Tuesday, May 31, 2011

PCI DSS in Cloud Computing Environments–THE Training

It took many long weeks to create and now it is …. OUT!!! Sign up here now if you are in Bay Area on July 8, 2011. The training is being offered free by the Cloud Security Alliance (well, we ask for $20 to offset the pizza costs) in exchange for your feedback and participation is very limited. I would not be surprised if future production “runs” would cost its attendees 30x-50x of the above “price” since this is a full-day class focused solely on PCI DSS and cloud environments (likely 9AM-4PM with a few breaks).

The initial PCI DSS Cloud  Training Class to be held in Silicon Valley on July 8, 2011, exact location to be determined.

The first ever class dedicated to assessing and implementing PCI DSS controls in cloud computing environments covers how to think of and how to do PCI DSS in various cloud computing environments. Focused primarily on people familiar with PCI DSS, it starts from the “hype-free” cloud computing facts and then delves into key scenarios where PCI DSS and clouds overlap in the real world. You will learn where to look while assessing such environments and what pitfalls and mistakes to avoid. It will also cover the shared responsibility between service providers and merchants in implementing PCI DSS controls. Specifically, we will discuss how PCI DSS Requirement 12.8 applies to various cloud scenarios.

The class would be most useful to PCI DSS QSA, organizations offering PCI DSS consulting as well as merchants planning or implementing PCI compliance.

BTW, in addition to the class materials, I am preparing some “goodies” such as control spreadsheets and implementation tips that should work for various cloud and payment environments. There will be some fun exercises as well!

See you there! I will post updates and maybe even some materials as time progresses.

Thursday, May 26, 2011

Log Management->SIEM Graduation Criteria: Violate at Your Own Peril!

Somebody asked me that question “Do I need SIEM or do I need log management?” yesterday again, and I figured I’d repost this “bit of Anton’s wisdom” (ego alert!Smile), so that people can just read this instead of repeatedly bugging me with this question.

Q: How do I figure out whether I need SIEM or log management?

A: You need log management – if you have computers, IT, data, etc. Period! This is not really a discussion item at all, since about 1986 or so. But do you also need a SIEM? You might think you need it, but you would only be able to benefit from it and satisfy that need if your organization fits the following "graduation criteria from log management to SIEM:”

  1. Response capability: The organization must be ready to respond to alerts soon after they are produced. Incident response process/procedures are a must
  2. Monitoring capability: The organization must have or start to a build security monitoring capability such as a Security Operations Center (SOC), or at least a team/person/resource dedicated to ongoing periodic monitoring.
  3. Tuning and customization capability: The organization must accept responsibility for tuning and customizing the deployed SIEM tool; pure out-of-the-box SIEM deployments rarely succeed.

(originally written for this paper where the above are clarified in more detail)

Possibly related posts:

  • All my posts about SIEM

Thursday, May 19, 2011

On SIEM MQ 2011

As all of you know, Gartner SIEM MQ 2011 is out – you can see it here (or here) without registration. The quadrant mostly matches my recent SIEM project experience.

My observations follow below:

  • CA “SIEM” and “Log Manager” are finally wiped off the face of the Earth (=removed from SIEM MQ), NetIQ is dumped down to the Niche. As they should be.
  • Honestly, Symantec SSIM in Leaders is a mystery to me; must be those invisible non-competitive deals or EU/APAC deals. I’ve not seen them on an enterprise SIEM shortlist in the US for a loooooooong time. The rest of the leaders match my expectations fully (and four of them have been at some point my consulting clients)
  • Splunk is now officially a [sub-par] SIEM, even though it is really not. Is that good or bad? Well, they got their “honorable mention” for the last few years and now they are in the quadrant. BTW, this example shows that you can make A LOT of money by being free and not in any Magic Quadrant!
  • Visionary sector of the MQ galaxy is extremely crowded – but with very different tools, ranging from Prism to Trustwave. Many organizations will choose a tool from this sector, but need to be careful – read the related posts below for some selection ideas and pitfalls.

BTW, congrats to all the vendors who got added this year: AlienVault, Tripwire, splunk and the regional SIEM guys.

As always, apart from insight, the MQ document has a good share of unintentional hilarity, for example:

  • “This company declined to provide any information to Gartner for this research” (Darwin Awards anybody?)
  • “Customer feedback on product function and support is mixed.” (Anton translation: product usually doesn’t work?)
  • “Non-English-language versions of XYZ are not available.” (Anton’s comment: is everything else about the product perfectly perfect?)

Finally, if anybody is wondering, I think the concept of Magic Quadrant (whoever at Gartner came up with) is brilliant. However, many wrong  SIEM purchase decisions I’ve seen made usually stem from the decision maker’s own ignorance and not from whatever document or market visualization he has in his possession. Keep this in mind…

Rocky, your turn! Smile

Possibly related posts:

Wednesday, May 18, 2011

What To Do When Logs Don’t Help: New Whitepaper

Here is a hard problem: you MUST log, but there are no logs to enable. Or, what is no less common, logs are so abysmal that they don’t help – and don’t fit the regulatory mold (example: PCI DSS Requirement 10.2 and 10.3). Or, logs are “out there in the cloud” and you cannot get them, but compliance is here and requires them.

What to do?

The answer to this eternal question is in my new whitepaper that I have written for Observe-IT (observeit-sys.com)

Executive summary:

This paper covers the critical challenges implementing PCI DSS controls and suggests creative solutions for related compliance and security issues. Specifically, the hard problem of security monitoring and log review in cloud, legacy, and custom application environment is discussed in depth. Additionally, clarification of key PCI DSS compensating controls is provided. This paper will help you satisfy the regulatory requirements and improve security of your sensitive and regulated data.

Short version [PDF] (5 pages)

Extended version [PDF] (13 pages)

As usual, the vendor was paying the bill, but thinking and research are all mine (SecurityWarrior Consulting)

Enjoy!

Possibly related posts / past whitepapers:

Tuesday, May 17, 2011

PCI Webcast Q&A

From the webcast I’ve done awhile back, here are some fun Q&A that I volunteered to answer. PCI DSS literati reading this blog, don’t freak out – this is BASIC since the webinar was for Level4 ecommerce merchants.

Q: I have a hosted Card Service Provider, are the SSL tunnel with certificates good enough security?  What PCI say about this?
A:  Well, “SSL tunnel with certificates” is good security (at least compared to no SSL!), but is it enough? Not really. PCI DSS has a long list of other security controls which need to be implemented - for example, if are and e-commerce merchant, web application security is extremely important, likely more so than SSL.

Q: Another crystal ball question. Do you think the day will come when merchants are not permitted to store credit card information in order to be PCI compliant?
A: Well, merchants are not permitted to store CVV data today, merchants are not permitted to store PAN in cleartext and they are strongly discouraged to store PANs at all today (example) – all as per PCI DSS. I do not foresee a complete ban on PAN storage, but these rules might well become stronger.  If

Q: If we are not processing cards at all, but instead are protecting client lists, how much security is needed?
A: The beauty of this question is that it is up to you to determine that risk. There are no regulations to compel you so you have to make your own decisions based on your own research. The answer might vary from “none” (if these are essentially public) to “a lot” if loss of those lists will destroy your business.

Q: What about ACHDirect processing?
A: Not under PCI – all risks are yours, same as above. In recent years, a lot of smaller companies have been attacked by ACH credential stealing malicious software.

Q: The question about 2 or 3 things to secure their system.  Could they not just go to dial up credit terminals?
A: They sure can a net will help protect the card data.

Q: How can a criminal use stolen card data for themselves?
A: Charge cards themselves, resell them in bulk, manufacture cards for resale and use (if Track2 data is available), buy and resell goods, buy software and then pirate it, etc, etc, etc. Think what you’d do if you are given a “free credit card” Smile

Q: Retailer that use MPLS networks have historically not had to encrypt data over a "private" network connection like MPLS.  Do you expect MPLS to require data  encryption and firewalling like you find with networks served by public internet connections?
A: No, this is not a “public” network defined in PCI DSS,  at least to the best of my knowledge. So, while encryption and firewalls are “a good idea”, they are not “the law.”  Requirement 4.1 states that “Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks”

Q: When we went to our website provider to close ports as we said it was not PCI compliant. we were told that because there was no CC data being taken through the  site (it's informational only), it doesn't have to be PCI compliant. Is that true?
A: Not exactly true. Public servers are in scope and must be scanned for vulnerabilities; having less open ports will help you have less vulnerabilities exposed to Internet.  Now, if you don’t accept credit cards at all in your business, then obviously your website is not under PCI DSS.

Q: We have a third party vendor that handles our payments; what tools can we use to audit our vendor?
A: Likely, you're talking not about technical tools, but “legal tools” like SLA, agreements, etc.

Q: To be totally honest, we save the CVV number. This is because is it a huge annoyance to have to call the customer every time we need to charge the card. Is there another solution so we don't have to contact our customers for their CVV number?
A: It is OK to save the CVV if you accept the fact that can never be PCI DSS compliant and will always be in violation of your agreement with your acquiring bank. If I were you, I’d ask you acquiring bank about how to do recurring payments without saving the CVV – it IS possible.

Q: Besides a firewall and web application firewall what other layer of security can be used?
A: Yes, many (if you are under SAQ D) – please read PCI DSS. Examples include log management, configuration management, IDS/IPS, FIM, etc, etc.

Q: What about credit card data stored in QuickBooks?
A: QB does have encryption, do you use it? PANs stored in this application are just like any other stored complete PANs: they need to be encrypted.

Q: What IDS/IPS system would you recommend?
A: Snort is free and is hard NOT to recommend for that reason.

Q: I use PayPal website Pro integrated into my site to process payments. Do I still need a firewall to be PCI DSS compliant?
A: It depends how it is used, but most likely yes (and not just a firewall). Read this for details.

Q: If we use a swipe machine, are we storing data, or is it just transmitted?
A: Depends on the machine, likely just transmitted but older machines are known to store data and should be replaced, whenever possible.

Q: How about some websites/books for learning web security
A: Key web security: OWASP and WASC.

Q: What products/solutions do you recommend for managing logs from different types of applications (e.g., web applications) and systems (e.g., /var/log/*) ?
A: Many tools exist with prices from $0 to (literally) millions, here are some of my favorite free log tools.

Q: How do I know if a website is PCI compliant before I accept credit cards? Should the web host give me a certificate?
A: Ah, good question and you are not the only one to wonder about that. But there's no good answer! Many security seals exist (and some mention PCI DSS scanning on them), but their credibility is frequently called into question.

Q: Why hasn't the term 'passphrase' taken off?  I tell all my users, use a pass phrase, with proper punctuation and spacing.
A: Hard to say, this is a really good way to create long while memorable passwords.

Q: We still transmit our payment card data over telephone lines. Is that less risky?
A: Yes, much less risky. Dial-up terminal makes PCI DSS easier and genuinely reduces the risks to cardholder data

Q: On the Who/What do Hackers Target question, what are the constraints for including the company data?  Are all companies included or only ones that require PCI compliance?
A: All data is potentially under risk – but payment card data (and now ACH credentials) are easier to profit from, if you are a criminal. Many companies use PCI DSS to learn about security and then expand their knowledge to protect other kinds of data, beyond the card numbers.

Enjoy the basics!

Possibly related posts:

Monday, May 09, 2011

How to Replace a SIEM?

Note: this has been written for “Cisco MARS blog” as a guest post and is reposted here for posterity.

Ouch! That “Venus” SIEM  appliance that we got with routers has finally croaked. That piece of PHP brilliance that pre-pre-previous security engineer wrote has been buried under the thick pile of XML. That managed SIEM provider has annoyed us one last time.

What do the above situations have in common? The unfortunate time to replace your SIEM has come. What to expect, apart from copious amounts of pain? This post will shed some light on this conundrum, based on author’s experiences.

First, it goes without saying that it is better to choose the right SIEM the first time (e.g. see “On Choosing SIEM” and other posts mentioned below) than to migrate from a SIEM that has been collecting logs (and dust) for a few years. However, you might not have any say in the matter – you might have inherited it, your “evil boss” might have procured the previous SIEM without asking you or you might have built it yourself after a particularly bad hangover… Also, your organization might have simply outgrown the SIEM or your early generation SIEM vendor has not kept up with innovation in the space. In any case, you have a SIEM and you need a new one.

Let’s look at the good side of the situation:

  • It is very likely that you learned some super-valuable lessons from your previous SIEM experience (other people have to hire consultants to get to those lessons) and now can avoid the common purchasing process pitfalls (some discussed here, BTW)
  • You have much more confidence while discussing confusing SIEM features with vendors – speaking from your previous SIEM experience (this alone will make your new SIEM purchase process much less painful)
  • You have some semblance of the logging policy across the systems that log into SIEM – that puts you ahead of those organizations who are just getting their first SIEM or log management tool
  • It is possible that you built some operational procedures around SIEM (such as for PCI DSS log review or other purposes) and those would be handy for a new SIEM as well
  • If you have to write an RFP (as I discuss here), the chances are that your new RFP would be MUCH better and more likely to result in a good vendor short list
  • Treat this situation as positive, think “I now know more than 90% of people buying a SIEM, thus my new SIEM project will be a success”

A few things to avoid and pay attention to:

  • Suppress that “I’d buy anything but this crap” mentality – think “what problems will a new SIEM solve or solve better?”
  • Avoid taking shortcuts (such as not doing a PoC); you are more knowledgeable, but not prescient…

How might a migration process look like? This assumes that you have already selected a new product, tested it in the lab and are ready for production deployment.

  • Prepare to run both products for some time – this might range from a few weeks to months
  • Draft the new SIEM vendor to help you migrate the data; after all, they are getting the prize Smile
  • Potentially, be prepared to keep the old SIEM running (without paying for the support contract, of course) or at least keep the old data backups – this becomes important if complete data migration is impossible due to architecture differences between the new and old SIEMs.  Ideally, your log management tool will hold raw log backups and so keeping the old SIEM in operation won’t be needed.
  • One of the biggest migration efforts will be migrating SIEM content: reports, rules, views, alerts, etc. As well all know, such content is not really portable across SIEMs and you should be prepared to simply recreate all the custom content AND all the default content that you used in the the old SIEM and that the new SIEM might lack.

By the way, I have seen more than a few organizations start from an open source SIEM or home-grown log management tool, learn all the lessons they can without paying any license fees – and then migrate to a commercial SIEM tool. Their projects are successful  more often than just pure “buy commercial SIEM on day 1” projects and this might be a model to follow (I once called this  “build then buy” approach)

Possibly related posts:

Enhanced by Zemanta

Wednesday, May 04, 2011

NEW (!) Metricon is Coming, RFP Out

The CFP for Metricon 6 is alive, the deadline is June 15. If you think that the previous one [somewhat] sucked, this one will be different, since it will be about…

"Real People Generating Real Information"

This year, Metricon 6 is excited to issue a call for participation to the InfoSec community. Occurring August 9th 2011 colocated with USENIX in San Francisco California. We will be breaking up topics into the following sections, and subsequently would be very interested to review submissions in the following subjects:

• Metrics & Instrumentation
• The Utility of Risk Metrics
• Risk & Cyber Insurance
• Methods for measuring impact
• Incident Management Metrics
• Operational Metrics Beyond Patches, Vulns, & Anti-Virus

THE PROGRAM
--------------------------------

This year's Metricon will be more "convention" than "defend your thesis." Included will be panels, discussions, as well as traditional presentations. We would like to include:

The "Listen" Portion of our Program: Executive use of Metrics

WANTED: Executives to join a panel on the use of Metrics to make decisions:

Metricon 6 is seeking executives excited to discuss metrics they are happy with, unhappy with, or just executives who want to reach out to the security metric community and give us an earful.

We're especially interested in executives who are (or have unsuccessfully tried to) use operational metrics to make business case.

The "Feedback" Portion of our Program: Metrics & Instrumentation

WANTED: Vendors (Product Managers?) who want to talk about their approach to developing the artifacts for their products and services and how they currently or in the future hope to help customers feed an evidence-driven approach to risk management.

In addition, we are looking for security vendors who would like unobstructed feedback to the artifacts and outputs of their current products & services.

For Discussion: Methods for Measuring Impact

WANTED: risk analysts, auditors and anyone else who is estimating and/or tracking the impact of incidents. How do you account for or estimate how much an organization suffers from IT Security incidents.

Speaking of Incidents, For Discussion: The Role of Metrics in an Incident Response Program

WANTED: IR teams and/or executives willing to talk war stories not about incident specifics but looking back, what is the role of metrics in IR (real or hypothetical), what metrics you (may or may not) collect, and why.

For Discussion: Risk & CyberInsurance

WANTED: Do you buy, sell, or have internal hedging practices that could be considered "cyberinsurance?" We're seeking individuals to present on the growing practice of cyberinsurance and it's use as a hedge against security incidents.

For Discussion: Operational Metrics Beyond Patches, Vulns, & Anti-Virus

It's cliche these days to say that most operational metrics programs are of little use beyond "the big three". WANTED: Panelists and presenters for discussions around operational metrics that are not directly the output of vuln. mgmt, patch mgmt, or A/V products.

The Lightening Rounds: New and Unique Approaches

15 minute sessions showing off new research, approaches, data and models.

 

See ya there!!

Monday, May 02, 2011

Monthly Blog Round-Up – April 2011

Blogs are "stateless" and people often pay attention only to what they see today. Thus a lot of useful security reading material gets lost. These monthly round-ups is my way of reminding people about interesting and useful blog content. If you are “too busy to read the blogs,” at least read these.

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

  1. Verizon DBIR 2011 is OUT!” announces the release of the next Verizon Breach Report: awesomeness unleashed Smile
  2. Simple Log Review Checklist Released!” is still one of the most popular posts on my blog. Grab the log review checklist here, if you have not done so already. It is perfect to hand out to junior sysadmins who are just starting up with logs. A related “UPDATED Free Log Management Tools” is also still on top - it is a repost of my free log tools list to the blog.
  3. My PCI DSS log review procedures that I created for a consulting client and posted on the blog (sanitized, of course!) took one of the top spots again: the first post “Complete PCI DSS Log Review Procedures, Part 1” and the whole series “PCI_Log_Review” would be useful to most large organizations under PCI DSS (as well as other regulated organization that are looking to create a structure log review policies, procedures and process)
  4. On Sony PSN Breach and Commenting” is about why I am rejecting many requests to “comment on the Sony PSN breach”: because most of such post-breach comments by outsiders are pure drivel, that rarely even RAISES to the level of FUD.
  5. SIEM Resourcing or How Much the Friggin’ Thing Would REALLY Cost Me?” is a new post about figuring out the costs of your SIEM/SIM/SEM implementation – it became an instant favorite and took the final top5 spot this month.

Also, as a tradition, I am thanking my top 3 referrers this month (those who are people, not organizations). So, thanks a lot to the following people whose blogs sent the most visitors to my blog:

  1. Anonymous “PCI Guru”
  2. Anonymous “SIEM Ninja”
  3. Dmitry Orlov

Also see my past annual “Top Posts” - 2007, 2008, 2009, 2010). Next, see you in May for the next monthly top list.

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

Dr Anton Chuvakin