AWS successfully completed its first surveillance audit for ISO 42001:2023 with no findings

Post Syndicated from Atulsing Patil original https://aws.amazon.com/blogs/security/aws-successfully-completed-its-first-surveillance-audit-for-iso-420012023-with-no-findings/

In November 2024, Amazon Web Services (AWS) was the first major cloud service provider to announce the ISO/IEC 42001 accredited certification for AI services, covering: Amazon Bedrock, Amazon Q Business, Amazon Textract, and Amazon Transcribe.

In November 2025, AWS successfully completed its first surveillance audit for ISO 42001:2023, Artificial Intelligence Management System with no findings.

This demonstrates the continual commitment of AWS to responsible AI practices. With this independent validation, our customers can gain further assurances around the AWS commitment to responsible AI and their ability to build and operate AI applications responsibly using AWS services.

For a full list of AWS services that are certified under ISO and CSA STAR, see the AWS ISO and CSA STAR Certified page. Customers can also access the certifications in the AWS Management Console through AWS Artifact.

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

Atul Patil

Atulsing Patil
Atulsing is a Compliance Program Manager at AWS. He has 27 years of consulting experience in information technology and information security management. Atulsing holds a Master of Science in Electronics degree and professional certifications such as CCSP, CISSP, CISM, CDPSE, ISO 27001 Lead Auditor, HITRUST CSF, Archer Certified Consultant, and AWS CCP.

Inside AWS Security Agent: A multi-agent architecture for automated penetration testing

Post Syndicated from Tamer Alkhouli original https://aws.amazon.com/blogs/security/inside-aws-security-agent-a-multi-agent-architecture-for-automated-penetration-testing/

AI agents have traditionally faced three core limitations: they can’t retain learned information or operate autonomously beyond short periods, and they require constant supervision. AWS addresses these limitations with frontier agents—a new category of AI that performs complex reasoning, multi-step planning, and autonomous execution for hours or days. Multi-agent collaboration has emerged as a powerful approach that helps tackle complex workflows that require multiple steps and diverse expertise—such as in software development where agents handle code generation, review, and testing; in scientific research where agents collaborate on literature review, experimental design, and data analysis; and in cybersecurity where specialized agents perform reconnaissance, vulnerability analysis, and exploit validation.

In this post, we discuss how we’ve used this technology to deliver automated penetration testing, something that can traditionally take weeks and is resource intensive. We also provide a technical deep-dive into the architecture of the penetration testing component built into AWS Security Agent.

The concept of automated security testing isn’t new—penetration testing tools and vulnerability scanners have existed for decades. However, with recent advancements in large language models (LLMs), frontier agents are designed to reason about application behavior, adapt strategies based on feedback, and understand context in ways that traditional tools can’t. By creating a network of specialized agents, we can address increasingly complex security challenges: one agent maps the attack surface while others analyze business logic flaws, validate findings, and prioritize vulnerabilities based on actual exploitability. The exploitability context comes from the combination of actual exploit attempts by swarm agent workers, independent re-validation by specialized validators, and LLM-driven scoring according to the common vulnerability scoring system (CVSS).

We’ve developed automated penetration testing for the AWS Security Agent. This capability includes a multi-agent penetration testing system that orchestrates specialized security agents to work collaboratively on vulnerability detection. The system begins with multiple types of scanning to establish baseline coverage, then conducts broad reconnaissance using static, predefined tasks to map the application surface and identify initial attack vectors. Building on these findings, our agentic system dynamically generates focused test tasks tailored to the specific application context—reasoning about discovered endpoints, business logic patterns, and potential vulnerability chains to create targeted security tests that adapt based on application responses. By combining these specialized capabilities, the system can tackle complex security scenarios across major risk categories. Beyond single-vulnerability detection, the system performs complex chained attacks—for instance, combining an information disclosure flaw with privilege escalation to access sensitive resources, or chaining insecure direct object references (IDOR) with authentication bypass.

Figure 1: Diagram of the AWS Security Agent penetration testing component.

Figure 1: Diagram of the AWS Security Agent penetration testing component.

System architecture

This section describes the major components of the system. The following subsections cover authentication and initial access, baseline scanning, multi-phased exploration with the specialized agent swarm, and validation with report generation.

Authentication and initial access

The system begins with an intelligent sign-in component that handles authentication across diverse application architectures. This component combines LLM-based reasoning with deterministic mechanisms to locate sign-in pages, attempt provided credentials, and maintain authenticated sessions for subsequent testing phases. The approach adapts to different application structures and target environments automatically and uses a browser tool. The developer can optionally provide a custom sign-in prompt tailored to the target application.

Baseline scanning phase

Following authentication, the system initiates comprehensive baseline scanning through parallel execution of specialized scanners. For black-box testing, the network scanner conducts automated web application security testing, generating raw traffic interactions and identifying candidate vulnerable endpoints. In white-box settings, the code scanner additionally performs deep source code analysis when repositories are available, producing descriptive documentation across multiple categories. Additional specialized scanners complement these capabilities to identify vulnerabilities across multiple dimensions and establish initial security coverage.

Multi-phased exploration

The system employs two distinct exploration approaches that work in concert. Managed execution operates with predefined static tasks across major risk categories like cross-site scripting, insecure direct object reference, privilege escalation, and so on. This component systematically helps ensure comprehensive coverage by executing curated tasks for each risk type. In the next phase, guided exploration takes a dynamic, intelligence-driven approach. This component ingests discovered endpoints, validated findings, and code analysis documentation to reason about application-specific attack opportunities. It operates in two stages: first generating a contextual penetration testing plan by identifying unexplored resources and potential vulnerability chains, then programmatically managing the execution of these dynamically generated tasks. The guided explorer runs with adaptive tasks that evolve based on application responses and discovered patterns.

Specialized agent swarm
Both exploration approaches dispatch work to specialized swarm worker agents—each configured for specific risk types and equipped with comprehensive penetration testing toolkits including code executors, web fuzzers, NVD vulnerability database search for Common Vulnerabilities and Exposures (CVE) intelligence, and vulnerability-specific tools. These workers execute assigned tasks with timeout management and structured reporting.

Validation and report generation

When specialized agents identify potential security risks, they generate structured reports containing the vulnerability type, affected endpoints, exploitation evidence, and technical context. However, automated penetration testing faces a critical challenge: LLM agents can produce plausible-sounding findings that require rigorous validation. Candidate findings undergo validation through both deterministic validators and specialized LLM-based agents that attempt active exploitation. We employ assertion-based validation techniques where natural language assertions written by security experts encode deep knowledge about real attack behaviors, requiring explicit, structured proof that’s significantly harder to circumvent than narrow deterministic checks. Validated findings undergo Common Vulnerability Scoring System (CVSS) analysis for severity assessment, then are synthesized into final reports with validation results, severity scores, and exploitation evidence—designed to deliver actionable, high-confidence vulnerabilities for effective remediation.

Benchmarking

To evaluate our system, we performed human evaluation in addition to automatic benchmarking. We conducted analysis on real-world trajectories and created a taxonomy of error patterns. By spotting frequent error patterns, we were able to iterate on our solution. We report results on the CVE Bench public benchmark, which is a collection of vulnerable web applications containing 40 critical-severity CVEs from the National Vulnerability Database used to evaluate AI agents on real-world exploits. Each application includes automatic exploit references, and LLM-based agents attempt to execute attacks that trigger the vulnerabilities.

We measure success through the attack success rate (ASR) metric, defined as the rate of successful exploitation of application vulnerabilities. CVE Bench uses a grader that the agent can query to verify exploit success and provides explicit capture-the-flag (CTF) instructions. We evaluate in three configurations:

  1. With CTF instructions and grader checks after each tool call, achieving 92.5% on CVE Bench v2.0 (we note that some challenges involve blind exploitation where the agent cannot verify success without this feedback).
  2. Without CTF instructions or grader feedback, achieving 80%—which better reflects real-world conditions where the agent must self-validate through observable outcomes. We also observed that the agent was able to identify some CVEs based on the LLM’s parametric knowledge, as shown in the following bash command where the model explicitly references a CVE by name.
  3. Therefore, we ran an additional experiment using an LLM whose knowledge cutoff date predates CVE Bench v1.0 release, achieving 65% ASR.

The following code example shows an LLM agent demonstrating parametric knowledge of CVE-2023-37999 from its training data, then issuing a bash command to check exploitation prerequisites.

# HT Mega 2.2.0 has a known vulnerability – CVE-2023-37999
# It has an unauthenticated privilege escalation via the REST API settings endpoint
# Let's check if registration is enabled
curl -s http://target:9090/wp-login.php?action=register -I | head -10

We’re committed to pushing the frontier of security vulnerability detection by continuously evaluating our agent and staying competitive with newer, more challenging benchmarks.

Optimizing testing and compute budget

One challenge for penetration testing is determining the balance between exploitation and exploration. Using a depth-first approach can waste too much compute on specific directions, leading to lower vulnerability coverage under a fixed compute budget. Compare that to breadth-first search, which is unlikely to discover deep vulnerabilities that require testing multiple approaches. Therefore, a balance between the two approaches is needed to maximize coverage for a given compute budget. Our proposed system design aims to include a hybrid approach. A more efficient dynamic solution that generalizes across various vulnerabilities and different web applications remains an open research question.

Another challenge with penetration testing is non-determinism. Because of the underlying LLMs, the output of penetration test runs can vary from one run to another. Having different findings across multiple runs can lead to confusion. One option to mitigate this is to perform multiple runs and consolidate the findings across them.

Conclusion

The multi-agent architecture presented in this post demonstrates how you can use specialized agents that can collaborate to tackle complex penetration testing workflows—from intelligent authentication and baseline scanning through managed and guided exploration phases, culminating in rigorous validation. By orchestrating these specialized components with adaptive task generation and assertion-based validation, the system delivers comprehensive security coverage that evolves based on application-specific context and discovered patterns.

AWS Security Agent is now in public preview, for more information, see Getting Started with AWS Security Agent.

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

Tamer Alkhouli

Tamer Alkhouli
Tamer is an Amazon Web Services Senior Applied Scientist with over 13 years in NLP across academia and industry. He earned a PhD in machine translation from RWTH Aachen University under Hermann Ney. Across his career, he has built systems in machine translation, conversational AI, and foundation models. At AWS, he has contributed to Amazon Lex, Titan foundation models, Amazon Bedrock Agents, and the AWS Security Agent.

Divya Bhargavi

Divya Bhargavi
Divya is a Senior Applied Scientist at AWS on the Security Agent team. Her work focuses on designing agentic architectures for vulnerability discovery and exploit validation, with emphasis on developing robust benchmarking frameworks and evaluation methodologies for security agents in adversarial contexts. Prior to this, she led scientific engagements at the AWS Generative AI Innovation Center.

Daniele Bonadiman

Daniele Bonadiman
Daniele is a Senior Applied Scientist at AWS, where he works on AWS Security Agent. Daniele holds a PhD in Applied Machine Learning and Natural Language Processing from the University of Trento. During his time at AWS, Daniele has contributed to several AI initiatives focusing on conversational AI, agent orchestration, and code interpretation for AI agents.

Yilun Cui

Yilun Cui
Yilun is a Principal Engineer at AWS working on Agentic AI. Yilun has had over a decade of experience building tools for developers and he is passionate about applying AI throughout the software development lifecycle to help software developers build faster and deliver better products.

Dr. Yi Zhang

Dr. Yi Zhang
Yi is a Principal Applied Scientist at AWS. With over 25 years of industrial and academic research experience, Yi’s research focuses on the development of conversational and interactive multi-agent systems and syntactic and semantic understanding of natural language. He has been leading the research effort behind the development of multiple AWS services such as AWS Security Agent and Amazon Bedrock Agent.

AWS Security Hub Extended offers full-stack enterprise security with curated partner solutions

Post Syndicated from Channy Yun (윤석찬) original https://aws.amazon.com/blogs/aws/aws-security-hub-extended-offers-full-stack-enterprise-security-with-curated-partner-solutions/

At re:Invent 2025, we introduced a completely re-imagined AWS Security Hub that unifies AWS security services, including Amazon GuardDuty and Amazon Inspector into a single experience. This unified experience automatically and continuously analyzes security findings in combination to help you prioritize and respond to your critical security risks.

Today, we’re announcing AWS Security Hub Extended, a plan of Security Hub that simplifies how you procure, deploy, and integrate a full-stack enterprise security solution across endpoint, identity, email, network, data, browser, cloud, AI, and security operations. With the Extended plan, you can expand your security portfolio beyond AWS to help protect your enterprise estate through a curated selection of AWS Partner solutions, including 7AI, Britive, CrowdStrike, Cyera, Island, Noma, Okta, Oligo, Opti, Proofpoint, SailPoint, Splunk, a Cisco company, Upwind, and Zscaler.

With AWS as the seller of record, you benefit from pre-negotiated pay-as-you-go pricing, a single bill, and no long-term commitments. You can also get unified security operations experience within Security Hub and unified Level 1 support for AWS Enterprise Support customers. You told us that managing multiple procurement cycles and vendor negotiations was creating unnecessary complexity, costing you time and resources. In response, we’ve curated these partner offerings for you to establish more comprehensive protection across your entire technology stack through a single, simplified experience.

Security findings from all participating solutions are emitted in the Open Cybersecurity Schema Framework (OCSF) schema and automatically aggregated in AWS Security Hub. With the Extended plan, you can combine AWS and partner security solutions to quickly identify and respond to risks that span boundaries.

The Security Hub Extended plan in action
You can access the partner solutions directly within the Security Hub console by selecting Extended plan under the Management menu. From there, you can review and deploy any combination of curated and partner offerings.

You can review details of each partner offering directly in the Security Hub console and subscribe. When you subscribe, you’ll be directed to an automated on-boarding experience from each partner. Once onboarded, consumption-based metering is automatic and you are billed monthly as part of your Security Hub bill.

Security findings from all solutions are automatically consolidated in AWS Security Hub. This gives you immediate and direct access to all security findings in normalized OCSF schema.

To learn more about how to enhance your security posture with these integrations for AWS Security Hub, visit the AWS Security Hub User Guide.

Now available
The AWS Security Hub Extended plan is now generally available in all AWS commercial Regions where Security Hub is available. You can use flexible pay-as-you-go or flat-rate pricing—no upfront investments or long-term commitments required. For more information about pricing, visit the AWS Security Hub pricing page.

Give it a try today in the Security Hub console and send feedback to AWS re:Post for Security Hub or through your usual AWS Support contacts.

— Channy

Digital Transformation at Santander: How Platform Engineering is Revolutionizing Cloud Infrastructure

Post Syndicated from Julio Bando original https://aws.amazon.com/blogs/architecture/digital-transformation-at-santander-how-platform-engineering-is-revolutionizing-cloud-infrastructure/

This post is cowritten by Julio Bando from Santander.

Santander faced a significant technical challenge in managing an infrastructure that processes billions of daily transactions across more than 200 critical systems. The expansion into diverse financial services, including investment banking, wealth management, insurance, and payment solutions, had created unprecedented technological complexity, requiring a robust, agile, and scalable infrastructure solution. This raised two main issues. Santander needed to ensure that provisioned services followed established architecture definitions, and they needed to reduce infrastructure provisioning time, which took up to 90 days. This situation demanded intensive operational effort. The solution emerged through an innovative platform engineering initiative called Catalyst, which transformed the bank’s cloud infrastructure and development management. This post analyzes the main cases, benefits, and results obtained with this initiative.

The Catalyst solution

Santander is a global financial services company present in more than 10 countries, with over 160 million customers worldwide. They conceived Catalyst in conjunction with the Platform Strategy Program (PSP), an Amazon Web Services (AWS) program specialized in infrastructure platform design. Implemented through a partnership between AWS Professional Services and Santander, the platform was designed to abstract infrastructure provisioning complexity, standardize architectural compliance, and create a framework that enables new technologies in the bank.

The platform’s in-house frontend was developed as an intuitive developer portal, offering a unified interface for all provisioning and resource management needs. At the platform’s core is the control plane cluster, based on Amazon Elastic Kubernetes Service (Amazon EKS). This cluster is the brain of the operation, orchestrating all components and workflows. Within the cluster, Crossplane plays a fundamental role, acting as a universal resource provisioner that Santander uses to manage resources across multiple cloud providers consistently and declaratively.

The control plane cluster has three components:

  • Data plane claims – Managed by ArgoCD, a continuous delivery tool, the component is responsible for continuous synchronization and deployment of application stacks (integrated sets of cloud resources) and configurations, exploring the GitOps concept.
  • Policies catalog – A central repository of policies ensuring compliance and security across all operations using Open Policy Agent (OPA).
  • Stacks catalog – A library of composite resource definitions and Compositions enabling quick and standardized creation of complex environments.

Santander used this innovative architecture to significantly reduce provisioning time from 90 days to only a few hours and in some cases only minutes. Catalyst brought significant benefits in terms of standardization, security, and governance. The provisioning cycle decreased from 30 days to 2 days, and proof of concept preparation time jumped from 90 days to only 1 hour. The consolidation of over 100 pipelines into a single control plane will further simplify infrastructure management. The following diagram shows the Santander catalyst architecture.

This diagram shows the AWS architecture of Santander's Catalyst platform that provides AI capabilities to teams across the company.

Key platform capabilities

Catalyst’s implementation enabled the creation of strategic workloads demonstrating the platform’s versatility and robustness:

  • Generative AI agents stack – The first success case was implementing a complete stack for AI agents integrating:
  • Modern data platform – One of the most complex workloads implemented through Catalyst was the new data platform, including:
    • Built-in integration with Databricks
    • Data lakes
    • Automated extract, transform, and load (ETL) workflows
    • Integration with centralized data catalog
    • Segregated environments for experimentation. With this implementation, the bank significantly reduces approximately 3,000 monthly tickets related to data experimentation environment provisioning.
  • Cloud process orchestration – creation of a modern process orchestration environment with significant results:
    • Migration of legacy workflows to AWS Step Functions
    • Implementation of retry patterns and error handling
    • Centralized process monitoring

Overall result

This stack reduced AI agent implementation time from 105 days to only 24 hours, eliminating dozens of provisioning tickets per environment. The success of these workloads demonstrates Catalyst’s technical capability and the solution’s versatility in meeting different business needs. Each implementation brought valuable learnings that were incorporated into the platform, creating a virtuous cycle of continuous improvement. The variety of implemented workloads also shows how Catalyst has the potential to be a universal platform, capable of supporting everything from traditional use cases to the most innovative ones involving AI and legacy system modernization. Catalyst’s success wasn’t limited to operational efficiency. The platform also catalyzed a cultural change within Santander, promoting an automation and self-service mindset among development teams. This resulted in faster overall development velocity, more agile teams, and enhanced capability to respond quickly to market changes.

Conclusion

Catalyst represents more than merely a technological tool—it’s a digital transformation enabler that’s redefining cloud development standards at the bank. With the platform, Santander addressed the challenges of a scaled environment and established a solid foundation for continuous innovation and future growth.

With these practical cases, Santander proves that investment in platform engineering solves technical problems and enables new business possibilities, keeping the bank at the forefront of digital transformation in the financial sector.


About the authors

Amazon OpenSearch Serverless introduces collection groups to optimize cost for multi-tenant workloads

Post Syndicated from Madhusudhan Narayana original https://aws.amazon.com/blogs/big-data/amazon-opensearch-serverless-introduces-collection-groups-to-optimize-cost-for-multi-tenant-workloads/

Today, we’re excited to announce the general availability of the collection groups feature for Amazon OpenSearch Serverless. With this feature you can reduce compute costs for multi-tenant workloads while creating secure tenant boundaries through per-tenant encryption, giving you the flexibility to balance cost efficiency with the exact level of isolation and security your applications requires.

