One More Time on SIEM vs Log Management

Since people keep asking me again and again, here is another post on the subject.

40,000 ft view:

SIEM = SECURITY information and event management; the emphasis is on SECURITY. Security information is not just logs.

while

LM = LOG management; the emphasis is on LOGS. Logs aren’t just for security.

10,000 ft view:

(with slight risk of oversimplification)

Functionality	Security Information and Event Management (SIEM)	Log Management (LM)
Log collection	Collect security relevant logs + context data	Collect all logs
Log pre-processing	Parsing, normalization, categorization, enrichment	Indexing, parsing or none
Log retention	Retail parsed and normalized data	Retain raw log data
Reporting	Security focused reporting	Broad use reporting
Analysis	Correlation, threat scoring, event prioritization	Full text analysis, tagging
Alerting and notification	Advanced security focused reporting	Simple alerting on all logs
Other features	Incident management, analyst workflow, context analysis, etc	High scalability of collection and storage

1000 ft view:

Read this paper – then ask me questions if it is not clear.

 

Finally, people, please STOP obsessing on “SIM vs SEM.” The 1990s are officially over [darn, even 2000s are over!] SIEM is what exists today – that and log management.

Possibly related posts:

• On Choosing SIEM
• The Myth of SIEM as "An Analyst-in-the-box" or How NOT to Pick a SIEM-II?
• Log Management / SIEM Users: "Minimalist" vs "Analyst"
• "I Want to Buy Correlation" or How NOT to Pick a SIEM?

Source Boston 2010 Conference Notes

Here is my delayed account of the awesomeness of Source Boston 2010. Did I mention the event was awesome? Yup, it was indeed. Awesome.
So, here is Source 2010 conference day by day.
Day 1 started from Andy Purdy keynote which was ..shall we say… “not bad.” Since keynotes at security conferences usually suck (with a few notable exceptions), “not bad” is actually a pretty good rating. For example, he complained about how many meetings in DC are about “the need for data sharing” and then called for more data sharing himself :-) Ooops!
The next very fun thing was a start-up panel – with two parts, one with startup entrepreneurs (including Loggly) and the second with VCs. It is quite hard to summarize since the discussion floated from subject to subject – watch the video when it comes out. "Secure cloud enablement"  was mentioned as something they would fund while “mobile security” produced a passionate “forget it.” Better endpoint protection  was also mentioned as “AV is in crisis.” Other hot – fundable? - topics mentioned were "data-focused security", cloud (surprise!), next wave of privacy for consumer (an actual surprise for me), “secure data anywhere,” etc.
I asked a question about SMBs: will VCs favor a security solution that is aimed at enterprises over the one for SMBs? They did say that while "SMBs are harder to reach”, “’SMB security’ is largely a green field.” They also said that “SMB game” is more business model innovation than technology innovation and the winner is determined by "who owns the channel" and who does more "creative selling"  rather than by who is more “hard core” technically.
At one point in the panel, Josh tossed his favorite curveball about PCI DSS and “compliance culture.” The esteemed VC panel members were actually negative on PCI. The panelists tried to blame PCI for “PCI as a ceiling” mindset by saying that many organizations “achieve PCI” and then not do any more security which results in “false sense of security.” They only praised PCI for raising awareness of information security. My guess is that VCs would like people to buy shiny new toys and PCI DSS prescribes the use of “boring,” but effective “old toys” aka security basics. PCI’s focus on the basics is definitely abhorred by a lot of “discretionary purchase” security vendors as well.
The end of the day was a mentor panel. I somehow thought that more people would show up there, even if just to watch @SecBarbie perform :-). The topics discussed were related to security career development, certifications, written goals, finding mentors in security, building your personal brand, the importance of hands-on work, etc. I wish Source will somehow make this mentorship idea permanent and ongoing…

UPDATE: I don't know how, but I missed Andrew's "Failagain's Island - The Perils of Banking in an Island Nation" talk which was fun as well - even though it suffered from a lack of details. In any case, it makes sense to be on the lookout for some island banks 0wnage...

During Day 2, I loved Alex Stamos presentation on cloud security architecture, “Securely Moving Your Business into the Cloud.” I will just not do it justice by retelling it here, try to get the slides or even the video if/when they get posted. He spoke about how cloud deployment makes flat architecture superior to a traditional on-prem 3-tier arch both in terms of security and performance, for example.
Obviously, “Too Many Cooks Spoil The Broth: How Compliance Regulations Get Made” compliance panel was impressive as well. And the huge-but-cute face hanging over the entire audience made me even more skeptical about ISO ever producing a vulnerability disclosure standard :-)
Max Kilger from the Honeynet Project did an awesome presentation called “Motivations and Objectives That Are Shaping Emerging and Future Information Security Threats.” On top of a few gems like “Russia steals our money, China steals our future” and “First time in history a single individual can affect the entire country” [by using Internet for attacks], the presentation was insightful since it connected the technical world of attacks with the cultural profiles of the attackers. More highlights of his talk are here.
Finally, our PCI presentation (slides) and subsequent PCI book signing went really well. We did get praise for  managing to “make PCI compliance … fun” which totally made my day :-)
Among other highlight of the day, I like Rich’s “Involuntary Case Studies in Data Breaches” (even though I missed a piece of it). As it is typical for Rich, he was very insightful – and again reminded everybody that incident response if the only thing that you can ever hope to “get right” (likely, you’d screw both prevention and detection – but please don’t screw the response!).
On Day 3, somehow I had high hopes for a keynote by Sam Currey, but it was again “not bad.” A lot of his stuff was about well-known facts packaged together in an interesting way, and I liked the bit about how regulations evolve and more than few others. Skim the video when it comes out, it is worth it.
The biggest disappointment was that Amit Yoran “Security Sucks” speech was cancelled. I cannot believe he “got volcanoed” while flying from DC to Boston :-)
Among the usually great hallway conversations, there was one curious discussion about the PCI assessment level of diligence. Is the diligence of a routine QSA assessment any different from the  “replacement QSA” assessment after a massive breach (e.g. was Heartland first QSA less diligent than the second?)? This debate had to do with “no breached company was compliant during the breach” [so far], which I find reasonable and most people find offensive [since they equate this with retroactive PCI pulling…which it is not!]
The usual “security con rumor central” produced such gems as “after you travel to China with your mobile device, company X mandates that you toss the device into a nice bucket of cold water” and “no less than 10% of all iPhone apps are 0wned.”  Rumors come …rumors go.
Grab the conference slides here (more are being added as we speak). Grab ours (Branden’s and mine) here.
For live coverage, as usual, check hashtag #sourceboston. BTW, other accounts of the event can be found here and here.
BTW, I have started highlighting the key points to make this blog even more useful for even busier people. Let me know if you like it or not!
Possibly related posts:

• All posts on conferences
• RSA 2010 - Day 2-3
• ShmooCon 2010 - Our PCI DSS Panel

On Choosing SIEM

Everybody knows how to figure out whether you need a Security Information and Event Management tool (SIEM) and also how to pick the right SIEM product for your organization. Extremely smart people with years of experience in the field spent years dealing with that exact problem (example). However, it sure seems like the right way – requirement-driven and use-case driven – is also the least popular way of picking and justifying SIEM deployments. Folks just want to do it wrong and make themselves suffer in the process while wasting money, generating annoyance and sparking intense hatred of SIEM vendors.

Great!

If doing it right  is not a popular option since many organizations are hell-bent on doing it wrong, let’s try to determine “What is the least wrong way which will actually get used in real-life?”

First, let me refer to my classic deck on SIEM and log management “worst practices.” The first two practices are related to choosing a SIEM product and are shown below:

•WP1: Skip need determination step altogether – just buy something

–“My boss said that we need a correlation engine” (more about this mistake)

–“I know this guy who sells log management tools …”

•WP2: Define the need for SIEM in general

–“We need, you know, ‘do SIEM’ and stuff” :-)

These situations are actually quite common and most unquestionably wrong; and many a SIEM project has been slaughtered as a result.

BTW, what partially inspired this post was a  lot of Google queries for “which siem system is right for security in my company?” that landed on my blog. Think about this! Folks think that Google actually knows what SIEM is best for their organizations :-) An additional inspiration was provided by a discussion I had with a colleague who said that many SIEM purchases also had a hidden “opportunity cost.” Namely, the money spent on a SIEM were thus not spent on something that could have contributed a lot more to risk reduction at this particular organizations. The final inspiration came from all the “MARS tossing” that is going on now; the organizations who acquired a SIEM product a few years ago and never managed to apply it to anything useful are now on the market for – you guessed it! – a new SIEM. These same folks then google for “SIEM justification” since they literally cannot say why they wasted $280,000 of perfectly good dollars…

