一、概述
今天分享的是在中小型企业中如何将安全管理嵌入到产品开发的生命周期管理中,对于大型企业或者互联网企业而言,他们的IT部门比较成熟,拥有比较多的资源投入,实现起来相对容易,可以通过引入敏捷开发、DevOps等流程进行完善,并且可以通过专门的安全开发团队对开发人员进行赋能。然而对于中小型企业,特别是还在经历传统业务向数据化转型的企业而言,其信息科技年度投入都可能达不到整体成本投入5%的情况下,对于安全的投入更是微乎其微。在这个阶段,企业往往是同步进行安全基础设施的建设及安全开发的投入,且往往是基于安全合规需求的驱动。
安全开发需要投入的不仅仅是基础设施及工具,更是对开发团队、安全团队人员的能力提出了更高的要求。企业面临着上述问题的时候,如资源不够、人员不足、能力欠缺等等,去做安全开发还会延伸出其他的问题,如谁来提安全需求、谁来做安全设计评审、谁来做安全功能测试等等,此时又必须去做安全开发的事情,如何去做呢?我们把安全管理拆解到业务开发流程的各个不同的阶段中,通过IT项目管理将安全开发流程统一纳入到业务开发流程中去,如下图所示。
二、主要安全开发流程拆解
1、安全需求。为了更好的对需求进行管理,我们将安全需求又拆为通用安全需求及业务安全需求。通用安全需求由安全团队事先准备好,形成企业的一个规范,当项目立项以后,在业务需求阶段由项目经理及产品经理进行安全需求选择。业务安全需求由业务需求而定,一般在安全团队和团队了解了业务流程后,安全团队评估已选择的通用安全需求是否可以覆盖到业务流程,如果不能全部覆盖,则根据业务特性提出业务安全需求。
2、设计阶段。在这个阶段我们主要对需求进行评审,参照安全需求规范对通用安全需求进行评审,项目经理或者产品经理选择了哪些需求,为什么另外一些需求不选择,不选择这些安全需求的原因是什么,是否会影响业务系统的安全等。根据业务流程进行安全设计访问控制,对于关键的业务流程进行威胁建模,威胁建模主要依赖于微软的STRDE威胁建模工具。另外,本阶段的评审最好是与项目经理组织业务需求设计评审一起进行,安全人员不要自行组织,因为企业的安全重视程度不够的情况下很难组织得起来,即使组织起来了,整个评审也不会很顺利进行。
3、编码阶段。本阶段是开发人员将需要通过代码实现的过程,开发人员对于安全的理解程度通常较低,而我们对开发理解程度也很低,在这个阶段我们寻找了通用的安全编码规范,如OWASP安全编码规范快速参考指南,对开发人员进行安全编码培训提供代码的质量。
4、代码构建。在这里我们进行代码扫描,目前本阶段主要依赖外部供应商进行,我们也正在逐步构建代码扫描的自主能力,预计在后续我们将代码自动扫描功能集成到现有的Jenkins中去,由开发人员自行进行代码扫描,由信息安全管理人员进行监控。
5、测试阶段。通常测试主要包括SIT测试及UAT测试,均为业务功能测试,我们在这个阶段要求由SIT人员加入安全功能的测试,也即对前面的安全需求进行测试,测试用例由SIT人员编写,安全管理人员协助。安全功能需求测试用例相对固定,几乎不会有太大的变化。测试人员测试后,安全管理人员进行评审,如果认可本次对安全需求的测试结论,则安全管理人员签署测试报告。该过程通过IT项目管理进行约束,确保测试过程顺利进行。在本阶段我们通常还会组织人员对产品进行渗透测试,渗透测试过程不同于前面的安全功能测试,渗透测试主要模拟黑客对产品安全保障测试。渗透测试发现的中高风险问题必须进行修复后,产品才可以上线。
6、部署上线。在产品上线前,视产品或者系统规模的大小,我们会组织人员或者安全服务厂商对产品或者系统进行投产测评工作。此时的投产测评工作会比前期进行的渗透测试范围更大,主要是对即将投产的系统的生产环境,包括应用、系统、中间件、网络环境等进行风险评估及整改。
三、安全开发需求规范举例
(一)、 总则
本规范的制定参考《JRT 0185-2020 商业银行应用程序接口安全管理规范》《个人金融信息保护技术规范》《GBT 38674-2020 信息安全技术 应用软件安全编程指南》《JRT 0197-2020 金融数据安全 数据安全分级指南》,规定了信息系统在需求阶段需要考虑的安全需求,并且以需求列表的方式进行展现。本规范中如有部分内容有对应具体实施细则的,则以细则为执行依据,否则以本办法为准。
(二)、 系统面向群体
在系统开发的需求阶段需求明确本系统所面向的人员群体,不同角色的人员在系统使用过程中应当具有不同的权限。
角色编号 | 群体角色 | 访问网络环境 | 说明 |
2.G1 | 运维管理人员 | 内网/VPN | 系统上线 |
2.G2 | 开发测试人员 | 内网/VPN | 修数、测试 |
2.G3 | 后管系统 | 内网/VPN | |
2.G4 | 管理员角色 | 内网/VPN | |
2.G5 | 审计角色 | 内网/VPN | |
2.G6 | 用户(对客) | 互联网 | |
(三)、 数据类型识别
1、在项目需求阶段,需要识别出来系统所处理的个人金融信息类别,可以参考下列的信息,根据实际情况进行选择。此规范数据类型参考《个人金融信息保护技术规范》。
需求编号 | C3类别信息主要为用户鉴别信息。该类信息一旦遭到未经授权的查看或未经授权的变更,会对个人金融信息主体的信息安全与财产安全造成严重危害,包括但不限于: |
|
3.C3.1 | C3 | 银行卡磁道数据(或芯片等效信息)、卡片验证码(CVN 和 CVN2)、卡片有效期、银行卡密码、网络支付交易密码; |
3.C3.2 | 账户(包括但不限于支付账号、证券账户、保险账户)登录密码、交易密码、查询密码; |
3.C3.3 | 用于用户鉴别的个人生物识别信息。 |
需求编号 | C2 类别信息主要为可识别特定个人金融信息主体身份与金融状况的个人金融信息,以及用于金融产品与服务的关键信息。该类信息一旦遭到未经授权的查看或未经授权的变更,会对个人金融信息主体的信息安全与财产安全造成一定危害, 包括但不限于: |
|
3.C2.1 | C2 | 支付账号及其等效信息,如支付账号、证件类识别标识与证件信息(身份证、护照等)、手机号码。 |
3.C2.2 | 账户(包括但不限于支付账号、证券账户、保险账户)登录的用户名。 |
3.C2.3 | 用户鉴别辅助信息,如动态口令、短信验证码、密码提示问题答案、动态声纹密码;若用户鉴别辅助信息与账号结合使用可直接完成用户鉴别,则属于C3类别信息。 |
3.C2.4 | 直接反映个人金融信息主体金融状况的信息,如个人财产信息(包括网络支付账号余额)、借贷信息。 |
3.C2.5 | 用于金融产品与服务的关键信息,如交易信息(如交易指令、交易流水、证券委托、保险理赔)等。 |
3.C2.6 | 用于履行了解你的客户(KYC)要求,以及按行业主管部门存证、保全等需要,在提供产品和服务过程中收集的个人金融信息主体照片、 音视频等影像信息。 |
3.C2.7 | 其他能够识别出特定主体的信息, 如家庭地址等。 |
需求编号 | C1 类别信息主要为机构内部的信息资产,主要指供金融业机构内部使用的个人金融信息。该类信息一旦遭到未经授权的查看或未经授权的变更,可能会对个人金融信息主体的信息安全与财产安全造成一定影响,包括但不限于: |
|
3.C1.1 | C1 | 账户开立时间、 开户机构; |
3.C1.2 | 基于账户信息产生的支付标记信息; |
3.C1.3 | C2 和 C3 类别信息中未包含的其他个人金融信息。 |
2、系统处理的数据类型除上述个人金融信息外,可能还涉及公司经营数据,管理员及操作员等的系统登陆鉴别数据,在需求阶段也需要进行识别,以确定其保护等级。
(四)、通用需求列表
通用需求使用R表示,下列为通用需求列表,在产品需求阶段可以从中选择合适的需求,并且在开发过程中现实这些需求。
编号 | 需求大项 | 小项 | 说明 |
4.1.R1 | 身份认证 | 用户身份鉴别 | 在系统的整个访问过程中均需求进行用户身份鉴别。 |
4.1.R2 | 唯一标识 | 用户身份信息与主体进行绑定。 |
4.1.R3 | 多重鉴别 | 系统使用多因素进行身份鉴别。 |
4.1.R4 | 鉴别失败处理 | 鉴别失败给出的提示信息应当避免导致攻击者进行猜测攻击。 |
4.1.R5 | 二次鉴别 | 对于合法用户登陆系统后,进行敏感操作时进行二次用户身份鉴别。 |
4.2.R1 | 帐户管理 | 注册 | 应当确保身份标识惟一,账户信息不能包含特殊数字。 |
4.2.R2 | 帐户锁定 | 对鉴别尝试的频繁进行限制,连续多次登陆失败强制锁定账户,但不能过于频繁锁定引起拒绝服务攻击。 |
4.2.R3 | 修改密码 | 账户具有默认密码时,强制要求进行密码修改; 密码修改需要进行二次认证,避免CSRF漏洞。 |
4.2.R4 | 验证码管理 | 验证码应当随机产生,验证码需要即时销毁。 |
4.3.R1 | 口令管理 | 口令复杂度 | 登录过程中,确保口令不可见; 使用强口令,口令要满足《XXX公司密码管理细则》。 |
4.3.R2 | 口令超期管理 | 口令设置过期时间,强制用户进行修改,在过期前进行提示。 |
4.3.R3 | 初始口令 | 对于默认的初始口令,强制用户初次登录时更改默认口令。 |
4.3.R4 | 口令存放 | 禁止明文存储口令; 使用不可逆的加密算法或单向HASH算法对口令进行加密存储; 在HASH散列过程中加入变量,确保HASH值难以猜测或者还原; 将加密后的口令存储在配置文件中、数据库或者其他外部数据源中; 禁止在源代码中写入口令。 |
4.3.R5 | 口令传输 | 禁止传递明文口令,通过加密算法将口令加密后传递; 使用https加密传输。 |
4.3.R6 | 用户信息改变时使用单独的信道通知 | 允许用户改变其口令,当用户改变其账号信息时(例如重置口令)需要发送确认信息,并使用单独的通道发送确认信息; 可要求用户通过邮件等方式来确认信息的变更,但禁止在确认邮件中包含身份鉴别信息; 当用户改变其联系信息时,发送两次变更通知:分别包含旧的和新的信息。 |
4.4.R1 | 会话管理 | 会话时间 | 用户会话应当设置超时时间,禁止长时间会话空闲连接。 |
4.4.R2 | 会话销毁 | 会话销毁后,凭据及时刷新。 |
4.4.R3 | 数据重放检测 | 关键操作引入重放检测。 |
4.4.R4 | CSRF漏洞防范 | 防范CSRF攻击。 |
4.4.R5 | 敏感操作频率检测 | 敏感操作统计功能,便于发现异常操作。 |
4.4.R1 | 权限管理 | 横向权限 | 同级别不同用户权限严格限制授权。 |
4.4.R2 | 纵向权限 | 不同级别账户权限严格授权。 |
4.4.R3 | 权限细粒度 | 为不同的账户授予不同的权限,且权限授予可以自主调整。 |
4.5.R1 | 数据管理 | 数据输入采集 | 数据采集授权及隐私政策明示 数据输入验证(类型、长度、边界等) |
4.5.R2 | 数据传输 | 数据进行加密后传输,如AES加密。 |
4.5.R3 | 数据采用传输协议加密,如https加密。 |
4.5.R4 | 数据采用隧道加密技术传输,如vpn。 |
4.5.R5 | 数据在接入侧进行完整性校验,防止数据被破坏,如HASH值、MAC校验等。 |
4.5.R6 | 数据存储 | 数据采用加密存储。 |
4.5.R7 | 数据脱敏展示 | 展示信息经过脱敏遮盖后进行展示。 |
4.5.R8 | 数据查询 | 不应具备开放式查询能力,应严格限制批量查询,查询的时间段应当进行严格的限制。 |
4.5.R9 | 应当设置查询频率限制。 |
4.5.R10 | 对查询到的信息中的敏感信息进行脱敏处理。 |
4.5.R11 | 数据导出 | 对个人电子信息的导出操作进行细粒度的访问控制与全过程审计,应采取两种或两种以上鉴别技术对导出信息操作人员进行身份鉴别。 |
4.5.R12 | 数据可用性 | 数据备份,多数据库等。 |
4.6.R1 | 安全审计 | 审计数据保护 | 审计数据不能被篡改。 |
4.6.R2 | 用户登陆日志审计 | 记录用户登陆的日志信息。 |
4.6.R3 | 用户访问日志审计 | 记录用户访问页面的日志信息。 |
4.6.R4 | 用户操作日志审计 | 记录用户敏感操作的日志信息。 |
4.6.R1 | 加密解密 | 算法选择 | 算法应当选择符合国家标准的商用密码算法。 |
4.6.R2 | 密钥管理 | 禁止密钥明文存储; 禁止将密钥写入到代码中。 |
4.6.R1 | 日志调试信息管理 | 禁止出现敏感信息 | 在日志等调试信息中禁止出现客户敏感信息。 |
4.6.R1 | 个人信息更新 | 根据时间触发更新 | 建立客户重要信息的管理和更新机制,采取有效的管理和技术措施,不断提升和保障客户信息的准确性、完整性; 按照一定规则,如半年或者一年等,定期给客户发送提示短信,请及时更新个人信息,确保信息的准确有效。 |
4.6.R2 | 用户登陆提示 | 如果客户超过一定时期后登陆,如间隔半年后登陆,通过明确的提示弹框,提示用户更新其个人信息。 |
4.7.R1 | 文件操作 | 文件上传 | 验证文件的安全性。 |
4.7.R2 | 文件读取下载 | 避免目录遍历; 防止任意文件下载; |
4.8.R1 | API接口安全 | 接口身份认证 | App_ID、 App_Secret。 |
4.8.R2 | App_ID、数字证书。 |
4.8.R3 | App_ID、公私钥对。 |
4.8.R4 | Token授权 | Token随机,惟一标识一个用户。 |
4.8.R5 | Token超时机制。 |
4.8.R6 | 白名单 | IP白名单。 |
4.8.R7 | 调试信息 | 向应用方提供的异常与调试信息,不应泄漏服务器、中间件、数据库等软硬件信息或内部网络信息。 |
4.8.R8 | SDK | SDK 应当具备静态逆向分析防护能力、动态调试防护能力。 |
4.8.R9 | 日志 | 日志应至少包括交易流水号、应用唯一标识、接口唯一标识、调用耗时、时间戳、返回结果(成功或失败)等。 |
4.8.R10 | Timestamp时间戳 | 客户端调用接口时对应的当前时间戳,用于防止DoS攻击。每次调用接口时接口都会判断服务器当前系统时间和接口中传的的timestamp的差值,如果这个差值超过某个设置的时间,那么这个请求将被拦截掉。 |
4.8.R11 | API签名机制 | 签名机制保证了数据不会被篡改。 |
4.8.R12 | 其他 | 未详述部分遵循上述其他通用选项。 |
四、写在最后
安全开发与开发安全是两个不同的概念,安全开发是对安全相关的功能进行开发,而开发安全是在软件开发生命周期中加入安全保障,我们是属于后者,我们目前也是在摸着石头过河,在此提出我们自己的做法,与大家分享讨论。
CIO之家 www.ciozj.com 公众号:imciow