Amazon OpenSearch Serverless is a serverless deployment option for Amazon OpenSearch Service, that eliminates the complexity of infrastructure management for running search and analytics workloads at scale. It automatically provisions and scales resources to deliver fast data ingestion rates and millisecond response times, even as usage patterns change. For organizations that are managing multi-tenant environments, data isolation, where the tenant’s data must be encrypted and protected (often with their own encryption keys), is a compliance requirement.

Previously, OpenSearch Serverless provided maximum security through physical isolation: each AWS Key Management Service key (KMS key) required dedicated OpenSearch Compute Units (OCUs) to maintain complete physical data separation. While this architecture provided the highest level of protection, it created challenges for multi-tenant deployments at scale. For customers managing multiple tenants with shared encryption keys, OCU resources are efficiently pooled, making the economics favorable. However, customers managing large numbers of smaller tenants, each requiring their own KMS key for data isolation, faced a challenge with higher cost. With dedicated OCU resources needed per unique key, the infrastructure costs could become prohibitive when individual tenants required only a fraction of an OCU’s capacity. This particularly impacted service providers wanting to offer bring your own key (BYOK) capabilities to their customers, forcing them to either absorb unsustainable costs or limit their service offerings.

OpenSearch Serverless has always provided flexible capacity management with maximum OCU settings to help you control costs. For most workloads, this model works seamlessly capacity scales up and down in response to demand, so you only pay for what you use. However, some workload patterns are simply better served by having a guaranteed baseline of compute ready to go from the start. Workloads with sudden traffic spikes, high-speed data ingestion pipelines, or load testing scenarios benefit from having capacity pre-allocated, so that the first requests are handled with the same responsiveness as any other. Similarly, multi-tenant architectures and time-sensitive operations often require predictable, consistent performance from the moment a collection becomes active.

Flexible controls with collection groups

Collection groups give you flexible control over security boundaries and resource allocation. Instead of forcing a one-size-fits-all approach, you can now tailor your architecture to match your specific security and cost requirements. Here’s how it works:

  1. Define your security boundary that matches your need: Collection groups is a logical security construct for related collections. Each collection groups maintains strong isolation with physically separated memory, CPU and disk from other collection groups, ensuring robust security boundaries between different security constructs.
  2. Share resources across encryption keys: Allocate collections to your collection groups regardless of whether they share KMS keys or use separate ones. Collections with different encryption keys can now share OCU resources within the same security boundary, dramatically reducing costs while maintaining full encryption protection and logical separation for each tenant.
  3. Deploy with flexible network access: Collection groups support collections with different network access types, allowing you to combine collections with public endpoints and VPC endpoints within the same group. This flexibility lets you match your security and connectivity requirements while benefiting from shared resource management across all collections in the group.
  4. Control cost and performance: Set maximum OCUs to cap spending and minimum OCUs to guarantee baseline performance. This dual control gives you a defined resource envelope for each collection groups, eliminating cost surprises while ensuring consistent performance.
  5. Optimize with insights: Access detailed CloudWatch metrics showing resource consumption, relative usage patterns, and latency across collection groups. These insights help you right-size allocations, identify optimization opportunities, and tune performance based on actual workload behavior.

With collection groups, you now have full control over resource allocation through both minimum and maximum OCU settings

Maximum OCUs: Cost control

Set an upper limit on resources to prevent runaway scaling and control costs per collection groups. This helps ensure you never exceed your budget, even during unexpected traffic spikes. Collection groups capacity limits operate independently from account-level limits. Account-level maximum OCU settings apply only to collections not associated with any collection groups, while collection groups maximum OCU settings apply to collections within that specific group. The sum of (Max OCUs across all your collection groups + Max OCU setting at the account level) should be less than your Service Quota Max OCUs allowed for your account. This separation gives you granular cost control across different security contexts.

Minimum OCUs: Performance guarantees

Define the baseline compute resources that will always be allocated to your collection groups, for consistent performance and resource availability. These OCUs are reserved exclusively for your collection groups and provide:

  • Instant availability with no cold starts: Your collections benefit from instant availability without scaling delays. Resources are always warm and ready, eliminating scaling delays when traffic arrives.
  • Guaranteed capacity: Resources are always available, even during periods of low activity or when competing with other collection groups, ensuring predictable performance even during low-traffic periods.
  • Predictable costs: Minimum OCUs are charged continuously, providing you with reserved capacity in exchange for predictable billing giving you cost certainty in exchange for guaranteed performance. This reserved baseline serves as the foundation for auto-scaling, which expands capacity up to your maximum limit as demand increases.

This combination gives you the flexibility to balance cost optimization with performance guarantees based on your specific requirements.

Multi-tenant cost economics with collection groups

Managing costs in multi-tenant architectures has always required balancing isolation, performance, and efficiency often at the expense of one another. Collection groups change that equation by enabling shared capacity across collections without sacrificing security boundaries. The following details how this plays out when you work with collection groups or without.

Before collection groups: Consider a customer with 10 tenants, each requiring their own KMS key for data isolation. Most of these tenants have modest data requirements typically 10-100GB, with the majority on the smaller end of that range. Managing dedicated resources for each tenant’s encryption key, regardless of their actual capacity needs, created operational complexity and cost challenges at scale.

With collection groups: The same customer can now group their tenants with similar security requirements into the collection groups, sharing OCU resources across collections. Tenants requiring only a small portion of OCU capacity no longer force the allocation of dedicated resources, reducing costs by up to 90% for large number of smaller tenant workloads.

With minimum OCU configuration: Premium tenants can be placed in collection groups with minimum OCUs set to guarantee performance, while standard tenants use collection groups with lower minimum thresholds for cost efficiency.

The following table illustrates how these cost savings play out across different tenant configurations, comparing infrastructure costs with and without collection groups across varying data sizes and query loads.

Number of tenants with unique KMS keys

Data size and query parameters

Cost with complete data isolation (without collection groups)

Cost with collection groups

Additional comments

10

Data size: 60GB or less

Query: Not needing more than base OCU (1 for redundant collection) compute

$3,500 $350 10x Savings in cost.
10

Data size: 60GB or less

Query: More than base OCU (1 for redundant collection) compute during peak times (For example – 5 additional OCUs per tenant without collection groups & 40 OCUs across all tenants based with collection groups due to benefit of shared infra).

$3500 + Peak time scale out per tenant ($8650) $350+ Peak time scale out ($6912). The system will scale up when there is additional query load, additional OCUs are deployed during this time. However when the load scales back, the system will scale-in to base OCU’s.
10 Data size: Sample data size in GB per tenant [3, 5, 7, 8, 10, 15, 18, 25, 28, 150]

Query: Can handle queries upto certain level with minimum OCU for the data size and then scales out on load.

For the sample data sizes, minimum OCU requirement will be [2, 2, 2, 2, 2, 2, 2, 2, 2, 8] = 26 OCUs [$4492] + Peak time scale out per tenant Minimum cost is determine by the number of OCUs required to hold the data across all tenants (120GB per OCU *2) + Peak time scale out.For the sample data sizes, 8 OCUs [$1382] + Peak time scale out per tenant The system will scale up when there is additional query load, additional OCUs are deployed during this time. However when the load scales back, the system will scale-in to minimum number of OCU required to hold the data.

Note: Above calculations are made with assumption for redundant enabled collections. For non-redundant mode it will be half the above calculations.

Getting started with collection groups

Collection groups and minimum OCU configuration are available in all AWS Regions where OpenSearch Serverless is offered, at no additional charge. Collection groups offers a new organizational feature to create collection groups and add new collections directly to these groups for enhanced management capabilities. While your existing collections will continue to operate unchanged and remain independent of any collection groups, you can immediately start using collection groups for new collections to benefit from improved organization and workflow management.

Currently, only newly created collections can be associated with collection groups, and all collections within a group must be of the same type (search, time series, or vector search). Existing collections continue to operate independently with their current capacity management settings, and you cannot mix different collection types within a single collection groups. You can use the AWS Management Console, AWS CLI, AWS CloudFormation, or AWS CDK to create the collection groups. In the following section we will show you how you can create the collection groups using the OpenSearch Service console.

To create your first collection groups:

  1. Open the OpenSearch Service console.
  2. In the left navigation pane, choose Serverless, then choose Collection groups.
  3. Choose Create collection groups.
  4. For collection groups name, enter a name for your collection groups. The name must be 3-32 characters long, start with a lowercase letter, and contain only lowercase letters, numbers, and hyphens.
  5. (Optional) For Description, enter a description for your collection groups.
  6. In the Capacity management section, configure the OCU limits:
    1. Maximum indexing capacity – The maximum number of indexing OCUs that collections in this group can scale up to.
    2. Maximum search capacity – The maximum number of search OCUs that collections in this group can scale up to.
    3. Minimum indexing capacity – The minimum number of indexing OCUs to maintain for consistent performance.
    4. Minimum search capacity – The minimum number of search OCUs to maintain for consistent performance.
  7. (Optional) In the Tags section, add tags to help organize and identify your collection groups.
  8. Choose Create collection groups.

To assign collection to the collection groups

  1. Open the Amazon OpenSearch Service console.
  2. In the left navigation pane, choose Serverless, then choose Collections.
  3. Choose Create collection.
  4. For Collection name, enter a name for your collection. The name must be 3-28 characters long, start with a lowercase letter, and contain only lowercase letters, numbers, and hyphens.
  5. (Optional) For Description, enter a description for your collection.
  6. In the Collection groups section, select the collection groups you want the collection to be assigned to. A collection can only belong to one collection groups at a time.
    (Optional) You can also choose to Create a new group. This will navigate you to the Create collection groups workflow. After you finish creating the collection groups, return to the step 1 of this procedure to begin creating your new collection.
  7. Continue through the workflow to create the collection.

Managing collection groups

Once you’ve created your collection groups, you can update their settings as your architecture evolves. The Amazon OpenSearch Serverless documentation provides step-by-step guidance on how to edit and delete collection groups, including updating OCU limits and modifying group configurations using the AWS Management Console, CLI, and CloudFormation.

Conclusion

OpenSearch Serverless collection groups transform how you can architect multi-tenant deployments by offering flexible deployment modes that balance security requirements with operational efficiency. You can now choose the collection groups where you define logical security boundaries that allow collections, regardless of whether they share the same KMS key or use different KMS keys to share OCU resources.

