Let’s meet some actors in this game, shall we?
First, we have Roger, who is angry that his peers have gotten promoted over him and he received a paltry bonus this year. Roger decided to reset production server accounts to a password only he knows, cover his tracks, and proclaim ignorance when a severe incident ensues.
Next, we have Rebecca, who is a talented engineer working for an autonomous driving startup. Rebecca stored the entire codebase for the vehicle sensor systems on her personal laptop and she just happens to be interviewing with Uber AND Argo next week for senior engineer positions.
Finally, let me introduce you to Dan, who is a supervisor in the ACH/Wire section of a medium-sized bank. Dan is having a little trouble paying bills lately, and he thinks MAYBE just a couple fraudulent money transfers will get his head above water.
These are admittedly stereotypical profiles of Insider Threats, and not tied directly to any real-life incident, but not far off from scenarios that have plagued companies for years. Despite technology solutions that tout their ability to stop these threats, almost 58% of the organizations that had security incidents in the prior year blamed them on insiders, according to one survey. Several high-profile Insider Threat events have occurred this year, such as a massive SWIFT fraud at Punjab National Bank and IT Sabotage at Tesla.
Inevitably, they are almost always followed by Cybersecurity experts putting forth supposedly ironclad solutions. These solutions often involve better organizational coordination, comprehensive threat detection, and technological solutions for encryption or data loss prevention (DLP). While all of these solutions may be appropriate to counter Insider Threat, they fail to mention an important foundational element – effective Enterprise Risk Management (ERM).In the first case mentioned above, an insider at India’s Punjab National Bank (PNB) had unauthorized access to an elevated privilege account for the SWIFT network, which permitted him to issue instructions to other banks to release funds to his conspirators’ PNB accounts. These funds, which totaled $1.8 billion, were released by PNB under the guise of loans that would be used to purchase uncut diamonds for processing.
Aside from the unauthorized account access and usage, there were other key operational risk failures that allowed this to take place for years, such as the use of non-automated process exceptions and a lack of software integration that would have reconciled systems. This was far from being the first instance of large-scale fraud related to the SWIFT network worldwide, so India’s central bank warned institutions at least three times since August 2016 to comply with SWIFT operational risk guidelines that would have likely prevented this incident. SWIFT incidents elsewhere have occurred with external actors who have compromised insider accounts to execute fraudulent transactions, which ALSO would have been prevented by following the controls that should have been operating effectively. So, the problem is not the insider – the problem is the organization who has controls in their hands that should be implemented, tested, governed, and reported to relevant parties as part of an ERM program.
Why ERM is Important?
To help avoid the above situation, there are a number of ERM frameworks that may be valid candidates to implement , such as NIST’s Risk Management Framework (RMF), CERT’s OCTAVE, or Factor Analysis of Information Risk (FAIR). Although different in many regards, these frameworks all begin with some method of risk framing, which requires an enumeration of risk tolerance as well as critical assets and business processes. The simplified risk management process in Figure 1 below demonstrates this first step in the larger context.
Put another way, organizations can ask themselves two simple questions that are core to zeroing in on risk that should be ultimately addressed.
1) What do we HAVE?
2) What do we DO?
These two questions are intentionally simplified and would not be entirely adequate to ask in isolation. Instead, having subject matter experts list and describe their core processes (and subprocesses) along with the key personnel and technology systems supporting that process can begin to paint a picture of risk that must be identified, analyzed and addressed. In the case of PNB, the transfer of money via SWIFT was most certainly a known core process that carried significant risk, but the bank obviously did not implement appropriate controls to address and govern that risk.
The second example referenced above involved Tesla motors and the sabotage and theft of its intellectual property (IP). A disgruntled employee made unauthorized changes to the Tesla Manufacturing Operating System and assisted in the disclosure of sensitive IP. A Tesla employee named Martin Tripp (who was disgruntled after not receiving an expected promotion) engaged in these activities as retribution against Tesla. In 2020, he was ordered to pay $400,000 to settle the hacking case.
Revisiting the simplified questions above, the answers for Tesla would be, “We have unique and expensive cars (which contain a LOT of proprietary code and technology), and we sell them to consumers.” Although much has been made of late about the production capacity of Tesla not meeting consumer expectations, it’s doubtful Martin Tripp significantly harmed their long-term ability in that area with the sabotage.
What may be of far greater concern is the exfiltration of sensitive IP that could portend a loss of competitive advantage – something Tesla currently possesses in spades. The fact that the insider accomplished this attack by unauthorized changes to a production code base using false usernames signals that Tesla also did not implement effective ERM practices. Proper ERM practices would have helped to avoid this situation.
This article is not intended to present the pros and cons of the referenced risk management frameworks or even address which specific steps within those frameworks could be used to better prepare an organization to be resilient against insider threats. Rather, it simply suggests that in the above cases where an insider did deliberate damage to an organization’s assets, having a robust set of risk management practices in place may have put controls in place to prevent, detect, or respond to the unauthorized activities. Further, these cases were noteworthy because of the damage caused or the popularity of the company/product, but there are far more insider cases (many that are inadvertent instead of malicious) occurring annually that do not reach the threshold of being reported in news outlets. In these instances, any number of controls (e.g., user education and awareness, multi-factor authentication, endpoint protection) may be effective in addressing insider threat, but putting these controls in the context of a complete ERM program will certainly give an organization the best possible chance to prevent damaging incidents from taking place and recovering when they do.
How can MindPoint Group help with Insider Threats?
Connect with the team Third-Party Risk Management team at MindPoint Group who can work to no only identify 3rd Party threats who have access inside your organization but also help you uncover vulnerabilities in your current systems.
