ZX_医院信息化系统三级等保安全标准及建设分享

医院信息化系统
三级等保安全标准及建设分享
汇报人: 周兴 2019年08月
背景介绍、原则与标准、等级评估 安全保障体系、等保方案设计与框架 等级保护软件开发安全管理 等级保护网络安全审计 边界访问控制、网关防病毒
背景介绍
门诊方面：挂号、收费、发药、护士分诊、大夫看病需借助门诊信息系统； 病房方面：每天大夫查房、开医嘱，护士给患者发药等需借助住院信息系统； 患者在医院做化验、照片子等都需要借助医院信息系统完成。
受破坏的风险，公司应考虑采取如下控制措施： • 程序运行库（operational program libaries）的升级只能由指定的程序库管理员
在获取授权后予以完成。 • 操作系统应尽可能只保留应用程序的可执行代码。 • 在系统测试、用户验收结束之前，及相应的程序源代码库升级之前，可执行代
码不得在操作系统中运行。 • 程序运行库的所有更新记录都应当予以保留。 • 历史版本的软件应当予以保留，用作应急措施。
医院信息系统已经成为医院不可缺少的工具。在这种情况下，医院信息系统一旦 出现问题，整个医院将无法运行。因此，医院信息系统的安全问题直接关系到病 人的利益，医院信息系统出现故障，将造成病人无法就诊、无法及时得到有效的 治疗。
安全问题关系到病人的利益，如何保障医院信息安全，确保业务连续性，是各大 医院面临的共同挑战。
技术与管理相结合原则：信息安全涉及人、技术、操作等各方面要素，单靠技术或单靠管理都不可能实现。因此在 考虑信息系统信息安全时，必须将各种安全技术与运行管理机制、人员思想教育、技术培训、安全规章制度建设相 结合。
动态发展和可扩展原则：随着网络攻防技术的进一步发展，网络安全需求会不断变化，以及环境、条件、时间的限 制，安全防护一步到位，一劳永逸地解决信息安全问题是不现实的。信息安全保障建设可先保证基本的、必须的安 全性和良好的安全可扩展性，今后随着应用和网络安全技术的发展，不断调整安全策略，加强安全防护力度，以适 应新的网络安全环境，满足新的信息安全需求。
分域防护、综合防范的原则：任何安全措施都不是绝对安全的，都可能被攻破。为预防攻破一层或一类保护的攻击 行为无法破坏整个信息系统，需要合理划分安全域和综合采用多种有效措施，进行多层和多重保护。
需求、风险、代价平衡的原则：对任何类型网络，绝对安全难以达到，也不一定是必须的，需正确处理需求、风险 与代价的关系，等级保护，适度防护，做到安全性与可用性相容，做到技术上可实现，经济17859-1999 计算机信息系统安全保护等级划分准 GB/T 25058-2010 信息安全技术 信息系统安全等级保护实施指南 系统定级 GB/T 22240-2008 信息安全技术 信息系统安全保护等级定级指南 技术方面 GB/T 22239-2008 信息安全技术 信息系统安全等级保护基本要求 GB/T 20270-2006 信息安全技术 网络基础安全技术要求 GB/T 20271-2006 信息安全技术 信息系统通用安全技术要求 GB/T 20272-2006 信息安全技术 操作系统安全技术要求 GB/T 20273-2006 信息安全技术 数据库管理系统通用安全技术要求 GA/T671-2006 信息安全技术 终端计算机系统安全等级技术要求 GA/T 709-2007 信息安全技术 信息系统安全等级保护基本模型 管理方面 GB/T 22239-2008 信息安全技术 信息系统安全等级保护基本要求 ISO/IEC 27001 信息系统安全管理体系标准
软件开发安全管理 —— 开发过程安全
➢ 外包开发的安全控制 在外包软件开发时，应注意以下几点要求： • 选择信誉与质量保证能力好的软件承包商。 • 软件许可权协议、代码所有关系以及知识产权。 • 对外包工作质量和准确性的检验，并保留检查权利。 • 承包方违约时应该采取的措施。 • 代码质量的合同要求，如对编程标准的要求。 • 在安装之前进行测试，以检测后门、逻辑炸弹和特洛伊代 码。
等级评估
根据国家针对计算机信息系统安全等级保护的相关规定。
保护对象 HIS 系统 PACS 系统 终端系统
定级备案 技术要求选择
3
S3A2G3
3
S3A2G3
3
S3A2G3
注：S\A\G是指《信息系统等级保护基本要求》里定义的要求项，其中S是信息安全类要求，A是服务保证 类要求，G是通用安全保护类。后面的数字代表等级，S3的意思也就是信息安全类3级要求，以此类推。
软件开发安全管理 —— 设计安全
➢ 系统测试数据的保护 • 用于正式运营系统的访问控制程序，也应用于测试环境。 • 在测试结束后，测试数据应当马上从测试系统中删除。 • 测试数据的加载和使用应当被记录在案，以便检查跟踪。
➢ 应用系统源代码访问控制 • 源代码尽量不要保留在操作系统内。 • 为每个系统指定程序库管理员。 • 控制系统支持人员对程序源代码库的访问。 • 处于开发和维护阶段的程序不得保留于运程序源代码库中。 • 程序源代码库的更新及发布只能由指定的程序库管理员在经过该应用的主管领导授权后实施。 • 程序清单应当保存在安全环境中。 • 对程序源代码库的所有访问都应保留审计日志。 • 老版本的源程序应当归档，并清楚记录其被正式使用的确切日期和具体时间，及所有相关的 支持软件、功能说明、数据定义和程序（如流程图）等。 • 程序源代码库的维护和拷贝应当遵从严格的变更控制程序。
由本公司负责将来的软件维护工作。 • 若修改必不可少，则应保留原始软件，并在原始软件的清洁拷贝上进
行。 • 全面测试所作的修改，并记录在案，以便必要时重新应用于将来的软
件升级。
软件开发安全管理 —— 开发过程安全
➢ 恶意代码控制
后门、逻辑炸弹和特洛伊代码都属于恶意代码范畴，对网络与信息系统 有重大的潜在威胁。在软件的原始采购、开发、使用和维护过程中，应采取 如下防范控制措施： • 仅从信誉卓著的厂商处购买软件。 • 购买提供源代码的软件，以便进行检验。 • 使用通过权威机构评估测试的软件产品。 • 在投入使用之前检查所有源代码。 • 一旦安装完毕，控制对源代码的访问和修改。 • 使用可靠人员操作关键系统。 • 不得随意运行未经检测的软件，如电子邮件附件。 • 安装并正确使用有关后门、特洛伊代码的检测和查杀工具。
等级保护技术方案框架
软件开发安全管理 —— 需求安全
必须在应用系统开发、修改或者投入使用之前指定应用系统责任人。 在应用系统开发、修改或者投入使用之前，必须完成风险评估、业
务影响评估、备份和灾难恢复方案。 确保开发、测试与运行设备的分离。 应用系统责任人负责标明应用的信息分类级别。 系统开发过程中应不断咨询操作部门及用户的意见，以提高所设计
安全体系保障
三个防御维度：技术、管理、运维全方位的纵深防御
等级保护技术方案设计
参考等级保护技术方案设计规范，从信息系统安全涉及角度，安全信息系统可 以看成是由应用安全支撑平台和在其上运行的应用系统两部分组成。
应用安全支撑平台又是由信息安全机制和信息安全基础技术支持来实现的，其 中信息安全基础技术包括密码基础、系统安全技术、网络安全技术以及其他安 全技术； 这些技术提供了身份认证、访问控制、安全审计、可用性保护、机密 性保护、完整性保护、监控、隔离、过滤等安全机制，用以形成覆盖计算环境、 区域边界、通信网络的等级保护技术方案，同时通过引入多级互联机制以及安 全管理中心， 则构成了多级的安全信息系统。
问题说明
1、之前医院信息系统安全运维标准化工作较为完善，但各个应用系统较为分散， 没有形成统一运维的安全管理机制；网络系统内涉及的硬件设备、系统平台种类 繁多，安全监控指标复杂，不能很好的实现分安全域进行安全隔离监管。
2、安全防护存在一定程度的缺陷，一旦有新的攻击技术，现有安全防护体系应 对外界攻击的能力较差，需要提升现有安全设备防护能力。网络病毒入侵攻击时 有发生，一旦应用系统存在防护缺口，将对整个医院的信息安全构成极大的威胁。
系统的操作效率。 当涉及系统开发外包或合作开发时，安全需求应在双方认可的合同
或协议中给予明确规定。如果可能，可采用通过公正的第三方独立 评估和认证的产品。
软件开发安全管理 —— 设计安全
➢ 输入数据检查 • 应用系统不应在程序或进程中固化账户和口令。 • 系统应具备对口令猜测的防范机制和监控手段。 • 避免应用程序以错误的顺序运行，或者防止出现故障时后续程序以不正常的 流程运行。 • 采用正确的故障恢复程序，确保正确处理数据。 • 采取会话控制或批次控制，确保更新前后数据文件的一致性，例如：检查操 作前后文件打开和关闭的数目是否一致。 • 检查执行操作前后对象的差额是否正常，如：句柄处理，堆栈等系统资源的 占用与释放等。 • 严格验证系统生成的数据。 • 在中央计算机和远程计算机之间，检查下载/上传的数据或软件的完整性。 • 检查文件与记录是否被篡改。例如通过计算哈希值（HASH）进行对比。
3、信息系统等级保护管理缺乏硬件设施。
4、尽管已经具备一套较为完善的应急响应和应急演练机制，但随着医院对信息 系统依赖度的不断加深，信息系统尤其是数字化的医疗信息系统发生风险事件的 可能性也不断加大，迫切需要对现有的信息系统应急预案和应急处置措施进行加 固和持续提升。
整改原则
清晰定义模型的原则：在设计信息安全保障体系时，首先要对信息系统进行模型抽象，这样既能相对准确地描述信 息体系的各个方面的内容及其安全现状，又能代表绝大多数地区和各种类型的信息系统。把信息系统各个内容属性 中与安全相关的属性抽取出来，参照IATF（美国信息安全保障技术框架），建立“保护对象框架”、“安全措施框 架”、“整体保障框架”等安全框架模型，从而相对准确地描述信息系统的安全属性和等级保护的逻辑思维。
软件开发安全管理 —— 开发过程安全
➢ 变更控制 • 保留变更的授权级别记录。 • 确保由授权用户提交变更申请。 • 审查变更控制措施和流程的完整性，确保未被修改和破坏。 • 识别所有要求修改的计算机软/硬件、信息、数据库实体。 • 及时发布操作系统的变更通知。 • 在实施之前，详细的变更方案必须获得正式批准。 • 在实施之前，确保授权用户接受变更。 • 选择恰当的变更时间，确保在具体实施过程中最大限度地减少业务影响。 • 确保操作系统的更改不会对应用系统的安全性和完整性造成不良影响。 • 确保系统文档在每次修改后得到及时更新，并确保旧文档被正确归档和处置。 • 做好软件升级的版本控制，如保存历史版本。 • 保留所有变更的审计跟踪记录。 • 确保操作文档以及用户程序能在必要时被修改。 • 确保及时更新业务连续性计划。