5 min read
Security is accountable, but it’s frustrating (and impossible) to do your job without visibility into cloud native development.
- Outdated approaches are to blame. Security thought they had the authority to push their solutions onto developers.
- Developers have all the authority. And they don’t want “yet another damn application” (YADA).
- For security to work (and survive), it must become developer first. Today we can do that using Kubernetes.
Read this blog, but it's not all talk, we're offering a way to get visibility of your clusters
A Dangerous Diagnosis
Just after publishing my first book, I became aware of what I call “cloud native blindness.” The “green book,” used as curriculum for the Department of Defense CISO program, The Society of Actuaries Exam prep, and numerous universities – gives security leaders easy-to-use predictive analytics tools. In short order, my CISO friends started asking for more. This snowballed into “speed consulting” with dozens of enterprises around the globe. It gave me a critical view into the global state of security, and it opened my eyes to some problems brewing.
My engagements included a litany of diagnostic questions, like:
- Do you have visibility into major software releases and infrastructure updates?
- Do you track service ownership and privilege changes?
- Are you measuring critical exposure rates and Time To Live of those exposures?
The answers were usually some form of “no,” “not nearly enough,” “we’re not there yet,” or most concerning, “we don’t see that as a problem.” The gaps were most pronounced in companies engaged in cloud native development. That’s development with autonomous teams, rapid software releases, and microservices-based architectures using Kubernetes or some other form of orchestration to manage.
We’ve seen Kubernetes emerge as the leading orchestrator because it takes companies from delivering software products to delivering software services that are continuously available, and constantly updated – essential cloud native development.
For those of you new to the cloud native world and unsure of its prevalence, Kubernetes is its poster-child. Nearly 80% of companies have deployed Kubernetes in production, and 70% of the Fortune100 use it as their main container orchestration tool.
Bottom line, it’s coming your way and has likely already landed in your organization with its usage growing rapidly.
My engagements showed that cloud native CISOs were reluctantly (or unconsciously) resigning themselves to blindness. What may have worked in the cloud or data center wasn’t translating over to cloud native development. Unbeknownst to them, they were leaving the part of their business that created the most exposure at the highest velocities unchecked.
I wondered why this was happening. Perhaps most importantly, I wondered how this could be solved.
An Industry and Its Leaders Left Behind
Having been a CISO before and after the digital transformation, I believe the cloud native train left the station without security. Our industry, particularly from a vendor perspective, is still mired in datacenter/IT-based approaches. This includes how we create solutions, how they are sold, and how they are deployed.
These outdated approaches would have worked in the old days, where we had centralized control when it came to acquiring, deploying and maintaining security software. It worked on homogeneous computing environments with slow rates of change. But now, those approaches present a brittle view of the world when compared to the fluidity and freedom that characterizes cloud native development.
The new world is predicated on distributed systems built by small autonomous teams that produce rapid software releases. This creates a huge problem for enterprise security vendors. They are looking for a single buyer with the authority to push their wares across a homogenous enterprise. Cloud native development is putting a nail in that coffin. The central authority and buyer is gone, and it has been replaced by the developer.
This leaves the cloud native CISO with two options. The first option is to hire a small army of highly skilled cloud native experts to cobble together and deploy open source security solutions. Good luck with that – I tried it – twice! You might think you’re saving money with free, open source solutions, and in-house talent to build it, but it’s very expensive, it takes a lot of time, and people with those skills are migratory. It doesn’t pay off. You’re often left with abandoned projects that never end.
The second option involves buying last generation’s enterprise solutions – even seemingly cloud native ones – and pushing them on developers. These are the solutions in categories that made sense for a datacenter approach – including vulnerability management, firewalls, threat management – but they do not work well in a dynamic, rapidly changing environment.
Invariably the anti-bodies of development, DevOps, and Site Reliability Engineering will reject these approaches because they are disruptive to their processes. They take months to acquire and deploy, they slow down developers, and they’re very expensive. Also, when weighing the seemingly intangible results of deploying security solutions against how quickly they can produce products, security may not win as the priority. In short, organizational friction slams the brakes on the enterprise security train before it leaves the station.
This is not the situation any CISO wants. You’re either slowing things down, or you can’t get solutions implemented. Code is shipped without the proper security measures to ensure that it’s secure, and you don’t have the information you need for regulatory compliance.
Toward a Cure
With my experience as a cloud native CISO, and having talked to other security leaders while doing my small consulting side-hustle, I gained a unique perspective of what does work.
In short, developer first approaches work! I observed how developers, DevOps and SREs acquired their solutions. There are patterns and principles at work in their decision making. They include:
- Access: SaaS and or Open Source
- Autonomy: Individual try and buy
- Annoyance: No sales people - no demos
- Cost: Low start up cost / pay for what you use
- Value: Immediacy of Satisfaction (time to value in minutes)
- Comfort: No fuss toolchain and pipeline integrations
Don’t just take my word for it. Observe what your development teams acquire and how they use it. For cloud native organizations with high release velocity, you will see the above patterns at work. And you will observe that security vendors, for the most part, do the exact opposite.
Fortunately, there is some good news emerging within the startup world. And it makes sense that it’s not coming from established enterprise security vendors. Established vendors have massive investments in enterprise software and sales. The sunk cost is overwhelming. Switching gears to a SaaS or open source strategy targeting developers would be unacceptable by the vendor’s shareholders.
The cure is to approach the cloud native market in the way front line developers expect and accept. We are attempting to do that at Soluble – one step at a time.
An Offer: The Cloud Native Digest
Nobody has time to login to YADA (Yet Another Damn Application) to learn what’s happened in their environment. They want something that meets them where they are and provides them with a meaningful summary of the important events that have occurred.
That is why we made the “Cloud Native Digest.” It’s all the interesting headlines from across your Kubernetes environments for the week. It includes things like new clusters, noteworthy configuration settings, and other sundry items you may want to look into. It has a very simple format:
- Delivered weekly, via email
- One click detail reports to drill into if you want
- Up and running within 30 seconds
Try it at no cost. If you get value, there’s more - lots more! Sound good?