The Common Security Framework Foundation: Addressing Configuration Controls
We have entered the era of multiple security frameworks. Sometimes mandatory, often voluntary, security frameworks are created to provide federal and commercial organizations with an effective roadmap for securing IT systems. The goal is to reduce risk levels and prevent or mitigate cyberattacks.
To accomplish this task, security frameworks typically provide a series of documented, agreed to and understood policies, procedures, and processes necessary to secure the confidentiality, integrity, and availability of information systems and data.
In the United States, the overarching framework is the National Institute of Standards and Technology (NIST) Cyber Security Framework. As part of the Department of Commerce, NIST is responsible for developing technical standards and guidelines for information security, among other things. Although the NIST standards apply to U.S. federal agencies and critical infrastructure, they’re also widely used throughout the private sector.
In addition, specialized frameworks are less comprehensive and address specific aspects of information compliance. HIPAA, for example, provides security requirements to protect patient privacy; PCI in the retail sector addresses credit-card processing, FedRAMP covers federal cloud standards, and the energy sector relies on the NERC Critical Infrastructure Plan. The list is long, and today even individual states are adopting their own cybersecurity frameworks (i.e., NYDFS).
If there’s a drawback to security frameworks, however, it’s that most provide a “30,000-foot view” of information security. Most identify potential risks as well as how to protect, detect, respond, and even recover from cyberattacks. Specific implementation steps, on the other hand, are rarely addressed.
However, there’s one critical exception. At the core of most, if not all, the frameworks are a set of security-related controls that affect the security posture and/or functionality of the system.
Now, with established, recognized standards to accomplish this network security “hardening,” along with new automation solutions, IT personnel have an effective starting point and foundation for implementing security frameworks.
Critical Security Controls and Configuration Settings
Critical Security controls provide specific safeguards for any and all systems connected to the network, including mainframe computers, servers, endpoints, attached devices, network appliances, operating systems, middleware, and applications.
The controls impact areas such as access control, audit and accountability, identification and authentication, contingency planning, incident response, configuration and change management, and physical and environmental security. By changing configuration settings in hardware, software, or firmware, companies can improve their security posture.
Of all the available frameworks, NIST SP 800-53 provides the most comprehensive baseline for security controls in its latest published revision. The controls are prioritized and categorized by level of risk.
However, it’s still up to the individual organization to establish company-specific configuration settings and changes to registry settings, account, and file directory permission settings, as well as settings for functions, ports, protocols, services, and remote connections. Such a task often falls to information security and IT staff, many of whom lack the background and training in the area. This introduces the potential that systems will be under-protected and/or left with exploitable security gaps.
As a result, many organizations—even those that apply security frameworks voluntarily—are moving away from proprietary security-hardening efforts in favor of recognized and established best practices. This simplifies deployment and configuration, enhances change control, and automates auditing, which significantly reduces risk.
Fortunately, NIST and other security frameworks point to either of two publicly available configuration standards: the Security Technical Implementation Guides (STIGs) and the CIS Benchmarks.
STIGs and CIS
The STIGs, published by the Defense Information Systems Agency, a support agency for the Department of Defense (DoD), outline hundreds of pages of detailed rules that must be followed to properly secure or “harden” the DoD computing infrastructure. Although STIGs are mandatory for DoD agencies, any civilian agency and even commercial companies are welcome to use the STIGs.
For most commercial organizations, though, CIS is the security standard of choice. Originally formed in 2000, CIS (Center for Internet Security Inc.) is a nonprofit organization with a mission to “identify, develop, validate, promote, and sustain best practice solutions for cyber defense.”
CIS employs a closed crowdsourcing model to identify and refine effective security measures. Individuals develop recommendations that are shared with the community for evaluation through a consensus decision-making process.
“Most organizations need a starting point that works today and that they can explain in simple language to their board on what needs to be done, and that is really what the CIS Benchmarks and CIS Critical Security Controls provide is that starting point,” says Curtis W. Dukes, Executive Vice President & General Manager of the Best Practices and Automation Group at CIS.
Although minor differences exist between the STIGs and CIS Benchmarks, the two overlap and are pretty much interchangeable, says Brian Hajost of SteelCloud, an expert in automated security control compliance. However, implementation of either STIG or CIS Benchmarks can be a challenge if the process isn’t automated in some manner, due to the disparate requirements and configurations of networks.
Changes to security settings can also have unintended consequences. When the configuration settings of an application are reconfigured, it can cause the installed application to “break,” meaning it won’t install and/or run properly.
“If the same security policies and configurations could be implemented on all systems, compliance would be a rather easy exercise,” explains Hajost. “All applications respond to security policies differently. Because configuration settings have the potential to ‘break’ applications, the settings for each system, therefore, have to be uniquely adapted or tuned to each application in the operational environment.”
For example, if some of the configuration settings of a Windows or Linux operating system on which an application operates are reconfigured, the application will break. If an application requires specific settings to operate and those settings are prohibited or blocked, the application will fail to load or operate. And so on.
Often, server policies must be manually adjusted on an application by application, server by server basis. It’s a painstaking task that can take many weeks and often falls to system administrators, application administrators, or information assurance staff.
“There are thousands of IT staff who are tasked with addressing compliance manually, but many are not experienced or trained in it,” says Hajost. “So, they muddle through, but the initial effort can take weeks or even months.”
This is where automation can come into play. Software tools can automate implementation of a security benchmark, even across complex and disparate environments with varying security policies.
ConfigOS from SteelCloud currently supports more than 6,000 standard CIS and STIG configuration settings. The software produces a domain-independent comprehensive policy “signature,” including user-defined documentation and policy waivers. In this step alone, weeks or even months of manual work can be completed in an hour.
The signature and documentation are included in a secure, encrypted signature container that’s used to scan endpoints (laptops, desktops, physical/cloud servers) without being installed on any of them. The time it takes to implement hundreds of configuration security settings on each endpoint is typically under 90 seconds, and ConfigOS can handle multiple implementations at a time.
Hajost estimates automating the process reduces initial hardening time by 90%, while reducing system security policy maintenance expenses by about 70%. Automated software also simplifies ongoing compliance, which in IT is a constantly evolving process.
“New security updates are introduced periodically to account for newly discovered vulnerabilities as well as changes and updates [made] by the vendors supplying the major operating environment components,” explains Hajost.
Limiting Risk/Liability
Although automating configuration security settings can be of immense value, it’s not intended to provide a complete cybersecurity framework. Still, the automation and associated documentation provided can play a critical role in reducing legal liability and attaining cyber insurance.
Dukes of CIS points to recently enacted legislation in Ohio and 2017 in California that establishes legal protections for organizations that have implemented an established security framework, such as the CIS Critical Security Controls, if the organization should suffer a data breach.
“If a data breach gets litigated or adjudicated in a court of law, you want to be able to demonstrate to a judge or jury that you had reasonably implemented and followed a security best practice framework,” says Dukes.
Although many of the security frameworks are still voluntary in the commercial sector, Dukes has seen increased adoption from forward-thinking organizations in the retail, IT consulting, and academia sectors.
“In the near future, more security frameworks are going to move from being voluntary to mandated,” explains Dukes. “Organizations should spend time getting educated and starting the process toward more effective cyber defense now, and not wait until it is mandated. There is too much at stake.”
For more information about ConfigOS from SteelCloud, call (703) 674-5500; or visit www.steelcloud.com.
Jeff Elliott is a Torrance, Calif.-based technical writer. He has researched and written about industrial technologies and issues for the past 20 years.
