Presentation of the security principles in WAPT¶

Date	Oct 28, 2024
Written by	Hubert TOUVET, Vincent Cardon
Applicable for WAPT	>= 2.3.0.13180
Version of the Document	2.3.0.0-0
Git hash	b24964be6be4421227960d0415b2186ee469b746

Here are documented the advanced security principles included in WAPT.

The reading of this portion of the documentation is not essential for your daily usage of WAPT; it is however recommended for you to better understand some architectural choices made by the developers of the software.

Preamble and definitions¶

Attention

The WAPT service operates as a privileged system account.

Technical environment for product operation¶

Scope of the Target of Evaluation¶

The assessment covers:

a WAPT Server and its repository (waptserver and waptrepo);
a WAPT Agent, with waptexit enabled (wapttray disabled);
the WAPT Console management console;
network communications between these components.
secure management of WAPT packets:
- secure deployment of one or more WAPT packages;
- secure deployment of a WAPT package update;
- uninstalling a WAPT package.

Secure management is based on the use of differentiated certificates between the deployment manager (standard X509 certificate) and the WAPT package designer (X509 certificate with Code-Signing attribute).

The operations that are part of the TOE’s external perimeter, and therefore not part of the scope of the evaluation, are:

Writing the WAPT script in Python, and supplying all the other files needed to create the WAPT package.
The manages private keys for signing packets, and manages and revokes SSL certificates.

Evaluation platform¶

The assessment will cover:

WAPT Server (waptserver and waptrepo) installed on up-to-date Rocky Linux 9 (RedHat 9 clone) with SELinux and firewalld enabled.
A WAPT Agent installed on Windows 10.
The management console (WAPT Console) installed on Windows 10.

The console is connected to the WAPT Server via a local network. This console-hosting workstation may also have access to an uncontrolled network, through which it obtains packages (software or software updates) that the Business Administrator then wishes to integrate into his private WAPT repository.

The evaluation platform’s workstations and administration console are linked to an Active Directory authentication domain.

WAPT operation on Linux and macOS client platforms (agent, administration console) will not be evaluated.

The HTTPS certificate for the Nginx server used in the evaluation is a self-signed certificate generated during WAPT installation. It is deployed at the same time as the agents and is pinned to the WAPT Server certificate.

List of third-party components integrated into WAPT (COTS)¶

Third-party components integrated into the WAPT Server waptserver¶
Conponent	Version	hashupdated to the latest version	Maintained	Origin
Nginx	1.20.1	Yes (distribution)	Yes (distribution)	RHEL9.1 distribution
nginx-mod-http-auth-spnego	1.20.1	Yes (upstream)	Yes (upstream)	compiled from nginx and Nginx SPNego sources (hash git bd4e8c3)
PosgreSQL	13.7	Yes (distribution)	Yes (distribution)	RHEL9.1 distribution
python 3.8	3.8.18	Yes (upstream branch 3.8)	Yes (upstream branch 3.8)	compiled from Python 3.8 sources
kerberos MIT	1.19.1	Yes (distribution)	Yes (distribution)	RHEL9.1 distribution
OpenSSL for python and Freepascal compiled modules	3.1.3	Yes (upstream)	Yes (upstream)	Compiled from OpenSSL sources
Python modules	see below for list			installed by pip command

Third-party components integrated into the WAPT Agent waptservice¶
Conponent	Version	hashupdated to the latest version	Maintained	Origin
python 3.8	3.8.18	Yes (upstream branch 3.8)	Yes (upstream branch 3.8)	compiled from Python 3.8 sources
OpenSSL for python and Freepascal compiled modules	3.1.3	Yes (upstream)	Yes (upstream)	Compiled from OpenSSL sources
Python modules	see below for list			installed by pip command

Third-party components integrated into the WAPT-specific binaries: waptconsole, wapt-get, waptexit, wapttray, waptdeploy, waptlicences¶
Conponent	Version	hashupdated to the latest version	Maintained	Origin
lazarus 2.3	2.3 fixed tag_2_3	Yes (upstream)	Yes (upstream)	Lazarus sources
freepascal 3.2.3	3.2.3 fixed tag_3_2	Yes (upstream)	Yes (upstream)	FPC sources
mormot2	2.1 Git Sha1 c3a060ea35e380a7e5f26ec6e23c5005a5d79f36	Yes (upstream)	Yes (upstream)	mORMot sources

Python agent and server modules¶

Python modules are imported in source form from Pypi.org and compiled in wheel form and stored on an internal pip repository. The WAPT build farm does not provide a direct connection to the Internet for Python module installations.

The “Target platform” column indicates wheel packages that are only installed on certain target architectures.

Python modules common to Agents and WAPT Server¶
Python modules common to Agents and Server	Version	Target platform
arpy	2.2.0
babel	2.9.1
beautifulsoup4	4.11.2
certified	2023.7.22
cffi	1.15.1
chardet	4.0.0
click	8.1.3
configparser	5.0.2
cryptography	41.0.4
decorator	5.1.1
distro	1.5.0
dnspython	1.16.0	sys_platform == ‘linux’ or sys_platform == ‘darwin’
flask	2.3.2
future	0.18.3
gssapi	1.8.2	sys_platform == ‘linux’ or sys_platform == ‘darwin’
idna	2.10
iniparse	0.5
ipaddress	1.0.23
itsdangerous	2.1.2
jinja2	3.1.2
kerberos	1.3.1	sys_platform == ‘linux’ or sys_platform == ‘darwin’
krb5	0.4.1	sys_platform == “linux” or sys_platform == ‘darwin’
ldap3	2.9
markupsafe	2.1.3
netifaces	0.11.0
packaging	20.9	sys_platform == ‘darwin’
psutil	5.8.0
pyad	0.6.0	sys_platform == ‘win32’
pyasn1	0.4.8
pycparser	2.21
py-cpuinfo	8.0.0	sys_platform == ‘linux’ or sys_platform == ‘darwin’
pyedid	1.0.2
pykerberos	1.2.4	sys_platform == ‘linux’ or sys_platform == ‘darwin’
pyobjc	8.5	sys_platform == ‘darwin’
pyobjc-core	8.5	sys_platform == ‘darwin’
pyobjc-framework-cocoa	8.5	sys_platform == ‘darwin’
pyobjc-framework-quartz	8.5	sys_platform == ‘darwin’
pyopenssl	23.2.0
pyparsing	2.4.7	sys_platform == ‘linux’ or sys_platform == ‘darwin’
pyspnego	0.7.0
python-engineio	4.7.1
python-pam	1.8.4	sys_platform == ‘linux’ or sys_platform == ‘darwin’
python-socketio	4.6.1
pytz	2021.1
pywin32	301	sys_platform == ‘win32’
requests	2.31.0
requests-kerberos	0.14.0
rpmfile	1.0.8
setproctitle	1.2.2
six	1.16.0
smmap	4.0.0
typing	3.7.4.3
ujson	5.5.0
uptime	3.0.1
urllib3	2.0.4
waitress	2.1.2
wakeonlan	2.0.1
websocket-client	1.1.0
werkzeug	2.3.6
winkerberos	0.8.0	sys_platform == ‘win32’
winshell	0.6	sys_platform == ‘win32’
winsys	0.5.2	sys_platform == ‘win32’
wmi	1.5.1	sys_platform == ‘win32’

Python modules specific to the WAPT Server¶
Server-specific Python modules	Version
dnspython	1.16.0
eventlet	0.31.0
flask-Babel	2.0.0
flask-Login	0.5.0
flask-SocketIO	4.3.2
greenlet	1.1.0
huey	2.4.3
monotonic	1.6
passlib	1.7.4
peewee	3.14.4
pefile	2022.5.30
psycopg2	2.9.1
psycopg2-binary	2.9.1
psycogreen	1.0.2

