#EntSec -- Not Business Relevant

Wednesday, October 26, 2011

Ali-Reza Anghaie

Bd623fa766512fdf6b57db66f522b741

When Rafal Los (@Wh1t3Rabbit) asked people to describe Enterprise Security in three words I took the humor approach with selections like "Complete Cluster Fsck" and "Advanced Persistent Marketing".

Rafal was kind enough to post a running document with all suggestions for reference at http://t.co/iqWlkudO and a blog post at http://bolt.thexfil.es/3sqzj. Now, I was being quite cynical in my responses but I do have very serious and strong feelings about this topic.

Enterprise Security is Not Business Relevant. Now, that's quite the inflammatory statement but unless your business is security then it's true in practice today. Before the flaming begins let me start by saying I believe firmly it ~IS~ business critical but I want to make it actually _relevant_.

I'm going to briefly explore what this means to me:

  • Security needs to produce better product
  • Security needs to provide product, service, and visibility to the core business
  • Security needs to instill trust and good faith amongst employees and customers
  • Security needs to be a competitive advantage

I'm going to talk about the first point in this post; Security needs to produce better product.

I'm not talking about Security vendors here, I'm talking about Enterprise Security departments within industrials, banks, pharmaceuticals, etc. Security and privacy offers all stages of the product lifecycle lessons, expertise, and benefits not immediately thought of by most internal customers.

Some examples:

  • Security Engineering frequently identifies bugs and incompatibilities that present themselves in non-traditional or internationalized use-cases. Or with popular but untested software and up-and-coming standards. I've yet to see a security oriented code review that didn't improve the tightness, readability, documentation, etc. of code. Or that didn't also improve stability and compatibility in some aspect or another.
  • Techniques used by security professionals can be used to improve the performance and stability of almost any production environment. We look at things through the lens of DTrace or Packet Captures in a way most people do not. Working alongside developers and systems administrators in this way can yield, once again, better development and product.
  • Security professionals can instill in your staff better overall intellectual property protections by also making the privacy and security of the end-user product better. When devops consider the end-user privacy in the context of their own then they will also further that practice with enterprise data. (This parallels what I've referred to as 'Security through undoing Facebook' which I will re-visit in another post.)
  • Security professionals have almost endless bandwidth for understanding innovation. This is somewhat vague and arrogant but I truly believe it from what I've seen over the past fifteen years. Security professionals can "get" almost anything you're trying to do and brainstorm and critique with the best of people. It's not something that is taught, I just believe it's something that also draws people to the security field.

Taking these examples and trying to put them into practice and play is non-trivial in most environments. There are institutional barriers, egos (our own included), hours in a day, etc. that all get in the way. However, it's critical that Security becomes more engrained in the production of product and thus business relevant if we ever want to get the funding, respect, and eventually rest we all desire.

How do I suggest you do this? Well, my first and most important step would be to actually ~DO~ it. Seriously... start with the developers and see if they have a bug system you can peruse, check out a copy of their code, submit a patch. Work with them in an agile environment. That's effectively your road-show to the developers. Just get in the muck and pain with them without prejudice or reservation.

Don't differentiate yourself in any way except the output. Comments, patches, etc. You might have to learn new APIs or languages even but it's about bleeding with them for their blood in return. Secondly provide unsolicited observations of the end-product in well written, visualized if possible, and non-judgmental ways.

Over a decade ago I first did this with a few page analysis of the core daemon for a software product. I provided information based on profiling, disk IO, network traffic, etc. that was all of interest to me in building a security model BUT I didn't say any of that. I just provided it to them in the numerous contexts of improving their product performance, lessening infrastructure dependencies, and improving stability.

By the time they got done appreciating and implementing all that I only had a minimal number of "security" issues to address and they were more than happy to oblige. This lesson stuck with me ever since and it's been endlessly valuable.

And finally you evangelize and take pride in your companies products and services. We're a cynical bunch but we can be fanboys too. Try it sometime and those who fund you and you need to influence will appreciate it. It's not social engineering exactly.. well...

OK, so it is in a sense but you'll be happier for it I wager.

That's the short of it for now. I will build on this basis in future posts and appreciate any feedback.

Cheers, -Ali

Cross-posted from Packetknife's Space

Possibly Related Articles:
13685
Enterprise Security Management Social Engineering Data Loss Prevention Security Infosec
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.