I know security is serious sh*t. I know that every time some hacker halfwit exploits a small code or configuration imperfection in a system that he could never dream of writing himself, the dung beetles in the press will feed off this excrement with gleeful abandon, telling our customers that our code stinks—simply because some pockmarked malicious pipsqueak managed to manipulate two lines of code, out of a million, into an illegal perversion. I know this.
Microsoft has millions of lines of legacy code, huge farms of networked servers, and hundreds if not thousands of external partners and dependencies. Each of these has the potential to be the next victim of vile, vindictive, vacuous, vessels of vomit whose mothers still wash their clothes. But which items should we focus on securing first?
Eric Aside Ah, the good old days when hackers were just misguided youth trying to make a name for themselves or fighting the powers that be. These days, hacking is big business—either preventing it, tracking it, or engaging in it for organized crime. In retrospect, my anger at the early hackers was misplaced. The world isn’t a place where you can just hope everyone plays nicely. The early hacker wake-up call set us on the proper path of writing secure solid code.
Beware the swinging pendulum
Some people say that every possible vulnerability must be corrected. That’s commendable—but crazy. We can’t get so paranoid that our products become unusable.
When I worked at Boeing, people assigned to “black projects” worked in buildings with no windows, were disconnected from the network, and every night removed their disk drives and locked them in a vault. With all these protective measures, these projects were still considered vulnerable.
Even the biggest security hawks probably don’t think our customers should be required to blacken their windows, stay off the web, and remove their disk drives. However, we must raise the security bar far higher than in the past and require accountability for it from top to bottom in our organizations. The key is to remember that this is all about delivering a trustworthy and delightful experience to our customers.
Other people say that we only need to focus on securing our firewalls, protocols, and common language runtime. They assume that if these are secure, we have nothing to worry about. This is ignorant and downright dangerous thinking.
Writing Secure Code (Microsoft Press, 2002) by Michael Howard and David LeBlanc (a must read) has an entire chapter on writing secure .NET code, which references almost all of the other 15 chapters. This chapter explains that vulnerabilities are not limited to buffer overruns, insecure protocols, and unguarded ports. Even if these items were the only attack points, firewalls, secure protocols, and managed code wouldn’t be enough protection from malicious data.
Eric Aside I refer to the first version of Writing Secure Code in this column. The column was written shortly after the first version was published. Naturally, later versions of the book have even more useful information. Also, Michael Howard has a great Kiwi accent.
Do the right thing
Of course, the right thing to do is to consider every possible vulnerability and rank each in terms of the risk to the customer. Finding vulnerabilities is not as hard as it sounds. By breaking your web or client application into components and interfaces, you can quickly spot potential issues and classify them with the STRIDE model. By searching your code for dangerous APIs (Appendix A in Writing Secure Code), properly restricting permissions, and checking inputs, you can find a ton of easy pickings—the kind that hackers look for. Although a deeper evaluation is necessary to catch more subtle issues, these simple steps will give you a great head start.
Eric Aside STRIDE is a mnemonic device to help people remember the different kinds of security threats: spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Writing Secure Code has all the details.
Next you have to assess the risk of each vulnerability. A vulnerability that allows hackers to discover how we keyword clip art is less critical than one that allows hackers to discover a customer’s private data. There is a higher probability that a vulnerability will be exploited if you can copy a hack from a website and change a couple of values in the script, as compared to a hack that must be tuned to each instance, requires detailed knowledge of the code, and must be written in a low-level language. The more critical the effects, the higher the risk; the lower the probability of exploitation, the lower the risk. Divide the criticality by the chance and you’ve got your risk assessment. (Table 2-2 in Writing Secure Code details this process.)
You’re only as secure as your weakest link
Computing security risks sounds simple enough, but how do you calibrate acceptable risk across a big product like Windows? First, your team has to agree on definitions of the criticality and chance ratings. The commonly suggested range for each is from one to ten, where a criticality of ten is highly critical and a chance of ten is highly unlikely.
Next, calibrate these ranges according to your group’s agreed-upon sense of importance. Is getting read-only database access to product catalog data a criticality rating of two or eight? What about the same access to user data? If you need to write custom COM code to exploit a vulnerability, is it assigned a chance rating of four or nine? What if that code can be written in VBScript? (One very helpful standard for risk assessment of interfaces can be found in Table 14-1 in Writing Secure Code.)
Eric Aside These days, Microsoft security experts have written custom templates in Team Foundation Server(TFS) that automatically map vulnerability types to priority and severity values for security bugs. These custom TFS templates are used internally by big teams to further normalize and simplify the bug tracking process.
After your group has standard definitions of criticality and chance, a high-level triage or war team can set a balanced risk bar across the organization. We already use this process to settle differences between component teams working on large products and to set a consistent quality bar. The same can and should be done for security issues.
Eric Aside To differentiate low-level product and feature triage from high-level product-line triage, we have a variety of funny internal names: war room, box triage, and Ÿber-triage, to name a few. Personally, I could do without the war references.
Lead, follow, or get out of the way
So are you on board with responding to the security challenge? Do you hate the idea of a group of arrogant, asocial peons pushing us around?
Perhaps you are thinking that these loser lawbreakers should be kept off the Net, and that pandering alarmist reporters and editors should have a sense of decency, fairness, and responsibility, not make heroes of hackers and not vilify Windows beyond all other platforms and systems. Perhaps you are thinking that if these hacking incidents were taken with the proper perspective, then maybe we wouldn’t all be going through this fire drill. Unfortunately, this is the world we live in, fair or unfair, true or exaggerated.
Let’s face it. No one likes being hacked and few of us praise hackers for their creativity and civic service. But letting snidely, sniffling, scurvy scum have control over the hearts, minds, and computers of our customers is completely shameful.
Sure Linux, Oracle, Sun, IBM, and AOL have as many, if not more, security problems than we do. But as BrianV says, “We are the leader in this industry and we have to lead!” Nothing short of a full commitment is acceptable.
Eric Aside Brian Valentine (BrianV) was the senior vice president of the Windows division at the time. Nearly a decade later, security is baked into all our products and services. It is a way of life we all accept, appreciate, and strive to understand.
Be First to Comment