Средства моделирования угроз: обзор существующих решений

Как и обещал публикую заметку с обзором средств моделирования угроз. Сразу надо сказать, что все эти решения врядли имеют свою, вполне конкретную сферу применения. Какие-то применяются в процессе разработки ПО и для других задач неприменимы, какие-то являются внутренними решениями, какие-то ориентированы на отдельные отрасли или вертикали. Универсального решения, да еще и под требования наших регуляторов, пока нет.

Начну я обзор с уже упомянутого мной ранее решения ADTool, которое входит в состав обучающей платформы CybatiWorks. Расшифровывается ADTool как "Attack-Defense Tree Tool" и разработано в университете Люксембурга в рамках проекта ATREES по разработке инструментария по составлению дерева атак и защитных мер.

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

В 2006-м году стартовал проект Trike, который включает в себя разработку методологии и инструментария для моделирования угроз. Сама методика разрабатывалась еще в 2003-2005-м годах, но оформилась в открытый проект она чуть позже. Реализация Trike доступна в двух вариантах. Первый - обычная табличка в Excel (Mac тоже поддерживается), в которой куча вкладок и опросников, которые надо заполнить для формирования модели угроз.

К таблице прилагается подробная подсказка, ориентированная на разные целевые аудитории - разработчики, тестировщики, архитекторы и т.п. Вторым вариантом реализации является отдельное приложение, написанное на Smalltalk (авторы говорят, что так сложилось исторически). Чтобы запустить его нужно запустить предварительно виртуалку на базе Squeak. В целом, надо признать, что вариант достаточно специфичен; я использовал только первый - более привычные таблицы Excel.

Компания Microsoft является одной из широко рекламирующих свой подход к безопасной разработке компанией и немудрено, что у нее есть и инструмент для моделирования угроз в соответствие с их методикой, неплохой описанной в книге бывшего сотрудника Microsoft Адама Шостака. Прежняя версия этого решения называлась Threat Analysis & Modeling Tool,

а текущая - MS Threat Modeling Tool 2016.

Решение Microsoft бесплатно и ориентировано на разработчиков ПО. Оно может быть интегрировано с различными системами, используемыми при отслеживании багов и иных проблем в ПО, что делает этот продукт уникальным среди аналогичных доступных на рынке решений. В систему встроено некоторое количество шаблонов проблем в соответствие с моделью STRIDE (аббревиатура, созданная по первым буквам шести самых распространенных угроз для ПО, - spoofing identity, tampering of data, repudation, information disclosure, denial of service, elevation of privelege).

Также в MS Threat Modeling Tool встроена подсистема визуализации информационных потоков (Data Flow Diagrams) и системе генерации отчетов, делающих это решение очень удобным в использовании.

Аналогичный по сути инструмент есть и в компании Cisco. Называется он Cisco ThreatBuilder и предназначен для моделирования угроз в процессе разработки решений Cisco. В отличие от универсального продукта MS, решение от Cisco является сугубо внутренним и поэтому заточенным на решения Cisco. По своей функциональности оно схоже с решением от MS, но у него есть и ряд отличий.

В частности, в инструменте Cisco присутствует база данных угроз и методов их реализации, а также интеграция с известным проектом MITRE - CAPEC. Вторым очень полезным отличием от ранее описанных решений является встроенная пополняемая база защитных мер для каждой из имеющихся угроз, что позволяет оперативно перейти к их устранению. 

Еще одним схожим инструментом является проект канадских студентов SeaSponge, ставший победителем конкурса Mozilla в 2014-м году. Проект, ориентированный на разработчиков ПО, доступен на Github, а также в виде онлайн-версии инструмента. Из минусов могу отметить отсутствие предопределенных шаблонов угроз - все надо писать с нуля самостоятельно. Никаких библиотек угроз тоже в SeaSponge нет.

Еще одним, активно рекламируемым инструментом для моделирования угроз является ThreatModeler от MyAppSecurity. Он реализует принцип "визуализации диаграммы связей" (mind map), но с ориентацией на процесс идентификации угроз.

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

Кстати ThreatModeler - не единственный, кто придумал использовать идеи MindMap для моделирования угроз. Есть, например, проект ThreatMind, который пытается объединить угрозы и бесплатное решение по созданию диаграмм связей Freemind.

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

Зато продолжает здравствовать и развиваться другая отечественная компания - R-Vision, которая предлагает одноименную модульную систему обеспечения деятельности службы ИБ. Среди прочих есть у R-Vision и модуль "Риски" (Risk Manager), в рамках которого среди прочего есть и подсистема моделирования угроз для всех идентифицированных активов организации. Идентифицируются виды, источники и способы реализации угроз.

Но в чистом виде инструментом для моделирования угроз решение от R-Vision назвать нельзя - данная задача там одна из многих. Собственно как и во многих иных инструментах по моделированию рисков - CRAMM, PTA и т.п.

В качестве заключению хочу вновь повторить, что у каждого из описанного выше инструментов своя область применения и своя задача. Взять их и применить для моделирования угроз по методике ФСТЭК не получится. Однако облегчить жизнь разработчикам, консультантам или архитекторам они могут. А может быть они наведут на мысли о том, каким могло бы быть отечественное решение по моделированию угроз, о котором я писал в прошлой заметке, и которое бы получило "одобрямс" от регулятора.

Подробнее…

Петля Бойда и кибербезопасность

Если вернуться к заметке про неспособность цикла PDCA эффективно отражать мир информационной безопасности, то возникает закономерный вопрос, а что тогда делать? Есть ли какая-либо концепция, которая может помочь описать реальность, но не слишком глубоко; учесть изменчивость окружающего мира и конкурентную среду, в которой действую современные кибербезопасники? На самом деле есть, но перед ее описанием необходимо вспомнить три классические научные теоремы:

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

Именно эти три теории привели американского полковника авиации Джона Бойда к формулировании его концепции петли OODA (Observe - Orient - Decide - Act или Наблюдай - Ориентируйся - Решай - Действуй),  легшей в основу современной военной доктрины США (и не только) и используемой во многих иных сферах - торговли, бизнеса, спорта и т.п. Идея Бойда заключалась в том, что для того, чтобы военные операции (как и кибероперации) соответствовали реальности необходимо действовать в непрерывном цикле, постоянно взаимодействуя с окружающей средой и учитывая ее постоянные изменения. При этом преимущество в скорости своего цикла (очевидно, что противники будут действовать в рамках своих аналогичных циклов) действий и точности оценок обеспечивает  преимущество над противоборствующей стороной и ведет в конечном итоге к победе.

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

Попробуем чуть более детально рассмотреть элементы петли Бойда.

• Наблюдение (observation). Это процесс сбора информации, необходимой для принятия решения в данном конкретном случае. Информацию об угрозах, хакерах, инсайдерах, конкурентах и иных противоборствующих сторонах можно собирать из внешних и внутренних источников. От качества и скорости сбора этой информации зависит эффективность принимаемых нами решений. Иностранные компании, знакомые с концепцией Бойда, активно ее используют, преподнося свои решения по Threat Intelligence как очень важную, первую часть цикла OODA, на которой строится все остальное.
• Ориентация (orientation). Это самый важный этап петли Бойда, который в свою очередь разделяется на два подэтапа - разрешение (destruction) и созидание (creation). Разрушение подразумевает декомпозицию ситуации на более мелкие части, для каждой из которых существует свой сценарий или план действий. В области ИБ это могут быть различные руководства и инструкции или, как это сейчас модно стало называть, playbook. Например, у служб реагирования на инциденты или у операторов SOC такие playbook насчитывают до нескольких десятков различных ситуаций (инцидентов) с описанием конкретных шагов по их разрешению. На этапе созидания все эти небольшие планы объединяются в общий план действий, который и позволяет с успехом выйти из сложившейся ситуации. Разумеется, успех этого этапа зависит от того, насколько много у нас уже сформированных планов. Если их нет, то мы будем терять время в попытке разработать их во время конфликта или инцидента, что в итоге приведет к проигрышу.
• Решение (decision). На данном этапе мы принимаем решение о реализации плана, сформированного на предыдущем этапе (если план один), или выбираем из альтернатив лучшую по критерию, например, эффективность-стоимость или скорость-стоимость или скорость-надежность. Очевидно, что в области ИБ у нас скорее всего будут множественные альтернативы, из которых нам надо будет принять лучшую в конкретной ситуации.
• Действие (act). На финальном этапе мы просто реализуем выбранный план действий.

Если внимательно проанализировать идеи Бойда, то становится очевидно, что существуют всего два основных способа достижения победы в борьбе с киберпреступниками и иными нарушителями - очевидный и не очень. Очевидный - это сделать свои циклы действий более быстрыми или улучшить качество принимаемых решений. Первый вариант позволит вам действовать на опрежение и вынудит именно вашего противника реагировать на ваши действия, а не наоборот, как часто происходит в ИБ. Например, вы можете регулярно перестраивать систему защиты, проводить постоянно учения “красно-синих”, менять настройки средств защиты, менять адресацию, менять банеры у сетевых и прикладных сервисов и т.п. Второй и менее очевидный путь позволят вам принимать решения, лучше соответствующие текущей ситуации, чем решения вашего визави. Хорошо просчитанные решения могут привести к более предпочтительным результатам, нежели быстрые, но неадекватные действия противника. Это можно сделать либо улучшая свои решения (например, путем проведения киберучений в своей компании или внедряя систему автоматизации рутинных действий или систему корреляции событий безопасности), либо ухудшая решения противника (например, внедряя в компании принцип “security through obscurity” и не давая злоумышленникам информации о внутренностях атакуемой системы).

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

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

Возьмем к примеру задачу мониторинга атак и подозрительных действий на уровне сети. В случае с PDCA мы сначала должны спланировать, что мы ищем (создать правила или включить нужные сигнатуры в системе обнаружения вторжений). Затем мы запускаем систему в промышленную эксплуатацию и смотрим - что она ловит, а что нет. Это второй и третий этапы PDCA. Четвертый этап заключается в тюнинге системы обнаружения с учетом полученной информации. И так по кругу, в надежде, что мы достигнем просветления и наш сенсор IDS будет ловить все, что он должен в конкретной точке сети. Если за основу взять цикл Бойда, то работа IDS будет выглядеть иначе. Сначала мы собираем данные из нашего окружения (Netflow, логи, события ИБ и т.п.) - это этап наблюдения. Затем мы проводим анализ и корреляцию событий, поиск аномалий, обнаружение несанкционированных действий. Это этап ориентации. На третьем этапе мы принимаем решение о том, будем ли мы блокировать атаку сами или изменим ACL сетевого оборудования или заморозив учетную запись пользователя, участвующего в атаке. И на финальном этапе приводим выбранную стратегию в действие. При этом на каждом из этопов мы обеспечиваем обратную связь. Например, на этапе принятия решения по конкретному событию мы можем получить дополнительную информацию о его окружении и, например, не заблокировать атаку, а дать ей развиться и направить ее на обманную систему. А другую такую же атаку, получив “вводную” от сканера безопасности, мы можем купировать, не дожидаясь ее развития. И все это опираясь на непрерывно получаемую информацию о состоянии внешней среды. Другой пример. Реализовав какую-либо реакцию на атаку мы делимся этой информацией, используя ее на следующем витке петли Бойда.

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

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

Подробнее…

Обязательная сертификация средств защиты ПДн не обязательна (ответ ФСТЭК)

Кто следит за темой персональных данных, тот помнит, что я давно придерживаюсь позиции о том, что средства защиты персональных данных не обязательно должны иметь сертификат ФСТЭК. Я исхожу из банальной логики - в законе "О персональных данных" ни слова не говорится о сертификации, как единственно возможной форме оценке соответствия средств защиты персональных данных. И ПП-1119 про это не говорит. А закон "О техническом регулировании", который и регулирует вопросы оценки соответствия, также ни слова не говорит о том, что средства защиты ПДн должны быть сертифицированы. Он говорит немного о другом - устанавливает семь форм оценки соответствия и указывает, что особенности этой самой оценки для средств защиты информации устанавливают Президент или Правительство, но никак не регуляторы. Опираясь на эту логику я утверждал и утверждаю, что средства защиты персональных данных, исключая государственные и муниципальные ИС, могут пройти любую из существующих форм оценки соответствия, а не только обязательную сертификацию по линии ФСТЭК или ФСБ.

Однако такую позицию не разделяют отечественные производители средств защиты информации и многие интеграторы, считающие, что оценка соответствия и обязательная сертификация - это суть одно и тоже. Понять их можно. Местами они просто не разбираются в законодательстве, считая слова регулятора истиной в последней инстанции (даже если эти слова противоречат законодательству). Местами они просто не хотят спорить с регулятором или писать обоснования для своих заказчиков. Что может быть проще, чем сказать, что оценка соответствия может быть только в форме сертификации? По счастливой случайности эти же интеграторы и производители и продают сертифицированные средства защиты информации.

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

Эта же мысль прописана и в 21-м приказе ФСТЭК, но не так явно, что и вызывало большое количество вопросов. Теперь ФСТЭК достаточно четко и явно ответила, что форма оценки соответствия средств защиты ПДн может быть любой, если это не ГИС/МИС, для которых оценка соответствия может быть только в форме обязательной сертификации. Для всех остальных форму оценку соответствия можно выбрать самостоятельно и она может быть и сертификацией. В этом случае надо руководствоваться 12-м пунктом 21-го приказа, который описывает классы защиты и защищенности СрЗИ персональных данных. Все предельно лаконично и логично. На мой взгляд, этот ответ ставит точку в долгих спорах о необходимости сертификации средств защиты ПДн для коммерческих операторов ПДн, которые могут самостоятельно определять форму оценки соответствия, упомянутую в ФЗ-152.

ЗЫ. Я не против сертификации как таковой, но у меня всегда были претензии к тому, как это производилось в России. Сейчас ситуация меняется, но пока не быстро.

ЗЫ. На вопрос о том, могу ли я поделиться всем ответом регулятора отвечаю - нет, не могу. Во-первых, этот ответ предназначен не мне и не мне им делиться. А во-вторых, это ответ конкретному лицу на конкретный вопрос. Использовать этот ответ как универсальный и юридический документ все равно не получится.

Подробнее…

Сказ о том, почему цикл PDCA плохо работает в ИБ

В области информационной безопасности, как и во многих других, существует две большие проблемы - фактор времени и нежелание критически рассуждать о якобы аксиомах или догмах безопасности, которые с течением времени претерпевают изменения, в том числе и очень серьезные. Одна из священных коров - ISO 27001, а точнее цикл PDCA, на идеологии которого ISO 27001 и был выстроен.

PDCA является аббревиатурой цикла Plan-Do-Check-Act (Планируй-Делай-Проверяй-Улучшай) и впервые эта концепция была озвучена Шухартом и Демингом в рамках идеи повышения качества на производстве в Японии. Потом на ее базе стали выстраивать процессы и в других областях, в том числе и информационной безопасности, разумно полагая, что если этот цикл позволяет улучшить качество производства, то почему бы с его помощью не улучшить качество управления ИБ. Однако, если отбросить в сторону постоянно ведущиеся споры на тему “Зачем мне ISO 27001?”, то гораздо более интересен вопрос самой применимости цикла PDCA в области современной ИБ (обратите внимание на ключевое слово “современной”).

Какие отличительные особенности ИБ можно назвать? Во-первых, это ее нелинейность. Это в теории красиво выглядит - “21 шаг построения ИБ на предприятии”, “Горячая десятка ИБ-процессов”, “Поэтапное внедрение системы управления ИБ в компании” и т.п. Реальность, она иная. Либо регулярно появляющиеся новые вводные, либо новые угрозы, заставляющие менять подходы к ИБ, либо вовсе хаотическое развитие, неподчиняющееся упрощенному и выхолощенному лозунгу “Планируй-Делай-Проверяй-Улучшай” (кстати, меня всегда удивляло, почему Act переводят как “улучшай” и чем Act отличается от Do?). Это если не рассматривать и вовсе новомодные штучки типа Agile, которые прямо конфликтуют по своей идеологии с размеренным и долгоиграющим PDCA и ISO 27001 на его основе. Кстати, ряд экспертов, стоящих у истоков ISO 27001, прямо говорят, что текущий цикл обновления стандарта - это зло; он не учитывает изменений, происходящих в отрасли, что негативно сказывается на эффективности процесса управления ИБ на предприятиях.

Во-вторых, безопасность в отличие от системы качества требует учета “интересов” злоумышленников, которые могут разбить все благие намерения по линейному циклу обеспечения управления ИБ. Более того, система повышения качества вообще не предполагает конкурентной среды, которая есть в информационной безопасности и без которой она немыслима. Вас ударили туда, где вы вообще забыли провести анализ рисков. Или вы запланировали внедрение повышения осведомленности персонала только через 2 года (а раньше денег не дают), а основной вектор для злоумышленников именно в вашей компании - это и есть нерасторопность и невнимательность пользователей. Вы срочно меняете свои планы и внедряете систему обучения персонала, а злоумышленики уже переориентировались и бьют по вашим контрагентам. Как тут помогает линейный и последовательный PDCA? Никак.

В контексте отсутствия учета внешних конкурирующих сил никак не помогает и любая другая цикличная модель, используемая в ИТ. Например, тот же COBIT, который в предыдущей, 4-й версии использовал тот же PDCA, а в новой, пятой версии перешел на семишаговый цикл. Но и он не учитывает воздействия неотъемлемых для ИБ сил напрочь отсутствующих в ИТ. В модели ITIL ровно тоже самое - цикл PDCA во всей красе.

В-третьих, вы не можете все время совершенствоваться. Непрерывное совершенствование подразумевает непрерывное изменение, которое само по себе является проблемой. Тут и путаница с текущим состоянием процессов и процедур (если они постоянно совершенствуются, то что является “текущим” и “желаемым” состоянием и как отслеживать динамику улучшений), и следование  устаревшим практикам, которые изменяются не так оперативно как процессы, и “усталость” персонала, который психологически не может жить в процессе постоянного изменения - они начинают путаться, совершать ошибки, скрывать недочеты и, в итоге, разочаровываться в идее повышения качества и терять мотивацию. В новых версиях стандартов, построенных на базе PDCA, этот момент учтен, но все ли активно пересматривают и свои взгляды (или живут в соответствии с полученными много лет назад знаниями)?

Кстати, первоначальная концепция PDCA была ориентирована на дополнительные улучшения уже существующих процессов, а не на перестройку всего процесса производства или построение его с нуля; да еще и в сложно организованной компании. Ведь понемногу улучшать существующее гораздо проще, чем строить все с основ. У нас же ISO 27001 рассматривается именно как стратегия построения или перестроения службы ИБ с самого начала и внедрения процессов ИБ по всему предприятию. Я нередко слышу от вновь пришедших на новое место работы коллег, что они будут внедрять там ISO 27001 (без сертификации пока). А все почему? Потому что это “стандарт де-факто”, который не принято критически оценивать. Отсюда и не очень высокое число успешных внедрений ISO 27001 и еще меньшее число повторных сертификаций. Многие эксперты отмечают, что ISO 27001 давно уже превратился из стандарта по безопасности в продукт зарабатывания денег для аудиторов и разработчиков новых реинкарнаций ISO 27001 для разных вертикалей и применений - финансов, операторов связи, промышленных предприятий и т.п.

