Tag Archives: AWS Artifact

AWS and the New Zealand notifiable privacy breach scheme

Post Syndicated from Adam Star original https://aws.amazon.com/blogs/security/aws-and-the-new-zealand-notifiable-privacy-breach-scheme/

The updated New Zealand Privacy Act 2020 (Privacy Act) will come into force on December 1, 2020. Importantly, it establishes a new notifiable privacy breach scheme (NZ scheme). The NZ scheme gives affected individuals the opportunity to take steps to protect their personal information following a privacy breach that has caused, or is likely to cause, serious harm. It also reinforces entities’ accountability for the personal information they hold.

We’re happy to announce that Amazon Web Services (AWS) now offers two types of New Zealand Notifiable Data Breach (NZNDB) addenda to customers who are subject to the Privacy Act and are using AWS to store and process personal information covered by the NZ scheme. The NZNDB addenda address customers’ need for notification if a security event affects their data.

We’ve made both types of NZNDB addenda available online as click-through agreements in AWS Artifact, which is our customer-facing audit and compliance portal that can be accessed from the AWS Management Console. In AWS Artifact, you can review and activate the relevant NZNDB addendum for those AWS accounts you use to store and process personal information covered by the NZ scheme.

The first type, the Account NZNDB Addendum, applies only to the specific individual account that accepts the Account NZNDB Addendum. The Account NZNDB Addendum must be separately accepted for each AWS account that you need to cover.

The second type, the AWS Organizations ANDB Addendum, once accepted by a management account in AWS Organizations, applies to the management account and all member accounts in that organization. If you don’t need or want to take advantage of the AWS Organizations ANDB Addendum, you can still accept the Account ANDB Addendum for individual accounts.

As with all AWS Artifact features, there is no additional cost to use AWS Artifact to review, accept, and manage either the individual Account NZNDB Addendum or AWS Organizations NZNDB Addendum. To learn more about AWS Artifact, including how to view, download, and accept the NZNDB addenda, visit the AWS Artifact FAQ page.

We welcome the arrival of the NZ scheme, and hope it helps New Zealand entities to improve their security capabilities.

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

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Author

Adam Star

Adam joined Amazon in 2012 and is a Program Manager on the Security Obligations and Contracts team. He enjoys designing practical solutions to help customers meet a range of global compliance requirements including GDPR, HIPAA, and the European Banking Authority’s Guidelines on Outsourcing Arrangements. Adam lives in Seattle with his wife and daughter. Originally from New York, he’s constantly searching for “real” bagels and pizza. He’s an active member of the Washington State Bar Association and American Homebrewers Association, finding the latter much more successful when attempting to make friends in social situations.

120 AWS services achieve HITRUST certification

Post Syndicated from Hadis Ali original https://aws.amazon.com/blogs/security/120-aws-services-achieve-hitrust-certification/

We’re excited to announce that 120 Amazon Web Services (AWS) services are certified for the HITRUST Common Security Framework (CSF) for the 2020 cycle.

The full list of AWS services that were audited by a third-party assessor and certified under HITRUST CSF is available on our Services in Scope by Compliance Program page. You can view and download our HITRUST CSF certification from AWS Artifact.

AWS HITRUST CSF certification is available for customer inheritance

You don’t have to assess the inherited controls, because AWS already has! You can deploy environments onto AWS and inherit our HITRUST CSF certification provided that you use only in-scope services and apply the controls detailed on the HITRUST website that you are responsible for implementing.

The HITRUST certification allows you, as an AWS customer, to tailor your security control baselines to a variety of factors including, but not limited to, regulatory requirements and organization type. The HITRUST CSF is widely adopted by leading organizations in a variety of industries in their approach to security and privacy. Visit the HITRUST website for more information.

As always, we value your feedback and questions and are committed to helping you achieve and maintain the highest standard of security and compliance. Feel free to contact the team through AWS Compliance Contact Us. If you have feedback about this post, submit comments in the Comments section below.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Author

Hadis Ali

Hadis is a Security and Privacy Manager at Amazon Web Services. He leads multiple security and privacy initiatives within AWS Security Assurance. Hadis holds Bachelor’s degrees in Accounting and Information Systems from the University of Washington.

Cyber hygiene and MAS Notice 655

Post Syndicated from Darran Boyd original https://aws.amazon.com/blogs/security/cyber-hygiene-and-mas-notice-655/

In this post, I will provide guidance and resources that will help you align to the expectations of the Monetary Authority of Singapore (MAS) Notice 655 – Notice on Cyber Hygiene.

The Monetary Authority of Singapore (MAS) issued Notice 655 – Notice on Cyber Hygiene on 6 Aug 2019. This notice is applicable to all banks in Singapore and takes effect from 6 Aug 2020. The notice sets out the requirements on cyber hygiene for banks across the following six categories: administrative accounts, security patches, security standards, network perimeter defense, malware protection, and multi-factor authentication.

Whilst Notice 655 is specific to all banks in Singapore, the AWS security guidance I provide in this post is based on consistent best practices. As always, it’s important to note that security and compliance is a shared responsibility between AWS and you as our customer. AWS is responsible for the security of the cloud, but you are responsible for your security in the cloud.

To aid in your alignment to Notice 655, AWS has developed a MAS Notice 655 – Cyber Hygiene – Workbook, which is available in AWS Artifact. The workbook covers each of the six categories of cyber hygiene in Notice 655 and maps to the following:

The downloadable workbook contains two embedded formats:

  • Microsoft Excel – coverage includes AWS responsibility control statements, and Well-Architected Framework best practices.
  • Dynamic HTML – same as Microsoft Excel, with the added feature that the Well-Architected Framework best practices are mapped to AWS Config managed rules and Amazon GuardDuty findings, where available or applicable.

