I designed the scanning solution for one of the ASV's and also handled the process of getting the solution approved as an ASV. All of the PCI Scanning solutions out there are supposed to be programmed to look for pretty much the same thing, and in (almost) exactly the same way. You would think that this would lead to accurate results. You would also think that this would lead to consistent scan results across ASV PCI Scan solutions. Unfortunately, I don't believe that is the case.
'PCI Scans' are not the same as a Vulnerability Assessment
Here are a few examples:
- The PCI Scan finds that port 53 tcp is open inbound to a branch of your restaurant. The PCI Scan doesn't find any known DNS service vulnerabilities so there are "no vulnerabilities detected" and the PCI Scan report shows that the host passed. The results do not raise any questions about this port being open. The tools don't understand the context of the environment. Why in the world would you need to have DNS traffic allowed inbound to a restaurant?
- The PCI Scan checked a few limited ports and concluded that the host is "dead" and therefore the scan service did not perform a vulnerability scan. Your PCI report doesn't show any vulnerabilities, so it's considered compliant. The problem is that the host is not "dead" and has some TCP ports open and could very well be running a vulnerable service on one of those ports.
- The PCI Scan found that port 443 (SSL) is open on a host and reports it as a Level 1 (Informational) finding. The PCI Scan report shows that this host is compliant. The problem is that this is one of your remote locations that uses a UTM (Unified Theat Management) device and has web-based remote management enabled from the Internet without the use of two-factor authentication. This system does not meet the requirements of the PCI DSS.
- The PCI Scan found that port 3389 (RDP) is open on a host and reports it as a Level 1 (Informational) finding. The PCI Scan report shows that this host is compliant. The problem is that this is an Internet-facing host that’s part of the card data environment (CDE) and is setup to allow connections from any source address via Terminal Services without the use of two-factor authentication. This system does not meet the requirements of the PCI DSS.
PCI Scan products can vary greatly in their findings
Earlier this year I did an ASV Scan Vendor Bake-off. I had narrowed it down to two vendors. The test scans were performed against the same hosts and under the same conditions. One report concluded that the scan FAILED and the systems were not compliant. This first report shows these vulnerabilities categorized as: 2 Critical, 1 High, 3 Medium, and 1 Low. The other report concluded that the scan PASSED and that the systems are compliant. According to the report, this scan solution had found 0 Vulnerabilities, and 16 informational comments.
What does this say about the effectiveness and value of PCI Scanning? To me it seems that PCI Scanning today is robotic and inconsistent. And since scan tools don't understand the role or context of a system being scanned, it's my feeling that they should not be trusted as the sole method of assessing vulnerabilities.
Walgreens emailing notice regarding "unauthorized access to an email list of customers" resulting in phishing
December 10, 2010\
Dear Valued Customer, We recently became aware of unauthorized access to an email list of customers who receive special offers and newsletters from us. As a result, it is possible you may have received some spam email messages asking you to go to another site and enter personal data. We are sorry this has taken place and for any inconvenience to you. We want to assure you that the only information that was obtained was your email address. Your prescription information, account and any other personally identifiable information were not at risk because such data is not contained in the email system, and no access was gained to Walgreens consumer data systems. We realize you previously unsubscribed from promotional emails from Walgreens, and that will continue. As a company, we absolutely believe that all customer relationships must be built on trust. That is why we believe it is important to inform you of this incident. Online security experts have reported an increase in attacks on email systems, and therefore we have voluntarily contacted the appropriate authorities and are working with them regarding this incident. We encourage you to continue to be aware of increasingly common email scams that may use your email address to contact you and ask for personal or sensitive information. Always be cautious when opening links or attachments from unsolicited third parties. Also know that Walgreens will not send you emails asking for your credit card number, social security number or other personally identifiable information. So if ever asked for this information, you can be confident it is not from Walgreens. If you have any questions regarding this issue, please contact us at 1-888-980-0963. We take your privacy very seriously, and we will continue to work diligently to protect your personal information. Sincerely, Walgreens Customer Service Team
I am an information security consultant and was a PCI Qualified Security Assessor for a number of years. I work with companies to help them lower their risk when it comes to protecting customer card data and personally identifiable information (PII). I have seen some pretty interesting things, some of which I would rather not share or will not share due to non-disclosure agreements. I will let you surmise what I mean by "interesting".But an important part of the equation is consumer awareness and good practice when it comes to using credit cards, whether online or at retail establishments. Below is my first attempt at a checklist for consumers when using their credit cards to make purchases online. I assume that you are practicing basic safe computing by using a Firewall, Anti-virus, and Anti-Spyware software. There are 18 items and they are not in a specific order of importance.Note: For tips on protecting your payment card information for retail purchases such as restaurants, gas stations, or other retail establishments - see my previous article '15 Steps for Protecting Your Credit Card Information for Retail Purchases'1. Avoid using your email address as your login name. Don’t use your email address as your login ID on web sites that you use your credit card to make purchases from. It’s a common practice now that web sites default to using your email address as the login name. This is for convenience and to help address the problem of users forgetting their login name. The problem is that if your login information is compromised on just one site, it could be assumed that you used not only the same login name (email address) but the same password too. Now all the attacker needs to do is to try this same login name and password on other sites.
2. Delete online accounts you no longer use. Remove your credit card information and your login account from sites you no longer frequent. It will only take a moment and it will reduce your exposure. If the site does not make this easy to do this online, call them or send them a letter with your request.
3. Change your password regularly. And I don’t mean once a year here. A reasonable time frame is probably every few months or even more frequently depending on your online buying habits. If the site does not make it easy to change the password, contact them for assistance on how to do this yourself online.4. Use complex passwords. This goes without saying but I continue to be amazed when performing security audits at how many people use very simple passwords. Consider using passphrases instead of passwords and mix it up with numbers, upper and lower case letters, and other punctuation characters. If a web site doesn’t allow the use of characters other than numbers and letters in the password, complain! This just isn’t good security practice. There are some great password management applications available that will make this easy to manage.5. Don't log in using your SSN or account number. Do not log into sites using your full social security number or account number as the login ID or password. If any sites you use require this, contact them and demand that they change this practice. There is really no reason for this.6. Perform initial web site registration for services that provide online access as a benefit. You likely have credit card, bank, medical, insurance, 401k, and other sites that make online access to your accounts possible as an additional benefit. You may not even be aware that you have online access to your account as a counterpart to your standard account management method. The first time sign-in to some sites may use a portion of your social security number or other personal information as part of the initial sign up confirmation process. If you don’t plan on using such sites, contact the company and request that they disable online access to the account. If you do plan on using the site, perform the initial login as soon as you can and assign a complex password to the account. Also, as mentioned above, avoid using your email address as your login name.7. Read the security and privacy policies of web sites that you use for card transactions. A number of large well known sites clearly stipulate that they are not responsible if your account or data is compromised and that there is no expectation of security or privacy on their part. Most users of these sites are probably not aware of this. Consider the consequences of using such sites.8. SSL doesn’t mean your data is secure or that the company follows best security practices. Don’t trust sites that have a security and privacy statement that simple says “this site is protected with the latest SSL security technology so your information is secure”. This really bugs me to see this as a security statement on a web site. SSL only protects your information in transit between your web browser and their web server during your session. This means nothing when it comes to protecting your information once it is saved to their server, or leaves their server to be processed or stored elsewhere. Read their policy on protecting your information after the transaction.9. Don’t make online card transactions from an untrusted computer. This includes Kiosks, Internet Cafes, or even a friends computer. You just don’t know what might be running in the background capturing your transaction information.10. Use online payment services. Use an online payment service to reduce the number of merchants that have your credit card numbers. These services reduce the possible ‘attack surface’ of your card information by keeping your credit card and identity information with the payment service, not with each of the merchants.11. Don’t ignore warnings from your web browser. They appear for a reason and you should read them. Don’t get in the habit of clicking Ok or Cancel before you know what the warning is about. An error could be a sign of a malicious site redirect, man-in-the-middle, or phishing attack.12. Use additional security features offered by the site. If the site offers additional security features, like those that confirm the authenticity of the site and the user computer, use them. They help ensure that you are connected to the actual site you intended, not a spoofed site.13. Watch for the lock. You’ve probably been reminded of this hundreds of times. But it’s worth mentioning it again. If there is no lock, then the site is not using SSL. If the lock indicator does appear but it looks “broken” or there is a line across it, then there is a problem with the web sites SSL certificate. Click on the lock for more information about the problem.14. Avoid logging in from the main page of web sites. There are some sites that provide login fields on their main web site page which are not initially secure (no lock displayed). This, they claim, is for user convenience. In most cases, the actual login will usually then be carried out encrypted with SSL, but not until you enter your login information and click login. This behavior is inconsistent with the idea of ensuring that the site is secure (you see the lock) before providing your login information. A simple workaround is to click on the login button without providing a login name and password. You will see a login error but you will immediately be redirected to a secure login page where you can login as usual.15. Do not use the ‘remember me’ feature for sites in which you use credit cards. For many sites, this means that they will store a persistent ‘cookie’ on your computer so they will know it’s you the next time you connect to the site. If your system were to be compromised, that ‘cookie’ is all that’s needed to login to your account without a login name and password. Note that this is different than the new feature of some sites that let you 'register' a computer as a system that you normally use to login. Also, after an online card transaction, remember to always click on the “log out” button and then close the browser window.
16. Do not use a debit card for online purchases. Most credit cards provide some form of protection in case fraud were to occur. For example, you are usually not liable for any fraudulent purchases if you notify the card company quickly. But you don't normally get these protections and liability limits if you use one of the many types of debit cards available that can also be used as if they were a credit card. They are not truly a credit card.
17. Check your credit report often. Many victims first learn of fraudulent accounts created on their behalf while reviewing their credit report. One of the tell-tale signs is a new address showing up in your credit report that is obviously not yours. At a minimum, you should be requesting your free credit reports from http://www.annualcreditreport.com/ or by phone at 1-877-322-8228 every 12 months.
18. Check your card statement as soon as it arrives. Many victims first learn that their card has been used fraudulently while reviewing their monthly statement. Be diligent and read it as soon as it arrives. Also, if you don't get your statement around the time it normally arrives, be concerned. Contact the card company to make sure the delay is on their end, and that someone didn't fraudulently change the address on the account.
Contents Copyright (c) 2007, 2008, 2009 Kenneth M. Smith
If you have found this check-list helpful, please let me know. You may forward a link to this post to anyone on any planet. You may reproduce this article as long as the author is credited and a link to this blog (http://post.ksm1th.com) is provided. If you would like to use this article for commercial purposes, please contact me by leaving a comment below.
During my presentation on tokenization at the Boston Application Security Conference I mentioned repeatedly that the application that calls the tokenization process should not have the ability to de-tokenize. This is important because, increasingly, this system is going to be closer to the initial point of data capture. In the case of an e-Commerce site this means closer to the consumer, like a public-facing web application. A publicly accessible web application should not have the ability to directly access a full credit card number after a transaction has occurred. And when I say ‘ability’ I mean that the functionality or code to accomplish this cannot be implemented and no connection to a system that could provide access to a full card number should exist. It is not sufficient to simply limit this type of activity to a privileged user or process running on this system if you truly want to realize the full benefit of tokenization.
I also made the point during my presentation that the applications that your typical internal users have access to should not have the ability to de-tokenize, access decryption keys, or even access the encrypted data. Any of these applications that your internal consumers have access to should only have access to the token value. The intent of tokenizing is to reduce the storage and the use of sensitive data across the organization, therefore reducing the attack surface and liability of protecting that data. If you are limiting the access to the de-tokenizing process that is running on the same system that all of your users have access to then you are completely dependent on this access control configuration. That entire system remains in-scope for the storage of the original sensitive data because this capability exists.
The best way to summarize these points is to think about the tokenization process as “checking in” sensitive data. Remember the Roach Motel ads? In this case, sensitive data checks in – but doesn’t check out (to your standard user or system). For those exceptions to this rule, users that must have access to the sensitive data directly, they should be provided with access to systems and data in a method that is out-of-band and requires strong authentication, authorization, and auditing.
My thoughts? Slow. The touch screen requires quite a bit of pressure to do anything and distorts as soon as you push on it. And did I mention I think it's slow?
This is a “QSL” card which is typically used to confirm that a communication has taken place over Amateur Radio frequencies. I connected to the space station using my home PC (386SX I think), a device called a Terminal Node Controller (a sort-of modem), a Yaesu VHF radio running 45 watts, and an old modified fire department antenna on my roof. The protocol was AX.25 at 1200 baud.
This first image (of the North End in Boston) was taken with the normal iPhone camera application.
As you can see it does improve the image, brightening up the dark (underexposed) areas, while equalizing the bright (overexposed) areas so that you get the detail you are looking for. The HDR process takes two images, so you may see things like the same car in two different places. Something to be aware of.
This is a very basic example of HDR, and the image was created with software that runs on the iPhone. This software only takes two images, one underexposed and one overexposed. Most HDR pro's take at least 3 images. You can do some pretty amazing things with a real camera and some real image editing software or HDR software. For some amazing images, take a look at this Google Search for HDR Images.
It's sometimes very difficult to determine who qualifies as a "Service Provider" according to the payment card companies. Especially when you are talking about complex third-party relationships in which payment card information might be exchanged.
After some in-depth research I did on this topic, and conversations with an acquirer, I put together these two rules of thumb. These have helped me to understand where the card brands are coming from in their determination of service providers.
- If the organization takes orders for a third-party firm and then passes on payment information to that third-party and that third-party uses their own merchant ID to process the transaction, then the organization is probably a 'service provider' according to card brands rules.
- If the organization acts as a repository for payment card information and a third-party obtains this information from the organization in order to process transactions and the third-party uses their own merchant ID, then the organization is probably a 'service provider' according to card brands rules.
These are, of course, rules of thumb and not the actual rules of classification. For formal guidance and requirements for Service Providers, you may find these helpful.Visa: http://usa.visa.com/merchants/risk_management/cisp_service_providers.html
Boston Application Security Conference: OWASP One Day Conference Nov 20 (free) #owasp <~Just Registered
I will be attending this event, thought you might be interested…. KEN
The Boston chapter of OWASP (Open Web Application Security Project) is holding a free, one day informal conference on web application security on Saturday Nov. 20, 2010 at Microsoft New England Research and Development Center, Cambridge, MA. The conference is intended for both people new to web application security and those experienced in web application security. You can find out more at
You can register at http://basc2010.eventbrite.com/
If you would like to submit a paper, see the instructions at http://www.owasp.org/index.php/Boston_Application_Security_Conference_-_Call_For_Papers
There will be 2 tracks: Basic Web Application Security and Advanced / New Research in Web Application Security.
Each track will have 50 minute presentations. There will be a 30 minute keynote. The conference is intended for both people new to web application security and those experienced in web application security.
And registration is now open at http://basc2010.eventbrite.com/
We need people to register so we can judge the food order as well as make sure we do not exceed the allowable room capacity.
A few of the takeaways from the MIT Startup Bootcamp I attended on Saturday September 11 at the Kresge Auditorium. There were all kinds of lessons within the speakers presentations. I’ll write up more on that later. For now these were some of the obvious ones:
Starting a business is easy
Growing a business is hard
Recruit only A-Players, because:
- A-players “recruit” A-players
- B-players hire C-players
- C-players hire D-players
Three things that cause startups to fail (I made these the three F’s to remember them easily)
- Founders ego
- Focus strays
- Funding, lack thereof
The PCI DSS Self Assessment Questionnaire, or SAQ, is supposed to be fairly simple way to report on your organizations compliance with the PCI DSS requirements. For those of us that have been working in PCI for a while, completing an SAQ is a simple task. Comparing an organization to the complete PCI DSS requirements is another thing completely and can be fairly complex. But for people that have not been exposed to PCI, even completing an SAQ accurately can be daunting.
There are a few different types of SAQ, each aimed at a specific organizations based on their total amount of annual transactions. The questions are high level and more basic than those in the full PCI DSS requirements and aim to confirm that the organization is following what’s prescribed in the 12 sections of the full standard without requiring that all organizations perform an audit against the entire PCI DSS requirements.
Having helped many organizations with their security and compliance initiatives, I have seen many SAQ’s that were not completed accurately. There are a lot of bogus SAQ’s floating around out there. Here are some tell-tale signs that your SAQ probably SUQ’s.
- You have no idea what a DMZ is, but you watched someone setup DNS once and figured you must have one. So you answered Yes to the questions in section 1.3
- Your whole encryption key management process is ... a guy. And you figure that since he’s pretty brilliant then you can answer Yes to all the questions in section 3.6
- It took less than a day to complete your SAQ Form D
- The very first time the organization completed an SAQ it scored all Yes’s
- Your SAQ is signed by the person who fixes the printers at your organization
- You answered Yes to everything because your POS vendor told you they are "PCI compliant"
- For all you know OWASP could be a bug spray, but you still answered Yes to the questions in section 6.5
If you don't truly understand the questions then you shouldn't be completing the SAQ yourself. Do yourself, your customers, your company, and the rest of the world a favor. Hire some outside help.
Finally, your organization should be performing a gap assessment using the latest version of the full PCI DSS as your guide, not just the SAQ. The SAQ is really a document for you to attest to compliance. In my next post I’ll talk about how passing the SAQ shouldn't be your goal.