Search

Brian Pennington

A blog about Cyber Security & Compliance

Month

September 2012

Information Commissioner publishes guidance on cloud computing

The UK’s Information Commissioner’s Office (ICO) has published guidelines to on how business treat personal information in the cloud whether that is a private or public cloud.

The data protection regulator ICO is concerned that many businesses do not realise they remain responsible for how the data is handled whilst it is in the cloud.

This has resulted in the ICO publishing a guide to cloud computing, to help businesses comply with the law.

The guide gives tips including:

  • Seek assurances on how your data will be kept safe. How secure is the cloud network, and what systems are in place to stop someone hacking in or disrupting your access to the data?
  • Think about the physical security of the cloud provider. Your data will be stored on a server in a data centre, which needs to have sufficient security in place.
  • Have a written contract in place with the cloud provider. This is a legal requirement, and means the cloud provider will not be able to change the terms of the service without your agreement.
  • Put a policy in place to make clear the expectations you have of the cloud provider. This is key where services are funded through adverts targeted at your customers: if they’re using personal data and you haven’t asked your customers’ permission, you’re breaking data protection law.
  • Don’t forget that transferring data internationally brings a number of obligations – that includes using cloud storage based abroad.

Speaking as the guide was launched, author Dr Simon Rice, ICO technology policy advisor, said:

“The law on outsourcing data is very clear. As a business, you are responsible for keeping your data safe. You can outsource some of the processing of that data, as happens with cloud computing, but how that data is used and protected remains your responsibility.

“It would be naïve for an organisation to take the attitude that these guidelines are too much effort to simply store some data in a different place. Where personal information is involved, the stakes are high and the ICO has already demonstrated it will act firmly against those who don’t meet data protection laws”

.

Advertisements

RSA’s September Online Fraud Report 2012 including a summary of rogue mobile apps

In their September Online Fraud Report RSA reports on the activity of online fraudsters, a summary is below

Threats and risks in today’s mobile app marketplace

In terms of mobile security, some mobile application (app) platforms, such as Apple’s AppStore, are known to employ strict rules to which application developers are obliged to adhere.

Other mobile app platforms, such as Android’s Google Play, are more flexible with regards to mobile apps. While providing application developers with a programming platform that is optimized for convenience and ease-of-entry into the app marketplace, it is these very qualities that have made Android the most heavily targeted mobile operating system, with Android apps by far the most widely used vehicle for spreading mobile malware.

Apps are one of the driving forces behind today’s smartphone market. Their download to mobile phones makes them an attractive new attack vector for cybercriminals along with other mobile phone attributes: the shortened URL, low security awareness among users, and the ease of copying a mobile webpage’s layout for malicious purposes.

This risk extends to the corporate setting with companies increasingly adopting Bring- Your-Own-Device (BYOD) policies, in which employees’ devices double as platforms for both personal and work-related communications. Apps that intercept a mobile user’s email and phone communications for example, may gain access to corporate communications, as well.

Types of Rogue App Payloads

According to a research study on Android malware conducted by the Department of Computer Science at North Carolina State University, 86% of Android mobile-malware payloads are repackaged with legitimate apps and are not standalone, making their detection more difficult. The same study found that many others piggyback on genuine app updates to remain undetected.

The payloads these apps install after being downloaded to a device vary widely, and can include:

  • SMS Sniffers. Apps that covertly collect SMS text messages, including passwords sent to users’ handsets, and forward this information to a remote drop point. Some of these include other stealth features to avoid raising the user’s suspicion, for example, functionality that turns off the alarm sound when new text messages are received and hides all incoming messages
  • Premium dialers. Apps that install themselves on the user’s handset and start dialing phone numbers or sending dummy text messages to premium-rate service numbers. This type of operation requires the setup of a bogus merchant, along with a fraudulent merchant ID through which cybercriminals can collect funds unwittingly siphoned out of user’s accounts. Handset owners would only become aware of the scam when seeing their bill the following month
  • SEO enhancers. Apps that repeatedly access a certain website, or websites, to increase their rankings in search engine’s results
  • Ransomware. Apps that lock a user’s handset and demand payment from users in return for relinquishing control of the mobile device
  • Spyware. Apps that send the attacker or spy (via a remote drop point) information garnered from a victim’s device including GPS data, intercepted calls and text messages, and phone contacts
  • Botnet clients / Bridgeheads. Apps that communicate with a cybercriminal via a command & control (C&C) server. These may be used as infrastructure for further malware downloads, much like ready-made PC botnets whose infected systems await to download banker Trojans or other malware pushed from the C&C server. These payloads act as a bridgehead by giving the perpetrator an initial foothold on the compromised device. The payload opens a port on the device, and listens for new commands issued from the fraudster’s C&C point. Later on, an encrypted payload may be downloaded to the user’s device

