Network security standards are in the works that will push banks to make substantial changes this summer.
The standards, from the Internet Engineering Task Force and the National Institute of Standards and Technology, focus on an obscure yet important area of IT: the management of SSH keys companies use to secure the access to and movement of data between networked servers.
A cybercriminal who accesses one SSH key could hack into one company computer and from there gain access to all other machines on that network, according to Tatu Ylonen, the inventor of the Secure Shell (SSH) data-in-transit security protocol and founder and CEO of SSH Communications Security. Many strains of malware collect SSH keys to gain access to multiple servers.
Banks have thousands, and in some cases millions, of SSH keys floating around their organizations vulnerable to theft and compromise. This is turning up in IT security and Sarbanes-Oxley audits. Bank regulators in the U.S., Singapore and India have begun focusing on this issue and ordering banks to fix it.
"One bank found more than a million keys that grant access to servers, many of which were no longer needed," Ylonen relates. "It failed an internal SOX audit and spent $1.8 million on remediation services. Many banks and other organizations have four to twenty times as many access credentials as they have people in their organizations. It's clear that they can't continue to ignore this."
"Tatu, as the inventor of the SSH protocol, unknowingly over time has created a situation where the SSH keys themselves can be keys to the kingdom and used by criminals, nation-states or anybody who has access to them to do bad things," says Richard Weeks, president, Americas for SSH Communications Security.
There is no evidence to suggest that the current wave of distributed denial of service attacks targeting banks have involved a compromise of SSH keys. DDoS attacks by nature don't involve a security violation of the server under attack, but an excessive flow of traffic to that server to slow it down. But the malware used to execute a DDoS attack could gain illicit access to a server as a launching point, potentially by gaming the SSH protocol. (The malware behind many recent anti-bank DDoS incidents is Brobot, a Trojan horse that allows a remote attacker to use a compromised Web server to launch distributed denial-of-service attacks.)
There have been publicly recorded security breaches involving SSH. In January of this year, some users were caught storing keys and passwords, including SSH keys, in public repositories on GitHub, a Web-based hosting service for software development projects. One exposed SSH password was to a production server of a major web site in China, according to Charles Kolodgy, research vice president for IDC's security products service.
The standards being developed by the IETF and NIST will be voluntary, at least at first. But what NIST requires within the government tends to trickle down to civilians, Ylonen notes.
The IETF recommended practice document requires companies to find out who has access to what throughout their IT organization. It requires companies to move authorized keys to protected locations, remove unused keys, associate authorized keys with a business process or application, and remove keys for which no valid purpose can be found. Companies are also expected to rotate existing keys, restrict what can be done with each authorized key, and establish an approval process for new authorized keys. They're expected to continuously monitor and control authorized key setup.
"There should be no keys that you don't know why they are there," Ylonen says. "Access should be on a need basis, there should be some business justification for each [person or machine] to have access.
SSH Communications Security is going through this process at several large banks — five out of the top 10 U.S. banks are its customers. "We have 10 people on site at a major bank in New York, helping them go through what each key is being used for," Ylonen relates.
Banks can handle all these steps manually. "In a small environment, that's totally reasonable," Ylonen says. "If you have 100 servers, no problem. But if you have 100,000 servers, there's no way you can do it manually."
The company has launched a free discovery tool to enable companies to find and assess the risk of their SSH keys. It's intended to expose the extent of the problem and the degree of risk caused. It can be used by internal and external auditors and by regulators. It produces a report that lists the keys that have the broadest access throughout an organization and that pose the highest risk. According to Weeks, the Big 4 IT audit firms — PwC, Deloitte, Ernst & Young and KPMG — are interested in the tool. It takes about two to three days to make its site-wide risk assessment.
