Gateway Hardening

This topic provides a high-level description of the hardening procedures that have been applied to the gateway.
gateway93
This topic provides a high-level description of the hardening procedures that have been applied to the
Layer7 API Gateway
.
Contents:
General Principle Around Hardening
The host OS/Platforms for the
Layer7 API Gateway
are delivered with moderate levels of OS hardening. This provides a secure default deployment platform configuration. The CA Technologies approach to OS hardening for the Gateway uses the following general security principles:
Economy of Mechanism
  • Keep the system as simple and small as possible
  • Remove unused components, services, open ports, etc.
Least Privilege
  • Programs and users of the system should operate using a minimum of privileges necessary to complete the job
  • Account access and resource restriction
Designed for Updating
Psychological Acceptability
  • Find a balance between security vs usability
  • Provide moderate level of hardening; customers can apply additional hardening as necessary
Hardening Process
The hardening process typically includes, but is not limited to, the following areas:
  • Partition limiting
  • Limited file system mount options
  • File ownership initial verification
  • Restricted file permission settings
  • Minimal number of OS packages
  • Package signature validation
  • Boot menu lock down
  • Kernel module configuration and minimization
  • Firewall configuration (iptable rules)
  • OS audit events that are integrated with syslog
  • Minimal user and service accounts
  • Increased user password complexity, and stronger hash for password storage
  • Minimal running services
  • Restricted resource controls
  • Security scanning (with various applicable tools)
The Docker container form factor receives generally the same hardening steps. However, some of the above hardening procedures do not apply to Gateways running on Docker. For example, Docker images do not contain kernel modules and Docker images are deployed with preconfigured settings (thus no boot/configuration menu).
Image Scanning for Security Vulnerability
All Gateway images (regardless of form factor) go through a thorough Secure Software Development Cycle (see the CA Technologies best practices here). These images are also checked with Static, Dynamic, and Manual Application Security Testing, plus other vulnerability scanning tools before release. CA Technologies uses third-party tools to identify vulnerabilities in the host OS/platform and to examine the Docker image composition and component.
Host Platform/OS Patching Security Requirements
The Gateway receives monthly platform patches or new base images that contain updated OS level packages for delivering platform-level security patches. For most of the form factors, you can apply the monthly patch from the Docker container form factor, configure your preferred Docker deployment platform (for example, OpenShift) to auto deploy the monthly updates.
If your Gateway is installed as an RPM package, it is your responsibility to maintain the host OS/platform.
Patching Requirements for Different Form Factors
The following table summarizes the security patching requirements for the Gateway on various host OS and platform form factors.
Form Factor
Security Patching Requirement
Virtual Appliance, OVA image, RHEL-based
Apply the Gateway monthly platform patch.
Virtual Appliance, OVA image, CentOS based
Apply the Gateway monthly platform patch.
Virtual Appliance, AWS AMI image, RHEL based
Apply the Gateway monthly platform patch.
Virtual Appliance, AWS AMI image, CentOS based
Apply the Gateway monthly platform patch.
Virtual Appliance, Docker container image, CentOS based
Set up your container application platform to auto deploy the latest container image from the Gateway Docker hub.
Software, RPM package
You manage your own host OS/Platform patching process.
Hardware Appliance, Oracle X5/X6/X7 server, RHEL based
Apply the Gateway monthly platform patch.