I decided to assemble a checklist of security questions and techniques that could be glanced at by an engineer before they sign off their newest feature.

The Software Engineer’s Security Checklist

James Butherway -  20 Dec, 2016

I have always had an interest in computer security and hacking prevention. Possibly due to the speed at which the techniques and software become outdated, even relative to other areas of computing. Or perhaps it was driven by an underlying fear of privacy invasion, as I could see so much of my life moving onto the internet. But this thirst for knowledge has lead me to get more involved in the security of the systems I help engineer. What I have found is that security in the ‘real world’ is hard. 

The difficulties of security

Security is hard! But it is that way by design in an attempt to make compromise even harder. This said there are still so many ways to ‘crack a nut’. With the complexity of computer systems today, we forget just how many technologies, layers, protocols, users and lines of code actually comprise them. To an attacker, the bigger the system, the more likely there will be a chip in its surface where an attack can be made. It was this reason that brought me to want to assemble a checklist of security questions and techniques that could be glanced at by an engineer before they sign off their newest feature. When caught in the whirlwind of creative engineering it is often easy to neglect the security.

The checklist

    • Have you assessed the risks?  - The only way to know if you are secure enough is to think about the value. Ask yourself ‘if this was compromised, what could a malicious user do?’ This will allow you to decide how far to go with securing it and which of the following needs to be addressed.
    • Will you know if you are compromised? - Will something odd occur that is a red flag? This might involve a more severe log if a certain action happens frequently in a short time frame. Maybe just having a special tag and triggered alert when these kind of errors are raised, with a process in place to make sure somebody always looks into them.
    • Can you react to a malicious action? - What can you do if you realise something has been compromised? You can never achieve 100% security and still have decent usability, but you must be able to counter if an attack comes your way. Generally this should be baked into the solution so consideration at design time is great.
    • Can you remove the hacker’s assets? - If you have outlined data that would have high value to an attacker, they will see this as an asset to use against you. The idea here is to try and come up with an alternative solution that reduces the risk in its compromise without impact to your system. A simple example of this at work, is the best practice for storing passwords. You never store the clear text password thus making your ‘password store’ less desirable. If it has limited use externally then it lessens the risk!
    • Do you understand the principal user? - Is this an authenticated operation and what level of authorization is needed? Have you explicitly defined all the rules surrounding the user’s actions and made sure the checks are represented in code? Even better, is it defined in an automated test suite?
    • Is there an Audit trail? - Logging is very important in monitoring security. Engineers tend to forget that logging is not only for debugging but can also be used to great effect for tracing valued actions across the system. Careful thought must go into what, where and when as to make the analysis of these logs most efficient. It is no use having a detailed log if come review time, it is unintelligible.
    • How expensive can you make the hack? - One of the core principles of attack countermeasures is understanding that security is nothing more than erecting walls around something precious. The walls can probably be broken through or walked around but every additional wall is extra effort. If each barricade is a different thickness or shape or material, the more tools and skills are required to bust in. The low hanging fruit will always be snatched first so moving it out of reach maybe enough deter most hijackers.
    • Seek advice from those who know best! - Have you read your team or department's security policies? These will more than likely have evolved from experiences of malicious intent in the past. As software security is ever changing looking to those who have experience in it will be the best way to gain insight into thinking in secure practices. It will be very rare that the issue you face will be the first of its kind and it is more than likely that it has been solved 100s of times and a common secure pattern is well known. It's always fun to invent the lock, but your house will be safer with a Yale fitted by a locksmith!
    • Can any of the most common security pitfalls trip you up?
        • A weak password policy.
        • Technology stack information leak.
        • Using more code or services than the task requires.
        • Outdated and ‘at risk’ services or libraries. Remember to constantly check for security patches in your dependencies.
        • Excessive file access for the task.
        • Poor logging.
        • Incorrect firewall rules.

White or Black it's hats that will teach you

The internet is the root of most malicious intent and yet also the strongest source of exploit exposure and prevention. It is a tool that should be used to stay on top of securing your systems because as fast as a miscreant can hack it, someone can patch and others then document it. Books go out of date yet the internet continues to update. I would suggest, as a start, get familar with https://www.exploit-db.com and make sure your main software dependancies are safe. Champion your systems’ security!

Subscribe to this blog

Use of this website and/or subscribing to this blog constitutes acceptance of the travel.cloud Privacy Policy.