СЗПДн. Анализ защищенности

В связи с тем, что меры контроля / анализа защищённости персональных данных входят в базовые наборы мер защиты начиная с УЗ4 – УЗ3, большинство операторов персональных данных обзавелось сканерами защищенности. Иногда сталкиваюсь со следующими вопросом: а нужно ли вообще запускать этот сканер, и если да, то с какой периодичностью и что именно проверять.
Давайте попробуем разобраться:
· сканеры используется для реализации группы мер по контролю (анализу) защищенности персональных данных (АНЗ) обязательных в соответствии с приказом ФСТЭК России №21 от 18 февраля 2013 г.
· посмотрим, имеется ли в нормативно-правовых актах РФ какие-то обязательные требования к порядку или периодичности проведения сканирования защищенности:
Приказ ФСТЭК России №21
“8.8. Меры по контролю (анализу) защищенности персональных данных должны обеспечивать контроль уровня защищенности персональных данных, обрабатываемых в информационной системе, путем проведения систематических мероприятий по анализу защищенности информационной системы и тестированию работоспособности системы защиты персональных данных.
АНЗ.1 Выявление, анализ уязвимостей информационной системы и оперативное устранение вновь выявленных уязвимостей
АНЗ.2 Контроль установки обновлений программного обеспечения, включая обновление программного обеспечения средств защиты информации
АНЗ.3 Контроль работоспособности, параметров настройки и правильности функционирования программного обеспечения и средств защиты информации
АНЗ.4 Контроль состава технических средств, программного обеспечения и средств защиты информации”
ГОСТ Р 51583-2014 порядок создания АС в защищенном исполнении

Больше НПА, содержащих требования к анализу защищенности найти не удалось
Значит в нормативно-правовых актах РФ не содержится требований к порядку и периодичности проведения сканирований защищенности, соответственно параметры настройки профилей сканирования, периодичности анализа уязвимостей определяется оператором самостоятельно
· как же ему определить этот порядок и периодичность?
· скорее всего нужно исходить из особенностей и критичности информационной системы, состава используемого программного обеспечения и внутренних правил обновления программного обеспечения;
· также необходимо понимать, что по результатам сканирования формирует отчет по уязвимостям, который ещё необходимо отработать – устранить уязвимости и установить недостающие обновления. Нет никакого смысла проводить сканирование чаще, чем ответственные лица успевают обработать отчет и устранить уязвимости. Периодичность сканирования > среднего времени на обработку отчета по уязвимостям
· при определении порядка и периодичности сканирования оператор информационной системы может руководствоваться собственной экспертизой в области информационной безопасности, опытом проведения мероприятий по анализу защищенности, рекомендациями внешних экспертов и лицензиатов ФСТЭК, а также документами, носящими статус “рекомендованных” или “лучших практик”
· при этом необходимо учитывать, что меры по анализу защищенности должен быть систематическими (пункт 8.8 приказ ФСТЭК №21) и должны быть достаточными для нейтрализации актуальных угроз (пункт 2 Постановление правительства №1119)
· посмотрим, что есть в лучших методических документах и лучших практиках:
ГОСТ Р ИСО/МЭК 27002-2012
“12.6 Менеджмент технических уязвимостей
Цель: Снизить риски, являющиеся результатом использования опубликованных технических уязвимостей.
Менеджмент технических уязвимостей следует осуществлять эффективным, систематическим и повторяемым способом, с проведением измерений с целью подтверждения его эффективности. Эти соображения должны касаться эксплуатируемых систем и любых других используемых прикладных программ.
12.6.1 Управление техническими уязвимостями
Мера и средство контроля и управления
Необходимо получать своевременную информацию о технических уязвимостях используемых информационных систем, оценивать незащищенность организации в отношении таких уязвимостей и принимать соответствующие меры для рассмотрения связанного с ними риска.
Рекомендация по реализации
Постоянно обновляемая и полная опись активов (см. 7.1) является предпосылкой эффективного менеджмента технических уязвимостей. Специальная информация, необходимая для поддержки менеджмента технических уязвимостей, включает в себя информацию о поставщике программного обеспечения, номерах версий, текущем состоянии развертывания (например, какое программное обеспечение установлено на каких системах) и специалисте(ах), отвечающем(их) в организации за программное обеспечение.
Аналогично, своевременное действие должно предприниматься в ответ на выявление потенциальных технических уязвимостей. Для создания эффективного процесса менеджмента в отношении технических уязвимостей необходимо выполнять следующие рекомендации:
a) в организации необходимо определять и устанавливать роли и обязанности, связанные с менеджментом технических уязвимостей, включая мониторинг уязвимостей, оценку риска проявления уязвимостей, исправление программ (патчинг), слежение за активами и любые другие координирующие функции;
b) информационные ресурсы, которые будут использоваться для выявления значимых технических уязвимостей и обеспечения осведомленности о них, следует определять для программного обеспечения и другой технологии на основе списка инвентаризации активов (см. 7.1.1); эти информационные ресурсы должны обновляться вслед за изменениями, вносимыми в опись, или когда найдены другие новые или полезные ресурсы;
c) необходимо определить временные параметры реагирования на уведомления о потенциально значимых технических уязвимостях;
d) после выявления потенциальной технической уязвимости организация должна определить связанные с ней риски и действия, которые необходимо предпринять; такие действия могут включать внесение исправлений в уязвимые системы и (или) применение других мер и средств контроля и управления;
e) в зависимости от того, насколько срочно необходимо рассмотреть техническую уязвимость, предпринимаемое действие следует осуществлять в соответствии с мерами и средствами контроля и управления, связанными с менеджментом изменений (см. 12.5.1), или следуя процедурам реагирования на инциденты информационной безопасности (см. 13.2);
f) если имеется возможность установки патча, следует оценить риски, связанные с его установкой (риски, создаваемые уязвимостью, необходимо сравнить с риском установки патча);
g) перед установкой патчи следует тестировать и оценивать для обеспечения уверенности в том, что они являются эффективными и не приводят к побочным эффектам, которые нельзя допускать; если нет возможности установить патч, следует рассмотреть другие меры и средства контроля и управления, например:
1) отключение сервисов, связанных с уязвимостью;
2) адаптацию или добавление средств управления доступом, например, межсетевых экранов на сетевых границах (см. 11.4.5);
3) усиленный мониторинг для обнаружения или предотвращения реальных атак;
4) повышение осведомленности об уязвимостях;
h) в контрольный журнал следует вносить информацию о всех предпринятых процедурах;
i) следует регулярно проводить мониторинг и оценку процесса менеджмента технических уязвимостей в целях обеспечения уверенности в его эффективности и действенности;
j) в первую очередь следует обращать внимание на системы с высоким уровнем риска.
Дополнительная информация
Правильное функционирование процесса менеджмента технических уязвимостей играет важную роль для многих организаций, поэтому процесс должен подвергаться регулярному мониторингу. Для обеспечения уверенности в том, что потенциально значимые технические уязвимости выявлены, важна точная инвентаризация.
Менеджмент технических уязвимостей может рассматриваться как подфункция менеджмента изменений и в качестве таковой может воспользоваться процессами и процедурами менеджмента изменений (см. 10.1.2 и 12.5.1).
Поставщики часто испытывают на себе значительное давление, заключающееся в требовании выпускать патчи в кратчайшие сроки. Поэтому патч не может решить проблему адекватно и может иметь побочные эффекты. К тому же, в некоторых случаях, если патч был однажды применен, деинсталлировать его может быть нелегко.
Если адекватное тестирование патчей провести не удается, например по причине затрат или отсутствия ресурсов, можно рассмотреть задержку в осуществлении внесения изменений, чтобы оценить связанные с этим риски, основанные на опыте других пользователей.”
РС БР ИББС-2.6-2014
“10. Стадия эксплуатации
10.1. Основными задачами на стадии эксплуатации в части обеспечения ИБ являются:
— периодическая оценка защищенности АБС (проведение мероприятий по выявлению типичных уязвимостей программных компонентов АБС, тестирование на проникновение);
10.2. Периодичность проведения работ по оценке защищенности определяется решении
ем организации БС РФ. Для АБС, используемых для реализации банковского платежного тех-
нелогического процесса, рекомендуется проведение комплексной оценки защищенности не
реже одного раза в год”
методический документ ФСТЭК России “Меры защиты информации в государственных информационных системах”, который может применяться и для обеспечения безопасности персональных данных по решению оператора
“АНЗ.1 ВЫЯВЛЕНИЕ, АНАЛИЗ И УСТРАНЕНИЕ УЯЗВИМОСТЕЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ
Выявление (поиск), анализ и устранение уязвимостей должны проводиться на этапах создания и эксплуатации информационной системы. На этапе эксплуатации поиск и анализ уязвимостей проводится с периодичностью, установленной оператором. При этом в обязательном порядке для критических уязвимостей проводится поиск и анализ уязвимостей в случае опубликования в общедоступных источниках информации о новых уязвимостях в средствах защиты информации, технических средствах и программном обеспечении, применяемом в информационной системе.
Требования к усилению АНЗ.1:
2) оператор должен уточнять перечень сканируемых в информационной системе уязвимостей с установленной им периодичностью, а также после появления информации о новых уязвимостях;”
· руководствуясь методическим документом ФСТЭК — анализ защищенности необходимо проводить в обязательном порядке после опубликования информации о критической уязвимости или обновлении;
· для ОС Windows такие уязвимости появляются в среднем ежемесячно;
· по моему мнению для обеспечения нейтрализации актуальных угроз анализ защищенности с использованием сканеров необходимо проводить не реже чем ежеквартально
· рекомендую начинать с этой периодичности, далее смотреть по времени отработки отчетов, устранения уязвимостей, установки обновлений – увеличивать или уменьшать частоту анализа
· в качестве старта при определении что и как проверять, можно использовать приложение 3 Рекомендации к проведению оценки защищенности к РС БР ИББС-2.6-2014 – раздел 2 “Выявление известных уязвимостей”

Часть 1. Платформа СППР Универсальные алгоритмы

Приветствую, уважаемое сообщество!
Забегая вперед прошу прощения у тех, кто ожидает новизны или революционных идей. Их тут нет. Но есть вполне хорошая прикладная система.
Системы поддержки принятия решений сейчас набирают обороты. Причем я не буду особо останавливаться на перечислении способов реализации. Оговорюсь только об основных свойствах. Я бы очень упрощенно и обобщенно назвал эти системы вероятностными. То есть они выдают рекомендации с известной долей вероятности используя накопленную и проанализированную статистику. Не скажу что это плохо. Тема BigData и Machine learning нынче в тренде. Так же эти системы работают по принципу черного ящика. Поэтому проверить достоверность работы заложенной модели не всегда можно выявить.
Я же постараюсь описать систему поддержки принятия решений основанную на несколько другом, кто-то может скажет и архаичном, принципе – условно назовем его оценочным. То есть система моделирует принцип того как человек реально действует – оценивает ситуацию и принимает решение на основе сделанной оценки в этой конкретной ситуации. А не на обобщенных данных.
Простейший пример: Вы входите в комнату. Оцениваете светло или нет. Если темно, то включаете свет и проходите в комнату. Если светло, то сразу проходите в комнату. И новая оценка…
Упрощенно примерно такой же подход использует и описываемое мной решение. То есть для принятия решения не проводится анализ на основании BigData с выявлением неких тенденций и закономерностей. А оценивается конкретная ситуация. И на основании конкретной оценки принимается вполне конкретное решение.
Чтобы избежать сильно большой критики могу сказать, что BigData очень даже полезны. И данные, полученные на их основе, должны использоваться в СППР. Но СППР не должна опираться на BigDta, как на фундаментальную основу. Это тема для отдельной дискуссии.

Предыстория

В основе решения лежит методика Частных алгоритмов действий врача. В данном случае добавлена абстракция и расширена сфера применения.
Способов алгоритмичных описаний много. Далеко не все бывают удобными. И уж тем более далеко не все могут претендовать на то, чтобы ими можно было одинаково хорошо описать экспертную систему. Да еще и в различных профессиональных областях.
Мне лично понравилась достаточно простая модель описания, которая использует 3 основных элемента: вопрос, ответ и рекомендация. Примечательно, что данная методика позволила описать наиболее сложную с точки зрения формализации отрасль – медицину. То есть у данной методики было успешное практическое применение. И еще немаловажно то, что при наличии инструментария, логику СППР могут создавать специалисты из своих профессиональных областей без привлечения разработчиков.
Для начала работы был взят на бумажном носителе алгоритм для специализированной бригады скорой помощи «Комы, Отравления, Коллапсы». Мне его в руки так и не отдали. Только временное использование. По сути это был набор карточек с инструкциями.
Идеологически хотелось получить решения для различных профессиональных областей кроме медицины. Поэтому было принято решение разрабатывать некую платформу, с помощью которой можно будет как создавать алгоритмы (создавать логику СППР), так и использовать созданную СППР. Был выбран путь не противопоставления системы уже существующим решениям, а наоборот, создать как дополнение, которое позволяет расширять функционал. То есть в системе должен быть API, который бы позволил встраиваться в существующие системы.

