Bảo mật thông tin thanh toán không dùng tiền mặt của ngân hàng. Phần 8 - Các mô hình mối đe dọa điển hình

Bảo mật thông tin thanh toán không dùng tiền mặt của ngân hàng. Phần 8 - Các mô hình mối đe dọa điển hình
Nghiên cứu về cái gì?

Liên kết đến các phần khác của nghiên cứu

Bài viết này hoàn thiện loạt ấn phẩm nhằm đảm bảo an toàn thông tin trong thanh toán không dùng tiền mặt của ngân hàng. Ở đây chúng ta sẽ xem xét các mô hình mối đe dọa điển hình được đề cập trong mô hình cơ sở:

HABRO-CẢNH BÁO!!! Khabrovites thân mến, đây không phải là một bài viết mang tính giải trí.
Hơn 40 trang tài liệu ẩn dưới phần cắt nhằm mục đích giúp đỡ trong công việc hoặc học tập những người chuyên về ngân hàng hoặc bảo mật thông tin. Những tài liệu này là sản phẩm cuối cùng của quá trình nghiên cứu và được viết với giọng văn khô khan, trang trọng. Thực chất đây là những khoảng trống dành cho các tài liệu bảo mật thông tin nội bộ.

Vâng, truyền thống - “việc sử dụng thông tin từ bài viết cho mục đích bất hợp pháp sẽ bị pháp luật trừng phạt”. Đọc hiệu quả!


Thông tin dành cho độc giả đã làm quen với nghiên cứu bắt đầu từ ấn phẩm này.

Nghiên cứu về cái gì?

Bạn đang đọc hướng dẫn dành cho chuyên gia chịu trách nhiệm đảm bảo an toàn thông tin thanh toán trong ngân hàng.

Logic trình bày

Lúc đầu ở Bộ phận 1 и Bộ phận 2 một mô tả của đối tượng được bảo vệ được đưa ra. Sau đó vào Bộ phận 3 mô tả cách xây dựng một hệ thống bảo mật và nói về sự cần thiết phải tạo ra một mô hình mối đe dọa. TRONG Bộ phận 4 nói về những mô hình mối đe dọa tồn tại và cách chúng được hình thành. TRONG Bộ phận 5 и Bộ phận 6 Một phân tích về các cuộc tấn công thực sự được cung cấp. Часть 7 и Phần 8 chứa mô tả về mô hình mối đe dọa, được xây dựng có tính đến thông tin từ tất cả các phần trước đó.

MÔ HÌNH MỐI ĐE DỌA ĐIỂN HÌNH. KẾT NỐI MẠNG

Đối tượng bảo vệ áp dụng mô hình mối đe dọa (phạm vi)

Đối tượng bảo vệ là dữ liệu được truyền qua kết nối mạng hoạt động trong các mạng dữ liệu được xây dựng trên cơ sở ngăn xếp TCP/IP.

kiến trúc

Bảo mật thông tin thanh toán không dùng tiền mặt của ngân hàng. Phần 8 - Các mô hình mối đe dọa điển hình

Mô tả các yếu tố kiến ​​trúc:

  • "Nút kết thúc" - các nút trao đổi thông tin được bảo vệ.
  • "Các nút trung gian" — các thành phần của mạng truyền dữ liệu: bộ định tuyến, bộ chuyển mạch, máy chủ truy cập, máy chủ proxy và các thiết bị khác — qua đó lưu lượng kết nối mạng được truyền đi. Nói chung, kết nối mạng có thể hoạt động mà không cần các nút trung gian (trực tiếp giữa các nút cuối).

Các mối đe dọa bảo mật cấp cao nhất

Sự phân hủy

U1. Truy cập trái phép vào dữ liệu được truyền.
U2. Sửa đổi trái phép dữ liệu được truyền.
U3. Xâm phạm quyền tác giả của dữ liệu được truyền đi.

U1. Truy cập trái phép vào dữ liệu được truyền

Sự phân hủy
U1.1. <…>, được thực hiện tại các nút cuối cùng hoặc trung gian:
U1.1.1. <…> bằng cách đọc dữ liệu khi nó ở trong thiết bị lưu trữ máy chủ:
U1.1.1.1. <…> trong RAM.
Giải thích cho U1.1.1.1.
Ví dụ: trong quá trình xử lý dữ liệu bởi ngăn xếp mạng của máy chủ.

U1.1.1.2. <…> trong bộ nhớ không khả biến.
Giải thích cho U1.1.1.2.
Ví dụ: khi lưu trữ dữ liệu được truyền trong bộ đệm, tệp tạm thời hoặc tệp hoán đổi.

U1.2. <…>, được thực hiện trên các nút bên thứ ba của mạng dữ liệu:
U1.2.1. <…> bằng phương pháp bắt tất cả các gói đến giao diện mạng của máy chủ:
Giải thích cho U1.2.1.
Việc ghi lại tất cả các gói được thực hiện bằng cách chuyển card mạng sang chế độ không liên tục (chế độ không liên tục đối với bộ điều hợp có dây hoặc chế độ giám sát đối với bộ điều hợp wi-fi).

U1.2.2. <…> bằng cách thực hiện các cuộc tấn công man-in-the-middle (MiTM), nhưng không sửa đổi dữ liệu được truyền (không tính dữ liệu dịch vụ giao thức mạng).
U1.2.2.1. Liên kết: “Mô hình mối đe dọa điển hình. Kết nối mạng. U2. Sửa đổi trái phép dữ liệu được truyền".

U1.3. <…>, được thực hiện do rò rỉ thông tin qua các kênh kỹ thuật (TKUI) từ các nút vật lý hoặc đường truyền thông.

U1.4. <…>, được thực hiện bằng cách cài đặt các phương tiện kỹ thuật đặc biệt (STS) ở nút cuối hoặc nút trung gian, nhằm mục đích thu thập thông tin bí mật.

U2. Sửa đổi trái phép dữ liệu được truyền

Sự phân hủy
U2.1. <…>, được thực hiện tại các nút cuối cùng hoặc trung gian:
U2.1.1. <…> bằng cách đọc và thực hiện các thay đổi đối với dữ liệu khi nó ở trong thiết bị lưu trữ của các nút:
U2.1.1.1. <…> trong RAM:
U2.1.1.2. <…> trong bộ nhớ cố định:

U2.2. <…>, được thực hiện trên các nút bên thứ ba của mạng truyền dữ liệu:
U2.2.1. <…> bằng cách thực hiện các cuộc tấn công trung gian (MiTM) và chuyển hướng lưu lượng truy cập đến nút của kẻ tấn công:
U2.2.1.1. Kết nối vật lý của thiết bị của kẻ tấn công khiến kết nối mạng bị đứt.
U2.2.1.2. Thực hiện tấn công vào các giao thức mạng:
U2.2.1.2.1. <…> quản lý mạng cục bộ ảo (VLAN):
U2.2.1.2.1.1. Nhảy Vlan.
U2.2.1.2.1.2. Sửa đổi trái phép cài đặt Vlan trên thiết bị chuyển mạch hoặc bộ định tuyến.
U2.2.1.2.2. <…> định tuyến lưu lượng:
U2.2.1.2.2.1. Sửa đổi trái phép bảng định tuyến tĩnh của bộ định tuyến.
U2.2.1.2.2.2. Thông báo các tuyến đường sai của kẻ tấn công thông qua các giao thức định tuyến động.
U2.2.1.2.3. <…> cấu hình tự động:
U2.2.1.2.3.1. DHCP giả mạo.
U2.2.1.2.3.2. WPAD giả mạo.
U2.2.1.2.4. <…> địa chỉ và độ phân giải tên:
U2.2.1.2.4.1. ARP giả mạo.
U2.2.1.2.4.2. giả mạo DNS.
U2.2.1.2.4.3. Thực hiện các thay đổi trái phép đối với tệp tên máy chủ cục bộ (máy chủ, lmhost, v.v.)

U3. Vi phạm bản quyền dữ liệu truyền đi

Sự phân hủy
U3.1. Vô hiệu hóa các cơ chế xác định quyền tác giả của thông tin bằng cách chỉ ra thông tin sai lệch về tác giả hoặc nguồn dữ liệu:
U3.1.1. Thay đổi thông tin về tác giả có trong thông tin được truyền đi.
U3.1.1.1. Vô hiệu hóa việc bảo vệ bằng mật mã đối với tính toàn vẹn và quyền tác giả của dữ liệu được truyền:
U3.1.1.1.1. Liên kết: “Mô hình mối đe dọa điển hình. Hệ thống bảo vệ thông tin mật mã.
U4. Tạo chữ ký điện tử của người ký hợp pháp dưới dữ liệu sai lệch"
.
U3.1.1.2. Vô hiệu hóa bảo vệ bản quyền đối với dữ liệu được truyền, được thực hiện bằng mã xác nhận một lần:
U3.1.1.2.1. Trao đổi SIM.

U3.1.2. Thay đổi thông tin về nguồn thông tin được truyền đi:
U3.1.2.1. Giả mạo IP.
U3.1.2.2. MAC giả mạo.

MÔ HÌNH MỐI ĐE DỌA ĐIỂN HÌNH. HỆ THỐNG THÔNG TIN ĐƯỢC XÂY DỰNG TRÊN KIẾN TRÚC KHÁCH HÀNG-SERVER

Đối tượng bảo vệ áp dụng mô hình mối đe dọa (phạm vi)

Đối tượng bảo vệ là hệ thống thông tin được xây dựng trên cơ sở kiến ​​trúc client-server.

kiến trúc
Bảo mật thông tin thanh toán không dùng tiền mặt của ngân hàng. Phần 8 - Các mô hình mối đe dọa điển hình

