Knowing what to do--and what not to do--can help you get into compliance and stay there.

Editor's Note: This article is an excerpt from "Compliance Without the Complexities," a free handbook that you can download from the MC White Paper Center.

The purpose of this article is to highlight the various aspects of compliance, specifically how to attain and maintain compliance. Many organizations have attained compliance, but a common complaint we hear is that maintaining compliance takes too long and costs too much. Through the practical experience of helping our clients--both large and small--attain and maintain compliance, we have built up a treasure chest of tips and techniques to help every organization address its compliance needs.

This article touches on the issues underlying compliance and highlights what areas of expertise you must develop to achieve compliance and avoid falling out of compliance. A more detailed treatment of these issues, including tips for maintaining compliance--what we like to call developing and maintaining a "compliance lifestyle"--can be found in our free handbook, "Compliance Without the Complexities." This article is based on material found in the handbook.

Determining What Compliance Means

One problem facing many of you is determining what compliance actually means to your organization. We are bombarded with ads for products that will help us "be in" or "attain" compliance. But what does this actually mean?

Compliance is defined in one dictionary as "Conformity or acting according to certain accepted standards." Another definition is "Conforming to a specification, standard or law that has been clearly defined."

I think the problem for most of us is the phrase "...that has been clearly defined." In talking with many users, "compliance" is anything but clear.

The first task in your quest for compliance is to determine exactly what it is that your organization needs to be in compliance with.

Common Compliance Requirements

While laws and requirements continue to rapidly evolve, let's look at the more common compliance requirements affecting organizations today:

• Payment Card Industry (PCI) Data Security Standards (DSS)
• Sarbanes-Oxley Act (SOX) and similar bills
• Worldwide financial sector
• Canada
• Individual states

Where to Turn for Guidance?

Because most of the laws and regulations are vague as to the actual specifications of how one actually achieves compliance, and almost none gives any implementation hints, organizations are turning to a variety of standards for guidance on attaining and maintaining compliance. Implementing your security configuration according to security best practices is the best method of proactively preparing your organization for attaining and maintaining compliance.

Defining Your Policies

I believe that all organizations have a policy, though for some it may just be in employees' heads. Why do I make that claim? Because when I work with our clients who don't have a written security policy and I ask them what their data access policy is--that is, whether users should be able to access application data outside of the protection of the application logic--they are always able to answer the question. I'm hoping that a discussion on security policies will help people actually get those policies down on paper, approved by management, and communicated to the organization. But just in case you still have some doubts, let's understand that a written security policy is a necessity. If an organization sees no other business benefit from having a formal security policy, they need to realize that having such a policy is required by many regulations, including the PCI's DSS and laws such as the U.S.-based Health Insurance Portability and Accountability Act (HIPAA).

Data Types and Security Requirements

Data--specifically the type of data and the actions that can be taken on that data--is the cause of every law relating to compliance. The type of data in your database files and tables determines the security requirements of the data. Therefore, the first thing I recommend people do is classify their data. You don't have to classify every field to be effective, but making an attempt to classify your data ensures that it will be handled appropriately. Things to define when you classify data include who (what roles) should have access to the data, how long data should be retained, what the disposal methods are, and whether data access is denied by default or read-only.

Reducing Your Risk

Regardless of what law or regulation is involved, its intent is to reduce risk to the data. For example, SOX addresses the need for data integrity, and PCI addresses the need to protect cardholder data. One of the methods for reducing your compliance efforts as well as reducing risk to data is to reduce the propagation of the data. Instead of subsetting personal information and propagating only the non-private information, companies often replicate entire files for use by other applications, copy the data into network file servers or data warehouses, or download it onto spreadsheets. By limiting propagation to only the non-private data, the risk to the private data is greatly reduced.

Encryption Considerations

One aspect you must consider when determining the scope of your compliance requirements is encryption. As most of us are aware, the PCI DSS has significant encryption requirements for both the transmission of credit-card information as well as cardholder data at rest. Other laws and regulations have requirements to encrypt the transmission of data over public networks, and some strongly encourage its use for data at rest. Finally, most of the breach notification laws have exemptions stating that if the lost or stolen data is encrypted, individual notification is not required.

Implementing Compliance Requirements

ISO17799, HIPAA, GLBA, and the PCI DSS all have specific requirements when it comes to user access. We discuss the concept of "least privilege" in our literature and explain how it pertains to accessing data. Another aspect of least privilege is the capabilities given a user. In i5/OS or IBM i, this translates into what special authorities are given to the user and what group profiles administrators place them in. Another security concept with which you should become familiar when considering compliance requirements is that of "roles" and "role-based" access.

User Management

Before looking at the various requirements dictated by laws and regulations, it's helpful to understand why proper user management is important. User management needs to be part of your routine system management processes. I believe that good user management requires that you have a process for creating new profiles, have a process for removing inactive profiles on a timely basis, require users to have strong passwords that are changed regularly, review user access to applications as well as the system itself, and make sure that users are not given more capabilities or access to system resources than is necessary to perform their jobs (at the very least).

Requirements That Drive System Configuration Settings

If you have read any of the compliance laws or regulations, you know that they are not so detailed as to spell out the exact settings for each operating system and application. Rather, they are written using generic wording and aimed at such a level so as to apply to any operating system and application. Some translation must occur from the wording of the various laws and regulations in order to know how to properly implement each requirement on the operating systems and applications within your organization.

Preparing for Audit

If you know that an auditor is coming, you need to prepare ahead of time. Don't wait until the day the auditor shows up to attempt to get your processes updated or run the reports they may have already requested. You want to start impressing your auditor the minute he or she walks in the door. We discuss ways to impress your auditor in our literature, but you may wish to ask yourself why an auditor is paying you a visit in the first place.

Security Processes

A friend was recently in a compliance training seminar, and the speaker said that the primary reason many organizations were failing their PCI DSS audits is because they didn't have their policies and processes documented. Why not? They were focusing too much on implementing the technology! SOX auditors focus on having processes documented. Processes must be documented for several reasons, including to assure the auditor the processes are thought-out and understood, to show proof that an action has taken place, to observe the process is being followed, and to ensure consistency in how the process is being performed.

Creating a Security Incident Response Plan

The Boy Scout motto-always be prepared-is what comes to mind when addressing this aspect of security compliance. Many laws and regulations (including the PCI's DSS) require that a section of your security policy address the need for a security incident response plan. And isn't that something you'd feel more comfortable knowing you have anyway?

The Security Awareness Program

Beyond the fact that a security awareness program is a requirement of many laws and regulations, it makes great business sense to develop a security awareness program in your organization. Many security problems can be avoided by educating your employees about the ways they can help to ensure that the security of your data is not compromised.

What Is a Risk Assessment?

A risk assessment is a thorough analysis of the security configuration of your system. By running an assessment of your security configuration, you can determine what issues exist on your system. An assessment should include (at least) an examination of the object-level authorities, the TCP/IP configuration settings, the various user profile settings, the issues with adopted authority, the commands run by limited capability users, and the system value settings, to name a few. Risk assessments are required by some laws, such as HIPAA and GLBA, as well as the PCI DSS standards and ISO17799.

Security Is a Business Process

Once you have run an assessment, identified the issues, categorized them, put work plans into place, fixed the most critical exposures, and written your business risk acceptance statements, you may think that you are done. Unfortunately, security is not a one-time project. It's a business process that needs to be addressed on a perpetual basis. It's more a lifestyle--the "security compliance lifestyle."

To learn more about how your company can attain and maintain compliance, download the handbook "Compliance Without the Complexities."

 

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

Authentication and Authorization: Why? Part 4: PAM Systems

Authentication and Authorization: Why? Part 3: A Word About Privileged Account Management

Authentication and Authorization: Why? Part 2: Query-Response Language & Policies