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”

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:

• Blatant: buy our PCI book NOW!

Proactive and Continuous Compliance? For Real?

At one of the first security conferences I ever attended (probably in 2001 or so), there was this vendor dude who would not stop rambling about continuous compliance. I listened to him and it suddenly dawned on me: what an awesome idea! Running a security-focused, ongoing, multi-regulation program that delivers value to both business units and reduces risk – what’s not to love here?

However, over the years I’ve gotten more cynical on this matter; we all know our beloved security industry does this to people As I said in my infamous “Top PCI DSS Security Marketing Annoyances”, ““Ongoing compliance” theme is awesome. Sadly, a majority of your customers [I was addressing security vendors in that post – A.C.] don’t do it like this (to their own loss – this why it is sad). They still have assessment-time rush, pleasing the assessor approach and checklist-oh-we-are-DONE! mentality. If you want to sell continuous compliance, you need to educate them first!”

Despite such sentiment, I still love the idea of continuous, proactive, cross-regulatory approach to compliance. A mere fact that most organizations don’t do it like this, should not discourage the education efforts to make this more common.

In fact, some recent research indicates that maybe – just maybe – the tide is turning and organizations will start revolting against the “annual assessment rush”, “audit mentality” and “audit done? see ya next year, security!” themes. Even if very weak, there are other indicators that the value of running an ongoing compliance program with technical control assessment automation is growing more popular and newer tools may make it more real. Verizon Breach 2010 report and Verizon PCI report also seem to indicate that compliance programs help security, while annual compliance audits only work to unearth negligence and incompetence. The drive to operationalize PCI DSS controls (example) and to stay compliant (example) also seems to be growing, at least among the larger merchants. One more example comes from the whole FISMA theater – NIST folks now are all about “continuous monitoring” for FISMA compliance (see this FAQ).

In light of this, maybe the times of continuous, [more] automated compliance are upon us? It so happens that I’d be doing a SANS webcast to explore this topic on February 11. Join the conversation as well as a fight for useful and continuous compliance in service of security.

Is continuous compliance a reality at your organization? Are you doing something 9, 6, 3 months before the annual PCI DSS assessment? Do you meet the auditor once a year? Or do you make an effort to stay compliant?

Log Awesomeness – On August 19!

As far as awesomeness is concerned  [and I am a big student of it :-)], this is full of it. BrightTalk Log Management Summit promises to be as awesome as logging events go... Here is an agenda:

WHEN: Thursday, August 19, 2010, attend live online throughout the day or afterward on-demand

HOW: Register Now: http://www.brighttalk.com/r/vbf

TOPICS AND PRESENTERS:

• “Log Standards & Future Trends” by Dr. Anton Chuvakin, Principal, Security Warrior Consulting
• “Leveraging Logs, Information and Events” by Derek Brink, VP & Research Fellow for IT Security, Aberdeen Group
• “Log Visualization in the Cloud” by Raffael Marty, Chief Logger, SecViz.org <– how come they don’t mention Loggly here?
• “The Integration Lifecycle: Loving Long Logging Lifecycles” by Andrew Hay, CISSP, Senior Analyst, Enterprise Security Practice, The 451 Group <- high chance for an awesomeness boost from Andrew!
• “Best Practice and Approaches for Log Management” by Ritesh Singhai, Senior Security Engineer, SecureWorks
• “Delivering Value from SIEM” by Chris Burtenshaw, Information & Technology Risk Manager, Deloitte

Enjoy! And “see” you there on August 19th.

Possibly related posts:

• Brief Log Management Class
• SANS Log Management Class in California?
• FINALLY! SANS SEC434 "The" Log Management Class (2-day version!) in Northern California on Sep 9-10, 2010

Recent SIEM/Log Management Webcast Q&A

A few weeks ago week I did this fun webcast with NitroSecurity (recording) on Log Management and SIEM; here are some belated Q&A we got there:

 

Q1: Is it Security Incident Event Management or Security Information and Event Mgmt?

A1: SIEM stands for Security Information and Event Management. But please shoot whatever market analyst who first mistook ‘information’ for ‘incident’

 

Q2: What is the level of personnel resources are needed to maintain a SIEM?

A2: This is what is known as "one million dollar question” :-) First, it depends on your SIEM “use cases” – essentially on what you plan to accomplish using a SIEM. You can read “SIEM Bloggables” to see some of the high-level usage scenarios. For example, you might acquire and use a SIEM for reviewing compliance reports once a month. In this case, your personnel requirement will probably not exceed a few hours of 1 FTE.  On the other extreme, you might be building a Security Operations Center (SOC) for a global enterprise based on a SIEM. In this case, you might be looking at dozens of people of varying skill levels, from junior analyst to senior SOC managers.

 

Q3: Please explain chain of custody.

A3: Wikipedia’s definition is just fine, see: http://en.wikipedia.org/wiki/Chain_of_custody. In brief: “Chain of custody (CoC) refers to the chronological documentation or paper trail, showing the seizure, custody, control, transfer, analysis, and disposition of evidence, physical or electronic.”

 

Q4: How long does PCI DSS require logs to be kept?

A4: As per PCI DSS v 1.2.1 Requirement 10.7: “Retain audit trail history [A.C. – i.e. logs] for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up).” A typical SIEM or log management tool can hold 90 days of data with up to 1 year available in file backups.

 

Q5: Does adding context/content sources slow the SIEM down?

A5: It depends on the SIEM. Some of the commercial products are slow even without anything being added to them :-) Others can handle extreme event loads. So, the only way to know for sure is to use it in your environment, with your log data and with your context data (assets, vulnerabilities, user roles, etc).

 

BTW, slides similar to those I used at the webinar are posted at Slideshare and embedded below:

Making Log Data Useful: SIEM and Log Management Together

View more presentations from Anton Chuvakin.

Enjoy!

Possibly related posts:

• One More Time on SIEM vs Log Management
• The Myth of SIEM as "An Analyst-in-the-box" or How NOT to Pick a SIEM-II?
• On Choosing SIEM
• Two New Logging Resources Published
• Log Management / SIEM Users: "Minimalist" vs "Analyst"
• IANS 3/25 Log Webcast Q&A
• SIEM Bloggables
• On SIEM Complexity
• All SIEM blog posts.

Two Upcoming Speaking Ops

Just FYI, in the next couple of days I am doing two fun speaking ops.
Namely:

1. Source Boston conference: Branden and me will present on “PCI DSS Done RIGHT and WRONG” (it will be even more fun than PCI Myths, promise!) on Thursday.
2. Focus.com webcast: don’t ask :-), but I will be doing a webcast titled “Zero Day Response: Strategies for the Newest Innovation in Corporate Defense”, primarily focusing on tips to management for improving response to security issues. It will be fairly high-level, so “listener beware.”

BTW, I am posting this after landing here in Boston. If you are around, show up at Source (location) and we can chat.

UPDATE: Focus.com webcast is recorded here

IANS 3/25 Log Webcast Q&A

As you remember, I’ve done this webcast/IPC with IANS called “Navigating the Data Stream without Boiling the Ocean: Case Studies in Effective Log Management.” My role as IANS faculty was to moderate the discussion.

My intro slides can be found here. A recording can be found somewhere here – grab it since we had a great panel discussion with a bunch of useful and juicy bits about log management in the real world. Below I am answering some of the fun questions we got at the show for a broader audience of this blog – and sorry for a delay with that.

Q: What, if anything, has anyone done to overcome privacy restrictions in some countries like Germany, France, Italy regarding log collection activity of users?

A: Sorry, but I have to give you a cynical answer. From what I am hearing, those countries are making a choice in favor of - what they think of as – “privacy” over security monitoring and activity auditing. As a result, many of the logging and log review tasks legality is becoming questionable or the burden of performing such tasks grows exponentially. The only advice I can give is to follow the law - even if you screw yourself and your organization in the process. Under democracy, you're supposed to act towards changing the law and not simply ignoring it.

 

Q: Can you describe your process for determining what to periodically review from your logs?  Did a committee comprised of sysadmin and information security team identify what to review?

A: Ideally, such process should and include all stakeholders, namely, people who can benefit from the information in log files. This would certainly include system administrators and a security team. However, it is not uncommon that the security team will do it on its own if other parties show no interest in participating. Regarding the process itself, the key approach to doing is “use cases.“ What do regulations say about logging and log review? What business units ask for, if anything? What level of details you'd prefer to have during incident response? What are the things I trying to accomplish? Look for future blog posts about this subject.

 

Q: Would you use log management without a SIEM?

A: Absolutely. I would not use a SIEM without log management though; I would also try not to use a SIEM without a good log management tool. For more info on this subject read this, this, this.

 

Q: Does using a complete SIEM solution reduce the number of staff required?

A: Hard to say what is meant by ”complete” here, but the answer is either “no” or “it depends.”

Overall, I do not like this type of positioning at all: if you are trying to purchase a SIEM solution in order to fire your security analysts, you'll fail miserably. On the other hand, if you'd like to reduce the number of people whose jobs consist of only reading logs every day, then SIEM can help reduce that staffing need so that you can allocate people to more productive security monitoring tasks. Still, the main value of a SIEM tool lies in the skilled personnel that operates it! For example, see this one.

 

Q: What is your definition of structured and un-structured data [mentioned in the discussion]?

A: Structured data is more like a database table, it has named fields such as “username”, “source IP”, etc. Name=value pairs is another example of log data with structure. On the other hand, plain English text is not structured [at least, not for our purposes of log analysis] and needs to be either structured (“parsed”, tokenized, etc) or directly analyzed using text mining tools.

 

Q: How visualization tools technically help in log review?

A: See http://secviz.org for more information on the subject than you ever wanted to learn :-) While you're in the subject, get a great book about it.

 

Q:  What level from the log management maturity curve [A.C. - reference to this graph] does HIPAA compliance require?

A: Based on the fact that HIPAA prescribes logging (164.312(b) Audit Controls) and some monitoring for specific events, such as logins (164.308(a)(5)(ii)(C)    Log-in Monitoring), I’d venture a guess that HIPAA compliance will require an organization to have a fairly mature log management and security monitoring operation. And is this reality? No, many healthcare organizations are nowhere near that stage with their logging.

 

Also, see awesome coverage of this webcast from Rocky DeStefano is here at his VisibleRisk blog.

Enjoy!

Possibly related posts:

• Fun Logging Webcasts: 4/1/2010 and 5/12/2010
• Open Group Log Webcast Slidea and Q&A: "Enterprise Logging and Log Management: Hot Topics"
• Thursday 3/25 IANS Webcast + Panel on Log Management: "Awesome++"
• Log Management / SIEM Users: "Minimalist" vs "Analyst"
• The Myth of SIEM as "An Analyst-in-the-box" or How NOT to Pick a SIEM-II?
• Log Management + SIEM = ?
• SIEM Bloggables talks about SIEM use cases.

Security Policy Roundtable Today!

Program:

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

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

Description:

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

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

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.