House of Representatives Homeland Security Committee PCI Hearing TODAY

UPDATE: live twitter from this hearing via tag #pcihearing.


This promises to be huge fun - and starts in about 1 hour...

What: House of Representatives Homeland Security Committee, Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology Hearing “Do the Payment Card Industry Data Standards (PCI DSS) Reduce Cybercrime?”

When: Tuesday, March 31, 2009 @ 2PM EST

Witnesses:

• Rita Glavin, Acting Assistant Attorney General, Criminal Division, Department of Justice
• Robert Russo, Director, Payment Card Industry Data Security Standards Council
• Joseph Majka, Head of Fraud Control and Investigations, Global Enterprise Risk, Visa
• Dave Hogan, Senior Vice President and Chief Information Officer, National Retail Federation
• Michael Jones, Chief Information Officer, Michaels Stores Inc.

There will be a webcast of this hearing: http://hsc.house.gov/about/schedule.asp

Enjoy!

Network Scan for Conficker/Downadup Malware

Detecting Confickr (good analysis here at SRI site) infected hosts via an unauthenticated network scan:

• Original Honeynet Project post: "Detecting and Containing Conficker - Management Overview", more detailed post "Detecting Conficker", a full paper [PDF] and a tool link.
• Dan Kaminsky "Taming Conficker, The Easy Way" and, of course, the related Slashdot thread (yuck!).
• Also, Rich Mogul's "Easily Detect Conficker Infections- Over the Network."

It goes without saying, of course, that Qualys can detect it too now too!

BTW, this post also serves as a self-reminder that we here owe a few good people some beer :-)

Thoughts After Chicago “PCI Dinner” Panel

As I mentioned before, I did this other panel aka “PCI dinner” in Chicago with Branden Williams, Davi Ottenheimer and William Cook, a notable IP/security lawyer from Wildman Harrold. Apart from washing down filet mignon with Sterling cabernet, a lot of fun discussion on PCI DSS took place and a few surprising insights were born. Compliance vs/with/in place of/against Security was definitely one of the major themes.

First, here is one of the insights that appeared. The discussion about PCI DSS and breaches led to a question: “Yes, companies suffer when they experience a breach; but do they suffer enough?” What makes one credit card breach almost unnoticeable on the company books (see: TJX), while the other leads to company’s near-demise (see: CardSystems)? What seemed to emerge was: if the victim company admits failure [of at least admits “a little something” :-)], seems to be trying hard (or, at least, “is seen as trying hard”), goes public with the breach soon enough, etc, the regulators are likely to be more lenient and not penalize it that much (sorry, but $150k fine is NOT “that much”!). On the other hand, companies who are seen as negligent even after the breach, claim innocence despite the facts, behave arrogantly (“No, it is NOT our fault! Screw you! Sue us!”), are more likely to be penalized severely and maybe driven out of business. What do you think?

Another theme, repeated here as well as during the previous panel, was that a nice fat data breach is still the best motivator for security spending and implementation. Definitely, it is “neat” when the breach happens to a similar company that you know well, you get the motivational power without the disclosure loss and all the post-incident frenzy. But then it “decays”: people start questioning their security spending approximately one or two years after the breach. Organizations end up overspending on security right after the breach; instead of spending smaller amounts of money over time. How do you prevent that? I think this shows some uber-desperation for good security metrics!

Next, “outsourcing PCI” via 3^rd party credit card processing is seen as a way to replace the security issue with the contractual issue. If you suck at security and you don’t suck at contracts, the whole “PCI in the cloud” thing kinda makes sense. I suspect that, sadly, many companies know how to deal with contractual issues better than they know how to deal with security issues…

A lawyer brought a good point about “director/officer liability”: compliance does invokes director or officer liability for failure to comply (with, say, PCI), all the way to personal liability. On the other hand, security is rarely seen as something that threatens CEO directly and personally.

