❌

Normal view

Received — 11 May 2026 ⏭ Blogs

Working in London at the World’s Largest Intelligence Company

✇Recorded Future
8 May 2026 at 02:00

Intro

There’s a certain energy you can only find at Recorded Future. Take that energy and bring it to London’s “Silicon Roundabout” and you get the perfect spot for Futurists to build and innovate.

Recorded Future's office @ The Bower on Old Street. Source: https://www.theboweroldst.com/

Across the globe, Recorded Future is 1000+ employees working towards the same mission: Securing Our World With Intelligence.

Our London office – one of our most storied hubs – hosts a range of departments supporting both local, regional, and global operations. The office brings together 100+ cross-functional professionals from People & Talent Acquisition, Finance, Sales, Marketing, Global Services, Research, and more!

Looking back: From the Attic to The Bower

Our story in London didn’t start in the high-rise, but in a converted attic with just a handful of people and a big mission.

When I first joined, we were in the attic of a 3-story building.It was full of great people and energy; the immediate feeling I got was that everyone was building something great together.”

Joe Rooke

Director Risk Insights, Insikt Group

This passion for building something great fueled incredible growth. Sam Pullen, Director of Intelligence Services, remembers when the entire EMEA team was just about 20 people. Since 2018, we’ve gone from service a few dozen customers in the region to ~700 now.

On the left: First Recorded Future office in London. On the right: Recorded Future's newest office

On the left: First Recorded Future office in London. On the right: Recorded Future's newest office

Inside the Office

This modern high-rise building’s open-plan layout offers quite a few collaboration spaces across our office, where the team likes to have small team meetings, breaks, or even lunch.

Like all Recorded Future offices, our meeting rooms follow a unique naming convention. While Boston uses countries, and Sweden volcanoes - London chose islands. Rumors say we picked islands following a 95-day rain streak – we can neither confirm nor deny. So, in our London office, you’ll find Futurists collaborating in rooms like Bora Bora, Crete, and even San Andres.

Our Culture

What truly defines our London office is the sense of camaraderie – whether that’s competing in a friendly team padel game, testing your dartboard skills, or truly memorable summer & end of year celebrations.

The culture at the London office has always been welcoming and inclusive. The BDRs are the soul of the office, and you can always rely on them for a good conversation over a cup of tea.
Sam Pullen

Whether over summer picnics and pedalos in Hyde Park years, playing 5-a-side football in the pouring rain, or at the most recent Christmas party at the Savoy - our Futurists celebrate wins together.

Friendly Team Padel Game at Canary Wharf

Onwards & Upwards: Why Recorded Future

We asked Sam and Joe what has been the highlight of their long tenure at Recorded Future: the opportunity to build. For Sam, it has been the opportunity to build great relationships with clients over nearly a decade. For Joe, it has been the opportunity to build new solutions and new ways to work towards our mission.

The company offers opportunities to builders. If you are willing to take the initiative to make something better, you are not stopped. That is rare.

Joe Rooke

Director Risk Insights, Insikt Group

Ready for your next move? Join the team!

A Complete History of Cybersecurity: From Early Viruses to AI-Powered Threats

✇Recorded Future
8 May 2026 at 02:00

Cybersecurity is a cornerstone of our modern world, but its roots stretch back long before the internet. Far from a recent phenomenon, the field began in university labs and evolved through decades of innovation and conflict. For professionals and everyday users alike, tracing this history reveals why today's defenses exist and why vigilance remains our most critical tool.

The 1940s: Theoretical Seeds and Massive Machines

Long before the first hack, pioneers were already contemplating the risks of digital intelligence. In 1945, the Electronic Numerical Integrator and Computer (ENIAC) - the first general-purpose electronic computer - showcased the power of computing, though it was a room-sized giant reserved for military use. While the idea of a "cybercriminal" was still science fiction, the theoretical groundwork for future threats was being laid.

Mathematician John von Neumann began developing his "Theory of Self-Reproducing Automata" during this era. He proposed that a machine-based organism could replicate itself across systems - the conceptual birth of the computer virus.

Key Characteristics of This Era:

  • Physical Isolation: Security meant locking the door to a room-sized machine.
  • Government Monopoly: Computers were exclusive to the military and the academic elite.
  • Conceptual Threats: Risks were purely mathematical theories rather than practical realities.
  • The Virus Blueprint: The foundational logic for self-replicating code was established.

By understanding these early foundations, we can appreciate how a field born in the realm of theory has become the frontline of global stability.

The 1950s: Mainframes, Physical Security, and Phone Phreaking

Governments, universities, and major businesses started using large, centralized machines known as mainframes. As these computers grew more powerful, the definition of "security" still remained grounded in the physical world. During this era, data protection simply meant controlling access to the room where the hardware sat. However, a new kind of technical subculture was beginning to emerge on the fringes of the telecommunications industry.

The 1950s saw the rise of phone phreaking, where enthusiasts exploited telephone signaling frequencies to make unauthorized long-distance calls. While not yet digital hacking, this movement introduced the concept of manipulating infrastructure for unintended purposes. This culture of curiosity and boundary-pushing would eventually produce industry titans; notably, both Steve Jobs and Steve Wozniak experimented with phreaking technology before the birth of Apple.

Key Characteristics of This Era:

  • Physical Perimeter: Security was defined by locks and restricted personnel access.
  • Phone Phreaking: The first widespread exploitation of a technological network.
  • Nascent Authentication: Password-based systems began to appear in informal, non-standardized forms.
  • Fragmented Protocols: Without a connected internet, every institution developed its own isolated security rules.

These early exploits proved that even the most robust physical defenses could be bypassed by those who understood the hidden language of the systems within.

The 1960s: The First Hackers and Growing Vulnerabilities

While known primarily for its social shifts, the 1960s also marked the birth of "hacking" as a technical practice. As computers became more prevalent in universities and large institutions, a new generation of users began exploring the limits of these systems. This era shifted the focus from purely physical security to the inherent vulnerabilities within the software itself.

In 1967, IBM invited students to test a new system, only to be surprised that their probing caused system crashes and revealed weaknesses. This informal "penetration test" proved that any system accessible to users was inherently open to exploitation. It was a wake-up call that sparked the transition of cybersecurity from a passive state to an active, intellectual discipline.

Key Characteristics of This Era:

  • Intentional Probing: The birth of deliberate vulnerability testing and "white hat" exploration.
  • Curiosity-Driven Hacking: Hacking emerged as a way to explore system boundaries, generally motivated by academic interest rather than malice.
  • Access vs. Security: Institutions realized that providing user access created inevitable security risks.
  • Beyond the Lock: The realization that cybersecurity required ongoing digital strategy, not just physical barriers.

This decade transformed the computer from a mysterious black box into a challenge to be solved, proving that human ingenuity would always be the greatest threat - and defense - to any system.

The 1970s: Networking and the First "Worm"

The 1970s transformed cybersecurity from a localized concern into a networked reality. The launch of ARPANET, the precursor to the modern internet, enabled researchers to share resources across distances but also opened a doorway for autonomous software to travel between systems.

In 1971, this potential was realized with Creeper, the world's first self-replicating network program. While harmless, its ability to move across the network and display messages was a revolutionary proof of concept. In response, programmer Ray Tomlinson created Reaper - the first antivirus program - specifically designed to hunt and delete Creeper. This decade also saw the rise of Kevin Mitnick, whose exploits in the 1980s showed that psychological manipulation, or social engineering, could bypass even the strongest technical barriers.

Key Characteristics of This Era:

  • Network Connectivity: ARPANET's birth created the first interconnected digital landscape.
  • The First Worm: Creeper demonstrated that programs could self-propagate autonomously.
  • The First Antivirus: Reaper established the "detect and delete" model of digital defense.
  • Social Engineering: Early hacks highlighted that human error is often the weakest link in the security chain.

This era proved that once computers started talking to each other, the "locked door" was no longer enough to keep an intruder out.

The 1980s: Personal Computers and the Birth of an Industry

The 1980s shifted computing from sterile labs to homes and offices. This explosion of connectivity via modems and floppy disks turned theoretical threats into a global reality, giving rise to the first commercial antivirus software and formal incident response teams like CERT.

Key Characteristics of This Era:

  • Wild Malware: Viruses like Elk Cloner and the Brain Virus moved beyond labs to infect personal computers worldwide.
  • The Morris Worm (1988): The first major network-wide disruption, leading to the first conviction under the Computer Fraud and Abuse Act (Robert Tappan Morris).
  • Cyber Espionage: Marcus Hess's breach of military systems for Soviet intelligence proved that digital networks had massive geopolitical stakes.
  • Ransomware Roots: The AIDS Trojan introduced the world to the concept of holding digital files hostage for payment.

The 1980s proved that as computers became personal, the threats against them became universal.

The 1990s: The Public Internet and Exploding Threats

As the World Wide Web went mainstream, the attack surface grew exponentially. This was the era of the "Macro Virus," where malicious code hid in everyday documents, and the dominance of Windows made it a universal target for hackers.

Key Characteristics of This Era:

  • Mass-Mailers: The Melissa virus demonstrated how email could be weaponized to clog global servers in hours.
  • The Encryption Standard: Netscape's SSL (1995) laid the foundation for secure online commerce and HTTPS.
  • Network Fortification: Firewalls became standard equipment as businesses scrambled to block external intrusions.
  • Legal Frameworks: Organizations like the EFF began fighting for digital privacy and standardized cybercrime laws.

This decade transformed cybersecurity services from a technical niche into a vital pillar of global commerce and law.

The 2000s: Professionalized Crime and Mature Defenses

The 2000s saw cybercrime scale into a high-profit industry. High-speed broadband and the rise of e-commerce meant that a single breach could compromise tens of millions of records, forcing the industry to develop more sophisticated authentication and monitoring tools.

Key Characteristics of This Era:

  • Massive DDoS Attacks: "Mafiaboy" proved that even giants like Amazon and eBay could be paralyzed by flooded traffic.
  • Social Engineering at Scale: The ILOVEYOU virus infected millions by exploiting human curiosity and trust.
  • Data Breach Epidemics: The TJX breach accelerated the adoption of strict data security standards like PCI DSS.
  • Encrypted Ransomware: In 2006, ransomware began using RSA encryption, making it nearly impossible to recover files without a key.

As attacks became more lucrative, the defensive industry responded with the first generation of modern security standards and behavioral analysis.

The 2010s: Nation-States and Digital Weapons

The 2010s shifted the focus from criminal profit to national security. Cybersecurity became a theater of war, with governments deploying digital weapons to destroy physical infrastructure and influence global politics.

Key Characteristics of This Era:

  • The Stuxnet Worm: The first acknowledged cyberweapon designed to cause physical destruction to industrial equipment.
  • The Snowden Leaks: Exposed the massive scale of global surveillance, sparking a decade-long debate on privacy.
  • Automation and AI: Machine learning began appearing on both sides - defenders used it for detection, while attackers used it to find flaws.
  • Global Ransomware: WannaCry and NotPetya showed how automated exploits could cripple hospitals and shipping lines across 150 countries.

By the end of the decade, it was clear that a line of code could be just as impactful as a physical weapon.

The 2020s: AI Threats and Modern Threat Intelligence

Today, the line between the physical and digital worlds has vanished. With remote work and cloud-native businesses, security is now a proactive game of "Threat Intelligence", which involves predicting and neutralizing an adversary's move before they even make it.

Key Characteristics of This Era:

  • Targeting Infrastructure: Attacks on power grids and water systems have raised the stakes from financial loss to public safety.
  • AI-Powered Attacks: Adversaries use AI to create deepfakes and hyper-personalized phishing at speeds humans can't match.
  • Predictive Defense: Modern strategy relies on Threat Intelligence, using AI to analyze patterns and stop attacks in their tracks.
  • Cloud & Remote Security: The shift away from traditional offices has forced a move toward "Zero Trust" security models.

The ongoing battle between human ingenuity and artificial intelligence now defines the frontlines of our digital existence.

The Different Types of Payment Fraud and How to Prevent Them

✇Recorded Future
8 May 2026 at 02:00

Payment fraud is growing in scale and sophistication, affecting businesses across every industry, and as digital payments expand, so do the opportunities for bad actors to exploit vulnerabilities. Understanding how fraud works and how to prevent it is essential for protecting revenue, maintaining trust, and staying resilient in an increasingly complex threat landscape.

What Is Payment Fraud?

Payment fraud refers to the theft of money from businesses or individuals through unauthorized transactions or deceptive purchases. Fraudsters may act using their own accounts or by gaining unauthorized access to someone else's account.

While payment fraud can happen in person, online transactions are especially vulnerable. According to Juniper Research, global business losses from online payment fraud are projected to surpass $362 billion between 2023 and 2028. A business's fraud risk depends largely on its industry, the sensitivity of the data it handles, and the payment methods it accepts. The more ways customers can interact with accounts and complete purchases, the more entry points exist for bad actors to exploit.

Different Types of Payment Fraud

Fraudsters use many tactics, and below we list 14 of the most common. Given the large number of threats, businesses must prepare their teams to recognize a variety of warning signs. Strong internal communication policies, clear escalation procedures, and knowledge of the landscape are foundational to any fraud prevention strategy.

1. Phishing

Phishing is a social engineering tactic in which criminals attempt to trick people into revealing sensitive information such as account credentials or payment details. These attacks often come in the form of malicious links sent via email or text, but they can also occur over the phone. Attackers may pose as trusted figures - a friend, a bank representative, or a government official - to manipulate victims.

Prevention tips:

  • Let customers know exactly how your business will contact them, including phone numbers and email addresses.
  • Be transparent about what information your staff will and will not ask for.
  • Alert customers to any known phishing attempts targeting your brand.
  • Train employees on information security protocols and how to identify suspicious communications.

2. Credit and Debit Card Fraud

This type of fraud involves obtaining card information - either physically or digitally - and using it to make unauthorized purchases. Cards may be stolen directly, or details may be harvested through card skimming devices installed on ATMs or point-of-sale terminals. Attackers also acquire card data through phishing schemes or by purchasing stolen credentials on the dark web.

Prevention tips:

  • Restrict POS system access to authorized personnel and regularly inspect payment hardware for tampering.
  • Build secure, encrypted payment pages that comply with data protection standards.
  • Offer customers multiple notification options for purchases and account activity.
  • Warn customers never to share account or confirmation numbers with unverified sources.

3. Wire Transfer Fraud

In wire transfer fraud, criminals convince victims to send money directly to them. Because wire transfers are difficult to reverse, they are a preferred method among scammers. Attackers commonly impersonate someone the victim trusts - a family member, a company executive, or a business vendor. The use of a convincing back-story is often referred to as "social engineering." For example, an attacker may text employees pretending to be their CEO, claiming an emergency and requesting an urgent fund transfer.

Prevention tips:

  • Train employees to spot the signs of social engineering and impersonation.
  • Establish official communication channels and avoid conducting financial business over easily spoofed channels like text messages.
  • Report and share all phishing attempts with the entire team.

4. Check Fraud

Check fraud involves using counterfeit or altered checks to make payments or writing checks from accounts that lack sufficient funds. Fake checks may be digitally printed or modified versions of real checks. In some cases, the check is genuine but drawn from a closed account.

Prevention tips:

  • Implement software that verifies the authenticity of checks.
  • Train staff to recognize the visual and physical signs of fraudulent checks.

5. Chargeback and Refund Fraud

Also known as "friendly fraud," chargeback fraud occurs when a customer makes a legitimate purchase and then falsely claims a refund - either directly from the business or through their credit card company. This type of fraud is particularly tricky because it can be hard to distinguish from genuine disputes, especially when delivery or service quality is involved.

Prevention tips:

  • Validate customer information, including billing addresses and card security codes.
  • Use payment platforms that include fraud protection and dispute automation tools.
  • Respond to refund and chargeback requests quickly.
  • Minimize legitimate chargebacks by fulfilling orders accurately and on time.

6. Identity Theft

Identity theft happens when a criminal obtains someone's personal information and uses it for financial gain or to make purchases in someone else's name. For businesses, a common result is having to deal with chargebacks after customers discover fraudulent charges on their accounts. Although the primary victim is the customer, businesses have a responsibility to prevent data breaches that expose customer information in the first place.

Prevention tips:

  • Train employees to recognize phishing and follow secure information handling practices.
  • Ensure your payment systems comply with PCI DSS (Payment Card Industry Data Security Standard) requirements.

7. Account Takeover Fraud

Account takeover (ATO) fraud typically follows identity theft. Once attackers obtain a user's credentials, they change the password and contact information to lock the real owner out. From there, they may use the account for fraudulent purchases or sell it to other bad actors.

Prevention tips:

  • Enforce strong password requirements for all accounts.
  • Require two-factor authentication (2FA) and send confirmation alerts for any significant account changes.
  • Notify customers of purchases and account modifications in real time.

8. New Account Fraud

New account fraud (NAF) occurs when someone uses stolen or fabricated identities to open new lines of credit or accounts. These fraudulent accounts can then be used to make purchases or commit further fraud down the line.

Prevention tips:

  • Require multi-factor authentication (MFA) - not just email verification - during account creation.
  • Verify address details and card security information during transactions.
  • Use fraud protection tools that leverage machine learning to detect unusual account creation patterns.

9. Gift Card Fraud

Gift card fraud is a social engineering scam where criminals pressure victims into purchasing gift cards and handing over the card numbers. Once the numbers are given, the funds are essentially unrecoverable, making this a popular method among scammers.

Prevention tips:

  • Display warnings about gift card scams during the checkout process.
  • Remind customers never to share gift card numbers with people they don't personally know.
  • Educate in-store staff to recognize signs of gift card fraud and when to escalate the situation.

10. Merchant Identity Theft

In merchant identity theft, attackers impersonate legitimate businesses or vendors to defraud customers or partner organizations. They may use phishing to extract employee credentials and gain access to business systems, or they may pose as a trusted vendor and redirect payments to themselves.

Prevention tips:

  • Train staff to identify phishing attempts and follow secure communication practices.
  • Establish verification procedures when communicating with vendors and business partners.
  • Report phishing attempts to employees and partners promptly.

11. Pagejacking and Domain Spoofing

Pagejacking involves cloning an existing webpage and redirecting users to the fake version to steal login credentials or payment information. Domain spoofing follows a similar concept - attackers build an identical-looking site under a slightly different URL. Users are typically directed to these fraudulent pages through malicious emails or texts.

Prevention tips:

  • Run plagiarism detection tools to identify duplicate versions of your pages online.
  • Pay attention to unusual customer service complaints that might signal a spoofed site.
  • Submit takedown requests to search engines if you discover a duplicate site, and notify affected customers.

12. Mobile Payment Fraud

As mobile payments become more prevalent, they've also become a target for fraud. Attackers can exploit mobile apps through malware installation, stolen app credentials, or interception of 2FA codes. For example, a scammer may call a customer pretending to represent a business and ask them to read back a verification code - which is actually a 2FA code the attacker has triggered on the victim's account.

Prevention tips:

  • Authenticate customers over the phone carefully to reduce the risk of impersonation-based fraud.
  • Monitor for unusual spending or refund activity in mobile transactions.
  • Educate customers about the risks of clicking on unknown links, QR codes, or visiting unfamiliar websites.

13. Push Payment Fraud

Unlike unauthorized transaction fraud, push payment fraud involves tricking the victim into willingly sending money to a fraudster. This can take many forms, including phishing, blackmail, or deceptive scenarios like fake emergencies. The key distinction is that the victim actively initiates the transfer.

Prevention tips:

  • Clearly communicate to customers what your staff can and cannot ask them to do or pay.
  • Make it easy for customers to report anyone impersonating your business.
  • Issue proactive alerts about ongoing scam attempts tied to your brand.

14. ACH Payment Fraud

ACH (Automated Clearing House) payment fraud involves criminals gaining unauthorized access to a victim's bank account details and using them to initiate fraudulent transfers. For businesses, this risk can come from both outside attackers and malicious insiders.

Prevention tips:

  • Strictly limit and monitor employee access to business bank accounts.
  • Educate all staff with account access about phishing tactics and establish firm security policies.

Which Businesses Have the Highest Fraud Risk?

Not all businesses face the same level of exposure. Fraud risk is generally highest in sectors that process online payments, handle sensitive personal data, or still accept paper checks.

E-Commerce Businesses

E-Commerce businesses are particularly vulnerable. Online retail involves accepting payments from a wide range of locations, often with multiple payment methods. Features like peer-to-peer payment integrations or international checkout add more potential points of failure. The more accounts and payment methods a customer has linked, the more attractive a target they become for data breaches.

Healthcare, Banking, and Data-Sensitive Industries

These sectors are at elevated risk because of the high value of the information they store. A breach in these sectors doesn't just expose financial data - it can compromise identity information used to commit fraud across many platforms simultaneously.

Businesses Still Accepting Checks

These kinds of businesses face unique challenges. As check usage declines, employees may become less experienced at identifying fakes, which makes training and verification systems all the more important. According to the Association for Financial Professionals, check fraud remains one of the most common forms of payment fraud.

How to Mitigate Risk

A variety of tools and strategies are available to help businesses identify and reduce fraud exposure. Conducting a security risk assessment is a strong starting point, helping teams understand which vulnerabilities are most critical and where to prioritize investment.

From there, organizations should focus on establishing a solid operational and security foundation before layering in more advanced fraud detection capabilities.

Foundational Controls

These measures create a baseline level of protection by securing systems, safeguarding data, and reducing avoidable losses:

  • Strong network and password security: Establish internal policies governing account access, password requirements, and physical access to devices and systems.
  • Network tokenization: Ensure payment systems encrypt and tokenize customer data to protect sensitive information.
  • PCI standards compliance: Build payment workflows that meet Payment Card Industry (PCI) standards to safeguard cardholder data.
  • 3D Secure (3DS) authentication: Use the latest 3DS protocols to validate transactions and verify user identity before completing purchases.
  • Chargeback protection: Work with your payment processor to implement tools that help minimize financial losses from disputed transactions.

Once these core protections are in place, businesses can enhance their fraud prevention strategies with more dynamic, data-driven approaches.

Advanced Detection & Optimization

These techniques improve visibility, adaptability, and long-term resilience against evolving fraud tactics:

  • Fraud KPI tracking: Monitor key metrics such as dispute rates, authorization rates, and approval/decline ratios to identify trends and respond proactively.
  • Rules-based systems: Implement rule-based detection as a reliable operational backbone. While rules require ongoing maintenance, they are especially useful in early stages and can be refined over time.
  • Machine learning algorithms: Leverage ML-powered systems to analyze large, complex datasets and uncover patterns that are difficult to detect manually. These models continuously improve as they adapt to new fraud behaviors.

Staying Ahead of Payment Fraud

Payment fraud is an ongoing challenge, but a proactive, layered approach can significantly reduce risk. By combining strong foundational controls with data-driven detection and continuous monitoring, businesses can stay ahead of evolving threats.

Ultimately, effective fraud prevention requires regular review, employee awareness, and a commitment to adapting as tactics change.

Additional Resources

Digital Citizenship Glossary: Key Terms Every Internet User Should Know

✇Recorded Future
8 May 2026 at 02:00

The internet is basically a giant digital city, and you need to be just as streetwise here as outside your front door. Most people go online every day - scrolling through TikTok, finishing a research paper, or making purchases - but they don't always know the "rules of the road" or the vocabulary that tech experts use to describe our digital lives. Here's a breakdown of essential digital citizenship terms to help you navigate the web and mobile apps like a pro:

Authority - Authority refers to how trustworthy a source is based on who created it. If information comes from a qualified expert or a well-known organization, it's more likely to be reliable than something posted by an unknown user.

Bystander - A bystander is someone who sees harmful behavior online, like cyberbullying, but chooses not to get involved or take action.

Cookies - Cookies are small files that websites store on your device to remember information about you, like login details or browsing habits. They make websites easier to use, but they also allow service providers to track your activity.

Cyberbullying - Cyberbullying is when someone uses digital platforms to repeatedly harass, threaten, or embarrass another person. Unlike trolling, it usually targets a specific individual.

Data Breach - A data breach happens when private or sensitive information is accessed or stolen without permission, often from companies or large platforms.

Digital Citizen - A digital citizen is anyone who uses technology to interact with others online. Being a good digital citizen means using the internet responsibly, respectfully, and safely.

Digital Footprint - A digital footprint is the trail of information you leave behind online through posts, searches, and interactions. The more you share, the greater your exposure to privacy issues or misuse of personal information. Also, once something is online, it can be very difficult to remove.

Digital Identity Theft - Digital identity theft occurs when someone steals your personal information, like passwords or account details, to pretend to be you or access your accounts.

Digital Divide - The digital divide refers to the gap between people who have access to modern technology and the internet and those who do not.

Encryption - Encryption is a method of protecting data by turning it into a coded format that only authorized users can read. It helps keep sensitive information secure.

Firewall - A firewall is a security system that monitors and controls incoming and outgoing network traffic, blocking anything that looks suspicious or harmful.

Imaginary Audience - The imaginary audience is the feeling that people are constantly watching and judging you. Social media can make this feeling stronger by showing likes, views, and comments.

Invisible Audience - The invisible audience refers to the unknown people who may see your online content, including strangers, future employers, or others outside your immediate circle. It pays to assess your security blind spots because you may not realize who is viewing your posts.

Malware - Malware is any type of harmful software designed to damage devices, steal information, or disrupt normal operations. It is often installed as part of a package or application that otherwise appears innocent.

Password Hygiene - Password hygiene refers to the practice of creating strong, unique passwords and keeping them secure instead of reusing the same one across multiple accounts.

Phishing - Phishing is a scam where attackers pretend to be a trusted source to trick you into giving away personal information, often through fake emails, texts, or websites.

Public Wi-Fi Risk - Public Wi-Fi risk refers to the potential dangers of using unsecured networks, where hackers may be able to intercept your data.

Reliability - Reliability refers to whether information is accurate and dependable. Just because something looks professional online doesn't mean it's true.

Social Comparison - Social comparison is the act of comparing your life to what you see online. Since people often share only their best moments, it can create unrealistic expectations.

Targeted Advertising - Targeted advertising uses your online behavior, location, and personal data to show ads that are specifically tailored to you.

Trolling - Trolling is when someone posts deliberately annoying or provocative content online to get attention or start arguments.

Two-Factor Authentication (2FA) - Two-factor authentication is a security feature that requires a second form of verification, like a code sent to your phone, in addition to your password.

Upstander - An upstander is someone who takes action when they see harmful behavior online, such as supporting the victim or reporting the issue.

VPN (Virtual Private Network) - A VPN is a tool that creates a secure, encrypted connection to the internet, helping protect your data and privacy, especially on public networks.

Additional Resources to Learn More

ICYMI: April 2026 @AWS Security

✇AWS Security Blog
By: Rodolfo Brenes
7 May 2026 at 20:52

Read all about the latest AWS security features, compliance updates, and hands-on resources in our new, monthly digest posts. You’ll find expert blog posts, new service capabilities, code samples, and workshops.

AWS Security Blog posts

This month’s AWS Security Blog posts covered AI security, identity and access management, threat intelligence, data protection, and multicloud operations. Whether you’re securing agentic AI systems, upgrading to post-quantum cryptography, or streamlining forensic collection, these posts offer practical guidance across the security landscape.

Identity

    Access control with IAM Identity Center session tags
    Author: Rashmi Iyer | Published: April 28, 2026
    Learn to combine AWS IAM Identity Center permission sets with session tags from Microsoft Entra ID to implement fine-grained attribute-based access control (ABAC) across multiple AWS accounts.

    Can I do that with policy? Understanding the AWS Service Authorization Reference
    Authors: Anshu Bathla, Prafful Gupta | Published: April 27, 2026
    Learn to use the AWS Service Authorization Reference to determine what’s achievable with IAM policies, recognize scenarios needing alternative solutions, and build more effective security controls.

    AI Security

    Secure AI agent access patterns to AWS resources using Model Context Protocol
    Author: Riggs Goodman III | Published: April 14, 2026
    Learn to secure AI agent access to AWS resources via MCP using three principles: least privilege, organizational role governance, and differentiating AI-driven from human-initiated actions.

    Four security principles for agentic AI systems
    Authors: Mark Ryland, Riggs Goodman III, Todd MacDermid | Published: April 2, 2026
    Learn four security principles from AWS’s NIST response for securing agentic AI: secure development lifecycle, traditional controls, deterministic external enforcement, and earned autonomy through evaluation.

    Designing trust and safety into Amazon Bedrock powered applications
    Author: Victor Lungu | Published: April 29, 2026
    Learn to integrate responsible AI concepts into Amazon Bedrock applications, including abuse detection, Amazon CloudWatch monitoring, Bedrock Guardrails configuration, and the abuse response process.

    Building AI defenses at scale: before the threats emerge
    Author: Amy Herzog | Published: April 7, 2026
    AWS CISO announces Project Glasswing with Anthropic, introducing Claude Mythos Preview for vulnerability research, plus the general availability of AWS Security Agent for autonomous penetration testing.

    Governance and compliance

      Shift-Left Tag Compliance using AWS Organizations and Terraform
      Authors: Welly Siauw, Sourav Kundu, Manu Chandrasekhar | Published: April 27, 2026
      Learn to validate tag compliance during development using AWS Organizations tag policies, a reusable Terraform tagging module, and a test-driven approach that dynamically validates against live organizational policies.

      Detection and incident response

      What the March 2026 Threat Technique Catalog update means for your AWS environment
      Authors: Shannon Brazil, Cydney Stude | Published: April 28, 2026
      The AWS CIRT’s latest Threat Technique Catalog update covers Amazon Cognito refresh token abuse, AMI image deletion targeting recovery, and trust policy modifications for persistence and privilege escalation.

      A framework for securely collecting forensic artifacts into S3 buckets
      Authors: Jason Garman, Vaishnav Murthy | Published: April 8, 2026
      Learn to securely collect forensic artifacts into Amazon S3 using time-limited, least-privilege credentials with AWS STS session policies and automated AWS Step Functions workflows.

      Transform security logs into OCSF format using a configuration-driven ETL solution
      Authors: Vivek Gautam, Arpit Gupta, Ryan Gomes | Published: April 17, 2026
      Learn to transform custom security logs into OCSF format using an AWS ProServe configuration-driven ETL solution with AWS Step Functions, AWS Glue or Amazon EMR Serverless, and Amazon Security Lake integration.

      A technical walkthrough of multicloud full-stack security using AWS Security Hub Extended
      Authors: Matt Meck, Michael Fuller | Published: April 22, 2026
      Learn how AWS Security Hub Extended simplifies multicloud security procurement and operations through curated partner solutions, unified billing, and OCSF-based findings consolidation.

      Data protection

        Protecting your secrets from tomorrow’s quantum risks
        Authors: Stéphanie Mbappe, Tobias Nickl | Published: April 24, 2026
        Learn to upgrade AWS Secrets Manager clients to use hybrid post-quantum TLS with ML-KEM, protecting secrets against harvest-now-decrypt-later attacks, and verify connections via AWS CloudTrail.

        How AWS KMS and AWS Encryption SDK overcome symmetric encryption bounds
        Authors: Panos Kampanakis, Matthew Campagna, Patrick Palmer | Published: April 3, 2026
        Learn how AWS Key Management Service and the AWS Encryption SDK use derived key methods to automatically handle AES-GCM encryption limits, eliminating the need to manually track bounds or rotate keys.

        How to clone an AWS CloudHSM cluster across Regions
        Authors: Desiree Brunner, Rickard Löfström | Published: April 20, 2026
        Learn to clone an AWS CloudHSM cluster to another Region using CopyBackupToRegion, then synchronize keys—including non-exportable keys—across cloned clusters for disaster recovery.

        April Security Bulletins

        Investigations of reported security vulnerabilities affecting Amazon and AWS services, software, and products.

        AWS Samples

        This month brings 16 new AWS samples spanning identity, governance, compliance, detection and incident response, AI Security, data protection, and infrastructure security. From beginner-friendly AI agent development on Amazon Bedrock to automated Control Tower re-registration at scale, these ready-to-deploy repositories help you implement security best practices across your AWS environment.

        Identity

          Amazon Cognito OAuth2 Token Proxy with Caching
          Learn to deploy an Amazon API Gateway proxy for Cognito’s OAuth2 token endpoint with intelligent caching and AWS WAF protection, reducing M2M authentication costs by over 90%.

          Cognito API Gateway Authorization Demo
          Learn to implement user-specific data protection using Amazon Cognito, API Gateway, and an AWS Lambda authorizer that enforces JWT sub claim matching to prevent cross-user data access.

          Securely Connecting On-Premises Data Systems to Amazon Redshift with IAM Roles Anywhere
          Learn to deploy a fully private environment connecting on-premises workloads to Amazon Redshift using X.509 certificate authentication via IAM Roles Anywhere for short-lived credentials.

          AWS IAM Access Key Lifecycle Management with Human Approval
          Learn to automate organization-wide detection, disabling, and deletion of unused IAM access keys using Step Functions, IAM Access Analyzer, and a secure human-in-the-loop approval workflow.

          Secrets Manager Audit
          Learn to resolve and report who can access your AWS Secrets Manager secrets—across accounts, through Identity Center, and down to the human behind the IAM role—in a single command.

          Governance

          Control Tower Organization Re-Registration Automation
          Learn to automate AWS Control Tower OU re-registration and account updates at scale using lifecycle events, Amazon EventBridge, and AWS Lambda to resolve mixed governance after landing zone changes.

          Sample Agent Skills for Builders
          A curated collection of installable agent skills that extend AI coding agents (Claude Code, Cursor, Copilot) with production-ready AWS, CDK, security scanning, and engineering workflows.

          How to Stop AI Agent Hallucinations: 5 Techniques + Production on Amazon Bedrock AgentCore
          Learn to detect, prevent, and self-correct AI agent hallucinations using Graph-RAG, semantic tool selection, multi-agent validation, neurosymbolic guardrails, and agent steering with Strands Agents.

          Compliance

          Compliance Lens
          Learn to deploy a serverless solution that analyzes AWS Config snapshots across an AWS Organization, compares them against conformance pack rule sets, and visualizes compliance posture via Amazon QuickSight dashboards.

          AWS Security Agent Terraform Configuration
          Learn to provision AWS Security Agent resources using the AWSCC Terraform provider, automating agent space creation, IAM roles, target domain registration, and penetration test setup.

          Detection and incident response

          AWS Security Agent Demo Suite
          Learn to use AWS Security Agent across three scenarios: automated design reviews, AI-generated infrastructure code review via GitHub, and penetration testing against intentionally vulnerable applications.

          Agentic SOC Workshop — CDK Infrastructure
          Learn to build an AI-powered Security Operations Center agent that investigates Amazon GuardDuty findings, queries CloudTrail logs, and takes automated containment actions using Amazon Bedrock AgentCore.

          Data Protection

          Implementing Kerberos Authentication for Apache Spark Jobs on Amazon EMR on EKS to Access a Kerberos-Enabled Hive Metastore
          Learn to configure Kerberos authentication for Spark jobs on Amazon EMR on Amazon Elastic Kubernetes Service, connecting to a Kerberos-enabled Hive Metastore using Microsoft Active Directory as the KDC.

          AWS Nitro Enclaves with Kubernetes – Hello World Example
          Learn to deploy a Hello World application inside an AWS Nitro Enclave on Amazon EKS, covering cluster creation, device plugin setup, and enclave image building.

          Infrastructure security

            Multi-Tenant OpenClaw on Firecracker
            Learn to deploy isolated, multi-tenant OpenClaw AI agents on AWS using Firecracker microVMs with per-tenant kernel/network isolation, auto-scaling, backup/restore, and a web management console.

            AI Security

            Amazon Bedrock for Beginners – From First Prompt to AI Agent
            Learn to build AI applications on Amazon Bedrock, from basic API calls to a full agent with RAG, guardrails, tool use, and the Strands Agents SDK.

            Conclusion

            April 2026 reinforces that securing AI workloads now requires the same rigor applied to traditional infrastructure. The posts and samples in this edition provide concrete patterns for enforcing least privilege on agentic systems, automating governance at organizational scale, and preparing cryptographic implementations for post-quantum requirements. The security bulletins address vulnerabilities across compute, networking, and developer tooling, reinforcing the need to apply patches consistently. Each resource includes deployment steps or runnable code so you can validate the approach in your own environment before adopting it. Subscribe to the AWS Security Blog RSS feed to receive updates as they publish, and revisit this digest monthly for a consolidated view of what changed and what to act on.

            If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

            Rodolfo Brenes

            Rodolfo Brenes

            Rodolfo is a Principal Solutions Architect focused on Cloud Governance and Compliance. With over 18 years of experience, he currently leads a technical field community in AWS helping customers scale and improve their security and governance frameworks. Besides work, Rodolfo enjoys video games, playing with his four cats, and won’t say no to a good outdoor adventure.

            Anna Brinkmann

            Anna Brinkmann

            Anna is a project manager and editor with more than 18 years of experience with content management in the technology space. For the past 6 years, she has run the AWS Security Blog. In her free time, Anna gardens, spends time with family and friends, and learns new slang words from her kids.

            AWS achieves SNI 27017, SNI 27018, and SNI 9001 certifications for the AWS Asia Pacific (Jakarta) Region

            ✇AWS Security Blog
            By: Ignatius Lee
            7 May 2026 at 18:03

            Amazon Web Services (AWS) achieved three Standar Nasional Indonesia (SNI) certifications for the AWS Asia Pacific (Jakarta) Region: SNI ISO/IEC 27017:2015, SNI ISO/IEC 27018:2019, and SNI ISO 9001:2015. SNI represents Indonesia’s national standards framework, comprising standards that are broadly applicable across industries within the country. These certifications further demonstrate that AWS services meet nationally recognized requirements.

            The certifications were assessed by an independent third-party auditor accredited by the Komite Akreditasi Nasional (KAN), Indonesia’s National Accreditation Committee, in accordance with applicable local regulatory requirements, helping customers rely on trusted, locally recognized validation for their compliance needs.

            All three certifications are based on international ISO standards adapted for Indonesia:

            • SNI 27017 adds cloud-specific security controls that complement ISO/IEC 27001, helping you run workloads securely while reducing security assessment overhead.
            • SNI 27018 focuses on protecting personally identifiable information (PII) in public clouds. This certification confirms that AWS handles your data according to international privacy standards.
            • SNI 9001 establishes quality management systems that ensure consistent service delivery and continuous improvement across AWS operations.

            Together with the existing SNI 27001 certification achieved in 2023, AWS is now the first cloud service provider (CSP) to hold all four SNI certifications—SNI 27001, SNI 27017, SNI 27018, and SNI 9001—demonstrating comprehensive alignment with Indonesia’s national standards for information security, cloud security, privacy, and quality management, and helping customers address a broad range of regulatory and risk management requirements.

            Customers can access the corresponding certificates through AWS Artifact, a self-service portal that provides on-demand access to AWS compliance documentation. For a full list of AWS services covered under the SNI certification, see the Services in Scope compliance page

            AWS continues to expand the scope of its compliance programs to help customers meet their architectural, business, and regulatory requirements. For more information regarding these certifications, contact your AWS Accounts team.

            Ignatius Lee

            Ignatius Lee

            Ignatius is a Security Assurance professional based in Singapore, responsible for third-party audits in Indonesia. He joined Security Assurance in early 2025 and has delivered and contributed to key audit programs across Hong Kong, Singapore, and Australia.

            New compliance guide available: ISO/IEC 42001:2023 on AWS

            ✇AWS Security Blog
            By: Abdul Javid
            6 May 2026 at 21:39

            We have released our latest compliance guide, ISO/IEC 42001:2023 on AWS, which provides practical guidance for organizations designing and operating an Artificial Intelligence Management System (AIMS) using AWS services.

            As organizations deploy AI and generative AI workloads in the cloud, aligning with globally recognized standards such as ISO/IEC 42001:2023 becomes an important step toward strengthening AI governance, risk management, and responsible AI practices. This guide helps cloud architects, AI/ML engineers, security teams, compliance leaders, and DevOps practitioners understand how to implement and operate ISO 42001-aligned controls using AWS services while applying the AWS Shared Responsibility Model for AI.

            The guide explains how organizations can integrate AWS services into their AIMS to support the requirements defined in ISO 42001:2023 clauses 4–10 and the Annex A control specific to AI systems. It also highlights how AWS AI services, security capabilities, monitoring, and automation can help customers maintain visibility over AI systems, improve operational consistency, and prepare audit-ready evidence.

            While AWS provides a secure and compliant cloud infrastructure with built-in responsible AI capabilities, customers remain responsible for defining their AIMS scope, implementing controls, and demonstrating conformity during certification audits.

            Inside the guide:

            • Overview of the ISO/IEC 42001:2023 framework, including understanding ISO 42001 and its Annexes, and how it relates to the broader ISO AI standards family
            • Guidance for integrating with AWS security architecture and applying the AWS Shared Responsibility Model for AI workloads
            • Context and scoping considerations for establishing an AIMS on AWS, including defining AI system boundaries within your environment
            • Mapping of ISO 42001:2023 clauses 4–10 to AWS services and architectural capabilities, covering organizational context, leadership, planning, support, operation, performance evaluation, and improvement
            • Implementation guidance for specific Annex A controls (A.2–A.10), including AI policies, internal organization, resources for AI systems, impact assessments, AI system life cycle management, data governance, transparency for interested parties, use of AI systems, and third-party and customer relationships
            • Recommendations for evidence collection, documentation, and audit readiness using AWS native tooling
            • Best practices for operationalizing AI compliance activities through automation and infrastructure-as-code

            Use this guide to map ISO 42001 clauses and Annex A controls to your AWS environment, automate evidence collection, and reduce the effort involved in preparing for a certification audit.

            Download: ISO/IEC 42001:2023 on AWS Compliance Guide

            For further assistance, contact AWS Security Assurance Services

            If you have feedback about this post, please submit comments in the Comments section below.

            Abdul Javid

            Abdul Javid

            Abdul is a Senior Security Assurance Consultant and a PECB ISO 42001 Lead Auditor, IAPP Certified AI Governance Professional and ISACA Advanced in AI Security Management. He draws on his extensive experience of over 25 years to guide AWS customers on compliance matters. He holds an M.S. in Computer Science from IIT Chicago and numerous certifications from IAPP, AWS, ISO, HITRUST, ISACA, CMMC, PMI, PCI DSS, and ISC2.

            Satish Uppalapati

            Satish is an Associate Assurance Consultant with AWS Security Assurance Services and has more than 8 years of experience in IT risk, governance, and regulatory assurance. He works with AWS customers to help align cloud environments with frameworks such as ISO 27001, SOC 2, and FFIEC. Satish also focuses on advancing governance for AI systems, including emerging standards such as ISO/IEC 42001.

            Amber Welch

            Amber Welch

            Amber is an AWS Security Assurance Services Senior Privacy Consultant, advising AWS customers on their AI and privacy risk management and compliance. She has an M.A. in English and ISO 42001 Lead Auditor, IAPP CIPM, and IAPP CIPP/E certifications. Amber has spoken and written extensively on AI and privacy topics, and is an AWS Privacy Reference Architecture primary author.

            Jonathan-Jenkyn

            Jonathan Jenkyn

            Jonathan (“JJ”) is a Sr Security Assurance Solution Architect with AWS Security Assurance Services. With over 30 years of experience, he is a proven security leader who delivers robust cloud security outcomes. JJ is also an active member of the AWS People with Disabilities affinity group and enjoys running, cycling, and spending time with his family.

            Muhammad Sharief

            Muhammad Sharief

            Muhammad is a Security Assurance Consultant with AWS Security Assurance Services (SAS) and a PECB-certified ISO/IEC 42001 Lead Auditor. He helps enterprise customers across AWS GovCloud (US) and commercial environments achieve and maintain compliance with FedRAMP, CMMC, ISO 27001, ISO 42001, and NIST 800-53. Muhammad works closely with customers, partners, and AWS service teams to design automated evidence collection architectures, advance AI governance, and align cloud security and compliance requirements with business objectives.

            Recorded Future Named a Leader in the 2026 Gartner® Magic Quadrant™ for Cyberthreat Intelligence Technologies. And there’s more.

            ✇Recorded Future
            6 May 2026 at 02:00

            For security professionals evaluating threat intelligence vendors, the Gartner Magic Quadrant offers an indispensable perspective. Gartner analysts’ thorough and nuanced analysis cuts through the noise, making it easier for teams to understand each platform’s approach, strengths, and considerations—and helping them determine whether a particular vendor fits their organization’s unique needs.

            That’s why we’re honored to share that Gartner has named Recorded Future a Leader in the first-ever Magic Quadrant™ for Cyberthreat Intelligence Technologies. This new report evaluated 17 vendors in the space, providing a comprehensive look at the competitive landscape.

            “In our view, being recognized as a Leader means something specific to us: we feel it reflects our ability to help our customers with the outcomes they depend on. These include stopping threats pre-attack, running intelligence autonomously at a scale no human team can match, and making every security control they own more effective," said Colin Mahony, CEO, Recorded Future. “We believe this recognition reflects both the trust our customers place in us and the strength of the outcomes we help them achieve.”

            A research methodology that prioritizes customer voice

            A Gartner Magic Quadrant is a culmination of research in a specific market, giving you a wide-angle view of the relative positions of the market’s competitors. By applying a graphical treatment and a uniform set of evaluation criteria, a Magic Quadrant helps you quickly ascertain how well technology providers are executing their stated visions and how well they are performing against Gartner’s market view.

            For Recorded Future, this meant that Gartner analysts spoke directly with our customers about their real-world experiences—the challenges they face, how they use our Platform, and the outcomes they've realized. We feel their voices shaped our position in the Magic Quadrant, just as they’ve always shaped our product offerings and roadmap.

            The new Gartner report offers a snapshot of what the analysts heard from customers. We haven’t stopped working since then and there’s much to talk about.

            There’s more… the next phase of threat intelligence

            In conversations throughout 2025, our customers gave us their thoughts about product complexity, pricing models, and the challenges of scaling intelligence across their teams. As a result of their input, we’ve fundamentally changed how they can access and make the most of Recorded Future threat intelligence.

            Here are the highlights of our continued commitment to simplicity and innovation to provide better experiences for our customers in 2026:

            1. Goodbye, modules. Hello, simplicity. Meet our four new solutions.
            Our four new solution areas cover the four major attack surfaces—an organization’s systems, brand, supply chain, and payment methods:

            • Cyber Operations—This foundational solution empowers security teams with the intelligence to monitor and prioritize threats and vulnerabilities, get in-depth malware insights, triage alerts and detect threats, and stand up an intelligence-driven defense.
            • Digital Risk Protection—Also foundational, this solution allows teams to monitor malicious sites, code repositories, and the dark web to detect brand abuse, employee credential compromise, and other threats to digital trust.
            • Third-Party Risk—This solution enables teams to continuously assess supplier security posture with real-time intelligence, accurate risk ratings, vendor action plans, and more.
            • Payment Fraud—With this solution, teams can detect and prevent card-not-present fraud with intelligence that identifies compromised payment data before it's used.

            The solutions are built on a unified intelligence foundation to provide consistency, accuracy, and alignment around shared security outcomes. And they integrate with other security solutions like CrowdStrike Falcon and Google SecOps, bringing the benefits of Recorded Future intelligence and rich context directly into common SIEM and EDR workflows.

            2. New pricing packages for less friction, more intelligence
            We’re offering the four solutions in new pricing packages designed to fit customer needs:

            • Simplicity—Customers can purchase one package instead of juggling multiple modules
            • End-to-end workflows—Packages cover full use cases, complete with the key capabilities to get the job done
            • Wider access—Higher tiers offer unlimited seats, so everyone now can be intelligence-led.

            In addition, integrations are included. Now your tools in the security stack—SIEM, SOAR, firewall, endpoint protection, ticketing system, and more—can leverage Recorded Future intelligence without integration fees or limitations.

            3. Expansion into Latin America
            The threat landscape knows no geographical borders, and neither do we. We’ve expanded Recorded Future’s operations into Latin America, giving security teams in the region better access to the expertise and support they need to mount a successful proactive defense.

            4. Autonomous Threat Operations for autonomous defense
            In February, we launched Autonomous Threat Operations to help customers move from isolated threat intelligence insights and manual workflows to automated and continuous defensive actions across the entire security ecosystem. Complete with AI-powered, 24/7 autonomous threat hunting and multi-source correlation in the Intelligence Graph®.

            As we continue to build on our vision of moving from automated to autonomous operations, we’re developing Recorded Future AI and agentic experiences to help our customers reduce alert fatigue, save time on research, and run threat hunts faster so they can detect and defend at scale.

            Explore the Gartner Magic Quadrant report today

            We’re proud to be recognized by Gartner as a Leader in Cyberthreat Intelligence Technology, and we’ll continue innovating for our customers to help them mitigate risk and stay ahead of evolving threats.

            Get the report to review Gartner analysis and see how Recorded Future fits your CTI program needs.

            ____________________________________________________________________________________________________________________________________

            Gartner, Magic Quadrant for Cyberthreat Intelligence Technologies, By Jonathan Nunez, Carlos De Sola Caraballo, Jaime Anderson, 04 May 2026.

            Gartner and Magic Quadrant are trademarks of Gartner, Inc. and/or its affiliates.

            Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.

            Threat Activity Enablers: The Backbone of Today’s Threat Landscape

            ✇Recorded Future
            6 May 2026 at 02:00
            This article introduces threat activity enablers (TAEs), the infrastructure providers and networks that underpin modern cyber threats across both criminal and state-sponsored activity. These entities sustain operations by enabling resilient, high-risk infrastructure that persists despite sanctions, takedowns, and public exposure.

            Behind every ransomware demand, botnet, or threat activity group is a server sitting in a data center. While most legitimate hosting providers evict threat actors once identified, a specific class of providers does the opposite. Recorded Future® calls these providers threat activity enablers(TAEs).

            What Is a Threat Activity Enabler?

            Figure 1: Overview of threat activity enablers’ patterns, ecosystem, and impact

            A threat activity enabler (TAE) is an individual, organization, or service provider that supports malicious cyber activity by providing infrastructure or services leveraged by threat actors. More commonly, this includes providers that lack a formal physical or virtual storefront, conduct business only via email or messaging platforms, and do not enforce know-your-customer (KYC) policies. It also includes hosting providers that selectively respond to abuse reports or law enforcement inquiries to maintain plausible deniability, as well as more traditional self-proclaimed “bulletproof” providers that openly ignore oversight or advertise non-cooperation.

            TAE networks serve as the backbone for ransomware groups, infostealer campaigns, botnets, and even state-sponsored threat actor operations. What distinguishes TAE networks is the sustained concentration of malicious infrastructure within their networks.

            How TAEs Operate

            TAEs are masters of obfuscation and are highly resilient, hiding behind layers of decoy companies to evade accountability. They use several core tactics:

            • Corporate Shell Games: They establish front companies across multiple jurisdictions to create legal distance between the infrastructure and the operators.
            • Strategic Resource Control: They often operate as local internet registries (LIRs). This gives them direct control over IP resources and autonomous systems (ASNs), allowing them to manipulate network resources at will.
            • Rapid Rebranding: When a network becomes too "hot" due to scrutiny, TAEs rapidly transfer IP address prefixes to a newly registered, clean-looking entity.

            Identifying High-Risk TAE Networks

            Recorded Future actively identifies high-risk TAE networks through its Network Threat Density List. These networks are ranked by their Threat Density Score, calculated from the concentration of validated malicious activity relative to the total number of IP address prefixes a network announces.

            This approach cuts through the noise to quickly expose infrastructure that is disproportionately associated with threat activity, a core characteristic of TAEs, allowing network defenders to prioritize the infrastructure most likely to pose material risk.

            Chart
            Figure 2: High-risk suspected or confirmed TAE networks in 2025, ranked by Threat Density Score

            From Insight to Action

            Tracking TAE networks allows security teams to move from reacting to individual threats to proactively managing infrastructure risk. In practice, this means applying TAE intelligence across three core areas: prevention, detection, and exposure.

            Operationalize TAE Intelligence

            Figure 3: Three steps for operationalizing TAE intelligence

            TAEs are persistent and continuously evolving, adapting quickly in response to sanctions, enforcement actions, and exposure. While their identities may change, their underlying infrastructure patterns often remain consistent.

            The "metaspinner" Case Study

            In April 2025, a TAE tracked by Recorded Future, Virtualine Technologies, shifted its IPv4 resources to a newly registered network that fraudulently impersonated a legitimate German software firm, metaspinner net GmbH. Because this provider’s historical infrastructure patterns were already being tracked, the newly created network was immediately identified as a front. Within weeks, this network became a primary distribution hub for malware families such as Latrodectus and AsyncRAT. When the operation was eventually exposed, Virtualine Technologies simply pivoted the infrastructure to a new identity within one of its existing autonomous systems to maintain its operations.

            Chart
            Figure 4: Validated malicious activity associated with Virtualine Technologies in 2025

            This case underscores the reality of TAE networks: while identities, ownership records, and corporate fronts may change, the underlying infrastructure and its associated risk persist, making continuous tracking essential to identifying and prioritizing the networks that will drive future threat activity, as demonstrated by Virtualine subsequently emerging as the highest-risk TAE network in 2025.

            The Stark Industries Case Study

            In May 2025, the European Union sanctioned UK-registered hosting provider Stark Industries Solutions and its executives for enabling Russian state-sponsored cyber operations. However, enforcement did not halt Stark Industries’ operations. In the weeks leading up to the sanctions announcement, Stark Industries began transferring IP resources, modifying RIPE registrations, and shifting infrastructure to affiliated entities.

            Figure 5: Timeline of Stark Industries-related events in 2025

            Despite the sanctions, the underlying infrastructure, routing relationships, and operational patterns remained traceable across these new fronts. Continuous monitoring of TAE ecosystems enables defenders to detect these pivots in near real time, revealing continuity beneath corporate rebrands and legal restructurings. This case underscores a broader reality: sanctions may change names and ownership records, but without infrastructure-level visibility, the enabling networks behind malicious activity often persist.

            What This Means for Security Leaders

            TAEs represent an ongoing challenge. While individual campaigns and threat actors may come and go, the infrastructure that supports them remains adaptive and deliberately resilient.

            For security leaders, this requires an additional shift from solely reacting to individual indicators to understanding and prioritizing the infrastructure that enables threat activity at scale. By identifying and tracking high-risk networks, organizations can reduce investigative noise, focus resources on the most impactful threats, and take proactive steps to limit exposure before attacks materialize.

            Ultimately, addressing TAEs is not just about detection; it’s also about disrupting the conditions that enable modern cyber threats to operate.

            Questions You Should Be Asking

            • How much of your network communicates with high-risk infrastructure?
            • Are you prioritizing alerts involving high-risk networks?
            • Is TAE or ASN risk intelligence integrated into your detection and triage workflows to ensure the highest-risk activity is addressed first?
            • Do any of your third-party providers rely on TAE-linked infrastructure?
            • Do you have hidden exposure to TAE networks?
            • Are your controls dynamically adjusting to infrastructure risk?
            • Can you proactively restrict or challenge traffic to and from high-risk networks?

            Introducing AI traffic analysis dashboards for AWS WAF

            ✇AWS Security Blog
            By: Christopher Jen
            5 May 2026 at 20:56

            As AI agents, bots, and programmatic access become an increasingly significant portion of web traffic, organizations need better tools to understand, analyze, and manage this activity. Today, we’re excited to announce AI Traffic Analysis dashboards for AWS WAF protection packs—also known as web access control lists (web ACLs)—providing comprehensive visibility into AI bot and agent behavior across your applications.

            The challenge: Understanding AI bot traffic

            The rapid proliferation of AI bots—from search engine crawlers to research agents—has fundamentally changed the nature of web traffic. Organizations across industries are discovering that AI agents now represent 30–60% of their total traffic, driving significant infrastructure costs without always generating business value.

            Traditional bot management tools weren’t designed for the nuances of AI traffic. Teams need to answer critical questions such as: Which AI organizations are accessing our content? What are they trying to accomplish? Which endpoints are most frequently targeted? How has this activity changed over time? Most importantly, how can we turn this visibility into actionable business decisions?

            Introducing the AI Traffic Analysis dashboard

            The new AI Traffic Analysis dashboard provides specialized visibility into AI bot and agent activity, available directly within your AWS WAF protection pack (web ACL) console. With this launch, AWS WAF Bot Control expands its detection coverage to track more than 650 unique bots and agents, offering one of the most comprehensive AI bot detection catalogs available. A detection catalog that will keep growing and be updated to align with the pace of the industry’s changes.

            This dashboard goes beyond standard security metrics to deliver AI-specific insights that help you understand and manage this critical traffic segment.

            Key capabilities

            • Bot identification and verification: See which AI bots are accessing your applications, including bot names, owning organizations, and verification status. Quickly distinguish between legitimate AI agents from known organizations and potentially suspicious activity.
            • Intent classification: Understand the purpose behind AI bot requests. The dashboard categorizes bot behavior patterns—whether crawling for search indexing, conducting research, gathering training data, or other activities—helping you align access policies with business objectives.
            • Access pattern analysis: Identify your most frequently accessed URLs and endpoints by AI agents. This visibility helps you understand which content is most valuable to AI organizations and optimize your infrastructure accordingly.
            • Temporal trends and historical analysis: Track AI bot activity patterns by time of day and analyze historical trends over the past 14 days. Detect anomalies, understand peak usage periods, and identify emerging patterns in AI traffic.
            • Organization breakdown: View traffic volume segmented by bot owner organization, giving you clear visibility into which AI companies are accessing your content and at what scale.

            How it works

            AI Traffic Analysis dashboards integrate seamlessly with AWS WAF Bot Control for common bots using the same traffic evaluation engine while providing specialized analytics for AI-specific patterns. The dashboards display near real-time summaries based on Amazon CloudWatch metrics collected as AWS WAF evaluates your web traffic.

            To access the AI Traffic Analysis dashboard:

            1. Navigate to your protection pack (web ACL) in the AWS Management Console for AWS WAF.
            2. Select the AI Traffic Analysis tab.
            3. Apply filters for bot organization, intent type, or verification status as needed.
            4. Analyze the comprehensive visualizations across bot identity, intent classification, access patterns, and temporal trends.

            The dashboard populates automatically once your protection pack begins receiving AI bot traffic, so you have visibility exactly when you need it.

            From visibility to action

            This new capability addresses a critical need as organizations navigate the evolving landscape of AI-driven web traffic. With detailed insights into AI bot behavior, you can:

            • Make informed access decisions: Understand bot intent before implementing allow or block rules.
            • Optimize infrastructure investment: Identify high-traffic endpoints and plan capacity accordingly. Know whether your infrastructure costs are supporting business value or used without programmatic compensation mechanism.
            • Implement tiered access strategies: Serve different content or pricing based on AI agent verification and intent.
            • Detect anomalies and emerging patterns: Spot unusual patterns that might indicate emerging threats or opportunities. Real-time visibility helps you respond quickly to changes in AI bot behavior.
            • Support cross-organizational strategy: Provide data to stakeholders across security, product, and business teams for informed decisions about AI bot access policies and monetization opportunities.
            • Customize as needed: AI Traffic analyses are emitted as CloudWatch metrics that an organization can use to customize CloudWatch or another supported observability product as needed. Moreover, by using CloudWatch metrics, an organization can build proactive measures such as alerts or business actions such as rate or limit changes.
            • Monetize AI traffic at the edge: For a reference architecture that combines WAF Bot Control AI visibility, traffic control, and content monetization using the x402 payment protocol, see the sample-x402-content-monetization-with-cloudfront-and-waf project on GitHub. It demonstrates how to classify AI bot traffic, enforce per-path pricing policies, and settle payments at the edge using Amazon CloudFront and Lambda@Edge – with zero changes to your existing origins.

              Note: This AWS Samples solution is not a supported product in their own right, but educational examples to help our customers use our products for their applications. As our customer, any applications you integrate this example into should be thoroughly tested, secured, and optimized according to your business’s security standards & policies before deploying to production or handling production workloads. Deploying it will provision resources that incur additional AWS charges, so review costs before deploying and delete the stack when no longer needed.

            Programmatic access: Automate your AI traffic insights

            In addition to the console dashboard, you can programmatically query AI bot traffic data using the GetTopPathStatisticsByTraffic action, available through the AWS WAF API, AWS SDKs, and AWS CLI. This action returns the top URI paths by bot traffic volume for a given web ACL and time window. Each path in the response includes request counts, traffic percentages, and the top bots accessing it. You can filter results by bot category (for example, ai), organization, or specific bot name, and use a URI path prefix (for example, /api/) to drill down into specific areas of your application. The following AWS CLI example shows how to query the top paths accessed by AI bots for a specific web ACL.

            The following AWS CLI example shows how to query the top paths accessed by AI bots for a specific web ACL:

            aws wafv2 get-top-path-statistics-by-traffic \
  --web-acl-arn "arn:aws:wafv2:us-east-1:123456789012:global/webacl/ExampleWebACL/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" \
  --scope "CLOUDFRONT" \
  --time-window StartTime=2026-02-25T00:00:00Z,EndTime=2026-02-26T00:00:00Z \
  --bot-category "ai" \
  --uri-path-prefix "/api/" \
  --limit 5 \
  --number-of-top-traffic-bots-per-path 3

            A sample response:

            {
  "TopPathStatistics": [
    {
      "Path": "/api/v1/products",
      "RequestCount": 145320,
      "TrafficPercentage": 32.4,
      "TopBots": [
        { "BotName": "ExampleBotA", "Organization": "ExampleOrgA", "RequestCount": 98210 },
        { "BotName": "ExampleBotB", "Organization": "ExampleOrgB", "RequestCount": 47110 },
        { "BotName": "ExampleBotC", "Organization": "ExampleOrgC", "RequestCount": 0 }
      ]
    },
    {
      "Path": "/api/v2/search",
      "RequestCount": 87650,
      "TrafficPercentage": 19.5,
      "TopBots": [
        { "BotName": "ExampleBotA", "Organization": "ExampleOrgA", "RequestCount": 52300 },
        { "BotName": "ExampleBotC", "Organization": "ExampleOrgC", "RequestCount": 35350 },
        { "BotName": "ExampleBotB", "Organization": "ExampleOrgB", "RequestCount": 0 }
      ]
    }
  ],
  "TimeWindow": {
    "StartTime": "2026-02-25T00:00:00Z",
    "EndTime": "2026-02-26T00:00:00Z"
  }
}

            Programmatic access enables you to:

            • Build custom dashboards or integrate AI traffic data into existing observability platforms.
            • Automate alerting when specific paths see unusual bot traffic spikes.
            • Feed traffic data into business intelligence pipelines for content monetization decisions.
            • Investigate and debug AI bot activity within a specific timeframe to identify the root cause of traffic anomalies or incidents.

            For detailed usage information, see the GetTopPathStatisticsByTraffic API reference and the AWS CLI command reference. This API pairs naturally with the CloudWatch metrics approach described above, giving you both real-time metric streams and on-demand path-level analytics for comprehensive AI traffic management.

            Availability

            For customers on flat-rate pricing plans, the AI Traffic Analysis dashboard is included with all paid plans. Read more about CloudFront flat-rate pricing in the launch blog post. For AWS WAF customers not subscribed to flat-rate plans, the AI traffic analysis dashboard is available at no additional cost. See AWS WAF pricing for details.

            Get started today

            The AI Traffic Analysis dashboard represents a significant step forward in managing the intersection of AI and web security. As AI agents continue to grow as a percentage of overall web traffic, having the right visibility tools becomes essential for both security and business success.

            To learn more about AWS WAF Bot Control and AI Traffic Analysis dashboards, visit the AWS WAF Developer Guide or explore the feature directly in your AWS WAF console.

            If you have feedback about this post, submit comments in the Comments section below.

            Christopher Jen

            Christopher Jen

            Christopher is a go-to-market leader at Amazon Web Services (AWS), specializing in Edge Services, Cyber Security, AI Security, and Agentic Identification. Based in London, he’s a seasoned business development and partnerships executive with a track record of driving growth across cloud, security, and emerging technology domains.

            Eitav Arditti

            Eitav Arditti

            Eitav is an AWS Senior Solutions Architect with over 15 years of experience in the AdTech industry. He specializes in Edge computing, Serverless, Containers, and Platform Engineering. Eitav helps organizations design cost-efficient, large-scale AWS architectures that integrate cloud-focused and Edge services such as CloudFront and WAF to deliver secure, performant, and globally scalable solutions that accelerate business growth.

            Author

            Kaustubh Phatak

            Kaustubh is a product leader specializing in AI/ML systems and enterprise security solutions. He has led cross-functional teams in deploying AI-powered products at scale, working closely with security architects and CISOs to address the intersection of AI innovation and cybersecurity risk. His work focuses on translating complex technical capabilities into business value, particularly in emerging technology domains where traditional frameworks don’t apply.

            Five ways to use Kiro and Amazon Q to strengthen your security posture

            ✇AWS Security Blog
            By: Roger Nem
            5 May 2026 at 17:00

            A Monday morning security alert flags unauthorized access attempts, security group misconfigurations, and AWS Identity and Access Management (IAM) policy violations. Your team needs answers fast.

            Security teams are using Kiro and Amazon Q Developer to handle repetitive tasks—scanning resources, drafting policies, and researching Common Vulnerabilities and Exposures (CVEs)—so engineers can focus on risk decisions and complex scenarios that require human judgment, resulting in faster threat response and more consistent security coverage.

            This post shows you five ways to use Kiro and Amazon Q Developer to strengthen your AWS security posture based on the AWS Well-Architected Framework Security Pillar. Each technique builds on a common foundation described after the tool overview below.

            About these tools

            Amazon Web Services (AWS) gives customers choices when it comes to AI-assisted development and security automation. Whether you prefer Kiro’s agentic integrated development environment (IDE) experience or the deep integration of Amazon Q Developer into your existing AWS environment, both tools can help you implement the security practices described in this post. The right choice depends on your team’s workflow, and in many cases both tools are complementary and can be used together.

            Kiro is an AI-powered, agentic, IDE designed by AWS for specification-driven development, combining natural language prompting with structured, intentional coding to generate, test, and deploy applications.

            Amazon Q Developer is the generative AI assistant integrated into AWS development and cloud environments, designed to answer questions, generate code, troubleshoot issues, and automate operational tasks across AWS services.

            For setup instructions and to learn more, see the Kiro documentation and Amazon Q Developer documentation.

            1. Embed security best practices with persistent context

            Providing AI assistants with the right context helps them produce more consistent and relevant results. Each of the five techniques in this post becomes significantly more powerful when your AI assistant already understands your organization’s security standards. Setting up persistent context first means every subsequent interaction builds on that foundation, and the results you get from triage, remediation, reviews, and policy development will better reflect your specific environment rather than generic best practices.

            Without persistent context, you need to repeat the same security requirements in every prompt such as "enable encryption, use least privilege IAM settings, and enable logging," which leads to inconsistent results and missed controls. Amazon Q Developer IDE Plugin rules and Kiro steering files (CLI and IDE) solve exactly this problem: you can use them to codify your organization’s security standards so AI automatically builds secure infrastructure consistently, without requiring you to repeat requirements in every prompt. Both tools support this capability independently, so you can configure whichever fits your workflow, or use both together for coverage across your full development environment. The following steps show you how to get started with each.

            For Amazon Q Developer:

            1. Create directory: .amazonq/rules/ in your project root.
            2. Create file: .amazonq/rules/security-standards.md.
            3. Paste your organization’s security standards in natural language (see “Example security standards context file” below).

            For Kiro (steering files):

            In Kiro, persistent context documents are called steering files. They give the agent ongoing awareness of your architecture decisions, coding standards, and security requirements across every interaction and every session.

            1. Create file: security-standards.md in your project root.
            2. Reference it in prompts: Using security-standards.md as context, create....

            Pro tip: You can use Kiro itself to help you create steering files. Describe your security requirements in natural language and ask Kiro to generate a structured steering file for your review before saving and activating it. This means your AI assistant can help you build the very context it will later use, making the setup process faster and more thorough.

            Example security standards context file:

            # AWS Security Standards

## Identity and Access Management
- All IAM roles must use least privilege principles
- Require MFA for console access
- Enable IAM Access Analyzer for all accounts
- Rotate access keys every 90 days
- Use IAM roles for EC2 instances, never embed access keys

## Data Protection
- Enable encryption at rest for all storage services (S3, EBS, RDS)
- Use AWS KMS customer-managed keys for sensitive data
- Enable encryption in transit with TLS 1.2 minimum
- Implement S3 bucket policies denying unencrypted uploads
- Enable versioning and MFA delete for critical S3 buckets

## Infrastructure Protection
- Security groups must follow least privilege (no 0.0.0.0/0 on sensitive ports)
- Deploy resources in private subnets when possible
- Enable VPC Flow Logs for network monitoring
- Use AWS WAF for public-facing applications
- Implement Network ACLs as additional defense layer

## Detective Controls
- Enable CloudTrail in all regions with log file validation
- Configure CloudWatch alarms for security events
- Enable GuardDuty for threat detection
- Set up AWS Config rules for compliance monitoring
- Implement centralized logging with retention policies

## Incident Response
- Create SNS topics for security alerts
- Configure automated responses with AWS Lambda
- Maintain runbooks for common security incidents
- Enable AWS Systems Manager for secure instance access
- Implement automated backup and recovery procedure

            What this unlocks:

            Without persistent context, a prompt like Create a Lambda function to process customer data could produce a basic function with no encryption, logging, or IAM configuration. AI output is non-deterministic, meaning that without guidance it might or might not include those controls. Steering files and rules documents minimize those variables by providing stronger guidance as part of every prompt and inference input.

            With your security standards embedded as in the example above, however, the same prompt generates a function with KMS-encrypted environment variables, a CloudWatch log group with 90-day retention, least-privilege IAM, VPC placement in private subnets, a dead-letter queue, and AWS X-Ray tracing—all automatically.

            Where it works:

            This persistent context approach applies across both tools and all infrastructure generation workflows:

            • Amazon Q Developer IDE Plugin: Rules in .amazonq/rules/ apply automatically to every code generation and review interaction.
            • Kiro: Steering files provide the agent with continuous architectural and security awareness across sessions and projects.

            The shift-left impact:

            This approach isn’t a replacement for your existing continuous integration and delivery (CI/CD) security automation. It’s a powerful complement to it, and that distinction matters. By embedding security standards directly into the development workflow, you shift security validation further left than pipeline checks can reach. Developers across your organization, not just security specialists, can generate infrastructure that meets your security standards from the first line of code. This scales security expertise into non-security roles, empowers development teams to self-serve on compliance requirements, and reduces the volume of findings that ever reach your automated pipeline checks.

            The result is security functioning as an enabler of faster development rather than a gate that slows it down, and security engineers spending their time on policy design and complex risk decisions rather than remediating avoidable misconfigurations.

            Measurable impact:

            Track these metrics to quantify the value of persistent context:

            • Security findings during code review: Establish a 30–60 day baseline before enabling context files, then compare
            • Time from development to deployment: Track average cycle time before and after
            • Remediation cost: Research consistently shows defects fixed in development cost significantly less than those fixed in production. Track your own ratio for 60 days
            • Standards consistency: Audit a random sample of infrastructure pull requests for compliance with your top 10 policies

            Implementation recommendation: Start by codifying your top 10 most frequently violated security policies as context. Measure the reduction in these specific findings over 30–60 days to quantify the impact on your team.

            2. Accelerate security finding triage and investigation

            AWS Security Hub consolidates findings from services such as Amazon GuardDuty, AWS Config, Amazon Inspector, and third-party security tools into a single dashboard, providing centralized security finding visibility and built-in triage capabilities across your AWS environment. AWS Security Hub Extended will bring even more capabilities into this mix, giving customers expanded control and additional opportunities to leverage the AI-assisted workflows described in this post at greater scale and with deeper integration across your security toolchain.

            Kiro can complement Security Hub by helping you correlate findings across accounts, understand CVE context, and develop remediation approaches, including:

            • Query findings using natural language across multiple AWS accounts and AWS Regions
            • Understand specific CVEs and their potential impact on your infrastructure
            • Generate investigation queries for AWS CloudTrail and Amazon Virtual Private Cloud (Amazon VPC) Flow Logs
            • Correlate security events across different time periods and services
            • Access the latest AWS security documentation and best practices

            How it works – Model Context Protocols:

            To enable these capabilities, Kiro uses Model Context Protocols (MCPs)—a standardized way for AI assistants to securely connect with external tools, services, and data sources, enabling them to take actions, retrieve real-time information, and interact with APIs beyond their built-in capabilities.

            Open source MCP servers for AWS are a suite of specialized MCP servers that enable Kiro to interact with AWS security services, providing real-time visibility into your security posture. To get started, configure security-focused MCP servers in your Kiro settings file (as shown in the following example). For full instructions on configuring MCP servers in Kiro, see the Kiro MCP documentation.

            Note on authentication: Before querying Security Hub, verify you have configured valid AWS credentials for the target account. Set the AWS_PROFILE value to a named profile in your ~/.aws/credentials file that has the appropriate permissions, or configure credentials using the AWS Command Line Interface (AWS CLI) (aws configure). Without valid credentials for the target account, Kiro will not be able to retrieve findings.

            {
    "mcpServers": {
        "awslabs.aws-api-mcp-server": {
            "command": "uvx",
            "args": ["awslabs.aws-api-mcp-server@latest"],
            "env": {
                "FASTMCP_LOG_LEVEL": "ERROR",
                "AWS_PROFILE": "<PROFILE>",
                "AWS_REGION": "us-east-1"
            },
            "timeout": 120000,
            "disabled": false
        },
        "awslabs.cloudtrail-mcp-server": {
            "command": "uvx",
            "args": ["awslabs.cloudtrail-mcp-server@latest"],
            "env": {
                "FASTMCP_LOG_LEVEL": "ERROR",
                "AWS_PROFILE": "<PROFILE>"
            },
            "disabled": false
        },
        "awslabs.iam-mcp-server": {
            "command": "uvx",
            "args": ["awslabs.iam-mcp-server@latest"],
            "env": {
                "FASTMCP_LOG_LEVEL": "ERROR",
                "AWS_PROFILE": "<PROFILE>"
            },
            "disabled": false
        }
    }
}

            Configure the following security-focused MCP servers to get started:

            • AWS API MCP Server: Interact with Security Hub, GuardDuty, IAM Access Analyzer, and AWS Config through AWS CLI commands
            • CloudTrail MCP Server: Audit trail analysis and compliance monitoring
            • AWS IAM MCP Server: Manage IAM users, roles, policies, and permissions
            • AWS Knowledge MCP Server: Access up-to-date AWS security documentation and best practices

            For a full list of available MCP servers, see the awslabs/mcp GitHub repository.

            Example: querying Security Hub with Kiro:

            1. Open your terminal or Kiro IDE.
            2. Enter the following command:
            "Show me all critical security findings from Security Hub in my production account ID <ACCOUNT ID>"

            Example output:

            > Found 4 critical security findings in account 123456789012:

## Configuration Issues (2)

1. SSM.7 - SSM documents block public sharing disabled
- Status: FAILED (since July 17, 2025)
- Impact: Systems Manager documents can be publicly shared
- Remediation: Enable block public sharing setting for SSM documents
- [Documentation](https://docs.aws.amazon.com/console/securityhub/SSM.7/remediation)

2. Config.1 - AWS Config not properly configured
- Status: FAILED (since March 4, 2025)
- Issue: Config isn't recording required IAM resource types (User, Role, Group, Policy)
- Standards affected: CIS, NIST 800-53, PCI DSS, AWS Foundational Security
- Remediation: Enable recording for IAM resources in AWS Config
- [Documentation](https://docs.aws.amazon.com/console/securityhub/Config.1/remediation)

## Vulnerabilities (2)

3. CVE-2020-36242 in Lambda function: MyLambdaOne
- Package: cryptography version 3.2.1
- CVSS Score: 9.1 (Critical)
- Issue: Integer/buffer overflow in Fernet encryption class
- Fix: Upgrade to cryptography 3.3.2
- Function: SPC-1233HH5R-MyLambdaOne-lUh3ESH0MdXF

4. CVE-2020-36242 in Lambda function: AutoUpdateMyLambdaOne
- Package: cryptography version 3.2.1
- CVSS Score: 9.1 (Critical)
- Same vulnerability as above
- Function: SPC-1233HH5R-AutoUpdateMyLambdaOne-d9HIBfxThbFW

            Real-world impact:
            Security finding triage that previously required navigating multiple consoles, correlating logs manually, and researching CVE databases can be accelerated significantly. Teams that have integrated AI-assisted triage into their Security Hub workflows report reducing mean time to triage for critical findings from hours to minutes, enabling faster containment and more consistent coverage across accounts.

            3. Accelerate remediation of security findings in your infrastructure as code

            AI assistants can scan your infrastructure code and flag security issues with specific fix recommendations. However, implementing these changes requires careful review, testing, and validation before any changes reach production.

            Important: AI-generated remediation suggestions must be reviewed by a qualified security engineer before implementation. Automated application of AI-generated changes without human validation can introduce unintended misconfigurations or service disruptions. Treat AI output as a starting point, not a finished product.

            The workflow:
            You can execute this workflow in either Kiro or Amazon Q Developer, depending on which tool fits your existing development environment:

            1. Ask Kiro or Amazon Q Developer to scan your infrastructure files and identify security gaps.
            2. Review AI-generated remediation suggestions with your security team.
            3. Test changes in non-production environments.
            4. Validate using AWS security services such as IAM Access Analyzer, AWS Config, and Security Hub.
            5. Deploy to production with monitoring and rollback procedures in place.

            Example prompt:

            "Scan my infrastructure at /path/to/templates, identify all S3 buckets without encryption, enable AES-256 encryption, add bucket policies to deny unencrypted uploads, and provide the deployment command"

            What happens:

            The AI assistant analyzes your infrastructure files, whether written in AWS CloudFormation, Terraform , or AWS Cloud Development Kit (AWS CDK), and identifies resources that violate security best practices. It then implements controls such as encryption at rest using AWS Key Management Service (AWS KMS) or Amazon Simple Storage Service (Amazon S3)-managed keys, adds bucket policies enforcing encryption in transit, configures public access blocks, and generates the exact deployment command with a change preview so you can review what will be modified before anything is applied.

            Based on the example security standards context file above, the following controls would be applied across all generated infrastructure: encryption at rest and in transit, least-privilege IAM policies, security group optimizations, VPC configurations, logging enablement, and backup and recovery settings.

            Validation required:
            AI-generated configurations deserve the same thoughtful review as other infrastructure code. Even a policy that looks correct on the surface might need tuning to match your organization’s least-privilege standards, or encryption settings might need adjusting to satisfy specific compliance requirements. Running those changes through a non-production environment and having a human confirm the results before anything reaches production are part of good infrastructure practices, whether the code was written by a person or generated by AI.

            Real-world impact:

            Identifying non-compliant resources across multiple accounts manually can take many hours and generating remediation templates for each resource can add significant time. Security teams that have adopted AI-assisted infrastructure scanning report spending less time on manual identification and template generation, and with AI assistance the same identification and drafting work can be completed in much less time. Customers report that a full remediation cycle that previously occupied their team for the better part of a day can be completed in under an hour when AI handles the scanning and template generation. It is worth noting that manual remediation time grows considerably at scale, as remediating dozens of non-compliant resources is not a linear exercise. Validation time in non-production environments remains essential regardless of how the remediation was generated, and should always be factored into your planning.

            4. Perform in-depth security reviews

            Amazon Q Developer and Kiro can analyze your infrastructure code and identify potential security issues across multiple categories aligned with the AWS Well-Architected Framework Security Pillar.

            Using Amazon Q Developer:

            1. Open your infrastructure file in your IDE.
            2. Select the code you want to review.
            3. Open the context menu and choose Send to Amazon Q, then choose Optimize.
            4. Select Focus on security best practices.

            Using Kiro:

            1. Open your infrastructure file in Kiro.
            2. Enter a natural language prompt such as: Perform a comprehensive security review of this CloudFormation template and identify all deviations from our standards.
            3. Kiro will automatically apply your steering files as additional context when generating its response.
            4. Review the findings and iterate with follow-up prompts.

            Security categories evaluated: For the complete, up-to-date list of security categories and controls, see the AWS Well-Architected Framework Security Pillar documentation. Current categories include but are not limited to:

            • Identity and access management: Overly permissive IAM policies, missing multi-factor authentication (MFA) requirements, unused credentials and access keys, cross-account access risks
            • Detective controls: CloudTrail logging configuration, Amazon CloudWatch alarm coverage, GuardDuty enablement status, and AWS Config rule implementation
            • Infrastructure protection: Security group misconfigurations, public subnet exposure, missing AWS WAF rules, unencrypted network traffic
            • Data protection: Storage encryption status, KMS key rotation policies, backup configurations, S3 bucket access controls
            • Incident response: Amazon Simple Notification Service (Amazon SNS) alerting setup, log retention policies, automated response mechanisms

            Example output:

            Security Recommendations:
- Enable S3 bucket encryption with KMS: Critical
- Implement least privilege IAM policies: High
- Enable GuardDuty threat detection: High
- Configure VPC Flow Logs: Medium
- Add WAF rules for API Gateway: Medium
- Enable CloudTrail in all regions: Critical
- Implement automated backup policies: High

Total security improvements: 23 findings across 5 Well-Architected pillars

            Keeping your configuration files current:

            A security architect review remains valuable for keeping your steering files and rules documents complete and current. The goal is an AI assistant that already understands your environment, not one that needs correcting after every interaction. Treat your configuration files as living documents and update them when your security standards evolve, when new services are adopted, or when post-incident reviews reveal gaps. As this post notes, project rules reduce architectural drift and help maintain consistency as AI agents operate more autonomously.

            Real-world impact:

            Security reviews that previously required a security engineer to manually inspect infrastructure templates line by line can be completed in significantly less time with AI assistance. Teams using AI-assisted security reviews as a pre-commit gate—before code reaches CI/CD pipeline checks—report catching a meaningful portion of security findings earlier in the development cycle where they are faster and less costly to address. Integrating this review step into pull request workflows means security validation happens continuously rather than only at deployment gates.

            5. Assist with service control policy development

            You can use AWS Organizations Service Control Policies (SCPs) to apply preventive controls consistently across every account in your organization, enforcing security baselines without relying on individual account administrators. Kiro can generate initial SCP drafts from natural language security requirements, speeding up the drafting and iteration process considerably. Because SCPs are preventive controls that can’t be bypassed by administrators, misconfigurations can cause organization-wide service disruptions, making expert validation and staged testing essential before any SCP reaches production.

            Step 1: Generate an SCP draft:

            Describe your security requirements in natural language:

            "Create an SCP with these security controls:
- Deny creation of S3 buckets without encryption
- Require MFA for IAM user console access
- Prevent public RDS snapshots
- Deny security group rules allowing 0.0.0.0/0 on sensitive ports
- Enforce encryption for all EBS volumes
- Require VPC Flow Logs on all VPCs
- Deny IAM policy creation without approval tags
- Restrict resource creation to approved regions only"

            Kiro generates a complete SCP policy JSON with proper deny statements, condition keys for MFA and encryption enforcement, resource-level restrictions, and regional compliance requirements.

            Step 2: Validate and lint the SCP:

            Use Kiro or Amazon Q Developer to assist with policy linting and initial testing as a first layer of validation. IAM Policy Autopilot, available as a Kiro Power with one-click installation directly from the Kiro IDE, can analyze your application’s usage and generate necessary permissions based on the SDK calls it discovers. IAM Policy Autopilot also integrates as an MCP server with Kiro, Amazon Q Developer, and other MCP-compatible coding assistants, making it a natural part of your existing workflow rather than a separate tool.

            "Review this SCP JSON for syntax errors, overly broad deny statements, and missing condition keys. Flag any statements that could unintentionally block legitimate operations."

            The IAM Policy Simulator then adds another layer of validation on top of the AI-assisted linting, so you can test policy behavior, verify condition keys are correctly applied, and confirm that no legitimate operations are unintentionally blocked. IAM Policy Autopilot complements existing IAM tools such as IAM Access Analyzer by providing functional policies as a starting point, which you can then validate using IAM Access Analyzer policy validation or refine over time with unused access analysis. Together, these tools form a layered validation approach where each one strengthens the output of the previous step.

            Step 3: Test in a sandbox environment:

            Create a test organizational unit (OU) with non-production accounts and apply the SCP to the test OU. Attempt operations that should be blocked and confirm that no legitimate operations are unintentionally blocked. Use Kiro to pre-validate your infrastructure code against the proposed SCP before sandbox testing:

            "Analyze my current infrastructure against this proposed SCP and identify resources that would be non-compliant"

            This scan covers your infrastructure code files. For live account scanning across your organization, use the following AWS services:

            • AWS Config with the Config Aggregator and Conformance Packs for continuous compliance monitoring across your organization.
            • IAM Access Analyzer for automated reasoning-based analysis of external access, internal access, and unused permissions.
            • Account Assessment for AWS Organizations for bulk scanning of identity-based, resource-based, and service control policies across all accounts.
            • Security Hub for centralized aggregation of compliance findings and security scores across your entire organization.

            Step 4: Security architect review:

            Engage your security architects to identify potential risks and verify the policy aligns with your security framework. Check for conflicts with existing SCPs by reviewing all SCPs attached to parent OUs and the root in the AWS Organizations console. Use the IAM Policy Simulator to test interactions between policies and verify that emergency access procedures ( SEC03-BP03 Establish emergency access process – Security Pillar and SEC10-BP05 Pre-provision access – Security Pillar) remain functional before any production rollout.

            Step 5: Staged rollout:

            Deploy to development accounts first and monitor for policy violations and operational issues. Gradually expand to additional environments and maintain documented rollback procedures throughout the process.

            Important: It’s strongly recommended not to deploy AI-generated SCPs directly to production without thorough expert review and staged testing. A misconfigured SCP can cause organization-wide service disruptions affecting every account in your organization.

            Real-world impact:

            SCP drafting that previously required security architects to write and iterate on complex JSON policy documents manually, often spanning multiple review cycles over several days, can be condensed when AI handles the initial drafting and linting. Your architects can then focus their time on policy design, edge case analysis, and organizational impact assessment rather than JSON syntax and structure.

            Responsible implementation framework

            Adopting AI-assisted security workflows is most effective when introduced gradually, with clear validation gates at each stage. The following two-phase approach gives your team time to build confidence, measure results, and establish the internal practices needed before expanding to production environments.

            • Phase 1: Development and testing (weeks 1–4): Start by testing AI-generated security controls in isolated development accounts. Validate functionality, identify edge cases, and deploy to a dedicated testing environment with thorough security validation. Use IAM Access Analyzer, AWS Config, and Security Hub to verify that generated controls behave as expected. This phase is also the right time to build internal expertise across both your security team and your development teams, so that knowledge of what works and what requires human review is shared broadly from the start.
            • Phase 2: Staging and production (week 5 and later): Apply the validated controls to a staging environment that mirrors production. Conduct penetration testing where appropriate and validate that monitoring and alerting function correctly before expanding further. Gradually roll out to production accounts with continuous monitoring in place. Maintain rollback procedures throughout and establish feedback loops so that lessons learned in production flow back into your steering files, rules documents, and validation processes over time.

            Key takeaways

            What distinguishes the approach in this post from general guidance on AI coding assistants is the specificity of the security integration. There’s no shortage of content about how AI assistants accelerate development. What this post focuses on is how to configure both Kiro and Amazon Q Developer to perform security-specific tasks: triaging findings from Security Hub, remediating infrastructure code vulnerabilities against your organization’s defined standards, conducting Well-Architected security reviews, drafting and validating SCPs, and generating secure-by-default infrastructure through persistent context that reflects your environment rather than generic defaults.

            Kiro is an agentic IDE that helps you go from prototype to production with spec-driven development, and its steering files give the agent persistent awareness of your security standards across every session. Amazon Q Developer complements this by providing deep integration into your existing AWS environment and IDE workflows. Together, these tools extend your security team’s reach into every stage of the development lifecycle, scale security expertise into development teams, and reduce the gap between when vulnerabilities are introduced and when they are caught. As the AWS Well-Architected Framework Security Pillar establishes, embedding security early and consistently across the development process is foundational to a strong security posture.

            These five techniques aren’t about replacing your security controls. They’re about making security a natural part of how your teams build on AWS, regardless of whether they’re security specialists or application developers. In addition to the five techniques covered in this post, the following AWS capabilities complement this approach and are worth exploring for a more complete picture:

            • Amazon Inspector is a vulnerability management service that continually scans AWS workloads for software vulnerabilities, code vulnerabilities, and unintended network exposure. It automatically discovers and scans Amazon EC2 instances, container images in Amazon ECR, AWS Lambda functions, and first-party code repositories. Amazon Inspector integrates directly into CI/CD pipelines through plugins for Jenkins, TeamCity, GitHub Actions, and Amazon CodeCatalyst, which teams can use to catch vulnerabilities before deployment. Its code security capabilities include Static Application Security Testing (SAST), Software Composition Analysis (SCA), and infrastructure as code (IaC) scanning, with native integration to GitHub and GitLab. All findings are surfaced directly in Security Hub for centralized visibility and response across your organization.
            • Amazon Q Developer security scanning provides real-time security issue detection in the IDE, including SAST scanning for security vulnerabilities, secrets detection, IaC security evaluation, and software composition analysis for third-party dependencies. These capabilities are available across JetBrains, Visual Studio Code, and Visual Studio.
            • Kiro Powers are curated and pre-packaged MCP servers, steering files, and hooks validated by Kiro partners to accelerate specialized development and deployment use cases. Security-relevant Kiro Powers include the IAM Policy Autopilot Kiro Power for baseline IAM policy generation and the real-time coding security validation MCP server pattern for Kiro.
            • AWS Security Agent is a frontier AI agent that proactively secures your applications throughout the development lifecycle. Security teams define organizational security requirements once in the AWS Security Agent console, such as approved encryption libraries, authentication frameworks, and logging standards, and AWS Security Agent then automatically validates these requirements throughout development by evaluating architectural documents and code against your defined standards. It provides three core capabilities: design security review for architecture documents, code security review that automatically analyzes pull requests against your defined standards across connected repositories, and on-demand penetration testing that discovers, validates, and reports vulnerabilities through sophisticated multi-step attack scenarios customized for each application. When vulnerabilities are found, AWS Security Agent creates pull requests with ready-to-implement fixes directly in your code repository. Customers report that AWS Security Agent compresses penetration testing timelines from weeks to hours, transforming penetration testing from a periodic bottleneck into an on-demand capability that reduces risk exposure and scales security reviews to match development velocity.
            • AWS Security Hub automated response and remediation provides pre-built playbooks for common findings using AWS Systems Manager Automation, enabling your team to act on findings faster and more consistently.

            Getting started

            If you’re new to AI-assisted security workflows, the following week-by-week approach gives your team a practical path forward without overextending before the foundation is in place.

            • Weeks 1 and 2: Set up your persistent context files with your top 10 security policies as described in the foundational setup section above. Configure MCP servers in Kiro for Security Hub and CloudTrail access and verify that credentials are correctly configured for your target accounts.
            • Weeks 3 and 4: Run your first AI-assisted security review on a non-production infrastructure template. Compare the findings against your last manual review to establish a baseline for measuring impact over time.
            • Weeks 5 and 6: pilot AI-assisted SCP drafting for one new preventive control. Run the full validation workflow including AI-assisted linting, IAM Policy Autopilot, and the IAM Policy Simulator before any production application.
            • From that point forward: Measure the metrics outlined in the foundational setup section, update your steering files and rules documents as your standards evolve, and share findings across your security team, development teams, and platform engineering teams. The knowledge of what works and what requires human judgment is valuable to everyone who touches infrastructure in your organization.

            Conclusion

            Kiro and Amazon Q Developer give security teams practical tools to accelerate threat response and maintain consistent security coverage by handling the tasks that consume the most time with the least strategic value: scanning for known misconfigurations, drafting policy JSON, researching CVEs, and generating secure infrastructure. These AI assistants are most effective when paired with security engineers, as they accelerate assessments and code generation while human review, policy design, and risk judgment remain essential throughout.

            By implementing the five techniques outlined in this post, starting with embedding security best practices through persistent context and then applying that foundation to Security Hub finding triage, infrastructure code remediation, in-depth Well-Architected security reviews, and SCP development, your team can strengthen your AWS security posture while maintaining the standards your organization requires.

            AWS services such as Security Hub, IAM Access Analyzer, AWS Config, and CloudTrail provide the foundation for these AI-assisted workflows, enabling centralized visibility and automated validation of security controls across your environment. Emergency access procedures should be established and validated before deploying any preventive controls such as SCPs, following the break-glass guidance in the AWS Well-Architected Security Pillar and the AWS Prescriptive Guidance for break-glass access.

            Start small with non-production environments, establish clear validation processes, measure results, and gradually expand your use of AI assistants as your team builds expertise and confidence. The result is faster threat response, more consistent security coverage, and security engineers focused on complex decisions rather than repetitive tasks.

            Additional resources

            If you have feedback about this post, submit comments in the Comments section below

            Roger Nem

            Roger Nem

            Roger is an Enterprise Technical Account Manager (TAM) supporting Healthcare & Life Science customers at Amazon Web Services (AWS). As a Security Technical Field community specialist, he helps enterprise customers design secure cloud architectures aligned with industry best practices. Beyond his professional pursuits, Roger finds joy in quality time with family and friends, nurturing his passion for music, and exploring new destinations through travel.

            Securing open proxies in your AWS environment

            ✇AWS Security Blog
            By: Dodd Mitchell
            4 May 2026 at 20:16

            This article shows you how to identify and secure open proxies in your AWS environment to prevent abuse, protect your IP address reputation, and control costs.

            An open proxy is a server that forwards traffic on behalf of internet users without requiring authentication. While proxies can support legitimate use cases such as load balancing or caching, open proxies allow unrestricted access that threat actors can use to hide harmful activity. In Amazon Web Services (AWS) environments, open proxies often result from misconfigured Amazon Elastic Compute Cloud (Amazon EC2) instances, containers, or compute resources such as AWS Lambda functions. These resources expose proxy functionality without access controls.

            Open proxies come in several forms. Common open proxies can include:

            • HTTP proxies: HTTP proxies forward HTTP requests to web servers, making them useful for web traffic management. These proxies can create potential issues when they’re unsecured.
            • SOCKS proxies: SOCKS proxies support a wider range of traffic types and provide more flexibility. These proxies create a broader potential for misuse.
            • Transparent proxies: Transparent proxies intercept traffic without the client’s knowledge and are often used to filter content. These proxies can become security liabilities when misconfigured.
            • Reverse proxies: Reverse proxies help with internal routing. Unauthorized users can misuse these proxies if they’re exposed.

            Knowing these risks can help you better protect your AWS environment.

            Security risks

            Because of the unrestricted configuration of open proxy servers, threat actors target them to conduct denial of service (DoS) events, intrusion attempts, distribute spam, and other forms of unauthorized activity. These open proxy servers allow threat actors to hide their actual IP address and other forms of identification from the intended targets.

            When your AWS infrastructure hosts an open proxy, several risks emerge that can affect both your operations and customers:

            • Threat actors can misuse your resources, which can result in your IP address being added to security service and reputation system block lists. This can affect your legitimate business operations and customer access. When external parties use your infrastructure for harmful activities, the reputation damage extends beyond immediate technical concerns to affect your ability to reach customers and partners.
            • Unexpected costs from resource consumption occur when threat actors use your bandwidth and compute capacity. The traffic patterns that proxy abuse generate can also alert AWS security monitoring systems and create additional operational overhead as you investigate and respond to these alerts.
            • Service disruptions might affect your legitimate workloads because unauthorized traffic competes for resources with your business-critical applications. This competition for resources can potentially degrade performance or cause availability issues for your customers.

            Implementing security measures

            To prevent the risks associated with open proxies, it’s essential to implement proper security controls for proxy services in AWS environments. The following guidance is a comprehensive approach that you can follow to secure your proxy infrastructure.

            Access control implementation

            An important security step is to use passwords and authentication mechanisms to restrict access to proxy services. Configure your proxies to accept connections only from known, trusted IP address ranges. For Elastic Load Balancing (ELB), limit access based on source IP addresses and add authentication to proxies behind the load balancers. When you create new instances in Amazon Elastic Kubernetes Service (Amazon EKS), limit access to your balancer in each instance. If instances don’t have public IP addresses, then you can limit access to the balancer instead. If instances have public IP addresses, then you must limit access to those IP addresses.

            When possible, use AWS PrivateLink virtual private cloud (VPC) endpoints to provide private connectivity to AWS services without exposing them to the internet. Deploy proxy services in private subnets with controlled outbound access through NAT gateways or other controlled channels. For Amazon EC2 and Amazon Lightsail resources, update the attached security group to prevent public internet access. To secure the proxy, you must either limit access to specific IP addresses or implement authentication on the endpoint.

            Authentication and authorization

            Turn on authentication for the proxy software and use strong credentials, certificates, or integration with AWS Identity and Access Management (IAM) and AWS Directory Service. Apply IAM policies with the principle of least privilege to limit access to only what users need to perform their tasks. This approach reduces the potential effects of credential compromise and helps maintain clear accountability for resource access.

            Monitoring and detection

            To detect unusual proxy activity, configure Amazon Virtual Private Cloud (Amazon VPC) Flow Logs, AWS CloudTrail, and Amazon GuardDuty. Use Amazon CloudWatch alarms to notify you of abnormal traffic patterns that might indicate unauthorized use of your proxy services. These monitoring capabilities provide visibility into your network traffic patterns and help you identify both legitimate usage and potential security concerns.

            Deployment best practices

            Use HTTPS for ELB traffic to protect data in transit, and restrict security groups to necessary ports to minimize the surface area for potential misuse. Integrate AWS WAF with balancers to filter web traffic based on rules that you define. You can also use AWS Network Firewall for advanced traffic filtering capabilities. For APIs, deploy Amazon API Gateway with authentication and authorization controls to manage access to your backend services. This layered approach to security helps protect your infrastructure at multiple points in the traffic flow.

            Regular security assessments

            Run Amazon Inspector to scan for misconfigurations in your infrastructure, and use AWS Security Hub to centralize security findings across your AWS environment. Conduct penetration tests in accordance with AWS policy to identify potential security issues before they can result in unintended access.

            Incident response planning

            Automate remediation with AWS Config rules and Automation, a capability of AWS Systems Manager, to respond rapidly to security events. Maintain incident response runbooks that outline clear steps for addressing proxy-related security incidents, and decommission unused resources that could become security liabilities.

            Documented procedures and automated responses reduce the time between detection and remediation and minimizes the potential effects of security incidents on your operations.

            Benefits of proper proxy security

            When you implement these security measures, you gain the following advantages for your AWS environment:

            • Protection of your IP address reputation helps maintain customer trust and prevents security services from blocking your legitimate traffic. When your infrastructure maintains a positive reputation, your business communications reach their intended recipients without interference.
            • Cost control prevents unauthorized users from consuming your AWS resources and generating unexpected charges on your account. When you restrict access to legitimate users and use cases, you maintain predictable costs that align with your business needs.
            • Operational stability reduces the risk of service disruptions that abuse of your proxy infrastructure can cause. When you dedicate your resources to serving your customers rather than supporting unauthorized activity, you can deliver consistent performance and availability.
            • Enhanced visibility into your network traffic patterns helps you identify both legitimate usage and potential security concerns. This awareness allows you to make informed decisions about capacity planning, security improvements, and operational optimizations.

            Conclusion

            Open proxies present a serious risk in AWS environments, but you can effectively secure proxies with the right measures. By implementing strict access controls and additional security practices such as authentication, monitoring, and regular assessments, you can prevent misuse, protect your infrastructure, and maintain your IP address reputation.

            Taking proactive steps strengthens your own environment and supports the broader security of the internet ecosystem. Under the AWS shared responsibility model, you’re responsible for the configuration and maintenance of these security controls, while AWS provides the underlying secure infrastructure. By following the guidance in this article, you can build a robust security posture that protects your proxy infrastructure while supporting your legitimate business needs.

            If you have feedback about this post, submit comments in the Comments section below.

            Dodd Mitchell

            Dodd Mitchell

            Dodd is a member of the AWS Trust and Safety team in Virginia, supporting customers in navigating abuse, phishing, and content-related risks. He works closely with partners to strengthen response processes and build more resilient, trustworthy platforms.

            Announcing the ISO 31000:2018 Risk Management on AWS Compliance Guide

            ✇AWS Security Blog
            By: Jesse McMahan
            1 May 2026 at 22:01

            AWS Security Assurance Services is announcing the release of our latest compliance guide, ISO 31000:2018 Risk Management on AWS, which provides practical guidance for organizations establishing and operating a risk management program in AWS environments using ISO 31000:2018 principles.

            The guide explains how organizations can integrate AWS services into their risk management processes to support the core components of ISO 31000:2018, including establishing context and criteria, conducting risk assessments, implementing risk treatments, and enabling continuous monitoring and review. It also highlights how AWS security, automation, and monitoring capabilities can help customers identify areas for improvement and help enforce controls at large. The guide includes:

            • An overview of the ISO 31000:2018 risk management framework, including context and criteria, risk assessment, risk treatment, and monitoring and review. You will learn how to apply ISO 31000’s core principles within AWS environments and use AWS services for risk identification, detection, treatment, and monitoring.
            • Governance and risk treatment considerations aligned with the AWS Shared Responsibility Model. This includes strategies for risk avoidance, mitigation, transfer, and acceptance.

            By combining ISO 31000 risk management principles with AWS security services, organizations can build scalable, automated environments that help support continuous risk identification, proactive treatment, operational visibility, and ongoing compliance readiness.

            Download Available: ISO 31000:2018 Risk Management on AWS Compliance Guide

            For further assistance, contact AWS Security Assurance Services

            If you have feedback about this post, submit comments in the Comments section below.

            Jesse McMahan

            Jesse McMahan

            Jesse is a Sr. Security Assurance Consultant at AWS with over a decade of experience in information security, risk management, and compliance. He holds multiple industry and AWS certifications and leads security assessment and advisory engagements covering standards such as PCI DSS, NIST, SOC 2, HIPAA, and ISO 27001. A United States Marine Corps veteran, Jesse brings a disciplined, mission-focused approach to helping organizations align their security posture with regulatory and business objectives.

            Juan Rodriguez

            Juan Rodriguez

            Juan is a Security Assurance Consultant at AWS, where he works with Strategic Services and customers to assess and secure cloud environments against frameworks including CMMC, FedRAMP, GovRAMP, and NIST based practices. He holds his CMMC Certified Professional and AWS Certified Security – Specialty certifications. Juan pairs technical expertise with a research-driven mindset to help organizations strengthen and architect their security posture and align with federal and industry standards.

            Akanksha Chaturvedi

            Akanksha Chaturvedi

            Akanksha is a Senior Security Assurance Consultant with over 10 years of specialized experience in risk-based security assessments and regulatory compliance across highly regulated industries. Expert practitioner in HIPAA, PCI-DSS, GDPR, FedRAMP, and IRAP frameworks, with demonstrated success in architecting and deploying enterprise security programs from conception through full implementation. Known for delivering innovative, scalable solutions that strengthen security posture while streamlining operational processes aimed at reducing compliance overhead.

            Sana Rahman

            Sana Rahman

            Sana is a Senior Assurance Consultant with AWS Security Assurance Services, and has been a PCI DSS Qualified Security Assessor (QSA) for over a decade. She has extensive knowledge and experience in information security and governance, and deep compliance knowledge in both cloud and hybrid environments. She uses all of this to remove compliance roadblocks for AWS customers and provide guidance in their cloud journey.

            Mayur Jadhav

            Mayur Jadhav

            Mayur is a Senior Assurance Consultant at AWS with over a decade of experience in cloud security, governance, risk management, and compliance. He holds AWS Certified Solutions Architect and Zero Trust Certified Architect (ZTCA) certifications. His career spans leadership roles across organizations including Amazon, AWS, EY-Parthenon, and PwC, where he has advised senior executives on cybersecurity and compliance initiatives across healthcare, financial services, and technology sectors.

            Building with AI: Here's What No Briefing Will Tell You

            ✇Recorded Future
            30 April 2026 at 02:00
            • Executives making AI decisions without hands-on building experience have a comprehension gap that no briefing can close.
            • AI is rapidly eroding most traditional competitive moats, and proprietary data's real value now comes down to how long it would take a competitor to reconstruct it.
            • As AI equalizes development speed, the most valuable engineers are those with sharp judgment and companies need to actively protect the foundational skills that make that judgment possible

            Designing trust and safety into Amazon Bedrock powered applications

            ✇AWS Security Blog
            By: Victor Lungu
            29 April 2026 at 21:27

            Generative AI brings promising innovation, transforming how individuals and organizations approach everything from customer service to content creation and more. As AI continues to expand its capabilities, organizations are increasingly focused on how they can integrate the responsible AI concepts into the development lifecycle of their AI applications.

            Research from Accenture and Amazon Web Services (AWS) reveals compelling evidence for the business value of responsible AI practices, both internally within their organizations and externally to their users. Organizations that communicate a mature approach to responsible AI see an 82% improvement in employee trust in AI adoption, which directly leads to increased innovation. Additionally, companies that offer responsible AI-enabled products and services experience a 25% increase in customer loyalty and satisfaction.

            Understanding the core dimensions of responsible AI

            AWS identifies these key dimensions that form the backbone of responsible AI implementation:

            • Safety focuses on preventing harmful system output and misuse. This dimension focuses on steering AI systems to prioritize user and system safety.
            • Controllability focuses on mechanisms that monitor and steer AI system behavior. This dimension refers to the ability to manage, guide, and constrain AI systems to operate within specific parameters.
            • Fairness considers the impacts of AI on different groups of users.
            • Explainability focuses on understanding and evaluating system outputs.
            • Security and privacy focuses on making sure that data and models are appropriately obtained, used, and protected.
            • Veracity and robustness focuses on achieving correct system outputs, even with unexpected or adversarial inputs.
            • Governance makes sure that development, deployment, and management of AI systems align with ethical standards, legal requirements, and societal values.
            • Transparency focuses on understanding how AI systems make decisions, why the systems produce specific results, and what data the systems use.

            It’s a best practice to review and apply all these dimensions to your AI implementation. For more information, see Considerations for addressing the core dimensions of responsible AI for Amazon Bedrock applications.

            The responsible AI lifecycle

            When you implement AI systems, you should build safety into every phase of the AWS responsible AI lifecycle. The responsible AI lifecycle consists of the following three phases, each with distinct responsibility considerations for the safety dimension:

            1. In the design and development phases, thoroughly evaluate potential safety risks. Understand what you want your AI application to do, what you don’t want it to do, and what you want to prevent it from doing. You should build safety guardrails into your systems from the beginning and make sure that your development teams understand the capabilities and limits of your AI application.
            2. In the deployment phase, theory meets reality. During this phase, you should implement robust safety measures through multiple layers, from comprehensive user training to proactive monitoring and review processes. Every application, product, and feature must include clear safety protocols and user guidelines. You must think beyond the launch of an application and consider how to launch a holistic safety framework. This framework—which can contain steps such as red team testing—must protect your brand, users, and stakeholders.
            3. In the operations phase, it’s important to maintain vigilance. Safety, like security, isn’t something you set up once and then ignore. Safety requires continuous monitoring and adaptation. To catch potential safety issues early, you can implement real-time feedback mechanisms to conduct regular performance evaluations. You can also continuously monitor for shifts in how your application is used, or functions that could compromise safety. Because safety considerations and risks evolve as technology evolves, it’s crucial to understand that adjustments are necessary over time.

            For more information, see the Responsible use of AI guide.

            Abuse detection

            Foundation models in Amazon Bedrock are inherently designed with safety mechanisms to prevent harmful outputs. However, you can implement additional input safety systems in production environments to provide critical early detection capabilities to identify problematic content, users, or patterns.

            Note: Amazon Bedrock might implement automated abuse detection mechanisms to identify potential violations of the AWS Acceptable Use Policy (AUP) and Service Terms, including the Responsible AI Policy or a third-party model provider’s AUP.

            See the Amazon Bedrock abuse detection document for more information.

            AI abuse prevention tools and techniques

            To maintain trust in your AI services, preventative action is key, while also efficiently planning and managing development resources. Introduce observability and safety guardrails early in development to support long-term scalability and help identify potential issues before they affect your users. To begin this process, thoroughly scope your AI use case with the following actions:

            • Understand your users
            • Anticipate potential misuse scenarios
            • Define your risk tolerance

            This scope guides your development of a precise safety framework that addresses the specific risks of your AI implementation while you maintain expected performance. For this scope, you can use AWS specialized tools designed specifically to monitor and protect Amazon Bedrock applications.

            Using CloudWatch to monitor Amazon Bedrock

            Amazon CloudWatch provides essential visibility into AI system behavior and performance. When you configure comprehensive logging, you can capture important information across user segments and interaction types, such as the following:

            • Request volumes
            • Response latencies
            • Rejection rates
            • Content filtering triggers

            You can use this information to identify potential abuse patterns or unexpected behaviors before they affect operations. CloudWatch dashboards visualize metrics according to monitoring priorities, and automated alerts provide prompt notification when you exceed thresholds. This infrastructure transforms interaction data into actionable insights and supports continuous safety improvement.

            Note: By default, Amazon Bedrock logging is turned off. You must turn on logging for your application. To configure this, contact your account manager.

            Using Amazon Bedrock Guardrails to customize safeguards

            Amazon Bedrock Guardrails offers configurable protection mechanisms tailored to specific risk profiles and content policies. You can customize Bedrock Guardrails to match your application requirements, such as:

            • Define domain-relevant undesirable topics
            • Configure appropriate content filtering thresholds
            • Configure sensitive information detection and redaction parameters aligned with data policies

            Additionally, you can configure controls that prioritize accuracy and prevent hallucinations while maintaining creative flexibility based on your application needs. When you thoughtfully configure Guardrails, you can balance performance and safety according to your specific use case requirements and risk factors.

            The abuse response process

            As AI safety evolves and new risks emerge, abuse might still occur even if you implement safety mechanisms. If you receive an abuse report from the AWS Trust & Safety team, then complete the following steps to help effectively address the issue:

            1. Acknowledge receipt: Acknowledge the receipt of the abuse report within 24 hours. If your team is still conducting their investigation, then inform AWS that the investigation is ongoing. Provide the number of days expected to complete the investigation.
            2. Investigate the issue: Thoroughly investigate the issue, including examining the logs (if enabled), reviewing Amazon Bedrock inputs, and checking for unauthorized access. While AWS abuse reports include a small sample of prompt IDs for you to investigate, investigate usage of your Amazon Bedrock application. Check for patterns to see if there’s a systemic issue that’s leading to abuse.
            3. Take appropriate action: If appropriate, take action to implement fixes, update safeguards, address violating users, or redesign features. Consider if you need systemic or root-cause fixes, rather than addressing one abusive end user. An abuse incident by one user could indicate vulnerabilities in your safety mechanisms that can lead to continuous abuse.
            4. Report back to AWS Trust & Safety: Following your investigation and implementation of fixes, provide an update to AWS Trust & Safety on your findings and remediation steps. Be transparent about what happened and how you addressed the issue. If you think that no violation occurred, then provide context on how you came to this conclusion. Include examples of the prompts and your business use case where possible.

            Conclusion

            To learn more about safety and responsible AI development, explore AWS resources, including the Responsible AI portal and machine learning best practices documentation. These resources provide additional tools and frameworks to build safe, effective AI systems that drive innovation and maintain safety standards.

            Victor Lungu Victor Lungu
            Victor is a Trust & Safety AI Abuse Specialist at AWS, based in Dublin. Victor works across a broad range of AI safety domains including content safety and emerging AI risks

            What the March 2026 Threat Technique Catalog update means for your AWS environment

            ✇AWS Security Blog
            By: Shannon Brazil
            28 April 2026 at 21:01

            The AWS Customer Incident Response Team (AWS CIRT) regularly encounters patterns that repeat across their engagements when helping customers respond to security incidents. We’re passionate about making sure that information is widely accessible so that everyone can improve their security posture and their organization’s resilience to disruption. The primary method we use to share this information is the Threat Technique Catalog for AWS (TTC). The latest update to the catalog for March 2026 addresses identity, persistence, infrastructure destruction, and privilege escalation. Each new entry reflects something we’ve encountered in practice, and each provides straightforward mitigations. This post breaks down what changed, why it matters, and what you can do about it today.

            What we’re seeing

            Based on recent observations, we’ve added three new entries to the TTC.

            Cognito refresh token abuse: The quiet persistence mechanism

            Amazon Cognito refresh tokens are designed for convenience. They let applications obtain new access and ID tokens without requiring users to re-authenticate. The default lifetime is 30 days and is configurable up to 10 years. Cognito provides the flexibility to address a wide range of use cases, however the AWS CIRT has seen this lifetime window used by threat actors in an unauthorized way to maintain persistence by refreshing credentials.

            When a threat actor obtains a valid refresh token—through credential theft, compromised client-side storage, or elevated permissions—they can call cognito-idp:GetTokensFromRefreshToken to silently generate fresh tokens. The legitimate user’s session continues normally because their application independently refreshes tokens as needed—the threat actor’s refresh calls don’t invalidate the user’s token. This creates a parallel, persistent foothold that’s invisible to the user. In environments where refresh token rotation isn’t enabled, the same token can be reused indefinitely within its validity window.

            This method of gaining persistent access is often overlooked by response teams who were confident that the initial compromise was contained, only to discover ongoing unauthorized access weeks later through a refresh token they didn’t know existed.

            Enabling refresh token rotation and reducing the lifetime of tokens can help mitigate this risk. Dive deeper in the TTC (T1098.A006).

            AMI image deletion: Targeting recovery capabilities

            Amazon Machine Images (AMI) are a core part of many solutions and foundational to disaster recovery. They often contain the operating system, application configurations, and everything needed to rebuild your infrastructure. Threat actors know this, and we’re seeing ec2:DeregisterImage used to make it more difficult to recover from an incident.

            By default, when an AMI is deregistered, it’s gone. Recycle Bin retention rules can allow the recovery of the AMI, but if you haven’t explicitly enabled that functionality, there’s no way to undo the deregister action. Working with customers, we’ve seen cases where the impact of this action goes beyond the immediate loss because the threat actors have also removed the golden images the teams planned to restore from.

            The TTC has more information about how to detect and mitigate this technique, including how to enable Recycle Bin retention rules for key AMIs (T1485.A002).

            Additional cloud roles: The trust policy blind spot

            We’ve updated T1098.003: Additional Cloud Roles to now include UpdateAssumeRolePolicy as a tracked API call. We’ve seen an increase in the use of this call to avoid detections set to flag new role creation (iam:CreateRole). By modifying the trust policy of an existing role, a threat actor with sufficient permissions can use UpdateAssumeRolePolicy to subtly add an external account or an identity they control. No new roles appear. No new policies are created. The existing role simply trusts a new principal which the threat actor can assume.

            This persistence and privilege escalation technique blends into the volume of normal AWS Identity and Access Management (IAM) operations. It’s especially effective in environments with a large number of roles where trust policy changes aren’t actively monitored.

            The current trend

            A common thread runs through all three of these updates: threat actors are using subtle, default, or unexpected behaviors to sidestep detection. Refresh tokens working as designed. AMI deregistration completing without guardrails. Trust policies being modified through legitimate API calls. These actions might not trigger alarms in most environments because they look like normal operations.

            This is a shift worth paying attention to. Rather than relying on novel exploits or zero-days, the techniques we’re cataloging reflect threat actors who understand how cloud services work and use that knowledge to hide in plain sight. The implication for security teams is clear: prevention and detection strategies need to mature beyond monitoring for obviously malicious actions. Customers need to be watching for legitimate actions happening in illegitimate context—such as the right API call, made by the wrong principal, at the wrong time.

            The Threat Technique Catalogue for AWS is designed to help with exactly this. Each technique entry includes detection guidance and mitigations specific to AWS environments. We encourage teams to review the relevant entries and assess whether their current monitoring would catch these patterns:

            • T1098.A006: Cognito Refresh Token Abuse: Are you monitoring for cognito-idp:GetTokensFromRefreshToken from unexpected sources? Is refresh token rotation enabled?
            • T1485.A002: AMI Image Deletion: Do you have Recycle Bin retention rules protecting your critical AMIs? Would you know if a production AMI was deregistered outside a maintenance window?
            • T1098.003: Additional Cloud Roles: Are trust policy modifications tracked and alerted on? Could an external account be added to an existing role without anyone noticing?

            Each of these techniques leaves traces in AWS CloudTrail, and the TTC provides specific guidance on what to watch for and how to respond.

            Looking ahead

            The Threat Technique Catalog for AWS exists because we believe the patterns we observe during security engagements shouldn’t stay behind closed doors. When we see techniques repeating across customers, the most effective thing we can do is document them and make that knowledge available so you can act on it before you’re in the middle of an incident.

            This March update adds three new entries, and the catalog will continue to evolve. Our team regularly updates it based on what we’re seeing in the real world when helping customers respond to security events. We encourage security teams to review the catalog regularly, incorporate its techniques into threat modeling exercises, and use it as a shared vocabulary for discussing cloud-specific threats.

            Explore the full catalog: Threat Technique Catalog for AWS

            Additional resources

            If you have feedback about this post, submit comments in the Comments section below.

            Shannon Brazil

            Shannon Brazil

            Shannon is a security engineer on the AWS Customer Incident Response Team (CIRT), specializing in digital forensics and cloud security investigations. Known in the community as 4n6lady, she is passionate about security education and mentoring the next generation of defenders.

            Cydney Stude

            Cydney Stude

            Cydney is a security engineer specializing in threat intelligence and incident response at AWS. Cydney works on the ground in incident response and is passionate about turning observables into security outcomes. Cydney is an author and maintainer of the Threat Technique Catalog for AWS.

            Access control with IAM Identity Center session tags

            ✇AWS Security Blog
            By: Rashmi Iyer
            28 April 2026 at 18:33

            As organizations expand their Amazon Web Services (AWS) footprint, managing secure, scalable, and cost-efficient access across multiple accounts becomes increasingly important. AWS IAM Identity Center offers a centralized, unified solution for managing workforce access to AWS accounts. It simplifies authentication, enhances security, and provides a seamless user sign-in experience to AWS services across diverse environments.

            By combining IAM Identity Center permission sets with session tags, organizations can unlock powerful capabilities for fine-grained access control and resource optimization. You can use session tags to pass dynamic attributes from your external identity provider into AWS, enabling more context-aware permissions and better cost visibility. This integration makes it possible to use advanced AWS features such as AWS Glue usage profiles and AWS Systems Manager Session Manager run as to enforce fine-grained access control, so that administrators can dynamically map permissions and runtime configurations based on user attributes passed during federated access.

            In this post, I demonstrate how session tags derived from directory group attributes in Microsoft Entra ID can deliver functionality equivalent to AWS Identity and Access Management (IAM) role tags. Using role tags, you can implement attribute-based access control (ABAC) using IAM Identity Center, while maintaining centralized and efficient access management. To demonstrate this, you can configure an AWS Glue usage profile, as described in Introducing AWS Glue usage profiles for flexible cost control, where session tags can be passed through Identity Center and an external identity provider like Microsoft Entra ID. This approach is extensible to other AWS services such as AWS Systems Manager Session Manager (run as) and can also be used with other identity providers.

            User authentication and IAM Identity Center Federation flow

            The following figure shows the architecture and workflow of the solution.

            Figure 1 – User authentication and federation flow between Microsoft Entra and AWS

            Figure 1 – User authentication and federation flow between Microsoft Entra and AWS

            The user authentication and federation flow includes the following steps:

            1. User accesses application using a browser.
            2. The enterprise application (configured in Azure) initiates authentication.
            3. Microsoft Entra ID handles sign-in.
            4. Users and groups are managed in Entra ID.
            5. A SAML trust is established between Entra ID and IAM Identity Center.
            6. SCIM provisioning syncs users and groups from Entra ID to AWS.
            7. Synced users and groups appear in Identity Center.
            8. Session tags are passed during SAML authentication.
              • Entra ID can send user attributes (department, role, cost center, project ID, and so on) as SAML attributes.
              • Identity Center consumes these as session tags, which are used for fine-grained access control and attribute-based access control inside AWS.
            9. Admins define permission sets for users and groups in Identity Center.
            10. Users get federated access to AWS using their Entra ID credentials.
            11. Users sign in through AWS Management Console or AWS Command Line Interface (AWS CLI) using those permissions.
            12. Access is granted to specific AWS accounts under AWS Organizations.

            Prerequisites

            To follow the steps in this post, you need the following prerequisites:

            1. An organization instance of IAM Identity Center enabled.
            2. A Microsoft Entra ID tenant. For more information, see Quickstart: Create a new tenant in Microsoft Entra ID.
            3. Access to an external identity provider such as Microsoft Entra ID to federate users into AWS. You can enable federated access between Microsoft Entra ID and IAM Identity Center by completing the steps in Configure SAML and SCIM with Microsoft Entra ID and IAM Identity Center. They include configuring SAML and SCIM integration between the two systems, testing the SAML connection to help ensure authentication is functioning correctly, and enabling SCIM synchronization to automate user and group provisioning.

            Solution implementation

            With the prerequisites in place, you’re ready to configure access control through IAM Identity center tags by using the following steps.

            1. Create an AWS Glue usage profile as described in Introducing AWS Glue usage profiles for flexible cost control in Create an AWS Glue usage profile. For the purposes of this post, create a profile named developer.
              1. On the AWS Management Console for AWS Glue, choose Cost management in the navigation pane.
              2. Choose Create usage profile.
              3. For Usage profile name, enter developer.
              4. Under Customize configurations for jobs, for Number of workers, for Default, enter 20.
              5. For Default worker type, select G.1X.
              6. For Allowed worker types, select G.1X, G.2X, G.4X, and G.8X.
              7. For Customize configurations for sessions, configure the same values.
              8. Choose Create usage profile.

              Figure 2 – Glue usage profile creation on the console

              Figure 2 – Glue usage profile creation on the console

            2. Create a custom permission set instead of using predefined ones. Attach the following AWS Managed Policies to the custom permission set:
              • AWSGlueConsoleFullAccess
              • IAMReadOnlyAccess

              Note: For fine-grained access control, you can create custom permission sets by combining AWS managed, customer managed, and inline policies in IAM. In this post, you use AWS managed policies with intentionally broad permissions for simplicity. In production, always follow the principles of least privilege and scope permissions appropriately.

              By default, when you create a permission set, the permission set isn’t provisioned (used in any AWS accounts). To provision a permission set in an AWS account, you must assign IAM Identity Center access to users or groups in the account and then apply the permission set to those users and groups. For more information, see Assign user or group access to AWS accounts.

            3. Configure user attributes in Microsoft Entra ID for access control in IAM Identity Center as described in Step 5 of Configure SAML and SCIM with Microsoft Entra ID and IAM Identity Center to set up ABAC. Add claim conditions for attribute mapping based on Entra ID group membership. Assign the developer value for users in a corresponding group. This enables logic such as Users in this group receive this profile or All users receive this profile. When using an AWS Glue profile and when making API calls to create AWS Glue resources, admins need to tag the user or role with glue:UsageProfile as the key and the profile name as the value.
            4. Next, sign in to the enterprise application that you created in the previous step, which has SCIM and SAML connections set up to IAM Identity Center:
              1. Sign in to Azure.
              2. Choose Enterprise applications.
              3. Select the application that you created
                Figure 3 – An enterprise application created in Microsoft Entra ID

                Figure 3 – An enterprise application created in Microsoft Entra ID

            5. When you’re signed in to your application, select Manage and then Single sign-on in the navigation pane, then select Attributes & Claims.
              Figure 4 – Attributes & Claims section in Microsoft Entra ID

              Figure 4 – Attributes & Claims section in Microsoft Entra ID

            6. Configure the key value pair that will used as session tags by selecting Add new claim.
              Figure 5 – Configuring attributes by adding a new claim

              Figure 5 – Configuring attributes by adding a new claim

            7. For Name, enter AccessControl:<AttributeName>. Replace <AttributeName> with the name of the attribute you are expecting in IAM Identity Center. For this example, use AccessControl:glue:UsageProfile.
            8. In Claim conditions set the following:
              • User type, select Members
              • Source, select Attribute.
              • Value, enter developer (without quotation marks).

              Figure 6 – Attribute claim addition in Microsoft Entra using group membership

              Figure 6 – Attribute claim addition in Microsoft Entra using group membership

            It’s important to note that the tags are being assigned based on group membership in Microsoft Entra ID. This approach lets you manage access and configuration dynamically without needing to set tags individually for each user. By assigning the tag to a Microsoft Entra ID group, anyone signing in to IAM Identity Center and who is in that group will automatically have the tag value applied to their session.

            Test the solution

            Now that the required configuration is complete, test the setup using the developer usage profile created as part of the Solution implementation section. Sign in as your user through Microsoft Entra ID using https://myapps.microsoft.com/ and verify the job creation using the following steps mentioned.

            To verify successful job creation:

            1. Open the AWS Glue console using the developer usage profile.
            2. In the navigation pane, choose ETL jobs.
            3. Select Script editor, then choose Create script.
            4. Create a new job using the values you want to validate.

            The green banner at the top of the screen should say Successfully updated job.

            Figure 7 – Successful AWS Glue job creation with configured parameters for the <em>developer</em> usage profile

            Figure 7 – Successful AWS Glue job creation with configured parameters for the developer usage profile

            Validation using AWS CloudTrail

            Examine the AssumeRoleWithSAML event using AWS Cloudtrail. Use the following steps to verify the sequence of events.

            1. Navigate to the CloudTrail console.
            2. Select Event history.
            3. In the Lookup attributes dropdown, select Event name.
            4. Set the event name to AssumeRoleWithSAML.
            5. Open a relevant event and inspect the requestParameters section.
            6. Confirm that the expected session tags appear under PrincipalTags.
            Figure 8 – ABAC tags passed during the role assumption

            Figure 8 – ABAC tags passed during the role assumption

            Using session tags for other use cases

            The concepts discussed in this post can be extended to configure AWS Systems Manager Session Manager Run As support for federated users using session tags. By default, Session Manager launches sessions using a system-generated ssm-user account. For Linux instances, you can optionally configure sessions to run as a specific OS-level user through Session Manager preferences. You can configure your identity provider to pass the user attribute (AccessControl: SSMSessionRunAs and name of an OS user account for the key value during federation and the session will be tagged using the attribute value.

            Clean up

            To avoid incurring future charges, delete any resources created during this walkthrough if they’re no longer needed:

            1. Remove the IAM Identity Center instance and clean up the associated enterprise application in Microsoft Entra.
            2. Delete the AWS Glue usage profile.
            3. Remove any other AWS resources you provisioned for testing the solution.

            Conclusion

            In this post, you learned how to federate access to AWS using AWS IAM Identity Center and SAML 2.0 identity providers like Microsoft Entra ID, enabling a secure, scalable, and centralized approach to managing user access across multiple AWS accounts. By using permission sets, reserved IAM roles, and session tags, organizations can implement fine-grained ABAC without the complexity of managing individual IAM users or static roles.

            As cloud environments become more complex, adopting modern identity federation and ABAC through IAM Identity Center helps security teams maintain control while providing users with seamless, context-aware access to the resources they need.

            Resources

            If you have feedback about this post, submit comments in the Comments section below.

            Rashmi Iyer

            Rashmi Iyer

            Rashmi is a Senior Solutions Architect at AWS, supporting financial services enterprises in building secure, resilient, and scalable cloud architectures while ensuring compliance with industry best practices. With over 15 years of experience in the private telco cloud, she has designed and architected complex telecom solutions, specializing in the packet core domain, the backbone of mobile data networks.

            The Money Mule Solution: What Every Scam Has in Common

            ✇Recorded Future
            28 April 2026 at 02:00
            • Scams are a $450B–$1T global problem, and unlike card fraud, they don't require a breach; just convincing a victim to send money themselves.
            • The mule account is the most stable target: every scam needs an exit point, and intelligence gathered before a transaction occurs is more actionable than behavioral monitoring after the fact.
            • CYBERA's approach uses agentic personas to engage active scammers and extract verified mule account details, confirmed intelligence, not probabilistic scoring.
            • Regulatory pressure is accelerating: the UK already mandates APP fraud reimbursement, and the US, Canada, and Australia are following, raising the stakes for institutions that don't act proactively.

            Lazarus Doesn't Need AGI

            ✇Recorded Future
            28 April 2026 at 02:00

            Last week’s reporting on unauthorized access to Claude Mythos reads as an AI security story. It is also, structurally, a North Korea (DPRK) story. Even if the current suspects turn out to be Discord hobbyists.

            Mythos was meant to be contained. Within hours of the public Project Glasswing announcement, a third-party contractor environment became the access vector. Not because Anthropic did something wrong. Because controlled release, at the scale modern enterprise software operates, is a goal rather than a guarantee.

            The interesting question isn’t who got in this time. It’s who gets in next, and their economics.

            What happened?

            The group accessed Mythos the same day it was announced, guessing the endpoint based on Anthropic’s naming conventions for prior models. The vector was an individual employed at a third-party contractor, not Anthropic’s core infrastructure. Source characterizations point to a research community “not wreaking havoc” with the model.

            The misread

            If the coverage only centers on Anthropic’s security posture or the AI safety debate, we’re missing an important angle.

            The structural signal is that any preview or controlled-access model release has porous boundaries by design. Access controls on paper (contracts, NDAs, approved vendor lists) differ from those in practice. Every partner brings their own contractors, endpoints, and people with legitimate credentials and uneven security hygiene. That is the real control surface, not the cryptographic perimeter around the model itself. Which makes this a supply chain problem that happens to be about AI, not an AI problem that happens to involve vendors.

            The blind spot

            AI policy discourse is locked on US versus China, including energy, chip controls, export rules, sovereign AI posture, and who wins the race.

            Structurally missing from the larger conversation is the one state actor whose entire foreign currency revenue stream is cyber-enabled theft. DPRK doesn’t need to win any race. They need a 20-30% productivity gain in existing operations.

            The pipeline is documented. Insikt Group’s Crypto Country estimated that regime-linked cryptocurrency theft reached roughly $3 billion through 2023. The Multilateral Sanctions Monitoring Team (successor to the UN Panel of Experts after Russia’s 2024 veto) has since done the harder primary work. MSMT’s October 2025 report documents $2.8 billion stolen from cryptocurrency companies between January 2024 and September 2025 across more than 40 heists, with proceeds explicitly tied to WMD and ballistic missile program funding. The State Department updated the tally in January 2026: another $400 million stolen in the three months since publication, bringing the 2025 totals above $2 billion.

            Every successful crypto exchange intrusion ends up on a launch pad.

            Why North Korea wants the next model

            Crypto exchange intrusions are labor-intensive at every phase. Recon, social engineering at scale (fake developer personas on GitHub and LinkedIn, spear-phishing of individual engineers at wallet providers), credential harvesting, post-exploit lateral movement, key extraction, and laundering.

            Agentic capability compresses the cycle to include the same operator-hours, more successful intrusions, and more stolen $$$ per operator.

            Bybit is an easy example. The FBI attributed approximately $1.5 billion in stolen virtual assets to TraderTraitor in February 2025. The intrusion chain ran months of patient targeting against a single Safe{Wallet} system administrator via phishing, followed by post-compromise operational patience. These types of attacks are expensive, time-intensive, and still extraordinarily productive.

            Lazarus and TraderTraitor don’t need AGI. They need the productivity lift that turns a junior operator into a senior one and shaves weeks off the planning phase. It doesn’t have to be Mythos specifically. Any comparable capability through a comparable vector does the job.

            Better tools mean more successful intrusions. More successful intrusions mean more stolen crypto. More stolen crypto means more missiles.

            Three access patterns

            Three different tradecraft patterns keep getting conflated in media coverage. They are not the same TTP, and treating them as one weakens the response on all three.

            1. Contractor misuse. A legitimately credentialed employee at a third-party vendor uses their access for unauthorized purposes. This is the Mythos story. The credentials and access are real, though the intent is variable. Defenses (easy to say, hard to do well): telemetry, behavioral monitoring, and least-privilege scoping at the vendor tier.

            2. Fraudulent hiring. An adversary places its own operatives inside the target through stolen or synthetic identities, often via remote IT contracting. This is the DPRK IT worker scheme. Insikt’s Inside the Scam documents PurpleBravo’s infrastructure: front companies in China spoofing legitimate IT firms, and a malware ecosystem (BeaverTail, InvisibleFerret, OtterCookie) targeting the cryptocurrency industry. The credentials are real, but the identities are fake. Defenses: identity verification at hire (in-person interviews to avoid AI tricks), ongoing personnel vetting, geographic and behavioral baselining.

            3. Supply chain compromise. A trusted vendor’s systems get breached, and the attacker uses that vendor’s legitimate distribution channel to reach the real target. TeamPCP’s March 2026 LiteLLM compromise hit the AI toolchain directly, poisoning Trivy (a defensive security scanner) to reach a package with 95 million monthly downloads. Defenses: build-pipeline integrity, dependency monitoring, signed artifacts.

            These three attack vectors converge on the same truth. Any preview or limited-release AI program that depends on third parties is exposed to all three vectors simultaneously. DPRK is the actor most motivated across the full triangle because the revenue case is specific, measurable, and directly beneficial for the regime. They are incentivized to be “AI native.”

            So what?

            In the security industry, we need to stop thinking about AI access as purely a lab problem when it’s also a sanctions problem. The great-power competition framing obscures the actor already online, with a rich history of monetizing cyber heists to fund missiles.

            “Limited release” is a wonderful bumper sticker. The AI reality, from a threat-modeling perspective, is a countdown to turbo-charging adversarial capabilities.

            Now what?

            The honest conversation is that perimeter-style AI “controlled access” is less effective against State-sponsored adversaries. A productive security path is a distinct preview infrastructure, aggressive telemetry, canaries, and third-party access tied to personnel-level vetting rather than contractual attestation. (Guessable endpoints should be the first thing dead.)

            Crypto exchanges and custodians: your threat model needs to anticipate what Lazarus can do 3 to 6 months from now, not what they did last quarter. Assume they improve faster than your defenses do.

            Policymakers: DPRK is a first-class entity in AI access governance. The Multilateral Sanctions Monitoring Team framework already documents cyber-enabled sanctions evasion thoroughly. What it doesn’t yet do is name AI capability access as a sanctions-relevant category. Dual-use export controls have governed the transfer of semiconductor and missile technology for decades. AI capability is the obvious next category.

            Corporate CISOs (outside the AI-lab orbit): your third-party contractor environments are now inside the AI capability threat surface, whether you opted in or not. Inventory accordingly.

            Close

            Mythos is a preview of an access pattern. Any actor whose business model is stealing money to build weapons will find the third-party seam. This time, it was hobbyists. DPRK has spent two decades proving why nonproliferation is the right frame here.

            Optimize security operations through an AWS Security Hub POC

            ✇AWS Security Blog
            By: Kyle Shields
            27 April 2026 at 20:55

            April 27, 2026: This post was first published in September 2025 when the enhanced AWS Security Hub was in public preview. It has since been updated to reflect the general availability of Security Hub. This revision also provides a more detailed, step-by-step framework for planning your POC.

            AWS Security Hub prioritizes your critical security issues and helps you respond at scale to protect your environment. The service sharpens findings through aggregation, correlation, and enrichment of AWS native security signals into actionable insights, enabling faster and more efficient response times. You can use these capabilities to gain visibility across your cloud environment through centralized management in a unified cloud security solution. Security Hub creates a cloud-native application protection platform (CNAPP) and through the AWS free trial, you can create a comprehensive proof of concept (POC) evaluation without significant upfront investment in time or resources.

            In this blog post, we guide you through planning and implementation POC for Security Hub to assess the implementation, functionality, cost estimate, and value of Security Hub in your environment. We walk you through the following steps:

            1. Understand the value of Security Hub
            2. Determine success criteria for the POC
            3. Define Security Hub configuration
            4. Prepare for deployment
            5. Enable Security Hub
            6. Validate deployment

            Understand the value of Security Hub

            Figure1: AWS Security Hub overview

            Figure 1: AWS Security Hub overview

            Figure 1 provides a visualization of how Security Hub unifies signals from multiple AWS security services, partner solutions capabilities. The signals, which are ingested by Security Hub from multiple AWS security services and curated partner solutions include:

            At its core, Security Hub provides four key capabilities in one unified solution:

            1. Unified security operations: Security Hub delivers a unified security operations experience, bringing your security signals into a single consolidated view and avoiding the need to switch between multiple security tools. This provides comprehensive visibility across your entire estate, including AWS, multi-cloud, and on-premises, so your security teams can efficiently detect, prioritize, and respond to potential security risks.
            2. Intelligent prioritization helps focus on what matters most: Security Hub helps you identify and prioritize critical security risks that might be missed when viewing findings in isolation. Security findings are correlated by analyzing resource relationships and signals from AWS security services and capabilities.
            3. Actionable insights guide security teams on next steps: Gain actionable insights through advanced analytics to transform correlated findings into clear, prioritized insights that highlight the most critical security risks in your environment. You can quickly understand potential impacts, visualize relationships, and identify which security issues pose the greatest risk to critical resources.
            4. Streamlined security response and automation capabilities: Security Hub enhances your security operations by enabling streamlined response capabilities. It seamlessly integrates with your existing ticketing systems to help facilitate efficient incident management.

            With this integrated approach your security team can:

            • Investigate critical risks that need immediate attention from a single pane of glass
            • Monitor security trends and attack surface across your environments
            • Fix what really matters across the entire attack chain and path
            • Automate responses to streamline remediation

            Understand the Open Cybersecurity Schema Framework

            Security Hub uses the Open Cybersecurity Schema Framework (OCSF) to help standardize security data and analysis and enable better integration between security tools. This standardization helps simplify how security findings are structured and analyzed across your environment. This standardized data model enables seamless integration and data exchange across your security tooling, providing normalized and consistent data formats. When implementing your Security Hub POC, make sure that you’re familiar with the OCSF specifications Security Hub uses.

            Additionally, confirm that any analytics or security information and event management (SIEM) tools you plan to integrate with support the OCSF data format to maximize the value of the consolidated security insights provided by Security Hub.

            Determine success criteria

            Establishing success criteria helps benchmark the outcomes of the POC with the goals of the business. Some example criteria and key performance indicators (KPI) include:

            • Alert consolidation metrics: Determine what resources you’re currently using to correlate security events and signals to understand their relationship. Review the process and note if it’s completed outside of AWS or through a SIEM. By setting a benchmark to reduce correlation overhead you can significantly improve efficiency and accelerate security investigations and posture improvement.
            • Response time improvements: Reducing your time to detect, investigate, and resolve security events and improve security posture is essential to streamlined security operations. Security Hub provides visualizations for potential attack paths that adversaries could use to exploit resources and helps assess the potential blast radius.
              • Reduced mean time to detect (MTTD) security incidents.
              • Reduced mean time to response (MTTR) for critical findings.
              • Reduced time to identify potentially affected resources in blast radius.
              • Increased accuracy of attack path analysis.
              • Number of controls implemented based on attack path insights (post investigation).
            • Automation capabilities: Having response playbooks as part of your incident management and response plan helps ensure comprehensive investigations lead to improved security posture. Review your automation capabilities to see if portions of or entire playbooks can be automated.
              • Potentially increased percentage of security findings automatically routed to the correct teams by using Jira Cloud, ServiceNow, or a third-party tool.
              • Reduced average time from detection to ticket creation.
            • Severity and risk classification: Review your organization’s inventory of assets to determine if it’s complete and if you can use telemetry to determine the severity level and associated risks.
              • Reduced time to identify critical resources and service coverage gaps affected by new vulnerabilities, threats, and misconfigurations.
              • Faster and more accurate severity label and risk calculation of findings.
              • Reduced time to identify service gap coverage.

            After establishing your success criteria, it’s essential to evaluate organizational readiness and potential constraints that might impact your POC implementation. Begin by conducting a comprehensive assessment of your current environment: Determine if the foundational security services (GuardDuty, Amazon Inspector, Security Hub CSPM, and Macie) are enabled across your accounts, and identify your critical workloads and if there are any excessive attack surfaces.

            Review your success criteria to make sure that your goals are realistic given your timeframe and potential constraints that are specific to your organization. For example:

            • Do you have full control over the configuration of AWS services that are deployed in an organization?
            • Do you have resources that can dedicate time to implement and test?
            • Is this time convenient for relevant stakeholders to evaluate the service?

            Maximize your POC value through service activation

            To get the most comprehensive evaluation of the capabilities of Security Hub, coordinate the activation of underlying security services to optimize the overlapping trial periods available at no additional cost. The following is a list of the underlying security services, and their free trial length:

            • Security Hub: 30-day trial (essential plan capabilities)
            • GuardDuty: 30-day trial (covers most protection plans except GuardDuty Malware Protection)
            • Security Hub CSPM: 30-day trial
            • Macie: 30-day trial
            • Amazon Inspector: 15-day trial

            Consider enabling these services simultaneously so that you have at least two weeks of overlapping coverage to evaluate the full correlation and risk prioritization capabilities of Security Hub across each service. Optionally, if you want to conduct a POC with minimal configuration because of limitations, you can enable only Security Hub CSPM and Amazon Inspector during the initial POC phase to properly assess the results and data.

            Note: Document your activation dates and trial expiration dates carefully. Create calendar reminders for trial end dates and schedule your key POC evaluation milestones to occur while services are active. This will help make sure that you can thoroughly assess the unified security operations capabilities of Security Hub when services are running at full capacity.

            If you already have one or more of these underlying services enabled, you can proceed to enable the new Security Hub. To fully use the new Security Hub capabilities, particularly the exposure findings feature, specific service dependencies must be met, both Security Hub CSPM and Amazon Inspector are essential because they provide the telemetry needed for the Security Hub correlation engine and exposure findings. The combination enables Security Hub to deliver comprehensive risk analysis and prioritization by correlating configuration risks with runtime vulnerabilities. If you have other security services already enabled (such as GuardDuty or Macie), you can maintain these existing services while enabling Security Hub, and it will automatically begin incorporating their findings into its consolidated view, enhancing your overall security posture visualization.

            Define your Security Hub configuration

            After your success criteria have been established, you’re ready to plan your configuration. Some important decisions include:

            • Select a delegated administrator: From the AWS Organizations management account, you can set a delegated administrator for your organization. As a best practice, we recommend using the same delegated administrator across security services for consistent governance and according to our AWS Security Reference Architecture (AWS SRA).
            • Select accounts in scope: Define accounts you want to have Security Hub enabled for.
            • Define AWS Regions: Determine Regional restrictions or considerations.
            • Determine AWS service integrations: In addition to the core security capabilities of posture management and vulnerability management, Security Hub integrates signals from other AWS security services such as GuardDuty and Macie.
            • Define third-party integrations:
              • For ticketing, Security Hub integrates with popular service management systems such as Atlassian’s Jira Service Management Cloud and ServiceNow.
              • Partners who already support or intend to support the OCSF schema to receive findings from Security Hub include companies such as Arctic Wolf, CrowdStrike, DataBee, Datadog, DTEX Systems, Dynatrace, Fortinet, IBM, Netskope, Orca Security, Palo Alto Neworks, Rapid7, Securonix, SentinelOne, Sophos, Splunk, Sumo Logic, Tines, Trellix, Wiz, and Zscaler.
              • Service partners such as Accenture, Caylent, Deloitte, IBM, and Optiv can help you adopt Security Hub and the OCSF schema.
            • Use the Security Hub cost estimator: Use the Security Hub Cost Estimation Tool for a pre-enablement cost estimate based on your current spend on Amazon Inspector, Security Hub CSPM, and GuardDuty.

            Prepare for deployment

            After determining your success criteria and Security Hub configuration, identify stakeholders, desired state, and timeframe. Prepare for deployment by completing:

            • Project plan and timeline: Develop a project plan with defined success criteria, scope boundaries, key milestones, and realistic implementation timelines. Suggested timeline of events:
              • Before enablement:
                • Validate core security service configuration for GuardDuty, Amazon Inspector, Security Hub CSPM, and Macie
                • Request approvals for free trial from appropriate stakeholders
              • Day 0 – Enable the service, become comfortable with the Security Hub layout and begin training security personnel
              • Week 1 – Validate desired coverage of threat detection, vulnerability management, and posture management across accounts and Regions
              • Week 2 – Connect to IT service management (ITSM) tools and begin creating automations for critical workloads and resources
              • Week 3 – Execute a tabletop exercise in response to a selected exposure finding
              • Week 4 – Analyze trends of threats and exposures from day 1 through week 4
            • Identify stakeholders: Identify CISO, information security teams, SOC personnel, incident response teams, security engineers, finance, legal, compliance, external MSSPs, and business unit representatives.
            • Develop a RACI matric: Create a detailed RACI chart defining roles and responsibilities across the incident response lifecycle, facilitating accountability and proper communication channels.
            • Configure management account access: Secure authorization to delegate administrative access. For more information, see Permissions required to designate a delegated Security Hub administrator account.
            • Set up IAM roles and permissions: Use AWS Identity and Access Management (IAM) roles to implement role-based access controls aligned with the RACI chart, including case management, escalation, and read-only roles using AWS managed policies. For more information, see AWS Managed Policies

            Enable Security Hub

            AWS security services integrate with AWS Organizations to help you centrally manage Security Hub.

            1. If you haven’t already done so, enable Security Hub CSPM and Amazon Inspector at a minimum. Also enable any other AWS security services that you want to integrate with Security Hub.
            2. Enable Security Hub for your organization from the organization management account.
            3. If setting a delegated administrator for Security Hub, see Setting a delegated administrator account in Security Hub from the management account.

              Note: As a best practice, we recommend using the same delegated administrator across security services for consistent governance.

            4. Sign in to the delegated administrator with an IAM policy that gives you permission to enable and disable member accounts. With this policy, you will have granular control to decide what Regions you want enabled.
            5. Configure Security Hub plans for deployment. Security Hub comes with the Essentials, Threat Analytics, and Extended plans.
            6. Configure third-party integrations to create incidents or issues for Security Hub findings.

            Note: After you enable Security Hub, exposure findings in your environment are created and analyzed immediately. However, it can take up to 6 hours to receive an exposure finding for a resource.

            Validate deployment

            The final step is to confirm that Security Hub is configured correctly and to evaluate the solution against your success criteria.

            • Validate policy: Verify that you have the correct permissions to manage member accounts and Regional restrictions are configured correctly.
            • Validate integrations: Verify that tickets with ServiceNow or Jira Cloud are working correctly by signing in to the AWS Management Console for Security hub and choosing Inventory in the navigation pane. Select Findings and verify there is a ticket ID in your finding.
            • Assess success criteria: Determine if you achieved the success criteria that you defined at the beginning of the project.

            Conclusion

            In this post, we showed you how to plan and implement an effective Security Hub POC. You learned how to do so through phases, including defining success criteria, configuring Security Hub, and validating that Security Hub meets your business needs. Take advantage of the trial periods to maximize your testing window without incurring significant costs. Throughout the POC, maintain focus on your predefined success criteria while remaining open to unexpected benefits or challenges that might arise. Maintain open communication with your AWS account team to address any questions or concerns to help you get the most out of your Security Hub POC experience.

            Additional resources

            If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

            Kyle Shields

            Kyle Shields

            Kyle is a Security Specialist Solutions Architect focused on threat detection and incident response at AWS. Today, he’s focused on helping enterprise AWS customers adopt and operationalize AWS Security Incident Response and improve their security posture.

            Ahmed Adekunle

            Ahmed is a Security Specialist Solutions Architect focused on detection and response services at AWS. Before AWS, his background was in business process management and AWS technology consulting, helping customers use cloud technology to transform their business. Outside of work, Ahmed enjoys playing soccer, supporting less privileged activities, traveling, and eating spicy food, specifically African cuisine.

            Author

            Marshall Jones

            Marshall is a Worldwide Security Specialist Solutions Architect at AWS. His background is in AWS consulting and security architecture and focused on a variety of security domains including edge, threat detection, and compliance. Today, he’s focused on helping enterprise AWS customers adopt and operationalize AWS security services to increase security effectiveness and reduce risk.

            ❌