NIST 800-53(2013版).ppt

关于NISTSP80053新版浅说,针对联邦信息系统和组织，建议的安全控制,2013年6月,开始语NISTSP800-53：为联邦信息系统和组织而推荐的隐私与安全控制（第四版，2013.2）,在实际操作层面上，就如何给出联邦信息系统及IT系统的信息安全需求要求，给出了一些值得借鉴的思路和方法。特别值得注意的是，若能有效地满足这样的需求,IT系统就可达到更安全的（secure），即系统处在一种特定状态，可有效地抵御所面临的不可接受的风险。,IT系统,所处的一种状态,抵御,风险,图：IT系统安全（Secure）,显然，在日常工作中，有的领导所说的“安全”，往往指的是这一含义！,NISTSP800-53给出的一些思路和方法：对于-提升我国信息系统安全等级保护水平;-改善当前我国IT系统安全保护工作;特别是对于我国电子政务和国家重要IT基础设施（例如：工业控制系统）的信息安全，以及对于我国信息安全战略制定、标准化工作、安全技术研发和创新，均具有很好的参考价值。NISTSP800-53，正文加规范性附录共431页。因此本文只能是它的一个“浅说”，但力争做到“画龙点睛”。,为此，本文主要介绍：1、NISTSP800-53概述；2、关于安全控制；3、关于安全控制的选择过程；4、关于IT系统语境下的隐私控制；5、关于信息安全保障与信赖。从以上五方面的内容中，看一下美国如何解决联邦信息系统以及工控系统的安全问题：-思想、途径与手段以实现图0所示的目标。,一、NISTSP800-53概述1、主要内容、意图及其应用范围1)该标准主要内容基于目前信息安全的实践现状,为联邦信息系统和组织,提供了一个综合详细的的安全控制目录。（附录F）为保护组织安全的（secure）运行，提供了安全控制选择过程-一种一致的、可比较的和可重复的途径；针对特定类型的使命/业务功能、技术或运行环境，描述了如何通过剪裁，开发特殊化的控制集或覆盖。为帮助组织执行有关隐私的联邦法律、政策、法规、方针和标准,提供了一个隐私控制集。（附录）,）该标准的意图该标准的意图是,通过以上给出的四方面内容及其指导，支持组织构造可满足FIPS200中针对联邦信息和信息系统所规定的最小安全需求-一种解决方案，以实现有效的风险管理，使联邦政府内的信息系统是更安全的（secure）。可见,该标准的意图是非常明确和具体的。）该标准的应用范围该指导可应用于处理、存储、传输联邦信息的信息系统的所有部件；可应用于所有联邦信息系统。但不可应用于联邦政府所规定的那些国家安全系统。鼓励州、地方和部族政府以及私有部门的组织，适当考虑使用本标准所给出的这些指导。,2、与其它标准的关系这一标准与其它一些重要标准之间的关系可概括为：,FIPS200联邦信息和信息系统的最小安全需求,FIPS199联邦信息和信息系统的安全分类标准,信息系统的安全分类,需求:,需求:,信息系统的最小安全需求,SP800-53:为联邦信息系统和组织推荐的安全控制,指南：基于安全控制基线,形成信息系统的一个特定安全控制集合,SP800-53A:联邦信息系统中安全控制评价指南,评价:,信息系统安全控制的有效性,其中：FIPS200：联邦信息和信息系统最小安全需求，是美国联邦政府的一个强制性联邦标准，是由NIST为响应FISMA而开发的，规定了联邦信息系统的最小安全需求。为了符合这一联邦标准，组织首先按FIPS199：联邦信息系统安全分类标准，确定它们信息系统的安全分类，包括：低风险影响的信息系统；中风险影响的信息系统，高风险影响的信息系统；然后依据该安全分类，按FIPS200导出信息系统的最小安全需求；,最后，合理地应用SP800-53：为联邦信息系统和组织推荐的安全和隐私控制，即依据该标准中给出的控制选择过程指南，剪裁、补偿和补充相应的基线安全控制集，使其更贴切地符合组织使命和业务需求以及运行环境。当然，对所选的安全控制集，在它们的实现与运行中，组织需要不断监视其有效性-是否能抵御已标识的风险。为此，NIST又开发NISTSP800-53A联邦信息系统中安全控制评价指南，其中针对FIPSSP800-53中的安全控制，给出了安全控制评估中可应用的评估规程，并以这些评价规程为基础，回答了：如何构建有效的安全评估计划；如何进行安全控制的评估。,需求类（如：FIPS200；ISO/IEC27001）,指南类（如：NISTSP800-53；ISO/27003,27004,27005）,评价类（如：NISTSP800-53A）,信息安全定义,实施指导,有效性评价,从以上所述标准及其关系来看，就解决IT系统各式各样的安全问题而言，美国遵循了一种实用的问题求解逻辑，即首先制定“需求类”标准，规约IT系统的安全模型-安全需求规约；而后制定“指南类”标准，就实现需求中若干关键环节，给出一个或多个实现指南；最后，制定“评价类”标准，给出评价指南或方法学，评价以上需求是否得以正确和有效的实现。这一“求解实际问题”的标准体系可示意为：,基于目前信息安全的实践,该标准通过附录F，为联邦信息系统和组织，提供了一个综合详细的的安全控制目录。其中包含253个安全控制。1、何谓安全控制所谓安全控制是指：应用于组织信息系统中有关管理上、运行上和技术上的对策（countermeasures),以保护信息系统及其信息的保密性、完整性和可用性。例如安全审计族中的一个控制AU-5:,二、关于安全控制,AU-5审计处理失效的响应控制：信息系统：a.对于审计处理失效的事件，向赋值：组织定义的人员报警；并b.采取赋值：组织规定的动作，例如：停止信息系统的运行，重写老的审计记录，停止生成审计记录等。,类比：该标准中的一个控制，相当于我们标准中的一个“安全要求”，但就质量来说，主要区别是：我们写的“要求”：缺乏“灵活性”；往往不具有一个需求要求的基本属性；（参见P20）缺乏整体上的关联性影响标准的可操作性！,图1：组织的安全程序,组织的安全程序,安全控制通常用于组织的安全程序。所谓安全程序是指一组相互协调的安全控制集，缓解组织及其信息系统的风险。一个安全程序如下图所示：注：对应ISO/IEC27001“建立ISMS”所生成的一个结果（参见其中的风险处置计划）。可见，没有一个有效的安全程序，想达到图所示的目标是不可能的,各类安全风险,缓解,、安全控制的表达为了在安全程序的设计中能正确地应用安全控制，本标准采用相互关联的五部分来描述每一个安全控制，这五部分分别为：控制，补充指导，控制增强，参考文献，优先级和基线分配。例如：,AU-5审计处理失效的响应控制：信息系统：a.对于审计处理失效的事件，向赋值：组织定义的人员报警；并b.采取赋值：组织规定的动作，例如：停止信息系统的运行，重写老的审计记录，停止生成审计记录等。,补充指导：-审计处理失效，例如包括：软硬件错误，审计扑获机制失效，达到或超出审计存储能力等。-组织可针对不同审计处理失效（例如，由于类型、位置、严重程度或这些因素的组合），选择定义附加的措施。-这一控制应用于每个审计数据存储库（即存储审计记录的信息系统部件），应用于组织的整个审计存储能力（即组合了所有审计数据存储库）。相关的控制为：AU-4（审计存储能力），SL-12。,控制增强：（点）（）对审计处理失效审计存储能力的响应在赋值：组织定义的时间段内，当分配给审计记录的存储量达到赋值：组织定义的最大审计记录存储容量的某一百分比时，信息系统向赋值：组织定义的人员，角色和或岗位提供一个警示。（）对审计处理失效实时报警的响应当赋值：组织定义的、要求实时报警的审计失效事件发生时，信息系统在赋值：组织定义的实时报警时间段内，向赋值：组织定义的人员，角色和或岗位发出报警。,（）对审计处理失效可配置的流量阈值的响应信息系统执行可配置的流量阈值，反映对审计能力的限制，并选择：拒绝；延迟网络流量超出这些阈值。（）对审计处理失效失效宕机的响应当发生赋值：组织定义的审计事件发生时，信息系统调用选择：完全宕掉系统，部分宕掉系统；降低运行模式，使之具有有限可用的使命业务，除非存在一种可选的审计能力。参考文献：无优先级和基线分配：,其中：AU-5是该控制的标号，说明它是“审计和可核查性(AU)”族中编号为5的一个安全控制。关于安全控制的组织可参见以下的2）。各部分的内容为：-控制部分：简单陈述了保护组织和信息系统特定方面的特定安全能力，描述了组织或信息系统所要进行的特定安全活动或动作。-补充指导部分：为以上描述的安全控制提供了一些附加信息，期望组织在定义、开发和实现安全控制时，适当地应用该补充指导。,-控制增强部分：陈述了对以上描述的基本控制的强度增强，即对基本控制这一构造的附加功能，但这些附加功能与基本控制是有关联的。控制增强用于需要更强保护的信息系统。-参考文献部分：列出了与特定安全控制和增强具有关系的联邦法律、法规、方针、政策、标准和指南，以便为安全控制的实现和评估获得更多的信息。-安全控制优先级和基线分配部分：给出该控制所在的安全控制基线；并为以后该安全控制的实现决策，给出优先级方面的建议，其中：P1表示最高的实现优先级，是达到相应安全需求的最关键的安全控制；P2表示中等的实现优先级；P3表示最低的实现优先级。,就AU-5例子而言，其“优先级和基线分配”部分指出：该控制已分配给低、中和高影响信息系统的基线；建议它具有最高的实现优先级(P1)。可见，这样表达的安全控制，可具有一些好的特性，例如：就一个需求而言，其基本性质为：必要性；无歧义性；可测性；可跟踪性；可测量性；就整个需求规约而言，应具有的基本性质为：优先与稳定性；无矛盾性；可修改性；完备性等。以支持安全控制的可应用性！,3、安全控制与安全需求及其关系正如以上所说，安全控制通常应用于组织的安全程序。因此，一提到安全控制，通常会涉及一个重要术语-“安全需求”（注：在我国，往往把“安全需求”称为“安全要求”）。其实，安全需求/要求可在不同抽象层上给出，例如：法律、策略、标准以及使命/业务陈述层等。FIPS200说及的安全需求就是在这样的一个层次上。组织为了满足“高层”上所定义的安全需求/要求，为使命/业务提供适当地保护，通常通过一个特定的对策（例如，安全控制）集，来定义所需要的安全能力。如下图所示：,安全需求,安全能力,满足,图2-1:高层上的安全需求,保护,组织的使命/业务,相互增援的安全控制（技术、物理、规程上的手段）,法律、行政命令、使命/业务层,工信部提出的有关工控系统的安全检查针对威胁现状，为使命/业务提供适当地保护。,例如,该图表明，安全控制是实现（realization）“高层”安全需求/要求一些技术、物理、规程上的手段。,再从“低层”的安全实施角度来看，组织（或安全服务提供者）应从不同的视觉管理视角，运行视角，技术视角等，以安全控制作为基本元素，开发强调安全需求的安全规约。如下图所示：,安全需求规约,开发,安全控制,图2-2:实施层上的安全需求,相互增援的安全控制（技术、物理、规程上的手段）,这意味着，在安全工程这一“较低”的抽象层上，安全控制是表达该层”安全需求的语言。,接着，系统开发人员，系统/安全工程师工作于安全控制的设计、开发和实现层上，将该安全需求规约中的安全控制分配给信息系统中不同的部件。例如：,系统部件1,系统部件2,系统部件3,系统部件4,系统部件5,安全控制3,安全控制2,安全控制1,分配给,分配给,分配给,图2-3:安全需求的开发（1）,信息系统,最后在机制层上，以硬件、软件和固件等，实现(implement)特定的安全功能。如下图所示：,系统部件1,系统部件2,系统部件3,系统部件4,系统部件5,安全控制3,安全控制2,安全控制1,分配给,分配给,分配给,图2-4:安全需求的开发（2）,信息系统,安全机制1：例如防火墙,安全机制2：例如身份鉴别,实现,实现,注意，在这一图示中，没有给出实现“安全控制1”的安全机制，这是为了说明，安全需求还可以通过一些非技术控制来反映。这些非技术控制往往作为组织不同详细层上管理方面和运行方面的元素，关注“注入”的策略和规程等。,以上内容可概括为：,安全需求,安全能力,满足,图2-5:安全需求、安全控制、控制实现之间的关系,保护,组织的使命/业务,相互增援的安全控制（技术、物理、规程上的手段）,法律、行政命令、使命/业务层,工信部提出的有关工控系统的安全检查针对威胁现状，为使命/业务提供适当地保护。,例如,与实现安全控制有关的机制、策略和规程所提供的安全功能,安全功能,实现,因此，不论是一个安全技术标准（例如：我们编制的标准经常称为安全要求），还是一篇信息安全论文，或是一次有关信息安全工作的讲话或文件，重要的是：一要对于每次使用的术语“安全需求要求”，定义其使用语境；二要了解“安全需求/要求”与“安全控制”之间的关系；三要不论是在高层还是在低层上所陈述的信息安全需求要求，均应具有以上所述的一些基本特性（参见2）。这样，才能使相关人员（包括负责策略、使命/业务保护以及工程技术人员等）可清晰地沟通他们的意图，才能提高标准/文件的质量，特别是提高它们的可操作性！,、安全控制的组织既然安全控制是规约安全需求的一种语言，因此，为了支持安全控制的选择-容易理解、使用安全控制，该标准把安全控制按“类”、“族”的形式予以组织。因为分类是人们认识客观世界的一种基本（构造）方法。,类,族,族,族,安全控制1,安全控制2,安全控制3,共：三个类管理类；运行类；技术类。十八个族（含安全程序管理族）253个安全控制。（1）管理类管理类分为五个管理族：系统和服务获取；风险评估；规划；安全评估和授权，外加：（安全）程序管理。,每个族中又包含一些特定的安全控制，例如：,管理族共：43个安全控制。,（2）技术类技术类分为四个技术族：访问控制，审计和可核查性，标识与鉴别，系统和通讯保护。例如：,技术类共77个安全控制。,（3）运行类运行类分为九个运行族：学习与培训，配置管理，持续性规划，事件响应，维护，媒介保护，物理和环境保护，人员安全，系统和信息完整性。例如：,运行类共86个安全控制。,在附录F中，给出了可适用于组织、独立于任何信息系统信息安全需求的安全控制。主要用于构建组织的安全程序。在附录G中，针对安全程序管理，给出了1个控制，其控制对象主要是附录中那些最基本的安全控制。,作用于,图3：组织的安全体系示意,组织的安全程序,组织的安全管理程序,注：安全程序是一组相互协调的安全控制集，应对组织及其信息系统的风险。-对应ISO/IEC27001“建立ISMS”所生成的结果,注：安全管理程序是一组作用于安全程序的控制，对安全程序实施有效的管理。-对应ISO/IEC27001“监视与评审ISMS”和“维护与改进ISMS”所生成的结果,1、背景：多层风险管理途径为了实现组织的最终目的，即组织在逐日运行中，支持组织使命和业务功能的IT系统达到“充分必要”的安全（secure），完成组织所规定的使命和业务功能，组织就必须：-标识、缓解来自其信息和信息系统的风险，并在一个持续不断的基础上监视之。-基于风险，进行安全控制选择以及规约，形成操作层面上的信息安全需求规约-IT系统的一种安全解决方案（参见图2-2）。,三、关于安全控制的选择过程,为此，通常使用一种紧密相关的三层途径来关注风险:,战略层面上的风险管理,战术层面上的风险管理,层1,组织,层2,使命/业务功能,层3,信息系统,图4:一种三层的风险管理途径,-基于风险决策的可跟踪性和透明性组织范围内的风险了解,层内和层外的沟通就不断改善的反馈循环,层：组织层（或称管制层）从组织的视角关注风险，即在组织层面上,开发一个综合详细的治理结构和风险管理战略。例如：在层1上可形成以下有关风险的决策：组织的风险管理战略目标；组织使命业务功能的优先度;组织关切的信息安全风险类型及其评估技术和方法学；风险缓解措施类型，以及风险缓解程度；风险接受准则；风险监视战略等。-战略层面上的风险管理组织层面的风险治理结构以及风险管理战略，驱动了投资和基金决策提高核算、有效的信息技术解决方案（如图2-2至图2-4）与组织战略目标的一致性，提高性能指标。,层：使命/业务过程层（或称风险管理规划层）该层从使命和业务过程视角关注风险，即基于层1上有关风险的决策，规划组织的风险管理项目。主要活动包括：定义支持组织使命业务功能所需要的使命业务过程；确定执行该使命业务过程所需要的信息系统之安全范畴；把信息安全需求编入到使命业务过程之中；建立组织业务的体系结构（包括被嵌入的信息安全体系结构），以便服务于把安全控制分配到组织的信息系统及其它们的运行环境之中从战略层面向战术层面转移,3)层3:信息系统层（或称风险管理执行层）该层从信息系统的视角关注风险，即遵循层1和层2上的风险决策,具体实施如下风险管理框架的六个步骤。,体系结构描述体系结构基准模型片段和解体系结构使命和业务过程信息系统边界,组织输入法律、方针、策略指导战略目标和目的优先级和资源可用性供应链考量,过程观点,开始点,步骤分类信息系统,步骤选择安全控制,步骤监视安全控制,步骤实现安全控制,步骤授权系统运行,风险管理框架,步骤评估安全控制,必要时重复,图5:风险管理框架,-主要是战术上的风险管理。,其中：第一步：基于FIPS199的影响评价，分类信息系统。第二步：基于安全分类的结果，并当需要时应用剪裁指导，为该信息系统选择初始的基线安全控制集。第三步：实现安全控制，并就控制的设计、开发、实现细节建立文档。第四步：评价安全控制，以便确定为满足系统安全需求，控制正确实现的程度，按期望运行的程度，以及产生预期结果的程度。,第五步：基于由于运行和使用信息系统所产生的对组织运行和资产、个人、其他组织和国家的风险之确定，以及有关可接受风险的决定，授权信息系统的运行。第六步：在一个持续不断的基础上，监视信息系统中的安全控制和运行环境，以便确定以下两种情况下控制的有效性：-对系统环境的改变；-符合法律、行政命令、方针、策略、规章制度和标准。注：NISTSP800-37有关该框架的应用提供了指导。在附录中，列出了所有支持该框架及其所引用的完整标准,可见，该框架上的步骤主要是战术上的风险管理，提供了一个涉及多学科知识的结构化过程，把信息安全和风险管理活动予以科学地集成在一起。即:体现了系统的信息安全：security保护系统及其信息，免遭人为的未授权访问（保密性），免遭人为的未授权修改（完整性），免遭人为的拒绝服务攻击（可用性）等；注意：security、afety以及reliability。,P,D,A,C,对系统安全有关风险的,图6:风险管理框架实现风险管理的一种方案,P:分类系统和安全控制选择,D:安全控制实现,C:安全控制评估,A:监视系统安全状态与系统授权,体现了风险管理的P-D-C-A循环：,综上可见，图所示的风险管理途径明确地表明，为了实现组织信息系统及其信息的信息安全：（1）离不开组织的风险治理结构和组织的信息安全战略。有了它们，才能有效地支持战略转移，实施战术层面上的具体风险管理活动，实现关键IT基础设施的信息安全。（2）离不开持续不断地实施风险相关的活动，包括：风险标识，风险分析，风险评估，风险处置，风险接受；特别是；（3）离不开在实施风险管理活动中，（层内、层外）所有关切组织使命业务成功的利益有关方之间的有效沟通，并不断改善之，以便把风险管理从战略层面有效地过度到战术层面。,在组织三层风险管理层次体系的语境下，由于安全控制选择主要涉及具体操作层面上的安全需求-一种安全解决方案的开发（参见图2-2），因此，该标准集中于该RMF的第二步安全控制选择，给出相关的指导。注意：安全控制的实现（该RMF的第三步），主要涉及具体操作层面上的安全控制到系统部件的分配，以及实现相关安全控制的机制（参见图2-3和图2-4），即我们经常所说的系统安全需求要求的实现。,2、安全控制基线组织准确地缓解在执行使命和业务功能中由于使用信息和信息系统所产生的风险，一个重大挑战是，确定更合算的、更合适的安全控制集-组织和系统的安全需求规约。其中，更合算的、更合适的安全控制集是指：如果把它们能以合理的成本予以实现，并能确定它们是有效的话，就能缓解组织的安全风险，符合可用的联邦法律、行政命令、政策、方针或标准（例如：FISMA,FIPS200等）所定义的安全需求。可以肯定地说，没有一个现成的安全控制集，能正确的处理所有组织、所有情况下的安全问题。因此，为一个特定情况或为组织信息系统，选择更合适的安全控制集能准确地缓解风险，这是一项重要的任务。,为了支持组织就信息系统做出安全控制的合适选择，该标准引入了“安全控制基线”概念。在FIPS200中，把安全控制基线定义为：针对低、中、高影响的信息系统所定义的最小安全控制集，该控制集为安全控制的剪裁过程提供了一个起始点。注意，这一定义说明，该标准所说的安全控制基线，也不是一个可实现信息系统安全需求的控制集，仅是为开发信息系统安全需求进行安全控制选择的起始点！在该标准的附录D中，分别对应：低影响信息系统、中影响信息系统、高影响信息系统，标示出三个基线控制集。其中，基线1包含129个安全控制；基线2中包含172个安全控制；基线3中包含182个安全控制或增强。,3、安全控制选择过程既然该标准中给出的安全控制基线，也不是可处理所有组织、所有情况中安全问题的正确控制集，仅作为进行安全控制选择的起始点！因此，为了达到“在安全计划中的安全控制集，必须是充分的”，实现组织及其信息系统安全（secure）的目标,就必须实施一个过程，即选择并规约安全控制和控制增强的过程，该过程包括：选择合适的安全控制基线；剪裁所选择的基线；创建覆盖；建立控制选择过程文档。,）选择安全控制基线FIPS199要求组织按安全目的保密性、完整性和可用性,执行RMF的步骤1，把信息系统分类为低、中、高影响的系统。表达一个信息系统安全分类的一般格式是：SC信息系统(保密性影响),(完整性影响),(可用性影响)，其中，可接受的潜在影响值为：低、中、高。由于保密性、完整性、可用性的潜在影响值对一个特定信息系统不可能总是一样的，因此为了确定信息系统的风险影响等级，FIPS199使用了“高透明水印概念”，即：-定义为低影响等级的信息系统，其中所有三个安全目的均是低等的；,-定义为中影响的信息系统，其中至少有一个安全目的是中等的，并且没有一个安全目的高于中等的；-定义为高影响的系统，其中至少有一个安全目的是高等的。依据执行RMF步骤1的结果-系统的风险影响等级，就可在附录D中选择一个和该等级相对应的一个安全控制基线。即：如果系统的风险影响等级为“低”，则选择基线1；如果系统的风险影响等级为“中”，则选择基线2；如果系统的风险影响等级为“高”，则选择基线3。,）剪裁（tailoring）基线安全控制在从附录中选择基线安全控制的初始集之后，组织开始该剪裁过程-剪裁基线安全控制。剪裁过程包括以下6个活动：标识并标示所选初始基线中的共用控制；应用范围考虑，剪掉该基线中不必要的安全控制（除共用控制之外）；如果需要的话，选择补偿(compensating)安全控制；定义安全控制参数（包括：赋值陈述和选择陈述，参见AU-5）的值；如果需要的话，用附加的安全控制和控制增强，补充(supplementing)该基线安全控制；如果需要的话，提供附加的控制实现规格说明信息。,初始的安全控制基线（低、中、高）剪裁前,经剪裁的安全控制基线（低、中、高）剪裁之后,剪裁指导标识并标示共用控制应用范围考量选择补偿控制赋安全控制参数值补充基线安全控制为实现提供附加规约信息创建覆盖,建立安全控制决定的文档共识的安全控制集之理由：信息系统为组织运行、资产、个体、其他组织和国家提供准确保护,下图概括了安全控制剪裁过程：,图7:安全控制剪裁过程,其中应当注意：有关共用控制的标识与标示共用控制是指由组织的一个或多个信息系统所继承的安全控制。共用控制可从许多源继承而来，例如包括：该组织的使命业务线，场地，飞地、运行环境或其它信息系统。,信息系统1,信息系统2,信息系统3,继承,共用控制,源于,使命业务线场地飞地运行环境其它信息系统,图:共用安全控制及其源,其中：为保护组织信息系统所需要的许多安全控制，例如：安全知识培训，事件响应计划，对设施的物理访问，行为规则等，对共用控制来说是非常好的后选。另外，还可能存在一些基于不同技术的共用控制（例如：PKI，针对客户服务器的经授权的安全标准配置，访问控制系统，边界保护，跨域解决方案）。在剪裁过程中，首先标识并标示共用控制的动机是，通过集中建立并管理共用控制的开发、实现、评价、授权和维护文档，就可减少相关多个系统的安全成本。,关于范围考虑范围考虑包括：-考虑与安全控制分配和放置有关的问题；-考虑与运行环境有关问题，诸如可移动性；单一用户系统和运行，数据连接性和带宽度；有限功能系统或系统部件；非持久性信息和系统；公共访问等；-考虑与安全目的有关的问题；-考虑与策略规章有关的问题；-考虑与使命需求有关的问题等，通过这些考虑，可剪掉该基线中一些不必要的控制，保留那些必要的控制。例如：对于单一用户的系统而言,诸如AC-10（当前会话控制）、SC-4（共享资源中的信息）以及AC-3（访问增强）等这样的安全控制，可能就是不需要的控制,关于选择补偿控制选择补偿控制是指组织为其信息系统和这些系统所处理的、存储的、或传输的信息，有选择地使用的一些安全控制，替代附录D中低、中、高基线的一些特定控制，提供等价的或可比的保护。例如，当组织不能有效实行基线中安全控制时，或当由于信息系统及其运行环境的特定本性，就获得所需要的风险环节而言，基线中的控制不是一种合算的手段时，就要使用补偿控制。通常，应用对初始基线安全控制的剪裁过程指导中的应用范围考虑之后，来选择补偿控制。,补偿控制可由组织在如下条件下使用之：从附录中选择补偿控制，其中如果没有合适可用的补偿控制，组织可采用其他源中合适的补偿控制；组织为补偿控制如何为组织信息系统提供等价的安全能力以及为什么不能使用该基线安全控制，给出支持理由；组织评价并接受与实现组织信息系统中补偿控制相关联的风险。,关于补充安全控制补充安全控制是指为了充分地缓解对组织运行和资产、个人、其他组织和国家的风险，需要对附录D中那个基线增加一些必要的安全控制或控制增强，以便处理对组织、使命业务过程和或信息系统的特定威胁和脆弱性，并满足可用法律、行政命令、方针、政策、标准和规章。安全控制选择过程中的风险评价，为确定基线中必要的、充分的安全控制和控制增强，提供了基本的信息。应鼓励组织最大程度地使用附录来服务于补充初始基线的过程，在此基础上增加安全控制和或控制增强。显然，补偿和补充是两个不同的概念。,在实施该剪裁过程中，第一点，组织不能随意就运行方便就从所选的基线中拿掉一些安全控制；第二点，安全控制的剪裁决策，包括剪掉、补偿和补充的决策，应基于使命业务需要，是可辩解的，并伴有明确的、基于风险的决定。有关剪裁决策的特定理由，以及剪裁出一些安全控制及其理由，均要记录在组织信息系统的安全计划中，并作为安全计划批准过程的一部分，得到负责这项工作的组织官员批准。,3）创建覆盖(overlay)以上从关注与组织相关安全能力的角度，描述了剪裁初始安全控制集的过程。但在某些情况下，可能更需要为更大的范围（例如一个行业），或为处理特定的需求、技术或独特的使命运行环境，应用剪裁基线的指导，开发一个相应的安全控制集。例如1：为政府建立以下系统的安全控制集及实现指南：-PKI系统可唯一地应用于所有联邦各局内所实现的PKI系统；-基于云的信息系统，可唯一地应用于购置或实现云服务的联邦各局的信息系统；-工业控制系统支持联邦层面上的产电或电力调度系统。,例如2：为了处理关切特殊需求的特殊团体，如国防部，应用该剪裁指导，就战术作战系统以及环境，建立一个安全控制集，并给出实现指导，以便标准化国家安全系统的安全控制基线，实现特殊化的解决方案。由以上的例子可以看出，可应用以上提及的剪裁过程，针对每一特定的信息技术，或针对独特的情况环境来开发一个相应的基线，向关切的行业/部门予以颁布，以达到标准化的安全能力、一致的实现和合算的安全解决方案。为此，该标准针对信息系统和组织，为了处理行业/部门内以及特殊的安全控制集的开发，引入了一个概念覆盖。,一个覆盖是应用以上所述的剪裁指南，针对一种特殊需要（包括范围需要，或特定技术和环境需要）而建立的一个完整规约的安全控制、控制增强集，以及所导出的补充指导。关于一个覆盖的格式可参见附录I。注意，覆盖概念的提出：体现了美国在处理各不同技术、不同行业中，应用“现成”知识的思路；体现了美国在处理各不同技术、不同行业中，标准制定的思路。,（2）开发覆盖的活动通常，附录D中的三个基线均具有一些基本假定/前提。这些假定或前提可能涉及诸如：信息系统被存放在的物理设施；组织信息系统中的用户数据信息是相对永久的；信息系统的运行是多用户的；组织信息系统中的某些用户数据信息并不可与其他已授权访问同一系统的用户共享；信息系统存在于网络化的环境之中等。至于在什么情况下有必要开发覆盖，这取决于以上所述的“特定信息技术、计算风范、运行环境、信息系统类型、使命运行类型、运行模式以及法律法规的需求”，是否与这些假定/前提存在矛盾，若存在矛盾的话，组织就应使用覆盖概念来创建初始的安全控制基线；否则，就可能不需要创建一个覆盖。,开发一个覆盖，通常通过以下活动，补充初始的安全控制基线：给出增加或消除控制的机会；为特定信息技术、计算风范、运行环境、信息系统类型、使命运行类型、运行模式、工业部门，以及依照法律法规的需求，提供可应用的安全控制集；为控制和控制增强中的赋值和选择陈述，建立行业/部门内的参数值；在必要的地方，扩展安全控制的补充指导。,（3）开发覆盖中注意的问题在开发覆盖中，组织可有效地使用NISTSP800-39中定义的风险管理概念。成功开发覆盖，要求以下人员的参与：了解覆盖开发、关注特定主题的安全专业人员；了解附录中安全控制和附录D中初始基线的主题专家。可应用单一安全控制基线，开发多重覆盖。由覆盖开发过程所产生的经剪裁基线，与原来那个安全控制基线可能更具有说服力，或缺乏说服力。风险评价为确定实现该剪裁基线是否符合关切开发该覆盖组织或团体的风险容忍，提供了必要的信息。,如果使用多重覆盖，就有可能在这些覆盖之间存在冲突。如果使用多重覆盖导致应用安全控制之间或移出安全控制之间的冲突，那么授权官员（或指定代表），就可与使命业务拥有者和或信息拥有者服务代理一起协商，解决该冲突。一般地，期望通过覆盖，减少在选择一个更紧密对应公共环境、情况和或条件的控制和控制增强集中组织的“特奇”剪裁基线的需要。但是，不能因为使用覆盖，阻止了组织为反映组织特定需要、假定或约束而执行进一步剪裁。例如，为ICS创建了一个覆盖，可能针对一个特定类型的ICS及其运行环境，有关可应用性要求一个剪裁。但要预见，使用覆盖应最大减少组织特定“奇特”剪裁的数目和程度。,在安全控制目录中给出的安全控制，除了很少几个之外，均被设计为：本质上是策略的和技术的。这意味着：安全控制和控制增强集中于必要的基础性对策(countermeasures)-保护处理期间、存贮和传输期间的信息。因此，如果把安全控制应用于特定技术、运行环境，以及应用于关切的行业或使命/业务，就要通过：使用所描述的剪裁过程，以及所描述的覆盖（overlaps），来处理这些特定的应用领域。,使用本质上是技术和策略的安全控制，具有以下好处：它鼓励组织集中于使命/业务成功所需要的安全能力，集中于信息保护，不再特别考虑组织信息系统中所使用的信息技术；它鼓励组织针对特定技术、运行环境、使命/业务功能以及团体的关切，分析每一安全控制的可应用性；它鼓励组织作为剪裁过程的一部分，来规约具有变化参数的安全控制。使用剪裁指导和覆盖所形成的特定化安全控制，与一个健壮的、本质上是技术和策略的安全控制一起，可提高组织-任何部门、任何技术和任何运行环境的成本合算、基于风险的信息安全。,4）建立控制选择过程文档组织在选择安全控制过程期间，在安全计划中记录所产生的安全控制集和有关选择决策的支持理由（包括组织对任何信息系统的使用限制）。记录安全控制选择过程中充分的风险管理决策，可使授权官员为组织信息系统做出正式的授权决策，访问必要的信息。当信息系统或运行环境改变状态并修订原来的风险决策时，有关信息系统的理解、假定、约束以及支持这些风险管理决策的理由，完全可能是不可用的。,在选择和规约安全控制中，特别注意：-有关组织的剪裁决策，应紧密地贴切组织一贯强调的风险因素，并且在决定把一些控制整个用于组织信息系统及其运行环境中，要考虑诸如成本风险、进度以及性能等风险因素。简言之，应把安全控制选择过程（包括剪裁活动），集成于组织整个风险管理过程（参见NISTSP800-39）。-针对所选择的控制，在实现程度严格性方面应该是可量度的，即针对特定运行环境，按系统影响等级给出控制的刻度，这样有助于形成更合算、基于风险的安全控制实现途径。,）关于安全控制选择过程的应用可应用于新开发的系统和遗产系统安全控制选择过程，从两个不同的视觉，可应用于组织的：新开发的系统；遗产系统。对于新开发的信息系统，从需求定义视角来应用安全控制选择过程，因为系统并非存在，而且组织进行初始的安全分类包含在信息系统安全计划中的安全控制，作为一个安全规格说明，并期望在系统开发生存周期的开发和实现阶段被编入到该系统中。,对于遗产信息系统，从间隙分析的视角，当组织预期对该系统进行大量改变（例如，升级、修改或外包期间）时，就应用该安全控制选择过程，因为该信息系统已经存在，组织完全可能已完成了安全分类和安全控制选择过程，在对应的安全计划中，以前建立了达到共识的安全控制，并在该信息系统中实现了这些控制。因此，可按以下方式来应用间隙分析：首先，必要时基于当前正被该系统处理的、存储的、传输的信息，重新证实或修订信息系统的安全分类和影响等级；其次，考虑任何对安全分类和信息系统影响等级的调整，以及对组织、使命业务过程、系统或运行环境的改变，评审描述当前使用的安全控制的现有安全计划。必要时，重新评价,风险并修订安全计划，包括记录该系统将需要的任何附加的安全控制，以确保对组织运行、组织资产、个人、其他组织和国家的风险仍在可接受的程度。第三，实现经调整的安全计划中的安全控制，并以同样方式，作为一个新开发的系统，继续风险管理框架中的其他步骤。当然，这一间隙分析还可应用于外部服务提供者。,四、关于IT系统语境下的隐私控制,一般地说,隐私是指：()Therightofanentity(normallyaperson),actinginitsownbehalf,todeterminethedegreetowhichitwillinteractwithitsenvironment,includingthedegreetowhichtheentityiswillingtoshareinformationaboutitselfwithothers.一个实体（通常为一个人）的权力,以自己名义的行动-确定与其环境相互交互的程度，包括该实体就自己的信息希望与其他人共享的程度。()Therightofindividualstocontrolorinfluencewhatinformationrelatedtothemmaybecollectedandstoredandbywhomandtowhomthatinformationmaybedisclosed.“个人有关控制或影响自己有关信息的收集和存储，以及可通过谁和向谁泄露此信息的权力。”,由以上“隐私”的定义来说：隐私就是一种权力；该权力涉及“个人信息”（PII）；涉及“个人信息”上的操作，包括：收集、存储、泄露等；涉及谁能执行这样的操作,以及按什么原则来执行操作,才能满足隐私的定义!当然“隐私保护”就是保护这种权力。为此，在处理PII的ICT系统语境下，在ISO/IEC29100隐私框架中，采用框架技术,把隐私定义为：,隐私保护需求,隐私策略,隐私控制,图8：隐私框架概示,控制,PII本人,PII控制者,PII处理者,第三方,控制,提供,接受,处理,PII控制者,演化为,处理PII的ICT系统,PII,2019/12/1,75,可编辑,特别是，PII控制者确定处理现有PII的意图以及如何处理。在这一框架中，PII控制者应确保在PII处理期间，在他的控制下，一直遵循隐私原则，例如：这些“隐私原则”可体现隐私这种权力如何使PII控制者及其授权的使用者遵循这些基本的隐私原则？其基本途径就是通过实现必要的隐私控制！,1、同意和选择2、意图合法性和规约3、收集限制4、数据最小化5、使用、保留和泄露限制6、准确及质量7、开放、透明和注意8、个体参与和访问9、可核查性10、信息安全11、隐私符合性,例如：,SE-1建立PII的目录控制：组织建立、维护PII的目录,并按赋值：组织定义的时间段调整PII目录，包括列出收集、使用、维护或共享PII时所标识的所有程序和信息系统。按赋值：组织定义的时间段，向CIO或信息安全官提供每次对PII目录的调整，以便支持所有新的或修改的（包含PII的）信息系统，建立信息安全需求。,显然，该隐私控制支持以上隐私原则“10信息安全”。,附录为保护隐私提供了一个结构化控制集，以保护PII并确保正确处理PII。共8个族，26个控制。,该隐私控制目录，是对原NISTSP800-53的补充。期望依此来处理联邦各局的隐私需要。隐私防护与隐私控制之间的关系为：,隐私防护,隐私控制1,隐私控制2,隐私控制26,实现,图：隐私防护与隐私控制之间的关系,该隐私附录的目的有四：基于国际标准和最佳实践，提供一个结构化的隐私控制集合，有助于组织执行由联邦法律、政策、法规、方针、标准和指南所导出的隐私需求。为执行相关的隐私和安全需求之目的，建立隐私控制和安全控制之间的可连接性和关系，其中在联邦信息系统、程序和组织中，这些控制在概念上和实现上可能是重叠的。证实NIST风险管理框架的可应用性，即可应用其中的选择、实现、评价、监视，在联邦信息系统、程序和组织中部署相应的隐私控制。,提高联邦政府内隐私和安全官员之间的紧密操作，有助于实现高层领导在执行联邦法律、政策、法规、方针、标准和指南等方面需求的目的。隐私计划和安全计划一起使用，为组织依据其使命/业务需求和其运行环境来选择合适的安全和隐私控制集，提供了一种机遇。用于管理信息安全风险的同样概念之间的互操作，有助于组织以更合算的、基于风险的模式实现隐私控制，不但保护个人隐私，还同时满足符合性需求。标准化的隐私控制，为满足联邦隐私需求并证实符合这些需求，提供了一种更科学的、结构化的途径。,五、关于信息安全保障与信赖通过以上所说的安全控制和隐私控制，以及有关安全控制选择指导，可正确规约操作层面上系统和组织的安全需求和隐私保护需求，但能否在实现层面上正确实现，这直接关系到“信息安全，保护个人隐私”是否“可信”的问题。显然，一个组织，特别是该组织的领导肯定十分关注这一问题。实际上，可信问题涉及以下四方面基本内容：何谓可信与保障；保障证据-一类保障值；实现高保障的开发和运行活动；4关于联邦信息系统和组织的最小保障需求,从信息安全的角度，可信是相信与安全相关的实体，在规定的条件或情况下，其行为将按预先指定的方式，满足所定义的安全需求集，即使遭到破坏、人为错误、部件失败和失效，以及运行环境中可能发生有意攻击。,可信（一般意义上的可信）,可信（信息安全领域中的可信）,一般地，可信是相信一个实体的行为，在特定的环境中以及在特定的条件或情况下，将按预先指定的方式执行特定的功能。其中该实体可以是一个人、信息系统、系统部件或任何组合。,图10:安全的可信概念,1、何谓可信（trust）与保障下面，按一般/特殊的形式，首先给出安全可信的概念。,由以上有关信息安全的可信定义可知，确定“可信”一般关联到特定的安全能力（参见图4），并涉及到一个系统部件或整个信息系统。因此，一定要注意：第一，由可信的系统部件集所组成的一种安全能力，其结果并不能达到信息系统层面上是可信的；第二，系统层面上的可信，本质上是一种主观的确定，涉及各实体（即技术部件，物理部件和个人）之间复杂的交互，还要考虑由此导出的管制、开发、运行以及维持系统生存的活动。因此，要使安全能力是可信的，就要求在提供这样能力的相关实体集中，就可信或信赖而言存在一个充分的基础。该基础涉及两类基本成分：安全功能和安全保障。,安全功能：通常用组织信息系统或其运行环境中所实现的安全特征（feature）、功能、机制、服务、规程和体系结构等来定义之。用于抵御所标识的风险。安全保障：是有关“安全功能予以正确实现，按预期那样运行，并就满足系统的安全需求，产生预想的结果（即准确地修补和执行了已建立的安全策略）”这一事实的信心之测度。注意，以上两方面均隐含着与提供安全能力相关的实体集为了理解安全保障的概念，下面给出一个图示：,可见，保障是“可信”的一个重要元素。,该标准中给出的安全控制，强调了安全功能和安全保障。其中：某些控制主要关注安全功能；另一些控制主要关注安全保障；还有一些安全控制，既支持安全功能又支持安全保障（例如：RA-5脆弱性扫描，SC-3安全功能隔离，AC-25基准监视器。组合一些与功能相关的安全控制，来开发安全能力（参见图），并运用具有一些与保障有关的控制在组织风险容忍内，提供该能力方面的信心。,2保障证据由图1可知，保障属性的“值”，来自于系统开发和运行活动，来自于运行环境中，并通常体现为“证据”。（1）开发环境中所产生的证据依据信息系统开发人员、实现人员、运行人员、维护人员和评估人员所采取的动作，组织获得安全保障。由个体和或小组在信息系统开发运行期间，为交付该安全能力所需要的安全功能所从事的动作，可产生对保障或信心测度有贡献的安全证据。这些动作的深度和覆盖度（参见附录）还贡献于该证据和信心测度的有效性。在系统开