ГОСТ Р 56850-2015 Информатизация здоровья. Менеджмент рисков в информационно-вычислительных сетях с медицинскими приборами. Часть 2-2. Руководство по выявлению и обмену информацией о защите медицинских приборов, рисках и управлении рисками

МЕНЕДЖМЕНТ РИСКА для ИТ защиты

МЕНЕДЖМЕНТ РИСКА, основанный на ИСО 14971

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

Атрибут системы, который ведет к возможности причинения ВРЕДА (в особенности данным и системам), т.е. является ОПАСНОСТЬЮ, возникающей из атрибута, явно подверженного использованию во вредоносных целях (в терминах ИТ)

Угроза - нечто (преднамеренное или случайное), что способно причинить ВРЕД системам и организациям

Обстоятельство или событие, которое может повлечь за собой ВРЕД, т.е. ОПАСНОСТЬ, возникающая из уязвимости, плюс обстоятельство или событие, которое является ее инициатором (в ИТ она часто предполагает участие фактора угрозы)

Незащищенность - ситуация, которая может повлечь за собой причинение ВРЕДА

ОПАСНАЯ СИТУАЦИЯ

Вторжение - программное обеспечение или набор команд, создающий брешь в защите

Угроза + уязвимость + "активация" ВРЕД

Экземпляр ВРЕДА

ОПАСНОСТЬ+ОПАСНАЯ СИТУАЦИЯ+"последовательность событий" ВРЕД

РИСК - влияние неопределенности на достижение целей. [ИСО/МЭК 27005:2011]

РИСК - комбинация вероятности причинения вреда и его тяжести. [ИСО 14971:2007]

Контрмеры, гарантии безопасности, средства управления безопасностью

Возможности УПРАВЛЕНИЯ РИСКОМ (в ИТ они иногда именуются ослаблением РИСКОВ, осуществляемой при логическом обосновании АНАЛИЗОМ РИСКА)

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

ВРЕД

Применение:

Стандарт. Нет.

Политика. Местная ИТ политика МО.

Справочный материал:

Нет.

Цель требований:

Уменьшить РИСК получения несанкционированного доступа к ДАННЫМ О ЗДОРОВЬЕ с рабочего места, оставленного без присмотра.

Предотвратить неправильное использование, если система или рабочее место не используются в течение периода времени.

Потребность пользователя:

Несанкционированные пользователи не могут получить доступ к ДАННЫМ О ЗДОРОВЬЕ с рабочего места, оставленного без присмотра.

Сеансы санкционированных пользователей должны автоматически завершаться или блокироваться по прошествии заранее установленного промежутка времени. Это уменьшает РИСК несанкционированного доступа к ДАННЫМ О ЗДОРОВЬЕ, когда санкционированный пользователь покидает рабочее место, не завершая сеанс и не запирая экран или комнату.

Автоматический выход из системы должен включать в себя очистку ДАННЫХ О ЗДОРОВЬЕ со всех экранов по мере надобности.

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

Хранитель экрана с коротким временем бездействия или активирующийся "быстрой клавишей" может являться дополнительным свойством. Эта очистка экрана ДАННЫХ О ЗДОРОВЬЕ может быть вызвана, когда на протяжении короткого времени не была нажата ни одна клавиша (например, от 15 с до нескольких минут). Это не завершит сеанс пользователя, но снизит РИСК случайного наблюдения информации.

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

Применение:

Профиль. Профиль IHE ATNA (Профиль интеграции журнал аудита и аутентификация узлов) [IHE ATNA profile (Audit Trail and Node Authentication Integration Profile)].

Техническая основа рентгенологии IHE (IHE Radiology Technical Framework).

Политика. Местная ИТ политика МО.

Справочный материал:

NEMA (Национальная ассоциация производителей электрооборудования): S&P Аудит (NEMA: S&P Auditing).

Цель требований:

Установить согласованный подход к надежному аудиту того, кто и что делает с ДАННЫМИ О ЗДОРОВЬЕ, чтобы позволить ИТ отделу МО контролировать использование этих данных, применяя общеиспользуемые подходы, стандарты и технологию.

Наша индустрия пришла к согласию в том, что ИТ МО предпочитает поддержку профиля журнала аудита IHE.

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

Потребность пользователя:

Возможность записывать и изучать деятельность системы посредством ведения журналов аудита с помощью прибора, для отслеживания доступа к системе и ДАННЫМ О ЗДОРОВЬЕ, а также их модификации и удаления.

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

Поддержка создания и сопровождения аудита поддерживается соответствующими инструментами проверки аудита.

Защита данных аудита по мере необходимости (в особенности, если эти данные содержат сами персональные данные).

Отсутствие возможности удалять или редактировать данные аудита.

Так как данные аудита скорее всего содержат персональные данные и/или ДАННЫЕ О ЗДОРОВЬЕ, то вся обработка (например, получение доступа, хранение и передача) должна подчиняться соответствующим средствам управления.

Применение:

Примечание - Основывается на аутентификации, но эти два понятия не следует путать.

Стандарт. ANSI/INCITS 359-2004 Управление доступом, основанное на ролях (ANSI/INCITS 359-2004 Role-Based Access Control).

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

Общий подход к технической ИТ инфраструктуре IHE. Журнал аудита и аутентификация узлов (ATNA)/Аутентификация корпоративных пользователей (EUA)/Контроль процесса авторизации пользователей (XUA) [IHE IT Infrastructure Technical Framework - Audit Trail and Node Authentication (ATNA)/Enterprise User Authentication (EUA)/Cross Enterprise User Assertion (XUA)];

IETF (Рабочая группа инженеров Интернет): Защита транспортного уровня передачи данных (TLS) 1.2 (RFC 5246) [IETF: Transport Layer Security (TLS) 1.2 (RFC 5246)];

ITU-T (Сектор стандартизации телекоммуникаций в составе международного телекоммуникационного общества): Рекомендация Х.509. "Информационная технология. Взаимодействие открытых систем. Директория. Инфраструктура сертификата открытого ключа и атрибута" [ITU-T: Recommendation Х.509. "Information technology - Open Systems Interconnection - The directory: Public-key and attribute certificate frameworks].

Политика. Местная ИТ политика МО

Справочный материал:

Белая книга IHE (Интегрированное учреждение здравоохранения). Управление доступом (IHE White Paper - Access Control).

Общий подход к технической ИТ инфраструктуре IHE Журнал аудита и аутентификация узлов (ATNA).

ИСО/TS 22600-1:2006, Информатизация здоровья. Привилегированный менеджмент и управление доступом. Часть 1. Обзор и политика менеджмента (ISO/TS 22600-1:2006 Health informatics - Privilege management and access control - Part 1: Overview and policy management).

ИСО/TS 13606-4:2009, Информатизация здоровья. Электронная система передачи медико-санитарной документации. Часть 4. Защита (ISO/TS 13606-4:2009 Health informatics - Electronic health record communication - Part 4: Security)

Цель требований:

Следуя принципу минимизации данных, предоставить управление доступом к ДАННЫМ О ЗДОРОВЬЕ и функциям только в той степени, насколько это необходимо для выполнения задач МО в соответствии с ПРЕДНАЗНАЧЕННЫМ ИСПОЛЬЗОВАНИЕМ прибора.

Потребность пользователя:

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

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

МЕДИЦИНСКИЕ ПРИБОРЫ, как правило, поддерживают систему, основанную на разрешениях, которая предоставляет доступ к функциям системы и данным в соответствии с ролью запрашивающего доступ пользователя МО (управление доступом, основанное на ролях, RBAC). Например:

- ОПЕРАТОРЫ могут выполнять назначенные им задачи, используя все надлежащие для этого функции прибора (например, контроль или сканирование пациентов).

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

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

Авторизация позволяет МО эффективно предоставлять медицинское обслуживание и в то же время (1) сохранять защищенность системы и данных и (2) придерживаться принципа надлежащей минимизации данных. Авторизация может управляться локально или же в масштабах предприятия (например, с помощью централизованного руководства).

Примечание - В случаях, когда ПРЕДНАЗНАЧЕННОЕ ИСПОЛЬЗОВАНИЕ не подразумевает время, достаточное для начала и завершения сеанса использования прибора (например, в случае использования высокой пропускной способности), местной ИТ политикой может быть разрешено ослабление контроля авторизации, допуская, что физический доступ контролируется и ограничивается в достаточной мере.

Применение:

Стандарт. Нет.

Политика. Местная ИТ политика МО.

Справочный материал:

Нет.

Цель требований:

Дать МО возможность определять, как задействовать ВОЗМОЖНОСТИ ЗАЩИТЫ изделия, чтобы удовлетворить их требования к политике и/или рабочему процессу.

Потребность пользователя:

Местному санкционированному ИТ администратору требуется возможность выбирать между использованием и не использованием ФУНКЦИОНАЛЬНЫХ ВОЗМОЖНОСТЕЙ ЗАЩИТЫ изделия. Это может включать в себя взаимодействие аспектов управления привилегиями с средством управления ФУНКЦИОНАЛЬНОЙ ВОЗМОЖНОСТЬЮ ЗАЩИТЫ.

Применение:

Руководство. Руководство OIS по созданию отчетов об уязвимостях в защите и ответным мерам на их появление V2.0 1-е сентября 2004 (OIS Guidelines for Security Vulnerability Reporting and Response V2.0 1 September 2004).

Политика. Местная ИТ политика МО.

Справочный материал:

NEMA SPC Установление исправлений на готовое программное обеспечение, использующееся в медицинских информационных системах. Октябрь 2004 (NEMA SPC Patching off-the-shelf software used in medical information systems. October 2004).

Цель требований:

Создать унифицированный метод выполнения работы. Установка/усовершенствование пакетов исправлений для системы защиты выполняется персоналом на рабочем месте, и, вероятно, санкционированным персоналом МО (в случае установки скачиваемых пакетов исправлений).

Потребность пользователя:

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

- назначение наивысшего приоритета исправлениям, адресованным уязвимостям, связанным с высоким уровнем РИСКА, которые определяются в результате объективного, официального, документально отраженного, процесса ОЦЕНИВАНИЯ РИСКА уязвимости, осуществленного ПМП;

- обеспечение вендором медицинских изделий и поставщиком медицинских услуг продолжительного безопасного и эффективного клинического функционирования их изделий; обеспечение понимания местного регламента для МЕДИЦИНСКОГО ПРИБОРА (в общих случаях запрещена установка изменений на МЕДИЦИНСКИЕ ПРИБОРЫ без четких прописанных инструкций от ПМП);

- проведения надлежащего испытания для обнаружения любых непредвиденных последствий установки исправления на медицинский продукт (для рабочих характеристик или функциональности), которые могут подвергнуть ПАЦИЕНТА опасности;

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

Применение:

Стандарт. NEMA DICOM (Формирование цифровых изображений и обмен ими в медицине) Дополнение 142. Профили деидентификации клинического исследования (NEMA DICOM Supplement 142: Clinical Trial De-identification profiles).

NEMA DICOM Дополнение 55. Конфиденциальность уровня атрибутов (включая деидентификацию) 5 сентября 2002 (Финальный текст) [NEMA DICOM Supplement 55: Attribute level confidentiality (including De-identification) 5 Sept 2002 (Final text)].

ИСО 25237:2008, Информатизация здоровья. Псевдонимизация (ISO 25237:2008, Health Informatics - pseudonimization).

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

Политика. Местная ИТ политика МО

Справочный материал:

Суини Л. 2002. К-анонимность: модель для системы охраны личной информации. Международный журнал, посвященный неопределенности, нечеткости и системам, основанным на знаниях. Выпуск 10(5), 557-570 (Sweeney, L. 2002. K-anonymity: a model for protecting privacy. International Journal on Uncertainty, Fuzziness and Knowledgebased systems, 10(5), 557-570).

Цель требований:

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

Удаление данных перед возвращением изделия на завод; создание архитектуры, позволяющей удаленное обслуживание без доступа к/раскрытия ДАННЫХ О ЗДОРОВЬЕ; внутризаводской карантин, присвоение меток и обучение.

Потребность пользователя:

Пользователь медицинского изделия, инженеры по обслуживанию и отдел маркетинга должны иметь возможность деидентифицировать ДАННЫЕ О ЗДОРОВЬЕ для разнообразных целей, не требующих информации о личности ПАЦИЕНТА.

Применение:

Стандарт. Нет.

Политика. Местная ИТ политика МО.

Справочный материал:

ИСО/МЭК 20000-2:2012, Планирование и испытание непрерывности обслуживания (ISO/IEC 20000-2:2012, Service continuity planning and testing).

Цель требований:

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

Потребность пользователя:

Достаточная гарантия того, что постоянные системные настройки и постоянные ДАННЫЕ О ЗДОРОВЬЕ, хранящиеся в изделиях могут быть восстановлены после отказа системы или нарушения, таким образом, что предприятие могло продолжить функционировать.

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

Применение:

Стандарт. Нет.

Политика. Местная ИТ политика МО.

Справочный материал:

NEMA SPC Белая книга. Разбитие стекла (NEMA SPC White paper: Break-glass).

Цель требований:

Обеспечить возможность доступа к охраняемым ДАННЫМ О ЗДОРОВЬЕ в случае экстренной ситуации, требующей немедленного доступа к хранящимся ДАННЫМ О ЗДОРОВЬЕ.

Потребность пользователя:

В экстренных ситуациях пользователь медицинского изделия должен иметь возможность получить доступ к ДАННЫМ О ЗДОРОВЬЕ без персонального идентификатора (id) и аутентификации (функции разбивания стекла).

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

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

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

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

Применение:

Стандарт. Нет.

Политика. Местная ИТ политика МО.

Справочный материал:

NEMA Аудит защиты и неприкосновенности частной жизни (NEMA Security and Privacy Auditing).

Цель требований:

Обеспечить сохранность ДАННЫХ О ЗДОРОВЬЕ от изменения или уничтожения несанкционированными методами, а также гарантировать, что эти данные поступили от их создателя. Обеспечить целостность ДАННЫХ О ЗДОРОВЬЕ.

Потребность пользователя:

Пользователь хочет подтверждение того, что ДАННЫЕ О ЗДОРОВЬЕ являются надежными и не измененными в результате злонамеренного вмешательства.

Решением является использование как несъемных, так и съемных носителей информации.

Применение:

Стандарт. Нет.

Политика. Местная ИТ политика МО.

Цитата из регламента:

Защита от вредоносного программного обеспечения (Решаемая проблема). Процедуры принятия мер предосторожности, обнаружения и уведомления (создания отчетов) о вредоносном программном обеспечении.

Справочный материал:

NEMA Защита медицинских информационных систем от вредоносного программного обеспечения (NEMA Defending Medical Information Systems Against Malicious Software).

Цель требований:

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

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

Для удовлетворения требований регламента качества часто требуется испытание для ВЕРИФИКАЦИИ работы прибора на соответствие ПРЕДНАЗНАЧЕННОМУ ИСПОЛЬЗОВАНИЮ и требованиям БЕЗОПАСНОСТИ, осуществляемое после обновления программного обеспечения.

Потребность пользователя:

МО должна обнаруживать традиционное вредоносное программное обеспечение также как и несанкционированное программное обеспечение, которое может нарушать корректную работу прибора/системы.

Применение:

Профиль. Профиль IHE ATNA. Профиль интеграции журнала аудита и аутентификация узла.

Политика. NEMA/COCIR/JIRA Объединенный комитет по вопросам защиты и неприкосновенности частной жизни (Joint Security and Privacy). Белая книга (предстандарт технического комитета). Управление сертификатами аутентификации компьютеров, 10 февраля, 2005 (Committee draft White Paper: Management of Machine Authentication Certificates, 10 February 2005).

Проект политики защиты института SANS (институт системного администрирования, аудита сети и защиты) [SANS Security Policy Project].

Местная ИТ политика МО.

Справочный материал:

Нет.

Цель требований:

Политика аутентификации должна быть гибкой, чтобы иметь возможность адаптироваться к местной ИТ политики МО. Использование, по мере необходимости, аутентификации узлов при передаче ДАННЫХ О ЗДОРОВЬЕ.

Потребность пользователя:

Возможность управления межкомпьютерными учетными записями на медицинском оборудовании для защиты доступа к ДАННЫМ О ЗДОРОВЬЕ.

Поддержка независимого и центрального администрирования.

Поддержка аутентификации узлов в соответствии с отраслевыми стандартами.

Обнаружение и предотвращение фальсификации (необходимо предоставить невозможность отказа от авторства).

Применение:

Профиль. Профиль IHE ATNA (Профиль журнала аудита и интеграции аутентификации узлов).

Профиль IHE PWP (Персональный телефонный справочник) [IHE PWP profile (Personal White Pages].

IHE EUA (Аутентификация корпоративных пользователей).

IHE XUA (Контроль процесса авторизации пользователей).

Политика. Проект политики защиты SANS.

Местная ИТ политика МО.

Справочный материал:

Нет.

Цель требований:

Политика аутентификации должна быть гибкой для того, чтобы адаптироваться к местной ИТ политике МО. Требование аутентификации личности при предоставлении доступа к ДАННЫМ О ЗДОРОВЬЕ должно быть логически обоснованным в каждом конкретном случае.

Иметь возможность контролировать доступ к приборам, ресурсам сети и ДАННЫМ О ЗДОРОВЬЕ, а также создавать журналы аудита с невозможностью отказа от авторства. Данное свойство должно позволить однозначно и с уверенностью идентифицировать личность, пытающуюся получить доступ к сети, прибору или ресурсу.

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

Потребность пользователя:

Создание и использование уникальных учетных записей для пользователей и управление доступом, основанное на ролях (RBAC, местное и удаленное) к прибору, подключенному к сети, для управления и контроля доступа к сети и ее деятельности.

Возможность управлять учетными записями на медицинском оборудовании обеспечения защиты доступа к ДАННЫМ О ЗДОРОВЬЕ.

Пользователю может потребоваться связать персональные установки с учетными записями пользователей. Это может помочь приборам и системам, используемым множеством ОПЕРАТОРОВ, отделов или даже множеством организаций здравоохранения (МО). Необходима поддержка независимого и центрального администрирования.

Однократная идентификация и использование одного пароля для всех рабочих мест.

Обнаружение и предотвращение фальсификации (необходимо предоставить невозможность отказа от авторства).

Применение:

Стандарт. Нет.

Политика. Местная ИТ политика МО.

Справочный материал:

Нет.

Цель требований:

Гарантировать, что несанкционированный доступ не нарушит конфиденциальность системы или данных, целостность и доступность.

Потребность пользователя:

Достаточная гарантия того, что ДАННЫЕ О ЗДОРОВЬЕ, хранящиеся в изделиях или носителях были и остаются защищены в соответствии с уязвимостью и объема записей данных на приборе.

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

Злонамеренное вмешательство (включая удаление прибора) обнаружимо.

Применение:

Стандарт. Нет.

Политика. Местная ИТ политика МО.

Цитата из регламента:

Нет.

Справочный материал:

Нет.

Цель требований:

МО требуется понимание защиты на протяжении всего жизненного цикла МЕДИЦИНСКОГО ПРИБОРА.

Планы ПМП предполагают, что их изделия считаются поддерживаемыми на протяжении их жизненного цикла, согласно внутренним системам контроля качества и внешнему регламенту.

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

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

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

Потребность пользователя:

Контракты, политика и регламент МО требуют от вендора сопровождения/поддержки системы на протяжении жизни изделия.

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

Различные МО поставщики услуг демонстрируют проявление особой осторожности при необратимом удалении ДАННЫХ О ЗДОРОВЬЕ перед списыванием (списывании по причине брака, повтором использовании, перепродаже или переработке) приборов. Подобная деятельность должна фиксироваться и подвергаться аудиту.

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

Применение:

Стандарт. Нет.

Политика. Местная ИТ политика МО.

Проект политики института SANS.

Справочный материал:

Читальный зал для литературы по информационной защите института SANS (Пошаговые руководства).

Инструменты защиты и исходные показатели CIS (Центр эталонов интернет-безопасности и инструментов обеспечения защиты).

Цель требований:

Отладить средства управления защитой МЕДИЦИНСКОГО ПРИБОРА и/или прикладного программного обеспечения таким образом, чтобы защищенность была максимальна ("усилена"), но при этом осуществлялось ПРЕДНАЗНАЧЕННОЕ ИСПОЛЬЗОВАНИЕ прибора.

Минимизировать векторы атак и совокупную площадь атак посредством закрытия портов; удаления службы и т.д.

Потребность пользователя:

Пользователю требуется стабильная система, предоставляющая только те службы, установленные ПРЕДНАЗНАЧЕННЫМ ИСПОЛЬЗОВАНИЕМ и требующиеся для его осуществления, с минимумом сопроводительной деятельности.

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

Желательно, чтобы пользователь информировал ПМП о предполагаемых нарушениях защиты и очевидных слабостях пользовательского оборудования.

Применение:

Стандарт. Нет.

Политика. Местная ИТ политика МО.

Справочный материал:

Заявление производителя о раскрытии информации о защите медицинского прибора (MDS2) [Manufacture Disclosure Statement for Medical Device Security (MDS2)].

Цель требований:

Обеспечить доступность руководства по защите для ОПЕРАТОРОВ и администраторов системы. Желательно предоставление отдельных пособий для ОПЕРАТОРОВ и АДМИНИСТРАТОРОВ (включая отдел продаж и обслуживания ПМП), так как это позволяет только администраторам сохранять за собой понимание всего административного функционала.

Потребность пользователя:

ОПЕРАТОР должен обладать четкой информацией о своих ответственностях и о защищенном способе работы с системой.

Администратору требуется информация об управлении, настройке и контроле системы (т.е. список средств управления, записей аудита и т.д.). Администратору необходимо четкое понимание функциональных возможностей защиты, чтобы позволить ему выполнение ОЦЕНКИ РИСКА для ДАННЫХ о ЗДОРОВЬЕ в соответствии с надлежащими нормативными требованиями.

Отдел продаж и обслуживания также нуждается в информации о ФУНКЦИОНАЛЬНЫХ ВОЗМОЖНОСТЯХ системы и защищенном способе работы.

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

Применение:

Стандарты. NEMA DICOM Часть 15. Профили управления защитой и системой (NEMA DICOM Part 15: Security and System Management Profiles). NEMA DICOM Дополнение 51. Защита носителей информации (NEMA DICOM Supplement 51: Media security).

NEMA DICOM Дополнение 55. Конфиденциальность уровня атрибутов (включая деидентификацию), 5 сентября, 2002 (Финальный текст).

Политика. Местная ИТ политика МО.

Справочный материал:

Шнайер Б. 1996, Практическая криптография. Второе издание. John Wiley & Sons, Нью-Йорк (Schneier В. 1996. Applied Cryptography, Second Edition. John Wiley & Sons, New York, NY).

Цель требований:

ПМП устанавливает технические средства управления для ослабления возможного нарушения целостности и конфиденциальности ДАННЫХ о ЗДОРОВЬЕ, хранимых на изделиях или съемных носителях.

Потребность пользователя:

Достаточная гарантия того, что ДАННЫЕ о ЗДОРОВЬЕ, хранящиеся на изделиях или носителях были и остаются защищены.

На основе результатов АНАЛИЗА РИСКА должна рассматриваться возможность использования шифрования для ДАННЫХ о ЗДОРОВЬЕ, хранящихся на МЕДИЦИНСКИХ ПРИБОРАХ.

В случае ДАННЫХ о ЗДОРОВЬЕ, хранящихся на съемных носителях, шифрование может послужить защитой конфиденциальности/целостности для пользователей медицинских изделий, но также и для инженеров служб и приложений ПМП, собирающих медицинские данные.

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

В методе и стойкости шифрования учитывается объем (масштаб сбора/агрегации) и уязвимость данных.

Применение:

Профиль. Профиль IHE ATNA (Профиль интеграции журнал аудита и аутентификация узлов).

Политика. Местная ИТ политика МО.

Справочный материал:

NEMA SPC Сертификаты, белая книга (NEMA SPC Certificates white paper). NEMA DICOM Часть 15. Профили управления защитой и системой.

IETF: Защита уровня передачи данных в сетевой рабочей группе RFC 5246, август 2008. Протокол TLS версия 1.2 (IETF: Transport Layer Security in Network Working Group RFC 5246) August 2008: The TLS Protocol Version 1.2).

ITU-T. Рекомендация Х.509. "Информационная технология. Взаимодействие открытых систем. Директория. Инфраструктура сертификата открытого ключа и атрибута" (ITU-T Recommendation Х.509. "Information technology - Open Systems Interconnection - The directory: Public-key and attribute certificate frameworks")

Цель требований:

ПРИБОР соответствует местным законам, регламенту и стандартам (например, USA HIPAA (закон об обеспечении доступности и подотчетности в медицинском страховании), национальным законам, основанным на EU 95/46/ЕС) в соответствии с потребностями МО для обеспечения конфиденциальности передаваемых ДАННЫХ О ЗДОРОВЬЕ.

Потребность пользователя:

Гарантия сохранения конфиденциальности ДАННЫХ о ЗДОРОВЬЕ во время передачи этих данных между аутентифицированными узлами. Это позволяет осуществлять передачу ДАННЫХ о ЗДОРОВЬЕ через относительно открытые сети и/или окружение, где действует крепкая ИТ политика МО обеспечения целостности и конфиденциальности ДАННЫХ о ЗДОРОВЬЕ.

В стандарте МЭК/ТО 80001-2-3:2012 представлено больше информации о МЕНЕДЖМЕНТЕ РИСКА для систем беспроводных сетей.

Применение:

Профиль. Профиль IHE ATNA (Профиль интеграции журнала аудита и аутентификация узлов).

Политика. Местная ИТ политика МО.

Справочный материал:

NEMA SPC Сертификаты, белая книга.

NEMA DICOM Часть 15. Профили управления системой и защитой.

Цель требований:

Прибор должен обеспечивать защиту целостности передаваемых ДАННЫХ о ЗДОРОВЬЕ.

Потребность пользователя:

Обеспечение сохранения целостности ДАННЫХ о ЗДОРОВЬЕ во время передачи. Это позволяет осуществлять передачу ДАННЫХ о ЗДОРОВЬЕ через относительно открытые сети и/или окружение, где действует крепкая ИТ политика МО обеспечения целостности и конфиденциальности ДАННЫХ о ЗДОРОВЬЕ.

Цель требований:

Политика аутентификации должна быть гибкой для того, чтобы адаптироваться к местной ИТ политике МО. Требование аутентификации личности при предоставлении доступа к ДАННЫМ О ЗДОРОВЬЕ должно быть логически обоснованным в каждом конкретном случае.

Иметь возможность контролировать доступ к приборам, ресурсам сети и ДАННЫМ О ЗДОРОВЬЕ, а также создавать журналы аудита с невозможностью отказа от авторства. Данное свойство должно позволить однозначно и с уверенностью идентифицировать личность, пытающуюся получить доступ к сети, прибору или ресурсу.

Примечание - Это требование смягчено в процессе выполнения "разбивания стекла". См. "экстренный доступ".

Потребность пользователя:

Создание и использование уникальных учетных записей для пользователей и управление доступом, основанное на ролях (RBAC, местное и удаленное) к прибору, подключенному к сети, для управления и контроля доступа к сети и ее деятельности.

Возможность управлять учетными записями на медицинском оборудовании обеспечения защиты доступа к ДАННЫМ О ЗДОРОВЬЕ.

Пользователю может потребоваться связать персональные установки с учетными записями пользователей. Это может помочь приборам и системам, используемым множеством ОПЕРАТОРОВ, отделов или даже множеством организаций здравоохранения (МО). Необходима поддержка независимого и центрального администрирования.

Однократная идентификация и использование одного пароля для всех рабочих мест.

Обнаружение и предотвращение фальсификации (необходимо предоставить невозможность отказа от авторства).

PAUT.1

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

PAUT.2

Использование центрального администрирования МО для учетных записей пользователей в соответствии с профилем IHE EUA.

PAUT.3

Поддержка идентификации множества одновременных пользователей (например, ОПЕРАТОР + практикующий врач) для управления доступом, основанного на ролях.

PAUT.4

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

PAUT.6

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

Ссылочный документ

Название

CIS

Центр эталонов интернет-безопасности и инструментов обеспечения защиты (The Center for Internet Security Benchmarks and Security Tools), //cisecurity.org/

DICOM

Формирование цифровых изображений и обмен ими в медицине, финансированное NEMA (Digital Imaging and Communications in Medicine sponsored by NEMA).

Стандарты.

NEMA DICOM Часть 15. Профили управления защитой и системой (NEMA DICOM Part 15: Security and System Management Profiles).

NEMA DICOM Дополнение 55. Конфиденциальность уровня атрибутов (включая деидентификацию) 5 сентября 2002 (Финальный текст) [NEMA DICOM Supplement 55: Attribute level confidentiality (including De-identification) 5 Sept 2002 (Final text)].

NEMA DICOM Дополнение 51. Защита носителей информации (NEMA DICOM Supplement 51: Media security).

NEMA DICOM Дополнение 142: Профили деидентификации клинического исследования (NEMA DICOM Supplement 142: Clinical Trial De-identification profiles).

IETF

Рабочая группа инженеров Интернет (The Internet Engineering Task Force).

Документы.

Рабочая группа сети RFC 5246 Август 2008: Протокол TLS Версия 1.2 (Network Working Group RFC 5246 August 2008: The TLS Protocol Version 1.2: ), //www.ietf.org/rfc/rfc5246.txt

IHE

Интегрированное учреждение здравоохранения (IHE Integrated Healthcare Enterprise), //www.ihe.net/Technical_Framework/.

Примечание - Об ATNA см. //wiki.ihe.net/index.php?title=Audit_Trail_and_Node_Authentication. Профиль интеграции журнала аудита и аутентификация узлов (ATNA) спроектирован для поддержки управления доступом посредством ограничения доступа к сети между узлами и разрешения доступа к каждому узлу только санкционированным пользователям (прошедшими местную аутентификацию). Он включает в себя Аутентификацию Пользователей, Аутентификацию Соединения, Журнал Аудита и поддерживает:

- Защищенные Узлы,

- Архив данных аудита, и

- Сервер времени.

Данные средства предназначены обеспечивать поддержку времени, аутентификации узлов и запись событий аудита. Это основывается на стандартах, созданных в IETF, посвященных Технической основе ИТ инфраструктуры, включая стандарты для Защищенных Коммуникаций (Secure Communications), Передачи записей аудита (Audit Log Transport), Сообщение записей аудита (Audit Log Message). Среди этих стандартов: RFC 5246, WS-I Базовый профиль защиты 1.1 (WS-I Basic Security Profile 1.1), RFC 5424, RFC 5425, RFC 5426, RFC 3164, RFC 3881, DICOM: Дополнение 95 (ИСО 12052 ftp://medical.nema.org/medical/dicom/final/sup95_ft.pdf).

Местная ИТ политика МО

Политика, утвержденная организацией пользователя изделия, в которой установлено допустимое использование информационной технологии

NEMA SPC

Объединенный комитет по вопросам защиты и неприкосновенности частной жизни NEMA/COCIR/JIRA, //www.medicalimaging.org/ policyandpositions/jointsecurityand-privacy-committee-2/.

Технические документы:

SPC Аудит защиты и неприкосновенности частной жизни в информационных технологиях в здравоохранении (SPC Security and Privacy Auditing in Health Care Information Technology).

SPC Разбитие стекла: Метод получения экстренного доступа к системам здравоохранения. Декабрь 2004 (SPC Break-Glass: An approach to granting emergency access to health care systems. December 2004).

SPC Защита медицинских информационных систем от вредоносного программного обеспечения. Декабрь 2003. SPC Установление исправлений на готовое программное обеспечение, использующееся в медицинских информационных системах, Октябрь 2004 (SPC Defending medical information systems against malicious software. December 2003. SPC Patching off-the-shelf software used in medical information systems, October 2004).

SPC Интерфейс удаленного обслуживания. Решение (А). Версия 2: безопасность IP в Интернете с помощью цифровых сертификатов, Декабрь 2003 (SPC Remote Service Interface - Solution (A) - Version 2: IPSec over the Internet Using Digital Certificates, December 2003).

ITU

Сектор стандартизации телекоммуникаций в составе международного телекоммуникационного общества ITU-T Рекомендация Х.509 (11/2008) ИСО/МЭК 9594-8:2008 (ITU International Telecommunication Union Telecommunication Standardization Section (ITU-T) Recommendation X.509 (11/2008) ISO/IEC 9594-8:2008),
//www.itu.int/itut/recommendations/index.aspx?ser=X

OSI

Публикация организации, специализирующейся на Интернет Безопасности (OIS Organization for Internet Safety), //www.oisafety.org/: OIS Руководство по созданию отчетов об уязвимостях в защите и принятию ответных мер V2.0 1 Сентября 2004 (OIS Guidelines for Security Vulnerability Reporting and Response V2.0 1 September 2004, //www.symantec.com/security/OIS_Guidelines%20for%20responsible%
20disclosure.pdf)

SANS

SANS - Институт системного администрирования, аудита, сети и защиты [The SANS (SysAdmin, Audit, Network, Security) Institute], //www.sans.org.

Проект политики защиты института SANS (The SANS Security Policy Project) - "...все, что вам необходимо для стремительного развития и реализации политики защиты информации": //www.sans.org/resources/policies/.

Читальный зал для литературы по информационной защите института SANS: //www.sans.org/reading_room/

Шнайер

Брюс Шнайер 1996 Практическая криптография, Второе издание. John Wiley & Sons, Нью-Йорк. (Schneier В. 1996. Applied Cryptography, Second Edition. John Wiley & Sons, New York, NY).

Если вы планируете использовать данную книгу, то найдите в интернете список опечаток, так как в тексте присутствуют хорошо известные ошибки

WEDI

Рабочая группа по защите и неприкосновенности частной жизни в электронном обмене данными SNIP [Workgroup for Electronic Data Interchange Security and PrivacyWorkgroup (SNIP)].

Технические документы:

WEDI-SNIP Введение в последнюю версию последнего правила защиты. Январь 2004 (WEDI-SNIP Introduction to Security Final Rule Final Version - January 2004): (требуется членство) //www.wedi.org.

WEDI-SNIP ЗАЩИТА: Технические документы для прояснения журнала аудита. Версия 5.0, Ноябрь 7, 2003 (WEDI-SNIP SECURITY: Audit Trail Clarification White Paper Version 5.0 November 7, 2003) (требуется членство) //www.wedi.org

NSA

Агентство национальной безопасности Соединенных Штатов (US National Security Agency). Руководства NSA по конфигурации систем защиты, //www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/index.shtml

IETF

Рабочая группа инженеров Интернет (The Internet Engineering Task Force)

Документы:

Рабочая группа сети RFC 5246, Август 2008, Протокол TLS Версия 1.2 (Network Working Group RFC 5246 August 2008: The TLS Protocol Version 1.2),

//www.ietf.org/rfc/rfc5246.txt

SANS

SANS - институт системного администрирования, аудита, сети и защиты [The SANS (SysAdmin, Audit, Network, Security) Institute], //www.sans.org.

Проект политики защиты института SANS (The SANS Security Policy Project) - "...все, что вам необходимо для стремительного развития и реализации политики защиты информации..", //www.sans.org/resources/policies/.

Читальный зал для литературы по информационной защите института SANS, //www.sans.org/reading_room/.

Словарь по защите SANS, //www.sans.org/securityresources/glossary.php.

WEDI

Рабочая группа по защите и неприкосновенности частной жизни в электронном обмене данными SNIP [Workgroup for Electronic Data Interchange Security and PrivacyWorkgroup (SNIP)].

Технические документы:

WEDI-SNIP Введение в последнюю версию последнего правила защиты. Январь 2004 (WEDI-SNIP Introduction to Security Final Rule Final Version - January 2004), (требуется членство).

WEDI-SNIP ЗАЩИТА. Технические документы для разъяснения журнала аудита. Версия 5.0, 7 ноября 2003 (WEDI-SNIP SECURITY: Audit Trail Clarification White Paper Version 5.0 November 7, 2003), (требуется членство).

IHE

Интеграция учреждения здравоохранения (IHE Integrating the Healthcare Enterprise), //www.ihe.net/Technical_Framework/.

Профиль IHE ATNA (Профиль интеграции журнала аудита и аутентификации узлов) [Audit Trail and Node Authentication Integration Profile].

IHE EUA (Аутентификация корпоративных пользователей) [Enterprise User Authentication].

IHE RAD TF (Журнал аудита рентгенологии) предварительная версия для открытого обсуждения [(Radiology Audit Trail) draft version for public comment].

Джоан Ковальски, CISSP

Сотрудник службы ИТ защиты

Больница общего профиля Нью Тауна

Дорогая мисс Ковальски,

Благодарим Вас за проявленный интерес к рабочей станции FOOBAR 2.0 DICOM PACS. Мы получили подписанное вами соглашение о неразглашении и настоящим направляем Вам копию, подписанную нами.

Вы также найдете в письме подробную информацию о защите FOOBAR 2.0, представленную в форме, соответствующей Техническому отчету о защите по МЭК 80001-1. Мы всегда стараемся соблюдать ясность и последовательность в общении с нашими клиентами по проблемам риска в вопросах защиты, и я уверен, что данный конфиденциальный документ соответствует вашим потребностям.

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

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

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

С наилучшими пожеланиями,

Хосе Армас

Менеджер по продажам продукции FOOBAR,

Корпорация Виджет

копия:

1 Подписанное с двух сторон Соглашение о неразглашении, датируемое 1 мая, 2010 г.

2 Отчет о характеристиках защиты FOOBAR 2.0 (МЭК 80001-1).

Идентификатор

Возможность

/ALOF.01/

Хранитель экрана запускается автоматически через пять минут после последнего удара по клавише/движения мышью.

Замечание - Местный авторизованный ИТ администратор может задать время задержки для данного действия и даже отключать хранитель экрана

/ALOF.02/

Хранитель экрана очищает все отображаемые ДАННЫЕ о ЗДОРОВЬЕ с экрана

/ALOF.03/

Хранитель экрана не выводит пользователя из системы/не прекращает сеанс

/ALOF.04/

Пользователю требуется снова войти в систему после активации хранителя экрана

/ALOF.05/

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

Замечание - Местный авторизованный ИТ администратор может задать время задержки для данного действия и даже отключать автоматический выход из системы

Идентификатор

Возможность

/AUDT.01/

О получении доступа, модификации или удалении любых ДАННЫХ о ЗДОРОВЬЕ делается запись, которая хранится в специализированном архиве DICOM

/AUDT.02/

О загрузке ДАННЫХ о ЗДОРОВЬЕ (в собственную память прибора) делается запись, которая хранится в специализированном архиве DICOM

/AUDT.03/

В случае, если прибор используется за пределами сети DICOM, то доступ к любым ДАННЫМ о ЗДОРОВЬЕ хранится в собственной памяти прибора

/AUDT.04/

После повторного подсоединения прибора к DICOM-сети, журнал аудита, который велся во внутренней памяти прибора во время автономной работы, синхронизируется со специализированным удаленным архивом DICOM

/AUDT.05/

Ссылается на /CNFS.01/: все изменения ВОЗМОЖНОСТЕЙ ЗАЩИТЫ фиксируются в журнале аудита прибора

Идентификатор

Возможность

/CNFS.01/

Местный авторизованный ИТ администратор может устанавливать/отключать доступные ВОЗМОЖНОСТИ ЗАЩИТЫ прибора

/CNFS.02/

Ссылается на /AUDT.05/: в случае, когда местный авторизованный ИТ администратор устанавливает/отключает/изменяет настройки доступных ВОЗМОЖНОСТЕЙ ЗАЩИТЫ прибора, его действие фиксируется в журнале аудита

Идентификатор

Возможность

/DTBK.01/

FOOBAR 2.0 предоставляет (встроенную) функцию резервного копирования для хранения системных настроек на внешнем подключаемом запоминающем устройстве большой емкости (например, на USB-накопителе)

/DTBK.02/

FOOBAR 2.0 предоставляет (встроенную) функцию резервного копирования для хранения журналов аудита на внешнем подключаемом запоминающем устройстве большой емкости (например, на USB-накопителе)

/DTBK.03/

Журналы аудита соответствующим образом шифруются для предотвращения потери конфиденциальной информации, содержащей ДАННЫЕ о ЗДОРОВЬЕ (такие как имя пациента, DOB и т.д.)

/DTBK.04/

Резервное восстановление хранящихся локально ДАННЫХ о ЗДОРОВЬЕ может быть выполнено только с возвращением данных на специализированный удаленный архив DICOM. Логическое обоснование. Для обеспечения сохранения непротиворечивости ДАННЫХ о ЗДОРОВЬЕ требуется ограничивающий функционал

Идентификатор

Возможность

/DIDT.01/

FOOBAR 2.0 не поддерживает никакие средства прямого удаления информации, которые позволяют идентифицировать ПАЦИЕНТА

Идентификатор

Возможность

/STCF.01/

ДАННЫЕ о ЗДОРОВЬЕ, хранящиеся в собственной памяти FOOBAR 2.0 зашифрованы. Использующийся алгоритм: AES (Rijndael), Стойкость шифрования: 256 БИТ.

Замечание - Данная настройка не может быть изменена местным ИТ администратором

/STCF.02/

Защищенные/зашифрованные ДАННЫЕ о ЗДОРОВЬЕ доступны только после удачной загрузки. См. также /MLDP.04/

/STCF.03/

Дешифруются только требующиеся ДАННЫЕ о ЗДОРОВЬЕ (требующиеся для текущего взаимодействия/использования/отображения). Неиспользуемые на данный момент ДАННЫЕ о ЗДОРОВЬЕ остаются зашифрованными

/STCF.04/

Загрузочный раздел, операционная система, временные данные или внутреннее запоминающее устройство большой емкости и т.д. также шифруются. Используемый алгоритм: AES (Rijndael), Стойкость шифрования: 256 БИТ.

Замечание - Данная настройка не может быть изменена местным ИТ администратором

/STCF.05/

Случайные сбои питания в системе не влияют на шифрование ДАННЫХ о ЗДОРОВЬЕ, хранящихся на запоминающем устройстве большой емкости. Не при каких обстоятельствах выполнения работы незашифрованные ДАННЫЕ о ЗДОРОВЬЕ не присутствуют на внутреннем запоминающем устройстве большой емкости

/STCF.06/

Соединение со специализированным удаленным архивом, находящимся в сети DICOM, может быть установлено с помощью VPN

Идентификатор

Возможность

/EMRG.01/

Наличие функции разбивания стекла. Даже без персонального идентификатора (id) пользователя и медицинской аутентификации пользователь может получить доступ к ДАННЫМ о ЗДОРОВЬЕ.

Замечание - Необходимо помнить, что данная функция может быть изменена/отключена местным ИТ администратором

/EMRG.02/

Использование функции разбивания стекла /EMRG.01/ требует использование общего идентификатора (id) пользователя и аутентификации (для предотвращения получения доступа к ДАННЫМ о ЗДОРОВЬЕ пациентами или сторонними наблюдателями)

/EMRG.03/

Каждое использование функции разбивания стекла /EMRG.01/ будет занесено в журнал аудита

/EMRG.04/

О каждом использовании функции разбивания стекла /EMRG.01/ может автоматически создаваться отчет для установления учетной записи пользователя, например посредством электронной почты (eMail)

Идентификатор

Возможность

/SGUD.01/

Руководство по защите для ОПЕРАТОРА включено в инструкции по использованию FOOBAR 2.0. См. главу 13

/SGUD.02/

Руководство по защите для администратора включено в техническую информацию FOOBAR 2.0. См. главу 17

Идентификатор

Возможность

/IGAU.01/

ДАННЫЕ о ЗДОРОВЬЕ, хранящиеся в памяти большой емкости FOOBAR 2.0 для отображения данных за пределами сети DICOM, защищены с помощью надлежащей контрольной суммы (SHA1), чтобы обеспечить целостность данных

/IGAU.02/

Предоставлены ВОЗМОЖНОСТИ по резервному копированию. См. главу, посвященную DTBK: Резервное копирование данных и аварийное восстановление

Идентификатор

Возможность

/MLDP.01/

Все несущественные порты сети FOOBAR 2.0 закрыты.

Замечание 01 - Более подробную информацию см. в технической информации FOOBAR 2.0, в руководстве по защите для администратора (глава 17). См. /SGUD.02/

Замечание 02 - Данная функциональная возможность не может быть изменена местным ИТ администратором

/MLDP.02/

Операционная система, установленная на загрузочном устройстве FOOBAR 2.0, защищена от санкционированных/несанкционированных изменений. После перезагрузки система возвращается в свое изначальное состояние.

Замечание - Данная функциональная возможность не может быть изменена местным ИТ администратором

/MLDP.03/

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

Замечание - Данная функциональная возможность не может быть изменена местным ИТ администратором

/MLDP.04/

Защищенные/зашифрованные ДАННЫЕ о ЗДОРОВЬЕ доступны только после успешной загрузки. См. также /STCF.01/.

Замечание - Данная функциональная возможность не может быть изменена местным ИТ администратором

Идентификатор

Возможность

/PAUT.01/

FOOBAR 2.0 поддерживает местное и глобальное управление учетными записями.

Замечание - Более подробную информацию см. в технической информации FOOBAR 2.0, в руководстве по защите для администратора (глава 17)

/PAUT.02/

FOOBAR 2.0 поддерживает закрытие учетных записей.

Замечание - Более подробную информацию см. в технической информации FOOBAR 2.0, в руководстве по защите для администратора (глава 17)

/PAUT.03/

FOOBAR 2.0 поддерживает быстрое переключение пользователей. Поддержка данной функции уменьшает затраты времени на задачу входа и выхода пользователей из системы

Идентификатор

Возможность

/PLOK.01/

По причине выбранного метода шифрования FOOBAR 2.0 не требуется физическое запирание

Идентификатор

Возможность

/CSUP.01/

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

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

Замечание - Более подробную информацию см. в технической информации FOOBAR 2.0, в руководстве по защите для администратора (глава 17)

/CSUP.02/

Прибор спроектирован так, что мы (производитель) не позволяем МО устанавливать какие-либо несанкционированные патчи

Идентификатор

Возможность

/RDMP.01/

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

Замечание - Более подробную информацию см. в технической информации о FOOBAR 2.0 (глава 42)

Идентификатор

Возможность

/SAHD.01/

Все ВОЗМОЖНОСТИ, предназначенные обеспечить стабильную систему, предоставляющую только те службы, которые установлены ПРЕДНАЗНАЧЕННЫМ ИСПОЛЬЗОВАНИЕМ и требуются для его осуществления с минимумом сопроводительной деятельности, а также для того, чтобы позволить поставщикам медицинских услуг/МО организациям подключить FOOBAR 2.0 к их сети, рассматриваются в главе MLDP: Обнаружение вредоносного программного обеспечения и защита от него в технической информации о FOOBAR 2.0 (глава 38)

Идентификатор

Возможность

/AUTH.01/

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

Замечание - Более подробную информацию см. в технической информации FOOBAR 2.0

/AUTH.02/

Так называемый вход в систему в качестве администратора предоставляется в случае FOOBAR 2.0 для:

- общего администрирования сервера;

- установки обновлений/решения проблем;

- добавления большого количества клиентов FOOBAR;

- администрирования главных пользователей;

- операций по резервному копированию

/AUTH.03/

Так называемый вход в качестве главного пользователя (Master User) настраивается заранее и может быть добавлен для:

- внесения поправок в/объединения отчетов/данных пациентов;

- восстановления потерянных отчетов;

- администрирования общих пользователей;

- редактирования и поддержки общей конфигурации применения FOOBAR

Идентификатор

Возможность

/TXDF.01/

См. /STCF.06/. Соединение со специализированным удаленным архивом, находящимся в сети DICOM, может быть установлено с помощью VPN.

Замечание - Более подробную информацию см. в технической информации FOOBAR 2.0 (глава 33)

/TXDF.02/

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

Идентификатор

Возможность

/TXIG.01/

См. /STCF.06/: Соединение со специализированным удаленным архивом, находящимся в сети DICOM, может быть установлено с помощью VPN.

Данная функциональная возможность гарантирует сохранение целостности ДАННЫХ о ЗДОРОВЬЕ на протяжении передачи данных и позволяет FOOBAR 2.0 передавать ДАННЫЕ о ЗДОРОВЬЕ через относительно открытые сети или окружение, в котором действует крепкая политика обеспечения целостности ДАННЫХ о ЗДОРОВЬЕ.

Замечание - Более подробную информацию см. в технической информации FOOBAR 2.0 (глава 33)

Хосе Армас

Менеджер по продажам продукции FOOBAR

Корпорация Виджет

Дорогой, мистер Армас,

Благодарю Вас за подробный ответ на мой запрос информации о защите рабочей станции DICOM PACS FOOBAR 2.0 корпорации Виджет. Ваш, основанный на МЭК 80001-1 документ содержит множество полезной информации и является хорошим основанием для начала нашего проекта приобретения и установки перед подключением Рабочей станции PACS к медицинской ИТ-сети больницы Нью Тауна.

И хотя я высоко ценю ваши попытки привнести ясность и прозрачность в вопрос риска, у меня имеется несколько замечаний и вопросов. Я позволила себе добавить еще одну колонку к вашему документу с комментариями, расположенную справа от вашего описания характеристик защиты. В местах, где, по моему мнению, не достает свойства, я добавила ряд в соответствующий раздел. Кроме того, там, где мной было подтверждена возможность и ее необходимость для удовлетворения наших нужд, стоит комментарий "Принято к сведению". И хотя мы еще не готовы "Принять" эти возможности, мне представилось удобным использовать данное письмо для сосредоточения нашего внимания на других, более важных проблемах нашего первого обсуждения.

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

Мое управление свяжется с Вами по вопросу последующего телефонного обсуждения.

С уважением, Джоан Ковальски, CISSP

Сотрудник службы ИТ защиты

Больница общего профиля Нью Тауна

Копия:

Ответ больницы Нью Тауна на отчет о характеристиках защиты FOOBAR 2.0 (МЭК 80001-1).

Идентификатор

Возможность

Комментарии/потребности МО

/ALOF.01/

Хранитель экрана запускается автоматически через пять минут после последнего удара по клавише/движения мышью.

Замечание - Местный авторизованный ИТ администратор может задать время задержки для данного действия и даже отключать хранитель экрана

Принято к сведению МО

Желателен более долгий период времени, так как диагностические операции имеют перерывы

/ALOF.02/

Хранитель экрана очищает все отображаемые ДАННЫЕ о ЗДОРОВЬЕ с экрана

Принято к сведению МО

/ALOF.03/

Хранитель экрана не выводит пользователя из системы/не прекращает сеанс

Принято к сведению МО

/ALOF.04/

Пользователю требуется снова войти в систему после активации хранителя экрана

Принято к сведению МО

/ALOF.05/

Сеанс пользователя завершается автоматически через 60 мин после последнего удара клавиши/ движения мышью/взаимодействия с сенсорным экраном

Замечание - Местный авторизованный ИТ администратор может задать время задержки для данного действия и даже отключать автоматический выход из системы

Принято к сведению МО

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

Идентификатор

Возможность

Комментарии/потребности МО

/AUDT.01/

О получении доступа, модификации или удалении любых ДАННЫХ о ЗДОРОВЬЕ делается запись, которая хранится в специализированном архиве DICOM

Для данного случая применения это свойство не требуется

/AUDT.02/

О загрузке ДАННЫХ о ЗДОРОВЬЕ (в собственную память прибора) делается запись, которая хранится в специализированном архиве DICOM

Для данного случая применения это свойство не требуется

/AUDT.03/

В случае, если прибор используется за пределами сети DICOM, то доступ к любым ДАННЫМ о ЗДОРОВЬЕ хранится в собственной памяти прибора

Для данного случая применения это свойство не требуется

/AUDT.04/

После повторного подсоединения прибора к DICOM-сети, журнал аудита, который велся во внутренней памяти прибора во время автономной работы, синхронизируется со специализированным удаленным архивом DICOM

Для данного случая применения это свойство не требуется

/AUDT.05/

Ссылается на /CNFS.01/. Все изменения ВОЗМОЖНОСТЕЙ ЗАЩИТЫ фиксируются в журнале аудита прибора

Для данного случая применения это свойство не требуется

Идентификатор

Возможность

Комментарии/потребности МО

/CNFS.01/

Местный авторизованный ИТ администратор может устанавливать/отключать доступные ВОЗМОЖНОСТИ ЗАЩИТЫ прибора

Принято к сведению МО

/CNFS.02/

Ссылается на /AUDT.05/. В случае, когда местный санкционированный ИТ администратор устанавливает/отключает/изменяет настройки доступных ФУНКЦИОНАЛЬНЫХ ВОЗМОЖНОСТЕЙ ЗАЩИТЫ прибора, его действие фиксируется в журнале аудита

Принято к сведению МО

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

Идентификатор

Возможность

Комментарии/потребности МО

/DTBK.01/

FOOBAR 2.0 предоставляет (встроенную) функцию резервного копирования для хранения системных настроек на внешнем подключаемом запоминающем устройстве большой емкости (например, на USB-накопителе)

Для данного случая применения это свойство не требуется

/DTBK.02/

FOOBAR 2.0 предоставляет (встроенную) функцию резервного копирования для хранения журналов аудита на внешнем подключаемом запоминающем устройстве большой емкости (например, на USB-накопителе)

Для данного случая применения это свойство не требуется

/DTBK.03/

Журналы аудита соответствующим образом шифруются для предотвращения потери конфиденциальной информации, содержащей ДАННЫЕ о ЗДОРОВЬЕ (такие как имя пациента, DOB, и т.д.)

Для данного случая применения это свойство не требуется

/DTBK.04/

Резервное восстановление хранящихся локально ДАННЫХ о ЗДОРОВЬЕ может быть выполнено только с возвращением данных на специализированный удаленный архив DICOM.

Логическое обоснование. Для обеспечения сохранения непротиворечивости ДАННЫХ о ЗДОРОВЬЕ требуется ограничивающий функционал

Для данного случая применения это свойство не требуется

Идентификатор

Возможность

Комментарии/потребности МО

/DIDT.01/

FOOBAR 2.0 не поддерживает никакие средства прямого удаления информации, которые позволяют идентифицировать ПАЦИЕНТА

Принято к сведению МО.

Примечание - Для отдела закупок МО. Данная функциональная возможность прибора препятствует его использованию в исследованиях и преподавании

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

Идентификатор

Возможность

Комментарии/потребности МО

/STCF.01/

ДАННЫЕ о ЗДОРОВЬЕ, хранящиеся в собственной памяти FOOBAR 2.0 зашифрованы. Использующийся алгоритм: AES (Rijndael), Стойкость шифрования: 256 БИТ.

Замечание - Данная настройка не может быть изменена местным ИТ администратором

Для МО требуется больше информации о ПРОЦЕССЕ генерации ключа.

После того как генерация ключа производителем была завершена, необходимо выполнение ПРОЦЕССА, который бы разделял сторону, генерирующую ключ и тех, кто занимается аппаратной поддержкой, для предотвращения легальных проблем, связанных с неприкосновенностью частной жизни, в случаях, когда дефектный жесткий диск возвращается производителю для замены. Как выполняется управление ключом?

/STCF.02/

Защищенные/зашифрованные ДАННЫЕ о ЗДОРОВЬЕ доступны только после удачной загрузки. См. также /MLDP.04/

Принято к сведению МО

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

/STCF.03/

Дешифруются только требующиеся ДАННЫЕ о ЗДОРОВЬЕ (требующиеся для текущего взаимодействия/использования/отображения). Не используемые на данный момент ДАННЫЕ о ЗДОРОВЬЕ остаются зашифрованными

Принято к сведению МО

/STCF.04/

Загрузочный раздел, операционная система, временные данные или внутреннее запоминающее устройство большой емкости, и т.д. также шифруются. Используемый алгоритм: AES (Rijndael)/ Стойкость шифрования: 256 БИТ.

Замечание - Данная настройка не может быть изменена местным ИТ администратором

Принято к сведению МО

/STCF.05/

Случайные сбои питания в системе не влияют на шифрование ДАННЫХ о ЗДОРОВЬЕ, хранящихся на запоминающем устройстве большой емкости. Ни при каких обстоятельствах выполнения работы незашифрованные ДАННЫЕ о ЗДОРОВЬЕ не присутствуют на внутреннем запоминающем устройстве большой емкости

Принято к сведению МО

/STCF.06/

Соединение со специализированным удаленным архивом, находящимся в сети DICOM, может быть установлено с помощью VPN

Принято к сведению МО

Идентификатор

Возможность

Комментарии/потребности МО

/EMRG.01/

Наличие функции разбивания стекла. Даже без персонального идентификатора (id) пользователя и медицинской аутентификации пользователь может получить доступ к ДАННЫМ о ЗДОРОВЬЕ.

Замечание - Необходимо помнить, что данная функция может быть изменена/отключена местным ИТ администратором

Принято к сведению МО

/EMRG.02/

Использование функции разбивания стекла /EMRG.01/ требует использование общего идентификатора (id) пользователя и аутентификации (для предотвращения получения доступа к ДАННЫМ о ЗДОРОВЬЕ пациентами или сторонними наблюдателями)

Принято к сведению МО

/EMRG.03/

Каждое использование функции разбивания стекла /EMRG.01/ будет занесено в журнал аудита

Принято к сведению МО

/EMRG.04/

О каждом использовании функции разбивания стекла /EMRG.01/ может автоматически создаваться отчет для установления учетной записи пользователя, например посредством электронной почты (eMail)

Принято к сведению МО

Идентификатор

Возможность

Комментарии/потребности МО

/SGUD.01/

Руководство по защите для ОПЕРАТОРА включено в инструкции по использованию FOOBAR 2.0. См. главу 13

Принято к сведению МО

/SGUD.02/

Руководство по защите для администратора включено в техническую информацию FOOBAR 2.0. См. главу 17

Принято к сведению МО

Идентификатор

Возможность

Комментарии/потребности МО

/IGAU.01/

ДАННЫЕ о ЗДОРОВЬЕ, хранящиеся в памяти большой емкости FOOBAR 2.0 для отображения данных за пределами сети DICOM, защищены с помощью надлежащей контрольной суммы (SHA1), чтобы обеспечить целостность данных

МО осведомлена о недостатках алгоритма SHA1 и потому необходимо предоставить программное заявление о том, как производитель справляется с криптографическими проблемами защиты

/IGAU.02/

Предоставлены ВОЗМОЖНОСТИ по резервному копированию. См. главу, посвященную DTBK: Резервное копирование данных и аварийное восстановление

Принято к сведению МО

Идентификатор

Возможность

Комментарии/потребности МО

/MLDP.01/

Все несущественные порты сети FOOBAR 2.0 закрыты.

Замечание 01 - Более подробную информацию см. в технической информации FOOBAR 2.0, в руководстве по защите для администратора (глава 17). См. /SGUD.02/.

Замечание 02 - Данная функциональная возможность не может быть изменена местным ИТ администратором

Принято к сведению МО

/MLDP.02/

Операционная система, установленная на загрузочном устройстве FOOBAR 2.0, защищена от санкционированных/ несанкционированных изменений. После перезагрузки система возвращается в свое изначальное состояние.

Замечание - Данная функциональная возможность не может быть изменена местным ИТ администратором

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

/MLDP.03/

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

Замечание - Данная функциональная возможность не может быть изменена местным ИТ администратором

Принято к сведению МО

/MLDP.04/

Защищенные/зашифрованные ДАННЫЕ о ЗДОРОВЬЕ доступны только после успешной загрузки. См. также /STCF.01/.

Замечание - Данная функциональная возможность не может быть изменена местным ИТ администратором

Принято к сведению МО

Идентификатор

Возможность

Комментарии/потребности МО

/PAUT.01/

FOOBAR 2.0 поддерживает местное и глобальное управление учетными записями.

Замечание - Более подробную информацию см. в технической информации FOOBAR 2.0, в руководстве по защите для администратора (глава 17)

МО необходима точная спецификация для соединения с центральными структурами аутентификации (например, PKI, IEEE 802.1X)

Примечание - Предоставьте методические документы как можно скорее

/PAUT.02/

FOOBAR 2.0 поддерживает закрытие учетных записей.

Замечание - Более подробную информацию см. в технической информации FOOBAR 2.0, в руководстве по защите для администратора (глава 17)

Может ли это выполняться удаленно или же ИТ администратору необходимо находиться у прибора FOOBAR?

/PAUT.03/

FOOBAR 2.0 поддерживает быстрое переключение пользователей. Поддержка данной функции уменьшает затраты времени на задачу входа и выхода пользователей из системы

Принято к сведению МО

Идентификатор

Возможность

Комментарии/потребности МО

/PLOK.01/

По причине выбранного метода шифрования FOOBAR 2.0 не требуется физическое запирание

Принято к сведению МО

МО интересуется, защищена ли клавиатура или же неразрешенное устройство перехвата вводимой с клавиатуры информации (key-logger) может с легкостью быть установлено между клавиатурой и корпусом компьютера

На корпусе компьютера установлен замок? Можно ли с легкостью извлечь или заменить дисковые накопители?

Идентификатор

Возможность

Комментарии/потребности МО

/CSUP.01/

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

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

Замечание - Более подробную информацию см. в технической информации FOOBAR 2.0, в руководстве по защите для администратора (глава 17)

МО требуется следующая информация.

1 Должен существовать и быть раскрыт ПРОЦЕСС того, как значимые усовершенствования защиты и стабильности отделяются от незначимых.

2 Должен существовать и быть раскрыт ПРОЦЕСС, определяющий то, какие критерии должны выполняться для того, чтобы действия защиты от кибератак заслуживали САРА-сообщения.

3 Должен существовать и быть раскрыт ПРОЦЕСС, связанный с задержкой между объявлением от производителя операционной системы и реакций производителя МЕДИЦИНСКОГО ПРИБОРА

4. Должен существовать и быть раскрыт ПРОЦЕСС того, как МО оповещается об угрозах кибератак

/CSUP.02/

Прибор спроектирован так, что мы (производитель) не позволяем МО устанавливать какие либо несанкционированные патчи

Принято к сведению МО, а также в СОГЛАШЕНИЕ об ОТВЕТСТВЕННОСТИ будет добавлено заявление о том, что производитель несет полную ответственность за ВРЕД, причиненный пациентам, в связи с отсутствием подтверждения пакетов исправлений, требующих срочной установки

Идентификатор

Возможность

Комментарии/потребности МО

/RDMP.01/

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

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

Замечание - Более подробную информацию см. в технической информации о FOOBAR 2.0 (глава 42)

Должен существовать и быть раскрыт ПРОЦЕСС того как МО будет проинформирована о датах окончания срока службы критически важных компонентов. Нам необходимо знать, когда усовершенствование защиты перестает быть возможным

Идентификатор

Возможность

Комментарии/ потребности МО

/SAHD.01/

Все ВОЗМОЖНОСТИ, предназначенные обеспечить стабильную систему, предоставляющую только те службы, которые установлены ПРЕДНАЗНАЧЕННЫМ ИСПОЛЬЗОВАНИЕМ и требуются для его осуществления с минимумом сопроводительной деятельности, а также для того, чтобы позволить поставщикам медицинских услуг/МО организациям подключить FOOBAR 2.0 к их сети рассматриваются в главе MLDP: Обнаружение вредоносного программного обеспечения и защита от него в технической информации о FOOBAR 2.0 (глава 38)

Принято к сведению МО

Идентификатор

Возможность

Комментарии/потребности МО

/AUTH.01/

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

Замечание - Более подробную информацию см. в технической информации FOOBAR 2.0

Заявление будет принято в СОГЛАШЕНИИ об ОТВЕТСТВЕННОСТИ

/AUTH.02/

Так называемый вход в систему в качестве администратора предоставляется в случае FOOBAR 2.0 для:

- для общего администрирования сервера;

- установки обновлений/решения проблем;

- добавления большого количества клиентов FOOBAR;

- администрирования главных пользователей;

- операций по резервному копированию

/AUTH.03/

Так называемый вход в качестве Главного Пользователя (Master User) настраивается заранее и может быть добавлен для:

- внесения поправок в/объединения отчетов/данных пациентов;

- восстановления потерянных отчетов;

- администрирования общих пользователей;

- редактирования и поддержки общей конфигурации применения FOOBAR

Идентификатор

Возможность

Комментарии/потребности МО

/TXDF/.0M1/

См. /STCF.06/. Соединение со специализированным удаленным архивом, находящимся в сети DICOM, может быть установлено с помощью VPN.

Замечание - Более подробную информацию см. в технической информации FOOBAR 2.0 (глава 33)

МО требуется заявление о совместимости с конкретным VPN для определения истинной интероперабельности с существующими в MO VPN

/TXDF.02/

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

МО принимает к сведению и примет решение о требующихся сертификатах соответствия перед приобретением изделия

Идентификатор

Возможность

Комментарии/потребности МО

/TXIG.01/

См. /STCF.06/. Соединение со специализированным удаленным архивом, находящимся в сети DICOM, может быть установлено с помощью VPN. Данная функциональная возможность гарантирует сохранение целостности ДАННЫХ о ЗДОРОВЬЕ на протяжении передачи данных и позволяет FOOBAR 2.0 передавать ДАННЫЕ о ЗДОРОВЬЕ через относительно открытые сети или окружение, в котором действует крепкая политика обеспечения целостности ДАННЫХ о ЗДОРОВЬЕ.

Замечание - Более подробную информацию см. в технической информации FOOBAR 2.0 (глава 33)

Принято к сведению МО

Применение:

Профиль. Профиль IHE ATNA (Профиль журнала аудита и интеграции аутентификации узлов).

Профиль IHE PWP (Персональный телефонный справочник).

IHE EUA (Аутентификация корпоративных пользователей).

IHE XUA (Контроль процесса авторизации пользователей).

Политика. Проект политики защиты SANS.

Местная ИТ политика МО.

Требование источника:

Стандарт HIPAA, Правило обеспечения защиты, § 164.312.(a)(1): "..Управление доступом. Реализовать техническую политику и процедуры для электронных информационных систем, которые поддерживает электронную защищенную информацию о здоровье, для того, чтобы сделать возможным получение доступа только для тех личностей или программного обеспечения, которому были предоставлены права доступа в соответствии с § 164.308. (a)(4)..."

_______________

Министерство здравоохранения и социального обеспечения, секретариат, 45 CFR, части 160, 162, и 164 Реформа медицинского страхования. Стандарты защиты. Окончательный регламент, 20 февраля, 2003 (Department of Health and Human Services, Office of the Secretary, 45 CFR, Parts 160, 162, and 164 Health Insurance Reform; Security Standards; Final Rule, February 20, 2003).

Справочный материал:

2(i) Уникальная идентификация пользователя (требуется). Необходимо назначить уникальное имя и/или номер для идентификации и отслеживания личности пользователя.

NIST SP 800-53 v3.

АСЗ. Осуществление доступа (Access Enforcement) - механизмы осуществления доступа служат организациям для управления доступом между пользователями и объектами.

Зависит от:

AUDT, NAUT

Цель требований:

Политики аутентификации должны быть гибкими для того, чтобы адаптироваться к местной ИТ политике МО. Требование аутентификации личности при предоставлении доступа к ЗАЩИЩЕННЫМ ДАННЫМ о ЗДОРОВЬЕ (PHI) должно быть логически обоснованным в каждом конкретном случае.

Потребность пользователя:

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

Возможность управлять учетными записями на медицинском оборудовании для обеспечения защиты доступа к ЗАЩИЩЕННЫМ ДАННЫМ о ЗДОРОВЬЕ.

Пользователю может потребоваться связать персональные установки с учетными записями пользователей. Это может помочь приборам и системам, используемым множеством ОПЕРАТОРОВ, отделов или даже множеством организаций здравоохранения (МО). Требуется поддержка независимого и центрального администрирования.

Однократная идентификация и использование одного пароля для всех рабочих мест.

Поддержка идентификации узла согласно промышленным стандартам.

Обнаружение и предотвращение фальсификации личности/сущности (необходимо предоставить невозможность отказа от авторства).

Применение:

Профиль. Профиль IHE (Интеграция учреждений здравоохранения) ATNA. Профиль журнал аудита и интеграции аутентификации узлов [IHE ATN Aprofile (Audit Trail and Node Authentication Integration Profile].

IHE EUA (Аутентификация корпоративных пользователей).

IHE XUA (Контроль процесса авторизации пользователей).

Политика. NEMA/COCIR/JIRA Объединенный комитет по вопросам защиты и неприкосновенности частной жизни (Joint Security and Privacy).

Технический документ. Проект стандарта, рассматриваемого техническим комитетом: "Управление сертификатами аутентификации компьютеров, 10 февраля, 2005" (Committee draft White Paper: Management of Machine Authentication Certificates, 10 February 2005).

Проект политики защиты института SANS (институт системного администрирования, аудита, сети и защиты) (SANS Security Policy Project).

Местная ИТ политика МО.

Требование источника:

Стандарт HIPAA. Правило обеспечения защиты, § 164.312 Технические средства защиты. (а) (1): "..Управление доступом. Реализовать техническую политику и процедуры для электронных информационных систем, которые поддерживают электронную защищенную информацию о здоровье, для того, чтобы сделать возможным получение доступа только для тех личностей или программного обеспечения, которому были предоставлены права доступа в соответствии с §164.308. (a)(4)..."

Справочный материал:

NIST SP 800-53 v3

АСЗ. Осуществление доступа (Access Enforcement) - механизмы осуществления доступа служат организациям для управления доступом между пользователями и объектами

Зависит от:

AUDT, PAUT

Цель требований:

Политики аутентификации должны быть гибкими для того, чтобы адаптироваться к местной ИТ политике МО. Требование аутентификации личности при предоставлении доступа к ЗАЩИЩЕННЫМ ДАННЫМ о ЗДОРОВЬЕ (PHI) должно быть логически обоснованным в каждом конкретном случае.

Потребность пользователя:

Возможность управлять учетными записями на медицинском оборудовании для обеспечения защиты доступа к ЗАЩИЩЕННЫМ ДАННЫМ о ЗДОРОВЬЕ (PHI).

Однократная идентификация и использование одного пароля для всех рабочих мест.

Поддержка идентификации узла согласно промышленным стандартам.

Обнаружение и предотвращение фальсификации личности/сущности (необходимо предоставить невозможность отказа от авторства).

Применение:

Стандарт. Нет.

Политика. Местная ИТ политика МО.

Требование источника:

Стандарт HIPAA. Правило обеспечения защиты, § 164.312 Технические средства защиты. (a)(1): "..Управление доступом. Реализовать техническую политику и процедуры для электронных информационных систем, которые поддерживают электронную защищенную информацию о здоровье, для того, чтобы сделать возможным получение доступа только для тех личностей или программного обеспечения, которому были предоставлены права доступа в соответствии с § 164.308. (a)(4)..."

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

NIST 800-53, Издание 3 - Дополнительное руководство. Блокировка сеанса является временным действием, которая выполняется в том случае, если пользователь прекращает работу и не осуществляет непосредственные действия с информационной системой, но не желает выходить из системы (завершать сеанс) из-за того, что его отсутствие является временным.

АС-11 БЛОКИРОВКА СЕАНСА. Управление. Информационная система:

a. предотвращает дальнейший доступ к системе с помощью запуска блокировки сеанса после [Установление периода времени, заданного организацией.] бездействия или при получении запроса от пользователя; и

b. сохраняет блокировку сеанса до тех пор, пока пользователь не восстановит доступ, используя утвержденные процедуры идентификации и аутентификации.

Справочный материал:

Нет.

Зависит от:

AUDT

Цель требований:

Уменьшить РИСК получения несанкционированного доступа к ЗАЩИЩЕННЫМ ДАННЫМ о ЗДОРОВЬЕ (PHI) с рабочего места, оставленного без присмотра.

Предотвратить неправильное использование, если система или рабочее место не используется в течение периода времени.

Потребность пользователя:

Несанкционированные пользователи не могут получить доступ к ЗАЩИЩЕННЫМ ДАННЫМ о ЗДОРОВЬЕ (PHI) с рабочего места, оставленного без присмотра.

Сеансы авторизованных пользователей должны автоматически завершаться или блокироваться по прошествии заранее установленного промежутка времени. Это уменьшает РИСК несанкционированного доступа к ЗАЩИЩЕННЫМ ДАННЫМ о ЗДОРОВЬЕ (PHI), если авторизованный пользователь покидает рабочее место, не завершая сеанс и не закрывая экран или комнату.

Автоматический выход из системы должен включать в себя очистку ЗАЩИЩЕННЫХ ДАННЫХ о ЗДОРОВЬЕ (PHI) со всех экранов по мере необходимости.

Местный авторизованный ИТ администратор должен иметь возможность отключать эту функцию и устанавливать время истечения срока (учитывая хранителя экрана).

Использование хранителя экрана с коротким временем бездействия или активирующегося "быстрой клавишей" может являться дополнительным свойством. Такая очистка экрана с ДАННЫМИ о ЗДОРОВЬЕ может быть вызвана, если на протяжении короткого времени не была нажата ни одна клавиша (например, от 15 секунд до нескольких минут). Это не завершит сеанс пользователя, но снизит РИСК случайного наблюдения информации.

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

Возможности

Характеристики защиты

Конфиденциальность

Целостность

Готовность

Отслеживаемость

ALOE. Автоматический выход из системы

2

2

-1

AUDT. Средства управления аудитом

1

1

1

AUTH. Авторизация

2

2

-1

1

CNFS. Конфигурация свойств системы защиты

1

1

1

1

CSUP. Усовершенствование системы защиты изделия от кибератак

1

1

1

DTBK. Резервное копирование данных и экстренное восстановление

1

2

EMRG. Экстренный доступ

2

-1

DIDT. Деидентификация ДАННЫХ о ЗДОРОВЬЕ

2

IGAU. Целостность и аутентификация ДАННЫХ о ЗДОРОВЬЕ

2

2

STCF. Конфиденциальность хранения ДАННЫХ о ЗДОРОВЬЕ

2

MLDP. Обнаружение вредоносного программного обеспечения и защита от него

1

1

1

NAUT. Аутентификация узлов

1

1

PAUT. Аутентификация личности

1

2

PLOK. Физические замки на приборе

1

1

1

SGUD. Руководства по защите

1

1

1

1

SAHD. Усиление защиты системы и приложений

1

1

1

RDMP. Влияние компонентов третьей стороны на весь жизненный цикл изделия

TXDF. Конфиденциальность передачи данных

2

TXIG. Целостность передачи данных

2

Обозначение ссылочного международного стандарта

Степень соответствия

Обозначение и наименование соответствующего национального стандарта

МЭК 80001-1:2010

-

*

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

[1]

EC 60300-3-9:1995

Dependability management - Part 3-9: Application guide - Risk analysis of technological systems

[2]

EC 60601-1-6:2006

Medical electrical equipment - Part 1-6: General requirements for basic safety and essential performance - Collateral standard: Usability

[3]

EC 60601-1-8:2006

Medical electrical equipment - Part 1-8: General requirements for basic safety and essential performance - Collateral standard: General requirements, tests and guidance for alarm systems in medical electrical equipment and medical electrical systems

[4]

EC 61907:2009

Communication network dependability engineering

[5]

EC 62304:2006

Medical device software - Software life cycle processes

[6]

EC 80001-2-1

Application of risk management for IT-networks incorporating medical devices - Part 2-1: Step by step risk management of medical IT-networks - Practical applications and examples EC 80001-2-3, Application of risk management for IT-networks incorporating medical devices - Part 2-3: Guidance for wireless networks

[7]

ISO/EC 15408

Information technology - Security techniques - Evaluation criteria for IT security - Parts 1, 2, and 3 ["Common Criteria"]

[8]

ISO/EC 20000-1:2011

Information technology - Service management - Part 1: Service management system requirements ISO/IEC 20000-2:2012, Information technology - Service management - Part 2: Guidance on the application of service management systems

[9]

ISO/EC 27001:2005

Information technology - Security techniques - Information security management systems - Requirements

[10]

ISO/EC 27002:2005

Information technology. Security techniques. Code of practice for information security management ISO/IEC 27005:2011, Information technology - Security techniques - Information security risk management

[11]

ISO 13485:2003

Quality management systems - Requirements for regulatory purposes ISO/TS 13606-4:2009, Health informatics - Electronic health record communication - Part 4: Security

[12]

ISO 14971:2007

Medical devices - Application of risk management to medical devices

[13]

ISO/TS 25238:2007

Health informatics - Classification of safety risks from health software

[14]

ISO 27799:2008

Health informatics - Information security management in health using ISO/IEC 27002

[15]

ISO/TR 27809:2007

Health informatics - Measures for ensuring patient safety of health software

[16]

IEEE 610.12:1990

IEEE Standard Glossary of Software Engineering Terminology

ASIP requirements

FR I'Agence des d'lnformation de (ASIP ) [ASIP , the shared healthcare information systems agency //esante.gouv.fr/en] creating conditions to comply with Law No. 2002-303 of 4 March 2002 on patients' rights and quality care system

DICOM

Digital Imaging and Communications in Medicine (DICOM)

National Electrical Manufacturers Association.

//medical.nema.org/dicom/

Japan Law/Guidance

JP Act on the Protection of Personal Information (PFD)

//www.caa.go.jp/seikatsu/kojin/index_en.html and Guideline for Medical Information System Safety Management

//www.mhlw.go.jp/shingi/2010/02/s0202-4.html (Japanese only), Ministry of Health, Labour and Welfare, Japan

NEMA/COCIR/JIRA

Joint Security and Privacy Committee. See tutorials and white papers at

//www.medicalimaging.org/policy-and-positions/jointsecurity-and-privacy-committee-2/

NEN 7510

NL Nederlands Normalisatie-instituut Standard Medische

informatica - Informatiebeveiliging in de zorg - Algemeen [Health Informatics - Information Security in the Healthcare Sector - General] //www.nen.nl/

web/Normshop/Norm/NEN-75102004-nl.htm

NIST 800 series

US National Institute of Standards and Technology Special

Publications series on Computer Security

//csrc.nist.gov/publications/PubsSPs.html

УДК 004:61:006.354

ОКС 35.240.80

П85

ОКСТУ 4002

Ключевые слова: здравоохранение, информатизация здоровья, информационная безопасность, менеджмент рисков, информационно-вычислительные сети, медицинские приборы