ГОСТРИСО 27789—2016
- коды и доверие к приложению для выявления шаблонов поведения:
- применение политики для выполнения обработки данных аудита, где политика определяет, когда и по ка
кому поводу подавать сигнал;
- необходимость в использовании следующей функциональности из системного журнала: выборочная от
правка журналов, которые соответствуют определенным (простым) шаблонам поведения в отдельное приложе
ние. которое не является частью основного сервиса аудита. Это другое приложение-*наблюдатель!) будет «смо
треть» за плохим поведением и посылать сигналы (такой тип приложения также можно использовать для проблем с
оборудованием):
- способность к извлечению основных данных из архива аудита:
- дополнительную возможность — добавить подключаемую программу для определенных видов поиска в
хранилищеданных аудита, но как минимум предоставить возможность вывести все данные из базы данных аудита на
печать, чтобы иметь возможность проводить анализ вручную на этапе 1.
Сервис уведомлений может быть простым или сложным, но он должен знать, что куда посылать. Сервис
уведомлений может быть условно зависимым сервисом. Существует два варианта этого случая, а именно:
Субьект получения медицинской помощи высокого уровня и злоумышленник слабо мотивирован.
Начальные условия угрозы. Злоумышленник, нацеленный на субьекта получения медицинской помощи, не
имеет хорошего финансирования или стимула, т. е. злоумышленник не будет долго подкупать сотрудника или нахо
диться в учреждении как сотрудник, а он непосредственно выполнит запросы в базу данных. В таких случаях ищут
только неправомерные «нормальные» транзакции. Хранилище данных аудита должно позволять делать запросы
случаев доступа no IP, PID. пользователю, промежутку времени и т. д.
Субьект получения медицинской помощи высокого уровня и злоумышленник серьезно мотивирован.
Злоумышленники для получения информации используют возможности запроса в основные базы данных, а
не только основные функции поиска интерфейса хранилища (например, средства администраторов баз данных).
Требуемая функциональность. Запрос в журналы аудита по идентификатору субьекта получения медицин
ской помощи, по времени доступа и идентификатору пользователя, общий анализ хранилища.
Хранилище данных аудита должно быть способно сбросить (в сервис отчетов) записи аудита для соответ
ствующего PID, идентификатора системы, временного окна и т. д.
Сервис отчетов получит из хранилища закодированную информацию и отобразит отчет в любом выбранном
виде (предпочтительно пригодном для использования).
Требуемый интерфейс (куда хранилищеданных аудита должно отправитьсообщение, которое будет понятно
сервису отчета и сервису анализа) (в случав, если к хранилищу подключен этот интерфейс) имеет четыре уровня:
a) события, связанные с конкретным субьектом получения медицинской помощи: нет необходимости про
сматривать любые запросы, просто ответь, есть ли события аудита, связанные с данным субьектом получения
медицинской помощи:
b
) покажи запросы, которые, как известно, вернули бы данные о субьекте получения медицинской помощи,
даже если идентификатор субьекта не указан: детерминированные запросы / запросы, не учитывающие время
(такие как запросы, хранящиеся в XDS):
c) покажи все события, удовлетворяющие диапазонам значений нескольких критериев: пользователь, вре
менное окно, тип события и набор систем, представляющих интерес (например, все входы в систему и выходы из
нее):
d) сложные запросы: пользовательские запросы, запросы по ИСО 12052 (1) (DICOM). запросы потока работ
лаборатории, которые зависят от потока работ и требуют от запрашивающего знания состояния базы данных на
момент осуществления запроса.
Уровни а). Ь) и с) могут осуществляться через прямой интерфейс к хранилищу.
Сервис анализа может быть использован для уровня d) и размещен сверху.
Возможная функциональность. Запрос в журналы аудита вручную или с использованием сервиса анализа.
Возможная новая область применения для аудита. Осуществление анализа/ сравнения’’ связи между жур
налами планирования и журналами аудита для обнаружения незапланированных/ необычных случаев доступа.
Дополнительные сервисы. Хранилище запросов/сервис анализа для выяснения существуют ли необычные
запросы?
А.З Случай принудительно обеспеченного установленного в законодательном порядке права на не
прикосновенность частной жизни (относящийся к прошлому, не активный)
В данном сценарии субъект получения медицинской помощи не хочет, чтобы его сосед, поставщик меди
цинской помощи, был осведомлен о его состоянии здоровья, субьект получения медицинской помощи может
выдать своему врачу по оказанию первичной медицинской помощи разрешительный документ, постановляющий
полностью закрыть доступ к его медицинской карте со стороны поставщика медицинских услуг. Через несколько
недель должностное лицо, ответственное за обеспечение конфиденциальности врача по оказанию первичной
медицинской помощи, получает сигнал о том. что сосед пытался получить доступ к картам, нарушая политику
учреждения, и что в доступе было отказано. Должностное лицо, ответственное за обеспечение конфиденциаль
ности. оповещает субъекта получения медицинской помощи о попытке получения доступа и о том. что она была
неуспешной.
28