What if Houston hadn’t been paying attention to Commander Lovell when he spoke those famous words? Would Apollo 13 still be known as an epic survival story or a preventable tragedy?
In space and security, people on the front lines see what works and what doesn’t. Their voices provide timely suggestions that aid course correction and prevent disaster. If you’re not encouraging your IBM i security administrator to speak up, you may be missing critical issues.
To help provide a voice to the staff responsible for security on Power Systems servers, this list offers five things that you may not have heard from your administrators, but should:
1. IBM i’s default security configuration makes it highly vulnerable.
While every Power Systems server comes with integrated security controls, organizations must begin by acknowledging that the majority of those controls are not pre-configured.
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.
To correctly accomplish this configuration, employ security-knowledgeable staff and help them prioritize this project or partner with a respected security firm.
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 provided 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. Examples of this include network-initiated access monitoring and anti-virus software.
While in-house staff can author some functions, there are many reasons to look outward:
- Specialized expertise is needed.
- Internal resources are focused on business-centric projects.
- Compliance concerns regarding self-policing.
3. Most auditors don’t know how to assess IBM i servers.
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.
An organization that engages in a review should factor in the expertise of the assessor and their recommendations when determining risk.
4. Regulatory compliance (PCI, SOX, HIPAA) does not make the server inherently secure.
Achieving regulatory compliance is a major initiative for thousands of companies around the globe, especially since the cost of non-compliance can include:
- Damaged reputation
- Stock devaluation
- Corporate fines
- Jail time
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.
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.
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.
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.
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 helps 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 more quickly and efficiently.
While the IBM i’s built-in 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.
For example, network access is one of the most overlooked vulnerabilities on IBM i. PowerTech assessments have found that most organizations monitor only 28% of IBM i exit points, leaving end users free to read, change, or delete critical data without anyone knowing it.
Powertech Exit Point Manager for IBM i is designed to leverage IBM i’s existing security capabilities. The product covers over 30 exit points, making it the industry-leading exit program for Power Systems servers.
Exit Point Manager for IBM i allows you to restrict user access to critical data from PCs, and audit end-user access across the network through common services like ODBC, FTP, and DDM.
Track, monitor, and control access to your critical data with a free 30-day trial of Exit Point Manager for IBM i.
See for yourself how Powertech Exit Point Manager for IBM i helps audit and restrict user access.