Scanv 4.ru - en

Translated from Russian to English - www.onlinedoctranslator.
com
STC "Volcano"
Materials for the implementation of recommendations for the protection of the technical project
Table of contents
Terms and abbreviations ............................................................... ................................................. ...............................2
Scheme for transferring information between databases .............................................................. .................................3
Database architecture.............................................................. ................................................. .........................4
Implementation of import and export of data between subsystems....................................................... ................14
API requests for data transfer from PSAP to PS Processing.................................................................. ......17
Working with messages .............................................................. ................................................. ...................17
Working with addresses.............................................. ................................................. ......................22
Working with sources .......................................................... ................................................. ...................23
Working with the state of the database ............................................... ................................................. .................24
Working with the rubricator .............................................................. ................................................. ...................24
Obtaining rubrics and languages............................................................... ................................................. ...........25
Order of synchronization of data of various subsystems.................................................................... .........................27
The order of synchronization of data of the PS "Processing" and PU-L .............................................. ......................27
The order of synchronization of databases PU-L and PU-W .................................................. ...................................29
The order of data synchronization between PU-L of the main and regional information
centers .............................................. ................................................. ................................................. .......31
The order of data synchronization between the PU-L GIC and the SS "Khranenie" Scan-AS ..............................33
Description of common interface solutions............................................................... ...............................................37
Typical scenarios for users' work, taking into account the role-based access model; .................................................39
Role-Based Access Control for Users to Information Panels of the Interface .........39
Role differentiation of functions performed on information objects ..............................................43
General scheme of work with the “Product” .............................................. ................................................. ..........45
Description of techniques and methods of working with "PU-L" .............................................. ......................................50
Description of techniques and methods of working with "PU-Z" .............................................. ...............................................52
Description of techniques and methods of working with the “Administration PS” .............................................................. .......54
Description of techniques and methods of working with "PS processing" .............................................. .......................61
1
Terms and abbreviations
FO - physical object;
VO is a virtual object;
SS - forces and means, description of methods of influencing a virtual
object;
CenterID - unique identifier of the center (main or regional);

ObjectID – FO identifier;
VObjectID - VO identifier;
VulnerabilityID - Vulnerability ID
AgentID - identifier of the Own agent
ID is a unique identifier of FO, VO, SS objects, automatically generated
by the system at the time of object creation, allowing them to be
identified in various subsystems, is a string value of the GUID format
(128-bit identifier with uniqueness that allows you to create extensible
services and applications without fear of conflicts caused by matching
identifiers);
GIC - the main information center;
RIC - regional information center;
IC - information center;
ICS - information and communication networks;
PAK - software and hardware complex;

APK - hardware and software complex;
PU-L - local loop control subsystem;
PU-Z - closed loop control subsystem;
PS "Processing" - a data processing subsystem in an open loop;
2
Scheme for transferring information between databases
The transfer of data between the databases that are part of the HSS "CUSS" is
carried out through the mechanism of export / import by a user with the role of
"Administrator" according to the scheme shown in Fig. 1, where:
1. Transfer of data upon request from the PAK "PSAP" to the PS "Processing"
using the appropriate API;
2. On removable media from "PS processing" to PU-L;
3. Data exchange via a communication channel between "PU-L" and APK
"Scan-AS". Data transfer is possible only from the main information center
(GIC) "PU-L" to the APK "Scan-AS" or from the APK "Scan-AS" to the "PU-L"
GIC;
4. Data exchange between PU-L of the main information center and PU-L
of regional information centers. Data transfer is carried out both from
PU-L RIC to PU-L GIC, and from PU-L to GIC to PU-L RIC via SSPD
communication lines or on removable media;
5. One-way data transfer on removable media from PU-L to PU-Z of the
main information center. Data transmission from PU-Z to other
subsystems is excluded.
Fig.1. Transfer of information between databases.
3
Database architecture
Information in the subsystems of the PS "Processing", PU-L, PU-Z is
stored in relational databases built on the PostgreSQL DBMS. Depending
on the purpose of the subsystem, databases differ in the number of
tables, the number of table fields, and the total amount of information
stored. So the PU-Z database, due to the limitation of the hardware
resources of the subsystem (one laptop), does not store information
about all the properties of the VO, being limited only by their identifiers,
names and coordinates. In order to ensure the uncompromising nature of
the PAK "TsUSS", in the database of the subsystem of the PS
"Processing" (open loop) there are no tables and separate fields
associated with the tasks performed as part of the activities. The most
complete information is collected in the database of the PU-L subsystem,
from where it will be regularly imported, using a data converter,
Having separate detailed differences, the databases of all three

subsystems, including their replicas in geographically distributed RICs, are
architecturally similar. The general storage structure of the ICS entities is shown
in Fig. 2. The storage structure of the task tracker entities is shown in Fig. 3.
4
Rice. 2. The general architecture of the relational database used in the subsystems of the PS "Processing", PU-L, PU-Z.
5
Rice. 3. Architecture for storing the entities of the task tracker for the PU-L subsystem.
6
The purpose of the database fields is described below:
Account table
Property Data type description

id integer ID of an object of type "account"
name varchar Name of an object of type "account"
type int4 Account Type
Link to the person who owns the account
personal_id bigint
Agent table

id bigint Own Fund Identifier (HC)
description varchar Description of the SS
name varchar Name of the SS

provided_access boolean Indicates whether the CC grants access
published boolean Specifies whether the SS is public
Indicates whether the SS is purchased or not
purchased boolean
Credo table

id bigint Creed object identifier
login varchar Login Information
password varchar Password information
host_id bigint Link to host
Table "entity"

id bigint Virtual object ID
description varchar Description of VO
name varchar Name of VO
latitude real Latitude is indicated
length real Longitude is indicated
entity_type_id integer The type of VO is indicated
Table "entity_type"

id integer VO type identifier
type_name varchar VO type name
id_parent integer Reference to the id of the parent entity_type
Extras table
7
Identifier of additional VO parameters
id integer
name varchar Parameter name

value varchar Parameter value
entity_id bigint Link to VO
Table "cluster"

id bigint Cluster ID
Department table

id bigint Cluster ID
organization_id bigint Organization link
"added_properties" table

agent_id bigint CC ID
software_id bigint Property ID to add
"deleted_properties" table

software_id bigint Property ID to remove
"start_properties" table

software_id bigint Start property ID
Table "fo"

id uid Physical Object Identifier (FO)
center_id integer Clearinghouse ID
description varchar FD Description
latitude real latitude
length real longitude
name varchar FO name
timestamp bigint FO creation date
type varchar FO infrastructure type
Host table
8
id bigint VO identifier "host"
domain varchar Domain is specified
ip varchar Specify ip address
mac varchar mac address is specified
os varchar Host OS specified
type varchar Host type specified
subnet_id bigint Subnet reference
Infrastructure table

name varchar Name of infrastructure type
organization table

id bigint Organization ID
address varchar The address of the organization
contacts varchar Organization contacts are indicated
priority integer strategic interest
type varchar Type of infrastructure
Table "personal"

id bigint Person ID
fio varchar Personal Information
priority integer Priority is indicated
status_id integer Link to person status
department_id bigint Link to department
"person_status" table

id integer Status ID
name varchar Status name
Port table

id bigint Port ID
number integer Port number
version varchar Port version
host_id bigint Link to host
"project" table
9
id bigint Project ID
number integer Project number
cluster_id bigint Link to cluster
relation table

id bigint Link ID
description varchar Communication Description
name varchar Communication name

finish_id bigint Link to final VO
start_id bigint Link to initial VO
relation_type_id bigint Link type link
"relation_type" table

id bigint Link type identifier
description varchar Description
name varchar Type name
Router table

id bigint Router ID
apn varchar APN (access point) is indicated
dns varchar DNS is specified
encryption_type varchar Encryption_type is specified
local_ip varchar Specify local ip
local_mask varchar The max local ip is specified
mark varchar Mark is indicated
mask varchar The mask is specified
model varchar The model of the router is indicated
password varchar Password is specified
source table

id bigint Source ID
dns varchar dns is specified
mask varchar Max is indicated
type_id integer Reference to VO type
Table "source_type"
10
id integer Source type identifier
name varchar Source type name
Table "software"

Software ID (SW)
id bigint
type varchar Software type
description varchar Software Description
name varchar Software name

version varchar Software version
subnet table

id bigint Subnet ID
mask varchar The subnet mask is specified
project_id bigint Project link
Attachments table

id bigint Attachment ID
comment_id bigint Link to comment
Color table

id integer Color ID
name varchar Color name
hex code varchar Specify color (hex color code)
Table "comments"

id bigint Comment ID
created_at timestamp The time the comment was created
text varchar Comment text
updated_at timestamp Specifies the update time
author_id bigint Link to the author
operation_id bigint Operation link
parent_id bigint Link to parent comment
task_id bigint Task link
deleted boolean Delete ID
"history_logs" table
eleven
id bigint Event ID
date timestamp Event date
type varchar Event type is specified
next_state text The new state is indicated
prev_state text Specifies the previous state
user_id bigint Link to user
event varchar Description of the event
Operations table

id bigint Event ID
created_at timestamp Event creation time
description varchar Description of the event
done_ratio integer Percent Complete
due_date timestamp Event end date
name varchar Name
start_date timestamp Operation start time
updated_at timestamp Operation update time
Link to the user that the event is assigned
assigned_to_id bigint
to
author_id bigint Author
priority_id bigint Link to Priority
status_id bigint Link to event status
"operation_statuses" table

id bigint Event Status ID
done_ratio integer The percentage of completion is indicated
name varchar Name
Priorities table

id bigint Priority ID
name varchar Name
color_id integer color link
Table "tasks"

id bigint Task ID
12
created_at timestamp Specifies the time the task was created
description varchar Task Description
due_data timestamp End time
double
estimated_hours Estimated time per task
precision
fo varchar physical object
subject varchar target object
done_ratio integer Percent Complete
double
remaining_hours Remaining hours
precision
start_date timestamp Task start time
updated_at timestamp Task update time
Link to the user to whom the task is
assigned_to_id bigint
assigned
author_id bigint Link to the author of the task
operation_id bigint Link to the event
parent_id bigint Link to the parent task
priority_id bigint Link to Priority
responsible_id bigint Link to the person responsible for the task
status_id bigint Link to task status
parent_editable boolean Editability ID
"task_statuses" table

id bigint Priority ID
done_ratio integer Specifies the percentage complete
Indicates if the status is set to
is_default boolean
default
name varchar Task status name
table "users"

id bigint User ID
login varchar User login
Table "work_groups"

id bigint Workgroup ID
name varchar Group name
responsible_id bigint Link to responsible
13
Implementation of data import and export between subsystems
The procedure for exporting/importing data between all the
specified subsystems is performed by a user with the "Administrator" role
both via communication channels and on removable media (CD/DVD
drives, USB drives). Zip-archiving and the XOR encryption procedure are
used, which excludes the possibility of reading the contents of archive
files by third parties even knowing the password, for example, when
intercepting data transmitted over a communication channel or when a
user loses removable media. The ability to read data from the archive is
provided only through the import-export mechanism, in which decryption
is performed via XOR as follows:
public static void xorFile(@Nonnull File file, @Nonnull String dest, @Nonnull byte[] password) throws
IOException {
FileInputStream is = new FileInputStream(file);
FileOutputStream os = new FileOutputStream(dest);
byte[] data = new byte[4096]; int

read = is.read(data), index = 0;
while (read != -1) {
for (int k = 0; k < read; k++) {
data[k] ^= password[index % password.length];
index++;
}
os.write(data, 0, read);
read = is.read(data);
}
os.flush();
os.close();
is.close();
}
Zip archive includes:

- data files for each type of object - contain a set of strings
with objects (each line is one object, separated by "\n")
- filemetadata.json - contains data about the source and target
segment, as well as a listing of all files with an indication of the type of data they
contain.
The segment to import into must match the segment specified in the
metadata.json file in the targetSegment field. In case of a mismatch, the
import will not be performed and an error will be generated (Error!).
14
An example of the contents of the metadata.json file:
{
"filesDescription" : [ {
"filename" : "object.objects",
"type" : "object"
}, {
"filename" : "operation.objects",
"type" : "operation"
} ],
"targetSegment" : "local",
"sourceSegment" : "local"
}
where object.objects - contains a set of FOs in the form of json, separated by

a line (\n),
operation.objects - contains a set of operations in the form of json, separated by a
string (\n).
Export and import of data is performed through the appropriate application programming
interface (API export and API import).
API export:
Post request along the path [SERVICE_URL]/api/v2/export:
{
data: {
settings: {
selected_items: [{...},{...},...],
selected_types: []
},
password: "123",
URL: ''
}
}
where url is the address for sending the selected data,

selected_items is an array of exported objects,
selected_types – array of exported object types (all objects of the
specified type are unloaded),
password – password for the archive where the uploaded objects will be
stored.
Selected_items array element:
{
type: ...,
id: ...
}
where type is the type of the object, id
is the id of the object.
15
API import
Post request along the path [SERVICE_URL]/api/v2/import
Archive import request:
{
"file": ...,
"password": '',
"confirm": true
}
where file is the MultipartFile file,
password is the password for the archive,
confirm – import confirmation flag (true – make import confirmation

(merge), false – save in the database without confirmation).
Import confirmation (transfer of selected import items):
Post request along the path [SERVICE_URL]/api/v2/import/

merge Import confirmation request content:
{
data: {
settings: {
confirmed: {
new: [...],
diff: [...],
merge: {}
}
},
fileId: '...'
}
}
where fileId is the identifier of a previously uploaded file (archive),

new is an array of confirmed id of new objects,
diff - an array of confirmed id changed objects,
merge – map with modified objects ({object id}: {final object}).
16
API requests for data transfer from PSAP to PS
Processing
As part of the performance of the tasks of the event, temporary users with the role of
"Operator" are registered in the PS "Processing". Sampling of data from HSS "PSAP" is
carried out at the request of the operator of the PS "Processing", in accordance with the
application programming interface (API) described below:
Working with messages

1. Get a list of messages by time
Call:
{ip}:9850/api/messagesByTime/{Window start in ms}/{Window end in ms}
{ip}:9850/api/messagesByTime/1522800000000/1522900000000
Answer:
[
{
ID: 1
"RecDate": "2018-04-04",
"RecTime": "09:30:04",
"Timestamp": 1522800000000,
"Type": null,
"Format": "Crypto-01",
"StoreFormat": "Crypto-01",
"BlockSize": 1646,
"Important": 9,
"lang": null,
RubNote: null
"RubName": "Unknown"
},
{
"ID": 2,
"RecDate": "2018-04-04",
"RecTime": "09:30:04",
"Timestamp": 1522800000000,
"Type": "Text",
"Format": "Undefined",
"StoreFormat": "PFF",
BlockSize: 37675
"Important": 9,
"Lang": "RU",
RubNote: null
},...
]
2. Get message information by ID
Call:
{ip}:9850/api/Messageinfo/{MessageID}
{ip}:9850/api/Messageinfo/1
17
Answer:
{
ID: 1
"RecDate": "2018-04-04",
"RecTime": "09:30:04",
"Timestamp": 1522800000000,
"Type": null,
"BlockSize": 1646,
"Important": 9,
"lang": null,
RubNote: null
"RubName": "Unknown",
Channel: 415
}
3. Get message by ID
Call:
{ip}:9850/api/Message/{message ID}
{ip}:9850/api/Message/1
Answer:
{
ID: 1
"RecDate": "2018-04-04",
"RecTime": "09:30:04",
"Timestamp": 1522800000000,
"Type": null,
"Block":
"VkVSUzQuMi41JCOjQVRJLTA1MjEjJV48REFUQSBTVFJJTkcgRElNPTYxPjExd1BBU1NXT1JEX0hFQU . . . . . . . .
MlXjxEQVRBIFNUUklORyBESU09NDQ+MjY0bmTyZvJm8mM4RklORV9DT01VTklDQVpJT05FX3V1dXVo
Nnl1ai1BVEk=",
blocksize: 1646
"Important": 9,
"lang": null,
RubNote: null
}
18
4. Get a list of messages by address type
Call:
{ip}:9850/api/messagesByAddrTypeID/{address type ID}

