The CERT Program announced the public release of the fourth edition of the Common Sense Guide to Mitigating Insider Threats on December 12, 2012. The guide describes 19 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 sixth of the 19 best practices follows.

Practice 6: Know your assets.

It is critical that employees and especially management know all of the assets that help create and define their organization. Organizations must identify both their physical and information assets. It is paramount that organizations have a firm understanding of what their critical assets are (people, information, technology, and facilities), all the locations where the assets reside, who should have authorized access to them, and who does have access.

Physical assets, such as servers and workstations, should be tagged and tracked in an inventory database. Furthermore, there should be security protections (e.g., locked rooms, cameras, tracking devices) in place to help prevent their loss or theft. Information assets are more difficult to track and protect. As a result, organizations must be better prepared to ensure that they know the types of data its systems process, who uses the data, and where it is stored.

The best way for an organization to know its assets and protect them from outsider and insider attacks is to conduct a formal risk assessment. The National Institute for Standards and Technology (NIST) developed a risk assessment framework that is referenced in the fourth edition of the Common Sense Guide to Mitigating Insider Threats. In addition to the NIST risk assessment, the guide also provides key questions that an organization must answer. These questions are associated with what types of data are processed; what types of devices process this data; and where the data is stored, processed, and transmitted.

At the CERT Insider Threat Center, we understand that there are challenges involved in conducting a risk assessment and answering key questions, including finding time and funding to complete and maintain an inventory and perform a risk assessment. However, organizations that do not identify their assets can be subject to devastating consequences. In one incident, a leader of an underground hacking group who was working the night shift as a security guard at a hospital was able to access unauthorized areas of the hospital. Once in the rooms, the insider planted malware on systems, including an HVAC system. The insider was eventually caught by the organization, but only after the insider made and posted a video online about his attack.

The guide offers quick wins and high-impact solutions for organizations. In it we recommend that organizations conduct a physical inventory, understand the data being processed, identify and document the software configurations of all assets, and prioritize assets and data to determine high-value targets. The bottom line is that organizations must identify their crown jewels, where they are located, and who should have access to them.

Check back in a few days to read about best practice 7, Implement strict password and account management policies and practices, or subscribe to a feed of CERT Program blogs to be alerted when a new post is available.

SEI LIBRARY

LATEST POST

According to DevSecOps: Early, Everywhere, at Scale, a survey published by Sonatype, "Mature DevOps organizations are able to perform automated security analysis on each phase (design, develop, test) more often than non-DevOps organizations." Since DevOps enables strong collaboration and automation of the process and enforces traceability, mature DevOps organizations are more likely to perform automated security analysis than non DevOps organizations. My previous blog post, Microcosm: A Secure DevOps Pipeline as Code, helped address the problem that most organizations do not have a complete deployment pipeline in place (and are therefore not considered to be DevOps mature) by automating penetration tests of software applications and generating HTML reports as part of the build process through the Jenkins CI service. In this follow-up blog post, I explore the use of a service evolution of Microcosm as a simple one-stop shop for anyone interested in learning how to implement a DevSecOps pipeline.