Tiêu chuẩn TCVN 12043:2017 Khuôn dạng dữ liệu trao đổi mô tả sự cố an toàn mạng

TIÊU CHUẨN QUỐC GIA

TCVN 12043:2017

KHUÔN DẠNG DỮ LIỆU TRAO ĐỔI MÔ TẢ SỰ CỐ AN TOÀN MẠNG

The incident object description exchange format

Lời nói đầu

TCVN 12043:2017 được xây dựng trên cơ sở tài liệu RFC 5070 và RFC 6684 của Nhóm Đặc trách về kỹ thuật Internet (IETF).

TCVN 12043:2017 do Học viện Công nghệ Bưu chính Viễn thông và Trung tâm ứng cứu khẩn cấp máy tính Việt Nam phối hợp biên soạn, Bộ Thông tin và Truyền thông đề nghị, Tổng cục Tiêu chuẩn Đo lường Chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố.

KHUÔN DẠNG DỮ LIỆU TRAO ĐỔI MÔ TẢ SỰ CỐ AN TOÀN MẠNG

The incident object description exchange format

1  Phạm vi áp dụng

Tiêu chuẩn này quy định khuôn dạng dữ liệu trao đổi mô tả sự cố (IODEF), là khuôn dạng biểu diễn thông tin về an toàn mạng máy tính thường được trao đổi bởi các đơn vị ứng cứu sự cố an toàn máy tính (CSIRT). Tiêu chuẩn này mô tả mô hình dữ liệu cho IODEF và cung cấp mô hình dữ liệu liên quan được quy định theo lược đồ XML

Tiêu chuẩn này có thể áp dụng để trao đổi thông tin về sự cố giữa các cơ quan, tổ chức, doanh nghiệp tham gia hoạt động ứng cứu sự cố có sự điều phối tại Việt Nam.

2  Tài liệu viện dẫn

Các tài liệu viện dẫn sau đây là cần thiết để áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi năm công bố thì áp dụng phiên bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất (bao gồm cả các sửa đổi, bổ sung).

TCVN ISO 8601:2004 (ISO 8601:2000), Phần tử dữ liệu và dạng thức trao đổi - Trao đổi thông tin - Biểu diễn thời gian;

RFC 6684, Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF) (Hướng dẫn và mẫu cho xác định phần mở rộng của Khuôn dạng dữ liệu phần tử mô tả sự cố);

RFC 4519, Schema for User Applications (Lược đồ cho ứng dụng người dùng);

RFC 2282, Internet Message Format (Khuôn dạng thông điệp internet);

RFC 4646, Tags for Identifying of Languages (Thẻ nhận diện ngôn ngữ);

RFC 3552, Guidelines for Writing RFC Text on Security Considerations (Hướng dẫn viết phần Xem xét an toàn);

RFC 5706, Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions (Hướng dẫn xem xét quản lý và vận hành các giao thức mới và các mở rộng của giao thức);

RFC 6545, Real-time Inter-network Defense (RID) (Bảo vệ liên mạng theo thời gian thực).

3  Thuật ngữ và chữ viết tắt

Tiêu chuẩn này sử dụng các thuật ngữ và chữ viết tắt như sau:

4   Tổng quan

4.1  Giới thiệu

Các cơ quan, tổ chức luôn có nhu cầu lưu trữ và trao đổi các thông tin về sự cố với các tổ chức khác nhằm làm giảm nhẹ thiệt hại từ hoạt động tấn công phá hoại và nắm bắt được các mối đe dọa tiềm tàng. Công việc điều phối đòi hỏi phải làm việc với các ISP để lọc lưu lượng tấn công, giải quyết vấn đề tắc nghẽn mạng hay chia sẻ danh sách các địa chỉ IP đã được theo dõi và xác định là nguy hiểm trong một mạng lưới các cơ quan tổ chức.

Mục đích quan trọng hơn của IODEF là tăng cường khả năng hành động của các CSIRT. Sự chấp nhận của cộng đồng đối với IODEF đã mang đến một khả năng tốt hơn để giải quyết các sự cố và các nhận biết tình huống thông qua cộng tác và chia sẻ dữ liệu. Khuôn dạng có cấu trúc cung cấp bởi IODEF cho phép:

- Tăng tính tự động hóa trong quá trình xử lý dữ liệu sự cố, do tài nguyên của các bộ phân tích an toàn thông tin phục vụ cho việc phân tích văn bản dạng tự do sẽ giảm đi.

- Giảm công sức cho việc chuẩn hóa các dữ liệu tương tự (ngay cả khi được cấu trúc ở mức độ cao) từ các nguồn khác nhau.

- Một khuôn dạng chung mà trên đó xây dựng các công cụ tương tác hỗ trợ cho việc xử lý sự cố và phân tích tiếp theo, đặc biệt khi dữ liệu đến từ nhiều khu vực khác nhau.

Điều phối giữa các CSIRT không hoàn toàn là một vấn đề công nghệ. Có rất nhiều xem xét mang tính thủ tục, tin cậy, và pháp lý có thể ngăn cản tổ chức trong việc chia sẻ thông tin. IODEF không tập trung vào xử lý các vấn đề này. Mặc dù vậy, việc triển khai áp dụng IODEF sẽ cần phải xem xét yếu tố này rộng hơn. Điều 6 và Điều 11 của Tiêu chuẩn này mô tả mô hình dữ liệu IODEF dạng văn bản và lược đồ XML. Các kiểu dữ liệu được sử dụng bởi mô hình dữ liệu được đề cập ở Điều 5 của tiêu chuẩn. Các vấn đề về triển khai, giải quyết phần mở rộng, và các vấn đề quốc tế liên quan đến mô hình dữ liệu sẽ lần lượt được đề cập trong Điều 7; Điều 8 và Điều 9. Các ví dụ được liệt kê trong Điều 10. Điều 4 của tiêu chuẩn cung cấp nền tảng cho các IODEF, và Điều 12 dẫn chứng các khuyến nghị trong vấn đề an toàn.

4.2  Ký pháp

Mô hình dữ liệu IODEF chuẩn được xác định với dạng văn bản trong Điều 6 của tiêu chuẩn và lược đồ XML trong Điều 11. Để giúp cho việc hiểu các yếu tố dữ liệu, Điều 6 cũng mô tả mô hình thông tin cơ bản bằng cách sử dụng UML.

Để cho dễ hiểu trong tiêu chuẩn này, thuật ngữ "tài liệu XML" sẽ được sử dụng để khi đề cập một cách tổng quan đến bất cứ trường hợp của tài liệu XML nào. Thuật ngữ "tài liệu IODEF" sẽ được sử dụng để đề cập đến các thành phần và các thuộc tính cụ thể của lược đồ IODEF. Cuối cùng, thuật ngữ "lớp" và "thành phần" sẽ được sử dụng thay thế cho nhau để đề cập hoặc là thành phần dữ liệu tương ứng trong thông tin hoặc là các mô hình dữ liệu.

4.3  Giới thiệu mô hình dữ liệu IODEF

Mô hình dữ liệu IODEF là một biểu diễn dữ liệu cung cấp một khung để chia sẻ thông tin trao đổi chung của các CSIRT về sự cố an toàn máy tính. Một số xem xét đã được đề ra trong thiết kế của mô hình dữ liệu:

Mô hình dữ liệu cung cấp như là một khuôn dạng truyền tải. Vì vậy, biểu diễn cụ thể của nó không phải là biểu diễn tối ưu cho việc lưu trữ trên ổ cứng, lưu trữ dài hạn, hay xử lý trong bộ nhớ.

- Vì không có một quy định thống nhất cho một sự cố nên mô hình dữ liệu không đưa ra một định nghĩa cho một sự cố cụ thể trong việc thực thi. Thay vào đó một quy ước rộng được sử dụng trong IODEF để đủ linh hoạt bao hàm phần lớn các trường hợp ứng dụng.

- Mô tả một sự cố cho tất cả các trường hợp có thể đòi hỏi một mô hình dữ liệu rất phức tạp. Vì vậy, IODEF chỉ dự định là một khung để trao đổi thông tin sự cố chung nhất. Nó đảm bảo rằng có nhiều cơ chế mở rộng để hỗ trợ thông tin cho các tổ chức cụ thể, và các kỹ thuật để tham chiếu thông tin bên ngoài mô hình dữ liệu.

- Vùng phân tích an toàn an toàn chưa được chuẩn hóa đầy đủ và phải dựa trên các mô tả dưới văn bản dạng tự do. IODEF cố gắng nhằm vào sự cân bằng giữa sự hỗ trợ nội dung dạng tự do này, trong khi vẫn cho phép xử lý tự động thông tin về sự cố.

IODEF chỉ là một trong số các biểu diễn dữ liệu có liên quan đến an toàn đang được chuẩn hóa. Các mô hình dữ liệu của IDMEF^[17] chịu ảnh hưởng từ thiết kế của IODEF.

Các thảo luận khác về các đặc tính mong muốn của IODEF có thể được tìm thấy trong phân tài liệu yêu cầu đối với khuôn dạng trao đổi thông tin sự cố (FINE) ^[16].

4.4  Về việc tạo lập IODEF

Việc tạo lập IODEF được mô tả dưới dạng lực đồ^[2] ngôn ngữ đánh dấu mở rộng XML^[1] trong Điều 11.

Thực hiện IODEF trong XML có nhiều ưu điểm gồm: Tính mở rộng của nó là lý tưởng cho xác định một khung mã hóa dữ liệu có khả năng hỗ trợ nhiều mã hóa ký tự khác nhau. Tương tự như vậy, sự đa dạng của các công nghệ liên quan (ví dụ như XSL, Xpath, XML-Signature) làm cho các thao tác trở lên đơn giản hơn. Tuy nhiên XML về cơ bản là một biểu diễn văn bản, không hiệu quả khi dữ liệu nhị phân phải được nhúng hoặc khối lượng dữ liệu cần trao đổi lớn.

5  Các kiểu dữ liệu IODEF

Các thành phần dữ liệu khác nhau của mô hình dữ liệu IODEF được thực hiện với các kiểu khác nhau. Điều 5 sẽ đề cập về các kiểu dữ liệu này. Trong một số trường hợp, các kiểu dữ liệu lược đồ tự nhiên được sử dụng, tuy nhiên đối với các kiểu khuôn dạng phức tạp hơn, các biểu thức chính quy (xem Phụ lục F của ^[3]) hoặc các tiêu chuẩn mở rộng được sử dụng.

5.1  Số nguyên (Integers)

Số nguyên được thể hiện bằng kiểu dữ liệu INTEGER. Dữ liệu số nguyên PHẢI được mã hóa theo cơ số 10.

Kiểu dữ liệu INTEGER được sử dụng dưới dạng "xs:integer" ^[3] trong lược đồ.

5.2  Số thực (Real)

Các thuộc tính số thực (dấu phẩy động) được thể hiện bằng kiểu dữ liệu REAL, số thực PHẢI được mã hóa theo cơ số 10.

Kiểu dữ liệu REAL được sử dụng dưới dạng "xs:float" ^[3] trong lược đồ.

5.3  Ký tự và chuỗi ký tự (Characters and Strings)

Một ký tự đơn được thể hiện bằng kiểu dữ liệu CHARACTER. Một chuỗi ký tự được thể hiện bằng kiểu dữ liệu STRING. Các ký tự đặc biệt phải được mã hóa sử dụng các tham chiếu thực thể. Xem thêm tại 7.1.

Kiểu dữ liệu CHARACTER và STRING được sử dụng dưới dạng "xs:string" ^[3] trong lược đồ.

5.4  Chuỗi đa ngôn ngữ (Multilingual Strings)

Dữ liệu STRING thể hiện các thuộc tính nhiều ký tự sử dụng ngôn ngữ khác với ngôn ngữ mặc định trong tài liệu là kiểu dữ liệu ML_STRING.

Kiểu dữ liệu ML_STRING được sử dụng dưới dạng "iodef:MLStringType" trong lược đồ.

5.5  Bytes

Khối dữ liệu gồm tám số nhị phân được thể hiện bằng kiểu dữ liệu BYTE. Một chuỗi tuần tự các khối dữ liệu tám số nhị phân được thể hiện bằng kiểu dữ liệu BYTE[]. Khối dữ liệu tám số nhị phân này được mã hóa theo chuẩn base64.

Kiểu dữ liệu BYTE được sử dụng dưới dạng "xs:base64Binary"^[3] trong lược đồ.

5.6  Byte thập lục phân (Hexadecimal Bytes)

Một bộ tám chữ số nhị phân được thể hiện bằng kiểu dữ liệu HEXBIN (và HEXBIN[]). Bộ tám này được mã số như một bộ ký tự bao gồm hai chữ số thập lục phân.

Kiểu dữ liệu HEXBIN được sử dụng dưới dạng "xs:hexBinary"^[3] trong lược đồ.

5.7  Kiểu liệt kê (Enumerated Types)

Các kiểu liệt kê được thể hiện bằng kiểu dữ liệu ENUM và chứa một danh sách chưa sắp xếp của các giá trị có thể chấp nhận được. Mỗi giá trị có một từ khóa thể hiện. Trong lược đồ IODEF, các từ khóa của kiểu dữ liệu liệt kê được sử dụng như các giá trị thuộc tính.

Kiểu dữ liệu ENUM được sử dụng dưới dạng một dãy các "xs:NMTOKEN" trong lược đồ.

5.8  Chuỗi ngày giờ (Date-Time Strings)

Chuỗi ngày - giờ được thể hiện bằng kiểu dữ liệu DATETIME. Mỗi chuỗi ngày - giờ chỉ xác định một thời gian nhất định; không hỗ trợ các khoảng thời gian.

Các chuỗi ngày - giờ được khuôn dạng theo một bộ của chuẩn ISO 8601:2000 ^[3] ghi lại trong RFC 3339 ^[12].

Kiểu dữ liệu DATETIME được sử dụng dưới dạng "xs:dateTime" ^[3] trong lược đồ.

