Why do organizations often tend to introduce more complexity! Complexity is harmful for security ("KISS" principle)
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 :-)
2 comments:
I think you're missing a key point, and that's differentiating between what I would call "technical" vs. "engineering" complexity. Yes, all of computing is effectively rife with complexity, but that's not really what we're talking about when we say "complexity is the enemy of security." Rather, we're typically talking about the complexity of a given solution from an engineering (or perhaps design) perspective. For example, developers using known good crypto libraries vs. trying to roll their own crypto functions. Or using built-in HTTPS capabilities vs. rolling custom SSL/TLS calls from scratch, or even built on libraries like OpenSSL.
As for your UNIX admin example, while you look at the complexity of the technical details of the solution, you gloss over the decreased complexity of managing large numbers of users at scale. It's far more complex to manage all identities when each system has it's own unique user repository vs. integrating those systems into a standardized IAM engine. So while the minutiae of the specific integration component is more complex than not integrating, you overlook the complexity of the overall environment, which is actually decreased, with commensurate decreases in admin load. Then factor in standardized builds with the integration component pre-configured and viola! you have substantially decreased overall complexity.
Hey Ben, how's it go?
I'm skipping your crypto example because I smell a red herring or a straw man, I can't tell, sorry :-)
Definition time:
complexity: the state or quality of being intricate or complicated
burden: a duty or misfortune that causes hardship, anxiety, or grief
Being my example, I'm allowed to gloss over what I want :-) But, burdensome != complexity. It's more burdensome to manage accounts on separate servers, but not more complex. It's no less intricate or complicated to add a user today as it was yesterday. It might be more burdensome to add ten accounts today when someone had to only add five yesterday. The sysadmin logs in, adds a user or many, and is done. How is this complex? Inefficient? Sure. A pain? Yep. Give the guy a spreadsheet and say add these users and delete these users is complex? No, not at all.
Building off of this, is it more or less complex to install a new system that inventories, scans, and possibly updates patches missing on a server? It's more, from a technical, engineering, and process stance. Anytime automation is brought in, engineering complexity increases until the system is at a steady state. Then, eventually processes catch up and the technology is predictable. Until then, there's churn. And, to get that churn took adding complexity in the first place.
Maybe we're agreeing about the same thing. Or not.
What about OAuth versus checking a password against a store of passwords (or hashes)? The latter has been the predominate pattern for authenticating a principle since I've been alive. OAuth is newer and a bit more complex (http://tools.ietf.org/html/draft-ietf-oauth-v2-11.). Instead of me checking my database of credential tokens, I have to play a silly game passing tokens, signing stuff, etc. Seems a bit more complex than looking up a hash in a database... Now, look at SAML and the complexity goes up more. (I secretly think the OAuth people are trying to converge onto SAML, but don't tell Gunnar!)
Now, I'm not knocking anything that is more simple. Given a simple and a complex process in doing something, if both operate in the same time complexities and have commensurate security properties, Occam might choose the simpler one and I'd probably agree. I just don't see complexity as the root of all evil in security.
Post a Comment