Cloud Computing Strategies for the CIOWhen it comes to security and cloud computing models, Platform as a Service (PaaS) has its own particular challenges. More than other cloud models, PaaS security
Requires Free Membership to View
requires application security expertise -- a skillset that most shops haven’t invested
heavily in. The issue is compounded because many organizations employ the strategy of “bolting on”
infrastructure-level security controls as a mitigation of application-layer security risks (for
example, the use of a WAF to help mitigate cross-site scripting or other front-end issues
discovered once application code is released to production.) This strategy becomes non-viable
in a PaaS deployment scenario due to lack of control over the underlying infrastructure in a
PaaS.
Consider the flexibility of PaaS relative to the control you have over the underlying computing environment. PaaS, like IaaS, provides nearly infinite design flexibility: you can build anything from social networking sites to corporate intranet sites or CRM applications. However, unlike IaaS, the “stack” below the application is opaque, meaning the components and infrastructure supporting the application are (by design) a “black box.” This means that, similar to SaaS, security controls must be built into the application itself; but unlike SaaS -- where the service provider usually implements application-level security controls that apply to all customers -- in PaaS, controls are specific to your app. This means the burden is on you to ensure those controls are appropriate and well implemented.
Here is a simplified illustration of the differences between the models and customer control:
For organizations that have invested heavily in application security, have solid developer training in place, and separate development, test and production processes, PaaS security should be familiar territory. Organizations that haven’t made these kind of investments, can follow these steps to help address the challenges of PaaS security.
PaaS security step one: Build security in
The fundamental challenges of application security were around long before the arrival of PaaS.
Consequently, there’s already been quite a bit of research into how to refine development efforts
to produce secure, robust applications. One technique that directly supports this is
application threat modeling. Some good starting points are the OWASP Threat Modeling Page and the
Microsoft Security Development
Lifecycle Resource Page. From a tool standpoint, the free cross-site
scripting (XSS) and SQL injection.
Organizations that have a tool in-house can leverage it for PaaS security, or many of the PaaS
providers provide those tools either free of charge or at reduced price to customers. Organizations
also can use a free tool like Google’s skipfish
while they iron out a broader scanning strategy.
PaaS security step two: Scan Web apps
Many shops have already embraced application scanning, a technique whereby tools scan Web applications for common security issues such as cross-site scripting (XSS) and SQL injection. Organizations that have a tool in-house can leverage it for PaaS security, or many of the PaaS providers provide those tools either free of charge or at reduced price to customers. Organizations also can use a free tool like Google’s skipfish while they iron out a broader scanning strategy.
Step three: Train developers
It’s critical that application developers are thoroughly versed in application security
principles. This can include language-level training (i.e. principles of secure coding in the
language they’re currently using to build apps) as well as broader topics such as secure design
principles. Developer
application security training can be expensive since developer attrition (not to mention
the fallibility of human memory) means training must be periodically repeated to stay relevant.
Fortunately, there are some free resources such as the joint Texas A&M / FEMA
Domestic Preparedness Campus, which offers free e-learning on secure software development.
Microsoft also offers free training through its Clinic
2806: Microsoft Security Guidance Training for Developers, which can be a useful starting point
while you bootstrap your own custom program.
Step four: Sanitize test data
It happens all the time: developers test with production data. This is an issue because
confidential data items, such as customer personally identifiable data, can get exposed in the
process, particularly when development or staging areas don’t have the same controls as
production. PaaS environments feel this acutely, as many PaaS services make it easy to share
databases between development, staging and production to streamline deployment. Tools like the
open source Databene Benerator can generate
high-volume data conformant to the particular structure of your database while data “scrubbers” exist to help sanitize
production data. These scrubbers are usually framework-specific though, so you may need to look a
bit to find one that works in your particular situation.
Step five: Reprioritize
This last one is the most important step you can take. Since PaaS probably means a culture and
priority shift, embracing that shift and representing security accordingly should be front of
mind. With PaaS, it’s all about the app; that means security organizations are highly
reliant on what comes out of the development side of the house. If that’s problematic without
PaaS, it’s going to be a nightmare afterwards since there’s not much you can bolt on at the
infrastructure level to mitigate identified risk. If you’ve historically relied on
infrastructure-level controls to meet security challenges at the application level, now’s the time
to rethink that strategy for PaaS security. Familiarize yourself with the application security
space now and don’t wait until you’re behind the eight ball to take action.
About the author:
Ed Moyle is a senior security strategist with Savvis as well as a founding partner of
Security Curve.
This was first published in April 2012
Join the conversationComment
Share
Comments
Results
Contribute to the conversation