Daniel Fortunov's Adventures in Software Development » Thoughts on software security
0 Comments
- Add comment |
Back to Software Development Blog Written on 01-May-2009 by asqui
Security is a thorny issue that can often come back to bite you. The main problem is that people don’t inherently think about security until it becomes a problem (unless they happen to be sitting across from Bruce Schneier and staring him in the eyes — in which case they already have a bigger problem). It became a big problem for Microsoft, so now they do threat modelling as part of the design for every new product feature.
A few years ago I was presenting a paper at the annual IEEE Engineering in Medicine and Biology Society conference in New York, and I attended a presentation about a pacemaker device which was remotely re-programmable. I think the idea was to allow tuning and refinements without invasive surgery. There was no mention of security during the presentation. We’re talking about a remotely programmable pacemaker here… I questioned security at the end but the presenter did not seem concerned. I guess it hadn’t been a problem yet. (And I’m not sure if medical devices are subject to threat modelling, yet.)
Security is a big issue on the internet because the interconnectedness that provides much of the value of the internet is also its Achilles’ heel in terms of large-scale automated attack and exploitation. In areas such as internal software development, it’s not such a big consideration because the software is deemed to be isolated enough from the internet by firewalls and other protection (more on insider attacks another day).
The problem is that security costs money, and requires expertise. It is a burden that you must carry through any refactoring, optimisations, or other changes to the software. Until lack of security becomes a problem, it is hard to trade off a hypothetical threat that most people don’t think about, against the potential goodness of not having to worry about security (be it faster completion, more features, smaller budget, etc.).
By the time security becomes a problem, it’s often too late. (Pacemaker-B-Gone, anyone?) Introducing security late in the software development life-cycle is an uphill battle when it hasn’t been designed-in from the ground up. Introducing security to a pacemaker that has already been “installed” might be even more of a challenge.