Home

CJSC Peter-Service, Data Retention System , September 16, 2009. Classification unknown.

Na

National Security Archive

May 25, 202620 min read

A 2009 Russian software manual reveals how a private vendor turned vague data‑retention laws into a plug‑in that let law‑enforcement query telecom networks directly.

Source: CJSC Peter-Service, Data Retention System , September 16, 2009. Classification unknown. Date: Sep 16, 2009 Archive: Wikileaks Collection: Cyber Vault: About the VPN... Oct 11, 2017


Editorial Analysis

Original analysis by the DriftSeas editorial desk. The complete primary-source document, transcribed from the National Security Archive scan, appears in full below.

A Russian Vendor’s Blueprint for State‑Level Wiretapping

The September 16 2009 product description from CJSC Peter‑Service is not a mundane marketing sheet; it is a technical roadmap for a “Data Retention System” (DRS) that plugs directly into a telecom operator’s core switching platform. The document was produced at a moment when Russia was tightening its legal framework for electronic surveillance—most notably the 2006 “Yarovaya” amendments that expanded mandatory data‑storage obligations for carriers. By offering a turnkey module that accepts search jobs from “authorised bodies” via the SMD‑538 protocol, Peter‑Service positioned itself as a conduit between Russian law‑enforcement agencies and the private networks that carry citizens’ communications.

The Policy Context Behind the Code

In the mid‑2000s, Russia’s security establishment pressed the telecommunications industry to retain traffic‑metadata for up to six months and, later, the content of communications for up to 30 days. The legislation was vague about the technical standards, leaving a market niche for domestic vendors who could translate legal mandates into software that integrated with existing switching suites (the “SPS Family of Products”). The DRS description explicitly references “authorised bodies” and “investigation agencies,” language that mirrors the wording of the 2006 Federal Law 149‑ФЗ. The timing—2009, just before the 2010 “SORM‑2” upgrade—suggests the document was meant to demonstrate compliance readiness to both carriers and the Ministry of Internal Affairs.

Who Was Behind the System?

CJSC Peter‑Service, a Saint‑Petersburg‑based firm, marketed itself as a specialist in billing and network‑management software. The presence of a detailed glossary cross‑reference to the “SVC_BASE” core subsystem indicates a close partnership with the larger SPS product line, itself a staple of Russian telecom infrastructure. The document lists four user roles—Administrator, Search Operator, Manager, Initiator—each mapped to a specific chain of command within a carrier’s security division. This hierarchy mirrors the Russian “SORM” (System of Operative‑Search Measures) model, where operators must log every search request and provide audit trails for oversight bodies.

Reading Between the Lines

While the text is ostensibly a neutral product manual, several passages betray the system’s surveillance purpose. The phrase “generates search jobs… received from authorised bodies” reveals a push‑button interface for law‑enforcement to inject queries directly into the carrier’s database, bypassing any judicial gatekeeping that might exist elsewhere. The dual logging—both in a dedicated log file and in the SVC_BASE database—creates a redundant audit trail, likely intended to satisfy internal compliance audits while also furnishing evidence for external investigators. Moreover, the mention of “SMD (538) protocol” is significant: the protocol is known within Russian security circles as a proprietary channel for transmitting lawful‑intercept orders. Its inclusion signals that the DRS was built to speak the same language as state‑run interception platforms, facilitating seamless data hand‑offs.

Why This Document Matters Today

The Peter‑Service DRS description is a rare glimpse into the commercial underpinnings of Russia’s expansive surveillance architecture. It shows how private‑sector software vendors translated ambiguous legislative mandates into concrete, marketable products that could be rolled out across multiple carriers. The modular design—adapters, dictionaries, web‑based reporting tools—allowed rapid integration without overhauling existing network hardware, a practical solution that likely accelerated the nationwide adoption of SORM‑2.

In the broader narrative of global cyber‑surveillance, the DRS is a case study in how state power can be outsourced to domestic tech firms, blurring the line between public authority and private enterprise. The document’s explicit focus on “authorised agency officers” and “security department experts” prefigures later debates about the role of telecom employees in executing surveillance orders, a controversy that resurfaced during the 2015‑2016 Russian “Yarovaya” package and continues to inform discussions about corporate complicity in state monitoring.

Understanding the technical specifications of the DRS helps scholars trace the evolution of Russia’s SORM ecosystem from a loosely enforced set of guidelines to a hardened, vendor‑supported platform. It also underscores why, even after the 2015 legal reforms, analysts still warn that Russian carriers remain tightly coupled to state‑mandated data‑retention tools—because the software foundations laid by companies like Peter‑Service are still in place, updated, and embedded in the operational fabric of the nation’s telecommunications.

