How mobile operators analyze our data


СисАдмин Форума
Staff member
Full members of NP "MOD"
Feb 17, 2007
Reaction score
How mobile operators analyze our data.

Mobile operators receive a lot of data and metadata, from which you can learn a lot about the life of an individual subscriber. And if you understand how this data is processed and how it is stored, you can track the entire chain of information from the call to the debit. If we talk about the model of the internal intruder, then the possibilities are even more enormous, because data protection is not at all included in the tasks of the pre-billing systems of the mobile operator.

First you need to consider that subscriber traffic in the network of the telecom operator is generated and comes from different equipment. This equipment can generate files with records (CDR files, RADIUS logs, ASCII text) and work on different protocols (NetFlow, SNMP, SOAP). And you need to control all this fun and unfriendly round dance, take data, process and transfer it further to the billing system in a format that will be pre-standardized.

At the same time, subscriber data runs everywhere, access to which it is advisable not to provide to outsiders. How secure is the information in such a system, taking into account all the chains? Let's figure it out.

Why pre-billing for mobile operators?
It is believed that subscribers want to receive more and more new and modern types of services, but you cannot constantly change equipment for this. Therefore, the pre-billing should be engaged in the implementation of new services and in the ways of their provision - this is his first task. The second is traffic analysis, verification of its correctness, completeness of loading into subscription billing, preparation of data for billing.

With the help of pre-billing, various reconciliations and additional data loading are implemented. For example, reconciliation of the status of services on equipment and in billing. It happens that a subscriber uses services despite the fact that he is already blocked in billing. Or he used the services, but there was no record of this from the equipment. There can be many situations; most of these moments can be solved with the help of pre-billing.

Once I wrote a term paper on optimizing the company's business processes and calculating ROI. The problem with calculating the ROI was not that there was no source data - I did not understand which “line” to measure them. Approximately the same happens with pre-billing. You can infinitely customize and improve processing, but always at some point circumstances and data will be formed so that an exception occurs. You can ideally build a system of work and monitoring of auxiliary billing and pre-billing systems, but it is impossible to ensure uninterrupted operation of equipment and data transmission channels.

Therefore, there is a duplicate system that is engaged in checking data in billing and data that has gone from pre-billing to billing. Its task is to catch what is left of the equipment, but for some reason “did not fall on the subscriber”. This role of the duplicating and controlling pre-billing system is usually played by the FMS - Fraud Management System. Of course, its main purpose is not to control pre-billing at all, but to identify fraudulent schemes and, as a result, monitor the loss and discrepancy of data from equipment and billing data.

In fact, there are a lot of options for using prebilling. For example, it can be a reconciliation between the state of the subscriber on the equipment and in the CRM. Such a scheme may look as follows.

  1. Using pre-billing on SOAP, we obtain data from equipment (HSS, VLR , Hlr , Auc , Eir )
  2. Convert the raw RAW data to the desired format.
  3. We make a request to related CRM systems (databases, software interfaces).
  4. We are reconciling data.
  5. We form exception records.
  6. We make a request to the CRM system for data synchronization.
  7. Bottom line - the subscriber downloading a movie while roaming in South Africa is blocked with a zero balance and does not go into a wild minus.
Another use case is the accumulation of data and its further processing. Such an option is possible when we have thousands of records from equipment (GGSN-SGSN, telephony): throwing all these records into the subscriber details is completely crazy, not to mention the fact that we hellishly load all systems with so much small data. For this reason, the following scheme is suitable, which solves the problem.

  1. Receiving data from equipment.
  2. Aggregation of data on pre-billing (we are waiting for all the necessary records to be collected by any condition).
  3. Sending data to the final billing.
  4. The result - instead of 10 thousand records, we sent one with the aggregating value of the counter of consumed Internet traffic. They made only one request to the database and saved a bunch of resources, including electricity!
These are just typical work patterns. The format of the article does not allow examples of more complex schemes (for example, Big Data), but they also occur.

Hewlett-Packard Internet Usage Manager (HP IUM) pre-billing
To make it clearer how this works and where problems may arise here, let's take the Hewlett-Packard Internet Usage Manager pre-billing system (HP IUM, in the updated version of eIUM) and see how its similar software works.

