четверг, 28 апреля 2011 г.

Лицензии от ФСТЭК России: глаза боятся руки делают!

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

Первый тип лицензии вызывает процессы активных обсуждений на различных форумах. Главное противостояние происходит вокруг термина "для собственных нужд" не буду развивать тему все можно почитать тут. Единственное, что хочу отметить - обсуждение и непонимание организациями необходимости владения лицензией ТЗКИ исходит из противоречивых ответов регулятора ФСТЭК России, в одном регионе он отвечает что надо лицензию, в другом регионе отвечает что не надо. Что делать в таком случае организации? Самый правильный выход из этой ситуации - официальный запрос в Ваше региональное отделение ФСТЭК Росссии. Далее ожидаете ответ и исходя из него решаете вопрос о получении/не получении лицензии на ТЗКИ.

Второй тип лицензии - для разработчиков софта. Процесс получения такой лицензии вообще не составляет какой-то сложности. Все, что нужно сделать это собрать все организационные документы (устав, ЕГРЮЛ......), документы подтверждающие право владения или аренды помещения, справка из бухгалтерии о том, что у вас на балансе есть ПК и софт, копии дипломов и сертификатов специалистов, заявление на получение лицензии, список нормативки, которой владеет организация из них пару тройку ДСП и ВПЕРЕД. По мне так ни чего сложного :), что там народ кричит про затраты!? Софт есть итак - ведь на чем-то разработчик уже разрабатывает софт. Аналогично с помещением, ПК и специалистами.

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

вторник, 26 апреля 2011 г.

Подготовительные работы к аттестации АС

Довольно часто задается один и тот же вопрос: "Какие подготовительные работы должен сделать заказчик перед проведением аттестацией объекта информатизации (ОИ)?". Я постораюсь ответить.
Со стороны заказчика объекта информатизации (ОИ) должны быть разработаны следующие организационно-распорядительные документы:
1. Приказ о создании комиссии для аттестации (лица, ответственные за организацию работ по аттестации ОИ на объекте).
2. Приказ о создании АС (состав и структура АС с указанием серийных/инвентарных номеров).
3. Акт ввода АС в эксплуатацию.
4. Перечень конфиденциальных ресурсов, обрабатываемых в АС.
5. Перечень лиц, допущенных к обработке конфиденциальной информации.
6. Матрица разграничения прав доступа (ролевая структура не пройдет :)).
7. Классификация АС, довольно часто 1Г.
8. Перечень программного обеспечения АС (список софта, с указанием номеров лицензий).
9. Уровень подготовки персонала в области ИБ (диплом, повышение квалификации, стаж работы).
10. Акт определения границ контролируемой зоны.
11. Описание технологического процесса обработки конфиденциальной информации (я бы сказал технология защиты, обрабатываемой информации).
12. Технический паспорт АС (форма есть в СТР-К, довольно сложный документ, так как прийдется рисовать все линии электросвязи, ЛВС, розетки, лампочки, проводку, отопление, вентиляцию....... :)).
13. Перечень помещений, в которых расположен ОИ (ОИ может состоять из нескольких ПК в разных комнатах).
14. Инструкция пользователю / администратору ИБ.
15. Инструкция по организации парольной / антивирусной защиты.
16. Инструкция по эксплуатации средств защиты.
17. Если СЗИ уже установлены, то должны быть акты ввода в эксплуатацию этих СЗИ (установить и настроить СЗИ могут только лицензиаты ФСТЭК).

Вот такой небольшой пакет документов надо подготовить заказчику, перед тем как запускать процесс аттестации АС. Можно не разрабатывать, а попросить аттестаторов разработать, но тогда готовьтесь раскошелиться ;).

четверг, 21 апреля 2011 г.

Обзор отраслевых рисков от LETA

Компания LETA запустила новый проект по обзору отраслевых рисков нарушения ИБ. Первый выпуск можно посмотреть тут. В водной части документа идет призыв на совместную доработку документов и необходимость конструктивной критики. Эту критику можно оставить в соответствующем посте, в блоге компании или по электронной почте. Ссылки на пост, электронку и сайт компании почему-то отсутствуют. Документ опубликован 29.03, а сегодня на дворе 21.04 :).
Писать на электронку особо нет желания, поэтому решил свои пожелания высказать в своем блоге.
В целом идея с проведением таких исследований, тем более имея накопленную статистику, является похвальной и полезной не только для начинающих специалистов в области ИБ, но и профессионалы своей отрасли могут почерпнуть новые для себя знания.
Если говорить про частности:
1. Риски нарушения целостности и доступности "Логистика"
Операция: Приемка товара, Перемещение товара.
Риски: Целостность: внутренне мошенничество (кража).
Не совсем понятно о краже чего идет речь - информации или товара? Думаю, что стоит уточнить. Ведь если мы украли информацию, то к нарушению целостности такое действие не приведет, скорее к нарушению конфиденциальности :).
2. Очень четко просматривается перемешка в принципе: Действие - Результат. 
Операция: Приемка товара, Перемещение товара.
Риски: Целостность: искажение учетной информации, расхождение и пересортица.
Действие: искажение учетной информации, Результат: нарушение целостности.
Действие: нарушение целостности, Результат: Расхождение и пересортица.
Целостность - это свойство актива, а не действие над ним. 

среда, 20 апреля 2011 г.

Как защищаются ПДн в образовании

На днях прочитал рекомендации Рособразования по защите ПДн и был приятно удивлен прочитанным.
Немного цитат и комментариев к ним:

Если затраты времени и средств на приведение информационных систем персональных данных (ИСПДн) в соответствие с предъявляемыми требованиями окажутся слишком высокими, то следует оценить возможность обезличивания или понижения классов информационных систем и провести необходимые работы повторно.

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

Наиболее эффективным способом приведению ИСПДн в соответствие с предъявляемыми требованиями является их обезличивание. Оно позволяет классифицировать ИСПДн по низшему классу К4 и самостоятельно определить необходимость и способы их защиты.

Это уже похоже на приказ о необходимости обезличивания ПДн ;).

Если система не может быть отнесена к типовой, модель угроз специальной информационной системы разрабатывается на основе ГОСТ Р 51275-2006 специалистами в области информационной безопасности.

Не совсем понятно из чего вытекает такое требование, но согласитесь, ход мыслей то правильный. Не в одних рекомендациях я ссылки на этот гост не видел, а следовательно Рособразованию еще один +.

+ 1 За способы понижения требований по защите ПДн и конкретные рекомендации к этим способам.

В итоге, сложилось положительное впечатление от прочтения. Документ выглядит лучше по сравнению со стандартами НПФР и Минздравсоцразвития, в части практического применения.  

Об аттестации объектов информатизации

Аттестация объектов информатизации (далее аттестация) является одним из видов "формального" аудита информационной безопасности. Хочу напомнить, что такой вид аудита является обязательным для государственных учреждений, обрабатывающих конфиденциальную информацию (СТР-К) и добровольным для всех остальных. Стоит ли добровольно проходить такую процедуру и что это за зверь "аттестация"?
Аттестация может проводиться для двух типов объекта информатизации (ОИ) - автоматизированная система и защищаемое помещение.

Как и любой другой вид аудита ИБ аттестацию можно представить в виде следующих этапов:
1. Анализ организационно распорядительных документов ОИ.
2. Проведение предварительных исследований.
2.1. Исследования на предмет утечки по техническим каналам.
2.2. Исследование на предмет утечки с помощью несанкционированного доступа (НСД).
3. Проведение контрольных испытаний (аналогично п. 2.)
4. Формирование отчетной документации.
5. Заветный "Аттестат соответствия" на три года.
6. Каждый год ожидать интегратора для плановой проверки.

Что должен сделать заказчик для успешной аттестации своих ОИ? В первую очередь заказчику необходимо подготовить организационно распорядительные документы (перечень и комментарии к документам приведу в следующем посте). Далее необходимо приобрести и установить технические средства защиты, в том числе и средства защиты от НСД. Дважды допустить на ОИ интегратора и ждать заветный "Аттестат соответствия".

А действительно ли "Аттестат соответствия" такой заветный? Все положительные эмоции пропадают, когда бросается в глаза абзац типа: "Аттестат соответствия выдан ........., в течении которых должна быть обеспечена неизменность условий функционирования АС и технологии обработки защищаемой информации, которые могут повлиять на характеристики". Естественно, сразу начинаешь искать глазами "характеристики" и находишь: изменение состава объекта информатизации, изменение условий эксплуатации АС и средств защиты.
Если по сути то, заменяя монитор, клавиатуру, мышь, оперативную память, блок питания..... - нужно уведомлять интегратора, который приходит с доп. проверкой. Перенести ПК, даже в пределах одного кабинета, запрещается. Установили телефон, радиоточку и т.д. - сообщите интегратору. Установили новое программное обеспечение - сообщите интегратору. Все эти изменения вносятся и в организационно-распорядительные документы. Как Вы понимаете это финансовые и временные затраты.

Имея опыт работы с аттестованными АС могу сказать, что решать бизнес-задачи на таких АС крайне тяжело. Нужна вам такая "добровольная аттестация"? Решайте сами. 


четверг, 14 апреля 2011 г.

Работы по защите ПДн (часть 5)

Возвращаясь к вопросу о проведении работ по защите ПДн, остановлюсь на втором этапе - проектирование СЗПДн.
Как я уже говорил: "не надо бросаться и изучать ГОСТы РФ". И это действительно так. Вполне достаточно аналитического обоснования, но перед тем как его сформировать, нужно плотно поработать с моделью актуальных угроз и существующими на рынке средствами защиты информации (СЗИ).
Процесс определения СЗИ для перекрытия актуальных угроз является не таким простым, как кажется на первый взгляд, за исключением тех случаев, когда Ваш бюджет на ИБ не ограничен ;).
Самая первая сложность возникает в выборе СЗИ из всего огромного выбора таких средств на рынке. Ведь стоимость СЗИ и их функционал примерно одинаковы. Как же быть в этом случае?! Я предлагаю использовать два критерия при выборе таких средств (естественно, что их гораздо больше): 1. Совокупная стоимость владения СЗИ и 2. Удобство работы. Второй критерий не люблю использовать, но в данном случае он подходит как ни что лучше.
Совокупная стоимость владения СЗИ - это не только стоимость самого комплекта СЗИ (ПО, железо), но и стоимость внедрения (новые технические средства по ПО, модернизация технических средств под ПО, изменение инфраструктуры), стоимость поддержки СЗИ (зп нового специалиста, повышение квалификации "старого" специалиста, техническая поддержка СЗИ производителем, стоимость обновлений). Дополнительная нагрузка по администрированию новой СЗИ на "старого" специалиста может привести к тому, что он станет меньше времени уделять другим вопросам ИБ, например, уменьшится контроль за действием пользователей в сети интернет и/или электронной почты. К чему я виду, есть такое понятие "упущенная выгода", которое можно применить к данной ситуации и стоимость "упущенной выгоды" включить в совокупную стоимость владения СЗИ.
Удобство администрирования и работы. Не буду философствовать, а приведу простой, и на мой взгляд, яркий пример. Есть сертифицированная по требованиям безопасности ОС и есть сертифицированное прикладное ПО. Администратор ИБ ведет работы по разграничению прав доступа, по мониторингу действий средствами ОС. Возникает вопрос: "Если стоимость владения сертифицированной ОС и сертифицированным прикладным ПО одинакова, какой выбор лучше?". На мой взгляд лучше выбрать вариант сертифицированной ОС так как все функции зашиты в ней известны и человек с ней уже работал, следовательно ему не придется разбираться с механизмами обеспечения ИБ и он сможет довольно оперативно их настроить. В случае выбора сертифицированного прикладного ПО надо учитывать тот факт, что эта "нахлобучка" будет утяжелять работу системы и потребует дополнительных навыков, времени и обучения специалиста для настройки корректной работы.
По критериям все. Теперь поговорим о том, что должно содержать аналитическое обоснование СЗПДн. В первую очередь обосновывается выбор конкретного средства СЗИ из всего множества. Основным аргументом для топ-менеджмента будет стоимость владения такого СЗИ. Первый критерий Вам в помощь. Далее необходимо нарисовать топологию ИСПДн и определить какие компоненты СЗПДн и где должны быть установлены. В заключении необходимо прописать какие функции СЗПДн должны быть сконфигурированы. Не надо настраивать СЗПДн на избыточное функционирование, помните, у Вас есть актуальные угрозы и вы должны снизить риск их возникновения.
В итоге у Вас должен получиться документ размером 10-15 стр. который будет понятен и топ-менеджменту и директору ИТ и директору ИБ. 

среда, 13 апреля 2011 г.

Как оценить уровень интегратора или кому доверить работу по защите информации!?

Проблема выбора интегратора действительно существует и является актуальной в условиях жесткой конкуренции и в порыве компаний заработать "халявных денег" на предоставлении услуг в области защиты ПДн.
Возвращаясь к томуже проекту документа "Концепция аудита ИБ.......", заострил свое внимание на пункте 7 Требование к кадровому обеспечению аудиторской деятельности. Изучив данный пункт каждая организация может составить своего рода план оценки интегратора.
Процесс оценки включает в себя следующие этапы:
1. Оценка личных качеств и знаний группы специалистов участвующих в проекте по защите информации ограниченного доступа (именно специалистов "участвующих", а не специалистов работающих в организации.).
2. Определить критерии оценки.
3. Выбор метода оценки.
4. Проведение оценки.
Этап на которые стоит обратить пристальное внимание - это определение критериев оценки.
К таким критериям в документе определяют:
- наличие базового образования;
- наличие практического опыта;
- наличие специального образования (курсы повышения квалификации, переподготовки, сертификации, аккредитации и т.д.);
- знание российских и международных нормативно-правовых актов;
- свободное владение деловым русским языком (важный аспект, так как разрабатываемые документы интегратором должны содержать стилистически и орфографически грамотные обороты, которые понятны всем, а не только человеку который их написал).
Применительно к организации, а не ее специалистам, я бы ввел еще такой критерий, как количество успешно выполненных проектов, аналогичных Вашему.
Наличие базового образования - высшего технического образования по направлению ИТ, ИБ.
Наличие практического опыта - опыт в проведение и участии в проектах, подобному Вашему, желательно, чтобы опыт имел нижнюю планку - 3года.
Знание российской и международной нормативки - как бы хорошо человек не знал российскую нормативку это не поможет ему провести, например аудит по стандарту Cobit или ISO 2700x.

В целом, п.7 "Концепции аудита....." я отнесу к полезной информации, которая может помочь многим специалистам и организациям в процессе выбора интегратора по ИБ.  

понедельник, 11 апреля 2011 г.

Есть такой проект "концепция аудита.." от ФСТЭК

Лежит у меня "Концепция аудита информационной безопасности систем информационных технологий и организаций" довольно давно и все как-то руки до нее не доходили. И вот эврика. Решил посмотреть не перешел ли документ в рабочий или возможно в редакцию 1, 2...... Зашел на сайт ФСТЭК России и не нашел его. Потом в новостях увидел, что его удалили с сайта 10 марта 2010г. и расстроился. Но желание прочитать его осталось.
Что я о нем знаю? Разработчик - ООО НПФ "Кристалл"; Дата создания 14.10.2004г. Документ не слишком свежий и поэтому есть как утопические мысли, так и довольно позитивные.
К разделу утопических я бы отнес:
1. Аккредитацию и лицензирование деятельности по аудиту ИБ, имея опыт по работе с аттестацией и лицензированием ТЗКИ :).
2. Сертификацию инструментальных средств поддержки аудита ИБ. Смысл сертифицировать такие средства если по своей сути они представляют экспертную систему с вариантами ответов на вопрос да, нет, "не уверен".
3. Мысль об отсутствие "национальных регуляторов", которое может нанести вред. Не судите строго, но бытует мнение, что на данный момент как раз беды от регуляторов и идут :).
4. Формирование критериев аудита на основании СТР-К и РД. Выходя на новый уровень, лучше сразу переходить к лучшим практикам, а не тянуть за собой обоз с прошлым.
5. ФСТЭК России должны разработать нормативно методическую документацию процедурного плана по аудиту ИБ. С каким бы уважением к представителям ФСТЭК я бы не относился, но на данном этапе развития такая задача им не по силам. Быстрее сформируют такие подходы отраслевые регуляторы, например Банк России, НПФР, Здравооохранение и т.д...

То, что смог увидеть при беглом просмотре. Далее сделаю более детальный обзор.

вторник, 5 апреля 2011 г.

Работы по защите ПДн (часть 4)

Перед тем как приступить к проектированию СЗПДн, я бы рекомендовал специалистам ИТ/ИБ разработать два документа: Политика информационной безопасности (ИБ) и Политика обеспечения безопасности ПДн. Ведь эти документы являются высокоуровневыми и являются основным фундаментом (если хотите, то задают вектор) для построения системы защиты организации.  Почему два документа, а не один? Тут как говорится: "на вкус и цвет - фломастеры разные". Привычка заставляет писать небольшие документы, но для каждого процесса. Ссылаясь на свой опыт, могу сказать, что документы размером 15-20 страниц получаются "реально рабочими" (15-20 для политик :), инструкции 3-5).

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

Политика обеспечения безопасности ПДн - структуру документа вы можете найти пошарив в интернете. Этот документ детализирует требования политики ИБ до уровня конкретных ИСПДн. В этом документе прописываются основные требования по обеспечению и управлению безопасностью ПДн, в "конкретных" ИСПДн. Например, в политике ИБ -  действия пользователей в информационной системе должны журналроваться (протоколироваться), в политике обеспечения безопасности ИСПДн - журнал действий пользователей в ИСПДн класса 3 должен содержать следующие параметры: логин, дата и время входа/выхода из ИСПДн; в ИСПДн класса 2 - ............ (в случае если у вас в организации ИСПДн разного класса).

Думаю, что нужно подвести итог. Так для чего же нужны эти два документа? Так как требования к СЗПДн определяются на основании актуальной модели угроз и требований приказа № 58 ФСТЭК, а в некоторых организациях добавляются требования международных стандартов ISO 27001, ISO 27002, ISO 17799? то необходимо их свести в один/два документа, и политики подходят для решения такой задачи как ни что лучше.

понедельник, 4 апреля 2011 г.

Работы по защите ПДн (часть 3)

Основные виды работ по приведению ИСПДн в соответствие с "требованиями регуляторов" привел в части 1 и 2. Перед тем как перейти к описанию этапов проектирование и внедрение СЗПДн. Хочу привести перечень документов, который должен появится до и после результата обследования ИСПДн.
В качестве стартовых документов должны появится три документа:
1. Приказ о назначении комиссии по приведению ИСПДн в соответствие с "требованиями регуляторов".
2. Приказ о назначении ответственного за обеспечение безопасности ПДн в ИСПДн.
3. План работ по приведению ИСПДн в соответствии с "требованиями регуляторов".
Эта тройка документов устанавливает четкое понимание: "кто,  за что отвечает и с кем должен взаимодействовать". 
По результатам обследования ИСПДн должны появиться следующие документы:
1. Список ПДн, обрабатываемых в информационных системах (ИС).
2. Перечень ИС, относящихся к ИСПДн.
3. Перечень сотрудников, имеющих доступ к БД ИСПДн.
4. Кому-то надо, кому-то нет - Акт определения границ контролируемой зоны.
5. Описание технологического процесса обработки ПДн (может быть оформлен книжным вариантом, может быть отдельный документ для каждой ИСПДн). 
6. Акт классификации ИСПДн.
7. Модель актуальных угроз ИБ - этот документ является конечным и содержит только актуальные угрозы, а не весь алгоритм определения таких угроз ;). 

Перед тем, как проектировать СЗПДн, я бы выпустил еще несколько документов, но об этом в "части 4" :).    

пятница, 1 апреля 2011 г.

Работы по защите ПДн (часть 2)

Что же в себя включает этап Обследования ИСПДн? Для меня - основополагающий этап в процессе построения системы защиты информации (СЗИ) и не важно, к какому типу информации ограниченного доступа она относится.

На этапе Обследования ИСПДн специалистам ИБ/ИТ необходимо выполнить следующие работы:
1. Выделить все ИСПДн, входящие в состав информационной системы (ИС) организации.
2. Определить, автоматизированная или неавтоматизированная обработка ПДн ведется в ИСПДн.
3. Классифицировать все системы, которые осуществляют автоматизированную обработку ПДн.
4. Из общего числа ИСПДн выделить, те, которые относятся к различным системам электронной отчетности и платежей (например СБиС++, ТаксКом, Клиент-банк, Интернет-Банк, Контур.........). Далее эти ИСПДн в процессе не участвуют, так как способы и методы защиты ПДн должны определяться разработчиком в инструкциях на использование таких систем.
5. Построить топологию каждой ИСПДн (сервера, АРМ, телекоммуникационное оборудование).
6. Описать технологию обработки ПДн в ИСПДн. (Указать, какие ПДн на входе и как они хранятся, передаются, корректируются в ИСПДн, а так же перечень сотрудников, учавствующих в процессе их обработки).
7. Описать все средства защиты, которые уже используются, в том числе и средства физической защиты.
8. Провести инвентаризацию документов, направленных на обеспечение информационной безопасности. (Не обязательно, конкретно защиты ПДн, это могут быть документы по конфиденциалке).
9. Провести классификацию источников угроз ИБ и определить актуальные источники для каждой конкретной ИСПДн.
10. Провести классификацию угроз ИБ и построить матрицу (таблицу) позиционирования (соответствия) угроз ИБ и источников угроз ИБ.
11. Оценить актуальные угрозы для каждой конкретной ИСПДн, для каждого конкретного источника угроз.
12. Кому-то надо, а кому-то - нет. Определить границы контролируемой зоны, т.е. зоны где исключено не контролируемое пребывание людей.