Economic arguments for cloud services migration

AWS Security and Compliance

As was previously mentioned, AWS uses a shared responsibility model in which AWS and its

customers share control over the IT environment, so both parties have responsibility for managing

that environment.

AWS’ role, in this shared responsibility approach, includes providing its services on a highly secure

and controlled platform and providing a wide array of security features customers can use. The

customer is responsible for configuring their IT environment in a secure and controlled manner for

their purposes.

AWS advises customers about any changes to its security and control environment, as appropriate,

and works to obtain industry certifications and independent third-party attestations. AWS publishes

information about its security and control practices openly. It also provides website content,

certificates, reports, and other documentation directly to its customers under Non-Disclosure

Agreements (NDAs).

When a customer moves their production workloads to the AWS cloud, responsibility for the

management of the IT environment falls to both AWS and the customer. The customer is responsible

for establishing their environment in a secure and controlled manner. The customer is also required

to maintain acceptable governance over the whole of their IT control environment.

The shared responsibility model helps reduce the customer’s IT operational burden, as it is AWS’

responsibility to manage the components from the host operating system and virtualisation layer

down to the physical security of the data centers in which these services operate. The customer is

responsible for the components from the guest operating system upwards (including updates,

security patches and antivirus software).

The customer is also responsible for any other application software, as well as the configuration of

security groups, Virtual Private Clouds (VPCs) and so on. While AWS manages the security of the

cloud, security in the cloud is the responsibility of the customer. Customers retain control of what

security they choose to implement to protect their own content, platform, applications, systems and

networks, no differently than they would for applications in an on-site data center.

The figure below illustrates the allocation of responsibilities to roles, in AWS’ shared responsibility

model –

Figure 1: AWS’ shared responsibility model

The customer-AWS shared responsibility model is not just limited to security considerations, but it

also extends to IT controls. For example, the management, operation and verification of IT controls

are shared between AWS and the customer.

Before moving to the AWS Cloud, customers were responsible for managing all of the IT controls in

their environments. AWS manages the controls for the physical infrastructure, thereby allowing

customers to focus on managing the relevant IT controls.

Because every customer is deployed differently in AWS, customers can shift management of certain

IT controls to AWS. This change in management of IT controls results in a new, distributed control

environment. Customers can then use the AWS control and compliance documentation available to

them to perform their control evaluation and verification procedures as required.

It is still the customers’ responsibility to maintain adequate governance over the entire IT control

environment, regardless of how their IT is deployed (whether it is on-premises, on the cloud or part

of a hybrid environment). By deploying to the AWS Cloud, customers have options to apply different

types of controls and various verification methods.

AWS Controls:

AWS provides customers with a wide range of information regarding its IT control environment

through whitepapers, reports, certifications, and other third-party attestations. This documentation

assists customers in understanding the controls in place relevant to the AWS Cloud services they use

and how those controls have been validated.

The information also assists customers in accounting for and validating that controls in their

extended IT environment are operating effectively. Traditionally, the design and operating

effectiveness of controls and control objectives are validated by internal and/ or external auditors

via process walkthroughs and evidence evaluation. Direct observation and verification, by the

customer or customer’s external auditor, is generally performed to validate controls.

In cases where service providers such as AWS are used, companies request and evaluate third-party

attestations and certifications to gain reasonable assurance of the design and operating

effectiveness of controls and control objectives. As a result, although a customer’s key controls may

be managed by AWS, the control environment can still be a unified framework in which all controls

are accounted for and are verified as operating effectively.

AWS third-party attestations and certifications not only provide a higher level of validation of the

control environment, but may also relieve customers of the requirement to perform certain

validation work themselves.

AWS Key Controls –

AWS customers can identify key controls managed by AWS. Key controls are critical to the

customer’s control environment and require an external attestation of the operating effectiveness of

these key controls in order to meet compliance requirements (for example, an annual financial

audit).

For this purpose, AWS publishes a wide range of specific IT controls in its Service Organisation

Controls 1 (SOC 1) Type II report. The SOC 1 Type II report, formerly the Statement on Auditing

Standards (SAS) No. 70, is a widely recognised auditing standard developed by the American

Institute of Certified Public Accountants (AICPA).

The SOC 1 audit is an in-depth audit of both the design and operating effectiveness of AWS-defined

control objectives and control activities (which include control objectives and control activities over

the part of the infrastructure that AWS manages). ‘Type II’ refers to the fact that each of the controls

described in the report are not only evaluated for adequacy of design, but are also tested for

operating effectiveness by the external auditor. Because of the independence and competence of

AWS external auditor, controls identified in the report should provide customers with a high level of

confidence in AWS control environment.

AWS controls can be considered effectively designed and operating for many compliance purposes,

including Sarbanes-Oxley (SOX) Section 404 financial statement audits. Leveraging SOC 1 Type II

reports is also generally permitted by other external certifying bodies. For example, International

Organization for Standardization (ISO) 27001 auditors may request a SOC 1 Type II report in order to

complete their evaluations for customers.

General AWS Controls based on Compliance with Industry-wide Standards –

If AWS customers require a broad set of control objectives to be met, evaluation of AWS industry

certifications may be performed. With the ISO 27001 certification, AWS complies with a broad,

comprehensive security standard and follows best practices in maintaining a secure environment.

With the Payment Card Industry (PCI) Data Security Standard (DSS) certification, AWS complies with

a set of controls important to companies that handle credit card information.

AWS compliance with Federal Information Security Management Act (FISMA) standards means

that AWS complies with a wide range of specific controls required by U.S. government agencies.

AWS compliance with these general standards provides customers with in-depth information on the

comprehensive nature of the controls and security processes in place in the AWS Cloud.

AWS’ Structured Approach to Risk Management:

AWS has a strategic business plan that includes risk identification and the implementation of

controls to mitigate or manage risks, similar to the risk-management framework presented in an

earlier lecture. An AWS management team re-evaluates the business risk plan at least twice a year.

As a part of this process, management team members are required to identify risks within their

specific areas of responsibility and implement controls designed to address and perhaps even

eliminate those risks. The AWS control environment is subject to additional internal and external risk

assessments.

AWS compliance and security teams have established information security frameworks and policies

based on the Control Objectives for Information and Related Technology (COBIT) framework, and

they have effectively integrated the ISO 27001 certifiable framework based on ISO 27002 controls,

AICPA Trust Services Principles, PCI DSS v3.1, and the National Institute of Standards and Technology

(NIST) Publication 800-53, Revision 3, Recommended Security Controls for Federal Information

Systems.

AWS maintains the security policy and provides security training to its employees. Additionally, AWS

performs regular application security reviews to assess the confidentiality, integrity and availability

of data, and conformance to the information security policy. The AWS security team regularly scans

any public-facing endpoint IP addresses for vulnerabilities. Note that these scans do not include

customer instances.

AWS security notifies the appropriate parties to remediate any identified vulnerabilities. In addition,

independent security firms regularly perform external vulnerability threat assessments. Findings and

recommendations resulting from these assessments are categorised and delivered to AWS

leadership. These scans are done in a manner for the health and viability of the underlying AWS

infrastructure and are not meant to replace the customer’s own vulnerability scans that are required

to meet their specific compliance requirements (based on local regulations).