Day: October 24, 2014

I attended the second National Institute of Standards and Technology (NIST) Privacy Engineering Workshop on behalf of ISACA, which was held in September in San Jose, California, USA. NIST took the information that they collected at their first workshop in April 2014 and put together a proposed high-level draft of the beginning of what will eventually become the privacy engineering framework—the “Preliminary Concepts” that will ultimately become integrated with the U.S. Framework for Improving Critical Infrastructure Cybersecurity, which was published early this year.

This workshop focused on four primary activities:

1. Reviewing the proposed privacy engineering definitions
2. Reviewing the proposed “System Privacy Risk Equation”
3. Determining a lexicon of privacy objectives, establishing common terms and categorizing potential privacy harms
4. Hearing from engineers, privacy experts and privacy advocates about additional issues

Proposed Privacy Engineering Lexicon
If engineers are expected to be able to understand privacy principles and then build privacy controls into their systems, devices and processes to effectively protect privacy, then they must be operating under a common vocabulary to understand the terms in the same way across the enterprise and then consistently implement the privacy controls. Some of the terms proposed by NIST, based upon their research and feedback from the April workshop, include three primary privacy engineering objectives and some primary privacy terms that all engineers need to know and understand.

The proposed privacy engineering objectives include (with my interpretations shown):

• Predictability: These are actions to support reasonable assumptions individuals have about how their personal information is collected, used and shared.
• Manageability: These are actions to allow individuals to access, correct, delete and selectively disclose their associated personal information as they determine to be appropriate.
• Confidentiality: These are actions to ensure only authorized access to personal information occurs.

There was also discussion of the need for a possible fourth objective: data subject disclosure and rights. However, as various speakers and attendees pointed out, this is something that could be a challenge to actually engineer.

A few of the key privacy terms proposed by NIST include:

• Data Actions: The typical information systems operations where personal information is involved.
• Problematic Data Actions: These are data actions taken with personal data that violate the objectives of predictability, manageability and confidentiality. For example, distortion, misappropriation and surveillance, just to name a few.
• Context: A critical term for engineers to understand. This is a concept that I emphasize all the time to my clients and in the classes I teach. It is also something most systems engineers do not take into consideration Context refers to the actions that should be taken based upon the reasons personal information is collected, and the ways in which it was intended to be used.

Defining Categories of Privacy Harms
NIST has proposed the following categories of privacy harms to be addressed by the privacy engineering framework.

• Loss of Self-Determination: These would include loss of autonomy, exclusion, and loss of liberty.
• Discrimination: These would include stigmatization and power imbalance.
• Loss of Trust: This would include situations where a breach of promises has occurred.
• Economic Loss: Direct financial losses resulting from identity theft and other misuse of personal information.

I firmly believe physical harm and safety should be another category added to the list. Here are just two considerations to support this.

1. We now have many devices that attach to individuals, and are used by individuals, to control their health, environment, etc. If the personal information and associated data within these devices was inappropriately accessed, used, altered, etc., it could result in physical harm to the associated individuals.
2. The types of surveillance methods and technologies continue to proliferate. They could be used to locate individuals, determine when individuals are alone, and reveal other aspects of an individual that could enable a malicious individual to bring harm to the individual in ways that could not occur without these surveillance methods and technologies.

Proposed System Privacy Risk Equation
NIST created a proposed “System Privacy Risk Equation” to help engineers to determine privacy risks in a similar way to how they use the information security risk formulas to determine information security risks. The big difference, though, is that the components focus on the likelihood of harm to the individuals involved, not to the organization itself. Which makes sense since the focus of privacy is on the individual.

The proposed System Privacy Risk Equation was presented as a diagram. Here is my interpretation in a more mathematical representation:

System privacy risk is the risk of problematic data actions occurring during
(Personal Information Collected or Generated +
Data Actions Performed on that Information +
Context)
= System Privacy Risk

One concept missing from this formula is stakeholder input. Without such input, it will be very hard to truly determine the associated privacy risk. I will look for this to be included in the updated equation, based upon discussions at the workshop.

Additional Issues to Address
In addition to the components of the proposed framework above, some of the additional issues that attendees expressed a need to add included:

• The need for basic privacy education for all involved with engineering privacy controls, in addition to providing detailed guidance documents and case studies
• Related to this, the need to educate the public on what is reasonable to expect from organizations with regard to preserving their privacy, and what they themselves need to take responsibility for
• The establishment of metrics to measure how well each of the privacy areas are being addressed within the organization, and to support a determination of an organization’s privacy program maturity model
• Addressing how engineers can include privacy actions within existing systems and software development models, such as agile and waterfall methodologies
• The need to shift the business view of privacy from being a compliance checklist responsibility to being a more holistic evaluation of privacy risks activity

You can download the documents containing the full details of the items discussed above, including the NIST proposed definitions, from www.nist.gov/itl/csd/privacy-engineering-workshop-september-15-16-2014.cfm.

Privacy is about the individual; security is about the business
A couple of recurring thoughts that were described during the workshop that are very important points for organizations to be able to effectively understand and then take appropriate actions to preserve privacy are:

1. The primary focus for privacy risks and mitigations generally is on individuals. This is different than the primary focus for information security, which generally is on the business.
2. Privacy must become part of the business culture and be addressed throughout every aspect of business activities where personal information is involved in any way.

Going Forward
This was an important next step toward establishing actionable privacy standards to include within the US Cybersecurity Framework to provide a reference that engineers will be able to effectively utilitize within their current systems and software development frameworks to help build in the controls currently missing that are needed to most effectively protect personal information and mitigate privacy risks. I do not see this as the last workshop, however; there were several issues that were left open and some that were not addressed at this workshop. NIST also emphasized that the privacy engineering initiative was a distinctively separate effort from the cybersecurity work, implying that there would be at least another workshop down the road.

I look forward to seeing the resulting NIST Interagency Report (IR) that Naomi Lefkovitz indicated would be created as a result of the workshop, and then attending the next workshop where the Privacy Framework likely will be finalized.

Rebecca Herold, CISA, CISM, CISSP, CIPP, FLMI
Owner & CEO, Rebecca Herold & Associates

[ISACA]

Cloud computing has the ability to offer organizations long-term IT savings, reductions in infrastructural costs and pay-for-service models. By moving IT services to the cloud, organizations are more geographically distributed than ever before and the pace of business gets faster every day. Online collaboration has become a business necessity—there is no other way for distributed teams to work as quickly and efficiently as business demands. With virtual, paperless environments becoming more common, simply locking the doors at night no longer protects merchants, banks, customers or the business they conduct.

This means that exploitation will change from systems to web. Due to these changes, today’s business needs demand that applications and data not only move across physical and international borders, but also to the cloud and accessible by third parties. This loss of control is significant for security teams that must not only keep data safe, but also comply with the necessary security standards, including the Payment Card Industry Data Security Standard (PCI DSS). The payment card industry (PCI) should recognize that the most effective way to protect customer data is to protect the networks from the point of purchase to the application servers in their networks.

The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process or transmit cardholder data or sensitive authentication data. “System components” include network devices, servers, computing devices and applications.

Compliance Challenges
Five compliance challenges organizations may encounter are:

1. The cloud is relatively new technology and may be misunderstood.
2. Clients may have limited visibility into the service provider’s infrastructure and the related security controls.
3. It can be challenging to verify who has access to cardholder data process, transmitted, or stored in the cloud environment.
4. Public cloud environments are usually designed to allow access from anywhere on the Internet.
5. Some virtual components do not have the same level of access control, logging, and monitoring as their physical counterparts.

Meeting the Compliance Requirements
Shared hosting providers must protect each customer’s hosted environment and cardholder data. From 30 June 2015, these providers must meet specific, additional requirements that are set out in an appendix A of PCI DSS Version 3. Below are a few highlights:

• PCI DSS requires that hosting providers ensure that each customer only runs processes that have access to that entity’s cardholder data environment.
• Access and privileges must be restricted to each customer’s own cardholder data environment.
• If a customer (merchant or service provider) is allowed to run its own applications on a shared server, it should run with the user ID of the customer, rather than as a privileged user.
• Logging and audit trails must also be enabled, unique to each entity’s cardholder data environment and consistent with PCI DSS requirements.
• Logs should be available to each customer, specific to their cardholder data environment.
• Processes must also be available to provide timely forensic investigation in the event of any compromise of cardholder data or systems.
• Even though a hosting provider meets PCI DSS requirements, the compliance of the customer using the service is not guaranteed.
• Each entity will need to comply with PCI DSS and validate its own compliance as applicable.

PCI DSS compliance is mandatory for banks, merchants and providers that process, transmit or store cardholder data. The risk of noncompliance is substantial, including fines, potential security breaches and loss of business.

Any enterprise that falls with the scope of the standard must implement it and seek compliance. Merchants who fail to comply might be forced to pay an extra percentage for noncompliance. There are also fines for storing sensitive authentication data, which is not allowed under the standard. Penalties for data breaches in noncompliant companies can be severe, including large fines as well as the threat of future exclusion from the payment card network.

Adesanya Ahmed, CRISC, CGEIT, ACPA, ACMA
IT Security and Connectivity Consultant, Petrovice Resources International Ltd.
owos2001@yahoo.co.uk

[ISACA]