Мнение

Сколько безопасности достаточно?

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

Как специалисту по информационной безопасности мне нравятся красивые решения, тем более что компромисс — необходимый элемент успешной работы любого менеджера в этой сфере. В частности, компромисс между безопасностью и ее стоимостью — в самом практическом, буквальном смысле. В среде специалистов по ИБ бытует мнение, что безопасности не может быть много, но в то же время есть понимание, что «много безопасности» стоит дорого, иногда — недопустимо дорого (с точки зрения бизнеса). Где же та тонкая грань «достаточности» безопасности, сколько ее надо и как это доказать лицам, принимающим решения? Об этом я и хочу поговорить.

Математика и картинки

Между директором по информационной безопасности (Chief Information Security Officer, CISO) и вышеупомянутыми лицами, принимающими решения, — их я для краткости буду называть бизнесом — существует своего рода языковой барьер. Пока специалисты по безопасности оперируют такими понятиями, как «горизонтальное перемещение» и «поверхность атаки», бизнес смотрит на деятельность «безопасников» и в целом на ИТ-департамент как на расходы, которые следует минимизировать. Причем если в случае ИТ затраты можно «визуализировать» в виде закупленных серверов или лицензий ПО, то в случае ИБ подобное сделать сложно, поскольку функция это исключительно прикладная, глубоко интегрированная в ИТ и на высоком уровне абстракции едва различимая. Я люблю говорить, что ИБ — это одно из множества свойств ИТ, один из критериев качества информационных систем компании или предприятия. За качество, как мы понимаем, надо платить. В теории это понимает и бизнес, но в то же время задает справедливые вопросы: почему нужно заложить в бюджет именно озвученную CISO сумму и что в итоге за эти деньги получит компания?

Исторически запросы на финансирование ИБ аргументируют различными «пугалками»: бизнесу рассказывают о тех или иных актуальных инцидентах, например об атаках вымогателей или утечках данных, а затем утверждают, что от перечисленных ужасов может помочь определенное решение. В качестве поддержки используются статьи в профильной (и не очень) прессе, содержащие описание и примерную оценку ущерба, а также прайс-лист поставщика. Однако такой подход хорош только на первых порах и не гарантирует повторяемость, тогда как в наших интересах построить непрерывно совершенствующийся операционный процесс, который позволит более-менее объективно и понятно для бизнеса измерять ландшафт угроз и адаптировать под него корпоративную систему контролей безопасности. Поэтому отложим «пугалки» в сторону — как подход, имеющий серьезные проблемы с эффективностью и результативностью — и вооружимся релевантными параметрами.

Но сначала отмечу, что люди не очень хорошо воспринимают текстовую информацию. Гораздо лучше работают таблицы, а еще лучше — изображения. Поэтому для разговора с бизнесом о необходимости совершенствовать систему управления ИБ рекомендую запастись красочными графиками и картинками, отражающими современный ландшафт угроз и возможности операционной безопасности. Успеха можно ожидать тогда, когда на представленных специалистом слайдах возможности операционной безопасности (скажу проще — возможности SOC) соответствуют современным угрозам.

Для сравнения ландшафта угроз с результативностью SOC данные следует выражать в одинаковых величинах. Эффективность и результативность SOC, как и любого операционного подразделения, тем более имеющего какие-либо соглашения об уровне сервиса (Service Level Agreement, SLA), постоянно измеряются, поэтому вполне логично переиспользовать метрики SOC для оценки уровня достаточности безопасности. С измерением ландшафта угроз все немного сложнее. Оценивать угрозы следует по множеству параметров: чем больше различных характеристик потенциальных атакующих мы оценим, тем больше шансов получить объективную картину. Я бы хотел остановиться на двух наиболее очевидных параметрах, которые достаточно просто вычислить и в то же время легко объяснить без сложных технических терминов.

Среднее время до обнаружения атаки

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

Соответственно, со стороны SOC требуется своевременное обнаружение и локализация атаки, что обычно выражается двумя показателями: средним временем обнаружения (Mean time to detect, MTTD) и средним временем реакции (Mean time to respond, MTTR). Оба должны быть меньше, чем среднее время атакующего для достижения цели — вне зависимости от типа атаки.

Время, требуемое на расследование

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

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

На мой взгляд, показатели, демонстрирующие (не)возможность нашего SOC обнаружить угрозу прежде, чем ее развитие приведет к ущербу, значительно более наглядны для бизнеса. В совокупности со многими другими показателями, такими как «умеет ли наш SOC обнаруживать конкретные техники и инструменты атакующих?» или «выполняет ли наш SOC мониторинг конкретных потенциальных векторов проникновения?», они позволяют наиболее объективно оценить оперативную готовность SOC и более аргументированно обосновать бизнесу необходимость инвестиций в то или иное направление.

Работаем с источниками

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

Тем, кому еще не повезло набрать собственную статистику и опыт, рекомендую обратиться к внешним поставщикам аналитики, провайдерам услуг в сфере ИБ. Например, мы ежегодно публикуем аналитику по инцидентам от команды DFIR, откуда можно вычленить потенциальный профиль атакующего, а аналитический отчет от команды SOC позволит сформировать потенциальные целевые показатели возможностей SOC. Естественно, провайдер должен предоставлять данные не обо всем на свете, а обладать репрезентативной статистикой в той стране и той сфере, в которой заказчик осуществляет свою деятельность. Впрочем, и внешние источники не будут лишними для опытных сотрудников, опирающихся на собственные данные. Они помогут узнавать о новых угрозах, которые стали актуальны для индустрии в целом, но еще не попали в поле зрения сотрудников SOC конкретной организации. Кроме того, внешние данные позволят сравнить свои показатели с представленными поставщиками услуг и в очередной раз ответить на вопрос о возможности выполнения работ своими силами или о необходимости использования аутсорсинга.

Ответ на заданный вопрос

Фактически стоимость необходимой безопасности — это разница между способностями атакующих и возможностями команды SOC. При условии, что первые оцениваются на базе фактических инцидентов и релевантной статистики, а вторые — на базе метрик SOC. Здесь лучше других подойдут упомянутые мной MTTD и MTTR, поскольку они более понятны принимающим решения лицам, чем модель оценки зрелости SOC и другие академические доводы. По моему мнению, именно сочетание операционных метрик, построенных на основе как данных работы собственных подразделений, так и аналитических отчетов провайдеров услуг ИБ, позволяет достичь правильного баланса, который в итоге приведет к желаемым результативности и эффективности при допустимой стоимости. Одним словом — к красоте.

Сколько безопасности достаточно?

Ваш e-mail не будет опубликован. Обязательные поля помечены *

 

Отчеты

Таргетированная атака на промышленные предприятия и государственные учреждения

Эксперты Kaspersky ICS CERT выявили волну атак на предприятия и государственные учреждения нескольких стран Восточной Европы и Афганистана. В ходе исследования выявлено вредоносное ПО, ранее использованное в атаках, которые другие исследователи отнесли к APT TA428.

ToddyCat: неизвестная APT-группа, нацеленная на организации Европы и Азии

ToddyCat является относительно новой APT-группой, ответственной за серии атак на высокостатусные организации Европы и Азии. Два ключевых отличительных признака этой группы — ранее неизвестные инструменты, которые мы назвали «бэкдор Samurai» и «троянец Ninja».

Lazarus распространяет протрояненный DeFi-кошелек

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

MoonBounce: скрытая угроза в UEFI

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

Подпишитесь на еженедельную рассылку

Самая актуальная аналитика – в вашем почтовом ящике