What To Focus On In 2013

It is the end of the year and, like all other pundits, here is another idea on what 2013 will bring in the way of security issues.  After reading a lot of the other predictions out there, I tend to agree with those from Verizon Business Services’ Data Breach Investigation Report researchers.  While everyone else is predicting cyber-Armageddon as the biggest threat, the researchers at Verizon Business Services see a lot more of the same for 2013.

The biggest threat Verizon identifies is more attacks on authentication systems.  This is most likely because your vendor or your developers talked you into storing authentication information in your database that is Internet facing.  We see this all of the time with eCommerce and Internet banking solutions.  The external user credentials end up being stored in the database along with order entry, inventory and pricing data.  This is typically done because using a directory system for such purposes is difficult and, at times, not as functional as when authentication data is stored in and used from a database.  Given the prevalence of SQL attacks, all of that information results in being available for the taking through a SQL injection attack.  As a result, the attackers compromise the authentication system, gain access to everyone’s credentials, including administrators, and it is likely ‘game over’ regarding the rest of your security measures.

I want to touch next on social engineering because it is typically directly related to compromising authentication systems even though the second place attack method most concerning Verizon researchers is application attacks.  Social engineering is all about tricking your end users into giving up key information so that an attacker can compromise your environment.  The most common piece of information an attacker tries to obtain is an end user’s credentials for logging onto the network.  Hence the reason why I wanted to discuss this after the authentication system attacks.  Social engineering is the most insidious of attack methods because it does not involve any of an organization’s security technology.  And worst of all, if social engineering is successful, all or most of your organization’s security technology is effectively neutralized as a result.  That is because most organizations have little or no security once someone is on the inside.

Now let us look at the second most concerning attack to Verizon which is application attacks.  Verizon is saying that application attacks are more of a threat to governments and large applications.  Regardless of the target, any organization with an application presence on the Internet is a potential target such as with eCommerce or Internet banking.  A lot of these applications are based on on-line frameworks such as IBM’s Websphere or Oracle’s Application Framework.  It is not that these frameworks are insecure, it is that they still require development effort and it is those custom development efforts that do not guarantee a secure application.  The problem comes from the fact that a lot of people believe that using a framework means that little to no security testing even though the amount of custom development done in these frameworks can be more extensive than starting from scratch.  As a result, we see a lot of organizations tossing Internet applications into production with little or no security testing and then ending up with breaches as a result.

In addition, there are third party applications served up by application service providers (ASP).  A lot of small and mid-sized businesses (SMB) use these sorts of applications to have an online presence.  As a result, a lot of SMBs believe that these solutions do not require any security testing because the vendor and the ASP do that for them.  However, we are encountering more and more attacks on SMBs, particularly those that have wealthy clientele such as country clubs and exclusive financial institutions because their applications are notorious for not being secure.  SMBs are constantly amazed that; (1) they were targeted and, (2) the application was not bettered secured.  Yet attackers know that while the take out of SMBs could be significantly less than a large organization, an SMB is usually easier to compromise because they do not have the security and monitoring resources of a large organization.  As a result, SMBs are becoming a larger and larger target for attackers.

Finally, something that concerns me as the previously discussed threats is mobile devices and devices not under the organization’s control, also known as ‘bring your own device’ or BYOD.  I think these devices will surpass the other three threats over the next few years because most organizations have difficulty maintaining security on their servers, desktops and notebooks, let alone something like an iPhone or an Android tablet.  The worst thing about mobile devices is that they are so easily lost and it fascinates me how many people lose their mobile devices.  The bottom line about mobile devices and BYOD is that you must be very, very careful as to what you allow these devices to access and how you grant that access.  And you must make sure that these devices are not allowed to download information, even if encrypted, as that information is highly likely to be lost.

So what should you be doing regarding these threats?  Here are my top things organizations should be doing to minimize the risks presented by these threats.

