“Leaving Vendorland” or Consulting Full-Throttle

I have a horrible confession to make: I was “vendor scum” for most of my security career. All good things come to an end – replaced by better things, of course.

Since departure from my last job, I discovered the world full of exciting projects where I can be incredibly useful. For some logging projects, I can be more useful than anybody else in the world (and, no, this is not my ego talking).  At the same time, I discovered many jobs at “wonderful” large companies, where everything developed two years after the market is considered “innovation.” Maybe this is why I don’t really believe in security market consolidation: BigCo=slow while threat=fast leads to some nice EPIC FAIL of “consolidation.” In any case, I’ve seen a lot of fun projects, and not enough fun jobs. Thus I decided to start developing my own consulting practice. 

With this post, I am “officially” announcing my switch to consulting (even though I’ve been busy consulting for a couple of months already). Here is a quick summary of my services, also posted at Security Warrior Consulting site:

• Technology vendor services: compliance strategy for a security product, security and compliance content development, “thought leadership” webinars, training and writing, etc.
• End-user organization services: development of logging strategy, logging policy, log review procedures, planning of log management architecture, etc.

Go see more details on my new consulting site or look at the full services menu [PDF]. At this time, I am working on a couple of very fun projects, but will look for more work along the above lines in the future.  If you have anything of that sort for me, please get in touch (email, other methods)!

Finally, if I discover new fun security things to build and evangelize,  I will once again join the noble ranks of vendor scum…

BTW, our “PCI Compliance” book should be out any day now and our book website is “ready for business.” Time to get back to work on that logging book…

Possibly related posts:

• Not at Qualys Anymore

Two Fun PCI Appearances

FYI, this week I spoke at these two fun PCI DSS events (both virtual):

• PCI 2010: Trends and Technologies by BankInfoSecurity.com
• PCI 360: Multiple Perspectives by ISC(2)/BrightTalk

If you are into that sort of thing, check them out.

BTW, the PCI book is about to be printed – and our official PCI book website is almost ready!

Fun Reading on Security and Compliance #21

Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security AND Compliance." Here is an issue #21, dated November 23, 2009 (read past ones here).

This edition of dedicated to all the folks who write blogs, but never read blogs. Shame on you :-)

1. The “60-minute-gate”: start here, then comments here and here.
2. Hilarious SIEM/log management video (“I need an outlet for my detective instincts”).
3. Did somebody finally beat “the Levin record” (which seems not really his now) from 1994? Stealing $9m purely through computers is kinda cool :-)
4. This shit is deep: data breaches cause data abuse (fraud, etc), says recent research. Captn Obvious award does not go unclaimed :-)
5. Detecting Malice eBook is out.  Get it!
6. NIST SCAP Conference presentations are finally posted (including mine). Check them out here.
7. Privacy and future shock discussion: read this (“Forget Privacy, It Is Just An illusion”), then this (“Gartner Gets Privacy Dead Wrong”), then this (“Bob Blakley Gets Future Shock Dead Wrong”). Fun to read and think about.
8. “HIPAA teeth” and HITECH act, very interesting. Also, this says that “57% of the survey respondents said they would make additional investments in security tools or technologies” [due to HIPAA/HITECH]. Is this for real?
9. Various smart people beat up risk assessment: here (“The practice of risk analysis is one of the root causes of our failure to match security countermeasures to the emerging threats. It depends on too many unrealistic assumptions”) and here (“I think one of the “hot” areas that I care about is being able to quantify risk. I personally don’t think this can be done because I’ve had too many customers show me their risk measuring systems and I’ve found fault with them.”) And then some other people defend it.
10. Gunnar’s cloud wisdom: Part 1,2,3a, 3b. Did I mention it is awesome?
11. Dave for the n00bs. Useful read, and not just for the n00bs: “Please please please please PLEASE do not come out of school with a degree in “Information Assurance” or some other bullshit and tell me you are a security professional.”
12. As I think more about SIEM, I find this old Decurity post very insightful, even though its enlightened creator has been absorbed by the EMC machine :-)
13. “The Art and Science of Infosec” is surprisingly insightful. Key quote: ”too many security folk, especially consultants and auditors, seem to fall into the trap of having the science drive their work more than the art.”
14. I read this (“Is Your Response Time Less Than 120 Days?” that talks about a security monitoring tool which was “mistakenly turned off for a four month period.”) and it reminded me of my old paper on "the fallacy of real-time” (here). Why obsess about sub-second correlation on your SIEM, if your “process” is to respond to events months after they happen? I like to call it “Is CNN your IDS?” syndrome. :-)
15. “Change the game” or “raise the bar”?

