Обратная сторона луны, или Как я посмотрел на вчерашнего себя
Однажды теплым августовским утром, когда солнце и пение птиц не предвещали ничего особенного, в жизни и работе произошел резкий поворот. Даже больше чем поворот: переход на другие рельсы — из информационной безопасности, которой я отдал около семи лет жизни, в информационные технологии. Об этом и хотелось бы рассказать: как я неожиданно увидел совсем другую «сторону баррикад», другую сторону информационной инфраструктуры — не ее защиту, а ее развитие и обслуживание. Увидел «жизнь на обратной стороне Луны». Именно об этой повседневной и бытовой жизни двух подразделений, увиденной с разных точек зрения, с их стычками, недопониманием и, самое важное, способами разрешения конфликтов, и пойдет речь.
О том, как поменялось мировоззрение и приоритеты
Изменения произошли быстро и весьма ощутимо — в тот момент, когда я в качестве нового руководителя вошел в кабинет к тем ребятам, которым по сложившимся традициям «мешал спокойно работать» годами в различных банках. Так уж повелось, что информационная безопасность обычно становится тормозящим фактором в ИТ, заставляя данный департамент многократно возвращаться на старт и вновь проверять и перепроверять безопасность, отказоустойчивость и качество сервисов, а также «выворачивать руки» сотрудникам, отказывая в использовании малоизученных и недостаточно испытанных решений.
С большим скептицизмом и недоверием множество глаз смотрели на меня, четко выражая мысль: «А вот теперь попробуй исполнить все свои требования и нормативку, при этом выполнив задачи бизнеса!» Выбора не было, поэтому пришлось исполнять. Но не только исполнять, а подходить к задачам с другой стороны: главное — как можно быстрее и дешевле запустить сервис и дать возможность бизнесу зарабатывать, а все остальное — это большей частью зона ответственности теперь чужого для меня подразделения.
Новые отношения с ИБ
«Поехали!» — именно так и началась новая работа и новые задачи. Шаг в неизвестность был действительно ощутимым: абсолютно новые задачи и проекты, да еще и с периодическими ограничениями, которые вчера сам же и поставил. И вот тогда эти самые ограничения открылись мне совершенно с иной стороны — их практической реализации. Первое, что обратило на себя внимание, — основной документ, можно сказать водораздел между ИБ и ИТ, — политика ИБ. В нем достаточно ясно и полно прописаны и зоны ответственности, и взаимодействие между подразделениями, и общие планы и стратегии, но не было одного! Причем я понял, что этого одного не хватало никогда ни в одной из написанных или прочитанных мной политик: форс-мажор! Что делать, если какой-то момент не предусмотрели, как быть, если назрел неразрешимый конфликт, а тем более если возник он на почве произошедшего инцидента?
Классическим вариантом является подчинение служб безопасности первому лицу организации, а ИТ — одному из заместителей (в банковской сфере, в силу требований регулятора, разделение кураторства обязательно). В описанной выше ситуации все заканчивалось тем, что каждое из подразделений предоставляло пояснения своему куратору и окончательное решение («кто виноват и что делать») принималось на уровне кураторов. Думаю, излишне отвечать на риторический вопрос, на чьей стороне правда и у кого сильнее позиции в таком положении. Отличным решением в подобных случаях становится третейский судья в виде стороннего для ИТ и ИБ представителя руководства. Как бонус — приходит понимание истинного умения и необходимости развития навыка общения на языке бизнеса и денег, когда нужно объяснить что-то человеку, не знающему других языков.
А справедливо ли разделили?
Это второй вопрос, с которым я столкнулся. Почему-то априори в течение многих лет в голове существовала странная идеология: «Конфиденциальность — наше все!» Но две другие отправные точки ИБ — целостность и доступность — обычно оставались за кадром. (В качестве отступления: недавно начал понимать, почему не нужно чрезмерно увлекаться отечественными нормативными документами и принимать их близко к сердцу, дальше устранения правовых рисков.)
Исторически же работу с отказоустойчивостью серверов, сети и сервисов, контроль и обеспечение целостности среды, а также ответственность за периодически падающую инфраструктуру повелось сваливать на ИТ. При этом подразделению ИТ, при всей кажущейся легкости задач, оказалось весьма непросто с ними справиться. И причина далеко не техническая: без отдельного штата сотрудников, что для многих является непозволительной роскошью, взгляд и мысли при постоянном беге за потребностями бизнеса со сверхзвуковой скоростью просто «замыливаются». Некогда, не хочется, а зачастую и не удается в огромном ворохе задач и проектов разглядеть эти подводные камни — риски доступности и целостности. Да и что там скрывать, по сути своей не айтишная это задача при живом и здоровом подразделении ИБ.
«Приходится бежать со всех ног, чтобы только остаться на том же месте»
Эта фраза из книги Льюиса Кэрролла как нельзя лучше описывает нынешнюю работу подразделений ИБ. Обычный баланс сил: не больше одного сотрудника ИБ на 10–15 сотрудников ИТ. И эти молодые и горячие парни (к слову, одни из опаснейших моделируемых нарушителей) постоянно бегут со всех ног и что-то пишут, переписывают, настраивают и внедряют. Как за ними угнаться? Как отследить вносимые ими изменения? Надежность и безопасность изменений? Как отследить, какие «грабли» закладываются ими в созданный код, в access-листы сетевого оборудования, в настройки множественных систем? Отвечу честно: никак!
Из большого числа программных решений для анализа кода, сканеров уязвимостей, ручного вычитывания конфигов и прочей управляющей информации ни одно в действительности не принесло ощутимого результата. При этом подобная работа ИБ весьма раздражает ИТ постоянным вмешательством в их деятельность и подозрительным взглядом на каждое нажатие клавиши, а в итоге приносит лишь необоснованные конфликты и замедление работы обоих подразделений.
Что же помогло найти выход? Неким подобием «серебряной пули» стал контроль версионности и частоты вносимых изменений. Ежедневное выявление ТОП-20 (30...100) критичных узлов ИТ-инфраструктуры с самым большим по рейтингу количеством изменений вкупе с тестированием их адекватной и отказоустойчивой работы подразделениями-потребителями (естественно, по предварительной договоренности в бумажном виде!) дало значительно больший эффект. Как оказалось, смотреть в корень — не всегда лучшее средство. Ну а все те же сканеры и анализаторы со счетов сбрасывать не стоит — дополненное ими тестирование может дать практически стопроцентный результат.
Делим бюджеты и осваиваем их
Мой переход на работу в другом направлении практически совпал с окончанием года и планированием бюджетов. И в тот момент для меня вскрылся еще один большой пласт — раздел средств, выделяемых организацией на ИТ-инфраструктуру. Что бы ни писалось и ни говорилось о самостоятельных и отдельных бюджетах подразделений ИБ и ИТ, первоначальная сумма, определяемая к расходу на инфраструктуру независимо от целей — развития или защиты, — одна. А дальше происходит доказывание приоритетности задач и расходов и дальнейшее деление. И именно на этой стадии вдруг был замечен (иначе и не скажешь!) парадокс. Весьма немалое количество статей бюджетов или дублируют, или дополняют друг друга, но нежелание или невозможность двух подразделений перекрестно рассматривать потребности и битва за «свой кусок» приводит к тому, что средств либо не получает никто, либо большая и комплексная задача остается профинансированной лишь на часть ее этапов. Причем в случае совместного рассмотрения и консенсуса те же банальные обновления парка сетевого оборудования со стороны ИТ и внедрение/замена межсетевых экранов и IDS/IPS со стороны ИБ могли бы вылиться в качественный проект защищенной ЛВС, а не во множество гирлянд из огромного количества недорогих устройств не самого высокого класса.
Логическое продолжение бюджетирования — освоение полученных средств. Деньги предоставлены, проекты посчитаны. А как обстоят дела с практической частью? Один из краеугольных камней — установка своих «черных ящиков» на чужой территории. Сколько сотрудников ИТ могут вспомнить попытки безопасности установить свои не совсем понятные и прозрачные в функционировании устройства и программные продукты под единственным предлогом: «Так требует закон, так будет безопаснее!» И сколько безопасников сталкивалось если не с прямым противодействием, то как минимум с желанием максимально растянуть процесс и минимизировать интеграцию «сертифицированных» (на языке ИТ — нестандартных и малоуправляемых) средств защиты.
Для того чтобы выйти из создавшегося тупика, думаю, нужно следующее. Во-первых, повышение прозрачности процессов: если ИБ/ИТ хочет что-то внедрить, то первое, с чего начинаются переговоры, — пояснение принципов действия, технических характеристик и рисков остановки ИТ/ИБ-инфраструктуры из-за неверной работы внедряемого продукта. Необходим обязательный и постоянный доступ к настройкам данных продуктов в режиме чтения. Без запросов и объяснений каждый в любой момент может посмотреть, что происходит на соседней территории. Во-вторых, разделение повышенных привилегий как в ИТ инфраструктуре, так и в ИБ. Здесь отлично помог «дедовский» способ разделения паролей привилегированных пользователей на части: хочешь что-то серьезно поменять — пригласи вторую сторону, согласуй и сделай вместе. Принцип «играть втемную» полностью исключен и пересмотру не подлежит.
Результаты при этом превзошли ожидания, естественно, в положительном ключе.
Заключение, или О том, почему нельзя жить без бумаг
Документировать, документировать и еще раз документировать. Одним из важных наблюдений в представлявшемся мне ранее трудноразрешимом вопросе — документировании процессов подразделением ИТ — оказался просто различный подход к данной работе и пропасть недопонимания. Так уж сложилось, что ИБ больше тяготеет к теоретической и юридической составляющей, а ИТ — это чистой воды практики и нигилисты. ИБ интересует в первую очередь сухой документальный язык и соответствие нормативки законам, и уже внутри данного соответствия — практическая составляющая. ИТ же преследует иную задачу: в случае очередного локального «армагеддона» как можно скорее и точнее найти отправные точки и готовый рецепт «что делать».
Решение видно на поверхности — практицизм ИТ, облаченный в эпистолярное умение, приносит ИБ хорошие результаты. Речь, конечно же, идет не о фиксации сложившейся ситуации, а о ее совместном пересмотре и приведении к правильному знаменателю. К сожалению, документ, созданный кем-то единолично и без полноценного учета практической составляющей работы другого подразделения, как и любая другая бумага, спущенная сверху, не будет эффективной и вызовет лишь отторжение.
В заключение нужно сделать самый важный вывод: слаженное и взаимовыгодное сотрудничество ИБ и ИТ может быть построено на трех китах — доверяй, соучаствуй, но сохраняй дистанцию. Соблюдение четкого баланса этих составляющих просто не может не дать богатых всходов на поле информационных технологий!
Опубликовано 26.03.2015