It's that time of year again when all security professionals converge in San Francisco for the RSA Conference (RSAC). This marks the second year that the conference has been back in full swing since the pandemic, and it was great to be there to discuss our solution with the attendees!

This year, RSAC attendees were transported to the Forward Networks Roadhouse. This is a place of solitude to share your network security concerns with one of our “bartenders.” As the attendees walked past the booth, there were two general impressions. First and foremost, “This is the best booth I have ever seen,” which was quickly followed by, “That is one sweet bike! Is there a raffle for it?” At this point, after we broke the news that, unfortunately, the bike was not for sale, the woeful attendee walked up to the bar and sat down. Our bartenders offered a refreshing cold brew (coffee) and a helpful ear as they explained their network security woes.

Fear not; those woes did not go on deaf ears, as our knowledgeable bartenders acknowledged all their security and network woes and showed how Forward Networks' mathematically correct digital twin was precisely the tool they needed to end their concerns! The attendees saw that by using Forward Enterprise, they would be able to sleep at night, knowing that the next time their cloud security posture was audited, it would be following the corporate security standards. They also learned that they no longer needed to fear undetected critical vulnerabilities, as Forward Enterprise uses their network data alongside the NIST database to to deliver a prioritized remediation plan, including what devices are affected by them and the lines of configuration that cause that vulnerability.

The biggest takeaway from presentations at RSAC is the industry's rapid adoption of Artificial Intelligence (AI) and Machine Learning (ML). Now, the ease of access to Large Language Models (LLMs), such as ChatGPT, enables the infrastructure to become more adaptable, self-healing, and open to more automated ways to make configuration changes. Operations teams are turning to AI-based diagnostics for troubleshooting and issue remediation. Seeing these technologies being more broadly spoken about and adopted in several ways further solidifies their place in the industry.

If automated changes happen in the environment, the question arises: How can you ensure that the change will not negatively affect the network? LLMs are constantly learning, and how can you ensure that the change you ask the system to perform will not cause any undesired changes in the network? Forward Networks' Verify function can ensure that the intent of how the network behaves is exactly as it should be behaving. Forward Networks Verify will look at any checks defined to ensure the intent of the network is correct and that nothing has changed that could cause an adverse condition in the environment. This is not only compared and validated with the organization's on-prem network but with the cloud and virtual overlay networks as well.

If you were not able to visit the Forward Networks Roadhouse at RSAC this year and would like to learn more about how a digital twin can help with your organization's security posture, request a demo with our technical team!

A new feature in Forward Enterprise now allows customers to simplify the analysis of network access issues between the network and security teams. We call this feature ACL-less analysis, or permit-all mode. First some context why multiple customers asked us to develop this feature, and the use case benefits they are seeing.

Forward Enterprise allows customers to quickly drill down into network and security configuration issues to isolate and expose the root cause of policy violations and deviations from intended network behavior. For example, why is this destination unreachable? Why is server access from the WAN impeded? What is blocking traffic between two sites or subnets? Forward Enterprise allows you to compare end-to-end path behavior with desired policies rather than focusing on individual device configurations and box-by-box analysis the old-fashioned way. Overall, this greatly accelerates Mean-Time-To-Repair (MTTR) and increases operational efficiency for IT teams.

When dealing with uncertain root-cause across large networks, many organizations are challenged to bridge the silos between network and security teams. It’s only natural. Visibility to both policies and implementations between two large technical organizations is rarely complete. It’s easy to start with a reasonable amount of finger-pointing. And when dealing with a connectivity or accessibility issues, sometimes it’s the network devices and topology, and sometimes it’s an unintended consequence of a security policy or access control issue.

When Forward Networks started putting our next-generation analytical tools and troubleshooting insights into the hands of large enterprise organizations, we uncovered some of these Layer 8 (political) problems ourselves. Several of our customers that have distinct network and security policy teams subsequently asked us to provide capability in our system to separate root-cause analysis between networking configuration and Access Control List (ACL) rules.

The motivation was at least two-fold: 1) It provides an immediate way of isolating any access or connectivity issues to network devices or security rules, and 2) It clearly indicates which team should be addressing the problem and further refines where remediation should best be applied. This usually decreases the MTTI (Mean Time to Innocence) for the networking team as well as avoiding tedious work and delays trying to definitively prove the lack of existence of some uncertain error.

How does this work in practice? Starting with the Verify view in Forward Enterprise, where a user has defined a set of policies to validate, we see a single failed policy check for the existence of at least one path between two IP addresses in different data centers, through a specific firewall, with traffic delivered between the sites via an MPLS backbone.

Clicking on the “failed” link allows the user to explore the configuration issues associated with this policy failure. This brings up a new view as depicted in Figure 2. The failing policy statement is displayed in the top search bar, which we can refine or broaden to help analyze the situation further.

The result of a Forward Enterprise query statement is always the full set of network paths that meet the requirements of the query or search. In this case, as expected, we see “No results found”, because no such path exists. All traffic is being dropped in this scenario between the two IP addresses 10.117.170.01 and 10.110.57.34. And no paths are highlighted in our topology diagram, only the individual devices included in the query.

At this point we don’t know if this is a network connectivity error, or security policy issue. The new permit-all mode in Forward Enterprise allows users to determine this immediately. By clicking on “permit-all mode”, the platform runs the same analytical query bypassing all the ACL rules, to see if there is network reachability and if traffic would flow in the absence of any security enforcement.

For those not familiar with Forward Enterprise, our platform is based on a behaviorally-accurate software model of your live network. These types of hypothetical analysis are very easy in our system, and never impact the live network where you can’t turn-off security enforcement just for the sake of analysis and testing. Checking the expected behavior of future traffic under any hypothetical change or scenario is one of many ways we aid in the analysis and troubleshooting of network and security issues.

In Figure 3, we see the top search updated with permit all, and now we are seeing that, indeed that are many (128) possible paths between these systems, due to the several pairs of redundant devices at most hops in the network. We are highlighting one path through the network, and focusing on an initial access layer switch that enforces ACLs.

We have highlighted in the hop details how the deny here, which is being applied to all packets, is being ignored, and the policy violation is not a network connectivity configuration issue after all. At this point, we can refer the ticket to the security team or administrator responsible for this particular device for further analysis or remediation. A key policy alert was detected, isolated and handed off to the responsible team in only a few clicks.

Another ACL-less scenario would be an application team wanting to know if the current network configuration supported access to a requested server. The current security policy would likely not support this policy a priori, but a key first step would be to know what network connectivity would allow in the absence of security rules. ACL-less analysis ignores the firewalls and ACL rules and can either confirm or deny network support for the application team request. This scenario is detailed in the YouTube video below.

This new capability, referred to as ACL-less or permit all mode, is having increasing interest across our entire user base that have separate security and network teams. We are interested to learn how it might help your organization and your IT processes in dealing with trouble tickets and how it may help overcome any Layer 8 problems you may have.

For more information, check out our YouTube video or get a live demo of ACL-less mode and the rest of the features in Forward Enterprise.

Top cross