Confusing Inconvenience for Enterprise Security: A Real-Life Case
Recently I spent a few minutes talking to a good, long-time friend of mine who manages a source code organization about some of the ramifications of an exfiltration of Intellectual Property.
That's right, their organization had some serious issues with developers actively stealing source code that was considered intellectual property, and selling (or attempting to) sell it off to a hostile nation-state.
The result of this type of event on an organization that lives and dies by their source code and resultant automation is probably best likened to what happened to airport security after 9/11.
When a problem that has been largely ignored for years all of the sudden causes immense pain on the organization, the result is an often unhealthy and rash reaction that is mostly grounded in fear and 'the need to do something' rather than a sane approach to securing the assets.
Much like airport security, much of the result to this organization is an increasingly complex, overly harsh set of policies and practices - leading mostly to inconvenience, and not as much better security.
Since this organization combines in-house and off-shore development teams, the tangle between code repositories is getting crazy. What has essentially happened is that passwords have been deemed "not good enough" so they're after some type of "crazy PKI solution" as my friend puts it, and he points out that "it's likely that no one has done this before"... which makes me wonder.
Now, it's not necessarily bad that no one has done anything like that before (that they/I know of)... but it brings to mind a question of whether building something from scratch is the right approach?
How often do we as security folks find that someone decided to build their own encryption or authentication system from scratch, avoiding using something industry-proven, only to fail miserably in implementation or design?
Avoiding FTP in favor of SCP is one thing, but having to write custom-scripted SCP handlers to limit per-user via pattern matching based on the SSH key used, that's a little dangerous.
Some of the smarter implementations have included locking out all USB-based peripherals, and disabling outbound access to dangerous services such as DropBox and others... but then the convolution of sane and over-the-top restrictions steps in and makes for one heck of a complex environment... and we all know how well complexity works to aid security right?
Imagine needing access to some software dev tools, or a build machine which required you to jump through a "logging box" where you had to SSH in, using rbash of all things, and through, to get to the things you really needed. Is that ratcheting up security, or just adding to the theater of it all and creating more user annoyance?
It's often difficult to tell where theater ends and real security begins ...if you're an end-user. Perhaps that's the point? But what about that malicious user who will be smart enough to get around the controls you implement that annoy the benign users and draw down their productivity? More on this in a moment.
Here's an interesting quote when I asked for some of the more annoying features from a development manager's perspective:
"well we had to change the group memberships on a per team basis, protect the source code repositories based on those groups... we had to split up our continuous integration servers on a per-team basis as well as ... we are looking at repository managers to prevent people from accessing jarfiles from other teams unless it is explicitly allowed to them we also had to accelerate our migration from one source code repository type to another to introduce per-person level of access control to each individual repository and branch so that of course impacts teams..."
That's ... fascinating. While I see some very real value in there for security, I think a good chunk of it is just reactionary, and has to cost a fortune to segment and separate all this hardware, unless you're virtualizing (or going cloud) in which case an entirely different security paradigm needs to be applied.
In the end, I think this probably impacts productivity and adds only marginally to security value over what a 'good enough' solution would be.
I've written multiple times on how a knee-jerk reaction to a security lapse is a very, very bad idea ...and I'm not saying this org's restructuring is necessarily a bad idea, but we have to consider the equilibrium of productivity, cost and security. Often times we laugh and say you can have something be usable, cheap, secure - pick any two of those.
Can your organization afford to put more emphasis on security than productivity? What happens when the wow factor of a data breach wears out and you're left with a tangled mess of security controls which are causing productivity lapses? If you're like most organizations I've worked with and talked to ...you'll un-jumble the mess and go back to pre-breach security. This isn't the right approach.
Building security 'sanely' is very difficult, especially when the pressure is on to do something while the pain of the breach is still there, and money is available to spent. I urge you, friends and colleagues, be sane.
Don't just dump lots of random, complex, unproductive controls onto your organization. Fear the backlash of productivity loss and angry users. Remember that if you can't justify what you're done when the sting of the breach has faded, you won't be a hero but probably unemployed.
Here are some simple tips...
- Be able to identify your users and their roles across systems & tasks (AuthN and AuthZ are critical)
- Follow the 'least privilege needed to perform your job' rule
- Avoid shared accounts
- Seek to protect the data rather than its use or host
- Segment systems (in an office, data center, or cloud) into 'security zones' based on task, sensitivity
- People were, are, and will be your weakest link - over-communicate learning smart security
- Carefully monitor inbound/outbound data from security zones (be careful not to blind yourself with 'encryption')
Down the Rabbithole Podcast: http://podcast.wh1t3rabbit.net
Cross-posted from Following the White Rabbit