[
	
		{
		  "title"      : "AI Security Built-in",
		  "category"   : "Natural Language Processing",
          "content": "The rapid evolution of generative artificial intelligence (AI) is reshaping our world, but it also brings forth a new array of security challenges. With AI systems finding their place in critical sectors like healthcare, finance, and transportation, they have become attractive targets for malicious actors.\n\nIn this blog post, we will embark on a journey to explore the realm of AI security, drawing from our own experiences in implementing AI applications. We will delve into the latest security standards and frameworks for AI, along with invaluable security best practices.\n\nIt is important to remember that security is not a one-size-fits-all solution, but rather a collection of data points that collectively enable better risk management outcomes. The standards, frameworks, and tools presented here serve as guiding principles to aid you on your own security journey, as they have ours. We hope you find this content as valuable as we have. Our motivation to write these blog posts stems not only from our desire to share knowledge but also to create a reference point for engaging with customers and partners.\n\nThis blog isn’t alarmist: it is informational, giving you more data points or showing you the data points we considered. It by no means covers everything, but gives you a reasoned view of the evolving landscape. The best approach to take with any new technology is balance and perspective, and try not get swept up in fear, hype or hysteria.\n\nSecurity Standards and Frameworks for AI\n\nThere are a number of security standards and frameworks that can be used to help mitigate the security risks of AI systems. Below we have put them under Government and Standards. Some of the below from governments are proposed laws or soon to be enforced. It is essential that you consider, like any other area of security, what jurisdictions you are likely to come under enforcement of. Often if you have customers in a location they will require you to be compliant with their local laws. Some of the most important standards and frameworks include:\n\nGovernment\n\n\n  \n    EU AI Act: This proposed regulation by the European Union sets out a number of security requirements for AI systems. The EU AI Act would require AI systems to be designed in a way that minimises the risk of harm, and to be subject to independent security assessments. Here is some very interesting research from Stanford Institute for Human-Centred Artificial Intelligence (HAI) on Do Foundation Model Providers Comply with the EU AI Act?. Research like this can show we need to assess these models carefully. The least privilege model or trust but verify model that we as an industry as a whole have so carefully built should still apply here even more so.\n  \n  \n    AI Framework US - Pending: This proposed framework by the United States government sets out a number of security requirements for AI systems. The pending AI Framework US would require AI systems to be designed in a way that minimises the risk of harm, and to be subject to independent security assessments. https://www.democrats.senate.gov/imo/media/doc/schumer_ai_framework.pdf\n  \n  \n    New York City AI Bias Law - Pending (July 5th): The law requires more transparency from employers that use AI and algorithmic tools to make hiring and promotion decisions. It also mandates that companies undergo annual audits for potential bias inside the machine. https://www.wilmerhale.com/en/insights/client-alerts/20230410-nyc-soon-to-enforce-ai-bias-law-other-jurisdictions-likely-to-follow\n  \n  \n    UK National Security Cyber Center: It’s interesting to see how different governments and government departments are thinking about this or putting out research. https://www.ncsc.gov.uk/blog-post/chatgpt-and-large-language-models-whats-the-risk\n  \n  \n    Australian AI Ethics Framework and Principles: This one is a bit older from back in 2019, but it shows lawmakers need to keep up with trends even if it’s putting out principles like this to give guidance. \nAI Ethics Framework\nAI Ethics Principles\n  \n\n\nStandards\n\n\n  \n    NIST AI RMF: This is a risk management framework developed by the National Institute of Standards and Technology (NIST). The AI RMF provides a structured approach to identifying, assessing, and mitigating the security risks of AI systems. If you want to read a very good analysis on NIST AI RMF, Walter Haydock, has done an amazing three part blog on this.\nFrame AI risk with the NIST RMF\nGovern AI risk with the NIST RMF: policies, procedures, and compliance\nGovern AI risk with the NIST RMF: accountability, communication, third parties, and more\n  \n  \n    OWASP Top 10 for LLMs: This is a list of the top 10 security risks for AI systems. OWASP Top 10 List for Large Language Models is a valuable resource for organizations that are developing or using AI systems. There is also the OWASP AI Security and Privacy Guide, as well as a good analysis from Reversing Labs on the OWASP Top 10 from an Application Security perspective. https://www.reversinglabs.com/blog/owasp-readies-top-10-for-llm-app-sec-risk-what-your-software-team-needs-to-know\n  \n  \n    MITRE regulatory framework: This framework provides a structured approach to complying with the security requirements of the EU AI Act and the Pending AI Framework US. A Sensible Regulatory Framework for AI Security.\n  \n  \n    Cloud Security Alliance: Security Implications of ChatGPT\n  \n  \n    OECD: https://oecd.ai/en/ai-principles\n  \n  \n    FAIR: Though FAIR isn’t considered a standard, I’ve added it here as they provide a standard to aim for and these articles should prove thought-provoking for the security professional.\nhttps://www.fairinstitute.org/blog/fair-cyber-risk-analysis-ai-insider-threat-chatgpt\nhttps://www.fairinstitute.org/blog/fair-cyber-risk-analysis-ai-phishing\nhttps://www.fairinstitute.org/blog/fair-cyber-risk-analysis-ai-exploiting-vulnerabilities\n  \n\n\nClouds\n\nIf you are hosting a model on one of the cloud providers AI services or using their AI services, as always check the Shared Responsibility Model to see the boundaries. It is wise to use the cloud providers’ frameworks and suggestions as your North star to aim for. They are providing suggestions and frameworks for you to operate in, and they have usually thought about these issues carefully, and of course they will naturally evolve quickly as the AI landscape changes.\n\n\n  Google Cloud Secure AI: https://blog.google/technology/safety-security/introducing-googles-secure-ai-framework/\n  Microsoft: https://www.microsoft.com/en-us/research/publication/responsible-ai-maturity-model/\n  AWS: https://docs.aws.amazon.com/whitepapers/latest/aws-caf-for-ai/aws-caf-for-ai.html\n  Facebook: https://ai.facebook.com/blog/facebooks-five-pillars-of-responsible-ai/\n\n\nGeneral Security Best Practices for AI\n\nIn addition to following the security standards and frameworks mentioned above, there are a number of general security best practices that can be used to mitigate the security risks of AI systems. Some of the most important best practices include:\n\n\n  Use secure development practices: This includes using standard secure coding practices, and conducting security reviews of AI models.\n  Use guardrails wherever possible: We learnt that we need to sanitise input as a general programming rule, so why shouldn’t that principle apply here too? Make sure the shape of the data is what you want before and after you send it to AI / ML models. Refer to tooling and guards further below.\n  Use secure infrastructure: This includes using secure cloud platforms, and implementing security controls around the data that is used to train and deploy AI models.\n  Monitor AI systems for security threats: This includes using security monitoring tools to detect and respond to security threats.\n\n\nTools:\n\n\n  https://github.com/leondz/garak/\n  https://github.com/NVIDIA/NeMo-Guardrails/\n  https://github.com/shreyar/guardrails\n  https://github.com/woop/rebuff\n  https://www.bearer.com/blog/devsecops-ai-openai\n  https://github.com/Bearer/bearer\n= https://www.robustintelligence.com/blog-posts/nemo-guardrails-early-look-what-you-need-to-know-before-deploying-part-1\n\n\nHelpful guides and articles\n\n\n  \n    AI attack surface map: This map provides a visualisation of the attack surface of AI systems. The map can be used to identify potential security vulnerabilities in AI systems. https://danielmiessler.com/p/the-ai-attack-surface-map-v1-0/\n  \n  Team8 CISOs Guide to Generative AI and ChatGPT Risk https://team8.vc/rethink/cyber/a-cisos-guide-generative-ai-and-chatgpt-enterprise-risks/\n  Honeycomb - All the Hard Stuff Nobody Talks About when Building Products with LLMs. When this came up it validated much of our thinking around where to use LLMs and what is difficult when integrating generative AI into our existing products. Honeycomb are some of the smartest engineers out there and their product is effective, so we place substantial weight on their experiences and opinions.\n  \n    Responsible AI: This blog from Unusual VC on Whose responsibility is responsible AI?. In my opinion this is one of the areas that is not talked about enough. If you want to delve into this deeper, I encourage you to check out a good knowledge base built up here https://github.com/alexandrainst/responsible-ai\n  \n  Manage Generative AI Risk Before It Manages You\n  Is Offensive AI Going to be a Problem for API Hackers?\n  Can you trust ChatGPT’s package recommendations?\n  Most popular generative AI projects on GitHub are the least secure\n  ExplAIning the Risk: Exploring the Large Language Models Open-Source Security Landscape\n  Protecting Enterprise Against the Dark Arts of Large Language Models\n  How to Talk to the C-Suite About AI Security\n  Are GPT-Based Models the Right Fit for AI-Powered Cybersecurity?\n  NVIDIA AI Red Team: An Introduction\n  4 vendor security risk assessment questions to ask companies using Artificial Intelligence (AI) in their software\n\n\nAI Vendor Risk Profiles, Risk Databases and Vulnerability Database\n\nWhat we have so far in this area is going to be very helpful. It’s going to be interesting to see how this work feeds into supply chain work. For me AI, ML it’s just another albeit special area of software engineering so we should aim for NIST SSDF for AI / ML engineering as well and as I’ve touched on before the below are just data points to help you along the way.\n\n\n  https://airisk.io/\n  https://avidml.org/\n= https://www.credo.ai/ai-vendor-directory\n\n\n",
          "url"        : "/natural%20language%20processing/enhancing-ai-security/",
		  "date"       : "2023-07-01 00:00:00 +0000",
		  "shortdate"  : "July 1, 2023"
		} ,
	
		{
		  "title"      : "Using NLP for Security and Compliance - Implementing Software Supply Chain Security",
		  "category"   : "Natural Language Processing",
          "content": "In the first part of this blog post series, we went over some use cases for using NLP for Security and Compliance. You can refer back to the first blog post to see the full list of use cases.\nFor this second part we will cover Use Case H which is related to software supply chain management, a hot topic at the moment.\n\n\n\n\n  📝 For a brief introduction to software supply chain security. There is also a good overview with some deeper dives into supply chain attacks.\n\n\nUse case H: Company B generates Software Bill of Materials on every release of both binaries and container images of all its microservices, which occur at least daily. It also generates SBOM of any major piece of software it runs e.g. ELT Tool, Dependency Track for every release we use. They want to know when or if a CVE appears in the output. They don’t want to have to search through daily or wait for a breach to happen to know they were affected.\n\nI won’t be focusing much on the different standards, frameworks or tools in the current supply chain ecosystem. My focus will instead be on the internal work we have done at Kapiche related to this topic and some of the interesting things we have discovered along our journey so far. We are starting to see a lot of movement in supply chain security on the vendor side e.g. I think I’ve updated and redone this blog four or five times cos of the additions to the pipeline just this year. What we hope to do via this blog and others sharing their implementation stories is share how companies are using tools and implementing supply chain security, so we can learn and build together.\n\nWhat I will go through below is our pipeline for dealing with the thousands of CVEs and finding what we actually need to fix, dealing with Software Bill of Materials (SBOM), Vulnerability Exploitability eXchange (VEX) and Vulnerability Disclosure Reports. We will go over what metadata we can go and where from, why we need and for what purpose and how it can make our lives easier in identifying what to fix and when.\n\nToo often SBOMs are being overused as the final goal. Instead like most things in security SBOMs should be treated as a data point, like VEX, EPSS and CVESs to get to our end goal or at least help us answer questions like:\n\n  Are we secure?\n  Are we affected by the CVEs the scanners are saying are critical?\n  What are the false positives or false negatives?\n  What is my risk?\n\n\nOne of the issues we ran into was that we had this ever-increasing sprawl of microservices, and with it came lots of SBOMs generated with Trivy. We could have published this for vendors, but SBOM data has many false positives and VEX reports can be cumbersome to maintain. So what else can we do with this data, and how can we automatically maintain our VEX data?\n\nWe publish this SBOM data to BigQuery, in keeping with our general data strategy, as a way to build a better picture of our entire landscape. We thought about what other metadata we need besides SBOM data and recently added SBOM scorecard metadata, this was mainly due to this amazing piece of analysis done by the Chainguard team. This was also to allow us to create policies in code in BigQuery around which SBOM data is considered valid based on certain standards e.g. Software Component Verification Standards BOM Maturity Model and our own internal policies as they evolve.\n\nWe then wanted to add vulnerability information. So initially we were sending this from Trivy, but now we get this from GKE container metadata using some interesting work Mark Chmarny has done around automating supply chain security.\n\nWe also wanted to pull in Exploit Prediction Scoring System (EPSS) data to be able to better score risk and likelihood. The Exploit Prediction Scoring System (EPSS) is an open source model provided by the non-profit Forum of Incident Response and Security Teams (FIRST). At a high level, the score refers to the probability (0-1 scale) that a Common Vulnerability and Exposure (CVE) will be exploited by a malicious actor in the next 30 days. Please see https://www.first.org/epss/model for additional details on how to interpret the results. See this article for a high-level analysis: Deep Dive into EPSS and Deploy Securely Risk Assessment Model on how to ingest EPSS and for help calculating the loss from the exploitation of a given vulnerability, using the confidentiality, integrity, and availability (CIA) triad. We have now enriched our vulnerability information with likelihood and severity information. Later we will further add our own context / likelihood categories / tags much like EPSS does based on our applications instead of the vulnerabilities so we can then match them up.\n\nAll the different types of data that are sent to BigQuery get put into partitioned tables and in different datasets. Then we have a daily scheduled query to join all our BigQuery datasets and put the results in a new dataset. Next we use the SBOM scoring and codified policies to make sure we have valid SBOMs, then we pull in the vulnerability data and join it on the application or container image name (generally these are the same). After that we use data from EPSS to add a risk level. We add some other risk metadata around concerns such as whether a component is internal or external, whether components are signed or unsigned, whether we know the component’s provenance.\n\n\n\n\n  📝 I must point out that we have a general strategy / policy that can’t always be adhered to, that is to use a new container image in one of our clusters, it needs to be signed and have provenance attached to it, as we have setup our Gatekeeper Open Policy Agent to only let container images run if they are from a known list and signed. Allowing only signed images requires extra setup, to call external data as shown here or use another policy controller from sigstore. We use a lot of the other examples as well from the Gatekeeper policy library, but those are the main two of interest for this topic. For this we often have to set up internal pipelines to sign these containers ourselves or get vendors to support this.\n\n\nSo once it has all been Ingested in BigQuery, we can then “Analyze” it in Kapiche. Now first we have metadata about the CVEs that scanners think are affecting our applications we are running and we have the title and description information for these. This is where I guess having an NLP engine comes in handy. I can look at the top 20 concepts and construct what we call themes for each. We first build out basic themes that match the EPSS data, as we will use that as part of our risk matrix. Then we will use what’s called the “Unmapped Verbatim’’ section to see if there is anything we are missing. Once we have our themes all worked out, we set up to ingest from BigQuery nightly so it will pick up any new data and see if anything new matches. We then set up an export job to push back into BigQuery what we have found. We then have a google sheet datasource in BigQuery which is just a map of each of our applications and the categories/tags that apply to them. We then use  the daily export from Kapiche and the application map to join against the categories and we then have a new automated way of getting to what we actually think we are vulnerable to. We then expose this data for internal consumption through a nice BI dashboard and to publish our final VEX report with vexctl. We can also see very early whether we need to put out a VDR. We then add a task to our weekly security check-in to go to our Kapiche analysis and check the “Unmapped Verbatims section, which tells us any new words that have not been included in any themes, so any words from titles or descriptions of vulnerabilities which are probably new vulnerabilities that have been picked up, that we have not mapped to Themes or Categories. We will also check the “Emerging Concepts’’ section of the product, this is helpful, as it will show us segments that are emerging and have high frequencies within a certain time period. So we can see CVEs with high EPSS segment data that have tags like user interactions and network.\n\nAn added benefit of having this continual data going into Kapiche, is we can jump in and answer any high level questions on numbers and segments across all our microservices. Kapiche is very good at slicing and dicing the data, so we can generally answer any adhoc question of the data.\n\nHere is one of our microservices Continous Integration, Continuous Deployment and Continous Attestation flows \n\nHere is our DevSecOps ToolChain \n\nFuture Work\n\nGreater Context\n\nWe are also looking for ways to add more metadata or context to this story. We use Dependency Track, which we also upload our SBOM data to, this has more vulnerability datasources, so can often give more context. It’s also a lot easier if we are given an SBOM from a vendor to upload and assess it, not that we are at that stage yet. We also have our policies in there around licenses and vulnerabilities much like we have in BigQuery. It tends to do a better job of component analysis or per service analysis, so we see a much more fine grained view. I have to find time to figure out how to export the information I want into the right format in BigQuery. This should give greater context to our analysis, then we can Share our results. I also want to share more of scripts we have done, even though most of what we have used is opensource, the key bits are the joining bits.\n\nMachine Learning\n\nWe are looking to apply more software engineering and supply chain management principles to our Machine Learning (ML) images and workflows. We currently build container images from the ML models we use. This means we download from HuggingFace or our ML Model Registry at build time instead of downloading at runtime. Three benefits we get from this: we are signing and being very declarative on what ML model and version we are using; and this metadata gets included in our pipeline for analysis; and the third one is faster start up times for our ML services, as sometimes these models can get up to 8 GB in size. We also get the added bonuses of adding signing and provenance to our ML models, which is lacking severely and is a huge hole in the industry at the moment: most models people use are either in cloud buckets or on Huggingface. Machine learning models should be built like other artifacts and using principles that are developing in the software supply chain like signing, provenance, attestation. The models should be then stored in artifact stores.\nAnother big area we are focusing on is ML image size: currently these can range from 2 GB to 5 GB, due to model size and tool bloat. For example, Nvidia drivers, pytorch, and then ML models on top. This can often mean many extra vulnerabilities to manage. One could use a cloud service to run models, but the problem still exists. I ran one of our models on Vertex AI and the image used came back with 271 vulnerabilities (11 High, 174 Medium) and it was still 2.7 GB. You need to make sure you are checking with your service providers what your Shared Responsibility Model is.\n\nIntegration\n\nWe are experimenting with a few Chainguard images for Python, Rust and tools like curl, kubectl etc. Expanding these out to be used in more services, especially Machine Learning images which I feel are very bloated.\n\nWe are also experimenting with OX Security for their Pipeline Bill of Materials. This is more experimenting at this stage, to see what they pickup and more value add they can add to our current flow. The other big thing we are excited about at the moment is Open Software Supply Chain Attack Reference (OSC&R) which is definitely worth the read. It’s basically the software supply chain equivalent of MITTRE ATT&CK.\n\nACKNOWLEDGEMENTS\n\nHuge thanks to Walter Haydock for his analysis, blogging and forward thinking with EPSS. The Chainguard team for their analysis and pushing forward of this space and everyone else working either in or around supply chain security at the moment. It feels like there is a lot of good momentum.\n\n",
          "url"        : "/natural%20language%20processing/using-nlp-for-compliance-part-2/",
		  "date"       : "2023-02-21 00:00:00 +0000",
		  "shortdate"  : "February 21, 2023"
		} ,
	
		{
		  "title"      : "Using NLP for Security and Compliance",
		  "category"   : "Natural Language Processing",
          "content": "As companies gather more data and face increasing compliance and security requirements across disparate data sources, it can be challenging to meet these obligations. One way to address these challenges is through the use of Natural Language Processing (NLP) techniques, which can be applied in a variety of areas, including phishing identification, source code and vulnerability analysis, event detection and prediction, threat detection and hunting, malware analysis, risk management, and compliance.\n\nLately there has been a lot of hype around ChatGPT with some use cases around offensive security, but ChatGPT is public, so we can’t use private company data and we can’t easily dig further into the why with its current capabilities. This is where Kapiche can come in. Kapiche is a feedback analytics platform that analyses mountains of customer feedback in minutes, allowing you to provide deep insights quickly and help your company make better decisions.\n\n\n\nThis is a two part blog series, where the main takeaways are Natural Language Processing (NLP) uses in Security and the help it can offer with operational use cases. I will take you through some use cases we have seen with customers, some we use internally at Kapiche “dogfooding” our own product. Finally we will cover some lesser known use cases / themes that you may not have thought of for NLP.\n\nBelow are some example use cases  / themes that might appear in your organisation.\n\nTheme Wellbeing monitoring / duty of care\n\nUse case A.1: Company A sends out internal staff surveys to get a pulse check on staff, and they want to monitor for keywords appearing, as they have internal policies and risk\n\nassessments around employee health and wellbeing e.g. We monitor for wellbeing and safety keywords around feeling ill and coming to work, mental health, so we can proactively monitor staff and de-risk the environment we work in.\n\nUse case A.2: Company A also has an internal chat system using Slack, which they also have the same reporting requirements as use case A.\n\nUse case B: A University provides a chat application to facilitate  student-faculty communication, regarding topics such as tutorials, lectures and general university lifestyle. The university has requirements around monitoring and reporting student wellbeing.\n\nTheme: Legal and Risk Reporting\n\nUse case C: Company A provides a chatbot to customers as their first line of online support. They have reporting and legal requirements around chatbots e.g. staying within internal policy requirements, data being collected and stored. Whether the chatbot is complying with industry regulations e.g. in advertising, chatbots will need to be programmed to comply with the relevant regulations (in the UK, the Advertising Standards Authority’s CAP code).‎\n\nUse case D: Company B has HIPAA requirements to report on when any HIPAA related records appear in their systems as they have a third party BAA with a particular customer, typical systems are very good at finding and reporting on HIPAA records found in structured data but tooling around alerting on HIPAA data found in unstructured data is varied to none. Here we can use NLP to search and alert on all unstructured data in the company and alert if we find any that meets requirements.\n\nUse case E: Company B has security policies, they want to make sure they are being upheld, so they combine all this information in a data warehouse with chat and support data and using NLP Semantic Search and Alerting, alerting can be configured to watch or continuously attest that we are adhering to policies.\n\nTheme: Security Incident Event Monitoring & Incident Management\n\nUse case F: Company A has security audit logs they store for long term audit requirements. They need to detect and report on specific events in a timely manner based on the company’s security policies.\n\nUse case G: Company C writes up all of its incidents in an incident management tool, as well as posting updates to their status tooling, and creating tickets in their ticketing system. They want to be aware of any trends, consistent wording across incidents and poor messaging to customers. There are also various laws in countries around reporting incidents, particularly security incidents, sometimes having all the information being fed into one place to search on trends, can help lead to better reporting and using Use case D above, can see incidents happen or evolve with the notes alongside.\n\nTheme: Supply Chain Management\n\nUse case H: Company B generates Software Bill of materials on every release of both binaries and container images of all its microservices, which occur at least daily. It also generates SBOM of any major piece of software it runs e.g. Airbyte for every release they have. They want to know when or if a CVE appears in our output. They don’t want to have to search through daily or wait for a breach to happen to know they were affected.\n\nThere are well known platforms and services that can achieve some of the above, of course SIEM and Threat Hunting can do a lot of the above. Cloud Posture management or Workload Protection can achieve Use Case G, Chatbot platforms can achieve Use Case C and HR platforms or internal survey platforms can do bits of Use Case A. You have tools specialising in those different areas, and will often do a very good job on showing you some high level stats, but what if I wanted to delve deeper into the why for any of the use cases above, or even better search across multiple data sources to see what patterns or compliance issues you are missing, then get alerted on them.\n\nThe two features that solve the above use cases in Kapiche are Alerting and Universal Search. \nWe will mainly go over in detail A.2 in this first part of the blog and then a follow up part 2, we will go over Use Case H as examples to break down how they work.\n\nFor our first detailed case, we will show you how to bring in Slack data and report on emerging themes, which covers Use case A.2. These are topics of discussion that have appeared recently or substantially increased in frequency. We want to be automatically alerted to the occurrence themes we want to monitor e.g. staff wellbeing, swear words, we could also add some of our internal bullying policy as a theme. We do this so we don’t have to manually look for them in the product each day, so it fits better into our operational workday. We are now more proactively monitoring our staff wellbeing and policy compliance, and hopefully de-risking the environment we work in.\n\nThis is what we will endevour to setup.\n\n\n\nSo how do we set this up? We first set up a Slack App and add the bot to the channels we want to pull data from. We used these instructions from Slack here.\nWe will need one app to pull the data from Slack, this bot gets added to the channels you want to pull data from. We then set up our Data Pipeline to retrieve the Slack data. We use Airbyte for this https://docs.airbyte.com/integrations/sources/slack/. We set up Airbyte ELT to pull the Slack data into an S3 bucket. We have set up both Airbyte and Kapiche to pull new files daily.\nThe second Slack Application, which we get the bot token for is the Kapiche bot that will send alerts to your slack, this bot needs much less access and probably only needs to be added to a single alerts channel. We then configure Slack notifications in Kapiche with the bot token we set up.\n\nNext we set up a theme to monitor.\nYou will notice as we add terms, the ‘OR’ operator that we click on shows us synonyms. These are synonyms in the Slack dataset, so ‘Health’ has appeared 49 times and has a similarity score of .486, this score is based on a centroid of all the words currently in the query. This helps us build out more accurate themes and quicker. As a bonus we can also find misspelt words.\n\n\n\nNow that we have our theme, we are going to set up an alert, using the Kapiche Radar. Here we set which Themes we want to monitor and alert on. If we have setup slack notifications it will also show an alert in Slack.\n\n\n\n\n\nNow whenever new data gets added daily, our radar will monitor for verbatims/terms that match our theme and alert us, allowing us to be much more proactive with staff e.g. the above alerted us it found 16 new verbatims from the day before around the wellbeing of staff. We can then click on the “Explore” link and see what staff were saying and if it is anything we need to follow up about.\n\nThis is just a simple use case demonstrating how to proactively monitor staff wellbeing with Slack data. There is a wide array of other compliance challenges and scenarios. For example, universities in New Zealand have the code of practice for pastoral care https://www.education.govt.nz/news/new-code-of-practice-for-the-pastoral-care-of-tertiary-and-international-learners/. This kind of code of practice or regulation is going to become increasingly prevalent, as mental health becomes more front and centre. Using proactive NLP-based techniques as we have discussed will allow companies and institutions to stay ahead of the regulatory and standards curve and minimise organisational risk.\n\n",
          "url"        : "/natural%20language%20processing/using-nlp-for-compliance/",
		  "date"       : "2023-01-03 00:00:00 +0000",
		  "shortdate"  : "January 3, 2023"
		} ,
	
		{
		  "title"      : "Using Private ACME server with Caddy and private certs in Python",
		  "category"   : "Engineering",
          "content": "Problem:\nIn order to request or have automatic Let’s Encrypt with Caddy you can either use HTTP-01 challenge, DNS challenge type or TLS ALPN challenge type. In order to use the HTTP or TLS challenge types you need to have your webserver publicly exposed on port 80 or 443. This worked for a while but we saw many bots and hack attempts, even though these servers were behind DDoS protection and bot protection services. We needed something better, something that would take us forward in our zero trust journey. Zero trust network access, as we aren’t really validating until we get to our webserver what or who is making the request, so we could do this better. We tried using the DNS challenge type but it required a service account key with pretty much full write access to a DNS zone, which moves the threat vector instead of fixing it.\n\nSolution:\nWe currently use Smallstep for Single sign on, two factor SSH authentication and they published a blog Automating internal TLS with ACME + Google CAS. This looked promising, we wanted to try out Google CA and Smallstep ACME Registration Authority (RA) server made sense. This way we could lock down lets encrypt requests only to come from our servers into the ACME Private server and our servers wouldn’t be public anymore.\n\nJourney:\nWe setup the Google CA and ACME server fairly easily following the instructions https://smallstep.com/docs/registration-authorities/acme-for-cas. The Smallstep ACME RA being available in the Google Cloud marketplace made things really easy.\n\nNow we want to setup firewall rules to only allow our webservers to access the new private ACME RA, so only we can use it. We also want firewall rules to lockdown our webservers our only expose them to the private ACME RA.\n\nWe then configure Caddy to use the new private ACME server, instructions given here https://smallstep.com/docs/tutorials/acme-protocol-acme-clients#caddy-v2 or here is our config:\n\n    tls {\n        issuer acme {\n             dir <acme ra server>\n             disable_http_challenge\n             trusted_roots ./certs/root_ca.crt\n        }\n    }\n\n\nWe disable the HTTP challenge, so we have only the secure TLS alpn challenge.\nWe can now use this Private ACME RA server for all the other supported acme clients https://smallstep.com/docs/tutorials/acme-protocol-acme-clients including Kubernetes cert-manager.\n\nWe have our private certificates setup and working with Caddy, but the microservices that talk to the webservers need the private certificate in their certificate store in order to send verified TLS requests.\nWe found a few old blog about using private certificates with Python but they didn’t quite work, either they were older blog articles or we must not have been doing something correctly. There is one issue raised in Python requests library which made things a little more nuanced https://github.com/psf/requests/issues/2966. Basically you have to work around the use of certifi and how it handles certificates.\n\nWe build our microservices in containers so we had to add the ca certificate into the container and add the following environment variables\n\nENV PATH=\"/opt/venv/bin:$PATH\" \\\n    PIP_CERT=\"/etc/ssl/certs/ca-certificates.crt\" \\\n    REQUESTS_CA_BUNDLE=\"/etc/ssl/certs/ca-certificates.crt\" \\\n    SSL_CERT_DIR=\"/etc/ssl/certs\"\n\n\nWe also had to link the certifi certificate to root as noted here. The script below adds our ca certificate at the top of the requests ca bundle we declared above.\n\n# Linking the certifi cert to root as noted \nRUN update-ca-certificates --fresh && \\\n    /scripts/py-ca-certs.sh && \\\n    ln -nfs \"${PIP_CERT:?Set me\\!}\" \"$(python3 -m certifi)\"\n\n\nNow when we make requests in our microservices, we add session.verify = True and everything will work as planned.\n\nNow we have this infrastructure setup, we have moved most of our cert-manager usage over to it and could move all public ACME requests over to the Google CA with the announcement recently of support https://cloud.google.com/blog/products/identity-security/automate-public-certificate-lifecycle-management-via–acme-client-api\n",
          "url"        : "/engineering/using-private-acme-server-with-caddy-and-private-certs-in-Python/",
		  "date"       : "2022-04-24 00:00:00 +0000",
		  "shortdate"  : "April 24, 2022"
		} ,
	
		{
		  "title"      : "Autoscaling on GKE and Seldon Core",
		  "category"   : "Machine Learning",
          "content": "Goal: Machine Learning service, deployed on Seldon Core, autoscales based on usage, so we optimise for costs and get the best performance for our customers.\n\nSteps to achieve:\n\n  Configure a new GPU node pool, that will be pre-emptible and autoscaling.\n\n\ngcloud container node-pools create gpu-burst-pool --cluster=botanic --zone us-central1-c --enable-autoscaling --enable-autorepair --enable-autoupgrade --num-nodes 4 --max-nodes=15 --min-nodes=1 --machine-type=n1-standard-8 --preemptible --node-labels=gpu=true --node-taints=preemptible=true:NoSchedule --accelerator=type=nvidia-tesla-t4,count=1 --disk-size 200GB --disk-type=pd-ssd --tags=ml\n\n\nNow we have a node pool, we deploy our application and run some tests to get some load against it. For our application we can see the profile of the application below. \n\nWe can see based on this, we should either scale based on CPU or GPU cycles. If we google, we can see some articles around scaling based on GPU cycles for Batch Machine learning applications, so this might be something to investigate. GPU cycle is not a normal metric to autoscale, on and in this article https://medium.com/deepdesk/scaling-workloads-based-on-gpu-utilization-in-gke-e852a8e47b4, it goes through how we have to install the GKE metrics adapater in order for the GPU cycle custom metric to appear in Google Monitoring.\n\nNow we have our metrics we need to scale on working, we add the horizontal pod autoscaler bit to our seldon core manifest like below:\n\n    - hpaSpec:\n        minReplicas: 1\n        maxReplicas: 15\n        metrics:\n        - type: External\n          external:\n            metricName: kubernetes.io|container|accelerator|duty_cycle\n            metricSelector:\n              matchLabels:\n                resource.labels.container_name: roberta\n            targetAverageValue: 35\n\n\nWe decided to use a targetAverageValue of 35, as usually when we start to get a bit of load it spikes about 40. At the moment, seldon core doesn’t support scaleUp and scaleDown behaviours, so we cant effect how quick we scale up or down, which is somewhat of a killer. We might even take this bit out of the seldon deploy and just use a normal horizonal pod autoscaler.\n",
          "url"        : "/machine%20learning/autoscaling-on-gke-seldon-deploy/",
		  "date"       : "2021-12-04 00:00:00 +0000",
		  "shortdate"  : "December 4, 2021"
		} ,
	
		{
		  "title"      : "Machine Learning on Kubernetes Journey",
		  "category"   : "Machine Learning",
          "content": "When choosing to use Kubeflow on Kubernetes we first looked at what was out there, in a traditional build vs buy analysis. We looked at the cloud offerings of AWS Sagemaker and GCP AI, SaaS offerings like Octoml, Algorithmia, Seldon Deploy and Datarobot but ultimately we decided to build, mainly so we could have more fine grained control at this early stage, we also wanted to offer the ability to customers to train their own models based on their datasets. We need to adhere to data locality laws, so security is important, we also felt we could learn more by building out our own platform based on Kubeflow and our core business is based on machine learning, so we didn’t think it was a waste of effort, especially if we consider this decision in the context of machine learning or Natural Language Processing in a Wardley Mapping Landscape.\n\nWe run our microservices on GKE, so found the GKE Kubeflow guide and started following it, but it assumed you have a management cluster and will install via Cloud Config Connectors, which is really nice if you want that automated kind of install, but we found it a bit too heavy or opinionated, especially if you are just trying out kubeflow. Then we looked into ArgoFlow, as this would use a lot of our existing GitOps infrastructure, and it felt natural that this would work the same way. We could not get it to deploy properly and felt like it had components we didn’t want, so we didn’t decide to use this, although we may come back to it, as it looks like a very nice project. In the end we decided to just use the basic manifests, so we could pick and choose components like a menu, here is the kustomize file we base our deployment from https://github.com/Kapiche/manifests/blob/v1.3-custom/example/kustomization.yaml. We used the kustomize setup they have listed here and ended up using ArgoCD in the end, so we have our own argoflow for now.\n\nOk now we have kubeflow installed and set up, it was time to play around with some notebooks, so we need some custom node pools in GCP with some GPU, so we can do some of the things we would usually do on Jupyter Notebooks and Google Colab in our own cluster.\n\nIf we aren’t doing host based routing, which we will most likely not do, we will do path based routing, which we need to customer VirtualServices:\n\napiVersion: networking.istio.io/v1alpha3\nkind: VirtualService\nmetadata:\n  name: kfserving-kapiche\n  namespace: kubeflow-user-example-com\nspec:\n  gateways:\n  - kubeflow/kubeflow-gateway\n  hosts:\n  - '*'\n  http:\n  - match:\n    - uri:\n        prefix: /kfserving/transformer-sample\n    route:\n    - destination:\n        host: cluster-local-gateway.istio-system.svc.cluster.local\n      headers:\n        request:\n          set:\n            Host: transformer-sample-transformer-default.kubeflow-user-example-com.svc.cluster.local\n      weight: 100\n    rewrite:\n        uri: /v1/models/transformer-sample\n    timeout: 300s\n\n\n\nThis allows us to use custom paths and redirect to the model v1 path, remember to always set the header to the transformer service, if there is one, not the predictor service like in this picture https://user-images.githubusercontent.com/6123106/122265361-52f9d400-cee1-11eb-8179-9ceb918c56f2.png\n\nWe need to also set up Authz. Here is a page outlining examples https://istio.io/latest/docs/tasks/security/authorization/authz-http/. Here is the example AuthorisationPolicy we used for testing.\n\napiVersion: security.istio.io/v1beta1\nkind: AuthorizationPolicy\nMetadata:\n  name: \"transformers-sample\"\n  namespace: kubeflow-user-example-com\nSpec:\n  Selector:\n    matchLabels:\n        serving.kubeflow.org/inferenceservice: transformer-sample\n  action: ALLOW\n  Rules:\n  - to:\n    - operation:\n        methods: [\"POST\"]\n\n\nSo now our ingress traffic will flow from the Google Load Balancer → Nginx Ingress → Istio Ingress Gateway. We leave Nginx ingress in there as it has some advantages for headers and controlling traffic. Our Google Load Balancer is only Layer4, it is more there for Cloud Armor and firewall protection.\n\nThe next thing we had to decide was which serving framework to use.\nIn Kubeflow, it supports two model serving systems that allow multi-framework model serving: KFServing and Seldon Core.\n\nComparison of kfserving vs seldon core https://www.kubeflow.org/docs/external-add-ons/serving/overview/\n\nWe decided to use Seldon Core, as most of the examples we tried with KFServing failed with google storage and transformers. This bad experience and the fact that Seldon Core had custom python wrappers led us to Seldon Core. We have our first service running in production, after scaling and integration tests. Some of the autoscaling features don’t quite work as documented for GPUs or to be more accurate, we need to scale based on gpu cycles, not GPU memory, as the profile of our application uses all the GPU memory sitting at idle, so scaling based off that would not make sense. So we found out we had to install the GKE metrics adapter https://medium.com/deepdesk/scaling-workloads-based-on-gpu-utilization-in-gke-e852a8e47b4.\n\nOther things we learned in our journey\n\n  For our jupyer notebooks we wanted them to run on GPUs to get a similiar experience to Google Colab, so we had to adjust the jupyter notebooks webapp config to be similiar to the below\n```\n— \napiVersion: v1\ndata: \nspawner_ui_config.yaml: |\n    spawnerFormDefaults:\n      image:\n        # The container Image for the user’s Jupyter Notebook\n        value: public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/jupyter-scipy:v1.3.0-rc.1\n        # The list of available standard container Images\n        options:\n        - public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/jupyter-scipy:v1.3.0-rc.1\n        - public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/jupyter-pytorch-full:v1.3.0-rc.1\n        - public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/jupyter-pytorch-cuda-full:v1.3.0-rc.1\n        - public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/jupyter-tensorflow-full:v1.3.0-rc.1\n        - public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/jupyter-tensorflow-cuda-full:v1.3.0-rc.1\n      imageGroupOne:\n        # The container Image for the user’s Group One Server\n        # The annotation notebooks.kubeflow.org/http-rewrite-uri: /\n        # is applied to notebook in this group, configuring\n        # the Istio rewrite for containers that host their web UI at /\n        value: public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/codeserver-python:v1.3.0-rc.1\n        # The list of available standard container Images\n        options:\n        - public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/codeserver-python:v1.3.0-rc.1\n      imageGroupTwo:\n        # The container Image for the user’s Group Two Server\n        # The annotation notebooks.kubeflow.org/http-rewrite-uri: /\n        # is applied to notebook in this group, configuring\n        # the Istio rewrite for containers that host their web UI at /\n        # The annotation notebooks.kubeflow.org/http-headers-request-set\n        # is applied to notebook in this group, configuring Istio\n        # to add the X-RStudio-Root-Path header to requests\n        value: public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/rstudio-tidyverse:v1.3.0-rc.1\n        # The list of available standard container Images\n        options:\n        - public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/rstudio-tidyverse:v1.3.0-rc.1\n      allowCustomImage: true\n      imagePullPolicy:\n        value: IfNotPresent\n        readOnly: false\n      cpu:\n        # CPU for user’s Notebook\n        value: ‘0.5’\n        # Factor by with to multiply request to calculate limit\n        # if no limit is set, to disable set “none”\n        limitFactor: “1.2”\n        readOnly: false\n      memory:\n        # Memory for user’s Notebook\n        value: 1.0Gi\n        # Factor by with to multiply request to calculate limit\n        # if no limit is set, to disable set “none”\n        limitFactor: “1.2”\n        readOnly: false\n      workspaceVolume:\n        # Workspace Volume to be attached to user’s Notebook\n        # Each Workspace Volume is declared with the following attributes:\n        # Type, Name, Size, MountPath and Access Mode\n        value:\n          type:\n            # The Type of the Workspace Volume\n            # Supported values: ‘New’, ‘Existing’\n            value: New\n          name:\n            # The Name of the Workspace Volume\n            # Note that this is a templated value. Special values:\n            # {notebook-name}: Replaced with the name of the Notebook. The frontend\n            #                  will replace this value as the user types the name\n            value: ‘workspace-{notebook-name}’\n          size:\n            # The Size of the Workspace Volume (in Gi)\n            value: ‘10Gi’\n          mountPath:\n            # The Path that the Workspace Volume will be mounted\n            value: /home/jovyan\n          accessModes:\n            # The Access Mode of the Workspace Volume\n            # Supported values: ‘ReadWriteOnce’, ‘ReadWriteMany’, ‘ReadOnlyMany’\n            value: ReadWriteOnce\n          class:\n            # The StrageClass the PVC will use if type is New. Special values are:\n            # {none}: default StorageClass\n            # {empty}: empty string “”\n            value: ‘fast-wait’\n        readOnly: false\n      dataVolumes:\n        # List of additional Data Volumes to be attached to the user’s Notebook\n        value: []\n        readOnly: false\n      gpus:\n        # Number of GPUs to be assigned to the Notebook Container\n        value:\n          # values: “none”, “1”, “2”, “4”, “8”\n          num: “none”\n          # Determines what the UI will show and send to the backend\n          vendors:\n          - limitsKey: “nvidia.com/gpu”\n            uiName: “NVIDIA”\n          vendor: “nvidia.com/gpu”\n        readOnly: false\n      shm:\n        value: true\n        readOnly: false\n      configurations:\n        value: \n          - ml\n          - add-grant-sudo\n        readOnly: false\n      affinityConfig:\n        # The default configKey from the options list\n        # If readonly, the default value will be the only option\n        value: “none”\n        # The list of available affinity configs\n        options:\n         - configKey: “GPU Affinity”\n           displayName: “Use GPU Training machine”\n           affinity:\n             nodeAffinity:\n               requiredDuringSchedulingIgnoredDuringExecution:\n                 nodeSelectorTerms:\n                   - matchExpressions:\n                       - key: “cloud.google.com/gke-nodepool”\n                         operator: “In”\n                         values:\n                           - “gpu-training-pool”\n        readOnly: false\n      tolerationGroup:\n        # The default groupKey from the options list\n        # If readonly, the default value will be the only option\n        value: “none”\n        # The list of available tolerationGroup configs\n        options:\n         - groupKey: “GPU Preemptible”\n           displayName: “Use GPU Burst Pool”\n           tolerations:\n             - key: “preemptible”\n               operator: “Equal”\n               value: “true”\n               effect: “NoSchedule”\n        readOnly: false\nkind: ConfigMap\nmetadata: \nlabels: \n  app: jupyter-web-app\n  kustomize.component: jupyter-web-app\nname: jupyter-web-app-config\nnamespace: kubeflow\n\n\n```\n\n\n  When starting a new notebook in kubeflow it gives you notebooks to start from based on pytorch, tensorflow etc. These are an ok starting point but often you need to have a better starting point or include custom packages, so we suggest starting from these https://github.com/DavidSpek/kubeflownotebooks and building your base notebooks. We have found these speeds up development for our data scientists. You will notice in the config above we use those notebooks.\n  Follow the guide as much as possible for istio e.g. Auth https://istio.io/latest/docs/tasks/security/authentication/authn-policy/\n  When upgrading to kubeflow which we use this branch now https://github.com/Kapiche/manifests/tree/v1.4-custom. Bring in the upgrades from upstream and slowly apply them. This gave us experience with the upgrades of each component. This method of upgrading also has allowed us to bring in upgrades of other components separately.\n  Some of our ML services will need to be managed differently to others e.g. Our first service is a sentiment analysis service. In our product we analyse customers feedback both internal and external and output sentiment. We analyse that feedback over time, so changing sentiment engines even if it’s an improved version, can make things vastly different and introduce issues in the analytics we are showing over time. So we must learn how to manage multiple versions of the same model and the same set of data for a customer must always be managed by the same version of the model. Our second service is a synonyms analysis service. This will show customers their synonyms for words that they want to get insights over. For this model, if we make it better, it will only make the synonyms better, so we don’t need to manage multiple versions.\n  Labelling datasets is hard. Use a service for this, we looked at https://labelbox.com/, https://aws.amazon.com/sagemaker/groundtruth, https://www.superb-ai.com, https://prodi.gy/ and https://github.com/microsoft/VoTT. There are more and more labelling/annotating services coming out all the time, so don’t try to do this yourself. We think it is a solved problem.\n\n\nAreas of Kubeflow still to investigate:\n\n  Pipelines - We tried pipelines but haven’t been able to fully utilise its power yet. We have plans for this, as we see how easier it can be to build a service with this and combine it with newer features like metadata management and hyper parameter tuning.\n  Investigate how we can integrate our streamlit process into the Kubeflow pipeline\n  Monitoring - We currently have basic monitoring on our services, but we intend to add Alibi detect for outliers and drift over the next couple of months.\n  Relook at KServing, we think kserving has a bigger community and the wonderful folks at Arriko have shown us many good resources/examples that are in the kserving repo, that have shown us how we could move our services to kserving and get greater integration into Kubeflow.\n  Investigate shadowing, canary, versions and mirroring types of deploys, to see how we could incorporate this into our services to roll out to customers faster.\n  Incorporate more of our security pipeline into Kubeflow e.g. Falco, Open Policy Agent, Zap Benchmarking, API Benchmarking and Project Sigstore model signing and verification\n\n\n",
          "url"        : "/machine%20learning/machine-learning-on-kubernetes-journey/",
		  "date"       : "2021-11-28 00:00:00 +0000",
		  "shortdate"  : "November 28, 2021"
		} 
	
]