Три риска в информационной безопасности, которые компании не видят до инцидента
Утечки и взломы корпоративных систем не всегда начинаются со сложной атаки. Иногда компания сама годами поддерживает условия, которые выглядят нормальными для бизнеса и ИТ, но создают риск: сотрудники бесконтрольно используют рабочую почту на сторонних сайтах, уязвимое ПО остается без обновлений, а сведения о мерах защиты инфраструктуры подрядчика не проверены.
Общая проблема таких ситуаций в том, что формально все выглядит благополучно. Реальный риск обнаруживается только тогда, когда проверка выходит за пределы привычных показателей.
Разберем три случая из практики, в которых именно это и произошло.
Ошибка № 1. Сотрудники используют корпоративную почту на сторонних сайтах
Внешняя проверка одной компании не показала ничего тревожного. На доступных из интернета ресурсах не обнаружили уязвимостей, открытые порты контролировались.
Проблема нашлась в другом месте — в повседневных привычках сотрудников.
Специалисты проверили, появлялись ли корпоративные адреса в известных наборах скомпрометированных данных. В открытом доступе обнаружились объявления о продаже списка адресов с домена организации и записи из утечек сторонних сервисов.
В наборах утечек обнаружили записи, связанные с корпоративными адресами. Такие совпадения требуют проверки: наличие адреса само по себе не подтверждает компрометацию пароля или действующей корпоративной учетной записи.
Здесь необходима важная оговорка: не вся база, которую в интернете называют «утечкой компании», действительно произошла именно из ее систем. Злоумышленники могут собирать сведения из нескольких старых инцидентов и публиковать их как новый массив, чтобы привлечь внимание или нанести репутационный ущерб.
Но для компании это не отменяет риска.
Рабочий email может стать началом цепочки:
корпоративный адрес попадает во внешнюю утечку → по нему устанавливают имя, должность и контакты сотрудника → человек получает персонализированное письмо или сообщение → злоумышленник пытается получить пароль, документ или доступ к корпоративной системе.
Это уже социальная инженерия: техническая защита может работать штатно, а атакующий убеждает самого сотрудника передать нужную информацию.
Особенно опасно повторное использование паролей
Если один пароль используется и на стороннем сервисе, и внутри корпоративной инфраструктуры, компрометация интернет-магазина, форума или другого внешнего ресурса может создать риск уже для компании.
Поэтому задача не заканчивается требованием «не регистрироваться с рабочей почты где попало».
Нужно определить, в каких внешних сервисах допустимо использовать рабочую почту, закрепить правила, применять многофакторную аутентификацию и периодически проверять появление корпоративных адресов и учетных данных в новых утечках.
Если такие требования пока существуют только как устная договоренность, их можно закрепить при разработке или модернизации локальных нормативных актов по информационной безопасности.
Ошибка № 2. Уязвимость исчезла из отчета, но не из инфраструктуры
В другом случае проблема обнаружилась при повторном сканировании.
Повторная проверка выявила больше уязвимостей критического и высокого уровней. В компании также обнаружились проблемы с получением и установкой обновлений.
Стандартная рекомендация очевидна — обновить программы.
В описанном случае компания не могла получить часть обновлений Microsoft по используемым каналам: автоматическое обновление не работало, а ручная проверка не показывала доступных исправлений.
С такой же проблемой организация сталкивалась и годом ранее.
Именно здесь стандартный процесс управления уязвимостями дал сбой. Типовой регламент исходил из предположения, что патч существует и его можно установить. Сценарий «исправление выпущено, но организация не может его получить» в процедуре не был предусмотрен.
Когда удаление ПО улучшает отчет, но не обязательно безопасность
Для компонентов с открытым исходным кодом решение удалось найти: специалисты компании пересобрали библиотеки и закрыли выявленные проблемы.
С Microsoft Defender и Teams поступили иначе — продукты удалили, и соответствующие строки исчезли из отчета.
Администратор сам назвал это «подстройкой задачи под результат».
Удаление ненужного уязвимого ПО может быть корректной мерой. Если же программа выполняла необходимую защитную функцию, нужно проверить, чем ее заменили и не создало ли удаление новые риски.
Похожая ситуация возникла с устаревшими библиотеками в составе MS Office. Компания не смогла установить необходимые обновления и решила оставить пакет: ее специалисты опасались проблем с восстановлением лицензий после удаления.
С точки зрения бизнеса такое решение может быть обоснованным. Проблема возникает тогда, когда оно не сопровождается оценкой и фиксацией остаточного риска.
Что делать, если обновить компонент невозможно
В такой ситуации нужен уже не только процесс установки патчей.
Полезно вести реестр используемого ПО, понимать источники обновлений и заранее определять альтернативные сценарии для компонентов, которые могут остаться без поддержки или доступных исправлений.
Для ПО, которое невозможно обновить, рассматриваются компенсирующие меры. В зависимости от системы это могут быть сетевая изоляция, ограничение функциональности или усиленный мониторинг.
Конкретный набор зависит от инфраструктуры.
Решение должно быть осознанным и задокументированным. При этом принятие остаточного риска не заменяет выполнение обязательных требований к защите данных.
Чистый отчет не равен отсутствию риска.
Если строка исчезла потому, что компонент удалили, отключили проверку или изменили конфигурацию, важно отдельно понять, что произошло с самой угрозой.
Проверьте не количество уязвимостей, а фактическое состояние защиты
Технический аудит информационных систем позволяет посмотреть шире результата одного сканирования: на инфраструктуру, настройки, доступы и реальные меры защиты.
Ошибка № 3. Сервер работает стабильно, но подтвердить его безопасность невозможно
Третий случай связан с решением, которое бизнес часто принимает один раз, а затем годами не пересматривает: где разместить серверы основной информационной системы персональных данных.
Компания использовала российского хостинг-провайдера.
При проверке соответствия требованиям статьи 19 152-ФЗ возник вопрос: чем подтвердить безопасность инфраструктуры, в которой находятся данные?
В открытых источниках не удалось найти достаточно сведений о мерах защиты, которые провайдер обеспечивает для размещенной ИСПДн. При этом уровень защищенности определяется для персональных данных при обработке в конкретной информационной системе по постановлению Правительства РФ № 1119. Обязательность аттестации зависит от применимых к системе требований.
Поручение на обработку между компанией и хостинг-провайдером не оформлялось. Если по фактической модели услуг провайдер обрабатывает ПДн по поручению компании, соответствующие условия должны быть закреплены в договоре по части 3 статьи 6 152-ФЗ.
При этом и при наличии поручения оператор отвечает перед субъектами ПДн за действия привлеченного лица — часть 5 статьи 6 152-ФЗ.
Здесь принципиальна одна оговорка.
Отсутствие подтверждающих документов на сайте провайдера само по себе не доказывает, что площадка небезопасна: общей обязанности публиковать такие документы нет.
Для оценки выполнения требований оператору нужны сведения о фактических мерах защиты и о том, какие из них обеспечивает провайдер, а какие сама компания.
Переносить инфраструктуру сразу тоже ошибка
Первая реакция может быть очевидной: если безопасность провайдера нельзя подтвердить, нужно срочно переносить серверы.
Но такой переезд сам создает бизнес-риски.
Это потенциальная остановка процессов, простой систем и сотрудников, временное снижение доступности сервисов, риск проблем после миграции и дополнительные расходы на восстановление нормальной работы.
Поэтому в описанном случае правильная последовательность начинается не с миграции.
Сначала нужно запросить у провайдера документы и сведения о мерах защиты на его стороне и сопоставить их с требованиями к своей информационной системе.
Ответ поможет определить, можно ли устранить выявленные пробелы на текущей площадке или потребуется менять инфраструктуру.
Если компания использует внешнюю или облачную инфраструктуру для обработки ПДн, отдельно можно проверить защиту персональных данных в облаке.
Что объединяет все три ошибки
На первый взгляд корпоративная почта на стороннем сайте, недоступное обновление и документы хостинг-провайдера никак не связаны.
Но во всех трех случаях повторяется одна и та же управленческая ошибка: компания принимает формальный признак благополучия за доказательство безопасности.
В первом случае проверка внешнего периметра не выявила уязвимостей, однако в сторонних утечках обнаружились корпоративные адреса.
Во втором сканер стал показывать меньше уязвимостей, но это не обязательно означало снижение остаточного риска.
В третьем инфраструктура стабильно работала, однако оператору требовалось проверить меры защиты на стороне провайдера.
Поэтому информационная безопасность требует не только технических средств, но и процесса принятия решений: что считаем риском, чем подтверждаем его снижение и кто принимает остаточный риск, если полностью устранить проблему невозможно.
Именно этот более широкий контур входит в задачи информационной безопасности и ИБ-комплаенса.
Что стоит проверить у себя
Для быстрой самопроверки можно начать с трех вопросов.
Корпоративные учетные записи. Знает ли компания, где сотрудники используют рабочие адреса и появляются ли они в сторонних утечках?
Уязвимости. Есть ли процесс для ситуации, когда исправление невозможно установить, и фиксируются ли компенсирующие меры и остаточный риск?
Подрядчики и инфраструктура. Может ли организация документально подтвердить меры защиты там, где фактически находятся ее данные?
Если хотя бы на один вопрос ответ строится на предположении «скорее всего все нормально», это уже повод посмотреть глубже.
Проверьте ИБ-контур не по отчету, а по фактическим рискам
Б-152 может провести обследование инфраструктуры, сопоставить технические меры с документами и помочь определить, где формальное выполнение процедур не подтверждает реальную защищенность.
Проверить инфраструктуру и меры защиты
Главное
Безопасность определяется не количеством зеленых строк в отчете.
Можно проверить внешний периметр и оставить без внимания риск, связанный с корпоративными адресами в сторонних утечках. Можно удалить уязвимый компонент и не заменить его необходимую функцию. Можно разместить сервер в надежном ЦОД, но не проверить, какие меры защиты провайдер обеспечивает для конкретной системы.
Во всех этих случаях проблема становится заметна только после вопроса: что именно подтверждает, что риск действительно снижен?
Если ответа нет, благополучный отчет может оказаться только формальностью.