Though security is usually associated with the perimeter; firewalls, IDE and antivirus software, the security of your systems often boils down to how securely the code of your applications was written.
While attending VSLive 2004 in San Francisco, I picked up a few best practices for designing and writing code within the .NET framework. But first, here are some of the threats that your code might be exposed to, courtesy of Gabriel Torok,
- Information disclosure
- Denial of Service
- Elevation of Privileges
This list provides the easy to remember acronym STRIDE. Torok recommends that you categorize the possible threats to your code into the above categories. Since security is about protecting assets, he also suggests that you rank the threats according to the menace they pose:
- Damage Potential
- Affect on users
This list also provides a handy acronym: DREAD.
So once the threats are identified and categorized, how do you go about making sure your code is secure? The first step is to develop the correct mindset: consider security to be a feature of your code. Security should be one of the first considerations in the design process. Portability and efficiency are admirable code qualities, but so is security. Spend time on developing it early in the process.
Once you have established security as a part of your process, here are some more tangible best practices:
- Follow the principle of least privilege. Only allow the code access to the minimum files and directories.
- Encryption standards. Use encryption for password transport. And don't roll your own. The .NET framework supports encryption and standard encryption algorithms have proven their security.
- Prevent reverse engineering and tampering. Encryption is not useful to prevent reverse engineering since the code has to be unencrypted to run. Obfuscation is the best way to secure your code and protect your intellectual property. An obfuscator called Dotfuscator is available in the .NET Framework.
- Fail and recover securely. Test every line of code, even error handlers. Make sure your code is not susceptible to a buffer overrun.
You may want to consider having people on staff that specialize in security. And remember, a secure product is a better product.
Benjamin Vigil is a technical editor for SearchWebServices.com
This was first published in April 2004