Fun Reading on Security and Compliance #22

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 #22, dated December 29, 2009 (read past ones here) with which I flush my 2009 “2blog” folder clean :-)

This edition of dedicated to all of us who changed something in their lives in 2009.

1. First, if you have to read only one thing, read everybody's security predictions for 2010: http://delicious.com/anton18/security+predictions+2010
2. BTW, Ivan Arce touches on security in the year 2030 (!) here in this piece: “By 2030 an organization’s or individual’s information security risk posture will be better described as a probable trajectory in an global multi-dimensional risk landscape constantly evolving and the tools used to measure and manage risk will be built using the foundations of modern physics, evolutionary biology, economic modeling and social sciences rather than technology-dependent abstractions.”
3. “What Information System Auditors and Information Security Auditors Do Not Want You To Know” is worth a read and my fave bit is: “…the future of the security profession will be deep and narrow technical knowledge. The generalist that walks around spouting best practices and reviewing documentation only will very quickly become a relic.”
4. Gunnar promises that 2010 will be the year of “war on risk” in “2010 Goal #1: No more "general risk.” Quote: “Goal 1. Exorcise the word "risk" from the infosec profession, unless its qualified with an adjective.”   This paper is an interesting one to read next as well.
5. An interesting post that insinuates that Cisco is “exiting security market” (well, not really): “Cisco seems much more passive and confused about its security play then it did a few years ago when it seemed intent on owning all-things security.” While there, read this bit on Life and Death of Cisco MARS, their “once-mighty” (well, not really :-)) SIEM product. The feeding frenzy on the MARS corpse has already begun, with many vendors promising “drop-in MARS replacement” (not hard, given that so many MARS boxes were shelfware …mmm… ”shelf-appliances”)
6. Fairly intelligent piece on choosing a SIEM from “CSO” magazine. Keep in mind that it is written by a journalist, so it has some inherent hilarity (such as 63,000:1 “compression”). BTW, CSO has another great piece: the first is a must read for all in security: “Lifestyle Hackers” – “The most interesting and ironic aspect of the lifestyle hacker is that he is motivated by the pursuit of productivity, often the very same motivation driving the implementation of various corporate controls”
7. Melissa Hathaway comes out of the woodwork with her “Five Myths About Cybersecurity” and they are actually a great read, even if sort of obvious to security industry insiders.
8. Ed Felten on “worst practices”, one of my favorite concepts: “A ‘Worst Practice’ is something that most of us do, even though we know it's a bad idea.[…] There's typically some kind of collective action problem that sustains a Worst Practice, some kind of Gordian Knot that must be cut before we can eliminate the practice.”
9. And some more log reading, calling to love log analysis. And here as well, but more on the fuzzy size :-)
10. While we are on the subject, Cisco published a great guide to logging: “Building Scalable Syslog Management Solutions”  (which, BTW, never once mentions MARS – please forget MARS already). It event has a good discussion of “actionable vs. non-actionable syslogs” and some useful architecture bits.
11. “PoS-gate” (a lawsuit from a merchant against 0wned Point of Sale system dealer and vendor Radiant Systems is covered: here, here, here, here and full suit here [PDF].
12. Some fun DLP discussion here. In fact, In didn’t even know that DLP stands for “Disturbing Lack of Progress” :-) This seem to follow the same theme of “DLP skepticism” – also check the discussion afterwards.
13. Very interesting philosophical piece by Rocky DeStefano on FUDSec: “We need to get out of the mindset of applying protection techniques based on physical realms and focus on evolving the entire environment to better suit our needs moving forward.” Some discussion of the above piece also continues here and here. While on FUDSec, check this awesome piece on utilities by Nick Selby; it is very useful if your paranoia is somehow losing its zing at the end of the year :-) (then read his other piece here too)
14. A good read from Rich Mogul “The Anonymization of Losses: A Market Forces Failure”: “Losses are also anonymized on the corporate side. When an organization suffers a data breach, does the business unit involved suffer any losses? Do they pay for the remediation out of their departmental budget? Not in any company I've ever worked with -- the losses are absorbed by IT/security.” A very useful read to those who like to whine about security not being taken seriously (while compliance is)
15. I just discovered that SANS is running their annual log management survey. It beats me why they are keeping it secret :-(
16. Finally, I saved the most though provoking piece for last:  this by Greg Hoglund paints a picture that few people even want to admit: “The decade in review: The most painful thing we learned is that computer security hasn’t worked. […] As we close out the first decade, we must realize we have just entered one of the biggest arms races in the history of warfare.”

PCI DSS section:

1. A paper “Data Breaches Show PCI DSS Ineffective” can’t be good, can it? Well, this one actually is a good “incite-ful” read: “If PCI is a failure, it is  not because it doesn’t prevent credit card theft; there is no such animal as a perfect set of countermeasures. PCI is a failure because it does not force a business to use it’s common sense and ask these practical, common-sense business questions.” In other words, it does not magically imbue the bearer with common sense :-)
2. Other people are also thinking about using PCI DSS guidelines for protecting other data. The actual story from McAfee blog mentions some [idiot] organization that lost critical data that was not protected by “PCI-grade” safeguard.
3. Another useful (=non-rant-ish) PCI DSS piece that I forgot to highlight: “Lessons Learned From PCI Compliance”

