For Security Managers using the
VSAM ESM Module,
Micro Focus recommends the following hardening configuration modifications:
- Module
- Set this to
vsam_esm, with no path, and for Linux/UNIX installations, no bitness, threadedness, or file extension suffixes. ESF loads ESM Modules
from the product installation directory automatically – it does not search the library load path. ESF will select the appropriate
bitness and threadedness automatically.
- File ownership and permissions
- It is important to secure the data files used by the
VSAM ESM Module so attackers cannot subvert security by changing the security data. Access to reading and changing the data is determined
by OS file permissions, not by ESF, with a couple of exceptions:
- ESF can impose additional restrictions on changing the files using the ESF Admin API, by using rules in the AdminAPI resource
class. For example, using the
esfadmin utility or
ESCWA.
- ESF can impose additional restrictions on changing the files using JCL, using rules in the PHYSFILE resource class.
Predominantly, it is OS permissions which will protect the files. There are two common use cases:
- Typical security: Here interactive users can change their own passwords, and administrators can alter security data using
esfadmin or
ESCWA. If a malicious program is run under
Enterprise Server, it could alter security data. For this use case, set the file ownership to the user account that
Enterprise Server processes run under, and give that account write access. If other users need to be able to write to the files — for example,
interactive administrators need to be able to edit the files directly — create a user group containing those users and give
that group write access to the file as well.
- Enhanced security: The files cannot be changed by processes running under the ES system user account. Users will not be able
to change their passwords and security data cannot be updated through
ESCWA, but the security data is protected from any programs running under
Enterprise Server. For this use case, make the files owned by a privileged user and deny write access to all other users, for example Administrator
on Windows or root on UNIX.
Remember to set the same write permission on the directory containing the data files and all subdirectories. On Windows, you
can use an inherited file ACL for this.
- Default security: Changing generated passwords and removing them from the vault
- On a fresh installation of 10.0 or later product release, a default security configuration is also installed. See
The Default Enterprise Server Security Configuration for more information. That configuration includes two user accounts,
SYSAD and
readonly. Random passwords are generated for these users and written to the default vault of the
Micro Focus Vault Facility.
If you are using the SYSAD account,
Micro Focus recommends changing the password, which you can do using
ESCWA, either when signing in or by editing the user entry in the security configuration. If you do not change the password, delete
it from the vault using the following command:
mfsecretsadmin write -overwrite microfocus/temp/admin
The readonly account only grants read access, and is used automatically by some
Enterprise Server components such as the
Micro Focus Common Client and
Host Access for the Cloud to retrieve data from MFDS, if no other credentials are configured for them. For that reason, you might want to leave those
credentials in the vault. If you do not need them, however, you can delete them with the following command:
mfsecretsadmin write -overwrite microfocus/common/readonly
- Predefined system user accounts
- See
User Accounts in the Default Enterprise Server Security Configuration and
Removing or changing default credentials for more information. Disable or delete predefined accounts you do not need. For those that have passwords such as
mf_cs and
mf_dep, if you do not disable or remove them, change the passwords.