Why vSkimmer Should Not Matter

It was announced this week by McAfee that a new threat to merchants has been discovered called vSkimmer.  This is a very insidious threat as most merchants will likely not know they have been infected until it is too late.

The net of vSkimmer is that it is malware of the highest order built for the explicit purpose of collecting track 2 data from Windows point of sale (POS) systems.  Worse yet, whoever wrote this little gem of software intends to enhance it in 2013 to include the ability to skim EMV cards’ “track” data as well.

vSkimmer can be deployed like Stuxnet through a USB thumb drive, as malware in an email message or on a Web site or any number of ways.  When installed, vSkimmer determines the operating system and version, hostname, active username and various other operational characteristics of the POS system.  It then inventories running tasks and memory to determine where track 2 data is stored and begins recording that data.

vSkimmer works whether the POS system is connected to the Internet or not.  When the POS is connected to the Internet, it transmits the data obtained to a control server using HTTP.  When the POS is not connected to the Internet, the information is stored until someone connects a USB device labeled ‘KARTOXA007’ and copies all the information it obtained onto the USB device.

As usual, the Internet is abuzz regarding how this will be addressed by the PCI DSS.  Sorry to disappoint, but it is already addressed.  Here are some key requirements in the PCI DSS that should mitigate vSkimmer.

• Requirement 1.2.1.a requires that only that network traffic that is necessary is allowed through the firewall.  Merchants should be only allowing connectivity from the POS or card terminal to their processor and nowhere else.  Any traffic attempting to go anywhere else should be flagged and IT alerted to investigate.
• Requirement 5.1 requires that you have anti-virus and anti-malware software installed on POS devices.  Given this is a Windows specific threat and Windows is highly susceptible to being infected, you should have done this already.  While anti-virus solutions are not perfect in always identifying such malware, since McAfee and other anti-virus solution vendors are the ones that found vSkimmer, I would imagine that they all have or will very soon have signatures for vSkimmer.
• Requirement 6.1 requires that systems are patched current.  The problem with patching POS systems is that a lot of vendors issue POS updates for the OS and their application on a quarterly or even annual basis and do not recommend that merchants patch their POS systems directly from Microsoft because of compatibility issues.
• Requirement 10.2 which requires the logging of events.  In the case of a USB device being plugged into the POS system, at a minimum you should see that the portable device enumerator service going active when a USB device is plugged in and if the device is new, you should see system event log entries regarding the loading of device drivers to support the USB device.  None of these actions should be seen in your log data, so if you monitor for these events, you will know that USB devices are potentially being plugged into your POS systems.
• Requirement 10.5.5 requires the use of file integrity monitoring which would catch the installation of vSkimmer as a foreign piece of software even though it masks itself as ‘svchost.exe’.  This would provide a backup control for requirement 5.1 if vSkimmer changes its approach as to its file name and is not caught by the anti-virus solution.

In addition to the PCI requirements, you can do the following to increase your security in regards to vSkimmer.

• Do not allow USB devices to be connected to your POS systems.  Most card terminals are RS232 devices, but USB is becoming more common.  The Windows Group Policy function can be used to disable USB ports on Windows systems.  There are also third party solutions that will disable USB ports.  A lot of these third party solutions can offer additional granularity in what types of USB devices can be connected.  This can be very advantageous when you are using USB card terminals which still need to connect, but other USB devices should not be allowed.  One of my more imaginative clients hot glues the ports shut on their POS systems.
• Train your staff on the vSkimmer threat.  Explain how it works and what they can do to minimize this threat such as not allowing anyone to manipulate the POS systems other than employees responsible for the care and maintenance of the systems.
• Lock your POS systems in a sealed cabinet or cage and only allow the manager on duty to have the key.  This may also involve additional security on POS servers if those are also used by your POS solution.
• Periodically review video of your POS stations to determine if cashiers or other personnel appear to be manipulating the POS system.

If you adopt all of these measures, you will significantly reduce the threat presented by vSkimmer and will likely never encounter it.

2013 Threats To Databases

Akamai just released their third quarter 2012 Internet statistics and are pointing to China as the generator of at least a third of all attacks.  Not only that, the Chinese attackers are going almost exclusively after Microsoft SQL Server.

Then I get on a Webinar with Application Security Inc. and they discuss what they see as the top risks for databases in 2013 and lo and behold, risks align.  It is no wonder that Chinese attackers are focused on SQL Server, not only are targets plentiful, but most of the time, the software was improperly installed.  Application Security Inc. sees the following as the top risks to databases for the coming year.

• SQL injection
• Password attacks
• Improper or ineffective access controls
• Database Java exploits
• Misconfiguration of database security settings

SQL Injection

In our rush to be “first” and to “get applications out the door” we seem to neglect security, privacy, good management practices and everything else.  Management repeatedly says, “we’ll fix it later” or “that is a version 2 enhancement” only to never get back to it or version 2 is a total rewrite with a new set of flaws.

I used to believe that when we found SQL injection that it was the protocol being used that required a certain amount of risk in order for the application to work.  While a few years ago that was true, it now turns out that most SQL injection vulnerabilities are there because it was quicker/easier/faster to do something stupid than to do it securely.  In our “I probably won’t be here in six months anyway” view of employment, it will be someone else’s problem, not theirs so why bother?  The next guy can fix it.

Requirement 6 and, in particular, requirement 6.6 require that applications developed get tested and remediated before they are placed into production.  The operative word here is ‘before’ which seems to be a stumbling block for a lot of organizations.

Application developers point to the requirements in 11 and ask, “How come the network folks get to test after the fact?”  My response is always, “Show me the test network that fully simulates production.”  Do not get me wrong, there is usually infrastructure that provides something similar to production, but once a firewall, router or switch is implemented in production, testing of production changes amounts to making a change and seeing if it works.  That is just the nature of network changes and why they can only be tested after the fact.

In the case of application development, developers usually have at least one, if not a few, development and testing environments that they can use to determine if applications are working properly and that they integrate with other applications.  As a result, applications have the opportunity to be vulnerability scanned and penetration tested before they are moved to production.  If vulnerabilities are found, they can either be remediated or mitigated prior to being moved to production.  That is what the requirements in 6 are all about – making sure that what ends up in production is as secure as possible.

Database Java Exploits

Unbeknownst to a lot of database administrators as well as IT personnel, database vendors now ship their database products with Java.  Java is the attacker’s dream environment because you can develop an exploit in Java and it will run virtually anywhere Java is installed.

Since most IT professionals do not realize Java installs by default with the database management system, Java ends up where it does not belong.  And since they do not realize it is installed, it also never gets patched resulting in a prime target for an attacker.  Better yet, it is a prime target with an ample supply of information.

This is why the server build and hardening standards are in requirement 2 of the PCI DSS.  The idea behind these standards is that they require people to stop blindly installing software without understanding what gets installed.  They also get people to think about what services they actually need from the database versus doing a default installation.

A lot of vulnerabilities with databases would be eliminated if IT departments did some research into database security and set forth installation standards that removed services and features that are never used.  However, in a lot of organizations, unnecessary services and features are installed just in case they are needed sometime in the future.  This approach is typically in response to the “rush” factor that I discussed in the SQL injection section.  The DBA does not want to be the critical point in a new application, so they just install everything and then complain about getting beat up over all of the security issues such an installation creates.

I have grouped the last three risks together as they all relate to one another.

Misconfiguration Of Database Security Settings

In that rush to get the database system up, IT personnel just do the “default” install and move on.  The problem with that approach is that a lot of security settings and features/functions are set at the time of installation and cannot be changed without a reinstall.  As a result, is it any wonder that databases are insecure?

One of the biggest security holes we find is the implementation of open database connectivity (ODBC) on a database.  ODBC has no security capabilities (unless you are talking about the IBM iSeries), so if you have ODBC installed (typically by default), you have essentially installed a backdoor into your databases for anyone on your network.