Imagine a large meat grinder, in which they throw meat, vegetables, loaves of bread - all that is possible. That is, at the input there are a variety of products, but at the output they all take the same shape. We can change the lattice and get a different shape at the output, but the principle and way of processing our products will remain the same - auger, knife, lattice. This is the classic pre-billing scheme: data collection, processing and output. In IUM pre-billing, the links in this chain are called encapsulator, aggregator, and datastore.

Here it is necessary to understand that at the input we must have the completeness of the data - a certain minimum amount of information, without which further processing is useless. In the absence of any block or data element, we receive an error or warning that processing is impossible, since operations cannot be performed without this data.

Therefore, it is very important that the equipment generates record files that have a strictly defined and set by the manufacturer data set and type. Each type of equipment is a separate processor (collector) that works only with its own input data format. For example, you cannot just take and upload a file from CISCO PGW-SGW equipment with Internet traffic of mobile subscribers to a collector that processes the stream from Iskratel Si3000 fixed communication equipment.

If we do this, then in the best case we will get an exception during processing, and in the worst we will get all the processing for a specific thread, since the collector handler will fail and wait until we solve the problem with the “broken” one from his point of view file. Here you can see that all pre-billing systems, as a rule, critically perceive data for the processing of which a specific collector-processor was not configured.

Initially, the stream of parsed data (RAW) is formed at the level of the encapsulator and can already be converted and filtered here. This is done if, before the aggregation scheme, it is necessary to make changes with the stream, which should be further applied to the entire data stream (when it will go through various aggregation schemes).


Files (.cdr, .log and others) with records of user subscriber activity come both from local sources and from remote (FTP, SFTP), work options are also possible using other protocols. Parser files are parsed using different Java classes.

Since the pre-billing system in normal operation is not intended to store the history of processed files (and there may be hundreds of thousands per day), after processing the file on the source is deleted. For various reasons, a file cannot always be deleted correctly. As a result, it happens that the records from the file are processed repeatedly or with a great delay (when it turned out to delete the file). To prevent such duplicates, there are protection mechanisms: checking for duplicate files or records, checking for time in records and so on.

One of the weaknesses here is criticality to data size. The more data we store (in memory, in databases), the slower we process new data, the more we consume resources and eventually reach the limit after which we are forced to delete old data. Thus, auxiliary databases (MySQL, TimesTen, Oracle and so on) are usually used to store this metadata. Accordingly, we get another system that affects the work of pre-billing with the ensuing security issues.

How does prebilling work?
Once at the dawn of such systems, languages were used that made it possible to work efficiently with regular expressions, such as, for example, Perl. In fact, almost all pre-billing, if you do not take into account work with external systems, is the rules for parsing-converting strings. Naturally, it is better to find nothing here than regular expressions. The constantly growing volume of data and increasing criticality by the time a new service was introduced to the market made the use of such systems impossible, since testing and making changes took a lot of time, scalability was low.

Modern pre-billing is a set of modules, usually written in Java, which can be controlled in the graphical interface using standard operations of copy, paste, move, drag and drop. Work in this interface is simple and straightforward.

For work, the operating system is mainly based on Linux or Unix, less often - Windows.

The main problems are usually associated with the testing or error detection process, as the data goes through many chains of rules and is enriched with data from other systems. To see what happens to them at each stage is not always convenient and understandable. Therefore, you have to look for the cause, catching changes in the necessary variables using logs.


The weakness of this system is its complexity and human factor. Any exception provokes data loss or its incorrect formation.

Data is processed sequentially. If we have an exception error at the input that does not allow us to correctly accept and process the data, the entire input stream rises or a portion of incorrect data is discarded. The disassembled RAW stream goes to the next stage - aggregation. There can be several aggregation schemes, and they are isolated from each other. As if a single stream of water entering the shower, passing through the watering can lattice, is divided into different streams - some are thick, others are very thin.

After aggregation, the data is ready for delivery to the consumer. Delivery can go either directly to the database, or by writing to a file and sending it further, or simply by writing to the pre-billing repository, where they will remain until it is empty.

After processing at the first level, data can be transferred to the second and further. Such a ladder is necessary to increase the processing speed and load distribution. In the second stage, another stream can be added to our data stream, mix, share, copy, merge and so on. The final stage is always the delivery of data to the systems that consume it.

The pre-billing tasks are not included (and rightly so!):

  • to monitor whether the input-output data has arrived and been delivered - this should be done by separate systems;
  • encrypt data at any stage.
Not all the flow of incoming data is processed. Only the data that is needed for work is processed. There is no point in wasting time on the rest until they are needed. Thus, only what is needed for aggregation schemes should be taken from the RAW stream. From RAW (text files, query results, binary files) only the necessary is parsed.

Pre-billing privacy
Here we have a complete cracker! To begin with, the pre-billing tasks do not include data protection in principle. Differentiation of access to pre-billing is necessary and possible at different levels (control interface, operating system), but if we force him to engage in data encryption, then the complexity and processing time will increase so much that it will be completely unacceptable and unsuitable for billing to work.

Often, the time from using the service to displaying this fact in billing should not exceed several minutes. Typically, the metadata that is needed to process a particular piece of data is stored in a database (MySQL, Oracle, Solid). Input and output data almost always lie in the directory of a particular collector stream. Therefore, access to them can be enjoyed by anyone to whom it is allowed (for example, the root user).

The prebilling configuration itself with a set of rules, information about access to databases, FTP and other things is stored in encrypted form in a file database. If the login password for accessing pre-billing is not known, then uploading the configuration is not so simple.

Any changes to the processing logic (rules) are recorded in the log file of the pre-billing configuration (who, when and what changed).

Even if data is transmitted directly through the chains of collector handlers inside pre-billing (bypassing the upload to a file), the data is still temporarily stored as a file in the handler’s directory, and you can access it if you wish.

The data that is processed on pre-billing is depersonalized: it does not contain a name, address or passport data. Therefore, even if you get access to this information, you won’t get to know the subscriber’s personal data from here. But you can catch some kind of information by a specific number, IP or other identifier.

Having access to the pre-billing configuration, you get data to access all the adjacent systems with which it works. As a rule, access to them is limited directly from the server on which pre-billing works, but this is not always the case.

If you get to the directories where the file data of the handlers are stored, you can make changes to these files, which are waiting for their sending to consumers. Often these are the most common text documents. Then the picture is this: the pre-billing data was received and processed, but they did not come to the final system - they disappeared into the “black hole”.

And to find out the cause of these losses will be difficult, since only part of the data is lost. In any case, it will be impossible to emulate the loss in a further search for the causes. You can see the data at the input and output, but to understand where they went, it will be impossible. In this case, the attacker only has to cover up the traces in the operating system.

Original message
Как мобильные операторы анализируют наши данные.

Мобильные операторы получают массу данных и метаданных, по которым можно узнать очень многое о жизни отдельно взятого абонента. А поняв, как обрабатываются и как хранятся эти данные, вы сможете отследить всю цепочку прохождения информации от звонка до списания денег. Если же говорить о модели внутреннего нарушителя, то здесь возможности и подавно огромные, ведь защита данных вообще не входит в задачи систем предбиллинга мобильного оператора.

Для начала нужно учитывать, что абонентский трафик в сети телеком-оператора генерируется и поступает с разного оборудования. Это оборудование может формировать файлы с записями (файлы CDR, логи RADIUS, текст в ASCII) и работать по разным протоколам (NetFlow, SNMP, SOAP). И нужно контролировать весь этот веселый и недружный хоровод, снимать данные, обрабатывать и передавать дальше в биллинговую систему в формате, который будет предварительно стандартизован.

При этом везде бегают абонентские данные, доступ к которым желательно не предоставлять посторонним. Насколько защищена информация в такой системе с учетом всех цепочек? Давайте разбиремся.

Зачем предбиллинг операторам мобильной связи?
Считается, что абоненты хотят получать все более новые и современные виды услуг, но нельзя постоянно менять для этого оборудование. Поэтому реализацией новых услуг и способами их предоставления должен заниматься предбиллинг — это его первая задача. Вторая — анализ трафика, проверка его корректности, полноты загрузки в абонентский биллинг, подготовка данных для биллинга.

С помощью предбиллинга реализованы различные сверки и дозагрузки данных. Например, сверка состояния услуг на оборудовании и в биллинге. Бывает, абонент пользуется услугами при том, что в биллинге он уже заблокирован. Либо он пользовался услугами, но с оборудования не поступили записи об этом. Ситуаций может быть множество, большинство таких моментов и решается с помощью предбиллинга.

