Most Read This Week
Does Cloud Shift the Burden of Security to Development?
Three ways to help development bear the burden of security that the cloud places on them
By: Cynthia Dunlop
Dec. 11, 2013 11:12 AM
The move to the cloud brings a number of new security challenges, but the application remains your last line of defense. Engineers are extremely well poised to perform tasks critical for securing the application—provided that certain key obstacles are overcome.
This paper explores three ways to help development bear the burden of security that the cloud places on them:
New Risks, Same Vulnerability
Before the move to the cloud, few organizations lost sleep over application security because they assumed their internally-controlled security infrastructure provided ample protection. With the move to cloud, security concerns are thrust into the forefront as organizations consider how much security control they are willing to relinquish to cloud service providers and what level of exposure they are willing to allow.
The fact of the matter is that with or without the cloud, failure to secure the application always is—and always has been—a dangerous proposition. Even when the bulk of the network security rested under the organization’s direct control, attackers still managed to successfully launch attacks via the application layer. From the 2002 breach at the Australian Taxation office where a hacker accessed tax details on 17,000 businesses to the 2006 incident where Russian hackers stole credit card information from Rhode Island government systems, to the recent attack that brought down the National Institute of Standards and Technology (NIST) vulnerability database, it’s clear that a deficiency in the application layer can the be one and only entry point an attacker needs.
Public cloud, private cloud, or no cloud at all, the application is your last line of defense and if you don’t properly secure the application, you’re putting the organization at risk/ Nevertheless, the move to the cloud does bring some significant changes to the application security front:
With the move to the cloud placing more at stake, it’s now more critical than ever to make application security a primary concern. The industry has long recognized that development can and should play a significant role in securing the application. This is underscored by the DoD’s directive for certifications in the area of software development security (e.g., via CISSP). Select organizations that have successfully adopted a secure application development initiative have achieved promising results. However, such success stories still remain the exception rather than the rule.
Should Development Be Responsible for Application Security?
Due to software engineers’ intimate familiarity with the application’s architecture and functionality, they are extremely well-poised to accomplish the various tasks required to safeguard application security. Yet, a number of factors impede engineers’ ability to shoulder the burden of security:
In the following sections, we explore how strategies related to penetration testing, service virtualization, and policy-driven development can better prepare engineers to bear the heavy burden of security that accompanies the shift to the cloud.
Moving Beyond Penetration Testing: Divide and Conquer
Penetration testing is routinely used to barrage the application with attack scenarios and determine whether or not the application can fend them off. When a simulated attack succeeds, you know for a fact that the application has a vulnerability which makes you susceptible to a particular breed of attacks. It alerts you to real vulnerabilities that can be exploited by known attack patterns—essentially sitting ducks in your applications. When a penetration attack succeeds, there is little need to discuss whether it needs to be repaired. It’s not a matter of “if”, but rather of “how” and “when.”
The common reaction to a reported penetration failure is to have engineers patch the vulnerability as soon as possible, then move on. In some situations, taking the path of least resistance to eliminating a particular known vulnerability is a necessary evil. However, relying solely on a “whack a mole” strategy for application security leaves a considerable amount of valuable information on the table—information that could be critical for averting the next security crisis.
Switching to a non-software example for a moment, consider what happened when the US Army realized how susceptible Humvees were to roadside bombs in the early 2000s. After initial ad-hoc attempts to improve security with one-off fixes (such as adding sandbags to floorboards and bolting miscellaneous metal to the sides of the vehicles), the Army devised add-on armor kits to address structural vulnerabilities and deployed them across the existing fleet . In parallel with this effort, they also took steps to ensure that additional protection was built into new vehicles that were requisitioned from that point forward.
How does such as strategy play out in terms of software? The first step is recognizing that successful attacks—actual or simulated—are a valuable weapon in determining what parts of your application are the most susceptible to attack. For example, if the penetration tests run this week succeed in an area of the application where penetration tests have failed before—and this is also an area that you’ve already had to patch twice in response to actual attacks—this module is clearly suffering from some underlying security issues that probably won’t be solved by yet another patch...
Want to read more? You can access the complete article here.
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads