Месячник молчания закончен - спешу сообщить, что блог переехал на новый домен - lukatsky.ru, где мы с вами и встретимся :-)
Тут всем пока, а там всем привет! И с международным днем защиты информации!!!
Бизнес безопасности или безопасность бизнеса? О том и о другом в одном непросветительском блоге от еще неиностранного агента... Имеющий мозг да применит его (6+)
Месячник молчания закончен - спешу сообщить, что блог переехал на новый домен - lukatsky.ru, где мы с вами и встретимся :-)
Тут всем пока, а там всем привет! И с международным днем защиты информации!!!
Вы обращали внимание на снижение качества нормативных документов от наших регуляторов? Когда смотришь в сторону только одного регулятора или одной сферы регулирования это не так заметно. Но когда пропускаешь через себя творчество всех органов исполнительной власти, то это очень сильно бросается в глаза. И дело не столько в синтаксических или орфографических ошибках, сколько в большом числе нестыковок, неточных и непонятных формулировок, которые требуют разъяснений от их автора, которые, конечно же, никаких пояснений не дают.
Давайте к примерам? Возьмем методику оценки угроз ФСТЭК, утвержденную 5-го февраля этого года. ЭТОГО! Но уже известно, что регулятор готовит в нее поправки. Документу от силы было полгода, когда регулятор решил вносить в него изменения, которые, согласно публичным высказываниям регулятора, планируют утвердить в первом квартале уже следующего года. У Банка России такая же проблема. 716-П по рискам вступило в силу 1-го октября прошлого года, но уже готов проект с поправками в него на 30+ (!) страниц. Не это ли свидетельство того, что документ получился сложным для восприятия? Ну а как может быть иначе, когда у вас нормативный акт занимает 130 страниц и к нему еще готовится ГОСТ на 180 страниц. 300 страниц (!), которые можно было бы изложить на одной странице формата А4! И это только один пример - у ЦБ таких косяков просто масса (отдельный пост им посвящу). РКН со своим 1046-м Постановление Правительства по надзору в области персональных данных тоже накосячил - и в расширительном толковании отдельных терминов, и синтаксических ошибках. И это только три примера, которые достаточно свежие и от разных регуляторов, но их ведь гораздо больше.
Как с этим бороться? На мой взгляд вариантов решения проблемы всего несколько. Первый - сформировать пул лояльных специалистов, которые не будут зависеть от регулятора, и через которых можно было бы пропускать проекты нормативки с обещанием принять всю критику и постараться ее исправить. Причем делать это адресно в обе стороны, а не так обезличенно, как это сейчас работает на regulations.gov.ru. Хотя где найти таких специалистов в достаточном количестве? Все же реально ссут сказать что-то супротив регулятора, от которого зависит сертификация выпускаемых твоей компанией продуктов или обновление/расширение лицензии или еще какие-то ништяки. Надо сказать, что это не совсем проблема регулятора, что у нас исторически все боятся сказать что-то против политики партии, но и его тоже - он же поощряет ее.
Второй вариант - при выходе каждого нормативного акта давать переходный период в 6-12 месяцев на его апробацию и без введения его в контур обязательных требований. Тогда первые желающие смогут попробовать что-то сделать, наступить на все грабли и сообщить о них регулятору, который внесет поправки в свои документы и выпустит уже гораздо более проработанный с точки зрения практики документ. Но и тут есть подводные камни. Не все захотят по доброй воле апробировать необязательные пока еще нормативные требования. А потом нужно время на повторную регистрацию документов в МинЮсте, что занимает много времени (сейчас доходит до шести месяцев). Ну и проблема "бесстрашных" рецензентов из предыдущего пункта тоже никуда не девается.
Можно попробовать пропустить документ через маленькие предприятия, в том числе поднадзорные, чтобы понять, насколько написанное реализуемо с малыми ресурсами. Такое замечание было очень частым после принятия ЦБшного ГОСТа 57580.1, который рассчитан на крупные финансовые организации, которые и принимали участие в его написании. Но и тут нас поджидают упомянутые ранее подводные камни.
Хорошей практикой является обучение. Есть высказывание, что когда начинаешь готовить материал для обучения и преподавать, то начинаешь лучше разбираться в вопросе (а почему я так активно преподаю, а?). А когда начинаешь рассказывать, что же ты имел ввиду в документе по 10 раз перед разными людьми, тогда лучше начинаешь понимать и область регулирования и свои корявые формулировки. Можно, конечно, сделать вариант-минимум - читать перед подчиненными, но они же правду в глаза не скажут все равно. Поэтому только публичная активность, но на это рассчитывать не приходится - не приучен у нас регулятор к публичной критике, а еще и отомстить может.
Пятый вариант заключается в том, чтобы попробовать сферического коня в вакууме в своем загоне, то есть в самом регуляторе. Вот выпустил ДИБ положение 716-П по рискам - так ты сначала его пропусти через своих ИТшников и ИБшников и посмотри, что они тебе скажут (ничего хорошего, кстати, не скажут). Вот выпустил ты методику по оценке угроз - так ты ее сначала на себе опробуй и выложи в качестве примера разработанный по методике документ. Причем обязательно, чтобы реализовывал нормативные требования не их автор, а лицо, которое впервые эти требования увидит.
Вот тогда у нас начнет реализовываться хотя бы один из озвученных вариантов, а лучше все вместе, тогда у нас качество документов сильно поднимется и претензий к регуляторам станет гораздо меньше. Если их, конечно, это волнует.
Решил я тут раскрыть чуть больше краткую заметку в своем Telegram, посвященную моделированию угроз в процессе разработки ПО. Я написал следующее: "Методика оценки угроз ФСТЭК не применяется при моделировании угроз в рамках безопасной разработки. Учитывая, что ФСТЭК уделяет последней очень много внимания, стоит ли ждать отдельного документа/стандарта по этому вопросу? Пока у меня нет ответа на этот вопрос, хотя появление ГОСТа по этой теме было бы логичным.
А пока можно использовать сторонние источники для моделирования угроз в рамках разработки:
- STRIDE от Microsoft (и Threat Modeling Tool от них же)
- OWASP - (и Threat Dragon Tool от них же)
- Матрица угроз ATT&CK для CI/CD
- Инструмент Materialize Threats Tools
- PyTM
- Agile Threat Modeling Toolkit"
Коллеги обратили мое внимание, что у ФСТЭК есть разделы в ГОСТах по безопасной разработке, посвященные моделированию угроз. И вот этот момент я бы и хотел прокомментировать. Если мы возьмем ГОСТ Р 56939 "Разработка безопасного ПО. Общие требования", то в разделе 5.2.1 говорится, что разработчик должен провести моделирование угроз, а в разделе 5.2.3.1 этот вопрос раскрывается чуть подробнее, но и в нем не приводится никакой методологии моделирования, а всего лишь уточняется, что она должна быть и что документация разработчика должна содержать описание выбранной методологии, список выявленных угроз и список мер, эти угрозы нейтрализующих.
Эта процедура моделирования из методики Microsoft |
Список угроз можно найти в другом стандарте - ГОСТе Р 58412 "Разработка безопасного ПО. Угрозы безопасности информации при разработке ПО", в котором перечислено 19 угроз. Но в нем также нет методологии выбора из перечисленного перечня угроз актуальных. Да и сами угрозы достаточно высокоуровневы и хотелось бы иметь их большую детализацию. Например, огромный пласт угроз для процесса CI/CD или угрозы, реализуемые через репозитории кода, объединяются в одну - угрозу внедрения уязвимостей программы из-за неверного использования инструментальных средств при разработке ПО. Лично мне не хватает в ГОСТ 58412 деталей, - тех же техник и тактик, которые есть в методике ФСТЭК, процедуры выбора угроз, примеров, то есть ровно того, что сделает документ практически полезным в работе.
А, например, угрозы при использовании API куда попадают в рамках упомянутого ГОСТа? А отсутствие шифрования или хотя бы хэширования паролей в разрабатываемых приложениях? А отсутствие контроля вводимых параметров? Или это не угроза, а уязвимость переполнения буфера (хотя SQL Injection это именно угроза)? А угрозы генерации неслучайных чисел в "датчиках случайных чисел"? А работа с памятью, позволяющая выполнять вредоносный код от имени привилегированных пользователей/процессов? А, в конце концов, нарушение правил контроля доступа, которое отвечает за 10 из 30 основных проблем безопасности ПО? Или такой уровень детализации не является предметом регулирования ГОСТ 58412? Вообще, хотелось бы видеть либо что-то аналогичное проекту CAPEC от MITRE (раз уж мы так активно используем концепции этой корпорации у нас), либо ссылку на возможность его использования в том же ГОСТе 58412 (рах уж мы ссылаемся на CAPEC в методике оценки угроз от 5-го февраля).
Главное, не забывать, что в методике важно иметь не только сам перечень угроз и процедуру их выбора, но и способ ранжирования актуальных угроз, которых может получиться немало и которые надо устранять не одним разом, а по частям. А вот в какой последовательности эти части будут формироваться нам подскажет методика ранжирования.
Ее, кстати, нет и в текущей методике оценки угроз, что ставить нас перед непростой задачей - какую из актуальных угроз нейтрализовывать первой, какую второй, какую третьей и т.д. Ровно то, о чем я писал в июне, рассказывая о методике TARA той же MITRE. А применительно к моделированию угроз в рамках безопасной разработке за основу такого метода ранжирования можно взять DREAD от Microsoft, а можно и что-то другое.
А пока я остаюсь при своем мнении относительно того, что пока у нас нет методики оценки угроз в рамках процесса безопасной разработки. Но именно что пока...
Последний круглый стол на конференции “Кибербезопасность нового времени” в рамках казанской DigitalWeek оказался мне ближе всех, так как обсуждаемая на нем тема интересует меня давно и мой блог по сути и начинался скоро уже 15 лет как именно с нее, а именно с бизнес-ориентации в деятельности службы ИБ. Это постоянная тема дискуссий последних пару лет и без нее не обходится ни одно мероприятие. Должен ли CISO заниматься только ИБ в классическом его понимании (борьба с угрозами и выполнение требований регуляторов) или ИБ - это более широкая тема и CISO может и должен выходить за привычный, но достаточно узкий мир нарушителей и compliance. В этой дискуссии, так уж случилось, участвовали только представители финансовой отрасли:
Но несмотря на это озвученные ими примеры могут быть применены не только там, а гораздо шире. Одним из таких примеров стали кадровые риски, в снижении которых ИБ может принять самое непосредственное участие и дело тут не только в том, чтобы заниматься повышением осведомленности персонала или поиском инсайдеров внутри компании, помогая экономической безопасности (хотя это тоже вполне себе интересный кейс, выходящий за рамки классической ИБ). Уже набивший оскомину пример с обнаружением работников, готовящихся к увольнению. Да, этот сценарий требует определенных условий для срабатывания (сотрудник должен пользоваться корпоративными устройствами для доступа на сайты для поиска работы, рассылку резюме или получение предложений о работе), но он вполне себе укладывается в возможности ИБ, имеющей весь необходимый инструментарий для того, чтобы оперативно обнаруживать тех, кто готов пойти на сторону. Возможно менее этичный, но недавно активно обсуждаемый кейс, - это анализ активности работника и предоставление кадрам и начальству данных об активности сотрудника и том, работает он вообще или балду гоняет. И вот тут закономерно развернулась некоторая дискуссия. Одни высказывались в пользу того, что не дело ИБ следить за тем, как тратится рабочее время компании. Другие говорили, а почему бы и нет?
Как мне кажется, все будет зависеть от того, с какой позиции мы смотрим на эти примеры; с точки зрения функции или инструмента? Да, возможно слежение за рабочим времени - это не функция ИБ (что не мешает ИБ-вендорам активно допиливать свои решения именно для этой задачи). Но не стоит забывать, что ИБ - это не только функция, но и инструмент, который может быть использован и другими подразделениями для их задач. ИБ дает возможность, а уж применить ее или нет - дело другое. Поэтому в описанных выше двух случаях ИБ имеет инструмент, который может собрать данные, которые могут быть предоставлены кадрам. Если для компании удержание сотрудников и снижение ротации важны, то ИБ может помочь решить эту задачу (наряду с другими подразделениями). Если в компании руководство беспокоится о том, не бездельничают ли сотрудники за зарплату, то ИБ может помочь и тут (хотя контроль рабочего времени - это вообще отдельная тема, имеющая очень много граней и нюансов).
Другой пример бизнес-ориентированности CISO - снижение CapEx. Да, урезание бюджета - вещь неприятная, но встречающаяся достаточно часто. Можно жаловаться на жизнь, а можно попробовать извлечь из нее пользу и показать, что ИБ разделяет интересы компании, перейдя в части своих услуг с CapEx-ной модели на OpEx-ную, заменив “железные” решения на облачные, а внутренние сервисы передав на аутсорсинг. Да, это грозит потерей компетенций и снижением контроля, но на то мы и говорим с позиций бизнеса, что нужно взвешивать все за и против, всю плюсы и минусы, предлагая взвешенное решение и демонстрируя бизнес-ориентированность.
А может ли ИБ зарабатывать? Такой вопрос тоже прозвучал на круглом столе и Сергей Демидов ответил на него положительно, хотя и не скажу, что озвученный им вариант подойдет многим. Сергей возглавляет небольшого оператора связи, работающего в интересах биржи, который помимо услуг связи предоставляет также услуги удостоверяющего центра, зарабатывая на них (есть и другие варианты, о которых говорится в видео по ссылке ниже). Да, это уже не совсем in-house функция, но все равно служит интересным примером того, как руководитель ИБ может выйти за пределы своих привычных задач. Я знаю пример финансовой организации, которая предлагает своим привилегированным клиентам, имеющим на счетах сумму, выше определенного значения, услуги по ИБ, в том числе и защиту бренда. В другом случае служба ИБ оказывает услуги своим клиентам из сегмента малого бизнеса, по сути выполняя для них роль сервис-провайдера по ИБ. Ведь малый бизнес не имеет возможности строить у себя нормальную ИБ. Почему бы тогда не возложить эту задачу на службу ИБ своего банка?
Если не заработок, то может ли ИБ влиять на прибыль компании? Надо отметить, что не слишком подкованные в финансах технари, часто путают прибыль и доход. Да, ИБ может не приносить дохода, но при этом влиять на снижение расходов, тем самым увеличивая прибыль предприятия. И дело не только и не столько в том, чтобы снижать стоимость инцидентов или предотвращать мошенничество, о чем мы тоже говорили. Например, можно существенно снизить затраты компании на отправку одноразовых кодов по SMS для входа в систему ДБО, если подумать о том, как обычно клиенты подключаются к своему онлайн-банкингу. Делается это обычно с одного и того же мобильного устройства, которое не меняется годами. Так зачем каждый раз спрашивать клиента “Это ты?”, если можно профилировать его устройство и в случае совпадения с профилем, считать устройство доверенным и не отвлекать пользователя смсками? Такой подход позволяет сократить 10-40% затрат на отправку SMS, что выливается при текущих расценках в кругленькую сумму. Заработок ли это? Нет. Влияет ли на прибыль? Безусловно. Интересно это бизнесу? Конечно. Об этом кейсе, кстати, можно послушать в "свежевыжатом подкасте", приуроченном к грядущему SOC Forum 2021, в котором моим гостем был Лев Шумский, глава кибербеза Яндекс.Банка (подкаст №2).
Но такая ориентация на бизнес требует от CISO новых навыков. Как было правильно отмечено на круглом столе - CISO может быть “военным” или “предпринимателем”. В первом случае он может отлично выполнять традиционные для ИБ задачи, но не выходить за их рамки. Во втором случае он ищет как помочь бизнесу с позиций предпринимателя. И у него это получается. И тогда у него появляется шанс вырасти за пределы обычного руководителя ИБ, “подмяв” под себя управление операционными рисками, непрерывность бизнеса, операционную надежность. Сергей Демидов упомянул концепцию S-кривых, которая описывает эволюцию многих технологий, многих компаний и даже людей. Сначала вы растете в своей роли, но в какой-то момент достигаете пика в развитии и у вас начинается движение по длительному плато, которое может в любой момент прерваться, так как вас обойдут более агрессивные, опытные, квалифицированные коллеги. Чтобы расти дальше вам надо выйти за пределы своей роли и сделать шаг в неизвестность, который может вывести вас на новый уровень, на новую кривую. И так далее. Для ибешника это означает, что он может начать свою карьеру как обычный сотрудник отдела защиты информации, занимаясь своей узкой сферой, развиваясь в ней. Следующим кардинально новым шагом может стать желание быть руководителем, что требует новых навыков и знаний. Проработав в этой роли, CISO может захотеть пойти еще выше и тут варианты его карьеры могут разойтись. Он может пойти в корпоративную безопасность, подмяв под себя темы экономической, физической, антитеррористической безопасности. А может пойти в сторону рисков и непрерывности бизнеса. И это очередной вызов, требующий новых знаний и навыков. А потом это может быть собственный бизнес и т.д.
На круглом столе мы обсуждали еще многие темы, но я не хочу пересказывать абсолютно все и не буду раскрывать секрет, как связана деятельность CISO с движением Black Lives Matter или концепцией ответственного инвестирования ESG, о которой сегодня не говорит только ленивый и которая вроде как не имеет никакого отношения к ИБ, но оказывается, что имеет. А ESG - это повестка дня руководителей крупнейших мировых компаний. И если CISO может встроиться в эту повестку, то это отлично. Но об этом вы можете сами услышать, посмотрев эфир, любезно записанный компанией Innostage, которая и организовала этот и другие два круглых стола, которые я вел, ссылки на записи которых ниже, и о которых я писал последние заметки:
Вторым круглым столом на конференции "Кибербезопасность нового времени", проведенной Innostage в рамках казанской DigitalWeek, был "Формальная безопасность vs практическая безопасность: как достичь синергии", который получился не таким, как я его задумывал изначально, готовя вопросы. Поэтому в этой заметке я буду говорить не столько о самом круглом столе, сколько о том, во что вылилась дискуссия и что я про все это думаю.
На самом круглом столе немного предсказуемо почти все участники высказались в поддержку нормативных требований регуляторов, что, на мой взгляд, вполне объяснимо, - не любят у нас публично критиковать регулятора, так как последний этого не любит и может отыграться во время проверок или продления лицензий или еще как. Только Сергей Демидов из ММВБ высказал все (ну или почти все), что он думает про регулирование финансовой сферы и КИИ и про то, насколько подкованы регуляторы во многих практических вопросах. Интересно, что на вечерних посиделках (а Innostage славится своими неформальными мероприятиями - от автогонок до /censored/) многие представители госорганов гораздо более откровенны и высказывают все, что они думают о регуляторах и об их требованиях.
Возьмем к примеру уже полгода как принятую модель оценки угроз ФСТЭК. Я про это писал уже неоднократно, но даже сейчас меня регулярно удивляют "вести с полей". Например, во время согласования модели угроз (а это обязательное требования по 676-ПП для всех ГИС) одно из региональных управлений сначала долго отнекивалось и пыталось манкировать своими обязанностями, а потом предупредили, что все равно придется пересогласовывать, так как после разработки нового БДУ (банк данных угроз) потребуется пройти процедуру заново! Ну вот как так? Почему об этом нигде не говорится и зачем вообще тогда надо было принимать документ, который нормально и не применить и меньше через год надо повторять процедуру (а деньги где брать)?
Или вот еще история. В самом начале круглого стола, который проходил сразу после выступления Романа Чаплыгина из Positive Technologies об открытых стандартах по ИБ (лучших практиках, создаваемых сообществом), я задал вопрос в зал, сколько из них знает о профессиональном стандарте 12.004 "Специалист по обнаружению, предупреждению и ликвидации последствий компьютерных атак", который был утвержден в 2015 (!) году? Шесть лет назад! Было всего 3 поднятых руки! Всего три на зал из 150 человек. А все потому, что этот стандарт имеет пометку "для служебного пользования". Ну вот о каких открытых стандартах можно говорить, если регуляторы у нас так любят политику засекречения всего, даже списка навыков, которым должен обладать специалист по реагированию на инциденты ИБ? Но интересно не это, а то, что получить этот документ нереально. Если вы запросите его в Минтруде (захотите найти - спрашивайте в Минтруде приказ 1179н/дсп от 29.12.2015), вам откажут и пошлют в ФСБ. Запрос в ФСБ тоже закончится ничем - вас отправят в Минтруд. Вот такой замкнутый круг. А я напомню, что согласно ПП-584 от 27.06.2016 профстандарты являются обязательными к применению всем государственным и муниципальным учреждениям, фондам, а также предприятиям, компаниям и корпорациям, что принадлежат государственным либо муниципальным органам власти (на праве владения более чем 50% от уставного капитала).
Еще одна обсуждаемая на круглом столе тема - трактовки требований регуляторов. Это вообще боль; даже для самих регуляторов, в которых написание требований и их проверка - это часто разные подразделения. А тут еще приближенные к регуляторам компании, которые часто участвуют в разработке требований в составе рабочих групп. Представители этих компаний потом выступают на мероприятиях, в чатах, в соцсетях и выдают собственное мнение за позицию регулятора. Ну есть еще и просто эксперты, которые также по своему трактуют требования нормативных актов. И вот у нас уже 4 разных точки зрения на один документ. И как тут быть? Участники круглого стола, например, Виктор Вячеславов из Innostage, Шальнов Олег из Росэнергоатома или Александр Дубасов из ФГБУ ЦНИИОИЗ Минздрава, посоветовали общаться с регулятором, задавать ему вопросы. Но тут всплывает классическая история - лучше не светиться :-( Наши регуляторы любят при общении с народом задавать вопрос: "Представьтесь, пожалуста" или "Какую организацию вы представляете?" Ну и кто захочет отвечать на такой вопрос? Смельчаков мало. Вот и любят у нас все ждать, когда кто-то храбрый сам спросит регулятора, а потом выложит ответ в каком-нибудь чатике. А сам регулятор, не видя вопросов, считает, что все нормально. Или он видит вопросы с мест, но не хочет публично показывать, что он поторопился с каким-то требованием. Поэтому и информационные письма с разъяснениями он не часто выпускает, ограничиваясь короткими комментариями в узком кругу специалистов или на закрытых встречах. И те, кого на этих мероприятиях "за закрытыми дверями", нет, потом вынуждены слушать пересказы и играть в испорченный телефон.
А вот еще один классический вопрос: "Почему <регулятор> сам у себя не реализовал свои же требования?" Почему на сайте ФСТЭК в разделе "Государственные информационные системы" написано, что у регулятора нет ни одной ГИС? Вы верите в это? Я лично нет. Особенно слыша ответы регулятора на мероприятиях по поводу того, что считать ГИС. Но тогда почему у самой ФСТЭК нет ни одной ГИС? А ОКИИ? ФСТЭК говорила на мероприятиях, что у них есть ОКИИ (научной деятельностью они же занимаются в том же Воронеже). Тогда почему они часто "плывут" на практических вопросах по 235/239-м приказам? А Банк России? ДИБ пишет кучу Пэшек, Ушек, ГОСТов, а потом их должны выполнять в том числе и другие подразделения ЦБ. И у них тоже немало вопросов к регуляторике, которую непонятно как выполнять на практике, так как она местами предельно неконкретна, расплывчата, а то и имеет двойственное/тройственное толкование. С ФСБ все проще - они по-моему до сих пор не имеют локальной сети и живут в мире автономных компьютеров, а обмениваются документами бумажными. В их мире их требования чуть ли не идеальны.
Еще одним выводом с круглого стола стало, что выполнение требований никак не гарантирует безопасности организации. Зачем тогда нужны требования, тем более обязательные? Не лучше ли превратить их в рекомендации? Особенно в условиях, когда отдельные регуляторы начинают пропагандировать риск-ориентированный подход, который, как известно, отличается от обязательных требований тем, что в нем мы сами определяем, что для нас опасно, а потом определяем, что мы будем с этим делать - принимать риски, перекладывать, уклоняться или снижать их. Такой подход, кстати, ФСТЭК реализует в ИСПДн и КИИ (для ГИС установлен минимальный, базовый набор требований по защите). А ЦБ, на гербе которого двуглавый орел, смотрящий одновременно в разные стороны, успешно реализует эту идею и в регулировании ИБ, одновременно устанавливая обязательные требования по ИБ в своих Пэшках и Ушках, а также обязывая оценивать риски и меры управления ими. Зачем мне управлять рисками, если все равно я обязан выполнять кучу требований?
Вот такой был круглый стол в Казани, который не ограничился только залом, а вышел за его пределы и дал возможность поговорить с участниками "не под камеру". А это всегда ценно.
ЗЫ. Мне кажется, что регуляторам надо выпускать свои документы тройками - сами требования, разъяснения к ним для тех, на кого требования распространяются, и методика их проверки (в идеале тоже публичная). Все три документа должны быть взаимоувязаны между собой. Тогда и проблем ни с их толкованием, ни выполнением, ни проверкой не будет (ну кроме редких ошибок и клинических идиотов). Прислушался бы кто-нибудь, а?!
Во вторник и среду довелось мне по приглашению моих друзей из компании Innostage посетить организованную ими конференцию по кибербезопасности в рамках более крупного ИТ-мероприятия DigitalWeek с участием Президента Татарстана, министра российской цифровизации и других не менее высоких чинов. Я не выступал, но зато вел три дискуссии, обзором которых и хочу поделиться в серии заметок. Первая из них называлась "Отстает ли российский рынок ИБ от западного?".
Фрагмент ИТ-выставки |
Началось все с провокационной просьбой в зал поднять руки тем, кто считает, что российские решения лучше или хотя бы не уступают по своим функциональным характеристиками и качеству иностранным аналогам. И чтобы вы думали? Всего одна рука в зале на 200 человек. Это достаточно показательная картина, на которой можно было и завершить круглый стол, так и не начав его, но мы не ищем легких путей и поэтому я стал мучать участников дискуссии вопросами о том, когда “иностранцам” в России укажут на дверь и что делать потребителю, которого заставляют мучаться, но есть кактус?
Фото с предшествующей сессии про то, что ждет отрасль ИБ и ИТ через 3-5 лет |
Василий Дягилев (CheckPoint) высказал мысль, что российские игроки за последнее время сделали гигантский скачок и если еще три года назад никто всерьез их и не рассматривал, то уже в прошлом, пандемийном году они очень быстро перестроились под нужды рынка, а сейчас достаточно активно наступают на пятки иностранным игрокам. Тут я могу частично согласиться с этой позиций - с момента подготовки моей презентации о домотканных средствах защиты (вот тут я тоже про это писал) на российском рынке появились не только новые имена среди игроков, но и среди номенклатуры средств защиты. IRP, SOAR, DDP (обманки), THP (Threat Hunting), TIP (Threat Intelligence) и т.п. Да, пока многие из этих решений делают только свои первые шаги и аналогами их называть еще рано, но по крайней мере с точки зрения категорий решений они уже явно не пустуют, как это было еще несколько лет назад. Олег Шальнов из Концерна “Энергоатом” своей репликой подтвердил слова Василия и сказал даже больше - у них в Концерне произошло практически полное импортозамещение и в области информационной безопасности они используют практически 100% отечественных решений. Лично для меня это было удивительно слышать, так как буквально в этот же день на площадке ТНФ-2021 прошла сессия "Импортозамещение в ИТ: отечественные решения для нефтегазовой отрасли", на которой выступила с докладом Лилия Загородных, директор программ по рискам, импортозамещению и непрерывности деятельности Департамента информационных технологий, автоматизации и телекоммуникаций "Газпромнефти”. Она сообщила, что заявленный план перехода объектов КИИ на российское ПО и оборудование к 2023-2024 г. выглядит красиво, но нереалистично. "Как мне, как директору по импортозамещению перевести нефтянку на все российское ПО и оборудование? Это сложно. Для нефтяников в первую очередь приоритетом является безопасность. Я за импортозамещение и могла бы сказать, что мы это сделаем. Но я опасаюсь, что нет". Возможно в Газпромнефти и Энергоатоме разные ПО и железо, но я из практики тоже больше склоняюсь к позиции Лилии Загородных. Но вернемся к секции.
Владимир Бенгин (Минцифры), который отдувался за всех регуляторов, высказал очень здравую мысль о том, что импортозамещение должно быть умным, то есть не всех и не сразу, а только значимых объектов (уже немалое подспорье) и только по окончании срока амортизации (это из проекта Указа Президента по импортозамещению в КИИ). При этом субъект КИИ может и дальше использовать иностранные решения, если сможет обосновать соответствующей комиссии свое решение. При этом Владимир высказал мысль, что Минцифры против ухода иностранных игроков с российского рынка, так как у отечественных вендоров тогда пропадет не только пример, к которому можно стремиться, но и конкуренция, что приведет только к застою. Я целиком и полностью поддерживаю позицию Владимира и его министерства, но вот шаги, которые я вижу все-таки говорят о том, что государство в целом планомерно выдавливает “иностранцев” из страны, не предложим ничего взамен. Если государство думает, что иностранные игроки всеми конечностями будут жержаться за российский рынок и довольствооваться подачками, то это не так. И в тучные времена доля России в объеме бизнеса иностранных ИТ и ИБ-компаний составляла около 1%. По мере импортозамещения эта цифра будет снижаться и экономического смысла продолжать держать в стране мощные офисы, вкладываться в сертификацию (которая не дает никаких преференций и не позволяет попасть в нужные реестры), разработку и поддержку нет. Поэтому в какой-то момент времени крупные ИТ и ИБ компании могут просто развернуться и уйти из страны вслед за уже ушедшими небольшими игроками рынка.
Семирханов Мидхат (Forcepoint) добавил, что хороший (продаваемый) продукт, интересный не только в России, но и на Западе/Востоке, зависит не только и не столько от программистов, которые в России и правда хороши. Очень важную роль играет маркетинг и продажи, с чем у наших игроков наблюдается провал. Без них не то, что выходить к иностранным заказчикам бессмысленно (о том, что у вас классный продукт просто никто не узнает), но и в России и ее сателлитах о серьезном прорыве говорить не приходится. Ему вторил и Андрей Брызгин (Group-IB), упомянув клиентоориентированность как фундамент для развития бизнеса в ИБ-сфере. Тут, правда, и Владимир Бенгин. и Василий Дягилев отметили, что у российских игроков есть преимущество, так как они находятся ближе к клиентам и готовы быстрее реагировать на потребности рынка и заказчиков, реализуя фичи, которые у иностранцев нет и в ближайших релизах может и не появиться. Хватило бы денег на реализацию всех хотелок. Все-таки многие иностранные ИТ-монстры развивались на заказах от государства, что позволило им потом завоевать весь мир. Владимир Бенгин отметил, что наше государство тоже готово поддерживать ИТ-компании, хотя со своей стороны отмечу, что не каждый ИБ-игрок (особенно если он сервисный провайдер) может рассчитывать на помощь государства. Кроме того, пока о госзаказах речи нет и не факт, что они появятся в области ИБ.
Кстати, о сервисных провайдерах. Мидхат Семирханов несколько раз упоминал сервисную модель как некий тренд в мире и в России, но, как мне показалось, он так и не выразил до конца свою мысль, что если сервисный провайдер использует иностранные решения, то заказчик этого все равно не видит, получая готовый сервис от российской компании, что позволяет в целом обойти требование по импортозамещению. И насколько мне известно некоторое количество зарубежных ИБ-игроков прекрасно используют эту модель на практике (лайфхак для тех, кто ищет пути).
Пытаясь вовлечь зал в дискуссию, я задал еще один вопрос, - есть ли решения, которых им не хватает у российских игроков. Ответов не последовало, из чего я могу сделать вывод, что либо все участники просто стеснялись, либо они не используют российских решений и пока не рассматривают импортозамещение, поэтому и не знакомы с предложениями российских ИБ-вендоров (вариант, что их все устраивает я даже не рассматриваю). И только Андрей Иванов из компании Яндекс ответил на этот вопрос, сказав, что им не хватает высокопроизводительных МСЭ. средств шифрования для облачных сред. И это правда. Таких решений у нас действительно нет. И даже для необлачных их тоже нет. Я знаю, что даже регуляторы, навязывающие импортозамещение в России, по-прежнему используют иностранные решения у себя в ядре или в ЦОДах, не имея отечественных альтернатив или не рискуя их ставить у себя в инфраструктуре.
Продолжая тему поддержки государства хотел бы еще отметить негативный факт - если посмотреть на резидентов Сколково, которые являются реально стартапами, а не монстрами типа Инфовотча или Group-IB, то они либо умирают через год-другой, либо сразу ориентируются на западные рынки, просто не имея возможности найти в России свою аудиторию. Тут получается замкнутый круг, чтобы продать свои решения крупным заказчикам, надо быть в реестре Минцифры и Минпромторга и иметь сертификаты ФСТЭК или ФСБ. А чтобы получить эти сертификаты, надо потратить кучу денег на танцы с бубном и выполнение никому ненужных телодвижений или функций, которые еще и будут шоу-стоппером при выходе на зарубежные рынки. А чтобы потратить кучу денег - надо ее заработать. А чтобы заработать... В итоге у нас нет достаточного количества стартапов, как это происходит, например, в Китае, Корее, Израиле, Германии, Испании и, конечно, США. Я не успел задать этот вопрос, но есть мнение, что скоро в России останется только большая пятерка именно отечественных игроков по ИБ, а все остальные будут либо поглощены, либо вынуждены будут уйти с рынка.
Кстати, схожую мысль об укрупнении, но вокруг государственных компаний (Ростех, Ростелек, Сбер и т.п.) высказал и Мидхат Семирханов. Владимир Бенгин, как представитель государства, что интересно, высказался против такого огосударствления рынка ИБ, так как это приведет к его выхолащиванию. Посмотрим, кто будет прав на горизонте в 3-5 лет, а именно такой временной отрезок рассматривался на секции до “моей”, где представители Positive Technologies и Касперского высказали мысль, что у российских игроков все прекрасно, много перспектив, на Западе много денег и скоро отечественные ИБ-компании (которые еще останутся не под санкциями) завоюют весь мир. Мне понравился такой оптимизм, хотя, как мне кажется, коллеги, высказавшие эти мысли, не учитывают один простой факт. Китаю мы нафиг не сдались - у них игроков гораздо больше и иностранцев они не жалуют. А вот западный мир, живущий по христианскому принципу “око за око”, будут ставить такие же заградительные препоны (уже ставят), как это делается и в России. Причем, я не буду спорить о том, кто “первый начал”, но факт есть факт. Нас там никто не ждет и примеров действительно успешной экспансии на иностранные рынки, особенно в последние 4-6 лет (после реализации непреодолимого желания Крыма влиться в состав нашей необъятной Родины) я сейчас и не вспомню. Есть отдельные попытки выйти на рынки Средней Азии и Ближнего Востока, есть примеры поставок в страны Южной Америки и даже Африки, но победоносным шествием это пока назвать нельзя; так, скорее пробираемся огородами. Приводить в пример Касперского не стоит - он это делал задолго до геополитических баталий и объявления России врагом №2 (после Китая) почти во всех прогрессивных странах. После этого, успехом пока хвастаться некому. Разве что Group-IB, которая сменила прописку и штаб-квартиру с России на Сингапур. Но пока оценивать ее успехи и насколько она будет продолжать называть себя российской рановато.
В целом, если подводить итог часовой дискуссии, я бы отметил, что перспективы есть у всех сторон - у государства не накосячить, у иностранцев - не уйти с рынка, у российских вендоров - сделать действительно востребованные потребителями продукты, а не только закрывающие регулятивные требования. А пока мы находимся в позе Ван Дамма, раскорячившегося между двумя грузовиками, - либо удержимся, либо е*немся и тогда будет больно.
ЗЫ. Кстати, в заголовке использовалось слово “выпихнут”, а не то, что вы подумали.
В пятницу, на конференции Kaspersky ICS Cybersecurity Conference, я выступал с темой "Основные сценарии реализации угроз на АСУ ТП и их преломление на методику оценки угроз ФСТЭК" (презентацию выложил в своем Telegram-канале). К этому выступлению я планировал завершить перевод последней версии матрицы MITRE ATT&CK v9 на русский язык и маппинг техник ФСТЭК в техники MITRE ATT&CK, что и было сделано (ссылки будут ниже).
Ключевая идея моей презентации заключалась в том, что моделировать угрозы по методике ФСТЭК можно (по-крупному) двумя путями - сверху вниз и снизу вверх. В первом случае мы последовательно выполняем все шаги методики, перебираем все возможные угрозы и сценарии их реализации и на выходе получаем список актуальных угроз, который, в зависимости от типа организации, должен или не должен быть согласован с регулятором. Второй подход, как мне кажется, более практичен и применим именно к АСУ ТП, в которых атак пока гораздо меньше, чем в корпоративных сетях. Поэтому вместо моделирования сверху вниз можно отталкиваться от уже известных инцидентов, которые просто надо описать с помощью методики ФСТЭК. И тут нас подстерегает засада - все известные отчеты по инцидентам на АСУ ТП, в том числе написанные и нашими лицензиатами, описывают техники и тактики нарушителей по MITRE ATT&CK. А ФСТЭК требует моделировать по своей "матрице" техник и тактик, которые отличаются от MITRE. Поэтому я и задался целью связать то, что принято во всем мире как стандарт де-факто (пусть и неидеальный) и что требует делать ФСТЭК.
Первым делом я перевел текущую, девятую версию матрицы MITRE ATT&CK на русский язык. Да, я прекрасно понимаю, что специалист по ИБ должен знать английский и должен самостоятельно читать матрицу MITRE в оригинале, но, увы, это пожелание далеко от реализации и многие не так хорошо говорят/понимают по-английски, как того хотелось бы. Да чего там, я сам не могу похвастаться хорошим знанием языка :-) Но это не помешало мне перевести названия техник ATT&CK на русский язык.
Переводы и маппинг выложил пока в свой Telegram-канал "Пост Лукацкого", но думаю над Google.Drive и Github (точнее я туда уже тоже выложил, но пока не пойму, где удобнее). Но судя по опросу, проведенному в Телеграме, большинству удобнее, чтобы файлы были выложены именно там.
Если не рассматривать крупные организации, службы ИБ которых насчитывают сотни человек, то в массе своей нам обычно не хватает людей на все наши хотелки и мы всегда чувствует дефицит персонала. И чем мельче компания, тем сильнее этот дефицит, который надо как-то закрывать. И когда ты приходишь к генеральному директору за одобрением новых ставок в штат ИБ, ты часто слышишь: "Вас и так много (а "вас" в реальности всего один или двое)" или "И так непонятно, что вы там в ИБ делаете, дармоеды". И ты выходишь весь оплеванный и не знаешь, как обосновать выделение ресурсов. Могу поделиться достаточно простой моделью, которая, если и не обеспечит 100% выделение нужных ресурсов, но позволит с цифрами в руках обосновать, что вам нужно именно такое количество людей; не больше и не меньше.
Идея заключается в том, что мы должны выписать все функции, которые нам нужны для обеспечения ИБ в табличку и против каждой функции проставить число часов, которые эта функция требует. Подсчитать число часов не так уж и сложно - достаточно просто замерить, сколько времени тратится на работу с тем или иным техническим решением или на организацию какой-либо задачи/процесса. В качестве примера могу привести такую табличку для небольшой компании с достаточно простой инфраструктурой.
Такой расчет является точкой отсчета для общения с руководством, которое начинает понимать, что вы не из пальца высосали нужное вам количество людей, а имеете подтвержденные цифрами доказательства. Когда вы просто приходите с протянутой рукой, вы находитесь в позиции человека просящего. Когда у вас есть обоснованные расчеты, у вас появляется предмет обсуждения с руководством, которое будет стоять перед вполне осознаваемым ими выбором:
Возможно, вам стоит заранее подготовить этот список альтернатив с описанием каждой из них, чтобы руководство принимало решение, опираясь на конкретику, а не на эмоции. Теперь, когда вам надо будет добавить новых функций, например, после появления новой нормативки, вам будет проще добавлять к имеющемуся расчету новые FTE. Допустим, вы банк и вам "навесили" обеспечение непрерывной надежности и уведомление ФинЦЕРТ об инцидентах ИБ, а ИТ сбагрила вам проект по идентификации и аутентификации. В итоге у вас получится уже 260 часов или 6,5 FTE (7 человек).
Бывает конечно и так, что в организации один человек - "и швец, и жнец, и на дуде игрец", то есть этакий многостаночник, который способен работать за двоих, а то и троих человек, подменяя собой 2-3 FTE. Это редкость, но бывает. Также бывает и обратная история, сотрудник вроде и есть, штатную единицу занимает, но при этом работает вполсилы, а то и вовсе на четверть от требуемого. Обычно каждый руководитель ИБ обладает о своих сотрудниках такими сведениями и может планировать работу службы исходя из реалий, а не теории, но это не лучший вариант. Вот уйдет такой многостаночник и придется где-то искать ресурсы закрывать то, что он раньше делал в одиночку. Но это уже лирика.
Если вы хотите увидеть какие-то иные оценки временных затрат на обеспечение отдельных функций ИБ, то я могу порекомендовать интереснейший документ от Банка России, а именно РС 2.7 2015-го года по ресурсному обеспечению ИБ в финансовой организации. Он, правда, ориентирован еще на СТО БР ИББС, но ежегодные усилия для каждого процесса ИБ там расписаны достаточно детально. Согласно Банку России минимальный состав службы ИБ банка составляет 12 человек (при росте числа филиалов и отделений и число растет пропорционально). Там приводится более сложная формула расчета ресурсов, но суть у нее та же.
Если вы дочитали эту заметку до конца и решили, что я выложил на блюдечке рецепт выбивания ставок из начальства, то не обольщайтесь. Все зависит не от используемых формул и затрачиваемых вами усилий, а от того, умеете ли вы общаться с руководством "на равных" и доверяет ли оно вам.
В Фейсбуке моя краткая заметке привела к некоторой дискуссии, поэтому я решил написать чуть более развернуто. Но начну я с копипаста своей заметки, чтобы было понятно, о чем идет речь.
"Вот почему люди так пофигистически относятся к подготовке своих резюме? Они ищут работу и, вроде как, должны быть заинтересованы в том, чтобы поразить будущего работодателя своими умениями, навыками и знаниями. Но нет! Почему мало кто из ИБшников или ИБшных сейлов пишет о своих измеримых достижениях в резюме? Меня лично мало интересует, какой ВУЗ человек закончил 10-20-30 лет назад (а это ставят на первое место в резюме почти все - как будто все один плохой шаблон используют). А достижения интересуют. По ним оценивается специалист, а не по тому какому КОИБАСу его учили старперы по учебникам времен Петра Первого. С достижениями, кстати, тоже засада. Если они и есть, то никак не учитывают, кому резюме отправляется. Вот зачем в американской компании человек, который на первое место в своих достижениях выносит проекты по импортозамещению? 😉 Интересно, когда пишется ТЗ на систему по ИБ, оно же не универсальное (я надеюсь). Почему тогда резюме универсальное? Почему нельзя под каждого потенциального работодателя сделать свой вариант, "бьющий точно в цель"?"
Собственно, что я имел ввиду, когда говорил о достижениях? Ну вот, например, вместо указания продуктов, с которыми человек работал (а может не вместо, а вместе), можно было бы написать "внедрил IdM в масштабах предприятия на 1000 сотрудников". Вместо указания названия IRP-платформы, работе с которой можно научиться за пару дней на курсах вендора, а то и вовсе по роликам в YouTube, было бы классно увидеть что-то типа "выстроил процесс incident response, снизив время приема заявки с 17 минут до 3-х". А вместо "работал с заявками пользователей на доступ" горазо выгоднее бы смотрелось "написал средство автоматизации работы с заявками пользователей на доступ, сократив время предоставление доступа до 1 часа".
В ФБ Юлия Омельяненко справедливо пишет, что "умение делать работу и умение продать себя - две, не всегда связанных между собой навыка". С одной стороны я с не соглашусь. Это совсем разные навыки. С другой - если ты хочешь найти себе новую работу (а не просто "а почему бы и не попробовать закинуть резюме, вдруг прокатит"), то чуть напрячься и потратить время на осмысливание того, что ты делал/делаешь на работе и какую пользу ты принес, полезно. Представьте, что вы ищете сейла (специалиста по продажам) и он в резюме пишет, что он каждый день искал клиентов и продавал им какие-то продукты или услуги. Вас разве не заинтересует вопрос, а успешно ли он продавал? На какую сумму он продал на прошлом месте работы и насколько он перевыполнил план? Так и с ИБшником. Он тоже не просто "крутит гайки на файрволах" или выдает ключи электронной подписи - он улучшает состояние ИБ на предприятии.
Насколько улучшает? Как улучшает? К чему приводит его деятельность? "А меня не интересует, насколько безопаснее стало предприятие от моей работы. Я делаю свое дело. Я делаю то, что мне говорит начальство". Ну ОК. Ты классный чувак, наверное. Но на кой ты такой нужен, если тебе абсолютно пофигу, есть результат от твоей работы или нет? Я бы такого человека не только не взял на работу, но и гнал бы в шею поганой метлой, потому что такой пофигист не только не приносит пользы, но и заражает свои безразличием окружающих. Как правильно отметила в заметке Екатерина Калугина, большинство соискателей в резюме пишут, что делали (а это у многих схожих по роли специалистов очень похоже), а не что сделали.
Рустем Хайретдинов в ФБ написал "Специалист такой же продукт, как и софт, чтобы его продать, надо знать своего покупателя, его "боли", свои сильные и слабые стороны. Мне очевидно, что для разных компаний надо писать разные резюме, выбирать те свои "фичи", которые максимально выпячивают конкурентные преимущества на конкретной должности, выбрасывать второстепенные, не врать, но умалчивать недостатки. Писать резюме - несложная штука, научиться сильно проще, чем обращаться с PowerPoint" и я с ним согласен. Если ты веерно рассылаешь одинаковые резюме, то шансов найти что-то стоящее немного. С другой стороны, появляется шанс у тех, кто чуть напрягся и потратил время на изучение потенциального работодателя и подкрутку своего резюме под конкретную организацию. А если еще и сопроводительное письмо было написано, то вообще космос и шансов становится гораздо больше. Причем даже если такое резюме не прошло фильтр в виде HR, который смотрит только на знакомые слова или аббревиатуры, которые ему дали в ИБ (CISSP, OSCP, TIP, NGFW, ФСТЭК, SOC, SIEM и т.п.), то даже в этом случае есть смысл.
"А я вот аналитик первой линии SOC и просто работаю по плейбукам. Какие у меня могут быть достижения?" Логичный вопрос. Тоже самое может сказать человек, который настраивает МСЭ или генерит криптографические ключи или обрабатывает заявки на доступ или... Этих "или" может быть очень много. ИБ - не столь творческая профессия, как у художника, у которого каждая его картина уже достижение. И это не продажи, которые легко измерить по объему продаж, перевыполнению плана и другим показателям. И это не начальник, который может писать в резюме, что он управлял 10 сотрудниками или увеличил бюджет подразделения на 20% за пять лет (при ежегодной инфляции в 8%). Но!.. Как мне кажется, на любой должности в области ИБ надо не тупо выполнять то, что написано в плейбуке или инструкции, а думать прежде всего. Если вы тупо выполняете какие-то рутинные операции, то будьте уверены - вы первый кандидат на увольнение. Любая рутинно выполняемая операция рано или поздно будет автоматизирована - либо с помощью специализированных решений класса SOAR, либо с помощью технологий no code/low code, которые начинают проникать в ИБ, либо с помощью машинного обучения (как бы мы к нему не относились), либо с помощью технологий RPA (robot process automation). А если вернуться к работе аналитика, то у вас идеально выстроены процессы мониторинга и идеальные плейбуки, которые не надо улучшать? Мониторя инциденты, вы не замечали, что описанные процедуры неидеальны и могут быть улучшены? А новые правила корреляции вам не нужны? Вы предлагали улучшения? Да? Вы молодец! Это и пишите в "достижения". Не предлагали? Ну тогда повод задуматься.
О том, как писать резюме можно писать еще много, но я не ставил перед собой такую задачу. Главное, что я бы вынес из этой заметки - любая работа должна приносить результат, оцифрованную форму которого и нужно вносить в резюму. Разумеется, все это имеет смысл, если действительно человек не просто ходил на работу "с 9-ти до 6-ти" просиживать штаны, а реально что-то делал полезное для своей компании или хотя бы для своего подразделения. И, конечно, идея "пишите про свои достижения" должна быть принята во внимание, если вы действительно ищете работу (а то многих работа находит сама) и не рассылаете веером свое стандартное резюме "лишь бы куда-нибудь оно попало".
Ну а если вам интересно еще глубже погрузиться в тему строительства своей карьеры по ИБ, то есть несколько книжек на тему:
Вчера я наткнулся на модель угроз и нарушителя безопасности информации, обрабатываемой в программно-техническом комплексе дистанционного электронного голосования (ДЭГ). И хотя это всего лишь выписка, она все равно дает пищу для размышлений. В частности, беглый просмотр этого документа вызвал у меня следующие вопросы:
На очередном мероприятии, где я выступал с рассказом о стратегии борьбы с шифровальщиками, и поднял тему об оплате выкупа вымогателям, завязалась дискуссия, в которой я отстаивал точку зрения, что оплата выкупа - это бизнес-решение, а мои оппоненты, сплошь одни безопасники, защищали противоположную точку зрения, что платить вымогателям нельзя, тем самым мы стимулируем их на совершение еще больших преступлений. И поскольку такие дискуссии завязываются достаточно часто, я попробую сформулировать свои тезисы в виде заметки, чтобы потом просто давать всем ссылку :-)
ЗЫ. "А я буду настаивать, что платить выкуп ни в коем случае нельзя", - продолжаете стоять на своем вы. Но, стоя на своем, помните, что бизнес может задать встречный и вполне закономерный вопрос: "А как ИБ допустила, что шифровальщик натворил таких дел?". Поэтому стоять на своем может быть больно :-)
Несколько лет назад, а именно пять, я писал о том, как можно было бы облегчить жизнь с реализацией приказов ФСТЭК, внедрив неку/ю модель зрелости, которая бы позволила оценивать текущий уровень реализации требований регулятора и выстраивать некую дорожную карту достижения желаемого уровня соответствия. К сожалению, описанная мной тогда идея так и осталась идеей и, в отличие от NIST, который к своему фреймворку CSF предложил как раз схожую тему, наш регулятор, видимо по причине загруженности в условиях нехватки кадров, оставил этот вопрос в стороне. И вот на днях подумал я, что неплохо бы реализовать такую идею самостоятельно, что я и сделал. Итак, представляю калькулятор оценки технологической зрелости реализации приказа №239 ФСТЭК (для значимых объектов КИИ).
В итоге получилась вот такая табличка, где для каждого блока защитных мер были выделены 5 уровней зрелости, характеризующихся применением тех или иных технологий или тем или иным уровнем автоматизации. Например, на первом уровне блока ИАФ (идентификация и аутентификация) компания применяет обычные пароли для своих пользователей. Затем она переходит к многофакторной аутентификации, потом задумывается о Zero Trust или 802.1x начинает аутентифицировать не только пользователей, но и устройства. Потом компания созревает до доступа к своим активам внешних пользователей и начинает аутентифицировать их, а в финале, на пятом уровне зрелости, применяет федеративную систему аутентификации, применяемую в том числе и на внешних ресурсах - облаках и т.п.
Сложность возникла для такого, казалось бы простого, блока защитных мер, как обнаружение вторжений. Всего две меры защиты в нем и вроде бы не так все сложно, но... У ФСТЭК под понятием СОВ понимается вполне конкретный набор решений, который описывается их руководящими документами. Я же считаю, что обнаружение вторжений - это гораздо более широкий спектр технологий, которые не только делятся на уровни реализации - сетевые и хостовые, но и по используемым алгоритмам обнаружения, интеграции их в единый комплекс (XDR), а также применением в облачных средах.
Но и с обнаружением вторжений ситуация не столь сложна, как с аудитом безопасности, под которым приказ 239 понимает не только классический аудит, но и мониторинг ИБ, а также применение решений по анализу трафика, которому, на мой взгляд, место больше в обнаружении вторжении. Но такова уж карма термина "активный аудит", который в России известен уже давно и в него засовывают и обнаружение вторжений, и анализ защищенности. Но и с этим я тоже справился. В итоге получилась небольшая таблица, в которой достаточно всего лишь 20 раз выбрать нужный уровень вашей технологической зрелости, после чего будет отрисована радарная диаграмма, показывающая уровень зрелости по каждому из блоков защитных мер и насколько нам далеко до желаемого/рекомендуемого уровня. Кстати, о последнем. Я его выбирал опираясь на собственный опыт. При желании там можно поиграться с уровнем, к которому надо стремиться.
Вот такой вот легонький инструмент, который я выложил у себя в Телеграме.Вы думали, почему на конференциях по ИБ выступают Рустем Хайретдинов, Дима Мананников, Алексей Качалин, Антон Карпов, Дима Гадарь, Мона Архипова и другие достойные специалисты? Я не знаю, почему. Да и наверное неправильно додумывать за них об их причинах. Я хочу поделиться своим видением того, почему человек начинает выступать на конференциях. Будем считать это продолжением моего опуса об ИБ-блогерстве, написанном 5 лет назад. Многое из того, что было написано тогда, продолжает оставаться актуальным и в отношении спикеров ИБ-мероприятий, но отдельные моменты все-таки надо уточнить и прокомментировать. Тем более, что и повод на днях появился. 8 лет назад я уже пытался оформить свои причины участия в ИБ-мероприятиях, но за это время ситуация немного поменялась.
Итак, давайте посмотрим на мотивацию организатора мероприятия. Он, очевидно, заинтересован в том, чтобы заманить в свои ряды именитого, интересного или востребованного спикера, на которого пойдут участники, что позволит привлечь много денежных спонсоров и не только отбить, но и заработать на мероприятии (либо сразу, либо впоследствии). Для решения этой задачи в ход идут совершенно различные инструменты и подходы - давнее знакомство со спикером, запрос через друзей спикера, гонорар, запрос начальству, оплата перелета и проживания, предоставление доступа к материалам мероприятия, предоставление доступа к другим проектам организатора мероприятия и т.п. Кто-то считает, что выступить на их мероприятии - это уже само по себе ценно и поэтому спикеры должны быть рады самому факту их приглашения на мероприятие. Кстати, это местами действительно так. Если бы меня пригласили выступить на RSA Conference, то я мог бы считать это некоей вершиной (возможно, промежуточной) для себя, как для спикера.
Кто-то из организаторов заманивает к себе спикеров тем, что они повысят свою экспертность и смогут получать больше зарплату. Последнее, конечно, вызывает только улыбку. Если человек не эксперт, то никакое выступление его экспертность не повысит (разве что он получит еще один опыт выступления, что тоже полезно, но слушателям нужно не это). Если же он признанный эксперт, то участие в большинстве отечественных мероприятий по ИБ на его экспертности никак не скажется (разве что его пригласят выступать в Госдуме или для олигархов в Барвиха Luxury Village). Если человек - неопытный спикер, но он работает на стороне заказчика, то возможность ему поделиться опытом ценна само по себе (и тоже никак не влияет на экспертность). В любом случае, бартер "выступление за рост экспертности" - это демонстрация непонимания того, что нужно спикеру.
Попробую сформулировать причины, по которым спикер соглашается выступать на разных мероприятиях. Через многие из них я прошел за 30 лет в области ИБ, поэтому могу сказать, что они все имеют место быть (правда, на разных стадиях развития и известности спикера). Итак, я бы составил следующий перечень причин для выступлений:
Вот такой вот набор причин, почему спикер может сказать "Да" (или "Нет") участию в мероприятии по ИБ. Но если попробовать выразить все эти мотивы более коротко, то выступление - это время, которое помогает или не помогает спикеру достигать поставленных им самому себе целей (ну или его работодателем, но спонсорские выступления - это отдельная тема для обсуждения). Зная спикера, его мысли, его планы, его желания (а это отличает хорошего организатора мероприятий от временщика), можно предложить ему ровно то, что его заинтересует и что повысит шансы на его участие в мероприятии, от чего выиграют все - и спикер, и организатор, и аудитория. А в противном случае получается какая-то инфоцыганщина :-(