Amazon Web Services (AWS) is pleased to announce that the Winter 2024 System and Organization Controls (SOC) 1 report is now available. The report covers 183 services over the 12-month period from January 1, 2024, to December 31, 2024, giving customers a full year of assurance. This report demonstrates our continuous commitment to adhere to the heightened expectations for cloud service providers.
AWS strives to continuously bring services into the scope of its compliance programs to help customers meet their architectural and regulatory needs. Customers can reach out to their AWS account team if they have any questions or feedback about SOC compliance.
To learn more about AWS compliance and security programs, see AWS Compliance Programs. As always, we value feedback and questions; reach out to the AWS Compliance team through the Contact Us page.
If you have feedback about this post, submit comments in the Comments section below.
The IAR provides management and technical information security controls to help establish, implement, maintain, and continuously improve information assurance. AWS alignment with IAR requirements demonstrates our ongoing commitment to adhere to the heightened expectations for cloud service providers. As such, IAR-regulated customers can continue to use AWS services with confidence.
Independent third-party auditors from BDO evaluated AWS for the period of November 1, 2023, to October 31, 2024. The assessment report that illustrates the status of AWS compliance is available through AWS Artifact. AWS Artifact is a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact.
AWS strives to continuously bring services into the scope of its compliance programs to help you meet your architectural and regulatory needs. If you have questions or feedback about IAR compliance, reach out to your AWS account team.
To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.
If you have feedback about this post, submit comments in the Comments section below.
Every day, I talk with security leaders who are navigating a critical balancing act. On one side, their organizations are moving faster than ever, adopting transformative technologies like generative AI and expanding their cloud footprint. On the other, they’re working to maintain strong security controls and visibility across an increasingly complex landscape. We all know that adding more tools and controls isn’t sustainable. We need a different approach to security at scale.
re:Inforce 2025: Your roadmap to security that powers innovation
This is what shaped our vision for AWS re:Inforce 2025. When done right, security at scale becomes a business accelerator, helping organizations move faster and more confidently in the cloud. This is more than just a philosophy; it’s a practical reality I’ve seen proven time and again by our customers, and it’s what we want to help every organization achieve.
At re:Inforce, we’ll share a vision for simplifying security at scale that’s deeply rooted in our experiences supporting millions of customers worldwide. We’ll explore how organizations are building inherently resilient applications that can withstand modern threats while accelerating innovation. I’m particularly excited to showcase real customer examples and architectural patterns that demonstrate how security better enables your business goals.
An environment built for learning cloud security
There’s a reason we created re:Inforce as a dedicated in-person security event. While I love our broader AWS events, security practitioners need space to dive deep into implementation details, ask tough questions, and work through complex scenarios. At re:Inforce, you can grab a whiteboard with the engineers who built our security services, collaborate with security partners, and schedule personal time with our leaders to tackle your specific security needs. It’s the kind of environment where real learning happens.
We’ve designed multiple learning paths to meet you wherever you are in your security journey. With over 250 technical sessions, you’ll find content that matches your needs – whether you’re looking to automate security controls, align development and security teams, or transform your security operations. You’ll find interactive workshops where you’ll build solutions in real-time, small-group technical deep-dives, hands-on labs where you can test new approaches, and solution-building sessions with AWS experts. Best of all, 70% of our content is at advanced or expert level, making sure you get the detailed implementation guidance you need.
I invite you to join us for three days that will transform how you think about and implement security in the cloud. Registration is now open, and I encourage you to secure your spot early—based on previous years, spots will fill up quickly. Join us to explore how simplified, scalable cloud security can fuel your organization’s future.Register today with the code SECBLObhZzr9 to receive a limited time $300 USD discount, while supplies last.
If you have feedback about this post, submit comments in the Comments section below.
This alignment with DESC requirements demonstrates our continued commitment to adhere to the heightened expectations for CSPs. Government customers of AWS can run their applications in AWS Cloud-certified Regions with confidence.
The independent third-party auditor (BSI) issued the Certificate of Compliance to AWS on behalf of DESC on January 23, 2025. The Certificate of Compliance that illustrates the compliance status of AWS is available through AWS Artifact. AWS Artifact is a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact.
The certification includes 11 additional services in scope, for a total of 98 services. This is a 13% year-on-year increase in the number of services in the Middle East (UAE) Region that are in scope of the DESC CSP certification. For up-to-date information, including when additional services are added, see the AWS Services in Scope by Compliance Program webpage and choose DESC CSP.
AWS strives to continuously bring services into the scope of its compliance programs to help you adhere to your architectural and regulatory needs. If you have questions or feedback about DESC compliance, reach out to your AWS account team.
To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.
If you have feedback about this post, submit comments in the Comments section below.
We’ve added four additional AWS services to the audit scope since the last certification issued on November 29, 2024. These are the four additional services:
For a full list of AWS services that are certified under ISO and CSA STAR, see the AWS ISO and CSA STAR Certified page. You can also access the certifications in the AWS Management Console through AWS Artifact.
If you have feedback about this post, submit comments in the Comments section below.
By implementing the PBHVA control overlay over a CCCS Medium baseline, you can better protect your organization’s most critical assets from potential threats and vulnerabilities, providing continuity of essential government operations and safeguarding sensitive information.
Understanding CCCS PBHVA overlay requirements
The CCCS PBHVA overlay consists of 137 controls designed to protect high-value assets, including 69 new controls and 68 controls from CCCS Medium. These controls provide enhanced data protection, particularly for integrity and availability, and are based on NIST SP 800-53 Revision 5.
Key findings from the Coalfire assessment
Coalfire’s assessment found that the LZA on AWS solution significantly supports CCCS PBHVA overlay compliance requirements:
71 percent of in-scope controls (97 of 137) are supported by the AWS contribution to compliance in the shared responsibility model
The solution uses over 35 AWS services to provide comprehensive security capabilities
Strong network segmentation is achieved through network account and network-boundary VPC design
Infrastructure-as-code (IaC) enables reliable build and deployment results
The 29 percent of controls not addressed by the LZA are on the customer side of the shared responsibility model. They are addressed in the customer’s application stack or as non-technical controls such as policies and procedures.
Key security capabilities
The LZA solution implements several critical security features:
While the LZA solution provides significant compliance support, organizations should note:
The solution alone does not guarantee compliance
Organizations must implement their own policies, standards, and procedures
A thorough understanding of the shared responsibility model is essential
The AWS Landing Zone Accelerator Verified Reference Architecture documentation is available for customer download in AWS Artifact. This resource can help organizations reduce the time and effort required to deploy an environment that aligns with CCCS PBHVA overlay requirements.
Conclusion
The Coalfire assessment confirms that the LZA on AWS solution provides effective support for CCCS PBHVA overlay compliance objectives. However, organizations should remember that compliance is an ongoing process that requires active management and cannot be achieved through technology alone.
For more information about implementing the Landing Zone Accelerator for CCCS PBHVA overlay requirements, contact your AWS account team or the AWS Public Sector team directly.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
February 12, 2025: This post was republished to include new services and features that have launched since the original publication date of June 11, 2020.
Encryption is a critical component of a defense-in-depth security strategy that uses multiple defensive mechanisms to protect workloads, data, and assets. As organizations look to innovate while building trust with customers, they need to meet critical compliance requirements and improve data security. Encryption, when used correctly, adds a layer of protection against unauthorized access that can help you strengthen data protection, adhere to regulations and standards, and enhance the security of communications.
How and why does encryption work?
Encryption works by using an algorithm with a key to convert data into unreadable data (ciphertext) that can only become readable again with the right key. For example, a simple phrase like “Hello World!” may look like “1c28df2b595b4e30b7b07500963dc7c” when encrypted. There are several different types of encryption algorithms, all using different types of keys. A strong encryption algorithm relies on mathematical properties to produce ciphertext that can’t be decrypted using any practically available amount of computing power without also having the necessary key. Therefore, protecting and managing the keys becomes a critical part of any encryption solution.
Encryption as part of your security strategy
An effective security strategy begins with stringent access control and continuous work to define the least privilege necessary for persons or systems accessing data. When using the AWS Cloud, you adopt the model of shared responsibility. You are responsible for managing your own access control policies. Encryption is a critical component of a defense-in-depth strategy because it can mitigate weaknesses in your primary access control mechanism. What if an access control mechanism fails and allows access to the raw data on disk or traveling along a network link? If the data is encrypted using a strong key, as long as the decryption key is not on the same system as your data, it is computationally infeasible for a bad actor to decrypt your data.
To show how infeasible this is, let’s consider the Advanced Encryption Standard (AES) with 256-bit keys (AES-256). It’s the strongest industry-adopted and government-approved algorithm for encrypting data. AES-256 is the technology we use to encrypt data in AWS, including Amazon Simple Storage Service (S3) server-side encryption. It would take at least a trillion years to break using current (and foreseeable future) computing technology. Current research suggests that even the future availability of quantum-based computing won’t sufficiently reduce the time it would take to break AES-256 encryption.
But what if you mistakenly create overly permissive access policies on your data? A well-designed encryption and key management system can also help prevent this from becoming an issue, because it separates access to the decryption key from access to your data.
Requirements for an encryption solution
To get the most from an encryption solution, you need to think about two things:
Protecting keys at rest: Are the systems using encryption keys secured so the keys can never be used outside the system? In addition, do these systems implement encryption algorithms correctly to produce strong ciphertexts that cannot be decrypted without access to the right keys?
Independent key management: Is the authorization to use encryption independent from how access to the underlying data is controlled?
There are third-party solutions that you can bring to AWS to help meet these requirements. However, these systems can be difficult and expensive to operate at scale. AWS offers a range of options to simplify encryption and key management.
Protecting keys at rest
When you use third-party key management solutions, it can be difficult to gauge the risk of your plaintext keys leaking and being used outside the solution. The keys have to be stored somewhere, and you can’t always know or audit all the ways those storage systems are secured from unauthorized access. The combination of technical complexity and the necessity of making the encryption usable without degrading performance or availability means that choosing and operating a key management solution can present difficult tradeoffs. The best practice to maximize key security is using a hardware security module (HSM). This is a specialized computing device that has several security controls built into it to help prevent encryption keys from leaving the device in a way that could allow an adversary to access and use those keys.
One such control in modern HSMs is tamper response, in which the device detects physical or logical attempts to access plaintext keys without authorization, and destroys the keys before the attack succeeds. Because you can’t install and operate your own hardware in AWS datacenters, AWS offers two services using HSMs with tamper response to protect customers’ keys: AWS Key Management Service (AWS KMS), which manages a fleet of HSMs on the customer’s behalf, and AWS CloudHSM, which gives customers the ability to manage their own HSMs. Each service can create keys on your behalf, or you can import keys from your on-premises systems to be used by each service.
The keys in AWS KMS or AWS CloudHSM can be used to encrypt data directly, or to protect other keys that are distributed to applications that directly encrypt data. The technique of encrypting encryption keys is called envelope encryption, and it enables encryption and decryption to happen on the computer where the plaintext customer data exists, rather than sending the data to the HSM each time. For very large data sets (e.g., a database), it’s not practical to move gigabytes of data between the data set and the HSM for every read/write operation. Instead, envelope encryption allows a data encryption key to be distributed to the application when it’s needed. The “master” keys in the HSM are used to encrypt a copy of the data key so the application can store the encrypted key alongside the data encrypted under that key. Once the application encrypts the data, the plaintext copy of data key can be deleted from its memory. The only way for the data to be decrypted is if the encrypted data key, which is only a few hundred bytes in size, is sent back to the HSM and decrypted.
The process of envelope encryption is used in AWS services in which data is encrypted on a customer’s behalf (which is known as server-side encryption) to minimize performance degradation. If you want to encrypt data in your own applications (client-side encryption), you’re encouraged to use envelope encryption with AWS KMS or AWS CloudHSM. Both services offer client libraries and SDKs to add encryption functionality to their application code and use the cryptographic functionality of each service. The AWS Encryption SDK is an example of a tool that can be used anywhere, not just in applications running in AWS. To make it easier for customers to encrypt data in databases like Amazon DynamoDB, we built the AWS Database Encryption SDK. The AWS Database Encryption SDK is a set of software libraries that enable you to use client-side encryption in your database design, including record-level encryption of database items. Today, the AWS Database Encryption SDK supports Amazon DynamoDB with attribute-level encryption.
Because implementing encryption algorithms and HSMs is critical to get right, all vendors of HSMs should have their products validated by a trusted third party. HSMs in both AWS KMS and AWS CloudHSM are validated under the National Institute of Standards and Technology’s FIPS 140 program, the standard for evaluating cryptographic modules. This validates the secure design and implementation of cryptographic modules, including functions related to ports and interfaces, authentication mechanisms, physical security and tamper response, operational environments, cryptographic key management, and electromagnetic interference/electromagnetic compatibility (EMI/EMC). Encryption using a FIPS 140 level 3 validated cryptographic module is often a requirement for other security-related compliance schemes like FedRamp and HIPAA-HITECH in the U.S., or the international payment card industry standard (PCI-DSS).
Independent key management
While AWS KMS and AWS CloudHSM can protect plaintext master keys on your behalf, you are still responsible for managing access controls to determine who can cause which encryption keys to be used under which conditions. One advantage of using AWS KMS is that the policy language you use to define access controls on keys is the same one you use to define access to all other AWS resources. Note that the language is the same, not the actual authorization controls. You need a mechanism for managing access to keys that is different from the one you use for managing access to your data. AWS KMS provides that mechanism by allowing you to assign one set of administrators who can only manage keys and a different set of administrators who can only manage access to the underlying encrypted data. Configuring your key management process in this way helps provide separation of duties you need to avoid accidentally escalating privilege to decrypt data to unauthorized users. For even further separation of control, AWS CloudHSM offers an independent policy mechanism to define access to keys.
In 2022, AWS KMS launched support for external key stores (XKS), a feature that allows you to store AWS KMS customer managed keys on an HSM that you operate on premises or at a location of your choice. At a high level, AWS KMS forwards requests for encryption and decryption to your HSM. Your key material never leaves your HSM. This can help you unblock use cases for a small portion of highly regulated workloads where encryption keys should be stored and used outside of an AWS data center. However, XKS forces a significant shift in the shared responsibility model—you now have responsibility for the durability, throughput, latency, and availability of your KMS key. If that key is lost or destroyed, you could permanently lose access to data, and if an XKS key becomes unavailable, all workloads in AWS that are dependent on that XKS key will be inaccessible.
Even with the ability to separate key management from data management, you can still verify that you have configured access to encryption keys correctly. AWS KMS is integrated with AWS CloudTrail so you can audit who used which keys, for which resources, and when. This provides granular vision into your encryption management processes, which is typically much more in-depth than on-premises audit mechanisms. Audit events from AWS CloudHSM can be sent to Amazon CloudWatch, the AWS service for monitoring and alarming third-party solutions you operate in AWS.
Encrypting data at rest and in transit
AWS services that handle customer data, encrypt data that is sent from one system to another—known as data in transit—provide options to encrypt data at rest. AWS services that offer encryption at rest using AWS KMS or AWS CloudHSM use AES-256. None of these services store plaintext encryption keys at rest—that’s a function that only AWS KMS and AWS CloudHSM may perform using their FIPS 140 level 3 validated HSMs. This architecture helps minimize the unauthorized use of keys.
When encrypting data in transit, AWS services use the Transport Layer Security (TLS) protocol to provide encryption between your application and the AWS service. Most commercial solutions use an open source project called OpenSSL for their TLS needs. OpenSSL has roughly 500,000 lines of code with at least 70,000 of those implementing TLS. The code base is large, complex, and difficult to audit. Moreover, when OpenSSL has bugs, the global developer community is challenged to not only fix and test the changes, but also to make sure that the resulting fixes themselves do not introduce new flaws.
AWS’s response to challenges with the TLS implementation in OpenSSL was to develop our own implementation of TLS, known as s2n, or signal to noise. We released s2n in June 2015, which we designed to be small and fast. The goal of s2n is to provide you with network encryption that is easier to understand and that is fully auditable. We released and licensed it under the Apache 2.0 license and hosted it on GitHub.
We also designed s2n to be analyzed using automated reasoning to test for safety and correctness using mathematical logic. Through this process, known as formal methods, we verify the correctness of the s2n code base every time we change the code. We also automated these mathematical proofs, which we regularly re-run to ensure the desired security properties are unchanged with new releases of the code. Automated mathematical proofs of correctness are an emerging trend in the security industry, and AWS uses this approach for a wide variety of our mission-critical software.
Similarly, in 2022, we released s2n-quic, an open-source Rust implementation of the QUIC protocol that was added to our set of AWS encryption open source libraries. QUIC is an encrypted transport protocol designed for performance and is the foundation of HTTP/3. It is specified in a set of IETF standards that were ratified in May 2021. Amazon CloudFront HTTP/3 support is built on top of s2n-quic, due to its emphasis on performance and efficiency. You can learn more about s2n-quic in this Security Blog post.
Implementing TLS requires using encryption keys and digital certificates that assert the ownership of those keys. AWS Certificate Manager and AWS Private Certificate Authority are two services that can simplify the issuance and rotation of digital certificates across your infrastructure that needs to offer TLS endpoints. Both services use a combination of AWS KMS and AWS CloudHSM to generate and/or protect the keys used in the digital certificates they issue.
Encrypting data in use
You might also have use cases for protecting data that is actively being used by federated learning models or other applications. Cryptographic computing—a set of technologies that allow computations to be performed on encrypted data, so that sensitive data is not exposed—is a methodology for protecting data in use.
Consider the example of an insurance company that works with other companies to develop machine learning models for insurance fraud detection. You might need to use sensitive data about your customers as training data for your models, but you don’t want to share your customer data in plaintext form with the other companies. Cryptographic computing gives organizations a way to train models collaboratively without exposing plaintext data about their customers to each other, or to a cloud provider like AWS. You can read more about cryptographic computing in this AWS Security Blog post.
Today, you can see cryptographic computing at work in AWS Clean Rooms, a service that helps companies and their partners more easily and securely analyze and collaborate on their collective datasets—all without sharing or copying one another’s underlying data. AWS Clean Rooms has a feature called Cryptographic Computing for AWS Clean Rooms (C3R) that cryptographically protects your data even while it is being processed by an AWS Clean Rooms collaboration.
The role of end-to-end encryption in secure communications
End-to-end encryption (E2EE) is a method of secure communication between two or more parties that combines encryption in transit and encryption at rest to protect data from unauthorized access, interception, or tampering. Decryption happens only on the parties you intend to communicate with, and no service providers in between. Every call, message, and file is encrypted with a unique private key and remains protected in transit. Unauthorized parties can’t access communication content, because they don’t have the private key required to decrypt the data.
AWS Wickr is an end-to-end encrypted messaging and collaboration service that protects one-to-one and group messaging, voice and video calling, file sharing, screen sharing, and location sharing with 256-bit encryption. With Wickr, each message gets a unique AES private encryption key and a unique Elliptic-curve Diffie–Hellman (ECDH) public key to negotiate the key exchange with recipients. Message content—including text, files, audio, or video—is encrypted on the sending device (your iPhone, for example) by using the message-specific AES key. This key is then exchanged by using the ECDH key exchange mechanism, so that only intended recipients can decrypt the message.
Quantum computing and post-quantum cryptography
Quantum computing is a field of technology that uses quantum mechanics to solve complex problems faster than on classical computers. Quantum computers are able to solve certain types of problems faster by taking advantage of quantum mechanical effects, such as superposition and quantum interference. For cryptography, this has implications that affect traditional encryption mechanisms such as asymmetric key encryption, which is often used for protecting data in transit (TLS) or creating hash-based signatures to verify the integrity and authenticity of a message or file. Quantum computers, if they are performant and stable enough, could theoretically compromise the security of asymmetric key algorithms like RSA, Elliptic Curve Cryptography (ECC), or Diffie-Hellman key agreement schemes. Based on current research, symmetric key algorithms like AES are not considered to be at risk from a quantum computer, because the key length of 256 bits is already sufficient to compensate for a decrease in cryptographic key strength posed by quantum algorithms.
AWS gives customers the option of evaluating post-quantum algorithms alongside traditional algorithms, using hybrid schemes that make use of both classic cryptography and newer post-quantum cryptographic (PQC) algorithms that are designed to be resistant to quantum computer threats. AWS has taken the first step in deploying PQC by implementing ML-KEM, a module lattice-based key encapsulation mechanism, within AWS-LC, our open source FIPS-140-3 validated cryptographic library. AWS-LC is the core cryptographic library used throughout AWS. Specifically, AWS-LC is used in s2n-tls, our open source TLS implementation used across AWS services with HTTPS-based endpoints.
AWS provides customers the ability to encrypt everything, everywhere. Customers can encrypt data at rest, in transit, and in memory, with a few clicks in the AWS Management Console, or an AWS API call. Services like Amazon Simple Storage Service (Amazon S3) encrypt new objects by default, and also support the use of customer managed AWS KMS keys to give customers more control over their encryption keys. Importantly, AWS KMS uses techniques like envelope encryption and highly scalable key management infrastructure to enable AWS services like Amazon S3 or Amazon Elastic Block Store (Amazon EBS) to encrypt data with minimal performance impact to customer applications.
AWS is also consistently working to improve the performance and security of our customers’ data as it moves between networks or devices. As of June 2024, all AWS API endpoints support TLS 1.3 and require at least TLS 1.2 or higher. By using TLS 1.3, you can decrease your connection time by removing one network round trip for every connection request, and can benefit from some of the most modern and secure cryptographic cipher suites available today.
Customers who require memory encryption can use AWS Graviton, our custom-built family of processors based on ARM. AWS Graviton2, AWS Graviton3, and AWS Graviton3E support always-on memory encryption. The encryption keys are securely generated within the host system, do not leave the host system, and are destroyed when the host is rebooted or powered down. Memory encryption is also supported for other instance types; see the EC2 documentation for more details.
As part of our AWS Digital Sovereignty Pledge, we commit to continue to innovate and invest in additional controls for encryption features so that our customers can encrypt everything, everywhere with encryption keys managed inside or outside the AWS Cloud.
Summary
At AWS, security is our top priority. We are committed to helping you control how your data is used, who has access to it, and how it is protected. By building and supporting encryption tools that work both on and off the cloud, we help you secure your data and enable compliance across your environment. We put security at the center of everything we do to make sure that you can protect your data using best-of-breed security technology in a cost-effective way.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS KMS forum or the AWS CloudHSM forum, or contact AWS Support.
Serverless queue processors like AWS Lambda often exist in architectures where they pull messages from queues such as Amazon Simple Queue Service (Amazon SQS) and interact with downstream services or external APIs in a distributed architecture. Robust retry approaches are necessary to provide reliable message processing due to the susceptibility of these downstream services to short-term outages or throttling. This often requires implementing special retry logic with features like dead-letter queues (DLQs) and exponential backoff to handle these cases gracefully, making sure that the downstream systems don’t get overwhelmed by too many retries.
In this post, we propose a solution that handles serverless retries when the workflow’s state isn’t managed by an additional service.
Solution overview
Some custom retry logic is required when Lambda functions interact with downstream services after consuming messages from SQS queues. This strategy involves the usage of Amazon EventBridge Scheduler and code in Lambda. The core concept is to implement a robust retry mechanism for handling failed message processing attempts using an EventBridge scheduler. When a Lambda function encounters a problem while processing a message, it triggers a specific error. Upon catching this error in a catch block, the function generates an EventBridge schedule. As a result, the message is sent back to the SQS queue and will be available for processing again at a specified future time.
In this approach, the retry mechanism can have a fine-grained level of control over the retry timing that might also support various techniques, including exponential backoff and linear retry intervals. This approach separates the retry logic from the code to process the message itself, making the Lambda function performant. Along with handling messages when all retries are exhausted, this solution interfaces with a DLQ to keep such messages separate from the main queue.
The following diagram illustrates the solution architecture.
The error handling and retry choice logic in the Lambda function code form the basis for how this custom retry mechanism is implemented. If there is an error while processing the message, the function raises a specific exception. Raising the exception then initiates the retry flow. A try-catch block catches this exception and calls a function that interfaces with the EventBridge Scheduler API to build a custom schedule. To configure the schedule, we include the destination SQS queue and the intended timestamp when the message is meant to be retried. We can change the delay with some code modifications depending on a number of parameters, such as error type, number of prior retries, or other custom backoff schemes.
As part of this approach, we use SQS message attributes for idempotency and to track retries. On each retry, the function adds the new timestamp to an array in the message body. If the function consumes the message more times than the maximum retry limit (determined by the array of retry attempts) it sends the message to the DLQ without rescheduling.
The solution also involves the integration of a DLQ so that it doesn’t keep messages in the main processing queue and be retried forever. The Lambda function will register messages with the DLQ in case of either exceeding the maximum retry limit or when certain error scenarios require it to stop early. This queue keeps all communications that have failed until such a time they can be manually reviewed, reprocessed, or even corrected.
Considerations and best practices
There are a few key factors to keep in mind while putting this custom retry system into practice. One aspect is handling partial failures, that is, processing where only part of the steps are complete. In such cases, we could use some form of compensating action or rollback to maintain consistency in data and avoid discrepancies downstream of the queue consumer.
Another crucial factor is controlling retry limits. Although the system design allows for variable retry limits, we must balance resource usage and resilience. Too many retries might cause higher costs and lead to slowdowns or service degradation. That is why we recommend that appropriate retry limits are set, considering probable failure rates, SLAs, and business consequences of failures.
We must also consider that EventBridge Scheduler has a granularity of 1 minute, and there is additional latency between the queue and the function, so the mechanism will not be completely precise. In principle, the scheduler sets the minimum time before which the message can be processed, making sure the Lambda function adheres to the rate limits at a minimum. This could also result in additional delays, so the mechanism would need to be adjusted for time-sensitive applications to account for these delays.
Because the solution might deal with variable volumes of messages and processing loads, scaling issues are also important. For example, the Lambda concurrency and retention period for the queue represent resource configurations we should monitor and adjust for optimal performance and cost.
Finally, we need to consider security as part of the solution. If the downstream service runs in a virtual private cloud (VPC), we would also need to place the Lambda function in the VPC. In this case, we would need to access EventBridge Scheduler through AWS PrivateLink, which enables secure and performant access to services from within a VPC.
Additionally, it is important to implement the AWS Identity and Access Management (IAM) roles (mainly the Lambda function role) with the principal of least privilege, which gives it access to create the EventBridge schedule (and iam:PassRole to give the scheduler the required permissions) as well as pass the scheduler’s IAM role to it. The scheduler’s role only needs permission to place a message into the source queue. We also need to give the function access to place a message in the DLQ and receive messages from the source queue.
Monitoring and troubleshooting
The custom retry mechanism demands efficient monitoring and debugging. With that in mind, we might view various behaviors of the system and identify potential problems by using Amazon CloudWatch logs and metrics.
The number of invocations of Lambda functions, related error rates, runtimes, and use of DLQ are the key indicators that we should monitor. It would be worth setting up alarms in CloudWatch to send an alert or initiate automated actions when the Lambda function’s metrics surpass certain predetermined thresholds. By doing this, we proactively detect and resolve certain issues pertaining to the function.
Also, we can examine logs of the Lambda function for certain error situations, retry patterns, or problems with the downstream services or with the retry logic itself. We can place logging lines judiciously in the function code to record pertinent information, including message attributes, retry attempts, and error details.
Future enhancements
There are some improvements we could consider to enhance the capabilities and flexibility of the suggested approach even further, which provides a foundation to customize retry mechanisms.
A possible improvement would be to introduce dynamic retry intervals depending on the conditions of a downstream service or kinds of errors. Instead of being based on predefined backoff schemes, the system might dynamically adjust the retry intervals based on specific error types detected or in-service health monitoring in real time. This concept’s principal disadvantage is additional complexity, which might cause the failure of the retry process itself.
Another potential enhancement is the integration of the system with external configuration services such as Amazon DynamoDB or Parameter Store, a capability of AWS Systems Manager. That way, we can handle the retry configurations centrally and dynamically to provide ease of maintenance and modification in retry strategies without having to redeploy the Lambda function code.
It would also be possible to build in advanced error analysis and reporting into the system. The system would then have the potential to provide key insights for root cause analysis and proactive remediation through comprehensive reporting, patterns of errors analyzed, and failures correlated with downstream service health.
Conclusion
It is often challenging to build scalable, robust serverless applications that might need to talk with external services. However, the proposed solution using Lambda, Amazon SQS, and EventBridge Scheduler brings a simple yet effective solution to implement customized retry mechanisms. It gives the developer fine-grained control over the retry interval, supports scenarios such as exponential backoff, and works seamlessly with DLQs for persisting failures and EventBridge Scheduler for delayed retries of messages. The mechanism can also be reused more broadly for stateless queue consumers, not only for Lambda functions. This pattern enables developers to implement robust, fault-tolerant serverless systems that handle disruptions in downstream services gracefully.
The Finnish Transport and Communications Agency (Traficom) Cyber Security Centre published PiTuKri, which consists of 52 criteria that provide guidance across 11 domains for assessing the security of cloud service providers.
An independent third-party audit firm issued the report to assure customers that the AWS control environment is appropriately designed and operating effectively to demonstrate adherence with PiTuKri requirements. This attestation demonstrates the AWS commitment to adhere to security expectations for cloud service providers set by Traficom.
The latest report covers a 12-month period from October 1, 2023 to September 30, 2024. AWS has added the following 10 services to the current PiTuKri scope:
AWS strives to continuously bring new services into the scope of its compliance programs to help you meet your architectural and regulatory needs. Contact your AWS account team for questions about the PiTuKri report.
To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.
If you have feedback about this post, submit comments in the Comments section below.
The Swiss Financial Market Supervisory Authority (FINMA) has published several requirements and guidelines about engaging with outsourced services for the regulated financial services customers in Switzerland.
An independent third-party audit firm issued the report to assure customers that the AWS control environment is appropriately designed and operating effectively to support adherence with FINMA requirements.
The latest report covers the 12-month period from October 1, 2023 to September 30, 2024, for the following circulars:
2018/03 “Outsourcing – banks, insurance companies and selected financial institutions under FinIA”
2023/01 “Operational risks and resilience – banks”
Business Continuity Management (BCM) minimum standards proposed by the Swiss Insurance Association
AWS has added the following 10 services to the current FINMA scope:
AWS strives to continuously bring new services into the scope of its compliance programs to help you meet your architectural and regulatory needs. Contact your AWS account team for questions about the FINMA report.
To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.
If you have feedback about this post, submit comments in the Comments section below.
Amazon Web Services (AWS) is pleased to announce the renewal of the Multi-Tier Cloud Security (MTCS) Level 3 certification under the SS584:2020 standard in December 2024 for the Asia Pacific (Singapore), Asia Pacific (Seoul), and United States AWS Regions, excluding AWS GovCloud (US) Regions. This achievement reaffirms our commitment to maintaining the highest security standards for our global customers, particularly those in Singapore and the Asia-Pacific.
AWS was the first cloud service provider (CSP) to attain MTCS Level 3 certification for Singapore in 2014. We continued this leadership by being among the first CSPs certified under the updated SS584:2020 Level 3 standard in 2021. Our dedication to expanding our security coverage is evident in the significant increase of in-scope services from 145 to 184, representing a 27% growth since 2021.
The MTCS standard is recognized as the world’s first cloud security standard to specify a multi-tiered management system for cloud security. This standard can be applied by CSPs to support differing cloud user needs for data sensitivity and business criticality, and the use of MTCS is mandated by the Singapore government as a requirement for public sector agencies and regulated organizations.
As part of our commitment to transparency, AWS fulfills the self-disclosure requirement for CSPs, providing detailed service-oriented information typically found in service level agreements. This allows our customers to make informed decisions about their cloud security needs.
The MTCS framework establishes three levels of security, with Level 3 being the most stringent:
Level 1: Designed for non-business-critical data and systems with baseline security controls.
Level 2: Addresses the needs of organizations that run business-critical data and systems in public or third-party cloud systems.
Level 3: Tailored for regulated organizations with specific and more stringent security requirements, including industry-specific regulations.
Benefits of the MTCS Level 3 certification
By achieving MTCS Level 3 certification, AWS helps Singapore customers in regulated industries to securely host applications and systems with highly sensitive information. This includes confidential business data, financial records, and medical records in a Level-3-compliant MTCS environment.
As cloud technology continues to evolve, AWS remains dedicated to maintaining and exceeding the highest security standards. Our renewed MTCS Level 3 certification under the SS584:2020 standard is a testament to this commitment, enabling our customers in Singapore and around the world to use AWS services with confidence for their most sensitive and critical workloads.
To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.
If you have feedback about this post, submit comments in the Comments section below.
Today, we released an updated version of the Aligning to the NIST Cybersecurity Framework (CSF) in the AWS Cloud whitepaper to reflect the significant changes introduced in the National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) 2.0, published in February 2024. This comprehensive update helps you understand how AWS services align with the enhanced framework and how you can use AWS capabilities to improve your cybersecurity posture.
The NIST CSF 2.0 provides guidance to industry, government agencies, and other organizations to manage cybersecurity risks. The updated version introduces important changes, including the following:
A new “Govern” Core Function, emphasizing procedural and organizational activities that have an impact on the management of cybersecurity risk within organizations.
An expanded scope, beyond critical infrastructure, to help organizations of many sizes and sectors.
Enhanced guidance for privacy risk management and supply chain security.
Updated Categories and Subcategories that better reflect current cybersecurity challenges.
In accordance with the AWS Shared Responsibility Model, the whitepaper provides a detailed mapping of AWS services to the six CSF Core Functions: Govern (New), Identify, Protect, Detect, Respond, and Recover. Organizations can use this whitepaper to understand how AWS services align with NIST CSF 2.0 requirements, implement AWS solutions to help achieve their security objectives, use AWS capabilities for automated security operations, and build resilient architectures that support their cybersecurity strategies.
Security and compliance remain our top priorities at AWS. This updated whitepaper demonstrates our commitment to helping customers align with the latest security frameworks while protecting their data and resources in the AWS Cloud. The whitepaper also includes practical guidance for implementing AWS services and features that support the CSF outcomes, whether you’re just starting your cloud journey or looking to enhance your existing security posture.
To learn more about implementing NIST CSF 2.0 in your organization by using AWS services, contact your AWS account team or download the whitepaper.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
In the piece, we spotlight the AWS Security Guardians program and how it helps security enable your business, not slow it down. Through the program, teams are provided tools, resources, and guidance to help address security concerns at every step of development. This enables developers to make the right decisions and embed security deeper in their solutions. Using our approach with their Security Champions initiative, the Commonwealth Bank of Australia shared how the program has helped transform their company culture and give ownership of services and security directly to their teams.
AWS and the Commonwealth Bank sought to understand how they could foster a culture where employees not only understand security, but care about it. They both needed a way to support new technology innovation while reducing security remediation work. This challenge offered both companies an opportunity to try something new with their Security Champions programs, enabling security expertise to be distributed across their respective organizations, which created a scalable solution with measurable results.
Read the full article on the BBC website to discover how AWS and our customers are creating a better environment for our teams, colleagues, customers, and communities.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
Amazon Web Services (AWS) is pleased to announce a successful completion of the 2024 Cloud Computing Compliance Controls Catalogue (C5) attestation cycle with 179 services in scope. This alignment with C5 requirements demonstrates our ongoing commitment to adhere to the heightened expectations for cloud service providers. AWS customers in Germany and across Europe can run their applications in the AWS Regions that are in scope of the C5 report with the assurance that AWS aligns with C5 criteria.
The C5 attestation scheme is backed by the German government and was introduced by the Federal Office for Information Security (BSI) in 2016. AWS has adhered to the C5 requirements since their inception. C5 helps organizations demonstrate operational security against common cybersecurity threats when using cloud services.
Independent third-party auditors evaluated AWS for the period of October 1, 2023, through September 30, 2024. The C5 report illustrates the compliance status of AWS for both the basic and additional criteria of C5. Customers can download the C5 report through AWS Artifact, a self-service portal for on-demand access to AWS compliance reports. Sign in to AWS Artifact in the AWS Management Console, or learn more at Getting Started with AWS Artifact.
AWS has added the following 10 services to the current C5 scope:
The following AWS Regions are in scope of the 2024 C5 attestation: Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Milan), Europe (Paris), Europe (Stockholm), Europe (Spain), Europe (Zurich), and Asia Pacific (Singapore). For up-to-date information, see the C5 page of our AWS Services in Scope by Compliance Program.
AWS strives to continuously bring services into the scope of its compliance programs to help you meet your architectural and regulatory needs. If you have questions or feedback about C5 compliance, reach out to your AWS account team.
To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.
If you have feedback about this post, submit comments in the Comments section below.
The Spanish National Cryptologic Center (CCN) has published a new STIC guide (CCN-STIC-887 Anexo A) that provides a comprehensive template and supporting artifacts for implementing landing zones that comply with Spain’s National Security Framework (ENS) Royal Decree 311/2022 using the Landing Zone Accelerator on AWS. Spain’s ENS establishes a common framework of basic principles and requirements of security for Spanish public sector organizations and their service providers, including supply chain providers. Over the years, the collaboration between Amazon Web Services (AWS) and the CCN has resulted in the publication of eight secure configuration guides (Series STIC 887) that provide comprehensive advice on the configuration of AWS services to align with the ENS. The guide CCN-STIC-887 Anexo A is the last addition to this series.
The centerpiece of this new guide is the ENS template for the Landing Zone Accelerator on AWS (LZA ENS). A landing zone serves as the initial setup of an organization’s cloud account or environment, including the implementation of security controls, access management, and compliance frameworks. The Landing Zone Accelerator on AWS is a powerful open source tool created by AWS for organizations that want to quickly customize and automate implementation of landing zones that align with AWS best practices and with regulatory compliance frameworks. This tool provides a comprehensive solution that, managed entirely by code, automatically configures over 35 AWS services using a simplified set of configuration files to manage and govern a multi-account environment, helping customers with highly regulated workloads and complex compliance requirements.
The CCN-STIC-887 Anexo A guide focuses on helping organizations implement landing zones that meet ENS security requirements from the ground up. It offers detailed instructions and templates for establishing a landing zone—the foundational infrastructure required for a secure, well-managed cloud environment—and a control matrix to demonstrate compliance with ENS controls.
Key components covered in the STIC 887H guide include:
Logging and monitoring: LZA ENS performs a default and scaled activation of the necessary logging and monitoring services required to meet ENS monitoring requirements in AWS services (such as AWS CloudTrail, Amazon CloudWatch, AWS Security Hub, and Amazon GuardDuty).
Access control: LZA ENS implements the management of identity and access management methods and policies at scale, which are aligned with the access control requirements of the ENS in a centralized manner using AWS IAM Identity Center.
Asset management: By default, LZA ENS activates inventory functions and resource and inventory tagging policies (for example, AWS Config) that support ENS asset management controls in the services.
Network topology: LZA ENS can be used to deploy a centralized network topology in accordance with ENS network security controls.
Cryptography: The encryption service activation capabilities built into LZA ENS can help organizations align with ENS data protection standards through mandatory encryption at rest, enforcement mechanisms with AWS Key Management Service (AWS KMS), and monitoring mechanisms to detect unencrypted data and communications with AWS Config rules.
Compliance and data residency: LZA ENS includes control policies to promote the use of AWS services with the ENS High certification and to provide processing on AWS in accordance with customers’ data residency requirements.
Organizations that require specific customizations to fully meet the requirements of the ENS can use LZA ENS to quickly modify and add customized security controls and then execute the scaled deployment of these controls to their accounts in the landing zone. One of the customizations included in LZA ENS is the integration of the open source security tool Prowler with Security Hub as an automated auditing tool with the objective of providing an up-to-date view of compliance with ENS controls. In addition, by providing a base designed for security and the flexibility to add custom controls, LZA ENS can support the process of achieving and maintaining compliance with the ENS in the AWS Cloud environment.
The CCN-STIC-887 Anexo A guide represents an important step forward in standardizing secure cloud deployments for Spanish public sector organizations and those working with government entities. This publication demonstrates the AWS commitment to support organizations in their secure cloud adoption journey while maintaining compliance with national security standards.
Spanish version
CCN publica la guía para las Zonas de Aterrizaje del ENS con AWS Landing Zone Accelerator
El Centro Criptológico Nacional de España (CCN) ha publicado una nueva guía STIC (CCN-STIC-887 Anexo A) que proporciona una plantilla de código y material de soporte para implementar zonas de aterrizaje (o landing zones) que cumplan con el Esquema Nacional de Seguridad del Real Decreto 311/2022 (ENS) mediante el Landing Zone Accelerator on AWS. El ENS establece un marco común de principios básicos, requisitos y medidas de seguridad para las organizaciones del sector público español y sus prestadores de servicios, incluyendo la cadena de suministro. A lo largo de los años, la colaboración entre Amazon Web Services (AWS) y el CCN se ha traducido en la publicación de ocho guías de configuración segura (serie STIC 887) que proporcionan consejo sobre la configuración de los servicios de AWS para alinearse con el ENS. La guía CCN-STIC-887 Anexo A es la última incorporación a esta serie.
La pieza central de la nueva guía es la plantilla ENS para el AWS Landing Zone Accelerator (LZA ENS). Una zona de aterrizaje (landing zone) sirve como la configuración inicial del entorno en la nube de una organización, e incluye la implementación inicial de controles de seguridad, la administración del acceso y los marcos de cumplimiento. El AWS Landing Zone Accelerator es una potente herramienta de código abierto creada por AWS para las organizaciones que desean implementar de forma rápida, segura, personalizada y automatizada zonas de aterrizaje alineadas con las prácticas recomendadas de AWS, así como con marcos de conformidad. Esta herramienta proporciona una solución integral que, mediante código, configura automáticamente más de 35 servicios de AWS con un conjunto simplificado de archivos de configuración para administrar y gobernar un entorno multicuenta, lo que ayuda a los clientes con cargas de trabajo altamente reguladas y requisitos de cumplimiento normativo.
La guía CCN-STIC-887 Anexo A se centra específicamente en ayudar a las organizaciones a implementar desde cero zonas de aterrizaje que cumplan con los requisitos de seguridad del ENS. Ofrece instrucciones y plantillas detalladas para establecer una zona de aterrizaje – la infraestructura básica necesaria para un entorno de nube seguro y bien administrado – así como una matriz de control para demostrar el cumplimiento de los controles del ENS.
Los componentes clave incluidos en la guía STIC 887H incluyen:
Registro y monitoreo: LZA ENS realiza una activación por defecto y a escala de los servicios de registro y monitoreo necesarios en AWS (como AWS CloudTrail, Amazon CloudWatch, AWS Security Hub, y AWS GuardDuty) para cumplir con los requisitos de monitoreo del ENS.
Control de acceso: LZA ENS implementa los métodos y políticas de administración de identidades y accesos a escala, que se alinean con los requisitos de control de acceso del ENS de manera centralizada mediante AWS IAM Identity Center..
Administración de activos: De forma predeterminada, el LZA ENS activa las funciones de inventario y las políticas de etiquetado de recursos e inventario (por ejemplo AWS Config) que soportan los controles de administración de activos del ENS.
Topología de red: LZA ENS se puede utilizar para implementar una topología de red centralizada de acuerdo con los controles de seguridad de red ENS.
Criptografía: las capacidades de activación de cifrado integradas en la LZA ayudan a organizaciones a alinearse con los estándares de protección de datos del ENS mediante el cifrado obligatorio en reposo, los mecanismos de aplicación con AWS Key Management Service (AWS KMS) y los mecanismos de supervisión para detectar datos y comunicaciones no cifrados con las reglas de AWS Config.
Cumplimiento y residencia de datos: LZA ENS incluye políticas de control para promover el uso de los servicios de AWS con la certificación del ENS Alto y realizar el procesamiento en AWS de acuerdo con los requisitos de residencia de datos del cliente.
Las organizaciones que requieren personalizaciones específicas para cumplir plenamente los requisitos del ENS pueden usar el LZA ENS para modificar rápidamente y añadir fácilmente controles de seguridad personalizados y ejecutar la implementación a escala de estos controles en sus cuentas de la zona de aterrizaje. Una de las personalizaciones que hemos incluido en el LZA ENS es la integración de Prowler con AWS Security Hub como una herramienta de auditoría automatizada, con el objetivo de proporcionar una visión actualizada del cumplimiento de los controles ENS de una manera fácil y eficaz. Además, al proporcionar una base diseñada para la seguridad y la flexibilidad de agregar controles personalizados, LZA ENS puede ayudar durante el proceso de obtener la conformidad con el ENS en el entorno de nube de AWS.
La guía CCN-STIC-887 Anexo A representa un importante paso adelante en la estandarización de las implementaciones seguras en la nube para las organizaciones del sector público español. Esta publicación demuestra el compromiso de AWS de apoyar a las organizaciones en su proceso de adopción segura de la nube, manteniendo al mismo tiempo el cumplimiento de las normas de seguridad nacionales.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
In Canada, the Canadian Centre for Cyber Security (CCCS) is the national technical authority for cybersecurity. CCCS publishes cybersecurity advice and guidance, including ITSG-33 Annex 3A, a catalog of security controls based on NIST Special Publication 800-53. When CCCS recently published new cloud security profiles based on NIST 800-53 Revision 5, we undertook a project to encode the relevant information in OSCAL. Expressing CCCS’s catalog and profile information in OSCAL facilitates automated analysis, including comparisons with OSCAL catalogs and profiles published by NIST and FedRAMP. This post explores the approach we took to express CCCS’s profiles in OSCAL, in addition to opportunities for future work.
OSCAL fundamentals
For the purposes of this discussion, there are two important OSCAL concepts to understand: catalogs and profiles. A catalog is a collection of security controls, such as NIST 800-53 or ITSG-33. An OSCAL catalog expresses control-specific information, including statements, parameters, and implementation guidance, in a structured and machine-readable format using either JSON, XML, or YAML.
OSCAL profiles import controls from catalogs (and other profiles) and express more specific implementation guidance. For example, the FedRAMP Moderate profile selects a subset of controls from NIST 800-53, specifies constraints for certain parameters, and provides assessment guidance. Profiles can also modify controls as they’re imported, which proved very useful for our purposes.
Expressing CCCS controls in OSCAL
Because CCCS’s ITSG-33 is based on NIST 800-53, most NIST controls can be used in CCCS profiles without modification. However, in some cases CCCS has modified the language of NIST 800-53 controls; for example, to replace mentions of a US agency or standard with a Canadian equivalent, or to add additional content specific to CCCS. Therefore, the first step in expressing CCCS requirements in OSCAL was to create a profile that makes the necessary control-level modifications. In some cases, CCCS has also created controls that are not part of NIST 800-53; these are specified in a separate catalog.
When an OSCAL profile is resolved, the information from the upstream catalogs and profiles that it’s importing controls from is assembled—along with modifications—and expressed as a catalog. By resolving the ITSG-33 modifications profile, we can programmatically generate the complete ITSG-33 catalog, incorporating NIST 800-53 controls, CCCS controls, and required modifications.
CCCS cloud security profiles
CCCS has created two profiles that are used to assess the security of cloud services: CCCS Medium and Protected B High Value Assets (PBHVA). Each of these profiles specifies a selection of controls from ITSG-33, in addition to the values for a number of parameters. Working backwards from the profiles published by CCCS as spreadsheets, we extracted the control and parameter information from each profile and expressed them in OSCAL. This exercise also informed the creation of the ITSG-33 modifications profile discussed previously, which captured control-level changes made by CCCS to NIST 800-53 controls, as well as the separate catalog of CCCS-specific controls.
Resources
In support of furthering this work within the Canadian security community, we’ve published the OSCAL files that we created as part of this project on GitHub, including:
CCCS-specific control catalog
ITSG-33 modifications profile and resolved catalog
CCCS Medium profile, resolved catalog, and CSV
PBVHA profile, resolved catalog, and CSV
We used an open-source tool, oscal-cli, to validate the structure of the OSCAL files that we created and to resolve the profiles into catalogs.
Future work
AWS is interested in further exploring the use of OSCAL to help us and our customers adhere to CCCS requirements as efficiently as possible. In the future, we want to explore how OSCAL data and tools can be used to support the efficient translation of the ITSG-33 catalog and CCCS profiles into French and the presentation of compliance information in accessible formats.
If you have feedback about this post, submit comments in the Comments section below.
The Agence du Numérique en Santé (ANS), the French governmental agency for health, introduced the HDS certification to strengthen the security and protection of personal health data. By achieving this certification, AWS demonstrates our continuous commitment to adhere to the heightened expectations for cloud service providers.
The following 24 Regions are in scope for this certification:
US East (Ohio)
US East (N. Virginia)
US West (N. California)
US West (Oregon)
Asia Pacific (Hong Kong)
Asia Pacific (Hyderabad)
Asia Pacific (Jakarta)
Asia Pacific (Mumbai)
Asia Pacific (Osaka)
Asia Pacific (Seoul)
Asia Pacific (Singapore)
Asia Pacific (Sydney)
Asia Pacific (Tokyo)
Canada (Central)
Europe (Frankfurt)
Europe (Ireland)
Europe (London)
Europe (Milan)
Europe (Paris)
Europe (Stockholm)
Europe (Zurich)
Israel (Tel Aviv)
Middle East (UAE)
South America (São Paulo)
The HDS certification demonstrates that AWS provides a framework for technical and governance measures to secure and protect personal health data according to HDS requirements. Our customers who handle personal health data can continue to manage their workloads in HDS-certified Regions with confidence.
AWS strives to continuously meet your architectural and regulatory needs. If you have questions or feedback about HDS compliance, reach out to your AWS account team.
To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.
If you have feedback about this post, submit comments in the Comments section below.
AWS re:Invent 2024 was held in Las Vegas December 2–6, with over 54,000 attendees participating in more than 2,300 sessions and hands-on labs. The conference was a hub of innovation and learning hosted by AWS for the global cloud computing community.
In this blog post, we cover on-demand sessions and major security, identity, and compliance announcements that were unveiled leading up to and during the conference. Whether you missed the event or want to revisit the key takeaways, we’ve compiled the essential information for you to provide a comprehensive overview of the latest developments in AWS security, identity, and compliance. This year’s event put best practices for zero trust, generative AI–driven security, identity, and access management, DevSecOps, network and infrastructure security, data protection, and threat detection and incident response at the forefront.
Key announcements
For identity and access management, we launched multiple new features that can help you scale permissions management across your AWS Organizations.
Resource control policies (RCPs) – RCPs are a new type of organization policy that can be used to centrally create and enforce preventative controls on AWS resources in your organization. Using RCPs, you can centrally set the maximum available permissions to your AWS resources as you scale your workloads on AWS.
Centrally manage root access – With central management for root access, you now have a capability to centrally manage your root credentials, simplify auditing of credentials, and perform tightly scoped privileged tasks across your AWS member accounts managed using AWS Organizations.
Declarative policies – Declarative policies simplify the way you enforce durable intent, such as baseline configurations for AWS services within your organization.
Feature tiers – Amazon Cognito launched two user pool feature tiers: Essentials and Plus. The Essentials tier offers comprehensive and flexible user authentication and access control features, helping you to implement secure, scalable, and customized sign-up and sign-in experiences. The Plus tier offers threat protection capabilities against suspicious sign-ins for customers who have elevated security needs for their applications.
Developer-focused console – Amazon Cognito now offers a streamlined getting-started experience featuring a quick wizard and use case–specific recommendations. This approach helps you set up configurations and reach your end users faster and more efficiently than ever before.
Managed Login – This feature is a fully managed, hosted sign-in and sign-up experience that you can personalize to align with your company or application branding. Managed Login helps you offload the undifferentiated heavy lifting of designing and maintaining custom implementations such as passwordless authentication and localization.
Passwordless authentication – With passwordless authentication, you can secure user access to your application with passkeys, email, and text messages. If your users choose to use passkeys to sign in, they can do so using a built-in authenticator, such as Touch ID on Apple MacBooks and Windows Hello facial recognition on PCs.
To discover security issues in your environment, Amazon GuardDuty launched Extended Threat Detection, a capability that you can use to identify sophisticated, multi-stage threats targeting your AWS accounts, workloads, and data. You can now use new threat sequence findings that cover multiple resources and data sources over an extensive time period, allowing you to spend less time on first-level analysis and more time responding to critical severity threats to minimize business impact.
Amazon OpenSearch Service now offers a zero-ETL integration with Amazon Security Lake, enabling you to query and analyze security data in-place directly through OpenSearch Service. This integration allows you to efficiently explore voluminous data sources that were previously cost-prohibitive to analyze, helping you streamline security investigations and obtain comprehensive visibility of your security landscape. With the flexibility to selectively ingest data and without the need to manage complex data pipelines, you can now focus on effective security operations while potentially lowering your analytics costs.
AWS Security Incident Response is a new service that helps you respond to security issues in your environment. This new service combines the power of automated monitoring and investigation, accelerated communication and coordination, and direct 24/7 access to the AWS Customer Incident Response Team to quickly prepare for, respond to, and recover from security events.
In the zero trust space, AWS Verified Access AWS Verified Accessand Amazon VPC Lattice both launched support for accessing non-HTTPS resources. Verified Access enables you to provide secure, VPN-less access to your corporate applications over protocols such as TCP, SSH, and RDP. With the launch of VPC Resources for Amazon VPC Lattice, you can now access your application dependencies through a VPC Lattice service network. You’re able to connect to your application dependencies that are hosted in different VPCs, accounts, and on-premises using additional protocols, including TLS, HTTP, HTTPS, and now TCP. Watch the on demand session to learn how you can enable zero trust access over non-HTTP(S) protocols by using AWS Verified Access.
Amazon Route 53 Resolver DNS Firewall launched an advanced firewall rule that has a new set of capabilities that you can use to monitor and block suspicious DNS traffic associated with advanced DNS threats.
Amazon Virtual Private Cloud launched block public access, which is a one-click declarative control that admins can implement centrally to authoritatively block internet traffic for each of their VPCs.
As more and more customers deploy generative AI workloads into production, it’s important to have proper security controls. Amazon Bedrock launched two new features to help with this:
Automated Reasoning checks – Automated Reasoning checks help detect hallucinations and provide a verifiable proof that a large language model response is accurate. With Automated Reasoning checks, domain experts can more straightforwardly build specifications called Automated Reasoning Policies that encapsulate their knowledge in fields such as operational workflows and HR policies. Users of Amazon Bedrock Guardrails can validate generated content against an Automated Reasoning Policy to identify inaccuracies and unstated assumptions, and explain why statements are accurate in a verifiable way.
Multimodal toxicity detection (Preview) – Amazon Bedrock Guardrails now supports multimodal toxicity detection for image content, enabling organizations to apply content filters to images. This capability, now in public preview, removes the heavy lifting required to build your own safeguards for image data or spend cycles with manual evaluation that can be error-prone and tedious.
AWS has continued to work closely with partners to help drive customer success. There were three new partner programs launched at AWS re:Invent:
AI Security category – The AI Security category in the AWS Security competency helps you identify AWS Partners with deep experience securing AI environments and defending AI workloads against advanced threats. Partners in this category are validated for their capabilities in areas such as prevention of sensitive data disclosure, prevention of injection threats, security posture management, and implementing responsible AI filtering.
AWS Security Incident Response Specialization – Today, AWS customers rely on various third-party tools and services to support their internal security incident response capabilities. To better help both customers and partners, AWS introduced AWS Security Incident Response, a new service that helps you prepare for, respond to, and recover from security events. Alongside approved AWS Partners, AWS Security Incident Response monitors, investigates, and escalates triaged security findings from Amazon GuardDuty and other threat detection tools through AWS Security Hub. Security Incident Response is designed to identify and escalate only high-priority incidents.
Amazon Security Lake Ready Specialization – This specialization recognizes AWS Partners who have technically validated their software solutions to integrate with Amazon Security Lake and demonstrated successful customer deployments. These solutions have been technically validated by AWS Partner Solutions Architects for their sound architecture and proven customer success.
Experience content on demand
If you were unable to join us in person or you want to watch a session again, you can view the sessions that are available on demand. Catch the CEO Keynote with Matt Garman to learn how AWS is reinventing foundational building blocks in addition to developing brand-new experiences, all to empower AWS customers and partners with what they need to build a better future. You can also replay additional re:Invent 2024 keynotes.
Watch the Security Innovation Talk, with AWS CISO Chris Betz, to hear how the latest AWS innovations are helping customers move fast and stay secure. Learn how AWS empowers organizations to confidently integrate and automate security into their products, services, and processes so security teams can focus their time on work that brings the highest value to the business. Chris also shares how AWS is helping to make the internet more secure by scaling security innovation and investing in the security community.
Stream any of the AWS security, identity, and compliance breakout sessions and new launch talks on demand to learn about the following key topics, and more:
Consider joining us for more in-person security learning opportunities by saving the date for AWS re:Inforce 2025, which will take place June 16–18 in Philadelphia, Pennsylvania. We look forward to seeing you there!
If you want to discuss how these new announcements can help your organization improve its security posture, AWS is here to help. Contact your AWS account team today.
We continue to expand the scope of our assurance programs at Amazon Web Services (AWS) and are pleased to announce the successful completion of our first ever Protected B High Value Assets (PBHVA) assessment with 149 assessed services and features. Completion of this assessment effective October 4, 2024, makes AWS the first cloud service provider (CSP) in Canada to meet this high security bar and provide assurance to our valued customers. This assessment also re-affirms our commitment to helping public and commercial customers achieve and maintain the highest-grade security standard for workloads with increased sensitivity.
What is the PBHVA assessment and why is it important?
The Protected B High Value Asset (PBHVA) overlay seeks to enhance the integrity and availability of customer organizational workloads that are considered to have an increased level of sensitivity. These are systems that the Government of Canada (GC) and its service providers use to support delivery of services at a national scale or that are determined to be significant for handling sensitive information. The overlay is a set of 117 controls from the ITSG-33 security control catalogue (baselined against NIST 800-53), which augments the security safeguards to enhance integrity and availability.
As of October 4, 2024, there are a total of 149 AWS services and features that were assessed by the Canadian Centre for Cyber Security (CCCS) under PBHVA assessment criteria. The assessment covers services and features that are available in both the Canada (Central) and Canada West (Calgary) AWS Regions.
How can you access the assessment?
The summary assessment is available through AWS Artifact. You can also learn more about the PBHVA assessment on our AWS PBHVA webpage.
AWS strives to continuously bring services into scope of its compliance programs to help you meet your architectural and regulatory needs. Please reach out to your AWS account team if you have questions or feedback about the PBHVA assessment.
To learn more about our compliance and security programs, see AWS Compliance Programs. As always, we value your feedback and questions; reach out to the AWS Compliance team through the Contact Us page.
If you have feedback about this post, submit comments in the Comments section below.
If you have feedback about this post, submit comments in the Comments section below.
The collective thoughts of the interwebz
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
