14.08.2018

Впечатления от проведенных киберучений

Не успел написать впечатления от "Кода ИБ. ПРОФИ" в Сочи - уехал в отпуск. Но сейчас надо исправляться, тем более что есть чем поделиться. Я уже писал о том, что в рамках сочинской конференции я буду читать мастер-класс по Threat Intelligence (материалы по не я выкладывать не буду - презентация и двухчасовое видео доступно только для участников "Кода ИБ. Профи" и купивших доступ к контенту) и проводить киберучения. Вот о последних мы и поговорим.


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

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

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


Но вот что мне хотелось бы отметить, так это неготовность участников к общению с бизнесом. Вообще эта тема (бизнес и ИБ) красной нитью проходит через все "Коды ИБ. Профи" и мы постоянно ее поднимаем в разных мастер-классах. Но несмотря на это стоит отметить, что пока она еще не вышла за рамки теоретических рассуждений и дискуссий; мало кто ее пытается применить на практике. Так получилось и на киберучениях. Последним кейсом, который рассматривался, стала ситуация, когда CISO приглашен на совещание руководства компании и ему надо за 5 минут доложить о том, что происходило в рамках предыдущих 8 кейсов, что это означает, какие уроки извлечены и что надо, чтобы ситуация не повторилась. И вот тут команды (а их было пять) на мой взгляд спасовали. Они стали отвечать так, как будто перед ними сидят их коллеги-безопасники - привычный сленг, привычные объяснения. Но для топов они не работают, так как никак не связаны с бизнесом.

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

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

13.08.2018

Imperva покупает Prevoty

Компания Imperva 26 июля подписала соглашение о приобретении за 140 миллионов долларов компании Prevoty, работающей в сегменте DevSecOps и выпускающей решения по защите приложений в процессе исполнения. 

Cisco покупает Duo Security

2 августа компания Cisco анонсировала приобретение частной компании Duo Security, являющейся лидером рынка многофакторной аутентификации и унифицированного защищенного доступа. Cisco последовательно расширяет свое портфолио, выводя свои традиционные корпоративные решения в облака. Вслед за покупкой OpenDNS (облачный Secure Internet Gateway), Observable Networks (облачный мониторинг аномалий), CloudLock (облачный анализ приложений и утечек), добавился и облачный контроль доступа (в развитие решения Cisco ISE). Стоимость сделки составила 2,35 миллиарда долларов. 

25.07.2018

Тест "Кобаяси Мару" при приеме безопасника на работу

Помните вселенную "Звездного пути" (Star Trek), в которой курсантам Звездного флота предлагали пройти тест "Кобаяси Мару", который моделировал изначально проигрышную ситуацию, которая должна была показать характер и качества курсантов? Так вот когда я готовился к киберучениям для сочинского "Кода ИБ. Профи", которые пройдут уже в эту пятницу, мне вспомнился этот тест. Но немного в другом контексте. Почему бы его не модифицировать под информационную безопасность и не использовать при приеме на работу?


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

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

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

Чем не идея? Среди других тестов "Кобаяси Мару" в ИБ может быть проверка дилемм "отечественное или зарубежное средство защиты", "open source vs коммерческое ПО", "своя система защиты vs аутсорсинг"...

ЗЫ. В фильме Джеймс Кирк проходит этот тест (единственный курсант в оригинальной вселенной "Звездного пути") просто "взломав" компьютер и изменив программу. Это позволяет проверить если не характер, то оригинальность мышления кандидата, что тоже может быть одной из задач теста.

23.07.2018

Новая триада законодательства по финансовой безопасности (презентация)

Еще одной темой презентации, прочитанной мной на Payment Security, стало новое законодательство, применимое к финансовым организациям. Это и пресловутый ФЗ-187, и новая редакция 382-П и ГОСТ 57580.1. Вот об этой триаде (хотя к ней можно было бы добавить и удаленную идентификацию) я и говорил в Питере. Вроде ничего нового, но вдруг кому-то будет интересно :-)



Сегодня для обнаружения атак недостаточно систем обнаружения атак (презентация)

На прошедшей на прошлой неделе в Питере Payment Security довелось мне вернуться к истокам - к теме обнаружения вторжений, которой я начинал заниматься в 98-м году и про которую написал в 2000-м свою первую книгу. Прошло 20 лет, а некоторые отечественные разработчики так и застыли в том времени, используя те же самые подходы к разработке средств обнаружения атак/вторжений. Отчасти это связано с нормативной базой, которая и задает тон для российских разработчиков. Но сегодня обнаружение атак - это не тоже самое, что и 20 лет назад. Этот очевидный тезис не столь очевиден для многих потребителей, которые по-прежнему живут в парадигме "для обнаружения атак надо использовать СОВ/СОА". Но за прошедшие пару десятилетий изменилось многое - атаки, технологии, подходы, архитектуры. И все это надо учитывать при выстраивании системы обнаружения атак на предприятии. Именно системы, а не средства. Одним продуктом это не решить (какой бы он ни был). Этому и была посвящена презентация, которую я выкладываю в блоге.



