Perhaps it is more appropriate for us to approach configuration management as an assurance process meant to ensure system integrity is maintained over time. By evolving our view of how to establish and control the integrity of the different devices and technologies in use, the concept of “configuration management” evolves to become more about “configuration assurance.”
The Need to Manage Configuration
When considering the different aspects of information security program management, few topics are of as much importance to an organization’s overall security posture as the topic of “configuration management.” This is due, in part, to the number of different standards and processes that typically comprise or govern a configuration management program. And, it is usually the lack of governance or enforcement of configuration management practices that lead to system and information compromises.
When we look at configuration management, it is important for us to keep in mind that what we’re really addressing is the “I” of InfoSec’s “Confidentiality, Integrity, and Availability,” or “C.I.A.” Because of this, we should understand each of the different parts that make up a configuration management program or process, and further understand them as part of an overall process for ensuring the integrity of any given device or system. Ultimately, the basis for establishing and verifying the integrity of a device or system needs to be consistent with the information security standards defined by the organization, industry best practices, industry or governmental regulation, and relevant legislative requirements.
The Basics of Configuration Management
The objective of any meaningful configuration management program is a security-minded framework within which all information systems can be tracked, classified, reviewed, analyzed, and maintained according to a consistent set of practices and standards. Configuration management programs usually incorporate several different standards and processes to address the diverse aspects of information security, such as standard build/configuration documentation and processes, antivirus monitoring, patch management, vulnerability management, asset management, etc. Essentially, it comes down to having lot of eggs that ultimately wind up in the same basket, with the objective being that none of the egg shells get broken.
At a high level, the functional and security requirements for most of these programs and services are fairly well understood. It is common for organizations to treat each of the different aspects of configuration management as stand-alone programs or processes. However, reality is quite different. In addition to ensuring that a configuration management program addresses all of the relevant security requirements, it is also equally necessary to understand how each individual security process or program relates to other security processes or programs. Why? Because each of the processes associated with configuration management impacts other processes related to configuration management. The manner in which these interrelationships are addressed (or not addressed) may expose significant risks in critical or sensitive information systems.
Regardless, many organizations still tend to approach delivery of these programs and services as individual and somewhat isolated or unrelated processes. This is especially true for organizations that heavily focus on meeting compliance requirements without embracing the larger concept of “information security.” This is also true in organizations where information security programs are less mature, or if there is an over-reliance on technology in the absence of formal documentation.
Where the Gaps May Lie
Following are a couple of examples where gaps might typically occur in the configuration management process. After each example, I’ve put together a few follow-up questions to help explore each issue a little more in-depth.
A. Auditing and Log Monitoring – Most security policies and system configuration standards tend to address audit and logging requirements at the operating system level. However, operating system audit log services are not always capable of capturing detailed audit log data generated by some applications or services. As a result, it may be necessary to combine and correlate multiple audit log data sources (perhaps from multiple devices) to reconstruct a specific chain of events. All business processes should be reviewed to ensure that the full complement of required audit log data is being collected and reviewed.
- Do your policies, standards, and processes ensure that all required security audit log data is collected for any and all firewalls/routers, workstations, critical/sensitive applications, databases, monitoring technologies, and other relevant security devices or technologies used in the environment?
- Do policies or standards require audit log data collection to include audit log data from all antivirus endpoints, file integrity monitoring endpoints, IDS/IPS alerts and events, security devices or applications, and file or database access?
- Is all audit log data, of all types, collected to a single or centralized source(s)?
- Is all audit log data backed up regularly (at least daily) and protected against unauthorized access or modification?
- Is audit log data from one source combined and correlated with audit log data from other devices or services to reconstruct specific activities, identify complex attacks, and/or raise appropriate alerts?
- Has your organization performed any testing or forensic activities to verify that audit log information currently being collected is sufficient to raise appropriate alerts and reconstruct the events related to any suspicious activity?
B. Standard Build/Configuration – It is commonplace for organizations to have standards documentation describing how to install and configure the different kinds of operating systems (and sometimes databases) used in the environment. However, it is not quite so common to have similar documentation (or similar level of detail) when it comes to some specialized technologies or functions. As we are all aware, a secure technical environment is reliant upon more than just securing the operating systems and extends to all devices in use. Policies, standards, and processes should exist to address all technologies used in the environment and should define how to establish, maintain, and verify the integrity of any device or application intended for use within the environment.
- Do documentation and processes currently exist to define the secure initial configuration of all technology device types and applications in use in the environment? This includes technologies or devices such as firewalls, routers, servers, databases, mainframe/mid-range, wireless technologies and devices, mobile computing devices (laptops and smartphones), workstations, point-of-interaction devices, IVR systems, and any other technologies related to establishing, enforcing, or monitoring security posture or controls.
- Are configuration standards cross-checked to ensure that all relevant information security subject areas are addressed or appropriately cross-referenced? For example, do OS configuration standards include details for installing antivirus or other critical software (FIM, patch management, etc.)? If not, is a reference provided to supporting documentation that details how to install antivirus or other critical software for each specific operating system type?
- Do documentation and processes currently exist to define not just the secure configuration of the base operating system, but also to define a minimum patch level or version a system must meet (e.g., “Win7 SP2” or “Apache version X.X.Y”) before being permitted to connect to the network environment?
These are clearly not all of the possible intersections or gaps that might occur in how an organization approaches configuration management. In developing an information security program, each organization will need to identify the relevant services, processes, and programs that represent how configuration management is achieved. As part of a process of constant improvement, the next logical step would then be to take a closer look at the internal process interrelationships and try to identify any gaps that might exist.
Where to from here?
By evolving our view of how to establish and control the integrity of the different devices and technologies, the concept of “configuration management” evolves to become more about “configuration assurance.” Instead of approaching configuration management as a somewhat unregulated process kept in check by periodic review (audit), perhaps it is more appropriate for us to approach configuration management as an assurance process meant to ensure system integrity is maintained over time.
In the end, one of the biggest enemies of information security is time. Because even if you have bullet-proof security controls in place today, they will probably not offer much protection against the vulnerability/exploit that a hacker will identify tonight or a vendor will announce tomorrow (or Tuesday).