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