Institutionalizing System Change Controls (Part 17 of 20: CERT Best Practices to Mitigate Insider Threats Series)
PUBLISHED IN
Insider ThreatThe 17th practice described in the newly released edition of the Common Sense Guide to Mitigating Insider Threats is Practice 17: Institutionalize System Change Controls. Organizations must change their systems and applications in a consistent, formalized manner. Controls must be put into place to ensure that assets, digital or otherwise, are protected from manipulations by an insider. In this post, I discuss case studies involving change control and a describe how to build a roadmap for implementing a change management system. Lastly, I discuss tools that can help you develop change management policies and procedures, and some quick gains and challenges to implementing change controls.
The CERT Division announced the public released the fifth edition of the Common Sense Guide to Mitigating Insider Threats in December 2016. The guide describes 20 practices that organizations should implement across the enterprise to mitigate (prevent, detect, and respond to) insider threats, as well as case studies of organizations that failed to do so. The 17th of the 20 best practices follows.
Practice 17: Institutionalize System Change Controls.
All organizations must have a change control system in place for all mission critical systems, at a minimum, and ideally for all systems, applications, databases, software, and physical security. Organizations that do not implement change control systems can open their doors to potential insider threat incidents that can do damage to the organization's reputation, cause loss of capital, or cause the organization to go out of business.
In one case from our CERT Insider Threat Incident Corpus, a financial company lost $3.1 million and went bankrupt due to an unauthorized change. This change, an insertion of a logic bomb by a trusted system administrator, occurred after employee bonuses were cut in half. The incident resulted in a company-wide outage of nearly 2,370 servers.
Another case involved a bond trading organization where a computer specialist, who was motivated by revenge, inserted malicious code into a system that increased trading risks. This incident resulted in customer losses of over $1 million and cost the organization $50,000 to repair the damage to the system. Damage to the organization's intangible assets, such as customer trust, were high.
The National Institute of Science and Technology (NIST) identified the importance of having a configuration control system when it specifically required a change management program in the Change Management section of NIST 800-53 (Rev 4). One of the core reasons that NIST emphasizes on having change management/controls systems in place is because they are effective at preventing and detecting internal and external threats and incidents.
Identifying organizational baselines is the initial step in implementing a change management system. Predefined baselines exist, such as the USGCB (U.S. government configuration baseline) for Windows 7 and baselines created by organizations such as DISA (Defense Information Systems Agency) and CIS (Center for Internet Security), which include server operating system baselines and database baselines. However, the organization must also create baselines for other applications, such as COTS (commercial off the shelf), GOTS (government off the shelf), or applications developed in house. Knowing the coding and behavior of the program is critical.
Baseline documentation should contain the following:
- cryptographic checksums of applications, at least for mission-critical applications
- interface characterizations (e.g., memory mappings, device options, and serial numbers) that ensure the organization understands the behavior of the application
- configuration files, which are normally custom generated to tailor the application or system to the organization (Without configuration files, rebuilding a system becomes exponentially more difficult.)
Once baselines are created, the organization must ensure the following:
- Configurations are used on the system using checksum compares and automated products, such as application whitelisting tools.
- Configuration change management processes allow the organization's baseline to grow while tracking changes to maintain those baselines.
Quick wins and high-impact solutions include the following:
- Periodic reviews of configurations should focus on differences from the current baseline.
- A designated manager must sign off on key changes. This approval ensures the segmentation of duties, as documented in Practice 15: Enforce Separation of Duties and Least Privileges.
Refer to the complete fifth edition of the Common Sense Guide to Mitigating Insider Threats for a comprehensive understanding of the issues and recommendations mentioned in this post.
Check back next week to read about Practice 18: Implement secure backup and recovery processes, or subscribe to a feed of the Insider Threat blog to be alerted when a new post is available.
For more information about the CERT Insider Threat Center, see https://www.sei.cmu.edu/research-capabilities/all-work/display.cfm?customel_datapageid_4050=21232, or contact us at info@sei.cmu.edu.
More By The Author
More In Insider Threat
PUBLISHED IN
Insider ThreatGet updates on our latest work.
Sign up to have the latest post sent to your inbox weekly.
Subscribe Get our RSS feedMore In Insider Threat
Get updates on our latest work.
Each week, our researchers write about the latest in software engineering, cybersecurity and artificial intelligence. Sign up to get the latest post sent to your inbox the day it's published.
Subscribe Get our RSS feed