среда, 29 февраля 2012 г.

СОИБ. Австралийский стандарт ИБ


Австралийское правительство (Департамент защиты) недавно выпустило объемное руководство по информационной безопасности, которое является частью их Государственной политики (за ссылку спасибо пользователю gvakiev с bankir.ru).

Целью документа является внедрение риск-ориентированного подхода в обеспечении ИБ. В документе вводится и активно используется термин кибербезопасность (Cyber security) как часть информационной безопасности.
Документ является обязательным для госучреждений Австралии, организаций которые получают доступ к государственной непубличной информации, а так-же организаций заключивших специальные соглашения Financial Management and Accountability Act, Commonwealth Authorities and Companies Act (как я понимаю сюда входят ключевые организации и например Банки).
Документ состоит из крупных областей обеспечения ИБ, каждый из которых делится на секции, посвященные определенным мерам (controls), каждая из которых состоит из разделов:
·        целей применения меры защиты
·        область действия и применимость меры
·        описание применяемых мер (controls)
·        обоснование для применения защитных мер и разъяснения
·        ссылки на внешние документы
Для каждой защитной меры приводится пометка, для защиты какого класса информации она должна применяться (G – служебная, P - ограниченного доступаC-конфиденциальнаяS - секретная, TS –совершенно секретная). Для систем общего доступа предлагается выбирать меры защиты на свое усмотрение.
Для каждой защитной меры приводится пометка:
·        обязательная мера (required),
·        обязательное мера, но может быть принято решение высшего руководства о компенсировании её другой мерой (must)
·        обязательное мера, если риск актуален, может быть принято решение ответственного лица о неприменении (should)
·        рекомендованная (recommended) 
То есть обязательные меры в документе есть их немало.
Из интересненького:
Госучреждения должны уведомить специальный центр Cyber Security Operations Centre Департамента защиты, если они приняли решение не применять обязательные меры и обосновать почему.
В документе описаны все государственные учреждение уполномоченные в области ИБ и приведены их функции.
Сервис провайдеры, предоставляющие услуги госучреждению должны быть аккредитованы и внедрять те же меры защиты что и учреждение.
 В учреждениях вводятся такие обязательные должности ответственные за ИБ как:
·        Agency head (must)
·        Chief Information Security Officer (must)
·        Security advisor (should)
·        Information technology security advisor (must)
·        Information technology security managers (must)
·        Information technology security officers (must)
Требуется чтобы они были и описывается распределение их обязанностей, так-же как и обязанности владельцев систем и пользователей систем.
Предлагается следующая структура документации по ИБ:
·        Общая политика ИБ (must)
·        План управления рисками безопасности (охватывающий все системы must)
·        План обеспечения безопасности (охватывающий все системы must)
·        Операционные процедуры (для всех систем should), в том числе процедуры для ITSM:
o   Cyber security incidents
o   Access control
o   Asset musters
o   Audit logs
o   Configuration control
o   Cyber security incidents
o   Data transfers
o   ICT equipment
o   System integrity audit
o   System maintenance
o   User account management
процедуры для System administrator:
o   Access control
o   Configuration control
o   System backup and recovery
o   User account management
процедуры для System user:
o   Cyber security incidents
o   End of day
o   Media control
o   Passwords
o   Temporary absence
·        План реагирования на инциденты и процедуры действий в чрезвычайных ситуациях (must)
Требуется сообщать о всех значительных инцидентах кибербезопасности и рекомендуется сообщать о незначительных инцидентах кибербезопасности в специальный центр Cyber Security Operations Centre Департамента защиты.

В основном в документе речь идет про организационные мероприятия но есть разделы связанные со средствами защиты информации, такими как:
·        Intrusion Detection and Prevention (should)
·        Защита email (should)
·        Gateways (между разными доменами безопасности must)
·        Content Filtering  (must)
·        Firewalls (must)
·        Diodes (must)
Для некоторых средств так-же приводятся требования по сертификации на EAL2, EAL4 по ОК.
В общем все приведенные меры и подход к ним в целом выглядят разумными. Я бы сказал это и есть те самые нужные “основные мероприятия” с учетом риск-анализа.
Документ получился довольно интересный и комплексный (как например СТО БР ИББС), можно почитать чтобы понимать как ОНО делается в других странах. 

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