Administrative accounts

“4.1. A relevant entity must ensure that every administrative account in respect of any operating system, database, application, security appliance or network device, is secured to prevent any unauthorised access to or use of such account.”

For administrative accounts, it is important to follow best practices for the privileged accounts, keeping in mind both human and programmatic access.

The most privileged user account in an AWS account is the root user. When you first create an AWS account (unless you create it with AWS Organizations), this is the initial user account created. The root user is associated with the provided email address and password used to create the account. The root user account has access to every resource in the account—including the ability to close it. To align to the principle of least privilege, the root user account should not be used for everyday tasks. Instead, AWS Identity and Access Management (IAM) roles should be created and scoped to particular roles and functions within your organization. Furthermore, AWS strongly recommends that you integrate with a centralized identity provider, or a directory service, to authenticate all users in a centralized place. This reduces the requirement for multiple credentials and reduces management complexity.

There are some additional key steps that you should do to further protect your root user account.

Ensure that you have a very long and complex password, and if necessary you should change the root user password to meet this recommendation.

  • Put the root user password in a secure location, and consider a physical or virtual password vault with strong multi-party access protocol.
  • Delete any access keys, and remove any programmatic access keys from the root user account.
  • Enable multi-factor authentication (MFA), and consider a hardware-based token that is stored in a physical vault or safe with a strong multi-party access protocol. Consider using a separate secure vault store for the password and the MFA token, with separate permissions for access.
  • A simple but hugely important step is to ensure your account information is correct, which includes the assigned root email address, so that AWS Support can contact you.

Do keep in mind that there are a few AWS tasks that require root user.

You should use IAM roles for programmatic or system-to-system access to AWS resources that are integrated with IAM. For example, you should use roles for applications that run on Amazon Elastic Compute Cloud (Amazon EC2) instances. Ensure the principle of least privilege is being applied for the IAM policies that are attached to the roles.

For cases where credentials that are not from AWS IAM, such as database credentials, need to be used by your application, you should not hard-code these credentials in the application source code, or stored in an un-encrypted state. It is recommended that you use a secrets management solution. For example, AWS Secrets Manager helps you protect the secrets needed to access your applications, services, and IT resources. Secrets Manager enables you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle. Users and applications can retrieve secrets with a call to Secrets Manager APIs, which eliminates the need to hardcode sensitive information in plain text.

For more information, see 4.1 Administrative Accounts in the MAS Notice 655 workbook on AWS Artifact.

Security Patches

“4.2 (a) A relevant entity must ensure that security patches are applied to address vulnerabilities to every system, and apply such security patches within a timeframe that is commensurate with the risks posed by each vulnerability.”

Consider the various categories of security patches you need to manage, based on the AWS Shared Responsibility Model and the AWS services you are using.

Here are some common examples, but does not represent an exhaustive list:

Operating system

When using services from AWS where you have control over the operating system, it is your responsibility to perform patching on these services. For example, if you use Amazon EC2 with Linux, applying security patches for Linux is your responsibility. To help you with this, AWS publishes security patches for Amazon Linux at the Amazon Linux Security Center.

AWS Inspector allows you to run scheduled vulnerability assessments on your Amazon EC2 instances, and provides a report of findings against rules packages that include operating system configuration benchmarks for common vulnerabilities and exposures (CVEs) and Center for Internet Security (CIS) guidelines. To see if AWS Inspector is available in your AWS Region, see the list of supported Regions for Amazon Inspector.

For managing patching activity at scale, consider AWS Systems Manager Patch Manager to automate the process of patching managed instances with both security-related patches and other types of updates.

Container orchestration and containers

If you are running and managing your own container orchestration capability, it is your responsibility to perform patching for both the master and worker nodes. If you are using Amazon Elastic Kubernetes Service (Amazon EKS), then AWS manages the patching of the control plane, and publishes EKS-optimized Amazon Machine Images (AMIs) that include the necessary worker node binaries (Docker and Kubelet). This AMI is updated regularly and includes the most up to date version of these components. You can update your EKS managed nodes to the latest versions of the EKS-optimized AMIs with a single command in the EKS console, API, or CLI. If you are building your own custom AMIs to use for EKS worker nodes, AWS also publishes Packer scripts that document the AWS build steps, to allow you to identify the binaries included in each version of the AMI.

AWS Fargate provides the option of serverless compute for containers, so you can avoid the operational overhead of scaling, patching, securing, and managing servers.

For the container images, you do need to ensure these are scanned for vulnerabilities and patched. The Amazon Elastic Container Registry (Amazon ECR) service offers the ability to scan container images for common vulnerabilities and exposures (CVEs).

Database engines

If you are running and managing your own databases on top of an AWS service such as Amazon EC2, it is your responsibility to perform patching of the database engine.

If you are using Amazon Relational Database Service (Amazon RDS), then AWS will automatically perform the patching of the database engine. This is done within the configurable Amazon RDS maintenance window, and is your opportunity to control when DB instance modifications, database engine version upgrades, and software patching occurs.

In cases where you are using fully-managed AWS database services such as Amazon DynamoDB, AWS takes care of the underlying patching requirements.

Application

For application code and dependencies that you run on AWS services, you own and manage the patching. This applies to applications that your organization has built themselves, or applications from a third-party software vendor. You should make sure that you have a mechanism for ensuring that vulnerabilities in the application code you run are regularly identified & patched.

For more information, see 4.2 Security Patches in the MAS Notice 655 workbook on AWS Artifact.

Security Standards

“4.3. (b)… a relevant entity must ensure that every system conforms to the set of security standards.”

