10系统的开发与维护
10.1 系统的安全需要
目的：确保将安全构建成信息系统的一部分。
这包括基础架构、业务应用软件和用户开发的软件。这种支持应用软件或者服务的商务处理的设计和实施可能对安全十分关键。在开发信息系统之前应当确定其安全需要并得到对它的赞同。
所有的安全需要包括撤退安排的需要都应当在一个项目的需求分析阶段被确认， 并且作为一个信息系统的总体经营情况得到对其合理性的证明、获得同意并被记录在案。
10.1.1安全性要求分析和规范
对新系统业务需要所做说明或者对现有系统所给的增强作用应当规定管理措施的要求。这样的规范应当考虑到将要集成到系统中的自动控制措施并考虑到支持手动控制的需要。为商业应用目的评价软件包时应当做类似的考虑。如果被认为合适的话，管理层可能希望利用独立的评价和验证产品。
安全需要和管理措施应当反映所涉及信息资产的价值和可能有安全故障或者缺乏安全导致的潜在业务损害。分析安全需要和识别管理措施以实现它们的基本框架是风险评估和风险管理。
在设计阶段引进的管理措施要比那些在实施时或者完成后的控制措施实现和维护起来更便宜。
10.2 应用软件系统中的安全
目标：防止在应用软件系统中的用户数据的丢失、改动或者误用。
应当把适当的管理措施和查验追踪或者活动日志设计到应用软件系统中，包括用户编写的应用程序。这些措施应当包括对输入数据、内部处理和输出数据的检验。
对于那些处理敏感的、有价值的或者重要的组织资产的系统或者对其有影响的系统，可能还需要适当的管理措施。这些管理措施的确立应当基于安全需要和风险评估。
10.2.1 输入数据的验证
应当验证输入到应用软件系统中的数据，确保它是正确的和适当的。应当检查业务交易的输入、固定数据（姓名和地址、信贷限额、客户基准数）的输入和参数表（售价、货币兑换率、税率）的输入。应当考虑以下的措施：
a）为发现下述错误可以重新输入或者采用其它输入检查方法：
1）超范围数值；
2）数据域中的无效字符；
3）遗漏的或者不完整的数据；
4）超出数据容量的上下限；
5）未经授权或者不一致的控制数据；
b）对关键域或者数据文件内容进行周期性检查，确认其有效性和完整性；
c）检查打印的输入文件中是否有未经授权的对输入数据的变更（对输入数据文件的所有变更都应当是得到授权的）。
d）响应验证错误的程序；
e）检测输入数据整体的可信度的程序；
f）确定所有涉及数据输入程序的人员的责任。
10.2.2 内部作业的管理
10.2.2.1 风险区域
正确输入的数据可能被处理中的错误或者删除行为破坏。应当把有效性验证作为系统的一部分来检测这种破坏。应用软件的设计应当确保实施限制措施把危及数据完整性的处理故障的风险降低到最小。需要加以注意的特殊地方包括：
a）改变数据的添加和删除功能在程序中的使用和位置；
b）防止程序按照错误的顺序运行或者在先前的处理故障之后马上运行的程序；
c）使用恰当的程序从故障中恢复，以确保对数据的正确处理。
10.2.2.2 检查和控制
所需的管理措施取决于应用软件的性质和数据破坏对业务的冲击。以下是一些可以采用的检测措施的例子：
a）对进程或者批处理的管理，用于在事务更新之后调节数据文件平衡。
b）平衡控制，用于对比检测期初余额和先前的期末余额，即：
1）运营对运营的控制；
2) 文件更新合计；
3) 程序对程序的控制。
b)对系统生成数据的验证（见10.2.1）;
c)验证在中心和远程计算机之间下载或上载的数据或者软件的完整性（见10.3.3）；
d)记录和文件的数位总和；
e)检查确保应用程序在恰当的时间运行；
f)检查确保应用程序按照正确的顺序运行，在出现故障时程序终止并且在问题解决之前停止运行。
10.2.3 文电鉴别
文电鉴别是一种检查手段，用于检测对传送的电子消息的内容所做未经授权的更改或者文电消息本身的损害。该方法可以用在支持物理消息鉴别设备或软件算法的硬件或者软件中。
对于需要保护消息内容完整性的应用程序应当考虑采用文电鉴别。例如，电子形式的资金传送、规定、合同、建议等具有很大重要性的消息内容，或者其它类似的电子数据交换。为了确定是否需要文电鉴别并找到最佳实施方案应当进行安全风险评估。
文电鉴别不是用来防止消息内容未经授权就被泄露的。可以用加密技术（见10.3.2和10.3.3）作为实现文电鉴别的方式。
10.2.4 输出数据验证
应当验证应用系统输出的数据以确保对存储信息的处理是正确的并且与环境相适应。一般的说，系统的建造基于这样的前提，即已经采用的对输出的适当的验证、鉴别和检测将会一致是正确的。而实际情况并非如此。输出验证可以包括：
a）可信度的检查，用来测试输出数据是否合理；
b）协调控制计数，用于确保所有数据的处理；
c）为读者或者后续处理系统提供充足信息以确定信息的准确性、完整性、精确度和类别；
d）响应输出验证测试的程序；
e）定义所有涉及数据输出过程的人员的责任。
10.3 密码管理措施
目标：保护信息的保密性、完整性和有效性。
对处于危险中而且其它管理措施无法对其进行有效保护的信息，应当用密码系统和密码技术对其进行保护。
10.3.1使用密码控制措施的策略
对一个密码解决方案是否适当做出决定可以看作是更广泛的评估风险和选择管理措施的手段的一个部分。应当用风险评估了确定信息所应当得到的保护等级。这种评估随后可以用于评判一个密码管理措施是否得当、应当采用何种控制措施以及为了什么目的和业务处理。
组织应当为保护其信息制订一套加密管理措施的使用策略。这样的策略必须能够将利益最大化并把使用密码技术的风险降到最低，而且还要避免不适当或者不正确的使用。 在开发该策略的时候应当考虑到以下几点：
a）在整个组织范围内使用密码技术的管理途径，包括业务信息应当受其保护的一般规则；
b）密钥管理的途径，包括为防止密钥丢失、受损或者被毁而对加密的信息进行恢复；
c）角色和任务，例如谁应当负责：
d）策略的实施；
e）怎样确定适当的密码保护等级；
f）为在整个组织内有效实施所要采用的标准（何种解决方案用于何种商务处理）。
10.3.2 信息加密
信息加密是一种密码技术，它可以用于保护信息的保密性。保护敏感的和关键的信息时应当考虑该技术。
根据风险评估，确定所需的保护等级并且考虑到所用加密算法的类型和质量以及要用的密码关键字的长度。
当实施组织的加密策略时，应当考虑到有的法规和国家性限制可能涉及在世界的不同地方这些加密技术的使用问题，还应当考虑到加密信息的越界流动。 另外，应当注意那些用于密码技术进出口的管理措施（见12.1.6）。
应当征求专家的建议来确定适当的保护等级、选择适当的将要用于所需保护的产品和挑选密钥管理的安全系统的实施方案（见10.3.5）。另外，为了寻找一些法律法规，它们可能适用于组织中意的加密技术的使用，可能需要法律建议。
10.3.3 数字签名
数字签名提供了一种保护电子文档的真实性和完整性的方法。例如它们可以用于电子商务，那里需要验证是谁签署了一份电子文件并且检查签了名的文件是否被改动。
数字签名能够用于以电子化处理的任何文件形式，例如可以用它们签署电子支付单据、基金传送、合同和协议。数字签名可以用基于唯一相关的密钥对的密码技术，其中的一个密钥用于生成签字（私有密钥）而另外一个密钥用于检测该签名（公共密钥）。
应当注意保护私有密钥的保密性。应当对该密钥进行保密，因为任何取得该密钥的人都能够签署文件，例如付款单据、合同，因此伪造了密钥主人的签字。另外，保护公共密钥的完整性也很重要。可以使用公共密钥证件（见10.3.5）来提供这种保护。
需要考虑所用签名算法的类型和质量以及将要使用的密码的长度。数字签名中使用的密码关键字应当与加密算法中使用的不同。
使用数字签名时，应当考虑到相关立法，它们描述了在什么情况下数字签名受法律约束。例如在电子商务中知道数字签名的立法角度是十分重要的。在缺乏法律框架的时候，可能需要具有约束力的合同或者其它协议来支持使用数字签名。
10.3.4 非拒绝服务
对于一个事件或行为是否发生有争议时，例如对在一份电子合同或者支付手续上数字签名的使用的争执，为解决争议需要用到非拒绝服务。它们能够帮助找到证据，以便证实一个特殊事件或者行为是否已经发生，例如是否拒绝使用电子邮件发送有数字签名的说明。这些服务基于加密和数字签名技术（见10.3.2和10.3.3）的使用。
10.3.5密钥管理
10.3.5.1 密码关键性的保护
密码关键字的管理是对密码技术的有效利用的根本。密码关键字的任何损坏或者丢失都可能危及信息的保密性、真实性和/或者完整性的安全。应当有一个管理系统适当地支持组织对两种密码技术的使用，它们是：
a）秘密密钥技术，其中两个或者更多方共享同一个密钥并且不但使用这个密钥的加密形式还使用它的解密形式。该密钥必须是秘密的，因为任何得到它的人都能够用这个密钥把所有加密的信息解密出来，或者用它加入未经授权的信息。
b）公共密钥技术, 其中每个用户有一个密钥对：一个公共密钥（可以展示给任何人）和一个私人密钥（必须保密）。公共密钥技术能够用在加密上（见10.3.2）也能够用于生成数字签名（见10.3.3）。
所有的密钥应当得到保护，以防被修改或者破坏。而且秘密和私有密钥要防止未经授权的泄露。密码技术也可以用于这个目的。应当从物理上保护那些用于生成密钥、存储密钥和将其存档的设备。
10.3.5.2 标准、程序和方法
一个密钥管理系统应当基于共同的标准、程序和安全方法的集合，它们用于：
a）为不同的密码系统和不同的应用软件生成密钥；
b）生成和获取公共密钥证明；
c）把密钥分发给需要的用户，包括接到密钥时应当怎样将其激活。
d）存储密钥，包括经授权的用户怎样得到密钥；
e）更改或者更新密钥，包括关于何时应该改变密钥和怎样改变的一些规则；
f）处理受损的密钥；
g）激活密钥，包括应当怎样将密钥撤出或者使其失效，例如密钥在何时被损害或者用户在何时离开了组织（在此种情况下密钥也应当被存档）；
h）作为业务连续性管理的一部分，恢复丢失的或者毁坏的密钥。例如加密信息的恢复。
i）存档密钥，例如用于信息存档或者备份；
j）销毁密钥；
k）密钥管理相关活动的记录和查验。
为了减少损害的可能性，密钥应当有确定的激活和休止日期，从而它们只能在有限的时间段内使用。该时间段的长度应当取决于运用密码管理措施的环境和所发现的风险。
为了处理访问密码关键字的法律要求，需要考虑一些程序。例如，可能需要用加密信息的解密形式做法庭上的证据。
除了安全管理的秘密和私人密钥的话题之外，还应当考虑公共密钥。有的人用自己密钥替代公共密钥来伪造数字签名，可能有这种威胁存在。这一问题可由使用公共密钥证明的方法来解决。这些证明文件应当以一种把与公共密钥/私有密钥的所有人相关的信息同公共密钥唯一地连续在一起。因此生成这些证明文件的管理过程要值得信赖，这一点很重要。该过程通常由一个权威验证机构来执行，该机构有适当的管理和控制措施提供所需的置信度。
服务等级管理的内容或者与外部密码服务供应商所签订合同的内容，例如与一个权威验证机构所签合同，应当包括有关责任、服务的可靠性和提供服务的响应时间等议题（见4.2.2）。
10.4 信息文件的安全
目标：确保IT项目和支持行为以安全的方式进行。应当控制对系统文件的访问。
维护信息的完整性应当是应用程序系统或者软件所属的用户功能或者开发群体的责任。
10.4.1 操作软件的控制
应当为在操作系统中使用软件提供管理措施。为了把操作系统溃掉的风险降到最低，应当考虑一些的管理措施：
a）操作系统程序库的更新应当只由指定的程序库管理员根据适当的管理层授权来执行（见10.4.3）;
b）如果可能的话，操作系统应当只包涵可执行代码；
c）获得测试成功和用户被接受的证据之前，以及在相应的程序资料库更新之前，不能在操作系统中运行可执行代码。
d）应当维护对层次系统程序库的所有更新的审查日志；
e）应当保留软件的以前版本做为应急之用。
操作系统中使用的由销售商提供的软件应当维护在一个由该供应商支持的水平之上。任何升级到新版本的决定都应当考虑到该版本的安全，比如新安全功能的引入或者影响该版本的安全问题的数量和严重性。当软件补丁能够帮助消除或者减少安全缺陷的时候，就应当使用他它们。
对操作系统进行的物理或者逻辑访问应当只是在需要的时候出于技术支持的目的而授予供应商的，而且还需要得到管理层批准。应当监视供应商的活动。
10.4.2系统测试数据的保护
应当保护并控制测试数据。系统和验收试验通常需要大量的尽可能与靠近际运行数据的测试数据。应当避免使用含有个人信息的业务数据库。如果要使用其中信息，在用之前应当使其失去个性化。当把运行数据用于测试目的时，应当采取以下措施保护运行数据。
a)访问控制程序，它可以用于应用操作系统.也可以用于测试应用系统。
b)每次把运行信息复制到测试应用系统都应当有单独的授权。
c)测试完成之后，应当立即把运行信息从测试应用系统中删除。
d)应当记录运行信息的复制和使用，以提供一种检查追踪。
10.4.3 对程序资源库的访问控制
为降低计算机程序溃掉的可能性，在对程序资源库的访问中应当保持如下所述的严格管理措施。
a)可能的情况下，程序资源库不应当放在操作系统中；
b)应当为每个程序指定一名程序资源库管理员；
c)IT技术支持人员不应当对程序资源库不加限制地访问；
d)正在开发的程序和正在维护的程序不应当放在程序资源库中；
e)程序资源库的升级和程序资源向程序员的发布应当只由指派的程序资源库管理员根据授权从应用程序的IT技术支持经理那里进行；
f)程序列表应当放在安全的环境中(见8.6.4)。
g)应当保留一份对程序资源库所有访问的审查日志。
h)老版本的程序资料应当存档，清楚标明它们运行的准确日期和时间，以及所有支持软件、作业控制、数据定义和程序。
i)程序资源库的维护和复制应当服从严格的变更管理程序（见10.4.1）。
10.5 开发和支持过程中的安全
目标：维持应用程序系统软件和信息的安全。
应当严格控制项目和支持环境。
应用程序系统的负责主管也应当负责项目或者支持环境的安全。它们应当确保所有建议的系统变更都经过复查以验证它们不会损害系统或者运行环境的安全。
10.5.1 变更控制程序
为了降低信息系统溃掉的危险，对变更的实施应当有严格的管理措施。正式的变更管理程序应当得到加强。它们应当确保安全并且控制程序不会受到损害，确保技术支持程序员只被授予访问他们工作所必须接触的部分系统内容，并且保证所有变更都得到了的正式同意和批准。改变应用程序软件可能对运行环境产生冲击。如果合适的话，应用程序和运行变更程序应当集成到一起（见8.1.2）。该过程应当包括：
a）保持一份同意授权等级的记录；
b）确保变更是由授权的用户提交的；
c）复查控制和集成程序以确保它们不会被变更所损害；
d）识别所有计算机软件、信息、数据库物理和需要维修的硬件；
e）在工作开始之前得到对详细建议的赞同；
f）确保授权的用户在任何执行之前接受改变；
g）确保过程的执行会把业务分裂降低到最小的程度；
h）确保每次变更完成之后更新系统文献集合并且把旧的文献存档或者进行处置；
i）为所有软件更新维持一个版本管理；
j）保持对所有变更要求的审查追踪；
k）确保运行文件（见8.1.1）和用户程序的改变必须得当；
l）确保在正确的时候做出变更而且没有扰乱相关的业务过程。
许多组织维护一个环境，用户在其中检测新软件并且该环境与开发和生成环境相互分离。这就提供了一种控制管理新软件的方式并且允许对用于测试的运行信息的给以额外保护。
10.5.2 操作系统变更的技术复查
需要定期改变操作系统，例如安装新提供的软件版本或者补丁程序。当发生改变时，应当复查并测试应用程序系统以确保对运行或者安全没有负作用。该程序应当包括：
a)复查应用程序控制措施和完整性程序以确保它们没有受到操作系统改变的损害；
b)确保手动支持计划和预算会保护由操作系统变更引起的复查和系统测试；
c)确保及时提供操作系统变更的通知，从而允许在执行之前进行适当的复查；
d)确保对业务连续性计划做了适当改变（见句1）。
10.5.3 改变软件包的限制
应当阻止修改软件包。只要可能，而且也可行，应当不加任何修改地使用卖方供应的软件包。如果认为必须对软件包进行改动，应当考虑以下各点：
a）受损的内置控制措施和集成程序的风险；
b）是否得到了供应商的许可；
c）从供应商那里得到所需变更作为标准程序更新的可能性；
d）如果因为软件包变更而要组织为软件未来的维护承担责任，有怎样的影响。
如果认为必须做改动，那么应当保留原始软件和对一个清楚定义的副本所做的改动。应当对所有的改动充分测试并记录在案，因此如果将来软件升级需要，就能重新应用它们。
10.5.4 隐蔽通道和特洛伊代码（渗透性代码）
隐蔽的通道可能由一些间接的和隐晦的方式披露信息。 改变一个计算系统的安全元素和不安全元素都可以访问的参数，或者把信息嵌入一个数据流中，就可以激活这一隐蔽通道。渗透性代码是要以一种未经授权、没被注意并且应用程序的接收方或者用户不需要方式和 的方式影响系统。隐蔽通道和渗透性代码的出现很少是偶然的。关注隐蔽通道或渗透性代码时，应当考虑一些几点：
a)只从有声誉的来源购买程序软件；
b)购买程序的源代码以便进行修改；
c)使用评价过的产品;
d)在运行之前检查所有源代码；
e)控制访问和修改已经安装了的程序代码；
f)在关键系统的工作中用已经证明是可以信赖的职工；
10.5.5 外购软件开发
如果软件开发是外购的，应当考虑以下几点：
a）对安排、代码所有权和知识产权发证照（见12.1.2）;
b）对所做工作的质量和准确性的验证；
c）第三方出现故障时对由其保存的附带条件委托契约的安排；
d）查验已完成工作的质量和准确性所需访问权；
e）合同对代码质量的要求；
f）在安装之前检测特洛伊代码（渗透性代码）；
