Falcongaze назвала популярные мифы, связанные с защитой информации

Falcongaze назвала популярные мифы, связанные с защитой информации

Сотрудники аналитического центра Falcongaze решили собрать самые популярные мифы из области DLP, с которыми сталкивались специалисты компании на своей практике при общении с потенциальными заказчиками системы для защиты информации SecureTower. Кроме сбора DLP-фольклора, аналитики компании решили взять на себя роль разрушителей легенд, развенчав тем самым многую напраслину, которую порой возводят на системы DLP.

DLP-системы дорого стоят и себя не окупают

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

Также, часто от покупателей приходится слышать, что никакая утечка не может сравниться по цене с DLP-решением. И хотя подсчитать стоимость утечек непросто, тем не менее, согласно статистике, утерянный, или украденный у топ-менеджера ноутбук (на котором могут храниться данные о ключевых клиентах, данные о сделках или же финансовая информация) в среднем стоит $46 000. Однако сейчас решениям для защиты информации уже недостаточно ограничиваться только лишь защитой от утечек: современные DLP-системы должны содержать инструменты, способные решать целый комплекс задач в сфере как информационной, так и экономической безопасности компании. К тому же, как показывает практика, правильно настроенная DLP-система, окупается еще за первые два-три месяца использования, а то и вовсе на стадии тестирования.

DLP-системы нужны только большим организациям

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

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

Для внедрения, обслуживания DLP необходимо много людей и времени

Многие заказчики даже и не задумываются об установке DLP-системы, поскольку считают, что обслуживание такого продукта отнимает слишком много времени и требует большого штата специалистов. Также большинство уверено, что установка DLP-решения автоматически повлечет за собой большие затраты на приобретение дорогостоящего оборудования, и внедрение системы для защиты информации будет очень продолжительным и неминуемо приведет к остановке бизнес-процессов в организации.

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

Все DLP сложны в освоении и использовании

Множество заказчиков уверено, что настраивать и использовать DLP-систему слишком сложно и неудобно из-за большого количества компонентов и сложных параметров.

Однако далеко не все системы для обеспечения информационной безопасности подразумевают под собой неудобный и громоздкий интерфейс, в котором даже искушенному специалисту с многолетним опытом работы не всегда возможно разобраться. Разработчики DLP, по-настоящему заботящиеся о своих заказчиках, всегда задумываются не только об эффективности предоставляемого продукта, но также и о том, чтобы их детище обладало настолько простым интерфейсом, чтобы его использование не вызывало затруднений даже у малоопытных сотрудников. Качественные продукты обязаны обладать единой консолью, из которой осуществляется управление всей системой. Для того чтобы сделать работу с DLP-продуктами еще более простой, в самых эффективных решениях уже содержатся предустановленные правила безопасности и их редактируемые шаблоны, которые позволяют использовать систему с момента ее запуска.

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

К сожалению, порой случается так, что, не разобравшись, основываясь на одних советах, заказчик выбирает DLP-систему, которая его полностью разочаровывает. После одного негативного опыта многие готовы «поставить крест» на всех остальных DLP-системах и именно это способствует появлению и укоренению мифов. Увы, такая ситуация – не редкость. Тем не менее, прежде чем говорить окончательное «не надо», стоит попробовать что-то другое, и уже потом решать, что в сфере DLP является мифом, а что – нет.

Баги в ядре Linux скрываются в среднем 2 года, а иногда и 20 лет

История с первой CVE для Rust-кода в ядре Linux, которая недавно привела к падениям системы, выглядела почти как повод для оптимизма. В тот же день для кода на C зарегистрировали ещё 159 CVE — контраст показательный. Но новое исследование напоминает: проблема не только в языках программирования.

Гораздо тревожнее первой Linux-дыры в коде на Rust тот факт, что многие ошибки в ядре Linux могут годами, а иногда и десятилетиями оставаться незамеченными.

Исследовательница Дженни Гуанни Ку из компании Pebblebed проанализировала 125 183 бага за почти 20 лет развития ядра Linux — и результаты оказались, мягко говоря, неожиданными.

 

По данным исследования, средний баг в ядре Linux обнаруживают через 2,1 года после его появления. Но это ещё не предел. Самый «долгоиграющий» дефект — переполнение буфера в сетевом коде — прожил в ядре 20,7 года, прежде чем на него обратили внимание.

Важно уточнить: речь идёт о багах в целом, а не только об уязвимостях. Лишь 158 ошибок из всей выборки получили CVE, остальные могли приводить к сбоям, нестабильности или неопределённому поведению, но не обязательно к эксплуатации.

Исследование опирается на тег Fixes:, который используется в разработке ядра Linux. Когда разработчик исправляет ошибку, он указывает коммит, в котором баг был добавлен. Дженни написала инструмент, который прошёлся по git-истории ядра с 2005 года, сопоставил такие пары коммитов и вычислил, сколько времени баг оставался незамеченным.

В датасет вошли данные до версии Linux 6.19-rc3, охватывающие период с апреля 2005 по январь 2026 года. Всего — почти 120 тысяч уникальных исправлений от более чем 9 тысяч разработчиков.

Оказалось, что скорость обнаружения ошибок сильно зависит от подсистемы ядра:

  • CAN-драйверы — в среднем 4,2 года до обнаружения бага;
  • SCTP-стек — около 4 лет;
  • GPU-код — 1,4 года;
  • BPF — всего 1,1 года.

Проще говоря, чем активнее подсистема используется и исследуется, тем быстрее там находят ошибки.

Отдельная проблема — неполные фиксы. Исследование показывает, что нередко разработчики закрывают проблему лишь частично. Например, в 2024 году был выпущен патч для проверки полей в netfilter, но уже через год исследователь нашёл способ его обойти.

Такие ситуации особенно опасны: создаётся ощущение, что проблема решена, хотя на самом деле она просто сменила форму.

RSS: Новости на портале Anti-Malware.ru