In this article, Carol Woodbury discusses the issues surrounding compliance as well as items to address to remain in compliance.

I wish I had a magic formula for ensuring that your organization's security configuration was in compliance. Unfortunately, it's just not that easy. It seems that there's at least a slight twist to every organization's compliance implementation. This article endeavors to provide guidelines for you to use to determine how best to attain and remain in compliance.

First, you must determine exactly what your organization needs to be in compliance with. How do you determine this? Some organizations have formed a compliance committee, or you may have a chief security officer (CSO) or chief compliance officer (CCO). If that's the case in your organization, you're probably already receiving direction from them. If that's not the case and you have to make the determination yourself, then you need to do a bit of investigation. Reading articles such as this one will help you understand compliance from an i5/OS perspective, but you should also do research in your vertical sector to help you understand the current and future compliance requirements specific to your organization's line of business. For example, if you are in the financial sector, you most likely have to comply with the Gramm-Leach-Bliley Act as well as Basel II. And later this year, you'll have to comply with the Identity Theft Red Flag regulations. Keeping informed of specific regulations associated with your organization's line of business is key to remaining in compliance. Next, government organizations (both U.S. and non-U.S.) have their own standards and regulations with which you must comply. Finally, you may have compliance requirements based on the state or region in which you live or the country in which your organization does business. Paying attention to general business news will typically give you the heads up on government laws and regulations.

Next, I recommend that you read the actual laws and regulations yourself. I believe it's important that you read the law or regulation for yourself so that you're not relying on someone else's interpretation. Relying strictly on someone else's opinion leaves you open to implementing something unnecessarily or improperly. And, as an added benefit, they're a great cure for insomnia!

What You Can Do

After you determine what you need to be in compliance with, identify the items you'll need to address to meet the security compliance requirements of the most popular laws and regulations:

Item #1: Make sure your organization has a security policy and that it's reviewed and updated at least annually.

Many of the laws and regs require a security policy, but beyond that, a security policy just makes good sense. A security policy documents your organization's security requirements and assigns responsibility for implementing those requirements as well as the consequences of not following the requirements. Without a formal security policy, you cannot know for sure whether your security configuration meets your organization's requirements.

Item #2: Implement security best practices throughout all system and network security configurations.

For guidance on what constitutes security best practices, I like to use the requirements of the Payment Card Industry (PCI) as defined in their Data Security Standards (DSS). This is the only standard that I'm aware of that describes security requirements in enough detail that you can actually implement them. The rest of the laws and regulations (including Sarbanes-Oxley) provide only generalized guidance with few or no details. Independent sources from which you can find guidance for security best practices include the 27000-series ISO standards, CobiT, and National Institute of Standards and Technology. For i5/OS guidance, you can consult the iSeries Security Reference manual or my book, Experts' Guide to OS/400 & i5/OS Security, but here are a few things to get you started:

•·        Eliminate default passwords.

•·        Require strong passwords (changed at least every 90 days, require a digit, minimum length of at least seven characters, cannot be repeated for at least four times).

•·        Promptly remove profiles after 90 days of inactivity.

•·        Give users only enough capabilities (special authorities) to do their jobs.

•·        Give *ALLOBJ authority only to trusted (i.e., a handful of) users.

•·        Set *PUBLIC authority of files containing private or company confidential information to *EXCLUDE.

•·        Run at security level 40 or 50.

•·        Turn on i5/OS auditing.

Item #3: Implement compensating controls and document mitigating factors for areas where risk remains but you have determined that best practices cannot be implemented.

While implementing security best practices is going to be your goal, in practice it is rare that organizations can fully implement best practices in all areas of their business. When that happens and risk continues to exist, you want to mitigate that risk wherever possible. To ensure auditors understand the business logic and reasoning for these situations, you'll want to document any controls that you have implemented that reduce the risk as well as any factors that cause the situation not to be as risky as it may seem on the surface. For example, while all profiles need to have their passwords changed at least every 90 days, application profiles need to be handled differently and will break if they start to receive the password expiration warning messages; therefore, you have changed the application profiles' Password expiration interval attribute to be *NOMAX. This is not a good security practice because, in theory, the profiles never have to have their passwords changed. However, you have a compensating control: a documented process that requires administrators to change these passwords every 90 days.

Item #4: Implement encryption where required (e.g., when transmitting healthcare and PCI data over public networks and for cardholder data at rest).

