Ранжирование защитных мер: практичный подход

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

Можно оценить любую защитную меру с трех позиций - покрытие угроз (чем больше угроз покрывает защитная мера, тем лучше), стоимость внедрения и стоимость эксплуатации. При этом второй показатель складывается из стоимости разработки (покупки) защитной меры, стоимости ее тестирования (пилотирования) и стоимости интеграции защитной меры в защищаемую среду. Стоимость эксплуатации в свою очередь также складывается из ряда параметров - стоимость обслуживающего персонала (можно иметь классную систему защиты, но не иметь персонала, умеющего с ней работать), стоимость обучения персонала (попробуйте найти в России или СНГ нормальные курсы по threat hunting или SOCам), стоимость обслуживания, поддержки, утилизации и перехода на новую или обновленную меру.

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

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

Подробнее…

Ранжирование угроз и их техник: практичный подход

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

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

Ниже я привожу один из возможных вариантов такого расчета. Пять градаций могут быть заменены на три, а количество показателей может быть как увеличено, так и уменьшено. Значения весов также указаны для примера - в конкретной ситуации с ними можно "поиграться" для достижения лучших результатов в той или иной организации. Например, в данном примере веса факторов, связанных с последствиями нарушения конфиденциальности и доступности выше, чем для нарушения целостности. Чем выше значение фактора (от 1 до 5), тем опаснее угроза. Кстати, точно по такой же методике можно оценивать и техники угроз. 

Для части показателей, чем выше их значение, чем угроза становится менее опасной. Может быть это не сразу становится понятным, но логика в этом есть. Чем сложнее атака, тем ниже вероятность ее реализации и, как следствие, ниже итоговый рейтинг. Хотя не исключаю, что под конкретные задачи можно пойти и привычным путем и более сложную атаку (и в части ресурсов, и в части детектируемости) считать и более опасной.

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

У данного подхода есть, как минимум, три преимущества. Во-первых, он легко автоматизируется - я прикладываю к заметке табличку в Excel, которую вы можете использовать для своих нужд и которая позволит вам ускорить процесс моделирования. Во-вторых, такое матричное представление и ранжирование угроз гораздо более компактное и помещается на половине страницы А4, что позволяет методики на ее основе делать также более компактными. Наконец, если вдруг возникнет задача обмена моделями угроз или их согласования, то отправить табличку в Excel гораздо проще, чем 200-300 страниц в Word. Да и проверять и согласовывать такие таблицы гораздо проще, чем вникать в сотнистраничные манускрипты.

Подробнее…

Не методикой ФСТЭК единой или модели угроз, утвержденные государством российским

Разрешая операторам информационных систем различного типа самостоятельно проводить оценку и моделирование угроз, наши регуляторы не забывают выпускать и собственные перечни негативных событий, которые по разумению регуляторов в обязательном порядке должны быть учтены в рамках выстраивания системы защиты информации в той или иной области. Учитывая, что сейчас таких моделей/перечнем стало немало, я подумал, что было бы правильно собрать их в рамках одной заметки, к которой можно было бы обращаться по мере необходимости. При этом стоит обратить внимание, что пока 90% этих моделей крутится вокруг всего одной темы - персональные данные, в том числе и биометрические.

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

На второе место можно смело ставить модель угроз безопасности ПДн, выпущенную в 2015-м году Банком России и утвержденную в виде Указания Банка России от 10.12.2015 №3889-У "Об определении угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных".

Спустя 3 года после предыдущего нормативного акта банковский регулятор выпустил новый документ - Указание Банка России от 9 июля 2018 года №4859-У "О перечне угроз безопасности, актуальных при обработке, включая сбор и хранение, биометрических персональных данных, их проверке и передаче информации о степени их соответствия предоставленным биометрическим персональным данным гражданина Российской Федерации в государственных органах, банках и иных организациях, указанных в абзаце первом части 1 статьи 14.1 Федерального закона от 27 июля 2006 года N 149-ФЗ "Об информации, информационных технологиях и о защите информации", в единой биометрической системе". Однако, ввиду серьезной переработки законодательства о ЕБС и навязывании ее везде и всем, Банк России решил отменить данное Указание, предложив вместо него два новых проекта, которые должны быть приняты в этом году:

• Проект Указания Банка России "О перечне угроз безопасности, актуальных при обработке биометрических персональных данных, их проверке и передаче информации о степени их соответствия предоставленным биометрическим персональным данным физического лица, при взаимодействии организаций финансового рынка с единой биометрической системой с учетом оценки возможного вреда, проведенной в соответствии с законодательством Российской Федерации о персональных данных"
• Проект Указания Банка России "О перечне угроз безопасности, актуальных при обработке биометрических персональных данных, их проверке и передаче информации о степени их соответствия предоставленным биометрическим персональным данным физического лица в информационных системах организаций финансового рынка, осуществляющих идентификацию и (или) аутентификацию с использованием биометрических персональных данных физических лиц, за исключением единой биометрической системы, а также актуальных при взаимодействии организаций финансового рынка, иных организаций, индивидуальных предпринимателей с указанными информационными системами, с учетом оценки возможного вреда, проведенной в соответствии с законодательством Российской Федерации о персональных данных"

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

• Приказ Минцифры от 26.11.2020 № 624 «Об утверждении перечня угроз безопасности, актуальных при идентификации заявителя – физического лица в аккредитованном удостоверяющем центре, выдаче квалифицированного сертификата без его личного присутствия с применением информационных технологий путем предоставления сведений из единой системы идентификации и аутентификации и единой информационной системы персональных данных, обеспечивающей обработку, сбор и хранение биометрических персональных данных, их проверку и передачу информации о степени их соответствия предоставленным биометрическим персональным данным гражданина Российской Федерации, а также хранении и использовании ключа электронной подписи в аккредитованном удостоверяющем центре».
• Приказ Минцифры от 21.12.2020 № 734 "Об определении угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных, эксплуатируемых в сферах деятельности, нормативно-правовое регулирование которых осуществляется Министерством цифрового развития, связи и массовых коммуникаций Российской Федерации".

Кроме того, Мицифры подготовило еще один проект приказа,  который также касается угроз биометрическим ПДн, - "Об утверждении перечня угроз безопасности, актуальных при обработке биометрических персональных данных, их проверке и передаче информации о степени их соответствия предоставленным биометрическим персональным данным физического лица в информационных системах организаций, осуществляющих идентификацию и (или) аутентификацию с использованием биометрических персональных данных физических лиц, за исключением единой биометрической системы, а также актуальных при взаимодействии государственных органов, органов местного самоуправления, индивидуальных предпринимателей, нотариусов и организаций, за исключением организаций финансового рынка, с указанными информационными системами, с учетом оценки возможного вреда, проведенной в соответствии с законодательством Российской Федерации о персональных данных, и учетом вида аккредитации организации из числа организаций, указанных в частях 18.28 и 18.31 статьи 14.1 Федерального закона от 27 июля 2006 года N 149-ФЗ "Об информации, информационных технологиях и о защите информации".

Минцифры вернулось в стройные, но плохо согласующие свои действия, ряды регуляторов по ИБ относительно недавно. Лет 10 от них ничего в этой области не было слышно, хотя раньше они были вполне активны и выпускали/согласовывали разные документы по защите информации. Одним из таких документов была "Модель угроз и нарушителя безопасности ПДн, обрабатываемых в ИСПДн отрасли [связи]", согласованная с ФСТЭК и ФСБ России. Текущий статус этого документа ввиду выхода новой методики ФСТЭК не совсем ясен (хотя с сайта министерства она не убрана) и возможно новый руководитель департамента кибербезопасности Минцифры наведет порядок в том, что делали его предшественники, коих сменилось на этом посту не мало.    

При этом не забывайте, что помимо указанных нормативных актов, выпущенных регуляторами и действующими на территории всей страны, существует немало перечней угроз ПДн, которые утверждались или каким-либо субъектом РФ, или каким-то министерством для себя и своих поднадзорных структур. Например, приказ Департамента здравоохранения Курганской области от 30 мая 2018 года №632 "Об утверждении Перечня угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных в Департаменте здравоохранения Курганской области и подведомственных ему учреждениях, организациях", приказ Минэнерго от 02.08.2019 №819 "Об определении угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных, эксплуатируемых при осуществлении Минэнерго России функций, определенных законодательством Российской Федерации" или Постановление Правительства Пензенской области от 20.04.2017 №192-пП "Об определении угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных Пензенской области" (почти в каждом субъекте РФ есть такое постановление).