ЗЫ. Я знаю, что SlideShare недоступен для многих пользователей из-за блокировки LinkedIn. Но обойти это ограничение не составляет большого труда.

13.07.2018

Broadcom покупает CA

11 июля компания Broadcom, один из лидеров рынка поставщиков полупроводников, согласился купить компанию CA за почти 19 миллиардов долларов. Зачем это Broadcom не совсем понятно - не повторилась бы история с Intel и McAfee. Но будем посмотреть...

Фиды - это еще не Threat Intelligence

“А у вас есть фиды?” - так часто начинается разговор наших заказчиков, которые обращаются к нам с вопросом о наличии у нас решений класса Threat Intelligence. “А у нас есть фиды!” - так часто звучит доказательство наличия системы TI в организации. Но фиды - это еще не Threat Intelligence, это скорее попытка заговорить о создании программы TI (или CTI, Cyber Threat Intelligence) в организации. Хотя и просто работа с фидами - это тоже непросто. Как, например, понять, когда полученный в рамках обмена фидами индикатор в виде IP-адреса вредоносного узла необходимо перестать учитывать, потому что он был "вылечен"? Или вот реальный свежий пример. Приходит в рамках информационного обмена индикатор в виде имени домена, который надо блокировать, а там "media.kaspersky.com"!!! С какого перепуга, спрашивается? Начинаешь переписку, а тебе в качестве доказательства вредоносности приводят статью из New York Times, где говорится, что продукты ЛК шпионят за пользователями. Просишь доказательств, а их нет. И как верить такому источнику? А ведь можно вспомнить и историю с Гризлигейтом, когда Россию обвиняли почем зря во вмешательстве в американские выборы и приводились "какие-то" индикаторы, которые с тем же успехом могли играть и против американцев. А ведь это только фиды. В категории уровней TI - это самый нижний, технический уровень.


Выше у нас еще есть тактический уровень, на котором надо оперировать тактиками, техниками и процедурами (TTP). Помните, в ноябре 2016-го я писал об этом? В пирамиде это самый верхний и самый непростой уровень для сбора информации. Да, мы можем использовать ATT&CK, но как формализовать описание методов злоумышленников? Тоже непростая задача; особенно в условиях повального импортозамещения, когда все западные продукты, использующие ATT&CK в своей работе, не могут быть использованы многими российскими предприятиями, а российские продукты вообще не используют ATT&CK в своем функционале.


Но допустим мы решили и эту проблему, какие сложности встают перед нами? Второй по поулярности вопрос после "а у вас есть фиды", звучит так: "А можете прислать ссылок на источники фидов и желательно бесплатных?" :-) Ох уж это неискоренимая жажда халявы :-) Ну да ладно, есть такие списки и предоставляемые ими фиды вполне себе неплохи на первых порах (с учетом ранее описанных нюансов).


А где их хранить все эти фиды и описание TTP? А как поднять с тактического уровня на операционный и оперировать уже целыми кампаниями? Как от разрозненных индикаторов перейти к пониманию того, что против нас действует целая группировка и уж точно попадание в логи МСЭ или IPS IP-адреса из присланного фида является неслучайным совпадением? Для этого нам нужны платформы Threat Intelligence (TIP), которые могут быть коммерческими и бесплатными, закрытыми и открытыми, зарубежными и отечественными. А не накроется ли выбранными нами TIP медным тазом, как это произошло с Soltra)? Есть ли у нас план Б на этот случай?


И конечно не стоит сбрасывать со счетом TI, предоставляемый нам государством, ГосСОПКОЙ или ФинЦЕРТом. В чем их сила, а в чем слабость? Это тоже вопросы, которые требуют ответа. Правда, с ГосСОПКОЙ пока все ясно - там нет ничего, что можно было реально использовать, - ни достаточного количества данных, ни ясной процедуры подключения, ни утвержденных стандартов обмена данными об инцидентах.


Кстати, о стандартах. Какой их них выбрать? STIX, используемый большинством компаний в мире и ставший по сути стандартом де-факто в этой области? CybOX? А может отечественный СТО 1.5, разработанный Банком России, и требуемый для взимодействия с ФинЦЕРТом? А что будет использовать ГосСОПКА (кроме TLP)? Не получится ли так, что мы сейчас выберем то, что не будет поддерживаться ни регуляторами (куда уж без них), ни отечественными разработчиками (хотя вот BI.ZONE в своей платформе обмена данными использует расширенный вариант STIX).


Но допустим мы выбрали платформу, выбрали источники фидов, научились описывать не только отдельные индикаторы и целые компании, но даже смогли подняться на стратегический уровень TI (он не всем нужен, кстати) и заняться атрибуцией нарушителей (со всеми оговорками, которые связаны с данной процедурой). Как измерить процесс Threat Intelligence? Как понять, что и сам процесс работает эффективно, и используемые нами источники дают ценную информацию, которую мы действительно используем, а не просто складируем в TIP?


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

10.07.2018

Thoma Bravo покупает Centrify

Частный инвестиционный фонд, хорошо известный в области поглощения на рынке ИБ, Thoma Bravo, объявил 10 июля о намерении приобрести одного из игроков рынка контроля привилегированного доступа, компанию Centrify. Размер сделки не разглашается.

AT&T покупает AlienVault

10 июля американский провайдер AT&T объявил о планах по приобретению компании AlienVault, известного разработчика SIEM (коммерческого USM и бесплатного OSSIM) и поставщика Threat Intelligence. Размер сделки не разглашается.

09.07.2018

Будущее криптографии: гомоморфное, медовое, функциональное и ДНК-шифрование

Завершу все-таки начатую тему про будущее криптографии (вдруг доживем) упоминанием еще нескольких направлений, который сейчас достаточно активно прорабатываются в индустрии (помимо постквантовой криптографии и нейросетей):
  • Медовое шифрование. Когда я только начинал изучать криптографию, то я задавался вопросом: "А как при автоматизации процесса дешифрования понять, что мы получаем правильный текст и как отличить один набор получаемых символов от другого?" И вот проблема, лежащая в основе этого вопроса, легла и в основу нового метода шифрования под названием "медовое". Когда криптоаналитик пытается дешифровать шифртекст с помощью неверного ключа он получает бессмысленный текст; в случае с медовым шифрованием криптоаналитик получает вполне осмысленную последовательность. И злоумышленник даже не понимает - он получит реальный открытый текст или фальшивый? Интересный проект.
  • Гомоморфное шифрование. Когда мы используем обычное шифрование, то мы сталкиваемся с ситуацией, к которой мы привыкли и даже не считаем ее проблемой. Чтобы поработать с зашифрованными данным мы их должны расшифровать и тогда они могут стать достоянием злоумышленников. Гоморфное же шифрование подразумевает, что вы можете проводить операции над зашифрованным текстом и получать вполне адекватный результат без расшифрования текста. Например, такую схему можно использовать в электронных выборах (подсчет голосов при сохранении анонимности избирателей), в облачных вычислениях, при защищенном поиске (выдача результата без анализа его реального содержимого) или в системах с обратной связью и т.п. И хотя идея гомоморфного шифрования была сформирована 40 лет назад, первый полностью гомоморфный алгоритм появился только в 2008-м году, но до сих пор все такие системы являются крайне низкопроизводительными, что и ограничивает их активное применение в реальной жизни. 
  • Функциональное шифрование. С одной стороны функциональное шифрование, предложенное в 2005-м году, базируется на идее шифрования с открытыми ключами, а с другой - в нем передается не зашифрованное сообщение, а зашифрованная функция, которая позволяет по аналогии с гомоморфным шифрованием обеспечить защиту данных не расшифровывая их целиком. Например, одним из сценариев применения такой схемы является защита программного обеспечения от анализа злоумышленниками. После его функционального шифрования мы получаем эквивалентный по функциональности, но недоступный для анализа, обфусцированный исходный код. Помимо защиты интеллектуальной собственности функциональное шифрование может быть применено и в облачных вычислениях.
  • ДНК-шифрование. В 1994-м году Леонард Адлеман (ему "принадлежит" буква А в алгоритме RSA) предложил идею использования ДНК для осуществления вычислений путем манипулирования молекулами, что позволяет производить параллельно триллионы операций. В отличие от бинарной логики современных компьютеров и кубитов квантовых компьютеров у ДНК-вычислений код тернарный (на основе 4-х оснований), что и обеспечивает огромную скорость вычислений. Однако извлечение результата вычислений из ДНК осуществляется гораздо медленнее, что пока и сдерживает активное их использование, в том числе и для криптоанализа.


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

PS. Кстати, у Siri очень забавные поисковые ассоциации с описанными в заметке вариантами шифрования :-)


05.07.2018

ФСТЭК определилась со своим будущим

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

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



03.07.2018

Комната для SOC: освещение и вентиляция, а также реверберация и кактусы на мониторах

После 12-ти минут непрерывного мониторинга оператор пропускает 45% активности на мониторе, после 22-х минут - до 95%. В целом после 20-40 минут активного мониторинга оператор систем охранного телевидения сталкивается с психологической слепотой и перестает распознавать любые объекты. Думаю, что у аналитиков SOC цифры не сильно отличаются. И возникает вопрос, как не ухудшить эти показатели? В прошлой заметке про количество мониторов я не стал касаться еще одной темы, связанный с помещением для SOCа. Поговорим о ней сегодня.

Когда Cisco много лет назад выводила на рынок технологию TelePresence, мы на первых порах, если мне не изменяет память, столкнулись с проблемой недовольства клиентов тем, что они не получали обещанный эффект присутствия. В результате первых пилотов, выяснилось что оборудование ставилось в обычные кабинеты, где раньше стояли ВКС-системы. Отсюда и недовольство - комнаты оказались неприсособленными для TelePresense. Отсутствие правильного освещения, акустики, эстетики, сказывалось на впечатлении заказчиков и эффективности проводимых переговоров. В результате у нас родилось руководство по проектированию комнат для TelePresence (советую посмотреть - там многие моменты применимы не только к TelePresence).


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


Я не планировал в одной заметке описать все возможные нюансы, возникающие при создании центров мониторинга. Просто мне хотелось обратить внимание на моменты, которые не часто рассматриваются в реальной жизни и уж совсем не озвучиваются на различных мероприятиях. По крайней мере я не помню ничего такого на всех наших SOC Forum'ах; да и на американских SOC Summit'ах тоже. Мы когда строим SOCи или оцениваем их зрелость обращаем на эти моменты внимание. Но что делать тем, кто не может обратиться к Cisco?

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

Многие стандарты этой серии переведены на русский язык и приняты в качестве ГОСТа:
  • ГОСТ Р ИСО 11064-1-2015 Эргономическое проектирование центров управления. Часть 1. Принципы проектирования
  • ГОСТ Р ИСО 11064-2-2015 Эргономическое проектирование центров управления. Часть 2. Принципы организации комплексов управления
  • ГОСТ Р ИСО 11064-3-2015 Эргономическое проектирование центров управления. Часть 3. Расположение зала управления
  • ГОСТ Р ИСО 11064-4-2015 Эргономическое проектирование центров управления. Часть 4. Расположение и размеры рабочих мест
  • ГОСТ Р ИСО 11064-5-2015 Эргономическое проектирование центров управления. Часть 5. Дисплеи и элементы управления
  • ГОСТ Р ИСО 11064-6-2016 Эргономическое проектирование центров управления. Часть 6. Требования к окружающей среде
  • ГОСТ Р ИСО 11064-7-2016 Эргономическое проектирование центров управления. Часть 7. Принципы верификации и валидации
И вновь повторю свое заключение из прошлой заметки - проектируя SOC, занимаясь TI-платформами, SIEMами, Stealthwatch'ами и другими компонентами центра мониторинга, не забывайте и про помещение для него, его юзибилити и эргономику рабочих мест, от которых заависит, насколько комфортно, а значит эффективно, будут работать его аналитики и обнаруживать угрозы.

02.07.2018

Разделенное внимание, мнимая многозадачность и количество мониторов в SOC

Наверное многие видели фотографии SOCов с огромными экранами, на которых что-то показано красивое и переливающееся всеми цветами радуги. А вы знаете, что по статистике, эти экраны не используются в 80% времени, исключая приходы руководства, СМИ (если компания важная) и важных клиентов.


Вместо правильного их использования (например, для вывода дашбордов) в SOC почему-то принято ставить у аналитиков по несколько мониторов. Вот примерно так:


Но на самом деле человек не способен работать в многозадачном режиме. Многие компьютеры тоже это не умеют несмотря на термин "многозадачность" (если не брать в расчет многопроцессорные или распределенные системы). Просто разные задачи распределяются между тактами процессора и переключение между задачами происходит незаметно для человеческого глаза. А вот человеческий мозг так не умеет (ну если вы не Юлий Цезарь, конечно). Более того. Мнимая человеческая многозадачность приводит к замедлению работы и забывчивости. При переключении мы откладываем дела в краткосрочную память и можем забыть до 40% в ней хранящегося, то есть того, что делали и планировали делать. Вот, посмотрите ролик, в нем как раз хорошо показан результат переключения с задачи на задачу:



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

В этой области (change blindness) проводится достаточно много различных исследований, особенно военными, у которых цена ошибки достаточно высока. В частности, ВМС США проводили такое исследование "Verification of the change blindness phenomenon while managing critical events on a combat information display" с целью определить, каков процент изменений на мониторах упускают из ввиду операторы ВВС, следящие сразу за несколькими мониторами. Согласно многочисленным исследованиям, на полное восстановление состояния глубокой концентрации после отвлечения на другие задачи, уходит примерно 15 минут. Иными словами, использование двух и более мониторов, отображающих разные типы информации, может негативно сказаться на способности концентрировать внимание. Это иная сторона психологической слепоты, о которой я уже писал в октябре.

А сколько мониторов нужно для того, чтобы работа аналитика SOC была максимально эффективной? Если честно, то я не нашел ни одного исследования, дающего ответ именно на этот вопрос. Но есть исследования, которые отвечают на вопрос относительно числа мониторов у операторов систем охранного видеонаблюдения. Согласно исследованиям, при использовании одного, четырех, шести и девяти мониторов, точность обнаружения составляет 85%, 74%, 58% и 53% соответственно. В различных материалах говорится, что чем критичнее область контроля (например, казино или алмазные компании), чем меньше мониторов используется - не больше 3-4-х. В SOCе же объекты контроля не только меньше, но и менее заметные, чем у видеонаблюдения, поэтому и мониторов должно быть меньше. Если бы мы наблюдали только за DDoS, то мы могли бы использовать больше мониторов, но увы... бывают и другие, менее заметные атаки, а значит число мониторов не должно быть большим. Тем более, что одна атака может скрываться за другой, отвлекающей внимание, и концентрация внимания у аналитика должна быть достаточно высокой - большое число мониторов только распыляет его концентрацию.

Бороться с описанной проблемой можно несколькими путями:
  1. Не использовать больше двух мониторов на аналитика.
  2. Согласно исследованиям многозадачность гораздо меньше сказывается на молодых женщинах, чем на пожилых мужчинах (возраст и пол имеют значение). Поэтому в качестве аналитиков SOC эффективнее брать прекрасную половину человечества, что, правда, немного отличается от современных реалий.
  3. Проводить тест Мюнстерберга при приеме на работу аналитиков SOC, который позволяет проводить профотбор тех, кто обладает хорошей избирательностью и концентрацией внимания (правда, если есть из кого выбирать и можно проводить тесты).
  4. Выбирать (разрабатывать) решения по мониторингу с учетом соответствующих рекомендаций по проектированию графического дизайна (например, вот). 

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

ЗЗЫ. Карты атак тоже бессмысленны для больших экранов. Да и вообще бесполезны.

29.06.2018

ЦБ получает новые полномочия по регулирования рынка ИБ

27 июня всенародно избранный Президент (кстати, очень много законов, связанных с ИБ, подписывалось Президентом именно 27-го июня) подписал Федеральный закон 167-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части противодействия хищению денежных средств». На сайте Президента написано буквально следующее:

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

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

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

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



Все это безусловно верно, но я бы отметил две других нормы, о которой в справе ГПУ (государственно-правового управления) не сказано ни слова, а именно две новых статьи закона "О Центральном банке Российской Федерации (Банке России)":

  • "Статья 57.4. Банк России по согласованию с федеральным органом исполнительной власти, уполномоченным в области обеспечения безопасности, и федеральным органом исполнительной власти, уполномоченным в области противодействия техническим разведкам и технической защиты информации, устанавливает обязательные для кредитных организаций требования к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента, за исключением требований к обеспечению защиты информации, установленных федеральными законами и принятыми в соответствии с ними нормативными правовыми актами".
  • "Статья 76.4.1. Банк России по согласованию с федеральным органом исполнительной власти, уполномоченным в области обеспечения безопасности, и федеральным органом исполнительной власти, уполномоченным в области противодействия техническим разведкам и технической защиты информации, устанавливает обязательные для некредитных финансовых организаций требования к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков, предусмотренной частью первой статьи 76.1 настоящего Федерального закона, в целях противодействия осуществлению незаконных финансовых операций, за исключением требований к обеспечению защиты информации, установленных федеральными законами и принятыми в соответствии с ними нормативными правовыми актами".
Иными словами, если раньше Банк России в лице ГУБЗИ устанавливал обязательные требования по безопасности только для участников Национальной платежной системы (по ст.27 ФЗ-161), то по истечении 90 дней с момента опубикования 167-ФЗ Центробанк получит права устанавливать обязательные требования для кредитных организаций (привет ГОСТ 57580.1 и др.), а также для всех некредитных финансовых организаций - страховых, негосударственных пенсионных фондов, бирж, микрофинансовых организаций, ломбардов и т.п. А планов по разработке новых требований у ЦБ немало - почти два десятка документов.


Революция от ЦБ: новая версия 382-П

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


Начну с более приземленной и практичной, но совершенно не раскрытой темы - уведомления об инцидентах ИБ. Лично я ждал, что ЦБ все-таки потребует от участников НПС (а 382-П распространяется именно на них) уведомления об инцидентах по форме, используемой в 552-П, то есть в течение 3-х часов с момента наступления инцидента. Но увы... ЦБ не смог ни определить перечень инцидентов, сославшись на то, что это будет сделано в виде отдельного документа, размещаемого на сайте ЦБ, ни определить порядок уведомления, также сославшись на то, что порядок и форма уведомления должны быть согласованы с ФСБ, курирующей ГосСОПКУ. Как мне кажется, это (а также сроки принятия новой редакции - больше года) связано с тем, что ФСБ в лице 8-го Центра и НКЦКИ до сих не смогли утвердить ни одного документа по ГосСОПКЕ в рамках 187-ФЗ. Ждать больше ЦБ не захотел или не смог, поэтому принял документ в этой части в абсолютно размытой и неконкретной формулировке, которая еще даст о себе знать.

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

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

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

