Tag Archives: state

Gartner – Visa sets Global PCI deadline

Visa announced a global compliance program for the card industry’s key security standard. But many issues remain, including unclear European deadlines and the treatment of merchants that have chip card processing in place.

On 10 November 2008, Visa announced new global standards for compliance with the Payment Card Industry Data Security Standard (PCI DSS) designed to create a consistent worldwide framework for compliance by merchants, service providers and others. The new standards include a global set of requirements for merchants accepting Visa payments to validate compliance with PCI DSS, deadlines for the largest merchants to achieve validation, and deadlines for large and mid-level merchants to demonstrate that they are not storing certain types of sensitive card data. The new deadlines and processes do not, however, apply to European merchants and service providers.

Analysis

The Visa announcement provides some much-needed clarification for the PCI DSS compliance and validation process for some merchants and service providers outside the United States. Visa merchants and service levels are aligned across most world regions, and deadlines and requirements have been set for demonstrating PCI DSS compliance. Nonetheless, several critical PCI DSS questions remain:

  • Visa deadlines and processes will be different in Europe, because Visa Europe is an independent licensee of Visa international. The absence of published deadlines for European companies leaves that region in its current confused state of PCI compliance.
  • Although Visa has once again taken the lead among card brands in moving the PCI compliance process forward, Gartner is not aware of any similar transparent global enforcement efforts or deadlines announced by American Express, Discover, JCB or MasterCard.

Moreover, many of the affected merchants and processors in the different global regions (including Latin America and Asia) — unlike their counterparts in the United States — have already spent considerable sums upgrading their infrastructure to support card brand mandates to roll out chip and personal identification number (PIN) cards. These same companies must now begin the often-costly PCI compliance process. Merchants Gartner has consulted believe they should be granted some type of compensation (in the form of reduced PCI compliance requirements or extended deadlines) for their chip and PIN support. Visa has indicated that some limited compensation is available to the largest European (Level 1) retailers, whose acquirers may, at their discretion, recategorize them to Level 2 if they have successfully deployed Europay, MasterCard and Visa (EMV) Chip and PIN, and EMV chip cards are encoded with iCVV (card verification value for integrated circuit cards).

Recommendations

Merchants and service providers:

  • Continue to focus on strengthening cardholder data security first, because PCI compliance will follow by default.
  • Begin securing your cardholder data and systems now, and do not wait for your acquiring bank to contact you about PCI compliance.

Visa Europe:

  • Publish deadlines and processes for European companies that must comply with PCI standards.

All card brands:

  • Strengthen the security of the payment system by recognizing that magnetic stripes on cards will not go away until all countries and cardholders move to chip and PIN, and by adding cardholder authentication to magnetic-stripe cards
  • Create a new Self-Assessment Questionnaire with further-reduced PCI DSS compliance requirements for merchants who have upgraded to chip and PIN infrastructure and are not storing any electronic cardholder data.

visa_sets_global_pci_deadlin_163330.pdf (application/pdf Object).

NIST Requests Comments on Next Generation CA Process for Information Systems

NIST Requests Comments on Next Generation C/A Process for Information Systems

National Institute of Standards & Technology

Release date: August 19, 2008

The National Institute of Standards and Technology (NIST) has released for public review and comment a major revision to its security certification and accreditation (C&A) guidelines for federal information systems. A substantial rewrite of the original document, the new Guide for Security Authorization of Federal Information Systems: A Security Lifecycle Approach, represents a significant step toward developing a common approach to information security across the Federal government, including civilian, defense, and intelligence agencies, according to NIST security experts.

When finalized, the revised guide will replace NIST Special Publication 800-37, which was issued in 2004 under the title Guide for the Security Certification and Accreditation of federal Information Systems. Like the original, the revised guide maps out a basic framework for managing the risks that arise from the operation and use of federal information systems, the measures taken to address or reduce risk, and a formal managerial process for accepting known risks and granting-or withdrawing-authorization to operate information systems. The guide emphasizes the need to treat information security as a dynamic process, with established procedures to monitor, reassess and update security measures to maintain the authorized security state of an information system. The revised security authorization process is designed to be tightly integrated into enterprise architectures and ongoing system development life cycle processes, promotes the concept of near real-time risk management, capitalizes on investments in technology including automated support tools, and takes advantage of over three decades of lessons learned in previous approaches to certification and accreditation.

Since 2003, NIST has developed and published information security standards and guidelines under the Federal Information Security Management Act (FISMA). While the NIST methodology for analyzing, documenting and authorizing the security of information systems is widely followed by federal agencies operating non-national security systems, other frameworks have coexisted with it for national security systems, including the Department of Defense Information Assurance Certification and Accreditation Process (DIACAP) and the National Information Assurance Certification and Accreditation Process (NIACAP). This first revision to SP 800-37 is the result of an interagency effort that is part of a C&A Transformation Initiative working toward a convergence of information security standards, guidelines and best practices across the government’s civilian, defense and intelligence agencies. NIST is participating in this effort along with the Office of the Director of National Intelligence (DNI), the Department of Defense (DOD) and the Committee on National Security Systems (CNSS). Future updates to NIST FISMA publications will continue this convergence towards common standards and procedures.

Copies of the initial public draft of SP 800-37 Revision 1 are available from the NIST Computer Security Resource Center at http://csrc.nist.gov. NIST is requesting comments on the draft by Sept. 30, 2008.

Media Contact: Michael Baum, michael.baum@nist.gov, (301) 975-2763

NIST Requests Comments on Next Generation CA Process for Information Systems, Natio.

International Challenges in PCI Security

In a country that’s seen many regulatory compliance challenges this decade, the headaches of PCI security tend to be analyzed from a largely American perspective.

In the process, companies tend to forget that PCI compliance has been a recipe for international indigestion.

“Remember that credit cards are used abroad, and many American companies have personnel handling credit card transactions in offices all over the world,” says Bruce Larson, security director at American Water, a major water utility that employs more than 10,000 people. “If you have a multinational organization, your data is not just sitting in the U.S.”

There may be some irony in hearing that from someone whose concerns are mostly based on security threats inside the U.S. Larsen has to worry about everything from cyberattacks targeting computerized water filtration systems to terrorists who might try to bomb pipelines or poison the water supply. He also loses sleep whenever there’s the chance of a natural disaster.

The inconvenience of online, global commerce

But more people are using credit cards to pay the water bill online, and he knows the credit card data is floating around in databases outside the U.S. Losing any of that data could be a body blow in terms of public confidence. Then there’s the fact that American Water does business with vendors across the globe.

“I have a very geographically distributed network — more than 1,500 locations where humans work, 150-200 of those are critical operations facilities,” Larson told attendees during a PCI security seminar CSOonline held in New York in September.

For Harshul Joshi, director of IT-risk and advisory services at CBIZ and Mayer Hoffman McCann P.C. (MHM), a professional business services company, doing business internationally can make for a lot of confusion regarding the PCI security ground rules.

“When we deal with non-U.S. companies, there is often confusion over what PCI security requires,” Joshi says. “We work with one of the largest magazine publishers with operations around the globe and if you dial an 800 number, chances are you’ll be talking to someone in a call center in Vietnam. You give your credit card number and it is recorded somewhere outside the U.S.”

On the outside looking in

If a company is based outside the U.S. — in Sweden or Ukraine, for example — the problem is usually a lack of communication and money regarding PCI security needs.

Dmitriy Tsygankov, director of the corporate customer care center at a bank based in Europe, says Visa USA tends to offer American companies more incentives and assistance for their compliance efforts. As an example, he mentions the US$20 million in financial incentives Visa USA offered nearly two years ago to encourage quicker adoption of the standard.

“Why does Visa USA offer merchants a $20 million bonus to become compliant and not other regions?” he asked. He suspects it’s because e-commerce is more popular and profitable in the U.S. In the bigger picture, he says, it can be harder for foreign companies to come up with the cash needed to achieve compliance.

No financial incentives were mentioned in a recent statement from Visa Inc. announcing new global PCI compliance deadlines. Under the deadlines, announced last week, global merchants and service providers must show by Sept. 30, 2009 that they are not storing full magnetic stripe data (track data), security codes or PIN data after a transaction is approved. Sept. 30, 2010, is the deadline for all service providers and Level 1 merchants to file compliance reports.

David Taylor, founder of the PCI Knowledge Base, agrees companies outside the U.S. don’t enjoy the same degree of financial support. “There really are no global incentives, just a marketing pitch in the Visa Global PCI Deadlines announcement last week to service providers,” he says.

Visa spokesperson Rosetta Jones confirmed Monday that the company does not currently offer any financial incentives for merchants outside the U.S.

“While Visa USA did offer some monetary incentives for U.S. merchants for a short period of time, the major motivator for merchants to achieve compliance has been their desire to properly protect cardholder data and to prevent being the target of a data compromise,” she says.

Keep the global perspective

Regardless, security experts agree companies must look at PCI security as a global mandate and ensure that the same controls used in the U.S. are being used elsewhere. There’s a danger of that not happening when companies find themselves deep in the weeds trying to get their arms around the sheer scope of the standard, says Daniel Blander, a CISM, CISSP and president of Techtonica Inc. in Los Angeles.

His advice is to not let the scope of the challenge get the better of the organization, and use every remediation and control to give something back to the business that provides a non-PCI return on investment.

“File integrity monitoring is great for improving the quality of implementations and maintaining configuration standards if used correctly; configuration standards can improve the delivery of services and systems by promoting consistency,” he says, noting that’s good for business as a whole — wherever in the world the company operates from.

http://www.networkworld.com/news/2008/111908-international-challenges-in-pci.html.

Do Federal Agencies Belong in Cloud Computing Networks?

Given the current state of the economy and the yawning federal deficit, the efficiency and cost-savings associated with cloud computing are prompting U.S. federal IT agencies to flirt with the cloud platform. Slowly, of course, since it is the government, after all.Cloud computing has become so pervasive in the enterprise that even federal agencies are moving—slowly, of course—in the direction of on-demand computing. Given the current state of the economy and the yawning federal deficit, the efficiency and cost-savings associated with cloud computing may prompt an even quicker shift to the cloud.

“In many cases, agencies are already using the Internet,” said Drew Cohen, a vice president in Booz Allen Hamilton’s Defense IT practice who is working closely with federal agencies. “The words and terms are new, but the core tools have been evolving for some time. It’s really just a maturing of things that are already going on.”

DISA (Defense Information Systems Agency), for instance, awarded contracts in 2006 for on-demand computing services. The idea was for government customers to pay for computing and storage capacity on an as-needed basis instead of having to invest in new hardware and software. Interested customers had to work through the Defense Enterprise Computing Center to develop solutions.

Taking another step toward the cloud, DISA recently introduced RACE (Rapid Access Computing Environment), in which Department of Defense users go to a Web-based portal and provision their own operating environments based on standard Department of Defense architecture. RACE contractors include Hewlett-Packard, Apptis, Sun Microsystems and Vion.

“DISA likes that model in terms of supporting their customers,” Cohen said, though noting that DISA is developing its own cloud for a number of security and privacy reasons. “Building your own cloud is whole different thing. When you build your own cloud, when does it become a cloud?”

Research in the cloud

Other, more public-facing agencies are embracing the now traditional cloud platforms offered by Amazon.com, Google and Microsoft. In February, Google announced it was working with NSF (National Science Foundation) and IBM to allow the academic research community to conduct experiments and test new theories and ideas using a large-scale, massively distributed computing cluster.

Jeannette Wing, the NSF assistant director for the Computer and Information Science and Engineering Directorate, said in an open letter to the academic computing research community that the relationship would give government-funded researchers access to resources that would be unavailable to them otherwise.

According to Wing, NSF hopes the relationship will provide a blueprint for future collaborations between the academic community and private enterprise. “We welcome any comparable offers from industry that offer the same potential for transformative research outcomes,” she said.

Other agencies are also considering a move to cloud computing. After an October cloud computing seminar for government IT agencies, Cohen said more than 20 agencies approached Booz Allen for further insights on life in the cloud.

“Cloud computing gives the ability to go out and try things,” Cohen said. “The cloud offers the opportunity to unlock new ideas. A lot depends on the IT problems they are trying to solve. The rate of adoption [for cloud computing] depends on how and when they are taking up the problem.”

The U.S. government’s march to cloud computing faces steep barriers to adoption, particularly in the areas of security and privacy, but nothing insurmountable, Cohen said. “There are already vulnerabilities in our existing infrastructure that are not in the cloud,” he said. “In the cloud it is harder to exploit these known vulnerabilities.”

Government regulations are also a problem that must be addressed. FISMA (Federal Information Security Management Act), which dictates what federal IT managers can and cannot do with their data, was written before cloud computing developed. The ITAA (Information Technology Association of America) is already exploring what standards the feds might use in cloud computing.

Overall, Cohen predicted, federal agencies will take up cloud computing sooner or later. Given the slow pace of government agencies, though, “sooner” can often be much later.

Do Federal Agencies Belong in Cloud Computing Networks?.

FTC Will Grant Six-Month Delay of Enforcement of ‘Red Flags’ Rule Requiring Creditors to Have Identity Theft Prevention Programs

The Federal Trade Commission will suspend enforcement of the new “Red Flags Rule” until May 1, 2009, to give creditors and financial institutions additional time in which to develop and implement written identity theft prevention programs. Today’s announcement and the release of an Enforcement Policy Statement do not affect other federal agencies’ enforcement of the original November 1, 2008 deadline for institutions subject to their oversight to be in compliance.

The Red Flags Rule was developed pursuant to the Fair and Accurate Credit Transactions (FACT) Act of 2003. Under the Rule, financial institutions and creditors with covered accounts must have identity theft prevention programs to identify, detect, and respond to patterns, practices, or specific activities that could indicate identity theft.

The Rule applies to creditors and financial institutions. Federal law defines a creditor to be: any entity that regularly extends, renews, or continues credit; any entity that regularly arranges for the extension, renewal, or continuation of credit; or any assignee of an original creditor who is involved in the decision to extend, renew, or continue credit. Accepting credit cards as a form of payment does not, in and of itself, make an entity a creditor. Some examples of creditors are finance companies, automobile dealers, mortgage brokers, utility companies, telecommunications companies, and non-profit and government entities that defer payment for goods or services. Financial institutions include entities that offer accounts that enable consumers to write checks or to make payments to third parties through other means, such as other negotiable instruments or telephone transfers.

FTC Will Grant Six-Month Delay of Enforcement of ‘Red Flags’ Rule Requiring Creditors to Have Identity Theft Prevention Programs.

EAC gets mixed review for FISMA compliance

An independent evaluation of the Election Assistance Commission found that it continues for a second year to fall short of some requirements in the Federal Information Security Management Act. Many of the problems identified are tied to a lack of resources and to the commission’s reliance on the General Services Administration as a provider of IT services.

FISMA establishes broad requirements for IT security in executive branch agencies, including maintaining an inventory of information systems, certification and accreditation of those systems, and comprehensive risk-based security plans. It requires an annual evaluation of compliance, which the EAC inspector general this year turned over to the CPA firm Clifton Gunderson LLP for the evaluation.

“The U.S. Election Assistance Commission has made progress in educating users through security and privacy awareness training, and has initiated discussions to develop EAC specific policies related to information system security and privacy,” the IG said in the transmittal letter with the report. “However, additional improvements are needed. The evaluation found that the EAC has not established an information security program and has not been proactive in reviewing security controls and identifying areas to strengthen this program. In addition, the evaluation found that the EAC was not fully compliant with several provisions of the Privacy Act.”

The problems illustrate the challenges faced by small agencies with limited resources, which often rely on other agencies and outside third parties to provide IT services. In the case of EAC, GSA provides network services and applications supporting the commission’s operations. Its Web site is supported by Humanitas Inc. of Silver Spring, Md.

The Election Assistance Commission was established in 2002 by the Help America Vote Act to serve as a national clearinghouse and resource for election administrators. Its mission includes providing technology guidance and voluntary voting system guidelines, managing a voting system testing and certification program, and administering grants and payments to states to help them meet HAVA requirements.

EAC said in its response to the findings that it relies heavily on GSA’s security plans and controls for its IT security and continuity of operations, but is developing its own programs and capabilities.

“Though EAC’s process is informal considering the lack of documentation and procedural guides, a contingency plan exists for GSA systems which include EAC,” the agency wrote. “As a result, EAC would be effectively operational in the event of a minor or major disaster. EAC currently has a draft of recommendations for a COOP plan which will be addressed during the agency’s efforts to be in compliance.”

EAC also has hired a consultant to help it meet FISMA requirements, including, “completion of a certification and accreditation of support systems, system security plans and practices and procedural guides and documentation that will address the following issues:

  • Periodic assessments of risks.
  • Policies and procedures that are based on risk assessments.
  • Periodic testing and evaluation of the effectiveness of information security policies, procedures, practices and security controls.
  • A process for planning, implementing, evaluating and documenting remedial actions to address any deficiencies in the information security policies, procedures and practices of the agency.
  • Procedures for detecting, reporting and responding to security incidents.
  • Plans and procedures to ensure continuity of operations.
  • Subordinate plans for providing adequate information security for support systems.

This year’s FISMA evaluation identified three deficiencies that carried over from last year, as well as six new ones. Carryovers from last year were:

  • Lack of an inventory of systems and applications used by GSA to support EAC.
  • Lack of policies and procedures for information security or privacy management.
  • Inadequate personnel security practices at GSA, which is EAC’s service provider. GSA’s inspector general has reported some non-compliance with background checks for contractors.

New problems for this year are:

  • Lack of an agencywide information security program.
  • Failure to implement a security management structure with written authorities.
  • Failure to complete certification and accreditation, formal risk assessment, security plan or security test and evaluation of LAN and Web site general support systems.
  • Privacy Act non-compliance: No chief privacy officer, has not identified systems with personally identifiable information or done privacy impact assessments, no formal policies addressing info protection needs associated with PII accessed remotely or removed from offices.
  • Failure to establish formal incident response capability.
  • Failure to complete a continuity-of-operations plan, disaster recovery plan or business impact assessment.

EAC is looking to its contractor to help address most of these issues, and in the meantime, “EAC operates within GSA’s security controls,” it said.

EAC’s human resources director currently is acting as privacy officer and the commission still is facing difficulties in identifying a permanent official.

“EAC is currently researching this issue,” it wrote in response to the evaluation. “Due to the fact that the EAC is a small agency with limited human resources and capital, EAC needs to verify that the currently Acting Privacy Officer can formally be appointed Chief Privacy Officer due to the multiple roles and assignments that the person formally has.”

EAC gets mixed review for FISMA compliance.

How to ensure Call Center security

Information security has emerged as a significant concern for businesses that use call centers and Interactive Voice Response or voice portal systems for customer service, which include financial services institutions, insurance agencies and health care companies. Here, Knowledge Center contributor Ron Settele explains how companies can safeguard against a contact center security breach, while meeting new regulatory demands to prevent identity theft.

Identify theft remains a major problem in the United States, with Americans losing $45.3 billion last year. In 2007 alone, 8.4 million adult Americans, or one in 27, were the victims of identity fraud.

While this is a drop of 11 percent from the $51 billion lost in 2006, it’s still a significant issue for consumers. Contact centers and IVR Interactive Voice Response / voice portal systems are particularly vulnerable since existing methods of confirming callers’ identities are insecure.

The pressures

Understandably, consumers today are concerned about security. When it comes to access to voice self-service systems, they are not satisfied with PIN numbers and content knowledge alone for identity verification. Compared to current authentication methods, an increasing number of consumers feel that the use of their voiceprint would go a long way in making their transaction more secure and convenient. Most consumers would enroll their voiceprint with their financial institution, for example, if given the opportunity.

The politics

Established in 1979, the Federal Financial Institutions Examination Council FFIEC is a “formal interagency body empowered to prescribe uniform principles, standards and report forms for….financial institutions.” In 2001, the FFIEC provided specific guidance on authentication in an Internet banking environment. In 2005, it updated that guidance to include high-risk services performed through telephone banking systems and call centers attached to financial institutions. As financial institutions enhance their Internet banking security, threats will migrate to other access channels–mainly the telephone.

The insurance and health care industries are being similarly impacted by the Privacy Rule under HIPAA Health Insurance Portability and Accountability Act of 1996. HIPAA itself protects “individually identifiable health information” held or transmitted, in any form, whether electronic, paper or verbal. HIPAA’s Privacy Rule establishes regulations for the use and disclosure of Protected Health Information PHI, which is any information about an individual’s health status, including biometric identifiers such as finger and voiceprints.

Both of these policies are forcing organizations to a heightened awareness of how to address critical security issues.

