Wed, Jun
4 New Articles

Security Compliance and Noncompliance

Compliance / Privacy
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

Over the last year, I have been asked questions like "Is iSeries SOX-compliant?" or the same question with "SOX" replaced by any of your favorite government security regulations or industry standards. This question is normally asked with the expectation that computer system vendors can somehow build computer systems that are inherently "compliant" with arbitrary regulations or standards. These questions indicate a basic lack of understanding of the process of securing a computer system hosting business assets.

Absent a basic understanding of the security process, compliance with any regulation or standard will be hopelessly confusing and seemingly complex. So let's take a brief look at the security process. The process of securing anything can be broken down into three phases: 1) defining who can access what and for which purposes, 2) configuring security mechanisms to implement the access defined in the first phase, and 3) measuring how accurately the defined access has been implemented.

Phase 1 defines your security policy. Security policies are inherently specific to each organization. For any given security policy, there are numerous possible implementations.

Phase 2 involves implementing your organization's security policy. Policies are implemented using tools and mechanisms provided with the computer system, purchased from a third-party, or both. Phase 2 is relatively straightforward, assuming you have defined a security policy. Unfortunately, most organizations start the security process at phase 2. Starting the security process at phase 2 is like packing the car and driving off for a vacation without first deciding where you're going or how long you'll be there. So it's no wonder that security configuration and compliance seems so complex.

Phase 3 is the process of determining if you have accurately and adequately implemented (in phase 2) the security policies defined in phase 1. This part of the process is referred to as an "audit." A formal security audit should start with an analysis of your security policy and only then proceed to measuring whether you have properly implemented that policy.

How Regulations and Standards Affect Security Configuration

This brings us back to complying with government and industry regulations. Because most organizations are unaware of the necessity of defining a formal security policy, they assume that standards and regulations apply directly to their security implementation. This is an invalid assumption. SOX, HIPAA, and the myriad of other government and industry regulations and standards first and foremost affect your security policy. In fact, they are elements that are required in your organization's IT security policy; they do not directly specify how those elements are implemented on specific systems.

How you implement the required policy elements, as well as the rest of your policy, is up to you. The rest of your security policy will likely significantly affect the way you choose to implement the elements of policy required by regulations and standards.

Since regulations and standards define policies but not policy implementation, no computer or software manufacturer can possibly provide products that are inherently compliant. It's your usage of these products that must be compliant, not the products themselves.

Compliance, therefore, presents you with three problems: incorporating regulations and standards into your security policy, implementing the new policy requirements, and proving you have implemented the required policy elements.

Unfortunately, I am not a policy expert. I wouldn't even begin to assume that I could help you define policies that are compliant with anything. Fortunately, however, I do know a bit about implementing policies in the easiest, most cost-effective way. Therefore, I'll provide some advice on implementing policy and measuring whether or not you have adequately and accurately implemented your policies.

How i5/OS Helps with Compliance Issues

The good news for implementing a security policy on systems running i5/OS is that many of the functions you need to enforce any policy are integrated in—and automatically or easily enforced by—the system itself. These functions don't secure your system. Nor do they make you compliant. They do, however, make it easier and cheaper for you to implement the enforcement of your policy, which makes you compliant.

