SecureCompliance « SecureThinking

Tuesday, July 20, 2010

CISOs to the Rescue!

By Jill Knesek, Chief Security Officer, BT Global Services

There aren’t many times I check in on the trade publications and see an article that really hits on the issues faced by the C-level audience in the security sector. Frankly, we’re an unusual bunch, with very specific interests, issues, and concerns. But recently, I saw an article by Ernie Hayden at searchsecurity.com that got to the heart of some of the compliance issues that I know I face and I’m sure you grapple with, too.

Approaching compliance from the standpoint of managing processes, Hayden outlines five key propositions that can help guide decision-making and apply as equally to PCI as to NERC. His top picks are:

Your fundamental obligation to the company is to protect data and prevent loss
You should know the ins and outs of the regulations your organization is held to
View training and awareness as key components of your compliance strategy
Understand the root cause of any issues related to compliance
The organization should be kept under constant pressure to be in compliance

To read Hayden’s entire article – “How to manage compliance as Chief Information Security Officer (CISO)” — click here.

And if you’re a C-level or senior security officer in the Chicago area and would like to continue this conversation over dinner, I’ll be hosting a BT Security Roundtable in Chicago on July 28. To learn more about the dinner, please contact our Chicago-area managed security solutions specialist, Kurt Luporini.

Wednesday, May 5, 2010

The States Take Action: Washington Becomes the 5th State to Give Data Privacy Some Legislative Teeth

By Sushila Nair, Product Manager, Managed Security Solutions Group, BT Global Services

In 2005, California’s Assembly Bill 1950 (AB 1950) became active, requiring a business that owns personal information about a California resident to “implement and maintain reasonable security procedures and practices to protect personal information from unauthorized access, destruction, use, modification or disclosure.” Since then, this law has been used as a basis for private and class action lawsuits and, it would seem, a model for other states’ legislation.

Similar legislation has been passed in other states, including Massachusetts, Minnesota, Nevada and, most recently, Washington state. HB 1149, which takes effect on July 1, 2010, provides issuing banks a legal mechanism to collect the costs to reissue payment cards after a payment card security breach. While there is no explicit requirement for organizations to take reasonable care to avoid a breach, companies that fail to do so may be liable to pay for re-issuance costs after a breach.

Of all these laws, the Massachusetts law is regarded as being the most comprehensive and, not surprisingly, implementation has been delayed many times; currently, the deadline for compliance to Mass. 201 CMR 17 has been extended to May 1. The law clearly calls for the need to discover and protect sensitive data in a manner that is absent from other laws that are being passed; but it no doubt will become a template for similar legislation elsewhere.

A federal law mandating security controls is missing, but it’s worth noting that in the case of a large scale security breach, the FTC has taken action by claiming that organizations have engaged in “unfair practices” in violation of Section 5(a) of the Federal Trade Commission Act, 15 U.S.C § 45(a). The FTC said it was unfair for the company, TJX, to collect private credit card information from consumers and fail to use adequate security procedures to protect it. TJX must obtain audits by independent third-party security professionals every other year for 20 years as a result of the FTC’s action. The definition of “adequate security” is, however, not clearly defined by the FTC, but it is fair to assume that PCI DSS forms a framework which can be used to measure an organization against.

With different states mandating various forms of security controls on storing sensitive information, organizations will obviously be required to comply with multiple sets of “reasonable security” requirements for each state where they have customers, a factor that will be confusing and expensive. The focus will center on one set of security controls and, love it or hate it, PCI DSS undoubtedly is being focused on as providing this framework.

What becomes an interesting part of this debate is whether or not this is the right direction for the United States to be taking for credit card security. Elsewhere in the world, the focus has been on increasing the security of credit cards by introducing smart cards and requiring secondary authentication for online banking. Half the world’s credit card transactions occur in the U.S., and while smart cards do not reduce card fraud, it’s a step in the right direction to introduce security into payment systems that were never really designed with security in mind.

As we struggle to get companies to introduce more effective controls around the storage and transmission of personal data, the question becomes — should we also be focusing on strengthening the processes that use that data to prevent it from being used without additional authentication. It is likely that banking regulators will revise their guidelines and start to issue stricter guidance, which in turn will prompt banks to offer better authentication mechanisms to protect consumers. But that needs to follow through to online merchants and the login behind credit card transactions — because let’s face it, the entire process seems to be quite broken.

