Other Blogs
There are no items in this list.
Knowledge & Insights > ISACA Now > Categories
Regulatory Landscape Provides Added Incentive for Enterprises to Explore Blockchain

Chris K. DimitriadisThe increasing emphasis on data privacy gained widespread attention last year with the enforcement deadline of the General Data Protection Regulation (GDPR). Regardless of your perspective on GDPR and its impact on enterprises, the need for organizations to provide more robust solutions to protecting customers’ data is only going to escalate as data sources continue to proliferate and the regulatory environment continues to evolve. While many organizations remain in the early stages of determining if and how blockchain fits into their digital transformation plans, the role blockchain can play in driving toward improved data privacy in addressing regulatory requirements such as GDPR could serve as an additional factor in their considerations.

Blockchain is among the most disruptive of the high-profile technologies that are being used today to help enterprises transform, and it is certainly one of the technologies with the most intriguing outlook for enterprise security leaders. Blockchain brings a range of data integrity-enhancing capabilities that should be appealing to most information security professionals, such as the ability to manage the identify of users, leverage tokens to build trust among all parties and make it impossible for hackers to access a trove of information in a single repository due to the decentralizing recordkeeping. Respondents to ISACA’s Digital Transformation Barometer identify artificial intelligence and big data as the technologies with the most transformational potential, but the considerable amount of hype blockchain has receives is good with good reason – there is real potential for blockchain to revamp business models and create unprecedented business efficiencies. These capabilities, though, can only come to fruition if the proper governance, risk and compliance considerations are accounted for, and if the implications of blockchain deployment are workable within the context of the evolving regulatory landscape, most notably including GDPR.

Private and Permissioned Blockchains Particularly Promising for GDPR Compliance
On that front, a recent report by the European Parliamentary Research Service provided some interesting context. As the report notes, “blockchain technologies are a data governance tool that could support alternative forms of data management and distribution and provide benefits compared with other contemporary solutions. Blockchains can be designed to enable data-sharing without the need for a central trusted intermediary, they offer transparency as to who has accessed data, and blockchain-based smart contracts can moreover automate the sharing of data, hence also reducing transaction costs. Furthermore, blockchains’ crypto-economic incentive structures might have the potential to influence the current economics behind data-sharing.” Despite the considerable upside, there are certainly challenges and nuanced use cases to work through. The report makes it clear, for example, that private and permissioned blockchains are better suited to comply with GDPR than permission-less blockchains. And more generally, there is not a single, clear-cut verdict on whether blockchains as a whole are GDPR-friendly, meaning individual use cases must be investigated and vetted on their individual merits.

Blockchain Brings the Potential for Automation, Clarity and Integrity
But while many open questions remain in terms of how blockchain fits into the modern regulatory landscape, it is clear that blockchain presents new opportunities to strengthen enterprises’ approach to data governance and data privacy. Addressing a variety of GDPR challenges, such as data subject consent management, can be managed through the introduction of blockchain, similarly to the contract management case. There are several other use cases to consider, such as the serving of data subject rights in environments in which many organizations and individual stakeholders are involved (from controllers to processors and subprocessors). In these instances, blockchain is capable of providing the automation, clarity and integrity required.

In the bigger picture, information security professionals need to embrace a future-minded approach, recognizing that the security programs of the past decade, in many cases, will not be sufficient to position their enterprises for success going forward. This mindset should not only apply to improving business results, but must also extend to the growing challenge of keeping pace with the increasing demands of the regulatory environment. Similar regulations to GDPR are being enacted around the globe, as the need for robust data privacy knows no geographic bounds. These evolving requirements provide all the more incentive for enterprises to explore what blockchain and other emerging technologies can do to strengthen their security programs and better position their organizations to meet current compliance requirements as well as prepare for the compliance challenges of the future.

Editor’s note: This blog post originally published in CSO.

The Next Challenge in IT Compliance Reporting: SOC2 2017 Trust Services Criteria

Varun PrasadIn the aftermath of GDPR, the next big change in the IT compliance standards landscape is here. The period of applicability for the new System and Organization Controls for Service Organizations: Trust Services Criteria (SOC2 2017 Trust Services Criteria) has just begun – all SOC2 reports with an examination period ending on or after 15 December, 2018 will have to be issued as per the new standard.

What is SOC2?
As stated by AICPA, SOC2 reports provide “detailed information and assurance about the controls at a service organization relevant to security, availability, and processing integrity of the systems the service organization uses to process users’ data and the confidentiality and privacy of the information processed by these systems.” Over the past couple of years, there has been an increased awareness around SOC2, with more organizations looking to get a SOC2 report to demonstrate a solid system of controls around the product or service they offer.

