During my undergraduate degree, I discovered the thought of the insider threat. Insider threat is a broad term and includes insiders which act in malicious intention (e.g. to sell intellectual property) but also insiders who are being careless in their actions (e.g. sending a classified email to the wrong recipient)). Moreover, the insider threat is often overlooked by senior management; having little prevention or detection mechanisms, allowing insiders to carry out attacks before being detected. However, that is changing now as companies put more effort in to keep their sensitive data only with authorized personnel.
This post is a summary of the findings in research through my undergraduate dissertation.
Naturally, when thinking about insider threat, one might think about Edward Snowden, who leaked an excessive amount of information regarding the National Security Agency (NSA) secret operations. In an interview, Steven Bay (the former boss of Snowden) claimed that he had “no reason to trust [snowden]”.
Contractors are often overlooked when it comes to insider threat. Contractors are in a strange position as typically they are outsiders, which are treated like insiders; obtaining authorized access to the network, documents, possibly even physical sites. Naturally, organizations trust contractors due to a non-disclosure agreement (NDA); however, this is not always a sufficient threat prevention mechanism. Moreover, due to the nature of a contractor only being temporary, some companies do not provide extensive information security training (beyond a brochure or a click-through online training) as the company could believe that it is not worth the investment of money and time.
Current Standards for Detecting Insider Activity
Organizations currently take a forensic approach to insider threat detection. The evidence of the security incident is handed to a forensic analysis team who must provide findings using tools available to them.
The issue with a forensic approach to insider threat management is that due to the retrospective nature of the forensic analysis, the attack has already occurred and therefore too late to stop it!
The purpose of a forensic investigation is to assess the impact of the attack and possibly identify other areas which have been affected. Furthermore, findings could be used to implement updated strategies to prevent similar attacks from repeating.
Prevention of Insider Threat
It is found that during periods of high workload, employees tend to be less diligent in analyzing possibly malicious emails. Hence, employees are more likely to fall subject to phishing emails. The natural solution against phishing is to train against employees. However, this is not likely to work by itself; instead, the company should focus on creating a positive security culture within an organization.
Positive security culture involves making employees feel their importance within an organization towards information security. Furthermore, a positive security culture can help to increase the subconscious mind to be aware and be vigilant.
Honeypots are commonly used when organizations try to defend against external attacks. Over time, many different honeypot models have been created to the extent that it has become challenging to define what a honeypot in a concrete fashion. The key about honey pots is that they are specifically designed to capture malicious attacks. This is useful for an organization as it can provide insight into attacker methodologies. Furthermore, it effectively wastes an attackers time as the attacker cannot obtain useful information by breaching the honeypot (depending on the setup/ segregation of data). A list of honeypots which can be implemented can be seen here (GitHub alternative link).
As honeypots are designed to capture malicious activity, and regular users are not expected to trigger the traps, honeypot attack analysis often provides low false-positive rates.
Honeypots can have different levels of interaction:
|Low||A simulation of a service (e.g. SSH) on a port. |
An example: Pentbox
|Easy to setup||Attackers quickly notice that there is no information available.|
|Medium||Allow connection/login attempts||Can retain an attacker’s attention more than a low-level||Similar to low-level, attackers quickly notice the use of a honeypot|
|High||Fully interactive system |
An example: Cowrie
|Attackers can completely exploit, allowing for better analysis (blue team perspective)||An inherent risk that attacker can infiltrate alternative systems through pivoting.|
Decoy documents are files that contain information intended to gain intelligence of insider activity baiting them to interact with the file. Decoy documents are also known as honey files. Similar to a honeypot, honey files are scattered around a system (perhaps a network file share or local filesystem) with the intention to capture malicious activity.
Decoy documents can include but are not limited to; email logins or bank account details. The key to a decoy document is that it is populated with bogus information, that otherwise would pertain no value. The challenge of decoy documents is to craft fake data such that malicious insiders perceive the data as valuable.
The idea of decoy documents is not necessarily new. Cliff Stoll is credited to be one of the first to use decoy documents, using them to capture conclusive evidence of German hackers breaking into Lawrence Berkeley Laboratory computer systems. He details his story in his book (ISBN-13: 978-1416507789).
Honey tokens are pieces of information which are not necessarily a file. Some examples include:
- Entries in a database
- Tokens in HTML comments
- DNS honey tokens
Microsoft used honey tokens in their Xbox software distributed in a closed-beta development phase. The full article can be seen on the Dualshockers website. The way that Microsoft implemented the honey token was to place a serial number using the rings under the Xbox logo. This could then be used to trace the source of any pre-released software leaks. The fascinating part of it all is that it worked!!
The Practical Portion of my Undergraduate Dissertation
The success of honey tokens inspired me to develop a web application which automatically distributes honey tokens in the HTML source code (as an HTML comment) of a simulated organization’s intranet login page.
To grab the interest of the malicious insider, I marked the honey token as a developer account. The malicious insider could use the developer account to not only raise account privileges but also to masquerade as another user.
To make the honey token believable, the HTML can be used to successfully log in to the web application as the credentials are stored within the user’s database table.
When a honey token is used, some optional alerts are generated:
- SMS alert performed through Twilio
- Email alert
- Slack alert
- The alert is written to a log file in JSON format.
The importance of logging the alert to a JSON file is that some basic statistics can be generated. For example, the time frame, as well as frequency, are calculated. Furthermore, the threat categorization (high/ medium/ low) are also calculated; based on the frequency of attack.
My full project code is posted on my GitHub profile.
Criticisms of my work
I realize that perhaps my developments are not so realistic in today’s situation, where secure software developers will not place login credentials within the HTML comments. Furthermore, with single sign-on (SSO) increasingly being used, manual logins are naturally being used less.