Регистрация использования разблокированных портов ввода-вывода информации СВТ.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Должно фиксироваться отдельным событием защиты информации использование ранее заблокированных портов ввода-вывода средств вычислительной техники (мера ПУИ.18).
Главная цель меры — обеспечить видимость случаев временной разблокировки порта для служебных целей и последующего его использования: сам факт разблокировки порта создаёт временное окно повышенного риска, и без регистрации фактического использования разблокированного порта невозможно подтвердить, что оно ограничилось заявленной служебной задачей.
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииТехническая реализация обеспечивается настройкой средства контроля устройств и портов ввода-вывода (мера ПУИ.18) на автоматическое формирование события защиты информации при каждом факте подключения устройства к порту, временно переведённому в разрешённый режим, с фиксацией типа подключённого устройства, времени и инициатора разблокировки, и передачей события в SIEM-систему.
Класс используемых средств — встроенный механизм журналирования средства контроля устройств (Device Control), система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: DeviceLock DLP (журнал использования портов), Splunk и пр.
- Российские сертифицированные (ФСТЭК): Kaspersky Endpoint Security для бизнеса (модуль Device Control), MaxPatrol SIEM, KUMA и др.
- Открытый код: Wazuh (сбор событий подключения устройств) и др.
- Конфигурация журналирования использования разблокированных портов ввода-вывода.
- Выгрузка зарегистрированных фактов использования разблокированных портов за проверяемый период с сопоставлением заявленной служебной задаче.
- Итоги интервью с ответственным за администрирование средств контроля устройств.
- Регистрируется только факт разблокировки порта, но не факт последующего фактического подключения устройства к нему;
- Событие не содержит сведений об инициаторе разблокировки, что не позволяет установить ответственного за принятое решение;
- Использование порта после истечения заявленного срока служебной необходимости не приводит к автоматической повторной блокировке и отдельному событию;
- События не передаются в SIEM-систему, доступны только в локальном журнале средства контроля устройств.
Регистрация операций, связанных с осуществлением доступа работниками финансовой организации к ресурсам сети Интернет.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Каждое обращение работника к ресурсам сети Интернет должно фиксироваться как событие защиты информации.
Главная цель меры — обеспечить историю обращений, позволяющую установить, кто и когда посещал конкретный ресурс, и оперативно выявить причастного сотрудника при расследовании утечки данных, произошедшей через веб-канал (меры ПУИ.2, ПУИ.11, ПУИ.12).
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииТехническая реализация обеспечивается настройкой веб-прокси (шлюза доступа в Интернет) на журналирование каждого обращения пользователя к ресурсам сети Интернет с фиксацией учётной записи (или сетевого адреса, сопоставляемого с учётной записью), адреса ресурса, времени и результата (разрешено/заблокировано), и последующей передачей событий в SIEM-систему для централизованного хранения и анализа.
Класс используемых средств — встроенный механизм журналирования веб-прокси (Secure Web Gateway) или NGFW, система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: Zscaler Internet Access (журнал обращений), Palo Alto Networks и пр.
- Российские сертифицированные (ФСТЭК): «Континент», UserGate (журнал веб-фильтрации), MaxPatrol SIEM, KUMA и др.
- Открытый код: Squid (access log) в сочетании с Wazuh (централизованный сбор и анализ) и др.
- Конфигурация журналирования обращений работников к ресурсам сети Интернет на веб-прокси.
- Выгрузка зарегистрированных обращений к ресурсам сети Интернет за проверяемый период.
- Итоги интервью с ответственным за администрирование сетевой инфраструктуры.
- Регистрация обращений выполняется по сетевому адресу устройства, без сопоставления с конкретной учётной записью пользователя, что затрудняет установление причастного лица;
- Регистрируются только заблокированные обращения, разрешённые (успешные) посещения ресурсов не фиксируются;
- Журнал обращений хранится с недостаточным для расследования сроком (менее срока, установленного мерами МАС.15/16 для данных регистрации);
- Обращения по зашифрованному (HTTPS) трафику фиксируются только по домену без детализации конкретного адреса страницы.
Регистрация фактов вывода информации на печать.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Каждый факт вывода информации на печать должен фиксироваться как отдельное событие защиты информации.
Главная цель меры — обеспечить возможность постфактум установить, кто, что и когда распечатал, при расследовании утечки конфиденциальной информации через бумажный носитель, дополняя техническую защиту, реализуемую мерами ПУИ.3, ПУИ.15, ПУИ.16.
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииТехническая реализация обеспечивается настройкой сервера печати и (или) модуля контроля печати DLP-системы на журналирование каждого задания печати с фиксацией учётной записи пользователя, наименования документа, количества страниц, устройства печати и времени, и последующей передачей событий в SIEM-систему.
Класс используемых средств — системы управления печатью (Print Management) и (или) встроенный механизм журналирования модуля контроля печати DLP-системы, система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: PaperCut MF (журнал заданий печати), Forcepoint DLP и пр.
- Российские сертифицированные (ФСТЭК): InfoWatch Traffic Monitor, Solar Dozor, MaxPatrol SIEM, KUMA и др.
- Открытый код: CUPS (журнал печати) в сочетании с Wazuh (централизованный сбор) и др.
- Конфигурация журналирования фактов вывода информации на печать.
- Выгрузка зарегистрированных фактов печати за проверяемый период с сопоставлением конкретному пользователю и документу.
- Итоги интервью с ответственным за администрирование печатной инфраструктуры.
- Регистрация фактов печати охватывает не все многофункциональные устройства организации, часть локальных (не сетевых) принтеров исключена из-под контроля;
- Событие фиксирует только факт печати и наименование документа, без сохранения содержимого или его цифрового отпечатка, что не позволяет впоследствии восстановить, что именно было напечатано;
- События печати не передаются в SIEM-систему, доступны только в локальной консоли сервера печати;
- Журнал печати не сопоставляется с результатами контентного анализа (мера ПУИ.15) для выявления случаев печати конфиденциальной информации.
Регистрация результатов выполнения контентного анализа информации, предусмотренного мерами ПУИ.5, ПУИ.11, ПУИ.15, ПУИ.17 таблицы 30.
Уровень защиты информации 3-Н, 2-Т, 1-Т.
Пояснение
Результаты контентного анализа, выполняемого мерами ПУИ.5 (почта), ПУИ.11 (веб), ПУИ.15 (печать) и ПУИ.17 (копирование на носители), должны фиксироваться как отдельные события защиты информации, включая как случаи блокировки, так и разрешённые прохождения проверки.
Главная цель меры — обеспечить единую, сводную по всем каналам утечки историю результатов контентного анализа: без такой регистрации результаты разрозненно остаются в локальных журналах каждого канала, что не позволяет проследить попытку передачи одной и той же конфиденциальной информации разными каналами (например, сначала через почту, затем через печать) как единую цепочку событий.
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииТехническая реализация обеспечивается настройкой DLP-системы на формирование единого события по каждому результату контентного анализа независимо от канала (почта, веб, печать, копирование), с фиксацией канала, результата (заблокировано/разрешено), сработавшего правила и учётной записи пользователя, и передачей всех событий в единое хранилище (SIEM или собственный инцидент-модуль DLP-системы) для сквозной корреляции по всем каналам.
Класс используемых средств — системы предотвращения утечек информации (DLP) с единым модулем инцидент-менеджмента, система централизованного сбора и корреляции событий (SIEM).
Примеры таких средств:
- Иностранные: Forcepoint DLP (Incident Manager), Symantec (Broadcom) DLP и пр.
- Российские сертифицированные (ФСТЭК): InfoWatch Traffic Monitor (единая консоль инцидентов), Solar Dozor и др.
- Открытый код: полноценной единой консоли инцидент-менеджмента DLP-класса в открытых решениях практически не представлено.
- Конфигурация единого инцидент-модуля (консоли) DLP-системы, объединяющего результаты контентного анализа по всем каналам.
- Выгрузка зарегистрированных результатов контентного анализа за проверяемый период по каждому из каналов (почта, веб, печать, копирование).
- Итоги интервью с ответственным за администрирование DLP-системы.
- Результаты контентного анализа разных каналов фиксируются в разрозненных журналах соответствующих подсистем, единая сводная регистрация не реализована;
- Регистрируются только заблокированные события, разрешённые прохождения контентной проверки не фиксируются, что не позволяет оценить полную картину применения меры;
- Сопоставление событий по разным каналам для выявления единой цепочки попыток утечки одной и той же информации не проводится;
- Срок хранения зарегистрированных результатов контентного анализа не соответствует установленному для данных регистрации событий защиты информации (меры МАС.15/16).
Регистрация действий по учету и снятию с учета МНИ, предназначенных для хранения информации конфиденциального характера.
Уровень защиты информации 3-О, 2-О, 1-О.
Пояснение
Мера требует регистрации в качестве события защиты информации каждого действия по учёту и снятию с учёта машинных носителей информации (МНИ), предназначенных для хранения информации конфиденциального характера (мера ПУИ.20).
Главная цель меры — обеспечить ретроспективную прослеживаемость изменений реестра учтённых носителей: без регистрации самих действий по учёту и снятию с учёта невозможно достоверно установить, когда конкретный носитель был поставлен на учёт, кем, и когда и по чьей инициативе снят с учёта, что необходимо при расследовании инцидента, связанного с носителем.
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииМера реализуется исключительно организационными методами и предполагает регистрацию каждого действия по постановке на учёт и снятию с учёта МНИ непосредственно в реестре учтённых носителей (мера ПУИ.20) с фиксацией даты, инициатора действия и основания (приказ, служебная записка), а не только актуального статуса носителя без истории его изменений.
- Реестр учтённых МНИ с историей действий по постановке на учёт и снятию с учёта (не только актуальным статусом);
- Выгрузка зарегистрированных действий по учёту и снятию с учёта носителей за проверяемый период;
- Итоги интервью с ответственным за учёт МНИ.
- Реестр хранит только актуальный статус носителя, история предыдущих действий по учёту и снятию с учёта не сохраняется при обновлении записи;
- Основание для снятия носителя с учёта (приказ, служебная записка) не фиксируется, отражается только сам факт снятия;
- Действия по учёту и снятию с учёта, выполненные в устной или неформальной форме, не находят отражения в реестре;
- Регистрация действий по учёту не защищена от последующего редактирования задним числом ответственным за ведение реестра.
Регистрация фактов стирания информации с МНИ.
Уровень защиты информации 3-О, 2-О, 1-О.
Пояснение
Каждый факт стирания информации с машинных носителей информации (МНИ), выполненного в рамках мер ПУИ.23—ПУИ.26, подлежит регистрации в качестве события защиты информации.
Главная цель меры — зафиксировать отдельным событием сам факт и результат выполненного стирания, дополняя формируемый техническими средствами протокол (мера ПУИ.23) организационной регистрацией: это позволяет впоследствии подтвердить, что стирание было выполнено в отношении конкретного носителя, в установленный срок и уполномоченным лицом, а не только предъявить сам факт наличия протокола без привязки к организационному контролю.
РеализацияПроверочные процедурыНедостаткиКомпенсационные мерыВыявленные коллизииМера реализуется исключительно организационными методами и предполагает регистрацию каждого факта стирания информации с МНИ в журнале (реестре) учёта носителей (мера ПУИ.20) с указанием даты стирания, применённого метода (мера ПУИ.23/24/25/26), ответственного лица и ссылки на технический протокол (сертификат) стирания как подтверждающий документ.
- Журнал (реестр) регистрации фактов стирания информации с МНИ со ссылкой на технические протоколы стирания;
- Выгрузка зарегистрированных фактов стирания за проверяемый период с сопоставлением конкретному носителю и ответственному лицу;
- Итоги интервью с ответственным за вывод из эксплуатации и перезакрепление МНИ.
- Регистрация фактов стирания в организационном журнале ведётся не по всем случаям, для части носителей имеется только технический протокол без организационной записи;
- Ссылка на технический протокол стирания в журнале регистрации отсутствует, что не позволяет быстро сопоставить организационную запись с техническим подтверждением;
- Ответственное за выполнение стирания лицо не фиксируется как отдельное поле записи;
- Журнал регистрации фактов стирания не защищён от редактирования задним числом.