How Fanatics Commerce built a scalable email platform on Amazon SES

2026-07-28 Paul DeLaria

Post Syndicated from Paul DeLaria original https://aws.amazon.com/blogs/messaging-and-targeting/how-fanatics-commerce-built-a-scalable-email-platform-on-amazon-ses/

Fanatics Commerce is a leading designer, manufacturer, and retailer of licensed consumer products, including fan gear, jerseys, lifestyle and streetwear products, headwear, and hardgoods. Whether it’s a championship jersey or a last-minute gift, fans trust Fanatics to deliver and that trust extends to every digital touchpoint along the way.

Every order confirmation, shipping notification, and account update represents a moment of connection with a fan. Fans check their inbox after buying a jersey, track a package before game day, and verify their account when they sign up. These emails are the backbone of the fan experience.

The Fanatics Commerce engineering team built a modern, scalable email platform on Amazon Simple Email Service (Amazon SES), designed from the start for high deliverability, operational efficiency, and seasonal scale that comes with serving more than 100 million fans. When events like Super Bowl, NBA Finals, or World Series drive a surge in orders, the platform has to keep up without missing a beat.

This post walks through what drove the decision, the platform architecture, migration, the key engineering decisions, and what comes next for a large transactional email platform running on Amazon SES.

The case for change

As Fanatics Commerce grew, the engineering team saw an opportunity to elevate their email infrastructure by using Amazon SES capabilities purpose-built for operating at scale.

Dedicated IP addresses for full reputation control. With dedicated IPs in Amazon SES, Fanatics Commerce could own their sending reputation entirely removing dependency on shared infrastructure and gaining direct control over deliverability outcomes.
Granular traffic segmentation. Amazon SES offered the ability to treat transactional and marketing email as distinct, independently managed streams each with its own configuration sets, sending identities, and performance tuning rather than routing everything through a single pipeline.
Real-time deliverability visibility. At the scale of millions of fans, the team needed domain-level insight into open rates, bounce rates, and complaint rates in real time. The built-in analytics and Virtual Deliverability Manager in Amazon SES gave them the detail to diagnose shifts quickly and act decisively.
Domain-level isolation and authentication. SES enabled the team to assign dedicated subdomains and authentication policies (DKIM, SPF, DMARC) per email type ensuring high-priority transactional messages maintain protected, independent reputations.
Operational automation at scale. IP warming, reputation monitoring, and sending pattern adjustments could be managed programmatically through SES rather than requiring manual intervention keeping pace with Fanatics Commerce’s volume growth.

The team recognized the opportunity to move beyond incremental fixes. Rather than continuing to adapt an existing system, they set out to build a purpose-built transactional email platform on AWS that addressed all of these needs from the ground up.

Why Fanatics Commerce chose Amazon SES

After evaluating their requirements against several email service providers, the Fanatics Commerce team chose Amazon SES for its combination of reputation control, native observability, and tight integration with their existing AWS infrastructure. Several capabilities stood out during their evaluation.

The priority was reputation control. SES supports dedicated IP pools with separate pools for high-priority transactional, account, and lower-priority traffic, ensuring noisy streams cannot contaminate critical flows.

Visibility was equally important. As Rajat Banerjee, Fanatics’ engineering leader, explains:

“SES emits detailed JSON events for every send, delivery, bounce, complaint, open, and click into S3, and we model that data directly in our warehouse. Tagging each event with order, site, and mailbox provider, plus the user agent SES captures on opens and clicks, lets us slice deliverability at the level we need to run at Fanatics Commerce scale. That granularity is what let us refine our NPS survey email, power order attribution reporting, and debug real production issues over the last few months.”

The team also valued owning the full delivery path, from provider through messaging queue, internal processing, and status store, with rendered email HTML stored in-house. This end-to-end visibility strengthens support and debugging workflows.

The migration scope is strictly transactional, service, and survey email with high but predictable baseline volume and large event-driven spikes. SES is purpose-built for this pattern, with configurable IP warm-up strategies and the flexibility to choose between standard and managed dedicated IPs.

Finally, SES integrates natively with AWS metrics, notifications, queues, and storage, allowing monitoring, alerting, and failure handling to follow the same patterns used elsewhere in the Fanatics stack.

“If SES works for Amazon at scale, I figured it would work for us. We had also seen SES handle our load before, during a failover from our primary provider on a shared IP setup. That gave us the confidence to commit early and design around it.”

Platform architecture

The Fanatics Commerce team designed their email platform with the same engineering rigor they apply to their commerce systems. The architecture reflects a technology first approach to email operations.

Figure 1 — Fanatics Commerce transactional email platform on Amazon SES

Application layer

The Fanatics application connects to Amazon SES through IAM role-based authentication, with no stored credentials anywhere in the pipeline. This approach simplified security management and eliminated credential rotation as an operational concern.

Managed dedicated IPs

Fanatics started with dedicated IPs and pivoted to managed dedicated to let SES handle IP warming and management. Managed IPs let Amazon SES handle reputation optimization automatically, adjusting sending patterns, warming new IPs, and responding to reputation signals without manual intervention. This was a deliberate engineering decision: the team wanted to invest their time building great fan experiences, not managing IP reputation.

“We started with standard dedicated IPs and managed warming ourselves. Reputation management at our scale became more challenging than we wanted to own, so on AWS architects’ recommendation we moved to managed dedicated IPs. We would rather have our engineers enhancing the fan experience than tuning IP reputation.”

Domain and subdomain strategy

The domain architecture reinforces sender reputation through isolation. Transactional email sends from a dedicated subdomain with its own DKIM signing, SPF records, and DMARC policy. This ensures mailbox providers evaluate transactional email reputation independently, protecting the deliverability of order confirmations and shipping notifications regardless of what other email streams do.

Multi-tenant email design

The team designed a multi-tenant architecture that separates email streams into distinct tenants with independent configuration sets, dedicated IPs, and domain strategies. Each tenant maintains its own reputation, its own IP warming schedule, and its own deliverability metrics. If one tenant has reputation challenges, that specific tenant will be paused without disrupting other tenants.

This isolation is a core design principle. Transactional email, the email fans depend on, runs in its own tenant with dedicated infrastructure. Commercial email operates in a separate tenant. The architecture ensures each stream scales independently and maintains its own deliverability profile.

Real-time observability

Amazon SES Virtual Deliverability Manager (VDM) gives the Fanatics Commerce team a real-time, centralized view of key deliverability metrics including open rates, bounce rates, and complaint rates at the tenant or configuration set level. With VDM, the team is able to spot deliverability shifts early, diagnose issues with confidence, and take action before fans ever notice a problem in their inbox.

Scaling with the seasons

Sports merchandise is inherently seasonal. The platform needed to handle volume swings, from baseline traffic to peak holiday and playoff demand, without degrading deliverability.

During the 2025 holiday season, the platform scaled sending volume by 48x in five months, from initial rollout to full peak capacity across Black Friday, Cyber Monday, and the holiday gifting season. The architecture handled this surge while preserving deliverability, demonstrating that the multi-tenant design and managed dedicated IPs absorb seasonal spikes while maintaining consistent inbox placement rates.

The team phased their rollout by email type and volume, monitored deliverability metrics at each stage, and adjusted sending patterns based on real time feedback from mailbox providers. As the volume scales rapidly, this methodical approach ensured deliverability remained high.

The partnership model

This platform succeeded because of the partnership between Fanatics Commerce and AWS. The engagement brought together an account team TAM, a Solutions Architect, and a Worldwide Specialist SA, each contributing a different perspective.

The TAM coordinated the engagement by connecting Fanatics Commerce engineering with AWS specialists and driving architecture reviews from initial planning through peak holiday season scale.

Rajat Banerjee, Senior Manager of Engineering at Fanatics Commerce, led this initiative end to end from platform design all the way through production rollout. He and his team designed the domain and subdomain strategy that protects sender reputation across brands and ran a phased migration that scaled sending volume to full peak capacity without any disruption to delivery. SES built real-time analytics and reporting pipelines that give team visibility into delivery rates, bounces, and engagement. That visibility transformed incident response and helped the team optimize sending behavior at scale.

This model, customer engineering plus a cross-functional AWS team, accelerated decisions and shortened the feedback loop between architecture questions and production answers. The team had direct access to SES product expertise whenever they needed it, which enabled them to make timely informed decisions.

What’s next

Tenant-level isolation within SES – Handling each tenant’s sending, reputation, and operational signals independently end to end.

Deep linking from transactional emails into the Fanatics mobile app so fans can tap a link in an order or shipping email and land directly on the right screen in the app instead of the web.

Conclusion

Fanatics Commerce set out to build an email platform that matches the speed and reliability fans expect from the brand. By choosing Amazon SES and investing in purpose-built architecture, multi-tenant isolation, managed dedicated IPs, domain-level reputation control, and real-time observability, the team eliminated the operational trade-offs that come with scaling large email systems.

The results speak for themselves: the platform scaled sending volume 48x in five months, maintained high inbox placement rates through peak holiday and playoff demand, and gave the engineering team the visibility to diagnose and resolve deliverability issues in minutes rather than days.

More importantly, this platform frees the Fanatics Commerce team to focus on what matters most, building great fan experiences rather than managing IP reputation and chasing deliverability problems. Every order confirmation that lands in a fan’s inbox on time is a moment of trust earned.

Whether you’re sending millions of emails or only beginning to outgrow your current setup, the patterns in this post apply at any scale. Start by identifying where your current email infrastructure makes you choose between deliverability and growth. Amazon SES is built so you don’t have to.

To learn more about Amazon SES, visit the Amazon SES product page. To explore the Fanatics Commerce AWS journey, read Migration at Scale: The Fanatics Commerce AWS Journey.

About the authors

2026 Phase 1a IRAP report is now available on AWS Artifact for Australian customers

2026-07-28 Patrick Chang

Post Syndicated from Patrick Chang original https://aws.amazon.com/blogs/security/2026-phase-1a-irap-report-is-now-available-on-aws-artifact-for-australian-customers/

Amazon Web Services (AWS) is excited to announce that the latest version of Information Security Registered Assessors Program (IRAP) report (Phase 1a – full assessment) is now available through AWS Artifact. An independent Australian Signals Directorate (ASD) certified IRAP assessor completed the IRAP assessment of AWS in June 2026.

The new IRAP report includes four additional AWS services that are now assessed at the PROTECTED level under IRAP. This brings the total number of services assessed at the PROTECTED level to 167.

The four newly assessed services are:

For the full list of services, see the IRAP tab on the AWS Services in Scope by Compliance Program page.

We have developed an IRAP documentation pack to help our Australian customers and their partners plan, architect, and assess risk for their workloads when they use AWS cloud services.

We developed this pack in accordance with the Australian Cyber Security Centre (ACSC) Cloud Security Guidance and Cloud Assessment and Authorisation framework, which addresses guidance within the Australian Government’s Information Security Manual (ISM, September 2025 version), the Department of Home Affairs’ Protective Security Policy Framework (PSPF), and the Digital Transformation Agency’s Secure Cloud Strategy.

The IRAP pack on AWS Artifact also includes newly updated versions of the AWS Consumer Guide and the whitepaper Reference Architectures for ISM PROTECTED Workloads in the AWS Cloud.

Reach out to your AWS representatives to let us know which additional services you want to see in scope for upcoming IRAP assessments. We strive to bring more services into scope at the PROTECTED level under IRAP to support your requirements.

Build a contract compliance search system with Amazon OpenSearch

2026-07-28 Durga Prasad

Post Syndicated from Durga Prasad original https://aws.amazon.com/blogs/big-data/build-a-contract-compliance-search-system-with-amazon-opensearch/

For legal and compliance teams, auditing a repository of thousands of contracts for a single regulatory obligation shouldn’t take weeks. But with keyword search, it often does. A search for “inadvertent access notification” returns exact matches while missing functionally equivalent clauses such as “security incident disclosure” or “unauthorized access reporting.” This creates two problems:

Discovery gap: Critical risk exposure goes undetected because keyword search cannot match semantically equivalent terms across different contracts.

Review latency: After finding relevant contracts, legal counsel must manually scan lengthy documents to locate the specific clauses that matter. This process can stretch from minutes to hours per document.

Amazon OpenSearch Service is a fully managed search and analytics service that configures, manages, and scales OpenSearch clusters in the AWS Cloud. It supports use cases from log analytics and application monitoring to full-text search and real-time security analytics. It also supports AI-powered semantic search.

Amazon OpenSearch Service addresses both problems through two capabilities:

Semantic search retrieves contracts based on meaning rather than exact keyword matches, closing the discovery gap.
Semantic highlighting pinpoints the exact clauses within retrieved contracts that answer the query, reducing review time from hours of manual scanning to seconds of targeted reading.

