I realize that security is a system level issue and it takes a long time to change things at that level, but what's more concerning to me is that the typical infosec mindset remains the same. Should we be surprised by rampant phishing and fraud? I am frankly surprised the numbers are so low given the opportunities that the attackers have via the glacial pace of security improvements. Its been three years since that list and I could write the same exact one today for SOAP, REST, SOA, Web 2.0 whatever. Maybe the main reason, beyond failure of imagination, why infosec is so far behind developers is that infosec lacks tools. Developers automate everything possible. Security doesn't. The most promising thing about static analysis is not the ability to find everything, its the ability to find many important things in an automated way. Infosec needs to stop giving people fish and teaching people to fish. Look at Fortify's vulncat site which has a Taxonomy of Coding Errors. Fortify's Seven (plus one) pernicious kingdoms are:

1. The number of potential terrorist targets is essentially infinite. 2. The probability that any individual target will be attacked is essentially zero. 3. If one potential target happens to enjoy a degree of protection, the agile terrorist usually can readily move on to another one. 4. Most targets are "vulnerable" in that it is not very difficult to damage them, but invulnerable in that they can be rebuilt in fairly short order and at tolerable expense. 5. It is essentially impossible to make a very wide variety of potential terrorist targets invulnerable except by completely closing them down.

1. Any protective policy should be compared to a "null case": do nothing, and use the money saved to rebuild and to compensate any victims. 2. Abandon any effort to imagine a terrorist target list. 3. Consider negative effects of protection measures: not only direct cost, but inconvenience, enhancement of fear, negative economic impacts, reduction of liberties. 4. Consider the opportunity costs, the tradeoffs, of protection measures.

This paper attempts to set out some general parameters for coming to grips with a central homeland security concern: the effort to make potential targets invulnerable, or at least notably less vulnerable, to terrorist attack. It argues that protection makes sense only when protection is feasible for an entire class of potential targets and when the destruction of something in that target set would have quite large physical, economic, psychological, and/or political consequences. There are a very large number of potential targets where protection is essentially a waste of resources and a much more limited one where it may be effective.

Your first real lesson about locking down a host was how to reduce its attack surface. You learned how to disable services using /etc/inetd.conf. Then you learned about rc.d and how to prevent unnecessary services from being launched at startup. Next, maybe you configured the Xserver to disallow remote connections or moved on to removing setuid permissions from files. As you worked, you’d periodically re-scan the box to gauge progress, asking yourself “have I removed everything I don’t need?” The underlying motivation, of course, is that an attacker can’t hack something that isn’t there.

You learned how to extend those concepts to the network — configuring firewall rules, router ACLs, VLANs, etc. Segmenting the network. Creating a DMZ. No need to dwell on this, you get the idea.

Eventually, people realized that applications had an attack surface too. Web servers and application servers got a lot of attention, followed closely by custom web applications. “What do you mean you can execute SQL queries against my database? That’s impossible, I have a firewall!”

Some companies, the ones who could afford it anyway, started to build security into their development cycle. Doing threat modeling during the design phase made sense, because hey, it’s much cheaper to fix security holes in a whiteboard drawing than it is to rewrite your authorization module from scratch after it’s in production.

Let’s talk strictly about custom web applications now. What I’ve observed is that most development groups, even the ones who actively engage in threat modeling, do not understand their web application’s attack surface. The lead architect can whiteboard a high-level diagram of all the major components and how they interact. Individual developers can go a bit deeper, telling you which files they touch, what database permissions they need, or how various pieces of data are encrypted in storage. At the end of this exercise you have a complete picture of the processes, data flows, protocols, privilege boundaries, external entities, and so on, and you’re well on your way to understanding all of the potential attack vectors.

Or are you?

What often gets overlooked or glossed over is the impact of external libraries or packages. Nobody writes everything from scratch. A typical list of third-party libraries for a Java-based Web 2.0 application might include DWR, GWT, Axis, and Dojo, plus about 30 other libraries to do everything from logging to parsing to image manipulation. Nine out of ten times, the libraries will be installed in full, using the default configuration from page one of the README file.

Why is this relevant? Because just as those old Unix boxes exposed unnecessary services, libraries expose unnecessary code. Let’s say you installed Dojo to simplify the process of creating an HTML table with rows and columns that can be sorted on demand. Did you remember to remove all the .js files you didn’t need? Or maybe you installed Axis or DWR or anything else that has its own Servlet(s) for processing requests. Have you compared what that Servlet can do against what you need it to do?