Legacy and Ongoing Relevance

The declassification of this 2009 product sheet invites a reassessment of how surveillance technology proliferates under the radar of public scrutiny. It demonstrates that the legal scaffolding of mass data collection is only half the story; the other half is the commercial ecosystem that builds, sells, and maintains the tools required to make the law work. For policymakers and civil‑society watchdogs, the Peter‑Service DRS reminds us that any attempt to curb state surveillance must address not just statutes but also the private‑sector supply chains that give those statutes teeth.


Page 1
# DATA RETENTION
# SYSTEM

PRODUCT DESCRIPTION
11150642.3222106.00305.PP.01.5.M

CJSC PETER-SERVICE
Page 2

CJSC PETER-SERVICE DATA RETENTION SYSTEM


This document is a Product Description. The document may not cover some versions of the software. If you find an error or misprint in this document or if you suppose there are any, please contact CJSC PETER-SERVICE. This document is intended for the sole purpose of maintaining products installed on the basis of an agreement duly executed by CJSC PETER-SERVICE. This document can only be provided as part of an agreement which contains an authorisation of any past, current or future product installation, or upon obtaining an explicit permission from CJSC PETER-SERVICE. If you have obtained this document in any other way, please contact CJSC PETER-SERVICE at the address given below. All examples in this document, including reports and screenshots, were generated using the test database of CJSC PETER-SERVICE. Any similarity to real personal or company names, bank details, or other information is a coincidence. All trademarks and registered trademarks used in the document are proprietary to their respective owners and are used for identification purposes only. All rights reserved by CJSC PETER-SERVICE under the existing copyright law.

© CJSC PETER-SERVICE, 2007-2009

CJSC PETER-SERVICE 36, Shpalernaya St., Saint-Petersburg, 191123, Russia tel: + 7 812 3261299; fax: + 7 812 3261298 ps@billing.ru; www.billing.ru


PRODUCT DESCRIPTION 2

Page 3

CJSC PETER-SERVICE DATA RETENTION SYSTEM

PRODUCT DESCRIPTION 3

Page 4

CJSC PETER-SERVICE DATA RETENTION SYSTEM

CONTENTS

1 GENERAL INFORMATION.................................................................................................... PURPOSE............................................................................................................................ GLOSSARY.......................................................................................................................... IMPLEMENTATION FEATURES............................................................................................ USERS................................................................................................................................ HARDWARE REQUIREMENTS............................................................................................ SOFTWARE REQUIREMENTS.............................................................................................. 2 FUNCTIONS...................................................................................................................... ACTIVATING DATA SEARCH JOB SCENARIOS.................................................................... CREATING A WEB SITE VIEW............................................................................................ Administration.................................................................................................................... Data Load Management...................................................................................................... Request Transfer and Search Result Access........................................................................ SMD (538) PROTOCOL SUPPORT...................................................................................... 3 INTEROPERATION WITH OTHER SYSTEMS.................................................................... 4 PRODUCT COMPONENTS................................................................................................ APPLICATIONS.................................................................................................................... SMD Protocol Adapter for DRS (DRS_ADP_538)............................................................ System-Wide Dictionaries Initialisation (DRS_DICTS_INIT)............................................ Request Processing Server Initialisation (DRS_RQS_INIT).............................................. DRS Tools (DRS_WEB).................................................................................................... DOCUMENTATION.............................................................................................................. REVISION HISTORY............................................................................................................

PRODUCT DESCRIPTION 4

Page 5
CJSC PETER-SERVICE
DATA RETENTION SYSTEM

CHAPTER
# 1 GENERAL INFORMATION

This chapter describes the purpose and the general operational concept of the product as well as the conditions in which it is used.

**1 Purpose**
The Data Retention System (DRS) product makes it possible to work with the Core Subsystems of SPS Family of Products (SVC_BASE) product on the side of the telecom operator.

**1 Glossary**
For a full glossary of terms used in this document, see the Glossary for the Core Subsystems of SPS Family of Products (SVC_BASE) product [SVC_BASE-DOC_GLOSS].

**2 Implementation Features**
The product contains the following components which interact with the PETER-SERVICE SVC_BASE product:
*   applications used for initialisation of the PETER-SERVICE SVC_BASE dictionaries;
*   a set of screen forms providing interoperation of the telecom operator's employees with PETER-SERVICE SVC_BASE;
*   the SMD (538) adapter which performs the following operations:
    *   it generates search jobs, which are received from authorised bodies via the SMD (538) protocol, in PETER-SERVICE SVC_BASE with the help of special HAS operations;
    *   converts the job execution results into the SMD (538) protocol's format;
    *   it logs system events in its own log file and in the PETER-SERVICE SVC_BASE database (using HAS operations).

