SOC бесполезен, если он не может увязывать технические и бизнес-показатели

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

...прошло 15 минут

- Степан Петрович, это Сергей! Я дернул дежурную смена нашего SOCа - у них все зеленое. Все индикаторы в норме и так уже недели две. Это не может быть из-за нас.
- Хорошо, Сергей. Давай в понедельник часиков в 7 приходи - будем разбираться!..
- Хорошо, Степан Петрович! Буду в 7 утра в понедельник. Хороших выходных.
...ту-ту-ту-ту...

Руководитель службы ИБ пытался долго заснуть, но не мог. В итоге он сорвался на работу, чтобы разобраться в ситуации и к утру понедельника иметь всю информацию для общения с генеральным директором. Проверки всех ключевых показателей ничего не дали - доступность торговой Интернет-площадки была в пределах допустимого - 99,9%. Число мошеннических транзакций нулевое. Угроз e-mail тоже было немного - 0,02% и все были отбиты на шлюзе. IPS, NGFW, анализ Netflow, контроль доступа... Все в зеленых зонах. Что же случилось?..

- (А может это Миша, наш дорогой CIO, решил поквитаться за прошлый раз, когда я обвинил его в том, что вся сеть легла из-за него, а не из-за накрывшей нас эпидемии вредоноса? А может  это Васильна взхъелась из-за того, что мы ей перекрыли доступа на сайт знакомств? Ну а фигли, хоть и финдир, а надо соблюдать политики. С чего они вообще решили, что это мы виноваты и почему SOC за сотни миллионов рублей ничего не видит?)

...прошло два дня...

В понедельник к обеду выяснилось следующее:

• За 10 минут недоступности торговой Интернет-площадки из-за DDoS-атаки отвалилась ключевая сделка, которая должна была принести компании 27% ее недельного дохода.
• Система защиты e-mail посчитала за спам рассылки маркетингового департамента и клиенты перестали получать предложения с последующим снижением покупательской реакции. 12 тысяч сообщений "выброшено в пропасть" - покупательская активность снизилась.
• Антифрод не увидел ни одной мошеннической транзакции. Да и откуда? Стоящий на периметре WAF отсек 3% клиентов, даже не дав им разместить заказ.
• Последней каплей стало внедрение скрипта, который высвечивал перед каждым посетителем сайта уведомление с прокруткой о необходимости получения согласия на обработку персональных данных в соответствие с ФЗ-152 и GDPR, с полным разъяснением всех последствий от осознанного принятия клиентом всех условий предоставления ПДн компании. Анализ показал, что время, за которое клиент теперь стал доходить до процесса заказа увеличилось на 47 секунд, что привело к оттоку еще 11% покупателей.

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

Чтобы вложения в SOC были действительно полезны, необходимо уметь объединять привычные нам данные от средств ИБ с метриками, которые важны для бизнеса и уметь их связывать между собой. 10-тиминутная недоступность сайта в течение недели вполне укладывается в установленные ИБ границы, но совершенно не устраивает бизнес. Тоже самое с блокированием внутренних маркетинговых рассылок. Отсекли спам и хорошо. А то, что этот "спам" зарабатывает деньги никто не подумал.

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

Оценка соответствия средств защиты информации (презентация и видео)

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

Об оценке соответствия средств защиты информации from Cisco Russia

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

Давненько не брал я в руки... перо и не писал книжек

Последняя моя книжка вышла в 2008-м году. С тех пор минуло уже 10 лет и вот я вновь в обойме пишущих длинные связанные тексты :-) По приглашению Клуба Топ-менеджеров 4CIO я принял участие в написании учебника CIO - проекта, стартовавшего в 2010-м году, и переживающего сейчас уже свою третью версию. Именно в третьей, последней версии, я и участвовал, занимаясь написанием главы по информационной безопасности.

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

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

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

Перечень регуляторов по КИИ и процессов, за которые они отвечают

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

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

С требованиями по ИБ вроде все ясно - основным застрельщиком является ФСТЭК, а в зависимости от сферы деятельности, могут быть добавлены и иные защитные меры. Банки должны выполнять требования ЦБ, госы - требования 17-го приказа, операторы связи - отсутствующие требования Минцифры.

Дальше интересней. Регулятором в области ГосСОПКИ у нас является ФСБ, которая создала для этого специальную организацию - НКЦКИ, которая и управляет всеми вопросами, связанными с ГосСОПКОЙ. Тут вроде ничего нового пока тоже нет. Кроме, разве что, пока непонятного лично мне статуса самого НКЦКИ. Судя по ФЗ-187 - это не подразделение ФСБ, а отдельная организация, обеспечение которой лежит на плечах ФСБ, и руководит им также сотрудник спецслужбы.

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

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

Кстати, вопреки распространенному мнению, что наказывать будут за несоблюдение защитных мероприятий, на самом деле статья 274.1 достаточно четко говорит, что наказание повлечет только нарушение правил эксплуатации средств хранения, обработки и передачи охраняемой компьютерной информации, содержащейся в КИИ, или правил эксплуатации ИС, АСУ ТП, ИТС и сетей связи, или правил доступа к ним, если оно повлекло нанесение вреда. Иными словами, если вы не установили промышленный МСЭ на границе с АСУ ТП, вас наказать нельзя (итак нельзя, но я упрощаю), а вот если вы его установили, но не соблюли инструкцию производителя, то вам светит часть 4 статьи 274.1 (до 8-ми лет). Вот такие пироги :-( Кстати, очень интересно почитать "Методические рекомендации по осуществлению прокурорского надзора за исполнение законов при расследовании преступлений в сфере компьютерной информации", выпущенные в мае 2014 года. Да, они касаются 274-й статьи (в 2014-м еще не было 274.1), но так как обе статьи почти идентичны по тексту, то думаю, что эти же рекомендации будут применяться прокуратурой и для новой статьи (как будет действовать ФСБ предположить пока не могу).

ЗЫ. Возможно в каких-то аспектах и ошибся, но вроде как перепроверил несколько раз по существующим и планируемым НПА.

Хотите изучить тактики хакеров из ГРУ и ФСБ?

В начале года я в очередной раз обратился к теме Threat Intelligence и в нескольких заметках расписал, что такое матрица MITRE ATT&CK, которая позволяет описать техники, тактики и процедуры злоумышленников (TTP). Данная матрица, будучи наложенной на действия тех или иных хакерских групп или кампаний, понять типичные действия, осуществляемые злоумышленниками и, это я уже фантазирую, позволить провести базовую атрибуцию. Например, с помощью инструмента CARET можно показать, какой тактики придерживаются группы FancyBear, Cobalt и другие.

И вот на днях компания Digital Shadows поделилась своим видением тактик и техник, используемых "русскими хакерами в погонах":

• ФСБ (обвинения 2017-го года)  

• ГРУ (обвинения 2018-го года).

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

Можете работать руками или на счетах? Значит у вас нет значимых объектов КИИ

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

Секция по цифровой экономике меня и порадовала и огорчила одновременно. Порадовала она тем, что на ней выступали представители регионов, которые задавали закономерные вопросы о том, почему им приходится тратить на непонятные требования по безопасности сотни миллионов рублей и стоимость защиты информационных систем выходит выше, чем стоимость самих информационных систем. И почему, например, муниципалы только-только установили у себя VipNet'ы 3-й версии, а тут приходит указание заменить все на 4-ую. Министры региональной информатизации задаются закономерным вопросом - что такого изменилось в мире, что надо срочно и в обязательном порядке переходить на новую версию? Угрозы стали серьезнее? Алгоритмы стали быстрее и эффективнее? Не было ответа, так как, и это меня удручало, чиновники не пришли на секцию. Что касается секции по импортозамещению, то она была похожа как две капли воды на все остальные секции - импортозаместители говорили каждый за себя и ничего конкретного :-(

Но перейдем к секции по кибербезопасности - я заранее подготовил вопросы к участникам, которые представляли собой субъектов КИИ, вендоров по ИБ и регуляторов. Правда, с последними вышла промашка, - обещанный НКЦКИ так и не посетил мероприятие и заготовленные ему вопросы остались без ответа. А по остальным вопросам были вполне конкретные ответы от участников.

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

Из субъектов КИИ на секции присутствовали ИВЦ питерского РЖД, питерский метрополитен и ДИТ Москвы. У ИВЦ прозвучало сначала очень революционная идея, что у них после оценки оказалось, что объектов КИИ нет вообще. В процессе дискуссии выяснилось, что позиция ИВЦ базируется на простом факте - если нарушение работы информационной системы не сказывается на выполняемых ИВЦ задачах и они могут быть выполнены "вручную", то данная информационная система не является объектом КИИ (думаю, что все-таки речь идет о значимом объекте, а не просто об объекте). Очень интересная, но и понятная позиция. У метро подход оказался схожий. А вот у ДИТ Москвы (выступал Валерий Комаров) иная проблема - они не являются обладателями/владельцами/заказчиками информационных систем, используемых в Москве, - они всего лишь их оператор и на них требование по категорированию не распространяется.

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

Вопросы к НКЦКИ остались без ответа, но тут может помочь презентация их представителя, прозвучавшая днем ранее в Москве.

На заданный в самом конце вопрос о гостайне, ФСТЭК ожидаемо ответила, что к ГТ будут относиться только совокупные сведения по КИИ и каждому субъекту не придется создавать у себя первые отделы.

Что еще прозвучало интересного на мероприятии? Тезисно я бы отметил следующее:

• питерское метро ориентируется в первую очередь на встроенные механизмы защиты и планирует выполнять 239-й приказ именно ими - в наложенных средствах защиты они не нуждаются
• ДИТ и Конфидент считают, что рынок отечественных решений ИБ вполне себе развит и можно выполнить требования 239-го приказа целиком на отечественных решениях (ну не знаю, я скептично отношусь к такой позиции).
• РТК-Solar рассказал, что НКЦКИ не требует, чтобы SIEM на стороне центров ГосСОПКИ были только отечественного производства. Интересно, в проекте приказа НКЦКИ было написано немного другое. Может и правда поменяют? Хотя РТК-Solar, использующий в своем SOCе три разных SIEM (Arcsight, QRadar и MaxPatrol), для субъектов КИИ применяет отечественное решение (может все-таки готовятся к негативному развитию событий?).
• Также РТК-Solar рассказал, что НКЦКИ рекомендует не арендовать SIEMы (например, в рамках аутсорсингового SOC), а покупать свой и ставить его себе на баланс, и хранить логи у себя локально.

Вот такие новости. Может кому-то будет что-то внове.

5 типовых ошибок при проведении штабных киберучений

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

Итак мой топ-5 ошибок выглядит так:

1. Вы не знаете свою целевую аудиторию и поэтому ваш сценарий не находит отклика у участников. Например, вы проводите учения для топ-менеджеров (главбух, финансовый директор, руководитель службы безопасности, директор HR и т.п.), но в своих кейсах даете слишком много технических деталей, которые не понятны участникам и они теряют интерес к мероприятию. Таже самая проблема возникает, когда ваш сценарий направлен на введение в реагирование на инциденты, а участвуют в киберучениях опытные специалисты службы Incident Response, которым ваши примеры кажутся детскими.
2. Вы не провели предварительное обсуждение с "заказчиком" учений и не уточнили, какую цель он преследует (а они могут быть разные). В итоге вы сделали не то, чего от вас ожидали. Например, генеральный директор захотел проверить, насколько эффективно его служба ИБ реагирует на нештатные ситуации в техническом, юридическом и организационном доменах, а ваш сценарий заточен на проверку способности службы ИБ пройти проверку регулятора, считая, что именно это важно в данный момент.
3. У вас нет сценария и вами управляет экспромт. Учитывая необходимость направлять участников в рамках многоходовой комбинации, экспромт не даст вам это сделать и вы уйдете далеко в сторону от первоначальной идеи.
4. Отсутствие четких правил и неумение держать аудиторию "в узде". Время учений обычно ограничено 2-3 часами (этого хватает для отработки 10-15 ситуаций для 5-6 групп) и поэтому вы не можете себе позволить давать участникам повторяться, долго думать, медлить с ответом, вступать в полемику не по делу и т.п. Работа ведущего (фасилитатора)  сродни модераторству, когда надо четко следить за временем и направлять дискуссию в заранее определенное русло. Пускать на самотек во время киберучений ничего нельзя.
5. У вас отсутствует follow-up и разбор полетов. Вы же проводите киберучения не потому, что это модно или прикольно. Вы преследуете вполне конкретную цель по выработке навыков ИБ и вовлечению (а не бездумному участию) ваших сотрудников в ситуации, схожие с реальной жизнью, но с которыми вы еще не сталкивались (и это хорошо). Для этого по окончании учений надо понять все ошибки (но не озвучивать их в рамках самих штабных командных киберигр, так как во время них не бывает правильных и неправильных ответов) и на их основе разработать планы по улучшению слабых мест, выявленных в процессе учений. Без этого, все эти "игрища" обречены на неудачу.

Сколько лицензий надо, чтобы подключиться к ГосСОПКА?

Сегодня, в четверг, 20 сентября, проходит несколько мероприятий по ИБ, с которых приходят интересные новости от рыцарей виртуального плаща и кинжала, то есть от ФСБ. Среди них и злободневный вопрос: "Сколько лицензий и каких надо, чтобы работать с ГосСОПКА?". Попробовал для себя сформулировать все, что знаю:

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

Итого: ФСБ в своем репертуаре. Чтобы получить методическую помощь от регулятора ответственного за обнаружение, предотвращение и ликвидацию последствий компьютерных атак, будьте добры получить лицензию на работу со сведениями, составляющими гостайну. Даже если ты сельская больничка из одного главврача и медсестры или ломбард. Приплыли... А если я не могу получить лицензию на гостайну, то как мне защищиться от атак? А тогда кому ты нужен, нищеброд?...

ИБ-перевертыш или влияние культуры на ИБ (презентация)

В пятницу на BIS Summit я рассказывал про влияние культуры на ИБ, презентацию откуда и выкладываю.

ИБ-перевертыш или влияние культуры на ИБ from Aleksey Lukatskiy

В рамках презентации показывал видео, которое нельзя залить на SlideShare, но можно увидеть на Youtube (только в презентации я чуть обрезал запись с 4-х минут до одной):

Bomgar покупает BeyondTrust

13 сентября компания Bomgar, занимающаяся решениями по управлению привилегированным доступом, подписала обязывающее соглашение о приобретении компании BeyondTrust, занимавшейся тем же. Детали сделки не раскрываются. 

Можно ли защитить ИТ-инфраструктуру российского госоргана отечественными решениями по ИБ?

Вчера в Facebook зашла речь, в очередной раз, об импортозамещении в ИБ, которое, как прозвучало на одной из конференций в Питере, должно состояться вот уже через 2-3 года. Тут надо бы ответственно заявить, что говоря об импортозамещении, большинство экспертов делает классическую ошибку, считая, что выпуск отечественного аналога зарубежного продукта, - это и есть импортозамещение. Но увы... Даже если отбросить в сторону тот факт, что для нормального развития того или иного сегмента нужно более одного вендора и продукта, то выпуск (и снова отбросим в сторону, на этот раз, вопрос качества и функциональности отечественного продукта) российского решения еще не означает, что его выбрали заказчики. Вот когда российские компании, хотя бы госорганы и госкорпорации, перейдут на все эти домотканные МСЭ, СОВ/СОА, UEBA, SIEM и др., тогда и можно будет говорить об импортозамещении.

Но вернемся к версии апологетов импортозамещения, которые говорят, что в России есть хотя бы по одному, но аналогу, западным и восточным (мы же понимаем, что китайское - это тоже импорт) продуктам и поэтому можно говорить о том, что реально отечественный рынок готов заместить все иностранное. Ну давайте смотреть. Если ограничиться не всем российским рынков, а только госорганами, то я позволил себе выбрать несколько кейсов, для которых сегодня нет сертифицированных российских продуктов по защите информации (по аналогии с заметкой восьмилетней давности про СКЗИ):

• Работа на Macbook'ах
• Разграничение доступа в iSCSI и FC сетях
• Защита SAN
• Высокоскоростные магистрали и резервные каналы связи (40 Гбит/сек и выше)
• Виртуальные среды на базе KVM
• Доверенная загрузка на ноутбуках (тут возможно и есть что-то, но я с ходу не вспомнил)
• Регламентация и контроль беспроводного доступа
• Средства контроля целостности ПО (как минимум на Windows 10, где пока не работает ФИКС)
• Обманные системы (вроде как решение Кода безопасности больше не существует).

Это я привел неполный перечень тех иностранных решений, которые достаточно активно используются в российских организациях, и при этом не имеют отечественных средств защиты, имеющих сертификат ФСТЭК. А если в качестве основы взять организацию, которая прислушалась к мнению чиновников и действительно перешла на отечественные информационные технологии или open source:

• средства унифицированных коммуникаций iMind, Vinteo, TrueConf и др.
• open source платформы Hadoop, Spark, Elastic, Pentaho, MongoDB и др.
• параллельные СУБД InfiniDB, InfoBright и др.
• семейство Apache - Tomcat, Cassandra, Struts, Metron, HTTP Server и др.
• сервера приложений - WildFly, GlassFish и др.
• web-сервера - nginx и др.
• промышленные решения - Tibbo и др.
• электронный документооборот - Alfresco, Directum и др.

Вот я с ходу не вспомнил российских разработчиков, которые бы декларировали средства защиты для упомянутых решений, преимущественно защищая решения иностранные - Windows, Oracle, IBM и т.п. А уж сертифицированных решений для названных решений и вовсе нет.

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

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

UPDATE: В Твиттере меня коллеги поправили. ФИКС есть для Windows 10. Для ноутов есть модули m2 и UEFI для доверенной загрузке. Есть Аккорд для KVM. Гарда поддерживает PostgreSQL, Cassandra, Hadoop и HDP. Threat Deception есть у Лаборатории Касперского.

Правила Керкгоффса (не путать с законами Кирхгофа)

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

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

Данные шесть принципов были впервые опубликованы в журнале "Военная наука" в 1883-м году (издается до сих пор). Две статьи, в январском и февральском выпусках, описывали существующие в 19-м веке системы шифрования и способы их криптоанализа. Там же Огюст Керкгоффс сформулировал и основы создания надежных криптографических систем, упомянутые выше.

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

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

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

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

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

Правило "1-10-60" или три метрики SOC, когда вы не знаете как правильно измерить свой центр мониторинга ИБ

Помню 2 года назад, на SOC Forum, я выступал в модерируемой мной с Дмитрием Мананниковым секции по оценке эффективности SOC. В рамках своей презентации я описывал возможные подходы к оценке SOC различных точек зрения - технической, процессной, бизнеса и т.п. За прошедшие два года я не раз сталкивался с различными центрами мониторинга, создатели которых, построив неплохую инфраструктуру, набрав специалистов и даже выстроив  отдельные процессы, так и не смогли правильно оценивать свою деятельность. Участвуя в различных проектах по консалтингу SOC, а также имея доступ к нашей базе знаний по этой теме, могу отметить, что происходит это по двум основным причинам (движение снизу вверх вместо движения сверху вниз и плохо управляемые ожидания при создании SOC). В обоих случаях мы не понимаем, ЗАЧЕМ нам нужен SOC? Именно нам, а не кому-то. Для нашего бизнеса. Для нашей ИТ-инфраструктуры. Для нашей оргштатной структуры. Для нашего руководства. Чтобы это сделать надо двигаться сверху вниз - от стоящих задач к способам их решения. От них же, кстати, будет зависеть и все остальное, - архитектура, технологии, люди, процессы и т.п.

Но на практике обычно все бывает иначе. Поддавшись моде или желая замутить что-то новое инвестируются десятки и сотни миллионов рублей в прорывные технологии "из гартнера", нанимаются за бешеные деньги аналитики ИБ, закупаются сервисы Threat Intelligence из десятков источников, а потом приходит руководство и спрашивает "И что? Где результат?" И показать нечего. Но есть ряд метрик, которые все-таки можно использовать для того, чтобы показать эффективность своего SOC. Пусть не на бизнес-уровне, но хотя бы на уровне, понятном любому безопаснику. Для чего мы создаем SOC на понятийном уровне? Чтобы оперативнее обнаруживать и реагировать на угрозы. Это очевидно и именно это можно на первых порах поставить во главу угла своей программы (до момента осознания реальной потребности в SOC и стоящих перед ним задач).

Обычно выделяют 3 основных метрики, которые показывают:

• время обнаружения угрозы (Time-to-Detect, TTD)
• время локализации угрозы, включая расследование (Time-to-Contain, TTC)
• время реагирования на угрозу (Time-to-Response, TTR).

Иногда еще добавляют и время восстановления после угрозы (Time-to-Remediate, TTR). Визуально связь между этими метриками выглядит следующим образом:

Измерить эти показатели проще простого, как и отслеживать их динамику. Но стоит помнить, что для разных угроз/инцидентов эти значения будут разные (хотя их и можно свести к некому единому показателю). Это по требованиям ФСБ в ГосСОПКУ данные передаются в течение 24 часов с момента обнаружения (хотя правильнее говорить, регистрации) инцидента независимо от его природы. Но мы с вами прекрасно понимаем, что время обнаружения спама, время обнаружения группировки Cobalt и время обнаружения соединения с командными серверами ботнетов могут сильно отличаться. Вот как, например, выглядит распределение данных показателей в одном из отчетов службы реагирования на инциденты Cisco:

Обычно считается среднее арифметическое параметров TTD, TTC и TTR, но у нас в Cisco также вычисляется и медиана, - две величины лучше отражают данные временные показатели в больших выборках с широким разбросом значений.

Как итог, отчет по эффективности SOC может выглядеть так:

Это фрагмент из трехлетней давности еженедельного отчета группы реагирования на инциденты Cisco. Обратите внимание, что помимо текущих значений TTD, TTC и TTR в отчете указано и целевое значение, к которому мы стремимся. Этот показатель тоже меняется время от времени и по мере улучшения процессов и технологий, а также роста квалификации персонала, он должен уменьшаться, но никогда не достигая нуля (это нецелесообразно).

Но есть и еще одна интересная метрика, которая не столь важна для представления ее наружу, сколько для оценки внутренней эффективности выстроенных в SOC процессов, поддержанных людьми и технологиями. Эта метрика называется время прорыва (breakout time). Ее предложила в 2018 году компания CrowdStrike, которая проанализировала около 30 триллионов событий безопасности в 2017-м году, и вычислила время, которое требуется злоумышленнику, чтобы уйти с первоначального плацдарма и начать распространение внутри корпоративной или ведомственной. Это время равно 1 часу 58 минутам. Важность понимания сути этого временного окна очень высока. Оно показывает, какой запас времени у нас есть, чтобы инцидент не превратился в катастрофу; чтобы взлом, например, публичного web-сайта (как это было с Equifax), не перетек во взлом баз данных.

CrowdStrike, кстати, предложила еще одно интересное измерение для SOC - это правило "1-10-60", которое означает, что хорошо защищенная компания должна уметь обнаруживать (TTD) угрозы за 1 минуты, проводить их расследование за 10 минут, а блокировать нарушителя за 1 час. Для этого надо использовать современные технологии ИБ, которые фокусируются не на предотвращении, а на всем жизненном цикле угрозы - ДО, ВО ВРЕМЯ и ПОСЛЕ.

PS. Скоро грядет очередной SOC Forum. Пройдет он в Москве 27-28 ноября (да, два дня, а не один). Пора регистрироваться!

PPS. А 9-10 октября буду на тему SOCов выступать на CyberCrimeCon 2018.

Утверждено 3 приказа ФСБ по ГосСОПКЕ из шести

6 сентября были опубликованы утвержденные и зарегистрированные в Минюсте 3 (из шести) приказа ФСБ, касающиеся ГосСОПКИ.

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

Второй приказ, №367, "Об утверждении Перечня информации, предоставляемой в ГосСОПКУ и Порядка предоставления информации в ГосСОПКУ" также не претерпел изменений по сравнению с проектом. Я про него уже писал и делал презентацию. Вопросы по данному приказу также остаются пока без ответа. Оценить причинно-следственные связи между атакой и инцидентов, да еще и оценить последствия... и все это в течение 24 часов?! Круто, ничего не скажешь.

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

Грустно все это. Разрабатывать документы почти год и получить на выходе пшик :-( Я не знаю с чем это связано. Неким показателем лично для меня должны стать шесть методических документов, о которых написал Валерий Комаров и которые сейчас готовит НКЦКИ:

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

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

Взлом Equifax: разбор полетов

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

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

Есть несколько интересных моментов, на которые я бы хотел обратить внимание в этой истории:

• Злоумышленники использовали известную к моменту первичной атаки уязвимость в Apache Struts Server, которая была идентифицирована US CERT двумя днями ранее. Это в очередной раз поднимает вопрос о том, как должен быть выстроен процесс устранения уязвимостей? Надо ли их устранять сразу по факту публикации бюллетеня по ним? А может надо ждать публикации сведений об экслойтах для уязвимости? Или опираться на рейтинг CVSS? Вопросов много, но однозначных ответов пока нет. В любом случае, это лишний раз напоминает нам, что злоумышленники далеко не всегда используют 0Day для своих атак.
• В процессе расследования выяснилось, что Equifax знал об уязвимости, так как получил от US CERT соответствующий бюллетень, который был распространен среди системных администраторов. Но... оказалось, что список этих лиц был устаревшим и в него не входили те администраторы, которые отвечали за установку патчей на уязвимом Web-портале. Наблюдается либо определенный пофигизм к поддержанию такой информации в актуальном состоянии, либо конфликт между ИТ и ИБ, что бывает очень часто.
• Интересно, что Equifax также заявил, что через неделю после получения бюллетеня от US CERT, они сканировали свою сеть, включая и уязвимый web-портал, но используемый сканер ничего не показал, что в очередной раз поднимает вопрос о том, надо ли целиком доверять используемым техническим решениям одного вендора и не надо ли их дублировать (не обязательно тратя на это еще деньги и используя решения open source).
• Equifax заявляет, что злоумышленники так долго могли скрывать свою деятельность, потому что использовали шифрование своей активности. Я уже неоднократно писал о том, что шифрование - это палка о двух концах и оно активно используется злоумышленниками для скрытия своих действий, существенно усложняя жизнь специалистам по ИБ. И им не нужно получать никаких лицензий ФСБ для этого. Так как это происходит все чаще, то необходимо иметь определенную стратегию для борьбы с зашифрованным трафиком.
• Самое интересное, что в процессе проведения регламентных работ в инфраструктуре Equifax выяснилось, что одно из решений по мониторингу и инспекции сетевого трафика не видело вредоносной активности в зашифрованном трафике из-за ошибок конфигурации этого устройства. Если быть точнее, то на данном устройстве был просроченный более чем 10 месяцев (!) цифровой сертификат. На мой взгляд это чистой воды халатность администраторов, которые почти год вообще не мониторили внутренний сетевой трафик. Это же показывает, что помимо защиты периметра необходимо иметь решения и для мониторинга аномалий во внутренней инфраструктуре. Без этого сегодня никуда.
• В другом источнике было написано, что используемое для инспекции сетевого трафика оборудование не соответствовали заявленным вендором цифрам по производительности, что часто приводило к задержкам в обработке трафика. В итоге настройки оборудования были изменены так (в сторону ухудшения ИБ), чтобы производительность устройства не снижалась.
• Никакой сегментации в инфраструктуре Equifax не было, что привело к неконтролируемому доступу к множеству различных баз данных, а не только к тем, которые были связаны с уязвимым Web-сервером. А ведь сегментация - это то, что дает чуть ли не 50% успеха в сетевой безопасности и при этом не требует особых затрат, так как задействует встроенные возможности сетевого оборудования.
• Интересный факт - позже выяснилось, что Equifax использовал оборудование компании FireEye для мониторинга угроз во внутренней сети, но FireEye на следующий день после известия о взломе Equifax удалил со своего сайта историю успеха о внедрении в кредитном бюро своих решений. Предположу, что это результат эмоционального решения руководства ИБ-вендора, который не хотел связывать себя с взломом, но мы все прекрасно понимаем, что кеш поисковых систем сохраняет все, в том числе и удаленные материалы. А на репутации такой факт сказывается гораздо больше, чем если бы мир знал, что Equifax защищался с помощью FireEye. Если верить отчету Счетной палаты США, то вина лежала целиком на администраторах Equifax, которые почти год не обновляли цифровой сертификат на средстве инспекции сетевого трафика. 

Выводы из этого кейса вполне очевидны и я бы назвал несколько рекомендаций, которые позволили бы предотвратить его. Необходимо:

1. выстроить процесс управления уязвимостями и четко понимать, как и когда устранять обнаруженные уязвимости.
2. тесно контактировать с ИТ-командой, отвечающей за процесс управления патчами и иметь актуальный список лиц, которые занимаются устранением дыр.
3. мониторить внутренний трафик с помощью решений класса NTA (NBAD), которые позволяют обнаруживать аномалии и угрозы, проникшие из-за периметра или инициированные изнутри.
4. поддерживать актуальную конфигурацию как сетевого оборудования, так и средств защиты.
5. сегментировать сеть для предотвращения несанкционированного доступа. 
6. понимать риски использования злоумышленниками шифрования для скрытия своей активности и использования решений, которые борются с этим (EDR на оконечных устройствах, устройства для SSL Offload, инспекция DNS-трафика для обнаружения взаимодействия с инфраструктурой злоумышленников, использование технологий машинного обучения для обнаружения вредоносной активности внутри зашифрованного трафика без его расшифрования).

PS. Примечательно, но во взломе Equifax русских хакеров не обвиняли :-)

Российский ИБ-рынок: между Востоком и Западом

Многие помнят нашумевший спор между Натальей Касперской и Анатолием Чубайсом на Петербургском международном экономическом форуме о том, какого пути надо придерживаться России в своем развитии. Наталья Ивановна считает, что Россия вполне может быть счастлива, идя по пути Китая. Анатолий Борисович напротив считал, что Россия не может повторить путь Китая, так как несоизмерима меньше и по населению, и по экономике, и по ВВП; и надо, мол, "дружить" с Западом.



Это тема, "Запад или Восток?", начала набирать обороты последние 4 года, с момента введения первых санкций со стороны США. И хотя число компаний, которые столкнулись с реальными проблемами в закупке, обновлении или использовании американских решений по ИБ не так велико, эти риски из фантастических превратились во вполне реальные и поэтому их никак нельзя сбрасывать со счетов. "Славянофилы" активно пугают реальностью этих рисков и предлагают... А вот предложить-то пока и нечего. В отличие от славянофилов 19-го века, упиравших на самобытность России и наличие у нас своего собственного пути, в отрасли ИБ спустя почти два века никакого намека на самобытность не наблюдается. У нас очень узкий рынок ИБ и число типов средств защиты (даже если рассматривать сегменты, в которых всего один представитель) измеряется максимум одним-полутора десятками, в то время как за пределами России их число приближается к сотне. Самое печальное, что за прошедшие с момента введения санкций 4 года у нас ситуация изменилась не очень сильно. А откуда браться новым решениям, если госзаказа нет, поддержки от государства тоже, собственных ресурсов не хватает, а новых игроков не появляется и не появится в условиях ужесточения требований к разработчикам средств защиты.

Итак, "западники", в публичном пространстве, в меньшинстве. "Славянофилы" напирают на патриотизм, но кроме него предложить ничего не могут. Что остается? Обращение лицом к Китаю? И вроде как за эту почти пятилетку мы достаточно много добились в наших взаимоотношениях с восточным партнером. Кстати, почему в единственном числе? Ну тут все просто. Япония жестко связана с США партнерскими отношениями, а с нами она активизировала отношения только ради Курил. Южная Корея неплохо зарекомендовала себя на рынке электроники, но вот на рынке ИБ я что-то не помню южнокорейских имен. Да и кажется мне, что мы нужны Южной Корее только для того, чтобы заручиться нашей поддержкой по ядерной проблеме КНДР. Кроме того Корея тоже является союзником США и не пойдет против их санкций. Кто у нас еще может рассматриваться в качестве восточного партнера в ИБ-сфере? Малайзия? Сингапур? Вьетнам? В первые две страны в последние годы зачастили организаторы российских конференций для того, чтобы перенимать восточный опыт, но вот программных и аппаратных решений из этих стран что-то не видно. Ну разве что производство комплектующих на Тайване. Действительно остается только Китай, который обладает огромным внутренним рынком ИБ, насчитывающим минимум сотню компаний, разрабатывающих свои антивирусы, NGFW, IPS, сканеры безопасности, WAF, DLP и т.п. Но все это для внутреннего потребления и эти компании не стремятся к географической экспансии, уступаю пальму первенства всего одной китайской компании, продукцию которой запрещают в США, Австралии, Индии, Европе (из-за обвинений в шпионаже), но которая успешно развивается именно у нас. Кстати, если посмотреть новостную ленты, то за последнее время китайцы были неоднократно (минимум раз двадцать обвинены в шпионаже и краже интеллектуальной собственности).

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

Я сам буду выступать в секции по культуре ИБ с рассказом про... честно говоря еще и не знаю про что. У меня будет всего 15 минут и поэтому надо ужать в этот тайм-слот что-то интересное и полезное, что непросто. Я вообще не люблю такие короткие презентации, но так получилось. Кстати... у вас может возникнуть вопрос, причем тут конвергенция, которая упоминается в названиях трех панельных сессий? Честно, я и сам не знаю и в программном комитете нам не удалось прийти к консенсусу. Конвергенция - это процесс сближения ранее различных позиций, течений, точек зрения и т.п. Поэтому лично для меня понятие "конвергенция культуры ИБ" звучит достаточно странно, так как тут нет процесса сближения. С чем сближается культура? А с чем сближается последняя линия защиты? А конвергенция compliance? В общем, мне не совсем понятно использование термина "конвергенция", исключая пленарную сессию "ИБ между Востоком и Западом", в которой как раз есть две позиции и они... но вот сближаются ли они? Может для того, что происходит между двумя частями света, надо использовать термин "дивергенция", то есть расхождение?.. В любом случае Рустем Хайретдинов обещал раскрыть, в чем же заключается конвергенция ИБ в своем докладе, который и начнет секцию по культуре, а на самом деле является заглавным для всей презентационной части конференции. А я, возможно, буду его троллить :-)

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

