Как может s-curve'иться CISO?

Последний круглый стол на конференции “Кибербезопасность нового времени” в рамках казанской DigitalWeek оказался мне ближе всех, так как обсуждаемая на нем тема интересует меня давно и мой блог по сути и начинался скоро уже 15 лет как именно с нее, а именно с бизнес-ориентации в деятельности службы ИБ. Это постоянная тема дискуссий последних пару лет и без нее не обходится ни одно мероприятие. Должен ли CISO заниматься только ИБ в классическом его понимании (борьба с угрозами и выполнение требований регуляторов) или ИБ - это более широкая тема и CISO может и должен выходить за привычный, но достаточно узкий мир нарушителей и compliance. В этой дискуссии, так уж случилось, участвовали только представители финансовой отрасли:

• Яшкин Вячеслав - Управляющий директор Аппарата Правления ПАО «АК БАРС» БАНК
• Титков Константин, Исполнительный директор Департамента защиты информации Газпромбанк
• Демидов Сергей - Директор департамента операционных рисков, информационной безопасности и непрерывности бизнеса, Московская биржа
• Волков Олег, начальник Департамента кибербезопасности ПАО "Банк ЗЕНИТ".

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

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

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

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

Если не заработок, то может ли ИБ влиять на прибыль компании? Надо отметить, что не слишком подкованные в финансах технари, часто путают прибыль и доход. Да, ИБ может не приносить дохода, но при этом влиять на снижение расходов, тем самым увеличивая прибыль предприятия. И дело не только и не столько в том, чтобы снижать стоимость инцидентов или предотвращать мошенничество, о чем мы тоже говорили. Например, можно существенно снизить затраты компании на отправку одноразовых кодов по SMS для входа в систему ДБО, если подумать о том, как обычно клиенты подключаются к своему онлайн-банкингу. Делается это обычно с одного и того же мобильного устройства, которое не меняется годами. Так зачем каждый раз спрашивать клиента “Это ты?”, если можно профилировать его устройство и в случае совпадения с профилем, считать устройство доверенным и не отвлекать пользователя смсками? Такой подход позволяет сократить 10-40% затрат на отправку SMS, что выливается при текущих расценках в кругленькую сумму. Заработок ли это? Нет. Влияет ли на прибыль? Безусловно. Интересно это бизнесу? Конечно. Об этом кейсе, кстати, можно послушать в "свежевыжатом подкасте", приуроченном к грядущему SOC Forum 2021, в котором моим гостем был Лев Шумский, глава кибербеза Яндекс.Банка (подкаст №2). 

Но такая ориентация на бизнес требует от CISO новых навыков. Как было правильно отмечено на круглом столе - CISO может быть “военным” или “предпринимателем”. В первом случае он может отлично выполнять традиционные для ИБ задачи, но не выходить за их рамки. Во втором случае он ищет как помочь бизнесу с позиций предпринимателя. И у него это получается. И тогда у него появляется шанс вырасти за пределы обычного руководителя ИБ, “подмяв” под себя управление операционными рисками, непрерывность бизнеса, операционную надежность. Сергей Демидов упомянул концепцию S-кривых, которая описывает эволюцию многих технологий, многих компаний и даже людей. Сначала вы растете в своей роли, но в какой-то момент достигаете пика в развитии и у вас начинается движение по длительному плато, которое может в любой момент прерваться, так как вас обойдут более агрессивные, опытные, квалифицированные коллеги. Чтобы расти дальше вам надо выйти за пределы своей роли и сделать шаг в неизвестность, который может вывести вас на новый уровень, на новую кривую. И так далее. Для ибешника это означает, что он может начать свою карьеру как обычный сотрудник отдела защиты информации, занимаясь своей узкой сферой, развиваясь в ней. Следующим кардинально новым шагом может стать желание быть руководителем, что требует новых навыков и знаний. Проработав в этой роли, CISO может захотеть пойти еще выше и тут варианты его карьеры могут разойтись. Он может пойти в корпоративную безопасность, подмяв под себя темы экономической, физической, антитеррористической безопасности. А может пойти в сторону рисков и непрерывности бизнеса. И это очередной вызов, требующий новых знаний и навыков. А потом это может быть собственный бизнес и т.д.

На круглом столе мы обсуждали еще многие темы, но я не хочу пересказывать абсолютно все и не буду раскрывать секрет, как связана деятельность CISO с движением Black Lives Matter или концепцией ответственного инвестирования ESG, о которой сегодня не говорит только ленивый и которая вроде как не имеет никакого отношения к ИБ, но оказывается, что имеет. А ESG - это повестка дня руководителей крупнейших мировых компаний. И если CISO может встроиться в эту повестку, то это отлично. Но об этом вы можете сами услышать, посмотрев эфир, любезно записанный компанией Innostage, которая и организовала этот и другие два круглых стола, которые я вел, ссылки на записи которых ниже, и о которых я писал последние заметки:

• Запись первого круглого стола, о котором я писал
• Запись второго круглого стола, о котором я писал
• Запись третьего круглого стола, о котором данная заметка.

Подробнее…

TARA - методология моделирования угроз и защитных мер от MITRE

В последнее время меня никак не отпускает тема моделирования угроз, что закономерно. Это один из последних документов регуляторов и по нему возникает немало вопросов. Но сегодня я буду писать не об этом. Сегодня я хотел бы подвести итог и завершить серию заметок, начатую во вторник. В них я описал подходы к ранжированию угроз/техник и мер защиты, список которых мы формируем в рамках моделирования угроз. Вчера я обещал назвать методику оценки негативных событий, в которой используются эти подходы. Речь идет о TARA - Threat Assessment & Remediation Analysis, методике, предложенной корпорацией MITRE еще в 2011-м году.

Методология TARA включает в себя три активности - анализ угроз (Cyber Threat Susceptibility Analysis), анализ защитных мер (Cyber Risk Remediation Analysis) и разработку данных и инструментов. Идеологически, методология TARA очень сильно похожа на то, что описано в методике оценки угроз ФСТЭК, но есть ряд нюансов, которые и отличают эти два подхода; причем существенно.  

Я не буду подробно расписывать всю методику - все-таки 60 страниц лучше прочитать самостоятельно. Коснусь только ключевых моментов, которые и отличают TARA от методики, предложенной ФСТЭК:

1. Методика не является обятельной к применению. Право ее выбора лежит на потребителе.
2. TARA не ссылается на матрицу техник и тактик MITRE ATT&CK (ее еще тогда просто не было), но само понятие TTP в методике TARA присутствует ровно в том же контексте, что и в ATT&CK. В последующих версиях TARA это понятие немного трансформировалось в вектора атак, то есть последовательность действий, которые злоумышленник осуществляет для достижения своей цели, но суть опять же не поменялась.
   
   
   
   
   
3. Указанные вектора атак объединяются в группы, которые могут быть классифицированы по разному. Обратите внимание, в конструкторе есть и группа техник MITRE ATT&CK и собственные варианты систематизации векторов атак. Например, у меня может быть группа векторов "аутентификация пользователя по паролю", а вектора, входящие в нее, - атаки по словарю, перебор паролей, радужные таблицы и т.п.
   
   
   
   
   
4. Методика начинается с инвентаризации и оценки защищаемых активов, которая может быть выполнена как самостоятельно, так и с помощью другой методологии MITRE - CJA (Crown Jewels Analysis). При этом TARA не требует описания активов вплоть до интерфейсов и уровней, как это описано у ФСТЭК. Все чуть проще - Web-сервер, браузер, СУБД, приложение e-mail, коммутатор, УПАТС и т.п. Но при необходимости можно и углубиться в детали, если такая задача стоит. Например, сам каталог возможных активов достаточно обширен с точки зрения описываемых атакуемых объектов.
   
   
   
   
   
5. Методика очень сильно завязана на так называемые каталоги, которые и содержат уже скрупулезно собранные и систематизированные техники и тактики угроз, вектора атак, защитные меры, активы и т.п. Эти каталоги позволяют легко автоматизировать процедуру моделирования угроз. Модель данных этих каталогов выглядит следующим образом:
   
   
   
   
   
6. Наличие в каталогах данных как из открытых, так и закрытых источников. В зависимости от оцениваемого объекта такое деление позволяет использовать более широкий круг источников данных, в том числе и грифованных, для оценки возможных векторов атак и негативных последствий от их использования. Из открытых источников TARA использует CAPEC, CWE, CVE. 
7. Скоринговая оценка угроз и защитных мер, описанных в трех предыдущих заметках. При этом рейтинг угрозы оценивается для разных типов нарушителей, коих TARA выделяет всего три - внешний, внутренний и привилегированный внутренний. Я не разделяю позицию, что нарушителей надо делать на внешних и внутренних, но в 2011-м году такой подход мог быть вполне разумным. Сейчас я бы отталкивался от другой классификации нарушителей, но идею по разному ранжировать угрозы, в зависимости от того, кто их реализует, я вполне поддерживаю. Вот как это выглядит в оригинальной методике TARA.
   
   
   
   
   
8. TARA предлагает нейтрализовывать не все актуальные угрозы, а согласно их рейтингу. Другой предлагаемой стратегией является нейтрализация угроз, в зависимости от важности актива. 
9. В первоначальной версии TARA все защитные меры оценивались не по трем типам эффекта (предотвращение, обнаружение и реагирование), которые я описал вчера, а по 4-м - нейтрализация угрозы, ее обнаружение, ее ограничение и восстановление после нее. Но после появления фреймворка NIST CSF подход немного изменили.
10. Итогом моделирования угроз по TARA было составление оптимального перечня защитных мер, которые обеспечивали бы эффективную защиту от угроз/техник с минимальными затратами на внедрение и эксплуатацию.
11. Автоматизация оценки, которая заключается в том, что все каталоги и интерфейсы для моделирования размещены в инфраструктуре MITRE, что позволяет не только обеспечить конфиденциальность проводимой оценки, но и ускорить процесс моделирования в разы по сравнению с самостоятельной разработкой инструментария для оценки.
12. Интересно, что уже в 2011-м году среди угроз, которые могли быть проанализированы TARA, предусматривались не только киберугрозы, но и угрозы воздействия по техническим каналам, а также угрозы цепочке поставок.
13. Упомянутые в начале заметки инструменты позволяют как создавать новые записи в каталогах, так и импортировать/экспортировать их их/во внешние системы в формате XML, искать в каталогах, а также генерить различные отчеты. Например, вот так выглядят интерфейсы создания новой техники реализации угроз, новой защитной меры и маппинг защищаемого актива в техники реализации угроз.
    
    

    

    Описание угрозы

    
    

    

    Описание защитной меры

    
    

    

    Маппинг актива в угрозы

    
    
14. Если первые версии TARA не фокусировались на нарушителях, то текущая версия уделяет этому вопросу немало внимания, требуя составить профиль нарушителя, который базируется на трех ключевых элментах - мотивация (зачем кому-то вас атаковать), цели (разведка, утечка, кража, удар по репутации и т.п.) и возможности для реализации угроз. Все эти параметры нарушителей могут меняться с течением времени, поэтому процесс составления "модели нарушителя" не статический и не одноразовый, а динамичный, требующий автоматизации.
15. Еще одним важным, и ранее отсутствующим элементом TARA, является определение поверхности атаки, которая определена как последовательность шагов нарушителя для достижения атакуемого объекта из точки входа. Понятно, что при одной точке входа и объекте атаки путей между ними может быть несколько. Также очевидно, что из одной точки входа можно попасть в множество целей, одну цель можно достичь из разных точек входа, а также что цель в случае ее компрометации может стать точкой входа для дальнейших атак. Точками входа по TARA могут быть запросы к полям баз данных, USB-порты, пользовательские учетные записи, вложения в e-mail и загружаемые из Интернет файлы, временные сетевые соединения, процессы обновления системы и т.п. В каталогах TARA многие из векторов атак, обеспечивающих переход из точки входа в точку назначения, уже прописаны и их надо просто выбирать из готового списка. Авторы TARA говорят, что более 25 векторов атак оценивать достаточно сложно. 
16. Опираясь на описанные выше данные, мы составляем список сценариев реализации угрозы, которые в отличие от векторов атак и их групп, дополнены контекстом для лучшего понимания актуальных угроз. В отличие от методики ФСТЭК TARA не требует перебора всех возможных сценариев, привязанных к техникам и тактикам.
    
    
    

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

Подробнее…

Выбор защитных мер: финальный подсчет рейтинга

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

Мы видим, что мера 1 "закрывает" 5 угроз, 6-я и последняя мера - по 3, а остальные по 2 угрозы. Выбор в пользу первой меры не вызывает вопросов - с ее помощью мы сможем нейтрализовать большее число угроз. Но у данного подхода, несмотря на его очевидные преимущества, есть и один недостаток. Он не учитывает эффект, которого достигает защитная мера. Если вспомнить NIST Cybersecurity Framework, то все защитные меры там разделены на 5 блоков - идентификация, предотвращение, обнаружение, реагирование и восстановление. Это и есть эффекты защиты, которые, для упрощения (если функцию восстановления отдать в ИТ, а функцию идентификацию реализовывать по любому), можно свести к трем:

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

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

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

• Высокий. Эффект защитной меры подтвержден демонстрацией, сертификацией, тестами, пилотом и т.п.
• Средний. Оценка эффекта защитной меры базируется на предположении эксперта.
• Низкий. Эффект имеет правдоподобную картину, но еще никак не подтвержден.

В итоге, если мы объединим эффект защитной меры с его уровнем и поместим в матрицу, то мы получим следующий вариант (P, D и R означают эффект - prevention, detection и response, а H, M и L - уровень - High, Medium и Low):

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

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

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

Подробнее…

Ранжирование защитных мер: практичный подход

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

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

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

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

Подробнее…

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

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

Подробнее…

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

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

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

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

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

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

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

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

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

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

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

Вот такая картина сегодня вырисовывается, когда мы говорим об эффективном обнаружении угроз. За прошедшие 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.

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

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

Подробнее…

Опыт обучения на курсах по SOCам

Упомянул вчера про прохождение курса по SOCам (для тех, кто думает, что SoC - это System-on-Chip, сообщаю, что это Security Operations Center) и хочу поделиться некоторыми впечатлениями. Начну с того, что когда речь заходит об обучении по SOCам, нет ни одного курса, который бы закрыл все потребности в этой части, как нет человека, который в SOC занимается всеми направлениями - от мониторинга до реагирования, от threat hunting до threat intelligence, от проектирования архитектуры до формирования плана обучения аналитиков. Это все разные задачи, которыми занимаются разные роли внутри SOC. Поэтому и обучение тут нужно разное. Одним нужны курсы по Threat Hunting, другим по реагированию на инциденты, третьим по организации Red Team (если это часть сервисной модели SOC), четвертым - по планированию и проектированию SOC. Я про это уже и писал и выступал, но посчитал нелишним упомянуть еще раз. Так вот сейчас я бы хотел поделиться впечатлением о курсе именно про планирование и проектирование SOC, который ориентирован больше не на аналитиков по мониторингу ИБ (типа CompTIA Cybersecurity Analyst, о прохождении которого я уже писал, или Cisco CyberOps Professional), а на руководителей центров мониторинга или их аудиторов и проектантов (проектировщиков). Ну а так как я в последнее время глубоко погружен в эту тему и участвую в разных проектах по аудиту или проектированию SOCов, то я и решил, что надо систематизировать свои знания по этой теме.

Хочу отметить, что курсы по проектированию SOCов я нашел только у SANS. Первоначально это был пятидневный курс SANS MGT517, который разработал и вел Chris Cowley. Позже, причина до сих пор непонятна, MGT517 был закрыт SANS'ом и долгое время никаких специализированных курсов по SOCам не было, пока в прошлом году Крис не анонсировал собственный трехдневный курс по SOCам (его я и проходил недавно), а SANS не запустил двухдневный курс MGT551 имени Джона Хаббарда. MGT551, по словам его автора, является дополнением к его же курсу SEC450 по Blue Team и позволяет дополнить картину уже с высоты птичьего полета, с точки зрения менеджера SOC. Курс Криса по-прежнему ориентирован только на руководителей/аудиторов/проектантов SOC и не является дополнением к чему бы-то ни было. У SANS есть еще шестидневный курс SEC511 по непрерывному мониторингу и SecOps, но он схож с упомянутыми выше курсами CompTIA и Cisco CyberOps, то есть ориентирован именно на специалистов по мониторингу ИБ, чем на лидеров.

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

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

Очень много времени уделяется вопросу выбора и обоснования. Например, как обосновать необходимость SOC руководству компании, какие доводы использовать, каким ролям CxO важны какие задачи SOC и т.п.

С выбором связана и тема смен в SOCах. Крис давал различные модели и описывал их плюсы и минусы. Полезная тема с точки зрения планирования работ персонала и определения численности сотрудников SOC.  

Фанатам технологий тоже было уделено внимание, но не с точки зрения лабораторных работ по конкретным платформам и инструментам, а с точки зрения их выбора. например, какие альтернативы есть для защиты коммуникаций в SOC, для TI, для SOAR, для SIEM и т.п. Причем они сравниваются по разным параметрам (цена, функциональность и т.п.), что дает возможность слушателям потом выбирать то, что лучше подходит под их задачи. Никаких "купите QRadar как SIEM" или "только Webex Teams может быть использован для коммуникаций внутри SOC".

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

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

