Жалобы

Как получить электронную подпись в удостоверяющем центре. Создание удостоверяющих центров Бизнес план аккредитованный удостоверяющий центр

Когда работал системным администратором, возникла у меня необходимость реализовать VPN на несколько десятков филиалов компании, интранет и почту на серверах в Москве с суровой защитой и доступом через VPN вообще отовсюду. При этом придумать всю систему и организовать её развёртывание предстояло в одно лицо. Бюджет был в тысячи полторы долларов, было это 4 года назад, некоторое время честно пытался найти более-менее приемлемое по цене ПО, потом нечестно пытался найти что-то на торрентах – пусто. В итоге – OpenSSL и OpenVPN. В этом вводном тексте хотелось бы поговорить об OpenSSL.

В конечном итоге были развёрнуты:

центр выдачи сертификатов (CA – Certificate Authority, он-же УЦ – Удостоверяющий Центр, в отечественной терминологии организация, уполномоченная выпускать сертификаты),
интранет-сайт с авторизацией доступа по клиентским сертификатам,
VPN с взаимной аутентификацией серверов, клиентов и динамической маршрутизацией,
Авторизация клиентов на корпоративном IM сервере с помощью тех-же сертификатов.

Судя по всему, к настоящему моменту система умерла… не знаю, как долго она продержалась после моего увольнения, скорее всего до момента истечения корневого сертификата (т.е. 2 года от момента запуска).

Описанное далее будет интересно скорее корпоративным технарям, нежели обычным пользователям. При условии, если: организация не государственная, есть цель сэкономить, есть желание попробовать некоторые «штуки» не вбухивая в R&D сумму с шестью нолями.

Предполагается, что читающие знакомы с понятиями VPN (в данном случае Virtual Private Network) и SSL (Secure Sockets Layer) и тем, что из себя представляют электронные сертификаты в формате x.509 .

СА

В полученной системе сертификаты можно было обновлять, отзывать, использовать для аутентификации, шифрования кода, файлов, почты, а в случае компрометации отозвать ветку, не убивая весь CA. Для этого пришлось очень внимательно отнестись к файлам настройки OpenSSL, построить процедуру генерации списка отозванных сертификатов (CRL – Certificate Revocation List) и корректную иерархию в CA. Только тогда выбранная реализация позволяла использовать сертификаты, в т.ч. и в автоматических процессах, где некому было нажимать кнопку «Да, я всё равно доверяю этому сертификату, хотя он и просрочен и выпущен неправильно и вообще не для этого предназначен ».

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

Сайт

Для интранет-сайта (первый эшелон – Apache, что там за ним было – не суть важно ) была реализована многофакторная аутентификация. Обычно первым и единственным фактором при аутентификации выступает знание логина и пароля или логина и пин-кода; представляется серверу только клиент, а серверу не нужно доказывать что он - это он, отсюда возможность воровства логина/пароля и/или подмены сервера. В моём случае это было неприемлемо, поэтому к знанию логина/пароля добавилась необходимость иметь сертификат. Выгружались сертификаты из CA в формате PKCS12 (PFX) с паролем.

В конфиг сервера было добавлено что-то вроде:

SSLVerifyClient require
SSLVerifyDepth 2
SSLRequire %{SSL_CLIENT_I_DN_CN} in {"My LTD OpenSSL CA"}

Т.е. разрешить всем, чей сертификат выдан My LTD OpenSSL CA (в реальности, конечно, название другое )

Также можно ограничить доступ по именам:

SSLOptions +FakeBasicAuth +StdEnvVars
SSLVerifyClient require
SSLVerifyDepth 2
SSLRequire %{SSL_CLIENT_S_DN_CN} in {"Ivan A Ivanov", \
"Petr B Petrov"}

В логи сервера пишется с помощью вот такой вот конструкции:

CustomLog ../logs/ssl/ssl_request.log \
"\"%t\",\"%h\",\"%{SSL_CLIENT_S_DN_CN}x\",\"%r\",\"%s\"" env=!dontlogit

Распространение сертификатов

Полученный сертификат вместе с ключами устанавливали на компьютере пользователя (в реестр, зашифрованным на пин-коде ), очень частый случай, при этом пользоваться сертификатом можно только на этом компьютере и в случае переустановки операционной системы сертификат, чаще всего, необходимо получать заново, если конечно закрытый ключ генерировался на компьютере, а не выдан вам на дискете при посещении УЦ, что можно считать профанацией с особым цинизмом, ведь по факту владельцами вашего якобы закрытого ключа становится (с возможностью проставлять за вас «электронную подпись» ) также и УЦ, а при определённом уровне разгильдяйства - все сменяющие друг друга админы в УЦ. Зато у УЦ появляется возможность предоставлять сервис по «восстановлению» сертификата.

Т.к. я был сам себе УЦ, то был избавлен и от такого «сервиса» и от копирования сертификатов «на память» техническими специалистами (и не очень).

Разъездным сотрудникам сертификаты выдавались на аппаратном носителе – USB-ключе Aladdin. Банки и УЦ предлагали (и предлагают) юридическим лицам для этой цели использовать дискеты или современный вариант - флешки. Это более удобно, но приводит к другой опасности - возможности сделать дубликат. В идеальном случае ключи и сертификаты должны храниться на смарт-карте, которая дополнительно защищена pin-кодом, имеет собственный крипто-процессор на борту, генератор случайных чисел, который, как считается, сильно понижает шансы потенциальных взломщиков, буде те решаться подобрать ваш ключ. Кроме того, смарт-карты практически не поддаются копированию.
USB-ключи Aladdin eToken как раз и являются такими картами, только в виде USB-брелка.
В случае аутентификации шифруется лишь небольшой объём данных, необходимый для процедуры, но при желании можно шифровать и весь трафик между клиентом и сервером. В случае, если сертификат нужно использовать для шифрования на сервере с большим количеством клиентов, в сервер нужно ставить уже что-то посерьёзнее например, крипто-плату, бесплатный IBM HTTP Server (тот-же Apache, фактически ), даже какое-то их количество поддерживает.
Никто конечно не мешает использовать смарт-карты, которые выглядят как обычные пластиковые карты, но тогда на каждом рабочем месте, на котором такую карту нужно будет использовать, должен стоять картридер.

После того, как мы получили у УЦ сертификат, поместили его на «токен», и закрыли токен пин-кодом, мы получаем возможность выполнить двухфакторную двустороннюю аутентификацию. Фактор первый - мы имеем токен, фактор второй - знаем от него пин-код. А имея сертификат можем выполнить проверку, что сервер действительно тот, за кого себя выдаёт, в этом случае bobik.ru и bоbik.ru уже спутать не получится, потому, что русская «о» во втором варианте даст несовпадение имени (для компьютера это всё-таки разные буквы ).

Списки отозванных сертификатов

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

Многие отечественные CA местоположение CRL указывают, а выкладывать или обновлять сам список «забывают», и когда, скажем, тот-же Outlook не может проверить сертификат по списку отозванных и вывешивает предупреждение, консультант в CA по телефону может предложить вам это предупреждение проигнорировать. В случае, если клиентом является другой сервер, при невозможности проверки сертификата, он просто будет разрывать подключение.

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

Доводка OpenSSL

В общем всем понятно, что сертификат – штука хорошая, осталось правильно его выпустить. После довольно продолжительной обкатки и изучения «документации» в несколько сотен страниц (на самом деле это был учебник по PKI и криптографии от «Интуита» ) выяснилось, что имеющиеся в инете на тот момент примеры конфигурации OpenSSL пригодны только для целей «на поиграться», я некоторое время сталкивался с тем, что выпущенные мной сертификаты то не работали в Outlook, то в Thunderbird, то в Firefox. Самым всеядным оказался IE.

Чтобы всё было чуть серьёзнее нужна небольшая рихтовка:

если вы хотите, чтобы ваша система прожила больше года, перед выпуском корневого сертификата CA увеличьте количество дней до 3650, потом верните обратно, для пользовательских сертификатов лучше оставить год или полгода
в секции [ CA_default ]
выставить параметр unique_subject в «yes» - это не позволит вам выпустить 2 идентичных сертификата
в секции [ user_cert ]
добавить
ExtendedKeyUsage = clientAuth
секция для серверов может выглядеть так
[ server_cert ]
basicConstraints = CA:FALSE
nsCertType = server
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = nsSGC, serverAuth
в секции [ v3_ca]
изменить
basicConstraints = CA:TRUE, pathlen:5
раскомментировать nsCertType и keyUsage
добавить
extendedKeyUsage = serverAuth, clientAuth

Как водится – готовый конфиг .

Автоматизация выпуска сертификатов

Следующим шагом наколенной автоматизации может являться написание интерфейса для просмотра списка сертификатов. Список имеет имя index.txt, понятный формат и я написал под него интерфейс на HTA. Для упрощения отладки HTA вызывал батники для отдельных процедур. Необходимый набор следующий:

отдельно вынесен файл настройки переменных окружения
выпуск произвольного сертификата – минимум настроек, задаёт кучу вопросов, позволяет выпустить сертификат, скажем, для партнёров, потом подписать в нашем CA
выпуск корневого сертификата CA – вызывается один раз или несколько раз, если строится дерево, ручками
выпуск сертификата сервера – понятная штука, openssl вызывается с параметром -extensions server_cert, а в конфиге в секции должны быть нужные параметры, ещё одно отличие – не упаковывается в PFX и создаёт распакованные версии ключей, может понадобится некоторым серверам
выпуск сертификата пользователя
отзыв сертификата – интересный процесс: из архива (надо делать самому) выданных сертификатов извлекался нужный (по имени, но можно и по серийному номеру), потом по нему уже выполнялся отзыв
обновление сертификата пользователя – сначала выполнялся отзыв старого сертификата (батником №6), потом создание нового сертификата (батником №5) для старого ключа
обновление списка отозванных сертификатов – простая команда, но в моём случае сопровождалась запуском скрипта на Perl, который препарировал полученный список и помещал его в директорию (адресную книгу, как её ещё иногда называют ) Lotus Domino, оттуда его было проще доставать (через LDAP, что является практически стандартным способом дистрибуции CRL)

Вот и весь инструментарий, пожалуй. Приятного внедрения.

Любая крупная компания имеет достаточно большой оборот документов. Сейчас прошли времена, когда все бумаги складировались на года в складах. В настоящее время вся документация отформатирована и хранится в основном в электронной версии. Это значительно экономит пространство в крупных предприятиях, но дарит свои риски. К примеру, вероятность подделки. Поэтому, большинство предприятий, чтобы защитить свои данные используют электронную подпись. Она приобретается в удостоверяющих центрах (центр сертификации).

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

В своей работе можно выбрать два направления для действий:

Первый вариант - это открытие центра для работы партнеров по бизнесу. Тогда можно будет объединиться для безопасной работы.

Второй случай подразумевает работу для сторонних предприятий, которым необходима электронная подпись.

Открытие офиса.

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

Обращение через посредников или посредством современных коммуникаций невозможно согласно законодательной базе. Размер помещения должен соответствовать количеству работников. В среднем площадь должна быть около 100 метров квадратных. Отдельно стоит предусмотреть расположение технического помещения для размещения оборудования.

Арендная плата за выбранную площадь будет начинаться от 1,7 тыс. $ в месяц. Чаще всего требуется авансовый платеж за аренду.

Персонал.

