Кейс-чемпионат поИБэ

В субботу посетил первый в России кейс-чемпионат по информационной безопасности, проведенный университетом ИТМО с очень активной поддержкой сообщества RISC. Проходил чемпионат, как и многие мероприятия подобного рода, в два этапа: первый - заочный, во время которого команды выполняли задания удаленно, а второй очный, где команды в течении часа решали составленный практиками-экспертами поИБэ кейс. 

Фишка чемпионата в  том (что, собственно, мне и понравилось), что речь именно о СУИБ в общем, а не отдельных технических или организационных частях. Учитывая то, что финальный кейс касался, в том числе, и утечки информации, заветные буквы DLP я услышал лишь однажды. А вот "внедрение менеджмента по ISO 27001", "репутационные и финансовые риски", "расследование инцидентов" отправлялись в аудиторию с частотой падения звезд во время метеорного потока Персеиды.

Студенты с неподдельным интересом рассказывали, что нужно организовать взаимодействие со СМИ, создавать комиссию и расследовать инцидент, получить лицензии ФСТЭК и ФСБ, провести инструктаж персонала и много чего еще. В общем, молодцы ребята. Эти студенты, как правильно сказал Алексей Митюшов из "Аэроэкспресса", наши будущие коллеги. И показать им с самого начала учебы, что то, чему учат в ВУЗах сейчас - это не всегда похоже на реальность, было очень важно и нужно. А в случае с кейсами им пришлось активно изучить тему и подготовиться. Взамен они получили опыт общение с практикующими CISO, узнали про ведущих экспертов области, а с некоторыми даже пообщались. 

А я бы с удовольствием посмотрел на студентов в аудитории, которые после подобных мероприятий на лекциях по будут выдавать:

- Как пишет Евгений Родыгин, лучше одновременно использовать два статических анализатора исходных кодов от разных производителей.

- По словам Алексея Лукацкого, внутренний маркетинг в ИБ - это необходимость, а не блажь и в будущем ИБ будет неотъемлемой частью бизнеса.

А на слова лектора "Кто такой Алексей Лукацкий?" студенты молча покидают забитую потоковую аудиторию =)

Было здорово, интересно! Спасибо Марии Сидоровой и Евгению Родыгину. Больше информации у RISC'а

Классификация информации. Начало.

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

Итак, согласно законодательству РФ  схема классификации имеет следующий вид (так называемая классификация по видам доступа):

1. 149-ФЗ "Об информации, информационных технологиях и о защите информации" выделяет общедоступную информация и информацию ограниченного доступа (или информацию, доступ к которой ограничен федеральными законами).

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

2.2. Информация ограниченного доступа имеет общеизвестную классификацию по видам тайн: государственная тайна, коммерческая тайна, персональные данные, служебная тайна и т.д. Вообще, Алексей Лукацкий выделяет 65 видов тайн, Андрей Прозоров 17, Игорь Агурьянов 23, Николай Федотов 16.

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

Согласно же NIST SP 800-60 "Guide for Mapping Types of Information and Information Systems to Security Categories", сначала происходит классификация информации по типам, а лишь после этого принимается решение о конфиденциальности информации, относящейся к тому или иному типу. При чем у применения данного метода классификации есть ряд плюсов. Вот некоторые из них:

1. Масштабируемость схемы.
2. Стандарт может быть использован как для классификации информации, так и для классификации информационных систем.
3. Выделяет два основных типа информации в организации: Mission–based Information и Management and Support Information. Т.е. информация, касающаяся целей организации (миссии, предназначения, кому как нравится)  и информация касательно процессов, поддерживающих ее жизнедеятельность.
4. Схожесть подходов ФСТЭК в приказах 17/21/31 и NIST SP 800-53 позволяет рассматривать NIST SP 800-60 как дополнение к приказам.

Праздник к нам приходит. TimmuS SIB

"Мы строили, строили и наконец построили..."

О чем это я. Последнее время я несколько отошел от блога, что грустно, по крайней мере для меня. Но есть два повода вновь написать пост-другой. Первый - это новые силы после отпуска. А второй... Второй повод и станет темой первого поста после долгого перерыва.

Итак, к нам приближается BIS Summit’2014. Многие знают, что это преобразившаяся и расширившая круг охватываемых вопросов безопасности DLP-Russia. О преображении было сказано на прошлой конференции (я писал об этом), но полностью в новом формате она проходит в первый раз. А это событие знаковое. Так что все запасаемся билетами в Москву и  19 сентября в Холидей Инн Сокольники с утра и до вечера узнаем много нового и интересного. Или старого, но под новым соусом. Позволю себе немного копипаста от организаторов, ибо у них информации всяко больше, чем у меня.

Итак, ключевые темы BIS Summit’2014:

• готовность ИБ к новым рискам, мировые рынки, тенденции;
• борьба с финансовыми потерями как приоритет бизнеса в период стагнации и кризиса;
• целенаправленные атаки: сценарии взлома и варианты защиты;
• переход от DLP-практик к DLP-культуре;
• юридические практики ИБ.

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

Из  заморских купцов международных экспертов выступят:

• Фаяз Хаки (Fayaz Khaki), заместитель руководителя IDC по направлению European Information Security.
• Троэльс Эртинг (Troels Oerting), заместитель руководителя Европола, глава Европейского центра по борьбе с киберпреступностью.

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

• Алексей Лукацкий. Моя презентация с DLP Russia 2013
• Андрей Прозоров. Моя презентация с DLP-Russia. Стандарты и «лучшие практики» в ИБ
• Алексей Волков. Дээлпэ в Раше: happy violence 

ИСПДн "Система Предотвращения Утечек Информации"

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

И на этом фоне возникает еще один интересный нюанс. Что мы расскажем сотрудникам?

1. Что есть такая умная система.
2. Что она  в автоматическом режиме собирает и хранит информацию.
3. Что она на своем уровне ее анализирует.
4. Что сотрудник может иметь к ней доступ.

Больше всего здесь интересен пункт 2, и вот почему:

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

(ФЗ "О персональных данных")

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

1. В первую очередь необходимо понять, обрабатываются ли в системе DLP персональные данные. Скорее всего, да. 

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

(ФЗ "О персональных данных")

2. В DLP-системе могут находится как данные сотрудников, по которым мы их в последующем можем идентифицировать при расследовании инцидентов, так и прочие данные сотрудников и данные клиентов. Следовательно, нужно провести категоризацию информации, которую мы защищаем от утечек с помощью DLP. Я бы в этом случае не упирался рогом только в "ПДн клиентов" и "ПДн сотрудников", а взглянул на эти две категории шире и глубже.

3. В DLP-системе могут находиться все четыре категории ПДн (которые определены в ФЗ-152 и ПП 1119), так как в большинстве случаев DLP защищает всё и вся. Однако, если мы защищаем с помощью DLP базу СКУД и если в ней есть фотографии сотрудников - биометрические персональные данные -, то в DLP они уже не будут таковыми, так как они не будут использоваться для идентификации субъекта. Таким образом, при определении категорий персональных данных не нужно руководствоваться простым суммированием.

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

Это только основные, на мой взгляд, и выделяющиеся моменты, которые дают повод задуматься, является ли ваша DLP-система ИСПДн и сделать первые выводы. Остальное может варьироваться от случая к случаю (от DLP к DLP ;) )

Также интересно: DLP. Спрятать или показать?

Сроки реагирования и ответов в ФЗ "О персональных данных"

В 20 и 21 статьях ФЗ "О персональных данных" указаны четкие сроки, которые должны быть соблюдены оператором в случаях обращения к нему субъекта персональных данных, а также в случаях выявления нарушений законодательства при обработке персональных данных.

Свел все в одну таблицу для наглядности.

