18.05.2017

Основные направления регулирования ИБ в России (презентация)

Вчера выступал в Челябинске на ИТ/ИБ-форуме и делал там краткий обзор основных направлений регулирования ИБ в России. Выкладываю эту презентацию.



Обязательное согласование моделей угроз и ТЗ для ГИС (обзор ПП-555)

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

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

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

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

При этом, новое ПП-555 также фиксирует, что ГИС не может быть введена в эксплуатацию без:
  • выполнения требований ФСТЭК и ФСБ, включая отсутствие соответствующего аттестата,
  • записи в реестре о местонахождении элементов ГИС (они не могут находиться за пределами РФ),
  • устранения нарушений, выявленных в рамках контроля и надзора за вводом в эксплуатацию отдельных ГИС,
  • оформления прав на использование ее компонентов, являющихся объектами интеллектуальной собственности.
В ФСБ направлять свои модели угроз надо сразу в центральный аппарат - терорганы не занимаются этими вопросами. По ФСТЭК возможно и удастся распределить эту нагрузку между управлениями по федеральным округам, но встанет вопрос компетенций и временных затрат на такие согласования. Если же ФСТЭК тоже будет всех заворачивать в Москву, во 2-е Управление, то оно просто "умрет" под ворохом таких запросов и на выработку других документов (новых РД, методичек, новых приказов) сил у них уже не останется - все погрязнет в рутине.

Пока вопросов больше, чем ответов. Совершенствование защиты информации - это, конечно, хорошо и полезно, но вот так вот "менять коней на переправе"?.. Если же перейти из плоскости теоретической в практическую, то могу порекомендовать начать работу над моделью угроз (если у вас ее еще нет) с сервиса, созданного Булатом Шамсутдиновым - www.threat-model.com.


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

15.05.2017

Почему не стоит ничего ждать от Стратегий и Доктрин ИТ и ИБ?

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

Начну с банального тезиса - в России нет стратегов в области ИТ и ИБ (или их просто нет у власти) - есть куча приглашенных для работы над "Стратегией/Доктриной" экспертов, решающих свои задачи в меру своего понимания, не видя всей картины (или видя картину, отличную от картин других). У каждого свой опыт, свое образование, свое текущее место работы. И шлют они все свои предложения в одно место. А там (возможно на Старой площади) сидит какой-нибудь ответственный и думает "вот эта идея прикольная, вставлю ее в финальный документ". И получается куча прикольных идей, но нет стратегии. Я так статьи нередко пишу - набросаю кучу мыслей, а потом привожу их в некий удобочитаемый текст, убирая что-то лишнее и связывая несвязанные мысли промежуточными абзацами. Но так то статья, а тут государственная стратегия. Если у ее координатора нет собственного финального видения, то не получится ничего. А тут еще, конечно, вмешивается известный всем принцип Питера, который звучит как "в иерархической системе каждый индивидуум имеет тенденцию подняться до своего уровня некомпетентности". Что мы получаем? Правильно. То, что получили в виде Доктрины ИБ или Стратегии развития информационного общества.

Я всегда считал, что стратегия - это путь к целевой архитектуре, которую и надо построить. А какова она у государства в части ИТ/ИБ? Где она определена? Как можно достичь того, что не определено? Отсюда появляются вот такие перлы: "Надо понимать, что стратегия определяет тактику" С какого перепугу? Стратегия определяет стратегию. А зачем в стратегии констатировать факты? "Пользователями Интернет в 2016-м году стали", "В России с 2014-го осуществляется подключение" и др. Ведь как должно быть? Сначала определили, чего мы хотим достичь, то есть архитектуру. Потом определили наш текущий уровень. Потом оценили разрыв и составили план перехода из состояния "как есть" в состояние "как хочется". Это и будет стратегия. Но у нас все объединяют вместе и получается...

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

Например, у нас в Cisco, есть такая часто используемая топ-менеджментом аббревиатура - VSE, которая рассшифровывается как "Vision. Strategy. Execution" ("Миссия. Стратегия. Исполнение"). Циничные продавцы превратили ее в "Vision, mission и comission" ("Миссия и комиссия", то есть бонус). Но за юмором скрывается важный момент. В обоих случаях говорится о execution, то есть о конкретных действиях с конкретными ответственными, которые приводят к конкретному результату в виде доходов.

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

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

ЗЫ. Кстати, по поводу неустранения уязвимости ETERNALBLUE, для которой Microsoft выпустил патч еще в марте. Вспомните мою заметку с обзором второй части семинара Gartner, которая была опубликована в день начала эпидемии WannaCry. Там как раз говорится о том, что многие заказчики уже смирились с наличием уязвимостей и даже не имеют процесса их устранения. В крупных компаниях это вполне частая ситуация (все-таки масштаб имеет значение).

12.05.2017

Обзор московского семинара Gartner по ИБ (часть 2)

В своей второй презентации на семинаре Gartner Антон Чувакин пытался вкратце рассказать о выпущенном недавно исследовании по SOCам (несколько десятков страниц).


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


Но было сделано несколько интересных замечаний, о которых мне хотелось бы поведать. Во-первых, Антон начал с фразы: "Когда я вижу, что компания продает SOC, я начинаю нервничать" :-) Таким образом Антон в очередной раз вернул многих продавцов SOCов с небес на землю, указав, что SOC - это процессы, люди и только потом технологии. Когда в 2007-м году мы в Cisco только выходили на рынок услуг по мониторингу ИБ, мы тоже говорили об этом - сначала процессы и люди, а уж потом различные продукты по мониторингу и аналитике. Да, без них сложно выстроить современный SOC, но не с них надо начинать этот длинный путь.

На семинаре специально не стали вдаваться в долгую терминологическую дискуссию, что такое SOC, сразу дав свое определение, от которого Gartner и отталкивается. Но самое главное, что надо помнить, задумываясь о SOC, - это то, что он требует определенного, и немаленького, уровня зрелости. Сегодня только ленивый не задумывается о том, что у себя в компании не назвать купленный ArcSight или скачанный OSSIM SOCом, но... повторюсь. SOC - это процессы, люди и только потом технологии. Если в компании нет процессов (или они приобретены у крупного консалтера без понимания их сути) - к SOCу компания не готова. Если в компании есть только МСЭ на периметре и антивирус на персоналках - к SOCу компания не готова. Нужно дозреть и только наткнувшись на невозможность решить возникающие проблемы текущими средствами, можно задумываться о переходе на новый уровень. Как мне кажется, с аутсорсингом та же ситуация.


Согласно подходу Gartner современный SOC базируется не только на SIEM (хотя понятно, что с него многие начинали и начинают). Сегодня SOC должен включать помимо анализа логов (с помощью SIEM), еще анализ сетевого трафика (и тут нужны решения класса NTA/NBAD/NFT), а также анализ активности на оконечных устройствах (решения класса EDR). Если же вернуться к SIEM, то по словам Антона, лучше плохой SIEM с хорошей командой, чем офигенный SIEM с плохой командой. Например, в Cisco (про наш подход я рассказывал на недавнем SOC Forum в Астане) мы отказались от архитектуры SOC, построенной вокруг только SIEM:


и построили новую архитектуру, где в центре находится набор технологий для мониторинга - мониторинг логов на базе Splunk, мониторинг сетевого трафика на базе Cisco Stealthwatch, мониторинг активности по ПК на базе Cisco AMP for Endpoints и ряда других технологий.


При этом Антон Чувакин отметил, что сегодня многие SOC начинают включать в себя технологии UEBA (как самостоятельные решения или как часть SIEM).


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

Как развитие темы управления уязвимостями, я спросил Антона, а что думает Gartner про решения по построению топологии сети и автоматизации процесса определения векторов атак на базе корреляции информации о сетевой топологии, информации об уязвимостях и конфигурации сетевого оборудования и средств защиты (например, RedSeal)? Ответ Gartner был удручающим - их клиенты редко используют такие решения, ввиду их сложности и неочевидности эффективности. На этом фоне новость о том, что отечественный MaxPatrol SIEM теперь умеет все это делать, выглядит презабавно. В защиту этой технологии могу сказать, что у нас в Cisco она используется достаточно успешно.

Еще одним "откровением" стало пассаж Антона о том, что в современном мире с его динамически изменяющимся ландшафтом угроз и ростом квалификации злоумышленников надо быть готовым, что "выгнать" злоумышленника из своей сети не удастся, возможно, никогда. Это надо осмыслить и если вдуматься, то возможно Антон не так уж и неправ (а он транслируют проблемы многих своих заказчиков). Я помню как админил сетку на несколько сот компьютеров (по Москве) и когда у нас вдруг появлялся вирус на дискетах с игрушками, я брал антивирус с обновленными базами и мотался по всем нашим магазинам (а мы тогда, в начале 90-х, были одним из крупнейших ритейлеров России), вычищая эту заразу. Вычистив все компы можно было на несколько недель успокоиться. Сегодня, во времена APT, увы, покой нам только снится. Даже при наличии серьезного арсенала защитных средств (и может быть даже с аналитикой ИБ) гарантировать полное очищение нельзя. А значит надо строить свой SOC (а, вспоминая определение Gartner, он обеспечивает управление инцидентами) исходя именно из этой парадигмы и готовить к ней свое руководство, которое до сих пор живет в плену иллюзии, что можно достичь 100%-й безопасности.

Вот таким мне запомнился приезд Антона Чувакина из Gartner в Москву и его выступление на закрытом мероприятии, прошедшем между майскими праздниками.

Обзор Стратегии развития информационного общества

9 мая Президент подписал Указ №203, утвердив новую Стратегию развития информационного общества до 2030-го года. Прежняя была реализована неполностью и вот новая попытка. Сложно говорить о том, насколько она будет успешной (все-таки срок стратегического планирования отодвинут до 2030 года, а это значит, что как в притче про Ходжу Насредина - "либо ишак, либо эмир, либо Ходжа". Поэтому дистанцируясь от реалий, поделюсь тезисно тем, что мне запомнилось из этого документа применительно к теме ИБ:

  • Вводится достаточно много новых терминов, имеющих более привычные нам английские аналоги - Big Data, Fog computing, Industrial Internet, Internet of Things, Cyberspace и др.
  • В отличие от прошлой стратегии в нынешней много говорят (местами завуалированно) о безопасности, включая и безопасность критической информационной инфраструктуры.
  • Вводится понятие "безопасного ПО и сервиса", под которым понимается сертифицированное по требованиям ФСБ и ФСТЭК ПО и сервис. Умолчим о том, где у нас требования по сертификации сервисов, но движение в этом направлении понятно и предсказуемо. Правда зачем нужно это понятие по тексту Стратегии непонято - оно нигде не упоминается.
  • Вводится понятие "технологически независимого ПО и сервиса", то есть такого, которое обслуживается и поддерживается в Крыму, не обновляется принудительно из-за рубежа (даже в случае наличия в нем критических уязвимостей), не управляется из-за рубежа, а также которые не передают ничего несанкционированно за пределы РФ (укол в сторону Windows 10?). Вообще про защиту от несанкционированной и незаконной трансграничной передачи информации говорится в нескольких местах. Как и в случае с понятием "безопасного ПО" термин "технологически независимое ПО" тоже непонятно зачем введен в Стратегии - он нигде не упомянут.
  • Терминология в части КИИ совпадает с законопроектом по безопасности КИИ, а значит, что упомянутые мной в декабре проблемы со списком отраслей, где могут быть критические инфраструктуры остались нерешенными и, видимо, их и оставят нерешенными (а то получится, что в законе по КИИ у нас одни отрасли, а в указе Президента - другие).
  • Иностранные технологии официальны признаны угрозой национальной безопасности и мешающими защите граждан и государства в информационной сфере.
  • Официально объявленный курс на изоляционизм и протекционизм как-то сочетается с желанием вывести отечественные технологии на мировой рынок и сделать их конкурентноспособными. То, почему это будет сделать сложно, хорошо написал Александр Чачава в своей недавней статье.
  • В очередной раз заявлено о необходимости создавать и развивать нормативную базу под ГосСОПКУ. Я про это писал пару лет назад, но с тех пор нормативки по ГосСОПКЕ у нас почти не появилось (кроме методички по созданию центров ГосСОПКИ - часть 1, 2 и 3).
  • Интернет-сайты, соцсети и мессенджеры будут регулировать еще больше.
  • Информационная инфраструктура РФ (читай, Рунет) должен централизованно мониториться и управляться. Как это сделать применительно к изначально децентрализованному Интернету не совсем понятно, но отдельные идеи в прессу просачиваются. Вполне допускаю, что Минкомсвязь вытащит из под полы проект приказа по использованию для управления магистральным оборудованием только сертифицированных по требованиям ИБ средств управления.
  • Также требуется обеспечить устойчивость, безопасность и независимость функционирования российского сегмента Интернет. Про это уже не раз Минкомсвязь выпускал нормативку, но как обычно забивал болт на контрол ее исполнения (по крайней мере РКН, который уполномочен это делать, занимается совсем другими вещами).
  • В очередной раз требуется перейти на использование отечественной криптографии при обмене не только между госорганами и муниципалами, но и с гражданами и предприятиями. Видимо прошлое поручение Президента пока не спешат реализовывать.
  • В информационной инфраструктуре необходимо заменить все импортное на свое родное, а также защитить ее с помощью ГосСОПКИ (раньше ГосСОПКУ распространяли только на критическую информационную инфраструктуру). Требование про непрерывный мониторинг и анализ угроз при наличии ГосСОПКИ, которая это и делает, не совсем понятно. Видимо, разные люди писали. На свои технологии надо также перейти в госорганах, органах местного самоуправления и компаниях с госучастием. В сетях связи должно использоваться оборудование и ПО, производство и ремонт которых (а также запчастей) должно производиться на территории России (и процессоры?).
  • В очередной раз требуется создать сугубо отечественное системное и прикладное ПО, железо и пользовательские устройства (очередной Йотафон?) и чтобы там непременно были встроенные российские средства защиты информации.
  • 31-й пункт вроде посвящен защите данных (не информации), но что хотели сказать авторы не до конца понятно, кроме общих фраз по защиту прав субъектов персданных и контроль трансграничной передачи ПДн.
  • Постулируется необходимость одновременно обеспечивать конфиденциальность пользователей и исключать их анонимность.
  • Предлагается усилить участие России в международных организациях по стандартизации.
  • Технологии ИБ должны стать одним из направлений развития отечественных ИТ. Это позитивно, но хотелось бы увидеть конкретные шаги для этого (пока ни один из регуляторов не сделал ничего для развития отрасли средств защиты информации). Про это в Стратегии написано много, но пока на уровне хотелок.
  • Говорится о трансфере иностранных технологий и применение лучшего зарубежного опыта в сфере ИТ. Интересная идея, но вот как она будет реализовываться на фоне существенного сокращения применения иностранных технологий и по сути постепенного запрета работы иностранных ИТ-компаний в России?
  • Развитие технологий удаленной идентификации и аутентификации пользователей, а также формирование трансграничного пространства доверия к электронной подписи.
  • В НПС рекомендуется применять сертифицированные средства защиты информации. Про это я уже писал в контексте новых требований ЦБ по ИБ.
  • Локализация не только ПДн, но и всей информации, которая создается и обрабатывается иностранными организациями в рамках цифровой экономики России. Это требование будет покруче ФЗ-242 по локализации ПДн россиян.
В целом Стратегия выглядит немного странновато - очень много повторов и пересечений между разделами. Такое впечатление, что документ писался разными экспертами (так оно и было на самом деле), но потом кто-то не очень сведущий в предмете регулирования свел все предложения воедино, не сильно задумываясь над конечным результатом. Главное, чтобы документ читался и в нем были правильные слова. Вот эта задача была выполнена на 100%. Подождем конкретных НПА, которые должны реализовать все указанные в Стратегии положения. В течение полугода они, как минимум, основные, должны быть приняты Правительством и ФОИВами.

11.05.2017

Обзор московского семинара Gartner по ИБ (часть 1)

Между майскими праздниками тихо и без помпы прошло одно из тех редких в Москве мероприятий, которые стоят того, чтобы утверждать, что рынок ИБ-мероприятий еще не до конца потерян и у него есть перспектива; разумеется при соблюдении ряда условий, одним из которых является правильный контент и докладчик. В Москве прошла непубличное мероприятие Gartner, на котором Антон Чувакин выступал с двумя связанными темами:
  • cybersecurity advanced analytics (почему название на английском, я напишу чуть ниже)
  • особенности построения SOCов.


Первая тема официально звучала как "Последнее слово техники в сфере Аналитики Безопасности", а по-английски - "State of the Art of Security Analytics". Вообще фраза "последнее слово" на русском имеет несколько смыслов (от криминального до ритуального) и этот казус хорошо отражает вообще проблему с терминологией в ИБ. Об этом Антон говорил в обоих презентациях, специально огорившись, что переводить на русский "security analytics", "big data", "machine learning", UEBA, SOC, "operations", "management", "threat intelligence", "orchestration", "engineering", "workflow" он не будет, так как получится полный бред. В этом плане английские емкие термины гораздо лучше, чем громоздкие русские переводы.

--- лирическое отступление 1 ---

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

--- конец лирического отступления 1 ---

Ключевая идея первого доклада Антона заключалась (в моем понимании и изложении), что сегодня дискретных правил (шаблонов/сигнатур) и базового матстата для работы систем ИБ уже явно недостаточно и нужно то, что называется security analytics. При этом мы не должны ограничиваться только событиями ИБ, которые нам отдают МСЭ, IDS, антивирусы и т.п., а брать все, что будет полезно для принятия решений - данные из HR, СЭБ, видеонаблюдение и т.п. Ровно то, о чем я говорил в прошлом сентябре на "Коде ИБ" в Челябинске.


Соответственно все эти данные уже не могут быть обработаны как раньше и для обнаружения необнаруживаемого (я про это говорил на Коде ИБ в Нижнем Новгороде, а потом стал эту тему активно использовать) нужны "продвинутые" средства аналитики.

--- лирическое отступление 2 ---

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

--- конец лирического отступления 2 ---

При этом Антон сделал несколько важных замечаний относительно технологий аналитики ИБ:

  • Эффективность технологий ИБ-аналитики зависит в первую очередь не от алгоритмов, а от данных, которые на них подаются. Gartner пока не нашел доказательств, что один алгоритм анализа неструктурированной информации дает лучший эффект, чем другой.
  • Эффективность технологий ИБ-аналитики может меняться от компании к компании - у одних взлетает, у других - нет.
  • Для работы технологий ИБ-аналикити, которые якобы "сокращают" число дорогих специалистов по ИБ, часто может понадобиться еще более дорогой специалист по прикладной математике (сдуть пыль что-ли со своего диплома по примату?..), которых на рынке просто нет (какую бы зарплату им не предлагали). Нужно комбинировать (воспитывать) аналитиков ИБ и аналитиков данных.
  • Если подождать пару-тройку лет, то многие методы с приставкой "advanced" войдут в традиционные продукты, те же SIEMы. Но тут стоит добавить, что до России с ее курсом на изоляционизм и вышибание иностранных игроков с рынка (а большинство технологий к нам все-таки приходит оттуда) этот прогноз может и не сбыться вовсе.


  •  Gartner советует присмотреться к 4-м направлениям технологий ИБ-аналитики, от которых может быть толк (с учетом всего вышесказанного):
    • UEBA (user entity behavior analytics) - анализ поведения пользователей и иных сущностей
    • CASB (cloud access security broker) - контроль происходящего в чужих облачных средах
    • EDR (endpoint detection & response) - защита ПК следующего поколения
    • NTA (network traffic analytics) - анализ сетевого трафика на предмет аномалий (это эволюция NBAD) и т.п.


  • Многие продукты по ИБ-аналитике сегодня не работают без сопутствующих услуг, что плохо и Gartner считает, что они гораздо хуже, чем продукт, который работает хуже, но из коробки. Причин тут несколько - и высокая цена, и зависимость от вендора, и неоправданные ожидания, и чувство ложной защищенности.
Но в целом Антон, подводя итоги своей первой презентации, полный вариант которой будет читаться на ближайшем Gartner Security & Risk Management Summit в США, сказал, что пока клиенты мало понимают, как работает аналитика ИБ (да и сами вендоры не всегда это понимают) и берут ее для улучшения своего текущего положения в ИБ, надеясь на нее как некую "кремлевскую таблетку".

Во второй части я расскажу про следующий доклад Антона Чувакина про SOCи...

05.05.2017

Видео мастер-класса по борьбе с фишингом с CISO Forum 2017

Выложил видео со своего мастер-класса по борьбе с фишингом, который проводил в рамках CISO Forum 2017. Неоднозначное впечатление. Звук не совпадает с мимикой, а сама демонстрируемая презентация и вовсе не показывается. То есть это просто запись "as is", без монтажа. Сравнение ее с видео мастер-класса по киберпреступности, прочитанного в Сбербанке, не в пользу первого :-( Но все-таки озвучка есть, поэтому пусть тут лежит.


Обзор проекта новой редакции 382-П

На сайте ЦБ выложен проект новой редакции Положения 382-П по защите информации в Национальной платежной системе. Новая редакция вносит следующие изменения в действующий нормативный акт Банка России:
  • Уточняется понятие инцидента ИБ, к которому теперь относятся "события, которые возникли вследствие нарушения или попыток нарушения целостности, конфиденциальности и (или) доступности защищаемой информации, в состав которых включаются инциденты из перечня, размещаемого Банком России на официальном сайте Банка России в информационно- телекоммуникационной сети "Интернет". Ждем перечня инцидентов от FinCERTа? Пока же можно посмотреть на временный регламент передачи данных в FinCERT, в котором перечислены такие инциденты, как вредоносный код, несанкционированный доступ, эксплуатация уязвимости, DDoS, перебор паролей, фишинг, командные сервера ботнетов, вредоносный ресурс, сканирование и общая категория "другие".
  • Прикладное ПО, используемое для осуществления переводов денежных средств, должно быть сертифицировано на отсутствие уязвимостей или в отношении которого проведен анализ уязвимостей. Если быть более точным, то применяется схожая с описанным ранее ГОСТом концепция:
    • сертификация на отсутствие НДВ или сертификация по уровню ОУД4 (привет PA DSS)
    • ежегодные пентесты и анализ уязвимостей инфраструктуры (привет PCI DSS)
    • проверки уязвимостей проводится только лицензиатами ФСТЭК.
  • Уточняется порядок работ по применению СКЗИ для защиты персональных данных. Если принимается решение, что защита ПДн будет обеспечиваться с помощью СКЗИ, то их применение должно соответствовать 378-му приказу ФСБ. Но не забываем, что СКЗИ не являются обязательными для обеспечения конфиденциальности ПДн, - существует и куча других методов, которые я неоднократно описывал в блоге.
  • Вводится обязательное разделение контуров подготовки и подтверждения платежных поручений, в том числе и в ДБО. Компенсирующей мерой для разделения контуров является введение ограничение на параметры операций, что является актуальным именно для физлиц, которые не захотят применять два компьютера или две виртуальных машины для проведения обычных платежей, например, с помощью мобильных устройств. Нового в этом требовании ничего нет - его давно обещали ввести. Да и в 552-П схожая конструкция применяется.
  • Вводится обязанность по информированию ЦБ об инцидентах ИБ, а также о планируемых мероприятиях по раскрытию информации о инцидентах. В первом случае информирование будет осуществляться согласно порядка, опубликованного на сайте ЦБ (смотрим выше про временный регламент). Единственное, что я бы поправил, это внес в сам документ сроки уведомления (по аналогии с 552-П). А то иначе все будут забивать болт на соблюдение этих сроков, а наказать за это будет нельзя - указание срока и порядка уведомления на сайте не является нормативным актом Банка России, за несоблюдение которого можно будет наказать.
  • Исключается оценка соответствия в форме самооценки. Теперь только внешняя оценка (читай, аудит) с помощью лицензиатов ФСТЭК. Это жесткая позиция ЦБ, которая была озвучена еще на заседании ПК1 ТК122 в контексте проекта ГОСТа по оценке соответствия. Никакой отсебятины - только внешний аудит со стороны доверенных фирм. Небольшим банкам будет сложно, но увы... А учитывая, что ЦБ ужесточил недавно требования к обычным аудиторам, не исключаю, что у ЦБ и требования к аудиторам ИБ появятся тоже. Тем более, что раньше, в одной из прежних редакций проектов 382-П, такая идея уже была и реализовать ее хотели через АБИСС (сейчас таких членов всего 6). Правда, тогда ее отмели по ряду причин, но ничто не мешает к ней вернуться вновь.
  • Оператор национально значимой платежной системы обязан информировать ФСБ о применяемых СКЗИ.
Новая редакция 382-П должна быть введена с 1-го июля 2018-го года, а в части сертификации на НДВ или ОУД4 и разделения контуров - с 1-го июля 2019 года.

Можно заметить, что ничего нового по сравнению с ранее обещанным не вводится. Ну разве что применение 378-го приказа ФСБ, но формулировка используется дипломатичная, позволяющая СКЗИ для защиты ПДн не применять. Требование по уведомлению об инцидентах с одной стороны ново, а с другой - после после принятия 552-П и роста роли FinCERT это было только вопросом времени. Я на курсах с обзором новинок в области законодательства ИБ для финансовых организаций говорю про это достаточно давно.

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

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

ЗЫ. До 11 мая принимаются предложения и замечания по проекту данного нормативного акта. Очень удачно выбрано время для выкладывания проекта - майские праздники, отпуска... :-(

04.05.2017

Финальная редакция ГОСТа ЦБ по защите информации

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

К изменениям, которые вошли в финальную редакцию (по сравнению с предыдущей), можно отнести:
  • Распространение действия стандарта еще и на субъектов НПС, а не только на финансовые кредитные и некредитные организации.
  • Включение пункта о возможности формирования нескольких контуров безопасности, для которых и устанавливаются уровни защищенности, определяемые нормативными актами Банка России. На мой взгляд, именно эта тема сейчас вызывает основные вопросы - никто не знает, какие уровни и для кого/чего будут установлены? Я еще недавно был уверен, что эти уровни будут устанавливаться отдельными нормативными актами Банка России, например, 552-П, 382-П, 437-П, 483-П и т.п. Но на заседании ТК122 представитель ЦБ сказал, что будет один нормативный акт (до конца года), который и определит эти уровни для разных типов организаций и платежных процессов. Первый вариант мне казался более логичным, так как второй врядли сможет учесть все возможные ситуации, что потребует регулярного его пересмотра, что не так быстро. Допускаю вариант, что ЦБ пока вообще не думал о форме установления этих уровней защищенности, так как есть более приоритетные задачи, а до принятия ГОСТа еще не далеко.
  • Помимо контроля отсутстви известных (описанных) уязвимостей добавили требование про их оперативное устранение (срок "оперативности" не определен).
  • Стирание информации может быть обеспечено не только средствами гарантированного стирания информации, но и способами (методами), обеспечивающими невозможность их восстановления. О том, что это за методы, могу посоветовать почитать мою заметку 2012-го года, в которой я делал обзор NISTовского стандарта на эту тему.
Наибольшее обсуждение вызвала тема сертификации. В отличие от предыдущей формулировки, которую я приводил в блоге раньше, удалось ее изменить и вернуться к тому, что было определено еще в прошлом году. Сейчас формулировка звучит следующим образом: "применение средств защиты информации, прошедших в установленном порядке процедуру оценки соответствия (в том числе программных (программно-аппаратных) средств, в которых они реализованы, имеющих необходимые функции безопасности) в случаях, когда применение таких средств необходимо для нейтрализации угроз безопасности, определенных в модели угроз и нарушителей безопасности информации финансовой организации". В таблице же требования РЗИ.11-РЗИ.13 стали звучать как "Применение сертифицированных по требованиям безопасности информации средств защиты информации не ниже Х класса**", где примечание (**) звучит как "В случаях, когда применение таких средств необходимо для нейтрализации угроз безопасности, определенных в модели угроз и нарушителей безопасности информации финансовой организации".

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

В части сертификации платежных приложений формулировка теперь такая: "Применение прикладного ПО АС, сертифицированного на соответствие требованиям по безопасности информации, включая требования по анализу уязвимостей и контролю отсутствия недекларированных возможностей (это добавление - выделено мной), в соответствии с законодательством Российской Федерации или в отношении которых проведен анализ уязвимостей по требованиям к оценочному уровню доверия не ниже чем ОУД 4 в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013***", где примечание звучит как "В случаях, предусмотренных нормативными актами Банка России, и (или) если в соответствии с моделью угроз и нарушителей безопасности информации финансовой организации, угрозы, связанные с наличием уязвимостей и недеклалированных возможностей в прикладном ПО АС признаны актуальными".

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

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

По срокам принятия данного ГОСТа пока сказать нечего. Сроком его введения в действие предполагается сделать 1-е января 2018-го года, но это не значит, что к этой дате надо бежать его и выполнять. Срок введения и срок вступления в силу - это, обычно, разные даты и могут быть разнесены на длительные временные периоды. Например, ГОСТ Р 56939-2016 по SDLC был принят 1-го июня 2016-го года, а введен в действие (вступает в силу) - 1-го июня 2017-го года. Что же касается 1-го января 2018-го года, то я пока скептически отношусь к этой дате - не помню случаев, чтобы ГОСТ так быстро проходил через все согласования в Ростехрегулировании. Более реальной я бы назвал дату 1 июня 2018 года. Иными словами сам ГОСТ может стать обязательным с 2019-го года (но это мои предположения).

03.05.2017

Нюансы функционирования SOC в Cisco (презентация)

На прошлой неделе, когда в Гармише завершался форум по МИБ, в Питере проходил "Код ИБ" и мероприятие по ИБ электроэнергетике, а также парочка других мероприятий по ИБ в Москве и ближайшем Подмосковье, я вырвался за пределы России в столицу Казахстана, где проходил первый зв пределами России SOC Forum. Там, помимо модерирования пленарной секции, я пытался рассказать 20 минут нюансы функционирования Cisco SOC. Обычно эта презентация занимает у меня около часа, а тут пришлось урезать все в три раза :-(

Выкладываю свою презентацию:



02.05.2017

Анализ рынка киберпреступности (видео)

Недавно мне довелось выступать в Сбербанке на тему рынка современной киберпреступности. В течение двух часов я рассказывал о том:
  • Как устроен рынок киберпреступности
  • Каковы бизнес-модели онлайн-криминала
  • Чем торгуют на «чёрном рынке» «ДаркНета»
  • Сколько можно заработать на уязвимости iOS
  • Каковы ваши шансы попасться на удочку мошенников
  • Кто из ваших друзей в соцсетях — «бот»
  • Как выглядят «партнёрские программы» в преступном мире
  • Какова структура прибыли и издержек криминального «IT-бизнеса»
  • Какие продукты и сервисы востребованы сегодня на рынке киберпреступности?
Коллеги из BIS-TV, за что им отдельное большое спасибо, сделали видео данного выступления и выложили у себя на сайте. Выложу его и я: 



Как и в случае с мастер-классом по борьбе с фишингом, который я читал на CISO Forum, данная презентация тоже является частью более полного материала, который состоит из шести больших блоков, 5 из которых описывают основные типы злоумышленников:


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

28.04.2017

Методические рекомендации по созданию центров ГосСОПКИ (часть 3)

Продолжим рассмотрение функций центров ГосСОПКИ согласно методических рекомендаций НКЦКИ. На очереди у нас этап анализа данных о событиях безопасности, целью которого является регистрация инцидентов. Но тут у меня возник еще один вопрос. Ведь есть еще одна функция - прием сообщений о возможных инцидентах от персонала и пользователей информационных ресурсов. И в рамках нее тоже говорится о приеме сообщений об инцидентах. Некоторая путаница возникает. На самом деле на данном этапе речь идет о SIEM, которые в автоматизированном режиме должны собирать события безопасности. Правда, написано все общими словами. Про обогащение событий с помощью Threat Intelligence, про приоритезацию и классификацию событий и другие важные аспекты работы SIEM документ не упоминает.


Следующая функция называется "Регистрация инцидентов" и у меня вновь появляется вопрос. А предыдущие две функции "анализ событий безопасности" и "прием сообщений об инцидентах" для чего? Ну да ладно. Не так уж это и важно. Функция опирается на необходимость вести карточки инцидентов, которые рассылаются по центрам ГосСОПКИ. Это предполагает унифицированный формат ведения карточек и обмена ими. Какой? STIX, TAXII, CyBOX?.. Вопросы стандартизации, к сожалению, в документе не учтены совсем и похоже авторы просто пока не знают, что брать за основу. Та же проблема и у FinCERT, который рассылает свои бюллетени в PDF/Word и которые нельзя в автоматическом режиме подцепить к SIEM/IDS/МСЭ и другим средствам защиты. На мой взгляд тут очень важно уже сейчас определяться со стандартами обмена информацией, чтобы не получилась ситуация, когда ведомственные и корпоративные центры ГосСОПКИ созданы и начинают функционировать, а обмениваться данными между собой не могут, так как используют разные форматы карточек инцидентов и разные протоколы для их обмена. Из стандартов методичка упоминает только стандарт TLP для "раскраски" информации об инцидентах, означающую круг лиц, которым эту информацию можно рассылать.

Документ ни слова не говорит о том, сколько хранятся карточки инцидентов? 3 года, как и уязвимости? А вот трафик, в котором была обнаружена атака, а также все события средств защиты и средств ГосСОПКА, включая и прикладные логи, должны храниться не менее 6 месяцев. Я надеюсь трафик DDoS хранить не придется, а то накладно будет.

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

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

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

В 7-м разделе методички приводится иерархия специалистов центров ГосСОПКИ. Выделяется 3 линии специалистов, реализующих 11 функций, описанных в трех заметках. Это достаточно распространенная схема, принятая в многих SOCах и службах реагирования на инциденты. Например, в Cisco это выглядит так (кстати, на 66 страниц методички нет ни одной картинки - не любят у нас регуляторы визуализацию, ох, не любят):


В заключении перечислю еще несколько вопросов, которые я бы включил в новую версию этой методички:
  • Резервирование способов взаимодействия персонала и что они могут стать мишенью сами по себе.
  • Регистрация и учет не только информации, получаемой центром ГосСОПКИ через Интернет, но и по телефону. В тех же рекомендациях NIPC или CERT/CC как раз приоритет отдается телефонной связи, как основному каналу взаимодействия при инциденте (так как Интернет-канал может быть под контролем).
  • Лаборатория (стенд) по расследованию скомпрометированных/зараженных узлов.
  • Взаимодействие с правоохранительными органами (инциденты же могут затрагивать интересы не только ФСБ, но и МВД).
  • Доказательная сила собираемых доказательств. Понятно, что для ГосСОПКИ может быть достаточно того, что было собрано в рамках рекомендаций. Но что делать, если пострадавшая сторона захочет обратиться в правоохранительные органы? Допускаю, что именно под расследование будет отдельная методичка; просто включил этот пункт, чтобы не забыть.
  • Эскалация инцидентов.
  • Особенности сбора доказательств в случае зарубежного инцидента (в рамках ближнего зарубежья, например, в рамках ОДКБ или СНГ, где есть определенное налаженное взаимодействие, или в рамках дальнего зарубежья). Особенно актуальна эта тема для российских компаний и организаций, имеющих зарубежные представительства или дочерние компании.
  • Более четкая систематизация действий в рамках инцидента. Не просто 11 функций, а пошаговая процедура (по сути некий аналог workflow). Например, в очень старой методичке SANS по реагированию на инциденты (еще 90-х годов) было прописано 6 процессов, 31 детальная процедура и 97 конкретных действий, которые необходимо было реализовать для управления инцидентами, на что и заточены центры ГосСОПКИ.
  • ...
Вообще можно еще много различных рекомендаций дать по улучшению данной методички. Но возможно я просто опережаю время и на описанные в трех частях вопросы будут отвечать другие документы, которые только будут разрабатываться, о чем я написал в первой заметке?

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

27.04.2017

Методические рекомендации по созданию центров ГосСОПКИ (часть 2)

Продолжу вчерашнюю заметку про ГосСОПКУ. При ее создании реализуются 11 подробно описанных в методичке функций:

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

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

Этап выявления уязвимостей подразумевает работу по ГОСТ 56546-2015 и предлагает на выбор следующие варианты получения информации о слабых местах контролируемого ГосСОПКОЙ сегмента:

  • сетевое сканирование
  • системное сканирование
  • пентесты
  • тестирование устойчивости к DDoS
  • аудит
  • анализ кода (SAST/DAST).
Варианты типа использования баз данных уязвимостей (Vulners, БДУ, Cisco ISIS, NVD) не попали в список. Ситуация с пассивным анализом сетевого трафика для поиска уязвимостей осталась до конца не выясненной. В принципе, я не думаю, что есть запрет на использование каких-то иных методов поиска уязвимостей, чем те, что указаны в методичке. Для каждого из способов сканирования указана своя периодичность (что очень позитивно). При этом владельцам центров ГосСОПКИ придется готовиться к длительному хранению результатов сканирования - 3 года. При ежемесячном сканировании получается 36 “слепков” по всей инфраструктуре, попадающей под мониторинг. Крутовато будет с точки зрения объемов хранилища. И если я правильно понял, то использовать надо все методы сканирования, а не какой-то один из них. Так что серверных стоек понадобится много.

На основе проведенной инвентаризации и выявленных уязвимостей проводится анализ угроз (или векторов атак). Наверное, это один из самых важных элементов всей ГосСОПКИ, так как именно от него зависит эффективность всей конструкции. Но пока ее не запустили в полном объеме, то и всех необходимых документов пока еще нет (или они в процессе, или секретны). А документом понадобится много:
  • описания компьютерных атак, актуальных для информационных ресурсов, находящихся в зоне ответственности сегмента ГосСОПКА;
  • методические рекомендации по предупреждению, обнаружению и ликвидации последствий компьютерных атак;
  • решающие правила средств обнаружения компьютерных атак;
  • настройки средств обеспечения информационной безопасности;
  • политики обеспечения информационной безопасности;
  • нормативные правовые акты организации;
  • дополнительные требования по обеспечению информационной безопасности для их включения в технические задания на создание новых, доработку и обслуживание существующих информационных ресурсов;
  • правила корреляции событий, направленные на определение попыток реализации угроз, связанных с проведением компьютерных атак;
  • инструкции для персонала информационных ресурсов по выявлению признаков проведения типовых компьютерных атак, порядку их обнаружения, действиям по ликвидации их последствий;
  • инструкции по действиям пользователей информационных ресурсов в случае возникновения инцидентов, связанных с компьютерными атаками;
  • требования к квалификации персонала и пользователей, необходимой для выполнения указанных выше инструкций.
Разрабатывает это все (если я правильно понял) не головной центр, а подчиненные - ведомственные и корпоративные, так как именно они и сталкиваются с атаками. Экспертиза у них должна быть ого-го какая.

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

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


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

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

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

26.04.2017

Методические рекомендации по созданию центров ГосСОПКИ (часть 1)

Сегодня, в канун дня проведения SOC Forum в Астане, я бы хотел поделиться впечатлениями от 66-тистраничного документа под названием “Методические рекомендации по созданию ведомственных и корпоративных центров государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации”, разработанного в Национальном координационном центре по компьютерным инцидентам (НКЦКИ), который курирует вопросы создания и эксплуатации ГосСОПКИ. Попавший мне в руки документ как раз и определяет, как создавать корпоративные и ведомственные центры этой национальной системы обнаружения атак.

Документ расчитан на госорганы, решившие создавать у себя ведомственные центры ГосСОПКИ, и на тех, кто решил создавать у себя корпоративные центры ГосСОПКА. В последнем случае речь идет о госкорпорациях, операторах связи и лицензиатах в области защиты информации, которые захотят помогать госорганам, госкорпорациям и операторам связи в этом непростом деле. И, как мы все понимаем, первые кандидаты на роль таких лицензиатов у нас есть. Это Solar Security, Positive Technologies, Перспективный мониторинг, Информзащита, то есть все те компании, которые активизировались в последнее время в относительно новой для России области - Security Operations Center (SOC). А ведь английская аббревиатура SOC и отечественная ГосСОПКА - это почти близнецы-братья (или сестры).  Интересно, куда относится ЦБ? А Газпром? А Роснефть? Они не являются госорганами и госкорпорациями и что, они не смогут создать в рамках своих холдингов корпоративный центр? Скорее всего это просто недогляд со стороны авторов документа - тот же FinCERT при ЦБ все называют именно ведомственным центром ГосСОПКИ.

Я не буду подробно расписывать все 66 страниц документа; коснусь только того, на что, после трех бокалов красного вина, я обратил внимание в самолете, летящем по маршруту “Москва - Астана”. Сразу скажу, что описанный документ не отвечает на все вопросы, которые могут возникнуть при создании собственного SOCа. Это скорее концепция, которая затем будет расширяться и дополняться. В методичке очень много отсылок на будущие документы, регламенты, интерфейсы взаимодействия, которые только будут разрабатываться по мере развития ГосСОПКИ. Еще одной особенностью этой методички является канцеляризм. Местами приходится продираться через вновь введенные и не сразу понятные термины. Только после вдумчивого многократного прочтения (и три бокала красного не облегчают задачу) понимаешь, что вот тут речь шла о UEBA (user entity behavior analytics), а вот тут о NBAD (network-based anomaly detection), а вот тут о SIEM.

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

Например, методические рекомендации говорят, что по ходу развития ГосСОПКИ будут определены use case (в документе их называют “типовыми инцидентами”), для которых будут даны соответствующие рекомендации по реагированию на них. Также будут определены типовые атаки, для которых будут определены документы, в которых будут прописаны IoC и порядок действий персонала при ликвидации последствий атак (предположу, что речь идет о более привычном термине “Playbook”, но это вкусовщина). При этом в 8-м разделе методички четко указаны 4 группы инцидентов и их наполнение (перечень почему-то закрытый и не расширяемый). С этим перечнем у меня возникли вопросы. Почему обычный вирус уравнен с APT? И почему центр управления бот-сетью отнесен к инциденту, а не к атаке? Или тот же спам? Или перебор паролей? Если следовать терминам, то это все-таки не инциденты, а именно атаки. Я бы этот раздел переработал, взяв за основу, какую-либо из существующих таксономий атак.

Кстати, не знаю, случайно ли, но несколько дней назад сайт МинОбороны Казахстана был взломан. И вот такая(ой) атака (инцидент), имеющая явно репутационный ущерб (если не было проникновения внутрь), в перечень инцидентов из методички НКЦКИ не входит. Не считается серьезной проблемой? Или забыли, так как российские сайты давно уже не дефейсили?


Второй не совсем понятной мне вещью стало включение динамических  IoC (могут хоть раз в день обновляться) в статические документы, еще и согласуемые с головным центром ГосСОПКИ. Вот, кстати, тоже - в тексте упоминаются головной центр ГосСОПКИ и главный центр. Я поначалу думал, что это опечатка, но потом понял, что это разные центры - один главный, а другой головной :-) Но все это не является серьезным препятствием и может быть поправлено в будущих версиях рекомендаций, которые, как мне кажется, еще будут претерпевать изменения.

Выделяется 7 защитных мер, реализуемых ГосСОПКОЙ:

  1. анализ угроз безопасности информации и рисков их реализации;
  2. контроль (анализ) защищенности информации;
  3. управление конфигурацией средств защиты;
  4. регистрация и анализ событий безопасности;
  5. выявление инцидентов и реагирование на них;
  6. обеспечение действий в нештатных ситуациях;
  7. информирование и обучение персонала,

которые по ходу раскрываются в 11 функций ГосСОПКИ (им и посвящено чуть ли не половина всего документа) и уже описываются гораздо подробнее. И вот о них мы поговорим уже завтра, когда в Астане начнет работу SOC Forum, а жители России будут скучать, ожидая майских праздников.

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

25.04.2017

Государственно-частное партнерство на примере последнего документа ФСТЭК по SOC

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

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

Предвидя закономерный вопрос, что надо было сразу делать нормально и тогда не потребовалось бы вносить изменения, отвечу. Первая версия документа писалась тоже экспертами, но работающими в отечественных компаниях, которые занимаются SOCами, что и обусловило некоторый перекос в требованиях. Я на первом заседании, на котором обсуждался этот перечень не присутствовал и не знаю, что и как там предлагалось. Но вот на последнее совещание меня позвали :-)

Общие замечания относительно этого перечня были следующими:
  • требование наличия некоторых средств защиты являются избыточными
  • требование наличия некоторых инструментов для SOC являются избыточными
  • требования по сертификации некоторых инструментов SOC являются избыточными
  • требования по аттестации на ГИС1 являются избыточными.

В итоге:
  • Средства контроля целостности были убраны из требований к лицензированию SOC.
  • Средства, предназначенные для пентестов, WAF, МСЭ, антивирус, IDS были удалены совсем, так как изначально было непонятно, для чего они нужны. Для защиты SOC или для мониторинга с помощью SOC?
  • Средства автоматизированного реагирования на инциденты объединили с другими инструментами.
  • Поменяли местами формулировки. Например, раньше мониторили средства и системы информатизации, а сейчас информационные системы; добавили термин "песочница", "системы" заменили на "средства" и т.д.
  • Сертификаты должны быть только у сканеров безопасности, SIEM и средств защиты каналов связи. Остальные решения могут обойтись формулярами, составляемыми разработчиками или лицензиатами ФСТЭК. Это было сделано для тех случаев, когда используются различные open source или freeware решения. Требования к составу и содержанию формуляра описаны в ГОСТ 19.501-78.
  • Убрали требование по нахождению SOC по адресу осуществления данного вида деятельности (виртуальные SOC вновь могут жить).
Требование наличия сертифицированных VPN (даже несмотря на то, что представители ГосСОПКИ не требовали этого) осталось. Как и требование ГИС1 к системам защиты SOC. Тут надо дать пояснения. В первоначальной версии перечня последний пункт звучал не совсем так, как об этом говорили представители ФСТЭК в частных беседах. Читалось, что сам SOC должен быть аттестован на ГИС1, включая и используемые им инструменты - SIEM, управление инцидентами, сканеры безопасности и т.п. А так как речь шла о ГИС1, то сертификация должна была быть произведена и на отсутствие НДВ, что было малореально. В итоге текущая формулировка теперь касается только системы защиты самого SOC, а не входящих в него компонентов.

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

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

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

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

24.04.2017

PlayStation 4 могли использовать для общения террористов, экстремистов и шпионов

Презабавнейший случай вновь произошел на просторах России, а точнее на ее границах. Житель Сургута решил заказать себе из Германии игровую приставку PlayStation 4, что с превеликим удовольствием и сделал, уже предвкушая вечера и ночи, проводимые у этого дьявольского изобретения, которое сжирает время, отупляет людей, разрушает семьи… Интернет у нас еще свободный, а оплата кредитными картами зарубежным лицам пока тоже не запрещены, и заказ в заграничном Интернет-магазине прошел без каких-либо проволочек. И вот настает долгожданный миг, счастливому покупателю приходит уведомление о том… нет, не о том, что его товар доставлен и его можно забрать на почте, а о том, что он нарушил законодательство, его товар будет изъят, а сам он будет оштрафован за нарушение таможенного законодательства, которое требует наличия специальных документов (нотификаций) на ввозимое в страну шифровальное оборудование. Да-да. Игровая приставка у нас считается шифровальным оборудованием, как и множество иных устройств, про которые мы даже не знаем, что они имеют встроенную криптографию, о чем я уже не раз писал (и вот тут еще).

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

Например, больше года назад (или уже два?) заказанная мной из Amazon электронная книжка Kindle была отправлена назад, так как на нее еще не было нотификации. Хорошо, что служба доставки тогда меня предупредила об этом и получив ответ, что заниматься оформлением нотификации я не буду, отправила Kindle обратно, а мне пришлось покупать ее срочно в Москве (дороже, как водится). А могли бы и оштрафовать... Когда я вез с SANSовского тренинга промышленный ИБ-симулятор Cybati с встроенным Arduino (а у него есть встроенная криптография), я тоже не особо задумыался о том, что у меня могут его изъять на границе (на него не то, что не было нотификаций, но, боюсь, и не будет никогда). А всяческая электроника с AliExpress, которая массово закупается у китайских умельцев? На нее подчас тоже нет никакой разрешительной документации.

В условиях роста Интернета вещей и желания российских граждан (как минимум, прогрессивной их части) приобщиться к новомодной тенденции, число ввозимых устройств с встроенной криптографией будет только расти. И тут впору бы задуматься о внесении изменений в таможенное законодательство, регулирующее вопросы ввоза устройств, содержащих функции шифрования для частного применения. Но… в этом плане я скептичен, так как помню еще эпопею с принятием последнего пакета поправок в эти нормативные акты, которые обсуждались и принимались в 2009-м году. Ведь мы живем по этим правилам уже 7 лет, с 1-го января 2010 года. Технологии и индустрия за это время сделали гигантский скачок вперед, а вот нормативная база осталась прежней :-(

ЗЫ. Вообще PlayStation 4 имеет нотификацию, но заказанная модель нет.

ЗЗЫ. Перечитал заметку и удивился. Как это мне удалось написать про эту тему и ни разу не упомянуть ФСБ :-) Да-да, куратором изменений в данное законодательство у нас является ФСБ и я не предвижу в текущих условиях изменений ситуации в лучшую сторону.

20.04.2017

Борьба с фишингом. Пошаговая инструкция

Выкладываю презентацию с мастер-класса по борьбе с фишингом, которую читал на CISO Forum 2017 в Москве. Это чуть более подробная версия, чем та, что читалась (часть слайдов в рамках выступления я скрыл, чтобы хватило времени за час все рассказать). Но есть и более полная версия, раскрывающая в деталях вопросы использования отдельных инструментов злоумышленников (тот же Social Engineering Toolkit, Evilginx, Punycode и др.) и защитных мер (фишинговые симуляторы, обучение сотрудников и т.п.). Полный вариант у меня занимает около 4-х часов.


Борьба с фишингом. Пошаговая инструкция from Aleksey Lukatskiy

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

Анатомия атаки:


Подбор фальшивых доменов с помощью URLcrazy:



Сбор контактных данных с помощью TheHarvester:



Сбор контактных данных с помощью Recon NG:



Поиск фальшивых и вредоносных доменов с именем sberbank в названии доменов:



Клонирование сайта с помощью Clone Zone:



Клонирование сайта с помощью SET:



Организация Spear Phishing с помощью SET:




12.04.2017

Accenture покупает iDefense

Компания Accenture объявила 3 апреля о завершении сделки по приобретению у VeriSign подразделения iDefense Security Intelligence Service, которая была анонсирована в феврале.

07.04.2017

Тенденции в области кибербезопасности Industrial IoT (презентация)

На Cisco Connect среди четырех прочитанных мной презентаций была и одна, практически не имеющая привязки к решениям Cisco, поэтому осмелюсь ее выложить сюда. Посвящена она некоторым последним трендам в области кибербезопасности Industrial IoT или просто промышленных сетей.