Тема сегодняшнего мероприятия - новая версия InfoWatch Traffic Monitor 6.11, о которой расскажет Александр Клевцов, руководитель DLP-направления компании InfoWatch, идеолог InfoWatch Traffic Monitor.
Traffic Monitor версии 6.11. вышел на рынок в декабре 2019 года. В нем появилось несколько новых функциональностей, среди них - защита векторных чертежей.
В результате анализа было выяснено, что около 20% заказчикам InfoWatch, работающим в производственных компаниях, в оборонно-промышленным комплексе, очень важна защита векторных данных. Представим себе такой сценарий (см. слайд).
Предположим, что существует некое конструкторское бюро, которое одновременно занимается оборонными и гражданскими проектами. Сейчас это очень распространенная практика, тем более, на законодательном уровне от КБ требуют заниматься конверсией, производством гражданских изделий, повышая тем самым свою прибыльность. И вот представьте, что, исходя из политик безопасности этого КБ, данные гражданских проектов могут пересылаться за периметр компании заказчикам, партнерам, поставщикам и т.д., в том числе и CAD-систем, тогда как аналогичная пересылка данных для материалов оборонных проектов неприемлема. Эти данные нельзя перемещать по почте или каким бы то ни было иным способом обмениваться секретной информацией с внешним миром. И вот представьте ситуацию, что конструктор, работающий над гражданским чертежом, по ошибке (а может быть и специально) вставил данные (либо фрагмент) из чертежа оборонного проекта в чертеж проекта гражданского, который уже может перемещаться за периметр.
Как отследить этот момент? Как детектировать, что чертеж не конфиденциального документа содержит фрагмент конфиденциального чертежа? Компания InfoWatch для этого разработали технологию «Векторные цифровые отпечатки». Технология запатентована и позволяет обнаруживать даже маленький конфиденциальный фрагмент даже перевернутый, даже с измененным масштабом, в любом другом не конфиденциальном чертеже. У вас есть, например, база конфиденциальных фрагментов и чертежей. Вы «скормили» эту базу системе InfoWatch Traffic Monitor, обучили ее, и впоследствии, если кто-то будет передавать за периметр компании или выполнять с чертежами какую-то другую операцию, и даже если этот чертеж будет содержать самый маленький фрагмент, даже часть конфиденциального чертежа, эта ситуация будет детектирована. Потому что технология анализирует векторные изображения, анализирует, что содержит чертеж, какие фрагменты его являются конфиденциальными, а какие нет. Можно указывать процент срабатывания, т.е. релевантность для каждого чертежа. Например, вы можете загрузить один большой чертеж танка в трех проекциях, с детализацией мотора или шасси, и впоследствии, если кто-то сделает копипас с этого чертежа, скопировал его небольшой фрагмент, все равно система обнаружит, что пересылаемые данные содержат фрагмент конфиденциального чертежа.
Сейчас на рынке подобных технологий недостаточно. Существующий сигнатурный анализ может определить, что файл чертежа, например чертежа AutoCad, допустим, переименован, что некий новый файл относится к чертежам AutoCad, но не сможет определить, что именно этот чертеж является конфиденциальным. Тем более сигнатурный анализ не позволяет детектировать наличие в чертеже конфиденциальных фрагментов. Есть технология бинарных цифровых отпечатков, их можно использовать для защиты векторных цифровых отпечатков, но эта технология не позволяет находить маленькие фрагменты, т.е. когда чертеж содержит какую-то небольшую часть конфиденциального чертежа. Эта технология применима только при нахождении каких-то больших часте чертежа, не перевернутых, не измененных в масштабе и т. д. Т. е. когда детектируем чертеж в чертеж. Это и есть бинарные цифровые отпечатки.
Для избежания ложных срабатываний системы можно в качестве эталонного документа загрузить большой чертеж. И отметить, например, что любые 10% этого чертежа являются конфиденциальными. И тогда, когда 10% осмысленности фрагмента у вас будет попадаться, будет срабатывать политика. А можно поступить по-другому. Можно ваши конфиденциальные чертежи разбить на законченные фрагменты, например, на мотор или конфиденциальный узел, или, скажем, фрагмент огнестрельного оружия, и уже задать релевантность для этого фрагмента 50% или 100%. Чтобы, как только он вдруг будет найден, тут же был бы задетектирован. Тут в зависимости от того, как вам будет удобно, либо конечные чертежи загрузить и указать релевантность 20%, либо чертежи разбить на законченные фрагменты, и указать им высокую релеватность, например, 80-90%. Тут нужно экспериментировать с самим материалом и смотреть, как это будет работать.
С данной технологией по защите векторных изображений была ознакомлена компания Autodesk, которая убедилась в её эффективности, и в результате у нас вышел совместный пресс-релиз. Центральный научно-исследовательский институт автоматики и гидравлики (ЦНИИАГ) также разрешил нам публиковать референс. Он тоже на своей площадке опробовал эту технологию и убедился в ее эффективности. Повторю, эта технология запатентована, все ее алгоритмы связаны с разбором и анализом изображений. С полной уверенностью можно сказать, что эта технология уникальна.
Контроль публикаций в соцсетях
Это реальная история, которую, наверное, можно найти в Интернете. Сотрудник судоверфи закончил свой рабочий день, получил на КПП свой личный смартфон. Затем он написал в социальной сети, что на такой-то судоверфи начались испытания новой подводной лодки и указал ее номенклатурный номер. Т.е. совершил, по сути, преступление. Как можно выявлять такие нарушения? В версии 6.11 появился механизм, который позволяет выявлять публикации в социальных сетях, которые содержат нарушения.
Например, утечку коммерческой тайны, какую-либо конфиденциальную информацию, публикацию персональных данных и т. д. Причем выявление этих утечек происходит даже в том случае, если сотрудник сделает публикацию с личного устройства (смартфона или ноутбука) вне корпоративной сети. Естественно речь идет только о выявлении грубых нарушений, связанных с утечкой информации, нарушении коммерческой тайны, обнародовании персональных данных, дискредитации компании и т.п. Эта возможность была достигнута с помощью интеграции системы Kribrum, которая собирает открытые, публичные данные в социальных сетях и передает в Traffic Monitor на анализ. Речь идет только о публичных постах, потому что весь этот механизм работает только в рамках закона. Ни о каком анализе личных сообщений и закрытых публикаций речь не идет. Опять же подчеркну, что мы не ставим себе цель отслеживать ленту сотрудника, его посты, изыскания в социальных сетях. Речь идет только о выявлении публичных постов, которые содержат грубые нарушения.
По словам Александра Клевцова, каждую технологию нужно использовать с умом. Подразумевается, что эта технология будет использоваться только для сотрудников из группы риска. Во-вторых, оседает в DLP-системе только информация о постах, которые содержат нарушения. Речь идет о рисках при нарушении очень серьезных политик. Если в посте нет номенклатурных номеров, и эти данные никак не подпадают под политику безопасности, то и в DLP-системе в данном случае данные сохраняться не будут.
Тут у участника мероприятия возник вопрос: если аккаунт закрыт, или если это чужой аккаунт, с которого идет постинг публикаций, как определяется, что этот аккаунт принадлежит сотруднику? И что делать с обезличенными аккаунтами в соцсетях?
Ответ. Для того чтобы определять аккаунты сотрудников есть два режима. Первый - ручной. Допустим, у вас есть десять сотрудников, которые работают над конфиденциальным закрытым проектом с ограниченным доступом. Можно вручную добавить этих сотрудников для мониторинга за их публикациями в соцсетях. В случае использования второго режима Traffic Monitor в автоматическом режиме выделяет аккаунт сотрудника в соцсетях в зависимости от его трафика. Но это возможно только, если сотрудник работает с соцсетями в своей корпоративной среде.
Допустим вы являетесь заказчиком и приобрели Kribrum и Traffic Monitor, теперь у вас есть возможность лицензировать еще и интеграцию между этими продуктами и использовать эту функциональность. Затем нужно развернуть и настроить определенный адаптер, который будет осуществлять интеграцию через API Traffic Monitor.
Тонкости блокировки
Представьте, что у вас есть публичная компания, которая готовится к слиянию или поглощению. И данные об этом доступны только нескольким сотрудникам. Это менеджер проекта, финансовый директор и юрист.
И все материалы по этому проекту хранятся в определенной папке. Нужно сделать так, чтобы все эти сотрудники, работающие с этой информацией, никуда больше ее скопировать не могли, ни по ошибке, ни специально. Все, что связано со слиянием и поглощением, они должны копировать, перемещать только между своими рабочими станциями и этой конкретной сетевой папкой. Т.е. надо выделить сетевой ресурс, к которой будут иметь доступ только эти три сотрудника, и они информацию из этой папки смогут переносить на свою рабочую станцию, работать с ней и обратно ее возвращать.
Как это можно сделать? В версии 6.11 появилась новая функциональность, позволяющая не просто мониторить сетевые операции внутри инфраструктуры, такие, как перемещения между рабочими станциями, сетевыми папками и т.д. Но и блокировать эти операции по результатам анализа. Например, менеджер проекта пытается скопировать какую-то смету или договор в папку с фотографиями, система заблокирует эту операцию. Копировать же в легитимную папку, она позволит. Или наоборот, если сотрудник попытается из этой папки забрать какой-то документ и перенести его на сервер, то такая операция будет заблокирована.
Версия 6.11 позволяет блокировать операции между сетевыми папками и рабочими станциями в оба направления. Контролируются и блокируются файлы, перемещаемые в FTP-сервера и в FTP-папки. Блокировку по результатам анализа можно настроить таким образом, что будет блокироваться канал при перемещении файлов через терминальные соединения.
Другой пример. Допустим, у вас есть сотрудники, работающие удаленно. И определенную категорию информации нельзя переносить на удаленные, например, домашние компьютеры. Терминальные соединения можно настроить так, что некоторые не конфиденциальные документы можно будет переместить на домашний компьютер, а другие документы будут блокироваться при перемещении через терминальное соединение. Все это делается очень просто с помощью технологии анализа, в которой используется полноценная лингвистика, а не примитивные стоп-слова или сигнатурный анализ.
Как можно использовать эту новую функциональную возможность? Вы можете расписать политики, как конфиденциальная информация может перемещаться в инфраструктуре компании между сетевыми папками, между рабочими станциями, FTP-ресурсами, терминальными соединениями. Это особенно важно, когда в компании есть несколько контуров открытых и закрытых. Когда есть закрытый контур, где функционирует какая-то ABS, а есть открытый контур, например, Интернет. И можно с помощью этой технологии реализовать следующий сценарий: конфиденциальная информация из закрытого контура в открытый попадать не может, а не конфиденциальная может свободно передвигаться между контурами.
Можно расписать все маршруты для передвижения файлов в инфраструктуре. И если файл при перемещении или копировании будет нарушать политику, эта операция будет заблокирована. Когда есть открытые и закрытые контуры, вы можете работать с нарушениями информации, с так называемыми утечками, на упреждение. Фиксировать факты, когда сотрудник накапливает информацию на своей рабочей станции, когда он ее еще никому не передал за периметр компании, но на своей рабочей станции он собирает эти файлы. Можно быстро фиксировать или блокировать операции, когда конфиденциальный документ перемещается в публичную папку вашей компании, проводить анализ, мониторинг прежде, чем документ покинет периметр, т.е. выявлять нарушения использования конфиденциальной информации в инфраструктуре.
Сейчас в политиках InfoWatch Traffic Monitor добавилось всего два поля в интерфейсе. Источник копирования и приемник копирования. И там можно детально указывать конкретные сетевые ресурсы, конкретные папки и т.д. И прописывать все маршруты.
Для того, чтобы блокировка файлов работала, нужно распространить агентов на рабочие станции или на файловые серверы, где находятся папки с конфиденциальными файлами. Можно зайти в политики в консоли Traffic Monitor и указать, что такие-то операции блокируются.
Если речь идет про закрытый контур, то нужно прежде всего понять, как сотрудники работают с данными этого контура. У кого-то этот закрытый контур имеет номинальный характер, какие-то определенные сетевые папки относятся к закрытой части инфраструктуры. У кого-то доступ к закрытому контуру осуществляется через терминальное соединение. Тогда вы просто заходите в политики и указываете, что перемещения определенной информации через терминальное соединение блокировать. Допустим, данные, связанные с закупками, блокировать через терминальное соединение. И эта конструкция заработает.
Как бы это странно ни звучало, но изменения в интерфейсе получились минимальными. Под капотом у системы контроль всех файловых операций, перемещений внутри сетевой инфраструктуры, между терминальными соединениями, в общем, в продукте было создано многое, а в интерфейсе добавилось всего два поля: «источник копирования» и «приемник копирования». Но, благодаря этим полям, можно указывать весь доступный спектр сетевых ресурсов, контролировать и блокировать перемещения.
На текущий момент версия 6.11 может блокировать следующие каналы: соцсети, облачные хранилища, веб-почту, съемные носители и всевозможные файловые протоколы.
Новые возможности версии 6.11
Теперь Александр Клевцов, переходит к менее значительным историям, но тем не менее также весьма полезным.
Итак, история №1. В версии 6.11 появилась новая возможность - ретроспективное сканирование почтовых архивов. Представьте, что у вас есть почтовый архив филиала компании, который был накоплен до внедрения DLP-системы. И вам бы хотелось знать, что в этом почтовом архиве хранится, были ли какие-то прецеденты. Особенно это важно при расследовании была ли там конфиденциальная информация. Вы подключаете этот почтовый архив к Traffic Monitor, загружается вся переписка в ретроспективе: месяц назад, три месяца назад до внедрения системы или более. Причем можно настроить систему таким образом, что, во-первых, указать определенный временной период сканирования. Во-вторых, указывать конкретную группу сотрудников, чтобы не задействовать весь архив, если он очень большой, а только, скажем, отдел аудиторов, или бухгалтерию. Плюс, что очень важно, при проведении расследования и анализе этой почтовой переписки, вы потом можете определять, были ли эти письма перехвачены во время отправки с помощью сетевого перехвата. Работает это следующим образом. Вы можете либо подключаться к конкретным серверам Microsoft Exchange, либо сканировать конкретные PST-архивы, допустим, изъятые у сотрудников или из филиала.
Следующая история связана с запароленными архивами.
Представьте себе такой сценарий. Есть внутренний злоумышленник, который вступил в преступный сговор с внешним злоумышленником. Один пообещал другому передать конфиденциальные документы. Для этого он скопировал и заархивировал в один архив несколько документов, запаролил их, открыл и передал по почте внешнему злоумышленнику. Как оценить что он передал в этом архиве? Дело в том в версии 6.11 появилась новая функциональная возможность по изъятию паролей, которые вводились в архиваторе. Появилась возможность по перехвату клавиатуры в конкретных приложениях.
Нужен перехват пароля в архиваторах WinRAR или WinZIP или каком-либо другом. Причем, для того, чтобы понимать как работал сотрудник с архиватором, эта функциональность позволяет также снимать скриншоты. Например, вы настроили политику таким образом, что система фиксирует пароли, вводимые в архиваторе, и когда сотрудник будет вводить эти данные в архиватор, будут сниматься скриншоты. В результате вы видите запароленный архив сотрудника Иванова, открываете событие, где есть этот пароль, расшифровываете перехваченный архив и можете посмотреть, что в нем содержится в связи с возникшей проблемой. Этот новый перехватчик называется Keyboard Monitor.
Совершенно не важно какие архиваторы при этом используются. Можно Keyboard Monitor настроить на любой архиватор, даже самописный. Вы можете снимать данные, которые вводились в этот архиватор без каких-либо проблем, скриншоты и вводимый текст. Это в некотором смысле универсальное средство.
Следующая история. Представьте себе, что некий злоумышленник взял какой-то документ Word, например, с рецептом пирога, и дописал туда excel-файл с закупочными ценами.
Потом переименовал файл с расширением JPG и передал его за периметр компании. Новые возможности Traffic Monitor версии 6.11 позволяют не только выявлять переименования файла в несоответствующей сигнатуре, но и определять "склейку" двух файлов. Настраивается это в политиках в автоматическом режиме. Благодаря чему вы сразу сможете понять, что файл был склеен, или, что у него было изменено расширение, не соответствующее сигнатуре. На этом может быть отработана автоматическая политика. Потом, при мониторинге, вы при поиске событий сможете в явном виде задавать атрибуты, найти события с измененной сигнатурой или найти склеенные файлы.
При копировании на флэшку, система также поддерживается блокировка по несоответствию сигнатуры и расширению файла. Вот простой сценарий. Сотрудник переименовал документ MS Word, дал ему расширение JPG и пытается скопировать его на флэшку. Эта операция будет заблокирована. И неважно, содержит ли файл конфиденциальную информацию, или нет. Потому что такие операции, как дописывание файлов, вкладывание одного в другой, склейка либо переименование сигнатуры уже свидетельствует о намеренной попытке маскировать информацию. Для легитимных, повседневный операций это совершенно не характерно.
Представьте у вас в компании есть сотни договоров на закупку каких-то номенклатурных изделий. Все эти договора могут меняться, редактироваться, дополняться, становиться неактуальными и т.д.
Перед представителями службы безопасности, стоит задача: всеми средствами защищать актуальные данные. Что вам для этого нужно делать? Первый вариант - постоянно общаться, например, с закупочным отделом и отслеживать, какой договор изменился, какой перестал быть актуальным, какие изменения внесены в договоры и т.д. Но когда у вас с этими данными работают сотни человек, решение такой задачи таким способом становится просто невозможным.
В версии 6.11 появилась новая функциональная возможность по автоматическому обновлению цифровых отпечатков. Представьте, что у вас есть сетевая папка, в которой хранятся все договоры. С ней работают сотни сотрудников. Они в эту папку вносят новые договоры, редактируют их, вносят изменения. Можно настроить DLP-систему таким образом, что база цифровых отпечатков будет постоянно синхронизироваться, обновляться и поддерживаться в актуальном состоянии. Например, если некий договор был удален, то из базы цифровых отпечатков он тоже удаляется. Если договор изменился, то и цифровой отпечаток, соответствующий этому договору будет изменен. Если в договор внесены дополнения, то и в цифровые отпечатки они будут также внесены. Вся база поддерживается в актуальном состоянии.
Теперь становится не нужным вручную загружать цифровые отпечатки и отслеживать изменения, вносимые в документы. Актуализировать эту базу цифровых отпечатков можно не только из сетевой папки, но и интегрировать это с бизнес-системой, в которой эти данные хранятся. Будет ли это система документооборота или ERP-система, не важно. Можно настроить таким образом, что все это будет синхронизироваться в автоматическом режиме.
Также появилась новая техническая возможность у API InfoWatch Traffic Monitor как раз для автоматической актуализации. И для этого API был написан специальный адаптер, который сканирует почтовый папки. Через это API можно сканировать как сетевые папки, так и систему электронного документооборота, или CRM-систему.
И еще одна история, связанная с интеграцией, с новыми возможностями API
История называется «соки-воды». Представьте, что вы внедряете систему по обработке инцидентов. Вы организовываете SOC-центр и хотите, чтобы в единой консоли у вас обрабатывались инциденты не только из DLP-системы, но и из антивируса или еще откуда-то. И вот новая интеграционная возможность версии 6.11 позволяет не только импортировать данные из DLP-системы в SOC-центр, но и из этого SOC-центра менять решение об инциденте в DLP-системе.
Скажем, офицер безопасности работает в единой консоли SOC-центра по обработке инцидентов и видит нарушение, пришедшее из Traffic Monitor, нажимает кнопку «Признать это нарушением», и это решение будет импортировано в Traffic Monitor и передано из SOC-центра в DLP-систему. Подобная интеграция уже была апробирована с вендором Secerity Vision, с их решением по организации SOC-центров, были проведены тестовые пилотные проекты. Эта конструкция хорошо работала в рамках пилотного проекта.
Следующая история также связана с новыми возможностями API.
Эта функциональная возможность скорее подойдет не для конечного заказчика, не для офицера безопасности, а именно для партнеров, для интеграторов, для вендоров, которые хотят осуществлять интеграцию с Traffic Monitor. Ну и для заказчиков, у которых есть свои центры разработок, и они хотели бы расширить свои возможности по использованию средств безопасности. Представьте, что вы хотите интегрировать свою DLP-систему, в данном случае Traffic Monitor, с корпоративным облаком и принимать решения по инцидентам, по событиям из этого облака, основанных не только на файлах, которые там опубликованы или скачаны, но и по расширенному списку атрибутов. Например, вы захотите узнать, какое устройство было использовано сотрудником рабочей станции, когда он публиковал в облако определенный файл, либо, наоборот, скачивал его. Где находился сотрудник, когда опубликовывал или скачивал файл, модель его устройства, объемы этих файлов и т.д. Т.е. вы хотите понимать при расследовании инцидента, связанного с облачным корпоративным хранилищем, контекст этой операции, свойственной для этого конкретного ресурса, будь это корпоративное облачное хранилище или вэб-сервис и т.п. В чем суть новой интеграционной возможности? Она позволяет события, которые поступают из внешней системы в Traffic Monitor, обогащать дополнительными атрибутами. Например, при интеграции с облаком, знать, где была позиция, какой тип устройства был использован, тип операций: скачивание или публикация и т.д. В результате по этим дополнительным подсказкам-атрибутам осуществлять поиск, назначать политики, просматривать в карточке события инцидента и т.д. Т.е. делать все те операции, как если бы вы делали для стандартных событий почты, мессенджеров и т.д.