In any case, what IS the least wrong way? How about this flow (drastic oversimplification alert!):

1. Do you really need a SIEM? Or do you want a SIEM? Figure this one out please….
2. If you need a SIEM to solve a particular problem, what would it cost (time, staff time, money) to solve it with SIEM and without SIEM? Which is cheaper, better, faster?
3. What problems won’t you solve due to engaging in a multi-month SIEM project? Is this acceptable?
4. Next, will a simpler – and cheaper!-  log management tool do the trick?
5. Are existing SIEM solutions actually capable to solving that problem you have? At a cost you can afford to pay?
6. Will existing SIEM solutions work in your organizations: politically, culturally, geographically, etc?
7. Are you prepared to WORK (yes, w-o-r-k!) to make SIEM solve your problem? What exactly is your expectation, SOC-in-a-box, perchance?
8. How about open source SIEM combined with other tools and integration services?
9. Only here you can start planning the deployment, phased approach, log source integrations, correlation rules, dashboards, etc.

(we can call it an “almost right” approach)

And by all means, study vendor stuff on “how to choose a SIEM?” [some of it will in fact be written by the same party as this post :-)], but don’t take it as gospel. The above list should get you going at least.

Here are some example of “SIEM gone wild” from recent experience.

In one case, a company called a consultant and said that they needed assistance with SIEM implementation. He asks: do you have business requirements defined? No. Do you have a product selected? No. But you want to implement already? Yes. <painful pause>

In another case, a company picked a SIEM that was [supposedly] the easiest to deploy. While undoubtfully an important criteria, wouldn’t an enlightened reader of my blog agree that this requirement comes a close SECOND right after the “Will it solve my security problem?!!!” This particular organization just focused on ease of deployment… and FAIL didn’t have to wait too long :-)

BTW, lately I’ve been puzzled about the whole concept of “co-managed SIEM” (subject of one of the future blog posts). I think it is gaining popularity (example) for that very reason mentioned in this post: folks don’t want to figure that stuff out, the want the crack team of mercenaries to parachute in, deploy and operationalize a SIEM for them – and then continue running it for some time…or forever. I was told that sometimes it is cheaper than signing up for an MSSP – and you retain more control while learning from the experts on how to do it.  But more on this in the future post.

Finally, just have to mention it: I am available for SIEM and log management consulting projects.

Possibly related posts:

• Log Management + SIEM = ?
• The Myth of SIEM as "An Analyst-in-the-box" or How NOT to Pick a SIEM-II?
• On SIEM Complexity
• SIEM Bloggables
• Log Management / SIEM Users: "Minimalist" vs "Analyst"
• Short Observation on Open Source SIEM
• All posts labeled SIEM

Two Upcoming Speaking Ops

Just FYI, in the next couple of days I am doing two fun speaking ops.
Namely:

1. Source Boston conference: Branden and me will present on “PCI DSS Done RIGHT and WRONG” (it will be even more fun than PCI Myths, promise!) on Thursday.
2. Focus.com webcast: don’t ask :-), but I will be doing a webcast titled “Zero Day Response: Strategies for the Newest Innovation in Corporate Defense”, primarily focusing on tips to management for improving response to security issues. It will be fairly high-level, so “listener beware.”

BTW, I am posting this after landing here in Boston. If you are around, show up at Source (location) and we can chat.

UPDATE: Focus.com webcast is recorded here

IANS 3/25 Log Webcast Q&A

As you remember, I’ve done this webcast/IPC with IANS called “Navigating the Data Stream without Boiling the Ocean: Case Studies in Effective Log Management.” My role as IANS faculty was to moderate the discussion.

My intro slides can be found here. A recording can be found somewhere here – grab it since we had a great panel discussion with a bunch of useful and juicy bits about log management in the real world. Below I am answering some of the fun questions we got at the show for a broader audience of this blog – and sorry for a delay with that.

Q: What, if anything, has anyone done to overcome privacy restrictions in some countries like Germany, France, Italy regarding log collection activity of users?

A: Sorry, but I have to give you a cynical answer. From what I am hearing, those countries are making a choice in favor of - what they think of as – “privacy” over security monitoring and activity auditing. As a result, many of the logging and log review tasks legality is becoming questionable or the burden of performing such tasks grows exponentially. The only advice I can give is to follow the law - even if you screw yourself and your organization in the process. Under democracy, you're supposed to act towards changing the law and not simply ignoring it.

 

Q: Can you describe your process for determining what to periodically review from your logs?  Did a committee comprised of sysadmin and information security team identify what to review?

A: Ideally, such process should and include all stakeholders, namely, people who can benefit from the information in log files. This would certainly include system administrators and a security team. However, it is not uncommon that the security team will do it on its own if other parties show no interest in participating. Regarding the process itself, the key approach to doing is “use cases.“ What do regulations say about logging and log review? What business units ask for, if anything? What level of details you'd prefer to have during incident response? What are the things I trying to accomplish? Look for future blog posts about this subject.

 

Q: Would you use log management without a SIEM?

A: Absolutely. I would not use a SIEM without log management though; I would also try not to use a SIEM without a good log management tool. For more info on this subject read this, this, this.

 

Q: Does using a complete SIEM solution reduce the number of staff required?

A: Hard to say what is meant by ”complete” here, but the answer is either “no” or “it depends.”

Overall, I do not like this type of positioning at all: if you are trying to purchase a SIEM solution in order to fire your security analysts, you'll fail miserably. On the other hand, if you'd like to reduce the number of people whose jobs consist of only reading logs every day, then SIEM can help reduce that staffing need so that you can allocate people to more productive security monitoring tasks. Still, the main value of a SIEM tool lies in the skilled personnel that operates it! For example, see this one.

 

Q: What is your definition of structured and un-structured data [mentioned in the discussion]?

A: Structured data is more like a database table, it has named fields such as “username”, “source IP”, etc. Name=value pairs is another example of log data with structure. On the other hand, plain English text is not structured [at least, not for our purposes of log analysis] and needs to be either structured (“parsed”, tokenized, etc) or directly analyzed using text mining tools.

 

Q: How visualization tools technically help in log review?

A: See http://secviz.org for more information on the subject than you ever wanted to learn :-) While you're in the subject, get a great book about it.

 

Q:  What level from the log management maturity curve [A.C. - reference to this graph] does HIPAA compliance require?

A: Based on the fact that HIPAA prescribes logging (164.312(b) Audit Controls) and some monitoring for specific events, such as logins (164.308(a)(5)(ii)(C)    Log-in Monitoring), I’d venture a guess that HIPAA compliance will require an organization to have a fairly mature log management and security monitoring operation. And is this reality? No, many healthcare organizations are nowhere near that stage with their logging.

 

Also, see awesome coverage of this webcast from Rocky DeStefano is here at his VisibleRisk blog.

Enjoy!

Possibly related posts:

• Fun Logging Webcasts: 4/1/2010 and 5/12/2010
• Open Group Log Webcast Slidea and Q&A: "Enterprise Logging and Log Management: Hot Topics"
• Thursday 3/25 IANS Webcast + Panel on Log Management: "Awesome++"
• Log Management / SIEM Users: "Minimalist" vs "Analyst"
• The Myth of SIEM as "An Analyst-in-the-box" or How NOT to Pick a SIEM-II?
• Log Management + SIEM = ?
• SIEM Bloggables talks about SIEM use cases.

Two New Logging Resources Published

Two new resources about logging, log management and SIEM , written by myself, have just been published.

“The Complete Guide to Log and Event Management” (a lofty title, I know) was written for Novell Sentinel team (this doc is behind the sign-up form, but it is totally worth it :-)) BTW, if you mistakenly wrote off Sentinel from the SIEM battlefield, you are sadly mistaken!

Quote:

“What happens after an organization deploys a log management tool and starts using it effectively for security and compliance as well as operational purposes? The natural and logical progression is for organizations to graduate to near-real-time event management by deploying a SIEM tool.

This paper is the first document that formulates “graduation criteria” for such development. Organizations that graduate too soon will waste time and effort, and won't any increased efficiency in their security operation. However, waiting too long also means that the organization will never develop the necessary capabilities to secure themselves.

[…]

One of the paramount conclusions from this work it to remember that everybody has logs and that means that everybody ultimately needs log management. In its broadest form, log management simply means “dealing with logs.” And if you have logs you have to deal with them – if only because many recent regulatory mandates prescribe that.

