Imperva, a leading provider of Internet firewall services that help Web sites block malicious cyberattacks, alerted customers on Tuesday that a recent data breach exposed email addresses, scrambled passwords, API keys and SSL certificates for a subset of its firewall users.
Redwood Shores, Calif.-based Imperva sells technology and services designed to detect and block various types of malicious Web traffic, from denial-of-service attacks to digital probes aimed at undermining the security of Web-based software applications.
Image: Imperva
Earlier today, Imperva told customers that it learned on Aug. 20 about a security incident that exposed sensitive information for some users of Incapsula, the company’s cloud-based Web Application Firewall (WAF) product.
“On August 20, 2019, we learned from a third party of a data exposure that impacts a subset of customers of our Cloud WAF product who had accounts through September 15, 2017,” wrote Heli Erickson, director of analyst relations at Imperva.
“We want to be very clear that this data exposure is limited to our Cloud WAF product,” Erickson’s message continued. “While the situation remains under investigation, what we know today is that elements of our Incapsula customer database from 2017, including email addresses and hashed and salted passwords, and, for a subset of the Incapsula customers from 2017, API keys and customer-provided SSL certificates, were exposed.”
Companies that use the Incapsula WAF route all of their Web site traffic through the service, which scrubs the communications for any suspicious activity or attacks and then forwards the benign traffic on to its intended destination.
Rich Mogull, founder and vice president of product at Kansas City-based cloud security firm DisruptOps, said Imperva is among the top three Web-based firewall providers in business today.
According to Mogull, an attacker in possession of a customer’s API keys and SSL certificates could use that access to significantly undermine the security of traffic flowing to and from a customer’s various Web sites.
At a minimum, he said, an attacker in possession of these key assets could reduce the security of the WAF settings and exempt or “whitelist” from the WAF’s scrubbing technology any traffic coming from the attacker. A worst-case scenario could allow an attacker to intercept, view or modify traffic destined for an Incapsula client Web site, and even to divert all traffic for that site to or through a site owned by the attacker.
“Attackers could whitelist themselves and begin attacking the site without the WAF’s protection,” Mogull told KrebsOnSecurity. “They could modify any of the security Incapsula security settings, and if they got [the target’s SSL] certificate, that can potentially expose traffic. For a security-as-a-service provider like Imperva, this is the kind of mistake that’s up there with their worst nightmare.”
Imperva urged all of its customers to take several steps that might mitigate the threat from the data exposure, such as changing passwords for user accounts at Incapsula, enabling multi-factor authentication, resetting API keys, and generating/uploading new SSL certificates.
Alissa Knight, a senior analyst at Aite Group, said the exposure of Incapsula users’ scrambled passwords and email addresses was almost incidental given that the intruders also made off with customer API keys and SSL certificates.
Knight said although we don’t yet know the cause of this incident, such breaches at cloud-based firms often come down to small but ultimately significant security failures on the part of the provider.
“The moral of the story here is that people need to be asking tough questions of software-as-a-service firms they rely upon, because those vendors are being trusted with the keys to the kingdom,” Knight said. “Even if the vendor in question is a cybersecurity company, it doesn’t necessarily mean they’re eating their own dog food.”
It was the Russians.
In Mother Russia, you don’t hack security company, security company hack you.
You’re subject to Carbon 14 dating if you remember that punchline.
You can outsource security (or some part of it) to the Cloud, or wherever you want, but you can’t really outsource the responsibility for it.
Regards,
Exactly. Herein is the rub. You will never know as much about how they do their security as you really need to know. You are essentially abdicating some of your responsibility to them. However when a breach happens pointing the finger will never do any good even if it is their fault entirely.
I am not anti-cloud, but people need to be aware there are increased risks when you involve other companies to handle some part of your companies security with little knowledge of their internal (real-life) security practices.
And everyone is fallible so it is not if a breach happens, but when it happens what will be your response?
–“people need to be aware there are increased risks when you involve other companies to handle some part of your companies security with little knowledge of their internal (real-life) security practices”–
100% agreed. What annoys me is that a lot of companies consider cloud low-risk because, in essence, they’re transferring the risk to another entity. In my opinion, this couldn’t be further from the truth. At the end of the day, regardless who has responsibility or governance over an asset, the originating company still has employees and employee data to worry about–even if that company is not in charge of a particular asset where that data is stored. There still will be some form of impact, be it reputation-based, regulatory-based, compliance-based, etc. “Transferring” the risk to the cloud just simply doesn’t exist.
“You will never know as much about how they do their security as you really need to know… You are essentially abdicating some of your responsibility…” – James Golden
Good point James Golden.
There of hundreds or thousands of details to be known about various cloud platforms. Currently, it is extraordinarily difficult or impossible to know all security risks in some other corporation’s cloud platform. This is particularly true of mission critical data and highly confidential data – banking data, real property data, medical data, lawyer/client data and the security in an evolving “cloud” platform.
It will take years of mistakes and customer learning, and possibly some lawsuits to get all risk factors under control.
It is one thing to run a news web-log and expand it quickly in a cloud environment. It is completely different to actually manage mission critical data and know all of the risks and risk mitigations successfully.
In the future those risks will probably be solved – but not at this current point time.
Sure, the “cloud” can expand rapidly and fairly safely for non-mission critical data but for mission critical data it will take years mistakes and learning from mistakes to do it successfully.
Those individuals in control of people’s mission critical data should think long and hard before rushing into the “cloud” environment without having a thorough understanding of the all risks.
One of the most concise replies on this subject and one which I believe many enterprises don’t fully face up to. Too much “trust” is given to these Sec AAS companies without doing the proper due diligence. In the end it is you as the Enterprise that will be held responsible by your customers and no matter what SLA or contract you try to fall back on it is ultimately your responsibility to your customers and with it your own reputation.
You can offload the BAU work never the responsibility.
The Cloud is just a term for someone else’s computer……and it’s your responsibility to make sure it is secure….
Check all of Imperva’s API docs (for both cloud and on-prem stuff). No Oauth to be seen anywhere. API IDs and Keys only….. . widely known in the API world to offer nothing in the way of API security. One wonders how an infosec company can overlook such an important and well known aspect of digital security.
Very embarrassing for them. Just recently there was another embarrassing incident in the industry: “Ransomware Hits Dental Data Backup Service Offering Ransomware Protection”.
This does the industry protection firms very little good in the way of public confidence. The cloud, in my opinion leaves much to be desired. I would be very careful about having mission critical data there.
But that said, we must continue to learn through such incidents as these. and work to perfect our craft.
Check all of Imperva’s API docs (for both cloud and on-prem stuff). No Oauth to be seen anywhere. 100% agreed. What annoys me is that a lot of companies consider cloud low-risk because, in essence, they’re transferring the risk to another entity.
Best,
Helena