Firewall as a Service: Best Practices

You’re ready to use Firewall as a Service to take granular control of your network access, but where should you start? 

Based on feedback from our many customers using FWaaS, we’ve compiled a list of suggestions to keep in mind as you create your network cloud firewall. 

Least Privilege: The Guiding Rule for Firewall as a Service

When defining your firewall rules, always keep Zero Trust and the “least privilege” principle in mind. Employees should only have access to what they need for their job, and resources and networks should only be open to those employees who need them.

Maintaining “least privilege” with the Perimeter 81 Firewall is easy. When adding rules, ensure that your network default is “Deny”:

When you set your network default to “Deny”, you are blocking network access from the start. Any rules you add to the network will be exceptions allowing access for specific users and resources. 

By setting your network to “Deny” and using network firewall rules to grant access to specific users and groups, you dramatically reduce your attack surface and ensure that hackers breaching a single user will not have access to your entire network. To further ensure that your network remains secure, you should also refrain from creating overly permissive rules, such as rules that unnecessarily allow all services or all addresses.  Such rules increase your attack surface and may create security risks, as they can expose vulnerabilities which otherwise could not have been exploited. 

Remember that the mistake of most hacked organizations was to allow too much access. The fewer privileges, the smaller the attack surface, and the less vulnerable the organization.

Basic Rules: Getting Started 

With the “least privilege” principle in mind, you may still wish to allow more universal access to resources or services that do not compromise your organization, such as Zoom or general Internet access. 

Beyond general services that everyone identified in the Perimeter 81 platform can access, you will also want to set up access for specific groups to the resources they need to do their jobs – for example, the software development team may need access to the MongoDB server on a regular basis, while the marketing department does not. 

Keep in mind that you may have particularly sensitive resources that should only be allowed to specific users rather than groups – for example, specific financial resources or applications that should not be accessible to the entire finance department.

In addition, you may wish to use firewall rules more widely as a preventive measure against the spread of malware by restricting employees to HTTP/HTTPS access. Such a rule isolates viruses on the infected computer so that action can be taken before the virus can spread to other computers, resources, or the corporate network.

Setting up Your Rules: Recommended Approaches

How you set up your rules is not written in stone, but you should choose a specific approach and then remain consistent. This will allow for easier management as your network grows and your network policies expand.

Three approaches are favored by those Perimeter 81 customers who are the heaviest users of Firewall as a Service:

1. By resource or service
   In this approach, your IT manager begins with the service or resource, and then decides who will have access to it. So for example, a rule named “SSH Access” can determine that only the Biz Ops team have access to the Operations SSH server.
2. By group
   In some organizations it is easier to decide what resources each department or group needs to access on a regular basis. In this case, you might have a rule called “Marketing Department Access” and then allow access for this group to resources such as Salesforce and Marketo.
3. Specific rules: Group to service
   In very specific cases, you may want to allow access for a specific group or user to a specific resource. For example, there may be a specific financial database that is only accessible to only the financial auditors. In that case, the rule may be named “Access to core financial DB for financial auditors.” Please note that this type of rule is the hardest to manage at scale, as such rules can multiply quickly. A consistent naming convention is very important here: choose whether you will start with the name of the group (in this case, the auditors) or of the service (the core financial database), so that you can easily filter rules to find the rule if you need to change it later.

Keeping it Simple: Naming conventions and rule type

We recommend that you choose either the first or second approach listed above as your foundation, and then add specific “group to service” rules if necessary. For maximum scalability, you should ensure that your naming convention is consistent, with your preferred approach determining the element that appears first in the network rule name.

So, if you have chosen to create rules by resource but sometimes wish to add a specific group-to-resource rule, rule names might look something like this:

• Zoom Access
• MongoDB Access
• Financial DB Access for CFO

In this way, if you add additional network rules regarding access to the financial database, they will appear next to your specific rule for the CFO, allowing you to prevent errors and redundancy.

If you had chosen the “group approach” instead, your rules might look like this:

• Marketing Department Access
• Development Team Access
• CFO Access to Financial DB

Again, what is important here is consistency, so that you can easily manage your rules as you scale up.

Enjoy Granular Control with FWaaS

We hope that this overview will help you begin your journey to more granular control of your network. We value your feedback, and we’d love to hear from you regarding your own recommended best practices and how we can improve the Perimeter 81 Firewall as a Service!