I started blogging about 2 and half-years ago because I felt like it would be fun to add my two cents to the public debate.  When Brad Feld introduced me to the Feedburner guys I was given an insiders view into the quickly developing blogging world.  When Feedburner started networks, I thought it would be interesting to start a network of all the security blogs that I was reading.  I also inherently knew in my gut that eventually there would be some common good that would benefit all of the members of the network by aggregating our content and buying power for ads. I also believed and still do believe that there are other ways that a network such as the Security Bloggers Network can be a force for good.

However, reading the SBN feed tonight I was just blown away! From being on the road, I had not read the SBN feed in my Newsgator reader for almost 2 days.  I had over 160 articles cued up in the feed.  Forget for a moment that the Security Bloggers Network now has over 160 blogs and a combined feedburner subscriber base of almost 67,000 readers!  The content is king.  Going through the articles I could not believe the total coverage, the ongoing commentary and give and take, but most of all it was the quality.  There are so many great members of the network who are just so damn smart and are writing about such important stuff.

I am humbled and incredibly proud of the what the Security Bloggers Network has become. If you are interested in security, whether it be the technical aspects of security, the business of security or the security industry, you cannot afford to miss this SBN feed. 

We are kicking around a lot of new activities and ways to publicize the member blogs of the network over the coming months.  Stay tuned for details, but in the meantime keep reading, you won't be sorry!

• Report itself [PDF] and brief on it from Verizon (and two fun follow-ups, this and this here)
• "90% of all statistics can be made to say anything… 50% of the time, aka my thoughts on the Verizon report"
• "Data Breach Post Mortem Offers Surprises" (well, to some people, they are surprises ...)
• "Insider Threat Exaggerated, Study Says" (not, it doesn't, BTW)
• "Verizon Business Report Speaks Volumes" (from Richard, thus a MUST read)

And of course, here is my favorite part: "In 82 percent of cases, our investigators noted that the victim possessed the ability to discover the breach had they had they been more diligent in monitoring and analyzing event-related information [AC - i.e. logs] available to them at the time of the incident." and this  "Furthermore, a crime scene devoid of any network and system logs, a key resource for computer forensics, is a disturbingly common occurrence."

What can I say? Back to battle stations for me - to fight the war of making logs more popular! :-)

1. What product(s) & version(s) should I use?
2. How much should I plan to spend?

The simplest answer of course is “it depends”. I’ve seen implementations range from a thousand bucks to over several million. Ideally, your virtualization project needs & goals should drive your product selection. The bells & whistles you chose will determine your spending.

10 Basic questions that will help you determine product & cost:

1. Will your Virtual Infrastructure (VI) host production Virtual Machines (VM)?
2. What servers do you already have that can be used as hosts (32bit, 64bit, Mem, Disk, Network)?
3. Do you have a need for High Availability (HA)?
4. Do you have the need to manage SLA’s on your VMs?
5. What will a typical VM in your VI look like (OS, Disk, Mem, Network, CPU)?
6. What other IT resources do you have that can be used (SAN, NAS, Switches, etc…)?
7. What level of comfort does your existing staff have with the various IT resources?
8. Do you have existing hardware/software support agreements with Vendors you could leverage?
9. What tools do you already own that are “virtualization aware” and what new tools will you need?
10. How many VM’s do you plan to scale to?

Please, please, please, don’t make the mistake of implementing features that you don’t need and over-engineering just because the product lets you do so.

If you plan it right your product & cost, questions will be answered with no unpleasant surprises.

ShareThis

Now the interesting thing to me is that NIST is working with some other players (DNI comes to mind) on reference implementations of 800-53A.  This is big, so big that I can’t add enough hyperbole to it.

Why do they need to do reference implementations?  Well, because by itself, SP 800-53A is dangerous if it’s given to people who “don’t get it”.  By that what I mean is this:

• SP 800-53 needs tailoring to distill into actual requirements.
• SP 800-53A needs a huge amount of tailoring to distill into test cases/procedures that match the tailoring that you did with 800-53.
• Taken at face value, 800-53 and 800-53A become the source of “death by compliance”.
• If you think the auditors could grill you to death with 800-53, 800-53A gives them tons more material.

Now time for a war story: I worked on a project where the contractor was having a hard time building a security program, mostly because they didn’t have the right staff to get the job done.  The government told the contractor to use 800-53A as a starting point, and 6 months of insanity followed with 13 “security engineers” in a conference room cranking out documentation that had no basis in reality.  At the end of it all, the contractor handed the Government a bill for $1M.

Now don’t get me wrong, I like the ideas behind 800-53A, but the first thing you need to know when you start using it is when you shouldn’t use it:

• Don’t run test procedures on every computer you have, use an automated tool and do spot-checks to validate that the automated tool works.
• Use less test procedures on low-criticality systems.
• “This procedure is conducted as part of the hardening validation process.”
• Common controls are even more important because you do not want the repetition of effort.

And whatever you do, don’t let 800-53A turn your risk management into a compliance activity.  It has all the potential to do that.

US Government Doc’s photo by Manchester Library.

Bookmark to:

From Snort.org:

We’re pleased to introduce our first beta release built on the new Snort 3.0 architecture. The Snort 3.0 architecture consists of two primary components: a software platform called the Snort Security Platform (SnortSP) 3.0, which is shipping in beta form in this release, and traffic analysis engine modules that plug into SnortSP. This beta test release contains one engine module which contains the Snort 2.8.2 detection engine implemented as a SnortSP engine module. SnortSP is an open-source platform for running packet-based network security applications. It provides many of the common functions required by programs that deal with packet processing such as configuration loading, event generation and traffic logging, data acquisition, protocol decoding and validation, flow management, and more.

They provide you an opportunity to provide feedback on the beta release as well “sspneta SHIFT 2 sourcefire D0T com”.

Downloading my copy now.

Article Link