Black Cloud, how the internet is going dark

The number of open listening ports on the internet is around 185 million (  This means there is plenty of opportunity to exploit these open services, as it is now possible to scan the entire internet in under 1 hour for a particular port (service) (  Can we somehow hide open ports (services) on the internet or in the enterprise?  Is there a method of making them invisible?  Well this idea has been around for a while, a method called Port Knocking ( has been around since the early 2000, and there is even a new IETF Internet Draft from 2015 called TCP Stealth ( that has a similar concept.  All these concepts have the same effect, making your services on the internet or in the enterprise invisible and only accessible by authorized devices or users.

Today the idea of making the Internet, or Corporate Network, dark has gained momentum since the introduction of Software Defined Network (SDN).  This has enabled the new concept Software Defined Perimeter (SDP) or what you might call Black Cloud.  This concept is slightly different to port knocking, it makes your services invisible and you need to be authorized.  The difference with SDP is you can not send a secret combination of packets to open the port on the host, you need to have trust with the controller.  The controller will allow for a mutual TLS (mTLS) session between the Initiating Host (IH) and the Accepting Host (AH).  This concept does not require any listening ports on the AH, more importantly the AH will not accept any connections unless authorized by the SDP controller.

The SDP controller is using Single Packet Authorization (SPA) which is an variant of port knocking.  This concept creates a authorization network fabric where you can define which connections are allowed, so think of this as a perimeter that is everywhere that fits nicely into the zero trust model.  You can define by policy which hosts can talk to which hosts and on what ports.

This diagram below explains the process for SDP, the concept is from Cloud Security Alliance (CSA) working group (

The security model below can also be used where you have SDP gateways, these could be placed into network segments on premise or in the cloud, this way you can control all traffic to hosts in the segment.

This security model makes a lot of sense, why should we open services and allow anyone to do a threeway handshake if this services should only be accessible by a group of users and devices.  The solution greatly reduces the attack surface, you do not have any open ports, therefore you can not DDOS the service, you can not even connect.

You can see below that ZScaler Private Access is based on a similar security concept but goes a few steps further, basically the Zscaler Connector is the SDP gateway, the ZApp client is the Initiating host, and the Central Authority is the SDP Controller.  The Broker (ZEN) is an additional component that removed the need for incoming connections to the data center or cloud network segment.  An extra layer of Mutual TLS is added between the Client and Connector to provide an extra layer of encryption and trust.

Basically you could think of SDP as a network fabric where you control traffic flows based on policy.  This concept even extends into the data center, which is used by Cisco ACI, where contracts between End Point Group (EPGs) is required to enable network connectivity.

I think this concept of creating your own Darknet (Black Cloud) where you can control and monitor network connections is the future. This will enable companies to create their own virtualized secure network fabric (Black Cloud) where they are in control. Furthermore this will enable enterprises to embrace cloud, and stay in control.

Black Cloud is the new Black

Application Delivery Controllers the Swiss Army Knife

The Application Delivery Controller continues to increase market share in the enterprise networking space, but I’m not sure everyone understands the value of this device, and why this network component has become an important part of the enterprise.


The most common task of an ADC is load balancing, and not that long ago most of these devices were called load balancers, but these devices evolved into ADC’s.  I’ve always tried to correct people when they call the Netscaler a Load Balancer, because this doesn’t do it justice, the Netscaler is like my swiss army knife, where it has many functions and I can solve many architecture challenges.

The fundamental different between ADC’s and other network devices like firewalls/routers and switches is the ADC is a proxy, and therefore terminates TCP and UDP connections, and creates new connections between the proxy and resource.  It is this fundamental difference that gives the device so much power

and flexibility over other network devices that are generally just routing or switching packets.

Here is a list of feature that most ADC’s will have

  • Load Balancing
  • SSL Offloading
  • Caching/Compression
  • TCP Multiplexing
  • Authentication
  • Authorization
  • Auditing
  • Routing
  • Switching
  • Content Switching
  • Application Firewall
  • DNS
  • Global Server Load Balancing
  • Many HTTP features

As HTTP has become the protocol of choice for some many applications today, the ADC’s has become the master of controlling, manipulating and transforming the HTTP protocol.

The placement of the ADC is commonly placed between the user’s and the server’s, so it is common to have this device in the data center network to control application delivery.  It is also common to have this device in the DMZ to be used as a reverse proxy between the internet and data center network.  It is also becoming popular to use the ADC in the data center network between internally data center services, for example front end web server’s and the database.

I believe the ADC will become an essential component in the enterprise.  Software Defined Network (SDN) will enable these devices to be easily architectured into the network, especially with the emerging technologies like Network Services Header (NSH) that will enable service chaining.


End of an Era for VPN?

The legacy method of granting users access to applications in the enterprise is to extend the network perimeter to the client. This is achieved by routing the traffic between the client and the network edge in one secure tunnel. This approach poses a security risk as the user usually has full access to all network resources and applications.

The next problem with legacy VPNs is that it is based on Layer 3. This means your security policies are based on IP information, for example Access Control Lists (ACLs). ACLs are hard to manage and are not application centric.

Zscaler Private Access could disrupt the Virtual Private Network (VPN) market with a new approach on how to connect users to applications securely.  Zscaler Private Access (ZPA) is cloud service that can securely connect users to applications without extending the network perimeter and without routing.  The Zscaler Application (ZApp) client securely presents applications to the client, therefore removing the network complexities and security risk from legacy VPN technologies.

ZScaler has an interesting approach, they have moved the security model up the network stack from ISO Layer 3 to 7 and based the entire system on Domain Name Systems (DNS) instead of Internet Protocol (IP). This is more application centric approach and solved many challenges we have at Layer 3, like routing, IP overlap, Network Address Translation (NAT), 4to6 NAT, IP4 Scalability.  All these network headaches disappear and now I can control application access.

The granular application policy is also based on DNS, this policy can be dynamically applied to the end user.  This idea follows the Zero Trust Model, where you only grant user access to applications and systems they require and not to your entire network.  There is also a method of using wildcard domains if you don’t want follow the this model.

ZPA is using federation via Security Assertion Markup Language (SAML), so easy to integrate with your external IDP or internal Microsoft ADFS.  The SAML claims define the user application access policy, the claims are linked to an application name that consist of the domain name and port number in the simplest form.

Without going into a deep dive on how this is working, you could say this is more like a Proxy VPN based on an Software Defined Network (SDN) in the cloud, every TCP session and UDP stream is proxied multiple times. The ZScaler cloud will always find the best path to the application and dynamically create a one hop encrypted tunnel for each application, so you could call this Software Defined Security (SDS).

I believe this application centric technology will improve security, flexibility, scalability and most important simplify the complex legacy VPN solutions we often see in the enterprise.

I am looking forward to how this disruptive technology will change the current IT landscape, and how enterprises will start solving security challenges, like Internet of Things (IoT), company mergers, contractor access, and securing the end user device.