The Payment Card Industry Data Security Standard (PCI DSS) is a set of 12 security requirements that any business accepting credit card payments must meet. These range from maintaining a secure network to implementing strong access control measures. As the IT landscape shifts towards more distributed cloud-based environments, maintaining a compliant state can be a challenge.
ScaleFT can significantly reduce the effort to deploy a compliant solution, while still being friendly to your developers and operations teams. ScaleFT Zero Trust Access Management ensures identity with role based access controls better protects cardholder data. By using modern TLS with client-certificates, communication is secure, and centralized logging tracks all user activity.
Malicious individuals (external and internal to an entity) often use vendor default passwords and other vendor default settings to compromise systems. These passwords and settings are well known by hacker communities and are easily determined via public information.
ScaleFT uses modern standardized TLS 1.2 for all communication between system components and uses a “default deny” posture for account access. ScaleFT has no default accounts to disable. (2.1, 2.2.3)
For Linux servers, ScaleFT provides SSH certificates, configures clients to use strong cryptographic configurations, and disables many unneeded features. The recent OpenSSH CVE-2016-0777 Roaming exploit is a good example of how disabling unneeded features can increase security. (2.2.4, 2.2.5)
Specific to Windows servers, ScaleFT provides additional capabilities for remote administration. ScaleFT runs a Broker to wrap the system RDP server, and this broker uses modern TLS 1.2 to encrypt all access. (2.2.3, 2.2.4, 2.3)
To ensure critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on need to know and according to job responsibilities.
"Need to know" is when access rights are granted to only the least amount of data and privileges needed to perform a job
ScaleFT provides role and group based access controls to Linux and Windows servers, enabling strict control of access to system components that contain cardholder data.
ScaleFT populates groups based on your identity provider or they can be manually configured. These groups can be based on job role or function, enabling tight control of access to protected resources. (7.1.1, 7.1.2, 7.1.3)
ScaleFT has a "deny all" philosophy. Groups must be linked specifically to a project. Projects are a set of servers that have the same purpose and access controls. User and Administrator privileges to these projects based on group memberships. (7.2.2, 7.2.3)
Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for their actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known and authorized users and processes.
When a server is managed by ScaleFT, it creates a unique user for every person with permissions to access that server. Each of these unique users is given permissions on the server based on their group memberships as configured in ScaleFT. (8.1, 8.1.1, 8.1.2) As soon as a user is disabled, ScaleFT ceases to issue new credentials for that user, and additionally disables their user ID on servers. (8.1.3)
To deploy a fully compliant solution, ScaleFT must work with your Identity Provider to have reasonable settings for inactive accounts, failed login lock outs, password length, and password rotation policies. (8.1.4, 8.1.5, 8.2.3, 8.2.4, 8.2.5, 8.2.6)
ScaleFT provides a bridge between your main identity provider, any two factor it provides, and access to servers by using strong cryptographically signed ephemeral certificates. If additional two factor is desired, or your identity provider does not have two factor, ScaleFT has native TOTP support, of which there are applications for all mobile platforms. Between the ScaleFT platform and a user, TLS 1.2 with Perfect Forward Security (PFS) is used to ensure all credentials are transferred securely. (8.2, 8.2.1, 8.2.2, 8.3)
Because ScaleFT uses unique accounts for every user, but still allows DevOps tools to work transparently, shared accounts for deployments or other purposes can be disabled. (8.5) For Service Providers, ScaleFT issues its short lived certificates on a per-project basis, enabling unique credentials to be used for every environment. (8.5.1)
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.
ScaleFT has always-on audit logging that provides detailed audit logs of access to the platform and servers managed by ScaleFT. Every audit record includes the unique user that took the action. Audited events include logins to the platform, issuance of short lived certificates, additions or removal of users, changes to settings and many other events. Audits cannot be deleted once created, and are stored in the platform away from servers that may have been compromised. (10.1, 10.2.5, 10.2.6, 10.5, 10.5.2, 10.7)
Each audit event stored in ScaleFT includes the user initiating the action, the type of the audit event, the timestamp, the source server if applicable, and extended event specific attributes. (10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6)