Система информационной безопасности обычно начинается с определения критичных информационных активов и оценки рисков для них. По результатам этой работы проектируется и строится архитектура системы, а затем проектируется и внедряется техническая  составляющая  ее поддержки, включающая антивирусы, системы защиты от утечек данных, системы защиты от атак извне и др. Построив ту или иную систему защиты, большинство организаций, как правило, на этом и останавливаются. Однако после того, как такая система запущена и начинает функционировать, целесообразно проверить, самостоятельно или с помощью внешних компаний, насколько она справляется с задачей защиты информации. Организация может иметь выделенное подразделение информационной безопасности или по крайне мере отдел ИТ, в ней могут быть внедрены и функционировать антивирусная система, система межсетевого экранирования, шифрование каналов связи, а также система предотвращения вторжений (Intrusion Prevention System, IPS). Возможно, в ней не будет только системы защиты от утечек данных (Data Leak Protection, DLP) — однако созданная система информационной безопасности не всегда обеспечит защиту информации.

Для проверки системы информационной безопасности применяется тестирование на проникновение путем выполнения попыток преодолеть защиту с помощью «пентестов» (от англ — penetration testing, сокр. англ. — pentest). Такое тестирование обычно проводится по методу черного ящика — тестировщику ничего не известно о системе.

В ряде случаев используется метод «серого» ящика, когда тестировщик обладает некоторой информацией об устройстве системы защиты. Этот метод применяется в случае, когда особого внимания требуют какие-то определенные функции или сервисы проверяемого объекта. Частичное знание позволяет расширить спектр методов атак для проверки целевых сервисов в стрессовых условиях — например, при проверке новой корпоративной системы авторизации тестировщик знает, как устроен механизм хранения реквизитов доступа и обработки данных.

Методика тестирования может включать следующие этапы:

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

Крупная компания, предоставляющая веб-сервис, к которому имеют доступ организации со всей России, решила провести независимую оценку по методу черного ящика. Уже на этапе сканировании автосканерами выяснилось, что серверы функционируют под управлением устаревшего ПО, со времени выхода которого производитель выпустил ряд заплат устранения уязвимостей, а дополнительное тестирование вручную выявило еще ряд любопытных моментов. В компании использовалась система управления контентом (Content Management System, CMS), для расширения функционала которой привлекалась сторонняя организация. При добавлении новых форм ввода специалисты не распространили на них базовые механизмы безопасности CMS. В итоге появились формы ввода, при переходе на которые открывалась возможность, например, кросс-сайтовых атак. Следует отметить, что это весьма распространенная ситуация, избежать которой можно, тщательно проинспектировав в системе все нововведения, сделанные привлеченными специалистами.

Данная компания предоставляет веб-сервисы, используя хорошо зарекомендовавший себя веб-сервер Nginx [1], уже давно обслуживающий серверы ряда высоконагруженных российских сайтов, таких как «Яндекс», Mail.Ru, «ВКонтакте» и «Рамблер», однако в его настройках были выявлены уязвимости, позволяющие получать доступ к ресурсам организации. Для проверки устойчивости системы безопасности автосканеры оказались почти бесполезны — в случае с Nginx обнаружились лишь уязвимости типа «устаревшая версия ПО». Для старых версий веб-сервера известны несколько уязвимостей, которые могут приводить к отказу сервиса или получению доступа к конфиденциальной информации (выполнение удаленного кода, переполнение буфера). В версии, применяемой в данной компании, Nginx некорректно обрабатывал файлы, содержащие пробел или нулевой символ в конце имени, что вело к возможности исполнения вредоносного кода на стороне сервера. Для выявления ошибок в конфигурировании маршрутизаторов было проведено тестирование вручную, которое выявило уязвимость в системе безопасности, возникшую по недосмотру сотрудника компании, отвечающего за информационную безопасность. Система защиты в принципе не может быть статична — требуется регулярно проверять состояние настроек ее конфигурирования.

До сих пор речь шла лишь о тестировании по методу черного ящика — были обнаружены лазейки, которыми может воспользоваться любой злоумышленник. Возникает вопрос: зачем тогда вообще нужны межсетевые экраны, IPS и т. д., если система все равно оказывается уязвимой? А если у потенциального злоумышленника будет сообщник внутри компании? По итогам пентеста данная организация решила провести полный аудит системы информационной безопасности, проведя ревизию ее компонентов. Аудит выявил типичную ошибку многих компаний — установили систему и забыли о ней, проигнорировав организационную составляющую процесса обеспечения информационной безопасности и строя систему по принципу «пока гром не грянет». Когда компанию начали одолевать вирусы — купили антивирус, когда начались внешние атаки на сервер — купили IPS, а после обнаружения утечек конфиденциальных данных приобрели систему DLP и т. д. Все это очень похоже на установку железной двери в картонной стене, когда забывают, что информационная безопасность зиждется на планомерном подходе, включающем составление моделей угроз, методичное введение организационных и технических мер защиты.

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

Представим, что имеется безобидный PDF-файл, не содержащий конфиденциальных сведений, и файл Word, содержащий описание производственных секретов компании или организации. Посредством обычной команды copy с атрибутом /b создается другой PDF-файл, визуально он является копией первого, однако его размер равен сумме двух файлов (безобидного .pdf и секретного .doc). При попытке отправить такую связку файлов за пределы корпоративной сети DLP-система молчит. Кто виноват в данной ситуации? Как бы то ни было, ответственность падет на сотрудника службы информационной безопасности, не предусмотревшего возникновение такого риска. Аудит может выявить такие ошибки, но спасут ситуацию только корректное построение модели угроз, защита информации на базе шифрования, грамотное развертывание и настройка системы DLP, которая используется лишь как вспомогательная система мониторинга утечек [2].

***

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

Литература

  1. Владислав Носков, Кирилл Криницын, Александр Пономарев. Балансировка масштабируемых приложений // Открытые системы.СУБД. — 2012. — № 8. — С. 50–53. URL: http://www.osp.ru/os/2012/08/13019244 (дата обращения 12.11.2014).
  2. Валерий Коржов. DLP на пути к расследованию инцидентов // Открытые системы.СУБД. — 2014. — № 8. — С. 22–23. URL: http://www.osp.ru/os/2014/08/13043489 (дата обращения 12.11.2014).
  3. Алексей Марков, Сергей Миронов, Валентин Цирлов. Выявление уязвимостей в программном коде // Открытые системы.СУБД. — 2005. — № 12. — С. 64–69. URL: http://www.osp.ru/os/2005/12/380655 (дата обращения 12.11.2014).

Вадим Галлямшин (pd@kontur.ru) — руководитель проектов внедрения систем информационной безопасности, Артур Скок — ведущий специалист по внедрению систем защиты, «СКБ Контур» (Екатеринбург).