Как защитить информацию: пошаговая стратегия

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

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

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

Бизнес и безопасность обычно говорят на разных языках

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

Выявление рисков утечки

Первой задачей при оценке рисков утечки данных является количественный и качественный анализ существующей в организации конфиденциальной информации. Часто при общении с заказчиками встречается фраза: "да нам нечего защищать, мы открыты". Правда, почему-то пока еще никто из озвучивших её не согласился выслать данные CRM или платежные пароли. В любой, даже самой небольшой организации существуют данные, потеря или кража которых нанесет существенный ущерб, причем риск далеко не всегда связан с непосредственным участием сотрудников – данные могут быть потеряны или украдены в ходе транспортировки или хранения. На практике перечень и критичность данных очень сильно зависит от области деятельности организации и часто определяется соответствующими нормативно-правовыми актами и отраслевыми стандартами, например, законом 152-ФЗ "О персональных данных".

Базовый перечень категорий документов, утечка которых может привести к убыткам:

• Финансовая информация;
• Договоры с поставщиками, клиентами и партнерами;
• Данные CRM и условия различных соглашений;
• Отчет о реализованных и оцениваемых проектах и процессах;
• Штатное расписание, должностные инструкции, система грейдов;
• Внутренние протоколы, правила, распоряжения и приказы;
• Персональные данные сотрудников и контрагентов;
• Детальные схемы бизнес-процессов;
• Бизнес-планы, аналитика и прогнозы развития рынка;
• Чертежи, сметы, планы работ и другие проектные данные;
• Описания технологий, "ноу-хау", исходные коды ПО;
• Перечень и активационные коды используемого ПО;
• Архитектура сети и схема информационных потоков;
• Резервные и архивные копии данных.

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

После этого стоит перейти к составлению списка потенциальных каналов утечки. Обычно сюда относятся внешние устройства, принтеры, электронная почта, интернет-пейджеры, социальные сети и различные веб-сервисы. Не стоит забывать и о местах хранения данных — почтовых и файловых серверах, системах хранения, СУБД, CRM, резервных носителях информации, ПК, ноутбуках, арендуемых дата-центрах и т. д. В итоге получится довольно обширный список возможностей для утечек. Именно он в будущем поможет правильно подобрать DLP-решение, ведь далеко не все системы могут закрыть даже половину потенциально опасных каналов.

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

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

Обоснование. Внутренняя статистика

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

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

Обоснование. Внешняя статистика

Если затронули о внутренней статистике, то стоит сказать и о внешней — данных об утечках из других организаций. Согласно статистике Open Security Foundation, с начала 2008 года в мире была обнародована информация о более чем 1700 утечках. И это только обнародованные данные, реальных утечек больше в тысячи раз. С Россией и СНГ ситуация сложнее: если на Западе большинство коммерческих компаний и государственных организаций обязаны извещать об известном им факте утечки, то у нас такие сообщения появляются исключительно с подачи сотрудников или журналистов. Несмотря на то, что проблема безопасности конфиденциальной информации, особенно персональных данных, часто поднимается в ведущих СМИ, пока еще крайне мало организаций внедрили системы защиты от утечек.

Статистику Open Security Foundation и других подобных организаций, несомненно, можно использовать как часть обоснования. Ведь если даже в крупных западных компаниях, в числе которых AIG, Citigroup, Kia Motors, McAfee, Shell, T-Mobile, Vodafone, Zurich, иногда происходят утечки даже с учетом более развитой корпоративной культуры и лучших условий труда, что уж говорить о России, где краденые базы данных некоторых операторов связи обновляются с завидным постоянством. Конечно, с подсчетом вероятности утечки из конкретной организации такие данные вряд ли помогут, однако прикладывание внешней статистики к основному обоснованию является хорошей практикой.

Обоснование. Экспертная оценка

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

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

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

Прогнозирование последствий утечки

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

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

В итоге для каждой категории конфиденциальных данных, выявленной на этапе оценки рисков, прописываются негативные события, которые могут наступить в случае утечки информации. У каждого полученного соответствия (категории и последствий — прим. ред.) выставляется приоритет и, при необходимости, вероятный ущерб. Правильно расставленные приоритеты будут полезны и на этапе внедрения DLP, так как позволят планомерно подключать политики для каждой категории данных.

Дополнительные варианты обоснования

В большинстве организаций существуют требования к security baseline (базовому уровню безопасности), в том числе к антивирусной и сетевой защите. Затратам на соответствие security baseline почти всегда ставится высокий приоритет и выделяется больший бюджет, при этом DLP почти никогда не являются частью таких требований. Внесение в security baseline требований к защите от утечек является хорошей практикой, так как обычно переводит процесс обоснования в плоскость необходимости соответствовать собственным же стандартам безопасности, которые утверждались топ-менеджментом.

Во многих развитых странах уже довольно давно существуют законодательно закрепленные требования к защите от утечек информации. В России в свою очередь существует закон 152-ФЗ "О персональных данных", который при желании можно использовать для обоснования издержек на DLP. Если не углубляться в тонкости, то на этапе построения моделей угроз можно довольно легко включить туда требования к защите от утечек данных, а в рекомендованные решения – предварительно выбранную DLP. Единственный момент — систему, скорее всего, необходимо будет специально сертифицировать, хотя в разрезе всего проекта этот процесс займёт не так много времени — около двух месяцев.

Сегодня также существует множество отраслевых стандартов, из которых стоит в первую очередь отметить PCI DSS (стандарт защиты информации в индустрии платежных карт), Кодекс корпоративного поведения ФСФР и Стандарт Банка России. В каждом из них есть требования, соответствие которым можно функционально возложить на DLP. Для организаций, работающих на зарубежных рынках, необходимо обратить пристальное внимание на Basel II, FACTA, GBLA, HIPAA, NASD 3010/3110, SEC Rule 17a-4, SOX и локальные кодексы корпоративного управления. Часто в них фигурирует формулировка "необходимо обеспечить достаточный уровень защиты", которая на практике серьезно развязывает руки в процессе обоснования.

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

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

Александр Ковалев

cnews

Опубліковано на сайті: 2010-11-20