Secure Design Principles — Insider Threat

DZone 's Guide to

Secure Design Principles — Insider Threat

A look at how to combat the security threat of insiders who want to do harm, presented by Zone Leader Christopher Lamb.

· DevOps Zone ·
Free Resource

As we were just about to hit 1980 and all the silliness that ensued, Dorothy and Peter Denning wrote another paper on cyber-security principles. While Saltzer and Schroeder and Turn and Ware were looking more toward general controls we could use to keep information safe, the Dennings looked at insider threat.

Today, we know that insider threat is kind of a big deal. Our more spectacular recent data breaches were insider orchestrated, in fact. The Dennings were certainly on the right track. Not only do insider breaches tend to be more harmful than externally-orchestrated breaches, they’re also more difficult to detect. After all, insiders know how to best attack the systems they work with every day, they know the data that’s the most valuable, and they know how to hide.

Access Controls

Common constructs today, access controls weren’t as widely deployed back in the late seventies as they are now. Nor are they as widely deployed today as they should be. Not only should access controls be used, they should allow for granular activity logging. So many systems today are built with application-level credentials - don’t do this! This gives you no visibility into who is doing what within your applications. Without that, you can’t effectively monitor for access and use. If you have an application with users, ensure that all access to data and functionality is limited by the user identity, not the identity of the system.

Flow Controls

Flow controls can be more difficult to implement as they’re not usually something you can configure through a single point of access. We do use flow controls extensively today - after all, that’s basically what firewalls do, what VLANs enable, and what software defined networking was built around. These flow controls are usually managed using tools and even organizations that are completely removed from application engineers, and that’s what makes implementing flow control so difficult. It’s hard enough to configure access controls over systems you control. Imagine having to do that when working with a completely separate department, with completely different goals. It’s still worth pursuing though - if an attacker needs to route sensitive traffic to a point where he can record it, he will. Try to make sure he can’t.

Inference Controls

Over the past few years, companies have spent millions collecting information on their customers from every data source they can get their hands on (and a few they probably shouldn’t). By pulling together things like your cell phone location, or what you’ve bought, or information from your home computer, or information from tracking data brokers, they can build remarkably accurate pictures of your behavior and purchasing habits. This same kind of approach can be used to de-anonymize information as well, with profoundly negative consequences (.e.g. HIPAA, for those of us in the US). Try to make sure that any sensitive data you collect, if anonymized as part of your data management strategy, is well segregated from information that can compromise its anonymity.


Wait a minute, haven’t we seen this one already? well, yes we have. Turn and Ware were fans of encryption too. Appropriately too! Everyone should be. Just make sure you implement it correctly, and don’t leak your keys.

This is the first paper where we start to see some principle overlap. This is a good sign - this means that we’re getting closer to having a complete list of principles we need to keep our eyes on.

design, security

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}