DLP-системы используются для защиты конфиденциальных данных компании и выявления сотрудников, сливающих эти данные. В большинстве случаев инженеры внедрения сталкиваются на проектах с типовыми инцидентами наподобие этих. Но иногда DLP-система неожиданно выявляет нарушения, на обнаружение которых даже не заточена.
Под катом – подборка самых необычных расследований, проводимых с помощью DLP.
Исследования — это неотъемлемая часть моего рабочего процесса. Я исследую ПО, исходные коды, ОС, железки — все, до чего дотянутся руки (ну или руки начальства, тут как повезет). Но не все исследования проводятся по заказу, иногда что-то просто делаешь для души (что, наша компания в общем-то поощряет). Это исследование началось с разговора о шифровании, а закончилось обходом DLP и выносом данных за контролируемый периметр.
Я очень не люблю DLP-системы. Моя неприязнь основана на маркетинговой стратегии продуктов, представляющих свои решения в виде этакой «серебряной пули», которая может предотвратить все утечки данных в любой компании. Не может. По моему мнению, реально DLP помогает в 2 случаях — предотвратить утечку данных из-за кривых рук (типа отправки платежных данных вместо ali@domain.mail на all@domain.mail) и помочь провести расследование, кто же унес данные (постфактум, естественно). Я изначально был уверен, что специалист, владеющий достаточными знаниями о Windows, например, сможет преодолеть почти любые фильтры. А мотивированный инсайдер сможет найти такого специалиста и обучиться нескольким трюкам. Но проверять разные трюки на конкретных комплексах довольно скучно, поэтому надо было придумать, как разом обойти их все.
Мы уже рассказывали о том, почему секционирование баз данных очень важно для производительности DLP-системы и как мы реализовывали его в PostgreSQL. В этой статье речь пойдет об Oracle.
Специфика использования СУБД в DLP-решениях состоит в том, что объем данных прирастает очень быстро. Их невозможно держать в оперативном архиве, и долговременное хранение – это необходимость в компании численностью свыше хотя бы 50 человек. При этом оперативный архив наполняется так быстро, что отдавать информацию в долгосрочный архив приходится раз в 2 недели или чаще. Использование только встроенных средств СУБД требует знаний и опыта. Это главная сложность, и она, в общем-то, очевидна «на берегу».
Кроме того, возникают проблемы, не очевидные сразу. Как вернуть из долгосрочного архива партицию с данными более старой версии приложения и прицепить к более свежей? Что делать, если у них разных формат хранения данных? Что делать, если подключение секции было прервано, и она «зависла» между долговременным и оперативным архивом?
Сегодня невозможно представить большой город без метрополитена с его линиями, правилами и станциями, достопримечательностями и своей историей, иногда даже известными во всем мире и привлекающими к себе особое внимание. Метро функционирует как отдельный организм, но вместе с тем является неотъемлемой частью города. Так и средства информационной безопасности в нашей стране уже невозможно представить без решений отечественных производителей (станции метро) различных классов систем (линии метро).
Предлагаем прокатиться вместе с нами по нашему метро под названием «Информационная безопасность» и подробно, при желании, остановится на известных или не очень, а, может, просто любимых станциях….
P.S. Карта метро ИБ является лишь информативным инструментом, не несет ответственности за работоспособность станций метро и является актуальной на конец 2017 года. Функциональность и качество работоспособности станций не зависит от их месторасположения на карте, внутри кольца или за пределами, аналогии с отчетами мировых аналитических агентств нет, мы же в столице России! График работы и иные детали функционирования уточняйте в самостоятельном порядке.
Любые предложения по реставрации станций, их закрытию или пожелания по внесению неучтенных станций приветствуются! Ведь линии метро продлеваются, а МЦК строится быстрыми темпами…
До встречи в 2018 году!
Читать полностью »
В октябре 2017 года довелось побывать на рекламном семинаре DLP-системы DeviceLiock, где помимо основного функционала защиты от утечек типа закрытия USB-портов, контекстного анализа почты и буфера обмена рекламировалась защита от администратора. Модель простая и красивая — в маленькую фирму приходит установщик, ставит комплекс программ, паролит БИОС, создает администраторскую учетку DeviceLock, а местному админу оставляет только права на управление собственно Виндой и остальным софтом. Даже в случае умысла этот админ ничего украсть не сможет. Но это все теория…
Читать полностью »
В ходе работы DLP-система ежедневно перехватывает огромные массивы информации – это и письма сотрудников, и информация о действиях пользователей на рабочих станциях, и сведения о хранящихся в сети организации файловых ресурсах, и оповещения о несанкционированном выводе данных за пределы организации. Но полезной эта информация будет только в случае, если в DLP реализован качественный механизм поиска по всему массиву перехваченных коммуникаций. С тех пор, как в 2000 году увидела свет первая версия нашего DLP-решения, мы несколько раз меняли механизм поиска по архиву. Сегодня мы хотим рассказать о том, какие технологии мы использовали, какие видели в них преимущества и недостатки, и почему мы от них в итоге отказывались. Возможно, кому-то наш опыт окажется полезен.
Читать полностью »
Сегодня хотелось бы еще раз поднять такую важную тему, как легитимность внедрения систем для защиты от утечек информации. Прекрасно, когда компания задумывается о сохранности своих информационных активов и внедряет DLP-решение. Но если этому внедрению не сопутствует юридическое оформление, часть функций DLP просто «отваливается». Компания не сможет использовать данные DLP в суде против сотрудника, виновного в разглашении конфиденциальной информации (а может и пострадать от иска самого сотрудника, например). Сегодняшний небольшой материал рассказывает, как этого избежать и где «подстелить солому».
Читать полностью »
В начале июня мы с моим другом и коллегой Андреем Данкевичем съездили на несколько дней в Лондон на Information Security Europe. Это крупнейшая выставка в Европе и «одна из» в мире. В этом году ее посетило более 15 000 человек, и проходила она уже в 22 раз.
Хотя на Information Security Europe и представлена довольно обширная программа докладов, но ехать стоит не за ними, а для того, чтобы набрать классной сувенирки пообщаться с производителями СЗИ, посмотреть их решения на стендах и самостоятельно (а не просто доверившись Gartner) сделать выводы о том, какие тренды сейчас на пике. Под катом — рассказ о том, какие технологии внедряют вендоры DLP, UEBA, GRC, IGA и MDR.
Читать полностью »
Аналитики Solar JSOC и Solar Dozor в своих статьях часто говорят о том, что даже все многообразие средств защиты, существующих на рынке, не защитит компанию от атаки, если она рассматривает данные каждой системы в отдельности. Чаще всего атаку, если она не совсем примитивная, можно выявить, только сведя воедино данные с различных источников.
Сегодня мы хотим рассказать об очередном примере, подтверждающем эту истину. Под катом – история одной атаки, которая едва не прошла незамеченной.
Сегодня мы хотели бы затронуть очень важную для DLP-решений тему – выбор СУБД для хранения данных. Так исторически сложилось, что большинство российских DLP используют для этих целей Oracle Database. На заказчиков это накладывает определенные финансовые ограничения: стоимость лицензий Oracle закладывается в стоимость DLP-системы. Это создает определенный фильтр, сокращающий аудиторию пользователей продукта: СУБД Oracle могут позволить себе не все – как в техническом, так и в финансовом плане.
Теперь, когда импортозамещение шагает по стране, госсектор (и не только) формирует спрос на DLP, поддерживающие свободные СУБД. Это очень ощутимый импульс, но, метнувшись в сторону свободных СУБД, важно сохранить удобство, производительность и функциональные возможности продукта. В этой статье речь пойдет о том, как мы решали эту задачу, реализуя поддержку PostgreSQL и разрабатывая схему секционирования в Solar Dozor.
