SRS - Johnson-Marist-Research/gorp GitHub Wiki

Software Requirements Specification

For Goal-Oriented Action Planning

Version 0.0 approved by Matthew A Johnson
Prepared by Cayleigh Goberman
Marist University
6/3/25

Table of Contents

Revision History

Name Date Reason For Changes Version
Matthew 6/ 3/25 Initial markdown template 0.0
Cayleigh 6/ 4/25 Add initial content 0.1
Matthew 6/ 5/25 Minor formatting update 0.2

1 Introduction

1.1 Purpose

Identify the product whose software requirements are specified in this document, including the revision or release number. Describe the scope of the product that is covered by this SRS, particularly if this SRS describes only part of the system or a single subsystem.

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.

1.2 Document Conventions

Describe any standards or typographical conventions that were followed when writing this SRS, such as fonts or highlighting that have special significance. For example, state whether priorities for higher-level requirements are assumed to be inherited by detailed requirements, or whether every requirement statement is to have its own priority.

This document does not contain any unusual standards or typographical conventions.

1.3 Intended Audience and Reading Suggestions

Describe the different types of reader that the document is intended for, such as developers, project managers, marketing staff, users, testers, and documentation writers. Describe what the rest of this SRS contains and how it is organized. Suggest a sequence for reading the document, beginning with the overview sections and proceeding through the sections that are most pertinent to each reader type.

This document is intended for developers and potential users. The majority of this project will be undertaken by a small team of developers, and they are the individuals most likely to refer to this version of the document. However, it is still important for possible users to be able to refer to this document in order to understand what GORP is and how it functions. This SRS mainly contains an overview of what GORP is, how it functions, and what problems it addresses. If a reader wants a general description of GORP, they should refer to the "Overall Description" section. Since this is an early version of the product, the range of its application is limited, but it is an important starting point for later improvements. As such, the overall description contains a large portion of the important aspects of the project. If the reader requires more information, the remaining sections go into a bit more detail.

1.4 Product Scope

Provide a short description of the software being specified and its purpose, including relevant benefits, objectives, and goals. Relate the software to corporate goals or business strategies. If a separate vision and scope document is available, refer to it rather than duplicating its contents here.

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.

1.5 References

List any other documents or Web addresses to which this SRS refers. These may include user interface style guides, contracts, standards, system requirements specifications, use case documents, or a vision and scope document. Provide enough information so that the reader could access a copy of each reference, including title, author, version number, date, and source or location.

Project Proposal

Project Notes

Project Wiki

2 Overall Description

2.1 Product Perspective

Describe the context and origin of the product being specified in this SRS. For example, state whether this product is a follow-on member of a product family, a replacement for certain existing systems, or a new, self-contained product. If the SRS defines a component of a larger system, relate the requirements of the larger system to the functionality of this software and identify interfaces between the two. A simple diagram that shows the major components of the overall system, subsystem interconnections, and external interfaces can be helpful.

This product is a new, self-contained product. It was initially conceptualized as a way to test the effectiveness of GOAP in relation to cybersecurity; as such, we are developing it from scratch. If the project goes well, it may be further developed by adding a graphical user interface, but for now we are focusing on the basic functions of the product.

2.2 Product Functions

Summarize the major functions the product must perform or must let the user perform. Details will be provided in Section 3, so only a high level summary (such as a bullet list) is needed here. Organize the functions to make them understandable to any reader of the SRS. A picture of the major groups of related requirements and how they relate, such as a top level data flow diagram or object class diagram, is often effective.

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

2.3 User Classes and Characteristics

Identify the various user classes that you anticipate will use this product. User classes may be differentiated based on frequency of use, subset of product functions used, technical expertise, security or privilege levels, educational level, or experience. Describe the pertinent characteristics of each user class. Certain requirements may pertain only to certain user classes. Distinguish the most important user classes for this product from those who are less important to satisfy.

The primary user class will be those who employ Linux desktop computers. GORP will be designed mainly for Linux computers at the moment, and thus will most likely only work on those systems. The goal of the product is for users of various computer literacy to be able to use it; that being said, administrators will have the most control over it. Non-admins will have minimal access to GORP due to the amount of sensitive data GORP can access; as such, administrators and the owners of the computers will be the most important to satisfy. However, since the product is in its early stages, at the moment only users with an in-depth knowledge of how to navigate a computer will be able to access it. This stage of the project does not include the development of a graphical user interface, so GORP must be run as a basic computer program.

