Stop neglecting IBM i security. Consider a risk assessment and two control layers to enjoy substantially less risk of data loss—without sending your organization into the red.
The time is now!
While some companies take a proactive stance on becoming more secure, many more act as a result of regulation. Governments and industry bodies have enacted numerous enforceable mandates, typically as a result of a scandal or high-profile breach. The growing list of these mandates includes PCI-DSS for credit card data, MAS-TRM for financial organizations in Singapore, BASEL for the banking industry, SOX for publicly traded companies, and HIPAA for those in the U.S. healthcare industry. Operators in the European Union face a dramatic increase in fines that may be levied for data breaches since the General Data Protection Regulation (GDPR) was adopted in April 2016. This replacement for the previous “directive” will become law in May 2018, and the financial impact on companies within this territory could be quite dramatic.
Hardening security to best-practice standards should be done out of due diligence. Even data that does not currently fall under the watchful eye of a regulation will likely do so eventually, and best practices state that all data should be treated with care to promote its protection as well as its accuracy. Sadly, many organizations can now attest to the fact that proactively taking even small steps to protect the technology infrastructure would have been far less costly than those actions implemented during the panic—as well as the aftermath—of a major breach.
A Short Platform History
IBM Power Systems servers and the IBM i operating system represent the latest in a long evolution of midrange servers manufactured by IBM. Once known as the “AS/400,” early generations of the server grew through the iSeries and System i monikers to settle at the current name in 2009 when IBM i v6.1 was released.
Despite the various changes in name and underlying architecture, one of the platform’s greatest strengths has always been the unprecedented level of forward compatibility that allows the latest generation of server to restore and use objects saved at any prior level of the OS and server hardware. Not only will the restore succeed, but applications written for the original 48-bit hardware will benefit from the newer 64-bit architecture, often without any modification or recompilation of the application.
This unique capability simplifies a migratory path spanning almost three decades; however, it also inadvertently resulted in very serious levels of security risk. Most organizations restore their security settings and applications to a new server without pausing to reflect on whether their configuration remains appropriate in this modern era of interconnectivity, remote access, and endless data breaches. In many instances, many of these restored configurations predate personal computers, network connections, mobile devices, and the Internet. Servers and databases are left dangerously open and highly vulnerable to access from overly powerful users using profiles that were created with only “green-screen” (5250) menus in mind.
The State of Platform Security
IBM i possesses an enviable reputation for being one of the most secure operating systems available. However, a popular security study reports that the majority of the security controls contained within the OS remain non-configured, allowing unrestricted access to application data. In addition, the popular practice of duplicating existing profiles during user provisioning leaves most organizations with a startling number of users who have access to restricted server functions. In an attempt to dispel a dangerous myth, IBM i security experts now use the term “securable” in place of the more common reference “secure” to describe the platform.
Start with a Scan!
A vulnerability assessment is the most effective way to evaluate the level of risk. IBM i is serviced by several people and companies within the community who perform these for a variety of organizations, from the casually curious to large international firms burdened by regulatory mandate to prove compliance.
Risk assessments should be performed by someone familiar with the nuances of this unique platform and who has a formal audit certification, attesting to an investment in ongoing education as well as an indication of adherence to a code of ethics.
Even a basic assessment should:
- Analyze how many users are operating with powerful user privileges.
- Validate that IBM i’s security system values adhere to best practices.
- Determine whether OS-controlled anti-virus scanning is active.
- Assess the number of unauthorized/failed connection attempts.
- Evaluate whether the audit controls have been activated and configured.
- Detect whether exit programs are monitoring and controlling access from PCs.
Thousands of organizations worldwide have conducted some flavor of assessment, but some inevitably become victims of “analysis paralysis,” intimidated by the large number of changes that often need to be made. In addition, a surprising number choose to avoid looking, assuming they are already “secure” or preferring to remain uninformed about the risks simply as a way to avoid having to act.
Don’t Ask, Don’t Tell
Regulatory compliance is designed to enforce good security practices and lower the risk for those that may not otherwise act on their own volition. However, regulations don’t apply to everyone, and many big-firm auditors simply don’t know how to correctly audit IBM i, still referring to the server by the obsolete “AS/400” name. The effectiveness of I.T. regulations is limited further by the fact that the controls struggle to keep up with an ever-changing threat landscape.
Has your organization chosen to avoid tackling security the project seems too complex or expensive? Is there a sense that data on your IBM i server is not valuable to a hacker? Or are you simply unsure of where to begin? If any of these objections ring familiar, I recommend considering a couple of basic controls to help assure the integrity of the server and to protect the database—which always has some intrinsic value to someone—from unauthorized access, both malicious and accidental.
Do Something…Do Anything!
This short article is written for those who are not yet entirely prepared to acknowledge the full extent of their vulnerabilities as well as for those who suspect their issues but don’t know how to start fixing them. While resistance to an audit is common, I still always recommend a vulnerability assessment. Take advantage of one of the IBM i vendors offering free automated scans to obtain executive sponsorship and for later comparison. If nothing else, documenting the risks is a way for the technical staff to cover themselves by reporting the vulnerabilities and requesting the necessary funding from management.
Now, with that being said, let’s cover two of the most basic considerations that can dramatically reduce the levels of risk without breaking the bank or overwhelming the available resources:
- Command-Line Permissions
Users who are able to access screens containing a command line are likely able to run a plethora of powerful commands. Ten years of audit experience has taught me that the majority of users are granted command-line permission via the limited capabilities (LTMCPB) attribute on their profile. This allows them to leverage all of their public and private object permissions, as well as utilize the reserved functionality afforded by their special authorities and those belonging to any groups they are a member of.
Only in rare instances should end users be allowed to run commands directly from a command line. By limiting access to this capability, a user may operate with excessive privileges with lower risk than would normally be observed when operating with an administrative-level account. This is an easy offset against overly powerful users operating within a “green-screen” environment and can be configured to still allow certain individual commands that you may deem benign.
- Network Access
Despite the overwhelming prevalence of PCs and mobile devices in today’s modern networks, a significant percentage of IBM i applications remain designed to be accessed via the green-screen environment. Users sign on using a Telnet emulator and access the application via menu options. Limiting the actions of users over this type of connection is a relatively simple task by limiting the menu options they are allowed to take and by removing their direct command-line permissions as outlined above.
IBM i contains a number of additional, powerful TCP interfaces that permit the same user community to also connect directly to the database. These connections are established without the restrictions imposed by menus or the application, often granting users free reign to directly view, change, and even delete data in files. These activities are mostly transparent as IBM i contains no “file transfer” event log type, which is often an immediate audit violation.
In addition, several network interfaces allow users to run commands. In a couple of instances, this can be done independently of the command-line permissions that have been configured. So why even bother establishing command-line restrictions? Because the restrictions do remain effective in the green-screen environment and do apply to most of the TCP interfaces.
These significant shortcomings can be addressed very effectively via the deployment of “exit” programs registered to the exit points within IBM i. Conceptually, an exit program merely extends the function of an existing system operation. An exit program can intercept a request originating from monitored network services—such as ODBC and FTP—and process it before the OS takes its turn. Experts recommend that an exit program should be used to determine whether the request should be permitted or rejected, as well as whether it should also be logged (audited). This latter capability fulfils an important function lacking within the OS. The ability to reject a request is performed without regard to the authority that the user would otherwise have. This solves the challenge of users with too many special authorities and databases with permissive private and public authorities. It also remediates the risk of users without command-line permission running server commands.
Custom exit programs can be written in-house, but utilizing a commercial-grade exit program solution ensures that the processing of requests is efficient and functional. It also avoids the conflict of interest from internal programmers writing exit programs to audit and control themselves. Regardless of their origin, the integration between exit programs and the IBM i OS ensures that the two components communicate effectively to police and audit data access and command requests.
Seek Out “Quick Wins”
To improve security without opening Pandora’s Box, remediate the two specific vulnerability points outlined above. While longer-term security projects may entail reducing the assignment of special authorities, changing system values, and establishing complex object-level security controls (a task made easier by the “authority collection” feature introduced in IBM i v7.3), a significant amount of risk can be resolved by enacting these two very simple controls. Obtain a quick win by making simple changes that improve security but that are largely transparent to the user community and that do not impose a burden on the existing infrastructure.
Quick wins should pave the way for additional milestones. Tasks that involve more time, money, and resources should be proposed and can be budgeted for in much the same way as the initial steps. It’s turning into a cliché, but “security is not a destination but a journey,” speaking to an evolution of threats and the associated response. You may fear that evolution, but you simply cannot afford to avoid adopting commonsense security basics.
A Business Decision Leads to Funding
Administrators and even system managers are often frustrated by the lack of a security budget for IBM i. This audience is beginning to realize that there are vulnerabilities in their configuration that need to be addressed, but the perception remains that blame will be apportioned for the shortcomings. There is also resignation that business leaders won’t allocate the necessary funding to solve the problem anyway. And, ultimately, who will be charged with the responsibility and workload for achieving, managing, and maintaining that secure configuration? Most likely them.
Sharing information about risks with business leaders empowers them to make important business decisions on how to plan for the future. In reality, blame doesn’t get assigned until a breach occurs and it’s discovered that risks were known but not shared or that nobody even bothered to check. Distributing an IBM i security study along with results of a risk assessment may garner the attention of a manager who is working under the (false!) impression that a Power Systems server is inherently secure and sets the stage for executive sponsorship and the assignment of the necessary monies and resources.
Isolating vulnerabilities should lead to the evaluation of remediation costs. In some instances, those costs may even be covered by separate departmental budgets, such as audit and compliance, rather than I.T. If a business running IBM i is to ever be secure, it’s critical that action be taken before it is too late—even if regulatory compliance is not yet demanding it. With most I.T. teams being over-extended, automation and operating efficiencies must be employed to ensure that new projects do not force the existing ones to take a back seat.
Ultimately, the remediation of IBM i security risks will never even begin until we ensure that leadership is made aware of the current state, the cost to mitigate, and the possible ramification of not doing so. The good news is that these two important configuration steps can be implemented easily and provide immediate benefits with minimal financial and resource investment.
More 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.
TRY 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.
Forms 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.
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:
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.
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:
LATEST COMMENTS
MC Press Online