Author: admini

At the same time, it’s likely you won’t have thought of everything or implemented defenses against every possible attack. It’s very unlikely you have a home defense management plan or have ever run a penetration test against your home.

As we build software, regardless of whether we’re in an agile or a waterfall world, we need agreement on what we’re building, what we’re not building, and what we’re doing to ensure we’re building the right thing. In the past few years, a perception that threat modeling is a heavy, bureaucratic process has been generated. There are some good reasons to move toward adding processes; I’d like to talk about them, some lessons learned from these processes, and how to put the fun back in threat modeling while making it an efficient, agile-friendly activity that anyone can do.

Approaches to Threat Modeling
There are many things called threat modeling. Rather than argue about which is “the one true way,” consider your needs and what your skills, abilities, and schedules are, and then work with a method that’s best for you. As part of that approach, some people ask, “What’s your threat model?” and “Have you threat modeled that component?”

One is requirements elicitation, the other design analysis. At Microsoft, we almost always mean the latter technique. There are more threat modeling methods out there than I can dream of covering in one column. There’s also a tremendous diversity of goals. Should your threat modeling process be fast or deep? Should it focus on assurance and completeness, or ease of use? Should you involve experts or developers in every meeting? Do you have organizational or industry rules you need to follow, such as the Microsoft® Security Development Lifecycle (SDL) or the rules for medical device manufacturers?

The high level objective should be to understand security issues early so you can address them in the design rather than try to overcome design flaws later. Some of the major ways to approach threat modeling activity include the following:

Assets
Asset-driven threat modeling is much like thinking about what you want to protect in your house. You start by listing what assets your software has associated with it, and then you think about how an attacker might compromise those assets. Examples include a database that stores customer credit cards or a file that contains encrypted passwords. Some people may interpret an asset as an element of the threat modeling diagram, thinking that a Web server itself is an asset. Digital assets are things an attacker wants to read, tamper with, or deny you the use of.

Attackers
Attacker-driven threat modeling involves thinking about who might want your assets, and it works from an understanding of their capabilities to an understanding of how they might attack you. This works great when your adversary is a foreign army with a known strategic doctrine, physical world limits, and long-lead-time weapons systems development. This works less well when your adversary is a loosely organized group of anonymous hackers. More generally, it’s not clear this is useful in software threat modeling. There are certainly people for whom “think like an attacker” is an effective part of design analysis. It’s less clear that this is a reproducible process in which people can get training. If you’re going to start from attackers, it’s probably worth using a standard set. It will be helpful to have a small set of these anti-personas written out.

Software Design
Design-driven threat modeling is threat modeling based on where your fences and windows are. You draw diagrams and worry about what can go wrong with each thing in your diagram. (This is the essence of the SDL threat modeling process today because everyone in software knows how to draw diagrams on a whiteboard.) The software equivalents of fences and windows are the various forms of attack surface, such as file parsers or network listening services—sockets, remote procedure call (RPC) services, Web services description language (WSDL) interfaces, or AJAX APIs. They’re the trust boundaries where you should expect an attacker to first get a foothold.

A Quick and Dirty Threat Model
Threat modeling doesn’t have to be a chore. Following the process illustrated in Figure 1, here is the outline of a basic threat modeling process that will get you going quickly and painlessly: Diagram your application, and use this to tell your app’s story in front of the whiteboard (see Figure 2). Use circles for code, boxes for things that exist outside of it (people, servers), and drums for storage. Our team uses funny looking parallel lines for data stores. Draw some trust boundaries using dotted lines to distinguish domains. When you get stuck, apply the STRIDE threat model, described in Figure 3, on each element of your app. All the threats in one place may mean you’re worried about the front door and not worrying about anything else. A third order defense might be an alarm system on the door, and to mitigate the threat of someone cutting the wire, you send a regular message down the wire. If you find yourself worrying about the software equivalent of what happens when someone cuts the phone wire to the alarm system before you worry about locks on the doors, you’re worrying about the wrong things.

File bugs so you can fix what you found threat modeling. Modifying a DLL on disk or DVD, or a packet as it traverses the LAN. Allowing someone to read the Windows source code; publishing a list of customers to a Web site. Crashing Windows or a Web site, sending a packet and absorbing seconds of CPU time, or routing packets into a black hole. Elevation of Privilege Authorization Gain capabilities without proper authorization.

Finally, you need to account for the availability of time and resources both for your threat modeling process and any resulting mitigation and testing.

Microsoft has found that threat modeling works better with a security expert in the room, but there isn’t always one available. You can get decent results by giving people structure and feedback on their work, and by breaking it down into small, easy pieces with rules and self-checks in each one. For problems validating the threat model and your mitigation plan, look to see whether the diagrams represent the code and whether you have agreement between developers and testers on that.

