As we all know, when you run things in the "Cloud" it’s "as-a-Service". There’s Software as a Service (SaaS), which started the terminology, Infrastructure as a Service (IaaS), Platforms as a Service (PaaS), etc. Therefore, it would stand to reason that security holes in your cloud deployments would have to be called aaS holes. If you are in the process of moving applications to the cloud, or deploying a cloud infrastructure (and who isn’t?) you are going to have to deal with a lot of aaS holes. This blog is here to help.
First, let’s talk about the types of aaS holes you are going to have to deal with. I’ll start with Engineering aaS holes. These are the problems caused by the fact that software is written by people with little training in application security. This is not their fault. Computer Science and Engineering programs, as well as the professional education that follows, focus on building software to do things – they do not address how that software can be abused and how to defend it.
Then there are the Sales aaS holes. Sales aaS holes are those caused by cloud service vendor’s infrastructure that does not do what their specifications say with respect to security or change after you contract with them. While you may have an SLA, a sort of no aaS holes rule for the services provided, liability is often limited to what you paid for the service while the cost of a breech can be far more.
Then you have your Product Management and Marketing aaS holes. These are caused by requirements of your applications and infrastructure that work against good security practice. The user experience is a primary factor that must be addressed when designing and building applications, but this and many other things can be used as an excuse to avoid security requirements, which if done properly can actually save time and money.
Last but not least, everybody has to deal with Management aaS holes. There are those caused by the lack of good systems management and monitoring which mean your application gets deployed on the wrong virtual image, in the wrong place or without the right configuration. Then there are those caused by a lack of security priority, process and information at the management level, leading to groups not having security goals, or poor coordination and execution on those goals.
There’s no doubt about it - when your applications move to the cloud, there’s a whole new world of aaS holes to deal with, so how do you do that? There are a series of steps you can take from small initial steps that will help to an entirely new way of doing things that will increase security and make you more efficient.
When building and deploying applications, the ultimate goal is to use a secure SDLC which will actually save you time and money. This addresses the PM and Marketing aaS holes with building security requirements in to the process. It addresses Sales and Management aaS holes with Threat Models, Attack Surface Analysis, and Deployment stage specification and activities that prevent and defend against aaS holes. Finally, it addresses Engineering aaS holes with secure design, coding and test practices as well as education and reference material on these.
The simple steps to start on the path to the goal of a secure SDLC start with an SDLC gap analysis and some training to get all parts of the process educated on the goal, the need and an understanding what has to be done to get there. From there, Threat Modeling and Attack Surface Analyses are low cost activities that will help you understand what you face and where you are facing it, as well as set some more concrete goals and non-goals. Your SDLC gap analysis will map out the steps from there that make the most sense for your situation.
As you can see, moving applications into the cloud means dealing with aaS holes. Butt, with the right help from a company like Security Innovation, and a little patience and perseverance, dealing with aaS holes can be a lot less painful than you think.