The subject of incompetent, ignorant, negligent QSAs came up in the informal discussion. Oops, sorry, I am not at liberty to say more :-) One thing we discussed was: what is more common reason for being “maybe compliant but definitely not secure” - a negligent QSA missing stuff OR a negligent organization, which deceives or misleads their QSA? I was surprised to hear that it was the former. For example, a QSA asks a leading question (“You do this, don’t you? You have this handled just fine, riiight?”) and the organization responds “Yes.” with no additional details. No other information is provided and the answer is accepted.

What deeply shocked me was that somebody reported that a well-known QSA firm was supposedly seen using THE SAME “PASSING” RoC as a template; they just change the assessed company name (!!!) When asked, why don’t their …. victims… eh… clients “rat” them to the council’s QA program, they, reportedly, responded: what if we will be seen as liable? What if a new QSA will “make us do more”? I also learned how to “opinion-shop” for QSAs: ask a bunch of questions to a bunch of QSAs and pick one whose answer presents the smallest gap between your environment and a compliant state (yes, really!)

Here is a fun one too: audience also called for the card brands to solve the problem by creating a more secure payment system. Some suggested that PCI is card brands’ way “clearing risk from their books.” I too would like to see us adopt a more security electronic payment system …. in my lifetime. Also mentioned was how “chip-and-pin” moved fraud from Europe to US, rather than eliminated it.

Also, a lawyer suggested that organizations must not change anything after the breach so that good evidence can be collected. He said that it is even important to indemnify the employees from past security mistakes at the moment of the breach. If you do not do this, a lot of things will be changed by the employees, who are afraid of being blamed for the breach. Good advice – but hard to follow – here!

Finally, we also did a quick unscientific poll: who do you fear more – a hacker or an auditor? It goes without saying that auditors won this round as well, just as the last round. Its OK, folks, just stay 0wned, it’s all good. Just don’t fail the audit :-)

Possibly related posts:

• Thoughts After RMISC 2009 PCI Panel

• Risk vs Risk

Book Review: "Googling Security: How Much Does Google Know About You?" by Greg Conti

I just reviewed "Googling Security: How Much Does Google Know About You?" by Greg Conti and gave it 3 out of 5 Amazon stars. Here is the review, also posted here:

Fails to Scare A Paranoid

I think the book has good information and I enjoyed reading it. However, as I was reading the book, I developed an impression that this was a book meant to scare the reader into some kinda behavior change. In other words, I felt that the book was written to highlight the risks, to explain why given somebody so much information about your online activities is a risky, bad thing and that you should do something differently.

Despite the fact that I enjoyed the book, I think this is where it fails. As somebody who works in security, I consider myself to be pretty paranoid, but the book failed even to scare me! After reading it, I did not become afraid of Google at all. The author highlights some of the presumed risks, but he fails to present scenarios that make the dangers come alive; instead, he makes vague statements ("you know, it can be pretty bad"). So he ends up with a “non-scary Scary Tale.”

For example, when talking about ads, and especially targeted ads, the book suggests that such consumer profiling is scary, but doesn't explain how and why.

To conclude: the book presents a good story of how much Google knows about you, but my impression was that the risks are not made to be scary enough and few resulting behavior changes are suggested. It goes a little like this at time: “OMG, you CAN be hit by the car if you cross the street!” A couple of times while reading it I thought that “you have no privacy, get over it” trumps what's written in the book...

Thoughts After RMISC 2009 PCI Panel

Today I participated in a very interesting PCI panel at ISSA Denver RMISC 2009 conference in Denver.  In fact, even our pre-panel discussion was quite fun: we planned to hit such subjects as checklist mentality vs risk mentality, prescriptive compliance versus outcome-based compliance, PCI for various sizes of organizations and even PCI compliance in virtualized environments.

