вторник, 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

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

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


воскресенье, 11 февраля 2018 г.

ИБ. Требования ФСБ к средствам защиты КИИ

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

Но недавно опубликованный проект приказа ФСБ России «Об утверждении Требований к средствам, предназначенным для обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты» наконец разъяснил, что мы должны увидеть на значимых объектах КИИ для подключения к ГосСОПКА.

Если не учитывать средства поиска атак на сетях электросвязи (которые требуются только для операторов сетей) то для остальных значимых субъектов КИИ необходимы следующие средства (я разделил их на 5 типа, хотя некоторые могут сочетаться в одном решении):
·         средства обнаружения компьютерных атак
·         средства предупреждения компьютерных атак
·         средства учета угроз БИ
·         средства реагирования на компьютерные инциденты
·         средства криптографической защиты обмена информацией

Как обычно я немного упростил формулировки требований и отобразил в виде майнд-карт, для того чтобы можно было быстро, одним взглядом окинуть новые требования ФСБ России.
Средства обнаружения компьютерных атак – под этим ФСБ России подразумевает не IDS, не IPS и не какие-то “сенсоры”. Тут требуется сбор, обработка, автоматический анализ событий ИБ и выявление инцидентов – традиционно такие средства называют SIEM (security information and event management). Тут нет никаких требований по передачи информации в НКЦКИ. Миллионы “сырых” событий ИБ – это не интересно.  

Средства предупреждения компьютерных атак – одна часть требований связанна со сбором информации об инфраструктуре, сбором информации об уязвимостях и недостатках в настройке. Эти функции как правило реализуются сканнерами защищенности. Вторая часть требований связана с получением так называемой справочной информации (базы репутаций IP, адреса серверов бот-сетей и т.п.), а также с получение информации об угрозах безопасности информации – как правило такие функции выполняются отдельными средствами или сервисами предоставление актуальной информации об угрозах.   Тут хочу отдельно отметить требования выгружать в НКЦКИ обобщенную информацию об уязвимостях и автоматически обмениваться с НКЦКИ информацией об угрозах – поэтому не подойдут имеющиеся на рынке готовые решения, должны появится новые решения, заточенные под ГосСОПКА.  

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

Для СКЗИ одно требование – они должны быть сертифицированными.  
Также в документе приводятся общие требования к средствам. Наиболее интересные из них – возможность модернизации и технической поддержки силами исключительно российских компаний. Это фактически исключает возможность использовать иностранные решения для защиты критических объектов КИИ.

Ниже общая схема взаимодействия указанных средств.  



Ещё недавно мы возмущались объемным требованиям к лицензиатам ФСТЭК оказывающим услуги по мониторингу (SOC-и). Сейчас мы пришли к ситуации, когда всем владельцам значимых объектов КИИ (а их может быть тысячи) придется создавать собственные SOC-и в обязательном порядке. Ведь указанные типы средств и функций составляют основу центров мониторинга и реагирования на инциденты.    


PS: Напоследок несколько замечаний к документу:
·         В приказе ФСБ России, в отличие от документов ФСТЭК, приводятся конкретные детальные требования к средствам, но не предусмотрено какой-либо системы оценки средств, указанным требованиям.
Как конечному пользователю узнать, соответствует ли его набор средств указанным требованиям? Запрашивать официальные письма у производителя? Проводить собственные испытания?  
Или в соответствии с другим приказом ФСБ России отправлять перечень предполагаемых средств на согласование с КНЦКИ и в таком случае положительный ответ будет подтверждением соответствия указанных средств требованиям.  Тогда надо запасаться временем на несколько попыток (по 45 календарных дней каждая)
·         Не совсем понятно, как подтвердить возможность осуществления модернизации средств силами исключительно российских компаний? Заранее проводить опрос среди интеграторов? Открытый конкурс на модернизацию?
·         Как можно проверить и подтвердить отсутствие НДВ кроме сертификации?  
·         Не совсем понятно, подойдет ли в свете указанного ПО с открытым исходным кодом (под требования ФСТЭК к лицензиатам вполне подходили gosint, spiderfoot)? Если субъект КИИ самостоятельно будет оказывать себе поддержу ПО, проводить модернизацию, сам оформит для себя формуляр и руководство администратора?
·         Некоторые требования к средствам представляются избыточными. Например, задавая себе вопрос, “действительно ли указанная функция необходима для эффективного обнаружения, предотвращения и реагирования на атаки?” не для всех функций можно ответить положительно. Некоторые – скорее для удобства или для некоторых исключительных ситуаций.  Например, настройка и контроль SLA по реагированию на инциденты или расчет прогнозов на основе ретроспективного анализа данных.