Логи логов
Разработчики ТСЗИ стараются зафиксировать и сохранить в логах все действия пользователя. Это очень полезное дело. Но ещё полезнее сохранять историю действий админа. Но не для того, чтобы "сторожить сторожей".
Свой жизненный цикл есть у всех правил и настроек средств защиты. Их придумывают не просто так, а из каких-то предпосылок, например, по итогам инцидента. Их вводят и распространяют на определённые группы пользователей. Их проверяют и пересматривают в зависимости от эффективности и конфликтов с другими правилами. Наконец, их отменяют или деактивируют до лучших времён. Каждое из этих действий подлежит документированию. Из записей должно быть понятно, кто, когда и почему каждое правило придумал, включил или отключил.
Администратор может смениться. Аудитор может проверить адекватность политики безопасности. Начальник может захотеть рассмотреть жалобу пользователя. Наконец сам сотрудник через год должен вспомнить, зачем он вводил какое-то ограничение. Для всего для этого необходимо логирование и документирование настроек.
По своей сложности и развесистости настройки ТСЗИ приближаются к компьютерным программам. А программистов, как известно, усиленно дрючат на предмет документирования и менеджмента версий (Revision control, Version control). Потому что давно установлено: в ряде случаев будет проще написать код с нуля, чем разобрать и модифицировать чужой. Или даже свой собственный, но написанный в пьяном виде давно.
Администраторов безопасности, в отличие от кодеров, пока ещё не строят в три шеренги.
Программный код стоит хороших денег, именно поэтому он должен содержаться в порядке, поэтому на уход за ним не жалеют человеко-часов. А настройки безопасности - бесплатные, что ли? Просто их цену ещё не научились убедительно подсчитывать.
Свой жизненный цикл есть у всех правил и настроек средств защиты. Их придумывают не просто так, а из каких-то предпосылок, например, по итогам инцидента. Их вводят и распространяют на определённые группы пользователей. Их проверяют и пересматривают в зависимости от эффективности и конфликтов с другими правилами. Наконец, их отменяют или деактивируют до лучших времён. Каждое из этих действий подлежит документированию. Из записей должно быть понятно, кто, когда и почему каждое правило придумал, включил или отключил.
Администратор может смениться. Аудитор может проверить адекватность политики безопасности. Начальник может захотеть рассмотреть жалобу пользователя. Наконец сам сотрудник через год должен вспомнить, зачем он вводил какое-то ограничение. Для всего для этого необходимо логирование и документирование настроек.
По своей сложности и развесистости настройки ТСЗИ приближаются к компьютерным программам. А программистов, как известно, усиленно дрючат на предмет документирования и менеджмента версий (Revision control, Version control). Потому что давно установлено: в ряде случаев будет проще написать код с нуля, чем разобрать и модифицировать чужой. Или даже свой собственный, но написанный в пьяном виде давно.
Администраторов безопасности, в отличие от кодеров, пока ещё не строят в три шеренги.
Программный код стоит хороших денег, именно поэтому он должен содержаться в порядке, поэтому на уход за ним не жалеют человеко-часов. А настройки безопасности - бесплатные, что ли? Просто их цену ещё не научились убедительно подсчитывать.