PCI DSS section:

1. I can’t think  why I haven’t highlighted it earlier: “Will PCI Mandate The Use Of Data Discovery Tools?” It is from Branden “Awesome” Williams, now of EMC.

Enjoy!

Possibly related posts:

• All other security reading posts.

Smart vs Stupid: But Not Why You Think So!

This slightly rambling post was born out of some fun conference discussions and well as pondering the “PCI is the Devil” theme. So, some interesting dichotomy was born as a result. Let’s temporarily call it “smart” vs “stupid” security, but if offensive labels … well.. offend you, you can pick something else instead :-)

The table below shows some concepts loosely associated with each security paradigm (of course, this whole thing is a gross oversimplification, but useful for our purposes nonetheless):

“Smart” Security	“Stupid” Security
Incident response	Badness prevention
Risk (to the extent understood … which is often not much)	Compliance, “doing the minimum checklist”
C of C-I-A, moving to I	A of C-I-A
Monitoring for attacks	“Nobody wants to hack us”
Logging + log analysis	No logging
Application security	Network security
System perimeter, application perimeter, network perimeter, “data perimeter”	Network perimeter
Firewalls, SSL, AV, IDS/IPS, WAF, SIEM, DLP, DAM, SDLC, VM, etc	Firewalls, SSL, AV
People	Boxes
Visibility (striving for it) – know control is impossible	Control (failing with it)  - afraid of visibility
Metrics (striving for it)	FUD
Want to know how secure they are	Afraid to know – but want to just “be secure”
0wned (know it, care to have less of it)	0wned (don’t know and don’t care)

Now, forget my “offensive” column labels that I added to purposefully confuse you :-) Even though security literati prefer to call the left column “smart”, “correct”, “good”, “risk-based”, “new school”, etc while label the right column “stupid”, “wrong”, “evil”, “checklist-based”, etc, it is more useful to think of the left as “RARE” and of the right as “TYPICAL” if you consider the organizations of all sizes.

However, things are actually a bit worse, even “TYPICAL” security from the right column is more than some smaller organizations have.  And this is where PCI DSS comes in, an angel with a flaming sword :-) In this context, PCI is a noble attempt to bring many organizations to somewhere better than the above “typical” level. And this is why I think it is awesome.

P.S. If  you were expecting a post on why PCI sometimes IS the devil, that will come later :-)

Possibly related posts:

• More PCI Devil Defense
• All posts tagged “musings”

SANS Log Management Class in Sacramento

FYI, I will be teaching my SANS class SEC434 called “Log Management In-Depth: Compliance, Security, Forensics, and Troubleshooting” on December 2nd in Sacramento.

Details: “This first-ever dedicated log management class for IT and security managers will cover system, network, and security logs and their management at an organization. We will start with the basics, like making sure that logs exist, and then go on to touch upon everything from managing log storage, to analysis techniques, to log forensics and regulatory issues related to logging.

In the beginning, we will cover various log types and provide configuration guidance, describe a phased approach to implementing a company-wide log management program, and go into specific tasks that IT and security managers need to be focusing on a daily, weekly, and monthly basis in regards to log monitoring.

A unique and comprehensive section that covers the hot topic of using logs for regulatory compliance, such as PCI DSS, will also be presented. Everybody knows that 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.

The class will also touch upon various uses of logs for incident response, forensics, and operational monitoring. Common logging mistakes, learned from many years of working with logs, will also be explained.”

Sadly, the class is NOT public, but open to employees of the State of CA only (this time). The next time the class will be taught at SANS CDI 2009 (sign up!)

On SIEM Complexity

I love Laura Ries (@lauraries). Not in that way, but I think she is the source of non-trivial marketing awesomeness (despite her iPhone fiasco).

In any case, here are three pictures from her recent presentation:

Note that on the 3rd picture she uses the line that I’ve heard many times, but never fully accepted: “Changing the reality doesn’t change the perception.”  This is pretty darn profound – and darn hard to accept for folks of the scientific or engineering persuasion.

What is has to do with Security Information and Event Management (SIEM)? You know, “SIEM is very complex.” Everybody “knows” it.

At a conference in Scotland last week, I was leading a roundtable on SIEM  and I started the discussion with this provocative question: “Is SIEM ‘a MUST-have’ or ‘a nice-to-have’?” No offense to my friends at SIEM vendors (you know I love you too :-)), but 100.00% of those who responded chose “nice-to-have” and, respectively,  0.00% picked “must-have.” One person added that it would indeed be “nice”, but only if it will solve problems that his organization is having and at a reasonable cost. And another person stated that “SIEM is very complex” (with the implicit assumption that anything that complex cannot really be mandatory). And yet another got upset that his auditor requested that he “needs to get correlation” without explaining what it was…

BTW, yet another person brought tears to my eyes by saying that “on the other hand, log management IS a MUST-have” for incident response, accountability and other uses, but this is a different story altogether.

So, “simple to use SIEM” is “a luxury Hyundai” or (new meme alert!) “an anti-Unicorn” – you might find it, smell it, touch it, BUT still refuse to believe in it. That, my friends, is why (deep insight alert!) enterprise SIEM vendors don’t have much success with their SIEM appliance offerings (note that I am talking about their SIEM appliances and not their log management appliances; those are doing fine). Remember that “old school” SIEM vendors all started with ambitions of being an “HP OpenView of security” (EPIC FAIL alert!) which exudes pure complexity…

Personally, I’ve seen some decent attempts to make appliance SIEM easier, but my suspicion is that today the theme of “SIEM is complex” is exceedingly powerful and mere reality will not overcome it.

What can we do about it?

First, if we are to believe esteemed Ms Ries, fighting it with facts will not work. Perception will beat reality and you into bloody pulp. So, “but, dude, our SIEM really IS SIEMmple” won’t fly.

Second, we can focus on how amazingly NICE it is, without being a MUST-have. Stop obsessing about your SIEM not being a MUST-have like, say, iPhone or, say, Twitter :-) In many cases other than SOC building, SIEM’s purchase justification is fuzzy at best, despite more than 10 years of concerted vendor efforts with “ROI”, “TCO”, etc. Or such justification is based on a compliance shortcut which then backfires. In fact, “SIEM is not for everyone” might not be a bad slogan to use… or maybe “grow up to SIEM!” BTW,  I’ve heard of cases where SIEM was deployed even before NIPS/NIDS (or at the same time), and this shows that some organizations place fairly high priority on it.

Third, we can we sidestep the whole “must vs nice” debate and focus on specific problems that SIEM solves. You know, well-tuned correlation engine really can tell you about “bad shit” happening on your network! And it can simplify your daily workflow. And enrich logs with a lot of useful context information. And help with incident response (well, log management is better in that case).  If SIEM focuses on solving particular problems and solving them well, then the customer will have to decide whether solving that problem is a must for them or would just be nice. And the whole debate will change in a useful direction!

Fourth, you can focus on log management. Easy, huh? :-) And then decide which of your customers are ready for SIEM and who think of it as “sufficiently nice”  to deploy – then you can have them “grow up to SIEM.” Log management is – or, at least, at some point will be – for everybody who has logs and that is pretty much everybody…

 

Finally, I’d like to invoke a curse of unspeakable evil: if you sell an appliance SIEM that has a  license-based “hard throttle” which causes you to silently (!) drop incoming logs when 10% (!) of the EPS rate [that your customer paid for!] is exceeded and you are reading this post, please die a painful and embarrassing death. You are an offense to common sense! Also: dear appliance SIEM buyers – please ask your vendor what happens if the EPS rate that you paid for is exceeded…

Possibly related posts:

• SIEM Bloggables
• All SIEM posts

FUDSec FUD Piece Reposted – With Comments

My fudsec post (reposted below for backup purposes with a two week delay) was not “an endorsement” of FUD, it was a reminder to many overly excited folks that FUD is largely all we have today – and there are signs that change just ain’t coming.  As I hinted in  my quick follow-up (“Smelly Goat vs Flying Unicorn”), I am not defending Fear/Uncertainty/Doubt for the merits, I am explaining that we are largely stuck with it, for now. Another way to explain is to quite Churchill, as I do in the comments. Those who know me can confirm that I am a huge proponent of metrics (but also highly skeptical of some metrics ever being achievable).

Here are some of the insightful responses to it:

• Just say ‘no’ to FUD from New School of Security (personally, I think that “trumping with ethics” is a low card in intellectual arguments! IMHO it is one step above name calling)
• On smelly goats, unicorns, and FUD from New School of Security.

 A Treatise on FUD

FUD or Fear/Uncertainty/Doubt triad seems better known than the other security triad: C-I-A. It seems inextricably linked with security industry as well as with security technologies. After all, don’t we reach for some extra safety and security if we fear something, feel uncertain about something or doubt something?

While few CSOs and security leaders admit that they build their security programs based on FUD, below we will hypothesize that FUD is indeed a meta-level above risks, threats, vulnerabilities as well as compliance mandates. FUD’s role in security today probably overshadows the role of any other factor we know. To put more substance into our discussion, here are some well-known examples where fear, uncertainty and doubt manifest themselves:

· Fear

• Getting compromised by attackers
• Failing an audit
• Suffering big loss
• All of the above: Failing an audit + getting hacked + being dragged into a media circus

· Uncertainty

• Keeping a security leadership job
• “Keeping the wheels on” for security infrastructure
• In case of an incident, loss amount is uncertain
• Threats and their impact

· Doubt

• Security mission success
• Effectiveness of security measures
• Support of senior management

Further, many people view using FUD for driving security spending and security technology deployments as the very opposite of sensible risk management. However, FUD is risk management at its best: FUD approach is simply risk management where risks are unknown and unproven but seem large at first glance, information is scarce, decisions uncertain and stakes are high. In other words, just like with any other risk management approach today! Big Hairy Ass Risks (BHARs) dominate both the FUD-infested security vendor materials as well as internal CSO presentations. Note that very few of the BHARs are truly imminent and thus fall out of FUD realm as there is no uncertainty about them - just like only few people develop phobias of poisonous snakes (which would be a very useful phobia to have).

In light of this, we have to accept that there are benefits of FUD – as well as risks.

The benefits of FUD stem from the above view of security which is defined as “being free from danger” or ”measures taken as a precaution” against something bad.

First, in the world we live in, FUD works! Demonstration of a BHAR followed by technology purchase or control implementation does reduce possible loss of not only due to said BHAR, but also due to other threats (if BHAR ends up being completely mythical). Such implementations often also deliver other useful things for the organization. It is worthwhile to remind that “FUD selling” applies to CISOs no less than to “enterprise software” sales people. It also applies to “fear of auditors” as well as “fear of attackers” – both drive security adoption, even if lately the former seems to be winning.

Second, keep in mind that many of the BHARs are both genuinely scary and, in fact, likely. Scaring a company into updating its anti-malware tools (despite all the concerns about their relative efficiency) or into deploying tools to collect and analyze logs is excusable, at the very least.

Third, many proclaim that people need to be naturally drawn towards doing "the right thing" after being educated about what the right thing might be and scaring people into action is not that efficient. The technical answer to such concern is a resounding “Ha-har-ha!!!”

Finally, for years FUD was used to sell insurance as well as safety features in cars and other products, legal services, to make people update their boring DR and BC plans, and other good things. Fear might not be a very positive emotion to experience, but acting out of fear has led to things that are an overall positive, all the way down to resolving political tensions out of fear of a nuclear war…

Admittedly, Fear/Uncertainty/Doubt approach has issues as well. The key issue with FUD is its “blunt weapon” nature. It is a sledgehammer, not a sword! If you use FUD to “power through” issues, you might end up purchasing or deploying things that you need and things that you don’t.

Second, it is well-known that magic of FUD wanes if you invoke it too often. If you scare your customers or your management into taking your product or your security agenda seriously, they are almost guaranteed to stop listening to you at some point. However, if enough BHARs manifest , FUD approach will continue to be fairly productive. One can get desensitized upon hearing that "sky is falling" too often, but here is the thing: I am willing to take the risk of such "desensitization" given that sky is indeed "not quite stable."

Third, FUD power – as any other power – corrupts whoever wields it too often. If you end up scaring people into action or spreading uncertainty, you might well lose an ability to win security arguments any other way. Also, if fear is a motivation for every decision you make, checking into a mental institution is not a bad idea. You might actually be paranoid!

Finally, I’d like to bring up the good old “greed vs fear” model for advancing security, last mentioned at BlackHat by one of the speakers. As “greed-based” ROI scams fail to move security ahead, the role of fear has nowhere to go but up. In other words, all of us get to pick out favorite 3 letter abbreviation – and I’d take honest FUD over insidious ROI any day…

To conclude, fighting FUD is a noble pursuit; Don Quixote thought the same about fighting windmills. Even if objective metrics will ever replace FUD as the key driver for security, we have a bit of time to prepare now. After all, in that remote future age interstellar travel, human cloning, teleportation and artificial intelligence will make the life of a security practitioner that much more complicated…

Original post.

More PCI Devil Defense

Our paper “PCI: No Angel, but Not the Devil Either” just went up on “CSO Magazine” online (and a few other sources), check it out. It debates this piece which quotes Joshua Corman of The 451 Group. Sorry, Josh, we had to argue with the imperfect retelling of your words, so some points might not have came out well… Hopefully, we can have a real industry-advancing debate at some point!

In any case, I am getting a bit tired defending PCI DSS (ya know, “I’d rather be logging” :-)) from smart people who should (IMHO) know better. As I am doing it, I am also looking for some sort of “root of PCI hatred” in order to dislodge it and stop this frenzy once and for all (the whole thing reminds me of Harry Harrison “Deathworld” Jason dinAlt saga)

Here is what occurred to me recently: I used to think that “security perfectionism” drives a lot of attacks on PCI (“it sucks because it is does not ‘guarantee’ ‘perfect’ security”). But some old Scottish whiskey made me realize that it is more subtle than that – it is not perfectionism per se, but “enterprise security disease.”

Let me explain. If your entire security career happened while working at, selling to or advising global organizations about information security, it is highly likely that your brain has adjusted to that reality. But there is another reality – and, darn, it is big.

Here is an example: next time you are having lunch somewhere and paying with a credit card, think: do there folks have a network IPS? Web application security scanner? SIEM perhaps? A DAM tool? Information risk protection strategy? BTW, the answer would be “No, no, no and no and no.” Their security is anti-virus (deployed on most systems and updated on some), filtering router with NAT (and with a very open ruleset) and a few other “bulletproof” shields of that sort.

PCI is truly a beam of light (an annoying one…) for them – it motivates them to learn about all the wonderful security things they should be doing. Risk management? Pah. Threat posture? WTH. Encryption? Stop cursing. Firewall? Yes, we have it.

Here is how I presented this side of a debate in a recent argument I had (via email), numbers are from my favorite source of security stats (that is srand(), as you know :-)):

• 198x-1992: 99% of people just say 'screw information security'
• 1996-1999: massive email viruses hit; 98% of people still say 'screw security'
• 2002-2004: worms hit; 97% of people still say 'screw security'
• 2005-2007: spyware hits, botnets start their ominous rise, 96% of organizations still say 'screw security'
• 2007-2008: data losses hit, massive data theft happens, 95% of organizations still say 'screw security'
• 2007-2009: PCI DSS spreads. Oops! Now only 30% say 'screw security.' The rest has to at least pay it some lip service and raise their “wooden shields.” Hurray!

That is the main reason I think PCI magick has the blinding power of pure awesomeness.

BTW, I am working on a post that clarifies this “enterprise security thinking” a bit more. Also BTW, if you are looking to use PCI DSS as a general security or data security framework, go here.

Possibly related posts:

• My PCI Myths deck
• Five Reasons to Dislike PCI DSS – And Why They Are WRONG!

SIEM Bloggables

I was working on a presentation related to Security Information and Event Management (SIEM) the other day. Even though it was intended for a particular audience, a few pieces of it are generic enough to be shared with the world at large. Hopefully said world at large will find it useful for planning SIEM deployments, analyzing your requirements, improving SIEM product design, etc.