What are these functions? The same ones that most people assume somehow make the system inherently secure; they don't and it isn't, but that's what people assume. For example, the object-based architecture of i5/OS, the hardware-based pointer attributes, and the trusted translator make it fairly cheap for you to ensure that a native i5/OS virus doesn't infect your system (as opposed to the cost of ensuring a PC virus doesn't infect your PC platforms). The deeply integrated nature of many of the security functions gives the system a very high level of integrity, so you can spend much less money on additional processes and products to monitor and protect the enforcement of your security policies.

These are just a couple of the numerous functions and attributes that make implementing an arbitrary security policy on your system easy and inexpensive. But these functions don't implement your security policy. They cannot and do not determine who can access what on your system. They merely make it easier for you to implement your enforcement of these policies.

Implementing Compliance

The system provides numerous tools and functions that you configure to meet your policy. The first and most important is object-level access control. In today's environments, the only way to adequately implement any policy is through an exclusionary access control model. This model assumes that everyone is denied access to any object unless specifically granted some level of access.

There is no shortcut or alternative to implementing an exclusionary access control policy—not even exit point programs. Exit programs are an excellent way to provide access to individuals who are not otherwise authorized; they cannot prevent access from individuals who are authorized.

Implementing object-level access control can be a daunting task, especially on a system that has no defined policy and hasn't exploited object-level access control in the past. In a two-part article last May and June, I described a rigorous process that gets you to an exclusionary access control model while minimizing the risks to your production environment.

The system also provides any number of mechanisms that provide flexibility and ease-of-use for implementing your policies. System values, profiles, group profiles, authorization lists, adopted authority, various user- and group-swapping mechanisms, support for multiple authentication protocols, data encryption algorithms, operating system exit points, etc. are provided so that no matter the policy, the elements of that policy can be adequately and accurately implemented while minimizing the cost to implement and manage those policies.

With respect to security and compliance, if your security policy includes the elements required by regulations and standards, and you have accurately and adequately implemented those policies, then you have secured your business assets and are compliant.

Proving Compliance

That brings us to the third problem associated with compliance: proving you have implemented your policies. If everyone understood their roles and responsibilities, this would be a much easier problem to address. Corporate executives, legal departments, and IT management would drive the definition of security policy. System administrators and programmers would implement those policies. And auditors would spend at least as much time examining your security policies as they do your implementation.

But that's not the way it usually works. Because most management chains think security is a "technical" problem, they abdicate their role in defining policy. System administrators are typically expected to assume the responsibility of both defining and implementing policies. This is an unworkable situation. It results in a security implementation that enforces, at best, a policy that, for the most part, exists only in the system administrator's brain. The implementation very likely addresses only obvious issues (e.g., password composition) and not many of the important business requirements (e.g., whether the accounts receivable role should be able to see a customer's credit card number). Finally, because these policies are neither clearly articulated nor comprehensive, their effectiveness with respect to security or compliance cannot be accurately measured by anyone.

Many auditors don't understand the security process or their role in it either. These auditors show up at your office and start looking at your security implementation without ever asking about your policies. They arrive with preconceived notions of what configurations on your system indicate compliance. If your configurations don't match their expectations, then, in their minds, you are non-compliant and you fail the audit. However, as I discussed above, there are any number of ways to accurately and adequately implement your policy. With no knowledge of your policy, it is difficult, if not impossible, to assess whether or not you have complied with anything. Most auditors will pass judgment anyway.

Auditors who provide real value will first ask for and analyze your security policies. If the policies appropriately incorporate government and industry regulations and standards, then your organization is in compliance. Technically, your policy is what needs to be compliant; your implementation must simply match your policy. However, a pattern of poor implementation across multiple systems or major policy elements that remain unimplemented indicates that your organizational policy is other than what is described by your written policies.

Only after determining whether your policies are compliant should an auditor consider the implementation of those policies on a system. This part of the process does not determine your compliance; it measures how closely you have implemented your policies on a specific system. This process is much more straightforward and valuable to you if you have a defined policy.

Whether or not you have an explicit policy, or an auditor assumes the appropriate role, you'll have to show the auditor what policies you have implemented. A number of tools shipped with the system can help you show what you have implemented on your system. The security toolkit (GO SECTOOLS or GO SECBATCH) contains over 40 commands, many of which produce information helpful for auditors. Here are just a few of them:

  • The Print Public/Private Authority (PRTPUBAUT/PRTPRVAUT) commands can show the access control model you have implemented.
  • The Print System Security Attributes (PRTSYSSECA) command shows the current setting of security-related system values. The security configuration wizard in iSeries Navigator provides similar information in a written report format that can be easily massaged into a formal report for the auditor.
  • The Print User Profile (PRTUSRPRF) command prints a report showing sensitive attributes such as enabled/disabled, special authorities, and last-used date, which, for example, helps an auditor determine if you have too many profiles with special authorities (an indication that you cannot adequately prevent access to data).
  • The Analyze Default Passwords (ANZDFTPWD) command shows which profiles, if any, have default passwords.

If you have a company policy that encompasses the regulations and standards applicable for your systems, then these tools provide most of the information an auditor needs.

If you have no explicit security policy or simply don't have the time or expertise necessary to run these tools, many third-party products can help you. It is important to understand that these products typically report against an arbitrary security policy containing only the elements of a single regulation or standard (or perhaps a subset of those that affect your organization). While a regulation or standard can be implemented in many ways, if you don't happen to use the specific implementation encoded in the product you use, you will be considered non-compliant.

Regardless of how you or the auditor generates the necessary information about your configuration, this information is used to show whether you have implemented security controls consistent with the policies specified by government regulations and industry standards.

For any audit, it is best to manage your auditors' expectations. Don't assume the auditors know everything they need to about your policies or your system. Meet with them first and provide as much information about your configuration as possible. Show them—or at least explain to them—the policies you believe you have implemented. Run your reporting tools before the meeting and go over them with the auditor. This will show the auditor that you know your policies and understand their implementation.

Getting Compliant

Complying with any regulation or standard is a three-step process that must be repeated periodically. First, your business owners define your organization's security policy at a high level, indicating who (in terms of employee roles) can access which assets for which purposes. Second, your technical folks implement the policy by configuring the security mechanisms on your system. Third, auditors analyze your policy to determine whether your organization complies, and then they measure the implementation of your policy to ensure that the written policies truly are the policies of the organization.

Without an explicitly defined IT security policy, there is no way to accurately measure which policies you have implemented—and certainly no way to determine whether you have secured those assets.

Even if your organization has never had an explicit IT security policy, something is better than nothing. Begin one today. You can find many useful policy templates using your favorite Internet search engine. A security policy is a living document that will be changed and updated no matter how complete. So having one, even if it is incomplete, is much better than not having anything at all. For example, an explicit policy that indicates no employee should be able to access any assets that are not required for them to meet their job responsibilities is an excellent start.

Once you have an explicit security policy, configuring the security mechanisms on your system will be much less confusing. It may still require a large amount of work depending on your current configuration, but it will be much clearer what has to be changed and you'll know when you're done.

Compliance audits will also become much less stressful. From a technical perspective, you're not directly responsible for the policy itself, only its implementation. As long as you have adequately and accurately implemented your organization's documented policy, you're pretty much in the clear. Business owners are responsible for defining policy, and if the policy itself is not compliant, it is their responsibility.

The best way to approach an audit is by managing your auditors' expectations. Be proactive and provide them as much information as you can before they start to physically audit your system. If you've followed the process, the worst they'll find are incidental mismatches that can be easily corrected or documented.

Finally, don't fall into the trap of believing you have secured your business assets because you have passed an audit, especially if your organization has no explicitly defined security policy. At best, passing an audit indicates that you have implemented certain required elements of security policy. At worst, it may mean your auditor didn't know enough about the security process in general or about the specific tools and techniques available on your particular system.

Pat Botz is the eServer Security Architecture and Consulting practice leader for the Rochester Client Technology Center (CTC). You can email him at This email address is being protected from spambots. You need JavaScript enabled to view it..

Pat Botz

Patrick Botz, an internationally known information security expert, is the President and CTO of Botz & Associates, a firm specializing in information security services for IBM i, AIX, UNIX, and Linux environments. 

With decades of experience in key system security positions, Patrick's expertise includes security strategy; security policy enforcement; password management and single sign-on; industry and government compliance; and biometrics.

As Lead Security Architect at IBM and founder of the IBM Lab Services security consulting practice, Patrick worked with IBM customers worldwide and achieved intimate knowledge of system security capabilities and pitfalls on a broad spectrum of platforms, with special emphasis on IBM i (formerly AS/400), AIX, Linux and Unix operating systems. He architected the SSO solution for OS/400 and i5/OS, and he holds several security-oriented patents. 

Early in his tenure at IBM, Patrick lead the AIX workstation tools team for CAD/CAM systems in Rochester, MN. Previous to IBM, he worked for Control Data Corporation with responsibility for CDC's Basic compiler, and for ETA Systems, Inc., a wholly owned supercomputer manufacturing subsidiary of CDC, where he was the team leader for the distributed, Unix-based Electronic Computer-Aided Design (ECAD) tools.

Patrick is the author of numerous trade press articles and a co-author of the book Expert's Guide to OS/400 and i5/OS SecurityIn addition, he is a worldwide speaker on various platform-specific and general security topics.



Support MC Press Online

$0.00 Raised:

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: