My Security Predictions for 2011

Now that I have checked my  2010 predictions (see here) and “reflected and mused” on 2010 (here), I am allowed to proceed to 2011 predictions 

My past experience predicting shows that I am a cowardly, extrapolating predictor – and can get a lot of easy, obvious stuff right. Great!  I will do some of it  now as well since  there is nothing wrong with extrapolation and “Feynman prediction methodology” [=predicting that whatever is there now will stay the same in the future]), but will try to be a bit more wild, like I was in my 2020 (!) security predictions. Also, I noticed I’ve been a bit too verbose in the past, so this year I ‘d rather be brief (since I am busier).

So:

• PCI DSS 2.0 marches on: this is the year when PCI DSS gets even BIGGER (if you can  imagine it!). And smaller too – more smaller business will “get” PCI. Great news! On the not so good side of PCI, I predict that  a few of “validated compliant” companies will be found abysmally non-compliant and insecure: after the breach or otherwise. Maybe some QSA heads will roll as a result, especially those “remote-assessing” “easy-graders.” The challenges of compliance in non-traditional environments (virtual, cloud, mobile devices, non-traditional payment methods, etc) will rise to prominence as well.
• HIPAA teeth: yes, this is one of those things that people has been predicting since 1996 (yes, really!), but somehow I feel like this time – in 2011 – HIPAA/HITECH enforcement will be for real.  OK…you can call me an idiot in a year, if I am wrong here.
• Application security – and application security monitoring:  Gunnar paradox on firewalls+SSL might finally start to break in 2011. I do predict that not just web application security, but also many internal “enterprise” application will get in scope for SIEM, correlation, near-real-time monitoring, etc. And not just at “adventurous” security leader companies, but more like in early mainstream.
• Still no mobile malware deluge: enough about this one. Enough! Enough!! For sure, there will be isolated (and possibly pretty bad) malware incidents, but not “Slammer for iPhone” or “Blaster for Android” in 2011.  I suspect that PCs will still have more “money” and more holes and so this is what the bad guys will continue to steal.
• Mainstream security in the cloud: yes, Qualys and a few others have been doing it since 1999 and a few cloud security providers has been absorbed into large entities (latest, sort of), but I suspect that in 2011 we will see much more of “<XYZ> approach to security of <ABC>… now in the cloud.” BTW, I mean REALLY using SaaS/PaaS/IaaS cloud options and not “press-release cloud” like many do today.
• “New” types of incidents: going on limb, I predict a few large  (and very damaging) breaches, NOT involving regulated PII, but good old secrets. Wikileaks mentality + cybercrime resources = a fun year!
• SIEM for dummies: OK, this is another risky one. As you know, there is no leader in the SMB/SME SIEM market and I am really looking for somebody to climb on that hill. The world needs a penultimate “SIEM for dummies.” As of today, SIEM is decidedly not.  At the very least….I am predicting the arrival of “a log toaster”
• Security vendors: despite the silly 2007 predictions by RSA CEO, there will still be hundreds of security companies around. However, some of the players will definitely feel like they”overstayed market’s welcome” (e.g. some legacy SIEM vendors) and will either die or go firesale.
• Risk “management”:  every past year, I predicted that we will remain dazed and confused about how to apply risk to information security in an objective manner (objective, not necessarily quantitative). This year…. drumroll… I am laying these dark thoughts to rest – at least for a while. Maybe, just maybe, we are starting to see both data and approaches that will eventually give us something to work with. And not just whine about it

Enjoy!

Possibly related posts:

• My prediction tracker of people’s 2011 predictions: www.delicious.com/anton18/security+predictions+2011
• My security 2010 predictions
• My security 2020 predictions
• All posts tagged prediction, going back to about 2007 or so.

Bottom 11 Log Management "Worst Practices"

FYI, this piece has been especially created for LogManagementCentral (original post). It is reposted here for posterity.

 

Many organizations talk about “best practices” for security, log management, SIEM, etc. The definition of such practice is often fuzzy (and overrun by marketing influences…) but can be loosely related to what leaders in the field are doing today and what practices generally lead to great results. Following the same model, we can create a definition of a “worst practice”:

· What the losers in the field are doing today

· A practice that generally leads to disastrous results, despite its popularity

Here are some of the “worst practices” in the area of SIEM and log management that I have observed over the years:

1. Skipping the requirement definition stage of SIEM purchase is one of the worst, albeit common, practices one can take. It almost always leads to failed SIEM projects, unmet needs for customers as well as unjustified anger aimed at technology providers. “John said that we need a correlation engine” is not the way to define your requirements, by the way.

2. Postponing the environment sizing until the purchase is another generally disastrous practice. Even if you plan to eventually collect “everything”, the initial implementation will only have a specific smaller set of data. Careful sizing of that initial phase by watching your logs for a week or two is very important.

3. Choosing by price alone has led to many wrong purchases – and not only in the realm of SIEM. SIEM and log management products are priced from $0 to a few hundred to millions – and there is usually a difference in both capability and scalability between tools with dramatically different prices. Remember that tool can be 30% cheaper, but be “only” twice as bad…

4. “Saving time” by not checking references is another common bad practice at purchase stage. Your environment might be unique, but references is one of the few ways to know that the tool you’re planning to purchase has the will of somebody else. Skipping Proof-of-concept is even worse- that is your way to test a complex new tool in your environment!

5. Expecting the vendor to tell you what you need to log happens more frequently than you might think. Sadly, the only person who knows your needs and requirement for logging, log management and log monitoring is you – not the vendor. If you don’t know – then nobody does.

6. SIEM implementation is often a very “political” affair and thinking you can do it alone without involving others from you organization is definitely the worst practices. SIEM touches systems, network devices, possibly IdM systems and many other components – each with their own business owners and administrators. These people and teams have to be involved in SIEM implementation; and there is no way around it. Preparing the infrastructure is key for the deployment, even if you simply need to make sure that all log source systems has their time synchronized.

7. Ignoring your legal team is a quick way to FAIL with SIEM, especially if your project covers log data from multiple countries. Log data is covered by a conflicting laws and regulations and only your organization legal counsel can figure it out.

8. Deploying everywhere at once and not in phases is a way to run out of budget, management patience and other resources. Phased approach – both in terms of log source scope and SIEM capabilities (from simple to more advanced) – is the only way to go. Focus on “quick wins” in each phase.

9. The interface is “intuitive” so who needs training? Avoiding training is not the way to save money on a SIEM tool. SIEM and log management tools connect to many pieces of the infrastructure and applications. The vendor or consultants might teach you how to resolve many of these challenges, based on their experience with other customers

10. Not checking for changed needs as your SIEM implementation expands is another way to fail. Even though your SIEM may have a few problems, it does not necessarily mean that it can solve every problem you have. Notice how some organization deployed log management tools and then had to expand their deployments to full SIEM due to evolving needs. “We made the decision years ago – why fuss over it?” does not work for integration-heavy technologies like SIEM.

11. Finally, expecting immediate reduction in work after deploying a SIEM is unreasonable. Unless you deploy, customize and tune your system, it is likely that you will not see massive resource savings. SIEM is a great example of “to get value you have to work on it” rather than a magic box that “tells you what is wrong”…

What good or bad practices with SIEM and log management can you share?

Today The Industry Is Changed!

Don’t I love overly dramatic headings? Yup, I do.
Pretty much since the day Security Scoreboard launched, I was a MAJOR fan of the site and have always considered it “an industry-changing idea”  that can solve the #1 problem in information security – no, not APT! – inability to match solutions to security problems and rate what solutions actually solve those problems well. The industry, as we all know, is full of crapware – from “PCI scans” for $0.41 per month to fake anti-spyware and “magic” appliances that “do security stuff.”
And now we have a powerful weapon to fight it! Today Security Scoreboard changes everything … again.
Specifically:

Security Scoreboard has announced the appointment of security industry veteran
Dominique Levin as Chief Executive Officer. The site offering unbiased end-user
reviews and ratings on security products also received an investment and moved its
headquarters to the Silicon Valley.

Yes, you can still think of the site as “Yelp for Security Products” – but also start thinking of it as “crowd-sourced and reality-based Gartner.”  In my opinion, there is NOTHING (!!!) that our industry needs more than clarity and Yes, even more than APT defense and easy-to-use SIEM  Lately, a lot of very smart folks have been bemoaning the state of the industry (example, example) and Security Scoreboard relaunch cannot have come at a better time.
Full press-release is pasted below (original) – yes, I am that excited to do it:

Security Scoreboard, which offers security product ratings and analytics based on real-world user experiences, announced that it has received an initial angel investment.
"Crowd-sourcing could significantly improve the validity and quality of the information available about commercial IT products”, said Dana Gardner, president and principal analyst at Interarbor Solutions. “As a consumer I can look at Angie's List, Rotten Tomatoes or TripAdvisor and it's crazy such thing doesn't exist for IT."
“Even if you have the time and money to test different solutions, it's always the details of real-life implementations that come to bite you”, said Chris Sawall, Supervisor of Information Security at Ameren Corporation, a Fortune 500 company and one of the nation's largest investor-owned electric and gas utilities. “You never know how technologies and solutions will really work until you have invested in them. Security Scoreboard allows me to be better informed."
At the time of the investment, the company also appointedDominique Levin as CEO.
Levin comes to Security Scoreboard from LogLogic Inc., a leader in security and log management solutions, where she served as Chief Marketing Officer and Acting CEO. She was also previously VP Marketing at PoliVec, held positions at Nippon Telegraph and Telephone and Philips Consumer Electronics and generated over $630 million in shareholder value as a venture capital investor.
“The recent funding and the move to Silicon Valley will allow us to tap into engineering talent to accelerate our roadmap,” said Levin.
“Security Scoreboard recently introduced new analytics capabilities, which highlight top vendors by user ratings and present trends on site visits”, said Dr. Boaz Gelbord, President and co-founder of Security Scoreboard and himself a practicing security executive. “We are looking to add more sophisticated analysis leveraging user generated data”.   
"The new analytics move Security Scoreboard in the direction from merely showing you what your peers are thinking to making true crowd-based recommendations about which vendor tools to use", said Jay Leek, Vice President of International Security at Equifax.
The company plans to raise additional venture funding later this year.
About Security Scoreboard:
Security Scoreboard is a community generated review and rating site to help security practitioners and executives select the right information security solutions. Security Scoreboard is supported by an Advisory Group and User Council of industry leading CISOs, CIOs and security managers. The site leverages crowd sourced ratings and state of the art analytics to provide recommendations based on real life experiences of other customers.

I am REALLY looking forward to the new era – and I do realize that it will take work!
Possibly related posts:

• “Security Scoreboard” Out! 
• Security Scoreboard Updated

Latest Reviews From Security Scoreboard

www.securityscoreboard.com

11 Log Resolutions for 2011

FYI, this piece has been specially created for LogManagementCentral (original post), an awesome site about logs, log management and SIEM. It is reposted here for posterity.

 

So, behold 11 log resolutions for 2011!!

1. I will turn logging on the systems I manage: this resolution is about the very first step one must take to using log data for many purposes inside and outside of IT – actually having logs. Start 2011 by committing to enabling logging across the systems you manage or oversee. And, yes, “log everything” is not the answer in most environments (and as all oversimplifications, it is often downright silly – e.g. log every SELECT on a database will lead to your DBAs killin’ ya ) – further resolutions help with figuring out how to do it without killing your systems

2. I will create log policy: this resolution helps you to make a commitment to understanding what you need to log on each system and how to do it. Logging policy starts from reviewing compliance requirements and other “use cases” for log data.

3. I will check for when logging stops: one of the simplest ways to commit to having logging in 2011 (and all years thereafter) is to commit to monitoring when logging stops. Apart from being a violation of a few regulatory compliance mandates, termination of logging – whether due to an attacker all by mistake – is something you need to know right when it happens.

4. I will use compliance intelligently: this resolution draws a line between being a checkbox-following “compliance monkey” and being convinced that “compliance is evil.” Regulation such as PCI DSS contain not just motivation but also some useful advice on how to do logging right (some ideas).

5. I will learn what the logs mean: committing to logs is not simply committing to having logs –you have to know what the log messages actually mean and what they are trying to tell you. In 2011, make sure who that you seek to understand what your systems are trying to tell you in their logs and learn to tell routine messages from critical “system-busting ” alerts.

6. I will at least check logs for intrusions, system and account changes and major errors: one cannot make a resolution to analyze logs without starting small first – if you have to look for some will things first, at least commit to check your logs for intrusions, system and account changes and major errors (this checklist can help)

7. I will review logs: generating, centralizing and storing logs is important. These practices a bed of sensible and mandatory (prescribed by many regulatory mandates). However, main log value lies in interpreting, understanding and then acting upon the information present in the logs. You cannot commit to logging excellence without committing to log review – using automated tools (lots of ideas on log review)

8. I will make sure that I have logs preserved after an incident: leads rarely matter more than in a hectic post-incident environment where every bit of data can help understand the origin and impact of the intrusion. Commit to using logs for incident response in 2011! (useful tips on that)

9. I will train my developers to create useful logs: making – and keeping!-a resolution to collect and review logs is impossible if logs do not exist – as it is often the case for your custom applications. In order to gain benefits of logging in such case, you must make a resolution to train your application developers to create useful logs inside their applications. Use emerging standards such as CEE to guide them towards proper logging practices

10. I will stop complaining about how bad logging is at most organizations: everybody starts somewhere, and many organizations start from a truly abysmal state in regards to logging. Start logging – and stop complaining. Go from log ignorance to near-real-time log enlightenment using a process similar to this

11. Finally, I WILL REMEMBER THESE RESOLUTIONS FOR THE ENTIRE YEAR: unlike some security technologies, logging, log review and log monitoring is a lifetime commitment. To get something useful out of log data, you have to log and review data all the time.

Any other logging resolutions you are making for 2011?

Complete PCI DSS Log Review Procedures, Part 18 FINAL

Once upon a time, I was retained to create a comprehensive PCI DSS-focused log review policies, procedures and practices for a large company.  They are focused on PCI DSS compliance, but based on generally useful log review practices that can be utilized by everybody and with any regulation or without any compliance flavor at all. The practices can be implemented with commercial log management or SIEM tools, open source log analysis tools or manually. As you well know, tools alone don’t make anybody compliant!

This is the FINAL, 18th post in the long, long series  (part 1, part 2, part 3 – all parts). A few tips on how you can use it in your organization can be found in Part 1. You can also retain me to customize or adapt it to your needs.

And so we end our Complete PCI DSS Log Review Procedures. Please start reading from Part 1 – at this stage we are deep in the details and these sections might seem out of context without reading earlier parts:

References

The following references are useful for PCI DSS log review program and log management in general:

SANS CAG/CSC

“Twenty Critical Security Controls for Effective Cyber Defense: Consensus Audit Guidelines”