СОИБ. Оценка рисков. База инцидентов ИБ


Недавно на incidents.su был опубликован отчет по инцидентам ИБ за 2011 год.
База инцидентов вышла на достаточно серьезный уровень в 850 инцидентов, который позволяет её использовать в некоторых задачах. Хочется надеется, что авторы ресурса incidents.su и приведенного отчета (кроме них в России базы инцидентов ведутся компаниями Infowatch и Group-IB) планируют использовать данную базу не только в своих целях, но и сделают достоянию общественности. 
Ведь любая занимающаяся анализом рисков нуждается в такой базе, для проведения точных расчетов.  Но пока нет базы, готовой к применению.

1.            Зачем такая база нужна организации проводящей анализ рисков ИБ?
Как правило, при оценке рисков выполняются следующие мероприятия:
·        составляется перечень оцениваемых активов (или типов активов)
·        составляется перечень возможных угроз
·        оценивается вероятность реализации угрозы
·        оценивается возможный ущерб от угрозы
·        оцениваются риски ИБ в соответствии с выбранной методологией
Специалист проводящий оценку рисков хочет увеличить объективность своей оценки опираясь на некую историческую статистику.
Для этого может использоваться база инцидентов по всему миру (как правило, объемная, широко охватывающая все возможные угрозы, но для России не совсем точная, в виду отставания в информатизации на 1-2 года), которая детализируется и уточняется статистикой инцидентов по России (пока охват невелик, ввиду закрытости инцидентов в России, но по тому что опубликовано, статистика более точная) и уточняется статистикой по инцидентам внутри самой организации (как правило в базе минимум инцидентов, но их достоверность самая высокая).

Приведу несколько пожеланий к авторам, ведущим базу incidents.su, а так-же ведущим других баз инцидентов ИБ.
2.            Нужно положение о применимости базы. В нем должно быть описано:
·        инциденты связанные с какими угрозами попадают в базу
·        инциденты связанные с какими угрозами не попадают в базу по причине отсутствия публикаций (например, инциденты по которым ущерб минимален)
·        инциденты связанные с какими угрозами не рассматриваются авторами, потому что им не интересны
·        рекомендации авторов по использованию базы, в которых описывается как эта база дополняет или заменяет другие базы – статистики в мире и статистике в организации.

3.            Какую информацию хотелось бы видеть в базе по каждому инциденту:
·        Дату инцидента (статистика по более свежим инцидентам более достоверна)
·        Источник информации об инциденте (пригодится для оценки достоверности информации)
·        Наименование организации в которой произошел инцидент
·        Отрасль организации в которой произошел инцидент (для оценки более достоверна будет выборка инцидентов по своей отрасли)
·        Качественная оценка размера организации по шкале “малый”, “средний”, “крупный” (некоторые инциденты характерны только для крупных организаций, другие наоборот для малых)
·        Текстовое описание инцидента
·        Описание угрозы реализацией которой связан инцидент.
(Нужно для определения вероятности определенной угрозы. Взяв количество инцидентов в год, связанных с определенным классом угроз – получим его вероятность.
Но для этого надо ввести базовую классификацию угроз.  Авторы incidents.su предложили следующие классы угроз: Утечки, DDoS, Взлом, Кража, Фишинг, Сбой, Другое.
Мне кажется данный вариант слишком простым. Надо использовать кукую-то методологию. Например, вариант от ФСТЭК:  угроза = источник угрозы + уязвимость + способ реализации угрозы + объект воздействия + тип несанкционированного воздействия
Способ реализации угрозы – можно как раз использовать классы предложенные авторами. Объект воздействия - тип актива. Тип несанкционированного воздействия – нарушение доступности, целосности, доступности и т.п.)
o   источник угрозы
o   уязвимость, которая использовалась для реализации угрозы
o   способ реализации угроз
o   объект воздействия
o   тип несанкционированного воздействия
·        Сумма ущерба связанного с инцидентом в рублях (нужно для определения степени опасности угроз)
·        Качественная оценка степени ущерба по шкале “низкий”, “средний”, “высокий” (там где не удается сразу оценить в деньгах)
·        Текстовое описание ущерба, на основе которого сделана оценка
В любом случае авторам incidents.su хочу сказать спасибо за начинание и прошу рассматривать данную заметку не как критику, а как возможно полезные предложения.


UPD: Если авторам incidents.su не хвататет ресурсов для реализации каких-то задач или для сбора информации об инцидентых из каких-то источников то было бы логично написать на сайте просьбу о помощи, которую могут оказать другие энтузиасты:

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



Возможно кто-то обладает небольшиз запасом времени и готов помочь если это ему будет инетересно.

пятница, 24 февраля 2012 г.

СОИБ. Обеспечение непрерывности бизнеса и восстановления деятельности (Часть 2)


привожу интервью с автором курса - Алексеем Бореалисом, руководителем группы разработчиков стандарта АРБ.


Почему нужна непрерывность бизнеса?
В условиях больших мегаполисов существует большое число чрезвычайных ситуаций, происходящих в любом районе города - от элементарного пожара до блокировки здания правоохранительными органами. Риски могут быть как технологического характера (просадка здания, обрыв кабеля из-за строительных работ, сбой в серверной из-за прорвавшейся водопроводной трубы или отключившегося в непредвиденно жаркую погоду кондиционера и т.д.), природного характера (подмыв грунтовыми водами, сильнейшие морозы и т.д.), юридического характера (неправильно оформленный договор аренды с последующим вынужденным выселением), так и социального характера (беспорядки в районе, эпидемия и т.д.). Не важно в чем именно риск, важно, что последствие риска – недоступность:
·        здания;
·        персонала;
·        ИТ и телекоммуникаций;
·        информации;
·        прочих технологий;
·        резерва ликвидных средств (для финансовых организаций);
·        внешних ключевых провайдеров, без которых немыслима деятельность организации
Как следствие работа всего или существенной части офиса (филиала) компании прерывается. На ликвидацию последствий ЧС и восстановления деятельности обычно уходит от нескольких недель до нескольких месяцев. Именно в этот период существует серьезная вероятность не выполнить минимальный объем обязательств (перед клиентами, регуляторами, иными заинтересованными сторонами) и, как следствие, потерять ключевые позиции на рынке, потерять ключевых клиентов, потерять лицензию на деятельность, понести потери, после которых просто невозможно восстановить деятельность и т.д. То есть в этот период существует риск потери всего или существенной части нормального бизнеса. По статистике DRII 93% компаний, не имевших систему непрерывности бизнеса, не продержались и 5 лет на рынке после ЧС, а 50% компаний, которые восстанавливали свою деятельность более 10 дней, уже не смогли восстановить ее вовсе.
Непрерывность бизнеса позволяет заранее спланировать и отрепетировать работы по аварийному восстановлению и продолжению ключевой деятельности бизнеса вне зоны поражения на время ликвидации последствий ЧС. То есть, фактически, спасти бизнес в кризисной ситуации. Это по-военному отлаженная методология, пришедшая к нам с Запада. 


Чем стандарт АРБ может помочь в вопросах обеспечения непрерывности и восстановления деятельности?
Существующие рекомендации, содержащиеся в положении 242-П касательно ОНиВД носят весьма общий характер. Стандарт четко структурирует требования к системе обеспечения непрерывности, включая все этапы ее создания, иерархию документов и т.д. Это сильно облегчает жизнь банкам, следующим рекомендациям ЦБ.


Какое обучение проводится на базе учебного центра компании Микротест по этой теме?
Компания Регул совместно с УЦ Микротест проводит ряд семинаров именно по теме обеспечение непрерывности бизнеса. 21-го и 22-го февраля прошел первый семинар из этого цикла - знакомство со стандартом Ассоциации Российских Банков в области обеспечения непрерывности и восстановления деятельности (ОНиВД), который был создан в поддержку инициативы ЦБ о вводе планов ОНиВД (положение 242-П) на территории всех кредитных организаций Российской Федерации.



