вторник, 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, СТО БР, интегратор, консультант) берется перечень основных решений по ИБ (которые выросли из универсального анализа рисков или моделирования угроз для большинства компании из определенной группы)

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


среда, 19 ноября 2014 г.

СОИБ. Анализ. Оценка ущерба в ИБ

Важно и нужно проводить оценку ущерба активам от угроз ИБ. Она потребуется при:
·        анализе рисков (ИСО 2700x, Cobit и др.),
·        выполнении требований законодательства по ПДн
·        моделировании угроз безопасности ПДн, ГИС, АСУ
·        замене одних мер защиты ПДн, ГИС, АСУ на другие компенсирующие
·        внутреннего маркетинга ИБ, обосновании необходимости службы ИБ, обоснования любых инвестиций в ИБ и т.п.

Не обязательно дожидаться запуска какого либо крупного проекта (например, по ПДн, АСУ, ГИС).  

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

Хорошо если активы в компании уже оценены в общем. Тогда ущерб активу от угроз ИБ будет составлять некоторую часть от его цены (не превышать). Даже если нет – самое время оценивать. Конечно же, к оценке будем привлекать владельцев активов.  

Чтобы правильно оценить ущерб нужно кроме прямых финансовых потерь учесть другие возможные последствия реализации угроз (и перевести их в деньги). Если точная оценка какого либо значения вызовет затруднения (недавно Михаил Хромов жаловался на невозможность оценки) – берите экспертные мнения (от трех экспертов и более). Если согласовывать бюджет вам будут те же лица, которые давали экспертную оценку ущерба (владельцы систем) – то проблем возникнуть не должно. К тому же опыт показывает что точный расчет и экспертная оценка в итоге дают схожий результат.

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



четверг, 6 ноября 2014 г.

СЗПДн. Анализ. Определение нарушителя для СКЗИ

В связи с выходом приказа ФСБ России по защите ПДн, а так-же в связи со сложностями реализации СКЗИ высоких классов криптографической защиты есть несколько мыслей…

Посмотрим какой порядок действий требуется в части СКЗИ:
Приказ ФСБ Р №378: “5. В соответствии с пунктом 13 Требований к защите персональных данных при их обработке в информационных системах персональных данных, утвержденных постановлением Правительства Российской Федерации от 1 ноября 2012 г. N11191 (далее - Требования к защите персональных данных), для обеспечения 4 уровня защищенности персональных данных при их обработке в информационных системах необходимо выполнение следующих требований:
...
г) использование средств защиты информации, прошедших процедуру оценки соответствия требованиям законодательства Российской Федерации в области обеспечения безопасности информации, в случае, когда применение таких средств необходимо для нейтрализации актуальных угроз.
9. Для выполнения требования, указанного в подпункте "г" пункта 5 настоящего документа, необходимо для каждого из уровней защищенности персональных данных применение СКЗИ соответствующего класса, позволяющих обеспечивать безопасность персональных данных при реализации целенаправленных действий с использованием аппаратных и (или) программных средств с целью нарушения безопасности защищаемых СКЗИ персональных данных или создания условий для этого (далее - атака), которое достигается путем:
а) получения исходных данных для формирования совокупности предположений о возможностях, которые могут использоваться при создании способов, подготовке и проведении атак;
б) формирования и утверждения руководителем оператора совокупности предположений о возможностях, которые могут использоваться при создании способов, подготовке и проведении атак, и определение на этой основе и с учетом типа актуальных угроз требуемого класса СКЗИ;
в) использования для обеспечения требуемого уровня защищенности персональных данных при их обработке в информационной системе СКЗИ класса КС1 и выше.”

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

В самом простом случае идут по пути реализации в одном документе (как правило, модель угроз) и требований ФСТЭК к определению угроз и требований ФСБ к определению угроз и нарушителей. Рассмотрим такой вариант.

При оценке рисков ИБ ИС наиболее опасными считаются угрозы от источников - внутренних пользователей ИС / сотрудников организации, так что скорее всего для ИС в целом будут актуальны внутренние нарушители (условно назовем Н3)


