Strategy on AWS offers best in class security. The Operating systems running on MicroStrategy on AWS servers are compliant with Center for Information Security Benchmarks.
Strategy recommends that customers also adhere to the following best practices to secure their operating systems:
Ensure filesystem integrity is regularly checked
A common tool to check filesystem integrity is AIDE. With AIDE, the user must create a configuration file with a catalog of every executable on the instance, let AIDE take a hash of all of them, and then schedule AIDE to check all of the files regularly. The AIDE configuration file would need to be created to keep track of the Strategy executables (for instance, /opt/mstr/MicroStrategy/bin, /opt/usher/usherApps, and /opt/mstr/PlatformAnalytics), and AIDE would need to be disabled and hashes re-taken if a hotfix were ever to be upgraded.
Documentation on how to set up AIDE can be found at:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-using-aide
Ensure default user umask is 027 or more restrictive
Note that doing this will cause programs which depend on files with permissions set to “other” (the third octal) to fail. This includes AWS CodeDeploy, so doing this will cause in-place upgrades to fail, and other unintended downstream impacts; do this at your own risk.
If this value must be set, run the following commands:
sed -i 's/umask.*/umask 027/g' /etc/profile
sed -i 's/umask.*/umask 027/' /etc/bashrc
Ensure X Window System is not installed
The X Windows System is a prerequisite of certain elements of Strategy, including its graphical administration tools, as well as VNC and the desktop manager GNOME. If disabling this functionality is acceptable, the command yum remove xorg-x11-server-common will remove the X Window System (as well as render all graphical tools inoperable.)
Ensure SSH X11 forwarding is disabled
Note that this will impact the ability to remotely access the Platform Instance’s GUI from tools like VNC and Xming. This can be done by modifying /etc/ssh/sshd_config and setting “X11Forwarding” to “no”.
Ensure NFS and RPC are not enabled
Note that disabling NFS on an Enterprise deployment will cause the environment to fail to come up, as shared components of the Strategy platform are mounted from an EFS file share, which uses the NFS protocol.
If this is acceptable or EFS is not in use, running yum remove portmap nfs-utils will remove the NFS software.
Ensure HTTP server is not enabled
Be aware that doing this will disable the Identity Manager product entirely. If this is acceptable, service httpd stop and chkconfig httpd off will turn off and permanently disable the HTTPD serverver.
Ensure ntp is configured
The Platform Instance uses AWS’ public NTP server, and does not run NTP. Best practices for running NTP can be found here:
https://insights.sei.cmu.edu/sei_blog/2017/04/best-practices-for-ntp-services.html
Ensure /etc/hosts.deny is configured
Ensure default deny firewall policy
Ensure firewall rules exist for all open ports
Whitelisting inbound traffic in MSTR on AWS at the instance level would cause certain AWS services (such as systems manager) as well as the customer’s own traffic to be blocked by default. Security groups around the instance presently prevent inbound traffic on port 22 (SSH) from the outside internet, so the risk of outside SSH entry is mitigated that way. By default, MSTR on AWS instances are deployed with security groups that only allow traffic on specific ports from the load balancer. All other ports are already blocked. For managing inbound traffic, AWS security groups and the properties of the subnet/VPC it is deployed into are an easy way to manage inbound traffic.
Ensure inactive password lock is 30 days or less
Ensure password expiration is 90 days or less
Ensure minimum days between password changes is 7 or more
Ensure inactive password lock is 30 days or less
Ensure password creation requirements are configured
Password management can be performed using the chage tool. Take care not to accidentally lock out the mstr user, as one cannot log in as root and there is no physical access to the EC2 instance with which to recover it. Documentation on chage can be found here:
https://linux.die.net/man/1/chage
Ensure no world writable files exist
Ensure no unowned files or directories exist
Ensure no ungrouped files or directories exist
Ensure users own their home directories
It is possible that security tooks like AWS Inspector might show this as a false positive because some files in /var/run are throwing a “permission denied” error even to root. However, other than those files, these criteria are met on the Platform Instance by default.
Ensure separate partition exists for /var
Ensure separate partition exists for /var/tmp
Ensure separate partition exists for /var/log
Ensure separate partition exists for /var/log/audit
Ensure separate partition exists for /home
AWS does not provide templates with a partitioned root volume; this can only be done by detaching it from the Platform Instance, attaching it to another EC2 instance, and manipulating it from there.
Documentation on how this can be done can be found here:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html
Ensure the SELinux state is enforcing
Ensure SELinux policy is configured
Unless SELinux policies are written for all processes on the Platform Instance, and maintained when more are installed, they will be blocked if SELinux is set to “enforcing”. To successfully set SELinux enforcing, one needs to write policies for all running processes; as SELinux is set to “permissive”, those processes are being logged to /var/log/audit/audit.log.
Documentation on how to set SELinux policy can be found here:
https://www.nsa.gov/Portals/70/images/resources/everyone/digital-media-center/publications/research-papers/configuring-selinux-policy-report.pdf
KB483006
