Nothing gets me going in the morning like a good ol' fashioned dust-up over "security" measures interfering with my ability to get stuff done. It just reminds me of how far we still have to go in order to fix all the wrongs of our past lives. Here are three (3) areas in which I think infosec fails people and shoots itself in the foot, undermining credibility for the future.
1) It gets in the way. Tying into that legacy concept of security's "culture of no," we seem to have a tendency to get in the way. We've created the enablement culture where we tell everyone else "don't worry, we'll take of security," but then we've screwed that up, too. And then when people actually need to get stuff done, rather than helping them, we mire them in process and policy and bureaucratic inanity. It's no wonder developers and business leaders eagerly plop down a credit card to by cloud-based computing services that allow them to quickly bypass all our stupidity!
2) It makes life more difficult. Control for the sake of control can be problematic. Security measures need to be easy and comprehensible whenever possible. Surreptitious changes that negatively impact peoples' ability to get work done is a bad thing, and it will not have a positive outcome for your efforts. Case-in-point, OWASP made a change recently to only allow owasp.org domain accounts to have access to their Google Apps instance. All good and fine in theory, except that it wasn't communicated (that I'm aware of), and it blocked me from conducting chapter business (updating a calendar of all things) because a) my personal account no longer worked, b) someone then had to add my owasp.org account to the calendar, and c) I somehow failed to record my new password for a forced owasp.org account update due to a (potential) security incident and account clean-up effort. If we make things more difficult and don't communicate that changes are happening and why they're needed, then we shouldn't be surprised when people get perturbed, frustrated, or simply find ways to bypass security altogether.
3) It doesn't understand what's important. I have a whole separate post brewing on the topic of "impact" and "value," but let's boil this down real quick: What's important is allowing the business to operate, thrive, and grow. That means not impeding key processes. It means helping ensure that every dollar spent on technology is done so wisely, and not out of some sense of "shiny object syndrome" or because such-n-such vendor says their tech is a "must have" for the year. More often than not, infosec people have a lousy reputation for failing to "get it" in terms of what is important to the business. This topic is well beyond simple IT realignment theory. It's a fundamental disconnect. Your job as a security professional is not to "stop bad things from happening" - it's to protect the business while allowing it to function. Understand all that that statement means and you'll be much better off in the future.
AND... finally... a bonus point to drive things home... says Gunnar Peterson:
We shouldn't look at security as a one off, an isolated department of "specialists", but rather leave the ivory tower and look for tools, processes, and training that help the people on this list do their jobs better. Making it faster, better, cheaper and easier to consume and integrate security services into their daily work is the biggest security influencer of all.
So... a little bit of a rant to help you get through the middle of your week. Fire up! :)
How exactly does security work and yet not get in the way? Isn't that inherent?
To your second point, and while it may not be the core point, but maybe you made things difficult by not using a standard account to access Google Apps? :) I understand your point, but in many cases people do things wrong and then blame security. It's like giving an angry glare to the curb on the side of the street because it bumped into you on a snowy, slippery day.
This isn't me arguing or angry so much as just discussion-banter.
In fact, let's just dive into item #3. Even something like ISU and standards may impede processes. But it does so in the hopes that in the long run a process will withstand adversity, be predictable, documented, and understood by everyone. Often, security gets misunderstood as control for the sake of control, rather than control for the sake of the business, stability, predictability, and security. At least, that's my token devil's advocate on that. :)
Cheers!
Thanks for commenting!
I do believe that security can be implemented without getting in the way. A big piece of this is getting away from the "party of 'no'" philosophy that has been pervasive. Our job is not to say 'no' to requests, but to help reduce the risk factors and associated liabilities associated with allowing business to function. This is a huge paradigm shift that has been much discussed in the past decade, but is only now starting to come to fruition.
On the Google Apps matter... I was using a standard account... the issue was that the rules were changed, not communicated, and I was effectively locked out, which prevented me from completing official OWASP chapter business. There were specific security reasons for the config change, but the execution was flawed, and it resulted in making life more difficult, even though there was no real evidence that the changes made would actually address the perceived weaknesses.
On your last points, I'm not sure I know what you're referring to with "ISU." That said, there's not much to argue with. My point, however, really ties more into this post:
http://www.secureconsulting.net/2011/12/impact-value-and-whats-important.html
There's a reason security is "misunderstood as control for the sake of control" - oftentimes it's just that. Foisting requirements and limitations onto the business that make it less agile, less responsive, less profitable, and less functionally capable are not inherently sound. If you start from the perspective of "What is most important to the business?" and then derive security measures accordingly, then I think you'll find people are less resistant and more appreciative. Unfortunately, we (as an industry) tend to flog notions based on a threat-centric perspective that mean nothing to the business, rather than starting from the perspective of "The business says X is critical to the business." and working backwards from there. For example, if the business says that web site uptime is most important, then you can easily justify various measures that protect that objective, or at least provide reasonable trade-off decisions. However, if you start from the perspective of "there are lots of threats out there that could DDoS us off the web" without knowing whether or not the impact on uptime matters to the business, then you're arguments will derail and spin off into weirdness, and often into a losing argument.
That, at least, has been - and continues to be - my experience. But, then, I tend to view things a bit differently...
cheers!