The short one: "A Look at Terrorist Behavior: How They Prepare, Where They Strike," by Brent Smith, National Institute of Justice Journal, No. 260, 2008.

The long one: How Terrorist Groups End: Lessons for Countering al Qa'ida, by Seth G. Jones and Martin C. Libicki, RAND Corporation, 2008.

Warnings About Financial Institutions and Derivatives

Risks of Financial Institutions
The nature of a financial institution is that there are a lot of ways to go to hell in a bucket. You can push credit too far, do a dumb acquisition, leverage yourself excessively---its not just derivatives [that can bring about your downfall].

Maybe it's unique to us, but we're quite sensitive to financial risks. Financial institutions make us nervous when they're trying to do well.

We're exceptionally goosey of leveraged financial institutions. If they start talking about how good their risk management is, it makes us nervous.

We fret way earlier than other people. We've left a lot of money on the table through early fretting. It's the way we are -- you'll just have to live with it.

Derivatives
The system is almost insanely irresponsible. and what people think are fixes aren't realy fixes. It's so complicated I can't do it justice here - but you can't believe the trillions of dollars involved. You can't believe the complexity. You can't believe how difficult it is to do the accounting. You can't believe how big the incentives are to have wishful thinking about values and wishful thinking about ability to clear.

People don't think about the consequences of the consequences. People start by trying to hedge against interest rate changes, which is very difficult and complicated. Then, the hedges make the [reported profits] lumpy. So they use the new derivatives to smooth this. Well, now you've morphed into lying. This turns into a Mad Hatter's Tea Party. This happens to vast, sophisticated corporations.

Somebody has to step in and say, "We're not going to do it - it's just too hard."

I think a good litmus test of the mental and moral quality at any large institutions [with significant derivative exposure] would be to ask them, "Do you really understand your derivatives book?" Anyone who says yes is either crazy or lying.

It's easy to see [the dangers] when you talk about [what happened with] the energy derivatives - they went kerflooey. When [the companies] reached for the assets that were on their books, the money wasn't there. When it comes to financial assets, we haven't had any such denouement and the accountings hasn't changed so the denouement is ahead of us.

Derivatives are full of clauses that say if one party's credit gets downgraded then it has to put up collateral. It's like margin - you can go broke [just putting up more margin]. In an attempt to protect themselves, they've introduced instability. Nobody seems to recognize what a disaster of a system they've created. It's a demented system. 

In engineering people have a big margin of safety. But in the financial world, people don't give a damn about safety. They let it balloon and balloon and balloon. It's aided by false accounting. I'm more pessimistic about this than Warren is.

Accounting for Derivatives
I hate with a passion GAAP [Generally Accepted Accounting Principles] as applied to derivatives and swaps. JP Morgan sold out to this type of accounting to front-end revenues. I think it's a disgrace.

It's bonkers, and the accountants sold out. Everyone caved, adopted loose [accounting] standards, and created exotic derivatives linked to theoretical models. As a result, all kinds of earnings, blessed by accountants, are not really being earned. When you reach for the money, it melts away. It was never there.

It [accounting for derivatives] is just disgusting. It is a sewer, and if I'm right, there will be hell to pay in due course. All of you will have to prepare to deal with a blowup of derivative books.

Likelihood of a Derivatives Blowup
We tried to sell Gen Re's derivatives operations and couldn't, so we started liquidating it. We had to take big markdowns. I would confidently predict that most of the derivatives books of [this country's] major banks cannot be liquidated for anything like what they're carried on the books at. When the denouement will happen and how severe it will be, I don't know. But I fear the consequences could be fearsome. I think there are major problems, worse than in the energy field, and look at the destruction there.

I'll be amazed if we don't have some kind of significant [derivatives-related] blowup in the next five to ten years.

I think we're he only big corporation in America to be running off its derivative book.

It's a crazy idea for people who are already rich -  like Berkshire - to be in this business. It's a crazy business for big banks to be in.

Yo would be disgusted if you had a fair mind and spent a month really delving into a big derivative operation. You would think it was Lewis Carroll. You would think it was the Mad Hatter's Tea Party. And the false precision of these people is just unbelievable. They make the worst economics professors look like gods. Moreover, there is depravity augmenting the folly. Read the book F.I.A.S.C.O., by law professor and former derivative trader Frank Partnoy, an insider account of the depravity of derivative trading at one of the biggest and best-regarded Wall Street firms. This book will turn your stomach.

"Risk management" is just a fancy term for the cost-benefit tradeoff associated with any security decision. It's what we do when we react to fear, or try to make ourselves feel secure. It's the fight-or-flight reflex that evolved in primitive fish and remains in all vertebrates. It's instinctual, intuitive and fundamental to life, and one of the brain's primary functions.

Some have hypothesized that humans have a "risk thermostat" that tries to maintain some optimal risk level. It explains why we drive our motorcycles faster when we wear a helmet, or are more likely to take up smoking during wartime. It's our natural risk management in action.

The problem is our brains are intuitively suited to the sorts of risk management decisions endemic to living in small family groups in the East African highlands in 100,000 BC, and not to living in the New York City of 2008. We make

systematic risk management mistakes -- miscalculating the probability of rare events, reacting more to stories than data, responding to the feeling of security rather than reality, and making decisions based on irrelevant context. And that risk cockpit of ours? It's not nearly as finely tuned as we might like it to be.

Like a rabbit that responds to an oncoming car with its default predator avoidance behavior -- dart left, dart right, dart left, and at the last moment jump -- instead of just getting out of the way, our Stone Age intuition doesn't serve us well in a modern technological society. So when we in the security industry use the term "risk management," we don't want you to do it by trusting your gut. We want you to do risk management consciously and intelligently, to analyze the tradeoff and make the best decision.

This means balancing the costs and benefits of any security decision -- buying and installing a new technology, implementing a new procedure or forgoing a common precaution. It means allocating a security budget to mitigate different risks by different amounts. It means buying insurance to transfer some risks to others. It's what businesses do, all the time, about everything. IT security has its own risk management decisions, based on the threats and the technologies.

There's never just one risk, of course, and bad risk management decisions often carry an underlying tradeoff. Terrorism policy in the U.S. is based more on politics than actual security risk, but the politicians who make these decisions are concerned about the risks of not being re-elected.

Many corporate security decisions are made to mitigate the risk of lawsuits rather than address the risk of any actual security breach. And individuals make risk management decisions that consider not only the risks to the corporation, but the risks to their departments' budgets, and to their careers.

You can't completely remove emotion from risk management decisions, but the best way to keep risk management focused on the data is to formalize the methodology. That's what companies that manage risk for a living -- insurance companies, financial trading firms and arbitrageurs -- try to do. They try to replace intuition with models, and hunches with mathematics.

The problem in the security world is we often lack the data to do risk management well. Technological risks are complicated and subtle. We don't know how well our network security will keep the bad guys out, and we don't know the cost to the company if we don't keep them out. And the risks change all the time, making the calculations even harder. But this doesn't mean we shouldn't try.

You can't avoid risk management; it's fundamental to business just as to life. The question is whether you're going to try to use data or whether you're going to just react based on emotions, hunches and anecdotes.

This essay appeared as the first half of a point-counterpoint with Marcus Ranum in Information Security magazine.

In any case, if you do pentests, think about all the RECENT cases where you break in to a major corporation through:

• a Solaris system with Internet-exposed telnet with a guessable password OR a telnet vulnerability (circa 1994!)
• an exposed VPN appliance with a manufacturer's administrator password
• a router with default "enable" password
• or, something else entirely - but something that rivals the above example in its unparalleled, unbelievable, abysmal, deep idiocy.

Indeed, many of my pentesting friends still report plenty of such cases (one was also featured in the presentation mentioned above). Whenever I hear about it from a pentester, I always ask:

Do you think "somebody bad" had already passed through the hole you just discovered?

Maybe an hour ago, a day ago - or a year ago?!

I cannot see how the answer can be "no."

Even though pentesters usually don't focus on forensics (no time for this), it is not uncommon to notice "your predecessor's" intrusion traces while you break through systems, "plant flags", change screen backgrounds [for the admins to notice that you've been there...], etc.

Let's think what this situation really means? Here are the choices I see:

1. Nobody discovered the hole - a law of large  numbers (aka "dumb luck") have "shielded" the company from an incident. Yes, Virginia, dumb luck IS a security strategy for some companies... AND it works for them.
2. It was discovered, but not used/abused by the attacker - maybe he was busy hacking other systems, or saved this for later and never came back due to his ADD. Congratulation, you win! The immense power of dumb luck wrapped you in a protective "security" blanket ... again :-)
3. It was discovered; the attacker went in, looked around and compromised a few others systems, but found nothing of interest (no low hanging fruits)  - and he was not a bot herder. Again, you win. Next time you are in Vegas, bet on "00."
4. It was discovered; the attacker went in and deployed a bot on "your" system - given how many botnets are there, this situation is clearly acceptable to many organizations. In this case, dumb luck strategy, apparently, still work: so they use your box to spam and phish somebody else ... big deal!
5. It was discovered; the attacker went in and stole all your credit card information (it is now for sale) - even in this case, the user of "the dumb luck strategy" still "wins" (in some perverse sense)! Unless and until the stolen information IS tracked back to you OR a friendly neighborhood PCI auditor come and jams a broomstick up your ..., you can still continue to be stupid at your leisure and ignore basic security practices.
6. It was discovered; the attacker went in and stole your CEO's Inbox, including the email related to his affair (it is now on CNN) - now, in this case, you lose AND it is time to stop being stupid! Welcome to the "0wned world." Time to launch (relaunch?) your security program and get serious.

What does this teach us about RISK? The lesson here is important:

• For a security professional, an Internet-exposed system with "root/root" is an obvious HUGE risk!
• For your boss's boss's boss, it is NOT!