В чем ценность семинара “Стандарт АРБ. Обеспечение непрерывности бизнеса и восстановления деятельности для Банков в соответствии с требованиями ЦБ РФ” по сравнению с самостоятельным прочтением стандарта?
Стандарт, в общем-то, сухой и скучный документ. Более того, многие пункты могут потребовать устного разъяснения. Его самостоятельное прочтение дает определенную картину, но оставляет массу вопросов, в особенности в области практической реализации требования стандарта. В будущем, в рамках АРБ будут создаваться методические пособия - приложения к стандарту. Но даже они не заменят живого диалога и практических упражнений, проходящих в рамках семинара.
От себя добавлю, что это наиболее быстрый способ войти в тему, по сравнению с самостоятельным изучением.


Каким вы видите участие подразделений ИБ в обеспечении непрерывности бизнеса?
Во-первых, задача ИБ и непрерывности бизнеса полностью пересекаются в области обеспечения доступности данных в условиях ЧС. СТО БР, равно как и 27001 ссылаются на планы обеспечения непрерывности бизнеса (обеспечения доступности в кризисной ситуации).

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


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


Сколько времени в среднем занимает внедрение системы управления непрерывностью?
От 4 до 6 месяцев в одном отделении (офисе), если двигаться в очень хорошем темпе, то есть быстро согласовывать промежуточные результаты. 

среда, 22 февраля 2012 г.

СОИБ. Обеспечение непрерывности бизнеса и восстановления деятельности (Часть 1)



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

1.                  Необходимость обеспечения непрерывности бизнеса понятна любому руководителю организации. Но обязательно обратите внимание на внешние требования по обеспечению непрерывности:
·         161-ФЗ О национальной платежной системе:
“Статья 12. Оператор электронных денежных средств и требования к его деятельности
6. Оператор электронных денежных средств обязан обеспечить бесперебойность осуществления перевода электронных денежных средств в соответствии с требованиями, установленными нормативными актами Банка России.
4. Оператор электронных денежных средств обязан уведомить Банк России в установленном им порядке о начале деятельности по осуществлению перевода электронных денежных средств не позднее 10 рабочих дней со дня первого увеличения остатка электронных денежных средств. В уведомлении должны быть указаны:
4) порядок обеспечения бесперебойности осуществления перевода электронных денежных средств;
Статья 24. Требования к значимой платежной системе
1. Банк России устанавливает следующие требования к системно значимой платежной системе:
4) обеспечение гарантированного уровня бесперебойности оказания операционных услуг;
Статья 28. Система управления рисками в платежной системе
3. Система управления рисками должна предусматривать следующие мероприятия:
4) определение показателей бесперебойности функционирования платежной системы в соответствии с требованиями нормативных актов Банка России;
5) определение порядка обеспечения бесперебойности функционирования платежной системы в соответствии с требованиями нормативных актов Банка России;
Статья 33. Порядок проведения инспекционных проверок поднадзорных организаций
2. При нарушении бесперебойности функционирования значимой платежной системы Банк России проводит внеплановые инспекционные проверки.
Статья 34. Действия и меры принуждения, применяемые Банком России в случае нарушения поднадзорной организацией требований настоящего Федерального закона или принятых в соответствии с ним нормативных актов Банка России
2. В случаях, если нарушения требований настоящего Федерального закона или принятых в соответствии с ним нормативных актов Банка России поднадзорной организацией влияют на бесперебойность функционирования платежной системы либо на услуги, оказываемые участникам платежной системы и их клиентам, Банк России применяет одну из следующих мер принуждения:
1) направляет предписание об устранении нарушения с указанием срока для его устранения;
2) ограничивает (приостанавливает) предписанием оказание операционных услуг, в том числе при привлечении операционного центра, находящегося за пределами Российской Федерации, и (или) услуг платежного клиринга.”
·         Указание ЦБФР 2695-У О требованиях к обеспечению бесперебойности осуществления перевода электронных денежных средств
“3. Оператор электронных денежных средств обязан принимать следующие меры, направленные на обеспечение бесперебойности осуществления перевода электронных денежных средств:
    осуществлять меры, направленные на недопущение нарушений функционирования операционных и технологических средств, устройств, информационных систем, обеспечивающих учет информации об остатках электронных денежных средств и их перевод, а в случае возникновения указанных нарушений осуществлять меры по их устранению;
    проводить анализ причин нарушений функционирования операционных и технологических средств, устройств, информационных систем, выработку и реализацию мер по их устранению;
    обеспечивать сохранение функциональных возможностей операционных и технологических средств, устройств, информационных систем при сбоях в их работе (далее - отказоустойчивость), осуществлять их тестирование в целях выявления недостатков функционирования, а в случае выявления указанных недостатков принимать меры по их устранению.
    4. Для организации деятельности, связанной с обеспечением бесперебойности осуществления перевода электронных денежных средств, оператор по переводу электронных денежных средств утверждает, внутренние документы в соответствии с пунктом 4 части 5 статьи 12 Федерального закона N 161-ФЗ (далее - внутренние документы).
