Breaking things is easy; creating things is hard. Creating secure software is really hard.
But that’s not because security is inherently difficult, complex or academic. As software engineers, we need to secure all possible entry points, of which there are many. An attacker, on the other hand, only needs to find a single weak point to exploit the software we spent months creating.
So what can we do about it?
Layers
Layered: secure systems, onions and Mary Berry’s favourite desserts
Secure systems, onions and Mary Berry’s favourite desserts all have one thing in common: layers.
Most people are already familiar with the concept of layers in real-world security. We lock all external doors; not just the front one. We shut all the windows, leaving none ajar. But what if someone brute-forces their way in? We might have an alarm. If that doesn’t deter them, at least the jewellery is in a safe – and of course the code is not written on a sticky note!
But this awareness doesn’t always get translated into the digital world.
Remember, our goal is to eliminate those single points of failure which give attackers the upper hand. So with that in mind, let’s take a broad look at some of these important – and commonly exploited – single points of failure.
People
Yes, you!
“People are the weakest point of a security system”
This has become somewhat of a cliché, but it remains true. If an attacker can convince a member of staff to read out the admin password over the phone, our secure software counts for nothing.
By forming good habits in our daily processes and procedures, security ceases to be an afterthought and becomes an inherent part of how we work. In February 2017, SwarmOnline was accredited to ISO 27001 (Information Security Management) – a process which involved staff at all levels and roles. With it came a heightened awareness of how our processes can have a direct impact on the software we produce – now everyone is a security guard!
In particular:
- Handle documentation and credentials with care. Passwords on paper, API keys in documents and database credentials in emails can all compromise your application before you’ve even written one line of code.
- Don’t assume that someone else will take responsibility for doing something properly. Establish well-defined roles and responsibilities early on to ensure that nothing falls through the cracks.
- Be aware of your surroundings – who is looking over your shoulder or listening in to your call?
Never Trust the Client
The ‘client’ in this case is the end-user’s web browser or mobile app. It’s a very obvious layer both in software terms but also security. The users control it, therefore they control the data that gets sent back to your server. Protecting against malicious or simply unexpected inputs is a topic which could easily span several blog posts.
Luckily, the Open Web Application Security Project (OWASP) maintains a Top 10 list of the most common application security risks. As a starting point, you should be familiar with:
- What they are
- How to exploit them – and what the consequences could be
- How to defend against them
Do the Bare Minimum
Granting unlimited access to a database or file system makes things easier, right? We don’t have to worry about all those fiddly permissions and roles, we just get on with writing code!
While it may be convenient, it’s a terrible idea. Only being able to access the bare minimum resources you require ensures that even if an attacker does gain access to credentials, what they can do with them is limited. Yet another layer.
- Don’t let your application connect to a database with an ‘admin’ account.
- Instead, create a dedicated user and grant only those permissions which are needed. If your application doesn’t need to delete tables, don’t let it!
- The same principle applies to other resources – config files, SMTP servers and other programs should only be accessible if absolutely necessary.
- The wide adoption of Cloud services makes it trivially simple to provision some very powerful services at the click of a button – but don’t let this ease of use lull you into assuming they are secure by default.
Don’t Reinvent the Wheel
In software, there are some tasks which crop up again and again.
User authentication, storing passwords and encrypting data are some common examples. Over time, a number of best practices have evolved – ignore these at your peril!
- Wherever possible, use an established solution to common problems such as authenticating users – if you do use a framework, ensure it is reputable
- Don’t be tempted to invent your own algorithm for performing something as important as encryption
- Don’t go it alone – discuss ideas with colleagues who may have already solved the same problem
Finally, have a backup plan. ‘Disaster Recovery’ may be a rather ominous term, but it is our last layer of security. Even if the worst happens, how quickly can you put things right?
Things are easily broken, after all.
