Регуляторы, ВСЕГЕИ или что такое MDM из ГОСТ 57580.1?

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

Возьмем, к примеру, ГОСТ 57580.1 имени Банка России, в котором, есть раздел 7.9, посвященный базовому составу мер защиты информации при осуществлении удаленного логического доступа с использованием мобильных (переносных) устройств. По сути, данный раздел, посвящен не только смартфонам и планшетам, а вообще любым переносным устройствам, включая и ноутбуки. И вроде бы все меры в этом разделе вполне понятны и реализуемы, если бы не одно но... А именно использование англоязычных аббревиатур для описания средств защиты, которые могут помочь реализовать ту или иную меру по защите. Например, MDM (Mobile Device Management), которые упомянуты в ЗУД.3 и ЗУД.10.

Эта аббревиатура, а равно и MAM, MCM, MSM, MEM, MIM и EMM, исторически была связана только с мобильными устройствами типа смартфон и планшет. Ни к каким других устройствам она не применялась, так как также исторически сложилось, что управление безопасность мобильных устройств отличается от управления безопасностью оконечных устройств (или, как их называет ЦБ: конечных точек) в виде стационарных компьютеров под управлением Windows, Linux, macOS и т.п. И если перед службой ИБ стояла задача защитить смартфоны и планшеты под управлением iOS или Android, то в голове сразу всплывала аббревиатура MDM. Причем надо отметить, что MDM - это управление мобильным устройством, а не обеспечение его безопасности. В контексте ИБ появились аббревиатуры MSM или MDSM, где буква S и означала безопасность (security).

MDM родила и схожие аббревиатуры - MAM (mobile application management), MCM (mobile content management), MIM (mobile information management) и т.д. В 2014-м году главный любитель новых аббревиатур, компания Gartner, ввела в обиход EMM - Enterprise Mobility Management, то есть класс решений, который включал в себя все аббревиатуры, начинающиеся с "M".

Но время шло, производители стали выпускать то, что было сложно относить к одной из четырех привычных категорий - смартфон, планшет, ноутбук, стационарный ПК. Более того, процесс "мобилизации" предприятий пошел так быстро, что классические мобильные устройства стали обладать всем набором ранее присущих только стационарным ПК свойств. Разве, что операционные системы пока использовались разные. Встал вопрос - может быть унифицировать функции управления всеми устройствами, на которых работают пользователи? Так родилась очередная аббревиатура - UEM (Unified Endpoint Management) и все классические игроки рынка MDM (MobileIron, SAP, Samsung, Blackberry, IBM, Citrix, Microsoft, VMware, Cisco и т.п.) стали относить свои решения к UEM, оснастив соответствующим функционалом. В итоге, найти сейчас на рынке классический MDM почти невозможно :-)

Но от экскурса в историю вернемся к стандарту Банка России, который использует именно аббревиатуру MDM. Лично для меня, это не столь существенно и я прекрасно понимаю, что данные раздел ориентирован не только на смартфоны и планшеты, а касается всех типов мобильных устройств, с которых можно осуществить удаленный доступ. Сейчас, во время пандемии и перехода на удаленку, эти устройства могут быть абсолютно любыми, не ограниченными только возможностью запуска на них ОС iOS, Android, "Авроры" или Sailfish. Поэтому для меня упомянутая в ГОСТ 57580.1 аббревиатура MDM не имеет никакого значения и я спокойно заменяю ее на MDSM, MSM, EMM или UEM, так как понимаю, что ГОСТ требует централизованного управления и мониторинга для переносных устройств, независимо от используемой ОС. Это логично. Но...

Недавно, в одном Telegram-канале возникла тема, в которой автор спрашивал, как реализовать ЗУД.3 и ЗУД.10 применительно к ноутбукам с Windows. На очевидный ответ, что ровно также, как и для обычного компа (СЗИ от НСД, EDR/антивирус, разграничение доступа, DLP и другие меры защиты из ГОСТ), последовал ответ, что вот же есть обязанность использовать MDM-решение. На комментарии, что тут важно соблюсти дух ГОСТа, а не буквоедствовать, топикстартер резонно заметил, что это с проверяющими из ЦБ не работает и они будут тупо требовать наличия именно MDM-решения. Не MSM (Mobile Security Management), не EMM, и даже не UEM, а именно MDM. В результате, вместо обсуждения того, как защитить пользовательские устройства на удаленке, дискуссия ушла в споры о том, что надзор можно ткнуть в то, что эта англоязычная аббревиатура вообще нигде не определена и что скрывается за тремя буквами никто не знает. А надо напирать на то, что используется не MDM, а система централизованного управления и мониторинга, под которую уже попадают и решения класса UEM и все остальные. Хотя гарантии, что это пройдет, никто не дает. Проверяющие бывают излишне въедливыми и прямолинейными - написано MDM, подавай MDM.

И ведь сама по себе проблема не стоит и выеденного яйца. Все всё понимают. Но раз уж речь идет о требованиях регулятора, то хотелось бы однозначности трактовок и либо отказа от использования аббревиатур типов защитных средств (достаточно вспомнить историю с аббревиатурами EDR, STAP им EVC, которые означают одно и тоже, только придумано разными аналитическими агентствами), либо их четкого объяснения в том же самом документе. Но лучше, конечно, не использовать такие аббревиатуры вообще.

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

ЗЫ. Надо было найти картинку для заметки и я сразу вспомнил про одну конференцию по ИБ, в которой я участвовал онлайн во время пандемии. Меня на нее пригласили достаточно заранее и я внес ее в свой календарь, но так как это было сделано впопыхах, то адрес сайта конференции я внести забыл. И вот за день до начала, пытаясь вспомнить, какую тему я назвал для своего выступления, я стал судорожно искать в Интернете сайт конференции, ориентируясь на ее название. И в первой десятке сайтов, услужливо предложенных мне Google, нашелся сайт Всероссийского научно-исследовательского геологического института, аббревиатура которого звучит как ВСЕГЕИ :-)

ЗЗЫ. Используя какие-либо названия и аббревиатуры в нормативных документах стоит помнить про закон письменной речи Майерса: "Все, что может быть понято неправильно, будет понято неправильно". К терминологии этот закон применим как никакой другой.

Подробнее…

Является ли ГОСТ по ИБ обязательным к применению?

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

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

Правительство в стороне не осталось и спустя полтора года с момента принятия ФЗ-162 выпустило свое Постановление под номером 1567 (оно отменило ранее действующее ПП-822 на ту же тему), которое утвердило два положения:

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

"Нашу" тему затрагивает второе положение. Оно очень короткое - в нем всего 10 пунктов (по сравнению с полусотней в положении о стандартизации оборонной продукции".

Согласно нему стандартизацией ИБ у нас занимаются ФСТЭК, ФСБ, МинОбороны и СВР, а утверждает разработанные ими стандарты Росстандарт. ЦБ в списке нет.

Предметом стандартизации этих ГОСТов (в том числе и ограниченного распространения) является продукция и связанные с ней процессы. Предметом регулирования ГОСТ 57580.1 является не продукция и не процессы, а уровни и требования.

Отсюда возникает закономерный вопрос - на каком основании ГОСТ Р 57580.1 считается обязательным? В самом стандарте написано, что область его применения устанавливается в нормативных актах Банка России путем включения в них ссылки на ГОСТ, что разрешено 27-й статьей закона "О стандартизации в Российской Федерации". Ни слова про то, что ГОСТ в этом случае является обязательным. Так является ли он таковым?

Стоит обратиться к другим нормативным правовым актам. В частности к Положению Банка России от 22.09.2017 №602-П "О правилах подготовки нормативных актов Банка России", в котором перечисляются нормативные и ненормативные акты Банка России:

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

Разумеется, не все нормативные акты ЦБ подлежат регистрации. Но согласно 602-П список нерегистрируемых документов четко определен и ГОСТы к их числу не относятся.

Согласно же разъяснениям МинЮста, утвержденным приказом от 04.05.2007 №88, национальные стандарты можно не регистрировать, но только если они не содержат нормативных предписаний. Поэтому получается, что если рассматривать ГОСТ 57580.1 как содержащий такие предписания, то он должен быть зарегистрирован МинЮстом, а это условие выполнено не было и, как следствие, применению этот ГОСТ не подлежит. Если же рассматривать ГОСТ просто как сборник рекомендаций, то тогда все нормально - это руководство к действию, но не более. Обязать его исполнять и тем более наказывать за его неисполнение нельзя.

Ну и еще. Вспоминая законы "О Центральном банке" и "О Национальной платежной системе", Банк России имеет право устанавливать обязательные требования по защите информации, но только по согласованию с ФСБ и ФСТЭК. Согласно уже упомянутому Положению Банка России 602-П, нормативный правовой акт считается совместно изданным, если он подписан/утвержден руководителями соответствующих ФОИВ, то есть в нашем случае с ФСТЭК и ФСБ.  Те же 382-П, 683-П, 684-П были согласованы с указанными регуляторами по ИБ. И соответствующий гриф согласования должен быть на совместно принятом нормативном правовом акте. А вот ГОСТ 57580.1 это требования снова нарушает - никаких согласующих грифов на нем нет.

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

Подробнее…

Банк России разъясняет. СПФС, СТО, ФЗ-161 ии др.

Ответы Банка России на оставшиеся разные вопросы, поступившие от отрасли.

1. Осталась ли для кредитных организаций, не подключившихся к СПФС, обязанность раз в квартал проводить контроль технической защиты информации? Или данная обязанность осталась только для участников СПФС?

Ответ: Контроль (мониторинг) использования технических средств защиты информации закреплен п. 2.14.5 действующей редакции положения 382-П за службой информационной безопасности ОПДС и ОУПИ. В отношении СПФС порядок оказания услуг регламентируется Указанием Банка России от 20.09.2019 № 5263-У, а остальные требования защиты определяются Договором на оказание услуг.

2. Необходимо ли в данный момент выполнять требования СТО Банка России? Если нет, то какова процедура отсоединения от данного стандарта? Необходимо ли уведомлять об отсоединении Банк России? Если да, то необходимо ли и дальше присылать результаты оценки соответствия наряду с отчетностью по 382-П и 57580.2?

Ответ: Требования стандартов Банка России носят рекомендательный характер. В связи с принятием Положения Банка России от 17.04.2019 № 683-П «Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента» требования, установленные национальным стандартом Российской Федерации ГОСТ Р 57580.1-2017 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер», утвержденным приказом Федерального агентства по техническому регулированию и метрологии от 8 августа 2017 года № 822-ст «Об утверждении национального стандарта» (далее - ГОСТ Р 57580.1-2017), являются обязательными.

3. Что понимается под «незамедлительным уведомлением при списании средств» согласно 161-ФЗ и 5039-У? В СТО 1.5, а также в 4926-У говорится о том, что в случае владения незначимыми объектами КИИ уведомление осуществляется в течение 24 часов. Не будет ли направление уведомления в течение 24-х часов рассматриваться как нарушение требования незамедлительности?

Ответ: На основании части 11.1 статьи 9 Федерального закона от 27.06.2011 № 161-ФЗ «О национальной платежной системе» (далее – Федеральный закон № 161-ФЗ) при получении от клиента - юридического лица уведомления, указанного в части 11 статьи 9 Федерального закона № 161-ФЗ, после осуществления списания денежных средств с банковского счета клиента оператор по переводу денежных средств, обслуживающий плательщика, обязан незамедлительно направить оператору по переводу денежных средств, обслуживающему получателя средств, уведомление о приостановлении зачисления денежных средств на банковский счет получателя средств или увеличения остатка электронных денежных средств получателя средств (далее - уведомление о приостановлении) по форме и в порядке, которые установлены нормативным актом Банка России.

Согласно пункту 1 Указания № 5039-У оператор по переводу денежных средств, обслуживающий плательщика, при получении от клиента - юридического лица уведомления об утрате электронного средства платежа и (или) о его использовании без согласия клиента должен незамедлительно направить оператору по переводу денежных средств, обслуживающему получателя, уведомление о приостановлении в виде электронного сообщения, позволяющего воспроизвести его на бумажном носителе.

В соответствии с пунктом 1.4 Указания № 4926-У оператор по переводу денежных средств, обслуживающий плательщика, оператор услуг платежной инфраструктуры - субъекты критической информационной инфраструктуры, которым на праве собственности, аренды или ином законном основании принадлежат значимые объекты критической информационной инфраструктуры, определяемые в соответствии с Федеральным законом от 26 июля 2017 года № 187-ФЗ "О безопасности критической информационной инфраструктуры Российской Федерации", должны направить в Банк России первичное уведомление в течение трех часов с момента наступления событий, указанных в абзацах четвертом и шестом пункта 1.3 Указания № 4926-У, и в течение одного рабочего дня, следующего за днем наступления событий, указанных в абзацах втором, третьем и пятом пункта 1.3 Указания № 4926-У.

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

• в случаях, указанных в абзацах четвертом и шестом пункта 1.3 Указания № 4926-У, - в течение 24 часов с момента наступления событий, указанных в пункте 1.3 Указания № 4926-У;
• в случаях, указанных в абзацах втором, третьем и пятом пункта 1.3 Указания № 4926-У, - в течение одного рабочего дня, следующего за днем наступления событий, указанных в пункте 1.3 Указания № 4926-У.

Таким образом, в указанных нормах Федерального закона № 161-ФЗ, Указании № 5039-У указано требование о незамедлительном направлении операторами по переводу денежных средств друг другу уведомлений о приостановлении. Сроки, содержащиеся в Указании № 4926-У, относятся к направлению в Банк России уведомлений о случаях и попытках осуществления переводов денежных средств без согласия клиента. Следовательно, указанные сроки не могут рассматриваться в качестве тождественных.

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

4. Согласно 161-ФЗ «оператор по переводу денежных средств, обслуживающий плательщика, должен незамедлительно направить оператору по переводу денежных средств, обслуживающему получателя» в случае несанкционированного списания средств. Согласно 5039-У для такого уведомления должна использоваться техническая инфраструктура Банка России, то есть ФинЦЕРТ. Получается, что мы направляем уведомление не оператору, обслуживающему получателя, а Банку России. Не нарушаем ли мы тем самым законодательство?

Ответ: На основании части 11.1 статьи 9 Федерального закона № 161-ФЗ при получении от клиента - юридического лица уведомления, указанного в части 11 статьи 9 Федерального закона № 161-ФЗ, после осуществления списания денежных средств с банковского счета клиента оператор по переводу денежных средств, обслуживающий плательщика, обязан незамедлительно направить оператору по переводу денежных средств, обслуживающему получателя средств, уведомление о приостановлении по форме и в порядке, которые установлены нормативным актом Банка России.

Согласно пункту 3 Указания № 5029-У оператор плательщика, оператор получателя (далее при совместном упоминании - операторы) должны направлять уведомление о приостановлении, уведомление о невозможности приостановления (далее при совместном упоминании - уведомления) с использованием технической инфраструктуры (автоматизированной системы) Банка России, указанной в пункте 1.2 Указания № 4926-У.

Таким образом, уведомления направляются операторами друг другу, техническая инфраструктура (АСОИ ФинЦЕРТ) является каналом взаимодействия.

5. Планируются ли к разработке и, если да, то когда, нормативные акты Банка России, регулирующие вопросы защиты информации в проектах по цифровому профилю, Мастерчейне и финансовом маркетплейсе?

Ответ: Банк России участвует в рассмотрении проектов федеральных законов в сфере инновационных финансовых технологий (например, проект федерального закона № 419059-7 «О цифровых финансовых активах», проект федерального закона № 617867-7 «О совершении сделок с использованием электронной платформы»).

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

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

Подробнее…

Банк России разъясняет. ГОСТ 57580.1

Ответы Банка России на вопросы по ГОСТ 57580.1, поступившие от отрасли.

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

Ответ: Для подтверждения статуса средства защиты информации от вредоносного кода необходима сертификация уполномоченным органом государственной власти (ФСТЭК).

Примечание от меня: неожиданно. ФСТЭК только антивирусы сертифицирует и то, только те, которые поданы на сертификацию, то есть обычно коммерческие решения.

2. Какие варианты реализации меры СМЭ.14 могут быть, если все представленные сегодня на рынке средства межсетевого экранирования, работают на третьем уровне и выше, а СМЭ.14 требует контроля на уровне не выше второго, канального? Или речь идет о разграничении доступа и контроле трафика на интерфейсах периметрового маршрутизатора? 

Ответ: Примером реализации меры СМЭ.14 может служить организация выделенных VLAN на уровне L2.

3. Возможно, в содержании меры СМЭ.15 вместо фразы «не выше» должно было быть написано «не ниже»? Можно назвать примеры типов средств, которые могут реализовать данную меру? 

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

4. Можно ли в качестве средства реализации меры СМЭ.16 использовать коммутаторы и маршрутизаторы, которые могут фильтровать трафик не только на сетевом уровне?

Ответ: Можно. Все зависит от конкретных средств и задач, и данный вид реализации можно считать частным.

5. По тексту стандарта часто используется термин «межсетевое экранирование». Надо ли его трактовать буквально и для его реализации применять только специализированные межсетевые экраны или возможно применение любых технических средств, которые могут обеспечить разграничение доступа на сетевом уровне? 

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

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

6. Можно ли в качестве средства реализации меры СМЭ.2 использовать коммутаторы и маршрутизаторы, которые могут фильтровать трафик на сетевом уровне? Или обязательно использовать только отдельно стоящие межсетевые экраны, что во внутренней коммутируемой сети может быть затруднительно? 

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

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

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

8. Оценка соответствия по ГОСТ 57580.1 для участка АБС, который является также и участком ЕБС, должна проводиться один раз в два года, как написано в 683-П, или один раз в год, как написано в 321-м приказе Минкомсвязи?

Ответ: Проведение оценки соответствия по ГОСТ 57580.1 должно осуществляться ежегодно для сегмента, на котором осуществляется обработка биометрических персональных данных в соответствии с 321 приказом Минкомсвязи. Проведение оценки соответствия не реже одного раза в два года осуществляется по требованиям Положений 683-П и 672-П применительно к соответствующим объектам информационной инфраструктуры (не пересекающихся с участком ЕБС).

Завтра будут ответы по 684-П.

Подробнее…

Планы по стандартизации ИБ финансовых организаций

Сегодня утром проходило заседании ПК1 ТК122 Банка России, посвященное стандартизации ИБ в финансовых организациях, на котором решалось 3 вопроса:

• обсуждение и голосование за ГОСТа 57580.2 по оценке соответствия защитных мер, описываемых ГОСТом 57580.1 (единогласно при одном воздержавшемся)
• обсуждение и голосование за СТО по безопасности аутсорсинга (единогласно)
• обсуждение планов подкомитета по разработке новых стандартов по ИБ.

В качестве резюме хочется тезисно отметить следующее:

• ЦБ выделяет для себя на ближайшие годы (до 2021 года) 5 направлений развития - управление киберрисками, взаимодействие с поставщиками услуг, управление инцидентами, киберустойчивость и мониторинг киберрисков и ситуационная осведомленность.
• Стандарт по киберрискам - это реинкарнация СТО 1.0, который был посвящен преимущественно вопросам управления ИБ и управления рисками. В недавно принятом ГОСТ 57580.1 описаны защитные меры (то есть вопросы уровнем ниже). Отсюда логичное желание регулятора трансформировать СТО 1.0 в ГОСТ, что постепенно и будет происходить. Пока же СТО 1.0 (как и СТО 1.2) остаются и отменять их никто не будет. В паре с этим ГОСТом будет и стандарт по оценке соответствия (также в статусе ГОСТа).
• Сам комплекс стандартов по ИБ (СТОБР) продолжит существовать и будет выполнять методологическую функцию. По сути на нем будут апробировать различные направления, которые затем будут входить в состав ГОСТов или нормативных актов Банка России.
• СТО 1.3 по сбору данных для расследования инцидентов и РС 2.5 по менеджменту инцидентов трансформируются в соответствующие ГОСТы, к которым добавится третий стандарт по обмену информацией об ИБ между финансовыми организациями и ФинЦЕРТом.
• Появится ГОСТ по аудиту, приходящий на смену СТО 1.1.
• Планируемый сейчас СТО по ИБ аутсорсинга трансформируется со временем в ГОСТ. А в пару к нему появится стандарт по ИБ при использовании информационных сервисов.
• Ранее неоднократно упоминаемая тема по киберустойчивости трансформировалась в ГОСТ по обеспечению непрерывности выполнения бизнес и технологических процессов (и тут АСУ ТП :-) и ГОСТ по оценке соответствия этим требованиям.
• Наконец, пятым направлением станет разработка ГОСТа по мониторингу киберрисков (модная тема) и ситуационной осведомленности и ГОСТа по оценке соответствия в данной сфере. 

Визуально, план работы ПК1 ТК122 Банка России я бы отразил примерно так (серым показано то, что уже разработано и практически принято):

Помимо этого я бы отметил несколько интересных тезисов, прозвучавших на мероприятии:

• Планируемый в свое время СТО по некредитным финансовым организациям (а точнее два СТО) плавно перетечет в ГОСТ 57580.1. Ну тут никаких сюрпризов - это было логично; зачем городить СТО, если новый ГОСТ и так покрывает НКФО. Ну и остальные ГОСТы, упомянутые выше, будут учитывать специфику НКФО. 
• Во исполнении пунктов ГОСТа и новой редакции 382-П, требующих оценки соответствия платежных и финансовых приложений (в виде сертификации или оценки уязвимостей), ЦБ подготовил профиль защиты, направленный в ФСТЭК России на согласование. Соответственно разработчикам банковского и финансового ПО стоит подготовиться к данной процедуре.
• Аккредитации поставщиков услуг аутсорсинга ИБ не планируется, а вот тема некой "аккредитации" (хотя скорее это некоторая форма оценки качества работ) аудиторов поднималась и в каком-то виде будет реализована. Либо это будет добровольная сертификация, либо саморегулируемая организация. Вопрос пока в стадии обсуждения.
• ЦБ активно копает тему страхования киберрисков, но каких-то конкретных действий и стандартов не озвучено. Какая-то ясность будет на Магнитогорском форуме, регистрация на который уже началась.
• Применительно к теме КИИ ЦБ никаких документов не планирует выпускать. Регулятором является ФСТЭК и именно она пишет требования к безопасности значимых объектов КИИ. ФСБ в свою очередь устанавливает требования по присоединению финансовых организаций к ГосСОПКЕ. По оценка ЦБ, и я с ними согласен, не очень много финансовых организаций будет иметь значимые объекты. А вот отправлять данные по инцидентам в ГосСОПКУ придется. Правда тут мы с ЦБ не сходимся во мнении. Они считают, что ФинЦЕРТ является ведомственным центром ГосСОПКИ и финансовые организации смогут без проблем направлять данные об инцидентах только в одну сторону, в ФинЦЕРТ, который уже сам все направит в ГосСОПКУ. Я по формальным признакам с этим не согласен, но буду рад ошибиться.
• Новая редакция 382-П (я о ней писал) находится на согласовании в ФСБ и скоро должна быть отправлена в Минюст на утверждение. Предположу, что это произойдет достаточно скоро и она вступит в действие (как и новая редакция 2831-У) с 1-го июля 2018-го года. Самое главное, что в ней не будет ссылок на новый ГОСТ 57580.1. Это произойдет в следующей версии 382-П, работа над которой начнется сразу после принятия текущего проекта. В принципе это было известно давно, но многие почему-то считали, что принятие в августе нового ГОСТа означает, что теперь на него ЦБ вставит ссылки во все свои нормативные акты. Это не так. Процесс небыстрый и требует, как минимум, разработки всей номенклатуры основных ГОСТов по защите информации и управлению киберрисками, что также займет определенное время.

Вот такой набор новостей по тому, что ЦБ готовит финансовым организациям с точки зрения нормативных требований. Обратите внимание, что на организации возрастет нагрузка по выполнению требований и, самое главное, оценке соответствия им. Запланирована разработка 5 стандартов по оценке соответствия и это помимо оценки, предусмотренной 382-П, а также иными требованиями, распространяющимися на финансовые организации (PCI DSS, SWIFT и т.д.). Вот такие дела...

Подробнее…

Управление логами - фундамент любой SIEM, в котором часто зияют прорехи

Уже совсем скоро пройдет конференция ЦБИ "Мониторинг ИБ: проблемы построения и эксплуатации", на которой я буду вести секцию про полноту и "доступность" источников информации, которые подключаются к SIEM, а потом на их основе работает SOC и принимаются решения о наличии или отсутствии угроз. По сути именно от того, насколько выстроена работа с источниками зависит эффективность всей системы кибербезопасности.

Давайте вспомним вот эту иллюстрацию двухнедельной давности:

В ней атомарным элементом считаются логи. Все логи сразу. Многие компании, да и производители SIEM, могут сказать, что уже они то выстроили достаточно зрелый, может быть даже на пятом уровне, процесс управления логами. И в принципе, не сильно задумываясь, мы можем с ними согласиться, так как о том, как работать с логами, как одним из источников информации ИБ, говорят уже много лет и даже десятилетий. Первые хостовые IDS, появившиеся в начале 80-х годов, как раз опирались в своей работе на данные из журналов регистрации. Можно предположить, что уж с логами-то за почти 40 лет у нас научились работать. Но история умеет преподносить сюрпризы. Вот так выглядит слайд из вчерашней презентации Антона Чувакина из Gartner, который рассказывал про технологию пользовательской поведенческой аналитики (UEBA):

Обратите внимания на первый пункт в списке основных проблем при внедрении и использовании UEBA - сбор данных, их доступность и качество. И это спустя 40 лет после появления первых хостовых IDS и 20 лет после появления первых SIEM. А ведь SIEM, которые в принципе должны уметь работать с источниками данных, потом отдают информацию в UEBA, а также иные системы аналитики ИБ.

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

Какие проблемы можно выделить при работе с источниками информации? Их немало:

• Множество источников. Это примерно как с DLP, которые вроде и борются с утечками, но когда начинаешь копать, то оказывается, что 2/3 коммуникационных каналов в вашей компании они вообще не отслеживают.
• Противоречивость данных. Например, в одном источнике у вас указан IP-адрес, но нет, допустим, имени пользователя, а в другом наоборот - имя пользователя есть, а IP-адреса нет. И как связать такие данные между собой? А вот еще простой пример. В одном логе у вас время события записано в формате DD-MMM-YYYY, а в другом - MMDDYYYY. Хорошо, если система управления логами, приводит все к единому формату, а если нет?
• Противоречивость временных меток. Ну тут все понятно и дело даже не в разных часовых поясах, в которых могли происходить события, а в отсутствии системы синхронизации, что может привести, например, к ситуации, когда в SIEM числится, что события А произошло после события Б через 66 секунд, а на самом деле оно произошло до - на 15 секунд.
• Множество разных форматов. XML, JSON, syslog, CSV (с разделениями табуляцией или запятыми), SNMP, REST, базы данных и др.
• Незащищенность логов. Кто мешает злоумышленнику удалить какие-то записи из источника информации или, что еще хуже, подменить их, создавая и поддерживая ложное чувство защищенности? А что с доступностью источников информации?
• Способы доступа к источникам информации. Часто в описании SIEM/LM написано, что они поддерживают потоковые данные из syslog (а Netflow как, кстати?) и удаленный доступ к логам через API и удаленный доступ. А что с агентами? Некоторые данные без агентов не вытащить и не проанализировать.
• Неструктурированные данные. Правда, это не совсем задача SIEM или LM, но без них сегодня сложно проводить серьезную аналитику и принимать решения и поэтому стоит задуматься об этой теме заранее.
• Отсутствие стандартов или отказ от поддержки вендорами уже существующих стандартов. RDEP, CEE, SDEE, IODEF, RID, SecDEF... Их поддерживают средства защиты или системы анализа?

Разумеется, все эти проблемы могут быть решены, но об этом все-таки лучше поинтересоваться у производителя SIEM/UEBA/NTA/IDS и других ИБ-решений. Ну а если вы пишете систему защиты/аналитики сами, то просто подумайте, как вы будете решать эти проблемы? Вот именно этим вопросам и будет посвящена секция на конференции ЦБИ, которую я модерирую. Выступать в ней будут представители:

• ЦБИ, которые недавно выпустили свою SIEM Neurodat,
• НТЦ Вулкан, которые активно развивают направление SIEM в своих проектах,
• Infowatch
• Код безопасности
• РТ-Информ
• R-Vision

и их ждут непростые вопросы от меня :-)

Подробнее…

Мониторинга много не бывает или зачем вам SOC, если у вас нет SIEM?

Осень выдается достаточно урожайной на мероприятия, посвященные теме мониторинга информационной безопасности. И на многих из них я часто слышу вопрос от коллег, который звучит очень просто: “Что должен уметь делать SOC?”. Как мне кажется, если такой вопрос возникает, то это значит, что компания еще не готова к SOC, так как в отличие от коробочных продуктов, сравниваемых по функциям/возможностям, SOC строится под конкретную компанию, под конкретную задачу. Поэтому бессмысленно спрашивать, что должен уметь делать SOC. Важнее понять, зачем он нужен и что будет делать, если компания решится инвестировать в него деньги. По этой же причине совершенно бестолково сравнивать SOCи между собой. Даже если они и построены на базе общих технологических решений, они могут решать совсем разные задачи, затачиваться под разные сценарии (use cases).

Посмотрите на эту картинку:

Она иллюстрирует упрощенную модель зрелости процесса управления журналами регистрации (log management). На каком уровне вы находитесь? Ответье честно сами себе. Если вы не достигли финального, пятого уровня (то, что находится в самом низу - это нулевой уровень), то о каком SOC может идти речь? Впору задуматься о SIEM, системе мониторинга ИБ. Кстати, неслучайно в нормативных документах той же ФСТЭК говорится о сборе событий безопасности, а не о мониторинге; это высший пилотаж, который могут потянуть далеко не все. Да, отсутствие NTA, EDR, UEBA, IRP (SOAR), CASB и других технологий тоже говорит, что вам пока рано думать о SOC, но управление логами - это основа основ мониторинга ИБ.

