Another Fun SIEM Whitepaper

As promised, here is another detailed SIEM whitepaper called “A Pragmatic Approach to SIEM: Buy for Compliance, Use for Security” that I wrote for a great team at Tripwire earlier this year.

“While recent economic troubles might have something to do with it, many organizations today seek to only do a bare minimum of security. To be more precise, they try to do what they think is the bare necessary minimum. Their perception that security “due diligence” can be reduced all the way down to the level prescribed by regulations, such as PCI DSS, is more common than ever today. All too common result of this thinking is security breaches and other damaging events.

This trend has affected many security safeguards, and SIEM and log management are hard hit by this as well. It is very common to deploy these technologies in order to satisfy the compliance check box. In this paper we will analyze this trend and provide useful guidance for getting value out of SIEM and log management tools while focusing on protecting systems and data – and not simply on checking the box.”

Get the paper here.

Possible related posts:

• “New SIEM Whitepaper on Use Cases In-Depth OUT!”
• “Two New Logging Resources Published”

CEE Architecture Overview FINALLY Out!

The future of logging is finally here! Common Event Expression (CEE) team releases CEE Architecture Overview [PDF] for public comments. HUGE thanks to MITRE side of team for finally clearing all the hurdles and releasing “our baby.”

The Common Event Expression (CEE™) Architecture Overview document defines the structure and components that comprise the CEE event log standard. This architecture was developed by MITRE, in collaboration with industry and government, and builds upon the Common Event Expression Whitepaper. This document defines the CEE Architecture for an open, practical, and industry-accepted event log standard. It provides a high-level overview of CEE along with details on the overall architecture and introduces each of the CEE components including the data dictionary, event taxonomies, syntax encodings, and profiles. The CEE Architecture is the first in a collection of documents and specifications, whose combination provides the necessary pieces to create the complete CEE event log standard. 

We encourage community members to offer feedback on this document on the CEE
Email Discussion list. You may also contact us directly at cee@mitre.org.

Again, the document is at: http://cee.mitre.org/docs/CEE_Architecture_Overview-v0.5.pdf

The day we were working towards for nearly five years (!) has finally come and more of CEE is revealed to the world! Of course, detailed specifications are still in development and we will release them when they are ready for public review.

Possibly related posts:

• All posts tagged CEE
• My first post on CEE in April 2007

To Those Escaping from Sinking SIEM/Log Management Vendors

As I am hearing rumors about some sinking (and some sunk) SIEM/log management ships, here is a special “public service” announcement to those affected by the disasters.

Don’t despair!

Quality vendors in this space are hiring like crazy, especially if you are a good Field Engineer (example) or Professional Services (example). Check out other SIEM and log management vendor sites as well, a lot of field hiring and some HQ hiring is going on as we speak.

And, if you happen to be a customer of one of those unfortunate vendors, well… pick better next time :-) Oh, one more tip: security vendors are not a reliable source of information on “security vendor longevity.” You will get wildly-crazy over-estimates (about self) and minblowingly-insane under-estimates (about competitors)…

Possibly related pots:

• All posts tagged jobs.
• SIEM-related Job: Principal SIEM Consultant
• SIEM-related Field Job: Western US
• SIEM-related Product Management Job: Atlanta, GA

Silly Compliance Poll

OK, some of you would say that I have weird hobbies, like writing books about  PCI DSS.

In any case, just for fun I am running this poll on compliance here. Please respond – violently is OK, if compliance brings this up in you :-)

Enjoy!

Possibly related posts:

• Old posts with fun polls and their analysis.

CEE Update – Aug 2010

Reposted (from here) for those who don’t monitor public Common Event Expression (CEE) log standard effort.

“First of all, let me answer the question that is in all of your heads: No, CEE is not dead... After a slow start, the work pace has picked up over the past couple of months. I apologize for the extremely long delay in posting any details regarding the state of CEE.

