In this Demo
  • Before we begin, this is the high level overview of the Application Security solution.
  • Let's get started Note: Click on the hotspots to clickthrough the guide.
  • A successful SQL injection attack can result in unauthorized access to sensitive data, such as passwords, credit card details, or personal user information. It is not that hard to pull it off if the attacker knows who and where to look. Here is a simplistic example of such an attack.
  • That could prove very costly! 90% of companies do not use WAF for its complexity. What if the complexity in using WAF were to disappear?
  • Keeping the SQLi scenario in mind, lets us now look at the WAF. First up is the Dashboard which easy and very intuitive. We notice all the applications in the tenant "admin" being listed here. It is important to note that NSX ALB provides WAF protection to every single application as desired. The first order of business is to ensure we are subscribed to the latest Bot and DDoS management updates. To do so, click on the Administration tab.
  • Click on the Cloud Services
  • Click on the Edit option
  • Click to enable the Cloud Services WAF management option
  • Enable to receive the CRS and WAF signatures updates
  • Let us now continue and dig a bit deeper into the WAF policies
  • The shield over the Virtual Service indicates it being protected by the WAF. Click on the Plus icon to view in more detail.
  • Here we notice the IP pool being load balanced along with the actual load balancer. For the purpose of this clickthrough demo, we will double click on the virtual service to take a closer look at the application and the WAF policies.
  • The application overview
  • Understanding the rejected transaction
  • Why did the request end abnormally
  • Pin pointing the reason for rejection
  • Moving on to the Security tab
  • The security overview dashboard
  • WAF analytics overview
  • Moving to the WAF policy editor
  • Click on the edit icon to view the virtual service details
  • Let us edit the WAF policy
  • Avi monitors over 700 application performance metrics, delivering insights into applications, end-users, and infrastructure, all in real-time. Avi optimizes the security pipeline in the following fashion Learning: Helps understand normal, expected, healthy traffic and behavior at a deeper level. Think of this as a child seat that is ok to go through with a parent or a guardian with a child. Allowlist: In the TSA screening analogy these are the pilots, cabin staff and pre-screened passengers Positive security: This is akin to regular TSA screening procedures. Anyone not on the Allow List heads to the regular screening line and follows standard security procedures. Application rules: What behavior is ok and what is not. For example, carrying a big bottle of soda is not acceptable and hence deposited in the trash can. Signatures: This is the pat down and individual screening at the airport. Takes a lot of time but is necessary and can often hold the line.
  • The learning capability of NSX ALB positive security engine protects applications against not only known threats, but also against new, malicious behavior hackers engage in as they attempt to breach the system. The best way to defend the application is to understand normal, expected, healthy traffic and behavior at a deeper level. This enables the system to detect anomalies and reduce false positives itself without waiting for some authority to identify known threats on a list.
  • The Allow List is for a select few who we know are safe and can immediately pass through in our analogy here, perhaps pilots, cabin staff and pre-screened passengers. They do not receive intensive screening, like a pat-down, nor do they even pass through the regular security line. They just rapidly move through to the gates.
  • Positive Security traffic can be much faster than signatures as it does not have to check against the whole list. And this majority of normal traffic allows the TSA to hone its procedures and learn what is normal and what is not.
  • Application Rules are specifically designed to block attacks on known application vulnerabilities (many of them with CVEs). They are automatically updated using the Application Rules of the NSX ALB Console. When the admin enables this protection, more than 5000 applications can be selected, thereby activating the specific application rules for that application in the WAF Policy guide
  • Click on the edit button. Note that transction in the earlier step was rejected because of this rule. We will verify the rule here.
  • Verify the rule
  • Save the policy
  • Remember at the begining of the clickthrough, we noticed how things went wront pretty quickly. With the WAF protection in place, let us try again!
  • Voila...Complete peace of mind !