Name: Cayleigh Goberman

Date: 6/9/25

• 1 Introduction
• 2 System Overview
• 3 System Architecture
• 4 Data Design
• 5 Component Design
• 6 Human Interface Design
• 7 Requirements Matrix
• 8 Appendices

Identify the purpose of this SDD and its intended audience.

The purpose of this Software Design Document is to outline the functions of the Goal-Oriented Response Planning (GORP) program and detail how it will accomplish its various tasks. It will hopefully provide a clearer view of how GORP functions are modeled, therefore providing developers with a better understanding on how to program GORP. As such, this document is mainly intended for developers and any individual who wishes to understand the exact mechanisms in GORP.

Provide a description and scope of the software and explain the goals, objectives and benefits of your project.

Goal-Oriented Response Planning (GORP) is intended to act as an agent to protect against cyber threats. It utilizes Goal-Oriented Action Planning (GOAP), an algorithm often employed when programming non-player characters in video games, in order to create a variety of plans that can change depending on the requirements of the system. GOAP features a pre-set list of actions, but the order in which the actions are performed is determined by a planner algorithm. As such, this allows the program to display emergent behavior; for example, if a specific threat makes itself known, the program will prioritize the threat over, say, scanning files. The goal of this project is to adapt GORP into a cybersecurity setting in order to create an effective defense against cyber criminals, one which is constantly changing and thus hard for said criminals to predict. This should lead to a decreased likelihood that cyber criminals will be able to steal sensitive data from the targeted system.

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

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

Provide an overview of this document and its organization.

This document is split into eight sections; Introduction, System Overview, System Architecture, Data Design, Component Design, Human Interface Design, Requirements Matrix, and Appendices. The Introduction and System Overview act as a launching point into the more complex aspects of GORP, which will be covered in the following three sections. Since GORP is not very focused on human interaction, the human interface design and requirements matrix sections will most likely be fairly short. The system architecture, data design, and component design will include in-depth discussions of how GORP functions, and will include additional resources such as graphs and diagrams.

Optional. List any documents, if any, which were used as sources of information for the test plan.

There are currently no documents being utilized as reference material.

Optional. Provide definitions of all terms, acronyms, and abbreviations that might exist to properly interpret the SDD.

• Goal-Oriented Action Programming (GOAP): An algorithm often employed in video game programming that features a pre-set list of actions, but the order in which the actions are performed is determined by a planner algorithm. Employed to encourage emergent behavior in a program.

Give a general description of the functionality, context and design of your project. Provide any background information if necessary.

Goal-Oriented Response Planning (GORP) v.0.1 is a program based on Goal-Oriented Action Planning (GOAP) utilized when programming non-player characters in video games. GORP will employ GOAP strategies in order to execute dynamic plans when defending a device from cyber attacks. Numerous cyber defense programs run sequentially through a list of actions that they then perform to minimize a threat. GOAP features a set of pre-defined actions, but the sequence of actions is not predetermined and is instead determined by a planner algorithm. As such, this encourages emergent behavior, as the program executes a sequence of actions that the developer did not directly program. This will allow GORP to create and undertake a variety of plans and actions in order to dynamically respond to a variety of threats.

Develop a modular program structure and explain the relationships between the modules to achieve the complete functionality of the system. This is a high level overview of how responsibilities of the system were partitioned and then assigned to subsystems. Identify each high level subsystem and the roles or responsibilities assigned to it. Describe how these subsystems collaborate with each other in order to achieve the desired functionality. Don't go into too much detail about the individual subsystems. The main purpose is to gain a general understanding of how and why the system was decomposed, and how the individual parts work together. Provide a diagram showing the major subsystems and data repositories and their interconnections. Describe the diagram if required.

• Top-Level Architecture Diagram

Systems:

• Host computer
  • GORP will have to interact with the host computer. As such, it must be aware of specific functions in the host computer's systems, such as traffic flow, port numbers, ARP table entries, and active DNS requests.
• GORP
  • GORP is based on Goal-Oriented Action Planning (GOAP), which itself is comprised of several different components (see below). These subcomponents must be able to seamlessly interact with each other in order to effectively respond to various different scenarios.
• Possible outreach system in the form of email or text
  • If we decide to implement an alert system, GORP must be able to contact the administrator. As such, it must be able to either utilize SMTP to send an email, or access a wireless network to send a text.

Subsystems (GOAP):

• Sensors
• Working Memory
• Planner
• Goals
• Response Set
• Blackboard
• Misc.Subsystems
• A filter to feed hypothetical situations from Sensors and into the Misc. Subsystems

Provide a decomposition of the subsystems in the architectural design. Supplement with text as needed. You may choose to give a functional description or an object-oriented description. For a functional description, put top-level data flow diagram (DFD) and structural decomposition diagrams. For an OO description, put subsystem model, object diagrams, generalization hierarchy diagram(s) (if any), aggregation hierarchy diagram(s) (if any), interface specifications, and sequence diagrams here.

GORP

• Component Diagram
• Sequence Diagram 1 (Sensor, Working Memory, Planner, Blackboard, and Subsystems)
• Sequence Diagram 2 (Planner, Goals, and Response Set)

Host System Interaction with GORP

• Monitoring Ports, Monitoring ARP Table, and Checking File Permissions
• DNS Requests

Possible GORP Alert System

• Email and Text Diagrams

Discuss the rationale for selecting the architecture described in 3.1 including critical issues and trade/offs that were considered. You may discuss other architectures that were considered, provided that you explain why you didn't choose them.

As mentioned previously, GORP is designed around Goal-Oriented Action Planning (GOAP), an algorithm often employed to promote dynamic behavior in video game non-player characters. We specifically selected this architecture in order to promote emergent behavior in our cybersecurity agent. While GOAP and GORP have a set of pre-defined actions, the exact sequence of actions is not predetermined and is instead determined by the planner algorithm. As such, GORP will be able to dynamically respond to a variety of situations instead of simply sequentially running through a list of predetermined actions. We intend to deduce whether this emergent behavior can result in an efficient cybersecurity agent; as such, the GOAP architecture was one of our first, and really only, choices. After selecting GOAP, we simply needed to deduce how GORP will interact with the host system and other outside systems, which led to the diagrams that can be viewed in Section 3.2.

Explain how the information domain of your system is transformed into data structures. Describe how the major data or system entities are stored, processed and organized. List any databases or data storage items.

World States

GORP organizes its data into various world states. These states indicate how the program is currently configured. For example, a world state may indicate that ARP_anomalies = false in the ARP table. If a threat is detected and then quarantined, the world state might change to ARP_anomalies = true. When the anomaly has been dealt with, the world state can revert to ARP_anomalies = false. However, we might want to quarantine the threat and address it while while ARP_anomalies = false. We can address this by setting a world state to monitor the quarantine, such as ARP_anomaly_quarantined = true. When we clear the quarantine, either by blocking the associated IP addresses or un-quarantining them, we can set ARP_anomaly_quarantined = false.

The world states assist in GORP deciding its next actions. Sensors send data to the working memory, which takes note of the information and current world state. It then forwards the information to the planner. The planner will inspect the world state, deduce whether a goal is present, and consult the list of possible responses to find an appropriate action. Once a response has been selected, the world state may change. The planner sends this altered state to the blackboard, which in turn informs the subsystems that the world state has changed. This allows the subsystems to react accordingly to the altered state of the program.

Data and Security

GORP is concerned with keeping data safe and secure. As such, while it may not permanently store most of this data, it is responsible for sifting through it for malicious activity. As such, the processing of this data must be efficient and thorough. Otherwise, if too much time is spent analyzing a section of data, threats could find a different way to access the device or the device could slow down.

Alphabetically list the system entities or major data along with their types and descriptions. If you provided a functional description in Section 3.2, list all the functions and function parameters. If you provided an OO description, list the objects and its attributes, methods and method parameters.

GORP Components

• Blackboard
  • The blackboard stores information from planner in order to inform the subsystems of changes in world states. It acts as a "message board" to announce any actions the planner may have decided to implement.
• Goals
  • The goal is the world state that the program wants to achieve.
• Planner
  • The planner is the algorithm that notes the current world state, acknowledges the goal, and decides on the best course of actions to reach said goal through utilizing the available actions in the response set. The planner functions similarly to a search algorithm such as A*; it locates the best path of actions to reach the desired world state.
  • In other words, actions act as the edges in a graph that take the program from one world state, or vertex, to another.
