вторник, 28 октября 2014 г.

Уязвимости высокого уровня зрелости ИТ

   Допустим нам очень повезло, и мы работаем в крупной западной компании с развитой унифицированной ИТ-инфраструктурой, приложениями и процессами. Вроде бы похоже на "счастье" - порядок наведен, можно в нормальном ритме анализировать цели организации и возможные риски, определять цели контроля и способы их достижения.
    Но не тут то было!:) Уже через месяц мы поймем все недостатки подобного положения дел, например:


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

Комментариев нет:

Отправить комментарий