« Feds in Cyberspace - What's the Value Proposition? | Main | Security Abstractions »

Comments

Michael Janke

"the challenge is to make security a compelling enough problem to get on their radar, but once you are there they will get it pretty quick."

Why is it Infosec's responsibility to make security compelling? I assume that security is part of every IT professionals job, and I do not assume that I can sit back and wait for Infosec to tell me how to secure my servers and networks.

Why do we assume that it's Infosec job to 'compel' application developers to embrace secure application design and coding?

Trillix

This is really disappointing. Infosec has done a lot and supports even more. I am banishing this blog from my reading list. How can you complain about devs being lumped together and bad mouthed then do the same to infosec. Are you in high school? Say goodbye to one former reader.

Bill Triest

Very intersting topic. One of the roles recently asked of me was to work how to mentor our developers to be at least more infosec concious. I'm very intersted in ideas people have on how to accomplish this.

Technically I'm a developer now, so part of my idea was to have some one of my nature sign off at every stage of the SDLC. The idea isn't to be another supervisor, but to let them have a chance to try and fail. Then I can help mentor them towards better design, coding practices, etc Also, we're taking away a lot of production access to try and really reduce attack suface and the scope of access from any one vulnerability.

With that said, there's a lot more that I feel I can learn and possibly better tools I could use to present and help our developers. I'd be very intersted in more in-depth informations, material for reading, and/or potential training.

Thanks!

Gunnar

@Michael- its security's job because security is supposed to responsible for *information* security not just infrastructure security.

instead of buying the next FW take your developers out to lunch:
http://1raindrop.typepad.com/1_raindrop/2009/01/enterprise-security-2009-to-do-list.html

the answer is not always a tool or a process, lots of progress can be made by winning allies on the dev side

Gunnar

@Trillix - sorry to lose you. While there are parts of infosec doing very good things (one example- I mentioned OWASP in the post), but I think its inarguable that developers have outperformed security in innovation. To wit, firewalls are the top budget enterprises this year

http://1raindrop.typepad.com/1_raindrop/2010/10/reconcile-this.html

@Bill - thanks. Training is an excellent way to get started, esp with hands on examples, because the output is detailed understanding. In addition I posted some thoughts on phasing security into SDLC back in 2006 but most still applies

http://1raindrop.typepad.com/1_raindrop/2006/01/phasing_securit.html

Michael Janke

"because security is supposed to responsible for *information* security"

I don't buy that. Infosec was created because the various units of IT failed to properly incorporate security into their daily practice. If software development (and infrastructure) were capable/competent, they would understand current and future threats and engineer systems to meet the threats without prodding, cajoling or lunch from infosec.

I'm really discouraged when what is essentially a third party (infosec) has to take dev's out to lunch and explain SQL injection to them. Dev's need to take it upon themselves to understand what the landscape is like and write code that can survive in that landscape. If devs (or infrastructure) cannot keep up with what's happening in the real world, they (dev and/or infrastructure) need to consider a career change.

I manage more that a few dozen firewalls, but I'm very aware that firewalls only exist because software developers routinely and consistently fail to write software that can survive on it's own, on the internet, without the protection of a firewall. Think finger, CIFS, Samba, RPC, SQLnet, and dozens of other application protocols that were written and deployed w/o sufficient self protection to survive on the Internet without the protection of a firewall.

I can point to a dozen applications that I have purchased from major software vendors, that I have installed in my data centers, that would be rooted in minutes if I dropped our data center firewalls.(IBM Director, HP tape libraries, Sun Lights-out Consoles, Netscaler load balancer XML interfaces, Oracle database listeners, Oracle Grid Control Agents...)

Firewalls are necessary evil, required only because software developers don't understand the problem.

Gunnar

@Michael- "I'm really discouraged when what is essentially a third party (infosec) has to take dev's out to lunch and explain SQL injection to them."

Agree, but it is what it is. I think security can help out a lot supporting devs to get to the next level of understanding.

Firewalls can do some stuff but they can oly take us so far

Matt

I have to say this article is quite disappointing. It seems that this was an excuse to deride infosec people. What's with the whole "network firewalls, SSL" jibe. Not funny.

Your suggestion to solve the problem is a grossly thin on the ground. I agree with the principle that dev and infosec should work together more but I feel tared by the same brush as the person who put you in this apparently bad mood.

Gunnar

@Matt, you might not agree with my proposals, but I do have a number of them written up in some detail. Have a look at the links under SOS: SERVICE ORIENTED SECURITY

LonerVamp

I'd love to dive into this more, but I fear some definition would be in order. Who is infosec? What is their job definition? Etc. So I'll try to dance around that as well as not belabor the, "Whoa slow down you're blaming infosec just like they blame devs..." approach that has been done already.

It's a little unfortunate that your last paragraph, with the real meat of your post(!), is way overwhelmed by the rest of the post.

I agree, I'd probably suggest more devs get into security, because security doesn't have a ton of development experience, and maybe never will. At least not in a sense beyond writing homegrown scripts and non-resilient "real" software code. And then supporting it.

There are probably just as many security people who can't operate technically (i.e. can't teach devs on a deep, specific, meaningful, actionable level about the OWASP top 10) as there are developers who struggle to understand networking ideas (DNS!) or security (transport encryption? least privilege accounts/access?).

I still feel much of the problem comes from business, which pushes down requirements and deadlines and rewards quick delivery and customer service. And none of this includes anything related to security. It's always an afterthought...if you're lucky. (Yeah, we can beat on each other, but why not pull in "business" and beat on them, too?! hehe)

That kinda means security needs to patch around things with what they know, but devs need to bake their security in whenever they can as they build the code. Rather than leave unvalidated inputs exist, validate them on the first write.

But that takes experience/knowledge. And as your own graphic suggests, dev technology changes pretty regularly, which does affect how far you can take that exp/knowledge...

And so on...

My ultimate point, and it's not surprising, is that I'm on the fence on where any blame goes. But yes, the ultimate result *should* be that teams work closer together. But business rarely rewards that, since it visibly costs money. It's like that old image where one guy paints the lines on the road and another picks up roadkill, and the guy who paints the road just paints over the roadkill since it's not his job.

As a totally different but yet similar thought exercise: Who manages the WAFs?

I really feel the true rockstars come in 2 *rare* flavors: those that are are experts in their slice of the IT world (and may be dumb in the rest) or those that have their knowledge grounded in everything; i.e. they can talk to devs just like they can talk to netops.

The comments to this entry are closed.