Newsletter #7: The Reality Of Attribution In An Incident
First of all, I’d like to wish you and your families happy holidays!
One reality of a security incident is that you may not always know who the attacker is. With the anonymity of the internet, the ubiquity of third-party applications getting breached and accessing your info and APIs with access anywhere and everywhere, the attack surface is large.
One time, I was asked to try to find out who attacked a company’s AWS Account after the fact. An AWS root key was used in the attack, but they quickly identified it and deleted the key.
After reviewing the Cloudtrail logs, it turned out that the attacker executed their attack from a Tor exit node. Since they used Tor and their user-agent had no other unique properties, there was no other way to identify the attacker. I tried looking for mistakes they may have made using the key from another location, but all dead ends.
What I’m trying to say is that it’s a fact of life: you may not know whoever attacked you. However, there is so much you can do to prevent this or increase the chances to identify someone.
Here is a few things you can do:
- Eliminate sharing of user accounts. Every human should have a unique ID.
- Reduce the use of shared/service accounts. More on that here.
- Ensure you have adequate logging on all authentication and privileged actions
- Deploy or move towards a Zero Trust Model in your organization
Of course, if you don’t already, look into publishing an Incident Response plan and even conducting a Tabletop exercise to practically test your organization.
Take care,
Ayman
This article was previously posted in the Newsletter.
If this article was helpful to you, consider subscribing to my weekly newsletter, where I share my latest commentary as a vCISO for high growth startups.
Check out how we help startups accelerate and level up their security programs through vCISO (CISO As A Service) and DevSecOps As A Service.
