Arcabit quality policy in the development and updating of software on Endpoints (SDP – Safe Deployment Practices)

 

Introduction

The aim of the implemented and strictly observed SDP policy is to ensure continuous, uninterrupted and safe operation of our Clients’ end devices and systems regardless of the Arcabit package update processes, both in terms of updating the threat databases themselves and in the area of ​​updating libraries and executable files.

Arcabit package update

Arcabit package update includes:

– threat databases (the main update path, in which new versions of the databases are published on average every 2 hours).

– libraries and executable files of the package (a parallel update path launched several times a year, when the software development cycle is completed).

Each update path includes restrictive test procedures, which must be completed successfully in their entirety before the update is published.

Threat database update

The threat database update path includes all patterns, signatures, rules and other types of information that constitute input data for all protection modules of Arcabit packages. This path does not include executable files, libraries and drivers.

Analysis

In the analysis phase, procedures are launched (both automatic and manual) that generate patterns, signatures, schemes, etc. that allow the protection mechanisms to detect new threats.

Initial tests

In this phase, newly generated patterns are tested for detection effectiveness, susceptibility to generating false alarms and performance.

Repository generation

In this phase, a new update repository is created, including new and fully tested patterns.

Repository tests (*1)

The generated repository is published in the internal test structure, and then the update procedure is launched on all versions of systems supported by Arcabit. After the update, a detailed test procedure is launched, including detection tests, false alarms, and system load. Each test is documented by a summary, detailed report.

Decision to publish a new repository

After completing all test procedures, the generated reports are compared with the reference reports. Full compliance allows for the publication of updates to official repositories. Any discrepancy causes the publication process to be suspended and returns to the analysis phase with information about the discrepancies that occurred.

Copies of previous repositories

The update system stores full versions of all published repositories from the last 30 days and is equipped with an emergency procedure for withdrawing the current repository and replacing it with one of the older repositories.

Updating executable files, libraries, and drivers

Updating the package’s executable files includes:

– new program functions,

– modifications to user interfaces,

– corrections to previously functioning modules.

Implementations of changes are inspired by, among others: constantly conducted internal analyses of the cybersecurity market, user suggestions, detected errors in package modules, changes in the requirements of operating system developers.

Partial tests

During implementation work, partial tests are conducted to verify and thus ensure that the design assumptions are met.

Initial tests

After each completed development cycle, initial test repositories containing new and modified program modules are generated. The repositories are distributed within the internal test network containing instances of all supported versions of operating systems. Changes are tested on all systems supported by them. A necessary condition for passing the tests is full compliance of the results with the defined patterns.

Implementation to public repositories

After successful completion of the initial testing phase, changes are merged with the existing public repositories and entered into the daily test cycle (*1). Changes are published to users gradually, with simultaneous control of any reports of irregularities.