These best practice concepts help you quickly spot common weak areas and poor controls.
Layered approaches provide more security over the long term than one complicated mass of security architecture. You might, for example, use access-control lists (ACLs) on the networking and firewall equipment to only allow necessary traffic to reach the application. This approach significantly lowers the overall risk of compromise to the system on which the application is running because you quickly eliminate access to services, ports, and protocols that otherwise would be accessible to compromise.
Positive (whitelist) security models only allow what is on the list, excluding by default everything else. However, negative (blacklist) security models allow everything by default, eliminating only the items you know are bad. This is the challenge to antivirus programs, which you must update constantly to keep up with the number of new possible attacks (viruses) that could affect you. The problem with this model, if you are forced to use it, is that you absolutely must keep the model updated. Even with the model updated, a vulnerability could exist that you don't know about, and your attack surface is much larger than if you used a positive security model.
There are basically three responses when an application fails. You can allow, block, or error. In general, application errors should fail in the same manner as a disallow operation as viewed from the end user. This is important because then the end user doesn't have additional information to use that may help him or her to compromise the system. Log what you want, and keep any messages that you want elsewhere, but don't give the user additional information he or she might use to compromise your system.
The principle of least privilege mandates that accounts have the least amount of privilege possible to perform their activity. This encompasses user rights and resource permissions such as CPU limits, memory capacity, network bandwidth, and file system permissions.
Obfuscating data, or hiding it instead of encrypting it, is a very weak security mechanism, especially for an application. If a human was able to figure out how to hide the data, there is a good chance that another person is going to learn how to recover the data. A real-world example is how some people will hide a key to their house under the doormat. A criminal wants the easiest possible way into the house and will check common places such as the doormat, the closest rock to the door, and above the door frame for a key. Never obfuscate critical data that can be encrypted or never stored in the first place.
Simple security mechanisms are easy to verify and easy to implement correctly. Bruce Schnieir is famous for suggesting that the quickest method to break a cryptographic algorithm is to go around it. Avoid overly complex security mechanisms, if possible. Developers should avoid the use of double negatives and complex architectures when a simpler approach would be faster and simpler. Don't confuse complexity with layers. Layers are good. Complexity isn't.
Applications should have built-in logging that's protected and easily read. Logs help you to troubleshoot issues and, just as important, help you to track down when or how an application might have been compromised.
Many organizations use the processing capabilities of third-party partners, who more than likely have differing security policies and postures than you. It is unlikely that you can influence or control any external third party, whether they are home users or major suppliers or partners. Therefore, implicit trust of externally run systems is dangerous.
Your applications should arrive to you or be presented to the users with the most secure default settings possible and still allow business to function. This may require training end users or communications messages, but the end result is a significantly reduced attack surface, especially when an application is pushed out across a large population.
Where possible, base security on open standards for increased portability and interoperability. Since your infrastructure is likely a heterogeneous mix of platforms, the use of open standards helps to ensure compatibility between systems as you continue to grow. Additionally, open standards are often well known and scrutinized by peers in the security industry to ensure that they remain secure.