In-Depth

5 Non-Coding Procedures for Securing .NET Applications

Organizations that encountered security breaches have lost large sums of money, both directly and indirectly in terms of damaged reputations, layoffs, fines, etc. With so much at stake, developers need to turn to IT security, which is now a must for any IT department.

• By Sam Nasr
• 10/15/2015

It's been said that developers are essentially "guardians of data." When developers hear the words "application security" the first thing they think of is writing good code to safeguard against security attacks. While that's a correct approach, it is not the only approach. To fully protect an application and its data, one has to think of security as a holistic solution, not just coding. All the secure coding practices can never safeguard against a criminal physically removing a server. Likewise, physical security alone is never enough to protect against a security breech. Instead, a combination of secure coding, physical security, and other procedures can help reduce security vulnerabilities significantly.

In this article I will discuss the following non-coding procedures to help secure an application and its data.

• Protect your servers
• Configure your .config
• Review your security code
• Test your security
• Audit your process

Protect Your Servers
The location of servers is something most developers take for granted. Surprisingly, the server room is not always secured, and often any employee or non-employee can enter that room. Once I visited a medical facility that had an air conditioning issue in the server room. To help with the heat ventilation, the door was propped open to the server room leading to a public hallway in the office building. This put the servers at great risk where anyone could simply walk in, disconnect cables, remove hard drives, or walk out with an entire server.

All the secure coding techniques in the world could not protect that company from losing sensitive data, application downtime, and/or the public embarrassment if any of those events took place. Servers need to be housed in a secure location where only a select few people have secure access.

In cases where server space is outsourced, question the vendor on facility security, and ask to visit the facility if possible. Ensuring the servers are physically secure should be the first step in securing your applications.

After the environment is protected physically, it also needs to be protected digitally. Depending on the OS used on the server, various feature access (anonymous FTP access, shared folders, etc.) will need to be turned on/off as needed. In addition, only the minimal software should be installed on it to perform the required tasks. A properly configured server will not only be more secure, it will run faster with less chance of conflict with other programs.

Configure Your .config
One of the most revealing ways of exposing information about your application and data is by allowing specific errors to be exposed to users. Once an application encounters an error, it will produce a message similar to that shown in Figure 1.

This not only looks unpleasant to a user, but also exposes key information about the application. In this case, database name and location are fully exposed as part of the error message. To avoid this, simply set the mode attribute of the <customErrors> element to "On" or "RemoteOnly". To learn more about this, visit http://bit.ly/1V4A6Kp.

Although <customErrors> is important, it's not the only element that requires attention. Many other elements in the .config need to be configured correctly to close security loop holes. Some of those elements are <connectionString>, <impersonation>, and ValidateRequest. To learn more about these items and others, please visit http://bit.ly/1Jj3qRs.

Security Code Review
Another useful tactic in safeguarding against security attacks is to implement code reviews solely for code security. Traditionally, code reviews are implemented to ensure a developer adheres to coding standards set forth in an organization. However, just because code adheres to standards and works well, does not mean it can prevent the various forms of security attacks (i.e. SQL injection, XSS, etc.)

A security code review should be a separate review process that focuses solely on the security aspects of the code. This may beg the question: "Why not implement the security code review along with the traditional code review?" This can certainly be done. However, doing it as a separate review process with a different reviewer can ensure a more thorough process. People generally have the attitude of "next, next, next…" when trying to get through a long process. Combining the security code review process with the standard code review could lead to that mentality and eventually render the process useless.

In addition, your team should maintain a security checklist to review against the code. One such list can be found at http://bit.ly/1MzWWoD. Since the number of security threats always continues to increase, this list will only continue to grow and never remain static. Furthermore, the same list can be used in the security-testing phase.

App Security Testing
Many organizations have a testing process in place for testing application functionality and user acceptance testing. However, just because an application works correctly doesn't mean it's hack-proof. Once again, the security testing process should be done as a separate process and formalized as much as possible. Developers should have a list of hacks and security vulnerabilities to test against, similar to that used for the security code review. This list will continue to grow since hackers are always discovering new ways to penetrate an application.

Audit Your Processes
Implementing procedures is one thing -- having your team follow them is another. It's always a good practice to schedule a minimum of one hour every quarter to review the processes mentioned previously with your team.

First, examine the list of security vulnerabilities used for both the security code review and security testing phases. Compare this list with the latest security threats exposed on the Internet to ensure your methods are not outdated. One useful site for this is the "OWASP Top Ten Cheat Sheet", available at http://bit.ly/1vNnCXN. As the name suggests, the Open Web Access Security Project (OWASP) maintains the list.

Another part of your audit is to ensure the servers are physically and digitally secured. Check the physical perimeter, as well as the components installed on it to ensure everything is approved. Lastly, spot-check various .config files in production to ensure best practices are followed and security vulnerabilities are minimized.

Security Through Diligence
Security attacks are only increasing in frequency and severity. The outcome of each attack varies in each scenario. It can range from public embarrassment to multi-million dollar losses. Protecting a company's assets is essentially protecting its future and the jobs of its employees. The non-coding procedures discussed in this article can help protect any company's information assets and minimize its security vulnerabilities.