Deploying LLMs Securely With OWASP Top 10

Generative Artificial Intelligence (GenAI) adoption is picking up pace. According to McKinsey, the rate of implementation has doubled compared to just ten months prior, with 65 percent of respondents saying their companies regularly use GenAI. The promise of disruptive impact to existing businesses — or delivering services into markets in new and more profitable ways — is driving much of this interest. Yet many adopters aren’t aware of the security risks at hand.

Earlier this year, the Open Worldwide Application Security Project (OWASP) released a Top 10 for Large Language Model (LLM) applications. Designed to provide hands-on guidance to software developers and security architects, the OWASP Top 10 guide lays out best practices for securely implementing GenAI applications that rely on LLMs. By explicitly naming the most critical vulnerabilities seen in LLMs thus far, prevention becomes a simpler task.

The biggest challenge around secure AI development, however, is not just knowing that problems might exist — this is true in any large software deployment. Instead, it is about how to help bridge the gaps that exist in cross-functional teams that span development, security, and line of business teams. Using OWASP Top 10, developers and security professionals can collaboratively map out their responsibilities across the whole AI application, then align with line of business teams on why these controls matter. 

On top of the technical security perspective, CISOs, too, can get a better overview of potential business risks associated with AI applications and attacks against their infrastructure. These attacks can vary from exploiting “traditional” software flaws that must be remediated to the hijacking and abuse of LLM service accounts that can cost organizations tens of thousands of dollars per day. For the CISO, explaining risk to the board and the business is essential when so many eyes are watching these potentially transformative projects. In essence, the pressure to deliver is high and the level of risk is growing; security should be involved from the start.

What Is in the OWASP Top 10 Today?

The OWASP Top 10 covers the following areas:

1. Prompt injection: How attackers might manipulate an LLM to carry out unforeseen or risky actions that affect the security of the output
2. Insecure output handling: Similar to more traditional security failures like cross-site scripting (XSS), Cross-Site Request Forgery (CSRF), and code execution, which occur when the LLM does not have appropriate security for its back-end systems
3. Training data poisoning: When the data set used to train the LLM includes an exploitable vulnerability
4. Model denial of service: When an attacker carries out actions that are resource-intensive, leading to either poor performance or significant bills for the victim organization
5. Supply chain vulnerabilities: Vulnerabilities that occur in more traditional software components or services and can then be exploited in an attack; the more complex the LLM application, the more likely it will have vulnerabilities to fix over time
6. Sensitive information disclosure: Incidents where an LLM may disclose information that should not be publicly available; to prevent this, ensure that training and production data are sanitized before using them
7. Insecure plugin design: Potential issues where plugins don’t protect the LLM against unauthorized access or insecure input, which can then lead to issues like remote code execution
8. Excessive agency: When the LLM can carry out more actions or has more permissions than it should have, leading to it undertaking tasks that it should not be allowed to carry out
9. Over-reliance: Where users rely on the LLM without carrying out appropriate checks on the content; this can lead to hallucinations, potential misinformation, or even legal issues
10. Model theft: When attackers access, copy, or steal proprietary LLM models

To implement the appropriate security measures for GenAI applications, developers should engage with security teams and carry out threat model exercises to better understand the potential risks involved.

Adding Security to GenAI

To deploy GenAI, developers have two choices: they can either adopt a service that fills the gap in their applications, or they can choose specific components and build a complete AI pipeline. For enterprises that want to use their own data to inform their AI applications, running a stack of AI components that equip them to more easily personalize their apps will be an advantage. These components are typically cloud-native and run on containerized architecture, as they can require large volumes of compute instances and storage to operate. 

Commonly, AI deployments use an orchestration tool like Kubernetes to manage workloads efficiently. Kubernetes makes it easier to deploy and scale GenAI, but it also introduces more complexity and security risks that organizations must consider. A containerized AI model running on a cloud platform has a very different set of security concerns to a traditional on-premises deployment or even other cloud-native containerized environments. With so many moving parts involved in the pipeline, and many of those elements being relatively new and developed fast, getting the right security insight in place right from the start is essential. 

The first step for security teams is to understand which components are in each AI application, covering the data, application components, and infrastructure together. This should be part of their overall IT asset inventory so they can catalog any existing AI services, tools, and owners in one place and keep that record up to date. This approach can also be used to create a Software Bill of Material (SBOM) for their AI system that includes all the relevant components. 

An AI SBOM generates a comprehensive list of all the software components, dependencies, and metadata associated with a GenAI workload, one which they can then follow up to track any changes that are needed over time. They can also apply this same approach to their AI data sources, based on how sensitive the data those sources contain. For general data — say a product catalog, website pages, or standard support material — information can be rated as public and used by anyone. For more sensitive data that includes either intellectual property, personally identifiable information (PII), or other information that must be kept secure, they can assign different levels of security access. This should help teams prioritize security for their AI workloads based on their risk severity level as well as the data that those workloads might use.

Posture Management

While implementing security for AI is essential, having proof of that implementation is also necessary for compliance and reporting. Ensuring that a system complies with the OWASP Top 10 is something that should be regularly affirmed so deployments are kept secure over time. This involves regularly auditing outlined aspects of the technology and checking that common security tasks are being followed, but it also covers the business process and workflow side.

Security and development teams can achieve this by mapping out their organization’s LLM security strategy to the MITRE Adversarial Threat Landscape for Artificial Intelligence Systems (ATLAS) framework. This will help teams look at their GenAI security in context with other application and software security requirements, such as those around their APIs, as well as other security holes that may exist. Whereas the OWASP Top 10 for LLMs provides guidance on where to harden GenAI applications and LLM systems against attack, MITRE ATLAS can be used to understand the signs that attackers might create during their reconnaissance or attack processes. By looking out for evidence of threat actors’ Tactics, Techniques & Procedures (TTPs), organizations can be more proactive in their approach.

Hardening Systems Involves Thinking Ahead

New systems like GenAI require new security models and new thinking around how to stay ahead of attackers. However, in the rush to meet the business goals set by implementing these new applications, it is all too easy to overlook the role that security should play. 

Frameworks like the OWASP Top 10 for LLMs help everyone understand the potential risks that exist and apply those guidelines to specific applications. However, AI workloads don’t run on their own — they may exist in software containers that are orchestrated by Kubernetes and run on the cloud. Kubernetes faces similar problems to GenAI in that it is still a very new technology and the best practices for security are not well-established across the industry. Using OWASP’s guidance for each of these platforms can make it easier to model potential threats and protect each layer of the infrastructure involved.

Clear-cut and auditable security processes can improve compliance reporting, threat mitigation, and workflows around application updates. They also improve the wider approach to deploying applications, ensuring that cloud security controls, processes, and procedures reduce potential exposure to evolving threats.