Your IBM i didn't come to you secure. But you certainly can—and should—make it secure.

One of the presentations I make to the IBM i community is coyly entitled "7 Habits of Highly Secure Organizations." Although the title is just a play on the name of the famous series of books by motivational speaker Stephen R. Covey, its message is intended to identify several important habits that companies need to consider as part of an overall strategy for becoming first secure and then compliant. I am not suggesting that there are a finite number of habits needed to become secure or compliant, but there are some baseline practices that all companies should adhere to.

Securable Does Not Equal Secure

The first step is to acknowledge the cold reality that the IBM i server is not inherently secure. Before you throw hundreds of articles at me that proclaim how integrated and rock-solid IBM i security is, realize that I said secure, not securable. This important distinction comes from the fact that the server ships with its security configuration pretty much wide open.

To be fair, IBM never told anyone that security came simply by plugging the server into an AC outlet and turning the power on. Unfortunately, many of us heard the message that way. I know it sounds obvious (would you ever dream of thinking that's all that's necessary to secure a Windows-based server?), but it's staggering how many assessments auditors and security ISVs perform each year that show critical application data remains openly accessible to users because of tools like Microsoft Excel or because of free or cheap desktop tools connecting through services such as FTP, DDM, or remote command.

Also, relying solely on legacy security mechanisms such as command line limitations and applications menus often does not afford an appropriate level of security. Whether it's a matter of priorities or a lack of knowledge of IBM i's security controls, application developers often do not put much thought into the security aspect of their programs. Unfortunately, even many commercial application vendors add very little value when it comes to securing the data within their applications. While they may not be familiar with specific customer environments and the available forms of data and application access, leaving the security of the application in the hands of inexperienced customers is an inexcusable practice that leads to the customer's false sense that "someone else" is probably (hopefully) handling it.

Mitigation of security risk often takes time, usually takes money, and definitely takes expertise, but we all know that these three factors— time, money, and skill—are not things that just fall from the sky. We need to acknowledge that there is some level of risk and that we need to plan for the appropriate application of all three factors to bring that risk to an acceptable level.

After that, rest assured that IBM i is one of the most securable operating systems on the market!

Security Starts with a Policy

If you don't have a policy to oversee the numerous security controls and procedures in your environment—both for IBM i and beyond—then you stand very little chance of being able to maintain a clean configuration for any period of time.

Have you ever cleaned out your garage, basement, or attic and wondered why you have to repeat this task annually? It likely has something to do with not having a policy to control the use and placement of the contents. The bottom line is that computer servers don't secure themselves! Even with the best of intentions, we are only human and usually become complacent unless we have controls and procedures in place to keep us true to those intentions.

Consider starting out by developing a policy based on industry best practices. From there, customize the policy in conjunction with an assessment of the level of compliance of your current environment. This allows you to determine an appropriate balance between allowing the business to function and affording it the security that prevents it from being abused.

It's important that the security policy not be designed and implemented only by the IT department. This is not unusual, but to be successful there needs to be executive sponsorship. This ensures that the standards contained within the policy are consistent with the corporate directives and can be enforced. It's tough to enforce strong password rules when the CEO doesn't agree and writes his on a Post-It note!

A good security policy often has multiple layers; perhaps non-technical corporate directives, general access and use statements, and then more-specific configuration procedures pertinent to the technologies in use. Don't make the mistake of having executives involved in technical decisions—they neither understand nor care—but instead place the responsibility for interpreting and documenting how to secure specific systems in the hands of a security officer, and task the security administrator with setting and monitoring the configuration involved to be compliant with the security policy.

The security policy should also be a dynamic document with a defined lifespan. This helps to ensure that it stays abreast of changes in your business, your industry, and the types of technologies that your organization leverages.

Assess and Adapt

After you've identified the desired standards for your security infrastructure, it's important to begin by measuring your configuration against the policy. You'll probably be alarmed by the results when you do this for the first time, but I contend that it's far better discovering the gaps yourself than allowing someone with malicious intent to discover them. Using the findings, decide whether the server's security configuration needs to be adjusted or whether the security policy needs to be adapted to better match the needs of the business.

Self-assessments might seem like a good option, but I would argue that it's not anywhere near as effective as a professional review. It's a strange expression, but "you don't know what you don't know." A knowledgeable expert will often zero in on deficiencies that might not yet be identified in your policy. In addition, your own IT staff might not be objective in assessing the controls that they are often responsible for designing and maintaining. After all, who wants to audit their own work?

There are companies that will review server configuration as part of a formal business audit, although many customers complain that these organizations often don't have strong IBM i expertise. Fortunately, there are individuals in the IBM i industry who can perform a quality assessment of vulnerabilities and provide a list of priorities for remediation.

I personally conduct numerous assessments throughout the year, and these assessments are often the first that many customers have ever had. I feel strongly that the benefit that a customer gets from the experience is significant and measurable. While some remediation items take planning and some level of expertise, there is often "low-hanging fruit" that is identified and can be corrected quickly and easily. Examples I often discover include users with default passwords, poor password policies, overly powerful users, and weak system value configurations.

Make it a habit to repeat this process on a regular basis. Companies that are serious about security and compliance will realize that subsequent reviews will identify remaining (or recurring) vulnerabilities.

Event Logging and Review

According to PowerTech's 2012 "State of IBM i Security" study, more than 20 percent of IBM i shops are still not performing any type of event logging (see Figure 1).

 Figure 1: Over 20 percent of IBM i servers don't use audit journaling.

I would venture that this number would be even higher if we excluded those using the system auditing for High Availability (HA) replication, rather than for security monitoring. In addition, with 16 different categories to choose from, there are many companies that are not auditing all of the recommended event types.

Most regulatory and industry compliance standards require user activities and system events to be logged and stored for subsequent forensic analysis. The collection of audit data is a built-in function of the operating system; however, you have to configure it. After you determine what types of activities should be audited, you can quickly and easily facilitate auditing through several operating system commands.

The challenge for most enterprises lies in the review of large volumes of event log data, and that task is best addressed programmatically. If you don't have the skills or inclination to write and maintain your own programs—or your auditors frown upon self-policing—there are commercial solutions available to make the process easier.

Even if you have no way to realistically review the raw log data (the operating system only includes some basic extraction commands), then I'm still a proponent of collecting the data as you can always load a tool after a security event and review what was collected. If there is no audit data, there are no tools that can reconstruct it.

You will also typically be required to plan for the retention of the event log data, and you should defer any decision about retention periods to corporate auditors or legal advisors.

View Security Tools as a Commodity

Reinvention of the (security) wheel is not only often a waste of money and resources, but it is also often extremely counter-productive. Take advantage of the expertise of companies that specialize in security technologies, and benefit from their R&D, industry knowledge, and dedicated development resources. It's not that you couldn't hire staff and develop and support your own technologies, but, as previously mentioned, auditors usually frown upon self-policing your own security and compliance; think of the fable of the fox guarding the hen house.

In addition, why spend countless hours performing repetitive tasks—sometimes relying on the manual review of thousands of log entries and events—when the technology exists to have the system notify you of an action. The criticality of security events typically means that you cannot afford to wait until month-end to run reports indicating when a profile has been disabled or a library deleted. In addition, there are some types of activities that the operating system has no visibility to, such as downloading your payroll file via FTP. In this case, it is imperative that you deploy a proven solution to ensure that all accesses made to your server from your network are controlled—or at least audited.

All access points to the server should be protected through a combination of layers. No single layer should be expected to be impenetrable, and a breach should trigger timely alerts to appropriate personnel. It's interesting to me that enough emphasis has been placed on perimeter security that the vast majority of breaches now come from inside the firewall. Many of us do little to protect data and applications from approved users, but fortunately there are solutions in the market to provide users with elevated privileges only when necessary, to monitor command usage, and to audit and control the movement of data on and off the server. It's even possible to receive notifications when critical data is modified by more than an acceptable margin or when a change is made outside of the approved application.

