Anton Chuvakin Blog - "Security Warrior"

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

2009-11-06T01:11:00.001-08:00

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.

Links for 2009-11-04 [del.icio.us]

2009-11-05T00:00:00-08:00

The Limitations of Risk Assessment | Blog | Infosecurity Security Adviser

Releasing Many Of My Security Papers!

2009-11-04T05:05:00.000-08:00

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

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

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

Notable papers released:

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

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

Possibly related posts:

Everything tagged security reading.

Links for 2009-11-03 [del.icio.us]

2009-11-04T00:00:00-08:00

Monthly Blog Round-Up – October 2009

2009-11-02T15:44:00.001-08:00

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.

“Top Log FAIL!” is hot! The post summarizes the most egregious, reckless, painful, negligent, sad, idiotic examples of “Log FAIL.”
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.”
“MUST Read on Walmart Intrusion” includes the juicy bits from the full story at Wired. Some amazing examples of “log FAIL” are mentioned there, BTW.
“Open Source CLOUD SIEM, Anybody?” post is where I shared some ideas on how to go about building an open source SIEM/SIM/SEM tool using cloud computing. It seems to have attracted a lot of attention. And it should have :-)
“Compliance != Security, Does Security = Compliance?” contains some fun analysis of situations where not only “compliance != security”, but also “security != compliance.” This theme will definitely be explored in the future.

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

Thanks for all the link-love!

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

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

Obligatory “added everywhere” posts :-)

I am not at Qualys anymore and looking for the next big security idea to work on! Meanwhile, I might be available for fun consulting projects related to PCI DSS, log management, SIEM or other fun security things.

Smelly Goat vs Flying Unicorn

2009-10-31T05:05:00.000-07:00

On FUDSec FUD piece and “data-driven” security.

Q: If you ride a smelly, ugly goat along the road and then meet a handsome stranger who promises to give you a new ride: a beautiful unicorn that can fly, teleport, butt enemies with its horn and doesn’t need any cleaning, should you take it?

A: No! Unicorns are mythical creatures. Please keep your goat for now :-)

Notes from CSI2009 Annual Conference

2009-10-30T05:05:00.000-07:00

If you’ve ever been to a ghost town before, you didn’t need to go to CSI this year. It seemed to have only a few people even at HOT topics. Initially I thought that it was because I spent only the last day of the show there, but others told me that it was not the case. I saw a ghost of risk management there, BTW…

Other people’s impressions:

Rafal Los on CSIAnnual (some observations about lack of passion, which I didn’t notice since I spoke on PCI DSS and PCI=passion :-))
TechRumble on CSI (some fun cloud stuff that I missed at the show is mentioned there; quote: “Today even a 1-person startup can compete with Google and IBM in terms of infrastructure”)

Also, if you’d like to see my “PCI DSS as a framework for security” presentation (with voice and all!), go here. It is essentially the same presentation that I gave at CSI, minus some magic tricks I played on the live audience :-)

BTW, if you suffer from mild voyeurism, you can see a picture of me giving this presentation here (yes, I had explosions and demons in my PCI presentation :-)).

Possibly related posts:

All conference stuff
Notes from NIST SCAP 5th Security Automation Conference (a day before CSI2009)

Notes from NIST SCAP 5th Security Automation Conference

2009-10-29T02:05:00.000-07:00

Sadly, I only had one day to spent at this fun event, but it was definitely well worth it. I missed some of the keynotes as I was speaking with various people, so the first presentation I went to was supposed to be about “HBSS Open Framework.” In this reality :-), it was replaced by John Pescatore from Gartner. He started to go about FISMA and NIST 800-53 (and even FDCC) popping up in commercial space (contractors mostly), but then quickly boosted into the cloud :-)

One fun thing he sad was that what he used to call “nightmare [cloud] scenario” is now called “everybody scenario.” His theme was that we used to think that security needs to be included when new [cloud] infrastructure is being built BUT (!) this moment is slipping away FAST! He even uttered that we need to “inject security back” as cloud train is speeding out of the station. His vision can be summarized as “MySecurity.cloud” – some kinda SaaS service that you go “through” before accessing other cloud services. He then quickly summarized what is the status of such “cloud exodus” now: vulnerability management is "”fully gone”, various filtering (“network security in the cloud” - he called it “MitM security”) is going now, what will go next (log management or SIEM)?

Another interesting thought was about “full stack, continuous VM” – don’t just check for presence of Skype (for example – he really means “all apps” including consumer apps on work PCs!) or for vulnerabilities in Skype, but check whether Skype is configured securely. He also show this fun chart:

/\ \| axis: value to business
high	embrace	contain
low	disregard	block
	low	high	axis: security pressure ->

[I love how Gartner folks can visualize something complex into a neat chart…]

Another insightful thought from him was that the world has shifted away from directories. There is “no directory for cell phone” – instead “ring of trust” such as Facebook is it…

Next I went to see Ed Bellis fling some SCAP goodness. The main idea is that one can build a tool to automate the layer of tasks and issues above vulnerability assessment. Basically, the whole workflow from discovery –> remediation task planning –> fixing the issue –> retest –> validate + track everything for all regular and custom web application vulnerabilities. I find it really, really curious that VM vendors didn’t do it like this …. So, this was very useful and checking the slides

when posted will come hand. I found it interesting that there is absolutely no reconciliation between “security asset management/discovery” with “real IT asset management.” IMHO it drives the nail into a coffin of “IT ops and security convergence” theme that many folks adore … Also, web application flaw severity scoring is still a big hole. Where is CWSS when you need it? :-)

Next I made a mistake of going to a vendor presentation. It was so salesy I almost puked :-) BTW, the name of the vendor rhymes with “BigAss.” Please, dear BigAss folks, next time send somebody who can talk substance and not just that you are “strong in government!”

As far as trend watching, for a brief second I sensed that “SCAP use outside of the government” is an emerging trend, but it really isn’t. Using CVE and other identifiers as well as CVSS for scoring – outside the government or anywhere else for that matter – does not SCAP use make. It is simply called “common sense” :-) Now, if you found some use for the juiciest pieces of SCAP – OVAL and XCCDF – then we are talking…

Next I went to CEE presentation and my log standards challenges presentation. Obviously, this was the highlight of the day. At this stage, BTW, now I am convinced we can win this one and start standardizing the logs! In particular, we will release the architecture specification in about a week or two.

I am writing this on the train to CSI2009, notes from that show will come tomorrow…

Presentation from NIST SCAP

2009-10-28T02:05:00.000-07:00

As mentioned before, here is my presentation from 5th Annual IT Security Automation Conference in Baltimore, MD on Oct 26-29, 2009.

LogChaos: Challenges and Opportunities of Security Log Standardization

View more presentations from Anton Chuvakin.

Onto CSI2009 tomorrow; my PCI presentation there is going to be totally awesome :-) It will feature … The Devil!!!

Also, events notes from the NIST event will follow later.

See you there!

Top Log FAIL!

2009-10-27T02:05:00.000-07:00

The Wal-Mart story inspired me to summarize the most egregious, reckless, painful, negligent, sad, idiotic examples of “Log FAIL.” Here they are:

Logging disabled: if you got a system which had operational logging enabled by default and then you turned it off before deploying in production – congratulations! You truly earn your title of a Log Idiot! :-)
Logging not enabled: this is more sad than anything else … and the person who will suffer the most from this is likely the one who has caused it. After all, you’d need those logs at some point yourself. There is nothing sadder than see a person having to explain to management, police, FBI, press, QSA, SEC, whoever: “Well, logging … was … never … enabled!” (check out this motivational horror story)
No log centralization: Windows admins, read this one – logs on the machine that crashed, was 0wned or even stolen will do you absolutely no good. It used to be that only Unix administratory can do this (via the magic of /etc/syslog.conf line “*.* @loghost.example.com”), but you, on the Windows side, could not. Please notice that the world is different now! (check out this deck on benefits and tips related to log centralization)
Log retention period too short: the picture on the right should make this item (as well as the one above) painfully clear: doing “the right thing” and building the centralized logging infrastructure and then limiting the retention to 30 days is still “log FAIL.” Many, many scenarios today require logs from the past – for the juiciest examples check all the recent “compromised in 2006 – discovered in 2008” stories (see some here in this deck)
No logging of “Granted”, “Accepted”, “Allowed”, etc: I don’t even know where to start on this one – maybe thus: logging a firewall “connection blocked” events simply means that the firewall was doing its job, logging “connection allowed” shows that somebody is now in your network… The same idea applies to logging “login failed” and missing “login successful” – please make really sure to always log both (read this tip for more examples, instructions and ideas)
Bad logs: if you are in operations, this is truly not your fault. But if you are in development – it probably is. Creating such logging classics as “failed successfully” and “login failed” [with no actual user name recorded] are fine examples of this “log FAIL.” Be aware that our work on CEE will fix it eventually, but more hilarity will have to transpire before it happens (see this deck for some ideas on how not to engineer logging and how to do it – and for some examples of hilarity, of course)
No log review or nobody is looking at logs: I am saving this “log FAIL” for last; logs are created to be reviewed, monitored, searched, investigated, etc and NOT – I assure you! – to simply use up disk space (check my famous “Top 11 Reasons to Look at Logs” as well the classic “Top Logging Mistakes” for more info on this one)

BTW, check out Branden’s musings about the same subject here.

Possible related posts:

Fun Reading on Security and Compliance #20

2009-10-26T05:05:00.000-07:00

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 #20, dated Oct 25, 2009 (read past ones here).

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

