One step that is often overlooked when securing an IBM i or AIX environment is the creation of a well-defined security policy.
Most large corporations have many policies in place to address access to different types of technology, but it is rare to find one that pertains to the required settings for Power Systems operating systems. It’s even more unusual for smaller organizations to have any type of formal policy beyond a simple list of best practices.
Even if there is no legal requirement, such as Sarbanes-Oxley or HIPAA, there is usually some level of fiscal and moral responsibility to the company’s customers, vendors, and employees. With no formal policy, it’s often impossible to achieve or maintain compliance.
Develop a Solid Outline
Some companies have multiple policies within their security program. This may mean an overall policy plus sub-policies that define the requirements in granular detail. For example, an international corporation might have a policy that outlines their main purpose for even having the policy, plus an outline of the policy objectives at a global level. Then, there are lower-level policies for every country where the organization has a presence. Each lower-level policy adds more information and requirements, but must conform to the policies above it.
Need help getting started? Check out our free security standards for IBM i and AIX.
Secure Senior Management Buy-In
It is critical that senior management endorse the process of creating a security policy. Otherwise, you’ll struggle to get the capital needed to design and enforce the policy. And, compliance will be more difficult to achieve and maintain. Security policy creation is not an IT responsibility—it should be the result of a steering committee charged with identifying key areas to address in the policy. The IT staff plans and implements the technical controls to adhere to the policy, and auditors determine whether the controls are compliant.
Establish Enforcement Guidelines
Once the team has created the policy, you must enforce it and follow it for real benefit. The policy should outline the penalty for willful non-compliance, and should be distributed throughout the organization so employees are aware of it. You should perform scheduled audits to build a gap analysis between the policy and controls. These audits can identify weaknesses in the policy, the mitigating controls, and the implementation and use of those controls.
The process of auditing and maintaining a security policy can be labor-intensive, especially if your organization is complex or operates in a heavily regulated industry. Security policy management software like Policy Minder reduces the amount of time it takes to identify policy exceptions and can provide greater visibility into system settings.
Monitor for Relevance
A security policy should have a defined life span. It’s not a static document—it should be reassessed every two to three years. That way, the policy meets the changing business and technology needs of the organization over time. The steering committee should update the policy when necessary and communicate any changes to the correct people, quickly.
Additional Policy Resources from PowerTech
Compliance Monitor™ allows you to report on a broad set of security data, including Security Audit Journal (QAUDJRN) log data, which can be stored compressed on a central system.
Policy Minder automates the documentation of your security policy on IBM i, AIX, and Linux, and eliminates hours of manual data analysis and reporting.
If you don’t know how to start your security policy, HelpSystems offers free security standards for IBM i and AIX that you can use to begin outlining your own policy objectives. It’s designed as an open-source model, so you can use it as is or customize it for your own unique corporate requirements. (If your changes might be of interest to other IBM i users, send them to us and we’ll review them for a future edition.)