Немного особняком стоит тема моделирования угроз, а точнее атак, на средства криптографической защиты информации. И если раньше ею можно было и не заниматься, так как обычно все эти вопросы ложились на производителей СКЗИ, которые и должны были решить эту задачу, то сейчас ситуация меняется. ФСБ подготовило проект приказа "Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, с использованием средств криптографической защиты информации", а последние правки в Постановление Правительства от 6 июля 2015 №676 "О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации". Оба документа подразумевают согласование модели угроз с ФСБ, что заставляет нас задумываться о том, есть ли утвержденные этим, уже 4-м в сегодняшней заметке регулятором, перечни угроз безопасности? На самом деле их нет. Но есть документы, на которые стоит ориентироваться при составлении модели угроз (атак) на СКЗИ:

• Приказ ФСБ от 10.07.2014 №378 "Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности".
• Методические рекомендации ФСБ по разработке нормативных правовых актов, определяющих угрозы безопасности персональных данных, актуальные при обработке персональных данных в информационных системах персональных данных, эксплуатируемых при осуществлении соответствующих видов деятельности.

Но не персональными данными едиными. Существуют перечни угроз и для других объектов защиты, например, для Интернета, а точнее для функционирования Интернета на территории России. Российские власти выделяют для него три типа негативных событий - угрозы устойчивости, безопасности и целостности функционирования Рунета. Они описаны в Постановлении Правительства  от 12.02.2020 № 127 "Об утверждении Правил централизованного управления сетью связи общего пользования".

Еще одним "особняком" я бы назвал тему моделирования угроз при разработке безопасного программного обеспечения, которая стала новым "фетишем" (в хорошем смысле) и для ФСТЭК и для Банка России. Существующая методика оценки угроз ФСТЭК не очень подходит для моделирования угроз для разрабатываемого ПО, как того требует утвержденный ГОСТ Р 56939-2016 "Защита информации. Разработка безопасного программного обеспения. Общие положения". Но зато в качестве перечня угроз можно ориентироваться на ГОСТ Р 58412-2019 "Защита информации. Разработка безопасного программного обеспения. Угрозы безопасности информации при разработке программного обеспечения". Не STRIDE, конечно, но тоже ничего.

Есть и совсем специфические перечни угроз, которые применимы для объектов защиты, работающих в очень узких сферах деятельности. Например, приказ Минэнерго от 6 ноября 2018 года №1015 «Об утверждении требований в отношении базовых (обязательных) функций и информационной безопасности объектов электроэнергетики при создании и последующей эксплуатации на территории Российской Федерации систем удаленного мониторинга и диагностики энергетического оборудования» определяет базовые атаки и базовые уязвимости для построения модели угроз СУМиД, а также перечень из 59 угроз безопасности.

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

Вот такая картина получается - свобода свободой, но стоит оглядываться и по сторонам, вдруг регуляторы за вас посчитают какие-то негативные действия актуальными, которые вам придется учитывать в своих моделях/перечнях угроз.

Подробнее…

Что лучше - длина или объем или почему спецсимволы в пароле не нужны?

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

Доказательством тому является формула Андерсона. Я не знаю, учат ли сейчас ее в институтах, но в мое время ее преподавали. С помощью нее определяют время подбора пароля, который характеризуется двумя параметрами - длиной (количество символов) и объемом алфавита (количество вариантов символа в каждой позиции пароля). Школьный курс комбинаторики подсказывает нам, что число возможных комбинацией пароля из L символов и объеме (мощности) алфавита A будет равно A^L (A в степени L). В формуле Андерсона также присутствует такой параметр как скорость перебора пароля (V). В итоге мы получаем следующую формулу, которая и показывает время перебора пароля определенной длины и определенной мощности алфавита при заданной скорости. Понятно, что чем, мощнее у нас компьютер или кластер компьютеров, тем быстрее будет производиться перебор (отсюда отличия в картинках, которые можно найти в Интернете и которые показывают сколько лет будут ломать ваш пароль).

Есть и другой вариант этой формулы, в которой P - это вероятность подбора пароля за указанный интервал времени, G - число попыток подбора за 1 такт времени, T -  число тактов времени и A^L - число возможных комбинаций пароля.

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

