[SecurityRatty] tag: unpredictable

Are Business Risk and Technical Security Part of a Natural Fourier Series?

Wed, 08 Oct 2008 06:25:03 +0000

Decade after decade politics moves from regulated economies to de-regulated economies. Changes are usually are triggered by “unpredictable events” (in political speak). We are almost certainly about to go onto a period of heavy government regulation of the financial services industry where “unpredictable events” or “failure” in plain English is blamed on inadequate of regulation. [...]

This week in history - volcanos, hurricanes, and the risk of Black Swans

Thu, 28 Aug 2008 07:07:47 +0000

Pouring over endless details of risks, regulations, taxonomies, and technologies can sometimes give us a narrow view of the world, so it seems worthwhile to take a minute to mark the 125th anniversary of the cataclysmic eruption of Krakatoa this week. For those of us that want to think big but can’t remember that far back, this week is also the 3rd anniversary of Hurricane Katrina’s devastating sweep across a wide stretch of the US Gulf Coast.

By now, I expect that most of you have read or are familiar with the 2007 book, The Black Swan, by Nassim Nicholas Taleb, which argues that these kinds of unpredictable, outlying occurrences are the ones that really shape businesses, countries, economies, and people. Taleb argues that although these “Black Swan” events are almost completely unforeseeable, we mistakenly try to explain the circumstances at the time and make predictions about similar events in the future.

In my ERM work with clients, and especially in the context of research I’ve been doing with my colleague Stephanie Balaouras on business continuity and resiliency, questions come up about how to plan for catastrophes... and they’re good questions. Were the CardSystems or TJX data breaches foreseeable? What about the Societe General debacle or the 2004 Indian Ocean tsunami? What’s next? Should these types of events be included in our risk assessments?

We’d like to get your opinion on these and other risks that may be on the very edge of the statistical tail. At what point do they belong in your risk register?

Of course, it’s possible to define mitigating controls for crises, disasters, or incidents without knowing for sure what they’re going to look like. That’s one of the hallmarks of a good crisis management plan. And that’s an important point, because trying to predict the next unforeseeable event can be a real challenge sometimes.

ScienceLogics 5-Year Anniversary

Wed, 20 Aug 2008 18:39:16 +0000

August 2003. The largest blackout in U.S. history darkens the Northeast and Midwest, the Blaster worm has been unleashed and Madonna and Britney create a stir at the 2003 MTV Music Video Awards. In the midst of this hot summer madness, ScienceLogic was founded.

To kick off our celebration of our first five years, we asked ScienceLogic founders Dave Link, Richard Chart and Chris Cordray for their thoughts and memories on events leading to today’s milestone. How and why did they set out on this venture? What happened along the way – expected and unexpected? Why were they successful in times when other new (and established) businesses have come and gone?

How did you three put together this team?

We all worked together at a large Managed Service Provider for a couple of years before leaving to start ScienceLogic, so we all knew each other and knew our collective strengths. More importantly, each of us had worked with network management tools on some level (sales and marketing, engineering and product development), and knew first-hand all of the customer pain points, from every perspective. So we left and began rapidly figuring out how to build a better network management solution based upon our real world operational experience..

Dave: One interesting aspect is that our areas of expertise don’t overlap, which has contributed to our success. Chris is excellent with developing the product front-end and interface, Richard handled the backend architecture and engineering and I focused on the technical business side of sales and marketing. Our roles have been to build a product that works well and that provides real value to operations teams that experience the same day to day frustrations that we felt.

Whose idea was it to start the company?

Dave: It was really a collective effort. We were all passionate about “getting it right” and not just starting a company. We knew the industry need and between us, we had the knowledge and skill sets to address all of the right aspects of developing a product and a building a business around it.

What process did you go through to get started?

Richard: From the beginning we knew the type of solution the market needed and we knew that we wanted to build it as an appliance. From different vantage points, we had each experienced the effects of long, difficult and expensive installations that still exist with traditional network tools. Every install has unique variations: there are always different server types, varying hardware and software versions, different patches installed, and on and on. Every installation was time consuming and unpredictable. We knew that an appliance model would address all of these variables and save a lot of time on how quickly customers could achieve immediate value.

The harder decisions were around actually starting the business, assessing the market and of course determining the product pricing.

EM7 completely flips the traditional model of complex, lengthy and expensive deployments. How did you convince others that the EM7 Meta-Appliance product was valid?

Dave: Yes, EM7 totally disrupts the traditional model for network management. While others take a narrow approach, we intentionally designed EM7 to focus on the broad problem – managing the data center. How do you cover a variety of technologies and make sure they work seamlessly together? The vision was to make it easier, not harder, for customers.

Chris: I have to give it to Dave – very early on, he realized the power of a demo. If Dave could get in front of someone, he’d make them a believer. He’d use the Peter Falk/Columbo technique of “let me show you one more thing.” It was very effective. It’s getting easier, but even today people sometimes have to see EM7 in action before they become believers.

Can you describe the early days of running a new business?

Dave: ScienceLogic is a classic case of entrepreneurship. For the first year we worked out of our basements. We kept the costs low in every conceivable way and spent the first year developing the product before we even made a sale.

Chris: We stayed at lots of odd places when we were on the road, took cheap flights with multiple layovers and purchased lots of our first test equipment on eBay. This was during the dot-com bust so there was lots of equipment for sale on eBay, really cheap!

Richard: The amount of equipment I had in my house was absolutely crazy. Back then, servers were huge – I had a Cisco 6509 Catalyst, a Compaq Proliant DL380, Brocade switch, IBM Netfinity 4500R, and tons of other machines.

Chris: I had to install a new circuit box at home because I was blowing breakers. I remember when that 6509 crashed, we revived it and it died again. The second death was final.

So you started in your houses – what was your first office space?

Dave: My friend, the CEO at Ernst & Young Technology had a few extra cubes and a data center in their office that they graciously allowed us to use. Their help was an important step in helping us really formalize the business. We started doing well and adding people, but ironically, their company was downsizing. Before long, many of their original YET people were gone and the ScienceLogic team kept growing in to the open cubes.

Our first leased space was converted warehouse space in Chantilly, VA that once housed an internet radio station. It was cool – it had a large salt water fish tank, a loft, a spiral staircase and a Star Trek door that retracted into the walls with the customary lights and “whooshing” sound.

We outgrew the Chantilly space, leading to our current office in Reston, VA.

Who was the first ScienceLogic customer?

Our first paying customer was Martins Point Health Care. We deployed there in July 2004 and are pleased to say they continue to be a ScienceLogic customer. Other early (and still) EM7 customers include Navy Knowledge Online and the Department of Transportation. Nearly all of our customers are still actively using EM7 and renewing their maintenance.

Where do you see the company in the next 5, 10 or 15 years?

Well, our revenue has doubled year-over-year in each of the last three years, so of course we’d like to continue to grow like that or even faster. In five years we’ve gone from three founders to the point where Dave does not know everyone’s fondest childhood memory. We’ll continue to scale our growth to cover the demands of our growing customer base.

Where do you see the industry going over the coming years?

Chris: IT is always moving and gaining in complexity, so network management is also becoming more complicated. There’s increasing diversity, new standards, virtualization and cloud computing. All of these are today’s technologies. Customers have a mix of the old and the new, so EM7 has to accommodate and support both.

Richard: Each generation of products has a new set of ways to monitor, but the “old” doesn’t go away. Even when a new, hot technology comes along, the old technologies still need to be supported. We work to ensure EM7 keeps up with both.

Dave: After five years we’re just hitting our stride and we’re just now reaching the tipping point in awareness of ScienceLogic and EM7. We’re all still passionate about the product and as Chris and Rich said, there’s still a lot do. We’ll continue disrupting the market with EM7. Our vision hasn’t changed, and with the increasing levels of automation that customers demand, the market needs are greater than ever. Our future is as bright, or brighter, than ever and we’ll continue to be looking for smart ways to automate traditionally manual IT Operations processes.

What’s your advice for someone interested in starting their own business?

Chris: Be passionate. That’s what has gotten me through the tough times. I didn’t really appreciate this thought when I heard others say it before. But it’s very true.

Richard: I agree. We met and talked with lots of people who told us, “That’s been done before.” But we kept going because we truly believed in what we were doing and we knew that while our approach was different, that it would be successful.

Richard: Be fearless. You can’t be too nervous and you need to be able to expect and handle the stress because it will be there. You have to learn to accept the stressful times as a necessary part of the process of starting out on your own.

Dave: Know your niche from the beginning and give potential customers a compelling reason to trust you and really benefit from your solution. You have to know the problem, see the gap and have a clear and consistent vision of how to solve the problem. Then you have to execute. If you don’t build your team with “doers” you won’t make it.

Chris: It helps to have friends. ScienceLogic was built on friendships and relationships, starting with the three of us. If you look at our team, most of our hires are referrals – people who developed and maintained great connections with other great people throughout their careers. Maintain your connections and keep in touch with your network of friends.

Unpredictable IT means unreliable business

Tue, 17 Jun 2008 09:00:00 +0000

HP-sponsored survey finds unchecked changes within IT lead to outages and security breaches that impact the business.

Unpredictable IT means unreliable business, survey says

Mon, 16 Jun 2008 20:00:00 +0000

HP commissioned the Economist Intelligence Unit to survey 1,125 IT professionals from 20 countries about their views on IT risk and how it relates to business risk.

Computers plus people equals risk, tech expert says

Wed, 26 Mar 2008 21:00:00 +0000

Companies are relying too much on technology to run their businesses, a trend that doesn't account for unpredictable situations that humans still deal with better than machines, a technology expert said Thursday.

NGO Security Scenario #21 - The Heat is On

Sun, 02 Mar 2008 15:30:00 +0000

You are a program manager for a forestry project in South America, spending a few weeks in the Western United States observing wildland firefighting operations. You are at a large fire camp. Drought conditions and high winds have caused several fires to increase in size and become unpredictable. Click the play button to see what happens next.

What are the primary threats? How much risk is there? What actions would you take? As the smoke gets thicker, it becomes difficult to breath. Would placing a wet bandanna over your face help? Share your thoughts by clicking on COMMENTS below.

Note: A PowerPoint presentation (in PDF format) by the Incident Commander discussing the event, with lots of photos, is here. Contrast what you see in the video with the description of the actual incident. The U.S. Forest Service, and the wildland fire community in general, do an excellent job of post-incident analysis and making lessons learned widely known. The humanitarian community could learn a lot in developing similar practices for safety and security incidents.

When Too Much Security Means No Security at All

Mon, 24 Dec 2007 09:30:19 +0000

We all know about the law of unintended consequences - the principle that the actions we take can have results that are unpredictable, and sometimes even the exact opposite of what we're hoping to achieve. Media reports out of the United Kingdom this week seem to offer a spectacular example of this principle at work in the world of enterprise security. The details are still emerging, but what's come out so far should be a wake-up call for security and risk professionals everywhere.

Last month, HM Revenue & Customs (HMRC), the U.K.'s tax and excise agency, acknowledged that it had suffered one of the worst data breaches in history (see "Data Loss Could Have Huge Impact on U.K. Banking Industry"). The agency had somehow managed to lose the entire national child benefits database, which contains highly confidential information on a staggering 25 million individuals - literally every household with dependent children in the U.K. The database was stored on two computer disks that were apparently lost while being transported and that still haven't been recovered. The U.K.'s citizens, who are very sensitive about privacy issues, were predictably outraged, parliamentary and regulatory inquiries were launched, and HMRC's chairman was forced to resign. But the agency blamed a single comparatively low-level staffer for causing the breach by downloading the benefits database onto disk. Now it looks like the story was a lot more complicated than that - and HMRC still hasn't learned its lessons from this debacle.

