Table of contents
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) to audit for unauthorized program changes |
| Communications | Consider encryption on sensitive data and controlling remote sign-on |
The security plan will determine whether we activate security auditing and which events will be audited. Security events can be configured for the system, a specific user, a specific object and the 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 a security event occurs that needs to be logged, it will be recorded in the audit log receiver).
<aside> 💡
The security audit log is always named QAUDJRN in the QSYS library
The auditor will need special authorization *AUDIT Some audit tasks require *SECADM and *ALLOBJ
</aside>
Before auditing can be started on the system, the QAUDJRN log must exist in the QSYS library. In fact, two objects must be created. Security-related events are written by the system audit log to a log receiver, which must exist before the log is created.
<aside> â›”
When the log is created, the corresponding log receiver is referenced and must therefore exist before the log can be created
</aside>
CRTJRNRCV JRNRCV(JRNRCV0001) LIB(AUDIT) → Create Journal Receiver
<aside> 💡
The best practice is to end the receiver name with the number 1
</aside>
**CRTJRN** **JRN(QSYS/QAUDJRN) JRNRCV(AUDIT/JRNRCV0001)** → Create Journal (create a new log using the previously created log receiver)
<aside> 💡
Log receivers fill up. When the log receiver is full, a new empty receiver must replace it. (the complete receiver must then be saved)
</aside>
CHGJRN → Change Journal
<aside> 💡
The change-journal parameter MNGRCV(*SYSTEM) allow the system to change the journal receivers (when an attached journal receiver reaches its size threshold, the system detaches the attached journal receiver and creates and attaches a new journal receiver)
</aside>
<aside> 💡
QUADJRN receivers are security audit failures, we should make sure they are properly registered before deleting them
</aside>