Today’s launch extends the abilities of Q Developer to access trusted AWS partner services that customers know and love. administrators on the Q Developer Pro Tier can enable plugins in the AWS Management Console by configuring the credentials to access these third party services. Builders can now easily query and interact with Datadog and Wiz services directly in the console using Q Developer, helping them find information faster and stay in the flow longer. Customers can access a subset of information from Datadog and Wiz using natural language by asking “@datadog are there any active alerts?” or @wiz what are my top 3 security issues today?
Datadog, an AWS Advanced Technology Partner and the observability and security platform for cloud applications, provides AWS customers with unified, real-time observability and security across their entire technology stack.
With Wiz, organizations can democratize security across the development lifecycle, empowering them to build fast and securely. As an AWS Security Competency Partner, Wiz is committed to effectively reducing risk for AWS customers by seamlessly integrating into AWS services.
When starting a new conversation with Q Developer, use the commands @datadog or @wiz to quickly learn more about these services in the context of your AWS resources. Q Developer will call out to these service APIs, assemble a natural language response, and return a summary with deep links to the Datadog and Wiz resources.
AWS Transit Gateway (TGW) and AWS Cloud WAN now support per availability zone (AZ) metrics delivered to CloudWatch. Furthermore, both services now support Path Maximum Transmission Unit Discovery (PMTUD) for effective mitigation against MTU mismatch issues in their global networks.
TGW and Cloud WAN allow customers to monitor their global network through performance and traffic metrics such as bytes in/out, packets in/out, and packets dropped. Until now, these metrics were available at an attachment level, and aggregate TGW and Core Network Edge (CNE) levels. With this launch, customers have more granular visibility into AZ-level metrics for VPC attachments. AZ-level metrics enable customers to rapidly troubleshoot any AZ impairments and provide deeper visibility in AZ-level traffic patterns across TGW and Cloud WAN.
TGW and Cloud WAN now also support standard PMTUD mechanism for traffic ingressing on VPC attachments. Until now, jumbo sized packets exceeding the TGW/CNE MTU (8500 bytes) would get silently dropped on VPC attachments. With this launch, an Internet Control Message Protocol (ICMP) Fragmentation Needed response message is sent back to sender hosts allowing them to remediate packet MTU size and thus minimize packet loss due to MTU mismatches in their network. PMTUD support is available for both IPv4 and IPv6 packets.
The per-AZ CloudWatch metrics and PMTUD support are available within each service in all AWS Regions where TGW or Cloud WAN are available. For more information, see the AWS Transit Gateway and AWS Cloud WAN documentation pages.
AWS Step Functions now supports exporting workflows as AWS CloudFormation or AWS Serverless Application Model (SAM) templates directly in the AWS console. This allows for centralized and repeatable provisioning and management of your workflow configurations. AWS Step Functions is a visual workflow service capable of orchestrating virtually any AWS service to automate business processes and data processing workloads.
Now, you can export and customize templates from existing workflows to easily provision them in other accounts or jump-start the creation of new workflows. When you combine the Step Functions templates you generate with those from other services, you can provision your entire application using AWS CloudFormation stacks. Additionally, you can export your workflows to the AWS Infrastructure Composer console to take advantage of the visual builder capabilities to create a new serverless application project. Using Infrastructure Composer, you can connect the workflow with other AWS resources and generate the resource configurations in an AWS SAM template.
We are happy to announce that AWS Glue, a serverless data integration service, is now available in the AWS Asia Pacific (Malaysia) Regions.
AWS Glue is a serverless data integration service that makes it simple to discover, prepare, and combine data for analytics, machine learning, and application development. AWS Glue provides both visual and code-based interfaces to make data integration simpler so you can analyze your data and put it to use in minutes instead of months.
Customers use Identity and Access Management (IAM) Access Analyzer unused access findings to identify over permissive access granted to IAM roles and users in their accounts or AWS organization. Now, customers can optionally customize the analysis to meet their needs. Customers can select accounts, roles, and users to exclude from analysis and focus on specific areas to identify and remediate unused access. They can use identifiers such as account ID or scale configuration using role tags. By scoping the analyzer to monitor a sub-set of accounts and roles, customers can streamline findings review and optimize costs of using unused access analysis. Customers can update the configuration at any time to change the scope of analysis. With the new offering, IAM Access Analyzer provides enhanced controls to help customers tailor the analysis more closely to their organization’s security needs.
This new feature is available in all AWS Commercial Regions. To learn more about IAM Access Analyzer unused access analysis, see the documentation.
Today, AWS announces the general availability of Microsoft Remote Desktop Services with AWS provided licenses. Customers can now purchase user-based subscription of Microsoft Remote Desktop Services licenses directly from AWS. This new offering provides licensing flexibility and business continuity for customers running graphical user interface (GUI) based applications on Amazon Elastic Compute Cloud (Amazon EC2) Windows instances.
Thousands of customers use Windows Server on Amazon EC2 to host custom applications or independent software vendor (ISV) products that require remote connectivity via Microsoft Remote Desktop Services. Previously, customers had to procure the licenses through various Microsoft licensing agreements. With the AWS provided subscription, customers can now access Microsoft Remote Desktop Services licenses from AWS on a per-user, per-month basis, eliminating the need for separate licensing agreements and reducing operational overhead. Unlike AWS provided Microsoft Office and Visual Studio, customers can continue using their existing Active Directory(s) for managing user access to GUI-based applications on Amazon EC2. Moreover, customers can have more than two concurrent user sessions with Windows Server instances. Lastly, AWS License Manager enables centralized tracking for license usage, simplifying governance and cost management. Customers can start using AWS provided Microsoft Remote Desktop Services licenses without rebuilding their existing Amazon EC2 instances, providing a seamless migration path for existing workloads.
Generative AI presents both immense opportunities and challenges for the Department of Defense (DoD). The potential to enhance situational awareness, streamline tasks, and improve decision-making is significant. However, the DoD’s unique requirements, especially their stringent security standards for cloud services (IL5), necessitate carefully crafted AI solutions that balance innovation with security.
The DoD’s 2023 Data, Analytics, and Artificial Intelligence Adoption Strategy report emphasizes the need to “strengthen the organizational environment” for AI deployment. This underscores the importance of solutions that seamlessly integrate into existing infrastructure, prioritize data security, and enable responsible and intelligent use of AI.
Google Public Sector’s 4 AI pillars: A framework for DoD AI adoption
To meet the DoD’s unique challenges, Google AI for Public Sector has focused on 4 areas when designing solutions to help empower the DoD:
Adaptive: AI solutions must seamlessly integrate into the DoD’s existing complex and evolving technology ecosystem. Google prioritizes adaptable solutions that minimize disruption and enable rapid adoption, aligning with the DoD’s focus on agile innovation.
Secure: Protecting sensitive DoD data is paramount. Google’s AI solutions are engineered with robust security measures, including Zero Trust architecture and adherence to IL5 requirements, ensuring the confidentiality and integrity of critical information.
Intelligent: Google’s AI capabilities are designed to deliver actionable insights from vast and diverse datasets. By harnessing the power of machine learning and natural language processing, our solutions enable the DoD to make data-driven decisions with greater speed and accuracy.
Responsible: Google is committed to developing and deploying AI in a responsible and ethical manner. Our AI Principles guide our research, product development, and deployment decisions, ensuring that AI is used for good and avoids harmful applications.
Breaking down data silos and delivering insights with enterprise search
Google Cloud’s solution for enterprise search is a powerful tool designed to help organizations overcome the challenges of data fragmentation. It acts as a central hub, seamlessly connecting to diverse data sources across the department, including structured and unstructured data.
Intelligent Information Retrieval: Leveraging advanced AI and natural language processing, enterprise search delivers precise and contextually relevant answers to queries, even when dealing with unstructured data like documents, images, and reports.
Seamless Integration: Federated search combined with Retrieval Augmented Generation (RAG) provides relevant query responses without the need to move data or train a custom Large Language Model (LLM).
Enhanced Transparency and Trust: The solution provides links to source documents alongside AI-generated responses, allowing users to verify information and build confidence in the system.
Robust Security: With all services used in the solution submitted for IL5 accreditation, enterprise search incorporates industry-leading security measures, including Role-Based Access Control (RBAC) and Common Access Card (CaC) compatibility, to safeguard sensitive DoD data.
Future-Proof Flexibility: The solution supports a wide range of Large Language Models (LLMs), including Google’s Gemini family of models and Gemma, our family of lightweight, state-of-the-art open models. Google offers choice, adaptability and avoids vendor lock-in, allowing the DoD to leverage the latest AI advancements without extensive redevelopment.
Google Cloud’s generative AI infused solution directly supports the DoD’s mission by consolidating data access, enhancing discoverability, and providing rapid, accurate insights, leading to improved decision-making and a strategic advantage.
Google Cloud is committed to supporting the DoD’s AI journey by providing solutions that are not only powerful and innovative, but also secure, responsible, and adaptable. By empowering the DoD to harness the full potential of its data, we are helping to enable more agile, informed, and effective service members. Learn more about how Google Public Sector’s AI solutions can empower your agency and visit Google AI for Public Sector for examples of how we are helping accelerate mission impact with AI.
Welcome to the first Cloud CISO Perspectives for November 2024. Today I’m joined by Andy Wen, Google Cloud’s senior director of product management for Google Workspace, to discuss a new Google survey into the high security costs of legacy tech.
As with all Cloud CISO Perspectives, the contents of this newsletter are posted to the Google Cloud blog. If you’re reading this on the website and you’d like to receive the email version, you can subscribe here.
–Phil Venables, VP, TI Security & CISO, Google Cloud
aside_block
<ListValue: [StructValue([(‘title’, ‘Get vital board insights with Google Cloud’), (‘body’, <wagtail.rich_text.RichText object at 0x3e6f0df2ddf0>), (‘btn_text’, ‘Visit the hub’), (‘href’, ‘https://cloud.google.com/solutions/security/board-of-directors?utm_source=cloud_sfdc&utm_medium=email&utm_campaign=FY24-Q2-global-PROD941-physicalevent-er-CEG_Boardroom_Summit&utm_content=-&utm_term=-‘), (‘image’, <GAEImage: GCAT-replacement-logo-A>)])]>
Confronting the high security cost of legacy tech
By Phil Venables, VP, TI Security & CISO, Google Cloud, and Andy Wen, senior director, product management, Google Workspace
From a business perspective, it’s easy to understand why many organizations continue to rely on outdated technology. Replacing older systems can be expensive, but relying on them comes with hidden costs that can far outstrip the benefits.
Legacy technology can greatly increase the business and security risks that an organization will face, a serious concern given that the global average total cost of a security breach in 2024 was $4.88 million. Despite the availability of a plethora of more modern solutions, we’re still seeing too many organizations rely on defenses that were designed for the desktop era, according to a new Google Workspace global cyber security survey of more than 2,000 security and IT decision-makers.
Phil Venables, VP, TI Security & CISO, Google Cloud
The numbers paint a dire picture of the security impact of operating legacy systems:
71% said that legacy technology has left organizations less prepared for the future.
63% believe that their organization’s technology landscape is less secure than it was in the past.
More than 66% told us that their organizations are investing more time and money than ever in securing their environments — but still experience costly security incidents.
81% of organizations experience at least one security incident per year.
Organizations experience eight security incidents on average per year.
We know many security leaders have convinced the business to invest in more security tools, because the survey also found that 61% of organizations are using more security tools than they did two years ago. Yet while more than two-thirds of organizations are investing more time and money in securing their environments, many are still experiencing expensive security incidents.
Andy Wen, senior director, product management, Google Workspace
Environments with more security tools often attempt to compensate for legacy platforms that continue to be vulnerable to security incidents. Meanwhile, 81% of security leaders believe cloud-first platforms are safer than legacy platforms.
Organizations with 10 or more security tools reported an average of 14 security incidents per year, with 34% of them spending more than $250,000 on incidents per year.
Organizations with fewer than 10 tools reported an average of six incidents per year, with 19% of them spending more than $250,000 on incidents per year.
“The solution is not more security tools, but more secure tools,” said CISA Director, Jen Easterly, at her mWISE Conference keynote in September.
We have also made this point often. To be truly resilient in today’s security landscape, organizations must consider an IT overhaul and rethink their strategy toward solutions with modern, secure-by-design architectures that nullify classes of vulnerabilities and attack vectors.
It may be daunting to take on an overhaul, especially for large organizations, but security leaders need to look at investing in a cloud-first solution to be resilient. The change can be made in small steps to minimize disruption and evaluate return on investment, such as using Chrome Enterprise for secure browsing and providing Google Workspace to specific teams.
The bottom line is that adopting modern technology can help eliminate entire classes of threats, as well as improve business outcomes.
We’d like to highlight three customer interactions that underscore organizational value gained by modernizing. Organizations need a centralized solution that can evolve, especially as attacks continue to increase in quantity and sophistication. We recently did some work with the cybersecurity company Trellix, which did a complete overhaul of its security infrastructure.
Trellix was running into issues where its old software stack felt stagnant and didn’t connect into new things they were doing or building. These older solutions made it hard to control where data was sitting and who was accessing it. They’ve since fully migrated to Google Workspace, adopted the Zero Trust capabilities we’ve built in, and augmented them with their own security solutions, including a security operations console, email security, and endpoint protection.
Employees can now chat, email, view files, edit documents, and join meetings from their device of choice without worrying about security and access permissions. All these capabilities live within the same platform, making it easier and simpler for security admins to oversee data safety with features like endpoint management and Zero Trust access controls in Workspace — without slowing down employee collaboration.
Similarly, the city of Dearborn, Mich., replaced its legacy email solution. After making the switch to Gmail, users noticed a meaningful decrease in spam, phishing, and malware, which helped reduce their cybersecurity risks.
Humana’s dilemma was driven by a legacy suite of desktop-based office applications that its IT team needed to spend 70% of its time maintaining. Humana’s IT team rolled out Google Workspace to 13,000 Humana employees in the field and in the office in four months, migrating 22 terabytes of data. Workspace’s built-in security features and browser-based apps saved the team time and reduced costs, and also led to a steady reduction in help desk tickets during and after rollout.
For more leadership guidance from Google Cloud experts, please see our CISO Insights hub.
aside_block
<ListValue: [StructValue([(‘title’, ‘Join the Google Cloud CISO Community’), (‘body’, <wagtail.rich_text.RichText object at 0x3e6f0df2d370>), (‘btn_text’, ‘Learn more’), (‘href’, ‘https://rsvp.withgoogle.com/events/ciso-community-interest?utm_source=cgc-blog&utm_medium=blog&utm_campaign=2024-cloud-ciso-newsletter-events-ref&utm_content=-&utm_term=-‘), (‘image’, <GAEImage: GCAT-replacement-logo-A>)])]>
In case you missed it
Here are the latest updates, products, services, and resources from our security teams so far this month:
Join our upcoming Security Talks to unlock the Defender’s Advantage: Our next Security Talks is coming on Nov. 19, and will focus on the Defender’s Advantage. This free, day-long virtual event is packed with insights and strategies to help you proactively secure your cloud environment. Register today.
Cyber risk top 5: What every board should know: Boards should learn about security and digital transformation to better manage their organizations. Here’s five top risks they need to know — and prepare for. Read more.
Mandatory MFA is coming to Google Cloud. Here’s what you need to know: To help keep our customers secure, starting in 2025 we will require them to use MFA when accessing Google Cloud. Read more.
Google Cloud expands CVE program: As part of our commitment to security and transparency on vulnerabilities found in our products and services, we now will issue CVEs for critical Google Cloud vulnerabilities. Read more.
Our 2025 Forecast report: Get ready for the next year in cybersecurity with our 2025 Forecast report, now available. Read more.
From AI to Zero Trust, Google Cloud Security delivers comprehensive public sector solutions: Google Cloud Security is committed to helping government agencies and organizations strengthen their defenses, and we recently made several announcements at the Google Public Sector Summit. Read more.
FedRAMP High development in the cloud: Code with Cloud Workstations: A Forrester Total Economic Impact™ (TEI) study found that Google Cloud Workstations enhance consistency, agility, and security while reducing costs and risks. Read more.
Please visit the Google Cloud blog for more security stories published this month.
(In)tuned to take-overs: Abusing Intune permissions for lateral movement and privilege escalation: Learn how the Mandiant Red Team was able to move laterally from a customer’s on-premises environment to their Microsoft Entra ID tenant, and obtained privileges to compromise existing Entra ID service principals installed in the tenant. Also learn how to defend against it. Read more.
Flare-On 11 Challenge solutions: The latest Flare-On challenge is over, and it proved a doozy: Only 275 players out of 5,300 completed all 10 stages. Read more.
Please visit the Google Cloud blog for more threat intelligence stories published this month.
Now hear this: Google Cloud Security and Mandiant podcasts
Gen AI security: Unseen attack surfaces and pentesting lessons: What’s the current state of gen AI security? From common mistakes to novel attack surfaces to unique challenges, podcast hosts Anton Chuvakin and Tim Peacock discuss with Ante Gojsalic, co-founder and CTO, SplxAI, today’s gen AI security concerns and their potential impact on tomorrow’s tech. Listen here.
Get the Google Security Operations perspective on SIEM and security data lakes: What’s a disassembled SIEM, and why you should care: Travis Lanham, uber tech lead for Security Operations Engineering, Google Cloud, goes SIEM-deep with Anton and Tim. Listen here.
To have our Cloud CISO Perspectives post delivered twice a month to your inbox, sign up for our newsletter. We’ll be back in two weeks with more security-related updates from Google Cloud.
It’s an exciting time in the world of data and analytics, with more organizations harnessing the power of data and AI to help transform and grow their businesses. But in a threat landscape with increasingly sophisticated attacks around every corner, ensuring the security and integrity of that data is critical.
Google Cloud offers a comprehensive suite of tools to help protect your data while unlocking its potential. In our new ebook, Building a Secure Data Platform with Google Cloud, we dig into the many data security capabilities within Google Cloud and share how they can help support data-based innovation strategies.
Take a peek inside the ebook, then download the full version here.
aside_block
<ListValue: [StructValue([(‘title’, ‘$300 in free credit to try Google Cloud data analytics’), (‘body’, <wagtail.rich_text.RichText object at 0x3e6f0e6fc0d0>), (‘btn_text’, ‘Start building for free’), (‘href’, ‘http://console.cloud.google.com/freetrial?redirectPath=/bigquery/’), (‘image’, None)])]>
Unlock data platform-level security with BigQuery BigQuery, Google Cloud’s unified data platform, offers a robust set of integrated security features to help you safeguard your data. The platform automatically encrypts all data at rest, which provides a foundational layer of defense against unauthorized access. For data sharing, BigQuery Analytics Hub and data clean rooms allow you to efficiently, securely, and easily share data across organizational boundaries. The platform also includes Dataplex, which enables you to implement comprehensive policies to govern how data is accessed, used, and shared within your organization.
Shield assets with granular access controls and guardrails With Cloud Identity and Access Management (IAM), you can manage access to critical data across BigQuery, Cloud Run, Cloud Run functions, and Google Kubernetes Engine (GKE) resources. Organization restrictions place further limits on which users can access resources in your organization. Combined with Cloud IAM, this feature supports your organization policies and helps you maintain a secure perimeter around your Google Cloud environment.
Create security boundaries with perimeter and data protection Google Cloud offers several ways to reinforce your perimeter. VPC Service Controls help prevent data exfiltration from cloud resources, providing precise control over access and movement by external entities or by insiders.
Meanwhile, with Sensitive Data Protection, you can identify and classify your sensitive data within BigQuery, which can help you implement targeted protection measures such as masking, tokenization, and redaction. You can also gain even more granular control over your encryption keys with Customer-managed encryption keys for BigQuery.
Strengthen data security posture with automated monitoring and compliance Establishing robust security controls for your data is essential for improving your security posture, but it’s just as important to monitor your environment for threats and maintain compliance with industry standards. Security Command Center gives you a comprehensive view of your security posture with direct visibility into your BigQuery datasets. With Cloud Logging, you can collect, store, and analyze logs to gain insights into system activities, detect anomalies, and respond to security incidents. Assured Workloads further simplifies compliance, providing peace of mind that you’ve established strong baseline controls and compliant configurations.
All-in-one data security with integrated solutions from Google Cloud
Building a secure data ecosystem requires a multi-layered approach. With comprehensive security features from Google Cloud, you can safeguard your sensitive data, comply with industry regulations, and discover the full potential of your data. Dive deeper into these tools, solutions, and strategies in the full ebook — Building a Secure Data Platform with Google Cloud — to ensure the safety and integrity of your organization’s most valuable asset. Download the full version here.
As open-source large language models (LLMs) become increasingly popular, developers are looking for better ways to access new models and deploy them on Cloud Run GPU. That’s why Cloud Run now offers fully managed NVIDIA GPUs, which removes the complexity of driver installations and library configurations. This means you’ll benefit from the same on-demand availability and effortless scalability that you love with Cloud Run’s CPU and memory, with the added power of NVIDIA GPUs. When your application is idle, your GPU-equipped instances automatically scale down to zero, optimizing your costs.
In this blog post, we’ll guide you through deploying the Meta Llama 3.2 1B Instruction model on Cloud Run. We’ll also share best practices to streamline your development process using local model testing with Text Generation Inference (TGI) Docker image, making troubleshooting easy and boosting your productivity.
aside_block
<ListValue: [StructValue([(‘title’, ‘$300 in free credit to try Google Cloud AI and ML’), (‘body’, <wagtail.rich_text.RichText object at 0x3e6f0cf8f040>), (‘btn_text’, ‘Start building for free’), (‘href’, ‘http://console.cloud.google.com/freetrial?redirectPath=/vertex-ai/’), (‘image’, None)])]>
Why Cloud Run with GPU?
There are four critical reasons developers benefit from deploying open models on Cloud Run with GPU:
Fully managed: No need to worry about drivers, libraries, or infrastructure.
On-demand scaling: Scale up or down automatically based on demand.
Cost effective: Only pay for what you use, with automatic scaling down to zero when idle.
Performance: NVIDIA GPU-optimized for Meta Llama 3.2.
Initial Setup
First, create a Hugging Face token.
Second, check that your Hugging Face token has permission to access and download Llama 3.2 model weight here. Keep your token handy for the next step.
Third, use Google Cloud’s Secret Manager to store your Hugging Face token securely. In this example, we will be using Google user credentials. You may need to authenticate for using gcloud CLI, setting default project ID, and enable necessary APIs, and grant access to Secret Manager and Cloud Storage.
code_block
<ListValue: [StructValue([(‘code’, ‘# Authenticate CLIrngcloud auth loginrnrn# Set default projectrngcloud config set project <your_project_id>rnrn# Create new secret key, remember to update <your_huggingface_token>rngcloud secrets create HF_TOKEN –replication-policy=”automatic”rnecho -n <your_huggingface_token> | gcloud secrets versions add HF_TOKEN –data-file=-rnrn# Retrieve the keyrnHF_TOKEN=$(gcloud secrets versions access latest –secret=”HF_TOKEN”)’), (‘language’, ”), (‘caption’, <wagtail.rich_text.RichText object at 0x3e6f0cf8f490>)])]>
Local debugging
Install huggingface_cli python package in your virtual environment.
Run huggingface-cli login to set up a Hugging Face credential.
Use the TGI Docker image to test your model locally. This allows you to iterate and debug your model locally before deploying it to Cloud Run.
Now, we will create a new Cloud Run service using the deployment script as follows. (Remember to update BUCKET_NAME). You may also need to update the network and subnet name as well.
AWS Lambda now supports creating serverless applications using Python 3.13. Developers can use Python 3.13 as both a managed runtime and a container base image, and AWS will automatically apply updates to the managed runtime and base image as they become available.
Python 3.13 is the latest long-term support (LTS) release of Python and is expected to be supported for security and bug fixes until October 2029. This release provides Lambda customers access to the latest Python 3.13 language features. You can use Python 3.13 with Lambda@Edge (in supported Regions), allowing you to customize low-latency content delivered through Amazon CloudFront. Powertools for AWS Lambda (Python), a developer toolkit to implement serverless best practices and increase developer velocity, also supports Python 3.13.
You can use the full range of AWS deployment tools, including the Lambda console, AWS CLI, AWS Serverless Application Model (AWS SAM), AWS CDK, and AWS CloudFormation to deploy and manage serverless applications written in Python 3.13. For more information, including guidance on upgrading existing Lambda functions, read our blog post. For more information about AWS Lambda, visit the product page.
New solutions, old problems. Artificial intelligence (AI) and large language models (LLMs) are here to signal a new day in the cybersecurity world, but what does that mean for us—the attackers and defenders—and our battle to improve security through all the noise?
Data is everywhere. For most organizations, the access to security data is no longer the primary issue. Rather, it is the vast quantities of it, the noise in it, and the disjointed and spread-out nature of it. Understanding and making sense of it—THAT is the real challenge.
When we conduct adversarial emulation (red team) engagements, making sense of all the network, user, and domain data available to us is how we find the path forward. From a defensive perspective, efficiently finding the sharpest and most dangerous needles in the haystack—for example, easily accessible credentials on fileshares—is how we prioritize, improve, and defend.
How do you make sense of this vast amount of structured and unstructured data, and give yourself the advantage?
Data permeates the modern organization. This data can be challenging to parse, process, and understand from a security implication perspective, but AI might just change all that.
This blog post will focus on a number of case studies where we obtained data during our complex adversarial emulation engagements with our global clients, and how we innovated using AI and LLM systems to process this into structured data that could be used to better defend organizations. We will showcase the lessons learned and key takeaways for all organizations and highlight other problems that can be solved with this approach for both red and blue teams.
Approach
Data parsing and understanding is one of the biggest early benefits of AI. We have seen many situations where AI can help process data at a fast rate. Throughout this post, we use an LLM to process unstructured data, meaning that the data did not have a structure or format that we knew about before parsing the data.
If you want to try these examples out yourself, please make sure you use either a local model, or you have permission to send the data to an external service.
Getting Structured Data Out of an LLM
Step one is to get the data into a format we can use. If you ever used an LLM, you will have noticed it will output as a story or prose text, especially if you use chat-based versions. For a lot of use cases, this is fine; however, we want to analyze the data and get structured data. Thus, the first problem we have to solve is to get the LLM to output the data in a format we can specify. The simple method is to ask the LLM to output the data in a machine readable format like JSON, XML, or CSV. However, you will quickly notice that you have to be quite specific with the data format, and the LLM can easily output data in another format, ignoring your instructions.
Luckily for us, other people have encountered this problem and have solved it with something called Guardrails. One of the projects we have found is called guardrails-ai. It is a Python library that allows you to create guardrails—specific requirements—for a model based on Pydantic.
To illustrate, take a simple Python class from the documentation to validate a pet from the output of the LLM:
from pydantic import BaseModel, Field
class Pet(BaseModel):
pet_type: str = Field(description="Species of pet")
name: str = Field(description="a unique pet name")
You can use the next code from the Guardrails documentation to process the output of the LLM into a structured object:
from guardrails import Guard
import openai
prompt = """
What kind of pet should I get and what should I name it?
${gr.complete_json_suffix_v2}
"""
guard = Guard.from_pydantic(output_class=Pet, prompt=prompt)
raw_output, validated_output, *rest = guard(
llm_api=openai.completions.create,
engine="gpt-3.5-turbo-instruct"
)
print(validated_output)
If we look at what this library generates underwater for this prompt, we see that it adds a structured object part with the instructions for the LLM to output data in a specific way. This streamlines the way you can get structured data from an LLM.
Figure 1: The generated prompt from the Pydantic model
For the next use case, we will show the Pydantic models we’ve created to process the output.
Red Team Use Cases
The next sections contain some use cases where we can use an LLM to get structured data out of data obtained. The use cases are divided into three categories of the attack lifecycle:
Initial Reconnaissance
Escalate Privileges
Internal Reconnaissance
Figure 2: Attack lifecycle
Initial Reconnaissance
Open Source Intelligence (OSINT) is an important part of red teaming. It includes gathering data about the target organization from news articles, social media, and corporate reports.
This information can then be used in other red team phases such as during phishing. For defenders, it helps them understand which parts of their organization are exposed to the internet, anticipating a possible future attack. In the next use case, we talk about processing social media information to process roles and extract useful information.
Use Case 1: Social Media Job Functions Information
During OSINT, we often try to get information from employees about their function in their company. This helps with performing phishing attacks, as we do not want to target IT professionals, especially those that work in cybersecurity.
Social media sites allow their users to write about their job titles in a free format. This means that the information is unstructured and can be written in any language and any format.
We can try to extract the information from the title with simple matches; however, because the users can fill in anything and in any language, this problem can be better solved with an LLM.
Data Model
First, we create a Pydantic model for the Guardrail:
class RoleOutput(BaseModel):
role: str = Field(description="Role being analyzed")
it: bool = Field(description="The role is related to IT")
cybersecurity: bool = Field(description="The role is related to
CyberSecurity")
experience_level: str = Field(
description="Experience level of the role.",
)
This model has two Boolean options if the role is IT or cybersecurity related. Additionally, we would like to know the experience level of the role.
Prompt
Next, let’s create a prompt to instruct the LLM to extract the requested information from the role. This prompt is quite simple and just asks the LLM to fill in the data.
Given the following role, answer the following questions.
If the answer doesn't exist in the role, enter ``.
${role}
${gr.complete_xml_suffix_v2}
The two last lines are placeholders used by guardrails-ai.
Results
To test the models, we have scraped the titles that employees use on social media. This dataset contained the titles that the employees used and contained 235 entries. For testing, we used the gemini-1.0-pro model.
Gemini managed to parse 232 entries. The results are shown in Table 1.
Not IT
IT
Cybersecurity
Gemini
183
49
5
Manual evaluation by a red team operator
185
47
5
False positive
1
3
0
Table 1: Results of Gemini parsing 232 job title entries
In the end, Gemini processed the roles quite on par with a human. Most of the false positives were questionable because it is not very clear if the role was actually IT related. The experience level did not perform well, as the model deemed the experience level as “unknown” or “none” for most of the entries. To resolve this issue, the field was changed so that the experience level should be a number from 1 to 10. After running the analysis again, this yielded better results for the experience level. The lowest experience levels (1–4) contained function titles like “intern,” “specialist,” or “assistant.” This usually indicated that the person had been employed at that role for a shorter period of time. The updated data model is shown as follows:
class RoleOutput(BaseModel):
role: str = Field(description="Role being analyzed")
it: bool = Field(description="The role is related to IT")
cybersecurity: bool = Field(description="The role is related to
CyberSecurity")
experience_level: int = Field(
description="Estimate of the experience level of the role on
a scale of 1-10. Where 1 is low experience and 10 is high.",
)
This approach helped us to sort through a large dataset of phishing targets by identifying employees that did not have IT and cybersecurity roles, and sorting them by experience level. This can speed up target selection for large organizations and may allow us to better emulate attackers by changing the prompts or selection criteria. To defend against this, data analysis is more difficult. In theory, you can instruct all your employees to include “Cybersecurity” in their role, but that does not scale well or solve the underlying phishing problem. The best approach with regards to phishing is, in our experience, to invest into phishing resistant multifactor authentication (MFA) and application allowlisting. If applied well, these solutions can mitigate phishing attacks as an initial access vector.
Escalate Privileges
Once attackers establish a foothold into an organization, one of their first acts is often to improve their level of access or control through privilege escalation. There are quite a few methods that can be used for this. It comes in a local system-based variety as well as wider domain-wide types, with some based on exploits or misconfigurations, and others based on finding sensitive information when searching through files.
Our focus will be on the final aspect, which aligns with our challenge of identifying the desired information within the vast amount of data, like finding a needle in a haystack.
Use Case 2: Credentials in Files
After gaining initial access to the target network, one of the more common enumeration methods employed by attackers is to perform share enumeration and try to locate interesting files. There are quite a few tools that can do this, such as Snaffler.
After you identify files that potentially contain credentials, you can go through them manually to find useful ones. However, if you do this in a large organization, there is a chance that you will have hundreds to thousands of hits. In that case, there are some tools that can help with finding and classifying credentials like TruffleHog and Nosey Parker. Additionally, the Python library detect-secrets can help with this task.
Most of these tools look for common patterns or file types that they understand. To cover unknown file types or credentials in emails or other formats, it might instead be valuable to use an LLM to analyze the files to find any unknown or unrecognized formats.
Technically, we can just run all tools and use a linear regression model to combine the results into one. An anonymized example of a file with a password that we encountered during our tests is shown as follows:
@Echo Off
Net Use /Del * /Yes
Set /p Path=<"path.txt"
Net Use %Path% Welcome01@ /User:CHAOS.LOCALWorkstationAdmin
If Not Exist "C:Data" MKDIR "C:Data"
Copy %Path%. C:Data
Timeout 02
Data Model
We used the following Python classes to instruct Gemini to retrieve credentials with an optional domain. One file can contain multiple credentials, so we use a list of credentials to instruct Gemini to optionally retrieve multiple credentials from one file.
class Credential(BaseModel):
password: str = Field(description="Potential password of an account")
username: str = Field(description="Potential username of an account")
domain: Optional[str] = Field(
description="Optional domain of an account", default=""
)
class ListOfCredentials(BaseModel):
credentials: list[Credential] = []
Prompt
In the prompt, we give some examples of what kind of systems we are looking for, and output into JSON once again:
Given the following file, check if there are credentials in the file.
Only include results if there is at least one username and password.
If the domain doesn't exist in the file, enter `` as a default value.
${file}
${gr.complete_xml_suffix_v2}
Results
We tested on 600 files, where 304 contain credentials and 296 do not. Testing occurred with the gemini-1.5 model. Each file took about five seconds to process.
To compare results with other tools, we also tested Nosey Parker and TruffleHog. Both NoseyParker and Truffle Hog are made to find credentials in a structured way in files, including repositories. Their use case is usually for known file formats and randomly structured files.
The results are summarized in Table 2.
Tool
True Negative
False Positive
False Negative
True Positive
Nosey Parker
284 (47%)
12 (2%)
136 (23%)
168 (28%)
TruffleHog
294 (49%)
2 (<1%)
180 (30%)
124 (21%)
Gemini
278 (46%)
18 (3%)
23 (4%)
281 (47%)
Table 2: Results of testing for credentials in files, where 304 contain them and 296 do not
In this context, the definitions of true negative, false positive, false negative, and true positive are as follows:
True Negative: A file does not contain any credentials, and the tool correctly indicates that there are no credentials.
False Positive: The tool incorrectly indicates that a file contains credentials when it does not.
False Negative: The tool incorrectly indicates that a file does not contain any credentials when it does.
True Positive: The tool correctly indicates that a file contains credentials.
In conclusion, Gemini finds the most files with credentials, at a cost of a slightly higher false positive rate. TruffleHog has the lowest false positive rate, but also finds the least amount of true positives. This is to be expected, as a higher true positive rate usually is accompanied by a higher false positive rate. The current dataset has almost an equal number of files with and without credentials—in real-world scenarios this ratio can differ wildly, which means that the false positive rate is still important even though the percentages are quite close.
To optimize this approach, you can use all three tools, combine the output signals to a single signal, and then sort the potential files based on this combined signal.
Defenders can, and should, use the same techniques previously described to enumerate the internal file shares and remove or limit access to files that contain credentials. Make sure to check what file shares each server and workstation exposes to the network, because in some cases file shares are exposed accidentally or were forgotten about.
Internal Reconnaissance
When attackers have gained a better position in the network, the next step in their playbooks is understanding the domain in which they have landed so they can construct a path to their ultimate goal. This could be full domain control or access to specific systems or users, depending on the threat actor’s mission. From a red team perspective, we need to be able to emulate this. From a defender’s perspective, we need to find these paths before the attackers exploit them.
The main tool that red teamers use to analyze Active Directory is BloodHound, which uses a graph database to find paths in the Active Directory. BloodHound is executed in two steps. First, an ingester retrieves the data from the target Active Directory. Second, this data is ingested and analyzed by BloodHound to find attack paths.
Some tools that can gather data to be used in BloodHound are:
Sharphound
Bloodhound.py
Rusthound
Adexplorer
Bofhound
Soaphound
These tools gather data from the Active Directory and other systems and output it in a format that BloodHound can read. In theory, if we have all the information about the network in the graph, then we can just query the graph to figure out how to achieve our objective.
To improve the data in BloodHound, we have thought of additional use cases. Use Case 3 is about finding high-value systems. Discovering more hidden edges in BloodHound is part of Use Case 4 and Use Case 5.
Use Case 3: High-Value Target Detection in Active Directory
By default, BloodHound deems some groups and computers as high value. One of the main activities in internal reconnaissance is figuring out which systems in the client’s network are high-value targets. Some examples of systems that we are interested in, and that can lead to domain compromise, are:
Backup systems
SCCM
Certificate services
Exchange
WSUS systems
There are many ways to indicate which servers are used for a certain function, and it depends on how the IT administrators have configured it in their domain. There are some fields that may contain data in various forms to indicate what the system is used for. This is a prime example of unstructured data that might be analyzable with an LLM.
The following fields in the Active Directory might contain the relevant information:
Name
Samaccountname
Description
Distinguishedname
SPNs
Data Model
In the end, we would like to have a list of names of the systems the LLM has deemed high value. During development, we noticed that LLM results improved dramatically if you asked it to specify a reason. Thus, our Pydantic model looks like this:
class HighValueSystem(BaseModel):
name: str = Field(description="Name of this system")
reason: str = Field(description="Reason why this system is
high value", default="")
class HighValueResults(BaseModel):
systems: list[HighValueSystem] = Field(description="high value
systems", default=[])
Prompt
In the prompt, we give some examples of what kind of systems we are looking for:
Given the data, identify which systems are high value targets,
look for: sccm servers, jump systems, certificate systems, backup
systems and other valuable systems. Use the first (name) field to
identify the systems.
Results
We tested this prompt on a dataset of 400 systems and executed it five times. All systems were sent in one query to the model. To accommodate this, we used the gemini-1.5 model because it has a huge context window. Here are some examples of reasons Gemini provided, and what we think the reason was based off:
Domain controller: Looks like this was based on the “OU=Domain Controllers” distinguishedname field of BloodHound
Jumpbox: Based on the “OU=Jumpboxes,OU=Bastion Servers” distinguishedname
Lansweeper: Based on the description field of the computer
Backup Server: Based on “OU=Backup Servers” distinguishedname
Some of the high-value targets are valid yet already known, like domain controllers. Others are good finds, like the jumpbox and backup servers. This method can process system names in other languages and more verbose descriptions of systems to determine systems that may be high value. Additionally, this method can be adapted to allow for a more specific query—for example, that might suit a different client environment:
Given the data, identify which systems are related to
SWIFT. Use the first (name) field to identify the systems.
In this case, the LLM will look for SWIFT servers and may save you some time searching for it manually. This approach can potentially be even better when you combine this data with internal documentation to give you results, even if the Active Directory information is lacking any information about the usage of the system.
For defenders, there are some ways to deal with this situation:
Limit the amount of information in the Active Directory and put the system descriptions in your documentation instead of within the Active Directory
Limit the amount of information a regular user can retrieve from the Active Directory
Monitor LDAP queries to see if a large amount of data is being retrieved from LDAP
Use Case 4: User Clustering
After gaining an initial strong position, and understanding the systems in the network, attackers will often need to find the right users to compromise to gain further privileges in the domain. For defenders, legacy user accounts or administrators with too many rights is a common security issue.
Administrators often have multiple user accounts: one for normal operations like reading email and using it on their workstations, and one or multiple administrator accounts. This separation is done to make it harder for attackers to compromise the administrator account.
There are some common flaws in the implementations that sometimes make it possible to bypass these separations. Most of the methods require the attacker to cluster the users together to see which accounts belong to the same employee. In many cases, this can be done by inspecting the Active Directory objects and searching for patterns in the display name, description, or other fields. To automate this, we tried to find these patterns with Gemini.
Data Model
For this use case, we would like to have the account’s names that Gemini clusters together. During initial testing, the results were quite random. However, after adding a “reason” field, the results improved dramatically. So we used the next Pydantic model:
class User(BaseModel):
accounts: list[Account] = Field(
description="accounts that probably belongs
to this user", default=[]
)
reason: str = Field(
description="Reason why these accounts belong
to this user", default=""
)
class UserAccountResults(BaseModel):
users: list[User] = Field(description="users with multiple
accounts", default=[])
Prompt
In the prompt, we give some examples of what kind of systems we are looking for:
Given the data, cluster the accounts that belong to a single person
by checking for similarities in the name, displayname and sam.
Only include results that are likely to be the same user. Only include
results when there is a user with multiple accounts. It is possible
that a user has more than two accounts. Please specify a reason
why those accounts belong to the same user. Use the first (name)
field to identify the accounts.
Results
The test dataset had about 900 users. We manually determined that some users have two to four accounts with various permissions. Some of these accounts had the same pattern like “user@test.local” and “adm-user@test.local.” However, other accounts had patterns where the admin account was based on the first couple of letters. For example, their main account had the pattern matthijs.gielen@test.local, and the admin account was named: adm-magi@test.local. To keep track of those accounts, the description of the admin account contained some text similar to “admin account of Matthijs Gielen.”
With this prompt, Gemini managed to cluster 50 groups of accounts in our dataset. After manual verification, some of the results were discarded because they only contained one account in the cluster. This resulted in 43 correct clusters of accounts. Manually, we found the same correlation; however, where Gemini managed to output this information in a couple of minutes, manually this took quite a bit longer to analyze and correlate all accounts. This information was used in preparation for further attacks, as shown in the next use case.
Use Case 5: Correlation Between Users and Their Machines
Knowing which users to target or defend is often not enough. We also need to find them within the network in order to compromise them. Domain administrators are (usually) physical people; they need somewhere to type in their commands and perform administrative actions. This means that we need to correlate which domain administrator is working from which workstation. This is called session information, and BloodHound uses this information in an edge called “HasSession.”
In the past, it was possible to get all session information with a regular user during red teaming.
Using the technique in Use Case 4, we can correlate the different user accounts that one employee may have. The next step is to figure out which workstation belongs to that employee. Then we can target that workstation, and from there, hopefully recover the passwords of their administrator accounts.
In this case, employees have corporate laptops, and the company needs to keep track of which laptop belongs to which employee. Often this information is stored in one of the fields of the computer object in the Active Directory. However, there are many ways to do this, and using Gemini to parse the unstructured data is one such example.
Data Model
This model is quite simple, we just want to correlate machines to their users and have Gemini give us a reason why—to improve the output of the model. Because we will send all users and all computers at once, we will need a list of results.
class UserComputerCorrelation(BaseModel):
user: str = Field(description="name of the user")
computer: str = Field(description="name of the computer")
reason: str = Field(
description="Reason why these accounts belong to this user",
default=""
)
class CorrelationResults(BaseModel):
results: list[UserComputerCorrelation] = Field(
description="users and computers that correlate", default=[]
)
Prompt
In the prompt, we give some examples of what kind of systems we are looking for:
Given the two data sets, find the computer that correlates
to a user by checking for similarities in the name, displayname
and sam. Only include results that are likely to correspond.
Please specify a reason why that user and computer correlates.
Use the first (name) field to identify the users and computers.
Results
The dataset used contains around 900 users and 400 computers. During the assignment, we determined that the administrators correlated users and their machines via the description field of the computer, which was sort of equal to the display name of the user. Gemini correctly picked up this connection, correctly correlating around 120 users to their respective laptops (Figure 3).
Figure 3: Connections between user and laptop as correlated by Gemini
Gemini helped us to select an appropriate workstation, which enabled us to perform lateral movement to a workstation and obtain the password of an administrator, getting us closer to our goal.
To defend against these threats, it can be valuable to run tools like BloodHound in the network. As discussed, BloodHound might not find all the “hidden” edges in your network, but you can add these yourself to the graph. This will allow you to find more Active Directory-based attack paths that are possible in your network and mitigate these before an attacker has an opportunity to exploit those attack paths.
Conclusion
In this blog post, we looked at processing red team data using LLMs to aid in adversarial emulation or improving defenses. These use cases were related to processing human-generated, unstructured data. Table 3 summarizes the results.
Use Case
Accuracy of the Results
Usefulness
Roles
High: There were a few false positives that were in the gray area.
High: Especially when going through a large list of roles of users, this approach will provide fairly fast results.
Credentials in files
High: Found more credentials than comparable tools. More testing should look into the false-positive rate in real scenarios.
Medium: This approach finds a lot more results; however, processing it with Gemini is a lot slower (five seconds per file) than many other alternatives.
High-value targets
Medium: Not all results were new, nor were all high-value targets.
Medium: Some of the results were useful; however, all of them still require manual verification.
Account clustering
High: After taking into account the clusters with one account, the other ones were well clustered.
High: Clustering users is most of the time a tedious process to do manually. It gives fairly reliable results if you filter out the results with only one account.
Computer correlation
High: All results were correctly correlated users to their computers.
High: This approach produces accurate results potentially providing insights into extra possible attack paths.
Table 3: The results of our experiments of data processing with Gemini
As the results show, using an LLM like Gemini can help in converting this type of data into structured data to aid attackers and defenders. However, keep in mind that LLMs are not a silver bullet and have limitations. For example, they can sometimes produce false positives or be slow to process large amounts of data.
There are quite a few use cases we have not covered in this blog post. Some other examples where you can use this approach are:
Correlating user groups to administrator privileges on workstations and servers
Summarizing internal website content or documentation to search for target systems
Ingesting documentation to generate password candidates for cracking passwords
The Future
This was just an initial step that we on the Advanced Capabilities team on the Mandiant Red Team have explored so far when using LLMs for adversarial emulation and defense. For next steps, we know that the models and prompts can be improved by testing variations in the prompts, and other data sources can be investigated to see if Gemini can help analyze them. We are also looking at using linear regression models as well as clustering and pathfinding algorithms to enable cybersecurity practitioners to quickly evaluate attack paths that may exist in a network.
AWS announces two AI-powered enhancements to AWS CloudTrail Lake, a managed data lake that helps you capture, immutably store, access, and analyze your activity logs, as well as AWS Config configuration items. These new capabilities simplify log analysis, enabling deeper insights and quicker investigations across your AWS environments:
AI-powered natural language query generation in CloudTrail Lake is now generally available in seven AWS Regions: Mumbai, N. Virginia, London, Tokyo, Oregon, Sydney, and Canada (Central). This feature allows you to ask questions about your AWS activity in plain English, without writing complex SQL queries. For example, you can ask, “Which API events failed in the last week due to missing permissions?” CloudTrail Lake then generates the corresponding SQL query, streamlining your analysis of AWS activity logs (management and data events).
AI-powered query result summarization is now available in preview in the N. Virginia, Oregon, and Tokyo Regions. This feature provides natural language summaries of your query results, regardless of whether the query was generated through the natural language query generation feature or manually written in SQL. This capability significantly reduces the time and effort required to extract meaningful insights from your AWS activity logs (management, data, and network activity events). For example, after running a query to find users with the most access denied requests, you can click “Summarize” to get a concise overview of the key findings.
Today, AWS announces the general availability of ListBillingViews API in the AWS SDKs, to enable AWS Billing Conductor (ABC) users to create pro forma Cost and Usage Reports (CUR) programmatically.
Today, CUR PutReportDefinition API requires a BillingViewArn – the Amazon resource name for a billing view, to populate the CUR with proforma data. Prior to this launch customers had to manually construct the BillingView Arn by retrieving Payer account and Primary account IDs and adding the metadata to the string arn:aws:billing::payer-account-id:billingview/billing-group-primary-account-id. ABC users can now eliminate these manual steps to retrieve the BillingViewArn, and automate the end-to-end CUR file configuration journey, based on each pro forma billing view available. As a result, ListBillingView API enables ABC users to simplify ABC onboarding and accelerate the ability to set up their rebilling operations.
ListBillingViews API is available in all commercial AWS Regions, excluding the Amazon Web Services China (Beijing) Region, operated by Sinnet and Amazon Web Services China (Ningxia) Region, operated by NWCD.
To learn more about this feature integration, visit the AWS Billing Conductor product page, or review the API Reference.
Amazon OpenSearch Service now supports 4th Generation Intel Xeon Scalable processors based compute optimized (C7i), general purpose (M7i), and memory optimized (R7i) instances. These instances deliver up to 15% better price performance over 3rd generation Intel C6i, M6i & R6i instances respectively. You can update your domain to the new instances seamlessly through the OpenSearch Service console or APIs.
These instances support new Intel Advanced Matrix Extensions (AMX) that accelerate matrix multiplication operations for applications such as CPU-based ML. The 4th generation Intel instances support the latest DDR5 memory, offering higher bandwidth compared to 3rd generation Intel processors. To learn more about 4th generation intel improvements, please see the following C7i blog, M7i blog & R7i blog.
One or more than one 4th generation Intel instance types are now available on Amazon OpenSearch Service across 22 regions globally: US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Canada (Central), Asia Pacific (Jakarta), Asia Pacific (Malaysia), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Milan), Europe (Paris), Europe (Spain), Europe (Stockholm), South America (Sao Paulo), AWS GovCloud (US-East) and AWS GovCloud (US-West).
To learn more about region specific instance type availability and their pricing, visit our pricing page. To learn more about Amazon OpenSearch Service, please visit the product page.
AWS B2B Data Interchange now enables you to generate electronic data interchange (EDI) mapping code using generative AI. This new capability expedites the process of writing and testing bi-directional EDI mappings, reducing the time, effort, and costs associated with migrating your EDI workloads to AWS. AWS B2B Data Interchange is a fully managed service that automates the transformation of business-critical EDI transactions at scale, with elasticity and pay-as-you-go pricing.
With AWS B2B Data Interchange’s new generative AI-assisted mapping capability, you can leverage your existing EDI documents and transactional data stored in your Amazon S3 buckets to generate mapping code using Amazon Bedrock. Once the mapping code is generated, it is managed within AWS B2B Data Interchange where it is used to automatically transform new EDI documents to and from custom data representations. Previously, you were required to write and test each EDI mapping manually, which was a time-consuming and difficult process that required niche EDI specialization. AWS B2B Data Interchange’s new generative AI-assisted mapping capability increases developer productivity and reduces the technical expertise required to develop mapping code, so you can shift resources back to the valued-added initiatives that drive meaningful business impact.
AWS B2B Data Interchange’s generative AI-assisted mapping capability is available in US East (N. Virginia) and US West (Oregon). To learn more about building and running your EDI workflows on AWS, visit the AWS B2B Data Interchange product page or review the documentation.
AWS Client VPN now supports Linux desktop client with Ubuntu versions 22.04 LTS and 24.04 LTS. You can now run the AWS supplied VPN client on the latest Ubuntu OS versions. AWS Client VPN desktop clients are available free of charge, and can be downloaded here.
AWS Client VPN is a managed service that securely connects your remote workforce to AWS or on-premises networks. It supports desktop clients for MacOS, Windows, and Ubuntu-Linux. With this release, CVPN now supports the latest version of Ubuntu client (i.e. 22.04 LTS and 24.04 LTS). It already support Mac OS version 12.0, 13.0 and 14.0, and Windows 10 and 11.
This client version is available in all regions where AWS Client VPN is generally available with no additional cost.
We are excited to announce Amazon GameLift now supports containers for building, deploying, and running game server packages. Amazon GameLift is a fully managed service that allows developers to quickly manage and scale dedicated game servers for multiplayer games. With this new capability, Amazon GameLift supports end-to-end development of containerized workloads, including deployment and scaling on-premises, in the cloud, or hybrid configurations. This reduces the time it takes to deploy a new version to approximately 5 minutes. It makes production updates faster, and removes the need to host separate customized development environments for quick iteration.
Containers package the entire runtime environment needed to run game servers, including code, dependencies, and configuration files. This allows developers to seamlessly move game server builds between local machines, staging, and production deployments without worrying about missing dependencies or configuration drift. Containers also enable efficient resource utilization by running multiple isolated game servers on the same host machine. Overall, containerization simplifies deployment, ensures consistent and secure environments, and optimizes resource usage for game servers. Containers integrate with AWS Graviton instances and Spot Instances, and run games designed for a containerized environments including those built with popular game engines like Unreal and Unity.
Amazon GameLift manged containers support is now generally available in all Amazon GameLift regions except AWS China. To get started with Amazon GameLift managed containers, visit the Amazon GameLift managed containers documentation.
Amazon CloudWatch Application Signals, an application performance monitoring (APM) feature in CloudWatch, makes it easy to automatically instrument and track application performance against their most important business or service level objectives (SLOs). Customers can now receive alerts when these SLOs reach a critical burn rate. This new feature allows you to calculate how quickly your service is consuming its error budget relative to the SLO’s attainment goal. Burn rate metrics provide a clear indication of whether you’re meeting, exceeding, or at risk of failing your SLO goals.
Today, with burn rate metrics, you can configure CloudWatch alarms to notify you automatically when your error budget consumption exceeds specified thresholds. This allows for proactive management of service reliability, empowering your teams to take prompt action to achieve long-term performance targets. By setting multiple alarms with varying look-back windows, you can identify sudden error rate spikes and gradual shifts that could affect your error budget.
Burn rates are available in all regions where Application Signals is generally available – 28 commercial AWS Regions except CA West (Calgary) and Asia Pacific (Malaysia) regions. For pricing, see Amazon CloudWatch pricing. See SLO documentation to learn more, or refer to the user guide and AWS One Observability Workshop to get started with Application Signals.
AWS is excited to announce resource control policies (RCPs) in AWS Organizations to help you centrally establish a data perimeter across your AWS environment. With RCPs, you can centrally restrict external access to your AWS resources at scale. At launch, RCPs apply to resources of the following AWS services: Amazon Simple Storage Service (Amazon S3), AWS Security Token Service, AWS Key Management Service, Amazon Simple Queue Service, and AWS Secrets Manager.
RCPs are a type of organization policy that can be used to centrally create and enforce preventative controls on AWS resources in your organization. Using RCPs, you can centrally set the maximum available permissions to your AWS resources as you scale your workloads on AWS. For example, an RCP can help enforce the requirement that “no principal outside my organization can access Amazon S3 buckets in my organization,” regardless of the permissions granted through individual bucket policies. RCPs complement service control policies (SCPs), an existing type of organization policy. While SCPs offer central control over the maximum permissions for IAM roles and users in your organization, RCPs offer central control over the maximum permissions on AWS resources in your organization.
Customers that use AWS IAM Access Analyzer to identify external access can review the impact of RCPs on their resource permissions. For an updated list of AWS services that support RCPs, refer to the list of services supporting RCPs. RCPs are available in all AWS commercial Regions. To learn more, visit the RCPs documentation.