In a traditional on-prem world, all the workload had one thing in common. They were all part of a large private network. You could shield that common attack vector (network) with strong security policies using both Web Application Firewall (WAF) and network firewall. As the workload moved to cloud, it moved to a lot of different cloud providers some SaaS and some Iaas_PaaS. In such a distributed world, the network is no more shared or is no more common factor. identity is the one common factor. You could use that to apply uniform security policies across various applications. From that perspective, yes, identity is the new perimeter however, you still have to protect the workload using WAF and network firewall.
We, at Oracle, have always believed in defense in depth. When you run the workload on the Oracle cloud, you get to choose the best of both worlds. You can and must implement traditional firewall-based security using WAF (Web Application Firewall), and network firewall, and also leverage Oracle cloud IAM to secure workload making sure who and when can access the workload.
Today, I want to focus on how to best use WAF policies and network firewall on OCI to secure the workload. Let's start with a Network firewall.
A network firewall is implemented by using the Virtual Cloud Network (VCN) security lists. Customers can specify a set of firewall rules and associate them with one or more subnets. Associating a security list with a subnet applies those firewall rules to all instances running inside the subnet, at the packet level. There are two types of firewall rules:
Every VCN has a default security list that customers can optionally use that allows only SSH and certain types of important ICMP ingress traffic and all egress traffic. Customers can associate multiple security lists with a subnet. The subnet uses the default security list if the customer doesn’t specify another list for the subnet to use.
The OCI Web Application Firewall (OCI WAF) is a cloud-based, PCI-compliant global security service that protects applications from malicious and unwanted internet traffic. Essentially, it is a device_filter on the service side that applies a set of rules to HTTP_S traffic. By intercepting HTTP_S traffic and passing them through a set of filters and rules, WAF is able to uncover and protect against attach streams hitting a web application. Generally, these rules cover common attacks such as Cross-Side Scripting (XSS) and SQL injection in addition to giving customers the ability to filter specific source IPs or bad bots. Typical response from WAF will either be allowing the request to pass through, audit logging the request, or blocking the request by responding with an error page.
Apart from a lot of flexibility it offers as being a firewall_proxy, it offers various security policies. Here is a couple of examples of those policies and how you would use them.
Bot Management of OCI WAF enables you to mitigate undesired bot traffic from your site using CAPTCHA and JavaScript detection tools while enabling known published bot providers like Applebot or Googlebot to bypass these controls. You can enable these controls either for the home page or for a sensitive resource(s) of the application.
You can create access rules to protect sensitive data or admin functions of the workload from unknown IP addresses or countries or devices. You can either log and allow that access or block that access.
WAF supports close to 500 Out-Of-the-Box protection rules ranging from SQL injection to XSS attack to HTTP parameter pollution. It has some very specific platform-specific rules as well like WebLogic, Drupal, Java Spring or Struts, etc. Here is an incomplete list of protection rules. The reason I say incomplete is that more rules are being added frequently and it is possible that the document is not updated when you read it.
In this day and age of increasing cyber-attacks, having such strong security measures are absolutely mandatory for sound sleep. OCI offers you end to end security. OCI WAF and network firewall are two such tools.
Apart from that, every compute instance has a local firewall running. It is advisable to not disable the local firewall. This gives defense in depth. Even if the network admin makes a mistake and opens a port that should not be open, the local firewall on compute instance can block that traffic.
Apart from the network firewall, you must also protect the workload using a WAF.
Kiran Thakkar is an expert in Identity and Access Management with more than 10 years of experience in the space. He is also OCI certified Associate Architect and help customers on OCI use cases. He is believer in blockchain technology and follows that space as it grows.
Previous Post
Next Post