Geekly articles weekly

银行无现金支付的信息安全。 第7部分-基本威胁模型



研究内容是什么
链接到研究的其他部分


本文介绍了通过俄罗斯银行付款系统对银行电汇进行信息安全威胁的基本模型。

这里提出的威胁对于俄罗斯联邦的几乎所有银行以及使用胖客户通过密码确认付款进行付款的任何其他组织都是真实的。

根据俄罗斯银行于2016年8月24日发布的第552-P号法规和2012年6月9日发布的第382-P号法规的要求，此威胁模型旨在确保银行的实际安全和形成内部文件。
以非法目的使用物品中的信息受到法律的惩罚 。



建模技术


威胁模型结构


当今，最成功的计算机攻击建模方法之一是Kill链 。 此方法将计算机攻击表示为攻击者为实现目标而执行的一系列步骤。

大多数阶段都在“ MITRE ATT＆CK矩阵”中进行了描述，但是没有对最终动作进行解码-“动作”（最后一个“杀伤链”阶段），攻击者为此进行了攻击，并且实质上就是从银行盗窃钱财。 使用经典的Kill链进行威胁建模的另一个问题是缺乏与可访问性相关的威胁的描述。

此威胁模型旨在弥补这些缺陷。 为此，它将正式包括两个部分：

  • 第一个将描述可访问性问题。
  • 第二个是经典的Kill链，最后一步已解密，将描述从银行“盗窃”金钱。



创建威胁模型的方法


创建的威胁模型的主要要求是：

  • 保持紧凑性并减少重复，
  • 威胁识别的完整性和简化模型的能力，
  • 为业务专业人员和技术人员提供了使用该模型的机会。

为了实施任务集，该模型是在“威胁树”方法的基础上构建的，该方法进行了较小的改进：

  1. 从业务级别开始描述了威胁，并逐渐将其分解为技术组件。
  2. 信息基础结构的典型元素（例如，网络连接，密码信息保护系统等）固有的威胁被分组为标准威胁模型。
  3. 此外，当对信息基础结构的典型元素中固有的威胁建模时，与其重复描述威胁，不如参考相应的标准模型。

将此威胁模型应用于真实对象的过程


将此威胁模型应用于实际对象时，应先弄清信息基础结构的描述，然后在必要时对威胁进行更详细的分解。

模型中描述的威胁更新程序应根据组织的内部文件进行。 在没有此类文档的情况下，可以基于先前研究文章中讨论的技术来开发它们。

威胁模型设计功能


在此威胁模型中，采用以下清除规则：

  1. 威胁模型是威胁树。 威胁树以分层列表的形式编写，其中每个列表项都对应一个树节点，因此也对应一个特定的威胁。
  2. 威胁的名称以威胁的标识符开头，其格式为：

    U <威胁代码>

    其中“ Y”是威胁的缩写，“威胁代码”是层次结构列表（威胁树）中的威胁编号。
  3. 威胁描述可以包含两个块：
    • 说明提供了所描述威胁的说明。 可以在此处给出威胁实现的示例，分解过程中做出的决策说明，建模限制以及其他信息。
    • 分解包含儿童威胁的分层列表。

  4. 分解威胁时，默认情况下，至少一个子威胁的实施会导致父威胁的实施。 如果父威胁的实现以另一种方式依赖于子威胁的实现，则在描述父元素的行的末尾分解时，将指示依赖项的类型：

    • （ I ）-父母威胁的实现仅在所有儿童威胁的实现中发生。
    • （ 方案 ）-父母威胁的实现发生在某些特定的方案或算法中，用于实施儿童威胁。

  5. 可以使用以下模板链接到相同或其他威胁模型中描述的威胁： 链接：“ <威胁模型名称>。<威胁名称> ”。
  6. 如果子威胁的名称以<...>开头，则意味着在读取而不是<...>时，必须完全插入父威胁的名称。

银行无现金支付信息安全威胁的基本模型


应用了威胁模型的保护对象（范围）