In this post, you build a contract compliance search system that combines semantic search with semantic highlighting in Amazon OpenSearch Service. You deploy the solution using two AWS CloudFormation stacks, test it with synthetic contract documents, and see how a single query surfaces both the right contracts and the right clauses within them.

Solution overview

The solution uses a two-stage retrieval and extraction pipeline. First, semantic search identifies relevant contracts across the repository. Then, semantic highlighting marks the specific clauses within those contracts that match the query intent.

The following diagram illustrates the solution architecture:

Solution architecture showing contracts flowing from Amazon S3 through OpenSearch Ingestion and Amazon Bedrock embeddings to semantic search and Amazon SageMaker AI highlighting

Upload contracts to Amazon Simple Storage Service (Amazon S3) – Contract documents (JSON format) are uploaded to an Amazon S3 bucket, which serves as the centralized document repository.
Amazon OpenSearch Ingestion (OSI) reads from S3 – A serverless OSI pipeline detects new documents in the S3 bucket and reads them for processing.
OpenSearch ingest pipeline generates embeddings through Amazon Bedrock – As documents arrive, the ingest pipeline’s text_embedding processor invokes Amazon Titan Text Embeddings V2 through an ML Commons Bedrock connector. This converts contract text into 1024-dimension vector representations, stored in a k-NN index that uses the faiss engine.
User submits a search query – A user queries the system with natural language (for example, “data protection regulations”) through a test AWS Lambda function that forwards the request to OpenSearch using the neural query type.
OpenSearch generates the query embedding – OpenSearch converts the user’s natural language query into a vector embedding using the same machine learning (ML) Commons Amazon Bedrock connector and Amazon Titan V2 model.
Amazon OpenSearch Service performs semantic search – OpenSearch uses k-NN vector similarity to retrieve contracts that are semantically relevant to the query, even when exact terminology differs.
Amazon SageMaker AI performs semantic highlighting – The opensearch-semantic-highlighter-v1 model, hosted on an Amazon SageMaker AI GPU endpoint, scores sentence relevance using cross-encoder inference and wraps the matching clauses in  tags for targeted reading.

How semantic search and semantic highlighting work together

The system processes queries in two steps:

Step 1 – Semantic search (document discovery): You query the contract corpus using natural language. The system retrieves contracts with semantically similar concepts, even when exact terminology differs. For example, searching for “force majeure” returns contracts discussing “natural disasters” or “unforeseeable circumstances” because the system understands these concepts are related.

Step 2 – Semantic highlighting (clause identification): After relevant contracts are retrieved, semantic highlighting automatically marks the clauses that semantically match your search intent. Instead of scanning pages of legal text, you immediately see the specific paragraphs that answer your question.

The difference between standard keyword highlighting and semantic highlighting is significant:

Keyword highlighting wraps individual matching words: termination and rights.
Semantic highlighting wraps entire relevant clauses: Upon termination, the consultant must return all confidential information and proprietary materials within 15 business days..

This reduces false positives, cuts review time, and provides explainability for why each document was retrieved.

Semantic highlighting model deployment

Before the system can highlight clauses based on meaning, the opensearch-semantic-highlighter-v1 model must be deployed to an Amazon SageMaker AI GPU endpoint and registered with the OpenSearch ML Commons plugin through a remote connector.

Stack 2 of the CloudFormation deployment automates this process. It performs the following steps:

Downloads the model artifact from an AWS-managed source and deploys it to an Amazon SageMaker AI endpoint (ml.g5.xlarge).
Creates a remote ML Commons connector in OpenSearch that points to the SageMaker endpoint.
Registers the model with the QUESTION_ANSWERING function so that OpenSearch can use the model’s cross-encoder capabilities to score sentence relevance at query time.

The equivalent manual registration call (handled automatically by the stack) is:

POST /_plugins/_ml/models/_register?deploy=true
{
  "name": "amazon/sentence-highlighting/opensearch-semantic-highlighter-v1",
  "version": "1.0.0",
  "model_format": "TORCH_SCRIPT",
  "function_name": "QUESTION_ANSWERING"
}

You don’t need to run this manually. The deployment script and CloudFormation stack handle model registration end-to-end. The resulting model ID is automatically passed to the query Lambda function for use in semantic highlighting requests.

Index configuration

The index uses a k-NN vector field with 1024 dimensions (matching the Amazon Titan V2 output) and the faiss engine with HNSW method. The mapping includes both a knn_vector field for semantic retrieval and a standard text field for keyword matching and highlighting. When you search for “liability limits,” OpenSearch first retrieves documents through vector similarity, then uses the Amazon SageMaker AI model to identify and wrap the specific relevant sentences in  tags.

PUT /legal-contracts-index
{
  "settings": { "index.knn": true },
  "mappings": {
    "properties": {
      "clause_text": { "type": "text" },
      "clause_embedding": {
        "type": "knn_vector",
        "dimension": 1024,
        "method": {
          "name": "hnsw",
          "engine": "faiss",
          "space_type": "l2"
        }
      }
    }
  }
}

Implementation steps

This section walks you through deploying the solution using two AWS CloudFormation stacks and two shell scripts. You first set up the core infrastructure (OpenSearch, ingestion pipeline, and ML Commons Bedrock connector), then deploy the semantic highlighting model on Amazon SageMaker AI.

Prerequisites

To deploy this solution, you need:

An active AWS account with permissions to create Amazon S3 buckets, AWS Lambda functions, Amazon SageMaker AI endpoints, Amazon Bedrock model access, Amazon OpenSearch Ingestion pipelines, Amazon OpenSearch Service domains, and AWS Identity and Access Management (IAM) roles (including iam:PassRole and sts:AssumeRole). For the exact least-privilege policy, see iam-deployer-policy.json in the repository. Both CloudFormation stacks require the CAPABILITY_NAMED_IAM acknowledgement.
Amazon Bedrock model access enabled for Amazon Titan Text Embeddings V2 (amazon.titan-embed-text-v2:0).
Familiarity with AWS CloudFormation.
Estimated deployment time: approximately 35 minutes.
Estimated cost: approximately USD $ 2.00–3.00 for a quick demo. Delete the stacks promptly after testing.
This post uses US East (N. Virginia) as the deployment AWS Region. Verify service availability in your preferred Region before deploying.

Deploy the solution

The solution deploys using two AWS CloudFormation stacks and two shell scripts. The demo includes synthetic contract documents covering common contract types including software licenses, data processing agreements, managed services, and software as a service (SaaS) subscriptions.

Clone the repository and run the deployment script:

git clone https://github.com/aws-samples/sample-contract-compliance-search-amazon-opensearch.git
cd sample-contract-compliance-search-amazon-opensearch
./deploy.sh

The deployment script creates the following resources across two stacks:

Stack 1:

An Amazon OpenSearch Service domain with fine-grained access control.
An Amazon OpenSearch Ingestion (OSI) pipeline that reads contracts from S3 and sends them to OpenSearch for indexing.
An ML Commons Bedrock connector and ingest pipeline that automatically generates 1024-dimension vector embeddings through Amazon Titan Text Embeddings V2 during document indexing.
A test Lambda function for querying the OpenSearch index using keyword, neural, or hybrid search with semantic highlighting support.
An S3 bucket for storing contract documents.
IAM roles for Lambda functions, the OSI pipeline, and OpenSearch access.

Stack 2:

An Amazon SageMaker AI endpoint hosting the semantic highlighting model.
A Lambda function that creates an ML Commons remote connector in OpenSearch and registers the highlighting model.

After both stacks deploy, the script automatically configures OpenSearch (role mappings, Amazon Bedrock connector, embedding model, k-NN index), ingests the sample contract data, and registers the semantic highlighting model.

The total deployment takes approximately 35 minutes to complete.

(Optional) Automated deployment with Claude Code CLI

If you have Claude Code CLI installed, you can deploy the solution using an AI-assisted workflow that creates a least-privilege IAM role scoped to this demo before deploying:

git clone https://github.com/aws-samples/sample-contract-compliance-search-amazon-opensearch.git
cd sample-contract-compliance-search-amazon-opensearch
./scripts/create-deployer-role.sh
export OS_DEMO_DEPLOYER_ROLE=arn:aws:iam::<ACCOUNT_ID>:role/os-demo-deployer-role
export AWS_DEFAULT_REGION=us-east-1
claude "Deploy the OpenSearch semantic search demo following README.md"

Claude Code reads the repository instructions, assumes the deployer role, deploys both CloudFormation stacks in order, runs the setup scripts, and verifies the deployment end-to-end. The deployer role restricts actions to resources prefixed with os-demo-*, following the principle of least privilege.

Test the solution

After the deployment succeeds, follow these steps to test the solution.

On the Lambda console, choose Functions in the navigation pane.
Choose the function that has os-demo-query in its name.
On the Test tab, in the Event JSON paste this keyword search query {"query": "data protection regulations?", "type": "keyword", "k": 3}
Choose Test to run the Lambda function.

The following screenshot shows the Lambda function test configuration on the AWS Management Console with the keyword search query.

Lambda console Test tab with the keyword search query entered in the Event JSON field

The function processes the query in two ways depending on the search type:

For keyword search (enter: keyword): The function sends a standard match query to OpenSearch, which returns documents containing the exact query terms. The highlight fragments wrap individual matching words like termination and rights.

For neural search (enter: neural): The function sends a hybrid query to OpenSearch combining k-NN (semantic similarity) with keyword matching. OpenSearch automatically generates the query embedding through the ML Commons Amazon Bedrock connector using the same Amazon Titan V2 model. This returns semantically related documents even if they don’t contain the exact query terms. The SageMaker endpoint powers the semantic highlighting, identifying the most relevant clauses within each retrieved document. It wraps entire passages like Upon termination, the consultant must return all confidential information and proprietary materials within 15 business days..

Download the highlight viewer HTML file and open it in the browser. This file helps you view the highlighted text.
Copy the entire execution output of the Lambda execution, paste it into the placeholder in the HTML file, and then choose Load Results.
The following screenshot shows that only the matching keywords are highlighted.

Highlight viewer showing only individual keywords highlighted in the keyword search results

Next, paste the neural search query as input to the Lambda function to see how semantic highlighting works: {"query": "data protection regulations", "type": "neural", "k": 1}
Choose Test to run, and then paste the entire output into the HTML viewer.

The viewer now displays entire sentences highlighted instead of individual keywords.

Highlight viewer showing entire relevant clauses highlighted in the neural search results

Optimizing for scale: batch semantic highlighting

In a standard search, a query might return dozens of relevant contracts. Using the default single inference mode, OpenSearch makes a separate ML call for every document in the result set. For a compliance officer reviewing 50 contracts, this sequential processing introduces noticeable latency.

OpenSearch 3.3 introduced batch inference mode to address this. Batch inference collects the matching documents and processes them in a single ML inference call. In the contract compliance use case, this shifts the performance characteristic from multiple sequential roundtrips to a single parallel execution on the Amazon SageMaker AI GPU.

To enable batch inference, first configure the cluster setting:

PUT _cluster/settings
{
  "persistent": {
    "search.pipeline.enabled_system_generated_factories": ["semantic-highlighter"]
  }
}

Then add batch_inference: true to your highlight options. The following query searches for data privacy clauses across the contracts and highlights the top 10 results using a single batch call:

POST /legal-contracts-index/_search
{
  "query": {
    "neural": {
      "clause_embedding": {
        "query_text": "standard for inadvertent access notification",
        "model_id": "<TEXT_EMBEDDING_MODEL_ID>",
        "k": 10
      }
    }
  },
  "highlight": {
    "fields": {
      "clause_text": { "type": "semantic" }
    },
    "options": {
      "model_id": "<REMOTE_HIGHLIGHTER_MODEL_ID>",
      "batch_inference": true,
      "max_inference_batch_size": 50
    }
  }
}

Best practices

Follow these recommendations to optimize performance, security, and cost-efficiency when deploying the contract compliance search system in production.

Experiment with overlapping chunk sizes (for example, 500 characters with a 10 percent overlap) in your OSI pipeline to verify that context is preserved for long indemnification or liability clauses.
Verify that your Amazon S3 buckets and OpenSearch domains are encrypted using AWS Key Management Service (AWS KMS). For production workloads containing sensitive data, make sure that all traffic stays within your virtual private cloud (VPC) through interface endpoints.

This demo uses simplified configurations for learning purposes. For production deployments, implement VPC isolation, AWS KMS encryption with customer-managed keys, and multi-AZ OpenSearch clusters.

Clean up resources

To avoid ongoing charges, delete the AWS CloudFormation stacks and associated resources:

On the AWS CloudFormation console, choose Stacks in the navigation pane.
Select the os-demo-highlighting stack (Stack 2) and choose Delete. Wait for deletion to complete.
Select the os-demo-search stack (Stack 1) and choose Delete. Stack deletion takes approximately 10–15 minutes to complete.

The stack deletion will automatically remove:

OpenSearch domain.
SageMaker model and endpoint.
Lambda functions.
IAM roles and policies.

After both stacks are deleted, manually delete the S3 bucket (opensearch-cfn-semantic-highlighting-us-east-1-<ACCOUNT_ID>) created for model artifacts. This bucket is provisioned at deploy time and is not managed by CloudFormation. Replace <ACCOUNT_ID> with your AWS account ID in the bucket name.

Conclusion

In this post, you built a contract compliance search system that combines semantic search with semantic highlighting in Amazon OpenSearch Service. The system helps close the discovery gap by retrieving contracts based on meaning rather than exact keywords, and it reduces review latency by highlighting the specific clauses that answer your query.

While we focused on legal agreements, the architecture described here is a blueprint for domains requiring high-stakes document discovery, including:

Regulatory filings: Identifying specific compliance mandates in financial reports.
Technical documentation: Pinpointing troubleshooting steps across massive product manuals.
Research and academia: Isolating specific methodologies within thousands of scientific papers.
Internal knowledge bases: Empowering employees to find exact policy language instantly.

To get started, deploy the solution from the sample repository on GitHub and try semantic search in the Amazon OpenSearch Service console. For more information about semantic search, see Semantic search in the Amazon OpenSearch Service Developer Guide.

About the authors

S9 E17: Inflation & Beach Dolls Update: Last Week Tonight with John Oliver

2026-07-28 LastWeekTonight

Post Syndicated from LastWeekTonight original https://www.youtube.com/watch?v=D10nBR4m9rg

Trump & Crypto #lastweektonight

2026-07-28 LastWeekTonight

Post Syndicated from LastWeekTonight original https://www.youtube.com/shorts/280a8zmi_ms

Wayfire 0.11 released

2026-07-28 jzb

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

Version
0.11 of the wlroots-based
Wayfire Wayland compositor has been
released. Notable changes include better fractional scaling,
per-output ICC
profiles, support for additional Wayland protocols, and more.

[$] A report from Debian’s new DFSG team

2026-07-28 jzb

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

The DFSG, Licensing
& New Packages Team (usually shortened to “DFSG team”) was
created in October 2025 as part of the ftpmaster team split. Its
job is to review packages in the new queue for compliance
with the Debian
Free Software Guidelines (DFSG), among other things, before the
packages are allowed to enter the Debian
archive. The change was long in coming, and some questions
remained after the split whether it was the right move. Andrew
McMillan provided an overview of the team’s activities and its current
status during DebConf26. While it may be
too early to say with certainty, his report suggests that the new
division of duties is working out well.

Галин Попов: Ресурсът на града е едно, потенциалът – нещо различно

2026-07-28 Ина Иванова

Post Syndicated from Ина Иванова original https://www.toest.bg/galin-popov-resursut-na-grada-e-edno-potentsialut-neshto-razlichno/

Галин Попов: Ресурсът на града е едно, потенциалът – нещо различно

През 2012 г. Галин Попов и група съмишленици създават независимото културно пространство ТаМ, което започва да работи като бар със събития, но постепенно се трансформира в лаборатория за общностни инициативи и предлага театър, музикални и киносъбития, литература, архитектура и наука. Във Велико Търново. Днес мястото е емблематично именно с културните и социалните си инициативи, неконвенционалния си подход и цветната публика. Когато Галин Попов измисля концепцията ТаМ, още не осъзнава, че му предстои да създава културни политики локално и по нова формула. Оттогава и досега екипът на сдружението (петима човека) разчита на не повече от 10–15% публично финансиране. Останалата част от дейността им се самофинансира.

Не съм сигурен дали е по-трудно да работиш с държавни институции с неясни инструменти за подкрепа, или да се справяш финансово заедно с други ентусиазирани хора, с които да постигате нещата.

Когато става дума за социална среда, парите не са водещи. Хората са важният ресурс – тези, които имат експертност, артистични таланти, тези, които имат ентусиазма да дойдат във Велико Търново и да споделяме търсенията си. Ако някой ви затвори с 1 милион евро в една стая, социалната ви среда няма да е много лека. Обаче ако в тази стая има хора, с които имате общи теми, всичко ще потръгне.

Според Галин Попов най-важно при всяка инициатива е да бъде изградено ниво на доверие, без значение дали става въпрос за изкуство, бизнес, или образование. Само така отпадат опасенията, че някой може да бъде подценен, използван или иронизиран.

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

През 2020 г., малко след локдауна и посред ковид кризата, които сега ни се струват доста отдалечени във времето, стартира фестивалът „48 часа Варуша юг“. Кръстен на името на квартал в Стария град на Велико Търново, фестивалът е мащабно културно събитие, което събира годишно около 15 000 души. Започва благодарение на инициативата „Отворен град“ – европейска концепция, вдъхновена от идеята за овластяване на локалните общности, която се фокусира върху местните жители като най-важните участници в промяната на кварталите. Фестивалът във Велико Търново е вдъхновен от артистичния фестивал 48 Stunden Neukölln, провеждан в един от най-колоритните квартали на Берлин – Neukölln. Немският фестивал също използва изкуството като инструмент за свързване между различни общности.

Дали „Варуша юг“ има манифест във време, в което всички предпочитаме да не правим големи жестове? Да, всяка година. Дали освен програмиране предлага и отворена покана за артисти, които желаят да се включат и допринесат? Да. Дали през изминалата година централната градска артерия на Велико Търново беше затворена и превърната в пешеходна зона, а дошлите от цял свят посетители имаха възможност да избират между 160 отделни събития? Да.

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

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

Галин е роден във Велико Търново, учил е в града, бунтувал се е в него. Казва, че е бягал от училище и е идвал да се разхожда в красивия квартал „Варуша“. Тогава е мислил, че ако ще остава да живее в Търново, трябва да си купи къща именно в старата част. По онова време не се е чувствал емоционално свързан с културните процеси, доколкото те са му се стрували доста затворени и капсулирани. В непокорния си период след завършване на училище се отдава на търсене, пътува почти всеки уикенд, за да посещава музикални или театрални събития. През лятото има шанса да си позволи по-дълги бягства – месеци в Берлин, Пловдив, Карадере, на стоп из Родопите.

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

Докато не настъпи моментът, в който да си кажа: ако аз си изкарвам парите в България и ходя да ги харча в Западна Европа, за западноевропейците ще е двойно по-изгодно да дойдат за интересно събитие тук. Ресурсът на града е едно, потенциалът един град да бъде разпознат на международно ниво е нещо друго.

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

Режисьорът Младен Алексиев беше човекът, който пръв ми каза, че трябва да се занимавам с културен мениджмънт. Фокусът ми винаги е бил тук и много неща в българския контекст, които през годините са ми се стрували като негативи, вече разбирам, че са позитиви.

Преди години при нас беше френски диджей, наполовина българин. След събитието беше решил да пътува, за да види баба си в Стара Загора. Започнах да се извинявам, че с влака ще отнеме минимум 3–4 часа. Неговата гледна точка обаче беше: няма лошо, виж сега, от жп гарата си купувам билет само за около 5 евро. Разбира се, влакът закъсня и аз се чувствах много неудобно. Неговата гледна точка обаче беше: седим си тук до релсите, говорим си, толкова е спокойно. С времето аз започнах да чувствам, че живея не на лошо, а на екзотично място. Тази екзотика вече не ме ядосва, не се срамувам и имам желание да я споделям с все повече хора откъде ли не.

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

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

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

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

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

Силният интерес и посещаемост прави екипа на сдружението разпознаваем и за общинските власти. Институциите не могат да бъдат променени с война и конфронтация, смята Галин. Единственият път е да впрегнем всичката си енергия и любов, за да изградим алтернативи, които са събирателни за големи групи хора.

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

Самият релеф на града според него спомага за изграждането на микрообщности. Велико Търново не разполага с големи зали или площади, но пък в по-малките локации хората по естествен път си стават по-близки. Архитектурата и начинът, по който един град е планиран, предлагат различни условия за жителите си. С това всъщност се съобразяват и културните оператори като Галин Попов – с възможността да създават, вярвайки в свободния дух. И убедено вървейки срещу инерцията на познатото.

Хората, които тихо и кротко променят средата, формират общности и задават посоки, в които има смисъл да тръгнем заедно. Тук ви срещаме с тях. Това са „Тези хора“.

Security updates for Tuesday

2026-07-28 jzb

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

Security updates have been issued by AlmaLinux (grafana and libreswan), Debian (openjdk-11 and openjdk-17), Fedora (opkssh, perl-Mojolicious, and rpm), Mageia (libyang, memcached, nginx, packages, and sqlite3), Oracle (.NET 8.0, acl, buildah, compat-openssl11, compat-poppler022, dogtag-pki, git-lfs, glibc, go-fdo-client, golang, httpd:2.4, jackson-annotations, jackson-core, jackson-databind, jackson-jaxrs-providers, and jackson-modules-base, kernel, libpq, LibRaw, maven:3.8, mysql8.4, nodejs:22, nodejs:24, openssl, podman, poppler, python3.14, samba, sssd, tomcat, tomcat9, vim, and yggdrasil), Red Hat (gstreamer1-plugins-bad-free), SUSE (afterburn, alsa, apache-ivy, avahi, aws-nitro-enclaves-cli, chromium, cifs-utils, cockpit, cockpit-machines, cockpit-packages, cockpit- podman, cockpit-repos, cockpit-subscriptions, containerd, curl, docker-compose, freetype2, gawk, glib2, google-cloud-sap-agent, gpg2, gstreamer-plugins-bad, gzip, helm, ignition, ImageMagick, jackson-annotations, jackson-bom, jackson-core, jackson- databind, jackson-dataformats-binary, jackson-modules-base, jackson-annotations, jackson-core, jackson-databind, java-11-openjdk, jline3, joe, jq, kernel, libgcrypt, libknet-devel, libsoup, libxml2, mariadb-connector-c, mcphost, net-tools, nghttp2, opennlp, openssl-1_0_0, PackageKit, pam, patch, pcr-oracle, perl, perl-DBI, perl-HTTP-Date, python-aiohttp, python-cryptography, python-Pillow, python-pyasn1, python-soupsieve, python-tornado, python-tornado6, python-urllib3, python3, radvd, rust-keylime, s390-tools, shibboleth-sp, sssd, systemd, tiff, vim, and wpa_supplicant), and Ubuntu (FreeIPMI, glibc, linux-aws, linux-aws, linux-raspi, linux-aws-6.8, linux-aws-fips, linux-azure, linux-azure-6.8, linux-azure, linux-oracle, linux-azure-5.15, linux-azure-fde-5.15, linux-oracle-5.15, linux-azure-6.17, linux-azure-fde, linux-azure-fde-6.17, linux-azure-fde-6.8, linux-azure-fips, linux-hwe-6.8, linux-ibm, linux-ibm-6.8, linux-nvidia-tegra, linux-xilinx, linux-oracle-6.17, roc-toolkit, and samba).

Natural disasters and government interference: examining Q2 2026’s major Internet disruption event

2026-07-28 Lai Yi Ohlsen

Post Syndicated from Lai Yi Ohlsen original https://blog.cloudflare.com/q2-2026-internet-disruption-summary/

Like most infrastructure, the Internet's fragility is easy to overlook — as long as it's working. When it fails, its complexity comes into full view. Cloudflare is in a unique position to detect and document the moments when one of the interrelated systems the Internet depends on breaks down and connectivity suffers as a result. Each quarter, we summarize the disruptions we detect and annotate on Cloudflare Radar.

In Q2 2026, Super Typhoon Sinlaku just north of Guam caused the longest outage, while government-mandated shutdowns during exam periods in Sudan were the most frequent. Iran restored national Internet access, reconnecting its citizens to the global network after an 88-day blackout, even as damage from drone strikes continued to disrupt AWS infrastructure elsewhere in the region. Finally, a cable cut in Saint Lucia and the distribution of faulty DNSSEC signatures in Germany underscored the fragility of Internet infrastructure, but also the remarkable stability these regional and global systems maintain when operating normally.

Here we will walk through the most significant Internet disruptions we observed in the second quarter of 2026, drawing on traffic data from Cloudflare Radar to show how each unfolded and what it meant for users on the ground. As always, this is a summary of notable, confirmed disruptions rather than an exhaustive list; a fuller view of detected traffic anomalies is available in the Cloudflare Radar Outage Center.

