Запор Ярилы, стезя педагогона или старославянский словарь импортозаместителей от ИБ

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

Вначале приведу список слов, которые могли бы стать названиями или частью названий продуктов по ИБ - градеж, забрало, заклеп, затвор, запор, оплот, твердыня и столпостена. Все эти слова имеют отношение к ограждению, защите или безопасности. Как могло бы звучать название компании "PT Security"? "Благая твердыня" или "Благой оплот" :-) А "Solar Security"? Например, "Запор Ярилы" (Ярила - это славянский бог солнца, а запор - это от глагола запирать) или "Забрало Ярилы" :-) А вот наезды или хула на Solar Security могли бы называться коротким "обсолонь", то есть движение против солнца.

Какие еще у нас могут быть применимы слова старославянского языка в кибербезопасности? Вот список, например, для английских слов, столь популярных в лексиконе отечественных безопасников:

• backdoor - афедрон
• blackholing - хлябь
• Cisco - лепота
• CISO - воевода, стража, стратиг, стратилат
• compliance - путы 
• CTF - палестра, ристалище 
• dlp - брещи
• Huawei - стезя педагогона
• Infosecurity Russia - позорище 
• SIEM - многоочитый 
• SOC - чертог.

А теперь список англицизмов и соответствующих им посконно русских синонимов:

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

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

• Infowatch - Инфоглядун, Инфосоглядатай или Инфооко
• Secret Net - Тайный Невод
• ViPNet - Знатный Невод
• DIONIS - Корс (это уже не греческий, а славянский бог пьянства)
• Secret Studio - Тайная светлица
• Комрад - Товарисч
• UserGate - Холопские врата
• Мастерчейн - Гривнозлатарь
• Перспективный мониторинг - Узреющая ворожения.

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

Подробнее…

Взлом 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 русских хакеров не обвиняли :-)

Подробнее…

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

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

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

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

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

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

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

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

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

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

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

Подробнее…

Три мифа о специалистах SOC #socforum

В августе я ездил в США в очередной SOC Tour (есть у нас в Cisco такая практика - показывать заказчикам, как устроена ИБ внутри нашей компании) и на встрече в том числе присутствовал Гэри Макинтайр, один из гуру SOCстроительства, автор книги про создание SOCов, приложивший руку к нескольким десяткам SOCов, которые мы помогали строить нашим заказчикам по всему миру. Так вот во время дискуссии с ним он развенчал несколько заблуждений, которые приходится часто слышать о центрах мониторинга ИБ.

В SOC работают квалифицированные специалисты

Бытует мнение, что в SOC работают обычно высококлассные специалисты, охотники за угрозами, аналитики, влет идентифицирующие APT и иные сложные атаки. Увы... Это миф. Даже в Европе уровень ротации специалистов SOC достигает... 90%. 90 процентов!!! О какой квалификации можно говорить в такой ситуации? Люди просто не успевают ее получить, уходя на другое место работы. Понятно, что эта цифра касается не всех работников, но даже на первой линии SOC такой показатель говорит, что специалист может пропускать атаки ввиду своей невысокой компетенции.

Нанимать в SOC надо специалистов по безопасности

Рустем Хайретдинов в ФБ любит упоминать, что он зарекся нанимать на работу сейла безопасников. Их мозги забиты мусором, который сначала надо вычистить, а потом уже прививать что-то нужное. Гораздо проще брать сейла из смежной области, а уж особенностям рынка ИБ научить несложно. Не буду спорить с данным тезисом; тем более что в SOC ровно та же самая ситуация :-) Брать надо не безопасников, а тех, кто обладает хорошими коммуникативными навыками, так нужными при расследовании инцидентов. Если они еще и знаниями ИБ обладают, так вообще супер. Но в первую очередь смотреть надо на то, как общается человек в коллективе, особенно в стрессовой ситуации, которые в SOC происходят регулярно.

Работа аналитика в SOC очень интересна

Вообще я люблю писать и могу делать это достаточно долго (вот в выходные даже 3 статьи накатал). Но даже я устаю от этого. А теперь представьте работу аналитика, который 8 часов в день (а есть SOCи, которые используют 12-тичасовую смену) пялится в экран и пытается найти угрозы в тысячах строк логов, потоков и других источников событий безопасности (даже при высоком уровне автоматизации ручная работа еще очень нескоро уйдет из арсенала безопасников SOC). Одна из классических проблем аналитиков SOC - демотивация. Изо дня в день видеть огромное количество событий и при этом не знать, какие из них хорошие, а какие плохие. Это классическая психологическая проблема боязни совершить ошибку в ответственном мероприятии. Этот страх отвлекает аналитика SOC от смысла выполняемых действий; он фиксируется на мелочах, упуская главное. Страх сделать ошибку заставляет аналитика перепроверять свои выводы и свою работу, что приводит к лишней трате времени и сил и снижает продуктивность специалистов SOC. Возможно и отсюда тоже вытекает высокая ротация в SOCах.

Разумеется, это всё не те проблемы, которые не имеют решения. При правильном подходе из них можно выйти победителем. Главное - задуматься о них заранее, не строя неоправданных ожиданий относительно работы в SOC. Это важно знать не только тем, кто работает в SOC (иногда, общаясь с работниками SOC, слышишь от них о названных проблемах, которые они скрывают от руководства, считая, что это именно их проблемы, в которых они уникальны), но и тем, кто только планирует строить свой SOC. Лучше заранее оценивать реалии работы центров мониторинга ИБ. 

Подробнее…

Почему коммерческие SOCи не имеют права работать с ГосСОПКОЙ

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

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

• подразделения и должностные лица ФСБ
• созданный национальный координационный центр по компьютерным инцидентам (НКЦКИ), часть людей из которого, недавно перешла в Positive Technologies
• подразделения и должностные лица субъектов КИИ.

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

Но и это еще не все. В ст.5.5 говорится о том, что ГосСОПКА осуществляет накопление информации, которая поступает от средств ГосСОПКИ, а также от иных органов и организаций, не являющимися субъектами КИИ. Тут, вроде, все нормально. Коммерческие SOCи, а также компании, предоставляющие услуги Threat Intelligence, вполне имеют право делиться своими данными с ГосСОПКОЙ, но... передача эта односторонняя - только в сторону ГоСОПКИ. А все потому, что согласно ст.5.6 закона о БКИИ НКЦКИ осуществляет обмен информации только между субъектами КИИ или между субъектами КИИ и иностранными органами и международными организациями, занимающимися реагированием на иниденты. Российских компаний в этом списке нет! То есть ни получать, ни передавать данные об инцидентах в КИИ коммерческие SOCи не могут :-(

Я вижу только одно исключение, когда описываемые мной предприятия могут стать полноправными членами ГосСОПКИ, - они должны стать субъектами КИИ и взять на себя все те обязанности, которые накладываются на субъектов. Правда и тут нас поджидает очередной терминологический тупик. Вспомните список тех, кто может называться субъектом КИИ. Там 13 отраслей и организации, которые обеспечивают взаимодействие субъектов КИИ между собой. К этой чертовой дюжине отраслей коммерческие SOCи не относятся. Но и к последней, 14-й "отрасли" их отнести сложно, ведь они не обеспечивают взаимодействие субъектов КИИ, а только обслуживание.

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

Понимаю, что тема дискуссионная и поэтому приглашаю желающих подисскутировать на круглый стол "SOC vs SIEM", который я веду в рамках грядущей InfoSecurity Russia 21-го сентября с 14.00 до 16.00. В круглом столе согласились принять участие:

• Мона Архипова, директор по безопасности, WayRay
• Александр Бабкин, начальник Ситуационного центра информационной безопасности Департамента защиты информации, Газпромбанк
• Александр Бодрик, заместитель генерального директора по развитию бизнеса, ANGARA Professional Assistance
• Александр Бондаренко, генеральный директор, R-Vision
• Алексей Качалин, исполнительный директор Центра Киберзащиты, Сбербанк
• Илья Шабанов, директор, Anti-malware.ru

ЗЫ. Но это не последний тупик, который поджидает нас с законодательством по безопасности КИИ. Их впереди еще много и я к ним еще вернусь.

Атлантические тупики (с ударением на первом слоге)

ЗЗЫ. Кстати, по ссылке вы можете найти презентацию и видеозапись с проведенного 21-го июля вебинара ”Обзор нового законодательства по безопасности критической инфраструктуры”, где я рассматриваю различные нюансы нового регулирования.

Подробнее…

Symantec и Nevis Networks продают часть своих бизнесов

1 августа американская Qualys анонсировала сделку по покупке части активов американской Nevis Networks, связанные с анализом сетевого трафика и планируемые к интеграции в Qualys Cloud Platform. Сумма сделки не разглашается.

2 августа американская DigiCert анонсировала покупку за 950 миллионов долларов бизнеса Web Security / PKI у компании Symantec. С одной стороны Symantec хочет сконцентрироваться на своих других направлениях бизнеса, особенно после июльских покупок Fireglass и Scycure, а с другой после скандала с сертификатами для Google и последующим решением Google об отказе от сертификатов Symantec в Chrome, сертификатный бизнес Symantec пошел на убыль. 

Подробнее…

5 вещей, которые вы обязаны требовать от своих ИБ-поставщиков

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

1. Открытый API. Даже в такой консервативной области как промышленные сети сегодня нельзя встретить производителя, который бы по-прежнему держался за принцип "security through obscurity" и использовал проприетарные технологии и протоколы в своих решениях. Чего уж говорить о мире обычном, который гораздо обширнее, чем промышленные сети. Сегодня нет в мире поставщика, который был бы монополистом в области ИБ (как бы этого не хотелось) и который мог бы закрыть своими продуктами все потребности своих заказчиков. Кто-то специализируется на защите сетей, кто-то на защите облаков, кто-то на защите оконечных устройств. А заказчики используют все эти решения у себя и не хотят иметь дело с зоопарком. Мы в своем исследовании состояния ИБ в 2016-м году получили цифры, которые показаны на иллюстрации ниже - больше половины заказчиков используют от 6 до 50 различных поставщиков средств ИБ, а число заказчиков, использующих от 6 до 50 средств защиты еще выше, 65%. Это говорит только о том, что средства защиты должны иметь открытые API для взаимодействия либо между собой напрямую, либо через некоторые средства оркестрации или управления. Особенно это важно сейчас, когда в России стали появляться и собственные системы управления событиями безопасности, и отдельные заказчики строят на базе open source собственные решения по ИБ и хотят пользоваться теми возможностями, которые им предоставляют имеющиеся у них иные средства.
   
   
   
   
   
2. Поддержка современных практик ИТ. Ну тут, вроде, как и не требуются отдельные пояснения. Если заказчик внедрил виртуализацию или планирует уйти в облака, если его руководство требует себе мобильное устройство, а вся компания стремится в BYOD, то средство защиты должно поддерживать все эти инициативы. А иначе зачем нужны такие "вериги" на ногах ИТ, которые только мешают, а не способствуют бизнесу?
3. Поддержка адаптивных политик. Статика уходит в прошлое... Сигнатуры, жестко прописанные ACL, статические политики МСЭ вида "IP1 может получить доступ к IP2 по протоколу HTTP, а IP2 к IP1 - не может" уже не учитывают динамическую картину мира. Я эту заметку начинал писать в Питере на рабочем ноутбуке, продолжил в Интернет-кафе в отпуске, завершил на смартфоне во время поездки в метро, а отшлифовал уже дома на планшетнике. Чтобы описать эту картину в старой, статической парадигме, необходимо множество правил, которые должны быть размещены на всем протяжении моего движения от устройства, с которого я пишу, до блога. А промежуточных коммутаторов и маршрутизаторов, межсетевых экранов и точек беспроводного доступа может быть на пути несколько. А теперь перемножим это число на количество сотрудников в компании и получим колоссальное количество правил, которые надо поддерживать в актуальном состоянии. В замкнутой и неизменяемой среде это еще возможно, а вот в динамической, с постоянно путешествующими сотрудниками, использующими личные устройства, такая статическая схема уже не срабатывает. Нужна адаптивная или контекстно-ориентированная политика, отвечающая на вопросы - кто, что, куда, откуда, как, когда и зачем. Вот, например, как это сделано внутри самой Cisco. У нас, правда, масштаб немного иной, но все-таки. Статика уходит в небытие и вендора должны поддерживать динамически изменяемые политики.
4. Полный доступ к данным без штрафов. Вы знаете, сколько событий безопасности (записей в логах) хранят ваши средства защиты? Сто тысяч? Миллион? Миллиард? У нас внутри Cisco только сетевых событий ежедневно регистрируется 1,2 триллиона (!). Чьи это события? Вендора средства защиты/сетевого оборудования или ваши? Вероятно второе. А значит мы хотели бы иметь к ним доступ, чтобы, возможно, проанализировать их самостоятельно, без участия вендорв, собравшего нам исходные данные, на основании которых он принимает решения о тех или иных нарушениях политики ИБ. И доступ этот у нас должен быть полный, без ограничений, без запретов в дизассемблировании или иных нарушений всяческих законов об интеллектуальной собственности (речь в данном случае идет о данных, а не о самом коде ПО или железе). Отсюда требование, перекликающееся с первым, наличие доступа к полным логам и собранным данным, которые можно выгрузить или к которым можно получить доступ собственным средствам аналитики ИБ. Особенно в контексте повального увлечения в России разрабатывать собственные SIEMы.
5. Использование множества методов обнаружения. Это требование в условиях современного динамичного ландшафта угроз вполне логично и очевидно. Антивирус не должен бороться с вредоносным ПО только с помощью сигнатур, а IDS должна использовать еще и анализ аномалий. EDR должен уметь анализировать сетевые потоки данных, а также при необходимости интегрироваться с песочницами. Эффективное средство защиты сегодня оперирует не одним, пусть и хорошим, механизмом детектирования вредоносной активности, а сразу несколькими. Не сработал один, поймал второй. Не поймал второй, зафиксировал атаку третий. А иначе средства защиты превращаются в красивую и дорогостоящую игрушку, которую, чтобы крикнуть "Мама", еще надо ухитриться поместить в определенное и только такое положение.

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

Подробнее…

Одна из платформ Threat Intelligence внезапно прекращает свое сущестование

Год назад я поднимал вопрос о том, можно ли бороться с угрозами без собственного исследовательского центра, который бы мог самостоятельно писать сигнатуры/решающие правила/фиды/шаблоны аномалий для средств защиты, а также для SOC? Это тема схожа с той, к которой я обращался еще в 2003-м году, высказав предположение, что в России невозможно создать собственную систему обнаружения атак, которая определяется не столько движком (многие берут просто Snort), сколько базой решающих правил и способностью ее поддерживать. В первой из упомянутых заметок я описал два варианта для того, чтобы регулярно быть в курсе последних угроз и оснащать этим знанием свои решения - создавать собственную группу анализа и описания угроз или покупать уже имеющуюся на рынке информацию. В качестве рисков второго варианта я назвал только вариант с поглощением, когда поглощенный разработчик сигнатур или фидов больше не захочет поставлять их на рынок своим клиентам. Но вот на днях произошел случай, который хорошо укладывается в описанный мной риск, только немного с другой позиции.

Речь идет о компании Soltra, которая в декабре 2014-го года объявила совместно с корпорацией DTCC и финансовым центром обмена информацией об угрозах FS-ISAC (Soltra и есть совместное предприятие FS-ISAC и DTCC) о выпуске платформы для обмена информацией об угрозах (threat intelligence). Платформа Soltra Edge предоставлялясь бесплатно и за прошедшие 2 года была скачана свыше 11 тысяч раз 2900 компаниями в 77 странах мира. Soltra Edge собирала данные об угрозах из различных источников и конвертировала их в форматы STIX и TAXII, ставшие одним из стандартов де факто в области обмена данными о киберугрозах.

И вот 15-го ноября DTCC и FS-ISAC без предупреждения объявили о том, что решение Soltra Edge больше не будет развиваться, обновляться и, с 31 марта 2017 года, поддерживаться. В перспективе платформа Soltra Edge может перейти в разряд open source, но решение об этом пока не принято. Что делать клиентам Soltra непонятно, как непонятно и то, чем заменить платформу Soltra Edge и куда девать все полученные данные? Вот такие новости. Интересно, был ли у клиентов Soltra резервный вариант на такой случай и рассматривался ли он вообще?

Подробнее…

ДТП как зеркало отрасли информационной безопасности

Все как-то не было повода, а тут он сам собой и с неожиданной стороны проявился. Попал я ДТП с участием Камаза, двух автобусов и 5 легковых автомобилей. Авария была серьезная - лобовое столкновение Камаза с одним из автобусов, водителю которого пришлось ампутировать обе ноги. И пока я находился на месте ДТП, а было это в течение 6 часов, и наблюдал за всем происходящим мне в голову пришли две мысли, имеющие отношение к ИБ.



Сам не раз ловил себя на том, что любая авария, мимо которой проезжаешь, вызывает любопытство. А что, а как, а почему?.. Но со стороны все это обычно выглядит не так, как в ситуации, в которой ты сам один из главных героев. За 6 часов вокруг места аварии скопилось немало зевак, многие из которых тупо щелкали все происходящее на камеры своих смартфонов. Потом появилось несколько видеоблогеров, которые решили не просто поснимать аварию с тротуара, а пробраться к самим машинам, залезть в наполовину снесенную кабину Камаза и полностью смятую кабину автобуса. Потом подтянулась пресса - ТВ и радио. Особенно настырным был корреспондент РЕН-ТВ, который все пытался взять интервью у водителей пострадавших машин, которые были явно не расположены что-то комментировать.

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

Вторая мысль пришла уже позже, когда спустя 6 часов после аварии нас отпустили по домам. Кто бывал в ДТП, тот знает, что обычно оформление проходит быстрее. Если дело происходит в Москве, то каждая машина ГИБДД обычно оснащена принтером и подключением к Интернету. Это сильно ускоряет процедуру оформления - в последний мой раз на оформление паровозика из 4-х машин ушло всего 2 часа с момента ДТП и моим отъездом домой. И это при том, что ДТП произошло в 18 часов с небольшим, то есть в час пик, на загруженной Ленинградке. Но вернемся к последней аварии.

Дело было на Новокуркинском шоссе, которое разделяет Москву и Московскую область. Это привело к тому, что на место ДТП приехали и столичные наряды, и областные. Было 8 машин скорой помощи, машина ЦЭМПа (Центра экстренной медицинской помощи), 5 машин МЧС и пожарных, 6 машин ГИБДД и парочку личных БМВ, видимо, руководителей близлежащих подразделений МВД. 20+ машин!!! Неорганизованность полнейшая.

12 (!) пожарных фотографировали место происшествия - каждую столкнувшуюся машину с двух сторон. Двенадцать! Я потом спросил одного из них, зачем они это делали? Оказалось все просто - у них порядок такой. Каждый наряд должен сделать фотофиксацию места, на которое они выехали, для отчетности. Для гарантии, что фотографии получатся, в каждом наряде фотографируют 2-3 человека. Отсюда такое количество "фоторепортеров".

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

Вся эта бюрократия мне напомнила фрагмент из старого советского фильма "Огарева, 6":


И несмотря на 36 лет, прошедшие с момента выхода фильма о доблестной милиции, ситуация совсем не сдвинулась с мертвой точки. И надо признать, что в информационной безопасности, а точнее в расследовании инцидентов ИБ все точно также. Куча бумаг, неорганизованность, конкурирующие "смежники", нежелание брать на себя ответственность и... куча потерянного драгоценного времени. И это не пессимизм, а реалии, которые все глубже и глубже засасывают тех, кто сталкивается с государственными органами, которые требует уведомлять их об инцидентах ИБ. Пока это сделано для объектов ТЭК (постановлению №861 в октябре будет уже 3 года) и банков. Не за горами требование оповещать СОПКУ. А там может всплыть и тема уведомления об инцидентах с персданными граждан (она уже давно муссируется в кулуарах).

Вот такие вот мысли...

Подробнее…

Уязвимость или закладка? В чем разница?

На волне последних новостей о Shadow Broker и частично выложенным в открытый доступ, а частично выставленном на продажу наборе вредоносного ПО, мне хотелось бы вспомнить о терминологии. А то что-то внезапно и много развелось специалистов по закладкам. Особенно в среде специалистов по поиску уязвимостей. Причем некоторые подменяют понятия "уязвимость" и "закладка" непреднамеренно, а некоторые делают это осознанно, манипулируя терминами в своих интересах, зачастую коммерческих.

Итак, я приведу три определения (в разницу терминов defect, fault, failure, error и сленгового bug вдаваться не буду - они сейчас они имеют никакого значения):

1. Уязвимость - свойство информационной системы, обусловливающее возможность реализации угрозы безопасности обрабатываемой в ней информации (ГОСТ Р 50922-2006 "Защита информации. Основные термины и определения"). В ГОСТ Р 56545-2015 "Защита информации. Уязвимости информационных систем. Правила описания уязвимостей" определение немного другое. Там уязвимость - это недостаток (слабость) программного (программно-технического) средства или информационной системы в целом, который может быть использован для реализации угроз безопасности информации. В ГОСТ Р 56545 есть еще и определение zero day, но дела это не меняет. Иными словами речь идет об ошибке в ПО или ИС, которая может привести к угрозе ИБ. Возможность реализации угрозы и разделяет ошибки и уязвимости, которые в большинстве случаев являются подмножеством ошибок.
2. Программная закладка - это преднамеренно внесенный в программное обеспечение функциональный объект, который при определенных условиях инициирует реализацию недекларированных возможностей программного обеспечения. Это определение из ГОСТ Р 51275-2006 "Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения". Аналогичное определение и в более старом ГОСТ Р 50.1.053-2005 "Информационные технологии. Основные термины и определения в области технической защиты информации". В РД ФСТЭК по недекларированным возможностям определение схожее - "программные закладки – преднамеренно внесенные в ПО функциональные объекты (то есть элементы программы, осуществляющие выполнение действий по реализации законченного фрагмента алгоритма программы), которые при определенных условиях (входных данных) инициируют выполнение не описанных в документации функций ПО, приводящих к нарушению конфиденциальности, доступности или целостности обрабатываемой информации".
3. В свою очередь "недекларированные возможности" это, согласно ФСТЭК, функциональные возможности ПО, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации. Реализацией недекларированных возможностей, в частности, являются программные закладки.

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

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

ЗЫ. Кстати, Шнайер считает, что вторая часть архива Shadow Broker - это фейк, и цель была опубликовать именно первую с целью демонстрации своей мощи неизвестными хакерами, за которыми, по версии того же Шнайера, стоит... Кто бы вы думали? Да, опять Россия или, с меньшей вероятностью, Китай.

Подробнее…

И вновь об экономике и информационной безопасности: два мира, два взгляда

Утром, 17 мая, довелось мне‬ выступать на 10-й юбилейной сессии Высших курсов CIO. В прошлые года я рассказывал ИТ-директорам о том, почему у нас в России все так непросто с ИБ, откуда у нее торчат ноги и почему ибшникам сложно жить между молотом регуляторов и наковальней бизнеса. В этот раз меня попросили рассказать про то, как увязать требования регуляторов с требованиями бизнеса. За основу взял свою презентацию по финансовой эффективности ИБ с добавлением ряда новых слайдов на базе материалов Дмитрия Мананникова. И вот что интересно. Когда эту тему рассказываешь безопасникам - часто слышишь про то, что это шаманство и оно не работает и вообще все это фигня - оценивать ИБ рублем. Мол, продажа страха и compliance были, есть и будут основными и единственными драйверами ИБ. А вот в среде руководителей ИТ, которые уже сталкивались с темой измерения эффективности ИТ, эта тема находит живейшее понимание и отклик. Появляются вопросы, комментарии, как на самом мероприятии, так и после него. Видимо нужно время и набитые шишки, чтобы эта тема вошла в жизнь и простых ИБшников. И именно поэтому многие аналитики последнее время заводят разговор о том, что роль CISO скоро вымрет. Вымрет не сама задача ИБ, а ее текущее наполнение и отсутствие привязки к бизнесу-потребностям.

На высших курсах CIO мне выдали тестовый доступ к онлайн-системе kartoteka.ru, которая позволяет анализировать финансовую устойчивость компаний, аффилированность, учредителей и т.п. информацию. Раньше особо не интересовался данными вопросами по игрокам отечественного рынка ИБ. А тут дали доступ и я решил, а почему бы и не посмотреть, что в таких системах обычно есть. Залип :-) Столько нового узнаешь об игроках рынка :-) Неожиданные товарные знаки, которые никогда (возможно пока) не всплывали у того или иного игрока. Другие компании, учредителем которых являются известные всем люди. Причем, некоторые компании совсем неожиданные (не из области ИБ и даже близко не лежали). Бухгалтерские балансы. Госконтракты и госзакупки. Интересное чтиво; не ожидал.

В конце 2014-го года я выступал на BISA с прогнозами на ближайшее будущее, иллюстрируя это картинами Васи Ложкина. Тогда я сделал предположение (лежащее на поверхности), что некоторым игрокам ИБ будет становиться сложнее выживать на рынке. И вот доступ к kartoteka.ru этот очевидный вывод лишний раз подтвердил, что доказывает изменение структуры финансов у ряда игроков рынка.

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

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

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

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

 

Еще одной интересной возможностью системы является построение карты связей между юрлицами и физлицами - тоже интересно смотреть на эти хитросплетения. Есть даже кипрские оффшоры среди учредителей, причем у тех, о ком даже и не думал. Разговоры о том, что Лаборатория Касперского зарегистрирована в Лондоне идут давно и уже ни для кого не являются секретом. А вот о кипрских корнях компании <имярек> я и не задумывался даже.

В Cisco есть отдельная компания Cisco Capital, которая занимается финансированием различных проектов, в которых участвует наше оборудование, включая и решения по безопасности. Кредитование, лизинг, отсрочка платежа и так далее. Бывают случаи, когда Cisco Capital отказывает в финансировании даже несмотря на казалось бы хорошую репутацию компании, ее PR и другие внешние признаки. После использования kartoteka.ru начинаешь по-иному смотреть на эту тему и начинаешь понимать, почему наши финансисты отказывают и не хотят рисковать.

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

ЗЫ. Никогда не думал, что в России 100 с лишним Инфотексов :-) Причем львиная их доля относится к текстильной промышленности, а не к защите информации :-)

ЗЗЫ. На некоторые компании и людей теперь смотришь совсем по другому...

ЗЗЗЫ. Коллеги говорят, что СПАРК лучше :-)

Подробнее…

Список косяков #phdays

1. 

Подробнее…

Почему лицензирование технологий - это не всегда хорошо с точки зрения ИБ

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

Лицензирование технологий - это популярный метод у разработчиков тех или иных технологий ускорить выпуск своего продукта на рынок. Далеко не всегда есть время, а иногда и компетенции на разработку функционала, который уже кто-то реализовал и готов им поделиться. Самый банальный вариант - использование open source компонентов при создании собственных решений. Кто-то берет целый Hadoop для своих решений, кто-то ограничивается обычной библиотекой OpenSSL. Результат один - мы задействуем чужие технологии в своих продуктах и затем предлагаем их заказчикам, которые обычно не сильно задумываются о том, из чего состоит купленное ими изделие и какие риски они должны учитывать при выборе ИБ-решений (да и ИТ тоже).

Возьмем уже старый, но близкий мне пример. Компания Cisco лицензировала у компании netForensics одноименную систему управления событиями безопасности, которую затем стала предлагать под новым именем Cisco SIMS (Security Information Management System). Мы ее некоторое время успешно продавали через свой канал продаж, но потом столкнулись с тем, что у компании netForensics сильно ухудшилась внутренняя ситуация - качество продукта снизилось, поддержка стала работать из рук вон плохо, число нареканий от заказчиков стало возрастать. А повлиять на чужой продукт мы были не в состоянии. Итог закономерен - мы прекратили сотрудничество с netForensics (с 2012-го года они переименовались в BlackStratus), а Cisco SIMS исчез из нашего прайс-листа. И для нас и для заказчиков риски были минимизированы, но ситуация все равно неприятная.

