Security Research Procedures


Submission of a policy exception request does not constitute an approved policy exception. Please await a response from the Cyber Security team prior to proceeding with your work.

Following this procedure and submitting the required policy exception is necessary, but may not be sufficient, to comply with all applicable Institute policies. Please seek IRB approval, etc. if your research requires it.


This procedure allows Cyber Security researchers to conduct their research without violating the law, violating Institute policy, or introducing reputational risk.


This procedure applies to all research and coursework that involves interacting with hosts and networks outside of your own lab environment. Examples of this type of interaction include:

  • Port scanning the internet (see best practices)
  • Port scanning the Georgia Tech network
  • Malware analysis allowing for callbacks
  • Sending malicious email
  • Operating Tor (or similar) exit nodes
  • Operating Darknets or Honeypots


Click on the following link to complete the policy exception form.

The form will require you enter the following information. Please collect this information prior to clicking the above link:

  • Name of the research project or course
  • Project website URL (for any project/course that may generate abuse complaints)
  • Name, email address, and phone number of the:
    • Principal Investigator or Professor
    • Primary point of contact
    • Secondary point of contact
  • A list of all Georgia Tech hosts involved in the research/course
  • A list of all Georgia Tech IP addresses involved in the research/course
  • A list of all student user IDs involved in the class project (for course only)

For any research project that is likely to generate abuse complaints (e.g. port scanning the internet), the following actions must be taken

  • Create a project website and include your host and IP address information on the website. The website should give visitors a description of what you are doing and give people direction on how to contact you and request that you no longer scan their hosts and networks.
  • Provide a simple means of opting out and honor requests promptly.
  • Create and use a whitelist of hosts/networks that have requested to opt-out.
  • Indicate the purpose of the interaction in the reverse DNS, UserAgent, etc. where possible.
  • Clearly explain the purpose and scope of the research in all communications.
  • Scope the interactions to be no larger, or more frequent, than is necessary for research objectives
  • Do not include special or unrouted network ranges.

For any abuse complaints, third party security notifications, or Georgia Tech generated alerts, the Georgia Tech Cyber Security team will send a notification to the primary point of contact for action. A response is required to the Cyber Security team within 24 hours. If no response is received within 24 hours, the secondary point of contact will be alerted and a response expected within 12 hours. If no response is received and appropriate action taken, the Cyber Security team is authorized by Institute policy to take the following actions as needed:

  • Physically or logically remove the device from the GT network
  • Physically power down the host in question
  • Physically seize the host in question (if it is a GT owned asset), if the host presents a threat to the Institute or others and forensic analysis is required
  • Lockout user accounts

In any case where the Cyber Security team believes a system to be compromised and is actively attacking Institute systems or networks, or outside systems or networks, the Cyber Security team is authorized to immediately take action as noted above.

Prohibited Actions

The following actions are expressly prohibited and will result in the Cyber Security team taking action as stated above:

  • Launching scanning activities or other research directly from the campus VPN subnets
  • Releasing malware into the wild
  • Exploiting hosts outside of your own lab environment without explicit permission from the owner of the systems you are attempting to exploit
  • Launching denial of service attacks outside of your own lab environment without explicit permission from the owner of the systems you are attempting to attack