Защищать данные — это как лечить хронь вроде диабета. С одной стороны, пациент менеджмент понимает, что пренебрегать правилами нельзя, а с другой — думает, что глазки отвалятся потом и вообще не факт, а тортик вкусный прямо сейчас. Искушение сэкономить на ИБ неодолимо.
Сама идея безопасности, отличной от настройки файервола, всё ещё нова для некоторых компаний. Средний возраст уязвимости, через которую влезают злодеи, составляет семь лет. СЕМЬ. То есть это не новое и модное, за которым не успели, это старое и известное, на которое забили.
Заставить высший менеджмент шевелиться тут могут только хорошо организованные шантаж и угрозы. И вот как я это делаю.
Я не тот человек, который настраивает сканеры и файерволы руками, а тот, кто руководит этой деятельностью. Не главный знаток правильной настройки, а строитель корпоративной системы информационной безопасности, которая обеспечивает файерволы и сканеры смыслом. Потому как одним файерволом сыт не будешь, что бы там ни показывали в кино про хакеров.
Кстати, о кино. Самый известный мой коллега — вот этот господин из фильма «Хакеры» 1995 года:
Помните, как он скандалил, узнав, что кто-то использует пароль «Бог»? Вот-вот. Друзьям я обычно объясняю, что выполняю роль завхоза — хожу по офису, заглядываю в тёмные углы и гугню, что там недовытерто и тут недокручено, на чае сэкономили, а туалетную бумагу опять не закупили.
Люди вроде меня называются в мире по-разному. Chief Security какой-нибудь. Или Head of. Director — тоже хорошее слово. Я работаю в Европе, и у нас есть документ European Cybersecurity Skills Framework Role Profiles, написанный Европейским агентством по кибербезопасности. Согласно этому документу, главный начальник умывальников тут называется Chief Information Security Officer (CISO) и отвечает он в основном за корпоративную стратегию информационной безопасности и последующее приложение её к жизни. Ну вот это я и есть. Но поскольку компания у нас не слишком большая, мы сократили длинное красивое название до простого Security Officer’а.
Так или иначе, я отвечаю за информационную безопасность в компании, которая пишет софт для банков и страхования. Наши клиенты озабочены безопасностью, как никто, так что приходится соответствовать. А до того как моя нынешняя компания заманила меня к себе, я пять лет проработала в банке, занимаясь там сперва сервис-менеджментом вообще, а потом менеджментом уязвимостей.
Как ИБ может появиться в вашей жизни
Например, вы делаете что-нибудь техническое — в моем случае это был большой и красивый банковский сервис на мэйнфрейме. Быстро выясняется, что ваш красивый сервис ещё зачем-то окружён остальным банком. А в нём полным-полно правил, регуляций, аудитов и людей, которые приходят к тебе с какими-то красными цифрами в руках и требуют, чтобы ты соответствовал, отвечал и вообще прилично себя вёл. Приходится разбираться в процессах, стоящих за красными цифрами. И тут-то оказывается, что безбрежное банковское айти, все эти платформы, сервисы и приложения упорядочиваются и регулируются в соответствии с какими-то там стандартами и даже фреймворками.
Так вы попадаете в историю под названием IT governance — управление процессами. Люди, работающие в этой области, занимаются тем, что пытаются заставить целые стада лебедей, раков и щук везти телегу вместе без ущерба для здравого смысла и какой-никакой стратегии. Например, централизованно управляют всеми IT-изменениями в компании, чтобы Иванов не зашиб ненароком Петрова, пытаясь сконфигурировать под себя какое-нибудь общее имущество, а Сидоров не вкатил свой опупительный патч в последние минуты старого года. Или вот информационной безопасностью, да: легко сказать, но чуть сложнее ответить на вопрос «Как жить, если стандарт PCI DSS требует чинить критические уязвимости за 30 дней максимум, а у патч-менеджмента полный цикл составляет 39 дней, и хоть ты тресни?».
В управлении ИБ одной технической стороной не обойдёшься — нужен процесс. Процесс — наша великая священная корова, и живётся без неё грустно. Технические специалисты разного рода норовят иметь очень техническое представление и о безопасности тоже: если, мол, купить какую-нибудь чудовищно дорогую штуку, чтобы бегала и сама рассказывала тебе всё о дырках в твоей драгоценной инфраструктуре, станешь ты безопасней некуда — а разные там бумагомараки в верхах только мешают. Ха!
Сами посудите: вот купили вы, например, лучший на свете сканер уязвимостей. Поставили. Настроили. Вот он стоит — дорогой, красивый и в меру упитанный, и производит вам немалые данные: IP-адрес такой-то — 125 уязвимостей, и все критические. Хорошо бы теперь всё это как-то починить, а в идеале ещё и предотвратить на будущее. И тут начинаются приключения.
Сперва мы ищем владельца нашего дырявого имущества. Для этого в компании должен существовать процесс под названием Asset Management, где прописано требование регистрировать в специальной базе все серверы и что там у нас ещё есть до распоследнего хаба. Там же каждый предмет оценивается по степени важности для компании. И там же им присваивается владелец, который теперь отвечает за него головой и зарплатой.
Нашли, а он такой: «Что это? Откуда это? Я все отрицаю, уйдите от меня, злые люди, я занят навеки». И тут нам нужен второй процесс: Vulnerability Management. В котором было бы написано что-нибудь вроде «Если уязвимость критическая на критическом же участке инфраструктуры, извольте чинить за 30 дней и никак иначе». А Asset Management в предыдущем абзаце любезно категоризировал нам нашего героя как критический участок. Так что по истечении месяца вредный владелец уязвимости получит втык от начальства, которому мы заботливо пришлём на него красные цифры: 125 критических уязвимостей, и все старше 30 дней.
Но чу! Он тычет пальцем в соседнюю команду и утверждает, что он бы и рад, но соседи, гады, не приготовили ему патч: не протестировали на корпоративной конфигурации и не выложили на раздачу внутри компании. Тут мы вынимаем из папочки следующий процесс, Patch Management, который вроде как требует, чтобы патчи безопасности выдавались сервисам в течение, например, 15 дней после выхода. А соседский менеджер, понурившись, говорит, что начальство велело ему плюнуть на эти глупости.
Тогда мы делаем ход конём и регистрируем на это безобразие риск. Риски — страшная штука, когда работают правильно: именно риск в любой момент может оказаться на столе у самого большого начальства. Итак, мы пишем: существует риск, что у нас сопрут последние портки из-за не починенных вовремя уязвимостей на критическом для компании сервере, причиной которых является несоблюдение сроков по процессу Patch Management’а. И не говорите, что мы вас не предупреждали.
Теперь нам нужно найти риску хорошего хозяина — человека, который мог бы повлиять на происходящее. Менеджер команды, отвечающей за патчи, явно не подходит — приоритеты для него, как видно, расставляет его начальство. Приходится идти вверх по цепочке начальников, пока не найдётся тот самый, который велел нас игнорировать. Ему мы торжественно вручаем риск и оставляем бедняжку подумать о его поведении.
После некоторого количества шантажа и угроз риску назначается дедлайн и составляется список действий, которые могли бы спасти нас временно или постоянно. Что-то из этих действий может оказаться на стороне информационной безопасности: например, мы можем договориться о временных мерах защиты, которые будут стоить нам денег или задержки производительности, — но куда деваться. А какие-то другие действия могут оказаться настолько монументальными, что сойдут за стратегическую цель на следующий год: пересмотреть политику найма в компании, чтобы ресурсы IT соответствовали потребностям и метрикам ИБ. Ну можно же помечтать...
Так мы начали с уязвимостей одного несчастного сервера, а закончили стратегическим уровнем — а все благодаря процессам и метрикам. Поскольку каждый промежуточный шаг в этой цепочке мы можем подтвердить данными и рисками, давайте торжественно поставим галочки в двух любимых пунктах корпоративного управления: risk-based approach и data-driven decision making. Ну не молодцы ли мы!
Кто чем занимается в ИБ
Ты сидишь в тёмном помещении и напряжённо таращишься в экран, по которому бегут невнятные строки в консоли. Вокруг тебя немытые кружки, непонятные железки, на голове у тебя чёрт-те что, а с социальными навыками полная катастрофа. Так себе представляют инфобез даже некоторые айтишники. На самом же деле корпоративная информационная безопасность — в первую очередь выстраиваемые годами процессы, а не количество немытых кружек и креатива на голове. Но поскольку это всё равно самый популярный образ профессии в народе, с него и начнём.
Если ты нырнул в экран с логами, а вокруг играет драматическая музыка, твой процесс — Security Incident Response (SIRT). Это первая линия обороны, люди, которые дежурят посменно и хорошо знают как техническую сторону кибербезопасности в целом, так и что на этот счёт есть в компании. Они же много читают о всевозможных атаках, случившихся в мире, и прикидывают, что будет, если такое вот случится с нами. SIRT/SOC получает информацию о возможном инциденте из двух основных источников: от других людей, следящих за сервисами компании, и от собственных уведомлений на инфраструктуре.
Итак, коллега из общей техподдержки сообщил, что корпоративный сайт безобразно тормозит, программисты клянутся, что ни при чём, а клиенты негодуют. Самое время проверить, не ДДОС ли это ненароком или ещё какая неприятность по нашей части.
Лучшее подспорье для SIRTа (да и любой другой безопасности в компании) — процесс Asset Management, с которым мы уже встречались. Если у тебя что-то не то с корпоративным сайтом, тебе хорошо бы иметь возможность быстро понять, из каких компонентов этот сайт состоит, какие команды за них отвечают и чем всё это богатство защищено.
В друзьях и соседях у нас процессы Log management и Event management. Первый — сливает все важные логи в компании в единую тулзу, называемую SIEM (Security Information and Event Management), второй — настраивает уведомления по определённым триггерам из логов или мониторингов.
Итак, мы проверили, из чего сделан наш пострадавший сайт, и заглянули в логи. И нашли, к примеру, несоответствие: всё портит какой-то компонент, про который мы ничего не знаем из Asset Management’а. Дело пахнет керосином: кто-то выкатил что-то, а зарегистрировать в каталоге забыл, и теперь мы не знаем, кто это и что это.
Чтобы найти негодяя и быстро понять, что к чему, можно привлечь Identity and Access Management. Этот процесс, понятно, идентифицирует пользователей в компании и распределяет доступ ко всему тому добру, о котором знает Asset Management. Эти-то милые люди скоренько расскажут нам, кто куда зачем в последний раз ходил.
Одной рукой ищем негодяя, обошедшего наши красивые процессы и выкатившего в прод неучтённый компонент, а второй — пытаемся понять, что с этим компонентом не так. А что это у нас за сканирование такое интересное огорчает наш компонент с внешнего айпи-адреса…
Поверх Asset Management’a работает также уже известный нам процесс Vulnerability Management. Он разнообразными способами ищет в компании уязвимости — автоматически при помощи сканеров или вручную при помощи пентестеров. Он же отвечает за программу Responsible Disclosure, которая задаёт правила взаимодействия со сторонними людьми, нашедшими в тебе уязвимость, — в расчёте на деньги или просто так.
Эти-то дорогие коллеги и отвечают за те сканы и взломы, которые не припишешь злым врагам. Поэтому проверим-ка мы, не они ли это. Ага, они. И даже change у них был, оказывается, зарегистрирован, и уведомления разосланы, просто ты, товарищ Холмс, почту читал невнимательно. Осталось сдать пентестерам наш несчастный компонент и подозреваемого владельца. Пусть сами разбираются, кто там кого огорчал.
С точки зрения бизнеса самый заметный и уважаемый процесс — Business Continuity, который описывает, как бизнесу выжить, если все пошло вразнос. Наиболее понятная простому инженеру часть его — бэкапы и Disaster Recovery, великое планирование и тестирование инфраструктуры на отказоустойчивость. Но помимо этого процесс включает ещё великое множество мер на стороне собственно бизнеса, о которых айти, как правило, не в курсе. В нашей детективной истории какие-то меры из Business Continuity Plan уже немножко принимаются, чтобы скомпенсировать плохую работу сайта. Например, команда IT-поддержки получила официальное сообщение для раздачи клиентам, а начальник пострадавшего бизнеса собрал свой отдел и в панике решает, что делать с тормозящими платежами и как их потом обрабатывать.
В любом из этих процессов ты можешь представлять одну из двух больших сторон: техническую, будучи программистом или администратором какой-то системы, либо управленческую — в нашем мире такие граждане называются Process Owner или Process Manager. Они следят за тем, чтобы процесс был документирован, документация кое-как соотносилась с внешними и внутренними регуляциями, аудитами, соседскими процессами, а ещё и ежедневной реальностью компании, ну и чтобы сотрудники всех видов были обучены всем необходимым правилам.
Над всей этой красотой парит главный технический специалист по безопасности — Security Architect. Иногда их больше одного, и тогда кто-то из них главный. Он знает инфраструктуру компании лучше всех и следит за тем, чтобы все возможные дыры были перекрыты тем или другим образом, всё со всем стыковалось и вообще складывалось в приличный пейзаж, а не полное Пикассо. Security Architect — последняя инстанция в спорах а-ля «если кит на слона налезет». Он же утверждает большие технические бюджеты на новые игрушки: вот здесь оно закроет нам такую дырку, а вот там — аж два риска сразу и ещё аудиторское замечание на сдачу, так что несите кошелёк.
А на спине этого орла сижу я и присматриваю, в свою очередь, за пейзажем процессным, а также отвечаю головой за свои красные цифры, производимые по метрикам процессов, и докладываю их разным другим начальникам, которых в каждой компании свой набор. Из комбинации красных цифр, превращённых в риски, как мы уже видели раньше, складывается стратегия безопасности компании.
Страсти, битвы и противоречия
Основной камень преткновения всего, везде и всегда — Asset Management (управление ИТ-активами). С одной стороны, на нём строится всё остальное, поэтому если он вам не удался, всё остальное тоже будет хромое, кривое и косое. С другой — он скучный и ни фига не романтичный. Вот ещё — роутеры в списочек складывать и стрелочки между ними рисовать! Ну фу же.
Скучные вещи принято автоматизировать, и Asset Management — прекрасный кандидат, потому как перечислять вручную, что у тебя есть предмет 1 — Vmware node, предмет 2 — storage unit, предмет 3 — виртуальный сервер, предмет 4 — веб-сервер на виртуальном сервере, предмет 5 — база данных на том же сервере, предмет 6 — системный аккаунт, под которым работает база данных, которая стоит на сервере… Ну вы поняли. Утомляет. А таких логических слоёв на большой инфраструктуре могут быть десятки, и каждый из них важен, потому что если у тебя есть две базы данных, одна с ценными клиентскими данными, а другая без, то лучше бы тебе их хорошенько различать.
Но с автоматизацией традиционный затык: 1) дорого, 2) долго, 3) надо собраться с духом и пережить большие первичные инвестиции — как денег, так и времени. Программы, которые бегают по Сети, собирают информацию обо всём, что в ней живёт, и строят все вот эти логические связи между слоями, стоят немало. Программы, в которые потом сливаются данные по найденным предметам, стоят ещё больше. Одно в другое надо интегрировать и потом поддерживать. Объяснить руководству, почему это не стоит делать наскоро руками в Экселе или просто продолжать верить в хорошее, не всегда просто. Связь всей этой одиссеи с безопасностью вообще ни фига не очевидна со стороны. Поэтому компания обычно успевает навернуть приличный кросс по граблям до того, как смирится и построит себе хоть какой Asset Management.
Дальше в дело идёт второе Великое Противоречие и ночной кошмар любого процессника. Нужно убедиться, что все участники понимают: это не спринт, это не марафон, это вообще навсегда. Обычно как только высокое начальство выпускает процесс из поля зрения и приоритезации, всё немедленно летит к чертям. Эту штуку нельзя закончить, её нельзя красиво описать в release notes и продать клиентам за много денег — она будет отъедать у тебя ресурсы, портить тебе жизнь и светить красными цифрами при любом удобном случае, а прямой немедленной выгоды из неё поди добудь.
Так что основное правило у нас примерно одно: знай то, что берёшься защищать. Знай инфраструктуру, знай инструменты в наличии, знай людей. И тогда из всего этого что-нибудь да накомбинируешь.
Что надо знать, чтобы попасть в ИБ
Техническому специалисту попасть в безопасность проще: достаточно определиться с областью интереса, а там — интернет вывезет. Главным архитектором с порога не возьмут, пожалуй, но при чудовищном дефиците кадров даже сертификаты предъявлять, возможно, не придётся.
Один вариант — хорошо знать операционные системы, популярные технологии и основные уязвимости всего этого. Хорошо разобраться в том, что имеется лично у тебя в компании. Потому что если в голове у тебя модное и новое, а на руках пожилой Оракл, то работать придется с Ораклом, куда деваться. Тогда можно смотреть в сторону пентестеров или консультировать программистов и инфраструктуру по части безопасности. У пентестеров есть довольно много недорогих ресурсов для практики вроде TryHackMe.
Можно попробовать свои силы в bugs bounty, искать уязвимости на публично доступных ресурсах, но тут лучше поосторожнее: вместо приятного денежного поощрения можно получить неприятный визит в полицию, если владелец ресурса тебя неправильно поймёт. Впрочем, нормальные это скорее поощряют и даже раздают смешные футболки в ответ на сообщения об уязвимостях:
Другой вариант — хорошо знать какой-то тип инструментов, с которыми работает безопасность: к примеру, сканеры уязвимостей (Qualys, Rapid7, Tenable) или SIEM (Qradar, Exabeam, что там ещё). Но тут их придётся сначала как-то изучить, а дело это не быстрое и не дешёвое, так что это скорее история о ротации из смежных областей.
Как стать руководителем в ИБ
Управленец должен знать стандарты, регуляции и иметь нужные личные качества.
Обобщённо в Европе есть, например, стандарт, на который если не равняются, то хотя бы оглядываются все: ISO 27001. В Америке уважают свой стандарт, разработанный NISTом. В России или Китае наверняка тоже найдутся собственные. Это самая база, основа всего. В дополнение к этому хорошо пойдут ITIL или COBIT для понимания процессов за пределами собственно безопасности, потому как вам с ними жить.
А вот дальше начинается интересное — отраслевые и географические регуляции. Если вы в Европе, к этому добавляется GDPR: локальные правила обработки данных о физических лицах. Если вы имеете отношение к карточным платежам, добро пожаловать в мир PCI DSS — стандарта безопасности для карточных данных. Если ваша компания работает в здравоохранении, там свои стандарты, причём разные для разных локаций. В США безопасность регулируется не только на уровне государства целиком, но ещё и по штатам в частности. В общем, тут глобально не посоветуешь.
Но процессы, как и любое руководство, требуют, в первую очередь, личных качеств, которыми никакой дорогущий MBA тебя не обеспечит. Надо уметь строить сложные структуры из людей, программ, правил и регуляций так, чтобы всё это работало. Если ты умеешь это в любой другой области айти, разобраться в специфике не так сложно.
После того как ты обрёл понимание корпоративных айти-процессов вообще (ITIL или COBIT) и ознакомился со стандартом-другим покрупнее (ISO 27001 или NIST), можно сосредоточиться либо на какой-то особенно симпатичной области, либо на общих вопросах управления корпоративной безопасностью. Можно прикупить пару-тройку солидных книжек вроде Chief Information Security Officer Handbook Аллена или The CSO Guide Эллиса. Но, если честно, удачно подобранная лента в LinkedIn окажет вам ту же услугу или даже лучше — специалисты по информационной безопасности с удовольствием делятся там новостями, историями и своими соображениями совершенно бесплатно и куда более лёгким слогом. Ну разве что вы очень, очень любите длинные английские слова.
Как меняется ИБ или куда мы катимся
Катимся мы, разумеется, вниз — как гравитация велит. Желающих пощипать корпорации за бока становится всё больше, знаний для этого требуется всё меньше, иногда достаточно удачно скачать какой-нибудь скриптик, а иногда и этого не требуется — слава социальной инженерии. Ни наём, ни обучение за этими энтузиастами не поспевают: если найти технического специалиста и посадить перед монитором ещё как-то можно, то найти того, кто встроит этого технического специалиста в процесс так, чтобы специалист не убежал в лес на третий день, сложнее. Сама по себе идея безопасности, отличной от настройки файервола, для многих компаний всё ещё очень нова. Так что пока статистика скорее удручает: средний возраст уязвимости, через которую влезают злодеи, составляет семь лет. То есть это не новое и модное, за которым не успели, это старое и известное, на которое забили.
И поскольку социальной инженерией всё лучше овладевают те же злодеи, корпоративная безопасность всё больше отходит от файерволов в работу с людьми как главным вектором атаки. Как хорошо ты ни настрой файервол, какого лучшего на свете спеца ни найми, а если ему позвонить посреди ночи и наорать, что ты главный начальник и файервол мешает тебе показывать клиенту, что надо вот прямо сейчас, с приличной вероятностью файервол от такого не поможет. Поэтому в безопасность приходят психологи, социологи и педагоги. Пока скорее в большие компании, которые могут позволить себе отдельного человека на security awareness, но это дело времени.
Их задача — во-первых, подготовить любого программиста Васю, менеджера Петю или бухгалтера Галину Петровну к мысли, что безопасность компании — дело буквально каждого живого человека в этой самой компании. Истории про уборщиц, у которых удачно забирали бумажный мусор, а в нём находили всё нужное для атаки, давно не новость. Во-вторых, продумать работу с теми особенностями психики, которые и делают социальную инженерию успешной.
Представьте, что утром вы проходите в офис через дверь, которая открывается вам по личной карте. Пришли, приложили карту, вас догоняет симпатичный человек в дорогом костюме, который напряжённо разговаривает по телефону и одновременно изображает вам лицом «придержите дверь, пожалуйста, а то телефон, портфель и дождь на улице!». Так вот: абсолютное большинство людей, включая безопасников, дверь придержат и даже задуматься над этим не успеют — потому что мама в детстве говорила, что вежливым быть хорошо, а невежливым — плохо. Так же точно придержат дверь для деловитого человека в спецовке с лестницей на плече. Надпись на спецовке при этом читать не станут, даже если она есть. Ну и уж тем более покорно отключат файервол для негодующего начальника посреди ночи, а тот ли это начальник и откуда он взялся, разбираться, пока он орёт, не будут. С этим вот и надо работать.
Ещё один важный аспект работы специалиста по security awareness — научить учить. Немалое количество моих коллег с удовольствием утопит вас в официальной документации в ответ на любой вопрос. Шанс выжить среди «вышеизложенных» с «нижеподписавшимися» у простого человека, скажем, не совсем нулевой, но будет ли ему от этого польза? Непонятно. Поэтому курсы и базы знаний должны быть как минимум понятными неспециалисту, а как максимум — ещё и увлекательными. Чем больше ты увлек бухгалтера Галину Петровну, расположил к себе и убедил, что глупых вопросов не бывает, тем больше шансов, что она принесёт тебе в клювике это странное письмо со ссылкой, а не молча скопирует в ответ свой логин с паролем и отправит прямиком в злодейскую базу.
Так что чем дальше, тем больше и разнообразнее становится эта область, и период в ней сейчас необычайно интересный. Приходите и вы.
Автор: Hanna Katargina
