Security Concepts
Securing an application is an ongoing process. There will never be a point where a developer can guarantee than an application is safe from all attacks, because it is impossible to predict what kinds of future attacks newer technologies will bring about. Conversely, just because nobody has yet discovered (or published) security flaws in a system, does not mean that none exist or could exist.
Security and the .NET Framework
A question that arises quite frequently is whether one product is "more secure" than another product. This question assumes that somehow a product can deliver security off-the-shelf. However, no software vendor can reliably assert that a product is secure against unknown future attacks. The best that a given product can do is to provide tools for the developer to use to attempt to secure applications developed with that product. The .NET Framework provides cryptographic tools to secure your applications as well as administrative tools to administer security policy. The Common Language Runtime (CLR) provides a type-safe environment for code to run in, with Code Access Security (CAS) to restrict further the permissions of managed code, and Role-Based Security to restrict permissions based on identity. However, you should never assume that simply running managed code is enough to ward off attack. For more information about how you can take advantage of .NET Framework security, see Key Security Concepts.
Designing for Security
One of the biggest problems in developing secure applications is that security is often an afterthought, something to implement after a project is code-complete. This leads to insecure applications where little thought has been given to what makes an application secure. When security is implemented at the last minute, it also leads to more bugs, as software breaks under the new restrictions or has to be rewritten to accommodate unanticipated functionality. Every line of revised code contains the possibility of introducing a new bug. For this reason, you should consider security early in the development process so that it can proceed in tandem with the development of new features.
You never have all of the facts at the start of any project. Designing security is an iterative process that needs to be revisited every time new functionality is added to an application, because new functionality can often lead to new security vulnerabilities. For guidelines on how to design secure applications, see Evaluating Security Threats.
Administering Security Policy
Although CAS can increase the reliability and security of applications, improperly administering CAS policy can potentially create security weaknesses. Security Policy Management provides links to additional information on creating and administering security policy.
Maintaining Security
Once an application is deployed, techniques for monitoring security should be used and risks evaluated as new threats emerge. Make sure that you subscribe to security bulletins and alerts, and that all service packs and patches are up to date. Maintaining Security contains links to additional security resources.
Online resources include the Microsoft Windows Update Service. SQL Server security service packs and downloads are available from this Microsoft Web site. The TechNet Security Resource Center provides technical information and security updates for Microsoft products.
The Human Element
Many successful attacks involve trusted individuals who either maliciously or innocently provide access to secure systems. All employees should be trained in security procedures, and all user activity should be monitored so that attacks by trusted users do not go undetected.
Logging User Activity
One part of monitoring users is to log user activity. Many attacks go undetected due to successful elevation of privilege attacks or from insiders compromising security. Without logging, it is impossible to know when such attacks occur in a timely manner. For more information on logging, see Logging Application, Server, and Security Events. You can also instrument your ASP.NET applications by logging trace information, as described in ASP.NET Tracing.
Running with Least Privilege
It is always advisable to develop and run applications using accounts that have the minimum permissions granted to get the job done. For more information, see the MSDN whitepaper, "The Challenge of Least Privilege".
See Also
Concepts
Other Resources
Securing ADO.NET Applications
Key Security Concepts
Code Access Security
Role-Based Security
Security Policy Best Practices