信息系统密钥管理测评对象

9.3.12　信息系统的获取、开发及维护

12.1　信息系统的安全要求

目标：确保安全成为信息系统的内置部分。

这将包括操作系统、基础设施、业务应用、非定制的产品、服务和用户开发的应用。支持应用或服务的业务过程的设计和实施可能是安全的关键。在信息系统开发之前应标识出并商定安全要求。

应在项目的要求阶段标识出所有安全要求，并证明这些安全要求是正确的，对这些安全要求加以商定，并且将这些安全要求形成文档作为信息系统整个业务情况的一部分。

其安全要求分析和规范如下：

控制

新的信息系统或对现有信息系统的更新的业务要求声明中应规定安全控制的要求。

实施指南

控制需求规范应考虑在系统中所包含的自动化控制以及支持人工控制的需要。当评价业务应用（开发或购买）的软件包时，应进行类似的考虑。

安全要求和控制应反映出所涉及信息资产的业务价值和潜在的业务损坏，这可能是由于安全失败或缺少安全引起的。

信息安全系统需求与实施安全的过程应该在信息安全工程的早期阶段集成。在设计阶段引入控制其实施和维护的费用明显低于实现期间或实现后所包含的控制费用。

如果产品是购买的，则购买产品之后就进行常规的测试和需求处理。与供货商签的合同上应确切地标明安全需求。一旦推荐商品的安全功能不能满足安全要求，则在购买商品之前应重新考虑引进和相关控制的风险。如果产品的附加功能引起了一些安全风险，则这个产品是不能用的，或者增加的功能优点突出，则可以对推荐的控制结构重新讨论决定。

其他信息

如果适当考虑花费的因素，管理层可能更愿意使用已独立评价和认证的产品。关于IT安全产品的评估准则的其他信息可见ISO/IEC 15408，或者其他评估和认证标准。ISO/IEC TR 13335-3提供了应用风险管理过程去确认安全控制要求的指南。

12.2　应用系统的正确处理

目标：防止应用系统信息的错误、丢失、未授权的修改或误用。

应用系统（包括用户开发的应用）内应设计合适的控制以确保处理的正确性。这些控制应包括输入数据、内部处理和输入数据的确认。

对于处理敏感的、有价值的或关键的组织资产的系统或对上述组织资产有影响的系统可以要求附加控制。这样的控制应在安全要求和风险评估的基础上加以确定。

12.2.1　输入数据确认

控制

应验证应用系统输入数据，以确保正确和适当。

实施指南

检验应适用于业务事务处理、常备数据（名字和地址，信贷限值，顾客引用号码）和参数表（销售价，货币兑换率，税率）的输入。应考虑下列控制：

a) 双输入或其他输入检验，比如边界检查或者限制具体范围的输入数据，以检测下列差错：

1) 范围之外的值；

2) 数据字段中的无效字符；3) 丢失或不完整的数据；

4) 超过数据的上下容量极限；

5) 未授权的或不相容的控制数据；

b) 周期性评审关键字段或数据文件的内容，以证实其有效性和完整性；

c) 检查硬拷贝输入文档是否有任何未授权的变更输入数据（输入文档的所有变更均应予以授权）；

d) 响应确认差错的程序；

e) 测试输入数据真实性的程序；

f) 定义在数据输入过程中所涉及的全部人员的职责。

g) 创建一个数据输入过程中的行为日志。

其他信息

考虑在应用中对输入数据进行自动检查和确认，以减少出错的风险，防止缓冲区溢出和代码注入等标准攻击。

12.2.2　内部处理控制

控制

应用系统中应包含确认检查，以检测数据处理过程中的错误。

实施指南

应用系统的设计与实施应确保由于处理失败导致的完整性被损坏的风险减至最小。考虑的特定风险区域包括：

a) 使用程序中的增加、修改和删除功能，以实现数据变更；

b) 防止程序以错误次序运行或在前面的处理故障后运行的程序；

c) 使用从失效中恢复的正确程序，以确保正确处理数据。

d) 防止利用缓冲区溢出进行的攻击。

应该准备适当的检测列表，检测行为需要记录文档，检测结果要保持安全。可以包括的检验的例子包括如下：

a) 会话或批量控制，以便在事务处理更新之后调解数据文件平衡；

b) 平衡控制，对照先前的封闭平衡来检验开放平衡，即：

1) 运行至运行的控制；

2) 文件更新总量；

3) 程序至程序的控制；

c) 确认系统生成的输入数据（见10.2.1）；

d) 检验在中央计算机和远程计算机之间所下载或上载的数据或软件的完整性、真实性或者其他任何安全特性（见10.3.3）；

e) 求所有记录和文件的散列函数值；

f) 检验以确保应用程序在正确时刻运行；

g) 检验以确保程序以正确的次序运行并且在故障情况下终止；进一步处理被停止，直到解决问题为止。

h) 创建一个有关处理的行为日志。

其他信息

正确输入的数据可能被硬件错误、处理错误和故意的行为破坏。确认性检查的需求取决于应用的特点和毁坏的数据对业务的影响。

12.2.3　消息完整性

控制

应识别应用系统中确保鉴别和保护消息完整性的要求，识别并实施适当的控制。

实施指南

需要进行安全风险的评估以确定是否需要报文完整性，以确定实施中的最合适的方法。

其他信息

密码技术（见10.3.2和10.3.3）是一种能实现报文鉴别的合适手段。

12.2.4　输出数据确认

控制

应确认应用系统输出的数据，以确保存储的信息的处理是正确的并与环境相适宜。

实施指南

输出确认可以包括：

a) 真实性检验，以测试输出数据是否合理；

b) 调解控制计数，以确保处理所有数据；

c) 对信息阅读者或后续处理系统提供足够的信息，以确定信息的准确性、完备性、精确性和分类；

d) 响应输出确认测试的程序；

e) 定义在数据输出过程中所涉及的全部人员的职责。

f) 创建一个输出数据确认行为的日志。

其他信息

典型地，系统和应用是在假设已经具备了适当的确认、认证、测试和输出数据总是正确的条件下构建的。然而这种假设并不总是正确的，例如，一个经过检测的系统在一些环境下会产生不正确的输出。

12.3　加密控制

目标：通过加密手段来保护信息的保密性、真实性或完整性。

应该制定使用密码的策略。密钥管理应该支持使用密码技术。

12.3.1　使用加密控制的策略

控制

为保护信息，应开发并实施加密控制的使用策略。

实施指南

制定密码策略时，应考虑下列内容：

a) 关于跨越组织使用密码控制的管理方法，包括保护业务信息的一般原则；

b) 基于风险评估确认要求的保护级别，包括要求的加密算法的类型、强度和质量；

c) 使用密码技术保护用移动电话、可移动介质、设备或者通过通信线路传输的敏感信息；

d) 密钥管理方法，包括密码密钥的保护，密钥遗失、泄密和毁坏后加密数据的恢复；

e) 角色和职责。谁负责：

1) 策略的实施；

2) 密钥管理，包括密钥的生成。

f) 为在整个组织有效实施而采用的标准（哪种解决方法用于哪些业务过程）；

g) 使用密码技术对控制的影响依赖于内容检查（例如病毒检查）。

当实施整个组织的密码策略时，应该考虑世界不同地区应用密码技术的规定和限制，也应考虑加密信息在出入境时的限制。（见15.1.6）可以使用密码技术去获得不同的安全目标：

a) 保密性：用信息加密去保护存储的和传输中的敏感和重要数据。

b) 完整性/可认证性：用数字签名和消息验证码去保护存储的和传输中的敏感和重要数据的可认证性和完整性。

c) 不可否认性：利用密码技术获得事件和行为发生或未发生的证明。

其他信息

一个密码解决方案是否合适，需要根据广泛的风险评估和选择控制来做出决定。这些评估可以用来判断一个密码控制是否合适，应该用什么类型的控制以及是应用于什么目的和业务流程。

一个应用密码控制的策略需要使其利益最大化，使利用密码技术的风险最小化，并尽量避免不合适和不正确的使用。在应用数字签名时，需要考虑任何相关的法律，特别是规定什么条件下数字签名被合法绑定的法律（参见15.1）。

提供需要的保护和实施安全密钥管理系统需要由专家确认适当的保护级别和定义适当的规范。

ISO/IEC JTC1 SC27已经制定了几个与密码控制有关的标准。更多的信息可以从IEEEP 1363和OECD指南中获得。

12.3.2　密钥管理

控制

应进行密钥管理，以支持组织对密码技术的使用。

实施指南

所有的密码密钥要防止修改、遗失和毁坏。另外，秘密和私有密钥需要防止非授权的泄露。用来生成、贮存和归档密钥的设备需要进行物理保护。

密钥管理系统应基于一组已商定的标准、规程和方法，以便：

a) 生成用于不同密码系统和不同应用的密钥；

b) 生成和获得公开密钥证书；

c) 分发密钥给预期用户，包括应如何激活收到的密钥；

d) 存储密钥，包括已授权用户如何访问密钥；

e) 变更或更新密钥，包括何时变更密钥以及如何变更密钥的规则；

f) 处理已泄露的密钥；

g) 撤销密钥，包括如何取消或解除激活的密钥，例如，当密钥已泄露时或当用户离开组织时（在这种情况下，密钥也要归档）；

h) 恢复密钥，作为业务连续性管理的一部分，恢复已丢失或损坏的密钥，例如，加密信息的恢复；

i) 归档密钥，例如，对已归档的或备份的信息的密钥归档；

j) 销毁密钥；

k) 记录和审核与密钥管理相关的活动。

为了减少泄露密钥的可能性，密钥应具有已定义的激活日期和解除激活日期，以使它们只能用于有限的时间周期。这个时间周期应根据所使用的密码控制的情况和所评估的风险而定。

除了安全管理秘密密钥和私有密钥外，还要考虑公开密钥的保护。这些认证过程可以由证书认证机构颁发的公钥证书来完成，该认证机构是一公认的组织，具有合适的控制和规程，可提供所要求的可信等级。

与外部密码服务提供者（例如与认证机构）签署的服务级协议或合同的内容应涵盖服务条款方面的服务责任、服务可靠性和响应次数的若干问题（见6.2.3）。

其他信息

密钥的管理对有效使用密码技术来说是必需的。ISO/IEC 11770提供了更多密钥管理的信息。下面给出了两密钥管理技术：

a) 秘密密钥技术，其中双方或更多方共享同一密钥，并且该密钥用来加密和解密信息。这个密钥必须被秘密地保存，因为访问过它的任何人能使用该密钥来解密被加密的所有信息，或引入未授权的信息。

b) 公开密钥技术，其中每个用户拥有一对密钥，一个公开密钥（它可以被展现给任何人）和一个私有密钥（它必须被秘密地保存）。公开密钥技术可用于加密，并可用来产生数字签名（参见ISO/IEC 9796和ISO/IEC 14888）。存在某人用他自己的公开密钥替换某用户的公开密钥伪造数字签名的威胁。密码技术可以用来保护密钥。规程可以考虑处理访问密钥的合法请求，例如，加密的信息可能需要以未加密的形式提供，以作为法庭案例的证据。

12.4　系统文件安全

目标：确保系统文件的安全。

要严格控制访问系统文件和程序源代码。按安全方式管理IT项目和支持活动。在测试环境中应注意不能泄露敏感数据。

12.4.1　操作软件控制

控制

应建立程序，对操作系统软件安装进行控制。

实施指南

为使运行系统被损坏的风险减到最小，应考虑下列控制：

a) 仅由受过专业培训的管理员根据相应的管理授权进行操作软件、应用和运行程序库的更新（见12.4.3）；

b) 运行系统只安装经核准的可执行代码，不安装开发代码和编译器；

c) 应用和操作系统软件只有在全面正确的测试后才能安装，测试包括实用性、安全性、在其他系统上的有效性，用户友好性，测试需要在独立的系统上完成，必须确保对应的程序库已经更新；

d) 应用配置控制系统去控制所有已开发的软件和系统文件；

e) 系统在修改之前应进行反复考虑；

f) 应维护对运行程序库的所有更新的审核日志；

g) 应保留软件的先前版本作为应急措施；

h) 软件的旧版本，包括需要的信息、参数、过程、配置细节都要归档，配套有文件和数据也要归档。

在运行系统中所使用的由厂商供应的软件应在供应商支持的级别上加以维护。过时后，软件供应商应停止提供旧版本的软件，组织应考虑依赖不支持软件的风险。

升级到新版的任何判定应考虑到该新版的安全，即，新安全功能度的引入或影响该版本安全问题的数量和严重程度。当软件补丁有助于消除或减少安全弱点时，应使用软件补丁（见12.6.1）。

必要时在管理层批准的情况下，仅为了支持目的，才授予供应商物理或逻辑访问权。应监督供应商的访问活动。

计算机软件可能依赖于外部提供的软件和模块，对这些产品应该进行监控，以防止非授权的修改，因为这些修改可能带来安全问题。

其他信息

操作系统只有在需要升级的时候才进行升级，比如说，当操作系统的当前版本不能支持业务需求的时候。只有有了新版本的操作系统后才能进行升级。新版本的操作系统可能在安全、稳定和便于理解方面不如当前版本的操作系统。

12.4.2　系统测试数据的保护

控制

应谨慎选择测试数据，并加以保护和控制。

实施指南

应避免使用包含个人信息和其他敏感信息的运行数据库作为测试目的用。如果使用这种信息，在使用之前应除去个人化信息。当用于测试目的时，应使用下列控制保护运行数据：

a) 访问控制规程，适用于运行应用系统，还应适用于测试应用系统；

b) 运行信息每次被拷贝到测试应用系统应予以分别授权；

c) 在测试完成之后，应立即从测试应用系统清除运行信息；

d) 为提供审核踪迹，应记录运行信息的拷贝和使用。

其他信息

系统和验收测试常常要求相当大的尽可能接近运行数据的测试数据量。

12.4.3　对程序源代码的访问控制

控制

应限制对程序源代码的访问。

实施指南

对程序源代码和相关事项（包括设计、规范、证明设计和确认设计）的访问应该严格禁止，以防止带入一些非授权功能，避免对源代码的无意识的修改。程序源代码可以放在中央存储区中，最好放在程序代码库中。为了控制对程序源代码库的访问以减少对计算机程序破坏的可能，应该遵守下面的指南：

a) 若有可能，在运行系统中不应保留源程序库；

b) 程序源代码和程序源库应根据制定的程序进行管理；

c) 支持人员不应不受限制地访问源程序库；

d) 更新源程序库和有关事项、向程序员发布源程序应在授权之后进行；

e) 程序列表应保持在安全的环境中（见12.7.4）；

f) 应维护对源程序库所有访问的审核日志；

g) 维护和拷贝源程序库应受严格变更控制规程的制约（见12.5.1）。

其他信息

程序源代码是由程序员编写的代码，经编译（连接）后产生执行代码。有的语言不能正常区分源程序代码和执行代码，这是因为执行代码是随程序产生而产生的。

标准ISO 1007和ISO/IEC 12207提供了更多关于配置管理和软件生命周期过程的信息。

12.5　开发和支持过程安全

目标：保持应用系统软件和信息的安全。

应严格控制项目和支持环境。

负责应用系统的管理者，也应负责项目和支持环境的安全。他们应确保评审所有建议的系统变更，以检验这些变更既不损坏该系统亦不损害操作环境的安全。

12.5.1　变更控制程序

控制

应通过正式的变更控制程序，控制变更的实施。

实施指南

为使信息系统的损坏减到最小应实施正式的变更控制规程。它们应确保不损坏安全和控制规程，并将变更控制规程文档化，引进新的系统和对已有系统进行大的变更要按照从文档、规范、测试、质量管理到实施管理这个正常的过程进行。

这个过程应包括风险评估、变更效果分析、安全控制规范。它们应确保不损坏安全和控制规程，确保支持性程序员仅能访问其工作所需的系统的某些部分，确保对任何变更要获得正式商定和批准。

只要可行，应用和操作变更控制规程应集成起来（见10.1.2）。该过程应包括：

a) 维护所商定授权级别的记录；

b) 确保由授权的用户提交变更；

c) 评审控制和完整性规程，以确保它们不因变更而损坏；

d) 标识要求修正的所有计算机软件、信息、数据库实体和硬件；

e) 在工作开始之前，获得对详述建议的正式批准；

f) 确保在任何实施之前，已授权的用户接受变更；

g) 为使业务损坏减到最小，确保完成实施；

h) 维护所有软件更新的版本控制；

i) 维护所有变更请求的审核踪迹；

j) 当需要时，确保对操作文档（见10.1.1）和用户规程作合适的修改；

k) 确保变更的实施发生在正确的时刻，并且不干扰所涉及的业务过程。

其他信息

变更软件会影响运行环境。

实践表明，要在一个与生产与开发完全隔离的环境中测试新软件（见10.1.4）。这提供对新软件进行控制和允许对运行信息（用于测试目的）给予附加保护的手段。这包括打补丁、服务包和其他更新。自动更新可以用在重要系统中，在这些系统中一些更新会引起一些重要应用的失败（见12.6）。

12.5.2　操作系统变更后的应用系统技术评审

控制

当操作系统变更后，应评审并测试关键的业务应用系统，以确保变更不会对组织的运营或安全产生负面影响。

实施指南

该过程应涵盖：

a) 评审应用控制和完整性规程，以确保它们不因操作系统变更而损坏；

b) 确保年度支持计划和预算将包括由于操作系统变更而引起的评审和系统测试；

c) 确保及时提供操作系统变更的通知，以允许在实施之前进行合适的评审；

d) 确保按业务连续性计划进行合适的变更（见第14章）。

应该指定专门的组织和个人负责监视系统的弱点和供货商发布的补丁和修正。

12.5.3　软件包的变更限制

控制

不鼓励对软件包进行变更。对必要的更改严格控制。

实施指南

在可能和可行范围内，应使用厂商供应的软件包，而无需修改。若认为修改软件包是必要的，应考虑下列各点：

a) 内置控制完整性过程被损坏的风险；

b) 是否要获得厂商的同意；

c) 按标准程序更新从厂商获得所要求的变更的可能性；

d) 如果作为变更的结果，组织要负责进一步维护此软件所带来的影响。

如果认为变更是重要的，则原始的软件要予以保留，并将变更应用于明确标识的拷贝。应建立软件更新管理流程以确保大部分最新的补丁和应用更新已经安装在所有的授权软件中（见12.6）。应全面地测试所有变更，并将其形成文档，若需要，可以使它们重新应用于进一步的软件升级。如果需要的话，所有的更新应由独立的评估机构进行测试和验证。

12.5.4　信息泄露

控制

防止信息泄露的机会。

实施指南

为了限制信息泄露的风险，如通过应用隐蔽通道，则应考虑下列事项：

a) 扫描隐藏信息的外部介质和通信。

b) 掩盖和调整系统和通信的行为，以减少类似第三方从那些行为中推断信息的能力。

c) 使用具有高信誉的系统和软件，比如用已评估的产品（见ISO/IEC 15408）。

d) 在法律和法规允许的前提下，定期监视个人的系统的行为。

e) 监视计算机系统的源码使用。

其他信息

隐蔽信道不是故意设计用来引导信息泄露的通道，但它毫无疑问存在于系统或网络中。例如，通信协议包中的隐藏比特能够用来作为隐藏的信号的方法。从本质上说，防止所有可能的隐蔽通道的出现是很困难的。然而特洛伊木马经常利用隐蔽通道（见10.4.1）。采取措施防止特洛伊木马能够减少隐蔽通道被利用的风险。

防止非授权的访问（11.4），采取措施和方法防止滥用个人信息服务会有助于保护隐蔽通道。

12.5.5　软件委外开发

控制

组织应对软件委外开发进行监控。

实施指南

在软件委外开发的情况下，应考虑下列各点：

a) 落实准许证、代码所有权和知识产权（见15.1.2）；

b) 所完成工作的质量和准确性的认证；

c) 发生故障时第三方的契约安排；

d) 审核所做工作质量和准确性的访问权；

e) 代码质量和安全功能的合同要求；

f) 在安装前，检测恶意代码和特洛伊代码。

12.6　技术脆弱点管理

目标：减少由利用公开的技术脆弱点带来的风险。

技术脆弱点管理应该以一种有效的、系统的、可反复的方式连同可确保其有效性的措施来实施。这些考虑应包括在用操作系统和任何其他的应用。

控制

应及时获得组织所使用的信息系统的技术脆弱点的信息，评估组织对此类技术脆弱点的保护，并采取适当的措施。

实施指南

当前的完整的财产清单（见7.1）是进行有效技术脆弱点管理的先决条件。支持技术脆弱点管理需要的特定信息包括软件供应商、版本号、软件部署的当前状态（即在什么系统上安装什么软件）以及机构内负责软件的人员。

要采取适当的、及时的行动来确认潜在的技术脆弱点。建立有效的技术脆弱点管理流程要遵循以下原则：

a) 机构应当定义和建立与技术脆弱点管理相应的角色和责任，这包括脆弱点监视、脆弱点风险评估、打补丁、资产跟踪和任意需要的等价责任。

b) 确认软件和其他技术的相关技术脆弱点的信息资源应予以标识（基于资产详细列表），这些信息应根据清单列表的变化而更新，当发现其他新的或有用的信息后，信息资源也应该更新；

c) 制定时间表对潜在的相关技术脆弱点通知做出反映；

d) 一旦潜在的技术脆弱点被确认，机构应该确认相关的风险并采取措施；这些措施可能包括对脆弱点系统打补丁，或者应用其他控制；

e) 根据技术脆弱点需要解决的紧急程度，根据改变管理相关的控制，或者根据信息安全事故应答规程完成采取的行为；

f) 如果要安装补丁，则应先评估安装补丁可能带来的风险（脆弱点引起的风险应该同安装补丁带来的风险进行比较）。

g) 补丁在安装之前应该进行测试与评估，以确保补丁是有效的，且不会带来不能容忍的副作用；如果没有合适的补丁，应该考虑采取其他控制措施，如：

1) 关掉与脆弱点有关的服务和性能；

2) 在网络国界上采用或增加访问控制，如防火墙（见11.4.5）

3) 增加监控以检测或防止实际的攻击；

4) 提高对脆弱点的意识能力；

h) 对行为的所有过程应做审核日志；

i) 应定期对技术脆弱点管理过程进行监控和评估，以确保其效力和效率；

j) 处理高风险的系统应该先解决。

其他信息

一个机构的技术脆弱点管理过程的正确实施对每个机构来说都是非常重要的，因此应该定期对其进行监控。要对潜在的相关技术脆弱点进行确认，一个准确的详细列表是最基本的。技术脆弱点管理可看作变化管理的一个子功能，因此可以利用变化管理的流程和规范（见10.1.2和12.5.1）。

供货商往往是在面对很大的压力下才发布补丁，因此一个补丁可能不能准确地解决问题，也可能存在副作用。在某些情况下，一旦补丁被安装后，很难被卸载。

如果不能对补丁进行准确的测试（可能因为费用或缺少资源），需要根据其他用户的经验报告，考虑推迟打补丁，评估相应的风险。