Путь в ИБ глазами управленца08.05.2024 23:30

Здравствуйте! Я Александр Шульман, руководитель компании Active в которой мы уже несколько лет занимаемся амбициозным проектом — пишем продукт для обеспечения кибербезопасности и достигли первых результатов: полгода назад мы получили аккредитацию от Минцифры, попали в реестр отечественного софта и у нас открылись продажи. Я хочу поделиться своим опытом и представлениями о рынке кибербезопасности с вами с позиции управленца, а не от лица специалиста ИБ, хочу рассказать о своих разочарованиях, открытиях и о том, как в итоге у нас в команде родилась идея сделать свой вклад в рынок ИБ. Мне кажется, что это многим будет интересно, т.к. рынок ИТ активно движется в сторону информационной безопасности по причинам регуляции и по причине роста реальных угроз, а значит, все больше менеджеров и управленцев столкнется с вызовами по кибербезопасности. 

Мое погружение в тему кибербезопасности началось в далеком еще доковидном 2016 году. К тому времени я уже много лет был опытным руководителем, выстраивал работу it-команд, много чего знал в разработке и администрировании, но о защите данных знал только на общем формальном уровне. Я и моя команда занималась тогда разработкой клиентских IT системам, мы их строили и поддерживали.  Нам пришлось перепробовать множество решений для обеспечения кибербезопасности клиентов, от простых fail2ban скриптов до тонкой настройки фаерволов и подключении их к большим SOC, работающих на SIEM-системах (например, QRadar от IBM). Быстро выяснилось, что реальность сильно отличается от медийных мифов о противостоянии хакеров и безопасников. Я бы сказал, что по моим тогдашним впечатлениям мне это более всего напоминало работу бухгалтера из 20 го века и оказалось вовсе не похожим на работу трейдера, который следит за индикаторами на множестве экранов и активно управляет рисками и поведением систем. Действительно, все начинается с длительной, бумажной работы, еще нет никакого реального взаимодействия с системами, а уже есть: заполнение форм, протоколы соответствия, стандарты ISO, акты передачи и пуско-наладки, формуляры ответственности и прочие штуки, которые меня как управленца сильно утомляли. Разочарованием стало, что 95% всех усилий прикладывается на разбор уже случившихся инцидентов, уже после того как «все было».

Вы соглашаетесь с отказом от ответственности

Расскажу как я с этим столкнулся впервые и как погружался в вопрос. Один из клиентов обратился к нам с просьбой помочь подобрать ему внешний SOC сервис. Он не очень понимал зачем точно ему это нужно, но было такое требование регуляции и нужно было соответствовать. Мы выбрали поставщика, использующего IBM QRadar: предварительно мы произвели исследование рынка и выяснили, что на тот момент (да в принципе и на сегодня) это было мощное и популярное решение, которое практически определяет стандарт отрасли. Заполнили много бланков, подписали договор, формуляры ответственности (первый раз это все было еще интересно, но по факту это просто бюрократический «театр» безопасности, который призван прикрыть пятую точку всем участникам процесса), всё настроили и стали наблюдать за происходящим. Спустя пару дней пришло письмо, примерно такого содержания:

Тут надо сказать, что для того чтобы получать такого рода защиту мы потратили дни на настройку и выгрузку логов из множества подсистем, перенастройку файрволов, добавление каких-то модулей и агентов в свою инфраструктуру, заплатили за аренду нескольких не самых дешевых железок, оплатили работу самого SOC и вся эта гора родила первое письмо. Я был полон оптимизма и, конечно же, я немедленно написал письмо с запросом: каковы потери от этого инцидента, что мы можем сделать чтобы предотвратить такие атаки, какие цели у врагов и что вообще делать? Мне ответили, что эти используемые нами порты небезопасны, требуется их закрыть и немедленно отключить указанные серверы от интернета до тех пор, пока команда безопасников будет делать свои сакральные ритуалы «обогащение данных об инциденте», «установление корреляций», «реверсивное исследование логов систем», «моделирование сценария вторжения» и прочий Forensic.

А на следующий день они выяснили, что порты эти — SSH, который используют разработчики клиента, а подключения происходили из офисов и удаленных рабочих мест разработчиков. Из анализа бизнес процессов внутри команды клиента мы выяснили, что перетащить их в VPN нельзя, что использовать переходный сервер разработчики не могут и казалось бы, что защититься от разного рода посягательств на этот протокол в этих условиях вроде как не представляется возможным и нас попросили …барабанная дробь… заполнить формуляр с отказом от ответственности! Стандартная и знакомая ситуация, да? Несколько таких рывков и мой энтузиазм угас окончательно.

Вас ломают, а мы смотрим

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

Убеждения рынка ИБ

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

• Хороший фаервол защитит хорошо, а плохой плохо.

• Многие верят в сложные или, как некоторые их называют, «хорошие» пароли, настолько, что если кто-то кого-то взломал, то тот, кого взломали просто «дурак», который не смог придумать себе пароль. 

• Автоматически блокировать никого и ничего нельзя, ведь можно заблокировать «директора» или «важного клиента».

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

• SIEM системы — это вам не антивирусы и из коробки они не работают. Они больше похожи на фреймворки, а настройка их — это почти магическое программирование.

• Все эти продвинутые системы информационной безопасности SIEM/SOC/SOAR/XDR/TDR нужны только только для крупных организаций с высокой зрелостью ИБ процессов, для остальных это слишком сложно, непонятно, дорого и вообще излишне.

• Все эти ИБ нужны только только для организаций с высокой зрелостью ИБ процессов, для простых смертных есть «файрвол».

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

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

• Или вот ещё — «а нам вообще скрывать нечего, кому мы нужны». 

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

• Пытаться защититься вообще бессмысленно: кому надо украдут или всё равно могут украсть/сломать изнутри кому надо, а вся система уязвима ровно настолько насколько уязвим хоть один ее узел. 

• ну и вот это прям мое любимое: у меня Mac — яблоки не взламывают.

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

Не смотреть, а действовать

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

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

Общие

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

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

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

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

Реагирование на угрозы

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

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

Уязвимо все, включая внутреннюю сеть
Если атаку не получилось предотвратить, то мы должны увидеть ее, локализовать и остановить.

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

Движение от 0 к 1
Современные средства защиты очень продвинуты, но их функционал используется на небольшой процент, это, кстати, очень напоминает ситуацию с MS Excel, в котором мало кто использует весь потенциал. Мы должны управлять силой уже имеющихся решений и средств защиты, а не стремиться все сделать с нуля.

Работа с системой

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

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

Аналитика и отчетность
Критически важно иметь возможность анализировать данные об угрозах и инцидентах, получать подробные отчеты. Это позволит принимать обоснованные решения по безопасности и демонстрировать результаты бизнесу, обосновывать выделение ресурсов. В реальном мире все просто: нет отчетов — нет денег.

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

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

© Habrahabr.ru