Complexity != Insecurity

Why do organizations often tend to introduce more complexity! Complexity is harmful for security ("KISS" principle) - @xme

I saw this tweet this morning and cried again. It was a really long cry. Actually, it was sweat going into my eyes because I'm out of shape and on the elliptical. Pretend they were tears of sadness!

Complexity does not equal insecurity. Complexity is not harmful for security. Heck, complexity is welcomed! Sometimes... And, arguably, sometimes not. Complexity can be needed for security, scalability, and consistency. And brother, I'm gonna preach on why.

Complexity Needed For Security

This is a cheap shot. Tell me, what's more of a complex protocol? HTTP or HTTP over a TLS connection? Think TLS isn't complex? It is. But its complexity and functionality add confidentiality, integrity, and authentication to a connection that doesn't directly offer those features. I won't focus on this one, but think about it.

Complexity Needed for Scalability

Before venturing here, be familiar with Big O notation. At least don't be afraid of O(1), O(N), and O(c^N).

UNIX systems manage passwords via a shadow or master password file. A sysadmin managing a small number of UNIX systems may be inclined to manually make updates to these files via their supported methods. The sysadmin might have to infrequently add or delete accounts, as needed and requested. This is very manageable and scales well to the scenario.

The sysadmin didn't realize his company would explode in growth over the next year. Each week brought on scores and scores of new employees and also the need for more and more servers. Now, instead of managing a couple changes a day over a couple systems, the sysadmin is coping with numerous changes a day, across a growing expanse of systems. Performing this manually is time consuming and also adds inflexibility if the sysadmin needs to quickly disable access.

The sysadmin, being lazy, hooks up to the company's Active Directory instance via LDAP. Now, the sysadmin needs to modify PAM modules (authentication) and name service lookups (authorization) across all of these systems. The sysadmin has effectively increased the complexity of a login from a local lookup to a remote lookup because a procedure that was O(N*M) for a small number of users (N) and a small number of servers (M) is inappropriate for larger sizes of N and M. And the sysadmin gets a security benefit by being able to quickly lock out or disable an account if needed. Is this added complexity more or less insecure?

Complexity Needed for Consistency

Building upon the LDAP example, the sysadmin was managing just CentOS servers. After the growth, the servers were made up of Solaris, CentOS, Redhat and FreeBSD because of business needs. Each of these had different ways to enforce account capabilities and restrictions, such as number of failed attempts before lock out, password complexity and strength, and password expiry days.

Some systems couldn't support what the policy required. Others took time to understand, test, and implement. And others would only work for certain services, say OpenSSH, but not other services, on the server. By having PAM support the authentication and connecting to the LDAP server, the LDAP server can be a single point of control. Or, rather in Big O notation, the sysadmin reduced an O(N) problem to an O(1) problem, with N being the number of servers needing the change. Oh, and I won't mention that the sysadmin will add some more complexity by using STARTTLS with his LDAP implementation to not disclose the hashes being sent across the wire ;-)

Trite Examples, Blah!

Perhaps. The point I'm trying to make is that complexity isn't and shouldn't be viewed as a bastard in the eyes of security. It's not. If the goal of complexity is commensurate with security goals, then it's a win. If complexity changes a process from O(N) to O(1), awesome! If complexity actually adds security at little perceived loss, even better. So, please, if you're gonna beat up on complexity, at least say unnecessary complexity. Because there's a lot of complexity out there that's keeping us secure, and it's a good thing :-)

Threat Modeling, Attack Trees, Call Graphs, Oh My!

Let's say I'm able to dynamically and statically analyze an application running on some platform. This analysis is so full of awesome that it enumerates every entry and exit point in the application. It enumerates all ways that data is touched, modified or/and returned to the user of the application. It understands authentication and authorization, from the interface down to the underlying operating system.

So what. Really, who cares. There's absolutely no context with this contrived analysis. Let's say that the application above only accesses information deemed public by the application owner. Let's say that the machine has no way to pivot to any other resources: an island. Then what? And why am I wasting time on a post like this that seems pretty obvious?

We have threat modeling, attack trees, call graphs, and everything at our disposal. Automation can get us far, but without subjective context, especially on asset valuation, everything looks the same. I'm all for measurements. We're no where near as an industry in enumerating what applications can do, what they touch, and even how to process all of this information. But even if we were, we would still be silly and mark a remotely exploitable vulnerability that popped root on this application as a "high", whatever that means. Whereas in reality, this asset has such little value that it's not even worth including its system name in a report.

We do not do a good job assessing asset values, however subjective. Yes, there's value for an attacker. At a minimum, can I pivot from this host? Can I now access something I wasn't able to access before? These are valid and should be called out if there's reason to. But, what about the data? Not all assets are equal and we should stop treating them as they are.