При таких актуальных типах нарушителей нам требуется использовать СКЗИ сертифицированные по классу не ниже КС3.
Приказ ФСБ Р №378: “10. СКЗИ класса КС1 применяются для нейтрализации атак, при создании способов, подготовке и проведении которых используются возможности из числа следующих:
в) проведение атаки, находясь вне пространства, в пределах которого осуществляется контроль за пребыванием и действиями лиц и (или) транспортных средств (далее контролируемая зона);
д) проведение атак на этапе эксплуатации СКЗИ на:
персональные данные;
и) проведение на этапе эксплуатации атаки из информационно-телекоммуникационных сетей, доступ к которым не ограничен определенным кругом лиц, если информационные системы, в которых используются СКЗИ, имеют выход в эти сети;
к) использование на этапе эксплуатации находящихся за пределами контролируемой зоны АС и ПО из состава средств информационной системы, применяемых на местах эксплуатации СКЗИ (далее - штатные средства).
11. СКЗИ класса КС2 применяются для нейтрализации атак, при создании способов, подготовке и проведении которых используются возможности из числа перечисленных в пункте 10 настоящего документа и не менее одной из следующих дополнительных возможностей:
а) проведение атаки при нахождении в пределах контролируемой зоны;
г) использование штатных средств, ограниченное мерами, реализованными в информационной системе, в которой используется СКЗИ, и направленными на предотвращение и пресечение несанкционированных действий.
12. СКЗИ класса КС3 применяются для нейтрализации атак, при создании способов, подготовке и проведении которых используются возможности из числа перечисленных в пунктах 10 и 11 настоящего документа и не менее одной из следующих дополнительных возможностей:
а) физический доступ к СВТ, на которых реализованы СКЗИ и СФ;”



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

Сертифицированных по КС3 VPN клиентов  раз, два и обчелся плюс есть системные проблемы использования VPN клиентов классов выше КС1 (об этом я писал ранее в серии статей), если сократить до двух фраз, то:
·        сертифицированные по классу КС1 VPN клиенты вам обойдутся в совокупности в 10 раз дороже чем не сертифицированные и заработают на порядка 75% необходимых устройств
·        сертифицированные по классу КС3 VPN клиенты вам обойдутся в совокупности в 10 раз дороже чем сертифицированные по классу КС1 и заработают на порядка 25% необходимых устройств.


Если необходима оптимизация – нужно дробить модель нарушителя, а именно определять актуального нарушителя (возможности нарушителя) для отдельных угроз. Далее, пример анализа в котором оставил столбцы касающиеся данной статьи:

№ п/п
Наименование угрозы (способ реализации угрозы, объект воздействия, используемая уязвимость, деструктивное действие)
....
Актуальность
Нарушитель
Необходимость применения СКЗИ для нейтрализации угрозы
1
Перехват информации, передаваемой по каналам связи, между компонентами ИСПДн расположенными в пределах одной  контролируемой зоны, использующий недостатки протоколов сетевого взаимодействия, приводящий к нарушению конфиденциальности информации

Актуальна
Н2, Н3
Другие меры
2
Перехват информации, передаваемой по каналам связи, между компонентами ИСПДн расположенными в пределах разных  контролируемых зон, использующий недостатки протоколов сетевого взаимодействия, приводящий к нарушению конфиденциальности информации

Актуальна
Н1
СКЗИ, КС1
3
Перехват информации, передаваемой по каналам связи, между компонентом ИСПДн расположенным пределах разных  контролируемой зоны и компонентом ИСПДн, расположенным в неконтролируемой зоне, использующий недостатки протоколов сетевого взаимодействия, приводящий к нарушению конфиденциальности информации

Актуальна
Н1
СКЗИ, КС1
4
Подмена информации, передаваемой по каналам связи, между компонентом ИСПДн, использующий недостатки протоколов сетевого взаимодействия, приводящий к нарушению целостности или доступности информации

Неактуальна
Н1, Н2, Н3
-
5
Локальная загрузка операционной системы с нештатного машинного носителя, для получения доступа к информации хранящейся на жестком диске компонента ИСПДн, использующая недостатки контроля доступа к компонентам ИСПДн, приводящая к нарушению конфиденциальности, целостности и доступности

Актуальна
Н3
Возможно СКЗИ, КС3

 PS: уточняющие вопросы отправлены ФСТЭК и ФСБ. Если будут интересные ответы, напишу...


среда, 15 октября 2014 г.

СОИБ. Анализ. Аттестация и проверка СЗИ



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

Ликбез из ГОСТ РО 0043-003-2012
Давайте посмотрим что может привести владельца ИС, не относящейся к гостайне, на эту темную сторону. Аттестация по требованиям ИБ обязательна для обеспечения ИБ в (возможно приведены не все варианты, дополняйте):
·        ГИС
Приказ ФСТЭК №17: “13. Для обеспечения защиты информации, содержащейся в информационной системе, проводятся следующие мероприятия:
аттестация информационной системы по требованиям защиты информации (далее – аттестация информационной системы) и ввод ее в действие;”
Информационное сообщение ФСТЭК N 240/22/2637: “В части государственных информационных систем, в которых обрабатываются персональные данные, оценка эффективности принимаемых мер по обеспечению безопасности персональных данных проводится в рамках обязательной аттестации государственной информационной системы по требованиям защиты информации в соответствии с Требованиями, утвержденными приказом ФСТЭК России от 11 февраля 2013 г. N 17, национальными стандартами ГОСТ РО 0043-003-2012 и ГОСТ РО 0043-004-2013 «Защита информации. Аттестация объектов информатизации. Программа и методики аттестационных испытаний».”
·        Государственные информационные ресурсы
СТР-К “На стадии ввода в действие объекта информатизации и СЗИ осуществляются: ...
• аттестация объекта информатизации по требованиям безопасности информации.”
·        ИС, участвующие в лицензируемой деятельности по СКЗИ
ПП № 313: “7. Для получения лицензии соискатель лицензии представляет (направляет) в лицензирующий орган заявление о предоставлении лицензии и документы (копии документов), указанные в пунктах 1, 3 и 4 части 3 статьи 13 Федерального закона "О лицензировании отдельных видов деятельности", а также следующие копии документов и сведения:
и) сведения о документе, подтверждающем наличие условий для соблюдения конфиденциальности информации, необходимых для выполнения работ и оказания услуг, определенных настоящим Положением, в соответствии с требованиями о соблюдении конфиденциальности информации, установленными Федеральным законом "Об информации, информационных технологиях и о защите информации";”
·        ИС, участвующие в лицензируемой деятельности по ТЗКИ
ПП №79: “5. Лицензионными требованиями, предъявляемыми к соискателю лицензии на осуществление деятельности по технической защите конфиденциальной информации (далее - лицензия), являются:
д) наличие автоматизированных систем, предназначенных для обработки конфиденциальной информации, а также средств защиты такой информации, прошедших процедуру оценки соответствия (аттестованных и (или) сертифицированных по требованиям безопасности информации) в соответствии с законодательством Российской Федерации;”

