Book Review “Beautiful Security”

As I mentioned before, I just had to celebrate the release of this awesome security book “Beautiful Security” from O’Reilly, which I just finished reading.

Now, I will probably have a high opinion of my own chapter (“Beautiful Log Handling”) since it took some work (eh… and one complete rewrite :-)) to create (this why people LOVE O’Reilly books!!) However, I am just about as excited about the rest of the chapters in the book.

Namely:

1. Psychological Security Traps  by Mudge: awesome chapter with some fun ideas. Must read.

2. Wireless Networking: Fertile Ground for Social Engineering

3. Beautiful Security Metrics by Betsy Nichols: if you are “a metrician”, there won’t be anything new (apart from here interesting medical research analogy); otherwise, a MUST read!

4. The Underground Economy of Security Breaches: not a bad, even if a bit dated, review of underground economics.

5. Beautiful Trade: Rethinking E-Commerce Security  by Ed Bellis: this is one of the 2 chapters  that I like more than my own (and that is coming from a fairly egotistic person ;-)); this has lots of visionary ideas on payment security.

6. Securing Online Advertising: Rustlers and Sheriffs in the New Wild West by Ben Edelman: this one is a fascinating read about attacks by and on online advertizing. Definitely both enjoyable and insightful.

7. The Evolution of PGP’s Web of Trust

8. Open Source Honeyclient: Proactive Detection of Client-Side Exploits: a good read for those not familiar with “client honeypots” or “honeyclients”

9. Tomorrow’s Security Cogs and Levers  by Mark Curphey: this chapter exudes pure awesomeness and is the best in the book; read it three times already and plan to read a few more. A quick preview of what is in the chapter is here on Mark’s blog. Sorry that it sounds cliché, but this chapter definitely stimulates new, beautiful ways of “thinking security”!!

10. Security by Design by John McManus: a very good chapter that mixes NASA, security and software design. Read it and learn from it.

11. Forcing Firms to Focus: Is Secure Software in Your Future? by Jim Routh: great chapter that describes one company’s battle for securing software (first, its own and then 3rd party)

12. Oh No, Here Come the Infosecurity Lawyers: way too much ROI and ROSI to my taste; also has ALE horror. Killed all the fun for me.

13. Beautiful Log Handling  by Anton Chuvakin: eh…make your own opinion here :-)

14. Incident Detection: Finding the Other 68%  by Grant Geyer: good old data correlation of IDS alerts, logs and other information is covered in this well-written chapter.

15. Doing Real Work Without Real Data

16. Casting Spells: PC Security Theater: this chapter was sad as it was the last. It was a sad piece of misdirected marketing that should have no place in O’Reilly books, IMHO.

Overall, this was BY FAR the most insightful and enjoyable security book that I’ve read in a long time!

BTW, authors of this book are not getting paid, but feel free to grab your own copy at Amazon or elsewhere.

Possibly related posts:

• It Changed My Life: My Review of "Geekonomics” book
• All security book review posts.

Security Quote of The Day

Security quote of the day is from here and is related to today's "secure Nation's cyberspace" events:

'"In short, America's economic prosperity in the 21st century will depend on cybersecurity," said Obama.'

BTW, a direct link to "Cyberspace Policy Review: Assuring a Trusted and Resilient Information

and Communications Infrastructure" [PDF] is here; it is a farely boring read, but read it it anyhow :-( And, finally, my one line summary of the above PDF: "The status quo is no longer acceptable."

MUST Read PCI DSS Paper “PCI: Requirements to Action”

OK, so this paper ("PCI: Requirements to Action" by Ben Tomhave) deserves a blog entry of its own rather than being buried in a security reading post. It also proves that the claim that nowadays people just won’t read a 38 page paper is just wrong :-)

The fun thing about this paper is that it brilliantly combines the passion of a well-fired rant with a coolness of a detailed procedural document. Read the first 6-7 pages to see a great philosophical discussion on PCI DSS (which is a little too dark at times, to my taste: I just hated that “murky twilight of security management” phrase). Read the rest of the paper and see a lot of useful and actionable guidance on how to think about PCI implementation and even how to do it.

