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.

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:

• Secure 360 Conference Notes
• Source Boston 2010 Conference Notes
• My Best PCI DSS Presentation EVER! and PCI Indy conference notes
• RSA 2010 - Day 4-5 notes
• ShmooCon 2010 - Our PCI DSS Panel and conference notes
• All posts tagged conference.

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:

• Source Boston 2010 Conference Notes
• My Best PCI DSS Presentation EVER!
• All conference posts.

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:

• Site: BrandenWilliams.com
• Blog: BrandenWilliams.com/blog (RSS)
• Twitter: @BrandenWilliams

"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.

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

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:

My other presentations on SlideShare

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.

1. 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.
2. 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.
3. 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 :-)
4. 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.
5. “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.
6. 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:

1. Cédric Blancher
2. Kevin  Riggins
3. Michał Wiczyński
4. Walt Conway
5. “Guerilla CISO”

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

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

• 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

One More Time on SIEM vs Log Management

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

40,000 ft view:

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

while

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

10,000 ft view:

(with slight risk of oversimplification)

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

1000 ft view:

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

 

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

Possibly related posts:

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

Source Boston 2010 Conference Notes

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

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

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

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

On Choosing SIEM

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

Great!

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

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

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

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

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

•WP2: Define the need for SIEM in general

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

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

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

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

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

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

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

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

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

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

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

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

Possibly related posts:

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

Two Upcoming Speaking Ops

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

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

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

UPDATE: Focus.com webcast is recorded here

IANS 3/25 Log Webcast Q&A

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

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

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

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

 

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

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

 

Q: Would you use log management without a SIEM?

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

 

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

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

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

 

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

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

 

Q: How visualization tools technically help in log review?

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

 

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

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

 

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

Enjoy!

Possibly related posts:

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

Two New Logging Resources Published

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

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

Quote:

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

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

[…]

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

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

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

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

Quote:

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

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

[…]

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

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

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

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

Possibly related posts:

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

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

SANS Log Management Survey 2010 is Out!

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

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

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

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

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

Q: Would you please suggest a log management application?

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

 

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

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

Enjoy!

Possibly related posts:

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

CISecurity Metrics Move Ahead

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

“The top three goals of metrics programs are to:

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

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

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

The top three business benefits expected from metrics are:

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

Metrics Programs:

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

Constraints on metrics programs are:

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

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

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

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

Monthly Blog Round-Up – March 2010

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

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

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

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

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

Thank you for all the link-love!

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

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

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

Obligatory “added everywhere” posts :-)

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