The latest Microsoft patch MS08-68 is a great example. It is a problem with NTLM authentication where the attacker can force a client to authenticate to him and the credentials, while not exposed in cleartext, can be relayed to another server or brute forced to obtain the cleartext. This is a very classic crypto protocol vulnerability. It’s not the crypto algorithms that are the problem, but the protocol implementation.

Microsoft recently fixed the problem, perhaps due to the availability of exploit code, the availability of an easy to use Metasploit implementation, or perhaps Microsoft’s changed tolerance for vulnerabilities. We can sum it up as a change in the threat space that made it worth fixing. But make no mistake, this is a very old problem.

News reports have been citing Sir Dystic’s SMBrelay tool, which was published in March, 2001, as the first knowledge of this vulnerability. Eric Shultze who worked at MSRC in 2001 just yesterday is quoted as saying, “I have been holding my breath since 2001 for this patch.” Obviously it is a long time coming. But this wasn’t the first publication of the problem. In 2000, one of my collegues on the research team at @stake, Christian Rioux (aka Dildog) published the telnet NTLM authentication vulnerability.

Rioux’s advisory has a great description of the credential relay and cracking weaknesses. I have talked to him and he says he discovered these problems independently, but he didn’t find them first. Dominique Brezinski published exactly these NTLM vulnerabilities in the SMB protocol in 1996 in a paper titled, “A Weakness in CIFS Authentication”. The earliest reference I can find on the paper on the net is here where it is included in another paper published in 1997. Such is the ad-hoc world of independent security research of 12 years ago which still continues today.

It seems ridiculous that a field like security research, which is so important to the running of modern society is so ad-hoc. Shouldn’t we know who discovered a vulnerability? Shouldn’t all researchers and engineers know about it? More importantly if someone implements a tool that takes advantage of a vulnerability shouldn’t they credit the discoverer? Don’t get me wrong. Implementation takes a lot of work and sometimes makes all the difference in makeing people aware of a security problem. After all when I was at the L0pht our slogan was, “Making the theoretical, practical”. I still think researchers should get credit when credit is due.

The security community has gotten better at documentating our research but I still see instances of independent discovery, misplaced credit, and tools giving no credit to researchers. I hate to say it but getting a bit more academic is in order. Credit is the currency of a researcher and placing it well will reward the right people and we will all benefit.

Richard Stallman - the man that gave us GNU - doesn’t trust Cloud providers with his data and says you shouldn’t either.  Richard believes we should store our private data on our own computers using ‘free’ (as in freedom) software.  The ironic part for Richard is that a significant portion of the Cloud is powered by open source software which he indirectly created (think gcc).

Richard sees it as a question of control.  Control is important but it isn’t the only variable.  Rather, I see it as a question of control, competence and economics.

The quick rebuttal to Richards’ view is this: the average computer user is not as smart as you.  Control is not the same as competence.  Control is about exercising choice, not about requiring everyone in the world to develop sufficient skills to protect complex hardware and software systems (aka their computer) against ever increasing threats.

My view is that privacy is not ‘free’.  It comes at a cost.  Whether you run your own systems or rely on someone else to do it, there is a cost.  There is cost in designing and implementing mechanisms to support privacy.  Beyond upfront costs there are ongoing expenditures to ensure privacy is maintained e.g. maintaining access control lists, testing and applying security patches, data leakage prevention etc.  None of these things are ‘free’.

If we agree that privacy costs money then how much is your privacy worth?

Stop for a second - think of a number…  

Now did we all think of the same number?

The problem with a one size fits all approach to privacy is that we each place a different value on it.

Checking in on the EPIC site, I saw this:  

A new report from Pew Internet and American Life Project indicates that “cloud computing” applications, such as web-based email and other web apps, are raising new privacy concerns. The report Use of Cloud Computing: Applications and Services found that 69% of online Americans use webmail services, store data online, or use software programs such as word processing applications whose functionality is located on the web. At the same time, “users report high levels of concern when presented with scenarios in which companies may put their data to uses of which they may not be aware.” For example, 90% of respondents said that they “would be very concerned if the company at which their data were stored sold it to another party,” 80% say “they would be very concerned if companies used their photos or other data in marketing campaigns,” and 68% of “users of at least one of the six cloud applications say they would be very concerned if companies who provided these services analyzed their information and then displayed ads to them based on their actions.”