Specific patches¶

Python modules specific to the WAPT Server¶
Python module	Version
description	iniparse
0.5	The REM keyword (remark) must be followed by a space to be a remark.
certified	2023.7.22
Importing root certificates from system stores for Windows and macOS	cryptography
41.0.4	Disable loading of legacy algorithms.

Vulnerabilities identified¶

The latest version of the kerberos python module is affected by vulnerability CVE-2015-3206.

The checkPassword function in python-kerberos does not authenticate the KDC it attempts to communicate with, which allows remote attackers to cause a denial of service (bad response), or have other unspecified impact by performing a man-in-the-middle attack.

This function is not used in the WAPT product.

Sensitive assets to be protected¶

Preamble and definitions¶

Please note: The WAPT service operates as a privileged system account.

Perimeter to be secured¶

B1 WAPT packages¶

The WAPT packages to be deployed are one of the main sensitive assets to be protected. They must be protected in terms of availability on the repository, and integrity during deployment.

Security needs: integrity, authenticity, availability

B2 Actions triggered on the client workstation from the console¶

Actions are sent to agents from the console (via a signed json payload). These actions can be updating the workstation, deploying/uninstalling a particular package, rebooting the machines…. These actions are sensitive assets that need to be protected in terms of integrity and authenticity.

Need for security: integrity, authenticity

B3. Cryptographic hardware¶

Cryptographic material is a sensitive asset and must be protected. It serves as authentication data, and is used for encryption.

Security requirements: integrity, confidentiality, availability

There are several cryptographic devices in a WAPT deployment:

server certificate for https communication.
the server’s private key for https communication.
WAPT Agent certificate: certificate signed by the WAPT Server following CSR by the authenticated workstation.
the workstation’s private key corresponding to the WAPT Agent’s certificate.
the WAPT administrator’s code-signing certificate.
the WAPT administrator’s private key, corresponding to the WAPT administrator’s code-signing certificate.
the WAPT administrator’s standard non-code-signing certificate.
the WAPT administrator’s private key corresponding to the WAPT administrator’s non-code-signing certificate.
WAPT administrator’s password to connect to the WAPT Server.
the WAPT administrator’s kerberos token (service ticket for the WAPT Server).

B4. Communications¶

Communications between the central server and the agents, and between the console and the server, are a sensitive asset and must be protected.

Security needs: integrity, confidentiality, authenticity.

B5. Inventory data¶

Information on the deployment status of packages, as well as the hardware and software configuration of client workstations, is a sensitive asset and must be protected.

Security needs: integrity, confidentiality.

B6. The newspapers¶

The logs generated by WAPT on the central server and agents are a sensitive asset and must be protected.

Security needs: integrity, availability, confidentiality.

B7. Configuration values¶

Server configuration values (https server keys, database access configuration, server authentication configuration) are a sensitive asset and must be protected.

Security needs: integrity, confidentiality, availability.

B8. WAPT executables installed¶

WAPT executables installed on managed client workstations (wapt directory contents including binaries, dlls, configuration files and database) are a sensitive asset and must be protected.

Need for security: integrity.

B9. Host system¶

The host systems, which here include the server hosting the WAPT Server, the administration workstations hosting the administration console and the user workstations equipped with the WAPT Agent, are a sensitive asset and must be protected.

Security requirements: integrity, confidentiality, availability.

Environmental measures¶

A WAPT operator will have to choose and follow a suitable methodology for:

Ensure safe downloading of all other files used to make up a WAPT package.
Write the python setup.py script for installing a WAPT package in such a way as to avoid any exploitable security or confidentiality holes.
Securely manage private keys for signing packets.
Securely manage Certification and Revocation Authorities for SSL and HTTPS certificates.

Description of typical WAPT users¶

The following roles must be understood in order to evaluate the security principles present in WAPT:

End user¶