It's also important to remember that logs are used for a very large number of situations: from traditional (incident response) to highly esoteric. Most of such uses of logs happen much later, after the event happens and is recorded in logs. It is much easier to be prepared to respond then to monitor.

Your organization might need to go “back to logging school” before it is ready to “graduate to SIEM.” Such graduation requires an ability to respond to alerts and customize and tune products.”

“PCI Logging HOWTO” (part 1)  was written for Prism Microsystems, the home of 100 Uses for Log Management.

Quote:

“To satisfy those requirements, it is recommended that an organization create “PCI System Log Review Procedures” and related workflows that cover:

• Log review practices, patterns and tasks
• Exception investigation and analysis
• Validation of these procedures and management reporting.

[…]

First, do determine the scope for PCI compliance, including systems, databases that store the data, application that process the data, network equipment that transmits unencrypted card data as well as any system which is not separated from the above by the firewall. In the case of so-called “flat network”, the entire IT environment is in scope and thus must be made compliant by implementing DSS controls.

Second, identify system components that touch the data: apart from the operating systems (Windows or Linux, for example) databases and web servers need to considered as well as payment application, middleware, Point-of-Sale (PoS) devices, etc.

Next, a logging policy must be created. PCI-derived logging policy should at least cover logged event types for each application and system deployed as well as details for all systems in scope for PCI DSS.  For custom applications, this logging policy needs to be communicated to internal or outsourced developers.”

Enjoy! And make sure you remember that I am available for consulting projects to deliver value to your organization as well.

Possibly related posts:

• “Log Management + SIEM = ?”
• "I Want to Buy Correlation" or How NOT to Pick a SIEM?”
• “The Myth of SIEM as "An Analyst-in-the-box" or How NOT to Pick a SIEM-II?”

• “Log Management / SIEM Users: "Minimalist" vs "Analyst"”
• “On SIEM Complexity”
• “SIEM Bloggables”

SANS Log Management Survey 2010 is Out!

The famous SANS Log Management Survey 2010 is out; grab the document here [PDF], some highlights follow below:

• One of the highlights this year is “there is room for improvement in the ability of log management systems to deliver value from logs being collected, specifically in the areas of searching (where 36% of respondents reported problems), and analysis (where 34% had problems)”
• It seems like collection beast has been beaten back by most organizations ”in 2005, respondents reported their biggest problem was simply collecting log data, in
  2010, collection was cited by only 10% as the biggest problem.” Looks like we continue to nicely evolve along the log maturity curve.
• ”The top reason for collecting logs was to “Detect/prevent unauthorized access and insider abuse,” with 63% of respondents rating this as most critical.“ Compliance, BTW, got the 2nd place with 41%. BTW, I think this is a fluke since the survey unexplicably had two of the identical options “meet regulatory requirements” and “ensure regulatory compliance."  These two together beat the current response leader!
• As expected, “organizations aren’t installing log management systems for their troubleshooting value, yet an increasing
  number are finding troubleshooting assistance to be a useful added bonus.” The magic of “Compliance+” model where you buy from compliance (say PCI DSS) and then use for security, troubleshooting, etc is alive and well!
• Another long expected finding is that  “we’re also seeing a large increase in the amount of log data being collected from a variety of other types of sources.” (there is a curve for that too). Log management is not only about firewalls, routers, switches, IDS/IPS, servers anymore (collection rates for these run in 90-95% range)
• And here is an OMFG: “Last year [2009], 41% of respondents collected log data from homegrown applications. This year, the definition was expanded to include both homegrown and commercial applications, and 73% of
  respondents say they’re collecting logs from these sources.” Mind-blowing indeed! I’d never guess that 73% of all organization collect application logs today. I am sure folks at Brannan St are preparing for an IPO, given this news.
• Similarly shocking is a finding that ”Logs from desktops are also being collected—49% of respondents report collecting data from desktops.” And so is “48% of respondents indicated they collect log data from “Physical devices (badge access systems, plant control systems).” This is great! This totally makes me think we live in the 21st century :-)
• Even though “The amount of log data being collected is growing at the rate of 15-20% per year,”  log retention is up, as expected, “This year, the largest group retained logs for one to two years.” However, survey says that even some PCI DSS impacted organizations store logs for less than 90 days. Sorry, guys, you are just not compliant :-) And don’t blame the council!
• At the end, the survey teams gives some useful tips such as “Know Your Data” and “Know Your Logs,” and, specifically, “Get to learn what normal is for your organization”

