The concept of configuration hardening has nice imagery to it. When we use it to describe battle-hardened soldiers who have been tested in combat, a grim, determined image invariably leaps to mind. The same thing happens when we speak of hardened steel that’s been repeatedly quenched and tempered or of hardened fortifications and bunkers.

But what does this state of “being hardened” mean in the context of information systems? What do we mean when we talk about operating system hardening techniques to repel exploits and withstand intrusions? Much of this is captured in three simple concepts:

1. Ensure a system’s security configurations are appropriately set given the job it needs to do.
   
2. Ensure operating system software, firmware  and applications are updated to stay ahead of exploits that attack flaws in the underlying code.
   
3. Ensure this process runs continually, leveraging and employing as much automation as possible.

What is Configuration Hardening?

Configurations are, in an almost literal sense, the DNA of modern information systems. “Configuration settings” are the attributes and parameters that tell these systems—from servers to network devices and from databases to desktops and applications—how to act and how to behave.

Unfortunately, these systems are made to “do work” and not to “be secure.” In other words, they’re shipped infinitely capable but effectively insecure. Modern computer systems have over 1,000 well-known ports with which to get work done. They also have another 40,000 or so “registered” ports and yet another 20,000 or so “private” ports. These in turn support a vast number of services and processes.

There’s a nice analogy that helps us get our arms around this: If we translate a server’s “ports and processes and services” to the “doors and gates and windows” in a house, we see information systems as unimaginably large, fundamentally porous houses.

Security configuration management

Security configuration management becomes the job of determining which of these doors and gates and windows should be open, closed or locked at any given time.

Of course, this notion of whether something should be “open or closed or locked” is very conditional—it depends on circumstances like “when” or “where.” If I’m going away for a week, I double-check that everything in my house is locked down tight.  If I’m only going to be gone for an hour, I may leave the back door unlocked.

And if it’s the height of summer, I may have an air conditioner in a window that comes right off the front porch. In this case, I’ve knowingly traded an inherent security weakness (I can’t lock that window until autumn!) for comfort.

To drag this analogy back to the modern computer network, we need to amplify our numbers exponentially. The first thing we note is that the number of “configuration items”—doors and gates and windows that need to be monitored and assessed just to achieve a basic level of security—becomes staggering:

• Network device configurations can have an average of 2000 lines of code for each device.
  
• Each device configuration can contain hundreds of parameters for about 20 different IP protocols and technologies that need to work together.
  
• A Fortune 1000 enterprise can have over 50 million lines of configuration code in its extended network.

System hardening best practices

At the device level, this complexity is apparent in even the simplest of “vendor hardening guideline” documents. These are vendor-provided “How To” guides that show how to secure or harden an out-of-the box operating system or application instance. Some examples:

• The hardening guide for Oracle Solaris v11 has 55 of these critical configuration items. (My house has just 30 doors and windows, by comparison.)
  
• The vmWare guide for vSphere 5 highlights 60 critical security items that must be checked
  
• For Windows 2008, the Microsoft guide for minimal system hardening includes 158 settings that need to be immediately secured out of the box (it’s is a big house).

This still falls short of a number of settings that need to be managed in prescriptive guides for information security. Prescriptive guidance comes from sources like the Center for Internet Security’s (CIS) “Benchmarks,” the Defense Information Systems Agency’s “Security Technical Implementation Guides” (DISA STIGs) or NIST 800-53 and the National Institute of Standards and Technology’s “Recommended Security Controlsfor Federal Information Systems and Organizations.”

The degree of “prescriptive-ness” in these standards refers to the level of specific guidance they provide: a non-prescriptive guide like SOX might say “Passwords should be complex.” But prescriptive guidelines like the ones above provide specific values that must be attained for each control.

Compared to the simple SOX standard for passwords, CIS requires passwords that:

• Are at least 8 characters in length for standard enterprises servers
  
• Are at least 11 characters for critical systems
  
• Are changed every 90 days but not more often than once a day
  
• Are different from the previous 24 passwords created by the user
  
• Contain characters from multiple classes: alphabet, numeric, special characters, etc.
  
• Are not saved or stored in any form of reversible encryption

Because of this level of control, prescriptive standards like CIS tend to be more complex than vendor hardening guidelines. Some standards, like DISA or NIST, actually break these down into more granular requirements depending on Hi/Med/Lo risk ratings for the systems being monitored.

It’s worth mentioning, too, that there are dozens more—a veritable alphabet soup of acronyms and abbreviations – that provide guidance across industry segments and areas of interest. “NERC CIP” requirements provide standards for critical infrastructure protection in the energy space, while HIPAA requirements govern systems that store or transmit patient health records. The list is long and covers virtually every industry and nearly every region or country.

In any industry or setting, the discipline of security configuration management seeks to find a balance between security and usability: somewhere between “server passwords are allowed to be blank” and a ridiculous work-stopping requirement like “the system needs to have a new, never-used, complex 30-character password that’s changed every 48 hours” rests that ongoing balance.

via:  tripwire