Catching up on ISC.SANS entries and I came across “In-house developed applications: The constant headache for the information security officer.” This is one of those things that I think is not only far easier said than done, but is also not limited at all to in-house apps. I’ve had as much headache, if not more, with third-party delivered apps, especially those custom made.

In-house apps suffer from a developer doing things any way they can get away with. The only protection is to be stringent with least privileges and access, and questioning every design requirement; basically make them develop inside a safe box, which of course gets in the way of innovation.

Out-of-house apps suffer from doing things any way they can that will get the job done with as little tinkering as possible. The only protection to this is to give complete knowledge of your requirements to the third-party so they design it to fit. Yeah, good luck with that.

So when shit hits the fan and a manger has already spent xx manhours on an application, guess what? Yup, the network/systems/security need to bend to accomodate, often creating exceptions and other administrative headache. All because of poor up-front involvement…

…and expert level knowledge. (Yes, that’s the crux of it all!)

This is why I am cynical about getting code to be better. It helps in large enterprises with mature development lifecycles, but I truly feel most shops don’t have that, and their security/ops teams are manhandled by developers meeting business requests.