Хороший раздел про разработку use case. Причем не только с точки зрения теории, но и практики.

Например, выдали табличку с кучей готовых use cases с их разбиением по L1-L3, привязкой к матрице MITRE ATT&CK, метриками и оценкой их эффективности. Полезная штука - мы в рамках наших проектов по SOC тоже используем схожую табличку в Excel, куда заносятся все Use Case, которые мы разрабатываем и с которыми потом можно работать, а не просто теоретизировать. 

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

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

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

ЗЫ. Вроде как Крис упоминал, что ему тоже не очень понравилась идея онлайн-курса по SOC и, возможно, больше таких не будет, - останутся только очные мероприятия, что увеличит цену на них, минимум, вдвое (за счет билетов и проживания). И это не считая сложностей с командировкой за пределы страны (сам Крис из США, но иногда проводит курсы в Европе, куда попасть сейчас непросто).

Подробнее…

Смена приоритетов ИБ как следствие коронавируса

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

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

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

а также обновить график реализации своих проектов в условиях удаленки, изменения приоритетов и, возможного, сокращения бюджетов: 

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

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

• EDR, которые позволяют не только обнаруживать неизвестное вредоносное ПО, но и проводить расследование, в том числе удаленное (антивирусы выкиньте в топку - это бессмысленная трата денег).
• ПО для защиты мобильных устройств (если у вас есть такие пользователи, которые работают с планшетов и, возможно, со смартфонов). Не забудьте про безопасность SmartTV (хотя защитного софта для них вроде и нет), так как бывает, что сотрудники ставят на SmartTV ПО для проведения телеконференций и с них ведут конфиденциальные переговоры.
• Zero Trust. Это целый пласт решений (писал про них тут и тут), который при удаленной работе становится очень важным, так как ваши удаленные пользователи уже не защищены корпоративными и ведомственными средствами защиты и остаются один на один с киберугрозами. Если вдруг вам интересно, как киберпреступники используют тему коронавируса в своей деятельности, то на Хабре я написал две статьи об этом - тут и тут.
• Мониторинг DNS. Учитывая, что сотрудники могут работать с личных устройств и их могут легко затроянить, стоит посмотреть в сторону сервисов по мониторингу DNS, которые позволяют без установки ПО на компьютер, мониторить доступ к фишинговым сайтам, блокировать работу ботнетов и обращение к C&C-серверам. Простенько и  прозрачно для пользователя.
• Многофакторная аутентификация (MFA). Ну тут вроде и так все понятно. Учитывая, что в 81% инцидентов задействованы были украденные или подобранные учетки, то доверять обычным паролям сегодня нельзя. А при удаленной работе тем более.
• Повышение осведомленности и фишинговые симуляции. Если вы прошли по последним двум ссылкам (на два абзаца выше), то увидели примеры фишинговых атак, которые сейчас популярны у киберпреступников. Пользователей, которые не сидят в офисе, и предоставлены сами себе, будут чаще попадать на удочку мошенников, чем раньше. Стоит их обучать тому, как выявлять подозрительные письма, сайты и ссылки, и что делать, если они с ними столкнутся. 
• UEBA. Это из серии "неплохо бы", так как существенно возрастают риски неправомерных действий со стороны сотрудников, как с их ведома, так и без оного. Но можно и просто правильно настроить существующие средства мониторинга (те же NTA, SIEM и др.).

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

Также не стоит забывать, что многие производители сейчас выдают лицензии на свои продукты бесплатно, но не навсегда, а на определенное время. У кого-то 45, у кого-то 60, у кого-то 90 или 180 дней, которые пролетят очень быстро. Особенно если наш гарант в очередной раз, вспомнив про половцев и печенегов, не продлит, наплевав на Конституцию, Трудовой Кодекс, закон о ЧС и эпидемиологическом благополучии населения,  режим самоизоляции. И тогда надо думать, как продлять полученные разные лицензии. Кто-то из производителей может и продлит, а кому-то это не позволят сделать финансовые контроллеры и надо будет оплачивать лицензии.

