Журналирование, мониторинг и разбор инцидентов

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

Коротко о задаче

Разговор о журналировании обычно начинается после инцидента, и тогда же выясняется, что журналов нет.

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

Отдельный слой — обязательства по срокам. При неправомерной передаче персональных данных оператор уведомляет регулятора в течение суток о факте и в течение трёх суток о результатах внутреннего расследования. Провести расследование за трое суток, начиная с нуля, при отсутствии журналов невозможно.

И третье: журналы нужны не только после атаки. Уволившийся сотрудник выгрузил клиентскую базу, спор с подрядчиком о том, кто изменил настройку, претензия клиента о том, что заявку никто не обрабатывал. Всё это вопросы к журналу.

Что входит в услугу

  • Определение состава событий

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

  • Настройка журналирования

Включаем и настраиваем сбор на всех уровнях: операционные системы, гипервизор, сетевое оборудование, базы данных, прикладные системы, средства защиты.

  • Централизованный сбор

События уходят с источника на отдельный узел сразу. Журнал, который хранится только на источнике, теряется вместе с ним.

  • Защита журналов

Запрет изменения и удаления записей, отдельные права на доступ к журналам, контроль обращений к ним. Журнал, который можно поправить, доказательством не является.

  • Сроки хранения

Определяем глубину хранения по типам событий с учётом требований к вашей отрасли и практической потребности: инциденты часто обнаруживаются спустя месяцы.

  • Выявление подозрительной активности

Правила на характерные признаки: вход в нерабочее время из необычного места, серия неудачных попыток, массовая выгрузка данных, создание учётной записи с административными правами, удаление журналов. Смотрите {{ссылка: Мониторинг IT-инфраструктуры 24/7}}.

  • Порядок реагирования

Регламент: кто получает оповещение, кто принимает решение, порядок изоляции, сбора данных и восстановления, кто общается с руководством и клиентами.

  • Расследование инцидентов

Восстановление хронологии, определение точки входа и охвата, оценка затронутых данных, подготовка выводов и корректирующих мер.

  • Уведомление регулятора

Подготовленные шаблоны и заранее собранные сведения для уведомления в установленные законом сроки при инцидентах с персональными данными. Смотрите {{ссылка: Приведение информационных систем в соответствие с 152-ФЗ}}.

Что это даёт заказчику

  • На вопросы есть ответы. Что произошло, когда, через кого и какие данные затронуты.
  • Журналы переживают инцидент. Централизованный сбор и защита от изменения.
  • Активность замечают. Правила выявления работают постоянно, а не когда кто-то решил посмотреть.
  • Сроки уведомления выполнимы. Материалы для расследования собраны заранее, а не ищутся в момент кризиса.
  • Споры разрешаются фактами. Кто изменил, кто выгрузил, кто заходил — вопрос к журналу, а не к памяти.
  • Готовность к аудиту. Наличие и защита журналов проверяются в регулируемых отраслях на каждой проверке.

Как мы работаем

Начинаем с перечня вопросов, на которые вы хотите уметь отвечать. Собирать всё подряд дорого и бесполезно: важен не объём, а наличие нужного.

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

Порядок реагирования оформляем письменно и проговариваем с ответственными до того, как он понадобится.

Наш опыт

Мы проектируем аудиторский след как часть архитектуры разрабатываемых систем. В платформе фармаконадзора журналируется более четырёхсот типов действий пользователей: создание и изменение записей, смена статусов, назначения, выгрузки, действия администраторов. Каждое событие пишется неизменяемой записью с автором, временем, прежним и новым значением.

На этой системе заказчик прошёл более тридцати аудитов клиентов и более десяти проверок регуляторов. Целостность данных и аудиторский след проверяют на каждом, и обычно с этого начинают. Смотрите {{ссылка: Целостность данных и аудиторский след: ALCOA+, Data Integrity}}.

Расскажите, что у вас сейчас журналируется и как долго хранится. Начнём с перечня вопросов, на которые нужно уметь отвечать.

Давайте создавать вместе!

Свяжитесь с нами и мы проконсультируем по вопросам реализации IT-решений и найдем лучший подход к разработке

Контакты

Офис: г. Казань, ул. Островского, 57Б, оф. 110
Почта: info@nabla-lab.ru
Телефон: +7 (965) 595-62-78