Guide

CIO Confidential: 5 Things Your IBM i Security Administrator Should Tell You

How security projects are first identified and then justified is a recurring topic among IT professionals from companies large and small.

After the recession and economic downturn of the late 2000s, employees—grateful that they remained employed—became less likely to speak up regarding inefficient or redundant practices.

Despite the fact that streamlining is desperately required, employees won’t ask for additional spending on security projects or suggest more cost-effective ways to do something for fear that they might find themselves earmarked as redundant.

Similarly, Power Systems servers host critical, line-of-business applications, but are often left languishing when it comes to an ongoing security investment.

These two conflicts can have serious consequences including undetected data loss, regulatory violations, and inefficient use of expensive, skilled resources.

Corporate leadership that actively seeks IBM i security insight from employees will experience greater success than those that make decisions without it.

People on the front lines of IBM i security see what works and what doesn’t—and can provide timely suggestions to aid course correction. Instead of employees fearing displacement, businesses can redeploy staff to tasks that contribute more to the bottom line.

To help provide a voice to the staff responsible for security on Power Systems servers, this list offers five things that you wouldn’t typically hear from the mouths of administrators, but should:

1. The default security configuration of IBM i makes it highly vulnerable.

Anyone who has worked on the IBM i platform for even a short amount of time knows the server’s reputation for unparalleled security. While every IBM Power Systems server comes with integrated security controls, organizations must begin by acknowledging that the majority of those controls are not pre-configured.

When a user profile is created, for example, it is assigned a password that matches the profile name. Although easy to resolve, the State of IBM i Security Study found that nearly nine percent of profiles retain this default configuration, making it painfully easy for someone to gain anonymous access to the server.

Instead of assuming that IBM or third-party software vendors have secured everything on behalf of the server’s owner, assume that they have not. Start by auditing your server to get a clear view of where you stand.

PowerTech offers a no-charge Security Scan that determines configuration weaknesses and identifies mitigation priorities. If your server is already secured, this process will provide useful documentation of that state.

FOR THE CIO or CISO:

This does not suggest that the Power Systems server and IBM i operating system are not securable. Quite the contrary; this is one of the most securable environments on the planet!

However, simply plugging it into the power grid of your data center does not magically establish the role of the server or what applications are running on it. This sounds obvious, but PowerTech has performed many assessments that expose users who could perform some type of inappropriate task.

Employ security-knowledgeable staff or partner with a respected security firm to correctly accomplish this configuration.

2. The IBM i operating system does not contain all of the required security functionality.

Let’s face it—every CFO knows that IBM i has a higher initial cost than many other operating systems.

The ‘i’ stands for integration and IBM has incorporated significant functionality, such as a DB2 database and a comprehensive security infrastructure that normally might have to be purchased separately. For years, IBM i has been proven to provide a lower total cost of ownership (TCO) compared to many other servers in the data center.

Despite such world-renowned integration, functions remain that must be written or purchased.

Powertech was founded almost two decades ago as a provider of award-winning security enhancements. In some cases, IBM has created “hooks” to enable Powertech’s tools to integrate tightly with the operating system. Examples of this hybrid integration include network-initiated access monitoring and anti-virus software.

As a respected security thought leader, Powertech recommends establishing a solid security foundation using the operating system controls. The integrated nature of this foundation means that it cannot be circumvented and takes advantage of class-leading technology such as hardware service protection (HSP).

However, some of these additional (non-IBM) capabilities may be acceptable as a compensating control when operating system security controls are not fully activated, for whatever reason.

Organizations that are serious about security should evaluate the benefit of commercial solutions, especially those that extend the functionality of existing operating system functions or provide capabilities that do not currently exist. Significant efficiencies can often be realized that will ultimately save money.

While in-house staff can author some functions, there are many reasons to look outward:

  • Requirement for specialized expertise for these critical functions
  • The ability to redeploy skilled resources to business-centric projects
  • Compliance concerns regarding self-policing

3. Auditors typically don’t know how to assess servers running IBM i.

Most of us associate an audit with an incredibly in-depth analysis that will discover anything we may have to hide. The reality of an IT audit is that they are often conducted by staff that have very limited (if any) experience with the IBM i operating system.

Questions may arise about non-issues such as partition security and entirely miss that end users can freely run commands via FTP.

Admittedly, the situation has seen improvement as audit firms recognize the criticalness of Power Systems servers in many Fortune 500 companies, but an organization that engages in a review should factor in the expertise of the assessor and their recommendations when determining risk.

Powertech conducts deep-dive security assessments for customers in addition to the no-charge assessment mentioned earlier. These are multi-day service engagements performed by an industry professional who is skilled in the operating system that your business relies upon.

