4 ТОП-совета по защите от утечек информации по вине подрядчика

В последние пару лет постоянно растет число инцидентов ИБ и, соответственно, проектов по их расследованию. В прошлом году прирост составил 50%. За первые девять месяцев 2023 года, в сравнении с показателями за весь 2022 год, количество проектов по расследованию инцидентов утечек выросло на 76%. По данным Positive Research, подобный скачок может быть спровоцирован увеличением количества инцидентов ИБ вследствие последних геополитических и экономических событий в мире. Владимир Алтухов, руководитель технического центра «АйТи Бастион» отвечает на один из актуальнейших вопросов кибербеза для любой компании — от большой до маленькой: «Что делать, если у вашего подрядчика произошла утечка в области ИБ?»

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

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

Во-вторых, важно определить «зону поражения» —доступные подрядчику элементы инфраструктуры. Считать их, по умолчанию, скомпрометированными, провести комплекс мер, принятый в организации. Зачастую, это изолирование данных элементов, сканирование их на наличие malware и вирусов/троянских программ/чего угодно; а также — постановка на дополнительный мониторинг со стороны отдела ИБ. Далее необходимо установить связь зараженных хостов с остальной инфраструктурой, усилить контроль за ними, в целом, за счет все тех же мер.

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

Четвертое и не менее важное — отработка всех найденных на предыдущем шаге инцидентов. А помочь в решении данных задач может как изначально грамотная организация контура защиты, так и использование в последующем дополнительных систем защиты информации. Допустим, внедрение PAM-системы (Privileged Access Managment), например, системы контроля действий поставщиков услуг позволит существенно облегчить решение задач из пунктов 1-3, а именно:

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

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

1. Рекомендуется обеспечить повышенный контроль действий подрядчиков на инфраструктуре (пример с PAM-системой все еще актуален).
2. Настроить доступ до инфраструктуры по времени, для критичных систем — внедрить процедуру доступа по согласованию; возможно рассмотреть внедрение элементов двухфакторной аутентификации.
3. Регулярное сканирование инфраструктуры на вирусы и уязвимости, проведение обновлений как структурных элементов, так и средств защиты.
4. Проведение киберучений внутри с целью повышения качества реакций на инциденты информационной безопасности.

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