5.9  Chuỗi múi giờ (Timezone String)

Múi giờ lệch với giờ tiêu chuẩn UTC được thể hiện bằng kiểu dữ liệu TIMEZONE. Chuỗi này được khuôn dạng theo biểu thức chính quy: "Z|[\+\-](0[0-9]|1[0-4]):[0-5][0-9]".

Kiểu dữ liệu TIMEZONE được sử dụng dưới dạng "xs:string" ràng buộc với một biểu thức chính quy trong lược đồ. Biểu thức chính quy này đồng nhất với thể hiện múi giờ sử dụng trong "xs:dateTime".

5.10  Danh sách cổng (Port Lists)

Danh sách các cổng mạng được thể hiện bằng kiểu dữ liệu PORTLIST. Một PORTLIST bao gồm một danh sách các số và các khoảng (ví dụ N-M nghĩa là bao gồm các cổng từ N đến M), phân cách bởi dấu phẩy. Danh sách này được khuôn dạng theo biểu thức chính quy sau: "\d+(\-\d+)?(,\d+ (\-\d+)?)*". Ví dụ. "2, 5-15, 30, 32, 40-50, 55-60".

Kiểu dữ liệu PORTLIST được sử dụng dưới dạng "xs:string" ràng buộc với một biểu thức chính quy trong lược đồ.

5.11  Địa chỉ bưu điện (Postal Address)

Địa chỉ bưu điện được thể hiện bằng kiểu dữ liệu POSTAL. Kiểu dữ liệu này là một ML_STRING với khuôn dạng được ghi trong 2.23 của RFC 4519 ^[10]. Kiểu dữ liệu này định nghĩa địa chỉ bưu điện dưới dạng một chuỗi nhiều dòng dạng tự do và được phân cách bởi ký tự "$"

Kiểu dữ liệu POSTAL được sử dụng dưới dạng "xs:string" trong lược đồ.

5.12  Cá nhân hoặc tổ chức (Person or Organization)

Tên của một cá nhân hay tổ chức được thể hiện bằng kiểu dữ liệu NAME. Kiểu dữ liệu này là một ML_STRING với khuôn dạng được ghi trong 2.3 của RFC 4519 ^[10].

Kiểu dữ liệu NAME được sử dụng dưới dạng "xs:string" trong lược đồ.

5.13  Số điện thoại và Fax (Telephone and Fax Numbers)

Số điện thoại và fax được thể hiện bằng kiểu dữ liệu PHONE. Khuôn dạng của kiểu dữ liệu PHONE được ghi trong 2.35 của RFC 4519^[10].

Kiểu dữ liệu PHONE được sử dụng dưới dạng "xs:string" trong lược đồ.

5.14  Chuỗi Email (Email string)

Một địa chỉ thư điện tử được thể hiện bằng kiểu dữ liệu EMAIL. Khuôn dạng của kiểu dữ liệu EMAIL được ghi trong 3.4.1 RFC 2822 ^[11].

Kiểu dữ liệu EMAIL được sử dụng dưới dạng "xs:string" trong lược đồ.

5.15  Chuỗi định vị tài nguyên thống nhất (Uniform Resource Locator strings)

Chuỗi định vị tài nguyên thống nhất (URL) được thể hiện bằng kiểu dữ liệu URL. Khuôn dạng của kiểu dữ liệu URL được ghi trong RFC 2396 ^[8].

Kiểu dữ liệu URL được sử dụng dưới dạng "xs:anyURI" trong lược đồ.

6  Mô hình dữ liệu IODEF

Trong điều mô tả các thành phần riêng biệt của mô hình dữ liệu IODEF sẽ được giải thích chi tiết. Đối với mỗi lớp, các ngữ nghĩa sẽ được giải thích và mối quan hệ với các lớp khác sẽ được mô tả bằng UML. Nếu cần thiết, các ghi chú cụ thể sẽ được cung cấp về các định nghĩa tương ứng trong lược đồ tại Điều 11.

6.1  Lớp lODEF-Document (lODEF-Document Class)

Lớp lODEF-Document là lớp ở mức cao nhất trong mô hình dữ liệu IODEF. Tất cả các tài liệu IODEF là các thể hiện của lớp này.

Hình 1 - Lớp lODEF-Document

Lớp kết tập cấu thành nên lớp IODEF-Document là:

Incident

1 hoặc nhiều. Các thông tin liên quan đến một sự cố đơn.

Lớp IODEF-Document có ba thuộc tính:

version

Yêu cầu. STRING. Số phiên bản đặc tả IODEF mà tài liệu IODEF này tuân thủ. Giá trị của thuộc tính này PHẢI là "1.00".

lang

Yêu cầu. ENUM. Một mã ngôn ngữ hợp lệ ứng với mỗi RFC 4646 ^[7] ràng buộc bởi định nghĩa của "xs:language". Các giải thích của đoạn mã này được mô tả tại Điều 9 của tiêu chuẩn này.

formatid

Tùy chọn. STRING. Một chuỗi dạng tự do để truyền các chỉ lệnh xử lý đến người nhận của tài liệu. Ngữ nghĩa của nó phải được thỏa thuận qua kênh riêng.

6.2  Lớp Incident (Incident Class)

Mỗi một sự cố được biểu diễn bằng một thể hiện của lớp Incident. Lớp này cung cấp các thể hiện được chuẩn hóa cho các dữ liệu trao đổi sự cố thông thường.

Hình 2 - Lớp Incident

Các lớp kết tập cấu thành nên lớp Incident là:

IncidentlD

1. Mã kiểm soát sự cố được gán cho sự cố này bởi CSIRT tạo tài liệu IODEF.

AItemativelD

0 hoặc 1. Mã kiểm soát sự cố sử dụng bởi các CSIRT khác để tham chiếu đến sự cố được mô tả trong tài liệu.

RelatedActivity

0 hoặc 1. Mã kiểm soát sự cố của các sự cố có liên quan.

DetectTime

0 hoặc 1. Thời gian sự cố được phát hiện lần đầu tiên.

StartTime

0 hoặc 1. Thời gian sự cố bắt đầu.

EndTime

0 hoặc 1. Thời gian sự cố kết thúc.

ReportTime

1. Thời gian sự cố được báo cáo.

Description

0 hoặc 1. ML_STRING. Giải thích bằng văn bản dạng tự do của sự cố.

Assessment

1 hoặc nhiều. Đặc điểm của tác động của sự cố.

Method

0 hoặc nhiều. Kỹ thuật được sử dụng bởi kẻ xâm nhập trong sự cố.

Contact

0 hoặc nhiều. Thông tin liên lạc của các bên liên quan đến sự cố.

EventData

0 hoặc nhiều. Giải thích của các sự kiện xảy ra trong sự cố.

History

0 hoặc 1. Nhật ký của các sự kiện hoặc hành động quan trọng xảy ra trong quá trình xử lý sự cố.

AdditionalData

0 hoặc nhiều. Cơ chế mở rộng mô hình dữ liệu.

Lớp Incident có bốn thuộc tính:

purpose

Yêu cầu. ENUM. Thuộc tính purpose thể hiện lý do tài liệu IODEF được tạo. Thuộc tính liên hệ chặt chẽ với lớp Expectation (tại 6.13). Thuộc tính này được xác định dưới dạng một danh sách liệt kê:

1. traceback. Tài liệu được gửi với mục đích dò vết lại.

2. mitigation. Tài liệu được gửi để yêu cầu hỗ trợ giảm nhẹ hoạt động đã mô tả.

3. reporting. Tài liệu được gửi để thực hiện các yêu cầu báo cáo.

4. other. Tài liệu được gửi với mục đích được xác định trong lớp Expectation.

5. ext-value. Giá trị ngoài được sử dụng để mở rộng thuộc tính này. Xem 8.1.

ext-purpose

Tùy chọn. STRING. Thuộc tính có mục đích để mở rộng thuộc tính purpose. Xem 8.1.

lang

Tùy chọn. ENUM. Một mã ngôn ngữ hợp lệ trong RFC 4646 ^[7] ràng buộc bởi định nghĩa của "xs:language". Giải nghĩa của đoạn mã này được trình bày tại Điều 9.

restriction

Tùy chọn. ENUM. Thuộc tính này chỉ ra các chỉ dẫn công khai mà người gửi mong muốn người nhận tuân thủ theo những thông tin được chỉ ra trong lớp này và các lớp con của nó. Các chỉ dẫn này không cung cấp các an toàn vì ở đây không xác định các phương pháp kỹ thuật để bảo đảm người nhận của tài liệu này xử lý thông tin theo cách người gửi yêu cầu.

Giá trị của thuộc tính này được thừa kế lô-gic bởi các lớp con của lớp này. Điều này đồng nghĩa với việc các chỉ dẫn công khai áp dụng cho lớp này đồng thời cũng được áp dụng cho các lớp con của nó.

Có thể đặt ra một chính sách tiết lộ thông tin vì tất cả các lớp bậc cao (các lớp con của lớp Incident) có thuộc tính restriction. Vì vậy một lớp con có thể ghi đè cơ chế của lớp cha, đặt các cơ chế này là giới hạn hoặc nới lỏng các quy định tiết lộ (ví dụ, một lớp con có cơ chế yếu hơn lớp cha; hoặc lớp cha có cơ chế yếu và các lớp con chọn lựa việc áp dụng các kiểm soát chặt hơn). Giá trị ngầm định của thuộc tính restriction cho một lớp không xác định thuộc tính này có thể được lấy từ lớp cha gần nhất có xác định thuộc tính này.

Thuộc tính này được xác định như một giá trị kiểu liệt kê với giá trị mặc định là "private". Lưu ý là giá trị mặc định cho thuộc tính restriction chỉ được định nghĩa trong phạm vi lớp Incident. Trong các lớp khác mà thuộc tính này được sử dụng, thuộc tính này không mang một giá trị mặc định nào.

1. public. Không có giới hạn nào trong thông tin.

2. need-to-know. Thông tin có thể được chia sẻ với các bên liên quan đến sự cố theo quyết định người nhận tài liệu này (ví dụ các trang bị tấn công có thể thông báo cho nhau).

3. private. Thông tin không được phép chia sẻ.

4. default. Thông tin có thể được chia sẻ dựa trên một chính sách thông tin công khai thỏa thuận giữa các bên trao đổi.

6.3  Lớp IncidentlD (IncidentlD Class)

Lớp IncidentlD biểu diễn một mã kiểm soát sự cố là duy nhất trong tình huống của CSIRT và xác định hoạt động được mô tả trong một tài liệu IODEF. Định danh này có thể đáp ứng như là một chỉ mục cho hệ thống xử lý sự cố. Kết hợp của thuộc tính name và chuỗi ký tự trong nội dung thành phần PHẢI là một định danh duy nhất có tính toán cục mô tả sự kiện đó. Các tài liệu được tạo ra bởi một CSIRT PHẢI KHÔNG dùng cùng một giá trị trừ khi chúng tham chiếu đến cùng một sự cố.

Hình 3 - Lớp IncidentID

Lớp IncidentID có ba thuộc tính:

name

Yêu cầu. Kiểu STRING. Một định danh mô tả CSIRT đã tạo ra tài liệu. Để có một tên CSIRT duy nhất có tính tổng quát, tên miền đầy đủ kết hợp với CSIRT PHẢI được sử dụng.

instance

Tùy chọn. Kiểu STRING. Một định danh tham chiếu một tập con của sự cố được đặt tên.

restriction

Tùy chọn. Kiểu ENUM. Thuộc tính này đã được quy định tại 6.2.

6.4  Lớp AlternativeID (AlternativeID Class)

Lớp AlternativeID đưa danh sách các mã kiểm soát sự cố được sử dụng bởi các CSIRT ngoại trừ số được tạo ra bởi tài liệu, để tham chiếu đến hành động tương ứng được mô tả trong tài liệu IODEF. Một mã kiểm soát được liệt kê là một AlternativeID tham chiếu đến cùng một sự cố được phát hiện bởi một CSIRT khác. Mã kiểm soát sự cố của CSIRT tạo ra tài liệu IODEF không bao giờ được coi là một AlternativeID.

Hình 4 - Lớp Alternative

Lớp kết tập cấu thành nên lớp AlternativeID là:

IncidentlD

1 hoặc nhiều. Mã kiểm soát sự cố của CSIRT khác.

Lớp AlternativeID có một thuộc tính:

restriction

Tùy chọn. Kiểu ENUM. Thuộc tính này đã được trình bày trong 6.2.

6.5  Lớp RelatedActivity (RelatedActivity Class)

Lớp RelatedActivity liệt kê các mã kiểm soát sự cố của các sự cố hoặc các URL (chỉ một trong hai trường hợp) có tham chiếu đến hành động liên quan đến sự cố được mô tả trong tài liệu IODEF. Các tham chiếu này có thể tham chiếu đến các mã kiểm soát sự cố cục bộ hoặc tham chiếu đến các sự cố của các CSIRT khác. Chi tiết về phương pháp CSIRT cho rằng hai sự cố có liên quan đến nhau nằm ngoài phạm vi.

Hình 5 - Lớp RelatedActivity

Các lớp kết tập cấu thành nên lớp RelatedActivity là:

IncidentlD

1 hoặc nhiều. Mã kiểm soát sự cố của một sự cố có liên quan.

URL

1 hoặc nhiều. URL. URL của hoạt động có liên quan đến sự cố.

Lớp RelatedActivity có một thuộc tính:

restriction

Tùy chọn. ENUM. Thuộc tính này được quy định tại 6.2.

6.6  Lớp AdditionalData (AdditionalData Class)