{ip}:9850/api/messagesByAddrTypeID/18
Answer:
[
{
ID: 70
"RecDate": "2018-04-04",
"RecTime": "09:31:18",
"Timestamp": 1522800000000,
"Type": "Document",
"Format": "X400",
BlockSize: 2027690
"Important": 9,
"Lang": "SR",
RubNote: null
},
{
"ID": 71,
"RecDate": "2018-04-04",
"RecTime": "09:31:18",
"Timestamp": 1522800000000,
"Type": "Graphics",
"Format": "X400",
BlockSize: 291010
"Important": 9,
"Lang": "UN",
RubNote: null
},...
]
5. Get a list of messages by address ID
Call:
{ip}:9850/api/messagesByAddrID/{address ID}
{ip}:9850/api/messagesByAddrID/246
Answer:
[
{
ID: 268
"RecDate": "2018-04-04",
"RecTime": "09:32:12",
"Timestamp": 1522800000000,
"Type": "Graphics",
"Format": "EML",
BlockSize: 70362
19
"Important": 9,
"Lang": "UN",
RubNote: null
},
{
ID: 269
"RecDate": "2018-04-04",
"RecTime": "09:32:12",
"Timestamp": 1522800000000,
"Type": "Graphics",
"Format": "EML",
BlockSize: 341505
"Important": 9,
"lang": null,
RubNote: null
},...
]
6. Complex filter
Call:
{ip}:9850/api/messages? filter=[{"AddrTypeId":5, "value":"158.167.45.28"},

{"operation": "Or","AddrTypeId":5, "value":"158.169.201.3"}, {"operation ":
"Or","AddrTypeId":5, "value":"213.180.199.21"}, {"operation":"and", "time":
{"start":1522800000000, "end":1530921600000}} ]
Answer:
[
{
ID: 70
"RecDate": "2018-04-04",
"RecTime": "09:31:18",
"Timestamp": 1522800000000,
"Type": "Document",
"Format": "X400",
BlockSize: 2027690
"Important": 9,
"Lang": "SR",
RubNote: null
Channel: 415
},
{
"ID": 71,
"RecDate": "2018-04-04",
"RecTime": "09:31:18",
"Timestamp": 1522800000000,
"Type": "Graphics",
"Format": "X400",
BlockSize: 291010
"Important": 9, "Lang": "UN",
20
RubNote: null
Channel: 415
},...
]
Call:
{ip}:9850/api/messages?
filter=[{"operation":"and",
"channel":{"Type":3,
"IP":"",
Mac: "",
"Name":"iDirect HUB Evolution",
"StationNumber":"",
"Time":1538640853920,
"GeoX":60.144,
"GeoY":10.808,
"Extras":"satellite-NSS 7; range-Ku-3 Norsat; polarization- Vertical;
carrier-12673995275; vsat_equipment-iDirect HUB Evolution; time-
stamp-1538630053920; location-60.144|10.808; city-Norway Akershus Hakadal
2.6km"
}}]
Answer:
[
{
"ID": 1692,
"RecDate": "2018-10-04",
"RecTime": "08:14:33",
"Timestamp": 1538611200000,
"Type": null,
"Format": "Java class",
"StoreFormat": "Java class",
"BlockSize": 2093,
"Important": 5,
"lang": null,
RubNote: null
Channel: 434
},
{
"ID": 1693,
"RecDate": "2018-10-04",
"RecTime": "08:14:18",
"Timestamp": 1538611200000,
"Type": null,
"Format": "JPEG",
StoreFormat: JPEG,
BlockSize: 15231
"Important": 5,
"lang": null,
RubNote: null
Channel: 434
},...
]
21
Working with addresses
1. Get a list of address types
Call:
{ip}:9850/api/addressTypes
Answer:
[
{
ID: 0
AddrTypeId: 0
"Name": "Undefined address",
"Notes": null
},
{
ID: 1
AddrTypeId: 1
"Name": "Wrong tech address",
"Notes": null
},...
]
2. Get a list of addresses by type
Call:
{ip}:9850 /api/addressByTypeId/{address type ID}