Reports in the U.K. media in the past few days suggest that the downloading was actually ordered by senior officials as part of official HMRC policy. As if that weren't bad enough, HMRC still seems to be working hard - even after the data breach - to make sure that most of its personnel don't even know what the agency's official policy is, much less follow it. It turns out that HMRC has a detailed policy manual governing the handling of confidential information. But in the days after the data breach, HMRC apparently decided that the manual itself was so sensitive that it had to be kept confidential. According to the media reports, only senior staff are allowed physical access to the manual, while lower-level personnel receive only a Web-based briefing that discusses general principles of security and confidentiality.

How are people supposed to follow a policy when they don't know what it is? I'll leave that question to the bright lights at HMRC. Even if they aren't ready to learn the lessons of this data breach, I hope you are. And one of the most important is that well-crafted, well-communicated security policies and policy documents are the bedrock of effective enterprise security. That's why Gartner security analyst Les Stevens recently published a three-part series of Toolkit documents focusing on creating, implementing and communicating an enterprise security framework. You can use these documents to build enterprisewide consensus on security issues, develop appropriate security policies and processes, and - crucially - communicate them to the necessary stakeholders within your enterprise. Take a look. I think you'll be glad you did.

Toolkit Best Practices: Creating a Security Policy Process (Security Policy Guidelines, Part 1)

Toolkit Best Practices: Creating a Security Policy Process (Security Policy Guidelines, Part 2)

Toolkit Best Practices: Creating a Security Policy Process (Security Policy Guidelines, Part 3)

Software Security Metrics and Commentary - Part 2

Tue, 23 Oct 2007 16:31:00 +0000

Part 1 here

In Part-1 of this entry I talked about the first 5 metrics from the paper "A Metrics Framework to Drive Application Security Improvement".

In part-2 of this piece I'll try to cover the remaining 5 metrics as well as discuss a few thoughts on translating survivability/Quality-of-Protection into upstream SDL metrics.

First, onto the other five metrics from the paper:

Injection Flaws

Again, I think the metric posited in the paper is too tilted towards incident discovery rather than prevention. Just like the XSS metric I added - OutputValidation , this is really the key to prevention here. Most static analysis tools can detect tainted input and have a set of untrusted input functions (things that read from sockets, stdin, etc). It should be relatively straightforward to model our own application-specific output functions to detect where we're handing unchecked/unfiltered input to an output routine, potentially those across a trust boundary. If we can model these, we can at least make sure we have good sanitization coverage for each output type. We'll want to have this type of output filtering anyway, we might as well combine metrics from our XSS example.

Improper Error Handling

I think the metric posed in the paper - counting unchecked returns is a pretty good idea. This isn't going to catch web-server layer errors unfortunately, and won't necessarily detect errors in things like app servers, db-layers, etc. We can test for these, but the best metrics might be those related to following secure configuration guidance such as the CIS guide for individual web servers and/or app servers. The CIS benchmark for example requires a compliant configuration to handle standard web errors (4xx and 5xx) through rewrites and/or custom handlers. There are cases (SOAP comes to mind) where we need to throw a 5xx error back to a client, but this is the exception rather than the norm. Configuring application and web servers to minimize this sort of data disclosure is certainly a good thing, and in this sense we can check for compliance at this layer as almost a binary config - you pass the CIS guidance or you don't.

Insecure Storage

I don't think the metric of percent encrypted hard drives is really a meaningful metric in this context. If we look at typical web attacks that fall into this category we'd be looking at exploits that leak things like passwords, CC-data, etc. that is stored in an improper manner on the webserver. Some of this is going to be related to the implementation in the code, and so our best bet is probably a detailed audit of each piece of information that falls into this criticality range to confirm that it is being handled in an appropriate manner. I struggle to find a concrete metric that helps to measure this however. PercentCriticalDataCovered for proper encryption/hashing technique? Still not a very convincing metric unfortunately.

Application Denial of Service

Two metrics spring to mind here:

Memory/Resource Allocations Before Authentication
Memory Leaks