http://www.sans.org/critical-security-controls/

Specifically, the relevant control on audit logs is shown below:

“Critical Control 6: Maintenance, Monitoring, and Analysis of Audit Logs”

NIST 800-92 Logging Guide

“Guide to Computer Security Log Management: Recommendations of the National Institute of Standards and Technology by Karen Kent and Murugiah Souppaya”

http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf

NIST 800-66 HIPAA Guide

“An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule ”

http://csrc.nist.gov/publications/nistpubs/800-66-Rev1/SP-800-66-Revision1.pdf

Appendix A Recommended Logbook Format

Logbook entry:

1. Date/time/time zone this logbook entry was started

2. Name and role of the person starting the logbook entry

3. Reason it is started: log exception (copied from log aggregation tool or from the original log file), make sure that the entire log is copied, especially its time stamp (which is likely to be different from the time of this record) and system from which it came from (what/when/where, etc)

4. Detailed on why the log is not routine and why this analysis is undertaken

5. Information about the system that produced the exception log record or the one this log exception is about

a. Hostname

b. OS

c. Application name

d. IP address(s)

e. Location

f. Ownership (if known)

g. System criticality (if defined and applicable)

h. Under patch management, change management, FIM, etc

6. Information about the user whose activity produced the log (if applicable)

7. Investigation procedure followed, tools used, screenshots, etc

8. Investigative actions taken

9. People contacted in the course of the log analysis

10. Impact determine during the course of the analysis

11. Recommendations for actions, mitigations (if needed)

Follow PCI_Log_Review to see all posts.

Possibly related posts:

• Incident Log Review Checklist
• All posts tagged PCI_Log_Review

Top 10 Things Your Log Management Vendor Won't Tell You

FYI, this piece has been specially created for LogManagementCentral (original post), an awesome resource for all logging things. It is reposted here for posterity.

 

While many people have seen 10 things that your chef, real-estate agent, wedding planner or pilot won’t tell you, the world has not yet seen Top 10 things your log management vendor won't tell you. Finally, this gap is now closed.

 

1. “We talk analytics, but really, most of our customers use us for collection only.” While some products within SIEM and log management offer advanced analytics features, many of their customers are not truly ready for them. They need to start dealing with the basics – logging, log collection, log review before delving into advanced areas. Buying a product based on features you won’t use is a mistake. For example, see “Log Management Before SIEM”

2. “Our tool won’t make you PCI compliant. You’d have to do A LOT of things yourself – every day – to get and maintain compliance.” Sadly, many security solutions – and SIEM / log management are no exception – are sometimes sold as “compliance in a box.” You need to be aware that to stay PCI compliance you need to do more than purchase tools. For example, see “How to Stay PCI Compliant”

3. “No, you cannot buy an entire SOC in this small box.” Just as with compliance, you cannot buy an entire Security Operations Center in a box, big or small. However, some will try to sell you their SIEM as “SOC-in-a-box.” Running an effective SOC includes multiple processes and procedures which are just as necessary as a market-leading SIEM tool

4. “We are cloud-ready, because … mmmmm… well, we are ready for it!” Many vendors will tell you that their tools are cloud-ready – without really thinking what they mean. Effectively monitoring traditional and multi-tenant cloud environments distributed across regions and countries requires more than updated marketing materials. You need to carefully test the tool in your own hybrid environment before concluding that it is “cloud ready”

5. “Our SIEM is really just a renamed log management tool. But that’s all you probably need.” The confusion around SIEM and log management functionality rages on – it also allows some tools to be sold as SIEM without having any critical SIEM functionality such as correlation and real-time dashboards. Even though it might be all many customers need, it does not make such tool a SIEM tool. For additional reading, see this whitepaper.

6. “We can do everything with logs, but it might require some SMALL customizations. Our PS team is standing by!” More than a few SIEM vendors will promise support for every possible log – including logs they have never seen. However, fully integrating a new log source for reporting, correlation and visualization will always takes work and cannot be taken for granted.

7. “If you make a mistake with capacity planning, we’d be happy to sell you more log management than you really need.” Many organizations are having trouble estimating how much log data will be coming into their SIEM or log management tools. Both under as to making and overestimating are common. It is recommended that you spend about a week measuring log volumes across the systems that will be reporting to a SIEM.

8. “We think our tool is scalable, but we don’t really have production customers of your size. Our engineers believe that it might work.” Scalability claims are cheap and would often be made by SIEM and log management vendors. However, the only real proof that the tool will scale to your requirements is testing the tool in your environment. Thus, you should insist on performance testing during the pilot if there are any doubts.

9. “Out tool offers predictive security intelligence. No, we don’t know what it means either – and we can’t really predict it.” SIEM is one of the most over-hyped and over-marketed security technologies out there. The only way to get the tool that satisfies your requirements is too carefully spelled out those requirements and then test the tool yourself.

10. “We estimate our performance using really small log messages sizes.” Yes, our tools can do a million message an instant – but these are our special messages that we create in the lab. Nowadays, application logs and proliferation of XML-based logging has pushed the message sizes up to 1 kb or more from a traditional 200 byte logs from firewalls. Thus, you need to be wary of performance estimates based on such artificially short logs.