Внутренние документы должны содержать:
    перечень возможных причин нарушения функционирования операционных и технологических средств, устройств, информационных систем, влекущих прекращение осуществления перевода электронных денежных средств или его ненадлежащее осуществление, и сроки их устранения;
    план действий в случае нарушения функционирования операционных и технологических средств, устройств, информационных систем, направленный на восстановление их функционирования, в том числе путем применения резервных операционных и технологических средств, устройств, информационных систем, а также сроки проведения мероприятий в рамках применяемого плана;
    перечень и периодичность проведения регламентных работ по обеспечению отказоустойчивости;
    порядок резервного копирования информации об осуществленном переводе электронных денежных средств, об остатках электронных денежных средств, а также хранения такой информации, в том числе сроки ее хранения;
    порядок контроля за обеспечением бесперебойности осуществления перевода электронных денежных средств.
    Внутренние документы могут включать иные положения, направленные на обеспечение бесперебойности осуществления перевода электронных денежных средств.
    6. Оператор по переводу электронных денежных средств разрабатывает и утверждает внутренние документы, предусмотренные настоящим Указанием, в течение одного месяца со дня вступления в силу настоящего Указания.”
·         Положение ЦБ РФ 242-П Об организации внутреннего контроля в кредитных  организациях и банковских группах:
“3.5. Контроль за управлением информационными потоками (получением и передачей информации) и обеспечением информационной безопасности.
3.5.3. Общий контроль автоматизированных информационных систем предусматривает контроль компьютерных систем (контроль за главным компьютером, системой клиент-сервер и рабочими местами конечных пользователей и т.д.), проводимый с целью обеспечения бесперебойной и непрерывной работы.
Общий контроль состоит из осуществляемых кредитной организацией процедур резервирования (копирования) данных и процедур восстановления функций автоматизированных информационных систем, осуществления поддержки в течение времени использования автоматизированных информационных систем, включая определение правил приобретения, разработки и обслуживания (сопровождения) программного обеспечения, порядка осуществления контроля за безопасностью физического доступа.
3.7. Кредитная организация должна иметь разработанные планы действий на случай непредвиденных обстоятельств с использованием дублирующих (резервных) автоматизированных систем и (или) устройств, включая восстановление критических для деятельности кредитной организации систем, поддерживаемых внешним поставщиком (провайдером) услуг. Внутренними документами должен быть определен порядок проверки этих планов в части их выполнимости в случаях возникновения непредвиденных обстоятельств, а также перечень непредвиденных обстоятельств, в отношении которых разрабатываются планы действий.
4.4. Служба внутреннего контроля осуществляет следующие функции:
4.4.3. Проверка надежности функционирования системы внутреннего контроля за использованием автоматизированных информационных систем, включая контроль целостности баз данных и их защиты от несанкционированного доступа и (или) использования, наличие планов действий на случай непредвиденных обстоятельств;“
·         149-ФЗ Об информации, информационных технологиях и о защите информации:
“Статья 8. Право на доступ к информации
5. Государственные органы и органы местного самоуправления обязаны обеспечивать доступ, в том числе с использованием информационно-телекоммуникационных сетей, в том числе сети "Интернет", к информации о своей деятельности на русском языке и государственном языке соответствующей республики в составе Российской Федерации в соответствии с федеральными законами, законами субъектов Российской Федерации и нормативными правовыми актами органов местного самоуправления. Лицо, желающее получить доступ к такой информации, не обязано обосновывать необходимость ее получения.
7. В случае, если в результате неправомерного отказа в доступе к информации, несвоевременного ее предоставления, предоставления заведомо недостоверной или не соответствующей содержанию запроса информации были причинены убытки, такие убытки подлежат возмещению в соответствии с гражданским законодательством.”
Статья 16. Защита информации
4. Обладатель информации, оператор информационной системы в случаях, установленных законодательством Российской Федерации, обязаны обеспечить:
5) возможность незамедлительного восстановления информации, модифицированной или уничтоженной вследствие несанкционированного доступа к ней;”

