Introduction

Ensuring that the condition of our systems are in a known, good, and trusted state is imperative to ensuring a high available network, which doesn’t not rely on implicit knowledge of the IT development teams. Having random available access to current and historical systems states are instrumental in helping project management perform adequate audits and for the development teams to perform debugging.

Findings

It’s critical to articulate the current state of the system configuration during the execution phase as well as handoffs in between stages of the development cycles.

We discovered numerous areas were improvement in configuration management is needed. These improvements include:

1. Increased efficiencies in stability and controls by improving network visibility.
2. Reduction in costs realized through the elimination of unnecessary duplication efforts.
3. Enhanced system reliability by eliminating improper configurations, which negatively impact system performance.
4. Expedient problem resolution ensuring improved quality of service.
5. Increased levels of security with a reduction in risks.
6. Efficient change management that do not yield new inconsistencies or incompatibility.
7. Rapid service restoration.

Risks

The risks associated with forgoing the aforementioned improvements in configuration management include:

1. Lost time in discovering which system components changed when requirements changed.
2. Having to redo an implementation due to missing a requirement that changed which wasn’t properly communicated to all parties involved.
3. Loss in productivity due to flawed component replacement that can’t quickly be reverted back to a working state.
4. Not having the ability to accurately identify which components need replacing.

Recommendation

We propose deploying company wide the use of two configuration management tools Chef and Puppet, which both align with the framework of NIST.SP.800-53 rev.4 Configuration Management family of controls. NIST’s Configuration Management family of controls will not only help increase the security posture of our IT department but will also has the benefit of helping us meet federal regulatory guidelines while reducing associated risks.

NIST.SP.800-53 rev.4 configuration management family of controls directly affected:

1. (CM-1) Configuration Management Policy and Procedures
2. (CM-2) Baseline Configuration
3. (CM-3) Configuration Change Control
4. (CM-4) Security Impact Analysis
5. (CM-5) Access Restrictions for Change
6. (CM-6) Configuration Settings
7. (CM-7) Least Functionality
8. (CM-8) Information System Component Inventory
9. (CM-9) Configuration Management Plan
10. (CM-10) Software Usage Restrictions
11. (CM-11) User-Installed Software

We will contrast and compare the two recommended configuration management tools below. Both Puppet and Chef are cross platform with Puppet supporting a wider range of operating systems. Puppet does have a larger use base than Chef being that it’s the older platform and has a larger system administrator user community as opposed to Chef’s larger developer community.

Complexity and Power

1. Puppet: Ruby based and model driven, thus, less imposing and considered system administrator friendly. Mature platform with huge system administrator user community. Cross platform and simple installation and setup. Most complete Web UI. Strong reporting capabilities.
2. Chef: Open sourced, Ruby based, is more procedural. This has the potential to be more problematic for system administrators with little Ruby experience. Steep learning curve that requires the skills of a large team to endure. Coding allows for a more customized configurations.

Return on Investment

Financial benefits will be realized through the leveraging of configuration management tools by increasing IT staff productivity who stay focused on business related initiatives, an increase in user productivity due to a reduction in downtime caused by cyber attacks, system outages, and configuration changes.

Figure 1. Configuration Management Workflow

A comprehensive configuration management plan enforces the configuration management policies set forth, which are tailored to individual systems. These plans would detail procedures on how configuration management is used to support the development life-cycle. A generic configuration management workflow, as seen in figure 1, highlights the interrelationships between the various product stages throughout out the development life-cycle.

References

Johnson, A., Dempsey, K., Ross, R., Gupta, S., & Bailey, D. (2011, April). Guide for Security-Focused Configuration Management of Information Systems. Retrieved September, 2016, from nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-128.pdf

 NIST. (2013, April). Security and Privacy Controls for Federal Information Systems and Organizations. Retrieved September, 2016, from https://champlain.instructure.com/courses/502529/files/39940581/download

UPGAURD. (2016, September). 7 Configuration Management (CM) Tools You Need to Know About. Retrieved September, 2016, from https://www.upguard.com/articles/the-7-configuration-management-tools-you-need-to-know