The CEE Board [that’s us – A.C. :-)] has been working on bringing the CEE Dictionary, Taxonomy, and Syntax requirements together. We have drafted specification documents detailing the CEE Architecture as well as the initial Dictionary and Taxonomy specifications. These documents are the first of the CEE v0.5 (previous versions were internal) document series and have already been shared with some of you for your feedback. We are waiting for the final authorization before they are posted to the CEE website for your review.

This authorization is expected to be granted next week. A follow-up e-mail will be sent to this discussion list as well as the CEE Announce list notifying you that the documents were posted along with the URL where said documents may be obtained. It is important to note that these are only the first iterations of many. We need your help in improving CEE.
 

In addition to helping critique and improve the CEE documents, we are also requesting your help in building and improving the CEE Use Cases. Within the next week or two, you will also receive the beginnings of a list of CEE Use Cases for review.”

Sign up for the public CEE list to see more. Meanwhile, the effort for log standardization makes another step!

Log Math

100,000 log messages / second x 300 bytes / log message ~ 28.6 MB
      x 3600 seconds  ~ 100.6 GB / hour
            x 24 hours ~ 2.35 TB / day
                  x 365 days ~ 860.5 TB / year
                        x 3 years ~ 2.52 PB

Oops! Now you know what is a petabyte.
And, BTW, you also now what is a trillion – of log messages.

Brief PCI Council Interview in Regards to PCI DSS 2.0

Everybody knows that PCI DSS 2.0 is coming! The Council released a summary of changes for version 2.0 [PDF] to be released in October 2010. Council folks have granted this brief interview to Security Warrior Blog; it is provided below in its entirety:

 

Q1: As promised, the changes to PCI DSS are minor. Are you worried that since the next edition will come in 2013, both technology and threat landscape will change way too much and DSS will lose its relevance over time?

PCI Council Answer 1: The Standard is maturing and is increasingly being adopted globally, that's part of the reason why there are no new requirements  in DSS 2.0. Nonetheless, we always have in place an errata process that allows us to add elements or requirements to the standards as necessary. It is important to note that in the years that the standards have been in effect, there has never been a specific threats that has required this. [emphasis by A.C.]

[A.C. – I am sure the highlighted bit will rile a lot of noisy security folks with minimum knowledge of the payment industry, but, upon some thinking, I actually tend to agree with it - mostly. The issue is not with “requirements are stale”, but with merchants not doing this stuff. Daily log reviews are MANDATORY for PCI DSS compliance (see Req 10.6). Are they ALL doing it? Ha. And people still fall victim to passwords guessing en masse – like its 1983. Even future “PCI in the cloud” is fairly well addressed by Req 12.8. So please can this “threats are dynamic” snivel…]

 

Q2: Does Council plan to launch any studies on the effectiveness of "the new PCI DSS" vs today's cyber attacks against payment card data?

PCI Council Answer 1: While we have no plans for an official study, we do receive feedback and public forensic reports, like the recent Verizon Data Breach report that allow us to review forensic data gathered globally. [link added  by A.C.]

 

Q2: Will there be any changes to Prioritized Approach to PCI DSS document in light of PCI DSS changes?

PCI Council Answer 3: Not at this point, but the new DSS does allow, on a merchant by merchant basis, a certain degree of a risk-based approach during their assessments.

[A.C. – this means that “implementation first, policy last” thinking will stay in. Intuitively, I get it – policies on their own don’t stop loss, while removal of PAN storage does – but I expect a lot of whining over this one as well]

 

Q4: Does Council plan any additional implementation guidance along the lines of wireless guidelines to help merchants comply with PCI 2.0?

PCI Council Answer 4: At some point, we will be releasing a similar set of guidelines on Bluetooth deployments, similar to the Wireless Guidelines.

There you have it. And we wouldn’t even have to update our PCI book much :-) Go PCI 2.0!

SIEM-related Job: Principal SIEM Consultant