Android apps and their exploitation

At the end of H2 2012, Google announced that the number of devices running Android has reached 400 million, representing 59% of the world’s smartphone market. And to date, Android’s open source code platform has led to the publication of over 600,000 mobile apps. Android’s source code is based on the Java programming language, and its ease of use and low publisher entry fee has made it the most widely targeted mobile platform by malware developers, and the most widely attacked by today’s Trojans. The increased risk for Android app users has already led several anti-virus companies to release AV software for Android-run devices.

A Secure Venue for Apps

The official venue for Android applications is called “Google Play” (formerly known as “Android Market”). By default, each handset running Android is configured to exclusively allow the installation of apps downloaded from Google Play, and to block installation of apps downloaded from any other venue. This is to ensure a minimal level of security.

Downloading apps from Google Play provides an extra security benefit to Android users, as the store provides a “Remote Application Removal” feature, which allows apps that are retrospectively identified by Google as being malicious to be removed from relevant users’ handsets.

Another important security feature added to Google Play is “Google Bouncer,” which scans new apps, acting as a gatekeeper to keep out those identified as malicious.

Despite Android’s default Google-Play-only settings, Android users can still choose to install apps from venues other than Google Play by manually changing their devices’ security settings. Aware of the security issues this may raise, Android users are presented with a warning message when selecting this option.

Android App Permissions

As a second security measure, prior to the installation of an Android app on most Android-based OSs, the app requests certain system permissions, all which have to be approved before the app can be installed on the device. Whereas legitimate apps normally request only one or two permissions, rogue apps are known to request a long list of permissions before installing themselves.

Currently, this is the main security obstacle for rogue Android apps, which some Trojan coders have managed to bypass through socially engineered schemes. For example, RSA has previously detected a mobile-malware app (SMS sniffer), which presented itself as security software. The app requested nine different permissions, including permission to boot the handset, change system settings, and send text messages. Unsurprisingly, the app was offered from a standalone domain not affiliated with any app store.

RSA’s Conclusion

Today, the payload app may remain on a device even after the host app (with which it was downloaded) has been removed. This makes initial detection and removal of the app from the app store that proffers it even more crucial.

As with PC-based malware, educating consumers to raise awareness of today’s mobile threats and urging them to take precautions against rogue apps, will be of paramount importance to mitigating mobile threats in years to come.

Phishing Attacks per Month

In August, 49,488 unique phishing attacks were identified by RSA, marking a 17% decrease from July. The bulk of this decrease is a result of fewer phishing campaigns launched against European financial institutions which have accounted for significant spikes in recent months.

Number of Brands Attacked

In August, 290 brands were subject to phishing attacks, marking a 20% increase from July. This considerable increase shows that cybercriminals are expanding their phishing targets wider, to new organizations and new industries not targeted in recent months. More than half of the brands affected by phishing in August were targeted by more than five phishing attacks.

US Bank Types Attacked

In the U.S. financial sector, nationwide banks experienced a 7% decrease in phishing attacks. However, brands in this segment continue to be most targeted by phishing attacks, hit by two out of every three attacks in August.

Top Countries by Attack Volume

In August, the UK continued to get hit by the majority of worldwide phishing attack volume for the sixth consecutive month, accounting for about 70% of all global phishing volume. The U.S. and Canada continued to remain second and third on the list.

Top Countries by Attacked Brands

In August, the U.S., UK and Australia were the top three countries whose brands were most affected by phishing, targeted by 45% of global phishing attacks during the month.

Top Hosting Countries

The U.S. hosted the vast majority of phishing attacks in August with 80%, followed by Canada, the UK and Germany.