• Trust no one.  This is particularly true of mobile devices or BYODs, but it also applies to your own internal systems.  Forrester has promoted this in their ‘Zero Trust Model’ as well as me in the ‘Fort Knox Approach’.  This is not as easy as one might think, but the approach makes sense in these days of attacks on authentication systems and social engineering approaches.
• Classify your data.  This is usually a difficult project, but they pay dividends at the end because everyone understands why certain information cannot be allowed out of the control of the organization.  It also allows people to justify to others why data cannot be allowed to be accessed by people that do not need access as well as via mobile or BYOD.
• Require encryption on mobile devices and BYOD.  Even if you do not allow data to end up on these devices, you do not even want the memory or other information that might be inadvertently stored on these devices out of your control.  As a result, if you encrypt these devices, there is a high likelihood that, if they are lost, the person finding them will just wipe them and start over.
• When possible, use a directory system for authentication.  This is always painful for systems that operate outside of the traditional control environment of internal users.  Directory systems are usually designed to be more secure than any sort of database authentication system because they are assumed to be at risk from the start.  However, just because they are designed to be secure does not mean they cannot be implemented in an insecure manner.  Windows Active Directory takes a lot of heat for being insecure; however a lot of that heat is due to silly implementations to support insecure authentication methods for compatibility.
• Conduct security awareness training.  The only thing that minimizes social engineering is consistent and regular security awareness training.  However, do not kid yourself or management.  Everyone has their ‘moments’ and does something they should not.  That said there are always those that just never seem to get it which is why you need other controls and monitoring to ensure you maintain your security.  However, to just throw up your hands and say it is pointless is also not a position to take.
• Secure your applications.  This means conducting application code reviews and testing applications before they are put into production not after the fact.  Unlike networks where you need to put them into production before testing them, applications can be tested before going into production.  It amazes me how many organizations put their applications into production and, by the time they finally get around to testing them, they have already been compromised.  And while automated application code testing solutions are all of the rage, we still find that the best results come from the more traditional human code review not automated tools.
• Monitor your network and applications.  This is a double edge sword.  You know what to look for, however, you have so many ports open that it is near to impossible to recognize bad traffic from good traffic.  And it is not necessarily the fault of your IT department as most packaged applications require an inordinate amount of ports open to function properly.  However, the key thing to monitor, more than anything, is any traffic going outside of your network to an unknown location.  When you see traffic going to Eastern Europe, China or any unexpected IP address, your monitoring system should generate an alert as that is typically a key indicator that you have been compromised.

Have a happy holiday season and I will “see” you all next year.

Merchant Beware – New Mobile Payment Solution Out In The Wild

Merchants need to be aware of a new mobile payment solution – Square from Square Inc.  A colleague pointed me to the Square site with the question, “Is this PCI compliant?”

Square appears to be a hardware/software solution for iPhones, iPads and Android devices.  It has a cute, square magnetic stripe reader for swiping cards, but also appears to provide the capability to manually enter cardholder data through these devices’ virtual keyboards.  This all appears to be similar to the iPhone that used to appear in the first Apple iPhone commercials that, for reasons that will become obvious, magically disappeared from their commercials very quickly and quietly.  It is also why Apple no longer uses iPhones or iPod Touches in their stores to process payments.

In referencing the PCI SSC’s PTS certification database, I could not find Square’s certification for the PTS standard.  Although, given the pictures on Square’s Web site, I really did not expect to find it certified to the PTS standard as there is no way it could meet the PTS standard.  Has Square submitted their solution for PTS certification?  It may have, but since the PCI SSC PTS certification database only lists those devices that have completed the certification process, there is no way for anyone to know if it has submitted Square until it is certified.  However, since the use of PTS certified devices is a requirement of all of the card brands, until Square is PTS certified, use of a Square device for processing of credit cards violates a merchant’s merchant agreement.  Game over.

