To accomplish application-layer security, application switches need to be able to process not just Layer 2 and Layer 3 packets at wire speed. They also need to sustain a similar type of processing performance while handling the more complex task of opening up a packet and inspecting the packet payload.
To enable application-layer security with an application switch, it must first be configured with a predefined set of security rules. These rules can be as simple as a Layer 2-4 access list or as complex as denying Layer 7 patterns that are embedded inside the payload. Once packets (either legitimate or attacks) enter the switch, the switch inspects each packet by comparing the security rules to the content of the packet. To increase the performance of the inspection, complex security rules can be defined with an offset value so that the switch inspection engine can go directly to the location in the packet to be inspected.
Often, a virus pattern is a combination of multiple patterns within the payload. Therefore, the application switch must be flexible enough to be configured to inspect multiple compound patterns located at different offsets within the payload. When the attack pattern is matched, the application switch drops this packet and creates a session table entry in the switch. This means that subsequent packets of the same session (e.g., TCP) will be dropped without going through any additional inspection. Creating the illegitimate application session table entry enables the application switch to accelerate the denial of subsequent packets in the session by inspecting the session table without the need to perform the initial complex security rule check.
This same application-layer security inspection capability enables an application switch to provide rate limiting of complex protocols such as those used in peer-to-peer (P2P) applications. KaZaA, Edonkey, and Gnutella are examples of popular P2P file sharing applications, which leverage protocols that use dynamic ports to enable client-to-client communication. Many enterprises want to limit the use of P2P applications because they can be significant bandwidth hogs and are often used to illegally transfer copyrighted files (music, movies, etc.). Standard firewalls are not able to detect these P2P applications because their unique protocol signature does not appear at the Layer 4 port level. Many of these protocols have signatures that are embedded in the HTTP header or, in some cases, embedded in the data payload itself.
Ultimately, an application switch can help standard firewalls detect P2P protocol patterns and restrict the traffic. Alternatively, the switch can act as a bandwidth management device that identifies P2P traffic and provides rate limiting and shaping functionality to control the amount of the total traffic generated by these applications. This is especially useful in cable, ISP, and university networks, where P2P traffic can account for as much as 70 percent of total network traffic.
To realize the benefits of cloud-native software, an application must actually be cloud-native—designed to run in the cloud, interacting with disaggregated cloud services, fully manageable as code—to deliver the expected benefits.
By combining resources and expertise, the AI-Enabled ICT Workforce Consortium will offer a blueprint for how industries can adapt to an AI-dominated future.
IT leaders should heed the guidance of cybersecurity insurance providers who think businesses should prioritize security education, incident preparedness, regular internal audits, and ongoing vulnerability scanning and patching.