Lớp AdditionalData được sử dụng như một cơ chế mở rộng cho các thông tin mà không được thể hiện trong mô hình dữ liệu theo bất kỳ cách nào nào khác. Đối với các thông tin tương đối đơn giản, các kiểu dữ liệu nguyên thủy (ví dụ integer, string) được cung cấp một cơ chế để chú giải ý nghĩa của chúng. Lớp này cũng được sử dụng để mở rộng mô hình dữ liệu (và lược đồ có liên kết đến) để hỗ trợ các mở rộng độc quyền bằng cách đóng gói toàn bộ các tài liệu XML tuân thủ theo lược đồ khác (ví dụ IDMEF). Trình bày chi tiết về việc mở rộng mô hình dữ liệu và lược đồ được trình bày Điều 8.

Khác với XML là tự mô tả, các kiểu dữ liệu nguyên thủy phải được chú thích để truyền đạt ý nghĩa của chúng. Các thông tin này được mô tả trong thuộc tính 'meaning’. Vì các mô tả này nằm ngoài phạm vi của đặc tả, có thể cần phải kết hợp với một số các phương pháp khác để bảo đảm người nhận của tài liệu sử dụng lớp AdditionalData có thể hiểu các mở rộng tùy chỉnh.

Hình 6 - Lớp AdditionalData

Lớp AdditionalData có năm thuộc tính:

dtype

Yêu cầu. ENUM. Kiểu dữ liệu của nội dung thành phần. Các giá trị hợp lệ của thuộc tính này được thể hiện dưới đây. Giá trị định là "string"

ext-dtype

Tùy chọn. STRING. Phương pháp được sử dụng để mở rộng thuộc tính dtype. Xem 8.1.

meaning

Tùy chọn. STRING. Mô tả dạng tự do của nội dung thành phần.

formatid

Tùy chọn. STRING. Định danh tham chiếu đến khuôn dạng và ngữ nghĩa của nội dung thành phần.

restriction

Tùy chọn. ENUM. Thuộc tính này được quy định trong 6.2.

6.7  Lớp Contact (Contact Class)

Lớp Contact mô tả thông tin liên lạc của các tổ chức và cá nhân liên quan đến sự cố. Lớp này cho phép việc đặt tên cho các bên liên quan, xác định các thông tin liên lạc và xác định vai trò của các bên trong sự cố.

Người và tổ chức được có thể được coi như các liên lạc và được sử dụng thay thế cho nhau; đối tượng này có thể liên kết đến đối tượng khác thông qua mô tả đệ quy của lớp (lớp Contact được kết tập trong một lớp Contact khác). Thuộc tính 'type' làm rõ kiểu của thông tin liên lạc được cung cấp.

Mô hình thừa kế của Contact cung cấp một phương pháp để liên hệ các thông tin mà không cần sử dụng tường minh các định danh trong các lớp hay sử dụng lại dữ liệu. Một thông tin liên lạc hoàn chỉnh được dẫn xuất từ việc duyệt từ lớp Contact gốc đến lớp Contact lá. Như vậy, nhiều thông tin của các liên lạc có thể được xác định trong một thể hiện duy nhất của một lớp Contact. Một lớp Contact con thừa kế lô-gic các thông tin liên lạc từ các lớp cha của nó.

Hình 7 - Lớp Contact

Các lớp kết tập cấu thành nên lớp Contact là:

ContactName

0 hoặc 1. ML_STRING. Tên của liên lạc. Liên lạc này có thể là một người hoặc một tổ chức. Thuộc tính type sẽ làm rõ ngữ nghĩa này.

Description

0 hoặc nhiều. ML_STRING. Mô tả dạng tự do của liên lạc này. Trong trường hợp là một người, đây thường là chức danh trong tổ chức của người đó.

RegistryHandle

0 hoặc nhiều. Tên xử lý đến đăng ký của liên lạc.

Postal Address

0 hoặc 1. Địa chỉ bưu điện của liên lạc.

Email

0 hoặc nhiều. Địa chỉ thư điện tử của liên lạc.

Telephone

0 hoặc nhiều, số điện thoại của liên lạc.

Fax

0 hoặc 1. Số fax của liên lạc.

Timezone

0 hoặc 1. TIMEZONE. Múi giờ tại vị trí của liên lạc, được khuôn dạng theo 5.9.

Contact

0 hoặc nhiều. Thể hiện Contact được chứa bên trong một thể hiện Contact khác thừa kế các giá trị của các lớp cha. Mô tả đệ quy này có thể được sử dụng để nhóm các dữ liệu chung có liên quan đến nhiều thông tin của liên lạc và đặc biệt hữu ích khi sử dụng nhiều liên lạc trong cùng một tổ chức.

Additional Data

0 hoặc nhiều. Cơ chế để mở rộng mô hình dữ liệu.

Ít nhất một trong các lớp kết tập PHẢI tồn tại trong một thể hiện của lớp Contact. Điều này không được thực thi trong lược đồ IODEF vì không có cách nào đơn giản để thực hiện việc này.

Lớp Contact có năm thuộc tính:

role

Yêu cầu. ENUM. Xác định vai trò của liên lạc. Thuộc tính này được quy định dưới dạng một danh sách liệt kê:

ext-role

Tùy chọn. STRING. Phương pháp để mở rộng thuộc tính role. Xem 8.1

type

Yêu cầu. ENUM. Xác định kiểu của liên lạc được mô tả. Thuộc tính này được quy định dưới dạng một danh sách liệt kê:

ext-type

Tùy chọn. STRING. Phương pháp để mở rộng thuộc tính type. Xem 8.1.

restriction

Tùy chọn. ENUM. Thuộc tính này được quy định ở 6.2.

6.7.1  Lớp RegistryHandle (RegistryHandle Class)

Lớp RegistryHandle thể hiện việc xử lý một đăng ký Internet hoặc một cơ sở dữ liệu đặc tả cộng đồng. Xử lý này được xác định trong nội dung thành phần và thuộc tính type xác định cơ sở dữ liệu.

Hình 8 - Lớp RegistryHandle

Lớp RegistryHandle có hai thuộc tính:

registry

Yêu cầu. ENUM. Cơ sở dữ liệu chứa xử lý này. Giá trị mặc định là 'local'. Các giá trị hợp lệ là:

Ext-registry

Tùy chọn. STRING. Phương pháp để mở rộng thuộc tính registry. Xem 8.1.

6.7.2  Lớp PostalAddress (PostalAddress Class)

Lớp PortalAddress xác định địa chỉ bưu điện được khuôn dạng theo kiểu dữ liệu POSTAL (5.11).

Hình 9 - Lớp PostalAddress

Lớp PostalAddress có hai thuộc tính:

meaning

Tùy chọn. ENUM. Mô tả dạng tự do của nội dung thành phần.

lang

Yêu cầu. ENUM. Mã ngôn ngữ hợp lệ theo RFC 4646 ^[7], ràng buộc bởi định nghĩa của "xs:language". Giải thích của mã này được mô tả trong Điều 9.

6.7.3  Lớp Email (Email Class)

Lớp Email xác định một địa chỉ thư điện tử được khuôn dạng theo kiểu dữ liệu EMAIL (5.14).

Hình 10 - Lớp Email

Lớp Email có một thuộc tính:

meaning

Tùy chọn. ENUM. Mô tả dạng tự do của nội dung thành phần.

6.7.4  Lớp Telephone và Fax (Telephone and Fax Classes)

Lớp Telephone và Fax mô tả một số điện thoại hoặc số fax tương ứng, và được khuôn dạng theo kiểu dữ liệu PHONE (5.13)

Hình 11 - Lớp Telephone and Fax

Lớp Telephone có một thuộc tính:

meaning

Tùy chọn. ENUM. Mô tả dạng tự do của nội dung thành phần (ví dụ: số giờ phủ sóng của một số nhất định).

6.8  Lớp Time (Time Classes)

Mô hình dữ liệu sử dụng 5 lớp khác nhau để thể hiện một nhãn thời gian. Quy định về chúng là như nhau, nhưng mỗi một lớp có một tên riêng biệt để cung cấp ngữ nghĩa khác nhau.

Nội dung thành phần của mỗi lớp là một nhãn thời gian được khuôn dạng theo kiểu dữ liệu DATETIME (xem 5.8).

Hình 12 - Lớp Time

6.8.1  StartTime

Lớp StartTime cho biết thời gian sự cố bắt đầu xảy ra.

6.8.2  EndTime

Lớp EndTime cho biết thời gian sự cố kết thúc.

6.8.3  DetectTime

Lớp DetectTime cho biết thời gian hoạt động đầu tiên của sự cố được phát hiện.

6.8.4  ReportTime

Lớp ReportTime cho biết thời điểm sự cố được báo cáo lại. Nhãn thời gian này NÊN trùng với thời điểm tài liệu IODEF được tạo ra.

6.8.5  DateTime

Lớp DateTime là một mô tả chung của nhãn thời gian. Ngữ nghĩa của lớp này nên được dẫn xuất từ lớp cha mà nó được kết tập.

6.9  Lớp Method (Method Class)

Lớp Method mô tả phương thức được sử dụng bởi kẻ xâm nhập liên quan tới các sự kiện của sự cố. Lớp này gồm một danh sách các tham chiếu mô tả cách thức tấn công và mô tả của kỹ thuật tấn công.

Hình 13 - Lớp Method

Lớp Method chứa ba lớp kết tập:

Reference

0 hoặc nhiều. Tham chiếu tới các điểm yếu, các mẫu phần mềm độc hại, tư vấn hoặc phân tích về một kỹ thuật tấn công.

Description

0 hoặc nhiều. ML_STRING. Mô tả dạng tự do của cách thức được sử dụng bởi kẻ xâm nhập.

AdditionalData

0 hoặc nhiều. Cơ chế để mở rộng mô hình dữ liệu

Thể hiện của lớp Reference hoặc lớp Description PHẢI tồn tại.

Lớp Method có một thuộc tính:

restriction

Tùy chọn. ENUM. Thuộc tính này được quy định trong 6.2.

6.9.1  Lớp Reference (Reference Class)

Lớp Reference gồm các tham chiếu đến một điểm yếu, cảnh báo IDS, mẫu phần mềm độc hại, tư vấn hoặc một kỹ thuật tấn công. Một tham chiếu bao gồm tên, một URL đến tham chiếu này, và một mô tả tùy chọn.

Hình 14 - Lớp Reference

Các lớp kết tập cấu thành nên lớp Reference là:

ReferenceName

1. ML_STRING. Tên của tham chiếu.

URL

0 hoặc nhiều. URL. Một URL liên kết đến tham chiếu.

Description

0 hoặc nhiều. ML_STRING. Mô tả dạng tự do của tham chiếu này.

6.10  Lớp Assessment (Assessment Class)

Lớp Assessment mô tả các ảnh hưởng cả về kỹ thuật và phi kỹ thuật của sự cố lên khu vực của CSIRT.

Lớp này bắt nguồn từ IDMEF ^[17].

Hình 15 - Lớp Assessment

Các lớp kết tập cấu thành nên lớp Assessment là:

Impact

0 hoặc nhiều. Ảnh hưởng kỹ thuật của sự cố lên mạng.

TimeImpact

0 hoặc nhiều. Ảnh hưởng của hoạt động được đánh giá dựa trên thiệt hại về mặt thời gian.

MonetaryImpact

0 hoặc nhiều. Ảnh hưởng của hoạt động được đánh giá dựa trên thiệt hại về mặt tài chính.

Counter

0 hoặc nhiều. Bộ đếm để tính quy mô của hoạt động.

Confidence

0 hoặc 1. Dự tính về sự tin cậy trong đánh giá này.

AdditionalData

0 hoặc nhiều. Cơ chế để mở rộng mô hình dữ liệu.

Ít nhất một thể hiện của một trong của ba lớp tác động (Impact, TimeImpact, MonetaryImpact) PHẢI tồn tại.

Lớp Assessment có hai thuộc tính:

occurrence

Tùy chọn. ENUM. Xác định đánh giá là mô tả kết quả thực tế hay tiềm năng. Mặc định là "actual" và được giả định nếu không được quy định rõ.

1. actual. Đánh giá này mô tả hoạt động đã xảy ra.

2. potential. Đánh giá này mô tả hoạt động tiềm ẩn có thể xảy ra.

restriction

Tùy chọn. ENUM. Thuộc tính này được quy định trong 6.2.

6.10.1  Lớp Impact (Impact Class)

Lớp Impact cho phép phân loại và mô tả ảnh hưởng về mặt kỹ thuật của sự cố lên mạng của một tổ chức.

Lớp này dựa trên IDMEF^[17].

Hình 16 - Lớp Impact

Nội dung thành phần sẽ là một văn bản dạng tự do mô tả về các ảnh hưởng.

Lớp Impact có 5 thuộc tính:

lang

Yêu cầu. ENUM. Một mã ngôn ngữ qua RFC4646 theo quy định của "xs:language". Giải thích về mã này được mô tả tại Điều 9.

severity

Tùy chọn. ENUM. Đánh giá về mức độ nghiêm trọng của các hoạt động có liên quan. Những giá trị hợp lệ được liệt kê phía dưới. Không có giá trị mặc định.

(1) Low: Mức độ nghiêm trọng thấp

(2) Medium: Mức độ nghiêm trọng trung bình

(3) High: Mức độ nghiêm trọng cao

completion

Tùy chọn. ENUM. Một chỉ thị mô tả hoạt động có thành công hay không. Những giá trị hợp lệ được liệt kê phía dưới. Không có giá trị mặc định.

(1) failed: Hoạt động không thành công.

(2) succeeded: Hoạt động thành công.

type

Yêu cầu. ENUM. Phân loại hoạt động độc hại vào một lớp sự cố. Những giá trị hợp lệ được liệt kê phía dưới. Giá trị mặc định là "other".

(1) admin. Hoạt động chiếm quyền quản trị đã được thử thực hiện.

(2) dos. Hoạt động tấn công từ chối dịch vụ đã được thử thực hiện.

(3) file. Hoạt động gây ảnh hưởng tới sự toàn vẹn của tệp tin hoặc cơ sở dữ liệu đã được thử thực hiện.

(4) info-leak. Hoạt động trích xuất thông tin đã được thử thực hiện.

(5) misconfiguration. Hoạt động khai thác cấu hình sai đã được thử thực hiện.

(6) policy. Hoạt động xâm phạm vào chính sách của tổ chức đã được thử thực hiện.

(7) recon. Hoạt động thăm dò đã được thử thực hiện.

(8) social-engineering. Hoạt động khai thác các yếu tố văn hóa, xã hội đã được thử thực hiện.

(9) user. Hoạt động xâm phạm quyền người dùng đã được thử thực hiện.

(10) unknown. Phân loại hoạt động này là chưa biết.

(11) ext-value. Giá trị ngoài được sử dụng để mở rộng thuộc tính này. Xem 8.1.

ext-type

Tùy chọn. STRING. Phương pháp để mở rộng thuộc tính type. Xem 8.1.

6.10.2  Lớp TimeImpact (TimeImpact Class)

Lớp TimeImpact mô tả ảnh hưởng của sự cố lên một tổ chức về mặt thời gian. Nó cung cấp thông tin về thời gian hệ thống ngừng hoạt động và thời gian khôi phục.

Hình 17 - Lớp TimeImpact

Nội dung thành phần là một số thực dương chỉ định một đơn vị thời gian. Thuộc tính 'duration' và 'metric’ sẽ thể hiện ngữ nghĩa của nội dung thành phần.

Lớp TimeImpact có 5 thuộc tính:

severity

Tùy chọn. ENUM. Đánh giá về mức độ nghiêm trọng của các hoạt động có liên quan. Những giá trị hợp lệ được liệt kê phía dưới, không có giá trị mặc định.

1. Low: Mức độ nghiêm trọng thấp

2. Medium: Mức độ nghiêm trọng trung bình

3. High: Mức độ nghiêm trọng cao

metric

Yêu cầu. ENUM. Quy định chuẩn đo mà thời gian được biểu hiện. Giá trị hợp lệ được liệt kê dưới đây, không có giá trị mặc định.

1. labor. Tổng số thời gian nhân lực để phục hồi lại (ví dụ: 2 nhân viên làm việc mất 4 giờ thì tổng thời gian sẽ là 8 giờ).

2. elapsed. Thời gian tính từ khi bắt đầu quá trình khôi phục cho đến khi hoàn thành.

3. downtime. Khoảng thời gian mà một số dịch vụ được cung cấp không hoạt động.

4. ext-value. Giá trị ngoài được sử dụng để mở rộng thuộc tính này. Xem 8.1.

ext-metric

Tùy chọn. STRING. Phương pháp để mở rộng thuộc tính metric. Xem 8.1.

duration

Yêu cầu. ENUM. Định nghĩa đơn vị thời gian, khi kết hợp với thuộc tính metric sẽ mô tả đầy đủ một chuẩn đo của tác động mà sẽ được đưa ra trong nội dung thành phần. Giá trị hợp lệ được liệt kê dưới đây. Giá trị mặc định là "hour".

1. second. Đơn vị của nội dung thành phần là giây.

2. minute. Đơn vị của nội dung thành phần là phút.

3. hour. Đơn vị của nội dung thành phần là giờ.

4. day. Đơn vị của nội dung thành phần là ngày.

5. month. Đơn vị của nội dung thành phần là tháng.

6. quarter. Đơn vị của nội dung thành phần là quý.

7. year. Đơn vị của nội dung thành phần là năm.

8. ext-value. Giá trị ngoài được sử dụng để mở rộng thuộc tính này. Xem 8.1.

ext-duration

Tùy chọn. STRING. Phương pháp đề mở rộng thuộc tính metric. Xem 8.1.

6.10.3  Lớp MonetaryImpact (MonetaryImpact Class)

Lớp này mô tả tác động về mặt tài chính của tổ chức. Ví dụ, ảnh hưởng này có thể là thua lỗ do chi phí của việc điều tra và phục hồi, sự sự giảm năng suất của nhân viên hay danh tiếng bị ảnh hưởng sẽ tác động đến các cơ hội trong tương lai

Hình 18 - Lớp MonetaryImpact

Nội dung thành phần là một số thực (REAL) dương xác định đơn vị tiền tệ được mô tả trong thuộc tính currency.

Lớp này có hai thuộc tính:

severity

Tùy chọn. ENUM. Đánh giá về mức độ nghiêm trọng của các hoạt động có liên quan. Những giá trị hợp lệ được liệt kê phía dưới, không có giá trị mặc định.

1. Low. Mức độ nghiêm trọng thấp.

2. Medium. Mức độ nghiêm trọng trung bình.

3. High. Mức độ nghiêm trọng cao.

currency

Yêu cầu. STRING. Định nghĩa đơn vị tiền tệ được diễn tả ảnh hưởng tiền tệ. Giá trị cho phép được định nghĩa trong ISO 4217:2001, quy tắc biểu diễn tiền tệ và quỹ ^[14]. Không có giá trị mặc định.

6.10.4  Lớp Confidence (Confidence Class)

Lớp Confidence mô tả một ước lượng gần đúng nhất về tính hợp lệ và độ chính xác của tác động được mô tả (6.10) trong hoạt động của sự cố. Ước lượng này có thể được thể hiện ở dạng một mục phân loại hoặc tính toán số học.

Lớp này được dựa trên IDMEF^[17].

Hình 19 - Lớp Confidence

Nội dung thành phần thể hiện đánh giá độ tin cậy của dữ liệu ở dạng số học khi giá trị của thuộc tính rating là "numeric". Trái lại, thành phần này sẽ rỗng.

Lớp Confidence có một thuộc tính:

rating

Yêu cầu. ENUM. Đánh giá tính hợp lệ phân tích của một bản đánh giá cụ thể. Giá trị cho phép được liệt kê dưới đây. Không có giá trị mặc định.

1. low. Độ tin cậy thấp.

2. medium. Độ tin cậy trung bình.

3. high. Độ tin cậy cao.

4. numeric. Nội dung thành phần chứa một con số để thể hiện được mức độ tin cậy của dữ liệu. Ngữ nghĩa của con số này nằm ngoài phạm vi của bản đặc tả.

6.11  Lớp History (History Class)

Lớp History là một bản ghi những sự kiện hoặc hoạt động quan trọng hoặc các hoạt động được thực hiện bởi các bên tham gia trong suốt quá trình xử lý sự cố.

Mức độ cụ thể của các thông tin được lưu trong bản ghi tùy thuộc vào quyết định của những người xử lý sự cố.

Hình 20 - Lớp History

Lớp kết tập cấu thành nên lớp History là:

HistoryItem

1 hoặc nhiều. Một bản ghi trong nhật ký lịch sử của các sự kiện quan trọng hoặc hoạt động được thực thi bởi các nhóm.

Lớp History có một thuộc tính:

Restriction

Tùy chọn. ENUM. Thuộc tính này được quy định trong 6.2.

6.11.1  Lớp HistoryItem (HistoryItem Class)

Lớp HistoryItem là một bản ghi trong một History (6.11) ghi lại một hoạt động hoặc sự kiện cụ thể xảy ra trong quá trình xử lý sự cố. Chi tiết của các bản ghi này là một mô tả dạng tự do, tuy nhiên các bản ghi có thể được phân loại bằng thuộc tính type.

Hình 21 - Lớp HistoryItem

Các lớp cấu thành lớp HistoryItem là:

DateTime

1. Nhãn thời gian của thực thể này trong nhật ký lịch sử (ví dụ: khi thực hiện hành động được mô tả trong phần Description).

IncidentID

0 hoặc 1. Trong một nhật ký lịch sử được tạo ra bởi nhiều nhóm, IncidentlD cung cấp cơ chế để xác định CSIRT nào tạo ra một bàn ghi cụ thể và tham chiếu đến mã kiểm soát sự cố của nhóm này. Khi chỉ có một nhóm quản lý, lớp này có thể được bỏ qua.

Contact

0 hoặc 1. Cung cấp thông tin liên lạc của người thực hiện hành động được ghi lại trong lớp này.

Description

0 hoặc nhiều. ML_STRING. Mô tả văn bản dạng tự do về sự kiện hoặc hoạt động.

AdditionalData

0 hoặc nhiều. Cơ chế để mở rộng mô hình dữ liệu.

Lớp HistoryItem có 3 thuộc tính:

Restriction

Tùy chọn. ENUM. Thuộc tính này được quy định trong 6.2.

action

Yêu cầu. ENUM. Phân loại một hoạt động đã được thực thi hoặc một sự kiện đã được ghi lại trong bản ghi này. Vì một hoạt động nhiều khả năng đã được xem xét thông qua một kỳ vọng hoặc điều tra nội bộ do đó thuộc tính này tương đương với thuộc tính category của lớp Expectation. Sự khác nhau chỉ là thời điểm. Khi một hoạt động nằm trong lớp này, nó đã thực hiện xong. Xem 6.13.

ext-action

Tùychọn. STRING. Phương pháp để mở rộng thuộc tính hành động. Xem 8.1.

6.12  Lớp EventData (EventData Class)

Lớp EventData mô tả một sự kiện đặc biệt của sự cố trong một tập cho trước các máy chủ hoặc mạng. Mô tả này bao gồm các hệ thống mà hành động được sinh ra và những hệ thống được nhắm đến, đánh giá về các kỹ thuật sử dụng bởi kẻ xâm nhập, tác động của hành động này đối với tổ chức và bất kỳ bằng chứng pháp lý nào phát hiện được.

Hình 22 - Lớp EventData

Các lớp kết tập cấu thành nên lớp EventData là:

Description

0 hoặc nhiều. ML_STRING. Mô tả văn bản dạng tự do của sự kiện.

DetectTime

0 hoặc 1. Thời gian sự kiện được phát hiện.

StartTime

0 hoặc 1. Thời gian sự kiện bắt đầu.

EndTime

0 hoặc 1. Thời gian sự kiện kết thúc.

Contact

0 hoặc nhiều. Thông tin liên lạc của các bên liên quan đến sự kiện.

Assessment

0 hoặc 1. Tác động của sự kiện đối với mục tiêu và các hành động đã được thực hiện.

Method

0 hoặc nhiều. Kỹ thuật sử dụng bởi các kẻ xâm nhập trong một sự kiện.

Flow

0 hoặc nhiều. Mô tả của hệ thống hoặc các mạng liên quan.

Expectation

0 hoặc nhiều. Các hành động dự kiến sẽ được thực hiện bởi các người nhận của sự kiện được mô tả.

Record

0 hoặc 1. Các dữ liệu hỗ trợ (ví dụ, các tệp tin nhật ký) cung cấp các thông tin khác về sự kiện.

EventData

1 hoặc nhiều. Các thể hiện EventData được chứa bên trong một thể hiện EventData khác thừa kế các giá trị từ một hoặc nhiều lớp cha. Mô tả đệ quy này có thể được sử dụng để nhóm các dữ liệu chung thuộc về nhiều sự kiện. Trong khi các thành phần EventData có thể được xác định theo đệ quy, chỉ có các thể hiện lá (các thể hiện EventData không chứa các thể hiện EventData khác) là thể hiện cho các sự kiện thực.

AdditionalData

0 hoặc nhiều. Cơ chế mở rộng dữ liệu không được thể hiện rõ ràng trong mô hình dữ liệu.

Ít nhất một trong các lớp kết tập PHẢI tồn tại trong một thể hiện của lớp EventData. Điều này không được thực thi trong lược đồ IODEF vì không có cách nào đơn giản để thực hiện việc này.

Lớp EventData có một thuộc tính

restriction

Tùy chọn. ENUM. Thuộc tính này được quy định trong 6.2.

6.12.1  Mối liên hệ giữa các lớp Incident và EventData

Giữa các lớp Incident và EventData có một số trùng lặp đáng kể. Tuy nhiên, ngữ nghĩa của các lớp này tương đối khác nhau. Lớp Incident cung cấp thông tin tổng quan về toàn bộ sự cố, trong khi đó lớp EventData cung cấp thông tin về các sự kiện riêng biệt cấu thành nên sự cố. Trong các trường hợp thông dụng nhất, lớp EventData sẽ cung cấp các thông tin cụ thể hơn cho mô tả tổng quan được cung cấp trong lớp Incident. Tuy nhiên cũng có một số trường hợp thông tin tổng thể về sự cố xung đột với một số thông tin riêng lẻ trong lớp EventData khi có tổng hợp của nhiều sự kiện trong sự cố. Trong trường hợp như vậy, việc giải thích của các EventData cụ thể PHẢI thay thế các thông tin chung được cung cấp trong IncidentData.

6.12.2  Thành phần của EventData

Lớp EventData có thể được coi như lớp bao của các thuộc tính của một sự kiện trong một sự cố. Những thuộc tính này bao gồm: các máy chủ liên quan, tác động của các hoạt động của sự cố lên máy chủ, các bản ghi pháp lý... Với một thể hiện của lớp EventData, các máy chủ (ví dụ, lớp System) được nhóm lại theo một số các thuộc tính chung. Mô tả đệ quy (hoặc các thừa kế thuộc tính thể hiện) của lớp EventData (Lớp EventData được kết tập vào trong lớp EventData) cung cấp một cách để đưa các thông tin liên quan mà không đòi hỏi việc sử dụng tường minh các định danh thuộc tính đặc trưng trong các lớp hay sao chép các thông tin. Thay vào đó, độ sâu tương đối của một lớp sẽ được sử dụng để nhóm các thông tin.

Ví dụ, một lớp EventData có thể được sử dụng để mô tả hai thiết bị liên quan trong một sự cố. Mô tả này có thể đạt được bằng cách sử dụng nhiều thể hiện của lớp Flow. Điều này xảy ra khi có một liên hệ kỹ thuật chung (nghĩa là lớp Contact) giữa các thiết bị này, tuy nhiên tác động (tức là lớp Assessment) lên chúng là khác nhau. Mô tả của tình huống này được trình bày ở Hình 23.

Sau đây là lược đồ mô tả:

Hình 23 - Đệ quy trong lớp EventData

6.13  Lớp Expectation (Expectation Class)

Lớp Expectation truyền đến người nhận tài liệu IODEF các hành động người gửi yêu cầu. Phạm vi của các hành động yêu cầu được giới hạn trong phạm vi hoạt động của lớp EventData mà lớp này được kết tập.

Hình 24 - Lớp Expectation

Các lớp cấu thành nên lớp Expectation là:

Description

0 hoặc nhiều. ML_STRING. Mô tả dạng tự do của một hay nhiều hành động mong muốn.

StartTime

0 hoặc 1. Thời gian mà hành động nên được thực hiện. Một dấu thời gian sớm hơn phần ReportTime được xác định trong lớp Incident chỉ ra việc mục tiêu cần được thực hiện sớm nhất có thể. Việc vắng mặt thành phần này chỉ ra việc thực hiện các mục tiêu này tùy thuộc vào quyết định của người nhận.

EndTime

0 hoặc 1. Thời gian mà hành động nên được hoàn thành. Nếu hành động này không được hoàn thành đúng thời gian này, nó không nên được tiếp tục thực hiện.

Contact

0 hoặc 1. Các tác nhân dự kiến cho hành động.

Lớp Expectation có bốn thuộc tính

restriction

Tùy chọn. ENUM. Thuộc tính này được quy định trong 6.2.

severity

Tùy chọn. ENUM. Chỉ ra mức độ mong muốn của hành động. Thuộc tính này là một danh sách liệt kê không có giá trị mặc định và ngữ nghĩa của các đơn vị đo tương đối này là phụ thuộc ngữ cảnh.

action

Tùy chọn. ENUM. Phân loại các hành động được yêu cầu. Thuộc tính này là một danh sách liệt kê không có giá trị mặc định.

ext-action

Tùy chọn. STRING. Phương pháp để mở rộng thuộc tính hành động. Xem 8.1.

6.14  Lớp Flow (Flow Class)

Lớp Flow nhóm các máy chủ nguồn và đích có liên quan.

Hình 25 - Lớp Flow

Lớp cấu thành nên lớp Flow là:

System

1 hoặc nhiều. Máy chủ hoặc mạng có liên quan đến sự kiện.

Lớp Flow không có thuộc tính nào.

6.15  Lớp System (System Class)

Lớp System mô tả một hệ thống hoặc mạng có liên quan đến sự kiện. Các hệ thống và mạng được thể hiện bởi lớp này được phân loại theo vai trò của chúng trong sự cố thông qua thuộc tính category. Giá trị của thuộc tính category này chỉ ra ngữ nghĩa của các lớp kết tập trong lớp System. Nếu thuộc tính category có giá trị "source", các lớp kết tập biểu hiện các thiết bị và dịch vụ mà hoạt động này bắt đầu. Với giá trị thuộc tính category là "target" hoặc "intermediary", thiết bị hoặc dịch vụ là các mục tiêu trong hoạt động. Giá trị "sensor" chỉ ra đối tượng System là một phần của thiết bị giám sát mạng.

Hình 26 - Lớp System

Các lớp kết tập cấu thành nên lớp System là:

Node

1. Máy chủ hoặc mạng liên quan đến sự cố.

Service

0 hoặc nhiều. Dịch vụ mạng chạy trên hệ thống.

OperatingSystem

0 hoặc 1. Hệ điều hành chạy trên hệ thống.

Counter

0 hoặc 1. Bộ đếm để tổng hợp các thuộc tính của máy chủ hoặc mạng.

Description

0 hoặc 1. ML_STRING. Mô tả văn bản dạng tự do của hệ thống.

AdditionalData

0 hoặc nhiều. Cơ chế để mở rộng mô hình dữ liệu.

Lớp System có năm thuộc tính,

restriction

Tùy chọn. ENUM. Thuộc tính này được quy định trong 6.2.

category

Yêu cầu. ENUM. Phân loại vai trò của máy chủ hoặc mạng trong sự cố. Các giá trị hợp lệ là:

ext-category

Tùy chọn. STRING. Phương pháp để mở rộng thuộc tính category. Xem 8.1.

interface

Tùy chọn. STRING. Xác định giao diện hệ thống phát sinh ra một hay nhiều sự kiện. Nếu lớp Node xác định một mạng thay vì một máy chủ, thuộc tính này không có ý nghĩa gì.

spoofed

Tùy chọn. ENUM. Chỉ số mức độ tin cậy trong việc hệ thống là mục tiêu thực sự hay máy chủ tấn công. Giá trị mặc định là "unknown"

6.16  Lớp Node (Node Class)

Lớp Node đặt tên cho một hệ thống (ví dụ máy tính cá nhân hay thiết bị định tuyến) hoặc một mạng máy tính.

Lớp này được dẫn xuất từ IDMEF^[17]

Hình 27 - Lớp Node

Các lớp kết tập cấu thành nên lớp Node là:

NodeName

0 hoặc nhiều. ML_STRING. Tên của nút (ví dụ, một tên miền thỏa mãn điều kiện). Thông tin này PHẢI được cung cấp nếu không thông tin Address không được cung cấp.

Address

0 hoặc nhiều. Địa chỉ ứng dụng, mạng hoặc phần cứng của nút. Nếu NodeName không được cung cấp, ít nhất PHẢI xác định một Address.

Location

0 hoặc 1. ML_STRING. Giải thích dạng tự do vị trí vật lý của thiết bị.

DateTime

0 hoặc 1. Mã thời gian của việc thực hiện phân giải tên và địa chỉ. Thông tin này NÊN được cung cấp nếu cả Address và NodeName không được xác định.

NodeRole

0 hoặc 1. Mục đích dự kiến của nút.

Counter

0 hoặc 1. Bộ đếm để tính tổng các thuộc tính của máy chủ hoặc mạng này.

6.16.1  Lớp Counter (Counter Class)

Lớp Counter tính tổng số lần xuất hiện của một số sự kiện hoặc cung cấp số lượng hay đánh giá một số các tính năng (ví dụ, các gói tin, phiên làm việc, sự kiện...). Giá trị của biến đếm là nội dung thành phần với đơn vị của nó được thể hiện trong thuộc tính type. Đánh giá của một tính năng được cung cấp có thể được thể hiện bằng thuộc tính duration. Ngữ nghĩa hoàn chỉnh là hoàn toàn phụ thuộc ngữ cảnh dựa trên lớp mà lớp Counter kết tập.

Hình 28 - Lớp Counter Class

Lớp Counter có ba thuộc tính:

type

Yêu cầu. ENUM. Xác định đơn vị của nội dung thành phần

ext-type

Tùy chọn. Phương pháp sử dụng để mở rộng thuộc tính này. Xem 8.1. duration

Tùy chọn. ENUM. Nêu được xác định, lớp Counter thể hiện một đánh giá thay vì là một bộ đếm cho cả sự kiện. Trong trường hợp này, thuộc tính này xác định mẫu số của đánh giá (còn thuộc tính type xác định tử số). Các giá trị khả dụng của thuộc tính này được xác định trong 6.10.2.

ext-duration

Tùy chọn. STRING. Phương pháp được sử dụng để mở rộng thuộc tính duration. Xem 8.1.

6.16.2  Lớp Address (Address Class)

Lớp Address thể hiện một phần cứng (lớp 2), mạng (lớp 3), hoặc địa chỉ ứng dụng (lớp 7).

Lớp này được dẫn xuất từ IDMEF(17).

Hình 29 - Lớp Address

Lớp Address có bốn thuộc tính

category

Yêu cầu. ENUM. Kiểu của địa chỉ được thể hiện. Các giá trị hợp lệ cho thuộc tính này được chỉ ra ở dưới. Giá trị mặc định là "ipv4-addr".

ext-category

Tùy chọn. STRING. Phương pháp để mở rộng thuộc tính category. Xem 8.1.

vlan-name

Tùy chọn. STRING. Tên của mạng LAN ảo sử dụng địa chỉ này.

vlan-num

Tùy chọn. STRING, số của mạng LAN ảo sử dụng địa chỉ này.

6.16.3  Lớp NodeRole (NodeRole Class)

Lớp NodeRole giải thích chức năng dự kiến được thực hiện bởi một máy chủ nhất định.

Hình 30 - Lớp NodeRole

Lớp NodeRole có ba thuộc tính

category

Yêu cầu. ENUM. Các tính năng được cung cấp bởi một nút.

ext-category

Tùy chọn. STRING. Phương pháp để mở rộng thuộc tính category. Xem 8.1.

lang

Yêu cầu. ENUM. Mã ngôn ngữ hợp lệ theo RFC 4646 ^[7], ràng buộc bởi định nghĩa "xs:language". Giải thích của mã này được mô tả tại Điều 9.

6.17  Lớp Service (Service Class)

Lớp Service mô tả một dịch vụ mạng máy tính của một máy chủ hoặc mạng máy tính. Dịch vụ này được xác định bởi một cổng cụ thể hoặc danh sách các cổng, cùng với ứng dụng lắng nghe trên cổng đó. Khi một Service là một lớp kết tập của một System là một nguồn, khi đó dịch vụ này là nguồn của hành động được quan tâm. Ngược lại, khi Service là một lớp kết tập của một System là một đích, khi đó dịch vụ là đích của hành động được quan tâm. Lớp này được dẫn xuất từ IDMEF^[17]

Hình 31 - Lớp Service

Các lớp kết tập cấu thành nên lớp Service là:

Port

0 hoặc 1. INTEGER. Mã số cổng.

Portlist

0 hoặc 1. PORTLIST. Danh sách các số cổng được khuôn dạng theo 5.10.

ProtoCode

0 hoặc 1. INTEGER. Trường mã giao thức lớp 4 đặc trưng (ví dụ trường mã ICMP).

ProtoType

0 hoặc 1. INTEGER. Trường kiểu giao thức lớp 4 đặc trưng (ví dụ trường kiểu ICMP).

ProtoFlags

0 hoặc 1. INTEGER. Trường cờ giao thức lớp 4 đặc trưng (ví dụ trường cờ TCP).

Application

0 hoặc 1. Ứng dụng liên kết với các Port hay Portlist được xác định.

Một trong hai lớp Port hoặc Portlist PHẢI được xác định cho một thể hiện được đưa ra của lớp Service. Với một nguồn được đưa ra, System@type="source", và một đích tương ứng, System@type="target" có thể được xác định hoặc ngược lại. Khi một lớp Portlist được định nghĩa trong lớp Service của cả nguồn và đích của một thể hiện được đưa ra của lớp Flow, yêu cầu PHẢI có tính đối xứng trong liệt kê các cổng. Do đó, nếu n cổng được liệt kê cho nguồn, phải có n cổng liệt kê cho đích. Tương tự, các cổng nên được liệt kê theo một chuỗi giống nhau để cổng thứ n tại nguồn sẽ tương ứng với cổng thứ n tại đích. Tính đối xứng trong danh sách và thứ tự các cổng này được áp dụng kể cả với trường hợp nguồn-đích là 1-1, 1-nhiều, nhiều-nhiều. Trong trường hợp 1-nhiều hay nhiều-nhiều, thứ tự như vậy trong các lớp System được liệt kê trong lớp Flow là rất quan trọng.

Lớp Service có một thuộc tính:

ip_protocol

Yêu cầu. INTEGER. Số giao thức IANA.

6.17.1  Lớp Application (Application Class)

Lớp Application mô tả một ứng dụng đang chạy trên một hệ thống cung cấp một dịch vụ.

Hình 32 - Lớp Application

Lớp kết tập cấu thành nên lớp Application là:

URL

0 hoặc 1. URL URL mô tả ứng dụng.

Lớp Application có bảy thuộc tính:

swid

Tùy chọn. STRING. Định danh được sử dụng để tham chiếu đến phần mềm này.

configid

Tùy chọn. STRING. Định danh được sử dụng để tham chiếu đến cấu hình cụ thể của phần mềm này.

vendor

Tùy chọn. STRING. Tên nhà cung cấp của phần mềm.

family

Tùy chọn. STRING. Họ của phần mềm.

name

Tùy chọn. STRING. Tên của phần mềm.

version

Tùy chọn. STRING. Phiên bản của phần mềm.

patch

Tùy chọn. STRING. Bản vá hoặc gói dịch vụ của phần mềm.

6.18  Lớp System (System Class)

Lớp OperatingSystem mô tả hệ điều hành chạy trên hệ thống. Định nghĩa này giống với lớp Application. (6.17.1).

6.19  Lớp Record (record class)

Lớp Record là lớp bao cho nhật ký và dữ liệu kiểm tra cung cấp các thông tin hỗ trợ về sự cố. Nguồn của dữ liệu này thường là đầu ra của các công cụ giám sát. Những bản ghi này nên minh chứng các hoạt động mô tả trong tài liệu.

Hình 33 - Lớp Record

Lớp kết tập cấu thành nên lớp Record là:

RecordData

1 hoặc nhiều. Nhật ký hoặc dữ liệu kiểm tra được sinh ra bởi một loại cảm biến cụ thể. Các thể hiện riêng biệt của lớp RecordData NÊN được sử dụng cho mỗi kiểu cảm biến.

Lớp Record có một thuộc tính:

restriction

Tùy chọn. ENUM. Thuộc tính này được định nghĩa ở 6.2.

6.19.1  Lớp RecordData (RecordData Class)

Lớp RecordData nhóm các nhật ký hoặc dữ liệu kiểm tra từ một cảm biến cho trước (ví dụ cảm biến IDS, nhật ký tường lửa) và cung cấp một cách để chú thích các đầu ra.

Hình 34 - Lớp RecordData

Các lớp kết tập cấu thành nên lớp RecordData là:

DateTime

0 hoặc 1. Dấu thời gian của dữ liệu RecordItem

Description

1 hoặc nhiều. ML_STRING. Giải thích văn bản dạng tự do của dữ liệu RecordItem được cung cấp. Tối thiểu giải thích này nên cung cấp ý nghĩa của dữ liệu RecordItem được cung cấp.

Application

0 hoặc 1. Thông tin về cảm biến sử dụng để sinh ra dữ liệu RecordItem.

RecordPattern

0 hoặc nhiều. Chuỗi tìm kiếm để có thể tìm thấy dữ liệu có liên quan một cách chính xác trong một RecordItem.

RecordItem

1 hoặc nhiều. Dữ liệu pháp lý, kiểm tra hoặc nhật ký.

AdditionalData

0 hoặc 1. Cơ chế mở rộng dữ liệu không được thể hiện rõ ràng trong mô hình dữ liệu.

Lớp RecordData có một thuộc tính:

restriction

Tùy chọn. ENUM. Thuộc tính này được quy định trong 6.2.

6.19.2  Lớp RecordPattern (RecordPattern Class)

Lớp RecordPattern mô tả vị trí nội dung của thông tin RecordItem có liên quan. Lớp này cung cấp một cách để tham chiếu đến tập con của thông tin, xác định bởi một mẫu trong một tệp tin nhật ký, dấu vết kiểm tra hoặc dữ liệu điều tra lớn.

Hình 35 - Lớp RecordPattern

Mẫu xác định để tìm kiếm trong một RecordItem được định nghĩa trong phần nội dung của thành phần. Nó được chú thích cụ thể hơn bởi bốn thuộc tính:

type

Yêu cầu. ENUM. Mô tả cả loại mẫu được xác định trong ngữ cảnh thành phần. Giá tri mặc định là "regex".

ext-type

Tùy chọn. STRING. Phương pháp để mở rộng thuộc tính type. Xem 8.1.

offset

Tùy chọn. INTEGER, số lượng đơn vị (xác định bởi thuộc tính offsetunit) để tìm kiếm dữ liệu RecordItem trước khi đối sánh với mẫu.

offsetunit

Tùy chọn. ENUM. Mô tả các đơn vị của thuộc tính offset. Giá trị mặc định là "line".

ext-offsetunit

Tùy chọn. STRING. Phương pháp để mở rộng thuộc tính offsetunit. Xem 8.1.

instance

Tùy chọn. INTEGER. Số lượng các kiểu để áp dụng mẫu xác định.

6.19.3  Lớp RecordItem (RecordItem Class)

Lớp RecordItem cung cấp một cách để kết hợp các dữ liệu pháp lý, dấu vết kiểm tra và nhật ký liên quan để hỗ trợ đưa ra các kết luận trong quá trình phân tích sự cố. Lớp này hỗ trợ cả đóng gói trực tiếp dữ liệu và cung cấp các kiểu nguyên thủy để tham chiếu đến dữ liệu lưu ở vị trí khác. Lớp này giống với lớp AdditionalData (6.6).

7  Các yêu cầu về xử lý

Điều 7 chỉ ra các yêu cầu bổ sung trong việc tạo và phân tích tài liệu IODEF.

7.1  Mã hóa

Tất cả các tài liệu IODEF PHẢI được bắt đầu bằng một khai báo XML và phải xác định phiên bản XML đã sử dụng. Nếu mã hóa UTF-8 không được sử dụng, mã hóa ký tự cũng phải được xác định rõ. IODEF tuân thủ tất cả các quy ước và ràng buộc mã hóa dữ liệu của XML.

Khai báo XML không kèm mã ký tự được viết như sau:

<?xml version="1.0"?>

Nếu có xác định mã ký tự, khai báo XML sẽ được viết như sau:

<?xml version="1.0" encoding-"charset" ?>

Trong đó "charset" là tên của mã ký tự đã đăng ký với tổ chức cấp phát số hiệu Internet IANA, xem ^[9].

Các ký tự sau có ý nghĩa đặc biệt trong XML và phải sử dụng ứng với các tham chiếu thực thể tương ứng: "&", "<", ">", "\"" (dấu ngoặc kép), và ""(dấu ngoặc đơn). Các tham chiếu thực thể của chúng lần lượt là "&", "<", ">", """, và "'"

7.2  Không gian tên IODEF

Lược đồ IODEF khai báo không gian tên là "urn:ietf:params:xml:ns:iodef-1.0" và được đăng ký theo ^[4]. Mỗi tài liệu IODEF NÊN bao gồm một tham chiếu hợp lệ đến lược đồ IODEF sử dụng thuộc tính "xsi:schemaLocation". Ví dụ một khai báo sẽ có dạng như sau:

<IODEF-Document

version="1.00" lang="en-US"

xmlns:iodef="urn:ietf:params:xml:ns:iodef-1.0"

xsi:schemaLocation="urn:ietf:params:xmls:schema:iodef-1.0">

7.3  Sự hợp lệ

Các tài liệu IODEF phải là các tài liệu XML mẫu chuẩn và nên phù hợp với lược đồ được trình bày trong Điều 11. Tuy nhiên, chỉ tuân thủ theo lược đồ vẫn chưa đủ cho một tài liệu IODEF hợp lệ về mặt ngữ nghĩa. Có quy định cụ thể hơn trong nội dung tại Điều 6 mà chưa sẵn sàng để được mã hóa trong lược đồ và nó phải được xử lý bởi bộ phân tích cú pháp IODEF. Dưới đây là danh sách các khác biệt về những phân được mô tả chặt chẽ hơn trong tiêu chuẩn (Điều 6), nhưng không được thực thực hiện trong lược đồ IODEF:

• Các thành phần hoặc thuộc tính được khai báo là kiểu dữ liệu POSTAL, NAME, PHONE và EMAIL được sử dụng dưới dạng "xs:string", nhưng quy định các yêu cầu khuôn dạng chặt chẽ hơn đã được quy định trong tiêu chuẩn.

• Các thuộc tính IODEF-Document@lang và MLStringType@lang được khai báo là "xs:language" mà giá trị ràng buộc với các giá trị với một biểu thức chính quy. Tuy nhiên, giá trị của thuộc tính này vẫn cần phải phù hợp với danh sách của các giá trị liệt kê hợp lệ được định nghĩa trong ^[7].

• Thuộc tính MonetaryImpact@currency được khai báo là "xs:string", tuy nhiên danh sách các giá trị hợp lệ được định nghĩa trong ^[14].

• Tất cả các lớp kết tập Contact và EventData là tùy chọn trong lược đồ, tuy nhiên ít nhất một trong các lớp kết tập này PHẢI tồn tại.

• Có nhiều quy ước có thể được sử dụng để phân loại một hệ thống sử dụng lớp NodeRole hoặc để xác định phần mềm với các lớp Application và OperatingSystem. Bộ phân tích cú pháp IODEF PHẢI chấp nhận các báo cáo sự cố không sử dụng các trường này để phù hợp với các quy ước cục bộ.

• Thuộc tính Confidence@rating xác định nội dung thành phần của Confidence là rỗng hay không.

• Thuộc tính Address@type xác định khuôn dạng của nội dung thành phần.

• Các thuộc tính AdditionalData@dtype và RecordItem@dtype dẫn xuất từ iodef:ExtensionType xác định ngữ nghĩa và khuôn dạng của nội dung thành phần.

• Tính đối xứng trong các cổng liệt kê của lớp Portlist là yêu cầu giữa nguồn và đích (xem 6.17).

8  Mở rộng lODEF

Để có thể hỗ trợ hành động thay đổi của các CSIRT, mô hình dữ liệu IODEF cần được phát triển cùng với các thay đổi này. Điều 8 đề cập về việc các thành phần dữ liệu mới không được biểu diễn trong mô hình dữ liệu có thể được tích hợp vào IODEF như thế nào. Các kỹ thuật này được thiết kế để cho việc thêm các dữ liệu mới mà không cần phải thay đổi lược đồ IODEF. Với các giá trị đã được khẳng định, các phần mở rộng đã được xây dựng tốt có thể được tích hợp vào các phiên bản tiếp theo tiêu chuẩn này. Tuy nhiên, tiếp cận này cũng đồng thời hỗ trợ các phần mở rộng riêng chỉ liên quan đến một nhóm kín các đơn vị công tác.

8.1  Mở rộng các giá trị liệt kê của các thuộc tính

Mô hình dữ liệu hỗ trợ các phương tiện cho phép thêm vào các giá trị liệt kê mới cho một thuộc tính. Đối với mỗi thuộc tính hỗ trợ kỹ thuật mở rộng này, có một thuộc tính tương ứng trong cùng thành phần với tên giống nhau nhưng ít hơn một tiền tố "ext-". Thuộc tính đặc biệt này được coi là thuộc tính mở rộng và thuộc tính được mở rộng được coi là thuộc tính có khả năng mở rộng. Ví dụ, một thuộc tính có khả năng mở rộng tên là "foo" sẽ có một thuộc tính mở rộng tương ứng tên là "ext-foo". Một thành phần có thể có nhiều thuộc tính được mở rộng, do đó có nhiều mở rộng, thuộc tính.

Bên cạnh các thuộc tính mở rộng tương ứng, mỗi thuộc tính mở rộng có một giá trị "ext-value" như là một trong các giá trị khả năng của nó. Giá trị cụ thể này có tác dụng như chuỗi thoát và không có ý nghĩa hợp lệ.

Để có thể thêm vào một giá trị liệt kê mới cho một thuộc tính được mở rộng, giá trị của thuộc tính nảy PHẢI được đặt là "ext-value" và giá trị mới mong muốn PHẢI được đặt theo thuộc tính được mở rộng tương ứng. Ví dụ, một thể hiện mở rộng của kiểu thuộc tính của lớp Impact sẽ có dạng như sau:

<Impact type="ext-value" ext-type="new-attack-type">

Thuộc tính mở rộng đã cho PHẢI KHÔNG mang giá trị trừ khi thuộc tính được mở rộng tương ứng đã được đặt là "ext-value".

8.2  Mở rộng các lớp

Các lớp của mô hình dữ liệu chỉ có thể được mở rộng thông qua việc sử dụng các lớp AdditionalData và RecordItem. Những lớp bao này, gọi chung là các lớp mở rộng, được sử dụng là kiểu dữ liệu iodef:ExtensionType trong lược đồ. Những lớp này cung cấp khả năng thêm mới các thành phần dữ liệu cơ bản hoặc đã mã hóa XML trong tất cả các lớp cấp cao nhất của lớp Incident và một vài lớp con phức tạp hơn. Do có nhiều thể hiện của các lớp mở rộng trong mô hình dữ liệu, vị trí thêm các thành phần dữ liệu mới là tùy chọn. Khuyến nghị các phần mở rộng nên được đặt trong lớp có liên quan nhất với thông tin mới thêm vào.

Các phần mở rộng sử dụng các kiểu dữ liệu cơ bản nghĩa là (tất cả các giá trị của thuộc tính dtype ngoài "xml") PHẢI:

1. Đặt nội dung thành phần của lớp mở rộng bằng các giá trị mong muốn, và

2. Đặt thuộc tính dtype tương ứng với kiểu dữ liệu của các nội dung thành phần.

Các hướng dẫn sau dành cho các phần mở rộng sử dụng XML:

1. Nội dung thành phần của các lớp mở rộng phải được gán giá trị mong muốn và thuộc tính dtype PHẢI được đặt là "xml".

2. Lược đồ mở rộng phải được khai báo ở một không gian tên riêng biệt. KHUYẾN NGHỊ các phần mở rộng này có tiền tố "iodef-".

3. KHUYẾN NGHỊ các lược đồ mở rộng tuân thủ quy tắc đặt tên của mô hình IODEF. Tên của tất cả các thành phần được viết hoa. Đối với các tên ghép, mỗi một từ sử dụng một ký tự viết hoa. Tên các thuộc tính là viết thường.

4. Khi bộ phân tích xử lý một tài liệu IODEF với phần mở rộng nó không nhận ra, phần mở rộng này PHẢI bị bỏ qua (và không được xử lý), tuy nhiên phần còn lại của tài liệu PHẢI được xử lý. Các bộ phân tích có thể xác định các phần mở rộng này dù chúng không có lô gíc xử lý thông qua khai báo không gian tên. Các bộ phân tích gặp phải các thành phần không nhận ra được trong không gian tên mà chúng hỗ trợ NÊN từ chối tài liệu này thông qua lỗi cú pháp.

5. Các thực thi KHÔNG NÊN tải các lược đồ về tại thời điểm chạy vì các lý do an toàn và các phần mở rộng KHÔNG được đòi hỏi cung cấp vị trí phân giải được trong lược đồ.

Lược đồ dưới đây và trích đoạn tài liệu XML cung cấp mẫu cho một lược đồ mở rộng và việc áp dụng trong tài liệu IODEF.

Lược đồ mẫu này định nghĩa một không gian tên "iodef-extension1" với một thành phần duy nhất là "newdata"

Trích đoạn XML dưới đây mô phỏng cách sử dụng lược đồ trên như phần mở rộng cho IODEF:

9  Các vấn đề trong quốc tế hóa

Quốc tế hóa và bản địa hóa là một trong các mối quan tâm cụ thể việc trao đổi dữ liệu theo chuẩn IODEF vì một số sự cố chỉ được giải quyết thông qua cộng tác và phải vượt qua các rào cản ngôn ngữ. IODEF hỗ trợ yêu cầu này bằng cách phụ thuộc vào cấu trúc XML và thông qua các lựa chọn thiết kế mô hình dữ liệu cụ thể.

Vì IODEF được thực thi dưới dạng một lược đồ XML, nó ngầm định hỗ trợ tất cả các mã ký tự khác nhau như UTF-8 và UTF-16, nhờ sự hỗ trợ của XML. Bên cạnh đó, mỗi tài liệu IODEF PHẢI xác định ngôn ngữ mà nội dung của nó được mã hóa. Ngôn ngữ này có thể được xác định với thuộc tính "xml:lang" (theo 2.12 của ^[1]) trong thành phần mức cao nhất (cụ thể là IODEF-Document@lang) và cho phép tất cả các thành phần khác thừa kế định nghĩa này. Tất cả các lớp IODEF với các định nghĩa văn bản dạng tự do (tất cả các lớp định nghĩa theo kiểu iodef:MLStringType) cũng đồng thời có thể xác định một ngôn ngữ khác với phần còn lại của tài liệu. Mã ngôn ngữ hợp lệ cho thuộc tính "xml:lang" được trình bày trong RFC 4646 ^[7].

Mô hình dữ liệu hỗ trợ nhiều bản dịch các văn bản dạng tự do. Ở những phần văn bản được sử dụng với mục đích giải thích, lớp đã cho luôn luôn có một hoặc nhiều tập hợp đến lớp cha (ví dụ, lớp Description). Mục đích là để cho các văn bản giống nhau có thể được mã hóa theo các thể hiện khác nhau của cùng một lớp, nhưng mỗi thể hiện dùng một ngôn ngữ khác nhau. Tiếp cận này cho phép tác giả tài liệu IODEF có thể gửi cùng một tài liệu đến người nhận sử dụng các ngôn ngữ khác nhau. Bộ phân tích cú pháp IODEF NÊN trích xuất ngôn ngữ thích hợp với người nhận.

Mặc dù mục đích của mô hình dữ liệu là để cung cấp khả năng quốc tế hóa và bản địa hóa, mục đích này sẽ không như vậy nếu phương hại đến tính liên thông. Trong khi IODEF có hỗ trợ các ngôn ngữ khác nhau, mô hình dữ liệu cũng phụ thuộc mạnh vào các thuộc tính liệt kê đã được chuẩn hóa có thể xác định gần đúng nội dung của tài liệu. Với tiếp cận này, CSIRT nên có khả năng giải nghĩa một tài liệu IODEF nó nhận được ngay cả khi các thành phần dữ liệu văn bản được viết bằng ngôn ngữ không quen thuộc với nhà phân tích.

10  Ví dụ

Điều này cung cấp các ví dụ về mã hóa sự cố trong IODEF. Những ví dụ này không nhất thiết là cách duy nhất để mã hóa một sự cố cụ thể.

10.1  Sâu máy tính

Ví dụ báo cáo của CSIRT về một thể hiện của sâu Code Red:

10.2  Thăm dò

Một ví dụ báo cáo của CSIRT về hoạt động dò quét:

10.3. Báo cáo về Bot-net

Một ví dụ báo cáo của CSIRT về mạng bot-net:

10.4. Danh mục theo dõi

Một ví dụ báo cáo của CSIRT về một danh mục theo dõi:

11. Lược đồ IODEF

12. Xem xét về an toàn

Mô hình dữ liệu IODEF không trực tiếp xem xét về các vấn đề an toàn. Thay vào đó, nó chỉ đơn giản xác định một biễu diễn cho thông tin sự cố. Do dữ liệu được mã hóa bởi IODEF có thể được coi là riêng tư nhạy cảm bởi các bên trao đổi thông tin hoặc những bên mà thông tin này mô tả, việc xem xét là cần thiết để đảm bảo việc tiết lộ thông tin phù hợp trong cả quá trình trao đổi tài liệu và quá trình xử lý tiếp theo. Quá trình trao đổi tài liệu được xử lý bởi khuôn dạng thông điệp, nhưng rủi ro trong quá trình xử lý sau đó phải được giải quyết bằng các hệ thống xử lý, lưu trữ tài liệu IODEF và thông tin thu được từ những dữ liệu này.

Nội dung của tài liệu IODEF có thể bao gồm yêu cầu hành động hoặc bộ phân tích cú pháp IODEF có thể sử dụng lô gíc độc lập để đưa ra một số quyết định dựa trên thông tin mà nó tìm thấy. Vì lý do này, bộ phân tích cần phải có các xem xét để xác thực đúng người nhận tài liệu và gắn thêm các thuộc tính tin cậy phù hợp với dữ liệu trước hành động.

Giao thức và khuôn dạng thông điệp cơ bản được sử dụng để trao đổi các thể hiện của IODEF PHẢI đảm bảo sự tin cậy, toàn vẹn, bí mật. Khuyến khích sử dụng giao thức bảo mật tiêu chuẩn. Giao thức RID (Real-time Inter-network Defense) và các giao thức trao đổi tương ứng gắn với IODEF/RID trên SOAP có thể đảm bảo các yêu cầu này.

Để xử lý dữ liệu và hướng dẫn xử lý cho các thông tin đã mã hóa, IODEF cho phép người gửi tài liệu có thể đưa ra các chính sách riêng tư bằng cách sử dụng thuộc tính hạn chế. Các thể hiện khác nhau của thuộc tính cho phép các thành phần dữ liệu khác nhau của tài liệu sử dụng các chính sách không đồng nhất khác nhau. Mặc dù khá linh hoạt, cần phải nhấn mạnh rằng phương pháp này chỉ được coi như hướng dẫn cho người gửi, người nhận có thể bỏ qua. Vấn đề thực thi không phải là vấn đề kỹ thuật.

13. Tài liệu mở rộng

13.1  Giới thiệu

Điều 14 là tài liệu mở rộng cho đặc tả IODEF đã được nêu trong các Điều từ 4 đến 12 của Tiêu chuẩn.

Môi trường đe dọa đã phát triển cùng với các thực nghiệm trong phòng thủ mạng máy tính. Các xu thế này, cùng với kinh nghiệm thu được thông qua việc thực hiện và triển khai đã chỉ ra nhu cầu của việc mở rộng IODEF. Điều 14 này cung cấp hướng dẫn cho việc xác định các mở rộng này. Điều 14 bắt đầu bằng việc giải thích tính áp dụng của các phần mở rộng IODEF và các cơ chế của mở rộng IODEF trước khi đưa ra tại (Phụ lục A) các mẫu làm điểm bắt đầu cho các dự thảo tiêu chuẩn mở rộng IODEF trong tương lai.

Điều 14 cung cấp hướng dẫn cho các phần mở rộng của IODEF, đặc biệt cho các tác giả phát triển các phần mở rộng mới. Không có nội dung nào trong điều này có thể được coi là xác định các quy tắc cho định nghĩa của các phần mở rộng này.

13.2. Áp dụng mở rộng cho IODEF

Trước khi quyết định mở rộng IODEF, bước đầu tiên là xác định liệu phần mở rộng của IODEF có phù hợp với vấn đề đưa ra hay không. Có hai mặt liên quan đến câu hỏi này:

- Vấn đề có liên quan hay không đến việc báo cáo hoặc chia sẻ các theo dõi, chỉ dẫn hoặc các thông tin khác liên quan đến một sự cố, có thể đang diễn ra hay đã hoàn thành cụ thể là giả thuyết hay thực tế? Thuật ngữ "Sự cố" được định nghĩa trong tài liệu RFC 3067: một sự kiện liên quan đến vi phạm an toàn thông tin, dù là của một nhóm hay của một cá nhân. Nếu câu trả lời cho câu hỏi này rõ ràng là "Không" thì IODEF có thể không phải là lựa chọn tốt như là một công nghệ cơ sở cho phạm vi ứng dụng này.

- IODEF có thể thể hiện thông tin của sự cố một cách đầy đủ nếu không có phần mở rộng hay không? IODEF có một tập phong phú các lớp có liên quan đến sự cố. Nếu sau quá trình kiểm tra chi tiết của phạm vi vấn đề và đặc tả IODEF cùng với việc tham khảo ý kiến của các chuyên gia IODEF và câu trả lời cho câu hỏi này là "Có" thì phần mở rộng này là không cần thiết.

Ví dụ về các phần mở rộng cho IODEF có thể bao gồm:

Phát triển các kết quả đã thực hiện trong việc giải thích các khía cạnh của sự cố để giúp cho IODEF phong phú hơn bằng các tham chiếu chuẩn hóa đến các thông tin bên ngoài dựa trên sự cố và các thông tin liên quan đến sự cố.

Cho phép mô tả các kiểu mới của thực thể (ví dụ, các tác nhân liên quan) hoặc các kiểu của đặc tính thực thể (ví dụ, thông tin liên quan đến các dịch vụ tài chính) liên quan đến một báo cáo sự cố IODEF:

Cho phép việc thể hiện các kiểu mới trong theo dõi, chỉ dẫn hoặc các sự cố trong một báo cáo sự cố IODEF:

Cho phép các lược đồ mở rộng hoặc ghi nhãn siêu dữ liệu cho các tài liệu IODEF (ví dụ, cho các chỉ dẫn xử lý hoặc sắp đặt, hoặc tuân thủ theo các quy định lưu trữ và an toàn dữ liệu).

13.3  Lựa chọn cơ chế cho phần mở rộng IODEF

IODEF được thiết kế để có thể mở rộng thông qua việc kết hợp các phương pháp sau:

- Mở rộng các giá trị liệt kê của các thuộc tính theo 8.1.

- Mở rộng các lớp thông qua các thành phần AdditionalData hoặc RecordItem, theo 8.2, và/hoặc

- Lưu trữ các thành phần tài liệu IODEF trong một tài liệu XML bên ngoài, bản thân có chứa các dữ liệu mở rộng, được thực hiện bởi Real-time Inter-network Defense (RID) [RFC 6545].

Lưu ý là trong trường hợp cuối, phần mở rộng không trực tiếp tương hợp với các thực thi IODEF và nó phải "mở" tài liệu IODEF từ lớp của nó. Tuy nhiên, việc này có thể phù hợp với một số trường hợp sử dụng liên quan đến việc tích hợp IODEF trong các lược đồ ngoài. Các phần mở rộng sử dụng việc bao hàm tài liệu IODEF không được phân tích trong tiêu chuẩn này, mặc dù các mẫu tài liệu trong Phụ lục A có thể sử dụng một số trong trong việc định nghĩa chúng.

Một số thuộc tính chứa các giá trị kiểu liệt kê bên trong một số các thành phần IODEF nhất định có thể được mở rộng. Ví dụ đối với một thuộc tính có tên là "foo", việc này có thể được thực hiện thông qua việc cung cấp cho "foo" một giá trị "ext-value" và thêm một thuộc tính đặt tên là "ext-foo" chứa giá trị được mở rộng. Thuộc tính có thể được mở rộng theo cách này giới hạn cho các thuộc tính sau, thể hiện với khuôn dạng "Element@attribute", tham khảo thêm mục các thuộc tính này được định nghĩa tại tiêu chuẩn này như sau:

lncident@purpose, tại 6.2

AdditionalData@dtype, tại 6.6

Contact@role, tại 6.7

Contact@type, tại 6.7

RegistryHandle@registry, tại 6.7.1

Impact@type, tại 6.10.1

TimeImpact@metric, 6.10.2

TimeImpact@duration, tại 6.10.2

HistoryItem@action, tại 6.11.1

Expectation@action, tại 6.13

System@category, tại 6.15

Counter@type, tại 6.16.1

Counter@duration, tại 6.16.1

Address@category, tại 6.16.2

NodeRole@category, tại 6.16.3

RecordPattern@type, tại 6.19.2

RecordPattern@offsetunit, tại 6.19.2

RecordItem@dtype, tại 6.19.3.

Lưu ý là danh sách này là hiện hành tại thời điểm ban hành tiêu chuẩn; tập các kiểu dữ liệu IODEF có thể được mở rộng bởi các bản đặc tả trong các bản cập nhật trong tương lai của tiêu chuẩn này.

Một ví dụ định nghĩa của một mở rộng thuộc tính được đưa ra trong Phụ lục B.

Tài liệu IODEF có thể chứa các dữ liệu vô hướng được mở rộng hoặc các dữ liệu XML sử dụng thành phần AdditionalData hoặc RecordItem. Các thành phần mở rộng dữ liệu vô hướng phải đặt thuộc tính "dtype" của thành phần chứa nó theo kiểu dữ liệu của các thành phần tham chiếu đến các kiểu dữ liệu IODEF dạng liệt kê theo Điều 5, và kiểu dữ liệu này nên sử dụng thuộc tính "meaning" và "formatid" để giải thích nội dung của thành phần.

Các thành phần mở rộng XML bên trong thành phần AdditionalData hoặc RecordItem sử dụng dtype là "xml" và chúng nên định nghĩa một lược đồ cho thành phần chứa ở mức cao nhất bên trong thành phần AdditionalData hoặc RecordItem. Một ví dụ xác định một định nghĩa thành phần được đưa ra trong Phụ lục C.

Khi thêm các thành phần vào mục AdditionalData của một tài liệu IODEF, không gian tên và lược đồ của phần mở rộng phải được đăng ký với IANA; xem Phụ lục A.6 để biết chi tiết.

13.4  Các xem xét an toàn

Điều 13 không đưa ra các vấn đề an toàn. Các phần mở rộng đã được định nghĩa sử dụng mẫu trong Phụ lục A cần phải cung cấp một bản phân tích về các vấn đề an toàn có thể xảy ra. Xem Phụ lục A.5 để biết chi tiết.

Phụ lục A

(Tham khảo)

Mẫu tài liệu

Phụ lục này đưa ra mẫu tài liệu giải nghĩa một mở rộng IODEF: Mẫu này mang tính chất tham khảo.

A.1. Giới thiệu

Mục này giới thiệu đưa ra các vấn đề có thể được giải quyết bởi phần mở rộng và thúc đẩy việc phát triển và triển khai phần mở rộng.

A.2. Thuật ngữ

Mục này cung cấp và định nghĩa các thuật ngữ dành riêng cho tài liệu. Thuật ngữ của tiêu chuẩn này hoặc thuật ngữ tại RFC 6545 nên được tham chiếu trong mục này, nhưng không định nghĩa lại hoặc sao chép lại. Nếu các thuật ngữ RFC 2119 được sử dụng trong tài liệu, việc này nên được ghi lại trong Thuật ngữ.

A.3. Tính áp dụng

Mục này định nghĩa các trường hợp sử dụng mà phần mở rộng có thể áp dụng được và chi tiết hóa các phân tích yêu cầu được thực hiện trong quá trình phát triển phần mở rộng. Mục tiêu chính của mục này là cho phép người đọc có thể xem phần mở rộng có thực sự hướng đến giải quyết vấn đề đã đưa ra hay không. Mục này cũng đồng thời định nghĩa và giới hạn phạm vi của phần mở rộng cho phù hợp bằng cách chỉ ra các tình huống không rõ ràng mà phần mở rộng đó không có hướng đến áp dụng.

Bên cạnh việc định nghĩa tính áp dụng, mục này cũng đưa ra các tình huống ví dụ, sau đó sẽ được trình bày chi tiết trong ví dụ ở dưới.

A.4. Định nghĩa phần mở rộng

Mục này định nghĩa phần mở rộng.

Các phần mở rộng là các kiểu liệt kê được định nghĩa ở một phần trong mỗi thuộc tính được mở rộng, liệt kê các giá trị mới với một giải thích về ý nghĩa của mỗi giá trị mới. Ví dụ về phần mở rộng liệt kê được đưa ra ở Phụ lục B bên dưới.

Các phần mở rộng thành phần được định nghĩa ở một phần cho mỗi thành phần, theo thứ tự từ trên xuống, từ thành phần được chứa trong AdditionalData hoặc RecordItem. Ví dụ về phần mở rộng thành phần được đưa ra trong Phụ lục C bên dưới. Mỗi một thành phần nên được mô tả bằng một biểu đồ UML như ở Hình A.1, theo sau đó là giải nghĩa của mỗi thuộc tính và một giải nghĩa ngắn của mỗi thành phần con. Các thành phần con sau đó nên được định nghĩa trong tiểu mục tiếp theo nếu chưa được định nghĩa trong bản thân tài liệu IODEF, hoặc các tài liệu mở rộng IODEF đã được tham chiếu khác.

Hình A.1 - Ví dụ biểu đồ UML của các thành phần

Các thành phần chứa các thành phần con nên chỉ ra bội số của các thành phần con này, như thể hiện trong hình trên. Các kiểu dữ liệu cho phép được liệt kê trong Điều 5 của tiêu chuẩn này.

A.5. Xem xét an toàn

Bất kỳ xem xét an toàn nào [RFC 3552] đã đưa ra bởi phần mở rộng này hoặc triển khai của nó nên được nêu chi tiết trong mục này. Các hướng dẫn nên tập trung vào việc bảo đảm an toàn cho người sử dụng của phần mở rộng này với chú ý đặc biệt đến những tác động không rõ ràng của việc truyền tải thông tin thể hiện bởi phần mở rộng này. RFC 3552 có thể là tài liệu tham khảo hữu ích trong việc xác định những gì cần phải đề cập trong Mục này.

Cần phải lưu ý trong mục này là các xem xét an toàn cho IODEF tại Điều 12 của tiêu chuẩn này cũng đồng thời áp dụng cho phần mở rộng này.

A.6. Các xem xét về khả năng quản lý

Nếu bất kỳ xem xét nào về hoạt động và/hoặc quản lý liệt kê trong Phụ lục A của RFC 5706 áp dụng cho phần mở rộng này, cần phải nhắc đến chúng trong mục này. Nếu không có xem xét nào được áp dụng, mục này có thể được bỏ qua.

A.7. Phụ lục A: Định nghĩa lược đồ XML cho phần mở rộng

Lược đồ XML mô tả các thành phần định nghĩa trong Mục A.4 được đưa ra ở đây. Mỗi ví dụ trong Phụ lục A.8 sẽ được kiểm tra để xác nhận với lược đồ này bằng các công cụ tự động.

A.8. Phụ lục B: Ví dụ

Mục này chứa các ví dụ tài liệu IODEF minh họa phần mở rộng. Nếu tình huống ví dụ đã được nêu trong mục A.3, các tài liệu cho những ví dụ này nên được cung cấp theo đúng thứ tự trong mục A.3. Các tài liệu ví dụ sẽ được kiểm tra để xác nhận với các lược đồ được đưa ra trong phụ lục.

Phụ lục B

(Tham khảo)

Ví dụ định nghĩa phần mở rộng kiểu liệt kê: Thuyết trình hành động

Ví dụ này mở rộng thành phần IODEF Expectation để thể hiện các kỳ vọng mà bộ trình bày có thể được tạo ra từ sự cố IODEF và một bản thuyết trình sẽ được đưa ra sau đó bởi tổ chức của người nhận.

Thuộc tính: Expectation@action

Giá trị mở rộng: give-a-presentation

Ý nghĩa của giá trị: Sinh ra một bộ trình bày từ các thông tin sự cố đã được cung cấp và sau đó đưa ra một bản thuyết trình

Xem xét thêm: Khuôn dạng của bộ trình bày để cho người nhận xác định cho phù hợp với thực tiễn đã được thiết lập cho việc trình bày báo cáo sự cố.

Phụ lục C

(Tham khảo)

Ví dụ định nghĩa thành phần: Test

Ví dụ này định nghĩa lớp Test để ghi nhãn cho dữ liệu kiểm thử IODEF.

Lớp Test được thiết kế để nằm bên trong thành phần AdditionalData trong tài liệu IODEF: Nếu thành phần Test có tồn tại, nó chỉ ra rằng tài liệu IODEF chứa các dữ liệu kiểm thử, không phải là thông tin về một sự cố có thực.

Lớp Test chứa các thông tin về việc làm thế nào mà dữ liệu kiểm thử được tạo ra.

Hình C.1 - Lớp Test

Lớp Test có hai thuộc tính:

category: Yêu cầu. ENUM. Kiểu của dữ liệu kiểm thử. Các giá trị cho phép của thuộc tính này được viết phía dưới. Giá trị mặc định là "unspecified"

1. unspecified. Tài liệu này chứa dữ liệu kiểm thử, ngoài ra không có thông tin nào được cung cấp thêm

2. internal. Dữ liệu kiểm thử được thiết kế cho mục đích sử dụng nội bộ của thực thi, và không nên phân phối hoặc sử dụng bên ngoài phạm vi mà dữ liệu này được sinh ra.

3. unit. Dữ liệu kiểm thử được thiết kế cho kiểm thử đơn vị của một cài đặt. Nó có thể được đi kèm với cài đặt để hỗ trợ như một phần của quá trình xây dựng và triển khai.

4. interoperability. Dữ liệu kiểm thử được thiết kế cho việc kiểm thử khả năng tương tác của một cài đặt, và nó có thể được chia sẻ không giới hạn để hỗ trợ mục đích này.

generator: Tùy chọn. STRING. Một chuỗi dạng tự do xác định người, thực thể hoặc chương trình đã sinh ra dữ liệu kiểm thử.

Thư mục tài liệu tham khảo

[1] World Wide Web Consortium, "Extensible Markup Language (XML)1.0 (Second Edition)", W3C Recommendation, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.

[2] World Wide Web Consortium, "XML XML Schema Part 1: Structures Second Edition", W3C Recommendation, October 2004, <http://www.w3.org/TR/xmlschema-1/>.

[3] World Wide Web Consortium, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, October 2004, <http://www.w3.org/TR/xmlschema-2/>.

[4] World Wide Web Consortium, "Namespaces in XML", W3C Recommendation, January 1999, <http://www.w3.org/TR/REC-xml-names/>.

[5] World Wide Web Consortium, "XML Path Language (XPath) 2.0", W3C Candidate Recommendation, June 2006, <http://www.w3.org/TR/Xpath20/>.

[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.

[7] Philips, A. and M. Davis, "Tags for Identifying of Languages", RFC 4646, September 2006.

[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 3986, January 2005.

[9] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 2978, October 2000.

[10] Sciberras, A., "Schema for User Applications", RFC 4519, June 2006.

[11] Resnick, P., "Internet Message Format", RFC 2822, April 2001.

[12] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.

[13] International Organization for Standardization, "International Standard: Data elements and interchange formats - Information interchange - Representation of dates and times", ISO 8601, Second Edition, December 2000.

[14] International Organization for Standardization, "International Standard: Codes for the representation of currencies and funds, ISO 4217:2001", ISO 4217:2001, August 2001.

[15] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.

[16] Keeni, G., Demchenko, Y., and R. Danyliw, "Requirements for the Format for Incident Information Exchange (FINE)", Work in Progress, June 2006.

[17] Debar, H., Curry, D., Debar, H., and B. Feinstein, "Intrusion Detection Message Exchange Format", RFC 4765, March 2007.

[18] Moriarty, K., "Real-time Inter-network Defense", Work in Progress, April 2007.

[19] Moriarty, K. and B. Trammell, "IODEF/RID over SOAP", Work in Progress, April 2007.

[20] Shafranovich, Y., "Common Format and MIME Type for Comma-Separated Values (CSV) File", RFC 4180, October 2005.

[21] R. Danyliw, J. Meijer, Y. Demchenko "The Incident Object Description Exchange Format", RFC 5070, December 2007.

[22] B. Trammell, "Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format", RFC 6684, July 2012.

MỤC LỤC

1  Phạm vi áp dụng

2  Tài liệu viện dẫn

3  Thuật ngữ và chữ viết tắt

4  Tổng quan

4.1  Giới thiệu

4.2  Ký pháp

4.3  Giới thiệu mô hình dữ liệu IODEF

4.4  Về việc tạo lập IODEF

5   Các kiểu dữ liệu IODEF

5.1  Số nguyên (Integers)

5.2  Số thực (Real)

5.3  Ký tự và chuỗi ký tự (Characters and Strings)

5.4  Chuỗi đa ngôn ngữ (Multilingual Strings)

5.5  Bytes

5.6  Byte thập lục phân (Hexadecimal Bytes)

5.7  Kiểu liệt kê (Enumerated Bytes)

5.8  Chuỗi ngày giờ (Date-Time Strings)

5.9  Chuỗi múi giờ (Timezone string)

5.10  Danh sách cổng (Port Lists)

5.11  Địa chỉ bưu điện (Postal Address)

5.12  Cá nhân hoặc tổ chức (Person or Organization)

5.13  Số điện thoại và Fax (Telephone and Fax Numbers)

5.14  Chuỗi Email (Email String)

5.15  Chuỗi định vị tài nguyên thống nhất (Uniform Resource Locator strings)

6  Mô hình dữ liệu IODEF

6.1  Lớp lODEF-Document (lODEF-Document Class)

6.2  Lớp Incident (Incident Class)

6.3  Lớp IncidentID (IncidentID Class)

6.4  Lớp AlternativeID (AlternativelD Class)

6.5  Lớp RelatedActivity (RelatedActivity Class)

6.6  Lớp AdditionalData (AdditionalData Class)

6.7  Lớp Contact (Contact Class)

6.7.1  Lớp RegistryHandle (Registry Handle Class)

6.7.2  Lớp PostalAddress (PostalAddress Class)

6.7.3  Lớp Email (Email Class)

6.7.4  Lớp Telephone và Fax (Telephone and Fax Classes)

6.8  Lớp Time (Time Classes)

6.8.1  StartTime

6.8.2  EndTime

6.8.3  DetectTime

6.8.4  ReportTime

6.8.5  DateTime

6.9  Lớp Method (Method Class)

6.9.1  Lớp Reference (Reference Class)

6.10  Lớp Assessment (Assessment Class)

6.10.1  Lớp Impact (Impact Class)

6.10.2  Lớp TimeImpact (TimeImpact Class)

6.10.3  Lớp MonetaryImpact (MonetaryImpact Class)

6.10.4  Lớp Confidence (Confidence Class)

6.11  Lớp History (History Class)

6.11.1  Lớp HistoryItem (HistoryItem Class)

6.12  Lớp EventData (EventData Class)

6.12.1  Mối liên hệ giữa các lớp Incident và EventData

6.12.2  Thành phần của EventData

6.13  Lớp Expectation (Expectation Class)

6.14  Lớp Flow (Flow Class)

6.15  Lớp System (System Class)

6.16  Lớp Node (Node Class)

6.16.1  Lớp Counter (Counter Class)

6.16.2  Lớp Address (Address Class)

6.16.3  Lớp NodeRole (NodeRole Class)

6.17  Lớp Service (Service Class)

6.17.1  Lớp Application (Application Class)

6.18  Lớp System (System Class)

6.19  Lớp Record (record class)

6.19.1  Lớp Record Data (RecordData Class)

6.19.2  Lớp RecordPattern (RecordPattern Class)

6.19.3  Lớp RecordItem (RecordItem Class)

7  Các yêu cầu về xử lý

7.1  Mã hóa

7.2  Không gian tên IODEF

7.3  Sự hợp lệ

8  Mở rộng IODEF

8.1  Mở rộng các giá trị liệt kê của các thuộc tính

8.2  Mở rộng các lớp

9  Các vấn đề trong quốc tế hóa

10  Ví dụ

10.1  Sâu máy tính

10.2  Thăm dò

10.3.  Báo cáo về Bot-net

10.4.  Danh mục theo dõi

11. Lược đồ IODEF

12. Xem xét về an toàn

13. Tài liệu mở rộng

13.1  Giới thiệu

13.2.  Áp dụng mở rộng cho IODEF

13.3  Lựa chọn cơ chế cho phần mở rộng IODEF

13.4  Các xem xét an toàn

Phụ lục A (tham khảo): Mẫu tài liệu

A.1. Giới thiệu

A.2. Thuật ngữ

A.3. Tính áp dụng

A.4. Định nghĩa phần mở rộng

A.5. Xem xét an toàn

A.6. Các xem xét về khả năng quản lý

A.7. Phụ lục A: Định nghĩa lược đồ XML cho phần mở rộng

A.8. Phụ lục B: Ví dụ

Phụ lục B (tham khảo): Ví dụ định nghĩa phần mở rộng kiểu liệt kê: Thuyết trình hành động

Phụ lục C (tham khảo): Ví dụ định nghĩa thành phần: Test

Thư mục tài liệu tham khảo