11–17 of 17 posts
Based on the other thread from yesterday, I wouldn’t jump to conclusions and pin the blame 100% to the former engineer. For such a large company, why the hell did they not put in safeguards to prevent former employees from accessing production environments? The vulnerability wasn’t like a week or two... it was 5 whole months. I read this as incompetence on Cisco’s part.
Earlier quoted context omitted.
> Aren't there protections in AWS For this, in general, the answer is: (1) yes, IAM permissions, and (2) yes, if you configure them, and they often have a cost. > Wouldn't AWS step in and help a company like Cisco if something horrible went wrong? If Cisco asked, probably. But some things are inherently non-trivial to recover from once you've allowed them to happen. AWS can help, but they aren't magic.
Deletion Protection is amazing, but the true way to fix this is to use IAM roles, and groups. Remove the user that is being terminated from the group and 'voila', it is safe.
Why did it take two weeks to recover from this? Aren't there protections in AWS from simply deleting VMs. Wouldn't AWS step in and help a company like Cisco if something horrible went wrong?
Why did it take two weeks to recover from this? Aren't there protections in AWS from simply deleting VMs. Wouldn't AWS step in and help a company like Cisco if something horrible went wrong?
Set the termination protection flag on critical instances (like databases), then they cannot be deleted programmatically. This works really really well.
Well, not accidentally, but the flag itself can be cleared programmatically, so protected instances can definitely still be maliciously deleted programmatically, if the actor has sufficient access.
Earlier quoted context omitted.
Set the termination protection flag on critical instances (like databases), then they cannot be deleted programmatically. This works really really well.
> Set the termination protection flag on critical instances (like databases), then they cannot be deleted programmatically. Well, not accidentally , but the flag itself can be cleared programmatically, so protected instances can definitely still be maliciously deleted programmatically, if the actor has sufficient access.
Earlier quoted context omitted.
> Set the termination protection flag on critical instances (like databases), then they cannot be deleted programmatically. Well, not accidentally , but the flag itself can be cleared programmatically, so protected instances can definitely still be maliciously deleted programmatically, if the actor has sufficient access.
Oh really? I thought the only way was to go to the web UI and and select instances to remove the flag.
Based on the other thread from yesterday, I wouldn’t jump to conclusions and pin the blame 100% to the former engineer. For such a large company, why the hell did they not put in safeguards to prevent former employees from accessing production environments? The vulnerability wasn’t like a week or two... it was 5 whole months. I read this as incompetence on Cisco’s part.
If you leave your front door unlocked that doesn't mean a burglar is free to steal your stuff with no consequences.
This demonstrates Cisco is shockingly incompetent. Imagine if, instead of basically causing them a business hassle, this engineer decided to grab the list of sales contacts for companies -- easily available by looking at who salespeople are meeting with -- and sell those?
It's cisco's job to make this impossible in more robust ways than hoping every employee they have is a good person.
Cisco are also liars, because they've almost certainly made commitments in SOC2 or 27001 or other audits that this is impossible via policy and procedures. And yet.