I saw this poster for Kiwicon 2009 and needed to save it. Eight years later, the reasons are still relevant, and likely 8 years from now, they’ll still be relevant.

NorkNork is a Windows Powershell Empire reboot persistence detection tool. The down side is it’s written in Python. On the upside, it’s a great Python example of how to do this!

So much of IT and especially infosec is driven by checklists and top ten lists and such. It’s a great way to succinctly get a topic across to someone else, especially when the alternative is a 50 page paper on how, why, and what to fix and do. I saw this TechRepublic article on “10 Tips for Reducing Insider Security Threats,” and was ready to be annoyed at it, but I honestly found it to be a good little list. I would re-order it, personally, and swap out a few items, but overall it frames where this line of thinking should be.

1. Establish a security incident and response team – Is this necessary? Not entirely; but in cases where it’s not, that organization needs at least someone local who cares a little about security and at least thinks about the rest of these items. But in most cases, it’s probably necessary. Hunting insider threats means keeping tight control on permissions, access, and accounts, monitoring logs for weirdness, and staff to configure tools that go the extra (arguable) mile like DLP and egress firewall rules. Honestly, without the staff or team, the organization can only go so far.

2. Use temporary accounts – This is an excellent idea, as account control should be a priority, and no one remembers to remove all of the temporary accounts out there. It’s best to just put them in from the start as a temporary account (along with a description that includes who requested/owns the account). If the account expires and is still needed, it can be re-requested and even it’s password changed at that point. But accounts should neve just linger out there that are no longer needed. And most of the requests like this are for third party vendors or contractors.

3. Conduct frequent audits to look for unused accounts and disable or remove them if possible – This should be done, and dormant accounts should be raised up for review. Just keep in mind there is a difference between user accounts and service-types of accounts, and perform due diligence when disabling these accounts to ensure critical services aren’t impacted. Just like the point of the above item, getting rid of unnecessary accounts is an important function.

4. Follow employee termination principles carefully – To me, once an employee is terminated, they are no longer an insider threat. However, if accounts and access are not terminated promptly, the risk does turn into one that mimicks an insider threat due to their lingering knowledge of internal systems and processes, but also their access to accounts they are already familiar with. A strong terminatation process needs to exist to shut terminated employees out of any and all access. If you trust your IT or infosec teams, they should get notified shortly before a termination and coordinate the timing. No one wants to find out a termination is happening at 5pm on a Friday when IT staff is already at home.

5. Identify unhappy employees – Whenever we talk about disgruntled employees, this really is an HR and managerial process. But it’s one that should also include infosec to some degree in a matured environment. Infosec is tasked with tracking and hunting threats, and an a disgruntled employee is a very big threat. Once a disgruntled employee has been identified, that process should include some sort of notification and some degree of enhanced monitoring or alarming on that employee’s activity. It might be nothing more than putting an account on some sort of yellow alert. Obviously, this is something that will only work in highly trusting environments where infosec has a mature process and heightened sense of integrity so as not to fall into the rumor mills or divulge that someone is flagged. Honestly, I think most of the time this is truly a manager and HR process and it pretty much stops there until an incident occurs and questions start getting asked. If nothing else, like the article states, it may be enough to just have HR/Manager tackle the source of the discontent and fix it.

6. Use two-factor authentication – This is an arguable item when it comes to insider threat, but I think it makes a good inclusion amongst a top 10 list of items. Internal employees will sometimes acquire or find out about account passwords for various other users (secretaries, or help desk staff, or uneducated supervisors…), and limiting the ability to commandeer someone else’s account to do nefarious things is part of the insider security tasks.

7. Use encryption of confidential data either in motion or at rest – Another somewhat arguable item, but again useful on this list in order to illustrate the risk of physical theft of devices or hard disks or backup tapes that contain retrievable data. I’d argue if someone is sniffing and capturing data in motion over the corporate network, there are deeper problems with application control in play.

8. Consider third-party products – The article points out IAM, DLP, and Tripwire as third party tools to fit into this arena, and honestly, that’s a good list to get started. The point is account control and access management, data loss detection, and monitoring for key internal files being accessed or changed. I’d throw in log collection and analyzing (or SIEM) as part of this bullet item, personally, in order to alarm on strangeness.

9. Don’t forget to guard your perimeter – For me personally, this bullet item is not so much an insider threat as it is an intruder that has gotten in. Granted, many of the controls at this point overlap, but I don’t think this bullet item completely fits in here.

10. Consider investments in products and staff more than just “insurance” – I agree with this bullet item, but I’d go beyond just saying this will lower costs of audits and possible impact of incidents. I’d also say that good security processes will help the business run more efficiently on the back end; this can include easier troubleshooting for operations, less hunting through old accounts, and less confusion and mis-handled security tasks that can easily land in a well-defined workflow with the security staff, keeping ops’ time freed up to do ops things. It can also provide better change mangement so that bad changes are more easily found and fixed.

I didn’t like item #9, and poked at a few others. I would personally add a few things as more important:

11 (new). Practice RBAC and document access needs. – This means documenting access needs, defining role-based access needs, and sticking to predictable pactices in regards to permissions and access. Everyone should know what they need access to and what they shouldn’t, and that should be predictable and defined so that things out of the ordinary don’t mysteriously occur that result in one employee having more access than they should and no one knows about it until they do something bad.

12 (new). Limit internal access to only what users needs, including workstation rights. – This follows the above item pretty closely in defining least privileges, but I prefer this to be a separate bullet in order to isolate the control over workstations rights and what someone can do on their workstation, such as installing Wireshark or some other nefarious tools that can turn an insider’s workstation into an insider attack platform.