Кибербезопасность бизнеса: утечки данных, уязвимости ПО и риски при работе с подрядчиками

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

Утечки данных и взломы корпоративных систем редко связаны исключительно с изощренными атаками хакеров. 

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

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

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

Кейс 1. Вы когда-нибудь регистрировались на сторонних сайтах с корпоративной почты?

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

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

В открытом доступе обнаружились объявления о продаже списка адресов с корпоративного домена, а также записи из утечек сторонних сервисов. Всего по домену выявили 927 скомпрометированных пользователей, 20 сотрудников и 3 набора учётных данных сторонних сервисов.

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

Чем это опасно?

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

Отдельный риск связан с паролями. Если сотрудник использует один и тот же пароль для сторонних сервисов и корпоративных систем, утечка данных интернет-магазина или форума может открыть злоумышленникам путь к инфраструктуре компании.

Что делать?

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

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

Кейс 2. Обновление программ недоступно из-за санкций: отчёт показывает уязвимости, но даже обновление не всегда решает проблему

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

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

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

Для программ с открытым исходным кодом решение нашли: специалисты компании пересобрали библиотеки и устранили выявленные уязвимости. С продуктами Microsoft поступили иначе — удалили Defender и Teams, после чего соответствующие записи исчезли из отчёта.

Сам администратор назвал этот шаг «подстройкой задачи под результат». Записи об уязвимостях больше не было, но это не означало, что риск устранён. Особенно опасно такое решение, если удалённые средства защиты не заменили альтернативными.

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

Вывод: как с этим бороться

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

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

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

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

Кейс 3. Безопасность сервера, на котором хранились данные, не удалось подтвердить ни заказчику, ни проверяющим

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

Вопросы возникли при проверке соответствия требованиям статьи 19 Федерального закона № 152-ФЗ «О персональных данных»: подтвердить безопасность серверной инфраструктуры документально не удалось.

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

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

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

Исправление может стоить дороже проблемы

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

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

Что с этим делать?

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

Заключение

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

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

Илья Балберов

специалист по ИБ компании Б-152