While not complying with the PTS standard is a deal breaker in my opinion that is not the only PCI compliance issue.  In referencing the PCI SSC’s PA-DSS certification database, I could also not find the Square software application listed.  That situation was also not unexpected as the PCI SSC announced in a press release on June 24, 2011 that it was suspending the PA-DSS certification review of all mobile payment applications indefinitely.  As a result, there is no way Square’s software will be PA-DSS certified for the foreseeable future whether they submitted it for PA-DSS certification or not.  Not that the PA-DSS certification is a deal breaker for merchants to use the Square software, but it means that merchants using the Square software to process payments will have to have the Square software assessed to ensure it meets all of the PCI DSS requirements regarding payment applications.

And knowing what I know about all of these devices, I can guarantee that the Square software will not be PCI DSS compliant because all of these devices will store the cardholder data unencrypted for an untold amount of time until it is written over.  Even if Square’s software encrypts the data, the underlying OS will also collect the data in cleartext.  Forensic examinations of these devices have shown time and again that regardless of what the software vendor did, the data still existed in memory unencrypted.  And that unencrypted data in memory can exist in these devices for days, weeks to even months depending on transaction volume and other applications loaded on the device.  It is this surreptitious OS data collection activity, the security issues with other applications as well as other security concerns that caused the PCI SSC to suspend their PA-DSS certification activities of these applications.

There is only one solution that uses an iPhone or iPod Touch that is PTS and PA-DSS certified at this time and it is from Verifone.  The reason that Verifone’s PAYware solution is certified is that: (1) Verifone submitted it for the PCI certifications prior to the June 24 suspension and, the bigger reason in my book; (2) it relies on a digital back separate from the iPhone/iPod that performs the card swipe and all of the card data processing/transmission in a secure manner.  The iPhone or iPod Touch are used only as a display and cellular/Wi-Fi conduit for network connectivity.

The only other mobile payment solutions I am aware that are PTS compliant are purpose built credit card terminal using Wi-Fi or cellular communications.  These are considered terminals by the PCI SSC, so their underlying software is not required to be PA-DSS certified at this time, but they are required to be PTS certified.  In addition, these terminals have been in use in Europe for quite some time, so they are a proven secure solution.

The bottom line is that it is the merchant’s responsibility to ask vendors the right questions and weed out non-PCI compliant solutions.  The card brands and the PCI SSC are not in the business of regulating vendors, they leave that to the marketplace.

If you are looking for a PCI compliant mobile payment solution, talk to Verifone, Equinox, Ingenico or other recognized card terminal manufacturers as those are going to be your only PCI certified mobile payment processing options at this time.

UPDATE: I have had a number of people contact me about the certification status of the Square solution based on the fact that Square Inc. is listed on Visa USA’s Web site as a PCI DSS compliant service provider.  Remember, this listing only means that the card processing services provided by Square Inc. to their customers (i.e., all of the back office processing they do to process card transactions) are PCI DSS compliant, not that the devices that actually conduct the card swipe are certified PCI compliant.  A certified card terminal would be PCI PTS certified and the software running on the terminal would be PA-DSS certified.  The Square Inc. device that connects to iPhones and Android devices does not have that PCI PTS or PA-DSS certifications, therefore it should not be used for conducting credit card transactions.

UPDATE: Here is another solution that avoids the iPad altogether, Hubworks Interactive.  I spoke with them and their QSA and this product avoids the iPad by conducting the transaction in the digital framework surrounding the iPad.  The iPad is strictly used as a display and a Wi-Fi conduit.  The digital framework encrypts the cardholder data before it is ever seen by the iPad just as Mark Bower suggested would work.

UPDATE: July 25, 2012 – In the July issue of Transaction Trends, page 6, there is an announcement from Square that they are offering a new loyalty program for merchants using Square Register and Pay. Let us hope it is securely implemented as I am sure Square is using a customer’s PAN for tracking based on how they describe the program.

UPDATE: August 30, 2012 – The Square Web site is now implying that the transmission of card data is secured through “industry-standard encryption,” whatever that means.  There have been rumors that Square has implemented point-to-point encryption (P2PE) in their card readers but was not advertising that fact.  That is why I went to this page to see what, if anything, had changed.  However, based on the statements on this page, it appears that P2PE has not been implemented as you would think they would be touting that fact.