Когда-то я писал курсовую работу по оптимизации бизнес-процессов компании и расчету ROI. Проблема с расчетом ROI была не в том, что не было исходных данных, — я не понимал, какой «линейкой» их мерить. Примерно так же часто бывает с предбиллингом. Можно бесконечно настраивать и улучшать обработку, но всегда в какой-то момент обстоятельства и данные сложатся так, что произойдет исключение. Можно идеально выстроить систему работы и мониторинга вспомогательных систем биллинга и предбиллинга, но невозможно обеспечить бесперебойную работу оборудования и каналов передачи данных.

Поэтому и существует дублирующая система, которая занимается проверкой данных в биллинге и данных, ушедших от предбиллинга в биллинг. Ее задача — поймать то, что ушло с оборудования, но по какой-то причине «не легло на абонента». Эту роль дублирующей и контролирующей предбиллинг системы обычно играет FMS — Fraud Management System. Конечно, ее основное предназначение — вовсе не контроль предбиллинга, а выявление мошеннических схем и, как следствие, мониторинг потерь и расхождений данных с оборудования и биллинговых данных.

На самом деле вариантов использования предбиллинга очень много. Например, это может быть выполнение сверки между состоянием абонента на оборудовании и в CRM. Такая схема может выглядеть следующим образом.

  1. С помощью предбиллинга по SOAP получаем данные с оборудования (HSS, VLR, HLR, AUC, EIR).
  2. Преобразуем исходные RAW-данные в нужный формат.
  3. Делаем запрос в смежные системы CRM (базы данных, программные интерфейсы).
  4. Производим сверку данных.
  5. Формируем записи-исключения.
  6. Делаем запрос в систему CRM на синхронизацию данных.
  7. Итог — абонент, качающий фильм в роуминге в ЮАР, блокируется с нулевым балансом и не уходит в дикий минус.
Еще один пример использования — накопление данных и дальнейшая их обработка. Такой вариант возможен, когда у нас тысячи записей с оборудования (GGSN-SGSN, телефония): выбрасывать все эти записи в детализацию абонента — полнейшее безумие, не говоря уже о том, что мы адски нагружаем все системы таким количеством мелких данных. По этой причине подойдет следующая схема, которая разрешает проблему.

  1. Получение данных с оборудования.
  2. Агрегация данных на предбиллинге (ждем, когда соберутся все нужные записи по какому-либо условию).
  3. Отправка данных в конечный биллинг.
  4. Итог — вместо 10 тысяч записей мы отправили одну с агрегирующим значением счетчика потребленного интернет-трафика. Сделали всего один запрос к базе данных и сэкономили кучу ресурсов, включая электричество!
Это всего лишь типовые схемы работы. Формат статьи не позволяет привести примеры более сложных схем (например, Big Data), но они тоже встречаются.

Предбиллинг Hewlett-Packard Internet Usage Manager (HP IUM)
Чтобы было понятнее, как это работает и где здесь могут возникнуть проблемы, давайте возьмем систему предбиллинга Hewlett-Packard Internet Usage Manager (HP IUM, в обновленном варианте eIUM) и на ее примере посмотрим, как работает подобный софт.

Представьте большую мясорубку, в которую бросают мясо, овощи, буханки хлеба — все, что только можно. То есть на входе самые разные продукты, но на выходе все они приобретают одинаковую форму. Мы можем поменять решетку и получим на выходе другую форму, но принцип и путь обработки наших продуктов останется прежний — шнек, нож, решетка. Это и есть классическая схема предбиллинга: сбор, обработка и вывод данных. В предбиллинге IUM звенья этой цепочки называются encapsulator, aggregator и datastore.

Тут необходимо понимать, что на входе у нас должна присутствовать полнота данных — некий минимальный объем информации, без которого дальнейшая обработка бесполезна. При отсутствии какого-то блока или элемента данных мы получаем ошибку или предупреждение, что обработка невозможна, так как операции не могут быть выполнены без этих данных.

Поэтому очень важно, чтобы оборудование формировало файлы-записи, которые имели бы строго определенный и установленный производителем набор и тип данных. Каждый тип оборудования — отдельный обработчик (коллектор), который работает только со своим форматом входных данных. Например, нельзя просто так взять и закинуть файл с оборудования CISCO PGW-SGW с интернет-трафиком мобильных абонентов на коллектор, который обрабатывает поток с оборудования фиксированной связи Iskratel Si3000.

Если мы так сделаем, то в лучшем случае получим исключение при обработке, а в худшем у нас встанет вся обработка конкретного потока, так как обработчик-коллектор упадет с ошибкой и будет ждать, пока мы не решим проблему с «битым» с его точки зрения файлом. Здесь можно заметить, что все системы предбиллинга, как правило, критично воспринимают данные, на обработку которых не был настроен конкретный обработчик-коллектор.

Изначально поток разобранных данных (RAW) формируется на уровне энкапсулятора и уже здесь же может быть подвергнут преобразованиям и фильтрации. Так делается, если нужно до схемы агрегации произвести с потоком изменения, которые должны быть в дальнейшем применены ко всему потоку данных (когда он будет проходить через различные схемы агрегации).


Файлы (.cdr, .log и прочие) с записями об активности пользователей-абонентов поступают как с локальных источников, так и с удаленных (FTP, SFTP), возможны варианты работы и по другим протоколам. Разбирает файлы парсер, с помощью разных классов Java.

Так как система предбиллинга в нормальном режиме работы не предназначена для хранения истории обрабатываемых файлов (а их может быть сотни тысяч в сутки), то после обработки файл на источнике удаляется. По разным причинам файл не всегда может быть удален корректно. В результате бывает, что записи из файла обрабатываются повторно или с большим опозданием (когда удалить файл получилось). Для предотвращения таких дублей существуют механизмы защиты: проверка на дубли файлов или записей, проверка на время в записях и прочее.

Одно из самых уязвимых мест здесь — это критичность к размеру данных. Чем больше мы храним данных (в памяти, в базах данных), тем медленнее мы обрабатываем новые данные, тем больше мы потребляем ресурсов и в итоге все равно достигаем предела, после которого вынуждены удалить старые данные. Таким образом, для хранения этих метаданных обычно используются вспомогательные БД (MySQL, TimesTen, Oracle и так далее). Соответственно, получаем еще одну систему, которая влияет на работу предбиллинга с вытекающими вопросами безопасности.

Как работает предбиллинг?
Когда-то на заре подобных систем использовались языки, которые позволяли эффективно работать с регулярными выражениями, — таким, например, был Perl. Фактически почти весь предбиллинг, если не брать во внимание работу с внешними системами, — это правила разбора-преобразования строк. Естественно, лучше регулярных выражений тут ничего не найти. Постоянно растущий объем данных и повышение критичности к времени вывода новой услуги на рынок сделали применение таких систем невозможным, так как тестирование и внесение изменений занимало много времени, масштабируемость была низкой.

Современный предбиллинг — это набор модулей, как правило написанных на Java, которыми можно управлять в графическом интерфейсе с помощью стандартных операций копирования, вставки, перемещения, перетаскивания. Работа в этом интерфейсе проста и понятна.

Для работы в основном используется операционная система на базе Linux или Unix, реже — Windows.

Основные проблемы обычно связаны с процессом тестирования или выявления ошибок, так как данные проходят по множеству цепочек правил и обогащаются данными из других систем. Видеть, что происходит с ними на каждой стадии, не всегда удобно и понятно. Поэтому приходится искать причину, отлавливая изменения нужных переменных при помощи логов.


Слабость этой системы — ее сложность и человеческий фактор. Любое исключение провоцирует потерю данных или неправильное их формирование.

Обрабатываются данные последовательно. Если на входе у нас ошибка-исключение, которая не позволяет корректно принять и обработать данные, встает весь входной поток либо порция некорректных данных отбрасывается. Разобранный RAW-поток поступает на следующую стадию — агрегацию. Схем агрегации может быть несколько, и они изолированы друг от друга. Как если единый поток воды, поступающий в душ, пройдя через решетку лейки, разделится на разные потоки — одни толстые, другие совсем тонкие.

После агрегации данные готовы к доставке потребителю. Доставка может идти как напрямую в базы данных, так и записью в файл и отправкой его дальше либо просто записью в хранилище предбиллинга, где они будут лежать, пока его не опустошат.