Here is an example of such set of action items from the paper:

Finally, keep in mind that the paper is written solely for large companies (I am guessing L1s and large L2s), but has some ideas useful for smaller ones.

Now enjoy the paper!

On StrengthsFinder 2.0 Test

If anybody happens to care, I just took this hugely insightful professional development test called "StrengthsFinder 2.0" which is supposed to highlight your strengths from a list of about 40 and also to give you some ideas on developing those strengths.

Perhaps unsurprisingly, here are my top strength results:

1. Strategic
2. Futuristic
   
3. Achiever
4. Ideation
5. Communication
   

Enjoy! To take your own test, you need to purchase a book ("StrengthsFinder 2.0" or "Strengths-Based Leadership" by Tom Rath) that has a registration code (I am not aware of any other way to take it).

Fun Reading on Security and Compliance #15

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 #15, dated May 22, 2009 (read past ones here).

This edition of dedicated to DRM: “Don't worry about people stealing your idea. If it's original, you will have to ram it down their throats.” (source) :-)

1. Adam continues an old Richard’s discussion on security inputs and outputs in his “Security is about outcomes, not about process”: “We've focused on process because we have so little data on outcomes. People will talk about their training processes. But when you ask them, did that process work? no one wants to say.” Pete adds to this discussion here.
2. “Geekonomics” future is coming? “Software Developer Liability Up For Debate In Europe”: “It appears that it's back up for debate in Europe, where the European Commission wants to make developers liable for buggy code.” More comments from one security vendor here.
3. A good read from Shrdlu ““Security is dead” must DIE.” Quote: “Is the rain attacking you as you walk beneath your umbrella?  Yes, water can drown you if applied correctly, but it doesn’t mean every drop is trying to kill you” and “you have a massive disconnect between the population that doesn’t think anything is possible—and the population that knows what’s possible and believes it all to be inevitable”
4. “The Security Implications Of Google Native Client” from the dark wizards at Matasano: “So the primary obstacle between Google and the future of software delivery is security. Google has a lot of interesting ideas about how to overcome that obstacle.”
5. Ben’s mini-treatise on risk management (“Dowsing Your Way Through Enterprise Risk”) is a fun read: “In many ways, risk assessment today is exactly living dowsing. We walk into organizations with some mystical methodology that assesses pseudo-risk and then we act is if we've done something that is in fact truly legitimate and well-founded. […] As such, we're stuck with gut instinct in assessing risk ratings, challenged in trying to come up with a consistent, reliable, and accurate method.”
6. The best read of the week (“The Future : Regulation is Futile – Market Forces Will Prevail”) comes from a super-enlightened Mark Curphey; there is too much to quote there, may be this: “Regulations will not work. “You can’t regulate the problem away”. Market forces drive economic change and when the cost of security becomes something everyone considers, people will act on Fact and not FUD. […] Market forces (insurance) will drive change. Market forces require empirical data to provide a framework in which to trade.”
7. Finally, why are people upset about PsyOps being conducted? Mike Murray links to an awesome read on Obama’s use of NLP patterning in his speeches: “It’s an excellent description of many hypnotic language patterns and how they can be used artfully to influence a large audience.”

Special PCI DSS section:

1. Required reading to those who say “PCI is too tough”: “Regulating IT Security Practices. PCI DSS too tough?:” “There’s really little in the PCI DSS that is not normal good IT security practice. If you’re not doing it [good security practices] now, questions should be asked as to why not? Businesses have an obligation to be doing it….for themselves, business partners, customers, staff, shareholders and society as a whole. If it takes a big stick to make it happen, well, I’m all for that.”
2. Mass hosting site + PCI DSS – thinking = security disaster; a worthwhile read “Mass Hosting && PCI: A Case Study”
3. Pete analyzes Verizon report as a measure of PCI DSS effectiveness in his “Verizon's DBIR on PCI Effectiveness” and “Is PCI Working?” and finds the data insufficient. While it is not the last word on PCI efficiency, the amount of insight there is still pretty enormous. BTW, more fun comments on the report are here and here.
4. Dave Taylor shares why “Why Most PCI Self-Assessments Are Wrong” – the idea is that many QSA- or self-assessments will miss undocumented, but risky and blatantly-non-compliant business processes. Also, here is another great read from Dave (“The technical complexity of the controls is inconsistent with the grading system that requires 100 percent to be compliant.”) And another one: “Raising the Bet: A National Payment Security Standard” where he reveals that a new, non-PCI retail security standard is coming!
5. Some people are somehow upset that PCI is about transferring risk. I don’t get why anybody should be upset about transferring risk to where is belongs: merchants are insecure –> they get breached –> they suffer. Seem perfectly fair to me, why should issuing banks eat all the losses?
6. Branden, my brand new co-author and partner in [PCI] crime, reminds about a big hole: “Compliance & Security Diverge on Private Label Cards.” Quote: “Here's one of those areas where security and compliance stare at each other angrily across the table instead of skipping down the trail together singing, "Tra-la-la."”
7. Can one take the PoS out of PCI scope? Analysis here in “Take The POS Out Of The Scope Of PCI.” It sounds a tiny bit fishy to me, since the card data will still traverse the PoS, but it is a fun read.
8. Finally, a good reminder that it is NOT true that “the only people who defend PCI are the ones who profit from it.” A fave quote: “One of the more difficult issues that I face with dealing with a company that is trying to obtain PCI compliance without a serious concern for security, is that they will do just about anything to obtain compliance.”

Enjoy!

Possibly related posts:

• All other security reading posts.

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

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. Enough ranting; let’s give those PCI skeptics something to whine about!

Let’s start from the obvious. There are a few general ways in which PCI provides value to organizations; such as by creating awareness or motivation for security improvements and data security in particular, helping loosen security budgets (and points at a few things that you probably should have bought even without PCI…), providing a simple laundry list of basic security controls (for those who don’t know what they are) as well as by simplifying [some say too much] “the whole security thing” for those who would otherwise ignore it.

However, this is not what I have in mind here: I’d like to draw my readers’ attention to a few specific things in PCI DSS guidance that will help with security if they are implemented. Also, please keep in mind that your PCI QSA is your final authority on what must be done for PCI, not some random blog on the Internet! :-)

Finally, 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 now twitter their way to infamy…

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

Tip #1 will focus on something very  basic, non-controversial and – we are in luck! – spelled out very clearly in PCI DSS: namely, passwords.

PCI DSS has a few areas where the use of passwords for cardholder data security is discussed:

Requirement 2 covers the following:  “2.1 Always change vendor-supplied defaults before installing a system on the network—for example, include passwords, simple network management protocol (SNMP) community strings,  and elimination of unnecessary accounts.”

This simply means make sure that if you buy “a piece of IT” which has a default password, it is changed right before said piece of technology is connected to a production network. Simple, obvious [for those doing security for more than a few minutes :-)]  and useful, since password guessing and default account trawling are still common ways to break into networks. BTW, I said “a piece of IT” and not “a computer”, since it applies to various devices (routers, switches, wireless gateways, etc) as well.

Requirement 8 covers the following:

“8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography.”

This simple means that passwords should never travel across the network in clear text (such as in FTP and – gasp! – telnet). BTW, for every one time that somebody says that “nobody is using telnet anymore”, I can point at a box that has telnet enabled (yes, this is 2009, not 1989!)

Same requirement also has the following guidance:

“8.5.3 Set first-time passwords to a unique value for each user and change immediately after the first use.”

“8.5.7 Communicate password procedures and policies to all users who have access to cardholder data.“

“8.5.8 Do not use group, shared, or generic accounts and passwords.”

“8.5.9 Change user passwords at least every 90 days.”

“8.5.10 Require a minimum password length of at least seven characters.”

“8.5.11 Use passwords containing both numeric and alphabetic characters.”

“8.5.12 Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used.”

This simply means that passwords should be kept secret, hard to guess, hard to break, changed frequently-enough-but-not-too-frequently, and not reused – and that all the above stuff should be known to everybody who can change his/her own password and who can touch card data.

Some automated tools can scan your systems and automatically verify that such configuration settings are in use across many systems.

BTW, if you read this and thought “huh? there is nothing here that I didn’t know before,” I have a secret to tell you: this was NOT written for you; this was written for somebody who runs the site where you just bought that new iPhone and who now has your credit card data…

On “Beautiful Security”

This is my first post since coming back from vacation; as you can guess, I’ve been busy with work and not with blogging. Still, I just have to celebrate the release of this awesome security book “Beautiful Security” from O’Reilly. I just received my author copies and can’t wait to start reading the other chapters.

Now, I will probably have a high opinion of my own chapter (“Beautiful Log Handling”) since it took some work (eh… and one complete rewrite :-)) to create (this why people LOVE O’Reilly books!!) However, I am just about as excited about the rest of the chapters in the book. Namely:

1. Psychological Security Traps

2. Wireless Networking: Fertile Ground for Social Engineering

3. Beautiful Security Metrics

4. The Underground Economy of Security Breaches

5. Beautiful Trade: Rethinking E-Commerce Security

6. Securing Online Advertising: Rustlers and Sheriffs in the New Wild West

7. The Evolution of PGP’s Web of Trust

8. Open Source Honeyclient: Proactive Detection of Client-Side Exploits

9. Tomorrow’s Security Cogs and Levers

10. Security by Design

11. Forcing Firms to Focus: Is Secure Software in Your Future?

12. Oh No, Here Come the Infosecurity Lawyers!

13. Beautiful Log Handling

14. Incident Detection: Finding the Other 68%

15. Doing Real Work Without Real Data

16. Casting Spells: PC Security Theater

BTW, authors of this book are not getting paid, but feel free to grab your own copy at Amazon or elsewhere :-)

PCI Myths Webcast Recording and Q&A

It took a while, but here is some fun Q&A from that PCI DSS Myths and Misconceptions webinar we did a few moths ago.

• PCI Myths slides on Slideshare (teaser, full version)
• Audio recording of the presentation and Q&A with slides
• Select Q&A are below

Some questions are way too deep to be answered in a blog post; still, I hope the answers are useful to my readers.

Q: What about the organization that says "but we use authorize.net, PayPal, Google Checkout (or whoever) to process our card payments for items we sell on the web. We don't ever handle the card data ourselves, so we don't need to worry about PCI...do we?"

A: Indeed, outsourcing credit card data processing is a very good way of reducing the scope of your PCI compliant environment. However , it is not the same as “outsourcing PCI DSS” since it does not completely shield you from PCI DSS requirements. “Scope reduction” is NOT “PCI elimination.” There are still areas where you must make an effort to comply. However, PCI Qualified Security Assessor (QSA) is the authorized source of this information.

Q: What is the purpose of the Self Assessment Questionnaire and why do we need to complete one for each scan? Our credit card processing company requires us to complete a Self Assessment Questionnaire to accompany each scan.

A: SAQ purpose is to assess (well, “self-assess”) security posture of an organization, just as the name says. The SAQ is a way to review the security controls which are in place without the help of an auditor. There is no formal requirement to complete a self-assessment questionnaire after every quarterly scan. Scans must be performed once a quarter, while a self-assessment questionnaire must be completed once every year. However, your acquirer might have a different opinion and might prefers to collect more information about you on a more frequent basis. BTW, you are supposed to answer the SAQ honestly, to the best of your knowledge, and remediate the gaps found.

Q: Is a QSA the only authorized entity to run a scan or can I as the owner of our business run the scan myself?

A: This is a pure misconception; 100% false. As per PCI DSS requirement 11.2, an approved scanning vendor (PCI ASV vendor) must be used for external (=Internet-visible) scanning. Internal scanning can be performed by yourself or anybody else skilled in using a vulnerability scanner.

Q: Do we need to ensure that our third party fulfillment company is PCI DSS compliant as well (especially if they are taking credit card numbers for our customers)?

A: It is hard to say how the contracts are written in such case, but often the answer is indeed “yes.” Moreover, if they take credit cards they need to be compliant and protect the data regardless of their relationship with you. PCI QSA is the authorized source of this information.

Q: Is this [PCI] a US requirement only or do we need to ensure that our international offices are in compliance as well?

A: PCI DSS is most definitely not just US; it is a worldwide mandate by the global card brands: Visa, Mastercard, American Express, Diners Club, etc.

Q: I thought using PA-DSS application makes me PCI compliant, isn't that the purpose of the PA DSS?'

A: Not, it most certainly does NOT. PCI DSS and PA DSS are separate mandates; one applies to organizations, networks, systems [PCI DSS] while another [PA DSS] applies to payment applications only. This is actually a very common misconception. Using PA DSS-certified application certainly does not make you PCI DSS compliant!

Q: Is a fax with credit card information that arrives to organization’s fax server considered to be a digital copy of this data?

A: A digital fax containing a credit card number is likely in scope for PCI DSS. There is some debate about the “pre-authorization data”, but protecting credit card information applies to all types of information: print, files, databases, fax, email, logs, etc.

Q: What if this fax contains a CVV2?

A: In this case it cannot be stored and must be destroyed. I’d leave the debate about the temporary storage of CVV2 containing media to PCI QSAs and lawyers. PCI DSS states that you cannot store certain types of credit card data, such as CAV2/CVC2/CVV2/CID. Overall, you should also minimize all storage of card data; and this is exactly what card brands recommend (e.g. see Visa’s DropTheData site)

Q: What are the most common ways to steal data from merchants?

A: It is very hard to summarize as reliable statistics are not publicly available. Informally, SQL injection has been a very frequent route to steal such data and so did lack of data encryption on internal networks.

Q: What are the real costs of being not compliant?

A: The reliable cost estimates are not available in the public domain. Overall, the costs are not just in monetary fines, but also in lawsuits, breach disclosure costs, investigation costs, processing rate increases, contractual breach costs, cost of additional security measures, cost of credit monitoring as well as a cost to have a QSA assessment performed (if jacked up to Merchant Level 1 due to a breach)

Q: Is there some type of official timeframe that everyone needs to be compliant?

A: Official PCI DSS compliance deadlines have already passed back in 2006 and 2007. However, card brands such as Visa recently typically set their own dates (example from Visa).

Q: Just to summarize, PCI is about processes and how these processes filter to how actions, processes, security both physical and procedures/audits and networks are setup and managed?

A: That is correct. PCI DSS goes beyond information technology and covers, for example, paper records as well as other ways of storing credit card information. However, your PCI QSA is the authorized source of the information of what PCI should cover in your organization.

Q: What criterion do the ASV follow for the external PCI DSS scanning?

A: Brief answer here. Longer answer is here.

Q: If the deadline for compliance has past, what might be a more relevant question would be when will merchants be completely liable?

A: This is a very dangerous way to think about PCI DSS. This highlights the fact that the person asking the question is only thinking of PCI DSS because of penalties and not because of the requirements to protect credit card data. Please focus on securing the card data, not on “avoiding liability.” Here is some useful reading on the subject.

Q: For a small merchant that only processes a handful of transactions a month, are there alternatives to some of the expensive technology requirements (e.g. application firewalls, independent web/db servers, etc)?

A: Outsourcing credit card transactions is likely the right answer in such circumstances.

Q: Is PCI just a way to avoid paying heavy fines in case of fraud?

