Geeks With Blogs

News Google

Nick Harrison Blog<Nick>.Next()

One of the most intriguing topics in computer security is defense in depth. This basically means having many layers to security. Think about the walls and defenses in a medieval castle. An intruder has to storm each of the outer walls before they could get access to the castle. This is the same logic that leads to system designs with firewalls, intrusion detection systems, demilitarized zones, etc.

The idea is that if one layer is breached then other layer may catch and stop the intrusion. More likely, having to breach each layer may slow the intrusion down to allow professionals time to catch the intruder in the act.

As a developer, you may think this looks like a bunch of stuff for the infrastructure guys. Looks can be deceiving.

There is a great deal to be done from a development perspective to augment the work already being done. The most important area for us to focus on is data validation, logging, and exception management. Most developers finally understand the importance of validating user input, but how many of us validate anywhere else? Do you validate data read from the database? Data read from the registry? Data read from a config file?

This is defense in depth. Consider UI input validation the otter most wall. In many ways this is a convenience for the users who are using your application as intended. Validations in the business layer are another wall. Validations in the data access layer are another wall. Validations in the database schema are a final wall. Each wall is important, and each wall should not negate the need to do validations on the next.

Now for an added twist, what do you with your validation results? Specifically, what do you do when an input validation fails? Do you log it anywhere? Are you tracking it?

Most likely, you reject the input. You probably complain to the user explaining what the correct input should be, but do you log these details anywhere? Logging failed input validations becomes a critical part of intrusion detection. Seeing that someone attempted a SQL injection attack gives you advance warning that someone is probing your system for vulnerabilities. Logging such details and keeping track of these logs may reassure you that your validations are working. It may also give you an indication of where future attacks may originate from. Every piece of information can be helpful.

We have also heard repeatedly about the perils of displaying system information in exception details. We all know not to display too much information to the user and risk giving away details like file locations, database location, database version, code details, etc. Sometimes even the very fact that an exception was thrown can give an intruder all the details they need. Have you heard of blind sql injection? We can also this information to our advantage. Whenever an exception is thrown, chances are that someone is using our application in a way that we did not predict. By reviewing the exception logs, we may be able to see patterns of unexpected use. This may alert us to someone attempting something like a blind sql injection or trying to overflow a buffer or trying to break the system to see what details they can find. With a good exception management strategy in place, they are also letting us know where the next attack may come from and what form it may take.

Seen from this perspective, mundane tasks like input validation and exception management suddenly take on a much more exciting, exotic feel.

Posted on Monday, October 4, 2010 11:39 AM | Back to top

Comments on this post: Defense in Depth: A Developer’s Perspective

comments powered by Disqus

Copyright © Nick Harrison | Powered by: