Software or Systems architecture is often undertaken from a very technical point of view, the main concerns being around reducing technical complexity and dependencies to make it easier to deal with change in the long run. This is fine for ‘standalone systems’ but in today’s highly interconnected world – the boundary of a system is often blurred as more and more interplay with the Internet is supported. Combine this with the rate of change and push to make everything ‘online enabled’ and you suddenly have a critical need to consider security concerns right up front.

Onion ring security is no longer enough

It used to be that creating rings of security or access zones around systems was sufficient to make a system secure, in order to move from one access zone to a more secure zone you needed to provide more stricter forms of ID combined with more restrictions on what you could do. Hence security zones being like an onion ring, one within the other.

Now this worked fine in a world where systems had a very well defined sets of users or operations and ‘who’ was accessing your system was a direct one to one relationship with the real person. Although in today’s online world and the availability of API’s – it’s very easy to link systems together in such a way that the chain of identity gets broken. The net effect of this is that systems you interface with that do not preserve this chaining, if hacked, open you up in turn to exploits where the hacker ‘acts’ as that system. This is a subtle point but one often missed in API designs, the trust rests with the system and not the user.

Another trend I’m seeing a lot of with online services is to provide a SaaS service where a collection of services are all enacted through the same framework or ‘stack’ with no technical segregation between them. This is fine if all the services are in the same security zone, but say you have one service that contains sensitive information (like bank account details, or personal assessments) – even if you provide role protection around that data – the sheer fact it’s ‘lumped in’ with everything else (for instance running on the same front end servers and the same database) – means if a hacker can get into the code layer for some other service running in the same set up – they by default will get access to the sensitive data as well. This is the security equivalent of putting all your eggs in one basket.

Truly Rotten Security Smells

What are the tell tail signs that you have something wrong with your security architecture? Below are a few of my choice favourites:

• No true separate ORM layer. An ORM (Object-relational mapping) layer is an abstraction technique to ‘wrap’ your database in a higher level object equivalent. In essence the schema is ‘enacted’ through a set of (usually) generated objects. The application can never directly interact with the database on a SQL level – it’s all down to the ORM. The big security win here is you avoid ‘SQL knitting’ – this is where in application code a SQL statement is made with direct variable substitution. This not only is a SQL injection vector it also makes it darn hard to deal with schema changes over time… Plus with an ORM you can easily wrap it in a high auth layer to make really secure you have the rights to do what you are doing (well away from the application layer code).
• Passwords stored in plain text. If I had a penny for every time I saw this.. Plain text passwords in a database is a really bad smell – it indicates whoever implemented the system does not have a clue about real world security.
• Account tables are accessed & stored with application tables. Again this is just inviting trouble – a simple SQL injection attack and you can make yourself a user god…
• Only two user access levels, user and admin. Again, unless you have some really noddy system, you will require many different access levels or roles to ensure people can do only what they are meant to do.
• All on one box. This is where an otherwise well modularised system is in reality all running on the same machine. The problem here is getting file level access in one system will probably give you access to everything else on that machine. Plus it’s a big denial of service risk.
• API security by obscurity. Nobody is going to find the magic ‘admin’ flag…

Getting architecture security right is hard

Unfortunately, there is no getting away from it. Given the number of permutations or vectors of attack possible, creating an architecture that fulfills its objectives and is secure at the same time is hard. Although the alternative is to play Russian Roulette with your brand value and hope you don’t get hacked – which in today’s world is not really a matter of ‘if’ more one of ‘when’.

If you are looking for someone to help sort out your systems architecture and make it secure at the same time, then please do get in touch today.