ГОСТР ИСО 27789—2016
А.8 Случай исчезающих записей аудита. Хранилище данных аудита как цель
Кто-то пытается скрыть свои следы. Во всех сервисах / системах должно быть установлено одно и то же вре
мя для того, чтобы заметить пробелы в данных, потому что для злоумышленника проще всего уничтожить часть
аудита во время атаки или незаконной операции. Выборочное уничтожение аудита является сложной задачей,
так что. как правило, разрыв заметен. Вторая особенность атаки, связанной с аудитом, это атака самого сервера
вре мени. так что существует необходимость провести аудит точности сервера времени (было ли сбросов больше,
чем обычно?) и аудит клиента для того, чтобы раскрыть возможные инциденты.
Примечание по внедрению. Маршрутизаторы являются хорошим местом (закрытым и подключенным), чтобы
служить в качестве серверов времени для того, чтобы гарантировать, что системы синхронизированы. Приложе ние
может/должно быть готовым обнаружить «ненормальные» пробелы в трафике аудита. «Нормальный» трафик аудита
должен определяться на местном уровне.
Так как серверы аудита являются главной мишенью, то как можно проверить аудитом, подвергается ли на
падению сервер аудита и что мы должны контролировать, если имеет место какое-либо необычное поведение, и
входит ли это в область применения сервиса(ов) аудита.
П ри м е ча н и я
1 Большинство систем используют NTP. который создает записи аудита; они должны сохраняться в хранили
ще данных аудита и контролироваться.
2 Серверы аудита сами по себе должны быть усилены и защищены.
3 Необходимо рассмотреть возможность сохранения местных копий записей аудита.
Согласованное время является обязательной функциональной возможностью и зависит от сервиса аудита
(оно должно использоваться и работать, а не быть просто доступным).
Требование. Хранилище аудита и ассоциированные сервисы должны быть защищены, включая средства
управления доступом и средства аудита.
А.9 Случай хакера, создающего ложные записи аудита
Современный злоумышленник подключает ноутбук, который создает ложные записи аудита, чтобы скрыть
тот факт, что он отключил систему аудита машины, которая подвергается атаке.
(Некоторые локальные политики могут решить использовать цифровые подписи для того, чтобы обнаружить
сокрытие записей аудита.)
А.10 Случай просмотра записей аудита хакером и их злонамеренного использования
Записи аудита могут также быть уязвимыми для анализа трафика или изменений с целью удаления важной
информации непосредственно во время передачи.
Смягчение. Не вносить личную медицинскую информацию в записи аудита! Если это невозможно, записи
аудита могут быть зашифрованы либо по каждой записи, либо по сессии / потоку.
А.11 Случай странного (уполномоченного/неуполномоченного) изменения конфигурации
Некто, действуя как системный администратор, устанавливает обновление программного обеспечения мест
ной системы. (Альтернатива; вредоносные атаки / случайный злоумышленник устанавливает HTTP-регистратор и
фиксирует весь трафик HTTP для обнаружения уязвимостей системы.)
Процесс аудита должен фиксировать дату, время и место обновления, а также «описание изменения», кото
рое включает в себя номера версий программного обеспечения, контрольные суммы файлов и т. д.
Хранилище аудита (или хранилище аудита конфигурации) должно быть время от времени исследовано, что
бы убедиться, что авторизованные обновления конфигурации имели место, когда должны были, и обнаружить не
санкционированные или неожиданные изменения конфигурации.
Журнал / сервис аудита также должен записывать все изменения конфигурации, обновления и т. д.. в том
числе установку программного обеспечения, установку оборудования и изменения конфигурации.
Система аудита должна поддерживать корректирующие действия, а также выполняемый в реальном време
ни анализ для обнаружения неблагоприятных происходящих событий.
Желательно, что более трудно, распространять это на оборудование.
А.12 Случай пользователя, пытающегося взломать пароль методом грубой силы
Сервер аудита получает отчеты о множестве сбоев при входе в систему и должен быстро установить флаг /
запустить сигнал тревоги.
31