A security audit can help us answer these questions:
Is the security plan complete ?
The system's security plan should address these points: controlling user access and privileges, maintaining information integrity, monitoring process access, audit functions, information backup and recovery.
Are the planned safety controls in place and working ?
Monitored with daily safety administration. Also, periodically with safety reviews by internal or external auditors.
Does system security keep pace with changes in the system environment ?
Some examples of changes affecting security are new objects created by system users, new users accessing the system, changes to object ownership and changes to user group responsibilities.
To prepare for an event in the future ?
A future event could be the installation of a new application, the upgrade to a higher security level, or the installation of a communications network.
The checklist groups together the areas that a security plan should address. It must be generated to best meet a company's security requirements.
| Security consideration | Details |
|---|---|
| Physical security | The system unit and console are in a secure location. Backup media is protected from damage and theft. Access to publicly located workstations and the console is restricted |
| System values | Set up system values to represent business needs, and track changed values |
| IBM supplied user profiles | Verifying that passwords have been changed and are secure |
| Password control | Use system values and auditing reports to control passwords |
| Authorization control | Authorization to data is controlled. Sensitive data is not public. Authority to user profiles and job descriptions is controlled |
| Unauthorized access | Use the auditing journal to audit unauthorized attempts to access information |
| Unauthorized programs | Use the check object integrity (CHGOBJITG) command to audit for unauthorized program changes |
| Communications | Consider encryption on sensitive data and controlling remote sign-on |
Our security plan will determine whether we activate security auditing and which events will be audited. ⛔ before configuring security auditing on our system, we need to determine the events we wish to audit
| Security relevant events are : |
|---|
| For the system : the auditing of security relevant events is called action auditing |
| For specific user : by user profile |
| For specific objects : object auditing can be used for all users or specific users who access the object |
| A network intrusion |
The security audit log is the main source of audit information on the system. When a security-related event occurs that can be audited, the system will check whether this event has been selected for auditing. This is done by referring to an object called the audit log. → if the event is to be audited, it is written to the current recipient of this log.
⛔ the security audit log is always named QAUDJRN in the QSYS library
If a security event occurs that needs to be logged, it will be recorded in the audit log receiver (the event is written to the receiver).