четверг, 28 февраля 2013 г.

СОИБ. Аналитика. Отчет об анализе информационной безопасности Check Point 2013


В 2013 году компания Check Point опубликовала отчет об анализе информационной безопасности проводившемся в течении 2012 года. В данном отчете есть интересные цифры, которыми хотелось бы кратко поделиться.

Данные для анализа собирались из следующих источников:
·        Check Point ThreatCloud, в анализе участвовало 1494 Security Gateway
·        Check Point SensorNet (распределенная сеть сенсоров)
·        Check Point Endpoint Security reports в 628 компаниях
·        3D Security Onsite Analysis проведенных в 888 компаниях

В рамках услуги 3D Security OnsiteAnalysis,  компания Check Point бесплатно устанавливает на площадке заказчика свой шлюз безопасности на определенное время, а по результатам готовит для заказчика отчет об обнаруженных атаках, уязвимостях, недостатках и т.п.

Check Point Endpoint Security reports получен по результатам сканирования конечных узлов с использованием утилиты Check Point Endpoint Security report tool.

По результатам анализа сделаны следующие основные выводы:
·        В 63% компаний хотя бы 1 система заражена вредоносным ПО (botnet)
·        В 75% компаний пользователи заходили на зараженные сайты, распространяющие вредоносное ПО
·        В 53% в результате наличия уязвимостей или при содействии пользователя произошли загрузка вредоносного ПО с сайта
·        На 23% систем не было установлено актуальное обновление антивируса
·        На 14% систем не был запущен антивирус в постоянном режиме
·        На 75% систем не были установлены последние версии ПО пользователя сети Интернет (Acrobat Reader, Flash, IE, Java)
·        На 44% систем не был установлен последний сервис пак ОС Windows
·        В  61% компаний было обнаружено использование P2P приложений (таких как BitTorrent)
·        В 43% компаний было обнаружено использование анонимайзеров сети Интернет. 85% из них сообщили что использование такого ПО запрещено корпоративными политиками и инструкциями
·        В 80% компаний было обнаружено использование публичных файловых хранилищ (таких как Dropbox)
·        В 54% компаний в течении 6-дневного (в среднем) анализа происходили события “потенциальная утечка конфиденциальной информации” (то есть система фиксировала факты отправки во внешние сети конфиденциальной информации)
·        В 29% компаний была обнаружена передача через сеть Интернет данных кредитных карт
·        В 16% из медицинских и страховых компаний передавались во внешние сети персональные данные (номера SSN, паспортов, диагнозы)

Приложение. Графики из отчета:
Средняя частота загрузки вредоносного ПО в компаниях




Наиболее часто встречаемые уязвимости

Обнаруженные P2P клиенты

Обнаруженные анонимайзеры

Обнаруженное использование публичных файловых хранилищ

Обнаруженные события потенциальной утечки информации по типам компаний

Обнаруженная передача данных кредитных карт по типам компаний

Типы передаваемых данных  в обнаруженных событиях потенциальной утечки информации


среда, 20 февраля 2013 г.

СОИБ. Анализ. Создание защищенных ИС


Последнее время всё больше попадающихся мне тендеров, конкурсов, программ, концепций, заданий на создание крупных информационных систем (ИС), автоматизированных систем (АС, АСУ), содержащих разделы, связанные с информационной безопасностью. В связи с увеличением количества нормативных актов в области ИБ и вниманием общественности – у инициаторов проекта есть понимание, что защита информации должна быть и должна в какой то момент обеспечиваться.

Так же есть понимание какие мероприятия включает в себя жизненный цикл ИС (ГОСТ 34.601), какие стадии включает в себя жизненный цикл подсистем ИБ (СТР-К, проект приказа ФСТЭК по защите ГИС и т.п.).

Но пока нет общего понимания – какие мероприятия ИБ и в какой последовательности должны выполнятся на каждой создания новой ИС:
·        на какой стадии создания ИС должно выполняться моделирование угроз?
·        проектирование ПИБ выполнять одновременно с проектированием основного приложения или после?
·        какие мероприятия ИБ закладывать на этапе разработки концепции ИС?

Проанализировал имеющиеся у меня стандарты на предмет наличия привязки мероприятий по ИБ к стадиям создания ИС.

Наиболее полон в этом смысле ГОСТ Р 51583-2000, в котором указано что на каждой стадии создания ИС, должен выполняться аналогичный этап создания ПИБ. Не смотря на дату документа (2000 год) для ФСТЭК Р это всё ещё приоритетный документ (судя по проекту приказа ФСТЭК Р по защите ГИС).

Посмотрим проект ISO 27002-2013. Всё что там есть по этапам создания систем: 

“System requirements for information security and processes for implementing security should be integrated in the early stages of information system projects. Controls introduced at the design stage are significantly cheaper to implement and maintain than those included during or after implementation.”

Негусто. Но то что есть - важное указание внедрять ПИБ на самых ранних стадиях создания ИС.

Есть ещё стандарты из группы ISO 27034-x (от 1 до 5), но они до конца не разработаны.

В документе NIST 800-64 “Security Considerations in the System Development Life Cycle” так-же есть привязка мероприятий по информационной безопасности к стадиям создания ИС  (IT system development life cycle, SDLC). Так-же как в ISO, мероприятия по ИБ требуется начинать уже на самой ранней стадии создания ИС. Сам NIST-овский документ очень похож, по сути, на проект приказа ФСТЭК Р по защите ГИС, который ссылается на ГОСТ Р 51583-2000.

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

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






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


Приложение 1. Таблица сравнения ГОСТ Р 51583-2000 и NIST 800-64



Приложение 2. Схема этапов по NIST 800-64 




понедельник, 18 февраля 2013 г.

СОИБ. Анализ. ЦБ и электронные базы данных


На сайте ЦБ РФ выложен проект Положения Банка России "О порядке создания, ведения и хранения баз данных на электронных носителях" на экспертизу до 18 февраля.
В область действия документа попадает информация о сделках, банковских операциях, лицевых счетах и т.п.

Привожу ниже основные требования документа:

Требования к ИС, базе данных или системе резервного копирования:
·        информацию хранить не менее 5 лет
·        создавать резервные копии (РК)
·        хранить РК на резервном (отличном от основного) оборудовании или носителях
·        хранить РК на резервных площадках (местах отличных от основных мест обработки)
·        резервные площадки должны быть на территории РФ
·        обеспечить доступ к информации по состоянию на каждый операционный день
·        обеспечить оперативное восстановление информации
·        обеспечить восстановление событий и действий по внесению изменений

Требования к документации:
·        регламентация полномочий и ответственности лиц (создание, ведение, хранение, защиту)
·        регламентация действий (создание, ведение, хранение)
·        регламентация учета изменений и способов хранения
·        регламентация поддержания БД в актуальном состоянии
·        регламентация восстановления информации
·        регламентация мер по защите БД от порчи, утраты, заражения вредоносными кодами, НСД
·        паспорт резервных копий БД

Взаимодействие с ЦБ:
·        при отзыве лицензии направляет РК в ЦБ в течении трех дней по требованию ЦБ
·        передает РК в опечатанной упаковке
·        ЦБ обеспечивает хранение, исключающее доступ к информации

Документ требует проведения мероприятий в целом схожих с мероприятиями в рамках создания системыобеспечения непрерывности бизнеса и восстановления деятельности послепрерываний (ОНиВД).

Таким образом ЦБ наращивает количество требований в области непрерывности бизнеса, в дополнение к Указанию ЦБ ФР 2695-У и Положению № 379-П от 31.05.2012 (из серии НПС).

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

Меры по защите БД от НСД выбирает банк, но наиболее подходящей видится система защиты БД (типа Database Firewall, Database Activity Monitoring).

К проекту Положения есть несколько замечаний:
·        Что понимается под заражение БД вредоносным кодом? Какие то SQL инъекции или другие атаки на уровне БД   или это была ошибка и необходима защита ОС сервера и клиентов?
·        Если резервное копирование выполняются с использованием специализированного ПО или АПК (например, Symantec Backup Exec или NetApp Snapshot) или при создании РК применялось шифрование,  то нет гарантии, что ЦБ удастся самостоятельно восстановить информацию из БД

Кстати замечания к документу принимаются  до 18 февраля на адрес bnb@cbr.ru. Ещё есть несколько часов чтобы написать.