2.4 Operating Environment

Describe the environment in which the software will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist.

GORP will be run on Linux desktop computer systems. Ideally, it will be able to run on any desktop system, but we plan to focus on Linux for now. Additionally, it must be able to coexist with preexisting antivirus software; it would be counterproductive if it prevented another defensive agent from properly performing its job.

2.5 Design and Implementation Constraints

Describe any items or issues that will limit the options available to the developers. These might include: corporate or regulatory policies; hardware limitations (timing requirements, memory requirements); interfaces to other applications; specific technologies, tools, and databases to be used; parallel operations; language requirements; communications protocols; security considerations; design conventions or programming standards (for example, if the customer’s organization will be responsible for maintaining the delivered software).

There are only three individuals working on this project; as such, the speed at which the project can be completed will be slower than that of a larger team. Additionally, this project must be completed, or at least close to complete, within 300 hours. In other words, we have until the beginning of August, or about two months, to create a satisfactory product. Between the three of us, we have expertise on game design, GOAP algorithms, and cybersecurity. However, we may be slowed down slightly due to the fact that this knowledge is limited on a person-to-person basis; for example, one individual with knowledge of GOAP has a limited understanding of cybersecurity, and must have their work checked by another teammate.

2.6 User Documentation

List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software. Identify any known user documentation delivery formats or standards.

In addition to the GORP program, we intend to have a report of some sort ready to be delivered once the program is complete. We also have a few documents available at this time, although they may not be part of the official deliverable.

Original Proposal

Problem Description

Solution Strategy

General Notes

2.7 Assumptions and Dependencies

List any assumed factors (as opposed to known facts) that could affect the requirements stated in the SRS. These could include third-party or commercial components that you plan to use, issues around the development or operating environment, or constraints. The project could be affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors, such as software components that you intend to reuse from another project, unless they are already documented elsewhere (for example, in the vision and scope document or the project plan).

We are assuming that...

  • We will be utilizing a functional Linux operating system
  • We will be able to test the GORP program in a sandbox
  • Users will be able to start GORP on their own
    • Since this version of GORP is very bare-bones, it will have limited instructions included on how to use it. This may change in the future.

3 External Interface Requirements

3.1 User Interfaces

Describe the logical characteristics of each interface between the software product and the users. This may include sample screen images, any GUI standards or product family style guides that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on every screen, keyboard shortcuts, error message display standards, and so on. Define the software components for which a user interface is needed. Details of the user interface design should be documented in a separate user interface specification.

Since we are in an early stage of the project, there will be no graphical user interface. Instead, users will be able to view a window with logs that GORP produces. At the moment, GORP will be largely autonomous, so there is not much that the user can do to influence it beyond responding to alerts. That being said, alerts will either take the form of an email, a pop-up, or a pause in the logs.

3.2 Hardware Interfaces

Describe the logical and physical characteristics of each interface between the software product and the hardware components of the system. This may include the supported device types, the nature of the data and control interactions between the software and the hardware, and communication protocols to be used.

GORP is mainly software-focused. As previously mentioned, it will run on Linux operating systems.

3.3 Software Interfaces

Describe the connections between this product and other specific software components (name and version), including databases, operating systems, tools, libraries, and integrated commercial components. Identify the data items or messages coming into the system and going out and describe the purpose of each. Describe the services needed and the nature of communications. Refer to documents that describe detailed application programming interface protocols. Identify data that will be shared across software components. If the data sharing mechanism must be implemented in a specific way (for example, use of a global data area in a multitasking operating system), specify this as an implementation constraint.

GORP will have ample access to the Linux systems. It will be able to search through files and detect traffic flowing through various ports. Additionally, it should be able to detect when a DNS request is sent out, and intercept it before it can return the website name in order to double-check the answer's authenticity. GORP should also be able to access the ARP table in order to check for odd entries. Each of these actions are performed in order to detect and halt any possible threats to the device; as such, Linux software that is not related to these aspects of the device's safety will be ignored.

3.4 Communications Interfaces

Describe the requirements associated with any communications functions required by this product, including e-mail, web browser, network server communications protocols, electronic forms, and so on. Define any pertinent message formatting. Identify any communication standards that will be used, such as FTP or HTTP. Specify any communication security or encryption issues, data transfer rates, and synchronization mechanisms.

Depending on how we decide to implement alerts, GORP may be able to email the administrator to provide warnings and updates on the progress of containing a threat. It will also be involved in the DNS requests to open websites, but it is not associated with the information transfer itself, instead acting as an extra security gate to check the authenticity of the returned DNS.

4 System Features

This template illustrates organizing the functional requirements for the product by system features, the major services provided by the product. You may prefer to organize this section by use case, mode of operation, user class, object class, functional hierarchy, or combinations of these, whatever makes the most logical sense for your product.

4.1 System Feature 1

Don’t really say “System Feature 1.” State the feature name in just a few words.

Scan, and potentially close, various ports.

4.1.1 Description and Priority

Provide a short description of the feature and indicate whether it is of High, Medium, or Low priority. You could also include specific priority component ratings, such as benefit, penalty, cost, and risk (each rated on a relative scale from a low of 1 to a high of 9).

This feature will allow GORP to scan ports for unusual activity. If unusual activity, such as suspiciously increased traffic, is found, then GORP can end the task and close the port. This is high priority, as GORP must be able to detect attacks while they are in progress and shut them down.

4.1.2 Stimulus/Response Sequences

List the sequences of user actions and system responses that stimulate the behavior defined for this feature. These will correspond to the dialog elements associated with use cases.

GORP is largely autonomous, so the user does not need to perform any actions to start this task. However, the user may receive a notification in the form of an alert or email in order to inform them that the port was closed due to suspicious activity.

4.1.3 Functional Requirements

Itemize the detailed functional requirements associated with this feature. These are the software capabilities that must be present in order for the user to carry out the services provided by the feature, or to execute the use case. Include how the product should respond to anticipated error conditions or invalid inputs. Requirements should be concise, complete, unambiguous, verifiable, and necessary. Use “TBD” as a placeholder to indicate when necessary information is not yet available. Each requirement should be uniquely identified with a sequence number or a meaningful tag of some kind.

  • If a port is detected to have an unusually large amount of traffic, 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)

4.2 System Feature 2

Check ARP table for odd entries

4.2.1 Description and Priority

This feature will allow GORP to read through entries in the ARP table. If there are odd entries, such as multiple IP addresses mapped to a single MAC address, GORP will block the offending addresses. This will be one of the main features, so it is relatively high priority.

4.2.2 Stimulus/Response Sequences

GORP is largely autonomous, so the user does not need to perform any actions to start this task. However, the administrator will receive a notification when addresses are blocked, and will be given the option to unblock them or permanently ban them.

4.2.3 Functional Requirements

  • 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)

4.3 System Feature 3

Monitor for unusual traffic

4.3.1 Description and Priority

This action is related to the scanning ports feature. GORP will keep track of the average amount of traffic traveling through ports. If a port experiences a drastic spike in traffic, GORP will take note and perform any necessary actions.

4.3.2 Stimulus/Response Sequences

GORP is largely autonomous, so the user does not need to perform any actions to start this task. If the port must be blocked, GORP will proceed to the "block port" feature, which will send the administrator a notification.

4.3.3 Functional Requirements

  • 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

4.4 System Feature 4

Check permissions of files and notify the user if a file has an unusual or altered permission

4.4.1 Description and Priority

GORP will occasionally scan through a group of files and check their permissions. If a file's permission has been alters, such as from "read" to "execute", GORP will notify the administrator and double-check that the change is intended. If it is not, the admin has the option to either change the permission back, or delete the file. This will be one of the main features, so it is relatively high priority.

4.4.2 Stimulus/Response Sequences

GORP is largely autonomous, so the user does not need to perform any actions to start this task. If altered file permissions are detected, GORP will double-check with the administrator that the file changes are intended.

4.4.3 Functional Requirements

  • 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

4.5 System Feature 5

Check for gaps in its own logs

4.5.1 Description and Priority

GORP will occasionally scan through its own logs from when it was last started. If it detects gaps in these logs, it will notify the administrator that there is a potential problem. This will be one of the main features, so it is relatively high priority.

4.5.2 Stimulus/Response Sequences

GORP is largely autonomous, so the user does not need to perform any actions to start this task. As with previous features, it will simply notify the administrator that something is wrong.

4.5.3 Functional Requirements

  • 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.

4.6 System Feature 6

Enter a "safe mode" where it parrots website names back to the user to determine if the DNS address was correctly translated

4.6.1 Description and Priority

When this mode is enabled, GORP will be able to detect and intercept DNS requests. It will check the returned website against what the expected website is, then ask the user if they want to go to the returned website. This will be one of the main features, so it is relatively high priority.

4.6.2 Stimulus/Response Sequences

GORP is largely autonomous, so the user does not need to perform any actions to start this task. This feature activates whenever GORP detects a DNS request. The user will have the option to review the website name and try again if the name is incorrect.

4.6.3 Functional Requirements

  • 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.

5 Other Nonfunctional Requirements

5.1 Performance Requirements

If there are performance requirements for the product under various circumstances, state them here and explain their rationale, to help the developers understand the intent and make suitable design choices. Specify the timing relationships for real time systems. Make such requirements as specific as possible. You may need to state performance requirements for individual functional requirements or features.

GORP performs various scans on sections of the system at varying times. The exact timing will be calculated based on the risk specific sections are under, which will be pinpointed over the course of this project. If a threat is detected, GORP will stop all other operations and focus on isolating the threat. Once the admin has made a decision, normal functions will resume. These functions must be unobtrusive, otherwise GORP will unintentionally impede users from working on the device.

5.2 Safety Requirements

Specify those requirements that are concerned with possible loss, damage, or harm that could result from the use of the product. Define any safeguards or actions that must be taken, as well as actions that must be prevented. Refer to any external policies or regulations that state safety issues that affect the product’s design or use. Define any safety certifications that must be satisfied.

GORP must be designed carefully in order to prevent damage to sensitive data. For example, it cannot block essential processes. This is part of the reason why it consults the administrator; the extra level of human oversight prevents it from accidentally altering or deleting important files.

5.3 Security Requirements

Specify any requirements regarding security or privacy issues surrounding use of the product or protection of the data used or created by the product. Define any user identity authentication requirements. Refer to any external policies or regulations containing security issues that affect the product. Define any security or privacy certifications that must be satisfied.

At some point in the future, we may require users to enter a password to access GORP. After all, GORP can access and alter sensitive data on the device, so it needs to be protected by certain security measures itself. However, since we are in the testing phase, we will not be implementing a password at the moment. Otherwise, GORP itself is a cybersecurity agent; as such, see Section 4: System Features for more information on how this product relates to device security.

5.4 Software Quality Attributes

Specify any additional quality characteristics for the product that will be important to either the customers or the developers. Some to consider are: adaptability, availability, correctness, flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability, and usability. Write these to be specific, quantitative, and verifiable when possible. At the least, clarify the relative preferences for various attributes, such as ease of use over ease of learning.

At the moment, our main focus is on making GORP efficient and effective. This may lead to it being hard to understand from an outside perspective, but since this is the early stage of the project, this is acceptable. We will mainly attempt to make the product as correct, flexible, robust, reliable, reusable, and adaptable as possible.

5.5 Business Rules

List any operating principles about the product, such as which individuals or roles can perform which functions under specific circumstances. These are not functional requirements in themselves, but they may imply certain functional requirements to enforce the rules.

GORP is largely autonomous, so the user does not need to perform any actions other than starting the program and responding to alerts.

6 Other Requirements

Define any other requirements not covered elsewhere in the SRS. This might include database requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so on. Add any new sections that are pertinent to the project.

TBD...

Appendix A: Glossary

Define all the terms necessary to properly interpret the SRS, including acronyms and abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire organization, and just include terms specific to a single project in each SRS.

TBD...

Appendix B: Analysis Models

Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams, state-transition diagrams, or entity-relationship diagrams.

TBD...

Appendix C: To Be Determined List

Collect a numbered list of the TBD (to be determined) references that remain in the SRS so they can be tracked to closure.

TBD...