Author Archive for David Mortman

Data Not Assertions

There have already been a ton of posts out there about the Verizon DBIR Supplement that came out yesterday, so I’m not going to dive into the details, but I wanted to highlight this quick discussion from twitter yesterday that really sums of the value of the supplement and similar reports:

georgevhulme: I’m glad we have data to refute the “insiders conduct 80% of all attacks” mantra that has been repeated, ad nauseum for at least a decade

adamshostack: @alexhutton @georgevhulme yeah, but… Data, not assertions

This is so awesome, I can barely stand it. We’re actually starting to be able to make data based decisions as opposed to just asserting something is true because we believe it on faith or like the way it sounds.

“Data, not assertions” really sums up so much of what I was trying to get at in the the discussion on securosis last week about password changing time frames. Read the comments over there. It really shows how far we have yet to go.

Chris Soghoian’s Surveillance Metrics

I also posted about this on Emergent Chaos, but since our readership doesn’t fully overlap, I’m commenting on it here as well.

Chis Soghoian, has just posted some of his new research into government electronic surveillance here in the US. The numbers are truly astounding (Sprint for instance provided geo-location data on customers eight million times in thirteen months).

There’s lots of great data on what’s being collected versus what’s being reported as collected. I know you’ll all be shocked to know that surveillance is dramatically under reported. It’s all very very interesting. Check it out.

Less Is More

Great post today over on SecureThinking about a customer who used a very limited signature set for their IDS.

Truth of the matter was that our customer knew exactly what he was doing. He only wanted to see a handful of signatures that were generic and could indicate that “something” was amiss that REALLY needed to be looked at. Not that something was a quasi attack or could be successful if only that OS was running this configuration of application X — just the nuts and bolts fundamentals of good ‘ole fashion network monitoring. His SNORT’s ran fast, faster than any other IDS of the same hardware investment, because pattern matching was reduced to a handful of rules.

I’m a huge fan of this sort of setup and something that I’ve promoted within the companies I’ve worked with. Why bother looking for something you know you aren’t vulnerable to either because you’ve patched it, configured around it or don’t have that issue at all? Furthermore, if you have signatures installed that you don’t care about, you are just creating noise that is hiding the stuff you really care about.

This does assume that you have a certain level of maturity and actually have the asset, patch and configuration management issues more or less under control. If you don’t, then this like many other problems remain intractable.

If you have a disciplined mature organization, you can largely, if not completely (depends on how complex your company is) move to only uses signatures to tell you when something out of the ordinary is going on and it doesn’t take a complex piece of software, such as Cisco Mars or Maltego to warn you. Instead, you configure just signatures for things like too many of certain classes of events coming from a certain machine:

Error 404: A client has requested something from my webserver that it does not have, or does not have at the location some client was looking for. When a high number of distinct web servers report 404 to a single client host, that host is not up to any good.

Or use of IP space you should never see on your internal network:

DARKNET: There was some IP traffic (ICMP/TCP/UDP doesn’t matter) from an RFC1918 (private) host that we didn’t allocate, or just don’t know about. This is the equivalent of the Police “running” a license plate, and the response coming back “not in system.” How many police would consider that a routine false positive and let the driver go without further questioning?

Alternately, you can look for events such as machines serving up DHCP who shouldn’t be or the sudden appearance of web servers on subnets that didn’t have them in the past.

I like to call this sort of configuration, “Signature Based Anomaly Detection.” It’s not fancy and it’s not complex, but it will tell you when something weird is going on. It may turn out to be a security issue, a misconfigured machine or someone violating change control, but regardless, it’s a great way to actually make your IDS useful and not just something you have to do because an auditor says you have to.

“80 Percent of Cyber Attacks Preventable”

Threatlevel (aka 27B/6) reported yesterday that Richard Schaeffer, the NSA’s information assurance director testified to the Senate Senate Judiciary Subcommittee on Terrorism, Technology and Homeland Security on the issue of computer based attacks.

If network administrators simply instituted proper configuration policies and conducted good network monitoring, about 80 percent of commonly known cyber attacks could be prevented, a Senate committee heard Tuesday.

The remark was made by Richard Schaeffer, the NSA’s information assurance director, who added that simply adhering to already known best practices would sufficiently raise the security bar so that attackers would have to take more risks to breach a network, “thereby raising [their] risk of detection.”

I’m really curious however on what data Director Schaeffer is basing his testimony on. Is it the DBIR? Another open set of breach data or is it based on data gathered by the NSA? Regardless, it’s great to see more folks talking about what the Verizon DBIR report told us and what we’ve known anecdotally for a long time; which is, we still aren’t even close to doing the basics well.

The article then goes on to tell us:

A 2009 Price Waterhouse Cooper study on global information security found that 47 percent of companies are reducing or deferring their information security budgets, despite the growing dangers of cyber incursions.

The thing is, as we’ve learned from the Verizon study, most of the found issues were due to failing at doing the basics, like not removing default passwords, not revoking accounts when employees leave and misconfigurations. Even in the case of patching, the vast majority of holes exploited had patches available for over a year and 100% had patches available for over 6 months. This is not the stuff of big budgets and sexy technology, but rather about having solid, repeatable and auditable processes, in other words, serious operational discipline. Budget cuts might actually be a good thing because it will force organizations to focus on the people and process portions of security rather then the technology. It’d be really cool to if PWC were to track correlation of budgets to breaches within their survey groups, then we’d have some actual data on potential optimal spend levels.

Quick Thought: Scenario Planning

I spent yesterday in a workshop learning about and practicing scenario planning. It’s a really great tool for planning for (as opposed to predicting) the future. It feels like it’s a great addition to the risk assessment/management process. Check it out.

Mini Metricon 4.5 Call For Participation

Mini MetriCon 4.5 will be a one-day event, Monday, March 1, 2010, in San Francisco, California. Through the cooperation of RSA, the workshop will be held at the University of San Francisco, within walking distance of the Moscone Center, the location of the RSA Conference, to be held during the same week. Mini MetriCon attendees are eligible for free RSA exhibit passes.

Like its predecessors, Mini Metricon 4.5 is an informal workshop designed to facilitate exchange of new ideas as well as practical experience in using metrics to drive better security, compliance, and risk management. The day will be divided between open/moderated exchange and short presentations. Participants are expected to come prepared to actively interact as either presenters or active listeners (or both).

Place: University of San Francisco (within walking distance of the Moscone Center)

Time: 8:30am to 4:30pm

Participation: by invitation.

Attendance: Limited to 80 people

If you would like to participate

Due to space limitations, we are asking all who are interested in participating to send an email to metr…@securitymetrics.org

Please provide some information about who you are, your interest/experience with metrics, what metrics you can bring to discuss, and your preferred level of participation: presenter or active audience participant.

Presenters: Please provide an abstract of 5 paragraphs or less that describes the nature of the metrics and metric results that you would like to present. Following past MetriCon practice, preference will be given to those who respond to this CfP with actual work in progress that demonstrates the value of security metrics with respect to a security-related goal.

Submission of recent, previously published work as well as simultaneous submissions to multiple venues is acceptable if disclosed in your proposal.

Active audience participants: Please indicate your area(s) of specific interest.

Examples of past well-received presentations are:

§ Intel Presentation

§ Verizon Presentation

§ Whitehat Presentation

Visit http://www.securitymetrics.org for digests, presentations, and handouts from past Metricon Workshops.

Notification

To get invitations out well beforehand, we’d like all email submissions to be in-hand by December 5. Our goal is to send invitations to participate by January 15.

Important Dates

– 05 Dec 2009 – Responses Due to this Call

– 15 Jan 2010 – Notification of Acceptance

– 01 Mar 2010 – Mini MetriCon 4.5 Workshop

Program Committee

§ Warren Axelrod, Financial Services Technology Consortium

§ Jennifer Bayuk, Bayuk.com

§ Fred Cohen, Fred Cohen and Associates

§ Lloyd Elam, SigmaRisks

§ Jeremy Epstein, SRI International

§ Dan Geer, In-Q-Tel

§ Renee Guttmann, Time Warner

§ Ray Kaplan, Ray Kaplan & Associates

§ Pete Lindstrom, Spire Security

§ Joe Magee, Vigilant

§ Elizabeth Nichols, Plexlogic

§ Steven Piliero, Center for Internet Security

§ Chris Walsh [Program Committee Chair], SurePayroll

§ Caroline Wong, eBay

Please feel free to contact the Program Chair with any questions. Inquiries beyond administrative matters will be forwarded to the Committee.

Additional information will be posted at www.securitymetrics.org as it becomes available.

You’ve Got To Move It Move It

Josh Corman had an awesome post over on Fudsec on Friday. It’s so awesomely appropriate to this blog, that I’m sharing it with you. My only complaint is that I wish that I had written instead. Go read it right now.

Botnet Research

Rob Lemos has a new article up on the MIT Technology Review, about some researchers from UC Santa Barbara who spent several months studying the Mebroot Botnet. They found some fascinating stuff and I’m looking forward to reading the paper when it’s finally published. While the vast majority of infected machines were Windows based (64% XP, 23% Vista), 6.4% were running either OS X Tiger or Leopard, demonstrating yet again that just because you have a Mac doesn’t mean you are safe. More interesting to me was:

The researchers also discovered that nearly 70 percent of those redirected by Mebroot–as classified by Internet address–were vulnerable to one of almost 40 vulnerabilities regularly used by the most popular infection toolkits designed to compromise computer systems. About half that number were vulnerable to the six specific vulnerabilities used by the Mebroot toolkit.

The research suggests that users need to update more often, says UCSB’s Vigna.

Unfortunately, until the paper comes out we won’t know which vulnerabilities were being used and how old they are. Hopefully, that will be explained further as it would be really interesting to see how this data compares with what Verizon found in their research.

Meta-Data?

So awhile back, I posted the following to twitter:

Thought of the Day: We don’t need to share raw data if we can share meta-data generated using uniform analytical methodologies.

Adam, disagreed:

@mortman You can’t test & refine models without raw data, & you can’t ask people with the same orientation to bring diverse perspectives.

We went back and forth a bit until it became clear that this needed an actual blog post, so here it is:

I don’t disagree with Adam that we need raw data. He’s absolutely right that without it, you can’t test models. What I was trying to get at was that, even though I would absolutely love to have access to more raw data to test my own theories, it just isn’t realistic to expect that sort of access in the legal and business environment we have today. So until things change, we have to figure out another way to get at the data.

One thing that has become increasingly popular is for vendors to publish aggregate data about what they’ve seen with their customers or on their networks. Verizon and WhiteHat have used this model to great effect. Not only has it generated a lot of press for them, but we as an industry have learned a lot from these reports.

What would be even better is if people would share the models they are using when generating their data. This way, other organizations could use the models and as reports were published, the rest of us could actually compare apples to apples. This would also allow us to more quickly identify issues/errors in the models, allow for public discussion of necessary tweaks and then test said changes while limiting liability for the data owners.

This is really where I was going with my initial thought above; that we need common models so we can have an intelligent discussion. This is also how things generally work in the sciences (yes, Alex, I know, we’re not a science yet :) . Researchers almost never publish their raw data, but just their models, methods and results. I feel strongly that until we can convince people to share raw data more openly, this is our best shot to figuring real information about what’s going on in the security world. It’s also what drove me to start developing the soon to be renamed Mortman/Hutton Model that Alex and I presented at Blackhat and BSides Las Vegas.

More data, even if it’s aggregate, is better then no data.

Metrics: 50% Chance of Injury by Biscuit

Crumbs: half of Britons injured by their buscuits on coffee break, survey reveals

The Telegraph reports:

More than half of all Britons have been injured by biscuits ranging from scalding from hot tea or coffee while dunking or breaking a tooth eating during a morning tea break, a survey has revealed.

Who knew that cookies could be so dangerous? So forget worrying about AV or even seat belts, skip the carbs….

[Image from the original article]