среда, 31 августа 2011 г.

Штраф Мегафону и 152-ФЗ

Как известно вчера суд обязал компанию Мегафон выплатить сумасшедший штраф в аж целых 30 тысяч рублей. Вот собственно чем закончился тот скандал с утечкой SMS-сообщений, произошедшей в момент подписания поправок в Федеральный закон № 152-ФЗ.

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

Собственно это и не удивительно, потому как в данном случае в интернет попали тексты сообщений и номера телефонов. Конечно эту информацию можно отнести к персональным данным, но есть одно важное НО. В текстовке закона есть такой термин:

"обезличивание персональных данных - действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность персональных данных конкретному субъекту персональных данных;"

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

"обезличенные персональные данные - персональные данные, принадлежность которых конкретному субъекту невозможно определить без использования дополнительной информации;"

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

вторник, 30 августа 2011 г.

Автоматизация управления ИБ в Банках

Разбираясь с результатами опроса по оценке рисков ИБ, заинтересовался тем, что же есть сейчас в плане программного обеспечения, которое можно использовать для проведения оценки рисков. Западных программ полно, а вот наших кроме древнего и по моему мнению очень неудобного ГРИФа от Digital Security больше ничего нет. И он, понятно дело, для банков не годится.

Коллеги скинули ссылку на сайт компании ISM SYSTEMS. Судя по описанию, компания занимается разработкой специализированного софта ISM Revision, который предназначен для автоматизации процессов управления ИБ (в том числе и управления рисками). Вот что они пишут о продукте:

«ISM Revision – комплексный программный продукт, предназначенный для автоматизации процессов управления информационной безопасностью. Каждый из модулей нашего решения обеспечивает автоматизацию управления определенным процессом: аудит информационной безопасности, риск-менеджмент, инцидент-менеджмент и другие.
Наш продукт разработан на базе веб-технологий, поэтому для его использования достаточно наличия на компьютере веб-браузера. Стоимость ISM Revision фиксирована для любой организации и не зависит от количества пользователей.
Еще одним преимуществом нашего программного продукта является возможность создавать документы, содержащие результаты деятельности по управлению информационной безопасностью. Эти документы могут быть использованы как для отчетности перед руководством, так и при проведении проверок со стороны Банка России.»

Пока для ознакомления доступен только модуль для проведения самооценки на соответствие СТО БР ИББС, модуль по рискам в разработке и в ближайшее время обещан его релиз. Посмотрим, что у них получится.

воскресенье, 28 августа 2011 г.

Ситуация с оценкой рисков ИБ в банках

Как и обещал выкладываю результаты проведенного опроса по оценке рисков ИБ в банках. Всего в опросе приняло участие 67 банков, что составляет примерно 7-8% от общего числа.

Первый вопрос касался того, проведена ли в банке оценка рисков, и вот его результаты:

Я честно говоря ожидал худшего, но судя по ответам в 43% банков оценка рисков ИБ уже проведена и почти 15% проводят ее сейчас.

Следующий вопрос касался того, кому в банке поручен процесс оценки рисков

В подавляющем большинстве это служба информационной безопасности. Реже всего - служба ИТ.

Следующий вопрос касался того, какая методика применяется при оценке рисков. И тут снова в общем ожидаемая ситуация - большинство выбирает методику Банка России. (в описании методики у меня вкралась ошибка, конечно же это РС БР ИББС-2.2-2009, а не тот документ, который указан в опросе, но видимо все поняли правильно :) )

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

Все спасибо за участие в опросе. Для начала получилось совсем неплохо. Есть над чем поразмыслить.

пятница, 26 августа 2011 г.

Переезд с точки зрения информационной безопасности


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


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

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

А как было у вас ? Поделитесь своими историями переезда.

четверг, 25 августа 2011 г.

Риски в банковской отрасли

Продолжая тематику рисков в банковской отрасли (кстати, опрос по ИБ-рискам пока еще продолжается) хотелось бы рассказать об исследовании, которое ежегодно проводит Pricewatehousecoopers - Banking banana skins. Текущая версия отчета относится к 2010 г. и в том числе отдельно описывает ситуацию в России. Что же мы видим:

Я обвел красным цветом то, что косвенно имеет отношение к вопросам информационной безопасности. Напрямую риски информационной безопасности в списке не представлены, что видимо свидетельствует о том, что они не способны привести к критическим последствиям для банков (точнее так это видится банкам).

Можно также отметить интересные тенденции. По сравнению с 2008 г. выросли риски непрерывности работы организаций, но снизились риски высокой зависимости от технологий.

пятница, 19 августа 2011 г.

Лицензирование отменяется !? Новый проект постановления правительства о лицензировании деятельности по ТЗКИ

Свершилось, на сайте ФСТЭК опубликован проект Постановления правительства о лицензировании деятельности по технической защите конфиденциальной информации.

Скачать можно здесь. (за ссылку спасибо Алексею Краснову)

Самое интересное в этом документе в начале, а именно то, что же ФСТЭК (хотя нет, конечно же Правительство) считает деятельностью по технической защите конфиденциальной информации.

Сразу оговорюсь, что мой беглый анализ возможно будет содержать неточности, т.к. читать и правильно понимать наши нормативные документы - это особый талант :) . Итак....

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

Ну ничего нового, комплекс работ или услуг... как же быть с использованием СЗИ для собственных нужд ?

"3. Лицензирование деятельности по технической защите конфиденциальной информации осуществляет Федеральная служба по техническому и экспортному контролю (далее - лицензирующий орган)."

Тут вроде тоже без неожиданностей.

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

Оо, а вот это уже интересный финт ушами. Деятельность то получается лицензируется не вся.

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

Это я понимаю как работы по проведению Э/М и акустических замеров с помощью специальной аппаратуры

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

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

в) сертификационные испытания на соответствие требованиям по безопасности информации продукции, используемой в целях защиты конфиденциальной информации (технических средств защиты информации, защищенных технических средств обработки информации, технических средств контроля эффективности мер защиты информации, программных (программно-технических) средств защиты информации, защищенных программных (программно-технических) средств обработки информации, программных (программно-технических) средств контроля защищенности информации);

Тут думаю понятно о чем идет речь...

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

Тут тоже из текста ясно о чем речь...

д) проектирование объектов в защищенном исполнении: средств и систем информатизации; помещений со средствами (системами), подлежащими защите; помещений, предназначенных для ведения конфиденциальных переговоров;

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

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

Воотт.. самый непростой пункт. Вот тут, коллеги, интересно будет услышать и ваше мнение. Установка, монтаж.... и ремонт... этими вещами все же занимаются рядовые администраторы. Но с другой стороны здесь нет слова "эксплуатация", а значит если вы просто используете средства защиты, то под этот пункт не подпадаете, а уж вопрос с установкой, монтажом и ремонтом уверен, что можно будет как-нибудь хитро обойти (либо просто ФСТЭК не будет подходить к этим терминам "в лоб").

Каков же итог ? Если я все правильно понял, то получается, что большинство организаций (за исключением интеграторов, сертификаторов, аттестаторов и еще ряда других) выпадают из обязательного лицензирования по ТЗКИ в том числе в свете пресловутого 152-ФЗ. Ура, коллеги, прям не верится, что здравый смысл все же может восторжествовать.... (стучу по дереву).

P.S. Так как это пока только проект радоваться рекомендуется очень осторожно :)

четверг, 18 августа 2011 г.

Украденный ноутбук можно попытаться вернуть

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

Случай кстати это далеко не единичный и специальные сервисы по отслеживанию мобильного оборудования существуют уже не первый год. Есть даже такие, которые рассчитаны на корпоративный сектор. Есть и open source решения вроде вот этого.

P.S. Кстати по статистике ФБР в Америке в среднем каждые 43 секунды обращаются в полицию по поводу кражи ноутбука.

среда, 17 августа 2011 г.

В библиотеку пентестеру

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

1) Penetration Tester's Open Source Toolkit, Third Edition

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






2) Metasploit: The Penetration Tester's Guide

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







Так как я сам с этими книгами пока ознакомиться не успел, то никакой рецензии от себя дать не могу.

понедельник, 15 августа 2011 г.

А как у Вас обстоят дела с оценкой ИБ-рисков ?

Вопросами оценки рисков я занимаюсь уже много лет. Изучил массу методологий, инструментов, реализовывал проекты у Заказчиков. И тем интереснее было в свое время читать методику, которую предложил в одном из своих документов Банк России. Мне как поклоннику методики OCTAVE было интересно находить в этом документе параллели с этой методикой (думаю они не случайны). Не буду сейчас останавливаться подробно на том, что я считаю удачным в методике Банка России, а что не очень. Суть этого поста в другом.

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

Сам опрос расположен здесь.

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

PCI SSC выпустил руководство по "токенизации"

"Токенизация" - это прием, при котором номер кредитной карты заменяется на "токен", т.е схожий по характеристикам номер, получаемый путем математического преобразования. Получить номер карты имея только токен невозможно, но эта технология подразумевает наличие центральной базы данных, в которой хранятся сведения о соответствии токена номеру карты. Для чего это нужно ? В контексте PCI DSS это позволяет уменьшить область действия требований стандарта, в которую включаются все системы, обрабатывающие номера кредитных карт. Если вместо номера токен, то такая система может не рассматриваться как подпадающая под требования PCI DSS.

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

И вот на днях PCI Council выпустил документ PCI DSS Tokenization Guide. Документ описывает общую концепцию, но тем не менее стоит того, чтобы его прочитать.

пятница, 12 августа 2011 г.

Замкнутый круг (не)безопасности

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

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

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

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

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

Вот как это выглядит:
  • руководство организаций не видит безопасность как функцию, дающую бизнес-ценность
  • в связи не делаются усилия для поиска и наем нужных специалистов на критические роли
  • это приводит к тому, что практически ничего не делается для того, чтобы улучшить информационную безопасность как функцию от риск-менеджмента
  • происходит серьезный инцидент информационной безопасности
  • на разбор и устранение последствий инцидента уходит огромное количество времени, денег и человеческих ресурсов
  • руководство задает вопрос "Почему наша служба информационной безопасности не смогла это предотвратить?"
  • ценность безопасности для бизнеса становится еще меньше
  • ... теперь возвращаемся в начало списка (круг замкнулся)...
Этот депрессивный взгляд на проблему может вызвать вполне резонный вопрос - "И как же выйти из этого замкнутого круга ? По моему мнению выход есть и он не потребует десятикратного увеличения бюджета на информационную безопасность. Он потребует только объединения усилий ваших поставщиков средств и сервисов по информационной безопасности, вашего руководства и вас как менеджеров по информационной безопасности. Давайте я поясню, что я имею ввиду.

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

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

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

Нужно начать думать не над тем, какую еще "передовую" технологию закупить, а над тем, что нужно сделать для решения проблем безопасности в контексте имеющихся бизнес-задач.

Данный материал является моим вольным переводом статьи Rafal Los, опубликованной в журнале CIO.

суббота, 6 августа 2011 г.

Как проверить не "сливает" ли Ваш сайт информацию в поисковик

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

Не знаю началось ли это с него, но человеком прославившимся на гугло-хакинге (Google Hacking) был хакер по имени Johny Long, известный под ником j0hnny (вот тут краткая статья о нем из wikipedia). Он в свое время активно развивал эту тему и даже создал базу данных различных запросов, позволяющих добывать интересную информацию из поисковика. База жива до сих пор, хотя Джонни отошел от дел и сейчас занимается благотворительностью в рамках организации Hackers for Charity.

Очень хорошая книжка есть о гугло-хакинге, которая так и называется Google Hacking for Penetration Testers (посмотреть можно тут). К этой книге также приложил руку Джонни.

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

Последним на моей памяти работающим инструментом был Goolag, разработанный хакерской группой Cult of the Dead Cow. Но он похоже уже тоже приказал долго жить.

И вот буквально на днях на хакерской конференции BlackHat 2011 были представлены новые инструменты для поиска информации через запросы к поисковикам Bing и Google - Google Hacking Diggity Project.

Используя эти инструменты у вас есть реальная возможность посмотреть что же интересного утекло/утекает с Вашего сайта в публичный доступ (поисковик).

Интерфейс программы выглядит следующим образом:




P.S. Аналогичных инструментов для отправки запросов в Яндекс я не встречал, если кто-то знает, напишите, очень интересно.

P.P.S Да и еще, очень много пишется что нужно прописать запрет на индексацию в robots.txt и будет все отлично. Господа, конечно от поискового бота это спасет, но реальный злоумышленник заглянув в этот файл сразу поймет где вы от него что прячете. Поэтому правьте сайт, а не файл robots.txt !!!


вторник, 2 августа 2011 г.

Новый стандарт по управлению рисками ИБ

Несколько незаметно для многих (по понятным для России причинам :) ) примерно месяц назад свет увидела новая редакция стандарта ISO 27005, посвященная риск-менеджменту (официальная страница на сайте ISO).
Вот как о ней отзывается CEO довольно известной британской компании IT Governance:

“The new ISO/IEC 27005:2011 is a much better standard than was the 2008 version. First, it is a better written, more coherent standard. Second, it is aligned with the risk management standard ISO 31000, which makes it easier to integrate Enterprise Risk Management approaches with information security risk management. Third, it provides good, practical guidance on carrying out the risk assessment required by ISO 27001, together with clear guidance on risk scales. Fourth, it has good guidance on threats, vulnerabilities, likelihoods and impacts. ISO 27005 should become standard additional guidance on risk assessment – the ISMS core competence – for all organisations tackling ISO 27001.”

Честно говоря сам я пока еще не успел ознакомиться с текстом этого документа, но планирую сделать в ближайшее время. В интернете удалось найти небольшой фрагмент, содержащий структуру стандарта.

Действительно, исходя из названий разделов документа видно, что стандарт изменился. Так, например, можно увидеть как изменилась терминология в части методов обработки рисков.

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

Купить стандарт (английскую версию) можно, например, здесь. Когда появится русскоязычный перевод мне не известно.

понедельник, 1 августа 2011 г.

DLP BEST PRACTICE от LETA

На днях вышел в свет новый буклет LETA, посвященный одной из основных тем с которой работает наша компания – DLP.
"Построение комплексной системы защиты от утечек конфиденциальной информации. DLP BEST PRACTICE"

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

В брошюре представлена следующая информация:

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

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

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

Материал доступен для скачивая в формате PDF на сайте LETA.