Again, this is why requirement 2 has all of the build and security standards required.  The idea is that these standards will tell the technicians how to do a correct installation and avoid installing services and features/functions that are insecure or not needed.  That way the database system is secure from the start as opposed to finding out after the fact that one of those just in case services or features are insecure.

Improper Access Controls

One of the most troubling settings people use for SQL Server is mixed mode authentication which allows for both Active Directory and SQL Server to control access to databases.  The first problem we see with mixed mode authentication is people seem to forget the SQL Server managed accounts.  As a result, they typically do not get the account management and review activities they deserve until they are remembered again, possibly years down the road.  These accounts also can get forgotten for monitoring, so if their credentials are compromised, it might not be recognized for a while, if at all.

Even if SQL Server managed user accounts are remembered and monitored, the second problem with mixed mode is that people forget that password change reminders, password complexity and the like are not managed by SQL Server.  As a result, people outside of the DBA arena assume that SQL Server managed user accounts are managed the same as the Active Directory accounts.  And that assumption gets a lot of organizations into trouble when those SQL Server account credentials are compromised.

An access control issue that occurs with all databases is the use of “service accounts” for database access.  Under these scenarios, an application controls access to the information stored in the database by performing the user management functions and access control.  Then to access the database, the application uses a single service account.  Those single accounts are typically configured as administrators and provide unimpaired access to the data stored in the database, making the theft of that information a relatively simple affair if someone gains access to the service account’s credentials.  Some databases have the capability to set up these service accounts so that they cannot be used by anything other than the application.  However, in my experience, this is only done when pointed out during a security assessment.

Another problem with service accounts is that the credentials for those accounts may be stored in a database table, stored in a parameter file (e.g., INI or CFG) or, worse yet, hardcoded in the application.  In the case of when it is stored in the code, the ability to change the service account’s credentials requires an application change.  But the larger question is who has access to the credentials and how are you ensuring that everyone understands their responsibilities to ensure the credentials’ security?

The PCI DSS has requirements in 2 (configuration standards), 7 (access control methods) and 8 (account management) that deal with these issues.

Password Attacks

This all leads to the success of password attacks.  When databases are not properly configured and/or access controls are not properly constructed, then it will be virtually impossible to protect the information in the databases.

The leading reason password attacks are successful is that databases are used to store user credentials.  A lot of e-Commerce solutions use a table in the database to store users’ credentials as well as the credentials for administrators of the e-Commerce environment.  As a result of the other conditions, compromise the database and you have access to the user credentials stored in the credential table.  Worse yet, the encryption keys for passwords are also likely stored in the same database or in a related database that shares administrator credentials with the compromised database.

Given the ease with which SQL injections and other database attacks can be conducted, the fact that most Internet facing databases are used for managing user accounts, the misconfiguration of databases and the improper access controls, is it any wonder that password attacks are so successful?

But the changes required to address this situation are not as easy as people think.  Most pre-packaged Web-based solutions are not engineered to address these credential security issues because that would raise their cost to a point where they are not priced for small and mid-sized merchants who are their target market.  Until this situation is resolved, these solutions will still be at risk.

One would think using Active Directory or another directory service would be an easy solution.  Active Directory and the like are designed to securely store account credentials as long as they are configured and implemented properly.  On the face of it, it would appear that way and it does work for organizations that host their own Web presences.  But for service providers it is not that easy as you realize that each customer’s Web presence would have to have their own branch in the directory’s forest.  Since there are no automated domain provisioning tools for directory applications, the ability to create or remove branches in a forest has to be manually done which would drive up the cost of a site.  As well as the manual process resulting in delays in establishing a site until the directory maintenance is completed which is totally unacceptable in our “have to have/do it now” world.

For the time being we are stuck with our using the database to store credentials.  With that the case, then that database should not be mixed with the other databases and should be on its own, not accessible to the Internet.  The applications that manage the credentials need to be properly engineered so that they are secure as well as efficient.  In addition, the development effort should be reviewed by someone with a security focus so that security and privacy are not left to the very end and then found to be too cumbersome to implement.

What If?

Here is a thought provoking question that was posed to me recently by a former accomplice in the PCI world.

What if PCI DSS assessments were only required until a merchant proved they were PCI compliant or if a merchant had been breached?

The premise behind this idea is simple.  There are going to be merchants that get information security and there are those merchants that are never going to get information security no matter the carrots or sticks employed.  Not that merchants that get information security cannot be breached, but the likelihood is significantly lower than merchants that do not get information security.

Merchants would go through the PCI DSS assessment process, clean up their act and ensure they are compliant and then they would only have to go back through the process if they were breached.  As a best practice, merchants could chose to periodically assess themselves after significant changes to their cardholder data environments to make sure no new security issues had been created or at annual intervals of say three to five years.

In the event that a merchant were breached, the PCI assessment process would be required annually for the next three years or until all of the card brands involved agreed to drop the reporting requirement, whichever comes first.  For Level 1 merchants, they would go through the Report On Compliance (ROC) process performed by a QSA or an ISA.  For all other merchant levels, they could use the appropriate self-assessment questionnaire (SAQ) but that SAQ would have to be reviewed and signed off by a QSA.

For high risk organizations that process, store or transmit large volumes of cardholder data such as processors or service providers that do transaction reporting, statement rendering or other similar services, they would still have to go through the ROC or SAQ D as they do today based on the levels defined by the card brands.

For service providers such as managed security service providers (MSSP) or cloud service providers (CSP), they would be required to go through an annual SAQ D, at a minimum, or a ROC, if they desired, for all services that are required to be PCI compliant.  The ROC would have to be prepared by a QSA or ISA and the SAQ D would have to be reviewed and signed off by a QSA.

As with merchants, if a service provider suffers a breach, all bets are off and they must do a ROC by a QSA or ISA for the next three years or until the card brands tell you to stop.

Visa and MasterCard currently maintain lists of PCI compliant service providers.  Service providers pay to be listed on those lists and the qualifications to get on those lists would also not change.

Regardless of whether an organization is a merchant or service provider, the quarterly external and internal vulnerability scanning and annual external and internal penetration testing requirements would remain the same.  Merchants would be required to file their results with the merchants’ acquiring bank or processor(s).  For service providers, their scanning and penetration testing results would be filed with the relevant card brands.  The scanning and penetration testing just help to keep everyone honest in their efforts to maintain their security.

I have to say, it sounds like a rational process to me if you accept the original premise that organizations will either do what it takes to be secure or will not.  Thoughts?

How To Be PCI Compliant And Still Be Breached

Bashas’ became the most recent example of a merchant claiming to be PCI compliant yet ending up breached.  A lot of naysayers I am sure are running around pointing to the PCI standards and say, “See, they are worthless.”  But the larger question most of you have is, “How can an organization be breached if it is PCI compliant?”

The first piece of the answer is security is not perfect.  Security controls have never, ever totally stopped an incident from happening.  If they were perfect, banks would no longer be robbed.  However, due to the security controls that have been implemented, the success of those robberies has dropped significantly.  This is the fact that the PCI SSC and the card brands seem to miss.  That while their standard is a good starting point, there is much more that has to be done to ensure a reasonable level of security.  And even then, an organization is never 100% secure.

The second part of the answer is that even if an organization is 100% compliant with the PCI DSS, there are still numerous ways to get around the controls and breach data as the Bashas’ breach may eventually point out.  Let us assume for this discussion that Bashas’ statement that they were PCI DSS compliant is accurate.  Then how could they have been breached?

The first clue is the statement that they discovered malware that went undetected for some period of time.  Any organization that believes that their anti-virus/anti-malware solution will address this issue is seriously lying to themselves.  AV is good, but it is also not perfect.  If the AV vendors have never seen the malware you picked up, then they have no signature to match it to, so they will likely not flag it.  This is the first indication that this attack was done by a professional.  The malware was not immediately detected which means the attacker likely developed it themselves from a variety of sources.

