Трансформация роли CISO

Особенно много говорят о трансформации ролей:

• HR – которые должны максимально эффективно осуществить отбор среди большего (чем лет десять назад) количества соискателей, создать и поддержать корпоративную культуру;
• CIO – которые стали ближе к бизнесу (а в некоторых компаниях и есть бизнес) и уже не могут с нуля развернуть почтовик или настроить роутер, зато умеют лавировать среди множества направлений и технологий;
• учителя – чьи лекции уже не всегда очные, а тесты в основном онлайн, чье призвание уже больше направлять, а не повествовать.

И конечно, CISO – здесь ближе, но не понятнее. Как совместить движение в сторону концепции создания безопасных процессов, нацеленность на полноценное участие в бизнес-функциях и при этом желание "поиграть" в разведчика и что-нибудь внедрить (а вдруг пригодится)? Трансформация роли очевидно назрела – как и понимание ИТ-процессов, привычка к подсчету KPI, анализу трендов и проактивности мониторинга угроз. Другое дело – развитие профессионалитета, которое отстает от основных трендов.

Причина проста: безопасность – это подключаемый сервис, который нужен для снижения рисков. И этот самый сервис становится ощутимо необходим, когда бизнес достигает определенного уровня зрелости собственных процессов и начинает работать с исключениями, выискивая новые пути для повышения эффективности. Соответственно, у стартапов или среднего размера компаний интерес к вопросам ИБ появляется только при острой необходимости (инцидент произошел) или в случае ИБ/ИТ-направленности самой компании (в целях формирования положительного имиджа).

Большое количество потоков информации, постоянно возникающих и меняющихся, обязывает CISO разбираться во множестве направлений. Зачем ходить далеко? Технология блокчейн существует не так давно, а к широкому применению вышла уже пару лет как. Гарантированных методов защиты ее от описанных и озвученных злонамеренных воздействий пока нет. При должном уровне абстракции можно применить стандартные подходы: прикинуть модель угроз и нарушителя. Но дальше будет работа с исключениями – динамичная и временами непредсказуемая, т.к. проработанных методик нет. И тут CISO должен взаимодействовать:

Этакий дипломат в квадрате, но с неотъемлемым шлейфом стереотипов, навеваемых профессиональным профилем. В какой-то момент вес появляющихся новых переменных и формирующихся потребностей работодателя обяжет CISO переродиться и оставить привычный набор функций роли позади. А вот какие качества и знания станут определяющими, для меня остается вопросом, его обсудили эксперты:

• Андрей Пряников, заместитель директора по безопасности по защите информации, ООО ТД“ УНКОМТе”
• Андрей Ревяшко, ИT-директор, WILDBERRIES
• Константин Саматов, руководитель направления в Аналитическом центре Уральского центра систембезопасности, член Ассоциациируководителей служб информационной безопасности, преподаватель дисциплин информационной безопасности в УрГЭУ и УРТК им. А.С. Попова

Андрей Пряников

- В ведении по уровням структуры организации. То есть несомненно контроль должен быть и со стороны главы компании (генерального директора/акционера), но при этом на самом минимально необходимом уровне (например, в пятиминутном еженедельном отчете или в виде одностраничного DashBoard). На более глубоком уровне - соответственно, ниже по иерархии структуры компании. Лучшим вариантом является подчинение CISO напрямую генеральному. Если же CISO по какой-то причине не может подчиняться такому уровню и стоит выбор между топ-менеджментом, то все сильно зависит от человеческого фактора. И ИТ-директор, и финансовый директор, и директор по безопасности могут быть хорошими руководителями, если они адекватно понимают возможные риски и более-менее следят за последними трендами в ИБ.

Константин Саматов 

- В идеале - самостоятельное подразделение в прямом подчинении первому лицу организации либо собственнику, как вариант - структурное подразделение в службе безопасности. Именно в службе безопасности, не в ИТ-подразделении, как это часто бывает на практике, т.к. основная функция ИБ - это не настройка технических средств, которую могут делать ИТшники, если им правильно инструкции написать, а как раз контроль и управление угрозами и рисками.

Лев Палей

На мой взгляд, тут нет "постоянного" ответа, потому что стратегия компании, ее история ведут к определенным коррективам, обусловленным требованиям к эффективности основных деловых процессов. Вопрос ведения становится второстепенным, а на первый план выходят возможности по включению в базовые деловые процессы.

Андрей Пряников

- В ЛНА нет смысла, если нет реального ИБ. Но без ЛНА невозможно скоординировать работу функции.

Так что все зависит от уровня развитости процессов в компании и от ее размера. Опять же, ведение вопросов корректной "нормативки" должно быть на руководящем уровне, а реальная ИБ - на уровне инженеров, которые выполняют эти ЛНА. Наверное, можно аккуратно сказать про 20% на 80% (популярное соотношение), где 20% - это грамотная проработка ЛНА и контроль ее выполнения, а 80% - это ее исполнение на всех уровнях. То есть инженеров должно быть больше, чем менеджеров.

Константин Саматов

- В каждой конкретной организации будет разный ответ на данный вопрос. По своему опыту руководства отделом ИБ могу сказать, что у меня соответствовали примерно на 80%. Большая часть норм, содержащихся в локальных нормативных актах, описывала реально принятые меры, и примерно 20% было написано для галочки.

Андрей Пряников

- Должен. При найме в штат технических специалистов это позволит оценить их реальный уровень и после этого более-менее спокойно доверить работу. При оценке рисков для ИТ-процессов - поможет понять, реально ли надо закрывать их и как это правильнее сделать. При написании ЛНА/регламентов это поможет сделать документы ближе к реальному положению дел в компании. И в конечном итоге (что самое важное) - технические знания помогут контролировать выполнение ЛНА и работу ИТ/ИБ-подразделения.

Андрей Ревяшко

- У хорошего CISO он однозначно должен быть, а без такового специалиста не назовешь специалистом. Речь не идет о том, что человек должен знать все от и до. Это нереально, хотя и исключения есть. Если говорить о багаже технических знаний, то должно быть понимание, что и где искать.

Константин Саматов

- По моему опыту, для CISO достаточно знаний терминологии и обзорного знакомства с основными технологиями. Технический бэкграунд вполне может быть компенсирован его подчиненными. К примеру, CISO должен понимать, что межсетевой экран - это устройство фильтрации трафика, а вот как его настраивать, CISO знать не обязательно. Для CISO скорее важен юридический или управленческий бэкграунд, так как основные вопросы, которые он решает, - организационно-правовые.

Лев Палей

Дьявол в деталях. Иногда качественный контроль, при наличии определенного опыта, позволяет выявить критичные недостатки процесса, а знание терминологии "изнутри" - значительно увеличить динамику применения изменений. И если задачи касаются сугубо вопросов соответствия, то основной фокус компетенций должен быть сосредоточен в области законодательства, а если в KPI получение максимального эффекта от процесса - тогда необходимо понимать в том числе и технические составляющие.

Андрей Пряников

- Информационная безопасность - это про "войну в цифровом мире". Если война ведется нечестно и с жестокостью, то к Аресу - это скорее про "хакеров-злоумышленников". Если вспомнить, кто же противопоставлен ему, то это Афина - богиня организованной войны, военной стратегии и мудрости. Именно этим мы и занимаемся, организуем, планируем, готовимся.

Андрей Ревяшко

- В древнегреческой мифологии есть Арес - бог несправедливой войны. ИБ вполне можно рассматривать как полноценную и несправедливую войну. Безусловно, есть и обратные моменты: к примеру, если ты как специалист по И Б допустил внедрение чего-то опасного для жизнедеятельности компании, то справедливо будет возложить ответственность за это на тебя.

Но речь больше про то, что бизнесу в основном угрожают исподтишка - не в честном бою, без объявления войны. Хотя нередки случаи, когда, к примеру, перед DDoS-атакой присылают "письма счастья" с предложением "откупиться" от атаки.

Константин Саматов

- Арес - бог войны. Должность CISO (впрочем, как и руководителя СБ) всегда подразумевает некое состояние войны (противодействия), причем как с внешним, так и внутренним нарушителем, защиту интересов организации от внутренних и внешних угроз. Поэтому хороший CISO - это всегда "свой среди чужих, чужой среди своих".

Андрей Пряников

- Слово эксперт означает "наличие экспертизы", т.е. определенных знаний, скорее полученных через практику. То есть говоря об эксперте в области ИБ, мы точно знаем, что вес его знаний очень значителен, при этом он не стремится ими со всеми делиться. Если же говорить про ИБ-евангелиста, то он может и не являться экспертом, а может даже и не обладать какими-то глубокими знаниями, но при этом способен очень грамотно донести мысль до других и хочет это делать. Такие люди могут хорошо работать, например, в продажах. Если же эксперт одновременно является и ИБ-евангелистом, то, скорее всего, у него есть твиттер, канал в Телеграме и личный блог, а работать при этом он может, например, в Cisco.

Константин Саматов

- Эксперт ИБ - это специалист, способный дать квалифицированное заключение по тому или иному вопросу, обладающий, по моему мнению, следующими характеристиками: наличие профильного образования (возможно, в виде профессиональной переподготовки); опыт работы в данной сфере не менее пяти лет; членство в отраслевых общественных организациях. ИБ-евангелист - это человек, занимающийся популяризацией информационной безопасности (например, ведущий блог в сети Интернет). В ряде случаев обе роли могут совпадать, однако для ИБ-евангелиста не обязательно обладать квалифицированными знаниями в области ИБ, достаточно лишь снабжать аудиторию тематическими материалами (например, вести тематический блог, где репостить публикации других людей).

Андрей Пряников

- Это часть профессии, и в ее рамках приходится изучать некоторые аспекты психологии. Даже если взять такой крупный блок ИБ, как повышение осведомленности персонала, - его невозможно развивать, не обладая пониманием того, как работает психология. Не зная принципов социальной инженерии, можно упустить, пожалуй, самый серьезный блок ИБ, с направленными атаками. Кстати, если вдруг читающие эти строки никогда не знакомились с книгой "Искусство обмана" Кевина Митника, настоятельно рекомендую это сделать и использовать знания в благих целях.

