Допустим нам очень повезло, и мы работаем в крупной западной компании с развитой унифицированной ИТ-инфраструктурой, приложениями и процессами. Вроде бы похоже на "счастье" - порядок наведен, можно в нормальном ритме анализировать цели организации и возможные риски, определять цели контроля и способы их достижения.
Но не тут то было!:) Уже через месяц мы поймем все недостатки подобного положения дел, например:
Но не тут то было!:) Уже через месяц мы поймем все недостатки подобного положения дел, например:
- реализовать какие-либо доработки ИТ-приложений в целях безопасности практически невозможно - "нет ресурсов разработчиков", "изменения в архитектуре не согласует вендор", "это порождает риск перебоев в работе системы", "сервера не выдержат возросшей из-за развития логирования нагрузки" и т.п.
- patch window у нас 3-6 месяцев (в зависимости от системы), договориться по-человечески крайне сложно (договариваться надо с локальной командой поддержки, потом с глобальной командой поддержки, потом иногда с владельцами использующих инфраструктуру приложений)
- в силу унифицированности инфраструктуры она имеет обыкновение оказываться тотальной уязвимой, т.е. патчить нужно сразу все (со всем вытекающими со стороны ИТ)
- любая наша инициатива по новой мере защиты крайне медленно продирается через многочисленные Архитектурные, Операционные, Инвестиционные и другие комитеты
- сильный бренд приводит к стремлению массы кандидатов-проходимцев устроиться к нам (в моей практике кандидат пытался пройти в БЦ на собеседование с ножом)
- большая часть всех вопросов безопасности уже урегулирована в штаб-квартире, нам остается только исполнять
- стандарты ИБ конфликтуют с локальным законодательством, например все бекапы мы должны хранить головном ЦОДе
Парадокс - даже в такой на первой вгляд идеальной ситуации есть свои "подводные камни". И для многих коллег будет комфортнее организовывать ИБ в компаниях с менее высокой зрелостью ИТ.
Комментариев нет:
Отправить комментарий