Summary

for RuBoard

So what are the key points to take away from this chapter?

• The most crucial aspect of securing a piece of software is the boundary between your code and code of lesser (or unknown) trust. This boundary can consist of public methods or other forms of communication such as files or network connections. Knowing this allows you to focus your efforts to secure your code on the places where it really matters; maximizing the use of your resources.

• Be paranoid in your dealings with untrusted code. Assume that all code of lower trust is malicious and will try to use your interfaces in ways that don't match their intended purposes. This is important because the 99% case (well behaved, benign code) is not the security threat. The attacks on your code base will be launched by malicious hackers that do not feel any need to follow the rules or use programming interfaces in the manner that you intended. By realizing this, and looking at your interfaces with the rest of the world through the eyes of a hacker, you stand a much higher chance of spotting vulnerabilities in your code that much earlier.

• Assume that all hackers have full access to your source code. Securing code by making vulnerabilities hard to find will not work. By examining your design from this perspective, you are more likely to architect code that is secure at a fundamental level (i.e., enforced security). Remember that a maze might seem complex to navigate, but very often is reduced to triviality by tracing a route backwards from the end target. Hackers almost invariably have this kind of technique at their disposal.

• Be conservative in your approach to exporting potentially sensitive interfaces to untrusted code. It's easier to add than to remove when it comes to such things, and the less you expose, the less that can go wrong. Applying this thinking has benefits at many levels: Reduced code and complexity lead to shorter design, implementation, and testing times and hence to enhanced coverage of the remaining features. Ultimately, this will lead to a more secure (and generally robust) product.

• Consider securing access to sensitive resources through a security choke point. Such a scheme will isolate the trickier security code in one area and might provide performance benefits. This technique has been applied to many areas of software development in the past and has proven its benefits many times over.

• Consider setting up rip cords or configuration options that allow you to quickly secure software that is under attack at customer sites. Just don't let these become security vulnerabilities in themselves . Careful use of such techniques gives you a reasonable contingency plan in the face of security breaches in the field, and may buy you some time in the repair of such breaches.

• Document the security aspects of the software design and make sure that this information is communicated effectively across the entire development team. A little up-front work here will save a lot of heartache later. It's important to adhere to this practice since the other techniques described previously, even if applied rigorously during the design process, are liable to fall by the wayside during the implementation phase unless some means to effectively communicate them forward is used.

for RuBoard