Some regulations such as the PCI DSS, require data "at rest" to be encrypted. Other regulations such as HIPAA require the transmission of data to be encrypted. Regardless of the regulation, don't try to implement your own encryption algorithm. Rather, use well-known algorithms and carefully plan out your key management strategies.

Item #5: Perform regular backups, periodically verifying that the backups are actually occurring!

Hardware fails, files are accidentally deleted, and data gets out of sync. Regardless of the cause, there are times when you have to get data back from your backup media. Determining what is being backed up and verifying that the backups actually occur is a part of your compliance strategy that cannot be ignored.

Item #6: Have a documented and tested disaster recovery plan.

This item is pretty self-explanatory. Even if you are in an organization that has no compliance requirements, developing and testing a disaster recovery plan is vital to the integrity of your business. Should disaster strike and you have no recovery plans, chances are your organization will not be able to recover and will either go out of business or suffer significant losses.

Item #7: Implement change management.

Implementing a formal change management process and software package is high on the list of priorities of SOX auditors. In addition, this is another item that just makes sense from a business perspective. Change management allows a point of communication so that everyone is aware of the changes going into production. In addition, a properly configured formal change management software package creates separation of duties. That is, programmers cannot promote their own code. This provides the opportunity for someone other than the programmer to examine or review the code one last time before it goes into production.

Item #8: Document your organization's IT processes.

This is another item that stems from observing our clients' SOX auditors. SOX auditors, more than other auditors, require that processes be documented. The processes that are required consistently from all of our clients include these:

•·        User account creation

•·        User account removal, including procedures for both normal attrition as well as employee dismissal (expecting that the dismissal case has actions that may be taken more immediately than when someone simply leaves the company)

•·        Requests for access to data outside of the user's job scope

•·        Change management requests

•·        Backups

•·        "Patch" (PTF) strategy

Item #9: Review user privileges and access controls to sensitive (private) data at least annually.

One aspect of implementing security best practices is to rework who has authority to your organization's applications and especially files containing critical or private data. Security best practices dictates that data be "deny by default" or, in i5/OS terms, *PUBLIC authority *EXCLUDE. However, there are times when a handful of users or outside processes need to be given private authority to a file. Without regular review of who has access to these files or application menu options, it is likely that over time users will have access to data or menu options that they no longer have a business justification to access.

Another aspect of implementing security best practices is to reduce the capabilities of users to only those required for them to perform their job functions. This is the concept of implementing "least privilege access." In i5/OS terms, this means giving users only the special authorities required for them to perform their job functions. Again, without regular review, users may change jobs or application requirements can change and users may have more capabilities than they require.

Item #10: Educate your employees through a security awareness program.

Your employees can be one of your biggest assets in preventing security incidences. But that will only be true if you take the time to educate them on the latest security threats, the appropriate use of confidential and private data, and the methods to recognize and report suspicious activity.

Item #11: Test your security configuration frequently so that non-compliant items are identified (and fixed) quickly.

Your security configuration can easily fall out of compliance. For example, user accounts get created with a default password, programmers promote programs causing them to own the program rather than the application owning profile, security-relevant system settings (i.e., system values) get changed, etc. So it's important to regularly check the compliance of your security configuration and address the issues (non-compliant items) as they arise. Otherwise, you'll be spending as much time and effort to get back into compliance as you did getting into compliance in the first place. In addition to this being a critical step to staying in compliance and saving you time, it's a requirement of several regulations, including PCI's DSS. Finding ways to automate your compliance testing, rather than spending your time testing and comparing the results by hand, will save your organization significant resources (and save your sanity as well!).

Item #12: Perform a security assessment at least annually to identify areas of vulnerability.

An annual assessment of your system's security configuration is a requirement of several regulations, including HIPAA, GLBA, and PCI's DSS. The assessment requirement is meant to keep you on top of continuous system configuration changes and the security implications of new technologies. The assessment that will benefit you the most will be broad in nature, giving you the best representation of how your system's security configuration stacks up against security best practices settings.  

 

Carol Woodbury is President and CTO of DXR Security and has over 30 years’ experience with IBM i Security. She started 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 current company - DXR Security - specializes in penetration testing for IBM i. Her practical experience together with her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known world-wide 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. 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
		IBM i Security Administration and Compliance: Second Edition Get the must-have guide by the industry’s #1 security authority. List Price $71.95 Now On Sale
		IBM i Security Administration and Compliance For beginners to veterans, this is the definitive security resource. List Price $69.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