A risk assessment is a thorough analysis of the security configuration. In the i world, this means an assessment of the entire i5/OS configuration. It's not just taking a look at the system values or looking for profiles with default passwords. It's looking across the entire system. Also, it's not just running the same reports you normally run. A risk assessment extends beyond the norm to find areas of the system that may have been opened up by a change in the configuration, a new application or an operating system upgrade, for example. Performing a risk assessment a bit like doing spring cleaning. During your normal cleaning you dust, vacuum and clean the bathrooms. But during spring cleaning you move furniture, wash windows, vacuum under beds, clean the refrigerator and oven, clean the carpets and wax the floors as well as doing the normal dusting, vacuuming and cleaning. Like spring cleaning, you need to do a risk assessment consistently, at least once a year.
By running an assessment of your security configuration, you can determine what issues exist on your system. On IBM i, an assessment should include (at minimum) an examination of the object level authorities (especially of critical files), TCP/IP configuration settings, various user profile settings (special authorities, default passwords, group membership, use of IBM profiles, etc), programs that adopt powerful profiles, commands that can be run by limited capability users and system value settings, directory authorities, and file shares.
Why do a Risk Assessment?
Risk assessments are required by laws such as HIPAA and GLBA as well as the PCI's Data Security standards and the ISO27000 series. The reason behind this requirement is simple - if you don't run an assessment, how do you know what the current risks and vulnerabilities are? In this case, "ignorance is not bliss." If you don't know about a vulnerability or an exposure, you cannot put plans in place to eliminate or at least reduce the risk it poses to your organization. Putting one's head in the sand and hoping there are no vulnerabilities is no longer an option.
The other reason to perform a risk assessment is that it simply makes good business sense. Issues cannot be fixed and vulnerabilities cannot be addressed unless they are known.
After the Assessment has been Performed
Once the security assessment has been performed, analyze the issues identified to determine the level of risk they pose to your organization. Some issues will need to be addressed because they put your organization and data in jeopardy. Others may need to be addressed because they cause your organization to be out of compliance with your security policy.
With the list of items and their risk levels, you can now create work plans to address the vulnerabilities. Obviously, the higher the risk level, the more quickly you'll want to get the issues addressed. You may decide to accept some of the low risk items and not address them. For those, I suggest that you write a risk acceptance statement that explains why it's not going to be addressed and explains anything that's in place that reduces the risk. For the items that you're going to address but cannot do so right away, I suggest that you go ahead write-up the project plan. This way, if an auditor asks about these items you'll be able to show how the organization is addressing them. This demonstrates to the auditor that you have a good understanding of the risks affecting your organization.
