Thursday, August 27, 2009

Not at Qualys Anymore

As of today, August 27th 2009, I am not at Qualys anymore. Later today I would be able to share a bit more details to those folks who are curious :-)

UPDATE: so, let me use a metaphor to explain my situation. First, I still think Qualys is one of the best companies I ever worked for; the culture, the people, the products there are truly awesome. On the other hand, have you ever seen two good people meeting each other, falling in love, dating and then getting married - only to find in a few months or years that they are just not a fit for each other. Yes, they might retain a very high opinion of each other - just not a high opinion for a particular role of each other's partner...

For example, if we are to believe StrengthFinder test (my results here), my strentghs are in developing strategy, creating new ideas and communicating them to the world. These happen to be things that I not only can do very well, but also enjoy doing very much. Heck, I am doing them for free now for my blog and for the book I am writing! These very things also happen to not be the ones I was tasked with. Result? This blog post :-)

Hopefully, this will clarify it for those who are wondering what is going on. If there ever was a case where a good employee (yes, I have a high opinion of myself :-)) and a good employer just were not a fit for each other, it is this one.

So, if you have ideas about what I should do next, go write ahead and send them over! I plan to send the next few days thinking and strategizing about "the next big thing" for me. Also, I will continue working on all those security community projects that I was neglecting for so long.

BTW, now I will have my chance to prove that I was positive about PCI DSS not due to the fact that I had "PCI DSS" in my poisition title :-) On the other hand, you can now say that I am only positive on it to sell the book... :-(

Tuesday, August 25, 2009

Security and Dire Straits

This gets my "exudes pure awesomeness" award of the 1st degree: "a little ditty sung to the tune of “Money for Nothing” by Dire Straits."

Quote:

"Now look at them blackhats that’s the way you do it
Finding holes in your security
That ain’t workin’ that’s the way you do it
Mutating malware very frequently

Now that ain’t workin’ that’s the way you do it
Lemme tell ya them guys ain’t dumb
Maybe get a virus on your little palmtop
Maybe get a virus on your phone..."

Continue here and ROFL, weep, etc!


Fun Security Challenge: Prison Break

Somehow I didn't realize that Ed Skoudis is still hosting those "hacker challenges" (old ones here and here), but I guess he does. There is one running right now with a deadline of Aug 31, 2009.

Feel free to play with it here.

Wednesday, August 19, 2009

Security Policy Roundtable Today!

Program:

Thought Leadership Roundtable Webcast on Security Policy Configuration [A.C. – that is the “small p” policy, not organizational Policy]

Date and time:
Wednesday, August 19, 2009 2:00 pm EST / 11:00AM PST (TODAY!)

Description:

Join Rich Mogull as he gathers industry visionaries from nCircle, Qualys & Tenable around a virtual table for a lively discussion on Policy Compliance IT Security trends.  Attendees gain a fresh, unedited perspective of the emerging security technology trends directly from those responsible for their development. Our vendor partners use this platform to communicate their organization’s vision and direction in a marketplace otherwise overwhelmed with an abundance of hyper edited press releases and other bland corporate chatter.

It will be fun, so register here. And if you don’t like it, you can always beat them up on Twitter :-)

Friday, August 14, 2009

Log Standards Make A HUGE Step

Quietly, sometimes with tiny steps and sometimes with long delays for deep meditation :-), the case for log standardization moves forward. Recently, at RSA2009 and BlackHat2009 meetings, the CEE team has managed to achieve a breakthrough and actually resolve many of the highly debated issues of taxonomy, definitions, formats and even of the future CEE compliance program. Of course, not all of the trouble spots are resolved – the log standardization remains as devilishly hard as it always has been!

For example, here is how far the Common Event Expression has progressed:

“Status
------
MITRE is continuing work on the Common Event Expression (CEE) standard
in conjunction with the Editorial Board and various organizations.
The past months have been spent on the drafting and validation of a
proposal for the initial CEE Specification.

This specification was submitted to the Editorial Board last month.
MITRE is currently working at rolling in the comments received from
the Board, and expect to have a new draft for their review in the next
couple of weeks.
Once the Board has approved the specification, the specification will
be posted to the CEE Community for feedback. We expect this to occur
within the next month. Our goal is to have final proposal that the
community can agree to by the end of 2009
. “

and

“Proposed Specification
----------------------
MITRE in collaboration with industry and government offer the Common
Event Expression (CEET) Architectural Proposal for the Core
Components as the basis to standardize event logs from electronic
systems. This paper builds on the CEE proposal summarized in the
Common Event Expression Whitepaper by defining the core components'
architecture needed to enable collaborative efforts in the creation
of an open, practical, and industry-accepted event interoperability
standard for electronic systems.
This specification summarizes CEE and provides details on the
architecture of the core components including the data dictionary,
syntax specifications, and event taxonomies.
This proposal is the
first in a collection of documents and specifications. The
combination of the documents and specifications provides the
necessary pieces to create a complete event log standard, which can
be mapped against the four components of CEE: Transport, Syntax,
Taxonomy, and Log Recommendations. “

Finally, CEE and the - previously thought to be lost - cause for log standardization now have a secret weapon: the EMAP, SCAP’s evil twin.

You thought government will mandate which health insurance you’d have? Ha-ha-ha, how about what logs you’d have? ;-) [but unlike health insurance, that would be a good thing!![

Possibly related posts:

  • TBA
  • All posts about CEE

Thursday, August 13, 2009

On Heartland VI

No time to comment on this, but aggregating this sudden revival of “the Heartland saga” is A MUST at this stage.

  • Heartland CEO Carr interview with CSO Magazine titled “Heartland CEO on Data Breach: QSAs Let Us Down.” Notable quotes are: "The audits done by our QSAs (Qualified Security Assessors) were of no value whatsoever. To the extent that they were telling us we were secure beforehand, that we were PCI compliant, was a major problem”, “The false reports we got for 6 years, we have no recourse. No grounds for litigation,”  “up until this point, we certainly didn't understand the limitations of PCI and the entire assessment process” and “PCI compliance doesn't mean secure.” Niiiiice. Also, why-oh-why did Bill ask that last question “What should companies be asking in terms of the insider threat?” Why did ya, Bill? :-)
  • Mike Rothman freaks out and goes on a rampage in “One Man's View: Heartland CEO Must Accept Responsibility.” Notable quotes are: “my blood is boiling”, “It's about time organizations suffering from a data breach owned up to the fact that they made a mistake”, “inevitably it will happen again”, “you cannot outsource thinking” (my personal fave!), “they [QSA] are not there to tell an organization whether they are secure or not – that […] is the responsibility of the internal security team”, etc.
  • Rich Mogull freaks out in unison and goes on a rampage in “An Open Letter to Robert Carr, CEO of Heartland Payment Systems.” Notable quotes are: “Your attempts to shift responsibility to your QSA are the accounting equivalent of blaming your external auditor for failing to prevent the hijacking of an armored car”, “Their [QSA] role isn't even to assess your security defenses overall, but to make sure you meet the minimum standards of PCI”, “Unless your QSAs were also responsible for your operational security, the only ones responsible for your breach are the criminals, and Heartland itself.”  BTW, this is the post where you have to also read the comments!
  • Andy reads all this and freaks out as a result in “Will the real leader please step forward.” Notable quotes: “If we can’t trust them to be responsible in this then how can we trust them to be responsible in any other way.” The rest of his comments are too strong even though this is my personal blog.
  • Branden from VeriSign coolly adds in “Bob Carr: "QSAs let us down." And Things Never Heard by a QSA.” He also thoughtfully reminds everybody that their PREVIOUS QSA, not CURRENT one did it. Notable quotes are: “The article is a fantastic read, but also slightly humorous in nature”, “Some QSAs WILL let you down. You get what you pay for, and some QSAs may not do a good job.”

Enjoy! Will add more as the come.

Possibly related posts:

Tuesday, August 11, 2009

A Myth of An Expert Generalist

In the future, it will become clear why I am writing this... For now, please treat this as some random analysis of our profession as well as of the dreaded definition of “a security expert.” Some might say it is a rant, but I prefer to tag it as “musings.”

Lately I’ve run into too many people who [claim to] “know security” or are [claim to be] “security experts.” Now, as some of you recall, I used to do theoretical particle physics before I came to information security. In my physics days, I’d be pretty shocked if I were to meet a colleague in the hallways of the C.N. Yang Institute for Theoretical Physics who would self-identify as “a scientist” or, for that matter, even as “a physicist.” It is overwhelmingly more likely that he would say “quantum chromodynamics” or “lepton number violation in electroweak gauge theories” or “self-ionization of the vacuum” or some such fun thing :-) However, as we all know, some folks in our industry have no shame introducing themselves to a colleague as “security experts.”

So, you are “a security expert.” Awesome, happy to hear it! Please let me know whether you are  Case A or Case B.

Case A: you know more than an average person on the street about every single area (or many, many areas) of information security: from ISO27001 to secure coding in Ruby?

or

Case B: you know more than your peers in security about one  particular area (or a few areas) of information security: log management, Java security code review, penetration testing, NIDS/NIPS rule creation, firewall management, wireless scanning, etc?

Let’s see which one is consistent with how people in other professions define “expertise.” The obvious start is Wikipedia. As of today, http://en.wikipedia.org/wiki/Expert entry says:

“An expert is someone widely recognized as a reliable source of technique or skill whose faculty for judging or deciding rightly, justly, or wisely is accorded authority and status by their peers or the public in a specific well distinguished domain. An expert, more generally, is a person with extensive knowledge or ability in a particular area of study.”

Other sources (such as Google “define:expert”) present similar results; expert can only be an expert in a specific narrow area.

Now, notice that the farther you are from a certain area, the more it seems like a narrow one (example: “science” to a average janitor is a narrow area). On the contrary, the deeper you are inside a particular area , the more it seems like a wide area (example: “brain tumor surgery” to a neurosurgeon is a broad area or “quantum gravity” to a physicist).

Despite such relativism, other professions somehow managed to converge on their definitions of “an expert.” After all, you don’t get to “enjoy” a neurosurgery from somebody who “knows more about medicine than an average layperson.” However, as we all know, many organizations “enjoy” having their NIDS tuned by a just-hired CISSP (aka proof of being “a light-year wide and a nanometer deep” in security :-)). What’s up with that?

I think this has a lot to do with the fact that the area of security is too new and too fuzzy. However, my point here is that a little common sense goes a long way even at this stage of our industry development. In light of this, next time you meet “a security expert,” ask him what is his area of expertise. If the answer is “security”, run! :-)

Finally, career advice for those new to information security: don’t be a generalist. If you have to be a security generalist, be a “generalist specialist;” namely, know a bit about everything PLUS know a lot about something OR know a lot about “several somethings.” If you ONLY know “a bit about everything,” you’d probably die hungry...

Possibly related posts:

Monday, August 10, 2009

Compliance/Security Dichotomy Fight

Just wanted to catalogue the whole “Oblomov-gate” for posterity.

  1. Showing The Oblomovs The Door” by Nick Selby, of 451 Group fame; read the comments too.
  2. Personal Responsibility in Information Security”  by Mike Dahn, of QSA training fame; read the comments too.
  3. Two must read posts on PCI” by Martin McKeay, of security podcasting fame.

The great “audit/compliance” vs “security/risk” battle is made very explicit in this discussion. As “audit/compliance” side was “winning" more lately, with this post the “security/risk” side hits back (with a pillow?) and makes the weaknesses in the other side armor more apparent.  BTW, I am sure that all the participants of this read the original Donn Parker piece “Making the Case for Replacing Risk-Based Security” [PDF] (if inaccessible, comments here and here), now, didn’t they?

BTW, if somebody will dare say “we need both”, you’d win the Captain Obvious award. But given that this discussion is about the driving or primary approach, such attempts at pacifying the participants will definitely result in F.A.I.L.

I will update as more people comment about it, as they undoubtfully will.

Possibly related posts:

Saturday, August 08, 2009

Book Review “Chained Exploits”

As you might guess, I often read security books for fun, not for solving  a particular technical problem. So I approached “Chained Exploits” by Andrew Whitaker, et al with that filter in mind. The book worked just fine for that purpose – it is well-written and has a story line, while covering enough technical details to be educational (for those who are reading it to learn about security and not just for fun). It covers the exploits of a malicious hacker “Phoenix” who fulfills the assignments of some underground criminal mastermind and sometimes just goes and 0wns somebody on his own. Obviously, the book does not cut it as “fiction” since it has actually commands, configuration, etc.

The book is not about a new cutting edge technique or an “oh-day”, its main goal is to actually tie “that security stuff” together for folks who are not skilled with it yet. IMHO, IT folks getting into security will benefit from it the most. If you 0wn boxes for fun and profit, you will not learn anything fundamentally new about security, but likely will have fun in the process. Think about it as “Life-like Security Horror Stories” or realistic scenarios. Still, these are a bunch of good story of how mundane, “uncool” attacks tie together to achieve some rampant 0wnage, like having people at a hospital almost die as a result of one particular scenario…

Each story covers motivation and goals of the attach, planning stage, sometimes failed attempts (and why they fail), tool selection and some guidance on tool use. Then it explains what happens and finally covers countermeasures that could have stopped it.

The book bears unfortunate, but noticeable signs of being written by multiple people who didn’t talk to each other much.

Finally, the name (“Chained Exploits”) first turned me away from the book, I thought it was kinda silly; now I suspect that it will attract some folks to the book.

Recommendation: definitely worth a read if you are new to security, especially if moving from IT. Useful for students in computer science classes to get motivated about security. Also useful for technical management to learn what is not just possible, but very real.   Finally, useful for security folks – as a fun read – and also as a reminder about things in their own (still their own, not 0wned…) environments.

Possibly related posts:

Friday, August 07, 2009

OWASP Podcast Interview on PCI.

Here is a fun podcast interview that I did with OWASP; the subject is mostly PCI DSS (but watch for some fun Q&A in the end too)

Direct MP3 link is here[mp3]

One Security MUST Read!

Why both with security reading this week, if you MUST only read one "to be compliant"? :-)

Nick Selby bares all in his insta-famous treatise called "Showing The Oblomovs The Door" at a new security blog, FudSec.

Fave quotes:

"The CEO who lets the Security organization become the compliance department has abdicated to the government and Payment Card Industry his responsibility to understand and manage organizational risk. "

"Thus have they managed not only to not raise the bar but in fact to substantially lower the ceiling - PCI is not the minimum standard, it's the maximum effort that many organizations make."

"'Best Practices' is a term for which toilet-dunks should be applied rigorously - the term is, to borrow a phrase from Marcus Ranum, weapons-grade marketing bullshit"

"It's more about the fact that all this compliance stuff is preventing us from addressing risk and performing, you know, security."

"You want your compliance department to manage risk for you? You'd better hope your firm is considered, “Too big to fail,” so the next round of government bailouts can save your sorry butt. "

Enjoy, his post definitely exudes pure awesomness (and so do some of the comments)!

Thursday, August 06, 2009

BlackHat 2009 Inspired – On Media Whoring

There is “security theater” and then there is BlackHat/DEFCON. If it were a vendor glossy, I’d have called BH/DC “the latest version of an ultimate, next-generation, paradigm-shifting, integrated theatrical experience.” :-)

As a result, seeing a few of the speakers [and being in, you know, Las Vegas, Nevada :-)] made me think about whoring; media whoring, to be exact. Obviously, security industry is unthinkable or maybe even provably impossible without some media slutting, but at this year’s show I realized “I ain’t seen nut’n yet.” Some folks are just sooooooooooooooooooooooooooooo good at it.

In any case, my thinking converged into the following over-simplified model (or “muddle”?) which analyzes the intersection of media whoring and subject matter (in this case, security) knowledge:

Security knowledge vs seeking media attention Media attention not sought Media attention sought
Knowledge of subject matter  present Knows his shit + nobody knows about it (case I) Knows his shit+ makes everybody know it (case III)
Knowledge of subject matter  lacking Knows nothing + nobody knows about it (case II) Knows nothing + makes everybody  think that he knows everything (case IV)

What does this teach us?

  1. Case I gets respect, but not enough of it. There is nothing we can do about it, however. People, if you are cool, speak up, the world needs you! Get a blog or something…
  2. Case II gets nothing, which is coincidentally what it deserves. Stay there :-)
  3. Case III  gets non-trivial amount of disdain and some respect  (especially when it involves MD2 crypto :-)) However, is such disdain truly justified?  While there is no metric to compare the value of one’s contribution with an effort needed to get the media to spread his message, common sense criteria definitely apply (“Internet is DEAD! Press conference at 5PM. Live Twitter coverage!” :-))
  4. Case IV gets non-trivial amount of hatred and disdain, but IMHO – and this is my MAIN POINT! – nowhere near enough disdain compared to what they actually deserve!

So, action item: get all your disdain, antipathy,  hatred and annoyance that you now spread between cases III and IV, “double it! double it!! – then double it again!!!” and focus it in the direction of case IV people.

Possibly related posts:

Wednesday, August 05, 2009

BlackHat 2009 Day 2 – Bruce “Reconceptualizing”

At the very end of BlackHat 2009, Day 2, I went to Bruce Schneier’s talk called “Reconceptualizing Security.” And, let me tell you, I was surprised that his talk was actually really fun, especially the Q&A in the end.

It seems like on his ‘security journey,’ Bruce is moving from security economics (which is still pretty “hot”, BTW, as most problems are unresolved) to security psychology. That was the main theme for his talk: being secure vs feeling secure. BTW, this post is an inseparable mix of what I’ve heard there at his talk and what I thought as a result :-)

He started from saying that ancient humans in African savannah used to have a complete match between “being” and “feeling” secure (scary=risky), but today this is out of sync AND, when it comes to computers, it is heavily out of sync (“tiger at the other end of the wire is not that scary”). So, while “evolution favors good security tradeoff”, we still evolved to today with an ever-decreasing correlation of being and feeling secure. To top it off, humans now make decisions on feeling, not being secure. Thus the whole mess :-)

This, BTW, drove the final coffin (for me, at least) into “market will drive infosecurity.” No it won’t!! Think about it:

People make bad risk decisions, since they are based on feeling secure, not becoming secure

+

Market drives security

+

Market is a bunch of people making purchase decisions

=

Overall result is folks feeling more secure and no advance in security aka “the whole mess.”

He also quoted some paper (this?) which analyzed the perception of risks and feeling secure (I think I’ve seen it before, but summary was useful):

  • unknown risk > (=is perceived as higher than) known risk (example: new disease vs flu variant)
  • rare > common (example: swine flu vs regular flu)
  • personal > anonymous (example: Osama vs terrorism)
  • involuntary > voluntary (example: smoking vs other medical problem)

One of the things I loved the most was Bruce’s final acknowledgement that “security theater” is actually beneficial: specifically, if PERCEIVED risk is higher than the REAL risk, what one needs is to be be reassured and feel good. Guess what? Security theater provides it! Air travel is pretty darn safe, but a lot of folks are afraid: thus, we have TSA, the ultimate in “security theater.” This argument actually makes sense, as long as the false boost to security does not overcome the actual state of being secure – you need to get them to feel as secure as they are secure, but not more. Get it? :-) Same logic applies to such “key” technologies as “anti-baby kidnapping RFID” or drug safety seals, which add a perception of safety to something already pretty safe.

His answer: metrics, of course. We need to observe the reality of security, not the perception. He had this fun warning about metrics though: “my elephant-trample protection device has been perfect for 10 years” (=nothing bad happened due to security vs nothing wouldn’t have happened anyway)

Next he went into models and at times sounded positively “Bandlerian” (actually, I think he quoted Bandler once when he said that ‘sometimes a “model” becomes a “muddle”’). My fave quote: neocortex is “kinda still in beta” :-)

Another very fun point was that he run a fine line about infosecurity becoming more scientific or at least more rational. He said that "“experiment, theory, science leads to good, useful models”, while “religion, faith, myth [or voodoo cult of infosec :-)] leads to bad models.” At the same time, when I asked whether security will become predominantly scientific, he countered with “not in our lifetime, maybe someday.”

So, his idea of “short term fix” for the whole mess is to sync the “feeling” and “being” secure, by reassuring (moves feeling up - hopefully not to “false sense of security”, leave security in place), FUD (moves feeling down – hopefully not too much to paranoia, leaves security in place) and securing (leaves feeling secure in place, increases security as needed). His idea of “long term fix” – “change the model” (which IMHO was not entirely clear to me or probably to anybody else in the audience for that matter :-)) BTW, he also reminded that maybe the reality now changes faster than we can adjust our models and so, as a result, maybe our models will never catch up (and we will be forever doing incident response on 0wned boxes :-), whether on-site or in the cloud…)

At one point, he also kicked infosec risk management in the balls, by reminding that you never really “manage” risk, sometimes it just hits you :-) This somehow reminded me about my sad experience at a Russian security conference a few years ago when I realized that a proper translation of the words “risk management” into Russian literally means “control of risk”…

Q&A was good. After the mandatory AES question, which proved that Bruce is still a cryptographer :-), there was a lot of interesting questions.

I loved these the most:

Q: Checkbox auditing vs value-based auditing, which is better? A: “Use AND” – both are useful.

Q: Is compliance beneficial? A: Security improves two ways: fear (negative) and greed (positive). The first is harder! “ROI nonsense; security is NOT a greed sell” . Thus, fear, but we need the right one :-) Compliance (=audit fail fear) sells security: Bruce noted that it is an “expensive way to sell security; a lot of stuff sold does not add to security at all – documentation, etc.” Still, his resume was that it is “INEFFICIENT BUT THE BEST we have!” and “has improved security at the cost of some extra spending.”

Conclusion: there is only one Bruce! :-) Despite all the jokes (and here), I still think that his security thinking contributions by far overshadow his contributions to media whoring (this will, BTW, be a subject of a dedicated BlackHat-inspired post soon…)

Now onto DEFCON 17th!

UPDATE: very timely link from Bruce's blog called "Risk Intuition."


Possibly related posts:

Tuesday, August 04, 2009

Monthly Blog Round-Up – July 2009

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

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

  1. Now every blogger has that experience: his most loved, deep, insightful post gets little traffic, while something fun and stupid gets loads of it: example this month is my “Nobody Is That Dumb ... Oh, Wait XII” about the evils of honeypots in Norway…
  2. I am no longer surprised that “Why No Open Source SIEM, EVER?” “rules the seas”, taking #2 spot this month, just as last month. The older inspiration for this post is “On Open Source in SIEM and Log Management.”
  3. My review and coverage of the book “Beautiful Security” (“Best Chapter From “Beautiful Security” Downloadable!” and “Book Review “Beautiful Security””) is popular due to a lot of linking to it.
  4. Vulnerability Scanning and Clouds/SaaS/IaaS/PaaS” post, which is basically a “link and quote” post to this was in Top 5. It helps to continue the discussion about vulnerability assessment of cloud infrastructure (a topic which will be featured in a few posts soon…)
  5. BlackHat 2009 Day 1 – Laws of Vulnerabilities Panel” is next. I have three more very fun BlackHat/DEFCON posts in the queue; never had a chance to write them since I was finishing that PCI DSS book last week.

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

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

Technorati Tags: ,,,

Monday, August 03, 2009

BlackHat 2009 Day 2 – Fun Cloud Stuff

BlackHat 2009 is over, but sharing impressions from it is certainly not.

So, for the the remainder of day 1 went to “Weaponizing the Web” (which had good ideas on CSRF, see their tool here) and “Psychotronica” (which was great content totally killed by a sleep-inducing speaker – I left mid-talk. In fact, I am yawning even as I write about it…). And then I had a chance of seeing Linus get his pwnie

Then I started Day 2 at Jeremiah and Trey talk, which was a lot of fun. Moreover, it was so much fun as to reach 100% entertainment, which is another way of saying that it was not useful for any practical purpose (apart from entertainment purpose mentioned above, of course :-)). In brief, it covered a whole bunch of fun “non-hacking hacking“ cases (such as compromise of a system to issue licenses to do logging in Brazilian jungle, which supposedly netted somebody a cool $800m). They touched (but, sadly, didn’t analyze) a few things such as what is a better focus: “super hacker strategy” (vs advanced targeted attacker on key systems) vs basic baseline (vs opportunists strategy on all systems) [“both” is what they hinted at, of course]. BTW, their deck is posted here, check it out!