Monday, March 29, 2010

Missing elements in PCI DSS

By Sushila Nair, Product Manager, Managed Security Solutions Group, BT Global Services

It is interesting to note that chip and pin was missing from the study initially done by the PCI council in 2009 on emerging technologies and yet is mentioned specifically by Bob Russo during a panel discussion at RSA. Key Management Insights recently posted this to their blog:

Bob Russo, General Manager of PCI Security Standard Council, boiled it down to: “There needs to be a mind shift from just compliance to security [since] compliance is a byproduct of good security.” And when it comes to PCI DSS, Russo added, “PCI DSS is the baseline.” Russo hinted at some of the clarifications coming in the PCI DSS update in October 2010. He identified three of the technologies which are likely to receive clarification as:

Chip & PIN technology
End-to-end encryption
Tokenization

The focus on new technology, though not a panacea, is an acknowledgement that our current methodology for securing payment data is difficult to secure. Retail sectors, which operate on tight profits, are struggling to have the in-house expertise to put the right controls in place to protect the data they house.

Given that Payment card data was stolen in 84 percent of the 285 million security breaches recorded in 2008, according to the most recent Verizon Business Data Breach Report, the payment card industry realizes that something needs to be done. Security breaches are ever increasing and if the industry does not take action, then it is likely that the federal government will impose additional regulations.

The focus on continuous control monitoring is key to understanding what your security posture is. While it is impossible to have impenetrable security, it is critical to be monitoring your network so when a breach does occur, the correct action can be taken.

Undoubtedly, the stakes of not complying with PCI-DSS are rising. Companies that don’t take PCI-DSS seriously are exposing their customers and themselves to an unacceptable business risk, and their cost of doing business will surely rise to cover the net impact of breaches. The real question is whether the costs will rise in a controlled fashion as companies put in place best practices, such as outsourcing, to enable their security to be in the hands of seasoned experts — or if businesses will allow costs to spiral as they pay for fines, compensation, and remedial activities in response to data breaches.

Thursday, February 18, 2010

Virtual Currencies – The changing world of online payments

By Sushila Nair, Product Manager, Managed Security Solutions Group, BT Global Services, PCI QSA, CISSP, CISA, CISM, BS 7799 Lead Auditor

While our real economy still struggles, the virtual economy is flourishing. In fact, some experts predict the virtual goods in the United States could be worth up to $5 billion in the next five years.

Virtual currency is used for purchasing virtual goods. However, the question is, will virtual currency go beyond the world of virtual goods and into the real world? Providing the opportunity for people without bank accounts, which includes the majority of world’s population, to buy virtual currency and then use it for online purchases is an interesting concept.

Virtual currency was recently recognized by the Korean courts, giving people the right to sell virtual currency for real money. Venezuela is pushing the Sucre, which won’t be printed or coined. Instead, it will be used solely as a virtual currency to manage debts between governments.

Why virtual currencies? Because the benefits are bountiful. Consumers will be able to buy the virtual currency in stores or by using their credit card or bank account.

Gaming companies, startups and social networking companies have all been clamoring to offer virtual currencies. The company that becomes the standard de-facto web currency stands to make an enormous amount of money on enabling transactions globally and for micro-payments. Virtual currency and virtual goods remain among the most interesting and potentially the highest growth sectors for 2010.

Facebook could take the lead — PayPal, which has aimed to be the abstraction layer between the payment process and the merchant, is the biggest online payment company. However, the company is just beginning to move beyond the U.S. dollar. Facebook, on the other hand, has been working on a payment service which would introduce Facebook credits that would act as a universal currency on its platform. Facebook is currently working to create applications in which users pay for virtual goods in Facebook credits, enabling Facebook to charge a fee based on selling its virtual currency.

Sizing up the market — The virtual goods market in the United States is estimated anywhere between $1 and $2 billion for 2010. In Asia, the virtual goods market has already hit $5 billion and is rapidly growing. Virtual goods range from virtual gifts such as digital bottles of champagne that users can give online in Facebook to in-game weapons users can buy so they can inflict more damage on other gamers.

Gaming sites, such as the teen site, Neopets, are using this model to cater to minors who don’t have credit cards or bank accounts.

