What can AWS WAF do to protect your GenAI applications?

A few days ago I delivered an internal presentation, during the annual Tech Summit in AWS, about how AWS WAF can be used to protect GenAI applications.

In this presentation, I worked backward from the different risks listed in the OWASP Top 10 for LLMs and Generative AI Apps, and how the GenAI application is exposed to the internet.

Publicly exposed GenAI applications to anonymous users

In certain scenarios, the GenAI endpoint is exposed to anonymous users on the internet. Examples include an AI playground, or an AI assistant for shopping on an e-commerce website. The risks in such scenarios come to the light by understanding the economics of operating a GenAI application.

Let me explain.

Consider an example LLM app, that uses Claude 3 Sonnet model on Bedrock, with each inference consuming 1400 input tokens to accommodate context retrieved with RAG techniques, and 150 output tokens. With these assumptions, 1 million inferences cost around 6540$.

Now let's calculate how much it would cost an attacker to send 1 million inferences to this endpoint. Assuming that every inference takes 3 seconds to complete, and that an EC2 instance that allows me to send 1000 simultaneous inferences, they would need 10 EC2 instances over 5 mins to send 1 millions inferences with an cost less than 10 cents.

A 10 cents attack can generate 6540$ on the GenAI app bill. Such economics create considerable incentives for malicious activities against GenAI endpoints, for example to:

• Abuse public endpoints for unintended purposes. Malicious actors can abuse the output of a target model to train other models, or jail breaking the agent instructions to freely use the underlying LLM in their own apps.
• Drive competition out of business by causing Denial of Wallet situations, following a DDoS attack that caused unbearable inference costs.

OWASP Top 10 explains these threats in Model Denial of Service (LLM04) and Model Theft (LLM10).

AWS WAF helps managing such threats, with recommended rules against DDoS attacks, specific rules for GenAI applications (e.g. such as limiting request sizes to stay below the desired input token consumption limits), and most importantly, using Bot Control Managed rules. Bot Control combine different techniques to detect and manage traffic generate by bots:

• First, Bot Control forces the client to execute a Javascript challenge through the SDK, making sure the client is a browser.
• During the challenge step, Bot Control collects client side signals to detect disguised browsers or browser automation frameworks operating in stealth mode.
• If the challenge is solved, a token is issued (e.g. using a cookie), allowing Bot Control to analyze the behavior of a client during a session, and detect abnormal activities.
• Additionally, ML based clustering techniques are employed, to detect coordinated movements, such as low and slow bots trying to bypass the previous techniques.
• CAPTCHA can be leveraged in responses as an additional, when there is suspicion in the received request.

The price of AWS WAF including Bot Control is around 10.6$ for 1 million invocations. It is less than 0.16% of the inference cost. From another perspective, Bot Control is tool to reduce GenAI inference cost. To understand why, think about the amount of undesired automated traffic that your GenAI endpoint will quickly start to received once it is exposed to the internet (e.g. scanners, scrapers, etc..). With a hypothetical 20% ratio of bot traffic, Bot Control can remove 1300$ of our 1 million invocation example.

Publicly exposed GenAI applications to logged in users

Let's illustrate it with an online design application, allowing registered users to generate creative content using GenAI. Users can interact with your GenAI endpoint, only after registering and logging to your application.

In this scenario, the risk of DDoS attacks moves towards the account creation and login steps. A malicious actor can create fake accounts at scale, or try to take over existing account by discovering their credentials, and then log in to start abusing GenAI endpoints.

Account Creation Fraud Prevention, and Account Takeover Prevention are two managed rules available on AWS WAF that can help manage such risks.

They work in the same way as Bot Control, but add detections that are specific to registration / login workflows, such as:

• Comparing used credentials with a database of stolen credentials,
• Specific behavioral analysis such as failed login attempts, or password traversal attempts.

In all cases, I recommend to monitor user consumption metrics that are correlated with incurred GenAI cost. For example, if you use Bedrock for inference, you can find in its logs or in the API response the below latency and token consumption metrics:

"amazon-bedrock-invocationMetrics": 
{ 
     "inputTokenCount": 291,
     "outputTokenCount": 143, 
     "invocationLatency": 6540, 
     "firstByteLatency": 3901 
}        

If it's another type of GenAI endpoints, not offering such metrics, you can approximate it with server metrics. For example, using CloudFront in front of the GenAI endpoint, allows you to consume the following metrics in the real time logs: bytes from client to server, bytes from server to client, origin last byte latency, and origin first byte latency.

These metrics allow you to identify top talkers, using tools like CloudWatch Contributor insights, and then take action when abnormal usage is detected. The below example architecture illustrates how it can be automated:

The Lambda function, sitting behind CloudFront, is responsible for interacting with Bedrock, and authorizing the request based on the JWT token placed by Cognito during the authentication process. For every invocation, the function logs the consumption metrics received in the Bedrock response, together with the user id extracted from the JWT token, and sends it to a real time analytics pipeline, which detects abnormal behavior and sink the abuser ids in a DynamoDB table. On a regular basis, another Lambda function queries this table for abusers ids, and update WAF rules to block them.

Internal GenAI applications

Often companies start implementing GenAI applications internally to improve their business processes and improve work efficiency. It allows them also to experiment with GenAI technology in a more controlled environment before expanding the technology to publicly exposed applications.

To enrich the behavior of the GenAI application, plugins are often used by agents, for example to augment the prompt context with fetched data from external sources, or invoke APIs to execute actions based prompts. If not well secured, a malicious prompt can exploit vulnerabilities in plugins to cause harm, such as stealing or tampering with data, or executing undesired code.

OWASP Top 10 explains these threats in Insecure Output Handling (LLM02) and Insecure Plugin Design (LLM07). Protecting plugins from such exploits requires following security best practices such as input validation, software patching and using a Web Application Firewall (WAF). Plugins are rarely exposed to the internet, and often implemented in private subnets within VPCs. To use a WAF in a private network, customers can either implement appliance based WAFs from the AWS marketplace, or simply enable AWS WAF on plugins that use Application Load Balancers, API Gateway or AWS Appsync. AWS WAF is a serverless Web Application Firewall, offering managed rules to protect plugins such as the Core Rule Set, Admin Protection, and Known Bad Inputs rules, and can be enabled on resources in private VPCs.

Closing thoughts

This content provides a specialized, narrow perspective about the security of GenAI apps, focused on AWS WAF. Please consider GenAI security in a holistic way. You can start on this this landing page.

If you are interested in further exploring this topic for a GenAI application you are implementing, feel free to contact me ^^