This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter’s approach.
Secure Shell (SSH) is a tool for secure computer system management, file transfers and automation in computer and telecommunications systems. The Secure Shell protocol ships standard with every Unix, Linux and Mac system and is also widely used on Windows (Microsoft has announced plans to make it a standard component of Windows). It is also included on practically every router and mobile network base station. In many ways, the connected world as we know it runs on Secure Shell. Its keys are ubiquitously used for automating access over a network, and modern systems could not be cost-effectively managed without it.
The U.S. Federal Information Security Management Act (FISMA) requires that all agencies must meet minimum information security standards developed by NIST, the National Institute of Standards and Technology. The mandatory controls required to achieve this minimum level of security is set in NIST Special Publication 800-53, rev. 4. It represents the industry best practice and is also widely followed in the commercial sector; its recommendations are largely reflected in industry-specific security standards as well.
Just recently, NIST published NIST IR 7966, “Security of Interactive and Automated Access Management Using Secure Shell (SSH).” It provides guidance for enterprises, government agencies and auditors for implementing Secure Shell key management practices and polices.
The NIST IR provides an overview of Secure Shell authentication and public key authentication in particular. It then provides recommendations on how Secure Shell keys should be managed and maps these recommendations to mandatory requirements in NIST SP 800-53. The document was written by the best experts in the field, based on years of practical experience in working with customers (including several of the world’s largest banks and private enterprises) on Secure Shell key management solutions.It defines the best current practice for the industry.
For example, NIST mandatory controls include limiting access to an information system based on valid authorization (business need), the principle of least privilege, termination of access when it is no longer needed and a defined access control policy. Secure Shell keys are just one way of providing such access, similar to passwords or smart cards.
Negligence of the Most Basic Security Control
All information security—confidentiality, integrity and continued operation of a system—starts from controlling who is given access to the system and with what privileges. If anyone can get administrative access, there is no security.
If an organization does not even know how many Secure Shell keys grant access to their information systems, let alone who has those keys, why they were put in place, or if they are still needed, it is being negligent. In most organizations, about 10% of all configured Secure Shell keys grant privileged administrative access. In many organizations, 90% of all configured Secure Shell keys are no longer used – they represent a failure to properly terminate access when it was no longer needed.
Many large enterprises have had about ten times more Secure Shell keys than they have user names and passwords. Finding between 500,000 and 5 million Secure Shell keys in a 100,000-employee enterprise is common. Enterprises and government agencies cannot seriously continue to pretend 90% of their access credentials do not exist. It is totally reckless!
Many IT managers know they have a massive problem with Secure Shell keys, but they do not want to call attention to it because it is going to be expensive and painful to fix, and they are very busy. Even some CISOs and CIOs just ignore the issue, but often they just aren’t technical enough to know in detail what is going on inside their systems.
Chief executives, board members, and audit committees have legal responsibility to ensure that certain standards are followed in their organizations. SOX (Sarbanes-Oxley) requires personal certification from CEO and CFO, under criminal liability, regarding the accuracy and completeness of financial reports and internal controls around financial reporting. If the company does not even know how many Secure Shell keys grant access to unknown parties at unknown privilege level to financial systems, it is failing to implement even the most basic security controls.
Companies also face major risks if they allow uncontrolled key-based access from test and development systems to production, from primary to disaster recovery sites, or from other systems to backup and logging systems. PCI (credit card processing) environments are not always audited for Secure Shell key-based access from other systems, risking massive costs and reputation loss. Secure Shell keys can be used to quickly spread an attack within an organization and also to backup and disaster recovery sites.
Substantial training is required to get auditors and risk managers to address these issues.
How Did We Get Here?
The use of Secure Shell grew in a grassroots fashion from system administration, and its deployment never got much management attention or planning in most organizations. It was a standard component included in most operating systems, requiring no purchasing decisions. It is the invisible plumbing that runs our systems.
The use of Secure Shell keys has grown for two decades, unattended, with system administrators, consultants and vendors installing them at their convenience to give themselves access, automate file transfers between applications and automate systems management. Keys have almost never been removed or changed.
With no controls and policies in place, nobody has tracked how many keys each system has installed, what they grant access to, why they are there, or whether the need still exists. Furthermore, Secure Shell keys provide a way to bypass normal privileged access management systems that are supposed to audit and control access to sensitive systems and data. The situations appears very similar across industries, from manufacturing to banking to telecommunications to government.
Call to Action
What needs to be done?
- Both internal and external auditors must add Secure Shell key scanning and management to their checks. It is much better to wake up to the issue in an internal audit than be given an ultimatum by a banking regulator or having to explain to shareholders or the SEC why the doors are closed for the fourth consecutive week after a massive attack.
- Proper controls and tools must be put in place for managing Secure Shell keys. The real issue is authorized keys, as they are the ones that grant access. No matter how much you try to protect private keys, it is of no help until the millions of existing authorized keys have been sorted out.
- Regulators must establish firm deadlines for enterprises and agencies to get their acts together. Regulations themselves are already sufficient. FISMA, HIPAA, NERC CIP, PCI, COBIT and others already require controls over who can access the systems and data and the proper termination of access when no longer needed. However, implementation and audit guidelines should be clarified to ensure Secure Shell keys are taken into account.
- Boards, audit committees, CEOs and risk management officers must ensure Secure Shell key-based access is properly accounted for in their organizations to avoid civil and criminal liability.
Looking Ahead
The size, frequency and impact of breaches are increasing. The longer Secure Shell keys are lost in mismanaged network environments, the greater the chances hackers or malicious insiders will exploit them to access and steal sensitive data. While the Secure Shell protocol itself remains secure, an effective risk mitigation strategy must include effective key creation, deployment and management practices. Auditors and hackers alike will be paying keen attention to this issue in the coming years. It’s time for organizations to step up and do the same.
About the Author
Ylönen released the first Secure Shell version in 1995 as open source, in response to a password-sniffing incident in which passwords from his company were stolen. The open source version eventually became OpenSSH. He founded SSH Communications Security in 1995 to build commercial security solutions around the protocol. Today, the company serves more than half of the world’s top ten banks and 40% of Fortune 500 companies, focusing on managing Secure Shell key-based and privileged access. It is also the producer of the world’s most widely used commercial Secure Shell implementation. Ylönen is the company’s Chief Innovation Officer, working on next-generation key management solutions that will change the market via ease of use and massive scalability. He holds approximately 50 U.S. and international patents.
Tatu initially drafted the guidelines for NIST IR 7966, after having worked with several large-scale key management projects with some of the world’s largest enterprises. In part, the work is based on an earlier Internet draft published with the IETF (Internet Engineering Task Force). Paul Turner of Venafi, Karen Scarfone of Scarfone Cybersecurity, Murugiah Souppaya of NIST and numerous reviewers also contributed significantly to the various revisions
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.