So what is your vendor NOT tellin’ ya?

Book Review: “Security Information and Event Management (SIEM) Implementation”

Here is my review for “Security Information and Event Management (SIEM) Implementation” by David Miller, Shon Harris, Allen Harper, Stephen VanDyke, Chris Blask. It has just been published to Amazon as 4 stars out of 5.


I was looking forward to reading this book for a few months – pretty much since the time I’ve heard that it is being written. Obviously, I was very excited when it arrived in my mailbox. Now that I am done reading it, I can say it left a mixed impression. Mostly positive –but still mixed. I definitely enjoyed reading it, despite (or maybe due to) the fact that I’ve been involved with SIEM for nearly 10 years.
Let me first go through all the chapters and then give my overall impression. The book is organized in three big parts: “introduction to SIEM: threat intelligence for IT systems”, “IT threat intelligence using SIEM systems ” and “SIEM tools.”
Chapter 1 covers security basics with minimum connections to SIEM. It might have that over-simplified refresher of what information security is about.
Chapter 2 can be summarized using the quote from the chapter itself: “the bad things that could happen.” It contains another refresher on attacks, somewhat jumbled and somewhat dated. We’re not really touching SIEM yet at this point.
Chapter 3 has an author’s view of regulatory compliance: the usual suspects are mentioned – PCI DSS, HIPAA, FISMA, SB1386, SOX, GLBA, etc. HIPAA is not misspelled which counts as good news
Chapter 4 has a bizarre name: “SIEM concepts: components for small and medium-sized businesses.” It contains an overview of SIEM with little focus on SMB. It is mildly confusing (for example, it calls LogRhythm “a commercial syslog server”). It contains a few outright mistakes as well (like a mention of one log management vendor whose application reportedly covers ”all 228 PCI controls”). The chapter tries to talk about everything (yes, even GRC) and makes a very weak impression.
Chapter 5 looks like a twin of the previous chapter. It also contains an overview of SIEM, but a different one – a better one, in fact. These two chapters don’t contradict each other much, but joint their presence in the book is mysterious and somewhat confusing.
Chapter 6 is a sudden break from SIEM into incident response. It does contain a few useful – but high-level- flow charts for incident response. I doubt that it was written by somebody who did much incident response however.
Chapter 7 is both a curse and a blessing. I loved the ideas in the chapter – using SIEM for BI – but I hated the fact that its author didn’t even bother to check what “SIEM” abbreviation stands for (see page 116)…
Chapter 8 and Chapter 9 are about OSSIM/AlienVault. From all the SIEM product chapters below, these are the weakest and the least useful. They offer little practical guidance and miss – yes, really! – most the details you’d need to know before deploying OSSIM in production. I was especially annoyed by “screenshot-three lines of text-screenshot-three lines of text…” model that most of Ch 8 and Ch 9 follow. It makes pages 152-166 just wasted paper. Ch9 tries to be a bit more useful (has two case studies), but collapses under the load of too many screenshots as well.
Chapter 10 and Chapter 11 talk about Cisco MARS. Since nobody cares about MARS anymore, I won’t be reviewing them here.
Chapter 12 and Chapter 13 cover Q1Labs SIEM. Unlike the above, these are actually useful for practical architecture planning of QRadar deployments. These chapters also contain useful SIEM insights – still, even these can benefit from more real-world tuning tips. The case study in Ch13 is useful as well. If you are thinking of getting a Q1Labs SIEM, grab the book to quickly review what you will encounter when you get the product.
Finally, Chapter 14 and Chapter 15 cover ArcSight SIEM. Despite minor mistakes and “vendor whitepaper feel,” the chapters would be handy for people in early stages of selecting, reviewing and deploying ArcSight SIEM. The chapters suffer a bit from trying to duplicate product help – you’re more likely to learn how to patch ArcSight them how to use it well.. Sadly, no case studies are included in these chapters.
Overall, the book has unfortunate signs of being written by a team of others who didn’t talk to each other. Despite the promises of implementation guidance, it leaves some of the very complex SIEM issues untouched – and even unmentioned. Very few case studies (some good ones are stashed in the appendix for some weird reason) and few tips and tricks for real-world SIEM implementation. Also, it is much stronger on the “what” then on “how.” Still, I suggest that people buying, using and building SIEM products, get their own copy and read at least a few chapters relevant to them. You will likely not be disappointed.

Complete PCI DSS Log Review Procedures, Part 17

Once upon a time, I was retained to create a comprehensive PCI DSS-focused log review policies, procedures and practices for a large company.  They are focused on PCI DSS compliance, but based on generally useful log review practices that can be utilized by everybody and with any regulation or without any compliance flavor at all. The practices can be implemented with commercial log management or SIEM tools, open source log analysis tools or manually. As you undoubtfully know, tools alone don’t make anybody compliant!