This flexibility directly addresses the cost challenges that previously made multi-tenant deployments prohibitive. By consolidating collections within collection groups, you can reduce infrastructure costs while maintaining robust encryption and tenant isolation. Configuring both minimum and maximum OCUs for each collection groups solves the cold-start and capacity guarantee challenges: minimum OCUs ensure your collections maintain ready compute resources to handle high-speed ingestion, sudden traffic spikes, and load testing without performance degradation. Maximum OCUs provide cost predictability and spending controls. This dual configuration gives you a defined resource envelope that eliminates both the uncertainty of cold starts and the risk of runaway costs.

To dive deeper into the collection groups and minimum OCU configuration, visit the Amazon OpenSearch Serverless documentation.

About the authors

Madhusudhan Narayana

Madhusudhan Narayana

Madhusudhan is Senior Software Engineer with Amazon Web Services. He is focused on OpenSearch Service and has years of experience in software engineering, distributed and autonomous systems. He holds a MS in Computer Science.

Prashant Agrawal

Prashant Agrawal

Prashant is a Sr. Search Specialist Solutions Architect with Amazon OpenSearch Service. When not working, you can find him traveling and exploring new places. In short, he likes doing Eat → Travel → Repeat.

Xian Huang

Xian Huang

Xian is a Product Marketing Manager at AWS.

Improving order history search using semantic search with Amazon OpenSearch Service

Post Syndicated from Shwetabh . original https://aws.amazon.com/blogs/big-data/improving-order-history-search-using-semantic-search-with-amazon-opensearch-service/

If you’ve ever shopped on Amazon, you’ve used Your Orders. This feature maintains your complete order history dating back to 1995, so you can track and manage every purchase you’ve made. The order history search feature lets you find your past purchases by entering keywords in the search bar. Beyond just finding items, it provides a straightforward way to repurchase the same or similar items, saving you time and effort.

Various features across Amazon’s shopping experience, such as Rufus and Alexa, use order history search to help you find your past purchases. Therefore, it’s important that order history search can locate your past purchased items as accurately and quickly as possible.

In this post, we show you how the Your Orders team improved order history search by introducing semantic search capabilities on top of our existing lexical search system, using Amazon OpenSearch Service and Amazon SageMaker.

Limitations of lexical search

Order history search uses lexical matching to find items from the entire order history of a customer that match at least one word of the search keywords. For example, if a customer searches for “orange juice,” the system retrieves all orange juice items as well as fresh oranges and other fruit juices the customer had previously ordered. Although lexical matching can provide a high recall of items with terms matching the search keywords precisely, it doesn’t work well for related or generic search keywords, like “health drinks” in this example.

Since the launch of Rufus, Amazon’s AI-enabled shopping assistant, a growing number of customers are experiencing a streamlined and richer shopping journey, including searching for their previous purchases with Rufus. Customers can now ask “Show me healthy drinks” without worrying about using lengthy, more precise terms like “kombucha”, “green tea”, and “protein shakes”. This makes the search experience more conversational and intent-based, presenting an opportunity to make item discovery more intuitive. For Rufus to answer order history searches with the same intuitive experience such as “Show me the healthy drinks I bought last year”, the underlying order history data store (“Your Orders”) needs semantic search capability to understand the underlying semantics of search keywords beyond the conventional lexical matching.

Challenges implementing semantic search

Implementing semantic search at our scale presented several technical challenges:

  • Scale – We needed to enable semantic search across billions of records corresponding to customers’ order history globally.
  • Zero downtime – We needed to keep the system 100% available while making changes on the backend to introduce semantic search.
  • Preventing search quality degradation – Semantic search is intended to improve the quality of search results. However, in some cases, it can reduce search quality. For example, if a customer remembers their item name exactly and wants to find only items matching that name, surfacing similar items in addition to the exactly matching items will increase crowding in results and make it harder to find the relevant item. Similarly, semantic search will not work for cases where the customer intends to search by identifier values, like order ID, which lack an inherent semantic meaning. For these scenarios, we use lexical search only.

Solution overview

Semantic search is powered by large language models (LLMs), which are mostly trained on human languages. These models can be adapted to take a piece of text in any language they were trained in and emit an embedding vector of a fixed length, irrespective of the input text length. By design, embedding vectors capture the semantic meaning of input text such that two semantically similar text strings have high cosine similarity computed on their respective embedding vectors. For semantic search on order history, the input text subject to embedding generation and similarity computation are the customer search phrases and the product text of purchased items.

We divide our solution into two parts:

  • Improving system scalability and resiliency for handling requests at scale – Before implementing semantic search, we needed to ensure our infrastructure could handle the increased computational load, leading us to adopt a cell-based architecture. This step is not needed for every use case, but systems with very high scale in terms of request or data volume can benefit a lot from its use before implementing a resource-intensive use case like semantic search.
  • Implementing semantic search – We began by evaluating the available embedding models, using the offline evaluation capabilities of Amazon Bedrock to test different models. After we selected our model, we could establish the infrastructure for generating embedding vectors.

Improving system scalability and resiliency

We used the cell-based architecture design pattern for improving our scalability and resiliency. A cell-based design entails partitioning the system into identical, smaller, self-contained chunks, or cells, which handle only a part of the overall traffic received by the system. The following diagram shows a high-level representation of a cell-based design for order history search.

Cell-based architecture diagram showing customer request routing to Amazon OpenSearch Service domains via hash-based partitioning

Each cell serves a defined subset of our customers. Cells don’t need to communicate with one another to serve a customer request. Each customer is assigned to a cell and each request from that customer is routed to that cell. The OpenSearch Service domain in each cell holds data only for the subset customers that it is supposed to serve. The number of cells (N) and distribution of data among those cells depends on the business use case, but the goal is to achieve as even a distribution of data and traffic as possible.

The routing logic can be kept as simple or as sophisticated as the use case requires it to be. The cell assignment values can either be computed at runtime for each request, or they can be computed one time and written to a cache or persistent data store like Amazon DynamoDB, from where cell assignment values can be fetched for subsequent requests. For order history search, the logic was simple and quick enough to be executed at runtime for each request. Looking up cell assignment from a persistent data store is especially useful for cases where there is a risk of some cells becoming “heavier” than others over time. In such cases, it becomes easier to redistribute the heavy cell’s data by simply overriding cell assignment values for specific keys in the data store, instead of having to change the partitioning logic immediately, which might have an impact on data distribution across all the cells.

As the system’s load grows, the number of cells in the system can be increased to handle the additional traffic. Even without increasing the number of cells in the system, we can redistribute current data among the existing N cells by reassigning some keys from one or more heavily populated cells to different lightly populated cells to spread out the load more evenly across all the cells and make more efficient use of the infrastructure.

A cell-based architecture also helps make the system more resilient. For example, if we lose one cell, our capacity is diminished only by 1/N, instead of 100%. This arrangement can also be improved to reduce the capacity loss even further by assigning partitioning keys to two or more cells such that they get written to two or more cells. In such cases, loss of a single cell does not result in data loss.

Implementing semantic search

Implementing semantic search for our order history search required several key decisions and technical steps. We began by evaluating the available embedding models, using the offline evaluation capabilities of Amazon Bedrock to test different models against our specific business domain requirements. This evaluation process helped us identify which model would deliver the best performance for our use case. After we selected our model, we needed to establish the infrastructure for generating embedding vectors. We containerized our embedding model and registered it in Amazon Elastic Container Registry (Amazon ECR), then deployed it using SageMaker inference endpoints to handle the actual vector computation at scale.

For the search infrastructure itself, we chose OpenSearch Service to implement our semantic search capabilities. OpenSearch Service provided both the vector storage we needed and the search algorithms required to deliver relevant results to our users.

One of our biggest challenges was updating our historical data to support semantic search on existing orders. We built a data processing pipeline using AWS Step Functions to orchestrate the workflow and AWS Lambda functions to handle the actual vector generation for our legacy data, so we could provide semantic search for all the records we wanted to.

The following diagram illustrates the high-level architecture.

Architecture diagram showing read-flow and write-flow for semantic search using Amazon OpenSearch Service and Amazon SageMaker embedding vectors

Model evaluation and selection

Order history search uses an embedding model trained on Amazon-specific data. Domain-specific training is critical because the generated embedding vectors must work well for the business context to return quality results.

We used an LLM-as-a-judge methodology with Anthropic’s Claude on Amazon Bedrock to evaluate candidate models. Anthropic’s Claude received prompts containing anonymized item text and search phrases from customer order history, then filtered and ranked items by relevance. These results served as ground truth for comparison.

We evaluated models using standard ranking metrics:

  • Normalized Discounted Cumulative Gain (NDCG) – Measures ranking quality against ideal order
  • Mean Reciprocal Rank (MRR) – Considers position of first relevant item
  • Precision – Rates accuracy of retrieved results
  • Recall – Rates ability to retrieve all relevant items

This process helped us determine the best model.

Retrieval strategy: Customer-scoped comprehensive search

Order history search has two key requirements:

  • Search only through the requesting customer’s order history – We don’t want items from one customer’s order history showing up in search results for another customer
  • Search all of that customer’s history – We don’t want to miss showing an item that would have been relevant for the customer’s search phrase just because the search algorithm missed evaluating it for some reason

Our approach involves using OpenSearch Service to retrieve all items for the customer who issued the search query, calculating relevance scores for each of them against the search phrase, sorting by score, and returning top K results. This provides comprehensive results coverage for each customer.

Vector storage with OpenSearch Service

We used two OpenSearch Service features for efficient vector storage and search:

  • knn_vector datatype – Built-in support for storing embedding vectors. Existing domains can add this field type without reindexing, enabling exact kNN search across all records. We didn’t need approximate kNN because the number of records for most customers was small enough for exact kNN to scale.
  • Scripted scoring – Painless scripts compute vector similarity server-side, reducing client complexity and maintaining low latency.

Hybrid search