Shifting goalposts
Regulatory and standards bodies keep revisiting existing mandates to see if they need an update in order to make it more meaningful, relevant and useful for the consumer. The AICPA has recognized the need for a solid system of internal processes and controls, including monitoring and reporting, to enable a service organization to fulfill its service commitments. Hence, at this time, the SOC2 criteria has been modified to include broader entity-level controls around management oversight and risk management processes, and other technical controls to specifically address cybersecurity risks. The Trust Service Principles – the security, availability, processing integrity and privacy on which reports are issued – are now referred to as Trust Service Categories in the update.

The key changes
The earlier set of Trust Services Principles and Criteria is now classified as Trust Services Criteria (TSC) and codified differently to align with the COSO 2013 framework. There are distinct common criteria that map to each of the COSO framework’s five COSO components and 17 principles. Further, as per COSO Principle 12 that requires entities to deploy controls, there are additional criteria for certain key control areas. As in the past, the common criteria pertains to the security category, and there are additional criteria for each of the other categories. The table below better illustrates this.

TSC Ref. # Criteria/COSO Component COSO Principles covered
CC 1.0 Control Environment Principles 1-5
CC 2.0 Communication and Information Principles 13-15
CC 3.0 Risk Assessment Principles 6-9
CC 4.0 Monitoring Activities Principles 16-17
CC 5.0 Control Activitities Principles 10-12
CC 6.0 Logical and Physical Access Controls Principle 12
CC 7.0 System Operations Principle 12
CC 8.0 Change Management Principle 12
CC 9.0 Risk Mitigation Principle 12
C 1.0 Additional Criteria for Confidentiality N/A
P1 1.0 Additional Criteria for Processing Integrity N/A
A 1.0 Additional Criteria for Availability N/A
P 1.0 Additional Criteria for Privacy N/A

Staying in line with the COSO framework, each criterion has a list of points of focus (POF) associated with it. According to the AICPA, the POFs help management in implementing the right controls. It may also assist both management and the service auditor when they are evaluating whether the controls were suitably designed and operated effectively to meet the TSC.

The final change that’s important to mention here is that as part of the system description, the service organization is now required to document its service commitments and also to disclose any system or security incidents that resulted from one of the control failures, or caused the service organization to not meet one of the stated service commitments. This is significant as it requires entities to track, evaluate the impact and remediate every incident that occurs for effective reporting.

What’s the effect?
From a practicality perspective, one important difference is that as part of the earlier version of the standard, the Trust Services Principle and Criteria had illustrative controls specified for every criterion. However, in the latest update, there are no example controls provided by AICPA for the TSCs. Interestingly, this could have been a conscious move, as there was this fear of the temptation to just include the bare minimum set of illustrative controls required for each criterion and seek an assurance report. As indicated by AICPA, applying the new TSC requires judgment. The current SOC2 TSC requires service organizations to think critically about each criterion and to evaluate the applicability of each of the POFs in the context of the services provided; and identify and implement controls corresponding to every relevant POF. The new SOC2 involves additional time and effort.

Overall, the scope of the new SOC2 covers more in breadth rather than depth. With a lot of emphasis on cyber risks, the new criteria rightly require a comprehensive risk assessment process, an appropriate mix of controls for risk mitigation (with a focus on incident monitoring and handling) and an overarching corporate governance structure as a crucial layer of defense. Definitely, the bar has gone up for the SOC2, and it mandates the existence and operation of a well-rounded internal system of controls related to reporting on the trust service category.

Author’s note: This post reflects the author’s personal views and does not necessarily reflect the views of any organization of which he is a part.

Protecting Patient Records in 2019 and Beyond

Adnan RajaA program called MyHealthEData was unveiled in 2018. Through this program, the US Centers for Medicare & Medicaid Services (CMS) is promoting the adoption of IT environments that allow simpler sharing of health data to outside organizations, as well as better access. The CMS will also allow easier access to claims data by medical beneficiaries.

While MyHealthEData is a fairly new program, its goals are not. Issues of access and interoperability are central to healthcare security and management. This initiative is part of a broader cultural and technological moment, in which there is an increased desire to allow patient sharing to third-party apps, along with strengthening discussion about making historical health data available anywhere a patient is treated. This strategy could become critical for public health, linking patients to health treatments that might be most powerful for them. De-identified patient data can be a powerful means to improve care, but the threats related to big data are manifold.

