14.11.2018

Устранять или нет? Вот в чем вопрос!

Malotavr, который недавно вновь вернулся в эпистолярный жанр по ИБ, обратил свое пристальное внимание на тему управления уязвимостями (тут и тут). И это немудрено, учитывая место его работы - компанию Positive Technologies. Так сложилось, что и я недавно погрузился в эту тему, задавшись достаточно простым, на первый взгляд, вопросом - как приоритезировать уязвимости, которые надо устранять? Их могут тысячи и даже сотни тысяч в крупной инфраструктуре. Вариант "устранять все" в реальной жизни не работает. Пока мы устраняем одни уязвимости (в каком порядке? по времени? по критичности узла? по критичности уязвимости?), злоумышленники могут воспользоваться другими. Устраняя "другие", злоумышленники могут воспользоваться третьими. И так далее. Где провести ту грань, за которой уязвимость может быть отложена "на потом"?

Задавшись этим вопросом, я, случайно или нет, наткнулся на интересное исследование, в котором был проведен анализ списка CVE корпорации MITRE. Из 120 тысяч CVE были отброшены зарезервированные, отброшенные или еще обсуждаемые уязвимости - осталось 94457 дыр, по которым исследователи анализировали наличие эксплойта, в том числе и находящегося в диком виде. По результатам исследования были сделаны следующие выводы:

  • 23% опубликованных уязвимостей имеют эксплойт.
  • 2% уязвимостей имеют эксплойт в диком виде.
  • Вероятность уязвимости быть использованной в 7 раз выше, если эксплойт существует. 
  • 50% эксплойтов публикуется в течение двух недель после обнаружения уязвимости.

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

В ней я отталкиваюсь в первую очередь от общего рейтинга CVSS; затем смотрю на наличие эксплойта (либо из Банка данных уязвмостей ФСТЭК, либо из CVSS); потом на наличие удаленной эксплуатации дыры (параметр AV в CVSS), и, наконец, на сложность получения доступа (параметр AC в CVSS). Все значения берутся из полей БДУ. В реальной жизни для проверки наличия эксплойта и подтверждения CVSS обычно используются перекрестные базы (NVD, Secunia, ExploitDB, Cisco, Vulners и т.п.), но для ряда пользователей, особенно государственных, использовать зарубежные БД было бы не совсем правильно. К сожалению, наполнение БДУ пока не идеально (особенно в части оперативной информации по наличию эксплойтов), но другой возможности у госов нет (хотя тот же Vulners имеет российские корни, но "не признан" регулятором).


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

Понятно, что у схемы есть и свои ограничения. Например, мы отсекаем локальные уязвимости без эксплойта с CVSS ниже 6.5, которые могут быть использованы злоумышленником, имеющим физический доступ к объекту защиты. Но тут я исхожу из предположения, что потребитель все-таки имеет хоть какие-то меры по контролю физического доступа, усложняющие эксплуатацию локальной уязвимости (хотя риск инсайдера остается). Также за двухнедельный временной зазор может быть разработан эксплойт и система может быть взломана. Можно попробовать уменьшить этот срок, но тогда мы слишком часто будем запускать цикл проверки, что для многих систем, особенно ГИС/МИС, будет непросто. Также я исхожу из того, что при отсутствии мер защиты безопасники все-таки смогут разработать компенсирующие меры (отключить уязвимую систему от сети, заменить уязвимое устройство, установить «виртуальный патч», зарезервировать систему, заблокировать использование уязвимости с помощью МСЭ или IDS и т.п.). Если нет, то тут уже ничего сделать нельзя :-(

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

13.11.2018

ФЗ коряв, но он ФЗ. Его изменят, но когда, ХЗ!

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

Алексей Лукацкий, Сергей Борисов, Александр Кузнецов, Алексей Комаров, Валерий Комаров (они с Алексеем не братья), Павел Луцик

Судя по времени, которое регулятор взял на анализ вопросов, я считал, что будут даны ответы на все 150+ из них и уже даже заготовил бутерброды с горячим чаем и предупредил семью, что могу вернуться заполночь. Но увы... ФСТЭК, числом 4 человека, во главе с Виталием Сергеевичем Лютиковым, поделилась своим видением происходящего и будущего, а также обрисовала свое видение ключевых вопросов, касающихся защиты информации в КИИ. При этом ФСТЭК сразу предупредила, что и взгляд может быть и неправильным. Хотя учитывая, что именно они регулятор, даже неправильный взгляд стоит учитывать. РКН, вон, тоже многие вещи трактует неправильно, но это не мешает ему осуществлять надзорную деятельность в соответствие с этими неверными (на мой взгляд) трактовками. Так и со ФСТЭК. Второй важный момент, прозвучавший на встрече, все, что делает ФСБ - не может быть предметом обсуждения, независимо от того, правильно это или нет, согласен с этим регулятор или нет. В чужие дела ФСТЭК не лезет, занимась только своей зоной ответственности. Уже после встречи у нас возникла мысль, что может быть и ФСБ/НКЦКИ соберет блогеров на такое неформальное общение. Хотя я в это верю с трудом. Тот же malotavr уже делился тем, что ФСБ собирает экспертов для обсуждения, но круг этих экспертов явно иной, чем ходоки блогеры, ходившие в ФСТЭК.

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

  1. "ФЗ коряв, но он ФЗ". Это общая мысль к тексту ФЗ-187, который содержит немалое количество ляпов, в том числе и терминологических. Но общее мнение регуляторов, законодателей и приближенных к ним - менять ФЗ сейчас неразумно. Должно пройти минимум года два, прежде чем об этом всерьез задумаются. Поэтому ни изменения понятия "объект КИИ", ни понятия "субъект КИИ", ни перечня сфер деятельности не будет в ближайшее время.
  2. Подход к определению объектов КИИ от критичности процессов, которые ИС обслуживает, останется неизменным. И его поддерживает и ФСБ в том числе. Поэтому разночтений с тем, считать объектом КИИ то, что написано в ФЗ-187 или в ПП-127, у регуляторов нет.
  3. Позиция некоторых субъектов, считающих, что если они могут перейти на ручной режим работы, то у них нет значимых, и вообще объектов КИИ, не является верной. Важна не только доступность ИС, но и ее влияние на критический процесс. Если в результате направленного (и этот момент достаточно важен - направленность, то есть злой умыслел) воздействия на ИС будут изменены какие-либо показатели, в результате чего будут предприняты какие-то действия, приводящие к ущербу, то такая ИС тоже должна считаться объектом КИИ. Иными словами, при категорировании надо думать не только о доступности ИС.
  4. Планы по изменению нормативных актов:
    • Будут изменены некоторые показатели в ПП-127 с целью уменьшения числа объектов КИИ, которых и так слишком много; даже при учете критичности процессов при категорировании. Например, изменят в сторону увеличения масштаб территории, которая может пострадать от направленного воздействия на объект КИИ.
    • Будут уменьшать число сведений, которые должны будут отправляться в ФСТЭК по результатам категорирования. Например, исключат сведения об уязвимостях, а некоторые сведения будут загрублять, чтобы процесс категорирования не превращался в пытку (например, в части составления перечня угроз).
    • Попробуют увеличить масштаб объектов КИИ, чтобы их число было не катастрофически большим. По озвученным оценкам ФСТЭК (странно, что это не было сделано при внесении законопроекта в Госдуму) в России насчитывается около 12000 субъектов КИИ (оценка примерная - было озвучено, что приславшие к моменту встречи перечни 590 субъектов - это 5-6% от их оценочного числа). Субъекты имеют, в среднем (по моей оценке озвученных ФСТЭК данных), около 40 объектов КИИ. Итого полмиллиона объектов КИИ - колоссальная работа для регулятора.
    • Пересмотрят экономические показатели, так как некоторые субъекты начинают манипулировать показателями с целью ухода от значимых объектов. И доказать "махинации" достаточно сложно.
    • Планируется ввести новую статью в КоАП, в дополнение к 13.12. Дело в том, что 13.12 наказывает только за нарушение обязательных требований по защите, но, например, за непредоставление перечня, за некатегорирование, за нарушение правил категорирования, за неотправку данных в ГосСОПКУ и пр. наказаний не предусмотрено. Этот пробел хотят устранить и повторить идею со статьей 13.11 КоАП по персональным данным. Наказывать по ней смогут и ФСТЭК, и ФСБ.
    • Планируют вернуть сроки составления перечня объектов КИИ, от которого будет отсчитываться год на само категорирование. Вариантов рассматривается два - или как было (перечень с последующим категорированием), или конкретный срок (например, конец 2019-го года), к которому надо завершить категорирование.
    • Новое ПП, которое планируют вносить в Правительство в первом квартале 2019-го года, обратной силы иметь не будет. То есть перекатегорировать ничего не надо будет. 
    • В приказах ФСТЭК планируют учесть обеспечение ИБ в холдинговых и интегрированных структурах.
  5. Наличие компенсирующих мер (например, резервирования) не является основанием для некатегорирования объекта и присвоения ему незначимой категории.
  6. Сеть электросвязи - это не объект КИИ.
  7. Водоканал - это... Все зависит от конкретной организации. Дело в том, что водоканал, как организация, занимающаяся водоснабжением и водоотведением, не относится к субъектам КИИ, так как такой сферы в ФЗ-187 нет (хотя в КСИИ была). А вот когда в Уставе конкретного ООО "что-тотамводоканал" написано про обслуживание электротехнических установок или про генерацию тепловой энергии (горячая вода и пар), то это уже сфера ТЭК со всеми вытекающими. Если вы введете в Google "водоканал устав", то найдете много готовых уставов различных водоканалов с различными целями существования организации, которые могут и попасть под действие ФЗ-187.
  8. ОМСУ - не является госорганом, а значит и не попадает в список субъектов КИИ. 
  9. Немного не в тему КИИ, но прозвучала интересная информация. Оказывается есть несколько решений судов, в которых признано, что информационные системы различных ГУПов и ФГУПов являются государственными, даже несмотря на то, что ГУП/ФГУП - это коммерческая структура. Продолжаю придерживаться позиции, озвученной мной в 2015 году, но с позицией судов спорить может только сам ГУП/ФГУП.
  10. Если удаленный доступ (в контексте приказа ФСТЭК) осуществляется с помощью VPN, то это не удаленный доступ, а локальный. Не самый логичный вывод, но зато снимает ряд проблем, связанных с привлечением для проведения регламентных работ сотрудников сторонних организаций.
  11. Сенсацию (для меня) я оставил на самый конец. Прозвучала позиция регулятора (я с ней не согласен), что если деятельность субъекта КИИ зависит от облака, в котором не только размещаются данные, но и ведется работа (как делают некоторые ЛПУ с облачными медицинскими ИС), то облако надо считать объектом КИИ этого субъекта! Как при этом получить информацию об уязвимостях, угрозах, мерах защиты и т.п., не совсем понятно. Рекомендация "договариваться" классная, но в реальной жизни не работает. Если логику ФСТЭК наложить на ДБО, которым пользуется нефтяная компания, которая из-за атаки на ДБО может недосчитаться денег на счете и недоплатит денег в бюджет, то получится, что ДБО банка - это объект КИИ нефтяной компании!!! Я посмотрю на попытки нефтяной компании получить информацию от банка об уязвимостях в ДБО, ее мерах защиты, модели угроз, списке допущенных лиц и другой достаточно критичной информации, требуемой для категорирования. Такая позиция ФСТЭК имеет далеко идущие и негативные последствия для многие субъектов, использующих услуги аутсорсеров.

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

ЗЫ. Да, кстати. Встреча началась с того, что Виталий Сергеевич Лютиков укорял некоторых экспертов, которые, выступая на публичных мероприятиях по КИИ, говорят не то, что говорит регулятор на своих мероприятиях, по сути перевирая слова ФСТЭК, что потом приводит к куче головной боли. В качестве примера было приведено высказывание одного из экспертов, который на большйо конференции высказал мысль, что перечени объектов КИИ надо направлять на имя Шевцова Дмитрия Николаевича, начальника 2-го Управления ФСТЭК. Это неверно! Так что стоит учитывать, что и я могу неверно трактовать те или иные высказывания регулятора :-) Но, надеюсь, если я местами не прав, мне старшие товарищи укажут на это. Отчасти именно поэтому ФСБ не практикует такие встречи - слишком много потом разгребать приходится :-) Не могу их винить за это, хотя открытость ФСТЭК мне импонирует больше.

ЗЗЫ. Также своим мнением о встрече поделились и коллеги:

Обзоры от Сергея Борисова и Валерия Комарова, надеюсь, появятся у них в блогах.

07.11.2018

Коммерческим SOCам нужна еще и лицензия ФСБ на шифрование

В сентябре я написал заметку о том, сколько лицензий нужно, чтобы подключиться к ГосСОПКА. А тут давеча, рассказывая про модель угроз и про то, что отсутствие у организации лицензии ФСБ на деятельность в области шифрования может также рассматриваться как угроза, я подумал, что у центра ГосСОПКИ, предоставляющего услугу подключения к ГосСОПКЕ должна же еще быть и еще одна лицензия ФСБ - на шифрование. И хотя дискуссия в Фейсбуке показала, что многим такая идея совсем не нравится, я все-таки решил повторить свои размышления в блоге. Во-первых, это повод задать вопрос своим корпоративным юристам. А, во-вторых, грядет SOC Forum, на котором этот вопрос можно задать регуляторам. Моя же логика была следующей:

  1. Согласно требованиям ФСТЭК, для оказания услуг по мониторингу ИБ (а это то, что в том числе делает центр ГосСОПКИ) в обязательном порядке необходимо иметь сертифицированные в ФСБ средства защиты каналов передачи данных, которые должны обеспечивать конфиденциальность данных, передаваемых между SOC и теми, кого этот SOC мониторит.
  2. В Facebook некоторые коллеги говорили, что на совещании в ФСТЭК, когда этот вопрос обсуждался, ФСТЭК заявила, что применение СКЗИ не является обязательным, а отдается на откуп лицензиату. Я, присутствуя на двух совещаниях ФСТЭК по этому вопросу, что-то не припомню такой позиции регулятора. Как раз наоборот. Он настаивал на том, что конфиденциальность должна быть обеспечена в обязательном порядке. А иначе зачем требовать покупку того, что можно и не использовать?
  3. Подход ФСТЭК по обязательному обеспечению конфиденциальности между системой управления и управляемыми решениями в последнее время становится все более жестким - в последних проектах РД на новые типы средств защиты, а также в ответах ФСТЭК на вопросы по смежным темам, явно сквозит требование по применению сертифицированных в ФСБ СКЗИ. Да и вообще, достаточно странно выглядит идея, что регулятор в области защиты информации не будет советовать обеспечивать защиту канала, в который может вмешаться злоумышленник.
  4. Подход ФСБ к наличию своей лицензии на деятельность в области шифрования известен уже много лет и он не меняется. ФСБ планомерно, а иногда излишне широко трактуя законодательство, требует либо поручать работы с СКЗИ лицензиатам, либо самим получать такую лицензию. Помнится ФСБ даже отвечала, что все, что было указано в Постановлении Правительства, независимо от возмездности оказания услуг и интересов (исключая один из видов работ, про который прямо сказано, что его для собственных нужд можно и без лицензии), требует лицензии ФСБ. С тех пор сменилось и само ПП (с 957-го на 313-е), и руководство ЦЛСЗ, а подход остается неизменным. Отсюда и мои выводы о необходимости лицензии ФСБ на шифрование.
Можно ли уйти от получения лицензии центром ГосСОПКИ? Если отталкиваться только от одного вида работ - оказание услуг в области шифрования, то можно было бы попробовать доказать, что никаких услуг в области шифрования SOC не оказывает. Но тут вступает в игру два нюанса. Во-первых, банки ФСБ активно плющила по ст.171 УК РФ (незаконное предпринимательство) именно по причине отсутствия лицензии при оказании услуг ДБО (а банк впрямую услуг по шифрованию не оказывал). А, во-вторых, кто-то же должен управлять ключами шифрования (а это тоже включается в деятельность в области шифрования). Если это делает сам SOC, то лицензия ФСБ нужна. Если это делает заказчик, то... такая схема вообще выглядит странно. Да и заказчик врядли захочет получать лицензию ФСБ в довесок к переходу к сервисной модели SOC. В ФБ активно предлагался вариант с привлечение УЦ для управления ключами между SOCом и его клиентами. Интересная идея, но вот я в нее что-то не верю. Во-первых, это удорожает решение и делает его более сложным (трехсторонний договор, а не двусторонний), а, во-вторых, учитывая происходящую вокруг УЦ ситуацию, стоило бы повременить.

Но помимо оказания услуг, у нас есть еще... создание SOC, то есть информационной системы с использованием шифровальных средств. А это тоже лицензируемый вид деятельности. А если SOC не только мониторит, но и управляет средствами защиты или обеспечивает удаленный сбор доказательств для расследования инцидентов и для этого заходит на удаленное оборудование с помощью SSH? Это ведь тоже лицензируемый вид деятельности :-) Шучу. Или не шучу?..

Что в итоге? Большинство текущих коммерческих SOCов не имеет лицензии ФСБ на деятельность в области шифрования и поэтому отстаивает позицию, что такая лицензия не нужна. Я их понимаю :-) Их вроде как спасает тот факт, что за шифрование у нас отвечает 8-й Центр ФСБ, который же "рулит" и ГосСОПКОЙ. Но за лицензирование у нас отвечает ЦЛСЗ, а у него не всегда взаимопонимание с другим управлением регулятора, ответственного за нацбезопасность. По крайней мере, когда представители 8-ки с открытой трибуны заявляли про собственные нужды, ЦЛСЗ говорил прямо противоположное. И я бы рассматривал этот риск - за 171-ю статью УК отвечают именно они, а не 8-й Центр. 

Клиентам коммерческого SOC вроде как ничего не угрожает - им лицензия ФСБ для выбора SOC не нужна (если ключами управляют не они). Но что делать, если к коммерческому SOC вдруг возникнут вопросы по лицензированию? Его деятельность могут приостановить! Риск это, конечно, маловероятный, но и сбрасывать со счетов его не стоит. В любом случае этот риск надо осознавать.

Запугал? Нет? Ну и прекрасно :-) А если да, то что делать; жизнь такая, непростая :-) 

06.11.2018

"Наша игра" про SOCи

В канун супостатского праздника Halloween компания "Авангард-Про", известная своими мероприятиями по ИБ, решила провести интеллектуальную игру для безопасников и пригласила меня в качестве ведущего, а также автора интеллектуальных вопросов.


Учитывая грядущий SOC Forum, я не стал долго думать и посвятил 61 вопрос игры именно этой теме. Первая половина вопросов далась достаточно легко, а вот над второй пришлось помучаться. Дело в том, что "Наша игра" подразумевает точные ответы на поставленные вопросы. Никакой отсебятины. Никаких размышлений, рассуждений и предположений. Одни голые факты. А это, в свою очередь, предполагает, что участники должны скорее больше "знать", чем "уметь". Опыт работы в SOC, умение выстраивать процессы, реагировать на инциденты и т.п., тут не помогут.


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


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


Тему следующей игры пока не придумал. Возможно это будет "Безопасность АСУ ТП", а может быть "Вредоносное ПО", а может быть "Хакеры", а может и вовсе "Регуляторы". Посмотрим ближе к делу. А пока жду фильма по итогам игры. Да-да, по аналогии с другими известными интеллектуальными играми, "Наша игра" тоже записывалась для ТВ. 15 ноября на канале BIS TV должен быть выложен профессионально смонтированный фильм по итогам игры.

ЗЫ. Если хотите поучаствовать в игре (в любом качестве - участник команды, зритель, спонсор и др.), то обращайтесь в медиа-группу Авангард.