It's one thing to instruct programmers to write security-responsible code and to demand that administrators maintain it; it's another for them to actually know what that means. Someone has to start the "compliance" ball rolling. Who exactly does that, and how do the compliance requirements get filtered down through an organization?

Compliance Begins at the Top

Somewhere in an organization, someone realizes that unless "things" occur, the organization isn't going to be in compliance. This epiphany may occur with the CEO, the board of directors, the organization's legal counsel, or the director of IT. It doesn't really matter where the idea comes; what matters is that upper-level management agrees with it, approves plans for it, and funds it. Once upper management decides that the organization must be in "compliance," they typically appoint one person to be in charge of said compliance. At this point, there is often no definition of what exactly the organization must be in compliance with, and most certainly, there are no implementation details available for programmers or system administrators.

The person anointed to be in charge of compliance may be the Chief Security Officer, the Chief Compliance Officer, the director of IT, or some other person (hereafter referred to as "the appointee"). It doesn't actually matter who the appointee is as long as this person has upper-level management support, funding, and power to effect the changes required by the organization to become compliant. Depending on the size of the organization, the appointee may work alone on the task of bringing the organization into compliance. Or, in larger organizations, the appointee typically forms a committee to address compliance issues. Unfortunately, in some organizations, management heaps this responsibility onto an already overworked system administrator!

(Note: Numerous aspects of "compliance" exist. For example, one aspect of SOX compliance means that the finance department must follow general accepted accounting principles, etc. This article focuses on data compliance issues.)

Determining What Compliance Means to an Organization

An organization's IT compliance requirements hinge on the data stored on the systems. Obviously, if data stored on the system falls under the definition of Electronic Protected Health Information (EPHI) under the Health Insurance Portability and Accountability Act (HIPAA), the organization must follow HIPAA's IT-compliance requirements. If credit card information is stored on the system, the organization must comply with the Payment Card Industry's (PCI) Data Security Standards. The first thing the appointee must do is determine the type of data stored on the organization's systems so the process of determining what the organization must comply with can begin.

In addition, some compliance requirements are based on an organization's specific industry segment. For example, the finance industry has specific data retention policies. If the appointee isn't familiar with these industry requirements, speaking with the organization's director of IT, legal counsel, and database administrator (DBA) should provide enough information or pointers to documentation to be able to derive the compliance requirements.

Much less obvious, but still important to discover, are laws enacted by the states in which the organization operates. For example, over 25 states have enacted "breach notification" laws. These laws require that organizations that retain state residents' private information notify those residents if the data is compromised. Unfortunately, states have not been consistent in writing these laws, so the appointee will need to read the law for each state in which the organization does business. Also, if the organization is multi-national, the appointee will need to research the data privacy and breach notification laws of the appropriate countries. The organization's legal counsel may be able to help clarify questions in this area as well as determine how the laws apply to the organization.

What can easily be missed in this analysis is data that falls outside of any regulatory or legal-compliance requirements but is critical to the organization. The organization itself needs to have compliance requirements for this type of data.

Classification of Data

The appointee's analysis should lead to a formal classification of data if this hasn't already been done. This information is then documented in the organization's security policy, and examples are provided in the standard for each operating system. The documentation defines each level of data and identifies how each level of data is to be handled. The exact terminology used for each level is unimportant as long as it is easily understood by those reading the documentation and those tasked with ongoing data classification. It is also unimportant how many levels are defined. You need as many as necessary to distinguish between levels of data. Too many levels and things will be too complex. Too few and the appropriate controls cannot be applied to the data. Here are some examples of levels or classifications of data:

• Private—Private data includes social security numbers (SSNs), bank accounts, etc. It is important that the policy state the organization's definition and provide examples of private data. I've seen this definition vary between organizations. Having a specific definition eliminates the guesswork for the system administrators and programmers working with the data.
• Credit card numbers—This definition includes what part of the credit card information can be stored, which parts must be masked when displayed, etc. If these details are not in the policy itself, a reference to where these details are kept needs to be provided. This is vital information that programmers can then refer to when writing applications that deal with credit card numbers.
• Company-restricted—This data is restricted to a subset of employees. Salary information is an example.
• Company-confidential—This data can be viewed by all employees but is not for general use. The company's financial information may be an example.
• Public—This data can be viewed or used by employees or the general public. A retail price list is an example.