Natural disasters and electricity cause disruptions in Guam, Venezuela, and Tanzania

Super Typhoon Sinlaku, the strongest storm of the 2026 Pacific typhoon season so far, tracked through the Mariana Islands in mid-April, passing just north of Guam. Though the island was spared a direct hit, the storm brought tropical-storm-force winds, knocking out power across Guam and disrupting water systems, which had a direct impact on Internet connectivity. Traffic from the territory fell as much as 80% below expected levels from April 13 to 14.

Two months later, on June 24, two major earthquakes struck northern Venezuela within about a minute of each other, in Yumare and San Felipe, followed by an aftershock near the coast outside of Caracas. The first 7.5 magnitude earthquake took place at roughly 22:04 UTC (18:04 local time). The immediate impact of these events can be seen in Radar, which shows a sharp decrease in both HTTP bytes transferred at the same time as the earthquakes. This decrease can be seen particularly well in Fibex Telecom, which, according to APNIC data, has 1.6 million estimated users. The drop is also visible for CANTV, the state-owned incumbent, and VNET, a slightly smaller regional ISP.

Across the Atlantic just a few days later, a power outage in Tanzania on June 27 caused a sharp drop in HTTP traffic there that lasted for at least five hours. While distinct in cause from the country's election-related blackout in October 2025 (a deliberate government action rather than an infrastructure failure) the resulting telemetry and user impact were nearly identical: a drastic loss of connectivity that left residents unable to communicate with loved ones or access critical news.

It is striking how such fundamentally different events leave such similar footprints in the data and user experience. Taken together, these weather-related and power-driven disruptions demonstrate the immense impact the physical world can have on the digital, and the importance of Internet resilience and of building networks with enough redundancy in power, routing, and physical paths to withstand inevitable shocks.

Governments and geopolitics impact connectivity in Iran, UAE, Iraq and Sudan

Starting on May 26, Radar began seeing signs of Iran's previously announced Internet restoration, the tentative end of an 88-day shutdown that had left the country almost entirely offline since it began on February 28. On May 27, Radar reported that traffic had been restored to 40% of its pre-outage levels, a partial reopening consistent with reports that access was being reintroduced selectively rather than all at once. Since then, we have seen HTTP bytes climb to as high as 90% before settling back to roughly 59% of pre-shutdown levels. This volume is consistent with the traffic we observed in February, a window between this recent shutdown and a previous one in January, suggesting that connectivity has returned to something like its most recent pre-shutdown baseline rather than fully normalizing. In our 2026 World Cup analysis, Iran stood out as a solo outlier: While traffic in most participating countries rose and fell with match schedules, Iran's readings were dominated instead by the contrast between its post-restoration levels and the near-complete loss of connectivity that had preceded them.

Meanwhile, HTTP traffic to me-central-1, an AWS cloud region located in the United Arab Emirates, has remained low, aligning with AWS service reports on April 30 that the region "has suffered damage as a result of the conflict in the Middle East and is currently unable to reliably support customer applications." This update follows the reports on March 3 that facilities in both UAE and Bahrain “have experienced physical impacts to infrastructure as a result of drone strikes.” In the UAE, two facilities were “directly struck” and in Bahrain a drone strike near the facility caused “physical impact” to their infrastructure. The decreased traffic is the downstream signature of physical damage to the underlying data center infrastructure rather than a network fault, and it continues to affect the websites and applications hosted in that region, regardless of their own availability.

The second quarter of 2026 also included three government-mandated shutdowns in Iraq (on June 2, June 11, and June 28) as well as 10 in Sudan between April 13 and 23, all of which were imposed to prevent cheating on national exams — a seasonal pattern we have documented across multiple prior quarters in both countries. The outages in Sudan followed a consistent rhythm, each lasting approximately 3.5 hours from 11:45 to 15:15 UTC (13:45 to 17:15 local time), timed to the exam window. In Iraq the outages were shorter, lasting about 90 minutes each, and likewise scheduled around the hours in which exams were administered.

Each of these examples, whether a restoration or a disruption, illustrates the significant control governments exert over their national connectivity, and the ease with which access can be switched off, throttled, or selectively reintroduced as a matter of policy rather than infrastructure.

Infrastructure vulnerabilities affect users in Germany and Saint Lucia

On May 5, a DNSSEC key rollover at DENIC, the registry for Germany's .de domain, started producing invalid signatures. These key rollovers are the periodic replacement of the cryptographic keys used to sign a zone's DNS records; they are a routine but crucial piece of maintenance, as resolvers that validate DNSSEC will only trust answers whose signatures match the current published keys. In other words, if the digital signatures don't match expected values, the resolver assumes the site has been tampered with and cuts off access. When invalid signatures started being produced, validating resolvers worldwide rejected every request for a .de website and returned SERVFAIL errors until normal operation was restored at 23:15 UTC (01:15 local time on May 6).

Cloudflare Radar observed worldwide .de query volume rise during the outage. While perhaps initially counterintuitive, this is because failed answers are effectively uncacheable, so lookups normally served silently from cache instead had to be re-resolved and retried repeatedly, causing a sharp increase in queries.

From a user's perspective, the incident was experienced not as a DNS or cryptographic failure but simply as a wave of .de websites and services suddenly becoming unreachable. Though users were still able to access sites that did not use the .de TLD, the experience included pages failing to load, email bouncing, and apps timing out, all of which can mirror the experience of an outage. You can read more about DNSSEC and the impact of the events on our blog.

In the Caribbean, an infrastructure failure caused a similar drop in availability. On June 21, HTTP request traffic from Karib Cable’s network fell to essentially zero by around 21:00 UTC (17:00 local time), and remained flat for the better part of a day before recovering to expected levels around 17:00 UTC on June 22 (13:00 local time). The outage was reportedly caused by a fiber cut near the island, a familiar hazard for Caribbean networks that depend on a small number of terrestrial and submarine paths to reach the wider Internet, meaning a single break can sever a disproportionate amount of capacity. Because Karib Cable is one of the largest providers, the loss was also visible at the country level, with Saint Lucia's overall traffic dropping approximately 60% against the prior week for the duration of the cut.

Radar continues to monitor disruptions

The second quarter of 2026 saw Internet disruptions arise from a wide range of causes, including severe weather, an earthquake, power outages, government-directed shutdowns, damage to cloud infrastructure, cable cuts, and a DNSSEC misconfiguration. As these events demonstrate, the Internet depends on a complex set of interrelated systems, and a failure in any one of them can result in a loss of connectivity.

The Cloudflare Radar team is constantly monitoring for Internet disruptions, sharing our observations on the Cloudflare Radar Outage Center, via social media, and in posts on blog.cloudflare.com. Follow us on social media at @CloudflareRadar (X), noc.social/@cloudflareradar (Mastodon), and radar.cloudflare.com (Bluesky).

Rapid7 Cyber GRC is now available: Turn security action into compliance proof

2026-07-28 Michael Chroney

Post Syndicated from Michael Chroney original https://www.rapid7.com/blog/post/pt-cyber-grc-available-prove-compliance-security

Compliance has become one of the biggest operational drains on modern security teams. CISOs are being asked to manage a growing sprawl of frameworks, prove control effectiveness more often, respond to more customer assurance requests, track risk across a growing web of third parties, and give executives and the board a clearer answer on whether cyber risk is actually going down.

Most of that pressure does not come from the frameworks themselves. It comes from the way compliance is still handled in many organizations, with security work happening in one set of tools and governance, risk, and compliance workflows managed somewhere else. Security teams detect exposures, investigate threats, validate risk, and drive remediation in active systems. Governance, Risk and Compliance (GRC) teams are often left managing controls, evidence, audits, third-party risk, and reporting in separate systems of record, which turns compliance into a constant reconciliation exercise rather than an extension of the security program.

That separation creates real drag. Skilled technical teams get pulled into repeated cycles of screenshots, exports, control validation, and spreadsheet updates, while CISOs are still left trying to answer the question that matters most: are our controls actually working right now?

Available today, Rapid7 Cyber GRC completely changes that model by connecting governance, risk, and compliance workflows to the security data and activity already happening across the environment. The result is a more connected way to reduce manual work, improve readiness, and turn security action into compliance proof.

Why compliance needs to move at the speed of security

For years, compliance work followed a familiar rhythm: prepare for the audit, gather evidence, prove the control, respond to findings, and start over when the next framework, customer review, or regulatory requirement arrives.

That rhythm works in conflict with how security teams operate today. Modern environments change continuously. Assets appear, cloud configurations drift, access permissions change, vulnerabilities emerge, vendors introduce risk, and remediation work is always in motion.

This leaves a widening gap between the state of the environment and the state of the evidence. A control that looked effective during the last audit may drift weeks later. A remediation effort may reduce risk, but the compliance record may not reflect it. A new exposure may change the risk tied to a control before the next review begins.

Boards and customers are asking for something more credible than periodic audit readiness. They want to understand whether security work is actually improving control health and reducing risk over time.

That is the shift from audit prep to continuous cyber assurance, built on better context and closer alignment between teams. As Bill Theissen, Managing Partner and VP of Consulting Services at Cyber Watch Systems, put it, “What excites me most about Rapid7 Cyber GRC is its ability to use existing security data, asset inventories, and API connectivity to produce more accurate, timely, and defensible risk reporting. Just as important, it helps bridge security engineering and GRC teams through a shared view of risk and a common language for communicating it.”

Cyber GRC is designed to support that shift by making governance, risk, and compliance part of how security teams prioritize, act, and prove progress. Compliance should not only document security activity after the fact – it should help show how that activity makes the business safer.

How Cyber GRC connects action to proof

Rapid7 Cyber GRC brings core GRC workflows into one place, including compliance program management, control monitoring, evidence collection, policy management, audit preparation, risk management, third-party risk management, exceptions, and reporting. Instead of managing those workflows in separate tools, teams can connect them to security context from the environment they are actively protecting.

Cyber GRC helps teams operationalize that model in a few practical ways:

Control monitoring helps teams see where requirements are being met and where gaps need attention.
Evidence workflows help teams collect, organize, and reuse proof across frameworks instead of rebuilding it for every audit.
Policy management helps link policies to controls, so teams can understand how documentation supports readiness.
Risk and issue workflows help teams assign ownership, track remediation, and prioritize work based on business and security context.

The value of that model is not just administrative efficiency. Security teams need confidence that controls are operating as intended, not simply that a control exists on paper. A policy may be in place without the control performing effectively. A remediation ticket may be closed without the underlying risk truly being reduced. Control testing and monitoring help close that gap by showing whether controls are functioning as expected, while issue and remediation workflows connect those findings to owners and next steps.

By connecting controls, evidence, risk, issues, policies, and remediation activity, Cyber GRC gives SecOps, IT, GRC, and compliance teams a shared view of where they stand and what needs to happen next.

Why third-party risk needs to be part of the same workflow

Third-party risk has become too significant to sit outside the rest of the security and compliance program. As organizations rely on more outside services, software, and vendors, they need a way to connect vendor risk to the same controls, evidence, remediation, and reporting workflows used internally. Verizon’s 2026 DBIR found that breaches involving third parties increased 60% from the previous year’s dataset and accounted for 48% of total breaches, which makes that connection harder to treat as optional.

Cyber GRC brings third-party risk management into the same operating picture by combining vendor oversight, control tracking, issue management, and evidence workflows in one place. That gives teams a more coherent way to assess external dependencies, understand where vendor risk affects control posture, and track action without creating yet another disconnected program.

Give leadership a better risk story

CISOs are under pressure to show progress in a way executives and boards can understand, and audit status alone does not tell the whole story.

Cyber GRC helps teams connect day-to-day security and compliance activity to higher-level reporting, including control health, readiness status, open risks, remediation progress, third-party dependencies, and evidence coverage. That gives leaders a clearer view of which gaps matter most, what is being done about them, and how security work is reducing risk.
What makes that more useful is the quality of the underlying context. When controls, evidence, vulnerabilities, risk, and remediation are tied together, leadership gets a stronger basis for understanding not just whether the organization is compliant, but whether its controls are keeping pace with the way risk is actually developing.

Why Rapid7

Security leaders have an opportunity to make compliance more connected, more useful, and closely aligned to the work already happening across their security program.

Rapid7 approaches Cyber GRC as part of a broader security program. What makes that more useful is the quality of the underlying context. When controls, evidence, vulnerabilities, risk, and remediation are tied together, leadership gets a stronger basis for understanding not just whether the organization is compliant, but whether its controls are keeping pace with the way risk is actually developing.

