Skip to main content

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.


Popular posts from this blog

An Observation

Much has changed in the past few years, hell, much has changed in the past few weeks, but that’s another story... and I’ve found a little time on my hands in which to tidy things up. The world of non-functionals has never been so important and yet remains irritatingly ignored by so many - in particular by product owners who seem to think NFRs are nothing more than a tech concern. So if your fancy new product collapses when you get get too many users, is that ok? It’s fair that the engineering team should be asking “how many users are we going to get?”,   or “how many failures can we tolerate?” but the only person who can really answer those questions is the product owner.   The dumb answer to these sort of question is “lots!”, or “none!” because at that point you’ve given carte-blanche to the engineering team to over engineer... and that most likely means it’ll take a hell of a lot longer to deliver and/or cost a hell of a lot more to run. The dumb answer is also “only a couple” and “

Inter-microservice Integrity

A central issue in a microservices environment is how to maintain transactional integrity between services. The scenario is fairly simple. Service A performs some operation which persists data and at the same time raises an event or notifies service B of this action. There's a couple of failure scenarios that raise a problem. Firstly, service B could be unavailable. Does service A rollback or unpick the transaction? What if it's already been committed in A? Do you notify the service consumer of a failure and trigger what could be a cascading failure across the entire service network? Or do you accept long term inconsistency between A & B? Secondly, if service B is available but you don't commit in service A before raising the event then you've told B about something that's not committed... What happens if you then try to commit in A and find you can't? Do you now need to have compensating transactions to tell service B "oops, ignore that previous messag

Equifax Data Breach Due to Failure to Install Patches

"the Equifax data compromise was due to their failure to install the security updates provided in a timely manner." Source: MEDIA ALERT: The Apache Software Foundation Confirms Equifax Data Breach Due to Failure to Install Patches Provided for Apache® Struts™ Exploit : The Apache Software Foundation Blog As simple as that apparently. Keep up to date with patching.