Другой пример - тоже с нами. В свое время мы лицензировали у компании Opsware систему Network Compliance Manager, этакий автоматизированный аудитор сети, который сканировал сетевое оборудование и средства защиты в поисках несоответствующих требованиям внутренних политик и внешних стандартов конфигураций. Продукт некоторое время существовал в нашем прайс-листе, но после покупки Opsware компанией HP мы вынуждены были свернуть сотрудничество. Эти риски тоже были минимизированы, так как у нас еще до заключения договоров по лицензированию технологий прорабатываются вопросы, как мы и наши заказчики будем из этих договоров выходить с минимальными потерями.

А теперь обратимся к отечественному рынку ИБ и посмотрим на сотрудничество “Код безопасности” с компанией Agnitum, которая лицензировала свои технологии и разрешила “Коду безопасности” встроить свой движок по борьбе с вредоносным кодом в Secret Net Studio. А потом компания Agnitum была куплена Яндексом, который не пожелал (и это его право) продолжать ранее заключенные договора лицензирования технологий Agnitum. Итог - “Код безопасности” потерял часть своего функционала и вынужден был в спешном режиме искать альтернативу, с которой все непросто. Антивирусный движок остался только один - зарубежный Nod32 от ESET, который не будет сертифицироваться в ФСБ и по высоким классам ФСТЭК. Модуль HIPS оказался потерян полностью и сейчас "Код безопасности" пытается написать его самостоятельно (что делать текущим пользователям - не совсем понятно).

Ситуация с “Кодом безопасности”, Agnutum и Яндекс не уникальна для российского рынка. Сейчас многие российские компании идут по пути лицензирования чужих (и не всегда российских) технологий. Кто-то WAF лицензирует, кто-то SIEM (например, OSSIM или ArcSight), кто-то антивирус (тот же Nod32), кто-то анализатор кода (например, Fortify), кто-то системы контроля доступа (какой-нибудь SSH Security Communications), кто-то системы управления идентификацией (например, Identity Manager). И дело тут не в отсутствии компетенций по разработке аналогичных решений. Просто в условиях, когда страна декларирует курс на импортозапрещение, зарабатывать на западных решениях становится сложнее, а ниша, в которую могут потечь денежные потоки, не уменьшается. Логично что у ряда разработчиков возникает идея по-быстренькому сваять “российский” продукт на базе уже имеющихся технологий (западных или отечественных). Я уже как-то писал про то, что это не совсем импортозамещение, но сейчас мне хотелось рассмотреть эту проблему под другим углом зрения.

Что будет, если разработчик приобретаемой технологии “загнется” или будет куплен более крупным игроком, который не захочет развивать это направление своей деятельности? Что будет делать производитель, использующий чужие технологии? А что будет делать потребитель? Вот возьмем, к примеру, Attack Killer от Infowatch. Продукт, который базируется на решениях четырех разных компаний - Infowatch Appercut, Infowatch Targeted Attack Detector (решение от Cezurity), Wallarm WAF и Qrator AntiDDoS. Когда в Интернет утек черновик этой статьи, Рустем Хайретдинов накидал мне еще фактов про Attack Killer, поэтому просто процитирую его: "На самом деле всё гораздо хуже - внутри Апперката есть SQLite, а внутри Валларма - ngnix. InfoWatch Traffic Monitor содержит десятки лицензируемых компонентов - СУБД Oracle или PostgreSQL на выбор, голосовые перехватчики от ЦРТ, OCR от ABBY, а скоро ещё и КППС, и т.п. Апперкату ещё сложнее - он пишется на Java, который принадлежит Oracle, который грозится запретить его лицензирование." Допустим, Wallarm, активно смотрящий на Запад, будет там куплен каким-нибудь IBM, Dell или Cisco, не имеющих в своем портфолио Web Application Firewall. Или Oracle все-таки запретит лицензирование Java Как это скажется на Attack Killer? Рустем пишет, что этот риск проработан на уровне договоров и там где это возможно, существуют резервные/дублирующие технологии. Тот же Oracle может быть заменен на PostgreSQL. В любом случае это тот риск, который стоит рассматривать до приобретения решения, а не после.

Но это не единственный риск лицензируемых технологий. Другой вопрос заключается в устранении уязвимостей в них. Тут впору вспомнить историю с уязвимостью Heartbleed в библиотеке OpenSSL, на базе которой построено немалое количество продуктов в мире, включая и российские. Среди них были и сертифицированные по требованиям ФСТЭК решения. И когда ФСТЭК обратилась к их разработчикам с просьбой сообщить об устранении серьезной дыры в сертифицированных решениях часть разработчиков ответила, что не имеет возможности Heartbleed устранить, так как у них нет компетенций в этой области, а код чужой и копаться в нем они тоже не умеют. История умалчивает, что стало с сертификатами на эти решения, но умалять от этого проблему не стоит. Если продавец не может устранить уязвимость в применяемых чужих open source компонентах (OpenSSL, Kibana, Elasticsearch, Hadoop, OSSIM, Snort и т.п.), то как это скажется на безопасности потребителя? Это второй из возможных рисков, о котором стоит, как минимум, помнить.

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

Подробнее…

Облачная ИБ, российские требования по локализации и точка бифуркации

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

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

Пример инфраструктуры обновления информации об угрозах у одного из мировых средств защиты

А отправка файлов для анализа их вредоносности? Она тоже идет с использованием облаков. А проверка хешей файлов или репутации сайтов? Опять через облака. А как мобильные пользователи используют защищенное подключение к Интернет? Снова облака. Да тот же VPN-as-s-Service или DDoS-as-a-Service - это тоже облако, имеющее свои точки присутствия в разных точках Земли и в разных часовых поясах. Ключевой признак такой "облачности" - распределенность. Именно в ней заключается преимущество многих современных технологий ИБ. Нет единой точки отказа, повышение надежности, рост скорости обработки, снижение задержек, учет часовых поясов... Если провести блиц-анализ рынка ИБ, то мы увидим, что точка бифуркации в этом вопросе уже давно пройдена и представить на современном этапе развития технологий ИБ чисто локальные решения уже невозможно.

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

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

Как влияют требования по локализации на средства ИБ (сравните с картинкой выше)

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

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

Распределенность в масштабах России

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

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

Эта проблема никак не связана с санкциями и запретом со стороны иностранных государств. Она никак не связана с выпуском продуктов на территории России (локальным производством). Она никак не связана с раскрытием исходных кодов и сертификацией на отсутствие НДВ. Просто в России отсутствует нормальный Интернет и достаточное количество адекватной инфраструктуры ЦОДов для работы таких площадок и многие зарубежные компании не готовы (возможно пока не готовы) менять существующие годами процессы обновления своих средств защиты. И если запустить ЦОД по предоставлению услуг фильтрации или VPN-as-a-Service на территории России еще можно теоретически (хотя требования СОРМ и последние инициативы депутатов по хранению всех передаваемых данных в течение трех лет в интересах правоохранительных органов не добавляют оптимизма), то с серверами обновления решающих правил ситуация не столь "простая".

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

Подробнее…

О сертификации средств защиты, уязвимостях и отзыве сертификатов

Спустя месяц после назначения в Juniper нового главного безопасника (Security CTO), этот производитель объявил об обнаружении в коде своей операционной системы ScreenOS неавторизованного фрагмента, который позволял злоумышленнику получать административный доступ к средствам сетевой безопасности NetScreen, а также расшифровывать VPN-трафик. В российском Twitter разгорелся некоторый флейм на эту тему, который можно кратко описать несколькими тезисами:

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

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

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

Можно спорить, насколько это правильно или нет, но ФСТЭК работает именно так. А если подумать, то такой подход вполне логичен, так как обнаружить все уязвимости при сертификации невозможно и защищенность продукта характеризуется не числом дыр в нем, а умением производителя устранять их, наличием выстроенного процесса. К сожалению, процесс устранения уязвимостей в продуктах ФСТЭК не оценивает. Да и непонятно вообще как это делать, по каким критериям? Ответом мог бы послужить метод V-RATE, разработанный в институте Карнеги-Меллона еще в конце 90-х годов (я про него писал уже ровно 4 года назад), но за пределами США он как-то не очень распространился; да и не об этом сейчас.

Отсюда, кстати, вытекает и банальная мысль, что если функционал NetScreen соответствует РД на межсетевые экраны, то сертификат продолжает действовать и отозвать его не так просто, как заявляют не очень компетентные в этом вопросе люди. В 199-м приказе Гостехкомиссии всего 5 оснований для отзыва сертификата и наличие уязвимости в сертифицированном продукте к ним не относится. Поэтому в России почти и нет случаев отзыва сертификатов на средства защиты.

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

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

Если же вновь вернуться к ситуации с недокументированными возможностями в Juniper, то стоит обратить внимание, что речь идет о VPN-функциональности, которая по российскому законодательству к ФСТЭК никакого отношения не имеет вовсе. Когда-то ФСТЭК пыталась войти в эту реку и даже проекты РД на VPN разработала, но смежники из 8-го Центра ФСБ замкнули все вопросы с VPN все-таки на себя. Поэтому ФСТЭК при сертификации средств защиты с криптографическими подсистемами в них не лезет... а в ФСБ NetScreen не подавался и подаваться не мог в принципе, так как согласно 608-му Постановлению Правительства по обязательной сертификации средств защиты информации, шифровальные средства должны использовать только рекомендованные в ФСБ криптоалгоритмы, а это ГОСТ. Поэтому закладка в Juniper могла и дальше оставаться незамеченной, находясь вне зоны ответственности ФСТЭК и ФСБ.

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

Вот как-то так...

Подробнее…

Информационная безопасность и фактор времени

На прошедшем в Казани "Коде информационной безопасности", когда я рассказывал про тренды угроз ИБ, возникла дискуссия с участием представителей Microsoft и Dr.Web о борьбе с криптолокерами в частности, и с угрозами вообще. В том числе прозвучала фраза о том, что антивирусные компании обновляют свои средства защиты 2-3 раза в день. Меня удивила такая "оперативность"; мы заявляем для своих средств защиты частоту обновления - 1 раз в 3-5 минут и даже в этом случае я не могу сказать, что мы гарантируем 100%-е обнаружение вредоносного кода.

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



Сама презентация выложена на Slideshare:

Информационная безопасность и фактор времени from Aleksey Lukatskiy

Подробнее…