В качестве руководящего звена необходимо нанять на работу человека с высшим профессиональным образованием по профилю «Информационная безопасность». Также важно, чтобы руководитель прошел переподготовку по одной из специальностей данного профиля. В зависимости от перечня предлагаемых услуг стаж работы такого специалиста будет составлять не менее 3-5 лет.

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

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

Зарплата штата работников, состоящая из 6 человек будет составлять не менее 4,5 тыс. $.

Инвестиции в технику и программное обеспечение.

Для работы в отрасли создания удостоверяющего центра и центра сертификации необходимо вложить средства в такие ресурсы:

1. Вычислительные устройства - от 12 тыс. $;
2. Программа с базой данных - от 5 тыс. $;
3. Компьютеры - от 3,5 тыс. $;
4. Сервер - от 2 тыс. $;
5. Программа безопасности - от 500 $;
6. МФУ - от 1,5 тыс. $.

Минимальное количество денежных средств на создание технической базы будет составлять около 25 тыс. $.

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

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

Основные траты.

Бизнес по созданию удостоверяющего центра и центра сертификации будет состоять из таких вложений:

1. Аренда помещения - от 1,7 тыс. $;
2. Техника и программы - от 25 тыс. $;
3. Персонал - от 4,5 тыс. $;
4. Реклама - от 1 тыс. $;
5. Вложения в разрешительную документацию - от 4 тыс. $.

Стартовым капиталом для начала деятельности в данной отрасли будет сумма в 36 тыс. $.

Прибыль и период для окупаемости.

Выдача электронной подписи - не слишком дорогостоящая услуга. Компания сама устанавливает цену на свои работы, опираясь на конкурентную среду. В среднем, для частного лица электронная подпись будет стоить около 150 $. Организации смогут воспользоваться подобной услугой за сумму, начинающую от 500 $. Для держания на плаву необходимо в месяц выдавать не менее 110 подписей.

Штат сотрудников в количестве 6 человек сможет поднять ежемесячную прибыль в 3,5 тыс. $. В данном случае окупаемость произойдет за 9-12 месяцев.

Клиенты и варианты для развития.

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

Читайте так же:

Что необходимо для создания и дальнейшей эксплуатации собственного УЦ (удостоверяющего центра) в компании? И в каких случаях вообще рекомендуется создавать именно свой, а не пользоваться услугами стороннего УЦ?

Ответ

Как правило, собственный удостоверяющий центр (далее - УЦ) в компании создается с целью обеспечения внутреннего юридически значимого документооборота. Для этого необходимо:

1. Собственно развернуть УЦ. Это вы можете сделать, например, на базе службы Microsoft Windows.

2. Сформировать и выпустить пакет документов, регламентирующих использование электронной подписи в компании. В первую очередь, это:

приказ об использовании электронной подписи;
приказ о назначении ответственного сотрудника или подразделения за использование электронной подписи в компании;
положение об электронной подписи;
регламент использования электронной подписи.

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

Подробно все это описано в Федеральном законе от 06.04.2011 № 63 «Об электронной подписи».

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

Во исполнение статьи 16 Федерального закона №63 «Об электронной подписи» Минкомсвязь России, как федеральный орган исполнительной власти, уполномоченный в сфере использования электронной подписи, осуществляет аккредитацию удостоверяющих центров.

Формы документов, необходимых для получения государственной услуги

В целях единообразного применения положений Федерального закона от 6 апреля 2011 г. № 63-ФЗ (далее - ФЗ № 63-ФЗ) Минкомсвязь России сообщает следующее:

В соответствии с пунктом 2 части 3 статьи 16 ФЗ № 63-ФЗ обеспечение ответственности за убытки, причиненные третьим лицам вследствие их доверия к информации, указанной в сертификате ключа проверки электронной подписи, выданном таким удостоверяющим центром, или информации, содержащейся в реестре сертификатов, который ведет такой удостоверяющий центр, в сумме не менее 30 миллионов рублей и 500 тысяч рублей за каждое место осуществления лицензируемого вида деятельности, указанное в лицензии федерального органа исполнительной власти в области обеспечения безопасности, выданной удостоверяющему центру в соответствии с пунктом 1 части 1 статьи 12 Федерального закона от 4 мая 2011 года № 99-ФЗ «О лицензировании отдельных видов деятельности», если количество таких мест превышает десять, но не более 100 миллионов рублей. Если количество мест осуществления указанного лицензируемого вида деятельности не превышает десять, финансовое обеспечение ответственности составляет 30 миллионов рублей, может подтверждаться следующими документами:

Договор страхования ответственности

В случае предоставления договора страхования он оформляется в соответствии с требованиями законодательства Российской Федерации. Страховым случаем по договору страхования, в соответствии с подпунктом 2 части 3 статьи 16 Федерального закона от 6 апреля 2011 г. № 63-ФЗ «Об электронной подписи» и подпунктом 9.1.1 пункта 2 приказа Министерства связи и массовых коммуникаций Российской Федерации от 30 ноября 2015 г. № 486 «Об утверждении административных регламентов предоставления Министерством связи и массовых коммуникаций Российской Федерации государственной услуги по аккредитации удостоверяющих центров и исполнения Министерством связи и массовых коммуникаций Российской Федерации государственной функции осуществлению государственного контроля и надзора за соблюдением аккредитованными удостоверяющими центрами требований, которые установлены Федеральным законом «Об электронной подписи» и на соответствие которым эти удостоверяющие центры были аккредитован», является факт наступления ответственности за убытки, причиненные третьим лицам вследствие их доверия к информации, указанной в сертификате ключа проверки электронной подписи, выданном таким удостоверяющим центром (страхователем), или информации, содержащейся в реестре сертификатов, который ведет такой удостоверяющий центр (страхователь).

В соответствии с частью 2 статьи 15 Гражданского кодекса Российской Федерации под убытками понимаются расходы, которые лицо, чье право нарушено, произвело или должно будет произвести для восстановления нарушенного права, утрата или повреждение его имущества (реальный ущерб), а также неполученные доходы, которые это лицо получило бы при обычных условиях гражданского оборота, если бы его право не было нарушено (упущенная выгода). Страховая сумма, при указанном страховом случае должна составлять не менее 30 миллионов рублей и 500 тысяч рублей за каждое место осуществления лицензируемого вида деятельности, указанное в лицензии федерального органа исполнительной власти в области обеспечения безопасности, если количество таких мест превышает десять, но не более 100 миллионов рублей. При заключении договора страхования рекомендуем прикладывать документы, подтверждающие уплату страховой премии в соответствии с договором страхования.

Банковская гарантия

В соответствии с положениями Гражданского кодекса Российской Федерации банковская гарантия может быть выдана банком, кредитным учреждением или страховой организацией. Банковская гарантия предоставляется в письменной форме с приложением указанных в гарантии документов. Бенефициаром по банковской гарантии, в соответствии с подпунктом 2 части 3 статьи 16 Федерального закона от 6 апреля 2011 г. №63-ФЗ «Об электронной подписи» и подпунктом 9.1.1 пункта 2 приказа Министерства связи и массовых коммуникаций Российской Федерации от 30 ноября 2015 г. № 486 «Об утверждении административных регламентов предоставления Министерством связи и массовых коммуникаций Российской Федерации государственной услуги по аккредитации удостоверяющих центров и исполнения Министерством связи и массовых коммуникаций Российской Федерации государственной функции осуществлению государственного контроля и надзора за соблюдением аккредитованными удостоверяющими центрами требований, которые установлены Федеральным законом «Об электронной подписи» и на соответствие которым эти удостоверяющие центры были аккредитован», являются третьи лица, которым причинены убытки вследствие их доверия к информации, указанной в сертификате ключа проверки электронной подписи, выданном таким удостоверяющим центром (принципалом), или информации, содержащейся в реестре сертификатов, который ведет такой удостоверяющий центр (принципал). Денежная сумма, указанная в банковской гарантии должна составлять не менее 30 миллионов рублей и 500 тысяч рублей за каждое место осуществления лицензируемого вида деятельности, указанное в лицензии федерального органа исполнительной власти в области обеспечения безопасности, если количество таких мест превышает десять, но не более 100 миллионов рублей.

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

В конференции "FinSec: безопасность финансовых организаций" 19 ноября в КВЦ "Сокольники" , из них более 100 - представители потребителей.

Участвовали руководители управлений ИТ, информационной и экономической безопасности, анализа финансовых рынков, специалисты отделов по сопровождению программ по защите информации, автоматизации и программирования, информационно-технологических департаментов таких финансовых организаций, как Банк России, Россельхозбанк, ВТБ24, БТА Банк, ФБ Инноваций и развития, Росбанк, HSBS, Банк Интеза, Центральный коммерческий банк, ЭКСПРЕСС-ТУЛ", ПРБ, ГУТА-Страхование, ЖАСО, УРАЛсиб, Ренессанс-Капитал и многие другие, а также представители, НПФ "Социум", Специализированного депозитария "ИНФИНИТУМ", ОДК, Агентства по ипотечному жилищному кредитованию, Национального бюро кредитных историй, банковских и страховых ассоциаций, Росфиннадзора, региональных администраций, руководители экономической и информационной безопасности ВНИИ, ФСИН, медицинских, транспортных, гостиничных компаний, руководители и сотрудники консалтинговых компаний, операторов, системных интеграторов, и производителей услуг в сфере ИБ.
Открыл конференцию директор по развитию бизнеса компании "Гротек" Александр Власов, вел конференцию Председатель Совета Ассоциации защиты информации Геннадий Емельянов.
С докладами на конференции выступили: Андрей Дроздов (Совет Сообщества ABISS) и Екатерина Лавринова (Россельхозбанк) - на брифинге "Стандарт Банка России. Опыт внедрения"; Ирина Геннадьевна Алехина (НП "Национальная страховая гильдия") , Роман Кобцев и Олег Беззубцев (ЭЛВИС-ПЛЮС) - на семинаре "Услуги по подготовке к прохождению проверок и аудитам в области ИБ"; Илья Сачков и Александр Писемский (Group-IB) , а также Александр Иванов (Управление "К" МВД РФ) и Константин Кузнецов (ГУВД по г. Москве, Криминальная милиция, отдел "К") - на семинаре "Расследование инцидентов информационной безопасности"); Михаил Ханов (InfoWatch) - на cеминаре "Защита от инсайдеров"; Константин Сорокин (BioLink), Дмитрий Ушаков и Екатерина Яблокова (Stonesoft) - в секции "Демонстрации средств защиты информации".
В заключительной секции конференции Виктор Минин (МОО "АЗИ", член Консультативного совета при уполномоченном органе по защите прав субъектов персональных данных) доложил об итогах и выводах Парламентских слушаний "Актуальные вопросы развития и применения законодательства о защите прав граждан при обработке персональных данных" от 20 октября, текущих заседаний Консультативного совета и совещания в Минкомсвязи по вопросам гармонизации законодательства в сфере персональных данных от 6 ноября, а также обрисовал сегодняшнюю ситуацию с формированием законодательного поля для ФЗ-152.
Сопредседателями секций выступили Виктор Гаврилов (ФСБ России), Александр Велигура (АРБ), Сергей Котов (Собинбанк) и Александр Захаров (НПФ "Социум") .

Завершилась конференция краткой экскурсией по стендам бизнес-форума All-over-IP, в рамках которого FinSec’2009 проходил, для тех, кто не успел во время перерывов их обойти, и "Праздником молодого божоле", который, как известно, традиционно стартует каждый третий четверг ноября и совпал в этом году с нашими мероприятиями.

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