TaoSecurity Blog

Thief Retrieves Cash, from Bloomberg Businessweek The February 2nd issue of Bloomberg Businessweek featured a story titled Boom: Inside a British Bank-Bombing Spree . The article describes how "five men, dressed all in black" used "crowbars, power tools, coils of flexible tubing, and two large tanks of explosive gas" to blow apart ATMs in the UK, then retrieve cash inside. The story opens by describing a raid that netted "almost £250,000, or about $375,000" and was the group’s biggest score in a single night yet. Their MO, using cheap, common, and legal gas, was nearly impossible to trace, and they left precious little forensic evidence for the police. To stop the rampage, there was little Britain’s banks could do. What is the history of this sort of attack? The article states: Bank security experts think the first ATM gas attack may have been in Italy in 2001. Early statistics are shaky, but by 2005 there were almost 200 across the continent...

It's 2007 and some people still do not know the difference between a threat and a vulnerability. I know these are just the sorts of posts that make me all sorts of new friends, but nothing I say will change their minds anyway. To wit, Threat Modeling Again, Threat Modeling Rules of Thumb : As you go about filling in the threat model threat list, it’s important to consider the consequences of entering threats and mitigations. While it can be easy to find threats, it is important to realize that all threats have real-world consequences for the development team. At the end of the day, this process is about ensuring that our customer’s machines aren’t compromised. When we’re deciding which threats need mitigation, we concentrate our efforts on those where the attacker can cause real damage. When we’re threat modeling, we should ensure that we’ve identified as many of the potential threats as possible (even if you think they’re trivial). At a minimum, the threats we list that we chos...

I'd hoped to not have to say anything else on FAIR, but I've decided to ask one final question. If I can't get a straight answer to this question I'm giving up on the discussion. So, here it is. In Thoughts on FAIR I walked through the section Analyzing a Simple Scenario . Steps 3, 4, 5, 8, and 9 [Estimate the probable Threat Event Frequency (TEF), Estimate the Threat Capability (TCap), Estimate Control strength (CS), Estimate worst-case loss, and Estimate probable loss, respectively] each require the user to "Estimate." Do these Estimates matter to the output of the model? If the answer is yes, then those answers are important and should be grounded in reality -- not opinions. If FAIR proponents agree with this, then we have been debating for days for no real reason. That would make me happy. If the answer is no, then what is so magical about FAIR that garbage in does not produce garbage out?

I've subscribed to the Economist for over ten years, and it's been worth every penny. Today I noticed the following in an article called The Long and Short of It : The second paper suggests that traders face “Knightian uncertainty”, or risks that cannot be measured. Hmm, what is this "Knightian uncertainty"? I found the following excerpt from Risk, Uncertainty and Expected Utility : Much has been made of Frank H. Knight's (1921: p.20, Ch.7) famous distinction between "risk" and "uncertainty". In Knight's interpretation, "risk" refers to situations where the decision-maker can assign mathematical probabilities to the randomness which he is faced with. In contrast, Knight's "uncertainty" refers to situations when this randomness "cannot" be expressed in terms of specific mathematical probabilities. As John Maynard Keynes was later to express it: "By `uncertain' knowledge, let me explain, I do...

I intended to stay quiet on risk models for a while, but I read the following Economist articles and wanted to note them here for future reference. From "Statistics and climatology: Gambling on tomorrow": Climate models have lots of parameters that are represented by numbers... The particular range of values chosen for a parameter is an example of a Bayesian prior assumption, since it is derived from actual experience of how the climate behaves — and may thus be modified in the light of experience. But the way you pick the individual values to plug into the model can cause trouble ... Climate models have hundreds of parameters that might somehow be related in this sort of way. To be sure you are seeing valid results rather than artefacts of the models, you need to take account of all the ways that can happen. That logistical nightmare is only now being addressed, and its practical consequences have yet to be worked out. But because of their philosophical training in the rigo...

