The Valley of Death Between IT and Infosec

Friday, August 13, 2010

Danny Lieberman


Not so long ago – when a company (business unit, department, or manager) wanted to develop a line of business software application, they would do a system analysis starting with business requirements and then proceed to develop the application and deploy it.

Things have changed. Packaged software and Web applications that the CEO’s niece can whip together in a week, have replaced structured systems development.

There are of course,  good things about not having a design (like not coming down with an advanced case of analysis paralysis) and iterating quickly to a better product, but the downside of not developing software according to a structured systems design methodology is insecure software.

So called security development methodologies are band-aids on deep cuts, that cannot replace a serious look at business requirements followed by a structured process of implementation.

There is a fundamental divide, a metaphorical valley of death of mentality and skill sets between IT and security professionals.  IT is about executing predictable business processes. Security is about reducing the impact of unpredictable events.

IT’s “best practice” security in 2010 is  firewall/IPS/AV.  Faced with unconventional threats  (for example a combination of trusted contractors exploiting defective software applications), IT staffers  tend to seek a vendor-proposed, one-size-fits-all “solution” instead of performing a first principles threat analysis and discovering  that the problem has nothing to do with malware on the network and everything to do with software defects that may kill customers.

Threat modelling is a lot of hard work, hard data collection and hard analysis.  It’s not a sexy, fun to use, feel-good application like Windows Media Player.  

Risk analysis  may yield results that are not career enhancing, and as  the threats  get deeper and wider  with  bigger and more complex systems – so the IT security valley of death deepens and gets more untraversable.

There is a joke about systems programmers – they have heard that there are real users out there, actually running applications on their systems – but they know it’s only an urban legend. Like any joke, it has a grain of truth. IT and security are primarily systems and procedures-oriented instead of  customer-safety oriented.

Truly – the essence of security is protecting the people who use a company’s products and services. What utility is there in running 24×7 systems that leak 4 million credit cards or developing embedded medical devices that may kill patients?

Clearly – the challenge of running a profitable company that values customer protection must be shouldered by IT and security teams alike.

Around this common challenge, I  propose that IT and security adopt a common goal and a common language – a language  of customer-centric threat modelling - threats, vulnerabilities, attackers, entry points, assets and security countermeasures.  

This may be the best or even only way for IT and security  to traverse the valley of death successfully.

Cross-posted from Israeli Software

Possibly Related Articles:
Enterprise Security
Enterprise Security
Post Rating I Like this!
Fred Williams Good topic Danny, I really enjoy your posts.

Your article makes it sound like iterative development methodologies are not as good as "structured" methodologies.

The move in today's software shops is away from the traditional waterfall analysis method to an Agile methodology. Agile is about lean requirements, lean architecture, and no BRUF (Big requirements up front). The idea is to release some kind of functionality every 2 weeks to production. Get it out in front of the customers - quicker to market.

This doesn't mean that security takes a back seat. You build your security model into your plan and devote an Agile iteration around it. Plan on releasing a bit of security in each deployment.

Of course, I agree the development team has to be aware of secure programming. It's up to the system architects to be knowledgeable enough to build the security in up-front.

But that doesn't mean that iterative development causes more insecure software.
Danny Lieberman Fred,

You bring up a cogent point. Secure agile development.

Designers and developers that use Agile (as I and my colleagues do btw) are always looking for vulnerabilities and striving to improve their code.

I suspect this is the exception rather than the rule in Web applications.

The quality of code that a typical programmer writes is at best questionable. Defective code is insecure code and unfortunately - the Microsoft mono culture doesn't encourage programmers to think...and thinking is at the root of secure code development Churning out a lot of defective code fast is a really bad idea.

I am intimately familiar with the mantra of iterating quickly and getting the application in front of customers and lots of eyeballs.

For a social media application sharing Twitter profiles and pictures of pets it's great. It helps you believe that you are going to get traction and venture capital which is about as likely to happen as ascending to heaven bodily. As long as the coders are happy, I'm happy.

But - for an application that manages medical records and personal data I suggest don't leaving home without a clear understanding of what you need to do at all levels - design, data models, interfaces, operations, contractors...


Danny Lieberman I'm working on a threat analysis of an ASP.NET app for online diagnosis and since it's beginning to look like the war in Iraq - I will take some of my notes and write an article about it in a couple of weeks

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.