That connection is at the core of what makes this solution different. Compliance proof is stronger when it is grounded in security context, not assembled after the fact from disconnected tools and static reports. With Rapid7 Cyber GRC, teams can move from documenting compliance activity to showing how security work is improving control health and reducing risk in real time.

See how Rapid7 Cyber GRC can help your team turn security operations into continuous cyber assurance.

The Next Evolution of MDR: Preemptive Defense and Agentic Investigation

2026-07-28 Mikayla Wyman

Post Syndicated from Mikayla Wyman original https://www.rapid7.com/blog/post/dr-the-next-evolution-mdr-preemptive-defense-agentic-investigation

For years, security operations followed a familiar sequence: detect suspicious activity, investigate what happened, and respond before it caused significant harm. That model developed in a threat landscape where defenders had considerably more time to establish the facts and decide what to do next. In 2019, the average data breach took 206 days to identify and another 73 days to contain, creating a total breach lifecycle of 279 days.

As the time between initial access and attacker movement continues to contract, security teams are being asked to operate within a much narrower window. AI is accelerating reconnaissance, vulnerability discovery, and campaign execution, while defenders are responsible for growing volumes of data across cloud, identity, endpoint, SaaS, and AI environments, often without equivalent growth in analyst capacity.

Managed detection and response is evolving to meet those conditions by connecting exposure intelligence, machine-speed investigation, and human expertise. This approach helps security teams identify credible risks sooner, understand their potential impact, and intervene earlier in the attack lifecycle.

MDR must move beyond alert-driven investigations

When suspicious activity generates an alert, traditional MDR typically moves into investigation mode. Analysts gather information about the affected asset or identity, correlate activity across security tools, establish the scope of the incident, and determine the appropriate response.

Although each step is necessary, much of the initial work involves finding and organizing information rather than applying expert judgment. Analysts can spend valuable time collecting asset details, checking vulnerabilities, validating signals, and reconstructing context before the investigation can progress.

Recent research conducted with Omdia found that 93% of security leaders agree AI improves analyst efficiency by automating repetitive tasks. Giving machines responsibility for routine evidence gathering and correlation allows analysts to focus their time on complex investigations, business impact, and response decisions.

Preemptive MDR connects exposure and detection

Exposure management and security operations often provide different views of the same environment. Exposure teams understand which vulnerabilities, assets, identities, and attack paths present risk, while detection and response teams see activity as it unfolds. Connecting these views gives analysts more context at the beginning of an investigation.

Preemptive MDR brings asset criticality, internet exposure, vulnerability data, and threat intelligence directly into the SOC workflow. When an alert appears, analysts can immediately see why the affected asset matters, which weaknesses may be involved, and whether the activity aligns with known attacker behavior.

The same context can also support action before an alert fires. Intelligence indicating stolen credentials or compromised sessions can be surfaced before an attacker uses them, while newly disclosed vulnerabilities can be assessed against the organization’s assets and business priorities. MDR teams can then guide remediation towards the exposures most likely to create a viable route into the environment.

By moving exposure intelligence closer to detection and response, investigations begin with a clearer understanding of what is happening and where action will have the greatest effect.

Agentic SOC capabilities accelerate investigation

By bringing security data together across the environment, connected context creates the foundation for agentic SOC capabilities. Security investigations require evidence gathering, correlation, validation, and scoping, with many of these tasks repeated across every alert.

AI agents can perform elements of that work in parallel by examining telemetry, connecting related activity, testing possible explanations, and presenting analysts with a structured account of what happened, what is at risk, and which actions are available. Analysts can then review the evidence and apply their understanding of the organization, its priorities, and the potential consequences of a response.

While AI can accelerate much of the investigation process, human oversight remains essential to the way this model operates. The same Omdia research found that 92% of security leaders believe analysts should retain responsibility for final decisions, while 90% view human oversight as essential to the accuracy and reliability of AI-driven processes.² Agentic SOC capabilities can support that balance by accelerating repeatable investigation work while keeping analysts responsible for decisions that require judgment and accountability.

Connected security data strengthens AI-driven MDR

Because security AI can only work with the data and context available to it, the quality of that foundation has a direct impact on the investigation. An investigation is more useful when the system can connect an alert to the affected user, asset, vulnerability, cloud resource, and wider attack path without requiring an analyst to search across several tools.

Rapid7’s data mesh brings together asset, cloud, configuration, exposure, event, and alert data in a normalized layer. This gives AI-driven investigations access to connected security context at the point of analysis and helps reduce the manual work involved in reconstructing it.

From faster response to continuous defense

Bringing exposure intelligence, connected security data, AI-driven investigation, and human expertise into the same operating model creates a continuous defense loop. Exposure context helps teams identify where attackers are most likely to find an opening, detection reveals how those risks are being used in practice, and response reduces the opportunities available to the next attacker.

This approach allows MDR to contribute beyond the investigation of individual alerts. Each incident can improve future detection and prioritization, while exposure insights can guide action before suspicious activity develops into a larger event. Analysts gain the context to make better decisions, and automation gives them more time to focus on the threats and business risks that require their expertise.

The next evolution of MDR will be defined by how effectively providers connect these capabilities. By combining preemptive insight with machine-speed investigation and accountable human decision-making, security teams can act earlier, investigate faster, and continuously strengthen their defenses as the threat environment changes.

Rapid7 will showcase upcoming investments in Preemptive MDR and Agentic SOC at Black Hat USA in Las Vegas, August 3–6, 2026.

THG Podcast: Counterfactuals – The Princeton Explosion

2026-07-28 The History Guy: History Deserves to Be Remembered

Post Syndicated from The History Guy: History Deserves to Be Remembered original https://www.youtube.com/watch?v=ZVJ_sz7JIEI

Axon Is Another License Plate Surveillance Company

2026-07-28 Bruce Schneier

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2026/07/axon-is-another-license-plate-surveillance-company.html

Governments are switching, but I’m not sure it makes a difference:

…some municipalities, including Denver, Colorado, are ditching their Flock arrays. But keep in mind that if they’re only switching from Flock to another brand of license-plate readers, like Axon, it’s like a gambling addict trying to kick the habit by switching from FanDuel to DraftKings.

[…]

Despite what you may read on the Flock website, Axon cameras are pretty effective when it comes to hoovering up personal details that can go far beyond your license plate numbers. That means a municipality that opts for Axon cameras instead of Flock units won’t necessarily reduce the amount privacy its citizens lose through their use.

Bringing the global Bebras community together in Cambridge

2026-07-28 Andrew Csizmadia

Post Syndicated from Andrew Csizmadia original https://www.raspberrypi.org/blog/bringing-the-global-bebras-community-together-in-cambridge/

On 10–15 May, we welcomed the global Bebras community to Cambridge, UK for the 22nd Bebras International Task Workshop.

As organisers of the UK Bebras Challenge, we hosted this year’s annual Task Workshop, bringing together Bebras organisers, educators, and researchers from around the world to review and refine the computational thinking tasks in preparation for countries’ 2026 Bebras Challenges. The Bebras tasks young people see every November may look simple and playful, but each one has been carefully discussed, tested, debated, and improved by people who care deeply about helping young people develop problem-solving skills.

4 days, 101 delegates, 277 tasks

This May, we convened 101 delegates from 61 countries at the Møller Institute in Cambridge for the Bebras International Task Workshop, with more participants joining parts of the Task Workshop online to take part in the discussions, decisions, and community moments that make this annual gathering so special.

277 tasks had been submitted by the Bebras community, including 4 by us. Over 4 intensive days, delegates worked in 8 working groups, considering everything about these proposed tasks: from clarity of wording and illustrations, to age suitability and accessibility, to the computational thinking involved. By the end of the workshop, 214 tasks including our 4 had been accepted.

Alex Parry from our team reflects:

“The effort that everyone put in was remarkable — the delegates who travelled from around the world, the sometimes slightly heated discussions about computational thinking and its wider implications, and the improvements to the tasks within the working groups.”

Promoting computational thinking around the world

These lively discussions are part of what makes the Bebras Challenge impactful. A Bebras task is more than simply a computational thinking puzzle and its answer. It invites curiosity, supports careful reasoning, and gives learners a fair opportunity to show how they think. Bringing together the perspectives of people from different countries and education systems makes the tasks richer, clearer, and more useful for teachers and learners everywhere.

The Bebras Challenge currently runs in schools in 78 countries. In 2025, more than 4 million students aged 6 to 19 took part, with an incredible 526,000 participants in the UK alone.

The Bebras tasks encourage logical reasoning, pattern recognition, abstraction, decomposition, and algorithmic thinking, often through engaging stories and visual puzzles.

Learning from a global community

Although the formal purpose of the Workshop is to review tasks, the event is also a valuable opportunity for the Bebras community to learn from one another. On the Wednesday evening, delegates took part in the Bebras marketplace, sharing posters, resources, ideas, and questions in a wonderful showcase of how creative and adaptable the community is.

We heard how Bebras is being delivered in countries where schools may have limited internet connectivity or access to computing hardware, including Ghana, Jamaica, Mexico, and Sri Lanka. We saw that many countries offer paper-based versions of the challenge to overcome technical barriers. We learned about Mexico’s work towards making the challenge accessible on smartphones.

There were also inspiring examples of countries extending computational thinking beyond the annual Challenge fortnight. Armenia has developed Bebras books, Brazil has a Bebras magazine, Indonesia is creating teacher training resources for all subjects, and Lithuania is using hands-on games to help learners explore computing concepts.

These examples are a powerful reminder that computational thinking does not require computers or programming skills: it can be explored through stories, games, puzzles, printed resources, teamwork, and discussion.

Thanks to Bebras, this is something we are bringing into other initiatives. Laura Kirsop, our Chief Technology and Product Officer, highlighted in the Workshop’s opening keynote how Bebras has influenced some of the Foundation’s educational products. For example, the unplugged Code Club resource Escape room: The jungle awakens uses previous years’ Bebras tasks in a new context to support clubs with access limitations.

Growing the Bebras community

Alongside the work of reviewing tasks, the Workshop also supports the continued growth of Bebras around the world. This year, 10 new provisional members — Bolivia, Cameroon, Ecuador, Ghana, Hong Kong and Macao, Luxembourg, Mongolia, Palestine, Sri Lanka, and Tanzania — were inducted, and 7 new full members were voted in: Armenia, Colombia, Greece, Jamaica, Mexico, Paraguay, and Puerto Rico.

Each new member country means more young people will have the opportunity to experience computational thinking in an accessible and engaging way, and more educators will be able to join the international conversation about how best to support learners.

Creating the conditions for collaboration

Hosting an international event such as this involves much more than providing meeting rooms and a timetable. The Workshop needed to support focused work, lively discussion, social connection, and participation from delegates joining remotely via livestreams.

We were pleased that our efforts were successful and recognised by delegates. One person described the event as “a truly positive experience on all fronts”, while another commented: “The planning and execution was flawless.” And for an event built around international collaboration, one piece of feedback was especially welcome: “The WiFi connection was phenomenal!”

You can’t get everything right though, as one delegate joked when we asked what could be improved about this year’s workshop: “Sorry, the weather could have been better :-)” We will take that as a challenge for our next time as hosts!

The 23rd Bebras International Task Workshop will be held in Uruguay in May 2027. We wish the Uruguay team every success as they begin planning the next gathering of this inspiring international community.

What’s next for UK Bebras?

We are now preparing the tasks for the next UK Bebras Challenge, working in collaboration with the Bebras teams from Australia, Ireland, Canada, and the USA.

Across the world, the Bebras Challenge takes place every November and is completed and automatically marked online. For students, it’s a range of fun and engaging computational thinking tasks, to be answered within 45 minutes. For educators, Bebras is a powerful way to introduce and practice computational thinking with their learners.

If you’re an educator in the UK, you can try out past Bebras tasks to get a taste, and register now to be ready to set up your classes from September. This year, the UK Bebras Challenge will take place between 8 and 20 November.

Learn more about the UK Bebras Challenge

The post Bringing the global Bebras community together in Cambridge appeared first on Raspberry Pi Foundation.

Rapid7 and Exclusive Networks expand partnership to modernize security operations and accelerate customer success

2026-07-28 Claudia Zoon

Post Syndicated from Claudia Zoon original https://www.rapid7.com/blog/post/c-exclusive-networks-partnership-accelerating-customer-success

Claudia Zoon is Senior Manager, Channel Sales at Rapid7.

Across Belgium, the Netherlands, and Luxembourg, organizations are accelerating digital transformation through AI, cloud adoption, and increasingly connected business operations. These investments are creating new opportunities for innovation, but also reshaping the cybersecurity landscape.

In this dynamic environment, Rapid7 is excited to announce an expanded strategic distribution partnership with Exclusive Networks across the Benelux region. Why now? Because as organizations grow, so too do the expectations of security teams. As attack surfaces expand, more sophisticated AI-enabled threats emerge; as compliance requirements evolve, leaders expect security to scale right along with the business – all without adding unnecessary complexity.

In this chaotic environment, cybersecurity customers are demanding experiences that create more calm. This means no more disconnected security tools or reactive approaches, but integrated security operations, trusted expertise, and partners who can help them improve visibility and build long-term cyber resilience.

Supporting a rapidly evolving market

The Benelux region has long been at the forefront of digital innovation. As organizations continue modernizing their infrastructure, they’re also preparing for increasingly rigorous cybersecurity requirements through regulations such as NIS2 and DORA. Along these lines, operational resilience has become a board-level priority, making it more important than ever for security teams to simplify operations while maintaining visibility across their environments.

Meeting these expectations requires more than technology; it requires partners who understand the regional market, can provide specialist expertise, and help customers navigate an increasingly complex cybersecurity landscape.

Why specialist partnerships matter

Channel partners play a critical role in acting as trusted advisors who help organizations modernize security operations through technology evaluation, solution implementation, and long-term security strategy build-out.

Our expanded partnership with Exclusive Networks reflects Rapid7’s continued investment in supporting that partner ecosystem.

Exclusive Networks has established itself as one of the region’s leading specialist cybersecurity distributors, combining deep technical expertise with a partner-first approach that prioritizes enablement, collaboration, and long-term growth. Together, we’re making it easier for partners to access the technical resources, training, and support needed to deliver stronger outcomes for their customers.

Helping partners grow

Rapid7’s AI-powered cybersecurity operations platform helps organizations simplify security operations by unifying exposure management, threat detection and response, managed services, and security automation into one platform.

Combined with Exclusive Networks’ cybersecurity expertise, technical enablement, and regional support, partners are better positioned to expand managed security services, strengthen customer relationships, and deliver integrated cybersecurity solutions that reduce complexity and improve cyber resilience.

Looking ahead

Cybersecurity success increasingly depends on strong partnerships that combine innovative technology with local expertise and long-term collaboration.

Rapid7 and Exclusive Networks share a commitment to helping partners grow and enabling organizations across Belgium, the Netherlands, and Luxembourg to modernize security operations with confidence.

We’re excited about the opportunities ahead and look forward to working together to help partners build stronger cybersecurity practices and deliver measurable and positive outcomes for customers across the Benelux region.

Ready to grow with Rapid7? Learn more about the Rapid7 PACT Partner Program and discover how Rapid7 and Exclusive Networks are helping partners strengthen cybersecurity operations across the Benelux region.

Научни новини: Генетични редакции, ракети и сателити

2026-07-28 Михаил Ангелов

Post Syndicated from Михаил Ангелов original https://www.toest.bg/nauchni-novini-genetichni-redaktsii-raketi-i-sateliti/

Генетичните редакции скоро ще са в Европа

Научни новини: Генетични редакции, ракети и сателити

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

Мерките като цяло следват предложението на Комисията и в тях са обособени две категории растения.

Първата обхваща растения, получени с помощта на новите геномни технологии, като CRISPR, в които няма големи намеси, например внасяне на ДНК от други видове или промяна на големи участъци от генома. В текста има няколко специфични ограничения: внасянето на ДНК може да става само когато то е достъпно и при класическа селекция (тоест от видове, които могат да се кръстосат) и промените не могат да са по-големи от 20 нуклеотида. За изтриването на участъци няма ограничение колко дълъг отрязък може да се премахне, но общият брой на всички промени също е ограничен до 20 броя.

Пречките и надеждите пред CRISPR

Като всеки инструмент, CRISPR може да бъде използван и за спорни цели. Но възможностите, които предлага, са много обещаващи. Някоя от модификациите му или нова подобна система ще бъде в основата на…

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

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

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

Научни новини: ГМО и глобално затопляне

Да си поговорим за ГМО и глобално затопляне. В случая ще говори Михаил Ангелов чрез своите научни новини. Този път е подбрал две големи теми – за генетичните манипулации и за затоплянето на планетата.

Като резултат от промените на територията на ЕС ще могат да се отглеждат свободно всички растения от категория 1, които на практика ще бъдат третирани като получените от конвенционална селекция. Новите правила водят и до друга съществена промяна – страните членки ще бъдат силно ограничени във възможността си да налагат местни закони, забраняващи отглеждането на растения от категория 1, каквито имаше в редица европейски държави, включително и в България, въпреки че сортовете бяха одобрени на европейско ниво. Това обаче не означава, че в държавата до момента не е имало ГМО продукти – например вносът на такива фуражи и суровини за хранителната промишленост е напълно легален.

Приемането им като еквивалентни на конвенционалните води и до това, че

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

Означение ще има само на посевния материал.

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

Чисто решение няма и най-вероятно с времето ще има период на напасване и организиране на мерки за намаляване на риска. Производителите, които все още не го правят, ще трябва да започнат стриктно да пазят документацията за произхода на семената, които са използвали. Пространствената изолация от съседни посеви също може да помогне. Възможно е и създаването на своеобразни „молекулярни отпечатъци“ на новите сортове, които да ги каталогизират, подобно на сегашното спазване на правилата за различимост, хомогенност и стабилност (РХС), прилагани в конвенционалната селекция.

Тоест разговаряме – епизод 7

Как се разказва за наука разбираемо и отговорно? И защо критичното мислене е ключово в епохата на псевдонаучни твърдения и конспиративни интерпретации? Отговори на тези въпроси ни дава биологът и автор на „Научни новини“ Михаил Ангелов в седмия епизод на „Тоест разговаряме“.

В научните среди няма консенсус и дали всъщност новите растения следва да бъдат изключени от органичното земеделие. Консервативните нагласи са, че в него трябва да продължи спазването на по-класически методи за отглеждане, с ограничени третирания и сортове, получени с помощта на старата селекционна школа. От друга страна, натискът на климатичните промени ще затруднява този тип земеделие, а възможността за използване на сортове, съобразени с новите условия, е подходящ начин за облекчаване на работата.

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

Наред с биологичната безопасност стои въпросът с икономическата.

Към момента в Европа е възможно патентоването на генетично модифицирани растения, стига промените да не са резултат от „естествен биологичен процес“. С оглед на новите правила такъв тип патенти обяснимо създават напрежение, предвид силната концентрация на семепроизводството в няколко световни гиганта – четири фирми (Bayer, Corteva, Syngenta и BASF) контролират над 50% от световния пазар. Това им дава значителна преднина, тъй като те вече имат големи отдели за разработка на сортове с помощта на новите инструменти за селекция.

В началото на 2024 г. имаше предложение патентите за новите технологии да отпаднат напълно, но през декември 2025 г. то беше отхвърлено. Във вече приетите правила патентите са възможни, но селекционерите ще са длъжни да подават подробна патентна информация в публична база данни. Доброволно ще е съобщаването дали смятат да лицензират въпросната технология и при какви условия. Ще бъде създадена и експертна група, в която ще участват представители на държавите членки, Европейския патентен офис и Службата на Общността за сортовете растения.

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

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

Редактиране на генома с CRISPR

Михаил Ангелов • В последните няколко десетилетия в света на биотехнологиите са направени редица открития. Последният революционен скок в способността ни да променяме света около нас е CRISPR – инструмент, който позволява бързо, достъпно и прецизно редактиране на генома.

По думите на докладчика Джесика Полфьорд

това е историческа победа за европейските фермери и бъдещето на Европа.

Според нея с дерегулацията на новите геномни технологии, които са безопасни и научно подкрепени, се подсигурява устойчивото развитие на земеделието в Европа, което дава възможност за създаване на съвременни сортове, по-устойчиви и по-малко зависими от пестициди.

До появата на подобни продукти има още време – предстои официалното приемане на текста от Европейския парламент, след което промените ще бъдат публикувани в Официалния вестник на ЕС и ще влязат в сила 20 дни след това. Пълното прилагане ще започне след 24 месеца, през които ще бъдат изготвени различните правилници, протоколи за наблюдение и други методики. Практически ефектите ще се усетят след средата на 2028 г.

Приземяване на ракети, приземяване на акции

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

Благодарение на тази иновация компанията се разви значително и стана един от най-важните космически оператори. Компанията на Илон Мъск успя да върне възможността на NASA да изпраща астронавти към Международната космическа станция, за което САЩ разчиташе на Русия и нейните ракети „Съюз“ в продължение на 9 години. В тази връзка, след като САЩ наложи санкции на Русия, директорът на „Роскосмос“ Дмитрий Рогозин коментира, че американците могат да използват трамплин, за да изстрелват астронавтите си. Последва саркастичният отговор на Мъск след първия полет на SpaceX до станцията: „Трамплинът работи.“

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

Миналия ноември ракетата New Glenn на Blue Origin – компанията, финансирана от Джефри Безос, се приземи на баржа, по подобие на подхода на SpaceX, след като успешно изпрати към Марс два апарата за NASA. Това са Blue и Gold в мисията EscaPADE, които ще изучават магнитосферата на планетата и как слънчевият вятър почти изцяло е заличил атмосферата ѝ.

Към момента компанията планира да използва всяка ракета за поне 25 полета, което значително ще намали тяхната стойност. Впечатление направи и по-големият размер на ракетата, която е с около 10 метра по-висока от тази на SpaceX. В средата на април New Glenn полетя отново, оборудван с нови двигатели. Приземяването му беше успешно, но спътникът, който беше на борда, се оказа в по-ниска от очакваната орбита.

В началото на месеца успешно приземяване, отново на баржа, направи и китайската Long March 10B.

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

Този пуск е важен за китайската космическа програма, тъй като е част от по-голямата цел на страната за човешко присъствие в Космоса. Пряк аналог на 10B е 10А, с разликата, че е предвидена да качва не товар, а хора до китайската космическа станция „Тиенгун“. Успешното приземяване значи, че това ще може да става по-често и евтино. Още по-амбициозна е идеята за съединяване на три такива ракети, които могат да изнесат в орбита горна степен, която има възможност да стигне до Луната.

Ще полети ли България в Космоса?

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

Не е изключено от Китай да дойдат още изненади, защото в края на миналата година една частна китайска компания направи неуспешен опит за приземяване, последван от друга разновидност на Long March – 12A.

Успешни тестове се провеждат и в Япония. Миналата година Honda направи демонстрация на „подскок“ (hop), при който ракетата излита и се изкачва до 300 метра височина, а после се спуска и се приземява. Сходен прототип показа преди броени дни и японската космическа агенция JAXA. Той се изкачи до няколко метра, след което се придвижи хоризонтално и се приземи. Макар и далеч по-малки по размери в сравнение с нормалните ракети носители, тези прототипи показват ясно, че скоро преизползването им ще стане рутинно за повечето космически агенции и компании.

Китайският тест се състоя, когато цената на акциите на SpaceX падна стремглаво след изключително високото им позициониране при появата им на борсата, но най-вероятно между двете събития няма особена връзка.

Според подадените от SpaceX документи преди първоначалното публично предлагане на акциите ѝ само около 7% от стойността на компанията е свързана с космическата ѝ дейност и със сателитния интернет Starlink. От документите става ясно, че SpaceX, изглежда, основно е ИИ компания и високата цена за дял от нея отразява потенциала ѝ да извежда изчислителни центрове в Космоса. Илон Мъск не дава подробности как планира да изпълни тези обещания и да реши важните технически проблеми, които стоят пред реализирането на подобни изчислителни центрове.

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

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

Близнаците от NASA и ключът към живота ни в Космоса

NASA събира десет изследователски екипа, които проучват промените в човешкото тяло след продължителен престой в Космоса. В изследването участват и еднояйчните близнаци Кели. Скот престоява в Космоса една година, а брат му Марк остава на Земята. Анастасия Орманджиева разказва повече.

От инженерна точка с много големи радиатори и подходяща конструкция на сателитите не е невъзможно идеята да се осъществи, но с наличните в момента технологии (включително микрочипове), изпълнението ще е много скъпо и ще изисква сглобяване на центровете в Космоса, подобно на Международната космическа станция. Алтернатива е изстрелването на повече по-малки изчислителни центрове, но това пък ще вдигне цената поради нуждата от повече ракети и повече шасита, а също така ще увеличи броя сателити в орбита. Последното не е за пренебрегване, защото астрономите вече се оплакват от голямата флотилия спътници, обслужващи Starlink.

Междувременно SpaceX направи поредно тестово изстрелване на Starship – Flight 13. Този път на борда като тестови товар имаше няколко нови сателита Starlink V3, които се отделиха успешно от ракетата, но на суборбитална траектория, като след това се очакваше да изгорят в атмосферата. Самият Starship се представи добре, като най-впечатляващи бяха обръщането му в атмосферата – своеобразна проверка как се държат топлинните му щитове, и последващото меко кацане в океана. В бъдеще тези кацания ще бъдат на ракетни площадки, така че ракетата да може да се преизползва. Носителят Super Heavy се справи с изнасянето на Starship към Космоса, но при кацането се задействаха само част от двигателите му и той направи „твърдо приземяване“ в океана. Този тест беше важен за компанията и за NASA, защото е част от програмата Artemis за изпращане на астронавти на Луната.

Веднъж месечно Михаил Ангелов – биолог, агроном и любим нърд от нашия екип, ни представя най-интересните скорошни новини от различни сфери на науката и обяснява защо тези постижения са толкова значими за света и човечеството. Или най-малкото – любопитни и забавни.

AWS Shield Advanced is embracing the AWS WAF Anti-DDoS managed rule group: What changes and how to prepare

2026-07-27 Eitav Arditti

Post Syndicated from Eitav Arditti original https://aws.amazon.com/blogs/security/aws-shield-advanced-is-embracing-the-aws-waf-anti-ddos-managed-rule-group-what-changes-and-how-to-prepare/

Application-layer distributed denial of service (DDoS) attacks are difficult to detect because they closely resemble legitimate traffic. HTTP request floods are now among the most common vectors targeting web applications, using valid-looking requests that blend in with normal user activity.

In June 2025, AWS launched the AWS WAF Anti-DDoS managed rule group, built specifically for application-layer (L7) DDoS protection. AWS Shield Advanced is adopting it as the default application-layer protection, and in time as the only one. On July 27, AWS Shield Advanced begins adding the Anti-DDoS managed rule group to eligible web access control lists (ACLs) in Count mode. It will not cause any interruption to your traffic alongside your existing L7 automatic mitigation and WAF rules. In this blog post, we provide details regarding the Anti-DDoS managed rule group and when the change is expected to reach your web ACLs. You will understand the phases and steps that you need to take before the finish date, including how the monitoring and metrics will change.

Anti-DDoS managed rule group features

The Anti-DDoS managed rule group builds on what Shield Advanced automatic mitigation already provides. It profiles your traffic, learns what normal traffic looks like for your application, and establishes a baseline in minutes rather than hours. When an attack starts, it reacts within seconds and there are no health checks to configure. The rule group adds a Challenge action to the Block and Count actions you already use. Challenge decisions are driven by the AMR labels that mark the suspicion level of each inspected request. One option is a silent browser challenge, which has a background verification that runs in the visitor’s browser with no interstitial page, so legitimate users are never interrupted while automated traffic is filtered out. You can also exclude workload paths that don’t support Challenge, which fall back to Block mitigations instead. Sensitivity is configurable to Low, Medium, or High, and you set it separately for Block and Challenge. Block and Challenge are tuned independently; meaning you can run Challenge at high sensitivity to catch more suspicious traffic while keeping Block low to avoid dropping legitimate requests or reverse it for a stricter posture.

The rest is about cost and visibility:

It uses less capacity than before. The rule group needs 50 web ACL capacity units (WCUs), down from the 150 the previous protection required, providing you with capacity for the rest of your rules.
The dashboard ships in the AWS Management Console for AWS WAF. It’s there now, showing live DDoS events, match metrics, and the top URIs, geographies, and IP addresses driving traffic.
It labels everything it inspects. Requests get labels for event-detected, graduated suspicion levels, and specific rules. Match on those labels in your own AWS WAF rules when you need logic the rule group doesn’t cover.
You don’t pay for the attack traffic. During active mitigation, blocked DDoS requests drop out of your monthly count. That exclusion covers AWS WAF request fees, Anti-DDoS managed rule group request fees, and Shield Advanced request charges.

AWS Shield Advanced isn’t required to use any of these features. Shield Advanced subscribers get the rule group included with AWS WAF and any customer can turn it on independently. See AWS WAF pricing for more information on costs.

Implementation details

Shield Advanced upgrades application-layer DDoS protection in five phases. The following dates are when AWS will act automatically, not the earliest date when you can act. After the rule group is deployed in Count mode on July 27, 2026, you can begin migrating right away rather than waiting for the October auto-upgrade. There’s no window where protection lapses. Your current automatic mitigation stays active through every phase until the Anti-DDoS managed rule group takes over. That handoff happens in a single operation, with no cutover window and no gap for your traffic flows.

Phase 1: Anti-DDoS managed rule group deployed in Count mode (rolling out July 27–August 7, 2026)

AWS adds the Anti-DDoS managed rule group in Count mode to every web ACL eligible for this rollout. Eligible means any Shield Advanced web ACL with at least one resource using application-layer automatic mitigation that isn’t already running the Anti-DDoS rule group. This is a broader set than the web ACLs eligible for the October auto-upgrade (Phase 3), which applies a stricter test. The deployment rolls out gradually, starting July 27 and expected to finish by August 7, 2026, so different web ACLs might be updated on different days. There’s no impact to your traffic because the rule group watches and labels requests without acting on them while your existing automatic mitigation keeps running. Throughout the evaluation period, you receive DDoS events, metrics, and AWS WAF labels at no additional charge.

Phase 2: Free evaluation period (July 27–September 30, 2026)

The existing automatic mitigation and the Anti-DDoS managed rule group run side by side each detecting independently. Automatic mitigation continues to protect your resources while the rule group operates in Count mode. To compare their detection results, use the DDoSAttackRequests metric, AWS WAF labels, and the Anti-DDoS dashboard. All Anti-DDoS managed rule group charges are waived during this period, including the subscription fee, per-request fees, and WCU consumption costs for the eligible web ACLs from phase 1.

Phase 3: Auto-upgrade begins (October 1, 2026)

For eligible web ACLs, the auto-upgrade mirrors your existing automatic mitigation configuration. The rule group inherits your current setting, so a Block configuration comes up in Block mode and a Count configuration comes up in Count mode in a single, atomic operation. The rule group takes over in the same step that disables automatic mitigation, so protection never drops for an instant. This is a handoff rather than a cutover with no window where your resources are unprotected. If you’d rather not upgrade you can opt out by contacting AWS Support before the auto-upgrade date.

Phase 4: Guided migration (available July 27–December 31, 2026)

You don’t have to wait for the October auto-upgrade to migrate. As soon as the rule group is deployed in Count mode between July 27 and August 7, 2026, you can move to it on your own schedule. This is the path to use for web ACLs that aren’t eligible for the Phase 3 auto-upgrade, meaning mixed-mode web ACLs or ones with resources that don’t have automatic mitigation enabled. Work with your AWS account team and AWS Support at any point in this window to plan and complete the migration. Eligible web ACLs are also upgraded automatically starting October 1 (Phase 3), so guided migration is mainly for the web ACLs the auto-upgrade can’t cover.

Phase 5: Shield Advanced application-layer automatic mitigation sunset (January 1, 2027)

As of January 1, 2027, the Shield Advanced application-layer automatic mitigation feature will no longer be available. Resources that haven’t migrated to the Anti-DDoS managed rule group will lose automatic application-layer DDoS mitigation.

Capability	Shield Advanced application layer automatic mitigation	Anti-DDoS managed rule group (AWSManagedRulesAntiDDoSRuleSet)
Feature type	Shield Advanced automatic mitigation	AWS WAF managed rule group
Detection and mitigation speed	Requires a baseline period; mitigation varies per event	Enhanced detection and faster mitigation
Configuration scope	Per resource (Shield API)	Per web ACL (AWS WAF API)
Mitigation actions	Count, Block	Count, Block, and Challenge
Sensitivity controls	None	Low, Medium, and High for both Block and Challenge
Non-HTML path handling	N/A	URI regex exemptions for Challenge
WCU consumption	150 WCUs	50 WCUs
Health checks	Required (Amazon Route 53 health-based detection)	Not required, provides automatic traffic profiling
Availability	Shield Advanced only	AWS WAF and Shield Advanced (see pricing)

Observability

The existing automatic mitigation and the Anti-DDoS managed rule group use separate Amazon CloudWatch namespaces and metric structures. The rule group gives you three tiers of observability: tier 1 tells you an attack is happening, tier 2 shows which requests it flagged and why, and tier 3 shows what it did about them. You don’t need all three on day 1 because most customer teams start at tier 1 to confirm detection is working, then add the others as they tune.

Tier 1: Event detection alarms

You can detect DDoS events using two CloudWatch metrics, each with its own namespace.

	DDoSDetected (Shield)	DDoSAttackRequests (Anti-DDoS managed rule group)
Namespace	AWS/DDoSProtection	AWS/WAFV2
Requires Shield Advanced	Yes	No
Scope	L3, L4, and L7 events	L7 events only
Value during event	Binary (0 or 1)	Count of requests observed
Value outside event	Reported once daily (keeps metric alive)	Absent (no data points)
Dimensions	ResourceArn	Resource, ResourceType

What this means for your existing alarms:

After the application-layer automatic mitigation feature is sunset, DDoSDetected still fires for infrastructure layer 3 and layer 4 events, so your existing network layer and transport layer alarms remain valid. For the full list, see AWS Shield Advanced metrics.
DDoSAttackRequests is the Anti-DDoS managed rule group equivalent for application-layer event detection. Alarm on Sum >= 1 to detect any event, or set a volume threshold (for example, more than 10,000 requests per minute) for severity-based alerting.
During the evaluation period, both metrics fire independently and you can validate detection parity before migrating your application-layer alarms.
Because DDoSAttackRequests is absent when there are no active DDoS events, set treat-missing-data to missing or notBreaching for alarms on this metric.

Tier 2: Detection labels for custom monitoring

Every request the Anti-DDoS managed rule group evaluates gets a label. Where tier 1 tells you an attack started, tier 2 shows which requests looked suspicious and how confident the rule group was. The labels surface as AWS WAF metrics in the AWS/WAFV2 namespace: AllowedRequests, BlockedRequests, and CountRuleMatch. Each carries the LabelName and LabelNamespace dimensions under the awswaf:managed:aws:anti-ddos: namespace.

event-detected – Requests observed during a detected DDoS event
ddos-request – Requests identified as part of the attack
low-suspicion-ddos-request, medium-suspicion-ddos-request, high-suspicion-ddos-request – Graduated suspicion levels
challengeable-request – Requests eligible for browser challenge

Chart suspicion-level trends on a CloudWatch dashboard to see how an attack builds. Match on the labels in your own AWS WAF rules or dig into them in your AWS WAF logs with CloudWatch Logs Insights or Amazon Athena when you need to understand a specific event after the fact.

Tier 3: Mitigation action metrics

Where tier 2 shows what the rule group flagged, tier 3 shows what it did about those requests during an event. You’ll find these metrics as ChallengeRequests, BlockedRequests, and CountRuleMatch, each scoped by the rule label that produced it.

ChallengeAllDuringEvent – Requests challenged during an active event
ChallengeDDoSRequests – Suspected DDoS requests challenged based on suspicion level
DDoSRequests – Requests blocked (or counted in Count mode)

Watch these during a live event to see whether mitigation is keeping up. If you’re challenging far more requests than you’re blocking, your configuration might be too cautious, and you can raise the sensitivity level after you trust the numbers.

Observability summary

Tier	Automatic mitigation	Anti-DDoS managed rule group
Event alarm	DDoSDetected in AWS/DDoSProtection (binary, L3/L4/L7)	DDoSAttackRequests in AWS/WAFV2 (request count, L7)
Detection labels	None	event-detected, ddos-request, suspicion levels, challengeable-request
Mitigation actions	Not visible (Shield-managed rule group metrics not exposed)	ChallengeAllDuringEvent, ChallengeDDoSRequests, DDoSRequests
Dashboard	Shield console event history	Shield console and Anti-DDoS dashboard in the AWS WAF console
Historical analysis	Shield event history only	AWS WAF logs (CloudWatch Logs, Amazon Simple Storage Service (Amazon S3), Amazon Data Firehose)

Billing

Your Shield Advanced subscription includes the Anti-DDoS managed rule group for up to 50 billion requests per month, counted across your whole organization at the payer account level. For most customers that ceiling is well above normal traffic, so you won’t see a line item here unless you’re operating at very high volume. For the exact rates, see AWS WAF pricing and Shield Advanced pricing.

You aren’t charged for DDoS traffic while the Anti-DDoS managed rule group is actively mitigating, which means Block or Challenge mode rather than Count. This applies to AWS WAF request fees, Anti-DDoS managed rule group request fees, and Shield Advanced request charges. Leaving the rule group in Count mode past the evaluation period costs you the protection without the billing relief, so avoid staying in Count mode longer than you need to validate.

During the evaluation period (July 27 to September 30, 2026), the eligible web ACLs AWS auto-enrolled don’t incur per-request fees or WCU consumption, even when configured in Count mode.

The Anti-DDoS managed rule group works at the web ACL level, so every resource you associate with a web ACL shares that coverage. Before assuming a single resource accounts for the whole cost, look at how many resources sit behind each web ACL. A web ACL fronting 20 resources bills differently from one fronting 2, so check that count first and familiarize yourself with the workload protected by each web ACL.

Adding the Anti-DDoS managed rule group to a web ACL yourself isn’t part of the upgrade path, so standard pricing applies from the moment you enable it. The same is true for any resource that was already running the rule group before the rollout. To get the free evaluation, let the automatic rollout reach your web ACLs rather than adding the rule group ahead of it. There’s no penalty for adding it yourself; you just don’t receive the waiver on that web ACL.

Update your infrastructure as code

If you manage web ACLs with AWS CloudFormation, AWS Cloud Development Kit (AWS CDK), Terraform, or other infrastructure as code (IaC), the auto-upgrade changes your infrastructure configuration outside your templates. Your code is still the source of truth, so you need to do two things. First, change where the protection is declared. Today you enable application-layer automatic mitigation through the Shield API (EnableApplicationLayerAutomaticResponse), configured per protected resource. The Anti-DDoS managed rule group is configured through the AWS WAF API instead (CreateWebACL and UpdateWebACL), as a managed rule group statement inside the web ACL, scoped per web ACL rather than per resource. In IaC terms, you remove the Shield automatic-response block (for example, Terraform’s aws_shield_application_layer_automatic_response) and add the WAF managed rule group statement shown in the following section. Second, pull the upgraded web ACL back into your tooling before your next deploy, or your pipeline will try to revert the change.

For the full statement in Terraform, CloudFormation, and the AWS CDK, plus how to sync state after the auto-upgrade (terraform plan, CloudFormation drift detection, cdk diff), see the iac-webacl-examples helper.

Update your AWS Firewall Manager policy

If you run a Shield Advanced policy in AWS Firewall Manager today, that policy is what enabled application-layer automatic mitigation across your accounts. To keep that protection, add the Anti-DDoS managed rule group to an AWS WAF Firewall Manager policy. Your Shield Advanced policy still handles L3 and L4, while the application-layer piece moves to the AWS WAF policy. The migration is straightforward: add or reuse an AWS WAF Firewall Manager policy, put the Anti-DDoS managed rule group in it, and scope it to the same accounts and resources your Shield Advanced policy covers.

You can’t add the rule group from the Shield console or by editing an account-level web ACL directly, because Firewall Manager owns the web ACLs it creates and overwrites local edits. Instead, add the rule group to the AWS WAF policy and Firewall Manager pushes it to every in-scope account.

You can make this change in the console or as code. If you manage your Firewall Manager policies as code, don’t edit them in the console: add a new AWS WAF policy or update an existing one in your templates with the Anti-DDoS managed rule group included, and deploy it using the following Firewall Manager policies using IaC steps. Otherwise, use the console.

In the console, follow Creating an AWS Firewall Manager policy for AWS WAF to create the policy and reach the Edit policy rules page. Add the Anti-DDoS rule group, listed there as AWS AntiDDoS Protection for Layer 7 attacks (AWSManagedRulesAntiDDoSRuleSet), as a new rule group under First rule groups so it evaluates before your other managed groups, but below any Allow custom rules you use to fast-path known-good traffic.

If you protect CloudFront distributions, make this change in your Global policy, and repeat it in each AWS Regional policy for regional resources. Save the policy, and Firewall Manager rolls the change out to in-scope accounts, which can take a few minutes.

After being added, the rule group appears as the first rule group in the policy, as shown in the following screenshot:

Figure 1: AntiDDoS enabled

Firewall Manager policies using IaC

If you manage Firewall Manager policies as code, make the change in your template instead of the console. The Anti-DDoS managed rule group goes into the AWS WAF policy’s ManagedServiceData, a WAFV2 policy definition carried as a JSON string, added to the first rule groups so it evaluates early. For the ManagedServiceData JSON with CloudFormation, Terraform, and AWS CDK examples, see the firewall-manager-examples helper.

Whichever path you take, scope the policy to the same accounts and resources your Shield Advanced policy already covers, so no resource loses application-layer protection during the move.

Getting started

Between July 27 and August 7, 2026, AWS will add the Anti-DDoS managed rule group in Count mode to Shield Advanced web ACLs that have resources using application layer automatic mitigation but not yet the Anti-DDoS rule group. After it reaches your web ACL, you can evaluate it, and migrate whenever you’re ready, without waiting for the October auto-upgrade.

Review the Anti-DDoS dashboard in the AWS WAF console. The dashboard shows real-time DDoS events, match metrics, and top traffic sources.
Compare event detection side by side. During Count mode, both systems detect independently. Check the DDoSDetected metric in AWS/DDoSProtection alongside DDoSAttackRequests in AWS/WAFV2 to validate detection parity for your resources. You can deploy the CloudWatch comparison dashboard from the AWS Samples repository to view both systems on a single dashboard.
Explore AWS WAF labels. Enable AWS WAF logging and query for labels in the awswaf:managed:aws:anti-ddos: namespace. Look at suspicion levels (low-suspicion-ddos-request, medium-suspicion-ddos-request, high-suspicion-ddos-request), event-detected, and challengeable-request to see per-request visibility into detected events.
Start with Low sensitivity for Block actions during evaluation to minimize false positive risk. Tune up as you gain confidence from the Anti-DDoS dashboard and AWS WAF label data.
Plan your configuration. Review sensitivity levels, URI exemptions for non-HTML paths, and web ACL priority placement. The Anti-DDoS managed rule group should run at the highest priority in your web ACL, or right below any custom rules with the Allow action.
Sync your IaC templates. After the auto-upgrade adds the Anti-DDoS managed rule group to your web ACL, fetch the current state into your IaC tooling (Terraform refresh, CloudFormation drift detection, AWS CDK import) before your next deployment.

Conclusion

The Anti-DDoS managed rule group profiles your traffic within minutes and mitigates within seconds, where the automatic mitigation it builds on established its baseline over hours, and it gives you granular visibility into what it’s doing. The evaluation period exists so you can watch both systems run on your own traffic before anything changes. Spend the first few weeks in Count mode confirming the new detection matches what you see today, then move your alarms over and pick a sensitivity level you’re comfortable with. If you run a web ACL across several resources, or you manage rules through AWS Firewall Manager, contact AWS Support before you start so you don’t have to unwind anything later. The Shield Advanced application-layer automatic mitigation feature retires on January 1, 2027, and anything still relying on it needs to be migrated by then.

Resources

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

[$] Hazard pointers for the kernel

2026-07-27 corbet

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

The kernel’s read-copy-update (RCU) subsystem ensures that data will not be
deleted until it is known that there are no threads holding references to
it. RCU works well and is widely used throughout the kernel, but it can
increase memory use and add significant delays before unused kernel objects
are cleaned up. Hazard pointers are
an alternative approach to lockless data updates that offers better
performance, for some situations at least. The kernel community is
currently considering a
hazard-pointer implementation by Mathieu Desnoyers and Paul McKenney.

Announcing the Cloud Security Alliance on AWS Compliance Guide

2026-07-27 Juan Rodriguez

Post Syndicated from Juan Rodriguez original https://aws.amazon.com/blogs/security/announcing-the-cloud-security-alliance-on-aws-compliance-guide/

AWS Security Assurance Services is announcing the release of the Cloud Security Alliance (CSA) Compliance Guide on Amazon Web Service (AWS), a new resource that maps the 17 control domains and 207 control objectives of the Cloud Controls Matrix v4.1 (CCM) to AWS services and recommended implementation practices. The guide is intended to help organizations using AWS plan, implement, and evidence the controls relevant to their CCM scope, including those pursuing or maintaining CSA STAR certification.

What is the Cloud Controls Matrix?

The Cloud Security Alliance is a not-for-profit organization dedicated to defining and raising awareness of best practices for cloud security. AWS maintains CSA STAR Level 2 certification, which couples the requirements of ISO/IEC 27001:2022 with the CCM. The CSA STAR documentation and the AWS Consensus Assessments Initiative Questionnaire (CAIQ) are available to AWS customers through AWS Artifact.

The CSA Cloud Controls Matrix is a cybersecurity controls framework developed by the CSA that provides a detailed set of security controls mapped across multiple domains (such as audit and assurance, identity and access management, and encryption and key management) specifically designed to assess and manage security risks in cloud computing environments. The CCM is cloud agnostic, designed to be applicable to any cloud service provider or deployment model, such as infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS), regardless of the underlying technology or vendor, providing universal security controls that organizations can apply across cloud platforms.

Responsibility models

CCM defines its own Shared Security Responsibility Model (SSRM) with three categories: Cloud service provider (CSP)-owned, customer-owned, and shared (independent or dependent). The guide recommends using the SSRM together with the AWS Shared Responsibility Model. For controls that AWS owns, the guide points to AWS attestations available through AWS Artifact (for example, SOC reports, ISO certificates, and the CSA STAR attestation) as inherited evidence. For controls that customers own or share, the guide describes how to implement and evidence them using AWS services. Using a CSA STAR–certified AWS service doesn’t by itself make a customer workload compliant. Customers remain responsible for configuring services, managing access, protecting data, and implementing additional controls based on their environment, risk assessments, and regulatory obligations. The guide is informational and doesn’t replace the AWS compliance documentation and certifications available through AWS Artifact.

What’s inside the guide

For each control, the guide states applicability, describes how organizations can implement the control on AWS, identifies common pitfalls, and lists examples that can be used as evidence during an assessment.

Related resources

Download available: Here

For further assistance, contact AWS Security Assurance Services. If you have feedback about this post, submit comments in the Comments section below.

The case for change

Why Fanatics Commerce chose Amazon SES

Platform architecture

Application layer

Managed dedicated IPs

Domain and subdomain strategy

Multi-tenant email design

Real-time observability

Scaling with the seasons

The partnership model

What’s next

Conclusion

About the authors

Solution overview

How semantic search and semantic highlighting work together

Semantic highlighting model deployment

Index configuration

Implementation steps

Prerequisites

Deploy the solution

(Optional) Automated deployment with Claude Code CLI

Test the solution

Optimizing for scale: batch semantic highlighting

Best practices

Clean up resources

Conclusion

About the authors

Natural disasters and electricity cause disruptions in Guam, Venezuela, and Tanzania

Governments and geopolitics impact connectivity in Iran, UAE, Iraq and Sudan

Infrastructure vulnerabilities affect users in Germany and Saint Lucia

Radar continues to monitor disruptions

Why compliance needs to move at the speed of security

How Cyber GRC connects action to proof

Why third-party risk needs to be part of the same workflow

Give leadership a better risk story

Why Rapid7

MDR must move beyond alert-driven investigations

Preemptive MDR connects exposure and detection

Agentic SOC capabilities accelerate investigation

Connected security data strengthens AI-driven MDR

From faster response to continuous defense

4 days, 101 delegates, 277 tasks

Promoting computational thinking around the world

Learning from a global community

Growing the Bebras community

Creating the conditions for collaboration

What’s next for UK Bebras?

Supporting a rapidly evolving market

Why specialist partnerships matter

Helping partners grow

Looking ahead

Генетичните редакции скоро ще са в Европа

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

Наред с биологичната безопасност стои въпросът с икономическата.

Приземяване на ракети, приземяване на акции

В началото на месеца успешно приземяване, отново на баржа, направи и китайската Long March 10B.

Anti-DDoS managed rule group features

Implementation details

Phase 1: Anti-DDoS managed rule group deployed in Count mode (rolling out July 27–August 7, 2026)

Phase 2: Free evaluation period (July 27–September 30, 2026)

Phase 3: Auto-upgrade begins (October 1, 2026)

Phase 4: Guided migration (available July 27–December 31, 2026)

Phase 5: Shield Advanced application-layer automatic mitigation sunset (January 1, 2027)

Observability

Tier 1: Event detection alarms

Tier 2: Detection labels for custom monitoring

Tier 3: Mitigation action metrics

Observability summary

Billing

Update your infrastructure as code

Update your AWS Firewall Manager policy

Firewall Manager policies using IaC

Getting started

Conclusion

Resources

What is the Cloud Controls Matrix?

Responsibility models

What’s inside the guide

Related resources

The collective thoughts of the interwebz