Я уже не раз писал, что в России не хватает фокусных мероприятий по тем или иным темам. Да, есть SOC Forum, целиком посвященный центрам мониторинга ИБ. Но в нем, по сути, мы перескочили через базу - через системы мониторинга (SIEM), без которых SOC не построишь. Хотя вон “Перспективный мониторинг” везде говорит, что у них в SOC нет SIEM, а все базируется на системе TIAS собственной разработки. Кстати, собственные разработки в области SIEM - это один из трендов российского рынка. Как раньше все разработчики создавали DLP-решения, так сейчас пришла пора для систем мониторинга, нужда в которых есть, а применять решения зарубежные боязно. Кто-то санкций боится, кому-то и вовсе запрещено применять иностранное, а кому-то нужно решение сертифицированное.

И вот на фоне этих обстоятельств и родилось еще одно мероприятие, которое пройдет 21-го ноября в Москве. Речь идет о научно-практической конференции “Мониторинг информационной безопасности - проблемы построения и эксплуатации”, проводимой ЦБИ. Когда я узнал об этом мероприятии (а меня пригласили модерировать одну из его секций), то у меня возник закономерный вопрос. 22-го же ноября проходит SOC Forum; не будет ли пересечения у этих двух событий, посвященных схожей теме? Но внимательно посмотрев на предварительную программу и пообщавшись с организаторами, я склоняюсь к мысли, что пересечений у конференции ЦБИ и SOC Forum будет немного.

