Денис Кораблёв: Мы создаём новую кибербезопасность с MaxPatrol O2

Денис Кораблёв, директор по продуктам компании Positive Technologies, рассказал нам о революционных технологиях, которые нашли своё воплощение в решениях нового поколения — метапродуктах, первый из которых (MaxPatrol O2) был представлен весной на Positive Hack Days 10, — и, в частности, о том, каким образом с их помощью изменится работа департаментов ИБ в ближайшем будущем.

На PHDays 10 была сделана очень интересная презентация с демоверсией одного из ваших продуктов. Он называется MaxPatrol O2. Ранее мы анонсировали это решение нашим читателям. В чём его концепция? Почему вы решили его создать, чего не хватало в классическом SIEM или в том же SOAR? 

Д. К.: Начнём с того, что все на рынке сконцентрированы на автоматизации, ориентированной на умных ребят (тех суперэкспертов, которых, как все знают, раз-два и обчёлся), чтобы они делали свою высокоинтеллектуальную работу как можно быстрее. Когда мы начали защищать не только своих клиентов, но и самих себя, добиваясь стопроцентного результата 24×7 на базе наших продуктов, мы поняли, что и нам без этих самых экспертов высочайшей квалификации никак не обойтись. При этом, повторюсь, их общее число на рынке весьма ограниченно ― всего-то полторы-две сотни. И рутинная работа — с утра до ночи смотреть в монитор — им далеко не интересна (что неудивительно, так как это сродни использованию микроскопа в качестве молотка). Например, у нас они не только кого-то защищают, но и расследуют сложные инциденты, изучают современные угрозы, принимают активное участие в разработке продуктов. 

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

Есть аналогия, которая, как мне кажется, очень удачно отражает сегодняшнюю ситуацию в кибербезе: вспомните автомобили и их водителей в начале двадцатого века. Кем был водитель в те времена? Он мог сам машину (сложнейший на тот момент механизм) разобрать, собрать, да ещё и доставить по месту назначения. Это была элитная профессия, таких людей было очень мало, и это очень похоже на нынешних кибербезопасников. И в случае с автомобилестроением прогресс изменил расстановку сил, сделав автомобиль доступным любому пользователю (даже со стремящимся к нулю пониманием того, какие технологии и как работают под капотом). То же самое произошло с ИТ в целом — здесь уже «по полной» используются всевозможные подходы и алгоритмы, такие как ML, AI, Big Data и прочее.

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

Сразу отмечу, что это — не написание плейбуков для SOAR, это ― совершенно другой подход. Плейбуки как раз и нужны умным людям, чтобы меньше времени тратить на рутину. Или для того, чтобы свою часть работы могли сделать специалисты меньшей квалификации, в случае необходимости передав задачу более квалифицированным экспертам. В нашем же случае речь идёт о том, чтобы организация смогла обойтись в принципе без привлечения в штат таких уникальных специалистов. Да, это возможно. И если весь рынок, делая IRP / SOAR, создаёт очень удобный интерфейс, но всё же для умных ребят, то мы стараемся в принципе избавиться от интерфейса. Лучший интерфейс — это тот, которого нет. Наиболее комфортная ситуация — когда тебе просто звонят по телефону, который ты всегда носишь с собой, или пишут в мессенджер, сообщая простым человеческим языком, что же фактически происходит, и ты принимаешь решение. И это всё. Именно это и подтолкнуло нас к идее создать MaxPatrol O2.

К какому классу продуктов можно отнести MaxPatrol O2? Это ведь не SIEM-система, не SOAR? На XDR, может быть, немного похоже.

Д. К.: XDR как один из сенсоров у нас тоже разрабатывается и был анонсирован на PHDays в мае. Но вот в чём суть: мы пытаемся сказать, что реагирование на инциденты не нужно вообще. Такой класс продуктов, как Incident Response, нужно помножить на ноль. Задачи, которые решает MaxPatrol O2, — из плоскости Incident Response, но подход принципиально другой. Для него даже ниши нет, он сам себе её создаст.

На демостенде и на презентации, которая была на PHDays, MaxPatrol О2 оперирует данными от продуктов компании Positive Technologies: SIEM-система, WAF (Web Application Firewall). А можно ли подключать туда сторонние продукты и использовать данные от них?

Д. К.: Концептуально мы именно в это и целимся. Просто у нас есть продукты в каждой из минимально необходимых для запуска MaxPatrol O2 ниш, поэтому естественно, что в первую очередь мы взяли свои технологии. Но в целом мы стремимся к тому, чтобы в итоге получился своего рода маркетплейс, в который смогут приходить и другие вендоры. MaxPatrol O2 обеспечивает результат основываясь на сенсорах, которые соответствуют определённым требованиям и реализуют определённый протокол. При этом мы как компания не делаем некоторые классы решений, например DLP, NGFW и прочие. И в этих нишах мы и хотели бы заполучить союзников в первую очередь. 

В принципе, даже уже сейчас можно, например, привязать сторонние продукты к SIEM-системе и использовать её как промежуточное звено.

Д. К.: Можно, но вот в чём дело: каждый из наших продуктов мы были вынуждены сильно доработать для MaxPatrol O2. Каждый наш продукт стал сенсором вот в каком смысле: всё, что пролетает через него, что может быть полезно MaxPatrol O2, но не может быть никак использовано самим сенсором, сразу пробрасывается в MaxPatrol O2 для дальнейшего анализа. Допустим, PT Application Firewall защищает только веб, но в то же время видит и многое другое, например подбор паролей и успешные авторизации. На своём уровне он далеко не всегда может с этой информацией как-то обойтись, однако если свести все потоки информации в MaxPatrol O2, возможно, построится цепочка атаки. В общем, есть такие вещи, которые сенсор сам по себе закрыть не может, но если он пробросит информацию дальше, то для MaxPatrol О2 это будет полезно. Соответственно, каждый сенсор мы доработали. Если взять продукт любого другого производителя, который так не адаптирован, то общая «конструкция» может потерять в качестве. Но функционировать эта конструкция всё равно будет.

Как раз к вопросу о технической составляющей. За счёт чего образуется эта магия, когда мы видим связанную цепочку событий и наблюдаем, как развивается конкретная атака? Откуда эта информация?

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

Вот как это работает технически. SIEM не держит «в голове» контекст, он просто выделяет события из огромного потока, а MaxPatrol О2 — держит. Для SIEM какой-нибудь логин или базовая операция запуска команды — это вообще не инцидент, он даже не обратит на него внимания. MaxPatrol О2 же понимает, что если злоумышленник здесь, то, значит, ему важно собрать всю информацию именно в этой точке, поэтому он начинает извлекать все доступные сведения, чтобы достроить эту атаку. Если говорить метафорически, MaxPatrol O2 начинает бегать за злоумышленником с фонариком, максимально подробно освещая всё вокруг потенциальной точки его присутствия. SIEM так делать не будет, он — очень высоконагруженная система.

Получается, что для эксплуатации MaxPatrol О2 нужно очень хорошо понимать контекст инфраструктуры, её отдельных узлов, какие узлы по-настоящему значимы, что на них происходит, как они связаны между собой?..

Д. К.: Та часть, которая про «связаны между собой», делается автоматически. Первый шаг — это всё-таки понять, что же является риском, абсолютно неприемлемым для той или иной организации событием. Такие риски — это часть конфигурации MaxPatrol O2. Его задача — не дать им случиться. За каждое такое неприемлемое событие (риск) в нашей концепции отвечает топ-менеджер или руководитель функции компании. Например, за риск хищения денег отвечает непосредственно финансовый директор. Ведь только он знает, насколько опасна угроза, и только он может принять решение об остановке 1С, скажем, на время разбирательства с атакой.

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

