Building TrustApplication Security

Building Trust Application Security

But that can't happen to us because it's always been a matter of trust.

Billy Joel, "A Matter of Trust"

In closing this chapter, we get around to the core component over which developers have control: application security. The number of protections you place in an application is dependent on the level of trust you place in the rest of the system components' having done the right thing. Before going any further, let us share a colorful phrase often used by one of our co-workers that summarizes one way to view this: "If you didn't build it, it's crap!"

Granted, this may be extreme in most situations. It does, however, set the stage for the key to application security, which, when it comes down to it, is the entire purpose of this chapter. This key is, application developers should do what they can to ensure the integrity, security, and utility of the data or resources their applications provide, utilize, or transport. Further, developers should not rely on others for their security and should do what they can in this regard.

To put it more generically, those responsible for each component of a system should do what is in their power to provide protections for resources or potential targets for malicious attackers. If it is necessary for you to rely on another component or resource to provide this protection for you, do not assume that this has been done. Verify that what you expect to be present and functional actually is. Anticipate failures or compromises in these protections, and have redundant or supporting mechanisms in place to protect critical information or components. If the protections required are outside the scope of your portion of a system, you should monitor or log activity and issue a warning when something potentially unscrupulous is detected.

In closing, we leave you with another quote, which verges on being rather "spy versus spy" in nature. You have followed the I-ADD process and have done all that is within your power to protect the resources of concern. There may still be areas where the system is vulnerable, either because of the security/functionality trade-offs (more on this in Chapter 12, "Define and Design") or because you intentionally presented or left a vulnerability unmitigated. However, this seeming vulnerability is heavily monitored as an early warning system for potential malicious activity. The point being, sometimes knowing when you have been compromised can be as important as protection against the compromise. If you can't protect, detect.