Во-первых, мероприятие ЦБИ фокусируется на системах (SIEM), а не центрах (SOC) мониторинга. На нем будут говорить про масштабирование SIEM, работу с разными источниками данных, их нормализацию, оценку полноты данных и т.п. То есть речь пойдет одновременно и о научных аспектах, и о практических. Во-вторых, конференция “Мониторинг информационной безопасности” организована известным российским вендором со сложившейся клиентской базой. Поэтому предположу, что целевые аудитории у двух мероприятий будут разные. Кстати, это будет не совсем моновендорная конференция - в программе заявлены представители разных игроков рынка - Microsoft, РТ-Информа, Кода безопасности, НТЦ Вулкан, НИИАС, Infowatch, Крока, СолидЛаб, Газинформсервиса, ГНИВЦ ФНС и т.п. (это помимо ряда крупных заказчиков, которые будут делиться своим опытом применения систем мониторинга ИБ). В третьих, у мероприятия ЦБИ заявлено еще два интересных момента - объявление грантов на инновационные разработки в области мониторинга ИБ и сбор и формулирование предложений по совершенствованию нормативной базы в области мониторинга ИБ. Учитывая активную работу ЦБИ с отечественными регуляторами, может получиться донести до ФСТЭК, начавшей лицензирование SOC, и ФСБ, планирующей аккредитацию центров ГосСОПКИ, определенные правильные мысли. А если вспомнить, что на отдельных слайдах ФСТЭК в свое время проявлялась тема разработки требований по сертификации SIEM, то становится еще интереснее...

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

Подробнее…

О стандарте ЦБ по ИБ аутсорсинга

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

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

Спустя две недели выходит статья в Коммерсанте и она тоже посвящена этому проекту стандарта. К журналисту у меня вопросов нет :-) Есть к эспертам, которые комментируют стандарт в статье. По их мнению есть следующие проблемы у стандарта:

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

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

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

При этом, когда мы выбираем облачного провайдера для своих нужд, а мы пользуемся услугами около 700 облачных провайдеров по всему миру, то это тоже непростая процедура, которая у нас формализована в так называемой процедуре CASPR (Cloud and Application Service Provider Remediation), состоящей из множества элементов, часть из которых требует определенной формализации и документированию:

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

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

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

Стандарт состоит из следующих разделов:

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

Вот такая картина с этим стандартом, который могут принять в ближайшее время и он вступит в действие с 1-го января 2018-го года.

Подробнее…

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

Пришла пора сформулировать свои впечатления от последних инициатив ЦБ по части нормотворчества, а таких инициатив по-крупному было две:

• утвержденная финальная редакция ГОСТа с базовыми защитными мерами для финансовых организаций
• проект новой редакции 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-го года (но это мои предположения).

Подробнее…

АБС и финансовые приложения должны быть сертифицированными. Так сказал ЦБ

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

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

Позиция ЦБ понятна - разработчики АБС не спешат повышать качество своего ПО с точки зрения безопасности, чем и пользуются злоумышленники. Поэтому ЦБ, уже по традиции, устанавливает требования для своих подопечных, которые должны будут заставить разработчиков прикладного ПО выполнить требования ГОСТа. Такой же фокус был проделан и в 552-П, который обязал перенести функцию электронной подписи из АРМ КБР в АБС.

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

Требования ОУД4

С предложенным ЦБ уровнем доверия ОУД4 есть тоже нюансы. Согласно ГОСТу "ОУД4 – самый высокий уровень, на который, вероятно, экономически целесообразно ориентироваться при оценке уже существующих продуктов". При это необходимо с помощью выборочного независимого анализа уязвимостей продемонстрировать противодействие попыткам проникновения нарушителей, обладающим усиленным базовым потенциалом нападения. Базовым?! Но ломающие те же банки нарушителя врядли могут быть отнесены к базовому потенциалу нападения (даже усиленному). А значит и проверки тут нужны более глубокие, то есть ОУД6, а то и ОУД7. Но это уже будет за гранью разумного. И возникает вопрос - обеспечивает ли ОУД4 эффективное противодействие действиям злоумышленников или это просто некоторая золотая середина, которая должна отсечь разработчиков, явно неспособных хотя бы задумываться о безопасности своих творений?

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

Подробнее…

ЦБ вводит обязательную сертификацию средств защиты информации

Хочу вернуться к недавно мной описанному проекту ГОСТа ЦБ с набором базовых защитных мер для финансовых организаций. На днях на сайте ТК122 появился практически финальный проект этого документа, который 13-го апреля будет обсуждаться в ЦБ и, возможно, будет вынесено на голосование его принятие.

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

Надо признать, что на прошлом заседании ПК1 ТК122 эта тема также озвучивалась, так как в первом проекте также было указано про сертифицированные средства защиты, но не про все, а только про СВТ, МСЭ, IDS и антивирусы (то, на что у ФСТЭК были соответствующие РД).

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

На мой взгляд, сюрприз неприятный, так как заставит все финансовые организации, включая малые банки, микрофинансовые организации, страховые, ломбарды, брокеров, негосударственные пенсионные фонды, операторы платежных систем и другие, выбросить то, что ими применялось до сих пор (а в массе своей оно было несертифицированным, исключая СКЗИ и некоторые крупные кредитные организации) и искать продукты, которые будут не просто сертифицированы как МСЭ или IDS или еще что-то, а искать продукты, проверенные на отсутствие НДВ (у МСЭ - это требование с 5-го класса, у IDS - пока с 4-го). Много ли у нас таких продуктов на рынке? И если с МСЭ или IDS еще можно поискать, то вот что делать с другими типами средств защиты, упомянутыми в проекте ГОСТа, но которые даже на ТУ не сертифицировались, не говоря уже про отсутствие НДВ.

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

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

ЗЫ. И самое интересное, что в дорожной карте Банка России с переченем мер по повышению уровня защищенности финансовой системы Российской Федерации эта норма (по сертификации средств защиты) отсутствует :-(

Подробнее…

Обзор нового ГОСТа ЦБ по защите информации

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

Во-первых, в отличие от СТО БР ИББС новый стандарт будет распространяться на кредитные и некредитные финансовыми организации и будет носить обязательный характер путем ссылок на него из нормативных актов Банка России, например, из обновленного 382-П или 552-П. При этом объектам стандартизации являются уровни защиты информации и соответствующий им базовый состав организационных и технических мер защиты информации.

Вот тут стоит обратить внимание, что впервые ЦБ переходит в своих требованиях на уровни защиты, которые схожи с тем, что прописано в ПП-1119 применительно к уровням защищенности персональных данных, в 17-м или 31-м приказах применительно к классам защищенности ГИС и АСУ ТП соответственно.

Стандарт определяет три уровня защиты информации:

• уровень 3 – минимальный
• уровень 2 – стандартный
• уровень 1 – усиленный.

Уровень защиты информации для конкретной области применения устанавливается Банком России и зависит от:

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

Как можно было заметить в 5-й редакции СТО БР ИББС, тему ПДн ЦБ перестал драйвить и попросту отсылает всех к 21-му приказу ФСТЭК. Так и в ГОСТе - никаких отдельных защитных мер для ПДн нет. ЦБ просто соотносит уровни защиты нового ГОСТа и уровни защищенности ПДн ЦБ:

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

• выбор базового состава мер адаптацию выбранного базового набора мер применительно к структурно-функциональным характеристикам ИС, реализуемым ИТ, особенностям функционирования ИС
• уточнение (включает дополнение или исключение)
• дополнение адаптированного базового набора мер по обеспечению безопасности дополнительными мерами, установленными иными нормативными актами.

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

Структура нового ГОСТа будет следующей:

• Область применения, нормативные ссылки, термины и определения, сокращения, назначение и структура стандарта
• Общие положения
• Требования к системе защиты информации
• Требования к организации и управлению защитой информации
• Требования по защите информации на этапах жизненного цикла автоматизированных систем
• Приложение А – Модель угроз и нарушителей
• Приложение Б – Состав и содержание организационных мер, связанных с обработкой финансовой организаций ПДн
• Приложение В – Перечень событий защиты информации, потенциально связанных с несанкционированным доступом и инцидентами защиты информации, обязательных для выявления, регистрации и анализа

И вновь обращаю ваше внимание на 3-5 пункты. Если СТО БР ИББС состоял из множества документов, то новый ГОСТ один. Поэтому все требования по ИБ включены в один документ, но разбиты на 3 большие части - сами меры защиты, меры по управлению и требования к жизненному циклу.

Блок защитных мер состоит из 8 основных процессов, которые являются переложением уже принятых ЦБ стандартов СТО и рекомендаций по стандартизации РС (за редким исключением):

• Обеспечение защиты информации при управлении доступом
• управление учетными записями и правами субъектов логического доступа 
• идентификация, аутентификация, авторизация и разграничение доступа при осуществлении логического доступа
• защита информации при осуществлении физического доступа
• идентификация, классификация и учет ресурсов и объектов доступа
• Обеспечение защиты вычислительных сетей
• сегментация и межсетевое экранирование вычислительных сетей
• выявление сетевых вторжений и атак
• защита информации, передаваемой по вычислительным сетям
• защита беспроводных сетей
• Контроль целостности и защищенности информационной инфраструктуры
• Антивирусная защита
• Предотвращение утечек информации, защита машинных носителей информации (МНИ)
• Управление инцидентами защиты информации
• мониторинг и анализ событий защиты информации
• обнаружение инцидентов защиты информации и реагирование на них
• Защита среды виртуализации
• Защита информации при осуществлении удаленного логического доступа с использованием мобильных (переносных) устройств

Фрагмент блока требований по управлению доступом

Блок управления состоит из четырех компонентов:

• Планирование системы защиты информации
• Реализация системы защиты информации
• Контроль реализация системы защиты информации
• Совершенствование реализация системы защиты информации.

Фрагмент блока требований к планированию системы защиты информации

Ну и блок требований к жизненному циклу защиты информации:

Фрагмент блока требований к жизненному циклу

Вот такая картина получается. Достаточно гибкий подход, как мне кажется. И ни слова про оценку соответствия или отправку в ГУБЗИ ее результатов. Правда, пока неясной (для меня) остается судьба самого СТО БР ИББС. Там остаются документы, положения которых не вошли и врядли войдут в состав нового ГОСТа. Например, свежий СТО 1.3 по сбору доказательств для расследования инцидентов. Возможно из них сделают то, что называется "рекомендация по стандартизации" с соответствующей их регистрацией в Росстандарте (как это сделано в ТК26). Посмотрим...

ЗЫ. На логичный вопрос, когда ГОСТ примут, ответить пока не могу. В дорожной карте ЦБ стоит второе полугодие 2017-го года. Но это не срок принятия, а срок разработки и внесения в Ростехрегулирования, за чем последует рассмотрение ГОСТа в Росстандарте и его принятие, на что обычно уходит не меньше года. Так что не раньше чем к концу 2018-го года новый ГОСТ примут, а вступит в силу он (предположительно) в 2019-м году.

Подробнее…

Новые требования по ИБ для финансовых организаций

А продолжу-ка я обзор последних изменений нормативных актов по ИБ, но в этот раз коснусь финансовой сферы. Она, наряду с госорганами, у нас наиболее заурегулирована и все равно на месте не стоит. Собственно, как и во всем мире. В конце прошлого года требования по ИБ разработала SWIFT, а "Минфин" штата Нью-Йорк разработал проект своих требований по безопасности финансовых организаций (вступят в силу с 1-го марта 2017-го года). Что же у нас появилось или появится в обозримом будущем и о чем можно будет поговорить/узнать на Магнитогорском форуме, до которого осталось меньше месяца. Вкратце (я все еще надеюсь посвятить каждому из НПА по отдельной заметке) у нас появилось вот что:

• Положение Банка России от 24 августа 2016-го года №552-П "О требованиях к защите информации в платежной системе Банка России" (или как его еще называют требования по защите АРМ КБР). Нельзя сказать, что раньше защита АРМ КБР не осуществлялась, - ведь об угрозах для этой системы ЦБ предупреждал давно. Например, в письме ЦБ №51-Т "О форме договора об обмене электронными сообщениями при переводе денежных средств в рамках платежной системы Банка России, заключаемого между Банком России и клиентом Банка России" было целое приложение по защите информации. Но за 4 года ситуация немного поменялась, да и сила такого договора межжду банком и ЦБ не сравнима с Положением Банка России. За его нарушение наказывать легче :-) Кстати, требование хранить 3 года видео - это, на самом деле, не так уж и серьезно. Стоимость такого решения не слишком высока и измеряется несколькими тысячами долларов.
• А вот рекомендация Банка России перенести формирование кодов аутентификации и защитных кодов в АБС может иметь более серьезные последствия. Такое встраивание СКЗИ на мой взгляд потребует от разработчиков не только соответствующей лицензии ФСБ, но и, возможно, согласования ТЗ на данную работу, что в текущих условиях 8-го Центра может быть не очень простой задачей.
• В конце прошлого года ЦБ принял новый СТО 1.3, посвященный сбору доказательств в рамках процесса реагирования на инциденты. Это, пожалуй, один из первых документов в комплексе стандартизации по ИБ Банка России, который опускается на такой уровень детализации, влоть до указания конкретных программных продуктов, облегчающих сбор доказательств в оперативной памяти, на ПК или в сетевом трафике.
• В декабре также был согласован проект ГОСТа "Базовый состав организационных и технических мер защиты информации", который в скором времени станет обязательным для финансовых организаций и именно на наего будут ссылаться иные документы ЦБ. Правда, по этому стандарту у меня сейчас возникают вопросы. Планировалось, что все технические меры защиты уйдут из 382-П и других Положений Банка России и они просто будут ссылаться на новый ГОСТ. Но новый стандарт содержит далеко не все (от слова "совсем") технические требования из 382-П. Поэтому я пока не могу для себя понять, что же появится в итоге. То ли положения ЦБ оставят за собой набор защитных мероприятий, то ли помимо упомянутого проекта ГОСТа будут и другие национальные стандарты.
• Поскольку в России ЦБ запустил аналог SWIFT - систему передачи финансовых сообщений, то логично было бы узнать, какие защитные меры приняты для СПФС. ЦБ считает, что риски для СПФС и для платежной системы Банка России идентичны и поэтому для обеспечения их безопасности применяется схожая идеология. Защитные меры перечислены в договоре об оказании услуг по передаче финансовых сообщений, утвержденном письмом ЦБ от 10 декабря 2015 г. № 017-45-4/10550. Думаю, что через какое-то время можно ожидать и отдельного положения Банка России под эту тему (по аналогии с 552-П).
• А еще ЦБ подготовил проект своего нового Указания “О требованиях к операторам услуг платежной инфраструктуры, привлекаемым Банком России, о порядке привлечения Банком России операторов услуг платежной инфраструктуры и ведения перечня операторов услуг платежной инфраструктуры, привлеченных Банком России”. В главе 4, целиком посвященной защите информации, всего 3 пункта, но они важны. Согласно им ОУПИ, являющийся резидентом РФ, должен иметь оценку соответствия 382-П на уровне "хорошая" (4-й уровень), а ОУПИ - не резидент РФ должен соответствовать уровню Level 1 стандарта PCI DSS или быть сертифицированным на соответствие ISO 27001.

Но это еще не все. Не стоит думать, что это все хаотические попытки понавыпускать какие-то документы по ИБ, имитирующую бурную деятельность, но не имеющие никакой конкретной цели. Это совершенно не так. Есть План мероприятий (дорожная карта) на 2016 год по реализации Основных направлений развития финансового рынка Российской Федерации на период 2016–2018 годов, которые описывают видение ЦБ отечественной финансовой отрасли на 3 года. Согласно этому плану по нашему направлению ЦБ должен:

• провести анализ возможности и целесообразности использования финансовыми организациями аутсорсинга отдельных элементов деятельности и подготовить соответствующих предложений - 2-е полугодие 2017-го года
• подготовить предложения по совершенствованию законодательства Российской Федерации в части наделения Банка России полномочиями по регулированию и контролю обеспечения информационной безопасности в финансовых организациях - 2-е полугодие 2017-го года
• участвовать в разработке проекта федерального закона, направленного на формирование правовой основы противодействия мошенничеству на финансовом рынке - 2-е полугодие 2017-го года
• разработать проекты национальных стандартов информационной безопасности - 2-е полугодие 2017-го года
• провести консультации с ФСТЭК России о создании системы сертификации и аттестации для цели контроля исполнения финансовыми организациями требований национальных стандартов информационной безопасности и технических требований к защите информации, установленных в правилах платежной системы Банка России для участников платежной системы - 2-е полугодие 2017-го года
• подготовить необходимые материалы и проекты документов для создания системы сертификации и аттестации для контроля исполнения финансовыми организациями требований национальных стандартов информационной безопасности и технических требований к защите информации, установленных в правилах платежной системы Банка России для участников платежной системы - 2-е полугодие 2017-го года
• провести консультации с представителями финансовых организаций для определения состава и содержания дополнительных организационных и технических механизмов защиты автоматизированного рабочего места «Клиент Банка России», применяемого для взаимодействия финансовых организаций – участников платежной системы с платежной системой Банка России - 2-е полугодие 2017-го года
• разработать регламенты взаимодействия по вопросам противодействия киберпреступности между Банком России и не являющимися поднадзорными и под- контрольными Банку России организациями и заинтересованными в повышении уровня информационной безопасности финансовой системы и национальной платежной системы Российской Федерации - 2-е полугодие 2017-го года
• разработать функционально-технические требования на автоматизированную систему противодействия мошенническим платежам в платежной системе Банка России - 2-е полугодие 2017-го года
• подготовить предложения по созданию и совершенствованию направлений подготовки специалистов внутреннего аудита, стратегического планирования, управления активами и финансового консультирования, обеспечения кибербезопасности и корпоративного управления - 4 квартал 2018 года. Я про это уже писал в июне прошлого года.
• разработать Указание Банка России «О внесении изменений в Положение Банка России от 9 июня 2012 года No 382-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств» - 2 квартал 2017-го года
• разработать Положение Банка России о правилах обеспечения безопасности и требованиях к защите информации в платеж- ной системе Банка России (для участников платежной системы Банка России). И это не 552-П - этот документ нужен для перспективной платежной системы ЦБ.

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

ЗЫ. У кого данный план регулятора вызывает вопросы, рекомендую посетить Магнитогорский форум - в этом году там будет высажен целый десант от Банка России - около 30 человек, причем самого высокого уровня. Кто, как не они, знают, что скрывается за краткими формулировками дорожной карты?..

ЗЗЫ. Хочу заметить, что утвержденные планы подготовки в России принято соблюдать, так как в противном случае чиновников не поглалят по головке. Поэтому все, что написано выше будет сделано в указанные сроки, но... хочу обратить внимание, что обычно в планах наших ведомств указывают не срок окончания работ по задаче, а срок ее начала. Например, написано, что во втором полугодии будут ГОСТы. Это не значит, что их до июля примут. Это значит, что их до июля разработают и прелставят общественности или утвердят. Потом начнется процедура согласований (если надо), общественных обсуждений, регистрации в Минюсте или в Ростехрегулировании. Поэтому не стоит питать иллюзий относительно скорого выхода указанных выше документов; обычно к этим срокам надо добавлять от 3 до 12 месяцев (а для законопроектов и того больше).

Подробнее…