Rafal has a very nice post up that explores why security folks have such a hard time getting application developers to care about secure coding.

As I was reading that post, two ideas merged in my poor little head. This was cause for celebration because it doesn't happen very often 🙂

Thought #1: Ask, Don't Tell

I recently attended a class provided by my employer called Adaptive Leadership. One of the tenets of this class is that is often more productive to ask than to tell. What does that mean?

When we tell somebody to do something or give specific instructions, they have no investment in the outcome.

However, if we ask the right questions and lead their thoughts down the right path, we give them the opportunity to invest in the outcome. If we do this well, we then have somebody who has convinced themselves that this is the right thing to do, whatever that right thing may be.

Thought #2: Engagement

This video, RSA Animate - Drive, is a synopsis of Daniel Pink's book Drive. I have just started reading it so don't have detailed knowledge of the thoughts ideas introduced in the book yet. One thought I did get from the video is that engagement is key to performance, performance, in this case, being caring about secure coding practices.

Engagement means that the individual cares about what they are doing. That they are invested in the outcome.

Thought Merge: Ask, Don't Tell To Get Engagement

If we can use 'ask, don't tell' to get people invested in something and getting people invested in outcomes produces engagement, might we not end up with developers who care about producing secure code?




Somebody Got Some Splaining To Do

by kriggins on January 16, 2009

in General, programming

An attribution would have avoided a problem here.

Marcin has a post up comparing the SANS Application Security Procurement Language and the OWASP Secure Software Contract Annex.

Give it a read and see what you think.


Reblog this post [with Zemanta]


Hi folks.  Yesterday, I included this story in my Bits post. It is about new procurement language that says software vendors must "certify" that their software does not have any of the Top 25 Errors released by SANS/CWE early this week.

I have read several blog posts on the topic since and today the topic came up on The Security Catalyst Forums. (You should check those out it if you haven't already. Great conversations and community.)

One of the questions posed was this; does this approach seem like something that should be encouraged?

Below is the response I posted.

Two main things pop out at me with this type of thing.

The first is this phrase "must certify that they have rid their code of the Top 25 Errors." What about the next 25 or the next one? I read a blog post over the last couple days that talked about this very well. Blocking where I saw it. If I find it I will update the thread. The essential bit was that "certifying" that you have addressed the top 25 errors doesn't mean your software is secure. That "26th" error  can be a show stopper too. Say it with me, compliant does not equal secure. Before people yell at me, I am not implying that we shouldn't address the errors listed in the top 25. (side note: Kees and some others have been pointing out that the 25 may not really be 25)

My second concern is this, sayin' it doesn't make it so. Creating contract language like this can lead an organization to a false sense of security. I can see where orgs might go the route of "the contract says the software is secure so we don't need to test it or perform a risk assessment." Again, that 26th error can hurt a whole lot.

Just my 2 cents worth. It's super cold in Iowa, so flame away Smiley

Like it says above, these are my thoughts. What are yours?



Top 25 Coding Errors Released

by kriggins on January 12, 2009

in Educational, programming, Tools

In today's Bits post, I mentioned that a top 25 coding errors report was going to be issued today. Well, it's happened. From the SANS website:

Today in Washington, DC, experts from more than 30 US and international cyber security organizations jointly released the consensus list of the 25 most dangerous programming errors that lead to security bugs and that enable cyber espionage and cyber crime.

The web page listing all the information about the project is here.

There is good stuff there that should be looked at by all who are involved in information security, not to mention those involved in developing programs.


, ,

Reblog this post [with Zemanta]