TCVN 8709-1:2011 ISO/IEC 15408-1:2009 Các tiêu chí đánh giá an toàn CNTT-Phần 1: Giới thiệu và mô hình tổng quát

TIÊU CHUẨN QUỐC GIA

TCVN 8709-1:2011

ISO/IEC 15408-1:2009

CÔNG NGHỆ THÔNG TIN - CÁC KỸ THUẬT AN TOÀN CÁC TIÊU CHÍ ĐÁNH GIÁ AN TOÀN CNTT - PHẦN 1: GIỚI THIỆU VÀ MÔ HÌNH TỔNG QUÁT

lnformation Technology - Security Techniques - Evaluation Criteria for IT Security -Part 1: Introduction and General Model

Lời nói đầu

TCVN 8709-1:2011 hoàn toàn tương đương ISO/IEC 15408-1:2008

TCVN 8709-1:2011 do Trung tâm Ứng cứu khẩn cấp máy tính Việt Nam 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ố. .

Lời giới thiệu

Tiêu chuẩn này cho phép thực hiện so sánh các kết quả đánh giá an toàn độc lập. Tiêu chuẩn cung cấp một tập các yêu cầu chung về chức năng an toàn cho các sản phẩm công nghệ thông tin (CNTT), và về các biện pháp đảm bảo áp dụng cho các sản phẩm này trong quá trình đánh giá an toàn. Các sản phẩm CNTT này có thể dưới dạng phần cứng, phần sụn hay phần mềm.

Quy trình đánh giá thiết lập một mức tin cậy về việc các chức năng an toàn cho các sản phẩm CNTT và các biện pháp đảm bảo áp dụng cho chúng thỏa mãn các yêu cầu nêu trên. Các kết quả đánh giá có thể giúp người dùng xác định xem sản phẩm hoặc hệ thống CNTT có thỏa mãn yêu cầu đảm bảo an toàn của chúng hay không.

TCVN 8709 là một chỉ dẫn bổ ích cho phát triển, đánh giá và/hoặc đầu tư các sản phẩm CNTT với chức năng an toàn.

TCVN 8709 có tính mềm dẻo, cho phép áp dụng nhiều phương pháp đánh giá cho nhiều đặc tính an toàn của đa dạng sản phẩm CNTT. Chính vì vậy, người dùng tiêu chuẩn này cần thận trọng khi áp dụng để tránh lạm dụng nó. Ví dụ, nếu sử dụng TCVN 8709 kết hợp với các phương pháp đánh giá không phù hợp, các đặc tính an toàn không thích hợp, hoặc các sản phẩm CNTT không phù hợp sẽ dẫn đến các kết quả đánh giá vô nghĩa.

Do vậy, thực tế là một sản phẩm CNTT đã được đánh giá chỉ có ý nghĩa trong phạm vi ngữ cảnh các đặc tính an toàn được đánh giá với các phương pháp đánh giá cụ thể đã sử dụng. Các cơ quan đánh giá cần kiểm tra thận trọng các sản phẩm, đặc tính và các phương pháp để xác định rõ việc đánh giá đem lại kết quả có nghĩa. Ngoài ra, người mua các sản phẩm đã được đánh giá cũng cần xem xét kỹ lưỡng ngữ cảnh này để xác định xem sản phẩm đã đánh giá có hữu ích và áp dụng được cho trường hợp cụ thể của mình và đáp ứng yêu cầu hay không.

TCVN 8709 đề cập đến việc bảo vệ tài sản thông tin chống các truy nhập trái phép, các sửa đổi hoặc mất mát trong sử dụng. Phân loại bảo vệ liên quan đến ba kiểu lỗi an toàn kể trên tương ứng với tính bí mật, tính toàn vẹn và tính sẵn sàng. TCVN 8709 cũng có thể áp dụng cho các đánh giá ngoài ba nhóm trên. TCVN 8709 áp dụng cho các rủi ro phát sinh từ các hành vi của con người (ác ý hoặc lý do khác), và cho các rủi ro không do con người tạo ra. Ngoài an toàn CNTT, TCVN 8709 có thể áp dụng cho các lĩnh vực CNTT khác, song không có ràng buộc nào khi áp dụng cho các lĩnh vực đó.

Một số chủ đề do liên quan đến các kỹ thuật đặc biệt hoặc do chúng nằm ngoài lĩnh vực an toàn CNTT sẽ được coi là nằm ngoài phạm vi TCVN 8709. Một số chủ đề trong số đó như sau:

a) TCVN 8709 không gồm các tiêu chí đánh giá an toàn gắn liền với các biện pháp an toàn quản lý không liên quan trực tiếp tới chức năng an toàn CNTT. Tuy vậy, cũng phải thừa nhận rằng an toàn cơ bản thường đạt được thông qua hoặc được hỗ trợ bởi các biện pháp quản lý ví dụ về mặt tổ chức, nhân sự, vật lý và các thủ tục kiểm soát.

b) Đánh giá các khía cạnh vật lý kỹ thuật của an toàn CNTT ví dụ như kiểm soát dò rỉ thông tin qua điện từ trường không được đề cập riêng biệt, mặc dù nhiều khái niệm đã đề cập có thể áp dụng cho lĩnh vực này.

c) TCVN 8709 không đề cập đến hệ phương pháp đánh giá mà các tiêu chí này sẽ được áp dụng. Hệ phương pháp này được nêu trong ISO/IEC 18045.

d) TCVN 8709 không đề cập đến bộ khung pháp lý và quản lý mà các tiêu chí này sẽ được áp dụng bởi các cơ quan đánh giá. Tuy nhiên, có thể coi là TCVN 8709 sẽ được sử dụng cho các mục đích đánh giá trong ngữ cảnh các bộ khung đó.

e) Các thủ tục sử dụng các kết quả đánh giá để công nhận nằm ngoài phạm vi TCVN 8709. Công nhận là một quy trình quản lý trong đó cho phép quyền khai thác một sản phẩm CNTT (hoặc một tập các sản phẩm) trong mỗi trường hoạt động đầy đủ của nó bao gồm tất cả các phần phi- CNTT. Các kết quả của quy trình đánh giá là đầu vào cho quy trình công nhận. Tuy nhiên, do các kỹ thuật khác thường phù hợp hơn cho việc đánh giá các đặc tính phi- CNTT và mối quan hệ của chúng với các thành phần an toàn CNTT, việc công nhận cần xem xét riêng các khía cạnh này.

f) Chủ đề tiêu chí đánh giá cho chất lượng vốn có của các thuật toán mã hóa không nằm trong TCVN 8709. Nếu cần có đánh giá độc lập cho các đặc tính toán học của mã hóa, lược đồ đánh giá áp dụng TCVN 8709 sẽ phải cung cấp thêm các đánh giá này.

Các thuật ngữ ISO, như “có khả năng”, “tham khảo“,“có thể”, “bắt buộc”, “cần” và “nên” sử dụng xuyên suốt trong văn bản tiêu chuẩn được định nghĩa trong Các chỉ thị ISO/IEC, phần 2. Lưu ý rằng khái niệm “nên” có nghĩa bổ sung khi áp dụng tiêu chuẩn này. Xem lưu ý dưới đây. Định nghĩa sau đây quy định việc sử dụng từ “nên” trong TCVN 8709.

Nên

Trong văn bản quy chuẩn, từ “nên” dùng để biểu thị “trong một số khả năng, có một khả năng được khuyến nghị là đặc biệt thích hợp mà không cần quan tâm hay loại trừ những khả năng khác, hoặc một diễn biến hành động nào đó được coi là ưa chuộng chứ không cần bắt buộc” (ISO/IEC Directives, Part 2).

CHÚ THÍCH: TCVN 8709 giải thích cụm từ “không cần bắt buộc” nghĩa là việc lựa chọn một khả năng khác đòi hỏi phải giải thích vì sao phương án ưa chuộng hơn không được chọn.

CÔNG NGHỆ THÔNG TIN - CÁC KỸ THUẬT AN TOÀN CÁC TIÊU CHÍ ĐÁNH GIÁ AN TOÀN CNTT - PHẦN 1: GIỚI THIỆU VÀ MÔ HÌNH TỔNG QUÁT

lnformation Technology - Security Techniques - Evaluation Criteria for IT Security -Part 1: Introduction and General Model

1. Phạm vi áp dụng

Tiêu chuẩn này thiết lập các khái niệm và nguyên lý chung cho đánh giá an toàn CNTT và đặc tả mô hình đánh giá tổng quát tạo bởi các phần của tiêu chuẩn quốc tế một cách toàn diện, được sử dụng làm cơ sở cho đánh giá các thuộc tính an toàn của các sản phẩm CNTT.

Tiêu chuẩn này trình bày tổng quan về các phần của bộ TCVN 8709. Nó mô tả các phần của chuẩn; định nghĩa các khái niệm và các từ viết tắt sử dụng xuyên suốt trong toàn bộ các phần của tiêu chuẩn; thiết lập khái niệm cốt lõi về Đích đánh giá (TOE); ngữ cảnh đánh giá; mô tả đối tượng độc giả mà các tiêu chí đánh giá hướng đến. Tiêu chuẩn này cũng đưa ra các khái niệm an toàn cơ bản cần thiết cho việc đánh giá các sản phẩm CNTT.

Tiêu chuẩn định nghĩa các thao tác làm cơ sở để đưa ra các thành phần chức năng trong TCVN 8709­-2 và các thành phần đảm bảo trong TCVN 8709-3 thông qua việc sử dụng các thao tác cho phép.

Các khái niệm cơ bản về Hồ sơ bảo vệ (PP), các gói yêu cầu an toàn và chủ đề về tính tuân thủ sẽ được nêu; các hệ quả đánh giá và các kết quả đánh giá cũng được mô tả. Phần này của tiêu chuẩn đưa ra hướng dẫn cho việc đặc tả Đích an toàn (ST) và cung cấp bản mô tả về tổ chức các thành phần xuyên suốt mô hình. Thông tin tổng quan về phương pháp luận đánh giá và phạm vi các lược đồ đánh giá được đưa ra trong ISO/IEC 18045.

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

Tài liệu viện dẫn sau đây không thể thiếu được khi áp dụng tài liệu tiêu chuẩn này:

TCVN 8709-2, “Công nghệ thông tin - Các kỹ thuật an toàn - Các tiêu chí đánh giá an toàn CNTT - Phần 2: Các thành phần chức năng an toàn".

TCVN 8709 - 3, “Công nghệ thông tin - Các kỹ thuật an toàn - Các tiêu chí đánh giá an toàn CNTT - Phần 3: Các thành phần đảm bảo an toàn".

ISO/IEC 18045, “Công nghệ thông tin - Các kỹ thuật an toàn - Hệ phương pháp cho đánh giá an toàn CNTT” (ISO/IEC 18045, “Information Technology - Security Techniques - Methodology for IT security evaluation”).

3. Thuật ngữ và định nghĩa

Tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa sau đây.

CHÚ THÍCH: Điều khoản này chỉ gồm các thuật ngữ sử dụng riêng trong TCVN 8709. Một số kết hợp của các thuật ngữ chung dùng trong TCVN không có trong điều khoản này sẽ được giải thích rõ trong ngữ cảnh nơi chúng được sử dụng.

3.1. Các thuật ngữ và định nghĩa chung trong TCVN 8709

3.1.1

Các hành động có hại (adverse actions)

Các hành động thực hiện bởi một tác nhân đe dọa vào một tài sản.

3.1.2

Tài sản (assets)

Các thực thể mà chủ sở hữu TOE đặt giá trị vào đó.

3.1.3

Chỉ định (assignment)

Định rõ một tham số định danh trong một thành phần (của TCVN 8709) hoặc một yêu cầu.

3.1.4.

Bảo đảm (assurance)

Cơ sở để tin cậy rằng một TOE thỏa mãn các TSF.

3.1.5

Khả năng tấn công (attack potential)

Ước lượng về khả năng tấn công vào TOE biểu thị qua kinh nghiệm, tài nguyên và động cơ của kẻ tấn công.

3.1.6

Gia tăng (augmentation)

Việc thêm một hoặc nhiều yêu cầu vào một gói.

3.1.7

Dữ liệu xác thực (authentication data)

Thông tin được dùng để xác minh định danh đã tuyên bố của một người dùng.

3.1.8

Người dùng có thẩm quyền (authorised user)

Người dùng có thể thực thi một thao tác tương ứng với các SFR.

3.1.9

Lớp (class)

Tập các họ TCVN 8709 cùng chia sẻ một mục tiêu chung.

3.1.10

Tính mạch lạc (coherent)

Sắp sếp thứ tự logic, có nghĩa rõ ràng.

CHÚ THÍCH: Đối với tài liệu, thuật ngữ này dùng cho cả nội dung và cấu trúc của văn bản, biểu thị việc độc giả có hiểu được văn bản đó hay không.

3.1.11

Tính hoàn thiện (complete)

Tính chất thể hiện rằng tất cả các thành phần cần thiết của một thực thể đều được cung cấp.

CHÚ THÍCH: Đối với tài liệu, tính hoàn thiện nghĩa là mọi thông tin liên quan đều có trong tài liệu, ở mức độ chi tiết đến mức không cần có giải thích gì thêm.

3.1.12

Thành phần (component)

Tập nhỏ nhất lựa chọn được của các phần tử mà các yêu cầu có thể dựa vào.

3.1.13

Gói đảm bảo tổng hợp (composed assurance package)

Gói đảm bảo này gồm các yêu cầu rút ra từ TCVN 8709-3 (chủ yêu từ lớp ACO), biểu thị một điểm trong cấp độ đảm bảo tổng hợp đã định nghĩa trước trong TCVN 8709.

3.1.14

Xác nhận (confirm)

Công bố một việc đã được soát xét chi tiết với việc xác định tính đầy đủ một cách độc lập.

CHÚ THÍCH: Mức độ chính xác theo yêu cầu phụ thuộc vào bản chất của sự việc. Khái niệm trên chỉ áp dụng cho các hành động của đánh giá viên.

3.1.15.

Tính kết nối (connectivity)

Đặc tính của TOE cho phép tương tác với các thực thể CNTT bên ngoài TOE.

CHÚ THÍCH: đặc tính này bao gồm việc trao đổi dữ liệu qua phương thức hữu tuyến hoặc vô tuyến, qua một khoảng cách bất kỳ trong một môi trường hoặc cấu hình bất kỳ.

3.1.16

Tính nhất quán (consistent)

Mối quan hệ giữa hai hoặc nhiều thực thể trong đó không có sự đối lập rõ rệt nào giữa chúng.

3.1.17

Chổng đỡ (counter, verb)

Đối đầu với một tấn công, làm giảm thiểu tác động của mối đe dọa song không nhất thiết phải loại trừ

3.1.18

Tính tuân thủ diễn giải được (demonstrable conformance)

Mối quan hệ giữa một ST và một PP, trong đó ST cung cấp một giải pháp để giải quyết vấn đề an toàn chung nêu trong PP.

CHÚ THÍCH: PP và ST có thể chứa các phát biểu khác nhau hoàn toàn mô tả về các thực thể, khái niệm,... khác nhau. Tính tuân thủ diễn giải được cũng thích hợp với một kiểu TOE khi tồn tại một số PP tương tự nhau, vì thế cho phép tác giả ST tuyên bố tuân thủ đồng thời theo các PP này để giúp tiết kiệm thời gian.

3.1.19

Sự chứng minh (demonstrate)

Đưa ra một kết luận rút ra từ việc phân tích, tuy có kém chặt chẽ hơn một “bằng chứng”.

3.1.20

Tính phụ thuộc (dependency)

Mối quan hệ giữa các thành phần mà nếu trong đó một yêu cầu dựa trên thành phần phụ thuộc được đưa vào một PP, ST hoặc một gói thì yêu cầu dựa trên thành phần được phụ thuộc cũng thường phải được đưa vào PP, ST hoặc gói đó.

3.1.21

Mô tả (describe)

Cung cấp các chi tiết đặc trưng của một thực thể.

3.1.22.

Xác định (determine)

Khẳng định một kết luận riêng dựa trên một phép phân tích độc lập với mục tiêu đạt được một kết luận cụ thể.

CHÚ THÍCH: Việc sử dụng khái niệm này ngầm chỉ một phép phân tích độc lập tin cậy, thường dùng khi thiếu phân tích trước đó. So sánh với các khái niệm “xác nhận” hay “thâm tra“ ngầm chỉ một phân tích đã thực hiện trước đó cần thiết phải soát xét lại.

3.1.23

Môi trường phát triển (development environment)

Môi trường để phát triển TOE.

3.1.24

Phần tử (element)

Phát biểu cơ bản nhất về một yêu cầu an toàn.

3.1.25

Bảo đảm (ensure)

Sự bảo đảm về mối quan hệ nhân quả chắc chắn giữa một hành động và các hệ quả của nó.

CHÚ THÍCH: Thuật ngữ này với từ „giúp" đặt trước sẽ biểu thị rằng hệ quả không hoàn toàn chắc chắn nếu chỉ có hành động đó.

3.1.26

Đánh giá (evaluation)

Đánh giá một PP, một ST hoặc một TOE theo các tiêu chí đã xác định.

3.1.27

Mức bảo đảm đánh giá (evaluation assurance level - EAL)

Tập các yêu cầu đảm bảo rút ra từ bộ TCVN 8709-3, biểu thị một điểm mốc trên cấp bậc bảo đảm được xác định trước trong TCVN 8709, tạo thành một gói đảm bảo.

3.1.28

Cơ quan đánh giá (evaluation authority)

Cơ quan thiết lập tiêu chuẩn và giám sát chất lượng các đánh giá được thực hiện bởi các đơn vị trong một cộng đồng cụ thể và là đơn vị thực thi TCVN 8709 cho cộng đồng thông qua một lược đồ đánh giá.

3.1.29

Lược đồ đánh giá (evaluation scheme)

Bộ khung quản lý và quy định về việc áp dụng TCVN 8709 cho một cơ quan đánh giá trong một cộng đồng cụ thể.

3.1.30

Thấu đáo (exhaustive)

Đặc trưng của một phương pháp tiếp cận được sử dụng để thực hiện một phân tích hoặc hoạt động theo một kế hoạch rõ ràng.

CHÚ THÍCH: Khái niệm này sử dụng trong TCVN 8709 chú trọng đến việc hướng dẫn phân tích hoặc các hoạt động khác. Nó liên quan đến tính hệ thống song được coi là mạnh hơn. Với nghĩa này, nó không chỉ biểu thị một cách tiếp cận có phương pháp đã được dùng để thực hiện phân tích hay thực hiện công việc theo một kế hoạch rõ ràng, mà còn biểu thị rằng kế hoạch này là đầy đủ để bảo đảm rằng đã thực hiện theo mọi con đường có thể.

3.1.31

Giải thích (explain)

Đưa ra luận cứ về lý do thực hiện một hành động.

3.1.32

Mở rộng (extension)

Bổ sung thêm vào một ST hoặc PP các yêu cầu chức năng không chứa trong TCVN 8709-2 và/hoặc các yêu cầu đảm bảo không chứa trong TCVN 8709-3.

3.1.33

Thực thể bên ngoài (external entity)

Một người dùng hay thiết bị CNTT có thể tương tác với TOE từ bên ngoài ranh giới TOE.

CHÚ THÍCH: Một thực thể bên ngoài có thể được coi là một người dùng.

3.1.34

Họ (family)

Một nhóm các thành phần cùng chia sẻ một mục tiêu giống nhau song khác nhau về tầm quan trọng hay tính chặt chẽ.

3.1.35

Hình thức (formal)

Cách biểu thị bằng một ngôn ngữ cú pháp hạn chế với ngữ nghĩa xác định trên cơ sở các khái niệm toán học được thiết lập rõ ràng.

3.1.36

Tài liệu hướng dẫn (guidance documentation)

Tài liệu mô tả về việc vận chuyển, chuẩn bị, vận hành, quản lý và/hoặc sử dụng cho TOE.

3.1.37

Định danh (identity)

Việc biểu diễn các thực thể (chẳng hạn như người dùng, tiến trình hoặc ổ đĩa) xác định duy nhất trong ngữ cảnh của TOE.

CHÚ THÍCH: Một ví dụ về việc biểu diễn này là một chuỗi ký tự. Đối với người dùng, biểu diễn có thể là tên đầy đủ, hoặc tên viết tắt hoặc một bí danh (duy nhất) của người dùng.

3.1.38

Không hình thức (informal)

Cách diễn tả bằng ngôn ngữ tự nhiên.

3.1.39

Vận chuyển giữa các TSF (inter TSF transfers)

Trao đổi dữ liệu giữa TOE với chức năng an toàn của các sản phẩm CNTT tin cậy khác.

3.1.40

Kênh truyền thông nội bộ (internal communication channel)

Kênh truyền thông giữa các phần tách biệt của TOE.

3.1.41

Vận chuyển nội bộ TOE (internal TOE transfer)

Trao đổi dữ liệu giữa các phần tách biệt của TOE.

3.1.42

Tính nhất quán nội bộ (internally consistent)

Là không có đối lập rõ nét nào trong mọi khía cạnh của một thực thể.

CHÚ THÍCH: Trong tài liệu, điều này có nghĩa là không có phát biểu nào đối lập với phát biểu khác.

3.1.43

Phép lặp (iteration)

Là việc sử dụng lặp lại một thành phần để thể hiện hai hoặc nhiều yêu cầu riêng biệt.

3.1.44.

Biện minh (justification)

Là việc phân tích để đi đến một kết luận.

CHÚ THÍCH: Khái niệm “biện minh” chặt chẽ hơn là “diễn giải”. Khái niệm này đòi hỏi tính chính xác đáng kể về việc giải thích một cách đặc biệt thận trọng và kỹ lưỡng từng bước cho một luận cứ logic.

3.1.45

Đối tượng (object)

Thực thể thụ động trong TOE có chứa hoặc tiếp nhận thông tin, mà dựa vào đó các chủ thể thực thi các hoạt động.

3.1.46

Hoạt động (operation)

(đối với một thành phần của TCVN 8709) là sự sửa đổi hoặc lặp lại một thành phần.

CHÚ THÍCH: Các hoạt động được phép cho thành phần là chỉ định, phép lặp, bổ sung chi tiết và lựa chọn.

3.1.47

Hoạt động (operation)

(đối với một đối tượng) là kiểu đặc trưng của một hành động do một chủ thể thực hiện trên một đối tượng.

3.1.48

Môi trường vận hành (operational environment)

Môi trường trong đó TOE hoạt động.

3.1.49

Chính sách an toàn của tổ chức (organizational security policy)

Tập các quy tắc, thủ tục, hoặc hướng dẫn an toàn cho một tổ chức.

CHÚ THÍCH: Một chính sách có thể chỉ áp dụng cho một môi trường vận hành cụ thể.

3.1.50

Gói (package)

Tập được đặt tên của các yêu cầu chức năng an toàn hoặc đảm bảo an toàn.

CHÚ THÍCH: Một ví dụ về gói là “EAL 3".

3.1.51

Đánh giá Hồ sơ bảo vệ (Protection Profile evaluation)

Đánh giá một PP theo các tiêu chí định sẵn.

3.1.52

Hồ sơ bảo vệ (Protection Profile - PP)

Phát biểu độc lập về mặt thực thi các yêu cầu cho một kiểu TOE.

3.1.53

Chứng minh (prove)

Chỉ ra sự phù hợp bằng việc phân tích hình thức theo cách tiếp cận toán học.

CHÚ THÍCH : Khái niệm này chính xác toàn diện theo mọi mặt. Điển hình, khái niệm chứng minh được dùng khi mong muốn chỉ ra sự phù hợp giữa 2 biểu diễn TSF ở một mức chính xác cao.

3.1.54

Tinh chỉnh (refinement)

Bổ sung thêm các chi tiết cho một thành phần.

3.1.55

Vai trò (role)

Một tập các quy tắc xác định trước để thiết lập các tương tác được phép giữa một người dùng và TOE.

3.1.56

Bí mật (secret)

Là thông tin chỉ được người có thẩm quyền và / hoặc TSF biết để thực thi một SFP cụ thể.

3.1.57

Trạng thái an toàn (secure State)

Trạng thái mà dữ liệu TSF là nhất quán và TSF tiếp tục thực thi chuẩn xác các SFR.

3.1.58

Thuộc tính an toàn (security attribute)

Các đặc tính của các chủ thể, người dùng (bao gồm các sản phẩm CNTT bên ngoài), đối tượng, thông tin, các phiên và/hoặc các tài nguyên được dùng cho việc xác định các SFR và các giá trị của chúng được dùng trong thực thi các SFR.

3.1.59

Chính sách chức năng an toàn (security function policy)

Tập các quy tắc mô tả hành vi an toàn cụ thể được thực thi bởi TSF và được biểu thị như một tập các SFR.

3.1.60

Mục tiêu an toàn (security objective)

Phát biểu về hướng đối phó với các mối đe dọa xác định và/hoặc hướng thỏa mãn các chính sách an toàn xác định của tổ chức cũng như hướng thỏa mãn các giả định.

3.1.61

Vấn đề an toàn (security problem)

Phát biểu dạng hình thức định nghĩa bản chất và phạm vi an toàn mà TOE chủ ý đề cập đến.

CHÚ THÍCH: Phát biểu là sự kết hợp của:

- Các mối đe dọa mà TOE cần chống trả,

- Các OSP được thực thi bởi TOE, và

- Các giả định đặt ra cho TOE và môi trường vận hành của nó.

3.1.62

Yêu cầu an toàn (security requirement)

Yêu cầu được phát biểu trong ngôn ngữ tiêu chuẩn, dùng để đạt được các mục tiêu an toàn cho một TOE.

3.1.63

Đích an toàn (Security Target - ST)

Phát biểu phụ thuộc thực thi về các yêu cầu cần thiết của một TOE xác định.

3.1.64

Lựa chọn (selection)

Việc định rõ một hoặc nhiều khoản mục từ một danh sách trong một thành phần.

3.1.65

Bán hình thức (semiformal)

Biểu thị bằng một ngôn ngữ cú pháp hạn chế với ngữ nghĩa xác định trước.

3.1.66

Đặc tả (specify)

Là đưa ra chi tiết đặc trưng về một thực thể theo một cách chính xác và chặt chẽ.

3.1.67

Tuân thủ chặt chẽ (strict conformance)

Mối quan hệ có thứ bậc giữa một PP và một ST trong đó mọi yêu cầu có trong PP thì cũng tồn tại trong ST.

CHÚ THÍCH: Mối quan hệ này có thể được xác định như „ST sẽ chứa tất cả các phát biểu có trong PP, nhưng có thể chứa thêm các phát biểu khác“. Tuân thủ chặt chẽ dự kiến dùng cho các yêu cầu nghiêm ngặt và đơn giản là chúng cần được giữ gìn triệt để.

3.1.68

Đánh giá ST (ST evaluation)

Đánh giá một ST theo các tiêu chí định sẵn.

3.1.69

Chủ thể (subject)

Một thực thể chủ động thuộc TOE thực thi các thao tác trên đối tượng.

3.1.70

Đích đánh giá (target of evaluation - TOE)

Một tập phần mềm, phần sụn và/hoặc phần cứng cùng với tài liệu hướng dẫn nếu có.

3.1.71

Tác nhân đe dọa (threat agent)

Thực thể có thể gây tác động không mong muốn vào tài sản.

3.1.72

Đánh giá TOE (TOE evaluation)

Đánh giá một TOE theo các tiêu chí định sẵn.

3.1.73

Tài nguyên TOE (TOE resource)

Những gì được dùng hoặc tiêu tốn trong TOE.

3.1.74

Chức năng an toàn của TOE (TSF-TOE security functionality)

Tính năng kết hợp tất cả phần cứng, phần mềm, và phần sụn của TOE mà dựa vào đó TOE mới thực thi được chính xác các SFR.

3.1.75

Theo dấu (trace, verb)

Thực hiện phân tích phù hợp một cách không hình thức giữa hai thực thể chỉ ở mức độ chính xác tối thiểu.

3.1.76

Vận chuyển bên ngoài TOE (transfers outside of the TOE)

Trung chuyển dữ liệu đến các thực thể ngoài tầm kiểm soát của TSF.

3.1.77

Chuyển đổi (translation)

Quá trình mô tả các yêu cầu an toàn sang một ngôn ngữ tiêu chuẩn.

CHÚ THÍCH: Khái niệm chuyển đổi trong ngữ cảnh này không có nghĩa dịch thuật và không ngầm chỉ rằng mọi SFR biểu diễn trong ngôn ngữ chuẩn có thể được dịch ngược lại thành các mục tiêu an toàn.

3.1.78

Kênh tin cậy (trusted channel)

Phương tiện qua đó một TSF và một sản phẩm CNTT tin cậy khác có thể liên lạc với nhau ở độ tin cậy cần thiết.

3.1.79

Sản phẩm CNTT tin cậy (trusted IT product)

Sản phẩm CNTT - không phải là TOE - mà các yêu cầu chức năng an toàn của nó kết hợp về mặt quản trị với TOE và được giả thiết là để thực thi các yêu cầu chức năng an toàn của nó một cách chuẩn xác.

CHÚ THÍCH: Ví dụ về một sản phẩm CNTT tin cậy có thể là một sản phẩm đã được đánh giá tách biệt khác.

3.1.80

Đường dẫn tin cậy (trusted path)

Phương tiện để một người dùng và TSF có thể truyền thông với nhau ở mức tin tưởng cần thiết.

3.1.81

Dữ liệu TSF (TSF data)

Dữ liệu cho việc hoạt động mà TOE dựa vào để thực thi các SFR.

3.1.82

Giao diện TSF (TSF interface)

Phương tiện để một thực thể bên ngoài (hoặc chủ thể thuộc TOE nhưng nằm ngoài TSF) cung cấp dữ liệu cho TSF, nhận dữ liệu từ TSF và thực thi các dịch vụ từ TSF.

3.1.83

Dữ liệu người dùng (user data)

Dữ liệu dùng cho người dùng và không ảnh hưởng đến hoạt động của TSF.

3.1.84

Thẩm tra (verify)

Soát xét kỹ ở mức chi tiết với việc xác định độc lập về tính đầy đủ.

CHÚ THÍCH: Xem khái niệm “Xác nhận” (ở 3.1.14). Khái niệm „thẩm tra“ có ý nghĩa chặt chẽ hơn. Nó được dùng trong ngữ cảnh các hành động của đánh giá viên, trong đó đòi hỏi sự nỗ lực độc lập của đánh giá viên.

3.2. Các thuật ngữ và định nghĩa liên quan đến lớp ADV

CHÚ THÍCH: Các khái niệm sau được dùng trong các yêu cầu đối với kiến trúc bên trong phần mềm. Một số khái niệm rút ra từ IEEE Std 610.12-1990 - Tập các khái niệm chuẩn trong công nghệ phần mềm của Viện Công nghệ Điện và Điện tử.

3.2.1

Người quản trị (administrator)

Thực thể có mức độ tin cậy tương ứng với mọi chính sách thực thi bởi TSF.

CHÚ THÍCH: Không phải tất cả PP hoặc ST giả định có cùng mức tin cậy cho người quản trị. Các nhà quản trị điển hình được coi là trung thành mọi lúc với các chính sách trong ST của TOE. Một số chính sách có thể liên quan đến chức năng của TOE, một số khác có thể liên quan đến môi trường vận hành.

3.2.2

Cây truy xuất (call tree)

Xác định các mô đun trong một hệ thống theo dạng biểu đồ, chỉ ra những mô đun nào gọi đến một mô đun khác.

CHÚ THÍCH: Vận dụng theo IEEE Std 610.12-1990.

3.2.3

Tính gắn kết (cohesion)

Cách thức và mức độ chặt chẽ của mô đun liên quan đến một mô đun khác của các tác vụ thực hiện bởi một mô đun phần mềm đơn lẻ. (Theo IEEE Std 610-12-1990).

CHÚ THÍCH: Các kiểu gắn kết gồm: kiểu trùng hợp, truyền thông, tính năng, logic, tuần tự và tạm thời. Các kiểu gắn kết này được mô tả bởi một khái niệm tương ứng nêu trên.

3.2.4

Gắn kết trùng hợp (coincidental cohesion)

Mô đun với các đặc trưng của việc thực hiện các hành động liên quan hoặc liên quan lỏng lẻo. (Theo IEEE Std 610-12-1990).

CHÚ THÍCH: Xem khái niệm 3.2.3 ở trên.

3.2.5

Gắn kết truyền thông (communicational cohesion)

Mô đun chứa các chức năng tạo ra kết xuất cho hoặc dùng kết xuất lấy từ các chức năng khác trong cùng mô đun.

(Theo IEEE Std 610-12-1990).

CHÚ THÍCH 1: Xem khái niệm 3.2.3 ở trên.

CHÚ THÍCH 2: Ví dụ về một mô đun gắn kết truyền thông là mô đun kiểm tra truy nhập, mô đun này chứa các hàm kiểm tra bắt buộc, tùy biến và kiểm tra năng lực.

3.2.6

Độ phức tạp (complexity)

Đại lượng đo mức độ khó hiểu của phần mềm, khó để phân tích, kiểm thử và duy trì nó.

(Theo IEEE Std 610-12-1990).

CHÚ THÍCH: Giảm độ phức tạp là đích chung của việc sử dụng phương pháp phân rã mô đun, phân lớp và tối giản hóa. Ghép điều khiển và gắn kết có vai trò quan trọng để đạt mục đích này.

Một nỗ lực trong lĩnh vực công nghệ phần mềm đã thể hiện trong việc cố gắng phát triển các thước đo để đo lường độ phức tạp của mã nguồn. Hầu hết các thước đo này sử dụng các đặc tính dễ tính toán của mã nguồn như số các biểu thức và toán hạng, độ phức tạp của đồ thị luồng điều khiển (độ phức tạp vòng lặp), số các dòng mã nguồn, tỷ lệ chú giải so với mã thực hiện, và các thước đo tương tự khác. Các chuẩn mã hóa cũng đã được tìm ra để có công cụ hữu ích trong việc tạo mã sao cho dễ hiểu hơn.

Họ nội bộ TSF (ADV_INT) gọi đến một hàm phân tích độ phức tạp trong mọi thành phần của chúng. Kết quả dự kiến là nhà phát triển sẽ đưa ra hỗ trợ cho các đòi hỏi về việc đã có giảm đáng kể trong độ phức tạp. Hỗ trợ này có thể gồm các chuẩn lập trình cho nhà phát triển, và một chỉ số về việc mọi mô đun thỏa mãn tiêu chuẩn (hoặc có một số ngoại lệ được biện minh bằng các luận cứ công nghệ phần mềm). Nó có thể chứa các kết quả của các bộ công cụ dùng để đo lượng một số tính chất của mã nguồn, hoặc có thể chứa hỗ trợ khác cho nhà phát triển cần đến.

3.2.7

Ghép nối (coupling)

Cách thức và mức độ của sự không liên thuộc giữa các mô đun phần mềm.

(Theo IEEE Std 610-12-1990).

CHÚ THÍCH: Các kiểu ghép nối gồm ghép nối truy xuất, ghép nối chung và ghép nối nội dung (xem bên dưới).

3.2.8

Ghép nối truy xuất (call coupling)

Quan hệ giữa hai mô đun trao đổi với nhau một cách chặt chẽ qua các lời gọi hàm chức năng được ghi lại tài liệu.

CHÚ THÍCH: Ví dụ về ghép nối truy xuất là dữ liệu, nhãn tem và điều khiển. (Xem phần tiếp theo).

3.2.9

Ghép nối truy xuất (call coupling)

(về dữ liệu). Quan hệ dữ liệu giữa hai mô đun trao đổi chặt chẽ với nhau thông qua việc sử dụng các tham số biểu diễn các biểu thức dữ liệu đơn lẻ.

CHÚ THÍCH: Xem ghép nối truy xuất (3.2.8)

3.2.10

Ghép nối truy xuất (call coupling)

(về nhãn tem). Quan hệ về nhãn tem giữa hai mô đun trao đổi với nhau thông qua việc sử dụng các tham số lời gọi có chứa nhiều trường hoặc có các cấu trúc bên trong có nghĩa.

CHÚ THÍCH: Xem ghép nối truy xuất (3.2.8)

3.2.11

Ghép nối truy xuất (call coupling)

(về điều khiển). Quan hệ về điều khiển giữa hai mô đun nếu một mô đun chuyển thông tin mà nó định gửi để gây ảnh hưởng đến logic bên trong của mô đun kia.

CHÚ THÍCH: Xem ghép nối truy xuất (3.2.8)

3.2.12

Ghép nối chung (common coupling)

Quan hệ giữa hai mô đun cùng chia sẻ một vùng dữ liệu chung hoặc một tài nguyên hệ thống chung khác.

CHÚ THÍCH: Các biến toàn cục chỉ ra rằng các mô đun sử dụng các biến toàn cục này là các ghép nối chung. Ghép nối chung thông qua các biến toàn cục nhìn chung được phép, song chỉ ở mức độ hạn chế.

Ví dụ: Các biến được đặt trong một vùng toàn cục, song chỉ dùng trong một mô đun, sẽ coi là đặt chỗ sai và cần phải hủy bỏ. Các yếu tố khác cần được xem xét khi đánh giá mức độ phù hợp của các biến toàn cục là:

- Số các mô đun có sửa đổi một biến toàn cục: Nói chung, chỉ một mô đun đơn nên được cấp cho trách nhiệm kiểm soát nội dung của một biến toàn cục. Tuy nhiên có thể có các tình huống trong đó một mô đun thứ hai có thể chia sẻ trách nhiệm này. Trong tình hướng đó, cần có sự biện minh thỏa đáng. Không thể chấp nhận được việc chia sẻ trách nhiệm trên cho nhiều hơn hai mô đun. (Để thực hiện đánh giá này, cần thận trọng khi xác định mô đun thực sự có trách nhiệm đối với nội dung của biến. Ví dụ, nếu có 1 trình đơn lẻ dùng để sửa đổi biến này, song trình này đơn giản chỉ thực hiện việc sửa đổi theo yêu cầu của mô đun gọi đến nó, thì mô đun này là mô đun chịu trách nhiệm và có thể có nhiều hơn một mô đun như vậy). Tiếp đó, về việc xác định độ phức tạp, nếu 2 mô đun có trách nhiệm đối với nội dung của biến toàn cục, cần có các chỉ số rõ ràng về mức độ phối hợp giữa các sửa đổi này.

- Số các mô đun có tham chiếu đến 1 biến toàn cục: Mặc dù nhìn chung không có hạn chế nào về số lượng các mô đun có tham chiếu đến 1 biến toàn cục, các trường hợp nhiều mô đun có tham chiếu tương tự sẽ cần được kiểm tra về tính hợp lệ và sự cần thiết.

3.2.13

Ghép nối nội dung (content coupling)

Quan hệ giữa hai mô đun trong đó một mô đun tạo tham chiếu trực tiếp đến nội dung bên trong của mô đun kia.

CHÚ THÍCH: Các ví dụ như: sửa đổi mã của - hoặc tham chiếu các nhãn nội bộ tới - mô đun khác. Kết quả là một số hoặc toàn bộ nội dung của một mô đun được ghép hiệu quả vào mô đun kia. Việc ghép nối nội dung có thể liên tưởng giống như việc sử dụng các giao diện mô đun không quảng cáo. Đây là cách đối lập với ghép nối truy xuất chỉ sử dụng các giao diện mô đun quảng cáo.

3.2.14

Phân cách miền (domain separation)

Đặc tính kiến trúc bảo an trong đó TSF định nghĩa các miền an toàn tách biệt cho mỗi người dùng và cho TSF và bảo đảm rằng không có một tiến trình người dùng nào có thể ảnh hưởng đến nội dung của một miền an toàn của người khác hoặc của TSF.

3.2.15

Gắn kết chức năng (functional cohesion)

Đặc tính của một mô đun để thực hiện các hành động liên quan đến một mục đích riêng.

(Theo IEEE Std 610-12-1990).

CHÚ THÍCH: Một mô đun gắn kết chức năng chuyển đổi một kiểu đơn của đầu vào thành một kiểu đơn đầu ra, ví dụ như một khối quản trị tác vụ hoặc quản trị hàng đợi (xem thêm tính gắn kết ở 3.2.3).

3.2.16

Tương tác (interaction)

Hoạt động dựa trên việc truyền thông chung giữa các thực thể.

3.2.17

Giao diện (interface)

Phương tiện tương tác với một thành phần hoặc một mô đun.

3.2.18

Phân lớp (layering)

Kỹ thuật thiết kế trong đó các nhóm mô đun tách biệt (các lớp) được tổ chức phân cấp để có trách nhiệm riêng biệt sao cho một lớp chỉ phụ thuộc vào dịch vụ các lớp bên dưới nó, và cung cấp dịch vụ chỉ cho các lớp trên nó.

CHÚ THÍCH: Phân lớp chặt chẽ bổ sung điều kiện là mỗi lớp chỉ nhận dịch vụ từ lớp ngay dưới nó và cung cấp dịch vụ chỉ cho lớp ngay trên nó.

3.2.19

Gắn kết logic, gắn kết thủ tục (logical cohesion, procedural cohesion)

Các đặc trưng của một mô đun thực hiện các động thái giống nhau trên các cấu trúc dữ liệu khác nhau.

CHÚ THÍCH: Một mô đun biểu thị gắn kết logic khi các chức năng của nó thực hiện các hành động liên quan - song khác biệt ở các đầu ra khác nhau (xem tính gắn kết ở 3.2.3).

3.2.20

Phân tách mô đun (modular decomposition)

Quá trình chia một hệ thống ra nhiều thành phần để thuận tiện cho thiết kế, phát triển và đánh giá. (Theo IEEE Std 610-12-1990).

3.2.21

Khả năng không đi vòng (non-bypassability)

(của TSF) là đặc tính kiến trúc an toàn trong đó mọi hành động liên quan đến SFR được đều được trung chuyển qua TSF.

3.2.22

Miền an toàn (security domain)

Tập hợp tài nguyên mà một thực thể chủ động có đặc quyền truy nhập đến.

3.2.23

Gắn kết tuần tự (sequential cohesion)

Mô đun chứa các chức năng mà kết xuất của mỗi chức năng này là đầu vào cho chức năng tiếp theo trong mô đun.

(Theo IEEE Std 610-12-1990).

CHÚ THÍCH: Một ví dụ về mô đun gắn kết tuần tự là mô đun có chứa các chức năng để ghi các bản ghi kiểm toán và để duy trì một bộ đếm động về số lượng tích lũy các vi phạm kiểm chứng của một kiểu đặc trưng.

3.2.24

Công nghệ phần mềm (software engineering)

Ứng dụng cách tiếp cận định lượng, có hệ thống, có nguyên tắc cho việc phát triển và bảo trì phần mềm, nghĩa là ứng dụng kỹ thuật cho phần mềm.

(Theo IEEE Std 610-12-1990).

CHÚ THÍCH: Như với thực tiễn công nghệ nói chung, cần có một vài suy xét trong khi áp dụng các nguyên tắc kỹ thuật. Nhiều yếu tố ảnh hưởng đến việc chọn lựa, không chỉ việc ứng dụng các thước đo về việc phân tách mô đun, phân lớp và tối giản. Ví dụ, một nhà phát triển có thể thiết kế một hệ thống với các ứng dụng tương lai theo ý tưởng chúng vẫn chưa được triển khai từ khởi điểm. Nhà phát triển có thể chọn đưa vào một vài logic để xử lý các ứng dụng tương lai này mà không cần phải triển khai chúng một cách hoàn thiện. Tiếp đó, nhà phát triển có thể đưa vào một số lời gọi đến các mô đun thực sự vẫn chưa triển khai này, song chỉ là các lời gọi cụt (không thực hiện gì và quay về luôn). Sự biện minh của nhà phát triển về những sai lệch so với các chương trình có kiến trúc hoàn hảo sẽ cần được đánh giá có suy xét, so với việc áp dụng nguyên tắc công nghệ phần mềm.

3.2.25

Gắn kết tạm thời (temporal cohesion)

Các đặc trưng của một mô đun có chứa các chức năng cần thiết để thực hiện tại cùng thời điểm.

CHÚ THÍCH 1: Dựa theo IEEE Std 610-12-1990.

CHÚ THÍCH 2: Các ví dụ về mô đun gắn kết tạm thời gồm các mô đun khởi tạo, khôi phục và ngừng hoạt động.

3.2.26

Tự bảo vệ TSF (TSF self-protection)

Đặc tính kiến trúc an toàn trong đó TSF không thể bị gián đoạn bởi các mã của TSF khác hoặc bởi các thực thể khác.

3.3. Các thuật ngữ và định nghĩa liên quan đến lớp AGD

3.3.1

Cài đặt (installation)

Thủ tục thực hiện bởi người dùng đưa TOE vào môi trường vận hành của nó và đưa nó vào trạng thái hoạt động.

CHÚ THÍCH: Hoạt động này thường chỉ thực hiện một lần, sau khi nhận được và chấp thuận TOE. Dự kiến TOE tiến hành theo cấu hình cho phép bởi ST. Nếu các quá trình tương tự cần được nhà phát triển thực hiện, chúng được biểu thị là “khởi tạo” trong suốt quá trình hỗ trợ vòng đời ALC. Nếu TOE yêu cầu khởi động ban đầu mà không cần nhắc lại định kỳ, quá trình này được phân loại là cài đặt.

3.3.2

Hoạt động (operation)

Giai đoạn sử dụng TOE gồm: “sử dụng bình thường”, quản trị và bảo dưỡng TOE sau khi chuyển giao và chuẩn bị.

3.3.3

Chuẩn bị (preparation)

Hoạt động trong giai đoạn vòng đời của một sản phẩm, bao gồm việc chấp thuận của khách hàng đối với TOE đã chuyển giao và cài đặt nó, có thể gồm cả những việc như khởi động, khởi tạo, thiết lập và tiến hành TOE đưa nó vào trạng thái sẵn sàng hoạt động.

3.4. Các thuật ngữ và định nghĩa liên quan đến lớp ALC

3.4.1

Các tiêu chí chấp thuận (acceptance criteria)

Các tiêu chí cần áp dụng khi thực hiện các thủ tục chấp thuận (ví dụ như soát xét thành công tài liệu, kiểm thử thành công về phần mềm, phần sụn hoặc phần cứng).

3.4.2

Các thủ tục chấp thuận (acceptance procedures)

Các thủ tục nối tiếp theo trình tự để chấp nhận các khoản mục cấu hình mới đã tạo lập hoặc đã sửa đổi cho TOE, hoặc để xóa bỏ chúng ở bước tiếp theo trong vòng đời.

CHÚ THÍCH: Các thủ tục này định dạng các vai trò hoặc trách nhiệm riêng đối với việc chấp thuận và các tiêu chí cần áp dụng để quyết định việc chấp thuận.

Có một số loại hình chấp thuận, một số có thể gối lên nhau, đó là:

a) Chấp thuận một khoản mục vào hệ thống quản lý cấu hình cho lần đầu, cụ thể gồm các thành phần phần mềm, phần sụn hay phần cứng từ các nhà sản xuất đưa vào TOE (“tích hợp”).

b) Tiến hành các khoản mục cấu hình trong giai đoạn tiếp theo của vòng đời tại mỗi tầng kiến thiết TOE (ví dụ mô đun, hệ thống con, kiểm soát chất lượng của TOE hoàn chỉnh).

c) Kế tiếp với việc chuyển tải các khoản mục cấu hình (ví dụ các phần của TOE hoặc các sản phẩm ban đầu) giữa các địa điểm phát triển khác nhau.

d) Kế tiếp với việc chuyển giao TOE tới người tiêu dùng.

3.4.3

Quản lý cấu hình (Configuration management - CM)

Nguyên tắc áp dụng chỉ đạo và giám sát về mặt kỹ thuật và quản lý để định dạng và tài liệu hóa các đặc tính chức năng và vật lý của một khoản mục cấu hình, kiểm soát những thay đổi về những đặc tính này, ghi nhận và báo cáo sự thay đổi trạng thái xử lý và triển khai, kiểm chứng sự tuân thủ theo các yêu cầu đặc trưng.

CHÚ THÍCH: Dựa theo IEEE Std 610-12-1990.

3.4.4

Tài liệu CM (CM documentation)

Tất cả tài liệu CM bao gồm đầu ra CM, danh sách CM (danh sách cấu hình), các bản ghi hệ thống CM, kế hoạch CM và tài liệu sử dụng CM.

3.4.5

Bằng chứng quản lý cấu hình (configuration management evidence)

Là mọi thứ có thể dùng để thiết lập sự tin cậy trong hoạt động đúng của hệ thống CM.

CHÚ THÍCH: Ví dụ, đầu ra CM, các sở cứ hợp lý cung cấp bởi nhà phát triển, các quan sát, các thí nghiệm hoặc các phỏng vấn tạo ra bởi đánh giá viên khi có mặt tại cơ sở.

3.4.6

Khoản mục cấu hình (configuration item)

Đối tượng quản lý bởi hệ thống CM trong quá trình phát triển TOE.

CHÚ THÍCH: Các khoản mục này có thể là các phần của TOE hoặc là các đối tượng liên quan đến việc phát triển TOE giống như các tài liệu đánh giá hoặc các công cụ phát triển. Các khoản mục CM có thể được lưu trữ trực tiếp trong hệ thống CM (ví dụ các tệp), hoặc qua tham chiếu (ví dụ các phần cứng) cùng với phiên bản của chúng.

3.4.7

Danh sách cấu hình (configuration list)

Tài liệu đầu ra quản lý cấu hình liệt kê mọi khoản mục cấu hình cho một sản phẩm đặc trưng cùng với phiên bản chính xác của mỗi khoản mục cấu hình tương ứng cho một phiên bản cụ thể của sản phẩm hoàn chỉnh.

CHÚ THÍCH: Danh sách này phân biệt phiên bản đã đánh giá của sản phẩm so với các phiên bản khác. Danh sách quản lý cấu hình là một tài liệu cụ thể cho một phiên bản cụ thể của một sản phẩm cụ thể. (Dĩ nhiên danh sách có thể là một tài liệu điện tử nằm trong một công cụ quản lý cấu hình. Trong trường hợp này, nó có thể coi là là một bản thuyết minh về hệ thống hoặc một phần của hệ thống hơn là phần kết xuất của hệ thống. Tuy nhiên, để sử dụng vào đánh giá, danh sách cấu hình có thể được chuyển giao như một phần của tài liệu đánh giá). Danh sách cấu hình định nghĩa các khoản mục thuộc các yêu cầu quản lý cấu hình của ALC_CMC.

3.4.8

Đầu ra quản lý cấu hình (configuration management output)

Các kết quả liên quan đến quản lý cấu hình, được tạo ra hoặc thực thi bởi hệ thống quản lý cấu hình.

CHÚ THÍCH: Các kết quả liên quan đến quản lý cấu hình này có thể là các tài liệu (ví dụ như các mẫu giấy tờ, các bản ghi hệ thống quản lý cấu hình, dữ liệu ghi nhật ký, các bản giấy sao chụp, dữ liệu kết xuất điện tử) cũng như các hành động (ví dụ các phép đo thủ công để thực hiện các lệnh quản lý cấu hình). Ví dụ về các đầu ra quản lý cấu hình như các danh sách cấu hình, các kế hoạch quản lý cấu hình, và/hoặc các hành vi trong vòng đời sản phẩm.

3.4.9

Kế hoạch quản lý cấu hình (configuration management plan)

Mô tả về việc hệ thống quản lý cấu hình được sử dụng cho TOE như thế nào.

CHÚ THÍCH: Mục tiêu của việc đưa ra một kế hoạch quản lý cấu hình là các nhân viên có thể thấy rõ họ cần làm gì. Từ quan điểm của hệ thống quản lý cấu hình nói chung, kế hoạch này có thể coi như một tài liệu kết xuất (vì nó có thể tạo ra như một phần ứng dụng của hệ thống quản lý cấu hình). Từ quan điểm của một dự án cụ thể, nó là một tài liệu sử dụng vi các thành viên của dự án sử dụng nó để hiểu được các bước cần thực hiện trong dự án. Kế hoạch quản lý cấu hình định nghĩa việc sử dụng hệ thống đối với một sản phẩm cụ thể; hệ thống này có thể mở rộng để dùng cho các sản phẩm khác. Nghĩa là kế hoạch quản lý cấu hình định nghĩa và mô tả đầu ra của một hệ thống quản lý cấu hình cho một công ty sử dụng trong quá trình phát triển TOE.

3.4.10

Hệ thống quản lý cấu hình (configuration management system)

Tập các thủ tục và công cụ (bao gồm cả tài liệu của chúng) dùng bởi nhà phát triển để phát triển và bảo trì các cấu hình cho sản phẩm của họ trong vòng đời sản phẩm.

CHÚ THÍCH: Các hệ thống quản lý cấu hình có thể khác nhau về mức độ chặt chẽ và chức năng, ở các mức cao, các hệ thống quản lý cấu hình có thể tự động hóa, với việc sửa chữa khiếm khuyết, kiểm soát thay đổi, và các cơ chế theo dấu khác.

3.4.11

Các bản ghi hệ thống quản lý cấu hình (configuration management system records)

Kết xuất tạo ra trong quá trình hoạt động của hệ thống quản lý cấu hình được tài liệu hóa, ghi lại các động thái quản lý cấu hình.

CHÚ THÍCH: Các ví dụ về bản ghi hệ thống quản lý cấu hình là các khuôn dạng điều khiển thay đổi khoản mục trong quản lý cấu hình hoặc các khuôn dạng phê duyệt truy nhập vào khoản mục quản lý cấu hình.

3.4.12

Các công cụ quản lý cấu hình (configuration management tools)

Các công cụ hoạt động thủ công hoặc tự động nhằm thực hiện hoặc hỗ trợ một hệ thống quản lý cấu hình

CHÚ THÍCH: Ví dụ các công cụ cho quản lý phiên bản cho các phần của TOE.

3.4.13

Tài liệu sử dụng quản lý cấu hình (configuration management usage documentation)

Phần của hệ thống quản lý cấu hình dùng để mô tả hệ thống quản lý cấu hình được định nghĩa và áp dụng như thế nào. Ví dụ, các sổ tay, các quy định và/hoặc tài liệu về các công cụ và các thủ tục.

3.4.14

Chuyển giao (delivery)

Vận chuyển một TOE hoàn chỉnh từ môi trường sản xuất tới tay khách hàng.

CHÚ THÍCH: Giai đoạn vòng đời sản phẩm này bao gồm cả việc đóng gói và lưu trữ tại địa điểm phát triển, song không bao gồm việc vận chuyển TOE chưa hoàn chỉnh hoặc các phần của TOE giữa các nhà phát triển hoặc giữa các địa điểm phát triển khác nhau.

3.4.15

Nhà phát triển (developer)

Tổ chức có trách nhiệm với việc phát triển TOE.

3.4.16

Phát triển (development)

Giai đoạn trong vòng đời sản phẩm liên quan đến việc biểu thị sự triển khai TOE.

