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

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

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

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

Аутсорсинг. Управление рисками информационной безопасности from Aleksey Lukatskiy

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

На прошлой неделе мне посчастливилось поучаствовать в конференции 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О необходимости регулярного пересмотра метрик в 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, число разосланных аналитиками фишинговых сообщений и т.п., то они начнут давать сбой (при общем повышении эффективности защиты) и их придется пересматривать.

Новое Положение Банка России 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-П распространяли на весь банк, а не только на сегмент, прямо подключенный к платежной системе Банка России. В общем я вроде и в теме немного, но даже я уже перестал понимать, что делает ЦБ в части регулирования вопросов ИБ и в части соотнесения между собой своих же нормативных актов и почему они не могут синхронизировать их требования между собой, а также четко разнести их сферы действия.

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

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

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

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

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