The Secret Reason You’re About to Fail Your IT Audit

Turning a Key Vulnerability into a Victory

No matter what an organization’s major market is, it is probably subject to regulatory compliance requirements, such as PCI, SOX, FISMA and HIPAA. Failing to comply with any of these requirements could result in a failed audit, which can incur hefty penalties. This article by Markku Rossi of SSH.COM shares one little-known reason why organizations are vulnerable to failing a compliance audit.

No matter your organization’s major market or sector, whether you are in the Fortune 5000 or want to be, you are subject to regulatory compliance requirements such as PCI, SOX, FISMA, GDPR, HIPAA or similar. Failing to comply with the relevant requirements could result in a failed audit, which can incur hefty penalties or loss of business continuity.

Many compliance risk factors are hidden in the plumbing of your organization’s IT infrastructure. This article reveals one little-known reason why your organization is vulnerable to failing a compliance audit, as well as best practices for ensuring you’re prepared the next time you need to demonstrate compliance.

The Secret Key to Compliance

Secure Shell (SSH) is an unseen workhorse in IT infrastructure. The SSH protocol enables secure encrypted remote access and file transfer. SSH keys are the ubiquitous method used to grant access to critical systems and data for humans and machines. SSH keys grease the wheels of finance and industry. However, SSH keys are the domain of sysadmins and app developers, part of the mundane daily work of maintaining databases and editing code.

Many organizations have no visibility into the use of SSH and their SSH key environments, just assuming compliance until an auditor identifies the issue or exception in their reports. How SSH servers/clients and SSH keys are managed is critical for ensuring adequate governance in all corporate IT environments, and it’s an acute issue for cardholder data environments, for business-critical automated data transfers and in enterprise DevOps and application development.

Key Steps to Avoiding a Failed Audit

Ensure you have a holistic and integrated strategy for Secure Shell governance and managing SSH keys. This is essential to avoid failing an audit and incurring fines.

Ask the Right Questions

Here are the critical questions to ask to ensure you don’t fail an audit due to mismanaged SSH keys.

Is Secure Shell deployed within my networks, in e.g. the cardholder data environment, in application development or other critical systems?

Rest assured it is. Some experts would say that it is impossible to implement secure networked environments without leveraging the Secure Shell protocol.

Which systems have Secure Shell enabled?

Secure Shell is typically enabled on all systems.

How is Secure Shell used in my networks?

Secure Shell is used for any of the following: system administrator access, application administrator access, developer access, device admin access, automated processes, file transfers, remote desktop access, backup and restore, system failover, VPN access and contractor/partner access.

What is our process for tracking SSH keys?

Any person or process in possession of a private SSH user key has access to accounts with the corresponding public key. Tracking and controlling configuration and distribution of these keys is a basic and critical security requirement.

How often are SSH keys rotated, and what is the process for rotating keys?

A policy should be in place and enforced for regular key rotation. Treat keys as you would user accounts.

What restrictions are in place to prevent authorized users from using Secure Shell access for an unauthorized purpose?

This applies to both interactive users and automated processes using Secure Shell. Keys should be created, managed and monitored using a central unified console. Only grant least privileged access – enough for users to do their job and nothing more. SSH servers should be hardened. Keys should be configured with quantum-ready encryption.

What monitoring is in place to record encrypted SSH connections and activities performed during encrypted sessions?

Privileged activities, such as those conducted by systems and applications administrators, third parties and subcontractors, should be monitored, logged and reviewed with full audit trail according to defined security policies and procedures.

What mechanisms or controls are in place to prevent SSH-based access between production and non-production environments?

SSH keys used by developers and testers must not enable access from your development servers to production. Remnant nonproduction access may lead to audit infractions, vulnerabilities and breaches.

Looking Ahead

Risk managers and internal auditors have to pick and choose their battles and decide when to take a proactive or reactive stance. When assessing compliance risk from weak Secure Shell governance, you want to know, “Am I ready if and when an auditor comes knocking at my door?”

From the outside, unfortunately, it is not a question of if you will experience a breach – it’s a question of when.

By taking control of Secure Shell governance and implementing integrated SSH key management controls, internal risk managers and auditors can help the organization with a basket of easy wins. You mitigate the risk from external attacks and insider data theft, minimize human errors with critical systems secured by SSH, expedite future breach investigations, stop compliance failure and deliver on your reporting requirements.

Now that you know the secret, you can turn this into a key victory.