Mô tả các yếu tố kiến ​​trúc:

  • "Khách hàng" – một thiết bị mà phần khách hàng của hệ thống thông tin hoạt động trên đó.
  • "Máy chủ" – một thiết bị mà phần máy chủ của hệ thống thông tin hoạt động.
  • "Kho dữ liệu" - một phần của cơ sở hạ tầng máy chủ của hệ thống thông tin, được thiết kế để lưu trữ dữ liệu được hệ thống thông tin xử lý.
  • "Kết nối mạng" — kênh trao đổi thông tin giữa Máy khách và Máy chủ đi qua mạng dữ liệu. Một mô tả chi tiết hơn về mô hình phần tử được đưa ra trong “Một mô hình mối đe dọa điển hình. Kết nối mạng".

Hạn chế
Khi lập mô hình một đối tượng, các hạn chế sau được đặt:

  1. Người dùng tương tác với hệ thống thông tin trong khoảng thời gian hữu hạn, được gọi là phiên làm việc.
  2. Vào đầu mỗi phiên làm việc, người dùng được xác định, xác thực và ủy quyền.
  3. Tất cả thông tin được bảo vệ được lưu trữ trên phần máy chủ của hệ thống thông tin.

Các mối đe dọa bảo mật cấp cao nhất

Sự phân hủy
U1. Thực hiện các hành động trái phép của kẻ tấn công thay mặt cho người dùng hợp pháp.
U2. Sửa đổi trái phép thông tin được bảo vệ trong quá trình xử lý bởi phần máy chủ của hệ thống thông tin.

U1. Thực hiện các hành động trái phép của kẻ tấn công thay mặt cho người dùng hợp pháp

Giải thích
Thông thường trong hệ thống thông tin, các hành động có tương quan với người dùng thực hiện chúng bằng cách sử dụng:

  1. nhật ký vận hành hệ thống (log).
  2. thuộc tính đặc biệt của đối tượng dữ liệu chứa thông tin về người dùng đã tạo hoặc sửa đổi chúng.

Liên quan đến phiên làm việc, mối đe dọa này có thể được chia thành:

  1. <…> được thực hiện trong phiên người dùng.
  2. <…> được thực thi bên ngoài phiên người dùng.

Một phiên người dùng có thể được bắt đầu:

  1. Bởi chính người dùng.
  2. Kẻ xấu.

Ở giai đoạn này, quá trình phân hủy trung gian của mối đe dọa này sẽ như sau:
U1.1. Các hành động trái phép đã được thực hiện trong phiên người dùng:
U1.1.1. <…> được cài đặt bởi người dùng bị tấn công.
U1.1.2. <…> được cài đặt bởi những kẻ tấn công.
U1.2. Các hành động trái phép được thực hiện bên ngoài phiên người dùng.

Từ quan điểm của các đối tượng cơ sở hạ tầng thông tin có thể bị ảnh hưởng bởi kẻ tấn công, việc phân rã các mối đe dọa trung gian sẽ như sau:

các yếu tố
Phân hủy mối đe dọa

U1.1.1.
U1.1.2.
U1.2.

Khách hàng
U1.1.1.1.
U1.1.2.1.

Kết nối mạng
U1.1.1.2.

Máy chủ

U1.2.1.

Sự phân hủy
U1.1. Các hành động trái phép đã được thực hiện trong phiên người dùng:
U1.1.1. <…> được cài đặt bởi người dùng bị tấn công:
U1.1.1.1. Những kẻ tấn công đã hành động độc lập với Khách hàng:
U1.1.1.1.1 Những kẻ tấn công đã sử dụng các công cụ truy cập hệ thống thông tin tiêu chuẩn:
U1.1.1.1.1.1. Những kẻ tấn công đã sử dụng phương tiện đầu vào/đầu ra vật lý của Khách hàng (bàn phím, chuột, màn hình hoặc màn hình cảm ứng của thiết bị di động):
U1.1.1.1.1.1.1. Những kẻ tấn công hoạt động trong khoảng thời gian khi phiên hoạt động, các cơ sở I/O có sẵn và người dùng không có mặt.
У1.1.1.1.1.2. Kẻ tấn công đã sử dụng các công cụ quản trị từ xa (tiêu chuẩn hoặc do mã độc cung cấp) để quản lý Client:
U1.1.1.1.1.2.1. Những kẻ tấn công hoạt động trong khoảng thời gian khi phiên hoạt động, các cơ sở I/O có sẵn và người dùng không có mặt.
U1.1.1.1.1.2.2. Những kẻ tấn công đã sử dụng các công cụ quản trị từ xa mà người dùng bị tấn công không thể nhìn thấy hoạt động của chúng.
U1.1.1.2. Những kẻ tấn công đã thay thế dữ liệu trong kết nối mạng giữa Máy khách và Máy chủ, sửa đổi dữ liệu theo cách được coi là hành động của người dùng hợp pháp:
U1.1.1.2.1. Liên kết: “Mô hình mối đe dọa điển hình. Kết nối mạng. U2. Sửa đổi trái phép dữ liệu được truyền".
U1.1.1.3. Những kẻ tấn công buộc người dùng thực hiện các hành động mà chúng chỉ định bằng các phương pháp lừa đảo xã hội.

У1.1.2 <…> do kẻ tấn công cài đặt:
U1.1.2.1. Những kẻ tấn công đã hành động từ Máy khách (И):
U1.1.2.1.1. Những kẻ tấn công đã vô hiệu hóa hệ thống kiểm soát truy cập của hệ thống thông tin:
U1.1.2.1.1.1. Liên kết: “Mô hình mối đe dọa điển hình. Hệ thống kiểm soát truy cập. U1. Thiết lập phiên trái phép thay mặt cho người dùng hợp pháp".
U1.1.2.1.2. Những kẻ tấn công đã sử dụng các công cụ truy cập hệ thống thông tin tiêu chuẩn
U1.1.2.2. Những kẻ tấn công hoạt động từ các nút khác của mạng dữ liệu, từ đó có thể thiết lập kết nối mạng với Máy chủ (И):
U1.1.2.2.1. Những kẻ tấn công đã vô hiệu hóa hệ thống kiểm soát truy cập của hệ thống thông tin:
U1.1.2.2.1.1. Liên kết: “Mô hình mối đe dọa điển hình. Hệ thống kiểm soát truy cập. U1. Thiết lập phiên trái phép thay mặt cho người dùng hợp pháp".
U1.1.2.2.2. Những kẻ tấn công đã sử dụng các phương tiện không chuẩn để truy cập hệ thống thông tin.
Giải thích U1.1.2.2.2.
Những kẻ tấn công có thể cài đặt máy khách tiêu chuẩn của hệ thống thông tin trên nút của bên thứ ba hoặc có thể sử dụng phần mềm không chuẩn thực hiện các giao thức trao đổi tiêu chuẩn giữa Máy khách và Máy chủ.

U1.2 Các hành động trái phép được thực hiện bên ngoài phiên người dùng.
U1.2.1 Những kẻ tấn công đã thực hiện các hành động trái phép và sau đó thực hiện các thay đổi trái phép đối với nhật ký hoạt động của hệ thống thông tin hoặc các thuộc tính đặc biệt của đối tượng dữ liệu, cho thấy rằng các hành động mà chúng thực hiện được thực hiện bởi người dùng hợp pháp.

U2. Sửa đổi trái phép thông tin được bảo vệ trong quá trình xử lý bởi phần máy chủ của hệ thống thông tin

Sự phân hủy
U2.1. Những kẻ tấn công sửa đổi thông tin được bảo vệ bằng cách sử dụng các công cụ hệ thống thông tin tiêu chuẩn và thực hiện việc này thay mặt cho người dùng hợp pháp.
U2.1.1. Liên kết: “Mô hình mối đe dọa điển hình. Một hệ thống thông tin được xây dựng trên kiến ​​trúc client-server. U1. Thực hiện các hành động trái phép của kẻ tấn công thay mặt cho người dùng hợp pháp".

U2.2. Những kẻ tấn công sửa đổi thông tin được bảo vệ bằng cách sử dụng các cơ chế truy cập dữ liệu không được cung cấp bởi hoạt động bình thường của hệ thống thông tin.
U2.2.1. Kẻ tấn công sửa đổi các tệp chứa thông tin được bảo vệ:
U2.2.1.1. <…>, sử dụng cơ chế xử lý tệp do hệ điều hành cung cấp.
U2.2.1.2. <…> bằng cách kích hoạt khôi phục các tệp từ bản sao lưu bị sửa đổi trái phép.

U2.2.2. Kẻ tấn công sửa đổi thông tin được bảo vệ được lưu trữ trong cơ sở dữ liệu (И):
U2.2.2.1. Những kẻ tấn công vô hiệu hóa hệ thống kiểm soát truy cập DBMS:
U2.2.2.1.1. Liên kết: “Mô hình mối đe dọa điển hình. Hệ thống kiểm soát truy cập. U1. Thiết lập phiên trái phép thay mặt cho người dùng hợp pháp".
U2.2.2.2. Những kẻ tấn công sửa đổi thông tin bằng cách sử dụng giao diện DBMS tiêu chuẩn để truy cập dữ liệu.

U2.3. Những kẻ tấn công sửa đổi thông tin được bảo vệ bằng cách sửa đổi trái phép thuật toán vận hành của phần mềm xử lý thông tin đó.
U2.3.1. Mã nguồn của phần mềm có thể được sửa đổi.
U2.3.1. Mã máy của phần mềm có thể được sửa đổi.

U2.4. Kẻ tấn công sửa đổi thông tin được bảo vệ bằng cách khai thác lỗ hổng trong phần mềm hệ thống thông tin.

U2.5. Kẻ tấn công sửa đổi thông tin được bảo vệ khi nó được truyền giữa các thành phần của phần máy chủ của hệ thống thông tin (ví dụ: máy chủ cơ sở dữ liệu và máy chủ ứng dụng):
U2.5.1. Liên kết: “Mô hình mối đe dọa điển hình. Kết nối mạng. U2. Sửa đổi trái phép dữ liệu được truyền".

MÔ HÌNH MỐI ĐE DỌA ĐIỂN HÌNH. HỆ THỐNG KIỂM SOÁT TRUY CẬP

Đối tượng bảo vệ áp dụng mô hình mối đe dọa (phạm vi)

Đối tượng bảo vệ mà mô hình mối đe dọa này được áp dụng tương ứng với đối tượng bảo vệ của mô hình mối đe dọa: “Mô hình mối đe dọa điển hình. Một hệ thống thông tin được xây dựng trên kiến ​​trúc client-server.”

Trong mô hình mối đe dọa này, hệ thống kiểm soát truy cập của người dùng có nghĩa là một thành phần của hệ thống thông tin thực hiện các chức năng sau:

  1. Nhận dạng người dùng.
  2. Xác thực người dùng.
  3. Ủy quyền của người dùng.
  4. Ghi nhật ký hành động của người dùng.

Các mối đe dọa bảo mật cấp cao nhất

Sự phân hủy
U1. Thiết lập trái phép phiên thay mặt cho người dùng hợp pháp.
U2. Tăng trái phép đặc quyền của người dùng trong hệ thống thông tin.

U1. Thiết lập trái phép phiên thay mặt cho người dùng hợp pháp

Giải thích
Việc phân tách mối đe dọa này nói chung sẽ phụ thuộc vào loại hệ thống nhận dạng và xác thực người dùng được sử dụng.

Trong mô hình này, chỉ hệ thống nhận dạng và xác thực người dùng sử dụng thông tin đăng nhập văn bản và mật khẩu mới được xem xét. Trong trường hợp này, chúng tôi sẽ giả định rằng thông tin đăng nhập của người dùng là thông tin có sẵn công khai mà kẻ tấn công đã biết.

Sự phân hủy
U1.1. <…> do xâm phạm thông tin xác thực:
U1.1.1. Những kẻ tấn công đã xâm phạm thông tin xác thực của người dùng trong khi lưu trữ chúng.
Giải thích U1.1.1.
Ví dụ: thông tin xác thực có thể được viết trên một tờ giấy dán dính vào màn hình.

U1.1.2. Người dùng vô tình hoặc cố ý chuyển thông tin truy cập cho kẻ tấn công.
U1.1.2.1. Người dùng nói to thông tin đăng nhập khi họ bước vào.
U1.1.2.2. Người dùng cố tình chia sẻ thông tin đăng nhập của mình:
U1.1.2.2.1. <…> đến đồng nghiệp làm việc.
Giải thích U1.1.2.2.1.
Ví dụ, để họ có thể thay thế nó khi bị bệnh.

U1.1.2.2.2. <…> cho các nhà thầu của chủ đầu tư thực hiện công việc trên các đối tượng cơ sở hạ tầng thông tin.
U1.1.2.2.3. <…> cho bên thứ ba.
Giải thích U1.1.2.2.3.
Một, nhưng không phải là lựa chọn duy nhất để thực hiện mối đe dọa này là việc những kẻ tấn công sử dụng các phương pháp kỹ thuật xã hội.

U1.1.3. Những kẻ tấn công đã chọn thông tin xác thực bằng các phương pháp vũ phu:
U1.1.3.1. <…> sử dụng cơ chế truy cập tiêu chuẩn.
U1.1.3.2. <…> sử dụng các mã bị chặn trước đó (ví dụ: băm mật khẩu) để lưu trữ thông tin xác thực.

U1.1.4. Những kẻ tấn công đã sử dụng mã độc để chặn thông tin xác thực của người dùng.

U1.1.5. Những kẻ tấn công đã trích xuất thông tin xác thực từ kết nối mạng giữa Máy khách và Máy chủ:
U1.1.5.1. Liên kết: “Mô hình mối đe dọa điển hình. Kết nối mạng. U1. Truy cập trái phép vào dữ liệu được truyền".

U1.1.6. Những kẻ tấn công đã trích xuất thông tin đăng nhập từ hồ sơ của hệ thống giám sát công việc:
U1.1.6.1. <…> hệ thống giám sát video (nếu thao tác gõ phím trên bàn phím được ghi lại trong quá trình hoạt động).
U1.1.6.2. <…> hệ thống giám sát hành động của nhân viên trên máy tính
Giải thích U1.1.6.2.
Một ví dụ về một hệ thống như vậy là Công cụCop.

U1.1.7. Những kẻ tấn công đã xâm phạm thông tin xác thực của người dùng do sai sót trong quá trình truyền tải.
Giải thích U1.1.7.
Ví dụ: gửi mật khẩu ở dạng văn bản rõ ràng qua email.

U1.1.8. Những kẻ tấn công lấy được thông tin xác thực bằng cách theo dõi phiên của người dùng bằng hệ thống quản trị từ xa.

U1.1.9. Những kẻ tấn công đã lấy được thông tin xác thực do bị rò rỉ thông qua các kênh kỹ thuật (TCUI):
U1.1.9.1. Những kẻ tấn công đã quan sát cách người dùng nhập thông tin xác thực từ bàn phím:
U1.1.9.1.1 Những kẻ tấn công ở gần người dùng và tận mắt chứng kiến ​​​​việc nhập thông tin đăng nhập.
Giải thích U1.1.9.1.1
Những trường hợp như vậy bao gồm hành động của đồng nghiệp làm việc hoặc trường hợp bàn phím của người dùng hiển thị với khách truy cập vào tổ chức.

U1.1.9.1.2 Những kẻ tấn công đã sử dụng các phương tiện kỹ thuật bổ sung, chẳng hạn như ống nhòm hoặc máy bay không người lái và nhìn thấy thông tin đăng nhập qua một cửa sổ.
U1.1.9.2. Những kẻ tấn công đã trích xuất thông tin xác thực từ liên lạc vô tuyến giữa bàn phím và thiết bị hệ thống máy tính khi chúng được kết nối qua giao diện vô tuyến (ví dụ: Bluetooth).
U1.1.9.3. Những kẻ tấn công đã chặn thông tin xác thực bằng cách rò rỉ chúng qua kênh nhiễu và bức xạ điện từ giả (PEMIN).
Giải thích U1.1.9.3.
Ví dụ về các cuộc tấn công đây и đây.

U1.1.9.4. Kẻ tấn công đã chặn việc nhập thông tin xác thực từ bàn phím thông qua việc sử dụng các phương tiện kỹ thuật đặc biệt (STS) được thiết kế để bí mật lấy thông tin.
Giải thích U1.1.9.4.
Ví dụ thiết bị.

U1.1.9.5. Những kẻ tấn công đã chặn thông tin nhập vào từ bàn phím bằng cách sử dụng
phân tích tín hiệu Wi-Fi được điều chế bởi quá trình gõ phím của người dùng.
Giải thích U1.1.9.5.
Ví dụ các cuộc tấn công.

U1.1.9.6. Những kẻ tấn công đã chặn thông tin đầu vào từ bàn phím bằng cách phân tích âm thanh gõ phím.
Giải thích U1.1.9.6.
Ví dụ các cuộc tấn công.

U1.1.9.7. Những kẻ tấn công đã chặn việc nhập thông tin xác thực từ bàn phím của thiết bị di động bằng cách phân tích chỉ số gia tốc kế.
Giải thích U1.1.9.7.
Ví dụ các cuộc tấn công.

U1.1.10. <…>, đã được lưu trước đó trên Máy khách.
Giải thích U1.1.10.
Ví dụ: người dùng có thể lưu thông tin đăng nhập và mật khẩu trong trình duyệt để truy cập một trang web cụ thể.

U1.1.11. Những kẻ tấn công đã xâm phạm thông tin đăng nhập do sai sót trong quá trình thu hồi quyền truy cập của người dùng.
Giải thích U1.1.11.
Ví dụ: sau khi một người dùng bị sa thải, tài khoản của anh ta vẫn không bị chặn.

U1.2. <…> bằng cách khai thác lỗ hổng trong hệ thống kiểm soát truy cập.

U2. Nâng cao trái phép đặc quyền của người dùng trong hệ thống thông tin

Sự phân hủy
U2.1 <…> bằng cách thực hiện các thay đổi trái phép đối với dữ liệu chứa thông tin về đặc quyền của người dùng.

U2.2 <…> thông qua việc sử dụng các lỗ hổng trong hệ thống kiểm soát truy cập.

U2.3. <…> do còn bất cập trong quá trình quản lý quyền truy cập của người dùng.
Giải thích U2.3.
Ví dụ 1. Người dùng được cấp nhiều quyền truy cập vào công việc hơn mức cần thiết vì lý do kinh doanh.
Ví dụ 2: Sau khi người dùng được chuyển sang vị trí khác, quyền truy cập đã cấp trước đó sẽ không bị thu hồi.

MÔ HÌNH MỐI ĐE DỌA ĐIỂN HÌNH. MODULE TÍCH HỢP

Đối tượng bảo vệ áp dụng mô hình mối đe dọa (phạm vi)

Mô-đun tích hợp là một tập hợp các đối tượng cơ sở hạ tầng thông tin được thiết kế để tổ chức trao đổi thông tin giữa các hệ thống thông tin.

Xem xét thực tế rằng trong các mạng công ty không phải lúc nào cũng có thể tách biệt rõ ràng hệ thống thông tin này với hệ thống thông tin khác, mô-đun tích hợp cũng có thể được coi là một liên kết kết nối giữa các thành phần trong một hệ thống thông tin.

kiến trúc
Sơ đồ tổng quát của mô-đun tích hợp trông như thế này:

Bảo mật thông tin thanh toán không dùng tiền mặt của ngân hàng. Phần 8 - Các mô hình mối đe dọa điển hình

Mô tả các yếu tố kiến ​​trúc:

  • "Máy chủ trao đổi (SO)" – một nút/dịch vụ/thành phần của hệ thống thông tin thực hiện chức năng trao đổi dữ liệu với hệ thống thông tin khác.
  • "Người hòa giải" – một nút/dịch vụ được thiết kế để tổ chức sự tương tác giữa các hệ thống thông tin, nhưng không phải là một phần của chúng.
    Ví dụ “Người trung gian” có thể có dịch vụ email, bus dịch vụ doanh nghiệp (bus dịch vụ doanh nghiệp / kiến ​​trúc SoA), máy chủ tệp của bên thứ ba, v.v. Nói chung, mô-đun tích hợp có thể không chứa “Trung gian”.
  • "Phần mềm xử lý dữ liệu" – một bộ chương trình thực hiện các giao thức trao đổi dữ liệu và chuyển đổi định dạng.
    Ví dụ: chuyển đổi dữ liệu từ định dạng UFEBS sang định dạng ABS, thay đổi trạng thái tin nhắn trong quá trình truyền, v.v.
  • "Kết nối mạng" tương ứng với đối tượng được mô tả trong mô hình mối đe dọa “Kết nối mạng” tiêu chuẩn. Một số kết nối mạng hiển thị trong sơ đồ trên có thể không tồn tại.

Ví dụ về các mô-đun tích hợp

Sơ đồ 1. Tích hợp ABS và AWS KBR thông qua máy chủ tệp của bên thứ ba

Để thực hiện thanh toán, nhân viên ngân hàng được ủy quyền tải xuống các tài liệu thanh toán điện tử từ hệ thống ngân hàng lõi và lưu chúng vào một tệp (ở định dạng riêng của nó, ví dụ: kết xuất SQL) trên thư mục mạng (...CHIA SẺ) trên máy chủ tệp. Sau đó, tệp này được chuyển đổi bằng cách sử dụng tập lệnh chuyển đổi thành một tập hợp các tệp ở định dạng UFEBS, sau đó được máy trạm CBD đọc.
Sau đó, nhân viên được ủy quyền - người sử dụng nơi làm việc tự động KBR - sẽ mã hóa và ký tên vào các tệp đã nhận và gửi chúng đến hệ thống thanh toán của Ngân hàng Nga.

Khi nhận được các khoản thanh toán từ Ngân hàng Nga, nơi làm việc tự động của KBR sẽ giải mã chúng và kiểm tra chữ ký điện tử, sau đó nó ghi lại chúng dưới dạng một tập hợp các tệp ở định dạng UFEBS trên máy chủ tệp. Trước khi nhập chứng từ thanh toán vào ABS, chúng được chuyển đổi bằng tập lệnh chuyển đổi từ định dạng UFEBS sang định dạng ABS.

Chúng tôi sẽ giả định rằng trong sơ đồ này, ABS hoạt động trên một máy chủ vật lý, máy trạm KBR hoạt động trên một máy tính chuyên dụng và tập lệnh chuyển đổi chạy trên một máy chủ tệp.

Bảo mật thông tin thanh toán không dùng tiền mặt của ngân hàng. Phần 8 - Các mô hình mối đe dọa điển hình

Sự tương ứng của các đối tượng của sơ đồ được xem xét với các thành phần của mô hình mô-đun tích hợp:
“Trao đổi máy chủ từ phía ABS” – Máy chủ ABS.
“Trao đổi máy chủ từ phía AWS KBR” – Máy trạm làm việc KBR.
"Người hòa giải" – máy chủ tập tin của bên thứ ba.
"Phần mềm xử lý dữ liệu" – tập lệnh chuyển đổi.

Sơ đồ 2. Tích hợp ABS và AWS KBR khi đặt thư mục mạng dùng chung có thanh toán trên AWS KBR

Mọi thứ tương tự như Sơ đồ 1, nhưng không sử dụng máy chủ tệp riêng biệt, thay vào đó, một thư mục mạng (...SHARE) chứa các chứng từ thanh toán điện tử được đặt trên máy tính có máy trạm của CBD. Tập lệnh chuyển đổi cũng hoạt động trên máy trạm CBD.

Bảo mật thông tin thanh toán không dùng tiền mặt của ngân hàng. Phần 8 - Các mô hình mối đe dọa điển hình

Sự tương ứng của các đối tượng của sơ đồ được xem xét với các thành phần của mô hình mô-đun tích hợp:
Tương tự như sơ đồ 1 nhưng "Người hòa giải" không được sử dụng.

Sơ đồ 3. Tích hợp ABS và nơi làm việc tự động KBR-N thông qua IBM WebSphera MQ và ký các văn bản điện tử “về phía ABS”

ABS hoạt động trên nền tảng không được CIPF SCAD Signature hỗ trợ. Việc ký các tài liệu điện tử gửi đi được thực hiện trên một máy chủ chữ ký điện tử đặc biệt (ES Server). Máy chủ tương tự sẽ kiểm tra chữ ký điện tử trên các tài liệu đến từ Ngân hàng Nga.

ABS tải tệp có tài liệu thanh toán ở định dạng riêng lên Máy chủ ES.
Máy chủ ES, sử dụng tập lệnh chuyển đổi, chuyển đổi tệp thành các tin nhắn điện tử ở định dạng UFEBS, sau đó các tin nhắn điện tử được ký và truyền tới IBM WebSphere MQ.

Máy trạm KBR-N truy cập IBM WebSphere MQ và nhận các tin nhắn thanh toán đã ký từ đó, sau đó một nhân viên được ủy quyền - người dùng máy trạm KBR - mã hóa chúng và gửi chúng đến hệ thống thanh toán của Ngân hàng Nga.

Khi nhận được thanh toán từ Ngân hàng Nga, nơi làm việc tự động KBR-N sẽ giải mã chúng và xác minh chữ ký điện tử. Các khoản thanh toán được xử lý thành công dưới dạng tin nhắn điện tử được giải mã và ký ở định dạng UFEBS sẽ được chuyển đến IBM WebSphere MQ, từ đó chúng được Máy chủ Chữ ký Điện tử nhận.

Máy chủ chữ ký điện tử xác minh chữ ký điện tử của các khoản thanh toán đã nhận và lưu chúng vào một tệp ở định dạng ABS. Sau đó, nhân viên được ủy quyền - người dùng ABS - tải tệp kết quả lên ABS theo cách thức quy định.

Bảo mật thông tin thanh toán không dùng tiền mặt của ngân hàng. Phần 8 - Các mô hình mối đe dọa điển hình

Sự tương ứng của các đối tượng của sơ đồ được xem xét với các thành phần của mô hình mô-đun tích hợp:
“Trao đổi máy chủ từ phía ABS” – Máy chủ ABS.
“Trao đổi máy chủ từ phía AWS KBR” - máy trạm KBR.
"Người hòa giải" – Máy chủ ES và IBM WebSphere MQ.
"Phần mềm xử lý dữ liệu" – trình chuyển đổi tập lệnh, Chữ ký CIPF SCAD trên Máy chủ ES.

Sơ đồ 4. Tích hợp Máy chủ RBS và hệ thống ngân hàng lõi thông qua API được cung cấp bởi máy chủ trao đổi chuyên dụng

Chúng tôi sẽ giả định rằng ngân hàng sử dụng một số hệ thống ngân hàng từ xa (RBS):

  • "Ngân hàng khách hàng Internet" dành cho cá nhân (IKB FL);
  • "Ngân hàng khách hàng Internet" dành cho pháp nhân (IKB LE).

Để đảm bảo an toàn thông tin, mọi tương tác giữa ABS và hệ thống ngân hàng từ xa đều được thực hiện thông qua máy chủ trao đổi chuyên dụng hoạt động trong khuôn khổ hệ thống thông tin ABS.

Tiếp theo, chúng ta sẽ xem xét quá trình tương tác giữa hệ thống RBS của IKB LE và ABS.
Máy chủ RBS, sau khi nhận được lệnh thanh toán được chứng nhận hợp lệ từ khách hàng, phải tạo một tài liệu tương ứng trong ABS dựa trên lệnh đó. Để thực hiện điều này, bằng cách sử dụng API, nó sẽ truyền thông tin đến máy chủ trao đổi, sau đó máy chủ này sẽ nhập dữ liệu vào ABS.

Khi số dư tài khoản của khách hàng thay đổi, ABS sẽ tạo ra các thông báo điện tử được truyền đến máy chủ ngân hàng từ xa bằng máy chủ sàn giao dịch.

Bảo mật thông tin thanh toán không dùng tiền mặt của ngân hàng. Phần 8 - Các mô hình mối đe dọa điển hình

Sự tương ứng của các đối tượng của sơ đồ được xem xét với các thành phần của mô hình mô-đun tích hợp:
“Trao đổi máy chủ từ phía RBS” – Máy chủ RBS của IKB YUL.
“Trao đổi máy chủ từ phía ABS” - máy chủ trao đổi.
"Người hòa giải" - còn thiếu.
"Phần mềm xử lý dữ liệu" – Các thành phần Máy chủ RBS chịu trách nhiệm sử dụng API máy chủ sàn giao dịch, các thành phần máy chủ sàn giao dịch chịu trách nhiệm sử dụng API ngân hàng lõi.

Các mối đe dọa bảo mật cấp cao nhất

Sự phân hủy
U1. Kẻ tấn công tiêm thông tin sai lệch thông qua mô-đun tích hợp.

U1. Kẻ tấn công tiêm thông tin sai lệch thông qua mô-đun tích hợp

Sự phân hủy
U1.1. Sửa đổi trái phép dữ liệu hợp pháp khi truyền qua kết nối mạng:
Liên kết U1.1.1: “Mô hình mối đe dọa điển hình. Kết nối mạng. U2. Sửa đổi trái phép dữ liệu được truyền".

U1.2. Truyền dữ liệu sai lệch qua các kênh liên lạc thay mặt cho người tham gia trao đổi hợp pháp:
Liên kết U1.1.2: “Mô hình mối đe dọa điển hình. Kết nối mạng. U3. Vi phạm bản quyền dữ liệu truyền đi".

U1.3. Sửa đổi trái phép dữ liệu hợp pháp trong quá trình xử lý trên Máy chủ Exchange hoặc Bên trung gian:
U1.3.1. Liên kết: “Mô hình mối đe dọa điển hình. Một hệ thống thông tin được xây dựng trên kiến ​​trúc client-server. U2. Sửa đổi trái phép thông tin được bảo vệ trong quá trình xử lý bởi phần máy chủ của hệ thống thông tin".

U1.4. Tạo dữ liệu sai trên Máy chủ Exchange hoặc Bên trung gian thay mặt cho người tham gia trao đổi hợp pháp:
U1.4.1. Liên kết: “Mô hình mối đe dọa điển hình. Một hệ thống thông tin được xây dựng trên kiến ​​trúc client-server. U1. Thực hiện các hành động trái phép của những kẻ tấn công thay mặt cho người dùng hợp pháp.”

U1.5. Sửa đổi trái phép dữ liệu khi được xử lý bằng phần mềm xử lý dữ liệu:
U1.5.1. <…> do kẻ tấn công thực hiện các thay đổi trái phép đối với cài đặt (cấu hình) của phần mềm xử lý dữ liệu.
U1.5.2. <…> do kẻ tấn công thực hiện các thay đổi trái phép đối với các tệp thực thi của phần mềm xử lý dữ liệu.
U1.5.3. <…> do kẻ tấn công kiểm soát tương tác phần mềm xử lý dữ liệu.

MÔ HÌNH MỐI ĐE DỌA ĐIỂN HÌNH. HỆ THỐNG BẢO VỆ THÔNG TIN MÃ HÓA

Đối tượng bảo vệ áp dụng mô hình mối đe dọa (phạm vi)

Đối tượng bảo vệ là hệ thống bảo vệ thông tin mật mã được sử dụng để đảm bảo an ninh cho hệ thống thông tin.

kiến trúc
Cơ sở của bất kỳ hệ thống thông tin nào là phần mềm ứng dụng thực hiện chức năng mục tiêu của nó.

Bảo vệ bằng mật mã thường được triển khai bằng cách gọi các nguyên hàm mật mã từ logic nghiệp vụ của phần mềm ứng dụng, được đặt trong các thư viện chuyên dụng - lõi mật mã.

Nguyên thủy mật mã bao gồm các chức năng mật mã cấp thấp, chẳng hạn như:

  • mã hóa/giải mã một khối dữ liệu;
  • tạo/xác minh chữ ký điện tử của khối dữ liệu;
  • tính hàm băm của khối dữ liệu;
  • tạo/tải/tải lên thông tin chính;
  • vv

Logic nghiệp vụ của phần mềm ứng dụng triển khai chức năng cấp cao hơn bằng cách sử dụng các nguyên hàm mật mã:

  • mã hóa tệp bằng khóa của người nhận đã chọn;
  • thiết lập kết nối mạng an toàn;
  • thông báo kết quả kiểm tra chữ ký điện tử;
  • và như vậy.

Sự tương tác giữa logic nghiệp vụ và lõi tiền điện tử có thể được thực hiện:

  • trực tiếp, bằng logic nghiệp vụ gọi các nguyên hàm mật mã từ các thư viện động của nhân mật mã (.DLL cho Windows, .SO cho Linux);
  • trực tiếp, thông qua các giao diện mật mã - các trình bao bọc, ví dụ: MS Crypto API, Kiến trúc mật mã Java, PKCS#11, v.v. Trong trường hợp này, logic nghiệp vụ truy cập vào giao diện mật mã và nó chuyển lệnh gọi sang lõi mật mã tương ứng, trong đó trường hợp này được gọi là nhà cung cấp tiền điện tử. Việc sử dụng các giao diện mật mã cho phép phần mềm ứng dụng tách khỏi các thuật toán mã hóa cụ thể và linh hoạt hơn.

Có hai sơ đồ điển hình để tổ chức lõi mật mã:

Sơ đồ 1 – Lõi tiền điện tử nguyên khối
Bảo mật thông tin thanh toán không dùng tiền mặt của ngân hàng. Phần 8 - Các mô hình mối đe dọa điển hình

Sơ đồ 2 – Tách lõi tiền điện tử
Bảo mật thông tin thanh toán không dùng tiền mặt của ngân hàng. Phần 8 - Các mô hình mối đe dọa điển hình

Các thành phần trong sơ đồ trên có thể là các mô-đun phần mềm riêng lẻ chạy trên một máy tính hoặc các dịch vụ mạng tương tác trong mạng máy tính.

Khi sử dụng các hệ thống được xây dựng theo Sơ đồ 1, phần mềm ứng dụng và lõi mật mã hoạt động trong một môi trường vận hành duy nhất cho công cụ mật mã (SFC), ví dụ: trên cùng một máy tính, chạy cùng một hệ điều hành. Theo quy định, người dùng hệ thống có thể chạy các chương trình khác, bao gồm cả những chương trình chứa mã độc, trong cùng một môi trường hoạt động. Trong những điều kiện như vậy, có nguy cơ rò rỉ khóa mật mã riêng tư nghiêm trọng.

Để giảm thiểu rủi ro, sơ đồ 2 được sử dụng, trong đó lõi tiền điện tử được chia thành hai phần:

  1. Phần đầu tiên cùng với phần mềm ứng dụng hoạt động trong môi trường không đáng tin cậy, có nguy cơ lây nhiễm mã độc. Chúng ta sẽ gọi phần này là “phần mềm”.
  2. Phần thứ hai hoạt động trong môi trường đáng tin cậy trên một thiết bị chuyên dụng có chứa bộ lưu trữ khóa riêng. Từ bây giờ chúng ta sẽ gọi phần này là “phần cứng”.

Việc phân chia lõi tiền điện tử thành các phần phần mềm và phần cứng là rất tùy tiện. Có những hệ thống trên thị trường được xây dựng theo sơ đồ với lõi mật mã được phân chia, nhưng phần “phần cứng” của nó được trình bày dưới dạng hình ảnh máy ảo - HSM ảo (Ví dụ).

Sự tương tác của cả hai phần lõi mật mã diễn ra theo cách mà các khóa mật mã riêng tư không bao giờ được chuyển sang phần phần mềm và do đó, không thể bị đánh cắp bằng mã độc.

Giao diện tương tác (API) và tập hợp các nguyên hàm mật mã được lõi mật mã cung cấp cho phần mềm ứng dụng đều giống nhau trong cả hai trường hợp. Sự khác biệt nằm ở cách chúng được thực hiện.

Do đó, khi sử dụng sơ đồ có lõi mật mã được phân chia, sự tương tác giữa phần mềm và phần cứng được thực hiện theo nguyên tắc sau:

  1. Phần mềm thực hiện các nguyên tắc mã hóa không yêu cầu sử dụng khóa riêng (ví dụ: tính toán hàm băm, xác minh chữ ký điện tử, v.v.).
  2. Các nguyên tắc mã hóa sử dụng khóa riêng (tạo chữ ký điện tử, giải mã dữ liệu, v.v.) được thực hiện bằng phần cứng.

Hãy minh họa công việc của lõi mật mã được phân chia bằng ví dụ về tạo chữ ký điện tử:

  1. Phần phần mềm tính toán hàm băm của dữ liệu đã ký và truyền giá trị này đến phần cứng thông qua kênh trao đổi giữa các lõi mật mã.
  2. Phần cứng, sử dụng khóa riêng và hàm băm, tạo ra giá trị của chữ ký điện tử và truyền nó đến phần mềm thông qua kênh trao đổi.
  3. Phần mềm trả về giá trị nhận được cho phần mềm ứng dụng.

Tính năng kiểm tra tính đúng đắn của chữ ký điện tử

Khi bên nhận nhận được dữ liệu được ký điện tử, bên nhận phải thực hiện một số bước xác minh. Kết quả tích cực của việc kiểm tra chữ ký điện tử chỉ đạt được nếu tất cả các giai đoạn xác minh được hoàn thành thành công.

Giai đoạn 1. Kiểm soát tính toàn vẹn dữ liệu và quyền tác giả dữ liệu.

Nội dung của sân khấu. Chữ ký điện tử của dữ liệu được xác minh bằng thuật toán mã hóa thích hợp. Việc hoàn thành thành công giai đoạn này cho thấy rằng dữ liệu chưa bị sửa đổi kể từ thời điểm nó được ký và chữ ký cũng được tạo bằng khóa riêng tương ứng với khóa chung để xác minh chữ ký điện tử.
Vị trí sân khấu: lõi tiền điện tử.

Giai đoạn 2. Kiểm soát độ tin cậy đối với khóa chung của người ký và kiểm soát thời hạn hiệu lực của khóa riêng của chữ ký điện tử.
Nội dung của sân khấu. Giai đoạn bao gồm hai trạm biến áp trung gian. Đầu tiên là xác định xem khóa chung để xác minh chữ ký điện tử có đáng tin cậy tại thời điểm ký dữ liệu hay không. Thứ hai xác định xem khóa riêng của chữ ký điện tử có hợp lệ tại thời điểm ký dữ liệu hay không. Nhìn chung, thời hạn hiệu lực của các khóa này có thể không trùng nhau (ví dụ: đối với chứng chỉ đủ điều kiện về khóa xác minh chữ ký điện tử). Các phương pháp thiết lập sự tin cậy đối với khóa công khai của người ký được xác định bởi các quy tắc quản lý tài liệu điện tử được các bên tương tác thông qua.
Vị trí sân khấu: phần mềm ứng dụng/lõi mật mã.