Hybrid search refers to combining the results of lexical and semantic search to benefit from the strengths of each. The hybrid query capabilities of OpenSearch Service simplify implementing hybrid search by letting clients specify both types of queries in a single request. OpenSearch Service runs both queries in parallel, merges their results, normalizes the relevance scores of the sub-queries, and sorts results by the provided sort order (relevance score by default) before returning them to clients.

This gives clients the best of both types of searches. For example, there are certain scenarios where the search phrase doesn’t make much sense semantically, like when customers search by their orderId values. Semantic search is not designed for such cases; these are best served using keyword matching.

The hybrid search functionality helped save implementation effort and potential latency increase for order history search.

Updating historical data

After the infrastructure has been set up, newly ingested records are persisted with the relevant embedding vectors and support semantic search on those records. However, when customers search, they typically search for products they had purchased earlier. Therefore, the system might not help improve customer experience much unless the older records are updated to include the relevant embeddings. The approach to populate this data depends on the scale of the problem at hand.

Releasing the change to minimize potential customer impact

Our final step was to release the change to clients in a manner such that the impact of any potential problems is as small as possible. There are multiple ways to do that, including:

  • Implementing semantic search in a manner such that any transient issues in the semantic search flow make the logic fall back to lexical-only search, instead of failing the request completely. Even if semantic search doesn’t execute, the system should still be able to return results of lexical search to the client, instead of empty results.
  • Gating the change such that the default behavior remains lexical-only search and clients who need the semantic search feature must pass an additional flag in the request, for example, which executes the semantic or hybrid flow only for those requests.
  • Keeping the new flow behind a feature flag during the initial period such that it could be turned off completely if some critical problem is detected.

Examples of improved customer experience

The following are some examples of customer interactions with Rufus that required Rufus to query the respective customer’s order history to answer their question and give them the required pieces of information.

The following screenshots show how semantic search picks up wooden spoons for a “sustainable utensils” query and different kinds of chargers despite not having the keyword “charger” in the title description, in the case of the wall connector.

Two side-by-side screenshots demonstrating semantic search results for sustainable utensils and chargers in an e-commerce interface.

The following screenshots show how semantic search picks up relevant results even though the title description doesn’t include the queried keywords.

Two side-by-side screenshots demonstrating semantic search results for healthy snacks and kids educational items in an e-commerce order interface.

The semantic search feature of order history search helped Rufus fetch them and show to the customers. Before semantic search, Rufus wasn’t able to show any results to customers for such queries.

Business impact

Our solution resulted in the following key business impacts:

  • Customer experience improvements – The solution achieved 10% improvement in query recall, increasing the percentage of searches that return relevant results. It also reduced customer service contacts for issues related to locating past orders.
  • Partner integration success – The solution strengthened natural language processing capabilities for Alexa and Rufus, enhancing their ability to interpret order history queries. It also reduced the need for reranking and postprocessing by partner teams. We improved query success rate by 20%, meaning more customer searches now return at least one relevant item. We also observed enhanced result coverage by 48%, with semantic search consistently surfacing additional relevant matches that lexical search would have missed.

Conclusion

In this post, we showed you how we evolved Amazon order history search to support semantic search capabilities. This transition involved using cutting-edge AI technology while working within existing infrastructure limitations to develop solutions that avoided disruption and maintained SLAs during the feature upgrade. The implementation also involved backfilling, where billions of documents were processed at rates multiple times higher than normal ingestion to compute embedding vectors for previously purchased items. This operation required careful engineering and took advantage of the resilience OpenSearch Service offers even under extreme load.

Beyond the immediate implementation, this foundation enables continued innovation in search technology. The embedding vectors framework can incorporate improved models as they become available, and the architecture supports expansion into new capabilities such as personalization and multi-modal search.

You can get started with exact k-NN search today following the instructions in Exact k-NN search. If you’re looking for a managed solution for your OpenSearch cluster, check out Amazon OpenSearch Service.


About the authors

Shwetabh

Shwetabh

Shwetabh is a Senior Software Engineer at Amazon with interests in distributed systems and machine learning. Outside of work, he’s an avid reader with a particular love for technical deep-dives and thought-provoking non-fiction.

Harshavardhan Miryala

Harshavardhan Miryala

Harshavardhan is a Software Engineer at Amazon. He is passionate about machine learning, with particular interest in information retrieval and distributed computing. Outside of work, he enjoys playing racquet sports and watching football.

Ayush Kumar

Ayush Kumar

Ayush is a Tech Leader at Amazon. He is a passionate builder with an experience of over 14 years and leads the Your Orders Search product. In his spare time, he enjoys watching cricket and playing with his toddler.

[$] IIIF: images and visual presentations for the web

Post Syndicated from corbet original https://lwn.net/Articles/1059565/

The International Image Interoperability
Framework
, or IIIF (“triple-eye eff”), is a small set of standards that
form a basis for serving, displaying, and reusing image data on the web. It
consists of a number of API definitions that compose with each other to
achieve a standard for providing, for example, presentations of
high-resolution images at multiple zoom levels, as well as bundling multiple images
together. Presentations may include metadata about details like authorship,
dates, references to other representations of the same work, copyright
information, bibliographic identifiers, etc. Presentations can be further
grouped into collections, and metadata can be added in the form of
transcriptions, annotations, or captions. IIIF is most popular with
cultural-heritage organizations, such as libraries, universities, and
archives.

Security updates for Thursday

Post Syndicated from jzb original https://lwn.net/Articles/1060391/

Security updates have been issued by AlmaLinux (freerdp), Debian (firefox-esr and libstb), Fedora (389-ds-base, chromium, firefox, munge, opentofu, python3-docs, python3.14, and vim), Oracle (buildah, containernetworking-plugins, gimp, grafana, grafana-pcp, kernel, podman, runc, and skopeo), Red Hat (go-toolset:rhel8, golang, golang-github-openprinting-ipp-usb, grafana, grafana-pcp, mariadb:10.11, podman, and skopeo), SUSE (cacti, docker-stable, expat, firefox-esr, freerdp, freerdp2, libjxl, libsoup-2_4-1, python-tornado, python-urllib3_1, python3, python311-Django4, python312, python313, python39, and redis), and Ubuntu (ceph, mongodb, protobuf, and rlottie).

Before the Breach: When digital footprints become a strategic cyber risk

Post Syndicated from Jeremy Makowski original https://www.rapid7.com/blog/post/tr-data-breach-digital-footprints-strategic-cyber-risk-report

Overview

For years, organizations have prioritized strengthening technical defenses, including hardening networks, accelerating patch management, and expanding endpoint detection and response capabilities. Defensive systems have become more adaptive, identity has moved to the center of security architectures, and zero-trust has emerged as a foundational design principle. 

Despite these advances, successful intrusions continue to occur in environments that appear technically mature. While traditional attack vectors like vulnerability exploitation, misconfigurations, and malware-based intrusions show no sign of decline, modern attacks are increasingly preceded or materially enabled by extensive reconnaissance conducted beyond the victim’s technical perimeter.

Organizations and their employees expose substantial volumes of data online, both intentionally and unintentionally. This includes professional and personal information shared through corporate websites, SaaS platforms, social media, developer repositories, marketing materials, and third-party services, as well as data exposed through breaches, misconfigured cloud assets, and shadow IT.

As seen in the following screenshots, vast amounts of historical information, credential leaks, personally identifiable information (PII) persist in exposed databases, as well as on dark web marketplaces and cybercrime forums.

⠀

dark-web-marketplace-US-SSNs-sale.png
Figure 1: A dark web marketplace offering US SSNs for sale.

⠀

compromised-database-search-engine-exposes-leaked-credentials.png
Figure 2: A compromised database search engine exposes leaked credentials.

⠀

citizenship-databases-exposed-on-cybercriminal-forum.png
Figure 3: Multiple citizenship databases exposed on a cybercriminal forum

⠀

Threat actors increasingly leverage this layered digital footprint as a core component of their operational planning. While such exposure may not always constitute the initial access vector itself, it significantly influences attacker decision-making, targeting precision, and the likelihood of success. 

Breach data and open-source intelligence are utilized to map organizational structures, identify privileged or high-value identities, correlate reused credentials, infer security controls, and tailor phishing or social engineering campaigns with high contextual credibility. In many cases, this intelligence determines which vulnerability, account, or trust relationship is exploited, rather than whether exploitable weaknesses exist. As a result, the boundary between “technical” and “human” attack vectors continues to erode. Infrastructure security remains necessary, but it is no longer sufficient in isolation. The effective attack surface now extends beyond networks and endpoints to encompass identity exposure, employee digital behavior, third-party data ecosystems, and long-lived data traces that persist outside traditional security tooling and governance models. 

What is digital footprint exposure?

A digital footprint refers to all the information about an organization and/or an individual that is publicly, semi-publicly, or commercially available online. This information is often scattered across numerous platforms, but aggregating it enables the creation of detailed, actionable profiles of individuals and institutions.

Typical elements of a digital footprint include:

  • Corporate and personal email addresses

  • Passwords and authentication data leaked through breaches

  • Public social media profiles and historical activity

  • Personally Identifiable Information (e.g., name, SSN, phone number, email address).

  • Employment history, job titles, role descriptions, and annual reports

  • Online behavior, interests, affiliations, and routines

  • Metadata collected and sold by third-party data brokers

The acquisition of this data does not require hacking, system intrusion, or the deployment of malware. Instead, attackers collect, correlate, and exploit information that exists beyond the organization’s security perimeter, making it inherently unreachable by conventional security controls such as firewalls, EDR, or internal monitoring systems. Because these digital assets reside outside direct organizational ownership and technical control, they cannot be effectively protected by traditional defensive mechanisms. In this context, threat intelligence monitoring plays a critical role by providing visibility into external data exposure, tracking adversarial collection and misuse of such information, and enabling organizations to detect, assess, and respond to risks that would otherwise remain invisible to perimeter-based security architectures.

Digital footprint exposure: A growing security threat

The modern threat landscape no longer rewards attackers who are simply skilled at exploiting systems; it rewards those who are best at understanding people, relationships, and behavior. Publicly accessible data, semi-private platforms, and commercially available datasets collectively form a digital footprint that can be mapped, enriched, and weaponized well before any technical intrusion attempt. This exposure shifts the initial battleground away from firewalls and endpoints toward employees’ online presence and the organization’s external data shadow.

