Beta release v0.2

CHANGELOG.md

@@ -1,3 +1,36 @@
+# 0.2 (2024-07-19)
+
+## Added
+
+- Support for parsing Common Criteria 2022 release (CC2022R1)
+- Dedicated object-oriented data structures to the CCT module to handle CC 2022
+- Graphical user interface (GUI) in the form of a web application
+- GUIs for the CCT browser and CC evaluation laboratory submodules
+- C5-DEC DocEngine publishing feature based on Quarto for both generic report and ETR generation
+- Dedicated data structures and algorithms for handling evaluation checklist creation in a structured format, e.g., csv and spreadsheets
+- Feature to create CEM evaluation checklist spreadsheets that can be parsed by the DocEngine (exposed via both the CLI and the GUI)
+- Dedicated C5-DEC publish function exposed via the CLI as a wrapper, complementing and improving the underlying Doorstop-based mechanism to publish technical specifications in HTML and Markdown
+- Docker-based deployment solution for end-users, along with build and executable scripts
+- test reports to the technical specifications (`tra` and `trb` under `docs`).
+
+## Fixed
+
+- Bugs in the CCT module, largely rooted in inconsistent data structure tracking and life cycle management, e.g., CC XML tree loaded several times
+- Bugs in the CLI checklist creation function
+- Errors in the technical specifications encodings, now stored under `docs/specs`
+
+## Modified
+
+- The CCT module to add support for setting parameters for the ETR CLI handler and CC release selection via user-accessible YAML configuration file
+- Heavily refactored and improved the CCT module, e.g., use of constants to handle paths, folders, use of `os.path.join` to ensure cross-platform path management
+- The specifications folder name (`reqs` to `specs`)
+- Dev container Docker file to include `pipx`, git repo creation and `poetry` installation
+- technical specifications under the `docs` folder to update all schematics, requirements and test cases
+
+## Deleted
+
+- Rendered schematics stored under `docs/sdd/images`
+
 # 0.1 (2023-12-01)
 
 - Initial release of C5-DEC CAD

Dockerfile

@@ -11,41 +11,48 @@ ENV MY_ENV=${MY_ENV} \
   PIP_DEFAULT_TIMEOUT=100 \
   POETRY_VERSION=1.5.0
 
-ENV user=alab
+ENV user=root
 ENV c5folder=c5dec
 
 # Update and install depencencies
 RUN apt update --fix-missing
 RUN apt-get install -y git python3-pip graphviz
 
-# Create a non-root user
-RUN useradd -ms /bin/bash ${user} && echo '${user} ALL=(ALL) NOPASSWD:ALL' >>/etc/sudoers
+# Install Doorstop
+RUN python3 -m pip install pipx
+RUN python3 -m pipx ensurepath
+
+RUN pipx install doorstop==3.0b10
 
 # Add location where pip is installed to the PATH variable
 ENV PATH="/home/${user}/.local/bin:${PATH}"
 
 # Copy the files and install the python environment as user alab 
-USER ${user} 
-# RUN pip3 install pipenv
 RUN pip3 install "poetry==$POETRY_VERSION"
 
-WORKDIR /home/${user}/${c5dec}
-COPY poetry.lock pyproject.toml /home/${user}/${c5dec}/
+WORKDIR /home/${user}/${c5folder}
+COPY poetry.lock pyproject.toml /home/${user}/${c5folder}/
+
+# Create a git repository (needed by Doorstop) at the project root
+RUN git init .
 
 # Project initialization
 RUN poetry install
 
 # Creating folders, and files for a project
-COPY . /home/${user}/${c5dec}
+COPY . /home/${user}/${c5folder}
+
+# Switch to project folder
+WORKDIR /home/${user}/${c5folder}/${c5folder}
 
-# Install python virtual environment for the project
-WORKDIR /home/${user}/${c5dec}
-# RUN pipenv install
+# RUN poetry config virtualenvs.create false
+
+RUN poetry install
 
 # Clean up unnecessary packages
-USER root
 RUN apt-get autoremove -y && apt-get autoclean -y
 
-# Set the container starting point, running the project as the user
-USER ${user} 
-CMD ["poetry", "shell"]
+# Expose port for the GUI (web app)
+EXPOSE 5432
+
+ENTRYPOINT ["poetry", "run", "c5dec"]

build-c5dec.sh

@@ -0,0 +1,3 @@
+#!/bin/bash
+echo Building C5-DEC CAD image...
+docker build -t c5dec .

c5dec.sh

@@ -0,0 +1,9 @@
+#!/bin/bash
+echo Starting C5-DEC CAD...
+
+if [ "$#" -lt 1 ]
+then
+    docker run --rm -it -v ./c5dec:/home/root/c5dec/c5dec c5dec -h
+else
+    docker run --rm -it -v ./c5dec:/home/root/c5dec/c5dec -p 5432:5432 c5dec "$@"
+fi

