Chapter 13: AWS Risk and Compliance

This chapter appears to be designed for accountants perhaps (or other people that "count" things and tick boxes)?




It introduces the Shared Responsibility Model, this is where AWS is responsible for Security "of" the Cloud, and the Customer is responsible for security "in" the cloud.

The picture:





This sort of makes sense at some level, until I noticed that The customer is responsible for the components from the guest operation systems upward: updates, security patches, etc.

Now for some reason I thought one of the advertised advantages of AWS was the customer didn't have to worry about O/S updates and patches? Which is correct? If you are just using AWS EC2 images provided by amazon I'm not even sure how you could update and patch them as you don't own the license for the O/S.

The windows guide says:

Keeping Your AMIs Up-to-Date

AWS provides updated, fully-patched Windows AMIs within five business days of Microsoft's patch Tuesday (the second Tuesday of each month). For more information, see Details About AWS Windows AMI Versions.

At their initial launch, your Windows instances contain all the latest security updates. We recommend that you run the Windows Update service as a first step after you launch a Windows, and before you create an AMI. After you launch an instance or create an AMI, you are responsible for keeping them up-to-date. You can use the Windows Update service, or the Automatic Updates tool available on your instance to deploy Microsoft updates to your instance. You must also keep any other software that you deploy to your instance up-to-date using whatever mechanism is appropriate for that software. After you update your Windows instance, you can create an AMI that replaces any previous AMIs that you created. For more information, see Updating Your Windows Instance.

You can also subscribe to AMI updates.

So yes, it seems that once you've launched an EC2 Windows instance updates and patches are up to the customer.

Much of the rest of the chapter appears to be about Accountants. I.e. people that count.

SOC 1

SOC 2

SOC 3

3 Socks!

SOC reports are Service Organisation Controls (SOC) and are produced by Accountants!  Astonishing. Does this make me feel better? More controlled? More something?

Evidently they allow accountants into AWS to check that it works (or something).

https://aws.amazon.com/compliance/soc-faqs/

SOC 1 is financial compliance, SOC 2 and 3 are for Security, Availability, & Confidentiality.

This whitepaper has more details. 

Appendix B has Australian specific content. Looks complicated.

Customers can request permission to conduct their own vulnerability scans on their own environments. But must not violate the AWS acceptable use policy, 

This page covers simulated event testing.

So I wonder who would need to know all this stuff? And how you'd decide what policies etc were required for your application in the AWS cloud? What if there are local (e.g. Australian) laws and policies applicable?

Amazon has also made some documents available, but you may not be allowed to share the content:

AWS Artifact features a comprehensive list of access-controlled documents relevant to compliance and security in the AWS cloud. Not seeing the document you are looking for? Make sure you have the correct access applied through your IAM policy. Review the AWS Artifact Documentation for instructions on how to gain access. It says this:

Securing Your Documents

Audit artifacts are confidential documents, and should be kept secure at all times. AWS Artifact uses the AWS shared compliance responsibility model for its documents. This means that AWS is responsible for keeping documents secure while they are in the AWS Cloud, but you are responsible for keeping them secure after you download them. AWS Artifact might require you to sign a Non-Disclosure Agreement (NDA) before you can download documents. Each document download has a unique, traceable watermark.

Audit artifacts should be shared only with those you trust. We strongly recommend that you use a secure document sharing service, such as Amazon WorkDocs, to share documents with others. Do not send these documents over email or upload them to an unsecure site.

What is Amazon WorkDocs?

PS
Why does this sort of "risk and compliance" approach worry me a bit? Well a few years ago I was involved in contractual negotiations with a potential customer. Their lawyers wanted us to agree to and demonstrate compliance to their security standards before we could sign the contract. They required us to agree to compliance to 2 government security standards which I'd never heard of, so naturally I got hold of them and read them.  It turned out that one document superseded the other, and stated that both could not be in force at the same time, therefore the customers security policy was invalid as it was contradictory. Their lawyers didn't appear to understand this or be able to do anything about it when I pointed it out to them. We eventually got the contract signed but were still obliged to satisfy both of the security standards (which was impossible).

PPS
To make this subject a bit more concrete I thought of a hypothetical case to test out (based on a real example when I was on the board of a non-profit a few years ago).  A non-profit organisation wants to run a MRM system in the cloud which includes personal details, financial details, and possibly details of children etc.  What regulations apply in Australia and does AWS satisfy them?

E.g. an article.

Here is the summary of APP.

Doesn't mention financial.

And this summary for cloud hosting for non-profits:

If you use internet (or ‘cloud’) based storage systems for your data, as well as adhering to the tips above there are some important issues to consider. Under the APPs, if you outsource data services to a third party provider based overseas – such as a server provider in another country – you must take reasonable steps to ensure that the third party provider does not breach the APPs. Also, if that provider breaches the Privacy Act, you will be accountable for those breaches! CLOUD STORAGE CONTRACT CHECKLIST Consider the steps you can take to ensure you limit the possibility of the provider breaching the APPs, including: ensuring any contract you sign with an overseas service provider requires them to comply with the APPs and contains indemnities against Privacy Law breaches ensuring you understand how a third party provider handles, stores, and deals with data and personal information ensuring you maintain strong access, security controls and procedures over who has access to your data and what they can do with it, and ensuring the third party provider understands your obligations under Privacy Laws.

This is the current AWS APP whitepaper.

Based on the above advice of:

ensuring any contract you sign with an overseas service provider requires them to comply with the APPs and contains indemnities against Privacy Law breaches

I can't tell if the AWS complies with APP and  and contains indemnities against Privacy Law breaches. My guess is that they DON'T provide indemnity against breaches due to their "shared responsibility" model.

And this blog with a legal opinion (2014).


And this inconclusive thread.

An update requiring notification of breaches (which assumes you know).

This appears to be the main credit card standard: The Payment Card Industry Data Security Standard
However, it's difficult to determine if it's applicable in Australia, or the only standard applicable in Australia.

AWS is PCI DSS certified.

P3S
This has made me realise that even though I'm familiar with metrics for some QoS attributes (e.g. performance, scalability, reliability, availability), I'm not sure how people specify and measure metrics for Security goals?   I guess something like: no unauthorised access to customer data in a period of a year; any unauthorised intrusion attempts detected within 10 minutes and remediated within an hour.

Some examples include:

• Process security metrics: E.g. Half-life time for applying security patches < x days i.e. (the time taken to apply security patches of medium or more importance to at least half the population of systems) 
• Malware metrics: Number of viruses, worms, trojans or spams detected and stopped; including median time to detect and stop; % successfully stopped.
• Security Audits: Number of audits conducted in period of time, and risks identified and analysed and status (severity, status, etc).
• IT incidents: Number and severity of breaches (e.g. median time to detect, stop and repair).
• DDOS attack: Impact limited to 1 minutes of timeouts/unavailability, impact in any 1 hour limited to an increase in 95% response time SAL to 5s from normal 3s.

How would these goals be set? Based on current baselines and planned improvement? How would they be detected/measured?  How do these metrics relate to security mechanisms in place? Audits? Compliance standards?

And another thought. We developed a tool and method for the architectural (from early life-cycle artefacts) and run-time (from APM data) modelling and prediction of software performance, scalability and availability metrics.  What's the equivalent body of theory and tool support for doing this for security???  Surely it must exist. Is there a systematic way of composing security mechanisms and determining the overall security metrics for a system? What impact do multiple security mechanisms have on metric values? E.g. What if basic username/password identification is combined with biometrics or token based authentication? What's the expected improvement in security?  What if end-to-end encryption is added?