Dr Anton Chuvakin Blog (Original)

Friday, July 02, 2010

Monthly Blog Round-Up – June 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.

By a HUGE margin again, the #1 post this month is “Simple Log Review Checklist Released!” Grab our log review checklist here, if you have not done so already. It is perfect to hand out to junior sysadmins who are just starting up with logs. Another similar resource is in the works… If you are a vendor, you can also use it to market your logging awesomeness :-) - but you have to keep the attribution to the authors.
“How Do I Get The Best SIEM?”, a companion to “On Choosing SIEM“, went to the top like lighting last month 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.
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)
“How PCI Leads to DLP?” discusses the linkage between PCI DSS compliance and Data Leak/Loss Prevention/Protection (DLP) tools. And, no, PCI DSS won’t mandate DLP soon – but it doesn’t mean that you should not look at it for various PCI-related reasons.
“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?” 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.

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:

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

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

Friday, June 25, 2010

SANS Log Management Class in California?

This post is not just an announcement; it contains a BIG question to my readers, mostly in California and around.

As you know, I have authored a SANS Log Management Class (SEC434) which is almost out of beta and near production stage, after a few years of tuning and trial runs. We are thinking of teaching it in California during the second week of August 2010. Via this blog post, I wanted to get some quick feedback from my readers about how many might want to sign up for it. So, please just leave a comment here if you’d like to attend!

Also, I wanted to check whether anybody’s employer (a log management or SIEM vendor perhaps…) would be willing to provide a venue to teach a class. We just need a room with a projector, nothing fancy. In exchange for that, SANS will give you some free attendance seats for the class. So, drop me an email, DM or something, if you’d like to take this opportunity.

The updated information on the class follows below:

“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.”

P.S. Response to comments might be delayed, I am away from my computers.

Possibly related posts:

Wednesday, June 23, 2010

SLAML 2010 Log Analysis Workshop

This year, Workshop on the Analysis of System Logs (WASL) is reborn as SLAML. Please consider submitting a short paper (no need to do a full academic write-up!). The deadline is July 11.

“Join us in Vancouver, BC, Canada, October 2–3, 2010, for the Workshop on Managing Systems via Log Analysis and Machine Learning Techniques. Modern large-scale systems are challenging to manage. Fortunately, as these systems generate massive amounts of performance and diagnostic data, there is an opportunity to make system administration and development simpler via automated techniques to extract actionable information from the data. SLAML '10 workshop addresses this problem in two thrusts: (i) the analysis of raw system data logs and (ii) the application of machine learning to systems problems. The large overlap in these topics should promote a rich interchange of ideas between the areas.

SLAML '10 combines the Workshop on the Analysis of System Logs (WASL) and the Workshop on Tackling Computer Systems Problems with Machine Learning Techniques (SysML)."

The part related to logs is:

“Log Analysis: It is well known that raw system logs are an abundant source of information for the analysis and diagnosis of system problems and prediction of future system events. However, a lack of organization and semantic consistency between system data from various software and hardware vendors means that most of this information content is wasted. Current approaches to extracting information from the raw system data capture only a fraction of the information available and do not scale to the large systems common in business and supercomputing environments. It is thus a significant research challenge to determine how to better process and combine information from these data sources.”

The topics sought are:

“Topics include but are not limited to:

Reports on publicly available sources of sample system logs
Prediction of malfunction or misuse based on system data
Statistical analysis of system logs
Applications of Natural-Language Processing (NLP) to system data
Techniques for system log analysis, comparison, standardization, compression, anonymization, and visualization
Applications of log analysis to system administration problems
Use of machine learning techniques to address reliability, performance, power management, security, fault diagnosis, scheduling, or manageability issues
Challenges of scale in applying machine learning to large systems
Integration of machine learning into real-world systems and processes
Evaluating the quality of learned models, including assessing the confidence/reliability of models and comparisons between different methods”

Please submit to advance the state of log analysis research! Past workshop information is here (2008, 2009).

P.S. This is posted by a scheduler; response to comments may be delayed since I might be away from computers.

Possibly related posts:

Monday, June 21, 2010

Ultimate Security Survey is ON!

Securosis folks are starting off a new data security survey “focused on evaluating perceived effectiveness of various controls, as well as some other incident data.” In other words, they are starting The Holy Grail of Security Surveys: how/why what we do works or fails. It only takes about 10-20 minutes to complete – but can provide hugely useful data.

Please participate!

The survey is available at http://www.surveymonkey.com/s/datasec2010

If asked for a code, enter "SecurosisAwesome"

Enjoy!

Wednesday, June 16, 2010

How PCI Leads to DLP?

By now, it is increasingly obvious that PCI DSS does not (and likely will not) mandate the use of Data Leak Prevention (DLP) technology now or in the near future. This applies to both discovery and monitoring/enforcement aspects of DLP. However, I am hearing that the percentage of DLP deployments driven by PCI DSS compliance is rising. What’s the story with that?
While a certain percentage of such deployments simply point “in the general direction of PCI” to get budget (huh…nothing wrong with that :-)), I’d like to comment on the fact that DLP often makes a decent compensating control for many PCI DSS requirements.

PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance

First, unless you read the PCI book already, read Branden’s chapter on the Art of Compensating Control (this paper [PDF] has some of the same coverage).
So, here is where I have seen DLP boxes used as compensating controls (warning: evidence of QSA actually accepting it was not available in all cases, so use this advice at your own risk)

Stored data encryption (Requirement 3.4 “Render PAN, at minimum, unreadable anywhere it is stored”): DLP was used to compensate for the lack of STORED data encryption. The thinking was that if the data cannot leave the storage (…via the network), DLP was satisfying the same intent as encryption in the original requirement. Would I agree that “it goes above and beyond” the original? Good question :-)
Access control (Requirement 7.1 “Limit access to system components and cardholder data to only those individuals whose job requires such access.”): DLP was used to reduce the chance of PANs falling into the wrong hands and thus satisfying the spirit of this requirement.
Monitoring access to data (Requirement 10.2 “Implement automated audit trails for all system components to reconstruct the following events: […] All individual accesses to cardholder data”): while logging is a common choice here, DLP was used to make sure that all network access to cardholder data is recorded. The reason for choosing DLP over logging was due to the fact that the company didn’t know how to configure logging, but knew how to buy a DLP box :-)

Others examples of auxiliary use of DLP for PCI DSS included verifying that Requirement 4.1 (“Use strong cryptography and
security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks”) is indeed being followed. In this case, DLP served as a glorified PAN sniffer.
On top of this, the discovery components of DLP tools are often used for scoping. See some fierce debate on this issue, referenced from here. To summarize, the use of DLP and standalone data discovery tools for PCI scoping is certainly not mandatory, but very helpful. On top of this, one can use a DLP system to make sure that scope does not explode when people pull card data from the payment environment to development, QA, etc, etc.
Finally, I see the fact that PCI-motivated use of DLP tools is growing as something positive. To me it says that people are following the spirit of DSS and not simply its letter (of course, one can also say that they are reaching for a DLP box as an easy way out). Indeed, despite everything that was said above, deleting cardholder data is still a better way to make sure it does not get stolen or “lost”…
(also, as a disclosure, I serve on an advisory board of a DLP company, nexTier Networks that has a product called Compliance Enforcer)
Possibly related posts:

On DLP, PCI and QSAs
Fun Views on DLP
DLP Works – If You Know What “Works” Mean!
A Few More Words on DLP and Compliance
So, CAN We Have DLP?
In Passing on DLP
All posts labeled DLP

Saturday, June 12, 2010

How Do I Get The Best SIEM?

Given that I spent this entire week getting back into a SIEM-building game [don’t ask :-)], a few thoughts on the state of Security Information and Event Management have dawned on me.

Some security technologies – like network firewalls - are getting pretty darn close to being commoditized and differences between products are ever-so-close to being wiped out.

SIEM, let me tell you, is nowhere near this. Maybe this also has something to do with the fact that Gartner SIEM MQ 2010 (see this fun commentary from Rocky and his view on SIEM history) contain so many players for so many years. To follow up on this, here is a fun quote from Gartner MQ on SIEM: “There are signs of general convergence on a core set of [SIEM] capabilities.”

Do you know WHEN the above was written? March 2003!

2003! In other words, full 7 (!) years after first SIEM products were built. And also - full 7 (!) years ago. Look to the right to see how SIEM realm looked back then [yes, Brian, I just reread all SIEM MQs from 2003 to 2010 – just for fun :-)]

Today, in 2010, there is still NO “best SIEM for everybody” and there is NO feature parity even across key capabilities.

Yes, there is a SIEM tool that seems better for large enterprises with unlimited budget. But overall “best SIEM"? Nope.

In fact, I bet that …

If you pick five top SIEM requirements AND 5 “top” SIEM vendors, then at least one of the tools will REALLY SUCK on at least one of the key requirements.

The reality is that after so many years, all – well, most - SIEM tools actually “run” - but do they always “work?” Let me explain the difference between a software that RUNS from the one that WORKS. “Runs” means that code compiles and, when executed, does not throw an exception. On the other hand, “works” means that it delivers value to its buyer. For example, rule-based correlation runs (well, unless it runs out of memory…oops!), but doesn’t work in many environments (see recent Securosis piece on that). Real-time dashboards run, but aren’t even utilized in many environments. Visualization tools run, but often users cannot get them to work. Risk scoring / statistical correlation runs, but often doesn’t deliver useful results.

And you known, believe it or not, SIEM vendors are NOT the ones to blame for it. Many are honest in saying that “Yes, to succeed, a SIEM project takes work BY it’s buyer/user.” So, your SIEM likely will WORK, if you WORK on it.

Now, let’s turn this into something practical and useful? What’s a poor SIEM buyer – whether enterprise or mid-market - to do? How to pick the right SIEM?

The only choice I see is the one that won’t surprise my readers: focus on requirements, define your SIEM use cases – and then test the products. Buy the one that WORKS FOR YOU! Some ideas on the selection process can be found here.

Enjoy!

Possibly related posts:

Tuesday, June 01, 2010

Monthly Blog Round-Up – May 2010

Blogs are "stateless" and people often only pay attention 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 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.

By a HUGE margin again, the #1 post this month is “Simple Log Review Checklist Released!” Grab our log review checklist here, if you have not done so already. It is perfect to hand out to junior sysadmins who are just starting up with logs. Another similar resource is in the works…
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)
Everybody loved my whitepaper on SIEM+ log management, released via the post called “Two New Logging Resources Published.” Check out the paper here (registration with Novell required). Just as a preview, another big research whitepaper on SIEM is in the works….
A recent post “On Choosing SIEM“ went to the top like lighting last month and stayed there this month. If you are thinking of getting a SIEM or a log management tool, check it out – please also look at related resources there at the end.
Proving that all SIEM/LM vendor product managers read this blog, the post “Log Management / SIEM Users: “Minimalist” vs “Analyst”” is in the Top5 too. It is about two vastly different types of people who buy and [try to] use SIEM and log management tools.
Just for a good measure, the item #6 of my Top 5 :-) is “Compliance Mega-Epiphany!”

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:

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

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

Sunday, May 30, 2010

SIEM-related Product Management Job: Atlanta, GA

As a favor to a friend, I am posting this job ad, related to SIEM, log management and MSSP.

This Product Manager role will primarily be responsible for SecureWorks next-generation correlation and analysis offering.

“This is a mid-level position reporting to the Vice President of Product Management. This position involves responsibility for defining new service lines as well as managing existing service lines. It is a highly visible position with enhanced opportunity for career growth.

In this role, you will drive product strategy and planning for your services and will lead the matrix team responsible for delivering these service lines. Your focus will be to work with the VP of Product Management and the Chief Marketing Officer to develop a compelling vision for your service and to execute, measure, and adjust the strategy accordingly. You must have experience in security technologies, enterprise and commercial markets, and ideally managed services. You would use your client input, market knowledge, and experience to define product plans and product requirements for services that will be highly competitive in the market and can be delivered efficiently through our Security Operations Center.”

All details and how to apply here.

So, if you end up getting hired, make sure to remember to buy me a beer :-)

Friday, May 28, 2010

Recent SIEM/Log Management Webcast Q&A

A few weeks ago week I did this fun webcast with NitroSecurity (recording) on Log Management and SIEM; here are some belated Q&A we got there:

Q1: Is it Security Incident Event Management or Security Information and Event Mgmt?

A1: SIEM stands for Security Information and Event Management. But please shoot whatever market analyst who first mistook ‘information’ for ‘incident’

Q2: What is the level of personnel resources are needed to maintain a SIEM?

A2: This is what is known as "one million dollar question” :-) First, it depends on your SIEM “use cases” – essentially on what you plan to accomplish using a SIEM. You can read “SIEM Bloggables” to see some of the high-level usage scenarios. For example, you might acquire and use a SIEM for reviewing compliance reports once a month. In this case, your personnel requirement will probably not exceed a few hours of 1 FTE. On the other extreme, you might be building a Security Operations Center (SOC) for a global enterprise based on a SIEM. In this case, you might be looking at dozens of people of varying skill levels, from junior analyst to senior SOC managers.

Q3: Please explain chain of custody.

A3: Wikipedia’s definition is just fine, see: http://en.wikipedia.org/wiki/Chain_of_custody. In brief: “Chain of custody (CoC) refers to the chronological documentation or paper trail, showing the seizure, custody, control, transfer, analysis, and disposition of evidence, physical or electronic.”

Q4: How long does PCI DSS require logs to be kept?

A4: As per PCI DSS v 1.2.1 Requirement 10.7: “Retain audit trail history [A.C. – i.e. logs] for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up).” A typical SIEM or log management tool can hold 90 days of data with up to 1 year available in file backups.

Q5: Does adding context/content sources slow the SIEM down?

A5: It depends on the SIEM. Some of the commercial products are slow even without anything being added to them :-) Others can handle extreme event loads. So, the only way to know for sure is to use it in your environment, with your log data and with your context data (assets, vulnerabilities, user roles, etc).

BTW, slides similar to those I used at the webinar are posted at Slideshare and embedded below:

Making Log Data Useful: SIEM and Log Management Together

View more presentations from Anton Chuvakin.

Enjoy!

Possibly related posts:

Monday, May 24, 2010

Fun Reading on Security and Compliance #25

Here is an issue #25 of my “Fun Reading on Security and Compliance,” dated May 24, 2010 (read past ones here). You can judge by its size that my “2blog” folder has been way too full, since I was too busy working on a few fun consulting projects.

Main section:

Fun piece from my co-author (“PCI Compliance”) Branden: “Compliance, Easier Than Security!”
CloudAudit (former A6WG) goes ahead full-steam: “Q&A: CloudAudit targets automated risk assessment, management” (I suspect this is where we’d go for practical guidance in a few years … not to CSA [PDF]) BTW, CSA did release its cloud compliance control matrix a while ago and it is used by CloudAudit.
I dunno why, but I forgot to highlight Alex’s awesome BSides presentation on…risk management: “Risk Management - Time to blow it up and start over?” (now you know that my 2blog folder has been rotting since March 2010 :-))
Worthwhile posts from Securosis: “Mogull’s Law”, “LHF: Quick Wins with DLP—the Conclusion”, “Announcing NetSec Ops Quant: Network Security Metrics Suck. Let’s Fix Them” , “Help Build the Mother of All Data Security Surveys” and their discoveries regarding PCI Level 4 merchants "Level 4 Apathy"
In addition, Securosis folks started a series on SIEM (a must): "Understanding and Selecting SIEM/Log Management: Introduction" "Understanding and Selecting SIEM/LM: Use Cases, Part 1", "Understanding and Selecting SIEM/LM: Use Cases, Part 2", "Understanding and Selecting SIEM/LM: Business Justification"
Notable pieces from FUDSec: ”The Broken Windows Economics of IT Security” , “SCSOVLF (aka, the Shpantzer Coma Scale Of Vendor Lameness and FUD)” (quote: “If, when asked, "How do you approach the APT issue, exactly?" they respond "That's on our roadmap"”)
Fun posts from Richard: “Time and Cost to Defend the Town”, “Forget ROI and Risk. Consider Competitive Advantage” (a fresh batch of ROI jokes inside)
Famous Forrester “too much compliance” study (notes, full PDF) , a must read!
Gunnar’s “10 Quick, Dirty and Cheap Things to Improve Enterprise Security” that I should have highlighted earlier (and of course: “8. Improve your Audit Logging”…)
Completely awesome presentation on REAL cloud security from Alex Stamos @ SourceBoston (was one of my favorite at Source)
Interesting report on web ownage from Dasient (disclosure: I am an advisor). Quote: “We found that 97% of Fortune 500 web sites are at a high risk of getting infected with malware due to external partners. In fact, Fortune 500 web sites have such a high risk because 69% of them use external Javascript to render portions of their sites and 64% of them are running outdated web applications.” Niiice.
InfoSecMentors (site, blog) launched off the ideas from the SourceBoston mentorship panel.
The Security FAIL Chronicles launched (site); “the purpose of this site is to document security failures in various technologies.” Note to self: I need to get my KilledBySoftware site finally up… :-)
SANS produces a mid-year list of security predictions for 2011-2012. Why now? I don’t know, but the predictions are always fun.
“How to Kick Ass in Information Security — Hoff’s Spritually-Enlightened Top Ten Guide to Health, Wealth and Happiness”...awesomely hoffistic piece.
Please don’t laugh but do check the calendar (the year part): people…still…ask…questions…what…ports…to block…on…a firewall! On a list where Marcus Ranum lurks. If this is not the best way to have you balls flattened, I don’t know what is.
Upon leaving security (!), Mark Curphey reposted all his Security Bullshit cartoons here.
A great, though-provoking piece from Michal Zalewski "Security engineering: broken promises"

Logging, log management section and SIEM section:

“Using OSSEC for the forensic analysis of log files” – OSSEC is mostly for real-time log analysis, but now you can also analyze stored logs
Useful list of windows event IDS that record application install/updates, such as “1005 Install operation initiated a reboot” and all others.
Gorka Sadowski has a useful bit on various logs here (especially read the part about anti-virus logs)
Rocky has a series of fun posts on SIEM that you need to read: "SIEM Evolution: Chapter 1" , "2010 Gartner MQ for SIEM" (with a lot of fun MQ analysis), "Tetragon of Prestidigitation".
“Centralized vs. Distributed Syslog System Architectures” about exactly what it says :-)
This fits under both PCI DSS and logging so, “log data revisited” is worth a read (it mentions 70TB of log data which is always juicy): “The second thing we hear most often is, “We only look at log data when we have a problem.” Typically what this means is that the problem has now grown to the size of a whale and has become noticeable by end users who are complaining.”
“Building a logging VM – syslog-ng and Splunk”
A really old log trick that people need to be reminded of: “How to Protect Your Logs from Tampering”
SANS ISC on application logs explains deep suckage of [most] application logs: “dear developer, please spare us the debug log that got swiftly re-branded into "audit log" five minutes before project completion.”
My “PCI Logging HOWTO, Part 2” (part 1). While we are on this subject, here is a fairly useful list on what to log for PCI DSS on Windows.
Another “you have no logs – when you REALLY need them” horror story: “ERP billing systems that did zero audits (total breach of SarOx) due to performance constraints and lack of vendor know how on what to implement let alone how.”
I've long whined about firewall "connection allowed" logs (example), LogLogic folks reminder everybody about their value again: "Do your "Traffic Allowed" logs sing?"
Another bit on SIEM "SIEM: The good and the bad - Part I" with SIEM basics. Key quote "I believe SIEM's will be as common as firewalls within 5 years. " (let’s see whether it will happen this way!)
Well-spelled out example of what one organization are looking for in a SIEM/log management tool: "Open Source centralized log management/SIEM solutions"
Bloor folks also unleashed a salvo in a direction of SIEM - their angle is SIEM as information management solution: "The problem with SIEM 1" and "The problem with SIEM 2" Quote: "… analytic warehouses are currently capable of ingesting data much faster than any of the SIEM products. In our survey the highest load rates we found were at around 4TB per day: analytic warehouses can often load that much per hour!"
SIEM implementation lessons video.

PCI DSS section:

“PCI And Cloud Computing: It’s All About Scope” …PCI DSS + clouds = what else do you need? :-)
Fun interview with me on PCI DSS. Quote: “Q: Where do you see the PCI compliance industry in five years? A: To be honest, I don’t want to see “PCI compliance industry” at all: not now, not in a year, not to five years. […]”
“Undergoing a PCI Assessment – How to Prepare” and “PCI Onsite Assessment - Part 1” (also “Part Two - Preparation for an onsite assessment and what to do first!” and all the way to “Part Five - Selecting a QSA!”)
Please take a good swig from the bottle of no less than 60 proof alcohol before reading this. EXTREME RAGE ALERT! :-)
A really good Forbes piece on PCI: “The easiest way for small businesses to address the information security requirements imposed by credit card companies is the wrong way. I'm talking about lying and praying.” and a quote from me: “Businesses that endanger their customers really do deserve to die.”

Enjoy!

Possibly related posts:

Wednesday, May 19, 2010

Compliance Mega-Epiphany!

After spending a week at an amazing Project Honeynet 2010 Annual “Get-together” in Mexico City, I realized that the workshop environment was missing one big thing: nobody ever mentioned COMPLIANCE (!!!). Yes, the pink elephant in the room was …not in the room – no trace of it, not even a whiff of compliant elephant dung.

The discussions covered malware (mostly bots, but also Conficker, of course), malware reversing, attacker behavior, distributed data analysis, intelligence gathering, log analysis (see the class that I gave there) – but not compliance. As a result, my brain got completely drained of all compliancy (and, no, the fact that I had to then fly to give my PCI DSS keynote didn’t stop it from draining).

And then I had A COMPLIANCE EPIPHANY.

You see, compliance has no value. [this would be a good moment to say that this gets a Captain Obvious 2010 award :-)] None! If somebody offers you “ROI for compliance,” just smile and kick them in the nuts. Hard! Then smile again. And if you are feeling generous, do it again! Again!!

Let me rephrase it: regulatory compliance has no intrinsic value. Just as a seatbelt law that fines you $30 for not wearing a seatbelt has no value – in fact, it has a negative value (of -$30) to those fined.

However, the epiphany continues: does the above mean that all the recent “comply-mancing” is in vain?

No, I think that is is needed more than ever!

Imagine the Universe where we, security professionals, possess detailed information on the threats that we face AND on the countermeasures we have – complete with how efficient each countermeasure is against each threat. In this case, doing “risk management” will be trivial: run a list of threats your organization faces, get the desired degree of security (or, “risk”, if you must call it that), then pick the countermeasures which will get you there, starting from the least expensive. Bingo! You are done. If you run out of budget in the process, then go back and reassess the desired degree of security/”risk”. Or negotiate the lower price with the countermeasures provider.

As you are reading the above, you are quickly coming to a realization that such description truly has nothing to do with the world we live in (sorry for NLP mind tricks…)

N-O-T-H-I-N-G!

In our world, threats are of unknown frequency and damage (ALE my ass!), countermeasures are of unknown efficiency and random cost – plus both change all the time. And we don’t even have the formula to plug the unknown and changing numbers in. And we can’t reliably value assets and losses. And we don’t know what is our desired level of security – that was icing on a security cake…yummmm.

So, what are the choices a majority of organizations take? Do nothing. Or do something random. Or do “something cheap.” Securosis folks once called it a market failure in security. Rich’s recent presentation at Secure 360 conference also spoke about the same.

The result? Massive 0wnage, fraud, losses, breaches and other cyber-freaking-war.

Here is where compliance comes in. Compliance is a blunt instrument (a sledgehammer, as I say here) to compel people to do security, auditability, transparency, even responsibility for the losses of others and sometimes even for their own losses, etc.

We live in an intensely interconnected world and if a merchant does not protect the data belonging to an issuer (taking an example from PCI land), we all suffer. If people don’t protect [or remove] such data, we’d have no ecommerce as electronic payment system will eventually crash. No electricity as SCADA systems will [eventually] be hacked. And no healthcare as eventually reliance on computers in healthcare will lead to people being KilledBySoftware (also see Security Predictions 2020)

Can we mandate that people do a good job? No. “Good job” by definition comes from the heart, not from the whip. Is it still worth it? Yes, I think so. In other words, the current onslaught of compliance is a sign that information security is pretty much mainstream. In the future, compliance efforts will help establish a new, higher baseline level will be established – and security battle will shit to levels above it.

Finally, is there any other way to sell security? Yup, FUD. Arghh!!!! You are sooo getting owned if you don’t buy our stuff!!! I happen to think compliance is a better choice than that.

To conclude this passionate epiphany, I have to say, thrice:

If you are “doing compliance” and gain no value of security, you are probably an idiot. Please stop!

If you are “doing compliance” and gain no value of security, you are probably an idiot. Please stop!!

If you are “doing compliance” and gain no value of security, you are probably an idiot. Please stop!!!

Possibly related posts:

Risk vs Risk
My Best PCI DSS Presentation EVER!
Source Boston 2010 Conference Notes and our PCI DSS presentation.

Monday, May 17, 2010

Hack in The Box Keynote in Amsterdam 2010

Among all the fun security conferences I’ve been to lately, this one is promising to be extra-special. After two failed attempts (one), I’d be doing (finally!) a keynote at Hack in The Box (HITB) Amsterdam 2010. So, if you are in the vicinity of Amsterdam on June 30 – July 2, 2010, come over and attend it. My keynote will be titled “Security Chasm”

Full abstract follows:

Have you often wondered why people are updating their security policies, closing compliance gap and defining ISMS while attackers are owning their systems – at the same time? Why consultants advise management on ‘risk ass-essment” while new bots are being deployed on what was formerly known as ‘your network’? Why some say that “DLP is all the rage” while record data losses and resulting fraud occur daily? Why application architects now have to assume that a client PCs is ‘owned’ when its user goes to a bank website and the design solutions to work securely around that?

Reality today often presents a grim vision of “two securities”: one concerned with ‘elevating the infosec conversation’ while the other is concerned with cleaning up the mess on our networks and systems. In one, people pretend to ‘assess risk’ while in the other incident response is the only way to go…. This very concept, that I call “security chasm,” will be the subject of my keynote presentation, along with such questions as “why we wear seatbelts because of the monetary fine, but not because of risk to our lives?” and “What will make us secure – if anything?” (and what does it actually mean!) Finally, I will explore the future of what we now call security industry and make a few long term predictions of where we will end up in a few years….

See ya all there!

Possibly related posts:

Friday, May 14, 2010

Secure360 2010 Conference Notes

I just came back from Secure 360 conference in Minneapolis, MN. First, I’d like to thank the organizers for inviting me to be a "featured" speaker at the event. Just as in 2008, the conference was well organized and well attended as well - pretty much all 9 (!) tracks.

Day 1 started from attending Rich Mogul’s talk called “Putting the Fun in Dysfunctional: How the Security Industry Really Works.” His main theme was in use in economics and psychology (all the way to Maslow diagram :-)) to do analyze what happens in security industry. Some bits that caught my attention follow below:

We as an industry spend MORE on anti-virus+firewall than on ALL other security safeguards combined (!).

Many organizations are “reactive, but not responsive.” Just as others, Rich also likes to remind people that incident response trumps most other things in important; you can choose to not deploy a DLP tool (for example, no offence to any DLP vendors in attendance :-)), but you WILL respond to an incident (even if your IR plan = panic :-))

We deal MUCH better with short term risks than long term risk (also see Schneier saying similar things here); the chain “Fear –> wired response -> buy product” seems all but unbreakable

Compliance realigns economic drivers: risk of audit > attack. It was funny that in his view organizations need to pay attention only to those laws and regulations where penalties are actually imminent.

On top of this, controls to outcomes are not tied!! I also consider this to be one of the horrible holes in security today!

One of the curious point that I’ve seen before from Securosis folks is that “making us better at security” does not sell security tools and practices; even if it is MUCH better than current. What sells is fear of threats – of either hacking or fines.

Finally, feel free to ask Rich what is "Porn and email theory of security" :-)

Next, Marcus Ranum gave a speech on software suckage (“Software as a Strategic Problem”) was thought-provoking (and somewhat argument-provoking too). The main idea was: BOTH COTS AND outsourced software development is wrong for super-sensitive government/national security uses (He gave an example of a rumored outsourced code running in a JDAM…) – agencies need to go back to hiring, retaining and utilizing in-house staff. In this view, that is the only way to avoid future “nation-busting” security issues.

He contrasted two approaches: “write the software to solve the problem - from scratch” vs “use very flexible COTS software + spend forever configuring and reconfiguring it.” He also called for such custom software to aim for “zero maintainability + zero administration” – which to me sounded unrealistic for most evolving uses of software…

Finally, Marcus was also visibly upset that US government didn’t backdoor Windows :-) - it seems like a missed opportunity for easy world domination…

Here is some fun coverage of Marcus’s speech and the usual Slashdot idiocy that followed. The key quote is: “If the United States wants to remain competitive in the global economy and prevent widespread penetrations of its strategic, corporate and commercial networks, enterprises and government agencies should stop relying on commercial [A.C. – whether COTS or contracted/outsourced] software and go back to writing more of their own custom code” (read the comments too)

I ended day 1 at Gal Shpantzer presentation on USB isolation. The key idea was: given that most PC’s are owned (sad, huh?), how do we still use them for sensitive application like banking? He reviewed approaches such as dedicated PC vs "bubble" approach vs bootable approach on USB.

Day 2 started from my very own presentation “PCI DSS-based Security: Is This For Real? Using PCI DSS as A Foundation for Your Security Program.” The slides are embedded below:

PCI DSS-based Security: Is This For Real? by Dr. Anton Chuvakin

View more presentations from Anton Chuvakin.

It went pretty well, despite containing the picture of the devil while in Midwest :-)

Enjoy!

Possibly related notes:

Tuesday, May 11, 2010

Guest Post (First Ever!): Branden Williams “‘Free’ or Commercial—YOU DECIDE!”

This is the first ever guest post on my blog. In it, my esteemed co-author of “PCI Compliance”, Branden Williams, analyzes the use of open source software for various projects.

Here is more information about Branden and his awesome blog:

"Free" or Commercial—YOU DECIDE!

Open source software that is freely available for download and use is one of the greatest things about our technical community. The fact that at any given time I have a massive library of software available at my fingertips to accomplish any number of software tasks is nothing short of amazing! Then you tell me that if there is something I want to add to the software, I just jump in and do it? WOW!

Don’t let the rest of this post fool you, I am 100% pro open-source. In fact, I released more than one open source project over the years (though nothing recently of note). Open source has a place in research and the commercial world alike.

But can you just assume that open source software is FREE software?

One of the biggest misconceptions that I see in our industry is open source software is free. Freely downloadable, 0pen source software is by no means free—remember you need smart ladies and gentlemen like yourselves to install, configure, and support it. That aside, there is absolutely no reason why open source software should not be used to meet security or compliance requirements.

Before settling on a particular solution (commercial or open source), security professionals should do a full cost analysis including some risk-based elements. I know security people avoid doing this because we trust our guts more than we trust business tools, and it can be very time consuming. When you have to put out fires on an hourly basis, fiddling with a spreadsheet just doesn’t seem like a good use of your time.

Know this: going through the exercise will pay off in spades by showing the team when and where open source is strategic.

Before considering an open source software package, check with your legal team to see if your company has a position on any of the plethora of open source licenses under which software is typically licensed. For example, I work with a customer that strictly forbids GPLv2 software from being used (due to the requirements to contribute code improvements back to the larger community), but permits software licensed under the BSD license. Get a legal opinion from your legal counsel before your business comes to depend on a piece of software.

Once you have the green light on a set of licenses and find a software package that meets your requirements, it’s time to do your cost analysis. Open source software that is freely downloadable does have a cost greater than zero, yet that cost is often left out of the comparison (or incomplete) between commercial and open source software packages. Here are some things to consider:

Do you have to acquire equipment for this software to run? Be sure to include network infrastructure to support it.
How much of your time is required to keep it up to date? Estimate it, then use your salary plus bonus, and add anywhere from 15-25% for a benefit load. This will get you in the ballpark.
Do you need to hire a staff to keep it up to date? Use the same calc above.
Will someone else in your company have to support it? Same calc as above.
Will you need a second tier support contract from the open source group to handle advanced support issues?

The base formula should look something like this:

Total Cost = (Total Man-Days * Estimated Daily Salary Costs) + Initial Hardware Cost + Hardware Upgrade Cost + Annual Support Contract.

Whereby:

Total Man Days = the TOTAL number of man-days you will spend per year. If maintaining this software will take 10% of your time, then that would be 192 hours (based on a 1920 hours/year) or 24 days. If you have multiple staff classes, you will need to do the math in the parenthesis multiple times with the correct corresponding day rates and man-day effort.
Estimated Daily Salary Costs = Your fully loaded daily rate. If someone made 70K/yr plus a 15K bonus, that’s 85K/yr target compensation, plus a 20% benefit load = 102K/year, divide that by 240 days per year and you get around 425/day. This and the previous would get you a support cost of 10K.
Initial Hardware Cost = The capital you must spend to get hardware to support your project.
Hardware Upgrade Cost = Your current hardware is probably on a 3 or 5 year lifecycle. Estimate costs of replacement and divide by the normal lifecycle to get an annualized cost.
Annual Support Contract = The annual cost of second tier support from the group that writes the software.

NOW you have something to compare to your commercial-off-the-shelf vendor’s estimate. In more cases than some of us want to admit, freely downloadable, open source software can be more expensive than commercial software. That doesn’t mean you shouldn’t use it, or that it always negatively impacts your business. On the contrary, this exercise will help you document all of the costs and risks associated with deploying the package.