A User is an individual equipped with a machine running the WAPT Agent. He can update his machine according to the settings defined by the deployment manager.

Professional administrator: deployment manager¶

A Deployment Manager is an individual who can sign packages NOT containing python code (usually group, unit and host packages) and upload them to the main repository. He defines deployment profiles (a set of WPAT packages assigned to workstations). He is identified by the absence of the Code-Signing attribute in his certificate.

Professional administrator: package developer¶

A Package Developer is an individual who can sign packages, whether or not the packages CONTAIN python code, and upload them to the main repository. The package developer is identified by the Code-Signing attribute of his certificate.

Job administrator: SuperAdmin¶

The SuperAdmin is an individual with full rights within WAPT. In particular, he defines ACLs and creates other administrators.

System administrator: Local administrator¶

A Local Administrator is a user with local administration rights on WAPT-equipped workstations. It is used for initial WAPT Agent deployment, if required.

Description of WAPT operating environment assumptions¶

The following assumptions about the WAPT operating environment must be considered:

H1. WAPT Business Administrators are trained¶

Business administrators are trusted and trained in the use of WAPT. In particular, they must ensure that their identifiers and security keys remain secret and protected.

H2. WAPT-subjacent systems are healthy¶

The operating systems on which WAPT Agents run implement adequate protection mechanisms (containment, access control, etc.) parameterized and configured according to best practices.

Operating systems are up to date with patches in force at the time of installation, and are sound and free of viruses, Trojans, etc.

H3. The binaries required to run WAPT are intact¶

All the libraries and tools required to install WAPT are considered safe.

H4. WAPT packages are securely constructed¶

It is the responsibility of the Administrator to ensure that files intended for inclusion in WAPT packages come from secure sources, and are free from viruses, Trojan horses, etc., in particular.

Administrators are also responsible for writing and incorporating safe setup.py scripts into WAPT packages.

H5. Client Users are not Local Administrators¶

A User does not have administrative rights to his or her workstation. Otherwise, the User is considered a Local Administrator.

In particular, the User does not have write access to the WAPT client installation directory.

H6. Local administrators of client workstations are trained¶

The Local Administrator of a client workstation must be trained in WAPT operation, or else must not modify the installation files in the WAPT installation folder.

H7. The WAPT Server is for dedicated use only.¶

The server on which WAPT is installed is dedicated exclusively to WAPT.

H8. Passwords comply with minimum security criteria¶

Passwords used by Administrators are supposed to comply with ANSSI minimum security criteria.

H9. The Windows environment is configured according to best practices¶

The underlying environment is configured according to the best practices described in the ANSSI workstation hardening guide.

Threat description¶

Threatening agents to be considered for safety assessment include:

Unauthorized entities: a human attacker or an entity that interacts with WAPT but does not have legitimate access to it.
Malicious end-user: an end-user with access to a workstation on which the WAPT Agent is installed, seeking to elevate his or her privileges on the workstation.

Business Administrators and Local Administrators are not considered as attackers.

The threats to the WAPT sensitive assets defined above are as follows:

T01. Installation of a corrupt package¶

This threat corresponds to an attacker who manages to use a component of the WAPT Agent to deploy a corrupted packet, bypassing the security normally provided by the packet signature.

T02. Alteration of configuration values¶

This threat corresponds to an attacker succeeding in modifying or deleting the settings of a WAPT element defined by a legitimate WAPT administrator.

T03. Illegitimate access¶

This threat corresponds to an attacker succeeding in recovering an Administrator’s authentication data, bypassing the authentication mechanism in order to access or alter a sensitive asset stored on the server. It also corresponds to an attacker who could impersonate a WAPT Agent.

T04. Network listening¶

This threat corresponds to an attacker succeeding in intercepting and gaining knowledge of network communications between agents and the server hosting WAPT.

T05. Network traffic alteration (Man In the Middle type)¶

This threat corresponds to an attacker succeeding in modifying network communications between agents and the server hosting WAPT, or network communications between the console and the WAPT Server.

T06. Log alteration¶

This threat corresponds to an attacker succeeding in corrupting the logs sent back from the agents and stored in the database.

T07. Cryptographic hardware recovery¶

This threat corresponds to an attacker succeeding in recovering or gaining knowledge of cryptographic keys.

T08. Alteration of cryptographic hardware¶

This threat corresponds to an attacker illegitimately corrupting cryptographic keys.

T09. Denial of service¶

This threat corresponds to an attacker affecting the availability of sensitive assets.

T10. Alteration or sending of an unwanted action on the workstation¶

This threat corresponds to an attacker who manages to generate or modify the json stream containing actions and execute them on the workstation.

T11. Elevation of workstation privileges¶

This threat corresponds to an attacker who manages to elevate his privileges on the workstation using the WAPT environment.

Functions implemented by the product¶

Safety functions (SF)¶

SF1. Secure communications¶

Agent-initiated communications¶

The agent downloads its packages from an https server, which checks that the repository certificate comes from an authority present in its <wapt>/ssl/server directory. The https server checks that the client certificate comes from an authority in the repository’s client trust store.

Requests from the agent to the server use the https protocol. The agent checks that the server’s certificate comes from an authority present in its <wapt>/ssl/server directory.

The agent establishes a websocket tunnel to the server to receive console actions. The websocket connection is encapsulated in a TLS tunnel. The agent checks that the server’s certificate comes from an authority present in its <wapt>/ssl/server directory.

Console-initiated communications¶

The console downloads packages from repositories, verifying that the certificate comes from an authority present in its %localappdata%/waptconsole/ssl/server directory. Repository https servers are configured to accept only client certificates from trusted authorities.

Console requests to the WAPT Server use the https protocol. The console checks that the server certificate comes from an authority present in its <wapt>/ssl/server directory. The WAPT Server is configured to accept only client certificates from trusted authorities.

Agent websocket connection¶

Agents request an authentication token from the server, signed with their private key. This token is verified by the WAPT Server during the websocket connection.
Access to the WAPT Server to obtain the token and establish the websocket connection is protected by client certificate authentication.

Agent login for inventory feedback¶

Agents sign their inventory data with their private key, and the server verifies the key and signature using the public certificate stored in its database during initial agent registration.
Access to the WAPT Server is protected by client certificate authentication.

Connecting agents to download packages¶

Access to the WAPT packet repository(s) is protected by client certificate authentication.

Server authentication by agents¶

When the agent connects to the server via HTTPS requests, it checks that the server certificate is valid and that it comes from a trusted certification authority. When installing the agent, you choose to use:

The system certificate store.
Or a WAPT-specific store stored in the <wapt>sslserver folder (certificate pinning). For the purposes of the evaluation, this second option is chosen.

Authentication of deposit(s) by agents¶

When the agent connects to a repository via HTTPS requests, it checks that the repository certificate is valid and that it comes from a trusted certification authority. When installing the agent, you choose to use:

The system certificate store.
Or a WAPT-specific store stored in the <wapt>sslserver folder (certificate pinning). For the purposes of the evaluation, this second option is chosen.

SF2. Identification, authentication and access control¶

Initial WAPT Agent registration¶

To exist in the database and thus appear in the WAPT Console, a machine must register with the WAPT Server using the register command.

The register action is performed automatically when the WAPT Agent is installed or updated, if the machine is correctly registered with a Kerberos machine account in the organization’s Active Directory domain.

If the machine does not present the WAPT Server with a valid kerberos ticket, then the register action fails before requiring database access.

During registration, the client station generates an RSA key pair in the local private directory and sends the server a certificate signature request with the kerberos ticket.

If the Kerberos ticket is valid, the WAPT Server registers the WAPT Agent in its database, signs the CSR (Certificate Signing Request), stores the certificate in its database and sends the signed certificate back to the WAPT Agent.

If a WAPT Agent is already registered, it can re-register without a kerberos ticket, using the signed certificate of its current server.

If kerberos authentication fails or is unavailable, the Nginx server sends an unauthorized status, and the client asks the Local Administrator to enter the credentials of a WAPT Server account with the admin or register_host privilege. This account is defined on the WAPT Server locally, or authenticated by an LDAP / Active Directory directory.

Note: The Kerberos method assumes that the Active Directory server responds at the time of registration.

Local actions on agents¶

The workstation User can interact with the WAPT Agent through local HTTP actions. The User is identified by his username, which determines the properties of his local session.

User actions (installations, uninstallations, package updates) are authenticated by the local service using a token deposited in the personal directory associated with the User’s session.

Access to actions is conditional on the User’s account belonging to local system security groups (see self-service rules defined by a self-service package).

Business administrator authentication on the WAPT Console¶

The HTTPS connection from the management console to the server is first authenticated by the Business Administrator’s client certificate.

The initial login request is authenticated by the Business Administrator’s kerberos session ticket. It is used to retrieve a session token that will authenticate subsequent requests.

The WAPT ACLs associated with the Business Administrator’s account determine the server’s accessible functions. They are intended to facilitate organization and are not considered a security feature.

SF3. Data protection¶

Access to WAPT Agent installation directory¶

The <wapt> installation directory (C:Program Files (x86)wapt by default) is readable and editable:

Local Administrators through local access to the WAPT Agent installation directory.
Business administrators through the WAPT Agent update deployment mechanism.

Users do not have write access to the WAPT Agent installation directory.

Access restrictions to the <wapt> folder are based on the operating system’s standard ACL mechanism and are applied during WAPT Agent installation.

Access to the <wapt>/private storage directory¶

The <wapt>/private directory (C:Program Files (x86)wapt/private by default) contains:

The private key/certificate pair identifying the agent to the server.
Persistent package data in the <wapt>/private/persistent subdirectory.

No access rights to the directory are granted to any User. Only the WAPT Agent and Local Administrators have read and write access to this directory.

Access restrictions to the <wapt>/private folder are based on the operating system’s standard ACL mechanism and are applied during WAPT Agent installation.

Access to the Administrator’s private key/certificate pair métier¶

The private key must be stored by the Business Administrator in a folder that only he or she can browse, and which he or she considers secure. When keys are generated by the console, it is suggested that they be stored in the Business Administrator’s personal directory in a <wapt>/private folder.

The key is encrypted by a key derived from a strong password supplied by the Business Administrator.

SF4. Cryptographic functions: Authenticity and integrity¶

Signature of control file attributes¶

A package’s metadata (attributes) are defined in a package text file called control.

A checksum of all the attributes in the control file is generated, then signed by the package developer’s private key. The signature is added to the control file.

When updating available packages, the agent is thus able to check that the package Developer’s certificate comes from an authority present in its local <wapt>/ssl directory.

The public key is used to verify the signature of the packet’s attributes and authenticate it.

The checksum signature verifies the integrity of the control file.

Signing WAPT packets¶

Packages are ZIP archives. When the package is signed, a manifest file is generated containing the list of files in the archive, along with the checksum for each file.

The checksum of this manifest file is signed by the package developer’s private key.

The agent is thus able to check that the Package Developer’s certificate comes from an authority present in its local <wapt>/ssl directory.

The public key is used to verify the manifest file signature and authenticate the packet. The manifest file’s file list and checksums are used to verify the integrity of the files making up the WAPT packet.

Signature of actions sent to WAPT Agents¶

An action is defined by a set of properties encoded in JSON by the WAPT Console.

A checksum of the JSON data is generated, then signed by the Administrator’s private key. The signature is added to the JSON data.

When the action is received, the agent is thus able to check that the certificate that signed the action comes from an authority present in its local <wapt>/ssl directory.

The public key is used to verify the action’s signature and authenticate it.

The checksum signature verifies the integrity of the action.

SF5. Tamper protection¶

All binaries distributed by WAPT: the installer and included binaries are signed by Tranquil IT, with an EV Code-Signing certificate issued by an authority recognized by Microsoft. During updates, the signature of the agent installer is verified by the waptdeploy utility. The fingerprint of the signing certificate must be part of the list of Tranquil IT certificates compiled in waptdeploy. waptdeploy also checks that the fingerprint of the downloaded installer matches the one supplied as an argument (argument –hash). The –hash argument is stored in a GPO, so can only be modified by an organization administrator.

If a user uses self-service to uninstall a WAPT package imposed by a business administrator, the package will be reinstalled the next time the system is updated (by shutting down or taking explicit action).

SF6. Logging¶

The agent, WAPT Server and NGINX https server processes generate traces of their respective operations in text files protected for reading and writing by file system ACLs. The WAPT administration console does not log anything on its own; it merely queries the WAPT Server.

The latest status of each installed package is stored in a local agent database, write-protected by the file system’s ACLs. This data is sent to the WAPT Server and stored in a PostgreSQL database, access to which is restricted to the “wapt” account, owner of the WAPT Server process.

When the agent sends its logs to the WAPT Server, it signs them with its private key. The server process verifies the authenticity and integrity of this data using the agent’s certificate/public key stored in the server database.

This information can be accessed via the administration console. However, you must have the admin or view role on the server to access it.

Functions not evaluated¶

The functions listed below are active in the product version delivered for evaluation, but will not be evaluated:

Functional restrictions linked to WAPT ACLs (evaluation is carried out with an account that has the admin ACL, i.e. full rights). This element is essentially organizational.

Disabled functions¶

The functions listed below require configuration to operate. Specific documentation is available if these functions are not implemented. These functions are:

WADS (initial deployment of workstations, Microsoft MDT equivalent).
WAPT Windows Updates (Microsoft WSUS equivalent).
Secondary deposits.

Cover matrices¶

Threats and sensitive assets¶

The following matrix shows the coverage of threats to sensitive assets (the letters D, I, C and A stand for Availability, Integrity, Confidentiality and Authenticity respectively).

Threat coverage of sensitive assets¶
	B1 WAPT packages	B2 Actions triggered on the client workstation from the console	B3. Cryptographic hardware	B4. Communications	B5. Inventory data	B6. The newspapers	B7. Configuration values	B8. WAPT executables installed	B9. Host system
T01. Installation of a corrupt package			D,I,C,A	I,C				I	D,I,C,A
T02. Alteration of configuration values			D,I,C,A				I, D
T03. Illegitimate access	D		C		I,C	D	I,C	I
T04. Network listening			C	C	C
T05. Network traffic alteration (Man In the Middle type)	D,I		C	D	D
T06. Log alteration						I, A, D
T07. Cryptographic hardware recovery	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A
T08. Alteration of cryptographic hardware	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A	D,I,C,A
T09. Denial of service				D	D	D			D
T10. Alteration or sending of an unwanted action on the workstation			I,A				I		D,I
T11. Elevation of workstation privileges				C,I	I	I	I	D,I,C,A	D,I,C,A

Threats and security functions¶

Threat coverage by security functions¶
	SF1. Secure communications	SF2. Identification, authentication and access control	SF3. Data protection	SF4. Cryptographic functions: Authenticity and integrity	SF5. Tamper protection	SF6. Logging
T01. Installation of a corrupt package			X	X
T02. Alteration of configuration values		X	X	X
T03. Illegitimate access		X		X
T04. Network listening	X
T05. Network traffic alteration (Man In the Middle type)	X
T06. Log alteration	X			X		X
T07. Cryptographic hardware recovery			X	X
T08. Alteration of cryptographic hardware			X
T09. Denial of service		X	X
T10. Alteration or sending of an unwanted action on the workstation	X		X	X
T11. Elevation of workstation privileges					X