Merged PR 221: Version 3 beta 2 doc changes
## Summary *Replace this text with an explanation of what the changes are and how you implemented them. Can this impact any other parts of the codebase that we should keep in mind?* ## Test process *How have you tested this (if applicable)?* ## Checklist - [Y] PR is linked to a **work item** - [Y] **acceptance criteria** of linked ticket are met - [Y ] performed **self-review** of the code - [N] written **tests** for any new functionality added with this PR - [Y] updated the **documentation** if this PR changes or adds functionality - [N] written/updated **design docs** if this PR implements new functionality - [N] updated the **change log** - [Y] ran **pre-commit** checks for code style - [N] attended to any **TO-DOs** left in the code Related work items: #2068
This commit is contained in:
@@ -18,7 +18,6 @@ PrimAITE provides the following features:
|
||||
* Highly configurable network hosts, including definition of software, file system, and network interfaces,
|
||||
* Realistic network traffic simulation, including address and sending packets via internet protocols like TCP, UDP, ICMP, etc.
|
||||
* Routers with traffic routing and firewall capabilities
|
||||
* Interfaces with ARCD GATE to allow training of agents
|
||||
* Simulation of customisable deterministic agents
|
||||
* Support for multiple agents, each having their own customisable observation space, action space, and reward function definition.
|
||||
|
||||
@@ -148,7 +147,7 @@ The game layer is built on top of the simulator and it consumes the simulation a
|
||||
Observation Spaces
|
||||
******************
|
||||
The observation space provides the blue agent with information about the current status of nodes and links.
|
||||
PrimAITE builds on top of Gym Spaces to create an observation space that is easily configurable for users. It's made up of components which are managed by the :py:class:`primaite.environment.observations.ObservationsHandler`. Each training scenario can define its own observation space, and the user can choose which information to inlude, and how it should be formatted.
|
||||
PrimAITE builds on top of Gymnasium Spaces to create an observation space that is easily configurable for users. It's made up of components which are managed by the :py:class:`primaite.environment.observations.ObservationsHandler`. Each training scenario can define its own observation space, and the user can choose which information to inlude, and how it should be formatted.
|
||||
NodeLinkTable component
|
||||
-----------------------
|
||||
For example, the :py:class:`primaite.environment.observations.NodeLinkTable` component represents the status of nodes and links as a ``gym.spaces.Box`` with an example format shown below:
|
||||
@@ -279,7 +278,7 @@ The game layer is built on top of the simulator and it consumes the simulation a
|
||||
3. Any (Agent can take both node-based and ACL-based actions)
|
||||
The choice of action space used during a training session is determined in the config_[name].yaml file.
|
||||
**Node-Based**
|
||||
The agent is able to influence the status of nodes by switching them off, resetting, or patching operating systems and services. In this instance, the action space is an OpenAI Gym spaces.Discrete type, as follows:
|
||||
The agent is able to influence the status of nodes by switching them off, resetting, or patching operating systems and services. In this instance, the action space is a Gymnasium spaces.Discrete type, as follows:
|
||||
* Dictionary item {... ,1: [x1, x2, x3,x4] ...}
|
||||
The placeholders inside the list under the key '1' mean the following:
|
||||
* [0, num nodes] - Node ID (0 = nothing, node ID)
|
||||
@@ -287,7 +286,7 @@ The game layer is built on top of the simulator and it consumes the simulation a
|
||||
* [0, 3] - Action on property (0 = nothing, 1 = on / scan, 2 = off / repair, 3 = reset / patch / restore)
|
||||
* [0, num services] - Resolves to service ID (0 = nothing, resolves to service)
|
||||
**Access Control List**
|
||||
The blue agent is able to influence the configuration of the Access Control List rule set (which implements a system-wide firewall). In this instance, the action space is an OpenAI spaces.Discrete type, as follows:
|
||||
The blue agent is able to influence the configuration of the Access Control List rule set (which implements a system-wide firewall). In this instance, the action space is an Gymnasium spaces.Discrete type, as follows:
|
||||
* Dictionary item {... ,1: [x1, x2, x3, x4, x5, x6] ...}
|
||||
The placeholders inside the list under the key '1' mean the following:
|
||||
* [0, 2] - Action (0 = do nothing, 1 = create rule, 2 = delete rule)
|
||||
|
||||
@@ -1,14 +0,0 @@
|
||||
.. only:: comment
|
||||
|
||||
© Crown-owned copyright 2023, Defence Science and Technology Laboratory UK
|
||||
|
||||
Custom Agents
|
||||
=============
|
||||
|
||||
|
||||
Integrating a user defined blue agent
|
||||
*************************************
|
||||
|
||||
.. note::
|
||||
|
||||
PrimAITE uses ARCD GATE for agent integration. In order to use a custom agent with PrimAITE, you must integrate it with ARCD GATE. Please look at the ARCD GATE documentation for more information.
|
||||
@@ -4,9 +4,9 @@ PrimAITE Game layer
|
||||
The Primaite codebase consists of two main modules:
|
||||
|
||||
* ``simulator``: The simulation logic including the network topology, the network state, and behaviour of various hardware and software classes.
|
||||
* ``game``: The agent-training infrastructure which helps reinforcement learning agents interface with the simulation. This includes the observation, action, and rewards, for RL agents, but also scripted deterministic agents. The game layer orchestrates all the interactions between modules, including ARCD GATE.
|
||||
* ``game``: The agent-training infrastructure which helps reinforcement learning agents interface with the simulation. This includes the observation, action, and rewards, for RL agents, but also scripted deterministic agents. The game layer orchestrates all the interactions between modules.
|
||||
|
||||
These two components have been decoupled to allow the agent training code in ARCD GATE to be reused with other simulators. The simulator and game layer communicate using the PrimAITE State API and the PrimAITE Request API. The game layer communicates with ARCD gate using the `Farama Gymnasium Spaces API <https://gymnasium.farama.org/api/spaces/>`_.
|
||||
The simulator and game layer communicate using the PrimAITE State API and the PrimAITE Request API.
|
||||
|
||||
..
|
||||
TODO: write up these APIs and link them here.
|
||||
@@ -20,13 +20,14 @@ The game layer is responsible for managing agents and getting them to interface
|
||||
PrimAITE Session
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
``PrimaiteSession`` is the main entry point into Primaite and it allows the simultaneous coordination of a simulation and agents that interact with it. It also sends messages to ARCD GATE to perform reinforcement learning. ``PrimaiteSession`` keeps track of multiple agents of different types.
|
||||
``PrimaiteSession`` is the main entry point into Primaite and it allows the simultaneous coordination of a simulation and agents that interact with it. ``PrimaiteSession`` keeps track of multiple agents of different types.
|
||||
|
||||
Agents
|
||||
^^^^^^
|
||||
|
||||
All agents inherit from the :py:class:`primaite.game.agent.interface.AbstractAgent` class, which mandates that they have an ObservationManager, ActionManager, and RewardManager. The agent behaviour depends on the type of agent, but there are two main types:
|
||||
* RL agents action during each step is decided by an RL algorithm which lives inside of ARCD GATE. The agent within PrimAITE just acts to format and forward actions decided by an RL policy.
|
||||
|
||||
* RL agents action during each step is decided by an appropriate RL algorithm. The agent within PrimAITE just acts to format and forward actions decided by an RL policy.
|
||||
* Deterministic agents perform all of their decision making within the PrimAITE game layer. They typically have a scripted policy which always performs the same action or a rule-based policy which performs actions based on the current state of the simulation. They can have a stochastic element, and their seed will be settable.
|
||||
|
||||
..
|
||||
|
||||
@@ -87,22 +87,7 @@ Install PrimAITE
|
||||
|
||||
pip install path\to\your\primaite.whl
|
||||
|
||||
|
||||
5. Install ARCD GATE from wheel file
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
:caption: Unix
|
||||
|
||||
pip install path/to/your/arcd_gate-0.1.0-py3-none-any.whl
|
||||
|
||||
.. code-block:: powershell
|
||||
:caption: Windows (Powershell)
|
||||
|
||||
pip install path\to\your\arcd_gate-0.1.0-py3-none-any.whl
|
||||
|
||||
|
||||
6. Perform the PrimAITE setup
|
||||
5. Perform the PrimAITE setup
|
||||
|
||||
.. code-block:: bash
|
||||
:caption: Unix
|
||||
@@ -153,17 +138,4 @@ of your choice:
|
||||
|
||||
pip install -e .[dev]
|
||||
|
||||
|
||||
4. Install ARCD GATE from wheel file
|
||||
|
||||
.. code-block:: bash
|
||||
:caption: Unix
|
||||
|
||||
pip install GATE/arcd_gate-0.1.0-py3-none-any.whl
|
||||
|
||||
.. code-block:: powershell
|
||||
:caption: Windows (Powershell)
|
||||
|
||||
pip install GATE\arcd_gate-0.1.0-py3-none-any.whl
|
||||
|
||||
To view the complete list of packages installed during PrimAITE installation, go to the dependencies page (:ref:`Dependencies`).
|
||||
|
||||
@@ -74,8 +74,8 @@ Glossary
|
||||
Laydown
|
||||
The laydown is a file which defines the training scenario. It contains the network topology, firewall rules, services, protocols, and details about green and red agent behaviours.
|
||||
|
||||
Gym
|
||||
PrimAITE uses the Gym reinforcement learning framework API to create a training environment and interface with RL agents. Gym defines a common way of creating observations, actions, and rewards.
|
||||
Gymnasium
|
||||
PrimAITE uses the Gymnasium reinforcement learning framework API to create a training environment and interface with RL agents. Gymnasium defines a common way of creating observations, actions, and rewards.
|
||||
|
||||
User app home
|
||||
PrimAITE supports upgrading software version while retaining user data. The user data directory is where configs, notebooks, and results are stored, this location is `~/primaite<version>` on linux/darwin and `C:\Users\<username>\primaite\<version>` on Windows.
|
||||
PrimAITE supports upgrading software version while retaining user data. The user data directory is where configs, notebooks, and results are stored, this location is `~/primaite<version>` on linux/darwin and `C:\\Users\\<username>\\primaite\\<version>` on Windows.
|
||||
|
||||
@@ -5,12 +5,12 @@
|
||||
Request System
|
||||
==============
|
||||
|
||||
``SimComponent`` in the simulation are decoupled from the agent training logic. However, they still need a managed means of accepting requests to perform actions. For this, they use ``RequestManager`` and ``RequestType``.
|
||||
``SimComponent`` objects in the simulation are decoupled from the agent training logic. However, they still need a managed means of accepting requests to perform actions. For this, they use ``RequestManager`` and ``RequestType``.
|
||||
|
||||
Just like other aspects of SimComponent, the request typess are not managed centrally for the whole simulation, but instead they are dynamically created and updated based on the nodes, links, and other components that currently exist. This was achieved in the following way:
|
||||
Just like other aspects of SimComponent, the request types are not managed centrally for the whole simulation, but instead they are dynamically created and updated based on the nodes, links, and other components that currently exist. This was achieved in the following way:
|
||||
|
||||
- API
|
||||
An ``RequestType`` contains two elements:
|
||||
A ``RequestType`` contains two elements:
|
||||
|
||||
1. ``request`` - selects which action you want to take on this ``SimComponent``. This is formatted as a list of strings such as `['network', 'node', '<node-uuid>', 'service', '<service-uuid>', 'restart']`.
|
||||
2. ``context`` - optional extra information that can be used to decide how to process the request. This is formatted as a dictionary. For example, if the request requires authentication, the context can include information about the user that initiated the request to decide if their permissions are sufficient.
|
||||
|
||||
@@ -23,8 +23,3 @@ Contents
|
||||
simulation_components/network/network
|
||||
simulation_components/system/internal_frame_processing
|
||||
simulation_components/system/software
|
||||
simulation_components/system/data_manipulation_bot
|
||||
simulation_components/system/database_client_server
|
||||
simulation_components/system/dns_client_server
|
||||
simulation_components/system/ftp_client_server
|
||||
simulation_components/system/web_browser_and_web_server_service
|
||||
|
||||
@@ -16,15 +16,17 @@ The bot is intended to simulate a malicious actor carrying out attacks like:
|
||||
- Dropping tables
|
||||
- Deleting records
|
||||
- Modifying data
|
||||
On a database server by abusing an application's trusted database connectivity.
|
||||
on a database server by abusing an application's trusted database connectivity.
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
- Create an instance and call ``configure`` to set:
|
||||
|
||||
- Target database server IP
|
||||
- Database password (if needed)
|
||||
- SQL statement payload
|
||||
|
||||
- Call ``run`` to connect and execute the statement.
|
||||
|
||||
The bot handles connecting, executing the statement, and disconnecting.
|
||||
|
||||
@@ -45,17 +45,14 @@ Key features
|
||||
^^^^^^^^^^^^
|
||||
|
||||
- Connects to the ``DatabaseService`` via the ``SoftwareManager``.
|
||||
- Handles connecting and disconnecting.
|
||||
- Executes SQL queries and retrieves result sets.
|
||||
- Handles connecting, querying, and disconnecting.
|
||||
- Provides a simple ``query`` method for running SQL.
|
||||
|
||||
|
||||
Usage
|
||||
^^^^^
|
||||
|
||||
- Initialise with server IP address and optional password.
|
||||
- Connect to the ``DatabaseService`` with ``connect``.
|
||||
- Execute SQL queries via ``query``.
|
||||
- Retrieve results in a dictionary.
|
||||
- Disconnect when finished.
|
||||
|
||||
@@ -70,6 +67,5 @@ Implementation
|
||||
|
||||
- Leverages ``SoftwareManager`` for sending payloads over the network.
|
||||
- Connect and disconnect methods manage sessions.
|
||||
- Provides easy interface for applications to query database.
|
||||
- Payloads serialised as dictionaries for transmission.
|
||||
- Extends base Application class.
|
||||
|
||||
@@ -5,9 +5,9 @@
|
||||
Simulation State
|
||||
==============
|
||||
|
||||
``SimComponent`` in the simulation have a method called ``describe_state`` which returns a dictionary of the state of the component. This is used to report pertinent data that could impact agent's actions or rewards. For instance, the name and health status of a node is reported, which can be used by a reward function to punish corrupted or compromised nodes and reward healthy nodes. Each ``SimComponent`` reports not only it's own attributes in the state but also that of its child components. I.e. a computer node will report the state of its ``FileSystem``, and the ``FileSystem`` will report the state of its files and folders. This happens by recursively calling childrens' own ``describe_state`` methods.
|
||||
``SimComponent`` objects in the simulation have a method called ``describe_state`` which return a dictionary of the state of the component. This is used to report pertinent data that could impact an agent's actions or rewards. For instance, the name and health status of a node is reported, which can be used by a reward function to punish corrupted or compromised nodes and reward healthy nodes. Each ``SimComponent`` object reports not only its own attributes in the state but also those of its child components. I.e. a computer node will report the state of its ``FileSystem`` and the ``FileSystem`` will report the state of its files and folders. This happens by recursively calling the childrens' own ``describe_state`` methods.
|
||||
|
||||
The game layer calls ``describe_state`` on the trunk ``SimComponent`` (the top-level parent) and then pass the state to the agents once per simulation step. For this reason, all ``SimComponent`` must have a ``describe_state`` method, and they must all be linked to the trunk ``SimComponent``.
|
||||
The game layer calls ``describe_state`` on the trunk ``SimComponent`` (the top-level parent) and then passes the state to the agents once per simulation step. For this reason, all ``SimComponent`` objetcs must have a ``describe_state`` method, and they must all be linked to the trunk ``SimComponent``.
|
||||
|
||||
This code snippet demonstrates how the state information is defined within the ``SimComponent`` class:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user