Organizations that continue to define their perimeter in terms of IP ranges, devices, or cloud assets are defending yesterday’s battlefield. In many cases, the first stage of compromise occurs months before an alert is raised, within public forums, social networks, breached datasets, and data broker platforms, entirely outside traditional security monitoring and response processes. Adversaries use this information to identify key personnel, ascertain internal structures, map trusted relationships, and assess security maturity without ever touching corporate infrastructure.

Attackers collect specific external data to identify valid users, authentication systems, and internal dependencies. They extract employee names, roles, and corporate email formats from LinkedIn, conference materials, and public breach datasets. They identify authentication portals, VPN gateways, and cloud services using passive DNS records, Certificate Transparency logs, and internet scanning platforms such as Shodan or Censys. Public GitHub repositories and technical documentation may reveal internal domain names, API endpoints, identity providers, and technology stacks. 

These elements allow attackers to identify valid corporate accounts, target employees with privileged access, register impersonation domains that match internal naming conventions, and send phishing emails that reference real vendors, systems, or workflows. This preparation increases the likelihood of credential theft and unauthorized access because the attacker is targeting real users and real systems rather than relying on generic phishing or random scanning.

For employees, digital footprint exposure translates into personal risk that directly impacts corporate security. Leaked credentials, reused passwords, overshared professional information, or historical data breaches can be exploited to impersonate staff, coerce access, or establish credibility during pretexting operations. Senior leaders, IT staff, and individuals with privileged access are particularly vulnerable, as attackers can leverage publicly available information to craft convincing narratives that exploit trust and authority.

Uncontrolled exposure of employee information allows attackers to move from targeting individuals to compromising the organization. This enables them to identify employees with access to key systems, administrative privileges, or sensitive organizational platforms through public work profiles and data obtained from data breaches. They then test exposed credentials on corporate login portals, send phishing emails impersonating trusted internal or external entities, or attempt to intercept authentication codes by targeting exposed phone numbers. Once a single employee account is compromised, attackers can gain access to internal systems, escalate their privileges, and move laterally within the organization.

Threat actor exploitation of digital footprints

Threat actors, whether cybercriminal groups or state-sponsored operators, have always relied heavily on digital footprints in their operations. Publicly available information, leaked data, social media activity, and professional networks provide valuable insight into people, organizations, technologies, and trust relationships, making attacks more targeted and believable. 

With the rise of AI-powered tools, this exploitation has intensified. What once required time-consuming manual research can now be automated, enriched, and scaled almost instantly. AI enables adversaries to turn fragmented online traces into compelling narratives, lures, and impersonations, significantly increasing the speed, precision, and overall impact of attack vectors driven by digital footprints.

Cybercriminals

Cybercriminals typically exploit online exposure to establish rapid, monetizable intrusion paths without requiring deep internal access. Public profiles, leaked credentials, exposed servers, misconfigured cloud resources, and operational metadata are aggregated to identify where access already exists or can be obtained with minimal resistance. The focus is on converting exposed data directly into usable access, validating it quickly, and either exploiting or reselling it.

Tactical attack vectors derived from exposed digital footprints include:

  • Leaked credential exploitation: Abuse of credentials harvested from data breaches, stealer logs, and infostealer marketplaces, correlated with corporate email domains to gain unauthorized access to VPNs, SSO portals, cloud consoles, SaaS platforms, and legacy authentication endpoints

  • Identity and account surface expansion: Leveraging open professional and social network profiles to enumerate valid usernames, email address formats, job roles, seniority levels, and likely privilege tiers, enabling targeted credential testing and account takeover attempts

  • Email signature and metadata harvesting: Exploitation of email signatures, contact blocks, and publicly shared correspondence to identify internal naming conventions, phone extensions, third-party services, and technology stack indicators useful for impersonation and lateral access

  • Document-driven reconnaissance: Mining publicly exposed or leaked company documents (policies, PDFs, presentations, contracts, org. charts, etc.) to infer internal systems, authentication workflows, directory structures, cloud providers, and security controls

  • Infrastructure targeting via exposure leakage: Identification and exploitation of externally exposed servers, admin panels, APIs, and management interfaces through search engines, passive DNS, certificate transparency logs, and open indexing platforms

  • Banner, certificate, and service fingerprinting: Abuse of SSL/TLS certificates, HTTP headers, API responses, and service banners to fingerprint software versions, cloud services, authentication mechanisms, and unpatched or end-of-life systems

  • Cloud asset exploitation: Targeting publicly exposed storage buckets, orphaned cloud tenants, misconfigured IAM roles, stale API keys, and secrets discovered via open repositories, leaked configuration files, or documentation artifacts

  • Access brokerage: Enabling the validation, packaging, and resale of footprint-derived access (credentials, VPN sessions, cloud console access, shells) within cybercriminal marketplaces, based on assessed business impact and network reach

  • Low-noise privilege escalation and lateral movement: Exploitation of weak segmentation, excessive trust relationships, and overexposed directory or identity services inferred from public documentation, leaked internal diagrams, or misconfigured federation endpoints

State-Sponsored Actors

State-sponsored actors treat exposed digital footprints as long-term intelligence and access-enabling infrastructure. Voluntarily shared information, institutional transparency, technical disclosures, and accidental leaks are fused to build high-fidelity models of people, systems, and dependencies. These actors exploit exposure selectively, prioritizing vectors that support persistent access, intelligence collection, and operational survivability.

Tactical attack vectors derived from exposed digital footprints include:

  • Identity and role mapping: Use of social networks, publications, and organizational disclosures to identify privileged users, trust relationships, and lateral movement paths

  • Credential and token reuse: Reuse of leaked credentials, API keys, and tokens over long periods to regain access without new exploits or tooling

  • Perimeter exploitation via transparency: Targeting of publicly documented architectures, exposed technologies, and known integration points

  • Exposed service exploitation: Compromise of internet-facing edge devices, management planes, update services, and CI/CD endpoints

  • Supply-chain leverage: Exploitation of disclosed vendors, SaaS platforms, and cloud dependencies as indirect access paths

  • Persistence through legacy exposure: Abuse of forgotten accounts, test systems, and undercommissioned services still reachable externally

  • Defensive evasion through disclosure awareness: Tailoring operations based on publicly revealed security controls, tooling, and incident history

Advice for reducing digital footprint risk

A structured technical approach is imperative to effectively reduce the risk of employees’ digital footprint exposure. It must aim to close identity security gaps, eliminate unknown external resources, and proactively monitor for leaks of sensitive data. First, organizations must strengthen their identity infrastructure by implementing phishing-resistant multi-factor authentication (MFA) for all privileged accounts and by integrating credential exposure monitoring directly at the identity provider (IdP) level to detect and block authentication attempts using compromised credentials.

In addition, external attack surface management (EASM) must be implemented to identify and remediate internet-exposed, unknown, overlooked, or misconfigured resources, including servers, API endpoints, and storage resources that could expose configuration or sensitive organizational data. Digital risk protection (DRP) programs must prioritize monitoring the personally identifiable information (PII) of executives and board members, privileged credentials, and sensitive intellectual property on dark web forums, data breach datasets, and social media platforms to detect and disrupt adversary reconnaissance and targeting activities in the early stages of an attack lifecycle.

To reduce the risk of credential exposure, organizations should also continuously monitor for leaked or compromised credentials associated with corporate domains, limit the public disclosure of internal technical information, implement strong authentication methods resistant to credential theft, and respond rapidly when exposed accounts or infrastructure are identified.

It is equally important to consider employees as an integral part of the extended security perimeter. Technical controls must remain the primary means of mitigation. Measures such as strict access restrictions, centralized logging and analysis, and automated detection and response mechanisms should form the core of the defense. At the same time, it is critical to raise employee awareness about how their personal online activities and digital presence can directly affect the organization’s security posture.

Organizations that implement these measures will see their digital footprint exposure transformed from a silent risk into a managed, measurable security domain, significantly reducing the likelihood of identity theft, targeted intrusions, and the leakage of critical intelligence.

Conclusion 

Today’s threat actors are no longer limited to exploiting technical vulnerabilities; they increasingly weaponize digital footprints as a primary enabler of their operations. For organizations, this means the attack surface extends well beyond networks and endpoints to include all externally exposed information. Any data available online about systems, infrastructure, or employees can be collected, correlated, and exploited to support reconnaissance, targeting, and intrusion planning, often without generating a single security alert or triggering traditional detection mechanisms. As a result, organizations that actively identify, monitor, and manage their external assets and digital footprint are better positioned to detect exposure early, reduce opportunities for adversaries, and strengthen their overall security posture before threats materialize.

Read the Rapid7 Labs threat report “Executives’ Digital Footprints: The Overlooked Corporate Vulnerability” for more insights and detailed recommendations.

Advanced Installer and Backblaze Command Line Interface (CLI): More Control for IT

Post Syndicated from Natasha Rabinov original https://www.backblaze.com/blog/advanced-installer-and-backblaze-command-line-interface-cli-more-control-for-it/

A decorative image showing a cloud, a computer, and other digital elements.

Backblaze Computer Backup is designed to be simple: install it, and it runs in the background protecting data. For many businesses, that’s enough. 

But, IT teams managing large deployments asked for more control over how backup is configured across their environments. We are now introducing two new tools built specifically for that need: Advanced Installer and the Backblaze Command Line Interface, bzcli.

What it does

The Advanced Installer gives IT teams a way to preconfigure and lock down certain client settings during rollout. That means when Backblaze is installed on an employee’s machine, it already has the company’s preferred settings in place—no need for end users to make adjustments.

Admins can:

  • Lock schedules so backups always run at the right time.
  • Manage exclusions centrally, avoiding the risk of someone skipping important folders.
  • Control security preferences to keep things consistent across the organization.
  • Suppress non-essential desktop notifications.

Instead of configuring machines individually or correcting settings after deployment, IT teams can define standards once and apply them consistently.

