* Modern approach to programming could cause software vulnerabilities
Last time, I was rattling on about how it seemed the march of security vulnerabilities leading to patches leading to new vulnerabilities was never-ending, and that was a depressing thought. While we want Microsoft to continue to fix any holes that allow our networks’ security to be compromised, we really don’t want it to turn into a “skyscraper” job, where the window washers on a towering skyscraper, once they finish the last window, need to start over again at the first one because it’s now dirty again. Their job is never done and there is never a time when all of the windows are sparkling clean.
Last time, I was rattling on about how it seemed the march of security vulnerabilities leading to patches leading to new vulnerabilities was never-ending, and that was a depressing thought. While we want Microsoft to continue to fix any holes that allow our networks’ security to be compromised, we really don’t want it to turn into a “skyscraper” job, where the window washers on a towering skyscraper, once they finish the last window, need to start over again at the first one because it’s now dirty again. Their job is never done and there is never a time when all of the windows are sparkling clean.
Another analogy might be crabgrass. You can examine your lawn every day (or, for a better analogy, once a month) and dig up any crab grass you find. But the next day (or next month) there’ll be more of the noxious weed to remove. What you really need to do, instead, is to create an environment where crabgrass cannot grow.
Can Microsoft create an environment where security vulnerabilities do not open up?
The “Trustworthy Computing” Initiative was supposed to do just that. It was supposed to refocus the company’s priorities away from new features and user friendliness onto better security and manageability. The major change we’ve seen is that default behavior has been modified for many products. Rather than the previous “allow that which isn’t specifically forbidden” paradigm, the new mantra is becoming “forbid that which isn’t specifically allowed.”
But could the problem be even deeper?
Old fogies like myself often talk about the early PC days (i.e., the ‘80s, B.W. – Before Windows) as a time when software security really wasn’t an issue. So what was different?
My opinion is that what’s different is the rise of programming by teams (or committees, even) along with modern concepts such as “extreme programming” (defined as: “a lot like a jig saw puzzle. There are many small pieces. Individually the pieces make no sense, but when combined together a complete picture can be seen.” https://www.extremeprogramming.org/what.html).
When large groups work on a programming project, it is typically broken down into individual modules with smaller subgroups handling each. Few, if any, members of the large group get to see the overall development. While this does allow faster development time for huge projects, it does have systemic flaws which can lead to easier exploitation of vulnerabilities. Extreme programming can exacerbate this, since the method boasts that it “empowers your developers to confidently respond to changing customer requirements, even late in the life cycle.”
This all requires well-publicized “join points” for the modules. These, today, usually take the form of messaging engines sending data from one module to another or, possibly, a static memory location acting as a “drop box.” Either way, this is an area ripe for exploitation by a cracker looking to do malicious damage.
So what can we do about it? Maybe nothing (I doubt Microsoft will change simply because I say so), but perhaps we can influence the direction that programming is taking. Come back next issue and we’ll look at how it used to be done – and how it is still done by some. It could be enlightening.
