1. Communications pathways to share best practices, learn more, and interact with colleagues and the community as a whole:

   1. The UW-Madison Palo Alto Firewall Services Readme KB document provides a brief description of the Palo Alto firewalls and links to helpful KB articles, training, and Palo Alto online resources. Includes links to training videos.

   2. The Firewall Admin User Group provides a venue for staff to learn more and share information about what they do at their local department level. The Firewall User Group has historically met quarterly and the cadence of meetings can be revised as needed.

   3. The Network Firewall Advisory Group (NFWAG) is an ongoing collaborative advisory group that includes subject matter experts and participants from representative UW–Madison academic and business units. The group is advisory to the chief information security officer (CISO). (see UW-513, section IIb).

   4. The UW-Madison Campus Firewall Administrators MS Teams channel ( link to join ).

   5. Leverage your professional networks and the expertise of colleagues on campus.

   6. Documentation of your firewall management processes and procedures provides a way to communicate about the specific rules, objects, etc. in your environment.

   7. Regular review of current firewall rulesets provides another way to communicate about your local configurations.
      
      

2. Rule change management process

   1. Groups should have locally consistent, documented change management practices that track on the who, what, when, and why of firewall changes.

   2. Firewall change management practices should meet the needs of your unit while also complying with UW System network security policy 1038 and UW-Madison firewall policy 513 needs.  

   3. Process considerations:

      1. All steps in the process should be repeatable in a consistent fashion.

      2. Process documentation should support new hire training and business continuity needs. 

      3. As part of a local review and approval step in the process, clearly define the information needed for review and the criteria for approve/deny conditions.

      4. As part of a communication step in the process, communicate changes for shared objects across departments.

      5. As part of an approval step in the process, define roles and responsibilities.

   4. Documentation should include:

      1. Who made the change: 

         1. If a single person serves multiple roles, then document that name in a single place; 

         2. If you have multiple people performing multiple roles, then include “who” in each change;

         3. If using a change management system, then typically who is auto documented

      2. What:

         1. The audience for a firewall change: what other departments may be or will be impacted by the change?

         2. Links to external documentation used in your unit: tickets, email archive, instructions, etc.

         3. Decommissioned servers or repurposed IP addresses for firewall objects and object groups.

      3. When: 

         1. The dates for the firewall change: effective date, end date, review date

      4. Why:

         1. The reason for a firewall change: why was the change made? What was the intended outcome of the change? Business need?

   5. Review

      1. Establish a time frame (process) for firewall rule reviews.

         1. Current time frames in use on campus include annually and quarterly.

      2. Items to consider when planning the frequency of your rule review are: data classification, compliance requirements and the risk category of systems protected by the rule.

3. Technical processes

   1. Using standard rule naming conventions will increase consistency and reduce confusion when reviewing and reporting on rulesets.

      1. Rule names should be easily understandable and descriptive, so that firewall admins are able to communicate quickly and confidently about which rule they are reviewing and changing. 

      2. Be consistent and ensure naming makes sense within your group.

   2. Adding tags to rules helps with organizing your rulebase for easier searching, grouping, and reporting:

      1. Be consistent within your group

      2. Tag based on the function or purpose of the rule. Examples are:

         1. IN or OUT (e.g.: INbound to network X/OUTbound from network X)

         2. Allow or Deny

         3. VPN-Rule

         4. Audit or Review for rules or other objects that need to be examined

      3. For instructions on how to create tags and tag rules in Palo Alto, go to Palo Alto’s Create and Apply Tags TechDoc (Source: docs.paloaltonetworks.com).

   3. Accessibility of Objects

      1. Application groups and service groups allow for grouping applications or services required for specific software access.

         1. Examples are: Active Directory, IBM BigFix, HP JetDirect

      2. PA tags allow you to group objects using keywords or phrases. You can apply tags to address objects, address groups (static and dynamic), zones, services, service groups and to policy rules.

      3. Address Groups should be used to group addresses for access, and named with a locally-meaningful name in order to communicate the political or practical grouping (eg: "Dean's Office" or "Linux Lab Workstations" or "Remote Access Linux Lab Workstations”).

         1. Address groups allow for application of security policies across addresses that require the same security settings.  

   4. Creating and testing firewall rules

      1. Your goal should be to only allow traffic that is necessary. Start restrictive and adjust to only allow traffic as necessary.

      2. PA recommendations for creating rules include: 

         1. Security Zones used in Source and Destination: avoid ambiguous rules allowing extra or unintended access

         2. Addresses and Address Groups used where possible to narrow scope of access

         3. Application-ID (eg, dell-drac, ssl, web-browsing) used when the network application is known to remove risk of unintentionally allowing applications running on non-standard service ports

            1. Service application-default when App-ID is used when services are running on standard ports, or specific ports otherwise

            2. For specifics, see the Application-ID KB article.

         4. User-ID in place of static IP addresses when User-ID is available and appropriate to avoid risk of IP spoofing or re-use of a static IP

            1. For specifics, see the User-ID/Manifest KB article.

         5. Inbound / Outbound Security Profiles applied to rules with Allow action (If rule denies or drops traffic the Security Profiles do not get processed)

            1. For specifics, see the Security Profiles KB article.

         6. Logging enabled with a log forwarding profile applied

         7. Description field populated with relevant information pertaining to the rule

      3. Use available “Preview Changes” when performing a commit to identify impact of changes made.

APPENDIX A: Examples

1. Tagging:

   1. Examples of tagging currently in use on campus:

      1. SMPH tags by department  (e.g.: SMPH-DOM-ANIM-CLIENTS_172-ANIMAL)

      2. Bacteriology tags by function (e.g. user remote access, interzone printing, etc.)

2. Rule Descriptions

   1. Rule description in PA can be up to 1024 characters, and include:

      1. Date, Ticket#, NetID of user making the change, Detailed description for rule purpose.

3. Change Management Roles

   1. Admin / change approver who reviews the change request against predetermined criteria and approves or denies the request.

   2. Technical expert who requests and commits the change.

   3. Test group users who are part of a smaller group to validate changes before releasing to your full unit.

   4. Assign the appropriate level of accountability to the role and expected duties.

4. DoIT Global Firewall Change Management Process

   1. Perform working session with team of DoIT campus firewall experts

   2. Communicate the work of the group to the firewall admins and scheduled global push

   3. Send reminder emails and Microsoft Teams Chat

   4. Create formal change request through DoIT services ticketing system (Cherwell)(aka WiscIT)

      1. Includes impacted services, impact check, approval process from stakeholders for services, and tracking for support staff.

Appendix B: Training

1. Documentation:

   1. Review Audit Comments section of individual firewall rules

      1. This section is found as a tab under the firewall rule properties window

   2. The before and after state of the change: print a PDF from the Palo Alto (PA) preview pane

   3. Expectations of “normal” traffic. A benchmark of what is expected from this rule and how traffic will look in Monitor, etc.

2. Rule descriptions should be used for extended communication of rule meaning.

3. Address groups allow for application of security policies across addresses that require the same security settings.  

4. Rule names in PA can be up to 63 characters, and often include a summary of the rule description including a brief note about purpose.

5. Addresses and Address Groups used where possible to narrow scope of access

   1. When a rule will be applied to multiple addresses, assess if they represent a logical organization and create reusable Address Groups  where possible.

   2. Avoid groups that don't represent logical organization and instead directly list addresses in rules (bad: "Group for Rule Name", good: "Dean's Office").