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.

ECB Mode Encryption Deficiencies Explained

 

For the record, I'm not sure where the original came from but there's a copy on Stack Exchange; "Why shouldn't I use ECB encryption", and the ECB penguin clearly has history as noted on PyTux...

Useful article on granting external access to AWS resources

How to use external IDs when granting access to your AWS resources...

Sleep-walking to a Bloody Revolution

According to The Guardian, the EU is about to tighten legislation on user tracking to apply to other means than just cookies.

However, no-one reads those cookie popups or EULAs anyway and you can't do much on the net if you don't blindly accept them. And I mean "blindly" since even though you could read them (most of us don't), you can assume that most users don't have a combined law and computing degree sufficient to be able to understand the implications of them regardless.

I like to think that I understand the computing aspects of these things but I also know that new techniques are developed daily to try to leverage more revenue from the end-user and place more responsibility on them than I can keep up with (or have the mental capacity to understand).

The  likes of Google, Twitter and Facebook are continually trying to capture more data about us and do so through the development of what appears to be "free" services. These services may seem nice but; as always, there's no such thing as a free lunch. They're making a lot more out of the combined mass of data they're collecting on us than we get out of it - after all, they're not charities, they're commercial organisations.

They're not interested in developing this stuff for your benefit; I wouldn't expect them to, and whilst we seem to talk about how relaxed sheep people have become about privacy online, at the same time these organisations have become that much tighter in how they share the data they have on us - individually and in aggregate form (anonymised preferably).

They give you free email or chat services, you let them spy on you so they can feed you with the right ad at the right time in the right place to milk the maximum revenue they can out of you. The algorithms are tuned to this model and they're getting better. We'll soon be letting them install a camera in the bedroom for the benefit of a free daily cappuccino...

So those seeking to extend existing legislation to cover alternative means of tracking which simply relies on "valid consent from the user" are part of the problem. They provide a façade of transparency where there isn't any. They are the lawyers and computer experts who understand the scope of the possible and should be defining the law such as to make some of these techniques illegal without sufficient transparency in what data is captured, how it is used and who it will be shared with.

Ultimately, we need to be paid for the value of the data we provide to these organisations to offset what is becoming a serious discrepancy between the data-rich and the data-poor. The use of vast amounts of data by so few is increasing the imbalance between rich and poor and ultimately will be a disaster for the real economy. That intelligence organisations across the world want to make use of this data themselves and that market leaning governments are ideologically crippled to the point of inaction means we'll not do anything about this until it becomes a real problem - yet another bloody revolution is on the horizon. To address this the law needs to change and no popup is going to help.

Amazon v Amazon

I was reading up a while back about how Amazon (and others) do differential pricing depending on who you are (or who they think you are) including factors such as the type of computer you use. As a very quick test I decided to do two searches...

One (let's call it "open") from my own laptop via my default browser used for everyday activity, logged in to Amazon, full of tracking cookies and history etc....

The other ("closed") from a TOR'ified Linux VM running a clean browser, privoxy and appearing (for now) to be surfacing out of Liberia.

Both searches were for "macbook air" (not that I intend on buying one but they're common and relatively expensive).

Results were pretty much the same, but not quite and the example below shows a difference...

From "open":

 

From "closed":

£686 v £669...

So, if proof were needed.... you can't get Amazon Prime in Liberia! (at least not from amazon.co.uk)... Because that's really the only difference. You can still buy the device (new) for £669 on the "open" version, it's just not the "obvious" option.

However, the first item in the "closed" search did suggest purchase via Prime as it did on the "open" version...



So there is a difference, but how significant is debatable. It may be a classic diversionary sales tactic - the top item via Prime is more expensive than another via Prime lower in the list but this one (which they want you to buy) is still more expensive than you could have got it for... If they can make you buy that one because you think it's a bargain over the top item then it's a good sale!

Who knows... I'm likely reading too much into this after too many beers... In any case it's largely up to us to be conscious that such behaviour goes on and that we; as human beings, are susceptible to all sorts of strange and suspect sales tactics.

Go search elsewhere, multiple times, from other devices, in Liberia... then save the money instead.

Tyre Swing and Architectural Artefacts

Using the legendary tree swing cartoon analogy of the IT industry for my own utility...

How does this sort of thing pan out in a naive project environment? (they're not all like this).

1. Analyst sits down with client for a chat about what's needed.


2. A mental picture (right or wrong - let's assume right for now) is formed in his/her head.


3. A blueprint of how it will work is drawn up (only mentally since we reckon the problem is simple enough).


4. A few questions come up when considering this; how heavy the user? how high the tree branch? etc.


5. Solution proposal is verified with client - via a chat over a pint because it's all pretty obvious and he's a mate.


6. Worked out what items are needed (tree, rope, tyre).


7. Worked out how to build it (again, only mentally because it's pretty straight-forward)...


8. Identified where to source the items from - rope from DIY shop, tyre from scrapyard, tree in back-garden (even checked that there was one!).


9. Took client to scrapyard - picked a nice 50s white-walled tyre he liked... (nice team building day-trip out).


10. Built it! Yeay!

All done with no documentation because it's a trivial problem and hell, it worked so let's do it this way everytime... until you write the requirement down...

Requirement: "I want a swing for my 10 yr old child to play on."

Or as a user story: "As a child I want a swing in the garden so that I can play, see how high I can go, get dizzy and feel really funny!"

Or a set of 20 page use case documents (which is wrong in itself).. yawn!

At which point you'll go to Amazon and discover a host of inexpensive off-the-shelf options which are probably better-designed/safer/more-flexible etc. and unless you've a rope, tyre and tree lying around you're probably going to opt for the COTS option.

So it's worth writing it down, just to make sure it's understood, even if it seems obvious. Agile does not mean "no documentation", just "avoid the bloated detailed crap no-one reads and focus on the useful stuff".

Which for me starts with requirements! (functional requirements - a swing! non-functional requirements - for an average weight 10yr old child). It does not take a lot of effort...

But oh wait there's more!... some form of logical design (blueprints), a plan (sources, how to do it), infrastructure requirements (a tree), physical solution (which tree?).

And my favourite hobby-horse this month... traceability from the solution to the requirements to demonstrate why it's the way it is and to confirm it meets the clients needs and expectations. It can even be done in the pub with a whisky chaser!

None of this needs to be written down as reams of verbose documentation, none of this is counter to agile principles. A lot (if not all of it) can be done with a few lists, diagrams and matrices... no Word docs or Powerpoint decks in sight (unless that's the chosen crapware you use to draw diagrams) and you can save the tree if you choose not to print to paper... But all of it needs to be thought about - whether you write it down or not!

I'd still prefer it if you'd use UML though... ;)

 

Cash-haemorrhaging public cloud

Interesting point of view on how cloud service providers are haemorrhaging cash to sustain these models in the hope they'll win big in the long run.

As data storage and compute costs fall they may well be able to sustain existing pricing though I suspect ultimately they'll need to ratchet things up. Cost comparisons are also hard to get right due to the complexity of pricing from suppliers and I also believe the difference in architectural patterns used in the cloud versus on premise further complicates things (something for another day).

What I do know is that their are those in the industry who cannot afford to be left behind in the race to the cloud; IBM, Microsoft and Google notably. They will likely be pumping all they can into the cloud to establish their position in the market - and maintain their position generally...