In this article, security expert Carol Woodbury discusses whether keeping data private assures compliance.

In my previous article, "Does Compliance Guarantee Privacy?" I came to the conclusion that, no, compliance does not guarantee privacy. But is the reverse true? Does keeping data private mean that you're in compliance?

As in my previous article, this question requires other questions to be investigated before we can come to a conclusion. Please join me in my investigation.

First, we need to come to a conclusion about the aspect of privacy we're investigating. Web sites are gathering more and more information about the sites we visit, customizing news articles, book selections, and ads based on our previous sites visited and clicks made around the Web. Some people are infuriated by the thought that our every Web move is being "watched." There are pros and cons to this type of data collection, with one con being the perceived invasion of privacy. (See the Wall Street Journal discussion for details.)

Then there's the expectation of privacy. For example, when we post something on Facebook, if our privacy settings are configured to share information only with our friends, we expect that our posts won't be available to the entire Facebook community. On the flip side, employers will often make sure we do not have an expectation of privacy in certain areas; email and instant message chats are two areas where this typically applies.

These two discussions on privacy really focus on us and how we perceive our actions and our information to be regarded. But the aspect of privacy to which I'm referring is that of the responsibilities of the data owner and the data custodian. These two roles in an organization hold the responsibility for protecting personally identifiable information (PII)—that is, keeping our PII data private. 

What Does It Take to Keep Data Private?

Another area we need to investigate is what it takes to keep data private. In general terms, keeping data private means that the data is given to and is accessible by only by those individuals with a business "need to know." Let's take a look at how this is implemented along with some of the common pitfalls of implementation.

Data Classification

First things first: the data has to be classified correctly, or maybe I should simply say that the data has to be classified. By classified, I mean that there is recognition by the organization of the sensitive nature of the data. I'd be happy if the problem was that data is being misclassified; the problem is really that many organizations fail to classify their data at all. If data isn't classified, then it's highly unlikely that it's protected appropriately.

Business "Need to Know"

What does this term mean? It means that the only people in the organization with access to PII data are those that have to access the data in order to perform their jobs. In other words, if they don't have access to the data, they can't do the tasks they've been assigned. The decision of who gets access to the data is the responsibility of the data owner. This is another area where organizations fall down. I've seen business owners justify access to the full decrypted credit card number because those users have "always had access," regardless of the fact that the process they're performing no longer needs the full card. Take the employees that have to investigate a particular transaction. Banks used to require the full credit card number for this investigation, but for most banks, this is no longer a requirement. Nevertheless, the users continue to have full access because organizations refuse to change one of their processes. Examples such as this abound.

Access Controls and Deny by Default

Once users with the business need are identified, they should be the only users with sufficient authority to access the data. In the IBM i world, this means setting the *PUBLIC authority setting to *EXCLUDE. In the IBM AIX world, this means the absence of authority—in other words, not giving the world authority to the file. It is the responsibility of the data custodian (i.e., system administrator) to implement or set the authorities on the database files. Authority is given only to the users approved (by the data owner) to have access to the data. While organizations often have these access controls set appropriately at some point (typically, right before or after an audit), the place that many organizations fail is in keeping access down to the approved set of users. For example, I often see access granted to a programmer for a special project but never removed when the project is completed. Or groups are granted full access when the application experiences a failure. In a flailing effort to find a solution, access controls and the concept of deny by default are thrown to the wind. Never mind that access control settings rarely provide a solution to the issue. The mental note to set the authorities back when the real cause of the failure is discovered is lost once the problem is properly debugged and production back up and running.

Encryption

In addition to setting the appropriate access controls on the database files containing the PII data, encryption is another layer of security that can be applied to the data. However, appropriate access controls need to be applied to the decryption function. If everyone on the system is allowed to decrypt the data, one has to question why one would bother with encryption. If it's to add a layer of security to data on backup media, then encryption may be appropriate. However, if the intent is to secure the data on the system, deny by default and appropriate access controls must be set; otherwise, I have to question the implementation logic.

And More

Of course, other things contribute to the privacy of data: strictly limiting the number of all-powerful profiles (root on AIX, *ALLOBJ special authority on IBM i), enforcing regular password changes, implementing strong passwords, encrypting sessions so user IDs and passwords can't be sniffed, etc. It really comes down to implementing security best practices wherever possible to have the best chance of keeping PII data private.

So What's the Answer?

Let me get back to the question at hand: does privacy assure compliance? The answer? The answer is…it depends. I can hear the groans, so let me explain. Whether the steps you've taken to ensure the privacy of the data equates to compliance depends on the type of data and the laws and regulations that your organization must be in compliance with. For example, healthcare information is regulated by the Health Insurance Portability and Accountability Act (HIPAA) and, more recently the Health Information Technology for Economic and Clinical Health Act (HITECH); financial information is regulated by the Gramm-Leach-Bliley Act (GLBA) and internationally by the Basel Accords; credit cards are under the jurisdiction of the Payment Card Industry's Data Security Standards (PCI DSS). Organizations doing business in Europe must comply with the EU data privacy laws as well as laws passed by individual countries. Organizations with operations in Korea must be in compliance with the privacy requirements in the very strict Korea Law (which I've heard referred to as "PCI DSS on steroids"). Organizations keeping Massachusetts' residents' information must comply with the Massachusetts data privacy law. You catch my drift. Some of these laws are extremely vague as to how data is to be secured. Some are very detailed. Take HIPAA: while encrypting electronic protected health information (ePHI) is recommended, is it not required. Therefore, you may be in compliance with HIPAA if you don't use encryption as one of your security layers for protecting data, but if you don't use encryption for PCI data or data falling under Korea Law, you are definitely not in compliance. Or you may choose to encrypt all of your PII data, but if users on your system aren't changing their passwords every 90 days and using strong passwords, you're not in compliance with PCI, Korea Law, or HIPAA.

The conclusion? As was my conclusion in my previous article and now this one, using security best practices throughout all of your systems and your network provides you with the highest likelihood of both keeping PII private as well as being in compliance with the laws and regulations under which your organization falls.

as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7,

 

Carol Woodbury is President and CTO of DXR Security and has over 30 years’ experience with IBM i Security. She started her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies – SkyView Partners and DXR Security. Her current company - DXR Security - specializes in penetration testing for IBM i. Her practical experience together with her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known world-wide as an author and award-winning speaker on security technology, specializing in IBM i Security topics. She has written seven books on IBM i Security. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

 

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		IBM i Security Administration and Compliance: Second Edition Get the must-have guide by the industry’s #1 security authority. List Price $71.95 Now On Sale
		IBM i Security Administration and Compliance For beginners to veterans, this is the definitive security resource. List Price $69.95 Now On Sale

Also Read

Data Privacy Rules Around the World

Data Security: 8 Privacy Principles Every IT Pro Should Know

Why the IBM i Community Needs to Pay Attention to GDPR