After you have defined your organizational security standards, the next step is to verify your conformance to these standards. In my consultation with customers, I advise that it is a best practice to enforce these security standards as early in the development lifecycle possible. For example, you may have a standard requiring that data of a specific data classification must be encrypted at rest with a AWS Key Management Service (AWS KMS) customer-managed customer master key (CMK). The way this is typically achieved is by defining your Infrastructure-as-Code (IaC), for example using AWS CloudFormation. As your projects move through the various stages of development in your pipeline, you can automatically and programmatically check your IaC templates against codified security standards that you have defined. AWS has a number of tools that assist you with defining you rules and evaluating your IaC templates.

In the case of AWS CloudFormation, you may want to consider the tools AWS CloudFormation Guard, cfn-lint or cfn_nag. Enforcing your security standards as early in the development lifecycle as possible has some key benefits. It instills a culture and practice of creating deployments that are aligned to your standards from the outset, and allows developers to move fast by using the tools and workflow that work best for their team, while providing feedback early enough so they have time to resolve any issues & meet security standards during the development process.

It’s important to complement this IaC pipeline approach with additional controls to ensure that security standards remain in place after it is deployed. You should make sure to look at both preventative controls and detective controls.

For preventative controls, the focus is on IAM permissions. You can use these fine-grained permissions to enforce at the level of the IAM principal (such as user or role) to control what actions can or cannot be taken on AWS resources. You can make use of AWS Organizations service control policies (SCPs) to enforce permission guardrails globally across the entire organization, across an organizational unit, or across individual AWS accounts. Some example SCPs that may align to your security standards include the following: Prevent any virtual private cloud (VPC) that doesn’t already have internet access from getting it, Prevent users from disabling Amazon GuardDuty or modifying its configuration. Additionally, you can use the SCPs described in the AWS Control Tower Guardrail Reference, which you can implement with or without using AWS Control Tower.

For detective controls, after your infrastructure is deployed, you should make use of the AWS Security Hub and/or AWS Config rules to help you meet your compliance needs. You should ensure that the findings from these services are integrated with your technology operations processes to take action, or you can use automated remediation.

For more information, see 4.3 Security Standards in the MAS Notice 655 workbook on AWS Artifact.

Network Perimeter Defense

“4.4. A relevant entity must implement controls at its network perimeter to restrict all unauthorised network traffic.”

Having a layered security strategy is a best practice, and this applies equally to your network. AWS provides a number of complimentary network configuration options that you can implement to add network protection to your resources. You should consider using all of the options I describe here for your AWS workload. You can implement multiple strategies together where possible, to provide network defense in depth.

For network layer protection, you can use security groups for your VPC. Security groups act as a virtual firewall for members of the group to control inbound and outbound traffic. For each security group, you add rules that control the inbound traffic to instances, and a separate set of rules that control the outbound traffic. You can attach Security groups to EC2 instances and other AWS services that use elastic network interfaces, including RDS instances, VPC endpoints, AWS Lambda functions, and Amazon SageMaker notebooks.

You can also use network access control lists (ACLs) as an optional layer of security for your VPC that acts as a firewall for controlling traffic in and out of one or more subnets, and supports allow rules and deny rules. Network ACLs are a good option for controlling traffic at the subnet level.

For application-layer protection against common web exploits, you can use AWS WAF. You use AWS WAF on the Application Load Balancer that fronts your web servers or origin servers that are running on Amazon EC2, on Amazon API Gateway for your APIs, or you can use AWS WAF together with Amazon CloudFront. This allows you to strengthen security at the edge, filtering more of the unwanted traffic out before it reaches your critical content, data, code, and infrastructure.

For distributed denial of service (DDoS) protection, you can use AWS Shield, which is a managed service to provide protection against DDoS attacks for applications running on AWS. AWS Shield is available in two tiers: AWS Shield Standard and AWS Shield Advanced. All AWS customers benefit from the automatic protections of AWS Shield Standard, at no additional charge. AWS Shield Standard defends against most common, frequently occurring network and transport layer DDoS attacks that target your web site or applications. When you use AWS Shield Standard with Amazon CloudFront and Amazon Route 53, you receive comprehensive availability protection against all known infrastructure (Layer 3 and 4) attacks. AWS Shield Advanced provides advanced attack mitigation, visibility and attack notification, DDoS cost protection, and specialist support.

AWS Firewall Manager allows you to centrally configure and manage firewall rules across your accounts and applications in AWS Organizations. Also in AWS Firewall Manager, you can centrally manage and deploy security groups, AWS WAF rules, and AWS Shield Advanced protections.

There are many AWS Partner Network (APN) solutions that provide additional capabilities and protection that work alongside the AWS solutions discussed, in categories such as intrusion detection systems (IDS). For more information, find an APN Partner.

For more information, see 4.4 Network Perimeter Defence in the MAS Notice 655 workbook on AWS Artifact for additional information.

Malware protection

“4.5. A relevant entity must ensure that one or more malware protection measures are implemented on every system, to mitigate the risk of malware infection, where such malware protection measures are available and can be implemented.”

Malware protection requires a multi-faceted approach, including all of the following:

  • Training your employees in security awareness
  • Finding and patching vulnerabilities within your AWS workloads
  • Segmenting your networks
  • Limiting access to your critical systems and data
  • Having a comprehensive backup and restore strategy
  • Detection of malware
  • Creating incident response plans

In the previous sections of this post, I covered security patching, network segmentation, and limiting access. Now I’ll review the remaining elements.

Employee security awareness is crucial, because it is generally accepted that the primary vector by which malware is installed within your organization is by phishing (or spear phishing), where an employee is misled into installing malware, or opens an attachment that uses a vulnerability in software to install itself.

For backup and restore, a comprehensive and tested strategy is crucial, especially when the motivation of the malware is deletion, modification, or mass encryption (ransomware). You can review the AWS backup and restore solutions and leverage the various high-durability storage classes provided by Amazon Simple Storage Service (Amazon S3).

For malware protection, as with other security domains, it is important to have complementary detective controls along with the preventative ones, it is important to have systems for early detection of malware, or of the activity indicative of malware presence. Across your AWS account, when you understanding what typical activity looks like, that gives you a baseline of network and user activity that you can continuously monitor for anomalies.

Amazon GuardDuty is a threat detection service that continuously monitors and compares activity within your AWS environment for malicious or unauthorized behavior to help you protect your AWS accounts and workloads. Amazon GuardDuty uses machine learning, anomaly detection, and integrated threat intelligence to identify and prioritize potential threats.

Continuing on the topic of malware detection, you should consider other approaches as well, including endpoint detection and response (EDR) solutions. AWS has a number of partners that specialize in this space. For more information, find an APN Partner.

Finally, you should make sure that you have a security incident response plan to help you respond to an incident, communicate during an incident, and recover from it. AWS recommends that you create these response plans in the form of playbooks. A good way to create a playbook is to start off simple and iterate to improve your plan. Before you need to respond to an actual event, you should consider the tasks that you can do ahead of time to improve your recovery timeframes. Some of the issues to consider include pre-provisioning access to your responders, and pre-deploying the tools that the responders or forensic teams will need. Importantly, do not wait for an actual incident to test your response and recovery plans. You should run game days to practice, improve and iterate.

For more information, see 4.5 Malware protection in the MAS Notice 655 workbook on AWS Artifact.

Multi-factor authentication

“4.6. … a relevant entity must ensure that multi-factor authentication is implemented for the following:
(a)all administrative accounts in respect of any operating system, database, application, security appliance or network device that is a critical system; and
(b)all accounts on any system used by the relevant entity to access customer information through the internet.“

When using multi-factor authentication (MFA), it’s important to for you to think of the various layers that you need to implement.

For access to the AWS API, AWS Management Console, and AWS resources that use AWS Identity and Access Management (IAM), you can configure MFA with a number of different form factors, and apply it to users within your AWS accounts. As I mentioned in the Administrative accounts section, AWS recommends that you apply MFA to the root account user. Where possible, you should not use IAM users, but instead use identity federation with IAM roles. By using identity federation with IAM roles, you can apply and enforce MFA at the level of your identity provider, for example Active Directory Federation Services (AD FS) or AWS Single Sign-On. For highly privileged actions, you may want to configure MFA-protected API access to only allow the action if MFA authentication has been performed.

With regards to third-party applications, which includes software as a service (SaaS), you should consider integration with AWS services or third-party services to provide MFA protection. For example, AWS Single Sign-On (SSO) includes built-in integrations to many business applications, including Salesforce, Office 365, and others.

For your own in-house applications, you may want to consider solutions such as Amazon Cognito. Amazon Cognito goes beyond standard MFA (which use SMS or TOTP), and includes the option of adaptive authentication when using the advanced security features. With this feature enabled, when Amazon Cognito detects unusual sign-in activity, such as attempts from new locations and unknown devices, it can challenge the user with additional verification checks.

For more information, see 4.6 Multi-Factor authentication in the MAS Notice 655 workbook on AWS Artifact.

Conclusion

AWS products and services have security features designed to help you improve the security of your workloads, and meet your compliance requirements. Many AWS services are reviewed by independent third-party auditors, and these audit reports are available on AWS Artifact. You can use AWS services, tools, and guidance to address your side of the shared responsibility model to align with the requirements stated in Notice 655 – Notice on Cyber Hygiene.

Review the MAS Notice 655 – Cyber Hygiene – Workbook on AWS Artifact to understand both the AWS control environment (the AWS side of the shared responsibility model) and the guidance AWS provides to help you with your side of the shared responsibility model. You will find AWS guidance in the AWS Well-Architected Framework best practices, and where available or applicable to detective controls, in AWS Config rules and Amazon GuardDuty findings.

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

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Boyd author photo

Darran Boyd

Darran is a Principal Security Solutions Architect at AWS, responsible for helping remove security blockers for our customers and accelerating their journey to the AWS Cloud. Darran’s focus and passion is to deliver strategic security initiatives that un-lock and enable our customers at scale across the financial services industry and beyond.

New IRAP reports for Australian customers are now available in AWS Artifact

Post Syndicated from Henry Xu original https://aws.amazon.com/blogs/security/new-irap-reports-australian-customers-now-available-aws-artifact/

Following our Information Security Registered Assessors Program (IRAP) assessment in December 2019, we are excited to announce that we have additional new IRAP documents now available in AWS Artifact as a result of the recent IRAP assessment at the PROTECTED level that was finished in June 2020. This includes an IRAP compliance report for 33 additional services, plus 1 separate report for AWS Outposts. Also included are 3 features of services that were already assessed in 2019: Amazon EventBridge for Amazon CloudWatch, AWS Transit Gateway for Amazon Virtual Private Cloud (Amazon VPC), and AWS Lake Formation for AWS Glue. The IRAP documentation pack continues to provide the ability to plan, architect, and self-assess Amazon Web Services (AWS) Cloud services in accordance with the Secure Cloud Strategy of the Australian government’s Digital Transformation Agency.

The list of new services includes Amazon Chime and Amazon AppStream 2.0, which are important services for remote working scenarios.

With the additional 34 services in scope of this cycle, we now have a total of 92 services assessed at the PROTECTED level. For the full list of those services, see the AWS Services in Scope page (select the IRAP tab).

The services in scope of this assessment are:

This brings a raft of services and capabilities to our customers for workloads at the PROTECTED level across contact centers, development pipelines, artificial intelligence and machine learning (AI/ML) services, media services, containers, storage, migration and transfer, networking, analytics, security, application integration, video conferencing, and Internet of Things (IoT), and also enables the ability to run AWS infrastructure and services on premises for a consistent hybrid experience using Outposts. All services in scope are available for you now in the Asia Pacific (Sydney) Region.

Because we care deeply about our customers’ needs, we strive to bring more services into the scope of the IRAP PROTECTED level, based on your requirements. Please reach out to your AWS representatives to let us know what additional services you would like to see in scope for coming IRAP assessments.

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 Artifact forum.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Author

Henry Xu

Henry is an APAC Audit Program Manager in AWS Security Assurance, based in Canberra, Australia. He manages regional compliance programs, including IRAP assessments. With experience across technical and leadership roles in public and private sectors, he is passionate about secure cloud adoption. Outside of AWS, Henry enjoys time with family, and he used to be a professional ballroom dancer.

AWS Artifact service launches new user interface

Post Syndicated from Dhiraj Mehta original https://aws.amazon.com/blogs/security/aws-artifact-service-launches-new-user-interface/

AWS Artifact service introduces a new user interface (UI) that provides a more intuitive experience in searching and saving AWS compliance reports, and accepting agreements. The new UI includes AWS Artifact home page equipped with information and videos on how to use the AWS Artifact service for your compliance needs. Additionally, the Reports and Agreements console now provides keyword search capability allowing you to accurately search the artifact you are looking for rather than scrolling through the entire page. The new UI is supported on a smartphone, tablet, laptop, or widescreen monitor, resizing the on-screen content dynamically.

Check out the new AWS Artifact UI and connect with us on our new AWS Artifact Forum for any questions, feedback or suggestions for new features. To learn more about AWS Artifact, please visit our product page.

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

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Author

Dhiraj Mehta

Dhiraj Mehta is a Senior Technical Program Manager at AWS and product owner of AWS Artifact. He has extensive experience in security, risk, and compliance domains. He received his MBA from University of California, Irvine, and completed his undergrad in Computer Science from Kurukshetra University in India. Outside of work, Dhiraj likes to travel, cook, and play ping-pong.

AWS Artifact is now available in AWS GovCloud (US) Regions

Post Syndicated from Ira Tiwari original https://aws.amazon.com/blogs/security/aws-artifact-is-now-available-in-aws-govcloud-us-regions/

AWS Artifact is now available in the AWS GovCloud (US) Regions, where you’ll now have on-demand access to AWS compliance reports and select online AWS agreements with a single-click in the AWS Management Console.

The AWS GovCloud (US) Regions are isolated and designed to host sensitive data and regulated workloads in the cloud, assisting customers who have United States federal, state, or local government compliance requirements.

AWS Artifact provides on-demand downloads of AWS security and compliance documents, such as AWS ISO certifications, and Payment Card Industry (PCI), AWS Federal Risk and Authorization Management Program (FedRAMP) Partner Package, and Service Organization Control (SOC) reports. You can submit the security and compliance documents (also known as audit artifacts) to your auditors or regulators to demonstrate the security and compliance of the AWS infrastructure and services that you use. You can also use these documents as guidelines to evaluate your own cloud architecture and assess the effectiveness of your company’s internal controls.

AWS Artifact can also be used to review AWS GovCloud (US) terms and conditions, accept agreements with AWS and designate AWS accounts that process restricted information (such as protected health information), and to track the status of multiple AWS agreements. To learn how to use Artifact to accept agreements for multiple accounts, see Managing Your Agreements in AWS Artifact.

Learn more about AWS Artifact here, and consult the Artifact FAQ here.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Author

Ira Tiwari

Ira’s focus area is to build strategic initiatives to automate compliance workflow for Amazon Web Services. She’s very excited about building innovations in the audit domain and providing assurance to customers to adopt AWS for regulated workloads.

Accept an ANDB Addendum for all accounts within your AWS Organization

Post Syndicated from Adam Star original https://aws.amazon.com/blogs/security/accept-an-andb-addendum-for-all-accounts-within-your-aws-organization/

For customers who use AWS to store or process personal information covered by the Australian Privacy Act 1988, I’m excited to announce that you can now accept a single AWS Australian Notifiable Data Breach Addendum (ANDB Addendum) for all accounts within your AWS Organization. Once accepted, all current and future accounts created or added to your AWS Organization will immediately be covered by the ANDB Addendum.

My team is focused on improving the customer experience by improving the tools used to perform compliance tasks. Previously, if you wanted to designate several AWS accounts, you had to sign in to each account individually to accept the ANDB Addendum. Now, an authorized master account user can accept the ANDB Addendum once to automatically designate all existing and future member accounts in the AWS Organization as ANDB accounts. This capability addresses a frequent customer request to be able to quickly designate multiple ANDB accounts and confirm those accounts are covered under the terms of the ANDB Addendum.

If you have an ANDB Addendum in place already and want to leverage this new capability, a master account user can accept the new AWS Organizations ANDB Addendum in AWS Artifact today. To get started, your organization must use AWS Organizations to manage your accounts, and “all features” need to be enabled. Learn more about creating an organization.

Once you’re using AWS Organizations with all features enabled and you have the necessary user permissions, accepting the AWS Organizations ANDB Addendum takes about two minutes. We’ve created a video that shows you the process, step-by-step.

If your organization prefers to continue managing ANDB accounts individually, you can still do that. It takes less than two minutes to designate a single account as an ANDB account in AWS Artifact. You can watch our video to learn how.

As with all AWS Artifact features, there is no additional cost to use AWS Artifact to review, accept, and manage individual account ANDB Addendums or the new AWS Organizations ANDB Addendum. To learn more about AWS Artifact, please visit the AWS Artifact FAQ page.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Author photo

Adam Star

