Анализ коммуникаций — красная таблетка для офицера внутренней безопасности
Узнать большеПроблематика
О том, что информация стоит денег, люди знают давно. А вот понимание того, что потеря информации тоже имеет свою цену, стало приходить только в последние несколько лет. И с приходом этого понимания вопросы обеспечения ИБ начали наконец выходить на первый план, и компании всё чаще стали вкладываться в средства защиты информации от несанкционированного доступа (СЗИ от НСД). В том числе – и в DLP-системы.
Раньше DLP-системы были простые. Потому что требования к ним предъявлялись тоже простые: перехват корпоративной почты, печати. Может, запись на внешние носители. Остальная корпоративная среда в зону охвата DLP не попадала. Да и не то, чтобы была она слишком развита: хранилища –папки с общим доступом на локальном сервере, мессенджер - ICQ, а под облаками понимались исключительно атмосферные образования в небе.
С развитием корпоративной ИТ–инфраструктуры, соответственно, стали расти и запросы к DLP-системам: заказчикам уже мало было контролировать только почту и печать. Потребовался контроль мессенджеров, комнат данных, различных ИС, например, SharePoint или Confluence, систем электронного документооборота и пр. Теперь перед DLP-системами ставится задача «перехватывать всё» - данные со всех корпоративных ИС, находящиеся как в покое, так и в движении. Данная интеграция просто необходима для обеспечения необходимого уровня ИБ, особенно в наши непростые времена.
К сожалению, в настоящий момент эта трудновыполнимая задача – в техническом плане такое просто не всегда возможно: где-то можно перехватить трафик, например, с использованием реверсивного прокси-сервера, где-то нет. У одной программы есть прямой внешний коннектор, а у другой он отсутствует. Но даже если удастся направить трафик с ИС в DLP, всё равно требуется проведение НИРов, чтобы информация в DLP-системе отображалась корректно. Но на всё это необходимы дополнительные инвестиции и время. В итоге что-то получается интегрировать, что-то – нет. А может сложиться ситуация, когда интеграция вроде бы реализована, но не полностью: например, перехваты идут, но не в полном объёме или без блокировок. Получается, что результат попытки интеграции не гарантирован.
Технические аспекты интеграции
В целом, при интеграции ИС с DLP всегда встают две проблемы: первая связана с получением и обработкой трафика, приходящего от ИС в DLP-систему, а вторая – с передачей ответов DLP-системы в ИС.
Разберём их подробнее.
1. Получение информации DLP-системой от ИС.
Проблема получения DLP-системой данных от ИС состоит в следующем:
a. Отсутствие единого формата.
Разные ИС передают информацию во внешние системы в разных форматах представления: например, в формате json, или xml, а то и просто как текст. Метаданные могут передаваться как в заголовках, так и в теле сообщения.
b. Состав сообщения.
Тут основная проблема: недостаток передаваемых атрибутов, например, отсутствие адресной информации (для мессенджеров – это данные об отправителе и получателе). Для антивирусов может быть этого и достаточно, но не для DLP-системы, которая должна осуществлять привязку зарегистрированной информации к её владельцам.
c. Контекст.
Один объект, например сообщение, может из ИС передаваться в DLP раздельными фрагментами, например - отдельно текст, отдельно файл. Как следствие – теряется целостность объекта, для представления его в DLP требуется создавать механизм его предварительной сборки вручную.
2. Обработка ИС ответов от DLP для активного противодействия (блокировки передачи запрещённого контента).
DLP-система по своему назначению, в первую очередь, должна обеспечивать предотвращение утечки информации, а значит, обрабатывать данные, поступившие от ИС, в активном режиме, например, при выявлении нарушения правил хранения информации осуществлять блокировку доступа к данным. Протоколы HTTP и ICAP, которые для этого обычно используются, в принципе позволяют настроить интерактивное взаимодействие ИС с DLP. Но далеко не во всех ИС предусмотрен механизм приёма и обработки ответов от DLP. Например, многие мессенджеры не понимают информацию, полученную по протоколу ICAP от DLP-системы, и просто не знают, что надо делать.
При обработке ответного трафика от DLP к ИС, следует обратить внимание ещё и на время ожидания отклика: этот параметр должен быть управляемым, в зависимости от сложности применяемых в DLP политик.
Резюмируя, можно сказать, что многие ИС, если и имеют возможность передавать в DLP свой трафик, то в виде, далёком от желаемого (так как специфика взаимодействия ИС с DLP не учитывалась). А с обработкой ответов от DLP у ИС дела обстоят ещё хуже. В итоге получается, что каждая интеграция превращается для компании в отдельный трудозатратный проект, требующий участия обеих сторон (разработчиков ИС и DLP), и при этом – с негарантированным результатом.
Мы подходим к пониманию того, что для обеспечения нормальной интеграции ИС c DLP – для 100-процентной передачи информации в DLP в соответствии с требованиями DLP, а также обеспечения работы связки ИС-DLP-ИС в активном режиме, – необходимо провести унификацию протоколов взаимодействия (форматов запроса и форматов ответа) в единый стандарт.
Свет надежды
Сейчас у нас уникальное время. Многие иностранные ИС заменяются отечественными аналогами. Задачи перед нашими производителями стоят колоссальные: в короткий срок заместить огромный срез зарубежных ИС, при этом сделать хорошо, и даже лучше, чем было (в итоге многие отечественные ИС, в т.ч. вновь созданные действительно оказались не хуже, а то и лучше западных систем). Но бросив все ресурсы на функциональность, разработчики порой забывают про возможности интеграции своих продуктов со смежными системами. И это понятно: программисты на вес золота, да тут ещё и цейтнот. А заказчик, у которого главная задача – срочно импортозаместить, к примеру, SharePoint (лицензия на который уже просрочена), и надо как можно быстрее выбрать и заново внедрить отечественный аналог, тоже вспоминает про интеграцию с СЗИ уже после сдачи ИС в эксплуатацию. И начинаются те самые танцы с бубном: трудозатраты, время – дополнительный расход ресурсов, о котором писалось выше.
Что же делать?
На первый взгляд, кажется, всё просто: при создании ИС, ещё на этапе её проектирования предусматривать создание универсального коннектора с внешним ПО, в таком объёме, чтобы он подходил и для СЗИ (в т.ч. – DLP-систем). Но, повторюсь, отечественным производителям ПО в условиях жёсткого дефицита ресурсов просто некогда этим заниматься. Заказчики требуют просто работающий продукт (у них тоже голова другим занята, помните?), и на продажи отсутствие коннектора не влияет. А проблемы интеграции можно решить и потом, по мере поступления. Да и вообще, пусть производители DLP разбираются. Это уже их боль.
Действительно, главный вопрос: зачем это разработчикам ИС. Ведь проблема интеграции стоит перед DLP. Я бы ответил так: проблема это не у DLP, а у бизнеса. А мы все зависим от бизнеса. И устойчивое экономическое состояние бизнеса во многом зависит от состояния ИБ: собственно говоря - способности корпоративных СЗИ своевременно выявлять проблемы безопасности и оперативно их решать. Именно поэтому в наших общих интересах обеспечить бесшовную интеграцию ИС (как бизнесовых, так и ИБ-шных) в корпоративную IT-инфраструктуру. В данном случае это обеспечение взаимодействия между собой ИС с СЗИ. Это как повысит привлекательность таких продуктов на рынке, так и обеспечит общий высокий уровень ИБ в отечественном ИТ-сегменте.
В заключении о единообразии.
Для того чтобы обеспечить интеграцию ИС с DLP, конечно потребуется не просто предусматривать в ИС какой-то механизм взаимодействия. Этого мало. Он должен быть унифицированным, и унификация это должна быть описана в нормативной документации как стандарт. Например – на уровне ГОСТа, в котором будет закреплена необходимость наличия универсальных коннекторов для СЗИ в ИС. Внедрение такого ГОСТа приведёт к тому, что крупный отечественный бизнес сможет рассматривать на конкурсах только такие перспективные ИС, в которых будет реализован коннектор с СЗИ. А за крупными компаниями подтянутся и остальные. В итоге у нас будет решена ещё одна немаловажная проблема ИБ.