Next was my cloud talk #1, “Clobbering the Cloud.” (UPDATE: full slide deck here) A lot of fun and useful things were discussed – and some impressive cloud “0wnage” was shown too. It started from a useful reminder that the whole permission for “testing the cloud” (whether via scanning or manual pentesting) issue is not resolved. Moreover, PaaS/IaaS made it that much worse, since you might have a permission from the cloud application vendor, but not from Amazon and then end up blacklisted (“Never allowed to buy from Amazon again” :-)). In addition, even issues like “Which version of the application/OS/environment are you testing?” are frequent, since SaaS provider might update their application at any time.

They briefly touched on “cloud compliance”, focusing on transparency of the cloud. Somehow they had an impression that nobody is putting regulated data in the cloud…mmmm… right :-) The also mentioned the subpoena risks of having your data obtained by this or that government without you even knowing. Their point was that trust matters A LOT in the cloud, but at the same time the “verify” part of ‘trust but verify’ often fails.

Here is a set of fun things discussed:

  • Cool method for password brute-forcing with password reset links; after all, most if not cloud apps use some password recovery (email- or secret questions-based)
  • A very interesting sifto tool (SaaS nikto) written as a Salesforce.com app, which then runs off a high-bandwidth link for free (the story also features a CAPTCHA with its text left in the same web page…)
  • Also, a bunch of good ways to steal cloud resources: Amazon cloud instance of Windows license stealing, paid application theft (via DevPay), etc.
  • Fun “cloud DoS” with exponential, virus-like growth of VM instances and users.
  • Impressive use of trojaned images combined with a tool to make them popular and have them show up at the top of the list. Instant mass cloud 0wnage!

Overall, amazing Amazon IaaS rampage! Also, they showed some fun Apple MobileMe 0wnage as well.

What are my thoughts on this?

First, I’d bet that offensive cloud use (either using stolen benign cloud resources or native “built for evil by evil” clouds :-)) will beat defensive cloud use (like Mark Curphey’s security data analysis ideas) by a long shot. Before we harness cloud resources for security (such as for analytics, etc – we do harness them for scanning already), somebody will turn it against us in a big way. But then again, botnet use for password cracking (which is more “distributed computing” than “cloud computing”) is already there so, “evil cloud” stuff is starting to be a reality…

Second, something made me think that, personally, I’d always keep an offline backup (for BOTH data and processing capability!) for anything I’d put in the cloud. Notice how it compares to the past paranoid mantra “don’t store anything truly private on an Internet-connected PC” – nowadays it is “don’t store it ON the Internet” :-( What’s next, don’t announce it on Twitter? :-)

Third, people talk a lot about software liability and how hard/controversial it is. I had this thought that maybe cloud computing will be where it will start?

Finally, how’s that for a paradox?

a) Many folks say that: “cloud security" (loosely defined here) can be and needs to be awesome.

b) Everybody agrees that: web app security is horrible and will be horrible for a long time.

c) Obviously: cloud computing today is mostly web apps.

Huh? Isn’t the whole cloud security fun (now I know why some folks are so excited about it)?

Next, I went to Kostya’s “Cloudburst” talk; I didn’t follow VMWare security closely enough, but seeing another reliable Guest->Host escape is pretty cool. Sadly, too many people chose this room to catch up on some much needed sleep after a rough night, it seems.

Finally, Bruce Schneier did a very fun talk (yes, really!), which deserves its own post tomorrow.

Possibly related posts:

Wednesday, July 29, 2009

BlackHat 2009 Day 1 – Laws of Vulnerabilities Panel

Since I am press (got my ridiculous pink  badge tag already), I will write :-) After catching part of the keynote (the Google guy was pretty interesting with his security thinking – however, I suspect when he says “users”, he means much better people than a typical organization), I am at Qualys-led (Wolfgang) panel with GE (Richard), Orbitz CSO (Ed), Heartland Payment Systems CSO (Kris), Goldman Sachs (Paul) and State of CA (Mark).

Wolfgang showed the updated Laws of Vulnerabilities (all details here); some good insights to take away are (if you were not here – there was a lot more of great insights than that!):

  • Half-lifes of vulnerabilities (=time in which half of the vulnerable boxes get patched) didn’t change much since 2004 (same as the research revealed at RSA 2009 showed)
  • No matter how old, many vulnerabilities stay forever on some systems (or new systems with old vulns are being connected). 8-10% of machines which were vulnerable stay vulnerable for as long as the research covers, but likely forever. This about it! Even old critical – “Insta-0wn”-type – vulnerability stay forever on some – likely compromised – systems.
  • If you limit the scope of half-life analysis to core OS vulnerabilities, the half-life drops to 15 days (which means that people patch those quickly!) On the other hand, if you limit it to Adobe and MS Office flaws, the half-life sharply rises to 60 days (which means people just don’t care – and the current dramatic “0wnage” will continue)
  • “Speed up patching!” call is still needed, despite it being made for years and years. Looks like people get to pay attention to OS flaws, but not to client issues.

The panel then discussed that doing “single day”  patching (holy grail for many organizations) is doable even in large companies, but that is not the end of it -by far. For example, Ed from Orbitz comments reminded folks that “deploy patch” becomes  “write patches”  for custom apps. The problem thus becomes worse and worse, if you happen to have a “build, not buy” culture: the percentage of systems that you can quickly patch becomes lower and lower.

A lot of interesting comments were made by the Heartland CISO (who, BTW, joined 2 weeks before the now-infamous election breach disclosure) about how a breach motivated a change in their patching process. He said that they used  to focus most resources on payment processing environment, but then their non-CDE corporate network was breached first and analyzed for 7 months (!) by the attacker who then broke thru the developer access to CDE. Patching client flaws on the corporate (non-CDE) side is now a priority as well.

Richard’s comments come from the IR/IH side. For example, in case of a particular Adobe flaw, they saw exploitation activity on the 15th, were informed about the issue on the 21st, and then the patch came on the 28th (timeline approximate). Thus, even if you patch really well, finding 0days becomes key since 0-day 0wnage is rampant if you are the “right target.” In-house research is the only choice in this case, I suspect.

Afterwards, Kris from Heartland made a few one comments on DLP: they use it for discovery and data auditing, not for data leak prevention (which is definitely very reasonable). Another interesting theme (brought up by Ed) was not just awareness of what is going on your network (which is hard), but also on all the supplier networks that connect to it. This is a curious mix of technical security and legal, contractual stuff.

Finally, an interesting insight came to me from listening to this panel: evidence of different focus of security management was clearly heard - some organizations focus on patching the right segment, some on faster patching, some on limiting access, some on network visibility. To me this spells the end of the quest for “security best practices” since your “best” might be doomed to be forever different from others “best” …

Overall, this was a very fun panel to attend!

Now, on to the  “Weaponizing the Web” talk.

Tuesday, July 28, 2009

Monday, July 27, 2009

Another Claimed "0wned While Compliant" Case ... NOT!

So, another card data theft (only 500,000 cards this time, not a biggy :-)), another chance for some folks to scream "PCI didn't save me!"

In particular, the paper has this quote:

"Wade added that Network Solutions is compliant with the Payment Card Industries (PCI) Data Security Standards, but did not immediately know when the last compliance assessment was conducted."
Stop ... right ... here! This is "delusions of compliance" case, a very clear-cut. Even without ever seeing her environment, I can guess that:
  • She has absolutely no idea whether they are compliant at this time or at the time of the breach!
  • She can hope that they were indeed compliant with all the necessary requirements whenever they were validated (not sure QSA or SAQ)
  • She can hope that they were in compliance at the time of the breach, but I bet a bottle of bad vodka that they were in fact NOT!
Please save us from another round of "PCI didn't save us, thus it is bad!" Think for a second before you spout it...

Wednesday, July 22, 2009

How to Harness the Power of PCI DSS? Tip #3

Inspired by the panels we did on PCI (here, here), I decided to start a series of posts with tips on harnessing the amazing motivating power of PCI DSS for meaningful security improvements. These tips are most useful for those in the trenches who are required to comply with PCI DSS while keeping the systems running and secure but maybe do not know how, and not to those who whine, bitch, blog and twitter their way to infamy…

So, got a nice heavy PCI hammer? Where do you hit for security?

image_thumb2[2]

Tip #3 will again focus on something very basic, non-controversial and, again, spelled out relatively clearly in PCI DSS: namely, vulnerability scanning, which is itself part of vulnerability management. Basic? Hell yeah! So then, pray tell me, why is it one of the most common PCI assessment failures (see Branden for evidence)?

First, where does PCI DSS guidance talks about vulnerability scanning? In Req 6 and 11, namely:

“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” [and vulnerability scanning is one of the options]

and

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

So, when you see the above what questions pop up first? My tip will be in answering them!

Q: What systems must I scan for PCI DSS compliance?

A:

  • External: “all Internet-facing Internet Protocol (IP) addresses and/or ranges, including all network components and devices that are involved in e-commerce transactions or retail transactions that use IP to transmit data over the Internet” (source: “Technical and Operational Requirements for Approved Scanning Vendors (ASVs)”[PDF] by PCI Council). The answer can be “none” if your business has no connection to the Internet (duh!)
  • Internal: all systems which are considered “in-scope” for PCI, which is either those involved with card processing or “directly connected” to them (source: PCI DSS[PDF]). The answer can also “none” if you have no systems insider your perimeter which are in-scope for PCI DSS.

Q: Is there a pass/fail criteria for scans?

A:

  • External: Yes, here is an example below from Qualys site:
PCI DSS ASV Scan Criteria
Vulnerabilities with a CVSS v2.0 base score of either 4.0 or higher will cause PCI compliance to fail on the scanned systems (excluding vulnerabilities leading only to denial-of-service issues)
A system will be considered non-compliant if the SSL version installed on it is limited to 2.0 or older.
Vulnerabilities that may lead to SQL injection attacks and cross-site scripting will result in a non-compliant status on the corresponding system.

These are derived from the same “Technical and Operational Requirements for Approved Scanning Vendors (ASVs)”[PDF] document by PCI Council.

  • Internal: there is no explicitly spelled-out pass/fail criteria. The decision is thus based on your idea of risk; there is nothing wrong with using the same criteria as above, of course, if you think that it matches your view of risks to card data in your environment. However, most QSAs will not accept a scan report with high-severity vulnerabilities present in the card holder data environment. For example, assuming a 1-5 scale with 5 being the most severe, 3s,4s and 5s are likely to be a "deal-breaker" (this section is UPDATED!)

Q: How do I pass?

A:

  • External: you satisfy the above criteria. If you don’t, you need to fix the vulnerabilities that are causing you to fail and the rescan. And then you pass and get a “passing report,” that you can submit to your acquiring bank.
  • Internal: there is no pass/fail criteria. You don’t get to to pass – or to fail. You just need to do it to reduce risk to cardholder data, based on your own view of such risk. You can do it right or wrong in that regard, BUT “not doing it” is unambiguously wrong! So, actually, you do get to fail – if you don’t do it at all.

Q: Am I “PCI compliant” if I get a passing scan for my external systems?

A: No. No. No. No. No. You only satisfied one of the PCI DSS requirements; namely, PCI DSS validation via an external Approved Scanning Vendor (ASV) scan. This is NOT the end. Likely, this is the beginning…

Q: If I scan my website using my ASV and get a passing scan, am I also OK in regards to Requirement 6.6 “For public-facing web applications… address new threats and vulnerabilities on an ongoing basis?”

A: No, most definitely not. This is a different story; and the subject of another tip.

Enjoy!

P.S. There are some of you who would read this and say “Give us sexy security stuff! Give us clouds! Give us bleeding edge! Or at least give us the results of your CVSS vector factor analysis..” To those I say, all in due course :-)

Possibly related posts:

Tuesday, July 21, 2009

More On KindleGate

SANS just repored that the KindleGate is worse than just "1984":

"COPYRIGHT, PIRACY & DIGITAL RIGHTS MANAGEMENT
--Amazon Deletes Purchased Books From Kindle Users' Devices (July 17, 2009)
Kindle owners who had purchased [emphasis by Anton, explained below] electronic copies of George Orwell's Animal Farm and 1984 were no doubt surprised to find the books deleted from their devices last week. Apparently the company that added the editions of the books to the Kindle catalog did not have the rights to do so. Amazon credited affected users' accounts for the cost of the books. Amazon says that if it faces similar circumstances in the future, it will not delete books from users' devices. Comments in customer web forms indicate that certain editions of Harry Potter books and works by Ayn Rand had similarly disappeared. The Kindle terms-of-service agreement nowhere states that Amazon has the right to delete purchased content from users' devices. The irony of Orwell's books being deleted has not been lost on the public.
http://www.techweb.com/article/showArticle?articleID=218501227&section=News
http://www.nytimes.com/2009/07/18/technology/companies/18amazon.html"

But this teaches us something truly deeply funny and sad about the world we live in! Even SANS thinks that the readers "PURCHASED" ebooks; I am sure that said readers thought so too. That was their honest perception.

In reality, they never did purchase anything - they licensed it.

As a result, I suspect that the more stuff like "KindleGate" happens, the more the following perception (whether true or not!) will grow, strengthen and develop:

When you "BUY" digital content, you don't really BUY it - it is not really a PURCHASE.

THEREFORE

When you STEAL digital content, you don't really STEAL it - it is not really a CRIME.

Please, folks who enforce the rules the way Amazon just did, watch for that monster you are helping to create. It will destroy you!

UPDATE: fun discussion about clouds, DRM and the KindleGate here (read the comments too)

UPDATE: Kindlegate truly ends; "Amazon Settles Kindle Deletion Lawsuit For $150,000" ("Amazon.com has agreed to pay $150,000 to the student who sued the company for deleting his digitalcopy of George Orwell's 1984 from his Kindle e-book reading device.")

Tuesday, July 14, 2009

On Scanning

This post is about PCI DSS and vulnerability scanning.  What can be simpler than that? :-)

Well, the illustrious Branden Williams reminds us that even the simplest, clearest, most painstakingly defined part of PCI DSS can cause .. you know … trouble. Since his post is so good, I’d quote more and comment less.

First, a quick and useful reminder:

“Requirement 11.2 mandates quarterly scans for all hosts in scope for PCI, both internal and external”

External scans are well-defined, internal scans are left to the discretion of merchant’s security team. The latter does NOT make them any less mandatory though.

Then Branden asks a perfectly reasonable question:

“In more than half of the PCI assessments we [=his team at VeriSign] did in 2008, Requirement 11.2 came up as an initial gap. If it's just scanning, why can't we get it right?”

And, yes, he has an answer. The first part of the answer makes me embarrassed to even mention it here; in fact, I feel ashamed of being part of the same humanity with folks who do it… Namely:

“Reason the First: You scanned, but you forgot to obtain CLEAN scans for every quarter. Remember, the testing procedure for Requirement 11.2 states that QSAs must "Verify that the scan process includes rescans until passing results are obtained." Just scanning is not enough, you have to scan, patch, and re-scan until you have a clean scan”

No, neither Branden nor I are joking; stuff like that really happens: “It mandates scanning? So, we are going to scan! Is there anything else?” He then explains it further, with YouTube video illustrations, of course :-) And now the second part:

“Reason the Second: You scanned externally, but forgot to scan INTERNALLY.”

So, please call me the f*cking broken record (modern version: a corrupted MP3 file? :-)), but:

Internal network scanning is just as mandatory as external, as per PCI DSS.

Internal network scanning is just as mandatory as external, as per PCI DSS.

Internal network scanning is just as mandatory as external, as per PCI DSS.

Internal network scanning is just as mandatory as external, as per PCI DSS.

Internal network scanning is just as mandatory as external, as per PCI DSS.

Did I mention … oh, never mind! In any case, read his whole post here.

P.S. Today was the day I really didn’t want to write about PCI since I realized that even though PCI DSS is definitely NOT the reason for scams, there are PCI-related scams out there nonetheless. And that makes me sad. Whether it is about “free PCI compliancy” or “guaranteed PCI compliance for $4.75/month”, such things are NOT the whole story – they are the exceptions and not the rule. I still believe that PCI DSS is a strong positive force for security; maybe the strongest we ever had so far.

Monday, July 13, 2009

Logging and Web Services

This post about the paper we wrote earlier this year (“Logging in the Age of Web Services” by Gunnar Petersen and Anton Chuvakin, published in “IEEE Security and Privacy”) will just prove how behind I am on blogging :-) Fortunately,  Gunnar announced this paper a long time ago; I just added it to “2blog” folder :-) The paper will be a useful read to those into either logging or web services or both. I do suspect that web services audit logging will be one of the unresolved mysteries when SaaS/PaaS/IaaS/cloud everything will enjoy further adoption…

Friday, July 10, 2009

Fun Reading on Security and Compliance #17

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 #17, dated July11, 2009 (read past ones here).

This edition of dedicated to people who send articles for me to read a few months after they are published:  hopefully folks were busy with something worthwhile…

  1. If you think that data breach disclosure laws made people immune to breach new, I bet the new medical breach law will suffer from it. Medical info loss is much scarier than card data loss, for sure. BTW, want smth even scarier? How about this, “DNA Database Breach?
  2. Also, a good insider “hack” story. $9m – gone. BTW, here is another.
  3. A few gems from Gunnar, as usual: “Enterprise Security Priorities” and “But I Don't Want To Trust the Cloud.”  Just read’em, no need to comment.
  4. Moderately fun read “Avoid Security Suffering With These 3 Questions.” Quote: “"What product should I start with?" is a very common first question, but it has about as much use as approaching a doctor and asking, "What medicine should I take?"
  5. Drazen has a good selection of links debating what drives security: ”Regulation vs. Market Forces – A collection of recent posts….” TODAY, market force to drive security = idealism.
  6. Calabrese’s Razor” post covers an interesting approach to risk and security metrics; quote: “I’ve long held the opinion that the community of “Information Security Experts” agree with each other 90% of the time, but waste 90% of their time arguing to the death with other InfoSec Experts about the remaining 10%.”
  7. Fun OWASP survey [PDF] is out, via “OWASP Security Spending Benchmarks Project Report for Q2 Published” post on Boaz blog. There is a lot of interesting SaaS and cloud stuff there. Mike also writes about it here.
  8. This fun read explores the relationship between cloud security and mobile warfare. It is a bit theoretical, but still worth a read: “With cloud computing, IT security can now use maneuver concepts for enhance defense. By leveraging virtualization, high speed wide area networks and broad industry standardization, new and enhanced security strategies can now be implemented.”
  9. Rich @ Securosis has his awesome “The State of Web Application and Data Security—Mid 2009” post. Fave: “When it comes to web application and data security, if there isn't a compliance requirement, there isn't budget.” Ah, and obviously this: “PCI is the single biggest compliance driver for web application and data security.” Overall, a must read!
  10. Web app is in such a horrible state, it isn’t funny. OK, sometimes it is funny. Also, this (see comments too) and this (with a good classifications of reasons…) cover  a lot of idiotic reasons why web application vulnerabilities are not fixed. My fave: “That application is behind 3 [!] firewalls!”
  11. Some fun SIEM FAIL and also here. More on SIEM from Securosis here.
  12. BusinessWeek prints ”Lessons from the Data Breach at Heartland.” Good insight on how business press views “this whole security thing.”
  13. “Honeypots aren’t dead” or “Goldman Sachs Code Torrent” story.
  14. Here is some SCAP fun: “Hot or not: SCAP is heating up”, “How SCAP Brought Sanity to Vulnerability Management” by Ed Bellis (also note the comments to both pieces. BTW, MITRE just did SCAP Developer days which I woefully missed. Here are the slides from the event which, sadly, don’t unzip for me ;-(
  15. Finally, Branden’s blog, as always, exudes pure awesomeness; here are some highlights:  “Do Data Breach Laws Push Compliance?” (quote: “My experience tells me that fines are a much bigger motivator to pushing compliance to a particular standard versus data breach laws.”), “Guest Post: The DNA of Compliance”, “The Top 8 Requirements Your Assessor Misses” (including “Requirement 11.2.a - QSA only documents the external ASV scan and internal scans are not addressed”), “More on NRF's Letter to PCI SSC, and the Wireless Network that Could” (and this post on NRF letter as well) and ”Guest Post: Is it better to be secure, or appear secure?” (scary shit, which reminds me of “Compliance First!” horrors – longer version)

As has become a tradition recently, a dedicated PCI DSS section, a bit short today:

  1. Also, Boaz has some fun discussion on “PCI and Nevada” here and here
  2. Mike Dahn is back into action, and he as a lot of fun blog posts: “The Good, Bad, and Ugly of PCI”, “How Banks and Merchants manage their risk with PCI DSS”  No comment needed – just read’em.
  3. Another awesome list of 10 PCI Misconceptions, courtesy of Rich. BTW, Mike has his own: “10 Fallacies in PCI Conversations.”
  4. Walt has a sadly humorous post about PCI and service providers: “PCI and Your Third-Party Service Providers – First, the Bad News.” Fave quote: “My favorite is when the vendor [=service provider] replies that they are compliant as a Level 3 (or 2 or whatever) merchant. That response is completely irrelevant and inexcusably misleading.”

Enjoy!

Possibly related posts:

Wednesday, July 08, 2009

Trick Question: Can PCI DSS Apply If …

a merchant does NOT store, process, or transmit any cardholder data on merchant premises?

The answer is “Of course!”

Simply if you accept cards, but process them somewhere else. SAQ A (doc) is small, but decidedly not empty.

Just a thought inspired by Trey here.

Monday, July 06, 2009

Nobody Is That Dumb ... Oh, Wait XII

Many, many moons ago I had this brilliant series "Nobody Is That Dumb ... Oh, Wait" (the last one was back in March) where I made fun of people making dumb security claims with apparent - and often scary! - seriousness. Somehow I neglected this series, but a few days ago I was shown a super-shining example of sheer stupidity of immense proportions.

It all started in a remote country of Norway where one particular journalist discovered a horrible evil (mmm… Evil!) that threatens all life in the Universe (mmmm… Multiverse!): honeypots.  Specifically, the English translation of the printed original from their “Aftenposten” newspaper starts like this:

“Unethical and unacceptable, says computer experts.”

Reeeeally? OMFG, thanks for enlightening me that an idiot in Norwegian is spelled “c-o-m-p-u-t-e-r e-x-p-e-r-t” :-)

“We have to trick the hacker to visit our home, without the him knowing. This sounds like a difficult task, but this is some of what honeynets are about. Tricking a hacker into our systems, allowing us to monitor him without his knowledge.”

Exactly: we “trick” them by using the secret honeypot “teknik” called “existence.” If a honeypot exists, somebody will hack into it. Deep, eh?

More fun quotes, hopefully with the correct translation:

“This is the same as if the cops would do private stakeouts in their spare time. No police department would have accepted that, says Professor of Law, Jon Bing.”

and

“This is far more serious than to set up a surveillance camera. It is more like building a new street and seting up surveillance cameras in the whole area, without the visitors knowing that the information is stored and analyzed, says Professor of Law Jon Bing.”

No comment; it is already pretty funny and pretty dumb. But it gets better:

“There is no doubt that the majority of data users who are monitored in honeypots, have not necessarily done anything criminal.”

Oh, so everything this guy learned about honeypots just went out of some hole in his head, interesting…

At this point a shadow figure emerges, which is behind all this: some Lance Spitzner, supreme commander of cybertank troops :-)

“The international organization was started by former US Army tank driver Lance Spitzner, in 1999, to take on the battle against attackers on the internet.
Bush advisor. Spitzner has been a computer security advisor for the  American defence and former president George W. Bush.”

Apart from being 100% false in regards to Bush, it is also pretty darn funny.  Please, dear journalist,  promote me to the Cyber-Apocalypses Supreme Commander for the  Priory of Zion :-)

Overall, let’s use this scale to put his article in proper proportion:

<---awareness ------ ignorance ----- stupidity ----- idiocy -------------------------------------  a particular piece of Norwegian journalistic excellence-|

In any case, if you are looking for a serious response to this from the Project, look here (“Comments on the Aftenposten article”) and here from Lance.

Dr Anton Chuvakin