Don't Build Your Own Security Solution!

There are only three reasons why building your own security solution is a good idea:

1. Security through obscurity - There's less likelihood that anyone will find the holes because no-one else is using it. This is just as well since your home-grown solution is probably riddled with them (see below).


2. Risk v Cost - You've weighed the risk, baulked at the cost and decided the benefits aren't affordable.


3. You're unique! - Some organisations may be unique and/or have unique problems for which there is not an off-the-shelf solution. You may be NASA or a top secret government department, or you could be one of the big internet organisations operating at the edge of technology and scale (fb, Google or the like) or it may just be your business to develop security products.

It's a fair bet that #3 doesn't apply to you and if you think the costs are too high then I suspect you've not really understood the problem.

There are many reasons why you shouldn't build your own security solution and should buy off-the-shelf instead:

1. Risk - The suppliers of security product are much more likely to understand the potential security issues and deal with them correctly than your in-house developers. You may have some really nice people working for you but despite their assurances, they're not the experts. The most basic of attack vectors; weak passwords, code-injection, CSRF, XSS etc., can be left exposed by an in-house team who don't have the experience or knowledge to address them correctly. This point really can't be stressed enough. I do not consider myself to be a security expert but I have seen problems in every single home-grown solution I've come across.


2. Features - Even basic administration capabilities require effort to implement - adding users, granting permissions, password resets, password rotation, revoking access etc. Add to this the expanding list of security patterns and protocols which may need to be supported (basic-auth, forms-based-auth, single-sign-on, WS-Sec, SAML, OAuth, multi-factor authentication etc.) and the range of vulnerabilities you need to address (buffer-overflow, virus scanning, intrusion detection etc.) and a home-grown effort can start to look pretty pathetic. Standards also evolve to improve quality and make interoperability easier and many off-the-shelf products will implement these accordingly. A home-grown effort likely won't efficiently lend itself to being manipulated to support such standards as they evolve - in either a qualitative or interoperable way.


3. Swiss cheese - Buying an off the shelf solution isn't going to solve your problems overnight and your developers will still need to employ secure development practices in case something gets through. However with many layers of security (especially where from a variety of suppliers) comes additional protection. Every product will have holes but you hope the holes don't all line up allowing something through. The more layers the better though home-grown layers have lots of holes.


4. Support - As new vulnerabilities are discovered you'll have (should have) a support contract in place with the supplier to provide patches to address these as they arise. With an in-house solution you'll probably never know you've a problem until it's too late. Furthermore, the obscurity benefit is a millstone around your neck. Finding developers to support the solution will become increasingly difficult (and expensive) as the years go by. No developer wants to be left supporting pre-historic software, it's a dead-end career role.


5. Maintenance - As technology marches on, the environment in which you operate changes. Constant upgrades in browsers, operating systems and devices means you've got to continue to develop solutions just to remain compatible with your users. The time and costs this consumes can quickly mount. The same issue can be charged at commercial vendors and you should ensure your supplier has the mind to consider the upgrade path before you sign on the dotted line.


6. Blame! - Ultimately if something goes wrong you'll have someone to shout at, sue and/or get emergency fixes from. You can still do the same for in-house solutions, it's just that you'll be the one being screamed at and if the breach is bad enough you could well be scanning jobserve sooner than you wanted.


7. Cost - If you can afford to fund development to address the risks, develop, maintain and support a fully featured product then by all means do so. Odds are that you can't.

I could (and do) levy many of these issues at any home-grown solution and not just security but I fear security is the most heinous case as it's taking risks with other peoples data.

Ultimately we need to ask the fundamental question as to whether it's our business to be writing some software product or whether we should focus on our own specific goals and let someone else, someone more qualified, do that for us.

In the case of security it's almost always better to buy off the shelf.