Aporeto Logo
Aporeto Logo

You have been riding a bicycle for a few years and have become good at it.  You’ve learned to ride fast but, confined by technological limitations, you cannot go any faster.  Over time, you also have picked up the appropriate safety equipment that provide protection in case things go awry.  Then, because you innovate, you decide to put a motor on your bike to multiply your speed.  Seeing that you are still concerned about security, you retrofit your existing safety equipment into your new riding model.  It turns out that a bike helmet does not do very well on a motorcycle.

This is the state of the software industry today:  We are running faster but not safer.

Development teams are shifting away from monoliths, generated waterfall processes, and adopting microservice architectures in DevOps environments.  To be competitive, business bias is for feature velocity.  In most cases, security is an afterthought and an retrofit application of what used to work.

Although software shops are more “DevOpsy” these days, they still live with the notion of major release timelines.  Within that construct, security and development team leaders congregate and interface by traipsing down the columns of a spreadsheet with pro forma questions.  The security team asks whether certain procedures, processes, and practices were followed.  The development team answers affirmatively.  The method (hope) is this ex post facto exercise will reinforce the right de facto behavior next time around.  And so, with the next major release, the ritual repeats.

The security team has a job to do.  Through social engineering and by befriending key influencers in the development team, they do their best to get their mandate done.  On the flip side, most developers see security as a velocity and innovation inhibitor.  Despite the march towards DevOps, security and development teams are neatly compartmentalized and live in separate silos.

To date, there are two classes of solutions whose goal is to break down organizational silos and automate security.  The first solution class, Runtime Application Self-Protection (RASP), is baked into specific software development platforms and has the ability to monitor application behavior from within and guard against untoward behavior.  Unfortunately, RASP requires that developers use specific environments and change their processes by adding particular libraries to the compilation.  In other words, RASP introduces quite a few restrictions and friction where the developer rubber meets the innovation road.  It looks good on paper but it does little to inspire engineering armies to fight a better fight.

The second solution class – let’s call it Transparent Security – is in use by the likes of Google and Facebook.  [To get an idea of Google’s impressive machine, watch this talk staring 26:30.]  Because these giants control their entire HW and SW stack and have plenty of cash, they have the ability and luxury of providing security monitoring across all environments to ensure appropriate software behavior.  And although this may not be evident by studying their markitechture diagrams, the real key innovation in Google and Facebook’s infrastructure is an organizational one:  They have merged engineering and security teams.  In a nutshell, these companies have fused security directly into engineering processes by submerging it in their infrastructure and making it transparent.  Google and Facebook are running faster, and they are running safer.

Running Safer:  Distributed Security for Distributed Applications

Google and Facebook’s approach to security are the hallmark of engineering and organizational excellence.  They deliver an invisibly pervasive security infrastructure to development teams in a manner that does not inhibit innovation or feature velocity.  The story is quite different for the rest of the software industry.  With DevOps and microservices gaining momentum, we have essentially built theDavid Henry Thoreau castle in the speed and agility cloud that beckons a security foundation.

Building this foundation requires resolving a problem:  Having access to the same security-engineering infrastructure as industry leaders without access to endless piles of cash, custom-made infrastructure, and enormous engineering depth.  This is where Aporeto and Trust-Centric Security come in.

We have a lot to share, but we did not want to make this post about us. Keep reading. More to come.

Recent Posts Key Security Concerns for a Kubernetes Deployment How We Prevented the Kubernetes API-Server Vulnerability Security Groups and their Pitfalls

Subscribe to Our Blog

x