**2 Users**
The product's users are the telecom operator's employees who are authorised to search, with the help of the product, for the information, which is either requested by investigation agencies or necessary to perform internal or criminal investigations. Depending on their positions and privileges, the product users can have the following roles:
*   Administrator – an IT department expert whose duty is to administer and configure the product;
*   Search Operator – an employee of a special division responsible for performing investigation activities, processing requests and their processing results and generating reports;
*   Manager – a manager of the special division who grants certain privileges to search operators and monitors the compliance with all the proper rules using the system logs;
*   Initiator – an authorised agency officer or an expert of the security department of the telecom operator who passes on the requests for information and receives reports on the search results;
*   Data Download Operator – an authorised agency officer or an expert of the security department of the telecom operator who manages the process of data load to the warehouse.

**3 Hardware Requirements**
The product's hardware requirements are defined by the hardware requirements for the PETER-SERVICE SVC_BASE product.

PRODUCT DESCRIPTION
5
Page 6

CJSC PETER-SERVICE DATA RETENTION SYSTEM

To support the SMD (538) protocol, the PETER-SERVICE SVC_BASE interface server must be additionally equipped with a network interface controller for the Ethernet 10/100 BassT specification. The throughput of the communications channels must correspond to the requirements stipulated by the Appendix to the Regulations for Interoperation of Telecommunications Operators with Authorised Government Bodies Engaged in Criminal Investigation Activities as of 27.08.2005 (No. 538). A user workstation should include a personal computer complying with the following minimum requirements:

  • 1 GHz processor;
  • 256 Mb RAM;
  • 1024x768 colour monitor;
  • keyboard;
  • mouse.

4 Software Requirements

The product runs properly only if the Core Subsystems of SPS Family of Products (SVC_BASE) product is pre-installed and configured accordingly. The following software must be installed on the user workstation:

  • an operating system (one of those listed below):
    • Microsoft Windows 2000/XP/2003;
    • Red Hat Enterprise Linux Advanced Server 4 Update 4.
  • a Web browser (one of those listed below):
    • Microsoft Internet Explorer 6 SP1 – for Microsoft Windows 2000/XP/2003;
    • Mozilla Firefox 1.5 – for Red Hat Enterprise Linux Advanced Server 4 Update 4. The following additional software is required to work with reports containing the search job results:
  • a text editor (one of those listed below):
    • Microsoft Office Word 2003 or later – for Microsoft Windows 2000/XP/2003;
    • OpenOffice.org Writer 2.3 or later – for Red Hat Enterprise Linux Advanced Server 4 Update 4;
  • a table editor (one of those listed below):
    • Microsoft Office Excel 2003 or later – for Microsoft Windows 2000/XP/2003;
    • OpenOffice.org Calc 2.3 or later – for Red Hat Enterprise Linux Advanced Server 4 Update 4. To work with loaded statistics charts, the Adobe SVG Viewer plugin version 3.05 or later (for Microsoft Internet Explorer 6 SP1 only) is required.

PRODUCT DESCRIPTION 6

Page 7
CJSC PETER-SERVICE
DATA RETENTION SYSTEM

CHAPTER

# 2 FUNCTIONS

The product performs the following functions:
* activating data search job scenarios;
* creating a Web site view for working with PETER-SERVICE SVC_BASE on the side of the telecom operator;
* supporting the SMD (538) protocol for interoperation of the PETER-SERVICE SVC_BASE product installed on the side of the telecom operator with a similar system installed on the side of the authorised agencies.

## 1 Activating Data Search Job Scenarios

The product defines the initial values of the dictionary of telecom operators of the PETER-SERVICE SVC_BASE product and activates the following data search job scenarios:
* requesting a subscriber card;
* searching for the subscriber's identifiers;
* searching for the data on balance top-ups;
* searching for the data on connections and calls.

## 2 Creating a Web Site View

The product provides a user interface for its administering, for managing the loaded data and also for transferring requests and accessing the search results on the side of the telecom operator.

### 1 Administration

The product allows registering new users in the PETER-SERVICE SVC_BASE product and controlling their access rights via the Web interface.
Using the product, you can view the PETER-SERVICE SVC_BASE product's system logs to audit the users' activities.
To view the logs of system events, you can select a source server of log records.

### 2 Data Load Management

The product allows loading data to any warehouse registered in the registry of PETER-SERVICE SVC_BASE servers.
The users can manage a list of load formats and a registry of loaded data packets. The following information is provided for each load format:
* the telecom operator identifier;
* a code of the load format;
* a type of the data being loaded;
* a data format name;
* start and end dates of the load format's validity period;
* an attribute of automatic data load;
* sample names of files in a certain format.
You can edit the attribute of automatic data load and view a log of loaded packets in terms of their load formats.
Using the product, you can check a data packet, load (and re-load) and reject packets.

7
PRODUCT DESCRIPTION
Page 8

CJSC PETER-SERVICE DATA RETENTION SYSTEM

The following information is provided for each packet:

  • the packet identifier;
  • a packet registration time;
  • file names within the packet;
  • the current packet status;
  • an operation being executed;
  • the current operation status;
  • a comment to the packet.

The product generates a graph of the temporal variation of the number of records in the loaded packets. The graph view depends on the type of load format. Each type of loaded data is associated with its own type of load formats:

  • for subscriber data – “cut-off” and “update-unload”;
  • for call and payment data – “event”;
  • for base station data – “cut-off”.

The statistical graph view for the “cut-off” and “event” types of load format is a histogram showing how the number of records of loaded packets changes in time. Each column of the histogram corresponds to the total number of records of the packets loaded on a certain date. Also, there is an additional statistical graph created for the load format of the “event” type; it contains a list of packets divided by hours, with their statuses described.

The statistical graph view for the “update-unload” type of load format is a linear diagram showing the rate of data volume growth in time. The diagram’s X-axis defines a time interval, while its Y-axis shows the average number of records in packets for the specified period of time.

To manage data loading, a Web interface is provided for the product users so as to access the following dictionaries of the specified data warehouse:

  • Base Stations – there is an interface implemented for viewing the dictionary’s records;
  • Telecom Operators – there is an interface implemented for viewing the dictionary’s records;
  • Switches – there is an interface implemented for viewing and editing the dictionary’s records;
  • Trunks – there is an interface implemented for viewing and editing the dictionary’s records;
  • Connection Types – there is an interface implemented for viewing and editing the dictionary’s records;
  • Payment Types – there is an interface implemented for viewing and editing the dictionary’s records;
  • Numbering Capacity of Telecom Operators – there is an interface implemented for viewing, creating, editing and deleting the dictionary’s records;
  • Associated Numbers – there is an interface implemented for viewing, creating, editing and deleting the dictionary’s records;

The dictionary of numbering capacity contains summary information on telecom operators who were owners of phone number ranges, but then sold their range or a part of their range and are now using certain phone number ranges in particular periods of time. You can add or edit a dictionary record on condition that:

  • the telecom operator which sells phone numbers is the owner of the entire range (including the first and last numbers in the range);
  • any phone number in the range can be included only in one resale chain at a time.

You can add or edit a record of the dictionary of associated numbers on condition that:

  • the associated ranges are of the same length (they include the same amount of phone numbers);
  • a phone number has only one association at a time.

With the help of the product, you can define the telecom operator which a phone number belongs to. Upon the user request, the history of a given phone number is displayed, so the user can get information on how the number has been used and resold by telecom operators and with what numbers it has been associated (if it is an associated number).

PRODUCT DESCRIPTION 8

Page 9

CJSC PETER-SERVICE DATA RETENTION SYSTEM

The dictionaries of numbering capacity and associated number ranges are populated manually. If the dictionaries are populated, it becomes easier for the search operator to search for data in the warehouse. With the interface privileges set up, the search operator can search for information on the phone number specified in the request. As a result of such a search, a list of telecom operators and a search period specified when a search job is being added can be shortened, which facilitates the search results generation process. And the phone number specified when a search job is being added can be defined in the same format as its associated number (if it is available), which increases the chance of finding the required information on the specified number.

3 Request Transfer and Search Result Access Using the product, you can create requests and start active search job scenarios with the help of the user interface forms. You can select search sources and define a start-up time for the search jobs. To manage the document flow required for executing search requests, you can view the summary dictionaries (maps) of call types, base stations, switches and trunks stored in PETER-SERVICE SVC_BASE. You can manage the results of call data search by categorising some phone numbers, the data on which have been loaded, as internal. This allows controlling access of the users to the search results containing information on the calls made from or to these numbers. The search results can be saved by the product in a .doc file of the MS Office Word 2003 XML format. When a report on jobs is being created, there are as many files generated as there are types of responses (subscriber, payment or call data) in the search results. If no result is found for a certain type of job, no report file is generated for it. You can save the results of a search for data on connections in an .xml file of the MS Office Excel 2003 XML format. If viewed in MS Office Excel, the report contains only a summary of each row with the resulting data. In this case, if the report includes results of several jobs, each job's results are displayed in a separate sheet of the Excel book.

