Signatures or PINs? EMV is Coming

Whether you are a seasoned, international road warrior, or a domestic suburbanite, new security features will soon be showing up on a credit card near you. In light of recent card data compromises, there’s a new drive to adopt credit card security technologies known as “Chip and PIN” (typically noted as “chip/PIN”) to better secure credit card data against fraud or compromise. While chip/PIN is new to most U.S. cardholders, it is the norm across most of Europe, Canada, and Mexico. There have been many initiatives in the last several years to drive U.S. payment card systems towards more secure technologies, but only now is adoption of chip/PIN starting to get increased traction across the U.S. payment card industry.

For individual card holders, these developments are important, and in this post we will cover some of the key points of these technologies.

 

First, what exactly is chip/PIN and what does it do to protect credit card data?

In a chip/PIN environment, when purchasing goods at a point of sale (POS) device, the credit card is inserted or “dipped” into a card reading device—not swiped as it is in the U.S. Once inserted, the customer inputs a PIN which authenticates the cardholder against the chip embedded on the card. Upon successful authentication, the chip generates the data necessary to complete the transaction and transmits the data for authorization.

Before we get too far into the discussion about chip/PIN, there is one point that needs to be clarified: The chip component of chip/PIN cards is sometimes referred to as “EMV data” or “EMV transactions” in the payment industry. The term EMV (for Europay, MasterCard and Visa) refers to a standard definition for chip-based payment cards, or “chip cards”—also referred to as “IC (integrated circuit) cards” as defined by EMVCo LLC. EMV is the basis for the chip/PIN implementation throughout Europe, and is planned for implementation in the U.S. (more on that, below). In short, EMV refers to the “chip” portion of chip/PIN cards, with the “PIN” implementation being a separate matter entirely.

Why is this relevant? Because much of what has been discussed thus far about implementing chip cards in the U.S. is focused primarily on the “chip” component, and does not necessarily include the “PIN” component that is otherwise present in Europe’s EMV environment. In lieu of using a PIN to authenticate the chip card, discussions in the U.S. have leaned toward reliance on manual signature verification (such as when a clerk compares the signature on the receipt to the signature on the card). As a result, the U.S. implementation will likely wind up being referred to as “chip and signature” or “chip/signature.”

 

What’s the difference between chip/PIN and chip/signature?

From the merchant’s perspective the credit-card payment process wouldn’t change significantly, outside of likely hardware upgrade requirements. And from the processor’s perspective, there really isn’t a difference, as long as they process or support transactions using EMV, or “track-equivalent data.”

Track-equivalent data is the data — including cryptographic data — used for transaction authentication and authorization within EMV environments. It is generated by the on-board integrated circuit, or the “chip,” on the card itself—not the card-reading device. This is not to say that track-equivalent data is “secure” in-and-of-itself. Because of some of the underlying functional requirements, track-equivalent data typically includes certain discretionary data elements, some of which are sensitive in nature and cannot be stored (something merchants should note).

From the cardholder perspective, however, there is one notable difference and that is the requirement of a PIN or signature to verify that the person holding the card is the actual card owner.

 

Is chip/PIN more or less secure than chip/signature?

That depends.

In a chip/PIN scenario, the PIN is used to authenticate the cardholder against the information stored on the chip. If you don’t know the PIN, the chip won’t give up the information necessary to complete the transaction. In a chip/signature scenario (theoretically speaking), the clerk responsible for completing the transaction would be required to validate the customer signature on the receipt with their signature on the card. If your signature doesn’t match sufficiently enough per the clerk’s perusal, they won’t complete the transaction. Say what you will about how consistently the practice of signature verification is actually practiced, versus how it is supposed to in theory, there are equally compelling arguments for either approach.

In a chip/PIN environment, as long as the cardholder’s PIN is kept secret, it would be theoretically impossible for someone to use a stolen card to perform fraudulent card-present transactions. It is because of the PIN requirement that card criminals have evolved their data collection strategies to include video surveillance targeting PIN entry devices, such as at ATMs and retail point-of-sale devices, to collect customer PINs. Once the PIN is compromised, the card can be used for fraudulent transactions. On the other hand, I can show my signature around to anyone, put it on all my receipts, etc., and the likelihood of anyone being able to reliably reproduce it on demand is pretty slim (expert forgers, excluded). Ultimately, the question boils down to this: Which is a more secure means to verify that a credit card belongs to the person holding the card?

 

Conclusion

It can be erroneously concluded that U.S. implementation of EMV heading in the direction of chip/signature undermines many of the anti-fraud security protections of chip/PIN. However, when the issue is considered from multiple sides, especially in putting everything together for this article, the more it is clear that there is no significant security benefit of one solution over the other.  Whether it is PIN or signature, the control is only used to authenticate the cardholder—the rest is about implementing security controls via EMV and integrated circuit cards that has nothing to do with either PINs or signatures. Until there is historical data to demonstrate the effectiveness or ineffectiveness of signatures vs. PINs in reducing card fraud, the jury is still out on which solution offers a significant upside over alternatives.

Ultimately, whether cards are authenticated via PIN or signature, the chip-based credit cards being rolled out in the U.S. will rely upon EMV security measures to protect the security of credit card data. These technologies provide a solid foundation for improving the overall security of credit card information and limiting fraud and misuse of compromised credit card data.

 

Resources

EMVCo LLC Website: http://www.emvco.com/

Wikipedia: EMV http://en.wikipedia.org/wiki/EMV

Configuration Assurance: Evolving Security Beyond the Basics

Perhaps it is more appropriate for us to approach configuration management as an assurance process meant to ensure system integrity is maintained over time. By evolving our view of how to establish and control the integrity of the different devices and technologies in use, the concept of “configuration management” evolves to become more about “configuration assurance.”

The Need to Manage Configuration 

When considering the different aspects of information security program management, few topics are of as much importance to an organization’s overall security posture as the topic of “configuration management.” This is due, in part, to the number of different standards and processes that typically comprise or govern a configuration management program. And, it is usually the lack of governance or enforcement of configuration management practices that lead to system and information compromises.

When we look at configuration management, it is important for us to keep in mind that what we’re really addressing is the “I” of InfoSec’s “Confidentiality, Integrity, and Availability,” or “C.I.A.” Because of this, we should understand each of the different parts that make up a configuration management program or process, and further understand them as part of an overall process for ensuring the integrity of any given device or system. Ultimately, the basis for establishing and verifying the integrity of a device or system needs to be consistent with the information security standards defined by the organization, industry best practices, industry or governmental regulation, and relevant legislative requirements.

The Basics of Configuration Management 

The objective of any meaningful configuration management program is a security-minded framework within which all information systems can be tracked, classified, reviewed, analyzed, and maintained according to a consistent set of practices and standards. Configuration management programs usually incorporate several different standards and processes to address the diverse aspects of information security, such as standard build/configuration documentation and processes, antivirus monitoring, patch management, vulnerability management, asset management, etc. Essentially, it comes down to having lot of eggs that ultimately wind up in the same basket, with the objective being that none of the egg shells get broken.

At a high level, the functional and security requirements for most of these programs and services are fairly well understood. It is common for organizations to treat each of the different aspects of configuration management as stand-alone programs or processes. However, reality is quite different. In addition to ensuring that a configuration management program addresses all of the relevant security requirements, it is also equally necessary to understand how each individual security process or program relates to other security processes or programs. Why? Because each of the processes associated with configuration management impacts other processes related to configuration management. The manner in which these interrelationships are addressed (or not addressed) may expose significant risks in critical or sensitive information systems.

Regardless, many organizations still tend to approach delivery of these programs and services as individual and somewhat isolated or unrelated processes. This is especially true for organizations that heavily focus on meeting compliance requirements without embracing the larger concept of “information security.” This is also true in organizations where information security programs are less mature, or if there is an over-reliance on technology in the absence of formal documentation.

Where the Gaps May Lie

Following are a couple of examples where gaps might typically occur in the configuration management process. After each example, I’ve put together a few follow-up questions to help explore each issue a little more in-depth.

A. Auditing and Log Monitoring – Most security policies and system configuration standards tend to address audit and logging requirements at the operating system level. However, operating system audit log services are not always capable of capturing detailed audit log data generated by some applications or services. As a result, it may be necessary to combine and correlate multiple audit log data sources (perhaps from multiple devices) to reconstruct a specific chain of events. All business processes should be reviewed to ensure that the full complement of required audit log data is being collected and reviewed.

  1. Do your policies, standards, and processes ensure that all required security audit log data is collected for any and all firewalls/routers, workstations, critical/sensitive applications, databases, monitoring technologies, and other relevant security devices or technologies used in the environment?
  2. Do policies or standards require audit log data collection to include audit log data from all antivirus endpoints, file integrity monitoring endpoints, IDS/IPS alerts and events, security devices or applications, and file or database access?
  3. Is all audit log data, of all types, collected to a single or centralized source(s)?
  4. Is all audit log data backed up regularly (at least daily) and protected against unauthorized access or modification?
  5. Is audit log data from one source combined and correlated with audit log data from other devices or services to reconstruct specific activities, identify complex attacks, and/or raise appropriate alerts?
  6. Has your organization performed any testing or forensic activities to verify that audit log information currently being collected is sufficient to raise appropriate alerts and reconstruct the events related to any suspicious activity?

B. Standard Build/Configuration – It is commonplace for organizations to have standards documentation describing how to install and configure the different kinds of operating systems (and sometimes databases) used in the environment. However, it is not quite so common to have similar documentation (or similar level of detail) when it comes to some specialized technologies or functions. As we are all aware, a secure technical environment is reliant upon more than just securing the operating systems and extends to all devices in use. Policies, standards, and processes should exist to address all technologies used in the environment and should define how to establish, maintain, and verify the integrity of any device or application intended for use within the environment.

  1. Do documentation and processes currently exist to define the secure initial configuration of all technology device types and applications in use in the environment? This includes technologies or devices such as firewalls, routers, servers, databases, mainframe/mid-range, wireless technologies and devices, mobile computing devices (laptops and smartphones), workstations, point-of-interaction devices, IVR systems, and any other technologies related to establishing, enforcing, or monitoring security posture or controls.
  2. Are configuration standards cross-checked to ensure that all relevant information security subject areas are addressed or appropriately cross-referenced? For example, do OS configuration standards include details for installing antivirus or other critical software (FIM, patch management, etc.)? If not, is a reference provided to supporting documentation that details how to install antivirus or other critical software for each specific operating system type?
  3. Do documentation and processes currently exist to define not just the secure configuration of the base operating system, but also to define a minimum patch level or version a system must meet (e.g., “Win7 SP2” or “Apache version X.X.Y”) before being permitted to connect to the network environment?

These are clearly not all of the possible intersections or gaps that might occur in how an organization approaches configuration management. In developing an information security program, each organization will need to identify the relevant services, processes, and programs that represent how configuration management is achieved. As part of a process of constant improvement, the next logical step would then be to take a closer look at the internal process interrelationships and try to identify any gaps that might exist.

Where to from here?

By evolving our view of how to establish and control the integrity of the different devices and technologies, the concept of “configuration management” evolves to become more about “configuration assurance.” Instead of approaching configuration management as a somewhat unregulated process kept in check by periodic review (audit), perhaps it is more appropriate for us to approach configuration management as an assurance process meant to ensure system integrity is maintained over time.

In the end, one of the biggest enemies of information security is time. Because even if you have bullet-proof security controls in place today, they will probably not offer much protection  against the vulnerability/exploit that a hacker will identify tonight or a vendor will announce tomorrow (or Tuesday).