S E C U R E Acrostic
The more integration work that has to be done to get a component to work, the more opportunities to introduce unintended errors which can result in security vulnerabilities. Secure code should therefore not require any special skills to incorporate. It should just be the normal way of doing things.
Easy to Understand
Complexity breeds insecurity. If you have overly complex code that other developers may need to maintain, it is in your best interest to re-factor this code and simplify it as much as possible. If code is hard to understand, it’s hard to troubleshoot and hard to review for vulnerabilities. The K.I.S.S. principle is good for security.
Cognizant of attacks
The more self-defensive your software is, the better it can identify and protect itself from attack. Strong auditing and defensive coding techniques such as input filtering / sanitization can help your identify potentially malicious input which can tip you off to potential attacks. These inputs can be audited and logged properly and if required, raise alerts.
All code should go through rigorous, consistent and repeatable unit testing. This increases the level of assurance that the code has undergone thorough testing and therefore is less likely to ‘break’ under attack.
Code should expect bad things to happen and fail to a secure and reliable position. There are more ways to DOS a system than to flood the pipe. Getting a system to error out and crash works just as well. Build in proper error handling and fail securely. Secure code does not underestimate the power of the adversary.
As with Resilient above, errors happen. Proper error handling needs to be maintained at all levels. At the same time, secure code does not provide more error information than necessary.
Rocky H, Richard L,