It may seem logical that with Facebook Connect, the social networking site could offer virtual currency to simplify micro-payments, eliminating the reliance on credit card transactions and reducing the per transaction cost. The extension from being a currency for virtual goods to smart phone applications and other “real” goods is not a large leap.

Since PayPal failed to create a virtual currency, it isn’t surprising to see eBay, which owns PayPal, introduce eBay bucks, enabling consumers to buy real goods.

Real need for global secure payment systems — As globalization becomes the reality of everyday life, there is no doubt that payment systems need to change. Micro-payments and varying currencies have posed challenges in a world that is becoming increasingly cashless. Since credit cards were created for face-to-face transactions, organizations have been struggling to make them secure for online transactions. This is proof that there’s a real need for global secure payment systems with centralized access into an account.

So, can virtual currency move past the virtual world and focus on providing a new payment system, one that is secure and enables micro-payments, global and mobile transactions?

I am interested in your thoughts. Feel free to leave a comment below.

Friday, February 12, 2010

Are you driving yourself insane with compliance?

By Pete Russo, Senior Marketing Manager, BT Global Services

Is compliance enough for your organization to be secure? BT’s Jason Stradley recently wrote in CSO magazine how companies confuse a completed compliance checklist with ironclad security. Interestingly, Stradley says, “… compliance is a poor excuse for security”:

Approaching this from the direction of building specific solutions or groups of solutions to answer each compliance requirement will ultimately lead to an overall security posture that is lacking basic elements and is inherently insecure. Such an approach may create a security function that is more reactionary than it was prior to having the regulatory compliance variable factored into the mix. This leads us to the undeniable realization that while a byproduct of security is compliance, the reverse couldn’t be further from the truth. Given that realization, hopefully we can all be somewhat in agreement that compliance is a poor excuse for security!

If you need evidence, look at the Heartland Payment Systems breach. This major breach has taught us that compliance alone is not enough to stop an attack. While Heartland was compliant with the PCI DSS requirements, the company still experienced the biggest breach ever involving payment card data.

Clearly, compliance is not enough. As more organizations accept this fact, we must look at how we can accomplish a comprehensive security program that is a strategic function of an organization. Here’s what Stradley recommended:

Develop a long term plan or “road map” for information security within your organization and include provisions for the known compliance requirements
Work closely with your senior business executives as you create this “road map,” so that they can understand where you are going, how it will affect their part of the operation, and it will give those business leaders an opportunity to provide you with better information to build it right the first time
Share the vision of your “road map” with your entire security organization and empower them as evangelists of that vision
To the extent that your are able, plan for potential future compliance requirements in your road map
Think of these potential new requirements as you build the various security capabilities within your organization. Try to build in the ability to adapt to new or more stringent compliance requirements without major upheavals to current processes, procedures and controls in place

By following these recommended steps, your security team will become less reactionary and more proactive. This will enable your security programs to become more valuable to your enterprise and a true strategic partner to the business.

Leave us a comment and let us know your thoughts.

Tuesday, February 9, 2010

Guest Post: PCI Compliance is still a myriad of tough choices on the ‘journey’ towards compliance

By Terry Ramos, Vice President of Product Marketing, Qualys, and co-author of “PCI Compliance for Dummies”

For organizations that process, store or transmits credit card data, achieving PCI compliance is causing them to evolve from using a periodic security checklist to employing a continuous process to achieve and maintain a state of security and compliance. For the security practitioners, this has certainly been a great way to connect with the rest of their organization and explain the risks related to data compromise. However, now we have the challenge of determining what steps we need to take to meet the compliance requirement while making our networks and systems secure as required.

The PCI Security Standards Council recently released the Prioritized Approach to pursue PCI DSS 1.2 compliance with its six milestones. Any vendor who provides some sort of PCI compliance-related solution will no doubt be working to implement this approach into their solution in the near future, if they have not done so already. The prioritized approach is a roadmap to meet PCI compliance, but all requirements must still be met.

Although many examples can be drawn upon in the 12-requirement structure, let’s examine Requirement 6 — Develop and maintain secure systems and applications. And more specifically, let’s look at PCI DSS Requirement 6.6.

For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:

Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
Installing a web-application firewall in front of public-facing web applications

Prior to the release of the final DSS, this was probably one of the most discussed new requirements that merchants and service providers would need to comply with. Initially, it was thought that the requirement would include all three — manual application assessment, regular use of automated assessment tools and installation of a web application firewall. This is in addition to the requirement for a code review before a custom application goes into production and whenever any changes are made.

In a perfect world where resources are truly limitless, an organization would do all three and would always implement a layered or defense-in-depth approach. However, “all of the above” is typically not a practical option for most organizations because trying to implement all three elements often brings other complexities, not to mention an increase in cost and resource requirements.

So let’s take a quick look at the type of analysis typically done when we are forced to choose one method over another. The first option is a manual web application review and assessment. Assuming you select a reputable professional services organization, this is a good option since it is likely to proactively catch the flaws in an application before cardholder data is compromised. This is especially true if the flaws are complex, requiring a sort of connect-the-dots approach, and should be performed just prior to the application being put into production and made publicly available. For this and other reasons, a competent human can often find flaws that an automated solution cannot. However, this option is more costly, especially when an application frequently changes. The testing procedure does allow for this assessment to be performed by a qualified employee of the company who is independent of the web development team. Certainly, this makes cost much less of an issue, but typically such resources are scarce within organizations.

An alternative to the manual web application assessment is to use an automated tool or service. Only recently has this become a more viable option, as web application assessment tools have largely required a human with advanced knowledge of web application security to tune them during the assessment of optimal results. A few service-based or cloud-computing options have emerged recently for automated web application assessment. For an organization that does not have the in-house expertise and needs to perform these web application security assessments on a regular basis, these services are a good option and more cost-effective as compared to the manual approaches discussed earlier.

The service-based approach allows for the automation of repeatable techniques used to identify the most prevalent vulnerabilities, identifies vulnerabilities of syntax and semantics in custom web applications, performs authenticated crawling, profiles the target application, and ensures accuracy by reducing false positives and false negatives through automated testing. Nonetheless, there is no “silver bullet” to detecting web application vulnerabilities. Even when using an automated solution, there is still a need at times to perform source code analysis, manual assessment or on-site penetration testing.

The third option is to deploy a web-application firewall (WAF) in front of all publicly facing web servers. This is also a fairly new technology, and it can be a good, cost-effective option for an organization with a small number of web applications that are not overly complex and dynamic or don’t process a high volume of transactions. However, the technology and the hardware it runs on are relatively expensive and as best practice, it is not recommended to deploy a large number of web applications behind a single WAF. In addition, it can be quite challenging to properly configure a WAF to detect and block all malicious traffic that the PCI requirement mandates without breaking some critical functionality along the way. And with the current move towards cloud computing for all types of applications, the downsides to deploying a WAF are further amplified. A new option is to combine the benefits of web application scanning to dynamically update and configure the WAF to block for new threats as the application changes.

Finally, with all these tough choices on the road to PCI compliance, organizations of all sizes really need to look at compliance holistically rather than trying to solve each requirement independently with decisions based solely on which option is least costly. Organizations need to understand which solutions will meet their needs and partner with providers who can help them meet the PCI DSS requirements effectively.

Thursday, February 4, 2010

Data breach disclosure in the USA: An emerging framework around data security

By Sushila Nair, Product Manager, Managed Security Solutions Group, BT Global Services, PCI QSA, CISSP, CISA, CISM, BS 7799 Lead Auditor

On July 1, 2003, the ground-breaking California Security Breach Notification Law went into effect. For the first time, organizations were forced to reveal a security breach and report the potential acquisition of personal information by unauthorized entities.

Today, while 45 states have data breach notification laws, none of the laws are identical. This leaves companies struggling to comply with a variety of requirements that vary, such as the notification period and any exclusions surrounding encrypted data or paper-based records. Defining sensitive data and knowing where sensitive data resides remains challenging for organizations. While many states are taking steps to develop laws, we still lack a cohesive national law that is applicable across the board.

Here is what some states are doing:

The original law from California focused on identity information – name and social security number, driver’s license number or financial account number. The California legislature expanded its law to also include breaches of medical data. That expansion became effective Jan. 1, 2009, and other states have followed suit. In the first five months of 2009, California authorities were notified of 823 healthcare data breaches.

