It’s better to call the segments by their function, e.g. web, app server, db, cache, mq whatever it is that the services in that security group are doing. It had the advantage of being easier to understand, closer to self-documenting and doesn’t imply a level of non-existent security like a term like DMZ does. Also by calling segments by their purpose, it points the security practitioner towards the right mindset of what types of traffic should or shouldn’t be allowed. All in all a very Jericho project kind of mentality.

[ETA: I had completely forgotten that Hoff covered this same issue in his Commode Computing talk last year. In particular see http://pic.twitter.com/wrx7F17R]

Oracle Database Server – 2 patches
Oracle Fusion Middleware – 11 patches
Oracle E-Business Suite – 3 patches
Oracle Supply Chain Products Suite – 1 patch
Oracle PeopleSoft – 6 patches
Oracle JD Edwards – 8 patches
Oracle Sun Products – 17 patches
Oracle Virtualization – 3 patches
Oracle MySQL – 27 patches

Fully 60% of the above patches are from OSS products. So which is more secure: open source or closed source. Or let’s compare Oracle DB vs MySQL: 2 versus 27 patches?

What do these numbers tell you? Absolutely nothing. Even with something like CVSS you still can’t tell which product is more secure. The whole thing is a load of malarkey. The product that is and will remain most secure is the one that you can manage and maintain the easiest for your organization.

In order for continuous deployment (and DevOps in general) to be successful there needs to be consistent process and automation. There are lots of other factors as well, such as qualified developers, proper monitoring, the right deployment tools but those are for another discussion.

Consistent processes are essential if you are to guarantee that the deployment happens the same way every time. To put it bluntly, when it comes to operations and security, variation is evil. Look to Gene Kim’s research (Visual Ops, Visual Ops Security) or more traditional manufacturing methodologies like Six-Sigma for a deep dive into why variation is so very very bad. The short version though is that in manufacturing, variation  means products you can’t sell. In IT, variation means downtime, performance issues, and security issues. At the most basic level, if you are making changes and you are making changes to how you make the changes, you create a much harder situation from which to troubleshoot. This translates to longer incident response times and longer times to recovery which nobody wants. Especially in an online business.

The easiest way to keep deployment process consistent is to remove the human element as much as possible. In other words, automate as much it as possible. This has the added advantage of saving the humans for reviewing errors and identifying potential issues faster. It doesn’t matter which automation mechanism you use as long as it’s stable and supports your operating environment well. Ideally, it will either be the same system as currently being used the by the operations and applications teams (e.g. chef, puppet, cfengine) or be one that can integrated with those systems (e.g. hudson/jenkins).

With good check-in/build release messages, you even get automated logging for your change management systems and updates to your configuration management database (CMDB).

Courage is particularly important, because every decision that a CEO makes is based on incomplete information. In fact, at the time of the decision, the CEO will generally have less than 10% of the information typically present in the ensuing Harvard Business School case study.

Sound familiar? Sounds like my job every single day. Personally, I like to have some data based rationale for how those decisions get made. Don’t you?

[Hat Tip to @aneel]

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.

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.

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.

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.

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.