Как строить информационную безопасность в условиях меняющихся требований

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

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

Новые требования не всегда требуют новых средств защиты

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

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

Если компания сегодня проектирует ИБ с нуля, я бы не советовал пытаться предсказать конкретные требования, которые появятся через несколько лет. Полезнее задать другие вопросы.

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

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

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

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

Регулятор говорит, что нужно обеспечить, но не должен проектировать за вас архитектуру

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

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

Есть и другой вопрос: появились ли сами риски вместе с новым требованием? Риски компрометации учетных записей и несанкционированного доступа существовали и раньше. Значит, новое требование — повод посмотреть шире: достаточно ли того, как компания управляла ими до сих пор, и не нужно ли помимо обязательных мер пересмотреть права доступа или другие процессы.

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

Контур Эгида — комплекс решений информационной безопасности, помогающий защитить бизнес от внутренних угроз.

Можно выполнить требования и остаться плохо защищенным

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

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

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

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

Строить лучше не вокруг документов, а вокруг контроля

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

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

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

Новое требование сначала должно попасть в гэп-анализ, а не в закупки

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

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

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

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

Гибкая архитектура — это не архитектура «на все случаи жизни»

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

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

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

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

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

Новое регулирование — это еще и проверка качества старой архитектуры

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

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

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

Не надо угадывать следующее требование

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

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

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

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

16+. Реклама. АО «ПФ «СКБ Контур». ОГРН 1026605606620. 620144, Екатеринбург, ул. Народной Воли, 19А. Erid: 2SDnjdSj2hy