A: PCI DSS compliant status will likely not protect you from fines and other costs in case of a data theft. Ultimately, you must protect the data and not just be compliant. If you're compliant, but not secure, and then compromised and fraud is committed, your will probably be liable for losses.

Q: Does PCI only apply to digital data, what about credit card information on print outs?

A: PCI requirements do cover printed data as well. See example in PCI DSS guidance itself.

Finally, thanks again for attending the webcast!

Note: this is posted by a scheduler; I am away from computers for a few days.

Fun Reading on Security and Compliance #14

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 #14, dated May 1th, 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 time I have to clean up a HUGE 2blog backlog :-(

This edition of “Fun Reading on Security and Compliance” is dedicated to all those who only read blogs posts after they’ve been twittered :-(

1. “Disagree with the Concept or Implementation?” from Jeremiah analyzes one of the well-known mysteries in our industry: do you “hate” a certain solution (e.g. WAF, in his case) because it is “designed to never work” (wrong concept) or because it is “never implemented right” (wrong implementation)? Quote: “What’s interesting is the vast majority of the time it’s only the current implementation by particular security vendors that are opposed. We all know many vendors abuse customers with over promising marketing, under delivering products, selling/doing/saying anything for a buck, etc. This reality will never go away, we can only expose the behavior, and this is also very different from saying that the concept behind the solutions shouldn’t exist at all or be offered by someone capable of doing better.” Another gem from the same source is “Quick Wins and Web Application Security” has this in it: “They instead selected Network security, while at the same time curiously agreeing that Application security would have been the better path. His rational was that that it is easier for him to show results to his CEO if he invests in the Network.”
2. RSA is over, and so Gunnar is asking “Where We Are and Where We Are Going.” Key quote: “I am still stunned that any CIO would sanction the purchase of 90% of the products I saw there. Utterly amazing waste of resources to spend so much money on toys and shenanigans just so "security" people can play cops and robbers on the shareholder's dime”
3. “Laws of Vulnerabilities 2.0 Declared” by Qualys: the said truth is people don’t fix vulnerabilities any faster than in 2004 (half-life is still at 30 days)
4. I missed TRISC2009 conference – and it looked like a missed a very fun PCI presentation “PCI PA DSS: Partners Against Credit Card Fraud [PDF]” by Rafael Rosado from PSC.
5. “Top 5 Information Security Annoyances” – yes, both “compliance=security” and “risk modeling” are in.
6. If you can handle, high-caliber cynicism go read “The infosec industry is a fraud”, which is centered around the following point: “The cost of 0wning a corporation is a fraction of a percent of their annual infosec spend.” Good read, even for non-cynics :-)
7. Boaz on OWASP “Security Spending Benchmarks Report” has A LOT of insights.
8. “Security Inevitabilities” from Securosis is something to read and think about. However, I just don’t see this happening “Any critical SCADA network will be pulled off the Internet” unless, of course, the mean “Any critical SCADA network will be CONNECTED TO the Internet” :-)
9. A bunch of interesting data from Dave Shackleford’s informal survey “The Economy Affecting Infosec? Survey Says!” Also check out his brilliant “The Security Hierarchy of Needs.” However, Dave, you suck for not allowing comments to posts! :-)
10. Gunter’s “Ignorance is bliss (in Web application security)” is a good read: “One of my favorite security maxims relates to "Ignorance is bliss" - i.e. the confidence that people have in security is inversely proportional to how much they know about it.”

Special PCI DSS section:

