вторник, 30 июня 2015 г.

СОИБ. Анализ. Лучшие практики по ИБ из Австралии

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


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


По сравнению с предыдущим обзором ISM в 2012 году, ISM разделился на 3 документа, каждый из которых имеет свои цели и свою аудиторию:
·         Executive Companion (28 страниц) предназначен для руководства организаций и содержит описание основных угроз и нарушителей, 5 ключевых вопросов, на которые нужно ответить руководителю о состоянии ИБ в организации и даже пример ответов (case study)
·         Principles (78 страниц) предназначен для CISO, CIO и ответственных за ИБ и содержит основные принципы ИБ, которые необходимо учитывать при разработке политики ИБ, сгруппированы по блокам:  
o   Information Security Risk Management
o   Outsourced Information Technology Services
o   Roles and Responsibilities
o   Information Security Documentation
o   System Accreditation
o   Information Security Monitoring
o   Cyber Security Incidents
o   Physical Security
o   Personnel Security
o   Communications Infrastructure
o   Communications Systems and Devices
o   PSPF Mandatory Requirement INFOSEC 4 Explained
o   Product Security
o   Media Security
o   Software Security
o   Email Security
o   Access Control
o   Secure Administration
o   Network Security
o   Cryptography
o   Cross Domain Security
o   Data Transfers and Content Filtering
o   Working Off–Site
·         Controls (328 страниц) предназначен для менеджеров ИБ, консультантов, аудиторов и других практических специалистов по ИБ и содержит детальный перечень из 1300 мер (control) необходимых для реализации Принципов и снижения рисков до приемлемого уровня.

Говорить о проблемах и задачах ИБ на разных уровнях и разными языками, это важно. Для сравнения, в РФ тоже появились сильные актуальные нормативные и методические документы по ИБ, но разделять их по аудитории не стали – всё идет в перемешку.

По австралийскому ISM мы с топ. менеджерами обсуждаем вопросы:
·         К какому ущербу может привести серьезный инцидент ИБ?
·         Кому выгодно получить доступ к нашей информации?
·         Что мы предпринимаем чтобы защитится против актуальных угроз?
·         Придерживаются ли мои подчиненные культуры ИБ в своей работе?
·         Готовы ли мы к оперативному реагированию на инцидент ИБ?

Для CISO по различным направлениям ИБ приводится обоснование необходимости (Rationale), область действия (Scope), принципы ИБ которых нужно придерживаться в данной области (Principles) и ссылки на дополнительные источники информации (References). Пример:



Для экспертов, консультантов и аудиторов приводится необходимая информация для внедрения и проверки внедрения мер ИБ. Информация сгруппирована блоками по различным направлениям ИБ, в каждом блоке приводится информация о целях принятия мер (Objective), области действия (Scope), описание ситуаций, когда данные меры применимы / не применимы (Context), меры ИБ (Controls) и ссылки на дополнительные источники информации (References). Пример:



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

пятница, 26 июня 2015 г.

СЗПДн. Общее. Круглый стол Роскомнадзора по персональным данным в Краснодаре

22 июня 2015 г. управление РКН по ЮФО провело круглый стол с операторами персональных данных. В отличие от других мероприятий Роскомнадзора, в этот раз не было никаких докладов и соло выступлений. Двухминутное вступление и перешли к вопросам, ответам и обсуждению.

Собралось порядка 25 человек, из которых 2 представителя РКН, пара интеграторов и остальные -  операторы. С одной стороны – участников немного. С другой – помещение и не позволяло принять больше участников - стулья стояли на проходе и т.п. Небольшое помещение обещали компенсировать регулярностью мероприятий (раз в 2 месяца).

Основной огонь взяла на себя Долакова Е.В., также на вопросы отвечал врио руководителя управления Рахвалов А.Ю. Большую часть вопросов задала активная половина операторов, остальные пришли просто послушать. Обсуждали вопросы простые, типа:
·         как относиться к недавно вышедшему научно-практическому комментарию к 152-ФЗ?
·         что делать, если мнение местных специалистов РКН при проверке будет отличаться от научно-практического комментария к 152-ФЗ?
·         должны ли относится к ПДн фамилия + инициалы + плюс любая информация как указано в научно-практическом комментарии к 152-ФЗ?
·         как попасть / не попасть в план проверок?
·         какие нарушения чаще всего встречаются?
·         можно ли обрабатывать данные о судимости? что делать со справкой об отсутствии судимостей?
·         нужно ли собирать согласия с кандидатов на работу? что делать с этим, когда устраиваем сотрудника на работу?
·         можно ли обрабатывать резюме, загруженные с сайтов?
·         можно ли обрабатывать ПДн на личных АРМах дома или на смартфоне?
·         всегда ли нужно придерживаться формы согласия указанной в статье 9 части 4?
·         при передаче третьим лицам, нужно ли указывать в согласии каким именно?
·         можно ли хранить ПДн в помещении архива, а при необходимости использования, брать документы из архива? будет ли проверятся помещение архива?
·         какие требования к помещениям в которых хранятся ПДн?
·         нужно ли обезличивать ПДн? как определить, что ПДн обезличенные?
·         проводятся ли совместные проверки с ФСБ Р, ФСТЭК Р?
·         привлекаются ли независимые эксперты к проверкам?
·         что отправлять при изменении уведомления? придет ли ответ от РКН?
·         с какими обычно жалобами обращаются субъекты ПДн, какая статистика удовлетворения?
·         нужно ли уведомлять субъекта об окончании обработки ПДн?

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


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


понедельник, 22 июня 2015 г.

СОИБ. Анализ. Политики vs положения ИБ

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

По факту регулярно встречаюсь с фактом использования неких безразмерных положений о защите ПДн / ГИС / ИБ, которые часто включают в себя описание всевозможных угроз, всевозможных нарушителей, мер которые могут быть приняты, с цитированием всего законодательства РФ в области ИБ, с расшифровкой всех терминов в области ИБ, курс теории вероятности и т.п. Если выделяется отдельный документ по какой-то теме, то в нем так-же мешанина – и требования и процедуры и описание ролей и теория. Что делать пользователю / администратору с таким 50 – 100 – 200 страничным документом, совершенно непонятно. Полистать и забыть!

Как так получается? Давайте посмотрим, может быть есть какие-то требования или рекомендации делать такие документы-монстры?

Русскоязычные документы, содержащие описание состава ОРД по ИБ:
ИСО МЭК 27001 (подробный перечень можно посмотреть у Андрея Прозорова):
·         политика ИБ
·         частные политики ИБ
·         процедуры
·         записи / документированная информация
СТО БР ИББС:
·         корпоративная политика ИБ,
·         частные политики ИБ,
·         документы содержащие требования к процедурам обеспечения ИБ:
o   инструкции по обеспечению ИБ, в том числе и должностные;
o   руководства по обеспечению ИБ, например, по классификации активов;
o   методические указания по обеспечению ИБ;
o   документы, содержащие требования к конфигурациям,
·         документы содержащие записи о результатах деятельности:
o   реестры и описи;
o   регистрационные журналы, в том числе журналы регистрации инцидентов;
o   протоколы;
o   листы ознакомления;
o   обязательства;
o   акты;
o   договоры;
o   отчеты.
ПП 211 (перечень мер по защите ПДн для ГОС):
·         порядок
·         правила
·         перечни
·         формы

Англоязычные лучшие практики, содержащие описание состава ОРД по ИБ:
NIST:
·         IS policy
·         procedures

UNINETT led working group on security (No UFS126, Норвегия):
·         security policy
·         guidelines and principles for IS
·         standards and procedures for IS

·         Governing Policy
·         Technical Policies
·         Job Aids / Guidelines

·         Information security policy
·         procedures
·         plans


Как видно, нет оснований для создания мега-документов по ИБ (хотя в русскоязычной области ИБ, кроме стандарта ЦБ РФ, больше вопросы документации ОРД по ИБ толком не проработаны)

Публичные примеры 1, пример 2, пример3, пример 4, пример 5. А среди неопубликованных встречаются на порядок больше.

И хотя документы могут быть хорошо и правильно написаны, мое мнение что работать с таким мега-документом пользователям документа будет неудобно / невозможно.
Аргументы которые я слышал в пользу таких документов: это удобно для ИБшника, когда всё в одном документе; легче утверждать и обновлять 1 документ чем 30 документов;  удобно при проверках.

Как правило, если мне приходится разрабатывать документы, стараюсь соответствовать лучшим практикам и делать короткие простые документы - удается уложится до 10 листов для политики ИБ, по 2  листа на частные политики и 3-5 листов на регламенты/порядки/процедуры.
Для удобства при утверждении и обновлении, предлагаю объединять в один пакет политик, который утверждается разом, но каждый документ может использоваться по отдельности. А для удобства использования ИБшником и при проверках – лучше заранее готовить папочки или использовать системы управления документацией.


Коллеги, а какими практиками вы пользуетесь при разработке структуры документов по ИБ?

четверг, 4 июня 2015 г.

СОИБ. Аналитика. Отчет по актуальным угрозам от Check Point

На днях компания Check Point опубликовала отчет о состоянии информационной безопасности “2015 Security Report”. Посмотрим на наиболее интересную информацию из него

Методология – собирали данные из следующих источников:
·        Данные от 1300 компаний подписавшихся на бесплатную акцию Security Checkup
·        Данные из облака Check Point TreatCloud, к которому подключено более 16 тыс. компаний
·        Данные с более 3000 шлюзов, подключенных к сервису Threat Cloud Emulation Services
Кстати это лишнее напоминание к тому, что когда вы используете какие-то бесплатные или выгодные сервисы, сервисы так-же используют вас.



Собранные данные анализировались по следующим направлениям:
·        Unknown Malware
·        Known Malware
·        Mobile Security
·        High-Risk Applications
·        Data Loss Incidents

Анализ ранее не известных вредоносных программ (Unknown Malware):
·        в 2014 году 41% компаний хотя бы раз загружали не Unknown Malware (что на 25% больше чем в прошлом году)
·        в худшем случае Unknown Malware загружался в объемах 106 новых экземпляров в час
·        52% из зараженных файлов были формата PDF
Для защита от Unknown malware check point рекомендует использовать песочницы (OS- and CPU-level sandbox capabilities with threat extraction)

Анализ ранее известных угроз (Known Malware & Intrusion):
·        с 86% организаций были обращения на заражённые сайты
·        в 63% компаний пытались загрузить файлы с вредоносным содержимым
·        в 83% компаний были обнаружены зараженные узлы (bot)
·        по статистике обнаруженных атак (ips)
o   в сравнении с 2013 годом существенно возросло количество DDoS и DoS атак и попыток использования переполнения буфера
o   c 32% до 60% сместился вектор атак на клиентские узлы сети (Client side)



Для защиты от Known malware & Intrusion  Check point рекомендует использовать антивирусы, ips, anti-bot, url-фильтрацию, патч-менеджмент и ограничение административных привилегий в текущей работе.


Анализ безопасности мобильных устройств (Mobile Security):
·        в 91% организаций стали больше использоваться персональные мобильные устройства  при работе с корпоративной информацией
·        при этом 44% организаций не регламентируют и не управляют использованием мобильных устройств
·        в 42% инцидентов связанных с мобильными устройствами нанесенный ущерб превысил $250 000
·        из 900 тыс. исследованных мобильных устройств, более 1000 были заражены
Для защиты обработки корпоративных данных на мобильных устройствах  Check point рекомендует использовать шифрование и контроль доступа к файлам, регламентировать использование  мобильных устройств, применять MDM, использовать защищенные подключения к корпоративной сети.


Анализ использования небезопасных приложений (High-Risk Applications):
·        использование небезопасных приложений было обнаружено в 96% компаний
·        в 78% компаний обнаружено использование анонимайзеров
·        по остальным направлениям небольшой рост в 2% (подробнее на графиках)



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

Анализ инцидентов утечки информации (Data Loss Incidents):
·        81% компаний был обнаружен как минимум 1 инцидент потенциальной утечки данных
·        при этом в 41% случаев была обнаружена утечка конфиденциальной информации
·        в 25% случаев – утечка ПДн
·        по остальным направлениям осталось на уровне прошлого года (подробнее на графиках)


Для уменьшения рисков утечки данных Check point рекомендует шифровать данные при хранении и передаче, контролировать передачу на периметре, обучение и вовлечение пользователей в выбор разумных мер защиты при обработке корпоративных данных.