Building the foundations: A defender's guide to AWS Bedrock

Opinions regarding artificial intelligence (AI) range from fears of Skynet taking over to hope regarding medical advancements enabled by AI models. Regardless of where you sit on this spectrum of anxiety and hype, it is evident that the AI epoch is upon us.

While influencers and tech leadership pontificate about the impact of AI on both broader society as well as our cyber assets, developers are busy training data sets, tweaking models and generally injecting AI into their respective products and services.

For those of us charged with defending enterprises, the addition of AI workflows generates new challenges with additional services and systems to secure. Indeed, in the AI race, it is sometimes convenient to forget about the security of the systems on which the AI magic is developed.

Read on to learn about securing AWS Bedrock, a popular service for the creation and generation of AI workflows and models.

What is AWS Bedrock?

Within the cloud computing models, AWS Bedrock falls into the Software-as-a-Service (Saas) category.

A perhaps overly-simplistic way to think about AWS Bedrock is something along the lines of an AI development platform as a service.

According to official AWS Documentation, Bedrock is defined as:

”[…] a fully managed service that offers a choice of high-performing foundation models (FMs) from leading AI companies like AI21 Labs, Anthropic, Cohere, Meta, Mistral AI, Stability AI, and Amazon through a single API, along with a broad set of capabilities you need to build generative AI applications with security, privacy, and responsible AI.”

AWS Bedrock, in other words, manages the infrastructure necessary to create AI workflows and applications for its users. This allows AI developers to not worry about provisioning compute resources and to focus on AI-enabled application development.

Like any other cloud computing service, AWS Bedrock specifically and AI development generally are aspects that require a thoughtful security plan to be put in place to protect model data, intellectual property and generally anything that would affect the confidentiality, integrity or availability of AI workflows and development efforts.

Risks to AI workflows and AWS Bedrock

The introduction of AI development workflows into enterprises has added a layer of challenge and complexity for us defenders.

In addition to our existing mandate to secure cloud and on-premises workloads, we now also have to combine this general enterprise security orientation with an understanding of AI-specific risk avenues.

Practically speaking, this means that defenders need to take into account techniques found in the MITRE ATT&CK Cloud Matrix in addition to other frameworks such as the MITRE ATLAS Matrix as well as the OWASP Top 10 LLM Applications & Generative AI and OWASP Machine Learning Top 10 list.

Some examples of AI-specific risks can include:

• Prompt Injection
• Poisoning training data sets
• LLM data leakage
• Model denial of service
• Model theft

AWS Bedrock telemetry tour

AWS Bedrock telemetry generally falls into a few categories.

Bedrock CloudTrail management events cover Bedrock control plane operations.

We can see that this event looks very similar in structure to typical CloudTrail telemetry and includes the API call being used (ListFoundationModels) as well as information regarding the IP address, User Agent, AWS Region used and other request IDs that we will be coming back to in later sections of this blog. In this case, we can see that the event has an “eventCategory” of “Management”.

In addition to Management events, you can also configure Bedrock to log “Data” events. These events are higher in volume and cover data plane operations such as invocation telemetry.

In addition to management and data events, Bedrock also makes model invocation telemetry available. This provides us with deep visibility into prompts and model responses as well:

Finally, a fourth strand of telemetry that we will be looking at is good old-fashioned endpoint telemetry. This is necessary to cover AWS CLI usage that targets Bedrock operations and functionality.

For additional information, check out the excellent AWS documentation around monitoring AWS Bedrock.

In sum, we have four different telemetry strands to weave and work from in the context of Bedrock:

• Management events
• Data events
• Model invocation telemetry
• Endpoint telemetry

We will be utilizing all four of these lines of telemetry when looking at our rules and queries.

AWS Bedrock rules and hunts

Let’s look at AWS Bedrock Cloud SIEM rules as well as various Log Analytics Platform queries that can be executed to proactively detect threats in a Bedrock environment.

Enumeration and reconnaissance

When choosing to build AI applications of workloads on Bedrock, users can use “Base models” that are included with Bedrock or can customize and/or import models.

From a threat actor point of view, enumeration and reconnaissance are critical steps when targeting a victim user’s network or, in this case, an AI development environment.

We can map these aspects roughly to the AML.TA0002 MITRE Atlas category and to LLM 10 – Model Theft within the OWASP LLM/AI top 10.