• Response Set
  • The response set is the list of available actions that can be taken to achieve the goal. It is based off the action set in Goal-Oriented Action Planning (GOAP).
• Sensors
  • Sensors are the pieces of program that notify the working memory of changes in the system. In this case, they are normally implemented using an observer pattern or signals.
• Subsystems
  • The systems being affected by the GORP algorithm
• Working Memory
  • Working memory is the component of GORP that takes note of notifications from sensors and holds on to the information until the planner is ready to receive it.

Non-GORP Components and Entities

• ARP Table
  • The ARP table allows GORP to view which devices are connected to the host network. GORP will be able to scan the ARP table in order to locate abnormalities indicative of potential threats, such as multiple IP addresses being mapped to a single MAC address.
  • Data Type: string (IP and MAC addresses)
  • Possible Commands:
    • arp -a: Shows current entries in the ARP table
    • arp -d <IP_address>: Removes an IP address from the ARP table
• DNS Request
  • GORP will intercept DNS requests to check that the request has returned the expected website. It will not alter the request, but it will block it and tell the device to send another if the website is mismatched.
    • Data Type: Boolean (Yes for match, no for mismatch)
    • Possible Commands:
      • dig: Retrieves information about DNS name servers
      • nslookup: Obtains information about the domain name or IP address mapping
      • host: Locates the IP address of a particular domain name
      • iptables: Allows the device to filter traffic based on destination port or domain name.
• Files
  • File Permissions: Linux files have three possible permission settings; read, write, and execute. GORP will be able to detect when a permission has been changed since the last time a file was scanned.
    • Data Type: string (Could do "read", "write", "execute" or "r", "w", "e")
    • Possible Commands:
      • -l: Command for a long listing of file properties, including the permissions of the file.
      • access(3): A library call used with C languages. Checks file permissions.
      • gfal_chmod: Changes the permissions of a file.
• Host System
  • The host system is not part of the GORP architecture. Instead, it is the system that GORP must interact with. It contains and transfers the data that GORP is tasked with protecting.
• Logs
  • These logs are not part of the GORP algorithm itself, but will be utilized to track the various actions that GORP takes. Since this will be a log created from GORP, it will mostly be coded from the ground up and will not include any Linux commands.
  • Data Type: string
• Ports
  • Port Number: In order to open and close ports, GORP will need to know their individual port numbers. Otherwise, an unrelated port might be closed while the port under attack will continue to operate as normal.
    • Data Type: integer
    • Possible Commands:
      • netstat -ntu: Lists all ports on the system
      • netstat -lntu: Lists all open ports on the system
  • Traffic: GORP will monitor the amount of traffic passing in and out of ports. It will store the average traffic for a port. If the amount of traffic traveling through a specific port rises by a concerning amount (say, 50% above average), GORP will take actions to close the port and deduce whether a threat is present.
    • Data Type: integer
    • Possible Commands:
      • netstat: General command that checks how the device is connecting to the internet. Communicates a wide variety of information, such as connections the device is making, the paths it uses to send information, and how many packets of data are being sent or received
      • netstat -nltp: Lists the processes using a specific port
      • -k: Kills a task running on a specific port
• Processes
  • The host system's processes are the requests, responses, and general actions that programs within the system are performing. Certain processes can pass in and out of ports in order to share and receive information from other devices. Malicious actors can potentially highjack these programs for their own nefarious purposes; as such, GORP needs to be able to end processes if they exhibit concerning behavior.
  • Data Type: Boolean (process status, or if a process is running or not)
  • Possible Commands:
    • netstat: See above
    • top: Shows running processes and their resource usage
    • du: Estimates file space usage

In this section, we take a closer look at what each component does in a more systematic way. If you gave a functional description in section 3.2, provide a summary of your algorithm for each function listed in 3.2 in procedural description language (PDL) or pseudocode. If you gave an OO description, summarize each object member function for all the objects listed in 3.2 in PDL or pseudocode. Describe any local data when necessary.

Preconditions and Postconditions

Each component of the GORP system must function efficiently in a specific manner. In most cases, this involves being activated by certain preconditions, or specific world states and actions. Following the activation of the component, it will produce a specific postcondition, which is a world state that differs from the original precondition(s).

• Overall GORP Architecture
  • In order to solicit a response from the GORP algorithm, a sensor must detect a notable change in the host system. This precondition is then shared with the working memory, which stores the information until the planner can retrieve it. GORP then decides on the appropriate response to the precondition, which takes the form of the postcondition. This postcondition is then shared with the blackboard, which in turn sends it to the subsystems to be executed.
• Scan, and potentially close, various ports
  • Preconditions: normal_traffic, port_open
  • Postconditions: excess_traffic_detected, port_blocked
• Check ARP table for odd entries
  • Precondition: no_ARP_anomalies
  • Postcondition: ARP_anomaly_quarantined
• Check permissions of files and notify the user if a file has an unusual or altered permission
  • Precondition: files_unchanged
  • Postcondition: change_detected
• Check for gaps in its own logs
  • Precondition: no_gaps
  • Postcondition: gap_detected
• Enter a "safe mode" where it parrots website names back to the user to determine if the DNS address was correctly translated
  • Precondition: general_mode
  • Postcondition: safe_mode
  • Precondition: dns_match
  • Postcondition: dns_mismatch

A* Search

GORP's planner component utilizes a search algorithm similar to A* search in order to select the best response to a specific condition. A* search is an algorithm that strives to find the shortest/lowest cost path between two points on a map/graph. It works backwards from the goal by comparing various different paths and discarding those that are less efficient. In GORP, a path is the series of actions required to reach a goal. The actions are the edges in this graph, and world states are the vertices.

A* tends to be more efficient than other search algorithms due to the fact that it is heuristic, or able to speed up the process of path selection due to the fact that it can "guess" the correct path. It does this by taking the known cost, or g-cost, and making the search more efficient by guessing what the remaining costs will be. This "remaining cost" is known as the heuristic cost, or h-cost.

In the case of A*, the algorithm is guaranteed to get close to the optimal solution as long as the heuristic is admissible. In other words, as long as A* does not overestimate the remaining distance, it will find an option that is, at the very least, extremely close to the optimal path.

Goals

Goal selection in GORP is generally decided by which threats are the most urgent. For example, if unusual traffic is detected from a particular port, GORP will prioritize addressing that issue over, say, scanning file to check for changed permissions.

GORP's overall goal is to protect the device from cyber threats. However, due to the fact that this is a very broad idea, it can be broken down into several smaller goals:

• Perform defensive cybersecurity actions to mitigate the risk of a cyber attack on the device
• Monitor ports for suspicious increases in traffic
  • If a suspicious increase in traffic is detected, isolate the affected port.
• Ensure that the ARP table does not contain multiple IP addresses mapped to the same MAC address
• Check for unusual alterations in file permissions.
  • If an unusual alteration is detected, either revert the file to its previous permissions or delete the affected file.
• Ensure that DNS requests return the correct website
• Inform users when a threat is present

Additional Notes

At the moment, the main focus of GORP is to respond to a variety of scenarios by dynamically selecting from a set of actions. However, the current design still only allows for a single action at a time. In the future, we may want to look into actions that can affect multiple sections of the system at the time; for example, if multiple cyber threats are detected, GORP may be able to lock down the entire system while it deals with each individual threat. However, such far-reaching responses are outside the current scope of the project, and if pursued in the future, must be done so in a different stage.

Describe the functionality of the system from the user's perspective. Explain how the user will be able to use your system to complete all the expected features and the feedback information that will be displayed for the user.

As of this stage of the project, GORP will not be interacting with the user. It will gather data, assess threats, and generally act autonomously.

Display screenshots showing the interface from the user's perspective. These can be hand drawn or you can use an automated drawing tool. Just make them as accurate as possible. (Graph paper works well.)

A discussion of screen objects and actions associated with those objects.

Provide a crossreference that traces components and data structures to the requirements in your SRS document.

Use a tabular format to show which system components satisfy each of the functional requirements from the SRS. Refer to the functional requirements by the numbers/codes that you gave them in the SRS.

TBD...

Optional. Appendices may be included, either directly or by reference, to provide supporting details that could aid in the understanding of the Software Design Document.

TBD...

Based on Software Design Document (SDD) Template