Current revision updated by rgilbert39 on
Originally created by rgilbert39 on
Definitions: 
  • OIT: Office of Information Technology 
  • USG: University System of Georgia 
  • TSO: Technology Services Organization 
  • Fw.noc: The firewall interface used by COC to make firewall changes 
  • SS Edit: self-service edit allowing a user to make changes that are preapproved by OIT. 
  • Edit: this access allows users to make changes to the firewall that are not preapproved by OIT 
  • Mitigate: resolve or use a different control.  A patch or removing service would resolve while blocking access to the port or temporarily disabling a service would be a different control. 
GA Tech Cybersecurity Firewall Standards 

Ga Tech has firewall standards in place for compliance with the policies of GA Tech and USG. Before making any changes, it is required to know the policies and standards as well as take a GA Tech-provided training.  

Network Firewall Standard 

GA Tech networks are required to have centrally managed firewalls in place that deny connections by default and allow exceptions with a business justification. While outbound rules are allowed by default, inbound rules should be created to apply to only the assets needed. Some System Security Plans, policy exceptions, and asset classifications may require limits to how inbound and outbound are handled these are known as Data Protection Safeguards and minimum endpoint security standards.  

Secure Shell (SSH) Standard 

Due to the frequency of attacks and the purpose of SSH, it has its own standard. SSH should work with the Network Firewall standard and does not replace it or other safeguards. SSH is preferred to be connected via the internal network and 2FA VPN. When running externally, all tools must be installed, and any Vulnerability, Security Event, Vulnerability, or Incident must be resolved and handled per the Patch management, Vulnerability management, And Security Incident processes. It is imperative to have the root account set to not allow remote access and logs stored off the endpoint. The SSH standard has other requirements as well, such as the Login Banner, Intrusion detection, limiting failed logins, etc., that must be followed.  

Web Server Standard 

Web Servers also have their own standard. Web servers open to the public are required to maintain a supported OS, the latest OS updates, updated web server software, updated software powering the site, themes, plugins, etc. Any security issues must be addressed per the standards and processes designed for the issue type. Lack of proper patching and possible compromise can result in the ports being blocked or removed from the network. Spamming is not permitted. Authentication to web applications requires GT single sign-on that must be audited quarterly and unneeded access. Traffic is expected to be using TLS, and any non-TLS must auto-redirect. Logs are required to be on OIT LMaaS, and Web application firewalls must be used. 

Default Firewall Rules 

Default firewall rules are rules that apply to all endpoints in the subnet. These rules should only be in place when they will apply to all or most endpoints and be set to block 10. These rules should not be changed without TSO discussion and documented in a ticket and TSO changelog. The rules are set in Block which means they can be overridden with a permit or denied in a different block with full edit. TSO uses block 5 for permit and block 6 for deny.  It is important to note that if a rule is set for a port in Default rules, creating a different permit rule does not block it, there has to be a matching deny on the endpoint for it to block it. 

Firewalls and Vulnerability Handling 

Firewalls commonly act as a compensating control when another option is not available such as patch management and vulnerability management. This means opening a port not only puts that endpoint at risk but every endpoint on that subnet and other subnets that talk to any endpoints on the host subnet. TSO has created different subnets to reduce these risks.  

  • Local subnet only: These subnets are restrictive as these can be endpoints that cannot be patched or go extended times without patching. This could be due to cost or operational risk. By default, Inbound connections are restricted to Bastion hosts, MFA VPNs, TSO management network, and options only that have gone through risk management and have been approved through TSO Leadership. Outbound connections may also be restrictive per TSO review. 
  • Internal subnets only: These subnets are for endpoints That do not have all necessary tools installed, permanent admin access given, or other issues that are allowed by GT given that certain controls are in place. They allow inbound connections from Internal networks and MFA VPNs. Outbound access may be restrictive as necessary and can only be given by pinhole access to the endpoints. 
  • External subnets: These subnets are for endpoints needing incoming connections from the Internet.  The endpoints will have all tooling and follow GT and TSO processes which include but are not limited to Vulnerability, Patch, and incident processes. Outbound is not usually restricted, and subnets with common service-specific needs, such as Web Servers, may have the ports opened in the default rules, so opening per endpoint would not be necessary. It is very important to note that endpoints in these subnets will be isolated from the network quickly if proper actions are not being performed to resolve security issues or concerns.  
  • Special subnets: TSO has needs for smaller or specialized networks that must be recognized and administered accordingly. Examples can be a CUI subnet, which would use strict controls to protect data, a requested subnet by faculty or staff for better isolation for their equipment, such as requiring a certain System Security Plan or policy exceptions, or A TSO designated network for systems with policy exceptions. It is important that risks are noted for these networks and shared with the users of the networks in a Ticketing system.  

Firewall scans must be performed before opening ports on an endpoint or moving an endpoint to a different network. If a new or rebuilt endpoint is placed on a network initially, the scan should be done once online and vulnerabilities mitigated. The Firewall scan will only show Vulnerabilities at level 4 (High) and level 5 (Critical) that are seen from the network, so mitigation for these could be to block at the local host firewall.  The endpoint cannot have ports opened or for new endpoints to stay in an external subnet until vulnerabilities are mitigated.  

Vulnerabilities from continuous scans are reported on Mondays and will be reported upon detection if high risk to cert@cc.gatech.edu. These scans are run locally by the standard cloud agent and externally by the firewall. Vulnerabilities must be mitigated as soon as possible. The mitigation could be in place due to the current subnet rules which would allow a patch to wait for the patch process, or a deny rule on block 6 could mitigate. In the case of external subnets, the patch must be made on the endpoint as a compromised endpoint will not be blocked by the firewall. TSO Information Security can assist with any recommended actions. Vulnerability mitigation is handled in the following order.  

  1. SSP and CUI subnets or SSP endpoint’s external scans 
  2. SSP and CUI subnets or SSP endpoint’s Internal scans 
  3. External subnets external scans 
  4. External subnets internal scans 
  5. PER subnet external scans 
  6. Internal subnet external scans 
  7. Local subnet external scans 
  8. PER subnet internal scans 
  9. Internal subnet internal scans 
  10. Local subnet internal scans  
TSO Access 

GT provides two different access models in a single sign-on browser window for administrating firewalls. The access does require an OIT training course. 

  • SS Edit: this is a self-service edit access provided to all TSOs by OIT. A user is allowed to make firewall changes that are preapproved by OIT and deemed low-risk. If there is no option to make the change, it allows a ticket to OIT to approve it. For TSO, these changes should not use the ticket to OIT process but should be escalated to Infrastructure via an RT ticket. Networking or Security will decide the next steps and reach out to OIT if needed. 
  • Full Edit access: This access is reserved for Leads and ADs or equivalent job titles. This access allows the creation of rules that are not preapproved, so they are at higher risk. The changes should go to Infrastructure, but for emergency or special situations such as identifying ports for new applications, all Leads and ADs can make the change with an RT ticket showing risks and final ports left open; later the change will be reviewed per process.  
Firewall Change Process 

Firewalls are considered changes to the security configuration, so they must follow a change process. The process can defer risk acceptance over types of changes but must be followed to ensure the protection of data and assets. 

Changes using SS Edit, are accepted risks by OIT. Although it is suggested and may, in time, require it, an RT ticket is not required for the change.  

Changes being made outside SS Edit, must have an RT ticket and be assigned appropriately. This allows for risks to be analyzed, determination it is allowed in the subnet, and anything else that can place a risk to security. The determination and information will be documented in the ticket for tracking purposes. 

Linking and copying firewall rules is allowed in the GUI. Linking to an endpoint poses a risk as once the endpoint is no longer in use, its rules will be removed. This means the endpoints linked to it would also lose the rules. A user would need to assign the rules to a different endpoint and link the other endpoints to reestablish the rules. This can be administratively intensive, and the risk of human error is reintroduced. If possible, the copy method is preferred. 

Once the change is made, the user must upload the changes in FW.noc or it will not take effect. Once the upload is complete, an email is sent automatically so the user can review the change. The Cybersecurity Queue in RT will be on the email list so a ticket is generated. TSO Cybersecurity or another designated person will review the change, document their findings and any results from the review, and close the ticket. This will work as the change log. It is important to note that the reviewer cannot be the person who made the change. If Security made the change, then another lead or an AD must review it.   

Incident Handling 

Security incidents take high precedence in normal operations and can override them. An incident is defined as a suspected breach of an asset and data. Security or TSO leadership will make their best efforts to contact the endpoint owner immediately; however, if there is a suspicion of lost data, the priority is to isolate affected devices and protect the data and GT’s reputation. Once a device is isolated, the TSO representative must give the user a means of contact to assist in the restoration of the endpoint back to the network.  

Firewall reviews 

Firewalls are reviewed throughout the week from the homepage which shows vulnerabilities. Included in this score are MAC and DNS changes. When these are seen, it should be verified they are valid changes before clearing. If the change is valid and there is no longer an endpoint associated with an IP, then the firewall rules are cleared to prevent a future endpoint from automatically being subject to them. If it is the IP others are linked to for rules, then it must be coordinated with the appropriate teams for those rules to be moved. 

A minimum of once a year, the firewalls will be completely reviewed for the default rules and endpoint rules they have. During this review, decommissioned endpoint IPs will have the rules removed, Default Rules will be verified for continued need and endpoint rules will need to be verified with the users to determine if they are still required yearly. The evidence and information will be stored within the Cybersecurity file directory for later review.  

Links to More Information  
Filing Categories
Identifier Categories
Specific categories