Lessons Learned from the Imperva Data Breach
by Sarah Harvey / November 11th, 2019
In August 2019, a third-party bug bounty discovered a data breach that exposed email addresses, hashed and salted passwords, API keys, and TLS keys for a subset of Imperva’s, a leading provider of Internet firewall services, cloud WAF users. This proves that no matter the vendor, you must perform your due diligence to ensure your own security won’t be at risk by working with a certain vendor – even if that vendor is a cybersecurity provider. So, what exactly happened at Imperva? Why should it matter to you? What lessons can you learn from it? Let’s discuss.
What Happened at Imperva?
The Imperva breach occurred because an unauthorized user stole an administrative API key in a production AWS account. Imperva states that when they were migrating to AWS RDS, “Some key decisions made during the AWS evaluation process, taken together, allowed information to be exfiltrated from a database snapshot.” The major issues that we see are the following, which began in 2017:
- “We created a database snapshot for testing.” Imperva didn’t do data hygiene and clean out legacy data or have a data life cycle management. Did they really need backups from two years ago?
- “An internal compute instance that we created was accessible from the outside world and it contained an AWS API key.” Imperva’s perimeter was not secure, which is odd – you would think a penetration test would have detected that instance. You should never be able to access internal instances directly from the Internet.
- In audits or penetration testing, organizations simply don’t want to test their test environments, but this is problematic because there could be a vulnerability in the test environment that compromises the production environment. Or, what if there’s live data in the test environment? Not performing securing testing in the test environment could jeopardize that data.
- Was Imperva actively trying to prevent cloud sprawl? You have to know what’s in your cloud environment otherwise it will bite you. The point of entry was a system they simply forgot about that was not properly secured. During our audit engagements, we often find that organizations do not know about the presence or functionalities of systems – they set it and forget it, or test it in AWS and forget it, to later be found by a hacker.
Why Should What Happened at Imperva Matter to You?
Are you a SaaS provider? Do you offer managed IT services? Or, does your organization partner with an MSP or a SaaS provider? If so, Imperva’s data breach should matter to you. Why? Because Imperva’s breach is the perfect example that hackers do not discriminate who they target – even experts in cybersecurity can be compromised – which means your organization can be impacted, too. According to IBM’s 2019 Cost of a Data Breach report, “If a third party caused the data breach, the cost increased by more than $370,000.” So, when partnering with SaaS providers or MSPs to outsource your organization’s information security program, it is critical that you perform your due diligence and form some type of vendor compliance management program to ensure that the entity you’re working with implements best practices. On the other hand, the breach also highlights that SaaS providers and MSPs must ingrain security in their development and implementation processes. When companies rely on SaaS providers or MSPs to manage their sensitive data, they’re expecting it to remain secure. What happened at Imperva will likely happen again, but there are some lessons we can learn from the data breach.
Lessons Learned: AWS Best Practices
Imperva cites sixes corrective actions that they are actively performing:
- Applying tighter security access controls
- Increasing audit of snapshot access
- Decommissioning inactive or non-critical compute instances
- Rotating credentials and strengthening credential management processes
- Putting all internal compute instances behind VPN by default
- Increasing the frequency of infrastructure scanning
These controls and processes are valuable to any organization protecting data, but especially valuable in preventing a security incident. These corrective actions, plus best practices like testing your incident response plan, using penetration testing for security incident analysis, and daily checks of S3 buckets are critical when recovering from a security incident.
All in all, you need to know what you have and test it. Want to learn more about securing your AWS environments? Contact KirkpatrickPrice today to work with cloud security experts.