But how did the malware get on Bashas’ network?  The answer is social engineering and probably a spear phishing attack.  The attacker likely used PasteBin or similar Web sites, got some Bashas’ email addresses and used those to deliver the malware.  Someone unfortunately clicked on a link, opened an attachment or any other number of infection methods and the deed was done.  This is why security awareness training is so important.  Not that it stops these sorts of attacks, but it significantly reduces the likelihood that they are successful.  However, with the malware in place, now all it took was time to find the data.

But would not Bashas’ have noticed someone probing their network?  That depends on a number of factors, but based on the fact that they became aware of the malware, something eventually triggered an incident.  Unlike the security firm you hire to do vulnerability scanning and penetration testing, professional attackers do not perform their scans as quickly as possible.  They take their time and scan very, very slowly.  As a result, they usually do not generate enough traffic at once to garner an alert.  In addition to that, most of their backdoor software encrypts their external transmissions using SSL/TLS/IPsec over port 80 or 443 which are typically open to the Internet.  As a result, from a monitoring perspective, a lot of what is going on would appear “normal.”

So now that your view of the PCI DSS is dashed.  What should you do to respond?

• Admit that security is not perfect and educate management that it is not perfect.  Breaches will still occur, but security controls are meant to minimize the number of those occurrences and the extent with which they obtain sensitive data.
• If possible, get rid of sensitive data.  In the case of cardholder data, there is no reason a merchant needs to keep it these days, so do not keep it.  If you must keep it, use tokenization so that your systems do not store cardholder data.
• If possible, further isolate your sensitive data.  Look at Forrester’s “Zero Trust” model or the McGladrey Ultra Secure approaches.
• If possible, reduce the number of actual people that can access your cardholder data to as few as possible.  The fewer people that can access cardholder data, the fewer targets that can be social engineered.
• Use a “jump box” to provide access to your cardholder data environment so that you do not allow people direct access.  Couple this with different user credentials to gain access to the cardholder data environment.  Add in full instrumentation of the jump box to capture all activity performed on the jump box and monitor the jump box tightly.
• More tightly monitor your communications through your firewalls.  Yes HTTP/HTTPS needs to be open these days just to do business, but do your personnel need totally unrestricted access to every possible IP address or URL?  No.  So white or black list IP addresses and URLs so that an attacker cannot just use whatever URL or IP address to work from.

Will all of this prevent a breach of your sensitive data?  No.  All these controls will do is reduce the risk of a breach to the lowest possible level.  In time, an ingenious professional attacker will find a way to compromise your controls.  However, with a rigorous control environment it is hoped that you will find them before they find your data.

Bring Your Own Device And PCI Compliance

Bring your own device or BYOD is all the latest rage.  I believe that the reason for that exuberance is the consumerization of technology.  It is that exuberance through BYOD that has made everyone an “IT expert.”  Just ask any user of a smartphone or tablet and they will baffle you with vendor lingo regarding BYOD.  However, regardless of what these people think, there is a big difference from consumer use and enterprise use, the first of which is security.  In this post I am going to look at the minimum PCI DSS requirements BYOD will have to comply in order for your organization to maintain PCI compliance.

From a PCI perspective, requirement 12.3 is very relevant in the BYOD discussion.

“Develop usage policies for critical technologies (for example, remote-access technologies, wireless technologies, removable electronic media, laptops, tablets, personal data/digital assistants (PDAs), e-mail usage and Internet usage) and define proper use of these technologies. “

Under 12.3, there are eight sub-requirements that require:

• Explicit approval by authorized parties.  Just because you have a smartphone or tablet, does not imply you get an automatic pass to connect, you must be approved for that privilege.  In most organizations, that means you need to provide a business need to have such a privilege granted.  While access to email through a smartphone or tablet is one thing, access to cardholder data should be another and be granted very judiciously, if at all.
• Authentication for use of the technology.  If you think you are using a PIN, think again.  You still have to log onto any PCI in-scope system using a password that meets the PCI DSS requirements.  By the way, two-factor authentication is required to access cardholder data remotely, so BYOD does not get you a pass there either.
• A list of all such devices and personnel with access.  For organizations issuing BYOD, this is not a problem.  For organizations allowing any Apple iOS, Android or Windows device to connect is problematic.  While it can be done, you will need to document who was granted access, for what reason/purpose, and what they are using to obtain that access (i.e., make, model, etc.) even if your organization is not providing the devices.
• Labeling of devices to determine owner, contact information and purpose.   I take issue with identifying purpose of the device as that, in my opinion, could just make someone ever more curious as to what is on the device.  However, identifying the owner, giving their general business address and general voice and facsimile telephone numbers for their location is what I would recommend.
• Acceptable uses of the technology.   Email is one thing, doing something that involves cardholder data is another.  I think if companies think this through, there is probably little, if any, reason for BYOD to be even near the cardholder data environment (CDE).  However, if for some bizarre reason you can come up with a valid reason, then all requirements for remote access of cardholder data apply such as personal firewall, no way to disable the firewall, strong passwords, two-factor authentication, encrypted connection, etc.  And remember that these devices have keyboard loggers, so all data input is recorded so keep that fact in mind when designing your information security requirements for BYOD.
• Acceptable network locations for the technologies.  In the case of BYOD, this is anywhere outside of the organization’s network perimeter.
• List of company-approved products.  For those organizations issuing the BYOD, this is not a problem.  For those of you that allow anyone with anything to connect as long as it runs iOS, Android or Windows 8 RT/Pro, your list is going to say “Any iOS, Android or Windows 8 RT/Pro device.”
• Automatic disconnect of sessions for remote-access technologies after a specific period of inactivity.  With BYOD, this can be problematic as most BYOD do not use traditional remote access connectivity and inactivity can all be in the eye of the beholder, so to speak.  As a result, inactivity timeouts can be difficult, if not impossible, to enforce in some instances.  As a result, you may have to be either creative or use a compensating control to comply with this requirement.

Going through the above, I think most organizations would see BYOD for what it is – a fad.  Do not get me wrong, BYOD has its uses in the corporate environment, but they are fairly limited and likely does not include cardholder data.

However, if you have come up with a business justification for processing, storing or transmitting cardholder data using BYOD, there are number of other requirements you are going to have to address.  I know there are other potential requirements that could be involved, but these are the most well known that will need to be complied with under the PCI DSS.