这种威胁模型的范围扩展到通过俄罗斯银行付款系统进行无现金资金转移的过程。

建筑学
该模型的范围包括以下信息基础结构：



在这里：

“俄罗斯银行支付系统（PS BR）的部分” -信息基础结构的一部分，受俄罗斯银行2016年8月24日第552-P号法规的要求约束。 将信息基础设施归类为BR变电站的一部分的标准是在信息基础设施中处理UFEBS格式的电子消息。

“电子消息传输通道”包括银行与俄罗斯联邦中央银行的通信通道，该通道是通过专门的电信运营商或调制解调器连接建立的，以及使用信使和一次性计算机存储介质（OMNI）进行操作的电子消息传递机制。

威胁模型涵盖区域中包括的房屋清单由资金转移所涉及的信息基础设施的存在标准来确定。

型号限制
该威胁模型仅扩展到使用KBR AWP组织支付基础设施，结合加密和电子签名功能的选择，并且不考虑使用KBR-N AWP ，而在KBS-AWP的“电子签名”上进行电子签名。

顶级安全威胁


分解

U1。 无现金转账系统的终止。
U2。 无现金转账系统运行期间资金被盗。

U1。 无现金转账系统的终止


说明

实施此威胁可能造成的损害可以根据以下假设进行评估：

  • 通常，在客户与银行之间订立的银行帐户服务协议中，有一个标记，要求银行付款多长时间。 违反合同中规定的条款将导致银行对客户承担责任。
  • 如果银行突然停止付款，这将引起对其财务稳定性的质疑，结果可能导致大量存款流出。
  • 付款的连续性是维持银行牌照的条件之一。 系统性故障和故障可能会引起俄罗斯联邦中央银行对该银行的严重质疑，并导致吊销许可证。

在一般情况下，可以将付款执行中允许的最大延迟视为每个运营日一次航班。 延迟的进一步增加将对银行造成越来越多的损害。

分解此威胁时，请考虑以下文件：


分解

U1.1。 翻译中使用的设备或存储介质出现问题：
U1.1.1。 失败与失败。
U1.1.2。 盗窃
U1.1.3。 损失。
U1.2。 销毁进行传输所需的程序或数据。
U1.3。 通过网络罪犯进行转移的技术手段和通信渠道进行的拒绝服务（DoS，DDoS）攻击。
U1.4。 无法与俄罗斯联邦中央银行的支付系统交换电子消息（ I ）：
U1.4.1。 <...>通过网络连接：
U1.4.1.1。 与俄罗斯联邦中央银行的沟通渠道无法运作（ I ）：
U1.4.1.1.1。 <...>由专业电信运营商提供。
U1.4.1.1.2。 <...>组织为调制解调器连接。
U1.4.1.2。 终止用于验证与俄罗斯联邦中央银行的网络连接的信息。
U1.4.2。 <...>，在快递员的帮助下在异化的机器数据载体（OMNI）上执行：
U1.4.2.1。 缺少正确执行的文件：
U1.4.2.1.1 <...>，确认快递员的权限。
U1.4.2.1.2 <...>随付给OMNI的款项。
U1.5。 用于保护电子消息的加密密钥的终止：
U1.5.1。 加密密钥已过期。
U1.5.2。 破坏加密密钥。
U1.5.3。 攻击者挑衅俄罗斯联邦中央银行认证中心，以阻止该银行的加密密钥动作。
U1.6。 缺乏在工作场所执行无现金支付的人员。
U1.7。 使用用于电汇的软件的过时版本。
U1.8。 在前提条件下不可能发生技术设备，通讯渠道和转让人员正常运行的情况：
U1.8.1。 动力不足。
U1.8.2。 严重违反温度规定（过热，体温过低）。
U1.8.3。 火。
U1.8.4。 房间泛滥。
U1.8.5。 房屋倒塌或倒塌的威胁。
U1.8.6。 武装进攻。
U1.8.7。 放射性或化学污染。
U1.8.8。 强烈的电磁干扰。
U1.8.9。 流行病。
U1.9。 以行政方式终止对用于付款的信息基础设施所在的建筑物或房屋的访问：
U1.9.1。 阻止权限访问：
U1.9.1.1。 进行搜索或其他运营调查措施。
U1.9.1.2。 开展文化活动，宗教节日等
U1.9.2。 阻止所有者的访问：
U1.9.2.1。 企业实体冲突。
U1.10。 不可抗力情况（自然灾害，灾难，暴动，恐怖袭击，军事行动，僵尸末日等等）。

U2。 无现金转账系统运行期间资金被盗


说明

在无现金转帐系统运行期间，资金被盗是指非现金资金被盗，随后又从受害银行取款。

非现金资金被盗是客户或银行帐户余额的未经授权的更改。 这些变化可能是由于以下原因引起的：

  • 帐户余额的意外变更；
  • 未经授权的银行间或银行间汇款。

帐户余额的异常变化将被称为不受银行内部文件规范的操作，其结果是发生未经授权的银行帐户余额减少或增加。 此类操作的示例可以是：进行虚拟银行交易，直接更改存储位置（例如，数据库中）的余额和其他操作。

帐户余额的异常变化通常伴随着对被盗资金支出的定期操作。 这些操作包括：

  • 在受害银行的自动柜员机上提取现金，
  • 汇款到在其他银行开设的帐户，
  • 网上购物
  • 等

未经授权的资金转移是指未经授权处置资金的人同意而进行的转移，通常是由执行伪造的转移令的银行所进行。

假汇款订单既可以通过客户的过失也可以通过银行的过失产生。 在这种威胁模型中，将仅考虑银行责任范围内的威胁。 在此模型中，仅将付款订单视为汇款订单。

在一般情况下，可以认为银行对银行间转账的处理是银行间转账的特殊情况，因此，为了保持模型的紧凑性，下面仅考虑银行间转账。

无现金资金的盗用既可以在执行外发付款订单时执行，也可以在执行外来付款订单时执行。 在这种情况下，外发付款订单将被称为银行向俄罗斯银行付款系统发送的付款订单，收款订单将被称为银行从俄罗斯银行付款系统收到的付款订单。

分解

U2.1。 银行执行伪造的付款订单。
U2.2。 银行执行伪造的收款订单。
U2.3。 帐户余额异常变化。

U2.1。 银行执行伪造的付款订单


说明

银行可以执行伪造的付款指令的主要原因是犯罪分子将其引入处理付款的业务流程中。

分解

U2.1.1。 入侵者将伪造的付款订单注入到付款处理业务流程中。

U2.1.1。 入侵者将伪造的付款订单引入付款处理业务流程


说明

该威胁将根据可能会引入虚假支付单的信息基础架构的要素进行分解。
物品分解威胁“2.1.1。 入侵者将伪造的付款订单引入付款处理业务流程”
银行运营商U2.1.1.1。
RBS服务器U2.1.1.2。
集成模块DBO-ABSU2.1.1.3。
ABSU2.1.1.4。
ABS-CBD集成模块U2.1.1.5。
AWP中央商务区U2.1.1.6。
CBD-UTA集成模块U2.1.1.7。
UTAU2.1.1.8。
电子邮件频道U2.1.1.9。

分解

U2.1.1.1。 元素“银行运营商”中的<...>。
U2.1.1.2。 <...>在“ RBS服务器”元素中。
U2.1.1.3。 <...>在元素“集成模块DBO-ABS”中。
U2.1.1.4。 ABS元素中的<...>。
U2.1.1.5。 <...>在元素“ ABS-CBD集成模块”中。
Y2.1.1.6。元素“ AWP KBR”中的<...>。
U2.1.1.7。元素“ CBD-UTA集成模块”中的<...>。
U2.1.1.8。 UTA元素中的<...>。
U2.1.1.9。 <...>在“电子消息通道”元素中。

U2.1.1.1。 元素“银行运营商”中的<...>


说明

当操作员接受客户的纸质付款单时，操作员将在他的基础上在ABS中输入电子文件。 绝大多数现代ABS都是基于客户端-服务器体系结构的，该体系结构允许基于客户端-服务器信息系统的典型威胁模型来分析此威胁。

分解

U2.1.1.1.1。 银行操作员从攻击者那里接受了攻击，攻击者向自己介绍了自己为银行客户的伪造付款指令（纸质形式）。
U2.1.1.1.2。 代表银行操作员的虚假电子付款订单已提交给ABS。
U2.1.1.1.2.1。 店员行为不当或无意中犯了错误。
U2.1.1.1.2.2。 攻击者代表操作者采取了以下行动：
U2.1.1.1.2.2.1。 链接： “典型的威胁模型。 基于客户端-服务器体系结构构建的信息系统。 U1。 犯罪分子代表合法用户实施未经授权的行为 。 ”

注意事项 以下文章将讨论典型的威胁模型。

U2.1.1.2。 元素“ RBS服务器”中的<...>


分解

U2.1.1.2.1。 RBS服务器代表客户接受了正式认证的付款单，但未经客户同意，由攻击者制定：
U2.1.1.2.1.1。 链接： “典型的威胁模型。 基于客户端-服务器体系结构构建的信息系统。 U1。 犯罪分子代表合法用户实施未经授权的行为 。 ”
U2.1.1.2.2。 攻击者向RBS服务器引入了伪造的付款命令：
U2.1.1.2.2.1。 链接： “典型的威胁模型。 基于客户端-服务器体系结构构建的信息系统。U2。“信息系统的服务器部分在处理受保护信息时未经授权对其进行修改。”

U2.1.1.3。<...>在元素“集成模块DBO-ABS”中


分解

U2.1.1.3.1。链接：“典型的威胁模型。集成模块。U1。入侵者通过集成模块引入虚假信息。”

U2.1.1.4。ABS元素中的<...>


分解

U2.1.1.4.1。链接：“典型的威胁模型。基于客户端-服务器体系结构构建的信息系统。U2。“信息系统的服务器部分在处理受保护信息时未经授权对其进行修改。”

U2.1.1.5。元素“ ABS-CBD集成模块”中的<...>


分解

U2.1.1.5.1。链接：“典型的威胁模型。集成模块。U1。入侵者通过集成模块引入虚假信息。”

U2.1.1.6。<...>在元素“ AWS KBR”中




, . .

():

2.1.1.6.1. :
2.1.1.6.1.1. : « . . 2. » .
2.1.1.6.2. :
2.1.1.6.2.1. : “典型的威胁模型。密码信息安全系统。U4。在虚假数据下创建合法签名人的电子签名。”

U2.1.1.7。元素“ CBD-UTA集成模块”中的<...>


说明

根据处理付款的技术过程，将对CBD-CBR工作站部分上的电子消息进行电子签名和加密。因此，只有在攻击者绕过标准加密保护程序设法加密并签署伪造付款单的情况下，才可能在此阶段引入伪造付款单。

分解（I）：

U2.1.1.7.1。链接：“当前的威胁模型。U2.1.1.6。<...>在元素“ AWS KBR”中。
U2.1.1.7.2。链接：“典型的威胁模型。集成模块。U1。入侵者通过集成模块引入虚假信息。”

U2.1.1.8。UTA元素中的<...>


解释

实际上，UTA是一种信息机器人，可以与俄罗斯联邦中央银行交换受密码保护的电子消息。该元素对信息安全的威胁与来自集成模块的威胁相对应。

分解（I）：

U2.1.1.8.1。链接：“当前的威胁模型。U2.1.1.6。<...>在元素“ AWS KBR”中。
U2.1.1.8.2。链接：“典型的威胁模型。集成模块。U1。入侵者通过集成模块引入虚假信息。”

U2.1.1.9。<...>在“电子消息通道”元素中


