Deploying New Security Content: The Imperva Process Explained

By Avishay Zawoznik posted 19 days ago

  

closeup photo of eyeglasseshttps://unsplash.com/photos/w7ZyuGYNpRQ
Find out how we identify and respond to new security threats in real-time.

Maintaining data security for an enterprise demands vigilance and hard work. The larger a company, the greater the surface area it presents to attackers is.

For enterprise-level organizations, every application carries a potential for cybercriminal abuse. New vulnerabilities and exploits are coming to surface every day, and it takes a dedicated team to develop solutions to those vulnerabilities in time.

Imperva has earned its place as one of the industry’s most reputable cybersecurity vendors thanks to its dedication to fast and comprehensive content deployment. Our innovative methods and meticulous processes have made Imperva a leader in the cybersecurity space. 

Let’s look a little deeper into what how Imperva’s processes ensure best-in-class security for both cloud and on-premises organizations.

Introducing Imperva Overmind

One of the most important daily tasks we perform at Imperva is addressing new security vulnerabilities in the web applications our customers use. In 2018, over 16,500 new security vulnerabilities were published – that’s an average of 45 new vulnerabilities every single day.

One of the tools the Imperva Research lab uses to catalogue these threats is called Overmind. It is a highly automated, internal portal, consisting of different modules we use to track vulnerabilities, establish rules and follow them up, and manage cyber threats. The system identifies, categorizes, and prioritizes these vulnerabilities by severity and platform popularity so that we can assign the appropriate resources towards addressing them.

This process is the first step of a continuous cycle of security improvement. Once our team knows which vulnerabilities to address first, we can begin the process of developing and validating solutions to those vulnerabilities.

Creating New Security Signatures to Patch Vulnerabilities

There are many ways that a security vulnerability can be discovered and sent to our database in Overmind. We have many different sources that operate within the greater security community to provide us with the latest information about vulnerabilities and exploits.

Whenever enterprises update their applications, be it a change of code, usage of new dependencies or installation of new updates, they expose themselves to new potential vulnerabilities. At the same time, hackers are constantly looking for ways to exploit older systems, often relying on the fact that many users neglect to install the latest security updates to protect themselves.

Our job is to identify and address these kinds of cybersecurity vulnerabilities. When we receive notice of a new vulnerability, we immediately begin the process of categorizing, prioritizing, and mitigating it. Imperva does this by examining the threat and assigning a signature to it.

Once we have a new security signature that corresponds to that vulnerability or exploit method, we deploy it to our cloud-based web application firewall (WAF) and start the follow-up process.  The initial deployment is in “silent-mode”, to collect information without running the risk of blocking legitimate traffic.

Sometimes, it turns out that our system already has a solution in place for that particular type of attack. This means that the vulnerability is similar enough to a previous vulnerability for which we already have a signature in place. In that case, our system catches it automatically.

But Imperva’s cybersecurity process is not purely reactive. We run a variety of proactive processes to catch attack attempts based on malicious behavior, IP reputation, and enforcement of expected input, among other things. 

The “Zero False Positive” approach

False positives hurt business processes. Effective cybersecurity processes must distinguish between authorized and unauthorized use with near-perfect accuracy in order to reinforce operational value.

Enterprise cybersecurity is a dynamic field. Prior to moving any solution from “silent” mode to “block mode”, our team adjusts the content deployment to eliminate false positives and improve results.

False positives are triggered when a signature that should block a vulnerability ends up blocking a legitimate user. This is obviously not the functionality our customers want, so we collect data on all of our security signature performance metrics and analyze them.

All of that data is housed in our Research Lab’s Data Lake system – an enormous and powerful database that runs on Amazon Athena infrastructure. Our team carefully reviews the way our security rules interact with our customers’ applications in “silent mode”, refining them to avoid false positives before “block” mode deployment.

The deployment process can take anywhere from several hours to several days. It depends on several factors, from the urgency of the vulnerability to the quality of the data we can collect about it. Another important factor is the level of certainty our team has over the quality of the rule itself.

Sometimes, the best course of action with a non-urgent security vulnerability involves waiting and collecting as much data as possible on it. Other times, a clear and immediate threat demands the fastest possible response.

In both cases, reducing false positives clarifies the security process and makes it easier for users to accomplish legitimate tasks securely. 

Our Processes Teach Us About Cybercriminal Strategies

One of the most valuable and interesting things about our security content deployment process and using the Data Lake infrastructure  is that it gives us a great deal of information about ongoing cybercriminal global trends

For instance, when Imperva’s team sees a spike in the number of unauthorized bitcoin mining applications trying to run on our customers’ systems, that says a great deal about the priorities and goals of the cybercriminal industry itself.


#CloudWAF(formerlyIncapsula)
#On-PremisesWAF(formerlySecuresphere)
0 comments
1081 views

Permalink