MSDN Magazine - November 2008 - (Page 43)

I have said this a million times before, and I’ll say it again: attack surface reduction is as important as trying to get the code right because you’ll never get the code right. I explained this mantra in more detail in my November 2004 article, “Attack Surface: Mitigate Security Risks by Minimizing the Code You Expose to Untrusted Users,” (see msdn.microsoft.com/magazine/cc163882). I’ll give you the short version here: you should reduce attack surface in order to reduce the potential risk to your customers. After all, an interface that is exposed to all attackers is a greater risk than an interface exposed only to attackers on your local subnet simply because there are fewer potential attackers in the second scenario. Looking at my example, I would make the TCP/1234 entry point authenticated by default and allow only authenticated users access to it. This could be as simple as using Basic authentication (yes, I know it’s a lousy authentication scheme) or something more complex, such as Kerberos. This would be my default, and if the system administrator wants to change it to anonymous access, then so be it. But that’s a decision the administrator should make. It’s important to point out that if I do add authentication to the application, then the threat model needs to be updated because there is now an authentication process and an authentication credential database somewhere in the system. Another component of attack surface reduction is to reduce application privileges, and that’s what I want to discuss next. Remember the processes that run as SYSTEM? Well, you need to think about using lower-privileged accounts to reduce the potential damage from a compromise. This is another important part of attack surface reduction. Start with the most exposed entry points. In this case, if the decision is made to allow anonymous access to TCP/1234 by default, then you should ascertain why the process listening on that port needs to run as SYSTEM. Can it be reduced to a lower privileged account? Attack Surface Reduction Also notice that the two network entry points and one file entry point all run in the same process. Is that really appropriate? Two entry points are for administrators, and one is for anonymous users. You should consider breaking this process up into two distinct processes so that you can take advantage of lower-privileged process identities. If you look at the IIS 6.0 and IIS 7.0 architectures, you will notice that the processes handling anonymous and remote user requests (w3wp.exe) runs as Network Service, and the main administrative Give more code review and fuzz testing to the code behind the most exposed entry points. process (inetinfo.exe) runs as SYSTEM. The latter process is limited to administrators. In IIS 4.0 and IIS 5.0, the process handling and the administrative access were often performed by one highprivileged process. Interestingly, a couple of aspects of attack surface reduction have been known for a long time. They are part of the classic Saltzer and Schroeder secure design principles and include least-privilege and least-common mechanism. That second concept, least-common mechanism, needs a little explanation. It means you should reduce the amount of code shared by more than one user or user type. In my example, a single process performing administrative tasks and anonymous user requests can be dangerous. The remediation is to follow what IIS did and split the application into two processes that perform distinct tasks as separate identities. To be absolutely honest, this column doesn’t define anything new. It’s all in the SDL! But the column explains the implicit relationship among the many security disciplines we define, describe and require in the SDL and how a good threat model can help streamline much of the rest of the security work required to ship more secure products to your customers. Build a good threat model, determine your exposure, use a list of entry points (ranked by exposure) to help drive code review and fuzz testing priority, and finally drive your attack surface down. This will lead to more secure software. Are you interested in finding out just how much you know about security? Take the challenging “Security IQ Test” found in this issue at msdn.microsoft.com/magazine/cc982154.  Reducing Privileges What Does It All Mean? Who Is the Bad Guy? Here is the golden rule of security code review: always understand what the bad guy controls. a corollary to this is, who is the bad guy? who the bad guy is depends on the entry point’s level of authentication and authorization. In the case of the first TCP port example given in Figure 1, the bad guy is absolutely anyone on the planet. In the case of the second entry point, the named pipe, the bad guy isn’t really a bad guy because he or she is a member of the local administrators group. If you can’t trust your administrators, who can you trust? Given that you have a finite amount of time, which interface should you code review earliest and deepest? Clearly, it’s the first interface because anyone on the planet can access it. If you have a security bug in that code, anyone can compromise it. To really hammer the point home, think of a worm: worms rely on unauthenticated and remote networking interfaces. msdnmagazine.com Michael howard is a Principal Security Program Manager at Microsoft fo- cusing on secure process improvement and best practice. He is the coauthor of many security books including Writing Secure Code for Windows Vista, The Security Development Lifecycle, Writing Secure Code, and 19 Deadly Sins of Software Security. November 2008 43 http://msdn.microsoft.com/magazine/cc163882 http://msdn.microsoft.com/magazine/cc982154 http://www.msdnmagazine.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - November 2008

Contents MSDN Magazine - November 2008 Toolbox CLR Inside Out Data Points Cutting Edge Security Briefs Test Your Security IQ Agile SDL Access Control Utility Spotlight RIA Test Run Wicked Code Foundations Team System End Bracket

MSDN Magazine - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.