Previous RSA Online Fraud Report Summaries:

  • The RSA August 2012 Online Fraud Report Summary here.
  • The RSA July 2012 Online Fraud Report Summary here.
  • The RSA June 2012 Online Fraud Report Summary here.
  • The RSA April 2012 Online Fraud Report Summary here.
  • The RSA March 2012 Online Fraud Report Summary here.
  • The RSA February 2012 Online Fraud Report Summary here.
  • The RSA January 2012 Online Fraud Report Summary is here.
  • The RSA December 2011 Online Fraud Report Summary is here.
  • The RSA November 2011 Online Fraud Report Summary is here.
  • The RSA October 2011 Online Fraud Report Summary is here.
  • The RSA September 2011 Online Fraud Report Summary is here.

.

PCI SSC’s insights on mobile, encryption and payment security following the North American community meeting

After the sixth annual North American Community Meeting in Orlando, Florida which was attended by over 1,000 stakeholders representing 460 organizations from 17 countries to discuss the PCI SSC summaries the key discussion topics as: –

  • Feedback on the standards in preparation for the release of the next version of the PCI DSS and PA-DSS in 2013
  • New guidance on secure mobile payment acceptance application development
  • Updates to the Council’s Point-to-Point Encryption (P2PE) program
  • Newly released guidelines for ATM security
  • The Council’s new training programs and professional qualifications
  • Updates from PCI Special Interest Groups on cloud, eCommerce and risk assessment

“The Community Meetings play an important part in bringing together PCI stakeholders to discuss the latest payment card security efforts, and we’re encouraged to see the continued growth of interest and participation in this initiative,” said Bob Russo, general manager, PCI Security Standards Council. “Gaining the feedback from our Participating Organizations is absolutely vital for us to develop new guidance on key topics such as mobile payment acceptance and ATM security, as well as in the on-going improvement of the PCI Standards. The input and discussion at this year’s meetings are especially important as we look to introduce the next version of the PCI Standards in 2013.”

“It is important for us to meet face-to-face with our stakeholders, not only to update them on the most recent developments, but also to have one-on-one interactions and personal conversations on the issues that matter most to them,” said Jeremy King, European director, PCI Security Standards Council. “We look forward to seeing more of our global counterparts in Dublin for the European Community Meeting on October 22-24, 2012.”

See you in Dublin next month.

Data Protection Advice for schools and just about everyone else

The UK Information Commissioner’s Office has released a report which gives practical advice on how to comply with the Data Protection Act.

The advice was prompted by a survey of 400 schools across nine local authority areas that showed that whilst awareness of data protection laws was generally good, schools need to pay more attention to complying with data protection law.

The survey showed 95% of schools provided some information to pupils and parents about what was done with personal information.

A third of schools with password-protected computer systems conceded the passwords were not necessarily strong enough and not changed regularly, with 20% admitting email systems were not secure.

Louise Byers, ICO Head of Good Practice, helped draft the report: “The survey results showed that whilst awareness of the law was broadly good, knowledge on how to comply with it wasn’t always there. In many respects that should come as no surprise – it’s not teachers’ area of expertise – and it is precisely what our report is aiming to address.

“I’d urge teachers and heads to take a look at our recommendations and make sure they’re complying with the law. The sensitive personal data that schools handle means it is crucial they get this right, and we hope the ICO’s report will help them achieve that.”

A summary of the main recommendations is below:

  • Notification. Make sure you notify the Information Commissioner of the purposes for your processing of personal data
  • Personal data. Recognise the need to handle personal information in line with the data protection principles
  • Fair processing. Let pupils and staff know what you do with the personal information you record about them. Make sure you restrict access to personal information to those who need it
  • Security. Keep confidential information secure when storing it, using it and sharing it with others
  • Disposal. When disposing of records and equipment, make sure personal information cannot be retrieved from them
  • Policies. Have clear, practical policies and procedures on information governance for staff and governors to follow, and monitor their operation
  • Subject access requests. Recognise, log and monitor subject access requests
  • Data sharing. Be sure you are allowed to share information with others and make sure it is kept secure when shared
  • Websites. Control access to any restricted area. Make sure you are allowed to publish any personal information (including images) on your website
  • CCTV. Inform people what it is used for and review retention periods
  • Photographs. If your school takes photos for publication, mention your intentions in your fair processing/privacy notice
  • Processing by others. Recognise when others are processing personal information for you and make sure they do it securely
  • Training . Train staff and governors in the basics of information governance; recognise where the law and good practice need to be considered; and know where to turn for further advice
  • Freedom of information (FOI)/ After consultation, notify staff what personal information you would provide about them when answering FOI requests.

