Secure Agile Cloud Development

A secure agile cloud development procedure to produce cloud-native and other applications starts first with a process. (See video at end of this article for a secure process.) This process defines how code created by a developer eventually makes it through to production and customer use. I have found that many companies do not even have such a process, or they have a very short process that primarily comprises the developers doing everything, including testing and security bits within their own little worlds. Since the same developer who wrote the code is testing and performing security, there are not enough eyes on the code to see all potential attacks.

There are also very few developers who have a security mindset, a mindset that thinks well outside the box for potential issues and attack mechanisms. So, we start with a flow of work. In many cases, that flow for waterfall projects is broken and disjointed, while for agile it seems fairly fluid.

As you can see in the previous diagrams, the process is very distinct. However, it is incomplete. Why is it incomplete? Because we still have a break between the developer and QA/test, even though we may place our code into production automatically. Where is the automation around testing or the creation of the infrastructure? We are still missing bits, and that is what can impact the security and stability of a cloud-native application. We need to add more into this process and involve others. What others? At least the infrastructure developers (who are today’s administrators who script everything) and some automated way to verify builds so that you can easily record issues into the scrum backlog.

By adding automation, as we have in the above, we only include one infrastructure developer (the administrator who writes scripts), but not those involved with security, and we still have no automated test. We even have no real security outside of what is done within the build server (if any). We are really looking only at build and orchestration failure points, not real security, or for that matter truly automated testing. There are many ways to add security into this process, and there are some great tools to help you. However, many of those tools are not tuned for agile cloud development and need some way to become hooked into your environment for use. Appropriate tools include code analyzers such as HP Fortify, dynamic code analyzers such as Core Impact, and testing automation tools such as Ixia BreakingPoint. There are many more listed at sectools.org.
When we add in such tools, we are changing how we look at the world. We are actually changing our mindset. Most importantly, we are not really changing how developers work. Instead, we are adding in more developers to help improve our agile cloud development experience. Where we end up is illustrated in Figure 4.

We can even go further and tie in not only security but application performance management as part of our automated testing. The goal here is to add security under the covers of the process, so the developers (of which we now have four classifications) can continue to do their job while issues are logged, testing is automated, and data protection is part of the process.
Data protection is made part of the process by using hooks as code is placed into our source code management system or repository. These hooks, of which AAC-Lib is one, are there to obfuscate, tokenize, remove, or deny code to be placed in the environment if it has embedded PII, PHI, API Keys, or anything else that could lead to backdoors, leaking data, or anything else that could break compliance or impact adversely an organization’s bottom line due to a breach of any sort.
Take a look at the following presentation, done recently for vBrownbag, for a good view on how to create a secure agile cloud development process for secure and automated continuous integration and deployment. Let us know your thoughts: