Many organizations use hundreds or even thousands of third party vendors. They connect to their networks, access private corporate data, and too often, as we saw in the case of Edward Snowden and more recently Harold Martin, elevate organizations’ cyber risk. A 2016 Ponemon Institute study showed 73 percent of organizations see the number of cyber security incidents involving vendors increasing and sixty-five percent say it is difficult to manage cyber security incidents involving vendors. Each third party vendor employee that has access to organizations’ sensitive data poses a cyber risk. Just one misstep, whether intentional or not, becomes an active insider threat that could lead to a compromise.
The United States Department of Defense (DoD) has recognized this risk, which is why beginning November 30, 2016, DoD third party contractors will be required to establish and maintain an insider threat program. The mandate is part of Change 2 to the DoD’s “National Industrial Security Operating Manual (NISPOM).” It says contractors must have a written insider threat program in place that focuses on detecting, deterring and mitigating insider threats.
The more attention organizations give to insider threats the better, especially those coming from third party contractors, which is why the change is a step in the right direction. That said, Change 2 only addresses one piece of the puzzle, which is policies, procedures, training and monitoring conducted by the employer of government contractors. While that is a good start, it does not address a number of important components of identifying and stopping insider threats. The greatest challenge is connecting the dots between what is known by government managers about how their contractors interact and access sensitive assets (which is accomplished via on site and technical behavior monitoring), business context surrounding those activities (via application security owners) and what is known by the contractor’s employer regarding the behavior of their employee. In many cases there is little to no communication between these parties and as such, nobody is viewing the user’s activities with all of the information needed to determine if an insider threat is real or not. Even the best policies, procedures and training on behalf of the contractor’s employer, as defined in the updated NISPOM, will not solve this problem beyond increasing everybody’s awareness.
The greatest challenge of identifying and stopping the insider threat is piecing together and communicating the many disconnected pieces of information to the right people, so that the right conclusions can be drawn. The indicators are usually there, found forensically after the fact, but it requires the right combination of technologies and procedures to connect the dots before something bad happens.
In the case of contractors, there are (at least) three participants in the process of analyzing the events in question.
The first is the analyst sitting in front of the console that identifies that the contractor in question is behaving unusually, especially as it relates to important assets. This requires technology that includes user and entity behavior analysis functionality with a strong asset value orientation.
Once the analyst has identified the contractor user as a person of interest, the second participant is the application security owner or manager who has knowledge of the applications, data and hosts the contractor user is accessing. These people understand the business context of what is being accessed and the role of the contractor. They can provide input into whether there is a legitimate reason for the access.
The third participant is the management of the company who actually employs the contractor, who can provide additional context and insight into the user’s profile and behavior. Additionally, if the incident is a case of a non-malicious repeat policy offender, the contractor’s employer should be incorporated into the process of reprimanding and educating the user in a manner that is focused on the violation.
Without the right technology to orchestrate the process of identification, investigation and most importantly, communication, managing the insider threat process can be incredibly time consuming and overwhelming.
It is simply not practical to manually identify the right people of interest, gather the right information for investigation and communicate with the right parties for context and escalation. Some companies have tried to apply SIEM or SIEM extension UEBA tools, but have fallen short because at best it only accomplishes step one.
To effectively reduce the risk of insider threats, risk management principles need to be applied, with the right technologies and procedures to orchestrate the rest of the process. NISPOM Change 2 is a great start, but will need to be built upon to truly be effective.