To start off, it was calming to note that most of the audience agreed that PCI was helpful for their organizations in cases where they wanted to jumpstart their security program, but were not sure how.  Most people also agreed that PCI helped them get executive attention and much-needed budget to implement the security controls they knew they needed to have. No surprises here.

However, at some point in the discussion I started to realize that the desire of some organizations to do “compliance first” and to treat PCI as a “blind” checklist as well as their desire to just focus on achieving compliance and not at all on security was due to the fact that the pressure on them “to be secure” was much weaker compared to the pressure “to be PCI compliant.”
In other words, those organizations who embark on a journey to “we just need to get the auditor/assessor off our backs” fear their auditors more than they fear the hackers (uhu, Russian, Chinese and Romanian combined :-)); at least, their decision-makers seem to. Those same decision makes also likely think that it is much simpler to measure when they are PCI compliant (=when the QSA leaves with a ‘PCI OK’ report) compared to when they are “secure enough” (=when nothing bad happens for a long time DURING WHICH they are not asleep at the wheel…); thus, in their minds,  compliance seems like a “cheap substitute” for security.

So we asked the audience:  “Why do you think some people fear an auditor more than a hacker?”

Results were interesting and somewhat surprising.  Some people suggested that their bosses still (despite all the evidence to the contrary!) share the “it won’t happen to us” mentality.  At this point, I asked “But what about all those scary media stories?”  The audience response was “Well, maybe they don't follow such media…”

When this discussion started, many of the audience members pointed out that PCI compliance projects were initiated by the finance departments or even directly by the CFO.  At the same time, most of the security projects at their organizations were initiated by the IT departments (or their IT security sub-departments).  It goes without saying that CFO has much more of a CEOs ear, compared to some unnamed security manager down in the trenches.

It was also added that senior management and decision makers do not perceive information security personally: no fines on them, no jail time, no clear (to them) chance of losing money or even their whole business.  However, they do perceive various compliance issues as affecting them directly and personally (especially with CFOs reminding them about it).

In light of this, it turns out that the biggest, best driver for implementing security measures and reducing risk to information was still a good old data breach or successful compromise! (BTW, read Rich’s paper on that [PDF]) Sometimes, as one audience member noted, a competitor suffering from such intrusion “helped” as well.  In other words, intrusions, compromises and other “0wnage” drives security, while regulatory mandates sometimes drive only “empty” compliance and none of the security (especially when a security department is either missing or inept at harnessing “compliance power surge” to further the actual risk reduction agenda).

While I was listening to the discussion, I realized that PCI has  no “superpowers” to magically make “security-ignorant” organization secure despite itself: if you are hellbent on ignoring security, PCI will not make you security conscious. If you want to help yourself and you organization to become more secure,  PCI DSS guidance is of service. Herein lies one of the more interesting “limitations” (better called “perceived limitations”) of PCI and, in fact, of any detailed, prescriptive security guidance: one can choose to use the “checklist”  to be followed blindly with no real advancement of security…

To conclude, it goes without saying that PCI is very helpful start for security for those who want to start; the rest can still choose to screw it up, no matter what level of detail is given in the prescriptive compliance mandate. PCI won’t stop you if you insist on ignoring security; it can only make it a bit harder.

Possibly related posts:

• Tales From the “Compliance First!” World

• More on “Compliance First!”

• PCI DSS and Data Breaches: Perception and Reality

• Risk vs Risk

Fun Views on DLP

For quite some time, I was meaning to write another post about “data leakage/loss prevention/protection” (DLP) – and this weekend presented a perfect opportunity. This post is also mildly inspired Richard’s Data Leakage Protection Thoughts from February 2009 as well as “lively” discussion that ensued.  Also, I would like to bring the method I used in PCI DSS and Data Breaches: Perception and Reality, namely, contrast perceptions and reality of what is considered to be “DLP” today.

So, personally, I have seen/heard the following views on DLP:

1. DLP  is worse than useless; it is actually harmful due to false sense of security it provides [e.g. in comments here it is called “an expensive, distracting failure”]
2. DLP is completely, 100% useless.
3. DLP is useless against anybody, but a certifiable, clinical idiot [BTW, this says nothing about its overall usefulness – there are plenty of idiots who are after your organization…]
4. DLP is great, as long as you monitor and not block.
5. DLP is great, as long as you block and not monitor.
6. DLP is not perfect! [some then quickly to jump to “…and thus useless”]
7. DLP is perfectly workable as long as a) you know what you want, b) the task is actually technically feasible and c) DLP is capable of doing that task.
8. DLP IS “That Silver Bullet” (tm).
9. DLP is everything: backup, encryption, access control – it cannot be good or bad, since it is EVERYTHING.

I wouldn’t spend much time talking about extreme views such as #1, #2 as well as #8, #9; as usual, there is usually little truth in extreme views. Additionally, a piece of technology seen as “truly useless” by some can be a “God-send” for others, depending upon what’s on their network and what’s on their minds. I will also not touch #6 as self-evident. Richard does a good job explaining #4 and #5 is his post, specifically leaning towards #5 (even though I suspect he underestimates the data discovery and classification angle of DLP a bit…). To top it off, it is also quite hard to perform such level of analysis while talking about technology “in general,” not any particular box.

So, what do we have left? These two:

DLP is useless against anybody, but a certifiable, clinical idiot

DLP is perfectly workable as long as a) you know what you want, b) the task is actually technically feasible and c) DLP is capable of doing that task.

The first one is an interesting one; it is typically tossed by people who are technically advanced and who know that THEY will never be blocked by an early 21st century DLP system. However, the jury is still out on the overall harm brought by so-called “IT idiots.” I think if some DLP vendor will market a near-100% effective (eh… effective vs subjects highlighted in the solution name, that is) “IdiotDefense DLP 2.0,” it will sell pretty darn well as a lot of real, hard $$ are burned due to stupid behavior. Also, Kevin’s comment (here) rings very true: "The threat surface is actually quite complex and not so simple as "stupid-employee" vs. "evil genius hacker". So, “Idiot+ Defense DLP” has a pretty real use case.

The second point is my favorite and I covered it in my previous posts on the subject, specifically in the “So, CAN We Have DLP?” That point was trivial and deep at the same time: it – hopefully correctly! – states that there are enough people who need what DLP offers; thus it is clearly useful for them. And just as was typing this, I saw this Forrester report with this amazing statistic: “About 38% of enterprise customers have DLP implemented already. Another 21% are planning to implement it this year.” I am sure this is biased towards the higher side, but still.

The report further goes one and says “These two issues -- increased toxicity of customer data, and mandates designed to protect that toxic data -- are the primary reason DLP is taking off. About 80% of the time, enterprises evaluating DLP are doing it because of toxic data problem [A.C. – and NOT due to intellectual property protection yet - “toxic data” use case seems to be easier to grasp and to start off with compared to IP protection].” 

Another worthwhile read related to this is A Response to Bejtlich on DLP which highlight another – sadly common! – case where DLP will be useful: “… DLP has potential to allow an organisation with an immature security posture, to fairly quickly put controls around high risk data, start working out where their high risk data is stored and where their biggest leaks are.”  Finally, here is also a fun report about nexTier, a DLP vendor that lists me on the Advisory Board.

Possibly related posts:

• In Passing on DLP

• So, CAN We Have DLP?

• A Few More Words on DLP and Compliance

• DLP Works – If You Know What “Works” Mean!

OMFG - Mutiny on Board

Cory Doctorow starts (! - that is how he starts) in his "The High Priests of IT — And the Heretics": "Though I've done time in corporate IT — and have even born the CIO title more than once — I've always had more sympathy for the firewall-breaking, virus-toting, data-leaking users than I have for the responsible and sober IT departments that struggle every day to keep the systems running while the users set out to dismantle it."

One comment: OMFG.

More SHOCKING quotes: "Contemporary corporate IT's top job is locking down the PC and the network, blocking users from installing their own apps, blocking them from accessing forbidden websites (nominally this is about blocking porn, but a dismaying number of workplaces also block IM, webmail, blogs, message-boards, and social networking services where employees might otherwise find useful, low-cost coordination with other employees, suppliers and customers), and spying on their every click and keystroke to capture the occasional bad egg who's saying or doing something that could put the whole firm at risk."

"The fact is that the most dreadful violators of corporate policy — the ones getting that critical file to a supplier using Gmail because the corporate mail won't allow the attachment, the ones using IM to contact a vacationing colleague to find out how to handle a sticky situation, the incorrigible Twitterer who wants to sign up all his colleagues as followers through the work day — are also the most enthusiastic users of technology, the ones most apt to come up with the next out-of-left-field efficiency for the firm."

More comments - I will add more as people post them:

• "The High Priests of IT"
• "Of maturity and mediocrity."

This deserves to be discussed widely in the security community...

Nobody Is That Dumb ... Oh, Wait XI

Many, many moons ago I had this brilliant :-) series "Nobody Is That Dumb ... Oh, Wait" (the last one was back in May 2008) where I made fun of people making dumb claims with apparent - and often scary! - seriousness. Somehow I neglected this series, but today I just happened upon a perfect piece to restart it.

So, when was the last time somebody who appears to be in a security business proclaimed:

"Is complying to PCI not enough anymore?"

Yes, really! NEWFLASH!!!!!!!!! PCI compliance is not enough. Wow, really? Why would you say that?

On Heartland V

Sorry, but I cannot resist – here comes “On Heartland V.” Why did I break my promise?

This is why:

Source: DatalossDB

And this is why:  “Class Action Lawsuit on behalf of certain investor in Heartland Payment Systems over alleged violations of Federal Securities Laws” (here)

And this is why:  “Visa withdraws Heartland PCI compliance” (here) And “a little bird” (tm) brought this missing piece of info: their merchants are contractually obligated to do business with a PCI-compliant processor (please confirm or deny this rumor, if you have more info)

Overall, in light of the above I now think that Heartland might well end up being “CardSystems 2.0” and actually die. That will make “security doesn’t really matter” crowd … well… not matter :-) At least for a while.

Case closed? Security breaches actually … gasp! … matter for business.

Possibly Related Posts:

• On Heartland I
• On Heartland II
• On Heartland III
• On Heartland IV
• Compliant + Owned = ?
• Other PCI DSS coverage

Dillbert on "Risk Management Software"

Dillbert on "Risk Management Software"

It's Official: Heartland Is NOT PCI Compliant (... Anymore)

A fun read here: "Visa Puts Heartland on Probation Over Security Breach"

Key points/questions/quotes:

• "HPS has advised, however, that it is aggressively working on remediation and re-validation of its systems to comply with PCI DSS standards." - AND then let them lapse into insecurity+non-compliance again? If not, why not? How do they plan to be sure?
  
• "The company will be relisted once it revalidates its PCI DSS compliance using a Qualified Security Assessor and meets other related compliance conditions." - OK, SAME QSA or a different one?
• "So Heartland is off of Visa’s Christmas card list for 2009, but they still get a fruitcake." - OMG, I get it now: Heartland is "TOO BIG TO FAIL" :-)
• "Fines - In accordance with Visa Operating Regulations, fines will be assessed to Heartland’s sponsoring banks." - Ah, fines finally! BTW, the definition of a "sponsoring bank" is here.
  
• "This recent compromise underscores the importance of all parties maintaining ongoing compliance with the Payment Card Industry Data Security Standard." - to me this line is proof that "people in the know" now know that Hearland case is the case of them being validated PCI-OK (by a QSA of unknown degree of "anality") and then lapsing into insecurity AND non-compliance.
  

Possibly related posts:

• “Compliant” + 0wned = ?

Brian's Interview With Me on PCI, Vulnerability, Application Security, etc

Brian did this fun interview with me a few days ago. The topics are PCI DSS (of course!), vulnerability management, application security and other fun stuff. The actual interview is here and a direct link to MP3 here.

How's That For Compliance=Security?

So I was googling for something and happened upon this hilarious gem of a quote (here): somebody "is calling for a PCI DSS status directory in which compliant merchants and processors are publicly listed. Opponents say such a directory could be used by hackers to find vulnerable companies to attack."

I know, I know... it is most likely taken out of context and all; but it doesn't stop me from ROFLMAOing here.

RSA 2009 Panel on Log Standards

Yes, the words “log” and “standard” in one sentence; alongside each other, in fact :-)

 

Session Code: HOST-304

Session Title: Common Event and Log Standards: Leveling IT's Tower of Babel

Scheduled Date/Time:  Thursday, April 23 02:10 PM @ Purple 304

Abstract:  The IT industry suffers from a lack of standards for event, log, and audit information. Regulatory requirements to retain, protect, and destroy log data continue to increase. Organizations also need better situation awareness and cost control across complex IT security event horizons. The good news is that standards efforts are underway, which this session will detail.

Moderator:

• Daniel Blum, Senior VP, Principal Analyst Burton Group

Panelist:

• Anton Chuvakin, Director of PCI Compliance Solutions, Qualys
• David Corlette, GRC Solution Architect
• Eric Fitzgerald, Senior Program Manager, Microsoft
• Mary Ann Davidson, Chief Security Officer, Oracle

Attendance is mandatory :-)

More on “Compliance First!”

I was about to post this back in January (!), but then Heartland blew off (coverage of the Heartland processor breach: On Heartland I, II, III and IV) and now it seems like ancient history. Still, I think one can say that the Heartland case shed some new light on the problems I covered in my “Making PCI Easier” and “Compliance First?” posts.

So, these were the  responses:

• Risktical’s  Making PCI Easier – A Reality / Health Check (“This post is more focused on merchants or processors making PCI compliance easier for themselves. My thought process is that if merchants can make some aspects of PCI compliance easier on themselves – then there is a reduced need for relying “so much” on QSAs and less heartache around PCI-DSS in general.” – the post is also full of other comments useful for those dealing with PCI DSS “in the trenches”)
• RiskAnalysis.is’s Using The Compliance Stick Actually Weakens You   (“WHY PRESCRIPTIVE COMPLIANCE WEAKENS OUR INDUSTRY. […] Using prescriptive regulatory compliance to “get your way” removes your ability to be that [A.C. - see full post] consultant.  So you don’t help make good decisions and therefore, in the eyes of management, have yet to earn the right to make the decisions you feel you need to make.   In the long run, you turn into the “guy who manages our PCI stuff”, and your value is limited to doing just that.  And therefore, so is your budget, your ability to execute, and ultimately, your “security”.” – a good argument that debates my points; in fact, I agree with it – BUT only in the context of a mature risk/security management program, not small ignorant company…)

• Infosec Ramblings’s Interesting Information Security Bits for 01/15/2009  (“Compliance does not equal security. Never has and never will.” – just a useful reminder!)

• Martin’s “Security first” please! (“While I’ve only heard of one concrete example of a situation where PCI caused a company to actually become less secure than they were before, I’ve seen multiple examples of company’s that were concentrating so hard on meeting compliance deadlines that they ignored any security measures around their network that weren’t directly related to PCI. ”  - his post expands this discussion, he also picks on my second point [see comments below this post])

And, finally, some news from the Delusion Dept: some people somehow still think that “compliance=security” (yes, really!)

• Treasure Institute’s Compliance First vs. Security First (Updated Friday 1/16)  is great by itself, but a real “gem” was dropped by one of the visitors: “… putting compliance first is putting security first, and vice versa.” )

There you have it – thanks to all who commented on these posts; hope they were useful to deepen our understanding of this whole conundrum…

BTW, in my next post, I will address a common misconception that “a PCI scan is a pussy scan.” :-)

Possibly related posts:

• Tales From the “Compliance First?” World
• Making PCI Easier
• On Heartland I
• On Heartland II
• On Heartland III
• On Heartland IV
• Compliant + Owned = ?
• PCI DSS and Data Breaches: Perception and Reality
• Other PCI DSS coverage

Fun Reading on Security and Compliance #13

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 #11, dated Feb 20th, 2009 (read past ones here). I admit that some stuff has been sitting in my “2blog queue” for way too long, but you know what? If it is relevant after a few weeks of “cooling down,” it is even more worth reading :-)

This edition of “Fun Reading on Security and Compliance” is dedicated to all those people in our security community who are “too busy to read blogs.”

1. OMG, not disclosure debate again. Yep, it sure seems like it. Starts here and then goes on when Pete “The Disclosure Warrior” Lindstrom picks it up.
2. Our CTO Wolfgang Kandek discusses IE on our new blog. Specifically, check out this shocking bit: ”Internet Explorer 6 continues to be the more prominent browser in the Enterprise.” IE7 came sooooo long ago (I think in 2006) and meanwhile “I use IE” became synonymous with “I am 0wned” – but people still don’t upgrade?!
3. CAG is out and – as far I can see – the response is ranging from skeptical to negative. Here are the examples: Richard’s “Consensus Audit Guidelines Are Still Controls”  (“CAG is all about inputs.”) and “Inputs vs Outputs, or Why Controls Are Not Sufficient”, (ISC)2’s “Consensus Audit Guidelines - What is the consensus?” (“I do not believe the initial draft of the CAG meets the goals it set out to achieve, and should be adjusted accordingly.”) and even “Clouds of CAG Confusion” (“There is a haze of confusion settling around the Consensus Audit Guidelines origins.”) BTW, here is a good CAG-related preso, direct from its mysterious source.
4. Next, Gunnar reminds us to be “to be asset focused, not auditor focused, in infosec”  by using “Berkshire 2008 Annual Letter”
5. Hoff’s “Offensive Computing - The Empire Strikes Back” reminds us to think again – is security really about “war with hackers?” and we need offense. What if it is insurance? Or door locks? Or something else?
6. Something I wanted to highlight for a long time: “How to Suck at Information Security” A very good thing to read next is “Information Security: How Does Your Organization Fail?”
7. Another one that spent too much time in my 2blog folder: “Alignment of Interests in Web Security” from Jeremiah.
8. Layer8 post reminded me why I swore on an Orange Book [on second thought, I should have used a Tan Book :-)] to never get a CISSP…
9. Feel like getting de-pe-re-me-trized? :-) Make sure you don’t kill BOTH network security AND system (=endpoint) security at the same time:  “Deperimeterization without endpoint control?”
10. Reminders, reminders… The “you’ve GOT to be realtime” crowd is less noisy now, but here is why before you utter the word “proactive” you should at least learn to be “reactive” well! Richard states it succinctly here: “we should adopt a mindset, toolset, and tactics that enable retrospective security analysis -- the ability to review past evidence for indicators of modern attacks”
11. Finally, IT in the year 2109? Yes, really. We will be “using technology that is able to transmit data at speeds of 10,000+ times the speed of light”…

Enjoy!  This post is certified “Heartland-free” :-)

All other “security reading” issues.

On "PCI Myths: Common Mistakes and Misconceptions About PCI"

We are doing this fun event "PCI Myths: Common Mistakes and Misconceptions About PCI" on 3/19/2009. Here are the details - I promise it will be fun:


"Date: Thursday, March 19, 2009

Time: 2pm EST / 11am PST

Length: 20-30 min plus Q&A

Synopsis:

The briefing will cover PCI DSS-related myths and misconceptions that are common among some merchants and other organizations dealing with PCI DSS challenges. Mistakes related to the technical and process side of PCI, self-assessment and audits as well as PCI validation requirements will be discussed. The information will be useful to all merchants dealing with credit card information and thus struggling with PCI DSS mandates."

Come join it!

Stratfor on Chinese Bots

A very fun read from Stratfor, available in open access: "China: Pushing Ahead of the Cyberwarfare Pack."

I took issue with a few of the bits in the piece and received a nice clarification from them. The bits were:

"The Chinese government can decipher most types of encrypted e-mails and
documents" (I said that it is defies the common sense of most every
cryptographer as brute-forcing many today's algorithms is pretty much
impossible - they clarified that they meant to add "... by 0wning the endpoints," which makes their point quite correct.)

"Details were vague, but the implication was that computer encryption
inside China would become essentially useless." (disclosing the algorithms
does NOT make encryption useless - they clarified that they mean "... hardware encryption with key embedded in a device and device available to China" which makes it pretty true)

"The government’s strongest tactic is a vast network of “bots” —
parasitic software programs that allow their users to hijack networked
computers." (the fact that bots are govt-controlled and not individual
hacker group-controlled has NEVER been proven; this is just a rumor - this point is still highly debatable, IMHO)

"Today, with current technology, the Chinese government can hack into most
anything, even without information on specific encryption programs."
(my comment was "no comment" on this one :-))

"Many Chinese Web sites have these embedded bots, and simply logging on to
a Web site could trigger the download of a bot onto the host computer."
(again, no proof that this is by govt, not hackers)

In any case, enjoy the piece here.

Monthly Blog Round-Up – February 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 an attempt to remind people of useful content from the past month! If you are “too busy to read the blogs” (eh…cause you spent all your time on twitter? :-)), at least read these.

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

1. Just as last month, my coverage of Heartland data breach saga took the #1 spot, by a long shot. Specifically, “On Heartland”, “Heartland II”,“Heartland III” and new “On Heartland IV” are the most popular. My first original post is here too (“Compliant + 0wned”) – the second just came up (“PCI DSS and Data Breaches: Perception and Reality”)
2. Next up, strangely, is my obscurely humorous post on SAQSA (“PCI SAQSA?”) – and to think that many people suggest that ‘humor’ and ‘auditors’ don’t mix …
3. A post where I link to a rumor of a new processor breach (“New Processor Breach?”) is next. No solid info has since emerged.
4. Next is my link to SANS SIEM whitepaper (“SANS on SIEM”); it is good reading on SIEM, even if a bit too “EPS-obsessed” to my taste.
5. And now something weird: two completely unrelated posts tie for the 5th place: an old  “On Doomsaying (Terry Childs case)” and a new “CAG Out!”   Please joke about it at your own leisure :-)

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

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

• Monthly Blog Round-Up - January 2009
• Monthly Blog Round-Up - December 2008
• Monthly Blog Round-Up - November 2008
• Monthly Blog Round-Up - October 2008
• Monthly Blog Round-Up - September 2008
• Monthly Blog Round-Up - August 2008
• Monthly Blog Round-Up - July 2008
• Monthly Blog Round-Up - June 2008
• Monthly Blog Round-Up - May 2008  
• Monthly Blog Round-Up - April 2008  
• Monthly Blog Round-Up - March 2008  
• Monthly Blog Round-Up - February 2008  
• Monthly Blog Round-Up - January 2008  
• Monthly Blog Round-Up - December 2007  
• Monthly Blog Round-Up - November 2007  
• Monthly Blog Round-Up - October 2007  
• Monthly Blog Round-Up - September 2007
• Monthly Blog Round-Up - August 2007

 

Technorati Tags: chuvakin,monthly,blog,security