Приложение А (справочное). Сценарии аудита

Приложение А
(справочное)

Сценарии аудита

А.1 Общие сведения

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

А.2 Случай недовольной знаменитости

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

Субъект получения медицинской помощи, обнаружив свое фото на обложке известной газеты, жалуется должностному лицу, ответственному за обеспечение конфиденциальности. Должностное лицо, ответственное за обеспечение конфиденциальности, использует хранилище данных аудита для просмотра всех случаев доступа к медицинской карте субъекта получения медицинской помощи и обнаруживает, что один случай произошел за пределами предусмотренного графиком времени проверки. В то время работали две медсестры, и после определенного расследования одна из них созналась, и ей был объявлен выговор.

Данный сценарий зависит от ведения записей аудита, а также от процесса выполнения аудита деятельности, которая была записана. Он должен включать в себя:

- создание записи/журнала аудита;

- передача (включая ожидание в очереди и локальные области хранения) записи/журнала аудита в хранилище;

- получение записи/журнала аудита;

- хранение записи/журнала аудита;

- аудит осуществления запросов/поисков для определения того, что произошло.

Это, в свою очередь, требует:

- поиск по соответствию даты и

- системы аудита, которые, по меньшей мере:

- идентифицируют каждого пользователя, который, согласно отчетам, просматривал карту данного субъекта получения медицинской помощи,

- идентифицируют каждый случай доступа данного пользователя к карте любого субъекта получения медицинской помощи и

- идентифицируют каждый случай доступа узла к карте субъекта получения медицинской помощи;

- соответствие с RFC 3881 для обеспечения возможности поиска;

- соответствие с ИСО 12052 [1] (DICOM) в случае аудита технологического процесса рентгенологического исследования.

Вышеуказанный сценарий охватывает ряд возможных случаев для субъектов получения медицинской помощи с конкретными потребностями в аудите:

- субъекты получения медицинской помощи, в случае которых злоумышленник был серьезно мотивирован, например, объект получения медицинской помощи, который, сам того не желая, подвергается преследованию;

- жертва насилия:

- объект получения медицинской помощи уведомляет должностное лицо, ответственное за обеспечение конфиденциальности, о необходимости закрыть доступ к персональной медицинской информации путем использования для этой информации маркировки, отличной от маркировки, используемой для идентификации VIP пациентов (у администрации может быть стандартный набор маркировок для идентификации данных такого типа субъектов). Для аудита в данном случае не стоит записывать, что объект получения медицинской помощи является "жертвой насилия", а скорее стоит записать, что должностному лицу, ответственному за обеспечение конфиденциальности, или должностному лицу, ответственному за обеспечение защищенности был отправлен сигнал о нарушении. Нам необходимо записать "код" данного нарушения, а не явно идентифицировать его простым текстом в записи аудита.

Для аудита можно стандартизировать:

- категории сигналов тревоги системы защиты - необходим механизм отправки сигналов тревоги. Можно применить сигнал тревоги для сценария возможного преследования/незаконной деятельности, а также более мощные сигналы для сценариев, рассмотренных ниже;

- коды и доверие к приложению для выявления шаблонов поведения;

- применение политики для выполнения обработки данных аудита, где политика определяет, когда и по какому поводу подавать сигнал;

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

- способность к извлечению основных данных из архива аудита;

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

Сервис уведомлений может быть простым или сложным, но он должен знать, что куда посылать. Сервис уведомлений может быть условно зависимым сервисом. Существует два варианта этого случая, а именно:

Субъект получения медицинской помощи высокого уровня и злоумышленник слабо мотивирован.

Начальные условия угрозы. Злоумышленник, нацеленный на субъекта получения медицинской помощи, не имеет хорошего финансирования или стимула, т.е. злоумышленник не будет долго подкупать сотрудника или находиться в учреждении как сотрудник, а он непосредственно выполнит запросы в базу данных. В таких случаях ищут только неправомерные "нормальные" транзакции. Хранилище данных аудита должно позволять делать запросы случаев доступа по IP, PID, пользователю, промежутку времени и т.д.

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

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

Требуемая функциональность. Запрос в журналы аудита по идентификатору субъекта получения медицинской помощи, по времени доступа и идентификатору пользователя, общий анализ хранилища.

Хранилище данных аудита должно быть способно сбросить (в сервис отчетов) записи аудита для соответствующего PID, идентификатора системы, временного окна и т.д.

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

Требуемый интерфейс (куда хранилище данных аудита должно отправить сообщение, которое будет понятно сервису отчета и сервису анализа) (в случае, если к хранилищу подключен этот интерфейс) имеет четыре уровня:

a) события, связанные с конкретным субъектом получения медицинской помощи: нет необходимости просматривать любые запросы, просто ответь, есть ли события аудита, связанные с данным субъектом получения медицинской помощи;

b) покажи запросы, которые, как известно, вернули бы данные о субъекте получения медицинской помощи, даже если идентификатор субъекта не указан: детерминированные запросы/запросы, не учитывающие время (такие как запросы, хранящиеся в XDS);

c) покажи все события, удовлетворяющие диапазонам значений нескольких критериев: пользователь, временное окно, тип события и набор систем, представляющих интерес (например, все входы в систему и выходы из нее);

d) сложные запросы: пользовательские запросы, запросы по ИСО 12052 [1] (DICOM), запросы потока работ лаборатории, которые зависят от потока работ и требуют от запрашивающего знания состояния базы данных на момент осуществления запроса.

Уровни а), b) и с) могут осуществляться через прямой интерфейс к хранилищу.

Сервис анализа может быть использован для уровня d) и размещен сверху.

Возможная функциональность. Запрос в журналы аудита вручную или с использованием сервиса анализа.

Возможная новая область применения для аудита. Осуществление анализа/сравнения/связи между журналами планирования и журналами аудита для обнаружения незапланированных/необычных случаев доступа.

Дополнительные сервисы. Хранилище запросов/сервис анализа для выяснения существуют ли необычные запросы?

А.3 Случай принудительно обеспеченного установленного в законодательном порядке права на неприкосновенность частной жизни (относящийся к прошлому, не активный)

В данном сценарии субъект получения медицинской помощи не хочет, чтобы его сосед, поставщик медицинской помощи, был осведомлен о его состоянии здоровья, субъект получения медицинской помощи может выдать своему врачу по оказанию первичной медицинской помощи разрешительный документ, постановляющий полностью закрыть доступ к его медицинской карте со стороны поставщика медицинских услуг. Через несколько недель должностное лицо, ответственное за обеспечение конфиденциальности врача по оказанию первичной медицинской помощи, получает сигнал о том, что сосед пытался получить доступ к картам, нарушая политику учреждения, и что в доступе было отказано. Должностное лицо, ответственное за обеспечение конфиденциальности, оповещает субъекта получения медицинской помощи о попытке получения доступа и о том, что она была неуспешной.

Обязательная функциональность. Формирование списка случаев доступа к медицинским картам через логин врача/пользователя; формирование/демонстрация списка неуспешных попыток доступа; и формирование сигналов тревоги в момент, когда фиксируется событие, не уполномоченное разрешительными документами.

- Любой случай использования (низкого/высокого уровня) требует возможности ретроспективного анализа аудита: "дайте мне данные, и я их проанализирую".

- Данный сценарий существует только для установления того, чтобы аудит мог быть "запрошен" по идентификатору процесса (PID), а также по успешным/неуспешным результатам события.

Проблемы:

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

- неавторизованные попытки получить доступ, как указано выше, соседом поставщика медицинских услуг, должны либо отслеживаться приложением, либо проявляться как запросы от неожиданного источника;

- "сервис-наблюдатель" может иметь белый список смотровых кабинетов, которые могут предварительно просматривать данные и отправлять уведомление, если запрос поступает от неожиданного источника и/или в нарушение разрешительных документов или документов по получению доступа. Определение того, когда и по какому поводу сервис-наблюдатель оповещает, относится к вопросам местной политики.

А.4 Случай взломанного сервера

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

Это другой тип сервиса приложения, а также другой тип аудита.

Эти записи аудита будет создавать защитная система. Журналы маршрутизатора не характерны для здравоохранения.

Обязательная функциональность. Необходимо "архитектурно" соответствовать тому, как профессиональная IT-индустрия решает эту проблему.

Факт отправления сигнала тревоги также подлежит аудиту.

А.5 Случай уполномоченного пользователя, который злоупотребляет этими полномочиями

Некое лицо просит своего партнера устроиться на работу в качестве регистрирующего агента в новой информационной Системе/Регистре поставщиков по лекарственным средствам и затем зарегистрировать это лицо и других лиц как врачей с правами электронного назначения, чтобы они могли незаконно назначать лекарственные средства.

Часто единственным способом раскрыть такой тип событий является естественная подозрительность или случайный анализ журналов аудита.

Как можно своевременно на это реагировать? Может ли аудит и мониторинг помочь обнаружить необычные случаи назначения подлежащих контролю лекарственных средств? (Резкий скачок в назначении морфина?) Наименьшее, чем может помочь система, - это немедленное предоставление доказательств несанкционированных регистраций при обнаружении пользователя, злоупотребляющего полномочиями, а также список всех "врачей", зарегистрированных при использовании учетной записи пользователя, злоупотребляющего полномочиями.

Обязательная функциональность. Формировать список успешных событий регистрации пользователя.

Дополнительная функциональность. Делать перекрестные ссылки между сервисом аудита и другими сервисами для определения области нарушения.

Потенциальная функциональность для сервиса ID Mgmt. Сверять личность в регистре поставщиков с учетными данными поставщиков.

А.6 Случай неправильно направленных результатов исследований

Субъект получения медицинской помощи ждал свои результаты лабораторных исследований уже в течение двух недель, когда врач сообщил ему, что при использовании новой информационной системы лаборатории результаты должны быть доступны менее чем через 48 часов. Когда субъект получения медицинской помощи звонит в офис своего врача, обнаруживается, что в офисе имеется запись о заказе результатов из лаборатории, но не сами результаты. Медсестра звонит в лабораторию и спрашивает, что случилось с результатами исследований. Лаборатория проверяет свои журналы аудита и находит номер полученного заказа результатов из лаборатории, а также результаты лабораторных испытаний, которые были отправлены в ответ. Лаборант проверяет, куда были отправлены результаты и понимает, что результаты были отправлены в офис другого врача. Лаборант пересылает результаты правильному получателю, и проверяет ARR, чтобы убедиться, что результаты были повторно отправлены должным образом (успешный результат события и правильный получатель) и звонит медсестре, чтобы узнать, получила ли она их. Медсестра звонит субъекту получения медицинской помощи, чтобы сообщить ему, что результаты получены.

Некоторые дополнительные уточняющие данные должны быть добавлены в журналы аудита для поддержки этого сценария, такие как: номера для отслеживания заказа, номера отчетов и т.д. Необходимо будет установить баланс между добавлением в журналы слишком большого объема уточняющих данных и анализом, который может устанавливать связь между заказами с запросами в журнале аудита. Возникает вопрос о том, необходимо ли сделать это при помощи средств управления потоком работ или же при помощи журнала аудита? Рентгенология делает это по двум направлениям при помощи средств управления потоком работ (подтверждение отправки, получения и прочтения отчетов, а также номера контейнеров и т.д.). Предоставление отчетов при помощи средств управления потоком работ могут обрабатываться с помощью отдельного аудита - предоставление отчетов лаборатории и подтверждение БД. Интерфейс может обеспечить возможность согласования журналов отчетности лаборатории с другими журналами аудита в ходе расследований. Например, сервис сопоставления журналов.

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

Обязательная функциональность. Показывать события, а также отправителя и получателя.

Возможная функциональность. Результаты были отправлены в неправильное место из-за ошибки в реестре поставщиков и инцидент обнаружил необходимость исправления/обновления реестра поставщиков. Как эта необходимость корректирующих действий может автоматически срабатывать и решаться?

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

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

В этом сценарии возникают следующие вопросы:

- может ли система определить, не потерялось ли сообщение?

- может ли система определить, не произошла ли операция? Так как операции являются событиями, подлежащими аудиту, эта информация должна быть получена;

- существует ли способ анализа наличия или отсутствия успешно или неуспешно отправленных сообщений?

- если появляется сообщение об ошибке (ошибка отклика), то оно может привязаться к сервису мониторинга, т.е. если система может это обнаружить, то сообщить о потере;

- для обнаружения несоответствий между полученными уведомлениями и отправленными уведомлениями существует функция сопоставления/анализа, которая находится вне сферы действия настоящего стандарта.

Сотрудники службы безопасности также хотели бы знать: если надлежащий специалист не получил сообщение из лаборатории в нужное время, то получал ли сообщения кто-нибудь еще в это время?

Отчасти это сценарий потока работ/предоставления отчетов/производительности. Сервис аудита может передать эту возможность сервису потока работ.

А.7 Случай непредсказуемости операций

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

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

Общая система аудита может оставаться последовательной повсеместно и использовать те же возможности отправлять и хранить журналы. Информация, которая будет зарегистрирована и то, где она будет загружена, будет определяться местной политикой конфигурации.

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

В современном мире этот вид аудита осуществляется путем предоставления администратору возможности проанализировать поток необработанных данных при помощи наиболее общих инструментов.

Система может не дать аналитические данные для входящего потока аудита, но может дать доступ к необработанному потоку аудита через интерфейс в случае, если кто-то захочет осуществить его анализ.

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

А.8 Случай исчезающих записей аудита. Хранилище данных аудита как цель

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

Примечание по внедрению. Маршрутизаторы являются хорошим местом (закрытым и подключенным), чтобы служить в качестве серверов времени для того, чтобы гарантировать, что системы синхронизированы. Приложение может/должно быть готовым обнаружить "ненормальные" пробелы в трафике аудита. "Нормальный" трафик аудита должен определяться на местном уровне.

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

Примечания

1 Большинство систем используют NTP, который создает записи аудита; они должны сохраняться в хранилище данных аудита и контролироваться.

2 Серверы аудита сами по себе должны быть усилены и защищены.

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

Согласованное время является обязательной функциональной возможностью и зависит от сервиса аудита (оно должно использоваться и работать, а не быть просто доступным).

Требование. Хранилище аудита и ассоциированные сервисы должны быть защищены, включая средства управления доступом и средства аудита.

А.9 Случай хакера, создающего ложные записи аудита

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

(Некоторые локальные политики могут решить использовать цифровые подписи для того, чтобы обнаружить сокрытие записей аудита.)

А.10 Случай просмотра записей аудита хакером и их злонамеренного использования

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

Смягчение. Не вносить личную медицинскую информацию в записи аудита! Если это невозможно, записи аудита могут быть зашифрованы либо по каждой записи, либо по сессии/потоку.

А.11 Случай странного (уполномоченного/неуполномоченного) изменения конфигурации

Некто, действуя как системный администратор, устанавливает обновление программного обеспечения местной системы. (Альтернатива: вредоносные атаки/случайный злоумышленник устанавливает HTTP-регистратор и фиксирует весь трафик HTTP для обнаружения уязвимостей системы.)

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

Хранилище аудита (или хранилище аудита конфигурации) должно быть время от времени исследовано, чтобы убедиться, что авторизованные обновления конфигурации имели место, когда должны были, и обнаружить несанкционированные или неожиданные изменения конфигурации.

Журнал/сервис аудита также должен записывать все изменения конфигурации, обновления и т.д., в том числе установку программного обеспечения, установку оборудования и изменения конфигурации.

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

Желательно, что более трудно, распространять это на оборудование.

А.12 Случай пользователя, пытающегося взломать пароль методом грубой силы

Сервер аудита получает отчеты о множестве сбоев при входе в систему и должен быстро установить флаг/запустить сигнал тревоги.