Реализация

Так и появилась концепция платформы СППР Универсальные алгоритмы. Которая стоит на 3-х китах:
• Методика создания и описания алгоритмической модели
• Алгоритм-Дизайнер – приложение для визуального создания и редактирования алгоритмов СППР
• Алгоритм-Навигатор – web-приложение, которое реализует использование логической модели СППР.
Всем понятно, что речь идет о графовой модели. Если честно не хотелось изобретать велосипед, но один недоброжелатель своим язвительным замечанием подтолкнул к тому чтобы нарисовать создаваемую модель. Поэтому было взятое готовое решение Graphviz, которое прекрасно справляется с такой задачей. Плюсом еще является и то, что данный пакет позволяет создавать интерактивные графы с URL.
Отрисовывать граф целого алгоритма нет смысла, иначе он не поместится на огромной стене. Поэтому был выбран путь создания графа для каждой ситуации. Если какой-то элемент ведет в другую ситуацию, то это так и отображается на графе.

Алгоритм-Дизайнер

Алгоритм-Дизайнер позволяет создавать логическую модель согласно методологии. Алгоритм по содержанию делится на ситуации. А в ситуациях реализуется модель рассуждений.
Алгоритм-Дизайнер – Windows приложение. Пока что не придумана концепция как еще можно реализовать весь функционал такого приложения в виде альтернативного решения (например web).

На скриншоте обозначены основные элементы в Алгоритм-Дизайнере:

  1. • Меню и панель инструментов – тут пояснения не требуются
  2. • Дерево алгоритма (дерево решений) – наиболее удобное отображение структуры алгоритма
  3. • Область для работы с «родительскими» элементами узла.
  4. • Область для отображения дочерних элементов узла.
  5. • Область для заполнения «Рекомендаций» и «пояснительных комментариев» — в этой области вносится текст рекомендации. Так же для остальных элементов позволяется вносить пояснительную или справочную информацию. Эта информация превращает алгоритм в справочное пособие для пользователя, когда ему может быть не понятен смысл предлагаемого на выбор элемента. На примере Алгоритм-Навигатора будет показан способ отображения таких комментариев.
  6. • Область «Репозиторий» — вспомогательный инструмент для хранения наиболее часто встречающихся логических конструкций. Чтобы не вводить повторно можно просто копировать из репозитория. И при изменении данных в репозитории, они автоматически реплицируются на все связанные элементы в дереве алгоритма.

Как уже упоминалось, на самом деле структура алгоритма представляет собой графовую модель. Но работать на прикладном уровне удобно с древовидной структурой. И логически разделять общую модель данных удобнее в древовидном представлении.
Основной логический элемент – Алгоритм.

Алгоритм может содержать вложенные элементы такого же типа. То есть элемент алгоритма «Скорая помощь» может содержать в себе элементы-алгоритмы для специализированных бригад скорой помощи.
Далее Алгоритм делится на Ситуации. Ситуация существует для того чтобы разделить Алгоритм на логические разделы. Это позволяет выделить отдельную логическую задачу из общего алгоритма.

Примечание: В терминах программирования можно считать, что Алгоритм – это программа, а Ситуация – подпрограмма, процедура или функция.
Естественно, что все элементы взаимосвязаны. Поэтому логические элементы Алгоритма позволяют устанавливать связи и переходы между Ситуациями.
Далее идет элемент – Вопрос. Система работает по принципу оценки «текущей ситуации». Поэтому она постоянно работает в режиме задавания вопроса и получения ответа от пользователя.
Ответ – логический элемент, связанный с вопросом. То, что пользователь будет выбирать для оценки «текущей ситуации»
Рекомендация – логический элемент, который на основании оценки предлагает, или требует выполнить некие действия. Рекомендации делятся на простые и те, что устанавливают время на исполнение. То есть для таких рекомендаций определяется временной промежуток, в течении которого должно быть выполнено действие прежде чем будет продолжено движение по алгоритму – минимальный и максимальный интервал.
Еще используется вспомогательный элемент – Закрыть линию. Это было продиктовано тем, что хотелось визуально выделить момент, когда заканчивается линия рассуждений. Этот элемент может использоваться многократно в алгоритме. В данном случае есть избыточность. Но ею лучше пренебречь ради наглядности.

Для чего понадобились «Работа с родительскими и дочерними элементами»?

Алгоритм – это граф. Но отображение древовидное. Следовательно, в дереве отображается только один родительский элемент узла. Что не отображает реальное положение вещей. Так же в дереве не видны все дочерние узлы, если они находятся в других ветках дерева. Так же нужен был механизм для установки таких связей. Поэтому был реализован функционал назначения «Родителя» для узла. Дочерние элементы – это просто информативное отображение.
Для упрощения просмотра и тестирования в дереве при двойном клике на элементе осуществляется переход на 1-й дочерний узел. В том числе и на тот, который установлен в другой ветке. Обратное движение по дереву к родителям осуществляется двойным кликом в поле отображения дочерних узлов.
Логическая модель редактируема и открыта. Но визуальное представление делает ее еще более наглядной и понятной для более широкой аудитории без специальных знаний. В качестве средства визуализации был выбран инструмент Graphviz. Потому что строит диаграммы быстро, бесплатный и кроссплатформенный. Есть еще ряд преимуществ. Одно из них – это возможность строить интерактивные диаграммы. То есть каждый элемент может содержать в себе URL.
Отображать решено было по ситуациям. Так как весь алгоритм представляет собой довольно большое полотно, в котором трудно разобраться. Элементы диаграмм содержат в себе отображение всех текстов. Это касается Рекомендаций и дополнительных справочных комментариев-пояснений для Ответов. Это позволяет полностью отразить логическое и содержательное наполнение системы.
Для реализации были использованы Delphi, СУБД Firebird, Graphviz. Привязка к СУБД продиктована использованием компонента. Для использования в web-приложении Алгоритм-Навигатор база конвертировалась в MySql, SQLite и т.д.

Алгоритм-Навигатор

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

Я выбирал некоторое время способ реализации Алгоритм-Навигатора. Известно было, что это должно быть web-приложение, что должна быть возможность запуска на Linux и должен быть API для встраивания в другие информационные системы. Потому что изначально планировалось не противопоставлять систему уже существующим, а наоборот дополнять.
Для разработки был выбран Python. Фреймворк bottle (планирую все перенести на django). Тут не нужно особых пояснений. Я не являюсь специалистом в дизайне и занимаюсь проектом сам. Поэтому был взят готовый набор для front-end titon.io, который обладает всем необходимым функционалом.
Я верстал страницы так как они должны были выглядеть. А потом на их основе делал шаблоны.
Поскольку хотелось иметь функционал генерации диаграмм и в Алгоритм-Навигаторе, то был использован пакет pydot.

Порядок и принцип работы

Алгоритм-Дизайнер позволяет создавать логическую модель. В принципе ее можно начинать использовать сразу после создания нескольких шагов.
По мере прохождения по алгоритму все шаги пользователя фиксируются. По ним происходит восстановление протокола. Это еще одна особенность данной методологии – при прохождении по алгоритму формируется протокол рассуждений специалиста. Который может быть использован как документ. Я планировал копирование текста в заявки системы сервис-деск.

Пример API


UID – ID пользователя алгоритма.
OID – ID объекта. В данном случае может быть любой объект. В медицине – пациент.
Parameter list – набор параметров типа name=value для макроподстановки в текстах алгоритма. Как пример имя, название компании, название продукта.
Algorithm entry point – точка входа в алгоритм. Не всегда нужно начинать с самого начала. При вызове алгоритма из другой системы можно выбрать точку в алгоритме (ситуацию) с которой будет начата работа.

Примеры применения

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

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

Скрипты разговоров и продаж услуг.

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

В своей работе так же описал процесс внедрения:
Предшествующие связанные публикации:
Часть 2. СППР Универсальные алгоритмы – Алгоритм для службы поддержки
Часть 3. Чат-бот Telegram на ядре логики СППР (в песочнице)

Рубрики: IT

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *