Monday, January 31, 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

Monday, January 24, 2011

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?

Wednesday, January 19, 2011

Don’t I love overly dramatic headings? Yup, I do.
Pretty much since the day Security Scoreboardlaunched, 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:

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.

Wednesday, January 12, 2011

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:

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)

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.

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.

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.

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.

Friday, January 07, 2011

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):

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%)

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:

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.

Wednesday, January 05, 2011

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.

Tuesday, January 04, 2011

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.

“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…

Saturday, January 01, 2011

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.

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.

About Me

He is a recognized security expert in the field of log management and PCI DSS compliance. He is an author of books "Security Warrior", "PCI Compliance", "Logging and Log Management" and a contributor to "Know Your Enemy II", "Information Security Management Handbook" and others. Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security management, honeypots, etc . His blog securitywarrior.org was one of the most popular in the industry.

In addition, Anton teaches classes (including his own SANS class on log management) and presents at many security conferences across the world; he recently addressed audiences in United States, UK, Singapore, Spain, Russia and other countries. He worked on emerging security standards and served on the advisory boards of several security start-ups.

Before joining Gartner in 2011, Anton was running his own security consulting practice www.securitywarriorconsulting.com, focusing on logging and PCI DSS compliance for security vendors and Fortune 500 organizations. Dr. Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a Chief Logging Evangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by a security vendor in a strategic product management role. Anton earned his Ph.D. degree from Stony Brook University.