CHÚ THÍCH: Trong mọi yêu cầu ALC, khái niệm phát triển và các khái niệm liên quan (nhà phát triển, phát triển) có ý nghĩa chung bao hàm cả việc phát triển và sản xuất.

3.4.17

Các công cụ phát triển (development tools)

Các công cụ (bao gồm phần mềm kiểm thử nếu có) hỗ trợ việc phát triển và sản xuất TOE.

CHÚ THÍCH: Ví dụ cho một TOE phần mềm, các công cụ phát triển thường là các ngôn ngữ lập trình, các trình biên dịch, các trình liên kết và các công cụ tạo lập.

3.4.18

Mô tả triển khai (implementation representation)

Mô tả trừu tượng tối thiểu cho một TSF, đặc trưng cho việc tạo ra TSF mà không cần bổ sung chi tiết thiết kế nào thêm.

CHÚ THÍCH: Mã nguồn được biên dịch hoặc bản vẽ phần cứng dùng để tạo ra phần cứng cụ thể là các ví dụ về các thành phần của một bản mô tả triển khai.

3.4.19

Vòng đời (life-cycle)

Chuỗi các giai đoạn tồn tại của một đối tượng (ví dụ một sàn phẩm hoặc một hệ thống) theo thời gian.

3.4.20

Định nghĩa vòng đời (life-cycle definition)

Định nghĩa cho một mô hình vòng đời.

3.4.21

Mô hình vòng đời (life-cycle model)

Mô tả các giai đoạn và mối quan hệ của chúng với các giai đoạn khác dùng cho việc quản lý vòng đời của một đối tượng nào đó, chỉ ra chuỗi các giai đoạn và các đặc tính mức cao của các giai đoạn cần phải như thế nào.

CHÚ THÍCH: Xem Hình 1.

3.4.22

Sản xuất (production)

Giai đoạn vòng đời sản xuất kế tiếp giai đoạn phát triển và bao gồm việc chuyển tải bản mô tả triển khai vào việc triển khai cụ thể cho TOE, nghĩa là đưa nó vào trạng thái chấp nhận được để chuyển giao cho khách hàng.

CHÚ THÍCH 1: Giai đoạn này gồm sản xuất, tích hợp, tạo lập, vận chuyển nội bộ, lưu trữ và ghi nhãn cho TOE.

CHÚ THÍCH 2: Xem thêm Hình 1.

Hình 1 - Các khái niệm trong CM và vòng đời sản phẩm

3.5. Các thuật ngữ và định nghĩa liên quan đến lớp AVA

3.5.1

Kênh bất hợp pháp (covert channel)

Kênh tín hiệu cưỡng ép trái phép, cho phép một người dùng lén lút vi phạm chính sách riêng biệt đa cấp và vi phạm các yêu cầu không quan sát được của TOE.

3.5.2

Các điểm yếu tiềm ẩn phải đối mặt (encountered potential vulnerabilities)

Các yếu điểm tiềm ẩn trong TOE có thể dùng để vi phạm các SFR được đánh giá viên nhận dạng trong khi thực hiện các hoạt động đánh giá.

3.5.3

Các điểm yếu có thể khai thác (exploitable vulnerability)

Các yếu điểm trong TOE có thể dùng để vi phạm các SFR trong môi trường vận hành của TOE.

3.5.4

Các tấn công giám sát (monitoring attacks)

Phân loại chung của các phương pháp tấn công có sử dụng các kỹ thuật phân tích thụ động nhằm phơi bày dữ liệu nhạy cảm bên trong TOE khi TOE hoạt động theo theo mô tả của các tài liệu hướng dẫn.

3.5.5

Các điểm yếu tiềm ẩn (potential vulnerability)

Các yếu điểm nghi vấn song chưa được khẳng định.

3.5.6

Các điểm yếu còn tồn tại (residual vulnerability)

Các yếu điểm không thể khai thác được trong môi trường vận hành của TOE, song một tin tặc có thể dùng để vi phạm các SFR với tiềm năng tấn công lớn hơn dự đoán trong môi trường vận hành của TOE.

3.5.7

Điểm yếu (vulnerability)

Yếu điểm trong TOE có thể dùng để vi phạm các SFR trong một số môi trường.

3.6. Các thuật ngữ và định nghĩa liên quan đến lớp ACO

3.6.1

Thành phần cơ sở (base component)

Thực thể trong một TOE tổng hợp, bản thân nó là chủ thể của một đánh giá, cung cấp dịch vụ và tài nguyên cho một thành phần phụ thuộc.

3.6.2

Tương thích (compatible)

(Thành phần) Là đặc tính của một thành phần về khả năng cung cấp các dịch vụ đòi hỏi bởi một thành phần khác, thông qua các giao diện phù hợp của mỗi thành phần trong môi trường vận hành nhất quán.

3.6.3

TOE thành phần (component TOE)

TOE đã được đánh giá thành công và là một phần của một TOE tổng hợp khác.

3.6.4

TOE tổng hợp (composed TOE)

TOE bao gồm hai hoặc nhiều thành phần đã được đánh giá thành công trước đó.

3.6.5

Thành phần phụ thuộc (dependent component)

Thực thể trong một TOE tổng hợp, bản thân nó là cơ quan của một đánh giá, dựa trên việc cung cấp dịch vụ bởi một thành phần cơ sở.

3.6.6

Giao diện chức năng (functional interface)

Giao diện với bên ngoài cung cấp cho người dùng khả năng truy xuất đến chức năng của một TOE không trực tiếp liên quan đến việc thực thi các yêu cầu chức năng an toàn.

CHÚ THÍCH: Trong một TOE tổng hợp có các giao diện cung cấp bởi thành phần cơ sở, được đòi hỏi bởi thành phần phụ thuộc để hỗ trợ hoạt động của TOE tổng hợp.

4. Ký hiệu và thuật ngữ viết tắt

Nội dung này liệt kê các thuật ngữ viết tắt trong tiêu chuẩn và các ký hiệu cần thiết để hiểu rõ hơn về tiêu chuẩn.

CHÚ THÍCH: Tiêu chuẩn này đưa ra các thuật ngữ bằng tiếng Việt, các thuật ngữ tiếng Anh tương đương và các thuật ngữ viết tắt tiếng Anh. Tuy chỉ có các thuật ngữ tiếng Việt mới được coi là của tiêu chuẩn, song các viết tắt thuật ngữ tiếng Anh giữ nguyên giúp cho việc tham chiếu tới tiêu chuẩn gốc thuận lợi hơn.

5. Tổng quan

5.1. Giới thiệu chung

Mục này giới thiệu các khái niệm chính của tiêu chuẩn TCVN 8709. Nó chỉ ra khái niệm “TOE”, các đối tượng sử dụng tiêu chuẩn, và cách thức tiếp cận để trình bày tiêu chuẩn.

5.2. TOE

Tiêu chuẩn TCVN 8709 linh hoạt trong việc đánh giá, do đó không bị bó hẹp trong giới hạn các sản phẩm CNTT như đa số vẫn hiểu. Bởi vậy, trong ngữ cảnh đánh giá, tiêu chuẩn này sử dụng khái niệm “TOE” (Đích đánh giá).

Một TOE được định nghĩa là một tập phần mềm, phần sụn và/hoặc phần cứng có thể kèm theo hướng dẫn.

Trong một số trường hợp TOE gồm có một sản phẩm CNTT, song đó không phải là cần thiết. TOE có thể là một sản phẩm CNTT, một phần của một sản phẩm CNTT, một tập các sản phẩm CNTT, một công nghệ độc nhất có thể chẳng khi nào dùng để sản sinh ra một sản phẩm, hoặc một tổ hợp của các thành phần trên.

Trong liên quan đến TCVN 8709, quan hệ chính xác giữa TOE và bất kỳ sản phẩm CNTT nào chỉ quan trọng ở một khía cạnh: đánh giá cho một TOE chỉ chứa một phần sản phẩm CNTT cần không thể hiện sai là đánh giá cho toàn bộ sản phẩm CNTT đó.

Ví dụ về các TOE là:

— Một ứng dụng phần mềm;

— Một hệ điều hành;

— Một ứng dụng phần mềm kết hợp với một hệ điều hành;

— Một ứng dụng phần mềm kết hợp với một hệ điều hành và một trạm làm việc;

— Một hệ điều hành kết hợp với một trạm làm việc;

— Một mạch tổ hợp thẻ thông minh;

— Một bộ đồng xử lý mật mã của một mạch tổ hợp thẻ thông minh;

— Một mạng cục bộ bao gồm tất cả các đấu nối, máy chủ, thiết bị mạng và phần mềm;

— Một ứng dụng cơ sở dữ liệu ngoại trừ phần mềm máy khách từ xa thường kết hợp với ứng dụng cơ sở dữ liệu.

5.2.1. Các mô tả khác nhau về TOE

Trong TCVN 8709, một TOE có thể xuất hiện theo một số cách thể hiện khác nhau, ví dụ (đối với TOE là phần mềm):

— Một danh sách các tệp trong một hệ thống quản lý cấu hình.

— Một bản sao chính mới được biên dịch;

— Một hộp chứa CD-ROM và sách hướng dẫn để chuyển tới khách hàng;

— Một phiên bản hoạt động đã cài đặt.

Tất cả những thể hiện nêu trên đều được xem là TOE: mỗi khi khái niệm “TOE” được dùng trong phần còn lại của tiêu chuẩn này, ngữ cảnh sẽ xác định cách thể hiện của nó.

5.2.2. Các cấu hình khác nhau của TOE

Nói chung, các sản phẩm CNTT có thể được cấu hình theo nhiều cách: cài đặt theo các cách khác nhau, với các tùy chọn khác nhau hoặc mở hoặc chặn. Vì khi đánh giá với TCVN 8709, TOE sẽ được xác định xem có thỏa mãn các yêu cầu xác định không, sự mềm dẻo trong cầu hình này có thể dẫn đến các vấn đề, do tất cả mọi cấu hình có thể của TOE sẽ phải thỏa mãn các yêu cầu. Vì những lý do này, thông thường phần hướng dẫn TOE phải hạn chế các cấu hình có thể của TOE. Nghĩa là, hướng dẫn TOE có thể khác với hướng dẫn chung cho sản phẩm CNTT.

Một ví dụ là với sản phẩm CNTT là hệ điều hành. Sản phẩm này có thể được cấu hình theo nhiều cách (ví dụ các kiểu người dùng, số người dùng, kiểu các kết nối ra ngoài cho phép/cấm, các tùy chọn mở/chặn ...)

Nếu sản phẩm CNTT cũng chính là một TOE, và được đánh giá theo một tập hợp lý các yêu cầu, cấu hình cần được kiểm soát chặt chẽ hơn, vì nhiều tùy chọn (ví dụ cho phép mọi kiểu kết nối ngoài hoặc quản trị hệ thống không cần phải được xác thực) sẽ dẫn đến vấn đề TOE không thỏa mãn các yêu cầu.

Vì lý do này, thông thường sẽ có sự khác biệt giữa hướng dẫn cho sản phẩm CNTT (cho phép nhiều cấu hình) và hướng dẫn cho TOE (cho phép chỉ một hoặc chỉ những cấu hình không có sự khác biệt về phương thức an toàn thích hợp).

Lưu ý là nếu hướng dẫn cho TOE vẫn cho phép nhiều hơn một cấu hình, các cấu hình này được gọi chung là “cho TOE” và mỗi cấu hình như vậy phải thỏa mãn các yêu cầu tập trung vào TOE.

5.3. Đối tượng sử dụng TCVN 8709

Ba nhóm người có mối quan tâm chung trong đánh giá các thuộc tính an toàn của các sản phẩm và hệ thống CNTT là: Người tiêu dùng TOE, nhà phát triển TOE và đánh giá viên TOE. Các tiêu chí được trình bày trong tài liệu này được xây dựng để hỗ trợ nhu cầu của cả ba nhóm trên. Họ được xem là người dùng chính của TCVN 8709. Lợi ích mà ba nhóm này có được từ các tiêu chí được liệt kê ra sau đây.

5.3.1. Người tiêu dùng

Tiêu chuẩn này được biên soạn nhằm đảm bảo rằng, việc đánh giá thỏa mãn các nhu cầu của người tiêu dùng vì đó là mục đích cơ bản và là biện minh cho quy trình đánh giá.

Người tiêu dùng có khả năng sử dụng kết quả đánh giá để giúp quyết định xem sản phẩm hoặc hệ thống đã đánh giá có thỏa mãn các nhu cầu an toàn của họ hay không. Những nhu cầu an toàn này thường được xác định qua kết quả của cả việc phân tích rủi ro và định hướng chính sách. Người tiêu dùng cũng có thể sử dụng các kết quả đánh giá để so sánh các TOE khác nhau.

TCVN 8709 mang lại cho người tiêu dùng - đặc biệt cho các nhóm người tiêu dùng và cộng đồng quan tâm - một cấu trúc độc lập với việc triển khai, được gọi là Hồ sơ bảo vệ (Protected Profile - PP), trong đó biểu thị các yêu cầu của họ về an toàn theo một cách rõ ràng.

5.3.2. Các nhà phát triển

TCVN 8709 hỗ trợ các nhà phát triển trong việc chuẩn bị và trợ giúp đánh giá các sản phẩm hoặc hệ thống, trong xác định các yêu cầu an toàn cần thỏa mãn cho các TOE. Các yêu cầu này được chứa trong một kết cấu phụ thuộc vào việc triển khai, được gọi là Đích An toàn (ST). Kết cấu ST này có thể dựa vào một hoặc nhiều PP để chỉ ra rằng ST tuân thủ các yêu cầu an toàn từ phía người tiêu dùng như đã sắp đặt trong các PP này.

TCVN 8709 có thể dùng để xác định trách nhiệm và các hành động để cung cấp bằng chứng cần thiết cho việc hỗ trợ đánh giá TOE theo các yêu cầu trên. Nó cũng định nghĩa nội dung và cách thể hiện của bằng chứng này.

5.3.3. Đánh giá viên

