Securing Machine-To-Machine Connections Through Encryption Key Management

Without best-practice controls, banks expose themselves to the risk of security liabilities and noncompliance with industry and government mandates

Today’s bank is a global entity. Consumers can access their checking accounts from their mobile phones or tablets, from virtually anywhere in the world. Employees can join meetings or check messages remotely from another continent. With so many points of access to the bank’s network, however, comes added risk for a malware or hacker breach. To protect against forgotten back doors to the bank’s most sensitive information, its IT team must deploy a holistic identity and access management (IAM) strategy. While IAM systems adequately manage identities given to human users, the bulk of network connections are comprised of machine-to-machine (M2M) connections, which often approach 90 percent of a network’s authenticated connections.

Clearly, banks and other financial institutions’ data is a bonanza of actionable data for hackers and malicious insiders. Therefore, it is imperative for banks to get their keys under secure management.

What is an Encryption Key?

One commonly-used encryption method for financial institutions using machine-to-machine processes is the Secure Shell data-in-transit protocol. It delivers authentication, authorization and an encrypted channel for data transmission. Financial institutions prefer this protocol because:

-- Secure Shell provides the ability 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.

-- 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.

-- Finally, Secure Shell provides for confidentiality of data in transit, since communications over a Secure Shell channel are encrypted.

Despite Secure Shell’s benefits, there are usually large holes in IAM processes of organizations that use the Secure Shell protocol. The problems start with how the keys are created and provisioned; often through a decentralized process. Application developers and owners – and even processes owners – have the ability to create and administer identities. With poor central management, financial enterprises can’t track how many Secure Shell identities exist, what each identity is allowed to do and which identities are no longer needed. The average financial organization has anywhere between eight and 100 Secure Shell operations while larger financial institutions can have in excess of over one million keys. Because they have so many keys, these organizations tend to have a large amount of unmanaged M2M trust relationships.

Optimizing A Universal Encryption Environment

Most Secure Shell trust relationships provide access to production servers and carry important data like credit card information, healthcare records, national secrets, intellectual property and other critical information.

Yet despite the high value of the data it protects, banks and other financial institutions all too often lack adequate IAM controls over their Secure Shell environments, creating a huge risk and compliance problem for most financial institutions. In these mismanaged environments, any user with proper credentials, such as stolen or lost key, can gain access to the bank’s most sensitive data. This results in most of the sensitive information within the financial institution’s network database having the least amount of protection.

The average large financial institution can have anywhere from 100,000 to over one million keys in their network. Despite these keys granting access to critical systems and serves, most have never been changed. Incredibly, most organizations don’t have a protocol to address who is allowed to give permission to access servers using these keys. A study conducted at a large bank with over a million keys found that at least 10 percent of these keys allowed for unlimited administrative (“root”) access to production servers, which presents a very serious security risk.

The dearth of security controls paired with the high value of the data they guard makes Secure Shell a focus for hackers. Recently, an IBM X-Force study found that most attacks against Linux/Unix servers used some kind of stolen or lost key as a threat vector. It is entirely possible that one single breach caused by a single compromised key could bring about a chain reaction of access violations across the network because so many of the keys deployed have one-to-many relationships.

Ironically, the process that keeps unauthorized eyes from viewing the sensitive data also keeps system administrators from determining whether information is being accessed with a stolen key. Because data-in-transit encryption methods blinds observers to the data traveling within its hardened shell, security defense systems cannot see malicious activity coming from a hacker, trusted insider, business partner or outsourced IT without an encrypted channel monitoring system in place. Encrypted channel monitoring allows for security intelligence and DLP solutions to inspect, store and stop traffic to ensure hackers and malicious insiders can’t use the Secure Shell encryption to steal information without leaving a trace. By implementing a monitoring system, network administrators can see what a user is doing inside the encrypted channel without exposing the data in the clear during transmission.

Updating Standards for Other Methods of Verification

As a precautionary measure to protect themselves again both hackers and security compliance mandates, a large number of financial institutions are improving interactive user authentication methods such as enforcing password strength, requiring periodic password changes and including two-factor authentication. These processes were created to puzzle hackers attempting to access interactive accounts by brute force attacks, lost or stolen passwords or spoofed credentials. Approaches like these are considered best practices and are a large part of compliance requirements like PCI, HIPAA, FISMA and SOX.

At the moment, compliance bodies are revising their regulations to include other methods of authentication above and beyond user-based authentication, such as usernames and passwords and certificates, to include machine-to-machine authentication methods, such as keys. Because of these new rules, auditors will be mandated to flag instances where access is not controlled via Secure Shell or other key-based authentication methods. These new rules are just part of the natural progression for compliance mandates, coming at a time when financial institutions are realizing that strong standards are necessary to keep their most sensitive data safe.

With a larger amount of people, devices and machines connecting to the company network, financial institutions must ensure that their IAM plans contain proper Secure Shell access controls for M2M transmissions. IT security, compliance and audit experts must discuss the issues surrounding improper Secure Shell access control and governance. Without best-practice controls, banks expose themselves to the risk of security liabilities and noncompliance with industry and government mandates. IT teams can expose and fix the M2M access control issues by looking closely at the organization’s Secure Shell environment.

Jonathan Lewis is director of product marketing for SSH Communications Security