VMware AppDefense has automatic responses using vSphere and VMware NSX, including the ability to block process communication, alert, suspend, shut down the endpoint, and snapshot an endpoint for forensic analysis. These remediation actions can be enforced automatically or manually as well. With AppDefense it is possible to leverage NSX distributed firewall rules based on the discovered behavior. Any Quarantine action set for a service uses NSX distributed firewall to isolate the VM on the network. Also these remediation actions are set at individual service level within the application scopes.

NSX integration with AppDefense avoids the process of manually retrieving Application Dependency Mappings for each application in the datacenter, as it gives greater visibility into every protected VM in the datacenter including the processes running within the OS and also all the in/out bound connections that are made by each process.

If an attacker tries to start a new process, which deviates from the “known good” behavior, AppDefense can block all of the in/out-bound connection requests made by that process (within the virtual machines). This means that AppDefense not only offers security at the network level but also provides security at the process level (within the virtual machine) and checks the OS Kernel integrity as well.


How is NSX manager integrated with AppDefense?


As part of the AppDefense appliance registration process, customers are required to register it to vCenter. Once this occurs, the appliance will automatically sync to the NSX manager on vCenter. The customer only needs to enter their admin login credentials to finalize integration with NSX.



AppDefense registration in NSX Manager



Once NSX manager is registered with the AppDefense appliance it automatically creates a few objects in the NSX manager, including:

  • NSX Security tag – AppDefense.AnomalyFound
  • Security Group – AppDefense Quarantine Group
  • Security Policy – AppDefense Quarantine Policy
  • Firewall Rules – To block all In/Out bound traffic from the VM which is quarantined via security policy

These objects are used to perform the remediation actions discussed above.



AppDefense quarantine policy



How are remediation actions configured to use NSX?


Within AppDefense manager customers have the ability to set the remediation action at the individual service level within the scopes created. This allows the security team to set the remediation actions at a more granular level for each service within an application running in datacenter. Customers can enforce remediation action for all in/out-bound connections, Guest OS integrity, AppDefense module integrity. Currently Linux OS only support in/out-bound connection remediation actions.



Configuring remediation actions in AppDefense



What happens when remediation action is triggered?


Whenever AppDefense notices a new behavior post moving the scope into protected state it triggers the action which is configured for the service where the VM is member. As part of remediation action, an NSX security tag is assigned to the VM and an AppDefense Quarantine policy gets applied to the VM to block all of the in/out-bound connections from the VM hence, isolating it.



Isolating bad connections with AppDefense





AppDefense empowers customers by transitioning from a reactive to a preventative security posture. Leveraging AppDefense with NSX provides customers with assurance about their security for example, knowing the processes needed for applications and how they communicate over the network. Also, the known good state of an application. And if there is an anomaly, we can inform users about what is changing, research the changes, and be very proactive so that the app owner can see the security footprint of the app at any time. The close tie to NSX is key to understanding the known good state of an application and taking remediation actions in case of any deviation from their known-good state.


To learn more about VMware’s Enterprise Security Solutions visit: https://www.vmware.com/security.html