• Requirement 1.4 – Install personal firewall software on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization’s network.   While this can be accomplished by a number of security vendors, it is the enterprise management of those solutions that is currently lacking and the ability to globally enforce policies.
• Requirement 3.4 – Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs).  Most cell phones and tablets do not support device encryption.  As a result, how will you protect any cardholder information stored on the device?  Remember that these devices have keyboard loggers, so any cardholder data input on the device is collected and stored by the device whether you like it or not.  The bottom line is that you will have to restrict BYOD to only those devices that can support whole device encryption.
• Requirement 4.1 – Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks.  You would not think that this would be a significant problem, but it can turn out to be very significant and I will speak about this later on.
• Requirement 8.3 – Incorporate two-factor authentication for remote access (network-level access originating from outside the network) to the network by employees, administrators, and third parties.  This capability is available, but if you are using any of the solutions that run on the BYOD, your users will likely have issues trying to connect and get their token value from that device.
• Requirement 8.5.10 – Require a minimum password length of at least seven characters.  This is likely a deal breaker for users.  Most like their PIN or swipe and will not want to give them up for a seven character, strong password.  In addition, some security solutions may create a situation where the phone cannot be answered without unlocking the device and, a seven character password may cause calls to be missed.
• Requirement 8.5.11 – Use passwords containing both numeric and alphabetic characters.  This can be problematic when some virtual keyboards require flipping between three or more screens to get to certain special characters.  With phones with physical keyboards, there may be limitations to the number of special characters available that could create problems with the password uniqueness requirement in 8.5.12.
• Requirement 8.5.13 – Limit repeated access attempts by locking out the user ID after not more than six attempts.  Some security systems may not be able to enforce this without wiping the device.
• Requirement 8.5.14 – Set the lockout duration to a minimum of 30 minutes or until administrator enables the user ID.  I am not aware of a security solution currently available that can enforce this on a smartphone or tablet.  You will have to meet this with a compensating control.
• Requirement 8.5.15 – If a session has been idle for more than 15 minutes; require the user to re-authenticate to re-activate the terminal or session.  As with 8.5.14, I am not aware of a security solution that can enforce this on a smartphone or tablet.  You will have to meet this with a compensating control.
• Requirement 10.2 – Implement automated audit trails for all system components to reconstruct events.  This is not an issue with Android and may be an issue with Windows 8 RT, but is definitely an issue with Apple iOS.  There is no utility I am aware, outside of forensic utilities, which can meet this requirement in an Apple iOS environment.  In addition, I am not certain how you get this log data back for any sort of analysis without chewing up a tremendous amount of data bandwidth or device memory.  At the end of the day, this will also likely be satisfied by a compensating control, if you can actually come up with enough controls that go above and beyond the PCI requirements.
• Requirement 10.3 – Record audit trail entries for all system components for each event.  If meeting requirement 10.2 is a gymnastic event, then there is the configuration of the log data to ensure that all of the necessary log information is collected.  I am sure that under Android and Windows there is probably some way to ensure that the necessary log data is required.  But with Apple, iOS, Apple will have to be able to provide this capability.  And knowing how stubborn Apple can be about having their hand forced in these matters, getting access to configuration of log data let alone log data will likely be a battle.  Again this will also likely be satisfied by a compensating control, if you can actually come up with enough controls that go above and beyond the PCI requirements.
• Requirement 10.4 – Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time.  For smartphones, they get their time synchronization from the carrier.  However, that time does not likely correlate to the time used by enterprise systems.  It will be close, but not necessarily the same thus complicating any forensic examination if one is required.  This can obviously dealt with in a compensating control.
• Requirement 10.5 – Secure audit trails so they cannot be altered.  Given that users have administrator access on their BYOD; this could be a problem that cannot be easily solved.  Yes, there are security solutions available that can lock down a device, but they can also lock them down so far that users can begin to wonder what the point of having the device is.  As a result, you will find you have a very fine line to tread in this area.

In the end, you start to understand why BYOD is a difficult thing to justify when you need to comply with all of the aforementioned PCI requirements.  But there are a few other considerations that you will still need to address.

The first situation that should concern any organization considering BYOD is the loss of that BYOD.  It is virtually guaranteed that BYOD will result in lost devices and you will need policies, standards and procedures to address that eventuality.  The way most organizations address this issue is providing a remote device wipe capability that can be invoked whenever a device is reported lost.  Not that such capability ensures that every lost device is wiped, but it is better than nothing, but not by much.  This is usually backed up by the bad password entry policy that wipes the device after six incorrectly entered passwords.  So even if the remote wipe does not destroy the data, the bad logon attempts will.

BYOD brings up an information ownership issue as, according to the latest statistics, 70% of all BYOD are owned by the employee, not the organization.  As a result, you are allowing the organization’s information to be processed or stored on a device not owned or necessarily even controlled by the organization.  While you can have an employee sign an agreement regarding the organization’s ownership of the information and the employee’s responsibilities for protecting that information, the issue of enforcement of such an agreement can be very problematic depending on platforms and other technology issues.  You can have a remote wipe capability, but that brings up the potential legal issue of can you also wipe an employee’s personal information such as contacts, music and pictures as well?  Just remember the old saying, “Possession is nine tenths of the law.”  When you finally get through court proceedings, does it really matter if you won when the data has already likely been disseminated?

Then there is the question about whether your applications actually capable of dealing with BYOD?  Most internally facing applications that employees desire access are not engineered for secure, remote access from BYOD.  As a result, a lot of organizations are turning to VPN technology to solve the remote access issue.  However, organizations using VPN are finding out that, while VPN clients are free for download to the BYOD, licensing for the BYOD VPN client is over and above the licensing the organization has already purchased for notebooks.  In addition, depending on the device, running the VPN client can make devices run very slow to the point of being worthless when connected.

When VPN is not a solution a lot of organizations are using remote desktop (RDP), Citrix virtual desktop or similar remote control environments to provide secure access to internal applications.  Having worked with a few of these in a smartphone and tablet environment, I can tell you their use is haphazard at best due primarily to screen size and lack of a mouse and a real keyboard.  In addition, we also find that some of these secure remote desktop solutions are not using secure communication methods.

In addition to VPN and remote control, a lot of organizations are implementing HTTPS for secure connectivity to their applications.  However, this creates all sorts of new security issues related to authentication and protecting the applications which are typically not engineered to be externally facing.  We are finding that in the rush to enable applications for HTTPS, there are numerous security vulnerabilities that are being introduced.  We also see vulnerabilities as well with applications developed specifically for mobile devices.  In the haste to get BYOD up and running, the security vulnerabilities are not corrected before the applications are put into use (a violation of PCI DSS requirement 6.6) which puts the applications and, potentially, the internal networks at significant risk of compromise.

And finally, data input from smartphone and tablets can be highly erroneous not just because of human typing errors but also because of auto-correction systems that are implemented on these devices.  Anyone considering significant data entry through BYOD is just asking for trouble as this erroneous data input could result in legal issues later on due to mis-spellings and mistakes in addresses and other information.

Most executives do not understand the security and privacy issues of BYOD because they have not encountered them and are not aware of them even when time is taken to educate them.  Unfortunately it usually takes an executive losing their BYOD to help management appreciate the issues with BYOD and to slow down the drive to integrate BYOD until their concerns regarding security and privacy are addressed.

As you can see, using BYOD is not as simple a process as your end users might think.  This is even truer when that BYOD will be part of your cardholder data environment (CDE).  There are a number of innovative solutions for BYOD that are secure, but those solutions are expensive and make the BYOD only a display device.  However, if you want to be able to sleep at night, I would highly recommend looking at those purpose built solutions.

How The PCI Standards Will Really Die

Welcome to the new year.  I hope the holidays have been treating you well and the coming year is good as well.

There have been a number of articles written about why and how the PCI compliance process will die.  It is not that I look forward to the PCI standards dying as they have brought a needed visibility to information security and privacy as well as the fact that PCI keeps me gainfully employed.  However if things stay on their current trajectory, the PCI standards will eventually die, but not for the reasons being quoted in today’s articles.  The real killers of the PCI compliance process will be the card brands and the PCI Security Standards Council.  Yes, the very folks that brought us the PCI standards will bring the ultimate demise of their precious set of standards.

The first death knell I see is that it is very easy to issue edicts from on high when you do not have to implement them.  Over the years, clarifications have been issued, quality assurance reviews performed, forensic examinations conducted and a host of other activities have resulted in “enhancements” to how the PCI standards are assessed and enforced.  Do not get me wrong, a lot of what has been done was needed and appreciated.

However, by the same token, some of what has come down has been a nightmare to implement.  Any QSAC not using some sort of automated system to conduct their PCI assessments will find it impossible to meet the current and any future documentation and tracking standards now required by the PCI SSC’s QA process.  Under the current standards, QSACs need to document who they interviewed and what the persons were interviewed about as well as tying documentation and observations to the tests performed.  Without some sort of automated process, these requirements are just too intensive to perform manually.

Documentation received and reviewed needs to have its file name, date of issue and a description of its purpose in the PCI assessment process documented.  The basic PCI DSS has a minimum of around 200 discrete documents that are required for the PCI assessment process.  The average we see for most of our engagements is over 600 documents which also include not only policies, standards and procedures, but configuration files, interview notes and observations such as screen shots, log files and file dumps.  You really have to question any QSAC that tells you they manually manage the process.  They either have an amazing and magically efficient project management process, they have very, very inexpensive staff (i.e., overseas labor) or they are short cutting the processes and producing a work product that does not comply with the PCI SSC QA program and have yet to be assessed by the PCI SSC (the most likely scenario).

Even using simple SharePoint or Lotus Notes solutions are not cheap when you consider the cost of the server(s) and the storage of all of documentation collected, which can be around 5 to 10GB per project, as well as all of the requisite system maintenance.  Servers and storage may be cheap, but it all adds up, the more clients you assess.  And speaking of the storage of documentation, the PCI SSC requires that documentation related to PCI assessments be stored for at least three years.  For those of us with electronic work paper management systems, this is not a problem.  However, given the amount of paper generated by these projects, those QSACs using the traditional paper filing methods will find a lot of shelf space taken up by their PCI engagements if they are truly following the procedures required by the PCI SSC.

All of this drives up the cost of a proper PCI assessment, more than I think the card brands and the PCI SSC are willing to admit.  It is not that I think the card brands and PCI SSC do not care about this situation, but more related to they do not have an understanding of the operational ramifications of their edicts.  The card brands and PCI SSC tread a very fine line here and to this point they have been heavy handed in the issuing of their edicts.  Going forward, the PCI SSC needs to ask the QSACs, Participating Organizations and ASVs to assess the cost and time impacts of these edicts so that they can be weighed against their benefits versus what is done now which is more of a procedural and proofing review.  If this is not done, there will soon come a point where merchants and service providers will push back hard and refuse to go through the process due to the cost and the amount of time involved to be assessed.

The next death knell is the inane process that is called the PCI Report On Compliance (ROC).  When the PCI SSC did not have access to the QSACs’ work papers, the current ROC writing process made some sense as there was no other way for the PCI SSC or the processors and acquiring banks to know if the QSACs had really done the work they were saying they had done.  However, all of that changed a number of years ago when the PCI SSC required QSACs to add a disclaimer to their contracts stating that the PCI SSC had the right to review all work products.  Yet even with this change, we continue to have to write an insanely detailed ROC, typically numbering in a minimum of 300+ pages for even the most basic of ROCs.

Unfortunately, there are QSACs out there that apparently have not been through the PCI SSC QA process and that dreaded of all states – Remediation.  As a result, they have much lower costs because they are not documenting their assessment work as completely as they need to and are not sampling, observing or interviewing like QSACs that have been through the QA process.  In addition, based on some work products we have seen, they also do not care about the quality of the resulting ROC as it looks entirely like a ‘find and replace’ of a template and makes no sense when you read it.  In talking to other large QSACs that have been through the QA process multiple times, the PCI SSC has indicated that they are monitoring the large QSACs more than the little QSACs because there is more risk with the large QSACs.  While true to an extent, we have encountered a number of smaller QSACs that perform assessments for large clients due to their much lower cost structure and their willingness to ‘overlook’ compliance issues.  If the PCI SSC does not go after these QSACs soon, there will likely be a number of breaches that occur due to the QSACs’ lack of diligence in performing their assessments.

I know of a number of QSACs that would like to see Bob Russo and the representatives of the various card brands to actually work as staff on a few PCI assessment engagements so that they can better appreciate the inordinate amount of work involved in generating a ROC.  I think they would be shocked at the amount of work effort they have driven into a process that is already too complicated and prone for error.

As it stands today, the ROC writing, review and proofing process is probably 50% to 60% of a good QSAC’s project costs.  To address this, the PCI SSC QA group tells QSACs to develop one or more templates for writing the ROC which, from what we have seen from some other QSACs, means a lot of mass ‘find and replace’ to speed the ROC writing process.  For the last few years, a number of QSACs have brought the ROC writing process up at the Community Meetings.  However the card brands continue to shoot down any sort of changes to the process.  As a result, the cost of producing a ROC is driven by the size and complexity of the merchants’ or service providers’ cardholder data environment (CDE).  These costs will only continue to rise as long as the PCI SSC does not allow QSACs to mark items as ‘In Place’ with only a check box and rely on the QSAC’s work papers versus the verbosity required now.  If this sort of process can work for financial auditors, it can work here as well.

A third death knell is the PCI SSC and card brands continuing to quote that the majority of breaches are the result of organizations not complying with the PCI DSS.  In discussions with a number of the PCI forensic examination companies, I am hearing that the card brands cannot believe the fact that more and more organizations were PCI compliant at the time of their breach.  The PCI SSC and card brands have apparently convinced themselves that the PCI standards are “perfect” and they cannot imagine that an organization could be breached unless that organization was not complying with the PCI standards.  There is no security standard that I am aware that totally prevent breaches.  So while the PCI standards are good baseline security standards, the card brands and PCI SSC seem to have forgotten that security is not perfect and that any security standard only minimizes the damage done when a breach occurs if the standard is truly followed.

And as organizations have gotten the PCI “religion,” the effort required to compromise them from the outside via traditional attacks has increased significantly.  As a result, successful attackers have changed strategy and work on social engineering their way past the bulk of an organization’s security measures.  The PCI DSS only has a little bit on social engineering in requirement 12.6 regarding security awareness training.  And even those organizations with the most robust of security awareness programs will tell you that, even after extensive security awareness training, human beings are still fallible and that some people still do very questionable things that continue to put organizations at risk, sometimes significant risk.  Even when you have the most diligent of employees, they still make mistakes in judgment from time to time.

Until the human element can be totally removed, there will always be a certain amount of risk that will never go away.  Again, the PCI SSC and card brands seem to not want to acknowledge the failings of the human element and appear to believe that technology is the savior based on the focus of the PCI standards.  However time and again, every security professional has seen very sophisticated security technologies circumvented by human error or just plain apathy towards security (i.e., “it always happens to someone else, not my organization” or “we’re too small to be a target”).

Until the PCI SSC and the card brands drop the “holier than thou” attitude toward the PCI standards and stop the public pillory of organizations that have been breached, there will continue to be editorial commentary regarding the pointlessness of the standards and ever more serious push back to complying with the standards.

These are the reasons why the PCI SSC and the card brands will be the ones that will kill the PCI standards.  At the moment, they are so far removed from the process; they do not understand how complicated and expensive the process has become which is why merchants and service providers are complaining about the ever increasing costs and effort related to the PCI assessment process.

The PCI SSC and card brands also seem to have forgotten that QSACs have to make money doing these assessments and, when you pile on clarifications and edicts that do nothing to streamline and simplify the process; you are only driving the costs of the process higher.  And higher costs only make merchants and service providers, who are on thin margins to being with, even more incentivized to use the much lower cost QSACs, driving the diligent QSACs out of the market, thus increasing the likelihood of breaches.

Again, it is not that I want the PCI standards to go away as I think they have brought a real benefit.  However, if these issues are not addressed, the PCI standards will end up going away.  I fear that, with them gone, there will be no carrot to ensure the security of cardholder information and we will end up back where we were before the PCI standards existed.

The Barnes & Noble Breach Take Aways

On October 24, 2012 it was announced that Barnes & Noble had a credit card breach that was the result of tampered credit card terminals.  As a result of the breach, Barnes & Noble pulled all of the credit card terminals out of their stores so that they can be examined.  The story published in the New York Times has some points that should be interesting to other large merchants.

“We have acted at the direction of the U.S. government and they have specifically told us not to disclose it, and there we have complied.”

This is probably the most important take away you should have because a lot of incident response plans miss this point.  While the credit card companies want to the notified immediately of a breach, law enforcement should be the first outside entity notified and then the card companies, if approved by law enforcement.  The reason is that law enforcement may want the breach to continue in an effort to more easily identify and apprehend the perpetrators and that may include allowing the perpetrators to use the stolen cards for purchases.

But the next question that typically comes up is who in law enforcement should be notified?  If you are not a large or regional entity, then you should notify your local police department or county sheriff.  If you are a regional or large sized merchant in the United States, you should contact the United States Secret Service and/or the Federal Bureau of Investigation.  In either case, whatever law enforcement entity you contact should be consulted with before notifying anyone else outside the organization and that includes notifying the card brands.

“The company determined that only one keypad in each of the 63 stores had been hacked.  Nevertheless, the company has not reinstalled the devices.”

The 63 stores involved were all across the country from San Diego, Miami, Chicago, New York and other locations in between.  This implies either a very organized criminal group that operates in a lot of locations or to a localized group that was able to infiltrate the operation that configures and ships out the terminals for Barnes & Noble.  Based on investigations similar to this, it is most likely that a criminal operation infiltrated a centralized location that is responsible for the configuration, repair and replacement of credit card terminals for Barnes & Noble.

So what can a merchant do to minimize this sort of attack?  Here are some actions to consider.

• Contract with only a reliable terminal supplier.  In this age of lowest cost providers, there is a big temptation to use anyone as a supplier, particularly if their costs are the lowest.  However, the old adage of “you get what you pay for” is very relevant in these situations.  As part of your vendor selection process, you should be asking a supplier of terminals what they do to ensure that terminals do not get tampered with.  If you cannot get an answer or the answer you get is “trust us,” then you should probably not consider them as a vendor.  At a minimum, vendors should put their employees through periodic background checks (at least every three to five years), track which employees work on what units, do random physical internal inspections of units and random testing of units to ensure that they are not tampered with before they are sent out.  If you are doing this activity in-house, you should also be following this process.
• Lock down your terminals.  Anyone that has been into a Barnes & Noble might recall that terminals just sat on the counter.  As a result, they were easy to quickly swap out with a doctored unit.  I have been involved in a number of situations where merchants had terminals doctored because they were easy to swap out.  If terminals are locked in a cradle and only the manager on duty has the key, anyone trying to swap terminals is going to have to have a key to free the device.  This prevents swaps that occur after hours when only the cleaning people are present.  In addition, the keys to these terminal cradles needs to be different for each location so that one key does not open every cradle at every location.  The common key is a lesson the gas station industry has only recently addressed.
• Use tamper-proof serialized security tape or stickers over the seams of the terminal and check them daily.  This is a trick that has been used for quite a while with gas pumps.  The key is to at least daily (I recommend at each manager shift change); have the stickers checked to make sure that they are still in place and log that activity.  If they have been tampered with or are missing, the lane should be immediately taken out of service and your loss prevention unit contacted.
• Confirm a terminal swap.  A lot of merchants are very lax in their terminal swap procedures.  If a terminal turns up with instructions to swap it with another or a technician appears at the location with a new terminal, the store personnel do it, no questions asked.  That is wrong.  At a minimum, a good terminal swap procedure should involve the generation of a trouble ticket in a help desk system or similar and having the store manager confirm the swap with the help desk or POS support.  No ticket, no swap, no exceptions.
• Put video monitoring on all your POS locations.  This does not stop such a swap from occurring, but it does at least record such an event if it does occur.  This is particularly important in situations where the customer also acts as cashier as with any self checkout situation.
• Use MAC address filtering on your store location networks.  If a device is unplugged and a new device is plugged in with a different MAC address it will not work.  Yes, I know for some of you this creates a bad situation.  But I always ask people in response, “Why should store personnel be swapping equipment in the first place?”
• Monitor your sensitive devices.  If a credit card terminal or POS gets unplugged from your network, you should generate an alert.  That alert should then be correlated to a help desk ticket.  If there is no ticket, then someone should immediately notify loss prevention and also follow up with store management to find out why the device was unplugged.
• Monitor your network.  Terminals or POS should only be communicating with your service provider for transaction authorization and your routers(s) and/or firewall(s) should be configured accordingly.  If a terminal or POS attempts to communicate with any other external IP address, that should generate an alert to corporate IT and security that should then be investigated immediately.  This will catch those devices that are tampered with and then transfer data to a server outside of your network.  It is highly likely that the communication will be encrypted, but the traffic will be directed to an external IP address that should be blocked if your firewall(s) or router(s) are configured properly.

UPDATE – October 24, 2012: I am quoted on the Financial Times Web site regarding the B&N breach. http://www.ft.com/intl/cms/s/0/919e3292-1dd7-11e2-8e1d-00144feabdc0.html#axzz2BjZ8C9WJ

UPDATE – November 1, 2012: I got to be a guest blogger on CNBC because of this blog entry. http://www.cnbc.com/id/49624444/How_Retailers_Can_Avoid_a_Credit_Card_Breach

UPDATE – November 5, 2012: I am interviewed by a USA Today reporter. http://www.usatoday.com/story/tech/2012/11/05/debit-card-account-theft-qa/1677537/

UPDATE – November 6, 2012: I am quoted on the front page of USA Today. http://www.usatoday.com/story/tech/personal/2012/11/05/debit-card–numbers-pins-stolen-at-pos-terminals/1675795/

UPDATE – November 8, 2012: I am interviewed on WCCO 830 Radio in Minneapolis.

The Global Payments Breach

We are very early on in this breach from a publicity sense as this is breaking news.  A big thank you to Brian Krebs for bringing this breach out into the sunlight.  However, there are a couple of things that are known that are troubling.

The first troubling statement is Visa and MasterCard stating that,

“the breached credit card processor was compromised between Jan. 21, 2012 and Feb. 25, 2012.”

There are two ways you can interpret this statement; (1) they do not know when the breach actually occurred other than this data range, or (2) for 36 days the attackers were in Global Payments and Global Payments had no idea they had been breached.

Regardless of interpretation, the bottom line is that no one really knows the timeframe of the breach.  That implies that Global Payments’ logging, monitoring and review processes were not performing to PCI DSS requirements.  Had they been working per PCI DSS requirements, I could understand a couple of days of not being able to know if you were breached as Global Payments would have been researching the information.

However, if it is option (2), it really is sad when statistics get confirmed.  This means that for 36 days, Global Payments was unaware that it had been breached.  If you look at my post regarding the latest Verizon Data Breach Report, Verizon states that most breaches are not detected quickly, if at all.

My favorite quote thus far though is from Visa.

“Visa also supports advanced security layers such as encryption, tokenization and dynamic authentication through EMV chip technology to further protect sensitive account information and minimize the impact of data compromises.”

Hello!  This was a processor that was breached Visa.  All of that security mumbo-jumbo you just pushed out there is meaningless once a transaction is at a processor.  The processor has to be able to read the information otherwise they would not be a processor.  This quote is nothing but a whole lot of spin.  It would have been better to have shut up than tried to put spin on this incident.

But the bigger issue that I think the card brands are just figuring out is that when you start shrinking the scope of where cardholder data (CHD) is stored in the systems, you just make those entities that do store CHD a bigger target.  I wrote about this phenomenon twice when I discussed point-to-point encryption (P2PE) and what would happen once merchants stopped storing CHD.  Where we are ultimately headed is with large merchants, service providers, processors, issuers, financial institutions and the card brands left with CHD.  The bottom line is that these organizations that are left storing CHD will have to be on their security “A Game” 24/7/365 in order to avoid being breached.  In addition, the PCI DSS will not be enough; they will have to be practicing security well above what the PCI DSS requires.

And finally, one piece of speculation.  Avivah Litan of Gartner is reporting:

“One interesting twist again sheds light on the fact that knowledge based authentication should not be relied upon.  I heard (and this may not be factual) that the crime was perpetrated by a Central American gang that broke into the company’s system by answering the application’s knowledge based authentication questions correctly.  Looks like the hackers took over an administrative account that was not protected sufficiently.”

I would love to meet the security “rocket scientist” that thought knowledge-based authentication (KVA) was a good idea, particularly for people with the keys to the kingdom.  Want to bet they are a former employee of a KVA solution provider?

