Security

A field terminal can end up in someone else's hands. A workstation can receive an infected file. A remote site can lose its link to the management infrastructure.

The conditions differ, but the questions stay concrete: what has to be protected, which actions are allowed and how control is kept when normal operation is broken.

In RUS OS we treat security as part of the architecture and of the whole life of the system. From the choice of components and preparation of the image to maintenance, recovery and taking the device out of service.

Protection has to match the purpose of the system.

For one device the main risk is remote access. For another, physical safety, removable media or the actions of maintenance staff matter. On a distributed site the compromise of neighboring nodes has to be taken into account.

We start by defining the data to protect, the critical functions, the possible adversaries and the consequences of their actions.

The threat model sets the requirements for the architecture, the settings and the trials. It has to be reviewed when the equipment, the functions and the conditions of use change.

Trust in the system starts with which code receives control.

For target configurations we look at ways of checking boot components, the integrity of the system environment and the authenticity of the software being installed.

What such a check can do depends on the hardware platform. So the boundaries of trust, the order of key management and the actions when a change is found have to be defined.

The recovery mode also has to be designed in advance: who can start it, which operations are available and how the return of the device to a working state is confirmed.

An operator, an administrator, a service and an application need different rights.

Access to data, equipment and settings has to match the task being done. Administrative actions need separate control, and temporary permissions have to have a clear lifetime.

Maintenance on site has to be taken into account too. A specialist may need diagnosis or replacement of a component without access to the user's working data.

We treat the separation of authority as the basis of the everyday work of the system.

An error or the compromise of one component can affect the services connected to it.

Boundaries between components have to limit that effect. For each interaction the available operations, the data passed and the conditions of failure have to be defined.

The means of isolation are chosen for the equipment and the load. Their properties have to be checked together with the real settings and the dependencies of the applications.

The aim is to keep the system manageable and to limit the area of a breach.

Drives, logs, backups and temporary files can hold sensitive information.

For each category of data the place of storage, the retention time and the circle of access have to be defined. Encryption needs considered key management, including boot without a network, maintenance and recovery.

Loss of the device, removal of the drive and physical access to a running system are different cases. The measures of protection have to account for each of them.

When equipment is sent for repair or to another organization, there has to be an established order for handling data and key material.

A network port, a radio module, a service connector and removable media open different ways of interacting with the system.

For each interface the purpose, the allowed connections and the available operations have to be defined. Unused capabilities have to be switched off according to the device configuration.

Diagnostic and manufacturing interfaces need particular attention. The order of access to them has to account for both development and later operation.

A system is assembled from components, each of which has a source, a version and dependencies.

We treat an account of the makeup, a check of origin and control of changes as necessary conditions of support. A vulnerability that is found has to be tied to the concrete builds and configurations it affects.

Updates require a check of authenticity and integrity, trials and a defined order of installation.

Returning to a previous version has to be managed separately: restoring operation has to account for the risk that vulnerabilities already removed appear again.

Protection has to account for autonomous operation.

A remote site may for a time receive no updates, no notice that access was revoked and no new policies. So the lifetime of permissions, the local rules of checking and the allowed length of autonomous mode are set in advance.

After the link returns, the system has to reconcile the changes and pass on the events it has accumulated.

The operator has to understand which limits are in force and whether intervention is required.

An investigation needs reliable events: who entered the system, changed settings, connected a device or carried out a significant operation.

Logging needs its own protection, access control and control of volume. The content of the records has to account for the confidentiality of the data.

Suspicious events need an order of action: a check, restriction of access, isolation of the affected components and recovery.

Procedures defined in advance help people act in sequence even with a limited link and without a developer on site.

The ability to analyze data and the right to carry out actions require different authority.

For intelligent components the available sources of information, tools and commands have to be defined. Significant operations may require a person's confirmation or further conditions.

An outside document, a message or a result of processing must not by itself grant new rights.

We look at intelligent functions inside the shared model of access, control and audit. The main operations of the device have to have a defined behavior if those functions fail or are switched off.

The properties of protection depend on the implementation, the configuration and the conditions of use.

So analysis, trials and a repeated check after significant changes are necessary. Boot, access, outside interfaces, updates, recovery and behavior on failures all have to be checked.

For each decision it is important to record the properties that were confirmed, the limits and the conditions of use.

We build the approach to RUS OS security around the ability to check: to understand the threats, to justify the mechanisms of protection and to keep control for the whole service life of the system.