Posted on by Insider Threatin
The 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:
Once baselines are created, the organization must ensure the following:
Quick wins and high-impact solutions include the following:
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.