Как выстроить информационную безопасность бизнеса: от аудита до устойчивой системы защиты

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

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

Почему набор защитных программ ещё не образует систему безопасности

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

Поэтому информационная безопасность должна рассматриваться как сочетание трёх компонентов:

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

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

С чего начать построение защиты

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

Руководителю совместно с ИТ- и ИБ-специалистами стоит ответить как минимум на несколько вопросов:

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

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

Аудит как отправная точка

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

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

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

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

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

Как расставлять приоритеты

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

Ситуация	Почему она важна	Что проверить в первую очередь
Критичная система доступна из внешней сети	Расширяется поверхность атаки	Необходимость доступа, способы аутентификации, обновления и сетевые ограничения
У сотрудников избыточные права	Компрометация одной учётной записи может иметь более серьёзные последствия	Роли, привилегированные аккаунты и порядок пересмотра доступов
Резервные копии создаются, но восстановление не тестируется	Наличие копии ещё не означает возможность быстро вернуть систему в работу	Целостность копий, доступность и практическую процедуру восстановления
Обновления устанавливаются нерегулярно	Известные уязвимости могут оставаться доступными для эксплуатации	Инвентаризацию ПО, критичные обновления и процедуру их установки
Нет единого мониторинга событий	Инцидент может долго оставаться незамеченным	Источники журналов, правила оповещения и ответственных за анализ

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

Управление доступом: фундамент корпоративной защиты

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

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

Проверить стоит следующие процессы:

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

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

Защита данных требует понимания их жизненного цикла

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

Поэтому имеет смысл определить основные категории информации и проследить их путь:

1. Выяснить, откуда данные поступают.
2. Определить, в каких системах они обрабатываются.
3. Проверить, кто получает к ним доступ.
4. Установить, куда данные передаются.
5. Разобраться, где создаются копии.
6. Определить правила хранения и удаления.

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

Зачем проводить тестирование на проникновение

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

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

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

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

Технические средства нужно выбирать после постановки задачи

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

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

При выборе любого средства защиты полезно проверить:

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

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

Почему мониторинг не менее важен, чем профилактика

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

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

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

Как подготовиться к инциденту заранее

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

Минимальный организационный сценарий должен определять:

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

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

Резервные копии должны проверяться восстановлением

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

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

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

Сотрудники являются частью системы, а не её слабым местом по определению

Ошибочно строить безопасность только на запретах и считать пользователя неизбежной причиной инцидентов. Задача процессов — сделать безопасное поведение понятным и выполнимым.

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

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

Когда разумно привлекать внешних специалистов

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

Типичные ситуации:

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

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

Какие вопросы задать исполнителю до начала проекта

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

1. Что входит в область работ? Необходимо точно определить системы, процессы, подразделения и инфраструктуру, которые будут анализироваться.
2. Как будет определяться приоритет замечаний? Оценка должна помогать принимать решения, а не просто увеличивать число найденных недостатков.
3. Какой результат получит компания? Следует заранее понимать структуру отчёта, дорожной карты или другой документации.
4. Что потребуется от внутренней команды? Некоторые работы требуют интервью, доступа к конфигурациям, журналам и участия владельцев систем.
5. Как будут обрабатываться чувствительные сведения? Исполнитель может получить доступ к конфигурациям и другой значимой информации, поэтому порядок работы с ней необходимо определить заранее.
6. Предусмотрено ли сопровождение устранения проблем? Полезно понимать, ограничивается ли проект выявлением недостатков или включает помощь на следующем этапе.

Типичные ошибки при построении информационной безопасности

Покупать технологию раньше, чем определена проблема

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

Пытаться устранить все замечания одновременно

После первой комплексной проверки список задач может оказаться большим. Если не расставить приоритеты, ресурсы распределятся между критичными и незначительными проблемами. Рациональнее сначала уменьшить риски с наиболее серьёзными последствиями.

Сосредоточиться только на внешних атаках

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

Считать внедрение окончанием проекта

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

Измерять безопасность количеством средств защиты

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

Как построить практическую программу улучшений

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

1. Определить ключевые бизнес-процессы, системы и данные.
2. Инвентаризировать основные элементы инфраструктуры и доступ к ним.
3. Оценить существующие меры и существенные риски.
4. Проверить применимые организационные, договорные и регуляторные требования.
5. Разделить обнаруженные задачи по приоритету.
6. Сначала устранить критичные организационные и технические пробелы.
7. Спроектировать недостающие защитные меры и выбрать необходимые технологии.
8. Настроить мониторинг и порядок реагирования.
9. Проверить восстановление критичных систем.
10. Регулярно пересматривать риски после значимых изменений инфраструктуры.

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

Как понять, что система защиты действительно становится зрелее

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

Хорошими практическими признаками являются:

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

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

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