This picture depicts log management and SIEM maturity curve and is taken from a soon-to-be-released [eh..make that when-my-consulting-client-decides-to-release-it] Guide to SIEM and Log Management. It says it all – and if your organizations tries to enter in the middle…well... FAIL happens:
Enjoy!
As we all know, blogs are a bit "stateless" and a lot of useful security reading material 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.
Can you achieve “security goodness” (and common good) by FUD and [possibly] stretching the truth? Let’s debate this one!
The story started here with this letter from an unknown-but-now-infamous PoS (=point of sale aka cash register – for the non-PCI crowd) vendor about using Windows 2000 after Microsoft EOL’s it and no more security updates come. The letter makes an argument that any OS no longer supported by the vendor will be automatically out of compliance. StorefrontBacktalk, that covers retail tech (and payment security), has a good story on this here. They say:
“For your overflowing folder marked “Ludicrous PCI Scare Tactics That Too Many People Believe” comes a renewed effort from some security vendors to say that out-of-date operating systems this year will cause instant PCI non-compliance. ”So, the statement about “no security patches –> no PCI compliance” clearly does not hold water. It is what is known as “a lie.” Compensating controls can definitely be used in this case and PCI Council even has a FAQ entry about this very subject (quote: “Systems that use operating systems that are no longer supported with new security patches by the vendor, OEM, or developer are not necessarily out of compliance.”)
UPDATE: this is HUMOR! HUMOR!! HUMOR!!!
It all started from this tweet: “if you read on #PCI and #APT on the same day, you get some pretty darn interesting high.” Some more …mmm…thinking about the subject resulted in this blog post.
 | vs |  |
Later this week I will be at ShmooCon, doing a very, very, very fun panel on PCI DSS:
“An Existential Threat To Security As We Know It?
Joshua Corman, Michael Dahn, Dr. Anton Chuvakin, and Jack Daniel
Whether you love it, hate it, or are merely "friends with perks"- compliance is significantly changing what we call security. PCI has been accused of being the Spawn of Satan by some, and yet it has also been credited with advancing security by others. This panel of PCI experts, analysts, and victims will discuss and argue the realities of PCI: its origins, goals, and consequences (intentional and otherwise). PCI is having an impact on priorities, budgets, and personnel, which is being felt throughout the security industry. Unfortunately, there have been few informed discussions of PCI and compliance issues in the technical ranks of the security community. This panel will bring PCI subject matter experts with real-world experience to the technical security professional and hacker audience to discuss, engage, enrage, and argue about what may well be an existential threat to information security as we know it. The diverse viewpoints and experiences of panel members will guarantee a lively and often heated discussion, and will provide a broad base for fielding audience comments, questions, and criticisms. Bring plenty of Shmooballs to this session, you will need all you can get.
Joshua Corman is Research Director for Enterprise Security at The 451 Group and was previously Principal Security Strategist at IBM ISS; Michael Dahn is Global PCI QA Manager for a Verizon Business and was previously the subject matter expert in creating PCI DSS training for Visa USA, Europe, Asia-Pacific, LAC; Dr. Anton Chuvakin is a recognized expert in the field of log management and PCI DSS compliance, he is Principal at Security Warrior Consulting and former Director of PCI Compliance at Qualys; Jack Daniel is some guy with a beard and Sock Puppets who drives the ShmooBus.”
This time, BTW, I will have plenty of time to meet with people since I am in DC from Thursday to Monday. Drop me an email/tweet/etc if you want to meet up and talk SIEM, logs, PCI (well, better logs than PCI :-)), etc. In any case, see you all in Washington, DC later this week!
Reading "UK Security Breach Investigations Report 2010" [PDF] (source) makes for some truly blood-curdling reading.
Example:
"Prior to having suffered a cardholder data compromise, 26% of the organisations had believed themselves to be PCI DSS compliant upon submission of completed
Self Assessment Questionnaires. The investigations also revealed that none of the organisations met all requirements of the PCI DSS."
This is how it starts. It is all downhill from there:
"Indeed, in just over one quarter of the cases, none of the twelve requirements were met."
and
"7Safe has found that all the merchants who have been subject to a breach and have completed an ASV scan
have believed themselves to be secure based solely on the results of this scan"
I literally cannot read any further, since I am starting to get angry! Can somebody come and kick those merchants in the balls, please? Actually, no. Do not kick them! Stand on their balls. :-) Then have then buy our book!
Recently somebody asked me: what do I mean by LOG CONTEXT? And what is “log enrichment correlation?”
This picture explains it clearly:
For each element in the log message shown, you can gather some contextual information. Contextual here simply means that the information is gathered NOT from this particular log entry. For example, a log entry might contain an IP address, but its DNS name needs to be grabbed from the DNS server, which “enriches” the log entry and makes it more useful.
One of the ways SIEM and log management systems performs such enrichment is by gathering and displaying context information. Context information is the additional information required to make the limited details available within the log entry more meaningful. Context information does not come from the logs themselves [not from the entry in question – it might come from other logs], but originates in the surrounding IT environment such as other systems inside or outside the organization.
As I say above, one of the simplest example of context data is name resolution: the DNS names or Windows NetBIOS host names are added to the logs. While the log file may have already provided IP addresses, the added context of a human-readable name makes the log more meaningful. Normally, DNS names are not present in logs, but have to be obtained by queries to a DNS server. The SIEM tool might find context data in a variety sources, including:
BTW, back in 2008, I did a poll on what context is the most useful for log analysis. That is what came back – it shows that some useful context is simply documentation on what the log mean (might be pulled from the internal knowledge base of a SIEM product):
Enjoy!
Somebody showed up at my door the other day and said “I want to buy some correlation!” Don’t get me wrong – I love correlation; I developed correlation rules for a living some time ago. Correlation is totally fun. That’s why I wrote a couple dozen papers defining and explaining security event correlation (example here, here, here).
Despite all that, I am still shocked when I see people who define their requirements for an expensive security product (such as Security Information and Event Management – SIEM) in that form: I want to buy correlation. BTW, I ridiculed this as one of the “worst practices” here in this fun presentation – see slide 11.
First, correlation engine is … well… an engine. What can you do with an engine? Unless you are an engine mechanic and think that it is fun to just tinker with it, you probably prefer this engine to be embedded in a car. And car is that thing that allows you to get from A to B faster [than walking … unless you drive up RT101 in the morning]. So, you are buying “transportation” and not “correlation.” Or, in our security realm, you are buying [a chance for] automated near-real-time detection of incidents. Or a tool to simplify your security monitoring.
Second, engine needs oil and gas to operate. What is correlation “oil and gas”? Content! This jargon term simply means correlation rules, alert/notification templates, views, workflows and reports that define how correlation will actually solve your particular problem. That is not everything that allows the engine to contribute to solving “the transportation problem,” but it is pretty darn important. Even engine mechanics drive their cars using oil and gas, even after they build that extra turbocharger on the side :-)
Third, the above two points should tell you that you need to know what problem you are trying to solve with correlation before you go “shop for correlation.” And here is something magical: don’t pick a problem of “improving food quality in a buffet on a ‘Titanic'.” Pick ship survivability instead! (BTW, “Titanic” was compliant!) What I mean here is that if you are not ready to handle real-time notification of incidents, then focus on investigations first with log aggregation, indexing and searching. This paper should jolt your brain in this useful direction.
Now, if your organization is looking for some help defining the requirements for a SIEM or log management product, choosing the right tool etc, figuring out how to operationalize it, I can definitely help.
BTW, this is posted by the scheduler. I am away attending to a family emergency; response to comments will be slow.
Possibly related posts:
As I am preparing to attend to a family emergency and thus go “offline” for a while, here is something fun stuff for my dear readers:
Despite my older post on this (“MUST-DO Logging for PCI?”), people continue to harass me to create an “authoritative” guide on logging for PCI DSS: what events to log? what details to log? what logs to retain? what logs to review? how to review? etc, etc. BTW, the quotation signs above are there since only your QSA holds an authoritative view on the subject; the rest have to settle on “defensible” view, such as the one from my very self :-)
So, OK, I will [eventually] share my entire defensible guide on logging for PCI DSS, even thought it doesn’t sound anywhere near as glam as an authoritative guide would :-). In this guide, I analyze all the PCI DSS logging requirements (in Requirement 1, 5,10,12 and all others too) and translate them info a logging policy and more-or-less-actionable tasks and operational procedures, while making few assumptions here and there about your organization. What it more important, I cover both PCI logging requirements that you need to achieve PCI DSS compliance, stay compliant with these requirements and what you need to [most likely - see the comment about QSAs above] get validated. It goes without saying that such logging will be actually useful, following the traditional "compliance+" model.
Still, no externally-created guide will ever be fully effective in defining logs and logging for your organization, for your applications, for your in-scope PCI environment. Indeed, the only way to get it right is to hire a consultant and have him customize and “operationalize” the document by replacing the assumptions with actual facts about your organization [oh-nos, I started to sound like a consultant already :-)]
The document will be shared later this year (unless I roll it into my upcoming book on log management..oops!.. that was a secret :-)) If you want it sooner, you can hire me to do this for you organization as some other people just did. Here are some examples of what I built for this F1000 consulting client:
Logging Policy
In light of the above, a PCI-derived logging policy must at least contain the following:
This post and, of course, the paper included below, are inspired by some work I’ve been doing on so-called “ongoing compliance,” in particular as it applies to PCI DSS. The table in the paper below is the result of my going through the text of the Data Security Standard and extracting all the requirements which are NOT “one point in time”, but periodic in nature. I did it just to prove to some buffoon that PCI actually mandates security things to be done periodically and NOT just before the assessment were to start or SAQ was due. No deep thinking here, but a useful reminder about the fact that …
| PCI DSS Requirements Version 1.2.1 | Period | |
| 3 | 3.6.4 Periodic cryptographic key changes § As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically § At least annually | 1/year |
| 6 | 6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: § Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes § Installing a web-application firewall in front of public-facing web applications | 1/year |
| 9 | 9.5 Store media back-ups in a secure location, preferably an off-site facility, such as an alternate or backup site, or a commercial storage facility. Review the location’s security at least annually. | 1/year |
| 9 | 9.9.1 Properly maintain inventory logs of all media and conduct media inventories at least annually. | 1/year |
| 12 | 12.1.2 Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment | 1/year |
| 12 | 12.1.3 Includes a [security policy] review at least once a year and updates when the environment changes | 1/year |
| 12 | 12.6.1 Educate employees upon hire at least annually | 1/year |
| 12 | 12.6.2 Require employees to acknowledge at least annually that they have read and understood the company’s security policy and procedures. | 1/year |
| X | On-site QSA assessment (Visa L1, Amex L1, MC L1-2, etc) or self-assessment (Visa L2-L4, Amex L2-3, MC L3-4, etc) | 1/year |
| 1 | 1.1.6 Requirement to review firewall and router rule sets at least every six months | 1/6 months |
| 11 | 11.1 Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use | 1/quarter |
| 11 | 11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades). | 1/quarter |
| 11 | 11.5 Deploy file integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files or content files; and configure the software to perform critical file comparisons at least weekly. | 1/week |
| 10 | 10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS). | 1/day |
| 12 | 12.2 Develop daily operational security procedures that are consistent with requirements in this specification (for example, user account maintenance procedures, and log review procedures). | 1/day |
| A lot of other processes require to “maintain”, “ensure”, etc - as well as procedures mentioned in item 12.2 | As needed |
If monthly, why not annual blog round-up? These are my top popular "Security Warrior" blog posts for 2009. This list covers the posts most popular in 2009, not necessarily only those written in 2009. Enjoy!
As we all know, blogs are a bit "stateless" and a lot of useful security reading material 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.
This month I am continuing a new tradition: I am going to thank my top 5 referrers this month (those that are actual humans, that is). So, thanks a lot to the following people whose blogs sent visitors to my blog:
Thanks for all the link-love! And now back to carving powder at Heavenly :-)
See you in January; also see my annual “Top Posts” - 2007, 2008 and the coming 2009!
Possibly related posts / past monthly popular blog round-ups:
Obligatory “added everywhere” posts :-)
How impossible is it to predict anything in the field of information security? 10 years? Into the future? Still the purpose of this endeavor is not necessarily to “have everything right”, but to have fun in the process and to get people to think beyond the immediate tactical horizon in information security.
Let's start from the overriding trend that will define the rest of the discussion:
That trend is that the walls between the computer world (aka the Internet, cyber-anything, online, virtual, cloud, etc) and the “real” world (aka meatspace, Earth, “outside”, “reality”, offline, etc) will break down beyond a certain interesting point, both on the perceptual level and in reality. With – duh! – huge implications to our profession and practice of information security.
What do I mean by this?
Whether perception is reality on not, studies I’ve seen (examples, more, more, more) point that most people behave differently in an online world and in the so-called “real” world. People can also point at many factual differences between online world (that happens inside the human created medium – networked devices) and the outside. I believe that this difference explains at least some of the current information security problems – on some deep level people just don’t see computer intrusions and other issues as “real enough” for them. Even the simple fact that we have “crime” and “cybercrime,” points that this difference.
So here is the punch line: I think that in the next 10 years these two worlds will be much closer to each other, in both perception and “real” reality. HUGE implications to information security will result.
Where's the evidence? Here are all the things that I bundle in that “ultimate convergence”
All of the above will make information security and computer security (as well as a dying art of network security) PAINFULLY more relevant for people’s lives. If an attacker from a remote location can crash the computer and steal your data, this is bad. If that same attacker can impact what you perceive to be your “real world,” the game changes. And change it will - probably even before 2020. What will stand between such attacker and others? That’d be you and me, my dear reader :-)
The above convergence will also be combined with these “side trends”, all with big impact to security:
So, I don’t know what features your log management system will have in 2020 or what the label “firewall” will mean in 2020, but I know is that it'll matter much, much more than now. Despite all the harping about information being “critical for business”, we only protect information today. Sorry for a bit of grandstanding here, but we will literally protect the world in 2020…
Enjoy!
BTW, other fun views of the year 2020 technology are here (created in 1994), here (created in 2005), here and in many other places.
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.
PCI DSS section:
Enjoy!
Possibly related posts:
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):
As it is traditional, I am setting free three more of my recent security presentations:
Happy holidays! What better way to celebrate the season is there then to read up on security? :-)
Possibly related posts:
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 (CSA) Guide next major release is OUT today: press release, full document [PDF].
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:
“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:
BTW, read the case study after this table – very insightful
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].”
Do read the full supplemental report!
Possibly related posts:
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:
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:
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:
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!
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.
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:
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:
Obligatory “added everywhere” posts :-)
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:
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:
FYI, this week I spoke at these two fun PCI DSS events (both virtual):
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!
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 :-)
PCI DSS section:
Enjoy!
Possibly related posts:
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:
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!)
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:
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:
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
· Uncertainty
· Doubt
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…
