вторник, 30 декабря 2014 г.

Общее. Лучшие специалисты в области ИБ 2014 *

Алексей Волков – Лучший эксперт ИБ 2014. В номинации – самый бережливый 




Алексей Комаров – Лучший эксперт ИБ 2014. В номинации – каталогизатор



Алексей Лукацкий – Лучший эксперт ИБ 2014. В номинации – самый щедрый



Андрей Прозоров – Лучший эксперт ИБ 2014. В номинации – самый эффективно развивающийся



Артем Агеев – Лучший эксперт ИБ 2014. В номинации – самый захватывающий



Илья Медведовский – Лучший эксперт ИБ 2014. В номинации – самый критикуемый 



Ксения Шудрова – Лучший эксперт ИБ 2014. В номинации – самый простонародный



Михаил Емельянников – Лучший эксперт ИБ 2014. В номинации – самый правозащитный



Ригель – Лучший эксперт ИБ 2014. В номинации – самый критический






* Последнее время при проведении каких либо рейтингов или голосований не производится особых усилий для обеспечения объективности выбора призеров. Блог https://sborisov.blogspot.ru решил поддержать эту традицию и приводит итоги рейтинга “Лучший эксперт ИБ 2014” по мнению экспертного сообщества блога https://sborisov.blogspot.ru


пятница, 26 декабря 2014 г.

СЗПДн. Проектирование. Регистрация событий ИБ

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

Чтобы ничего не упустить, вспомним требования из НД регуляторов:
Приказ ФСТЭК Р №21:
“8.5. Меры по регистрации событий безопасности должны обеспечивать сбор, запись, хранение и защиту информации о событиях безопасности в информационной системе, а также возможность просмотра и анализа информации о таких событиях и реагирование на них.
Приложение.
V. Регистрация событий безопасности (РСБ)
РСБ.1 Определение   событий   безопасности,   подлежащих регистрации, и сроков их хранения
РСБ.2 Определение  состава  и  содержания  информации  о событиях безопасности, подлежащих регистрации
РСБ.3 Сбор, запись  и  хранение  информации  о  событиях безопасности  в   течение   установленного   времени хранения
РСБ.5 Мониторинг    (просмотр,    анализ)    результатов регистрации событий безопасности и  реагирование  на них
РСБ.7 Защита информации о событиях безопасности
XI. Защита среды виртуализации (ЗСВ)
ЗСВ.3 Регистрация  событий  безопасности  в  виртуальной инфраструктуре”
Приказ ФСБ Р №378:
“20. Для выполнения требования, указанного в пункте 19 настоящего документа, необходимо:
б) обеспечение информационной системы автоматизированными средствами, регистрирующими запросы пользователей информационной системы на получение персональных данных, а также факты предоставления персональных данных по этим запросам в электронном журнале сообщений;
23. Для выполнения требования, указанного в подпункте "а" пункта 22 настоящего документа, необходимо:
а) обеспечение информационной системы автоматизированными средствами, позволяющими автоматически регистрировать в электронном журнале безопасности изменения полномочий сотрудника оператора по доступу к персональным данным, содержащимся в информационной системе;
б) отражение в электронном журнале безопасности полномочий сотрудников оператора персональных данных по доступу к персональным данным, содержащимся в информационной системе. Указанные полномочия должны соответствовать должностным обязанностям сотрудников оператора;
в) назначение оператором лица, ответственного за периодический контроль ведения электронного журнала безопасности и соответствия отраженных в нем полномочий сотрудников оператора их должностным обязанностям (не реже 1 раза в месяц).”

Как минимум вам необходимо иметь план регистрации, сбору и анализу событий ИБ. Если же вы заказываете проектирование СЗПДн или разработку ОРД или ЭД, то необходимо требовать наличия в них разделов связанных с регистрацией событий ИБ.

Для типовой СЗПДн план регистрации событий будет примерно следующий (для типового оператора с центральным офисом в 500 чел. и двумя удаленными офисами в 100 чел. и типовым набором СЗИ в рамках СЗПДн)



