FAQ – Cyber Security

Pacom and immediate sub-contractors align with development standards defined in NIST SSDF. The NIST SSDF standard (also known as NIST Special Publication (SP) 800-218) details a development process with unified testing and build processes. The following processes are defined (from SP 800-218). 

• Prepare the Organization (PO): Ensure that the organization’s people, processes, and technology are prepared to perform secure software development at the organization level and, in some cases, for individual development groups or projects. 

• Protect the Software (PS): Protect all components of the software from tampering and unauthorized access. 

• Produce Well-Secured Software (PW): Produce well-secured software with minimal security vulnerabilities in its releases. 

• Respond to Vulnerabilities (RV): Identify residual vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar vulnerabilities from occurring in the future. 

The build and test environments are ephemeral containers running within Azure DevOps. Each environment is re-created for every new “job instance”. 

Pacom performs yearly penetration tests on selected components. The penetration tests are performed by reputable independent third-party testers. 
Each new build of Pacom software is source-controlled using software component analysis (SCA). A dependency SBOM report is produced for each build. Pacom employs a zero bug policy for third-party software. This means that each new release of Pacom software is distributed without any known third-party vulnerabilities. 

Pacom products use TLS. See Encryption for more information. 

The Sibelius frontend HTTP server communicates with the backend Microsoft SQL server using a TLS tunnel. The Pacom products employ industry standards for software-to-software encryption. The Pacom ecosystem allows for integration with third-party products outside of control. 

Pacom supports backward compatibility with legacy third-party solutions and therefore allows cleartext communication at the discretion of the integrator. 

TBD Third-party security 

TBD AccessControl 

The Pacom unison product employs a framework for input type validation and access control on all incoming API calls. The framework is a central component for all API access. 

If new software updates introduce security or availability issues the version can always be rolled back by the integrator (given that a backup is not unselected during the upgrade). A hot-fix solution to the issue will be provided as a response to a reproducible bug report. In case of extended issues with Pacom unison, direct SQL access can be used to run the environment in a degraded mode. 

In the case of availability or security issues, Pacom will produce a hot-fix response to a reproducible bug report within 90 days. Pacom offers software support and fixes on the three most recent versions. 

Each build of Pacom Unison performs SCA scans on each dependency and its transitive dependencies. Pacom employs a zero-bug policy on known vulnerabilities in third-party dependencies. Due to the sensitive nature of Pacoms business, we cannot perform system monitoring of clients’ installations. 

Pacom communicates with customers through integrators. Security advisories are distributed through integrator channels. New hot-fixes are announced through the integrators. 

Pacom works closely with its main vendor TLab West AB. Pacom and TLab share processes and methodology to adhere to NIS2. 

Pacom uses SonarQube and OWASP Dependency-Check to secure its code by identifying and addressing vulnerabilities early in development. SonarQube performs static code analysis to catch issues like SQL injection and cross-site scripting, providing developers with real-time feedback through CI/CD integration. OWASP Dependency-Check scans third-party libraries for known vulnerabilities, referencing the Common Vulnerabilities and Exposures (CVE) database and the National Vulnerability Database (NVD). When a vulnerability is found, it reports the CVEs and suggests fixes, allowing developers to update insecure dependencies. Together, these tools help Pacom maintain secure code by continually monitoring for risks in both proprietary code and external libraries.

Pacom aims to control the risk of malicious code from third-party software using dependency sourcing, manual audit, static code scanning, and software composition analysis. Using build-step isolation the effects of malicious build or test code are reduced to the individual components.  

A process of threat modeling during the design phase produces documentation of potential risk. Design choices are made to reduce the impact of unintentional vulnerabilities. 

Potential vulnerabilities introduced by Pacom are reduced further by yearly secure software development training on relevant topics as well as tuning of static code analysis (SAST).  

Collaborative code reviews on sensitive components improve shared learning and security culture within the development teams. 

Logical Denial of Service is controlled using the input validation framework. 
Checks are performed on content: Origin, Size, Lexical, Syntax, Semantic. 

Pacom development is performed in AzureDevOps which is unlikely to be impacted DDoS. The product runs in isolated networks, and the integrator may accidentally expose the product to network failures, this is nothing the products defend against. 

Requirements are collected from certification standards from Svenska Stöldskyddsföreningen. The implementation of the safety standards is checked during in-house testing. The verification of the implementation is performed by independent third parties. 

Pacom performs yearly penetration tests. The executive summary of the penetration test report and progress follow-up is shared with customers upon request. Serious security findings from penetration tests are remediated promptly. 

Testing of safety aspects of the product is certified in the context of product integrations. The integrated products are certified by Svenska Stöldskyddsföreningen (SSF). 

Encryption between server and client takes place using MS SQL Server and it supports the version of SQL used. 

Both the database itself and communication between server and client can be encrypted. 

More information can be found here: 

https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/sql-server-encryption?view=sql-server-ver16  

https://learn.microsoft.com/en-US/troubleshoot/sql/database-engine/connect/tls-1-2-support-microsoft-sql-server 

Sentrion v4.9.x and older supports TLS 1.1. 

Sentrion v5.x supports TLS v1.2 and is required if Unison is v5.11.4 or later.  

If Unison version is older, TLS v1.1 is used. 

Communication is initiated with handshaking using AES128 keys (encryption). 

After the Sentrion has verified the sub-unit, the DSS is approved, they switch to talking using scrambling, i.e. a simpler type of encryption.