Training, training and more training

Well last weeks training went well, both sessions got a fair crowd, and sensible questions were asked, so it’s a step in the right direction.

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.

This Weeks Link

Only the one thing caught my eye this week:

• Oracles asking for secure training at uni

This Weeks Links

More things that have caught my eye

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

Enjoy this, it’s the only training you’re getting

And unfortunately (for me) I’ll be the one doing the training. Having spent the last couple of months producing our secure coding guidelines, it is now time to roll it out to all the developers.

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.

This Weeks Linkage

Things that have caught my eye this week:

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

Scoring vulnerabilities

As we are only really starting out thinking about security, one of the things that we are looking at is how to determin the severity and priority or reported vulnerabilities.

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.

Hello World!

I suppose I’d better introduce this blog, and myself.  I’ve a full time developer with an interest in secure software development, in a company that is slowing becoming aware that this is important.

I’ll be posting about the things that I am learning, and links to other useful sites.  And posting about the trials and tribulations of  making people take security seriously.

To give a quick indication of the up hill struggle our small, merry band face, we had started logging security issues within our issue database as a means for the security team to track them initially, and I overheard one of the engineers commenting at the Issure Review Meeting:

“These security issues, they’re not real bugs are they?  We don’t have to fix them do we?”