As a favor to yet another friend, I am posting yet another SIEM-related job.

Job Description

A Principal Security Consultant at Vigilant is expected to leverage his/her extensive technical abilities to provide innovative, pragmatic and business-focused security solutions for our customers. Principal Security Consultants report to the Director of Services Delivery, and are expected to work in the capacity of a Vigilant Project Managers on multiple, concurrent engagements to architect and deliver a variety of solutions, in such functional areas as Security Information / Event Management (SIEM), Security Architecture & Design, and general Security Assessments. It is expected that the Principal Security Consultant will be a mentor within the Professional Services team, and will provide expert advice and guidance to partners and newer Vigilant consultants. Applicants who reside in the NY Metro area and Washington DC area are encouraged to apply.

Skills

Analytical & Technical Skills:
• Expert knowledge of SIEM products (ArcSight, Novell Sentinel, RSA enVision, etc.)
• Ability to design complex, enterprise-scale network security architectures
• Extensive knowledge in the use and configuration of relational databases, including Oracle and SQL Server
• Expert knowledge in the use of Unix (Solaris/Linux) and Windows Server Family (NT/2000)
• Extensive experience with Intrusion Detection Systems, Firewalls, Proxy Servers, Antivirus, NAC, or other network security infrastructure
• Familiarity with the integration of 3rd-party applications (ETL tools, data mining, business intelligence products)
• Ability to analyze complex issues for impact and alternative solutions, making logical decisions based on overall product objectives
• Ability to prioritize tasks and manage time efficiently. High level of self-initiative and self-motivation.

Full info and how to apply is here.

More SIEM jobs from Vigilant in the NYC area are here.

Possibly related posts:

• All posts tagged jobs (mostly SIEM and log management related)

New SIEM Whitepaper on Use Cases In-Depth OUT!

A lot of people talk about “SIEM use cases” (example), but few describe them in depth, complete with instructions on how to actually solve the problems and actually do each use case, using a particular SIEM tool. Here at Security Warrior Consulting, we are all about DOING, not just TALKING :-)

With this introduction, I am presenting a new detailed SIEM whitepaper that I wrote for the RSA enVision team.  “This paper will help jumpstart SIEM use process and highlight common SIEM usage scenarios for organizations of all sizes. It will also explain how to operationalize the SIEM tool and utilize it for many security use cases and scenarios, from Web site threats to security incident response. Specific examples from RSA’s enVision platform are used to illustrate the concepts in the paper.”
Here is an excerpt from one  use case from the paper:

Comprehensive firewall monitoring
(security + network)
Since the early days of SIEM technology, firewall log data
has been considered as one of the most useful and
commonly collected information sources.
Apart from allowing and denying connections to and from
the network, firewalls allow recording or logging of every
single connection denied or allowed by the firewall. An
example would be connections from the outside world to
the DMZ Web server, or connections by users inside the
company to their favorite social media Web site.
Analysis of such logs is extremely useful for security,
compliance and even operational purposes such as
network management, bandwidth management, etc.
For example, on the compliance side, PCI DSS, HIPAA,
NERC/FERC all have firewall logging implications. Firewall
logs are also extremely useful for incident response and
forensics since they can help identify the connectivity
pattern and serve as “poor man netflow.” On top of this,
firewall logs can be used to assess the health of the
firewall itself and to optimize the rule set performance.

Collection: comprehensive firewall log collection is
mandatory for this use case, and it is important to
remember that firewalls can record both failed and
successful connections through the firewall – both
types are essential for SIEM.
…

Grab the paper here [PDF]!

Another fun long whitepaper is coming soon … and it will be just as fun.

UPDATE (09/23/2013 [!]): the paper is again available here [PDF] with the following disclaimer, mandated and provided by RSA as a condition for paper access:

This document is provided for historical reference only; since the publication of this document by RSA, they have come out with RSA Security Analytics which provides centralized security monitoring by combining the collection of logs/events and network packets fused with threat intelligence.

Possibly related posts:

• Two New Logging Resources Published
• How Do I Get The Best SIEM? 
• On Choosing SIEM
• One More Time on SIEM vs Log Management

CloudAudit Delivers – Cloud Compliance Maps

CloudAudit delivers it’s first batch of cloud compliance specifications. Quoting from the announcement:

“The CloudAudit initial distribution features five elements:

1) The CloudAudit normative specification in .txt format [cloudaudit-specification_draft.txt]
2) The CloudAudit CompliancePacks archive of .xls files which map controls/control objectives to namespaces based upon the Cloud Security Alliance Control Matrix [cloudaudit-compliancepacks.zip]
3) The CloudAudit namespaces archive which represents a complete CloudAudit directory tree representation of all CompliancePacks    with placeholder index.html/manifest.xml created in each directory stub [cloudaudit-namespaces.zip]
4) The CloudAudit Python script pack which automates the creation of the CloudAudit namespaces above  [cloudaudit-namespace_creator.zip]
5) A README.txt file [this content]”

and

“The CompliancePacks map control objectives to specific namespace entities which are contained below and feature NIST SP800-53, PCI DSS, HIPAA, ISO27002 and COBIT compliance frameworks.  Ultimately these directories are where a Cloud Provider will store and secure the assertions and supporting materials related to each compliance framework or assertion.” [<- the bold part is kinda the whole point :-) A.C.]

Grab the mammoth itself here [ZIP].

Enjoy!

Pathetic Analytics Epiphany!

As some of you know, I have been doing SIEM and log management for more than 9 years already. Nine years of looking at them logs is a long time, lemme tell you  :-)
And that 86% of cases where intrusion evidence was present in logs (see Verizon 2010 Breach Report) just sent me down into cold rage. This is freakin’ year twenty-ten! Why are people STILL not looking at their logs?!! Not even monthly especially where daily is mandated (see PCI DSS)?! Are they that mind-blowingly stupid?! Do they love to live on the bloody edge, perhaps? Do they enjoy being violently penetrated and not even enjoy it, purely for masochistic purposes? I read some blog posts which basically expressed the same rage (example), and my rage just became The Epic Log Rage.
And while consumed by this rage, I had an epiphany! End-users are not really the ones to blame - not that much. Nobody can be blamed for not wanting to ‘grep’ a 245GB log file… I think :-)
Our log analysis tools are simply too pathetic. Think about it - they are!!!
Why is “empty search window” and “overly complicated correlation rule builder” represent the state of the art of log analysis after nearly 20 years of development in this field?! Why do we have to dig for log insights like fucking truffle hunting pigs?

Further, yesterday I was trying to explain the state of the art of log analysis to a client (who looks to use his cool  new technology for log analysis and SIEM), and I felt embarrassed to admit that, yes, “search” and “rules” are indeed the state of the art.
In other words, most of the analysis burden is on the tool USER BRAIN, not on the TOOL. They looked at me like I just wasted 10 years of my life, writing regexes and otherwise being a stupid monkey. Even things like profiling/baselining (example) or simple – and I mean SIMPLE – data mining (example, details) mostly stay on research drawing boards for ages.
So, I can talk about unsupervised learning, associative rule discovery and natural language processing (the other NLP) for logs as well as the next guy (and maybe better), but the tools you can buy just don’t have that shit. They have “compliance reports” [deep insight alert… NOT :-], “empty search window” and “learn what CustomInteger17 means and then you can write your very own correlation rule…that will function…maybe” while a simple Netflix movie selection triggers more brainpower on the backend than is available in all SIEM product combined…
To conclude, I have a suspicion that it is likely that in the near future all SIEM tools magically turn into electric typewriters.
P.S. My dear vendor friends and colleagues, don’t take offense! I still love you. We all just need to work and think a little harder – that’s all :-)
P.P.S My dear friends in academia, please DO take offense! Most log analysis research I’ve seen over the last 10 years is …mmm… not very practical. Get some real logs and get thinking!

“How to Do Application Logging Right” Paper OUT!

Just wanted to highlight another useful resource on logging: "How to Do Application Logging Right” by Gunnar Peterson and myself. Following on our previous IEEE paper (here [PDF]), we explored application logging from a developer's perspective. As Gunnar already pointed out, “audit logs are one of the quick, dirty and cheap things that can improve enterprise security.”

Here is a fun except:

“Organizations have finally gotten network device logging and—to
some extent—server logging under control. However, after getting
used to neat Cisco Adaptive Security Appliance or other firewall
logs and Linux “password accepted” messages, security incident
investigators trying to respond to the next wave of attacks
have been thrust into the horrific world of application logging.”

and

“We can start by establishing  criteria for good security audit logs (which we just call “logs” from now on). […]  On the basis of the six Ws, the following list [see paper] provides a starting point for what to include [in each application log message]”

and

“Software architects and developers must “get” logging; there’s
no other way. This is because infrastructure logging from network
devices and operating systems won’t cut it for detecting
and investigating application-level threats. Security teams will need
to guide developers and architects through useful, effective logging.”

Grab the paper here [PDF] and enjoy!

And, Raffy, you owe me another beer for “We thank Raffy Marty of Loggly for his thoughtful review of the draft article.” :-) In fact, I think me using the word “thoughtful” here justifies “beer+2”…

Possibly related posts:

• IEEE

Updated With Community Feedback SANS Top 7 Essential Log Reports DRAFT2

Thanks for overwhelming community response (here, here, here, and separate blog posts here and here and I might have missed a few places too). The list has grown and is on the verge of becoming unwieldy and not “top” and “essential” so I am about to close the comment period, write up the doc and send it to SANS to update the legacy SANS Top 5 Log Reports [PDF].

Any last second thoughts before I document this baby? Any smokin’ hot log reports to add?!  Also, anything I should take OFF the list for not being “top” and “essential”?

 

1. Authentication and Authorization Reports

a. All login failures and successes by user, system, business unit – must have login success logs, not just failure!

b. Login attempts (successes, failures) to disabled/service/non-existing/default/suspended accounts

c. All logins after office hours / “off” hours

d. Users failing to authentication by count of unique systems they tried

e. VPN authentication and other remote access logins (success, failure)

f. Privileged account access: logins, su use, Run As use, etc (success, failure)

g. Multiple login failures followed by success by same account – needs to have correlation for that

2. Change Reports

a. Additions/changes/deletions to users, groups – even a trend on user additions across systems would be useful

b. Additions of accounts to administrator / privileged groups

c. Password changes and resets – by users and by admins to users

d. Additions/changes/deletions to network services

e. Changes to system files – binaries, configurations – likely needs a list to run

g. Changes in file access permissions

h. Application installs and updates (success, failure) by system, application, user

 

3. Network Activity Reports

a. Log volume trend over days – watch for both drops and increases in logging levels on systems

b. All outbound connections from internal and DMZ systems by system, connection count, user, bandwidth, count of unique destinations, hour of access (focus on “off hours”)

c. Top largest file transfers (inbound, outbound) OR Top largest sessions by bytes transferred

d. Web file uploads to external sites - based on proxy logs

e. All file downloads by content type (exe, dll, scr, upx, etc) and protocol (HTTP, IM, etc)

f. Internal systems using many different protocols/ports

g. Top internal systems as sources of multiple types of NIDS, NIPS or WAF Alerts

h. VPN network activity by user name, total session bytes, count of sessions, usage of internal resources

i. P2P use by internal systems

j. Wireless network activity

i. Rogue AP detection

ii. Wireless network access by user

iii. WIDS/WIPS alert activity

4. Resource Access Reports

a. General

i. Access to resources on critical systems after office hours / “off” hours

b. Web

i. Top internal users blocked by proxy from accessing prohibited sites (malware sources, pornography, etc)

c. File

i. File, network share or resource access (success, failure) - for specific audited resources

d. Database

i. Top database users - excluding known application access

ii. Summary of query types - excluding known application queries

iii. All privileged user access

iv. All users executing INSERT, DELETE commands - excluding known application queries

v. All users executing CREATE, GRANT, schema changes, etc

vi. Database backups

e. Email

i. Top internal email addresses by count of messages, byte volume

ii. Top internal email addresses sending attachments to public/hosted addresses

iii. All emailed attachment content types, sizes

iv. All internal systems sending mail – excluding known mail servers

5. Malware Activity Reports

a. All systems with AV events by user, system name, time trend

b. Detect-only events from anti-virus tools (leave-alones)

c. All anti-virus protection failures (crashes, unloads, update failures, etc)

d. Internal connections to known malware IP addresses – a public blacklist needed

6. Failures and Critical Errors

a. Critical errors by system, application, business unit

b. System and application crashes, shutdowns, restarts

c. Backup failures

d. Capacity / limit exhaustion - memory, disk, CPU, etc

7. Analytic Reports – Mostly Using “Never Before Seen” (NBS) aka “NEW Type/Object” Analysis = also add “rarely seen” / OSO / “bottom X by …”

a. NEW (NBS) Log message types / event types

b. NEW (NBS) Users authenticating successfully

c. NEW (NBS) Sources that connected to systems using privileged accounts

d. NEW (NBS) Internal system connecting to external systems

e. NEW (NBS) External IPs connecting to NEW Entry Points – not sure how to collect this

f. NEW (NBS) Ports accessed on internal systems

g. NEW (NBS) HTTP request types

h. NEW (NBS) Downloaded/uploaded content types

i. NEW (NBS) Query types on databases

 

More last-second comments? If not, I will be adding documentation for all report examples and submitting it to SANS for distribution.

Also, if you commented, please let me know if you do NOT want your name in the credits. Default:  you will be mentioned as valuable contributor as long as your contribution was, you know, valuable :-)

Possibly related posts:

• Simple Log Review Checklist
• SANS Top 5 Essential Log Reports Update!

Verizon Breach Report 2010 OUT!

Belated reading of Verizon DBIR 2010. My favorites:

“79% of victims subject to PCI DSS had not achieved compliance” [close to what I suspect the reality is – a lot of organizations did try to ‘fake their way’ to PCI compliance. Hopefully now Bob’s point about ‘not compliant at the time of the the breach’ will make more sense – A.C.]
“Because fraud alerts are the leading method of discovering breaches, it stands to reason that many breaches could occur without anyone being the wiser if the criminal decided it was in his best interest to be patient“ and “We find it more than a little ironic that the most effective way of detecting data breaches is for the perpetrator to fraudulently use what was stolen.” [every time I read “fraud is the leading method of breach discovery”, I feel sad. To me this means either most organizations are negligent, or our security technology is crap. Or both :-)]
I am not touching the whole insider vs outsider debate again; it just smells. Read the report and forget the “80/20 myth.” Think about it though: every organization has 1-100,000 insiders (=employees, partners, contractors, etc), but there are possibly millions of criminal outsiders… Given how porous many networks are, who do you think will steal more?
“incredible 97% (!) of the 140+ million records were compromised through customized malware across the Verizon-USSS caseload.” [toss the AV, finally? – A.C.]
“The use of stolen credentials was the number one hacking type in both the Verizon and USSS datasets, which is pretty
amazing when you think about it.”
“We’ve observed companies that were hell-bent on getting patch x deployed by week’s end but hadn’t even glanced at their log files in months.”  [given that password guessing – seen in logs – trumps vuln exploitation by such a wide margin, this should change. Will it? – A.C.]
“The security media hype machine would like us to believe that we’re all Targets of Choice [which is ‘cool’ and not Targets of Opportunity which is silly – A.C.] and there’s nothing we can do to stop the new [insert whatever you like here] threat. This simply isn’t true and is not a healthy line of reasoning for security management.”  [indeed, ‘APT is for everyone’ message is pretty stupid. If your passwords on external routers are something like ‘password’, you have a long task list to go thru before ‘APT’ shows up – A.C.]
Breach discovery bar chart on the right is “The Saddest Picture Ever (TM)” :-) No comment really.
“It cannot be a pleasant experience to learn that the six months of log data you’ve been collecting contained all the necessary indicators of a breach. It is, however, a common experience. We consistently find that nearly 90% of the time logs are available but discovery via log analysis remains
under 5%.”
“In the 2009 DBIR, we reported that event monitoring and log analysis, which should be the doyen of detection, successfully alerted only 6% of breach victims. This year that figure has dropped—yes dropped—to 4%. Of that 4%, log analysis lead to the discovery of a handful of breaches while intrusion detection systems identified only one.” [‘Richard, IDS really is dead’ :-) or The Second Saddest Fact in the report - A.C.]
“Change your approach to event monitoring and log analysis: A quick review of a few findings from this report will set the stage
for this one. 1) In most attacks, the victim has several days or more before data are compromised. 2) Breaches take a long time to
discover and 3) when that finally happens, it usually isn’t the victim who finds it. 4) Finally, almost all victims have evidence of the
breach in their logs.” [this, BTW, reminds us that ‘detection within days’ is darn right close to ‘real-time’ for most organizations… – A.C.]
Get full report here.
Enjoy!

Monthly Blog Round-Up – July 2010

Blogs are "stateless" and people often pay attention only to what they see today. Thus a lot of useful security reading material gets lost.  These monthly round-ups is my way of reminding people about interesting blog content. 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. “Top5 SANS Log Reports Update DRAFT” finally beat the previous champion of a few months “Simple Log Review Checklist Released!” In a few days, I will post the results of a community effort to refine the new SANS Top 8 (!) Log Reports…stand by.
2. Career posts somehow always get top scores automatically and “Skills for Work vs Skills for Getting Hired” is no exception. Just as its predecessor, “Myth of an Expert Generalist”, it got on my monthly Top 5 posts immediately, was featured on Reddit.com, etc, etc.
3. “How Do I Get The Best SIEM?”, a companion to “On Choosing SIEM“, went to the top like lighting a few months ago and stayed there this month. If you are thinking of getting a SIEM or a log management tool, check them out and also look at related resources at the end of these posts.  “The Myth of SIEM as “An Analyst-in-the-box” or How NOT to Pick a SIEM-II?” and ““I Want to Buy Correlation” or How NOT to Pick a SIEM?” also stay at the top – it seems like smaller organizations are looking at deploying SIEM and log management and there is a lot of interest in simple guidance on this.
4. Next up are my notes from University PCI DSS workshop where I delivered a keynote: “My Best PCI DSS Presentation EVER!” (the infamous “compliance kitten” quotes comes from here)
5. The report from HITB 2010 Amsterdam conference which I opened with a keynote “Security Chasm” is also on the monthly top list – “HITB 2010 Amsterdam Awesomeness.”

Also, below I am thanking my top 5 referrers this month (those who are people, not organizations). So, thanks a lot to the following people whose blogs sent the most visitors to my blog:

1. Michał Wiczyński
2. Raffael Marty
3. Dancho Danchev
4. Walt Conway 
5. Cédric Blancher

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

P.S. Watch for a fun post tomorrow, releasing a new SIEM whitepaper that I wrote for a client.

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

• Monthly Blog Round-Up – June 2010
• Monthly Blog Round-Up – May 2010
• Monthly Blog Round-Up – April 2010
• Monthly Blog Round-Up – March 2010
• 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