UPDATE: October 15, 2012 – A good friend of mine just started working at Square, so hopefully we can get to the bottom of how Square works and what risk there is to merchants using their solution.  Stay tuned.

End-To-End Encryption – The Rest Of The Story

Step right up folks.  I have something that will cure all of your problems with credit card processing.  It is called end-to-end encryption.  Yes, folks, it is the be all, to end all in security.  It will cure all that ails you, particularly those nasty data breaches.  Don’t be shy, just step right up and get your own version while supplies last.

Gee, when end-to-end encryption (E2EE) is put that way, it sounds great, almost too good to be true.  And you would be right; it is too good to be true.  But if you listen to the statements of the proponents of E2EE, they make it sound like once E2EE is in place, it is like the Ronco Showtime Oven, “Just set it and forget it.”

Now, do not get me wrong.  E2EE is not a bad thing, but it does have its own set of risks.  And it is those risks that do not get discussed that concern me.  The reason for my concern is that if you discuss E2EE with any merchant, most see it as this panacea, something that will get them out of the PCI compliance game altogether.  However, nothing could be further from the truth.  If anything, E2EE may make PCI compliance even more daunting than it is today.

The first thing everyone seems to forget is that E2EE only removes those systems and networks that are between the endpoints.  That is because the data stream between the endpoints is encrypted and, therefore, out of scope for PCI compliance.  However, for a merchant, that means that the device that accepts the credit card is still in-scope for PCI compliance.  Bring this fact up to most merchants and they start complaining like no tomorrow.

That device might be as “simple” as a credit card terminal or as complex as an integrated point-of-sale (POS) workstation on a network.  However, since this device is an endpoint, the merchant or the merchant’s QSA needs to ensure that the endpoint is properly secured and cannot end up being a breach point.  Depending on the complexity of that device, that assessment might be very straight forward or very time consuming.  The reason the endpoint needs to be assessed is that security is only as good as its weakest link.  In the case of E2EE, the weakest links are the endpoints at which the data is encrypted and decrypted.

The next thing that seems to slip people’s mind is that fact that since the merchant has an endpoint, that endpoint is still a target.  Worse yet, because it is an endpoint, the level of sophistication likely required to compromise that endpoint goes up exponentially, meaning that any successful attack will likely be beyond the average merchant’s capability to readily detect.  The PCI DSS addresses this threat fairly well by requiring network monitoring, daily log reviews, anti-virus, anti-malware, firewalls and the like.  However, I can tell you from personal experience that your average merchant is not going to be equipped to deal with this new threat.

And what is the new threat?  The new threat is tampered with hardware and software.  If you think this is farfetched, think again.  It has already happened on a limited scale.  The doctoring of hardware is fairly straight forward to both accomplish and to detect.  Detection only takes looking inside the device and noticing something that does not belong.  However, doctored software is another story.  The concept of doctored software has been a concern in the health care industry since the start of using computerization for heart pacemakers.  While the health care industry has developed rigorous testing and certification procedures, the rest of the software industry has said there is no need.  That is, until now.  As the world further automates, the need for reliable, safe and secure software only increases because of the reliance people and organizations apply to that software.

So what can an organization do to stem this new threat after implementing E2EE?  Here are some thoughts.

• Purchase your credit card processing equipment only from your acquiring bank or reputable vendor.  This is not a perfect solution to the problem, but doing this should be better than buying a used unit off of eBay or from Joe’s Guaranteed Card Equipment.  Yes, you may save a few bucks, but is that worth having every one of your customers that uses a credit card being compromised?  Probably not.

• Ask your supplier of terminals or POS workstations about what they do to test these systems to ensure that they operate as expected and are not routing cardholder data to Timbuktu as well as your bank.  Ask them to provide those procedures in writing and review them to ensure they appear adequate.
• Use serialized tamperproof tape on the seams and doors of your terminals and POS workstations.  Require that at every Manager shift change the new manager on duty is required to log their review of the devices, inventory the devices and notate if any have been tampered with.  If a device does appear to have been tampered with, it should be taken out of service until a new, secure device can replace it.
• If using self-checkout systems, make sure to have those systems under both video and employee monitoring.
• Upgrade your card processing devices to the latest devices.  Over the last few years, some of these devices have seen significant changes in their design that improves their tamper resistance.  This is particularly true of fuel pumps and certain types of terminals.
• Review video monitoring if any manager notates that a device may have been tampered with to determine if you can identify possible suspects that may have tampered with the device.
• Patch your devices as soon as possible to minimize their susceptibility to attack or compromise.
• If the vendor of the equipment will perform updates, make sure that you or someone in your organization schedules the updates.  If anyone shows up at a location to “update” your equipment and it was not scheduled by your organization, contact law enforcement.
• If updates will be done by the vendor remotely, make sure that someone from your organization initiates the remote access and they observe the remote update process.  At the end of the update process, the person should terminate the remote session of the vendor.

Even implementing these processes will not remove all of the risk.  Particularly the risk of having modified software introduced into your environment.  However, these processes will show a court that you attempted to conduct due diligence and tried to keep your equipment secure.

The Reinvigoration Of Social Engineering

Social engineering did not go away, but it seems to have taken a backseat to other attack techniques over the last few years.  With the publication of the results of the social engineering contest at Defcon this year, the participants in the contest have shown that social engineering is still alive and well and a very successful attack technique.  The following quote from the report on the contest says it all.

“Targeting people has become the most cost efficient attack vector in many situations, and all indications point to this trend continuing to increase.”

Social engineering is one of the most insidious attack techniques around.  Unfortunately, organizations do little to address social engineering and have only made social engineering easier over the years.  Customer service methodologies and training over the last 30+ years have done a great disservice to organizations.  For example, organizations trip all over themselves to be the JD Power customer service leader.  Employees are assessed on their ability to solve a problem on the first customer contact.  Yet in my experience, these sorts of activities typically focus organizations on blindly providing customer service at the expense of the organization’s security.

The organizers of the contest defined 32 objectives or flags that contestants could obtain over a 25 minute call to the target.  These flags were assigned point values based on the perceived difficulty in obtaining them.  While the flags were not considered to be highly sensitive information, the flags were such that one as to wonder if even more sensitive information would have easily been obtained had the contestants been allowed to go after it.

Prior to the contest, contestants were required to develop dossiers and attack scenarios on their targets that were also graded and given a value that became part of their score.  In the 25 minutes, contestants could call their target once or multiple times.

The statistics gathered as a result of the contest bear out the effectiveness of social engineering.  Of the 15 organizations targeted, 14 of them did give up at least one flag.  More troubling is the fact that if a contestant encountered difficulty in obtaining information all it took to get the information was to hang up and call back and get a different employee.

Another area that provides concern is the amount of information the contestants were able to obtain through their dossier development.  The use of Google, Google Earth and Google StreetView provided an amazing amount of information for the contestants.  Also used were social media sites such as Facebook, MySpace and LinkedIn.  While Facebook, MySpace and similar sites have garnered the most attention by the media, it was LinkedIn that provided the most information, in a few cases providing the contestants with the ability to develop an organization chart for the target.

Security is only as good as the weakest link.  As this contest points out, an organization’s weakest link is probably their employees – the likely cause of which is a lack of or only cursory focus on security awareness.  The contest just magnifies the fact that organizations have done little or nothing to protect their organizations from information leakage by employees.  As I constantly like to remind everyone, security is not perfect.  While you may have a fairly good security awareness program, you are still at risk from social engineering.  As PT Barnum liked to say, “There’s a sucker born every minute.”  Humans are fallible and as much as we try, everyone has their moments, but some people have a lot more moments than others.