TCVN 8709 chứa các tiêu chí được đánh giá viên sử dụng khi lập ra các phán xét về sự tuân thủ của các TOE theo các yêu cầu an toàn của chúng. TCVN 8709 mô tả một tập hợp các công việc chung mà đánh giá viên cần thực hiện và các chức năng an toàn, căn cứ theo đó để thực hiện các công việc trên. Lưu ý là TCVN 8709 không chỉ ra các thủ tục hướng dẫn thực hiện các công việc này. Xem thêm thông tin về các thủ tục này ở Mục 5.5.

5.3.4. Các đối tượng khác

TCVN 8709 hướng tới việc định rõ và đánh giá các thuộc tính an toàn CNTT của các TOE, đồng thời nó cũng có thể là một tài liệu tham khảo hữu ích cho tất cả những ai quan tâm đến hoặc có trách nhiệm về an toàn CNTT. Một vài nhóm đối tượng quan tâm khác cũng có khả năng có lợi ích từ các thông tin trong TCVN 8709 bao gồm:

a) Các nhân viên bảo vệ hệ thống và các nhân viên an toàn hệ thống, những người có trách nhiệm trong việc xác định và đáp ứng các chính sách và yêu cầu an toàn CNTT cho tổ chức.

b) Các kiểm toán viên, cả bên trong và bên ngoài, có trách nhiệm lượng giá mức tương xứng về an toàn của một hệ thống.

c) Các nhân viên thiết kế và xây dựng hệ thống, có trách nhiệm định rõ nội dung an toàn cho các sản phẩm và hệ thống CNTT.

d) Những người được ủy quyền, có trách nhiệm chấp thuận việc một giải pháp CNTT đưa vào sử dụng trong một môi trường cụ thể.

e) Những người bảo trợ đánh giá, có trách nhiệm yêu cầu và hỗ trợ việc đánh giá.

f) Các cơ quan đánh giá, có trách nhiệm quản lý và giám sát các chương trình đánh giá an toàn CNTT.

5.4. Các phần khác nhau của bộ tiêu chuẩn

TCVN 8709 được trình bày dưới dạng một tập hợp ba phần riêng biệt song có liên quan như tóm tắt dưới đây. Các thuật ngữ sử dụng để mô tả các phần này được giải thích trong Điều 6.

a) Phần 1 (TCVN 8709-1): Giới thiệu và mô hình tổng quát, là phần giới thiệu về TCVN 8709. Trong đó có định nghĩa các khái niệm và nguyên tắc chung cho đánh giá an toàn CNTT, và trình bày một mô hình tổng quát cho đánh giá.

b) Phần 2 (TCVN 8709-2): Các thành phần chức năng an toàn, xây dựng một tập các thành phần chức năng an toàn theo cách biểu diễn chuẩn hóa các yêu cầu chức năng cơ bản cho các đích đánh giá (TOE). Phần 2 phân loại tập hợp các thành phần chức năng, các họ và các lớp.

c) Phần 3 (TCVN 8709-3): Các thành phần đảm bảo an toàn, xây dựng một tập các thành phần đảm bảo an toàn theo cách biểu diễn chuẩn hóa các yêu cầu đảm bảo cơ bản cho các đích đánh giá (TOE). Phần 3 phân loại tập hợp các thành phần đảm bảo, các họ và các lớp. Phần 3 cũng định nghĩa các tiêu chí đánh giá cho các Hồ sơ bảo vệ (PP) và các Đích An toàn (ST), và trình bày 7 gói đảm bảo định nghĩa trước gọi là các Mức đảm bảo đánh giá (EAL).

Để hỗ trợ ba phần của tiêu chuẩn như nêu ở trên, các tài liệu khác cũng đã được công bố, ví dụ ISO/IEC 18045 cung cấp hệ thống phương pháp cho đánh giá an toàn CNTT sử dụng ISO/IEC 15408 làm cơ sở. Dự đoán là sẽ có thêm các tài liệu khác được công bố, bao gồm các tư liệu sơ cứ kỹ thuật và các tài liệu hướng dẫn.

Bảng dưới đây biểu diễn ba nhóm đối tượng sử dụng tiêu chuẩn chủ chốt, dựa trên mức độ quan tâm đến các phần của tiêu chuẩn TCVN 8709:

Bảng 1 - Cấu trúc “Các tiêu chí đánh giá an toàn CNTT"

5.5. Ngữ cảnh đánh giá

Để đạt được sự so sánh rõ rệt giữa các kết quả đánh giá, các đánh giá cần được thực hiện trong khuôn khổ một lược đồ đánh giá có thẩm quyền. Lưu đồ đó đặt ra các tiêu chuẩn, giám sát chất lượng các đánh giá và quản lý các điều chỉnh mà các nhà đánh giá và các phương tiện đánh giá cần phải tuân thủ theo.

TCVN 8709 không nêu rõ các yêu cầu về bộ khung điều chỉnh. Mặc dù vậy, sự nhất quán giữa các bộ khung điều chỉnh của những người có thẩm quyền đánh giá khác nhau là cần thiết để đạt được mục tiêu công nhận lẫn nhau cho các kết quả đánh giá.

Một cách thứ hai để đạt được tính tương thích nhiều hơn giữa các kết quả đánh giá là sử dụng hệ phương pháp luận chung để đạt các kết quả này. Hệ phương pháp này được công bố trong tiêu chuẩn ISO/IEC 18045 cho tiêu chuẩn TCVN 8709.

Sử dụng một hệ phương pháp đánh giá chung giúp làm tăng khả năng lặp lại và tính khách quan của các kết quả, tuy nhiên như vậy vẫn chưa đủ. Nhiều tiêu chí đánh giá đòi hỏi vận dụng suy xét chuyên gia và kiến thức cơ bản, khi đó sẽ khó khăn hơn để đạt được sự nhất quán. Để nâng cao sự nhất quán của các nhận xét đánh giá, các kết quả đánh giá cuối cùng cần được thông qua một quy trình chứng nhận.

Quy trình chứng nhận là việc thanh tra độc lập các kết quả đánh giá, dẫn đến đưa ra chứng nhận cuối cùng hoặc công nhận. Chứng nhận thường được đưa ra công khai. Điều này chỉ ra rằng quy trình chứng nhận là một cách để đạt được một sự nhất quán hơn khi ứng dụng các tiêu chí an toàn CNTT.

Lược đồ đánh giá và các quy trình chứng nhận là trách nhiệm của những cơ quan đánh giá khi thực hiện các lược đồ đánh giá và không thuộc phạm vi của TCVN 8709.

6. Mô hình tổng quát

6.1. Giới thiệu mô hình tổng quát

Phần này trình bày các khái niệm chung được sử dụng trong TCVN 8709, bao gồm ngữ cảnh trong đó các khái niệm được sử dụng và cách thức TCVN 8709 áp dụng các khái niệm này. TCVN 8709-2 và TCVN 8709-3 là các tài liệu bắt buộc người dùng phần 1 của tiêu chuẩn TCVN 8709 phải tư vấn. Chúng mở rộng việc sử dụng các khái niệm này và giả định cách tiếp cận trên được dùng. Ngoài ra, đối với người dùng tiêu chuẩn TCVN 8709-1 nhằm thực hiện các hoạt động đánh giá, tiêu chuẩn ISO/IEC 18045 có thể áp dụng. Phần này giả thiết một số hiểu biết về an toàn CNTT và không dự định thực hiện vai trò hướng dẫn trong lĩnh vực này.

TCVN 8709 bàn về an toàn dựa trên một tập các khái niệm và thuật ngữ an toàn. Hiểu biết các khái niệm và thuật ngữ này được xem như một điều kiện tiên quyết để sử dụng hiệu quả TCVN 8709. Mặc dù vậy, bản thân các khái niệm này rất tổng quát, không dự kiến hạn chế sử dụng chỉ cho lớp các vấn đề an toàn CNTT mà trong đó TCVN 8709 được áp dụng.

6.2. Tài sản và các biện pháp đối phó

An toàn liên quan đến việc bảo vệ các tài sản. Các tài sản là các thực thể mà ai đó có thể đặt giá trị vào đó. Ví dụ về các tài sản là:

— Các nội dung của một tệp hay một máy chủ;

— Tính xác thực của việc bỏ phiếu trong một cuộc bầu cử;

— Tính khả dụng của một quy trình thương mại điện tử;

— Khả năng sử dụng một máy in đắt tiền;

— Truy nhập vào một tiện nghi đã phân loại tính mật.

Tuy vậy, do các giá trị có tính chủ quan cao, hầu hết các thứ đều có thể là một tài sản.

(Các) môi trường trong đó các tài sản này được đặt, được gọi là môi trường vận hành. Ví dụ về (các khía cạnh của) môi trường vận hành là:

— Phòng máy tính của một ngân hàng;

— Một mạng máy tính kết nối với Internet;

— Một mạng cục bộ (LAN);

— Một môi trường công sở nói chung.

Rất nhiều tài sản ở dạng thông tin được lưu trữ, xử lý, truyền tải bởi các sản phẩm CNTT để thỏa mãn các yêu cầu đặt ra bởi các chủ sỡ hữu thông tin. Các chủ sở hữu thông tin có thể yêu cầu là tính khả dụng, phổ biến và sửa đổi của bất kỳ thông tin nào kể trên cần được kiểm soát chặt chẽ và các tài sản cần được bảo vệ chống các mối đe dọa băng các biện pháp đối phó. Hình 2 minh họa cho các khái niệm và các mối quan hệ mức cao.

Hình 2 - Các khái niệm và quan hệ về an toàn

Đảm bảo an toàn cho tài sản là trách nhiệm của người chủ sở hữu, người đưa các giá trị vào các tài sản đó. Các tác nhân đe dọa hiện hữu hoặc dự đoán cũng có thể đưa các giá trị vào tài sản và tìm cách lạm dụng tài sản theo cách trái ngược với lợi ích của chủ sờ hữu. Ví dụ về các tác nhân đe dọa là các tin tặc, kẻ ác ý, những người vô ý (những người đôi lúc gây lỗi), các tiến trình và các tai họa trong máy tính.

Chủ sở hữu sẽ nhận thức được các đe dọa đó là một nguy cơ tổn hại đến các tài sản cũng như làm giảm giá trị các tài sản của họ. Những tổn hại đặc trưng về an toàn nói chung bao gồm, song không chỉ giới hạn ở: mất tính bí mật của tài sản, mất tính toàn vẹn của tài sản và mất tính sẵn sàng của tài sản.

Các mối đe dọa nêu trên sẽ làm gia tăng các rủi ro cho tài sản, dựa trên khả năng một đe dọa đang hình thành và ảnh hưởng vào tài sản khi mối đe dọa được hình thành. Các biện pháp đối phó tiếp theo sẽ được đưa ra nhằm giảm thiểu rủi ro cho các tài sản. Các biện pháp đối phó này có thể gồm các biện pháp đối phó thuộc CNTT (như các tường lửa hay thẻ thông minh) hay các biện pháp đối phó phi- CNTT (như bảo vệ và các quy trình). Có thể xem thêm tiêu chuẩn ISO/IEC 27001 và ISO/IEC 27002 để có thêm thông tin về các biện pháp đối phó an toàn (các điều khiển) và việc triển khai và quản lý chúng như thế nào.

Các chủ sở hữu tài sản có thể chịu trách nhiệm về các tài sản trên và do vậy cần có khả năng bảo vệ quyết định chấp nhận các rủi ro phơi bày tài sản trước các mối đe dọa.

Có hai thành phần quan trọng trong việc bảo vệ quyết định này có thể diễn giải, đó là:

— Các biện pháp đối phó là vừa đủ: Nếu các biện pháp đối phó thực hiện theo những gì chúng đặt ra để thực hiện, các mối đe dọa đối với tài sản được ngăn chặn.

— Các biện pháp đối phó là chính xác: Các biện pháp đối phó thực hiện đúng những gì chúng đặt ra để thực hiện.

Nhiều chủ sở hữu tài sản thiếu nhận thức, kinh nghiệm hay tài nguyên cần thiết để suy xét mức độ đầy đủ và chính xác của các biện pháp đối phó, và họ có thể không muốn chỉ đơn thuần dựa vào sự xác nhận của của các nhà phát triển các biện pháp đối phó. Những người tiêu dùng này, do vậy, có thể chọn cách tăng độ tin cậy trong mức độ đủ và chính xác của một số hoặc toàn bộ các biện pháp đối phó thông qua việc đặt hàng đánh giá các biện pháp đối phó này.

Hình 3 - Các khái niệm và quan hệ trong đánh giá

6.2.1. Tính đầy đủ của các biện pháp đối phó

Trong khi đánh giá, tính đầy đủ của các biện pháp đối phó được phân tích thông qua một kết cấu gọi là Đích an toàn (ST). Mục này trình bày một cách sơ lược về kết cấu này, chi tiết và mô tả đầy đủ về ST có thể xem trong Phụ lục A.

Đích an toàn bắt đầu băng việc mô tả các tài sản và các mối đe dọa tới chúng. Tiếp đó, Đích an toàn mô tả các biện pháp đối phó (dưới dạng các Mục tiêu an toàn) và diễn giải rằng các biện pháp đối phó này là đủ để chổng lại các mối đe dọa kể trên: Nếu các biện pháp đối phó thực hiện những gì chúng cần phải thực hiện, các mối đe dọa sẽ được ngăn chặn.

Tiếp theo, Đích an toàn chia các biện pháp đối phó này thành hai nhóm:

a) Các mục tiêu an toàn cho TOE: Đây là mô tả các biện pháp đối phó mà tính chính xác sẽ được xác định trong khi đánh giá;

b) Các mục tiêu an toàn cho môi trường vận hành: Đây là mô tả các biện pháp đối phó mà tính chính xác sẽ không được xác định trong khi đánh giá;

Lý do để chia ra hai nhóm trên như sau:

— TCVN 8709 chỉ thích hợp cho việc đánh giá tính chính xác của các biện pháp đối phó thuộc CNTT. Do đó các biện pháp đối phó phi- CNTT (ví dụ như nhân viên bảo vệ, quy trình) luôn thuộc về môi trường vận hành.

— Việc đánh giá tính chính xác của các biện pháp đối phó tiêu tốn thời gian và tiền bạc, có thể làm nó bất khả thi trong việc đánh giá cho tất cả các biện pháp đối phó thuộc CNTT.

— Tính chính xác của một số biện pháp đối phó thuộc CNTT có thể đã được đánh giá trong một quá trình đánh giá khác. Bởi vậy, để hiệu quả, không cần phải đánh giá lại một lần nữa.

Đối với TOE (các biện pháp đối phó thuộc CNTT với tính chính xác sẽ được đánh giá trong quá trình đánh giá), Đích an toàn đòi hỏi có thêm chi tiết về các mục tiêu an toàn cho TOE trong các yêu cầu chức năng an toàn (SFR). Các SFR này được trình bày trong một ngôn ngữ chuẩn (mô tả trong TCVN 8709-2) để bảo đảm sự chính xác và dễ tương thích.

Tóm lại, Đích an toàn diễn giải:

— Các SFR thỏa mãn các mục tiêu an toàn cho TOE;

— Các mục tiêu an toàn cho TOE và các mục tiêu an toàn cho môi trường vận hành ngăn chặn các mối đe dọa;

— Và do vậy, các SFR cũng như các mục tiêu an toàn cho môi trường vận hành ngăn chặn các mối đe dọa.

Từ đây suy ra rằng, một TOE đúng (thỏa mãn các SFR) trong sự kết hợp với một môi trường vận hành đúng (thỏa mãn các mục tiêu an toàn cho môi trường vận hành) sẽ ngăn chặn các mối đe dọa. Trong hai mục con tiếp theo, tính chính xác của TOE và tính chính xác của môi trường vận hành sẽ được trình bày riêng biệt.

6.2.2. Tính chính xác của TOE

Một Toe có thể được thiết kế và triển khai không chính xác, do đó có thể chứa các lỗi dẫn đến điểm yếu. Qua khai thác các điểm yếu này, tin tặc vẫn có thể phá hoại và/hoặc lạm dụng các tài sản.

Các điểm yếu trên có thể xuất hiện từ các lỗi ngẫu nhiên có trong quá trình phát triển, thiết kế sơ sài, việc cố ý chèn thêm mã độc, kiểm thử sơ sài, v.v.

Để xác định tính chính xác của TOE, nhiều động thái có thể thực hiện ví dụ như:

— Kiểm thử TOE;

— Kiểm tra các mô tả thiết kế khác nhau của TOE;

— Kiểm tra an toàn vật lý cho môi trường phát triển của TOE.

Đích an toàn cung cấp một mô tả có cấu trúc của các động thái này để xác định tính chính xác dưới dạng Các yêu cầu đảm bảo an toàn (Security Assurance Requirements - SAR). Các SAR này được biểu thị trong một ngôn ngữ chuẩn (mô tả trong TCVN 8709-3) để bảo đảm sự chính xác và dễ tương thích.

Nếu các SAR được thỏa mãn, sẽ có sự bảo đảm về tính chính xác của TOE, và do đó TOE gần như ít chứa các điểm yếu có thể bị tin tặc khai thác hơn. Lượng bảo đảm có trong tính chính xác của TOE được chính các SAR này xác định: Một vài SAR “yếu” có thể dẫn đến khả năng bảo đảm kém, nhiều SAR “mạnh” sẽ dẫn đến bảo đảm nhiều.

6.2.3. Tính chính xác của môi trường vận hành

Môi trường vận hành có thể được thiết kế và triển khai không đúng, do đó có thể chứa các lỗi dẫn đến điểm yếu. Qua khai thác các điểm yếu này, tin tặc vẫn có thể phá hoại và/hoặc lạm dụng các tài sản.

Tuy nhiên, trong tiêu chuẩn TCVN 8709, không có sự bảo đảm nào đạt được liên quan đến tính chính xác của môi trường vận hành. Hay nói một cách khác, môi trường vận hành không được đánh giá (xem mục 6.3).

Trong liên quan đến đánh giá, môi trường vận hành được giả định là thuyết minh đúng 100% về các mục tiêu an toàn cho môi trường vận hành.

Điều này không cản trở người tiêu dùng một TOE sử dụng các phương pháp khác để xác định tính chính xác của môi trường vận hành đó, ví dụ:

— Nếu đối với một TOE là hệ điều hành, các mục tiêu an toàn cho môi trường vận hành khẳng định “môi trường vận hành cần bảo đảm rằng các thực thể từ một mạng không tin cậy (ví dụ Internet) có thể chỉ truy nhập vào TOE bằng ftp”, người tiêu dùng có thể chọn lựa một tường lửa đã đánh giá, và cấu hình nó chỉ để cho phép truy nhập ftp đến TOE;

— Nếu các mục tiêu an toàn cho môi trường vận hành khẳng định “môi trường vận hành cần bảo đảm rằng mọi nhân viên quản trị không có hành vi ác ý", người tiêu dùng có thể điều chỉnh hợp đồng với các nhân viên quản trị để đưa vào các hình phạt đối với hành vi ác ý, song việc xác định này không thuộc phạm vi đánh giá theo TCVN 8709.

Các chủ sở hữu tài sản sẽ phân tích các mối đe dọa có thể xảy ra với tài sản và môi trường của họ, xác định các rủi ro liên quan tới chúng. Phân tích trên có thể hỗ trợ trong việc lựa chọn các biện pháp phòng chống để chống lại các rủi ro và giảm chúng xuống một mức độ chấp nhận được.

Các biện pháp phòng chống được áp đặt để làm giảm các điểm yếu và để đáp ứng các chính sách an toàn của chủ sở hữu tài sản (hoặc trực tiếp hoặc gián tiếp thông qua chỉ dẫn tới các phần khác). Các điểm yếu còn lại có thể vẫn tồn tại sau khi áp đặt các biện pháp phòng chống. Các điểm yếu đó có thể bị khai thác bởi các tác nhân đe dọa thể hiện một mức độ rủi ro tồn đọng cho tài sản. Các chủ sở hữu sẽ tìm cách giảm thiểu rủi ro đó theo những ràng buộc khác.

6.3. Đánh giá

TCVN 8709 thừa nhận hai kiểu đánh giá: đánh giá một ST/TOE như được mô tả sau đây, và đánh giá các PP được định nghĩa trong TCVN 8709-3. Tại nhiều vị trí, TCVN 8709 sử dụng khái niệm đánh giá (không có bổ nghĩa) để chỉ đánh giá ST/TOE.

Trong TCVN 8709, đánh giá ST/TOE được thực hiện theo hai bước sau:

a) Đánh giá ST: xác định tính đầy đủ của TOE và môi trường vận hành.

b) Đánh giá TOE: Xác định tính chính xác của TOE. Như đã nêu ở trên, đánh giá TOE không hàm ý đánh giá tính chính xác của môi trường vận hành.

Đánh giá ST được thực hiện bằng việc áp dụng các tiêu chí đánh giá Đích an toàn (như đã định nghĩa trong TCVN 8709-3 Điều khoản ASE) cho Đích an toàn. Phương pháp chuẩn xác áp dụng các tiêu chí ASE được xác định bởi hệ phương pháp đánh giá được dùng.

Đánh giá TOE phức tạp hơn. Các đầu vào chính của đánh giá TOE là: bằng chứng đánh giá bao gồm TOE và ST, song thường cũng bao gồm cả đầu vào từ môi trường phát triển, ví dụ các tài liệu thiết kế hoặc các kết quả kiểm thử của nhà phát triển.

Đánh giá TOE gồm việc áp dụng các SAR (từ Đích an toàn) vào bằng chứng đánh giá. Phương pháp chuẩn xác để áp dụng một SAR cụ thể được xác định bởi hệ phương pháp đánh giá được dùng.

Việc tài liệu hóa các kết quả áp dụng SAR như thế nào, các báo cáo nào cần tạo ra và đến mức chi tiết nào được xác định bởi cả hệ phương pháp đánh giá được dùng và lược đồ đánh giá theo đó phép đánh giá được thực hiện.

Kết quả của quá trình đánh giá TOE là một trong hai phát biểu sau:

— Một phát biểu về việc không phải mọi SAR đều được thỏa mãn và do đó không có mức đảm bảo đã chỉ ra cho việc TOE thỏa mãn các SFR như đã nêu trong ST;

— Một phát biểu về việc mọi SAR đều được thỏa mãn và do đó có mức đảm bảo đã chỉ ra cho việc TOE thỏa mãn các SFR như đã nêu trong ST;

Đánh giá TOE có thể thực hiện sau khi bước phát triển TOE hoàn tất, hoặc song song với quá trình phát triển TOE.

Phương pháp công bố kết quả đánh giá ST/TOE được mô tả trong Điều 9. Các kết quả này cũng định danh các PP và các gói mà TOE đòi hỏi tuân thủ, các kết cấu này được mô tả trong Điều 7.

7. Biến đổi thích ứng các yêu cầu an toàn

7.1. Các hoạt động

Các thành phần chức năng và đảm bảo của tiêu chuẩn có thể sử dụng chính xác như đã định nghĩa trong TCVN 8709-2 và TCVN 8709-3, hoặc chúng có thể được biến đổi thích ứng qua việc dùng các hoạt động được phép. Khi sử dụng các hoạt động, tác giả PP/ST cần thận trọng là các nhu cầu phụ thuộc vào các yêu cầu khác lệ thuộc vào yêu cầu này cần được thỏa mãn. Các hoạt động được phép được chọn từ tập sau đây:

— Phép lặp: cho phép một thành phần được sử dụng nhiều lần với các hoạt động biến đổi;

— Phép chỉ định: cho phép đặc tả các tham số

— Phép lựa chọn: cho phép đặc tả một hoặc nhiều biểu thức từ một danh sách

— Phép bổ sung chi tiết: cho phép bổ sung các chi tiết

Các hoạt động chỉ định và chọn được cho phép chỉ khi thể hiện một cách rõ rệt trong một thành phần. Các hoạt động lặp và bổ sung chi tiết được phép cho mọi thành phần. Các hoạt động được mô tả chi tiết ở phần sau.

Các phụ lục của TCVN 8709-2 cung cấp hướng dẫn về việc hoàn thiện hợp lệ các lựa chọn và chỉ định. Hướng dẫn này cung cấp các lệnh chuẩn về việc hoàn thành các hoạt động như thế nào, các lệnh đó sẽ kế tiếp ngoại trừ tác giả PP/ST bố trí lại các lệch lạc sau:

a) Từ “Không” chỉ có thể dùng làm một lựa chọn để hoàn tất một phép lựa chọn nếu nó được cung cấp rõ ràng.

Các danh sách đã cung cấp cho việc hoàn thiện các phép lựa chọn cần không được là danh sách trắng. Nếu tùy chọn “Không” được chọn, sẽ không có tùy chọn phép lựa chọn bổ sung nào có thể được chọn. Nếu “Không” đưa ra trong một phép lựa chọn không phải là tùy chọn, nó cho phép kết hợp các chọn lựa trong một phép lựa chọn với “và” và “hoặc", ngoại trừ phép lựa chọn công bố rõ “chọn một trong số …"

Các hoạt động chọn có thể kết hợp bởi phép lặp khi cần. Trong trường hợp này, khả năng áp dụng được của tùy chọn đã chọn cho mỗi phép lặp cần không chồng lấn lên cơ quan của các phép lựa chọn có lặp khác, vì chúng dự kiến là bị loại trừ.

b) Để hoàn thành các phép gán, các phụ lục của TCVN 8709-2 sẽ được tham khảo để xác định ra khi nào “không” có thể là một hoàn tất hợp lệ.

7.1.1. Hoạt động lặp

Hoạt động lặp có thể được thực hiện ở mọi thành phần. Tác giả PP/ST thực hiện một hoạt động lặp bằng cách đưa vào nhiều yêu cầu dựa trên cùng một thành phần. Mỗi phép lặp của một thành phần cần khác biệt với mọi phép lặp khác của thành phần đó, điều này được thực hiện bằng việc hoàn thành các phép chỉ định và phép lựa chọn theo một cách khác, hoặc áp dụng phép bổ sung chi tiết cho nó theo một cách khác.

Các phép lặp khác nhau nên định danh duy nhất để cho phép các sở cứ và các dấu vết đến từ và đi từ các yêu cầu này.

Quan trọng là cần lưu ý rằng đôi lúc một hoạt động lặp có thể được dùng với các thành phần, khi đó cũng có thể thực hiện một phép chỉ định với một khoảng giá trị hoặc một danh sách các giá trị thay vì lặp lại chúng. Trong trường hợp này, tác giả có thể chọn ra phương án thích hợp nhất, xem xét xem cs cần cung cấp toàn bộ sở cứ cho một khoảng giá trị hoặc xem có cần có riêng từng sở cứ tách biệt cho mỗi khoảng. Tác giả nên lưu ý nếu việc ghi dấu vết riêng được yêu cầu cho các giá trị này.

7.1.2. Hoạt động chỉ định

Một hoạt động chỉ định xảy ra khi một thành phần cho trước chứa một phần tử với tham số có thể đặt bởi tác giả PP/ST. Tham số có thể là một biến không giới hạn, một quy tắc hạn chế biến trong một khoảng giá trị nhất định.

Mỗi khi một phần tử trong một PP có chứa một phép chỉ định, tác giả của PP cần thực hiện một trong bốn việc sau:

a) Rời bỏ phép chỉ định không hoàn tất. Tác giả PP có thể đưa vào FIA_ASL.1.2 “Khi một số lượng xác định phép thử xác thực không thành công đạt được hoặc vượt qua, TSF cần [Ấn định: danh sách các hành động]” trong PP.

b) Hoàn tất phép chỉ định: ví dụ, tác giả PP có thể đưa vào FIA_ASL .1.2 “Khi một số lượng xác định phép thử xác thực không thành công được thỏa mãn hoặc được vượt qua, TSF cần “ngăn cản thực thể bên ngoài gắn kết với bất kỳ cơ quan nào trong tương lai’’ trong PP.

c) Thu hẹp phép chỉ định, tiếp đó giới hạn khoảng giá trị cho phép. Ví dụ, tác giả PP'có thể đưa vào FIA_ÀL.1.1 “TSF cần phát hiện khi nào [Ấn định: một số nguyên dương giữa 4 và 9] lần thử xác thực không thành công xảy ra...” trong PP.

d) Chuyển đổi phép chỉ định thành một phép lựa chọn, qua đó thu hẹp phép chỉ định. Ví dụ, tác giả PP có thể đưa vào FIA_ÀL.1.2 “Khi một số xác định số lần thử xác thực không thành công đã đạt được hoặc vượt quá,TSF cần [Chọn: ngăn cản người dùng này gắn kết với bất kỳ cơ quan nào trong tương lai, thông báo cho người quản trị” trong PP.

Mỗi khi một phần tử trong một ST chứa một phép chỉ định, tác giả ST cần hoàn tất phép gán này, như đã biểu thị ở mục b) nêu trên. Các tùy chọn a), c) và d) không cho phép đối với ST.

Các giá trị được chọn trong các tùy chọn b), c) và d) cần tuân thủ theo kiểu đã chỉ ra yêu cầu bởi phép chỉ định.

Khi một phép chỉ định cần được hoàn thành với một tập (ví dụ các cơ quan), nó có thể là liệt kê một tập các cơ quan, song cũng một số mô tả của tập có thể được các phần từ của tập dẫn xuất ra, như:

— Toàn bộ các cơ quan

— Toàn bộ các cơ quan của kiểu X

— Toàn bộ các cơ quan ngoại trừ cơ quan a

Chừng nào còn rõ các cơ quan nào được xét tới.

7.1.3. Hoạt động lựa chọn

Một hoạt động lựa chọn xảy ra khi một thành phần cho trước chứa một phần tử và một chọn lựa từ các biểu thức cần được lập bởi tác giả PP/ST.

Mỗi khi một phần tử trong một PP có chứa một phép lựa chọn, tác giả của PP cần thực hiện một trong ba việc sau:

e) Rời bỏ phép lựa chọn không hoàn tất.

f) Hoàn tất phép lựa chọn bằng việc lựa chọn một hoặc nhiều biểu thức.

g) Giới hạn phép lựa chọn qua việc xóa bỏ một số lựa chọn, song để lại 2 hoặc nhiều hơn.

Mỗi khi một phần tử trong 1 ST chứa một phép lựa chọn, tác giả ST cần hoàn tất phép lựa chọn này, như đã biểu thị ở mục b) nêu trên. Các tùy chọn a), c) và d) không cho phép đối với ST.

Biểu thức hoặc các biểu thức được chọn ở b) và c) cần lấy từ các biểu thức đã cung cấp ở phép lựa chọn.

7.1.4. Hoạt động bổ sung chi tiết

Hoạt động bổ sung chi tiết có thể được thực hiện ở mọi yêu cầu. Tác giả PP/ST thực hiện một phép bổ sung chi tiết bằng cách thay đổi yêu cầu này. Quy tắc đầu tiên cho một phép bổ sung chi tiết là một TOE đáp ứng yêu cầu đã chi tiết hóa cũng sẽ đáp ứng các yêu cầu không chi tiết hóa trong ngữ cảnh của PP/ST (nghĩa là yêu cầu chi tiết hóa cần phải “chặt” hơn yêu cầu ban đầu). Nếu một phép bổ sung chi tiết không thỏa mãn quy tắc này, kết quả yêu cầu chi tiết hóa được coi là một yêu cầu mở rộng và cần xử lý như vậy.

Chỉ có một ngoại lệ cho quy tắc này là một tác giả PP/ST được phép bổ sung chi tiết cho SFR để áp dụng cho một số, song không phải là tất cả cơ quan, đối tượng, hoạt động, thuộc tính an toàn và/hoặc các thực thể bên ngoài.

Tuy nhiên, ngoại lệ này không áp dụng cho bổ sung chi tiết SFR lấy từ các PP đang đòi hỏi tuân thủ. Các SFR này có thể không được bổ sung chi tiết để áp dụng to một vài cả cơ quan, đối tượng, hoạt động, thuộc tính an toàn và/hoặc các thực thể bên ngoài so với SFR trong PP.

Quy tắc thứ hai cho một phép bổ sung chi tiết là một phép bổ sung chi tiết cần liên quan đến thành phần chính hiệu.

Một trường hợp đặc biệt của phép bổ sung chi tiết là một bổ sung chi tiết biên soạn, trong đó một thay đổi nhỏ được tạo trong một yêu cầu, nghĩa là làm rõ nghĩa một câu để trung thành với ngữ pháp tiếng Anh đúng, hoặc làm cho nó dễ hiểu hơn cho người đọc. Sự thay đổi này không được phép sửa đổi ý nghĩa của yêu cầu theo bất kỳ cách nào.

7.2. Sự phụ thuộc giữa các thành phần

Giữa các thành phần có thể có các quan hệ phụ thuộc. Các quan hệ phụ thuộc nảy sinh khi một thành phần không đủ và phải tồn tại khi có mặt thành phần khác để cung cấp tính năng an toàn hay đảm bảo.

Các thành phần chức năng trong TCVN 8709-2 điển hình có sự phụ thuộc vào các thành phần chức năng khác như một số thành phần đảm bảo trong TCVN 8709-3 đã có, chúng có thể có sự phụ thuộc vào các thành phần khác của TCVN 8709-3. Sự phụ thuộc của TCVN 8709-2 vào các thành phần TCVN 8709-3 cũng có thể được định nghĩa. Tuy nhiên, điều này không ngăn cản các thành phần chức năng ngoài có sự phụ thuộc vào các thành phần đảm bảo và ngược lại.

Các mô tả sự phụ thuộc của thành phần được xác định qua tham khảo các định nghĩa thành phần trong TCVN 8709-2 và TCVN 8709-3. Để đảm bảo mô tả sự hoàn thiện các yêu cầu an toàn TOE, các phụ thuộc cần được thỏa mãn khi các yêu cầu dựa trên các thành phần với sự phụ thuộc được kết hợp vào PP và ST. Các phụ thuộc nên được xem xét khi cấu trúc các gói.

Nói một cách khác, nếu thành phần A có sự phụ thuộc vào thành phần B, điều đó nghĩa là mỗi khi một PP/ST có chứa một yêu cầu an toàn dựa trên thành phần A, PP/ST cũng cần chứa một trong số:

a) Một yêu cầu an toàn dựa trên thành phần B, hoặc

b) Một yêu cầu an toàn dựa trên một thành phần nằm ở phân cấp cao hơn B, hoặc

c) Một biện minh tại sao PP/ST không chưa một yêu cầu an toàn dựa trên thành phần B.

Trong các trường hợp a) và b), khi một yêu cầu an toàn được bao hàm do tính phụ thuộc, có thể cần thiết phải hoàn thiện các hoạt động (chỉ định, lặp, bổ sung chi tiết, chọn) trên yêu cầu an toàn này theo một cách riêng để đảm bảo rằng nó thực sự thỏa mãn tính phụ thuộc.

Trong trường hợp c), biện minh cho việc không chứa một yêu cầu an toàn nên đề cập đến:

— Tại sao sự phụ thuộc không cần thiết hay không hữu ích, hoặc

— Sự phụ thuộc đã đề cập trong môi trường vận hành của TOE, trong đó việc biện minh cần mô tả cách các mục tiêu an toàn cho môi trường vận hành đề cập đến sự phụ thuộc của nó như thế nào, hoặc

— Sự phụ thuộc đã đề cập đến bởi các SFR khác theo một cách nào đó (các SFR mở rộng, các tổ hợp của các SFR...)

7.3. Các thành phần mở rộng

Trong TCVN 8709, các yêu cầu bắt buộc phải dựa vào các thành phần trong TCVN 8709-2 hoặc TCVN 8709-3 với 2 ngoại lệ sau:

a) Có các mục tiêu an toàn cho TOE không thể chuyển đổi sang các SFR của phần 2, hoặc có các yêu cầu của bên thứ ba (ví dụ luật pháp, tiêu chuẩn) không thể chuyển đổi sang các SAR của phần 3 (ví dụ liên quan đến đánh giá mật mã).

b) Một mục tiêu an toàn có thể được chuyển đổi, song chỉ với mức độ phức tạp cao hoặc/và khó khăn lớn trên cơ sở các thành phần trong TCVN 8709-2 hoặc TCVN 8709-3.

Trong cả hai trường hợp, tác giả PP/ST được đòi hỏi phải định nghĩa các thành phần riêng của họ. Các thành phần mới được định nghĩa này được gọi là các thành phần mở rộng. Một thành phần mở rộng được định nghĩa chính xác là cần thiết để đưa ra ngữ cảnh và ý nghĩa cho các SFR và SAR mở rộng dựa trên thành phần này.

Sau khi các thành phần mới đã được định nghĩa chính xác, tác giả PP/ST có thể đưa ra một hoặc nhiều SFR hoặc SAR trên cơ sở các thành phần mở rộng đã định nghĩa này và sử dụng chúng theo cùng cách như với các SFR và SAR khác. Từ đây trở đi, không có sự phân biệt hơn giữa các SAR và SFR dựa theo TCVN 8709 và các SAR, SFR dựa trên các thành phần mở rộng. Xem thêm phần định nghĩa các thành phần mở rộng của TCVN 8709-3 (APE_ECD) và định nghĩa các thành phần mở rộng (ASE_ECD) để rõ hơn các yêu cầu về các thành phần mở rộng.

8. Hồ sơ bảo vệ và gói

8.1. Giới thiệu

Để cho phép các nhóm người tiêu dùng và cộng đồng quan tâm biểu thị các nhu cầu an toàn của họ, và để thuận lợi cho việc viết các ST, phần này của tiêu chuẩn cung cấp hai kết cấu đặc biệt: các gói và các hồ sơ bảo vệ (PPs). Trong các mục 8.2 và 8.3, các kết cấu này được mô tả chi tiết hơn. Mục nhỏ 8.4. giải thích các kết cấu này có thể được dùng như thế nào.

8.2. Các gói

Một gói là một tập định danh các yêu cầu an toàn. Một gói có thể là:

— Một gói chức năng, chỉ chứa các SFR, hoặc

— Một gói đảm bảo, chỉ chứa các SAR.

Không được phép có các gói hỗn hợp chứa cả SFR và SAR.

Một gói có thể được định nghĩa bởi bất kỳ bên nào và dự kiến là có thể tái sử dụng. Để đạt được mục tiêu này, nó cần chứa các yêu cầu hữu ích và hiệu quả kết hợp với nhau. Các gói có thể được dùng trong kiến thiết các gói lớn hơn, các PP và ST. Hiện tại không có tiêu chí nào cho việc đánh giá các gói, do vậy bất kỳ tập SAR hay SFR có thể là một gói.

Ví dụ về các gói đảm bảo như: các mức đảm bảo đánh giá (EAL) được định nghĩa trong TCVN 8709-3. Hiện tại, chưa có các gói chức năng cho phiên bản tiêu chuẩn này.

8.3. Các hồ sơ bảo vệ

Trong khi một ST luôn mô tả một TOE nhất định (ví dụ thiết bị tường lửa FW MinuteGap V18.5), một PP dự kiến mô tả một kiểu TOE (ví dụ các tường lửa). Cũng PP này do đó có thể sử dụng làm bản mẫu cho nhiều ST khác để sử dụng trong các phép đánh giá khác nhau. Mô tả chi tiết của các PP được đưa ra trong Phụ lục B.

Nói chung, một ST mô tả các yêu cầu cho một TOE, và được viết bởi nhà phát triển TOE này, trong khi đó một PP mô tả các yêu cầu chung co một kiểu TOE, và do đó thường được viết bởi:

— Một cộng đồng người dùng tìm kiếm sự đồng thuận về các yêu cầu cho một kiểu TOE cho trước.

— Một nhà phát triển TOE, hay một nhóm các nhà phát triển của các TOE tương tự mong muốn lập ra một mức tổi thiểu cho kiểu TOE này.

— Một chính phủ, hoặc tập đoàn lớn chỉ rõ các yêu cầu của họ là một phần của quá trình thu thập thông tin.

PP xác định kiểu được phép cho tính tuân thủ của ST với PP. Nghĩa là PP công bố (trong phát biểu tuân thủ PP, sem B.5) rằng các kiểu tuân thủ được phép cho ST là:

— Nếu PP công bố là sự tuân thủ chặt chẽ cần có, ST cần tuân thủ với PP theo cách chặt chẽ;

— Nếu PP công bố rằng cần có sự tuân thủ có thể diễn giải được, ST cần tuân thủ với PP theo cách chặt chẽ hoặc cách diễn giải được.

Tường trình lại điều trên theo một cách nói khác, một ST chỉ được phép tuân thủ trong một PP theo cách diễn giải được, nếu PP cho phép một cách rõ ràng điều này.

Nếu một ST đòi hỏi sự tuân thủ với nhiều PP, nó cần tuân thủ (như đã mô tả ở trên) cho mỗi PP theo cách được quy định bởi PP này. Điều này có thể nghĩa là ST tuân thủ chặt chẽ với một số PP và có thể diễn giải tới các PP khác.

Lưu ý rằng hoặc ST tuân thủ theo PP trong yêu cầu hoặc nó không tuân thủ. TCVN 8709 không chấp thuận tính tuân thủ “từng phần”. Do đó, trách nhiệm của tác giả PP là đảm bảo PP không phiền hà thái quá, ngăn cấm tác giả PP/ST trong đòi hỏi tuân thủ theo PP.

Một ST tương đương hoặc gới hạn hơn nhiều so với một P nếu: