The data breach that recently affected certain customers of Imperva’s Cloud Web Application Firewall (WAF) product was made possible by a series of missteps as the cybersecurity company migrated to a cloud-based database service, the firm’s chief technology officer disclosed yesterday in a blog post.

Collectively, these errors allowed an unauthorized party to steal an administrative API key for one of Imperva’s production Amazon Web Services accounts back in October 2018, CTO Kunal Anand said in his detailed explanation. This key gave the attacker access to a database snapshot containing a variety of information on customers who had signed up for accounts through Sept. 15, 2017, but not afterwards.

Such information included email addresses, hashed and salted passwords and, for a subset of customers, API keys and customer-provided SSL certificates.

According to Anand, Imperva in 2017 begun contemplating a migration to the AWS Relational Database Service (RDS) because its WAF product, then known as Incapsula “was under significant load from onboarding new customers and meeting their critical demands.” However, “Some key decisions made during the AWS evaluation process, taken together, allowed information to be exfiltrated from a database snapshot.”

Creating the aforementioned database snapshot was one of those decisions, as was the creation of an internal compute instance, replete with an AWS API key, that could be accessed externally by users. Consequently, the attacker was able to compromise the instance, steal the key and use it to access the database snapshot.

While the data exfiltration took place in October 2018, Imperva was not aware of the act until last Aug. 20, when a third party sent the company a data set, seeking a bug bounty reward. This third party was unknown to Imperva.

Anand said Imperva has taken multiple steps to prevent future incidents, including: strengthening security access controls, increasing audits of snapshot access, decommissioning inactive computer instances (including the one that was compromised) and placing active compute instances behind a VPN, rotating credentials and keys and fortifying credential management, and increasing the frequency of infrastructure scanning.

The CTO also asserted that the data breach that took place in October 2018 could not happen today because of these improvements in internal controls. He also said Imperva’s new processes would now flag vulnerable compute instances and database snapshots like those that caused the incident.

Anand said that Imperva did not find any other vulnerabilities during its emergency investigation, and is so far not aware of any malicious activity targeting customers who were exposed in the incident.

“We communicated quickly and early in the investigation process to ensure our customers could make informed decisions and act on the security measures we were recommending,” said Anand. “Those recommendations resulted in our customers changing more than 13,000 passwords, rotating over 13,500 SSL certificates and regenerating over 1,400 API keys.”