If you think this is all just a nice exercise and it really does not present a strong enough threat, then go back over the last six months and read all of the news clippings about data breaches and other exploits.  The majority of these attacks are all social engineering based or had a very strong social engineering component.

I highly recommend that you visit the Social-Engineer.org Web site and obtain a copy of their report.  Share the report with your executives, particularly the leader of your customer service area.  Hopefully they will get a clue regarding the amount of information that is inadvertently leaving your organization.

Twelve Character Long Passwords

This past week researchers from Georgia Tech released a paper saying that the days of eight character long passwords is over and that twelve character long passwords had arrived. The researchers based their efforts on the use of the latest graphics cards that have the computing power of a supercomputer, have software development kits and can be programmed in C.  However, the telling quote about their research came from the CNN Web site which stated, “The researchers used clusters of graphics cards to crack eight-character passwords in less than two hours.”

The first thing I thought of was, “What kind of system administrator lets a brute force attack on a single account run for two hours?”  The answer was no one, not even stupid ones allow that to happen.  As a result, this seemed to be a lot of “Chicken Little” reporting if you think only about a brute force attack in the traditional sense.

But the more I thought about it I did come up with potential uses for their work.  Wireless technologies are a method of communication where a hacker could obtain passwords without setting off alarms.  So, there is a potential threat, but not as great as the news reports are making you believe.

Then there is the portability, or lack thereof, of a system packed with a bunch of graphics cards.  Yes, we will find a way to shrink it in time, but for now, it’s not a possibility.  So even while the wireless scenario is a threat, without the portability, it too is relatively minor.

This is the problem with security research.  You really have to read the research paper to understand if the threat could actually be used outside of the laboratory.  In the case of this threat, most system administrators have put the following controls in place to stop such attacks.

• Accounts lock after three to five invalid logon attempts.  No running a brute force attack against accounts for two hours straight when you only get three to five logon attempts.
• Once locked accounts can only be unlocked by contacting the help desk.  So you lock the account, you just call the help desk right?  Think the help desk will wonder why you are constantly asking for a reset?  Eventually, you will not be able to convince the help desk to reset the account.
• The help desk requires users to uniquely identify themselves by answering a question that only the user would know the answer.  Now you will have to do research into the user to determine their children’s’ names, birthdates, pets’ names, etc.  That of course implies that you got past bullet number two.

The bottom line is that this is why security standards such as the PCI standards are built in layers.  As researchers discover new threats, there are other controls in place to prevent the failure of the control now in question.

However, where security people frequently mess up is in connecting the dots between the current threat and threats exposed months or years ago that were written off because they were believed to be blue sky thinking.  I have seen examples where, in combination, the current threat plus older threats could be used to compromise security.  It was just all in how the threats were put together and the order they were executed.

This is why I think it is very important that security professionals need to understand their opponent and think like the opponent.  If you cannot understand how to put together an attack, it is very difficult to defend against it.  The best security professionals I have ever worked with thought like their adversaries.  They were always trying to see things through their opponent’s eyes and think of ways to circumvent controls.  It was through this sort of analyses that these top security people were able to create almost impenetrable defenses.  I say almost, because even these super security pros understand that security is not perfect.

Credit Card Terminals And PCI Compliance

Here is a point of confusion that even I do not completely understand.  Mainly because I do not understand why there is any confusion to begin with.  I am writing about this because the PCI SSC and the card brands need to provide guidance on what applies in regards to credit card terminals and PCI compliance.  The credit card terminal industry also needs to wake up and get on board with security before they end up in the PCI compliance dog house.

There seems to be a huge disconnect between the various standards and how they apply to credit card terminals.  In a thread on the SPSP Forum, there have been discussions regarding the fact that credit card terminals are required to meet the PCI DSS standard.  Yet I have seen terminals that store primary account numbers (PAN) unencrypted and violate other PCI DSS and PA-DSS requirements.  If you ask the terminal vendors, they claim that the only standard they need to worry about is the PCI PTS.  Hello?