California demands reasonable security measures to be in place to prevent loss or theft of personal data, but there is no prescriptive definition of what constitutes “reasonable security.” Similar legislation has appeared in other states, including Massachusetts.

Massachusetts moved to introduce an even tougher law around data loss prevention and gave shape to a more prescriptive approach, which has been loosely defined as reasonable security. Objections to Massachusetts’s 201 CMR 17 have been raised about the cost involved, especially with small companies that need to comply with the security controls required by this legislation. The law has been delayed three times, and the underlying concern has been that the security controls are too onerous for small companies. Every organization that collect, owns or licenses personal information about a resident of the Commonwealth shall be in full compliance with 201 CMR 17.00 on or before March 1, 2010.

Most recently, in October 2008, Nevada became the first U.S. state to enact a law that specifically requires encryption for all external electronic transfers of customers’ personal information. The requirement for encryption was a move away from the standard non-prescriptive requirements of most of the disclosure laws, which generally require organizations to implement reasonable security measures. The move by Nevada and Massachusetts to define required security controls will in all likelihood be imitated by other states. It is likely the same domino effect that happened with disclosure laws will be repeated with data loss prevention legislation.

The liability involved in losing personal details can be intimidating. Legal action involving the FTC has cost companies six figures in penalty costs, and Visa, MasterCard and AMEX can also impose six figure penalties. In addition, there can be legal action from state Attorney Generals, and the cost of notification rises each year. In the wake of the seemingly endless stream of breaches, it is becoming more complex to comply with the increasing range of laws designed to enforce stricter security controls around the storage of personal data.

In the United States, there have been several attempts to unify the patchwork of state laws, but not one of these attempts to introduce a national law has been successfully passed in the Senate. A national data breach notification bill was passed in the U.S. House of Representatives on December 8, 2009, and will be enforced by the FTC. However, concerns have been raised about the lack of jurisdiction the FTC has to enforce regulations on government, banks, savings and loan institutions, the insurance industry, and nonprofit organizations.

I have no doubt that in 2010, we will see the introduction of a federal law surrounding data disclosure. A federal law will help ease the compliance burden by unifying requirements, though ensuring the law has teeth may be challenging. Generally federal laws tend to be less onerous than state laws and may in fact result in less stringent requirements.

And I believe that data loss prevention laws — laws that require organizations to have security controls in place as a condition of collecting personal data — will become a hotly debated topic internationally. Increasing legislation around security controls and private data will grow in the face of the increasing number of breaches worldwide.

Tuesday, December 8, 2009

Why the Adoption of Chip and PIN Technology is Inevitable

Sushila Nair, Product Manager, Managed Security Solutions Group, BT Global Services

Credit card usage is growing annually and the figures reveal some very interesting trends. In 2006, the United States Census Bureau determined there were nearly 1.5 billion credit cards in use in the U.S., creating a similarly large opportunity for credit card fraud. In fact, credit and debit card fraud is the #1 fear of Americans in 2009, superseding fears about terrorism, personal safety and even the consequences of the global financial crisis. (Source: Unisys Security Index: United States, March 2009).

The response in many parts of the world where card issuing companies bear financial responsibility for credit card fraud is to roll out chip and PIN technology, also known as “EMV” after the three companies that originally cooperated to develop the standard — Europay, MasterCard and VISA. Twenty-two countries have already adopted this technology, including most of the European Union, Mexico, Brazil, and Japan, with another 50 countries in various stages of adoption during the next two years, including China, Canada and India.

But so far in the U.S., there has been little incentive to follow suit. The card issuers cite the enormous cost of rolling out chip and PIN technology, estimated to be around $5.5 billion, and they rest safe in the knowledge that it is the merchants in the U.S., and not the card issuers, who are responsible for the financial costs of credit card fraud.

But is the United States being short sighted in its reluctance to adopt chip and PIN technology? Have other countries that have adopted this technology actually seen a reduction in the amount of fraud?

So far, there appears to be mixed results. In France, which introduced a chip-based PIN system in 1993, losses halved in the first year and counterfeiting fell by 78 percent. By 1996, counterfeit charges had effectively been eliminated, according to the French national bank card association, Cartes Bancaires, and by 1998, banks were saving the equivalent of 0.1 percent of sales volume on fraud alone. But in the UK, fraud has continued to rise, but interestingly, only in areas where chip and PIN technology makes little difference, including card-not-present fraud and overseas-use fraud. What this suggests to me is that criminals are creative; and credit card fraud, like all security problems, requires a multi-layered solution.

