ИБ без бюджета. 7 сценариев

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

Пилоты

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

Разделение бюджета с другими подразделениями

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

Open source

Ну с этим вариантом вроде все понятно - вы используете кем-то уже написанное и выложенное в открытый доступ защитное ПО, которое представлено сегодня огромным спектром вариантов - от SIEM до DLP, от антивируса до системы обнаружения атак, от реверс-инжиниринга вредоносного ПО до threat hunting. За лицензии платить не надо, что отлично укладывается в стратегию "ИБ без бюджета". Однако есть и обратная сторона у open source - у специалистов, работающих с ним, квалификация должна быть гораздо выше, чем при использовании коммерческих решений. А высокая квалификация означает большую зарплату, в среднем выше, чем у традиционного безопасника, знакомого только с лидерами магических квадратов Гартнера. И хотя это совсем иная статья затрат, она в целом тоже может лечь на бюджет службы ИБ, что может сделать этот вариант не таким уж и предпочтительным.

Уход от CapEx в сторону OpEx

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

Встроенные механизмы

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

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

Если посмотреть на Топ8, то к упомянутым выше 4-м мерам, добавятся:

• конфигурация настроек макросов в MS Office
• включение защитных возможностей приложений (отключение Flash, Java Script и т.п.)
• ежедневное резервное копирование
• многофакторная аутентификация.

Пожалуй, только многофакторная аутентификация требует внешних решений, да и то, она может быть реализована с помощью open source решений, например, LinOTP, FreeOTP, Gluu, Aerobase и т.п. Если добавить сюда встроенные механизмы защиты в сетевое оборудование, то можно получить неплохий базовый уровень защиты, который будет отсекать не менее 80-90% всех угроз. Иными словами, закрыть многие вопросы ИБ можно встроенными механизмами защиты и отдельного бюджета на это не потребуется.

Работа с людьми

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

Купоны / скидки / черные пятницы / розыгрыши призов

В выходные закончилась "Черная пятница", которую можно назвать седьмым сценарием обеспечения ИБ без бюджета. Разумеется, наш преимущественно корпоративный рынок с его циклами продаж и длительным процессом заключения договоров мало использует тему, столь привычную для сегмента B2C. Но и у нас бывают различные интересные кейсы. Например, розыгрыши антивирусов на различных конференциях. А недавно, на одной из конференций разыгрывали бессрочную лицензию на Secret Net Studio на 1000 пользователей, VPN-поддержку на АПКШ Континет и лицензию vGate на неограниченное количество CPU. Учитывая, что стоимость софта практически равна нулю (даже на флешку или CD тратиться не надо), то для вендора это ничего не стоит, а для заказчика - возможность получить хоть какое, но решение по ИБ (да еще и сертифицированное). Правда, тут тоже могут возникнуть сложности с оформлением выигрыша и постановкой его на баланс, но это уже второй вопрос.

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

Подробнее…

Новая концепция кибербезопасности - Zero Trust (презентация)

Последний региональный "Код ИБ", который я посетил в этом году, проходил в Самаре, где я рассказывал о новой концепции Zero Trust. О самой концепции я уже написал небольшую заметку, а теперь пора выложить и презентацию.

Новая концепция кибербезопасности Zero Trust from Aleksey Lukatskiy

Есть еще и видео про Zero Trust, но оно с другого мероприятия и включает в том числе упоминания Cisco.

Подробнее…

ИБ в госорганах. Голоса с мест

Этой осенью мне довелось поучаствовать в нескольких региональных мероприятиях по ИБ, на которых я пообщался с представителями госорганов, которые поделились со мной своей болью относительно того, что происходит у них с точки зрения кибербезопасности. А на прошлой неделе на SOC Forum было искрометное выступление представителя Самарского ДИТа, который рассказывал о схожих проблемах. В совокупности набежало на целую заметку.

1. ВУЗы практически убили специалитет по ИБ, оставив преимущественно магистратуру и бакалавриат. А ФСТЭК в своей нормативке требует специалистов по защите информации. А их в природе больше и не готовят почти ;-( Как выполнить это требование?
2. Качество подготовки кадров оставляет желать лучшего. Это старая история, но не теряющая своей актуальности. То, чему учат, плохо подходит под новые требования, а то, что подходит, не имеет согласований у регуляторов, что вызывает опасения у представителей госорганов - полученную "корочку" не покажешь проверяющим, которые часто следуют формальным признакам.
   
   
   
   
   
3.  С 1-го января 2020 госы переходят на профстандарты, требующие специалистов (опять) с опытом работы от трех лет. Выпускник не подходит, а реальный спец с опытом 3+ на зарплату в гос не пойдет ;-( А если брать выпускника ВУЗа, то это штраф за нарушение профстандарта. В итоге получается коллизия, которую непонятно как решать. Судя по всему, регулятор в лице ФСТЭК не в курсе происходящих изменений в сфере образования и свои документы под них не обновлял.
   
   
   
4. Зарплата же в регионах в госорганах оставляет желать лучшего. Найти на такую зарплату специалиста с опытом непросто. И даже 13-я зарплата и премии не всегда сильно выправляют эту ситуацию. Приведенный внизу слайд с SOC Forum вызвал бурю эмоций в соцсетях; особенно ассоциативная картинка слева от сумм денежного довольствия :-(
   
   
   
   
   
5. Лицензия на мониторинг ИБ требует специалиста с опытом мониторинга ИБ от трех лет, который (опыт) может быть получен только при наличии лицензии, который требует специалиста с опытом мониторинга ИБ от трех лет, который... Рекурсия-с... Это старая история, но до сих пор всплывает, так как регулятор не дает четкого и официального (или хотя бы публичного на сайте) ответа.
6. ФСТЭК в числе ошибок по категорированию ОКИИ указывает отказ в признании субъектами, что у них есть КИИ, или занижение категорий значимости. А почему госы так делают? А денег им никто не дал на выполнение ФЗ-187. Лучше не признать наличие ОКИИ, чем признать и не выполнить ФЗ и сесть по 274.1 УК РФ. Парадоксально, но часто именно такие действия рекомендует региональное управления ФСТЭК своим подопечным (разумеется, неофициально).
   
   
   
   
   
7. Новые требования ФСТЭК не может даже сама ФСТЭК выполнить, а точнее ее региональные управления, часто сидящие в арендуемых помещениях, в которых нельзя выполнить все требования регулятора (в т.ч. и по ГТ). Это тоже старая история - многие требования ФСТЭК пишутся из расчета, что подопечные находятся в собственном здании или помещении, а это не так.
8. К ГосСОПКЕ все подключились, а от нее уже несколько месяцев никаких уведомлений и фидов не приходит. И в чем тогда был весь смысл? Чтобы ФСБ получила дополнительные права по проверкам?.. На SOC Forum прозвучало предположение, что сотрудники НКЦКИ готовились к выступлению и поэтому им не хватало рук на подготовку бюллетеней :-) А может просто атак не было. Хотя по данным регулятора враг не дремлет - на виртуальных границах обстановка неспокойная.
   
   
   
   
   
9. Российские вендора по ИБ достали. Вместо того, чтобы рассказывать о способах решения проблем, тупо впаривают свои поделия, часто даже повышая цены в условиях отсутствия конкуренции и запугивая требованиями по импортозамещению и обращением в суд или прокуратуру, если госорган не побоится и решит купить зарубежное решение. Часто звучит от госорганов вопрос "что делать, когда российских продуктов вообще нет под нужные требования, а дамоклова меча импортозамещения от плеч никто не отнимал?" Российские вендора только в рекламных листовках аналогичны иностранным решениям. А на деле далеки от того, что они импортозамещают.
10. Отдельная тема - боль испытательных лабораторий, которые не знают, как реализовывать новые требования по доверию от ФСТЭК. И ладно бы, это был единичный случай, я уже от 6-8 лабораторий это слышал в неформальной беседе.

Вот такая нерадужная картина вырисовывается. Но мы выстоим! Не в первой!

Подробнее…

Измерение эффективности SOC. 3 года спустя (презентация)

На прошлой неделе я выступал на SOC Forum с презентацией о том, как изменилось за последние три года отношение к измерению эффективности SOC. С этой темой я уже выступал три года назад и вот решил вновь к ней вернуться и посмотреть, что изменилось. В качестве иллюстрации использовал данные отчетов о состоянии SOC от SANS и Exabeam, а также результаты еще неопубликованного обзора по российским SOCам, который проводился в преддверии SOC Forum. Отдельный обзор по форуму я еще напишу, а пока выложу свою презентацию:

Измерение эффективности SOC. 3 года спустя from Aleksey Lukatskiy

Подробнее…

Как не ошибиться в выборе SOC-as-a-Service (презентация)

Вчера выступал на нижегородском Коде ИБ, где рассказывал про особенности выбора аутсорсингого партнера по ИБ на примере SOC-as-a-Service. Выкладываю презентацию (на Slideshare).

Как правильно выборать аутсорсингового партнера from Aleksey Lukatskiy

Подробнее…

Как защищать систему без моделирования угроз?

Сегодня совпало три события, которые и повлекли за собой написание этой заметки. Во-первых, я читал сегодня вебинар по концепции Zero Trust (если вдруг интересно, то вот ссылки на  материалы и видео). Во-вторых, а сейчас изучаю проект новой методики ФСТЭК по моделированию угроз, которая должна быть утверждена до конца года. Наконец, среди интересного проскочила новость, что исследователи нашли способ взламывать Siri, Alexa, Google Assistant с помощью лазера, который внедряет команды, заставляющие голосовых помощников открывать двери, заходить на сайты, запускать и разблокировать автомобили и т.п.

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

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

Первоначально она развивала идеи термина "депериметризация", родившегося ранее на Jericho Forum, и касавшаяся только сетевой составляющей. В оригинальную модель Zero Trust входило три компонента, которые позволяли повысить уровень защищенности, не доверяя статическим правилам на МСЭ, коммутаторах и точках доступа. 

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

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

 Это краткое изложении концепции Zero Trust, которая сейчас реализуется многими компаниями, - Cisco, Illumio, Okta, Google, Intel, Akamai, MobileIron и т.п. Но этот, достаточно инновационный подход для многих российских компаний врядли так быстро займет свое место на нашем рынке. Требования регуляторов по моделированию угроз и от него никуда не деться. Поэтому придется совмещать первое со вторым.

Подробнее…

Киберучения на SOC Forum 2018 (видео)

BIS TV выложило на своем канале в YouTube запись прошлогодних киберучений, который я вел на прошлом SOC Forum 2018. Меня многие спрашивали то презентацию с них, то примеры сценариев, и вот теперь есть возможность увидеть не только это, но и саму процедуру их проведения. В обычной жизни они проходят не так пафосно и пишутся под конкретную организацию, но и данное видео очень неплохо показывают всю концепцию и ее реализацию.


ЗЫ. Остается всего две недели до нынешнего форума. 

Подробнее…

Кибербезопасность медицинского учреждения: взгляд с точки зрения бизнеса

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

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

По сути речь идет о попытке обосновать нужду в ИБ опираясь на три составных части, которые "заинтересованы" в атаках и защите от них - пациенты, регуляторы и хакеры. Но как мы уже поняли, первым двум категориям в целом ИБ не так уж и важна. А третья... А что третья? Как она может монетизировать атаки на медицинские учреждения? Социнжиниринг? Может быть, но маловероятно, так как что можно заставить сделать пациента, которому представились представителем его медучреждения? Повторно сдать анализы?

Но... давайте посмотрим чуть шире и попробуем встать на место конкретного пациента, который ходил не только в поликлиники по врачам, но и может лечь в стационар на 2-3 недели. Что можем ему помешать "насладиться" лежанием в больничной палате? Отсутствие Wi-Fi, выведенного из строя хакерской атакой? Может быть, если речь идет не о Москве с его безлимитным LTE. Подмена лекарств или рецептуры в электронной карте больного? Тоже может быть. Но пока не в России, где электронные карты - еще редкость. Шантаж родных, близких и знакомых разглашением факта "плохой" болезни? Да, вполне. В свое время представители РКН и Госдумы именно под этим соусом продвигали ФЗ-152 в его жесткой редакции. Еще утечка может быть актуальной в тех случаях, когда среди пациентов есть всяческие селебрити - звезды шоу-бизнеса, чиновники, телеведущие и т.п. Из информации об их болезнях можно сварганить репортаж, который привлечет массу людей, рекламодателей и т.п. Вспомните, непрекращающуюся последние пару месяцев эпопею с "болезнью" Заворотнюк...

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

Есть еще одна категория заинтересованных в медицинской ИБ лиц. Это производители медицинского оборудования, взлом которых влияет и на пациентов, их жизнь и здоровье, и на клиники, простой оборудования от шифровальщика может повлечь снижение доходов, и на производителя, которого могут наказать регуляторы (например, в США) или чьи заказы могут сократиться.

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

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

Подробнее…

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

Не секрет, что в России немало находится людей и компаний, активно продвигающих идеи импортозамещения в области информационной безопасности. Это патриотическое занятие на благо России сегодня омрачается только одним - использование англицизмов, а то и вовсе английских слов в названии продуктов и компаний, который считают себя апологетами импортозапрещения ИБ. И пока в российских школах не ввели изучение старославянского языка и Закона Божия, многие отечественные специалисты сталкиваются с трудностями в поиске слов-синонимов, которые бы отражали суть отечественных инноваций и при этом бы были исконно русскими. Я решил немного помочь поборникам ИБ-нравственности и составил небольшой словарик старорусских слов, которые можно использовать при создании новых или переименовании существующих продуктов и технологий защиты информации. Тем более, что за 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 - Холопские врата
• Мастерчейн - Гривнозлатарь
• Перспективный мониторинг - Узреющая ворожения.

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

Подробнее…

Эскалация инцидентов ИБ

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

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

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

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

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

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

При эскалации одной из важнейших задач является обоснование для нее. Я, как, думаю, и многие люди, не всегда объясняю причины своих поступков, считая, что "все же и так очевидно". Вот в эскалации такая фигня не работает - чтобы эскалация прошла успешно, должна быть веская причина. "Я так хочу", "Это же очевидно", "Я же босс" к таковым не относятся. Интересно, но когда пытаешься внятно сформулировать, зачем тебе нужна эскалация, часто получается, что она и не нужна :-) Если же верно все-таки обратное, то обоснование для эскалации должно быть бизнес-ориентированным. "Данный инцидент может стать достоянием СМИ и надо подготовиться", "Несмотря на стандартные двое суток на решение данного типа инцидента, нам надо его решить к завтрашнему совету директоров", "По результатам расследования стало известно, что утекло не 1000 записей о клиентах, а 1 миллион записей", "Шифровальщик заразил компьютеры бухгалтерии и они не успевают сдать отчетность в налоговую, что может привести к штрафам" и т.п.

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

Подробнее…

Приоритезация инцидентов ИБ: все не так просто

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

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

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

Очевидно, что от приоритета/класса инцидента зависит, например, в течение какого времени необходимо реагировать на него. Потенциальная утечка миллиона записей о клиентах относится скорее к критичному инциденту (а может быть и к катастрофичному, если в организации вводится еще одна, шестая категория), а вот утечка "всего" 100 записей могла бы быть отнесена к инциденту среднего, а то и низкого приоритета.

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

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

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

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

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

Подробнее…

Вас шантажируют утечкой данных. Что делать?

Весной 2019-го года, на CISO Forum, я проводил киберучения, где среди прочего был и такой кейс - вы получаете сообщение через соцсети (чат в Facebook Messenger, Telegram, Whatsapp, Viber и т.п.) от человека, который называет себя известным в отрасли ИБ именем и который заявляет, что нашел в Darknet доказательства утечки у вас базы данных. Он, разумеется, готов вам помочь провести расследование данного инцидента. Следующий кейс - этот же человек публикует в открытом доступе информацию об утечке в вашей компании и вы сталкиваетесь с запросами со стороны СМИ.

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

Вот представьте, что пока вы читаете эту заметку, к вам пришло сообщение о том, что ваша база клиентов утекла и ее продают в Darknet? Что вы будете делать? Если собрать все, что звучало в рамках киберучений (не только двух упомянутых) и добавить кое-что от себя, то вырисовывается следующий набор действий, который надо делать в таких ситуациях.

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

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

Подробнее…

Применение роботов (платформ RPA) для кибербезопасности

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

Оставим пока в стороне ответ на этот вопрос. Зададимся другим. Точнее я им задавался достаточно долгое время, наблюдая за реализацией сервиса CAPTCHA на разных сайтах. Какое-то время считалось, что этот простой механизм позволяет отсечь ботов и пройти его может только человек. Но если посмотреть на то, как реализуется CAPTCHA, то будет понятно, что мы всегда повторяем одни и те же действия - вводим увиденный на картинке текст в соответствующее поле или нажимаем на картинки, показывающие то, что нас спрашивает сервис CAPTCHA (светофоры, машины, вывески, мосты, гидранты и т.п.). Можно ли автоматизировать действия по нажатию клавиш или движению мыши? Ведь в конце концов мы это делаем не сами,  а просто даем команды компьютеру, которые он и реализует. Но куда вбивать текст и куда кликать мышью указывает человек! Да, но эти действия тоже можно автоматизировать. Помогает решить эту задачу технология RPA (Robotics Process Automation), которая позволяет автоматизировать различные процессы, используя настраиваемых программных роботов, имитирующих действия человека за счет взаимодействия с информационной системой и она не видит разницы между роботом и человеком.

Что умеют  роботы RPA? Они работают с Web-формами, приложениями, почтой, документами, базами данных, файлами на диске или в Интернет, которые могут быть преобразованы по заданному сценарию или алгоритму. Такой робот:

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

Внедрение робота занимает немного времени - от 2-х дней уходит на изучение процесса, определение необходимых приложений и ИС, с которыми нужно работать, и снятие скриншотов действий пользователя. От 5-ти дней уходит на настройку робота - сценариев его работы и взаимодействия с нужными системами. От 3-х дней уходит на тестирование и доработку робота. Для простых случаев автоматизации внедрение робота займет около 10 дней - в более сложных может понадобиться 1-2 месяца.

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

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

• Заход в личный кабинет ФинЦЕРТ или ГосСОПКА для получения бюллетеней или уведомлений
• Обогащение событий безопасности из источников TI
• Заведение тикетов в IRP / SOAR
• Анализ заявок на предоставление доступа к корпоративным ресурсам
• Организация фишинговых симуляций
• Сбор облачных логов в Excel/CSV и загрузка их в SIEM
• Анализ входящих сообщений от пользователей
• Работа с унаследованными или legacy системами ИБ
• Тестирование защищенности Web-приложений
• Сбор инвентаризационных данных из десятка источников и приведение к единому формату с загрузкой в CMDB
• Мониторинг Интернет-ресурсов, а также анализ новостей по ИБ и отправка ключевых во внутреннюю рассылку
• Построение dashboard
• Получение согласий на обработку ПДн от клиентов
• Уведомление о нарушении прав субъекта ПДн.

Это неполный перечень, но он достаточно показательный. С помощью RPA можно автоматизировать многие рутинные задачи, возникающие в деятельности ИБ. Кто выпускает RPA-платформы? Вот список некоторых вендоров, которых можно встретить в России, - UiPath, Automation Anywhere, Blueprism, WorkFusion, Pegasystems, NICE, Kryon, Kofax, Contextor, Softomotive, Redwood Software, EdgeVerve, Another Monday, Antworks, Toughtonomy, SAP iRPA, Datamatics Trubot, Jacada, NTT-AT, Helpsystems, Servicetrace, Robin, PIX, HyperUp, electroNeek.

Подробнее…

Измерение эффективности ИБ промышленных систем

На прошлой неделе мне довелось выступать на конференции Kaspersky ICS Cybersecurity Conference с докладом, посвященным оценке эффективности ИБ промышленных систем. Оказалось, что я удачно дополнил доклад выступившего передо мной Патрика Миллера из Archer про коммуникации с бизнесом. У меня же доклад был более приземленный с примерами метрик, которые могут быть использованы при оценке своей эффективности и последующей коммуникации с бизнесом.

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

Выкладываю свою презентацию:

Измерение эффективности ИБ промышленных систем from Aleksey Lukatskiy

Подробнее…

Разъяснения Банка России с осенной сессии Уральского форума

На прошлой неделе прошла конференция, организатором которой стал Банк России, и которая стала выездной сессией Уральского форума, проведенной в Москве. На ней регулятор попробовал ответить на животрепещущие вопросы, касающиеся как ЕБС, так и недавно выпущенных, но уже вызвавших немало вопросов нормативных актов (683-П, 684-П и т.п.). Параллельно с этим, как член ПК1 ТК122 я собрал с отрасли около 50 вопросов, которые были направлены в Департамент ИБ Банка России с целью получения ответов на них. И вот часть таких ответов прозвучала на конференции. Позволю себе тезисно озвучить то, что было озвучено.

Единая биометрическая система

1. Банк России опросил 38 банков, 7 из которых планируют делать свои собственные решения для подключения к ЕБС. Остальные хотят использовать типовое решение, самых распространенных сейчас четыре - от Ростелекома, Инфотекса, ЦФТ и IDSystems.
2. Стоимость облачного решения Ростелекома - около 3 миллионов рублей в год. Стоимость типового решения - 5 миллионов (включая инфраструктуру построения, HSM, антивирусы и т.п.).
3. Типовое решение уже включает тематические исследования и финансовым организациям проводить их не требуется.
4. Покупка типового решения не отменяет выполнения методички Банка России МР-4.
5. По словам ЦБ, ряд разработчиков типовых решений делают только сбор биометрии, без предоставления функции верификации, что неправильно по мнению регулятора.
6. Стоимость собственной разработки (в качестве примера был приглашен Тинькофф) обходится примерно в те же 5 миллионов. Но это все без резервирования тех HSM. С резервированием - стоимость увеличивается еще примерно на 3-4 миллиона. Длительность создания собственного решения у Тинькофф составила 4-5 месяцев без тематических исследований.
7. Обсуждалась тема мобильного сбора биометрии, для которой максимальный возможный класс сертификации СКЗИ озвучивался как КС2. Готовых решений пока нет, но Ростелеком работает над ним. При этом вопрос качества собранной биометрии с помощью планшета или смартфона не обсуждался совсем.
8. Для удаленного сбора должны применяться только СКЗИ КС3 или КС2 но с соблюдением. требований к СВТ 4-го класса. Пока обойти эти требования или снизить нельзя. 

683-П / 684-П / 672-П

1. Планируется кардинальное изменение 382-П, из которого уберут упоминание кредитных организаций (операторов по переводу денежных средств). 382-П будет распространяться на участников НПС - некредитные организации, а также на новые сущности, введенные последними правками в 161-ФЗ - платежные агрегаторы, разработчики платежных приложений, операторы информационного обмена (SWIFT, привет!). Защита информации при осуществлении переводов денежных средств уйдут целиком под 683-П, который покрывает все банковские операции. 
2. ЦБ считает, что анализ уязвимостей можно проводить своими силами, если есть для этого возможности, навыки и квалификация. Но пока непонятно, как отсекать некачественно проведенную оценку. ЦБ думает над этим.  
3. На вопрос о том, что является доказательством проведения анализа уязвимостей, если это делает производитель платежного ПО или привлекаемый лицензиат, ЦБ подготовит разъяснение. Надо внимательно посмотреть ГОСТ 15408 в части представления результатов оценки.
4. В августе ЦБ разослал письмо по кредитным организациям, в котором говорится, что с учетом принятия ГОСТ 57580.1/57580.2 и 683-П, направлять оценку по СТО БР ИББС 1.2-2014 больше не требуется. Ее проведение остается на усмотрение кредитной организации. Когда кредитные организации выведут и из под 382-П, то у них останется единственная оценка соответствия - по ГОСТу. Надзор ЦБ больше не будет руководствоваться СТО БР при проведении своих мероприятий.
5. 202-я форма будет пересмотрена.
6. Документ по операционным рискам (с резервирование капитала и прочим блэкджеком) будет очень плотно завязан на новый ГОСТ по управлению киберрисками, который сейчас активно пишется и в октябре будет представлен членам ПК1 ТК122. Так что можно ожидать, что до конца года положение по операционным рискам будет все-таки принято.  
7. На вопрос о том, почему 683-П и 684-П местами так отличаются друг от друга, прозвучало, что хоть они и писались ДИБом, но затем сильно перерабатывались соответствующими - департаментами банковским и НФО.
8. Несмотря на то, что в 684-П прямо не упомянуты (при установлении уровней защиты) микрофинансовые организации, ломбарды и ряд иных, на них распространяются общие требования, прописанные в 684-П (защита от вредоносного кода, уведомление клиентов о рисках и т.п.).
9. Если кредитная организация ведет депозитарную и репозитарную деятельность, то применять необходимо и 684-П, даже несмотря на то, что у него сфера деятельности - некредитные финансовые организации. Но, учитывая, что кредитные организации обязаны также выполнять и 683-П, то при пересечении требований выполняться должны те, которые жестче, то есть, по сути, 683-П. 
10. По поводу SMS и Push ЦБ считает, что не обязательно применять УКЭП. Можно использовать и другие меры подтверждения целостности без УКЭП. Сейчас завершается подготовка информационного письма для этого.
11. Было озвучено, что есть правовые проблемы с использованием облачным провайдером ЭП банка (ключи нельзя передавать третьим лицам). ЦБ вроде как нашел с ФСБ некое решение, но у них есть сомнение в его правомерности. Если в новую редакцию 63-ФЗ внесут "третью доверенную сторону", то проблема разрешится. Пока этот вопрос в серой зоне и каждая кредитная организация решает его для себя самостоятельно.
12. ГОСТ допускает применение несертифицированных средств защиты при отсутствии их на рынке (техническая невозможность) или высокой цены (экономическая нецелесообразность). Это и так было понятно, но тут это прозвучало еще раз на прямо заданный вопрос.
13. Вновь прозвучала мысль, которая звучит последние лет 10, что ЦБ не интересует КАК будут реализовываться защитные меры и какие конкретные технические решения будут применяться. Финансовые организации сами выбирают способ реализации. Для ЦБ важна оценка уровня риска, для чего ЦБ сейчас внедряет новый риск-ориентированный подход, который будет оценивать каждую организацию по набору показателей.

Перспективы и планы

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

Подробнее…

Почему ВУЗы не преподают теорию игр специалистам по ИБ?

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

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

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

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

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

Про игру Касперского я повторяться не буду, покажу еще парочку примеров игр по ИБ, которые основаны на теории игр (я постил их скриншоты в своем Twitter, но решил повторить и в блоге). Начну с решения Project Ares компании Circadence, которое позволяет моделировать различные ситуации и учить специалистов по ИБ реагированию на различные ситуации.

За последний год проект существенно обновился и "вырос" - появились различные варианты подписки - для ВУЗов, для корпоративных пользователей и т.п.

Есть различные сценарии проведения игр с разным числом участников и разными заданиями.

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

Есть в Project Ares и развлекательные компоненты, например, "пасьянс "Косынка" на тему ИБ:

или аналог "Своей игры":

или аналог "Змейки":

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

Но стали появляться и компьютерные игры, доступные каждому желающему. Например, на игровой платформе Steam скоро выпустят игру ThreatGEN: Red vs Blue, которая позволит множеству игроков попробовать себя в роли хакеров или защитников, не ломая реальные сети и системы, но оттачивая свои стратегические и тактические навыки, которые можно будет применять в реальной жизни (конечно, с оговорками). 

У этой игры будет несколько версий:

• Red vs Blue. Игра для всех желающих на платформе Steam.
• Red vs Blue Corporate. Настраиваемые сценарии игр для корпоративных тренингов.
• Red vs Blue CTF. Соревнования команд.
• Red vs Blue Tabletop. Игра для проведения штабных киберучений.
• Red vs Blue Instructor Led Training.

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

Подробнее…

Deepfake: обход биометрии, непредусмотренный регуляторами

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



Меня эта тема интересует последние пару лет, когда только появилось первое приложение DeepFake и когда Банк России стал семимильными шагами внедрять Единую Биометрическую Систему (ЕБС). Когда ЦБ выпустил свое Указание 4859-У, то я надеялся, что там такого рода угрозы найдут отражение, но все, что хоть как-то можно отнести к ним, это расплывчатая формулировка про актуальность угроз нарушения целостности (подмены) биометрических персональных данных. Настолько абстрактное понятие, что даже непонятно, о чем идет речь - о deepfake или о подмене свертки биометрического фактора?

Была надежда, что в 321-м приказе МинЦифры или в МР-4 Банка России включат раздел про нейтрализацию таких угроз, но увы. И эти документы оказались далеки от прикладных атак, концентрируясь либо на применении криптографии, либо на применении сертифицированной ОС, МСЭ и антивируса, напрочь забыв даже про защитные меры из 21-го приказа ФСТЭК по защите ИСПДн. Последний, перекрывая по своему содержанию и МР-4 и приказ №321, тоже ни слова не говорит о том, как. бороться с deepfake.

Самое неприятное, что на различных мероприятиях или в соцсетях, где присутствуют участники процесса, связанного с ЕБС, упорно обходят молчанием эту тему, даже если им задаешь напрямую вопрос о том, как бороться с этой проблемой. Хоть какой-то ответ я нашел в одной презентации "Центра речевых технологий", чьи технологии используются в ЕБС, например, у того же Банка "Открытие" и ряда других (решение VoiceKey.INSPECTOR). Правда, используются они при сборе биометрии, а проблема с deepfake возникает на этапе ее проверки в режиме повседневной эксплуатации.

Если посмотреть на классический жизненный цикл биометрической, то он в обязательном порядке должен содержать этап проверки "живости", без которого биометрия не имеет никакой ценности, несмотря на использование СКЗИ класса КВ или даже КА.

В своих материалах ЦРТ приводит методы проверки живости для изображения лица, как биометрического признака:

и для голоса, как второго биометрического признака:

Но какие из этих методов реализованы в ЕБС не совсем понятно. В описании того же "Ключа" от Ростелоекома говорится о liveness detection, но без каких-либо деталей и уточнений. А судя по презентациям отдельных банков, которые бодро отрапортовали о том, что они не только интегрировались с ЕБС, но и внедряют уже биометрию в свои банковские процессы, далеко не все понимают угрозу deepfake и борются с ней. Например, один из банков предлагает возможность перевода денег без указания номера карты или телефона, "просто сфотографировав получателя". В данной схеме даже liveness detection никакого нет - работа со статическим биометрическим признаком, который подделать ничего не стоит.

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

Если посмотреть на обратную сторону, на то, что можно противопоставить deepfake, то тут исследований не так уж и много. На последних крупных конференциях по ИБ я вспомнил только одно. А вот с готовыми решениями по этой теме, что-то не густо. Что-то встроено в сами биометрические решения, но не во все. В отличие от идентификации фальшивых изображений (OZ Forensics) или собственно самой биометрической идентификации. И тут остается полагаться на здравый смысл безопасников, которые будут следовать не только нормативных актам регуляторов, но и самостоятельно задавать вопросы производителям внедряемых решений о том, как те борятся с deepfake. Ибо цена ошибки достаточно высока, а ответственности за взлом биометрической системы регуляторы не несут; как и сами вендоры, которые продают свою решения по принципу "AS IS". Как минимум, стоит посмотреть в сторону решений по многофакторной аутентификации, которые могут частично. нивелировать проблемы, связанные с низкой защищенностью биометрии.

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

Подробнее…