Very, very bold statement: “Why On-Premise Log Management is Destined for Extinction” from my friends at AlertLogic: “why, for all but the largest organizations, hosting your own log management solution in your data center simply won’t be a practical solution”
Some fun metrics-related reading: “A Bit on the State of Security Metrics” (quote: “Security is a complex system based on a combination of biological (people) and computing elements. Thus our ability to model will always have a degree of fuzziness.”) and Metricon 4.0 slides (some exude pure awesomeness).
Cyber Security Awareness Month is almost over. Here is my token tribute to it – a link to SANS “month of tips”” Day 1 - Port 445 - SMB over TCP, Day 2, etc. (BTW, here is somebody making fun of the whole thing)
This is hot shit (“5 Mistakes a Security Vendor Made in the Cloud”) and the sad part is that I know what the vendor is… Quote: "The client now doesn't trust itself and blocks everything." Good news? It was fixed quickly :-)
Securosis shares a very useful tip on database logging: “Database Audit Events” (full lists here) for popular databases
From the bizarro world, comes this LinkedIn thread: “When will Information Security professionals stop talking about ROI?”
Burton Group weighs in on SaaS security; key quote: “[cloud] vendors will provide the controls they feel are necessary to get and retain customers. They will provide proof to the customers of the controls if asked and as long as the proof does not increase their costs too much.”
Richard encounters a “data idiot” and beats him into the pulp: “"Protect the Data" Idiot!”, “"Protect the Data" from Whom?” (the answer to “How do you protect yourself from nation-state actors?” is revealed…) and “"Protect the Data" Where?” Read it!
Philippe on the shift to the cloud [PDF]. Quote: “One day, almost everything we do on private networks – manage information, applications, infrastructure, and services – will be accessible instantly and securely from anywhere and from any Web browser.”
EthicalHacker.net is doing another challenge, here.
We had an ROI war. Now another war is coming: “How to Value Digital Assets?” started it. The pile-up is here, here, here, here, here – hostilities continue…
Finally, Josh Corman (now a security lead at 451 Group) unleashes some awesomeness here at FUDsec: “Do the Evolution..” He uses what lately became one of my favorite ideas as well: “Can you name *one* security control we’ve retired?” He also bitch-slaps some folks with “… or we could continue to whine about PCI ruining risk management” :-) BTW, you also must read the turmoil in the comments…

PCI DSS section:

Good or bad data, but this is worth thinking about: “PCI Survey Finds Some Merchants Don't Use Antivirus Software” (PCI haters should read it too, BTW!) This is about folks who security is nowhere near PCI DSS levels. Key quote: “Around 10 percent of the respondents who said they were PCI DSS compliant said they weren't using basic security software such as antivirus, firewalls and SSL.” More comments on it here.
Fun interview with Bob Russo. Enough said. Quote: “How many [QSAs] have left the QSA program because they weren't able to recertify [after being kicked in the balls by the QSA QA SWAT team]?”
“Tokenization Vs. End-to-End Encryption: Experts Weigh in” (myself includes). “End-to-end” claim worry me in the same way intrusion PREVENTION worries me…

Enjoy!

Possibly related posts:

All other security reading posts.

On PCI and Whitelisting

2009-10-25T11:11:00.000-07:00

I am hearing some interesting rumors… But let’s take a step back. PCI DSS Requirement 5.1 mandates the use of anti-virus on systems in scope of PCI (“Deploy anti-virus software on all systems commonly affected by malicious software”)

Now, when people think “AV software” they think about classic anti-virus with daily updates, painful scans, etc. In other words, “enumerating badness”, blacklisting, FAIL, etc. Give relatively low adoption of the whitelisting for desktop security (and slightly wider adoption for single-purpose systems such as PoS or industrial control boxes), I was under impression that the issue of whether a whitelisting protection would be a satisfactory control for PCI Requirement 5 was never presented to a QSA.

Well, I was mistaken. It seems like many QSA WILL accept a whitelisting-based security application for Req 5, even if it is a pure whitelisting app with no embedded blacklisting mini-engine. Isn’t it cool?

And the rumor was that PCI Council will issue some kind of an opinion on this soon. So, maybe, just maybe, PCI gods will bless this technology into wider adoption – I think it might well happen. And I think it deserves to happen, especially since some vendors have usable implementations of whitelisting which does not plunge its user into “granular-policy-writing hell” (but more on this in the future…)

BTW, my favorite whitelisting vendor, Savant Protection (where I serve on the advisory board) is doing a fun webinar on Tuesday, October 27th.

Links for 2009-10-23 [del.icio.us]

2009-10-24T00:00:00-07:00

Open Source CLOUD SIEM, Anybody?

2009-10-23T10:59:00.001-07:00

"It's too bad I am not building an open-source SIEM … but if I would" (extra credit: guess the inspiration for this line), I would actually not build a software security information and event management (SIEM) product.

If I were doing it (and I am not!), I’d built an open-source-based “cloud SIEM” with a default option to have it hosted by the vendor (that is you) as well as with a possibility to have it hosted by the customer (that is, old school on-premise model). The latter option would give you a classic open source “product.”

Think about it! If you are a new company, you cannot afford to be in the appliance business. That leaves two choices: software and SaaS. If you want to sell software, you are probably insane, go lock yourself up :-) If you want to give away software and sell services, you are OK. But won’t SaaS be better? And you can combine it with on-prem model, if some folks insist. My recent employment made me quite SaaS-obsessed, since I had a chance to observe an excellent SaaS operation from the inside. It was amazing how easy it is to provision trials as well deploy the service in production, track usage and improve customer experience.

But let’s take a step back first! A lot of folks try to understand the relationship between “open source” and “cloud everything” (discussions about their relationship here, here, here and obviously here). The main idea here is the following: if people have “trust issues” with cloud providers, what is a better “mistrust breaker” than showing the source code for your solution? “Wonna audit?” - “Knock yourself out!” Moreover, if people have “hidden costs issues” with open source software, what is a better way to mitigate it but to offer to run it for them? No hidden costs, not even electricity…

