The Insider Threat: History and Defense

In cyber security, the “Insider Threat” refers to potential actions taken by people within an organization that can cause harm, as opposed to hackers attacking from the outside. Sometimes an insider takes actions maliciously with intent to steal data or cause damage. In other cases, the insider takes actions accidentally by clicking a link or sharing information because they make a mistake or don’t understand the consequences of their actions. The challenge for a business is to find ways to allow people to do their jobs, while at the same time protecting the business from insider actions that pose security problems.

What Are the Risks Associated with an Insider Threat?

When evaluating the likelihood and potential damage caused by an insider, it is helpful to consider past events. The damage caused by an insider will vary by the intent of the person accessing the systems and what they can do with the information they can access. These and other examples will help an organization consider the risk and damage to the business that could result from insider actions.

• A Tewksbury Hospital employee improperly viewed patient records for over 14 years before anyone noticed.
• A Morgan Stanley employee accessed over 700,000 customer accounts for several years.
• UMass Memorial Medical Center had a breach that lasted 12 years undetected. The insider may have opened cell phone and credit card accounts with patient data.
• The network administrator for the city of San Francisco locked out the city from its own network.
• A fired Gucci engineer used social engineering to trick IT staff to enable him to shut down servers and delete data.
• An anonymous Amazon source told me he saw cases in which customers with improperly secured accounts watched employees deleting data and could not stop it fast enough.
• A computer programmer dismissed from his job planted a software bomb at Omega which resulted in $10 million in losses for the company and 41 months in jail for the former employee.
• Edward Snowden, as most people know, released topsecret US documents.
• Morris Cohen, also known by the alias Peter Kroger, stole the plans for the atomic bomb from Los Alamos labs and gave them to the Russian government.
• The Silvermaster Group and other spy rings worked inside the US government during the Cold War, hiring co-conspirators, leaking sensitive data, and influencing US government decisions as explained in the Encyclopedia of Cold War Espionage, Spies, and Secret Operations.

A curious reader will find many other examples of insiders within organizations taking adverse actions against an organization from within. Insider threats pose a challenging problem. On the one hand, employers want to trust their employees and allow them to carry out their duties. Setting up many road blocks for employees can slow down the business and affect its ability to operate. On the other hand, employers need to protect themselves from potential loss, sabotage, or at a minimum negative press. Although this is a difficult problem, companies can take steps to defend against this threat.

Awareness

Before a company can implement a successful security program of anykind, the executives or owners of a company must be aware and believe that the threat exists. The executives are responsible for making the decisions that protect the business and must buy into and sign off on any security programs. Business owners must also help enforce the security program.

Security Policy

A clear, written security policy should inform employees what they should and should not do. In some cases, employees may not realize how their actions can cause damage. Inappropriate access may simply be a result of curiosity more than malicious behavior. Sometimes employees just want to do their job or help someone and do not understand the consequences of risky actions.  A student in one of the security classes I attended worked for the NSA and said Edward Snowden was a nice guy and asked a coworker to share credentials to obtain the documents he leaked. This article explainsthat a civilian NSA employee unwittingly helped Snowden and had no idea of his intent to steal documents.

A policy makes it easier for employees to decide what actions to take. A policy will make it easier for an employee who follows the rules to say no to a person using social engineering tactics. If there is no documentation or the employer does not inform employees it exists, the employer may have no recourse if an employee takes actions that cause security problems. The company must also have proper evidence showing an employee did not follow the policy and enforce the policy consistently.

Training

The policy alone will not do any good if employees do not know it exists or what it says. Effective training involves more than simply handing out a document and having employees sign it. Employees are busy and overloaded. I attended a security awareness training from SANS Institute which offers in-depth information to help employers create an effective security awareness training program. Security teams can use tools created to help with security training. Case studies may help. The ability to influence behavioral changes may be improved by integration of training into the process employees use to do their jobs, as explained in this paper about secure cloud deployments: Balancing Security and Automation with Event Driven Security.

Segregation of Duties

Segregation of Duties or Separation of Duties involves structuring work in a way that requires more than one person to carry out a task. Financial processes often follow this principle. Organizations can apply this principle to the design of IT systems. Here are a few examples I have read about, experienced as a consultant or employee, or personally implemented:

• One company developing a drug in a foreign country had the drug manufactured in separate locations. Neither location had the complete formula. As a result, no employee at either location would be able to steal the formula via the systems to which he or she had access.
• One company split social security numbers into two pieces and stored each piece in separate databases. Different employees had access to the different databases. Note that the design would need to ensure the system never writes full SSN to a log file as well and has protection while a system is processing it in memory. Applications would not show the full SSN to users.
• Create separate teams to break duties up in a way that protects systems from total control: for example, one to create accounts and permissions to access data, other teams to process data and a separate team to manage encryption keys.
• System architecture and organizational structure can ensure it takes a three-party collusion to write code to access sensitive data. Different teams can own different parts of the code in separate source code repositories.
• Maintain separate environments and teams for software development, QA, and production operations. Restrict access to change systems to the team that owns the system.
• A company could implement temporary access in production environments monitored by a second party and approved by a third.
• Data not needed for a job can be anonymized or restricted from view. For example, a person processing a transaction does not need to know the credit card number. A hospital billing clerk does not need to see a person’s prescriptions, ailments, or social security number.
• Systems can separate data processing from PII (personally identifiable information). For example, the part of the system that displays logs in a SAAS solution doesn’t need to know details about the owner of the logs. Using microservices lends itself well to this type of system design.
• A previous post on CloudFormation Benefits for Secure AWS Deployments explains how leveraging AWS deployment tools for cloud deployments provides a separate logging system that company employees cannot alter as that portion of the system is handled by Amazon.

Every organization is different and will need to decide which of processes and data are most critical. After figuring out what needs the most protection, design the related systems and processes to limit access to what is necessary for an employee or system to do the job. Implement an organizational structure that avoids giving a single person full access to all systems and data. Incorporate checks and balances into processes handling sensitive data.

Monitoring

“Trust but verify.” Ronald Regan used this phrase often in the Cold War negotiations with Mikhail Gorbachev. In fact, it originates from a Russian proverb. Rather than distrust employees or create stringent systems to enforce rules, an organization can set up monitoring and alerts for security-related actions. If an employee acts outside of company policies, employees can receive more training. If an employee consistently disregards security policy, organizations can take the actions written in the policy.

Monitoring needs to comply with the privacy laws applicable to the organization and locations in which it does business. To trust the data from monitoring systems, the monitoring systems themselves must be secure. Monitoring is not a purely technical control and requires human involvement. In a paper on the Target Breach, I mention that setting up security cameras but then having no one to watch them renders the cameras useless. Companies must employ people either internally or externally to review log data and alerts. The data could be forward to the employee’s manager, an internal security team, or a company could employ an external Managed Security Service Provider (MSSP) to handle this type of monitoring.

Incident Response

In the case of an incident, how will your company respond? A small business may use an MSSP to help in cases like this if full time security staff is not possible. Target had a third-party monitoring company but when a breach occurred they did not act on the information about the breach right away. Will you? Do you have the backups to quickly restore your business operations? Do you have the necessary logs to figure out what actions the insider took? Are the logs secure or could they have been deleted or altered? Considering these things before the incident may help a business recover from an incident with minimal damage.

Defending Against Insider Threats Protects Everyone

Creating defensive measures to prevent insider threats helps not only the organization but the customers of the organization and its employees. Organizations protect themselves from the consequences of a data breach, including negative press and financial loss. Customers benefit from data protection. Employees find it easier to do their work securely by following straight-forward policies and understanding why they exist. Policies and well-informed employees will make it difficult for a person with malicious intent to trick or coerce employees who are following the rules into taking harmful actions. System architecture and process design can limit data loss. Monitoring can help alert organizations to unwanted activity. Involving employees in security efforts allows everyone to understand and contribute to improving the effectiveness of security programs. — Teri Radichel (@teriradichel)

Share This: