среда, 17 марта 2010 г.

Практика ИБ \ Наиболее распространенные ошибки при построении системы ИБ

Ниже представлены наиболее распространенные ошибки при построении системы информационной безопасности, которые следует избегать. Это переведенная, расширенная и слегка адаптированная "шпаргалка" (How to Suck at Information Security) с сайта Ленни Зельцера.

Политика безопасности и Соответствие
  • Игнорировать требования регуляторов
  • Надеяться, что пользователи будут читать политику безопасности, потому что Вы попросили их об этом
  • Использовать шаблоны политик без предварительной их адаптации под конкретные условия
  • Браться за полное внедрение комплексного стандарта безопасности (такого как ISO 27001/27002) до того, как Ваша компания реально будет к этому готова
  • Создавать политики безопасности, которые Вы не сможете реализовать на практике
  • Внедрять политики, которые не были надлежащим образом согласованы и приняты
  • Вслепую следовать требованиям регуляторов без создания целостной архитектуры безопасности
  • Разрабатывать политику безопасности просто "для галочки"
  • Поручать внешнему подрядчику написание политики безопасности без понимания им бизнеса и процессов Вашей компании
  • Переводить политику с иностранного языка (например, в международных компаниях) без учета особенностей значения отдельных слов, понятий, терминов в различных языках
  • Создавать условия для того, чтобы сотрудники даже при желании не могли найти политики безопасности
  • Надеяться, что если политика работала в прошлом году, она будет актуальна и в следующем году
  • Надеяться, что обеспечив соответствие требованиям регуляторов, Вы тем самым обеспечите безопасность
  • Полагать, что требования политики не относятся к руководству компании
  • Скрывать политику от аудиторов
Инструменты безопасности
  • Внедрять коробочные продукты безопасности без их тонкой настройки
  • Настраивать IDS на слишком большое количество сообщений (излишне жесткие правила) или на слишком малое (излишне мягкие правила)
  • Покупать продукты безопасности, не учитывая стоимость их внедрения и дальнейшей поддержки
  • Полагаться на одни только антивирусы и межсетевые экраны без других защитных мер и средств
  • Регулярно проводить сканирование уязвимостей, но не анализировать результаты
  • Позволять антивирусным средствам, IDS и другим средствам безопасности работать на "автопилоте"
  • Внедрять множество различных технологий безопасности, не понимая вклада каждой из них
  • Ориентироваться на различные "прибамбасы" продуктов безопасности, забывая при этом про важность их системы отчетности
  • Покупать дорогие и сложные продукты безопасности при том, что более простые и дешевые могут решить проблему на 80%
  • Внедрять новые защитные меры и средства без предварительного анализа их влияния на ИТ-инфраструктуру и бизнес-процессы
Управление рисками
  • Пытаться применить одни и те же строгие требования ко всем ИТ-активам, невзирая на профили их рисков
  • Поручать кому-либо управление рисками, но не давать ему при этом никаких полномочий для принятия решений
  • Игнорировать общую картину, фокусируясь на количественной оценке рисков
  • Полагать, что Вам не следует волноваться за безопасность, поскольку Ваша компания маленькая и незначительная
  • Полагать, что Вы в безопасности потому, что у Вас за последнее время не было проблем с безопасностью
  • Параноидально относиться к защите активов, не взирая на уровень их ценности и угрозы этим активам
  • Классифицировать все информационные активы по высшему уровню конфиденциальности
  • Проводить оценку рисков силами одной только Службы ИБ, не привлекая владельцев данных и ИТ-специалистов
Практика безопасности
  • Не анализировать системные журналы, журналы приложений и безопасности
  • Ожидать, что пользователи откажутся от удобств ради повышения безопасности
  • Жестко ограничивать инфраструктуру, делая выполнение работы значительно более сложным
  • Отвечать "нет" на любые запросы
  • Устанавливать требования безопасности без предоставления необходимых для их выполнения инструментов и проведения обучения
  • Фокусироваться на превентивных механизмах, игнорируя детективные меры и средства
  • Не использовать DMZ для серверов, доступных из сети Интернет
  • Надеяться, что Ваш процесс управления патчами работает, не проверяя это
  • Удалять журналы регистрации событий из-за того, что они очень большие и их сложно читать
  • Ожидать, что использование SSL решит все проблемы безопасности Вашего веб-приложения
  • Запрещать использование USB-флешек, не ограничивая доступ в Интернет
  • Ставить себя выше Ваших коллег - администраторов сети и систем, а также команды разработчиков
  • Не изучать новые технологии и новые виды атак
  • Внедрять новинки ИТ и информационной безопасности до того, как они достигнут приемлемого уровня зрелости
  • Принимать сотрудника на работу в Службу ИБ только потому, что он имеет много различных сертификатов
  • Не уведомлять своего руководителя о проблемах безопасности, которые удалось избежать Вашими усилиями
  • Не проводить взаимное (перекрестное) обучение персонала ИТ и информационной безопасности
  • Привлекать внешних подрядчиков для выполнения работ, цели, объем и/или ожидаемые результаты которых Вам не полностью ясны
  • Игнорировать потребности бизнеса
  • Обеспечивать соблюдение безопасности персоналом только с помощью метода "кнута"
  • Устанавливать запреты, не предоставляя эффективных разрешенных альтернатив
  • Фокусироваться на "конфиденциальности", забывая при этом про "доступность" и "целостность" (в коммерческой компании)
Управление паролями
  • Требовать, чтобы пользователи меняли пароли очень часто
  • Ожидать, что пользователи будут помнить множество своих паролей, не записывая их
  • Устанавливать очень жесткие требования по сложности паролей
  • Использовать одни и те же пароли в различных системах, которые отличаются по уровню рисков или по уровню критичности данных
  • Устанавливать требования к паролям не обеспечивая простого способа их сброса
  • Устанавливать жесткие требования к паролям пользователей, забывая при этом про пароли администраторов и служебных учетных  записей

6 комментариев:

Ригель комментирует...

Странно, что он (она?) вообще остановился - неужели самому наскучило? А то ж таким макаром можно было еще три недели писать, так и не родив не единой мысли:
политика должна быть согласована с заинтересованными сторонами и надлежащим образом утверждена => грех ни с кем не согласовывать, грех согласовывать с незаинтересованными и несторонами, грех не утверждать, грех утверждать подлежащим, грех не образом;
инциденты должно регистрировать, обрабатывать, докладывать, делать выводы => грех не регистрировать, не обрабатывать, не докладывать и делать вводы и т.п.
Ощущение такое, как будто несвежего поел.

eagle комментирует...

Увы, но мне приходилось сталкиваться с политиками безопасности, которые не читал даже "автор", хотя они были подписаны руководством. Ни о каком согласовании их с "заинтересованными сторонами" даже речи не было.
А управление инцидентами часто выливается только в вялую (либо бурную) реакцию на них, выражающуюся в поиске виновника.

Ригель комментирует...

Всем приходилось, но клонирование чтива задрало конкретно. Вы, видимо, еще мало раз это читали.

eagle комментирует...

Про это там тоже есть "Использовать шаблоны политик без предварительной их адаптации под конкретные условия" :)

Или это камень в мой огород по поводу переводных постов? ;)

Ригель комментирует...
Этот комментарий был удален автором.
Ригель комментирует...

Нет, я имею в виду автора (если вообще так можно называть человека, весь креатив которого сводится к замене слов "должно" на "не следует не").