In previous posts, we discussed what the Federal Information Modernization Act of 2002 (FISMA) is and how it affects your IBM i in terms of categorizing risk, defining baseline controls, implementing security controls, and assessing the effectiveness of your controls. Today, let’s focus on the final two activities of the six FISMA Risk Management activities for compliance and how they can be applied to IBM i systems. These activities are: Authorization to information based on the risk to the activity; and Monitoring the security controls on an on-going basis to reduce risk. These activities are critical in maintaining FISMA compliance.
What FISMA does
For more information on what FISMA does and the Risk Management Framework used for FISMA compliance, see our blog post What is FISMA and How Does It Affect My IBM i? The Risk Management Framework is maintained by the National Institute for Standards and Technology (NIST).
We previously discussed the first four activities in the NIST Risk Management Framework for FISMA compliance. Today, let’s focus on activities 5) Authorize the information for processing (Authorize) and 6) Monitoring the security controls on an on-going basis (Monitor). These activities specify the FISMA requirements for security authorization and monitoring for federal information systems.
Authorization to Information Based on Risk
One of the keys to FISMA compliance is limiting who is authorized to access sensitive data or systems (Activity 5 of the Risk Management Framework, Authorize). The Authorize activity requires that you have someone who is responsible for reviewing system access who can authorize users to data, based on the risks posed to organization operations and assets, individuals, other organizations, and the nation. While defining risks is out of the scope of IBM i operations, access to IBM i objects isn’t. If the risk analysis determines that a user has no need to access a specific IBM i database object, program, operating system, or data, the user shouldn’t be authorized to it.
The IBM i supports Activity 5 authorization decisions by using object based security, where users are either granted authority to or have authority withheld from system and application objects.
Object based security allows IBM i systems to protect sensitive data. If a user isn’t authorized to an object, they can’t access it, and the object is protected. However, since IBM i authorization occurs in layers, you must insure that your objects are protected from the many ways that unauthorized access and modification can occur, including.
- Restricting *ALLOBJ authority only to those who need it or on a temporary basis – Giving a user *ALLOBJ authority is basically handing them the keys to the kingdom. They can access any object, anywhere, any time, and this authority should be limited only to those users who have a valid reason to possess it.
- Restricting IBM i library authorities that can provide access to all objects in a library, even if the user doesn’t have authority to any specific library objects. Review and control overall library authority, as it can inadvertently allow access to sensitive objects inside a library.
- Restricting user command line authority and authority to IBM i commands that update data, including SQL and DFU. Don’t allow your unauthorized users direct and uncontrolled access to execute commands and programs. This can easily be set up in user or group profiles. You should also remove user access to IBM i commands that allow you to change data, such as SQL and DFU.
- Restricting user access to remote capabilities that can be used to access and retrieve IBM i data, including ODBC, OLE DB, RUNCMD, Data Transfer, and FTP. Exit point programs can be used to provide an additional layer of security for users who remotely access your IBM i data.
- Restricting database field level access. Securing what users can do with sensitive data that they are authorized to. Some software products, such as iSecurity AP-Journal, provide IBM i application and filed-level security that allows you to set limits on database changes and program access, and alert security personnel when changes to sensitive organizational data occur that violate those pre-defined limits (ex., when a user deletes an order, modifies commission amounts above a certain level, changes payroll information without proper authority, or accesses personal information).
- Locking down individual object authority for sensitive files and other objects. Lock down your sensitive objects and database files, as well as your user profile, library, command and update utilities, and remote access authorities. Don’t forget to check your Integrated File System (IFS) authorities to insure stream file objects are secured.
It’s important for the Risk and IT team to work together to ensure that authorization is properly implemented to ensure that your sensitive data is truly protected. There are many third-party products from SEA and other vendors that can help secure user authorization to critical objects, and report on how user authorization was secured.
One common issue for IBM i organizations is that there are often too many users with excessive authority, which puts your data at risk. With the new Authority Collection feature in IBM i 7.3, IBM allows you to identify your current object security levels by individual users, and determine what level of authority a user needs to perform their day to day tasks. You can run a simple CL command to start the collection, which will provide you with a report that helps you understand the lowest level of authority an object needs for users to complete their tasks. The Authority Control feature allows you to more easily identify users with excessive authorities for the job they’re performing, allowing you to tighten down access controls.
Continuous Monitoring for effectiveness
The final activity in the Risk Management Framework (Activity 6, Monitor) is to continuously monitor to ensure the effectiveness of your security controls. According to NIST, “The purpose of the Monitoring Step is to maintain an ongoing situational awareness about the security and privacy posture of the system and organization in support of risk management decisions.” Through monitoring, you can generate reports and real-time alerts that allow you to make continuous improvements to your security policy whenever authority and access breaches are detected. Monitoring is important to ensure that as things change in your environment, risks are identified and accounted for so that you are still protected.
It’s critical to FISMA compliance to implement an IBM i monitoring solution that will notify you in real time, if one of your policies has been breached. The whole idea behind FISMA is to reduce risk of loss of sensitive federal information. If you are not monitoring your security controls in real time, then you are at risk. While audit reports are important, it’s easy for someone to miss an event if the report has 100s of events that are unrelated to security breaches or security policy violations.
For IBM i FISMA monitoring, you’ll want to look at third-party security auditing, monitoring, alert, and reporting products such as iSecurity Audit or iSecurity Native Object Security packages. Some of the more valuable features of an IBM i security auditing and monitoring package include:
- Real-time detection of security events as they occur, recording these events for later review, and sending out alert notifications when an event occurs
- Taking corrective action when a security breach is detected
- Setting target security level templates for sensitive objects or object types and checking for inconsistencies between your target and actual security levels
- Automatic resetting of security setting to their default values, if the setting is changed outside of its target value
- Query and report generation for audit and FISMA compliance reporting
By implementing a real-time security monitoring solution, you can be alerted to events and take corrective action as an event happens, prevent rogue users from resetting security values, and produce reports for auditors showing FISMA compliance. Undercovering and reporting on security breaches creates a continuous improvement loop for IBM i authorization changes, where an authorization change goes into effect and is documented, security monitoring detects a breach that isn’t covered by an authorization policy, which then triggers another modification to the authorization policy to improve security.
Getting started with FISMA compliance for IBM i
Compliance can be overwhelming, but it doesn’t have to be. A good way to start reviewing your FISMA compliance is to contact SEA for a free security assessment or for more information on how we can help you with your security issues. We’ll be glad to review your current situation and make recommendations for any changes that might be needed.
