понедельник, 2 июля 2018 г.

КИИ. Категорирование объектов, часть 3


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

3. Определение объектов КИИ
Продолжаем начатое на прошлых этапах (а можно и совместить 1-3) общение с руководителями подразделений. Спрашиваем какие ИС или АСУ обрабатывают информацию, необходимую для обеспечения выявленных критических процессов, и (или) осуществляют управление, контроль или мониторинг критических процессов.
Отдельно в ИТ подразделении получаем полный перечень ИС (он должен был готовится в рамках мероприятий по ПДн) и АСУ, совместно с ИТ выкидываем из перечня ИС, не связанные с критическими процессами (как правило, кадровые, бухгалтерские, отчетность, банк-клиенты).
В результате, того, что данные об ИС и АСУ получены не из одного источника, гарантируется его большая адекватность и актуальность.
(UPDATE) При формировании перечня АСУ, обращайте внимание на определение АСУ, данное в 187-ФЗ. Возможно придется вычеркнуть некоторые АСУ не подходящие под определение. Например, если в составе его нет программных средств, или если это АСУ управляется не технологическим или производственным оборудованием.    
Далее к перечню объектов КИИ необходимо добавить информационно-телекоммуникационные сети. Тут нет особого смысла дробить на маленькие кусочки. Указываем одним пунктом – корпоративная сеть организации. Внешние защищенные сети, такие как Защищенная сеть Минздрава РФ, Защищенная сеть Минздрава КК, Защищенная сеть ТФОМС – не указываем, так как не являемся владельцами данных сетей.

3.а. Получившийся, предварительный, но ещё не утвержденный, перечень объектов КИИ отправляем вышестоящему гос. органу (Минздрав субъекта РФ). По-хорошему, отраслевые регуляторы должны публиковать порядок согласования с ними перечней, но пока такого не замечено. Поэтому просто пишем письмо  
“В соответствии с требованиями пункта 15 Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, утвержденных Постановлением Правительства РФ от 8 февраля 2018 г. № 127 направляем Вам на согласование предварительный перечень объектов критической информационной инфраструктуры нашей организации.”
и прикладываем перечень объектов КИИ.

3.б. Минздрав субъекта РФ, посмотрит не забыли ли вы указать какую-то систему, которую указали коллеги до вас. По-хорошему, они могли бы предложить убрать системы, которые точно не будут критическими. Но в ближайшее время этого делать никто не будет, так как информации недостаточно. И уже озвучиваются вопросы типа “вдруг мы вычеркнем систему, а потом произойдет инцидент и окажется что не надо было её вычеркивать”.

4. Утверждение перечня объектов КИИ
После согласования перечня с отраслевым регулятором, готовим формальный документ с перечнем объектов и отдаем его руководителю на утверждение. Одновременно с ним нужно подготовить письмо на начальника 2 управления ФСТЭК России (копию на руководителя Управления ФСТЭК России по вашему федеральному округу), приложением к которому необходимо приложить перечень объектов КИИ.
И хотя форма перечня объектов КИИ формально не утверждена, но на семинарах, в письмах и заседаниях ФСТЭК России приводит различные “рекомендованные форматы”
например, такой



или такой


Если обобщать, то в целом получается такая форма перечня (примеры объектов КИИ)
Наименование организации
Сфера деятельности
Наименование объекта КИИ
Планируемый срок категорирования
Адрес и контакты организации
ККБ №0
Здравоохранение
ИС:
"Электронная очередь"
"СОЦ-Лаборатория"
"Льготные рецепты"
"М-Аптека"
МИС "Самсон"
"Медкомтех"
"03"
"Экспресс-здоровье"
"Скрининг новорожденных"
"Высокозатратные нозологии"
"Регистр больных сахарным диабетом"
АРМ ПЦ ЛЛО
СК ИПРА
АСУ:
Автоматизированная система оперативного управления диспетчерской службой скорой медицинской помощи
АСУ пожаротушением
АСУ рентген аппаратами
АСУ томографом
АСУ лучевой терапия
ИТС:
Корпоративная сеть ККБ №0
1 января 2019 г.
Руководитель – Иванов И.И.

(861)2790001

г. Краснодар, ул. Красная 1.

Несмотря, на то, что в ПП 127 не установлены сроки на утверждение перечня объектов КИИ, есть решение Коллегии ФСТЭК России от 24.04.2018 №59, в котором озвучены сроки, которые в свою очередь доносятся на заседаниях по защите информации во всех субъектах РФ.

Пример протокола такого заседания можно посмотреть тут.
Срок на утверждение перечня объектов КИИ – до 1 августа 2018 г.
Срок на проведение категорирования объектов КИИ – до 1 января 2019 г.

пятница, 29 июня 2018 г.

ИБ. Как не нужно моделировать угрозы ИБ


Не смотря на то что нет ни одной утвержденной ФСТЭК России методики моделирования угроз, учитывающей БДУ ФСТЭК России и не смотря на то что ФСТЭК России на семинарах говорит, что заказчики могут использовать любые подходящие им методики, по факту при согласовании МУ с регулятором (а это обязательно, например, для ГИС) или при проверках регулятора далеко не все модели угроз проходят без замечаний.

Зачастую отдельные территориальные органы предъявляют специфические требования к моделям угроз.  И сегодня хотелось бы обсудить такое требование, как указание в модели угроз перечня уязвимостей из БДУ ФСТЭК России.  
Но идею использовать базу уязвимостей из БДУ ФСТЭК при моделировании угроз я встречал не только у регулятора, но и у некоторых продвинутых специалистов операторов. Что в общем не удивительно – раз уж есть база, почему бы её не использовать?

Предлагается использовать уязвимости из БДУ следующим образом: определять перечень используемого в ИС программного обеспечения, а потом выбирать все уязвимости, соответствующие версиям используемого ПО. 

Например, если у нас используется ОС Window 7, то мы должны привести перечень всех 306 уязвимостей, связанных с данной ОС


Если MS office 2007 – ещё 135 
MS Adobe Flash Player 11 – ещё 646.

Таким образом, в достаточно большой ИС, с разным прикладным и системным ПО, мы выберем из БДУ ФСТЭК, например, половину всех уязвимостей. Порядка 9000. И что дальше? Зачем нам эта информация на этапе моделирования угроз? На этапе, когда самой ИС ещё нет, а только формируются требования к ней?
    
Для чего нам вообще моделирование угроз? Для того чтобы на этапе создания системы защиты мы могли выбрать правильные меры и средства защиты. Как нам поможет этот перечень гипотетических уязвимостей, которые могут быть, а могут и не быть в итоговой системе.  Ведь для нейтрализации угроз, связанных с эксплуатацией публично известных уязвимостей, существует всего 2-3 меры:
·         установка патчей и патч-менеджмент
·         виртуальный “патчинг”, для тех случаев, когда мы не можем быстро установить обновление
·         изолирование уязвимого узла на уровне сети

А что если у нас новая версия ПО и в БДУ ФСТЭК на него пока не зарегистрированы уязвимости? Исходя из этого мы можем не включить в нашу систему защиты меры по регулярному обновлению ПО? Нет. Меры по регулярному анализу уязвимостей и установке обновлений ПО и так уже прописаны как обязательные в 17 и 239. Лучше сразу исходить из концепции что в нашем системном и прикладном ПО могут быть уязвимости, просто пока мы не о всех знаем.

Но нам же надо моделировать… от нас требуют анализировать уязвимости при моделировании угроз – скажете Вы.  
Посмотрите, как классифицировались угрозы по типам уязвимостей в базовой модели угроз ФСТЭК от 2008 г. – там нужно было ответить, могут ли у нас быть уязвимости на разных уровнях: в системном ПО, прикладном ПО, сетевых протоколах, СЗИ, наличие аппаратных закладок, технических каналов утечки, недостатки мер защиты. 7 уязвимостей.
Посмотрите в текст угроз из БДУ ФСТЭК, как там описаны уязвимости, которые могут быть использованы при реализации угроз. Это совсем не те уязвимости.
 


Да, они плохо структурированы, они не типизированы, но их хотя бы 200, а не 18000 как в соседней ветке. С 200 уже можно работать.  Но ещё лучше структурировать уязвимости, упомянутые в тексте угроз из БДУ и привести их к 7-30 типам, по которым необходимо будет принять обоснованное решение – могут у нас быть такие уязвимости или нет.

Хотите ещё пример, как можно описывать и классифицировать уязвимости в рамках моделирования угроз? Ну вот хотя бы ГОС ИСО/МЭК 27005-2010 Менеджмент риска ИБ


четверг, 31 мая 2018 г.

КИИ. Категорирование объектов, часть 2


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

Небольшое отступление чтобы объяснить при чем тут процессы:
·         в итоге категорирования мы должны определить попадают ли возможные последствия от компьютерных инцидентов на объекте КИИ (ИС, АСУ, телеком сети) в категории значимости

·         очевидно, что если объект КИИ автоматизирует или предоставляет информацию для обеспечения определенного процесса организации, то ущерб от инцидента на объекте не может превышать максимального ущерба от нарушения всего процесса, включающего как автоматизированную, так и неавтоматизированную деятельность
(например, если от полного прекращения деятельности службы скорой помощи, медицинская помощь не будет оказана 1000 человек, по статистике 10% из которых=100 приведут к ущербу здоровью, то от нарушения деятельности АСУ диспетчерской службы скорой помощи, деятельность полностью не прекратится, но будет оказываться менее эффективно - только 100 человек не получат её, 10% из которых =10)    

·         правительство РФ решило более эффективным будет сначала выявить критические процессы и отбросить лишние, чтобы не тратить в дальнейшем время на системы с ними связанные

·         поэтому в первую очередь надо выявить критические процессы


2. Выявление критических процессов
Продолжаем общаться с руководителями подразделений. Нам нужно выяснить у них возможные последствия от нарушения или прекращения процесса организации. Последствия рассматриваем в разрезе показателей критериев, утвержденных постановлением правительства №127. Если вы уверены, что ряд показателей заведомо не применимы к процессам вашей организации, то можно их отбросить, чтобы не тратить на них время в пустую. Например, для мед. организаций я бы оставил такие показатели для рассмотрения (UPDATE):



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

Оптимальным вариантом с моей точки зрения представляется необходимость получить следующую информацию:
·         сможет ли ущерб он нарушения процесса на сколь угодно долгое время достичь показателя значимости КИИ? Если нет, то мы можем смело отбросить его из числа критических. (например, если мы поняли, что сколько бы система не была отключена или работала неправильно – день, месяц, год, это не приведет к ущербу здоровью граждан)
·         если в принципе может достичь показателей значимости, то в каких промежутках попадает в какую категорию (например, если деятельность будет нарушена на 1-10 дней – то потенциальный ущерб попадет в 3 категорию, если на 10-30 то во 2 категорию). Далее нам пригодятся эти значения
·         если руководителю подразделения сходу трудно оценить ущерб по экономическим показателям, даем им подсказки, подкатегории ущерба:
o   упущенная выгода
o   штрафы, пени, неустойки и т.п.
o   дополнительные затраты на персонал
o   дополнительные затраты на оборудование, материалы, энергию и т.п.
o   судебные издержки
o   дополнительные представительские расходы

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

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


PS: продолжение следует.


четверг, 24 мая 2018 г.

КИИ. Категорирование объектов, часть 1


Давайте будем проводить категорирование объекта КИИ на примере организации сферы здравоохранения.

Будем руководствоваться следующими НПА:
·        Федеральный закон от 26.07.2017 N 187-ФЗ "О безопасности критической информационной инфраструктуры Российской Федерации"
·        Постановление Правительства РФ от 8 февраля 2018 г. № 127 “Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений”
·        Приказ ФСТЭК России ОТ 06.12.2017 N 227 "Об утверждении порядка ведения реестра значимых объектов критической информационной инфраструктуры Российской Федерации"
·        Приказ ФСТЭК России от 22.12.2017 N 236 "Об утверждении формы направления сведений о результатах присвоения объекту критической информационной инфраструктуры одной из категорий значимости либо об отсутствии необходимости присвоения ему одной из таких категорий"

Общая схема категорирования примерно следующая:



Давайте подробнее разберем начальные этапы.

0. Формирование комиссии.
Очевидно, что чем больше специалистов мы включим в комиссию, тем на больший срок затянется наше категорирование. С другой стороны без специалистов по основным видам деятельности безопаснику будет сложно определить критические процессы и оценить последствия их нарушения.
В случае медицинской организации включить главного врача и его заместителей по мед. деятельности, ответственного за ИБ, ответственного за ГОиЧС. Также можно попробовать договориться с местным Минздравом, МИАЦ (это обеспечит быстрое согласование перечня объектов), а также с организацией оказывающих вашей организации услуги в области ИБ, о включении их сотрудников. Договорится можно в устной форме, но потом лучше отправить официальное письмо данным организациям с просьбой предоставить эксперта для участия в категорировании объектов КИИ.
Создание комиссии необходимо документировать. Вероятнее всего это будет приказ о создании комиссии для категорирования объектов КИИ в такой то организации. Там могут быть определены конкретные этапы и сроки, но не обязательно. Полный цикл категорирования, скорее всего, займет значительное время, поэтому лучше сразу определить, как будут фиксироваться промежуточные решения комиссии: протокол, акт...

1. Определение процессов
В идеальном случае, в вашей организации уже документированы основные процессы. Либо Вы, как правильный ИБ специалист, определили их в начале своей работы в организации. Если нет, самое время наверстать упущенное:
·        изучаем учредительные документы организации – определяем функции (полномочия) или виды деятельности организации
·        вооружаемся блокнотом или электронными анкетами и идем общаться с руководителями всех подразделений –  какие процессы, существуют процессы в рамках функций или видов деятельности организации?

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



PS: продолжение следует.  


вторник, 15 мая 2018 г.

КИИ. Какие ГОСы попадают сферу КИИ?


Срок на категорирование объектов критической информационной инфраструктуры РФ скоро заканчивается ; )  а многие организации только сейчас начинают планировать мероприятия в этой части. Если с коммерческими компаниями вопрос попадания или не попадания их в сферу действия ФЗ о безопасности КИИ решается достаточно просто, то с государственными органами и учреждениями ситуация сложнее.
В ряде регионов от регуляторов проводилась рассылка на все гос. органы с требованием провести категорирование объектов КИИ. Но по факту им надо было сначала определится с попаданием с сферу КИИ, а потом уже проводить или не проводить категорирование.
Вспомним рекомендации ФСТЭК в этой части:



1.       ОКВЭД. Давайте посмотрим несколько примеров.
·         Минздрав: 84.11.21 - Деятельность органов государственной власти субъектов Российской Федерации (республик, краев, областей), кроме судебной власти, представительств исполнительных органов государственной власти субъектов Российской Федерации при Президенте Российской Федерации
·         Минтруда: 84.11.21 - Деятельность органов государственной власти субъектов Российской Федерации (республик, краев, областей), кроме судебной власти, представительств исполнительных органов государственной власти субъектов Российской Федерации при Президенте Российской Федерации
·         Минтранс: 84.11.21 - Деятельность органов государственной власти субъектов Российской Федерации (республик, краев, областей), кроме судебной власти, представительств исполнительных органов государственной власти субъектов Российской Федерации при Президенте Российской Федерации
·         Медицинская организация: 86.10 - Деятельность больничных организаций - здравоохранение. Плюс в доп. Видах деятельности есть 49 – транспорт
·         Университет: 85.22 - Образование высшее, но среди доп. Видов деятельности присутствует 72.19, 72.20 – наука
Получается, что гос. учреждения – попадают в сферу ФЗ о безопасности КИИ по ОКВЭД, а гос. органы – остаются в стороне.
Хорошо, что у гос. органов есть дополнительный классификатор ОКОГУ, именно по нему можно определить в какой сфере действует гос. орган субъекта РФ:

Но и тут не все однозначно. Например, Министерство ТЭК и ЖКХ попадает по ОКОГУ только в ЖКХ.
И что с администрациями муниципальных образований? По ОКОГУ они идут отдельным пунктом.
2.       Также гос. органы (в отличие от их подведомственных учреждений) не получают лицензии на свою деятельность – по данному фактору мы тоже не сможем их отнести к сфере КИИ.

3.       Смотрим в учредительные документы.
Зачастую самая важная часть в начале документа: “Министерство … является органом … проводящим/реализующим политику в сфере ТЭК, …”   - в сферу КИИ
С муниципальными образованиями сложнее. Приходится смотреть поглубже: “Администрация в области … транспорта и связи осуществляет следующие полномочия:” “Полномочия администрации в области охраны здоровья граждан, развития …” – в сферу КИИ

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


среда, 25 апреля 2018 г.

ПДн. В РФ введут штрафы за утечку персональных данных


Как вы, наверное, знаете в РФ фактически нет наказания за утечку персональных данных (если не считать 13.14 со штафом в 5 тыс. руб.). В то же время в Евросоюзе за утечки персональных данных предусмотрены GDPR штрафы до 20 млн. евро или 4% от оборота компании.

В Минкомсвязи решили исправить этот недочет и подготовили законопроект предусматривающий административное наказание за 2 новых состава правонарушений: 
·         8) за хранение баз данных с ПДн граждан РФ за границами РФ
·         9) за несоблюдение требований по конфиденциальности ПДн, за незаконное раскрытие или распространение ПДн – по сути, утечки персональных данных как раз попадают под этот состав
Для сравнения привожу таблицу с действующими и новыми составами правонарушений в области ПДн.



Есть правда одна проблема - штраф за утечку ПДн должен быть на порядок выше. Иначе, это не стоит внимания бизнеса.  
А есть и ещё проблема – Роскомнадзор и суды похоже совсем не хотят штрафовать нарушителей в области ПДн. По результатам анализа, который я делал к недавнему Коду ИБ, подавляющее большинство выявленных нарушений заканчивается только предупреждением.






четверг, 12 апреля 2018 г.

ИБ. Проблемы применения ЭП в организации


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

В той же отрасли здравоохранения чуть ли не всему медицинскому персоналу нужно обзавестись ЭП: электронные больничные (ПП РФ  от 16.12.2017 N 1567), рецепты, мед. справки и заключения, согласие на мед. вмешательство, документирование телемедицинских услуг в электронном виде (N 242-ФЗ от 29.07.2017), маркировка обращения лекарственных средств (№ 425-ФЗ от 28 декабря 2017 г.), проект Минздрава “Электронное здравоохранение” до 2025 г. – не менее 99% рабочих мест мед. работников оборудовано ЭП.

При этом вопросы применения, эксплуатации и обеспечения безопасности ЭП регламентируются либо документами 17-ти летней давности либо не регламентируются вовсе.

Например, не определено, должны ли ЭП быть выданы на физ. лицо или на юр. лицо? Владельцы ГИС-ов решают этот вопрос на свое усмотрение. Ответ ФСС: разрешают личные ЭП.


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


В итоге получается в организации большой кусок серых ИТ: персональные токены с СКЗИ, ключи ЭП которые не подконтрольны службе ИБ. Какой-то bring your own crypto.

Как выполнить обязательные требования ФСБ для таких СКЗИ: на каком основании принимать их на баланс? как учитывать такие ЭП и СКЗИ? как обеспечить их безопасное хранение? как заставить пользователя сдавать их на хранение?   С другой стороны, пользователи – владельцы персональных ЭП говорят: с какой стати мы будем отдавать вам наши личные токены c ЭП?

А кроме обязательных требований есть ведь ещё и актуальные угрозы:
·         ЭП сотрудника может быть несанкционированное получена или пере выпущена злоумышленником;
·         потерян или украден носитель с ключами ЭП;
·         вредоносным ПО ключи могут быть извлечены с токена;
·         если пользователь один раз и навсегда подключил свой токен к компьютеру и никогда не извлекает его – существенно повышаются шансы на выполнение каких-то несанкционированных операций с ЭП вредоносным ПО;
·         фишинг и социальная инженерия могут заставить пользователя ввести пароль и подписать какой-то ЭД.
И кстати с развитием электронного документооборота в медицине будет развиваться и рынок услуг кибер мошенников, которые могут наносить значительный ущерб: например, ущерб от поддельного больничного на месяц, ЗП = 30-500 тыс. руб. от одного случая, изменение мед. заключений в системе - может причинить ущерб здоровью пациента, поддельные рецепты - получение наркотических лекарственных средств,  подделка льготных рецептов = бесплатное получение лекарств = ущерб сравним с общим рынком лекарственных средств, а это 50 млрд руб. и  тп... 

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

Примерно такой вопрос я задавал в ФСБ России и получил следующий ответ:
Если кратко – то применение личных ЭП в рабочих системах Организации – это вне закона.

PS: ещё остаются нерешенными такие проблемные вопросы, как: текущая практика УЦ выпускать отдельные сертификаты ЭП под каждую отдельную ИС/ГИС; порядок использования ЭП в случае если врач работает сразу в нескольких Организациях - если записать несколько ключей на один токен, то приходится разрываться в его учете. Если под каждую организацию свой отдельный токен – то работникам придется на шее носить ожерелье из токенов.


пятница, 2 марта 2018 г.

ПДн. Лучшие практики ENISA по защите персональных данных


Год с небольшим назад Агенство по безопасности сетей и информации Евросоюза (European Union Agency for Network and Information Security) выпустили руководства для малых и средних компаний (SME) по защите персональных данных.

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

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

1.       На первом этапе предлагается определить уровень риска. Для этого нужно:
·         Определить процессы обработки ПДн и их особенности, а именно ответить на следующие вопросы:
                                                                          i.      В каких процессах обрабатываются ПДн (для разных процессов можно сделать разную оценку)?
                                                                         ii.      Какие типы ПДн?
                                                                       iii.      Цели обработки?
                                                                       iv.      Какие системы и технические средства участвуют в обработке
                                                                         v.      В каких местах (странах) происходит обработка
                                                                       vi.      Данный каких категорий субъектов ПДн обрабатываются
                                                                     vii.      Кто получатели обработанных данных?
·         Оценить возможный ущерб по упрощенной схеме – в совокупности оценить возможный ущерб по шкале из 4 значений для нарушений целостности, доступности и конфиденциальности ПДн (от low до very high)

·         Определить суммарную вероятность угрозы по упрощенной схеме – все угрозы объединены в 4 блока по объектам угроз:
                                                                          i.      Сетевые и технические ресурсы
                                                                         ii.      Процессы обработки информации
                                                                       iii.      Персонал и третьи лица участвующие в обработке
                                                                       iv.      Отрасли и масштаб бизнеса привлекательные для киберпреступников
Вероятность угроз предлагается оценить по шкале от Low до High, ответив на 5 вопросов по каждому блоку, например:
                                                                          i.            Обработка ПДн осуществляется с передачей через сеть Интернет?
                                                                         ii.            Возможен доступ из сети Интернет к внутренним системам?
                                                                       iii.            ИСПДн взаимодействует с другими системами?
                                                                       iv.            Могут ли посторонние лица легко получить доступ к ИТ инфраструктуре?
                                                                         v.            ИСПДн разрабатывалась или создавалась без учета лучших практик (стандартов) по безопасности?
Просто суммируя количество вопросов, с ответами “да” и “нет” мы получаем итоговую оценку вероятности угроз.

·         Определить степень риска по простой формуле

2.       На втором этапе нужно выбрать из базового каталога мер защиты – меры исходя из нашей степени риска. Без всякого анализа – просто берем меры нужного цвета.


Не показалось что вы уже видели раньше нечто подобное?
Ба – да это же более упрощенная версия методики ФСТЭК по моделированию угроз + приказ ФСТЭК 17/21/31 с базовым набором контрмер + ПП 1119 по установлению уровня защищенности.  Та же оценка исходной защищенности -> определение вреда -> определение вероятности угроз.  Только по ENISA не нужно оценивать каждую частную угрозу и подбирать ей контрмеры, вместо этого просто применяем лучшие практики одного из 3х наборов.
  
Вывод 1: В свое время представители крупных операторов критиковали ФСТЭК за негибкий подход в документах. ENISA выбрали более простой подход. Хотя он и проигрывает в гибкости, но позволяет использовать данные руководства даже в организациях с самыми небольшими компетенциями в ЗИ.

Вывод 2: Российские компании выполнившие требования ПП 1119 и документов ФСТЭК будут одновременно соответствовать и рекомендациям ENISA. Ну может с небольшим дополнением по составу мер защиты. Но подходы схожие и выбирать меры по ENISA гораздо проще.

Кстати подход с перечнем простых вопросов мы уже достаточно давно отрабатываем в системе DocShell – отвечаешь на ряд вопросов, а экспертная система сама проводит аналитику, определяет актуальные угрозы, контрмеры и готовит необходимые документы. Как показала практика это хорошо работает в организациях с небольшим уровнем компетенций в ЗИ.  


Но ENISA на этом руководстве не остановилась. Как оказалось, даже по такой простой методике у операторов есть проблемы с определением уровня вреда (Impact) и совокупной вероятности атак (Probablity) ох уж эти глупые европейцы. Несколько месяцев назад они выпустили ещё один документ, в этот раз справочник по безопасности обработки ПДн (Handbook on Security of PersonalData Processing). По сути в нем приведены 13 типовых процессов обработки ПДн из разных отраслей, и для каждой приводится анализ в соответствии с руководством (Guidelines for SMEs on the security of personal data processing) – как отвечали на вопросы, как считали ущерб, как считали вероятность угроз и какой итоговый уровень риска.

Для вас я выбрал наиболее ценную итоговую информацию:

Use case (тип процесса обработки ПДн)
Ущерб
Вероятность
Итоговый уровень риска
Платежи персоналу и отчетность (payroll management)
Medium
Low
Medium
Найм персонала (reqruitment)
Medium
Low
Medium
Управление персоналом – оценка и развитие персонала (еvaluation of employees)
Medium
Medium
Medium
Заказ и доставка товаров (Order and delivery of goods)
Medium
Medium
Medium
Маркетинг для потенциальных заказчиков (Marketing/advertising)
Low
Medium
Low
Работа с поставщиками товаров и услуг (Suppliers of services and goods)
Low
Low
Low
Контроль доступа на территорию и в помещения (Access control)
Low
Low
Low
Системы охранного видеонаблюдения (Closed Circuit Television System)
Low
Low
Low
Оказание медицинских услуг (Health Services Provision)
High
High
High
Услуги по искусственному оплодотворению (Medically Assisted Procreation)
High
Medium
High
Удаленный мониторинг пациентов (Remote monitoring of patients with chronic diseases)
High
High
High
Дошкольное образование (Early childhood)
Medium
Medium
Medium
Дистанционное высшее образование (University e-learning platform)
Medium
Medium
Medium

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

Другие статьи по теме Лучших практик.