4 года назад я уже как-то обращался к идее составления новогоднего обывательского чеклиста по безопасности. Решил обновить тот список и ориентировать его больше на специалистов по кибербезопасности, которые могут не только обезопасить себя, но и сделать окружающий мир чуточку лучше, следуя теории малых шагов. Затрачивая немного усилий в течение года, можно сделать себя, близких и друзей безопаснее, а коллегам показать пример. Выкладываю скриншот для тех, кто не сможет зайти на Slideshare и скачать файл в формате PDF (хотя обычный плагин в Хроме, даже не VPN, решает эту задачу элементарно).
28.12.18
17.12.18
Утечка из Marriott/Starwood или 10 ошибок при уведомлении об инциденте
30 ноября Marriott International анонсировала, что неизвестные хакеры (позже появилась информация, что следу ведут в Китай, в государственные шпионские структуры) смогли взломать систему резервирования сети отелей Starwood, принадлежащей Marriott, и в течение 4 лет (еще до поглощения сети Starwood сетью Marriott) смогли украсть данные около полумиллиарда постояльцев, что может обойтись компании в десятки миллиардов долларов потерь. Цифра эта взята не с потолка. Marriott пообещала компенсировать смену паспорта тем, чьи паспортные данные могли утечь, а это без малого 327 миллионов постояльцев. При стоимости замены паспорта в 100$ компенсация может составить около 30 миллиардов долларов. Стоимость акций Marriott за последние две недели упала с 122 до 104 долларов, что тоже не самым лучшим образом сказывается на финансовом положении Marriott, которая вынуждена расплачиваться за проблемы Starwood, которую взломали еще до слияния с Marriott (тут, кстати, встает вопрос качестве Due Dilligence и делался ли при покупке аудит безопасности).
Как частый путешественник я тоже пользовался сетью Starwood и допускаю, что мои данные тоже попали в список утекших. Точного ответа на этот вопрос у меня нет. Все, что я пока имею, это письмо от пострадавшей компании, в котором описан инцидент. Судя по нему, а также по специально созданному для этого инцидента сайту, компания, которая еще 8 сентября узнала об инциденте до сих пор не может понять, чьи данные пострадали, так как украденный массив данных был зашифрован и Marriott пытается его расшифровать, чтобы понять, что все-таки утекло (только ли контактная информация и номера кредитных карт или еще и данные по проживанию). Получил я уведомление об инциденте 12 декабря, спустя две недели после анонса со стороны Marriott. Понимаю, что отправить 500 миллионов сообщений - задача непростая, но, как клиент Marriott, мне бы хотелось, чтобы гостиничная сеть была более оперативной. Две недели неведения - не самое лучшее время.
А пока я жду хоть какой-то ясности, я решил составит перечень типовых ошибок, которые делают компании, которые сталкиваются с инцидентом ИБ. Кстати, эта тема хорошо ложится на тему штабных киберучений, в рамках которых можно прекрасно отработать навыки коммуникаций во время серьезного инцидента ИБ. Итак, на мой взгляд, перечень типовых ошибок выглядит следующим образом:
Как частый путешественник я тоже пользовался сетью Starwood и допускаю, что мои данные тоже попали в список утекших. Точного ответа на этот вопрос у меня нет. Все, что я пока имею, это письмо от пострадавшей компании, в котором описан инцидент. Судя по нему, а также по специально созданному для этого инцидента сайту, компания, которая еще 8 сентября узнала об инциденте до сих пор не может понять, чьи данные пострадали, так как украденный массив данных был зашифрован и Marriott пытается его расшифровать, чтобы понять, что все-таки утекло (только ли контактная информация и номера кредитных карт или еще и данные по проживанию). Получил я уведомление об инциденте 12 декабря, спустя две недели после анонса со стороны Marriott. Понимаю, что отправить 500 миллионов сообщений - задача непростая, но, как клиент Marriott, мне бы хотелось, чтобы гостиничная сеть была более оперативной. Две недели неведения - не самое лучшее время.
А пока я жду хоть какой-то ясности, я решил составит перечень типовых ошибок, которые делают компании, которые сталкиваются с инцидентом ИБ. Кстати, эта тема хорошо ложится на тему штабных киберучений, в рамках которых можно прекрасно отработать навыки коммуникаций во время серьезного инцидента ИБ. Итак, на мой взгляд, перечень типовых ошибок выглядит следующим образом:
- Скрытие инцидента. "Про то, что нас взломали, никто не узнает. Поэтому скроем это от всех". Это реально одно из самых типовых заблуждений, которое я нередко слышу во время киберучения или при встречах с заказчиками. Но, как показывает опыт, в последнее время с инцидентами сталкиваются все и поэтому глупо рассчитывать на то, что это удастся оставить в секрете. Вспоминая высказывание гендиректора Cisco Джона Чемберса (хотя это говорили многие): "Есть два типа компаний - те, кого уже взломали, и те, кто еще об этом не знает".
- Рассмотрение инцидента как ИТ-проблемы. "Это не проблема ИБ - это сбой в ИТ-системе". "Наш сайт не работает не из-за DDoS-атаки, а из-за блокировки Роскомнадзора". "У нас плановое обновление ПО". "У нас регламентные работы и поэтому система не позволяет переводить денежные средства". После скрытия инцидента, это вторая по популярности ошибка, которую допускают многие.
- Атака русских|китайских|иранских|северокорейских хакеров. Я не понимаю, чем это отмазка лучше других, но и она нередко звучит, когда надо переложить ответственность на кого-то, снимая ее с себя. Кто бы вас не атаковал, выстраивание системы защиты - это ваша обязанность и при моделировании угроз и нарушителей надо предусматривать такие вещи. Тем более, что используют и государственные, и обычные хакеры типовые методы. Миф о каких-то секретных знаниях "хакеров в погонах" сильно преувеличены, судя по всем обвинениям, которые сыпатся в последнее время против России, Китая, Северной Кореи или Ирана.
- Отсутствие плана. Самое худшее, чтобы понять как реагировать на инцидент, выяснять это во время инцидента. Когда проводятся киберучения - основная их задача - подготовиться к плохому и нештатному. И все это надо внести в план, в котором надо ответить на 4 ключевых вопроса - кто будет сообщать об инциденте, какую информацию, кому и когда. Клиенты? Подрядчики и партнеры? Правоохранительные органы? СМИ? Уполномоченные органы по защите прав субъектов ПДн (в письме Starwood указаны адреса всех европейских DPA, что является требованием GDPR, но, кстати, нет РКН)? Кто должен входить в команду, отвечающую за сообщение об инциденте? Маркетинг, PR, юристы…
- Преуменьшение инцидента. Не пытайтесь скрывать инцидент или вводить аудиторию в заблуждение. Мало того, что это не удастся, так это еще может быть и незаконно в разных странах мира (если у вас клиенты не только в России). Сокрытие может повлечь за собой дополнительные иски и ущерб репутации. Тот же Marriott поступил достаточно честно, сразу уточнив, что речь идет о 500 миллионов гостей Starwood. Да, это неприятно, но зато честно. А если бы они сообщили об утечек 50 миллионов и потом всплыли факты про еще 450 миллионов, то это было бы крайне негативно воспринято всеми. Можно попробовать заявить, что масштаб инцидента не понятен, но кто знает, как это обернется в будущем. Хотя тот же Facebook, когда у него утекло вроде как данные 50 миллионов учетных записей, заявил, что они не знают о реальном масштабе бедствия.
- Задержка с уведомлением. Equifax и Marriott сообщили об инциденте спустя два-три месяца с момента его обнаружения. Вообще затягивать с этим не стоит. Скорость и четкость при инциденте имеют важнейшее значение. Часто задержка связана с тем, что жертва просто не понимает, что у нее пострадало; она не знает свой бизнес, свою инфраструктуру; а инвентаризацию проводило очень давно. Иногда это происходит потому, что службы ИБ или ИТ тратит много времени на расследование, не сообщая об инциденте руководству компании и не следуя плану реагирования и уведомления (если план вообще есть). В любом случае любая задержка должна быть обоснована и обусловлена требованиями правоохранительных органов (если вы обращаетесь к ним) или иными юридическими требованиями. Понятно, что и бежать в тот же день раскрывать все карты не стоит - нужно собрать достаточно информации, чтобы не выглядеть попкой, непонимающим, что происходит. Кстати, с уведомлением тоже есть отдельные нюансы. Marriott о своем взломе сообщил 30-го ноября, а я получил от них письмо только 12-го декабря. С чем это может быть связано? Представьте, что вам надо направить 500 миллионов уведомлений! Вы же сразу попадете во всем спам-базы и вас будут блокировать все средства защиты. Поэтому надо либо отправлять небольшими порциями, либо договариваться с владельцами соответствующи сервисов, чтобы вас не блокировали на время массовой рассылки.
- Распространение слишком малого объема информации. Цель публичного уведомления об инциденте - не покаяться, а помочь клиентам защитить себя. Поэтому делитесь тем, что им поможет в этом. Если вас уведомили об инциденте, но не сказали, что делать, вы будете разочарованы. Marriott в своем письме предложил вот такой перечень (помимо контактов с DPA, правоохранителями, бесплатного доступа к WebWatcher /если вы гражданин США, Канады и Великобритании/ и компенсации замены паспорта):
- Распространение слишком большого объема информации. Мало информации - плохо. Много информации... Тоже плохо. Нужно найти баланс и раскрыть только то, что принесет пользу вам, вашим клиентам и акционерам. Не надо раскрывать то, что может навредить другим компаниям. Например, Equifax сразу раскрыла, что это кредитное бюро взломали через уязвимость в Apache Struts. Это заставило многих компаний понервничать, так как у них тоже была эта уязвимость и она не была устранена. Это давало хакерам преимущество. Вообще кейс с Equifax на сегодняшний день уже стал хрестоматийным - немалое количество отчетов на десятки страниц посвящено этой утечке. В разрабатываемом плане коммуникаций по результатам инцидентов надо указать, кому и в каком объеме должна быть представена информации. Понятно, что правоохранительным органам надо представить информации больше, чем для прессы. Клиентам нужны рекомендации по снижению ущерба, а агентству по расследованию инцидентов (Marriott, например, пригласил Kroll) эта информация без надобности.
- Невзаимодействие с правоохранительными органами. В России не так уж и принято взаимодействовать с органами внутренних дел в случае того или иного инцидента. Недоверие к полиции и неверие в ее компетентность приводят к тому, что все пытаются с инцидентами бороться самостоятельно (исключая те случаи, в которых может понадобиться решение суда). На Западе ситуация иная - поэтому там как раз рекомендуется активно взаимодействовать с правоохранительными органами. И они во многих случаях сами расскажут, что раскрывать, а что нет, чтобы не навредить следствию. У вас всего один шанс, показать, что вы сделали все, что нужно для защиты себя и своих клиентов. Обращение в правоохранительные органы (как и привлечение какой-либо известной компании для расследования) - хороший тон и демонстрация того, что вы ответственно действуете в соответствие с лучшими практиками.
- Отсутствие киберучений :-) Да, это не совсем связано с уведомлением об инциденте ИБ, но именно отсутствие киберучений часто приводит к тому, что описанные выше девять ошибок совершаются. В процессе имитации реальных кейсов проявляются все подводные камни и формируются пункты будущего плана реагирования на инциденты и плана коммуникаций в случае их наступления.
ЗЫ. Почти три года назад я уже обращался к теме коммуникаций с внешним миром. Правда, тогда, я проводил аналогии с допинговыми скандалами в российском спорте. И как показали прошедшие годы я был прав. Шарапова вернулась в спорт, а остальные участники, описанные в заметке, - похоже нет. Так что даже в случае с произошедшем инцидентов можно извлеь правильные уроки и повернуть историю себе во благо. Было бы желание.
13.12.18
Занимательная нумерология ИБ или как манипулировать статистикой
В курсе по измерению ИБ есть у меня раздел, который называется "Как врать с помощью цифр ИБ", название которого является аллюзией на известное высказывание Дизраэли, популяризованное Марком Твеном "Есть три вида лжи: ложь, наглая ложь и статистика". В этом разделе я привожу несколько манипуляций, которые позволяют сформировать определенное мнение относительно демонстрируемых цифр, имеющих отношение к ИБ.
Один из примеров касается понятия "среднеестатистическое". Большинство под этим термином понимает "среднее арифметическое", которым многие ИБ-компании и консультанты манипулируют. Например, вы встречаете в каком-нибудь отчете тезис, что средняя сумма инцидента ИБ составляет 11 миллионов рублей (цифра взята с потолка). Авторы отчета умалчивают, что они имели ввиду под средним, но чаще всего они, недолго думают, просто делят сумму по всем инцидентам на число инцидентов. Является ли это действительно средним? Увы. В данной ситуации средним должна быть медиана - именно она наиболее точно показывает среднестатическую компанию. Давайте проиллюстрирую. Представим, что у нас 10 компаний сообщили об инцидентах ИБ. У 9 компаний размер ущерба составил 1 миллион рублей, а у десятой - 100 миллионов рублей. Среднее арифметическое будет равно 10.9 миллионам, а вот медиана - одному миллиону. И именно медиана отражает реальную картину с размером ущерба (только если у всех ущерб одинаковый, то медиана будет равна среднему арифметическому).
Другой пример "манипуляции" (цифры-то все верные), изменение размерности графика. На примере ниже показан именно такой случай. Достаточно всего лишь изменить размер по оси ординат (Y) и у вас сразу меняется отношение к цифрам - вы начинаете думать, что у вас колоссальный рост атак произошел за месяц, хотя на самом деле это не так.
Отмечу, что тут нет "среднего". И размерностью никто не играл. И дело даже не в трактовке термина "атака" (вон, Лаборатория Касперского под атакой понимает просто срабатывание своего средства защиты). Тут иная манипуляция. При сравнении чего бы-то ни было с течение времени очень важно соблюсти неизменность объекта измерения. Было у меня 100 компьютеров, атаки на которые я мониторю. 100 должно быть и дальше. Иначе возникают вопросы. За два года мы видим колоссальный рост числа атак (на 2 порядка). С чем это связано? Стало действительно больше атак? Поменялось определение атаки? Мы стали лучше ловить? Увеличилось число контролируемых объектов? В случае с цифрами НКЦКИ вероятно имеют место все факторы сразу, но хотелось бы (лично мне, я понимаю, что журналистам в целом пофиг, а именно на них и направлены данные цифры) видеть методологию расчета. А то получится как у Лаборатории Касперского - срабатывание антивируса считается атакой. А может я пентест проводил? Или сканер запустил? Это тоже считается атакой?
И последняя манипуляция цифрами. "Ведомости", по отчету Лаборатории Касперского, напечатали статью, согласно которой хакерским атакам подверглась половина компьютеров российской промышленности. Все в панике и бегут срочно покупать средства защиты информации. Специалисты по ИБ справедливо критикуют эти цифры, которые не отражают действительности. А все дело в грамотном пиаре и нежелании журналистов разбираться в подоплеке цифр. Ведь ЛК прямо пишет, что атакованными она считает только то есть компьютеры, на которых сработали их средства защиты. При этом число таких инсталляций она не сообщает. Что в итоге? Срабатывание 5 миллионов антивирусов на 10 миллионах компьютеров - это половина! Срабатывание 1 антивируса на 2 компьютерах - это тоже половина! Бинго! А в материале "Ведомостей" звучит устрашающе и руководство компаний начинает задумываться о своей безопасности. А после пресс-конференции Мурашова у всех уже не возникает сомнений, что Россия в круге киберврагов и надо усиливать кибербезопасность страны и подключаться к ГосСОПКЕ.
Что в итоге? Есть цифры. И есть умение ими пользоваться и умение их читать. И надо понимать, что у тех, кто показывает цифры есть разные задачи, которые могут отличаться от задач читателей этих цифр. Если, читая разные отчеты, держать это в голове, воспринимать многие цифры будет гораздо проще :-)
11.12.18
Какой крест по ИБ вам нести на своих плечах?..
Тупил я вчера в пробке и родилась у меня интересная аналогия с тем, что сейчас происходит в области нехватки хороших специалистов по ИБ. Ну и отчасти вчерашняя заметка про кругозор безопасника тоже добавила парочку идей, которые я и решил выплеснуть на страницы блога.
Итак, выпускник по специальности ИБ, пришедший на реальную работу, схематически выглядит так. Желтым показаны его знания и навыки по ИБ, которые пока мало помогают ему в работе, мешая развиваться и мешая делать что-то полезное для нанявшего его бизнеса.
С течением времени специалист по ИБ накапливает новые знания в своей области, которые он использует в работе или которые лежат в пассиве, но могут быть применены по мере необходимости.
Обратите внимание. Этот специалист крутится в своем соку и не выходит за рамки текущих потребностей. Он не смотрит вперед и не смотрит назад - его заела рутина и на решение творческих задач он почти не способен. Зато он неплохой исполнитель чужих поручений. Иногда, даже дойдя до позиции руководителя того или иного уровня, безопасник остается на том же уровне знаний, что и в начале своего пути.
Если специалист, накапливая знания, нужные в текущей работе, обращается еще и к истории, которая открывает глаза на причины многих событий в нашей отрасли, то схематично его можно нарисовать так. Длина оранжевой стрелки означает глубину погружения в историю ИБ. В зависимости от роли безопасника эта стрелка может быть очень длинной или не очень, но она должна быть в любом случае. Жизнь "здесь и сейчас" интересна, но недолговечна :-(
Многие безопасники старой закалки, кстати, выглядят именно так. Неплохие знания текущей ситуации и багаж исторических знаний. Но полное отсутствие перспективы и понимания тенденций, которые сейчас очень активно влияют на ИБ. А вот молодежь выглядит иначе - неплохое понимание новомодных трендов и технологий, но полное отсутствие знания истории ИБ в России и, как следствие, непонимание происходящих процессов, их причин и следствий. Классический конфликт пиджаков и джинсов (или, как модно, худи :-)
Есть безопасники, находящиеся в центре креста, где их текущие знания ИБ дополняются знанием истории и пониманием тенденций. Надо признать, что таких безопасников немного, - предыдущий вариант встречается чаще - отрасль молодеет.
На самом деле многие молодые безопасники, особенно имеющие опыт программирования, а то и вовсе пришедшие из ИТ, схематично выглядят так (желтым по-прежнему показаны знания по ИБ, а коричневым - по ИТ):
Идеальный же безопасник выглядит так:
Он не только обладает широким кругозором в области ИБ, смотрит в будущее и не забывает оглядываться назад, но и имеет знания в широком круге смежных дисциплин - не только ИТ, но и психологии, социологии, экономике, финансах, маркетинге, юриспруденции и т.п.). Да, это непросто, но по-другому сегодня оставаться профессионалом и развиваться нельзя. Узкие знания нужны для специалистов, занимающихся администрированием средств защиты, но чем выше такой специалист метит, тем шире кругозор надо иметь.
Итак, выпускник по специальности ИБ, пришедший на реальную работу, схематически выглядит так. Желтым показаны его знания и навыки по ИБ, которые пока мало помогают ему в работе, мешая развиваться и мешая делать что-то полезное для нанявшего его бизнеса.
С течением времени специалист по ИБ накапливает новые знания в своей области, которые он использует в работе или которые лежат в пассиве, но могут быть применены по мере необходимости.
Обратите внимание. Этот специалист крутится в своем соку и не выходит за рамки текущих потребностей. Он не смотрит вперед и не смотрит назад - его заела рутина и на решение творческих задач он почти не способен. Зато он неплохой исполнитель чужих поручений. Иногда, даже дойдя до позиции руководителя того или иного уровня, безопасник остается на том же уровне знаний, что и в начале своего пути.
Если специалист, накапливая знания, нужные в текущей работе, обращается еще и к истории, которая открывает глаза на причины многих событий в нашей отрасли, то схематично его можно нарисовать так. Длина оранжевой стрелки означает глубину погружения в историю ИБ. В зависимости от роли безопасника эта стрелка может быть очень длинной или не очень, но она должна быть в любом случае. Жизнь "здесь и сейчас" интересна, но недолговечна :-(
Многие безопасники старой закалки, кстати, выглядят именно так. Неплохие знания текущей ситуации и багаж исторических знаний. Но полное отсутствие перспективы и понимания тенденций, которые сейчас очень активно влияют на ИБ. А вот молодежь выглядит иначе - неплохое понимание новомодных трендов и технологий, но полное отсутствие знания истории ИБ в России и, как следствие, непонимание происходящих процессов, их причин и следствий. Классический конфликт пиджаков и джинсов (или, как модно, худи :-)
Есть безопасники, находящиеся в центре креста, где их текущие знания ИБ дополняются знанием истории и пониманием тенденций. Надо признать, что таких безопасников немного, - предыдущий вариант встречается чаще - отрасль молодеет.
На самом деле многие молодые безопасники, особенно имеющие опыт программирования, а то и вовсе пришедшие из ИТ, схематично выглядят так (желтым по-прежнему показаны знания по ИБ, а коричневым - по ИТ):
Идеальный же безопасник выглядит так:
Он не только обладает широким кругозором в области ИБ, смотрит в будущее и не забывает оглядываться назад, но и имеет знания в широком круге смежных дисциплин - не только ИТ, но и психологии, социологии, экономике, финансах, маркетинге, юриспруденции и т.п.). Да, это непросто, но по-другому сегодня оставаться профессионалом и развиваться нельзя. Узкие знания нужны для специалистов, занимающихся администрированием средств защиты, но чем выше такой специалист метит, тем шире кругозор надо иметь.
Вот такая аллюзия родилась в пробке... Иногда это полезно; постоять, подумать... :-)
10.12.18
О киберучениях на SOC Forum
Свою презентацию с SOC Forum я уже выложил. Теперь пришел через поделиться впечатлениями по прошедшим киберучениям. В таком масштабе это был мой первый опыт. На том же сочинском "Коде ИБ. Профи" учения проводились также для 6 команд, но не было зрителей и мероприятие не было таким пафосным - с девушками, с флагами, с призами, и с жюри с представителями ФСТЭК, ФСБ, ЦБ. Поэтому немного давила атмосфера :-)
Сразу надо сказать, что что какой-то нехороший человек вбросил в отрасль мысль, что киберучения - это тоже самое, что и "Наша игра", которая прошла месяцем ранее SOC Forum и которая была посвящена SOCам. Единственное, что объединяло эти форматы, - наличие команд. Вот и все. На "Нашей игре" вы проверяете свой кругозор, а на киберучениях - имеющиеся навыки. Я, видимо, упустил этот момент и, как мне показалось, у многих сложилось изначально неверное представление о том, что такое киберучения. Поэтому и некоторые участники, и некоторые зрители в зале не получили того, за чем шли.
В отличие от сочинских учений, в этот раз я в кейсах погружался чуть глубже в технические детали, справедливо полагая, что на мероприятии будут люди, которые занимаются мониторингом в том или ином виде. Но ввиду краткости мероприятия (всего два часа с вводной частью и награждением), я кейсы сконцентрировал только на некоторых сервисах SOC.
Объясняя правила, я сразу уточнил, что в киберучениях не бывает неправильных ответов. В принципе! Задача киберучения высветить слабые места существующих процессов, чтобы в реальной работе их можно было устранить до того, как произойдет настоящий инцидент, который и покажет слабость. Но сейчас мне бы хотелось обратить внимание на несколько моментов, которые мне кажутся достаточно важными.
Во-первых, я слышал "претензию", что выбрав в качестве гипотетической организации банк, я сильно ограничил участников, дав одним преимущества (например, команде Сбербанка), а другим поставив палки в колеса. Мне возражали, что описанные кейсы не встречаются, например, в энергетике. Тут я должен не согласиться. Почти все кейсы универсальны. Да, я приводил кейс с утечкой данных кредитных карт, но его можно заменить на кражу любой другой защищаемой информации. Да, ФинЦЕРТ, рассылающий бюллетени об инцидентах, есть только у банков. Но у остальных есть ГосСОПКА. И т.д. Кроме того, иногда полезно выйти за рамки своей индустрии и попробовать себя на месте члена команды SOC в смежных областях.
Обратил внимание, что многие участники не рассматривают в качестве одного из источников угрозы третьи лица, например, подрядчиков, поставщиков и т.п. В ситуации №4 я использовал кейс с подменой скрипта JavaScript на сайте подрядчика, с которого скрипт и загружался. Поэтому попытка вычистить скрипт с сайта гипотетической организации ни к чему не приведет - возможны повторные заражения. Такой сценарий активно использовался группировкой Magecart, которая активно действует до сих пор. British Airways, взломанная в сентябре, вообще была атакована, по одной из версий, через CDN, а не через основной сайт авиакомпании, что отследить было достаточно нетривиальной задачей.
Вообще, у меня сложилось впечатление, что многие из участников не очень хорошо знакомы с кейсами последних нашумевших взломов, которые я брал за основу киберучений :-( Например, кейс с Equifax.
Еще одно наблюдение касалось сферы ответственности SOC. В запале участники команд пытались решать абсолютно все задачи, которые перед ними ставились. Даже то есть, которые не относятся к компетенции SOC. Например, вот этот кейс с запросом от DPA одной из европейских стран. Не SOCу с ним разбираться надо, а уполномоченным за GDPR в организации лицам. Хотя ответы и были в тему (что показывает, что многие разбирались с европейским законодательством по персданным), но все-таки у SOC четко очерченная сфера деятельности и брать на себя лишнее смысла нет. Тоже самое было и с делегированием ряда функций другим подразделениям гипотетической компании (тому же PR) - не все так просто, как описывали участники (хотя направление было правильным).
Так как в жюри этих киберучений были представители регуляторов, то я добавил парочку кейсов про НКЦКИ, ФинЦЕРТ и ФСТЭК. Например, вот такой. Было интересно послушать, как участники будут выкручиваться из этой ситуации :-)
Общее впечталение от учений высказал Дмитрий Кузнецов из Positive Technologies (он был участником одной из команд): "...участники не столько отыгрывали роль руководителя SOC, сколько демонстрировали свой кругозор ;)". Вот тут я согласен. Но отчасти это объясняется тем, что для многих участников киберучения - это забавное времяпрепровождение и возможность показать себя. Мало кто, пропускает кейсы через себя, свой опыт и свою организацию. Поэтому ответы звучат из серии "Мы должны...", а не "Я сделаю...". Ну и сам формат публичных киберучений тоже не подразумевает заточки под конкретную организацию, что размывает внимание аудитории, которая не видит в кейсах себя. В заметке про пять типовых ошибок в организации штабных киберучений я уже писал про это. Когда проводишь киберучения в конкретной организации и затачиваешь сценарий под нее, реакция немного иная.
Следующие штабные киберучения я планирую проводить (если все сложится успешно) на московском "Код ИБ. Профи" (28-31 марта) и CISO Forum (22-23 апреля). Разумеется, сценарии там будут иные, но формат тот же. Единственное, что там, я так думаю, не будет зрителей. Все-таки мероприятия платные и просто сидеть и смотреть на других, когда в соседних залах идут другие, интересные доклады, будут немногие.
ЗЫ. Кстати, следующий раунд "Нашей игры" пройдет 18-го декабря. Учитывая грядущее 20-е декабря, то есть день сотрудников госбезопасности, мы решили посвятить эту игру регуляторам. Но так как "Наша игра" направлена на расширение кругозора, то мы не будем концентрироваться только на отечественных структурах, регулирующих вопросы ИБ, но посмотрим и на зарубежные, имеющие отношение к кибербезопасности, включая и криптографию.
Сразу надо сказать, что что какой-то нехороший человек вбросил в отрасль мысль, что киберучения - это тоже самое, что и "Наша игра", которая прошла месяцем ранее SOC Forum и которая была посвящена SOCам. Единственное, что объединяло эти форматы, - наличие команд. Вот и все. На "Нашей игре" вы проверяете свой кругозор, а на киберучениях - имеющиеся навыки. Я, видимо, упустил этот момент и, как мне показалось, у многих сложилось изначально неверное представление о том, что такое киберучения. Поэтому и некоторые участники, и некоторые зрители в зале не получили того, за чем шли.
В отличие от сочинских учений, в этот раз я в кейсах погружался чуть глубже в технические детали, справедливо полагая, что на мероприятии будут люди, которые занимаются мониторингом в том или ином виде. Но ввиду краткости мероприятия (всего два часа с вводной частью и награждением), я кейсы сконцентрировал только на некоторых сервисах SOC.
Во-первых, я слышал "претензию", что выбрав в качестве гипотетической организации банк, я сильно ограничил участников, дав одним преимущества (например, команде Сбербанка), а другим поставив палки в колеса. Мне возражали, что описанные кейсы не встречаются, например, в энергетике. Тут я должен не согласиться. Почти все кейсы универсальны. Да, я приводил кейс с утечкой данных кредитных карт, но его можно заменить на кражу любой другой защищаемой информации. Да, ФинЦЕРТ, рассылающий бюллетени об инцидентах, есть только у банков. Но у остальных есть ГосСОПКА. И т.д. Кроме того, иногда полезно выйти за рамки своей индустрии и попробовать себя на месте члена команды SOC в смежных областях.
Обратил внимание, что многие участники не рассматривают в качестве одного из источников угрозы третьи лица, например, подрядчиков, поставщиков и т.п. В ситуации №4 я использовал кейс с подменой скрипта JavaScript на сайте подрядчика, с которого скрипт и загружался. Поэтому попытка вычистить скрипт с сайта гипотетической организации ни к чему не приведет - возможны повторные заражения. Такой сценарий активно использовался группировкой Magecart, которая активно действует до сих пор. British Airways, взломанная в сентябре, вообще была атакована, по одной из версий, через CDN, а не через основной сайт авиакомпании, что отследить было достаточно нетривиальной задачей.
Вообще, у меня сложилось впечатление, что многие из участников не очень хорошо знакомы с кейсами последних нашумевших взломов, которые я брал за основу киберучений :-( Например, кейс с Equifax.
Еще одно наблюдение касалось сферы ответственности SOC. В запале участники команд пытались решать абсолютно все задачи, которые перед ними ставились. Даже то есть, которые не относятся к компетенции SOC. Например, вот этот кейс с запросом от DPA одной из европейских стран. Не SOCу с ним разбираться надо, а уполномоченным за GDPR в организации лицам. Хотя ответы и были в тему (что показывает, что многие разбирались с европейским законодательством по персданным), но все-таки у SOC четко очерченная сфера деятельности и брать на себя лишнее смысла нет. Тоже самое было и с делегированием ряда функций другим подразделениям гипотетической компании (тому же PR) - не все так просто, как описывали участники (хотя направление было правильным).
Так как в жюри этих киберучений были представители регуляторов, то я добавил парочку кейсов про НКЦКИ, ФинЦЕРТ и ФСТЭК. Например, вот такой. Было интересно послушать, как участники будут выкручиваться из этой ситуации :-)
Общее впечталение от учений высказал Дмитрий Кузнецов из Positive Technologies (он был участником одной из команд): "...участники не столько отыгрывали роль руководителя SOC, сколько демонстрировали свой кругозор ;)". Вот тут я согласен. Но отчасти это объясняется тем, что для многих участников киберучения - это забавное времяпрепровождение и возможность показать себя. Мало кто, пропускает кейсы через себя, свой опыт и свою организацию. Поэтому ответы звучат из серии "Мы должны...", а не "Я сделаю...". Ну и сам формат публичных киберучений тоже не подразумевает заточки под конкретную организацию, что размывает внимание аудитории, которая не видит в кейсах себя. В заметке про пять типовых ошибок в организации штабных киберучений я уже писал про это. Когда проводишь киберучения в конкретной организации и затачиваешь сценарий под нее, реакция немного иная.
Следующие штабные киберучения я планирую проводить (если все сложится успешно) на московском "Код ИБ. Профи" (28-31 марта) и CISO Forum (22-23 апреля). Разумеется, сценарии там будут иные, но формат тот же. Единственное, что там, я так думаю, не будет зрителей. Все-таки мероприятия платные и просто сидеть и смотреть на других, когда в соседних залах идут другие, интересные доклады, будут немногие.
ЗЫ. Кстати, следующий раунд "Нашей игры" пройдет 18-го декабря. Учитывая грядущее 20-е декабря, то есть день сотрудников госбезопасности, мы решили посвятить эту игру регуляторам. Но так как "Наша игра" направлена на расширение кругозора, то мы не будем концентрироваться только на отечественных структурах, регулирующих вопросы ИБ, но посмотрим и на зарубежные, имеющие отношение к кибербезопасности, включая и криптографию.
5.12.18
DNS и искусственный интеллект на страже кибербезопасности (презентация)
По приглашению ICANN выступал на вчера с keynote на восточно-европейском DNS-форуме (впервые в России ICANN проводит мероприятие) с темой применения искусственного интеллекта для мониторинга и защиты DNS-инфраструктуры. Вроде получилось неплохо. Выкладываю презентацию, а видео можно посмотреть на самом сайте.
29.11.18
Почему аналитики L1 в SOC бесполезны? (презентация)
Вчера выступал на SOC Forum с дискуссионной темой о бесполезности первой линии SOC. Докладу предшествовала дискуссия в Facebook, где мне высказывали позицию, что автоматизация (а я предлагаю именно ее взамен слабому человеку) не может решить все проблемы и человек все равно нужен. Спор бесконечный и у каждого участника есть свои аргументы за его позицию. На моей стороне около сотни построенных нашей компанией SOCов по всему миру и накопленная база знаний, а также большое количество исследований в области создания ситуационных центров или, как их часто называют в англоязычной литературе, Control Room. У оппонентов какие-то свои доказательства. Рассудит, как обычно, жизнь. Пока же наличие SOCов, опирающихся на аналитиков L1, не дает каких-то прорывов в ИБ у их владельцев. Атаки, уязвимости, реализованные инциденты, нанесенный ущерб. А аналитики первой линии работают - мониторят, эскалируют, передают на вторую линию, заводят карточки инцидентов... Каждый выбирает для себя.
26.11.18
Безопасность - это не право, а привилегия
В четверг довелось мне в рамках RIW модерировать секцию "Выбор пользователя: полная анонимность или полное доверие - поиск "золотой середины" в рамках мини-конференции "Большие данные и приватность в интернете", которая изначально планировалась как площадка для дискуссии по теме Big Data. В процессе подготовки к мероприятию я столкнулся с интересной дилеммой - в мире Big Data - это в первую очередь технологии, а в России - законодательство. Отсюда и некоторая рассинхронизация в дискуссии, которая предсказуемо скатилась в обсуждение персональных/пользовательских данных. Одним из рассматриваемых кейсов я взял известную летнюю историю про индексацию Яндексом документов Google. У участников дискуссии я спросил: "Кто несет ответственность за то, что произошло?" и вот тут меня поджидал некоторый сюрприз.
Представители Яндекса и Group-IB высказали мысль, что спасение утопающих - дело рук самих утопающих, то есть виноват сам пользователь. Отчасти я, конечно, согласен с тем, что пользователи должны чуть более внимательно относиться к настройкам приватности того, что они выкладывают в Интернет. И касается это не только документов, но и профилей соцсетей, фотографий, переписок в мессенджерах и т.п. И вот тут в дискуссию вступил Георгий Грицай из АНО "Цифровая экономика", который высказал, показавшуюся мне сначала крамольной, мысль, что безопасность - это не право, а привилегия и ее надо заслужить или оплатить. Иными словами, Интернет-компании не обязаны тратить все свои силы на безопасность пользовательских данных, а пользователь будет сидеть и ничего не делать, ожидая, что провайдер Интернет-услуг все сделает за него. Конечно ничего не делать тоже можно, но тогда надо переложить всю ответственность на кого-то.
И вот тут мы подходим к интересной ситуации. Как-то для одной из презентаций я рисовал вот такую картинку, которая показывает градацию видов ИБ по масштабу ее действия - личная, корпоративная, национальная и международная.
Если немного отвлечься от нашей профессиональной деятельности и поставить себя на место рядового пользователя, то кто отвечает за нашу безопасность на улицах города? А в гражданской авиации? А от террористов? Государство! Мы справедливо полагаем, что национальная безопасность - это наше право и обязанность государства. Это вытекает из публичных правоотношений между нами и страной, гражданами которой мы являемся. Тут вроде все нормально и вопросов эта концепция не вызывает. А вот дальше наступает коллизия. Мы публичное право пытаемся натянуть на частные отношения пользователя и Интернет-компании. Мы по-прежнему считаем, что Интернет-компания должна нас защищать - от вредоносов, от утечки, от DDoS. И в этом кроется основная проблема. В случае права частного - безопасность перестает быть нашим правом, а является предметом договоренностей между сторонами договора (даже если это коллективный договор или договор-офферта).
Вспомните договора, заключаемые между юрлицами. Только за то, что в них написано, компании и отвечают. Есть там раздел по конфиденциальности? Выполняем требования по защите. Нет? Не выполняем. Произошла утечка данных - отвечаем только в случае нашей обязанности защищить данные, которые прописана в договоре. Все логично. Но эта же логика применима и к договорам между физлицом и юрлицом, но пользователь это не всегда понимает и транслирует обязанности государства на частные компании. Отчасти изменению этой логики мешает законодательство по персональным данным, которые превращает защиту ПДн в право гражданина (и обязанность оператора ПДн), а он начинает его распространять на все данные, а не только те, которые определены в ФЗ-152.
В итоге недовольство пользователей, которые считают, что им все должны и должны бесплатно, и недовольство компаний, которые не понимают, почему должны именно они и должны задаром. Ситуацию исправить могло бы принятие основ госполитики в области формировании культуры ИБ, которые готовились несколько лет назад, но увы. Пользователь по-прежнему будет считать, что защита его данных в Интернете - это не его обязанность, а Интернет-компаний.
Да, не стоит думать, что я считаю, что Интернет-компании ни в чем не виноваты и не должны предпринимать усилий по ИБ. Должны, но либо в рамках повышения своей репутации, либо договорных обязательств. А пользователям стоит чуть больше задумываться о собственной гигиене в Интернет.
ЗЫ. Презентация-подстрочник, как иллюстративный ряд к дискуссии на секции.
Представители Яндекса и Group-IB высказали мысль, что спасение утопающих - дело рук самих утопающих, то есть виноват сам пользователь. Отчасти я, конечно, согласен с тем, что пользователи должны чуть более внимательно относиться к настройкам приватности того, что они выкладывают в Интернет. И касается это не только документов, но и профилей соцсетей, фотографий, переписок в мессенджерах и т.п. И вот тут в дискуссию вступил Георгий Грицай из АНО "Цифровая экономика", который высказал, показавшуюся мне сначала крамольной, мысль, что безопасность - это не право, а привилегия и ее надо заслужить или оплатить. Иными словами, Интернет-компании не обязаны тратить все свои силы на безопасность пользовательских данных, а пользователь будет сидеть и ничего не делать, ожидая, что провайдер Интернет-услуг все сделает за него. Конечно ничего не делать тоже можно, но тогда надо переложить всю ответственность на кого-то.
И вот тут мы подходим к интересной ситуации. Как-то для одной из презентаций я рисовал вот такую картинку, которая показывает градацию видов ИБ по масштабу ее действия - личная, корпоративная, национальная и международная.
Если немного отвлечься от нашей профессиональной деятельности и поставить себя на место рядового пользователя, то кто отвечает за нашу безопасность на улицах города? А в гражданской авиации? А от террористов? Государство! Мы справедливо полагаем, что национальная безопасность - это наше право и обязанность государства. Это вытекает из публичных правоотношений между нами и страной, гражданами которой мы являемся. Тут вроде все нормально и вопросов эта концепция не вызывает. А вот дальше наступает коллизия. Мы публичное право пытаемся натянуть на частные отношения пользователя и Интернет-компании. Мы по-прежнему считаем, что Интернет-компания должна нас защищать - от вредоносов, от утечки, от DDoS. И в этом кроется основная проблема. В случае права частного - безопасность перестает быть нашим правом, а является предметом договоренностей между сторонами договора (даже если это коллективный договор или договор-офферта).
Вспомните договора, заключаемые между юрлицами. Только за то, что в них написано, компании и отвечают. Есть там раздел по конфиденциальности? Выполняем требования по защите. Нет? Не выполняем. Произошла утечка данных - отвечаем только в случае нашей обязанности защищить данные, которые прописана в договоре. Все логично. Но эта же логика применима и к договорам между физлицом и юрлицом, но пользователь это не всегда понимает и транслирует обязанности государства на частные компании. Отчасти изменению этой логики мешает законодательство по персональным данным, которые превращает защиту ПДн в право гражданина (и обязанность оператора ПДн), а он начинает его распространять на все данные, а не только те, которые определены в ФЗ-152.
В итоге недовольство пользователей, которые считают, что им все должны и должны бесплатно, и недовольство компаний, которые не понимают, почему должны именно они и должны задаром. Ситуацию исправить могло бы принятие основ госполитики в области формировании культуры ИБ, которые готовились несколько лет назад, но увы. Пользователь по-прежнему будет считать, что защита его данных в Интернете - это не его обязанность, а Интернет-компаний.
Да, не стоит думать, что я считаю, что Интернет-компании ни в чем не виноваты и не должны предпринимать усилий по ИБ. Должны, но либо в рамках повышения своей репутации, либо договорных обязательств. А пользователям стоит чуть больше задумываться о собственной гигиене в Интернет.
ЗЫ. Презентация-подстрочник, как иллюстративный ряд к дискуссии на секции.
22.11.18
Провожу киберучения вместе с ФСБ, ФСТЭК и ЦБ
Уже на следующей неделе в Москве пройдет SOC Forum, на который уже зарегистрировалось 2001 человек.. Насыщенная программа, активное участие основных регуляторов (ФСТЭК, ФСБ, ЦБ), общение... Я в этом году решил отойти от инноваций и посвятить свой доклад человеческому фактору в деятельности SOC. К сожалению, этому вопросу уделяют недостаточно внимания, пытаясь либо компенсировать отсутствие людей технологиями, либо принудить к переходу на аутсорсинг, который снимает остроту нехватки собственных квалифицированных специалистов по мониторингу. Однако в обоих случаях это попытка спрятать голову в песок.
У нас в компании накопилось достаточно фактов и цифр о людях, работающих в SOCах по всему миру, и пришло время этой информацией поделиться. Я буду выступать во второй день SOC Forum, в секции "Люди и процессы". Доклад свой я назвал достаточно дискуссионно - "Почему первая линия SOC бесполезна? Цифры и факты", но это неслучайно. Я попробую, опираясь на статистику, показать, почему уровень L1 в современном SOCе не только не нужен, но и вреден.
Попутно, раз уж буду говорить о людях и цифрах, покажу расчеты затрат на обучение специалистов SOC разных уровней (включая и ненужный L1 :-), а также приведу несколько разных расчетов по тому, сколько человек вам понадобится в SOCе при 8-ми, 10-ти и 12-тичасовой смене? Все это позволит более обоснованно подходить к вопросу формирования численности SOC, его бюджета и путей развития персонала.
А в конце второго дня, я вновь обращаюсь к теме киберучений, но уже не в виде доклада, а в виде реальных штабных игр, в рамках которых можно будет проверить свои навыки и знания в области мониторинга угроз и реагирования на них. В этот раз сценарий будет отличаться от десятка ранее проведенных учений чуть большей технической составляющей. Все-таки мероприятие заточено под SOC и поэтому сценарий можно также сфокусировать на этой теме.
Уже сформировано 6 команд, которые изъявили поучаствовать в этом интерактиве:
У нас в компании накопилось достаточно фактов и цифр о людях, работающих в SOCах по всему миру, и пришло время этой информацией поделиться. Я буду выступать во второй день SOC Forum, в секции "Люди и процессы". Доклад свой я назвал достаточно дискуссионно - "Почему первая линия SOC бесполезна? Цифры и факты", но это неслучайно. Я попробую, опираясь на статистику, показать, почему уровень L1 в современном SOCе не только не нужен, но и вреден.
Попутно, раз уж буду говорить о людях и цифрах, покажу расчеты затрат на обучение специалистов SOC разных уровней (включая и ненужный L1 :-), а также приведу несколько разных расчетов по тому, сколько человек вам понадобится в SOCе при 8-ми, 10-ти и 12-тичасовой смене? Все это позволит более обоснованно подходить к вопросу формирования численности SOC, его бюджета и путей развития персонала.
А в конце второго дня, я вновь обращаюсь к теме киберучений, но уже не в виде доклада, а в виде реальных штабных игр, в рамках которых можно будет проверить свои навыки и знания в области мониторинга угроз и реагирования на них. В этот раз сценарий будет отличаться от десятка ранее проведенных учений чуть большей технической составляющей. Все-таки мероприятие заточено под SOC и поэтому сценарий можно также сфокусировать на этой теме.
Уже сформировано 6 команд, которые изъявили поучаствовать в этом интерактиве:
- Сборная Сбербанка
- Сборная "Кибер Коммандос"
- Сборная Гринатома "DROP TABLE"
- Сборная ЗащитаИнфотранса "ЦКБ" (надеюсь, не центральная клиническая больница)
- Сборная "Steak Holders", которая уже выиграла недавно проведенную интеллектуальную "Нашу игру", посвященную SOCам
- Сборная RUSCADASEC
В жюри, помимо Алексея Качалина из Сбербанка, с которым мне уже доводилось проводить киберучения на последнем "Код ИБ. Профи" в Сочи, войдут представители регуляторов - ФСТЭК, ФСБ (НКЦКИ) и ЦБ (ФинЦЕРТ). Первый опыт у меня будет оценивать команды в таком составе. Посмотрим, что получится.
Приходите на SOC Forum, будет нескучно :-)
21.11.18
Устранение уязвимостей. Подход №2
Решил вернуться я к теме, поднятой неделю назад, относительно приоритезации устранения уязвимостей. Никита Ремезов в Фейсбуке справедливо заметил, что она ориентирована в первую очередь на госов и надо признать, что это так. К этой схеме он предложил добавить привязку к критичности сканируемых ресурсов для бизнеса. Да, и это тоже верно и контекстные метрики в CVSSv3 могут помочь это сделать. Преимуществом данной методики является ее простота. Чтобы ею воспользоваться не нужно ничего, кроме сканера безопасности, поддерживающего CVSS. Хотя даже он не нужен. Идентифицировать уязвимости можно либо путем анализа сетевого трафика
либо использованием средств защиты ПК, которые часто имеют такие возможности.
В последних двух случаях останется только выгрузить все данные об уязвимостях и провести их приоритезацию по описанной методике (это можно легко автоматизировать через обычный Excel).
Но что делать в крупных организациях, в которых десятки и сотни тысяч устройств. Даже если представить, что на каждом устройстве по одной уязвимости (а может быть и гораздо больше), то число строк в Excel станет неподъемным для анализа и составления списка дыр для устранения. Например, вот так выглядит картина всей сети Cisco, в которой насчитывает около полумиллиона устройств (200 тысяч пользовательских, около полусотни тысяч сетевых устройств, а также различные Интернет вещи).
Детализация карты сети сильно не улучшает ситуацию. Описанная в прошлой заметке методика не поможет в такой масштабной сети.
А надо ли это? Надо ли устранять все уязвимости? Даже те, у которых CVSS больше 6.5? А если попробовать пойти по иному пути и в scope работ по устранению уязвимостей включать не все, а только то, что может быть использовано извне? Вспомним историю с Equifax. Злоумышленники воспользовались уязвимостью на публичном Web-портале и через нее проникли во внутреннюю сеть бюро кредитных историй. Таких уязвимостей будет на порядки меньше и именно с них можно начинать устранение (по методике или без нее).
По сути речь идет о построении графа атак, который опирается на данные об уязвимостях, которые могут быть использованы для попадания из Интернет во внутреннюю сеть компании.
Интерес представляют только те уязвимости, которые позволяют путем многоходовой комбинации проникнуть внутрь. Именно их мы и будем устранять в первую очередь. Обратите внимание на иллюстрацию. Дыр внутри сети может очень много, но путь к ним всего один (отмечен красной линией). Устранив уязвимость в демилитаризованной зоне, мы получаем возможность существенно снизить плоскость будущей атаки, ограничив ее только ДМЗ.
Разумеется, для реализации данного подхода нам не обойтись уже только одним сканером . Придется использовать специализированные решения по построению векторов атак (у Cisco их нет - это не реклама :-), которые, анализируя настройки текущей инфраструктуры (сетевого оборудования и средств защиты), увязывают их с уязвимостями, и показывают масштаб будущих проблем. Для одной из точек выхода в Интернет в Cisco это выглядит так.
Список уязвимостей, идентифицируемых NGFW |
Список уязвимостей, найденных на защищенных EDR узле |
Но что делать в крупных организациях, в которых десятки и сотни тысяч устройств. Даже если представить, что на каждом устройстве по одной уязвимости (а может быть и гораздо больше), то число строк в Excel станет неподъемным для анализа и составления списка дыр для устранения. Например, вот так выглядит картина всей сети Cisco, в которой насчитывает около полумиллиона устройств (200 тысяч пользовательских, около полусотни тысяч сетевых устройств, а также различные Интернет вещи).
Детализация карты сети сильно не улучшает ситуацию. Описанная в прошлой заметке методика не поможет в такой масштабной сети.
А надо ли это? Надо ли устранять все уязвимости? Даже те, у которых CVSS больше 6.5? А если попробовать пойти по иному пути и в scope работ по устранению уязвимостей включать не все, а только то, что может быть использовано извне? Вспомним историю с Equifax. Злоумышленники воспользовались уязвимостью на публичном Web-портале и через нее проникли во внутреннюю сеть бюро кредитных историй. Таких уязвимостей будет на порядки меньше и именно с них можно начинать устранение (по методике или без нее).
Но даже это число уязвимостей может быть еще больше сокращено, если привязать дыры к векторам атаки, то есть проанализировать возможные пути, которыми злоумышленники могут воспользоваться для проникновения внутрь.
По сути речь идет о построении графа атак, который опирается на данные об уязвимостях, которые могут быть использованы для попадания из Интернет во внутреннюю сеть компании.
Интерес представляют только те уязвимости, которые позволяют путем многоходовой комбинации проникнуть внутрь. Именно их мы и будем устранять в первую очередь. Обратите внимание на иллюстрацию. Дыр внутри сети может очень много, но путь к ним всего один (отмечен красной линией). Устранив уязвимость в демилитаризованной зоне, мы получаем возможность существенно снизить плоскость будущей атаки, ограничив ее только ДМЗ.
Разумеется, для реализации данного подхода нам не обойтись уже только одним сканером . Придется использовать специализированные решения по построению векторов атак (у Cisco их нет - это не реклама :-), которые, анализируя настройки текущей инфраструктуры (сетевого оборудования и средств защиты), увязывают их с уязвимостями, и показывают масштаб будущих проблем. Для одной из точек выхода в Интернет в Cisco это выглядит так.
Методика из прошлой заметки дешева и не требует дополнительных затрат, но плохо работает в крупных инфраструктурах. Подход, описанный сегодня, более практичен, но и требует больших ресурсов / усилий по реализации. Зато полностью автоматизирован. Однако у него есть и еще один недостаток. Он предполагает, что мы не имеем других способов проникновения в корпоративную сеть или можем их минимизировать. Однако, если в сети есть незащищенный Wi-Fi, пользователи падки на подброшенные флешки, а руководство может безконтрольно приносить свои домашние ноутбуки и подключать их к внутренней сети, то второй подход может создать ложное чувство защищенности. Ищите баланс...
16.11.18
Видео "Нашей игры" по SOCам
Вот и подоспело видео с "Нашей игры", посвященной SOCам, которая прошла пару недель назад. Задорненько получилось. Респект операторам и монтажерам :-)
А мы уже во всю готовимся ко второй игре, которая пройдет уже в конце декабря. И хотя на сайте игры информации по ней еще нет, но отправить заявку на участие уже можно.
А мы уже во всю готовимся ко второй игре, которая пройдет уже в конце декабря. И хотя на сайте игры информации по ней еще нет, но отправить заявку на участие уже можно.
15.11.18
Меня окружали милые, симпатичные люди, медленно сжимая кольцо... или токсичность российских специалистов по ИБ
Только выезжая заграницу, на какое-либо мероприятие по ИБ, понимаешь, насколько наш российский междусобойчик отличается от всего того, что происходит за его пределами. И дело не в том, какие темы обсуждаются на конференциях "здесь" и "там", а в том, как воспринимают Россию в киберпространстве "здесь" и "там". Я уже писал, что американцы раздувают киберугрозу со стороны нашей страны, рисуя из нас образ врага и обвиняя во взломах всего "что движется".
У российских специалистов эта тема вызывает лишь улыбку - никаких серьезных доказательств не представлено, а те, что опубликованы в докладе Мюллера, докладах американской разведки, в исследованиях американских ИБ-компаний, рассматриваются с точки зрения нечестных методов геополитической борьбы, в которых все методы хороши, лишь бы удержаться на вершине геополитического Олимпа. Ну действительно, можно ли всерьез рассматривать в качестве доказательства использование в атаках российских IP-адресов, московский часовой пояс и имя "Феликс Эдмундович" в коде найденных вредоносных программ? Смешно. Но в последнее время уровень представленных доказательств изменился. В ход пошли такие факты, которые сложно выявить чисто техническими мероприятиями - ФИО, должности, звания, места дислокации, номера в/ч и т.п. Все это говорит либо о том, что у американцев и их партнеров есть и оперативная информация о том, что и кто осуществляет различные действия в киберпространстве от имени России, либо об усилении дезинформации западного общества и приведении якобы неубиенных фактов, которые должны лишний раз доказать вину России.
Лично я не знаю, какая из этих версий более реалистична (вполне возможно, что обе). Только я вижу что:
У российских специалистов эта тема вызывает лишь улыбку - никаких серьезных доказательств не представлено, а те, что опубликованы в докладе Мюллера, докладах американской разведки, в исследованиях американских ИБ-компаний, рассматриваются с точки зрения нечестных методов геополитической борьбы, в которых все методы хороши, лишь бы удержаться на вершине геополитического Олимпа. Ну действительно, можно ли всерьез рассматривать в качестве доказательства использование в атаках российских IP-адресов, московский часовой пояс и имя "Феликс Эдмундович" в коде найденных вредоносных программ? Смешно. Но в последнее время уровень представленных доказательств изменился. В ход пошли такие факты, которые сложно выявить чисто техническими мероприятиями - ФИО, должности, звания, места дислокации, номера в/ч и т.п. Все это говорит либо о том, что у американцев и их партнеров есть и оперативная информация о том, что и кто осуществляет различные действия в киберпространстве от имени России, либо об усилении дезинформации западного общества и приведении якобы неубиенных фактов, которые должны лишний раз доказать вину России.
Лично я не знаю, какая из этих версий более реалистична (вполне возможно, что обе). Только я вижу что:
- уровень атрибуции и представляемых доказательств становится очень высоким
- многие коллеги из американских компаний по ИБ говорят в частных беседах, что публикуемые доказательства - это только верхушка айсберга и на самом деле под NDA находится гораздо больше фактов
- эти обвинения сильно мешают как российским ИБ-компаниям так и самим специалистам по ИБ, вынужденным скрывать свое происхождение при выходе/выезде зарубеж.
На прошедших осенью "Подмосковных вечерах" клуба топ-менеджеров 4CIO как-то само собой зашел разговор о будущем, о работе заграницей и о том, что айтишники стали возвращаться, так как в условиях текущей геополитики стало сложно работать зарубежом. А я стал примерять эти рассуждения на безопасников и картинка тоже не самая радостная. Быть российским специалистом (и компанией) по ИБ (включая и многие страны СНГ, как это не парадоксально) стало очень токсичным. За последние 2,5 года, с момента когда я написал заметку про то, как американцы раздувают угрозу из России, ситуация стала гораздо хуже. Вот только некоторые проявления с которыми сталкиваются многие:
- Нет доступа к сайтам, если пытаться подключаться из России.
- Некоторые госорганы начинают блокировать доступ к себе, если он идет со стороны нероссийских IP-адресов.
- Ярлык "русские хакеры" прочно укрепился в мире и "там" он несет вполне негативную конотацию, в отличие от России, где это не более чем забавный термин, который, по мнению многих, не подкреплен никакими доказательствами.
- Российские компании по ИБ попадают в санкционные списки, что мешает им вести бизнес не только на Западе (или Востоке), но и в России (крупные заказчики начинают снижать свою активность по работе с такими "токсичными" компаниями). По ряду направлений разрываются партнерские отношения, которые длились годами.
- Против иностранных (читай, американских) компаний в России вводятся ограничения, которые снижают проникновение инновационных технологий и отбрасывают российских заказчиков назад.
- На Интернет начинаются гонения, а запретительная стратегия набирает все большие обороты. Балканизация Рунета не за горами.
- Запрет на передачу исходников и снижение числа сертифицированных зарубежных ИБ-решений, приводящие к отсутствию свободы маневра при выстраивании долгосрочной и среднесрочной стратегии ИБ на предприятии.
- В риторике западных стран (Европа и Северная Америка) все чаще начинает проскальзывать идея симметричного ответа на российскую киберагрессию, а учитывая, что российский ИТ-рынок построен преимущественно на западных технологиях, то градус недоверия растет.
Самое главное, пожалуй, что вытекает из этой ситуации, - это неопределенность, которая снижаться в обозримом будущем не будет. Мы все большо отдаляемся от прогрессивного мира соседей и закукливаемся в себе. С практической точки зрения это ставит перед почти любым специалистов по ИБ ряд вопросов, которые из теоретических перерастают во вполне практические:
- Готов ли я строить систему ИБ своей организации на решениях, происходящих из стран - геополитических противников? Если нет, то какова альтернатива? Если да, то каковы пути отхода, если с этими решения что-то "вдруг" произойдет?
- Если в качестве альтернативы мы рассматриваем Китай, то где гарантии безопасности со стороны этого "союзника" (союзником, кстати, его называет только Россия, - Китай по отношению к нам это слово не использует никогда)?
- Готов ли я к тому, что российские компании, решения которых я выбрал для своей системы ИБ, будут внесены в санкционные списки и я могу столкнуться с риском вторичных санкций?
- Готов ли я к атакам со стороны не только киберпреступников, но и целых государств и их спецслужб (если я интересен для них)?
- Готов ли я к отключению Рунета от всемирной Сети? Можно и в более легкой форме задать этот вопрос. Что я буду делать в случае учащения случаев блокировок иностранных IP-адресов (актуально для активных пользователей XaaS-платформ)?
Не хотелось бы, чтобы эта заметка рассматривалась как пессимистичный взгляд в будущее и разговор в стиле "все пропало". Безопасность - это в первую очередь управление рисками (в том числе и их принятие). Просто сейчас, некоторые, ранее чисто теоретические риски, становятся более приоритетными и их уже нельзя сбрасывать со счетов.
14.11.18
Устранять или нет? Вот в чем вопрос!
Malotavr, который недавно вновь вернулся в эпистолярный жанр по ИБ, обратил свое пристальное внимание на тему управления уязвимостями (тут и тут). И это немудрено, учитывая место его работы - компанию Positive Technologies. Так сложилось, что и я недавно погрузился в эту тему, задавшись достаточно простым, на первый взгляд, вопросом - как приоритезировать уязвимости, которые надо устранять? Их могут тысячи и даже сотни тысяч в крупной инфраструктуре. Вариант "устранять все" в реальной жизни не работает. Пока мы устраняем одни уязвимости (в каком порядке? по времени? по критичности узла? по критичности уязвимости?), злоумышленники могут воспользоваться другими. Устраняя "другие", злоумышленники могут воспользоваться третьими. И так далее. Где провести ту грань, за которой уязвимость может быть отложена "на потом"?
Задавшись этим вопросом, я, случайно или нет, наткнулся на интересное исследование, в котором был проведен анализ списка CVE корпорации MITRE. Из 120 тысяч CVE были отброшены зарезервированные, отброшенные или еще обсуждаемые уязвимости - осталось 94457 дыр, по которым исследователи анализировали наличие эксплойта, в том числе и находящегося в диком виде. По результатам исследования были сделаны следующие выводы:
Понятно, что существуют уязвимости, которые не публикуются до их использования, но бороться с такой напастью почти невозможно. Поэтому стоит сконцентрироваться в первую очередь на том, что нам известно. Поэтому родилась некоторая блок-схема процесса приоритезации уязвимостей, которые требуют устранения. Она, безусловно, неидеальна, но хоть как-то выстраивает процесс устранения уязвимостей.
В ней я отталкиваюсь в первую очередь от общего рейтинга CVSS; затем смотрю на наличие эксплойта (либо из Банка данных уязвмостей ФСТЭК, либо из CVSS); потом на наличие удаленной эксплуатации дыры (параметр AV в CVSS), и, наконец, на сложность получения доступа (параметр AC в CVSS). Все значения берутся из полей БДУ. В реальной жизни для проверки наличия эксплойта и подтверждения CVSS обычно используются перекрестные базы (NVD, Secunia, ExploitDB, Cisco, Vulners и т.п.), но для ряда пользователей, особенно государственных, использовать зарубежные БД было бы не совсем правильно. К сожалению, наполнение БДУ пока не идеально (особенно в части оперативной информации по наличию эксплойтов), но другой возможности у госов нет (хотя тот же Vulners имеет российские корни, но "не признан" регулятором).
В итоге выстраивается приоритезация уязвимостей. Устраняются они исходя из наличия патчей или иных мер по устранению, включая компенсирующие. Если мер нет, то повторно проверяем через 2 недели (по статистике за 2 недели для большинства уязвимостей разрабатывается эксплойт). Если за месяц уязвимость не устранили, то начинается бессмысленное общение с разработчиком (госам проще - они могут пожаловаться во ФСТЭК для воздействия на разработчика) с попутной разработкой более эффективных компенсирующих мер. Если устранены все приоритетные уязвимости, то начинаем устранять неприоритетные. Ситуация, когда уязвимость не устраняется, отсутствует в принципе. Но процесс зациклен вокруг приоритетных уязвимостей в первую очередь, которые и представляют максимальную опасность.
Понятно, что у схемы есть и свои ограничения. Например, мы отсекаем локальные уязвимости без эксплойта с CVSS ниже 6.5, которые могут быть использованы злоумышленником, имеющим физический доступ к объекту защиты. Но тут я исхожу из предположения, что потребитель все-таки имеет хоть какие-то меры по контролю физического доступа, усложняющие эксплуатацию локальной уязвимости (хотя риск инсайдера остается). Также за двухнедельный временной зазор может быть разработан эксплойт и система может быть взломана. Можно попробовать уменьшить этот срок, но тогда мы слишком часто будем запускать цикл проверки, что для многих систем, особенно ГИС/МИС, будет непросто. Также я исхожу из того, что при отсутствии мер защиты безопасники все-таки смогут разработать компенсирующие меры (отключить уязвимую систему от сети, заменить уязвимое устройство, установить «виртуальный патч», зарезервировать систему, заблокировать использование уязвимости с помощью МСЭ или IDS и т.п.). Если нет, то тут уже ничего сделать нельзя :-(
Вот такие размышления. Они не идеальны и не дают стопроцентной гарантии устранения всех уязвимостей, которые могут быть использованы злоумышленниками. Но с чего-то надо начинать?.. Может кому-то эта схема покажется интересной и полезной в работе.
Задавшись этим вопросом, я, случайно или нет, наткнулся на интересное исследование, в котором был проведен анализ списка 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.18
ФЗ коряв, но он ФЗ. Его изменят, но когда, ХЗ!
В пятницу ряд доблестных блогеров, активно, но не всегда верно, пишущих о различных законодательных инициативах и особенно о ФЗ-187, были приглашены на профилактическую, ой, беседу, целью которой было ознакомить блогерскую общественность со взглядами регулятора на безопасность критической инфраструктуры. За месяц до этого, через блогеров было собрано более 150 предельно конкретных вопросов, ответы на которые интересовали субъектов КИИ, а также интеграторов, оказывающих услуги в сфере, регулируемой ФЗ-187. Встреча состоялась, но ее результаты немного отличались от первоначальных ожиданий.
Судя по времени, которое регулятор взял на анализ вопросов, я считал, что будут даны ответы на все 150+ из них и уже даже заготовил бутерброды с горячим чаем и предупредил семью, что могу вернуться заполночь. Но увы... ФСТЭК, числом 4 человека, во главе с Виталием Сергеевичем Лютиковым, поделилась своим видением происходящего и будущего, а также обрисовала свое видение ключевых вопросов, касающихся защиты информации в КИИ. При этом ФСТЭК сразу предупредила, что и взгляд может быть и неправильным. Хотя учитывая, что именно они регулятор, даже неправильный взгляд стоит учитывать. РКН, вон, тоже многие вещи трактует неправильно, но это не мешает ему осуществлять надзорную деятельность в соответствие с этими неверными (на мой взгляд) трактовками. Так и со ФСТЭК. Второй важный момент, прозвучавший на встрече, все, что делает ФСБ - не может быть предметом обсуждения, независимо от того, правильно это или нет, согласен с этим регулятор или нет. В чужие дела ФСТЭК не лезет, занимась только своей зоной ответственности. Уже после встречи у нас возникла мысль, что может быть и ФСБ/НКЦКИ соберет блогеров на такое неформальное общение. Хотя я в это верю с трудом. Тот же malotavr уже делился тем, что ФСБ собирает экспертов для обсуждения, но круг этих экспертов явно иной, чемходоки блогеры, ходившие в ФСТЭК.
Однако, несмотря, на несбывшиеся ожидания от встречи, все-таки на ней прозвучало несколько, местами очень революционных идей, которые я посчитал нужным осветить. Вообще, основная идея встречи для ФСТЭК заключалась в более широком освещении темы безопасности КИИ, так как сам регулятор не всегда может достучаться до всех, а информационные письма готовить не всегда удобно и возможно. Да и аудитория у приглашенных блогеров будет, наверное, поболее, чем у ФСТЭК, о чем регулятор не преминул напомнить на встрече. Поэтому участники встречи со стороны общественности стали этаким рупором, которой должен был донести до всех интересующихся подходы и взгляды регулятора. Итак, тезисно:
Вот таков краткий перечень озвученных регулятором на встрече блогеров вопросов. Да, не совсем то, что ожидалось, но сам факт встречи можно только приветствовать. Нечасто регуляторы у нас идут на контакт и готовы делиться своей позицией с широкой общественностью. Тут можно сказать ФСТЭК только спасибо. Что касается оставшихся вопросов, то мы договорились, что из 150 вопросов будут выбраны наиболее важные и регулятор попробует на них ответить на следующей встрече, которая состоится в обозримом будущем (регулятор готов к этому).
ЗЫ. Да, кстати. Встреча началась с того, что Виталий Сергеевич Лютиков укорял некоторых экспертов, которые, выступая на публичных мероприятиях по КИИ, говорят не то, что говорит регулятор на своих мероприятиях, по сути перевирая слова ФСТЭК, что потом приводит к куче головной боли. В качестве примера было приведено высказывание одного из экспертов, который на большйо конференции высказал мысль, что перечени объектов КИИ надо направлять на имя Шевцова Дмитрия Николаевича, начальника 2-го Управления ФСТЭК. Это неверно! Так что стоит учитывать, что и я могу неверно трактовать те или иные высказывания регулятора :-) Но, надеюсь, если я местами не прав, мне старшие товарищи укажут на это. Отчасти именно поэтому ФСБ не практикует такие встречи - слишком много потом разгребать приходится :-) Не могу их винить за это, хотя открытость ФСТЭК мне импонирует больше.
ЗЗЫ. Также своим мнением о встрече поделились и коллеги:
Алексей Лукацкий, Сергей Борисов, Александр Кузнецов, Алексей Комаров, Валерий Комаров (они с Алексеем не братья), Павел Луцик |
Судя по времени, которое регулятор взял на анализ вопросов, я считал, что будут даны ответы на все 150+ из них и уже даже заготовил бутерброды с горячим чаем и предупредил семью, что могу вернуться заполночь. Но увы... ФСТЭК, числом 4 человека, во главе с Виталием Сергеевичем Лютиковым, поделилась своим видением происходящего и будущего, а также обрисовала свое видение ключевых вопросов, касающихся защиты информации в КИИ. При этом ФСТЭК сразу предупредила, что и взгляд может быть и неправильным. Хотя учитывая, что именно они регулятор, даже неправильный взгляд стоит учитывать. РКН, вон, тоже многие вещи трактует неправильно, но это не мешает ему осуществлять надзорную деятельность в соответствие с этими неверными (на мой взгляд) трактовками. Так и со ФСТЭК. Второй важный момент, прозвучавший на встрече, все, что делает ФСБ - не может быть предметом обсуждения, независимо от того, правильно это или нет, согласен с этим регулятор или нет. В чужие дела ФСТЭК не лезет, занимась только своей зоной ответственности. Уже после встречи у нас возникла мысль, что может быть и ФСБ/НКЦКИ соберет блогеров на такое неформальное общение. Хотя я в это верю с трудом. Тот же malotavr уже делился тем, что ФСБ собирает экспертов для обсуждения, но круг этих экспертов явно иной, чем
Однако, несмотря, на несбывшиеся ожидания от встречи, все-таки на ней прозвучало несколько, местами очень революционных идей, которые я посчитал нужным осветить. Вообще, основная идея встречи для ФСТЭК заключалась в более широком освещении темы безопасности КИИ, так как сам регулятор не всегда может достучаться до всех, а информационные письма готовить не всегда удобно и возможно. Да и аудитория у приглашенных блогеров будет, наверное, поболее, чем у ФСТЭК, о чем регулятор не преминул напомнить на встрече. Поэтому участники встречи со стороны общественности стали этаким рупором, которой должен был донести до всех интересующихся подходы и взгляды регулятора. Итак, тезисно:
- "ФЗ коряв, но он ФЗ". Это общая мысль к тексту ФЗ-187, который содержит немалое количество ляпов, в том числе и терминологических. Но общее мнение регуляторов, законодателей и приближенных к ним - менять ФЗ сейчас неразумно. Должно пройти минимум года два, прежде чем об этом всерьез задумаются. Поэтому ни изменения понятия "объект КИИ", ни понятия "субъект КИИ", ни перечня сфер деятельности не будет в ближайшее время.
- Подход к определению объектов КИИ от критичности процессов, которые ИС обслуживает, останется неизменным. И его поддерживает и ФСБ в том числе. Поэтому разночтений с тем, считать объектом КИИ то, что написано в ФЗ-187 или в ПП-127, у регуляторов нет.
- Позиция некоторых субъектов, считающих, что если они могут перейти на ручной режим работы, то у них нет значимых, и вообще объектов КИИ, не является верной. Важна не только доступность ИС, но и ее влияние на критический процесс. Если в результате направленного (и этот момент достаточно важен - направленность, то есть злой умыслел) воздействия на ИС будут изменены какие-либо показатели, в результате чего будут предприняты какие-то действия, приводящие к ущербу, то такая ИС тоже должна считаться объектом КИИ. Иными словами, при категорировании надо думать не только о доступности ИС.
- Планы по изменению нормативных актов:
- Будут изменены некоторые показатели в ПП-127 с целью уменьшения числа объектов КИИ, которых и так слишком много; даже при учете критичности процессов при категорировании. Например, изменят в сторону увеличения масштаб территории, которая может пострадать от направленного воздействия на объект КИИ.
- Будут уменьшать число сведений, которые должны будут отправляться в ФСТЭК по результатам категорирования. Например, исключат сведения об уязвимостях, а некоторые сведения будут загрублять, чтобы процесс категорирования не превращался в пытку (например, в части составления перечня угроз).
- Попробуют увеличить масштаб объектов КИИ, чтобы их число было не катастрофически большим. По озвученным оценкам ФСТЭК (странно, что это не было сделано при внесении законопроекта в Госдуму) в России насчитывается около 12000 субъектов КИИ (оценка примерная - было озвучено, что приславшие к моменту встречи перечни 590 субъектов - это 5-6% от их оценочного числа). Субъекты имеют, в среднем (по моей оценке озвученных ФСТЭК данных), около 40 объектов КИИ. Итого полмиллиона объектов КИИ - колоссальная работа для регулятора.
- Пересмотрят экономические показатели, так как некоторые субъекты начинают манипулировать показателями с целью ухода от значимых объектов. И доказать "махинации" достаточно сложно.
- Планируется ввести новую статью в КоАП, в дополнение к 13.12. Дело в том, что 13.12 наказывает только за нарушение обязательных требований по защите, но, например, за непредоставление перечня, за некатегорирование, за нарушение правил категорирования, за неотправку данных в ГосСОПКУ и пр. наказаний не предусмотрено. Этот пробел хотят устранить и повторить идею со статьей 13.11 КоАП по персональным данным. Наказывать по ней смогут и ФСТЭК, и ФСБ.
- Планируют вернуть сроки составления перечня объектов КИИ, от которого будет отсчитываться год на само категорирование. Вариантов рассматривается два - или как было (перечень с последующим категорированием), или конкретный срок (например, конец 2019-го года), к которому надо завершить категорирование.
- Новое ПП, которое планируют вносить в Правительство в первом квартале 2019-го года, обратной силы иметь не будет. То есть перекатегорировать ничего не надо будет.
- В приказах ФСТЭК планируют учесть обеспечение ИБ в холдинговых и интегрированных структурах.
- Наличие компенсирующих мер (например, резервирования) не является основанием для некатегорирования объекта и присвоения ему незначимой категории.
- Сеть электросвязи - это не объект КИИ.
- Водоканал - это... Все зависит от конкретной организации. Дело в том, что водоканал, как организация, занимающаяся водоснабжением и водоотведением, не относится к субъектам КИИ, так как такой сферы в ФЗ-187 нет (хотя в КСИИ была). А вот когда в Уставе конкретного ООО "что-тотамводоканал" написано про обслуживание электротехнических установок или про генерацию тепловой энергии (горячая вода и пар), то это уже сфера ТЭК со всеми вытекающими. Если вы введете в Google "водоканал устав", то найдете много готовых уставов различных водоканалов с различными целями существования организации, которые могут и попасть под действие ФЗ-187.
- ОМСУ - не является госорганом, а значит и не попадает в список субъектов КИИ.
- Немного не в тему КИИ, но прозвучала интересная информация. Оказывается есть несколько решений судов, в которых признано, что информационные системы различных ГУПов и ФГУПов являются государственными, даже несмотря на то, что ГУП/ФГУП - это коммерческая структура. Продолжаю придерживаться позиции, озвученной мной в 2015 году, но с позицией судов спорить может только сам ГУП/ФГУП.
- Если удаленный доступ (в контексте приказа ФСТЭК) осуществляется с помощью VPN, то это не удаленный доступ, а локальный. Не самый логичный вывод, но зато снимает ряд проблем, связанных с привлечением для проведения регламентных работ сотрудников сторонних организаций.
- Сенсацию (для меня) я оставил на самый конец. Прозвучала позиция регулятора (я с ней не согласен), что если деятельность субъекта КИИ зависит от облака, в котором не только размещаются данные, но и ведется работа (как делают некоторые ЛПУ с облачными медицинскими ИС), то облако надо считать объектом КИИ этого субъекта! Как при этом получить информацию об уязвимостях, угрозах, мерах защиты и т.п., не совсем понятно. Рекомендация "договариваться" классная, но в реальной жизни не работает. Если логику ФСТЭК наложить на ДБО, которым пользуется нефтяная компания, которая из-за атаки на ДБО может недосчитаться денег на счете и недоплатит денег в бюджет, то получится, что ДБО банка - это объект КИИ нефтяной компании!!! Я посмотрю на попытки нефтяной компании получить информацию от банка об уязвимостях в ДБО, ее мерах защиты, модели угроз, списке допущенных лиц и другой достаточно критичной информации, требуемой для категорирования. Такая позиция ФСТЭК имеет далеко идущие и негативные последствия для многие субъектов, использующих услуги аутсорсеров.
Вот таков краткий перечень озвученных регулятором на встрече блогеров вопросов. Да, не совсем то, что ожидалось, но сам факт встречи можно только приветствовать. Нечасто регуляторы у нас идут на контакт и готовы делиться своей позицией с широкой общественностью. Тут можно сказать ФСТЭК только спасибо. Что касается оставшихся вопросов, то мы договорились, что из 150 вопросов будут выбраны наиболее важные и регулятор попробует на них ответить на следующей встрече, которая состоится в обозримом будущем (регулятор готов к этому).
ЗЫ. Да, кстати. Встреча началась с того, что Виталий Сергеевич Лютиков укорял некоторых экспертов, которые, выступая на публичных мероприятиях по КИИ, говорят не то, что говорит регулятор на своих мероприятиях, по сути перевирая слова ФСТЭК, что потом приводит к куче головной боли. В качестве примера было приведено высказывание одного из экспертов, который на большйо конференции высказал мысль, что перечени объектов КИИ надо направлять на имя Шевцова Дмитрия Николаевича, начальника 2-го Управления ФСТЭК. Это неверно! Так что стоит учитывать, что и я могу неверно трактовать те или иные высказывания регулятора :-) Но, надеюсь, если я местами не прав, мне старшие товарищи укажут на это. Отчасти именно поэтому ФСБ не практикует такие встречи - слишком много потом разгребать приходится :-) Не могу их винить за это, хотя открытость ФСТЭК мне импонирует больше.
ЗЗЫ. Также своим мнением о встрече поделились и коллеги:
Обзоры от Сергея Борисова и Валерия Комарова, надеюсь, появятся у них в блогах.
7.11.18
Коммерческим SOCам нужна еще и лицензия ФСБ на шифрование
В сентябре я написал заметку о том, сколько лицензий нужно, чтобы подключиться к ГосСОПКА. А тут давеча, рассказывая про модель угроз и про то, что отсутствие у организации лицензии ФСБ на деятельность в области шифрования может также рассматриваться как угроза, я подумал, что у центра ГосСОПКИ, предоставляющего услугу подключения к ГосСОПКЕ должна же еще быть и еще одна лицензия ФСБ - на шифрование. И хотя дискуссия в Фейсбуке показала, что многим такая идея совсем не нравится, я все-таки решил повторить свои размышления в блоге. Во-первых, это повод задать вопрос своим корпоративным юристам. А, во-вторых, грядет SOC Forum, на котором этот вопрос можно задать регуляторам. Моя же логика была следующей:
- Согласно требованиям ФСТЭК, для оказания услуг по мониторингу ИБ (а это то, что в том числе делает центр ГосСОПКИ) в обязательном порядке необходимо иметь сертифицированные в ФСБ средства защиты каналов передачи данных, которые должны обеспечивать конфиденциальность данных, передаваемых между SOC и теми, кого этот SOC мониторит.
- В Facebook некоторые коллеги говорили, что на совещании в ФСТЭК, когда этот вопрос обсуждался, ФСТЭК заявила, что применение СКЗИ не является обязательным, а отдается на откуп лицензиату. Я, присутствуя на двух совещаниях ФСТЭК по этому вопросу, что-то не припомню такой позиции регулятора. Как раз наоборот. Он настаивал на том, что конфиденциальность должна быть обеспечена в обязательном порядке. А иначе зачем требовать покупку того, что можно и не использовать?
- Подход ФСТЭК по обязательному обеспечению конфиденциальности между системой управления и управляемыми решениями в последнее время становится все более жестким - в последних проектах РД на новые типы средств защиты, а также в ответах ФСТЭК на вопросы по смежным темам, явно сквозит требование по применению сертифицированных в ФСБ СКЗИ. Да и вообще, достаточно странно выглядит идея, что регулятор в области защиты информации не будет советовать обеспечивать защиту канала, в который может вмешаться злоумышленник.
- Подход ФСБ к наличию своей лицензии на деятельность в области шифрования известен уже много лет и он не меняется. ФСБ планомерно, а иногда излишне широко трактуя законодательство, требует либо поручать работы с СКЗИ лицензиатам, либо самим получать такую лицензию. Помнится ФСБ даже отвечала, что все, что было указано в Постановлении Правительства, независимо от возмездности оказания услуг и интересов (исключая один из видов работ, про который прямо сказано, что его для собственных нужд можно и без лицензии), требует лицензии ФСБ. С тех пор сменилось и само ПП (с 957-го на 313-е), и руководство ЦЛСЗ, а подход остается неизменным. Отсюда и мои выводы о необходимости лицензии ФСБ на шифрование.
Можно ли уйти от получения лицензии центром ГосСОПКИ? Если отталкиваться только от одного вида работ - оказание услуг в области шифрования, то можно было бы попробовать доказать, что никаких услуг в области шифрования SOC не оказывает. Но тут вступает в игру два нюанса. Во-первых, банки ФСБ активно плющила по ст.171 УК РФ (незаконное предпринимательство) именно по причине отсутствия лицензии при оказании услуг ДБО (а банк впрямую услуг по шифрованию не оказывал). А, во-вторых, кто-то же должен управлять ключами шифрования (а это тоже включается в деятельность в области шифрования). Если это делает сам SOC, то лицензия ФСБ нужна. Если это делает заказчик, то... такая схема вообще выглядит странно. Да и заказчик врядли захочет получать лицензию ФСБ в довесок к переходу к сервисной модели SOC. В ФБ активно предлагался вариант с привлечение УЦ для управления ключами между SOCом и его клиентами. Интересная идея, но вот я в нее что-то не верю. Во-первых, это удорожает решение и делает его более сложным (трехсторонний договор, а не двусторонний), а, во-вторых, учитывая происходящую вокруг УЦ ситуацию, стоило бы повременить.
Но помимо оказания услуг, у нас есть еще... создание SOC, то есть информационной системы с использованием шифровальных средств. А это тоже лицензируемый вид деятельности. А если SOC не только мониторит, но и управляет средствами защиты или обеспечивает удаленный сбор доказательств для расследования инцидентов и для этого заходит на удаленное оборудование с помощью SSH? Это ведь тоже лицензируемый вид деятельности :-) Шучу. Или не шучу?..
Что в итоге? Большинство текущих коммерческих SOCов не имеет лицензии ФСБ на деятельность в области шифрования и поэтому отстаивает позицию, что такая лицензия не нужна. Я их понимаю :-) Их вроде как спасает тот факт, что за шифрование у нас отвечает 8-й Центр ФСБ, который же "рулит" и ГосСОПКОЙ. Но за лицензирование у нас отвечает ЦЛСЗ, а у него не всегда взаимопонимание с другим управлением регулятора, ответственного за нацбезопасность. По крайней мере, когда представители 8-ки с открытой трибуны заявляли про собственные нужды, ЦЛСЗ говорил прямо противоположное. И я бы рассматривал этот риск - за 171-ю статью УК отвечают именно они, а не 8-й Центр.
Клиентам коммерческого SOC вроде как ничего не угрожает - им лицензия ФСБ для выбора SOC не нужна (если ключами управляют не они). Но что делать, если к коммерческому SOC вдруг возникнут вопросы по лицензированию? Его деятельность могут приостановить! Риск это, конечно, маловероятный, но и сбрасывать со счетов его не стоит. В любом случае этот риск надо осознавать.
Запугал? Нет? Ну и прекрасно :-) А если да, то что делать; жизнь такая, непростая :-)
Подписаться на:
Сообщения (Atom)