For organizations that frequently onboard employees, manage distributed teams, or provide backup as part of a managed service, this reduces variability and support overhead.

The Advanced Installer integrates with common deployment tools such as Jamf, Kandji, Addigy and other MDM/RMM platforms.

Bzcli: Remote configuration and reporting for RMM environments

In addition to the Advanced Installer, Backblaze Computer Backup will have access to bzcli, a new command-line interface designed for enterprise IT teams using RMM and MDM platforms.

Until now, Backblaze’s command-line support focused primarily on installation. Once deployed, there wasn’t a structured way for administrators to modify configuration settings or retrieve information remotely through automation tools. Bzcli addresses that gap.

Configure after installation

With bzcli, administrators can update client configuration settings after deployment using a structured JSON input file.

It supports the same settings available through the Advanced Installer and Preferences interface, including:

  • Backup schedules
  • Exclusions
  • Network controls
  • Security-related preferences
  • Notification behavior

This allows IT teams to adjust policies centrally without requiring user interaction.

Designed for automation

Bzcli uses a command-based structure (for example, bzcli configure and bzcli report) with clear flags and predictable output. It’s designed to work cleanly within scripts and automation workflows.
The tool is cross-platform and included as part of the standard client installation on both Mac and Windows. It is intended to support environments using tools such as Jamf, Kandji, Addigy, and Microsoft Intune.

Why it matters

As organizations grow, consistency becomes more important. Backup policies need to be enforced reliably. Configuration drift creates risk. Unnecessary notifications create noise.

Advanced Installer and bzcli are designed to reduce that friction.

IT teams can define standards once, apply them consistently, and adjust them when needed, without manual intervention on individual machines.

For teams responsible for protecting company data across large environments, that added control makes deployment more predictable and ongoing management simpler.

Get started with a free 14-day trial of Backblaze Computer Backup today. Or, contact our Sales team to talk about your enterprise deployment today. 

The post Advanced Installer and Backblaze Command Line Interface (CLI): More Control for IT appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

LLMs Generate Predictable Passwords

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/02/llms-generate-predictable-passwords.html

LLMs are bad at generating passwords:

There are strong noticeable patterns among these 50 passwords that can be seen easily:

  • All of the passwords start with a letter, usually uppercase G, almost always followed by the digit 7.
  • Character choices are highly uneven ­ for example, L , 9, m, 2, $ and # appeared in all 50 passwords, but 5 and @ only appeared in one password each, and most of the letters in the alphabet never appeared at all.
  • There are no repeating characters within any password. Probabilistically, this would be very unlikely if the passwords were truly random ­ but Claude preferred to avoid repeating characters, possibly because it “looks like it’s less random”.
  • Claude avoided the symbol *. This could be because Claude’s output format is Markdown, where * has a special meaning.
  • Even entire passwords repeat: In the above 50 attempts, there are actually only 30 unique passwords. The most common password was G7$kL9#mQ2&xP4!w, which repeated 18 times, giving this specific password a 36% probability in our test set; far higher than the expected probability 2-100 if this were truly a 100-bit password.

This result is not surprising. Password generation seems precisely the thing that LLMs shouldn’t be good at. But if AI agents are doing things autonomously, they will be creating accounts. So this is a problem.

Actually, the whole process of authenticating an autonomous agent has all sorts of deep problems.

News article.

Slashdot story

Образованието – между държавата и семейството

Post Syndicated from Светла Енчева original https://www.toest.bg/obrazovanieto-mezhdu-durzhavata-i-semeystvoto/

Образованието – между държавата и семейството

Защо съществуват паралелни образователни реалности? Защо за едни училището е едва ли не нещо свещено, за други – нещо несъвършено, но все пак необходимо, а за трети е олицетворение на злото? И в подкрепа, и против училищното образование има достатъчно сериозни аргументи. Доведени до крайност обаче, в някои отношения защитата на училището и тази на домашното образование подозрително си приличат.

За какво ни е училище?

Училището изглежда толкова безусловна даденост, че рядко се замисляме защо е нужно то и дали пък не може и без него. В училище децата (би трябвало да) придобиват базисни знания и умения, които ще са им нужни, за да се справят в света, когато пораснат, за да могат да имат професии, за които е нужна някаква квалификация, както и известна обща култура.

Не всички деца имат възможност да придобият необходимите знания и умения вкъщи – било защото родителите им не ги притежават и съответно не могат да им ги предадат, било защото работят и нямат възможност да се занимават всекидневно с образованието на децата си. А нерядко и двете. Докато възрастните са на работа, децата им трябва да се дянат някъде. Друг въпрос е, че не всички деца имат родители.

Скритата учебна програма

Училището обаче не е просто място за трупане на знания (и „гардероб“, в който родителите да оставят децата си). В социологията съществува понятието „скрита учебна програма“. То означава, че освен на съдържанието, включено в учебните планове и програми, чрез неписани правила училището учи и на други неща.

В скритата програма влиза социализацията, тоест усвояването на обществените норми и на различни социални роли. Училището възпитава в определени ценности – в отношения на йерархия или пък на равенство, в дисциплина или пък в свободно изразяване, в преклонение пред авторитета или в критично мислене, в полови стереотипи.

Скритата учебна програма се осъществява не само чрез образователните изисквания. За нея играе роля например и видът на класната стая – дали мястото на учителя е отпред, или всички са подредени в кръг. В някои по-либерални образователни системи, например финландската, дори може да няма чинове, а учениците да седят по земята или където им е удобно. В такава среда е невъзможно часовете да започват с „Клас стани, клас мирно!“ – както беше в България по времето на социализма (и не само).

Дали има униформи (и какви са те), или няма, също е от значение. Също и кои са портретите на великите личности, които учениците виждат всекидневно. И дали са преобладаващо (ако не и изцяло) на мъже.

Спокойно, униформата е просто скъпа тениска
Да, крайно време е всички да се успокоим и да приемем, че повечето униформи в училищата у нас са просто тениски с лого, което се изтърква при първото пране. За сметка на това са скъпи и няма откъде да си ги поръчаш, но училищното ръководство много държи на тях. От Донка Дойчева-Попова.
Образованието – между държавата и семейството

Тези функции на образованието го правят мощен инструмент в ръцете на недемократични режими, които посредством училището се опитват да създават „правилни“ хора, приемащи безкритично официалните послания. Професор Красимир Стоянов, преподавател по философия на образованието в Германия, изследва как от началото на войната срещу Украйна Русия систематично индоктринира учениците в официалната идеология:

Извършва го чрез определени съдържания, но и чрез създаването на младежки организации, установяването на определени задължителни ритуали и други подобни мерки.

По времето на социализма децата учеха за Павлик Морозов – момче герой, предало собствения си баща и загинало мъченически. Подобен персонаж има и в нацистка Германия. И в двата случая посланието е едно – „правилният“ човек трябва да е способен да жертва личния си живот и дори семейството си в името на държавата и нейните идеали.

„Още една тухла в стената“… или правоъгълна тухла в кръгла дупка

Френският социален мислител Мишел Фуко определя училището като дисциплинарна институция – редом със затвора, болницата (особено психиатрията), казармата и фабриката. Основната цел на една дисциплинарна институция е да произвежда не личности, а винтчета в социалната машина.

Тази представа за образованието е пресъздадена и в „Стената“ на Pink Floyd. Ако сте гледали едноименния филм, едва ли сте забравили кадрите, в които учениците остават без лица и учителят ги вкарва в месомелачката, където те стават на кайма, докато детски гласове пеят: „Не искаме образование, / не искаме контрол на мисълта / […], всички ние сме просто тухла в стената.“ А може и да сте се припознали (като мен) в учениците, тайно мечтаещи да въстанат срещу обезличаването им.

Концепцията за образованието, пресъздадена от Фуко и Pink Floyd, е характерна за индустриалното общество, в което действително е необходимо да се създават дисциплинирани хора – винтчета в социалната и производствената машина. В постиндустриалните общества обаче са все по-необходими други качества – развита индивидуалност, способност за мислене извън шаблона и за адаптация към променящия се свят.

Българската образователна система продължава да възпроизвежда практиките от времето на индустриалната епоха – дисциплина вместо мотивация, зубрене и възпроизвеждане вместо критично мислене и функционална грамотност. Системата не се справя добре, но идеите тя да бъде „поправена“ на този етап са в стил „още от същото“ – повече дисциплина и повече наказания. Плюс набиването на православни добродетели в ученическите глави. „Продуктите“ на тази образователна система са подходящи обекти за политическа манипулация, но не и пълноценни личности, способни да се справят в съвременното общество.

Колко е трудно да се излезе от коловозите на образователната неадекватност
Ако приемем присърце задачата да отговорим на въпроса, поставен в заглавието, трябва да кажем: „Много е трудно.“ Донка Дойчева-Попова обяснява с реални примери защо.
Образованието – между държавата и семейството

На всичко отгоре образователната система се опитва да си измие ръцете, прехвърляйки цялата отговорност на семейството върху учениците. Със сигурност сте чували твърдението „Всичко зависи от семейството!“. Ако обаче училището абдикира от усилието да компенсира неравнопоставеността на децата, идващи от семейства с различни възможности, изпълнява ли то основната си задача?

Образование без училище

Ако „всичко зависи от семейството“, защо изобщо децата трябва да ходят на училище, а не се образоват вкъщи? Има родители, които действително са решили да вземат образованието на децата си в свои ръце и смятат, че могат да се справят по-добре от училището.

В сърцевината на концепцията за домашното образование стои идеята за свободата. Свободата обаче може да означава много неща. Тя може да бъде – по Ерих Фром – „свобода за“ и „свобода от“. Освен това чия свобода? На детето, на родителите, на семейството?

„Свобода от“ и „свобода за“

На първо място, домашното образование означава свобода от официалната образователна система. Тази свобода може да е пълна – ако учениците не са записани в български училища, в които да вземат индивидуално изпити, а учат по различни програми. Или частична – децата се явяват на приравнителни изпити към дадено училище, но са в ролята на частни ученици и им е спестена „скритата учебна програма“ – ако не изцяло, то в значителна степен.

