Greater distribution = more complexity

We use an array of systems to gather and analyze data related to our operations, security, app performance and system health.  This type of visibility is critical in enabling us to run our businesses.  Unfortunately, the collection of this data has become increasingly expensive, insecure and complex.  So we end up in a catch-22 type situation: we need to collect the data to run our businesses, but collecting the data hurts our businesses.

Bolted-on wasn’t designed for distributed, dynamic application topologies

Our current bolted-on architectures were based on a much more centralized and static app topology:

Problem #1 leaps off the page: open inbound firewall ports.  In more centralized and static architectures, we tried to compensate for the inherent insecurity of open ports by bolting on VPN, MPLS, IPS/IDS, ACLs, more monitoring systems, etc.  And that leads to problem #2 – those bolted-on solutions are:

  1. Targets of cyberattackers (especially VPNs and open firewall ports)
  2. Are prohibitively complex and expensive at modern levels of app distribution
  3. Block our automation and agility goals.

Problem #1 and problem #2 are multiplied because there are many more VPNs and open firewall ports than shown in the simplified diagram above:

  • Multiple connections from the WAN to collection points.
  • There is often a layer between initial collection and ultimate datastores.
  • Multiple systems – e.g. APM systems, SIEM, ops systems.
  • An MSSP who is managing solutions (e.g. Splunk, Dynatrace, Informatica, Datadog) for (n) enterprises multiplies the pain and security risk by at least (n) connections.

We can try to ‘patch’ the problem, e.g. add more bolted-on solutions, and that is often necessary.  But the only sustainable (architecturally and economically) solution is to change our approach – to move to a framework which is designed to solve the challenges of our modern distributed, dynamic architectures.

Built-in: security goes everywhere your apps go, as software

Build-in architectures are optimized for modern, distributed application topologies, meeting our automation and agility goals (DevOps, SecOps, NetOps), while providing the strongest security via software instead of infrastructure.

This is often labeled as Security as Code and is part of a Shift Left movement which enables better security and automation by designing security into the development and delivery lifecycle.  Here’s how the NetFoundry Security as Code implementation closes inbound firewall ports and eliminates VPN/MPLS:

This architecture:

#1: Closes the inbound firewall ports.  This secure by design architecture both drastically improves security and removes the need to invest in adding bolted-on solutions like complex firewall rules and ACLs, IPS/IDS, VPN, etc.

#2: Improves automation and agility.  Everything you see in the diagram above is cloud orchestrated code, managed by your DevOps tools, APIs or web console.  You can literally spin it up in minutes!

#3: Enables flexibility.  NetFoundry open sourced the underlying software (Ziti).  Or you can choose to NetFoundry’s turnkey, consumption-based SaaS (free forever for up to 10 endpoints).

#4: Enables simple scale and extensibility.  Adding a new datastore, site or cloud takes minutes.  Use high bandwidth, low cost Internet ports rather than low bandwidth, high cost MPLS ports.  Control it all from the cloud, as code.

This is not just for cloud native companies or innovative startups.  The NetFoundry platform is used by the world’s largest companies such as Microsoft (Zero Trust, Azure Private MEC) and Oracle (Autonomous database, Kubernetes APIs).

How do businesses implement Security as Code?

There are two main options to choose from:

There are many options within both the SaaS and open source models, including:

  • Agentless (embedded in the application, as code, rather than a complex/insecure DNS redirect)
  • ZDBC driver (a Zero Trust wrapper around the existing JDBC drivers; again resulting in an agentless type approach for cases in which JDBC is used)
  • App-specific agents (VM, container, Win, Mac, Linux, Android, iOS).  One key here is that the agents enforce policy, e.g. they can send web apps to a SWG or Internet gateway, while optimizing the specific application of the solution provider.
  • Cloud-specific agents (available in every cloud marketplace).

Useful links

Most of us in the security, tech and networking worlds are cynics, and for good reason.  Meanwhile, the marketeers have flocked to use and abuse the Zero Trust terms.  So here are links to enable you to quickly filter through the noise and judge for yourself if you want to learn a bit more before diving into the SaaS or open source:

Watch a DevOps SRE leverage NetFoundry to do simple, Zero Trust data collection in 10 minutes (video)

Download a whitepaper for details and customer case studies.

See how NetFoundry’s Zero Trust aligns with NIST Special Publication 800-207

Schedule a briefing or demo with a product expert

Discuss On: