Cloud Not Secure As Rob Alexander(CapitalOne-CIO) Believes

Rob Alexander is CIO of Capital One and was very proud of his move to AWS

http://t.co/ix9TamNPAW  here is one of his slides touting the his efforts.

awsreinvent-slide

“We can provide higher security with AWS than with our own data centers”

They are developing  new mobile and web apps to connect to your bank account

“Mobile is the new Wallet” was in the 7min video of Rob Alexander at invent2015.

 

As a counterpoint …   I found the following Slides from the Bsides Vienna conference:

https://github.com/BSidesVienna/bsidesvienna.github.io/blob/master/slides/2015/the_aws_survival_guide.pdf

 

Here is official Amazon wording on support page:

“No matter how carefully engineered the services are, from time to time it may be necessary to notify customers of security and privacy events with AWS services. We will publish security bulletins below.”

https://aws.amazon.com/security/security-bulletins/

Most interesting slides from Bsides:

awsnetwork

So AWS is set in a 10.0.0.0/16 VPC (Virtual Private Cloud)

there are no broadcasts or multicasts and no IPv6  yet.

 

The key with AWS is the IAM or Identity Access Managment.

users are managed in Groups

AWS services are assigned Roles

Policies define permissions

 

S3, EBS, RDS,…

Transparent Key management

Technologies and AWS account per team

OAuth for internal and external communicaiton

 

Now we get the actual security incidents on AWS (from Bsides)

codespacesisdownonaws

I also found some headlines from this Code Spaces failure:

http://arstechnica.com/security/2014/06/aws-console-breach-leads-to-demise-of-service-with-proven-backup-plan/

All we need is to look at the first sentence  in the article”A code-hosting service that boasted having a full recovery plan has abruptly closed after someone gained unauthorized access to its Amazon Web Service account and deleted most of the customer data there.” to know that there was a major failure of a “backup” company on the cloud.

There are plenty of articles on how Code Spaces failed to live up to its own marketing message:

http://www.csoonline.com/article/2365062/disaster-recovery/code-spaces-forced-to-close-its-doors-after-security-incident.html

In this article we find out what happened:

“However, the issue was much larger than a sustained DDoS. In fact, the reason they were able to contact the attacker in the first place is because they left contact details within Code Spaces’ Amazon EC2 control panel.”

The DDoS was a part of the attack, but not the main attack. And once the attack was being noticed and mitigated the attackers continued with their mischief:

“Code Spaces moved to regain control over their Amazon accounts, but the attacker had already taken steps to prevent this.The intruder created backup log-ins on the EC2 panel and when recovery efforts were noticed, they started to delete artifacts at random.  ”

 

And this is my favorite quote (albeit obvious)…

In a statement, Patrick Thomas, security consultant for Neohapsis, said that for companies using cloud services as part of their business, “this is the nightmare scenario.”

But unfortunately Code Spaces was not the only company:

drawquestannouncement

Again the AWS cloud main account was compromised and the following happened:

“The person(s) used our account to order hundreds of expensive servers, likely to mine bitcoin or other cryptocurrencies.”

(If one loses the main controlling account access this can happen easily)

there is much more to the DrawQuest failure: http://chrishateswriting.com/post/74083032842/today-my-startup-failed  Chris Poole has a blog that discussed the failure of DrawQuest as a startup.

His words from the blogpost link above: “It may seem surprising that a seemingly successful product could fail, but it happens all the time. Although we arguably found product/market fit, we couldn’t quite crack the business side of things.”

 

It is interesting that Chris Poole did not mention the hack that helped fail his startup: http://chrishateswriting.com/post/84931829578/when-a-bad-day-gets-worsegetting-hacked-twice-in  from a previous post.

they made significant architectural errors in devising the app.  Apparently not enough (if any) security testing.

And this is the final nail in coffin: “To make an already long story short, when leaving the company a few months ago, one of our developers asked to open source a project he had worked on. You can probably already guess where this is going, but suffice it to say he did so by flipping the existing repository to public.”

 

When a developer does such a boneheaded move he basically killed the company. (my words).

 

One more company (unfortunately):

Bonsaiserviceoutage

Notice the Incident report mentioned the compromise of an API key.

 

 

So we know if your defense is dependent on IAM (Identity Access Management), but also internal design of an app can cause security problems.

This concept of testing the applications for security must be drummed into everyone.

systemengineeringassecurity

Contact Us to help you explain this.

 

 

 

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.