There is a parallel with our industry, which I will get to eventually. Some of you may be aware that the Playstation network, which is Sony’s answer to Xbox Live in that it is a free multiplayer gaming service and media provider (unlike Xbox Live online play requires a subscription). So given that Sony are not paid to support the service, and upgrade/development costs are funded by Sony themselves. Until the incident occurred what incentive did they have to ensure the security of the system and the data that it held.

This is the same issue facing control system users and vendors. Control system users will nearly always prioritise features over security. Also the vendor will not directly be impacted by any breach of a control system(our networks just fine thankyouverymuch). So where is the vendors incentive, and where is the users incentive. Apart from Stuxnet there is little real hard and fast incident metrics that can be used to determine any ROI on security. And you can even argue that Stuxnet was a targeted attack that did not impact a large majority of the control systems in the world.

So what’s the next step, vendors to keep providing “security for free” For the vendors to make a concerted effort to shore up their software, or for the customers to realise that control system security is an issue that we all share?

The goals of the project were:

1) Ensure that the development centre produced high quality applications meeting or exceeding industry standards for quality and security

2) Enable the development team to become more self-reliant on its own security expertise within the 18 months

At the conclusion of the project teh development team had moved themselves up to the Standardised level, and already including some advanced and dynamic activities.

Don’t panic I’m hoping that this is not a one off and I get back into posting again

As per usual, nerves got the better of me for the first presentation and I rattled through the slides at a rate of knots. The second one went much smoother.

It was interesting to guage peoples reactions during and after the sessions, one of the common points that came out was that they had not really thought of coding securely and how a simple crash could be so much more.

So having presented an overview of the new coding standards, we have sent them out to, hopefully, be read and understood, failing that I’m working on a more details training session that should bring people up to speed.

• Oracles asking for secure training at uni

• Static code analysis failures
• Spot the overflow
• a torrent of trojans made simple
• Poking holes in databases for fun and profit
• measuring secure

So I’ve become a powerpoint wiz again and put some slide together, going through the main points of the guidelines. To ensure buy in (I hope) I’ve tried to emphasize the quality aspects of secure coding, in that a securely written program will be a high quality one.

You may get people saying “this secure coding malarky, just a load of shit isn’t it”, it’s harder to say the same about quality coding because then you shouldn`t be developing code in the first place if you do not care about quality.

The other aspect of this is, given that there is little in the way of “secure” thinking, why focus on coding guidelines first.  Well for a number of reasons, firstly I’m a developer it is what I understand, secondly one of my many ‘hats’ is that I am the ISO department rep for software development, so I already manage the coding guidelines, so fitting another one in is quite straightforward.

Finally a number of studies, both open source and from the likes of Microsoft show that over 50% of all security vulnerabilities are caused by software bugs rather that design defects.

As I am “part time” there is only so much I can do, so why not tackle the low hanging fruit, with potentially quite a big benefit.

As it happens we have thought a little about requirements and design, but nothing formal, but what we have will be mentioned as we have invited our architects (design) and business analysts (requirements) to the training.

• reverse engineering firmware
• All my hard work writing coding guidelines scuppered by the compiler

We have a process for dealing with existing bugs, but given that the bug review team has no experience in review security issues, so something a little more thorough that a finger in the air is needed.

I had done some poking around our software and had logged about half a dozen issues and the security team decided that we should start to score them. We looked around and decided to focus on the Microsoft STRIDE and DREAD models to describe and categorise them.

So 4 of us sat down and individually scored, them and realised that whilst we scored them differently, we picked the same ones as our highest priority.

What we learned as part of the process, is we had to determine what a Damage of 1 or 5 meant to our software. So we went through and added examples of what a 5 damage meant compared to a 1 or a 3. We also noted factors that would affect the score. for example discoverability was simplistically scored and the level of knowledge required, so that if joe bloggs could find it, then it scored 5. but this could be impacted by the time needed to discover something.

There was discussion about the point of view of the attacker. It was simpler to assume that the damage, reproducability and affected users should assume that the vulnerability was about to be exploited.

Exploitability and discoverability dealt with the difficulty in getting to that stage in the first place.

With all that slowly getting in place, we now have the basis for a reliable scoring method that should help us prioritise our fixes when vulnerabilities are reported. Now we have to work on the rest of the process.