X

Best Practices from Oracle Development's A‑Team

Identity is the new perimeter BUT, you still need a firewall!

Kiran Thakkar
Consulting Solutions Architect

Identity is the new perimeter. Sounds familiar?

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 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 Network firewall.

Network firewall

A network firewall is implemented by using 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:

  • Ingress rules specify the source (IP CIDR and port range), destination port range, and protocol to match on, and are applied to ingress network connections.
  • Egress rules specify the destination (IP CIDR and port range), source port range, and protocol to match on, and are applied to egress network connections.

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.

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 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.

What is the OCI Web Application Firewall?

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.

OCI WAF in action

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.

1. Protecting non-human actors from accessing workload

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.

2. Protecting sensitive data access from suspicious IP addresses

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.

3. Protection rules

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 document is not updated when you read it.

Best Practices to protect the workload

  • Always run workload (application servers, databases) in private subnet.
  • You should always have web server proxy in front of application servers
  • Web server proxy should only expose application endpoints. Every other endpoint on the application server including the administrative endpoints should be blocked.
  • Every application should only run over SSL. You can leverage WAF policy to block HTTP traffic and redirect to HTTPs
  • Use bastion hosts to access the application admin console
  • Use bastion host in public subnet to SSH to application and database instances
  • Security list should be tightly monitored and along with that, never turn off local firewall on compute instances
  • Never copy private keys on any of the compute instances
  • Never store application credentials or tokens in any of the application configuration files

More best practices when moving the workload to OCI

  • Production workload should run in a separate compartment than dev/test
  • Access to production compartment should be tightly controlled and monitored
  • Business critical applications should be deployed in multiple regions. You can configure (using edge security) to route traffic to a region closer to the end user.
  • Within the same region, application instances should be distributed across various availability domains
  • If you choose to run multiple instances in same availability domain then make sure they run on separate fault domains

Conclusion

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. 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha