G-Cubed security policies

Table of contents

There are a number of cyber-security layers to consider when working with G-Cubed models distributed by McKibbin Software Group. These include:

  • The authenticity of the models that are made available
  • The privacy associated with the distributed models and usage of them
  • Cyber-security risks associated with usage of the models

Model authenticity and privacy

Model authenticity and privacy are closely tied to the platform used to develop, maintain and distribute G-Cubed models. G-Cubed models are stored in git repositories on the Github platform under the McKibbin Software Group (MSG) organisation. Only MSG staff have write access to the git repositories used to store the G-Cubed Software and to store the original G-Cubed models versions. The Github facilities are used for:

  • Source control for the G-Cubed software
  • Software and model documentation
  • Cyber-security risk scanning of the G-Cubed software and its dependencies
  • Software and model distribution to clients

Software and models that are distributed to clients are distributed from Github repositories that have been specifically created for those clients. Models are distributed from Github repositories that can only be accessed by select MSG staff (those working with the client) and by clients with Github accounts that have been granted specific access to those repositories by MSG staff.

All browser traffic to the Github servers is encrypted. All browser access to client-specific Github repositories must also be authenticated.

All git interactions with Github servers is encrypted and authenticated.

Github usage is subject to our Github usage policy.

G-Cubed model cyber-security risk profile

The cyber-security risk profile associated with a G-Cubed model reflects the implementation technologies and the specifics of how the model is deployed. Various model deployment approaches are available to clients depending upon their security requirements. Details of the risks and ways of mitigating them are set out below.

G-Cubed model technologies

G-Cubed is implemented using Python 3 and is distributed to clients as a Python package. It requires a suitable Python interpreter to execute. It also depends on a number of packages that extend core Python functionality. The Python interpreter, the G-Cubed Python Package and the various dependencies are all provided within a Python virtual environment that is associated with a specific G-Cubed model build.

The G-Cubed Python package is made available from a private Github repository owned by the McKibbin Software Group. In the default distribution model, the Python interpreter and the Python package dependencies are sourced from the Internet when the Python virtual environment is being configured for a G-Cubed model. This approach can be tailored to meet client requirements to enforce, for example, sourcing of the Python Interpreter or dependency packages from locations specified by the client.

Python G-Cubed

Python G-Cubed is implemented in Python version 3 and requires Python 3.10 or later to run. It is distributed to clients as a source Python package. The package is a “WHL” file, a compressed archive of all the Python modules that make up the Python G-Cubed software. Users of G-Cubed models require a full implementation of Python 3.10 or later. The risks associated with access to Python can be mitigated in various ways based upon how G-Cubed models are installed (typically in a devcontainer and on a local computer, a remote computer within client infrastructure, or on a remote computer in the cloud, outside of client infrastructure).

The G-Cubed Python package is distributed to clients as source code and so comprehensive code scanning and review is possible for clients as part of implementing their own cyber security policies.

Python interpreter

When establishing the Python virtual environment for a G-Cubed model, by default the Python interpreter is sourced from Microsoft. This can be tailored to client requirements.

Package dependencies

Python G-Cubed minimises the number of other Python packages that it depends upon. The direct package dependencies are limited to the following:

pandas -> numpy, python-dateutil, pytz, tzdata
scipy -> numpy
numpy -> no dependencies
regex -> no dependencies
jinja2 -> markupsafe

The indirect Python package dependencies are:

pytz -> no dependencies
tzdata -> no dependencies
python-dateutil -> six
six -> no dependencies
markupsafe -> no dependencies

None of these packages involve network access functionality.

All of these packages are available in the Python Package Index (PyPI).

At the client’s discretion, G-Cubed models can be installed to use a private archive of Python packages (e.g. DevPI and Artifactory). This can mitigate the risks (e.g. package typosquatting) associated with uncontrolled access to the Python Package Index. Other bespoke solutions can also be supported, depending on client requirements in relation to the level of control required over Python packages, where they are sourced from and the versions of them that permitted to be used.

SYM processor

The equations in a G-Cubed model are expressed in SYM files. They are translated into the data required to run the model using a SYM processor, software implemented in the C programming language and maintained in a Github repository that is readable by the general public but writeable only by McKibbin Software Group.

The SYM processor is compiled from source and made available as an executable whenever a new G-Cubed model is installed. Because the SYM processor is compiled from source, the devcontainer includes the standard C compilation tools including gcc, byacc, and make.

The SYM processor is run from the terminal in VS Code.

The source code for the SYM processor is available for review. It makes no use of code associated with network operations. It relies on no external libraries. It is subject to weekly Github vulnerability scans.

G-Cubed platform

G-Cubed models are typically distributed within a devcontainer and interacted with using Microsoft’s Visual Studio Code IDE.

Devcontainers

Instructions for setting up G-Cubed devcontainers in various ways are provided in the online documentation

Depending on client infrastructure and security policies, devcontainers can be run:

  • as Github codespaces (running the G-Cubed model on a virtual machine hosted by Github);
  • using Docker on a linux server installed on the client network;
  • using Docker on a virtualised linux server; and
  • using Docker on the user’s local computer (this can run directly in a MacOS or Microsoft Windows WSL virtual machine context, or within a Linux virtual machine).

Running G-Cubed models using Python in a devcontainer instead of as software directly installed on the operating system provides several security benefits:

Isolation from the Host System

A devcontainer runs in a containerised environment, separate from the host operating system. This isolation prevents Python scripts or malicious packages from directly interacting with the host system’s files, processes, or other sensitive resources.

A Linux-based host operating system can furthermore itself run in a virtualised environment (either in a WSL context or as a separate virtual machine hosted by, for example, Hyper-V from Microsoft, VMware, or VirtualBox from Oracle) further isolating the processes running in the G-Cubed environment.

Controlled Environment

Devcontainers use predefined configurations (like Dockerfile or devcontainer.json) to build a consistent and minimal environment for development. Developers can explicitly define only the required dependencies, reducing the attack surface for vulnerabilities. If a vulnerability is in fact discovered in a package then it is inherently contained and does not affect the host system, and application of updates/upgrades/remediation is easily applied.

Immutable Environment

Container environments are typically stateless and can be rebuilt easily. Any malicious modifications or unintended changes in the environment can be undone by rebuilding the container. This ensures a clean state every time the container is restarted or rebuilt. If a script attempts to persist harmful changes, rebuilding the devcontainer restores it to a safe configuration.

Reduced Privilege Model

Containers run with limited privileges by default. Even if a Python script exploits a vulnerability, it is confined to the container and does not have administrative access to the host system. Using features like rootless containers further reduces the impact of potential exploits. Even if a vulnerability in Python or a library is exploited, the attacker cannot gain elevated privileges on the host.

Easier Dependency Management

Devcontainers allow specifying Python versions and dependencies without affecting the host system. This prevents conflicts or inadvertent upgrades/downgrades of Python or libraries on the host. Vulnerabilities or misconfigurations in dependencies are limited to the container, not the host.

Network Access Control

Containers can be configured with strict networking rules, such as limiting external access or blocking certain ports. This prevents malicious Python scripts from making unauthorised network connections. A malicious Python script then cannot send sensitive data to an attacker over the network.

Reproducibility

Using devcontainers ensures that the environment is reproducible across systems. This minimises the risk of “it works on my machine” scenarios, where environment-specific security issues might go unnoticed.

Monitoring and Auditing

Containers provide tools for monitoring and logging activity within the container. Suspicious behaviour (e.g., accessing restricted files, unusual network activity) can be logged and analysed. This is more challenging to achieve with a non-containerised Python environment installed on the host.

Quick Response to Vulnerabilities

Containers can be rebuilt with updated configurations or patched versions of Python and dependencies without requiring downtime on the host system. Thus, a security patch can be applied to a devcontainer without risking disruption to the host or other projects.

The G-Cubed Devcontainer

The base Docker images used to construct the G-Cubed devcontainer are retrieved from the Microsoft Artifact Registry. The images used bundle the underlying operating system, utilities, tools, user setup and python interpreter. mcr.microsoft.com/devcontainers/python:1-3.12

Visual Studio Code

Microsoft Visual Studio Code (VS Code) can be set up in various ways, either installed on a user’s local computer or made available via a VS Code server hosted remotely and exposed to the user via their web browser (see, for example, the VS Code interface to Github Codespaces).

Visual Studio Code allows for installation of extension packages. G-Cubed models make use of a number of these extension packages to enhance the user experience when working with CSV data files and when editing and running Python scripts.

The VS Code extensions that are required as part of the devcontainer build are:

  • GCubed VS Code Python venv switcher (by McKibbin Software Group) for managing Python virtual environments across model builds within the one devcontainer
  • Dev Containers (by Microsoft)
  • Python (by Microsoft)
  • Python Debugger (by Microsoft)
  • Pylance (by Microsoft)

Optional but recommended extensions include:

These VS Code extensions are installed by default in the standard customer image, however can be customised to suit client requirements.

Typically, users are able to install additional extensions that meeting their own requirements. This can be controlled by clients and responsibility for such controls lies with clients.

G-Cubed VS Code Python Environment Switcher

One challenge often faced in Python development environments, and moreso in a modelling environment such as this one, is managing a cohesive set of dependencies including those on the McKibbin Software Group G-Cubed Python library utilised by the Python code executing the modelling functions. A partial solution to this is provided by the Python virtual environment system. This is, however, insufficient by itself as it requires informed manual intervention in order to correctly set up and administer throughout the development lifecycle. Furthermore switching from one environment to another is also a manual process and is somewhat difficult to track and manage appropriately.

McKibbin Software Group has therefore developed a solution that operates within the devcontainer context to automatically handle Python environment switching for G-Cubed economic modeling projects. It ensures the correct Python dependencies including the G-Cubed Code library build are available and active for both editing and execution of economic models.

The solution is comprised of both a VS Code extension and a Python library that work in tandem with the modelling software to ensure the correct prerequisites are available at all times.

Key Features

  • Automatically responds to virtual environment change requests from G-Cubed scripts
  • Seamlessly switches VS Code’s Python interpreter to the requested environment
  • Supports both absolute and relative Python interpreter paths
  • Integrates with the G-Cubed build system to ensure consistent development environments

How It Works

When a G-Cubed economic model script runs, it can request a specific G-Cubed Code build version. The Python component of this system will:

  • Check if the requested build’s virtual environment exists
  • Create and set up the environment if necessary
  • Send a request via secure local Unix Socket to this VS Code extension to activate the appropriate Python interpreter

This ensures that the correct dependencies are available for both code completion/linting and runtime execution.

Security Model

All operations occur within the container environment. Messaging between the Python component and VS Code Extension is via secure Unix Sockets that operate purely within the container.

On creation of a new Python virtual environment the required version of the G-Cubed Code library is retrieved by default from the McKibbin Software Group private G-Cubed Code repository. The source of the repository satisfying these requirements can be customised if required.

Installation of this library will also retrieve additional dependencies as described above in Package Dependencies.

Source code dependencies are pinned and source code is available for inspection upon request.