28.06.2008

Сертификация продукта по требованиям PCI DSS. Бред или очередной маркетинговый ход?!

Начну с предистории: Когда-то лаборатория NSS блистала на рынке сетевой безопасности, предложив независимую оценку и сертификацию средств предотвращения атак. Однако рынок этот достаточно узкий, да и интерес к сетевой безопасности постепенно угасает, сдавая позиции прикладной безопасности, теме compliance, стандартой и т.д. Но зарабатывать как-то надо и поэтому NSS стала расширять спектр своей деятельности - она ввела сертификацию Web Application Firewall, UTM, средств защиты контента.

И вот недавно NSS объявила о том, что она будет проверять соответствие (сертифицировать) различных технологических продуктов требованиям стандарта PCI DSS. Учитывая интерес к данному стандарту и его обязательность для многих, ход правильный, но... Если посмотреть на текущую версию PCI DSS 1.1, то мы увидим, что несмотря на его технологичность, он не является продуктовым. Мы не можем сказать, что один продукт соответствует требованиям стандарта PCI DSS. С точки зрения безопасности и здравого смысла это нонсенс. Максимум на что мы можем рассчитывать, это "наш продукт помогает выполнить требования x стандарта PCI DSS".

Однако маркетинг, есть маркетинг... Поэтому к тесту Антона Чувакина "Вы идиот безопасности, если..." можно добавить 9-ый вопрос: "вы считаете, что продукт может выполнить требования PCI DSS".

Fortinet покупает активы IPLocks

Китайская компания Fortinet покупает американские и английские активы частной компании IPLocks, которая работает в области оценки, мониторинга и аудита баз данных с точки зрения безопасности. Финансовые детали сделки не разглашаются.

По оценке Canalys 99% всех продаж Fortinet. Поэтому выход на рынок прикладной безопасности, сделанный вслед за Cisco и другими компаниями является вполне логичным и закономерным. Сложно сказать, насколько данный шаг позволит компании занять свое место под солнцем, но китайские методы ведения бизнеса говорят о том, что они могут потеснить небольшие компании в этом сегменте.

Вы идиот безопасности...

У Антона Чувакина в блоге появился классный мини-тест на тему "Идиот ли вы в области безопасности". Если хотя бы на один вопрос вы отвечаете положительно, то увы...

Читать здесь...

ЗЫ. А тут очередной укол в сторону CISSP ;-)

22.06.2008

Стандартизация в ИБ - лед сдвинулся

Не раз я писал про то, что уровень стандартизации в области ИБ не так высок, как в других отраслях. В частности у нас отсутствуют стандарты на обмен сигналами тревоги между решениями разных фирм. Когда-то был стандарт RDEP, разработанный Cisco. Потом RDEP был поддержан NFR, ISS, Sourcefire и на его основе родился SDEE. Но и его постигла судьба RDEP - кроме Cisco его никто не использовал. Отчасти потому, что стандарт, разработанный конкретной компанией, мало кто поддерживает из конкурентов (даже если стандарт хорош).

Но сейчас ситуация меняется и в отрасли стали появляться стандарты. Первой ласточкой стал CVE - Common Vulnerabilities and Exposures - стандарт, определяющий единое именование уязвимостей. Потом появился OVAL - Open Vulnerability and Assessment Language - стандартизованный язык описания уязвимостей в сканерах и системах анализа защищенности. Оба эти стандарта были разработаны под эгидой MITRE.

С тех пор число стандартов, над которыми MITRE взяла шефство, только возросло. Среди них:
- CCE - Common Configuration Enumeration - стандарт описания конфигураций, которые затем могут проверяться в сканерах и системах анализа защищенности
- CEE - Common Event Expression - стандарт описания, хранения и обмена сигналами тревоги между разнородными средствами защиты
- CME - Common Malware Enumeration - стандарт, похожий на CVE, но ориентированный на вредоносное ПО
- CWE - Common Weakness Enumeration - стандартизованный набор слабых мест в ПО. Этот стандарт не зацикливается только на уязвимостях как CVE и является более высокоуровневым, описывая типы проблем, а не их конкретные имена и проявления
- CPE - Common Platform Enumeration - стандарт описания и именования элементов ИТ-инфраструктуры
- CAPEC - Common Attack Pattern Enumeration and Classification - создание публичного каталога и схемы классификации шаблонов атак
- CRF - Common Result Format - стандартизация описания результатов тестирования или оценки защищенности.

Еще три стандарта появились не в MITRE, но тоже в Америке и тоже в известной своей деятельностью в области ИБ организации - Национальном институте стандартов США (NIST):
- SCAP - Security Content Automation Protocol - это даже не стандарт, а метод используюзий различные стандарты для автоматизации процесса управления уязвимостями
- CVSS - Common Vulnerability Scoring System - стандарт рейтингования уязвимостей
- XCCDF - eXtensible Configuration Checklist Description Format - стандартизованный язык описания чеклистов, тестирований и т.п.

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

17.06.2008

4 документа ФСТЭК: краткий анализ. "Методика определения актуальных угроз"

Итак, не без помощи добрых людей, удалось раздобыть 4 документа ФСТЭК, которые расширяют уже неоднократно упоминаемый мной "приказ трех". Прочтя их, решил поделиться кратким анализом. Итак, документ первый - "Методика определения актуальных угроз".

Начну с того, что методика ориентирована в т.ч. и на физлиц, исключая случаи создания информационных систем персональных данных (ИСПДн) для личных и семейных нужд.

Угрозой безопасности ПДн называется не только их утечка, но и иные несанкционированные или непреднамеренные воздействия на информацию. С одной стороны у нас достаточно широкий спектр угроз подпадает под понятие, данное ФСТЭК. С другой - мы сталкиваемся с проблемой терминологии. К чему, например, относится доступность? К информации или к информационной системе? Ведь блокируя работу той или иной ИС, с информацией мы ничего не делаем и вообще на нее никак не воздействуем, концентриясь на системе ее обработки, передачи и хранения. Т.е. доступность скорее относится к понятию "информационная система". А раз так, то угрозы доступности не относятся в сферу компетенции рассматриваемой методики ФСТЭК.

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

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

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

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

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

Под уровнем исходной защищенности ИСПДн понимается обобщенный показатель, зависящий от технических и эксплуатационных характеристик ИСПДн, перечисленных в методике. Например, территориальная распределенность ИСПДн, наличие подключения к Интернет, наличие встроенных механизмов регистрации событий, уровень обезличивания ПДн, объем ПДн, передаваемых наружу без обработки и т.д. У каждого из таких параметров есть три степени защищенности - высокий, средний и низкий, оценка которых осуществляется экспертом. Суммирование таких показателей и дает нам совокупный уровень исходной защищенности. Например, ИСПДн имеет высокий уровень исходной защищенности, если не менее 70% характеристик ИСПДн соответствуют уровню "высокий" и т.д.

С вероятностью все более или менее понятно. Оценка экспертная. Градация по четырехбалльной шкале - маловероятно, низкая вероятность, средняя вероятность и высокая.

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

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

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

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

Используя данные о классе ИСПДн (из "приказа трех") и составленного на основе рассмотренной Методики перечня актуальных угроз, на основе «Рекомендаций по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных» и «Основных мероприятий по организации и техническому обеспечению безопасности персональных данных, обрабатываемых в информационных системах персональных данных» "формулируются конкретные организационно-технические требования по защите ИСПДн от утечки информации по техническим каналам, от несанкционированного доступа и осуществляется выбор программных и технических средств защиты информации, которые могут быть использованы при создании и дальнейшей эксплуатации ИСПДн".

04.06.2008

Классификация информации

По заказу портала bankir.ru сотворил я нечто под названием "Классификация информации: что, зачем, кто, как и с помощью чего?", которая из обычной статьи на 3-4 страницы вылилась в некий "труд" на 18 листов. Мне даже самому понравилось ;-)

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

Первая часть статьи размещена на сайте bankir.ru, а дискуссия будет разворачиваться (я надеюсь) там же, но на форуме.