Giai đoạn 3. Kiểm soát thẩm quyền của người ký.
Nội dung của sân khấu. Theo các quy tắc quản lý tài liệu điện tử đã được thiết lập, người ta sẽ kiểm tra xem người ký có quyền chứng nhận dữ liệu được bảo vệ hay không. Ví dụ, chúng ta hãy đưa ra một tình huống vi phạm quyền lực. Giả sử có một tổ chức mà tất cả nhân viên đều có chữ ký điện tử. Hệ thống quản lý văn bản điện tử nội bộ nhận đơn hàng từ người quản lý nhưng được ký bằng chữ ký điện tử của người quản lý kho. Theo đó, một tài liệu như vậy không thể được coi là hợp pháp.
Vị trí sân khấu: phần mềm ứng dụng.

Các giả định được đưa ra khi mô tả đối tượng bảo hộ

  1. Các kênh truyền thông tin, ngoại trừ các kênh trao đổi khóa, cũng đi qua phần mềm ứng dụng, API và lõi mật mã.
  2. Thông tin về độ tin cậy đối với khóa công khai và (hoặc) chứng chỉ cũng như thông tin về quyền của chủ sở hữu khóa công khai được lưu trữ trong kho khóa chung.
  3. Phần mềm ứng dụng hoạt động với kho khóa chung thông qua nhân mật mã.

Ví dụ về hệ thống thông tin được bảo vệ bằng CIPF

Để minh họa các sơ đồ được trình bày trước đó, hãy xem xét một hệ thống thông tin giả định và làm nổi bật tất cả các thành phần cấu trúc trên đó.

Mô tả hệ thống thông tin

Bảo mật thông tin thanh toán không dùng tiền mặt của ngân hàng. Phần 8 - Các mô hình mối đe dọa điển hình

Hai tổ chức đã quyết định giới thiệu giải pháp quản lý tài liệu điện tử (EDF) có ý nghĩa pháp lý giữa họ. Để làm điều này, họ đã ký một thỏa thuận trong đó họ quy định rằng các tài liệu sẽ được truyền qua email, đồng thời chúng phải được mã hóa và ký bằng chữ ký điện tử đủ tiêu chuẩn. Các chương trình văn phòng từ gói Microsoft Office 2016 phải được sử dụng làm công cụ tạo và xử lý tài liệu, đồng thời nên sử dụng CIPF CryptoPRO và phần mềm mã hóa CryptoARM làm phương tiện bảo vệ bằng mật mã.

Mô tả cơ sở hạ tầng của tổ chức 1

Tổ chức 1 quyết định sẽ cài đặt phần mềm CIPF CryptoPRO và CryptoARM trên máy trạm của người dùng - một máy tính vật lý. Khóa mã hóa và chữ ký điện tử sẽ được lưu trữ trên phương tiện khóa ruToken, hoạt động ở chế độ khóa có thể truy xuất được. Người dùng sẽ chuẩn bị các tài liệu điện tử cục bộ trên máy tính của mình, sau đó mã hóa, ký và gửi chúng bằng ứng dụng email khách được cài đặt cục bộ.

Mô tả cơ sở hạ tầng của tổ chức 2

Tổ chức 2 quyết định chuyển chức năng mã hóa và chữ ký điện tử sang một máy ảo chuyên dụng. Trong trường hợp này, tất cả các hoạt động mã hóa sẽ được thực hiện tự động.

Để thực hiện việc này, hai thư mục mạng được sắp xếp trên máy ảo chuyên dụng: “...In”, “...Out”. Các tệp đang mở nhận được từ đối tác sẽ tự động được đặt trong thư mục mạng “…Trong”. Các tập tin này sẽ được giải mã và chữ ký điện tử sẽ được xác minh.

Người dùng sẽ đặt các tập tin vào thư mục “…Out” cần được mã hóa, ký tên và gửi cho đối tác. Người dùng sẽ tự chuẩn bị các tập tin trên máy trạm của mình.
Để thực hiện chức năng mã hóa và chữ ký điện tử, phần mềm CIPF CryptoPRO, CryptoARM và ứng dụng email được cài đặt trên máy ảo. Việc quản lý tự động tất cả các thành phần của máy ảo sẽ được thực hiện bằng cách sử dụng các tập lệnh do quản trị viên hệ thống phát triển. Công việc của các tập lệnh được ghi vào tệp nhật ký.

Khóa mật mã cho chữ ký điện tử sẽ được đặt trên một mã thông báo có khóa JaCarta GOST không thể truy xuất được mà người dùng sẽ kết nối với máy tính cục bộ của mình.

Token sẽ được chuyển tiếp đến máy ảo bằng phần mềm USB-over-IP chuyên dụng được cài đặt trên máy trạm của người dùng và trên máy ảo.

Đồng hồ hệ thống trên máy trạm của người dùng ở tổ chức 1 sẽ được điều chỉnh thủ công. Đồng hồ hệ thống của máy ảo chuyên dụng trong Tổ chức 2 sẽ được đồng bộ hóa với đồng hồ hệ thống ảo hóa, sau đó sẽ được đồng bộ hóa qua Internet với các máy chủ thời gian công cộng.

Xác định các yếu tố cấu trúc của CIPF
Dựa trên mô tả ở trên về cơ sở hạ tầng CNTT, chúng tôi sẽ nêu bật các thành phần cấu trúc của CIPF và viết chúng vào bảng.

Bảng - Sự tương ứng của các phần tử mô hình CIPF với các phần tử hệ thống thông tin

Tên mặt hàng
Tổ chức 1
Tổ chức 2

Phần mềm ứng dụng
Phần mềm CryptoARM
Phần mềm CryptoARM

Một phần phần mềm của lõi tiền điện tử
CIPF CryptoPRO CSP
CIPF CryptoPRO CSP

Phần cứng lõi tiền điện tử
Không
JaCarta GOST

API
API tiền điện tử MS
API tiền điện tử MS

Kho khóa công khai
Máy trạm của người dùng:
- ổ cứng;
- kho chứng chỉ Windows tiêu chuẩn.
Giám sát viên:
- Ổ cứng.

Máy ảo:
- ổ cứng;
- kho chứng chỉ Windows tiêu chuẩn.

Lưu trữ khóa riêng
Nhà cung cấp khóa ruToken hoạt động ở chế độ khóa có thể truy xuất
Nhà cung cấp khóa JaCarta GOST hoạt động ở chế độ khóa không thể tháo rời

Kênh trao đổi khóa công khai
Máy trạm của người dùng:
- ĐẬP.

Giám sát viên:
- ĐẬP.

Máy ảo:
- ĐẬP.

Kênh trao đổi khóa riêng
Máy trạm của người dùng:
- Xe buýt USB;
- ĐẬP.
Không

Kênh trao đổi giữa các lõi tiền điện tử
thiếu (không có phần cứng lõi tiền điện tử)
Máy trạm của người dùng:
- Xe buýt USB;
- ĐẬP;
— Mô-đun phần mềm USB-over-IP;
- giao diện mạng.

Mạng lưới công ty của tổ chức 2.

Giám sát viên:
- ĐẬP;
- giao diện mạng.

Máy ảo:
- giao diện mạng;
- ĐẬP;
— Mô-đun phần mềm USB-over-IP.

Kênh dữ liệu mở
Máy trạm của người dùng:
- phương tiện đầu vào-đầu ra;
- ĐẬP;
- Ổ cứng.
Máy trạm của người dùng:
- phương tiện đầu vào-đầu ra;
- ĐẬP;
- ổ cứng;
- giao diện mạng.

Mạng lưới công ty của tổ chức 2.

Giám sát viên:
- giao diện mạng;
- ĐẬP;
- Ổ cứng.

Máy ảo:
- giao diện mạng;
- ĐẬP;
- Ổ cứng.

Kênh trao đổi dữ liệu an toàn
Internet.

Mạng lưới công ty của tổ chức 1.

Máy trạm của người dùng:
- ổ cứng;
- ĐẬP;
- giao diện mạng.

Internet.

Mạng lưới công ty của tổ chức 2.

Giám sát viên:
- giao diện mạng;
- ĐẬP;
- Ổ cứng.

Máy ảo:
- giao diện mạng;
- ĐẬP;
- Ổ cứng.

Kênh thời gian
Máy trạm của người dùng:
- phương tiện đầu vào-đầu ra;
- ĐẬP;
- hệ thống hẹn giờ.

Internet.
Mạng lưới tổ chức doanh nghiệp 2,

Giám sát viên:
- giao diện mạng;
- ĐẬP;
- hệ thống hẹn giờ.

Máy ảo:
- ĐẬP;
- hệ thống hẹn giờ.

Kênh truyền lệnh điều khiển
Máy trạm của người dùng:
- phương tiện đầu vào-đầu ra;
- ĐẬP.

(Giao diện người dùng đồ họa của phần mềm CryptoARM)

Máy ảo:
- ĐẬP;
- Ổ cứng.

(Kịch bản tự động hóa)

Kênh nhận kết quả công việc
Máy trạm của người dùng:
- phương tiện đầu vào-đầu ra;
- ĐẬP.

(Giao diện người dùng đồ họa của phần mềm CryptoARM)

Máy ảo:
- ĐẬP;
- Ổ cứng.

(Tệp nhật ký của tập lệnh tự động hóa)

Các mối đe dọa bảo mật cấp cao nhất

Giải thích

Các giả định được đưa ra khi phân tích các mối đe dọa:

  1. Các thuật toán mã hóa mạnh được sử dụng.
  2. Các thuật toán mật mã được sử dụng một cách an toàn ở các chế độ hoạt động chính xác (ví dụ: ECB không được sử dụng để mã hóa khối lượng dữ liệu lớn, tải trọng cho phép trên khóa được tính đến, v.v.).
  3. Những kẻ tấn công biết tất cả các thuật toán, giao thức và khóa công khai được sử dụng.
  4. Kẻ tấn công có thể đọc tất cả dữ liệu được mã hóa.
  5. Những kẻ tấn công có thể tái tạo bất kỳ thành phần phần mềm nào trong hệ thống.

Sự phân hủy

U1. Xâm phạm các khóa mật mã riêng tư.
U2. Mã hóa dữ liệu giả mạo thay mặt cho người gửi hợp pháp.
U3. Giải mã dữ liệu được mã hóa bởi những người không phải là người nhận dữ liệu hợp pháp (kẻ tấn công).
U4. Tạo chữ ký điện tử của người ký hợp pháp dưới dữ liệu sai lệch.
U5. Thu được kết quả tích cực từ việc kiểm tra chữ ký điện tử của dữ liệu giả mạo.
U6. Chấp nhận sai văn bản điện tử để thực hiện do vướng mắc trong việc tổ chức quản lý văn bản điện tử.
U7. Truy cập trái phép vào dữ liệu được bảo vệ trong quá trình CIPF xử lý chúng.

U1. Xâm phạm các khóa mật mã riêng tư

U1.1. Lấy khóa riêng từ kho lưu trữ khóa riêng.

U1.2. Lấy khóa riêng từ các đối tượng trong môi trường hoạt động của công cụ mật mã, nơi khóa đó có thể cư trú tạm thời.
Giải thích U1.2.

Các đối tượng có thể lưu trữ tạm thời khóa riêng sẽ bao gồm:

  1. ĐẬP,
  2. Hồ sơ tạm thời,
  3. trao đổi tập tin,
  4. tập tin ngủ đông,
  5. các tệp chụp nhanh về trạng thái “nóng” của máy ảo, bao gồm các tệp nội dung trong RAM của các máy ảo bị tạm dừng.

U1.2.1. Trích xuất khóa riêng từ RAM đang hoạt động bằng cách đóng băng các mô-đun RAM, xóa chúng rồi đọc dữ liệu (tấn công đóng băng).
Giải thích U1.2.1.
Ví dụ các cuộc tấn công.

U1.3. Lấy khóa riêng từ kênh trao đổi khóa riêng.
Giải thích U1.3.
Một ví dụ về việc thực hiện mối đe dọa này sẽ được đưa ra dưới đây.

U1.4. Sửa đổi trái phép lõi mật mã, do đó, kẻ tấn công có thể biết được khóa riêng tư.

U1.5. Xâm phạm khóa riêng do sử dụng các kênh rò rỉ thông tin kỹ thuật (TCIL).
Giải thích U1.5.
Ví dụ các cuộc tấn công.

U1.6. Xâm phạm khóa riêng do sử dụng các phương tiện kỹ thuật đặc biệt (STS) được thiết kế để lấy thông tin một cách bí mật (“lỗi”).

U1.7. Xâm phạm các khóa riêng trong quá trình lưu trữ chúng bên ngoài CIPF.
Giải thích U1.7.
Ví dụ: người dùng lưu trữ phương tiện chính của mình trong ngăn kéo trên máy tính để bàn, từ đó kẻ tấn công có thể dễ dàng lấy chúng.

U2. Mã hóa dữ liệu giả mạo thay mặt cho người gửi hợp pháp

Giải thích
Mối đe dọa này chỉ được coi là đối với các sơ đồ mã hóa dữ liệu có xác thực người gửi. Ví dụ về các chương trình như vậy được nêu trong các khuyến nghị tiêu chuẩn hóa R 1323565.1.004-2017 “Công nghệ thông tin. Bảo vệ thông tin mật mã. Lược đồ tạo khóa chung có xác thực dựa trên khóa chung". Đối với các sơ đồ mã hóa khác, mối đe dọa này không tồn tại vì mã hóa được thực hiện trên khóa chung của người nhận và những kẻ tấn công thường biết đến chúng.

Sự phân hủy
U2.1. Xâm phạm khóa riêng của người gửi:
U2.1.1. Liên kết: “Mô hình mối đe dọa điển hình. Hệ thống bảo vệ thông tin mật mã.У1. Xâm phạm các khóa mật mã riêng tư".

U2.2. Thay thế dữ liệu đầu vào trong kênh trao đổi dữ liệu mở.
Ghi chú U2.2.
Ví dụ về việc thực hiện mối đe dọa này được đưa ra dưới đây. đây и đây.

U3. Giải mã dữ liệu được mã hóa bởi những người không phải là người nhận dữ liệu hợp pháp (kẻ tấn công)

Sự phân hủy
U3.1. Xâm phạm khóa riêng của người nhận dữ liệu được mã hóa.
Liên kết U3.1.1: “Mô hình mối đe dọa điển hình. Hệ thống bảo vệ thông tin mật mã. U1. Xâm phạm các khóa mật mã riêng tư".

U3.2. Thay thế dữ liệu được mã hóa trong kênh trao đổi dữ liệu an toàn.

U4. Tạo chữ ký điện tử của người ký hợp pháp dưới dữ liệu sai

Sự phân hủy
U4.1. Xâm phạm khóa riêng của chữ ký điện tử của người ký hợp pháp.
Liên kết U4.1.1: “Mô hình mối đe dọa điển hình. Hệ thống bảo vệ thông tin mật mã. U1. Xâm phạm các khóa mật mã riêng tư".

U4.2. Thay thế dữ liệu đã ký trong kênh trao đổi dữ liệu mở.
Lưu ý U4.2.
Ví dụ về việc thực hiện mối đe dọa này được đưa ra dưới đây. đây и đây.

U5. Thu được kết quả khả quan từ việc kiểm tra chữ ký điện tử của dữ liệu giả mạo

Sự phân hủy
U5.1. Kẻ tấn công chặn một tin nhắn trong kênh để truyền kết quả công việc về kết quả tiêu cực của việc kiểm tra chữ ký điện tử và thay thế nó bằng một tin nhắn có kết quả tích cực.

U5.2. Những kẻ tấn công tấn công sự tin tưởng trong việc ký chứng chỉ (SCRIPT - tất cả các thành phần đều bắt buộc):
U5.2.1. Kẻ tấn công tạo khóa chung và khóa riêng cho chữ ký điện tử. Nếu hệ thống sử dụng chứng chỉ khóa chữ ký điện tử thì hệ thống sẽ tạo chứng chỉ chữ ký điện tử giống nhất có thể với chứng chỉ của người gửi dữ liệu dự định có thông điệp mà họ muốn giả mạo.
U5.2.2. Những kẻ tấn công thực hiện các thay đổi trái phép đối với kho khóa công khai, đưa ra khóa công khai mà chúng tạo ra mức độ tin cậy và quyền hạn cần thiết.
U5.2.3. Kẻ tấn công ký dữ liệu sai bằng khóa chữ ký điện tử được tạo trước đó và chèn nó vào kênh trao đổi dữ liệu an toàn.

U5.3. Kẻ tấn công thực hiện cuộc tấn công bằng cách sử dụng khóa chữ ký điện tử đã hết hạn của người ký hợp pháp (SCRIPT - tất cả các thành phần đều bắt buộc):
U5.3.1. Kẻ tấn công xâm phạm các khóa riêng đã hết hạn (hiện không hợp lệ) của chữ ký điện tử của người gửi hợp pháp.
U5.3.2. Những kẻ tấn công thay thế thời gian trong kênh truyền thời gian bằng thời gian mà các khóa bị xâm phạm vẫn còn hiệu lực.
U5.3.3. Kẻ tấn công ký dữ liệu sai bằng khóa chữ ký điện tử đã bị xâm phạm trước đó và đưa dữ liệu đó vào kênh trao đổi dữ liệu an toàn.

U5.4. Những kẻ tấn công thực hiện một cuộc tấn công bằng cách sử dụng các khóa chữ ký điện tử bị xâm phạm của người ký hợp pháp (SCRIPT - tất cả các thành phần đều bắt buộc):
U5.4.1. Kẻ tấn công tạo một bản sao của kho khóa công khai.
U5.4.2. Những kẻ tấn công xâm phạm khóa riêng của một trong những người gửi hợp pháp. Anh ta nhận thấy sự xâm phạm, thu hồi khóa và thông tin về việc thu hồi khóa được lưu trữ trong kho khóa chung.
U5.4.3. Những kẻ tấn công thay thế kho khóa công khai bằng một kho khóa đã sao chép trước đó.
U5.4.4. Kẻ tấn công ký dữ liệu sai bằng khóa chữ ký điện tử đã bị xâm phạm trước đó và đưa dữ liệu đó vào kênh trao đổi dữ liệu an toàn.

U5.5. <…> do có sai sót trong quá trình thực hiện giai đoạn 2 và 3 của xác minh chữ ký điện tử:
Giải thích U5.5.
Một ví dụ về việc thực hiện mối đe dọa này được đưa ra dưới đây.

U5.5.1. Kiểm tra độ tin cậy trong chứng chỉ khóa chữ ký điện tử chỉ bằng sự hiện diện của độ tin cậy trong chứng chỉ được ký mà không cần kiểm tra CRL hoặc OCSP.
Giải thích U5.5.1.
Ví dụ triển khai các mối đe dọa.

U5.5.2. Khi xây dựng chuỗi tin cậy cho chứng chỉ, cơ quan cấp chứng chỉ không được phân tích
Giải thích U5.5.2.
Một ví dụ về cuộc tấn công chống lại chứng chỉ SSL/TLS.
Những kẻ tấn công đã mua chứng chỉ hợp pháp cho e-mail của chúng. Sau đó, họ đã tạo một chứng chỉ trang web lừa đảo và ký vào đó bằng chứng chỉ của họ. Nếu thông tin đăng nhập không được kiểm tra, thì khi kiểm tra chuỗi tin cậy, kết quả sẽ đúng và theo đó, chứng chỉ gian lận cũng sẽ đúng.

U5.5.3. Khi xây dựng chuỗi tin cậy chứng chỉ, chứng chỉ trung gian không được kiểm tra để thu hồi.

U5.5.4. CRL được cập nhật ít thường xuyên hơn so với chúng được cấp bởi cơ quan chứng nhận.

U5.5.5. Quyết định tin tưởng chữ ký điện tử được đưa ra trước khi nhận được phản hồi OCSP về trạng thái của chứng chỉ, được gửi theo yêu cầu được đưa ra muộn hơn thời điểm chữ ký được tạo hoặc sớm hơn CRL tiếp theo sau khi chữ ký được tạo.
Giải thích U5.5.5.
Trong quy định của hầu hết các CA, thời điểm thu hồi chứng chỉ được coi là thời điểm cấp CRL gần nhất chứa thông tin về việc thu hồi chứng chỉ.

U5.5.6. Khi nhận dữ liệu đã ký, chứng chỉ thuộc về người gửi không được kiểm tra.
Giải thích U5.5.6.
Ví dụ về một cuộc tấn công. Liên quan đến chứng chỉ SSL: sự tương ứng của địa chỉ máy chủ được gọi với giá trị của trường CN trong chứng chỉ có thể không được kiểm tra.
Ví dụ về một cuộc tấn công. Những kẻ tấn công đã xâm phạm khóa chữ ký điện tử của một trong những người tham gia hệ thống thanh toán. Sau đó, họ đột nhập vào mạng của một người tham gia khác và thay mặt anh ta gửi chứng từ thanh toán được ký bằng khóa bị xâm phạm đến máy chủ thanh toán của hệ thống thanh toán. Nếu máy chủ chỉ phân tích độ tin cậy và không kiểm tra tính tuân thủ thì các tài liệu gian lận sẽ được coi là hợp pháp.

U6. Chấp nhận sai văn bản điện tử để thực hiện do vướng mắc trong việc tổ chức quản lý văn bản điện tử.

Sự phân hủy
U6.1. Bên nhận không phát hiện sự trùng lặp của hồ sơ nhận được.
Giải thích U6.1.
Ví dụ về một cuộc tấn công. Những kẻ tấn công có thể chặn tài liệu đang được truyền đến người nhận, ngay cả khi nó được bảo vệ bằng mật mã, sau đó liên tục gửi tài liệu đó qua kênh truyền dữ liệu an toàn. Nếu người nhận không xác định được các bản sao thì tất cả các tài liệu nhận được sẽ được coi và xử lý như các tài liệu khác nhau.

U7. Truy cập trái phép vào dữ liệu được bảo vệ trong quá trình xử lý của CIPF

Sự phân hủy

U7.1. <…> do rò rỉ thông tin qua các kênh bên (tấn công kênh bên).
Giải thích U7.1.
Ví dụ các cuộc tấn công.

U7.2. <…> do vô hiệu hóa biện pháp bảo vệ chống truy cập trái phép vào thông tin được xử lý trên CIPF:
U7.2.1. Hoạt động của CIPF vi phạm các yêu cầu được mô tả trong tài liệu dành cho CIPF.

U7.2.2. <…>, được thực hiện do có lỗ hổng trong:
U7.2.2.1. <…> phương tiện bảo vệ chống truy cập trái phép.
U7.2.2.2. <…> Bản thân CIPF.
U7.2.2.3. <…> môi trường hoạt động của công cụ mật mã.

Ví dụ về các cuộc tấn công

Các kịch bản được thảo luận dưới đây rõ ràng có chứa các lỗi bảo mật thông tin và chỉ dùng để minh họa các cuộc tấn công có thể xảy ra.

Kịch bản 1. Ví dụ về việc triển khai các mối đe dọa U2.2 và U4.2.

Mô tả đối tượng
Bảo mật thông tin thanh toán không dùng tiền mặt của ngân hàng. Phần 8 - Các mô hình mối đe dọa điển hình

Phần mềm AWS KBR và CIPF SCAD Signature được cài đặt trên máy tính vật lý không được kết nối với mạng máy tính. FKN vdToken được sử dụng làm vật mang chìa khóa ở chế độ làm việc với chìa khóa không thể tháo rời.

Các quy định giải quyết giả định rằng chuyên gia giải quyết từ máy tính làm việc của mình tải xuống các tin nhắn điện tử ở dạng văn bản rõ ràng (sơ đồ của máy trạm KBR cũ) từ một máy chủ tệp bảo mật đặc biệt, sau đó ghi chúng vào ổ flash USB có thể chuyển nhượng và chuyển chúng đến máy trạm KBR, nơi chúng được mã hóa và ký hiệu. Sau đó, chuyên gia chuyển các tin nhắn điện tử an toàn đến phương tiện bị xa lánh, sau đó, thông qua máy tính làm việc của mình, ghi chúng vào một máy chủ tệp, từ đó chúng đến UTA và sau đó đến hệ thống thanh toán của Ngân hàng Nga.

Trong trường hợp này, các kênh trao đổi dữ liệu mở và được bảo vệ sẽ bao gồm: máy chủ tệp, máy tính làm việc của chuyên gia và phương tiện truyền thông xa lạ.

Tấn công
Những kẻ tấn công trái phép cài đặt hệ thống điều khiển từ xa trên máy tính làm việc của chuyên gia và tại thời điểm viết lệnh thanh toán (tin nhắn điện tử) sang phương tiện có thể chuyển nhượng, hãy thay thế nội dung của một trong số chúng bằng văn bản rõ ràng. Chuyên gia chuyển các lệnh thanh toán đến nơi làm việc tự động của KBR, ký và mã hóa chúng mà không nhận thấy sự thay thế (ví dụ: do số lượng lệnh thanh toán lớn trên chuyến bay, do mệt mỏi, v.v.). Sau đó, lệnh thanh toán giả sau khi vượt qua dây chuyền công nghệ sẽ xâm nhập vào hệ thống thanh toán của Ngân hàng Nga.

Kịch bản 2. Ví dụ về việc triển khai các mối đe dọa U2.2 và U4.2.

Mô tả đối tượng
Bảo mật thông tin thanh toán không dùng tiền mặt của ngân hàng. Phần 8 - Các mô hình mối đe dọa điển hình

Một máy tính có máy trạm KBR, SCAD Signature được cài đặt và nhà cung cấp khóa được kết nối FKN vdToken hoạt động trong phòng chuyên dụng mà không cần nhân viên truy cập.
Chuyên gia tính toán kết nối với máy trạm CBD ở chế độ truy cập từ xa thông qua giao thức RDP.

Tấn công
Những kẻ tấn công chặn các chi tiết mà chuyên gia tính toán sử dụng để kết nối và làm việc với máy trạm CBD (ví dụ: thông qua mã độc trên máy tính của anh ta). Sau đó, họ thay mặt anh ta kết nối và gửi lệnh thanh toán giả đến hệ thống thanh toán của Ngân hàng Nga.

Tình huống 3. Ví dụ về triển khai mối đe dọa U1.3.

Mô tả đối tượng
Bảo mật thông tin thanh toán không dùng tiền mặt của ngân hàng. Phần 8 - Các mô hình mối đe dọa điển hình

Hãy xem xét một trong các phương án giả định để triển khai mô-đun tích hợp ABS-KBR cho sơ đồ mới (AWS KBR-N), trong đó chữ ký điện tử của tài liệu gửi đi xảy ra ở phía ABS. Trong trường hợp này, chúng tôi sẽ giả định rằng ABS hoạt động trên cơ sở hệ điều hành không được hỗ trợ bởi Chữ ký CIPF SKAD và theo đó, chức năng mật mã được chuyển sang một máy ảo riêng biệt - tích hợp “ABS-KBR” mô-đun.
Mã thông báo USB thông thường hoạt động ở chế độ khóa có thể truy xuất được sử dụng làm vật mang khóa. Khi kết nối phương tiện chính với bộ ảo hóa, hóa ra là không có cổng USB trống trong hệ thống, do đó, người ta đã quyết định kết nối mã thông báo USB qua bộ chia USB mạng và cài đặt ứng dụng khách USB-over-IP trên thiết bị ảo máy sẽ giao tiếp với hub.

Tấn công
Những kẻ tấn công đã chặn khóa riêng của chữ ký điện tử từ kênh liên lạc giữa bộ chia USB và bộ ảo hóa (dữ liệu được truyền ở dạng văn bản rõ ràng). Có được khóa riêng, những kẻ tấn công đã tạo một lệnh thanh toán giả, ký vào đó bằng chữ ký điện tử và gửi đến nơi làm việc tự động KBR-N để thực thi.

Tình huống 4. Ví dụ về việc triển khai các mối đe dọa U5.5.

Mô tả đối tượng
Hãy xem xét mạch tương tự như trong kịch bản trước. Chúng tôi sẽ giả định rằng các tin nhắn điện tử đến từ máy trạm KBR-N sẽ nằm trong thư mục …SHAREIn và những tin nhắn được gửi đến máy trạm KBR-N và xa hơn tới hệ thống thanh toán của Ngân hàng Nga sẽ chuyển đến …SHAREout.
Chúng tôi cũng sẽ giả định rằng khi triển khai mô-đun tích hợp, danh sách thu hồi chứng chỉ chỉ được cập nhật khi khóa mật mã được cấp lại và các tin nhắn điện tử nhận được trong thư mục …SHAREIn chỉ được kiểm tra để kiểm soát tính toàn vẹn và kiểm soát độ tin cậy trong khóa chung của chữ ký điện tử.

Tấn công

Những kẻ tấn công, sử dụng các khóa bị đánh cắp trong tình huống trước, đã ký một lệnh thanh toán giả chứa thông tin về việc nhận tiền vào tài khoản của khách hàng lừa đảo và đưa nó vào kênh trao đổi dữ liệu an toàn. Vì không có xác minh rằng lệnh thanh toán đã được Ngân hàng Nga ký nên lệnh thanh toán này được chấp nhận thực hiện.

Nguồn: www.habr.com

Thêm một lời nhận xét