Так вот, «магия» MaxPatrol O2 работает только в том случае, когда инфраструктура выстроена в соответствии с нашими рекомендациями, а именно — путь с периметра до непосредственной реализации риска достаточно длинен, чтобы злоумышленник не остался незамеченным, и покрыт средствами мониторинга, а узлы по пути следования к риску достаточно тщательно укреплены (hardening). При этом пути следования к разным рискам начиная с какого-то шага не пересекаются, иначе мы не сможем однозначно идентифицировать цель злоумышленника. Если какие-то из пунктов не выполняются, система будет работать с меньшей эффективностью. Поэтому очень важно настроить инфраструктуру в соответствии с рекомендациями и поддерживать в актуальном состоянии.

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

Какие настройки и индивидуализация нужны под конкретного заказчика? Допустим, у него уже стоят ваши продукты, на них идёт определённая активность, собираются логи, всё поступает в SIEM-систему, и теперь он хочет установить и начать использовать MaxPatrol О2. Что для этого нужно сделать помимо определения рисков? Может быть, нужен консалтинг с вашей стороны, чтобы помочь заказчику понять эти риски и формализовать их?

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

Впрочем, такая работа всё равно улучшает безопасность, вне привязки к MaxPatrol О2, поэтому её нужно провести в любом случае. После того как риски будут выявлены и станет понятно, как они переносятся на инфраструктуру, придёт время для их задания в системе.

Получается, чтобы соотнести риски с инфраструктурой, нужно провести глубокий аудит своими силами или привлечь кого-то извне, чтобы он всё это описал: здесь у нас 1С, там у нас стоит контроллер, там, например, веб-серверы, которые для нас тоже очень важны, и так далее.

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

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

Д. К.: MaxPatrol O2 сам автоматически сканирует инфраструктуру и перестраивает маршруты, риски он не потеряет, об этом не нужно беспокоиться. Но есть другая проблема: что если нарушилось выполнение рекомендаций к инфраструктуре (отключили мониторинг, изменили конфигурацию сети) и теперь к риску можно попасть в один шаг? Для этого мы делаем отдельный продукт. У нас уже есть MaxPatrol O2, второй же мы пока называем MaxPatrol C — Compliance. Всё вместе — «СО2» (смеются). MaxPatrol С производит непрерывное сканирование и говорит, в каком порядке устранять возникающие несоответствия. Это — особый продукт, он сможет отдельно и работать, и продвигаться. В случае если его нет, его операции будет необходимо выполнять вручную, по-другому никак.

Получается, необходимо заложить определённые ресурсы и заранее понимать, что оно так всё время «из коробки» работать не будет. После установки эту систему необходимо определённым образом поддерживать.

Д. К.: Безусловно. Но эта история типична для сферы безопасности. В конце концов, это те же самые силы, которые ты и так тратил бы на то, чтобы поддерживать инфраструктуру в актуальном состоянии. Просто тут тебе даны фреймворк и направление, как это делать правильно, и ещё продукт, который тебя буквально ведёт за руку.

Сейчас хотел бы выступить в качестве скептика. В презентации была показана впечатляющая магическая кнопка — «остановить атаку». Воплощённая мечта безопасника, ведь часто говорят: «Не хочу разбираться в ваших консолях, хочу одну кнопку нажать, и чтобы всё было хорошо». Но, с другой стороны, мы видим, что тот же SOAR, как и реагирование вообще, спотыкается о реалии: автоматическое реагирование блокируется на человеческом уровне, потому что непонятно, как это отработает и кто за это будет нести ответственность. Нет ли и здесь такого, что в теории всё великолепно, а на практике все будут банально бояться нажимать на кнопку?

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

Да, можно увидеть, что будет блокироваться, что ещё будет происходить.

Д. К.: В целом мы допускаем, что тот вариант реагирования, который мы заложим «из коробки», может для кого-то оказаться неприемлемым. Поэтому можно действовать более атомарно. Условно говоря, тебе даётся сценарий и ты можешь нажать не на все кнопки, а изолировать только часть узлов, разорвать только часть соединений. Но тема эта бесконечна, её можно бесконечно улучшать. На мой взгляд, ноу-хау этого продукта — это сам подход: мы не для суперэкспертов это делаем, а для тех, кто всего лишь разбирается в контексте.

Про автоматизацию мы поговорим чуть позже, а вот с реагированием хотелось бы закончить. Реагирование, автоматическое или полуавтоматическое, подразумевает интеграцию с целевыми системами. За счёт чего она происходит? Для SОAR-систем это — болезненный вопрос: надо разработать и поддерживать в актуальном состоянии множество коннекторов. А как у вас?

Д. К.: Так же.

Всё равно приходится это делать?

Д. К.: Конечно. Тут нет никакого другого ответа. Интеграция с элементами инфраструктуры и тикетными системами для ИТ-специалистов. 

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

А есть ли какой-то вариант самообучения этой системы? Чтобы она, допустим, увидела не до конца распознанные атаки или аномалии.

Д. К.: Да, такой механизм имеется. У нас кроме обычного интерфейса MaxPatrol О2 есть MaxPatrol О2 Pro. Это взгляд на ту же систему через призму атомарных алертов. Там можно искать алерты, связывать и развязывать цепочки и таким образом тонко настраивать систему. Просто мы скорее сами этим занимаемся, и всё, что мы сделали, попадает в автоматическую базу, так что клиентам заниматься этим ни к чему. Но если они очень хотят, то могут сделать и это.

Теперь об автоматизации. Представляется, что одна из основных задач ИБ на ближайшие годы — сделать рутину более-менее автоматизированной. Насколько MaxPatrol О2 позволяет снять с безопасника основные рутинные операции?

Д. К.: Это тот же самый типовой подход: есть безопасники, их много, и у них есть рутина, давайте упростим эту рутину — напишем правильные плейбуки, и будет легче жить. У нас принципиально другой подход! Вообще не надо этим заниматься, не надо сидеть и связывать всё это. Пусть безопасник лучше занимается более полезными делами — тем, чтобы правильно настроить инфраструктуру, например. А ежедневно делать разборы по каждому алерту ни к чему — система сама решает эту проблему. И сидеть 24×7 дежурной смене тоже не нужно — достаточно держать телефон на виду, продукт сам напишет, когда надо будет принять решение. Это и есть та самая работа, за которую и должны платить безопаснику — понимая контекст атаки, целевой риск, который потенциально может быть осуществлён, принимать решение о противодействии вместе с ответственным за этот риск.

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

Д. К.: Для того чтобы всё работало, софт не нужен. Вообще, проблемы, которые мы видим, — это проблемы инертности, а также нежелания и невозможности быстро что-то поменять. Но есть и хорошая новость. Обычно, когда говоришь с CISO, эта идея заходит не очень хорошо, потому что, по сути, ты бьёшь по устоям и канонам того, как CISO привык жить. Но разговаривая с топами и акционерами, видишь, что идея находит понимание. Дело в том, что безопасность, как правило, непонятна и непрозрачна для топ-менеджмента. Они не знают, чего от кибербезопасности хотеть. Часто звучит тезис, что сломать можно всё и вопрос только в вероятности. Наш же подход про гарантированное недопущение неприемлемых событий более честен, понятен и прозрачен.

По поводу вопроса о зрелости — нужно, чтобы руководство хотело от безопасности реальной защиты. Этого достаточно.

А потенциальные заказчики новых решений — это компании крупные или не очень?

Д. К.: Данные решения подходят всем. Хотя некрупным компаниям, конечно, проще их внедрить, потому что им легче перестроить инфраструктуру. Например, финтех-стартапы. Для них безопасность — это вообще жизненная необходимость. У них любой риск связан с потерей денег. И они изначально создают такую систему, чтобы всё было максимально безопасно.

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

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

Д. К.: Хочу отдельно рассказать про киберучения как средство верификации результата. Мы всем советуем перейти от классических пентестов к киберучениям, в рамках которых нужно реализовать именно те риски, которые для вашей компании критически значимы. Тогда пентест перестаёт быть абстрактным, а заодно можно и увидеть MaxPatrol O2 в действии.

Что ещё можно было бы предложить в качестве метрик?

Д. К.: Основная метрика — это невозможность совершить недопустимое событие. Понять это можно в результате киберучений, когда цели — те самые недопустимые события. 

Спасибо за беседу! Успехов!