In this climate, it is important to consider the protections that should be in place for the protection of HIPAA data, both today and in the future.

Patient safeguards for today
A report published in 2017 by the Journal of Medical Systems reviewed the most common HIPAA compliance security methods recommended in research articles. Below, these methods are organized according to the three types of protections mandated by the Security Rule – technical, physical, and administrative safeguards.

Technical safeguards:

  • Access controls to prevent unauthorized access;
  • User IDs and passwords;
  • Simple passwords for backup systems;
  • Personal and role-based authentication;
  • Pseudonymity;
  • Firewalls;
  • Antivirus software;
  • Mobile agents;
  • Encryption through cryptography (digital certificates, digital signatures, and encryption algorithms);
  • RBAC Matrix cryptography protocol;
  • Decryption and verification;
  • Data discard;
  • Authenticated assertion issuances;
  • Data transmission that meets ANSI/AAMI/IEC TIR80001–2-1:2012 and similar risk management standards;
  • Fax transmission encryption via privacy enhancing technology (PET);
  • Cloud computing (hybrid cloud integration); and
  • Use of short-range wireless (Bluetooth).

Physical safeguards:

  • Locks on laptops;
  • Physical access controls, including locked spaces for network servers;
  • Tamper-proof equipment;
  • Security cameras; and
  • Radio Frequency Identification (RFID).

Administrative safeguards:

  • Full employee training programs (with game-based education), including regarding disaster recovery, response training for missing records, and prevention of unauthorized patient record disclosure via email;
  • Full security plans, including monitoring and testing practices;
  • Annual risk assessments;
  • Hiring a Chief Information Security Officer (CISO);
  • Hiring HIPAA consultants;
  • Policy of manager approval related to any releases of paper patient data;
  • Requirement that prohibits wireless devices for PHI storage or transmission;
  • Policy on how to use social media in a HIPAA-compliant manner;
  • Deidentification of research samples;
  • Prevention of offsite ePHI transfer;
  • Mitigation of alert fatigue;
  • Routine backups;
  • Generators for downtime prevention;
  • Duplication of key hardware;
  • Requirement of computerized provider order entry (CPOE) for any order;
  • Restrictions on the interaction of ancillary systems, such as pharmacy management, with mission-critical environments;
  • Fostering of a security culture, with strong computer habits;
  • Digital signatures for any of the organization’s documents; and
  • Business associate agreements with all cloud and other third parties.

Patient safeguards for tomorrow
Maintaining HIPAA compliance requires reasonable and appropriate measures, given the changing threat and technology environment. Approaches to HIPAA compliance that will become increasingly of use to organizations for HIPAA compliance in the future include advanced analytics, custom security infrastructure, the Gartner method of continuous risk and trust assessment (CARTA), and blockchain, among others.

Beyond the technology and approach options that are newly available to you, it is also important to consider how patient behavior and expectations are evolving. Patients have the right to their own ePHI at any time. That means they can copy their information, even from your computer screen, without signing an authorization. Once their ePHI is in their hands, the patient is accountable for safeguarding it. Providers worry that they could be expected to protect information that they are not controlling. Doctors also are concerned because they have traditionally been in charge of health information, but today, patients often want control, which means they need access to their complete records.

As indicated by ISACA member and health technology writer Susan Snedaker, studies “show that engaged and informed patients have better outcomes.” Since that’s the case, you want to provide this access.

This broader access to patient records and diversification of environments is certainly a challenge for HIPAA compliance, though, as indicated by a July study that highlighted the limitations of HIPAA’s scope. The analysis, written by attorneys Glenn Cohen and Michelle M. Mellow, Ph.D., found that the law was geared toward traditional environments and interactions – only encompassing a small portion of all digital health data. Other key data related to healthcare is available through search engines, supermarkets, and credit card firms. Examples of data through which people can infer that a person has an illness include over-the-counter purchase data from drugstores, user-generated posts on social media, and purchase data from online stores.

“The amount of such data collected and traded online is increasing exponentially and eventually may support more accurate predictions about health than a person’s medical records,” noted Cohen and Mellow.

Given how powerful this data is, it is likely that compliance will eventually turn toward incorporating other forms of information under the healthcare law.

Internal and external compliance
The steps an organization needs to take to protect its ePHI today are extensive. As security technologies and the threat environment continue to adapt, the specific methods will change. However, a core concern with and focus on security will remain at the cultural core of organizations serious about HIPAA compliance.

It is not just about what is going on within your organization but also about managing relationships with your vendors. Be certain that your business associates are ready for compliance today and tomorrow, as indicated in strong business associate agreements that indicate their knowledge of this law and commitment to meeting its provisions.

GDPR Compliance as a Competitive Advantage

Laszlo Dellei Last year was a milestone in the field of privacy as the General Data Protection Regulation (GDPR) put privacy into the spotlight in and outside the European Union. The heightened interest in data protection resulted in the growing publicity of unlawful data processing, data breaches, and similar incidents, drawing the attention of the general public to the conduct of data controllers.

One example is Facebook, which has misused the personal data of its users on multiple occasions. As a result, many users decided to delete or hibernate their accounts, a process that may lead to significant loss of income to the company, which has partially based its business model on the economic exploitation of users’ information. The case of Facebook, as well as data subjects’ reaction to similar scandals, highlights the importance of the relationship between the use of personal data, data subjects’ trust, and the digital economy.

Consumer confidence is a well-known notion in economics. Consumers express their trust by paying for a product or a service and, at the same time, they are hesitant to buy goods that they do not trust. Therefore, commercial relations are based on trust. In the age of information society, consumer confidentiality has been reshaped: consumers may express their trust not only by paying a certain amount of money for goods, but by providing certain personal information. However, using one’s personal data leaves the individual vulnerable to a certain extent. Unlawful processing of this information leads to a lack of trust on the consumers’ side. Without trust, the consumer will not provide personal data for the products or services, and thus there may be no commercial relations, leading to the loss of income of the controller. Consequently, the data-driven economy has become particularly reliant upon the proper handling of personal data.

GDPR has significantly amplified the importance of the correlation between data protection and consumer confidence. One consequence of the heightened attention concerning the application of the regulation is that individuals are more interested in the way controllers process their personal data. New institutions introduced by the European regime resulted in the wide publicity of incidents and the reactions given by controllers, proper or otherwise. The public is informed about breaches concerning millions of individuals almost on a daily basis, which leads to the erosion of consumer confidence on many occasions, such as in the case of Facebook. These data subject thus began to demand more responsible governance of their data, and, in many cases, even deleted or suspended their accounts. Since Facebook has based most of its income on the use of data relating to users, these events may lead to serious losses to the company.

As a summary, proper processing of personal data strengthens consumer confidence in the digital age. A lack of trust results in the lack of consumer willingness to buy certain products or services. On the other hand, users tend to provide their personal data to the controllers they trust, thus generating income and economic growth for those organizations. In other words, GDPR-compliant conduct by the controller constitutes a competitive advantage.

Editor’s note: For more related to this topic, read “Maintaining Data Protection and Privacy Beyond GDPR Implementation.”

Five Cost-Effective Ways for Small Businesses to Achieve Compliance

Ira GoelIn today’s world, in order to do and sustain business, all large and small companies are required to show and prove constant compliance. The task may be somewhat easier for large companies to achieve by hiring more employees; however, small businesses do not typically have the luxury to hire more people at competitive rates with large companies.

Having worked for several small businesses over the past decade in addition to helping non-profits, I have seen several compliance challenges, pains and disruptions to business – and even fear! Simplifying work items is a big step in the right direction. Below are five practical methods that can be effective for small businesses in their quest to achieve compliance:

1. Establish a common language. Whether it is GDPR, SOX, HIPAA, or some other regulatory requirement, establishing a common language is critical. In an ideal world, a privacy and security program is unified, though that is usually not the case. Work with your Chief Privacy Officer and Chief Security Officer together to establish standard language when describing goals, action items, and writing policies and procedures. Different terminology increases confusion. Strike an appropriate balance between technical and business speak.

2. Prioritize training and education. Most practitioners will mention training and education as one of the key elements for a successful privacy or security program. Small business often conduct an annual training session for all employees to check their training requirements. However, in today’s environment, that isn’t going to cut it. Training employees, including vendors and contractors, needs to be a continuous program, and it also has to be focused. Establish focus group trainings for management, committees, developers, quality assurance team members, and business managers. Email blasts, posters and news flashes highlighting relevant incidents are helpful.

3. Do due diligence on documentation. Everyone hates documentation, whether they are business teams or developers. All businesses have something valuable to protect, including personal information, proprietary product information, employee data and more. Documenting business processes to show how that valuable information flows, what happens to it, and who has access to that information will assist in identifying compliance action items. Most of the time the information is not even required but is collected nonetheless, adding liability. Several tools can build documentation from product code and the comments in the code.

4. Don’t forget internal reviews and audits. Once a process is established, policing it is important. Audit the documentation, processes, data and information collected to ensure established controls are implemented correctly and are working, and to identify gaps that need to be  remedied.

