Imperva Breach Update: Stolen AWS API Key Triggered The Breach

It has been over a month since the cybersecurity firm Imperva suffered a breach, we now have an update. As revealed recently by the company’s CTO, the firm suffered the breach due to the stolen AWS API key.

Update On Imperva Security Breach

Recently, the Chief Technology Officer of Imperva, Kunal Anand, has shared details about the security breach that hit the firm more than a month ago. As revealed through the update, Imperva suffered the breach owing to the stolen API key of Amazon Web Services (AWS).

As revealed via a detailed post, the main cause of the recent breach links back to the breach that happened in 2017. Elaborating some of the actions the company took at that time, the CTO reveals an inadvertent lapse that arose. The company took a database snapshot for testing purposes that allowed data exfiltration.

Some key decisions made during the AWS evaluation process, taken together, allowed information to be exfiltrated from a database snapshot. These were: (1) we created a database snapshot for testing; (2) an internal compute instance that we created was accessible from the outside world and it contained an AWS API key; (3) this compute instance was compromised and the AWS API key was stolen; and (4) the AWS API key was used to access the snapshot.

Eventually, this led to the subsequent data breach in August this year that affected the customers. However, it is now apparent that the breach was not the result of any vulnerability in Cloud WAF or any other product.

Actions Taken By Imperva

Following the incident, the company began thorough investigations into the matter. And now, they have shared the details with us, including the stolen AWS API key. Initially, these details remained unstated in their previous disclosure.

Regarding the corrective actions that Imperva implemented, the post reads,

The steps we have taken since this incident to improve our security protocols include: (1) applying tighter security access controls; (2) increasing audit of snapshot access; (3) decommissioning inactive compute instances; (4) rotating credentials and strengthening our credential management processes; (5) putting all internal compute instances behind our VPN by default; and (6) increasing the frequency of infrastructure scanning.

While the company assures no such incidents to happen in the future, still, they believe “Security is never ‘done’”. And so, they will continue to review their systems for adequate security.

Let us know your thoughts in the comments.

Related posts

Apple Addressed Two Zero-Day Flaws In Intel-based Macs

Really Simple Security Plugin Flaw Risks 4+ Million WordPress Websites

Glove Stealer Emerges A New Malware Threat For Browsers