Our TEL team is working with Customer State Bank of India to operationalise one new SSS 3500 that we sold to customer to replace the existing Gen2 GLS2 SSS Storage.
As part of the internal security practices the State Bank of India runs their own scans on all their devices is asking the TEL team to help close the discovered vulnerabilities . For few of the changes sought the DEV team has requested the Tel team to help raise RFE for these so this configs can be tested in dev setup and post which the dev team can confirm if same can be implemented in customers SSS3500 storage.
There are multiple vulnerabilities noted , as per discussion with TEL & Dev team raising at high level 5 RFE where the related vulnerabilities are bunched
Control Objective - 2.26.1. Disable System Accounts
Control Statement - There are a number of accounts provided with the Red Hat that are used to manage applications and are not intended to provide an interactive shell.
Risk/Impact - It is important to make sure that accounts that are not being used by regular users are locked to prevent them from being used to provide an interactive shell. By default, Red Hat sets the password field for these accounts to an invalid string, but it is also recommended that the shell field in the password file be set to /sbin/nologin. This prevents the account from potentially being used to run any commands.
Recommendations/ Implementation Steps-
Accounts that have been locked are prohibited from running commands on the system. Such accounts are not able to login to the system nor are they able to use scheduled execution facilities such as cron and default system accounts except root.
Dev teams Comment - Please open an RFE so that we can investigate the ramifications of changing these permissions.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Control Objective - 2.26.2. Set Default Group for root Account
Control Statement - The usermod command can be used to specify which group the root user belongs to. This affects permissions of files that are created by the root user.
Risk/Impact - Using GID 0 for the root account helps prevent root-owned files from accidentally becoming accessible to non-privileged users.
Recommendations/ Implementation Steps-
Ensure the default root GID "0" should not be assign to layman users.
usermod -g 0 root
Dev teams Comment - Please open an RFE so that we can investigate the ramifications of changing these permissions.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Control Objective - 2.26.3. Set Default umask for Users
Control Statement - The default umask determines the permissions of files created by users. The user creating the file has the discretion of making their files and directories readable by others via the chmod command. Users who wish to allow their files and directories to be readable by others by default may choose a different default umask by inserting the umask command into the standard shell configuration files (.profile, .cshrc, etc.) in their home directories.
Risk/Impact - Setting a very secure default value for umask ensures that users make a conscious choice about their file permissions. A default umask setting of 077 causes files and directories created by users to not be readable by any other user on the system. A umask of 027 would make files and directories readable by users in the same Unix group, while a umask of 022 would make files readable by every user on the system.
Recommendations/ Implementation Steps-
Edit the /etc/bashrc and /etc/profile.d/cis.sh files (and the appropriate files for any other shell supported on
your system) and add the following the UMASK parameter as shown: umask 027.
Dev teams Comment - Please open an RFE so that we can investigate the ramifications of changing these permissions.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Control Objective - 2.27.2. Ensure gpgcheck is globally activated
Control Statement - The gpgcheck option, found in the main section of the /etc/yum.conf and individual /etc/yum/repos.d/* files determines if an RPM package's signature is checked prior to its installation
Risk/Impact - It is important to ensure that an RPM's package signature is always checked prior to installation to ensure that the software is obtained from a trusted source
Recommendations/ Implementation Steps-
Edit /etc/yum.conf and set 'gpgcheck=1' in the [main] section.
Edit any failing files in /etc/yum.repos.d/* and set all instances of gpgcheck to '1'
Dev teams Comment -Please open an RFE so that we can investigate the ramifications of changing these permissions.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Control Objective - 2.27.3. Ensure filesystem integrity is regularly checked
Control Statement - Periodic checking of the filesystem integrity is needed to detect changes to the filesystem
Risk/Impact - Periodic file checking allows the system administrator to determine on a regular basis if critical files have been changed in an unauthorized fashion.
Recommendations/ Implementation Steps-
Run the following command:
# crontab -u root -e
Add the following line to the crontab:
0 5 * * * /usr/sbin/aide --check
Dev teams Comment - Please open an RFE so that we can investigate the ramifications of changing this.
