This post is also available in: Português English Español
The terms and concepts associated to firewall have undergone major transformations over the last few years, so a simple packet filter in the first generations has now turned into a complex security architecture, comprised of several other features such as intrusion detection and prevention, antivirus, DLP, application control, web management based on categories, and many others.
Because of these developments, the complexity of deploying firewalls has changed considerably and now requires a much broader understanding of technologies than before. The good news is that, despite this, good practices continue to serve fully, regardless of the specificity of applied technologies.
In this post, we will address good practices for deployment of firewalls, be it using an open architecture of less complexity, or closed structures of high complexity. What will change of course will be the depth you can give in each of the topics, according to the requirement and maturity of your information security business.
Although our goal is to address good practices for deployment, be aware that in many cases there is a process of acquiring or changing the current technology, so we strongly recommend our e-book 10 essential firewall acquisition tips, which you can access by clicking here.
Items associated with firewall deployment process
Security policy
As cliché as this may seem, deploying a security asset without prior definition of its parameterization is the aspect that most frustrates those involved in such projects.
Therefore, however simple your business or your need for security, establish the minimum criteria for operation of the solution. If you have questions in this regard, we have created a checklistthat can help a lot in this process, just click here.
Based on the outcome of this step, you have defined what you want from the solution and how it should behave to protect the environment. Some of the aspects covered by the checklist will also be in this post.
Set a default policy
The default policy is nothing more than the action that will be taken if a particular packet or traffic crosses the firewall without having a rule predicting its behavior. In this case, although with some variants, in general the traffic can be released or blocked.
A restrictive standard policy assumes as a rule that everything will be blocked, except what is contemplated in the permission rules. Conversely, a permissive policy allows absolutely everything except what is configured in the lock rules.
Obviously, the ideal is to work with a restrictive policy, but this is often a problem, with many legitimate accesses being blocked, due to the lack of a correct mapping of the applications that should be allowed for the business.
Because of this, many end up opting to work with a permissive policy, blocking accesses as needed. This for some cases may seem interesting; however, it is important to note that you cannot block the unknown. In this sense, this policy is much more prone to problems and bypassing the structure.
Tip: The complexity of access management for some applications on the internet is a challenge for both policies, and in any product. So first, make a list of what should always work in your framework, validate it with vendor, test it, and then replicate it to production, affecting all users.
Do not expose private services without VPN
It is very common for the perimeter of companies today to be very mobile because even users outside their structure need to be connected, using internal systems to carry out their activities.
This mobility is a fantastic element, but it needs to be very well thought out so as not to expose the company to the internet. By the facility, it is tempting to have public port redirects for private services, or limited access, such as terminal services such as Microsoft RDS/WTS.
Before offering any external access to the company, whether it is for employees in transit or even for suppliers that need to perform some remote maintenance, do not do this without any security consideration.
Here we clearly set out for use with VPN, and this is a good practice if you need to offer secure private internal services to anyone on the internet. With this, you guarantee not only security in access but also control of who is connecting, among other facilities.
Ensure non-repudiation in internal or external accesses
Non-repudiation is a fundamental element in a security framework, basically meaning create mechanisms by which a user can be uniquely securely identified, without the user being able to claim they did not make certain action or access.
Translating this to a good practice of firewalls deployment, we want to emphasize the importance of working with authentication or unique identification of users, abstracting the control of accesses by equipment.
Create an authentication structure, preferably centralized, and integrate the firewall solution to ensure that access to the internet, both from the inside and vice versa, is properly authenticated.
This will ensure greater security, traceability to claims among other important usage tracking facilities and compliance with your business’s security policy.
Build a secure visitor access policy
Providing Internet access for visitors to your company is highly commonplace, but if done improperly it can lead to major problems. Customer, vendors and visitors of all kinds will inevitably request Internet access while passing through your company, so it is best to create a suitable environment for that.
This structure must be logically or physically separate from the production structure of your company. The reasons are different, but the main one is that you have no control over the device, and therefore, cannot gauge the security of the device.
An external device can bring intentional or opportunistic threats into its structure; because of this, it is so important to do this separation to avoid potential problems, because different from the employees, the relationship and responsibility in case of a claim is quite different.
Another point to emphasize for these networks is to ensure the traceability of users. This means that you need some mechanism, such as a captive portal, that will ensure that, in case of any need, it is possible to associate inappropriate access to a visitor.
Know more about Captive Portal: Captive portal benefits for authentication management
Create access policies by interest groups
Building a single policy that addresses everyone’s interest in a company can be very complex and does not satisfy, or even undermine, the productivity of certain employees.
Because of this, when it comes to setting your policy and deploying your firewall, you should be able to create group-based access policies, which can be departments, jobs, and the like, it is best for you to combine security and productivity.
Very restricted access policies can bring problems, especially of productivity to employees, and in many cases end up affecting motivation.
Unfortunately, not every sector can have flexible access, in many cases the policy must be very rigid and applied horizontally. In addition, this is quite acceptable in certain industries where managing exceptions can be a very big risk for any business.
Use DMZ or private network for public services
If your company offers some sort of public service to the internet, such as a portal of vendors, partners, email service and website, create a separate network for them and make the firewall regulate accesses between internal networks.
This is a basic and extremely functional measure for security, since once a DMZ service is compromised, the attacker is not in their administrative networks, nor will they gain access because the firewall will not allow this network to generate connections to the internal segments.
Once the DMZ is compromised, the attacker can only escalate to other services or DMZ equipment, which ultimately ensures that internal services such as database and other sensitive applications are not affected.
Create a change management process in the firewall
One of the trickiest points of good information security management is to ensure the quality and compliance of what has been deployed over time. So, create a basic change management process.
This will ensure that any need for change in policy must undergo a basic feasibility and risk analysis, thus based on this will generate a change request that should update its documentation or policy.
Believe: in time, this makes a fundamental difference, especially because knowledge stays in the company, not necessarily with people or suppliers who are, at that moment, involved in these activities.
Track network behavior and update access policies
A policy should not be immutable, especially at the beginning of its deployment and alignment with the firewall, as much information will come from that. In this case, in businesses where there is no technological resource applied, it is common to place the firewall with a permissive policy in the first few days or weeks, precisely to collect information and access profiles that can help in the construction of the guidelines themselves.
The important thing is to have a defined process of monitoring network utilization and security incidents, updating access policies according to need, balancing the security purpose with the functionality of the entire business requirement.
If your company has a dedicated security team, great. This should be a daily process through a SOC/SIEM. If you do not, regular follow-up is interesting. If the solution allows it, receiving reports by e-mail is enough to follow the environment.
Auditing
More incisively than monitoring network behavior, an audit process is not necessarily a good deployment practice, but it is a recurring procedure you should use in security framework.
The audit will ensure compliance of your policy with security assets over time, and if you are in disagreement, or the procedures should be updated, or items entered should be properly removed.
The audit work can be done internally, but depending on the type of business, external audit may be required. In these cases, in regulated markets or those that are more demanding, compliance is of course much more compliant.
Regardless of the size and maturity of your security business, these best practices are critical to a successful security management of firewall devices, and in some cases can be extended to other assets.
In conjunction with our checklist for building internet usage policies/guidelines, we are sure that your project will be a great success. Feel free to add comments or even contact our sales team.
This post is also available in: Português English Español