3 SMD (538) Protocol Support The product receives and processes official requests sent by the authorised agencies via the SMD (538) protocol. The requests for information on subscribers, their calls and payments are registered in the database of the request server of the telecom operator, after which active search job scenarios get launched. Apart from this, the product receives and processes requests for reference data on trunks, base stations, roaming partners, switches, IP gateways, call types, additional services and payment types. The product generates responses to jobs in the format defined by the SMD (538) protocol. The set of fields shown in the search job results can vary depending on the data storage structure of the data warehouse. To transfer the requests for information, the product registers the following objects in the database of the telecom operators' request server: a division, groups of permissions and users. To secure the data transfer process, the product checks the user data for compliance with the created profiles. The product logs the following events in the request server database of the telecom operator: opening and closing sessions, receiving requests for creating new search jobs, receiving requests for information and sending responses. Also, the product logs system messages (creating TCP sockets, opening listening ports, etc.) in its own file system log.

PRODUCT DESCRIPTION 9

Page 10

CJSC PETER-SERVICE DATA RETENTION SYSTEM CHAPTER

3 INTEROPERATION WITH OTHER SYSTEMS

The product is an add-on product for the Core Subsystems of SPS Family of Products (SVC_BASE) product. It provides access to the main functions of PETER-SERVICE SVC_BASE by means of the Web interface and the SMD (538) adapter and also defines a set of scenarios to be used for performing search requests in the product installed on the side of the telecom operator. The product can interoperate with external systems which support the SMD (538) protocol, e.g. the Service-SP-PU (SSP) product developed by PETER-SERVICE. The Service-SP-PU (SSP) product sends requests for information generated by authorised agencies to the product via the SMD (538) protocol and receives responses from the product. For more information on the interoperation algorithm, see the Appendix to the Regulations for Interoperation of Telecommunications Operators with Authorised Government Bodies Engaged in Criminal Investigation Activities as of 27.08.2005 (No. 538).

10 PRODUCT DESCRIPTION

Page 11

CJSC PETER-SERVICE DATA RETENTION SYSTEM

CHAPTER

4 PRODUCT COMPONENTS

This chapter describes the product's distribution package.

1 Applications

This section gives an overview of the product's applications.

1 SMD Protocol Adapter for DRS (DRS_ADP_538)

The SMD Protocol Adapter for DRS (DRS_ADP_538) application provides interoperation of the Core Subsystems of SPS Family of Products (SVC_BASE) product, installed on the side of the telecom operator, with a similar system, installed on the side of the authorised agencies, via the SMD (538) protocol.

2 System-Wide Dictionaries Initialisation (DRS_DICTS_INIT)

The System-Wide Dictionaries Initialization (DRS_DICTS_INIT) application is designed to initialise the dictionary of telecom operators.

3 Request Processing Server Initialisation (DRS_RQS_INIT)

The Request Processing Server Initialization (DRS_RQS_INIT) application is designed to define a set of active search job scenarios.

4 DRS Tools (DRS_WEB)

The DRS Tools (DRS_WEB) application is designed to manage the Core Subsystems of SPS Family of Products (SVC_BASE) product with the help of visual elements.

2 Documentation

Listed below are documents which are shipped with the product distribution package:

  • Product Description (this document) [DRS-DOC_PP];
  • Maintenance Guide [DRS-DOC_G3];
  • User Guide for the DRS Tools (DRS_WEB) application [DRS_WEB-DOC_USER];
  • Administrator Guides for the product's applications.

PRODUCT DESCRIPTION 11

Page 12
CJSC PETER-SERVICE
DATA RETENTION SYSTEM

# REVISION HISTORY

**Version 005.01 of 16.09.2009**
The document was created.

12
PRODUCT DESCRIPTION
Page 13

NATIONAL SECURITY ARCHIVE

National Security Archive, Suite 701, Gelman Library, The George Washington University, 2130 H Street, NW, Washington, D.C., 20037, Phone: 202/994-7000, Fax: 202/994-7005, nsarchiv@gwu.edu

Keywords

declassifiedNational Security ArchiveCyber Vault: About the VPN... Oct 112017

Keep reading

More related articles from DriftSeas.