c5dec/assets/c5dec_params.yml

@@ -0,0 +1,10 @@
+etr:
+  eval-wu-id: "WU-ID"
+  eval-file-name: "etr-eval-checklist"
+  # eval-file-name: "<your-checklist-filename>"
+  eval-wu-sheet: "WU"
+  eval-awi-sheet: "AWI"
+
+cc:
+  # release: "2022R1"
+  release: "3R5"

c5dec/assets/config.json

@@ -1,6 +1,6 @@
-{
-    "width": 100,
-    "height": 100,
-    "language": "en",
-    "title": "C5-DEC CAD"
+{
+    "width": 100,
+    "height": 100,
+    "language": "en",
+    "title": "C5-DEC CAD"
 }

c5dec/assets/database/KnowledgeBase/Assumption.md

@@ -1,32 +1,32 @@
-# Assumption
-
-**Acronym:** None
-
-Security rests on assumptions specific to the type of security required and the environement in which it is to be employed. Assumptions are treated as axioms, i.e., they are taken to be true, to serve as a premise for further reasoning and arguments. Assumptions provide a grounding, describing expected conditions in the [operational environment](TOEOperationalEnvironment.md) which are presumed to be true, and under which the [Target of Evaluation (TOE)](./TargetofEvaluation.md) will operate securely. These are essential in the construction of a [Security Problem Definition (SPD)](./SecurityProblemdefinition.md) and subsequently the entire security posture of the TOE.
-
-In the world of CC, assumptions are categorized based on aspects such as physical, personnel, and connectivity of the operational environment. However, these assumptions are not scrutinized or tested during the evaluation phase as they are regarded as fundamental truths, providing a reliable basis upon which the [TOE's security functionality](./TOESecurityFunctionality.md) is conceived and designed. Consequently, if a TOE is placed in an environment that does not adhere to these assumptions, its security functionality and reliability can be compromised.
-
-## Practical Guidance
-
-Navigating through the landscape of crafting and implementing assumptions within CC involves being mindful of their dual utility and strategic integration. Assumptions in CC are leveraged to:
-
-- **Dictate Environmental Controls**: Highlight specific controls or types of controls that are the responsibility of the operational environment and not the TOE.
-- **Dismiss Irrelevant Threats**: Specify threats or types of threats that can be disregarded, asserting that they either do not exist or are not pertinent in the context of the posited operational environment.
-
-### Identifying and Formulating Assumptions:
-- **Operational Insights:** Derive assumptions from an in-depth understanding of the physical, personnel, and connectivity aspects of the operational environment.
-- **Policy Alignment:** Shape assumptions that are in sync with organizational policies and user behaviors.
-- **Regulatory Adherence:** Ensure that assumptions are congruent with legal and regulatory requirements.
-- **Industry Benchmarking:** Evaluate industry best practices and historical incident data to extract relevant assumptions.
-- **Articulation into Security Objectives:** Ensure that assumptions are translated into actionable [security objective](./SecurityObjective.md) in the [Security Target (ST)](./SecurityTarget.md) or [Protection Profile (PP)](./ProtectionProfile.md). These security objectives should offer a clear, solution-oriented representation, elucidating how the TOE's operational environment will concretely upheld the assumptions.
-
-## Additional Resources
-
-- **ISO/IEC TR 15446:** A Guide for the production of Protection Profiles and Security Targets.
-
-## Related Articles
-
-- [Deriving the Security Problem Definition](./SecurityProblemdefinition.md)
-- [Identifying Threats](./Threat.md)
-- [Deriving Security Objectives](./SecurityObjectives.md)
+# Assumption
+
+**Acronym:** None
+
+Security rests on assumptions specific to the type of security required and the environement in which it is to be employed. Assumptions are treated as axioms, i.e., they are taken to be true, to serve as a premise for further reasoning and arguments. Assumptions provide a grounding, describing expected conditions in the [operational environment](TOEOperationalEnvironment.md) which are presumed to be true, and under which the [Target of Evaluation (TOE)](./TargetofEvaluation.md) will operate securely. These are essential in the construction of a [Security Problem Definition (SPD)](./SecurityProblemdefinition.md) and subsequently the entire security posture of the TOE.
+
+In the world of CC, assumptions are categorized based on aspects such as physical, personnel, and connectivity of the operational environment. However, these assumptions are not scrutinized or tested during the evaluation phase as they are regarded as fundamental truths, providing a reliable basis upon which the [TOE's security functionality](./TOESecurityFunctionality.md) is conceived and designed. Consequently, if a TOE is placed in an environment that does not adhere to these assumptions, its security functionality and reliability can be compromised.
+
+## Practical Guidance
+
+Navigating through the landscape of crafting and implementing assumptions within CC involves being mindful of their dual utility and strategic integration. Assumptions in CC are leveraged to:
+
+- **Dictate Environmental Controls**: Highlight specific controls or types of controls that are the responsibility of the operational environment and not the TOE.
+- **Dismiss Irrelevant Threats**: Specify threats or types of threats that can be disregarded, asserting that they either do not exist or are not pertinent in the context of the posited operational environment.
+
+### Identifying and Formulating Assumptions:
+- **Operational Insights:** Derive assumptions from an in-depth understanding of the physical, personnel, and connectivity aspects of the operational environment.
+- **Policy Alignment:** Shape assumptions that are in sync with organizational policies and user behaviors.
+- **Regulatory Adherence:** Ensure that assumptions are congruent with legal and regulatory requirements.
+- **Industry Benchmarking:** Evaluate industry best practices and historical incident data to extract relevant assumptions.
+- **Articulation into Security Objectives:** Ensure that assumptions are translated into actionable [security objective](./SecurityObjective.md) in the [Security Target (ST)](./SecurityTarget.md) or [Protection Profile (PP)](./ProtectionProfile.md). These security objectives should offer a clear, solution-oriented representation, elucidating how the TOE's operational environment will concretely upheld the assumptions.
+
+## Additional Resources
+
+- **ISO/IEC TR 15446:** A Guide for the production of Protection Profiles and Security Targets.
+
+## Related Articles
+
+- [Deriving the Security Problem Definition](./SecurityProblemdefinition.md)
+- [Identifying Threats](./Threat.md)
+- [Deriving Security Objectives](./SecurityObjectives.md)
 - [Understanding the Operational Environment (OE)](./TOEOperationalEnvironment.md)

c5dec/assets/database/KnowledgeBase/CompositeEvaluation.md

@@ -1,19 +1,19 @@
----
-Last Updated: October 4, 2023
-Relevant CC Version: CC 2022
-Tags: [Composite Evaluation]
----
-
-# Composite Evaluation
-
-**Acronym:** None
-
-For IT products that are composed of several independent, already evaluated product components the composed security assurance can be evaluated. The composition of assurance is dependent upon:
-- Type of composition, it is differentiated between layered, network or bi-directional, and embedded compositions.
-- Security function policies, and [OSPs](./OrganizationalSecurityPolicy.md) that the component evaluation was based on:
-- Claimed security assurance, for example the [assurance level](./EvaluationAssuranceLevel.md)
-- The overall security policies for the entire product.
-
-The CC only explicitly addresses the layered composition model. For bi-directional and embedded composition models [extended components](./ExtendedComponentDefinition.md) and [evaluation methods](./EvaluationMethods.md) have to be defined.
-
-For the evaluation of layered [TOE](./TargetofEvaluation.md) compositions the CC defined the Composition class ACO in CC Part 3. In the layered composition two already evaluated TOEs are assumed one of which is defined to be the base TOE while the other is considered to be the dependent TOE. The evaluation of such a composed TOE consists of evaluating the interaction between both TOEs. CC Part 5 provides pre-defined Composition Assurance Packages that may be used for determining the composed TOE’s assurance level. The COMP related assurance families specified in CC Part 3 for the ADV, ALC, ASE, ATE and AVA classes provide evaluation criteria pertinent to composite products using this layered model. 
+---
+Last Updated: October 4, 2023
+Relevant CC Version: CC 2022
+Tags: [Composite Evaluation]
+---
+
+# Composite Evaluation
+
+**Acronym:** None
+
+For IT products that are composed of several independent, already evaluated product components the composed security assurance can be evaluated. The composition of assurance is dependent upon:
+- Type of composition, it is differentiated between layered, network or bi-directional, and embedded compositions.
+- Security function policies, and [OSPs](./OrganizationalSecurityPolicy.md) that the component evaluation was based on:
+- Claimed security assurance, for example the [assurance level](./EvaluationAssuranceLevel.md)
+- The overall security policies for the entire product.
+
+The CC only explicitly addresses the layered composition model. For bi-directional and embedded composition models [extended components](./ExtendedComponentDefinition.md) and [evaluation methods](./EvaluationMethods.md) have to be defined.
+
+For the evaluation of layered [TOE](./TargetofEvaluation.md) compositions the CC defined the Composition class ACO in CC Part 3. In the layered composition two already evaluated TOEs are assumed one of which is defined to be the base TOE while the other is considered to be the dependent TOE. The evaluation of such a composed TOE consists of evaluating the interaction between both TOEs. CC Part 5 provides pre-defined Composition Assurance Packages that may be used for determining the composed TOE’s assurance level. The COMP related assurance families specified in CC Part 3 for the ADV, ALC, ASE, ATE and AVA classes provide evaluation criteria pertinent to composite products using this layered model.