5. Continuous evaluation is needed. Once the above steps are in place, keep the loop open to allow employees to provide feedback and allow the documentation to work instead of being treated as overhead. Then, implement solutions and address gaps noticed in the audits.

All of these steps allow the controls implementation to become efficient and lean. In order to get to that point, these steps need continuous repetition to become part of the organization’s DNA.

I have shared similar thoughts in an article on LinkedIn. Nothing is a sure shot or quick fix; it takes a lot of disciplined work, training and re-evaluation to succeed.

Is HIPAA Compliance Enough to Keep Your Organization Safe?

Anna JohannsonThe Health Insurance Portability and Accountability Act (HIPAA) has evolved considerably to keep up with the demands of our modern society. Now that protected health information (PHI) is kept via electronic records, healthcare organizations need to comply with the HIPAA Security Rule if they want to keep their patients’ data private (and avoid a hefty fine).

What’s Required for HIPAA Compliance?
HIPAA compliance requirements can be complicated, but at a minimum, you’ll need to do the following:

  • Only access PHI information when you need to and/or when you have permission. First, you’ll need to comply with all former iterations of HIPAA by not accessing PHI data unless you have the patient’s explicit, written permission to do so, or if it’s required to treat your patient adequately.
  • Have an emergency plan to access PHI. In some cases, you may not be able to get your patient’s permission, and you may not have the account access necessary to retrieve it. What happens then? To be HIPAA-compliant, you’ll need to have an emergency plan in place.
  • Limit and secure email transmissions of PHI. At times, you may need to transmit patient information via email. Avoid these situations when possible, and make sure you’ve upgraded your email platform to be HIPAA-compliant when transmitting via email becomes necessary.
  • Back up all patient data. This should be common sense, but have a backup in place for all patient data, preferably, a HIPAA-compliant source of cloud storage. Don’t risk the damage or destruction of patient data.
  • Give role-based permissions to staff. Your staff members shouldn’t have universal access to patient records. Establish multiple roles, with varying types of permissions, so staff members can access only the data they need.
  • Take precautions against malware. Malware can bring your entire system down, so make sure you have a strong antivirus platform in place, and keep all your apps updated.
  • Maintain different passwords, and change them routinely. Every staff member should have a unique password, and be prompted to change those passwords regularly.
  • Maintain activity logs and audit controls. Your digital systems should keep track of activity, noting when records are accessed or changed. That way, you can audit them in event of a breach or other suspicious activity.
  • Never leave PHI out in the open. Avoid leaving PHI open on a computer. Always log out before leaving a room.
  • Enable automatic logouts. Computers should log out automatically if left unattended for a few minutes.
  • Don’t share PHI information. Staff members shouldn’t share PHI with anyone unless they have explicit permission from the patient and/or orders from a physician to do so.
  • Dispose of PHI information properly and completely. If and when you need to delete patient records, do so completely and securely. That means shredding all documents and wiping all hard drives.
  • Keep an updated training program. Your staff should always be up-to-date on the latest HIPAA security practices. Make sure your training program dedicates enough time to learning these fundamentals, and introduces new information as it becomes available.
  • Have and test a disaster recovery program. What happens if your system’s integrity is compromised? Have a plan in place and test it to ensure it’s working and that staff understand it.
  • Ensure all partners and vendors are following proper procedures. A breach from outside your organization can compromise your PHI; make sure your partners and vendors are HIPAA-compliant as well.
  • Report any security incidents. If you do encounter a security breach, report it, and update your policies to guard against similar events in the future.

Are these standards enough?
Meeting HIPAA standards will ensure your organization remains HIPAA-compliant, avoiding legal trouble that could arise if you slip up. But is it truly enough to keep patient data safe?

HIPAA doesn’t have set requirements for specific types of security; for example, it doesn’t mandate that you use a certain encryption standard, or set your passwords in a specific format. Instead, it’s up to your discretion how to set those standards for your own organization. Competent security isn’t just about checking items off a list; it’s about creating an environment that’s actively searching for and guarding against potential new threats, and evolving to face those threats more efficiently.

In short, HIPAA standards are a great start to any organization’s data security, but they aren’t enough to have a truly comprehensive security program.

Learning to keep up
Even if you believe all your current practices keep your organization HIPAA-compliant, and even if that level of compliance is enough to keep your patients’ data safe, it may not stay that way for long. HIPAA is constantly being updated to respond to new threats and add newer, better layers of protection for patients in the United States. If you want to stay ahead of cybercriminals, and remain in compliance with these regulatory requirements indefinitely, you’ll need to stay plugged into the latest news—and be willing to adapt your security protocols at a moment’s notice.

Action Plan for HIPAA-Compliant Cloud

Adnan RajaHIPAA compliance involves treating your data with extreme sensitivity, so you should view any related technology with extreme care.

Note that the security of a public cloud architecture has often been described as an asset. For instance, Tripwire wrote that “the Cloud is more secure than on-premise backup, storage, and computing systems” – citing regular audits, controlled access, security knowledge, surveillance, and perimeter defenses. However, a poll by SDxCentral found that, across industry, security and compliance was the primary challenge related to public cloud. With 62 percent of respondents indicating this, it was a higher stress than cost management (46%), lack of performance visibility (44%), and cost predictability (41%).

Since healthcare companies have to be so centrally focused on compliance, particularly with the Health Insurance Portability and Accountability Act of 1996 (HIPAA), this concern over cloud compliance deserves special attention. How can you leverage cloud for all its positives without suffering a violation? A few chief concerns should be addressed.

Focus on the BAA.
The US Department of Health and Human Services (HHS), the federal agency that develops and enforces HIPAA regulations, has issued specific guidance related to meeting compliance with cloud systems. This guidance advises that cloud service providers (CSPs) are considered business associates when they generate, receive, send, or store electronic health data, whether they are doing so for a covered entity or business associate. In fact, HIPAA compliance is necessary for cloud vendors that are entirely handling personally identifiable health records (the electronic protected health information, or ePHI, of HIPAA) that is encrypted and for which the provider does not have a key.

Even if a cloud firm does not have any way to access data except in encrypted form (thus meeting the confidentiality requirement), it still must maintain the integrity and availability of the data. As in any other business associate relationship, a business associate agreement (BAA) must be signed by both parties (or a subcontractor BAA, if applicable). Note that the HHS also refers to this document, less commonly, as a business associate contract. The cloud vendor is legally responsible for adhering to the agreement’s provisions. Beyond meeting the BAA’s parameters, the cloud firm also must be HIPAA-compliant itself: ever since the Health Information Technology for Economic and Clinical Health Act of 2009 (HITECH) went into effect in 2013, business associates have been directly responsible for HIPAA compliance.

Know that the data is, in fact, protected health information.
Protected health information (PHI) is the information under the umbrella of HIPAA rules. Encrypted PHI is PHI. However, if it is unidentified (encrypted or unencrypted), it is not PHI.

Work with a cloud provider that is ready to scale.
With acquisitions on the rise in healthcare, it is particularly important to know that a CSP can expand with you. If an acquisition occurs, the vendor should be able to quickly spin up new servers. Scalability is important because you must have enough resources to meet your demand to comply with HIPAA’s availability requirement.

Create a dual relationship.
In signing a BAA with a CSP, you should be creating a two-part relationship that encompasses both business and technical functions. Permitting a balanced interconnection between different healthcare services and knowing about the covered entity or business associate that is contracting with them (i.e., you) are core elements of a cloud vendor that deserve your attention.

Pay attention to use cases.
Think in terms of use cases when you assess CSPs. Many cloud vendors now have HIPAA-compliant business associate agreements readily available (although certainly not all do). Even among those that have BAAs in place, they are not created equal. You especially must be concerned that the organization can customize to suit your requirements when you're looking for a data backup or disaster recovery service, noted Bill Kleyman. Plus, commitment and expertise related to compliance will vary greatly.

Verify transparency.
You want to have a reasonable view of the cloud firm’s operations and business to assess risk and meet compliance.

Check for HIPAA certification.
Does the CSP have a HIPAA compliance certification from a trusted, credible third party, based on a recent audit? Look over the provider’s implementations and control matrix.

Conduct routine risk assessments.
Do your CSPs conduct routine risk assessments? Risk assessments are fundamental to HIPAA compliance – and they must be ongoing. The HHS is extremely clear on this point. The language on risk assessments is somehow loose but specific: “Some covered entities may perform these processes annually or as needed (e.g., bi-annual or every three years), depending on circumstances of their environment,” notes the HHS.

Select the right cloud partners.
Compliance can become especially challenging when you consider your business associates – and cloud providers represent specific risks. By following the above guidance and additional insights provided through the HHS site, you can feel certain that your cloud is healthcare-compliant.

Author’s note: Adnan Raja is the Vice President of Marketing at Atlantic.Net. During his tenure, Atlantic.Net has grown from having a primarily regional presence to garnering and developing attention nationwide and internationally.

Doing the Math: The Value of Healthcare Security Controls

Adnan RajaThe Health Insurance Portability and Accountability Act of 1996 (HIPAA) is a central concern of US organizations that are in any way involved with the creation, access, processing or storage of sensitive confidential health records – electronic protected health information (ePHI). The Security and Privacy Rules are a particular point of focus since violation of those guidelines often leads to federal fines and settlements; those parameters are covered under Title II of HIPAA.

A newer piece of healthcare legislation is the Health Information Technology for Economic and Clinical Health Act (HITECH) of 2009. The first act is typically discussed in terms of concern with security and privacy of health records, while the second is generally described as increasing the implementation of digital health records and technologies. However, Subtitle D of HITECH is specifically focused on issues of security and privacy of electronic health data; it achieves this end by modifying and elaborating on those parameters within HIPAA. Essentially, if an organization is HITECH-compliant, that means that they are compliant with the most recent HIPAA security and privacy stipulations contained within the 2013 Omnibus Rule.

HITECH gives professionals a chance to work with an access governance model so that they can better control who does and does not get access to information – particularly for any systems that contain ePHI. When companies do implement some of the lessons they can glean from HITECH into the structure of their organizations, they will see that it costs them less to operate and that they are better able to create more efficient workflow to manage access risk. Both this reduction in the cost of operation and the streamlining of workflow improve the security of the organization while boosting its value.

To consider that specific notion of value from a security system, it helps to look at the return on security investment (ROSI) of a HIPAA compliant system – and we can use the analogy of soccer.

ROI and ROSI—Like Offense and Defense
Return on investment (ROI) and return on security investment (ROSI) initially seem to be almost identical concepts. However, you can start to understand what makes them dissimilar when you think about how you arrive at an ROI figure: add up the gains, subtract the cost and divide the difference by the cost. Immediately it’s clear that formula will not work: you will not typically profit from adding security measures. Instead of focusing on gain, the intent of the ROSI concept is to limit your losses and help your organization’s value from that perspective. For that reason, rather than thinking in terms of gain and scoring goals as you would with a soccer team, think in terms of not letting the other team score.

You can figure out how much value is being achieved with your security controls by performing a quantitative risk assessment, as noted by the European Union Agency for Network and Information Security (ENISA). In order to come up with your ROSI number, you need to first look at other data: the ARO, SLEs, ALE and mALE.

Calculating ROSI
The single loss expectancy (SLE) denotes the total cost of a single security incident. The annual rate of occurrence (ARO) is the probability that the incident will take place during a single year. The annual loss expectancy (ALE) is the complete loss from security incidents throughout the year. Finally, the modified ALE (mALE) is the ALE, plus whatever losses are avoided through adoption of the security mechanism – as expressed by the mitigation ratio (the percent of threats the solution is able to counter).

To get the ROSI itself, you want to multiply the ALE by the mitigation ratio (producing the mALE), and then subtract the cost of the security apparatus. Divide that total by the cost of the security plan. The end result is the return on security investment.

In other words, you will get the ROSI figure by adding up your loss reduction numbers, subtracting how much you spent on the security mechanism to achieve that loss reduction, and then dividing by the amount you spent on the protective system. You want the number to be higher for ROI, but you want it to be lower for ROSI.

Problems with ROSI
What exactly is the loss reduction, though? By subtracting the annual loss expectancy once the security system is implemented from the annual loss expectancy prior to its adoption, you get the loss reduction. The issue is that the second figure is not easy to measure accurately, with confidence. The figure often has more to do with suggestions made within individual projections and broader polling than it does with real objective measurement.

Pete Lindstrom has said that what must be involved when looking at any solution is effectively a “gut check,” asking oneself point-blank if the amount spent on security achieves a loss reduction that justifies the cost.

Beyond ROSI
As you can see, ROSI can be problematic when it is taken too seriously as an absolute. For greater accuracy when determining value of security, it helps to think about how security can be considered – different perspectives and factors when attempting to accurately apply a value to it, as indicated by Steven J. Ross, CISA, CISSP, MBCP. First, there is the notion of a threshold condition for adequacy of security solutions, without which a business could not be sold because protections do not meet standards of “adequacy.” A higher degree of security would be sufficiency – based on an independent metric that goes beyond the needs of adequacy. Intellectual property should be factored into any estimation of the worth of security solutions, since that asset is being protected. Plus, security should be considered in terms of facilitating sales, since security solutions will often lead to greater revenue.

In the context of healthcare, you want to consider how precious the ePHI is. Because of the various costs related to compliance and general data protection, expenses incurred in a healthcare data breach are diverse, ranging from forensics to breach notifications to lawsuits to lost revenue to lost brand value to post-breach cleanup – and that doesn't even include the federal fine. By implementing industry standards such as those of ISACA, you can systematize your controls and auditing, resulting in security that you and your clients can trust – and that really is holding true as a valuable data defense.

Author’s note: Adnan Raja is the Vice President of Marketing at Atlantic.Net. During his tenure, Atlantic.Net has grown from having a primarily regional presence to garnering and developing attention nationwide and internationally.

Advancing a Symbiotic Relationship Between COBIT, ISO Governance Standards

Judd HesselrothAs a 2003 CISA recipient and a former honorary secretary of the ISACA Singapore Chapter’s board of directors, I am honored to be selected as the ISACA liaison to the International Organization for Standardization (ISO) Technical Committee 309 – Governance of Organizations.

Having served nearly three years as the chair of the US Technical Advisory Group to ISO Project Committee 278 to help develop, draft and evangelize the ISO 37001 Anti-Bribery Management System Standard, I see this as a wonderful opportunity to not only keep both the ISACA and TC-309 communities informed of significant developments in the world of governance and compliance, but also to help shape and develop newly proposed ISO standards while supporting and strengthening existing ones.

As you may already be aware, TC-309 is focused on standardization in the field of governance relating to aspects of direction, control and accountability of organizations, and is responsible for:

The symbiotic relationship of COBIT and ISO governance and compliance standards, particularly in the realms of data governance, privacy, security in the cloud and the Internet of Things, likely goes without saying. However, having the opportunity to proactively and positively engage, inform, shape and contribute to this relationship with fellow subject matter experts from 40-plus countries is rare, and I thank ISACA for enabling me to participate in this partnership. 

Author’s note:  Judd Hesselroth is a Director in Microsoft’s Office of Legal Compliance, where he has focused primarily on anti-corruption programs and ISO 37001 since 2010, and prior to that, internal audit.

Data Analytics Maturity Models and the Control Environment

Angel SerranoOrganizations have recently raised concerns on their data analytics capabilities. There are several motivations for this increased interest in data analytics, such as fulfilling regulatory requirements, increasing efficiency and reducing cost. However, the primary reason is focused on the identification of business opportunities. The most typical questions include:

   • Are we maximizing the value from the data we currently have?
   • Are we missing business opportunities because we do not use our customer data?
   • What is the competition doing?
   • What are the best practices in the market?

It is difficult to answer these questions without a structured model that defines what is “basic” and what is “advanced.” It helps to provide a simple maturity model that is easy to understand.

The maturity levels below show a basic and summarized model based on the current situation in the financial services sector, and are based on what the industry wants to achieve.

  • Level 1: Basic data analytics capability. Systems and applications working in silos and analysis performed on individual databases on end-user computing tools (e.g., spreadsheets and access databases). Limited analysis can be done at this level due to the limitation of the tools and the data used.
  • Level 2: Specific analytics function. Interaction between systems (e.g., data warehouses or data lakes) and usage of data analysis tools that allow integration of different data sets. Analysis can be reused on those systems that combine different data sets. However, there is a gap between the business and its data analytics teams.
  • Level 3: Business intelligence capability. Adding a business intelligence platform (data visualization ledger) to the previous maturity level. This allows the end users to perform their own analysis through dynamic dashboards.
  • Level 4: Prediction Analytics (artificial intelligence). Adding to the previous maturity level the usage of statistical analysis that allows for the creation of prediction models and algorithms based on parameters or scenarios.

Some organizations want to achieve the best maturity level without having basic controls in place, which can create erroneous results due to the lack of quality in the data used. An appropriate level of control and data governance function is critical for the success of the data analytics function, and helps to progress through the maturity model.

Examples of basic controls that must be in place before progressing to the next level include:

  • Input controls on entry data systems and applications, such as range controls (e.g., age must be between 18 and 100), avoid zeros and blanks, invalid characters, etc.
  • Reconciliations (or equivalent) on interfaces and transfers of data between systems applications; sometimes totals on number of transactions and total value provides enough level of comfort.
  • Assurance that calculations performed on applications are correct. Reperform calculations in an independent environment in order to ensure that calculations are performed correctly.

To summarize, the use of data analytics techniques and expertise can increase the value from the data that organizations can obtain. However, it is important to maintain data quality and a management framework to ensure that the data used for the analysis is fit for purpose.

1 - 10 Next