SummitRoute/csp_security_mistakes

Personal capacity?

seriousme opened this issue · 3 comments

https://github.com/SummitRoute/csp_security_mistakes#aws-aws-employee-posts-customer-access-keys-and-information

The Register reports:

A spokesperson for Amazon has told us the code repository was used by the engineer in a personal capacity, and claimed no customer data or company systems were exposed.

https://www.theregister.com/2020/01/23/aws_engineer_credentials_github/

would include this. Shows a lack of security controls for AWS employees if they can use repos outside their approved env.

Question is whether the data was leaked using his company credentials?
If I would work for AWS (which, for the record, I do not) and I post data from my private AWS account on GitHub then it wouldn't be a lack of AWS security controls. If I would post AWS customer data that I obtained using my AWS company account then it would definitely be a lack of AWS security controls!

So the context does matter in my view.

The situation is not entirely clear, with Upguard possibly portraying the situation as being worse than it was, and AWS possibly trying to make it look less severe to save face. We have to consider that Upguard possibly incorrectly identified what they saw or possibly were misleading to gain reads, and equally that AWS's legal or public relations may be trying to mislead us. For example this statement from Chris Vickery:

Of course AWS tried very hard to claim “nothing to see here”, but I personally reviewed the files. There was much to see there.

It seems everyone is aligned that an AWS employee had a public github repo with contents that should not have been public, as AWS does not try to argue that point. The point of contention is what the contents were. At one extreme this may have been AWS customer data and at the other extreme just the individual's personal data, with the possibility of something in between existing.

It seems apparent that "Amazon Confidential" data was included in the repo as Upguard included a screenshot of this in their post and AWS's statement only argues that "no customer data or company systems were exposed".
image

Now if this is just internal training materials then that is not too concerning, but is still an incident as exposure of confidential information is an issue I would include this repo, maybe with just a low severity though.

However, Upguard's post also mentions the following:

  • "mentions of hostnames to identify likely AWS customers being assisted by the engineer"
  • "Other files contained collections of auth tokens and API keys for third party providers. One such file for an insurance company included keys for messaging and email providers."
  • "correspondence with AWS customers"

Depending on definitions, AWS can claim that is not "customer data", but this seems like a noteworthy incident to me. I've added some text to the issue to identify that it is not entirely clear what happened: 9ffda19