Снижение киберрисков в эпоху цифровой трансформации

Отступая, отстреливайтесь!

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

Отдельно выкладываю презентацию.

Reducing cyber risks in the era of digital transformation from Sergey Soldatov

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

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

Оперативность и Релевантность

У меня создалось впечатление, что вера среди широких масс в то, что IoC-и  - это основа  современной безопасности, достигла своего апогея. Уже вполне толковые ребята со сцены всерьез (хотя, может, шутил, но я шутку не почувствовал) заявляют о том, что они у себя выкинули антивирус и заменили его на EDR с хешевым фидом, и это - революционный подход к безопасности. Удивительно?!
В целом, любому здравомыслящему человеку понятно, что даже файловая антивирусная сигнатура - куда более продвинутая технология детектированя, чем хеш, как минимум, потому, что одна сигнатрура может детектить одно и то же зло с разными хешами, а современный EPP еще имеет кучу других технологий, в том числе, и по поведению (кстати, единственный способ детекта malware less атак). Если рассмотреть Пирамиду Боли, то статические индикторы - низшие в иерархии. Ниже я раскрасил где о чем написано.

Да и EDR - не панацея сама по себе, но только в связке с EPP. А вообще, нужна целая совокупность технологий и сервисов, и только тогда, может быть, будет возможность эффектино обнаруживать и реагировать.

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

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

1. Я каким-то образом обнаружил вредоносных хеш, который пока не обнаруживается вендорским ЕРР.

2. Добавляю этот хеш в мой кастомизированный Черный спискок.

3. Сэмпл добавляю в папочку, которая постоянно сканируется моим вендорским EPP в применяемой у меня комплектации (я бы порекомендовал использовать полную комплектацию - с облаком, с поведенческими и эвристирческими движками и т.п.) - это будет моя "лаборатория постоянной проверки детекта"

4. Как только сэмпл стал обезвреживаться используемым у меня ЕРР, его можно удалить из Черного списка, чтобы список не был бесконечно большим, но содержал ровно то, что для меня релевантно, но пока не покрывается вендором ЕРР.

Не раз писал, что я фанат схемок, поэтому ниже картинка про эти 4 пункта. Черными буквами на синем фоне отражено описание ситуации в указанной точке, белыми буквами на синем фоне - мои действия.

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

Инструкция по применению

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

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

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

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

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

Managed Defence and Response

Есть в среде аналитиков такой устоявшийся термин - MDR.
Сам феномен этот, в целом, несложно объяснить. Ранее, когда угрозы, с которыми мы сражались были "обычными", проблема в случае аутсорсинга закрывалась предложением MSSP. Высокая эффективность MSSP обеспечивается жесткой формализованностью его бизнес-процессов, зарегулированностью и алгоритмизацией деятельности участников. Но, как конвейер пригоден для массового производства, и не работает в случае выпуска опытных образцов, так и MSSP не может быстро перестраиваться при возникновении угроз, требующих изменения подходов к управлению ими.
Сейчас мы узнали (и убедились, что целевые атаки - реальность), и эти "Продвинутые угрозы" требуют иных подходов к управлению такими угрозами. Мы заговорили об активном поиске угроз, Threat intelligence, EDR и т.п.
Перестройка зарегулированного "конвейера" MSSP требует времени, а угрозы адресовать нужно сейчас, - это создало нишу "MDR", как совокупность технологий-процессов-людей (да, то же, что и в MSSP), способную решить задачу обнаружения необнаружимого. Я фанат схемок и картинок, способствующих пониманию, поэтому вот "домики", красноречиво описывающие сказанное.

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

Но этот пост всего лишь о названии (а предметные рассуждения на эту тему я продолжу когда-нибудь потом)! Получившееся комплексное предлоение я бы назвал тоже MDR, но "Managed Defence & Response". Одно слово на "De" полностью меняет ситуацию. Так как мы уже не говорим только об "обнаружении", но о "защите",  что с точки зрения конечного потребителя - более ценный продукт. Но этот продукт и более сложен: он уже не является просто сервисом мониторинга над EDR (Managed EDR, MEDR) или (Managed Detection and Response, где к EDR добавляется еще что-то, помимо Endpoint-а), а где реализуются все возможные слои и циклы.
Managed Defence & Response предоставляет в первую очередь защиту, если это возможно, если невозможно - обнаружение (и автоматизированное и ручное, т.е. с активным поиском угроз), а также - реагирование. И к такому "MDR" надо стремиться, и такой смысл надо в него вкладывать, - "Defence" вместо незаконченного "Detection".

Технологическая безопасность

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

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

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

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

На практике можно делать это следующим образом: проанализировать бизнес-процессы, понять схемы мошенничества или любой другой вредоносной активности, несущей материальные риски, придумать как на уровне АСУТП эти риски адресовать; и здесь применяется концептуально тот же подход: предотвратить, если технически возможно, а если невозможно - достоверно обнаружить. Под материальным риском здесь понимаются те, что ассоциированы с реальным ущербом, никогда не следует охотиться на ведьм и приоритезироваться всегда в те 20%, которые дадут 80% результата. А достоверно обнаружить означает, что на уровне приложения и инфраструктуры риски, связанные с умышленным нарушением целостности логов, на основании которых мы судим о происходящем и фиксируем инциденты, адекватно адресованы. Security Operations Center здесь также может (и должен!) быть эффективным и результативным контролем безопасности, но в отличии от классического SOC, работающего, обычно, на уровне инфраструктуры и сражающегося в конечном счете с инструментами: сетевыми атаками, различными видами ВПО, этот, технологический SOC, будет искать мошенничество с пластиковыми картами и картами лояльности, нелегитимные изменения параметров технологического процесса, нарушение целостности метрологических систем, злоупотребления доступом и служебным положением и пр. сценарии атак и модели нарушителей, разработанные при анализе защищаемых бизнес-процессов и проектировании контролей безопасности. Организационные подходы к построению технологического SOC такие же как и в случае SOC для борьбы с инфраструктурными угрозами, но различна специализация персонала, который должен хорошо разбираться в защищаемом бизнес-процессе, чтобы корректно интерпретировать выявленные аномалии, говоря заумно, но короче, - правильно делать триаж.

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

Намеренно не хотел в посте ссылаться на какой-то личный опыт, чтобы никого и ничего не запалить, получилось несколько размыто, поэтому, хотя бы, подведу итоги.
1. АСУТП также крутится на инфраструктуре, поэтому классические системы инфраструктурной безопасности там также должны применяться.
2. Системы безопасности АСУТП работают на уровне приложения, поэтому, помимо контролей в инфраструктуре, они должны реализовывать меры на уровне приложений и прикладных протоколов.
2.5. Для вендоров, выросших из инфраструктурной безопасности и решивших подняться на уровень приложения, логичным кажется модульный подход, когда безопасность АСУТП (и любых других приложений, коими заинтересуется производитель) обеспечивается дополнительными компонентами к системам инфраструктурной безопасности. При таком подходе не теряется вся накопленная практика в области инфраструктуры, и продукт наделяется новыми "способностями" по обнаружению на уровне приложений. В конечном счете это разумно еще и потому, что есть масса приложений и разобр каждого из них в отдельном модуле позволит конечному заказчику, как конструктор, собирать функционал, релевантный ему.
3. Весь комплекс контролей безопасности, реализуемых на уровне инфраструктуры, как технических (например, анализ аномалий в протоколах), так и организационных (как, например, операционные сервисы безопасности: мониторнг и реагирование на инцидент, анализ соответствия требованиям и управление уязвимостями и т.п.), применим и на прикладном уровне, но с учетом соответствующей специфики. Это и есть еще одна перспектива эшелонированного подхода, когда один и тот же потенциальный сценарий атаки мы ловим на разных уровнях абстракции, используя разные подходы.
3.5 Технологический SOC - необходимое и абсолютно правильное явление, позволяющее адресовать риски на уровне бизнес-процессов посредством их обнаружения и расследования с помощью техничеких контролей, реализованных в специализированных приложениях и на инфраструктуре.
3.6 Технологический SOC может объединяться с классическим инфраструктрным SOC, например, как линия эскалации на экспертов в предметной области. Поскольку предметных областей много, как много и бизнес-процессов, и средств их автоматизации, - таких экспертных линий эскалации вполне может быть также много.

PHD'18: Threat hunting своими руками на базе open source

Привет всем любителям практической безопасности!
16 мая в 10:00 Теймур Хеирхабаров в рамках PHD будет проводить воркшоп по обнаружению атак. Настоятельно рекомендую выкачать все необходимое для этого хендзона заблаговременно, вот ссылка.

https://yadi.sk/d/qB1PNBj_3ViWHe

Увидимся на PHD!

Сила действия равна противодействию

...во многой мудрости много печали; и кто умножает познания, умножает скорбь
(Екк. 1:18)

Сумасшедшим жить легко

(Пилот)

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

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

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

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