{ip}:9850 /api/addressByTypeId/8
Answer:
[
{
ID: 1
"Visual": "217.20.147.94" },
{
"ID": 3,
"Visual":
"217.69.134.208" },...
]
22
Working with sources
1. Get all sources by type
Call:
{ip}:9850/api/GetSourcesByID/{ID}
Where: "ID" - source type: 1 - wifi, 2 - GSM, 3 - Vsat Hub, 4 - rest (Radars)
Answer:
[
{
Type: 3
IP: "",
Mac: "",
"Name": "UK Scotland Redmoss 1.9km",
"StationNumber": "",
"Time": 1538640835725,
"GeoX": 57.13,
"GeoY": -2.12,
"Extras": "Vsat from
file" },
{
Type: 3
IP: "",
Mac: "",
"Name": "iDirect HUB Evolution",
"Time": 1538640853920,
"GeoX": 60.144,
"GeoY": 10.808,
"Extras": "satellite-NSS 7; band-Ku-3 Norsat; polarization-Vertical; carrier-12673995275;
vsat_equipment-iDirect HUB Evolution; timestamp-1538630053920; location-60,144|10,808;
city-Norway Akershus Hakadal 2.6km"
}, ...
]
2. Get sources by type and time
Call:
{ip}:9850/api/GetSources?Type=3&start=123&end=456
Where:
ID – source type. 1 - wifi, 2 - GSM, 3 - Vsat Hub, 4 - Radars;
start - beginning of the source appearance interval (time in ms starting from 01/01/1970);
end - end of the source occurrence interval (time in ms starting from 01/01/1970).
Example: //http://localhost:3699/api/GetSources?Type=3&start=1532620329&end=1532620329
Answer:
[
{
Type: 3
IP: "",
23
Mac: "",
"Name": "UK Scotland Redmoss 1.9km",
"Time": 1532563200000,
"GeoX": 57.13,
"GeoY": -2.12,
"Extras": "Vsat from
file" },
{
Type: 3
IP: "",
Mac: "",
"Name": "iDirect HUB iNFINITI",
"Time": 1538572327000,
"GeoX": 55.784, "GeoY": 37.486,
"Extras": "satellite-NSS 7; band-Ku-3 Norsat; polarization-Vertical; carrier-12558014279;
vsat_equipment-iDirect HUB iNFINITI; timestamp-1538572327; location-55.784|37.486;
city-Russia Moscow Oblast Khoroshevo-Mnevniki ( 159000) 0.9km"
}, ...
]
Working with database state

1. Get the state of the database
Call:
{ip}:9850/api/GetState
Answer:
[
{
ID: 1
"Name": "KOS",
Status: Ok,
"Message": "KOS DB. Number of messages in the DB:
478" },...
]
Working with rubricator

1. Get a set of keywords by rubric id
Call:
{ip}:9850/api/KeyWords/{id} //GET
Where: id is the category identifier.
Answer:
//http://localhost:3699/api/KeyWords/1 [
{
ID: 1
"Language": "AR",
"KeyWords": ["Sergy*","356","Test rub 358999","Last Add rub 66"] },
24
{
ID: 1
"Language": "CA",
"KeyWords": ["ARRAMBADA","BANDARRA","BARRINAR","BOLLERA","BOLLICAO","CAGANER",
"CARDAR","CASCAR&SE&LA","COLLONS","CONSOLADOR","CONY"," CUL","ESCALFAPOLLES","FAR
RANACO","FER&UN&RIU",
"FIGA","FILL&DE&PUTA","FILL&DE&VERRA","FOLLADOR","FOLLAR","FURNICAR","GALLUMBOS","GILIPOLLES","HINYA
","LLEPAR","LLETERADA","MAMADA","MANOLA","MARIETA","MARIPILI","PAJARITO","PARRĂŞS","P
ELAR&SE&LA","PUT
A","PUTOT","TREMPERA","TXITX*","XONA","XUFA"] },
{
ID: 1
"Language": "CS",
"KeyWords": ["BUZERANT","CHUJ","HOVNO","KOULE","KUNDA","KURVA","PRDEL","VEJCE","ZMRD"] },...
2. Rewrite the set of keywords by rubric id. POST method.
Parameter example:
{
ID: 1
"Language": "AR",
KeyWords: [
"Yukpn*",
Sergi*,
"356",
"Test rub 358999",
"Last Add rub 667" ]
Getting rubrics and languages

1. Request a list of categories
Call:
{ip}:9850/api/rubriclist?Parent=-1 // request for all categories {ip}:9850/

api/rubriclist?Parent=20 // request for categories with Parent=20
Answer:
[
{
ID: 0
ID1: 0
parent: null
"Name": "Unknown"
},
{
ID: 1
"ID1": 1,
"Parent": 0,
Name: Garbage
25
},...
]
Note: Equivalent to Url="/json/rubrics/5”
2. Request a list of languages
Call:
{ip}:9850/api/rubriclist api/LanguageList
Answer:
[
{
ID: 0
ID1: 0
"ShortName": "UN",
"Name": "UN-Unknown"
},
{
ID: 1
"ID1": 1,
"ShortName": "AA",
"Name": "AA-Afar"
},
{
"ID": 2,
"ID1": 2,
"ShortName": "AB",
"Name": "AB-Abkhazian"
},...
]
The specified API implements a one-way transfer of information in accordance with

the requests of the Processing PS. Additional synchronization of data on the servers
of the PS "Processing" and the HSS "PSAP" is not required.
Upon completion of the event, temporary users and all data related to
the completion of their tasks are deleted. Long-term storage of
information on open circuit servers is not expected.
The results of the work of the SS "Processing" are promptly imported into the PU-L
on removable media by a user with the "Administrator" role.
26
Order of synchronization of data of various subsystems
The order of synchronization of data of the PS "Processing" and PU-L
During the execution by the operators of the PS "Processing" of the tasks

for the event, it is supposed to create and edit physical objects (FO), virtual
objects (VO), instances of forces and means (SS). This information is
subsequently imported into the PU-L on removable media.
The data of physical objects contains:

1. ObjectID – FO identifier;
2. CenterID – identifier of the IC in which the FO was created;
3. ObjectName - the name of the FO in an anonymized form;
4. Description - text description of the FD;
5. Region – region (country) of location of the federal district;
6. Infrastructure - the type of infrastructure of the FD;
7. ObjectLat is the geographic latitude of the federal district;
8. ObjectLong – geographic longitude of the FD;

9. ObjectAddress – FO address;
Data on virtual objects contains:

1. VObjectID - VO identifier;
2. VObjectName - virtual object name
3. ObjectID – ID of the FO to which the VO belongs;
4. EtenityID - topology entity type
5. Software – software installed at the facility from the list
(including operating systems);
When exporting data from PU-L, records are created in the processing database in
the corresponding tables. The information in the processing PS is stored only for the
duration of the execution of the assigned Subtasks to the operators, therefore, with
each import of information here, all Physical and Virtual objects, as well as known
vulnerabilities, are re-registered.
Data about Physical and Virtual objects are imported into PU-L.
When exporting Physical Objects from the processing PS, the required
Physical Object in the DB PU-L is sorted first by the “CenterID” property, and
then by “Object_ID” in the “fo” table. If there is a discrepancy in the values
of other properties of the Physical object, the user is notified about this
with the option to confirm the import or cancel.
27
When exporting Virtual Objects from the processing PS, the required
virtual object is searched in the "fo" table by the "FoID" property (parent
object), and then by the "VObjectID" property of the "Entity" table. If there is
an identical object in the DB PU-L, the user will receive a corresponding
notification with a choice of further action - to confirm or cancel the import.
When confirming the import, lists of existing in the database and new
Virtual objects appear with the ability to select those VOs that need to be
copied to the PU-L with replacement.
In a situation where changes occurred simultaneously in both the PU-L and the
processing PS, it is possible to "Merge" the properties of the imported VO and those
stored in the database. This feature applies to the following entities and properties:
1. Host, "Ports" property

2. Host, "Creds" property
3. Personnel, property "accounts in the social. networks"
4. Staff, "e-mail" property
5. Personnel, property "phone"
6. Staff, property "Internet access"
7. Host, "Installed software" property
In a situation where the same (identical) object will be created both in the PU-L
and in the processing PS, it will be assigned different VObjectIDs in the Entity
table. The coincidence of the name and other properties of the Virtual Object will
not generate an error at the time of import into PU-L. To prevent duplication, the
user needs to manually find identical objects and choose which of the objects will
remain in the PU-L database.
28
Order of synchronization of databases PU-L and PU-W
Information about events, physical objects (FO), forces

and means (SS) is exported from PU-L to PU-Z.
The databases of the subsystems PU-L and PU-Z contain tables "Operations" - data on
activities, which consist of the following fields:
1. M_ID – event identifier;

2. CenterID – identifier of the information center (IC) in which the
event was created;
3. M_Name – event name;
4. M_status – event status identifier;
5. PersonID – identifier of the person responsible for the event;
6. M_DateStart – event start date;
7. M_DateFinish – end date of the event;
8. ObjectID - FO involved in the event;
For each FO:
9. ObjectName – FO name;
10.Description – text description of the FD;
11.Region - region (country) of the location of the FD;
12.Infrastructure - the type of infrastructure of the FD;
13.ObjectLat - geographic latitude of the federal district;
14.ObjectLong – geographic longitude of FD;
15.ObjectAddress – FO address;
16. Topology FD;
Forces and means involved in the event:
17.AgentID – SS identifier;
18.CenterID (ID of the center in which it was created)
19. Name of Own Fund
20.ID type
21.Array - Application Conditions ID
22.Weight
23.ID Impact Result
When transferring a Physical Object from PU-L to PU-Z, the presence of

this FO in PU-Z is checked. In the DB PU-Z in the table "fo" the property
"CenterID" is checked. If this property matches, further checks are made by
the "ObjectID". In the absence of matches of this property of the transferred
FO and those available in the PU-Z, a new Physical Object is formed in the DB
of the PU-Z with all attribute values obtained from the PU-L. If the "ObjectID"
property of the portable
29
an object with an existing one in the database, a notification is issued about the
presence of such a FD with the ability to confirm the import or cancel it. When
confirming the import, cards of the existing and new FI appear with the ability to
select the fields that will be updated. By default, all fields are selected for
replacement, except for “Name of the financial institution”. All FD fields in PU-Z can be
edited later.
When transferring data about an Event from PU-L to PU-Z, the presence
of this Event in PU-Z is checked. In the DB PU-Z in the table "Operations" the
property "CenterID" is checked. If this property matches, further verification
goes by "M_ID". If there is no match between this property of the transferred
Activity and those available in the PU-Z, a new Activity is formed in the DB of
the PU-Z with all attribute values obtained from the PU-L. If the "M_ID"
property of the transferred object matches the one in the database, all data on
the Event will not
corresponding to the available ones are updated, except for the Name of
the Event, information about the performer. All the Event fields in the PV-
C can be edited later.
When information about the Own Fund is transferred from PU-L to PU-Z,
the availability of this Own Fund in PU-Z is checked. In the DB PU-Z in the table
"Agents" the property "CenterID" is checked. If this property matches, further
checks are carried out by "AgentID". If there is no match between the given
property of the transferred Own facility and those available in the PV-C, a new
Own facility is formed in the DB of the CP-R with all the attribute values
obtained from the CP-L. If the "AgentID" property of the transferred object
matches the one in the database, all data on the Own Tool that do not
correspond to the existing ones are updated, except for the name of the Own
Tool.
thirty
The order of data synchronization between PU-L of the main and regional
information centers
Information about Physical objects, Virtual objects, new types of

entities, Events, forces and means (SS) is transmitted between PU-L GIC
and PU-L RIC.
Data on Physical objects includes:
1.ObjectID
2. CenterID (ID of the center in which it was created)
3. Name of the financial institution
4. FD coordinates
5. List of VO
6. PO topology
Data on Virtual Objects includes:
6.VObjectID
7.Object ID
8. Name of the Virtual object
9.EtenityID
10.Properties
Event data includes:

1. M_ID (own property
3. Name of the Event
4. Event Status ID
5. Information about the artist
a. IC name
b. Responsible
6. Start date of the event (for completed - Also the end date)
7. Information on the FIs participating in the Event
8. Information on the SS used in the Event
9. Information on Tasks, Subtasks
Data on Equity includes:
2.AgentID
3. Name of the Own Fund
4.ID type
5. Array - Application Condition ID
31
6. Weight
7. Result ID
When exporting data on the delivered Events from PU-L GIC to PU-L
RIC, a corresponding record is created in the table “Operations” of the DB
PU-L RIC. Events are identified by the IC in which it was created (CenterID
property) and the ID of the event itself (OperationID).
If the event was originally created in the RIC, then when it is transferred to the
GIC database, a corresponding entry is created in the "Operations" table - the
"CenterID" of the RIC in which the event was created, and the "OperationID" of
the Event are written, which eliminates the possibility of duplication of events
created in various ICs.
The exchange of the Event takes place during the "Clarification" of the event,
sending "For revision", "For verification". In these cases, the event is uniquely
identified by "CenterID" and "OperationID" when importing and exporting. All
other values of the Event properties available in the database of the imported IC
are replaced with new ones.
When exporting data on Physical objects from PU-L GIC to PU-L RIC,
a corresponding entry is created in the table “fo” of the DB PU-L RIC. A
physical object is identified by the IC in which it was created (“CenterID”
property) and the identifier of the object itself (ObjectID)
If the Physical Object was examined during the implementation of the Event and
created in the RIC, then when transferred to the GIC database, a corresponding entry is
created in the “fo” table - the “CenterID” of the RIC in which the Physical Object was
created, and the “ObjectID” of the Physical Object are written.
The exchange of Physical objects can also occur during the “Refinement” of
the Event to which the FO belongs, as well as during the sending “For revision”,
“For verification” (Event). Information on the FD is updated at each contact
between the GIC and the RIC. In these cases, the Physical Object is identified by
"CenterID" and "ObjectID" when importing and exporting. All other values of
properties of Physical objects available in the database of the imported IC are
replaced with new ones.
When exporting new types of entities (derivatives) from PU-L GIC to PU-L
RIC, records about them are created in the RIC database in the “Etenitys_types”
table. Each new type corresponds to a specific "EtenityID" (a property of any
Virtual Object).
32
The order of data synchronization between PU-L GIC and PS "Khranenie" Scan-AS
HSC "Scan-AS" is a universal data warehouse, into which

information flows from various subsystems included in HSC "TsUSS",
territorially distributed RIC, external sources. The complex provides
storage and access of operators to information about well-known
information security vulnerabilities,ongoing events, about all Physical
and Virtual objects, forces and means...
The Scan-AS APK uses a non-relational database based on the

Elasticsearch software search system, which provides horizontally
scalable full-text search, supports multithreading and allows you to
manipulate super-large amounts of information.
Storage of information in the subsystems of the processing system, PU-

L, PU-Z, necessary for solving tasks within the framework of events, is
implemented using the PostgreSQL object-relational DBMS, the main
advantage of which is high-performance and reliable mechanisms for
transactions and data replication.
To ensure the exchange of information between PU-L and APK "Scan-AS", a

data converter is implemented through intermediate JSON objects supported by
both databases. When exporting from PU-L to APK "Scan-AS", data from relational
tables are converted into objects of the universal text data exchange format JSON,
with a structure corresponding to the objects of the database of APK "Scan-AS".
When exporting data from APK Scan-AS to PU-L, the reverse process is
provided: data is converted from JSON objects into relational tables in
accordance with the structure described in the [Database Architecture] section.
Data on Physical objects, Virtual objects, forces and means are

transmitted between the PU-L GIC and the Skranenie PS Scan-AS.
33
Rice. 4. Implementation interface for import/export between PU-L and Scan-AS.
Data on Physical objects includes:

1.ObjectID
3. Name of the financial institution
4. FD coordinates
5. List of VO
6. PO topology
Data on Virtual Objects includes:
1.VObjectID
2.ObjectID
3.CenterID
4. Name of the Virtual Object
5.EtenityID
6. Properties
Data on Equity includes:

2.AgentID
3. Name of the Own Fund (anonymized)
4.ID type
5. Array - Application Condition ID
6. Weight
7. Result ID
Vulnerability data contains:
1. VulnerabilityID
2.CenterID
3. Vulnerability name
4. Type
5. Properties
When exporting data on Physical objects from the PU-L GIC to the SS
"Khranenie" Scan-AS, the presence of this FO in Scan-AS is checked. In the table
"fo" of the SS "Storage" Scan-AS, a physical object is identified by the IC in which it
was created ("CenterID" property) and the identifier of the object itself
("ObjectID"). In the absence of matches between the properties of the transferred
FO and those available in the SS "Storage", a new Physical Object is formed in the
Scan-AS DB with all attribute values obtained from the PU-L. If the "CenterID" and
"CenterID" properties match
34
"ObjectID", the existing FO is updated according to all values
received from the PU-L.
When exporting data on FDs from the SS "Khranenie" Scan-AS to PU-L
GIC, a similar procedure occurs.
When exporting data on Virtual Objects from the PU-L GIC to the SS
"Hranenie" Scan-AS, the presence of this VO in Scan-AS is checked. In the
"Virtual_objects" table of the "Storage" SS Scan-AS Virtual objects are identified
by the "ObjectID" and "CenterID" properties, and then by the "VObjectID"
property. If there are no matches between the properties of the transferred VO
and those available in the Storage SS, a new Virtual Object is formed in the
Scan-AS DB in the "Virtual_objects" table with all attribute values obtained
from the PU-L. If the properties "CenterID", "ObjectID" and "VObjectID" match,
the user is notified accordingly, with a further opportunity to confirm or cancel
the import. When confirming the import, the VO available in the Scan-AS
database is updated in accordance with all the values obtained from the PU-L.
Since VOs exist within the framework of a FD, during the import to the
SS "Storage" Scan-AS, a situation is possible when the Scan-AS database
contains more objects than those exported from PU-L. In this case, all
Virtual Objects within one physical object are checked - all "VObjectID"
are compared with identical "CenterID" and "ObjectID". All "extra" VOs
located in the "Storage" PS are deleted.
When exporting data on VO from the SS "Khranenie" Scan-AS to PU-L

When exporting information about the Own Fund from PU-L to the SS
"Storage" Scan-AS, the presence of this Own Fund in the Scan-AS database is
checked. In the SS "Storage" in the table "Agents" the property "CenterID" is
checked. If this property matches, further checks are carried out by "AgentID".
If these properties of the transferred Custom Tool and those available in Scan-
AS do not match, a new Custom Tool is formed in the Scan-AS DB with all the
attribute values obtained from the PU-L. If the "CenterID" and "AgentID"
properties of the transferred object match those available in the database, all
data on the Own Tool that do not correspond to the existing ones are updated.
When exporting data on SS from the SS "Hranenie" Scan-AS to PU-L

35
When exporting data on Vulnerabilities from the Storage system Scan-AS to
the PU-L GIC, all available records are unloaded. In the PU-L GIC, the
"Vulnerability" table is checked against the "CenterID" property, and then against
the "VulnerabilityID" property. If there is an identical Vulnerability, the data about
it is updated. If not, a new record is created in the table with all the characteristics
of the vulnerability obtained from the Storage system.
When exporting data on vulnerabilities from the PU-L GIC to the SS "Storage"
Scan-AS, a similar procedure occurs.
36
Description of common interface solutions
The graphical interface of the developed open source software is
designed to work on 15.6-inch laptop monitors with a resolution of
3840x2160, 27-inch monoblock monitors with a resolution of 3840x2160, as
well as demonstrations on 43-inch LCD TVs with a resolution of1920x1080.
The base set of color themes includes 4 color options

corresponding to the base OpenStreetMap themes. It is possible to
customize the color themes of the map and window interfaces. An
example of two different color forms used in the application interface is
shown in fig. 5.
Fig.5. Examples of the SC dashboard in two colors.
All controls are visible and understandable, have a size

sufficient for manipulation with a touchpad or mouse. User
interaction with them is limited to one action - pressing.
To prevent erroneous user actions (pressing the wrong button),

empty spaces are set between buttons and other controls, as well as a
visual change in their state when the cursor is hovered over. Any
interaction with controls leads to an event: displaying messages,
signaling the result of an action, the appearance of a dialog box,
switching to another window or menu, etc.
Widgets and toolbars are located on the right side of the screen and
do not block the main working area.
Fault and warning messages are displayed in the central area of the screen.
The functions of the controls are the same depending on the content. The names of
the elements are short, understandable and reflect their functions.
37
The names of the menu items associated with the continuation of
the dialogue contain ellipsis. The most important menu items are
provided with icons.
Functional menu groups are separated by stripes and "visual

pauses". The most frequently used items are located on the left and top
of the screen, the rarely used are on the right and bottom. In addition,
the administration subsystem contains the ability to customize interfaces
for users and roles - unused elements can be hidden.
Termination buttons of modal windows (for example, "OK", "Cancel",

"Apply", "Close") are located at the bottom of the windows.
38
Typical scenarios of user work, taking into account the role-based access
model;
Role-based differentiation of user access to information panels of the

interface
demarcation
role-playing users And available them
UI dashboards are shown in Table 1.
Table 1 - Role differentiation of users and interface information panels available to them
Circuit
Role
"PS processing" "POOL" "PU-Z"
Dashboard Dashboard
(custom (custom
widgets) widgets)
materials
objective
situation center
execution control
activities
Catalog
registered Map
activities
Director - Catalog Creation Interface

registered reports and their
RIC templates.
Catalog Catalog
registered registered
physical objects physical objects
Catalog Catalog
registered registered
own funds own funds
Directory of Controls,
Departments
39
Circuit
Role
Dashboard
(custom
widgets)
situation center
Catalog
registered
activities
Task catalog
(appointed to
subordinates/all
users)
Boss
- -
IC Template Manager
activities
Catalog
formed
working groups
Catalog
registered
own funds
Catalog
registered
physical objects
Supervisor Dashboard Dashboard -

groups (custom (custom
widgets) widgets)
Topology editor Topology editor
Interface Creation Interface

interactions with special
PAK "PSAP" operations
Creation Interface Catalog

script registered
40
Circuit
Role
special
physical objects
operations
Catalog
registered
Physical
Catalog of Vulnerabilities
objects
(transferred to PS
processing)
Catalog
registered
(transferred to PS -
Tasks (assigned to
processing)
RG)
Catalog
registered
-
Subtasks (within
assigned Tasks)
Operator Dashboard Dashboard

(custom (custom
widgets) widgets) -
Topology editor Topology editor
Interface Creation Interface

interactions with special
PAK "PSAP" operations
Creation Interface
-
Catalog
script
registered
special
physical objects
operations
Catalog Catalog of Vulnerabilities -

registered
Physical
objects
(transferred to PS
processing)
41
Circuit
Role
Catalog
registered
(transferred to PS -
Subtasks (within
processing)
working group)
Control Control Control

reference books reference books reference books
Interface Interface Interface

management management management
users/priv users/graft users/graft
administrator legacies legions legions
op
Interface Setting interface
Setting up profiles
profile settings profiles
users
users users
System monitoring System monitoring System monitoring
Import Export Import Export Import
42
Role differentiation of functions performed on information objects
Role differentiation of access to information objects and functions

performed on them by users with the appropriate roles, in the Local,
Closed and Open contours, are given in tables -4.
Table 2 - Role differentiation of functions performed on information objects. Local contour.
Role
Informational
Boss
th object Directo Head Operator
informational Administrator
R b groups R
about the center
Events CRUD CRU - - -
Tasks - CRUD EN - -
Subtasks - - CRUD CRUD -
Forces and means R R CRU CRU CRUD
Physical
R R CRU CRU CRUD
objects
Virtual
- - CRUD CRUD -
objects
Export Import - - - - +
Users R R R R CRUD
RIC management R R - - CRUD
Reference books R R R R CRUD
C - creation
R - Read/View/Select from List U -
Edit
D - delete
43
Table 3 - Role differentiation of functions performed on information objects. Closed loop.
Role
Informational
an object Director Administrator
SS EN CRUD
FD EN CRUD
Export Import - +
Users R CRUD
CC types R CRUD
Infrastructure types R CRUD
Target impact CRUD -
History of applications (part of SS) CRU CRUD
File types - CRUD
Table 4 - Role differentiation of functions performed on information objects. Open contour.
Role
Informational Supervisor Operator Administrator
an object groups R R
FD CRU CRU CRUD
IN CRUD CRUD CRUD
Export Import - - +
Users - - CRUD
CC types R R CRUD
Infrastructure types R R CRUD
Target impact R R CRUD
VO types CRU CRU CRUD
Roles - - CRUD
File types CRU CRU CRUD
44
General scheme of work with the "Product"
The logic of the client application includes role-based access control

to the information panels of the user interface. The application uses a
fixed set of roles, shown in Table TTABLE1. Each role has its own set of
functionality, due to the set of information panels (dashboards) available
to it and the list of operations performed on information objects - CRUD.
The logic of users' work with information objects available on the

corresponding information panels is based on the differentiation of
operations performed on them in accordance with the table.
According to the role model laid down in the application, users are
endowed with the capabilities determined by the role and have the
appropriate access rights to conduct operations: creating, reading and
editing information objects of the HSS "CUSS".
Each user created in the application is assigned a role (one or more)
from the list of pre-installed in the application.
Description of techniques and methods of working with the product as a whole:
1. The main information center updates information on Physical objects

by exporting information from Scan-AS.
2. With the help of PU-L of the Main Information Center, the situation
on registered Physical Objects is monitored. As part of the
monitoring, a decision is made on the need to conduct an event for
one or more Physical objects.
3. Director or Head of the SIC registers the event in the system. Within
the framework of one Event, only one performer is possible - the
Regional Information Center. Physical objects subordinate to the RIC
are attached to the event, the goals of the Event are described, as
well as the start date. The event is assigned the status "Determined".
4. "Responsible" for the event is the Head of the RIC, to whom the Event
was delivered.
5. Bringing information about the Event, as well as all the necessary
initial data to the RIC, is possible in one of the following ways:
45
- by exporting data from PU-L GIC to PU-L RIC on external
media;
- through OSPD (if available).
6. Initial data may be:
- Information about Physical objects and all Virtual objects
included in them, obtained from the Scan-AS database
- Information about Own Funds obtained from the database
Scan-AS data
- Information about Vulnerabilities from CEE.
7.In some cases, an event can be created in the RIC. At the same time,
all data on Physical objects, Virtual objects and other information
(stored in Scan-AS) necessary for the event are requested from the
PU-L GIC, and transmitted by one of the methods described above.
Rice. Event formation interface
8. The head of the RIC gets acquainted with the Event and informs the GIC
about the acceptance of the Event. The event is assigned the status "In
Progress".
9. Responsible for the Event, with the help of the Administrator, forms
working groups in the system, appoints a responsible person in
each group - the Head of the group.
10. A user with the Administrator role in the Administration PS assigns
the users selected by the Head of the RIC to belong to a certain
working group, creates new ones, and appoints those responsible.
11. The head of the RIC, within the framework of the Event, creates
Tasks and assigns them to the Team Leaders. If one user is
46
the head of several groups at once, then the Head of the RIC, in the
task creation interface, selects which group of this WG the Task
belongs to.
12. During the implementation of the Event, the Head of the RIC, the Head
of the GIC and the Director have the opportunity to view the
percentage of the completion of the Event. The percentage of
completion is the ratio of the number of completed Tasks for the Event
to the number of all Tasks set. This indicator dynamically changes
when creating new Tasks, deleting/completing existing ones.
13. Each Task is formed to a specific Physical Object, as well as with a
specific Target Impact.
14. Target impact - a task classifier containing a brief description, as
well as possible task templates.
15. Team leaders are responsible for completing the task. They plan
their part of the work and assign Subtasks to the operators of their
groups. This ensures that the requirements for group and individual
tasks are met.
47
Rice. 4. An example of a screen form for setting Subtasks by the Head of the group.
16. Operators and Team Leaders, perform the assigned Subtasks in the PU-L
and PS processing.
17. The administrator of the Open Loop Administration PS creates
temporary user accounts and transfers this information to the
working groups.
48
Rice. 5. Creation of a temporary user account PU-L to work in the processing PS.
18. The identifiers of the Physical objects with which the work will be carried out are
manually entered into the "Processing PS".
19. Operators and the Head of the group, using the processing software,
send requests to the PAK "PSAP". further, the primary processing of the
received data is carried out, the topologies of Physical objects are built
m1ATKAYAS?RukTOUR X G''*"71T%O5 27%5$•Cat'tsARM
ini—
"1Isoko
Logioesz
Dff? ss1b Z
I-: igyaoainyusnOoyupa
i and w With . bs ' , . n i . . . Weastaa
747f7244*$
4'
74 T'M
741'? 244
49
Rice. 6. An example of the interface for working with topology in the processing PS.
20. When working with the topology of several operators at the same
time, each of them is assigned its own topology mapping. The team
leader chooses which topology display will be saved in the FO card
for transfer to PU-L.
21. All information received in the course of work in the processing PS is transferred to the
PU-L on an external medium.
22. Team leaders with the help of PP-L evaluate the implementation of
subtasks, confirm or clarify tasks, work with reports on the actions
of operators, report on the work of their groups.
23. The head of the RIC, after completing all the tasks, draws up his report on
the results of M and sends it to the GIC. When a completed Event is sent
to the GIC, it is assigned the status "Under Review"
24. From the RIC, the collected information and reports are transferred to
the GIC using an external medium or through the OSPD. In the case of
a long-term activity, it is possible to provide periodic reports on the
progress of the activity.
25. With the help of PU-L GIC, data is processed, on the basis of which
the values of analytical metrics for the activities carried out are
calculated.
26. When the event is fully completed, the Head of the SIC makes a
decision on its completion. The event is assigned the status
"Completed". If the activity is not fully completed, the Head of the
GIZ decides whether it will continue or complete it with a certain
percentage of completion.
27. After the completion of the event, all data on new and updated
Physical Objects, Virtual Objects, Own Funds, new Vulnerabilities are
exported from the POOL-L GIC to Scan-AS.
28. Data on Physical objects, Event, Own funds are transferred to PU-Z.
29. The received data is synchronized in Closed Loop. A user with the
Administrator role creates catalogs of Own Funds and Physical
Objects, creates new ones and updates old ones, enters information
on the activities carried out in the system.
30. The director works with the received data. Deanonymizes received
Own funds, Physical objects, analyzes the results of activities, freely
edits their properties.
31. Further actions of the Director are related to the construction of
reports on the information of interest to him. These reports can be
either system-provided or customizable PU-3 report templates.
50
51
Description of techniques and methods of working with "PU-L"
PU-L provides for the following types of work:
- setting and delegation of tasks, taking into account the hierarchy of roles
users;
- view the status of current, completed and planned tasks
by functional groups and user hierarchies;
- scheduling tasks using the calendar;
- receiving information about events using the news feed;
- interaction of users through means of communication (chat,
VKS);
- viewing situational information in graphical form;
- visualization of information from the database on a heterogeneous graph;
- building,editing, visualization multilevel

heterogeneous network infrastructure graphs;
- manual entry of data on personnel and staff structure, binding to
network topology;
- formation and viewing of a catalog of objective materials
control (for each event);
- loading,searching, reading, editing materials and
attached files in a single knowledge base;
- formationparameterized analytical reports
way of grouping and aggregating information in different sections,
comparing indicators.
- uploading data from and to the centralized storage Scan-AS -
for PU-L Main Information Center
Users with the following roles are registered in the "PU-L" of each
RIC:
- "Head of the RIC";
- "Team leader";
- "Operator".
In addition, a user with the role of "Director" is registered in the "PU-
L" GIC. Also, each subsystem has a predefined user with the
"Administrator" role. A user with the "Administrator" role performs
actions related to user management, access rights and interface settings,
export and import of information between subsystems.
"PU-L" provides users with different roles with a graphical interface

with access rights.
52
For a user with the "Director" role, sections are implemented in the
graphical interface that allow viewing situational information, setting
tasks for the heads of the RIC, and generating analytical reports.
User Withrole "Boss RIC" provided

functionality similar to the director. The head of the RIC can create events
and assign tasks to the heads of his center. In addition, for the head of
the RIC, sections are implemented in the graphical interface that allow
you to view the status of current, completed and planned tasks by
functional groups and user hierarchies.
A user with the Supervisor role creates and assigns tasks to their
agent group. The manager can view situational information within the
tasks assigned to him and tasks created by the manager for his
subordinates, as well as tools for generating analytical reports.
The user with the role of "Operator" performs the tasks assigned to
him: works with information stored in a single knowledge base, views
data on the topology in the form of a multilevel heterogeneous graph,
performs manual data entry, generates and views a catalog of objective
control materials. It is also possible to work with several operators with
the topology of one FD. To improve work efficiency, similar actions are
performed by a user with the "Manager" role.
All users of SPO "PU-L" have access to tools such as news feed,
calendar, chat and video conferencing.
53
Description of techniques and methods of working with "PU-Z"
In "PU-Z" a single-user application is installed with the roles
assigned to the user: "Director" and "Administrator".
PU-Z provides for the following types of work:
- formation of the SS catalog;
- viewing the SS catalog;
- viewing the forms of objects and events;
- formationreporting documents on ongoing
activities;
- import of data from "PU-L".
The formation of the CC catalog and data import is performed by a
user with the role of "Administrator". Viewing the SS catalog is available to
all users of "PU-Z". Other actions can be performed only by a user with the
"Director" role.
In "PU-Z" its own graphical interface is available for users of different
roles with differentiation of access rights.
Fig.7. An example of the interface for viewing the list of Physical objects in PU-Z.
The graphical user interface with the role of "Director" has sections
for visualizing data on a geographical map, viewing forms of objects and
events, viewing the CC catalog, and also for generating reporting
documents.
In the data visualization section on geographical map
FD icons of a special kind are displayed. Icon colors and labels
54
reflect information objective control By conducted
activities in the Federal District. FD clustering is not provided.
Reporting documents may include event parameters, FD and VO
parameters, a number of analytical metrics and free fields, the names and
values of which are set by the user "PU-Z". The values of analytical metrics are
calculated by means of the SPO "PU-L" and transferred to the "PU-Z" in finished
form.
The graphical user interface with the "Administrator" role provides
sections for importing data from "PU-L" and for managing the CC catalog.
Export of data from "PU-Z" to other subsystems is excluded.
In the section for managing the CC catalog, a user with the
"Administrator" role can create, edit and delete (hide) unused objects, as
well as view information on the history of use of each instance of the CC
catalog.
55
Description of techniques and methods of working with the "Administration PS"
"Administration PS" is a conventional designation for a set of
software solutions (software modules) that are part of the open source
software and software tools for each of the circuits of the HSS "CUSS" and
are designed to perform administrative functions and perform a number
of functional tasks in accordance with the requirements of the
destination.
In PS administration" envisaged performance
the following types of work:
- RIC registration;
- creating and deleting users, setting access rights;
- customization of displaying user profiles;
- creation, deletion, change of entity types (infrastructure,
files, own funds);
- creating, deleting, changing types of topology entities;
- creation, deletion, change of entities (Physical objects,
Own funds, Virtual objects, Vulnerabilities);
- collection and display of diagnostic information about the work
software and hardware;
- export and import of data;
- setting up groups and user privileges for funds
communications (chat, videoconferencing).
- creation and editing of working groups of operators;

All types of work in the "Administration PS" are performed by a user with the
"Administrator" role.
To perform each type of work, a separate section is implemented in
the graphical user interface of the Administration PS.
Registration of the RIC is carried out in the "PS Administration" of the
GIC. Each RIC is assigned a unique identifier. The catalog of all RICs is kept in
the GIC.
"PS Administration" provides mechanisms For
user registration and access rights settings. The graphical user interface
of the Administration PS allows you to:
- view the list of users within one RIC;
- create temporary credentials for work in "PS
processing";
- set the validity period of temporary credentials;
- assign specialization of users with the role of "Operator";
56
- set specialization settings for each type;
- export and import the list of users.
- create working groups, appoint a responsible person in them.
- export and import files between subsystems and
information centres.
"PS Administration" allows register new
users within one RIC. The "Administration PS" of the GIC contains the data
of users with the role of "Head of the RIC" in order to provide the
possibility of setting tasks, organizing a chat and video conferencing.
Users with roles of lower levels of the hierarchy can register in the
"Administration PS" of the RIC without synchronization with the GIC.
To access the functionality of the SPO "PS Processing", the

administrator creates temporary credentials for users with the "Operator"
role and sets their validity period. A temporary credential is a randomly
generated username/password pair. The generated data is manually
entered into the processing PS to synchronize users and the tasks they
perform in various subsystems.
New FOs are registered, as a rule, in the “PS Administration” of the

GIC. After registration, the objects are transferred to the RIC in
accordance with the tasks set. The option of registering a new FO at the
RIC is possible if the new FO is directly located on the territory under the
jurisdiction of the RIC.
The "Administration PS" does not provide mechanisms for remote
monitoring of all subsystems of the HSS "TsUSS". The graphical user interface of
the "Administration PS" displays information about the current state of the
subsystem, as well as a log of messages about events that occur during the
operation of the open source software.
57
Fig.8 System health monitoring interface.
Setting up user groups and privileges for communication tools
consists in creating user groups, adding users to an already created
group, setting up rights so that users can perform various actions.
When exchanging data using export and import mechanisms, the

graphical user interface allows you to:
- select objects to be exported;
- view the results of comparing imported data with
objects stored in the database and confirm or cancel the import.
Administrator procedure for data export/import (with graphical
interfaces):
1. The administrator enters the export and import interface, selects the
necessary action.
2. In the "Export" interface that appears, the Administrator selects

the necessary items to be transferred.
58
3. After selecting all the necessary elements, the
Administrator clicks on the "Export" button - this creates
an encrypted file with all the data (Json format)
59
4. The administrator transfers the received file to another
circuit (external media, OSPD - depending on the situation)
and, using the import mechanism, decrypts it
60
5. In the window that opens, the Administrator performs actions on the
data - selects which objects he imports, which he leaves unchanged
(in the target contour), which he replaces with new ones.
61
62
Description of techniques and methods of working with "PS processing"
The "PS processing" provides for the implementation of the following types
works:
- visualization of information from the database on a heterogeneous graph;
- building, editing and visualization of multi-level

heterogeneous network infrastructure graphs;
- manual entry of data on personnel and staff structure, binding to
network topology;
- loading,searching, reading, editing materials and
attached files in a single knowledge base;
- obtaining data from external sources.
A user account with the "Administrator" role is predefined in the
"Processing PS". Temporary user accounts with the "Operator" role are
exported from "PU-L" on removable media by a user with the
"Administrator" role.
PU-L does not provide the ability to import data from PU-L. To build,
edit and visualize multilevel heterogeneous network infrastructure
graphs, a set of tools is implemented that allows you to add, delete, edit
graph vertices and create links between them. Possibilities are provided
for searching data on the graph, filtering vertex types, and adding
additional graphical and textual materials to the topology. A separate
section of the interface is intended for setting up various options for
displaying vertices on the topology. It is possible to work with several
operators with the topology of one FD.
Fig.9 An example of an interface for simultaneous operation of several operators with a topology.
63
For manual data entry and editing, the graphical user interface
provides entity cards of different types.
An advanced search for information in the database is performed
using wildcards, as well as custom templates with the ability to save them.
In addition to the advanced search, a quick search is provided for a
selection of objects already presented in the interface in the form of
tables and lists.
Obtaining data collected by PSAP from external sources is
implemented as a response to a request via the API. It is possible to
obtain data both manually (at the user's request) and in automatic mode,
which allows you to save search query parameters and monitor the
emergence of new data. Data from external sources is aggregated in the
local database "PS Processing".
The result of the work is the export of the obtained data with all their
changes to the PU-L.
64

Scanv 4.ru - en

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Scanv 4.ru - en

Uploaded by

Copyright:

Available Formats

Translated from Russian to English - www.onlinedoctranslator.

Scheme for transferring information between databases .............................................................. .................................3

Database architecture.............................................................. ................................................. .........................4

Implementation of import and export of data between subsystems....................................................... ................14

API requests for data transfer from PSAP to PS Processing.................................................................. ......17

Working with messages .............................................................. ................................................. ...................17

Working with addresses.............................................. ................................................. ......................22

Working with sources .......................................................... ................................................. ...................23

Working with the state of the database ............................................... ................................................. .................24

Working with the rubricator .............................................................. ................................................. ...................24

Obtaining rubrics and languages............................................................... ................................................. ...........25

Order of synchronization of data of various subsystems.................................................................... .........................27

The order of synchronization of databases PU-L and PU-W .................................................. ...................................29

Description of common interface solutions............................................................... ...............................................37

Role differentiation of functions performed on information objects ..............................................43

General scheme of work with the “Product” .............................................. ................................................. ..........45

Description of techniques and methods of working with "PU-L" .............................................. ......................................50

Description of techniques and methods of working with "PU-Z" .............................................. ...............................................52

CenterID - unique identifier of the center (main or regional);

PAK - software and hardware complex;

Fig.1. Transfer of information between databases.

Having separate detailed differences, the databases of all three

Property Data type description

Property Data type description

name varchar Name of the SS

Property Data type description

Property Data type description

Property Data type description

name varchar Parameter name

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

name varchar Communication name

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

type varchar Software type

description varchar Software Description

name varchar Software name

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

Property Data type description

byte[] data = new byte[4096]; int