Find the full report here.

.

Feedback requested from PCI community on best practices to help prevent card data compromise at ATMs

The PCI SSC is seeking feedback from Participating Organizations (POs) on draft ATM security guidelines. The draft information supplement provides best practices to mitigate the effect of attacks to ATMs aimed at stealing PIN and account data, a direct response to stakeholder feedback for guidance on ATM security.

Participating Organizations have until November 13, 2012 to review and comment on the ATM Security Guidelines Information Supplement, which is slated for final publication later this year.

PIN and account data present in ATMs has become a growing target for criminals who use this stolen information to produce counterfeit cards for fraudulent transactions, primarily ATM cash withdrawals. Purchases with PIN at the point of sale and purchases without PIN in card-not-present environments are also other avenues of fraudulent card activity.

PCI Standards currently address ATM PIN pads, but not the ATM as a whole. In the absence of a global industry standard for securing ATMs, the Council has developed a set of compromise-prevention best practices based on existing standards from a number of industries, including IT, security, payment card and ATM that stakeholders can leverage in their ATM security efforts.

The draft ATM Security Guidelines Information Supplement provides an introduction to ATM security and outlines best practices that address the software, hardware and device components of the ATM. The intent is for the final document to guide ATM manufacturers, hardware and software integrators, and deployers of ATMs in the secure development, deployment and maintenance of ATMs.

We rely on industry feedback to develop PCI Standards and resources, said Bob Russo, general manager, PCI Security Standards Council. By sharing an early version of the guidelines with the PCI community, we re aiming to ensure these best practices reflect the key challenges and areas of concerns when it comes to addressing ATM security. Specifically, we encourage ATM manufacturers and software vendors to provide their input, as experts in the space and as those will be applying these guidelines in their everyday business.

.

PCI Security Standards Council releases best practices for mobile software developers

During this week’s PCI SSC US Community meeting a demonstration of a Mobile attack highlighted the need for more secure development practices in the mobile payments space.

The demonstration coincided and supported the release of the new guidelines the PCI Mobile Payment Acceptance Security Guidelines which offer software developers and mobile device manufacturer’s guidance on designing appropriate security controls to provide solutions for merchants to accept mobile payments securely.

The demonstration of the top mobile attacks was done by Nicholas J. Percoco, senior vice president of Trustwave’s SpiderLabs, and showed the threats to the security of payments over mobile acceptance devices, including malware and rootkits, jailbreaking vulnerabilities and SSL-man-in-the-middle attacks.

It is important that a best practice guide be developed, by the industry, to educate mobile app developers on methods of securing commerce transactions and risks of not doing so.” said Percoco.

The PCI SSC formed an industry taskforce in 2010 as part of a dedicated effort to address mobile payment acceptance security. Since then, the Council has released guidance on how merchants can apply its current standards to mobile payment acceptance by addressing mobile applications with the Payment Application Data Security Standard (PA-DSS), and leveraging the PIN Transaction Security (PTS) and Point-to-Point Encryption (P2PE) standards to accept payments on mobile devices more securely.

The guidance for developers is the next piece of the Council’s work in this area. The document organizes the mobile payment-acceptance security guidance into two categories: best practices to secure the payment transaction itself, which addresses cardholder data as it is entered, stored and processed using mobile devices; and guidelines for securing the supporting environment, which addresses security measures essential to the integrity of the broader mobile application platform environment.

Key recommendations include:

  • Isolate sensitive functions and data in trusted environments
  • Implement secure coding best practices
  • Eliminate unnecessary third-party access and privilege escalation
  • Create the ability to remotely disable payment applications
  • Create server-side controls and report unauthorized access

“Applications are going to market so quickly – anyone can design their own app today that can be used to accept payments tomorrow,” said PCI SSC Chief Technology Officer Troy Leach in his presentation to PCI CM attendees. “It’s our hope that in educating this new group of developers, as well as device vendors on what they can do to build security into their design process, that we’ll start to see the market drive more secure options for merchants to protect their customers’ data.”

The council has announced that in 2013 they will be releasing further guidance for merchants to help them leverage mobile payment acceptance securely, while continuing to collaborate with industry subject matter experts to explore how card data security can be addressed in an evolving mobile acceptance environment, and whether additional guidance or requirements must be developed.

.

The average cost of a breach event is $7.2 million or $214 per compromised record

In promoting their Internal Security Assessor Training in Dublin the Payment Card Industry Security Standards Council (PCI SSC) sent an email quoting the Verizon Data Breach Investigation Report 2011 statistics:

  • The average cost of a breach event is $7.2 million
  • The average cost per compromised record is $214

The reason they were using the statistics in their promotional email was because they believe in the value of their Internal Security Assessors qualification and with the PCI SSC’s European community meeting in Dublin next month they are encouraging people to register and learn the skills required to improve PCI DSS compliance.

The promotional wording for the course is “Enhance your organization’s data security with an investment in training this year – and realize these benefits:”

  • Improve your organization’s understanding of PCI DSS
  • Facilitate interaction with a QSA for your organization
  • Enhance payment card data security and manage compliance costs
  • Simplify year-round compliance efforts

The Dublin dates are 18-19 October 2012.

For more information on the course and to register click here, or email training@pcisecuritystandards.org with questions.

.

Almost 50% of organizations report 10 or more significant data breaches a year

Ponemon have revealed the results of a Co3 Systems sponsored survey into Data Loss Management. Ponemon Institute polled more than 100 influencers in the privacy and data protection community across the US.

Key findings of the survey were:-

  • almost 50% of organizations experience ten or more data loss incidents annually that meet the legal criteria that require tracking and reporting
  • more than 60% of the organisations surveyed employ manual, repetitive and time intensive processes to manage these incidents across tasks like notifying customers and informing regulators

“Not only have the number of data breaches reached epidemic proportions, but organizations are hemorrhaging records at staggering volumes,” said Dr. Ponemon. “To start the response process at day zero and square one is not only a recipe for disaster, it is irresponsible business. Privacy has become a hot button issue for everyone from citizen groups to elected officials, and one can only expect protections and regulations to increase. Organizations need to evaluate ways to automate their response process, and tools like Co3 have arrived at just the right time.”

“The Ponemon survey findings, with regards to data breach response and management, highlight the very real challenges firms are grappling with,” said John Bruce, CEO at Co3 Systems. “Organizations realize that the opportunities for loss and exposure — by their own hand or through partners and connected organizations — far outnumber the points of control and protection they can implement. It’s not surprising that more than one third of those surveyed have tried to create their own automated systems to cope with the implications of a breach. Our knowledgebase of regulations and industry best practices produce instant incident response plans based on the unique characteristics of a breach, and our easy-to-use project management interface ensures a timely, decisive and accurate response by any team.”

.

Rubbish causes a breach of the Data Protection Act and a £250,000 fine

Scottish Borders Council employed an outside company to digitise their employee records but when the pension records of several hundred ex-employees were found in recycling bins the Information Commission’s Office began an investigation for a breach of the Data Protection Act.

Following the investigation the Information Commissioner has fined the Council £250,000 for not seeking appropriate guarantees on how the personal data would be kept secured and dealt with.

It is believed more than 600 files were deposited at the recycle bins, containing confidential information and, in a significant number of cases, salary and bank account details. The files were spotted by a member of the public who called police, prompting the recovery of 676 files. A further 172 files deposited on the same day but at a different paper recycling bank are thought to have been destroyed in the recycling process.

Ken Macdonald, ICO Assistant Commissioner for Scotland, said:

“This is a classic case of an organisation taking its eye off the ball when it came to outsourcing. When the Council decided to contract out the digitising of these records, they handed large volumes of confidential information to an outside company without performing sufficient checks on how securely the information would be kept, and without even putting a contract in place.

“It is only good fortune that these records were found by someone sensible enough to call the police. It is easy to imagine other circumstances where this information could have exposed people to identity fraud and possible financial loss through no fault of their own.

“If one positive can come out of this, it is that other organisations realise the importance of properly managing third parties who process personal data. The Data Protection Act is very clear where the responsibility for the security of that information remains, and what penalties await those who do not comply with the law.”

Who else has the information commissioner caught this year? Find out here.

.

Four Things You Need to Know About Risk Analysis

Guest Blog: IDexperts Chris Apgar.

Every privacy professional knows that risk analysis is a foundation for successful information privacy and security, just as flossing your teeth is a foundation for good oral health. If you’re in healthcare, you also know that risk analysis is one of the five core Office for Civil Rights (OCR) “culture of compliance” requirements, and a prerequisite to receiving “meaningful use” dollars for implementing electronic health records (EHR). But what you may not know, according to nationally recognized information security expert and former HIPAA Compliance Officer Chris Apgar, is that compliance is not the biggest reason for conducting ongoing risk analysis. The biggest reason is that it can save your business.

OCR audits are proceeding, and failure to conduct risk analysis can result in a finding of “willful neglect” with penalties up to $50,000 per incident and up to $1.5 million per calendar year for the same type of violation (and any such finding will typically involve multiple types of violations). That risk, alone, justifies the cost of conducting risk analysis. A thorough risk analysis also provides a strategic roadmap for security spending, but Apgar says that even now, when he speaks to groups about medical data privacy, only about 1/3 of all healthcare organizations that are not seeking “meaningful use” dollars indicate that they’ve conducted risk analysis, and he points out that this is dangerous because by deferring the analysis, they may fail to identify other risks such as lawsuits, civil penalties, and loss of reputation that could damage or destroy their business.

Here are three other things Chris Apgar says you need to know risk analysis:

  • Confidentiality is not enough. The three pillars of security are confidentiality, availability, and integrity, and risk analysis needs to account for all of these. Yes, you want to prevent data breach, but that’s not enough. For example, what happens if a patient is in critical care, systems go down, and doctors lose access to critical information they need to make medical decisions?  Data corruption can be even more serious because if doctors unknowingly make bad healthcare decisions based on corrupt information, lives can be lost.
  • Technical security is not enough. Apgar says that, too often, when an organization looks at risks, they look only on the digital side, but PHI risks extend far beyond technical infrastructure. You need to look at every place where PHI lives, in any form, and everyone who touches it. For example, encryption can mitigate risk  in case of a security related incident involving electronic records, but  you can’t encrypt paper.  So if paper records are lost, by definition, that’s a security incident and potentially a reportable breach. People and process risks also have to be assessed as part of the security plan. One privacy officer that Apgar worked with pointed out that he and other compliance professionals in the organization had to be considered as organizational assets and as liabilities, because at that time, they were the only ones who knew how to respond in case of an incident, and if they were unavailable, the organization would be at risk.
  • There’s more than one way to become a covered entity. A new Texas healthcare privacy law goes into effect this month. Apgar says that, in addition to non-compliance penalties over and above the federal, it has a broader definition of covered entities.  Under the Texas law, if an organization handles any sort of electronic healthcare information, no matter its role in the healthcare system, it is covered by the new privacy requirements and considered a covered entity. So, for example, a small dental practice that transmits HIPAA covered transactions in Texas is now a covered entity under Texas law.  In addition, business associates and subcontractors could now face non-compliance fines from both OCR and state of Texas. Other states, including California and Massachusetts, also have high levels of regulation around healthcare information. A thorough and ongoing risk analysis program is necessary to keep organizations of all sizes abreast of new risks and requirements at state and federal levels.

Apgar has a number of practical recommendations for conducting risk analysis.

  • Successful risk analysis begins with a thorough inventory that accounts for all assets: digital, physical, and human. He points out that you need that inventory, anyway, to create a disaster recovery plan, and that keeping that inventory current makes the initial risk analysis and updates relatively simple because you have a baseline to work from.
  • Think of things inside the organization that can hurt you. “Threats” are unpredictable outside factors such as natural disasters and hackers that require response plans, but there are “vulnerabilities” that you can address to head off trouble. For example, you can help preventing network attacks by putting in place a process to ensure security patches are always kept up to date.
  • The risk analysis needs to rate risks both in terms of likelihood and in terms of potential harm or impact. For example, tsunamis are unlikely in Oklahoma so they don’t need to be part of an Omaha hospital’s disaster recovery plan, and unauthorized access to one patient record showing on a computer screen is likely to cause far less damage than a stolen computer full of patient records in lab’s business office. Once you’ve made a reasonable assessment of the likelihood and potential impact, it will become clear how best to spend your security budget and resources.
  • Don’t stop with the risk analysis. Meaningful use requires risk analysis, documentation, a mitigation plan, and implementation of a risk management program. Whether or not your organization is seeking meaningful use dollars, knowing about a risk offers little protection if you don’t act on the knowledge and implement steps to manage risk throughout the year.
  • If you bring in experts to conduct a risk analysis or to help your staff conduct one, look for someone who has done this before in healthcare and who has a track record with your type of healthcare business. Make sure their products and services address more than just technical security, and check references, of course, but also ask colleagues about their reputation. Word travels fast in the healthcare industry, and word on the street may tell you things that you won’t find out in a reference check.

Chris Apgar says the most critical thing to realize about risk analysis is that it stretches beyond what the regulations require. “There are so many other risks: the risk of being sued, of losing your practice, of causing harm to your patients. Yes, doing risk analysis costs time and money, but not doing it is a good way to lose more money or lose your business.”

.

PCI Security Standard Council releases summary of feedback on PCI standards

The Payment Card Industry Security Standards Council releases a summary of feedback from the PCI community on the PCI Security Standards. The document highlights key themes coming out of the Council’s formal feedback period on version 2.0 of the PCI DSS and PA-DSS, in preparation for the next release of the standards in October 2013.

As part of the open standards development process for the PCI DSS and PA-DSS, the PCI Security Standards Council (PCI SSC) solicits input on the standards from its global stakeholders through a variety of avenues, including a formal feedback period. More than half the input received during the formal feedback period originated from organizations outside of the United States.

This industry feedback drives the on-going development of strong technical standards for the protection of cardholder data, providing more than 650 Participating Organizations, including merchants, banks, processors, hardware and software developers, Board of Advisors, point-of-sale vendors, and the assessment community the opportunity to play an active role in the improvement of global payment security. Payment security stakeholders can use the summary document to better understand the Council’s approach to reviewing and categorizing the feedback, key trends and themes, and how the feedback is being addressed.

The feedback was received by the Council across the following five categories:

  1. Request change to existing requirement/testing procedures (34%)
  2. Request for clarification (27%)
  3. Request for additional guidance (19%)
  4. Feedback only – no change requested (12%)
  5. Request for new requirement/testing procedure (7%)

Over 90% of the feedback was on the PCI DSS, the foundation for the Council’s standards, with more than half specific to the following topics:

  • PCI DSS Requirement 11.2 – Suggestions include prescribing use of specific tools, requiring ASVs to perform internal scans, and defining what constitutes a “significant change”.
  • PCI DSS Scope of Assessment – Suggestions for detailed guidance on scoping and segmentation.
  • PCI DSS Requirement 12.8 – Suggestions include clarifying the terms “service provider” and “shared,” and providing more prescriptive requirements regarding written agreements that apply to service providers.
  • PCI DSS SAQs – Suggestions for updating the SAQs; they are either too complex or not detailed enough.
  • PCI DSS Requirement 3.4 – Suggestions for further clarification and guidance since encryption and key management are complex requirements, and truncation/hashing & tokenization is not a convenient method to store and retrieve data
  • PCI DSS Requirement 8.5 – Suggestions for updating password requirements, including expanding authentication beyond just passwords; current password requirements are either too strict or not strict enough, be either less prescriptive or more prescriptive.

These trends and other highlights are provided in the summary document, including main PA-DSS feedback themes, breakdowns of the types of organizations that participated and geographic regions represented.

“Industry feedback is the lifeblood of the PCI Standards,” said Bob Russo, general manager, PCI Security Standards Council. “As the PCI community continues to expand across industries and geographies, the Council relies on its expertise to drive the evolution of the standards. I want to personally thank all who have contributed to the on-going development of these critical resources for payment security.”

.

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: