Security Discipline

There are a couple of basic rules of thumb that should be followed when either configuring or programming security. The first is the principle of least privilege, which is primarily a conservative guideline that helps avoid unforeseen risks. The other rule of thumb is that you should try to plan ahead by establishing security policy early in the project life cycle.

Principle of Least Privilege

Many programmers recommend that you do not run a development tool such as Visual Studio .NET under administrative privileges. In situations where you temporarily need greater privileges, you can use the runas utility, which allows you to specify a username and password for an individual command line.

This is the principle of least privilege, which dictates that you should work with only the minimal set of necessary privileges required to perform the application's task, and no more. The argument is that you should be aware of the security restrictions that will be in effect when the application is deployed. Fortunately, you don't need to be an administrator to run Visual Studio .NET and debug your .NET applications.

Unfortunately, this can be very awkward during development, so you may prefer to work as an administrator during the development phase only. Then, during the testing and debugging phases, which require that you much more closely simulate the realistic runtime environment of the deployed application, revert to a more limited set of privileges. Of course, when the application is deployed, it should run strictly under minimal privileges according to the principal of least privilege.

Establish Security Policy Early

It is important that security issues are understood and designed into the application early in the life cycle of the project. It can be very difficult to add security as an afterthought to an existing project.