The person that got access to their system was not an AWS employee when the breach happened. The person got access via a misconfigured server/system that wasn't Amazon's fault.
See the original court case for details: http://regmedia.co.uk/2019/07/29/capital_one_paige_thompson.pdf This is the same as saying it's Amazon's fault that people make their S3 buckets public and information gets exposed. Andras On Wed, Sep 11, 2019 at 12:26 PM Chad Kelly <[email protected]> wrote: > On 9/11/2019 12:00 PM, [email protected] wrote: > > > When someone questions whether this-or-that was predicted, this seems > most > > likely to indicate either the plausibility of the threat, or which side > of > > a closed door the questioner was on when the discussions were held. > > I'd worry less about people placing explosives in servers and more about > making sure that proper checks are in place for the people with access > to information. > > > AWS is a good example of this, they really need to lift their game. > > Stuff like the Capital One incident just shouldn't happen and as a > result of that I am not recommending AWS to any of our customers. > > That isn't the only reason, but the fact Capital One are still with AWS > after that incident scares me a little, if I was them I would of dumped > them as a vendor immediately. > > Basically Datacentres and network operators need to force all staff to > undergo regular checks particularly when dealing with sensitive info. > > I also am aware that the Capital One case isn't Australian, but it is > still a good example of why providers need to keep an eye on who has > access to certain info. > > > -- > Chad Kelly > Manager > CPK Web Services > Phone 03 5273 0246 > Web www.cpkws.com.au > > _______________________________________________ > AusNOG mailing list > [email protected] > http://lists.ausnog.net/mailman/listinfo/ausnog >
_______________________________________________ AusNOG mailing list [email protected] http://lists.ausnog.net/mailman/listinfo/ausnog