Стартапам от ИБ будет тяжело (а им так тяжело в России, так как отечественные требования по ИБ не дают возможности малым компаниям развиваться и находить заказчиков), так как CISO в текущих условиях будут предпочитать доверенных и проверенных поставщиков. Стартапы к таковым, увы, не относятся.

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

Подробнее…

Каких навыков не хватает ИБшникам и какие навыки востребованы?

Наткнулся я на днях на вот такую матрицу, которая показывает результаты анонимного опроса 34-х специалистов по ИБ с минимум 5-тилетним стажем по 19 различным навыкам, которыми они обладают или не обладают. Черным показаны пробелы в навыках. Если посмотреть внимательно, то окажется, что только один чувак с опытом более 24 лет обладает всеми навыками. У остальных есть пробелы, местами достаточно значительные. Отсюда можно сделать два простых вывода:

1. Нельзя знать все! Если вы чего-то в ИБ не знаете, не надо посыпать голову пеплом. 97% специалистов такие же как и вы и тоже чего-то не знают. Скорее это повод задуматься о том, каких навыков вам не хватает и пойти их нарабатывать.
2. Но нарабатывать их вам надо, если вам они нужны. И отсюда второй вывод. Специалисты по ИБ широкого профиля редки на рынке. У многих есть своя специализация и он растет в ней.

Если посмотреть таблицу, то основные пробелы у людей в нескольких направлениях:

• управлением уязвимостями и поиск багов
• управление доступом и идентификационной информацией
• разработка эксплойтов
• пентесты
• безопасность ПО (тут, думаю, речь идет об AppSec) и DevOps
• социальный инжиниринг.

Такая картина соответствует, как минимум, моему восприятию мира. SecDevOps и AppSec - это достаточно новое направление в ИБ и в нем еще маловато специалистов. Социнжиниринг подразумевает работу с людьми и знание психологии, что никогда не было коньком безопасников. Еще три навыка относятся к offensive-тематике, которая хорошо знакома обычно молодому поколению, а не пиджакам. Немного выбивается тема Identity Management; не знаю почему.

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

1. Умение писать скрипты для различных задач, возникающих в деятельности безопасника
2. Знание бизнеса и умение говорить с ним на одном языке
3. Гиперконвергентные инфраструктуры
4. Анализ данных
5. Понимание бизнес-тенденций
6. Машинное обучение
7. Управление приложениями
8. API
9. SQL
10. ERM или ERP.

Судя по списку, в нем речь идет скорее о нехватке знаний, чем навыков. Но список все равно интересен. Интересно, что в список из 30 областей знаний, в которых опрошенные специалисты по ИБ хотели совершенствоваться, совершенно не вошли:

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

Часть из этого списка "аутсайдеров" скорее связана с тем, что безопасники думают, что они все знают в той или иной области (например, в сетях, open source или той же кибербезопасности, тех областях которые вообще не были названы), а остальные темы скорее просто неинтересны безопасникам и они их считают неперспективными (тот же VR/AR или блокчейн) или ненужными в своей работе (тот же BPM или UD/UX).

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

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

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

И не болейте! 

Подробнее…

Безопасность по подписке

На новогодних праздниках я настраивал новый телевизор с функцией Smart TV и загрузил на него приложения нескольких онлайн-кинотеатров - Okko (годовая подписка вместе с покупкой телевизора), КиноПоиск HD (подписка при покупке Яндекс.Плюс), ivi (подписка сына), Netflix (подписка сына). Помимо этого я активно пользовался еще и Apple TV. Итого 5 стриминговых кинотеатра по подписке и почти полный отказ от обычной телевизионной программы. Мир переходит на новую модель приобретения товаров и услуг - по подписке. Потребитель больше не хочет вкладывать капитал в собственность и берет все больше по требованию.

Интересно, что ровно та же модель начинает все активнее проникать и на рынок ИБ. Наблюдая за его зарубежной частью, я вижу, что почти все иностранные ИБ-вендоры также переходят на модель продажи услуг и продуктов ИБ по подписке, постепенно уводя на задний план традиционные продажи "железа" и ПО. По оценкам Gartner в 2020-м году более 80% ИТ-компаний перейдет на эту модель. Рынок ИБ чуть отстает, но движение в этом направлении уже не отменить.

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

Подписочная же модель выравнивает расходы на ИБ с фактическим использованием ИБ-решений. Вы не покупаете впрок и вам не надо бояться, что вы не сможете использовать то, что закупили. С ростом потребностей вы просто докупаете новые подписки, как и с ростом производительности, ростом пиковых нагрузок и т.п. Мечта... Помните заметку про новый класс решений SASE? Так вот они обычно и продаются по модели подписки. Вам нужен МСЭ? Покупаете подписку на соответствующую функцию. Нужен VPN? Еще лицензия на нужное количество пользователей и длительности. Нужен DLP, IPS, WAF, анти-DDoS, антивирус? Докупаете необходимые лицензии по мере необходимости.

Еще одно преимущество подписочной модели - отсутствие зависимости от необходимости постоянных обновлений средств защиты и лежащих в их основе операционных систем, СУБД, прикладного ПО. Вы перекладываете эту задачу на производителя/поставщика и он сам выполняет это в рамках жизненного цикла решения. Это же позволяет при необходимости перейти на решение другого вендора, если текущее решение вас не устраивает. В обычной жизни вы не можете этого сделать, пока не закончится срок амортизации поставленного на баланс предприятия решения. В подписочной модели вы можете вообще не знать, с помощью чего обеспечивается ваша безопасность - вы просто оплачиваете подписку за нужную возможность.

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

Следуя общей тенденции и росту запросов от заказчиков, многие ИБ-вендора также переходят на эту модель. И дело тут не в антивирусах, которые продавали обновления антивирусных баз по подписке (это немного иная модель). Firewall-as-a-Service, IPS-as-a-Service, DLP-as-a-Service, IDM-as-a-Service, SOC-as-a-Service... (даже Crime-as-a-Service). Многие технологии ИБ все чаще получают приставку "как сервис", переходят в облака и переходят на подписочную модель.

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

Подробнее…

3 рекомендации по улучшению приказов ФСТЭК. Экселизация

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

RTF, PDF и HTML. С PDF работать невозможно - только читать.

Та же ситуация и с HTML и RTF. Допустим, я хочу выбрать нужные мне защитные меры, сделав фильтрацию по нужному уровню защищенности или классу информационной системы или АСУ ТП. Указанные форматы мне этого сделать не позволяют.

Что делает в таком случае большинство людей? Копипастит все в табличку Excel и начинает с ней работать за счет возможностей, предоставляемых Excel для работы с данными. Например, можно отмечать нужные мне защитные меры (добавляя их или удаляя) и затем делать выборку только по актуальным мерам защиты. Можно, если воспользоваться рекомендациями из вторничной заметки, делать выборку по приоритезированным группам защитных мер. С помощью цветовой маркировки можно отмечать реализованные защитные меры, нереализованные, и находящиеся в процессе реализации. Вот, например, как выглядит такая таблица у Center of Internet Security (CIS). Помимо PDF с описанием защитных мер, они выкладывают еще и таблицу, с которой удобно работать.

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

На самом деле таких таблиц у CIS три - одна ведет отсчет от защитных мер. Вторая - от защищаемого актива, а третья - от угрозы. То есть мы можем работать сразу с несколькими срезами и точками отсчета.

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

В данной рекомендации нет ничего революционного - речь идет просто об автоматизации и удобстве работы с документами ФСТЭК. Многие, в принципе, такую работу проделывают сами. Но гораздо лучше было бы, если бы такие файлы выкладывались самим регулятором у себя на сайте и он бы поддерживал их актуальность. Причем можно сделать это в двух вариантах - в более привычном всем MS Office, который предлагает больше возможностей по работе с данными, или в более импортозаместительном OpenDocument (ODS). В последнем формате ФСТЭК выкладывает у себя на сайте различные реестры. Базовые функции у этих форматов схожие и многие описанные выше вещи можно делать и в ODS тоже. Но что-то более продвинутое поддерживает только Excel.

Подробнее…

3 рекомендации по улучшению приказов ФСТЭК. Привязка защитных мер к угрозам

В конце января я написал заметку о том, как можно было развить БДУ, добавив в нее привязку к этапам атаки (там где угроза является низкоуровневой, а не стратегической) и затем уже к матрице MITRE ATT&CK. Сегодня я хотел бы посмотреть на эту проблему немного с другой стороны. Одним из часто задаваемых вопросов касательно инициатив ФСТЭК является - "Как связать угрозы из БДУ с защитными мерами из приказов?". Сергей Борисов уже писал об этом и даже провел колоссальную работу, выложив соответствующую табличку.

Однако, как я писал в январе, сама по себе БДУ решает задачу скорее бумажной ИБ, чем практической, и маппинг мер 17-го приказа в перечень угроз из банка данных (а точнее наоборот) не сильно помогает бороться с реальными атаками, которые описываются с помощью матрицы ATT&CK или более высокоуровневой модели Kill Chain.

Первый вариант является частью самой матрицы ATT&CK - в описании многих из тактик нарушителей есть раздел по мерам их нейтрализации и способам обнаружения. Да, он неполный. Например, в отношении угрозы использования DGA-доменов ATT&CK предлагает сетевые IPS и локальные DNS-sinkhole, напрочь забывая о решениях класса ISG (Internet Security Gateway) или SASE или DNS Firewall. Но как точка отсчета и как пример реализации, этот вариант подходит неплохо.

Есть и обратный процесс - выбрав в списке защитных мер интересующую вас, вы получите перечень тактик, которые мера позволяет нейтрализовывать.

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

Второй вариант был предложен Центром Интернет-безопасности (CIS), который разработал модель CAM (Community Attack Model), задачей которой было, отталкиваясь от Топ20 защитных мер, приоритезировать их исходя из хакерских техник, чаще всего используемых в мире. Методология CAM может быть описана следующим образом:

• проанализировать источники данных (CIS анализирует кучу TI-отчетов и источников)
• идентифицировать ключевые тактики и техники
• идентифицировать способы защиты от ключевых тактик и техник
• связать методы защиты с мерами CIS Control.

Учитывая, что CIS расположен в США, где одним из самых популярных фреймворков по ИБ является NIST CSF, то CAM использует его в качестве основы для группирования защитных мер. По горизонтали матрицы у нас 5 блоков защитных мер по NIST CSF (Identify, Protect, Detect, Respond, Recover - идентификация, предотвращение, обнаружение, реагирование, восстановление), а по вертикали - этапы большинства современных атак. Эти этапы немного отличаются от этапов ATT&CK, но в перспективе, во второй версии CAM должен быть маппинг и в матрицу корпорации MITRE. Иными словами, матрица CAM позволяет обсуждать защитные возможности/меры применительно к стадиям атаки.

Схожие подходы уже используются разными компаниями. Например, вместо пяти блоков защитных мер применяется три - предотвращение, отражение, реагирование. Другая компания применяет шестиэтапную модель МинОбороны США (я о ней уже писал) - detect, deny. disrupt, degrade, deceive, destroy. Столбцы в свою очередь могут быть разбиты дополнительно на типы нарушителей. В любом случае в ячейках на пересечении вписываются защитные меры. Наиболее популярный вариант матрицы  CAM выглядит так.

Но так как основная задача CAM развивать и поддерживать CIS Controls, то связь защитных мер из списка Топ20 с этапами атаки выглядит таким образом.

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

Так как MITRE ATT&CK сегодня становится все более и более популярной, то Center of Internet Security в рамках развития CAM ведет работы по связыванию защитных мер CIS Controls с техниками и тактиками ATT&CK, существенно расширяя те возможности, которые предоставляются самой MITRE. По сути получается, что если MITRE использует матрицу ATT&CK как точку отсчета и уже потом привязывает к ней защитные меры, то у CIS подход другой - они отталкиваются от защитных мер и потом уже смотрят на матрицу MITRE.

Резюмируя, приказы ФСТЭК можно было бы еще улучшить за счет привязки защитных мер к угрозам из БДУ, которую в свою очередь стоило бы улучшить за счет привязки к конкретным тактикам и техникам злоумышленников. При этом, матрицу MITRE ATT&CK я привожу как пример того, как это может быть реализована. Она тоже не идеальна, фокусируясь преимущественно на APT и группировках, использующих те или иные методы. В итоговую матрицу попадает далеко не все, что используется при атаках. Но сама идея матрицы очень неплоха и на ее основе, раз уж у нас не любят в лоб использовать американские наработки, можно сваять что-то отечественное. Правда, в последнем случае мы получим очередной импортозаместительный костыль, который без должной поддержки со стороны сообщества умрет. А поддерживать его, увы, никто не будет, как и многие другие инициативы, исходящие от государства (отечественная Википедия, отечественный Гитхаб, отечественный стандарт обмена данными об инцидентах и т.п.). Будем вариться в собственном соку, в то время как иностранцы будут обходить нас по многим направлениям ИБ. 

Подробнее…