Как превратить тысячи найденных уязвимостей в понятный план действий
Говорить о развитии технологий поиска уязвимостей в отрыве от реального контекста инфраструктуры компании — все равно что обсуждать эволюцию автомобилей без упоминания дорог, законов и правил движения. Инструменты защиты, точно так же как и машины, менялись не сами по себе. Их развитие мотивировано появлением новых типов атак, изменением бизнес-потребностей и появлением новых требований регуляторов.
Павел Попов, руководитель группы инфраструктурной безопасности, Positive Technologies
За время, которое я занимаюсь процессом управления уязвимостями, получилось поработать с компаниями абсолютно разного уровня зрелости: от тех, кто впервые запускает сканер и удивляется, почему у них «так много красного и критичного», до тех, кто строит полноценные процессы и уже думает не про отдельные CVE-уязвимости, а про устойчивость бизнеса. Подталкивая рынок к более зрелому подходу при работе с уязвимостями, мы перепробовали многое, чтобы быть, а не казаться защищенными, соответствуя требованиям бизнеса, а не только регулятора. Написали курс по управлению уязвимостями, чтобы специалисты перестали изобретать велосипед и получили необходимую базу знаний; опубликовали десятки статей — от методичек до различных аналитик. Даже записали подкаст «Кибердуршлаг», в который приглашали экспертов по ИБ, специалистов, которые выстраивают процессы управления уязвимостями у себя в компаниях, и тех, кто помогает выстраивать комплексную защиту бизнеса от угроз. Все это было сделано ради одной цели — помочь подняться на следующий уровень зрелости, потому что без этого разговоры про «цифровую устойчивость» так и останутся красивыми лозунгами. Получилось ли? Думаем, да. За последние три года не появилось ни одного нового сканера уязвимостей, но начали появляться решения класса vulnerability management (VM). Ниже я расскажу, как происходило и, надеюсь, будет происходить развитие продуктов, связанных с поиском уязвимостей и небезопасных параметров.
Первые сканеры появились не потому, что кто-то мечтал о красивой картинке с отчетами. Все было куда прозаичнее: лавина вредоносного программного обеспечения, массовые атаки на открытые сервисы, громкие истории об отключенных почтовых серверах и дефейсах сайтов. Регуляторный фон в то время был почти пустым. Безопасность считалась делом добровольным.
Но бизнес сталкивался с прямыми потерями: упавший сервер — потерянные деньги клиенты. В ответ на это появился первый софт, который умел проходиться по системе и показывать, где находится уязвимое место. Результат работы — примитивные списки, никаких процессов. Появляется метод черного ящика: не знаем, что внутри, но пробуем нащупать снаружи. Почему это сработало? В тот момент альтернативы просто не было. Организации начали хотя бы видеть, где у них могут быть пробелы в защите. Для бизнеса это было не про стратегию, а про выживание. «Главное, чтобы сервер не лег», — основная мысль тогда. Для киберустойчивости — микрошаг, но именно с этого шага пришло осознание (но не у всех), что безопасность — это не роскошь, а необходимость. На примере нашего портфеля — это продукт XSpider.
Со временем стало ясно: сканеры — это скорая помощь без врача. Приезжает, мигалки включила, а диагноз поставить не может. Админы смотрели на длинные списки уязвимостей и не понимали, что важнее, что чинить первым.
Из-за этой боли и родились решения, которые стали добавлять метод белого ящика, который подразумевает тестирование программного обеспечения при наличии доступа к активам с привилегированной учетной записью, и контроль конфигураций. В организации начали задавать вопросы: почему в разных филиалах одни и те же ошибки? Может, стандарты нужны? Может, стоит регламенты написать? Так появилась первая попытка построить процесс управления уязвимостями. Конечно, неполный, но хоть какой-то. В России такие решения продолжили называть сканерами безопасности. Да, нового поколения и т. д., но сканерами. Так у нас появился продукт MaxPatrol 8.
Хотя западные вендоры такие инструменты уже окрестили продуктами класса VM. Сейчас, конечно, риторика уже поменялась и их называют legacy VM.
Ценность для бизнеса стала заметнее. Появилась возможность отчитываться: «В прошлом квартале мы закрыли столько-то недостатков безопасности». Это выглядело уже как деятельность, а не хаос. Для киберустойчивости цикличность — важный шаг. Когда у тебя есть правила и ответственность, вероятность системного провала снижается.
Но ничего не стоит на месте. Следующим триггером стала резкая цифровизация всего и вся. Появлялось больше софта — росло количество уязвимостей. Число CVE-уязвимостей увеличивалось как на дрожжах. Регуляторы требовали все более детальных отчетов: в Европе — Общий закон о защите данных (GDPR), в США — требования к критической инфраструктуре, в России — обновленные приказы Банка России, ФЗ № 187 «О безопасности критической информационной инфраструктуры Российской Федерации», приказы ФСТЭК (Приказ ФСТЭК России от 11.02.2013 № 17 «Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах», Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»).
На уровне legacy VM компании начали захлебываться в поступающей информации — тысячи уязвимостей, сотни страниц отчетов. Невозможно все обработать вручную, несмотря на то что какие-никакие процессы есть, а решения собирают уязвимости и выпускают отчеты. Но объем такой, что в ручном режиме не справиться. Это и стало причиной перехода к следующему классу.
Эволюция управления уязвимостями: от сканера к риск-ориентированному подходу
Потребовалось новое качество — умение различать, где мелочь, а где критически опасная брешь. Именно поэтому появился полноценный класс решений VM, основанный на рисках для бизнеса. Здесь сохраняется несостыковка в части названия: на Западе — risk-based VM, в России — просто VM. В этот момент мы выпустили продукт MaxPatrol VM. Он позволяет выстраивать полноценный процесс управления уязвимостями — от их обнаружения до устранения, приоритизировать уязвимости и доставлять информацию о трендовых[1] в течение 12 часов. Теперь речь шла не просто о технических дефектах, а о том, как они соотносятся с важностью конкретного актива. К примеру, есть сервер бухгалтерии и учебный тестовый стенд. Формально уязвимость в обоих системах может быть одинаковой, но ценность сегментов несопоставима. Именно такая логика и появилась: сначала — важность актива, потом — уязвимость.
Кажется, что для бизнеса это должно было стать спасением, а для киберустойчивости — революцией. Впервые можно было сказать: «Мы сфокусировались на том, что реально влияет на деньги». Но, к сожалению, развитие — это не всегда упрощение. Нужно делать больше работы, менять уже существующие процессы. Часто приходится объяснять, что отчет на 112 млн строк в файле Excel никак не сделает компанию более защищенной, в него никто даже не посмотрит. Важно акцентировать внимание на трендовых уязвимостях, важности активов и фиксировать сроки патч-менеджмента для контроля устранения, да еще и новые уязвимости будут без пересканирования находиться.
В итоге и здесь есть нюансы. Все больше организаций упирались в эффект насыщения, инфраструктуры растут экспоненциально. Если 10 лет назад казалось, что 5 тысяч узлов — это уровень огромного финтеха, то сейчас даже государственные организации могут насчитывать больше 100 тысяч узлов. Данных много, приоритизация есть, но ощущение «мы тонем» никуда не исчезло. Контекста все равно не хватало.
Атакующие стали действовать более системно. Они перестали «ломиться в дверь» и начали искать обходные пути: через подрядчиков, старые сегменты, уязвимости в связках. Простое управление списком CVE-уязвимостей или соблюдение базовой кибергигиены больше не дают уверенности в безопасности. Из-за роста числа взломов бизнес начал понимать, что можно потерять большие деньги, если не уделять должного внимания информационной безопасности. Появилась потребность говорить о киберустойчивости на языке бизнеса. Руководству было все равно, что у уязвимости оценка 9,8 по шкале CVSS. Ему важно, что это значит для прибыли, клиентов и репутации. Если специалисты по безопасности не могли этого объяснить, они теряли поддержку. Когда владелец или генеральный директор спрашивает: «Насколько мы защищены?» — он не хочет читать отчет из миллионов строк и выполненных SLA.
При этом в текущих реалиях видно, что сами команды ИБ начали уставать. Объем работы становится неподъемным, и без понимания контекста специалисты превращаются в пожарных, которые носятся с ведром и льют воду куда попало.
Все эти предпосылки и породили новый класс — exposure management.
Главное — это контекст. Не просто «вот уязвимость», а «вот цепочка событий, которая через три шага и три часа приведет злоумышленника к критически важным данным». Exposure management объединил все источники опасности, или по-простому — управление киберугрозами. Неизвестные активы, конфигурации, учетные данные, ошибки в сегментации сети и уязвимости складываются в единую картину с точки зрения возможностей атакующих в конкретной инфраструктуре. Впервые появилась возможность строить карту путей атаки. Не отдельные дыры, а маршруты, по которым злоумышленник может двигаться до критически важных для устойчивости бизнеса систем. Ценность для бизнеса стала огромной. Это и послужило предпосылками для запуска нового решения — MaxPatrol Carbon. Руководство получило понятный язык и теперь понимает, какие сценарии угрожают ключевым процессам. Специалисты по ИБ могут объяснять свои действия с помощью бизнес-метрик, а не набора технических аббревиатур. В конце концов, количество проблем, с которыми нужно работать, уменьшается кратно, так как теперь можно заранее увидеть наиболее вероятные пути атаки и перекрыть их с наименьшими усилиями, максимально повысив защищенность самого ценного.
Эволюция подхода к управлению киберугрозами
По мере роста зрелости подхода от выявления до управления уязвимостями и киберугрозами повышается приоритет более важных задач для исправления. Одновременно с этим растет их эффективности и значимость для усиления реальной, а не бумажной безопасности, а следовательно, и уровень защиты от кибератак.
Стоит признать, большинство организаций пока остаются на предыдущих ступенях. Им привычнее жить в парадигме «нашли — исправили». Но рано или поздно реальность подталкивает к большему. И чем раньше компания поймет, что управление киберугрозами — это не роскошь, а необходимость, и соответственно, шанс выстоять в современном цифровом шторме.
[1]Трендовыми называются наиболее опасные уязвимости, требующие оперативного устранения или принятия компенсирующих мер.