I find that many of our clients are re-working the structure of their applications because of the increased focus on regulatory compliance as well as more strict requirements from both internal and external auditors. When re-architecting for compliance, several issues must be addressed. Let's take a look.

Determine the Requirements

If you've read any of my articles on compliance, you know that my first piece of advice is for you to determine what laws and regulations your organization must comply with. Espousing an architecture that will supposedly put your applications in compliance is worthless if you make decisions that leave the organization out of compliance. Sources with which you might confer to determine the laws and regulations include the data owners, your Chief Security Officer (CSO), legal counsel, and publications associated with your industry sector. Once you understand the requirements, you can embark on the task of creating your new architecture.

It's All About the Data

The laws and regulations with which you must comply depend on the data that is stored on your systems. For example, if credit card numbers are stored, your organization must comply with the Payment Card Industry (PCI) Data Security Standard. Because it's all about the data, it is vital that your architecture reflect the appropriate classification of data. The appropriate classification provides answers to the questions below. If data is not classified, you are leaving your developers and system administrators to determine the following:

• Who (what role) has access to the data—How is the programmer supposed to know what roles are allowed to view application data? It is vital that this be defined based on the type of data. For example, the regulations for Heath Insurance Portability and Accountability Act (HIPAA) data state that only users whose job responsibility it is to work with the data be allowed access. Unless the data is properly classified, the design and implementation of the application could easily cause your organization to be out of compliance.
• How the data is secured—In other words, is the data available to the general user community? Or is it to be defined as "deny by default"? This decision determines the application's default access setting (or, in i5/OS terms, the *PUBLIC authority setting) of the database files. Without making the specification, the *PUBLIC authority of data files defaults to the value of the QCRTAUT (Create authority) system value. This value defaults to *CHANGE, but I have seen some administrators set this system value to *ALL.
• How long the data is retained—Most likely, industry regulations will drive this requirement. For example, the finance industry requires that data be retained for a minimum of seven years. If your organization's industry sector does not have specific requirements, your organization should determine the retention period based on the needs of the business.
• What method should be used to dispose of the data—While there may be no regulatory or legal requirements for the type of data your organization retains, common sense says that certain types of data need special disposal instructions. For example, your organization may determine that all information classified as company confidential needs to be cross-cut shredded. And I don't mean just printed data; you should define how to properly dispose of all electronic media containing the data.
• Whether the data needs to be encrypted—Some data, such as credit card numbers, must be encrypted while at rest. HIPAA data is required to be encrypted when transmitted outside of the network. Private data, if compromised, may escape the various state breach notification laws if it was encrypted when the breach or loss occurred. This part of the data classification definition should consider whether the data should be encrypted during transmission, when at rest (e.g., stored in a database file), and/or when saved. Make sure to specify the algorithm that should be used as part of the definition.
• What use of the data is appropriate—For example, the data classification definition may state that the use of private data is strictly limited to those whose job responsibility it is to maintain the data and that all access to private data—even through application interfaces—must be approved by the data owner. This ensures that the data owner has complete control over who (what roles or applications) has access to their data. I've seen examples where a new application is being developed that requires some human resource information. The natural tendency of programmers is to pull the information from the employee master database. But that database has social security numbers, payroll data, and other private information. If this aspect of the data classification is properly defined, the human resource data owner receives the request for the application to be able to access the human resource data, but instead of allowing access to the full database, the data owner will direct the developer to query a different file containing the information or a view of the employee master file that does not contain private data.

Unfortunately, when organizations hear the term "classification of data," they automatically assume that means classifying every field in every file in every application they've written. While that would be a good thing to do, I've never seen an organization complete such a task. Therefore, I suggest a different approach. It is quite possible that adequate controls can be put into place by taking a broad sweep and classifying the file (instead of all fields in the file.) Or perhaps you could take a slightly larger sweep and say that all files in a particular library belong to a particular classification. The broadest statement of all would be to classify all files in a particular application. Whichever you method you choose, some type of data classification is better than no data classification. Leaving the decisions of how data is secured, retained, etc. to your development staff or system administrators is totally inappropriate and virtually ensures that your applications will be out of compliance.

Appropriate Authorization Methods

Because your data specification will state the default *PUBLIC authority settings, you need to describe the application authorization methods that are approved for your organization. For example, if the use of adopted authority is the preferred method of providing applications with sufficient authority to run, that should be stated in the architecture document. Other methods you may want to discuss include the approved method of swapping of profiles, occasions to use authorization lists, and considerations when working with Integrated File System (IFS) objects. And, of course, you want to mention the methods that are not allowed, such as using objects' *PUBLIC authority setting and requiring users to be a member of the group that owns the application.

Ownership

Another aspect to address in your architecture is that of object ownership. In general, you probably want to discourage (or disallow totally) the use of IBM profiles for owning application objects. In addition, you want to describe when a new profile is required or when another profile created to own application objects may suffice for the new application.

Logging

Your architecture must address the logging requirements of your data. For example, if you have HIPAA data, all changes must be logged. In i5/OS terms, this requires that files containing HIPAA data be journaled. Depending on your legal counsel's interpretation of the regulations, you may also have to log every read of the data. Make sure you understand the requirements for each type of data and document the requirements in your architecture. Not only should you describe what actions to log, a description of where the logging must occur may be required. For example, if your organization has implemented or is considering implementing a WebSphere application, an i5/OS database file is the back-end data store, and the WebSphere application performs reads and updates to the file all under the same profile. In this case, the logging must occur in the WebSphere application because the audit logs in i5/OS will not contain sufficient information to be able to uniquely identify who performed the transaction.

Roles

While this may be an unfamiliar term to some, the concept of roles is not new. "Green-screen menus" have been providing the concept of roles for years. In a menu environment, users see more or fewer menu options, depending on their role. This concept can be applied to all applications, including WebSphere, client/server, etc. In the architecture, you'll want to ensure that applications implement the concept of roles and that all applications provide a sufficient number of roles so as to provide separation of duties. (This is especially critical when working with financial applications because SOX requires that organizations implement separation of duties, especially working with financial information.) There is a fine balance between providing too many or too few roles, thus making it difficult to maintain and difficult to provide adequate separation of duties. So include in the architecture the guidelines for determining how many roles are required.

It's All About the Architecture

Regulatory compliance within the application development world may be a mystery, but with research and planning, the architecture can guide your programming and system administration staffs, ensuring that your organization's data is in compliance.

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