NIST 800-53(2013版)

关于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”的安全机制，这是为了说明，安全需求还可以通过一些非技术控制来反映。这些非技术控制往往作为组织不同详细层上管理方面和运行方面的元素，关注“注入”