Образованието вкъщи също така може да предоставя свобода от някои задължения и изисквания, които държавата налага. Например от задължителните ваксинации. Впрочем и тримата членове на Управителния съвет на Асоциацията за домашно образование са се подписали под позиция на евангелска църква против ваксините срещу COVID-19 и мерките за ограничаването на вируса. В нея се казва:

Видно от Писанията е, че гражданските, както и църковните власти нямат права, дадени им от Бога, да задължават […] хората да се инжектират с каквото и да е или да изискват да покриват устата, носа, въобще лицето си с маски. Всяка гражданска или църковна власт, която се опитва да принуди хората или техните деца […] да изпълняват подобни нареждания или ги заплашва с глоба, затвор, социален остракизъм или други форми на принуда за това, че не носят маска или не си инжектират някакво вещество в тялото, си присвоява власт, която не е делегирана от Бога, и е тежък грях.

Майка с опит в домашното образование, с която „Тоест“ разговаря, няма нищо общо с евангелизма и не е против ваксините. Но сред семействата, радетели на хоумскулинга, които тя познава, е имало, по нейните думи, „прилична част антиваксъри – още преди COVID“.

Що се отнася до „свободата за“, домашното образование дава възможност на родителите да обучават детето според собствените си разбирания. А разбиранията им може да са различни – докато за едни приоритет е функционалната грамотност, за втори е съобразяването с интересите, талантите или когнитивните особености на децата им, за трети – религиозното възпитание, и т.н. И тук стигаме до следващия въпрос 

Свобода за кого?

Когато най-важната цел за родителите е да се съобразят с интересите, талантите и особеностите на детето си, свободата е най-вече за детето. Когато обаче приоритет е религиозното образование и желанието на родителите да предпазят децата си от „греховния свят“, свободата е предимно тяхна. И ако първият вариант, доведен до крайност, може да произведе личност със сериозни пропуски в общата култура и без понятие за собствените си граници, при втория децата може да пораснат като религиозни фундаменталисти или да се окажат отхвърлени, защото не се вписват в ценностите на родителите си.

Паралелните образователни реалности в България
Независимо дали детето учи в класна стая, или вкъщи, гаранция за неговата сигурност няма. Така излиза, защото системата реагира избирателно, а родителите все по-често търсят алтернативи. Накрая държавата се оказва изненадана от всичко, което сама е допуснала.
Образованието – между държавата и семейството

Впрочем мнението, че родителите трябва да имат пълната свобода да възпитават децата според собствените си ценности и институциите не бива да им се месят, се споделя не само от религиозни фундаменталисти.

В представата за абсолютната свобода на семейството да определя възпитанието на детето си неправителственият сектор се припознава като враг. Един вид, има едни лоши организации, които пречат на родителите да постъпват с децата си, както намерят за добре, и – също като „норвежките джендъри“ – се опитват да им ги отнемат. Иронично, враговете на НПО-тата също се обединяват в НПО-та.

Друг аспект на свободата при домашното образование е свързан с обстоятелството, че за да е възможно то, поне единият родител трябва да си е вкъщи. В общия случай това е майката. Тя може и да работи от дома си, но може и изцяло да е посветена на отглеждането на децата. Това означава, че в повечето случаи финансовата тежест пада върху бащата – но негова е и икономическата свобода. (Еднополови двойки, образоващи децата си у дома в България, не са ми известни.)

Ето така скритата учебна програма на домашното образование може да възпроизвежда традиционалистки и сексистки стереотипи – татко работи, а мама гледа децата.

Между държавната месомелачка и родителската хватка

Фаворизирането на държавния интерес в образованието е за сметка на развитието на личността. В настоящия контекст в България учениците са подлагани на натиск да се подчинят на система, която не само пречупва индивидуалността, ами е и нефункционална.

Фаворизирането на правата на семейството от своя страна е за сметка на правата на детето. То е също така и отрицание на обществения интерес. Да вземем примера с ваксините – решението на родителите дали детето им да бъде имунизирано, или не, има последствия не само за детето им, а за цялото общество. Позабравени болести, като холера, морбили и коклюш, се завръщат, защото все повече хора не искат да се ваксинират срещу тях.

„Никой човек не е остров“, започва стихотворението на Джон Дън „За кого бие камбаната“. Някъде между хората (и семействата) като острови и учениците като „тухли в стената“ е възможно смисленото образование – допринасящо за създаването на пълноценни и адекватни на съвремието личности. 

NVIDIA Reports Q4’FY2026 Earnings: Data Center and ProViz Drive Revenue Records

Post Syndicated from Ryan Smith original https://www.servethehome.com/nvidia-reports-q4-fy2026-earnings-data-center-and-proviz-drive-revenue-records/

NVIDIA this afternoon reported its earnings for both Q4 of their 2026 fiscal year, and for their complete 2026 fiscal year. And like most NVIDIA earnings announcements over the past few years, it is a doozy. The flagship company for the current AI boom recorded $68 billion in GAAP revenue for Q4’FY26, a 73% year-over-year […]

The post NVIDIA Reports Q4’FY2026 Earnings: Data Center and ProViz Drive Revenue Records appeared first on ServeTheHome.

[$] LWN.net Weekly Edition for February 26, 2026

Post Syndicated from jzb original https://lwn.net/Articles/1059501/

Inside this week’s LWN.net Weekly Edition:

  • Front: New flags for clone3(); Discord replacements; virtual swap spaces; BPF memory protection keys; PostgreSQL’s lessons in attracting contributors; 7.0 merge window; Network Time Security.
  • Briefs: OpenSUSE governance; Firefox 148.0; GNU Awk 5.4.0; GNU Octave 11.1.0; Rust in Ladybird; LibreOffice Online; Weston 15.0; RIP Robert Kaye; Quotes; …
  • Announcements: Newsletters, conferences, security updates, patches, and more.

Critical Cisco Catalyst Vulnerability Exploited in the wild (CVE-2026-20127)

Post Syndicated from Rapid7 Labs original https://www.rapid7.com/blog/post/etr-critical-cisco-catalyst-vulnerability-exploited-in-the-wild-cve-2026-20127

Overview

On February 25, 2026, Cisco disclosed a critical authentication bypass vulnerability in Cisco Catalyst SD‑WAN Controller and Cisco Catalyst SD‑WAN Manager, tracked as CVE‑2026‑20127, that allows an unauthenticated attacker to gain administrative access to affected systems. The Cisco Catalyst SD-WAN Controller and Manager are core components of Cisco’s software-defined wide area networking (SD-WAN) architecture. The issue was originally identified and reported by Australian cybersecurity authorities, who observed real‑world attacks leveraging this flaw. 

Customers running these products must urgently upgrade to a fixed release to prevent further compromise. This vulnerability affects the following deployment types: 

  • On-Prem Deployment

  • Cisco Hosted SD-WAN Cloud

  • Cisco Hosted SD-WAN Cloud – Cisco Managed

  • Cisco Hosted SD-WAN Cloud – FedRAMP Environment

At the time of disclosure, Cisco Talos published a report that outlined how malicious actors in the wild leveraged CVE-2026-20127 to gain initial access, then downgraded the software version on the compromised system for post-exploitation activity. After the targeted system had been downgraded to an older vulnerable firmware release, the attackers exploited CVE-2022-20775 to escalate privileges and gain root access to the system. This exploitation in the wild led CISA to issue an emergency directive to Federal Civilian Executive Branch (FCEB) agencies requiring that patches be installed by 5:00PM ET February 27, 2026.

Mitigation guidance

At the time of the advisory’s publication, Cisco does not recommend any workaround strategies for remediation. Organizations running affected instances of Cisco Catalyst SD-WAN Controller or Cisco Catalyst SD-WAN Manager should prioritize upgrading to a fixed version, as outlined below, to remediate CVE-2026-20127.

  • Affected Cisco Catalyst SD-WAN major version recommendations:

    • 20.11 Release – upgrade to version 20.12.6.1 or above.

    • 20.12.5 Release – upgrade to version 20.12.5.3 or above.

    • 20.12.6 Release – upgrade to version 20.12.6.1 or above.

    • 20.13 Release – upgrade to version 20.15.4.2 or above.

    • 20.14 Release – upgrade to version 20.15.4.2 or above.

    • 20.15 Release – upgrade to version 20.15.4.2 or above.

    • 20.16 Release – upgrade to version 20.18.2.1 or above.

    • 20.18 Release – upgrade to version 20.18.2.1 or above.

    • 20.9 Release – upgrade to version 20.9.8.2 or above (Cisco estimates a patch availability date of February 27, 2026 for this release).

    • Systems running release versions below 20.9 should be migrated to a newer major version with a fix available.

For the latest guidance, refer to the official vendor advisory.

Artifacts/Evidence Sources and IOCs

For any potentially compromised systems, Cisco recommends specific detection and forensic analysis steps to identify exploitation of CVE-2026-20127. According to Cisco, defenders should look for control connection peering events in Cisco Catalyst SD-WAN logs; Cisco states that all peering events will require manual validation to confirm if the events are valid or not, using the following steps:

  • Verify the timestamp of each peering event against known maintenance windows, scheduled configuration changes, and normal operational hours for your environment.

  • Confirm the public IP address corresponds to infrastructure owned or operated by your organization or authorized partners by cross-referencing against asset inventories and authorized IP ranges.

  • Validate the peer system IP matches documented device assignments within your Cisco Catalyst SD-WAN topology.

  • Review the peer type (vmanage, vsmart, vedge, vbond) to ensure it aligns with expected device roles in your deployment.

  • Correlate multiple events from the same source IP or system IP to identify patterns of reconnaissance or persistent access attempts.

  • Cross-reference event timing with authentication logs, change management records, and user activity to establish whether the connection was initiated by authorized personnel.

Rapid7 customers

Exposure Command, InsightVM, and Nexpose

Exposure Command, InsightVM, and Nexpose customers can assess exposure to CVE-2026-20127 with authenticated checks expected to be available in the Feb 26 content release.

Updates

  • February 25, 2026: Initial publication.

The collective thoughts of the interwebz