How to Protect Your Bank From an Information Heist

Ever since it was rolled out to the market in the mid-90’s, the secure shell (SSH) data-in-transit protocol has been used by financial institutions worldwide to both protect sensitive data as it moves from machine to machine and to provide remote administrator access. The exact number of secure shell deployments worldwide is impossible to pinpoint, but can easily be estimated in the millions – making secure shell an asset ubiquitous in the financial network security world.

Since its creation, it has secured billions of financial transactions without suffering any major security breaches caused by vulnerabilities in the protocol itself. While the protocol itself is highly secure, today’s rapidly-changing threat landscape is forcing banks and other financial institutions to reconsider how they manage their secure shell environments.

Misplacing the Keys to the Safe

Traditionally, banks use secure shell to transfer massive amounts of sensitive financial and business information, including credit card numbers, personally identifiable data and account information. From the perspective of an attacker or malicious insider, secure shell is an artery that carries data linked to the money itself.

Yet since the protocol itself is secure, how would a hacker get access to sensitive financial information protected by secure shell?

The answer is the financial industry’s dirty little secret.

When users connect via secure shell, a trust relationship between a computer and the server is created using a cryptographic key pair. One key is installed on the user’s computer, and the other is installed on the server. These trust relationships are created and managed by the bank’s IT team, sometimes on systems close to 20 years old. None of these systems have the ability to search for – let alone find – where the company’s trust relationships exist. Tracking trust relationships must therefore be done manually. When a network has potentially hundreds of thousands of keys, trust relationships are inevitably lost. If a malicious actor – internally or externally – gains access to one of these keys, he or she can mimic an authorized user with impunity.

Improper management of secure shell keys, therefore, presents a prominent vulnerability available for exploitation by attackers looking to gain access to sensitive information. After a study was performed on the management operations of some of the largest financial organizations in the world, a disturbing trend appeared:

-- About 10 percent of all secure shell user keys provide root access, creating a major security and compliance issue

-- Financial organizations often share the same secure shell host keys across thousands of computers, which leaves the network vulnerable to attack

-- The use of each secure shell key is rarely known, which poses both a security risk and a business continuity risk

-- Many secure shell keys that grant access to critical servers are forgotten or no longer in functioning

-- In some instances, bank administrators have permission to create or delete secure shell user keys without approval – basically issuing uncontrolled access to systems and people

-- Few secure shell user keys are ever rotated or removed if an employee leaves the organization or an application is halted

-- Secure shell host keys are often shared across multiple locations and thousands of computers, making the network extremely vulnerable to man-in-the-middle attacks

-- Key-based access grants are essentially permanent, in direct violation of SOX, PCI and FISMA requirements for proper termination of access

Financial institutions are facing very real and very serious risks as advanced persistent threats become more common. Neglecting best practices for managing secure shell keys greatly increases the risk for any bank or financial organization.

Not only are there clear security implications that accompany the mismanagement of secure shell keys, but financial organizations need to pay particular attention to federal compliance standards, such as FISMA and SOX, that mandate financial institutions maintain complete control over who has access to sensitive information. Neglecting to do so means costly fines and headaches. From a purely economical standpoint, most organizations have over 20,000 servers in use, which comes out to a $40 million cost over ten years to manually manage secure shell keys. These costs, coupled with the reputation damage an institution can suffer, makes a very good argument for why banks must quickly fix any secure shell key management issues.

Adjusting the Approach to Key Management

Luckily for financial institutions, access control problems that occur in secure shell environments don’t originate from any flaws or vulnerabilities in the protocol itself. The risks stem from the following situations:

-- A lack of guidelines or policies directly relating to secure shell key management

-- A misunderstanding of the reach and potential implications of secure shell key mismanagement

-- Insufficient resources, such as time any money, to devote to learning about the risks or develop solutions

-- A proactive list of guidelines and tools for solving key management issues before they escalate

-- The tendency for auditors to ignore issues for which they don’t have solutions

-- The focus of the access management field on interactive users without addressing automated access

With clear evidence that secure shell key mismanagement is prevalent in the financial industry, it’s difficult to understand why the problem hasn’t been remediated years ago. Unfortunately, secure shell key management is a very technical process that tends to remain hidden away except to system administrators. Even so, each administrator tends to see only one small portion of an institution’s IT operations and therefore doesn’t fully understand the far-reaching implications of such problems. Coupled with the fact that management may be far removed from the problem and therefore miss seeing it altogether, means that nothing is done at all.

How to Remediate Secure Shell Key Management

With vulnerabilities typically found in all Unix/Linux servers and many Windows servers, the necessary steps an organization must take to solving this problem will require the involvement of many people in the IT department. In addition to IT involvement, executive management will need to step-in as well to protect the company from neglecting any compliance regulations that could bring about liability for the organization.

In approaching the problem, here are some important practices financial institutions should start with:

-- Automate key setups and key removals thereby eliminating manual work and human error. This step reduces the number of administrators needed for key setups to a few highly trusted administrators

-- Discover all existing users, public and private keys and mapping trust between machines and users

-- Enforce proper approvals for all key setups

-- Monitor environment to determine which keys are actually in use and remove the ones that are not

-- Rotate keys regularly so that copies cease to work and proper termination of access can be ensured

-- Restrict access for each key and which commands each key is capable of executing

Additional steps that can be taken to ensure security and compliance will involve establishing internal boundaries within the financial organization. The institution should closely control what key-based trust relationships can cross boundaries, while enforcing iron-clad IP address and “forced command” restrictions for all authorized keys.

While secure shell is widely considered the benchmark for data-in-transit security, the current threat landscape requires banks and other financial organizations to reconsider how they are managing access to their encrypted networks. The secure shell protocol does its job in protecting data-in-transit at a tactical level, but an increasing number of threats means effective management of the secure shell environment is necessary to secure operations. Best practices, like the ones identified above, will position your bank to prepare for security threats and new compliance mandates before they occur

Jason Thompson is director of global marketing for SSH Communications Security