Wednesday, April 27, 2011

What Secure Code Means to Me

I’ve had the following idea rattling around my head for a while now, and I think it nicely and somewhat humorously illustrates the gravity of the situation and the importance of secure coding practices (and a secure development lifecycle).

The Story

Let’s say I’m a business user (Me) with a problem and I have a friendly IT team (Alice, Bob, and Charlie) willing to help me solve it.

The problem statement is this: “I’m getting nagged to death by my [partner|spouse|child|etc.]”, so I formulate the requirement “I want the nagging to stop.” and convey that to my willing and eager IT team.  The meeting goes something like this:

Alice: “Sure, we can do that.  It’ll be easy.  I’d give it one story point.  We can even put it in the current sprint so you don’t have to wait.”

Me: “Awesome!  Thanks a lot, you’re doing me a great favor.  I thought I’d never be able to solve this problem.  How can you come up with a solution so fast?”

Alice: “Oh, we’re going to use a cyanogen.  It’ll be quick.”

Me: (eyes glazed over at the technical term, regretting that I asked) “Alright, well, thanks again and I look forward to testing out your solution.”

Alice then promptly goes off and kills my partner.  Bob reviews the implementation and signs off on it because, well, it does meet the requirements quite effectively and, well – permanently. He may even give Alice a pat on the back for her elegant and ingenious solution.  Charlie, although he might have some reservations about Alice’s implementation, believes that it’s Not His Problem™, and if asked about it would refer you to Alice, because she wrote/executed the implementation.

A few days later it comes back to me for functional testing/user acceptance testing.  Like any good functional tester, I care that the requirements have been met, and don’t really understand or care about *how* they’ve been met.

Me: “Wow!  Whatever you guys did it worked wonders.  Thank you so much for this.  I haven’t been nagged at all in almost a week!  Of course, the car is missing…but anyway, that’s a different problem, I’m sure it’ll turn up sooner or later.  You guys are heroes.”

Alice: “Glad we could help, let us know if you need anything else.”

Of course, after a while a body (a vulnerability) is found and exploited by the police, landing me in jail for hiring my IT team to fix my problem.  I can explain and exclaim all I want that it’s Not My Fault™ and that I didn’t know that murder was involved, but the money trail doesn’t lie and I still hired my team to “fix my problem”.

The Moral of the Story:

Just because it works and meets all of the business requirements does not mean that it’s correct.

First Corollary:

Security testers care more about correct and appropriate implementations that protect the stakeholders from harm and losses.  The fact that the software works and meets its requirements is a bonus.

Second Corollary:

Software can easily be implemented incorrectly.  Correct implementations frequently take more time, analysis and attention to detail.

Monday, April 18, 2011

Git R Done

For some reason, I feel like I’ve been hyper-productive lately.  Justin seems to finally be getting his things in order and I’m helping him with his documentation requirements.  The secure coding curriculum that I’m helping to develop for my employer is moving forward at a fairly quick pace.  My chemotherapy has resumed and next steps are on my calendar, and I’m generally just ‘feeling good’.

I think part of it has to do with just being more organized and conscious of time management and putting my planned activities on my calendar (accounting for travel time as well).

I like this…let’s keep it up.

One thing that I think I could use more of is – wait for it – some sleep.  I was going non-stop from Friday at around 7am through Sunday morning at around the same time.  The 12 Starbuck's Venti’s, 2 Red Bulls and 3 Five Hour Energy’s throughout that period helped just a tad.  Caffeine works wonders.