The biggest mistake a programmer can make is to design an application update or a new application without looking into the laws and regulations that may affect the application's design. Driving your compliance requirements is the type of data your application works with and stores. For example, if your application works with credit card data, it comes under the requirements of the Payment Card Industry's (PCI) Data Security Standards. If the application is working with financial healthcare information, you must abide by the Health Insurance Portability and Accountability Act (HIPAA). And so forth. While you, the programmer, are probably not intimately aware of the details of the laws and regulations affecting your organization, your compliance committee, the data's owner, or your organization's chief security officer (CSO) should be. You'd be wise to check with these people during the requirements gathering phase or the application's design phase to understand and account for your organization's compliance requirements.

Let's take a look at a few of the common compliance requirements that today's applications must accommodate.

Authentication

Some applications (typically applications that work with sensitive data) require users to authenticate themselves before using the application. The typical authentication mechanism is a user ID and password. The problem with passwords is that you have to make sure you enforce all password compliance requirements within your application. Typical requirements include no default passwords, minimum length of six characters, no reuse for at least four password changes, and the inclusion of at least one digit. The application must also force regular password changes and provide a secure mechanism for application users to change their passwords. As you can see, using passwords as an application's authentication mechanism can be complex and annoying!

An alternative to passwords is to accept a Kerberos ticket for authentication. For Windows applications, you can require that the user be authenticated to an entry in Active Directory. For an i5/OS application, you can use the General Security Services (GSS) APIs to accept and validate a Kerberos ticket passed to your application. While not widely implemented on iSeries, Kerberos tickets may be a significantly less complex method of authentication than implementing password authentication within your organization. Using Kerberos tickets can also enable single sign-on capabilities for your application.

Role-Based Access

Many auditors—especially SOX auditors—are advocating "role-based access." With role-based access, employees are assigned a "role" that is defined by the employee's position in the company and the tasks required to perform associated job responsibilities. The role is then authorized to perform specific tasks or have specific capabilities. For example, the accounts receivable clerk role may allow users to enter payments but not enter a new account. That task can be performed only by the accounts receivable manager.

Some applications lend themselves to easily enable role-based access. This is especially true when writing Java applications because of some of its built-in access methods.

If you are providing role-based access in your applications, you will want to add enough roles so that duties can be adequately separated. One of the biggest issues SOX auditors have is when one individual can perform an entire task or workflow without intermittent or final approval. Auditors want to see separation of duties. For example, for fraud prevention purposes in an accounts payable workflow, one person should not be able to add a new account, post entries against that account, and authorize that a check be written to the account. You need to have enough roles defined to allow someone to authorize employees to different roles that perform different steps in the workflow. Because of this, it's helpful to be familiar with the business process being accommodated by the application you're writing so that you can discuss ways to implement this requirement and determine, with the application and data owners, the best way to implement this type of control. A word of caution, however: You don't want to add so many roles that the application will be difficult or overly time-consuming to administer.

Access Controls to Data

Most regulations require that access to data—especially private data—be "deny by default." That is, unless specifically authorized, no user should be allowed to access the data. This is also known as providing access to data on a "need to know" basis. To implement the deny-by-default requirement on i5/OS means that you set the *PUBLIC authority of the physical and logical files to *EXCLUDE.

For new applications, the easiest way to implement access on a need-to-know basis is to put private data in a separate file. In addition, consider putting each type of private data in its own file. That way, if additional regulatory requirements come along for a specific type of private data, you will be better positioned to accommodate it. Also, by putting it in a separate file, you can more tightly control access to the data.

Unfortunately, most existing applications combine private information with non-private information. For example, the SSN may be in the same file as the employee's address. When private and non-private data reside in the same file, many people have access to the private data simply because they need access to the non-private data. To meet the requirement of restricting data to a need-to-know basis, you will have to provide a view of the file that doesn't include the private or company confidential data. Users can then have access to the non-private information without compromising the confidentiality and compliance requirements of the private data.

Use an Appropriate Security Scheme

Because many application files (if not all of them) have to be configured as *PUBLIC *EXCLUDE, you have to choose an authorization method that allows the data to be accessed when people use the application. The method you choose cannot open up the security of the data. For example, it would not be appropriate for you to dictate that the users of your application have *ALLOBJ special authority or be a member of the i5/OS profile that owns the application. Both methods provide users with too much authority to the application itself (as well as to other parts of the system in the case of a user having *ALLOBJ).

Configuring application programs to adopt authority is a more appropriate method of providing users access to application data. By using adopted authority, users will be able to perform the tasks the application has been configured to allow them to perform, but if they try to access the database files directly, they will be prevented from doing so (because the *PUBLIC authority has been set to *EXCLUDE.) Other methods to consider that can provide temporary authority to access application data are to swap profiles (using the QSYGETPH and QWTSETP APIs) and to run the set group identifier API, qsysetegid().

Avoiding the Penalties of the Law

Another reason to pay attention to compliance requirements is because of the steps you must take should the law be broken. Over half of the states have "data notification laws." These laws require that, if private data is lost or stolen or thought to have been lost or stolen, the organization notify the state's residents of the breach. The idea is that the residents must be notified so they can take steps to protect themselves from identity theft.

Obviously, you don't want your organization to be the next headline proclaiming the loss of private data. Protecting files containing private data (SSNs, driver's license numbers, bank account and PIN numbers, credit card numbers, and anything else your compliance committee and legal counsel define as private data) is in the best interest of your entire organization. Therefore, be aware of the classification of the data your application is working with and ensure that any file containing private data is configured as "deny by default."

Encryption Considerations

If your application stores credit card numbers, you must comply with PCI requirements. PCI requires that credit card numbers be stored encrypted in a file whose access is deny-by-default. One of the worst mistakes I see programmers make is attempting to create their own encryption scheme. PCI is explicit about the encryption algorithm and the encryption key strength required. It also has strict requirements for managing the encryption key. While creating your own encryption algorithm may be a fun exercise, it will never pass an audit by the credit card industry and is, most likely, easily broken. Cryptographers spend years perfecting and "proofing" their algorithms. To meet compliance requirements, you must use one of the algorithms specified by the law or regulation. Furthermore, depending on the law or regulation, you will have to carefully plan how to securely create the encryption "master key" and how to securely store and access the application's encryption key. For example, reading PCI's encryption algorithm and key management requirements will dictate your encryption implementation.

Auditing or Logging Requirements

Many client/server applications, including WebSphere applications, authenticate the user on one system and access a database—often an i5/OS DB2 database—on another system. Unless you're dealing with electronic protected healthcare information (which falls under the requirements of HIPAA and can require logging when data is read), it is likely that no additional logging is required. However, if the i5/OS database is updated, additional logging is probably required on the client. The problem with many client/server applications is that all database updates are logged as the same (server) profile. This means that the i5/OS auditing and database journaling functions can't log the actual user who initiated the addition or update request to the database. Many regulations consider this a problem. Therefore, if you are writing a client/server or WebSphere application and it makes modifications to a database using a generic profile, you will need to add logging to the client side of your application to ensure a record is kept of the exact user and exact database change request being made. If the client or WebSphere application server is running on i5/OS, I recommend that the log entries be written to a journal, because entries in a journal receiver cannot be modified or deleted. If it's on another platform, then the audit information needs to be written to a log file that has been configured as deny-by-default to prevent all but administrators from being able to access or modify the log. The log entry should include enough information to identify the action taken, the time the action was taken, and the original transaction user.

Connecting to Another System

Another aspect of many client/server applications is not just that the database access is performed as the same user but the connection to i5/OS is made using this generic profile. To accomplish this, the authentication information (in other words, the user ID and password) for this generic profile is typically hard-coded in clear text somewhere in the application—often in an unsecured file in the Integrated File System (IFS) or in a program's source file. Storing passwords unencrypted is a compliance issue for many regulations and complying with the requirement to regularly change these hard-coded passwords is nearly impossible.

If you are connecting to i5/OS using the AS/400 object in the Java Toolbox, IBM has made it very easy to use something called an "identity token" to eliminate the password exposure. (Even if you're not using this method, you can still use identity tokens.) Identity tokens use Enterprise Identity Mapping (EIM) to allow the system to recognize the token coming in from your application and run the i5/OS job as the generic profile associated with your application. While you don't eliminate the need for additional logging, you do eliminate the issue of hard-coded, clear-text passwords because, using this method, the generic profile doesn't need a password on i5/OS. By not having a password, you significantly reduce the risk of the generic profile being exploited.

Watch the Implementation

I can't emphasize enough that the implementation of the application is just as important as the design. I have seen many well-designed applications be "opened up" from a security perspective because they were poorly implemented. Care needs to be taken to make sure that the object authority on the application's objects does not default to the typical i5/OS setting of *PUBLIC *CHANGE. With careful planning and attention when the application is implemented, i5/OS applications can, without a doubt, meet today's compliance requirements and be well-positioned for new requirements that may arise in the future.

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