Strategy - Johnson-Marist-Research/gorp GitHub Wiki
Add a brief summary of what is GORP and how we hope it will be useful to solving the problem from our problem statement.
Goal-Oriented Action Planning (GOAP) is a technique utilized in game programming. GOAP features a set of pre-defined actions, but the sequence of actions is not preestablished and is instead determined by a planner algorithm. This allows for emergent behavior as the program assembles a sequence of actions that the developer did not directly implement. As such, this project aims to utilize GOAP in a cybersecurity defense program in order to deduce if the emergent actions are able to more effectively defend the device than predetermined actions.
What are the "goals" for the GORP agent? In this section, first identify the high-level goal(s) for the agent before breaking this down into smaller sub-goals that focus on one desired outcome at a time. Ideally, each sub-goal maps to some statement about the world. For example, imagine a video game in which we are using GOAP to implement the behavior of an NPC creature. The overarching goal for that creature might be to "stay alive", but we can break this down into a set of sub-goals like "satisfy hunger" and "satisfy thirst", which further map to properties of the world state such as
hungry = false
andthirsty = false
. In the context of our cybersecurity agent, we the goal of "protecting a system from cyber-threats" must be broken down into sub-goals, one of which might be "block unused ports", which might map to a world state property likeunused_open_port_count = 0
. (Note that exactly how we will do this is left to the design phase and the SDD.)
The goal of GORP is to...
- Successfully protect a device from cybersecurity threats
- Inform users when a threat is present
- Perform defensive cybersecurity actions to mitigate the risk of a cyber attack on the device
What are the "actions" for the GORP agent? Similar to the goals above, we first identify high-level actions that the agent might perform, but we must then break these down into a least three elements - preconditions, postconditions, and the mechanism/subsystem used to carry out the action. The preconditions are the prerequisite world state that must be present in order for the agent to perform the action; the postconditions represent the resulting world state that we expect to exist after the agent performs the action. For example, if a high-level action is "block port number 5000", then the preconditions might include
agent.has_firewall_permission = true
, the postconditions might includeport50.is_open = false
, and the mechanism/subsystem would include be the specific sequence of Windows/Linux/MacOS shell commands needed to add a firewall rule blocking traffic on the desired port.
The GORP agent will be able to...
- Scan, and potentially close, various ports
- Check ARP table for odd entries
- Monitor for unusual traffic
- Check permissions of files and notify the user if a file has an unusual or altered permission
- Check for gaps in its own logs
- Enter a "safe mode" where it parrots website names back to the user to determine if the DNS address was correctly translated
What are the "sensors" or mechanisms through which the agent obtains information about what is happening? For example, if the agent needs to know whether a given port is open or closed, what command(s) can provide that information? The agent would then need to run those commands periodically to update its knowledge of the world so that it "knows" the current state of a port. Ultimately, we will also have to decide how to represent information obtained from these "sensor" commands as structured data of the world state.
GORP will obtain information via...
- Repeated scans of the system
- Analysis of logs
- Will look for gaps or an unusual amount of activity
- Actions from other parts of the system to indicate when certain actions are being performed, such as DNS
What are the "subsystems" or mechanisms through which the agent can effect changes on the system? For example, as suggested above, actions involving closing or opening a port may require specific shell commands to be executed (dependent on the host system). A subsystem would be a software component or object that can carry out specific functions by executing the necessary shell commands.
Note: The following commands are for Windows, and are tentative solutions. Mainly focus on the steps that must be taken to perform an action.
- Scan, and potentially close, various ports
- Locate the process ID of the process occurring on the port (findstr :<PORT_NUMBER>)
- End the process (taskkill /PID /F)
- Create a firewall to block access to the port (Ex: netsh advfirewall firewall add rule name="Allow Inbound 80" dir=in action=allow protocol=TCP localport=80)
- Check ARP table for odd entries
- Use arp -a to pull up the ARP table
- Run through each entry in the table and keep track of how many IP addresses are mapped to individual MAC addresses
- If more than one IP address is mapped to a single MAC address, make a list of all the associated IP addresses
- Use a firewall to block the IP addresses in the list and notify the administrator of the unusual activity
- If the admin approves the addresses, unblock them. Otherwise, use arp -d to delete each IP address that the admin indicates must be removed (the admin has the option to select individual IP addresses or all of the addresses in the list)
- Monitor for unusual traffic
- Use netstat -an to display all active ports and connections
- Check the amount of traffic going through each port and compare it to a pre-stored average
- If the amount of traffic going through the ports is higher than a certain amount above average (maybe 50% above average), block the port and notify the admin
- Check permissions of files and notify the user if a file has an unusual or altered permission
- Make of list of the files we want to scan
- Use icacls to check the permissions of the files
- If the permissions of a specific file have changed since the last time the agent scanned, add the file name to a list
- At the end of the scan, send the list to the admin to see if the changes are intended
- If they are, remove the file from the list. If they are not, give the admin the opportunity to change the permission (icacls "path_to_file" /grant "user_or_group:(permissions)") or delete the file (del "path/to/file")
- Once the list is empty, save a list of the scanned files and their permissions to be referred back to the next time the agent performs a scan
- Check for gaps in its own logs
- This will be more within the agent itself and not within the overall device
- The agent will log when it turns on and when it turns off.
- To check its logs, it will run through the logs since it was last turned on.
- When specific log reports are started, it will check to see if expected follow-up logs are present.
- If they are not, they will report to the admin.
- Enter a "safe mode" where it parrots website names back to the user to determine if the DNS address was correctly translated
- When the device sends a DNS request, the agent will intercept it on the way back.
- It will check the received address against nslookup to see if the received address is the same as the expected address
- If not, the DNS request will be sent again
- If it is the same, the agent will parrot the website name it received from the DNS request
- If the website is correct, the user can indicate as such and proceed. If not, the user has the option to re-send the DNS request, or exit.