While not a formal regulatory audit, these detailed analyses can produce more than 120 pages of recommendations and explanations. Our goal is to help identify potential areas for improvement and we gladly cooperate with existing corporate security and compliance teams to ensure that data remains secure yet accessible to those that require it.

4. Regulatory compliance (PCI, SOX, HIPAA) does not make the server inherently secure.

Government mandates exist for the protection of private information such as medical records, the prevention of consumer fraud, and to ensure ethical and responsible business practices. Regulations span virtually every world industry, and have been established in an attempt to stem the loss of credit card information, financial data, and personal information that could be used as a source for crimes such as identity theft.

Achieving regulatory compliance is a major initiative for thousands of companies around the globe. The cost of non-compliance can include:

  • Damaged reputation
  • Stock devaluation
  • Corporate fines
  • Jail time

It is not surprising that executive teams are sitting up and taking notice. But, compliance mandates are not step-by-step manuals that guarantee protection from all risk. If they were, the news would not be saturated with stories of security breaches at compliant companies.

Mandates are nothing more than guidelines that establish the minimum level of controls that should be implemented, and should never be regarded as the utopia of security.

One of the most commonly discussed legislative mandates is the Sarbanes-Oxley (SOX) Act that was enacted in response to some shocking cases of asset mismanagement and corporate fraud in the early 2000s.

SOX does not spell out how to configure IBM i system values or user profiles. Instead, auditors rely on an IT audit framework, such as COBIT, to interpret the requirements into processes and procedures that support the initiative.

The definition of compliance is simply the adherence to a minimum standard and assumes that the standard is a good one. Imagine a policy that allows users to carry too many privileges; it’s easy to achieve compliance despite the fact that the users might have access to things they shouldn’t. Unfortunately, too many organizations seek compliance and disregard security.

Many companies look for guidance on how to make their IBM i server compliant with a particular standard. They are often surprised that there is not much difference in the requirements of the dozens of standards that exist. In fact, if they focused on establishing security best practices, they might discover that regulatory and legislative compliance comes easily. Likewise, the harder a company has to work to become compliant, the further they were from being secure.

Today’s focus on compliance is understandable based on visibility; however, the intended effect that virtually all of these compliance standards have on IT is to secure data and server assets. Focusing on security in the first place is a more effective objective.

5. Security is not a one-time investment.

Capital expenditures resolve some need that the business has. This may include a new fleet of delivery trucks, a widget manufacturing machine, or an advanced VoIP telephone system. All of these purchases will eventually wear out, break down, or become redundant and need to be replaced. They also require ongoing investment in servicing, upgrades, and training to ensure that they remain effective during their lifespan.

Security should never be regarded as something that is simply “purchased.” It also cannot be implemented and then forgotten. Much like a messy attic, good security practices take more effort to establish and maintain than chaos, and will not stay in place if not carefully managed and monitored on an ongoing basis.

Also, as new risks develop, an organization must assess the appropriate response— even if that response is a carefully considered business decision to accept the risk and do nothing.

Too many companies empower server administrators to make security decisions, citing that they are the most qualified to secure the server that they manage. Unfortunately, this means that there is no overall corporate directive for these administrators to comply with, resulting in conflicts of interest, or worse, ineffective security controls.

Security—and its closely-related brethren, compliance—must begin with executive sponsorship. Security officers cannot implement and enforce rules if management does not concur with objectives or recognize the return-on-security investment (ROSI). Once a security project is authorized, annual budgets should be established for ongoing maintenance. This might be allocated for the acquisition of additional security controls, upgrades of existing controls, or training of personnel.

Empowering employees to speak up about the realities of IT security and the tools and skills they need will help improve efficiency and reduce the risk of data loss. Over time, good security practices can also save money because generating compliance reports, monitoring users, and detecting security events in real time allow security teams to respond quickly and efficiently.

While the operating system’s security should be deployed as the foundation of the house, commercial security applications—such as those available from Powertech— can streamline existing processes and provide advanced functionality that is simply not available in IBM i alone.

About The Author

Robin Tatam is a CISM with two decades of AS/400 and IBM i consulting experience. He has a strong midrange background that includes programming in RPG and advanced CL, web enablement using CGI and IBM refacing products, as well as systems administration.

An IBM-certified technical consultant, Robin conducts technical presentations online and at user group meetings, including COMMON, where he is a subject matter expert. He has written numerous articles for leading trade journals and was the co-author of the IBM Redbook, “IBM System i Security: Protecting i5/OS Data with Encryption.” Robin can be reached by email at robin.tatam@helpsystems.com.

Let's Get Started
Find out security vulnerabilities put your IBM i at risk. Request your free Security Scan today.

Related Solutions