BankInfoSecurity.com
HealthCareInfoSecurity.com

CLEANING CREW STEALS DOCTORS CREDIT CARD INFO STORYhttp://docpay.com/pciarticle.pdf

Not PCI Compliant? Get ready for monthly fees…http://gazebo.commonplaces.com/2009/09/not-pci-compliant-get-ready-for-monthly-fees/

Indicted Suspect Allegedly Breaks Record for Credit-Card Data Theft
http://www.cnn.com/2009/CRIME/08/17/US.computer.hacking.charges/

 Big-Box Breach: The Inside Story of Wal-Mart’s Hacker Attack
http://www.wired.com/threatlevel/2009/10/walmart-hack/

 VISA Best Practices
http://corporate.visa.com/_media/best-practices.pdf

A Chronology of Data Breaches
http://www.privacyrights.org/ar/ChronDataBreaches.htm#4

Data Breach Credit Card Hackers
http://www.youtube.com/watch?v=eEnX_TzmuSk

Wireless Hack Data Breach
http://www.youtube.com/watch?v=pqCJqwkeTVo

Biggest Data Breach in History
http://www.youtube.com/watch?v=8M27V70IRGE

Forbes Article Validates Need for PCI
http://www.forbes.com/2010/05/17/security-paypal-pci-technology-business-survival-10-credit-card.html

The HIPAA Security Rule
The Security Rule applies to protected patient health information in electronic formats. This is protected patient information either transmitted by electronic media or maintained on electronic media. Covered entities that maintain or transmit protected health information are required by the Security Rule (see 45 C.F.R. §164.306) to:

• Ensure the confidentiality, integrity, and availability of all electronic protected health information the covered entity creates, receives, maintains, or transmits.
• Protect against any reasonably anticipated threats or hazards to the security or integrity of such information.
• Protect against any reasonably anticipated uses or disclosures of such information that are not permitted or required under subpart E of this part.
• Ensure compliance with this subpart by its workforce.

According to the HIPAA regulations, Covered Entities are allowed to use a flexible approach when implementing the above requirements. Specifically, Covered Entities may use any security measures that allow the Covered Entity to reasonably and appropriately implement the standards and implementation specifications as specified in this subpart.
In deciding which security measures to use, a covered entity must take into account the following factors:

• The size, complexity, and capabilities of the covered entity.
• The covered entity's technical infrastructure, hardware, and software security capabilities.
• The costs of security measures.
• The probability and criticality of potential risks to electronic protected health information.

With this information in mind, organizations must adhere to the Security Rule's standards and specifications for backing up and safekeeping electronic data. Covered Entities also need to institute a contingency plan to be prepared for an emergency, such as a natural disaster or computer virus attack, that results in a major data loss. The contingency plan must:

• Establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that damages systems that contain electronic protected health information (Administrative Safeguards - §164.308(a)(7)(i)).

This contingency plan must be implemented as follows:

• Data backup plan (Required). Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information.
• Disaster recovery plan (Required). Establish and implement procedures to restore any loss of data.
• Emergency mode operation plan (Required). Establish and implement procedures to enable continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode.

Covered Entities must also have certain physical safeguards, such as facility access controls. They must:

• Implement policies and procedures to limit physical access to its electronic information systems and the facility or facilities in which they are housed, while ensuring that properly authorized access is allowed (Physical Safeguards - §164.310(a)(1)).
• The contingency operations should establish and implement procedures that allow facility access in support of restoration of lost data under the disaster recovery plan and emergency mode operations plan in the event of an emergency (§164.310(a)(2)(i)).

In addition, Covered Entities must implement specific technical safeguards (§164.312) to, among other things:

• Limit access to and electronic protected health information.
• Encrypt and decrypt electronic protected health information.
• Put into place audit controls that record and examine activity in information systems that contain or use electronic protected health information.
• Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.

These regulations are in place to ensure that healthcare organizations properly secure their Electronic Protected Health Information (EPHI). Based on these directives, an organization should evaluate their system and then implement a secure backup, archiving and recovery solution to comply with HIPAA standards.

HIPAA Compliance and Intronis Online Backup + Recovery Intronis Online Backup + Recovery can help organizations meet HIPAA compliance requirements, specifically those of the Security Rule. Intronis Online Backup + Recovery is an online backup, archiving and recovery solution that automates the process of securely backing up electronic data and file recovery. It was created, with healthcare providers in mind, to satisfy the broad need for a safe, reliable, and cost-effective method of backing up data offsite and allowing full file restoration at any time from any authorized location. Intronis Online Backup + Recovery was designed to encompass the advanced functionality and features of backup systems used by Fortune 500 companies, yet be effortless for anyone to use regardless of their computer expertise. When it was unveiled to the market, it quickly gained recognition with customers nationwide, and has since built a reputation for providing a superior quality service and world-class customer support.

The Intronis solution ensures that all electronic protected health information (EPHI) is fully protected when it is backed up and stored. It encrypts all data and stores the information in military-grade secure facilities. The HIPAA security standards require your practice to appoint someone as the security manager3, thus only this designated individual in charge of the security management process will have access to this data, hence preventing unauthorized access or corruption. Furthermore, in the event of a natural disaster or system failure, the data will be recoverable, thus, assuring that patient medical records will not be lost.

Security and Encryption
Why is it important to secure and encrypt my organization's data?
Your organization needs to protect EPHI from unauthorized access and corruption. David Kibbe of the American Academy of Family Physicians explains, "The basic idea behind cryptography, of which electronic data encryption is a branch, is that a group needs to keep a message secret from everyone else and therefore encrypts it. Encryption is the transformation of a message from plain text into nonsensical cipher text before the message is sent. Anyone who steals the cipher text message will not be able to understand it. Only those who have the code used to encrypt the message can convert it back from cipher to plain text and reveal its meaning." The following types of electronic data contain information that should be encrypted when backed up:

• Patient billing and administrative information exchanged with payers and health plans;
• Utilization and case management data, including authorizations and referrals that are exchanged with payers, hospitals and utilization management organizations;
• Patient health information gathered from or displayed on a Web site or portal;
• Lab and other clinical data electronically sent to and received from outside labs;
• Word-processing files used in transcription and other kinds of patient reports that are transferred electronically;
• E-mails between physicians and patients, and between attending and referring physicians and their offices 3.

The Intronis Online Backup + Recovery solution is a secure and trusted method to protect this private data. During a backup all data, including patient and billing records, will be encrypted before leaving the user's computer(s) and is never accessible without the user's encryption key. This encryption key is stored only on the user's system and never transmitted over the Internet. Furthermore, it is not stored on the Intronis servers, thus Intronis cannot access files or even read the file names. Only the user maintains control of their data, eliminating the threat of unauthorized access.

Data is encrypted using a 256-bit Advanced Encryption Standard (AES) encryption technology. AES encryption was developed by the U.S. National Institute of Standards and Technology (NIST) and is now the state-of-the-art standard encryption technique for both commercial and government applications. Moreover, in June 2003, 256-AES was approved by the United State's National Security Agency (NSA) for use encrypting the U.S. government's documents classified "TOP SECRET." Using this secure technology, data is initially encrypted during the initial backup and then encrypted once again during the Internet transfer, to and from the Intronis servers.

For added security, and to meet the Security Rule's transmission requirements, each encrypted file is sent over the Internet via a secure channel using Secure Sockets Layer (SSL) technology. The same Internet transmission technology is used for online banking and credit card applications. As a result, Intronis Online Backup + Recovery is able to provide double the data encryption of typical online backup products.

Additionally, all user data is transferred and stored in two redundant Level 4, SAS 70 certified, secure data centers, located hundreds of miles apart from each other Each data center has 24/7 onsite monitoring, advanced security technology such as biometric access controls, backup generators and redundant connections to the Internet.

Logging and Archiving
Intronis Online Backup + Recovery records each file that is backed up or restored as well as additional information and statistics regarding the backups. This audit log, which can easily be searched, allows the user to verify that files were successfully backed up and help troubleshoot any issues. The user also has the option to receive an automated email notification at the conclusion of each successful backup. Information about recent backups and total storage usage can also be viewed via the Internet, by logging on to the user's account at www.intronis.com. For further HIPAA compliance, CDs and DVDs of data are available for additional archiving.

Backing Up and Restoring
The backup process and file recovery process are completely automated, eliminating the need for manual data handling. Backups will automatically occur according to the specific schedule the user sets in place as long as the computer is on and functioning (and not in sleep or powersave mode). Backups can also be initiated by the user at any time. Because backups run in the background of the system, they have little or no impact on the computer's performance or Internet connectivity, and are non-disruptive.

Restoring files can be accomplished with just a few clicks of the mouse by the individual who is designated as having overall responsibility for the security of a CE's EPHI. Using Intronis Online Backup and Recovery, the user simply chooses the files, folders or revisions that he or she wants to retrieve by clicking on the file name. The data will then be downloaded to the user's computer, decrypted, and then restored to their original location or another specified location on the user's system. A password is required to restore any files, thus, preventing unauthorized restores, as per the HIPAA Security Rule. In the event of a complete system failure, a full recovery of the user's backed up data can be initiated in just minutes. The recovery procedure can be performed on any Windows based computer - not just the computer where the data was originally backed up. The user can simply download and reinstall the software, enter his or her username and password, and then enter the encryption key. Once the software installation is complete, the file catalog can be accessed (the list of all of the files backed up) which will allow the user full control to restore their data.

VeriFone addresses PCI enforcement confusion
A large part of what complicates compliance with the Payment Card Industry (PCI) standards for data, PIN entry device and payment application security is the frequent, though necessary, changing of the rules to keep up with evolving security threats.

To make things easier, the PCI Security Standards Council (PCI SSC) established specific timelines by which upgrades must be made to payment terminals. Yet, compliance is enforced by the card brands, not the PCI SSC. Furthermore, the rules can be tweaked by individual acquirers eager to ensure the compliance of their merchants and thus avoid liability for data breaches or rules violations.

Such discrepancies in the way compliance is enforced can be a source of confusion among merchants, ISOs and merchant level salespeople.

An Oct. 8, 2009, webinar put on by secure payment solutions provider VeriFone (available on VeriFone's Web site at www.verifonezone.com) addressed this and other issues relating to the PCI sunset dates and compliance generally. The webinar, hosted by Lori Breitzke, Director of Marketing for VeriFone, clarified when those sunset dates are, the differences between each one and other related issues.

Those dates
Two important sunset dates are July 2010 and December 2014, and both relate to PIN Entry Device (PED) terminals. The first date is the time by which terminals manufactured before 2004 must be swapped; the latter pertains to terminals manufactured between 2004 and 2007. Those cannot be used after 2014, but their sale has been forbidden since the end of 2007.

Meanwhile, PED terminals built after 2007 – all of which contain Triple Data Encryption Standard (DES) encryption, which is the key feature in all this – can as yet be used indefinitely.

According to Breitzke, there is "a whole lot of confusion over what the impact is" of the PCI compliance sunset dates because of some of the additional rules they have spawned. For example, Visa has required that summaries be submitted of all triple DES-compliant terminals and "attendant POS activity" by October 2009.
Visa stated further that beginning in August 2012, acquirers may be assessed fines for "fostering non-triple DES compliant merchants or agents" even though triple DES encryption won't be required of all merchants by the PCI SSC until 2014.


New fees
"We know there is one major acquirer that has come out and said they are going to be charging noncompliance fees," Breitzke said. "But we've heard that several large acquirer processors have been charging these fees, so it's really up to the ISO to communicate with the acquirer processor to figure that out.

"But I think that's going to be very likely [that acquirers in general will began levying fees for noncompliance] because the acquirer is the one that's going to be liable. So a way for them to recoup some of those costs of noncompliance or a breach would be to charge some kind of a fee."

Breitzke said that for merchants using terminals without PIN debit, there is "absolutely no compliance or security mandate to get rid of it." Nonetheless, she stressed that, for security reasons, having an updated terminal is always a good idea.

Breitzke also mentioned an omission in the PCI SSC's merchant self-assessment security questionnaire used to check various compliance points: It does not contain any questions that specifically address PED devices."We have spoken with the PCI Security Council, and they do plan to update that questionnaire," she said.


NEW requirements for securing payment applications
Recently the Payment Card Industry Security Council has transitioned payment application security procedures from the Payment Application Best Practices (PABP) to a series of requirements called the Payments Application Data Security Standards (PA DSS). These measures guide software vendors and others in developing secure payment applications that do not store prohibited data, such as full magnetic stripe, CVV2 or PIN data, and ensure their payment applications support compliance with the PCI DSS.

Summary PA DSS Requirements

• Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data.
• Protect stored cardholder data.
• Provide secure authentication features.
• Log payment application activity.
• Develop secure payment applications.
• Protect wireless transmissions.
• Test payment applications to address vulnerabilities.
• Facilitate secure network implementation.
• Cardholder data must never be stored on a server connected to the Internet.
• Facilitate secure remote software updates.
• Facilitate secure remote access to payment application.
• Encrypt sensitive traffic over public networks.
• Encrypt all non-console administrative access.
• Maintain instructional documentation and training programs for customers, resellers, and integrators.

Detailed standards and other PA DSS information are available from the PCI Security Standards Council. www.pcisecuritystandard.org

Merchant Requirements
Access, report, and validate PSI compliance

Obligations
Every merchant is assigned one of four levels based on the volume of its annual payment card activity. Merchants at each level must perform certain actions within a defined process in order to meet requirements. The definitions and obligations for each merchant level appear below:

Place Table here

Reporting
Merchants must become fully PCI compliant to prevent fines. PCI Coverage mitigates potential fines by reporting progress toward PCI compliance for Level 1, 2, and 3 merchants to MasterCard and Visa prior to each of the following dates: We will report on Level 4 merchants at our discretion.

PCI DSS Compliance Validation
To validate compliance with the PCI DSS, there are two requirements.

All merchants are required to complete:
Annual PCI DSS Self Assessment Questionnaire (SAQ) - An approved list of questions from the card associations about the security controls on a merchant's transaction network. There are four different SAQs to help scale the question set appropriately to each merchants’ environment.

Certain processing environments are also required to complete:
Quarterly Network Vulnerability Scanning - A remote scan of a merchant's transaction network (conducted by an ASV) to detect weaknesses in your external systems could be exploited by hackers or unauthorized third-parties. Merchants will receive a compliance report, created with data gathered from the questionnaire and the scan, which outlines actions required to address any vulnerabilities.

PCI Coverage merchant clients will have access to these steps for validating PCI DSS compliance through Trustwave's TrustKeeper® solution. TrustKeeper is an online compliance portal, providing access to the SAQ and vulnerability scanning for merchants approaching PCI DSS. To get started, follow these easy steps:

Please visit: https://pcicoverage.trustkeeper.net and click “Register Now”

• Complete the registration questionnaire
• Choose and complete the appropriate SAQ (TrustKeeper provides guidance on what makes sense for your environment)
• Schedule and execute vulnerability scanning

Once these steps are complete, you will receive a compliance report of your results, outlining any areas that require attention and remediation to secure your external-facing environment. Please be aware that compliance with PCI DSS is an ongoing process, not a point in time. Compliant quarterly scans and a compliant annual SAQ are required to maintain compliance.

 

Links to additional resources, white papers, and web-based media resources:

HIPAA Content
www.legalarchiver.org/hipaa.htm
PCI SSC Quick Guide

Organizations

Below are links to the data security programs of the Card Associations, American Express, Discover, and Trustwave, a third-party assessor.

• Visa’s Cardholder Information Security Program (CISP)
• MasterCard’s Site Data Protection (SDP) program
• Discover’s Discover Information Security and Compliance(DISC) program
• American Express Data Security Operating Policy (DSOP)
• Trustwave

Webinars and Webcasts
Downloadable media presentations from Trustwave.
www.trustwave.com/webinars.php

White Papers
Register on the Trustwave website, at https://www.trustwave.com/whitePapers.php to view more detailed technical white papers about PCI DSS and other data security issues, including:

• PCI DSS Compliance for Merchants Accepting Payment Cards Through Multiple Channels
• Payment Card Data Security for the Restaurant Industry
• Payment Card Information Security for Higher Education
• Higher Education Best Practices Checklist
• Automated Compliance Scanning: Simplifying System Audits
• VPNs: The Remote Network Enabler of Choice for Today's Economy
• Patch and Configuration Management for the Enterprise
• Security Event Management: Keeping Up with Advancing Technology
• Wireless Security: Detecting Wireless Networks from the Wire

Winning the PCI Compliance Battle

Proof of Insurance
http://www.royalgroupservices.com/trustwave/


Helpful Links

PCI Security Standards Council - https://www.pcisecuritystandards.org/

PIN Transaction Security - https://www.pcisecuritystandards.org/security_standards/ped/index.shtml

Payment Applications Data Security Standard - https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml

PCI DSS- https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml 

Scan requirements for all merchants that have a pc- http://www.mastercard.com/us/sdp/merchants/merchant_levels.html

Demo Videos:
http://www.youtube.com/watch?v=4sy7M1sMo6E&feature=related