Fail Safe - Your application must always fail safe. That is to say if it encounters a situation and it can no longer proceed, it must deny access to the resource. For example, if a firewall can not validate the action that is being requested by the requester, it should reject the operation; this is known as fail close or fail safe.
Secure the Weakest Link – The security of an application is that of its weakest link thus, it is important that all components in the application are secured and not just the operating system or database server. This also means that as a developer you must protect any resources your code owns or is responsible for.
Security Through Obscurity Does Not Work – Obscurity should not be used as the only or primary security mechanism.
Simplicity - Complexity increases the potential risk of problems. Application architecture and implementations should be as simple as is practical. This also makes it easy to do the right thing.
End to End security – Where data requires protection during transportation, it should be enforced from the sender to the recipient (end to end).
Compartmentalize - Applications should compartmentalize user access. Compartmentalization provides user access to data and functions that they require and restricts them from accessing data or functions they do not need.
Defense in Depth - Applications should use multiple layers of security. This ensures that if one security mechanism is vulnerable to an attack, an additional layer will still enforce an adequate security policy. Password files for example, should be restricted by access control lists and encryption. Similarly even if data is validated, the use of stored procedures or prepared SQL statements is strongly recommended since it adds an additional layer of defense.
Least Privilege – Applications should run with the minimum amount of system privileges that they need to function. Where elevated privileges are required they should be granted for the minimum period of time they are required. A similar principle is the “need to know” principle. Ensure that only the minimum number of people have administrative level access to production web, database and application servers.
Trust but Verify – Applications need to trust other applications or objects on the same host or on the network, however, they must always verify the source they are trusting. The same also applies to users and their actions. For instance, before performing any administrative action, it is important to check that the requesting user is indeed an administrator authorized to request such an action.
Think Strategically – There are no security silver bullets. Security requires constant monitoring and improvement and is not somebody else’s responsibility. Pay special attention to architecting the right solution so that it maybe reused frequently. The use of software design patterns like Model-View-Controller (MVC) and frameworks like JAVA Struts are therefore strongly encouraged.
Attribution
This content was provided by Foundstone and prepared by Nick Murison.