Понятно, что речь не идет о просто длинных словах. Какая-нибудь "электрификация" (14 символов) хоть и длинна, но все-таки это слово присутствует в словарях, которые могут быть использованы при переборе. Слово "метоксихлордиэтиламинометилбутиламиноакридин" (44 символа) я бы тоже не стал использовать, а то кто знает, может у хакеров есть и словари названий химических веществ. Но вот какое-нибудь "модясачепродвшузаиувсезанобовынемо" (34 символа) вполне себе подойдет (немного шучу, но только немного). Запомнить его несложно - это первые два символа из начала "Евгения Онегина" ("Мой дядя самых честных правил..."). На самом деле начало у Онегина другое ("Не мысля гордый свет забавить..."), но "мой вариант" более привычен.

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

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

Подробнее…

Разбитая чашка кинцуги, как символ современной ИБ, или о чем говорили на RSA Conference 2021

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

Еще один слайд с аналогиями ИБ

Именно с такой аналогии началась конференция  RSA 2021, завершившаяся почти месяц назад, а у меня все не доходили руки, чтобы о ней написать. В этом году тема устойчивости (resilience) пронизывала красной нитью все мероприятие, которое проходило целиком в онлайн-формате. Могу сказать, что получилось очень неплохо. Да, нехватало нетворкинга и очных дискуссий, который все-таки имеют свою атмосферу, отличную от виртуальных выступлений. Но организаторы смогли все-таки показать, что и онлайн может быть интересным. Рекламы почти нет (как и всегда), куча практики, множество дискуссий и интерактивных сессий, возможность задавать вопросы спикерам (на очной RSAC это всегда было непросто). И все это за почти пять сотен долларов, что гораздо дешевле прошлогодних RSAC, цена участия в которых начиналась с 2-х тысяч; плюс стоимость перелета и проживания. И хотя отсутствие очных встреч оттолкнуло ряд участников, более 16000 человек на RSAC все-таки пришли.

Я не буду подробно погружаться в каждый из нескольких сотен докладов (а как и на обычной RSAC и в этот раз параллельно проходило около 10 сессий), но ключевые направления и наиболее популярные темы подсвечу. Тем более, что они характеризуют определенные тенденции на рынке ИБ. Итак, мои наблюдения (тезисно):

1. Очень активно обсуждалась тема кибербезопасности в авиации и медицине. И если последнее понятно (атаки шифровальщиков на медицинские организации и проникновения в фармацевтические компании, занимающиеся исследованиями COVID-19), то внимание к авиационной ИБ для меня стало некоторым открытием. Вроде как инцидентов серьезных в этом сегменте не было; как и новых регулятивных требований. В любом случае именно эти две отрасли стали наиболее популярными на RSAC. Финансы, госы, транспорт, нефтянка, энергетика и т.п. не удостоились чести быть активно представленными на мероприятии.
2. Машинное обучение (не поворачивается у меня язык называть это искусственным интеллектом) стало еще одной горячей темой RSAC, но дифирамбов этой технологии уже никто не поет. Надо признать, что на пути активного внедрения ML в ИБ встало несколько сложностей, а именно отсутствие актуальных и публичных датасетов, а также отсутствие тех, кого на английском языке модно называть data scientist. Без первого сложно обучать модели ML; без второго - разрабатывать сами модели. И хотя аналитиков данных сегодня выпускают все кому не лень, прикладных аналитиков среди них почти нет. Ну не будем же мы всерьез называть аналитиком данных того, кто прошел двухнедельные курсы по Python и умеет извлекать ключевые слова из массива данных или суммировать значения в таблице. Но даже при наличии аналитиков возникает вопрос с тем, на чем они будут обкатывать свои данные - несмотря на прогнозы Рустема Хайретдинова, что скоро датасеты по ИБ будут выкладывать в открытый доступ и они перестанут быть конкурентным преимуществом, до этого еще очень далеко. Такие датасеты, еще и регулярно обновляемые и размеченные, находятся в собственности крупных игроков рынка и они делиться ими не спешат. Остальным же остается довольствоваться датасетом KDD 99 :-)
3. На удивление популярной стала тема моделирования угроз, о которой говорили многие, приводя различные примеры моделей и подходов к моделированию для различных систем - от облаков до АСУ ТП. Отдельно хотелось бы отметить интересный мастер-класс по форкастированию угроз, то есть, по-русски, по научному предсказанию того, что будет в долгосрочной перспективе и на горизонте в 7-10 лет. Интересное было упражнение - надо будет его как-нибудь повторить на других данных. Кстати, практики на RSAC было немало, что необычно для онлайн-мероприятий. Но предварительная подготовка и хорошее модерирование показали, что даже не собирая людей в одной комнате, можно отлично проводить лабораторные работы, давать задания, принимать ответы и т.п. 
4. Предсказуемо много говорили про матрицу MITRE ATT&CK и ее применение в различных сценариях ИБ - от редтиминга до моделирования угроз, от оценки средств защиты до формирования стратегии ИБ. У меня в последнее время в блоге тоже немало заметок по этому фреймворку и я планирую продолжить писать про него.
5. После истории с SUNBURST немало докладов было посвящено атакам на цепочки поставок и тому, как с ними бороться. Примерно такая же история была в свое время с WannaCry - после него многие ИБ-компании рассказывали, как надо обнаруживать и предотвращать эту угрозу. Правда, почему их решения не обнаруживали WannaCry ДО его начала (хотя прошел месяц с момента публикации данных об уязвимости до начала эпидемии), никто не отвечал :-) Так и с проникновением в сеть компании SolarWinds. Но идеи были озвучены интересные и эта тема осстанется популярной на ближайшее время.
6. Удивительно, но, в отличие от прошлых лет почти никто не обвинял русских хакеров (исключая Альперовича). Вообще тему атрибуции обходили стороной, видимо, понимая, что делать выводы о принадлежности хакеров тому или иному государству, не пристало на серьезной конференции специалистов по ИБ. 
7. Новых технологий по ИБ представлено почти не было, исключая, пожалуй, Attack Surface Management, о которых я писал несколько дней назад. Но зато из всех щелей звучало три аббревиатуры - ZT (Zero Trust), XDR (eXtended Detection & Response) и SASE (Secure Access Service Edge). Я про них уже тоже писал - про ZT аж в 2014-м году еще, про SASE пару лет назад. Но это, по сути, и не новые технологии, а скорее новый взгляд на комбинирование этих технологий для достижения новых результатов. ZT - это ответ на размывание периметра и необходимость обеспечивать непрерывный контроль доступа по динамическим правилам. XDR - это новый взгляд на обнаружение угроз, когда разные системы (хостовые, сетевые, облачные и т.п.) объединяются в единый комплекс для обнаружения того, что ранее было скрыто от отдельных решений по мониторингу. Не удивлюсь, если скоро кто-то скажет, что SIEM мертвы и нужно переходить на XDR. Ну а SASE  - это очевидный ответ на переход всех в облака и нехватку кадров для решения всех вопросов ИБ своими силами.
8. С технологической точки зрения также немало докладов было посвящено безопасности АСУ ТП и приложениям. Но это тренд последних лет, который просто усиливается.
9. А SOCи? Как же SOCи? Эта аббревиатура тоже слышалась из всех динамиков, но не как самостоятельное направление, а как необходимый элемент любой системы ИБ любой организации, в котором аккумулируются все усилия по мониторингу (с помощью XDR и SASE в том числе) и реагированию на инциденты на широкий спектр атак - от шифровальщиков (про них, кстати, много не говорили, видимо все сказав на прошедшем в рамках RSAC Ransomware Summit пару лет назад).

Вот такая картинка вырисовывается. Каких-то прорывов и откровений не звучало - скорее все обсуждали, как обеспечить киберустойчивость предприятий в условиях постоянных атак. В целом мне мероприятие понравилось. Хотя и не хватило живого общения, брожения по стендам вендоров, споров в близлежащих барах и вечерних посиделок. Интересно, что на выставке раньше было раза в 3-4 больше экспонентов, чем в онлайне, что странно. По идее порог входа в онлайн гораздо ниже - просто выложи свои материалы на страницу и собирай лиды. Но, видимо, этот пассивный маркетинг уже не работает и компании не хотят тратить на него усилия, желая очного общения, демонстраций на стендах, рассказа о преимуществах глядя в глаза посетителям. Этого не хватало, да.

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

ЗЫ. Пойду разгребать свои записи с RSAC - было немало того, что достойно того, чтобы про него написать.

Подробнее…

От техник и тактик угроз к мерам обнаружения и защиты. Как сопоставить первое со вторым?

Читая методику оценки угроз ФСТЭК, собственно как и матрицу MITRE ATT&CK, понимаешь, что делается это все не просто так, а для какой-то цели (вот новость-то). И целью этой является выработка защитных мер, которые позволят нам противодейстовать выбранным нами как актуальными техникам и тактикам нарушителей. Еще во время появления первых документов ФСТЭК в 2013-м году многие эксперты задавались вопросом, а как увязать защитные меры с моделью угроз. У ФСТЭК пока нет ответа на этот вопрос, а вот у MITRE есть. Ему я и посвящу данную заметку.

В фреймворк MITRE ATT&CK помимо техник и тактик входит еще один блок - защитных мер (mitigations), которые увязаны с блокируемыми ими техниками и тактиками.

Таким образом, выбрав актуальные для вас техники и тактики, можно перейти к мерам, которые позволяют их нейтрализовать. На текущий момент фреймворк MITRE ATT&CK содержит 42 защитные меры (для мобильных устройств еще 13 защитных мер), среди которых шифрование важных данных, антивирус, контроль сетевого доступа, управление привилегированными учетными записями, обновление ПО, программа Threat Intelligence и т.п. Среди 42-х мер (вот он ответ на главный вопрос жизни, вселенной и всего такого) есть и такая "не надо блокировать", в описании которой сказано, что реализация защитной меры может повлечь рост риска компрометации: а значит нейтрализация не рекомендуется (сейчас техник, для которых эта рекомендация дана, всего две).

Для многих техник и тактик в матрице указаны не только защитные меры, но и источники данных, которые позволяют их детектировать с помощью различных технологий - от XDR и SIEM до антивирусов и средств контроля целостности файлов и ПО.

В итоге, если объединить блок защитных мер с блоком источников данных мы получим возможность бороться со всеми почти 400 техниками, которые описаны в текущей версии MITRE ATT&CK. Этого тоже пока не хватает подходу ФСТЭК, у которого из всего "фреймворка" есть пока только перечень техник и тактик. Поэтому-то я и ратую за то, чтобы ФСТЭК прекратила заниматься самодеятельностью и унифицировала нумерацию своих техник и тактик с тем, что есть у MITRE. В этом случае даже при отсутствии времени и ресурсов на разработку полного собственного фреймворка можно было бы использовать уже имеющиеся наработки от MITRE.  

Самое интересное, что 42 защитные меры от MITRE ATT&CK могут быть смаппированы в различные иные защитные фреймворки - ISO 27001/27002, NIST CSF и CIS Controls. Например, вот так этом может выглядеть для последнего фреймворка.  

В защитные меры из приказов ФСТЭК тоже можно смаппировать, но про это в другой раз.

Подробнее…

Как написать свой профстандарт специалиста по ИБ, а заодно и должностную инструкцию для него?

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

Мне подумалось, что надо помочь писателям профстандартов и подсказать им прекрасный ресурс, с которого можно копипастить все, что необходимо для качественного профстандарта специалиста по ИБ. Самим же авторам стандартов останется заниматься только оформлением переведенного текста. Да, это не русскоязычный ресурс, но от этого он не стал хуже, скорее наоборот. Речь идет об постоянно обновляемом фреймворке NICE (National Initiative for Cybersecurity Education).

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

К семи категориям и 33 специализациям внутри них относятся:

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

В зависимости от специализации выделяются 52 роли или, можно сказать, должности по ИБ. Например, аналитик по киберпреступлениям, архитектор, администратор баз данных, аналитик SOC, специалист по расследованиям, аудитор, разработчик ПО, инструктор и т.п. Но NICE полезен не тем, что он классифицировал ИБ-роли, а тем, что для каждой из них прописаны рекомендуемые обязанности, знания и навыки. Например, возьмем специалиста по реагированию на инциденты. Он должен разбираться в 30-ти областях знаний, среди которых:

• знание угроз и уязвимостей
• знание законодательства (без уточнения какого)
• знание сетевых сервисов и протоколов
• знание категорий инцидентов
• знание методов обнаружения атак на уровне сети, хостов и облаков
• знание основных сетевых концепций, включая топологии, протоколы, компоненты
• знание концепций и методологий анализа вредоносного ПО
• знание рисков безопасности приложений, например, OWASP Top10
• и т.п.

Навыков от специалиста по реагированию требуется "всего" восемь:

• навыки идентификации, получения, локализации и репортинга по вредоносному ПО
• навыки обеспечения целостности цифровых доказательств на разных платформах и в соответствие с требованиями локального законодательства
• навыки защиты сетевых коммуникаций
• навыки распознавания и категоризации типов уязвимостей и связанных с ними атак
• навыки защиты сети от вредоносного ПО
• навыки оценки ущерба
• навыки использования средств корреляции событий ИБ
• навыки реализации реагирования на инциденты для облаков (этот пункт, видимо, добавился совсем недавно).