As more and more countries move to adopt chip and PIN and make their retail data more difficult to hack, one real concern is that U.S. card holders and businesses become viewed as “low hanging fruit” and are targeted by hackers and identity thieves more frequently. A recent survey by Actimize found that around 66 percent of bankers, card issuers or payment processors anticipate U.S. card fraud levels to increase, with 11 percent expecting a significant level of fraud growth in the near future due to progressing technology upgrades in Canada.

As the number of cases of attempted fraud threatens to rise in the U.S., local banks, card issuers and payment processors will come under increased pressure to find a solution that reduces their liability, even though retailers seem to be focused on user-friendliness over security, as evidenced by Amazon’s use of a payphrase + PIN check-out system. However, there are some contrary indicators. The increased number of high profile security breaches in the States has resulted in laws like Massachusetts State Law 201.CMR 17:00 and the Nevada law requiring compliance with PCI DSS.

The reality is, however. that some of the biggest economic powers in the world have chosen the solution that they are backing — which is chip and PIN. As the U.S. becomes an increasing target of fraud and as U.S. cards are rejected abroad, the long, slow and painful process of converting the American payment system to chip and PIN will begin. The reliance on static account data stored on an easily counterfeited magnetic stripe card transaction is doomed to failure and the question really is not if, but when.

Wednesday, November 18, 2009

Massachusetts Passes State Law 201 CMR17.00: Will Risk-Based Approach Reward Both Business and the Consumer?

Sushila Nair, Product Manager, Managed Security Solutions Group, BT Global Services

By March 2010 every business that owns or licenses personal information about a resident of the Commonwealth of Massachusetts shall be in full compliance with state law 201 CMR 17.00. The law has been delayed several times as smaller businesses and law makers negotiated over the fair balance between consumer protections and business realities, resulting in this version which requires safeguards that are appropriate to the size, scope, and type of business handling the data.

Although I’ve discussed the impact of 201 CMR 17.00 before, the passing of the law brings two critical questions that are primed for more discussion into sharp focus:

Do you know where your data is and if it’s necessary to keep storing it?
Is a risk-based approach the right way to bring ensure compliance?

Time and again, based on our experience with helping our customers meet their regulatory requirements, the need to locate data and evaluate whether it really needs to be retained is the number one challenge that most companies face. Frequently, organizations try to avoid this step citing that it is simply too difficult. Inevitably they end up doing some data location to segregate information, because the broader task of evaluating the data’s value to the organization and creating a data destruction protocol is often too expensive. But for companies large and small who are affected by 201 CMR 17:00, it is crucial to discover where your information is and then rationalize and segregate.

Here is a list of tools that can be used to assist in locating privileged information:

http://www.groundlabs.com
www.dbdatafinder.com
CCSRCH: http://sourceforge.net/projects/ccsrch
SENF: https://source.its.utexas.edu/groups/its-iso/projects/snef/
SPIDER: http://www/cit.cornell.edu/security/tools/sider-windows.html
SPIDER: http://www.cit.cornell.edu/securitytools/spider-linux.html
SNORT for sniffing: http://bleedingthreats.net/rules/bleeding-policy.rules

Once you’ve located the information the next step is to draw a data flow diagram to ensure you understand how confidential data enters your organization, where it is routed, and where it is eventually stored. Having undertaken these two steps you’ve won at least half the battle!

The next step is to understand how you are going to secure the information that you have just located. Every company, whether directly affected by industry or governmental regulations should invest time creating a written information security policy, which encompasses the storage, access, and transportation of records containing personal information and what is to be done in the event that information is breached.

While bringing in external consultants is an obvious action at this point, businesses with smaller resource bases should evaluate sample policies on the web and as well as tool kits that can be bought and act as building blocks towards the process of creating a policy which is in line with your business objectives. The key is to always start with a policy and then map out standards which meet the technical requirements to protect the types of personal data and the locations of data your company needs to store.

Fortunately, for businesses in the Commonwealth of Massachusetts, the state has outlined the technology requirements needed to be compliance in the section entitled Computer System Security Requirements. The broad list includes:

Secure user authentication protocols
Secure access control
Encryption of all transmitted records and files containing personal information that will travel across public networks, and encryption of all data containing personal information to be transmitted wirelessly.
Reasonable monitoring of systems, for unauthorized use of or access to personal information;
Encryption of all personal information stored on laptops or other portable devices;
Up-to-date firewall protection and operating system security patches
Reasonably up-to-date versions of system security agent software which must include malware protection and reasonably up-to-date patches and virus definitions
Education and training of employees on the proper use of the computer security system and the importance of personal information security

The technical requirements should encompass those that are outlined within CMR 17.00 but it is good business sense to really analyze any foreseeable risks to personal information and come up with a plan to eliminate or reduce those risks. The controls selected should be in line with the amount of data and the risk involved. Small organizations that store only personal records of their employees should simply ensure that information is kept under lock and key and handled in a manner to ensure that it cannot be lost or stolen. Organizations that are handling large amount of personal data including sensitive customer information need to place more stringent controls in place such as real time monitoring.

What makes CMR 17.00 most notable is, however, the risk-based approach to compliance. The approach of the Massachusetts legislature is completely at odds with the prescriptive approach taken by PCI DSS. PCI DSS mandates the same controls independent of the quantity of card data or transactions. The risk based approach in the Massachusetts law is based on the concerns surrounding costs to small businesses for securing information. The lack of legal precedence and, to some degree the lack of knowledge on what controls are appropriate for varying risk levels, may make taking this approach confusing for some companies though it is undoubtedly the best approach from a security perspective.

Do you think that the risks of confusions businesses is more than made up for by the better security practice? Leave a comment here, or let us know what you think @SecureThinking on Twitter.

Monday, November 9, 2009

What healthcare reform means for HIPAA

Sushila Nair, Product Manager, Managed Security Solutions Group, BT Global Services

The last thing a patient wants to deal with is a security breach of his/her protected health information (PHI), which is why the government implemented the Health Insurance Portability and Accountability Act (HIPAA) in 1996. Healthcare regulations changed dramatically with the introduction of HIPAA to protect patients’ privacy by limiting access to PHI. With the latest round of healthcare reform, lawmakers are working to ensure patient privacy is protected with the latest health information technologies being implemented in healthcare.

The latest healthcare regulation, which was created by the American Recovery & Reinvestment Act, enables secure connectivity in a collaborative healthcare environment. The new Federal Health Information Technology for Economic and Clinical Health (HITECH) Act outlines how the federal stimulus money is being used at the state level to advance the design, development, and operation of a nationwide health information infrastructure that promotes the electronic use and exchange of information. In other words, electronic health records (EHRs), electronic prescribing of prescription medication and other similar initiatives.

This past April, the U.S. Department of Health & Human Services issued guidance specifying the technologies and methodologies that render PHI unusable, unreadable, or indecipherable to unauthorized individuals, as required by the HITECH Act. This guidance was based on two additional breach notification regulations – one by HHS for covered entities and their business associates under HIPAA and the other by the Federal Trade Commission for vendors of personal health records and other non-HIPAA covered entities. HITECH requires these regulations to be published within 180 days of enactment. If the entities subject to the regulations apply the technologies and methodologies specified in the guidance to secure information, the entities will not be required to provide the notifications required by the regulations in the event the information is breached.

As part of the revised regulations, civil monetary penalties have increased substantially from $25,000 to $1.5 million, effective immediately. The HITECH Act will make monetary penalties mandatory in February 2011 if an investigation reveals a “willful neglect” of compliance duties. It is likely that proactive enforcement activity and the assessment of monetary penalties will be much more aggressive from this point onwards.

It also expands the reach of HIPAA data privacy and security requirements to include the “business associates” of those entities like billing agencies, insurance and pharmaceutical companies. So, suddenly 13 years after HIPAA was first implemented, there are new organizations that have to comply with HIPAA.

Interestingly, it is possible that the yet-to-be-determined healthcare reform bill may include new rules regarding HIPAA, including proposals allowing HIPAA standards to be updated periodically, and fines to health plans that don’t comply to HIPAA “operating rules” by April 2014.

While health IT remains a focal point in the healthcare reform bills, HIPAA is also being viewed as the mechanism to secure the exchange of health information which is an integral part of establishing an affordable, efficient and transparent healthcare system.