The following principles are fundamental to using any application securely. These principles will be referenced throughout this guide.
This chapter contains the following topics:
One of the principles of good security practice is to keep all software versions and updates current, to take advantage of improvements in new releases. Throughout this document, we assume a JD Edwards World Release level of A9.3 and A9.4.
Keep the IBM i behind a firewall. In addition, if you are using Web Enablement, consider placing a firewall between the LegaSuite GUI server and the System i. The firewalls provide assurance that access to these systems is restricted to a known network route, which can be monitored and restricted, if necessary. As an alternative, a firewall router substitutes for multiple, independent firewalls.
This principle encourages the security administrator to reduce the number of possible security vulnerabilities by removing unused or unnecessary system objects and security capabilities. This action may include removing unused IBM User Profiles and JD Edwards User records. It may also include the use of IBM's Adopted Authority feature on the IBM i.
The principle of least privilege states that users should be given the least amount of privilege necessary to perform their jobs. Overambitious granting of authorities, especially early on in an organization's life cycle, when people are few and work needs to be done quickly, often leaves a system open for abuse. User privileges should be reviewed periodically to determine relevance to current job responsibilities. Previously, the common security practice was to grant all access to all users and to restrict authority on a selected basis. In today's security environment, all authorities should be denied as a general rule and selected authority granted where needed. The security modifications beginning in World release A9.3 support this principle by using ”no access” as the authorization default.
To minimize possible system abuse by otherwise authorized users, the security administrator must define conflicts of responsibility and take steps to ensure that users are not allowed capabilities that conflict from a security standpoint. For example, the user responsible for printing Accounts Payable checks should not be the same person who is responsible for setting up suppliers and approving invoices.
Your overall security strategy should not rely on one security layer. If one security defense is defeated, you should have reasonable redundancies. For example, you may want to set up Menu Security to restrict unauthorized users from a particular module (such as Payroll), but also set up Action Code Security on critical Payroll programs and secure the Payroll files using IBM i Resource Security.
One of the main requirements of system security is monitoring. Auditing and reviewing audit records address this requirement. Each component within a system has some degree of monitoring capability. Establish a policy to check and monitor activities in your system regularly. Refer to the IBM i database and operating system documentation for audit functionality. For JD Edwards World, follow the advice in this document and regularly monitor audit records.
Good security requires secure accounts. Establish a policy to set up strict password controls for all accounts so that passwords are not easily compromised. In addition, establish a policy that requires users to periodically change passwords, perhaps every 90 days.
Establish a policy to set up a change management process to keep track of all the changes in your software systems. All changes to software should be approved and audited.