“III. Требования к информационной безопасности СЭД ФОИВ, в том числе при обработке служебной информации ограниченного распространения
31. Для обеспечения безопасности электронных документов СЭД ФОИВ должна предусматривать возможность регулярного резервного копирования электронных документов (электронных образов документов), метаданных, восстановления электронных документов (электронных образов документов), метаданных из резервных копий. Регулярное автоматизированное резервное копирование и восстановление могут быть реализованы либо в самой СЭД ФОИВ за счет интеграции со средствами, используемой в СЭД ФОИВ, системы управления базами данных, либо с иным программным приложением.
32. Для обеспечения резервного копирования и восстановления СЭД ФОИВ должна соответствовать следующим функциональным требованиям:
иметь автоматизированные процедуры резервного копирования и восстановления, позволяющие проводить регулярное полное или выборочное резервное копирование разделов (подразделов) классификационной схемы, электронных документов (электронных образов документов), метаданных, параметров администрирования и контрольной информации, а также, при необходимости, их восстановление;“
·         ПП 424 Об особенностях подключения федеральных государственных систем к информационно-телекоммуникационным сетям:
“а) операторы федеральных государственных информационных систем, созданных или используемых в целях реализации полномочий федеральных органов исполнительной власти … (далее – информационные системы общего пользования), при подключении информационных систем общего пользования к информационно-телекоммуникационным сетям, доступ к которым не ограничен определенным кругом лиц, обязаны обеспечить:
восстановление информации, измененной или уничтоженной вследствие несанкционированного доступа к ней, в течение не более 8 часов;”
·         Приказ Минкомсвязи N 104 Об утверждении Требований по обеспечению целостности, устойчивости функционирования и безопасности информационных систем общего пользования:
“2. Организационно-техническое обеспечение устойчивого и безопасного функционирования информационных систем общего пользования представляет собой совокупность мероприятий, направленных на поддержание:
2) устойчивости функционирования информационной системы общего пользования как ее способности сохранять свою целостность при отказе части компонентов системы, а также в условиях внутренних и внешних деструктивных информационных воздействий и возвращаться в исходное состояние;
4. Устойчивость функционирования информационной системы общего пользования обеспечивается:
1) разработкой мер при проектировании информационной системы общего пользования, направленных на выполнение требований к показателям надежности этой информационной системы общего пользования;
2) соблюдением условий эксплуатации, установленных в технической и эксплуатационной документации соответствующих технических и программных средств информационной системы общего пользования;
3) выполнением требований к информационной системе общего пользования в части технического обслуживания ее технических и программных средств;
4) выполнением требований к управлению информационной системой общего пользования в части контроля функционирования и анализа технических неисправностей в информационной системе общего пользования.”
·         Приказ ФСБ/ФСТЭК 416/489:
“11. В информационных системах общего пользования должны быть обеспечены:
поддержание целостности и доступности информации;
предупреждение возможных неблагоприятных последствий нарушения порядка доступа к информации;
возможность оперативного восстановления информации, модифицированной или уничтоженной вследствие неправомерных действий;”
·         Общие требования по обеспечению безопасности информации в КСИИ:
“Требования по обеспечению действий в непредвиденных ситуациях предъявляются:
-          к плану действий в непредвиденных ситуациях;
-          к обучению действиям в непредвиденных ситуациях;
-          по проверке плана действий в непредвиденных ситуациях;
-          по обновлению плана действий в непредвиденных ситуациях;
-          к местам резервного хранения носителей информации;
-          к резервным местам обработки информации;
-          к резервированию телекоммуникационных сервисов (услуг);
-          к резервному копированию информации;
-          по восстановлению ИУС.”
·         ПП 781 Положение об обеспечении безопасности персональных данных:
“11. При обработке персональных данных в информационной системе должно быть обеспечено:
г) возможность незамедлительного восстановления персональных данных, модифицированных или уничтоженных вследствие несанкционированного доступа к ним;”
Таким образом, при обеспечении непрерывности бизнеса и восстановления деятельности в части информационных систем обязательные требования надо учитывать:
·         Банкам;
·         Государственным органам и органам местного самоуправления;
·         КСИИ
·         Операторам персональных данных.

2.                  Если вы уже осознали необходимость обеспечения непрерывности то вам пригодятся  рекомендации и стандарты в РФ по обеспечению непрерывности, которые можно использовать при внедрении мероприятий:
·         СТО БР ИББС–1.0.      8.11. Требования к организации обеспечения непрерывности бизнеса и его восстановления после прерываний
·         ГОСТ Р ИСО/МЭК 27002.    14 Менеджмент непрерывности бизнеса.

Стандарт АРБ является наиболее свежим и подробный.  Именно ему был посвящен курс, проведенный 22-23 февраля компанией Микротест. “Стандарт АРБ. Обеспечение непрерывности бизнеса и восстановлениядеятельности для Банков в соответствии с требованиями ЦБ РФ”.  Автор курса: Алексей Бореалис, руководитель группы разработчиков стандарта АРБ.

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

среда, 15 февраля 2012 г.

СЗПДн. Проектирование. Сертифицированные СЗИ


Запрашивал у ведущих мировых производителей СЗИ планы по сертификации продукции в системе ФСТЭК России или ФСБ России. Делюсь с вами:
McAfee:
·          Сертифицирован McAfee Total Protection for Endpoint (антивирус McAfee VirusScan Enterprise, web-фильтрация McAfee SiteAdvisor Enterprise Plus, контроль приложений, персональный межсетевой экран, персональное средство обнаружения вторжений McAfee Host Intrusion Prevention и система управления McAfee ePolicy Orchestrator) на соответствие ТУ
·         Идет сертификация McAfee Total Protection for Endpoint (антивирус, контроль приложений, персональный межсетевой экран, персональное средство обнаружения вторжений и система управления) на соответствие НДВ по 4 классу защищенности
·         Идет сертификация McAfee DLP (средство защиты КИ от тучки) на соответствие ТУ и НДВ по 4 классу защищенности.

Trend Micro:
·         Сертифицирован комплекс средств защиты «Trend Micro Enterprise Security 10.0» включающий OfficeScan 10.0, ServerProtect, InterScan Messaging Security Virtual Appliance 7.0, ScanMail for Lotus Domino 5.0 Win, ScanMail for Microsoft Exchange 10.0, InterScan Web Security Virtual Appliance 5.0, Deep Security 7.0, Control Manager 5.0 –  на соответствие ТУ и на НДВ по 4 уровню контроля


Symantec:
·        Сертифицировано Symantec Data Loss Prevention (версия 10) - средство предотвращения несанкционированного копирования информации  на ТУ и по 4 уровню РД НДВ  (аналогично идет сертификация версии 11.1)
·        Сертифицировано Symantec Endpoint Protection (версия 11.0.5) - комплексное СЗИ (антивирус, персональный межсетевой экран, средство контроля приложений, средство контроля съемных носителей, средство обнаружения вторжений) на ТУ и по 4 уровню РД НДВ  (аналогично идет сертификация версии 12).
·        Сертифицировано Symantec Endpoint Protection Small Business Edition (версия 12) - комплексное средство защиты информации на ТУ
·        Сертифицировано средство почтовой фильтрации «Symantec Brightmail Gateway Virtual Edition  (версия 8.0.3)»  - на ТУ
·        Сертифицировано средство антивирусной защиты «Symantec Mail Security» для почтового сервера Lotus Domino версии 7.5 - на ТУ
·        Сертифицировано средство антивирусной защиты «Symantec Mail Security» для почтового сервера Microsoft Exchange версии 6.0.8 - на ТУ
·        Сертифицировано комплексное средство защиты «Symantec Critical System Protection Server Edition» (версия 5.2)  на платформе MS Windows 2003/XP - на ТУ (будут продолжать сертифицировать  новые версии)
·        Идет сертификация Control Compliance Suite (в том числе сканнера защищенности CCS VM) на ТУ.


Check Point:
·        Сертифицирован шлюз безопасности, сертифицированный ФСТЭК как МЭ 3-го класса (версия R65 HFA50)
·        Интегрирован шлюз безопасности с библиотекой КриптоПро (версия R65 HFA50), сертифицированной ФСБ по КС1, КС2   (IPSEC и SSL)
·        Идет сертификация шлюза безопасности как МЭ 3-го класса, антивирус и IPS (версия R71.20) и на отсутствие НДВ по 4 уровню
·        Идет интеграция шлюза безопасности (на платформе версии R71.20) IPSEC VPN  с библиотекой КриптоПро, сертифицированной ФСБ по КС1, КС2
·        Идет интеграция шлюза безопасности (на платформе версии R71.20) SSL VPN  с библиотекой КриптоПро, сертифицированной ФСБ по КС1, КС2
·        Идет сертификация шлюза безопасности в ФСБ по КС1, КС2
·        Идет сертификация Endpoint Security сначала без встроенного КриптоПро как персональный межсетевой экран. Затем сертифицироваться SSL VPN ГОСТ, который будет терминироваться на Mobile Access Blade шлюза безопасности.

Stonegate:
·        Сертифицировано StoneGate SSL - по 3 классу РД МЭ, РД НДВ - по 4  уровню контроля, соответствует ТУ
·        Сертифицировано система предотвращения вторжений с функцией межсетевого экрана Stonegate IPS - по 3 классу РД МЭ, РД НДВ - по 4  уровню контроля, соответствует ТУ
·        Сертифицировано межсетевой экран с функциями обнаружения вторжений, антивирусной защиты и фильтрации web-трафика StoneGate Firewall - по 2 классу для МЭ,  по 4  уровню контроля в соответствии с РД НДВ и требованиям ТУ. В том числе в сертифицированный комплекс входит StoneGate VPN Client
·        Идет сертификация StoneGate SSL как средства криптографической защиты трафика в ФСБ по КС1, КС2
·        Идет сертификация StoneGate Firewall как средства криптографической защиты трафика в ФСБ по КС1, КС2.
Все эти продукты сертифицируются силами производителя и заказчик платит только небольшую доплату за сертифицированный комплект документов и дистрибутив.
Собственно меня очень радует, что  для защиты персональных данных можно использовать фактически любые СЗИ, в том числе самые передовые и многофункциональные.
И мне совершенно непонятна жесткая критика текущего подходя регуляторов требующего использовать сертифицированные СЗИ. Стоимость Системы защиты персональных данных с использованием сертифицированных СЗИ увеличивается в среднем на 5%, но за это добавляется порядок и улучшается контроль.

среда, 8 февраля 2012 г.

Обучение. Вебинары ИБ 2

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

Особенно это актуально для региональных специалистов. Надеюсь кому-то будет полезным.

Если есть организации регулярно проводящие вебинары о которых я забыл, просьба напомнить.

вторник, 7 февраля 2012 г.

СЗПДн. Эксплуатация. Работы и услуги по технической защите ПДн



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

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

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

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


UPD:
Попробую подробнее рассмотреть какие задачи, связанные с СЗИ могут возникнуть после их ввода  в эксплуатацию и в каких случаях попадают под лицензирование:
·        Штатное использование штатных функций СЗИ – не подпадают
·        Штатная установка и настройка СЗИ (при замене АРМ, сервера) – подпадают
·        Штатная настройка СЗИ (при добавлении пользователя, администратора, при изменении IP-адресов) – не подпадают
·        Нештатные изменения СЗИ (при существенном изменении топологии сети используемых технологий) – подпадают, потому что по результатам нужны испытания, подтверждающие что СЗИ работает как надо
·        Штатное обновление СЗИ – не подподают
·        Существенное обновление СЗИ (при котором требуется переустанавливать СЗИ) – подпадают
·        Резервное копирование конфигурации и восстановление конфигурации СЗИ – не подпадают
·        Устранение неисправностей СЗИ (ремонт) – подпадают, но чаще всего вместе с СЗИ приобретается техническая поддержка от производителя или лицензиата, в таком случае - не подпадают 
·        Мониторинг работоспособности СЗИ, анализ журналов – не подпадают
Возможно это поможет определится что именно включать в договор с Лицензиатом по-минимуму.