1.12.20

Последствия от онлайна по ИБ - от ибшнего getAbstract до онлайн-ИБ-тамады

UPDATE: Эта заметка изначально писалась в прошлую среду, но я забыл ее запостить, а потом, точно в тот же день, Рустем Хайретдинов в Фейсбуке написал примерно ту же идею, и я даже хотел удалить заметку, чтобы не дублировать Руста. Но потом подумал, что я мысль повторю, но поверну ее немного в иную плоскость. Тем более и повод нашелся для этого. 

Завершившися недавно The Standoff, навел меня на мысль о стартапе, который мог бы быть достаточно востребован у ИБ-аудитории, особенно у людей, занимающих руководящие должности и при этом стремящиеся к постоянному самообучению. Речь идет о аналоге классических getAbstract или Smart Reading (и вроде как эта идея даже уже звучала у Льва Шумского в Фейсбуке). Последние полгода лишний раз показали, что такой сервис как никогда нужен. 

Вот заходите вы на портал The Standoff и видите там 70 досаточно интересных докладов по информационной безопасности, которые вы бы и хотели посмотреть/послушать, но явно не готовы потратить на это 70 часов при обычной скорости просмотра и 50 часов на ускоренной в 1,5 раза перемотке. Что делать? А если сюда приплюсовать сотни часов RSA Conference, Black Hat, Defcon, SOC Forum, Магнитки и множества других не менее интересных мероприятий, на которых часто рассказываются очень интересные вещи, но которые остаются неуслышанными по причине нехватки времени на их прослушивание. Ровно по этой причине столь большой популярностью пользуется моя презентация на Магнитке "Уральский форум за 15 минут", и мои, правда, уже заброшенные обзоры новой нормативки и регулярно читаемые пятичасовые курсы по новинкам законодательства по ИБ для финансовой сферы.

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

С одной стороны, это вроде усложняет задачу. Людей, которые пишут резюме для Smart Reading или getAbstract на порядки больше. Но с другой, это не такая уж и нерешаемая задача. Под нее можно брать "пенсионеров", которые разбираются в теме и у них много времени, чтобы сидеть и слушать/читать все, что необходимо для описываемого сервиса.

Таким "пенсионерам" есть и еще одна сфера применения - поддержка онлайн-мероприятий. Вы замечали же, что многие мероприятия, ушедшие в онлайн, много потеряли, так как нет кулуарного общения? Но проблема еще и в том, что их организаторы часто считают, что можно просто дать красивую картинку во вкладку браузера слушателя и наступит счастье. Увы, не наступит. В онлайне тоже надо активно общаться с участниками в чате/чатах, созданных каналах в Телеграм или группах в Вотсапп, а у продвинутых так и в комнатах Webex Teams/Training, каналах Slack и т.п. Ведь во время скучного доклада слушатель может уйти и уже не вернуться. Его надо удерживать и беседа с умными людьми в чате помогает решить эту задачу. Но другие слушатели не всегда горят желанием "болтать" или отвечать на вопросы - им доклад может быть интересным. Поэтому нужны профессиональные ИБ-тамады, которые будут комментировать выступления, троллить докладчиков (по доброму), вовлекать аудиторию в дискуссию и т.п. Тогда онлайн реально станет онлайном, а не просто просмотром видео, которое можно сделать в свободное время на ускоренной перемотки без потери качества.

Мне такая идея показалось достаточно интересной и сегодня, на SOC Live мы ее обкатаем. Вместе с Алексеем Комаровым мы будем в течении дня комментировать в чате все выступления в обоих потоках виртуального SOC Forum. Не взирая на регалии и спонсорские пакеты - все, что мы посчитаем нужным, мы выплеснем на платформе для мероприятия и с нами можно будет даже вступить в перепалку и виртуально набить нам морду :-) Это интересный формат, которого раньше не было у нас на мероприятиях. И если он получится, то так ругаемый всеми онлайн-формат (он же "вебинар на стероидах", как его называет Денис Горчаков) может получить новуюжизнь. А ИБ-пенсионеры смогут найти себя. Если, конечно, их найдут организаторы мероприятий и посчитают возможным для себя потратить на их услуги немного спонсорских денег :-)

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

16.11.20

Как выстроить эффективный процесс повышения осведомленности по ИБ (видео)

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


13.11.20

Обнаружение угроз 20 лет спустя: источники данных и их расположение

 В ряде прошлых заметок я коснулся темы обнаружения угроз и показал отличия этих двух тем сейчас и 20 лет назад. Продолжу. Одним из ключевых отличий является наличие совершенно различных типов контента обнаружения, который не ограничен только сигнатурами атак. Но не только это. На самом деле я бы выделил еще 3 ключевых направления, в которых произошли кардинальные изменения:

  • источники данных
  • методы анализа
  • сценарии обнаружения (use case).

Задайте себе простой вопрос - что вы сейчас анализируете на предмет вредоносной активности и в чем вы ищете ранее обсуждаемый контент обнаружения? Сетевой трафик? Логи? Телеметрию? Файлы? URL? Почтовый трафик? Активность пользователей и процессов? А анонсы BGP? А API? А DNS-трафик?

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

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

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


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


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

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

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


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

11.11.20

Актуальные требования регуляторов к средствам защиты (видео)

В январе выступал на конференции Oracle Security Day с рассказом об актуальных на тот момент требованиях регуляторов к средствам защиты информации. Оказывается видео этого выступления было официально выложено на Youtube:


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

10.11.20

Требуется консультант по безопасности личного профиля (навеяно Дзюбой)

Не так часто пишу про персональную кибербезопасность, но история с интимным видео Дзюбы навеяла ряд мыслей, которые показались мне достаточно важными, чтобы сохранить их для потомков. Итак, дистанцируясь от конкретной истории, мы имеем дело с публикацией интимного видео человека в Интернет явно без его согласия. Что стоит за такой ситуацией? Я бы выделил 5 причины:

  1. Месть "бывшей". Вполне возможный вариант, повлиять на который мы не в состоянии никак. По крайней мере информационная безопасность тут ни причем. 
  2. Случайность. Всякое бывает. Я тут в Whatsapp хотел отправить картинку в сообщении и случайно вместо одной кликнул на соседнюю. Размер экрана смартфона и толстые пальцы - это вообще сложносовместимые вещи, а уж если в фотопотоке рядом соседствуют обычные и интимные фото и видео, то тем более. К ИБ это тоже отношения не имеет, по крайней мере пока смартфоны не научились распознавать содержимое видео и фото и не задавать вопросов "Вы уверены, что хотите разместить в публичном доступе этот контент?" Ну либо соцсети должны оперативно выявлять и блокировать такой контент (правда, если он попал туда случайно).
  3. Смартфон был взломан и злоумышленники вытащили все самое ценное, что было в нем. Вспоминая уязвимости Bluesnarfing/Bluebugging/Bluejacking/Bluesnipping в Bluetooth, понимаешь, что такое возможно; особенно, если смартфон давно не обновляли. Тут даже физический доступ к смартфону получать было необязательно.
  4. Было взломано облачное хранилище, в котором хранились фотографии, видео и, возможно, резервные копии смартфона. При отсутствии многофакторной аутентификации или затроянивании домашнего компа с доступом к облаку такой сценарий тоже вполне возможен.
  5. Ну и, наконец, дипфейк. В истории, послужившей причиной для данной заметки, вроде как это не так, но в теории такое вполне может быть. В Интернете публикуется видео или фото с подменой лица и потом иди и доказывай, что ты не верблюд. Может быть ты это и докажешь, но "осадочек остался".

В 2014-м году Сколково и АСИ выпустило атлас новых профессий, в котором говорилось о том, что до 2020-го года должна появиться такая профессия, как консультант по безопасности личного профиля. 4 года назад я уже писал о том, что у меня были идеи замутить бизнес на эту тему. Но пока я благополучно работаю в Cisco, а прогноз Сколково и АСИ не сбылся, временно возьму на себя роль такого консультанта и дам ряд советов по 3-5-м пунктам:

  1. Регулярно обновляйте свой смартфон, особенно если он на Андроиде, уязвимость которого изначально выше из-за архитектуры и подхода Google к работе с этой платформой и распространением приложений для нее.
  2. Настраивайте права доступа мобильных приложений и не разрешайте им то, что не нужно. Например, зачем приложению с прогнозом погоды доступа к вашей адресной книге и фотографиям?
  3. Установите на смартфоне PIN-код длиннее 8 символов (если он символьный).
  4. Настройте многофакторную аутентификацию при работе с внешними сервисами, особенно облачными сервисами, хранящими фотопоток (например, iCloud, Google Фото, OneDrive, Яндекс.Диск, Облако Mail.ru, Dropbox и т.п.) и резервную копию.
  5. Сыграйте с собой в игру "А что, если?.." Если вы достаточно известный человек, то что вы будете делать, если в Интернете появится ваши нелицеприятные видео или фото? И дело тут не только в дикпиках. Представьте, что вы жрете козявки перед web-камерой? :-) Или чешете себе "Гондурас" регулярно... Неприятно, да. Но это уже не исправить и не удалить, а попытка потребовать удаления каких-то материалов из Интернет приведет только к эффекту Стрейзанд. Неплохо бы подготовить (хотя бы в голове) какое-нибудь заявление по поводу, пытаясь не усугублять негатив, повернув его в более позитивное русло. 
  6. В развитие предыдущего совета, подумайте о том, что даже если вы весь белый и пушистый и web-камера у вас заклеена изолентой как у Цукерберга, то существует такое явление как Deep Fake, которое позволяет приделать ваше лицо к чужому телу. И это не игрушки, когда используется Photoshop (как в рекламе для SOC Live, где к одному телу приделали поочередно головы меня, Володи Дрюкова и Антона Шипулина). Речь и применении специальных алгоритмов, которые очень грамотно накладывают фото на чужое лицо, подстраивают его под движения, мимику, добавляют речь, синхронизируют ее с движением губ и т.п. Отличить фейк от реального человека становится очень сложно. Не даром говорят, что порнография драйвит технологии. Так и тут. На порносайтах сейчас создают отдельные каталоги таких фейков, а в Телеграмме появилось куча каналов, которые позволяют "раздеть" любого человека, убрав всю одежду и сгенерировав фотографию обнаженного человека. При этом в последнем случае лицо будет настоящим, и телосложение тоже. Только вот человек уже будет без одежды. Вы готовы к таким дипфейкам?  

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

ЗЫ. Да, для особо настойчивых. Это заметка не про Дзюбу (я вообще не знаю, за какую команду он играет) и не про нарушение закона "О персональных данных" и распространение спецкатегории ПДн без согласия субъекта. Это всего лишь повод хайпануть обратиться к теме персональной кибербезопасности и обратить на нее внимание.

9.11.20

Что общего между SOCом и онлайн-мероприятием по ИБ? Ложь в цифрах!

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

Собственно аналогия с мероприятиями у меня возникла не на пустом месте. Попросили тут меня провести для одной компании вебинар по повышению осведомленности сотрудников в области ИБ, пообещав загнать туда около 400 человек, почти весь свой персонал. Для этого они были готовы привлечь HR, который должен быть разослать сообщение по всем сотрудникам, большинство из которых находилось на удаленке. Сказано - сделано. В день мероприятия я подключаюсь к платформе (это был Zoom) и вижу там 36 человек. Мда, - думаю. "Прекрасный" результат, отражающий все отношение сотрудников компании к ИБ. До конца мероприятия осталось 32 человека (достаточно неплохой результат - 89%). Каков эффект от мероприятия мне неизвестно, но в письме, которое служба ИБ направила своему руководству, фигурировало число 400, красиво обернутое фразой "информация о мероприятии была доведена до 400 человек" :-) Но мы же прекрасно понимаем, что это совсем не то, что было в реальности. Аналогичная ситуация и с онлайн-мероприятиями, а я за последние почти 9 месяцев поучаствовал в многих из них.

Их организаторы обычно хвалятся числом регистраций. Это примерно как хвалиться числом событий ИБ, которые фиксируют ваши средства защиты. Например, в инфраструктуре Cisco фиксируется ежедневно 1,2 триллиона событий ИБ. Это, на минуточку, в 3 раза больше чем звезд в нашей галактике "Млечный путь". Круто, не правда ли? Но вот только мы прекрасно понимаем, что из этих событий ИБ многие ложные, а многие вообще малоинтересны. Мы должны все эти события просеять через различные фильтры, убрав ложные срабатывания, проведя анализ и корреляцию, а после из оставшихся реальных инцидентов выбрав только критичные. В итоге, в Cisco остается на отработку нашим SOCом всего 22 инцидента в день. Так вот с онлайн-мероприятиями необходимо использовать ту же саму "воронку продаж", только вместо "клиентов" использовать слушателей.

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


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

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

Вот пример с повышением осведомленности и более глубокая статистика, чем просто число регистраций. Для анализа использовался сервис Cisco Webex Events (не путать с Webex Meetings - разница именно в фишках для организации мероприятий), который по каждому мероприятию позволяет собрать полноценную статистику, из всего объема которой нас в контексте данной заметки интересует всего три показателя. Первый - длительность участия в мероприятия с момента входа до момента выхода. Для одного из Security Awareness тренингов, длившихся чуть более двух часов (почему так долго - это отдельный разговор), статистика выглядит следующим образом. Метрика "среднее время нахождения на мероприятии":

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

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

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

6.11.20

Что такое контент обнаружения или почему сигнатур атак недостаточно?

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


На первом этапе вы должны определиться с тем, что вам позволит обнаруживать угрозы. Обычно в качестве контента обнаружения рассматриваются сигнатуры, которые точно описывают ту или иную угрозу. Например, вот так может выглядеть сигнатура для Zerologon:

alert tcp any any -> [$HTTP_SERVERS,$HOME_NET] any (msg:"ET EXPLOIT Possible Zerologon NetrServerReqChallenge with 0x00 Client Challenge (CVE-2020-1472)"; flow:established,to_server; content:"|00|"; offset:2; content:"|04 00|"; distance:19; within:2; content:"|5c 00 5c 00|"; distance:0; within:50; content:"|00 00 00 00 00 00 00 00|"; isdataat:!1,relative; fast_pattern; threshold: type limit, count 5, seconds 30, track by_src; reference:url,www.secura.com/blog/zero-logon; reference:cve,2020-1472; classtype:attempted-admin; sid:2030870; rev:2; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Server, created_at 2020_09_14, cve CVE_2020_1472, deployment Perimeter, deployment Internal, former_category EXPLOIT, signature_severity Major, updated_at 2020_09_18;)

Имея низкий уровень ложных срабатываний сигнатуры считались долгое время основным, а иногда и единственным способом обнаружения угроз. Ярким примером системы обнаружения атак на базе сигнатур является бесплатная система Snort, лежащая в основе многих отечественных СОВ/СОА, или Zeek (бывшая Bro), а также коммерческие решения, лидером рынка которых по мнению Gartner является Cisco.


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

Комбинация IoC

Триггеры позволяют отделять нормальную активность от аномальной. Например, решение по защите e-mail позволяет выявлять компрометацию почтовой учетной записи пользования по числу отправляемых вовне сообщений, а система класса Network Traffic Analytics/Analysis позволяет выявлять утечки данных через разрешенные сетевые протоколы, например, DNS.

18 Гб с терминального сервера по DNS? Не странно ли? 

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

Анализ файла в песочнице

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


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


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

Обнаружение утечки данных в зашифрованном трафике

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

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


 

5.11.20

Обнаружение угроз 20 лет спустя: краткое резюме

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

  1. Угрозы постоянно эволюционируют – за ними должны эволюционировать и механизмы их обнаружения.
  2. Не существует «серебряной пули» - универсального метода и решения по обнаружению угроз. 
  3. Сравнение систем обнаружения вторжений по числу сигнатур сегодня не отражает ни качества продукта, ни его возможностей, так как, во-первых, число угроз бесконечно, во-вторых, способы создания сигнатур могут быть разные (сигнатура для эксплойта vs сигнатура для использования уязвимости), а, в-третьих, существуют не только сигнатурные методы обнаружения угроз.
  4. Традиционные системы обнаружения вторжений тоже эволюционируют и могут решать вполне конкретные задачи в рамках определенной области применения.
  5. Существует немало способов улучшения сигнатурных методов обнаружения угроз. Для выстраивания современной системы обнаружения угроз необходимо понимать ограничения используемых вами сейчас методов 
  6. Необходимо использовать разный контент обнаружения, не ограниченный только сигнатурами атак, а расширенный индикаторами компрометации, триггерами, правилами, графом взаимосвязей, алгоритмами и т.п.
  7. Контент обнаружения должен применяться к различным источникам данных – сетевому трафику, файлам, URL, активности процессов, логам, API и т.п.
  8. Нельзя полагаться только на один метод обнаружения – необходимо комбинировать различные способы, взаимно дополняющие друг друга.
  9. Обнаруживать угрозы можно не только на стороне заказчика, но и своевременно выявлять их, устанавливая решения по обнаружению на уровне операторов связи, провайдеров услуг или государства (примером последнего являются ГосСОПКА или ФинЦЕРТ).
  10. Современная система обнаружения угроз – это комбинация разного контента и методов обнаружения, различных источников данных, а также мест установки компонентов системы обнаружения угроз.
  11. Помимо процесса обнаружения угроз также должен быть выстроен процесс их поиска (threat hunting), который позволяет подтвердить или опровергнуть сделанные гипотезы о наличие или отсутствии следов компрометации в корпоративной инфраструктуре.
  12. Требования российских регуляторов (ФСТЭК, ФСБ, Банка России и др.) ориентированы только на один из классов средств обнаружения угроз – системы обнаружения вторжений/атак.

4.11.20

От обнаружения атак к обнаружению угроз или что изменилось за последние 20 лет

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

Документы ФСБ по системам обнаружения атак являются закрытыми, а вот отношение ФСТЭК к этой теме вполне публично и ориентируясь на приказ №17, методичку по мерам защиты и РД на СОВ можно сделать следующие выводы. По мнению ФСТЭК

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

Учитывая, что в этом году стукнуло 20 лет, как я написал свою первую книгу, "Обнаружение атак", я подумал, что можно запустить серию публикаций, которые будут направлены на то, чтобы рассказать о том, как отличается обнаружение вторжений конца 90-х и начала 2000-х от того, что происходит в начале 2020-х. И начну я, пожалуй, с чеклиста, который покажет, насколько эффективна ваша система обнаружения угроз.


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

Обратите внимание, что чеклист "бьет" по совершенно различным болевым точкам - от проводной сети до беспроводной, от сетевого уровня до прикладного, от офисной сети до облаков, от IoT/АСУ ТП до контейнеров, от сетевых атак до подброшенных устройств, прослушивающих сетевой трафик, от внутрикорпоративной установки средств обнаружения до установки в Интернет, от обнаружения сигнатур до мониторинга Darknet... Что-то из этого может быть реализовано с помощью приобретенных средств обнаружения, что-то с помощью аутсорсинга, а что-то потребует выстраивания системы обмена информацией с другими организациями. Современная система обнаружения угроз - это гораздо больше, чем все еще необходимая, но явно недостаточная система обнаружения вторжений/атак, которая еще и необязательна по мнению ФСТЭК для информационных систем низкого класса защищенности. Вот об этом мы и будем говорить в следующих заметках, которых, если повезет, наберется на 3-е издание книги "Обнаружение атак" :-)

3.11.20

Регуляторы, ВСЕГЕИ или что такое MDM из ГОСТ 57580.1?

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

Возьмем, к примеру, ГОСТ 57580.1 имени Банка России, в котором, есть раздел 7.9, посвященный базовому составу мер защиты информации при осуществлении удаленного логического доступа с использованием мобильных (переносных) устройств. По сути, данный раздел, посвящен не только смартфонам и планшетам, а вообще любым переносным устройствам, включая и ноутбуки. И вроде бы все меры в этом разделе вполне понятны и реализуемы, если бы не одно но... А именно использование англоязычных аббревиатур для описания средств защиты, которые могут помочь реализовать ту или иную меру по защите. Например, MDM (Mobile Device Management), которые упомянуты в ЗУД.3 и ЗУД.10.

Эта аббревиатура, а равно и MAM, MCM, MSM, MEM, MIM и EMM, исторически была связана только с мобильными устройствами типа смартфон и планшет. Ни к каким других устройствам она не применялась, так как также исторически сложилось, что управление безопасность мобильных устройств отличается от управления безопасностью оконечных устройств (или, как их называет ЦБ: конечных точек) в виде стационарных компьютеров под управлением Windows, Linux, macOS и т.п. И если перед службой ИБ стояла задача защитить смартфоны и планшеты под управлением iOS или Android, то в голове сразу всплывала аббревиатура MDM. Причем надо отметить, что MDM - это управление мобильным устройством, а не обеспечение его безопасности. В контексте ИБ появились аббревиатуры MSM или MDSM, где буква S и означала безопасность (security).

MDM родила и схожие аббревиатуры - MAM (mobile application management), MCM (mobile content management), MIM (mobile information management) и т.д. В 2014-м году главный любитель новых аббревиатур, компания Gartner, ввела в обиход EMM - Enterprise Mobility Management, то есть класс решений, который включал в себя все аббревиатуры, начинающиеся с "M".

Но время шло, производители стали выпускать то, что было сложно относить к одной из четырех привычных категорий - смартфон, планшет, ноутбук, стационарный ПК. Более того, процесс "мобилизации" предприятий пошел так быстро, что классические мобильные устройства стали обладать всем набором ранее присущих только стационарным ПК свойств. Разве, что операционные системы пока использовались разные. Встал вопрос - может быть унифицировать функции управления всеми устройствами, на которых работают пользователи? Так родилась очередная аббревиатура - UEM (Unified Endpoint Management) и все классические игроки рынка MDM (MobileIron, SAP, Samsung, Blackberry, IBM, Citrix, Microsoft, VMware, Cisco и т.п.) стали относить свои решения к UEM, оснастив соответствующим функционалом. В итоге, найти сейчас на рынке классический MDM почти невозможно :-)

Но от экскурса в историю вернемся к стандарту Банка России, который использует именно аббревиатуру MDM. Лично для меня, это не столь существенно и я прекрасно понимаю, что данные раздел ориентирован не только на смартфоны и планшеты, а касается всех типов мобильных устройств, с которых можно осуществить удаленный доступ. Сейчас, во время пандемии и перехода на удаленку, эти устройства могут быть абсолютно любыми, не ограниченными только возможностью запуска на них ОС iOS, Android, "Авроры" или Sailfish. Поэтому для меня упомянутая в ГОСТ 57580.1 аббревиатура MDM не имеет никакого значения и я спокойно заменяю ее на MDSM, MSM, EMM или UEM, так как понимаю, что ГОСТ требует централизованного управления и мониторинга для переносных устройств, независимо от используемой ОС. Это логично. Но...

Недавно, в одном Telegram-канале возникла тема, в которой автор спрашивал, как реализовать ЗУД.3 и ЗУД.10 применительно к ноутбукам с Windows. На очевидный ответ, что ровно также, как и для обычного компа (СЗИ от НСД, EDR/антивирус, разграничение доступа, DLP и другие меры защиты из ГОСТ), последовал ответ, что вот же есть обязанность использовать MDM-решение. На комментарии, что тут важно соблюсти дух ГОСТа, а не буквоедствовать, топикстартер резонно заметил, что это с проверяющими из ЦБ не работает и они будут тупо требовать наличия именно MDM-решения. Не MSM (Mobile Security Management), не EMM, и даже не UEM, а именно MDM. В результате, вместо обсуждения того, как защитить пользовательские устройства на удаленке, дискуссия ушла в споры о том, что надзор можно ткнуть в то, что эта англоязычная аббревиатура вообще нигде не определена и что скрывается за тремя буквами никто не знает. А надо напирать на то, что используется не MDM, а система централизованного управления и мониторинга, под которую уже попадают и решения класса UEM и все остальные. Хотя гарантии, что это пройдет, никто не дает. Проверяющие бывают излишне въедливыми и прямолинейными - написано MDM, подавай MDM.

И ведь сама по себе проблема не стоит и выеденного яйца. Все всё понимают. Но раз уж речь идет о требованиях регулятора, то хотелось бы однозначности трактовок и либо отказа от использования аббревиатур типов защитных средств (достаточно вспомнить историю с аббревиатурами EDR, STAP им EVC, которые означают одно и тоже, только придумано разными аналитическими агентствами), либо их четкого объяснения в том же самом документе. Но лучше, конечно, не использовать такие аббревиатуры вообще.

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

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

ЗЗЫ. Используя какие-либо названия и аббревиатуры в нормативных документах стоит помнить про закон письменной речи Майерса: "Все, что может быть понято неправильно, будет понято неправильно". К терминологии этот закон применим как никакой другой.

2.11.20

Терминологический кризис или полный п...ец

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

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

Возьмем к примеру проект ГОСТа с терминами и определениями по ГосСОПКЕ, который внесли в ТК362 в августе этого года. Я на него писал отзыв и сейчас, спустя два месяца, думаю могу и в блоге повторить свои мысли здесь.

  1. Большая часть терминов не соответствует терминам, уже данным в законодательстве, в том же ФЗ-187. Они зачем-то "адаптированы" в предлагаемом ГОСТе. Возможно, это и обосновано (хотя обоснования не приведено), но это будет вводить еще большую путаницу вместо того, чтобы терминологическую путаницу устранять. А часть терминов не "адаптирована", а просто другая. Например, термин "компьютерная атака" из ФЗ-187 вообще не соответствует проекту ГОСТа (при этом пометки "адаптировано" нет). Часть терминов не соответствует не только НПА ФСТЭК, но и НПА ФСБ.
  2. Часть терминов, повторяющихся в утвержденном, но еще не принятом проекте ГОСТ по мониторингу, также не совпадают по тексту и "адаптированы". Это выглядит еще более странно, так как автор у двух проектов ГОСТов один и тот же. Но ГОСТ по мониторингу, видимо, "велся" "под эгидой" ФСТЭК, а ГОСТ по ГосСОПКЕ - "под эгидой" ФСБ. Необходимо хотя бы на уровне обоих ГОСТов принять единую терминологию.
  3. Часть терминов из п.4.2.2 про источники данных не соответствует терминам из уже принятых профилей защиты ФСТЭК. Например, средство доверенной загрузки. Также по тексту используются термины, которые не используются ФСТЭК, например, "фсбшный" термин "система обнаружения атак" вместо "система обнаружения вторжений".
  4. Часть терминов из п.4.2.3 не соответствуют их смыслу. Например, нормализация - это устранение избыточности, приводящей к ошибкам, а не приведение к единому формату. Корреляция - это поиск зависимостей между случайными событиями, а не просто вид анализа данных. Правило регистрации признаков атак и инцидентов не может быть алгоритмом анализа событий и т.п. При этом в п.4.4.9 для правила регистрации компьютерного инцидента уже другое определение.
  5. Очень много терминов некорректны. Например, бэкдор - это не столько дефект алгоритма, сколько намеренно оставленная уязвимость ПО (про ПО в определении ни слова). А уязвимость "нулевого дня" не всегда трактуется как уязвимость до выпуска патча (есть известные годами уязвимости без патча и их никто не называть "нулевого дня"). Источником атаки (как написано в проекте методики МУ ФСТЭК) может быть не только лицо (то есть антропогенный источник) или инициируемый им процесс, но и техногенный источник. Факт получения ВПО ресурсом не может рассматриваться как распространение ВПО. Нарушение или замедление работы ресурса трактуется как неспособность ресурса выполнять возложенную функцию, но это не так. При замедлении работы ресурса он свою функцию продолжает выполнять.
  6. В терминах используется то "Интернет", то "глобальные компьютерные сети". Также бывает, что подменяются понятия "признак", "критерий" и "индикатор" применительно к атаке и инциденту.
  7. Очень много англицизмов и жаргонизмов, которые слишком буквально переведены на русский язык - "дампер", "плагин", "бэкдор", "руткит", "инсайдер" и т.п.
Причем, это не проблема только ФСТЭК или ФСБ. У других регуляторов схожая проблема. Например, последний, утвержденный 23 октября, стандарт Банка России СТО БР ФАПИ.СЕК-1.6-2020. Там есть такие термины, как "нативное приложение" (ну зачем эти англицизмы?", "агент пользователя" (это, на секундочку, user agent, - зачем тут буквально переводить - смысл же другой), "конечная точка" (это, как вы понимаете, "endpoint")... От этой "конечной точкой" и начинаются "конечная точка клиента" (наверное, точка G) и "конечная точка токена". А чего тогда не перевести "UserInfo endpoint" как "конечную точку информации пользователя"? Почему оставили "конечная точка UserInfo"?

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

И почему нельзя при использовании терминов, посмотреть на уже принятые стандарты с разделами по терминам? Почему термин "атака"из нового СТО БР ФАПИ.СЕК-1.6-2020 отличается от определений из документов ФСБ? И это если не вспоминать упомянутую выше проблему с тем, что в проекте ГОСТа по ГосСОПКЕ этот же термин отличается и от ФЗ-187, и от уже принятых НПА ФСБ. Ну ладно... Я могу понять, когда регуляторы конфликтуют между собой и им недосуг читать документы "конкурентов" и синхронизироваться с ними. Но свои-то документы надо знать? Почему в новом СТО термин "аутентификация" отличается от этого термина в ГОСТ 57580.1? Да, понятно, что его взяли из свежего ГОСТа Р 58833-2020 по идентификации и аутентификации (а могли бы и из ГОСТ Р 53632-2009). Но почему-то не привести и ГОСТ 57580.1 к единому терминологическому аппарату (а там и не только терминологию, но и некоторые формулировки бы утрясти)? Кстати, термин "аутентификация" в ГОСТ 57580.1 взят из РД Гостехкомиссии 1992-года, который, вроде как никто и не отменял официально.

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


29.10.20

Аутсорсинг. Риски информационной безопасности (презентация и видео)

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

Видео моего выступления:

А также сама презентация:

28.10.20

Чеклист организации, выстраивающей стратегию безопасного удаленного доступа (презентация и видео)

На прошлой неделе мне посчастливилось поучаствовать в конференции GIS Days 2020, которая проходила целиком онлайн, но по уже становящейся традиции спикеров пригласили выступать в специально оборудованный павильон. Сейчас уже немодно читать из дома или из офиса - организаторы понимают, что слушатели устали от бесконечных вебинаров и онлайн-конференции, которые похожи друг на друга как близнецы. Один из способ выделиться на фоне других - попробовать уйти от набившего оскомину формата Zoom или Webinar.ru и дать слушателям что-то иное - профессиональных ведущих, задающих нужные вопросы спикерам, красивую картинку, возможность задавать вопросы в чате и т.п.

И вот компания Газинформсервис, которая ежегодно проводит свою конференцию GIS Days, в этом году решила попробовать себя в новом формате, и перестроила под себя один из павильонов Ленфильма, в котором снимались такие шедевры отечественного кинематографа как "Особенности национальной охоты", "Гений", "Собачье сердце", "Приключения Шерлока Холмса и Доктора Ватсона", "Трое в лодке, не считая собаки", "Труффальдино из Бергамо" и многие другие.

И вот еще один эксперимент - на этот раз "сериал" про информационную безопасность. Целых 11 часов онлайн-трансляции, 42 актера спикера. Весь "сериал" был посвящен новой реальности; так называют удаленку и вызовы ИБ, которые с ней связаны. Кто-то считает, что эта тема уже набила оскомину и в ней нет ничего нового. Но мне кажется, что это не так. Первую волну пандемии многие пережили в авральном режиме и использовании триальных лицензий, предоставленных вендорами. Сегодня настало время выстраивать полноценную стратегию организации удаленного доступа, какой бы она не была, - с помощью прямого доступа к корпоративным приложениям, с помощью VDI или RDP, с помощью DaaS или иных облачных сервисов.

Вот про чеклист такой стратегии я в рамках GIS Days 2020 и рассказывал. Ниже можно посмотреть видео моего доклада. Я не знаю, откроется ли ссылка ровно на моем докладе, но если что, то смотреть с временной отметки 01:17:15. Моя сцена в этом эпическом фильме заняла всего 20 минут, но если вы хотите посмотреть и другие сюжеты и актеров, то переходите по ссылке выше и вы сможете удовлетворить свое любопытство киномана. 


Презентацию я также выложил на Slideshare - вроде доступ к нему уже не блокируется. Понятно, что это высокоуровневый обзор, в котором указаны только темы, требующие внимания при переходе на удаленку. Если вам интересны детали, то могу посоветовать серию своих статей, которая продолжает публиковаться в питерском издании "ИТ-Менеджер" (уже опубликованы часть 1 и 2). На подходе еще пара завершающих серию статей, раскрывающих детально чеклист, который я привел на конференции GIS Days 2020.


Вообще надо отметить, что уровень онлайн-конференций за последние полгода только вырос и это не может не радовать. Организаторы и спикеры научились держать аудиторию не только качественным контентом, но и иными фишками, многие из которых можно увидеть на GIS Days 2020, организованном "Газинформсервисом", за что им большое спасибо, как и за приглашение меня в качестве спикера.

27.10.20

Презентация ИБ для руководства (видео с CISO Forum)

Продолжим вчерашнюю тему про дашборды для руководства, но выйдем за рамки темы АСУ ТП. Сегодня я выложил видеозапись своего выступления (оно вдвое длиннее, чем на Kaspersky ICS Security Conference) с CISO Forum, прошедшем в этом сентябре, в рамках которого я вновь коснулся темы дашбордов, но уже в более расширенном варианте. 


Презентацию этого выступления я уже выкладывал

26.10.20

Создание дашбордов по ИБ АСУ ТП, понятных руководство (видео)

В начале сентября, первым моим очным мероприятием стала конференция Лаборатории Касперского Kaspersky ICS Security Conference, где я выступил на тему дашбордов по ИБ АСУ ТП. Свою презентацию я выкладывал раньше, а сейчас подошло время и для видеозаписи.


Это мое выступление по сути продолжает прошлогоднее, в котором я рассказывал про измерение эффективности ИБ АСУ ТП. Поэтому я дам ссылку еще и на него, чтобы можно было сложить А и Б, то, что мы измеряем, и то, как мы это визуализируем. Оказалось, что я видео этого выступления в блоге не выкладывал, так что исправляюсь.



ЗЫ. Остальные видеозаписи с Kaspersky ICS Security Conference 2020 можно посмотреть в плейлисте на Youtube (постепенно туда выкладывают обработанные записи докладов).

12.10.20

5 целей сбора персданных в рамках нового указа мэра столицы

Зарекся писать про тему прав субъектов персональных данных и законодательство про это, так как не только перестал понимать логику его авторов, но и потому что исполнительная власть давно и успешно положила болт на это законодательство и комментировать его действия сложно. Вот про техническую защиту персональных данных пишу и рассказываю - там все чуть проще и понятнее. В мае вот выступал на GDPR Day с рассказом про защитные меры по ФЗ-152 и GDPR. На днях доделал документ по мотивам этой презентации, где в сжатой форме попробовал собрать все ключевые вещи, связанные с технической защитой персональных данных. Но тут Михаил Юрьевич задался сакраментальным вопросом, а зачем мэрия собирает ПДн работников, переведенных на удаленку. И так как он рассмотрел, на мой взгляд, не все возможные причины сбора этих данных, то позволю себе продолжить его заметку и пофантазировать.

Я вижу 5 причин (целей, в терминах ФЗ-152), зачем мэрия это делает. Причина первая - самая очевидная. В мэрии работают недалекие люди, с полностью отсутствующим критическим мышлением, незнанием законодательства; этакие винтики, которые в меру своего понимания делают то, что им устно кто-то приказал, услышав такое же устное распоряжение еще от кого-то сверху и так по цепочке. Чиновники мэрии превратились в собак из опытов Селигмана (я про них писал в контексте ИБ), потеряв всю инициативу и желание сделать что-то по уму.

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

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

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

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

Вот такая конспирология... 

Интерфейс загрузки ПДн удаленщиков... Опять не работает (фото Циникса из телеги)


7.10.20

О необходимости регулярного пересмотра метрик в SOC

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

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


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

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

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

6.10.20

Новое Положение Банка России 719-П. Вопросов больше, чем ответов...

На днях Минюст зарегистрировал новое Положение Банка России 719-П, которое пришло на смену 382-П. У него есть несколько отличий от отменяемого с 1-го января 2022-го года 382-П:

  • Расширен перечень лиц, на которых распространяется 719-П. Теперь это не только операторы по переводу денежных средств, операторы услуг платежной инфраструктуры, операторы платежных систем и банковские платежные агенты и субагенты, но и операторы услуг информационного обмена и поставщики платежных приложений, для которых прописаны требования по защите информации.
  • Технические требования по защите теперь прописаны в ГОСТ 57580.1, а не в самом Положении как раньше (хотя часть требований остались в самом Положении).
  • Операторов по переводу денежных средств обязали выполнять 683-П (как будто они могли отказаться?).
  • Оценка соответствия проводится по ГОСТ 57580.2.
  • Операторы по переводу денежных средств обязаны провести сертификацию прикладного программного обеспечения автоматизированных систем и приложений (будем считать, что это, что было в устных разъяснениях ДИБ в связи с выходом профиля защиты) по уровню доверия не ниже 5-го, а для значимых и системно значимых кредитных организаций - не ниже 4-го уровня.
  • Добавили жесткие требования к банковским платежных агентам и субагентам (ГОСТ 57580.1 и много чего еще, вплоть до сертификации ПО на 6-й уровень доверия).
  • Добавили необходимость вычисления значения показателя, характеризующего уровень переводов денежных средств без согласия клиента, формируемого на ежеквартальной основе
  • Добавили обязанность подтверждать принадлежность клиентам e-mail, на которые отправляются выписки и подтверждения перевода денежных средств. 
Это не все, что я бы отметил. Недавно ЦБ выложил проект изменений в 683-П, в котором было сделано пару небольших, но важных изменений. Во-первых, к сертификации банковского ПО добавили еще и оценку соответствия (без уточнений). В 719-П этого нет - там "древняя" формулировка про оценку соответствия по ОУД4, которую уже и непонятно как выполнять. Как мы помним, просто сертификацию в ФСТЭК для такого ПО будет выполнить невозможно, а ОУД4... тоже. В итоге тупик. Во-вторых, в проекте изменений  683-П "лицензиат ФСТЭК" был заменен на "проверяющую организацию", а в 719-П старое требование про лицензиатов. В-третьих, в проекте нового 683-П допускается самостоятельная оценка соответствия банковского ПО, а в 719-П - нет. Учитывая, что 683-П и 719-П не только очень сильно пересекаются по сферам применения, но операторы по переводу денежных просто обязаны выполнять их оба, то как разруливвать эти коллизии (в случае принятия поправок в 683-П) не совсем понятно.

Вообще, иногда кажется, что в ЦБ выпуская новые нормативные акты, немного забывают про то, что уже было выпущено ранее. Я тут попробовал оценить сферы применения 382-П, 683-П, 719-П и 672-П и понял, что они очень сильно перекрываются даже по формальным признакам. 


А если брать в расчет практику надзора, когда проверяющий может вытащить операционистку на ресепшн и попросить подключиться к АБС, что по мнению проверяющих означает, что и компьютер на ресепшн попадает в область действия тех же 683-П и 719-П/382-П. А были ведь еще истории, когда таким образом и 672-П/552-П распространяли на весь банк, а не только на сегмент, прямо подключенный к платежной системе Банка России. В общем я вроде и в теме немного, но даже я уже перестал понимать, что делает ЦБ в части регулирования вопросов ИБ и в части соотнесения между собой своих же нормативных актов и почему они не могут синхронизировать их требования между собой, а также четко разнести их сферы действия.

5.10.20

Кому нужно квантовое шифрование?

За последнее время 8-й Центр ФСБ объявил госзакупок по теме квантового распределения ключей на сумму более 200 миллионов рублей. И уже достаточно активно стали появляться различные новости о том, что то одна, то другая российская компания (преимущественно из финансового сектора) вместе с каким-либо из российских разработчиков СКЗИ, запустили прототип системы квантового шифрования. Если чуть погрузиться в детали, то речь идет не совсем о шифровании, сколько о квантовом распределении ключей, но не суть. Меня во всей этой истории интересует именно практическая сторона дела. И вот с ней все не так просто.

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

Почти все исследователи сходятся в мнении, что применение на практике (если не рассматривать вариант замкнутой системы в пределах одного города и его окрестностей) квантового шифрования вызывает вопросы и с точки зрения длины квантового канала, и с точки зрения скорости передачи данных (единицы мегабит в секунду). В отличие от квантовых компьютеров, которых работающих пока нет, но которые как раз могут иметь более приземленное применение в части ускорения криптоанализа большей части асимметричной криптографии, которая может превратиться в тыкву в случае появления действительно работающих квантовых компьютеров (эксперты называет срок их появления в 2027 году). Поэтому гораздо активнее многие крупные компании развивают направление так называемой постквантовой криптографии, которая будет устойчивой к атакам со стороны квантовых компьютеров. Этой же темой занимается и 8-й Центр ФСБ, который на последнем PKI Forum / CTCrypt, анонсировал направления, в котором они работают. Правда, открытых НИРов в этой области они не анонсируют, но и приведенных на слайде алгоритмов достаточно.    


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

16.9.20

Про обязательную сертификацию для всех без исключения значимых объектов КИИ

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

Одно из них - расширение запрета на использование элементов значимого объекта КИИ не только 1-й, но уже и 2-й категорией. Прощай Zoom, облака и сервера обновлений, расположенные за пределами Российской Федерации. Ну да и ладно. Зачем значимым объектам КИИ обновление? Не нужно оно. Хотя допускаю, что регулятор не рассматривает сервера обновлений как угрозу для ОКИИ и не включает их в контур контроля. Ну тем лучше.

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

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

Можно ли получить данную методику и требования по доверию посторонним лицам? Согласно требованиям ФСТЭК, они "предназначены для организаций, осуществляющих в соответствии с законодательством Российской Федерации работы по созданию средств, заявителей на осуществление сертификации, а также для испытательных лабораторий и органов по сертификации, выполняющих работы по сертификации средств на соответствие обязательным требованиям по безопасности информации". Учитывая курс ФСТЭК на засекречивание всего и вся, боюсь, что обычный субъект КИИ, владеющий значимыми объектами КИИ, получить их не сможет. И даже если у него есть лицензия ФСТЭК на ТЗКИ или разработку СрЗИ, тоже. А откуда у районной поликлиники или транспортной компании такая лицензия? Вот и получается, что своими силами провести такую оценку будет очень проблематично. Я уже не говорю, про отсутствие у субъектов КИИ специалистов, способных провести такой анализ. Да и вообще, эти требования в принципе не способен выполнить субъект КИИ, как бы он не хотел, так как они рассчитаны либо на разработчиков средств защиты, имеющих весь пакет документации и исходных кодов на свою продукцию, либо на лиц, которым они доверили ее анализ. Субъекты КИИ, до свидания!.. 


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

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

  • Значит ли, что уже сейчас нельзя устанавливать на ЗОКИИ средства защиты, прошедшие оценку соответствия в форме испытаний или приемки, но без уровней доверия? Или запрет вступает в силу именно в 2023-м году? 
  • Если я сейчас внедрю (или они уже внедрены) такие средства защиты, то 2-го января 2023-го года мне надо от них отказываться или все-таки закон не имеет обратной силы?
  • Если закон обратной силы не имеет, то можно ли мне после 1-го января 2023-го года обновлять средства защиты или это уже будет считаться модернизацией ЗОКИИ, а значит, как написано в приказе, надо будет уже проводить оценку по 6-му уровню доверия?
  • А если сейчас идет проектирование системы и в ТЗ таких требований не было, то что делать? Будет ли отсрочка?
  • Если у меня инвестпрограмма рассчитана на 3 года и в нее уже внесены средства защиты без оценки по 6-му уровню доверия, то что делать в таком случае? Бюджет уже заложен и часто это бюджет государственный.
  • Закупка обновлений средств защиты без 6-го уровня доверия не будет ли рассматриваться для госкомпаний или госорганов, как нецелевое расходование средств со всеми вытекающими последствиями? 
  • Как будет трактоваться отсутствие 6-го уровня доверия при проведении проверок ФСТЭК (если средство защиты было внедрено до 1-го января 2023-го года)? 
Вопросы, конечно, риторические. Авторы приказа явно не думали о них, когда готовили свой документ. Даже информационного сообщения никакого на сайте не опубликовали с разъяснениями. Видимо, не досуг.

Кстати, еще пример, как ФСТЭК подходит к своим документам. 12-го августа регулятор утвердил список документов, необходимых лицензиатам для выполнения работ по ТЗКИ, включая и тематику КИИ. В этом перечне присутствуют и 17-й, и 21-й приказы, и методичка по защитным мерам, и даже ДСПшная методика моделирования угроз ПДн 2008-го года, на смену которой скоро придет новая методика моделирования угроз ФСТЭК. Чего в этом перечне нет, так это 235-го и 239-го приказов по КИИ. То есть строить защиту субъектам КИИ лицензиат может, а вот документы, устанавливающие требования к этой защите, лицензиату иметь необязательно. В - Внимательность...