Новые требования ЦБ устанавливают обязательность ГОСТа для кредитных и некредитных финансовых организаций

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

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

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

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

Требования для кредитных организаций

Первый возникающий вопрос касается первого проекта. Зачем он нужен, если ЦБ уже выпустил 382-П и имеет ГОСТ 57580.1, устанавливающий базовый набор защитных мер. Ответ на этот вопрос очень просто. 382-П касается только участников НПС и защиты информации в Национальной платежной системе, а разработанный проект распространяется на всю банковскую деятельность, исключая те области, которые уже покрыты требованиями по ИБ, установленными федеральными законами (ФЗ-152 о ПДн, ФЗ-161 о НПС, ФЗ-187 о безопасности КИИ). Идеологически новый проект схож с 382-П и его реализация не будет чем-то новым для кредитных организаций, но есть и ряд отличий. Пусть и с некоторым опозданием (обещали это сделать еще в конце 2017-го года), но Банк России наконец-то сделал обязательным использование своего ГОСТа 57580.1, сославшись на него в новом проекте. Именно в нем даются ссылки на 3 уровня защиты информации из ГОСТа, которые и описывают базовый (рекомендуемый, а не минимальный) набор защитных мер для разных типов кредитных организаций. Оценка соответствия новым требованиям осуществляется внешним лицензиатом на соответствие ГОСТ 57580.2.

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

Требования для некредитных финансовых организаций

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

1. Такие организации обязаны изучить регулирование криптографии, которая им может потребоваться как для защиты ПДн, так и для защиты иной информации. Также они должны изучить законодательство об электронной подписи.
2. Такие организации обязаны информировать ФинЦЕРТ о выявленных инцидентах.
3. Такие организации обязаны присоединиться к ГосСОПКЕ и взаимодействать с ФСБ для уточнения порядка информирования ФинЦЕРТа и ГосСОПКИ.

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

Дата вступления в силу новых проектов не установлена (будет зависеть от даты принятия), а вот  требование по сертификации банковского/финансового ПО (исключая небольшие финансовые некредитные организации, которым это не требуется) вступают в силу с 1-го января 2020 года, требования по использованию ГОСТа 57580.1 и внешнему аудиту соответствия ГОСТ 57580.2 - с 1-го января 2021 года.