logo资料库

信息安全风险评估-脆弱性识别-操作系统脆弱性表格.doc

发布时间：2022-06-06 发布人：admin 分类：说明书 资料大小：0.19M 资料格式：doc 举报 版权申诉
第1页 / 共11页
第2页 / 共11页
第3页 / 共11页
第4页 / 共11页
第5页 / 共11页
第6页 / 共11页
第7页 / 共11页
第8页 / 共11页
资料共11页，剩余部分请下载后查看
    服务器脆弱性识别表格 依据《GB/T20272-2007 操作系统安全技术要求》中第三级---安全标记保护级所列举内 容编制。 项目 子项 内容 是否符合 备注 安 全 功能 身 份 鉴别 自 主 访 问 控制 a) 按 GB/T 20271-2006 中 6.3.3.1.1 和以下要求 设计和实现用户标识功能： ——凡需进入操作系统的用户，应先进行标识（建立 账号）； — — 操 作 系 统 用 户 标 识 应 使 用 用 户 名 和 用 户 标 识 （UID），并在操作系统的整个生存周期实现用户的唯 一性标识，以及用户名或别名、UID 等之间的一致性； b) 按 GB/T 20271-2006 中 6.3.3.1.2 和以下要求 设计和实现用户鉴别功能： ——采用强化管理的口令鉴别/基于令牌的动态口令 鉴别/生物特征鉴别/数字证书鉴别等机制进行身份鉴 别，并在每次用户登录系统时进行鉴别； ——鉴别信息应是不可见的，在存储和传输时应按 GB/T 20271-2006 中 6.3.3.8 的要求，用加密方法进行 安全保护； —— 过对不成功的鉴别尝试的值（包括尝试次数和 时间的阈值）进行预先定义，并明确规定达到该值时 应采取的措施来实现鉴别失败的处理。 c) 对注册到操作系统的用户，应按以下要求设计和 实现用户-主体绑定功能： ——将用户进程与所有者用户相关联，使用户进程的 行为可以追溯到进程的所有者用户； ——将系统进程动态地与当前服务要求者用户相关 联，使系统进程的行为可以追溯到当前服务的要求者 用户。 a) 允许命名用户以用户的身份规定并控制对客体 的访问，并阻止非授权用户对客体的访问。 b) 设置默认功能，当一个主体生成一个客体时，在 该客体的访问控制表中相应地具有该主体的默认值； c) 有更细粒度的自主访问控制，将访问控制的粒度 控制在单个用户。对系统中的每一个客体， 都应能够实现由客体的创建者以用户指定方式确定其 对该客体的访问权限，而别的同组用户 或非同组的用户和用户组对该客体的访问权则应由创 建者用户授予； d) 过确认用户身份的真实性和记录用户的各种成 功的或不成功的访问，使用户对自己的行为承担明确 的责任； 自主访问控制能与身份鉴别和审计相结合，通
    e) 客体的拥有者应是唯一有权修改客体访问权限 的主体，拥有者对其拥有的客体应具有全部控 制权，但是，不允许客体拥有者把该客体的控制权分 配给其他主体； f) 定义访问控制属性，并保护这些属性。主体的访 问控制属性至少应有：读、写、执行等；客 体的访问控制属性应包含可分配给主体的读、写和执 行等权限； g) 定义分配和修改主体和客体的访问控制属性的 规则，并执行对主体和客体的访问控制属性的 分配和修改，规则的结果应达到只有被授权的用户才 允许访问一个客体； h) 定义主体对客体的访问授权规则。该规则应基于 主体对客体的访问控制属性，授权的范围应 包括主体和客体及相关的访问控制属性，同时应指出 主体和客体对这些规则应用的类型。 标记 a) 采用标记的方法为操作系统 SSOOS 安全功能 控制范围内的主体和客体设置敏感标记。这些敏 感标记构成多级安全模型的的属性库。操作系统主、 客体的敏感标记应以默认方式生成或由 安全员进行建立、维护和管理； b) 当信息从 SSOOS 控制范围之内向 SSOOS 控 制范围之外输出时，可带有或不带有敏感标记；当 信息从 SSOOS 控制范围之外向 SSOOS 控制范围 之内输入时，应通过标记标明其敏感标记。 a) 由专门设置的系统安全员统一管理操作系统中 与强制访问控制等安全机制有关的事件和信 息，并将系统的常规管理、与安全有关的管理以及审 计管理，分别由系统管理员、系统安全员和系统审计 员来承担，按职能分割原则分别授予它们各自为完成 自己所承担任务所需的权限，并形成相互制约关系； b) 强制访问控制应与用户身份鉴别、标记等安全功 能密切配合，使系统对用户的安全控制包含从用户进 入系统到退出系统的全过程，对客体的控制范围涉及 操作系统内部的存储、处理和传输过程； c) 运行于网络环境的分布式操作系统，应统一实现 强制访问控制功能； d) 运行于网络环境的多台计算机系统上的网络操 作系统，在需要进行统一管理时，应考虑各台计算机 操作系统的主、客体安全属性设置的一致性，并实现 跨网络的 SSOOS 间用户数据保密性和完整性保护 对于以数据流方式实现数据交换的操作系统，一般应 按 GB/T 20271-2006 中 6.3.3.6 的要求，设计 和实现操作系统的数据流控制功能。 强 访 问 控 制 数 据 流 控 制
    安 全 审计 用 户 数 据 完 整 性 a) 安全审计功能应与身份鉴别、自主访问控制、标 记、强制访问控制及完整性控制等安全功能紧密结合； b) 提供审计日志、实时报警生成，潜在侵害分析、 基于异常检测，基本审计查阅、有限审计查阅和可选 审计查阅，安全审计事件选择，以及受保护的审计踪 迹存储和审计数据的可用性确保等功能； c) 能够生成、维护及保护审计过程，使其免遭修改、 非法访问及破坏，特别要保护审计数据，要严格限制 未经授权的用户访问； d) 能够创建并维护一个对受保护客体访问的审计 跟踪，保护审计记录不被未授权的访问、修改和破坏； e) 指出可记录的审计事件的最少类型，包括建立会 话登录成功和失败，使用的系统接口，系统数据库管 理的改变（改变用户账户属性、审计跟踪设置和分析、 为程序分配设置用户 ID、附加或改变系统程序或进 程、改变日期和时间等），超级用户命令改变用户身份、 将某个客体引入某个用户的地址空间（如打开文件）、 删除客体及计算机操作员、系统管理员与系统安全管 理员进程的操作等。当审计激活时应确保审计跟踪事 件的完整性；应提供一个机制来显示当前选择的审计 事件，这个机制的使用者应是有限的授权用户； f) 每个事件的数据记录，应包括的信息有：事件发生 的日期和时间、触发事件的用户、事件的类型、事件 成功或失败等。对于身份标识和鉴别事件，应记录请 求的源（如末端号或网络地址）；对于创建和删除客体 的事件，应记录客体的名字和客体的安全属性； g) 应提供一个受保护的打开和关闭审计的机制。该 机制能选择和改变审计事件，并在系统工作时处于默 认状态；该机制的使用应受到系统管理员的授权限制， 系统管理员应能够选择一个或多个基于身份鉴别或客 体属性的用户的审计活动；审计工具应能够授权个人 监察和浏览审计数据，同时数据应得到授权的使用、 修改和删除；应提供对审计跟踪管理功能的保护，使 之可以完成审计跟踪的创建、破坏、腾空和存档；系 统管理员应能够定义超过审计跟踪极限的阈值；当存 储空间被耗尽时，应能按管理员的指定决定采取的措 施，包括：报警并丢弃未记录的审计信息、暂停审计、 覆盖以前的审计记录等。 a) 应为操作系统 SSOOS 安全功能控制范围内的 主体和客体设置完整性标签（IL），并建立完整性保护 策略模型，保护用户数据在存储、传输和处理过程中 的完整性； b) 在对数据进行访问操作时，检查存储在存储介质
    上的用户数据是否出现完整性错误，并在检测到完整 性错误时进行恢复。可通过密码支持系统所提供的完 整性功能，对加密存储的数据进行完整性保护。操作 系统对磁盘设备中存储的数据，可通过增加磁盘扫描 程序实现以下功能： ——自动检查文件与磁盘表面是否完好； ——将磁盘表面的问题自动记录下来； ——随时检查、诊断和修复磁盘上的错误； ——修复扇区交错和扇区流失； ——将数据移到好的扇区； ——可增加硬盘数据备份和修复程序，将硬盘中的数 据压缩、备份，并在必要时恢复； c) 在操作系统内部传输的用户数据，如进程间的通 信，应提供保证用户数据完整性的功能。完 整性标签应随数据一起流动，系统应保证低完整性的 数据不能插入、覆盖到高完整性的数据； d) 对操作系统中处理的数据，应按回退的要求设计 相应的 SSOOS 安全功能模块，进行异常情况 的操作序列回退，以确保用户数据的完整性。系统应 保证在处理过程中不降低数据完整性的级别。 a) 应确保动态分配与管理的资源，在保持信息安全 的情况下被再利用，主要包括： ——确保非授权用户不能查找使用后返还系统的记录 介质中的信息内容； ——确保非授权用户不能查找系统现已分配给他的记 录介质中以前的信息内容； b) 在单用户系统中，存储器保护应防止用户进程影 响系统的运行； c) 在多用户系统中，存储器保护应保证系统内各个 用户之间互不干扰； d) 存储器保护应包括: ——对存储单元的地址的保护，使非法用户不能访问 那些受到保护的存储单元； ——对被保护的存储单元的操作提供各种类型的保 护，最基本的保护类型是“读/写”和“只 读”，不能读/写的存储单元，若被用户读/写时，系统 应及时发出警报或中断程序执行； ——可采用逻辑隔离的方法进行存储器保护，具体有： 界限地址寄存器保护法、内存标志法、 锁保护法和特征位保护法等。 一般应按 GB/T 20271-2006 中 6.3.4.1 的要求，实 现 SSF 的物理安全保护，通过对物理攻击的检查 和自动报告，及时发现以物理方式的攻击对 SSF 造成 的威胁和破坏。 用 户 数 据 保 密 性 SSOOS 自 身 安 全 保护 SSF 物 理 安 全 保 护
    SSF 运 行 安 全 保 护 a) 系统在设计时不应留有“后门”。即不应以维护、 支持或操作需要为借口，设计有违反或绕过安全规则 的任何类型的入口和文档中未说明的任何模式的入 口； b) 安全结构应是一个独立的、严格定义的系统软件 的一个子集，并应防止外部干扰和破坏，如修改其代 码或数据结构； c) 操作系统程序与用户程序要进行隔离。一个进程 的虚地址空间至少应被分为两个段：用户空间和系统 空间，两者的隔离应是静态的。驻留在内存中的操作 系统应由所有进程共享。用户进程之间应是彼此隔离 的。应禁止在用户模式下运行的进程对系统段进行写 操作，而在系统模式下运行时，应允许进程对所有的 虚存空间进行读、写操作； d) 提供设置和升级配置参数的安装机制。在初始化 和对与安全有关的数据结构进行保护之前， 应对用户和管理员的安全策略属性应进行定义； e) 应区分普通操作模式和系统维护模式； f) 应防止一个普通用户从未经允许的系统进入维 护模式，并应防止一个普通用户与系统内维护 模式交互。从而保证在普通用户访问系统之前，系统 能以一个安全的方式进行安装和配置； g) 对备份或不影响 SSOOS 的常规的系统维护，不 要求所有的系统维护都在维护模式中执行； h) 当操作系统安装完成后，在普通用户访问之前， 系统应配置好初始用户和管理员职责、根目 录、审计参数、系统审计跟踪设置以及对文件和目录 的合适的访问控制； i) 执行系统所提供的实用程序，应（默认地）限定 于对系统的有效使用，只允许系统管理员修 改或替换系统提供的实用程序； j) 操作环境应为用户提供一个机制，来控制命令的 目录/路径的查找顺序； k) 提供一个实用程序来校验文件系统和磁盘的完 整性。此实用程序应由操作系统自动执行； l) 为操作系统安全管理人员提供一种机制，来产生 安全参数值的详细报告； m) 在 SSOOS 失败或中断后，应确保其以最小的 损害得到恢复。并按失败保护中所描述的内容， 实现对 SSF 出现失败时的处理。系统因故障或其它 原因中断后，应有一种机制去恢复系统。 系统应提供在管理维护状态中运行的能力，管理维护 状态只能被系统管理员使用，各种安全 功能全部失效；
    n) 操作系统环境应控制和审计系统控制台的使用 情况； o) 补丁的发布、管理和使用：补丁是对操作系统安 全漏洞进行修补的程序的总称。操作系统的 开发者应针对发现的漏洞及时发布补丁。操作系统的 管理者应及时获取、统一管理并及时运 用补丁对操作系统的漏洞进行修补。 a) 实现对输出 SSF 数据可用性、保密性、和完整 性保护； b) 实现 SSOOS 内 SSF 数据传输的基本保护、数据 分离传输、数据完整性保护； c) 实现 SSF 间的 SSF 数据的一致性和 SSOOS 内 SSF 数据复制的一致性保护。 a） 应通过一定措施确保当系统出现某些确定的故障 情况时，SSF 也能维持正常运行，如系统应 检测和报告系统的服务水平已降低到预先规定的最小 值； b） 应采取适当的策略，有限服务优先级提供主体使 用 TSC 内某个资源子集的优先级，进行 SSOOS 资源的管理和分配； c）应按资源分配中最大限额的要求，进行 SSOOS 资 源的管理和分配，要求配额机制确保用户和主体将不 会独占某种受控的资源； d） 系统应确保在被授权的主体发出请求时，资源能 被访问和利用； e） 当系统资源的服务水平降低到预先规定的最小值 时，应能检测和发出报告； f） 系统应提供维护状态中运行的能力，在维护状态 下各种安全性能全部失效，系统只允许由系统管理员 使用； g） 系统应以每个用户或每个用户组为基础，提供一 种机制，控制他们对磁盘的消耗和对 CPU 的使用； h） 系统应提供软件及数据备份和复原的过程，在系 统中应加入再启动的同步点，以便于系统的复原； i） 操作系统应能提供用户可访问的系统资源的修改 历史记录； j） 系统应提供能用于定期确认系统正确操作的机制 和过程，这些机制或过程应涉及系统资源的监督、硬 件和固件单元的正确操作、对可能在全系统内传播的 错误状态的检测以及超过用户规定的门限的通讯差错 的检测等内容。 a) 按会话建立机制的要求，对会话建立的管理进行 设计。在建立 SSOOS 会话之前，应鉴别用户的身份。 SSF 数 据 安 全 保护 资 源 利用 SSOOS 访 问
    控制 登录机制不允许鉴别机制本身被旁路； b) 按多重并发会话限定中基本限定的要求，进行会 话管理的设计。在基于基本标识的基础上，SSF 应限 制系统的并发会话的最大数量，并应利用默认值作为 会话次数的限定数； c) 按可选属性范围限定的要求，选择某种会话安全 属性的所有失败的尝试 ，对用来建立会话的安全属性 的范围进行限制； d) 成功登录系统后，SSOOS 应记录并向用户显示 以下数据： ——日期、时间、来源和上次成功登录系统的情况； ——上次成功访问系统以来身份鉴别失败的情况； ——应显示口令到期的天数； ——成功或不成功的事件次数的显示可以用整数计 数、时间戳列表等表述方法； e) 在规定的未使用时限后，系统应断开会话或重新 鉴别用户，系统应提供时限的默认值； f) 系统应提供锁定用户键盘的机制，键盘开锁过程 应要求验证用户； g) 当用户鉴别过程不正确的次数达到系统规定的 次数时，系统应退出登录过程并终止与用户的交互； h) 系统应提供一种机制，能按时间、进入方式、地 点、网络地址或端口等条件规定哪些用户能进入系统。 g) 当用户鉴别过程不正确的次数达到系统规定的 次数时，系统应退出登录过程并终止与用户的交互； h) 系统应提供一种机制，能按时间、进入方式、地 点、网络地址或端口等条件规定哪些用户能进入系统。 a) 在配置管理能力方面应实现对版本号、配置项、 授权控制等方面的要求； b) 在配置管理自动化方面要求部分的配置管理自 动化； c) 在 SSOOS 的配置管理范围方面，应将 SSOOS 的实现表示、设计文档、测试文档、用户文档、管理 员文档以及配置管理文档等置于配置管理之下，要求 实现对配置管理范围内的问题跟踪，特别是安全缺陷 问题进行跟踪； d) 在系统的整个生存期，即在它的开发、测试和维 护期间，应有一个软件配置管理系统处于保持对改变 源码和文件的控制状态。只有被授权的代码和代码修 改才允许被加进已交付的源码的基本部分。所有改变 应被记载和检查，以确保未危及系统的安全。在软件 配置管理系统中，应包含从源码产生出系统新版本、 鉴定新生成的系统版本和保护源码免遭未授权修改的 工具 配 置 管理 SSOOS 设 计 和 实 现
    分 发 和 操 作 和规程。通过技术、物理和保安规章三方面的结合， 可充分保护生成系统所用到的源码免遭 未授权的修改和毁坏。 a) 以文档形式提供对 SSOOS 安全地进行分发的 过程，并对修改检测的过程进行说明，最终生成安全 的配置。文档中所描述的内容应包括： ——提供分发的过程； ——安全启动和操作的过程； ——建立日志的过程； ——修改内容的检测； ——对任何安全加强功能在启动、正常操作维护时能 被撤消或修改的阐述； ——在故障或硬件、软件出错后恢复系统至安全状态 的规程； ——对含有加强安全性的硬件部件，应说明用户或自 动的诊断测试的操作环境和使用方法； ——所有诊断测试过程中，为加强安全性的硬件部件 所提供例证的结果； ——在启动和操作时产生审计踪迹输出的例证； b) 对系统的未授权修改的风险，应在交付时控制到 最低限度。在包装及安全分送和安装过程中，这种控 制应采取软件控制系统的方式，确认安全性会由最终 用户考虑，所有安全机制都应以功能状态交付； c) 所有软件应提供安全安装默认值，在客户不做选 择时，默认值应使安全机制有效地发挥安全功能； d) 随同系统交付的全部默认用户标识码，应在交付 时处于非激活状态，并在使用前由管理员激活； e) 用户文档应同交付的软件一起包装，并应有一套 规程确保当前送给用户的系统软件是严格按最新的系 统版本来制作的； f) 以安全方式开发并交付系统后，仍应提供对产品 的长期维护和评估的支持，包括产品中的安全漏洞和 现场问题的解决； g) 应采用书面说明的方式向客户通告新的安全问 题。 h) 对可能受到威胁的所有的安全问题，均应描述其 特点，并作为主要的问题对待，直到它被解决或在用 户同意下降级使用； i) 为了支持已交付的软件的每个版本，对所有已有 的安全漏洞都应有文档书面说明，并且用户能在限制 的基础上得到该文档； j) 对安全漏洞的修改不必等到系统升级到下一个版 本。安全功能的增加和改进应独立于系统版本的升级， 也就是说，应存在适应性独立于系统其它功能的改进；
    分享到：
    赞 收藏

    相关推荐

    资料库

    安全技术

    共收录1285份资料，累计4个分类，关注成员有19位，主要包括：网络攻防,系统安全,其它,网络安全

    热门标签

    网络攻防 系统安全 其它 网络安全

    最新资料