Besides, on a personal note… if it goes down at 4am on a Sunday, isn’t it nicer to scream at someone’s face and then go back to bed? :-)

Enjoy the guest post – feel free to check out my guest post at Branden’s blog too.

Friday, May 07, 2010

My Best PCI DSS Presentation EVER!

As you know, I gave a keynote presentation at PCI DSS Workshop 2010 by Treasury Institute for Higher Education (the other keynote being Bob Russo, naturally :-)). Addressing an audience of about 130 mostly University IT, IT security and finance (!) professionals in charge of their payment and PCI DSS programs was a fun challenge. The slides are embedded below – I seriously consider it to be my best PCI presentation ever… mmm… to date.

Spirit of PCI DSS by Dr. Anton Chuvakin

View more presentations from Anton Chuvakin.

(I suspect some of the things I had to invent for this presentation – e.g “the kitten bit” – will end up on Twitter pretty soon :-))

Also, the workshop was also pretty educational for me since I learned how PCI DSS is really done at the most challenging environments possible – large Universities with hundreds of merchant IDs, every possible card acceptable method, wayward academics, general skepticism for policies and mandates, desire for “openness” (aka come-take-our-PANs-SSNs-medical-records-kinda-openness…), lack of centralized control and (sad and unjustified, but frequent) disdain for central IT groups.

On the other hand, I was amazed to learn that many Universities do not need any extra pushing and hand-wringing to treat PCI DSS and payment security as … gasp!… a business problem. As I mentioned above, the audience at a PCI Workshop was only about 30% IT and IT security with 70% finance/treasury folks responsible for PCI DSS compliance (there were also 2 stray auditors in the room).

So, the second day keynote was given by Bob Russo who is definitely known for putting up a good show (and, nowadays, song and dance!). A new bit for me was the establishment of ISAs – Internal Security Assessors – and upcoming ISA training by the Council. He also reiterated that PCI DSS “1.3” (October 2010) won’t have massive changes, but mostly additional clarifying guidance, produced by SIGs, will be released at or before that date.

Also, I was involved in “PCI Experts Panel” with Bob Russo and representatives from Elavon and Fifth Third Processing Solutions. We covered many fun questions (some of which sure made my head spin… we are talking deep PCI esoterica here). I was kinda surprised to learn that people still ask whether encrypted data needs to be protected, even though it is answered in the official PCI DSS FAQ.

Enjoy!

P.S. WTH is “a kitten bit”? I coined the following phrase for this presentation: “Every time you think ‘PCI DSS OR security,’ god kills a kitten!”

Possibly related posts:

ShmooCon 2010 - Our PCI DSS Panel
Minor Bit of Promotion: PCI Book Rocks!
Source Boston 2010 Conference Notes (and my PCI DSS presentation with Branden Williams)
RSA 2010 EXCLUSIVE PCI Security Standards Council Interview
How to Stay Compliant? or Ongoing Tasks in PCI DSS

Tuesday, May 04, 2010

Brief Log Management Class

I gave a brief 90 minute log analysis and log management class at the Project Honeynet event in Mexico City.
The class slides are embedded below:

Logs: Can’t Hate Them, Won’t Love Them: Brief Log Management Class by Anton Chuvakin

View more presentations from Anton Chuvakin.

Enjoy!
Possibly related posts:

presentations on SlideShare

Monday, May 03, 2010

Monthly Blog Round-Up – April 2010

Blogs are a "stateless" media and people often only pay attention 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 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.

By a HUGE margin, the #1 post this month is again “Simple Log Review Checklist Released!” Grab our log review checklist here, if you have not done so already. It is perfect to hand out to junior sysadmins who are just starting up with logs.
Next is the post announcing the release of SANS Log Management Survey 2010 (“SANS Log Management Survey Is Out”), some highlights – and some surprises! - from the survey are in the post.
The post announcing the release of my detailed whitepaper on SIEM and Log Management is also in Top5 (“Two New Logging Resources Published”); also see other relates content such as “One More Time on SIEM vs Log Management.” To get the paper, you’d need to fill the form at Novell site, but I assure you – it is totally worth it :-)
A recent post “On Choosing SIEM“, only published a few days ago, went to the top like lighting. If you are thinking of getting a SIEM or a log management tool, check it out.
“The Myth of SIEM as “An Analyst-in-the-box” or How NOT to Pick a SIEM-II?“ and its predecessor ““I Want to Buy Correlation” or How NOT to Pick a SIEM?” hold the next position this month. They present some sadly popular misconceptions about acquiring and implementing SIEM and log management tools.
My log management maturity curve post (“Logging, Log Management and Log Review Maturity”) continues to sit in Top 5 (as #6 :-)). Is it awesome or what? :-)

BTW, notice something funny about the Top 5 this month? Look, Ma, no PCI DSS! :-)

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:

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

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