Bank Systems & Technology is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

03:03 PM
Jonathan Camhi
Jonathan Camhi
Connect Directly

A Growing Security Risk in IT Automation

The increasing use of automated processes could expose organizations to new forms of malware if proper monitoring and controls aren’t put in place.

Financial institutions are increasingly relying on automated processes to run their business and IT infrastructures, but may not be doing enough to secure those automated processes from security threats, according to a study conducted last November by SSH Communications Security and Forrester. The study, conducted across several industry verticals, found that of the 109 organizations that said that machine-to-machine processes were important to their operations, 62% expect an increase in automated machine-to-machine processes over the next 12 months. In financial services, much of that increase in automation is around sensitive parts of the organization, such as billing and data management processes. More than half of the financial institutions in the survey already use machine-to-machine connections in their billing processes.

Many of organizations involved in the study use secure shell (SSH) keys to help secure automated processes like sending data form one machine to another (41%), administrator access control (40%), securing machine-to-machine transactions (35%) and data center management automation (31%).

But there is a growing threat in protecting those SSH keys from falling into the wrong hands. Just this month Kapersky Labs uncovered a malware virus, called “The Mask,” that targeted organizations’ SSH keys. “We’re seeing growth in these malware attacks that focus on encryption keys,” says Jason Thompson, director of global marketing at SSH Communications Security, the creator of the SSH security protocol. “If someone gets a hold of those keys, and the organization doesn’t have any monitoring or forensics in place, then they will be giving up critical information in a blind spot.” That makes it increasingly important for companies to ensure they have security and monitoring controls in place to protect access to their SSH keys for their automated processes, Thompson argues.

However many organizations don’t have the necessary controls in place around their SSH keys for automated processes to protect against potential hackers, the study found. Only 44% of the organizations in the study said they are monitoring the logins and activities of their keys’ privileged users.

[For More of Our Security Coverage, Check Out: 7 Security Predictions for 2014 from Booz Allen Hamilton]

This lack of security controls is largely due to a misunderstanding of the role of secure shell in data security, SSH’s Thompson notes. While 68% of the survey respondents said that data security was a critical priority, only 25% said the same about machine-to-machine security. “Many companies just haven’t thought about secure shell controls,” he says. But “if anyone has malware in that environment, the organization would have a real challenge. This is where some of the most critical data often is.”

Adding to the lack o understanding around this risk, many large organizations don’t have a view of all of their SSH keys, who has access to them and how the processes they secure are connected throughout the IT infrastructure. “A few banks are interested in this area, and they go and pull a report [on all of their keys]. They find they have 1.5 million keys, and a lot of different people with access to those keys,” Thompson reports. “They have to map out: what is this app doing? And who does it talk to? One secure shell key could tunnel through multiple networks and applications.”

The study found that only 34% of the organizations involved that use SSH keys can generate reports on how many SSH keys they have in their server environment and what those keys are used for.

Working to map out all of the keys, centralizing management of access to the keys and putting monitoring in place to detect malware is a project that can take years, Thompson warns. But banks that are already keeping track of access to their SSH keys can significantly cut down the time on such a project, he adds.

Thompson advises banks take three steps to help secure their machine-to-machine processes:

- Firstly, banks need to make sure that they encrypt their automate processes as a first step in preventing data breaches.

- Secondly, banks should adopt the same security policies for machine-to-machine processes that they have for manual human-to-machine processes. That means putting in authentication, auditing and monitoring tools to ensure secure access and keep an eye out for attacks.

- Thirdly, centralizing SSH key management will be important going forward in auditing access to keys both for security and compliance. (Note that the newest version of PCI compliance requires controls be put in place for SSH kay management.) Unfortunately most organizations in the study (65%) shared responsibility for the management of those keys among many individuals. But centralizing that responsibility will help increase visibility and enable faster responses to potential intruders.

[To learn more about how financial firms are preparing for and responding to security incidents, attend the Acknowledge the Inevitable: How to Prepare For, Respond to, and Recover from a Security Incident session at Interop 2014 in Las Vegas, March 31-April 4.


Jonathan Camhi has been an associate editor with Bank Systems & Technology since 2012. He previously worked as a freelance journalist in New York City covering politics, health and immigration, and has a master's degree from the City University of New York's Graduate School ... View Full Bio

Comment  | 
Email This  | 
Print  | 
More Insights
Copyright © 2018 UBM Electronics, A UBM company, All rights reserved. Privacy Policy | Terms of Service