После обработки на первом уровне данные могут передаваться на второй и далее. Такая лестница необходима для увеличения скорости обработки и распределения нагрузки. На второй стадии к нашему потоку данных может добавляться другой поток, смешиваться, делиться, копироваться, объединяться и так далее. Конечная стадия — это всегда доставка данных в системы, которые его потребляют.

В задачи предбиллинга не входит (и это правильно!):

  • мониторить, поступили и доставлены ли входные-выходные данные, — этим должны заниматься отдельные системы;
  • шифровать данные на любой стадии.
Далеко не весь поток поступающих данных подвергается обработке. Обрабатываются только те данные, которые нужны для работы. Тратить время на остальные нет смысла до того момента, пока они не понадобятся. Таким образом, из RAW-потока нужно брать только то, что нужно для схем агрегации. Из RAW (текстовые файлы, результаты запросов, бинарные файлы) парсится только необходимое.

Приватность предбиллинга
Здесь у нас полный расколбас! Начнем с того, что в задачи предбиллинга не входит защита данных в принципе. Разграничение доступа к предбиллингу нужно и возможно на разных уровнях (интерфейс управления, операционная система), но если мы заставим его заниматься шифрованием данных, то сложность и время обработки настолько увеличатся, что это будет совершенно неприемлемо и непригодно для работы биллинга.

Зачастую время от использования услуги до отображения этого факта в биллинге не должно превышать нескольких минут. Как правило, метаданные, которые нужны для обработки конкретной порции данных, хранятся в БД (MySQL, Oracle, Solid). Входные и выходные данные практически всегда лежат в директории конкретного потока-коллектора. Поэтому доступ к ним может иметь любой, кому он разрешен (например, root-пользователь).

Сама конфигурация предбиллинга с набором правил, сведениях о доступах к базам данных, FTP и прочему хранится в зашифрованном виде в файловой базе данных. Если неизвестен логин-пароль для доступа в предбиллинг, то выгрузить конфигурацию не так просто.

Любое внесение изменений в логику обработки (правила) фиксируется в лог-файл конфигурации предбиллинга (кто, когда и что менял).

Даже если внутри предбиллинга данные передаются по цепочкам обработчиков-коллекторов напрямую (минуя выгрузку в файл), данные все равно временно хранятся в виде файла в директории обработчика, и при желании к нему можно получить доступ.

Данные, которые проходят обработку на предбиллинге, обезличены: они не содержат ФИО, адресов и паспортных данных. Поэтому даже если вы получите доступ к этой информации, то персональных данных абонента отсюда не узнать. Зато можно поймать какую-то инфу по конкретному номеру, IP либо другому идентификатору.

Имея доступ к конфигурации предбиллинга, вы получаете данные для доступа ко всем смежным системам, с которыми он работает. Как правило, доступ к ним ограничен непосредственно с сервера, на котором работает предбиллинг, но так бывает не всегда.

Если вы доберетесь до директорий, где хранятся файловые данные обработчиков, то сможете вносить изменения в эти файлы, которые ждут своей отправки потребителям. Часто это самые обычные текстовые документы. Тогда картина такая: предбиллинг данные принял и обработал, но в конечную систему они не пришли — пропали в «черной дыре».

И выяснить причину этих потерь будет сложно, так как потеряна только часть данных. В любом случае эмулировать потерю будет невозможно при дальнейшем поиске причин. Можно посмотреть данные на входе и выходе, но понять, куда они делись, будет невозможно. Злоумышленнику при этом остается только замести следы в операционной системе.

Last edited by a moderator:

До нового года осталось

About us

  • Welcome to our "International Forum of private detectives", detectives of the CIS, where not only private detectives and detective agencies from different regions of the world are represented, but also professionals from other areas of personal, social and state security: employees of information and analytical, consulting agencies, non-state security structures, practicing business intelligence officers and other professionals. With the help of this resource you can find out as much useful information as possible: find your relatives, lost friends. Find out the addresses and phone numbers, including mobile phones, of persons you are interested in and much more. The forum contains e-mail:, and telephones: + 7-812-715-15-08, + 7-921-423-20-02 where you can leave your suggestions and comments. Yours faithfully, President of NP "MOD" Andrey Nikolaevich Matushkin.

Fast Navigation

User's menu