国际标准 ISO/IEC 17799(三)9访问控制
9.1访问控制的业务需要
目标:控制对信息的访问
根据业务和安全的要求应当控制对信息的访问和对业务程序的访问。
这应当把信息发布和授权的策略考虑在内。
9.1.1访问控制策略
9.1.1.1 策略和业务的要求
应当定义并记录下对访问控制的业务要求。在访问控制策略说明中,应当清楚阐明访问控制规则和每个个人
用户和用户群体的权限。用户和服务提供商应当提供一份清楚的对访问控制所要满足的业务要求的说明。
该策略应当考虑到以下内容:
a) 个人业务应用软件的安全要求。
b) 对所有与业务应用程序相关的信息的鉴别。
c) 信息传播和授权的策略,例如 需要知道原理和信息的安全等级和分类;
d) 在访问控制和不同系统和网络间信息分类的策略之间的连贯性;
e) 对数据或者服务的访问的保护所涉及的法律和所有合同义务;
f) 对一般工种而设的标准用户访问特征;
g) 在分布式的和网络化的环境中访问权限的管理。这种环境能够分辩所有可用连接的类型。
9.1.1.2 访问控制规定
为确定访问控制规定,应当仔细考虑以下问题:
a) 区分必须一直坚持的规定和那些有可选择性和有条件的规定;
b) 规定的建立基于如下前提“除非得到明白的许可,否则一般必须禁止此类行为”,而不是更弱的标准
“除非被明令禁止,否则所有的行为都是允许的”;
c) 由信息处理设备自动引起的信息标签(见5.2)的改变和那些用户判断引起的信息标签的改变。
d) 由于信息系统自动引发的用户许可的改变和管理员所做的这种改变。
e) 在执行之前,需要管理员或者其他人批准的规定和那些不需要这种批准的规定;
9.2 用户访问管理
目标:防止对信息系统的未经授权的访问
应当由正规的程序来控制对信息系统和服务的访问权限分配。
这些程序应当覆盖用户访问全过程的所有阶段,从新用户的最初注册到不再需要访问信息系统和服务的用户
最终的注销。适当的情况下,应当特别注意控制特权访问权限的分配。 这些特权允许用户超越系统控制。
9.2.1 用户注册
为了授予对一个多用户的信息系统和服务的访问权限,应当由一个正式的用户注册和注销程序。
应当通过正式的用户注册程序来控制对于多用户信息服务的访问。该注册程序应当包括:
a)
使用唯一的用户身份,以便将用户与他们的行为联系上并让他们对自己的行为负责。群体身份(group ID)
只允许在它们适于所要做的工作时才采用。
b) 检查用户是否有从系统所有人处得到的使用信息系统和服务的授权。管理层做出的对于访问权限的单
独批准可能也是合适的
c) 检查授予的访问等级是否于业务目标相适应(见9.1),并且是否与组织的安全策略相一致,例如:
它不会损害任务的分离(见8.1.4)。
d) 给用户一个关于他们访问权限的书面声明;
e) 要求用户签署该声明以表明他们理解访问的条件。
f) 确保访问提供商在授权程序完结之前不提供访问途径。
g) 保存一份注册使用该系统的所有人员的正式记录。
h) 立即取消已经改换工作或者离开该组织的用户的访问权限;
i) 定期检查并删除冗余的用户ID和帐户;
j) 确保冗余的用户帐号不被转给其它用户。
如果职工和服务代理人有未经授权的访问时要受处罚,应当注意,在员工合同和服务合同中要包涵相关条款
对此做出规定(见6.1.4和6.3.5)。
9.2.2 特权管理
应当严格限制特权(多用户信息系统的任何使得客户超越系统或者应用软件控制的特征或者便利)的分配和
使用。对系统特权的不当使用经常成为导致被攻破的系统产生故障的一个主要因素。需要防止未经授权访问
的多用户系统应当通过正式的授权程序来控制对特权的分配。 应当考虑以下的步骤:
a) 应当确定与每个系统产品例如操作系统、数据库管理系统和每个应用软件相联系的特权和需要分派的
职工类别;
b) 特权的分配应当建立在一种需要使用的基础和就事论事的基础上,例如只有在需要时才对它们功能角
色有最低限度的要求。
c) 应当保有一个授权程序和一份所有分配出的特权的记录。在授权程序结束之前不应当授予特权。
d) 系统程序的开发和使用应当得到提升,以避免需要向用户授予特权。
e) 特权应当分配给一个不同于常规业务使用的用户身份。
9.2.3 用户密码管理
密码是一种访问信息系统或者访问时确认用户身份的常用方式。应当通过正式的管理程序来控制密码的分配
。这一程序应当:
a) 需要用户签署一项声明以保持个人密码的保密性并确保工作组密码只在该组成员的内部(这应当包括
在用工合同条款中,见6.1.4)
b) 在用户需要维护他们的密码时,确保最初为它们提供一个安全的临时密码,而迫使他们立即更改。当
用户未经他们密码的时候提供的临时密码应当只按照确实的用户身份提供。
c) 需要临时密码来给用户一个安全的方式。应当避免使用第三方或者使用未受保护 的明码电文的电子
邮件信息。用户应当确认接收到密码了。
无论如何,密码都不能以一种未受保护的形式存储在计算机上。可以使用其它的用户识别和授权技术,例如
生物测定像指纹鉴定、签字确认和硬件标识例如集成芯片卡。适当情况下应当加以考虑。
9.2.4 用户访问权限的复查
为了保持对数据和信息服务的存取访问的有效控制,管理层应当实施一个正式的程序来定期复查用户的访问
权限,使得:
a) 用户的访问权限得到定期复查(推荐周期是6个月)并在做任何改动后进行复查(见9.2.1)。
b) 对特殊的特权访问权限(见9.2.2)应当以更高的频率来检查;推荐周期是3个月。
c) 定期核查特权分配,以确保无人得到未经授权的特权。
9.3 用户责任
目标:防止未经授权的用户访问
得到授权的用户进行合作是有效的安全基础。
为了维持有效的访问控制,应当让用户知道他们的责任,尤其是有关密码使用和用户设备的安全方面的责任
。
9.3.1 密码使用
用户应当按照良好的安全操作规程来选择和使用密码。
密码提供了一种验证用户身份的手段,从而建立了对信息处理设备和服务的访问权限。 应当建议所有的用户
:
a) 保护密码的保密性;
b) 避免在纸张上保留密码记录,除非可以对其安全存放。
c) 只要有系统或者密码可能被侵害的迹象,就更改密码;
d) 选择的优质密码至少要有6个字符的长度,这些字符要:
1) 容易记忆;
2) 不是基于那些别人很容易地根据个人相关信息就能够猜出来的东西。例如:名字、电话号码和生日等
等。
3) 避免使用连续的相同数字,或者全是数字或全是字母的字符组。
d) 定期更换密码或者根据一定量的访问次数来更改密码(特权帐户的密码应当比普通帐户密码更改的更
为频繁)。避免重复或者循环使用旧的密码。
e) 定期更换密码或者根据一定量的访问次数来更改密码(特权帐户的密码应当比普通帐户密码更改的更
为频繁)。避免重复或者循环使用旧的密码。
f) 在第一次登录时更改临时密码;
g) 不要把密码包含在任何自动登录程序之中,例如把密码存在宏代码或者功能键上。
h) 不要共用个人用户密码。
如果用户需要访问多重服务或者平台并且被要求持有多重密码,那么应当建议他们对于所有的为存储的密码
提供合理保护等级的服务都使用单一的优质密码(见上述d)) 。
9.3.2 无人值守用户设备
用户应当确保无人值守设备得到足够的保护。在用户区安装的设备,例如工作站或者文档服务器,可能需要
特殊的保护以防止在较长的无人值守时间内被未经授权地访问。为了保护无人值守的设备,应当让所有的用
户和合同伙伴明白安全要求和安全程序。而要实施这些保护还得使他们清楚自己的责任。 应当建议用户:
a) 当完成对话束时要将活动的对话终止,除非有适当的锁定机制的保护,例如一个密码保护的屏幕保存
程序;
b) 当对话期结束时要注销主机(而不仅仅是关掉个人计算机和终端);
c) 在不使用PC机和终端时,用密码锁或者相类似的控制手段例如密码访问,以防止对它们的未经授权的
使用。
9.4 网络访问控制
目标:保护网络服务
应当控制对内部和外部网络服务的访问。
这对于确保对网络和网络访问有访问权限的用户不损害这些系统的安全是必要的。为此,要确保:
a) 在本组织的网络和其它组织的网络例如公共网之间有适当的接口;
b) 对用户和设备的适当的授权机制;
对用户访问信息服务的控制。
9.4.1 网络服务的使用策略
与网络服务的不安全的链接会影响到整个组织。只应当向用户提供对那些特别授权他们使用的服务进行直接
访问。这种控制对于同敏感或者关键业务应用软件的联网或者同处于高风险地区的用户的联网都是十分重要
的。其中高风险地区指公共的场所或者组织的安全管理范围以外的区域。
策略的筹划应当考虑到网络和网络服务的使用。应当包括:
a) 允许访问的网络和网络服务;
b) 用来确定谁可以访问那些网络和网络服务的授权程序;
c) 保护对网络连接和网络服务的访问的管理措施和程序。
这一策略应当与业务访问控制策略(见9.1)相一致。
9.4.2 强制路径
从用户终端到计算机服务器的路径可能需要进行控制。 网络被设计成要允许最大程度的资源共享和最大程度
的路径选择自由。而网络的这些特征也可能为那些对业务应用软件未经授权的访问或者对信息设备未经授权
的使用制造了机会。限制用户终端与允许用户访问的计算机服务器之间路径的联合管理措施,例如建立一条
强制路径,能够降低这种风险。
强制路径的目的是为了防止用户选择了任何用户终端与允许用户访问的计算机服务器之间路径的其它路径。
一般来说,这需要在路径的不同地点实行一定数量的控制。其原理是通过预先确定的选择来限制在网络中的
各个点处的路径选取。
下面是它的例子:
a) 分配专用线路和电话号码;
b) 自动连接到指定的应用软件系统或者安全门路;
c) 为单个用户限制菜单和子菜单选项。
d) 防止不受限制的网络漫游;
e) 对外部的网络使用者,强制其使用指定的应用软件系统和/或安全门路;
f) 通过安全门路例如防火墙来积极地控制目的地通信的许可来源。
g) 为组织内部的用户群建立分离的逻辑域来限制网络访问,例如虚拟私人网络(又见9.4.6)。
对强制路径的要求应当基于业务访问控制策略(见9.1)
9.4.3 外部连接的用户认证
外部连接可能导致对信息系统未经授权的访问,例如拨号的方法。因此,应当把远程用户的访问置于比其它
方式更为严密的保护之下,例如以使用密码技术为基础的方法能够提供强大的认证。要从风险评估中确定所
需保护等级,这点十分重要而且选择恰当的认证方法时也需要。
可以通过多种方式验证远程用户的身份,例如加密技术、硬件标识或者询问/应答协议。也可能用专用线路或
者网络用户地址检查设备来确认连接的来源。
拨号回送程序和控制措施,例如使用回拨调制解调器,能够防止对一个组织的信息处理设备的未经授权的和
有害的连接。这种控制鉴别那些试图从远处建立到组织的网络的连接的用户。使用这些管理措施时,组织不
应当用网络服务包括电话发送;如果使用了这种网络服务,就应当取消这样的特征,以避免与电话发送相关
的弱点。回拨过程包括确认在组织一方的连接确实断开了,这点也很重要。否则,远程用户能够持续占线假
装已经做了回拨验证。应当仔细的检测回拨程序和控制的这种可能性。
9.4.4 节点鉴别
自动连接到远程计算机的设备能够提供了一种途径,从中可以获得对业务应用软件的未经授权的访问。因此
应当认证连到远程计算机系统的连接。如果连接使用的网络在组织的安全管理的控制范围以外,这种做法就
尤其重要了。 在上述9.4.3中给出了一些例子说明什么是认证和如何实现认证。
节点认证能够作为认证远程用户群的替代方式,在那里用户连接到了一个安全的共享的计算机设备(见9.4.3
)。
9.4.5 远程诊断接口的保护
应当安全地控制对诊断接口的访问。为了方便维护工程师的使用,许多计算机和通信系统安装在一个拨号远
程诊断设备之中。如果未加保护,这些诊断接口就为未经授权的访问提供了途径。因此,应当用适当的安全
机制对其加以保护,例如一个密码锁和一个保护程序。通过在计算机服务管理员和需要访问通路的硬件/软件
支持人员之间所做的安排,该程序确保了诊断接口只能由他们访问。
9.4.6 网络分离
网络日益被扩展到传统的组织边界以外,例如业务伙伴关系的形成可能需要互联或者共享信息处理和网络设
备。网络的这种扩展可能加大使用网络的现有信息系统受未经授权的访问的风险。由于有些网络的敏感性或
者关键性,它们可能需要其它网络用户的保护。在这种情形下,应当考虑在网络中引入管理措施来分离不同
的信息服务、用户和信息系统。
大型网络安全管理的方法之一就是将其分解为独立的逻辑网域,例如组织的内部网域和外部网域, 每个域都
由一个确定的安全边界保护。在将被连接起来以控制两个域之间的访问和信息流的两个网络之间安装一个安
全门路,由此可以实现上述的安全边界。这一门路经过定制可以来过滤这些域之间的通信(见9.4.7和9.4.8
)并能够按照组织的访问管理措施(见9.1)堵住未经授权的访问渠道。这种门路的一个例子就是我们通常所
说的防火墙。
将网络分离成域的标准应当是基于访问控制策略和访问的要求(见9.1),而且还要考虑到合成适当的网络路
径或者门路技术的相对成本和对性能的影响(见9.4.7和9.4.8)。
9.4.7 网络连接管理
共享网络访问控制策略的要求,特别是那些跨越组织界线的关系网络,可能需要把控制措施结合起来以约束
用户的连接能力。这种控制措施可以由一个用预先拟定的表格或者规则过滤通信的网络门路来实现。所用的
这种约束措施应当基于访问控制策略和业务应用软件的需要(见9.1),因此应当加以维护和更新。
需要加以限制的一些具体应用是:
a) 电子邮件;
b) 单向文件传送;
c) 双向文件传送;
d) 交互式访问;
e) 与每天或者某个日期的时间相关的网络通路。
9.4.8 网络路径选择控制
共享的网络,尤其是那些跨越组织边界的网络,可能需要把路径选择管理措施结合起来以确保计算机连接和
信息流不会破坏业务应用软件的访问控制策略(见9.1)。这种控制对于同第三方(非组织)用户共享的网络
常常是具有根本性的。
路径选择控制应当基于确定的来源和目标地址检测机制。网络地址翻译对于隔离网络和防止路径从一个组织
的网络延伸到另一个网络中也是一种非常有用的机制。它们能够在软件和硬件中实现。实施者应当清楚所配
备的任何机制的作用强度。
9.4.9 网络访问安全
有广泛的公共网络服务和私有网络服务可供利用,其中有的是增值服务。网络服务可能有独特的或者复杂的
安全特征。使用网络服务的组织应当确保对所有服务的安全属性做一个清晰的描述。
9.5 操作系统访问管理
目标:防止未经授权的计算机访问。
操作系统水平的安全设备应当用于限制对计算机资源的访问。这些设备应当能够做到以下事情:
a) 鉴别和验证身份,如果需要的话还能够鉴别和验证每个经授权用户的位置和终端。
b) 记录对系统的成功访问和失败访问。
c) 提供适当的授权方式;如果使用了密码管理系统,应当能够确保使用的是优质密码(见9.3.1 d))。
d) 在适当的地方,限制用户的连接次数。
如果证明对于业务风险没有危害,那么也可以使用其它的访问控制方法,例如询问-应答方法。
9.5.1 自动终端识别
为了鉴别连到特殊地点和便携设备的连接应当考虑自动终端识别技术。如果一个对话只能从特殊的地点或者
计算机终端上启动这点很重要,那么自动终端识别就是一种可以考虑的方法。终端内或者贴到终端上的一个
标识可以用来指示是否允许这个特定的计算机终端启动或者接收特殊事项。为保持终端标识的安全,可能需
要对计算机终端进行物理保护。也可以用其它的技术鉴别计算机终端(见9.4.3)。
9.5.2 终端登录程序
由一个安全的登录程序应当能够获得对信息服务的访问。这一登录到计算机系统的过程的设计应当把对系统
未经授权的访问的机会降到最低限度。因此为了避免给未经授权的用户以不必要的帮助,该登录程序只会透
露出最少的系统信息。一个好的登录程序应当做到:
a) 除非登录程序成功结束,否则不显示系统或者应用程序;
b) 显示一般性的警告,说明只有经过授权的用户才能够访问;
c) 在登录程序中不提供可能会帮助未经授权的用户的信息;
d) 只有完成所有数据的输入以后才开始验证。如果产生一个错误条件,该系统不应当指示出哪对哪错。
e) 限制所允许失败登录次数(推荐使用3次),并且考虑:
1) 记录失败的尝试;
2) 在重新登录之前强制等待一段时间或者拒绝任何没有特殊授权的进一步尝试。
3) 断开数据连接。
e) 限制所允许的登录程序的最长和最短时间。如果超过了这个范围,系统应当终止登录。
f) 当成功的完成登录以后,要显示以下信息:
1) 上一次成功登录的日期和时间;
2) 自从上次成功登录以来,历次失败登录尝试的细节。
9.5.3 用户识别和鉴定
所有的用户(包括技术支持人员,例如操作员、网络管理员、系统程序员和数据库管理员)应当有唯一的标
识(用户ID)供他们个人并且只供他们个人使用。因此,可以追踪各种活动到负有责任的个人身上。用户ID
不应当显示出用户的特权等级(见9.2.2),例如管理人员、监控人员。
在例外的情况之下,如果有明显的商业利用,可能会让一个用户群或者特殊的工种共享一个用户ID。管理层
对这种情况的批准应当记录在案。为保持可计量性,可能还需要其它管理措施。
有各种授权程序,可以用来证实所声称的用户身份。密码(见9.3.1和下文)是一种非常通用的进行识别和鉴
定(I&A)的方法。这一方法基于一个只有用户才知道的秘密。利用加密技术和鉴别协议也可以达到同样的目
的。
像存储标识或者用户拥有的智能卡这类物品也可以用来进行识别和鉴定。利用个人的唯一的特征或者属性的
生物鉴别技术也可以用来鉴别一个人的身份。将鉴别技术和管理机制妥善地结合到一起能够得到更为强大的
鉴定能力。
9.5.4 密码口令管理系统
密码是验证用户访问计算机权限的主要形式之一。密码管理系统应当提供一个有效的、交互的设备。这样可
以确保优质密码(参考9.3.1小节的密码使用指导)。
一些应用程序需要有独立的职权来分配用户密码。在大多数情况下,密码是由用户选择和维护的。
一个好的密码管理系统应当:
a) 强制使用个人密码以保持可计量性;
b) 适当的时候,允许用户选择和更改他们自己的密码并包括一个确认程序,它允许出现输入错误。
c) 强制选择如9.2.1所述的优质密码;
d) 用户维持他们自己的密码时,强制实行如9.3.1所述的密码变更;
e) 当用户选择密码时,强制他们在第一次登录的时候更改临时密码(见9.2.3);
f) 维持一份以前用户密码的记录,例如在此之前12个月,并避免再次使用;
g) 输入密码时不要将其在屏幕上显示出来;
h) 把密码未经与应用软件系统的数据分开存放;
i) 以使用单向加密算法的加密形式存储密码口令;
j) 软件安装完毕后,改变缺省的卖方密码。
9.5.5 系统实用程序的使用
大多数计算机安装有一个或者更多系统实用程序,它们可能有能力超越系统和应用程序的控制。限制并严格
控制对它们的使用是十分重要的。应当考虑以下的控制措施:
a) 给系统实用程序使用认证程序;
b) 系统实用程序从应用软件分离出来;
c) 把使用系统实用程序的人限制在最少的值得信任的授权用户之内;
d) 为系统实用程序的特殊使用进行授权;
e) 限制系统实用程序的有效性,例如在一个经授权的变更的持续时间之内;
f) 记录系统实用程序的所有使用;
g) 系统实用程序授权等级的定义和文件证明;
h) 所有基于软件的多余实用程序和多余系统软件的删除。
9.5.7 终端暂停
为了防止未经授权的人访问,在一段确定的休止期结束后,应当关闭在高风险地区例如在组织的安全管理之
外的公共场所或外部地区的暂停终端或者是正在为高风险系统提供服务的终端。 在一段确定的暂停期后,这
一终端暂停手段应当清除终端屏幕内容并关闭应用程序和网络对话。该暂停应当反映出这个地区和终端用户
的安全风险。
一些PC机可以得到有限的终端暂停手段,使其能够清楚屏幕内容并防止未经授权的访问但是不会关闭应用程
序或者网络进程。
9.5.8 连接时间的限制
对连接时间的限制应当为高风险应用程序提供额外的安全保证。限制终端可以连接到计算机访问的时间缩小
了未经授权访问的机会空间。对于敏感的计算机应用程序,特别是那些有终端安装在高风险地区例如在组织
的安全管理范围之外的公共场所或外部地区的,应当考虑这样的管理措施。这样约束措施的例子包括:
a) 使用预先确定的时间段,例如批量的文件发送,或者定期的短时交互式对话;
b) 如果没有超时或者延时业务,限制连接到正常办公时间的次数。
9.6 应用程序访问控制
目标:防止保存在信息系统内信息被未经授权地访问。应当使用安全设施限制在应用程序系统中的访问。
对软件和信息的逻辑访问应当限制在经过授权的用户之中。应用软件系统应当:
a) 控制用户对信息和应用程序系统功能的访问,并要与确定的业务访问控制策略相一致;
b) 为任何一个能够超越系统或应用程序限制的实用程序和操作系统软件提供保护,防止未经授权的访问
;
c) 不损害有共享信息资源的其它系统的安全;
d) 只能够向所有权人、其它被指派和经授权的个人或者确定的用户群提供对信息的访问权限。
9.6.1 信息访问限制
按照确定的访问控制策略,应当为应用软件系统的用户包括技术支持人员提供对信息和应用程序系统的访问
。这是基于个人业务应用程序要求的并且与组织的信息访问策略(见9.1)相吻合。为了支持访问限制要求,
应当运用以下管理措施:
a) 提供菜单来控制访问应用程序系统功能;
b) 通过适当编辑用户文件,可以限制用户对于未得到授权进行访问的信息或者应用程序系统功能的了解
;
c) 控制用户的访问权限,例如读取、改写、删除和执行等权限。
d) 确保处理敏感信息的应用程序系统的输出只包括与输出的使用相关的信息,而且只送到得到授权的终
端和地点,包括对这种输出周期性的复查以确保多余的信息被删除了。
9.6.2 敏感系统的隔离
敏感系统可能需要专用(隔离的)计算环境。有些应用程序系统对于潜在的损失如此敏感以致于需要对它们
做专门处理。这种敏感性可能表示应用程序系统应当在专用计算机上运行,而且只同受信的应用程序系统共
享资源,或者没有限制。可以考虑以下几点。
a) 对一个应用程序系统的敏感性应当做清楚的定义并且有应用程序所有权人把它记录在案(见4.1.3)。
b) 当一个敏感的应用程序将在共享的环境下运行时,应当识别出应用程序将分享其中资源的该应用程序
系统,并获得敏感应用程序的所有权人的准许。
9.7检测系统访问和使用
目标:探测未经授权的活动。
应当监视系统以发现偏离访问控制策略的行为并记录可监测事故以便方式安全事件时提供证据。
系统检测允许对所采用管理措施的有效性进行检测,并允许对一个访问策略模型(见9.1)的确认进行验证。
9.7.1 事件记录
应当编写用来记录异常现象和其它有关安全的事件的审查日志,并在各方同意的时间段内保持该日志,以协
助以后的调查研究和访问控制监测。 审核日志还应当包括:
a) 用户ID;
b) 登录和注销的日期及时刻;
c) 如果需要,要做终端或者地点的识别;
d) 对系统成功的访问和被拒绝的尝试所做的记录;
e) 对数据和其它资源成功的和被拒绝的访问所做的记录。
某些审核日志可能需要放入档案中,作为记录保留策略的一部分或者出于收集证据的需要(另见第12句)
9.7.2 检测系统使用
9.7.2.1 程序和风险区域。
应当建立程序以检测信息处理设备的使用。为了确保用户只做了得到明确授权的行为,这样的程序是必需的
。应当由风险评估确定个人设备所需的监测等级。应当考虑的地方有:
a) 得到授权的访问,包括细节例如:
1) 用户ID;
2) 关键事件发生的日期和时间;
3) 事件的类型;
4) 访问的文件;
5) 使用的程序/实用程序;
c) 所有有特权的作业,例如:
1) 监督员帐户的使用;
2) 系统启动和结束;
3) 输入/输出设备附件/可拆件。
d) 未经授权的访问尝试,例如:
1) 失败的尝试;
2) 对访问策略规定的违反和对网络门路和防火墙的通告。
3) 警惕所有权人侵入检测系统;
e) 系统警报或者故障,例如:
1) 控制台警报或者消息;
2) 系统日志异常;
3) 网络管理警报。
9.7.2.2 风险因素
应当定期检查检测活动的结果。检查的频率取决于所涉及的风险。应当加以考虑的风险因素包括:
a) 应用进程的重要程度;
b) 所涉及信息的价值、敏感性和重要程度;
c) 以往的系统过滤和和误用的经验教训;
d) 系统互联的程度(特别是公共网络);
9.7.2.3记录和检查事件
日志检查涉及对于系统所面临威胁的理解和对这些威胁可能的产生方式的认识。在9.7.1中给出了为了防止安
全事故可能需要深入调查的事件的例子。
系统日志常常包涵大量的信息,其中很多信息与安全检测无关。出于安全检测的目的而帮助识别重要事件时
,应当考虑把适当的信息类型自动复制到第二个日志和/或者使用适当的系统实用程序或检测工具,以便进行
文件审查。
当为检查日志而分配责任时,应当考虑把执行检查的人员和其活动被监测的人员之间的角色分离开。
应当尤其注意日志记录设施的安全,因为一旦遭到破坏可能给人一种十分安全的假相。管理措施应当致力于
防范未经授权的改动和操作问题包括:
a) 将记录设备置于停止状态;
b) 所记录的消息模式的变更;
c) 被编辑或者删除的日志文件;
d) 被用完的日志文件的存储器,要么不能记录事件要么覆盖了自己。
9.7.3 时钟同步
为了确保审查日志的准确性,正确的设定计算机时钟是十分重要的。这在调查研究中可能需要或者可以作为
法律案件中的证据。不准确的审查日志可能会妨碍调查研究的进行,并会削弱它作为证据的可信度。在计算
机或者通信设备有能力操作一个实时的时钟的地方,应当按照一个共同的标准把它设定,例如 通用协调时间
(UCT)或者当地标准时间。由于有的时钟有偏差,应当有一个程序可以检测并改正任何重要的变更。
9.8 移动计算和远程工作
目标:在使用移动计算和进行远程工作时确保信息安全。
所需要的保护应当与这些工作的特殊方式引起的风险相协调。使用移动计算时应当考虑到 未经保护的环境下
工作的风险,并且要考虑到所采用的适当措施。在远程工作时,组织应当为远程工作地点提供保护并且确保
对这种工作方式有适当的安排。
9.8.1 移动计算
使用移动计算设备例如笔记本电脑、掌上电脑、膝上电脑和移动电话等的时候,应当特别注意要确保业务信
息不受损害。应当采取正式策略来考虑使用移动计算设备的风险,特别是在未加保护的环境之中。例如,该
策略应当涵盖物理保护、访问控制、加密技术、备份文件和防范病毒等等方面的需要。该策略还应当包括有
关把设备连接到网络的规则和建议以及对于在公共场所使用这些设备的指导。
在公共场所、会议室和其它在组织的保护范围之外的未受保护的地区。在适当的位置应当有保护措施,以避
免未经授权的访问或者泄露由这些设备存储和处理的信息,例如使用加密技术(见10.3)。
当这种设备在公共场所使用的时候应当小心避免被未经授权的个人从远处看见的危险。这一点很重要。应当
有适当的防止恶意软件的程序并且要对其不断更新(见8.3)。为了确保能够快速而方便地备份信息,这些设
备应当是可用的。这些备份应当得到充分的保护例如防盗和防止信息丢失。
对连接到网络的移动设备移动给以适当的保护。只有经过成功的识别和鉴定之后才可以使用移动计算设备通
过公众网对业务信息进行访问,并且有适当的访问控制机制在(见9.4)。
还应当对移动计算设备加以物理上的保护,以防在离开时被偷窃,例如在轿车和其它交通工具上、在宾馆房
间、会议中心和见面地点等。载有重要信息、敏感和/或者关键的业务信息的设备不应当没人照看,而且如果
可能的话,应当把实物锁起来、或者使用特殊的锁来保护该设备。关于对移动设备进行物理保护的更多的信
息可以在7.2.5找到。
应当训练职工使用移动设备,提高他们对这种工作方式所带来的额外风险和应当实行的管理措施的认识。
9.2.8 远程工作
远程工作用通信技术使得职工能够在组织之外的远程固定地点工作。对远程工作的适当保护应当防止设备和
信息被盗走、未经授权就披露信息、对组织内部系统的未经授权的访问或者设备的误用。远程工作不但需要
授权还要由管理层控制,而且对这种工作方式应当有适当的安排。这一点非常重要。
组织应当考虑开发一种策略、程序和标准来控制远程工作活动。组织应当只授权远程工作活动,如果它们能
够满足有适当的安全设置和管理措施的要求而且符合组织的安全策略的话。应当考虑以下几点:
a) 对远程工作地点现有的物理上的保护,考虑建筑物理的安全和当地环境的安全。
b) 拟定的远程工作环境;
c) 通信安全要求,考虑到对组织内部系统进行远程访问的需要、即将通过通信链接并接收评估的信息的
敏感性和内部系统的敏感性。
d) 在该适应范围例如家庭和朋友的其他人对信息或者资源的未经授权的访问所造成的威胁。
需要考虑的管理措施和安排应当包括:
a) 为远程工作提供适当的设备和存储家具。
b) 对允许做的工作、工作时间、可以保留的信息的分类和远程工作人员被授权访问的内部系统及其服务
分别做出的定义。
c) 提供适当的通信设备包括保护远程访问的方法。
d) 物理安全;
e) 对家庭成员和来客访问设备和访问信息的有关规定和指导;
f) 软件和硬件支持和维护措施的提供。
g) 备份和业务连续性的过程。
h) 审查和安全监测;
i) 远程工作活动停止时,权力的取消、访问权限和设备的归还
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) 在安装之前检测特洛伊代码(渗透性代码);