So, in no particular order:

What SIEM MUST Have Today?

1. Log and Context Data Collection
2. Normalization (including event categorization)
3. Correlation (what used to be bundled under “SEM”)
4. Notification/alerting (“SEM”) [the role of real-time processing seems to be shrinking, as I predicted in 2004 - that surprised everybody including myself]
5. Alert/event prioritization (“SEM”)
6. Reporting (“SIM”) [including visualization]
7. Security role workflow [from security analyst roles to incident responder (my classic piece on using SIEM for incident response, BTW) to security manager and – rarely! – the CSO]
8. Everything else is icing on the cake!

Key SIEM Use Cases

1. Security Operations Center (SOC): real-time views, analysts online 24/7, chase alerts as they “pop up” [this was the original SIEM use case when SIM started in the 1990s; nowadays it is relegated to the largest organizations only]
2. Mini-SOC / “morning after”: delayed views (“analyst comes in the morning”), analysts online 1-3/24, review alerts and reports then drill-down as needed
3. “Automated SOC” / alert + investigate: configure SIEM to alert based on rules and forget until the alert, investigate alerts, review reports weekly/monthly [this is the use case that many users want and few SIEM products can deliver…]
4. Compliance status reporting: review reports/views weekly/monthly, no security operation focus [it might be common, hopefully the organization can later transition to any of the use cases 1.-3.]

Two Types of Users To Make Happy – with SIEM or Log Management

“Minimalist”	“Analyst”
•Still evolves from “logs are dirt” to raw collection •Pure compliance focus – “deliver me from evil… eh… auditors” •Collecting logs •Checkbox mentality •Less mature; needs more hand-holding	•Evolved to “so we have them collected – now what?”; now stuck •“Compliance+” or pure security/operational focus •Using logs (analysis) •Situational awareness mentality •More mature; needs more “cool tools”

Enjoy!

Book Review: “The myths of Security” by John Viega

My review for “The myths of Security” by John Viega has been posted to Amazon; I gave it 4 out 5 stars.

Think about this book as a printed collection of blog posts – some a dozen pages, some half a page. John’s essays – all 48 of them - read like a typical blog: fun views on hot subjects, controversial opinions, new ideas for the future, dispelled myths, cool technology ideas, etc. I definitely enjoyed reading the book, even if most of the material was at least somewhat familiar to me.

For starters, this was the first time that I have seen a book written by somebody employed by a major antivirus company, who would agree that antivirus solutions don't work too well and slow down systems. It was very impressive to read that the author himself does not use an antivirus solution and didn’t even use one when he' was in charge of building one! (Understandably, he does recommend that consumers use one on their systems)

The following are some of my fave chapter highlights. “Security:”Nobody Cares” is one of my favorites; it covers why people, on average, don’t care about information security. His analysis matches that of some other industry thinkers, but it is presented well in the book.

I also enjoyed his thinking about why Microsoft antivirus solution would never pick up and never present a threat to the big AV vendors. In his opinion, most people do not trust Microsoft as a security brand. He thinks that customers would always go to security specialist and not to MS for antivirus tools, even if such specialist is located in Russia or Czech Republic. Also, it looks like the 30% success ratio for antivirus solutions is pretty much a commonly accepted number nowadays; it is mentioned in the book more than a few times.

One chapter that made me angry was chapter 7 on Google. He basically makes the insinuation that the Google in particular and pay-per-click advertising in general motivates people to hack into systems; a view as illogical as it is silly.

In chapter 26, John has an interesting idea for a Social Security number replacement scheme. Many other chapters contain ideas for improving major parts of security technology, even if in some cases the author has to disclaim them with his disbelief about their implementation potential.

It is quite interesting that in chapter 28 John dispelled the myth that including security early in the application design is cheaper. Compared to ignoring the problem until notice from customers, it is certainly more expensive. He touches most other known security industry “pain points” such as vulnerability disclosure. He proposes to replace “responsible disclosure” with a new scheme from my view looked kinda similar, less dangerous for the world at large but less motivating to software vendors. He also discusses whether disclosing vulnerabilities reduces or increases the risk for consumers (in his view seems to increase it).