Андрей Ревяшко

- Уверен, что психология есть часть профессии. Ведь это и хорошее подспорье в расследовании инцидентов, и решение ИБ-вопросов на перепутье интересов, к примеру, нескольких департаментов. С одной стороны, можно пустить разбор сложных инцидентов на самотек, ввиду несогласованности междепартаментных действий, а можно грамотно, с психологией к тому или иному решению спорных моментов, сэкономив время, которое, как правило, играет против ИБ (к примеру, ограниченное время хранения логов).

Не стоит забывать и о том, что специалист по ИБ, способный грамотно применять на практике методы психологии, с большим успехом (по отношению к специалисту без таковых навыков) донесет информацию о возможных угрозах, к примеру, сотрудникам компании, чем снизит риски последней.

Константин Саматов

- Скорее, данность, необходимый элемент. Лично я бы не рассматривал ИБ как часть ИТ. ИБ, на мой взгляд, - это составная часть управления безопасностью компании, а не управления информационными технологиями. Первоочередные задачи ИБшника - это не настройка средств защиты (по-хорошему, он может вообще этим не заниматься), а управление процессом минимизации (нейтрализации) источников угроз безопасности информации, одним из которых является человек.

Андрей Пряников

- Если посмотреть все стандарты по очереди, то можно заметить пересечения, но где-то есть конкретика, а где-то требования описаны общими словами, где-то речь про процесс, а где-то про технику. В своей практике я обращаюсь к таким стандартам, как ISO 27001 (упор на "какие процессы нужны") и требования из ФЗ (тот же 21-й приказ про ПДн и 31-й приказ про КИ - тут больше про "а какие виды средств нужны"). И хоть я никогда не работал в банках/кредитных организациях, я иногда обращаюсь к стандарту PCI DSS, так как стандарт защиты для платежных систем в некотором смысле является эталоном И Б. Базой для инфраструктуры многих организаций сейчас является ПО компании Microsoft - очень часто в качестве стандартов обращаюсь к их Security-стандартам.

Андрей Ревяшко

- Для нас, в первую очередь как для e-commerce-проекта, ИБ - это прежде всего OWASP, PCIDSS, SDL и постоянное повышение уровня осведомленности как сотрудников, принимающих участие в жизнедеятельности компании, так и наших клиентов.

Константин Саматов

- В первую очередь я ориентируюсь на нормативно-правовые акты (законы, постановления, приказы регуляторов) и методические документы (методики, базовые модели угроз и т.п.) регуляторов, исходя из них и формирую стратегию и политику ИБ. Еще использую стандарты ГОСТ Р ИСО/МЭК серии 27001. Правда, при их применении нужно учитывать взаимосвязь с принятыми нормативно-правовыми актами, чтобы не было расхождений.

Лев Палей

Не существует стандартов, которые можно взять на вооружение в состоянии "как есть", но вот под каждый подпроцесс можно найти ориентиры для последующей детализации и подстройки. Здесь и NIST SP 800-53, и CIS: Метрики безопасности и 27001 (ГОСТ и ISO) - ограничений в том, что использовать для совершенствования, не существует.

Андрей Пряников

- ИБ просто обязана ориентироваться на бизнес. И если бизнес меняет требования по принципу Agile, то и ИБ приходится это делать. При этом для развития функции такой вариант, конечно, хуже, так как с изменением переменных меняются и вероятные риски и надо динамически успевать выбирать наиболее оптимальное изменение. Для ИБ гораздо лучше планомерное стратегическое развитие и наименьшее количество резких изменений как в бизнесе, так и в ИТ-инфраструктуре и процессах. Так что ответ на вопрос: Agile в ИБ жить может, но лучше для нее побольше стабильности. Хотя если такой Agile прилетает извне в виде очередного шифровальщика – тут ИБ надо перестраиваться максимально быстро.

Андрей Ревяшко

– Так уж сложилось, что современный мир бизнеса все больше и больше наполняется духом Agile. Так что хотим мы этого или нет, но у ИБ одна дорожка – трансформироваться под новые требования. Agile в ИБ будет все больше и больше набирать обороты. Исходя из этого гибкий подход в ИБ живее всех живых.

Предоставляя постулатам о гибкости проектов место для маневров, ИБ проникает в жизненные циклы последних, дабы не становиться бутылочным горлышком бизнес-задач. Сегодня это видится чуть ли не единственной возможностью достойно реагировать на угрозы ИБ.

Константин Саматов

– Agile – это методология проектного управления, наряду с PM BOK и PRINCE 2, хорошо зарекомендовавшая себя при разработке программного обеспечения. При этом слабым местом данной методологии с точки зрения ИБ можно считать "пренебрежение" к документированию процессов, что может затруднять процесс сертификации разработанных средств защиты (в случае с разработчиком программного обеспечения) либо обоснование неактуальности угроз, связанных с наличием НДВ (при использовании собственных разработок организации). Если говорить о проектах, не связанных с разработкой программного обеспечения (создание СЗПДн, КСЗИ, внедрение DLP и т.п.), то для их реализации чаще используется классическое проектное управление (PM BOK).