ГОСТ Р ИСО/МЭК 27001 в медицине: инвентаризация активов и первый цикл оценки рисков

Медицинские организации как операторы персональных данных - это отдельная история. Данные специальных категорий, требования 152-ФЗ, лицензионные условия Росздравнадзора, и сверху - нарастающее давление со стороны регуляторов по части формализации системы защиты. Один из клиентов - сеть частных клиник, несколько площадок, собственная МИС - обратился с конкретным запросом: помогите выстроить СУИБ под требования ГОСТ Р ИСО/МЭК 27001. Не «хотим разобраться», а «нам сказали, что надо».

Сказали, судя по всему, внешние аудиторы на предварительной проверке. Мы взялись.

Контекст: почему ГОСТ, а не просто 152-ФЗ

152-ФЗ и приказы ФСТЭК описывают минимально необходимые технические и организационные меры. Они говорят что делать, но не как управлять безопасностью как системой. ГОСТ Р ИСО/МЭК 27001 (точнее, его российская адаптация) - это уже про управленческий цикл: политики, процессы, оценка рисков, внутренний аудит, корректирующие действия. Для организации с несколькими площадками и сложной инфраструктурой это принципиально другой уровень.

Клиент это понимал - или по крайней мере принимал на веру. Конкретные ожидания от проекта были сформулированы примерно так: «чтобы при следующей проверке вопросов не было». Рабочий критерий.

Шаг первый: инвентаризация активов

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

Картина оказалась типичной для клиник, которые росли органически:

• МИС - медицинская информационная система, основной репозиторий персданных пациентов. Два сервера, один из них - «резервный», который никто не проверял на актуальность репликации.
• PACS - архив медицинских изображений (рентген, УЗИ). Отдельный сервер на одной из площадок, физически подключённый к сети клиники напрямую, без сегментации.
• 1С:Зарплата и 1С:Бухгалтерия - тоже персданные, на отдельном сервере, доступ у главбуха и ещё пятерых человек по факту.
• Рабочие станции врачей - часть из них хранила локальные копии документов пациентов «для удобства». Неформально, никем не согласованно.
• Сетевое оборудование, резервные каналы, точки доступа Wi-Fi - всё это тоже активы, хотя в первой итерации клиент про них не думал.

Отдельного разговора заслужила история с Wi-Fi: на одной площадке в регистратуре использовалась одна точка доступа для и персонала, и пациентов. Пароль менялся последний раз года полтора назад.

Реестр активов в итоге занял несколько страниц и включал около пятидесяти позиций. По классификации - информационные, программные, физические, человеческие (персонал с привилегированным доступом). Это стандартная таксономия по приложению к ГОСТ.

Шаг второй: оценка рисков по методике ФСТЭК

Для оценки рисков мы взяли методику ФСТЭК - она доступна, она же применяется при классификации ИСПДн, клиент с ней уже соприкасался через 152-ФЗ. Логика: угроза + уязвимость + вероятность реализации + величина ущерба = уровень риска. Для каждого актива из реестра - матрица.

Сложность в том, что ГОСТ говорит «проведите оценку рисков», но конкретный метод не предписывает - выбирай сам. Методика ФСТЭК привязана к ИСПДн и слегка отличается по терминологии от того, что ожидает СУИБ. Пришлось немного адаптировать: где ФСТЭК говорит «класс ИСПДн», мы смотрели на классификацию актива по конфиденциальности/целостности/доступности - CIA-триада, которая в ISO 27001 центральная.

Из значимых находок по рискам:

• PACS без сегментации - высокий риск. Медицинские изображения технически относятся к специальным категориям персданных. Прямой доступ к серверу из общей сети клиники - это не теоретическая угроза.
• Локальные копии на рабочих станциях врачей - средний риск с высоким потенциалом роста. Данные вне контроля, резервное копирование не охватывает, при замене компьютера - возможная утечка или потеря.
• Отсутствие контроля привилегированного доступа к 1С - средний риск. Пять человек с доступом, двое из них - бывшие сотрудники, которым «забыли» закрыть учётки после увольнения. Это обнаружилось случайно в ходе инвентаризации.

Последнее - не редкость. Почти в каждом проекте по аудиту находим хотя бы одну такую учётку.

Где мы сейчас

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

СУИБ - это не разовый проект, это цикл. Первый обход всегда самый трудоёмкий: нет реестра, нет базовой документации, нет культуры фиксации изменений в инфраструктуре. После первого прохода появляется хотя бы отправная точка - от которой уже можно работать системно.

Клиент пока смотрит на всё это с некоторым скепсисом: «много бумаги, мало конкретики». Понять можно. К концу следующего этапа должны появиться конкретные задачи в трекере, а не только строчки в реестре рисков.