Поделиться
Как защитить информацию: пошаговая стратегия
Любая современная компания подвержена рискам утечки конфиденциальной информации. Однако при этом далеко не каждый топ-менеджер уверен в том, что ее необходимо защищать. Люди убеждены, что уж с ними-то точно никаких неприятностей не случится и что традиционный фаервол вполне может справиться с обеспечением ИБ. Как же доказать, что внедрение DLP необходимо, и оценить реальные риски?Для большинства специалистов по информационной безопасности необходимость защиты от утечек конфиденциальной информации уже давно является очевидной. При этом полноценные DLP-решения установлены лишь в немногих организациях: где-то с помощью узкоспециализированных продуктов контролируется только часть каналов утечки, где-то проблему решают исключительно своими силами, а где-то вообще не предпринимается никаких действий. Такая ситуация объясняется тем, что бизнес и безопасность обычно говорят на разных языках: первым необходимо экономическое обоснование внедрения DLP, тогда как вторым очевиден риск убытков даже от незначительной утечки.
Как и любые ИТ-проекты, внедрение DLP-решений необходимо обосновывать с точки зрения полезности для бизнеса. Она может выражаться как в возврате инвестиций, так и в снижении рисков, так как утечка даже самой незначительной информации может породить множество проблем и убытков.
Бизнес и безопасность обычно говорят на разных языках
У большинства разработчиков и интеграторов существуют красивые описания осуществленных проектов в области DLP, хотя некоторые и высылают их только по запросу. Часто в этих описаниях можно найти подсказки, как в той или иной организации обосновали затраты и почему выбрали конкретный продукт. Кроме того, сведения о внедрении DLP в компании-конкуренте обычно серьезно повышает интерес к проекту со стороны топ-менеджмента.
Выявление рисков утечки
Первой задачей при оценке рисков утечки данных является количественный и качественный анализ существующей в организации конфиденциальной информации. Часто при общении с заказчиками встречается фраза: "да нам нечего защищать, мы открыты". Правда, почему-то пока еще никто из озвучивших её не согласился выслать данные CRM или платежные пароли. В любой, даже самой небольшой организации существуют данные, потеря или кража которых нанесет существенный ущерб, причем риск далеко не всегда связан с непосредственным участием сотрудников – данные могут быть потеряны или украдены в ходе транспортировки или хранения. На практике перечень и критичность данных очень сильно зависит от области деятельности организации и часто определяется соответствующими нормативно-правовыми актами и отраслевыми стандартами, например, законом 152-ФЗ "О персональных данных".
Базовый перечень категорий документов, утечка которых может привести к убыткам:
- Финансовая информация;
- Договоры с поставщиками, клиентами и партнерами;
- Данные CRM и условия различных соглашений;
- Отчет о реализованных и оцениваемых проектах и процессах;
- Штатное расписание, должностные инструкции, система грейдов;
- Внутренние протоколы, правила, распоряжения и приказы;
- Персональные данные сотрудников и контрагентов;
- Детальные схемы бизнес-процессов;
- Бизнес-планы, аналитика и прогнозы развития рынка;
- Чертежи, сметы, планы работ и другие проектные данные;
- Описания технологий, "ноу-хау", исходные коды ПО;
- Перечень и активационные коды используемого ПО;
- Архитектура сети и схема информационных потоков;
- Резервные и архивные копии данных.
Для составления полного списка всех конфиденциальных данных часто привлекают внешние аудиторские компании, однако на этапе первичной оценки вполне хватит экспертизы специалистов служб безопасности и специального ПО. Кроме того, не стоит забывать и о сотрудниках, которые обычно отлично знают перечень применяемых в своей работе конфиденциальных документов, их критичность для компании и сценарии использования. Критичность подразумевает ущерб, который может понести организация в случае попадания данных в руки конкурентов, клиентов, партнеров и СМИ. В идеале результатом исследования должен стать список всей конфиденциальной информации с описанием критичности, сценариев использования и перечня лиц, имеющих к ней доступ.
После этого стоит перейти к составлению списка потенциальных каналов утечки. Обычно сюда относятся внешние устройства, принтеры, электронная почта, интернет-пейджеры, социальные сети и различные веб-сервисы. Не стоит забывать и о местах хранения данных — почтовых и файловых серверах, системах хранения, СУБД, CRM, резервных носителях информации, ПК, ноутбуках, арендуемых дата-центрах и т. д. В итоге получится довольно обширный список возможностей для утечек. Именно он в будущем поможет правильно подобрать DLP-решение, ведь далеко не все системы могут закрыть даже половину потенциально опасных каналов.
В результате хорошо проделанной работы появится не просто несколько списков, появится базис для оценки объемов, вероятности и последствий рисков. У каждого типа данных и канала утечки будут своя критичность и связанные с ним сотрудники. Такая информация даст возможность подойти к процессу обоснования гибко и с несколькими вариантами — от предложения выборочного контроля лишь части документов и каналов до тотальной защиты даже некритичных данных. Например, использование пиринговых сетей на рабочих местах почти всегда можно безболезненно для бизнес-процессов запретить с помощью уже имеющегося фаервола.
Часто под определением вероятности подразумевается точное число, которое будет получено в результате измерений, однако точно измерить вероятность утечки, как и многих других бизнес-рисков, практически невозможно. К сожалению, точную вероятность того, что конкретный сотрудник допустит случайную или умышленную утечку данных за определенный период, нельзя, однако можно существенно снизить неопределенность. Для каждой категории конфиденциальной информации должен соответствовать максимально узкий диапазон вероятности утечки.
Обоснование. Внутренняя статистика
Пожалуй, самый действенный способ снижения неопределенности — это использование внутренней статистики. Часто только на основе данных о произошедших в организации утечках можно обосновать внедрение DLP, однако на практике подобная статистика ведется лишь в единицах организаций, да и её погрешность остаётся высокой — неизвестно число инцидентов, которые остались без внимания. Кроме того, далеко не всегда даже общеизвестные случаи утечки, например, баз данных федеральных операторов связи, могут сдвинуть дело с мёртвой точки и мотивировать менеджмент задуматься о внедрении DLP. Однако, несмотря на сложности, всё же стоит при оценке вероятности события попробовать собрать статистику утечек и данные об активности пользователей с последующим выявлением подозрительных сценариев.
Если внутренняя статистика раньше не собиралась, ее можно получить как собственными силами, например, опросив старожилов компании и менеджмент, так и с помощью пилотного внедрения DLP. Почти любой разработчик DLP предоставляет возможность проверить систему в боевых условиях и собрать информацию о текущих нарушениях политик безопасности и злонамеренном использовании конфиденциальных данных. При пилоте DLP-система устанавливается в пассивном режиме, т. е. ничего не блокирует, и собирает всю возможную статистику по текущему перемещению данных: какую информацию, куда и по каким каналам отправляют сотрудники. Не раз были случаи, когда уже на этапе пилотного проекта служба безопасности обнаруживала злонамеренных инсайдеров, и компания еще до завершения тестирования приобретала DLP-систему. Пилотный проект будет крайне полезен и для получения реальных сценариев перемещения конфиденциальных данных.
Поделиться
Короткая ссылка
