О программе повышения осведомленности

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

Есть еще конечно проверенный годами метод кнута… Но будет ли он работать эффективно? Демотивированный персонал лучше работать не станет. Скорее наоборот. А специалисты по безопасности превращаются в надсмотрщиков.

А ведь часто бывает, что большинство персонала в компании даже не осведомлено о существующих политиках и стандартах в организации!

А если пользователи и знают требования по безопасности, то очень часто их не понимают и недооценивают для чего это необходимо.

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

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

И для того, чтобы сделать это максимально эффективно, нам и нужна та самая программа повышения осведомленности.  Как правило, такая программа включает следующие элементы:

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

Где и что почитать подробнее (на английском):

• Security Awareness—Best Practices to Serve Your Enterprise от ISACA
• How to raise information security awareness от ENISA
• SP800-50 Building an Information Technology Security Awareness and Training Program
• SP800-16 Rev1 Information Security Training Requirements: A Role- and Performance-Based Model

ISO 27001 <> СОУ Н НБУ 65.1 СУІБ 1.0:2010

Общался сегодня с бывшим коллегой из моего банковского прошлого. Услышал от него интересный комментарий, полученный якобы от Ирины Сергеевны Ивченко (главный идеолог и методолог СОУ Н НБУ 65.1 СУІБ 1.0:2010 и смежных стандартов). Что, даже если банк сертифицирован по ISO 27001, это не значит, что банк соответствует требованиям СОУ Н НБУ 65.1 СУІБ 1.0:2010.
Моя первая реакция была - "бред". СОУ является локализированной версией ISO.
В той же методичке по внедрению написано, что в случае соответствия банка стандарту СОУ Н НБУ 65.1 СУІБ 1.0:2010, Нацбанк гарантирует (тут он, конечно, погорячился) соответствие ISO 27001. А обратной совместимости выходит нет?
Но потом вспомнил главное ключевое отличие ISO и СОУ - в ISO мы можем сертифицировать один процесс и получить сертификат. В СОУ же четко сказано: объем для внедрения - весь банк.
Видимо из-за незнания этого нюанса, незрелые консультанты, которые мечутся сейчас по банкам с предложениями внедрить "все как по стандарту", обещают уложится за 3 недели. А может это осознанное желание "успеть рубануть денег, а там как карта ляжет"...

Назначено руководство Госслужбы по вопросам защиты персональных данных

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

Между тем, единственное, что можно сделать на текущий момент - это провести инвентаризацию и составить перечень баз и картотек персональных данных. Дальше пока никак. Ибо Государственная служба по вопросам защиты персональных данных создана месяц назад, а руководство этой службы назначено позавчера. Если быть абсолютно точным, то был назначен  председатель (Алексей Мервинский) 28 декабря 2010 (указ № 1270/2010), а позавчера были назначены  первый заместитель председателя (Олег Фролов, указ № 88/2011) и  заместитель председателя ведомства (Владимир Козак, указ № 89/201).

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

И последний момент. Комитет по вопросам законодательного обеспечения правоохранительной деятельности разработал проект изменения в законодательстве.
В частности, проект предполагает изменения в Уголовном кодексе, Кодексе Украины об административных правонарушениях, Уголовно-процессуальном кодексе и Законе «Об информации». Предусматривается:

• уточнить понятие «информация о лице», содержащееся в статье 23 Закона «Об информации»
• установить административную ответственность за нарушение законодательства в сфере защиты персональных данных и нарушение установленных законодательством требований о защите информации о лице в статьях 188 37 и 188 38 КУоАП
• возложить обязанность относительно рассмотрения дел о правонарушении на уполномоченный государственный орган по вопросам защиты персональных данных (статья 244 19 КУоАП)
• изложить в новой редакции норму статьи 182 1 Уголовного кодекса

Проект также предлагает дополнить Уголовный кодекс новыми статьями (182 1, 182 2), предусмотрев в них уголовную ответственность за нарушение требований о защите информации о лице и отдельно за умышленное нарушение таких требований и установить, что досудебное следствие должно проводиться тем органом, к подследственности которого относится преступление, в связи с которым возбуждено это дело (часть шестая статьи 112 УПК).

А это серьезная "пугалка" для продажи услуг консультантами. И в период, когда ответственность уже есть, а требования еще не финализированны, продать можно ой как много...

Cоу н нбу 65.1 суіб 1.0:2010 - время косить бабло

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

Внедрение стандарта в полном объеме к 1-у октября 2011.
Внедрение стандарта в полном объеме нереально по огромному ряду факторов:

• Не завершены рекомендации и методики НБУ по внедрению использованию стандартов (а время идет).
• Внедрение некоторых требований стандарта займет значительное время и будет достаточно дорогостоящим. Например А.14 Управление непрерывностью бизнеса. Мало кто из банков на текущий момент имеет полноценный план обеспечения непрерывности бизнеса. И стоит это удовольствие не 10 долларов.
• Есть не разъясненные моменты по защите персональных данных (А.15.1.4). Не самая большая проблема, но есть.
• Самое главное - ресурсы. Для внедрения стандарта в полном объеме, банкам необходимо сейчас бросить все и заниматься исключительно стандартом. А это, естественно, ни один банк не сможет себе позволить - есть другие, более важные задачи. К тому же на рынке нет достаточного количества квалифицированных специалистов по информационной безопасности, которые бы могли это все дело обслуживать. Наличие на рынке квалифицированных аудиторов, которые требуется стандартом, до смешного мало. При использовании же внешних специалистов стоимость внедрения начинает исчисляться сотнями тысяч долларов. 

Внедрение стандарта в течение 2-3х недель
Даже не буду комментировать.

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

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

Занимательная таксономия

Таксоно́мия (от др.-греч. τάξις — строй, порядок и νόμος — закон) — учение о принципах и практике классификации и систематизации

Wikipedia

ТАКСОНО́МИЯ, -и, ж. Наука о классификации сложных объектов действительности (живой природы, строения Земли, этнических общностей, языка и др.).

Словарь Ожегова

Таксономия термин в словаре не найден

Словарь Даля 

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

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

Стратегический уровень:

• Стратегия ИБ
• Политика ИБ

Операционный/тактический уровень:

• Процедуры/стандарты
• Руководства
• Инструкции

Теперь пройдемся по сути документов.

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

Со следующими документами возникает путаница, потому что, как я писал выше, каждые лучшие практики называют их по-разному. Главное не название. Главное суть. А суть их в том, что документы с разной детализацией и на разных уровнях описывают подходы по реализации тех целей, которые у нас содержаться в Политике. Привожу на примере NISTа

• Процедура - обязательный документ. Описывает реализацию политики по конкретному направлению. Чаще всего одного процесса ИБ. Например, "процедура по мониторингу событий информационной безопасности" или "процедура по оценке информационных рисков"
• Стандарт - обязательный документ. Описывает техническую реализацию политики для конкретного инфраструктурного уровня. Пример, "стандарт конфигурации настроек информационной безопасности для активного сетевого оборудования"
• Руководство - не обязательный документ. Данный тип документа содержит рекомендуемые действия для администраторов / пользователей и т.д. В силу того, что документ не обязательный, и времени нет даже на обязательные, руководства  в природе почти не встречаются. Исключение составляют руководства от внешних разработчиков и поставщиков программного/аппаратного обеспечения, вроде Security Giude от Microsoft, Cisco или SWIFT.
• Инструкция - обязательный документ. Детальное пошаговое описание выполнения определенных действий для определенных ролей. На подобии документа "нажмите такую кнопку, появится ... см. картинка 1...  выполните команду.... убедитесь что...". 

Написание и главное поддержание таких документов в адекватном состоянии - задача достаточно трудоемкая. Но наличие дает целый ряд неоспоримых преимуществ:

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

О подборе специалистов по ИБ

Ни что так не близко специалистам по информационной безопасности, как деньги, которые они получают.  Ярким тому примером служит тема "ЗП специалистов по ИБ" на форуме UISG. Тема сначала зародилась в недрах совсем другой, затем начала набирать популярность и выделилась в отдельную и скоро, похоже, станет отдельным форумом. Из долгих трений "кто кому сколько платит?", отдельно перемыли "кто?" и "сколько?" и дошли до интересного вопроса "кому?".
Одному из членов форума показались забавными требования к консультанту по безопасности, выдвигаемые одной из консалтинговых фирм:

• Возраст 25 до 35 лет
• Высшее техническое образование в сфере информационных технологий (желательно в области ИБ)
• Опыт работы в ИТ безопасности - от 3-х лет
• Аналитические способности
• Грамотная речь
• Любознательность
• Коммуникабельность
• Быстрая обучаемость
• Английский уровня не ниже intermediate (устный и письменный)

Как человек, работающий в одной из таких фирм и занимающийся в том числе подбором персонала к себе в подразделение, скажу, что достаточно типовые требования. Вроде бы даже смешно такое требовать. На практике же (за последние пару лет интервьюировал более 60 человек + еще сотни полторы отсеялось предварительными тестами) найти специалиста удовлетворяющего таким "банальным" требованиям задача не тривиальная. Рассмотрим по порядку влияние факторов на вероятность нахождения нужного нам кандидата (в моем примере поиск на позиции младшего и среднего уровня) :

• Возраст - тут все более-менее понятно. В зависимости от позиции, которую компания предлагает, определяем ожидания и от кандидата. Если позиция начального уровня - то даже 30 лет у кандидата вызывают вопрос: "А чем ты занимался раньше, если идешь на начальную позицию?".  С другой стороны в 35 лет быть консультантом... Это тоже специфика отдельных компаний. Обычно это уже возраст менеджера / старшего менеджера / партнера. Это их теории. На практике с возрастом у кандидатов проблем нет. Был конечно случай, в 50 человек пришел на начальную позицию "готовый учится". Что поделаешь - кризис и не такое с людьми делает.

• Высшее техническое образование в сфере информационных технологий (желательно в области ИБ) - Первое препятствие. Мало кто из выпускников, даже престижных ВУЗов, может похвастаться приличными техническими знаниями. Из них малая толика - широкими техническими знаниями. Краснодипломник технической специальности плохо владеющий компьютером на уровне рядового пользователя.  Выпускник Политеха специальности "защита информации"  не знающий чем отличается симметричное шифрование от асимметричного. К сожалению, такие "специалисты" встречаются гораздо чаще, чем хотелось бы. А куда делись все специалисты по xNIX системам? Средний уровень знаний по данному направлению - "умею устанавливать Ubuntu". Соискателей же, которые обладают знаниями, можно разделить на  категории: 

1. Те, у кого есть технические знания на уровне администрирования систем (включая вопросы безопасности), но не знакомы со стандартами, регламентирующими вопросы ИБ. Более предпочтительный тип, если мы ищем младшего специалиста,  ибо основа есть, а остальному легко научить. Таких мало.
2. Те, кто хорошо понимают знают высокоуровневые стандарты (27к и т.д.) и могут их цитировать с любой страницы. Но понятия не имеют, как это реализовать на практике. Таких больше.
3. Те, кто знает и то и то. Встречаются редко. Как правило, на младшие/средние позиции  работу не ищут.

• Опыт работы в ИТ безопасности - от 3-х лет. - В целом, делятся на два вида - те, у кого есть и те, у кого нет (спасибо, Кэп). Те, у кого опыт есть, также условно делятся на 3 типа схожих с предыдущими:

1. "Технари". Опыт как правило связан с файерволами/IDS/IPS/IRM/DLP и другими мигающими коробочками, как говорит один мой коллега.  Подходят для младших и средних позиций. Нужно дообучать нормативке.
2. "Законодатели". Мастера бумажного беспредела бумажной безопасности. Основной опыт состоит из: а) написания мертвой нормативной базы б) никому ничего не разрешать.
3. "И швец и жнец"  Встречаются редко. Как правило, на младшие/средние позиции  работу не ищут.

• Аналитические способности. Любознательность.  - Не проблема. Для большинства соискателей наличие этих двух факторов обуславливают выбор профессии. За всю историю вспомню может только пару людей с атрофированной логикой, которые хотели работать в безопасности.  

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

• Быстрая обучаемость. - Не проблема. Не встречал людей, чтобы нормальное образование, аналитические способности, любознательность, коммуникабельность и т.д. и при этом медленно обучаются. 

• Английский уровня не ниже intermediate (устный и письменный).  - Последнее серьезное препятствие. Почему-то среди ИБ специалистов, как и среди саперов (специалистов по SAP), знание английского языка считается дурным тоном. Приходит кандидат - и знания есть, и опыт, и коммуникабельность (таких нужно заносить в красную книгу), а английский на уровне индикатора из "Тайны третьей планеты" - все понимает, но не говорит, только меняет цвет.

Вот и приводит комбинация факторов к ситуации, когда специалисты по ИБ ищут работу, а компании ИБ специалистов, и не могут друг друга найти.