As part of the definition, the following should also be provided:

• Who (what role) has access to the data—An example of information provided by this statement is "private data is to be accessed only through the application providing the information unless the data owner grants specific approval."
• How the data is secured—An example of this statement is "access to private data is to be 'deny by default.' " This is where the corresponding operating system standard is vital. Compliance cannot be attained unless this statement is implemented properly. Each operating system standard needs to provide examples of properly securing each type of data using the respective operating system terminology and user interfaces.
• How long the data is retained—This is where industry-specific retention periods should be documented. Lacking specific regulations, organizations should determine the retention period based on the needs of the business.
• What method should be used to dispose of the data—Examples of information that should be provided for this are "all hard-copy reports containing private data should be cross-cut shredded." Or "deleting databases containing private data must be rendered unreadable." The operating system standard should further expand on this topic. For example, the standard for Windows may describe the "scrubbing" or "bleaching" software that is to be used when deleting private data from a PC.
• Whether the data needs to be encrypted—If the data needs to be encrypted, the method of encryption must be described. This should also include whether the data in transmission needs to be encrypted (using an SSL session, for example). The corresponding operating system standard should describe the methods (third-party software, hardware, or integrated operating system functions) used to encrypt the data.
• What use of the data is appropriate—For example, the policy might state that "use of private data is strictly limited to those whose job responsibility it is to maintain the data." All access to private data—even through application interfaces—must be approved by the data owner. This statement prevents a department outside of HR from having a programmer write a program that provides all employees' social security numbers without first getting approval from the HR director (that is, the owner of the data).

Keeping Up

To ensure that the appointee stays current with the latest compliance requirements, he or she must spend time reading and doing research. For example, trade publications for the organization's industry segment often have articles on new or changing regulations as well as warnings about upcoming compliance deadlines. General-information security publications and publications specifically targeted at the Chief Security Officer often publish compliance-related articles.

In addition, the appointee needs to keep up with where the organization is going with technology. Expanding the business into e-commerce, for example, has obvious compliance implications if the business starts to collect and retain customers' credit card numbers.

Maintaining Compliance

An organization's compliance status can start to degrade because of, for example, personnel changes, a disgruntled employee who circumvents the process because he "can't get the job done any other way," or a new application that collects customers' private data is proposed for the organization's Web site.

To maintain compliance, the appointee needs to work with the DBA and/or programming staff to understand new and changing applications. In addition, the appointee—together with system administrators and programming managers—needs to develop tests and tools that can easily verify that system and application configuration settings remain in compliance with the policy and that processes developed when compliance was first addressed are still being followed. For example, application objects should be examined to ensure they maintain the approved security settings. Objects will have the correct settings if the change management process is followed (properly configured, change management software takes care of this for the programmer). However, a programmer who has the capability may bypass the change management process. Regularly checking the application's configuration confirms compliance with the organization's policy as well as the change management process.

In addition, the entire security policy needs to be reviewed and approved by upper management and new or updated sections disseminated to the appropriate groups. This exercise should occur at least annually or whenever a major technology shift or organizational change occurs. For example, if the organization creates a Web site that collects and retains credit card numbers, the organization's data classification section must be updated. Furthermore, the appropriate operating system's standard must include the requirements of complying with the PCI data security standards.

Most organizations have a policy specifically written for every employee to read and sign. This often occurs during new-employee orientation. But management in IT has an additional responsibility to ensure that new employees in their area are educated on the parts of the policy and corresponding standards that pertain specifically to them.

Communication Is Key

The changes that IT must go through to resolve data compliance issues usually require significant effort. Staying in compliance also requires effort. In particular, it requires good communication between the appointee, system administrators, and the programming staff to ensure all parties continue to understand all aspects of their organization as well as any regulatory issues that affect their organization's data compliance requirements.

Carol Woodbury is co-founder of SkyView Partners, Inc., a firm specializing in security policy compliance and assessment software as well as security services. Carol is the former Chief Security Architect for AS/400 for IBM in Rochester, Minnesota, and has specialized in security architecture, design, and consulting for more than 15 years. Carol speaks around the world on a variety of security topics and is coauthor of the book Experts' Guide to OS/400 and i5/OS Security. 

 

Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting 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 practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known worldwide 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, including her two current books, IBM i Security Administration and Compliance, 3^rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. 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
		Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.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