I'm aware that Capital One was found guilty of not properly securing customer information when they started moving it to "the cloud" (AWS). I'm also aware that the person who orchestrated the data breach, by exploiting the bank's AWS (mis)configuration, had been hired by Amazon as a developer. Maybe the bank's IT staff created "cloud custodian" after the incident.
Custodian was already there , they have a strict pipeline but what I hear is that the environment where the hack took place was bypassing the normal organisational pipe governance and did not even have coverage of the custodian on the account. Basically shadow it. I still put a lot of blame on the way AWS Iam makes it incredibly hard to stop the use of the credentials outside the vpc in the event they are stolen , for example source ip restrictions do not work if the bucked it using kms encryption because kms will decrypt on users behalf appearing to come from a different ip than the user . The called via is a farce that only work with about 4 services out of hundreds and the meta data v2 with its ip level TTL is a marketing gimmick
Thanks for sharing this. Looks like a sophisticated solution, although might be too complex and enterprise-y for what I needed as a sleepy developer, but is definitely worth having a look :)
https://www.marketwatch.com/story/capital-one-fined-80-milli...