Наконец, в NICE для каждой роли описаны еще и служебные обязанности, среди которых, например:

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

В заключение, для каждой роли прописаны дополнительные требования, привязанные к трем уровням "крутости" специалиста (начальный, средний, продвинутый). У нас бы их назвали как-нибудь типа инженер по защите информации I-III категории, ведущий или старший инженер по защите информации. Для каждого из 3-х уровней NICE рекомендует:

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

В США, где, собственно, и родилась инициатива NICE, сейчас все требования к специалистам по ИБ, особенно для госорганов, базируются на NICE, что позволяет использовать этот фреймворк как единую точку отсчета для оценки специалистов по ИБ. Работодатели знают, что требовать от кандидатов при приеме на работу, а также что включать в должностные инструкции. ВУЗы знают, какие навыки будут востребованы работодателями и готовят свои учебные планы, отталкиваясь от нужных навыков и знаний. Кандидаты понимают, что им надо знать/уметь, когда они отзываются на ту или иную вакансию. Учебные центры могут готовить нужных специалистов в соответствие с классификацией NICE.

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

Подробнее…

Куда движутся SOCи? Взгляд с RSA Conference 2021

Занимаясь проектами по SOC (как проектированием, так и оценкой существующих и разработкой их улучшений) постоянно сталкиваюсь с темой развития центров мониторинга в соответствие с лучшими практиками. Готовя такие планы, обычно включаешь в них только то, что уже проверено и действительно дает эффект. Понятно, что есть различные идеи и технологии, которые вроде и появились на рынке, но пока непонятно, насколько они полезны на практике. Рекомендовать их в рамках консалтинга не совсем правильно, но и скрывать тоже не имеет смысла. Поэтому решил вкратце пройтись по интересным новациям, которые были представлены в рамках прошедшей в конце мая RSA Conference 2021, где одной из популярных тем стал именно мониторинг ИБ. И хотя в условиях провального импортозамещения все это так и останется красивой сказкой, но кому-то может и поможет. Итак, что добавляют различные компании, производители и потребители, в свои SOCи для повышения их эффективности.

Во-первых, это решения класса Security Intelligence Automation, которые обладают следующими отличительными особенностями:

• Библиотека знаний по ИБ. Человек принимает решения, опираясь на достаточно широкий кругозор и имеющийся опыт, который отсутствует у многих средств анализа ИБ. Идея заключается в формализации правил принятия решений и помещении их в систему для того, чтобы и другие аналитики могли воспользоваться этой библиотекой, и сами средства анализа могли в автоматическом режиме обращаться к этой библиотеке при проверке гипотез и поступающих от источников данных событий. По сути речь идет о набившем оскомину тезисе о контекстно-ориентированной аналитике, но с ее формализацией для удобства использования.
• Роботизация экспертизы расследований инцидентов. При проведении расследований инцидентов аналитики опираются не только на плейбуки, но и на свой опыт, позволяющий им сопоставлять разные данные и делать на их основе выводы, облегчающие принятие решений, классификацию и приоритизацию инцидентов. Анализ выполняемых аналитиками ежедневных действий и выявление в них закономерностей, которые потом могут быть автоматизированы, это тоже тренд в SOCостроении. 
• Роботизация человеческой классификации и приоритизации инцидентов. Многие средства анализа ИБ построены по принципу обнаружения "известного плохого" и пасуют перед новыми событиями, в классификации и приоритизации которых задействуется человек. Часто набор производимых при этом действий достаточно стандартный и может быть автоматизирован с помощью инструментов, схожих с RPA. 

Ключевыми тут являются последние две возможности, которые позволяют не ждать, когда занятые аналитики соблаговолят записать свои действия и облегчит себе жизнь, а заставить "робота", наблюдая за действиями аналитика, записать их и потом их будет гораздо проще проверить, "согласовать" и ввести в действие.

Вторым интересным рассмотренным на RSAC направлением стали решения класса Attack Surface Management, которые позволяют в непрерывном режиме оценивать потенциальные точки проникновения в организацию. Делают они это за счет нескольких функций:

• Автоматическая инвентаризация, которая позволяет идентифицировать все ваши активы без указания, как в сканерах, диапазона IP-адресов. При этом решения класса ASM учитывают наличие облачных сред, динамические инфраструктуры и т.п.
• Непрерывный мониторинг позволяет отслеживать все изменения, происходящие в сети.
• Риск-ориентированный анализ, который заключается в приоритизации ресурсов и активов на основе различных данных - уязвимостей, критичности активов, наличие известных эксплойтов, сложности их использования и т.п. На основании этой информации каждому активу присваивается уровень риска.

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

Другой проблемой, на которой были направлены усилия отрасли, стала снижение числа ложных срабатываний, с которыми сталкиваются почти все организации (число фолсов достигает 50% и выше). Одним из способов борьбы с этим является внедрение риск-ориентированной аналитики в SIEM, в рамках которой происходит не просто обычная корреляция событий ИБ, но к ней добавляется учет TTP по MITRE ATT&CK (увы, ТТУ от ФСТЭК не поддерживается), уровень риска узла или системы или пользователя и ряд других показателей (у Splunk такой механизм называется RBA - Risk Based Alerting).

Пример риск-ориентированной оценки активов в SIEM

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

Последним в этой заметке я упомяну решения класса no code, которые начали завоевывать рынок (сложно от всех требовать умения программировать), в том числе и в ИБ. В частности сегмент SOAR стал одним из первых, в которых стали появляться решения no code, позволяющие описывать плейбуки и интеграции с другими решениями без написания отдельных коннектов. Причем в этом направлении сейчас идут многие игроки - от стартапов типа Tines, sirp.io, D3 Security:

Пример описания workflow без программирования

до крупных игроков типа Spunk (с Phantom) или Cisco (с бесплатным SecureX):

Пример встроенных коннекторов с разными решениями по ИБ

Вот такая вырисовывается картина. В условиях роста числа событий ИБ, увеличения ложных срабатываний, нехватки кадров и большого разнообразия средств защиты, которые надо объединять в единый комплекс, вполне очевидной становится задача автоматизации различных аспектов работы SOC, что и наблюдается в отрасли и ее мероприятиях, включая и RSA Conference.  

Подробнее…

Что не покрывает методика оценки угроз ФСТЭК?

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

Во-первых, угрозы, связанные с шифровальными средствами, регулируются различными публичными и не очень документами ФСБ, в том числе:

• «Методические рекомендации по разработке нормативных правовых актов, определяющих угрозы безопасности ПДн, актуальные при обработке ПДн в ИСПДн, эксплуатируемых при осуществлении соответствующих видов деятельности» (утверждены руководством 8 Центра ФСБ России 31 марта 2015 года, № 149/7/2/6-432)
• «Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности» (утверждены приказом ФСБ России от 10 июля 2014 года № 378).

Во-вторых, финансовые организации, которые являются либо операторами ПДн, либо владельцами ЗОКИИ, обязаны соблюдать помимо документов ФСТЭК еще и документы Банка России, а именно два действующих Указания:

• Указание Банка России от 10 декабря 2015 г. № 3889-У «Об определении угроз безопасности ПДн, актуальных при обработке ПДн в ИСПДн»
• Указание Банка России и ПАО «Ростелеком» от 9 июля 2018 г. № 4859-У/01/01/782-18 «О перечне угроз безопасности, актуальных при обработке, включая сбор и хранение, биометрических ПДн, их проверке и передаче информации о степени их соответствия предоставленным биометрическим ПДн гражданина РФ в государственных органах, банках и иных организациях, указанных в абзаце первом части 1 статьи 14.1 Федерального закона от 27 июля 2006 года N 149-ФЗ «Об информации, информационных технологиях и о защите информации», в единой биометрической системе»

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

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

Разные методики моделирования угроз

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

Но если внимательно посмотреть на описанные зоны действия методики, то мы увидим, что она, например, плохо подходит для оценки угроз при разработке программного обеспечения, что, например, требуется по отечественным ГОСТам по безопасной разработке. В этом случае вам потребуется что-то другое. Например, хорошим стартом может послужить методика от Microsoft, которую для краткости называют STRIDE, хотя она этой аббревиатурой и не ограничивается. Она, безусловно покарывает не все угрозы для ПО, но самые популярные точно. Кроме того, по ней существует немало материалов и курсов, а также бесплатные средства автоматизации данной задачи. Можно еще посмотреть в сторону методики OWASP, но она не сильно отличается от Microsoft'овской.

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

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

Подробнее…