Enjoy!

Possibly related posts:

• All other security reading posts.
• All security predictions.

Security Predictions 2010

First, if you want to impress friends with your future-seeing powers, just do what Richard Feynman did when he predicted some WWII events: predict “everything will stay the same.” It is known to typically score better than any more “smarty-pants” ways of seeing the future. Granted, you’d be wrong in many cases, but other methods just make you wrong in MORE cases :-)
But how fun is that? What is the value of such passive “predicteering”, apart from winning bets? No new insight will be produced, no new thoughts, no new strategy, etc. I will not follow that approach!

In any case, let’s start from my traditional del.ici.us annual security prediction tracker: http://delicious.com/anton18/security+predictions+2010. There I log what everybody else has been predicting, from fairly insightful to downright dumb and biased. Also, right before preparing the 2010 version, I reviewed my 2008 security predictions and then I realized that I never posted the 2009 version. Shame on me!
The main theme of my 2010 predictions is “nearing the thresholds.”  These thresholds are in many dimensions: interest in information security, security awareness across organizations (mostly due to PCI DSS) as well as threshold of the offensive side lead (offense’s lead cannot grow indefinitely, ya know).
Next, let’s go by themes!


Compliance: as many other observers (Joshua at 451 Group comes to mind) noted, many of the security activities in 2010 will be defined by regulatory mandates such as PCI DSS, HIPAA/HITECH and others.  This will be the case from the smallest (larger extent) to the largest (smaller extent of compliance influence) organizations. I’d love to predict that people will finally get the spirit of PCI DSS (data security) and not just the letter (assessment readiness), but it is a tall one to forecast.
So, PCI DSS will continue its march. In fact, I bet (like I did in 2008) PCI DSS frenzy will further spread down-market - there is so much more Level 3s and Level 4s compared to Level 1 merchants. Now they all take payment cards, they are all insecure - thus, they might all be 0wned! BTW, nowadays nobody is predicting that PCI momentum will fizzle, as some did in 2007-2008.  While some people criticize it for specific requirements or missing things here and there, I still swear that those organizations who paid NO attention to security now do it ONLY because of PCI.
On the other hand, just as it was in 2008, ISO17799 (and its 2700x children), ITIL, COBIT frameworks likely won't be 'hot,' at least not in the US. Ad hoc approach (with some use of ideas from the above frameworks) to security management will still rule. In fact, more will try to base their entire security program on PCI DSS.
All this “comply-mancing” will bring both good and bad, as far as those organization’s ability to defend themselves from “bad shit” is concerned. And while we are on the subject…


Bad shit: what we have here is an intersection of two opposite trends: rampant, professional cybercrime and low occurrence of card fraud (as a percentage of card transaction volume). I explain this conundrum by predicting a scary picture of huge criminal opportunity, which still exists unchanged.
So, there will be more of rampant, professional cybercrime: from RBN to its descendants, from individual criminal entrepreneurs to emerging criminal enterprises, all signs point to dramatic rise of cybercrime. This is not some kinda FUD – this is simply logical consequence of today’s situation with the use of information systems: Insecure computers + lots of money + no punishment = go do it! (in the past, I made fun of people who predicted that “hackers will hack” – this item is different)
Still, I predict that low card fraud rates will continue: despite the above crime picture, many in the payment security industry know that fraud as a percentage of transaction volume is relatively low (I’ve seen estimates from 1% to 5% - in dollar volume this is till huge, by the way). Why is that? I explain it by the fact that criminal enterprises have limited bandwidth -you simply cannot pump ten billion dollars through a garage-style operation. My guess is that most if not all credit card numbers in circulation have already been stolen; the bad guys just didn’t have a chance to monetize most of them due to their limited bandwidth. This is exactly why selling card dumps is seen as a better [criminal] business than actually using stolen cards to buy goods – a counter-intuitive situation to many outside the industry.
In other words, there has not been a better time to go into a cybercrime business. The strategy is pretty much the “blue ocean” one: a lot of unexplored opportunity with low barrier to entry. You don’t want to wait until emerging “market leaders” will run the black business. Today, those folks have a unique opportunity to focus on “easy AND rich targets”, not “easy OR rich targets.” The best analogy is robbing a large bank with no security instead of large bank with security or small bank with no reliable security.


