OS/400 Security Compliance Handbook
Week 3:
Implementing Compliance Requirements for Protecting Data
Last week we talked about some of the laws with which your organization may need to comply. This week we’re going to discuss compliance requirements for protecting data.
Data – if you think about it, data is the cause of all of the laws we discussed last week. No data to steal or abuse or illegally modify and we wouldn’t be having this discussion! So the first thing you need to determine is whether the private or confidential data you’re retaining really needs to be retained. Obviously if you are a hospital or health insurance provider or you are a retailer that accepts credit cards, you are retaining private data and need to continue to do so. But if you are an organization that started to use a person’s social security number (SSN) or social insurance number (SIN) in Canada because it was a convenient way to ensure a unique account number, you need to seriously consider changing that practice. A lot of compliance issues are being placed on your organization unnecessarily if this practice continues.
Once you determine what data you are going to continue to retain, I recommend that you classify the data. Data classification often means that you label the data as “public”, “confidential”, or “top secret” but in this case, I want you to classify each database by the type of data it contains – healthcare information, credit card information, other private information (SSNs, bank account numbers, etc) company confidential, general company information (that anyone can read) etc. Classifying the data in your databases will allow you to determine what laws and regulations you need to comply with.
It's pretty clear from HIPAA, GLBA and the Visa PCI requirements that access to files containing healthcare, financial or card holder data needs to be configured so that they can only be read on a need-to-know or least privilege basis. In other words, the *PUBLIC authority of these files needs to be set to *EXCLUDE and only users whose job function requires it have authority to actually access the files.
At this point I need to explain the concept of "least privilege.” Least privilege is where a user is only able to access and is only given the capabilities required to perform their job function. This concept is specifically mentioned in Visa’s auditor guidelines for Visa PCI compliance. Least privilege supports the security and access control requirements of the Payment Card Industry (PCI) as well as GLBA and HIPAA. Users are prevented from accessing any application or system resources that are outside the scope of their job function. In other words, the system, applications and application functions are “locked down” and not accessible except when it is part of their job responsibility to do so. This is often the exact opposite of the way applications are implemented today. Don’t misunderstand – business logic within an application is often implemented this way; however the actual implementation of the access controls on the application’s database files allows this logic to be by-passed.
Today, most application objects are available for direct access by the general user community with only a few objects (e.g., HR database files) configured for restricted access. With the “least privilege” concept, the only functions and resources the user has access to – no matter what interface he or she attempts to make them through – are the functions directly related to performing their job function. And, in most cases, the user can only perform the function through application interfaces – not direct access from a command line, FTP, ODBC, etc. This is especially true of data updates or modifications. It should be rare that access to a file is configured so that a user is allowed to modify or otherwise update data without going through the application logic. In other words, it should be the exception, not the rule that users on OS/400 be granted a private authority or the public authority of a file be set to *CHANGE.
How does one implement the concept of “least privilege?” Through prudent use of object authorities. Setting the appropriate object level or *PUBLIC authority will ensure that the level of access is guaranteed – no matter how the object is accessed. Before you totally panic at the thought of implementing object level authority, remember, that a great deal of security (access control) can be achieved simply by restricting access at the library or directory level. Take an HR application – should the general user community be able to access this application? Doubtful. So you can set *PUBLIC to *EXCLUDE on the application libraries and authorize the human resources group to the libraries. Note that you may need to accommodate other processes such as timekeeping applications so that they can also access the files in the libraries. But, in general, simply restricting access to the libraries or directories containing the confidential data provides significant improvement in the security and implements the concept of “least privilege.”
Perhaps you’ve read down to this point and are thinking (very smugly) that you have nothing to
worry about. Your system contains no healthcare information, no HR information, no accounting
information, no credit cards and no bank account numbers. It simply runs the manufacturing and
inventory applications for your company. Here’s where I have to agree with those people that argue
that SOX implies data security. If you look at the spirit of the Sarbanes Oxley Act (SOX) – that is,
