Журналирование, мониторинг и разбор инцидентов
Настраиваем сбор событий со всех уровней инфраструктуры, защиту журналов от изменения, выявление подозрительной активности и порядок разбора инцидентов. После происшествия должно быть возможно ответить, что именно произошло, когда, через кого и какие данные затронуты. Без журналов на эти вопросы ответить нечем.
Коротко о задаче
Разговор о журналировании обычно начинается после инцидента, и тогда же выясняется, что журналов нет.
Варианты неутешительны и повторяются. События вообще не собираются: на серверах включено то, что было по умолчанию, и хранится три дня. Собираются, но лежат на том же сервере, который скомпрометировали, и вместе с ним удалены. Собираются и хранятся, но в них нет нужного: вход в систему записан, а действия внутри — нет, поэтому непонятно, что человек делал. Есть всё, но никто никогда в них не смотрел, и заметить активность на протяжении месяцев было некому.
Отдельный слой — обязательства по срокам. При неправомерной передаче персональных данных оператор уведомляет регулятора в течение суток о факте и в течение трёх суток о результатах внутреннего расследования. Провести расследование за трое суток, начиная с нуля, при отсутствии журналов невозможно.
И третье: журналы нужны не только после атаки. Уволившийся сотрудник выгрузил клиентскую базу, спор с подрядчиком о том, кто изменил настройку, претензия клиента о том, что заявку никто не обрабатывал. Всё это вопросы к журналу.
Что входит в услугу
- Определение состава событий
Разбираем, какие события нужны для ответа на вопросы, которые действительно возникают: входы и попытки входа, изменения прав, действия администраторов, доступ к чувствительным данным, выгрузки и экспорт, изменения конфигураций, операции с резервными копиями.
- Настройка журналирования
Включаем и настраиваем сбор на всех уровнях: операционные системы, гипервизор, сетевое оборудование, базы данных, прикладные системы, средства защиты.
- Централизованный сбор
События уходят с источника на отдельный узел сразу. Журнал, который хранится только на источнике, теряется вместе с ним.
- Защита журналов
Запрет изменения и удаления записей, отдельные права на доступ к журналам, контроль обращений к ним. Журнал, который можно поправить, доказательством не является.
- Сроки хранения
Определяем глубину хранения по типам событий с учётом требований к вашей отрасли и практической потребности: инциденты часто обнаруживаются спустя месяцы.
- Выявление подозрительной активности
Правила на характерные признаки: вход в нерабочее время из необычного места, серия неудачных попыток, массовая выгрузка данных, создание учётной записи с административными правами, удаление журналов. Смотрите {{ссылка: Мониторинг IT-инфраструктуры 24/7}}.
- Порядок реагирования
Регламент: кто получает оповещение, кто принимает решение, порядок изоляции, сбора данных и восстановления, кто общается с руководством и клиентами.
- Расследование инцидентов
Восстановление хронологии, определение точки входа и охвата, оценка затронутых данных, подготовка выводов и корректирующих мер.
- Уведомление регулятора
Подготовленные шаблоны и заранее собранные сведения для уведомления в установленные законом сроки при инцидентах с персональными данными. Смотрите {{ссылка: Приведение информационных систем в соответствие с 152-ФЗ}}.
Что это даёт заказчику
- На вопросы есть ответы. Что произошло, когда, через кого и какие данные затронуты.
- Журналы переживают инцидент. Централизованный сбор и защита от изменения.
- Активность замечают. Правила выявления работают постоянно, а не когда кто-то решил посмотреть.
- Сроки уведомления выполнимы. Материалы для расследования собраны заранее, а не ищутся в момент кризиса.
- Споры разрешаются фактами. Кто изменил, кто выгрузил, кто заходил — вопрос к журналу, а не к памяти.
- Готовность к аудиту. Наличие и защита журналов проверяются в регулируемых отраслях на каждой проверке.
Как мы работаем
Начинаем с перечня вопросов, на которые вы хотите уметь отвечать. Собирать всё подряд дорого и бесполезно: важен не объём, а наличие нужного.
Правила выявления настраиваем по фактическому поведению вашей инфраструктуры и первое время калибруем. Правило, дающее двадцать ложных срабатываний в день, отключат через неделю.
Порядок реагирования оформляем письменно и проговариваем с ответственными до того, как он понадобится.
Наш опыт
Мы проектируем аудиторский след как часть архитектуры разрабатываемых систем. В платформе фармаконадзора журналируется более четырёхсот типов действий пользователей: создание и изменение записей, смена статусов, назначения, выгрузки, действия администраторов. Каждое событие пишется неизменяемой записью с автором, временем, прежним и новым значением.
На этой системе заказчик прошёл более тридцати аудитов клиентов и более десяти проверок регуляторов. Целостность данных и аудиторский след проверяют на каждом, и обычно с этого начинают. Смотрите {{ссылка: Целостность данных и аудиторский след: ALCOA+, Data Integrity}}.
Расскажите, что у вас сейчас журналируется и как долго хранится. Начнём с перечня вопросов, на которые нужно уметь отвечать.
Давайте создавать вместе!
Свяжитесь с нами и мы проконсультируем по вопросам реализации IT-решений и найдем лучший подход к разработке
Контакты
Офис: г. Казань, ул. Островского, 57Б, оф. 110
Почта: info@nabla-lab.ru
Телефон: +7 (965) 595-62-78