If you have followed the recommendation to assess and implement proven commercial solutions, I still have a couple of tips for you: security technology only adds value in your enterprise if you deploy it (properly), and in the case of IBM i, you should also leverage the security controls that have been built into the operating system since day one. There are no "silver bullets" in security, and a realistic (and honest) explanation from the vendor of what their tools can and cannot do is critical.

There Is No Final Destination

Many people make the mistake of thinking that security is a final destination. Hardly so; it is a more like a never-ending journey. Even if you are lucky enough to escape the oversight of a government mandate or industry regulation, you still have a corporate or ethical responsibility to your clients, customers, and employees to protect various forms of information.

After you feel like you have accomplished becoming secure, your objective then alters to one of maintaining that security so that it doesn't become like the garage or basement that I mentioned earlier. The best way to do that is via ongoing compliance checks.

Not dissimilar to the initial assessment that helped to shape your security policy and subsequent server configuration, these compliance checks should verify that you are actually doing what your policy states you should be doing. Find the cause of any non-compliant items, and put additional controls in place to prevent them from recurring. If you find that your business model has changed, you may need to adjust your policy to be a better fit to the current and future infrastructure.

In addition to compliance checks, use your security tools to help keep you abreast of important events. Don't wait until the end of the month to discover something happened weeks earlier that caused a situation of non-compliance. While this constant analysis might seem like a daunting task, the implementation of a good security solution will alleviate much of the manual "heavy lifting" usually associated with this process.

I do want to issue a word of caution: don't confuse regulatory or legislative compliance with security. I speak with many customers who are primarily concerned with passing a formal audit to achieve PCI or SOX compliance. While these are necessary goals, it is quite possible to be compliant with such directives without truly being secure. Formal compliance is typically based on a regulatory framework such as COBIT or ITIL and is interpreted by an auditor. No IBM i configuration settings are spelled out in these frameworks, and two auditors will often assess the same system in two different ways. Remember that these compliance standards are designed as a basic minimum to ensure that sound business practices are followed and information is protected; those who pursue sound security practices will often meet or exceed IT compliance requirements.

Future-Proof Your Security

There is really only one definite in the world of technology: it won't be the same tomorrow! If you consider the technologies and challenges we were dealing with just five or ten years ago, you will realize how many things can affect your approach to security.

In 2001, the world witnessed a horrific terrorist attack that has had a far-reaching impact on business' security, disaster recovery (DR) preparation, and operational resiliency. And over the past decade, we've seen widespread adoption by businesses and consumers of Internet-based technologies; an explosion of powerful mobile devices such as phones, PDAs, iPads, and laptops; and wireless and cellular technologies that now allow consumers and business to demand 24x7 access to information from anywhere around the world, including coffee houses, book stores, or even in planes flying at 36,000 feet!

As businesses, we are forced to oblige these demands in order to stay competitive: we need to move products and services to more places, more quickly, for less money. And we have to do all of this while also dealing with more oversight; in other words, more compliance to standards, laws, and regulations.

While compliance requirements might change, it is extremely unlikely that they will lessen or go away. Look to the past to predict the future. Privacy laws passed in California rolled quickly to more than 40 other states, and a federal law is currently being discussed. Businesses that are not required to be SOX-compliant are now required to pass audits simply in order to do business with those that are. While you may not be able to predict the future, it is a pretty safe bet to say that there will always be electronic data and the need to protect it, so keep your eyes on the horizon and prepare for a growing storm.

Don't Be a Statistic

By working through the process and developing good habits, you can become secure and can maintain that security going forward, no matter what technology comes along.

Robin Tatam is the Director of Security Technologies for PowerTech, a leading provider of security solutions for the System i. As a frequent speaker on security topics, he was also co-author of the Redbook IBM System i Security: Protecting i5/OS Data with Encryption. Robin can be reached at 952.563.2768 or This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility