Researchers on the CERT Division's insider threat team have presented several of the 26 patterns identified by analyzing our insider threat database, which is based on examinations of more than 700 insider threat cases and interviews with the United States Secret Service, victims' organizations, and convicted felons. Through our analysis, we identified more than 100 categories of weaknesses in systems, processes, people, or technologies that allowed insider threats to occur. One aspect of our research focuses on identifying enterprise architecture patterns that organizations can use to protect their systems from malicious insider threat. Now that we've developed 26 patterns, our next priority is to assemble these patterns into a pattern language that organizations can use to bolster their resources and make them more resilient against insider threats. This blog post is the third installment in a series that describes our research to create and validate an insider threat mitigation pattern language to help organizations balance the cost of security controls with the risk of insider compromise.

Developing an Enterprise Architecture Pattern Language

Our aim in developing an insider threat pattern language is to equip enterprise engineers with the tools necessary to make an organization resilient against insider threat. The patterns in our language capture solutions to recurring patterns in insider threat. For example, the Thirty-Day Window pattern, discussed by my colleague Andrew Moore in his blog Effectiveness of a Pattern for Preventing Theft by Insiders, is based on the observation that a large percentage of malicious exfiltration by insiders happens within 30 days of termination. So, organizations can improve their detection of such violations by focusing on a very narrow window of time.

Once we identified and documented the original 26 patterns, we wanted to go beyond simply publishing them as a flat, two-dimensional collection. Instead, we wanted to show the relationships among the patterns by arranging them in an organic hierarchy (i.e., a pattern language). This approach follows the example of Christopher Alexander, the father of the patterns movement in the building architecture community, and his work on patterns and pattern languages.

Unfortunately, insider threat poses challenges to a hierarchical approach to organizing patterns because insider threats permeate the organization. Addressing and protecting enterprise organizations from insider threat involves an enterprise-wide approach involving several different strategies. This diversity leads to multiple potentially conflicting classification systems. A classification that makes sense for human resource systems might not make sense from an incident response perspective. Likewise, some third classification might be required for the information technology staff, and so forth.

Trying on Classification Systems

We explored several categorizations before ultimately deciding on a multi-dimensional approach. Each of the systems that we explored provided useful perspectives on our patterns by situating them within a specific domain, whether information security, enterprise architectures, incident management, resiliency, or organizational structure.

• Information security pattern languages. We initially assumed that our insider threat patterns would fit well within existing information security pattern languages. As a guide, we relied on the book Security Patterns by Schumacher et al., which maps information security pattern languages to the categories in the Zachman Framework (see below). Our insider threat patterns were most compatible with the "Enterprise Security and Risk Management" patterns because the crux of the insider threat problem is that, for employees to do their jobs efficiently, they must be trusted by their employers and operate in an environment largely unfettered by authentication controls, access controls, and firewalls. As a result, our patterns are a bit of a mismatch for the identification and authentication patterns, the operating system access control patterns, and the firewall architecture patterns, which are largely focused on implementing those fetters. We soon realized that this mismatch meant that despite a commonality of purpose, the Schumacher landscape would not be ideal as a single taxonomy for our pattern language.

• The Zachman Framework. We then mapped our patterns to the Zachman Framework, which is an enterprise architecture framework that provides a formal and highly structured view of an enterprise. The Zachman Framework provides a diagram for organizing architectural artifacts on the basis of the intended recipient and the issue being addressed. The diagram helped us quickly realize that our patterns were at the enterprise security strategy and policy levels and not at the mechanisms and implementation levels. This was an important insight, but it did mean that our patterns were clustered in one small area of the framework, making it of limited utility as the single way of classifying our patterns.

• Business units. We also considered organizing our patterns by business units, such as human resources, legal, etc. Business units provide a very useful organization system for the patterns. Business units are less useful as a general-purpose classification system, however, because they obscure the fact that our patterns frequently cross business-unit boundaries.
• Lifecycle phase. Another approach we explored involved using the insider threat lifecycle to break the patterns into prevention, detection, and response patterns. This approach made sense in terms of risk management and incident response, but proved less satisfactory in terms of the organization-wide enterprise focus of insider threat.
• CERT Resilience Management Model. Finally, we considered the CERT Resilience Management Model (CERT-RMM), a broad-based model of the organizational process areas needed for resilience. Unsurprisingly, this was a better fit for insider threat patterns in the sense that its process areas divided our patterns into logical groups, but even so we did not want to give up the insights provided by the other schemas.

A Multi-Dimensional Organizational Structure
After exploring the categorizations listed above, we realized that it would make sense to move away from rigid, top-down, linear hierarchical systems. No one system would serve all users and all use cases equally well, so a multi-dimensional classification system was called for.
One problem with multi-dimensional constructs is that the human brain struggles to conceive of ideas beyond three dimensions. Instead, we looked to a library classification technique known as faceted classification. Recently, faceted classification has become widely used again in search engines on commerce websites. When shopping on Amazon's site, for example, users can narrow their searches by classifications or facets, such as price, color, or manufacturer. This approach made sense in this age of near-ubiquitous computing where users have easy access to higher dimensional structures.
The specific implementation of faceted classification that we used is the facet map, which we downloaded from Facetmap software. We realized two benefits to organizing the pattern language as a drill-down facet map

1. Users can specify the exact aspects of the patterns that are applicable to their circumstances. For example, a user can narrow a search to only address insider threat patterns within human resources. That same search can also be narrowed to include misuse of information technology infrastructure.
2. The faceted classification's formal description of the pattern language organization makes it easier for users to generate alternative representations and categories.

The facet map model allowed us to organize our patterns into a map that categorizes each of the 26 patterns in a five-dimensional space defined by the classifications described above. Figure 2 below shows the Facetmap interface to this hyperspace.

Current and Future Work

Our current work focuses on pattern composition because we feel that is a crucially important issue in transitioning patterns to the operational community. Instead of trying to impose a single composition method on all end users, we have created a pattern language to help usersselect from a number of different composition methods, depending on the situation. For example, the way a small software startup would want to integrate an insider threat pattern into its organization will be different from the way it might be integrated into a military organization or a multinational corporation.

To assist in validating the composition operations, we are exploring the idea of using simple ontologies to capture the essential components of a pattern and its relationships. For example, the 30-day Window Pattern is essentially a relationship among the human resources and information technology staff and the employee.

To allow users to easily guarantee the completeness of their pattern composition, we are testing the use of a formal ontology expressed in the Web Ontology Language (OWL). For more information on OWL and the more general use of ontologies in information security, please see CERT's Security and Ontology webpage.

The integration of our pattern language and its multi-dimensional interface, combined with the pattern composition pattern language and our ontology-driven validation methodology, will be a significant step in the evolution of insider threat mitigation techniques. We welcome your feedback on our work. Please send us an email at info@sei.cmu.edu or leave feedback in the comments section below.

Additional Resources

Cybersecurity experts from the CERT Insider Threat Center will present a free virtual event on current research aimed at establishing best practices to mitigate insider threats. Managing the Insider Threat: What Every Organization Should Know will took place Thursday, Aug. 8, from 9 a.m. to 5 p.m. EDT.

To learn more about OWL and the use of ontologies in security, please visit
https://www.sei.cmu.edu/about/divisions/cert/index.cfm

To read the SEI technical report, A Pattern for Increased Monitoring for Intellectual Property Theft by Departing Insiders, please visit
www.sei.cmu.edu/reports/12tr008.pdf

To read the SEI technical note, Insider Threat Control: Using Centralized Logging to Detect Data Exfiltration Near Insider Termination, please visit
www.cert.org/archive/pdf/11tn024.pdf

To read the CERT Insider Threat blog, please visit /blog?tag=insider-threat