点赞

开源软件安全使用规范-v1.1

发布时间: 2021-09-13

25
4938

ICS 35.240.01 L70

团 体 标 准

T/CFAS 0001-2019

 

信息安全技术

开源软件安全使用规范


 

Information Security Technology: The UsingSpecifications of Open Source Software Security

 

 

 

 

 

北京长风信息技术产业联盟   发布

 

前     言

 

       软件不安全因素主要来源于软件自身存在的错误和缺陷引起的安全漏洞,以及通过安全    漏洞进行的各种攻击。通过开源软件漏洞检测和监测技术,减少软件的安全漏洞,从而有效    的抵御攻击。

       本规范主要规范了开源软件在使用上的各种安全规范,将在不同阶段中所需要注意的安    全问题和相关安全规范进行进一步的描述和规定,以提高开源软件的安全性和抵御攻击的能    力。

 

       本标准的实施应遵循配套国家标准的具体规定。 本标准由北京长风信息技术产业联盟提出并归口。

       本标准起草单位: 北京长风信息技术产业联盟、中国科学院软件研究所、中科软智(北京)科技有限公司、北京中科微澜科技有限公司、北京合睿科技有限公司。

       本标准起草人:吴敬征、郭维、杨牧天、罗天悦、刘梅、倪琛、吴亚丽、武延军、孙启。

 

引  言

0.1 概述

开源软件安全使用规范是指从开源软件使用角度出发,标准化使用流程步骤,规范化软件维护方法,通过应用有效的手段或工具提高开源软件使用过程中的信息安全性,降低    由于不良的软件使用习惯或触发安全漏洞所产生的信息安全风险,因此,开源软件安全    使用规范提供了一种针对开源软件使用上产生的信息安全问题,从而对其进行高效的安    全管控的方式和方法。

0.2 本文的作用

开源软件安全使用规范包括的标准:

a)    定义对开源软件安全使用规范及涉及此规范的行业内要求;

b)    为建立、实施、维护和改进开源软件安全使用规范的整个过程提供直接支持、详细指    南和/或解释;

c)     针对特定行业提出开源软件安全使用规范指南;

d)     阐述开源软件安全使用规范的合格评定方法。

0.3本文内容

在本文件中,使用下列动词形式:

——“应当(shall表示要求;

——“应该(should表示推荐;

——“可以(may表示许可;

——“能(can表示可能性或能力。

标记为注释的信息用于理解或澄清相关指导要求。第 3 条中使用的条目注释提供了补充术语数据的附加信息,并且包含使用有关术语的条款。

 

信息安全技术

开源软件安全使用规范

 

1          范围

        本标准规定了开源软件安全使用上的标准化流程规范。

本标准适用于软件在开源软件安全使用过程中涉及到的信息安全相关操作流程,规范化    和标准化开源软件安全使用的完整流程体系,用于有效评估和验证软件在开源软件安全使用    过程中是否得当,是否符合开源软件安全使用规范标准。

本标准主要针对开源软件安全使用以及管理过程进行标准化规定,因此本标准不适用于    病毒检测等非开源软件安全使用规范类标准化工作的开展。

本标准适用于软件相关的信息产品生产、技术研发、系统运营等组织、机构在相关工作    中参考。

2          规范性引用文件

下列文件对本文件的应用是必不可少的,凡是注日期的引用文件,仅注日期的版本适用    于本文件。凡是不注日期的引用文件,其最新版本(包括所有修改单)适用于本文件。

GB/T 25069-2010  信息安全技术   术语

ISO/IEC 27000-2018 信息安全技术 信息安全管理体系 概述和术语

 

 

3          术语和定义

(可能包括缩略语)

3.1  访问控制 access control

作为进行授权和限制的手段,确保对于资产的访问是基于业务和安全要求(3.56)。

3.2  攻击 attack

企图破坏、泄露、篡改、损伤、窃取、未授权访问或未授权使用资产的行为。

3.3  审核 audit

获取审核证据并客观地对其评价的过程,以确定满足过程化(3.54)、系统化、独立化   和文件化的审核准则。

注1:审核可以是内部审核(第一方)或外部审核(第二方或第三方),可以是结合审核(结合两个或两个以上学科)。

注 2:内审核是由组织自己,或由外部以组织的名义进行的。

注 3:审核证据审核准则在 ISO 19011|GB/T 19011 中被定义。

3.4  审核范围 audit scope

审核(3.3)的程度和边界。

[资料来源:ISO19011:2011,定义 3.14,修改:删除注 1]

3.5  鉴别 authentication

为确保一个实体声称的特征是正确的而提供的保障措施。

3.6  真实性 authenticity

一个实体是其所声称实体的特性。

3.7  可用性 availability

根据授权实体的要求可访问和可使用的特性。

3.8  基本测度 base measure

用某个属性及其量化方法定义的测度(3.42)。注 1:基本测度在功能上独立于其他测度。

[资料来源:ISO/IEC15939:2017,定义 3.3,修改:删除注 2]

3.9  能力 competence

应用知识和技能实现预期结果的才能。

3.10 保密性 confidentiality

信息不能对未授权的个人、实体或过程(3.54)可用或泄露的特性。

3.11 符合性 conformity

对要求(3.56)的满足。

3.12 后果 consequence

事态(3.21)影响目标(3.49)的结果。

注 1:一个事态(2.25)可能导致一系列后果。

注   2:后果可以是确定的或不确定的,并且在信息安全(2.33)的语境下通常是负面的。注 3:后果可以被定性或定量地表示。

注 4:初始后果可能通过连锁效应升级。

[资料来源:ISO Guide 73:2009,定义 3.6.1.3,注释 2 在并且之后被更改。]

3.13 持续改进 continual improvement 反复提高性能(3.52)的活动。

3.14控制 control

规避风险(3.61)的措施。

注  1:控制包括任何规避风险(3.61)的过程(3.54)、方针(3.53)、设备、实践或其他措施。

注 2:控制可能不一定总是达到预期或假定的风险规避效果。[资料来源:ISO Guide 73:2009,定义3.8.1.1——注 2 有改变]

3.15控制目标 control objective

描述控制(3.14)的实施结果所要达到目标的声明。

3.16 纠正 correction

消除已查明的不合格(3.47)的措施。

3.17 整改措施 corrective action

消除不合格(3.47)成因以防再次发生的措施。

3.18 导出测度 derivedmeasure

定义为两个或两个以上基本测度(3.8)值的函数的测度(3.42)。    [资料来源:ISO/IEC 15939:2017,定义 3.8,修改:删除注1]

3.19成文信息 documented information

组织(3.50)需要控制和保持的信息及其载体。

注 1:成文信息可以以任何格式,在任何载体中,来自任何来源。注 2:成文信息可能涉及

——管理体系(3.41),包括相关过程(3.54);

——为组织(3.50)运行所创建的信息(文件);

——结果实现的证据(记录)。

3.20 有效性 effectiveness

实现所计划活动和达成所计划结果的程度。

3.21 事态 event

发生或改变一组特定情形。

注 1:一个事态可能是一个或多个情形,并可能有多种原因。注 2:一个事态可能有一些未发生的事情组成。

注 3:一个事态可能有时被称为事件事故

[资料来源:ISO Guide 73:2009,定义 3.5.1.3,修改:删除注 4]

3.22 外部语境 external context

组织寻求实现其目标(3.49)的外部环境。注 1:外部语境可以包括如下方面:

——无论是国际的、国家的、地区的或地方的文化、社会、政治、法律、法规、金融、    技术、经济、自然和竞争环境;

——影响组织(3.50)目标的关键驱动力和趋势;

——与外部利益相关方(3.37)的关系及其认知和价值观。    [资料来源:ISO Guide 73:2009,定义3.3.1.1]

3.23信息安全治理 governance of information security

指导和控制组织(3.50)信息安全(3.28)活动的体系。

3.24 治理者 governing body

对组织(3.50)的性能(3.52)和合规负有责任的人或一组人。 1:治理者在某些司法管辖区可以是董事会。

3.25指标 indicator

提供估算或评价的测度(3.42)。

3.26 信息需求 information need

对目标(3.49)、目的、风险和问题进行管理所必需的洞察能力。    [资料来源:ISO/IEC 15939:2017,定义 3.12]

3.27信息处理设施 information processing facilities

任何的信息处理系统、服务或基础设施,或者其安置的物理位置。

3.28 信息安全 information security

对信息的保密性(3.10)、完整性(3.36)和可用性(3.7)进行保护。

注 1:另外,也可包括诸如真实性(3.6)、可核查性、抗抵赖(3.48)和可靠性(3.55) 等其他特性。

3.29信息安全持续性 information securitycontinuity

确保信息安全(3.28)持续作用的过程(3.54)和规程。

3.30 信息安全事态information securityevent

识别到的一种系统、服务或网络状态的确定情况,表明可能违反信息安全(3.28)方针

(3.53)或控制(3.14)失效,或者一种可能与信息安全相关但还不为人知的情况。

3.31 信息安全事件information securityincident

单一或一系列不希望发生或意外发生的,极有可能损害业务运行和威胁信息安全(3.28)  的信息安全事态(3.30)。

3.32信息安全事件管理

信息安全事件管理 information security incidentmanagement

发现、报告、评估、响应、处理和总结信息安全事件(3.31)的过程(3.54)。

3.33 信息安全管理系统

信息安全管理系统( ISMS )专业人员 information security management system (ISMS) professional

建立、实施、维护并持续改进一个或多个信息安全管理系统过程(3.54)的人员。

3.34 信息共享社区 informationsharing community 同意共享信息的组织(3.50)群体。

注 1:组织(3.57)可以是一个人。

3.35 信息系统 information system

应用、服务、信息技术资产或其他信息处理组件的集合。

3.36 完整性 integrity

准确和完备的特性。

3.37 利益相关方

利益相关方 interested party(首选术语);stakeholder(许用术语)

对于一项决策或活动,可能对其产生影响,或被其影响,或认为自己受到其影响的个人    或组织(3.50)。

3.38内部语境 internal context

组织(3.50)寻求实现其目标的内部环境。注 1:内部语境可以包括如下方面:

——治理、组织结构、角色和职责;

——方针(3.53)、目标(3.49)和需要实现它们的战略;

——在资源和知识方面的能力(如资本、时间、人员、过程(3.54)、系统和技术);

——信息系统(3.35)、信息流和决策过程(正式的和非正式的);

——与内部利益相关方(3.37)的关系及其认知和价值观;

——组织的文化;

——组织采用的标准、指南和模型;

——契约关系的形式和程度。

[资料来源:ISO Guide 73:2009,定义 3.3.1.2]

3.39 风险程度 level of risk

以后果(3.12)和其可能性(3.40)的组合来表示的风险(3.61)大小。[ISOGuide 73:2009,定义 3.6.1.8,修改:删除定义中的或风险组合]

3.40可能性likelihood

某事发生的机会。

[ISO Guide 73:2009,定义 3.6.1.1,修改:删除注 1 和注 2]

3.41 管理体系 management system

组织(3.50)中相互关联或相互作用的要素集,用来建立方针(3.53)和目标(3.49) 以及达到这些目标的过程(3.54)。

注 1:一个管理体系可能专注于单一学科或多个学科。

注 2:体系要素包括组织结构、角色和责任、规划、运行。

注3:一个管理体系范围可能包括组织的整体、组织的特定且确定的功能、组织的特定且确定的部门,或者跨组组织的一个或多个功能。

3.42测度 measure

作为测量(3.43)结果赋值的变量。

[资料来源:ISO/IEC15939:2017,定义 3.15,修改:删除注 2]

3.43 测量 measurement

确定一个值的过程(3.54)。

3.44 测量函数 measurement function

组合两个或两个以上基本测度(3.8)的算法或计算。

[资料来源:ISO/IEC15939:2017,定义 3.20]

3.45 测量方法 measurement method

用于按指定的尺度量化属性的通用逻辑操作序列。

注 1:测量方法的类型取决于量化属性(3.4)操作的性质。可区分为两种类型:

——主观的:包含人为判断的量化;

——客观的:基于数字规则的量化。

[资料来源:ISO/IEC15939:2017,定义 3.22,修改:删除注 2]

3.46 监视 monitoring

确定系统、过程(3.54)或活动状态的行为。

注 1:为确定状态可能需要检查、监督或严密观察。

3.47 不合格 nonconformity 不满足要求(3.56)。

3.48抗抵赖 non-repudiation

证明所声称事态(3.21)或行为的发生及其起源实体的能力。

3.49 目 标objective 要实现的结果。

注 1:目标可以是战略性的、战术性的或操作性的。

注2:目标可以涉及不同学科(诸如金融、健康与安全以及环境目标),可以适用于不同层次(诸如战略、组织、项目、产品和过程(3.54))。

3:目标可以以其他方式表示,例如,作为预期结果、意图、操作准则,作为信息安全目标,或者使用具有类似含义的其他词(例如,目的或标靶)。

4:在信息安全管理体系的语境下,组织制定与信息安全策略一致的信息安全目标以实现特定的结果。

3.50组织 organization

具有自身的功能、责任、权威和关系来实现其目标(3.49)的人或一组人。

1:组织的概念包括但不限于个体经营者、公司、法人、商行、企业、机关、合伙关系、慈善机构或院校,或部分或其组合,不论注册与否,公共的还是私营的。

3.51外包 outsource

安排外部组织(3.50)执行部分的组织功能或过程(3.54)。

注 1:外部组织在管理体系(3.41)的范围之外,尽管外包的功能或过程在范围之内。

3.52 性 能 performance 可测量的结果。

注 1:性能可以涉及定量或定性的调查结果。

注 2:性能可涉及活动、过程(3.54)、产品(包括服务)、系统或组织(3.50)的管

理。

3.53 方针 policy

由最高管理者(3.75)正式表达的组织(3.50)的意图和方向。

3.54 过程 process

将输入转换成输出的相互关联或相关作用的活动集。

3.55 可靠性 reliability

与预期行为和结果一致的特性。

3.56 要求 requirement

明示的、通常隐含的或强制性的需要或期望。

注 1:通常隐含意指组织或利益相关方的惯例或常见做法,所考虑的需要或期望是不

言而喻的。

注 2:指定要求是明示的,例如在成文信息中。

3.57 残余风险 residual risk

风险处置(3.72)后余下的风险(3.61)。1:残余风险可能包含未识别的风险。注 2:残余风险也可以被称为保留风险

3.58评审 review

针对实现所设立目标(3.49)的主题,为确定其适宜性、充分性和有效性(3.20)而采   取的活动。

[资料来源:ISO Guide 73:2009,定义 3.8.2.2,修改:删除注 1]

3.59 评审对象 review object被评审的特定事项。

3.60评审目标 review objective

描述评审(3.59)结果要达到什么的陈述。

3.61 风险 risk

对目标(3.49)的不确定性影响。

注 1:影响是指与期望的偏离(正面的或负面的)。

注2:不确定性是对事态及其结果或可能性的相关信息、理解或知识缺乏的状态(即使是部分的)。

注 3:风险常被表征为潜在的事态(如ISO guide 73:2009,3.5.1.3 定义的)和后果(如ISOguide 73:2009,3.6.1.3 定义的),或者它们的组合。

注 4:风险常被表示为事态的后果(包括情形的改变)和其发生可能性(如ISO guide 73:2009,3.6.1.1 定义的)的组合。

5:在信息安全管理体系的语境下,信息安全风险可被表示为对信息安全目标的不确定性影响。

6:信息安全风险与威胁利用信息资产或信息资产组的脆弱性对组织造成危害的潜力相关。

3.62风险接受 riskacceptance

接纳特定风险(3.61)的有根据的决定。

注  1:可不经风险处置(3.72)或在风险处置的过程(3.54)中做出风险接受。注 2:接受的风险(2.68)要受到监视(3.46)和评审(3.58)。

[资料来源:ISO Guide 73:2009,定义 3.7.1.6]

3.63 风险分析 risk analysis

理解风险(3.61)本质和确定风险等级(3.39)的过程(3.54)。

注 1:风险分析提供风险评价(3.67)和风险处置(3.72)决策的基础。注 2:风险分析包括风险估算。

[资料来源:ISO Guide 73:2009,定义 3.6.1]

3.64 风险评估 risk assessment

风险识别(3.68)、风险分析(3.63)和风险评价(3.67)的整个过程(3.54)。   [资料来源:ISO Guide 73:2009,定义3.4.1]

3.65风险沟通与咨询 riskcommunication and consultation

组织就风险(3.61)管理所进行的,提供、共享或获取信息以及与利益相关方(3.37)   进行对话的一组持续和迭代的过程(3.54)。

1:这些信息可能涉及到风险的存在、性质、形式、可能性(3.41)、重要性、评价、

可接受性和处置。

注    2:咨询是对问题进行决策或确定方向之前,在组织(3.50)和其利益相关方之间进行知情沟通的双向过程。咨询是

——通过影响而不是权力来影响决策的过程;

——决策的输入而非联合决策。

3.66 风险准则 risk criteria

评价风险(3.61)重要性的参照条款。

注   1:风险准则是基于组织的目标以及外部语境(3.22)和内部语境(3.38)。注 2:风险准则可来自标准、法律、方针(3.53)和其他要求(3.56)中。

[资料来源:SOURCE: ISO Guide 73:2009, 3.3.1.3]

3.67 风险评价 risk evaluation

将风险分析(3.63)的结果与风险准则(3.66)比较以确定风险(3.61)和/或其大小是  否可接受或可容忍的过程(3.54)。

注  1:风险评价有助于风险处置(3.72)决策。[资料来源:ISOGuide 73:2009,定义 3.7.1]

3.68风险识别 risk identification

发现、识别和描述风险(3.61)的过程(3.54)。

注 1:风险识别涉及风险源、事态(3.21)及其原因和潜在后果(3.12)的识别。

注 2:风险识别可能涉及历史数据、理论分析、知情者和专家的意见以及利益相关方

(3.37)的需要。

[资料来源:ISO Guide 73:2009,定义 3.5.1]

3.69 风险管理 risk management

指导和控制组织(3.50)相关风险(3.61)的协调活动。   [资料来源:ISO Guide 73:2009,定义2.1]

3.70风险管理过程 riskmanagement process

管理方针(3.53)、规程和实践在沟通、咨询、语境建立以及识别、分析、评价、处置、   监视和评审风险(3.61)活动上的系统性应用。

注 1:ISO/IEC 27005|GB/T31722 使用术语过程(3.54)来描述全面风险管理。在风险管理(3.69)过程中的要素被称为活动

[资料来源:ISO Guide 73:2009,定义 3.1,修改:增加注 1]

3.71 风险责任者 riskowner

具有责任和权威来管理风险(3.61)的人或实体。  [资料来源:ISO Guide73:2009,定义 3.5.1.5]

3.72风险处置 risk treatment

改变风险(3.61)的过程(3.54)。注 1:风险处置可能涉及如下方面:

——通过决定不启动或不继续进行产生风险的活动来规避风险;

——承担或增加风险以追求机会;

——消除风险源;

——改变可能性(3.40);

——改变后果(3.12);

——与另外一方或多方共担风险(包括合同和风险融资);

——通过有根据的选择保留风险。

注 2:处理负面后果的风险处置有时被称为风险缓解风险消除风险防范

险降低

注 3:风险处置可能产生新的风险或改变现有风险。

[资料来源:ISOGuide 73:2009,定义 3.8.1,修改:将注 1 中的决策替换为选择]

3.73 安全实现标准 security implementationstandard 为实现安全而规定授权方式的文件。

3.74威胁 threat

可能对系统或组织(3.50)造成危害的不期望事件的潜在原由。

3.75 最高管理者 top management

在最高层指导和控制组织(3.50)的人或一组人。

注 1:最高管理者具有在组织内授权和提供资源的权力。

注    2:如果管理体系(3.41)的范围只涵盖组织的一部分,则最高管理者就是指指导和控制组织这部分的人或一组人。

3:最高管理者有时被称为执行管理,可以包括首席执行官、首席财务官、首席信息官以及类似的角色。

3.76可信信息通信实体 trusted information communication entity

支持在信息共享社区(3.34)内进行信息交换的自主组织(3.50)。

3.77 安全漏洞 vulnerability

可能被一个或多个威胁(3.74)利用的资产或控制措施(3.14)的弱点。计算机信息系   统在需求、设计、实现、配置、运行等过程中,有意或无意产生的缺陷。这些缺陷以不同形     式存在于计算机信息系统的各个层次和环节中,一旦被恶意主体所利用,就会对计算机信息    系统的安全造成损害,从而影响计算机信息系统的正常运行。

3.78       漏洞管理 vulnerability management

漏洞管理是建立、实施、运行、监视、评审、维护和改进组织漏洞安全来实现业务目标的系统方法。它是基于漏洞风险评估和组织的漏洞风险接受程度,为有效地处置和管理漏洞风险来设计的。分析信息资产保护要求,并按要求应用适当的控制措施确保这些信息资产,    有助于漏洞管理的成功实施。

3.79       漏洞库 vulnerability database

漏洞库是为了更好的进行信息安全漏洞的管理及控制工作而建立的一项漏洞安全信息    数据库。

 

 

4          信息安全开源软件安全使用规范标准

4.1 概要

造成软件在使用过程中出现安全问题的主要原因来源于软件的使用不当或不良的使用    习惯,从而触发软件缺陷引起的安全漏洞问题,导致不法分子通过利用安全漏洞实施的各种    攻击。

本标准主要规范了使用开源软件过程中,开源软件安全使用规范的各个实施办法和流程    的标准化规范,将在不同阶段中所需要注意的安全问题和相关安全规范进行进一步的描述和    规定,规范化软件开源软件安全使用的流程步骤,以提高软件使用过程中的信息安全性,达到有效管控软件开源软件漏洞和安全风险的目的。

通过开源软件安全使用规范化和安全漏洞监测管理技术,全方位的排查和管理开源软件    的信息安全问题,辅助性的提供解决方案,降低软件在使用不当或不良使用习惯的影响下所     产生的安全漏洞问题,从而有效的抵御攻击。还可以通过对开源软件安全漏洞的管理,进一    步预警和预测漏洞可能带来的安全问题,增强风险的可控性。

 

4.2  开源软件安全使用规范综述

4.2.1   概述和原则

开源软件安全使用规范主要在于以规范标准的操作流程为标准化手段,规范化标准化开    源软件使用流程和操作步骤。目的在于保护开源软件信息资产的基础安全。基于开源软件漏     洞风险评估和组织对开源软件漏洞风险接受程度的指标,应用标准化设计手段,进行有效地     处置和管理软件操作步骤和安全漏洞风险。分析开源软件信息资产保护要求,并按要求应用     适当的控制措施确保这些开源软件信息资产的安全,有助于开源软件安全使用规范工作的成    功实施。下列基本原则也有助于开源软件安全使用规范工作的成功实施:

a)    意识到漏洞管理的重要;

b)     分配开源软件安全使用的责任;

c)     涵盖管理者的承诺和利益相关方的利益;

d)     提升社会价值;