A fictitious example may help illustrate further. Imagine you just downloaded a new library called WhizBang. You follow the installation instructions to define and map two servlets in your web.xml file, WhizServlet and BangServlet, and you configure it to integrate with your web app. After a bit of trial and error, it’s functional. Yay! This is where most developers stop.

Nobody asks, “how much of this do I actually need?” Case in point, what if your application only uses WhizServlet? BangServlet is still exposed, and you don’t even use it! Similarly, what if WhizServlet takes an “action” parameter which can be either “view”, “edit”, or “delete”, and your application only uses “view”? You’re still exposing the other actions to anybody who knows the URL syntax (pretty trivial if it’s open source). You wouldn’t expose large chunks of your own code that you weren’t using, so why should it be any different with libraries?

This post is getting kind of long so I’m going to split it up. In the next post, I’ll continue the discussion of attack surface minimization, as well as some of the tradeoffs that go along with this approach.

First, let me say what I knew about the SDL going in: no policy can anticipate every situation; you have to make tradeoffs; the details matter; the big picture matters; you need tools; you need human insight; you need management support; and we’re never going to be perfect. All of the things you’ve read in this blog are true, and they really shouldn’t be controversial. Since joining SQL, I’ve learned a lot about SQL Server too, and what it means to ship a product - but that’s outside the scope of this blog. So instead, I’ll try to describe three real experiences that illustrate things that shouldn’t be controversial either, but aren’t usually covered under the rubric of security.  They are crucial nonetheless.

Security is not the point, it’s the needs of the customer. It’s easy to believe that security is the point of producing a product. It’s not. We won’t produce an insecure product, but the primary driver for a product team is to produce a valuable, useful product. Yes, security is a big part of that, but security is not a goal in and of itself.  For example, one of the areas of fierce competition in enterprise database products is performance, and we have to balance security with  performance. One of the ways we do that is by verifying data we receive really well, but only when necessary. We define clear trust boundaries, and check the data thoroughly once on the way in, and then work very hard to enforce those trust boundaries.

I first encountered this in SQL when I helped review threat models for the database engine. The engine trusts that the data on the disk was written correctly by a trusted entity (with checksums to guard against random errors), and enforce that. Instead of a slavish adherence to the principle of total mediation or defense in depth, which, when taken to its extreme would say to “check everything, every time,” we are hard core about making the right checks, but only the right checks.

I will note that it is not an either/or choice between security and performance – it is possible to do both. Indeed, I would say that doing one without the other is pointless, but to get both 1) world class performance, and 2) world class security,  you have to understand your data flows really well, and make detailed decisions.

Be polite, but don’t be afraid: Job interviews at Microsoft can be challenging. When I interviewed for this job, my final interview was with a very senior architect. The subject of integer overflows came up, and he asked me to describe the problems and solutions. So I started writing some code on the whiteboard. After about 10 minutes of describing my approach to integer overflows, he said to me, “What if I were to tell you that’s a really bad solution, and the interview is over?”

My heart sank.

But instead of rolling over, I said, “well, that’s a bad outcome, tell me why.” He proceeded to attack my solution on several grounds, including being unreadable and unmaintainable, and he proceeded to describe his solution to the problem. Now, this was a very serious, very senior technical architect, and I was in a high pressure, asymmetric situation. So, not willing to be intimidated, but unable to attack back, I pointed out several shortcomings of his solution, politely, but firmly. And we spent the next 40 minutes talking about various aspects of the problem, and me defending my solution, which I think was credible. I don’t know if he agreed with my solution or not, really, but I suspect it might have been a test to see if I would cave. Or maybe he thought it really was a bad solution, I don’t know. But I got the job.

As a security professional, you’re always going to be at a technical disadvantage when you’re reviewing another team’s components. They designed and implemented the system. You are an outsider, and it is absolutely impossible to understand the system to the degree as the people who built it. Nonetheless, you’ve got to find a way to ask hard, probing, impolite and sometimes even uninformed questions without being threatening or insulting, or undermining your own credibility.  

Be polite, be firm, put your ego in a box, and ask questions until you understand.

“It should work” is not a good answer:  We take the giblets problem very seriously, and managing giblets can be quite difficult at times. And in SQL, we have lots of giblets. We consume things from Windows, and Office, and Visual Studio, and others, and we provide giblets to other teams as well. In fact, we provide components that other teams use to build the giblets they provide to us – we consume our own giblets!

And as it happens, one of the components we use was updated recently. Even though it would get serviced through Microsoft Update, we want to ensure we have the latest and greatest version of any component we ship. But to consume the latest and greatest version of this particular component would require some small updates to either our installer or theirs. So we met with the team that owns the giblet in question to try to divvy up the work, and to avoid schedule disruptions on either side.

There was a lot of back and forth about various things to try, and we continued to refine a solution until we had reduced the problem to a single issue. 

At this point, there was an air of hope in the room. If the idea actually worked, we had a solution at relatively low cost. But would it work? When the question of “will this work” comes up, all eyes turn towards test managers.

Our general manager was looking right at our test manager and she asked, “Will that work?” The test manager looked across the table at the development manager from the other group, and said, “I don’t know. That depends on their level of confidence in the behavior of their component under these conditions.”

Now, all eyes were starting at the dev manager, and the room got quiet. A somewhat sheepish look came over his face, because he knew the answer he was about to give would be unsatisfactory. He said, “Well, I’m not a tester, I’m just a developer, but it should work.”

At which point the room erupted into hysterical laughter.

“It should work” means “I think so, but we have to test it.” And that means the whole battery of tests for each of the affected components, across all of the supported platforms. And that has to be scheduled in test labs. To be clear, this wasn’t a lack of confidence in the developer, quite the contrary, he was laughing along with everyone else. We just know that writing software to satisfy all the scenarios in which our software is deployed requires far more testing than can reasonably be performed on a single desktop system.

So the tests were scheduled, the developer was proven correct, and we’re picking up the latest version. Even seemingly simple changes require a lot of testing.

So, that’s what I’ve learned: security isn’t the be-all-end-all,, things are really complex and hard to understand, and you don’t really know if anything works until you test it. None of which should be controversial, but none of the central ideas in the SDL are controversial either. The hard part is putting theory into practice, and recognizing that no venture is risk free, despite the natural inclination of security engineers to avoid any risk whatsoever. In this, I am reminded of one of my favorite books, “To Engineer is Human: The Role of Failure in Successful Design,” by Henry Petroski. He writes, “No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art. Contrary to their popular characterization as intellectual conservatives, engineers are really among the avant-garde. They are constantly seeking to employ new concepts [and are] constantly striving to do more with less. [] The engineer always believes he is trying something without error, but the truth of the matter is the each new structure can be a new trial. [] Such is the nature not only of science and engineering, but of all human endeavors.”

You raise some interesting points on which I would like to comment. First, RSA believes that there are always tradeoffs between strength of security, cost and ease of use. The key (no pun intended) is matching the right means of authentication to the right level of risk. This is why we have such a broad range of authentication types and form factors.

To some of your specific points, RSA SecurID hardware and software authenticators are both forms of multi-factor authentication. In the case of hardware authenticators, they are based on something you have (the physical authenticator) and something you know (your password or Personal Identification Number). Software authenticators work the same way depending on the form factor and can include other factors.... ]]> Mon, 10 Dec 2007 21:00:00 +0000 authentication multi-factor authentication software authenticators rsa securid hardware rsa form factors factors authentication types blog entry In response to "Soft tokens aren't tokens at all" http://securityratty.com/article/0b2de27ab1ef185846b968c1dd9088d2 http://securityratty.com/article/0b2de27ab1ef185846b968c1dd9088d2 Adam Shostack here, with the second post in my series on the evolved threat modeling process. To summarize, what I’ve tried to achieve in changing the process is to simplify, prescribe, and offer self-checks. I’ll talk in the next post about why those three elements are so important to me. For now, let me describe the process.

One of the largest changes that we’ve made is to a simplified process (and diagram). I like to say that this looks pretty much like every other software process diagram you see today. That’s intentional. There’s only so much we can expect people to take away from a class, and making this simple and familiar helps ensure there’s room for the other important parts.

First, the “process hamster wheel,” (with apologies to Yankee Group analyst Andy Jaquith):

Now that you’ve seen the wheel, I’ll briefly describe the steps:

1. Vision: Consider your security requirements, scenarios and use cases to help frame your threat modeling. What are the security aspects of your scenarios? What do your personas expect or hope doesn’t happen? What are the security goals of the system you’re building, and how do those interact with the system as it stands?
2. Model: The basic idea is to create a diagram of your software, showing all trust boundaries.

a. Draw a diagram of your software. We encourage use of the DFD formalisms, which Larry Osterman describes in this post.

 

Essentially, the elements are

1. External entities (anything outside your control)
2. Processes (running code)
3. Data stores (files, registry entries, shared memory, databases)
4. Data flows (which connect all the other elements)

