Application Dictionary

I struggled to name this blog, as I have long considered the end state an “Application Dictionary”–which would describe your applications and how they connect to each other. However, the intention of the Application Dictionary is to reasonably maintain your security posture with a proper Source of Truth (SoT).

The Problem Space

At NTC, we frequently get questions about how best to manage firewall policies from our customers. With the introduction of micro segmentation and zero-trust security models, the problem is only being exacerbated. Like many issues within the network automation space, the underlying cause usually has to do with SoT. Outside of SoT, other issues we’ve seen include:

• Users who request access want to do so in terms of function, not low-level IP and protocol.
• The application owners generally do not know how their applications communicate over the network.
  • The application owners do not feel any ownership in defining their application or taking responsibility for the associated rules.
• Rule ownership is not strictly defined, generally falling on the security engineer’s shoulders.
• Firewall rule objects (IP address and service) are difficult to manage.
  • As an example, when an object is modified, does that adjust the ownership of the rules that pertain to those objects?
• The firewall rule implementer is expected to reverse engineer all of the above.
• Rules are generally traceable from a transaction perspective, but nearly impossible to have a holistic view of.
• Duplication of rules across multiple firewalls or security controls since there is a lack of trust for edge control.
• An increasing amount of non-traditional firewall control points.
  • With hypervisor and container hosts controlling access, firewall rules are either duplicates or do not provide the level of control expected.

These issues can ultimately lead to an unfavorable experience overall. The requestor feels that their application should “just work”,the engineer fielding the request wished the requester understood their requests better, and the approver is attempting to ensure security integrity. Ultimately, everyone feels as if the other side “should do more.”

The Complications

With modern applications, there is no longer the concept of just servers, virtual machines, and L3 separation. Containers and hypervisor separation now blur the lines of security control. What was traditionally handled by systems communicating over the wire via IP can now be controlled by container or hypervisor network and security constructs.

However, in moving in this direction, the centralized control and visibility that once lived in the firewall is lost–when the network or security team does not have access to the container security controls, as an example. In practice, these rules end up getting duplicated due to that lack of visibility, by also creating the rules on firewalls as well.

A non-exhaustive list of complications includes:

• Identity based access, rather than traditional IP space access.
• Network Address Translation (NAT) and Virtual IPs (VIPs) can make it difficult to track systems’ actual IP vs network requests.
• SaaS based systems completely remove IP based considerations from the picture, as systems are generally offered off-premise.
• Container security is often the best (or the only) method to handle by container orchestration systems, since container to container systems are unlikely to traverse a firewall.
• Hypervisors now have the ability to enforce security, including layer 2 enforcement.
• Firewalld and IP tables provide access control on edge servers.

The Proposal

I am proposing to introduce what I have dubbed the “Application Dictionary.” This method allows users to speak, such as “I need SNMP monitoring” or “I need my application server to speak to my database,” while also understanding that all of the onus is not on the network/security engineer. There needs to be shared ownership and responsibility overall. That means that requestors, implementors, and approvers all need to have skin in the game.

The basic premise is “everything is an application.” Access between systems is assigned an owner and rules are pushed to the edge. So how does that manifest itself as security controls? Creating a disaggregation from the SoT and the configuration management gives you the ability to express your configurations as near natural language.

If application owners can define their applications as services that they expose, the application owners can also request for services that they to other services. While I of course can appreciate that not all application owners understand how their applications operate over the network, helping application owners define their application via a white-glove service without taking rule ownership is several steps in the right direction.

Ok, there is a lot going on here, in the interest of breaking it down to more consumable areas:

• Applications are defined by the services that they expose, such as an SQL port.
• Applications can define their access by subscribing to other services.
• There is likely always a review process for any service subscription. However, application owners may or may not be in that approval chain.
  • As an example, the owner of LDAP or Splunk likely does not want to approve every request to their service.
• As application owners add to their application, there are likely two types of requests.
  • Requests of expansion, such as adding another server to the cluster, configured the same way, which would require less scrutiny.
  • Requests of new services that would be more akin to new application requests.
• An automated process would generate configurations for the resulting services.
  • This configuration management aspect is essentially a build artifact from the SoT and specific programmatic methods implemented.
  • Policy creation of rules does not have to only apply to firewalls. For example, policies can apply to containers orchestration systems or AWS security groups.

Note: Those familiar with Cisco ACI will notice the similarities in terms of naming, such as Application Profiles and Contracts vs Application Services and Application Requests. This is by design, as both solutions are intending to solve similar problems, but the Application Dictionary is only about storing data, regardless of whether or not the traffic is controlled by a networking device or not, such as the case with containers and IP Tables.

To help describe what this system may look like here are two basic wire frames.

To illustrate these two pieces coming together:

In this simplified example, rule definition and policy creation only follow traditional firewall IP protocol communication patterns. However, this can naturally be expanded upon for many more use cases.

Building a Data Model

Building such a data model is no easy feat and depends heavily on your environment. Take the following questions an organization would likely have to ask itself before embarking on such a journey:

• Should locality be considered in application assignments or does that require too much management?
• How does the system differentiate between applications that are secured by a firewall, IP tables, or container orchestration?
  • For each one of these components, you likely need a different driver and translation engine to the security appliance.
• How does the system provide proper RBAC and security workflow approval controls for various use cases?
• How does the system reconcile when the actual state differs from the intended state?
  • The actual configuration will become less important and harder to understand from a troubleshooting perspective.
• How is the “application owner” defined for users?
  • Does identity based on authentication mechanisms replace subnet space?

Updated Links

Since this blog was created, the following demonstrations, presentations, and podcast have been created on the topic.

• Nanog 83 Video Next-Gen Firewall Automation
• Application Dictionary with Nautobot A demonstration of an implementation of Applicatino Dictionary within Nautobot
• Heavy Networking 573: Using Application Dictionaries For Better Security Policy Management.
• Heavy Networking 564: Seven Engineers At The Community Roundtable (Timestamp 16:10-37:00)
• Network Automation Nerds #024: Application Dictionary in Network Automation with Ken Celenza