Adam joined Amazon in 2012 and is a Program Manager on the Security Obligations and Contracts team. He enjoys designing practical solutions to help customers meet a range of global compliance requirements including GDPR, HIPAA, and the European Banking Authority’s Guidelines on Outsourcing Arrangements. Adam lives in Seattle with his wife & daughter. Originally from New York, he’s constantly searching for “real” bagels & pizza. He’s an active member of the Washington State Bar Association and American Homebrewers Association, finding the latter much more successful when attempting to make friends in social situations.

Accept a BAA with AWS for all accounts in your organization

Post Syndicated from Kristen Haught original https://aws.amazon.com/blogs/security/accept-a-baa-with-aws-for-all-accounts-in-your-organization/

I’m excited to announce to our healthcare customers and partners that you can now accept a single AWS Business Associate Addendum (BAA) for all accounts within your organization. Once accepted, all current and future accounts created or added to your organization will immediately be covered by the BAA.

Our team is always thinking about how we can reduce manual processes related to your compliance tasks. That’s why I’ve been looking forward to the release of AWS Artifact Organization Agreements, which was designed to simplify the BAA process and improve your experience when designating AWS accounts as HIPAA accounts. Previously, if you wanted to designate several AWS accounts, you had to sign-in to each account individually to accept the BAA or email us. Now, an authorized master account user can accept the BAA once to automatically designate all existing and future member accounts in the organization as HIPAA accounts for use with protected health information (PHI). This release addresses a frequent customer request to be able to quickly designate multiple HIPAA accounts and confirm those accounts are covered under the terms of the BAA.

If you have a BAA in place already and want to leverage this new capability a master account user can accept the new AWS Organizations BAA in AWS Artifact today. To get started, your organization must use AWS Organizations to manage your accounts, and “all features” needs to be enabled. Learn more about creating an organization here.

Once you are using AWS Organizations with all features enabled, and you have the necessary user permissions, then accepting the AWS Organizations BAA takes about two minutes. We’ve created a video that shows you the process, step-by-step.

If your organization prefers to continue managing HIPAA accounts individually, you can still do that.  We have streamlined the process for accepting an individual account BAA as well. It takes less than two minutes to designate a single account as a HIPAA account in AWS Artifact. You can watch the new video here to learn how.

As with all AWS Artifact features, there is no additional cost to use AWS Artifact to review, accept, and manage individual account BAAs or the new organization BAA. To learn more, go to the FAQ page.

 

Spring 2018 AWS SOC Reports are Now Available with 11 Services Added in Scope

Post Syndicated from Chris Gile original https://aws.amazon.com/blogs/security/spring-2018-aws-soc-reports-are-now-available-with-11-services-added-in-scope/

Since our last System and Organization Control (SOC) audit, our service and compliance teams have been working to increase the number of AWS Services in scope prioritized based on customer requests. Today, we’re happy to report 11 services are newly SOC compliant, which is a 21 percent increase in the last six months.

With the addition of the following 11 new services, you can now select from a total of 62 SOC-compliant services. To see the full list, go to our Services in Scope by Compliance Program page:

• Amazon Athena
• Amazon QuickSight
• Amazon WorkDocs
• AWS Batch
• AWS CodeBuild
• AWS Config
• AWS OpsWorks Stacks
• AWS Snowball
• AWS Snowball Edge
• AWS Snowmobile
• AWS X-Ray

Our latest SOC 1, 2, and 3 reports covering the period from October 1, 2017 to March 31, 2018 are now available. The SOC 1 and 2 reports are available on-demand through AWS Artifact by logging into the AWS Management Console. The SOC 3 report can be downloaded here.

Finally, prospective customers can read our SOC 1 and 2 reports by reaching out to AWS Compliance.

Want more AWS Security news? Follow us on Twitter.

Newly released guide provides Australian public sector the ability to evaluate AWS at PROTECTED level

Post Syndicated from Oliver Bell original https://aws.amazon.com/blogs/security/newly-released-guide-provides-australian-public-sector-the-ability-to-evaluate-aws-at-protected-level/

Australian public sector customers now have a clear roadmap to use our secure services for sensitive workloads at the PROTECTED level. For the first time, we’ve released our Information Security Registered Assessors Program (IRAP) PROTECTED documentation via AWS Artifact. This information provides the ability to plan, architect, and self-assess systems built in AWS under the Digital Transformation Agency’s Secure Cloud Guidelines.

In short, this documentation gives public sector customers everything needed to evaluate AWS at the PROTECTED level. And we’re making this resource available to download on-demand through AWS Artifact. When you download the guide, you’ll find a mapping of how AWS meets each requirement to securely and compliantly process PROTECTED data.

With the AWS IRAP PROTECTED documentation, the process of adopting our secure services has never been easier. The information enables individual agencies to complete their own assessments and adopt AWS, but we also continue to work with the Australian Signals Directorate to include our services at the PROTECTED level on the Certified Cloud Services List.

Meanwhile, we’re also excited to announce that there are now 46 services in scope, which mean more options to build secure and innovative solutions, while also saving money and gaining the productivity of the cloud.

If you have questions about this announcement or would like to inquire about how to use AWS for your regulated workloads, contact your account team.

EU Compliance Update: AWS’s 2017 C5 Assessment

Post Syndicated from Oliver Bell original https://aws.amazon.com/blogs/security/eu-compliance-update-awss-2017-c5-assessment/

C5 logo

AWS has completed its 2017 assessment against the Cloud Computing Compliance Controls Catalog (C5) information security and compliance program. Bundesamt für Sicherheit in der Informationstechnik (BSI)—Germany’s national cybersecurity authority—established C5 to define a reference standard for German cloud security requirements. With C5 (as well as with IT-Grundschutz), customers in German member states can use the work performed under this BSI audit to comply with stringent local requirements and operate secure workloads in the AWS Cloud.

Continuing our commitment to Germany and the AWS European Regions, AWS has added 16 services to this year’s scope:

The English version of the C5 report is available through AWS Artifact. The German version of the report will be available through AWS Artifact in the coming weeks.

– Oliver

Updated AWS SOC Reports Are Now Available with 19 Additional Services in Scope

Post Syndicated from Chad Woolf original https://aws.amazon.com/blogs/security/updated-aws-soc-reports-are-now-available-with-19-additional-services-in-scope/

AICPA SOC logo

Newly updated reports are available for AWS System and Organization Control Report 1 (SOC 1), formerly called AWS Service Organization Control Report 1, and AWS SOC 2: Security, Availability, & Confidentiality Report. You can download both reports for free and on demand in the AWS Management Console through AWS Artifact. The updated AWS SOC 3: Security, Availability, & Confidentiality Report also was just released. All three reports cover April 1, 2017, through September 30, 2017.

With the addition of the following 19 services, AWS now supports 51 SOC-compliant AWS services and is committed to increasing the number:

  • Amazon API Gateway
  • Amazon Cloud Directory
  • Amazon CloudFront
  • Amazon Cognito
  • Amazon Connect
  • AWS Directory Service for Microsoft Active Directory
  • Amazon EC2 Container Registry
  • Amazon EC2 Container Service
  • Amazon EC2 Systems Manager
  • Amazon Inspector
  • AWS IoT Platform
  • Amazon Kinesis Streams
  • AWS Lambda
  • AWS [email protected]
  • AWS Managed Services
  • Amazon S3 Transfer Acceleration
  • AWS Shield
  • AWS Step Functions
  • AWS WAF

With this release, we also are introducing a separate spreadsheet, eliminating the need to extract the information from multiple PDFs.

If you are not yet an AWS customer, contact AWS Compliance to access the SOC Reports.

– Chad

New: Server-Side Encryption for Amazon Kinesis Streams

Post Syndicated from Tara Walker original https://aws.amazon.com/blogs/aws/new-server-side-encryption-for-amazon-kinesis-streams/

In this age of smart homes, big data, IoT devices, mobile phones, social networks, chatbots, and game consoles, streaming data scenarios are everywhere. Amazon Kinesis Streams enables you to build custom applications that can capture, process, analyze, and store terabytes of data per hour from thousands of streaming data sources. Since Amazon Kinesis Streams allows applications to process data concurrently from the same Kinesis stream, you can build parallel processing systems. For example, you can emit processed data to Amazon S3, perform complex analytics with Amazon Redshift, and even build robust, serverless streaming solutions using AWS Lambda.

Kinesis Streams enables several streaming use cases for consumers, and now we are making the service more effective for securing your data in motion by adding server-side encryption (SSE) support for Kinesis Streams. With this new Kinesis Streams feature, you can now enhance the security of your data and/or meet any regulatory and compliance requirements for any of your organization’s data streaming needs.
In fact, Kinesis Streams is now one of the AWS Services in Scope for the Payment Card Industry Data Security Standard (PCI DSS) compliance program. PCI DSS is a proprietary information security standard administered by the PCI Security Standards Council founded by key financial institutions. PCI DSS compliance applies to all entities that store, process, or transmit cardholder data and/or sensitive authentication data which includes service providers. You can request the PCI DSS Attestation of Compliance and Responsibility Summary using AWS Artifact. But the good news about compliance with Kinesis Streams doesn’t stop there. Kinesis Streams is now also FedRAMP compliant in AWS GovCloud. FedRAMP stands for Federal Risk and Authorization Management Program and is a U.S. government-wide program that delivers a standard approach to the security assessment, authorization, and continuous monitoring for cloud products and services. You can learn more about FedRAMP compliance with AWS Services here.

Now are you ready to get into the keys? Get it, instead of get into the weeds. Okay a little corny, but it was the best I could do. Coming back to discussing SSE for Kinesis Streams, let me explain the flow of server-side encryption with Kinesis.  Each data record and partition key put into a Kinesis Stream using the PutRecord or PutRecords API is encrypted using an AWS Key Management Service (KMS) master key. With the AWS Key Management Service (KMS) master key, Kinesis Streams uses the 256-bit Advanced Encryption Standard (AES-256 GCM algorithm) to add encryption to the incoming data.

In order to enable server-side encryption with Kinesis Streams for new or existing streams, you can use the Kinesis management console or leverage one of the available AWS SDKs.  Additionally, you can audit the history of your stream encryption, validate the encryption status of a certain stream in the Kinesis Streams console, or check that the PutRecord or GetRecord transactions are encrypted using the AWS CloudTrail service.

 

Walkthrough: Kinesis Streams Server-Side Encryption

Let’s do a quick walkthrough of server-side encryption with Kinesis Streams. First, I’ll go to the Amazon Kinesis console and select the Streams console option.

Once in the Kinesis Streams console, I can add server-side encryption to one of my existing Kinesis streams or opt to create a new Kinesis stream.  For this walkthrough, I’ll opt to quickly create a new Kinesis stream, therefore, I’ll select the Create Kinesis stream button.

I’ll name my stream, KinesisSSE-stream, and allocate one shard for my stream. Remember that the data capacity of your stream is calculated based upon the number of shards specified for the stream.  You can use the Estimate the number of shards you’ll need dropdown within the console or read more calculations to estimate the number of shards in a stream here.  To complete the creation of my stream, now I click the Create Kinesis stream button.

 

With my KinesisSSE-stream created, I will select it in the dashboard and choose the Actions dropdown and select the Details option.


On the Details page of the KinesisSSE-stream, there is now a Server-side encryption section.  In this section, I will select the Edit button.

 

 

Now I can enable server-side encryption for my stream with an AWS KMS master key, by selecting the Enabled radio button. Once selected I can choose which AWS KMS master key to use for the encryption of  data in KinesisSSE-stream. I can either select the KMS master key generated by the Kinesis service, (Default) aws/kinesis, or select one of my own KMS master keys that I have previously generated.  I’ll select the default master key and all that is left is for me to click the Save button.


That’s it!  As you can see from my screenshots below, after only about 20 seconds, server-side encryption was added to my Kinesis stream and now any incoming data into my stream will be encrypted.  One thing to note is server-side encryption only encrypts incoming data after encryption has been enabled. Preexisting data that is in a Kinesis stream prior to server-side encryption being enabled will remain unencrypted.

 

Summary

Kinesis Streams with Server-side encryption using AWS KMS keys makes it easy for you to automatically encrypt the streaming data coming into your  stream. You can start, stop, or update server-side encryption for any Kinesis stream using the AWS management console or the AWS SDK. To learn more about Kinesis Server-Side encryption, AWS Key Management Service, or about Kinesis Streams review the Amazon Kinesis getting started guide, the AWS Key Management Service developer guide, or the Amazon Kinesis product page.

 

Enjoy streaming.

Tara

Introducing the Self-Service Business Associate Addendum

Post Syndicated from Chad Woolf original https://aws.amazon.com/blogs/security/introducing-the-self-service-business-associate-addendum/

HIPAA logo

Today, we made available a new feature in AWS Artifact (our auditing and compliance portal) that enables you to review, accept, and track the status of your Business Associate Addendum (BAA). With this new feature, you can accept the terms of a BAA online, and instantly designate an AWS account as a “HIPAA Account” for use with protected health information (PHI) under the U.S. Health Insurance Portability and Accountability Act (HIPAA). In addition, you can sign in to AWS Artifact to confirm that your account is designated as a HIPAA Account, and review the terms of the BAA for that account. If you are no longer using a designated HIPAA Account in connection with PHI, you can remove that designation using the AWS Artifact interface.

Today’s release addresses two key customer needs in particular: (1) the need to enter into a BAA quickly, and (2) the need to easily track and control whether an AWS account is designated as a HIPAA Account under a BAA.

The BAA is the first specialized industry agreement that AWS is making available online. We chose to launch with the BAA as a commitment to AWS customer organizations who are reinventing the way healthcare is researched and delivered with the cloud. Many AWS customers have great stories to tell as we work together to use technology to advance the healthcare industry.

If you already have a BAA with AWS, or if you are considering designing or migrating a new solution that will create, receive, maintain, or transmit PHI on AWS, you can use AWS Artifact to manage your HIPAA Accounts today. As with all AWS Artifact features, there are no additional fees for using AWS Artifact to review, accept, and manage BAAs online.

– Chad

Updated AWS SOC Reports Include Three New Regions and Three Additional Services

Post Syndicated from Chad Woolf original https://aws.amazon.com/blogs/security/updated-aws-soc-reports-include-three-new-regions-and-three-additional-services/

 

SOC logo

The updated AWS Service Organization Control (SOC) 1 and SOC 2 Security, Availability, and Confidentiality Reports covering the period of October 1, 2016, through March 31, 2017, are now available. Because we are always looking for ways to improve the customer experience, the current AWS SOC 2 Confidentiality Report has been combined with the AWS SOC 2 Security & Availability Report, making for a seamless read. The updated AWS SOC 3 Security & Availability Report also is publicly available by download.

Additionally, the following three AWS services have been added to the scope of our SOC Reports:

The AWS SOC Reports now also include our three newest regions: US East (Ohio), Canada (Central), and EU (London). SOC Reports now cover 15 regions and supporting edge locations across the globe. See AWS Global Infrastructure for additional geographic information related to AWS SOC.

The updated SOC Reports are available now through AWS Artifact in the AWS Management Console. To request a report:

  1. Sign in to your AWS account.
  2. In the list of services under Security, Identity and Compliance, choose Compliance Reports. On the next page, choose the report you would like to review. Note that you might need to request approval from Amazon for some reports. Requests are reviewed and approved by Amazon within 24 hours.

For further information, see frequently asked questions about the AWS SOC program.  

– Chad

The AWS EU (London) Region Achieves Public Services Network (PSN) Assurance

Post Syndicated from Oliver Bell original https://aws.amazon.com/blogs/security/aws-uk-region-achieves-public-services-network-psn-assurance/

UK flag

AWS is excited to announce that the AWS EU (London) Region has achieved Public Services Network (PSN) assurance. This means that the EU (London) Region can now be connected to the PSN (or PSN customers) by PSN-certified AWS Direct Connect partners. PSN assurance demonstrates to our UK Public Sector customers that the EU (London) Region has met the stringent requirements of PSN and provides an assured platform on which to build UK Public Sector services. Customers are required to ensure that applications and configurations applied to their AWS instances meet the PSN standards, and they must undertake PSN certification for the content, platform, applications, systems, and networks they run on AWS (but no longer need to include AWS infrastructure and products in their certification).

In conjunction with our Standardized Architecture for UK-OFFICIAL, PSN assurance enables UK Public Sector organizations to move their UK-OFFICIAL classified data to the EU (London) Region in a controlled and risk-managed manner. AWS has also created a UK-OFFICIAL on AWS Quick Start, which provisions an environment suitable for UK-OFFICIAL classified data. This Quick Start includes guidance and controls that help public sector organizations manage risks and ensure security when handling UK-OFFICIAL information assets.

You can download the EU (London) Region PSN Code of Connection and Service Compliance certificates through AWS Artifact. For further information about using AWS in the context of the National Cyber Security Centre (NCSC) UK’s Cloud Security Principles, see Using AWS in the Context of NCSC UK’s Cloud Security Principles.

– Oliver