Вторым революционным изменением (после сертификации прикладного ПО) стало другое, которое имеет далеко идущие последствия для всего рынка и даже, не побоюсь этого, для всей цифровой экономики, как бы не смешно звучало это словосочетание в наших условиях. Речь идет о поголовном переходе всех финансовых организаций на российскую криптографию!!! Да-да, именно так. Мне можно возразить, что в 4793-У написано только про значимые платежные системы (кстати, в проекте упоминались национально значимые ПС), но давайте посмотрим на перечень таких систем. Там есть, как минимум, Сбербанк, Visa, Master Card и НСПК. Достаточно? Все банкоматы и POS-терминалы, все ДБО, позволяющие пополнять карточные счета, должны будут перейти на российскую криптографию. Пункт о том, что в остальных случаях можно применять СКЗИ иностранного производства в таком варианте звучит как издевка. Учитывая, что с 2011-го года, когда начался писаться первый вариант 382-П, эту формулировку не удавалось протоклнуть через ФСБ, а сейчас это удалось, мне кажется это сделано осознанно. Ситуаций, когда можно будет обойти компоненты инфраструктуры значимых платежных систем, практически нет. Кстати, требования от международных платежных систем перейти на российскую криптографию, не значит ли перевода и платежных карт Visa и MC на нее?

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

ОБНОВЛЕНИЕ

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

КОНЕЦ ОБНОВЛЕНИЯ

В обоих случаях (отечественная криптография для защиты денежных переводов и ПДн) неотвеченным остается вопрос квантовых атак, но я им уже задавался и ответа на него пока не слышал/не видел. С практической же точки зрения я хотел бы обратить внимание на существенные финансовые обременения (глава НСПК на прошлогодней конференции Payment Security в Питере называл цифру в миллиарды долларов только для одной НСПК), связанные с внедрением российской криптографии, а также определенные технические сложности, которые я предвижу в этом процессе. Ведь переход на ГОСТы произойдет не одномоментно и будут ситуации, когда какие-то системы будут работать на российской криптографии, а какие-то на международной. То есть придется дублировать системы управления ключевой информацией, HSMы, ПО на картах и POS-терминалах и т.п. Вопрос стабильности работы двух параллельных СКЗИ еще предстоит анализировать. Но простым он точно не будет. Тут дело даже не в криптографии как таковой, а в ее практической реализации, внедрении и поддержке.

Прошлой весной, когда появился проект новой редакции 382-П, срок его введения был установлен на 1 июля 2018-го года. То есть давался примерно год на реализацию многих защитных мер. В текущей редакции, зарегистрированной Минюстом, 22 июня, срок остался... тем же - 1 июля 2018 года. Учитывая, что главки ЦБ стали рассылать 4793-У только 27-го июня, оставалось всего 2 рабочих дня на его реализацию :-( Два рабочих дня!!! Но есть и исключения:
  1. Требование по сертификации прикладного ПО или оценке уязвимостей по ОУД4 вступает в силу с 1-го января 2020 года (а вот пентесты и анализ уязвимостей объектов информационной инфраструктуры с 1-го июля 2018-го). У некоторых главков ЦБ есть мнение, что это не так и сертификация должна быть реализована с 1-го июля, но это не так. Достаточно посмотреть методические рекомендации по юридико-техническому оформлению законопроектов, в котором написано, как и откуда считается нумерация абзацев.
  2. Требование разделения контуров вступает в силу с 1-го января 2020-го года.
  3. Требование применения в значимых платежных системах HSM на базе иностранных криптографических алгоритмов, согласованных ФСБ, и вообще иностранных СКЗИ (с учетом оговорок выше) вступает в силу с 1-го января 2024-го года.
  4. Требование применения в значимых платежных системах HSM на базе иностранных криптоалгоритмов и ГОСТов по криптографии, подтвержденных ФСБ, вступает в силу с 1-го января 2031-го года.
  5. Требование применения в значимы платежных системах СКЗИ на базе иностранных криптоалгоритмов и ГОСТов по криптографии (исключая HSM), подтвержденных ФСБ, вступает в силу с 1-го января 2031-го года.
  6. Требование применения в национально значимых платежных системах HSM на базе иностранных криптоалгоритмов и ГОСТов по криптографии, подтвержденных ФСБ, в соответствие с 3342-У про требования к ИТ в национально значимых платежных системах.
А что же надо делать со следующей недели? А вот что:
  • Анализ уязвимостей и пентесты информационной инфраструктуры (обойти это требование нельзя). Это лицензируемый вид деятельности.
  • Применение 378-го приказа ФСБ, если вы для защиты ПДн хотите использовать СКЗИ (можно творчески подойти, как я описывал ранее)
  • Информировать об инцидентах ГосСОПКУ и ФинЦЕРТ (но после того, как ФСБ разродится своими приказами).
  • Отказ ЦБ от самооценки и переход на аудит с помощью лицензиатов ФСТЭК был ожидаемым и он вступает в силу с 1-го июля.
Документ хоть и короткий, но емкий - большинство пунктов отнесены на перспективу от 1,5 до 13 лет, что дает определенную свободу маневра, но требует и более серьезной проработки стратегии выполнения этих недешевых требований регулятора за это десятилетие, включая и оценку будущих угроз и изменения ИТ-ландшафта, которые тоже надо учитывать.

28.06.2018

Ping Identity покупает Elastic Beam

26 июня американская Ping Identity, поставщик решений для идентификации и аутентификации, объявила о приобретении производителя решений для защиты API - Elastic Beam. Размер сделки не сообщатся.

А вы сталкивались когда-нибудь с ливийским скорпионом?

Что меня всегда поражало в атрибуции киберугроз и приписывание тех или иных кибернападений тем или иным государствам и группировкам, так это четыре вещи:
  1. Потрясающие названия. Ну только вслушайтесь: "Ливийские скорпионы", "Пыльная буря", "Хищная панда", "Тропический кавалерист", "Ночной дракон", "Цветочная леди", "Ледяной туман", "Панда со скрипкой", "Обрезанный котенок", "Шакал повстанцев", "Скрытый ястреб" и т.п. Такое впечатление, что все усилия эксперты по ИБ тратят на придумывание названий, а не добычу доказательств и нормальную атрибуцию. Но надо признать, что выглядят такие высосанные из пальца названия хакерских групп солидно. Всегда приятно осознавать, что тебя атаковал какой-нибудь "Летучий кедр" (сразу вспоминается диалог из фильма "Операция "Ы"" про "...а чтоб никто не догадался"), а "группа неизвестных лиц неопределенной национальности" :-)
  2. Красивая визуализация.  Вторая половина усилий тратится на то, чтобы отрисовать комиксоподобные изображения хакерских группировок. Это выглядит красиво, но бессмысленно. Особенно когда натыкаешься на перечень всей "сувенирки", которая создается вокруг бездоказательных заявлений - футболки, брошюры, стикеры, скринсейверы, картины, календари


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


  4. Почти полное отсутствие хакерских групп в США. Вот смотришь на разоблачения какого-нибудь Fireeye или CrowdStrike и думаешь, а почему в ваших списках APTxxx есть все геополитические противники США (Китай, Северная Корея, Иран, Ливия, Сирия), но нет ни одной американской группы хакеров? Их там нет? Или про них запрещают писать (не этим ли объясняется пропуски в нумерации групп, названия которы начинается с APTххх)?
В общем, атрибуция киберугроз вещь безусловно важная и нужная, но сегодня слишком политизированная и не имеющая ничего общего с реальной ИБ. Единственный плюс, который я вижу в том, что сегодня некоторые компании излишне усердствуют в придумывании "страшных" названий хакерских групп - это PR, внутренний и внешний. Согласитесь, гораздо круче выглядит, если вывести на карту атак не просто IP-адрес атакующего, а его название, и сообщить руководству, что компания была атакована "Обрезанным котенком", "Срущим слоном" или, что еще ужаснее, "Ливийскими скорпионами" :-)

Для тех, кому интересен список всех известных сегодня хакерских групп, могу посоветовать воспользоваться вчера анонсированным сайтом APTMAP:


27.06.2018

Будущее криптографии: нейросети создают новые алгоритмы шифрования

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

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


В октябре 2016-го года Мартин Абади и Дэвид Андерсен из Google опубликовали результаты своего исследования, в котором они изучали возможность применения нейросетей для защиты коммуникаций от атак со стороны других нейросетей. Было создано три нейросети - Алиса, которая пыталась создать метод шифрования, Боб, которая, должна была расшифровать трафик от Алисы, и Ева, которая выступала в роли врага и должна была дешифровать трафик, передаваемый между Алисой и Бобом. Самое интересное, что нейросеть Алиса ничего не знала о криптографических алгоритмах и способах их применения - она до всего "дошла" сама. В заключении к своему исследованию инженеры Google предположили, что нейросети могут быть применены и в других областях криптографии - генерации псевдослучайных чисел, проверки целостности, стеганографии. В конце Абади и Андерсен даже предположили, что нейросети могут быть использованы для анализа зашифрованного трафика с целью анализа его содержимого. К слову сказать, к этому моменту у Cisco уже была разработана технология Encrypted Traffic Analytics, которая ровно это и делала, и позволяла обнаруживать вредоносный код в зашифрованном трафике (я писал про это тут).

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

ЗЫ. Исходники описанных нейросетей можно найти на GitHub. Надеюсь эту ссылку нельзя рассматривать как распространение СКЗИ и мне не потребуется лицензия ФСБ :-)

Провожу киберучения по ИБ! Присоединяйтесь!

Многие специалисты по ИБ прекрасно знают о том, что они могут стать жертвами киберпреступников и имеют прекрасные наборы технических мер защиты от них. Но атаки все равно происходят и ущерб организации, финансовый или репутационный, все равно наносится. Одной из причин, почему все-таки, несмотря на наличие широкого спектра навороченных и не очень мер защиты мы все равно сталкиваемся с проблемами, является отсутствие практического опыта реагирования на нештатные ситуации. Мы знаем КАК защититься, но не всегда представляем, ЧТО ДЕЛАТЬ, когда произошло что-то плохое. Куда бежать? Кому звонить или писать? Какие шаги предпринимать, чтобы купировать последствия киберинцидентов? Проверять и нарабатывать опыт во время атаки – не самый лучший путь. Проводить технические киберучения (типа Cyber Range) тоже не всем под силу и все-таки они ориентированы на технических специалистов – аналитиков SOC, специалистов по Threat Hunting, экспертов по расследованию инцидентов. А что делать руководителям ИБ или их заместителям? Ответ есть – штабные киберучения.

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

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

Для участия в киберучениях на «Код ИБ. Профи» вам не нужно ничего, кроме вашего желания и хорошего настроения. Все остальное – сценарии, неожиданные вбросы, многоходовые комбинации, реальные жизненные ситуации и кейсы, шутки и юмор, вам предоставлю я :-)

Присоединяйтесь - будет интересно!!!


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

26.06.2018

Что общего между пенсией и ГосСОПКА?

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

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

Если опросить многих людей, то для них термин "безопасность" имеет абсолютное значение и может быть описан бинарной логикой - вы либо в безопасности, либо нет. И мы почему-то эту логику транслируем на все фразу, в которых упоминается термин "безопасность". Например, "национальная безопасность". Мы считаем, что государство нас должно защищать от разных напастей. Меня, тебя, его, их... Но это не так. Государство обеспечивает безопасность себя. От врагов. Внешних и внутренних. В рамках своей модели угроз, которая отличается от вашей или моей. Мне иностранные ИТ-вендоры не враги. И Украина не враг. И Макаревич с Шевчуком. А государство считает иначе и поэтому предпринимает шаги, направленные на мою свою защиту.


Можно спорить с новой пенсионной якобы реформой. Можно не соглашаться с поднятием НДС. Можно выступать против обязательного страхования жилья (это новая инициатива государства). Можно требовать повышения качества медицинских услуг (я уже лет 20 не был в обычной поликлинике). Можно сетовать на низкое качество образования в ВУЗах. А можно попробовать самостоятельно, без оглядки на государство "которое должно" попробовать решить стоящие проблемы.

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

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

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

19.06.2018

F-Secure покупает MWR InfoSecurity

18 июня финская F-Secure подписала соглашение о покупке MWR InfoSecurity, занимающуюся threat hunting, пентестами и антифишингом. Размер сделки составляет 91 миллион евро.

Новая отечественная TI-платформа и здоровая конкуренция между двумя главными банками страны

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

Интерфейс TI-платформы (фото BIS Journal)
Платформа обмена данными позволит участникам АБР в режиме реального времени получать самую актуальную информацию о киберугрозах, злоумышленниках и их методах работы (речь идет о TTP), и автоматически применять ее в своих защитных решениях через API. Что интересно, участники АБР могут направить (и уже направили) в BI.ZONE данные о своих средствах защиты, которые можно будет автоматически интегрировать с Платформой.

Компания BI.ZONE ("дочка" Сбербанка) - технический провайдер сервиса. В течение бесплатного пилотного периода, который продлится 3 месяца, информация (читай, индикаторы компрометации) в Платформу будут поступать только из потока данных BI.ZONE. После этого возможность загружать данные получат все организации-участники сервиса. База индикаторов компрометации и обширная контекстуальная информация помогут повысить защищенность инфраструктуры, снизить количество инцидентов и, в конечном счете, ущерб от атак киберпреступников. На данный момент к Платформе подключились «Сбербанк России», «Кубань Кредит» и Саровбизнесбанк. В ближайшее время также ожидается подписание соглашений с 17 другими банками, также выразившими желание присоединиться к Платформе.

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


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

Получается этакая здоровая конкуренция, которая движет рынок вперед. Тем интереснее будет увидеть планы, которые были озвучены Станиславом Кузнецовым (зампред Сбербанка по безопасности) в январе этого года:

  • Оповещать кредитные организации о рисковых событиях по абонентам, в том числе при выдаче дубликатов и замене SIM-карт.
  • Обеспечить выявление мошеннических и спам-рассылок SMS-сообщений в SMS и мессенджерах.
  • Законодательно закрепить ответственность социально значимых Интернет-проектов к информационному обмену с банками информацией о рисковых событиях и реализации собственной системы защиты от мошенничества. Мне казалось, что идею с "социально значимыми Интернет-проектами" похоронили :-(
  • Предусмотреть на законодательном уровне возможность создания площадки обмена данными о мошенниках в режиме реального времени. У ЦБ был (и сейчас он рассматривается) схожий законопроект, но без привязки к режиму онлайн.
  • Создать Национальную Образовательную и Исследовательскую организацию 0 Академию Кибербезопасности. Ну вроде как уже создали и запустили пилотные курсы.
  • Создать эффективную систему контроля защищенности ИТ-инфраструктуры банков страны.
  • Создать Национальный координационный центр по информационной безопасности.

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