The Basics of Securing Applications

In this next One on One with Visual Studio conversation, we’re joined by Steve Syfuhs (@stevesyfuhs), who is a Canadian developer security MVP. I’ve asked him to chat with us about code security – more specifically, what we can easily do to ensure that our code is safe from common threats and how we can use Visual Studio and Team Foundation Server to do that.

As in the past, our conversation will be broken down into parts to allow you to squeeze the conversation into your busy schedule. I’d recommend that you go in order as each segment builds on the previous.

• Part 1: Development Security Basics
• Part 2: Vulnerability Deep Dive
• Part 3: Secure Design and Analysis in Visual Studio 2010
• Part 4: Secure Architecture
• Part 5: Incident Response Management with Team Foundation Server

Remember, this conversation is bidirectional. Share your comments and feedback in this Ignite Your Coding LinkedIn discussion. Steve and I will be monitoring the discussion threads and will be happy to hear from you and answer any questions you may have.

Steve, on behalf of myself and the developers in Canada, I would like to thank you for taking the time to have this conversation with us and for the effort you put into conversation, allowing us to better understand how to secure our applications.

So without further ado, Steve, take it away.

Thanks Jonathan, and hello Canadian solution developers.

Every year or so a Software Security Advocacy group creates a top 10 list of the security flaws developers introduce into their software.  This is something I affectionately refer to as the stupid things we do when building applications list .   The group is OWASP (Open Web Application Security Project) and the list is the OWASP Top 10 Project (of which I have no affiliation to either).  In this conversation, we will dig into some of the ways we can combat the ever-growing list of security flaws in our applications.

Security is a trade off.   We need to balance the requirements of the application with the time and budget constraints of the project. A lot of times though, nobody has enough forethought to think that security should be a feature, or more importantly, that security should just be a central design requirement for the application regardless of what the time or budget constraints may be (do I sound bitter?).

This of course leads to a funny problem.  What happens when your application gets attacked? There is no easy way to say it: the developers get blamed.  Or if it's a seriously heinous breach the boss gets arrested because they were accountable for the breach.  In any case it doesn't end well for the organization.

Part of the problem with writing secure code is that you just can't look for the bugs at the end of a development cycle, fix them, and move on.  It just doesn't work.  Microsoft introduced the Security Development Lifecycle to combat this problem, as it introduced processes during the development lifecycle to aid the developers in writing secure code.

Conceptually it's pretty simple: defense in depth.

In order to develop secure applications, we need to adapt our development model from the beginning of development training, all the way up to application release, as well as how we respond to vulnerabilities after launch to include security requirements. Now, Microsoft, for example, has a vested interest in writing secure code, so it went all in with the SDL.  Companies that haven't made this decision may have considerably more trouble implementing the SDL simply because it costs money to do so.  Luckily we don't have to implement the entire process all at once.

During this discussion we'll touch on some of the key aspects of the SDL and how we can fit it into the development lifecycle.

Perhaps the most important aspect of the SDL is that it's important to have a good foundation of knowledge of security vulnerabilities.  This is where the top 10 list from OWASP comes in handy: 

1. Injection
2. Cross-Site Scripting (XSS)
3. Broken Authentication and Session Management
4. Insecure Direct Object References
5. Cross-Site Request Forgery (CSRF)
6. Security Misconfiguration
7. Insecure Cryptographic Storage
8. Failure to Restrict URL Access
9. Insufficient Transport Layer Protection
10. Unvalidated Redirects and Forwards

Next up, we'll take a look at a few of these vulnerabilities up close and some of the libraries available to us to help combat attackers. We’;; see how different steps in the SDL process can help find and mitigate these vulnerabilities. After that, we'll take a look at some of the tools Microsoft has created to aid the process of secure design and analysis. Then, we'll dig into some of the architectural considerations of developing secure applications. Lastly, we'll take a look at how we can use Team Foundation Server to help us manage incident responses for future vulnerabilities.

Looking forward to the discussion.

About Steve Syfuhs