От черного ящика к прозрачности: что CEO должен знать об ИБ

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

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

Вот почему эффективность киберзащиты бизнеса напрямую зависит от прозрачности работы ИБ-департамента для высшего руководства. Вопрос в балансе: что именно необходимо показывать?

Почему нет ясности

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

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

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

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

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

Кстати, о допусках

Один из подходов в ИБ сформулирован как "безопасность через неясность", то есть непрозрачность в ИБ – дополнительная мера защиты. Приведу аналогию: закрывать все двери города даже не просто одинаковым замком, а замком одного типа – очевидно, плохая идея. В то же время оформлять фасады зданий в городе в гармонирующих стилях – вполне распространенная практика.

Получается, что пока методология носит достаточно общий характер и занимается "фасадами", она распространяется в сфере ИБ, несмотря на ограниченную эффективность. Конкретика же должна оставаться секретом, и многие безопасники считают, что не лучшая идея – допускать бизнес-методологов к "замочной скважине".

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

Неопределенность растет и за счет вариативности используемых инструментов. Богатый выбор производителей средств защиты – источник проблем и возможностей, о которых стоит поговорить отдельно.

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

Рассмотрим три варианта, по которым, как правило, оказывается построена система защиты современного предприятия.

Вариант 1. Почти недостижимый идеал

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

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

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

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

MSSP (Managed Security Service Provider – компании-провайдеры, которые предоставляют услуги по обеспечению информационной безопасности) широко используют дублирование функций. Типичные примеры – проверка одних и тех же подозрительных объектов, приходящих от их заказчиков, антивирусами разных производителей, получение данных об уязвимостях и угрозах (индикаторов компрометации) от нескольких поставщиков.

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

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

Вариант 2. Мультивендорный ИБ-ландшафт

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

Подключение в единую систему СЗИ различных классов от разных производителей снижает время реагирования на атаки. Даже в случае выхода из строя нескольких отдельных средств защиты время распознавания и реакции в большинстве случаев остается допустимым. При этом требования к вычислительным ресурсам у данного варианта системы защиты заметно ниже, как и стоимость владения, которая приемлема для большей части организаций, особенно если вендоры обеспечивают совместимость своих решений с продуктами других разработчиков, не являются сторонниками политики vendor lock-in.

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

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

1. Работа толкового интегратора на проекте создания системы защиты.
2. Готовность производителей идти навстречу ожиданиям клиента при интеграции своих продуктов.
3. Наличие системообразующего продукта – связующего звена, уже совместимого с продуктами выбранных вендоров, на котором можно построить свою методологию объединения.

Вариант 3. Метавселенная ИБ, или "зоопарк решений"

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

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

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

Заключение

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

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

Поставляемая такой системой управления обратная связь поможет адекватно оценивать действия ИБ-подразделений и своевременно выделять требуемые им ресурсы, в полном соответствии с общими приоритетами бизнеса. Если собственных возможностей пока не хватает – мало свободных рук – к системе можно подключить MSSP-компании, а к процессу ее создания – интегратора.