All of the recent high profile hacks of public figure email accounts and smartphones were done through KVA using information from LinkedIn, Facebook and the like and you thought it was robust enough for your administrator accounts?  If this proves to be true, I guess we know the answer to that question and we will likely know one update to the PCI DSS.

It will be interesting to see how this breach unfolds in the coming weeks.

UPDATE: Monday, April 2, 2012

News outlets are reporting the fact that Visa has removed Global Payments from Visa’s Global Registry of Service Providers.  This is standard operating procedure for Visa, however, some of the news outlets are writing their stories to appear that Visa has severed their relationship with Global Payments and nothing could be further from the truth.  Unless the forensic examination points to some glaring error such as what was found at Heartland years ago, Visa will only remove Global Payments from the registry.

Now that Global Payments is removed from the registry, they will have to go through the PCI DSS assessment process and re-file their compliance with Visa to be added back to the registry.  It is likely that this will take a bit of time as it is my understanding that the forensic examination is not yet complete.  Until that examination is complete, it will be difficult for Global Payments to address any shortcomings in their operations that they need to correct to be PCI compliant.

The forensic examination could come back with findings that Global Payments was PCI compliant at the time of the breach.  I know a lot of you are questioning how that could be.  Remember, the PCI DSS is only a baseline for security practices, not a “be all to end all” list of security practices.  As a result, Global Payments could have been PCI compliant only to find that certain security measures needed to be at a level higher than what the PCI DSS requires.  This is how changes to the PCI DSS occur.  Attackers up their game and the PCI SSC institutes changes to the PCI DSS to address those changes of the attackers.

UPDATE: Friday, May 4, 2012

News outlets this week are reporting that the Global Payments breach may have started as early as June 2011.  Originally the breach was reported to only be 30 days in duration.  Since the breach was announced, the date the breach began has been slipping further and further back from January 2012, to December 2011 and now to June 2011.  Given the history of this breach, it is likely to slip again.  The only consistent news in all of this is that the number of breached accounts continues to be reported at under 1.5 million.  However, I am concerned that if the date of the initial breach slips again, we may find that the number of accounts may also start to rise.

The other troubling thing, as the date of the breach continues to slide backwards, is the fact that this starts to imply that Global Payments was not as diligent in their monitoring as we thought.  When the breach was initially announced, I took some flack over my implying that fact as there was only a 30 day window of breached data.  However, now that we are hearing that the breach could have been going on for more than six months, I think it is safe to say that monitoring was likely not as good as it should have been.  This would also seem to imply that they likelihood that Global Systems was PCI compliant is probably low.

UPDATE: Friday, May 18, 2012

Talk about a train wreck.  Krebs On Security is reporting that the Global Payments breach started back in January 2011.  Yes, you read that right, 2011, a full year earlier than thought.  It gets better.  Brian Krebs is stating that he has spoken to one of the persons involved in the breach and has some very interesting information about the breach posted as well.  The tally now is around 7M cards have been compromised.  I have been at a client all week and they have a minimum of 100 pre-paid cards that have been affected and they suspect there will be more.

2012 Database Threats

I attended a Webinar recently put on by Application Security Inc. regarding the threats to databases for the coming year.  If you did not attend it, you missed a good session.  But the most disturbing thing brought up was their top 10 list database vulnerabilities and misconfigurations.  Their top 10 list is:

1. Default or weak passwords
2. SQL injection
3. Excessive user and group privileges
4. Unnecessary DBMS features enabled
5. Broken configuration management
6. Buffer overflows
7. Privilege escalation
8. Denial of Service
9. Unpatched RDBMS
10. Unencrypted data

If you look at my post a while back on the 2011 Verizon Business Services’ reasons for why organizations were breached, there is a great correlation between Verizon’s report and what Application Security Inc. is saying.

Their first point about weak or default passwords is very clear and should not need to be discussed.  In this day and age, we should all be ashamed that this is even on the list, let alone the first item on the list.  The bottom line here is that, if you use default or weak passwords, you deserve to be breached.

They brought up and interesting point about SQL injection attacks that a lot of organizations do miss or underestimate and that is the internal SQL injection.  Most organizations are so focused on the external threat that they forget about the threat from the inside.  Worse yet, most security professionals and DBAs are unaware of the threat SQL injection poses even without the Web.  Since most of today’s attacks are perpetrated once past the perimeter, the protection from the inside attack is very relevant and very important.  Because once an attacker is on the inside, it is relatively trivial to use SQL injection or other techniques to obtain data.  More and more organizations are beginning to understand the insider threat and are firewalling all of their database servers away from the general user community as well as minimizing the number of users that have direct SQL access to those servers.

Excessive privileges cannot always be addressed at the DBMS level.  In today’s packaged software world, a lot of the rights are managed and maintained at the application level and that security matrix is maintained in a database table.  The granularity that can be granted is usually where things go awry because the application’s security system only provides an “all or nothing” approach.  Application vendors are getting better with this because of SOX, HIPAA, PCI and the like.  However, organizations typically need to be on the most current releases to have access to such enhanced security granularity.  Unfortunately, there are very few organizations that can afford the most current release or can implement the most current release due to their extensive modifications.  The simplest way to address this issue is the periodic reviews of database privileges and minimizing those users that have excessive privileges.  In the longer term, I expect we’ll see the return of the data dictionary with the addition of user rights and roles that will manage this problem.

Unnecessary features enabled are a vendor and DBA issue.  In some cases, vendors make changing features impossible or near to impossible once the RDBMS is installed.  In some cases, there are physical reasons as to why a feature must be enabled at installation.  However, there are also instances where features could be enabled or even disabled at anytime, but because the vendor only wanted to do that at installation, that is the only time you can deal with the feature.  This results in a lot of DBAs installing the RDBMS with every feature/function available, whether it is needed or not, just in case they might need it later on.  Do not get me wrong as I understand the drivers for this practice.  In today’s “I needed it yesterday” world, it is tough to be responsive when something will require an entire re-install of the RDBMS and migration of existing data in order to get something done.  It is time for IT people as a whole to start explaining to non-IT people that there are just some tasks that take time to do properly no matter how quickly anyone needs them completed.  Our infrastructure has become susceptible to attack in large part because of this rapid response desire.  If we intend to make things secure, we need to stop and think things through before creating even larger issues.

The pervious issue feeds directly into the next; broken configuration management.  Configuration management is broken because the vendors make it virtually impossible not to break it.  And even when configuration and changing configuration is easy and manageable, DBAs are not always as structured as other IT operational disciplines.  As a result, whether talking about the configuration of the RBDMS or the client that loads on the workstation, configurations are too broad because of the “just in case” factor.  I know it is a pain to only enable what needs to be enabled and then six months later have to reinstall everything just for a particular feature, but that is the correct way to do things if you intend to be secure.

Buffer overflows, privilege escalations and denial of service are all common vulnerabilities that organizations will have differing levels of success in mitigating.  I will tackle the easiest to address first, privilege escalation.  If there is any area where security can always be addressed it is with privilege escalation.  The reason privilege escalation exists is because someone, usually a developer, created the issue because they decided to allow users to perform a task that the user should not be allowed to perform.  Because if they were allowed to perform the function, then they would not need their privileges escalated to perform it.  The easiest thing to do is to disable those functions that require privilege escalation.  However, in some cases, that approach will create operational issues that will be unacceptable.  In those cases, monitor the daylights out of things so that you can be sure that the privilege escalation did not result in a different outcome.

In a lot of cases, there can be little done to address a denial of service (DoS) attack short of blocking the offender(s).  Denial of service does not compromise information; it just makes the information stored in the database unavailable.  And for most organizations, that is an important distinction.  If no information has been or can be compromised, then DoS is an annoyance and should be treated as such.  However, some DoS attacks can be used to defeat security measures in the RDBMS by causing the RDBMS to fallback to a basic operational state.  It is in these situations that one has to be careful because information can be lost.  The easy fix is to put a firewall in front of the database and enable DoS attack protections.

Buffer overflows are the most insidious attacks because, in some cases, there is little that can be done to stop them.  A lot of security professionals make the success of buffer overflow attacks sound like they are all the result of sloppy coding practices.  And while there is some truth to that view, the amount of which depends on the skills of your programmers, the success of buffer overflow attacks is also the result of embedding too much flexibility into our applications and leveraging the capabilities of the RDBMS.  In today’s world of open constructs such as SQL and RegEx, we have effectively made everyone a potential database programmer all in the sake of expediency.  Yes, customer service is highly improved, but at what cost?  Web application firewalls can minimize buffer overflows by “learning” how your SQL calls are typically structured, but they are not a complete answer nor do they completely remove the risks.  The way to fix the problem is to reduce functionality and make applications more complicated and difficult to use.  For most organizations that is not an option.  As a result, we must minimize the risks but be willing to accept the risks that remain as a result of our desire for ease of use and flexibility.  Minimizing the risk may mean implementing that Web application firewall internally as well as externally.

While I was glad to see that unpatched RDBMS software low on the top 10 list, I was very disappointed that it was still in the top 10.  One would think with all of the discussions about the importance of patching software, this would not occur in the top 10.  I understand the issues of compatibility and testing that make patching difficult, but really?  Maybe you need to invest in more than one or two instances of the RDBMS.  This is the cost of doing business the correct way.  If you are not doing things the correct way, then do not complain when you have a breach.  So while you saved yourself money on licensing costs on the front end, you likely paid for that cost savings a hundredfold on the back end.

I also understand the issues and fears with encryption.  For a lot of people, encryption is this mystical science that only certain “geeks” practice and practice well.  For others, the problem with encryption is the perceived loss of ready access to their data.  As time goes on, I would say that unencrypted data will rise to the top of the top 10 list.  Why?  Because the information age is all about the control of information.  The more information you control and can use to your advantage, the more power and control.  If your information can be readily obtained through public sources or the lax security surrounding your information systems, then you have little, if any, power or control.  The next 10 years will likely be spent by most organizations figuring out what information is critical to their business model and implementing the necessary protections around that information.  Critical information will be protected like the gold at Fort Know because, to that organization, that is their “gold” and it must be protected accordingly.  And that protection will likely involve encryption for some or all of it.

I know that people have a lot on their plates these days.  However, if you are a security person or a DBA, you need to leverage these surveys to your advantage and address the top 10 issues.  If more companies did this, the less data that would be breached.

When A Breach Is Not A Breach

An interesting but troubling article appeared this past week.  A merchant is suing their processor and acquiring bank over a fine they were assessed for an alleged credit card breach.  What makes this situation troubling is that the merchant had a forensic examination of their systems conducted and the results of that investigation were that there was no breach.  Yet Visa and MasterCard said the merchant was the source of the breach because their analyses of transactions lead them to the merchant and that was enough to invoke fines and penalties.

What should rile merchants is a quote that comes from David Navetta, founding partner of the Information Law Group, who states,

“Most QIRAs (qualified incident response assessors) do not necessarily do a deep-dive forensic assessment.  Rather, they do something more tailored to the task of confirming PCI compliance and validating the existence of a card breach.  Unfortunately for merchants, we have found that some of the assumptions made by QIRAs in this context are often not favorable to the merchant.”

To be fair, there are two issues here.  One is a breach of data and the other is compliance with the PCI standards.  In regards to compliance with the PCI standards, if you were breached, what is the likelihood you were PCI compliant at the time of the breach?  It does not take a rocket scientist to figure that out, let alone some QSA or PFI (PCI Forensic Investigator) coming in after the fact.  In fact, even without any analysis, I would say that your compliance with all of the relevant PCI standards at the time of the breach was probably somewhere between slim and none.

However, this lawsuit points out an even more disconcerting issue with a cardholder data breach.  What Mr. Navetta is pointing out is that any incident investigation initiated by the card brands under the PCI standards is going to focus on PCI compliance and not on whether or not the breach actually occurred.  What a piece of comforting news that should be to merchants.  The card brands know that you were not in compliance with the PCI standards, yet they go through the motions of an “investigation” just for appearances.

But the most troubling thing of all, and the point that should scare all merchants, is the indication that Visa and MasterCard did not even conduct an investigation into the breach and how it occurred.  The article implies that Visa and MasterCard implicated the merchant based on an analysis of the fraudulent transactions.  That transactional analysis led the card brands back to a common point, the merchant that filed suit.  And as the following examples show, the card brands’ all knowing analyses are not always the entire story.

I can tell you from experience with some of our clients that this happens all of the time.  A number of our clients have been involved in these card brand driven “witch hunts.”  The card brands point the finger at a number of merchants because of the fact that the merchants all came into contact with the cards involved.  Unless you have the wherewithal to prove you are not the reason for the fraud, you are the reason the breach occurred.

As an example, back in the ancient times when the Visa CISP ruled the land, we were involved in the forensic examination of a client that is a franchisee of a restaurant chain.  Visa informed them that one of their restaurants was the source of a cardholder data breach.  Their “evidence” was a report that showed their restaurant had come into contact with the cards involved in fraud.  Their attorney asked Visa to explain how this analysis was proof that no other merchant could have been the cause of the breach?  The attorney also asked if any other merchants had also come into contact with the cards in question.  Visa told their attorney that it was proprietary information and that they could not share that information.

Since our client was getting nowhere with Visa, they asked us to conduct a forensic examination of the computers involved to see if a breach had occurred.  While we found a number of improvements in security that should be made, we were not able to find any evidence of the card numbers in question on any of his systems that could have come into contact with the cardholder data.  When presented with this information, Visa replied to our client and their legal counsel that it did not matter as their restaurant was the source of the breach.  In the end, our client paid Visa the equivalent of a third of a year’s profit as their fine to resolve the situation.

As Paul Harvey liked to say, “And now, the rest of the story.”  It turned out our client actually was involved in the data breach, albeit indirectly.  Skip ahead a half a year at the same restaurant.  One day the police walk in and arrest an employee for skimming credit cards.  As the police continued investigating, it turned out there were two more employees that were also skimming cards.  Did Visa apologize or return the “fine” they collected.  Heavens no, our client was still guilty as far as Visa was concerned.

In another case only a couple of years ago, the same situation occurred.  This time our client was a very large Midwestern retailer with a store in the same town where the fraud was occurring.  When approached with the fraud analysis report, the retailer’s legal team ambushed Visa’s representatives and got them to admit that there were four other potential outlets that could also be the source of the breach.  However, in retaliation, Visa implicated our client in the breach through various local media outlets.  The retailer involved us in some due diligence regarding their PCI compliance and other potential issues surrounding the possibility they were the source of the breach.  In the end it turned out that a convenience store in town was the actual source of the breach.  The overnight convenience store clerk had allowed a friend to doctor the ATM in the store to skim cards.  While Visa dropped their “investigation” with our client, they never once apologized for accusing our client of being the source of the breach or the inconvenience they caused with their “investigation.”

The lesson to be learned here is that the card brands are very heavy handed when dealing with a breach.  While I understand their motives for this approach, I also feel it is also very one sided in the favor of the card brands.  I know they are trying to protect their brand names.  But in the end, such heavy handedness will only alienate merchants and, in the end, customers who use their cards to pay for goods and services.

It will be interesting to see how this lawsuit plays out.

UPDATE: Since posting this entry, I have had an opportunity to talk to a number of PFIs about this topic.  While they would not comment on specific investigations, they have all stated that how investigations are conducted has changed significantly.  While the card brands may still only be interested in PCI compliance, the investigations now typically cover everything regarding the breach: how it occurred, who was behind the breach and other relevant investigative topics.  They also told me that they are finding themselves more and more in an adversarial position with the card brands over breaches that were not the fault of the merchant or the result of a merchant’s PCI non-compliance.