Phase 1– [Primary Migration Complete, fall 2017]. Migration of our existing firewall functionality from our Cisco ASA appliances to the Palo Alto appliances. This will include implementation of Security Profiles at the campus border. This functionality incorporates Antivirus, Anti-spyware, URL Filtering, and Vulnerability Protection. Vulnerability Protection replaces the Intrusion Prevention System functionality of our old border firewalls.Phase 2– [Complete, July 2018] A number of smaller steps which includes:Migrating NAT firewalls from ASAs to Palo Altos.We have a few firewalls that are performing NAT operations for security or regulatory compliance. The Palo Altos do this differently than Cisco, so it is taking some extra time to prepare.Implementing Security Profiles for intra-campus traffic.This feature includes Antivirus, Anti-spyware, and Vulnerability Protection: aka Intrusion Prevention. We have had these features running on our campus border for some time, and have had them set to send alerts for intra-campus traffic. This enhancement will block malicious traffic detected between campus networks.Implementing DoS protection features for intra-campus traffic.This protects the data plane of the appliance and will drop malicious traffic, such as a SYN flood, before it ever hits a security policy.Implementing External Dynamic Lists– Palo Alto provides functionality where the firewall can query a text file on an external web server that contains IP addresses, URLs, or domains. It then populates Objects with this information which can then be used in a security policy. Mapping these lists to Global Scopes in fw.noc will allow us to manage how these are used with the fw.noc application, and replace some Global Scopes which currently have to be updated manually or via scripts. Using External Dynamic Lists increases the update intervals for this information, and will give us additional flexibility to use external feeds of malicious or whitelisted IP addresses and domains.Adding the ability to create new firewall rules via fw.nocthat use AppID, which bases a security policy rule on the application rather than port and protocol. This can prevent malicious traffic, such as non-web traffic traversing a port intended for web only.Updating our firewall course as we add AppID features into fw.noc.We will also be offering a shorter refresher course for existing authorized requesters.
- Phase 3 – Further development of AppID and UserID functionality into fw.noc. AppID allows us to create rules based on application. UserID allows us to create rules based on a user or group.
- Add AppID based rules to the pre-approved list. Customers would be able to select an AppID based rule from the pulldown list just as they do today with port based rules. Most of the existing Pre-approved rules are intended to permit applications, making a migration from port based to AppID straightforward for the customer.
- Add AppID functionality to new rule requests which are not pre-approved. Much like a customer manually typing in a port and protocol today, they will be able to type in the AppID for the service they require as part of their new rule request.
- Add UserID based rules to the pre-approved list. An example could be ‘allow ssh from single UserID or Group
- Add UserID functionality to new rule requests which are not pre-approved.
- Updating our firewall course as we add AppID and UserID features into fw.noc. We will also be offering a shorter refresher course for existing authorized requesters.