http://msdn.microsoft.com/en-us/magazine/cc700352.aspx

How do you justify spending on something that isn’t designed to increase the bottom line? The fear factor exists, and yet explaining why bulletproof glass is worth more than Plexiglas still requires numbers. With a recession hovering over the United States like some black helicopter, there will be still more pressure to measure what security spending brings to a company.

One big challenge is that the data rarely is simple to pull together. And even though there are now tools like Agiliance, which makes an ROI calculator for information security expenditures, the devil is still in the data.

Here are four well-known metrics and measurement components that, if used properly, can help put the impact of security spending in the financial perspective companies need.

ROI (Return on Investment) It’s a classic business expectation that if you invest money in something, you can measure the return on your investment by its impact on the bottom line. But understanding the value of security spending presents challenges, since the tension that exists in most branches of IT is that investment does not usually lead directly to profits. For security spending, the problem is bigger: If investing in security works, nothing happens.

But what if nothing would have happened anyway?

“[The trouble with] trying to calculate ROI on security tools is that they destroy the proof of their effectiveness simply by doing their job,” says Ross Leo, CEO of Alliance Group Research, a security consultancy. So ROI has become a somewhat loose measure of how long it will take to recoup the cost of investing in security. It is not a perfect measure, which may be why its usage appears to be dropping.

Some 42 percent of organizations polled in the 2007 Computer Security Institute Computer Crime and Security Survey said they used ROI to measure their information security investments. That was up from 39 percent the year before, but well below the 55 percent who reported using it in 2004.

Other common measures: 21 percent of respondents said they used internal rate of return measures, and 19 percent used net present value. ROI can be straightforward for some aspects of physical security. Craig Chambers, CEO of Cernium, which makes software that analyzes videotape, says at a minimum, his firm’s tools mean companies can hire fewer security guards, creating obvious savings on salary and benefits. But it’s rarely so straightforward to calculate savings. Some of the problems with using ROI: Strict adherence to ROI may cause companies to pick the wrong technology to save money. For instance, a firm might find that inexpensive surveillance cameras are not as effective as ones that include built-in analytical tools, but a strict focus on ROI will seem to show a better payback for an inferior product, says Steve Hunt, a security consultant in Evanston, Ill. “ROI is misleading because people don’t understand what they’re trying to accomplish…Look at the benefit you want first, then the ROI,” Hunt says. He doesn’t think ROI numbers work well in security, and he tends to counter with a discussion of their likely losses if they don’t invest in security services. Even though he prefers measuring losses, he concedes that unless a firm has recently experienced a breach of some sort, measuring costs becomes an exercise in “throwing darts at a dartboard.”

Otherwise, it’s tough to quantify the potential around losses, says Anthony Hernandez, managing director of the information risk management practice at Smart business advisory and consulting in Devon, Pa. He notes, for instance, that it was difficult to say what companies would get in return for spending on HIPAA compliance. In the case of PCI, he’s seeing companies receive fines of $25,000 a month. It’s also possible to measure what breaches will cost, thanks in part to incidents like those at TJX, which paid $100 million in fines and another $156 million to resolve lawsuits. It would be harder to say whether TJX suffered any intangible costs, like loss of goodwill (sales actually rose in the wake of the breaches).

Note that there’s also another measure, ROSI (return on security investment), which works by taking the expected security spending and subtracting any expected annual loss (see ALE, Page 39).

TCO (Total Cost of Ownership) An alternative to ROI is to figure the total cost of ownership (TCO) for a security investment. While the purchase cost or ongoing contract costs will be clear, figuring out less-obvious spending is harder. For Tyminski, TCO helped him justify buying a new intrusion prevention system. Bell will measure the time system administrators need to spend with the product, how much time it will take to install or migrate to a software package, what the product itself costs (both up front and for maintenance or support) and how much time its help desk will spend doing hand-holding. Marc Shapiro, senior vice president of Group 4 Securicor, the parent company of Wackenhut, says the firm is seeing more CSOs look for metrics, primarily TCO. Ideally, he likes to contrast those with the potential losses, but even in the physical security world, annualized loss estimates “are difficult to get,” he says.

EVA (Economic Value Added) The best-known version of EVA was developed and trademarked by Stern Stewart and offers a way to measure financial performance for business units. To use an EVA in a practical way, one should take numbers used to generate things like total cost of ownership, ROI and the annualized loss expectancy, and compare them to actual costs, looking at factors like what it would cost to implement and support them.

http://www.csoonline.com/article/394963/Security_and_Business_Financial_Basics