At Impacta, one of the core values we have is to always innovate. Find new, better and more creative ways to solve today and tomorrow’s online risk (security, privacy, etc.) problems. In fact, our company motto is literally ”Innovations that Inpsire” to speak to that core value. I just had one of those unexpected moments today that got the wheels turning and inspired me to think about the need for new innovation in the security space. Read on and you’ll see why.
I was emailing an old developer friend of mine earlier today who I was asking if he had a security book that I was sure he had. We’ll call him Brad to protect his identity (call him Brad Pitt to add to the illusion and mystery if you really want). The conversation was short, sweet and inspiring:
- Kevin Lam: “Hey Brad, do you have that book on threat modeling from way back? I need to borrow it.”
- Brad Pitt: “Umm no (I don’t have that book). That would require me to actually care about security …”
Now, you have to understand that Brad says stuff like this all the time and we love him for it, but his comment got me really thinking: why would developers care about security? More precisely, should developers have to care about security? The answer I came to is … “no, developers should not have to care about security*” (note the asterisk, since I know this is going to ruffle a lot of feathers real soon). Let me elaborate.
Today, most security regimens looks like this. Developers need to run tools, developers need to analyze vulnerabilities, developers need to fix vulnerabilities, developers need to attend this course, developers need to this and that.
- Strike 1. Developers are forced to get involved and spend time on every nitty gritty detail of security, on top of their actual jobs.
- Strike 2. We’re also asking them to do their jobs differently than what they are used to.
- Strike 3. Worse, instead of becoming part of the process, security is the process.
Imagine we started asking major league baseball players to catch line drives with their teeth, instead of with their gloves? That’s a little extreme example, maybe even a bad one, but you get the idea. How jazzed up would you be if someone told you this is how you do your job from now on and gave you more work? Could this be in part why some developers are so resistant to anything security related and possibly why security is still a major struggle for most organizations? Developers should be involved, but do they have to be involved in every little detail? How about engaging developers only when really necessary?
To help drive sustained adoption of security and all that good stuff, my gut feeling is that the next generation of security solutions (tools and people) need to demonstrate value by “look how much easier I (the security solution) made your (the developer) life, because I took care of the majority of work that I could do myself for you, and the few times that I had to derail you from your actual job was because I needed your expertise.” Show developers how security can be a good thing for them and the business. Contrast this value proposition to today’s which says “look how many vulnerabilities I found for you, I am not sure which one ares real and which ones are noise, but look how many I found!” (read: look how much more work is coming down the pipe for you).
I might be completely out in left field with this gut feeling of mine (heck, I may be even out in the far parking lot underneath a car) and the way that security is handled now is the way it should be (constantly butting heads, political plays to get out of fixing vulnerabilities, you versus me, cats versus dogs), but I got a good feeling. Of course I don’t have the complete answer right now, just a little spark in me that makes me think some change is needed. What do you think?
Anyhow, a little humor, a little inspiration and hopefully a lot of innovation in the coming year – what a way to ring in the New Year! Alright, see you all in 2009 and stay safe — and of course thanks Brad Pitt!
–Kevin
3 Comments
Kevin,
Interesting comments, but the one that is missing is that the developers continue to ignore their responsibilities for writing secure code and following the security standards as well as best business practices – for which they are well paid.
So using your ballplayer analogy, let’s pay him for every ball he catches not just for being on the field – and I don’t care what he uses, teeth, butt face, I don’t care – catch the ball and make the play – and you get paid, don’t and you don’t.
The problem is everywhere – it’s called accountability and nobody wants to hear it, the mechanic working on your car, the ballplayer, the business owner, etc. But when the software goes bad or the line drive gets missed, it’s always the coaches, glove manufactures, sunglass manufacturer, etc. fault or the Security guy that did not review the code or made it to tough for the developer to write good code correctly – regardless of the fact hat he has failed to keep his skills updated for Web 2.0 or new Java or Oracle 11 – security made it too hard because they take the arrow in the neck when the code fails and data is lost – how many developers lose their jobs when a data breach occurs versus the CISO or his staff? Now that would be a metric to have when discussing performance reviews.
I submit that developers need to be responsible for a quality product and they need to articulate to management what tools it will take to do that, and management needs to support those needs – Security is just the Q&A to determine if the developer lived up to the agreement and the organizations security policies for data and information, and THEN hold the developers accountable.
It is like a contract for paining my house – the painter does not get to pick the color, nor does he get to tell me that the overspray on the windows and the empty paint cans in the yard are my problem – if he does I don’t pay him until I get what we agreed – overspray is not in the contract for clean up, but it is a best practice for painters that it should not occur and when it does they fix it.
BTW, security is not about making the developers life easy, it’s about protecting the company’s brand image and information, the customer’s data and the business integrity. When this becomes the accepted norm, both security and development can move forward.
Chuck, thanks for taking the time to post and sharing your comments! Some great thoughts you shared there!
You’re right, security isn’t just about making developers life’s easy, but I think that if you want security best practices to widely adopted and most of all sustained — I think security has to be made as easy as possible (of course not all of it will be easy ;P). If you boil it down right down to the bones, security = extra work. Worse, it’s extra work that the developers don’t want to do (if they did, it would have been done in the first place). So how do you get someone who does not inherently share the same goals as you do (make ‘stuff secure’)? You can (1) make the work that they have to do for you as minimally instrusive as possible or (2) you blend your goal into their goal, or (3) force them develop stuff that is secure. I would agrue that today’s approaches do not align to either (1) or (2) and for some organizations not even (3) <– within some organizations, security just isn’t a priority at all.
I liked your comment (your first paragraph) about developing ignoring their responsibilities for writing secure code (for which they are paid), because it brings light to an interesting reality: security is nebulous. I’ve seen developer job descriptions that do say the requirement is to develop secure software, but what does secure look like? From a functional perspective, that’s easy — you follow the design from the architects and when it meets all the business requirements laid out that’s success. But how does a developer know what success looks like with regards to security? When it’s free from all buffer overflows, SQL injections and other nasties … well how do you know? I think ‘security’ is one of those things that are just thrown out there, but not well defined — kind of like saying to a developer, make sure this application is fun :)
Anyways, great stuff again Chuck, and thanks again for taking the time to post!
–Kevin
Kevin et al, BTW feel free to jump in anyone!
I think we are (all of security for the most part) on the same page. What is security? What does writing secure code mean – today it’s good and tomorrow it’s full of holes – and it only takes one to get you the front page! What accountability do the vendors carry to make sure there code is backward compatible security capability?
My thinking is that developers – no, make that everybody from the top down – needs to understand that they have a responsibility to the business and the customer when it comes to security.
The NC State Employees Federal Credit Union just announced a breach last night – so am I going to keep my money there any more? No, and I wonder how many others will pull back business thus lowering deposits and thus lowering the ability to loan money and service member needs.
Do the folks supporting that business really understand what that means to their jobs in the long run? I don’t think they do and if they did, they might have more buy-in to keeping security on the front burner and not a bolt on.
Vendor accountibiltiy is more problematic – perhaps we need to institute a recall process for software like we have for vehicles and appliances where safety issues are concerned – make them security recalls and force fixes as part of the purchase and support contract language. I must be dreaming on this one!
So, how do we equate maintaining security with on-going employment so that everyone from the CEO to the Janitor understands their role in keeping the integrity, confidentiality and availability of the business viable as part of the mission activity – each and every day – therein lies the challenge for every CEO, CIO and CISO?
* First – Make Security part of the performance rating for employee, just like meeting production or sales goals – any breach should affect everyone on a sliding scale, based on how the breach occurred.
* Second – Put a reward/bounty system in place for those finding the security holes before they are exercised – of course if these folks are finding their own bad work, out they go!
* Third – Make code review processes and tools that are less painful and easy to use and follow, AND less expensive – sometimes cost gets in the way of a solid review and thus we spiral downward – “pay me now or pay me later”, chances are you are really good that you are going to pay me.
* Fourth – Require time be used in the project for security reviews – hold the program manager accountable for this each and every time until it is part of the culture – nothing moves without the review – and I mean during the development not at the 11th hour when the software or application or infrastructure delivery pressure can get senior management to override the security review requirements!
* Fifth – The Board of Directors should hold senior management responsible for providing the support for the above security review processes – Audits of the processes should go right to the Board for CEO/CIO/CISO performance discussions.
* Sixth or first – Security Awareness must be ingrained in everyone and it must carry constant reinforcement and corporate value – not just pretty pictures and posters with quips about other companies problems but through accountability – failure to follow the processes should have consequence, that is commensurate with the exposure created – in the USPS if you steal or interfere with the delivery of the mail, you will get fired and you could go to jail, but rest assured, you will get fired! Once theft is on your record where are you going to work next?
With Identity theft and account pirating running rampant these days, I am surprised at the seeming acceptance by the general public that this is the best it can be and not much can be done to prevent it.
The nation of sheep continues to follow the trail through the pasture of the sheep before us – how do we as security professionals get them off the path to better grazing (love the analogy)? I guess that falls to us – the Security Professional to find new and better ways to educate.
We need to get into the elementary, middle and High Schools with the message of security – that sharing your information could get you in trouble – maybe not today but perhaps tomorrow – that iTunes gift card just got credited to somebody else’s account – all that babysitting or lawn mowing money is gone, and you can’t get it back because there is no way to prove that it was your card anyway. Look at what is happening with these kids sending nude photos of themselves on Myspace and Youtube – prosecution for Child Porn – regardless of age, not that sends a message to a parent – get you kid labeled as a sex offender before their 16th birthday – now what?
Anyway these are my rants for today – Great discussion – Thanks
Chuck