My post Thoughts on FAIR has attracted some attention, but as often the case some readers choose to obscure my point by overlaying their own assumptions. In this post I will try to explain my problems with FAIR in as simplistic a manner as possible. Imagine if someone proposed the following model for assessing force: F=ma (Yes, this is Newton's Second Law , and yes, I am using words like "model" and "assess" to reflect the risk assessment modeling problem.) I could see two problems with using this model to assess force. Reality check : The model does not reflect reality. In other words, an accurate measurement of mass times an accurate measurement of acceleration does not result in an accurate measurement of force. Input check : To accurately measure force, the values for m and a must not be arbitrary. Otherwise, the value for F is arbitrary. With respect to FAIR, I make the following judgments. Reality check : The jury is out on whether FAIR reflects reali...

You knew I had risk on my mind given my recent post Economist on the Peril of Models . The fact is I just flew to Chicago to teach my last Network Security Operations class, so I took some time to read the Risk Management Insight white paper An Introduction to Factor Analysis of Information Risk (FAIR) . I needed to respond to Risk Assessment Is Not Guesswork , so I figured reading the whole FAIR document was a good start. I said in Brothers in Risk that I liked RMI's attempts to bring standardized terms to the profession, so I hope they approach this post with an open mind. I have some macro issues with FAIR as well as some micro issues. Let me start with the macro issue by asking you a question: Does breaking down a large problem into small problems, the solutions to which rely upon making guesses, result in solving the large problem more accurately? If you answer yes, you will like FAIR. If you answer no, you will not like FAIR. FAIR defines risk as Risk - the probable f...

Gunnar Peterson pointed me to a great blog post he wrote called Protect the Transaction . He quotes Dave Kilcullen's post Two Schools of Classical CounterInsurgency , which discusses the difference between “enemy-centric” and “population-centric” counter-insurgency operations. I consider two responses to these posts. First, when monitoring, you can take a threat-centric or an asset-centric approach to monitoring insider threats. This is especially true when monitoring inside an organization. As I teach in my Network Security Operations class, threat-centric monitoring places sensors closer to the suspected intruders (rogue sys admins, curious call center workers, etc.) while asset-centric monitoring places sensors closer to valuable resources (source code repositories, payroll servers, etc.) Sometimes you can follow both approaches, but that usually ends up in a "monitor everywhere" style that can be cost- and operationally-prohibitive. Keep in mind that defenses a...

The image at left is from the first issue of an Intel marketing magazine called Premier IT . I like it because it shows many of the terms I try to describe in this blog, in relationship to each other. In English, the graphic says something like the following: Threats exploit vulnerabilities , thereby exposing assets to a loss of confidentiality/integrity/availability , causing business impact . I disagree that business impact is mitigated by controls . I think those terms were connected to make a pretty cyclical diagram. I would also say that controls mitigate attacks (exploits) by threats, not the threats themselves. Imprisonment mitigates threats. The next diagram shows Intel emphasizes Policy at the base, followed by Training and Education , then Technology and Testing , and finally Monitoring and Enforcement . I think the Training and Education piece is marginally effective at best, at least for the general user population. It's tough enough for security pros to ...

I write about risk, threat, and other security definitions fairly regularly. Lo and behold I just read a post by someone else who shares my approach. This is a must read . How did you react to the story? A second brother in risk is Gunnar Peterson , who writes in part: When security teams conflate threats and vulnerabilities, the result is confusion. Instead efforts dealing with threats... and vulnerabilities... should be separately optimized, besides both being part of "security"; they don't have that much in common. Oh bravo, especially the old school link to Dan Geer which I should read again.

Donn Parker published an excellent article in the latest issue of The ISSA Journal titled Making the Case for Replacing Risk-Based Security . This article carried a curious disclaimer I had not seen in other articles: This article contains the opinions of the author, which are not necessarily the opinions of the ISSA or the ISSA Journal. I knew immediately I needed to read this article. It starts with a wonderful observation: What are we doing wrong? Is the lack of support for adequate security linked to our risk-based approach to security? Why can't we make a successful case to management to increase the support for information security to meet the needs? Part of the answer is that management deals with risk every day, and it is too easy for them to accept security risk rather than reducing it by increasing security that is inconvenient and interferes with business. I would argue that management decides to "accept security risk" because they cannot envisage the conse...

If you've been following the last few days of posts, I've been thinking about security from a more general level. I've been wondering how we can mitigate risks in a digital world where the following features are appearing in nearly every digital device. Think about digital devices in your possession and see if you agree with this characterization of their development. Digital devices are increasingly: Autonomous: This means they act on their own, often without user confirmation. They are self-updating (downloading patches, firmware) and self-configuring (think zeroconf in IPv6). Users could potentially alter this behavior, but probably not without breaking functionality. Powerful: A cell phone is becoming as robust as a laptop. Almost any platform will be able to offer a shell to those who can solicit it . There is no way to prevent this development -- and would we really want to? Ubiquitous: Embedded devices are everywhere. You cannot buy a car without one. I ex...

This evening I watched a story on BBC News about the problem of bird flu . Here is the story broken down in proper risk assessment language. Two assets are at risk: human health and bird health. We'll concentrate on birds in this analysis. Healthy birds are the asset we wish to protect. The threat is wild migratory birds infected by bird flu. The threat uses an exploit , namely bird flu itself. The vulnerability possessed by the asset and exploited by the threat is lack of immunity to bird flu. A countermeasure to reduce the asset's exposure to the threat is keeping protected birds indoors, away from their wild counterparts. The risk is infection of domesticated birds by wild birds. All infected birds must be killed. The TV story I watched contained this quote by reported Tom Heap: "The lesson learned from foot-and-mouth [disease, which ravaged Europe several years ago] is to do your best to keep the disease out , but assume that will fail . Be ready to tackle an...

I found the article Corporates focus on basics for IT security defences by John Leyden to be interesting. He reports on a survey presented by Gartner at their recent IT Security Summit. Gartner's survey found that IT staff ranked threats as follows: 1. Viruses and Worms 2. Outside Hacking or Cracking 3. Identity Theft and Phishing 4. Spyware 5. Denial of Service 6. Spam 7. Wireless and Mobile Device Viruses 8. Insider Threats 9. Zero Day Threats 10. Social Engineering 11. Cyber-Terrorism I am disappointed to see social engineering ranked so low. I am glad cyber-terrorism is dead last. I am surprised to see outside hacking ranked so high, even though I agree it should be a top three priority. Here is the list I would create (if I had to call these "threats;" many of these are not "threats." I rank these "problems" or issues using a mixture of likelihood and damage inflicted. I do not agree with all the categories ...