Closer to the end of the book chapters get shorter and shorter. For example, chapter 42 ends up being half of a page in length. It pretty much states that he would sacrifice some privacy for more functionality and so would most of the others, which seem to be a very popular view nowadays.

I was very happy to find that he devoted an entire chapter - 2 pages in length - to criticizing academic security research (one of my pet peeves!). He says “lots of academics are reinventing what security industry has been doing for years. “ [They are also reinventing a lot of “epic FAIL”, proven to not work.] The book also mentions that there is nowhere near enough data sharing between security industry, where the problems are, and academia, where - supposedly - the brains are.

Other reviewers have pointed out that it is not clear what is the audience for the book. Many of the chapters seemed written for the “curious consumer” while others are clearly intended for security practitioners or even security managers and imply a degree of IT industry savvy.

Finally, I have to say that multiple mentions of McAfee did not annoy me at all. I fully realize that if somebody employed by the vendor criticizes the very livelihood of that vendor (classic signature AV, in this case), you must throw your employer a major bone. You absolutely have to mention your employer positively to counterbalance the criticism and he does – in many chapters.

To conclude, I read books on information security for fun. This book was a lot of fun to read even if I did not agree with some of his opinions. It is well-written, has light writing style and touches most if not all controversial issues in security; the book also has a lot of fun novel ideas for the future to think about.

Releasing Many Of My Security Papers!

As you can guess, I have written a lot of fun security stuff over the years. I’ve been “liberating” my content for the community to read, starting from presentations (via Slideshare)

Now, I am releasing most of my old paper content as well:

• My DocStoc collection
• My Scribd collection
• My Slideshare collection

Feel free to check these periodically as I will be adding old papers from my collections for a long time (they also get auto-dumped to Twitter). BTW, I am doing it despite the fact that some of my writing from 2002 is quite embarrassingly naive :-) But I never, ever misspelled HIPAA! Never!

Notable papers released:

• Automated Incident Handling Using SIM (now known as SIEM :-))
• Log Data Mining  /awesomeness alert! :-)/  - and related presentation on log data mining.
• Where Logs Hide: Logs in Virtualized Environments
• Discovery of Compromised Machines
• Trends in database log management 
• Buy vs. Build vs. Outsource: What’s Your Best Log Management Strategy? – and related presentation on the same subject.
• [very old, but still fun piece] On covert channels
• PCI DSS Myths – and related presentation on PCI myths
• “Security First” or “Compliance First”
• All presentations – there are pretty much all fun!

Go dig thru it, but keep in mind, old security stuff gets stale fast. So, while reading it, keep this in mind.

Possibly related posts:

• Everything tagged security reading.

Monthly Blog Round-Up – October 2009

As we all know, blogs are a bit "stateless" and a lot of good content gets lost since many people, sadly, only pay attention to what they see today. These monthly round-ups is my attempt 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. “Top Log FAIL!” is hot! The post summarizes the most egregious, reckless, painful, negligent, sad, idiotic examples of “Log FAIL.”
2. Open source SIEM theme continues to drive a lot of traffic – 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. The older inspiration for this post is “On Open Source in SIEM and Log Management.”
3. “MUST Read on Walmart Intrusion” includes the juicy bits from the full story at Wired. Some amazing examples of “log FAIL” are mentioned there, BTW.
4. “Open Source CLOUD SIEM, Anybody?” post is where I shared some ideas on how to go about building an open source SIEM/SIM/SEM tool using cloud computing. It seems to have attracted a lot of attention. And it should have :-)
5. “Compliance != Security, Does Security = Compliance?” contains some fun analysis of situations where not only “compliance != security”, but also “security != compliance.”  This theme will definitely be explored in the future.

This month I am also starting 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/resources sent most visitors to my blog:

1. Dancho Danchev blog
2. Dmitry Evteev blog
3. Martin McKeay blog
4. Kevin Riggins Infosec Ramblings blog
5. Richard’s TaoSecurity blog

Thanks for all the link-love!

See you in November. Also see my annual “Top Posts” (2007, 2008)

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

• 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 not at Qualys anymore and looking for the next big security idea to work on! Meanwhile, I might be available for fun consulting projects related to PCI DSS, log management, SIEM or other fun security things.