Layer 8

Developers don’t understand the basics of what their code does, thanks to GUI-based object-oriented programming.  Or they’re re-using someone else’s code and don’t understand it either.

I agree; but I’m not sure I would blame OO programing… There are far too many programmer’s who think “code reuse” means “cut and paste”. And it is not just the developers. The people running the systems don’t understand what is happening on their boxes and they don’t understand what is happening on the wires of their networks.

They don’t even understand how HTTP works, for crying out loud

Heck, I’ve seen developers that don’t understand that HTML != HTTP it is quite depressing. Again, it is not a “they don’t understand security” issue; they just plain don’t understand how their systems work.

[...] they automatically assign it a probability of damn-near-zero.

Now you’re starting to sound like me The problem here is that even if they did understand the problem, we can’t prove what the probability is. We lack the actuarial data that so many other practitioners of risk management take for granted.

So how do you battle this kind of stubborn ignorance?  I don’t have time to teach them all about risk analysis, or even teach them the programming knowledge they’re clearly missing.

The approach that I am intending to try shortly is the “teach them the programming knowledge they’re clearly missing” option. At this point I have not progressed far down the path, so I don’t know how well it is going to work.

Cool, let me know how that works out for you

Between my department having to teach programmers to program, system administrators how the OS works, and help desk people how to deliver real customer service, I’m getting mighty cranky these days.  Pretty soon I’ll be confused with Rob.

shrdlu,

My experience is that people who are immune to reason respond better to scary stories and explanations about how they will get in trouble.  I would avoid trying to explain risk management, which a rational person might respond to, and instead show an actual example of an application security breach, explain how it could play out in your company, and how the developer would get fired.

Specifically, you can take an application security breach story from here and walk the developer through the ways it might play out within your company.  What if the FTC charged us with violating the law?  How would the CEO react if we lost a whole bunch of customers due to a very public breach?  How would the CEO react if we got sued by former customers?

Having illustrated the explosion that would occur, explain to the developer how s/he will be the target of the executive management’s wrath.  Explain that executive management will start an investigation into why the developer chose to ignore basic security practices that the security team recommended, and firing the developer might be an obvious action to convince the government and shareholders that they are taking action to fix the problem.

If the developer still doesn’t seem concerned, explain how that even if a breach does not occur, you will document that s/he assured you that the his/her application was immune to the issues you raised. Then explain how your regular application security audit will expose the fact that vulnerabilities do really exist, and the developer will look incompetent and foolish when you present your report.

Most people have a high risk tolerance when protecting other people’s assets, but as soon as you explain what will happen to their own ass(ets), they get very risk adverse.

-Ryan

I feel your pain.

I really, honestly do. I can relate. Oh, yes I can. I even have one up on you, but can’t discuss it just yet. I tried your approach once, and it didn’t work all too well. And the reason why it didn’t work is because I tried to tackle it bottom up, addressing systemic issues with tactics.

Do you have a corporate fraud office?
Or good auditors?
Are you a public company?

These are all good venues to explore and get understanding of the risks that developers are introducing to the company. Heck, even sitting down with CFO (or someone high enough in the CFO office) will help. They, accountants, know all about integrity and how important it is to them. Make them aware of the problem and all of a sudden it’s not going to be “security making silly requirements”, it is going to become “a valid business concern.“

Empower other parts of the business to help you, and you’ll suddenly be everyone’s best friend.

Makes ya think we should all get minors in psychology to deal with the people making poor or non-existent security decisions…and those that put their head in the sand and act as resistent as possible.

I really believe there is a difference between developers who are true programmers and know their code and want to improve it (and are willing to take training or lessons), and those who are just doing the job on a more superficial level; to just get the job done and not really care about understanding what is going on or the quality or it or the lessons learned. Be sure if you have any of those former programmers, to give their managers compliments about them so that hopefully they stick around more than the superficial roadblocks.

Wow. Ya nailed this one. 

I honestly had THAT conversion with a developer a couple years ago.  The only difference was that my conversation ended when the beleaguered coder had to take a call from a Sr Exec asking why the font on the new, www app (publicly accessible, hosting the company’s crown jewels of course) was Arial 10pt and not Times Roman 8.5.. “as requested”

Developer to me: “Well, uh thanks for stopping by. Yea.. good stuff, really.  But, uh, I got to get back to work here to fix this font thing.  And umm yah.. thanks for putting all this change control crap in place and removing my access from prod so that this one minute change is going take me 3 days now.“

The playaz. (And things that I am trying):

* Auditors: Good luck getting them on your side on this. They’re still trying to find your mainframe. “But my checklist here says to review the ‘change log clipboard’ located near something called a ‘mane frayme’.“  .. bonus points in blowing their mind with comparing IT to an eco-system. 