So, if you are possessed by SIEM aspirations (and I am not!), head to the clouds. For starters, your tool will be easier to deploy and update. But what is much more important, you’d take a fare shot at solving scalability problems without being a database tuning uber-guru. Unlike early software SIEM vendors (FAIL!), you won’t have to sheepishly point in the direction of mammoth Sun boxes, you’d just fire up another EC2 instance (or a thousand). Moreover, on the scalability front, you’d have a fare shot against established SIEM vendors: I often hear rumors that even today, in the age of “cheap hardware”, some large organizations with loads of log data simply cannot architect a SIEM to handle all their security log data. And cloud computing leads to affordable scalability!

Solving these performance problems will let you use the CPU resources for log data parsing, correlation, stored data analysis and all sorts of other fun stuff. Storage, whether raw text or parsed data, will be even easier. Bandwidth will be a bit tricky, but I am leaving it out of this piece for a particular reason … don’t want to spill too much (I am leaving “the collection challenge” out as well).

Finally, as cloud applications [as well as web applications, in general] grow in importance, the whole idea of “SIEM in the cloud for the cloud” won’t be as naive. As we know, the need for auditing comes last (here), but when it does come, it will come in force and both SMBs and F2000s will have this problem. And it never hurts to be better prepared for the death of on-prem apps, if we are to believe certain visionaries.

So, throw together some EC2 magic, some database code and a sleek, well-designed UI to delight the users – and you are ready to do battle with foes 10x your size…

Any thoughts?

Possibly related posts:

Obligatory “added everywhere” posts :-)

I am not at Qualys anymore and looking for the next big security idea to work on! Meanwhile, I might be available for fun consulting projects related to PCI, log management or other fun security things.

My Fun PCI Webcast on Oct 27, 2009

2009-10-21T19:58:00.000-07:00

So, apart from flying to Baltimore, speaking at CSI2009 and NIST Security Automation conference and meeting a huge number of fun people, next week I will also be doing this exciting PCI DSS webcast, where I will unveil my latest idea.

Here is an embed that talks about it:

Enjoy!

And if you are in Baltimore at CSI or NIST - see you next week!.

P.S. Somebody (wink-wink) promised to bring cigars, please do it ;-)

Book Review: “Into the Breach”

2009-10-19T05:05:00.000-07:00

“Into the breach” by Michael Santarcangelo is actually a fun read; it seems to be a useful book on security for management. It is non-technical by design since it is about the people side of security. In fact, he presents security itself as “a human issue.”

One of my favorite sections in Part 1 reminds that many policy violations happen because people just want to do their jobs better (the author also claims that people “want to do the right thing” if such choice is easy enough). I loved the “compliance is not a video game” theme, where your faults do not have real world consequences, as well as “security as something inflicted upon the organization” and “security as a crash diet” themes. What is also interesting is that the book seeks to solve one of the key problems of “what is risky?” vs “what is only perceived as risky?”

The part of the book is Part 2 where author’s “strategy to protect information” is unveiled. The author then goes into some level of details on how to implement the strategy (run a pilot, “build a flywheel”, etc).

On the negative side, I was saddened that Michael succumbed to a popular insider myth (on page 11 – “70% of attacks are by insiders”) while trying to dispel another security myth. That is the risk anybody runs while quoting too many questionable surveys. Also, the book sounds too fluffy at times (e.g. the strategy is “understand-engage-optimize”, frequent advice to “be effective”, etc), but does seem to convey its message pretty well.

Overall, if you are managing security on a high level, or manage IT or even the whole business, read this book. It is short enough so that such people will read it and get the ideas! If you are a security pro and can handle a non-technical volume, grab it as well and keep in mind that this is a management book. After reading it, please give it you your manager!

Possibly related posts:

Praying to PCI Gods

2009-10-16T01:01:00.000-07:00

Obviously, inspired by Amrit’s “Exorcising the PCI demons” and, in fact, morphed right from it.

“… But let’s get back to Josh’s demonological metaphor and consider some of the ways that PCI resembles ...” the Benign Deity (specific deity is up to the reader…)

The God holds promise. PCI DSS offers its adherents access to the spiritual riches — and not only those attainable through debit and credit cards—so long as they know and respect (and validate!) PCI’s 12 commandments. While delivering its spiritual riches, it also makes its adherents BETTER in the process: better security, better businesses, better awareness of the threats.

The God is honest. PCI does not promise falsities such as “to make retailers secure against hackers.” It promises to raise them out of the ignorance and “0wnage” to finally having a modicum of much-needed security technology and process.

The sorry history of breaches, blowouts, and damaged reputations attests that there is a long and sometimes difficult road ahead of us and that both faith and hard work will be needed along the way.

The great thing is that PCI is likely the best that many organizations can use to protect a transaction technology based on account numbers, magnetic stripes, fixed user identities, and passwords.

The God is an inspiration for goodness. PCI has led countless companies and organizations to improve security and reduce their operational risks – as well as instill customer confidence.

Security professionals often find themselves assisted by the PCI God when they win an argument with management which then allows them to start taking actions to block threats and keep the business running and out of the negative press. PCI both inspires them to build a solid security program and helps them as a powerful force for good security.

The God loves humanity, even its haters. As at least one commentator has pointed out, the PCI standard is a brilliant way to shift responsibility for IT security from card issuers to retailers.

It is indeed brilliant since many merchants are negligent and lose card data in massive amounts as a result of their own ignorance, but issuing banks have to “eat” all of the card replacement costs which are due to no fault of their own.

Card issuing banks did not invent and institute the technologies that have proven so vulnerable to moderately skilled hackers. When a breach occurs, merchants shrug and talk about their devotion to promulgating security measures, knowing that the issuers will be left with all of the card replacement costs and some of the fraud costs.

The God is sometimes a sacrificial lamb. There are two groups that will vehemently attack the virtues of PCI by completely lacking any insight into it. One group are organizations who refuse to implement any security measures and prefer to be negligent and breach the social contract with their customers by losing their data left and right. The other group are idiotic perfectionists who want all the data to be protected all the time, no matter what the business impact. The latter group also wants somebody (but, obviously, not them!) to pay for an overhaul of the world’s electronic payment processing systems.

Vendors that provide security solutions and those that provide PCI assessment services, also known as qualified security assessors (QSA), will always position PCI as necessary and useful for security. Indeed, PCI God guides the willing – by providing the Data Security Standard – and motivates those still in the darkness – by providing the validation regime and His army of God’s Angels aka QSAs.

At this point, readers may ask, with all of the God’s awesomeness and track record in doing good even to those who prefer to remain ignorant, why do people criticize it? Well, remember the old saying: "I see..."

UPDATE: link for the "I see..." updated; the previous link had some bad language in comments. Thanks for one of my readers for pointing it out.

Amrit, sorry for all the quoting! :-) Enjoy!

Possibly related posts:

Five Reasons to Dislike PCI DSS – And Why They Are WRONG!

Notes from Cornerstones of Trust Conference

2009-10-15T09:50:00.001-07:00

I spent a day yesterday at Cornerstones of Trust Conference conference here in Bay Area. The event was “a cooperative effort of the San Francisco Bay and Silicon Valley chapters of the Information Systems Security Association (ISSA); and San Francisco Bay Area InfraGard.”

Here is what I attended; they promise to post the presentations soon:

“Compliance is Not The Same as Security” panel moderated by Robert K. West, CEO and Founder of Echelon One.
“Head in the clouds, feet on the ground - The business side of security in the cloud” by Tim Mather, Security Strategist and Subra Kumaraswamy.
"Why We Must Develop a New Model for Collaboration in Cyber Security: A Perspective on America’s Innovation Crisis", keynote by Pascal Levenson
“Cloud Computing Security - Practical and Actionable Security Controls to Assess the Cloud Vendor” by Brian Koref , Information Security Officer at KLA-Tencor.

Do you know what amazed me the most about this event? Lack of tweeting! Back at RSA and BlackHat, you can see flashes of TweetDeck everywhere in the audience, if you look from the back. Here – you see a lone gunman…eh... tweetman :-) In any case, I invented” the hashtag “#cornerstonestrust” and took some notes; read them here (as usual, you have to read from the bottom).

The conference was fun, but I couple of times I had my “buffoon alert” tingled. For example, somebody said that Heartland is suing their QSA and, to the best of my knowledge, that is not true. Cloud sessions – both of them – were pretty interesting. I learned what is “cloud angst” and realized that despite CSA work, people are still creating their own cloud provider diligence sheets (hopefully, the upcoming version 2 will help). The innovation keynote reminded me of my ROTC training in PsyOps. Namely, when you push your message too hard, people just start doubting you (our ROTC colonel also cautioned us from ever saying anything like “I am not saying it because I profit from it; on the opposite…” :-))

In any case, the conference was a day well spent!

Enjoy!

SANS Log Management Class – CDI2009

2009-10-14T05:05:00.000-07:00

As some of you know, I’ve been secretly working on a one day SANS Log Management class for quite some time now. A few trials were conducted and most-if-not-all-all guinea pigs survived their encounter with the log :-)

It now seems increasing likely that this class will be first launched at SANS CDI 2009 in DC this December.

Here is the information about it – please sign up now:

Log Management In-Depth: Compliance, Security, Forensics, and Troubleshooting (1 day)

Thursday, December 17, 2009 : 9am – 5pm

Description: 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.

Here is my “Author Statement” about the class:

Logs and log analysis have long been one of the most challenging areas of security; they are also closely tied to proper system and network administration practices. With regulatory compliance added on top with specific requirements on log collection, retention, and analysis (such as those found in PCI DSS), there has never been a better time to FINALLY get your logs under control. This class is the first-ever dedicated class on getting your log management project right. If you know that "you need to have those logs handled!", sign up and learn exactly how to do that. Many years of experience with logs went into this class and so you, an attendee, have a chance to avoid the most damaging mistakes and learn from many years of the author's experience with logging, log management, log tools, and the use of logs for various purposes.

More info and sign-up here!

Enjoy!

Links for 2009-10-13 [del.icio.us]

2009-10-14T00:00:00-07:00

Barracuda Networks buys Purewire - Atlanta Business Chronicle:

MUST Read on Walmart Intrusion

2009-10-13T12:05:00.001-07:00

Move over “Heartland-gate”, make room for “Walmart-gate” :-)

Wired uncovers a very fun story here. The juiciest quotes follow below:

On intruder goals:

“hackers targeted the development team in charge of the chain’s point-of-sale system and siphoned source code and other sensitive data”

On practices:

“at least four years’ worth of customer purchasing data, including names, card numbers and expiration dates, were housed on company networks in unencrypted form.”

On intrusion discovery (Was is … an IDS maybe? Ha, not funny!):

“a fortuitous server crash led administrators to a password-cracking tool that had been surreptitiously installed on one of its servers”

On logging:

“The company’s server logs recorded only unsuccessful log-in attempts, not successful ones, frustrating a detailed analysis.”

Please read the above line again! Again! AGAIN!

On some spoils of war:

“one of the documents that flew off to Minsk from a programmer’s machine was titled“POS Store Systems Technical Specifications TLOG Encryption and Financial Flows.” […] The hackers also stole or accessed files containing point-of-sale source code and executables, as well as additional proprietary documentation detailing the company’s transaction processing network.”

On PCI role:

“Wal-Mart says it received a number of [PCI DSS compliance validation] deadline extensions […] … became certified as PCI-compliant in August 2006 by VeriSign. After it discovered the breach in November 2006 …”

Read the whole thing, will ya?!

More On Security Vendors and PCI DSS

2009-10-13T05:05:00.000-07:00

Image by purpleslog via Flickr

This is a forced follow-up to my “Top PCI DSS Security Marketing Annoyances” post. What forced this is that a lot of folks are googling for “pci-dss market analysis” (double laugh, if you read my previous post)!

So, let’s analyze this a bit: what creates such tidal wave of PCI security marketing stupidity is a mindset of some vendors. They keep thinking “how to sell our shit using PCI?” and not “how to help organizations with PCI challenges?” This is what drives people to buy encryption instead of not storing the data, to deploy IDS sensors with alerts going to /dev/null, to scan web sites and never fix them, etc.

It is not uncommon for a security vendor to review a report that says that “only 6% of companies under PCI DSS use a technology X mentioned in the standard” (and that said vendor happens to produce) and then think “Wow, those merchants are stupid! They really should buy out shit NOW!” A quick question to merchants reading this: do you guys like it? :-)

The answer is obviously “NO!” You probably want said vendor to actually understand your problems with PCI DSS and then offer, well, SOLUTIONS! It is very hard for some vendor to shift to that helpful mode if they keep obsessing about the following: “Problems? What do you mean “what problems we solve?” – out bottom-line is our problem! ‘PCI-says-YOU-MUST-BUY!’” :-(

Yes, PCI DSS does mandate the use of many security technologies and it is prudent to mention that fact, whether you are vendor looking to help others or an end user looking to gain management support. Admittedly, I’ve long called PCI our sledgehammer of both awareness and budget for information security. But you can build a house with a hammer or .. you know how this metaphor goes :-) PCI DSS has a lot of energy to motivate people to improve security, please help them do just that!

But what if a merchant’s only perceived challenge is to “make QSA go away and take his PCI thing with it?” Obviously, the other side of the coin is merchants buying something (like a Dell box with the the label “FIREWALL” taped on [source here]) just to fake validation. This is where you as a vendor must evangelize! As Guy would explain, “evangelism” is not the same as “shouting the loudest” or “lying the vilest,” it is educating and then eventually converting the customer base to your way of thinking, which also happen to be the most useful one for them as well…

Finally, if you did get here after googling for “pci-dss market analysis,” please keep in mind:

Payment card security standard is called “PCI DSS”, not “PCI-DSS.”
There is no such thing as “PCI market” so there is nothing to “analyze”; PCI is not for sale :-)

Enjoy!

Possibly related posts:

Top PCI DSS Security Marketing Annoyances

Another Old Presentation: FIRST 2006 Logs and Incident Response

2009-10-12T08:37:00.001-07:00

I am releasing another one of my old presentations that I don't plan to reuse in whole: “Log Data Analysis for Incident Response.”

It was presented at FIRST Conference in 2006 in Baltimore, MD as a half-day tutorial.

FIRST 2006 Full-day Tutorial on Logs for Incident Response

View more presentations from Anton Chuvakin.

Enjoy!

Compliance != Security, Does Security = Compliance?

2009-10-08T09:33:00.001-07:00

Yes, I know, I know: math fans will cringe at my post title :-)

In any case, this post was inspired by a weird conversation I had with a particular QSA, who shall remain nameless. Right in the middle of the discussion, he uttered the usual “compliance does not equal security.” I nodded and made some incomprehensible agreement sounds.

And then he tossed a bomb: “And, as you know, security does not equal compliance.”

I was like: “… ah … eh … mmmm … really?… mmmm … I guess so”

But seriously?

Blabbing “compliance does not equal security” is a secret rite of passage into the League of High Priests of the Arcane Art of Security today. Still, it is often quietly assumed that a well-managed, mature security program, backed up by astute technology purchases and their solid implementation will render compliance “easy” or at least “easier.” One of my colleagues also calls it “compliance as a byproduct.” So, I was shocked to find out that not everyone agrees…

Let’s explore what the deal is.

First, we all know that “focus on compliance, ignore security” is a recipe for EPIC FAIL, usually of both. This is what I called “compliance first” thinking and it is indeed scary. For those who like FUD, you end up BOTH “0wned” and fined + embarrassed in the media [if you are big], on top of it.

Second, let’s assume for simplicity that you completely ignore regulatory requirements (not sure why anybody would want to do that though …) and just focus on your best understanding on what you need to do for protecting data, infrastructure, “keeping the wheels on,“ etc. If you execute perfectly on that and then go read, say, PCI DSS, you will find out that you likely have a gap. How big of a gap? I don’t now, but it is likely that closing the gap will not make you less secure. For some regulations, you can also argue that your measures protect the data better than the prescribed ones (see Branden’s “The Art of Compensating Control” for more on that). So, in the worst case, you’d waste a bit of time/money … or so the thinking goes.

Are we missing something?

Yes, we are! The third, most interesting case is: you read the regulations, you consider what you need for protecting data and then implement what you think is an intelligent combination of both. Then the assessor (PCI DSS)/auditor(other) comes to validate your compliance. And he finds a particular control that you implemented to protect the data (e.g. an appliance has no administrative access from the local network; it is managed by the vendor only) and says that this control is not compliant (e.g. requirement 8.5.6 says that you can “Enable accounts used by vendors for remote maintenance only during the time period needed”). Now, an obvious first reaction is to dismiss such assessor as an idiot, who just doesn’t “get security.” However, the situation is real: security thinking (even if stale at times…) evolves faster than any regulations. But I’d really like to hear about cases where security-inspired compliance requirements forced somebody to reduce security that was the motivation for those very requirements? I bet these would be extremely rare – and if you subtract those that are explained by the assessor/auditor inexperience, the number would be very, very close to zero!

What I suggest is that the whole industry debate about “security vs compliance” should be switched from a mildly idiotic “equals” (well, they are called different names, maybe it means they are not really equal") to a saner “helps.”

Does security helps with compliance? Yes, in most cases.
Does compliance helps with security? Yes, in many cases.
Are they the same? No.

Thoughts? Other examples where security didn’t lead to compliance?

UPDATE: a very interesting response here from CSOandy.

Possibly related posts:

SecureWarrior Spyware Removal

2009-10-05T17:20:00.001-07:00

Earlier today I noticed a lot of web traffic which came to my blog from Google queries such as “secure warrior” or “secure warrior virus” and “help how to remove secure warrior”. Even though this blog, “Security Warrior” has nothing to do with SecureWarrior malware (well, fake anti-malware, to be exact), I figured I’d aggregate and post the info about this malware since people are coming here anyway.

About this malware (fake anti-malware):

Binary name: “SecureWarrior.exe”
HTLogs description from HijackThis folks (now Trend, I guess)

Removal instructions from reliable sources:

HTLogs folks point to these instructions [NOT tested!]

BTW, this quick research project once again reminded us how fucked up the so called “big AV players” are. None had any info on this critter.

Possibly related posts:

5th Annual IT Security Automation Conference - Early Registraion Closes TODAY

2009-10-05T09:33:00.000-07:00

Just FYI, NIST 5th Annual IT Security Automation Conference early registration (for just $350!) closes today. Here is more info about the event (copied from the official page):

Audience:	Public and Private Sector. Executives, Security Managers and staff, Information Technology (IT) professionals, and Developers and Integrators of Software Products and Services.
Format:	Conference, Tutorials, and Workshop.
Purpose:	Provide a common understanding for using specific open standards and new security technologies across various domains of interest including Cloud Computing, Health Information Technology (IT)/Health Information Portability and Accountability Act (HIPAA), Federal Information Security Management Act (FISMA), Federal Information Processing Standards (FIPS) 140, and Security Content Automation Protocol (SCAP) implementations. This conference will also provide tutorials and workshop regarding Department of Commerce, Department of Defense, and Department of Homeland Security technologies and initiatives..
Topics:	Cloud Computing (Security and Trust) DoD Data Pilot/Strategy/Architecture Health IT/Health Insurance Portability and Accountability Act ( HIPAA) Crypto/FIPS140 Compliance Frameworks/800-53 Security Content Automation Protocol (SCAP)

Website:	http://scap.nist.gov/events/


Registration:	Early Registration Fee: $350 before 5 pm on October 5, 2009 Late Registration Fee: $450 On-line Registration (By clicking on this link, you are leaving the NIST site.)

See you there!

Possibly related posts:

Speaking at NIST Security Automation Conference

Misc Fun Blog Follow-ups

2009-10-04T10:24:00.000-07:00

Follow-ups to “A Myth of An Expert Generalist”:

Is a CISO an expert generalist? has good insight on whether a CISO is such expert generalist (no, he is not: he is an expert in “security leadership” [well, should be])
“Thoughts on Security Careers” from Richard explains why in some cases “broader skills” –> “recipe for disaster.”

Follow-ups to “Is Risk Just Too Risky?”

“Risk-less security” from SecurityBalance has gems like “discussions about decision making (risk based vs. others) is the only thing interesting for me today on the security field” and “if PCI DSS is working, it’s certainly not because of those approaching it with a checklist based mind. It is because it is a quite good prescriptive standard.” Overall, this post exudes awesomeness.
“Mandating Protection, Society and Seatbelts” uses my favorite analogy - seatbelts (namely, people don’t do it due to unknown risk of death, but do it due to $50 fine). In other words, this is a must-read too.

Misc fun interview with me (it has some fun bits e.g. the one on the [embarrassing :-)] first job I had…):

Anton Chuvakin – Stuck In the Lift With The Cynic

Possibly related posts:

Risk vs Risk

Obligatory “added everywhere” posts :-)

I am not at Qualys anymore and looking for the next big security idea to work on! Meanwhile, I am available for fun consulting projects related to PCI DSS, log management or other fun security things.

PCI SSC Community Meeting 2009 Posts

2009-10-02T09:17:00.001-07:00

Since I missed all the PCI fun, all that remains is to aggregate other people’s posts, starting, of course from …

… Branden Williams. His “Ask The Council” wonders why people go to the PCI Community meeting and then ask questions with the answer of “1. Read PCI DSS.” or “5. It’s on the website.” :-)
“Observations from the PCI Security Standards Council’s Community Meeting” from my friends at AlertLogic.
“Prepare Ye List Of PCI Grievances” is a pre-meeting post by Dave Taylor, worth a read. It has gems like : “Why is it that [issuing] banks say they don’t think they have to comply with PCI, when their debit cards are co-branded and carry the same risks of theft and even more risks to consumers.” Dave also has the second meeting post about the famous PwC reports: “The Two Scenarios Coming From The PWC PCI Report” (quote: “there were no reported fistfights” at the meeting), read the comments too.
NetSPI folks add “Maturity and Convergence at the PCI-SSC Community Meeting” which mentions risk: “the focus on moving to more of a risk-based approach to implementing the PCI DSS. The council was only lukewarm to this idea […] Managing a risk-based approach may be something that is incorporated over time, but it adds too much subjectivity [A.C. – yes!] to the current PCI program.”
Retail Payments blog adds (“Former Congressman Does Not See Federal PCI Legislation Likely”: "there is no benefit to any congressman in pushing cyber security legislation of any kind until there is some kind of cyber Armageddon" :-(

Enjoy! More will be added as they surface… please add them to the comments and I will move them to the main post.

UPDATE:

Branden's "The Social Media Ban"

Obligatory “added everywhere” posts :-)

I am not at Qualys anymore and looking for the next big security idea to work on! Meanwhile, I might be available for fun consulting projects related to PCI, log management or other fun security and compliance things.

Links for 2009-10-02 [del.icio.us]

2009-10-03T00:00:00-07:00

Ig Nobels mix serious and silly science tonight - White Coat Notes - Boston.com

Attending The Computer Forensics Show Oct 5-6 in Santa Clara, CA

2009-10-02T08:24:00.001-07:00

So, next week I will be at The Computer Forensics Show in Santa Clara, CA and I got some discount codes to share, courtesy of the organizers. 50% off attendance code is: VIP50

Here is the info about the event:

WHEN: October 5-6, 2009

WHERE: Santa Clara Convention Center, Santa Clara, CA

PRESO HIGHLIGHTS:

"When No One Else Can": Data Recovery from a completely overwritten hard drive. Sample Forensic recovery from over written drive from Turkish assassination case, 2007 by Alfred Demirjian

eDiscovery in the Cloud: Policy, Technology and Security Requirements for SaaS Email Archiving by Rick Dales, Proofpoint.

"Forensic" vs. "Forensically Sound" Electronic Data Collections? by Jake Frazier, Esq., EMC Corp.

Challenges to Digital Forensic Evidence by Fred Cohen [A.C. - awesomeness alert! this will probably be awesome!]

E-Discovery: Why Most Enterprise Implementations Fail To Make The Grade by Kon Leong, ZL Technologies, Inc.

Computer Forensics Solutions in Trade Secret Matters by Don Vilfer, JD, CFE, Califorensics

10 Biggest Mistakes of a Data Breach (panel) by Christopher Hague, VeriSIgn, Inc; M. Peter Adler, Esq, Pepper Hamilton, LLP; Anne Buchanan – APR,Buchanan Public Relations, LLP

Forensic Accounting – How to Uncover Fraud by Richard C. Hermerding, MBA, MA, MSIS, CMA, CFM, CFE, CFS, OLIVO-CPA

Understanding Credit Card Theft – A Practical Approach by Harshul Joshi, CBIZ MHM, LLC

The Security Data Dilemma: A Data Warehouse Approach to Improve Security by Bruno Kurtic, SenSage

E-banking Fraud Schemes: Attack Trends and Defenses by Kevin Donovan, VASCO Data Security

Detecting Zero-day and Polymorphic Malware in the Enterprise by Greg Hoglund, HBGary, Inc.

Network Forensic Investigations: Establishing Probable Cause by Eric Knight, LogRhythm, Inc.

… and many, many others.

See you there!

Links for 2009-09-30 [del.icio.us]

2009-10-01T00:00:00-07:00

Barracuda Networks takes controlling interest in phion - Silicon Valley / San Jose Business Journal:

Links for 2009-09-27 [del.icio.us]

2009-09-28T00:00:00-07:00

Emergent Chaos: Computer Capers and Progress - Little change in 30 (!) years in security?:-)