Intrusion tolerance is another trend (and its continues existence is in fact my prediction for 2010) which helps the “bad guys”: it is highly likely that most organizations have bots on their networks. What are they doing about it? Nothing much that actually helps. It is too hard; and many businesses just aren’t equipped – both skill-wise and technology wise – to combat a well-managed criminal operation which also happens to not be very disruptive to the operation of their own business. Your systems run OK and bots don’t bother you, what’s 5% of CPU and 10% of bandwidth between friends for sending penis enlargement spam? This view is admittedly cynical, but fairly realistic and results in a weird symbiosis that I call “intrusion tolerance.”
BTW, the Heartland guy said (http://www.govinfosecurity.com/articles.php?art_id=1774&rf=091509eg) “a breach is usually detected when the processing payer is notified of fraudulent use of cards.” This simply negates the existence of the entire security industry! Why is that? ‘Cause it is not doing enough to stop the tide. For example, it was very insightful to learn  that it took us on average 30 days in 2004 to patch a vulnerability, while in 2009 is takes 29 (!) days. See a huge improvement in security management practices here? 2010 will not change this trend: more bugs (such as all the Adobe stuff) moved the stats back to the Stone Age even as we improved our handling of platform patches.
Still, I doubt that “fully automated crime”, predicted back in the 90s by Donn Parker is fully possible today. If it were, the fraud rates and losses will probably grow – yes, you guessed right! – exponentially. So, I vote “no”, at least not in 2010. If that happens, the threshold will surely be crossed…


Cloud security: I predict much more noise and a bit more clarity (due to CSA work) in regards to information security requirements as more and more IT migrates to the cloud. The Holy Grail of “cloud security” – a credible cloud provider assessment guide/checklist – will emerge during 2010.

Finally, I am going to drag some of the 2008 predictions which are still valid and dust them off for 2010:

Platform security: just like Vista didn’t in 2007, Windows 7 won’t “make us secure.” The volume of W7 hacking  will increase as the year progresses.  Also, in 2008, I predicted an increase in Mac hacking. I’d like to repeat it as there is still room there :-)
And, only the truly lazy won’t predict more web application attacks. Of course! It is a true no-brainer, if there ever were one. Web application hacking is “a remote network service overflow” of the 2000s….

Incidents: just like in 2008, I predict no major utility/SCADA intrusion and thus no true “cyber-terrorism”  (not yet). Everybody predicts this one forever (as Rich mentions), but I am guessing we would need to wait at least few years for this one (see my upcoming predictions for 2020!) Sure, it makes for interesting thinking about why it did not happen; surely there is a massive fun factor in sending some sewage towards your enemies.  I'm happy to be correct here and have no such incidents happen, but I was predicting that something major and world changing would NOT happen so Feynman paradox is on my side.
A massive data theft to dwarf Heartland will probably be on the books. And it will include not some silly credit card number (really, who cares? :-)), but full identity - SSN and all.

Malware: sorry guys, but this year won’t be the Year of Mobile Malware either. As I discussed here, mobile malware is "a good idea" (for attackers) provided there is something valuable to steal – but it is just not the case yet in the US. There will be more PoC malware for iPhone, BlackBerry, maybe the Droid, but there will be no rampage. On the fun side, maybe we will finally see that Facebook malware/malicious application (that I predicted and consequently missed in 2008). This one will be fun to watch (others agree), and current malware defenses will definitely not stop this "bad boy," at least not before it does damage.

Risk management: more confusion. Enough said. In 2008, I said “Will we know what risk management actually is in the context of IT security? No!” It sounds like we know no more now.


Various security technologies (refreshed from 2008):

• Full disk encryption will not (yet?) become ubiquitous.
• NAC will be largely forgotten by the end of 2010.
• More whitelisting for host and network security will happen (but combined with blacklisting, which is certainly not going away!) As malware landscape becomes even more diverse, application whitelisting for security will start to shine even more. Collaborative filtering for malware will also become more noticeable.
• Secure coding does not (yet?) becomes mainstream (definitely, 'not yet' on this one) It pains me to say that that I think that while this ball definitely started rolling (e.g. SANS is pushing it hard now) it won't be hurtling down the highway at full speed. 2011? Sure, maybe! :-)
• More vendors will release SaaS versions of their security technologies and new SaaS security vendors will be launched.
• Few people will be on the market for “just the network firewall.”
• WAFs will finally boast near-mainstream adoption.
• A sizable percentage of log management users will feed application logs into their systems. Not just payment application (for PCI DSS), but various enterprise application logs as well (and, of course, web application logs)
• End-user organization will start talking (and buying) technologies specifically aimed at protecting virtual machines and other virtualization technology (the first year of “virt sec” tools will be 2010)

Overall, we will be approaching those thresholds – with unpredictable and interesting events likely during the course of the year!
Decade predictions will follow next!!! Go “security 2020”!
Possibly related posts:

• My 2008 predictions and their 2009 review
• 2009 predictions tracker

Three More Fun Presentations Set Free

As it is traditional, I am setting free three more of my recent security presentations:

• “Implementing and Running SIEM: Approaches and Lessons” (HOT!), given in St Andrews in Scotland in November 2009. All SIEM/SEM/SIM/log management people, check it out. You can get most of it here with voice… but there is a catch :-)
• “PCI 2010: Trends and Technologies”, given at “PCI 2010: Trends and Technologies” by BankInfoSecurity. You can get it here with voice and some fun subsequent discussion. It is about PCI DSS and contains the nor-infamous floor-and-ceiling picture…
• “PCI DSS Myths 2009: Fiction and Reality” (a slightly updated version of my PCI DSS myths), given at a recent ISC(2) webinar called “PCI 360: Multiple Perspectives”. You can get it here with voice.

Happy holidays! What better way to celebrate the season is there then to read up on security? :-)

Possibly related posts:

• All posts with presentations
• My slideshare stash
• My docstoc stash
• Fun security papers and presentation released!
• “SIEM Bloggables”
• “On SIEM Complexity”

PCI Compliance Book at 50% TODAY

It looks like fine folks at Syngress / Elsevier  have given everyone a BIG holiday gift: our "PCI Compliance" book at 50% off with code 97561 (not sure for how long the discount code will work ...maybe just today). To use the code, buy the book direct from the publisher here.  

This is awesome, pretty much! Even if you hate PCI :-)

And if you came here too late, but still in December, use this old code for 30% off. If the above also doesn't work, feel free to use the Amazon icon on the left.

BTW, while you are at it, check out the book website: www.pcicompliancebook.info

Think about! PCI DSS, massive holiday shopping ... what can possibly go wrong? :-)

Cloud Security Alliance Guide 2.0 (well, 2.1 Actually) is OUT!

Cloud Security Alliance (CSA) Guide next major release is OUT today: press release, full document [PDF].

It's full name is now "Security Guidance for Critical Areas of Focus in Cloud Computing." I did contribute to the compliance domain (what is more fun than PCI in the cloud, he-he? :-)), full domain documents will be released soon here.

Unintended PCI DSS Consequences IS The Devil!

No, sir, PCI DSS is STILL not the devil. However, the devil is in the details ;-) This post attempts to analyze some of the details and is inspired by a really insightful conversation I had with Joshua Corman of 451 Group. In particular, this post is about the devilish nature of some unintended consequences of PCI DSS.

Let’s start from something truly despicable (WARNING: vomit alert!)

the purpose of security measures is to minimize legal damage

after complete loss of all critical data (or after other EPIC security FAIL)

by claiming that “adequate protections were in place”

If this line does not cause you (assuming you work in security) to go into seizures, I am not sure what will (maybe a lightning strike will?) I can barely type it, in fact, it is so disgusting :-) This is the evil side of otherwise benign phenomenon called “diligence.”

What it has to do with PCI DSS and the devil? Let’s explore it.

Security programs built and run ONLY as “a post-hack lawsuit defense” are indeed despicable. And so are compliance programs that are “mistakenly” labeled “security program.” And I’ve long claimed that organizations that “magically” arrive at “all we need to ‘be secure’ is to deceive a QSA” have only themselves to blame for their intrusion losses. Despite that, we all agree that there are plenty of organizations like this; in the past they were just negligent and now they are “fake PCI negligent.”

However, now there is definitely a market for “fake PCI security”, “get compliant and think you are secure”, “free PCI compliancy”, “guaranteed secure web site seals” and other scams. All these shops were not in business a few years ago. In addition, given such market, other security vendors have dedicated efforts to compliance-focused tools – obviously at the expense of thereat-focused tools and functionality. “All we need for web app security is PCI DSS Req 6.6” is one example of it (“only 6.6” is clearly better than no web application security whatsoever, of course!) – and if most customers “only want PCI”, this is what will get built at vendor shops.

And “anti-assessor” features might not work as well against attackers.

As a result, it is hard to find a niche within a security market which is not affected by regulatory compliance. DLP (see discussion here)? DAM? It affects even those technologies which are not even when not mentioned/

That is not PCI’s fault, of course – but this unintended consequence of PCI is quite devilish. PCI certainly plays a huge role in improving security; however, through the above mechanism it does seem to play for the opposite team as well…

Now, some of these compliance-focused efforts are actually quite beneficial for security. If we treat compliance as “validated security” (see discussion after this post away for details), then evidence of security measures being deployed and being effective does not just make the assessor happy. It actually helps you run you security program better – and help prove its value to senior management. For example, PCI push for more logging clearly helped both compliance and security.

As Adrian said in his recent post, “They need to have WAF to comply with PCI, so they bought one, but no one mandated they use it effectively. Security professionals really care about security, but the executive management cares precisely as much as legal and finance tells them to.”

In other words, some of PCI consequences is The Devil – they make people focus on things that might be suboptimal from the security point of view. And they make some think that there are easy solutions for very, very hard problems….

Enjoy!

P.S. This is posted by a bot, all comments will be responded to when I am back.

P.P.S More on this in the future (treat this as Part I of the ongoing debate)

Possibly related posts:

• Compliance != Security, Does Security = Compliance?
• More PCI Devil Defense
• Tales from “Compliance First” World
• Making PCI Easy?
• Risk vs Risk

More VzDBIR Awesomeness!

“2009 Data Breach Investigations - Supplemental Report: Anatomy of a Data Breach” is OUT! Grab it here or here at their blog.

Some highlights follow below:

• This covers the use of keyloggers in investigated breach cases – note a high percentage of stolen records:

BTW, read the case study after this table – very insightful

• This tells the same sad story, but about backdoors and bots – note a high percentage of records and the use of SQL injection:

Also, read the case study after this; it has gems like “as to how the assailants first gained access, investigators found a non-sanctioned commercial remote
desktop program on one of the R&D workstations [that handled super-secret ‘business-buster’ data].”

• The attack entry on SQL injection is event more fun – note the reference to database logs (“Routine log monitoring (especially web server and database)”):

• Other fun bits (the whole thing is one big bundle of fun though!) are: “Striving for perfection in any one control is inefficient and introduces single-point of failure dependencies” and “loose-grained access control applied to routers, firewalls, and other network devices are extremely efficient due to the large number of known and unknown problems they mitigate.” [please shove it to folks who proclaim ‘firewall is dead’] I also liked the VzBIR vs DataLossDB comparison in the appendix.
• Conclusion: Verizon report series exude pure awesomeness!

Do read the full supplemental report!

Possibly related posts:

• Breach Report 2009 Day …

"PCI Compliance" Book Is Here!

Finally, the PCI book is here in the flesh. I decided to use this opportunity to try video on my blog. Here it is:

Possibly related posts:

• “PCI Compliance” Book 30% Discount code

  
  

Log Management + SIEM = ?

Lately, something made me think of using log management WITH security information and event management (SIEM) - I suspect it was either this or maybe this zombie here. I did spent some time in my career building SIEM tools and then spent some building log management. Nowadays, their “separate identities” are pretty much widely accepted; even “Big G” combines them in the same document, but calls them out by name separately (this, BTW, took about 2 years of fierce arguments back in 2005-2007 :-))

In any case, my recent bout of thinking revealed four scenarios, crudely depicted on the image to the right:

Those are:

1. Log management as a foundation and SIEM as [one of the] applications: this is what I call “a common sense scenarios” since it is so …well… common sense. It can also be called “grow up to SIEM.” By some strictly unscientific estimates (=random guessing), it accounts for maybe up to 50% of SIEM deployments. This is the case where an organization gets a log management tool and slowly realizes the need for correlation, visualization, monitoring workflows, etc.
2. SIEM and log management deployed together alongside and at the same time: this is what I call “emerging scenario” since more people now get both at the same time (from same or different “best” vendors). I have no idea about the percentage of adoption here, but likely vendors who offer SIEM and LM can attest to the growth of this scenario. Indeed, if you somehow realized the need for correlation, you better save all the logs and have an ability to perform efficient search and raw data analytics.
3. SIEM=LM: this scenario means that either you are small (and use the same tool that can handle simple SIEM and log management functions) or, if you are large, you’ve been duped by the vendor who said “they are the same thing” [today they are still not and a smart vendor won’t tell you this – eventually maybe they will be…]. Admittedly, “one box with SIEM+LM functionality” can work in principle and for smaller environments, but typically there are too many things competing for CPU, RAM, network and disk (e.g. correlation and indexing are both resource hogs…). Still, this might well be the #1 by the number of deployments due to its applicability to smaller (and thus more numerous) environments.
4. SIEM deployment with LM as an archive: this scenario arises when somebody buys a big fat SIEM – and then, over time, realizes that something is missing. As a result, a log management tool is deployed to "dump” all logs into and (sometimes) perform analysis of the raw logs that SIEM “rejects” (i.e. doesn’t know how to parse, normalize, categorize, etc). Specifically, incident response and PCI DSS come to mind here.
5. “SIEM Shield” [UPDATED!]: the final 5th scenario is so obvious, I completely forgot about it :-). While it is similar to both #2 (simultaneous SIEM and log management deployment) and #4 (log management as an archive for a SIEM), it is also distinctly different – and VERY common. In this case, an inherently more scalable log management tool is deployed in front of SIEM (typically after SIEM is first implemented, which is similar to scenario #4) to serve as a shield and filter to protect a less scalable SIEM tool from extreme log flows. It is not uncommon to only send every 10th event received by the “log shield” to a SIEM, hiding behind it. At the same time, all received events are archived, just like in case #4.

Obviously, it goes without saying there are lots of “log management only” (still growing) situations and some “SIEM only” (likely shrinking) deployment scenarios. But their are not the subject of today’s note here.

BTW, today is my birthday :-) … and I am writing about SIEM. How cool is that?

Possibly related posts:

• On SIEM Complexity
• All posts on SIEM.

“PCI Compliance” Book 30% Discount code

I have not yet received my copy of “PCI Compliance” book, but I was told it is OUT in the flesh.

During the entire “launch month” – December 2009 – you can get the book at 30% off using discount code: SYNGRESS30 

Here is some more info:

• Book website (check out a couple of free PCI DSS sample policies there!)
• Official page of “PCI Compliance” at Amazon
• Book page at Syngress website (has full book Table of Contents); for the above discount code, you have to buy it from here.
• My co-author’s Branden Williams website and blog.

BTW, we worked really hard on the book (and then the editors worked on us :-)) - despite this, some typos are unavoidable. Please report them and we will add them errata pages.

Enjoy!

Monthly Blog Round-Up - November 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 spot this month (by far!) is deservedly taken by “Smart vs Stupid: But Not Why You Think So!” You need to go read it to know why it is so awesome :-)
2. “Top Log FAIL!” is still hot! The post summarizes the most egregious, reckless, painful, negligent, sad, idiotic examples of “Log FAIL.”
3. “On SIEM Complexity” is next – it is a piece about Security Information and Event Management (SIEM) and why it is / is perceived as “very complex.”
4. “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.”
5. “SIEM Bloggables” post covers key SIEM use cases – it is part of the presentation which is yet to be posted.
6. “More PCI Devil Defense” is the next iteration in the ongoing industry discussion of the value of PCI DSS for information security.

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

1. Gunnar Peterson
2. Dancho Danchev blog
3. Richard’s TaoSecurity blog
4. Dmitry Evteev blog
5. Adam O’Donnell blog

Thanks for all the link-love!

See you in December when I will post both monthly and annual blog round-ups (see my previous annual “Top Posts” - 2007, 2008)

BTW, somebody said that this year is a good year to post not only next year’s annual security predictions, but also next decade security predictions. Now, that is what I would call super-fun! :-)

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

• 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 might be available for fun consulting projects related to PCI DSS, log management, SIEM, etc. Please see the services list at my consulting site.

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