News & Commentary

11:11 AM
Oren Hamami, SunGuard Availability Services
Oren Hamami, SunGuard Availability Services

Protection in the Cloud

DDoS attacks are already a huge concern for banks, and moving infrastructure to the cloud can open new vulnerabilities for banks from such attacks. Here’s a step-by-step plan to protect your infrastructure in the cloud.

Headlines tell the story: “DDoS Attacks on Major Banks Causing Problems for Customers.” “Hacktivists expand bank DDoS attacks.” “DDoS Attacks on Banks Resume.”

No wonder distributed denial of service (DDoS) attacks have become the No. 1 concern for a growing number of financial institutions. As one bank analyst describes it, “Literally, these banks are just in war rooms, sitting at controls trying to stop [the attacks].”

Security remains a major concern as FIs move to cloud computing, and vulnerability to DDoS attacks should be considered as part of this move. So just what are the DDoS risks for FIs when moving to the cloud? And what steps can they and their cloud providers take to dispel these concerns?

A DDoS attack is an attempt to make one or more computer systems unavailable, typically by overwhelming them with a large number seemingly legitimate requests. Traditionally, these attacks were targeted at web servers. Increasingly, however, attackers target supporting infrastructure that may not be as well protected, such as the domain name service, which translates Internet domain and host names to IP addresses.

An attack from a single computer is easy to block using traditional security technologies, such as firewalls. But today’s DDoS assaults are an orchestrated bombardment from thousands or even tens of thousands of computers. The result: edge protections such as firewalls are unable to differentiate malicious requests from normal traffic, and cannot block them without also blocking legitimate requests.

A hosted cloud service is vulnerable to the same DDoS attacks as any other hosted service, including direct attacks on cloud-based web servers and attacks on a provider’s supporting infrastructure. However, because of its heavy use of software-based virtualization and management systems, a cloud service’s supporting infrastructure can have a significantly larger attack surface, and may be vulnerable to attacks from the outside and from within.

So what’s a financial institution to do when it wants to move to the cloud?

• Get your cloud host provider to explain in depth how it protects its cloud management system and its customers’ information from orchestrated attacks. This includes explaining its approach to protecting against traditional attacks as well as those that specifically target cloud technologies.

• Have your provider discuss the “bad neighbor” problem that can be more prominent in the cloud. That’s when your cloud server or application could be running on the same physical server as another customer and that customer gets attacked and you suffer collateral damage. Find out how the provider prevents one customer from impacting another on the shared infrastructure. Be sure the provider isolates network connectivity from one customer to another.

• Consider using multiple clouds or combining a public cloud deployment with a private or hybrid component. This may not protect against an attack targeting you directly, but it provides a hedge against attacks on any single provider’s cloud infrastructure.

• Determine whether a cloud provider is leveraging other cloud providers to deliver its services. Such “nested” clouds are particularly common among Software-as-a-Service providers who often deploy their software on another cloud provider’s infrastructure, which may also be vulnerable to DDoS attacks.

• Recognize that more attacks are emanating from cloud providers themselves as an attacker sets up fraudulent accounts and uses the cloud servers, each far more powerful than a single desktop computer, to launch large-scale attacks. This can result in collateral damage to you if you use the same cloud provider, both through exhaustion of the cloud provider’s resources (see the “bad neighbor” problem) and by the provider’s network being blacklisted as a source of attacks.

• Make sure to develop and test a contingency plan. This plan should account for DDoS attacks directly against an FI’s servers as well as those targeting a provider’s infrastructure, and should identify roles, responsibilities and response procedures for both the FI and the provider.

• Consider leveraging cloud services as part of a broader DDoS resiliency strategy. Cloud-based recovery services may enable you to rapidly recover key systems in the cloud when your primary facility is under attack. Don’t let your security concerns overshadow the promises of effective cloud computing. The cloud does introduce some new DDoS risks, but also presents tremendous opportunity for improving overall resiliency.

The cloud is not a panacea, but it should not be ignored entirely. The most successful FIs will be those that understand the risks and tackle them head on.

Oren Hamami is director of Security Strategy at SunGuard Availability Services.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Janice, I think I've got a message from the code father!
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.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
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 ...

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

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

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.

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.