Requirement 3.4 of the PCI DSS is the most troubling of the lot, the storing of PANs unencrypted.  I have seen numerous terminals that store PANs unencrypted.  Press the vendors on this issue and they come back with the following.

• The PANs can only be displayed one at a time.
• You have to be in administration mode to view the PANs.
• The PANs cannot be printed out.
• The PANs are stored in memory, not on a hard drive.
• The PANs are cleared when the end-of-day (EOD) process is run.

In a couple of instances of which I am aware, the terminal vendor has told everyone that the terminals that are storing PANs will be fixed by August 2010, but not sooner.

Okay.  So you will rely on a compensating control to meet requirement 3.4.  In my opinion, none of those aforementioned bullets are sufficient to meet the requirements of a compensating control.  Big deal that the PANs can only be displayed one at a time.  The fact that you need to be in administrative mode is nothing, as most of these devices only have two modes, end user and administrative.  And to run EOD or do anything else, you need to be in administrative mode.  Storage is storage, memory or otherwise.  Logging of access to these devices is not available.  None of these conditions rise to going above and beyond, so a compensating control is not even possible.

Then there is compliance with the PA-DSS.  This is a really sore spot with terminal vendors.  They claim that the PA-DSS does not apply to them and point to the following on page vii of the PA-DSS standard.

“Hardware terminals with resident payment applications (also called dumb POS terminals or standalone POS terminals) do not need to undergo a PA-DSS review if all of the following are true:

• The terminal has no connections to any of the merchant’s systems or networks;
• The terminal connects only to the acquirer or processor;
• The payment application vendor provides secure remote 1) updates, 2) troubleshooting, 3) access and 4) maintenance; and
• The following are never stored after authorization: the full contents of any track from the magnetic stripe (that is on the back of a card, in a chip, or elsewhere), card-validation code or value (three- or four-digit number printed on front or back of payment card), PIN or encrypted PIN block.”

First, I do not believe there is such a thing as a “dumb” credit card terminal any more.  They all have memory and software and, in most cases, have complete software development kits for application development using languages such as Java, C++ and the like.  In some cases, these terminals are as powerful as a netbook.  Yet, somehow the PCI SSC and the card brands have missed this point.

Most of these devices have only one ‘secure’ account.  And that account is shared with every support person around.  Anyone remember PCI DSS requirement 8.5.8 regarding shared accounts?  Whoops!

Then there is that first bullet regarding the terminal having NO connection to any of the merchant’s systems or networks is where I run into the most problems.  We see a lot of these credit card terminals with serial or USB connections to POS solutions.  In most cases, the terminals are only retrieving the amount of the purchase from the POS solution and telling the POS solution that the transaction has been approved or declined.  But there are also a lot of instances where the data flows from the terminal through the POS to and from the processor.  That does not include the number of terminals that are connected to LANs for access to the processor.

The “rub” in all of this is that the software that drives these terminals is the same regardless of whether they connect to a POS solution or network.  Talk to any software engineer from any terminal vendor and they will tell you that the underlying software for each family of terminals is the same, regardless of the options used or installed.  So, if the terminals are not connected to a POS system we can ignore the fact that these terminals are not PA-DSS compliant.  But if the terminals are connected to the POS, then all of a sudden, they need to be PA-DSS complaint.  What kind of nonsense is that?  In my opinion, they need to comply with the PA-DSS regardless as this is cardholder data processing software.

So, where are we in all of this?

Is the software application in the terminal PA-DSS certified?  No!

Is it supposed to be certified?  Yes!

And the vendors’ responses?  You are misinterpreting the standard.

Pardon?  Exactly where have I misinterpreted the standard?

It’s BS like this that allow people to point at the PCI standards and say they are inconsistent and stupid.  Well, I hate to say it, but in this situation, it is inconsistent and a bit stupid.  All of you at the PCI SSC, the card brands and terminal vendors – get a clue before this becomes the next big exposure point.