IDG Contributor Network: Finding and protecting the crown jewels
Visibility and security controls for internet-based applications such as social media, file sharing and email have been widely adopted at the perimeter. As we transition from the legacy perimeter security model to a cloud security model, there is a need to ensure we don’t forget the principles we have established.
Virtualization has changed how applications are built, deployed and used. It has also created challenges to how security is applied and deployed for these environments. That isn’t necessarily a bad thing; the result of these challenges has driven new innovation in the cloud security space.
+ Also on Network World: The tricky, personal politics of cloud security +
Discovering and mapping application communications and dependencies is one of the first steps in defining and creating security policies for east-west data center traffic. Unfortunately, there is often a lack of understanding about these relationships, making east-west security policies difficult to implement and often prone to misconfiguration. As a result, we still see an abundance of successful attacks and the loss of critical data, even with traditional perimeter security models in place.
Layer 7 visibility and enforcement for the cloud
Layer 7 information provides context about applications, and that context improves the accuracy of the security controls that can be applied. This information is the first step in being able to define security policies that can prevent attacks (such as protocol hijacking or exfiltration) in complex enterprise environments.
Service-oriented architectures (SOA) offer the flexibility needed to deliver business value and meet the strategic goals for large enterprise organizations. These web services are often composed of multiple components, and they leverage communication protocols that operate on non-standard ports. In most examples, it is impossible to accurately discern these services using Layer 4 information alone.
Databases represent one of the most critical information assets for most organizations and often house what can be considered the crown jewels for the business. They are often bound by strict security policies and controls. In many organizations, databases provide shared access and are required to support database multi-tenancy. As a result, databases are typically bound to non-standard TCP ports, making it difficult to discover, monitor and implement controls without a lot of time-consuming manual investigation.
Layer 7 context is required for the discovery and identification of these web services, databases and other critical functions such as message queues. Having this information significantly streamlines the policy planning lifecycle.
Being able to fingerprint applications and dynamic protocols such as SOAP and RPC (DCERPC, MSRPC) through application ID is critical to deploying and enforcing security policy. The use of Layer 5-7 discovery and matching allows a combination of protocol and payload to be used for defining policy. Using the database as an example, this would include TCP 1433 and MySQL.
Being able to discover and match this traffic also allows for the possibility to configure full Layer 7 logging where you could specifically log all MySQL transactions leveraging the Layer 5 information gleaned. This is applicable for dynamic applications and services that not only use non-standard ports but for those that can be configured to use a wide range of dynamic ports. This ability to discover and match on Layer 5-7 provides the flexibility needed to properly secure these dynamic architectures and protocols.
Multi-stage DNS man-in-the-middle attack
This visibility is critical for detecting protocol and payload anomalies and in identifying threats and exploits. Some recent examples in the wild include:
- Detecting rogue DNS services
- Vulnerability detection (e.g., glibc)
- Enforcing and providing audit support for compliance-bound applications
- Identifying restricted protocols (i.e. Telnet)
- Discovering web application and database threats hiding on standard ports
- Verifying connections and messages to SWIFT (Society for Worldwide Interbank Financial Telecommunication)
It is not enough to just detect, you must also be able to take action. If you detect an application anomaly but can only enforce for on a Layer 4 port, you are not successfully protecting your applications. You must be able to prevent threat actors from moving laterally and burrowing themselves deeper within the network. Leveraging Layer 7 visibility to provide proper segmentation of assets is a strong first step.
The next step is being able to verify connection attempts through stateful inspection, which then allows you to then move up the stack to support session and application security. This provides strong support for ongoing security management and the availability and protection of business-critical applications and services.
Protecting critical assets with Layer 7 visibility, segmentation application-ID matching and enforcement
Virtualization technologies and cloud services are driving changes in security. We can no longer rely on traditional perimeter security at the Internet Edge or in the DMZ to provide protection in these environments. The workload has become the new perimeter, and protecting the critical applications and data housed on these workloads is paramount.
A flexible and scalable security solution applied around the workload is needed to successfully identify east-west application services and traffic and protect against lateral threats. The ability to view and enforce on all layers of communication is key in delivering a successful security model for these service-oriented environments.
This article is published as part of the IDG Contributor Network. Want to Join?