This is the 17th, one before last,  post in the long series of 18 posts (part 1, part 2, part 3 – all parts) – this is a very important part as it contains the summary of key periodic operational procedures. Please consider reading from Part 1 – at this stage we are deep in the details and these sections might seem out of context without reading earlier parts. A few tips on how you can use it in your organization can be found in Part 1. You can also retain me to customize or adapt it to your needs.

And so we continue with our Complete PCI DSS Log Review Procedures:

Periodic Operational Task Summary

The following chapter contains a summary of operational tasks related to logging and log review. Some of the tasks are described in detail in the document above; others are auxiliary tasks needed for successful implementation of PCI DSS log review program.

Daily Tasks

The table below contains daily tasks, responsible role that performs them as well as what record or evidence is created of their execution:

Task	Responsible Role	Evidence
Review all the types of logs produced over the last day as described in the daily log review procedures	Security administrator, security analyst, (if authorized) application administrator	Record of reports being run on a log management tool
(As needed) investigate the anomalous log entries as described in the investigative procedures	Security administrator, security analyst, (if authorized) application administrator	Recorded logbook entries for investigated events
(As needed) take actions as needed to mitigate, remediate or reconcile the results of the investigations	Security administrator, security analyst, (if authorized) application administrator, other parties	Recorded logbook entries for investigated events and taken actions
Verify that logging is taking place across all in-scope applications	Application administrator	Create a spreadsheet to record such activities for future assessment
(As needed) enabled logging if disabled or stopped	Application administrator	Create a spreadsheet to record such activities for future assessment

Weekly Tasks

The table below contains weekly tasks, responsible role that performs them well as what record or evidence is created of their execution:

Task	Responsible Party	Evidence
(If approved by a QSA) Review all the types of logs produced on less critical application over the last day as described in the daily log review procedures	Security administrator, security analyst, (if authorized) application administrator	· Record of reports being run on a log management tool. · Record of QSA approval for less frequent log reviews and reasons for such approval
(As needed) investigate the anomalous log entries as described in the investigative procedures	Security administrator, security analyst, (if authorized) application administrator	Recorded logbook entries for investigated events
(As needed) take actions as needed to mitigate, remediate or reconcile the results of the investigations	Security administrator, security analyst, (if authorized) application administrator, other parties	Recorded logbook entries for investigated events and taken actions

Monthly Tasks

The table below contains daily tasks, responsible role that performs them as well as what record or evidence is created of their execution:

Task	Responsible Party	Evidence
Prepare a report on investigated log entries	Security analyst, security manager	Prepared report (to be filed)
Report on observed log message types	Security analyst, security manager	Prepared report (to be filed)
Report on observed NEW log message types	Security analyst, security manager	Prepared report (to be filed)
(If approved by a QSA) Review all the types of logs produced on non-critical applications over the last day as described in the daily log review procedures	Security administrator, security analyst, (if authorized) application administrator	· Record of reports being run on a log management tool. · Record of QSA approval for less frequent log reviews and reasons for such approval
(As needed) investigate the anomalous log entries as described in the investigative procedures	Security administrator, security analyst, (if authorized) application administrator	Recorded logbook entries for investigated events
(As needed) take actions as needed to mitigate, remediate or reconcile the results of the investigations	Security administrator, security analyst, (if authorized) application administrator, other parties	Recorded logbook entries for investigated events and taken actions

Quarterly Tasks

The table below contains daily tasks, who performs them as well as what record or evidence is created of their execution:

Task	Responsible Party	Evidence
Verify that all the system in scope for PCI are logging and that logs are being reviewed	Security analyst, security manager	Recorded logbook entries for review and exception follow-up
Review daily log review procedures	Security analyst, security manager	Updates to logging procedures; change log
Review log investigation procedures	Security analyst, security manager	Updates to logging procedures; change log
Review collected compliance evidence	Security analyst, security manager	Compliance evidence; evidence review log
Review compliance evidence collection procedures	Security analyst, security manager	Updates to procedures; change log

Annual Tasks

The table below contains daily tasks, who performs them as well as what record or evidence is created of their execution:

Task	Responsible Party	Evidence
Review logging and log review policy	CSO	Policy changes; change log; policy review meeting minutes
Review compliance evidence before the QSA assessment	PCI DSS compliance project owner	Meeting minutes or other record
Live tests with anomalies	As needed	Logs or other records of such tests

To be continued.

Follow PCI_Log_Review to see all posts.

Possibly related posts:

• Incident Log Review Checklist
• All posts tagged PCI_Log_Review

Complete PCI DSS Log Review Procedures, Part 16

Once upon a time, I was retained to create a comprehensive PCI DSS-focused log review policies, procedures and practices for a large company.  They are focused on PCI DSS compliance, but based on generally useful log review practices that can be utilized by everybody and with any regulation or without any compliance flavor at all. The practices can be implemented with commercial log management or SIEM tools, open source log analysis tools or manually. As you undoubtfully know, tools alone don’t make anybody compliant!
This is the 16th post in the long series  that is nearing the end (part 1, part 2, part 3 – all parts). A few tips on how you can use it in your organization can be found in Part 1. You can also retain me to customize or adapt it to your needs.
And so we continue with our Complete PCI DSS Log Review Procedures (please consider reading from Part 1 – at this stage we are deep in the details and these sections might seem out of context without reading earlier parts):

Management Reporting

In addition for compliance evidence, validation activities can be used to report the success of a log management program, processes and procedures to senior management. The data accumulated in the above sections as proof of organization-wide PCI DSS compliance can also be used for management reporting. Specifically, the following are useful reports that can be produced from the data:
· Presence and adequacy of logging
o Percentage of all systems / regulated data systems covered by logging (the latter should be 100%)

· Presence of defined  log review processes and their implementation
o Log policy and procedure changes
o Application under log review
o Log entries reviewed

· Exception handling process and its implementation
o Log exceptions handled by type, analyst name, etc
o Exception escalated to incident response
o (if relevant) Risk reduced due to timely escalation or incident prevention
o Resources saved due to timely escalation or incident prevention
o Application performance improvement due to log review

· Other log management program reporting
o Overall compliance readiness (PCI DSS and other)

Finally, let’s summarize all periodic operational tasks the organization should be executing in connection with log review.
To be continued.
Follow PCI_Log_Review to see all posts.
Possibly related posts:

• Incident Log Review Checklist
• All posts tagged PCI_Log_Review

SANS SEC434 Log Management Class is Back–Jan 27-28, 2011 in Sacramento, CA

We are doing ONE LAST BETA for my log management class (1/2 price) in Sacramento again. Info and where to sign up are below:
Class name:  Log Management In-Depth: Compliance, Security, Forensics, and Troubleshooting
Class dates:
Thursday, January 27, 2011 - Friday, January 28, 2011 :
Day 1: 9:00am - 5:00pm
Day 2: 9:00am - 12:00pm
Class location:
CalPERS
400 Q Street, East Building Room 1733
Sacramento, CA 95811
Class description (source):

This first-ever dedicated log management class teaches system, network, and security logs, their analysis and management and covers the complete lifecycle of dealing with logs: the whys, hows and whats.
You will learn how to enable logging and then how to deal with the resulting data deluge by managing data retention, analyzing data using search, filtering and correlation as well as how to apply what you learned to key business and security problems. The class also teaches applications of logging to forensics, incident response and regulatory compliance.
In the beginning, you will learn what to do with various log types and provide brief configuration guidance for common information systems. Next, you will learn a phased approach to implementing a company-wide log management program, and go into specific log-related tasks that needs to be done on a daily, weekly, and monthly basis in regards to log review and monitoring.
Everyone is looking for a path through the PCI DSS and other regulatory compliance maze and that is what you will learn in the next section of the course. Logs are essential for resolving compliance challenges; this class will teach you what you need to concentrate on and how to make your log management compliance-friendly. And people who are already using log management for compliance will learn how to expand the benefits of you log management tools beyond compliance.
You will learn to leverage logs for critical tasks related to incident response, forensics, and operational monitoring. Logs provide one of the key information sources while responding to an incident and this class will teach you how to utilize various log types in the frenzy of an incident investigation.
Finally, the class author, Dr. Anton Chuvakin, probably has more experience in the application of logs to IT and IT security than anyone else in the industry. This means he and the other instructors chosen to teach this course have made a lot of mistakes along the way. You can save yourself a lot of pain and your organization a lot of money by learning about the common mistakes people make working with logs.

Class is beta: SANS gives you a 50% discount and you provide detailed feedback:

This is a special beta course whose materials are still being fine-tuned. We are offering it at a discount at this event in exchange for the students' detailed feedback, which will help us improve and finalize the course's content and exercises.

Note this laptop requirement: no MacOS, no VMWare.

A laptop with Windows XP or later or recent Linux operating system installed which can unzip/gunzip compressed files. CD/DVD drive is required. MacOS is not acceptable.

Sign-up please; the class already has enough people which suggests that  it will not be cancelled, like the last one in LA.

JOB: SIEM Architect at RSA

As a favor to yet another friend, I am posting yet another SIEM-related job. IMHO, it is an ideal position for a good architect looking to jump ship from a failing or “non-performing” SIEM vendor:

The RSA Security’s fast-growing  Security Management group is looking for the best technical minds to develop the next generation of Security Information and Event Management (SIEM) software.  We are building a great organization with talented employees with the highest ethical and professional standards who deliver a portfolio of products to enable our customers to protect their information assets.

Ideal candidate will have broad knowledge of IT security with proven ability to architect and build complex enterprise systems.  You must enjoy working in a rapidly-changing, high-pressure environment spanning multiple geo locations. As a lead architect, you will exert significant influence over the technical strategy and the architectural definition of the next generation of RSA’s Security Management products.  Practical experience in one of the following areas is required: large-scale database systems, real-time design, network monitoring and analysis.

This position is full-time, based in Bedford, MA. If you are interested in joining the Security Management group in RSA, please send your inquiry or resume to Lauren Day at  lauren.day@emc.com or 978-686-2234.

… and somebody now owes me beer at RSA 

Possibly related posts:

• SIEM-related Job: Principal SIEM Consultant 
• SIEM-related Product Management Job: Atlanta, GA
• All jobs posts on my blog

Annual Blog Round-Up – 2010

If monthly, why not annual blog round-up? These are my top popular "Security Warrior" blog posts for the entire 2010. This list covers the posts most popular in 2010, not necessarily only those written in 2010.

So, the list:

1. “Simple Log Review Checklist Released!” made BY FAR the biggest splash last year. The checklist, a list of critical things to look for while reviewing  system, network and security logs when responding to a security incident,  now has a dedicated page (securitywarriorconsulting.com/logchecklist/) and you can grab an updated versions there
2. Checklist has a companion tool list of a popular free open-source log management and log analysis tools, which is also on the top list for 2010. It was posted to my blog (“On Free Log Management Tools”) as well as to a dedicated page (securitywarriorconsulting.com/logtools/)
3. “On Choosing SIEM” is next in my top post chart. It helps to determine “What is the least wrong way [of choosing a SIEM or log management product] which will actually get used in real-life?”  Sadly, people  seems unwilling to use the right way for a set of reasons…
4. A carryover from last year, the quest for open source SIEM continues! In fact, a few top posts on my blog in 2010 (as well as 2009) resulted from search queries for “open source SIEM” – and now “open source log management.”  They are: “Why No Open Source SIEM, EVER?” , “On Open Source in SIEM and Log Management”  and “Short Observation on Open Source SIEM”
5. “Updated With Community Feedback SANS Top 7 Essential Log Reports DRAFT2”, “SANS Top 5 Essential Log Reports Update!” and their predecessor  “Top5 SANS Log Reports Update DRAFT” also show up close to the top. Now that I have a bit more time, I will finally finish the write-up and submit it to SANS for distribution… look the final version in January 2011.
6. “The Myth of SIEM as “An Analyst-in-the-box” or How NOT to Pick a SIEM-II?” with 7 reasons why SIEM is NOT “an analyst in the box” – and never can be. “SOC in the box”? Bua-ha-ha-ha, come on, let’s be reasonable here
7. “My Best PCI DSS Presentation EVER!” covers my keynote experience at  PCI DSS Workshop 2010 by Treasury Institute for Higher Education (the other keynote being Bob Russo, naturally) – the presentation is embedded in the post
8. “How Do I Get The Best SIEM?” is another SIEM selection advice post that made the top chart. It sure seems like 2010 was a year when a lot of organizations were looking for SIEM tools…
9. ““I Want to Buy Correlation” or How NOT to Pick a SIEM?” … guess what it is about? Yup, selecting a SIEM tool.
10. It is amazing that something posted in November made the “year’s best” list. Still, “Complete PCI DSS Log Review Procedures, Part 1” and the whole series (which would be completed in early 2011) is among the most read posts for the entire 2010.

See you in December 2011 when I will post the next annual blog round-up; see my previous annual “Top Posts” -2007, 2008 and the monthly top posts below.

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

• Monthly Blog Round-Up – December 2010
• Monthly Blog Round-Up – November 2010
• Monthly Blog Round-Up – October 2010
• Monthly Blog Round-Up – September 2010
• Monthly Blog Round-Up – August 2010
• Monthly Blog Round-Up – July 2010
• 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

Monthly Blog Round-Up – December 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 this month.

1. Obviously, my PCI DSS log review procedures that I created for a consulting client and started posting on the blog (sanitized, of course!)  took the #1 spot: the first post “Complete PCI DSS Log Review Procedures, Part 1” and the whole series “PCI_Log_Review” are expected to be useful to most large organization  under PCI DSS
2. Just as last month, one of the top positions is again held by my repost of my free log management tool list (“On Free Log Management Tools”) from my consulting site. The original version was written as a companion to our “Log Review Checklist” that also sits on the top list this month.  BTW, my other  checklist, “Log Management Tool Selection Checklist Out!”  is also in the top chart. It can be used to compare log management tools during the tool selection process or even formal RFP process
3. Surprisingly, “Novell Bought–What Happens in SIEM?” takes the next spot. The post contains my quick market analysis and some strategy choices related to SIEM market impact of Novell acquisition
4. “Checking My 2010 Security Predictions” contains my self-assessment of security predictions I made back in early 2010.
5. Finally, “Random Fun Highlights from PCI DSS 2.0 …” originated from my reading the new version of PCI DSS and taking some notes. Feel free to read it to quickly get “what’s new?” in PCI DSS 2.0

Also, below I am thanking my top 3 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. Walt Conway
2. Raffy Marty
3. Stephen Bradshaw

First, see you in a day or so when I post the list of most popular blog posts in the entire 2010 (also see my past annual “Top Posts” - 2007, 2008,  2009). Next, see you later in January for the next monthly top list.

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

• Monthly Blog Round-Up – November 2010
• Monthly Blog Round-Up – October 2010
• Monthly Blog Round-Up – September 2010
• Monthly Blog Round-Up – August 2010
• Monthly Blog Round-Up – July 2010
• 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