Для примера расчетов использовались условные предположения о том, что в среднем пользователь раз в 10 минут обращается к новому ресурсу, 2 раза в день запускает (пробуждает) ОС, 8 раз входит в ОС (после блокирования сессии), активный пользователь ИСПДн раз в минуту обращается к ПДн, 10 раз в день печатает документ, удаленный пользователь 2 раза в день подключается по VPN и т.п. предположения основанные на опыте.  Данные цифры необходимо будет заменить на актуальные для вашей компании.

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

Когда мы переходим к реализации плана по регистрации, сбору и анализу событий ИБ, мы можем столкнуться со следующими сложностями / проблемами:
·        Нам необходимо собирать события ИБ разными способами (Syslog, SNMP, SDEE, копирование файлов, SQL запросы) с большого количества источников (даже с учетом максимальной централизации – от 15 источников).
·        Нам необходимо просматривать и  анализировать порядка 155 000 событий в день.
·        Нам нужно хранить в оперативном доступе порядка 10 000 000 событий и периодически проводить в них поиск в рамках обработки инцидента
·        Все компоненты участвующие в регистрации, сборе и анализе событий ИБ реализуют меры ИБ и соответственно должны быть сертифицированы (либо пройти оценку соответствия)

По первым 3 проблемам – надо грамотно планировать трудовые ресурсы на регистрацию, сбор и анализ событий ИБ и пытаться максимально автоматизировать данные процессы (например, SIEM).


По последней проблеме напишу детально в следующей заметке.


четверг, 4 декабря 2014 г.

Общее. Не ассоциации, а клубы по ИБ

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

И как мы видели в этом году, даже небольшая но инициативная группа ИБшников может сделать многое:
·        Товарищество Russian Information Security Club провели несколько интересных мероприятий и большое количество онлайн мастер-классов поИБ
·        Групп Defcon Russia, объединяющая исследователей уязвимостей и специалистов offensive направления ИБ, провели большое количество встреч, разрабатывают различные онлайн проекты поИБ

Есть и совсем новенькие:
Сегодня первая встреча Russian IDM Architects Club  - междусобойчик специалистов по системам централизованного управления учетными записями.


В ближайшее время состоится первая встреча OWASP Russia Chapter в Москве, в офисе яндекса.  
Почитать про мероприятие можно тут, а зарегистрироваться тут.

Open Web Application Security Project – международная некоммерческая организация, имеющая интересы в безопасной разработке, внедрении, эксплуатации, оценке и защите  web приложений (и просто современных приложений) и известная своими открытыми проектами в области безопасности web приложений и мероприятиями по теме безопасности приложений.

понедельник, 1 декабря 2014 г.

Общее. Как выбирать ИБ

1. Регулярно сталкиваюсь с такой ситуацией, что специалисты со стороны компании – заказчика, под предводительством CISO пытаются детально разобраться в особенностях работы всех СЗИ и проводят тестирование/пилотирование всех доступных решений, пытаются найти себе “самое лучшее для компании решение”. (частично этот подход продвигал Алексей Волков)

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

Это всё хорошо и приятно для самих специалистов, но надо понимать, что при этом реализуются их личные интересы, а не цели компании.

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


2. Ещё одна часто встречаемая мной ошибка – когда CISO заказчика имея бюджет на год начинает собирать / рассматривает предложения по всем возможным типам решений по принципу “у меня есть бюджет, пусть сбегаются все вендоры и интеграторы со своими предложениями, возьму самое вкусное”.

Может так случится что вы попадетесь на модный тренд или красиво говорящего менеджера и купите решение, которое не будет снижать неприемлемые риски ИБ или будет снижать но в 10 раз менее эффективно чем решение другого типа.

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

Тут может быть только 2 подхода:
·        или решения определяются по результатам анализа рисков ИБ (моделирования угроз) для данной конкретной компании
·        или из доверенного источника (top20 SANS, СТО БР, интегратор, консультант) берется перечень основных решений по ИБ (которые выросли из универсального анализа рисков или моделирования угроз для большинства компании из определенной группы)

Иными словами кратко: “самостоятельный анализ” либо “лучшие практики”.