So, enjoy the survey! BTW, the webcast (part 2) focused on the use of the data – which is more fun (here is a link to part 1 webcast which focused on collection). The rumor is, however, that the recording for part 2 might not be available… :-)

Open Group Log Webcast Slidea and Q&A: “Enterprise Logging and Log Management: Hot Topics”

As you remember, I’ve done this webcast with Open Group called “Enterprise Logging and Log Management: Hot Topics.”

Here are the slides from the webcast. Full recording with voice can be found here. Below I am answering some of the fun questions we got at the show for a broader audience of this blog.

 

Q: As the log management curve matures [reference to this graph], how do you ensure that the log data is secure?

A: Check out my “Top 11 Reasons to Secure and Protect Your Logs.” In reality, access control, occasionally hashing (yes, sometimes even with MD5) and sometimes encryption of archived logs is the “state of the art” for log protection. Think about it! People don’t encrypt and poorly protect SSNs, payment card numbers and their own key intellectual property… do you think they will protect logs well? Thus this is in mane cases an academic question…

 

Q: What do you mean by “use cases” here, is it the same concept as in software engineering or it has diff context here?

A: Yes, same use case definition – pardon for a bit of PM-speak. Example brief SIEM use cases are here.

 

Q: Are there any templates or best practices to decide as what to log in order to cover wide range of domains/purposes e.g. hacking, policy,

A: This is a million dollar question, really. What exactly needs to be logged for PCI has been discussed here and here and I was involved in some consulting projects to define that for a particular company (recent project example). In the near future, an attempt will be made to answer this question more consistently… sorry, can’t say more yet, but watch this blog for updates.

 

Q: How have you dealt with the trade off of logging requirements & mandates vs scale & performance needs in the area of application architecture? 

A: Poorly? :-) In most cases the mandate/security requirement HAS TO WIN and the only way for the developer to present this situation as “a tradeoff” is to avoid the security guy like a plague until the application is fielded – and the present this fake “dilemma.” In reality, if your application crashes or slows to the crawl when you enable logging of, say, all transactions, it needs to go back to the drawing board. Think of an example: can you field a payment app that can operate without logging all transactions? There is no tradeoff here.

 

Q: Would you please suggest a log management application?

A: Free tools are listed here and some commercial ones are here; you can pay me to select the right tool for your requirements  since log management is broad enough and complex enough to make “one best log management tool” a pipe dream at best. Are you collecting Cisco ASA log data or Oracle Finacials audit table? For PCI DSS or against web application attacks? Or maybe for web server debugging? These are other cases will have different “best app choices.” You can try reading this to learn maybe you need to write your very own log analysis application.

 

Q: What is your opinion of OVAL/CVE and SCAP as standards for log management?

A: CEE by MITRE is an active effort to create such set of log standards; NIST plan to later adopt them as “EMAP” (SCAP’s logging brother). As we work on the standard, I occasionally blog about it here. Right now the team is actively engaged at weekly workgroup calls and email discussions, mostly focusing on finalizing the taxonomy draft (the famous “O-A-S”), “logging profiles” and other fun things.

Enjoy!

Possibly related posts:

• “Thursday 3/25 IANS Webcast + Panel on Log Management: “Awesome++””
• My other recent presentations and webcasts
• All of my speaking
• My decks at Slideshare.

CISecurity Metrics Move Ahead

Center for Internet Security Metrics Project has done a quick poll on security metrics goals; some of the results are shown below with their permission:

“The top three goals of metrics programs are to:

1. Improve security outcomes (35%)
2. Improve risk management decisions (30%)
3. Improve security process performance (15%)
   

The top three reasons why metrics are requested are (in order):

1. For security trends
2. Evidence of compliance
3. To justify spending

The top three business benefits expected from metrics are:

1. Improve security outcomes
2. Align security activities with business goals
3. More efficient use of resources
   

Metrics Programs:

•   8% have an existing program in place
•   30% have recently established metrics programs
•   62% have the creation of a metrics program as a current goal
  

Constraints on metrics programs are:

1. Lack of resources
2. Lack of information on what metrics to deploy
3. Lack of capability/data access

  30% of respondents cited lack of resources as the primary
  constraint, and many comments indicated the need for an
  established standard with metrics accepted as meaningful in
  order to both move the organization and to obtain long-term
  resources. “

Grab the v1 metrics here. A quick start guide on them is in development.

IMHO, metrics is #1 hole in security today: our total inability to tie security controls to outcomes is truly sad. And, yes, maybe blind diligence-based security is the answer. And then again … maybe it is not :-)

Monthly Blog Round-Up – March 2010

As we all know, blogs are a bit "stateless" and a lot of useful security reading material gets lost since people often only pay attention to what they see today. These monthly round-ups is my way to remind people of useful content from the past month! If you are “too busy to read the blogs,” at least read these.

So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts/topics.

1. By a HUGE margin (20x?), the #1 post this month is “Simple Log Review Checklist Released!” Grab our log review checklist here, if you have not done so already.
2. My RSA 2010 interview with Bob Russo and Troy Leach from PCI SSC holds the #2 spot: “RSA 2010 EXCLUSIVE PCI Security Standards Council Interview.” BTW, my other RSA coverage shows up on the top list as well: “RSA 2010 – Day 1 Metricon” and other RSA 2010 posts.
3. “The Myth of SIEM as “An Analyst-in-the-box” or How NOT to Pick a SIEM-II?“ and its predecessor ““I Want to Buy Correlation” or How NOT to Pick a SIEM?” hold the next position this month. They present some sadly popular misconceptions about acquiring and implementing SIEM and log management tools.
4. “Log Management / SIEM Users: “Minimalist” vs “Analyst”” being next on the hotlist made me think that maybe my blog is back to being the best blog on SIEM and log management :-) Also, my post on progressing from logging to log management to log monitoring discussion in “Logging, Log Management and Log Review Maturity”  is still popular as well. It presents a maturity scale for organization selecting log management or SIEM.
5. Open source SIEM – and now also open source log management - theme continues to drive a lot of traffic (starting from “Short Observation on Open Source SIEM”) – it looks like folks are still desperately googling for it. “Why No Open Source SIEM, EVER?” post takes the spot in Top5 this month again – and so does “Open Source CLOUD SIEM, Anybody?” The older inspiration for these posts is “On Open Source in SIEM and Log Management.”

This month I am continuing a new tradition: I am going to thank my top 5 referrers this month (those that are actual humans, that is). So, thanks a lot to the following people whose blogs sent the most visitors to my blog:

1. Walt Conway
2. Sandro Süffert
3. Dancho Danchev
4. Lenny Zeltser
5. Stefano Zanero

Thank you for all the link-love!

See you in April; also see my annual “Top Posts” - 2007, 2008,  2009!

Possibly related posts / past monthly popular blog round-ups:

• Monthly Blog Round-Up – February 2010
• Monthly Blog Round-Up – January 2010
• Monthly Blog Round-Up – December 2009
• Monthly Blog Round-Up – November 2009
• Monthly Blog Round-Up – October 2009
• Monthly Blog Round-Up – September 2009
• Monthly Blog Round-Up – August 2009
• Monthly Blog Round-Up – July 2009
• Monthly Blog Round-Up – June 2009
• Monthly Blog Round-Up – May 2009
• Monthly Blog Round-Up – April 2009
• Monthly Blog Round-Up – March 2009
• Monthly Blog Round-Up – February 2009
• Monthly Blog Round-Up - January 2009
• Monthly Blog Round-Up - December 2008
• Monthly Blog Round-Up - November 2008
• Monthly Blog Round-Up - October 2008
• Monthly Blog Round-Up - September 2008
• Monthly Blog Round-Up - August 2008
• Monthly Blog Round-Up - July 2008
• Monthly Blog Round-Up - June 2008
• Monthly Blog Round-Up - May 2008
• Monthly Blog Round-Up - April 2008
• Monthly Blog Round-Up - March 2008
• Monthly Blog Round-Up - February 2008
• Monthly Blog Round-Up - January 2008
• Monthly Blog Round-Up - December 2007
• Monthly Blog Round-Up - November 2007
• Monthly Blog Round-Up - October 2007
• Monthly Blog Round-Up - September 2007
• Monthly Blog Round-Up - August 2007

Obligatory “added everywhere” posts :-)

• I am available for consulting projects related to logging, log management, SIEM, PCI DSS etc. Please see the services list at my consulting site.