Статья, часть	Ситуация	Действие	Срок	Уведомление
ст.20 ч.1	Обращение субъекта или его представителя с требованием предоставить сведения, касающиеся обработки его ПДн	Предоставление сведений, касающихся обработки ПДн субъекта (ст.14, ч.7)	При обращении или в срок до 30 календарных дней с момента обращения или получения запроса
ст.20 ч.2	Обращение субъекта или его представителя с требованием предоставить сведения, касающиеся обработки его ПДн	Мотивированный отказ с указанием положения, предусмотренного ч.8 ст.14.	При обращении или в срок до 30 календарных дней с момента обращения или получения запроса
ст.20 ч.3	Предоставление субъектом  сведений, подтверждающих неточность, неполноту или неактуальность ПДн	Внесение изменений в персональные данные (актуализация).	7 рабочих дней с момента предоставления сведений	О внесенных изменениях
ст.20 ч.3	Предоставление субъектом сведений, что данные получены незаконно или не соответствуют заявленным целям обработки	Уничтожение персональных данных	7 рабочих дней с момента предоставления сведений	Об уничтожении (явно не указано)
ст.20 ч.4	Обращение уполномоченного органа по защите прав субъектов ПДн (Роскомнадзор)	Предоставление Роскомнадзору необходимой информации	30 календарных дней с даты получения запроса
ст.21 ч.1	Выявление неправомерной обработки (в результате обращения субъекта, его представителя или уполномоченного органа)	блокирование неправомерно обрабатываемых ПДн или обеспечение блокирования (в случае обработчика)	с момента обращения или получения запроса (ст 14. ч.1) на период проверки
ст.21 ч.1	Выявление неточных ПДн (в результате обращение субъекта, его представителя или уполномоченного органа)	блокирование неточных ПДн или обеспечение блокирования (в случае обработчика)	с момента обращения или получения запроса (ст 14. ч.1) на период проверки
ст.21 ч.2	Подтверждение факта неточных ПДн	уточнить данные (или обеспечить их уточнение) и снять блокирование	7 рабочих дней со дня предоставления	О внесенных изменениях (ст.20 ч.3)
ст.21 ч.3	Выявление факта неправомерной обработки ПДн	прекращение неправомерной обработки	3 рабочих дня	Об устранении нарушений
ст.21 ч.3	Невозможность обеспечения правомерности обработки	уничтожение персональных данных *	10 рабочих дней с даты выявления неправомерной обработки	Об уничтожении ПДн
ст.21 ч.4	Достижение цели обработки ПДн	уничтожение персональных данных * **	30 календарных дней с момента достижения цели
ст.21. ч.5	Отзыв субъектом согласия на обработку ПДн и если сохранение ПДн не требуется для целей обработки	Прекращение обработки и уничтожение ПДн * **	30 календарных дней с даты поступления отзыва согласия

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

** если иное не предусмотрено договором, стороной которого, выгодоприобретателем или поручителем по которому является субъект персональных данных, иным соглашением между оператором и субъектом персональных данных либо если оператор не вправе осуществлять обработку персональных данных без согласия субъекта персональных данных на основаниях, предусмотренных ФЗ "О персональных данных" или другими федеральными законами.

DLP. Спрятать или показать?

Недавно на BIS-Expert'e своими размышлениями по поводу бюджетов в ИБ поделился УЦ "Информзащита". И в этих размышлениях есть пункт, с которым я несогласен. И касается это использования систем DLP-систем в организации, предлагается держать это в секрете. И одним из аргументов является то, что если сотрудник будет знать, что в организации есть DLP-система, он будет искать пути обхода. Моя позиция относительно использования DLP-систем в организации , а именно в их сокрытии от сотрудников, обратна. И на этот счет у есть несколько аргументов:

1. Если мы скрываем то, что применяем DLP-систему для контроля утечек, то организация должна понимать, что есть высокая вероятность нарушения конституционных прав человека (а сотрудники у нас в первую очередь люди), предоставленных им 23 статьей. Ведь контролируя свою информацию, мы можем наткнуться и на личную информацию сотрудника, на его переписку. И здесь недостаточно закрытия внешних почтовых ресурсов. Сотрудник может вести личную переписку со служебной почты, даже если это запрещено внутренними положениями. Сотрудник нарушает внутреннее положение организации, возможно. Да, мы можем его депримировать или уволить. Но организация нарушает его конституционные права, и он может подать в суд. На мой взгляд, несоизмеримо. Для этих целей нужно предупредить сотрудника о том, что его личная информация может стать доступна лицам, указать, при каких условиях и взять на это его согласие. Главное здесь, не перегнуть палку и сказать, что организация это делает только в рамках защиты своей КТ и ни в коем случае ни в целях слежения за сотрудниками. И здесь сразу несколько profit'ов:

• Мы действуем в рамках закона.
• У сотрудника не будет лишнего желания поделиться интимными подробностями пятничного вечера с товарищем "снаружи" с рабочего места.
• Сотрудник понимает, что к нему относятся с уважением и лояльность его относительно компании может возрастать.

2. Открытость внедрения DLP-систем является драйвером для службы ИБ для более тщательной и грамотной ее настройки. Теперь сотрудник знает, что такая система есть и может предпринимать шаги к ее обходу. И, следовательно, службе ИБ нужно более грамотно настроить DLP-систему. А чем грамотнее она будет настроена, тем лучше для организации.

3. Даже само название Data Loss(Leak) Prevention говорит о том, что основной задачей таких систем является предотвращение утечек. А немалая часть таких утечек совершается по банальной ошибке. Не даром во многих DLP-системах во всплывающих окнах при отправке документа, попадающего под политику ограничения, есть пункт "Я не знал, что это коммерческая тайна". Какие выводы можно сделать из этого?

• Если сотрудник и правда не знал, он это укажет (результаты ответов падают АИБу и за сотрудником можно присмотреть более пристально, а вдруг и правда инсайдер). Если сотрудник знал, но попытался, он будет осторожней (опять таки, за ним можно присмотреть). Но в любом случае мы предотвратили утечку. Система достойно справилась со своей основной задачей.
• В обратном случае если сотрудник отправит документ и такого окошка у него не будет, то вслучае, если сотрудник не инсайдер лояльность отношения к компании у него может упасть, так как может появиться ощущение "тотальной слежки". А организации это надо? И тем более, после нескольких инцидентов вся тайна о существовании DLP-системы в организации перестанет быть тайной, так как сарафанное радио никто не отменял. И здесь можно добавить еще и принцип испорченного телефона, когда из обыной DLP-системы и порядочного АИБа мы получим СОРМ и злого КГБшника (простите, если кого обидел).

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

Семинар RISSPA. Особенности приготовления PCI DSS 3.0

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

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

Эстафету выступлений принял Анатолий Скородумов, начальник отдела ИБ ОАО "Банк Санкт-Петербург" и  рассказал про то, как их банк готовился к оценке соответствия требованиям PCI DSS, с какими пришлось столкнуться трудностями. Доклад получился достаточно живым. Анатолий первым словом попросил зал именно о диалоге, а не о монологе. И слушатели с радостью поддержали это начинание. Далее прозвучала достаточно интересная фраза о том, что PCI DSS с доработками можно использовать в качестве политики ИБ организации. По ходу диалога стало ясно, что не любая организация, а та, которая в своей работе "завязана" на использование банковских карт и для которых это является большой частью основной деятельности.

За Анатолием слово взял Сергей Шустиков, генеральный директор компании Deiteriy. Держал он это самое слово про особенности перехода с версии 2.0 на 3.0. Многое отражено в презентации, я приведу лишь несколько тезисов:

• PCI DSS должен стать такой же привычкой, как мыть руки перед едой (Business as Usual). При любом действии, касающимся банковских карт, нужно помнить про PCI DSS.
• В PCI SSC реагируют на обратную связь. Пишите.
• С момента вступления в силу очередной версии стандарта PCI DSS предыдущая продолжает действовать еще год. 

Также Сергей наглядно продемонстрировал, что для совершения покупки в интернете достаточно знать только номер карты и срок ее действия. И пример был показан не на маленьком магазинчике, а на amazon.com. Да, там есть еще поле для ввода имени и фамилии, но оно, по словам Сергея, не проверяется.