What does that tell us?

The average (American) Internet user finds Cloud services convenient but has concerns about how their privacy might be affected by Cloud providers actions (duh!).  The survey identifies a lack of awareness in how private data is used in some consumer based Cloud services (consistent with web advertising awareness surveys).  

Unfortunately, the results of this survey are not very actionable.  The survey doesn’t mention whether these are all ‘free’ Cloud services (we can only assume they are) or ask the respondents what their expectations of privacy are and how much they would be willing to pay for different privacy assurance levels. 

On a sidenote, respondents were not asked if they had actually read the privacy agreement for the services they signed up to.  But the providers know if they did or not…  Or at least, they have the data to figure it out.  At sign up time they can measure the time between displaying the privacy agreement and the user clicking ‘I accept’.  If its just a few seconds then its pretty obvious there was more scrolling than reading going on.  But I think we can probably guess the answer without the data ;-).

I believe we need to be able to link expectation of privacy with cost.

• How much are you willing to pay for privacy?  What level of privacy assurance do you need?
• How much is your Cloud Provider paying to protect your privacy today?  What privacy services could they reasonably offer if they had customers willing to pay?  How might this compare with how you manage your private data on your home computer today?

The cynical view is that we expect privacy but don’t want to pay for it.  Its a bit like uptime - there is a parallel universe out there, where internal IT departments allegedly meet their 99.999% uptime SLAs, but when Gmail goes down, the Sergey Brin witchcraft dolls come out.

From a provider perspective, the “cost” of privacy invariably gets bundled under that line item called ‘Information Security’.  And don’t be fooled, the cost of privacy in reality is more than the salary of the person employed to be the privacy advocate (if there is one).  If we can’t see how much our providers are spending on our privacy then how can we judge if they are spending enough?  And what is enough?  And what can I get if I’m willing to pay a little extra?

Personally, I would rather we get some transparency around privacy costs and assessment of offerings.  However, without a sufficiently sized market of customers willing to pay for privacy assurance and Cloud Providers willing to be more open, I won’t hold my breath.

What about you?  Would you be prepared to pay for privacy?  Should providers be more transparent about what they do and don’t do and how they do it?
 
 

When a data owner's (a business) sensitive data is breached it is difficult to quantify the monetary loss. According to respectable survey sources, the average cost of sensitive data breach for a large size company is about $50,000. I am attempting here to think about this in simple mathametical terms:

There is a data breach. From the data owner's perspective the loss is:

Loss = Cost to protect data + Loss of business due to data theft aka cost of competitive disadvantage

From the data thief's perspective

Net Gain= [Cost of producing the data  *  Data freshness factor] - Cost to steal the data + Profit of business due to data aka gain of competitive advantage

From the above two equations it is very clear that this is not a zero sum game. There is a clear cost asymmetry for a data owner and for a data thief. When there is an asymmetry there is an opportunity. Data owner would not even know that the data is lost because the original copy of the data may be still intact - data thief could have simply copied the data. Data theft does not look like a car theft, there is no vacuum left behind. 

This motivates a data thief to keep the cost to steal low, steal highly valuable data that has a long shelf life and in a way that data owner will never even be aware of theft.

From a data thief's perspective, the cost to steal data if kept high would disincentive him. Moreover, Data freshness factor, i.e. how valuable this data is over period of time plays an important role. A good example is content of today's newspaper is hardly valuable tomorrow, but the content of newspaper two days ahead (if can be procured)would be invaluable. Data relevance is a function of time and other marketplace variables -  Data freshness Factor accounts for that variable. A good way to discourage data thief is to increase his/her cost to steal the data. There are other inferences from the above equation. If there exists no competitive advantage with the stolen data, hardly any thief would even venture to steal the data in the first place. If the cost of producing data is very low, then probably thief can just produce the data himself and would not attempt to steal the data. If the cost of theft is kept high, it would definitely deter the data thief from stealing data using technical mechanisms, then the data thief would exploit weak links in data security such as use of social engineering to get access to the data.