To begin, we can detect the enumeration of Bedrock Foundation Models by operationalizing the “ListFoundationModels” CloudTrail event.

To make this type of alert more actionable, we can utilize Cloud SIEM’s UEBA rules, particularly the first seen rule type. Here, rather than alerting on every occurrence of this event and flooding our analysts, we can baseline this activity for a set period of time and alert when a user is enumerating Bedrock models for the first time since the established baseline period.

We can also generally look at when an AWS user is making Bedrock API calls not seen since the baseline period, as well as use Outlier rules to detect anomalous volumes of enumeration activity.

Initial access

After enumeration and discovery, the next logical step in a threat actor kill chain is initial access.

Consider the following scenario: a threat actor locates a leaked AWS key for your environment, performs the necessary reconnaissance and enumeration within the environment utilizing the stolen key and discovers that the Bedrock service is in use.

As a next step, this nefarious actor attempts to invoke an AWS Bedrock model using the stolen credentials and gets an access denied error. Although the activity failed, it would behoove us to alert and take action on it, as there may be other sensitive systems that this particular access key has access to beyond Bedrock.

In addition to the above, we can also create alerts that look for new AWS Bedrock Agents being created or a first seen role creating an AWS Bedrock agent.

Going off the rails

One key feature of AWS Bedrock is Guardrails. These are designed to implement some safeguards and controls around AI applications and prompts.

Depending on how the Guardrail is configured, it may protect against such as risks as LLM06 – Sensitive Information Disclosure as well as LLM05 – Model Denial of Service.

We can look at a user or administrator removing a Bedrock Guardrail with alerting logic, as Guardrails should only be removed by authorized users with some kind of ticket or change request associated with the activity.

In addition to the removal of Guardrails, another threat vector for Bedrock is changes to model invocation logging configurations. This creates an interesting dynamic, as defenders charged with monitoring AWS Bedrock must keep in mind AI-specific risks such as those found in the OWASP LLM Top 10 as well as MITRE ATLAS, in addition to more “traditional” threat vectors found in MITRE ATT&CK. In this instance, the model invocation logging configuration change can be mapped to T1562.008 – Impair Defenses: Disable or Modify Cloud Logs.

Hunting in AWS Bedrock telemetry

Model invocation telemetry is fairly verbose relative to other types of telemetry like AWS Bedrock Management Events. This dynamic lends itself well to proactive threat-hunting efforts.

LLM01 – Prompt injection – Direct prompt injection

We can look for attempts at direct prompt injections by utilizing model invocation telemetry, specifically looking at the input that the user interacting with the model or Agent utilized.

We can use regular expressions to create a list of keywords that we want to flag as sensitive, such as user inputs that contain phrases like “training data” or “model” or something else related to your specific industry or workload.

LLM03: Training data poisoning

Features of AWS Bedrock allow AI developers to fine tune and customize existing models. This is an event that can obviously occur during normal operations and is therefore infeasible to alert on every occurrence of it. However, this telemetry makes for a very rich hunting experience.

Model denial of service

Having the telemetry exposed by Bedrock model invocation logs lets us write queries that look at attempts at performing model denial of service. We can measure the length of users’ input/prompts and baseline activity, then add a qualifier to show results only when a user prompt is longer than the baselined amount.

Another approach is to sum up the input tokens used by a particular account ID so that we can flag on any deviations and anomalies.

AWS CLI profiling

It’s time for the fourth and final strand of telemetry that we will be exploring: endpoint telemetry.

One of the powerful features of Cloud SIEM is its built-in and constantly refreshed and updated log mappings, which serve to normalize disparate strands of telemetry.

We can abstract command lines to perform a count of AWS Bedrock command line actions a particular user and host have executed, categorizing them into “delete”, “get”, and “list” actions. This helps analysts quickly understand what types of AWS Bedrock command lines a user has executed.

Final thoughts

Much has been written and spoken about AI and every day it is becoming apparent that this technology is not only here to stay, but will have a material impact on both the social and professional aspects of our lives. For those in charge of defending enterprises and networks, the protection of AI workloads will predictably become a priority.

This blog has focused on AWS Bedrock and its relevant telemetry streams: CloudTrail management and data events, model invocation telemetry and endpoint telemetry. All four streams need to be understood, analyzed and formed into efficacious threat detection rules and proactive hunts to gain visibility into and protect the AWS Bedrock platform.