* Your SDLC folks:  I am trying to get “threat modeling” engrained into every phase of the SDLC.  Useless, but makes them all at least think about it.

* Developers: I think alot of the problem for them is determining where to even start. OWASP.org is written by programmers for programmers. If the developers can just not code these 10 areas of badness, all will be well.  http://www.owasp.org/index.php/OWASP_Top_Ten_Project

* External 3rd party assessment -  Have your next one focus entirely on web app security.  Let them find and show the problems to everyone.

* Management - Since they paid for the above, they’ll want to see the problems fixed and never happen again.  Turn the assessor’s deliverable right into a project.  And bonus points for making that developer from above go back through 5000 lines of code written by someone else who has been gone for years. heh heh.

jaw-box, it sounds like we have a lot of the same tactics.  We’ve brought out the OWASP Top Ten and said, “Yo, listen up—don’t do any of this.“  We’ve done the 3rd party assessment.  We even do automated and manual app testing ourselves.  They still don’t understand why what we find is Bad.

Ryan, threats would have a chance if they had any teeth.  I work in a sector where, let’s just say, nobody has ever been fired for creating a security problem.  Even if they were caught with their hand in the proverbial cookie jar.  And auditors?  Don’t make them laugh.  These developers are not in a position responsible enough to care what auditors write up.

Besides, I hate playing the auditor card.  Yes, it’s always there, but it sounds lame to me.  I wish I could pull out all the stops and say, “The fact that you don’t understand or care why this is bad proves that you’re a bad programmer.“

They’re not working for me, though, and in our area they’re in very short supply, so nobody is going to get disciplined or fired.  My only chance is to hold their production releases hostage so that their project managers come under fire from their customers.  If the PM feels pain, they’ll make their programmers do the work.  At least, that’s my theory.  Sometimes it works, sometimes it doesn’t.

Great and on the point dialog there, shrdlu! I got a flashback to the time I dealt with programmers myself. My luck was having the force to fire them. I actually replaced a whole team due to this lack of understanding, and lack of care. I made sure to hand-pick the new team, and trained them thoroughly. After that, no more problems

Today, as a mere consultant, I can only report this to my contact at the client, and write a report with my advices (fire the s*cker, and train the new guy properly). But I would probably whack the bast*rd with a book or two about secure programming first.

K

Perhaps it is more nurture then nature.  (Although I happen to believe it is genomic orientation .. a “bad coder” protein that is activated occasionally.  Yep, saw it on NOVA.)

Well, got to get ready for patch Tuesday.. looks to be some cool, new buffer overflows this month!

Sad but true, earlier this year I had to explain to a career programmer turned security manager how SQL-injection works.  The conversation started like this:
Them: So why do we need security in the applications team?
Me: To help with design and code review.
Them: Why do you need to do code review?
Me: To catch security errors.
Them: Like what?
Me: Well, you know how SQL-injection works, right?  Things like that.
Them: <Blank stare>
Me: Argh, I made an assumption at your level of competence.  I think it’s time we go back and talk about the basics.

shrdlu,

It sounds like you’ve been given responsibility without the corresponding authority.  Recall Spafford’s first principle of security administration:

“If you have responsibility for security but have no authority to set rules or punish violators, your own role in the organization is to take the blame when something big goes wrong.“

If it were me, I’d quit and work somewhere else if they won’t give you the authority necessary to do your job.  I don’t see how security can fundamentally work as a grassroots effort rather than a top down initiative.  Either way, best of luck and keep up the great blogging.

-Ryan

Ryan, you’re absolutely right (and I would NEVER argue with Spaf ), but in fact I do have the authority.  It’s just that I hate to use it except as a last resort.  Like going back to a signed contract for enforcement, it’s a sign that things are very wrong somehow.

I’ve finally had to come out and say “Just fucking DO IT” a couple of times, but it was never pretty when I did, and nobody came out happy.  So I’d rather exhaust all other avenues first (like, getting them to UNDERSTAND).

shrdlu,

Ah, I see; that makes more sense.

How much security training do you require the developers to take?  What about training for your testers, so they can spot vulnerabilities and log them like any other software bug?

I think it’s a rare person that can manage the mental shift necessary to “think evil thoughts” and grasp the magnitude of the problem based on a few conversations.  Perhaps you grasped such issues instantly, but that satori could have been part of what attracted you to security.  My experience has been that most people are capable of “getting it”, but it takes either substantial training or some bad experiences.

-Ryan

Haha, that what happens when software development goes to the lowest bidder.