Both of these are a lot more likely to lead to application denial of service than any other errors I can think of. Both of these should be minimized. Tracking them and having the absolute fewest of them is probably a good bet. That doesn't mean we're not going to have a DoS issue, but these are at least 2 places to look.

Insecure Configuration Management

This item probably goes back to the same metrics I posited for Improper Error Handling. Things like the CIS benchmarks for OS, webserver, and appserver are our first pass candidates for measuring this.

On the question of survivability I was struck by a presentation and paper Steve Bellovin did last year about this topic at the first Metricon - "On the Brittleness of Software and the Infeasibility of Security Metrics." He published a paper and a presentation about it.

Steve makes what I believe are two major points in this paper:

Software is brittle, it fails catastrophically
Unlike other engineering disciplines, we don't know how to get to certainty about the strength of a piece of software.

I won't disagree with either of these points, but to an extent you can say this about all new technologies. We've had catastrophic failures in physical engineering before as well. Old materials fail in sometimes new ways, new materials fail in unpredictable ways, and we still rely on sample and testing for analysis of a batch of materials.

The Quality of Protection workshop at the CCS conference is probably the best place to look for research in this area. Previous papers from the workshop can be found here. This years conference and workshop is starting next week, if you're in the DC area and interested in software security metrics it looks like its going to be a good event. The accepted papers list contains a number of papers that I think might shed some light on my speculation above.

I plan to put together a few more thoughts on brittle failure modes of software in a followup to this, I haven't had time to pull all of my thoughts together yet.

Is Risk-Based Security Really Possible?

Thu, 26 Jul 2007 16:42:00 +0000

Yes. Few security professionals doubt that our job is all about risk mitigation. But there tends to be sharp debate about whether you can measure risk. I think you can and should, but quantitative models don't work. I'll come back to "why you should" and "how you can" another time, but for now I want to discuss why the quantitative approach doesn't work.

The classic textbook quantitative risk calculation is Annualized Loss Expectancy:

ALE = (Impact of the event in $$) * (Number of times in a year the event will happen)

So, you calculate your ALE and that's the maximum you should spend to mitigate that risk.

If the real world was that simple, we'd all use ALE to plan our security strategies. But ALE is fundamentally wrong for for information security. I'll concede that ALE can be useful as a simple conceptual model for risk because it requires us to think about both of the factors that generally influence risk: Likelihood and Impact. But literal use of ALE for information security decisions is problematic to say the least.

The problem with ALE is that the numbers we plug into that formula are so baseless that the resulting calculation has no credibility. We probably inherited this simple conceptual model at some point from the insurance industry, which is different from security management in at least two key ways:

They have statistics and actuarial models that predict the likelihood of certain events with reasonable numerical accuracy across a certain demographic - we don't
They have a straightforward way of estimating the loss associated with those events with reasonable numerical accuracy - we don't

Not to mention the fact that insurance and information security are fundamentally different models, but I'll save that tangent for another time.

How does one calculate the financial impact of a security breach? Here's a hint: the amount of money you paid for the server that was just compromised is wrong. There's a whole bunch of things that go into it... the cost of employees and consultants to restore order after the breach, the potential legal liability, the cost of business you may have lost when the system went down, the opportunity cost of things you couldn't do because you had to spend time and resources responding to the incident, and the impact of lost goodwill and reputation damage that you suffer in the market. All of these factors are either immeasurable or unpredictable, which makes them poor candidates for mathematical calculations.

How does one calculate the likelihood of a security breach? The spectrum of threats is too broad and too unpredictable to have any hope of doing this. If you were just hacked by an outsider, or fell victim to a disgruntled employee, or made a simple mistake and exposed a bunch of sensitive information on a website, chances are you never saw it coming, and sure couldn't have sat at your desk six months ago and said "there's a 20% chance that this will happen in the next year".

So, with ALE hopelessly wrong for information security, how can we argue in favor of risk-based security? The answer lies in qualitative models - stay tuned.

Cheers,
Bryan