News > i3

How to Engineer Privacy


Consumer data privacy is a topic that is keeping executives of the biggest internet giants busy. Privacy is on a lot of minds in Washington and in other global regulatory organizations, as they consider how industry should protect consumers’ Personally Identifiable Information (PII). The people who work on standards and best practices are deep into these waters as well.

As the attention on privacy grows, the term “privacy engineering” has emerged. But it can be difficult to understand what someone means by privacy as an engineering topic. At the root, questions of privacy are questions of policy. 

As an analogy, I have a policy at my home that I don’t want people looking in the windows at night. I use technology—window blinds—to enforce that policy. The window blinds are the privacy engineering supporting the privacy policy. Closing the blinds is a best practice for use of the technology. 

Similarly, I have a security policy that people should not walk in the front door and steal things. The lock is my security technology. I lock the door at night when I close the blinds, also as a best practice.

Privacy Engineering 

What does this mean if privacy per se is a policy topic? 

While the NIST description is specific to their efforts, a few common themes are for a manager’s own considerations of privacy engineering. 

The first has to do with using secure systems— “trustworthy” systems —to protect privacy. If you are collecting data, it’s important to protect that data when it is stored or being transmitted— or in the parlance of the security world, “data at rest and data in motion.” This implies good cybersecurity practice. A good starting point is Securing Connected Devices for Consumers in the Home – A Manufacturer’s Guide (CTACEB33), free to CTA members. 

The NIST mission also mentions measurement science. Privacy concerns are about the risk of breaches. Breaches of consumer data not only damage consumers, but tarnish the company’s reputation, expose it to government action and civil lawsuits, and potentially impact the stock price. Setting up privacy requirements for the organization is only logical. Like performance goals in an annual review, privacy requirements should be measurable — by test, observation, etc. Privacy engineering is also about measuring performance to privacy requirements. 

The text also speaks of frameworks. CTA believes that prescriptive regulatory requirements hamper innovation and are quickly dated. Frameworks are a useful structure to establish the guidelines without such static requirements. When you use an established framework for a purpose, you can customize your program to your evolving needs. A privacy risk management framework can be helpful to understand and measure risk categories within the privacy space. 

Understanding privacy risk categories allows you to decide which ones must be given the greatest attention. One cannot mitigate all possible risks with equal effort. Those risk categories that need to be addressed can be attacked with good cyber hygiene. CTA has partnered with the Council to Secure the Digital Economy (CSDE) to develop an international anti-botnet guide (IABG) . While the IABG is mostly focused on botnets— swarms of compromised computing devices used by hackers for malicious, coordinated attacks—the best practices in the IABG span all parts of the internet ecosystem and cover the important elements of security engineering that will also support privacy policy.

In short, privacy engineering is about managing privacy-related risks with tools and frameworks that help decide how to direct cyber security resources to protect the security of PII. 

Mike Bergman

Tagged

Related