1. “Should InfoSec companies be betting on PCI ?” is not a bad read from SensePost. It is a little pessimistic (“The infosec market isnt going away, but i suspect that the credit-card model we currntly use, will. […] Its like building a company on the Y2k hype. […] The situation is built for check boxes that obey the law but miss its essence.”), but has a few good insights.
2. Fallout from PCI hearing: “Washington And PCI Are A Terrifying Combo”, “PCI Hearing in Congress”, “There’s nothing wrong with the PCI DSS”, “PCI Debate: How Do We Raise the Bar on Security?”, “PCI security rules may require reinforcements” and “An Analysis on the Hearings before the Sub-Committee on Emerging Threats, Cybersecurity, and Science and Techology; "Do the PCI Standards Reduce Cybercrime?" (by far THE deepest, from a Ph.D. in public policy (!))
3. “Heartland Data Breach Update: Now More Than 600 Institutions Impacted” (full list – NOT a fun read)
4. A fun read: “The Great PCI Divide: The Dids And The Never Dids,” just read it :-)
5. “PCI And Schrodinger's Cat”, a fun piece I think I forgot to link to before. This has some discussion of it too.
6. A pile of fun reads from Branden which I forgot to link to before: “Rolling the Dice on PCI”, “BUSTED! Why passing the blame for a PCI Breach will fail” , “PCI Council releases Prioritized Approach for v1.2”, “Sanity DOES Exist!”, “The Problem with PCI” (this has the following quote in comments: “Most in the know (Including myself) are unwilling to come out and publicly state that there are a lot of validations (PCI DSS & PA-DSS) that are complete junk.”), “What SHOULD Keep You Up At Night”, “Companies need PCI++ (not just PCI) to be safe!”, “How a Little Push can put you into a Freefall” and a more recent “An alternative to PCI” (the last piece has a few awesome ideas, BTW!)
7. Dave Taylor’s awesome “How PCI Leaders are Different from Other Merchants” is based on KnowPCI research. An insightful read! Another one from Dave (“PCI’s Grading System Is Failing”) has a good idea about how PCI can be made less “black and white” but still remain compelling (and not diluted by [poor] risk thinking)
8. Mike’s old-ish “There is No Spoon - Compliance in a New World” is another piece I forgot to link to; now justice prevails. Also check his “Ten Commandments of PCI;” my fave is “Thou shalt not covet your neighbors compliance certificate.”
9. “Untangling ‘out of scope’ Vulnerabilities & Compliance Threats“, a good read from Trey Ford. One line summary: you are way more vulnerable than you think (and way less compliant :-()
10. “Compliance doesn’t really matter” by Andy is worth reading as well.
11. Simple and to the point “What Good is PCI?“ has a few good questions and answers on PCI DSS, useful for merchants.
12. Seriously fun read “Six ways you can bork PCI” from an ever-insightful Declan Ingram from Securus Global.

Enjoy!

P.S. The word “fun” has been used 17 times in the above text :-)

P.P.S Now I’ve done it. I cleaned my “2blog” folder.

Note: this is posted by a scheduler; I am away from computers for a few days.

All other “security reading” issues.

Monthly Blog Round-Up – April 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. My PCI DSS hearing coverage in US Congress takes the #1 spot, hand down. Also see (if you can stand it…) , live Twitter coverage here under #pcihearing hashtag.
2. Of course, “Five Reasons to Dislike PCI DSS – And Why They Are WRONG!” is hot. Also check out the longer paper on the same subject “PCI Shrugged”, published in CSO Magazine.
3. This month Verizon breach reports was released and my coverage of it takes the #3 spot: “Breach Report 2009 Day." Again, kudos to the team that made it real!
4. My highlight of Dave’s paper (“MUST Read: ”Who is Minding the Legal Risk around PCI?” by David Navetta“) takes the spot in Top 5 this month.
5. Only then comes Conficker / Confickr, but not the post you’d think :-) It is my April 1st post “100% Protection from Confickr Revealed!”
6. RSA impressions crawled from the back, namely RSA 2009 Impressions, Part I or “PCI DSS is NOT a Pill Against ‘Stupid’”. All other RSA impressions.

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

Note: this is posted by a scheduler; I am away from computers for a few days.

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

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

Technorati Tags: chuvakin,monthly,blog,security

No Blogging - Away For A Few Days

Not telling you where I am going to avoid unnecessary envy :-)

I have scheduled 3 fun posts; please be aware that I will not respond to comments right away.