Но ведь PDCA работает! В Японии он сильно помог поднять качество производства. Да! В Японии! 50 лет назад! Вы обращали внимание, где больше всего компаний, сертифицированных по ISO 27001? Не знаю, как сейчас, но еще несколько лет назад, когда эта тема в России была модной, я анализировал страны, в которых сертификация на соответствие ISO 27001 имела хождение. Оказалось, что чуть ли не 80% всех сертификатов выдано японским компаниям. Оно и понятно, в стране, где идея PDCA и родилась и культивировалась, грех было бы увидеть иные цифры. Но в мире картина внедрения ISO 27001 с его концепцией PDCA оказалась совсем иной. На нее очень сильно влияют культурные различия Востока и Запада.

Я в свое время изучал “историю” PDCA и оказалось, что то, к чему мы так привыкли, говоря про PDCA, немного отличается от того, что Шухарт реально делал в Японии 50 лет назад. В реальной жизни процессы, процедуры и мероприятия для улучшения качества были намного детальнее и обширнее, чем выхолощенная абстракция, заключенная в 4-х символах аббревиатуры PDCA, разработанной специально для Запада. На действующих производствах фаз повышения качества было гораздо больше четырех и разрабатывались они специально для Японии и ее культуры. Однако в мир ушла именно упрощенная модель (возможно именно потому, что она была упрощенной и более понятной), потянувшая за собой ворох проблем с ее интерпретацией. И чем больше людей было в цепочке интерпретаторов, тем дальше от исходной концепции уходила реализация. Кроме того, в исходной версии подхода Шухарта и Деминга предполагалось, что за улучшение качества будут отвечать выделенные сотрудники, эксперты, погруженные в тематику. Сегодня, в условиях когда требуется активное вовлечение и рядовых сотрудников в обеспечение ИБ, требовать от них понимания всех ИБ-концепций не приходится. В итоге они начинают очень вольно трактовать достаточно конкретные положения PDCA или того же ISO 27001 (интерпретации и трактовка - это один из бичей стандартизации вообще и ИБ в частности). Кстати, даже сами японцы за 50 лет существования концепции PDCA изменились. Об этом стоит помнить. Люди! Вот те, о ком мало говорится в цикле PDCA, но от кого зависит успех (или неуспех) его внедрения на предприятии. Почему различные японские модели (то же “бережливое производство”) так плохо внедряются за пределами Японии? Почему продукция из одинаковых запчастей, собранная на одинаковых конвейерах в России и Германии, отличается? Потому что люди разные и их восприятие и принятие процессов тоже разные. Пару лет назад в Высшей школе экономики я делал презентацию “Русская ментальность как фактор невозможности адекватного управления ИБ на базе западных практик”, которая вызвала достаточно живую (мягко сказано) дискуссию, которая, на мой взгляд, показала, что в России действительно не так просто внедрять западные (да и восточные) методики управления ИБ, родившиеся в совершенно иной исторической и культурологической среде. С PDCA ситуация такая же.

PDCA не говорит вам как решать те или иные ИБ-проблемы. Это речевка, лозунг из советских времен. Их восприятие зависит от многих условий и для эффективной реализации требует гораздо большей детализации, чем просто 4 шага. При этом большая часть усилий должно тратиться на самом первом этапе планирования, но как можно все, что нужно делать в ИБ, вместить в упрощенный донельзя один шаг “Plan”? Не случайно, видя проблемы с PDCA в области улучшения качества, на свет появились лучше детализированные и проработанные концепции DMAIC (Define - Measure - Analyze - Improve - Control) или “Шесть сигм”. Тот же COBIT в итоге отказался PDCA в сторону семишагового цикла.

С планированием вообще не все так просто. Термин “Plan” сильно зажимает вас в прокрустово ложе линейных и пошаговых моделей. Вы ограничены в выборе творческих путей формирования тех или иных решений в области ИБ. Как мне кажется, время прямолинейных решений в ИБ проходит. Не случайно сейчас активно развивается тема геймификации в ИБ. И, кстати. Всегда ли вы действуете на основании плана? Мне можно возразить, что всегда прежде чем что-то сделать, надо подумать, спланировать и потом уже действовать. В теории да, а на практике? Часто ли вы действуете спонтанно или вне плана? И насколько вас устраивают результаты? Улучшение возможно и без плана, а в современных условиях, когда злоумышленники действуют творчески, так же творчески должны действовать и специалисты по ИБ (в том числе творческий подход очень важен при отсутствии бюджета). А творчество и инновации с одной стороны и систематическое планирование с другой - вещи плохо совместимые.

Значит ли все вышенаписанное, что PDCA - это ненужная и неработающая концепция? Конечно, нет. PDCA может задать основу для построения службы и процессов ИБ, но он не является инструментом, которым можно пользоваться изо дня в день, особенно в “конкурентной” среде, коей является информационная безопасность. Помимо PDCA можно обратить внимание и на другие методы - DMAIC, IDEAL, ТРИЗ, TBBDI, EBBDI, из которых можно извлечь что-нибудь полезное. А вообще, не надо быть догматиком. Ключевой идеей, закладываемой в ISO 27001 в свое время, было создание на базе передового опыта базового уровня в области ИБ. Однако за 20 с лишним лет первоначальная идея была извращена и современный ISO 27001 - это неповоротливая конструкция, ориентированная на соответствие (галочный подход), от которого страдает реальная безопасность предприятия. И положенный в основу ISO 27001 цикл PDCA явно не помог эту конструкцию сделать более гибкой и адаптивной. Концепция PDCA в принципе не учитывает, что процессу улучшения ИБ могут мешать хакеры и регуляторы с генерируемыми ими динамическими изменениями, влияющими на обеспечение ИБ. Отсюда и сложности с ее применением, о которых надо просто знать и помнить.

Подробнее…

Почему лицензирование технологий - это не всегда хорошо с точки зрения ИБ

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

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

Возьмем уже старый, но близкий мне пример. Компания Cisco лицензировала у компании netForensics одноименную систему управления событиями безопасности, которую затем стала предлагать под новым именем Cisco SIMS (Security Information Management System). Мы ее некоторое время успешно продавали через свой канал продаж, но потом столкнулись с тем, что у компании netForensics сильно ухудшилась внутренняя ситуация - качество продукта снизилось, поддержка стала работать из рук вон плохо, число нареканий от заказчиков стало возрастать. А повлиять на чужой продукт мы были не в состоянии. Итог закономерен - мы прекратили сотрудничество с netForensics (с 2012-го года они переименовались в BlackStratus), а Cisco SIMS исчез из нашего прайс-листа. И для нас и для заказчиков риски были минимизированы, но ситуация все равно неприятная.

Другой пример - тоже с нами. В свое время мы лицензировали у компании Opsware систему Network Compliance Manager, этакий автоматизированный аудитор сети, который сканировал сетевое оборудование и средства защиты в поисках несоответствующих требованиям внутренних политик и внешних стандартов конфигураций. Продукт некоторое время существовал в нашем прайс-листе, но после покупки Opsware компанией HP мы вынуждены были свернуть сотрудничество. Эти риски тоже были минимизированы, так как у нас еще до заключения договоров по лицензированию технологий прорабатываются вопросы, как мы и наши заказчики будем из этих договоров выходить с минимальными потерями.

А теперь обратимся к отечественному рынку ИБ и посмотрим на сотрудничество “Код безопасности” с компанией Agnitum, которая лицензировала свои технологии и разрешила “Коду безопасности” встроить свой движок по борьбе с вредоносным кодом в Secret Net Studio. А потом компания Agnitum была куплена Яндексом, который не пожелал (и это его право) продолжать ранее заключенные договора лицензирования технологий Agnitum. Итог - “Код безопасности” потерял часть своего функционала и вынужден был в спешном режиме искать альтернативу, с которой все непросто. Антивирусный движок остался только один - зарубежный Nod32 от ESET, который не будет сертифицироваться в ФСБ и по высоким классам ФСТЭК. Модуль HIPS оказался потерян полностью и сейчас "Код безопасности" пытается написать его самостоятельно (что делать текущим пользователям - не совсем понятно).

Ситуация с “Кодом безопасности”, Agnutum и Яндекс не уникальна для российского рынка. Сейчас многие российские компании идут по пути лицензирования чужих (и не всегда российских) технологий. Кто-то WAF лицензирует, кто-то SIEM (например, OSSIM или ArcSight), кто-то антивирус (тот же Nod32), кто-то анализатор кода (например, Fortify), кто-то системы контроля доступа (какой-нибудь SSH Security Communications), кто-то системы управления идентификацией (например, Identity Manager). И дело тут не в отсутствии компетенций по разработке аналогичных решений. Просто в условиях, когда страна декларирует курс на импортозапрещение, зарабатывать на западных решениях становится сложнее, а ниша, в которую могут потечь денежные потоки, не уменьшается. Логично что у ряда разработчиков возникает идея по-быстренькому сваять “российский” продукт на базе уже имеющихся технологий (западных или отечественных). Я уже как-то писал про то, что это не совсем импортозамещение, но сейчас мне хотелось рассмотреть эту проблему под другим углом зрения.

Что будет, если разработчик приобретаемой технологии “загнется” или будет куплен более крупным игроком, который не захочет развивать это направление своей деятельности? Что будет делать производитель, использующий чужие технологии? А что будет делать потребитель? Вот возьмем, к примеру, Attack Killer от Infowatch. Продукт, который базируется на решениях четырех разных компаний - Infowatch Appercut, Infowatch Targeted Attack Detector (решение от Cezurity), Wallarm WAF и Qrator AntiDDoS. Когда в Интернет утек черновик этой статьи, Рустем Хайретдинов накидал мне еще фактов про Attack Killer, поэтому просто процитирую его: "На самом деле всё гораздо хуже - внутри Апперката есть SQLite, а внутри Валларма - ngnix. InfoWatch Traffic Monitor содержит десятки лицензируемых компонентов - СУБД Oracle или PostgreSQL на выбор, голосовые перехватчики от ЦРТ, OCR от ABBY, а скоро ещё и КППС, и т.п. Апперкату ещё сложнее - он пишется на Java, который принадлежит Oracle, который грозится запретить его лицензирование." Допустим, Wallarm, активно смотрящий на Запад, будет там куплен каким-нибудь IBM, Dell или Cisco, не имеющих в своем портфолио Web Application Firewall. Или Oracle все-таки запретит лицензирование Java Как это скажется на Attack Killer? Рустем пишет, что этот риск проработан на уровне договоров и там где это возможно, существуют резервные/дублирующие технологии. Тот же Oracle может быть заменен на PostgreSQL. В любом случае это тот риск, который стоит рассматривать до приобретения решения, а не после.

Но это не единственный риск лицензируемых технологий. Другой вопрос заключается в устранении уязвимостей в них. Тут впору вспомнить историю с уязвимостью Heartbleed в библиотеке OpenSSL, на базе которой построено немалое количество продуктов в мире, включая и российские. Среди них были и сертифицированные по требованиям ФСТЭК решения. И когда ФСТЭК обратилась к их разработчикам с просьбой сообщить об устранении серьезной дыры в сертифицированных решениях часть разработчиков ответила, что не имеет возможности Heartbleed устранить, так как у них нет компетенций в этой области, а код чужой и копаться в нем они тоже не умеют. История умалчивает, что стало с сертификатами на эти решения, но умалять от этого проблему не стоит. Если продавец не может устранить уязвимость в применяемых чужих open source компонентах (OpenSSL, Kibana, Elasticsearch, Hadoop, OSSIM, Snort и т.п.), то как это скажется на безопасности потребителя? Это второй из возможных рисков, о котором стоит, как минимум, помнить.

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

Подробнее…

Кому ты будешь нужен через 5 лет? А через 10?

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

Кому мы будем нужны через 5 лет? Вот так, немного и немало. По-философски. Но не в контексте семьи или страны, а в контексте профессии. Будем ли мы востребованы через 5 лет в качестве специалистов по безопасности? "Мы", в данном случае, это мое поколение, хотя вопрос, наверное, будет применим к специалисту любого возраста.

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

Я регулярно получаю вопросы от будущих выпускников ВУЗов или аспирантов - о чем им писать диплом или диссертацию? И я понимаю, что мне им особо нечем помочь. То, что модно и на слуху сейчас, завтра перестанет быть актуальным. Если сейчас начать чем-то заниматься (не для галочки), то к окончанию работы тема уже может стать ненужной или, как минимум, не столь актуальной.

Тоже самое и с учебой. Учиться на кого-то, потому что это нужно сейчас, бессмысленно. Завтра это уже будет неактуально. Возьмем, к примеру, такую моднейшую профессию, как аналитики данных. Сейчас эти люди получают большие зарплаты и ежегодный дефицит в них оценивается в несколько сотен тысяч человек. Но к 2025-му году предсказывают, что их заменят системы искусственного интеллекта. Поэтому даже если сейчас пойти в ВУЗ и потратить пять лет на погружение в тему, к окончанию обучения, останется всего 4 года на извлечение прибыли из своих знаний. А потом все - в утиль или на повышение квалификации.

Сегодня очень модный термин - это Agile, который сложно перевести на русский язык одним словом. Быстротечность... Изменчивость... Он хорошо отражает те проблемы, которые возникнуть у специалистов по ИБ в скором времени. Все будет меняться очень быстро (если не рассматривать вариант, когда Россия пойдет по пути Северной Кореи или самоизоляции). И почивать на лаврах или базироваться на своих знаниях, полученных в ВУЗе уже не удастся. Хотя никто, наверное, никогда на этих знаниях и не строил свой профессиональный путь - уровень вузовского образования по ИБ сегодня очень низкий. Но и полученные пять лет назад или год назад знания уже тоже устарели. Я про это уже писал неоднократно, объясняя, почему у нас такое закостенелое законодательство по ИБ. Но ведь каждый из нас может превратиться в такого же закостенелого безопасника, который не видит и не хочет видеть ничего нового, сидя на багаже своих старых знаний и заслуг.

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

Когда я был на RSA Conference, меня приятно удивил Ади Шамир, человек-легенда в области криптографии и информационной безопасности. Один из авторов алгоритма RSA (буква S как раз от его фамилии), лауреат премии Тьюринга (аналог нобелевки для математиков). Он достиг всего, что можно в профессии. Но несмотря на это, он продолжает учиться - ходит на доклады, внимательно слушает, ничем не выделяется, стоит в очереди как все, не требует особого отношения к себе. Да и в общении приятный человек. Ты понимаешь, что человек востребован и хочет быть востребован дальше.

Ади Шамир

К чему такая философская заметка? Не потому что мне надо было чем-то занять руки во время ожидания рейса на Москву :-) Просто это тот вопрос (который вынесен в заголовок), я регулярно задаю сам себе :-) И не всегда сам имею ответ на него. Вот выпустишь какую-нибудь "вентиляторную" заметку и радуешься - попал в тему, народ ее обсуждает, дисскутирует, значит не зря. А бывает опубликуешь что-нибудь очень, на мой взгляд, интересное, а народ безмолствует и начинаешь задумываться, блин, не попал, пора на покой...

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

ЗЫ. Какая-то философия получилась... Видимо старею... Или вино действует :-)

Подробнее…

Немного изменений законодательства по ИБ за последнее время

За последнее время произошло несколько изменений на нормотворческой ниве, которые я решил свести воедино:

• Законопроект, о котором я писал, и который вносил правки в ФЗ-152, наделяя РКН правом выпускать документы по порядку проведения надзора и контроля, удалили с сайта regulations.gov.ru. От слова совсем! Так до сих пор законность деятельности РКН по надзору в сфере ПДн и висит в воздухе - оснований для проведения проверок у них как не было, так и нет.
• Законопроект, о котором говорилось на конференции ФСТЭК и который, за счет изменений ст.16 ФЗ-149, расширяет сферу действия требований ФСТЭК не только на ГИС, но и на остальные информационные системы, обрабатывающие информацию, обладателями которой являются госорганы и госкорпорации (например, Ростех, Росатом или Роскосмос). Помимо этого, данный законопроект устанавливает обязательное требование информировать ФСТЭК и ФСБ об инцидентах в госорганах и госкорпорациях. Это будет третий случай в российской истории, когда на законодательном уровне устанавливается необходимость сообщать об инцидентах ИБ (после требований ЦБ в рамках НПС и требований для объектов ТЭК).
• Банк России ввел в действие с 1-го мая 2016 года новые рекомендации по стандартизации, посвященные выявлению и предотвращению утечек информации (РС 2.9).
• Банк России начал процедуру рассмотрения новых рекомендаций по стандартизации "Квалификационные требования к специалистам по информационной безопасности организаций кредитно-финансовой сферы Российской Федерации". Интересно, что в первоначальном плане работ ТК122 этого документа не было. Как и документа "Обеспечение длительного архивного хранения электронных юридически значимых документов с сохранением свойств аутентичности, целостности, достоверности, пригодности для использования и юридической значимости", проект которого тоже уже подготовлен.
• Нашумевший законопроект Яровой о хранении всех данных по всем пользователям на территории России в течение 3-х лет. Понятно, что законопроект разработан для борьбы с терроризмом (а с чем же еще?). Понятно, что депутаты мало понимают в предмете регулирования. Посмотрим, что будет принято в финале.
• ФСБ приказом №182 (в Консультант+) утвердила Административный регламент по лицензионному контролю тех, кто разрабатывает, производит и распространяет шифровальные средства.
• PCI Council принял все-таки новый PCI DSS 3.2. Изменения не то, чтобы значительные, но судя по ним можно сделать вывод, что 4-й версии PCI DSS ждать раньше 2018-го года уже не придется.

Вот как-то так...

Подробнее…

Презентация с мастер-класса по моделированию угроз

Выкладываю свою презентацию с мастер-класса по моделированию угроз с форума директоров по ИБ.

Мастер-класс по моделированию угроз from Aleksey Lukatskiy

Подробнее…

Ответ ФСТЭК стартапу по ИБ в части лицензирования деятельности по ТЗКИ

Упомянутый позавчера стартап по ИБ направлял вопросы не только в Минкомсвязь, но и в ФСТЭК России. И вот на днях был получен оттуда ответ, который, на мой взгляд, гораздо более адекватный и взвешенный, чем у ИТ-регулятора. Это не отписка, а ответ по существу.

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

Следующий вопрос был связан с тем, что облачный провайдер привлекает для ряда работ внешних подрядчиков, которым передаются ПДн для обработки или хранения. Стартап спрашивал - нужна ли привлекаемой организации лицензия ФСТЭК на ТЗКИ. Нужна!

Ни действующие, ни новые требования к лицензиатам ФСТЭК, не будут дифференцированными и учитывать масштаб бизнеса лицензиата. Что стартап с двумя сотрудниками, что интегратор с 2-мя тысячами сотрудников - требования едины. Не очень позитивная новость для стартапов, относящихся к малым или микро-предприятиям.

Но зато не требуется контрольно-измерительное оборудования :-)

Еще одна засада для стартапа - место осуществления лицензируемых видов деятельности. На квартире или в собственном доме это не допускается.

Последний вопрос касался возможности использования open source решений при создании облачного сервиса по ИБ, который планировалось затем сертифицировать/аттестовывать. Тут ФСТЭК похоже с этим еще не сталкивалась, судя по тому, что они говорят о наличии договора (если только GNU License рассматривать как оферту), гарантиях качества, наличия консультаций и техподдержки.

Вот такой ответ от ФСТЭК. Четко, по делу, но не всегда позитивно :-( Но таковы уж реалии нашего рынка. Посторонних в ИБ становится все меньше и меньше, ибо национальная безопасность под угрозой. Скоро введут новые требования к ИБ-аудиторам и пентестерам и жизнь станет совсем веселой...

Подробнее…

Ответ ФСБ по поводу необходимости применения сертифицированных СКЗИ для защиты ПДн

Чуть меньше года назад я уже публиковал свою презентацию с рассмотрением вопроса о необходимости применения сертифицированных СКЗИ при защите ПДн. И вот на днях мне переслали ответ 8-го Центра ФСБ по данному вопросу. Самое важное в этом ответе находится в первом абзаце - СКЗИ не являются обязательными.

В следующем абзаце говорится о том, что определение актуальных угроз осуществляется оператором ПДн (и никем иным). В последующих абзацах повторяется классическая фраза 8-го Центра, что СКЗИ надо применять, если определенные угрозы могут быть нейтрализованы только СКЗИ. К таким угрозам 8-й Центр относит только две ситуации:

Я по-прежнему придерживаюсь позиции, отраженной в презентации, - информацию в каналах связи можно защитить различными способами, а не только СКЗИ, что вытекает из 19-й статьи ФЗ-152.

Ну и по поводу сертификации - в ответе 8-го Центра нет ни слова про сертифицированные СКЗИ. От слова "вообще".

Вот как-то так...

Подробнее…

Ответ Минкомсвязи про требование сертификата ФСТЭК на средства защиты при включении в реестр отечественного ПО

Пока идет форум директоров по ИБ я решил не публиковать запланированную заметку с обзором средств моделирования угроз; опубликую что-нибудь попроще. Это будет ответ Минкомсвязи, полученный одним из стартапов по ИБ, с которым я познакомился на тусовке ФРИИ, на вопрос о необходимости получения сертификата ФСТЭК на решения по защите конфиденциальной информации для включения продукта в реестр отечественного ПО.

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

Несмотря на требования наличия сертификата ФСТЭК на средство защиты, в письме говорится, что заказчики сами должны устанавливать требования по защите информации, в том числе и самостоятельно выбирать, будут они применять сертифицированные средства защиты или нет. Кто знаком с нормативной базой в области защиты информации, тот прекрасно знает, что никакой самостоятельности у государственных и муниципальных заказчиков нет - средство защиты обязано иметь сертификат ФСТЭК. Это написано в ФЗ-149, это же написано и в 17-м приказе ФСТЭК. Но Минкомсвязь, видимо, не знакомо с этими нормами и посему оно выпускает абсолютно безграмотное разъяснение за подписью министра.

При этом эксперты Экспертного совета защищают свою позицию тем, что "для попадания в реестр важно соблюдение критериев “отечественности”, а не наличие лицензий внутренних контролирующих органов" (имеется ввиду все-таки сертификат, а не лицензия) и "Сертификация не имеет прямого отношения к определению происхождения софта. Она занимает значительное время и требует существенных затрат. Эти факторы не должны затруднять работу экспертного совета и процедуру формирования Реестра". Я прекрасно понимаю чем это обусловлено (и все понимают), но так откровенно забивать болт на требования Постановления Правительства?.. Хотя бы внести изменения в его текст, чтобы придать всей этой конструкции хоть какую-то легитимность...

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

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

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

Подробнее…

Средства моделирования угроз: обзор возможностей

В последнее время мне часто задают вопросы о том, когда ФСТЭК выпустит обещанную методику моделирования угроз? Я уже устал отвечать "вот-вот" и "скоро". Могу предположить, что проблема в сложности получающегося документа. При достаточно большом числе потенциальных угроз, которые могут быть признаны актуальными на предприятии, процедура их определения становится достаточно сложной и не всеми подъемной. Упрощать документ - значит сознательно идти на потенциальное снижение защищенности информационных систем, что в текущих условиях может быть и неразумно. Оставлять как есть - плодить число нареканий на ФСТЭК и число запросов регулятору с просьбой разъяснить те или иные моменты новой методики. А в условиях нехватки ресурсов задача эта очень непростая. Я не знаю, как выкрутится из нее ФСТЭК, но на мой взгляд одним из выходов (хотя может быть и не очень быстрым) стала бы автоматизация процесса моделирования угроз. Вот и средствах такой автоматизации я бы и хотел поговорить.

На самом деле я планирую сделать две заметки по средствам моделирования угроз. В одной рассмотреть ключевые возможности, которыми должно обладать средство моделирования атак, а в другой - посмотреть на рынок таких средств. Начну я с первой темы. Итак, что выделяет хорошее решение по моделированию угроз и позволяет существенно снизить время и сложность составления перечня актуальных угроз для организации, ее отдельных процессов, систем или программных продуктов? Я бы обратил внимание на следующие ключевые моменты:

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

Я перечислил этакий джентльменский набор, которым должно обладать средство моделирования угроз. Разумеется, можно помечтать и расширениях, среди которых я бы выделил:

• Привязку защитных мер к различным стандартам, требованиям и лучшим практикам в области ИБ
• Учет динамичности угроз и многоходовости при их реализации. Правда, это скорее уже системы типа RedSeal или Skybox, которые могут динамически строить и перестраивать карту угроз, исходя из информации об уязвимостях, настройках средств защиты и т.п.
• Корпоративные фишки типа удаленного Web-доступа, ведения репозитория моделей угроз, ролевого доступа, отказоустойчивости и т.п.
• Учет разных целевых аудитория для модели угроз и, как следствие, разные описания угроз.
• Автоматизацию "пересчета" модели опираясь на новые угрозы, заложенные в систему.
• Возможность сравнения разных моделей угроз и анализа тенденций.

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

Подробнее…

Облачная ИБ, российские требования по локализации и точка бифуркации

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

И речь идет не о банальной услуге контроля доступа в Интернет или фильтрации электронной почты в облаках. Такие услуги сейчас есть в портфолио многих производителей средств защиты. Речь скорее о поддерживающих сервисах, которые невозможно сегодня представить без облачной поддержки. Например, обновление баз сигнатур (решающих правил) у антивирусов, средств предотвращения вторжений, средств контентной фильтрации, сканеров безопасности, межсетевых экранов или иных средств сетевой безопасности. Прошли те времени, когда обновления скачивались в эхоконференциях FIDO или на BBS; да и дискетами и флешками с обновлениями уже никто не балуется. Все давно уже получают их из облака.

Пример инфраструктуры обновления информации об угрозах у одного из мировых средств защиты

А отправка файлов для анализа их вредоносности? Она тоже идет с использованием облаков. А проверка хешей файлов или репутации сайтов? Опять через облака. А как мобильные пользователи используют защищенное подключение к Интернет? Снова облака. Да тот же VPN-as-s-Service или DDoS-as-a-Service - это тоже облако, имеющее свои точки присутствия в разных точках Земли и в разных часовых поясах. Ключевой признак такой "облачности" - распределенность. Именно в ней заключается преимущество многих современных технологий ИБ. Нет единой точки отказа, повышение надежности, рост скорости обработки, снижение задержек, учет часовых поясов... Если провести блиц-анализ рынка ИБ, то мы увидим, что точка бифуркации в этом вопросе уже давно пройдена и представить на современном этапе развития технологий ИБ чисто локальные решения уже невозможно.

И вот тут на пути победного шествия облачной ИБ в России возникает наше законодательство и явные и неявные планы по его "совершенствованию", которые рассматривают такую распределенность в мировых масштабах как угрозу национальной безопасности и государственному суверенитету. Про требование локализации баз данных ПДн россиян слышали все. А про запрет нахождение технических средств информационных систем госорганов за рубежом? Тоже многие. А про требование наличие доверенного источника обновления решающих правил для антивирусов и средств обнаружения вторжений при сертификации средств защиты информации? А какой же доверенный источник может быть на серверах в США или Европе? Вопрос риторический, конечно.

Требование локализации, которое в последнее время все чаще звучит применительно к тем или иным Интернет-сервисам или продуктам, к сожалению, не всегда положительно сказывается на обеспечении информационной безопасности. Представьте на минуточку, что ФСБ решит в рамках развития ГосСОПКА создать собственную систему Threat Intelligence, к которой смогут обращаться не только организации с территории России, но и наши партнеры по ШОС и ОДКБ (а может и БРИКС). Китай, Бразилия, Индия, Южная Африка, Белоруссия, Азербайджан будут "ходить" за этой информацией в Россию? Оптимальный ли это вариант? И готовы ли к "потере суверенитета" наши партнеры по военным и экономическим блокам?

Как влияют требования по локализации на средства ИБ (сравните с картинкой выше)

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

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

Распределенность в масштабах России

Но поднятые ранее вопросы с загранучреждениями, заграничными командировками все равно остаются. Гонять весь трафик в Россию - не самый эффективный способ решения задачи. И если для обновления средств защиты - это может быть еще и не столь критично (хотя надо смотреть схему информационных потоков), то для православных VPN-сервисов или сервисов контентной фильтрации это может уже играть важную роль. Рост задержек может привести, например, к невозможности предоставлять сервис защищенных унифицированных коммуникаций с мобильного устройства чиновника, поехавшего, например, на заседании в ООН или МАГАТЭ или в ISO.

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

Эта проблема никак не связана с санкциями и запретом со стороны иностранных государств. Она никак не связана с выпуском продуктов на территории России (локальным производством). Она никак не связана с раскрытием исходных кодов и сертификацией на отсутствие НДВ. Просто в России отсутствует нормальный Интернет и достаточное количество адекватной инфраструктуры ЦОДов для работы таких площадок и многие зарубежные компании не готовы (возможно пока не готовы) менять существующие годами процессы обновления своих средств защиты. И если запустить ЦОД по предоставлению услуг фильтрации или VPN-as-a-Service на территории России еще можно теоретически (хотя требования СОРМ и последние инициативы депутатов по хранению всех передаваемых данных в течение трех лет в интересах правоохранительных органов не добавляют оптимизма), то с серверами обновления решающих правил ситуация не столь "простая".

Есть ли решение данной проблемы? Увы. Пока все развивается вялотекуще - требования есть, но нет процедуры их контроля. Мы вплотную подступили к точке бифуркации в этом вопросе и в ближайшей перспективе (2-3 года) станет понятно, вернемся ли мы к хаосу или выйдем на качественно новый уровень. Пока же у нас полная неопределенность в этом вопросе...

Подробнее…

PCAPы для проведения собственных исследований, демонстраций и CTF

Тема проведения различных киберучений в последнее время набирает в России обороты и помимо CTF такие мероприятия в той или иной форме стали проводиться и в рамках различных конференций и семинаров. Одним из вариантов таких киберучений, помимо мозгового штурма или игрищ "А что если..." (и еще тут), является проведение лабораторных работ по анализу сетевого трафика, в рамках которой отрабатывается способность обнаруживать аномалии и несанкционированные действия в сетевом трафике, собранном и записанном с помощью, например, Wireshark. Да и при исследовании собранных доказательств такой анализ также является очень важным элементом процесса расследования инцидентов.

Но что нужно для лабораторной работы по анализу сетевого трафика? Не только инструментарий, но и сам сетевой трафик. Очевидно, что записать его не составляет большого труда, но где гарантия, что в нем есть соответствующие следы несанкционированной активности? Есть ли где-нибудь уже записанные фрагменты сетевого трафика с вредоносным кодом, которые можно было бы скачать и использовать в рамках CTF, лабораторок в ВУЗах или собственных исследований?

Да, ресурсы, содержащие записанные pcap-файлы, существуют и их немало. Например, на сайте Wireshark выложено большое количество семплов различных протоколов (около сотни), в том числе и с вредоносным содержанием. Но именно "вредоносных" семплов на Wireshark не так уж и много, в отличие от блога Contagio, где выложена целая коллекция семплов вредоносного кода в формате pcap для проведения анализа (там выложены и другие семплы - не только pcap).

Однако наибольшая из известных мне коллекций pcap находится на сайте Netresec, компании, специализирующейся на мониторинге и проведении расследований сетевых событий. Netresec собрал у себя ссылки на pcap с различных CTF (например, с DEFCON), киберучений (например, MACCDC), тренингов, челенджей и просто Интернет-ресурсов, эпизодически выкладывающих различные pcapы, которые можно скачать и использовать для своих нужд.

Подробнее…