Аттестация по требованиям ИБ может проводится добровольно по решению владельца ИС:
·        АСУ
Приказ ФСТЭК №31: “По решению заказчика подтверждение соответствия системы защиты автоматизированной системы управления техническому заданию на создание (модернизацию) автоматизированной системы управления и (или) техническому заданию (частному техническому заданию) на создание системы защиты автоматизированной системы управления, а также настоящим Требованиям может проводиться в форме аттестации автоматизированной системы управления на соответствие требованиям по защите информации. В этом случае для проведения аттестации применяются национальные стандарты, а также методические документы ФСТЭК России.”
·        ИСПДн
Приказ ФСТЭК №21: “6. Оценка эффективности реализованных в рамках системы защиты персональных данных мер по обеспечению безопасности персональных данных проводится оператором самостоятельно или с привлечением на договорной основе юридических лиц и индивидуальных предпринимателей, имеющих лицензию на осуществление деятельности по технической защите конфиденциальной информации. Указанная оценка проводится не реже одного раза в 3 года.”
Информационное сообщение ФСТЭК N 240/22/2637:  “Оценка эффективности реализованных мер может быть проведена в рамках работ по аттестации информационной системы персональных данных в соответствии с национальным стандартом ГОСТ РО 0043-003-2012 «Защита информации. Аттестация объектов информатизации. Общие положения».”
·        ИС общего пользования
Приказ ФСТЭК № 489: “17.1. В информационных системах общего пользования I класса:
введение в эксплуатацию только после направления оператором информационной системы общего пользования в ФСБ России уведомления о готовности ввода информационной системы общего пользования в эксплуатацию и ее соответствии настоящим Требованиям.
17.2. В информационных системах общего пользования II класса:
введение в эксплуатацию только после направления оператором информационной системы общего пользования в ФСТЭК России уведомления о готовности ввода информационной системы общего пользования в эксплуатацию и ее соответствии настоящим Требованиям.”
·        Аккредитованные УЦ
Приказ Минкомсвязи №320 “8. Дополнительно УЦ, претендующий на получение аккредитации, может представить документы, подтверждающие:
соответствие требованиям по безопасности информации на объекте информатизации или копия заключения о соответствии требованиям по безопасности информации, выданных ФСТЭК России и ФСБ России в пределах их полномочий.”
·        Хостинги, дата-центры, торговые площадки, облачные сервис провайдеры, сервис провайдеры, интернет-магазины и другие ИС.
Почему-то так сложилось среди компаний которые оказывают безопасные сервисы и которым нужно какое-то подтверждение своим клиентам рассматривают  либо аттестацию на  соответствие требованиям безопасности информации в системе ФСТЭК либо сертификацию по ISO 27001. Все остальные формы (аудит, оценка соответствия в свободной форме) в серьез не рассматриваются.


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

Теперь подробнее:
Чаще всего Заявителю аттестации нужно только получить аттестат, желательно за минимальное время и стоимость (идеальный вариант – 1 рубль, 1 час). Какие именно проверки будут выполняться его не интересует.

Кто же будет определять, какие проверки будут выполняться? Посмотрим что-нибудь по этому поводу в последних ГОСТ-ах ГОСТ РО 0043-003-2012 и ГОСТ РО 0043-004-2013:

Порядок проведения аттестации включает следующие мероприятия:
·        Подачу заявки
·        Предварительное обследование
·        Разработку программы и методики аттестационных испытаний
·        Проведение испытаний
·        Выдача аттестата

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

Как я отметил выше – Заявителю всё равно какие проверки и методики. И тут мы получаем что у разных Лицензиатов могут существенно отличаться объем проверок:   у одного 3 проверки продолжительностью 5 минут, у другого 30 проверок по часу каждая. При этом речь не идет про некачественную работу, предполагаем что работы проводятся в полном соответствии законодательству РФ, просто имеет место разное экспертное мнение.  

Например, я бы рассмотрел следующие проверки в отношении СЗИ и выбрал необходимые из них:
·        проверка наличия прав на СЗИ (договора)
·        проверка наличия техподдержки на СЗИ (договора)
·        проверка наличия сертификата на СЗИ (документы по сертификации)
·        проверка наличия акта установки и настройки СЗИ (акт)
·        проверка наличия установленного СЗИ на каждом техническом средстве (горит зеленая лампочка)
·        соответствие настроек СЗИ требованиям ТЗ
·        соответствие настроек СЗИ требованиям Технического проекта
·        соответствие настроек СЗИ требованиям безопасности информации (исходным из законодательства)
·        работоспособность всех требуемых функций СЗИ
·        надежность всех требуемых функций СЗИ
·        отсутствие закладок или уязвимостей в СЗИ
·        соответствие контрольных сумм файлов СЗИ, тем которые указаны в формуляре
·        пентест ИС в условиях работы СЗИ
При этом кроме выбора самих проверок интересует ещё выбор объекта проверок: надо проверять СЗИ на каждом АРМ? Надо проверять каждое сетевое СЗИ из кластера?

Посмотрим, какие обязательные требования включает ГОСТ РО 0043-004-2013 в части проверки технических мер / СЗИ:  только одно существенно требование - проведение испытаний АС на соответствие требованиям по защите информации от НСД. Каждый Лицензиат под этим понимает что-то свое.

Есть мнение что правильная методика испытаний привидится в приложении Д к ГОСТ РО 0043-004-2013 и всем Лицензиатам надо на её ориентироваться.  Но практика показывает что это методика заточенная под гостайну (проверка требований к АС класса 1В, ГИС класса К1) так как, например, включает управление потоками информации. Практика показала, что бывают ситуации, когда СЗИ, настроенные в соответствии с рекомендациями производителя, например к классу 1Г, не могут пройти проверку  в соответствии с данной методикой, в которой выбраны только проверки, соответствующие классу 1Г.

Получается что пример методики из приложении Д к ГОСТ РО 0043-004-2013 приходится так  корректировать,  что лучше уж написать с нуля только те проверки, которые нужны.


2. Ещё одна проблема обязательной аттестации заключается как раз в свободе выбора мер защиты и СЗИ, которая обсуждалась недавно в блогах: тут и тут. При обязательной аттестации проверяется соответствие только требованиям законодательства. Соответствие внутренним документам – МУ, ТЗ, техническому проекту – проверяться не должно.

Приходит, например, лицензиат на аттестационные испытания, а у заявителя из СЗИ стоит только антивирус. Заявитель говорит что он выбирал, выбирал меры да и выбрал – получился только антивирус. Лицензиат хватается за “требования безопасности информации” (приказ 17) там написано, что меры могут быть такие-то, но выбирает заказчик.

Должен ли лицензиат проверить его выбор? Имеет ли он право оценивать выбор оператора? Что будет достаточным обоснованием для выбора/исключения мер?  На эти вопросы в нормативных документах нет ответа. Опять отдаемся на откуп экспертному мнению Лицензиата. Но это сначала экспертное мнение. А допустим, отказал Лицензиат в выдаче Аттестата. Заявитель подает в суд. Тут уж лицензиату придется аргументировать свои решения. Нет аргемента – выдавай аттестат.


пятница, 10 октября 2014 г.

СЗПДн. Анализ. Выбор мер защиты

Последний год в комментариях про последние документы ФСТЭК: приказы №17, 21, 31 регулярно встречаю фразы про невиданный ранее прорыв в требованиях регуляторв, про полную свободу выбора мер защиты Заказчиком.

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



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

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

Например, характеристики ИСПДн:
·        Типы пользователей ИС: работники и внешние пользователи
·        Уровни ИС, на которых выполняется управление доступом: ОС, сервис терминалов, приложение, СУБД
·        Структура ИС: распределенная информационная система.
·        Наличие подключений к ССОП и СМИО (Интернет): имеются подключения к сети Интернет
·        Режим обработки ПДн: многопользовательский.
·        Разграничение доступа пользователей: С разграничением прав доступа.
·        Место нахождения технических средств: все сервера ИС находятся в пределах РФ.
·        Применение виртуализации АРМ или серверов ИС: да
·        Применение мобильных устройств при работе с ИС: нет
·        Применение беспроводного доступа при работе с ИС: да

Из не применения мобильных устройств однозначно следует что мера УПД.15 исключается. Свободы выбора я тут не вижу. Скорее просто логика – нельзя защищать то, чего нет.

Под свободой я понимаю либо возможность исключения мер защиты в соответствии с неактуальностью определенных угроз, либо просто возможность исключения “неподходящих” мер на усмотрение оператора. Но сейчас этого нет. А в “старом” приказе №58 такая возможность была
“2.2. В системе защиты персональных данных информационной системы в зависимости от класса информационной системы и исходя из угроз безопасности персональных данных, структуры информационной системы, наличия межсетевого взаимодействия и режимов обработки персональных данных с использованием соответствующих методов и способов защиты информации от несанкционированного доступа реализуются функции управления доступом, регистрации и учета, обеспечения целостности, анализа защищенности, обеспечения безопасного межсетевого взаимодействия и обнаружения вторжений.”

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