b. Draw trust boundaries between components. You can do this on a whiteboard, in Visio, or in one of the specialized threat modeling tools we’ve built. (A trust boundary is anywhere that more than one principal can access an object, such as a file or process.)

c. If your trust boundary crosses something which isn’t a data flow, you need to break it into two logical elements, or draw a sub-diagram with more details. (This is different advice: we used to tell people trust boundaries could only cross data flows. People drew them anywhere that felt right. We decided to go with what people were doing—there was important information in what they were expressing.)

d. If you need more details to express where trust boundaries are, add an additional diagram.

e. When you don’t have any more trust boundaries to draw, you’re done.

f. If a diagram doesn’t have any trust boundaries, you may have drawn too many details.

3. Identify Threats using STRIDE/element

For each element in your diagram, consider threats of the types indicated in this chart. (We’ll come back to the chart’s origins in a later post.)

There’s an important mis-conception we often see, which is that STRIDE is appropriate for use as a classification system. It’s really hard to use STRIDE to describe attacks—the impacts blend together really quickly. The most valuable use of STRIDE is to help people think about how threats have impacted elements of a design in the past. That is, it’s a framework for finding threats, not for describing them. “What if someone spoofs this host?”

 

4. Mitigate

Here on the SDL strategy team, we love threat modeling. We know that not everyone feels that way, and we ask teams to threat model so that they can find and mitigate threats. A threat model document with great diagrams and lots of threats isn’t very useful if you don’t take the key step of addressing the issues you find. There are four ways to do that:

a. Redesign to eliminate threats.

b. Use standard mitigations, such as those provided by OS features, to mitigate threats.

c. Invent new mitigations, understanding that this is a subtle art.

d. Accept risk, when allowed by the SDL

5.  Validate

There are two levels of validation. The first is within each stage, the second is a validation pass at the end of the process. That end of process validation entails:

a. Make sure that the diagrams are up-to-date and accurate

b. Ensure that you have STRIDE threats per data flow that crosses a trust boundary, and for each element that such a trust boundary connects to

c. Make sure you’re mitigating each threat

i. You have a bug filed per threat that you want to mitigate. The bug should be of the form “attacker can do X. Proposed fix: Y.” You might include tradeoffs you’re making, and possibly have test plans in the bug, if you include those.

ii. You have a valid reason for each non-mitigated threat not being mitigated.

iii. All threats are in class i or ii.

5.a. On change, re-validate

 

This hamster wheel has a very intentional brake on it: the word change, above validate. What that means is you want to go through the process again when you make changes that need to be on the diagram. Checking to see if your diagrams change is a relatively simple check that allows people to track changes against their threat model as their design iterates.

In the next post, I’ll talk about the reasoning behind the design, and offer up some process tools that anyone can use to make a process more user-friendly.

1. Run the Windows Firewall
2. Keep Windows and your applications up-to-date
3. Use current antivirus software
4. Use current antispyware

These are good recommendations for organizations, as well.

But as I've talked about many times in the past, security decisions always involve tradeoffs. They also (should) involve an intimate understanding of what the users will be doing with their computers. Fact is, most individuals who are not full-time security professionals often make mistakes when trying to decide whether something is legitimate -- witness the ongoing success of phishing and 419 scams. And organizations, unless they run highly locked-down environments, often can't know everything their users are doing.

As I said in the previous post, anti-malware is not useless. It is a necessary element in your suite of defensive technologies to help keep the bad guys at bay. In my post I'm simply explaining a personal tradeoff I've made on my own machines at home--that by not running as admin (which I didn't mention before), by using UAC, by relying on the firewall, and by training my family--I have made the decision not to use anti-malware.

So should you make the same tradeoff? Well, that depends. If you're asking me about your own use of your own personal computers at home, I can't answer that for you, you need to. Remember what I wrote: "I know what to click and what to skip, what to visit and what to avoid. I have control over what I choose to open, what I choose to load, and what I choose to run." Do you have similar self-control? :)

If you're the security administrator for an organization, you should not make this tradeoff. Again, remember what I wrote about my own self-control; I doubt that anyone could make such a statement for everyone in their organization! Antimalware definitely belongs on machines where users can store or transfer files:

• client computers
• email servers
• file servers
• SharePoint servers

The purpose of my earlier post was to spark a little discussion, to see what other opinions there might be. Some folks are doing the same thing I am, others always run anti-malware on every computer. Neither stance can be declared "right" or "wrong." It's simply a reflection that we all make tradeoffs, every day, when we decide how to manage and use our computers. And as I suspected, different folks make different tradeoffs, based on their own risk tolerance and experience. These are always good conversations to have.