您好,欢迎访问代理记账网站
移动应用 微信公众号 联系我们

咨询热线 -

电话 15988168888

联系客服
  • 价格透明
  • 信息保密
  • 进度掌控
  • 售后无忧

软件安全

文章目录

  • 软件安全
    • 软件安全的概述
        • 软件面临的安全威胁
        • SDS
    • 软件漏洞概述
        • 概念
        • 漏洞生命时间轴
        • 软件漏洞的定义
    • Windows系统典型漏洞分析
        • Windows安全漏洞保护分析
          • 栈溢出检测选项/GS
          • 数据执行保护DEP
          • 地址空间布局随机化ASLR
          • 安全结构化异常处理SafeSEH
    • 软件安全开发模型
      • 微软的SDL简化模型
      • 名词解释
    • 软件安全需求分析
      • 外部安全需求
      • 内部安全需求
      • 软件安全总从性要求
    • 软件安全设计
      • 经典安全设计原则条目
        • Saltzer和Schroeder提出的安全设计8条原则
        • John Viega 和 Gary McGraw总结的10条软件安全设计原则
        • Michael Howard 总结的13条安全设计原则
        • 威胁建模
    • 软件安全测试
      • 软件安全测试方法分类
      • 渗透测试

软件安全

软件安全的概述

软件面临的安全威胁

  • 软件漏洞:通常被认为是软件生命周期中与安全相关的设计错误、编码缺陷及运行故障等。
  • 恶意代码:是在未被授权的情况下,以破坏软硬件设备、窃取用户信息、干扰用户正常使用、扰乱用户心理为目的而编制的软件或代码片段。
  • 软件侵权

SDS

SDS是使用SDN复杂网络的安全防护新思想,基本原理是将物理及虚拟的网络安全设备预期接入模式、部署方式和实现功能进行解耦,底层抽象为安全资源池里的资源,顶层同意通过软件编程的方式进行智能化、自动化的业务编排和管理,以完成相应的安全功能,从而实现一种灵活的安全防护。SDS可以分解为软件定义流量、软件定义资源和软件定义威胁模型,三个举措环环相扣,形成一个动态、闭环的工作模型

软件漏洞概述

概念

软件漏洞通常被认为是软件生命周期中与安全相关的设计错误、编码缺陷及运行故障等。
软件漏洞包括错误(Error/Mistake)、缺陷(Defect/Flaw/Bug)及失效(Failure)等。

  • 软件错误:指在软件开发过程中出现不符合期望或不可接受的人为差错,其结果将可能导致软件缺陷的产生。
  • 软件缺陷:指由于人为差错或其他客观原因,导致软件隐含能导致其在运行过程中出现不希望或不可接受的偏差,例如软件需求定义,以及设计、实现等错误。
  • 软件故障:指软件出现可感知的不正常、不正确、或不按规范执行的状态。
  • 软件失效:指软件丧失完成规定功能的能力的事件。

漏洞生命时间轴

从时间维度上,漏洞都会经历产生、发现、公开和消亡等过程。从漏洞是否可利用且相应的补丁是否已经发布的角度,可以将漏洞分成以下三类:

  • 0day漏洞:已经被发现但是官方还没有相关补丁的漏洞。
  • 1day漏洞:厂商发布安全补丁之后但大部分用户还未打补丁时的漏洞,此类漏洞依然具有可利用性。
  • 历史漏洞:距离补丁发布日期已久且可利用性不高的漏洞。

软件漏洞的定义

软件系统或产品在设计、实现、配置和运行等过程中,由操作实体有意或无意产生的缺陷、瑕疵或错误,它们以不同形式存在于信息系统的各个层次和环节之中,且随着信息系统的变化而改变。

Windows系统典型漏洞分析

Windows安全漏洞保护分析

Windows平台下集中点秀的漏洞利用阻断技术:/GS、DEP、ASLR及SafeSEH。

栈溢出检测选项/GS
  1. /GS保护机制

    调用函数时将一个随机生成的秘密值(Cookie)存放在栈上,当函数返回时,检查这个堆栈检测仪的值是否被修改,以此判断是否发生了栈溢出。

  2. 对抗/GS保护

    1. 猜测Cookie值
    2. 通过同时替换栈中的Cookie和Cookie副本
    3. 覆盖SEH绕过Cookie检查
    4. 覆盖父函数的栈数据绕过Cookie检查
数据执行保护DEP
  1. 数据执行保护DEP机制

    栈溢出漏洞最常见的利用方式是:在栈中精心构造二进制串溢出原有数据结构,进而改写函数返回地址,使其跳转到位于栈中的Shellcode中执行。如果使栈上数据不可执行,那么就可以阻止这种漏洞利用方式的成功实施。而DEP就是通过使可写内存不可执行或使可执行内存不可惜写,以消除类似威胁

  2. 对抗数据执行保护DEP

    • 利用ret-to-libc执行命令或进行API调用,如调用WinExec实现执行程序。
    • 将包含Shellcode的内存页面标记为可执行,然后再跳过去执行。
    • 通过分配可执行内存,再将Shellcode复制到内存区域,然后跳过去执行。
    • 先尝试关闭当前进程的DEP保护,然后再运行Shellcode。
地址空间布局随机化ASLR
  1. 地址空间布局随机化ASLR机制
    原理:通过对堆、栈和共享库映射等线性区域布局的随机化,增加攻击者预测目的地址的难度,防止攻击者直接定位攻击代码位置,达到阻止漏洞利用的目的。

    包括以下几个方面:

    • 映像随机化:改变可执行文件和DLL文件的加载地址。
    • 栈随机化:改变每个线程栈的起始地址。
    • 堆随机化:改变已分配堆的基地址
  2. ASLR机制的缺陷和绕过方法

    1. 对本地攻击者无能为力
    2. 造成内存碎片的增多
    3. 利用没用采用/DYNAMICBASE选项保护的模块作为跳板
安全结构化异常处理SafeSEH
  1. SafeSEH机制
    原理:编译器在连接生成二进制IMAGE时,把所有合法的异常处理函数的地址解析出来制成一张安全的SEH表,保存在程序的IMAGE数据库中,当程序调用异常处理时会将函数地址与安全SEH表中的地址进行匹配,检查调用的异常处理函数是否位于该表中。如果IMAGE不支持SafeSEH,则表的地址为0。
  2. 对抗SafeSEH机制的方法
    1. 利用未启用SafeSEH的模块作为跳板进行绕过
    2. 利用加载模块之外的地址进行绕过

软件安全开发模型

微软的SDL简化模型

培训
需求分析
设计
实施
验证
发布
响应
  • 培训

    • 安全培训
  • 需求分析

    • 确定安全需求
    • 创建质量门/缺陷等级
    • 安全/隐私风险评估
  • 设计

    • 确定设计要求
    • 减少攻击面
    • 威胁建模
  • 实施

    • 使用批准工具
    • 弃用不安全函数
    • 静态代码分析
  • 验证

    • 程序动态分析
    • 模糊测试
    • 威胁模型/攻击面分析
  • 发布

    • 事件响应计划
    • 最终安全审核
    • 发布/存档
  • 响应

    • 执行事件响应计划

敏捷SDL能够快速利用敏捷开发刘晨更好地实现安全需求

名词解释

  • SDL:软件安全开发生命周期
  • BSI:内建安全模型
  • CLASP:综合的轻量级应用安全过程
  • SAMM:软件保障成熟度模型

软件安全需求分析

外部安全需求

外部安全需求通常主要指法律、法规等遵从性需求,包括相应国家和地区关于安全技术与管理的法规、标准及要求等。

内部安全需求

内部安全需求通常包括两个部分,一是组织内部需要遵守的政策、标准、指南和实践模式,二是与软件业务功能相关的安全需求。

软件安全总从性要求

信息系统安全评测国际标准、信息安全管理国际标准、信息系统安全工程国际标准以及我国的信息安全标准

软件安全设计

经典安全设计原则条目

Saltzer和Schroeder提出的安全设计8条原则

  1. 经济性
  2. 默认安全配置
  3. 完全控制
  4. 开发设计
  5. 权限分离
  6. 最小特权
  7. 最少共用机制
  8. 心理可接受

John Viega 和 Gary McGraw总结的10条软件安全设计原则

  1. 保护最弱的一环
  2. 纵深防御
  3. 失效安全
  4. 最小特权
  5. 权限分离
  6. 保持简单
  7. 保护隐私
  8. 隐藏信息是困难的
  9. 不轻信
  10. 使用社区资源

Michael Howard 总结的13条安全设计原则

  1. 从错误中吸取教训
  2. 尽可能地减少软件受攻击面
  3. 纵深防御
  4. 使用最小特权
  5. 采用安全的默认设hi
  6. 向下兼容总是不安全的
  7. 假设外部系统是不安全的
  8. 要有应对失败的计划
  9. 系统失效时几个进入安全模式
  10. 安全特性不等于安全的特性
  11. 绝对不要将安全仅维系于隐匿
  12. 不要将代码于数据混在一起
  13. 正确地解决安全问题。

威胁建模

没有标准的定义,但是有一个解释:软件威胁建模是指,通过抽象的概念模型对影响软件系统的威胁进行系统的识别和评价

威胁建模的一般过程:

确定安全目标
创建应用程序概况图
分解应用程序
确定威胁
威胁评估
确定威胁缓解计划或策略
验证威胁
验证建档
  • 确定安全目标:包括确定软件系统设计的资产,以及围绕这些资产的业务目标和安全目标

  • 创建应用程序概况图:主要目的是分析应用程序的功能、应用程序的体系结构、物理部署配置以及构成解决方案的技术。

  • 分解应用程序:主要目的是通过分解应用程序的结构来确定信任边界、数据流数据入口点和数据出口点。

  • 确定威胁:确认可能影响应用程序和危机安全目标的威胁,以及深入分析其他可能威胁。

  • 威胁评估

    • 常见风险票据方法:Delphi排序、平均排序以及概率×影响因子排序。
  • 确定威胁缓解计划或者策略
    | 威胁 | 缓解措施 |
    | :------------------------------: | :----------------------------------------------------------: |
    | 假冒(Spoofing) | 验证主体:Windows身份研制(NTLM)、Kerveros身份验证、Windows或Live ID身份验证、PKI系统(如SSL/TLS和证书)、IPsec、数字 前面数据包代码或数据:数字签名、消息认证码、哈希 |
    | 篡改(Tampering) | 访问控制列表、Windows完整性控制、数字签名、消息认证码 |
    | 否认(Repudiation) | 强身份认证、安全日志记录和审计、数字签名、时间戳、受信任的第三方 |
    | 信息泄露(Information disclosure) | 加密、访问控制列表 |
    | 拒绝服务(Denial of service) | 访问控制列表、配额和费率限制、授权、高可用性设计 |
    | 特权提升(Elevation of privilege) | 访问控制列表、组或角色成员资格、权限、输入验证 |

  • 验证威胁:说明列举出的威胁如何进行攻击、攻击的内容级影响。

  • 验证建档:需要记录的威胁属性有(威胁的类型、独有的标识符、威胁描述、威胁目标、攻击技术、安全影响、发生的可能性或威胁转化为现实的风险,以及可能实施的缓解措施)

软件安全测试

软件安全测试方法分类

软件安全测试方法
白盒测试
黑盒测试
安全功能测试
源码分析
漏洞扫描
模糊测试
渗透测试
保密性
完整性
可用性
可认证性
授权
可记账性/审计
静态分析
动态分析
脆弱点扫描
威胁内容扫描
隐私保证扫描
基于生成的模糊测试
基于变异的模糊测试
黑盒渗透测试
白盒渗透测试

渗透测试

渗透测试技术的核心思想是模仿黑客的特定攻击行为,也就是尽可能完整地模拟黑客使用的漏洞发现技术和攻击手段,对目标的安全性做深入的探测,发现系统最脆弱环节的过程。

《渗透测试执行标准》将渗透测试过程分为以下七个阶段:

  1. 前期交互
  2. 情报收集
  3. 威胁建模
  4. 漏洞分析
  5. 渗透攻击
  6. 后渗透攻击
    )
    G–>G1(基于生成的模糊测试)
    G–>G2(基于变异的模糊测试)
    H–>H1(黑盒渗透测试)
    H–>H2(白盒渗透测试)

### 渗透测试

渗透测试技术的核心思想是模仿黑客的特定攻击行为,也就是尽可能完整地模拟黑客使用的漏洞发现技术和攻击手段,对目标的安全性做深入的探测,发现系统最脆弱环节的过程。

《渗透测试执行标准》将渗透测试过程分为以下七个阶段:

1. 前期交互
2. 情报收集
3. 威胁建模
4. 漏洞分析
5. 渗透攻击
6. 后渗透攻击
7. 报告

分享:

低价透明

统一报价,无隐形消费

金牌服务

一对一专属顾问7*24小时金牌服务

信息保密

个人信息安全有保障

售后无忧

服务出问题客服经理全程跟进