The purpose of this blog is to highlight several key elements for a secure IBM i environment. As you will read, policies and procedures should precede technology to achieve the best results.
Disclaimer: iSeries and AS400 are servers. IBM i is an operating system. I use these terms interchangeably to make it easier for folks to find this kind of information on the web.
IT security is a HOT topic. The risks of security breach and loss of critical/confidential data are potentially massive.
And, the IBM i is included in the mix.
As I have read and studied this topic, I agree that too many IBM i users have such high confidence in their IBM i reliability and integrity that they may not give security the attention it deserves. Clearly, IBM i users need to take a closer look at this issue.
At the other extreme, I have encountered too many of the security “fixes” that are Windows-based “force fits” that do not take the IBM i built-in security into account.
So What Is A Practical Starting Point? First Policies, NOT Technology.
For starts, I recommend any of Carol Woodbury’s books about IBM i Security. Ms. Woodbury explains that each business needs to understand its own “rules.”
Having an up-to-date and enforceable security policy lets you implement a security scheme confidently and provides a clear pathway for resolving issues.
Designing your corporate security policy is a critical business practice—much like laying out your employee compensation plan. For example, once you have a policy in place, you can analyze a proposal for enabling a new technology to see whether it fits with the rules. Thus, a security policy can settle arguments and avert power struggles.
As I have reflected on what Ms. Woodbury and others have written on the topic, the first step is NOT technology. Instead, it starts with developing the policies and procedures that define the business security policy.
While some laws and regulations (e.g., the Payment Card industry’s Data Security Standard) have requirements regarding specific issues that must be addressed in a policy, no law or regulation mandates how many additional areas are addressed.
Here’s the point. Your policy needs to meet your organization’s requirements, and those requirements vary from organization to organization.
Where To Start?
At a high-level, your security strategy and implementation must take into account the potential for a security breach – accidental or intentional – that could result in the disclosure, modification, or deletion of your information assets. What are the risks to those assets – the data residing on your systems? The risk is to the confidentiality, integrity, availability and privacy of the data.
Evaluating The Threats
As you evaluate the potential threats, a common issue is the role accidents can play in breaching confidentiality, accuracy or availability. Common-sense measures, such as appropriately securing production data, securing the source so that it cannot be updated outside of change management, reducing the number of all-powerful users, auditing the users of critical data and security-relevant actions and handling data according to the requirement of the data type, you can eliminate many common sources of errors and omissions.
Clearly, you want to protect yourself from the threat of disgruntled employees and hackers. First, you need to develop a security plan. Then concentrate on the simple security basics, which can prevent accidents and employees from damaging the system. Moreover, a good business contingency plan which can reduce the effects of a natural disaster or other form of unexpected disruption.
Managing The Strategic Issues – from Carol Woodbury’s book “IBM i Security Administration and Compliance”
Evaluating the risks and threats to your information assets is the key to getting management’s attention. As you expose risks and threats, management begins to see the possible ramifications of inadequate or inappropriate security. Once you have management buy-in, it’s important to follow through by implementing a security awareness program throughout your organization and ensuring that the requirements of your organization’s security policy are considered with all major changes that occur in the organization. In addition to managing upper management’s knowledge and expectations of a security policy, you need to manage the access controls to your applications, data and systems. And you need to establish and carry out security auditing procedures.
These tasks take time. But once completed, they provide the building blocks for the various security implementations you need to undertake on your enterprise’s computer systems.
Getting Started
Getting started is the hardest part of implementing a sound security plan.
The two first steps include:
1) Examine any potential risks to your company’s information assets – its data. What confidential or private information requires protection? How do you guarantee the integrity of your organization’s data? What would the cost be if it were lost or stolen? List the risks of your current implementation and compare that to the cost if the data were lost or stolen.
2) Get management support to begin documenting corporate-wide security policies. After defining the organization’s policies, start to define the department procedures and establish data ownership.
Only after completing these tasks are you ready to begin implementing a new security plan. It is in the enforcing that you will apply technology.
The last step in getting started is to commit to maintain your security implementation and plan. The only way to determine whether your implementation is working is to check the compliance of the current system settings against your security policy and continue to do so on an ongoing basis. When you discover gaps in the configuration, you can fix the implementation to bring it back into compliance with your policy.
Security is an ongoing event. You adapt your security plan as your business and the market evolve as well as laws change.
Need help and would like some guidance with IBM i security? Call me at 714-593-0387 or email me at blosey@source-data.com.
Leave a Reply