News & Commentary

10:51 AM
Jonathan Lewis, SSH Communications Security
Jonathan Lewis, SSH Communications Security
Commentary
50%
50%

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.

[See Also: How to Protect Your Bank From an Information Heist]

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

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This is a secure windows pc.
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.