Fouad Khalil, Director of Compliance, SSH Communications Security
The lack of clarity today about SSH key management is stunning–and dangerous. In the case of SSH user key-based access, what you don’t know can hurt you, both in terms of security and compliance. Many enterprises don’t know who is in charge of this access, which very well mean that no one is in charge. Let’s look at what this means for compliance.
The reason that effective, consistent SSH management is so critical is that it’s all about access controls. All the regulations, laws and frameworks exist to ensure, at a minimum, that protected data (PII, ePHI, credit card data, etc.) has authorized access. It doesn’t matter whether that access is being requested by a machine, admin or business user. The facts are that:
• There is little to no oversight and control in many organizations
• There is a lack of processes for provisioning ownership, revocation and rotation of keys
• There is no ownership of the access being provided or clear policies for key-based access
• There is little to no visibility into SSH user key-based trusts or monitoring capabilities
These facts are best illustrated by the fact that in some10, 000 Unix/Linux hosts, lack of strong SSH key management equates to 1.5 million application keys granting access and 70,000 keys each for database administrators and system admins. There can be up to one billion authentications per year granting access. The majority of the access available via these keys is obsolete, having been assigned to employees or third parties who no longer work with or for the organization.
Failure to Comply
That’s a nightmare waiting to happen in terms of compliance. SSH keys are a critical component of logical, privileged and third-party access; their misuse can have repercussions across all critical frameworks. Regulatory bodies won’t be easing up any time soon; instead, they are levying seven-figure fines, incarceration and reputation-damaging publicity.
HIPAA HITECH, for instance, is not kidding around. Administered by the Office of Civil Rights (OCR), it is the only government agency conducting security-related audits. Key focus areas are segregation of duties, access authorization and transmission security (encryption protocol). The healthcare industry has struggled to keep up with compliance mandates and audit activities. These “distractions” slowed their progress to compliance maturity and increased the risk to breaches and/or audit violations. The good news is that earlier in 2016 the OCR/HHS kicked off the effort of mapping HIPAA specifications to the NIST Cybersecurity framework.
That’s a positive development–because how can you sign off on an attestation when you’re ignoring a huge access gap of production?
The OCR regularly updates its “wall of shame” web page, which lists all organizations that have had breaches affecting 500 or more individuals. And that’s just the beginning of the pain. There are hefty fines for non-compliance, of course. These fines are issued per violation category, per year that the violation was allowed to persist. The maximum fine per violation category, per year, is $1,500,000. In other words, if your organization knew there was an access issue but you did nothing, you’re going to pay for it–literally.
That’s only one regulatory body; there are many more, each with its own punishments. SOX violations carry potential fines and jail time, and PCI violations pack their own punch. In addition to stiff fines, PCI can take away your payment processing privileges. This happened to a national chain, rendering the chain incapable of processing card transactions for several weeks. That’s a financially devastating outcome, one that has the potential to destroy a business.
Compliance’s Dark Underbelly
For illustrative purposes, let us suppose that you are an auditor in the financial industry. You conduct annual IT General Controls audits for all your in-scope IT systems. You continuously assess the effectiveness of your logical access, privileged access and segregation of duties controls. Now, have you considered SSH keys? Once you learn what those keys are and what they entail, consider that the assumption that someone’s managing them is often wrong. This is the “dark side of compliance.” CEOs and CFOs of publically traded financial organizations are required by law to attest the state of their internal controls annually. Access control is a key component of these attestations, so how accurate are they if SSH Keys based access (elevated in nature) is not part of the assessment?
Confronted with this harsh reality, those tasked with compliance issues understand that they must take action on SSH-related, key-based access. Then the logical three questions follow:
1. Where are your keys? How many do you have?
2. Are the SSH keys managed as part of your provisioning or governance processes? If so, who managed them?
3. Who and what connects to your production environment? Is the access authorized?
A negative or unclear answer to one or more of these questions means that immediate action needs to be taken.
No Time Like the Present
It can take a lot of work to get your SSH user key-based access under control, but it’s work that must be done and is, in fact, possible. The more security controls you implement as a standard business practice, the more likely you are to be compliant out of the box. Adopt the mindset of continuous compliance. It’s not a matter of checking a box that you set up a server; you need to harden everything that goes on that server. It may seem impossible to do this company-wide, but start with critical assets and then implement in phases.
Because of the complexity and volume of this issue, though, gaining control must not be a manual task. The Unix/Linux hosts example makes this clear. Automation is a crucially here, as is expertise in the SSH user key field. Bring in professionals for help if necessary.
Start this process now, before an audit or a breach occurs– because it’s only a matter of time before one or both occur. Keep in mind the below equation regarding what these keys truly represent.