The Stagnated Culture of Compliance

Anyone tasked with managing security for a large organization is familiar with the established “best practices” espoused by organizations such as ISACA and SANS. The basic approach is to scan, assess, report, remediate or patch, and verify.

The problem is that most organizations get bogged down in the “scan-and-patch” cycle, yet the increase in data breaches has proved this approach to be less than effective. It’s not that it’s a bad approach — after all, you need to scan systems to identify vulnerabilities and you must find some way to remediate the issues. The problem is that, while hacking techniques have evolved, the best practices approach has stagnated. There needs to be a balance between operational risk and security risk. While patching systems may lower security risk, it can raise operational risk, sometimes to unacceptable levels, as anyone who has ever had to back out a patch can attest.

In the early days of the internet, there were no best practices for security. No certifications to demonstrate security knowledge and no compliance requirements to follow. In those days, IT professionals — usually systems administrators — had to figure it out for themselves. The solutions they came up with were pretty finely tuned to their environment and needs.

Today, we have a plethora of security standards, compliance and regulatory requirements, certifications, and best practice guidance. It seems you can’t turn around without getting hit with a new compliance initiative or certification. Many of the compliance initiatives overlap, but organizations have to run through the checkboxes of some fairly rigid requirements. The same goes for security certifications. Any skilled IT professional who has taken one of the many certification exams knows that to pass the exam, you may have to answer some questions “wrong” — give them the answer they want, not the one your experience tells you is correct, which really speaks to the actual value of some of these certifications.

We’ve created such a governed and stagnated culture of compliance and rules that solutions always seem to be presented — usually by product vendors — but we do not question those solutions, which cripples any real innovation.

The concept of a “hacker” is really all about innovation. Hackers have no rules or compliance structures to govern how they are supposed to interpret a security construct, whether it be hardware, software, or the people themselves. They look at how a piece of software is “supposed to work” and turn it on its head to figure out innovative ways to make it do things it wasn’t designed to do. Like, say, open a pathway to a privileged service. Real hackers don’t concern themselves with certifications or worry about complying to an ISO audit. All they care about is if their hack can succeed — and they’re relentless in this pursuit. This has proved distressingly effective.

Scanning and Patching Isn’t Enough

Vulnerability scanners are useful tools to quickly get a snapshot of your organization’s security posture, but they don’t tell the whole story and they certainly don’t accurately evaluate the risk specific to your organization. Run a scan and you will likely get hit with a ton of vulnerability data marked “Critical,” “High,” “Medium,” and “Low.”

The security industry largely uses the Common Vulnerability Scoring System (CVSS) to rate the severity of a vulnerability, but this evaluation lives in a vacuum that doesn’t know anything about your business or infrastructure. CVSS scoring has an “assume the worst” approach. The severity of vulnerability scan data ought to be used as a starting point for risk analysis, but far too often it’s used as indisputable fact. We’ve become “script kiddie auditors,” taking vulnerability scan data as gospel truth and then frantically trying to patch everything.

We seem to have forgotten that these were built to be tools to assist security professionals in gauging the security posture of an organization, and required intelligent analysis to interpret their results. Instead, the results are considered gospel truth. So we scan and patch, rinse and repeat. Add to this process the pain of trying to get your developers and business units to collaborate on remediation and it’s no wonder organizations struggle to make any headway in security.

Risk Triage

Fortunately, there’s a better way. Instead of using the shortcut “scan and patch” approach and focusing on vulnerability data, think about what you are trying to protect and why you are trying to protect it. Risk analytics involves a lot more than just vulnerability scan data. First, you need to know what and where your critical data is. A “Medium” severity vulnerability finding on an asset containing critical data, such as SSN or credit card numbers, is a lot more serious than a “Critical” severity on public marketing content. Don’t just look at a vulnerability on its own — you have to consider aggregated risk across a number a vulnerabilities.

It’s also important to realize that vulnerability scan data is just one of many inputs that needs to be intelligently analyzed. There’s also configuration data, third-party libraries, manual tests, network configuration, log data, and data from application analysis to consider. That’s just the data on your network – you also have to apply threat intelligence to understand what attackers are targeting and which exploits are actively in use.

All of this data needs to be correlated and analyzed, but it’s also important to involve the people with the appropriate expertise. Sure, a security analyst can look at a vulnerability and understand the technical impact, but the developer or business owner will have greater insight into the impact to the business if the vulnerability is exploited. Developers and business owners main priority is functionality and features with security a distant third at best. They need to be part of the security analysis so that the CVSS severity ratings of vulnerabilities are appropriately weighted with the business risk of the asset. This way, you can focus on remediating the vulnerabilities that pose the greatest risk to the organization — not necessarily those that CVSS identifies.

Using complementary security tools and services, combined with ensuring that people with the appropriate expertise are involved in the process is the best approach to breaking the “scan and patch” cycle. There needs to be a focus on what mitigation is the most practical, effective, and causes the least operational risk: patching is not the only method to lower security risk. Technologies such as firewalls, intrusion prevention systems, and configuration hardening can reduce security risk without raising operational risk of patching. It’s a lot easier to back out a firewall change than a patch.

Can’t See the Risk for the Data

Security organizations are so flooded with vulnerability data that they can’t see the bigger picture — the real risks to their critical assets. A skilled attacker exploits this by sending so many attacks that the actual threat is lost in the noise. Threat intelligence is necessary to ensure that management has accurate information about current activities that affect the services the organization offers and the type of industry they are in. Threat data needs to be tuned to filter out the noise and the best way to do this is to tie the threats to the critical data that you are trying to protect. CVSS provides the ability to include environmental and temporal metrics to refine the score based on the organization’s risk evaluation of confidentiality, integrity, and availability of the asset. This can only be determined by collaboration of the organization’s security analysts with the developers and business owners.

Think Like a Hacker

A true hacker is not some script kiddie running an exploit against any systems that are vulnerable, but someone with the skills to think creatively. A hacker’s approach is to perform reconnaissance on a business to determine the weakest point to attack that will draw minimal attention, while providing the best chance of success. A skilled attacker will research the critical assets — both data and personnel — to your organization. This approach is often referred to as “advanced persistent threat,” which really just means a skilled, targeted attack that is tailored to a particular target.

This is the type of risk assessment that you should be performing. Don’t just run tools to find vulnerabilities, but consider social media such as LinkedIn profiles of your security staff and management. Do they give away too much information about your organization’s defenses? At the very least they identify the people who may be of interest to an attacker. You want to make sure that their network access is pretty closely monitored, since it’s likely a point that could be used to bypass network security defenses. People are far less secure than the security technologies they employ and do not come with a patching option.

There’s a tendency among security technologists to think in terms of black and white — that a vulnerability rating of 10 will have the same effect in every environment. The reality is that the rating is a one-dimensional piece of a three-dimensional puzzle that needs to be weighed with other factors, mitigating controls, ease of exploit, along with business and operational risk. Run the software, and run your security programs. Don’t let them run you.