This is exactly why I think that the most critical problem in security today is METRICS. Metrics that a) work AND mean something to decision makers and b) can be clearly communicated to said decision makers [BTW, a) and b) are two separate problems.] Metrics that cover not only threats and vulnerabilities we face, but also the effectiveness of security countermeasures we deploy. Metrics you can act on - and ones your boss (and his boss) will act on. Metrics that lead to correct decisions about which risks to accept, which to  mitigate (all while knowing with what efficiency such mitigation occurs) and which to transfer.

Until that time, the dreaded "C-word" (compliance) will trump "the other C-word" (common sense) as a driver for security ... and we will continue to live in the "0wned world."

Possibly related posts:

• Risk vs Risk 

Defining Cloud Computing

Cloud computing is a very active community. The Google Group gets 600 posts per month and many bloggers are covering the space. However, “cloud computing” is impossible to define in a way that satisfies everyone (or even most). Cloud computing is not alone in this controversy, consider the definition and meaning of “Web 2.0″, “mashups” or “RESTful architecture”. All of these terms are relatively recent. According to Google Trends, these terms became popular to the general public sometime between 2005 and 2007:

• Web 2.0 - often confused with RIA, AKA Social Computing, Long-Tail Apps, Crowdware (2005 by O’Reilly Media)
• Mashup - made popular by Google Maps, AKA Composite/Situational Apps. (2005)
• REST - Has a strict definition, but many don’t understand it and abuse the term. (2006 by R. Fielding)
• Cloud computing - collides with many other terms, such as SaaS, Grid, Utility, PaaS, etc. (2007)

The definition of cloud computing is in progress:

There’s a Darwinian evolution of the exact definition of cloud computing running around. We’re about a country mile away from “knowing when I see it”, which is excellent progress. The cloud to everyone’s silver-lining has enough material to write a 3 volume desktop reference at this point. - Michael Cote, June 2008

Definition #1 - “Cloud computing is the realisation of Internet (”Cloud”) based development and use of computer technology (”Computing”) delivered by an ecosystem of providers. - Sam Johnston, July 2008

Definition #2 - “Cloud computing = network computing. I love the idea of cloud computing, the next evolution of the most network intensive architecture possible, but one that if it works well, is transparent. It’s all about the transparency.” - Douglas Gourlay, Cisco, May 2008

Definition #3 - “There seems to be a group myopia around so-called “cloud computing” and its definitions. What we’re really talking about are “cloud services” of which, “computing” is only a subset…Cloud services are not SaaS. They are far more akin to web services…” - Randy Bias, neoTactics, May 2008

(Anti-)Definition #4 - “Note that I refer to cloud services, not to the could. I am not interested in defining cloud as a term, because I don’t think it’s very useful. For those of us in the distributed computing’s pace

The Working Definition (Winner!):

“…the notion of providing easily accessible compute and storage resources on a pay-as-you-go, on-demand basis, from a virtually infinite infrastructure managed by someone else. As a customer, you don’t know where the resources are, and for the most part, you don’t care. What’s really important is the capability to access your application anywhere, move it freely and easily, and inexpensively add resources for instant scalability.” - Mitchell Crandell, Rightscale, June 2008

Taxonomies of the Cloud Space

Taxonomies are useful to provide insight into a market. It classifies a multitude of players into a smaller bucket.

Andreessen’s Platforms - September 2007

Provided an early taxonomy model for emerging cloud platforms

Platform being a system that can be programmed

• Access API - platform that provides web service endpoints
• Plug-In API - platform invokes your code, that you have deployed remotely
• Runtime Environment - your code runs inside the platform’s process space.

Mehta 11 Layer Stack, April 2008

1. Facilities (space, power, cooling)
2. Network
3. Hardware (e.g. servers Amazon EC2 runs)
4. Hardware virtualization (e.g. Xen for EC2) - optional
5. O/S (e.g. Linux)
6. Systems Management (e.g., tools to manage EC2 instances)
7. Application Middleware (e.g., MySQL on EC2)
8. Application Code
9. Application APIs / Web Services
10. GUI for Application
11. GUI for Application Development / Customization

Croll Cloud Stack, June 2008

7 layer stack within Turnkey app and Generic Platform.

Turnkey app

• SaaS
• Extensible app
• Generic IDE
• Constrained APIs
• App Cluster
• Virtual Data Center
• Virtual Servers

Generic Platform

The bottom of Alistair’s stack includes “root access “style compute clouds.

Robert Anderson, July 2008

3 layer stack

• Software (SaaS)
• Platform (PaaS)
• Infrastructure (IaaS)

This is the model taxonomy for this session.

Related Concepts and Terms

• Infrastructure as a Service (IaaS), Hardware as a Service (HaaS) are synonyms to cloud infrastructure.
• Virtualization
• Hosting
• Autonomic computing
• Distributed computing
• Grid computing

Cloud Applications

• SaaS
• S+S (Software+Services)
• Managed Service Provider (MSP)