From data owner perspective protecting data becomes very important. How much would the owner be willing to spend? Not definitely the cost equal to cost of producing the data. 1% to 10% of cost of producing data is considered prudent. For a data owner it is difficult to estimate cost of data protection of a specific data, because it is not easy to chunkify data protection costs. Moreover, as Dan Geer says in his book, a data owner has to protect himself from number of intruders not just one.

It pays for a data owner to: be aware of data breaches (or data leaks), employ appropriate mechanisms to protect the data; the cost of protection which is fractional cost of the valuable data and enhance information security awareness of personnel who handle the data.

Data loss is not a zero sum game. The advantage is in favor of a data thief (data thieves rather). Data owner does not give much thought on the value of data unless there is a data theft. But, a data thief has every reason to think about economics of data theft before he acts to steal the data else data thief won't survive in this game and he is very well aware of his advantageous position.

“Complex Event Processing (CEP) is a technology which has been used for many years in the Aerospace and Defence Industry for Situational Awareness and Data Fusion modules in Command, Control, Communications, Computing and Intelligence Systems (aka C4I).

Currently CEP is being rediscovered as a foundation for new class of extremely effective Business Intelligence, Security and System/Network/SCADA Monitoring solutions in industries like Financial Services, Telecommunications, Oil and Gas, Manufacturing, Logistics etc. The increasing connectivity and processing power of the modern IT and Telecom technologies lead to increasing speed and volume of the dataflow available to the organisations. By using CEP solutions companies can gain competitive advantage by achieving real-time situational awareness and tapping the information value that is hidden within the streams of real-time event data that are coming from a variety of sources such as enterprise applications, financial transactions, sensor networks and supply chains.”

Unfortunately, the author does not cite references in the paper.

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)

1. Our brilliant field engineer Dimitri McKay talks about the eternal topic of converting Windows event logs to syslog. Yes, Eric, we ALL know it is ugly, but that is the only way that actually works well across all systems ...
2. More on Windows and syslog: "Syslog ... 20 Years Later."  BTW, this is really not about syslog, but about Vista/2k8 finally getting an ability to natively centralize the event logs via event subscriptions ("It's only about twenty years behind schedule, if you're counting.")
3. Two fun pieces on correlation: 1 and 2. What often kills "a log correlation project"? "Whoever had worked on it had not had much time available to learn the way to properly configure the software" (from this)  and "correlation only really works when backed up by real data about what is the biggest problem in your environment, and how that problem manifests itself in the event logs." (from this) None of this is new, but a useful reminder nonetheless
4. Fun LogLogic podcast is here. The topic of this high-level discussion (CEO) is related to operational use for logs. I did one with them too; on logs and virtualization (will be up soon)
5. A couple of good posts on logging from Nemertes Research: "Sharpening Stones and Walking on Coals",  "Search or Destroy"
6. Reminder about a few useful Windows Vista and 2k8 events: 4802 (screensaver engaged) and 4803 (screensaver dismissed)
7. One person is wondering about the usefulness of logging after "experiencing" Linux auditd logging (kernel audit): "Logs are like a warm blanket; verbose logging means you can know what's happening on your systems if you keep up with the logs.  At the same time, logs become a burden very very easily, and they are easy to ignore." This post is a must read for us logging afficionados; producing too much log data is a sure way to make people hate you...
8. This also follows the same theme: people doubting the god-like power of logs :-) "So for an administrator to not care about logs was a shock." But would I argue that "log management is NOT a pain?" Now, would I? :-)
9. A classic about logging for application developers: "Building Secure Applications: Consistent Logging."  I am noticing a lot more discussions about logging in a developer community, e.g. see this and this (the latter, BTW, contains a lot of info on "why log" for developers). Overall, "getting logging right" is important (and will get more important in the future) and people need something NOW and cannot wait for the standards.  BTW, I am planning a mini-crusade on how to train application developers to include useful logging in their applications...
10. Finally, the "Is SIEM dead?" theme is continued in this fun post "Life after SIEM. Situational Awareness is next." Indeed, context is key for logs. BTW, if somebody mentions that I have "vendor bias", I will kick your ass! :-)

Enjoy!

Photo Credit: www.heelys.com

Since the Ninja has such a hypnotizing voice, we decided to leave this one as a podcast: ScienceLogic Q&A with the Splunk Ninja