分解（I）：

U2.1.1.9.1。链接：“当前的威胁模型。U2.1.1.6。<...>在元素“ AWS KBR”中。
U2.1.1.9.2。攻击者将伪造的付款单转移到俄罗斯银行：
2.1.1.9.2.1。<...>在与代表该银行成立的俄罗斯银行进行的交流中。
U2.1.1.9.2.2。<...>使用OMNI的快递员。

U2.2。银行执行伪造的收款订单


分解

U2.2.1。入侵者将伪造的付款订单注入到付款处理业务流程中。

U2.2.1。入侵者将伪造的收款订单引入付款处理业务流程




— . — .

. (private PKI), : — . , .

因此，为了引入伪造的付款指令，攻击者需要破坏接收者的公共加密密钥和电子签名密钥，其证书受接收者银行信任。

该威胁将根据可能引入虚假收款单的基础架构要素进行分解
物品分解威胁“ U2.2.1。入侵者在付款处理业务流程中引入了伪造的付款订单”
ABSU2.2.1.1。
ABS-CBD集成模块U2.2.1.2。
AWP中央商务区U2.2.1.3。
CBD-UTA集成模块U2.2.1.4。
UTAU2.2.1.5。
电子邮件频道U2.2.1.6。

分解

U2.2.1.1。ABS元素中的<...>。
U2.2.1.2。<...>在元素“ ABS-CBD集成模块”中。
Y2.2.1.3。<...>在元素“ AWP KBR”中。
U2.2.1.4。元素“ CBD-UTA集成模块”中的<...>。
U2.2.1.5。UTA元素中的<...>。
U2.2.1.6。<...>在“电子消息通道”元素中。

U2.2.1.1。ABS元素中的<...>


分解

U2.2.1.1.1。链接：“典型的威胁模型。基于客户端-服务器体系结构构建的信息系统。U2。“信息系统的服务器部分在处理受保护信息时未经授权对其进行修改。”

U2.2.1.2。元素“ ABS-CBD集成模块”中的<...>


分解

U2.2.1.2.1。链接：“典型的威胁模型。集成模块。U1。入侵者通过集成模块引入虚假信息。”

U2.2.1.3。<...>在元素“ AWS KBR”中




, . , , , , .



2.2.1.3.1. :
2.2.1.3.1.1 : « . . 5. » .

2.2.1.4. <...> « -»




, , (), , , . , , .

():

U2.2.1.4.1。中和传入电子消息的密码保护（I）：
U2.2.1.4.1.1。银行公钥上的伪造付款单加密：
U2.2.1.4.1.1.1。链接：“典型的威胁模型。密码信息安全系统。 U2。代表合法发件人对欺诈性数据进行加密。”
U2.2.1.4.1.2。电子签名的私人钥匙上的伪造付款单，银行信任其证书：
U2.2.1.4.1.2.1。链接：“典型的威胁模型。密码信息安全系统。 U4。在虚假数据下创建合法签名人的电子签名。”
U2.2.1.4.2。连结：“典型的威胁模型。集成模块。U1。入侵者通过集成模块引入虚假信息。”

U2.2.1.5。UTA元素中的<...>


分解：

U2.2.1.5.1。链接：“当前的威胁模型。U2.2.1.4。<...>在元素“ CBD-UTA集成模块”中。

U2.2.1.6。<...>在“电子消息通道”元素中


分解（I）：

U2.2.1.6.1。链接：“当前威胁模型。U.2.2.1.4.1。取消传入电子消息的密码保护。“
U2.2.1.6.2。从俄罗斯联邦中央银行收到伪造的付款订单：
U2.2.1.6.2.1。<...>在与代表该银行成立的俄罗斯银行进行的交流中。
U2.2.1.6.2.2。<...>使用OMNI的快递员。

结论


该系列的下一篇文章将研究典型的威胁模型：

Source: https://habr.com/ru/post/zh-CN421161/

More articles:


All Articles