Until very recently, you could always count on being prompted for your account number and the last four digits of your social security number when accessing a self-service system. In many cases, the same would be true when speaking to a live agent. Times have certainly changed! There are now many methods available to enhance caller authentication. However, no single method is adequate. Utilizing multiple “factors” to authenticate the identity of a caller is advised.

What is a factor? The FFIEC places factors into three specific categories:

Category #1: Something the user has, such as an ID card, security token, software token, phone or cell phone

Category #2: Something the user knows, such as a password, passphrase or PIN number

Category #3: Something the user is (such as voiceprint, fingerprint or retinal pattern)

In some cases, providing access with a single-factor, multi-item authentication would be considered adequate. In this case, challenging the caller with pieces of information that only they would be likely to know are used. These solutions are typically simple to implement and could be deemed adequate for callers accessing information that is not considered sensitive.

But that’s where the rub is! Opinions differ widely as to what types of information should be deemed sensitive. And, with the proliferation of information that can be accessed via the Internet, could single-factor, multi-item authentication ever be viewed as secure enough?

Multifactor and risk-based authentication solutions

These concerns by the consumer are pushing enterprises to consider multifactor and risk-based authentication solutions. Using something the user “knows” in combination with something they “are,” provides a much more secure environment in which callers can access account information and transact business. The ability to compare and verify a voice sample from the caller against the voiceprint found in the customer profile (for the account being accessed) significantly increases the likelihood that the right person is attempting to access the account.

Even more secure authentication methods are available if other parameters are taken into account. What if, on top of the multifactor authentication method described above, the system also took into account the number from which you were calling? Or how about whether or not the transaction you are performing is typical based on past behavior? How about taking into account the “Superman Effect?” What do I mean by that? It’s when someone tries to access your account from Los Angeles and then tries again just an hour later from New York City.

Risk-based authentication can take all of these parameters into account and more. How about taking into account access attempts from the Internet and the contact center? Solutions such as these are available today and can be tailored to meet your business needs. Market and regulatory pressure is building to require enterprises to deliver more secure access to customer account information. How secure is your customers’ information?

eWeek.

PCI Webinar

The PCI Security Standards Council, a global, open industry standards body providing management of the Payment Card Industry Data Security Standard (PCI DSS), PIN Entry Device (PED) Security Requirements and the Payment Application Data Security Standard (PA-DSS), today announces it is offering a complimentary webinar, “Understanding PCI DSS Version 1.2,” to be held on Tuesday Nov. 25, 2008 at 11:30 a.m. EST and at 7:30 p.m. EST. The session will be repeated on Wednesday Dec. 17, 2008 at 10:30 a.m. EST and 8:30 p.m. EST.

These one hour webinars are designed for merchants and service providers who are implementing the PCI DSS and want to better understand the changes brought about with version 1.2 which was released on Oct. 1, 2008. The series and will feature Bob Russo, General Manager of the Council and Lauren Holloway, Chairperson of the Council’s Technical Working Group. During each session Mr. Russo and Ms. Holloway will address key elements of version 1.2 and what it means for any organization’s compliance efforts.

Webinar participants will discover:

– Elements of each of the 12 requirements of version 1.2;

– What has changed from version 1.1;

– Key dates for version 1.2, and

– The intent of the Council in making any changes.

To register for the 11:30 a.m. EST session on Nov, 25 click http://register.webcastgroup.com/event/?wid=0801125084404 and for the 7:30 p.m. EST session click http://register.webcastgroup.com/event/?wid=0801125084405. To register for the 10:30 a.m. EST session on Dec. 17 click http://register.webcastgroup.com/event/?wid=0801217084406 and for the 8:30 p.m. EST session click http://register.webcastgroup.com/event/?wid=0801217084407. These webinars will be recorded and available for download on the Council’s Web site for those who cannot attend any of the sessions.

For More Information:

If you would like more information about the PCI Security Standards Council or would like to become a Participating Organization please visit pcisecuritystandards.org, or contact the PCI Security Standards Council at participation@pcisecuritystandards.org.

State College Business | Centre Daily.

PCI Post-Audit Pain

 

Those who thought their PCI security challenges would be over after the first passing compliance audit say they continue to be dogged by the same problems that caused pain in the beginning.

 

For Jennifer Atwell, point-of-sale and communication support manager at Apple Gold Group, log management continues to be a pesky nuisance.

“Log management, while necessary, has turned out to be the biggest issue for us,” says Atwell, who is based in the Raleigh-Durham, North Carolina area. “Partnering with a good vendor helps, but when you’re starting from scratch, it’s a big project.”

Legacy applications continue to challenge PCI security at Lifestyle Services Group, according to Jim Griffiths, the company’s UK-based information security and compliance chief. And at the National Bank of Kuwait, Information Security Officer Imran Minhas continues to be challenged by the task of database encryption.

Related Content

“Database encryption is turning out to be a huge project in itself,” Minhas says. “A place where no cardholder data is encrypted at all, all of a sudden has to encrypt almost every one of its databases. It’s a bit hard to get everyone to prioritize this project to everything else. Upper management is good with it, but it comes down to the people who are going to implement the solutions.”

But for the vast majority of security pros surveyed by CSOonline in recent weeks, the biggest problem is upper management.

The top brass may be fully supportive during that initial PCI security effort. But once that first audit is complete and the company gets a passing grade, the executives assume the task is done. Instead, security pros have found that the work is never done.

“Everyone, especially senior management, thinks that if we pass a PCI audit then we are safe for a year,” says David Glosser, network security administrator for a company in New York City. “There’s a perception that PCI-compliant shops are perfect.”

The upper management problem

Others polled by CSOonline reported running into the same wall Glosser spoke of. Daniel Blander, a CISM, CISSP and president of Techtonica Inc. in Los Angeles, says he has seen the problem up close.

“Having worked on two PCI projects, the biggest challenge is typically management’s view, ‘Well, were compliant, so we’re done.’” He says. “Some parts of management understand the ‘why’ of PCI, but don’t understand overall risk management. Maintaining attention after the fact is the biggest challenge.”

Serg Anishchenko, the technical manager at a company in Hungary, offered a “funny” example of how clueless upper management can be:

“They were sure I would be able to fix the system alone in couple of weeks,” he says of the top brass at his company. “Another challenge is working out a roadmap to find the easiest way to get compliant and stay that way for the longest period of time.”

Tim Holman, senior consultant at QCC Information Security Ltd. in the UK, says PCI security is still generally being seen as an IT security project, lacking buy-in from senior management, which “leads to all sorts of fun and games.” Taking credit card payments is rarely seen as a risk at the board level.

Documentation, please

The second-biggest ongoing challenge security pros mentioned is log management and documentation. Auditors rabidly digest those logs during audits, and they are a critical tool for spotting security holes and attempted breaches. Unfortunately, good log management isn’t an easy process to maintain.

“My experience with PCI DSS compliance showed that documentation is a problem. Merchants could have good security installations, but it’s a problem to write policy for change management procedures,” says Dmitriy Tsygankov, director of the corporate customer care center at Swedbank in Ukraine. “It’s not difficult to change IP tables or to buy a new server, but it’s much more difficult to use and control all procedures” once they are in place, according the documentation procedures.

Survival tips

Blander says there are a host of other PCI challenges companies continue to wrestle with. For one thing, he says, the sheer scope of remediation can be overwhelming, given that the standards are so broad. “For a retailer that means all stores (typically in the many hundreds),” he says. “The sheer cost of addressing that large a scope is a factor given the current state of retail. This doesn’t make the standards bad, just a challenge to tightening budgets and limited resources.”

His advice is to not let the scope of the challenge get the better of the organization, and use every remediation and control to give something back to the business that provides a non-PCI return on investment.

“File integrity monitoring is great for improving the quality of implementations and maintaining configuration standards if used correctly; configuration standards can improve the delivery of services and systems by promoting consistency,” he says, noting that’s good for business as a whole.

Griffiths has experienced many of the challenges listed above. But he remains confident in his organization’s ability to do right by PCI security.

“None of the pain points are insurmountable,” he says. “PCI is either a logical extension of current security practices or a huge undertaking in organizations with little or no security appetite.”

The most important ingredient for any organization dealing with PCI security, security experts generally agree, is the security appetite Griffiths mentions.

http://www.networkworld.com/news/2008/110508-pcis-post-audit-pain.html

New ‘Red Flag’ Requirements for Financial Institutions and Creditors Will Help Fight Identity Theft

New ‘Red Flag’ Requirements for Financial Institutions and Creditors Will Help Fight Identity Theft

Identity thieves use people’s personally identifying information to open new accounts and misuse existing accounts, creating havoc for consumers and businesses. Financial institutions and creditors soon will be required to implement a program to detect, prevent, and mitigate instances of identity theft.

The Federal Trade Commission (FTC), the federal bank regulatory agencies, and the National Credit Union Administration (NCUA) have issued regulations (the Red Flags Rules) requiring financial institutions and creditors to develop and implement written identity theft prevention programs, as part of the Fair and Accurate Credit Transactions (FACT) Act of 2003. The programs must be in place by November 1, 2008, and must provide for the identification, detection, and response to patterns, practices, or specific activities – known as “red flags” – that could indicate identity theft.

Who must comply with the Red Flags Rules?

The Red Flags Rules apply to “financial institutions” and “creditors” with “covered accounts.”

Under the Rules, a financial institution is defined as a state or national bank, a state or federal savings and loan association, a mutual savings bank, a state or federal credit union, or any other entity that holds a “transaction account” belonging to a consumer. Most of these institutions are regulated by the Federal bank regulatory agencies and the NCUA. Financial institutions under the FTC’s jurisdiction include state-chartered credit unions and certain other entities that hold consumer transaction accounts.

A transaction account is a deposit or other account from which the owner makes payments or transfers. Transaction accounts include checking accounts, negotiable order of withdrawal accounts, savings deposits subject to automatic transfers, and share draft accounts.

A creditor is any entity that regularly extends, renews, or continues credit; any entity that regularly arranges for the extension, renewal, or continuation of credit; or any assignee of an original creditor who is involved in the decision to extend, renew, or continue credit. Accepting credit cards as a form of payment does not in and of itself make an entity a creditor. Creditors include finance companies, automobile dealers, mortgage brokers, utility companies, and telecommunications companies. Where non-profit and government entities defer payment for goods or services, they, too, are to be considered creditors. Most creditors, except for those regulated by the Federal bank regulatory agencies and the NCUA, come under the jurisdiction of the FTC.

A covered account is an account used mostly for personal, family, or household purposes, and that involves multiple payments or transactions. Covered accounts include credit card accounts, mortgage loans, automobile loans, margin accounts, cell phone accounts, utility accounts, checking accounts, and savings accounts. A covered account is also an account for which there is a foreseeable risk of identity theft – for example, small business or sole proprietorship accounts.

Complying with the Red Flags Rules

Under the Red Flags Rules, financial institutions and creditors must develop a written program that identifies and detects the relevant warning signs – or “red flags” – of identity theft. These may include, for example, unusual account activity, fraud alerts on a consumer report, or attempted use of suspicious account application documents. The program must also describe appropriate responses that would prevent and mitigate the crime and detail a plan to update the program. The program must be managed by the Board of Directors or senior employees of the financial institution or creditor, include appropriate staff training, and provide for oversight of any service providers.

How flexible are the Red Flags Rules?

The Red Flags Rules provide all financial institutions and creditors the opportunity to design and implement a program that is appropriate to their size and complexity, as well as the nature of their operations. Guidelines issued by the FTC, the federal banking agencies, and the NCUA (http://ftc.gov/opa/2007/10/redflag.shtm) should be helpful in assisting covered entities in designing their programs. A supplement to the Guidelines identifies 26 possible red flags. These red flags are not a checklist, but rather, are examples that financial institutions and creditors may want to use as a starting point. They fall into five categories:

# alerts, notifications, or warnings from a consumer reporting agency;

# suspicious documents;

# suspicious personally identifying information, such as a suspicious address;

# unusual use of – or suspicious activity relating to – a covered account; and

# notices from customers, victims of identity theft, law enforcement authorities, or other businesses about possible identity theft in connection with covered accounts.

More detailed compliance guidance on the Red Flags Rules will be forthcoming. For questions about compliance with the Rules, you may contact RedFlags@ftc.gov.

Read more about this regulation at http://www.ftc.gov/bcp/edu/pubs/business/alerts/alt050.shtm

And about the extension of the compliance deadline at http://www.ftc.gov/opa/2008/10/redflags.shtm

 

New ‘Red Flag’ Requirements for Financial Institutions and Creditors Will Help Fight Identity Theft.