Proactive System Hardening: Continuous Hardening’s Coming of Age

The first article in this series examined configuration hardening—essentially looking at ports, processes and services where security configuration management (SCM) is key. The second article looked at application and version hardening strategies. This third installment will discuss the role of automation in the coming of age of what’s called “continuous hardening.”

Known Vulnerabilities vs. Conditional Vulnerabilities

If I want to harden my systems against “known vulnerabilities”—weaknesses or deficiencies for which there are known common vulnerabilities and exposures (CVEs)—I use a vulnerability management solution. If I need to harden my systems against “conditional vulnerabilities”—weaknesses based on the way they’re configured—I use an SCM solution. But without automation to provide the element of “continuousness” to these efforts, we rapidly find ourselves back at square one.

What is Configuration Drift?

To stick with our house analogy: If I’ve checked the configurations of all my doors and windows, but I have no way to know when the state has changed and I instead rely on periodic inspection by human eyes, a phenomenon known as “configuration drift” invariably occurs.

I open the fire escape window to water the potted hydrangea sitting out there but forget to close it afterward: configuration drift. I enable Telnet to maintain or update a server and then forget to disable it afterward: configuration drift.

The Role of Automation in Continuous System Hardening

A primary weakness of our house analogy is actually useful here, as it shows us the critical need for automation. In real life, most people have one house. But most organizations have hundreds—if not many, many thousands—of servers, desktop systems, laptops and devices. These represent an almost inexhaustible supply of attack surface and potential beachheads. How can we win a war at this scale?

Automation requires us to not only create continuous, ongoing routines to assess states across this vast array of targets, but it also requires us to make allowances for the constantly changing conditions that give meaning and relevance to risk.

In the case of our house, it’s useful to know that, over the last two years, the leafy maple out back has grown a large solid branch that’s close enough to an upstairs bedroom for a tall thief to reach the window. And the inverse is sometimes true: If the old kitchen window was painted shut twenty years ago, who needs to waste time including it in our daily “is it locked” checklist?

This critical need for current “state” information has caused the security community to create more persistent real-time agents, more effective scanning processes that are “aware” of network constraints and ways to avoid “mega scans” in favor of continuous segmented scanning.

Integrating Disparate Security Systems

They’ve also broken down barriers between infosec solutions themselves and addressed another critical requirement for achieving this attribute of “continuousness”: Information security systems must talk to one another. A few simple examples illustrate this need:

  • Vulnerability Management: Vulnerability management (VM) systems are quite good at finding unexpected (and likely unsecured) systems. When one of these is discovered, the VM system can tell the SCM system about the new asset and ask it to perform an on-the-spot configuration assessment.
  • Security Configuration Management: Similarly, SCM systems are evolving intelligent ways to classify assets: by business unit, by system owner, by critical application, and even by the type and criticality of data stored on the system. This helps manage and prioritize their own risks, but when shared with a VM system, this also helps clarify and prioritize remediation efforts.
  • Security Information and Event Management: Both of these systems are being used extensively by SIEM systems as a foundational source of security information: in the first case, correlating known vulnerabilities with detected threats, and in the second case, using sudden configuration changes (“Why is the ‘Telnet should not be enabled‘ test suddenly failing?“) to power real-time threat intelligence models.

SC Magazine summed up these needs in a prescient review of policy management systems—what we’ve called “security configuration management” systems in this article—way back in 2010: “The only reasonable answer to the challenges of compliance, security and configuration management is to automate the tasks.”

The key to continuous system hardening as a goal and a discipline is a willingness to seek out and employ automation wherever possible. Gone are the days when isolated, siloed systems can harden information systems and keep them that way in the face of continuous drift.

Highly interactive solutions that understand the ever-shifting nature of “state” and talk to each other regularly—security configuration and vulnerability management solutions in particular—are the first, best and often the last line of defense.


via:  tripwire

Save pagePDF pageEmail pagePrint page

Leave a Reply

Your email address will not be published. Required fields are marked *