e)     进行漏洞风险评估来确立适宜的控制手段,从而达到可接受的漏洞风险程度;

f)     将安全作为信息系统的基本要素;

g)     主动防范和发现漏洞安全事件;

h)     确保漏洞管理方法的全面性;

i)    持续对漏洞管理进行再评估,并在适当时进行修正。

 

4.2.2    开源软件安全使用流程规范

1)         开源软件在环境内安装前必须确认版本信息,确认是否来源于官方发布版本。对于    开源软件的获取及维护活动以及对遗留系统的变更都应该进行软件安全评估及计   划,并进行安全计划评审,以确保软件安全计划得到正确的执行。

2)         开源软件安全管理人员应在开源软件安全计划中记录软件安全计划编制信息,如果    该计划被记录在多个文档中,那么每个计划都应包含对相关的计划中的安全活动的    交叉引用。

3)         开源软件在环境内安装后,必须通过开源环境漏洞检测流程,对开源软件漏洞进行全面扫描,并得出结果报告。报告由相关安全管理人员进行审查后给出建议并归档。

4)         开源软件使用过程中,每一次版本变更,必须由开源环境漏洞进行监测,监测结果    生成报告。

5)         开源软件所安装、调试的系统环境必须长期处于开源环境漏洞监测工具的实施监控之下,私自卸载、改装、屏蔽等影响开源软件环境漏洞监测的行为均属于违规行为,    不符合规范的执行。

6)         开源软件使用前后检测或检测所产生的漏洞结果报告,必须由专人负责统计和管   理,由专业人员进行评估,并第一时间提交给有关部门的负责人。

7)         开源软件使用过程中,所产生的漏洞必须尽快根据漏洞结果报告的建议修复方式进    行漏洞的修复工作,负责人有义务监督并管理整个漏洞修复的实施过程。

8)         必须定期检查开源软件的运行状况、定期调阅软件运行日志记录,进行数据和软件    日志备份。将这些进行文档化保留。

9)         禁止在服务器上进行试验性质的软件调试,禁止在服务器随意安装软件。需要对服    务器进行配置,必须在其它可进行试验的机器上调试通过并确认可行后,才能对服    务器进行准确的配置。

10)       对会影响到全局的开源软件更改、调试等操作应先发布通知,并且应有充分的时间、    方案、人员准备,才能进行软件配置的更改。

11)       对开源软件配置的更改,应先形成方案文件,经过讨论确认可行后,由具备资格的    技术人员进行更改,并应做好详细的更改和操作记录。对软件的更改、升级、配置    等操作之前,应对更改、升级、配置所带来的负面后果做好充分的准备,必要时需    要先备份原有软件系统和落实好应急措施。

12)       不允许任何人员在服务器等核心设备上进行与工作范围无关的软件调试和操作。未    经允许,不允许带领、指示他人进入机房、对网络及软件环境进行更改和操作。

13)       开源软件应按照实际情况设置登陆策略,按安全策略要求具备防防范账户暴力破解    攻击措施的能力。

14)       应严格遵守张贴于相应位置的安全操作、警示以及安全指引。

 



展开
收起