23.08.2017

Маскировка киберпреступников под личиной партнеров ИБ/ИТ-вендоров

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

Есть гораздо более вероятные сценарии. Например, на днях прошла новость о якобы обнаруженной новой угрозе, которую уже успели окрестить емким термином "Chip-in-the-Middle" ("чип посередине"), суть которой заключается в установке в мобильные устройства чипов (например, во время ремонта) с вредоносной функциональностью. На самом деле это угроза не нова и вполне предсказуема при правильном моделировании угроз в управлении цепочками поставок. Вот хорошая иллюстрация из презентации, которую я делал еще 3 года назад.


В ней описанный сценарий "chip-in-the-middle" описан наряду с другими точками приложения сил злоумышленниками. В сегодняшней заметке я бы хотел коснуться немного другого участка цепочки поставок, о котором многие специалисты по ИБ не думают, но именно через него возможно нанесение ущерба для предприятия. Речь пойдет о процессе, который на иллюстраии отмечен словом "партнеры". Да-да, именно те компании, которые и поставляют львиную долю всех ИБ-решений потребителям, и являются одной из угроз.

Реализуется эта угроза достаточно просто - злоумышленнику нужно проделать всего несколько шагов:

  1. Зарегистрироваться в качестве партнера у интересующего производителя решений по ИБ (на самом деле это касается не только ИБ-производителей, но и любого поставщика, например, ИТ). Выдавать себя лучше за регионального партнера - их проверяют (если вообще проверяют) не очень пристально.
  2. Податься на конкурс по поставке средств защиты, организованному предприятием-жертвой.
  3. Установить минимальную цену своего предложения (можно ничего не заработать, а можно даже и в минус уйти). Нередко (а у госорганов в соответствие с 44-ФЗ так почти всегда) основным критерием выбора продукта является цена (что вызывает неудовольство разных сторон, и продавцов, и покупателей) - кто дешевле, тот и выиграл.
  4. Выиграть конкурс, который, по тому же 44-ФЗ, практически невозможно отменить.
  5. Получить у производителя оборудование или ПО (нередко, для отчетности в бухгалтерии, ПО скачивается не с сайта, а поставляется на CD/флешке).
  6. Внедрить закладку в оборудование или ПО. Понятно, что в зависимости от железа или софта это может потребовать определенной квалификации, но невозможным я бы это не назвал.
  7. Осуществить поставку оборудования или ПО заказчику.
  8. Бинго!

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

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

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

  • Внедрение SDLC (также и применительно к железу) на стороне производителя. Тема SDLC непроста - немногие производители, особенно небольшие, особенно в России, реализуют у себя цикл безопасной разработки. Крупные игроки тоже не всегда могут похвастаться идеально выстроенными процессами. Могу привести пример нашей компании - мы в Cisco реализовывали все поэтапно (вот тут презентация и видео с конференции ФСТЭК, где про это рассказано более подробно) и контроль целостности на уровне софта (при загрузке и в процессе исполнения) и на уровне железа у нас появился по меркам компании относительно недавно.


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


  • Использование третьей стороны, которая возьмем на себя оценку целостности поставленных решений. Частным случаем такого пути решения проблемы является сертификация на отсутствие недекларированных возможностей и проведение соответствующего тестирования (с упором на поиск именно постороннего вмешательства, а не уязвимостей, которые являются результатом деятельности разработчиков).
  • Мониторинг активности. Это традиционная деятельность любой службы ИБ или ИТ, но в контексте заметки привычные системы класса NTA (Network Traffic Analysis), EDR (Endpoint Detection & Response), UEBA (User Entity Behavior Analytics), NFT (Network Forensics Tool) и т.п. должны включать в область своего контроля еще и средства защиты (что бывает нечасто) и иные "доверенные" устройства и решения. Это не так сложно и не требует больших усилий (если технологии мониторинга аномалий на уровне софта и железа, сетевом и прикладном в компании есть) - просто надо признать такую угрозу актуальной.
ЗЫ. Когда уже заканчивал заметку пришло в голову, что в проекте методики моделирования угроз ФСТЭК, этот тип нарушителя впрямую не указан, как и сама угроза. Хотя направление размышлений задано в проекте верно.


21.08.2017

Не верь глазам своим или всегда проверяйте резюме своих кандидатов

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

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


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


 Все бы ничего, но в качестве последнего места работы у этого кандидата было написано вот что:


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

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


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

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

ЗЫ. Имен не будет (ни тут, ни в личке).

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

09.08.2017

Закон по БКИИ. Терминологический тупик

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

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

В Стратегии говорится, что "объекты критической информационной инфраструктуры - информационные системы и информационно-телекоммуникационные сети государственных органов, а также информационные системы, информационно-телекоммуникационные сети и автоматизированные системы управления технологическими процессами, функционирующие в оборонной промышленности, в сфере здравоохранения, транспорта, связи, в кредитно-финансовой сфере, энергетике, топливной, атомной, ракетно-космической, горнодобывающей, металлургической и химической промышленности". То есть, объект КИИ - это не то, что влияет на обороноспособность и безопасность страны, а то, что находится в определенных секторах экономики. Например, POS-терминал, стоящий в кассе столовой любого госоргана :-) Вместо того, чтобы отталкиваться от назначения инфраструктуры (системы), авторы (из 8-го Центра ФСБ) решили зачем-то оттолкнуться от отраслевой привязки. Соответственно, КИИ у нас могут быть, согласно Стратегии, только в 13 отраслях, перечисленных в определении выше. Я уже писал раньше, что мне совсем непонятна причина, по которой тоже водоснабжение или телерадиовещании выпали из контроля. То ли лобби у них сильное, то ли по ошибке их забыли включить, то ли авторы посчитали, что указанное определение покрывает и их тоже. Но увы, нет.

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


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

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


К чему это привело (а точнее приведет)? К тому, что будет полная *опа с категорированием. Если в идеальной ситуации (с сохранением причино-следственной связи) можно было бы сослаться на существующие методики категорирования критически важных объектов и плясать от них (а они, несмотря на их разнообразие, вполне могули бы стать точкой отсчета), то сейчас, увы, придется создавать новую методику категорирования именно объектов КИИ и прописывать в них показатели категорирования исходя из соответствующих критериев - социальной, политической, экономической, экологической и иной значимости. А это значит, что какая-нибудь гидроэлектростанция будет классифицироваться по требованиям МинЭнерго, как объект ТЭК, по требованиям к антитеррористической защищенности, по требованиям МЧС, и еще по требованиям к КИИ. Владельцы таких объектов будут только "рады"; особенно когда поймут, что эти методики используют разные подходы и результаты отнесения к категориям могут не совпадать.

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

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

ЗЫ. Кстати, еще один интересный момент. Субъектом КИИ является только та организация, которой принадлежит на законном основании (праве собственности или аренды) информационная система или АСУ. А если у организации нет в собственности таких систем и они используются на условиях аутсорсинга?..

08.08.2017

"Код ИБ. ПРОФИ": краткие впечатления

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


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


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


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


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


К сожалению, у нас "отвалился" один из докладчиков, который должен был читать мастер-класс по внутреннему маркетингу ИБ. Эту тему мы плавно интегрировали в мастер-класс по культуре ИБ и повышению осведомленности, а освободившийся тайм-слот я закрыл своим могучим "мозгом", оперативно подготовив презентацию с обзором основных технологических трендов в ИБ, на которые стоит обратить внимание руководителям служб ИБ. Тут были и EDR, и CASB, и NTA, и UEBA, и системы симуляции атак, и обманные системы, и программно определяемая сегментация и т.п. В течении полутора часов попробовал рассказать о том, что из себя представляют все эти новомодные продуктовые аббревиатуры и на что обращать внимание при их выборе.


Презентации выкладывать не могу по условиям мероприятия, но доступ к ним возможен для тех, кто готов это оплатить. В стоимость такого доступа входят не только все 11 презентаций, но и видео всех докладов. Это, конечно, не заменит культурной программы, вечерних прогулок вдоль набережной и дебатов экспертов, но, как минимум, сможет прикоснуться к деловой программе и почувствовать себя участником "Код ИБ. ПРОФИ". 

04.08.2017

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 пошел на убыль. 

25.07.2017

Текущий статус законодательства по безопасности критической инфраструктуры

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



20.07.2017

Security Foresight: темная сторона искусственного интеллекта

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


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

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

Вот представьте сценарий. Депутат Госдумы является скрытым педофилом, который зарегистрировался на нелегальном форуме с детской порнографией под вымышленным псевдонимом и с зарубежного почтового сервиса. При этом, по глупости, этот же псевдоним он использовал как часть своего e-mail для личного почтового ящика на mail.ru. А на эту почту он же пересылал несколько сообщений со своей служебной почты в домене gov.ru. Вполне реалистичный сценарий, в котором только технологии ИИ могут сопостовить множество источников данных и сделать гипотезы о совпадении этих трех виртуальных личностей. ну а дальше можно только предугадывать, что могут преступники (а может спецслужбы?) сделать с такой информацией.

А теперь вспомним про конкурс Cyber Grand Challenge, проведенный Агентством по передовым оборонным исследованиям МинОбороны США DARPA. В его рамках семь команд использовали автономных агентов для обнаружения, анализа и исправления уязвимостей до того, как их найдут противники. При этом поощрялось обнаружение уязвимостей в коде своих оппонентов по конкурсу. Целью конкурса была демонстрация технологий искусственного интеллекта для целей кибербезопасности, но... DARPA занимается не только оборонными исследованиями. У них есть и атакующий потенциал. Что, если технологии автоматизации поиска и использования дыр в ПО будет применяться киберпреступниками (или спецслужбами)? Незря Элон Маск сравнил проект DARPA с Skynet из "Терминатора".


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

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

ЗЫ. Бывший глава национальной разведки США в конце прошлого года предупредил Конгресс об опасности искусственного интеллекта, который может быть использован киберпреступниками. 

19.07.2017

Security Foresight: стеганография

Довелось мне тут поучаствовать в одном проекте Cyber Security Foresight (по прогнозированию того, что будет в/с ИБ через несколько лет). Теперь буду по мере возможности выкладывать краткие зарисовки с этого проекта - там есть интересные мысли и выводы, о которых нечасто задумываешься в рамках ежедневной рутины. Понятно, что предсказывать будущее у нас еще не научились, но опираясь на знание прошлого и понимание настоящего можно попробовать спрогнозировать будущее (и оно будет не одно). Это и называется foresight, а в контексте нашей индустрии - cyber security foresight.


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

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

Второй сценарий заключается в применении стеганографии разработчиками вредоносного кода. Первый пример такого использования был зафиксирован в случае с Duqu в 2011-м году. Этот вредонос шифровал данные и скрывал их внутри графических файлов JPEG, позже отправляемых на сервер управления. В 2014-м году аналогичная техника использовалась в банковском трояне Zeus. Потом были Zbot, Stegoloader, Shady RAT, DNSChanger, Sundown, Cerber, TeslaCrypt и другие. Детектировать такие вещи непросто и проникновение вирусов и утечки данных через них могут долго оставаться незамеченными специалистами служб ИБ.

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

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

ЗЗЫ. Кстати, сами спецслужбы активно используют стеганографию для сокрытия своих коммуникаций. Например, в 2010-м году ФБР обвинило Службу внешней разведки (СВР) в использовании стеганографии в разведывательной деятельности.

18.07.2017

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 должен уметь анализировать сетевые потоки данных, а также при необходимости интегрироваться с песочницами. Эффективное средство защиты сегодня оперирует не одним, пусть и хорошим, механизмом детектирования вредоносной активности, а сразу несколькими. Не сработал один, поймал второй. Не поймал второй, зафиксировал атаку третий. А иначе средства защиты превращаются в красивую и дорогостоящую игрушку, которую, чтобы крикнуть "Мама", еще надо ухитриться поместить в определенное и только такое положение.
Понятно, что эта пятерка - не догма, а руководство к действию, как писал Фридрих Энгельс в позапрошлом столетии. Но выглядит она достаточно здраво и ее стоит взять на вооружение при общении со своими поставщиками средств защиты информации. Лишними эти требования уж точно не будут.

17.07.2017

Шквал информации об угрозах затрудняет работу с множеством источников Threat Intelligence

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


Некоторая доля из этих тысяч непрочитанных писем составляли различные сообщения от компаний, участвовавших в RSAC и Gartnet Security & Risk Management Summit, которые шлют мне всякую рекламу, приглашения на вебинары, ссылки на их white paper и приглашения поговорить со мной по телефону в целях заинтересовать меня их продуктами. Но я их не удаляю, а пробегаю глазами все, что приходит, - это хорошо позволяет погрузиться в то, чем живет американский рынок и понять тенденции (даже если они и оцениваются по спаму).

Но немалая доля непрочитанной, ежедневно сыплящейся корреспонденции составляют различные бюллютени Threat Intelligence из различных источников - IT-ISAC, DHS, FBI, ThreatStream, Record Future, MS-ISAC, FS-ISAC, NCCIC и других. И это просто какой-то колоссальный поток информации, которую нужно пробежать глазами, чтобы получить общее представление о происходящем по ту сторону баррикад. Ниже покажу только некоторые примеры:










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


Под таким валом информации несложно и загнуться, а то и пропустить что-то важное (если бы я был аналитиком Threat Intelligence или работал бы в каком-либо SOC на постоянной основе, а не время от времени). Отсюда практический совет, который я даю последнее время в своих презентациях (тут впервые, потом тут и тут), - используйте платформу для TI, которая вам будет и давать высокоуровневый, стратегический взгляд на угрозы (кампании, участники, угрозы, инциденты и т.п.), и аккумулировать низкоуровневые, тактические индикаторы компрометации. Причем скорее всего это будет не одна платформа.


 Главное, чтобы не вручную, а то будете иметь такие же почтовые ящики как мой :-)

14.07.2017

Symantec покупает Skycure

Не прошло и недели, как Symantec объявила о приобретении израильской компании Skycure, занимающейся борьбой с угрозами для мобильных устройств. Размер сделки не сообщается.

Коллапс в аэропорту как отражение ситуации с ИБ во многих компаниях

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

Событие №2 случилось также вчера. Компания Аэрофлот объявила об отмене и задержках нескольких своих рейсов. Объявила заранее, разместив уведомление на сайте, а также обзвоним пассажиров по телефону или направив им SMS. В последнем случае сообщения выглядят примерно вот таким образом (это мне такая SMS приходила 3 года назад):


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

Ну и, наконец, третий кейс, который случился 1-го июля с авиакомпанией S7 в Домодедово. За день, 30 июня в Москве случился серьезный ливень, и многие рейсы, которые должны были прилететь в Москву туда не прилетели, что привело к коллапсу на следующий день - самолетов просто не хватило, чтобы улететь всем по оплаченным маршрутам. По словам друзей и коллег, столкнувшихся с этой ситуацией, авиакомпания не предприняла никаких действий для того, чтобы разрулить проблемы. Не было ни уведомлений пассажиров, ни нормального питания, пассажиров гоняли по разным людям, якобы принимающим решения, и т.п. В итоге у многих был сорван отпуск, командировки и встречи, понесены дополнительные затраты на замену авиакомпаний или переключение на ж/д транспорт, а также невосполнимые потери по потере времени, которое можно было бы провести в уже оплаченном отеле.

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

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

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

Дабы заметка не выглядела как реклама "Аэрофлота" :-) могу рассказать кейс, когда эта авиакомпания отработала не самым лучшим образом. В прошлом году вылетал из Нижнего Новгорода с "Кода ИБ". Рейс был предпоследний и его по техническим причинам отменили; хотя нас уже посадили в самолет и даже вырулили на ВПП. Выйдя из самолете многие кинулись менять билеты на последний рейс, но цена на эконом оказалось совсем не экономной - 60 тысяч рублей (из Нижнего в Москву, где лета минут 50). Работника "Аэрофлота" на месте уже тоже не оказалось, так как у него закончился рабочий день и он свалил домой. По громкой связи всем объявили, что рейс переносится на 10 утра. В адрес авиакомпании было сказано много добрых слов от пассажиров.

Моя попытка уехать поездом тоже не увенчалась успехом - ночных "Сапсанов" из Нижнего нет, а ехать обычным поездом 7-8 часов никакого желания не было - приезжаешь почти в то же время, что и перенесенный рейс. Я был очень раздасадован, так как в 8 утра у меня уже была запланирована в Москве встреча и я на нее никак не попадал - все варианты разрулить проблему я перепробовал. Но итог оказался вполне успешным - я из Нижнего в Москву... уехал на такси. В вечернее время это заняло всего 4,5 часа, а цену я разделили с еще двумя пассажирами, которым тоже нужно было в столицу. Вот такое нестандартное реагирование, о котором я и не думал изначально, так как в голову прийти заменить самолет обычным такси мне мысль не приходила :-) То есть реагирование может быть иногда и спонтанным, но все-таки лучше, если все варианты прорабатываются заранее.

13.07.2017

Становление финансовой корпорации "Сайберкрайм и сыновья"

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

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

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


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

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

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


11.07.2017

Как разные мировые и отечественные регуляторы отреагировали на WannaCry и Petya/Nyetya

Обновлял тут презентацию по построению национального центра мониторинга кибербезопасности и решил проанализировать, как регуляторы разных стран отреагировали на последние эпидемии WannaCry и Petya/Nyetya.


Традиционно американцы считаются законодателями мод в области кибербезопасности (хотя их, по их же словам, русские и китайские хакеры ломают в хвост и гриву). Как же отреагировали множественные американские государственные и отраслевые регуляторы, имеющие отношение к информационной безопасности? Получается такая картина:
  • US-CERT - 12 мая появился полноценный бюллетень с описанием WannaCry, индикаторами компрометации, правилами YARA и т.п. Потом бюллетень многократно обновлялся. Про Petya американский государственный CERT отписался 1-го июля.
  • ICS-CERT - 15 мая был опубликован бюллетень, посвященный обзору WannaCry применительно к промышленным системам. Про Petya ICS-CERT опубликовал бюллетень 30 июня, на день раньше US-CERT.
  • NCCIC про WannyCry выпустил обзор 2 июня.
  • ФБР - 13 мая опубликован бюллетень с индикаторами компрометации для WannaCry, а 3 июля для Petya.
  • SEC (Комиссия по ценным бумагам) выпустила бюллютень про WannaCry 17 мая.
  • FTC отметилась 15 мая заметкой про WannaCry в своем блоге; про Petya - молчок.
  • АНБ публично выпустило бюллютень про WannaCry в первый рабочий день после начала эпидемии, 15 мая. Про Petya их бюллетеней не нашел.
  • DHS опубликовал пресс-релиз про WannaCry в день начала эпидемии, 12 мая, а про Petya - 28 июня.
  • FCC (Федеральная коммуникационная комиссия, аналог нашего Минкомсвязи) никак не отреагировала на WannaCry и Petya.
  • FINRA никак не отреагировала на атаки шифровальщиков.
  • ABA (Ассоциация американских банков) распространила среди своих членов бюллетень о Petya 5 июля, а о WannaCry - 15 мая.
  • Различные ISAC (Innformation Sharing and Analysis Center) также распространили соответствующие уведомления о WannaCry и Petya/Nyetya (я получил анонсы от FS-ISAC, MS-ISAC, IT-ISAC).

В Старом Свете ситуация с уведомлениями была схожей - кто-то оперативно и публично уведомил пользователей, а кто-то промолчал и молчит до сих пор (возможно, делая рассылки по закрытым спискам или публикуя уведомления на закрытых порталах):
  • Английский NCSC 13 мая отделался общими фразами о существовании WannaCry, но уже 14 мая выпустил два руководства по отражению WannaCry для домашних пользователей и малого бизнеса, а также для корпоративных заказчиков. Про Petya NCSC до сих пор ничего не написал, кроме упоминания в еженедельном обзоре событий безопасности.
  • CPNI, занимающийся в Великобритании защитой критической инфраструктуры, публично никак не отреагировал на эпидемии шифровальщиков.
  • Европейское агентство по ИБ ENISA отчиталось о WannaCry подробным отчетом 15 мая, а по Petya никакой информации нет до сих пор.
  • Европейский CERT-EU выпустил первую версию бюллетеня по WannaCry в день начала эпидемии - 12 мая, а по Petya - 28 июня.
Отечественные регуляторы оказались не хуже, а местами и лучше импортных. ГосСОПКА отчиталась по WannaCry в тот же день (по словам очевидцев - сам не видел их уведомления). По Petya  ГосСОПКА разослала уведомление 27-го июня (я первоначально искал новости на gov-cert.ru, но там ничего нет и цель этого сайта мне не совсем понятна). МВД молчит до сих пор, а ФСТЭК объединила WannaCry и Petya в своем информационном сообщении от 2-го июля. ЦБ разместил у себя на сайте краткие анонсы по WannaCry 19 мая, а по Petya - 28 июня (с указанием, что детальные уведомления были разосланы в день начала эпидемий всем подключившимся к информационному обмену с FinCERT). Другие регуляторы (МинЭнерго, Минкомсвязь, МЧС и другие) никак не отреагировали на глобальные киберугрозы, которые затронули многие российские компании, включая и критические инфраструктуры.

Уведомление ГосСОПКИ мне понравилось. Тут и индикаторы компрометации, и YARA-правила (от Касперского), и сигнатуры Snort (если не ошибаюсь, от Positive Technologies). А еще ГосСОПКА не чурается использовать международно признанные стандарты в области Threat Intelligence - YARA, TLP, хеши по SHA1/SHA256/MD5 (это вообще забавно, когда ГосСОПКА, созданная 8-м Центром ФСБ, активно насаждающем российские криптоалгоритмы, в своей работе использует алгоритмы западные, а точнее американские :-). Постепенно вырисовывается то, что осталось за рамками методических рекомендаций по созданию центров ГосСОПКИ, о чем я писал ранее.

Выводов из этой картины я бы мог сделать несколько:
  1. В России не хватает национальных CERTов, которые бы эффективно могли отрабатывать такие глобальные эпидемии и оперативно делиться со всеми (а не в рамках закрытого информационного обмена как у ГосСОПКА или FinCERT) информацией об индикаторах компрометации и способах нейтрализации угроз. С частными CERTами ситуация неочевидная - GIB-CERT вообще ничего на своем сайте не публикует (возможно рассылая информацию по платной подписке), а вот Лаборатория Касперского через свой промышленный ICS-CERT опубликовала отчет по WannaCry 14 мая.
  2. Регуляторы, устанавливающие требования по ИБ, практически никогда оперативно не выпускают уведомления о глобальных угрозах, запаздывая на несколько дней, а то и недель. Более того, они никогда (почему-то) не ссылаются на разработанные ими же документы, требования и рекомендации. То есть получается, что "бумажные требования" живут своей жизнью, имеющей мало общего с реальностью, а конкретные рекомендации даются без какой-либо привязки к ранее разработанным документам (и зачем они тогда нужны). В России исключением стала только ФСТЭК, которая в своем информационном сообщении сослалась на свои приказы с требованиями по защите.
  3. В России регуляторы по-прежнему не умеют коммуницировать с целевой аудиторией по вопросам ИБ. Я как-то про это уже писал и вижу, что ситуация с мертвой точки за это время так и не сдвинулась. А ведь и WannaCry и Petya/Nyetya могли стать отличными инфоповодами для регуляторов, которые могли бы обратить внимание аудиторию на существующие проблемы в ИБ и способы их решения; да и про собственный PR не забыть. Хотя про PR некоторые из них иногда помнят, а про помощь своим подопечным нет... :-(
  4. В России по-прежнему любят секретить все, что только можно. Закрытые рассылки, закрытые порталы, закрытые мероприятия, включая, онлайн... И ситуация лучше не становится. Тот же законопроект по безопасности критической инфраструктуры, принятый во втором чтении, в котором так и осталась норма об отнесении информации о мерах защиты и состоянии защищенности критических инфраструктур к гостайне. И зачем так закручивать гайки?

10.07.2017

Symantec покупает Fireglass

6 июля Symantec объявил о намерении купить израильскую Fireglass, известную своей технологией изоляции вредоносного кода и фишинговых угроз при посещении Web-сайтов. Условия сделки не раскрываются.

О реакции ФСТЭК на Petya и WannaCry

2-го июля ФСТЭК выпустила информационное сообщение про вредоносные программы Petya и WannaCry и способы борьбы с ними. Закрою глаза на то, что рекомендации ФСТЭК вышли спустя полтора месяца с момента WannaCry и пару недель с момента Petya/Nyetya. Все-таки у ФСТЭК нет задачи оперативного оповещения о компьютерных атаках и способах им противодействия - это задача ГосСОПКИ и она с ней справляется, пусть пока и для избранных, подключенных ведомств или иных организаций, например, в рамках Кубка Конфедерации. Да и процедура согласования любых официальных коммуникаций у госорганов со своими юристами дело небыстрое. Учитывая, что ряд госорганов, за безопасность которых и отвечает ФСТЭК, столкнулись с заражениями своих компьютеров, регулятор не смог остаться в стороне (хотя, наверное, мог) и выпустил “рекомендации”, в которых, если их уложить в одну фразу, указал, что 17/21/31-й приказы содержали защитные меры для борьбы с WannaCry и Nyetya и их реализация помогла бы предотвратить эпидемии. Отчасти конечно это так, но…


Во-первых, часть из описанных в сообщении мер (кстати, в нем было бы правильно указать коды этих мер) была включена в базовый набор только для 1-го и 2-го классов защищенности ГИС, а для 3-го и 4-го (хотя последних в природе, по словам ФСТЭК, почти не существует) эти меры не входили в состав рекомендованных (например, ОЦЛ.4, ОДТ.2, ОДТ.4, ОДТ.5, ЗИС.17, ЗИС.23 и СОВ.1). Тоже самое с ИСПДн и АСУ ТП - далеко не для всех классов/уровней защищенности рекомендованные меры были рекомендованы. А учитывая классическое стремление многих заказчиков к занижению классов и уровней защищенности, число тех, кто мог попасть под раздачу могло оказаться вполне большим, даже несмотря на реализацию приказов ФСТЭК.

Во-вторых, как показали обе эпидемии, традиционные антивирусы не могли оперативно обнаруживать данные вредоносные программы (очень хорошо это было видно на VirusTotal, где в первые часы после начала эпидемий только 5-7 антивирусов обнаруживали данные угрозы). ФСТЭК в своем сообщении правильно пишет, что нужны не простые антивирусы, а имеющие функцию эвристики. И тут мы натыкаемся на несколько тонких нюансов. Во-первых, ни в 17-м приказе (а также 21-м и 31-м), ни в методичке к нему, про эвристику не сказано ни слова, и в целях экономии и так небольшого бюджета на защиту информации заказчики могут применять обычные бесплатные антивирусы без какой-либо эвристики (в данном случае речь идет о реальном механизме, а не маркетинговых заявлениях). Во-вторых, эвристика включена далеко не всегда (отжирает системных ресурсов она не мало). В-третьих, системы класса STAP или EDR или EVC, которые заточены на борьбу именно с такими угрозами (я проверял на нашем Cisco AMP for Endpoints), часто не сертифицированы в ФСТЭК, так как непонятно, по каким требованиям проводить оценку соответствия - базы решающих правил у таких решений нет вовсе. В-четвертых, я пробежался глазами по требованиям к 4-му классу антивирусных средств типа “В” (для автоматизированных рабочих мест) и также не нашел в них ни слова про эвристику или иные, отличные от сигнатурных, методы обнаружения вредоносных программ, а значит при сертификации их могут и не проверять вовсе.

Кстати, еще один нюанс. В информационном сообщении ФСТЭК от 30 июля 2012 г. N 240/24/3095 говорится, что для применения в ГИС могут применяться только антивирусы 4-го класса защиты (не ниже), а в том же 17-м приказе еще недавно, до принятия 27-го приказа, говорилось, что для ГИС 4-го класса возможно применение антивирусов 5-го класса защиты. Теперь же, после принятия 27-го приказа, 17-й приказ допускает применение антивирусов 5-го класса защиты для ГИС 2-го класса защищенности и антивирусов 6-го класса для ГИС 3-го класса соответственно. Понятно, что руководствоваться надо 17-м приказом, а не информационным сообщением, но нестыковка требований налицо. Схожая проблема была с информационным сообщением про межсетевые экраны и 1-е декабря 2016-го года, что потребовало выпуска еще одного информационного сообщения.

В-третьих, среди упомянутых защитных мер не упомянуты ни управление потоками, например, анализ Netflow с сетевого оборудования (УПД.3), ни применение СЗИ от НСД для блокирования запуска того же psexec.exe (УПД.1, УПД.2, УПД.4, УПД.5, ЗИС.1), используемого в эпидемии Nyetya? А где упоминание контроля удаленного доступа к средствам административного управления WMI (УПД.13, ЗИС.23), внутренней сегментации сети (ЗИС.6, ЗИС.17), взаимодействия с Tor (ЗИС.16)?

Очень непривычно выглядит ссылка ФСТЭК на уязвимости, классифицированные в соответствие с Банком данных угроз и уязвимостей (БДУ). Обычно все вендоры ссылаются на CVE. Интересно, что ГосСОПКА в своих рекомендациях тоже использует международную классификацию CVE, “забывая” про отечественную БДУ (можно было бы и в скобках указать соответствующие коды). Добавлю, что рекомендации ГосСОПКИ по борьбе с Petya/Nyetya отличаются от рекомендаций ФСТЭК.

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

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