Something a little different for my site; this post is a soft-skill article. In job listing, or development plans its really common for Technical roles to include a soft skills component and I had kinda assumed it was filler content, how hard is it to talk to people?! A couple of years ago I moved from Consultancy into an Internal Operational role, and now, ok I get it, it's that old saying Men from Mars, Women from Venus but with like 7 Layers of OSI complication!

I have something like 15years experience working with firewalls in large enterprise, it's a tricky topic, if you cannot communicate your requirements to the firewall team the chances are you application/solutions/service just isn't going to work, after all as Scott Adams has portrayed in Dilbert, everyone blames the firewall.

Firewalls are everywhere, and even though the security industry likes to argue that they are becoming less and less effective I'm confident they're not going away any time soon, so here are my tips:

1. Do not forward (copy/paste) vendor documentation

If I had a £$ for every time I get forwarded this Microsoft document I'd be a millionaire, forwarding the documentation verbatim is the quickest way to get yourself at the bottom of someones's todo list or land you in the SLA trap where the minimum gets done on your ticket to keep the timer green.

Communication requires consideration, throwing a document you haven't read at another team is showing you don't value their time/effort

Remember:

• Everyone is busy! The simplest and most complete requests will be implemented quickest, all operations teams have this issue, it is not unique to firewalls.
• The firewall team do not know anything about your application/solution/service, but are accountable for the security; help them to help you, reduce friction by having information up front.
• You are making the request for Your Application, You should take the time to read and understand the documentation so that you can present the firewall change accurately and make it is simple as possible.

2. Presentation is everything

Always format your communication for your audience, powerpoint for Execs, spreadsheets for finance, for firewalls it's tables.

Large organisation will/probably/maybe have a template to follow for change requests, don't deviate from that, seriously if your firewall team has a template use it! Arguing yours is better is futile, firewalls form part of a compliance chain, auditors tick boxes your rockstar form won't tick the box; if you think you can improve the process or add value, speak to the Security Officer.

Formal documentation such as High Level (HLD) or Low Level Designs (LLD) might be a bit more fluid, here are some hints to make it easy to read and understood.

Arrows like -> should not be used in formal documentation, unless in a flow diagram, don't do it, from my experience I know it leads to mistakes. Something like 10.1.1.1 -> 192.168.1.1 on port 22 is fine for an email or instant message but for documentation use a table (or spreadsheet):

Source Name | Source IP    | Destination Name | Destination IP | Service Name | Protocol | Port | Comment
------------|--------------|------------------|----------------|--------------|----------|------|---------
VLAN11      | 10.10.0.0/24 | WebServer01      | 192.168.168.1  | HTTPS        | TCP      | 443  | Intranet
AdminPC     | 10.1.0.1     | WebServer01      | 192.168.168.1  | SSH          | TCP      | 22   | Admin Access

Use the above table format, give IP addresses names (use the FQDN if possible), the FW team will instantly recognise what needs to be done; a table like this is both simple to read and complete and will put you top of anyone's todo list.

If you have a large design document, I recommend the firewall table (communications matrix) being a summary/appendix of all the required flows as picking rules from disparate sections will only lead to tears.

3. Direction, know which way to go

On a firewall direction is really, really important. Your communication needs to demonstrate you know which way traffic is going and what your expectations are of the firewall.

Firewalls process traffic as it arrives, from a source IP to a destination IP. Your request needs to show which IP addresses are the client (source) and which IP address are the server (destination)... DO NOT bung in both directions to be "safe" when you don't need it, it just shows that you don't know what you are requesting, it's a common red flag for rule approvers/implementer.

For example, A laptop accessing a web site on HTTPS, needs TCP/443 to the server (web site) only. You do not need TCP/443 from the server (web site) to the client (laptop). Take time when digesting the vendor documentation to understand the direction of traffic flow.

Modern Firewall are smart when it comes to TCP and common applications; unless your traffic is media (voice/video) you typically don't need to worry about the random high port source, focus your effort on the destination port, get the direction right and your app will work.

(Media traffic is the devil, ask the firewall team for their recommendations prior to submitting your request)

4. Choose Secure

Most vendor documentation includes protocol choices, HTTP vs HTTPS for example. As the Firewall Team are responsible/accountable for security, you'll make friends with the security teams if you pick the secure protocol, forming strong relationships with other teams is a valuable skill.

If you are unclear, secure in this instance is encrypted. So:

• HTTPS (not HTTP)
• SSH (not Telnet)
• FTPs (FTP with SSL is better than plain old FTP)
• LDAPS (LDAP with SSL is better than plain old LDAP)
• etc, etc.. if in doubt pick "s" ;-)

Thanks to the dangers of Privacy/GDPR most organisations are moving to a Secure by Design motto, the firewall team are tasked to help enforce that.

5. Firewalls are everywhere

In a large enterprise there is going to be more than one firewall. Some organisations will add a column to their request tables to record which flow (rule) belongs to which firewall others will want a table per firewall.

If your environment is large/complicated, typically you'll find different firewalls for management, production traffic or testing. Keep the communication flowing with the firewall team to find out what you need to know/do before submitting a 100 rules, it'll save you all time!

Some firewall language

To finish, here is some further firewall language to help you on your way:

• Security Policy - A document that tells the firewall guy what he can and cannot allow through the firewall
• Firewall Policy - The complete set of rules implemented on a single firewall
• Firewall Rule - A line in the FW policy that contains, source, destination, service. The exact content of the line may vary by vendor.
• Flow - Firewall Flow / Network Flow / Traffic flow. All used interchangeably, it means the path taken from the source to the destination, a flow might touch one or many firewalls
• Communications Matrix - All of the rules required for an application or service that need to be implemented into an existing firewall policy

/End

Hopefully this is of help to someone, comments via twitter are welcomed; would you like to see more of this kind of thing?