Identity and access management solutions provide governance and visibility capabilities that enable organizations to provision and control access to their applications, cloud infrastructure, servers and both structured and unstructured data. Enterprise IAM deployments are generally effective in managing the identities assigned to interactive, human users. However, within a typical enterprise there often are a greater number of identities assigned to the automated processes that drive much of the computing in large- scale data centers. As enterprises adopt more and more process automation, the number of non-human identities continues to grow while the number of identities assigned to human users remains relatively flat or even declines. The net result is enterprise IAM deployments are ignoring the much larger set of identities that actually perform most of the enterprise computing functions.
The vast majority of the identities enabling machine to machine (M2M) processes use Secure Shell for authentication, authorization and to provide a secure encrypted channel for M2M data transfers. For example, an automated process that retrieves server log data requires an authenticated and authorized connection to each server, plus a secure channel to move the log data to a centralized processing application. Secure Shell is ideal for these functions because:
- Public key (PKI) based authentication supported by Secure Shell enables the process to present its credentials without requiring an interactive user to login via username and password - or via any other interactive authentication process.
- The PKI based authentication process used by Secure Shell provides security for the login credentials. The private Secure Shell user key is never sent over the network.
- Secure Shell provides facilities to define and limit what functions a process may perform under a Secure Shell authorization. This meets "need to know, need to do" criteria of basic IAM governance.
- Finally, Secure Shell provides for confidentiality of data in transit. Communications over a Secure Shell channel are encrypted.
In spite of these advantages, there are significant gaps in IAM governance of identities that use Secure Shell. Typically, the provisioning of these identities is decentralized. Identities may be assigned by application developers, application owners and process owners. This often leads to a lack of proper control and oversight over creation of identities and their authorizations. Without central management and visibility, enterprises cannot be sure how many Secure Shell identities have been created, what these identities are authorized to perform and what authorizations are in fact no longer needed. The scope and nature of this problem are not theoretical. The typical enterprise server has between 8 and 100 Secure Shell authorizations (i.e., public Secure Shell user keys). This adds up. A large enterprise may have over one million keys, which in turn establish an even greater number of unmanaged machine-to-machine (M2M) trust relationships.
The Challenge of Ubiquitous Encryption
While many in IT security use Secure Shell to securely access remote servers, most are surprised to discover that M2M communication makes up the majority - in some cases over 90% of all Secure Shell traffic - on their network. The vast majority of Secure Shell trust relationships provide access to production servers and carry high-value payloads; including credit card information, healthcare records, national secrets, intellectual property and other highly critical information.
Shockingly, access to M2M encrypted channels via Secure Shell, which uses keys to authenticate a non-human user, almost always lacks proper identity and IAM controls, creating a huge risk and compliance issue for most enterprises. Any interactive user who has the proper credentials - in the case of Secure Shell, a simple copy of the key file - can hijack these uncontrolled M2M networks. This means that, in many cases, the most valuable information in the enterprise has the least amount of protection from unauthorized access.
Most large organizations have between 100,000 to well over a million of these keys in their network environments. Even though these keys grant access to critical systems and servers, many have never been changed. Even more incredibly, many organizations have no process for approving and enforcing who can grant permanent access to servers using these keys. One study at a large bank, with over one million keys in use, found that 10 percent of these keys granted unlimited administrative ("root") access to production servers; a grave security risk.
The lack of security controls - coupled with the high value of data it protects - has made Secure Shell a target for hackers. A recent IBM X-Force study found most attacks against Linux/Unix servers utilize stolen or lost Secure Shell keys as a threat vector. Because many keys are deployed in one-to-many relationships, it is possible that a single breach related to a compromised key could have a cascading effect across a large swath of the network environment.
In an ironic twist, the very function that blinds prying eyes from spying on sensitive data in-transit also prevents systems administrators from seeing whether information is being accessed improperly using a stolen Secure Shell key. All data-in-transit encryption, including Secure Shell, blinds layered security defense systems to malicious activity originating from a hacker, trusted insiders, business partners and outsourced IT. This means that unless the enterprise has deployed an encrypted channel monitoring, security operations and forensics teams cannot see what is happening in the encrypted network. Encrypted channel monitoring enables security intelligence and DLP solutions to inspect, store and - if need be - stop traffic to make sure hackers or malicious insiders cannot use Secure Shell encryption to spirit away information in an undetectable and untraceable manner. This way, the network administrator can track what a user is doing inside the encrypted channel, without exposing the data in the clear during transmission.
Evolving Standards to Include Other Authentication Methods
Moving to protect themselves against both hacker attacks and security compliance mandates, many enterprises are bolstering interactive user authentication methods; including enforcing password strength, requiring periodic password changes and implementing two-factor authentication. These methodologies are designed to confound hacker attempts to access interactive accounts through brute force attacks, lost or stolen passwords, or spoofed credentials. These approaches are now considered best practices and are enshrined in compliance requirements like PCI, HIPAA, FISMA, SOX and others.
Currently, compliance bodies are updating their regulations to specifically include other methods of authentication above and beyond user names and passwords - such as certificates and keys - in their regulatory language. This means that auditors will be required to flag instances where access is not being controlled via Secure Shell. This is a natural progression for compliance mandates, arriving at a time when the market is beginning to recognize that strong standards are required to ensure the safety of the enterprise's most critical business information.
Best Practices
To provide the highest levels of security and accountability, it is in the organization's best interest to research, design and deploy an IAM strategy that includes processes designed specifically for M2M communications. A comprehensive, best practices-based IAM program that includes provisions for Secure Shell-based M2M security must address both the provisioning and intelligence aspects of IAM across large, complex and heterogeneous environments.
Best practices based Secure Shell key management enables strong authentication practices, including:
- Restricting root access to servers so that only the key manager can provision or revoke keys
- Automated key creation, rotation and removal
- Discovery and continuous monitoring of trust relationships and unauthorized key deployments and removals
- Enforcing proper key type, size and version of Secure Shell
- Controlling where each key can be used from and what commands can be executed using the key
- Monitoring traffic in encrypted channels
Looking Ahead
In an environment where ever-increasing numbers of users, devices and machines are connected to the Internet and the company network, ensuring that the enterprise's IAM strategy includes strong Secure Shell access controls in M2M communications is mission-critical. While ubiquitous encryption offers clear network security benefits, left unmanaged it can present a significant threat to the business. IT security, compliance and audit professionals must begin the process of addressing Secure Shell access control and governance issues. The absence of such controls creates security vulnerabilities and can cause an organization to run afoul of compliance mandates, resulting in the risk of fines and other liabilities. By critically examining the organization's Secure Shell environment, IT teams can reveal and address the M2M access control issues that lie beneath the tip of the iceberg.
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
