Building Bridges from Security to Development, Part II
This is part 2 of 4 in a blog series on key trends in securing the public cloud.
If we had to categorize companies deploying infrastructure in the public cloud into two buckets we would call one cloud native and the other cloud migrant. Cloud native companies are typically less than 10 years old and made the decision early on to go 100% cloud, meaning they have no data center, and they do not deploy any server.
Although most people consider this startup culture, publicly traded companies with multi-billion dollar market caps can also be cloud native. The second category, cloud migrant, is made of more established companies that have one or more of the following in common:
- They have decided to transition some or all of their workloads to the cloud
- They have acquired a cloud native company
- They have departments or subsidiaries that have adopted the cloud
Use cases across both categories vary widely, but there is one commonality: velocity. Cost, flexibility, and scale are cited as reasons why organizations decide to use the public cloud. However, the ability to move at the speed of today’s technology innovation comes out on top more than not, time after time.
So, on one side of the spectrum you have speed as a cloud adoption driver; on the other end you have the need for security.
Starting again.
One positive aspect of securing the public cloud is that you have the opportunity to start from a clean slate which can bring new ideas, approaches, and solutions. There is no changing the engine of the airplane mid-flight, and when your start deploying workloads in the cloud, you are literally at takeoff. With that I believe you have the opportunity to rid security of the reputation of being slow, often behind, and of being the proverbial roadblock to velocity.
As I mentioned in my AWS re:Invent recap, Werner Vogels so eloquently said that security comes before building the system and that we are all security engineers. We all know that this is easier said than done, but as a start, it’s time for both developers and security engineers to establish a bridge and close some of the communication and technical gaps that exist today.
The good news is that we are seeing the gap between the two groups getting closer more and more frequently in our customer base. With cloud native organizations, security is often core to the responsibility of engineering and with cloud migrants, security is being engaged in cloud projects, M&A diligence for cloud. Public cloud might even be used for security projects.
What’s next?
In part three of this series, I will outlined how visibility is the next key component to securing public cloud. We all know that you can’t secure what you can’t see but there is more to visibility than simply logging and auditing as I will outline in my next post.