После Сергея выступал Никита Кислицин из Group-IB. Он подробно разобрал черный рынок банковской информации, коснулся ситуации с Target, выделил основные пути хищения и использования информации. В общем, получился очень хороший технический доклад с элементами Awareness, что на мой взгляд, безусловно, правильно.

Далее всех ждал полноценный шведский стол. После же Вячеслав Максимов из компании "Андэк"  провел интересную презентацию о взаимодействии с сервис-провайдерами в рамках соответствия PCI DSS. Из основного:

• Напоминание о том, что PCI DSS применим везде, где присутствуют банковские карты.
• Некоторые нюансы, на которые необходимо обратить внимание при передаче услуг по обслуживанию банковских карт. Например при заполнении Attestation of Compliance желательно максимально подробно расписывать свои процесссыы, если в итоге целью является именно безопасность, а не формальное соответствие требованиям. QSA-аудитор - ваш друг!
• Пункт 12.9 PCI DSS 3.0, касающийся сервис-провайдеров,  вступает в действие с 15 июля 2015.

После Вячеслава Алексей Бабенко из компании "Информзащита" провел экскурс в этапы разработки ПО с учетом PCI DSS. Хочу отметить, что презентация, которая представлена здесь и презентация, которую видел зал, разные. Хотя больше не по содержанию, а по "формату". Мы смотрели презентацию, запущенную из exe-шника (прошу прощения, из исполняемого exe-файла). Однако, суть от этого не менялась.  Опять-таки, была отмечена важная роль обучения сотрудников в процессе разработки ПО.

Далее Константин Ян из ЗАО "Смартфин" подробно расказал про mPoS-терминалы и про их преимущества перед привычными PoS, про особенности работы технологии и про перспективы развития. Сказать, что было интересно - не сказать ничего. И может настать момент, когда ситуация, в которой курьер, доставивший пиццу, предложит для оплаты не стандартный терминал, а обычный сотовый телефон с присоединенным к нему ридером, станет вполне ординарной.

После Дмитрий Свиридов из компании KupiBilet.ru поведал о том, как "голому" стартапу пройти оценку соответствия PCI DSS.  Доклад можно считать некоторым руководством, как делать надо, как не надо и на что обращать внимание если ваша компания только начинает плавание в большом океане бизнеса.

Завершающим был доклад Андрея Дроздова из компании KPMG. Андрей рассказал про лучшие практики и стандарты, широко затронул COBIT и также акцентировал внимание на Awareness. Приводить отдельные тезисы не буду, лучше смотреть презентацию и воспринимать все единым целым. Скажу лишь, что доклад был действительно на высоте. 

Как я уже говорил, перед началом семинара был анонсирован конкурс на лучший вопрос. И счастливым обладателем ковбойской шляпы стал Андрей Инюшин из Travel.ru (Oktogo group). Также отметили Михаила Карпова из Ленты и Игоря Кнауфа из Объединенных машиностроительных заводов. Им достались ежедневники от компании Deiteriy. 

После было закулисное общение, благодарности и прощания.

Я не стал выносить много цитат в пост, так как  на протяжении всего мероприятия я писал самое интересное в твиттер. И, конечно, мои (и не только) твиты доступны по хэш-тегу #RISSPA_Spb 

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

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

Мария, Сергей <Шустиков> - большое спасибо за семинар. Все доклады были очень информативными и интересными. Жду новых мероприятий.

Отдельно привожу презентации докладчиков:

• Мария Сидорова. RISSPA SPb: вчера, сегодня, завтра  
• Анатолий Скородумов. Трудный путь к соответствию требованиям PCI DSS (путевые заметки) 
• Сергей Шустиков. Стандарт PCI DSS: как перейти с версии 2.0 на 3.0 
• Вячеслав Максимов. Особенности взаимодействия организаций в рамках программы соответствия PCI DSS  
• Алексей Бабенко. Разработка ПО в рамках PCI DSS, как ее видит жуткий зануда 
• Константин Ян. Всесторонние аспекты защиты Mobile point of sale  
• Дмитрий Свиридов. История одного стартапа  
• Андрей Дроздов. Как одновременно соответствовать различным регуляторным требованиям и лучшим практикам в области ИБ и ИТ