Tiêu chuẩn TCVN 8709-3:2011 Các thành phần đảm bảo an toàn mức đánh giá CNTT

  • Thuộc tính
  • Nội dung
  • Tiêu chuẩn liên quan
  • Lược đồ
  • Tải về
Mục lục Đặt mua toàn văn TCVN
Lưu
Theo dõi văn bản

Đây là tiện ích dành cho thành viên đăng ký phần mềm.

Quý khách vui lòng Đăng nhập tài khoản LuatVietnam và đăng ký sử dụng Phần mềm tra cứu văn bản.

Báo lỗi
  • Báo lỗi
  • Gửi liên kết tới Email
  • Chia sẻ:
  • Chế độ xem: Sáng | Tối
  • Thay đổi cỡ chữ:
    17
Ghi chú

Tiêu chuẩn Việt Nam TCVN 8709-3:2011

Tiêu chuẩn Quốc gia TCVN 8709-3:2011 ISO/IEC 15408-3:2008 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
Số hiệu:TCVN 8709-3:2011Loại văn bản:Tiêu chuẩn Việt Nam
Cơ quan ban hành: Bộ Khoa học và Công nghệLĩnh vực: Khoa học-Công nghệ, Thông tin-Truyền thông
Năm ban hành:2011Hiệu lực:
Người ký:Tình trạng hiệu lực:
Đã biết

Vui lòng đăng nhập tài khoản gói Tiêu chuẩn hoặc Nâng cao để xem Tình trạng hiệu lực. Nếu chưa có tài khoản Quý khách đăng ký tại đây!

Tình trạng hiệu lực: Đã biết
Ghi chú
Ghi chú: Thêm ghi chú cá nhân cho văn bản bạn đang xem.
Hiệu lực: Đã biết
Tình trạng: Đã biết

TIÊU CHUẨN QUỐC GIA

TCVN 8709-3:2011

ISO/IEC 15408-3:2008

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

Information Technology - Security Techniques - Evaluation Criteria for IT Security - Part 3: Security assurance components

Lời nói đầu

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

TCVN 8709-3: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

Các thành phần đảm bảo an toàn như định nghĩa trong tiêu chuẩn này của TCVN 8709 là cơ sở cho các yêu cầu đảm bảo an toàn được biểu thị trong một Hồ sơ bảo vệ (PP) hoặc một Đích An toàn (ST).

Các yêu cầu này tạo thành một cách thức chuẩn để biểu thị các yêu cầu đảm bảo cho một Đích đánh giá (TOE). Phần này của tiêu chuẩn TCVN 8709 liệt kê danh mục các thành phần, các họ và lớp đảm bảo. Tiêu chuẩn TCVN 8709-3 cũng đồng thời xác định các tiêu chí đánh giá cho các PP và các ST, biểu thị các mức đảm bảo đánh giá dùng để xác định các thang bậc mà TCVN 8709 định trước cho việc đánh giá tính đảm bảo của các T, còn lại là các Mức đảm bảo đánh giá (EAL).

Đối tượng của tiêu chuẩn này bao gồm các khách hàng, nhà phát triển và đánh giá viên cho các sản phẩm công nghệ thông tin (CNTT) an toàn. Tiêu chuẩn TCVN 8709-1 cung cấp thông tin bổ sung về các đối tượng mục tiêu của bộ tiêu chuẩn TCVN 8709, và về khả năng các nhóm đối tượng sử dụng TCVN 8709. Các nhóm này có thể gồm:

a) Các khách hàng, sử dụng phần này của TCVN 8709 khi chọn lựa các thành phần để biểu thị các yêu cầu đảm bảo nhằm thỏa mãn các mục tiêu an toàn đã biểu thị trong một PP hoặc ST, xác định các mức đảm bảo an toàn cho TOE theo yêu cầu.

b) Nhà phát triển, phản ánh lại thực tế hoặc nhận thức được các yêu cầu an toàn của khách hàng để thiết kế TOE, tham chiếu phần này của TCVN 8709 để diễn đạt các yêu cầu đảm bảo và xác định các phương thức đảm bảo cho các TOE.

c) Đánh giá viên, sử dụng các yêu cầu đảm bảo định nghĩa trong phần này của TCVN 8709 như một tuyên bố bắt buộc về các tiêu chí đánh giá khi xác định tính đảm bảo của các TOE và khi đánh giá các PP và các ST.

 

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

Information Technology - Security Techniques - Evaluation Criteria for IT Security - Part 3: Security assurance components

1. Phạm vi áp dụng

Tiêu chuẩn này định nghĩa các yêu cầu đảm bảo cho bộ tiêu chuẩn. Tiêu chuẩn này gồm các mức đảm bảo đánh giá (EAL) dùng để xác định một cấp độ đo lường đảm bảo cho các TOE thành phần; các gói đảm bảo tổng hợp (CAP) dùng để xác định một cấp độ đo lường mức đảm bảo cho các TOE tổng hợp; các thành phần đảm bảo riêng biệt dùng cho việc tổng hợp các mức đảm bảo và các gói, và các tiêu chí đánh giá cho các PP và ST.

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-1, “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”.

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”.

3. Thuật ngữ, định nghĩa, ký hiệu và các từ viết tắt

Các thuật ngữ, định nghĩa, ký hiệu và các từ viết tắt được nêu trong TCVN 8709-1.

4. Tổng quan

4.1. Bố cục của tiêu chuẩn

Điều 5 mô tả mô hình sử dụng trong các yêu cầu đảm bảo an toàn thuộc phần này của TCVN 8709.

Điều 6 mô tả cấu trúc trình bày của các lớp, họ, thành phần, các mức đảm bảo đánh giá trong mối quan hệ giữa chúng và cấu trúc của các gói đảm bảo tổng hợp, nêu đặc trưng các lớp và họ đảm bảo dùng trong các điều từ 9 đến điều 16.

Điều 7 cung cấp các định nghĩa chi tiết về các mức bảo đảm đánh giá (EAL).

Điều 8 cung cấp các định nghĩa chi tiết về các gói đảm bảo tổng hợp (CAP).

Điều 9 đến điều 16 cung cấp các định nghĩa chi tiết các lớp đảm bảo của tiêu chuẩn TCVN 8709-3.

Phụ lục A giải thích thêm và cung cấp các ví dụ về các khái niệm bên trong lớp phát triển.

Phụ lục B giải thích các khái niệm bên trong các đánh giá cho TOE tổng hợp và các lớp tổng hợp.

Phụ lục C tóm lược các liên thuộc giữa các thành phần đảm bảo.

Phụ lục D cung cấp một bảng tham chiếu chéo giữa các hồ sơ bảo vệ (PP) và các họ cũng như các thành phần của lớp APE.

Phụ lục E cung cấp một bảng tham chiếu chéo giữa các mức đảm bảo đánh giá (EAL) và các thành phần đảm bảo.

Phụ lục F cung cấp một bảng tham chiếu chéo giữa các gói đảm bảo tổng hợp (CAP) và các thành phần đảm bảo.

5. Mô hình đảm bảo

Mục đích của điều này là trình bày triết lý nền tảng của TCVN 8709 trong việc đảm bảo. Hiểu được điều này, độc giả sẽ hiểu được sở cứ của các yêu cầu đảm bảo trong TCVN 8709-3.

5.1. Triết lý của TCVN 8709

Triết lý TCVN 8709 thể hiện ở chỗ các nguy cơ mất an toàn và xâm hại cam kết chính sách an toàn của tổ chức cần được thể hiện rõ ràng và các biện pháp an toàn đã đề xuất cần biểu thị đầy đủ các mục đích dự kiến của chúng.

Mặt khác, các biện pháp cần được chọn để giảm thiểu khả năng điểm yếu, khả năng sử dụng một điểm yếu (ví dụ cố ý lợi dụng hoặc vô ý gây ra), và phạm vi thiệt hại có thể xảy ra từ việc một điểm yếu bị sử dụng. Ngoài ra, các biện pháp cần được chọn sao cho thuận tiện việc nhận diện tiếp tục các điểm yếu và giảm bớt, hạn chế và/hoặc thông báo về việc một điểm yếu đã bị lợi dụng hoặc bị khai thác.

5.2. Tiếp cận đảm bảo

Triết lý của bộ tiêu chuẩn là cung cấp sự đảm bảo dựa trên một phép đánh giá (kiểm tra một cách tích cực) sản phẩm CNTT để có thể đưa ra tính tin cậy. Đánh giá là phương thức truyền thống để bảo đảm và là cơ sở cho các tài liệu tiêu chí đánh giá trước đó. Tương tự với các phương thức đã có, TCVN 8709 kế thừa triết lý trước đó. TCVN 8709 đưa ra định mức giá trị pháp lý của văn bản và các sản phẩm CNTT bởi các chuyên gia đánh giá với mức nhấn mạnh tăng dần về phạm vi, mức chuyên sâu và tính chặt chẽ.

TCVN 8709 không loại trừ và cũng không diễn giải các đặc điểm liên quan của các phương thức đảm bảo khác. Nghiên cứu của TCVN 8709 tiếp tục theo hướng tìm các đường khác nhau để đạt được sự bảo đảm. Kết quả là những phương thức khác đạt được từ các hoạt động nghiên cứu sẽ được xem xét đưa vào TCVN 8709, và tiêu chuẩn này được cấu trúc để cho phép cập nhật thêm các phương thức mới.

5.2.1. Tầm quan trọng của các điểm yếu

Giả thiết rằng có các tác nhân đe dọa đang tích cực tìm kiếm cơ hội khai thác để xâm phạm các chính sách an toàn kể cả theo ý tốt và ý xấu, song đều là các hành động không an toàn. Các tác nhân đe dọa này có thể ngẫu nhiên lôi ra các điểm yếu an toàn, gây hại cho tổ chức. Do nhu cầu xử lý các thông tin nhạy cảm và do thiếu các sản phẩm đủ tin cậy, luôn tồn tại rủi ro do lỗi của CNTT. Nghĩa là, các lỗ hỗng an toàn CNTT có thể dẫn đến mất mát đáng kể.

Các lỗ hổng an toàn CNTT xuất hiện thông qua việc khai thác có chủ ý hoặc vô tình làm phát sinh các điểm yếu khi ứng dụng CNTT vào hoạt động liên quan.

Cần có các bước thực hiện nhằm chống lại các điểm yếu phát sinh trong các sản phẩm CNTT. Trong các bước này, các điểm yếu cần được:

a) loại bỏ - nghĩa là cần có các bước thực hiện tích cực nhằm vạch rõ, xóa bỏ hoặc vô hiệu hóa mọi điểm yếu có tác dụng;

b) giảm thiểu - nghĩa là cần có các bước thực hiện tích cực nhằm giảm bớt, đến một mức độ chấp nhận được, ảnh hưởng có thể khi một điểm yếu bất kỳ được khai thác;

c) theo dõi - nghĩa là cần có các bước thực hiện tích cực nhằm đảm bảo mọi cố gắng khai thác một điểm yếu hiện hữu sẽ bị phát hiện và thiệt hại gây ra bị hạn chế;

5.2.2. Nguyên nhân của các điểm yếu

Các điểm yếu có thể nảy sinh qua các lỗi trong:

a) các yêu cầu - nghĩa là, một sản phẩm CNTT có thể có mọi chức năng và đặc trưng theo yêu cầu đối với chúng, song luôn chứa các điểm yếu thể hiện chúng không phù hợp hoặc không hiệu quả về góc độ an toàn;

b) phát triển - nghĩa là, một sản phẩm CNTT không đáp ứng các đặc tả và các điểm yếu nảy sinh là kết quả của các chuẩn phát triển không đủ hoặc lựa chọn thiết kế không phù hợp;

c) khai thác - nghĩa là, một sản phẩm CNTT đã được thiết kế phù hợp cho đặc tả đúng song các điểm yếu có thể nảy sinh là kết quả của việc kiểm soát hoạt động không phù hợp.

5.2.3. Đảm bảo trong bộ TCVN 8709

Đảm bảo là cơ sở cho tính tin cậy mà một sản phẩm CNTT cần thỏa mãn các mục tiêu an toàn của chúng. Đảm bảo có thể nhận được từ tham chiếu tới các nguồn như các xác nhận không có minh chứng, kinh nghiệm liên quan trước đó, hoặc kinh nghiệm xác định nào đó. Tuy nhiên, TCVN 8709 cung cấp sự đảm bảo thông qua điều tra tích cực. Điều tra tích cực là một cách đánh giá các sản phẩm CNTT nhằm xác định các đặc tính an toàn của chúng.

5.2.4. Đảm bảo thông qua đánh giá

Đánh giá là phương thức truyền thống để đạt được sự đảm bảo, và là cơ sở của phương pháp TCVN 8709. Các kỹ thuật đánh giá có thể bao gồm song không hạn chế các nội dung sau:

a) Phân tích và kiểm tra các tiến trình và các thủ tục;

b) Kiểm tra hiện trạng áp dụng các tiến trình và các thủ tục;

c) Phân tích tính tương hợp giữa các mô tả thiết kế TOE;

d) Phân tích mô tả thiết kế TOE so với các yêu cầu;

e) Kiểm tra các bằng chứng;

f) Phân tích các tài liệu hướng dẫn;

g) Phân tích các phép đo kiểm tra chức năng đã thiết lập và các kết quả đạt được;

h) Kiểm thử chức năng độc lập;

i) Phân tích các điểm yếu (bao gồm các giả thiết về khiếm khuyết);

j) Kiểm thử độ thẩm thấu;

5.3. Cấp độ đảm bảo đánh giá của bộ TCVN 8709

Triết lý của TCVN 8709 xác nhận rằng khi có nhiều nỗ lực đánh giá hơn thì sẽ đạt được các kết quả bảo đảm hơn, đích đặt ra là áp dụng nỗ lực tối thiểu theo yêu cầu để đưa ra mức độ đảm bảo cần thiết. Mức độ tăng dần các nỗ lực dựa vào:

a) Phạm vi - nghĩa là nỗ lực nhiều hơn do một phần lớn hơn của sản phẩm CNTT được xem xét;

b) Chuyên sâu - nghĩa là nỗ lực nhiều hơn do cần triển khai một mức thiết kế và triển khai chi tiết hơn;

c) Chặt chẽ - nghĩa là nỗ lực nhiều hơn do phải áp dụng theo một phương thức bắt buộc có cấu trúc hơn.

6. Các thành phần đảm bảo an toàn

6.1. Cấu trúc các lớp, họ và thành phần đảm bảo an toàn

Các điều khoản con sau đây mô tả các kết cấu sử dụng để biểu thị các lớp, thành phần và các họ đảm bảo.

Hình 1 trình bày các yêu cầu đảm bảo (SAR) được xác định trong tiêu chuẩn này (TCVN 8709-3). Lưu ý rằng tập hợp trừu tượng nhất của các yêu cầu đảm bảo SAR được coi là một lớp. Mỗi lớp chứa các họ đảm bảo, mỗi họ lại chứa các thành phần đảm bảo, còn thành phần thì chứa các phần tử đảm bảo. Các lớp và các họ được dùng để cung cấp một tập hợp phân loại các yêu cầu đảm bảo, còn các thành phần dùng để đặc tả các yêu cầu đảm bảo SAR trong một PP/ST.

6.1.1. Cấu trúc lớp đảm bảo

Hình 1 biểu diễn cấu trúc lớp đảm bảo.

6.1.1.1. Tên lớp

Mỗi lớp đảm bảo được gán một tên duy nhất. Tên biểu thị các chủ đề nêu trong lớp đảm bảo.

Một dạng viết tắt thống nhất cho tên lớp đảm bảo cũng được cung cấp. Đây là phương thức cơ bản để tham chiếu tới lớp đảm bảo. Quy ước đặt ra là một chữ “A” nối tiếp bởi 2 chữ cái biểu thị tên lớp.

6.1.1.2. Giới thiệu lớp

Mỗi lớp đảm bảo có một điều khoản nhỏ giới thiệu nhằm mô tả tập hợp của lớp và chứa thông tin hỗ trợ về mục đích của lớp.

6.1.1.3. Các họ đảm bảo

Mỗi lớp đảm bảo chứa ít nhất một họ đảm bảo. Cấu trúc của các họ đảm bảo được mô tả trong điều khoản sau đây.

Các yêu cầu đảm bảo theo tiêu chí chung

Hình 1 - Phân cấp lớp/họ/thành phần/phần tử đảm bảo

6.1.2. Cấu trúc họ đảm bảo

Hình 1 mô tả cấu trúc họ đảm bảo.

6.1.2.1. Tên họ

Mỗi họ đảm bảo được gán một tên duy nhất. Tên cung cấp thông tin mô tả về các chủ đề nêu trong họ đảm bảo. Mỗi họ đảm bảo được đặt trong lớp đảm bảo có chứa các họ khác với cùng mục đích.

Một dạng viết tắt thống nhất cho tên họ đảm bảo cũng được cung cấp. Đây là phương thức cơ bản để tham chiếu tới họ đảm bảo. Quy ước đặt ra là sử dụng dạng viết tắt của tên lớp nối tiếp bởi một gạch dưới, tiếp đó là 3 chữ cái biểu thị tên họ.

6.1.2.2. Các mục tiêu

Điều khoản các mục tiêu của họ đảm bảo biểu thị mục đích của họ đảm bảo.

Điều khoản này mô tả các mục tiêu, cụ thể là các mục tiêu liên quan trong mô hình đảm bảo của TCVN 8709 mà họ này sẽ đề cập đến. Việc mô tả cho một họ đảm bảo được duy trì ở một mức tổng quát. Mọi chi tiết đặc trưng theo yêu cầu của các mục tiêu được kết hợp trong một thành phần đảm bảo riêng.

6.1.2.3. Phân mức thành phần

Mỗi họ đảm bảo chứa một hoặc nhiều thành phần đảm bảo. Điều khoản này của họ đảm bảo mô tả các thành phần sẵn có và giải thích sự khác biệt giữa chúng. Mục đích chính của chúng là nhằm phân biệt giữa các thành phần đảm bảo một khi đã xác định rằng họ đảm bảo là một phần hữu ích và cần thiết cho các yêu cầu đảm bảo (SAR) của một PP/ST.

Các họ đảm bảo chứa nhiều hơn một thành phần được phân mức và sở cứ được cung cấp về việc phân mức các thành phần như thế nào. Sở cứ này gồm phạm vi, chiều sâu và/hoặc tính chặt chẽ.

6.1.2.4. Chú thích ứng dụng

Điều khoản về chú thích ứng dụng của họ đảm bảo, nếu có, sẽ chứa thông tin bổ trợ thêm cho họ đảm bảo. Thông tin này cần thể hiện sự quan tâm cụ thể cho những người sử dụng họ đảm bảo (ví dụ các chủ thể PP hoặc ST, các nhà thiết kế TOE, những đánh giá viên). Việc biểu diễn thông tin là không bắt buộc và bao gồm, ví dụ như các cảnh báo về giới hạn và phạm vi sử dụng, trong đó cần có những lưu ý đặc biệt.

6.1.2.5. Các thành phần đảm bảo

Mỗi họ đảm bảo có ít nhất một thành phần đảm bảo. Cấu trúc của các thành phần đảm bảo được cung cấp ở điều khoản con sau đây.

6.1.3. Cấu trúc thành phần đảm bảo

Hình 2 biểu diễn cấu trúc thành phần đảm bảo

Hình 2 - Cấu trúc thành phần đảm bảo

Mối quan hệ giữa các thành phần trong một họ được nhấn mạnh qua quy ước viết đậm. Các phần này của các yêu cầu là mới, cải tiến hoặc hiệu chỉnh theo các yêu cầu của thành phần trước đó trong phân lớp cấu trúc đã nhấn mạnh.

6.1.3.1. Định danh thành phần

Điều khoản định danh thành phần cung cấp các thông tin mô tả cần thiết để định danh, phân nhóm, đăng ký và tham chiếu cho một thành phần.

Mỗi thành phần đảm bảo được gán một tên duy nhất. Tên cung cấp thông tin mô tả về các chủ đề nêu trong thành phần đảm bảo. Mỗi thành phần đảm bảo được đặt trong họ đảm bảo có chia sẻ mục tiêu an toàn của chúng.

Một dạng viết tắt thống nhất cho tên thành phần đảm bảo cũng được cung cấp. Đây là phương thức cơ bản để tham chiếu tới thành phần đảm bảo. Quy ước đặt ra là sử dụng dạng viết tắt của tên họ nối tiếp bởi một thời kỳ và tiếp đó là một ký tự số. Các ký tự số cho các thành phần bên trong một họ được gán tuần tự, bắt đầu từ 1.

6.1.3.2. Các mục tiêu

Điều khoản các mục tiêu của thành phần đảm bảo, nếu có, sẽ chứa các mục tiêu đặc trưng cho thành phần đảm bảo cụ thể. Đối với các thành phần đảm bảo có điều khoản con này, điều khoản sẽ biểu thị mục đích đặc trưng của thành phần và giải thích chi tiết về các mục tiêu.

6.1.3.3. Chú thích ứng dụng

Điều khoản về chú thích ứng dụng của thành phần đảm bảo, nếu có, sẽ chứa thông tin bổ trợ thêm cho phép sử dụng thành phần.

6.1.3.4. Các mối phụ thuộc

Các mối phụ thuộc giữa các thành phần đảm bảo nảy sinh khi một thành phần không tự nó tồn tại mà phải dựa trên sự hiện diện của thành phần khác.

Mỗi thành phần đảm bảo cung cấp một danh sách đầy đủ các mối phụ thuộc với các thành phần đảm bảo khác. Một vài thành phần có thể liệt kê “không phụ thuộc” để chỉ ra sự không phụ thuộc. Các thành phần phụ thuộc nêu trên có thể có các mối phụ thuộc trong các thành phần khác.

Danh sách phụ thuộc xác định ra tập tối thiểu các thành phần đảm bảo mà chúng dựa vào. Các thành phần được phân cấp theo thành phần trong danh sách phụ thuộc có thể được dùng để thỏa mãn tính phụ thuộc.

Trong một số trường hợp đặc biệt, tính phụ thuộc đã biểu thị có thể không áp dụng được. Chủ thể PP/ST có thể tùy chọn không thỏa mãn tính phụ thuộc này thông qua việc cung cấp sở cứ tại sao các mối phụ thuộc đã cho không áp dụng được.

6.1.3.5. Các thành phần đảm bảo

Một tập các thành phần đảm bảo được cung cấp cho mỗi thành phần đảm bảo. Một phần tử đảm bảo là một yêu cầu an toàn và nếu tiếp tục chia nhỏ, sẽ không cho một kết quả đánh giá có nghĩa. Đó là yêu cầu an toàn nhỏ nhất chấp nhận được trong TCVN 8709.

Mỗi thành phần đảm bảo được xác định là thuộc một trong 3 tập các phần tử đảm bảo sau đây:

a) Phần tử hành động của nhà phát triển: Là các hành động cần được thực thi bởi nhà phát triển. Tập các hành động này tiếp tục được nêu rõ trong tài liệu chứng cứ được tham chiếu trong tập các phần tử sau đây. Các yêu cầu cho các hành động của nhà phát triển được xác định bởi việc thêm chữ cái “D” vào số hiệu phân tử.

b) Nội dung và biểu diễn của các phần tử chứng cứ: là chứng cứ yêu cầu, nghĩa là chứng cứ cần biểu thị gì, thông tin nào cần có trong chứng cứ. Các yêu cầu về nội dung và biểu diễn chứng cứ được xác định bởi việc thêm chữ cái “C” vào số hiệu phần tử.

c) Các phần tử hành động của đánh giá viên: Là các hành động cần được thực thi bởi đánh giá viên. Tập các hành động chứa sự khẳng định rõ ràng về sự thỏa mãn các yêu cầu đã mô tả trước đó trong Các phần tử nội dung và trình bày. Nó cũng chứa các hành động và phân tích rõ ràng cần thực hiện bổ sung thêm cho những gì nhà phát triển đã làm. Các hành động đánh giá ngầm định cũng được thực hiện như là kết quả của các phần tử hành động của nhà phát triển do các hành động này không chứa trong nội dung và biểu diễn của các phần tử chứng cứ. Các yêu cầu về hành động của đánh giá viên được xác định bởi việc thêm chữ cái “E” vào số hiệu phần tử.

Các hành động của nhà phát triển, nội dung và biểu diễn chứng cứ xác định các yêu cầu đảm bảo được dùng để biểu thị trách nhiệm của nhà phát triển trong việc biểu diễn sự đảm bảo khi đích đánh giá (TOE) thỏa mãn các yêu cầu đảm bảo cho một PP hoặc một ST.

Các hành động của đánh giá viên xác định trách nhiệm của đánh giá viên ở 2 khía cạnh đánh giá. Khía cạnh thứ nhất là tính hợp lệ của PP/ST, trong tương quan với các lớp APE và ASE trong các điều khoản APE: Đánh giá hồ sơ bảo vệ và ASE: Đánh giá đích an toàn. Khía cạnh thứ 2 là kiểm chứng tính tuân thủ của các TOE với các yêu cầu chức năng (SFR) và yêu cầu đảm bảo (SAR) của chúng. Qua việc biểu thị PP/ST hợp lệ và các yêu cầu thỏa mãn bởi TOE, đánh giá viên có thể cung cấp một cơ sở tin cậy rằng TOE giải quyết vấn đề bảo mật đã được đặt ra trong môi trường xử lý của nó.

Phần tử hành động của nhà phát triển, Các phần tử nội dung và trình bày, và các phần tử hành động rõ ràng của đánh giá viên sẽ xác định nỗ lực của đánh giá viên cần sử dụng để kiểm chứng các đòi hỏi an toàn tạo ra trong ST của TOE.

6.1.4. Các phần tử đảm bảo

Mỗi phần tử biểu thị một yêu cầu cần thỏa mãn. Các công bố yêu cầu này cần rõ ràng, chính xác và không mập mờ. Bởi vậy, chúng không có các câu phức hợp: mỗi yêu cầu riêng biệt được công bố là một phần tử riêng.

6.1.5. Danh mục các thành phần

Trong phần này của TCVN 8709 chứa các lớp của các họ và các thành phần, chúng được phân nhóm dựa trên cơ sở của các đảm bảo liên quan. Tại điểm bắt đầu của mỗi lớp là một đồ thị thông tin về các họ trong lớp và các thành phần trong mỗi họ.

Hình 3 - Ví dụ về sơ đồ phân cấp lớp

Trong hình 3 ở trên, lớp được thể hiện với một họ duy nhất. Họ này chứa 3 thành phần theo kiến trúc tuyến tính (nghĩa là thành phần 2 đòi hỏi nhiều hơn thành phần 1 với các biểu thức về hành động đặc trưng, chứng cứ đặc trưng, hoặc tính chặt chẽ của các hành động hoặc chứng cứ). Các họ đảm bảo trong phần này của TCVN 8709 đều thuộc phân lớp tuyến tính, mặc dù tính tuyến tính không phải là tiêu chí bắt buộc cho các họ đảm bảo có thể bổ sung thêm trong tương lai.

6.2. Cấu trúc EAL

Hình 4 trình bày các EAL và cấu trúc liên quan định nghĩa trong tiêu chuẩn này. Lưu ý rằng trong khi hình chỉ ra các nội dung của các thành phần đảm bảo, thông tin này dự kiến sẽ đưa vào trong một EAL qua tham chiếu tới các thành phần thực tế được định nghĩa trong TCVN 8709.

Các mức đảm bảo Phần 3

Hình 4 - Cấu trúc EAL

6.2.1. Tên EAL

Mỗi EAL được gán một tên duy nhất. Tên cung cấp thông tin mô tả về nội dung của EAL.

Một dạng viết tắt thống nhất cho tên EAL cũng được cung cấp. Đây là phương thức cơ bản để tham chiếu tới EAL.

6.2.2. Mục tiêu

Điều khoản mục tiêu của EAL biểu thị mục đích của EAL.

6.2.3. Chú thích ứng dụng

Điều khoản về chú thích ứng dụng của EAL, nếu có, sẽ chứa thông tin thể hiện sự quan tâm cụ thể cho những người sử dụng EAL (ví dụ các chủ thể PP hoặc ST, các nhà thiết kế TOE với mục tiêu hướng tới EAL này, các đánh giá viên). Việc biểu diễn thông tin là không bắt buộc và bao gồm, ví dụ như các cảnh báo về giới hạn và phạm vi sử dụng, trong đó cần có những lưu ý đặc biệt.

6.2.4. Các thành phần đảm bảo

Một tập các thành phần đảm bảo đã được chọn cho mỗi EAL.

Một mức cao của đảm bảo hơn mức được cung cấp bởi một EAL cho trước có thể đạt được qua:

a) chứa các thành phần đảm bảo bổ sung từ các họ đảm bảo khác hoặc

b) thay thế một thành phần đảm bảo với một thành phần đảm bảo mức cao hơn từ cùng một họ đảm bảo.

6.2.5. Mối quan hệ giữa đảm bảo và các mức đảm bảo

Hình 5 trình bày mối quan hệ giữa các yêu cầu đảm bảo (SAR) và các mức đảm bảo xác định trong TCVN 8709. Trong khi các thành phần đảm bảo tiếp tục phân tách ra thành các phần tử đảm bảo, các phần tử đảm bảo không thể tham chiếu riêng biệt bởi các mức đảm bảo. Lưu ý rằng mũi tên ở trong hình biểu thị tham chiếu từ một EAL đến một thành phần đảm bảo bên trong lớp nơi nó được xác định.

Hình 5 - Quan hệ giữa đảm bảo và mức đảm bảo

6.3. Cấu trúc CAP

Cấu trúc của gói đảm bảo tổng hợp (CAP) tương tự như của các mức đảm bảo đánh giá (EAL). Khác nhau chính giữa chúng là kiểu của đích đánh giá (TOE) mà chúng áp dụng; các EAL áp dụng cho thành phần của TOE còn CAP áp dụng cho các đích đánh giá tổng hợp.

Hình 6 trình bày các gói đảm bảo tổng hợp (CAP) và cấu trúc kết hợp được định nghĩa trong TCVN 8709-3. Lưu ý rằng trong khi hình chỉ ra các nội dung của các thành phần đảm bảo, thông tin này dự kiến sẽ đưa vào trong một CAP qua tham chiếu tới các thành phần thực tế định nghĩa trong TCVN 8709.

Hình 6 - Cấu trúc CAP

6.3.1. Tên CAP

Mỗi CAP được gán một tên duy nhất. Tên cung cấp thông tin mô tả về nội dung của CAP.

Một dạng viết tắt thống nhất cho tên CAP cũng được cung cấp. Đây là phương thức cơ bản để tham chiếu tới CAP.

6.3.2. Mục tiêu

Điều khoản mục tiêu của CAP biểu thị mục đích của CAP.

6.3.3. Chú thích ứng dụng

Điều khoản về chú thích ứng dụng của CAP, nếu có, sẽ chứa thông tin thể hiện sự quan tâm cụ thể cho những người sử dụng CAP (ví dụ các chủ thể PP hoặc ST, những người hợp nhất các TOE tổng hợp với mục tiêu hướng tới CAP này, các đánh giá viên). Việc biểu diễn thông tin là không bắt buộc và bao gồm, ví dụ như các cảnh báo về giới hạn và phạm vi sử dụng, trong đó cần có những lưu ý đặc biệt.

6.3.4. Các thành phần đảm bảo

Một tập các thành phần đảm bảo đã được chọn cho mỗi CAP.

Một vài các mối phụ thuộc nhận dạng các hoạt động diễn ra trong khi đánh giá các thành phần phụ thuộc dựa vào hoạt động của TOE tổng hợp. Nếu không nhận dạng rõ ràng được các mối phụ thuộc trong hoạt động của thành phần phụ thuộc thì các mối phụ thuộc sẽ là một cách đánh giá khác của TOE tổng hợp.

Một mức cao của đảm bảo hơn mức được cung cấp bởi CAP cho trước có thể đạt được qua:

a) chứa các thành phần đảm bảo bổ sung từ các họ đảm bảo khác hoặc

b) thay thế một thành phần đảm bảo với một thành phần đảm bảo mức cao hơn từ cùng một họ đảm bảo.

Các thành phần kết cấu trong các gói đảm bảo CAP không nên sử dụng làm phần mở rộng cho các đánh giá thành phần TOE vì nó có thể cung cấp sự đảm bảo không đầy đủ cho những thành phần đó.

6.3.5. Mối quan hệ giữa đảm bảo và các mức đảm bảo

Hình 7 trình bày mối quan hệ giữa các yêu cầu đảm bảo (SAR) và các gói đảm bảo tổng hợp định nghĩa trong TCVN 8709. Trong khi các thành phần đảm bảo tiếp tục phân tách ra thành các phần tử đảm bảo, các phần tử đảm bảo không thể tham chiếu riêng biệt bởi các gói đảm bảo. Lưu ý rằng mũi tên ở trong hình biểu thị tham chiếu từ CAP đến một thành phần đảm bảo bên trong lớp nơi nó được xác định.

Hình 7 - Quan hệ giữa đảm bảo và gói đảm bảo tổng hợp

7. Các mức đảm bảo đánh giá

Các mức đảm bảo đánh giá (EAL) cung cấp một thang bậc tăng dần có cân bằng giữa mức độ đảm bảo đạt được với chi phí và tính khả thi đạt được cấp độ đảm bảo đó. TCVN 8709 xác định các khái niệm khác nhau về đảm bảo trong TOE ở cuối của phần đánh giá, và duy trì sự đảm bảo đó trong quá trình sử dụng TOE.

Chú ý quan trọng rằng không phải tất cả các họ (families) và các thành phần (components) trong phần này của TCVN 8709 được bao gồm trong EAL. Điều này không phải nói rằng nó không cung cấp các đảm bảo có ý nghĩa và mong muốn. Thay vào đó được mong đợi rằng các họ và thành phần này sẽ xem xét thêm vào EAL trong các PP và ST

7.1. Tổng quan về các mức đảm bảo đánh giá (EAL)

Bảng 1 trình bày một tổng kết của EAL. Các cột thể hiện một tập các EAL sắp xếp từ 1 đến 7, các dòng thể hiện các họ đảm bảo. Mỗi một số trong ma trận xác định một thành phần đảm bảo cụ thể có thể áp dụng được.

Như đã nêu ở phần sau, 7 cấp đảm bảo đánh giá được định nghĩa phân lớp trong TCVN 8709 nhằm đánh giá mức độ đảm bảo cho một TOE. Mức đảm bảo tăng lên từ EAL này đến EAL khác được thực hiện bởi việc thay thế một thành phần đảm bảo có cấp cao hơn từ cùng một họ đảm bảo (ví dụ tăng về tính chuẩn xác, phạm vi và/hoặc độ sâu) và từ việc thêm vào các thành phần đảm bảo từ các họ đảm bảo khác (ví dụ như thêm các yêu cầu mới).

Các EAL bao gồm một tổ hợp thích hợp các thành phần đảm bảo như được miêu tả trong phần 6 của TCVN 8709-3. Một cách chính xác hơn, mỗi EAL bao gồm không hơn một thành phần của mỗi họ bảo đảm và tất cả sự lệ thuộc đảm bảo của mỗi thành phần được xác định.

EAL được định nghĩa trong TCVN 8709, nó có thể được thể hiện bằng tổ hợp khác của sự đảm bảo. Đặc biệt, khái niệm “sự mở rộng” (augumentation) cho phép thêm vào các thành phần đảm bảo (từ họ đảm bảo không sẵn sàng trong EAL) hoặc thay thế thành phần đảm bảo (bằng một thành phần đảm bảo có cấp cao hơn trong cùng một họ đảm bảo) trong một EAL. Xây dựng nên sự đảm bảo được định nghĩa trong TCVN 8709, thì chỉ EAL có thể được mở rộng. Thuật ngữ “EAL trừ đi một thành phần đảm bảo” không được công nhận bởi chuẩn này. Khả năng mở rộng cho phép điều chỉnh tính hữu ích và thêm giá trị vào thành phần đảm bảo mở rộng trong EAL. Một EAL có thể cũng được mở rộng với các yêu cầu đảm bảo rõ ràng.

Bảng 1 - Tóm tắt các cấp đảm bảo đánh giá

Lớp đảm bảo

Họ đảm bảo

Các thành phần đảm bảo theo các mức đảm bảo đánh giá (EAL)

EAL1

EAL2

EAL3

EAL4

EAL5

EAL6

EAL7

Phát triển

ADV_ARC

 

1

1

1

1

1

1

ADV_FSP

1

2

3

4

5

5

6

ADV_IMP

 

 

 

1

1

2

2

ADV_INT

 

 

 

 

2

3

3

ADV_SPM

 

 

 

 

 

1

1

ADV_TDS

 

1

2

3

4

5

6

Tài liệu hướng dẫn

AGD_OPE

1

1

1

1

1

1

1

AGD_PRE

1

1

1

1

1

1

1

Hỗ trợ vòng đời

ALC_CMC

1

2

3

4

4

5

5

ALC_CMS

1

2

3

4

5

5

5

ALC_DEL

 

1

1

1

1

1

1

ALC_DVS

 

 

1

1

1

2

2

ALC_FLR

 

 

 

 

 

 

 

ALC_LCD

 

 

1

1

1

1

2

ALC_TAT

 

 

 

1

2

3

3

Đánh giá đích an toàn

ASE_CCL

1

1

1

1

1

1

1

ASE_ECD

1

1

1

1

1

1

1

ASE_INT

1

1

1

1

1

1

1

ASE_OBJ

1

2

2

2

2

2

2

ASE_REQ

1

2

2

2

2

2

2

ASE_SPD

 

1

1

1

1

1

1

ASE_TSS

1

1

1

1

1

1

1

Kiểm thử

ATE_COV

 

1

2

2

2

3

3

ATE_DPT

 

 

1

2

3

3

4

ATE_FUN

 

1

1

1

1

2

2

ATE_IND

1

2

2

2

2

2

3

Đánh giá điểm yếu

AVA_VAN

1

2

2

3

4

5

5

7.2. Chi tiết cho mức đảm bảo đánh giá

Các phần sau trình bày các định nghĩa của EAL, nêu rõ sự khác nhau giữa các yêu cầu cụ thể với các diễn tả văn xuôi của các yêu cầu đó sử dụng kiểu tô đậm.

7.3. Mức đảm bảo đánh giá mức 1 (EAL1) - Kiểm thử chức năng

7.3.1. Mục tiêu

EAL1 có thể áp dụng nơi mà tính bí mật trong hoạt động chính xác được yêu cầu, nhưng nguy cơ an toàn không được xem là quan trọng. Nó sẽ có giá trị khi sự bảo đảm độc lập được đòi hỏi để hỗ trợ luận điểm đã được áp dụng đối với sự bảo vệ thông tin cá nhân hoặc thông tin tương tự.

EAL1 chỉ đòi hỏi một đích an toàn giới hạn. Đơn giản chỉ là tuyên bố các yêu cầu chức năng an toàn (SFR) mà đích đánh giá (TOE) phải đáp ứng chứ không cần phải diễn giải xuất xứ của chúng xuất phát từ các nguy cơ đe dọa.

EAL1 đưa ra một đánh giá cho TOE đáp ứng cho khách hàng, bao gồm cả kiểm thử độc lập với một bảng mô tả đặc tính, và cung cấp một văn bản kiểm tra tài liệu hướng dẫn. Ý đồ hướng đến là đánh giá EAL1 có thể được thực hiện một cách thành công mà không cần sự trợ giúp của nhà phát triển TOE, và với chi phí nhỏ nhất.

Một đánh giá ở mức này có thể cung cấp bằng chứng về các chức năng TOE phù hợp với tài liệu của nó.

7.3.2. Các thành phần đảm bảo

EAL1 đưa ra một mức đảm bảo cơ bản bởi một đích an toàn giới hạn và sự phân tích các yêu cầu chức năng an toàn (SFR) trong đó ST sử dụng một đặc tả chức năng và giao diện kèm theo tài liệu hướng dẫn để diễn tả hoạt động an toàn.

Sự phân tích được hỗ trợ bởi việc tìm kiếm những điểm yếu tiềm năng thông báo công khai và kiểm tra độc lập các chức năng cũng như sự thâm nhập của các chức năng an toàn TOE (các TSF).

EAL1 cung cấp sự đảm bảo thông qua việc nhận dạng duy nhất cho TOE và tài liệu đánh giá liên quan.

EAL này có ý nghĩa hơn trong việc đảm bảo đối với một sản phẩm CNTT không được đánh giá.

Bảng 2 - EAL1

Lớp đảm bảo

Các thành phần đảm bảo

Phát triển: ADV

Đặc tả chức năng cơ bản (ADV_FSP.1)

Tài liệu hướng dẫn: AGD

Hướng dẫn người dùng vận hành (AGD_OPE.1)

Các thủ tục chuẩn bị (AGD_PRE.1)

Hỗ trợ vòng đời: ALC

Dán nhãn TOE (ALC_CMC.1)

Tổng quát TOE CM (ALC_CMS.1)

Đánh giá đích an toàn: ASE

Yêu cầu tuân thủ (ASE_CCL.1)

Định nghĩa các thành phần mở rộng (ASE_ECD.1)

Giới thiệu ST (ASE_INT.1)

Các mục tiêu an toàn cho môi trường vận hành (ASE_OBJ.1)

Các yêu cầu an toàn đã công bố (ASE_REQ.1)

Đặc tả tóm tắt TOE (ASE_TSS.1)

Kiểm thử: ATE

Kiểm thử độc lập - Tuân thủ (ATE_IND.1)

Đánh giá điểm yếu: AVA

Khảo sát điểm yếu (AVA_VAN.1)

7.4. Mức đảm bảo đánh giá 2 (EAL2) - Kiểm thử cấu trúc

7.4.1. Mục tiêu

EAL2 yêu cầu sự hợp tác của nhà phát triển dưới dạng thông tin thiết kế và các kết quả kiểm tra, nhưng không yêu cầu nhiều hơn về tính hiệu quả của các bộ phận phát triển so với tính phù hợp thực tế về thương mại. Như vậy đó không yêu cầu một sự gia tăng về đầu tư chi phí và thời gian.

EAL2 vì vậy có thể áp dụng trong các trường hợp nhà phát triển và người sử dụng yêu cầu một mức thấp đến trung bình về đảm bảo an toàn một cách độc lập khi thiếu hồ sơ phát triển đầy đủ. Một tình huống như vậy có thể xảy ra khi đảm bảo cho các hệ thống kế thừa, hoặc ở nơi truy nhập đến nhà phát triển có thể bị giới hạn.

7.4.2. Các thành phần đảm bảo

EAL2 cung cấp sự đảm bảo bằng một đích an toàn đầy đủ và thông qua phân tích các đòi hỏi chức năng an toàn (SFR) của ST, sử dụng một đặc tả chức năng và giao diện, tài liệu hướng dẫn và các mô tả cơ sở về kiến trúc của TOE để hiểu hành vi an toàn.

Sự phân tích được hỗ trợ bằng việc kiểm tra độc lập các chức năng an toàn TOE, bằng chứng về việc kiểm tra của nhà phát triển dựa trên đặc tính chức năng, sự xác nhận độc lập có chọn lọc các kết quả kiểm tra của nhà phát triển, phân tích những điểm yếu (dựa trên các đặc tính chức năng, thiết kế TOE, mô tả kiến trúc an toàn và bằng chứng hướng dẫn được cung cấp) để thể hiện khả năng phản ứng trước một xâm nhập của kẻ tấn công với một tiền lực tấn công cơ sở.

EAL2 cũng như cung cấp sự đảm bảo thông qua hệ thống quản lý cấu hình và bằng chứng của các thủ tục chuyển giao an toàn.

EAL này thể hiện sự đảm bảo có ý nghĩa hơn so với EAL1 bằng việc yêu cầu kiểm tra của nhà phát triển, phân tích lỗ hổng, (ngoài ra tìm kiếm thông tin công cộng) và kiểm tra độc lập dựa trên đặc tả TOE chi tiết hơn.

Bảng 3 - EAL2

Lớp đảm bảo

Các thành phần đảm bảo

Phát triển: ADV

Đặc tả kiến trúc an toàn (ADV_ARC.1)

Đặc tả chức năng bắt buộc an toàn (ADV_FSP.2)

Thiết kế cơ bản (ADV_TDS.1)

Tài liệu hướng dẫn: AGD

Hướng dẫn người dùng vận hành (AGD_OPE.1)

Các thủ tục chuẩn bị (AGD_PRE.1)

Hỗ trợ vòng đời: ALC

Sử dụng một hệ thống CM (ALC_CMC.2)

Các phần tổng quát TOE CM (ALC_CMS.2)

Các thủ tục chuyển giao (ALC_DEL.1)

Đánh giá đích an toàn: ASE

Yêu cầu tuân thủ (ASE_CCL.1)

Định nghĩa các thành phần mở rộng (ASE_ECD.1)

Giới thiệu ST (ASE_INT.1)

Các mục tiêu an toàn (ASE_OBJ.2)

Các yêu cầu an toàn thu được (ASE_REQ.2)

Định nghĩa vấn đề an toàn (ASE_SPD.1)

Đặc tả tóm tắt TOE (ASE_TSS.1)

Kiểm thử: ATE

Chứng cứ về tính tổng quát (ATE_COV.1)

Kiểm thử chức năng (ATE_FUN.1)

Kiểm thử độc lập - ví dụ (ATE_IND.2)

Đánh giá điểm yếu: AVA

Khảo sát điểm yếu (AVA_VAN.2)

7.5. Mức đảm bảo đánh giá 3 (EAL3) - Kiểm thử và kiểm tra phương pháp

7.5.1. Mục tiêu

EAL3 cho phép một nhà phát triển tận tâm đạt được sự đảm bảo tối đa với công nghệ an toàn tốt ở mức thiết kế mà không cần thay đổi các cơ chế phát triển đang có sẵn.

EAL3 có thể ứng dụng trong các tình huống mà nhà phát triển hoặc người sử dụng yêu cầu ở mức vừa phải về đảm bảo an toàn độc lập, và yêu cầu một sự điều tra tỉ mỉ về TOE và phát triển nó không cần bước thiết kế lại đáng kể nào.

7.5.2. Các thành phần đảm bảo

EAL3 cung cấp đảm bảo bởi một đích an toàn đầy đủ và phân tích các yêu cầu chức năng an toàn (SFR) của ST, sử dụng một đặc tả chức năng và giao diện, tài liệu hướng dẫn và các mô tả về kiến trúc thiết kế của TOE, để diễn giải hoạt động an toàn.

Sự phân tích được hỗ trợ bằng việc kiểm tra một cách độc lập các chức năng an toàn của TOE, chứng cứ về việc kiểm thử của nhà phát triển dựa trên đặc tả chức năng và thiết kế TOE, sự xác nhận độc lập có chọn lọc các kết quả kiểm tra của nhà phát triển, phân tích các lỗ hổng/điểm yếu (dựa trên các đặc tính chức năng, thiết kế TOE, mô tả kiến trúc an toàn và bằng chứng hướng dẫn được cung cấp) để thể hiện khả năng bảo vệ trước xâm nhập của kẻ tấn công với một tiềm lực tấn công cơ bản.

EAL3 cung cấp đảm bảo thông qua sử dụng các biện pháp quản lý môi trường phát triển, quản lý cấu hình TOE, và chứng cứ về các thủ tục chuyển giao an toàn.

EAL này thể hiện sự đảm bảo có ý nghĩa hơn so với EAL2 bằng việc đòi hỏi tổng quát việc kiểm thử hoàn thiện hơn về chức năng an toàn và cơ chế và/hoặc thủ tục nhằm đưa ra một sự tin cậy nào đó về việc TOE sẽ không bị giả mạo trong quá trình phát triển.

Bảng 4 - EAL3

Lớp đảm bảo

Các thành phần đảm bảo

Phát triển: ADV

Đặc tả kiến trúc an toàn (ADV_ARC.1)

Đặc tả chức năng với tóm tắt đầy đủ (ADV_FSP.3)

Thiết kế kiến trúc (ADV_TDS.2)

Tài liệu hướng dẫn: AGD

Hướng dẫn người dùng vận hành (AGD_OPE.1)

Các thủ tục chuẩn bị (AGD_PRE.1)

Hỗ trợ vòng đời: ALC

Các biện pháp quản lý cấp quyền (ALC_CMC.3)

Tổng quát CM biểu diễn triển khai (ALC_CMS.3)

Các thủ tục chuyển giao (ALC_DEL.1)

Định danh các biện pháp an toàn (ALC_DVS.1)

Mô hình vòng đời định nghĩa cho nhà phát triển (ALC_LCD.1)

Đánh giá đích an toàn: ASE

Yêu cầu tuân thủ (ASE_CCL.1)

Định nghĩa các thành phần mở rộng (ASE_ECD.1)

Giới thiệu ST (ASE_INT.1)

Các mục tiêu an toàn (ASE_OBJ.2)

Các yêu cầu an toàn thu được (ASE_REQ.2)

Định nghĩa vấn đề an toàn (ASE_SPD.1)

Đặc tả tóm tắt TOE (ASE_TSS.1)

Kiểm thử: ATE

Phân tích tổng quát (ATE_COV.2)

Kiểm thử: Thiết kế cơ bản (ATE_DPT.1)

Kiểm thử chức năng (ATE_FUN.1)

Kiểm thử độc lập - ví dụ (ATE_IND.2)

Đánh giá điểm yếu: AVA

Phân tích điểm yếu (AVA_VAN.2)

7.6. Mức đảm bảo đánh giá 4 (EAL4) - Thiết kế, kiểm thử, soát xét phương pháp

7.6.1. Mục tiêu

EAL4 cho phép một nhà phát triển đạt được sự đảm bảo tối đa về kỹ thuật an toàn tốt dựa trên các thực tế phát triển thương mại tốt, tuy chặt chẽ, song không yêu cầu kiến thức chuyên gia, kỹ năng, và các tài nguyên đáng kể nào khác. EAL4 là mức cao nhất khả thi về mặt kinh tế đưa vào một dòng sản phẩm đang tồn tại.

EAL4 vì vậy có thể ứng dụng trong các trường hợp mà ở đó các nhà phát triển và người sử dụng yêu cầu một mức từ trung bình đến cao đảm bảo an toàn độc lập trong TOE thông thường và được chuẩn bị để đưa vào các chi phí mở rộng công trình an toàn cụ thể.

7.6.2. Các thành phần đảm bảo

EAL4 cung cấp khả năng đảm bảo bởi một đích an toàn đầy đủ và sự phân tích các yêu cầu chức năng an toàn (SFR) của ST, sử dụng một đặc tả chức năng và giao diện, tài liệu hướng dẫn, mô tả về thiết kế mô-đun cơ bản của TOE và một tập triển khai, nhằm diễn giải hoạt động an toàn.

Sự phân tích được hỗ trợ bởi việc kiểm tra độc lập các chức năng an toàn TOE, chứng cứ về việc kiểm thử của nhà phát triển dựa trên đặc tả chức năng và thiết kế của TOE, sự khẳng định độc lập có lựa chọn về các kết quả kiểm thử của nhà phát triển, phân tích các lỗ hổng/điểm yếu (dựa trên các đặc tính chức năng, thiết kế TOE, trình diễn thực thi, thiết kế kiến trúc và bằng chứng hướng dẫn được cung cấp) để thể hiện khả năng bảo vệ trước xâm nhập của kẻ tấn công với một tiềm lực tấn công trên mức cơ bản.

EAL4 cũng cung cấp đảm bảo thông qua sử dụng các biện pháp quản lý môi trường phát triển và quản lý cấu hình TOE mở rộng bao gồm tự động hóa và bằng chứng về các thủ tục chuyển giao an toàn.

EAL này thể hiện sự đảm bảo hơn EAL3 bằng việc yêu cầu mô tả thiết kế tỉ mỉ hơn, trình diễn thực thi cho toàn bộ các chức năng an toàn TOE và cơ chế cải thiện và/hoặc các thủ tục nhằm đưa ra sự tin cậy rằng TOE sẽ không bị giả mạo trong quá trình phát triển.

Bảng 5 - EAL4

Lớp đảm bảo

Các thành phần đảm bảo

Phát triển: ADV

Đặc tả kiến trúc an toàn (ADV_ARC.1)

Đặc tả chức năng đầy đủ (ADV_FSP.4)

Mô tả triển khai TSF (ADV_IMP.1)

Thiết kế kiến trúc cơ sở (ADV_TDS.3)

Tài liệu hướng dẫn: AGD

Hướng dẫn người dùng vận hành (AGD_OPE.1)

Các thủ tục chuẩn bị (AGD_PRE.1)

Hỗ trợ vòng đời: ALC

Tự động hóa, các thủ tục chấp nhận và hỗ trợ sản xuất (ALC_CMC.4)

Tổng quan CM theo dấu vết vấn đề (ALC_CMS.4)

Các thủ tục chuyển giao (ALC_DEL.1)

Định danh các biện pháp an toàn (ALC_DVS.1)

Mô hình vòng đời định nghĩa cho nhà phát triển (ALC_LCD.1)

Các công cụ phát triển xác định rõ (ALC_TAT.1)

Đánh giá đích an toàn: ASE

Yêu cầu tuân thủ (ASE_CCL.1)

Định nghĩa các thành phần mở rộng (ASE_ECD.1)

Giới thiệu ST (ASE_INT.1)

Các mục tiêu an toàn (ASE_OBJ.2)

Các yêu cầu an toàn thu được (ASE_REQ.2)

Định nghĩa vấn đề an toàn (ASE_SPD.1)

Đặc tả tóm tắt TOE (ASE_TSS.1)

Kiểm thử: ATE

Phân tích tổng quát (ATE_COV.2)

Kiểm thử: Các mô đun bắt buộc an toàn (ATE_DPT.2)

Kiểm thử chức năng (ATE_FUN.1)

Kiểm thử độc lập - ví dụ (ATE_IND.2)

Đánh giá điểm yếu: AVA

Phân tích điểm yếu trọng tâm (AVA_VAN.3)

7.7. Mức đảm bảo đánh giá 5 (EAL5) - Thiết kế và kiểm thử bán chính thức

7.7.1. Mục tiêu

EAL5 cho phép một nhà phát triển đạt được đảm bảo tối đa với kỹ thuật an toàn dựa trên thực tế sự phát triển thương mại nghiêm ngặt hỗ trợ bởi việc ứng dụng ở mức trung bình các kỹ thuật an toàn đặc biệt. Như vậy một TOE sẽ có thể được thiết kế và phát triển với mục đích đạt được đảm bảo EAL5. Nó tương tự như các chi phí mở rộng đưa vào các yêu cầu EAL5, liên quan đến sự phát triển nghiêm ngặt không ứng dụng các kỹ thuật đặc biệt.

EAL5 vì vậy có khả năng ứng dụng trong các trường hợp mà ở đó nhà phát triển và người sử dụng yêu cầu ở mức cao đảm bảo an toàn độc lập trong sự phát triển đã được kế hoạch và đòi hỏi một nghiên cứu phát triển nghiêm ngặt không chịu các chi phí có thể quy cho các kỹ thuật an toàn đặc biệt.

7.7.2. Các thành phần đảm bảo

EAL5 cung cấp khả năng đảm bảo bằng một đích an toàn đầy đủ và việc phân tích các đòi hỏi chức năng an toàn (SFR) của ST, sử dụng một đặc tả chức năng và giao diện, tài liệu hướng dẫn, mô tả thiết kế của TOE, và ứng dụng, để hiểu hành vi an toàn. Như vậy đòi hỏi TSF thiết kế theo mô-đun.

Sự phân tích được hỗ trợ bởi việc kiểm tra độc lập các chức năng an toàn TOE, bằng chứng kiểm tra nhà phát triển dựa trên các đặc tả chức năng, thiết kế TOE, sự khẳng định độc lập có lựa chọn các kết quả kiểm tra nhà phát triển, và một sự phân tích lỗ hổng độc lập thể hiện sự phản ứng đối với các xâm nhập của kẻ tấn công với một khả năng tấn công mức vừa phải.

EAL5 cũng cung cấp khả năng đảm bảo thông qua sử dụng các kiểm soát môi trường phát triển, và quản lý cấu hình TOE tổng thể bao gồm thông tin và bằng chứng của các thủ tục chuyển giao an toàn.

EAL này thể hiện sự đảm bảo hơn EAL4 bằng việc yêu cầu mô tả thiết kế bán chính thức, kiến trúc có cấu trúc hơn (và từ đây có thể phân tích) và cơ chế cải thiện và/hoặc các thủ tục mà nó cung cấp sự chắc chắn mà TOE sẽ không bị ảnh hưởng trong quá trình phát triển.

Bảng 6 - EAL5

Lớp đảm bảo

Các thành phần đảm bảo

Phát triển: ADV

Đặc tả kiến trúc an toàn (ADV_ARC.1)

Đặc tả chức năng đầy đủ bán chính thức với thông tin lỗ bổ sung (ADV_FSP.5)

Mô tả triển khai TSF (ADV_IMP.1)

Thiết kế mô đun bán chính thức (ADV_TDS.4)

Tài liệu hướng dẫn: AGD

Hướng dẫn người dùng vận hành (AGD_OPE.1)

Các thủ tục chuẩn bị (AGD_PRE.1)

Hỗ trợ vòng đời: ALC

Tự động hóa, các thủ tục chấp nhận và hỗ trợ sản xuất (ALC_CMC.4)

Tổng quan CM các công cụ phát triển (ALC_CMS.5)

Các thủ tục chuyển giao (ALC_DEL.1)

Định danh các biện pháp an toàn (ALC_DVS.1)

Mô hình vòng đời định nghĩa cho nhà phát triển (ALC_LCD.1)

Tuân thủ với các tiêu chuẩn triển khai (ALC_TAT.2)

Đánh giá đích an toàn: ASE

Yêu cầu tuân thủ (ASE_CCL.1)

Định nghĩa các thành phần mở rộng (ASE_ECD.1)

Giới thiệu ST (ASE_INT.1)

Các mục tiêu an toàn (ASE_OBJ.2)

Các yêu cầu an toàn thu được (ASE_REQ.2)

Định nghĩa vấn đề an toàn (ASE_SPD.1)

Đặc tả tóm tắt TOE (ASE_TSS.1)

Kiểm thử: ATE

Phân tích tổng quát (ATE_COV.2)

Kiểm thử: Thiết kế mô đun (ATE_DPT.3)

Kiểm thử chức năng (ATE_FUN.1)

Kiểm thử độc lập - ví dụ (ATE_IND.2)

Đánh giá điểm yếu: AVA

Phân tích điểm yếu theo phương pháp (AVA_VAN.4)

7.8. Mức đảm bảo đánh giá 6 (EAL6) - Xác minh thiết kế và kiểm thử bán chính thức

7.8.1. Mục tiêu

EAL6 cho phép nhà phát triển đạt tới độ đảm bảo cao từ việc ứng dụng các kỹ thuật an toàn đối với môi trường phát triển nghiêm ngặt để đưa ra TOE cho việc bảo vệ dữ liệu có giá trị cao trước các rủi ro.

EAL6 vì vậy có thể ứng dụng để phát triển TOE cho ứng dụng có độ rủi ro cao mà ở đó giá trị của tài sản bảo vệ điều chỉnh theo chi phí phát sinh.

7.8.2. Các thành phần đảm bảo

EAL6 cung cấp khả năng đảm bảo bởi một đích an toàn đầy đủ và sự phân tích các yêu cầu chức năng an toàn (SFR) của ST, sử dụng đặc tả chức năng và giao diện tổng thể, tài liệu hướng dẫn, thiết kế của TOE, và triển khai, nhằm diễn giải hoạt động an toàn. Ngoài ra, đảm bảo còn đạt được thông qua một mô hình chính thức về lựa chọn các chính sách an toàn TOE và một thể hiện bán chính thức của các đặc tả chức năng, thiết kế TOE. Điều đó đòi hỏi thiết kế TOE theo mô-đun và phân lớp.

Sự phân tích được hỗ trợ bởi việc kiểm tra độc lập các chức năng an toàn TOE, bằng chứng về việc kiểm thử của nhà phát triển dựa trên đặc tả chức năng, thiết kế TOE, sự xác nhận độc lập có lựa chọn về các kết quả kiểm thử của nhà phát triển, và một sự phân tích lỗ hổng độc lập thể hiện bảo vệ trước xâm nhập của kẻ tấn công với một khả năng tấn công mức cao.

EAL6 cũng cung cấp khả năng đảm bảo thông qua sử dụng một quy trình phát triển có cấu trúc, các biện pháp quản lý môi trường phát triển, và quản lý cấu hình TOE tổng thể bao gồm thông tin và bằng chứng của các thủ tục chuyển giao an toàn.

EAL này đưa ra một sự đảm bảo có ý nghĩa hơn so với EAL5 bằng việc yêu cầu phân tích toàn diện hơn, thể hiện ứng dụng có cấu trúc, kiến trúc có cấu trúc hơn (ví dụ phân lớp), sự phân tích lỗ hổng độc lập toàn diện hơn, cải thiện quản lý cấu hình và kiểm soát môi trường phát triển.

Bảng 7 - EAL6

Lớp đảm bảo

Các thành phần đảm bảo

Phát triển: ADV

Đặc tả kiến trúc an toàn (ADV_ARC.1)

Đặc tả chức năng đầy đủ bán chính thức với thông tin lỗi bổ sung (ADV_FSP.5)

Ánh xạ đầy đủ mô tả triển khai TSF (ADV_IMP.2)

Nội bộ tổ hợp tối thiểu (ADV_INT.3)

Mô hình chính sách an toàn TOE chính thức (ADV_SPM.1)

Thiết kế mô đun đầy đủ bán chính thức (ADV_TDS.5)

Tài liệu hướng dẫn: AGD

Hướng dẫn người dùng vận hành (AGD_OPE.1)

Các thủ tục chuẩn bị (AGD_PRE.1)

Hỗ trợ vòng đời: ALC

Hỗ trợ cải tiến (ALC_CMC.5)

Tổng quan CM các công cụ phát triển (ALC_CMS.5)

Các thủ tục chuyển giao (ALC_DEL.1)

Sự đầy đủ của các biện pháp an toàn (ALC_DVS.2)

Mô hình vòng đời định nghĩa cho nhà phát triển (ALC_LCD.1)

Tuân thủ với các tiêu chuẩn triển khai - tất cả các phần (ALC_TAT.3)

Đánh giá đích an toàn: ASE

Yêu cầu tuân thủ (ASE_CCL.1)

Định nghĩa các thành phần mở rộng (ASE_ECD.1)

Giới thiệu ST (ASE_INT.1)

Các mục tiêu an toàn (ASE_OBJ.2)

Các yêu cầu an toàn thu được (ASE_REQ.2)

Định nghĩa vấn đề an toàn (ASE_SPD.1)

Đặc tả tóm tắt TOE (ASE_TSS.1)

Kiểm thử: ATE

Phân tích tổng quát nghiêm ngặt (ATE_COV.3)

Kiểm thử: Thiết kế mô đun (ATE_DPT.3)

Kiểm thử chức năng theo thứ tự (ATE_FUN.2)

Kiểm thử độc lập - ví dụ (ATE_IND.2)

Đánh giá điểm yếu: AVA

Phân tích điểm yếu theo phương pháp cải tiến (AVA_VAN.5)

7.9. Mức đảm bảo đánh giá 7 (EAL7) - Xác minh thiết kế và kiểm thử chính thức

7.9.1. Mục tiêu

EAL7 được ứng dụng để phát triển TOE cho ứng dụng có độ rủi ro rất cao hoặc ở đó tài sản có giá trị cao điều chỉnh chi phí lớn hơn. Ứng dụng thực tế của EAL7 hiện nay giới hạn cho TOE tập trung vào chức năng an toàn tuân theo phân tích chính thức mở rộng.

7.9.2. Các thành phần đảm bảo

EAL7 cung cấp khả năng đảm bảo bởi một đích an toàn đầy đủ và sự phân tích các yêu cầu chức năng an toàn (SFRs) của ST, sử dụng đặc tả chức năng và giao diện tổng thể, tài liệu hướng dẫn, thiết kế TOE, và một thể hiện triển khai có cấu trúc, nhằm diễn giải hoạt động an toàn. Ngoài ra, đảm bảo còn đạt được thông qua một mô hình chính thức về chọn lựa các chính sách an toàn TOE, và một thể hiện bán chính thức các đặc tả chức năng và thiết kế TOE. Điều đó đòi hỏi thiết kế TSF có tính mô-đun, đơn giản và có phân lớp.

Sự phân tích được hỗ trợ bởi việc kiểm thử độc lập các chức năng an toàn TOE, bằng chứng về việc kiểm thử của nhà phát triển dựa trên đặc tả chức năng, thiết kế TOE và thể hiện triển khai, xác nhận độc lập có lựa chọn về các kết quả kiểm tra của nhà phát triển, một phân tích lỗ hổng độc lập thể hiện sự bảo vệ trước xâm nhập của kẻ tấn công với một khả năng tấn công mức cao.

EAL7 cũng cung cấp khả năng đảm bảo thông qua sử dụng một quy trình phát triển có cấu trúc, các biện pháp quản lý môi trường phát triển, quản lý cấu hình TOE tổng thể bao gồm tự động hóa đầy đủ và bằng chứng về các thủ tục chuyển giao an toàn.

EAL này đưa ra một sự đảm bảo có ý nghĩa hơn so với EAL6 bằng việc yêu cầu phân tích toàn diện hơn, sử dụng các thể hiện chính thức, phù hợp chính thức và kiểm thử toàn diện.

Bảng 8 - EAL7

Lớp đảm bảo

Các thành phần đảm bảo

Phát triển: ADV

Đặc tả kiến trúc an toàn (ADV_ARC.1)

Đặc tả chức năng đầy đủ bán chính thức với đặc tả chính thức bổ sung (ADV_FSP.6)

Ánh xạ đầy đủ mô tả triển khai TSF (ADV_IMP.2)

Nội bộ tổ hợp tối thiểu (ADV_INT.3)

Mô hình chính sách an toàn TOE chính thức (ADV_SPM.1)

Thiết kế mô đun đầy đủ bán chính thức với thể hiện thiết kế mức cao (ADV_TDS.6)

Tài liệu hướng dẫn: AGD

Hướng dẫn người dùng vận hành (AGD_OPE.1)

Các thủ tục chuẩn bị (AGD_PRE.1)

Hỗ trợ vòng đời: ALC

Hỗ trợ cải tiến (ALC_CMC.5)

Tổng quan CM các công cụ phát triển (ALC_CMS.5)

Các thủ tục chuyển giao (ALC_DEL.1)

Sự đầy đủ của các biện pháp an toàn (ALC_DVS.2)

Mô hình vòng đời định mức được (ALC_LCD.2)

Tuân thủ với các tiêu chuẩn triển khai - tất cả các phần (ALC_TAT.3)

Đánh giá đích an toàn: ASE

Yêu cầu tuân thủ (ASE_CCL.1)

Định nghĩa các thành phần mở rộng (ASE_ECD.1)

Giới thiệu ST (ASE_INT.1)

Các mục tiêu an toàn (ASE_OBJ.2)

Các yêu cầu an toàn thu được (ASE_REQ.2)

Định nghĩa vấn đề an toàn (ASE_SPD.1)

Đặc tả tóm tắt TOE (ASE_TSS.1)

Kiểm thử: ATE

Phân tích tổng quát nghiêm ngặt (ATE_COV.3)

Kiểm thử: Biểu diễn triển khai (ATE_DPT.4)

Kiểm thử chức năng theo thứ tự (ATE_FUN.2)

Kiểm thử độc lập - đầy đủ (ATE_IND.3)

Đánh giá điểm yếu: AVA

Phân tích điểm yếu theo phương pháp cải tiến (AVA_VAN.5)

8. Các gói đảm bảo tổng hợp

Các gói đảm bảo tổng hợp (CAP) cung cấp một thang đo tăng dần để cân bằng mức độ đảm bảo đạt được với giá thành và sự khả thi có thể đạt được mà mức độ đảm bảo cho TOE tổng hợp.

Điểm quan trọng cần chú ý là chỉ có một số lượng nhỏ các họ và thành phần trong phần này của ISO 15408 được chứa trong CAP. Đây là tính tất yếu của việc xây dựng dựa trên các kết quả đánh giá các thực thể được đánh giá trước đó (dựa trên các thành phần và các thành phần phụ thuộc), điều này không nói lên rằng chúng không cung cấp các đảm bảo được mong muốn và đầy đủ ý nghĩa.

8.1. Tổng quan về gói đảm bảo tổng hợp (CAP)

CAP có thể được sử dụng để đưa ra các TOE tổng hợp, bao gồm các thành phần mà đã hoặc sẽ được đánh giá TOE thành phần (xem Phụ lục B). Các thành phần riêng sẽ được chứng nhận EAL hoặc gói bảo đảm khác được chỉ ra trong ST. Với mong muốn, mức độ cơ bản của bảo đảm trong TOE thành phần sẽ đạt được thông qua áp dụng các EAL1, mà có thể đạt được với các thông tin về thành phần thường có sẵn trong một miền chung. (EAL1 có thể được áp dụng như được chỉ ra trong cả TOE tổng hợp và thành phần). CAP cung cấp một cách tiếp cận khác để đạt được cấp độ cao hơn bảo đảm cho TOE thành phần hơn việc áp dụng các EAL trên EAL1.

Khi một thành phần phụ thuộc có thể được đánh giá bằng cách sử dụng các đánh giá và chứng nhận trước đó để thỏa mãn đòi hỏi về nền tảng CNTT trong môi trường, điều này không cung cấp bất kỳ sự bảo đảm chính thức của tương tác giữa các thành phần hoặc đưa ra các lỗ hổng có thể xảy ra thu được từ sự tổng hợp. Các gói đảm bảo tổng hợp xem xét các tương tác này, ở các mức đảm bảo cao hơn, đảm bảo rằng tương tác giữa các thành phần mà chính nó là mục tiêu để kiểm thử. Phân tích điểm yếu của TOE tổng hợp sẽ được thực hiện để xem xét việc đưa ra các điểm yếu như là kết quả của sự tổng hợp các thành phần.

Bảng 9 biểu diễn tóm tắt của các CAP. Các cột biểu diễn sự phân cấp có trật tự của các tập của các CAP, còn các hàng biểu diễn các họ đảm bảo. Mỗi số trong ma trận kết quả chỉ ra một thành phần đảm bảo tại các chỗ có thể áp dụng.

Như được nêu trong mục con tiếp theo, ba gói đảm bảo tổng hợp được phân cấp có trật tự được định nghĩa trong TCVN 8709 để xếp hạng mức độ đảm bảo của các TOE tổng hợp. Chúng được phân cấp theo trật tự để đảm bảo rằng mỗi biểu diễn CAP là chính xác hơn tất cả CAP thấp hơn.  Việc tăng mức độ đảm bảo từ CAP đến CAP được thực hiện bằng việc thay thế bằng thành phần đảm bảo có mức độ phân cấp cao hơn từ các họ đảm bảo tương tự (ví dụ tăng tính nghiêm ngặt, phạm vi và độ sâu) và từ việc bổ sung các thành phần đảm bảo từ các họ đảm bảo khác (ví dụ như thêm các đòi hỏi mới). Điều này làm việc phân tích lớn hơn với các tập hợp để chỉ ra tác động trong các kết quả đánh giá đạt được với TOE tổng hợp.

Các CAP bao gồm một sự phối hợp thích hợp của các thành phần đảm bảo như mô tả trong điều 6 trong phần TCVN 8709 này. Chính xác hơn, mỗi CAP chứa không nhiều hơn một thành phần của mỗi họ đảm bảo và tất cả các phụ thuộc đảm bảo trong mọi thành phần được đề cập đến.

Các CAP chỉ xem xét khả năng chống lại kẻ tấn công với khả năng tấn công lên trên mức cơ bản. Đây là do mức độ thông tin thiết kế được cung cấp bởi ACO_DEV, hạn chế một số yếu tố kết hợp với khả năng tấn công (hiểu biết về các thành phần cấu thành TOE) và sau đó ảnh hưởng đến sự chặt chẽ của phân tích điểm yếu được thực hiện bởi đánh giá viên. Vì vậy, mức độ đảm bảo trong TOE tổng hợp sẽ bị giới hạn, mặc dù vậy việc đảm bảo trong các thành phần riêng trong TOE tổng hợp cao hơn nhiều.

Bảng 9 - Tóm tắt mức đảm bảo tổng hợp

Lớp đảm bảo

Họ đảm bảo

Các thành phần đảm bảo từ Gói đảm bảo tổng hợp

CAP-A

CAP-B

CAP-C

Tổng hợp

ACO_COR

1

1

1

ACO_CTT

1

2

2

ACO_DEV

1

2

3

ACO_REL

1

1

2

ACO_VUL

1

2

3

Tài liệu hướng dẫn

AGD_OPE

1

1

1

AGD_PRE

1

1

1

Hỗ trợ vòng đời

ACL_CMC

1

1

1

ACL_CMS

2

2

2

ACL_DEL

 

 

 

ACL_DVS

 

 

 

ACL_FLR

 

 

 

ACL_LCD

 

 

 

ACL_TAT

 

 

 

Đánh giá đích an toàn

ASE_CCL

1

1

1

ASE_ECD

1

1

1

ASE_INT

1

1

1

ASE_OBJ

1

2

2

ASE_REQ

1

2

2

ASE_SPD

 

1

1

ASE_TSS

1

1

1

8.2. Chi tiết về gói đảm bảo tổng hợp

Các điều khoản sau đây sẽ cung cấp các định nghĩa của các CAP, phần khác nhau giữa các yêu cầu riêng và các đặc trưng thường của các yêu cầu này sử dụng chữ in đậm.

8.3. Mức đảm bảo tổng hợp A (CAP-A) - Tổng hợp theo cấu trúc

8.3.1. Mục tiêu

CAP-A được áp dụng khi TOE tổng hợp được tích hợp và tin cậy với hoạt động an toàn thực hiện đúng theo tổng hợp kết quả được yêu cầu. Điều này đòi hỏi sự hợp tác của nhà phát triển của thành phần phụ thuộc về việc cung cấp thông tin thiết kế và kết quả kiểm tra từ việc chứng nhận các thành phần phụ thuộc, mà không đòi hỏi sự tham gia của nhà phát triển thành phần cơ sở.

CAP-A do đó áp dụng trong các trường hợp này, nơi các nhà phát triển hoặc người dùng yêu cầu một mức thấp đến trung bình mức độ an toàn được đảm bảo một cách độc lập trong trường hợp không sẵn có toàn bộ bản ghi phát triển.

8.3.2. Các thành phần đảm bảo

CAP-A cung cấp đảm bảo thông qua phân tích đích an toàn cho TOE tổng hợp. Các SFR trong ST của TOE tổng hợp được phân tích bằng cách sử dụng kết quả đầu ra từ đánh giá của các TOE thành phần (ví dụ ST, tài liệu hướng dẫn) và đặc tả cho các giao diện giữa các TOE thành phần trong TOE tổng hợp để hiểu về hành vi an toàn.

Phân tích này được hỗ trợ bằng cách kiểm tra độc lập của các giao diện của các thành phần cơ sở dựa trên thành phần phụ thuộc, như được mô tả trong thông tin tin cậy, bằng chứng về nhà phát triển các phép thử dựa trên thông tin tin cậy, thông tin phát triển và các sở cứ tổng hợp, và lựa chọn xác nhận độc lập có chọn lọc các kết quả kiểm tra của nhà phát triển. Phân tích này cũng được hỗ trợ bởi việc xem xét lại điểm yếu trong TOE tổng hợp bởi đánh giá viên.

CAP-A cũng cung cấp bảo đảm thông qua nhận dạng duy nhất của TOE tổng hợp (ví dụ TOE CNTT và tài liệu hướng dẫn).

Bảng 10 - CAP - A

Lớp đảm bảo

Các thành phần đảm bảo

ACO: Tổng hợp

ACO_COR.1 Sở cứ tổng hợp

ACO_CTT.1 Kiểm thử giao diện

ACO_DEV.1: Mô tả chức năng

ACO_REL.1: Thông tin tin cậy cơ sở

ACO_VUL.1: Soát xét các điểm yếu tổng hợp

AGD: Tài liệu hướng dẫn

AGD_OPE.1 Hướng dẫn người dùng vận hành

AGD_PRE.1 Các thủ tục chuẩn bị

ALC: Hỗ trợ vòng đời

ACL_CMC.1 Gắn nhãn cho TOE

ACL_CMS.2: Các thành phần của TOE CM tổng quát

Đánh giá các đích an toàn

ASE_CCL.1 Các yêu cầu tuân thủ

ASE_ECD.1 Định nghĩa các thành phần mở rộng

ASE_INT.1: Giới thiệu ST

ASE_OBJ.1: Các mục tiêu an toàn cho môi trường vận hành

ASE_REQ.1: Các yêu cầu an toàn đã xác nhận

ASE_TSS.1: Đặc tả tổng quát TOE

8.4. Mức đảm bảo tổng hợp B (CAP-B) - Tổng hợp theo phương pháp

8.4.1. Mục tiêu

CAP-B cho phép nhà phát triển đạt được đảm bảo tối đa từ sự hiểu biết, tại mức hệ thống con, các ảnh hưởng của tương tác giữa các TOE thành phần được tích hợp trong các TOE tổng hợp, trong khi giảm thiểu nhu cầu về sự tham gia của các nhà phát triển thành phần cơ sở.

CAP-B được áp dụng trong các trường hợp này, nơi các nhà phát triển hay người dùng đòi hỏi một mức độ vừa phải về an toàn được đảm bảo độc lập, và yêu cầu một cuộc điều tra kỹ lưỡng về TOE tổng hợp và sự phát triển của nó mà không có kỹ thuật quan trọng.

8.4.2. Các thành phần đảm bảo

CAP-B cung cấp đảm bảo bằng phân tích một đích an toàn đầy đủ cho TOE tổng hợp. Các SFR trong ST của TOE tổng hợp sẽ được phân tích bằng cách sử dụng kết quả đầu ra từ đánh giá của các TOE thành phần (ví dụ như ST, tài liệu hướng dẫn), đặc tả cho các giao diện giữa các TOE thành phần và thiết kế TOE (mô tả hệ thống con TSF) chứa trong thông tin phát triển tổng hợp để hiểu về các hành vi an toàn.

Phân tích này được hỗ trợ bằng cách kiểm tra độc lập của các giao diện của thành phần cơ sở được dựa trên các thành phần phụ thuộc, như mô tả trong thông tin tin cậy (bây giờ cũng bao gồm thiết kế TOE), bằng chứng kiểm thử phát triển dựa trên thông tin tin cậy, thông tin phát triển và sở cứ tạo ra, xác nhận độc lập có chọn lọc kết quả kiểm thử của nhà phát triển. Phân tích cũng được hỗ trợ bởi một phân tích điểm yếu trong TOE tổng hợp bởi đánh giá viên chứng minh khả năng chống kẻ tấn công với các khả năng tấn công.

CAP biểu diễn sự gia tăng có ý nghĩa trong sự bảo đảm từ CAP-A bằng cách yêu cầu vùng bao phủ đầy đủ của các chức năng an toàn.

Bảng 11 - CAP - B

Lớp đảm bảo

Các thành phần đảm bảo

ACO: Tổng hợp

ACO_COR.1 Sở cứ tổng hợp

ACO_CTT.2 Kiểm thử giao diện nghiêm ngặt

ACO_DEV.2: Mô tả chứng cứ cơ sở

ACO_REL.1: Thông tin tin cậy cơ sở

ACO_VUL.2: Soát xét các điểm yếu thành phần

AGD: Tài liệu hướng dẫn

AGD_OPE.1 Hướng dẫn người dùng vận hành

AGD_PRE.1 Các thủ tục chuẩn bị

ALC: Hỗ trợ vòng đời

ACL_CMC.1 Gắn nhãn cho TOE

ACL_CMS.2: Các phần của TOE CM tổng quát

Đánh giá các đích an toàn

ASE_CCL.1 Các yêu cầu tuân thủ

ASE_ECD.1 Định nghĩa các thành phần mở rộng

ASE_INT.1: Giới thiệu ST

ASE_OBJ.2: Các mục tiêu an toàn

ASE_REQ.2: Các yêu cầu an toàn được cung cấp

ASE_SPD.1 Định nghĩa các vấn đề an toàn

ASE_TSS.1: Đặc tả tổng quát TOE

8.5. Mức đảm bảo tổng hợp C (CAP-C) - Tổng quát theo phương pháp, kiểm tra và soát xét.

8.5.1. Mục tiêu

CAP-C cho phép nhà phát triển đạt được mức đảm bảo cao nhất từ việc phân tích chủ động sự tương tác giữa các thành phần của TOE tổng hợp, mà không đòi hỏi phải truy cập đầy đủ đến tất cả các chứng cứ đánh giá của thành phần cơ sở.

CAP-C do đó áp dụng trong các trường hợp này, nơi các nhà phát triển hoặc người sử dụng đòi hỏi phải có mức độ an toàn độc lập được đảm bảo ở mức trung bình đến cao trong TOE tổng hợp thông thường truyền thống và được chuẩn bị để phải chịu thêm chi phí liên quan đến vấn đề an toàn đặc trưng.

8.5.2. Các thành phần đảm bảo

CAP-C cung cấp đảm bảo bằng phân tích của một đích an toàn đầy đủ cho TOE tổng hợp. Các SFR trong ST của TOE tổng hợp được phân tích bằng cách sử dụng kết quả đầu ra thông qua đánh giá các TOE thành phần (ví dụ như ST, tài liệu hướng dẫn), đặc tả cho các giao diện giữa các TOE thành phần và thiết kế TOE (mô tả các mô đun TSF) được chứa trong thông tin phát triển tổng hợp để hiểu về hành vi an toàn.

Phân tích được hỗ trợ bằng cách kiểm tra độc lập của các giao diện của thành phần cơ sở được dựa trên thành phần phụ thuộc, như mô tả trong thông tin tin cậy (nay bao gồm cả thiết kế TOE), kiểm tra chứng cứ của nhà phát triển dựa trên thông tin tin cậy, thông tin phát triển và sở cứ tổng hợp và chọn lọc độc lập xác nhận kết quả kiểm thử của nhà phát triển. Phân tích này cũng được hỗ trợ với việc phân tích điểm yếu của TOE tổng hợp bởi đánh giá viên để chứng minh khả năng chống kẻ tấn công với khả năng tấn công trên mức cơ bản.

CAP này thể hiện sự gia tăng có ý nghĩa trong sự bảo đảm từ CAP-B bằng cách yêu cầu mô tả chi tiết thiết kế và thể hiện khả năng chống lại khả năng bị tấn công cao hơn.

Bảng 12 - CAP-C

Lớp đảm bảo

Các thành phần đảm bảo

ACO: Thành phần cấu tạo

ACO_COR.1 Sở cứ tổng hợp

ACO_CTT.2 Kiểm thử giao diện nghiêm ngặt

ACO_DEV.3: Chứng cứ chi tiết cho thiết kế

ACO_REL.2: Thông tin tin cậy

ACO_VUL.3: Phân tích điểm yếu tổng hợp mức cao hơn cơ bản

AGD: Tài liệu hướng dẫn

AGD_OPE.1 Hướng dẫn người dùng vận hành

AGD_PRE.1 Các thủ tục chuẩn bị

ALC: Hỗ trợ vòng đời

ACL_CMC.1 Gắn nhãn cho TOE

ACL_CMS.2 Các phần của TOE CM tổng quát

Đánh giá các đích an toàn

ASE_CCL.1 Các yêu cầu tuân thủ

ASE_ECD.1 Định nghĩa các thành phần mở rộng

ASE_INT.1: Giới thiệu ST

ASE_OBJ.2: Các mục tiêu an toàn

ASE_REQ.2: Các yêu cầu an toàn được cung cấp

ASE_SPD.1 Định nghĩa các vấn đề an toàn

ASE_TSS.1: Đặc tả tổng quát TOE

9. Lớp APE: Đánh giá hồ sơ bảo vệ

Đánh giá một PP được yêu cầu để chứng minh rằng PP là nhất quán và nếu là PP dựa trên một hoặc nhiều PP khác hoặc trong các gói, mà PP là một thể hiện đúng của các PP này và các gói. Các thuộc tính này là cần thiết cho PP cho phù hợp để sử dụng làm cơ sở để viết ST hay PP khác.

Mục này nên được sử dụng cùng với các Phụ lục A, B và C trong TCVN 8709-1, như các phụ lục để làm rõ các khái niệm ở đây và cung cấp nhiều ví dụ.

Hình 8 cho thấy các họ trong lớp này, và hệ thống phân cấp của các thành phần trong họ.

Hình 8 - Phân cấp lớp APE: Đánh giá Hồ sơ bảo vệ

9.1. Giới thiệu PP (APE_INT)

9.1.1. Mục tiêu

Mục tiêu của họ này là mô tả TOE theo một phạm vi hẹp.

Đánh giá giới thiệu PP được đòi hỏi để chứng minh rằng PP được xác định đúng và tham chiếu PP và tổng quan TOE là nhất quán với các thành phần khác.

9.1.2. APE_INT.1 Giới thiệu PP

Các mối phụ thuộc: không có sự phụ thuộc nào.

9.1.2.1. Phần tử hành động của nhà phát triển

9.1.2.1.1. APE_INT.1.1D

Nhà phát triển PP cần cung cấp giới thiệu PP

9.1.2.2. Các phần tử nội dung và trình bày

9.1.2.2.1. APE_INT.1.1C

Giới thiệu PP cần chứa tham chiếu PP và tổng quan TOE

9.1.2.2.2. APE_INT.1.2C

Tham chiếu PP cần là định danh duy nhất của PP

9.1.2.2.3. APE_INT.1.3C

Tổng quan TOE cần tóm tắt việc sử dụng và các đặc trưng an toàn chính của TOE

9.1.2.2.4. APE_INT.1.4C

Tổng quan TOE cần xác định kiểu TOE.

9.1.2.2.5. APE_INT_1.5C

Tổng quan TOE cần xác định bất kỳ phần cứng, phần mềm và phần sụn không phải TOE có trong TOE.

9.1.2.3. Các phần tử hành động của đánh giá viên

9.1.2.3.1. APE_INT.1.1E

Đánh giá viên cần khẳng định rằng thông tin cung cấp đáp ứng mọi yêu cầu về chứng cứ cho nội dung và trình bày.

9.2. Các yêu cầu tuân thủ (APE_CCL)

9.2.1. Mục tiêu

Mục tiêu của họ này là quyết định giá trị của các yêu cầu tuân thủ. Thêm vào đó, họ này chỉ ra làm sao mà ST và các PP khác được yêu cầu tuân thủ với PP.

9.2.2. APE_CCL.1 Các yêu cầu tuân thủ

Các phụ thuộc:

APE_INT.1 Giới thiệu PP

APE_ECD.1 Định nghĩa các thành phần mở rộng

APE_REQ.1 Nêu các yêu cầu an toàn.

9.2.2.1. Phần tử hành động của nhà phát triển

9.2.2.1.1. APE_CCL.1.1D

Nhà phát triển cần cung cấp yêu cầu tuân thủ

9.2.2.1.2. APE_CCL.1.2D

Nhà phát triển cần cung cấp sở cứ các yêu cầu tuân thủ

9.2.2.1.3. APE_CCL.1.3D

Nhà phát triển cần cung cấp các tuyên bố về tuân thủ

9.2.2.2. Các phần tử nội dung và trình bày

9.2.2.2.1. APE_CCL.1.1C

Các yêu cầu tuân thủ cần chứa yêu cầu tuân thủ TCVN 8709 mà xác định phiên bản của TCVN 8709 mà PP yêu cầu tuân thủ.

9.2.2.2.2. APE_CCL.1.2C

Các yêu cầu tuân thủ TCVN 8709 cần mô tả sự tuân thủ của PP theo TCVN 8709-2 cũng như là sự tuân thủ TCVN 8709-2 hoặc mở rộng của TCVN 8709-2.

9.2.2.2.3. APE_CCL.1.3C

Các yêu cầu tuân thủ TCVN 8709 cần mô tả sự tuân thủ của PP theo phần này của TCVN 8709 cũng như là sự tuân thủ phần này của TCVN 8709 hoặc phần này của phần mở rộng TCVN 8709.

9.2.2.2.4. APE_CCL.1.4C

Yêu cầu tuân thủ TCVN 8709 cần nhất quán với định nghĩa các thành phần mở rộng

9.2.2.2.5. APE_CCL.1.5C

Yêu cầu tuân thủ TCVN 8709 cần chỉ ra tất cả PP và các gói yêu cầu an toàn mà PP yêu cầu tuân thủ.

9.2.2.2.6. APE_CCL.1.6C

Yêu cầu tuân thủ cần mô tả bất kỳ sự tuân thủ nào của PP theo gói cũng như gói tuân thủ hay gói tăng cường khác.

9.2.2.2.7. APE_CCL.1.7C

Sở cứ cho yêu cầu tuân thủ về cần chứng minh rằng kiểu TOE này là nhất quán với kiểu TOE trong các PP mà sự tuân thủ đang được yêu cầu.

9.2.2.2.8. APE_CCL.1.8C

Sở cứ cho yêu cầu tuân thủ sẽ chứng minh rằng tuyên bố định nghĩa các vấn đề an toàn là nhất quán với tuyên bố về định nghĩa các vấn đề an toàn bên trong các PP mà sự tuân thủ đang được yêu cầu.

9.2.2.2.9. APE_CCL.1.9C

Sở cứ cho yêu cầu tuân thủ cần chứng minh rằng tuyên bố các mục tiêu an toàn là nhất quán với tuyên bố về định nghĩa các mục tiêu an toàn bên trong các PP mà sự tuân thủ đang được yêu cầu.

9.2.2.2.10. APE_CCL.1.10C

Sở cứ cho yêu cầu tuân thủ cần chứng minh rằng tuyên bố định nghĩa các yêu cầu an toàn là nhất quán với tuyên bố về định nghĩa các yêu cầu an toàn bên trong các PP mà sự tuân thủ đang được yêu cầu.

9.2.2.2.11. APE_CCL.1.11C

Tuyên bố tuân thủ cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày các chứng cứ.

9.2.2.3. Các phần tử hành động của đánh giá viên

9.2.2.3.1. APE_CCL.1.1E

Đánh giá viên cần khẳng định rằng thông tin cung cấp đáp ứng mọi yêu cầu về chứng cứ cho nội dung và trình bày.

9.3. Định nghĩa vấn đề an toàn (APE_SPD)

9.3.1. Mục tiêu

Phần này của PP định nghĩa các vấn đề an toàn được đề cập đến trong TOE và môi trường áp dụng của TOE.

Đánh giá định nghĩa các vấn đề an toàn được yêu cầu để chứng minh rằng các vấn đề an toàn dự kiến được đề cập bởi TOE và môi trường áp dụng của nó, được định nghĩa rõ ràng.

9.3.2. APE_SPD.1 định nghĩa các vấn đề an toàn

Các mối phụ thuộc: không có sự phụ thuộc nào

9.3.2.1. Phần tử hành động của nhà phát triển

9.3.2.1.1. APE_SPD.1.1D

Nhà phát triển cần cung cấp định nghĩa các vấn đề an toàn

9.3.2.2. Nội dung và trình bày của các thành phần

9.3.2.2.1. APE_SPD.1.1C

Định nghĩa các vấn đề an toàn cần mô tả các mối đe dọa.

9.3.2.2.2. APE_SPD.1.2C

Tất cả các mối đe dọa cần được mô tả dưới dạng tác nhân gây nguy cơ, tài sản và các hành động thù địch.

9.3.2.2.3. APE_SPD.1.3C

Định nghĩa vấn đề an toàn cần mô tả các OSP.

9.3.2.2.4. APE_SPD.1.4C

Định nghĩa các vấn đề an toàn cần mô tả giả thiết về môi trường vận hành của TOE.

9.3.2.3. Các phần tử hành động của đánh giá viên

9.3.2.3.1. APE_SPD.1.1E

Đánh giá viên cần khẳng định rằng thông tin cung cấp đáp ứng mọi yêu cầu về chứng cứ cho nội dung và trình bày.

9.4. Các mục tiêu an toàn (APE_OBJ)

9.4.1. Mục tiêu

Các mục tiêu an toàn là tuyên bố ngắn gọn của phản ứng dự định cho vấn đề an toàn được định nghĩa thông qua định nghĩa các vấn đề an toàn (họ APE_SPD).

Đánh giá các mục tiêu an toàn được đòi hỏi để chứng minh rằng các mục tiêu an toàn được đề cập đến là tương xứng và đầy đủ cho các vấn đề an toàn và sự phân tách giữa TOE và môi trường áp dụng nó sẽ được định nghĩa rõ ràng.

9.4.2. Phân mức thành phần

Các thành phần trong họ này được phân mức ra dựa trên việc quy định chúng là mục tiêu an toàn cho môi trường áp dụng hay mục tiêu an toàn cho TOE.

9.4.3. APE_OBJ.1 Các mục tiêu an toàn cho môi trường áp dụng

Các mối phụ thuộc: không có sự phụ thuộc nào.

9.4.3.1. Phần tử hành động của nhà phát triển

9.4.3.1.1. APE_OBJ.1.1D

Nhà phát triển PP cần cung cấp tuyên bố các mục tiêu an toàn.

9.4.3.2. Các phần tử nội dung và trình bày

9.4.3.2.1. APE_OBJ.1.1C

Tuyên bố các mục tiêu an toàn cần mô tả các mục tiêu an toàn cho môi trường vận hành.

9.4.3.3. Các phần tử hành động của đánh giá viên

9.4.3.3.1. APE_OBJ.1.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các chứng cứ.

9.4.4. APE_OBJ.2 Các mục tiêu an toàn

Các phụ thuộc: APE_SPD.1 định nghĩa vấn đề an toàn

9.4.4.1. Phần tử hành động của nhà phát triển

9.4.4.1.1. APE_OBJ.2.1D

Nhà phát triển cần cung cấp tuyên bố về các mục tiêu an toàn

9.4.4.1.2. APE_OBJ.2.2D

Nhà phát triển cần cung cấp sở cứ cho các mục tiêu an toàn.

9.4.4.2. Các phần tử nội dung và trình bày

9.4.4.2.1. APE_OBJ.2.1C

Tuyên bố về mục tiêu an toàn cần mô tả 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 áp dụng.

9.4.4.2.2. APE_OBJ.2.2C

Sở cứ các mục tiêu an toàn cần theo vết từng mục tiêu an toàn cho TOE chống lại các nguy cơ bởi các mục tiêu an toàn đó và các OSP được thực hiện bởi các mục tiêu an toàn.

9.4.4.2.3. APE_OBJ.2.3C

Sở cứ các mục tiêu an toàn cần theo vết từng mục tiêu an toàn cho môi trường áp dụng chống lại các nguy cơ bởi các mục tiêu an toàn đó và các OSP được thực hiện bởi các mục tiêu an toàn và giả định duy trì các mục tiêu an toàn.

9.4.4.2.4. APE_OBJ.2.4C

Sở cứ các mục tiêu an toàn cần chứng minh rằng các mục tiêu an toàn chống lại tất cả các nguy cơ.

9.4.4.2.5. APE_OBJ.2.5C

Sở cứ các mục tiêu an toàn cần chứng minh rằng các mục tiêu an toàn thực thi tất cả OSP.

9.4.4.2.6. APE_OBJ.2.6C

Sở cứ các mục tiêu an toàn cần chứng minh rằng các mục tiêu an toàn cho môi trường áp dụng duy trì tất cả các giả định.

9.4.4.3. Các phần tử hành động của đánh giá viên

9.4.4.3.1. APE_OBJ.2.1E

Đánh giá viên cần xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày các chứng cứ.

9.5. Định nghĩa các thành phần mở rộng (APE_ECD)

9.5.1. Mục tiêu

Các yêu cầu an toàn mở rộng là các yêu cầu mà không dựa trên các thành phần từ TCVN 8709-2 hay phần này của TCVN 8709 mà dựa trên các thành phần mở rộng: các thành phần được định nghĩa bởi tác giả PP.

Đánh giá định nghĩa các thành phần mở rộng là cần thiết để quyết định rằng chúng rất rõ ràng và không mập mờ, và chúng là cần thiết, ví dụ chúng không thể được biểu diễn rõ ràng nếu sử dụng các thành phần đang có trong TCVN 8709-2 hoặc phần này của TCVN 8709

9.5.2. APE_ECD.1 định nghĩa các thành phần mở rộng

Các mối phụ thuộc: không có sự phụ thuộc nào.

9.5.2.1. Phần tử hành động của nhà phát triển

9.5.2.1.1. APE_ECD.1.1D

Nhà phát triển cần cung cấp tuyên bố về các yêu cầu an toàn

9.5.2.1.2. APE_ECD.1.2D

Nhà phát triển cần cung cấp định nghĩa các thành phần mở rộng

9.5.2.2. Các phần tử nội dung và trình bày

9.5.2.2.1. APE_ECD.1.1C

Tuyên bố các yêu cầu an toàn cần xác định tất cả các yêu cầu an toàn mở rộng.

9.5.2.2.2. APE_ECD.1.2C

Định nghĩa các thành phần mở rộng cần xác định thành phần mở rộng cho từng yêu cầu an toàn mở rộng.

9.5.2.2.3. APE_ECD.1.3C

Định nghĩa các thành phần mở rộng cần được mô tả mỗi thành phần mở rộng có quan hệ thế nào với các lớp, họ và thành phần đang có trong TCVN 8709.

9.5.2.2.4. APE_ECD.1.4C

Định nghĩa các thành phần mở rộng cần sử dụng các lớp, họ, thành phần của TCVN 8709 đang tồn tại như là mô hình cho sự trình bày.

9.5.2.2.5. APE_ECD.1.5C

Các thành phần mở rộng cần sử dụng phương pháp, lớp, họ và thành phần đang có trong TCVN 8709 như là mô hình trong sự trình bày.

9.5.2.3. Các phần tử hành động của đánh giá viên

9.5.2.3.1. APE_ECD.1.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày của các chứng cứ.

9.5.2.3.2. APE_ECD.1.2E

Đánh giá viên cần xác nhận rằng không thành phần mở rộng nào được biểu diễn rõ ràng sử dụng các thành phần đang tồn tại.

9.6. Các yêu cầu an toàn (APE_REQ)

9.6.1. Mục tiêu

SFR được mô tả một cách rõ ràng, không lẫn lộn được xác định hoàn toàn các hành vi an toàn mong muốn của TOE. SAR được mô tả một cách rõ ràng, không lẫn lộn được hoàn toàn xác định các hoạt động mong muốn mà có trách nhiệm đạt được sự đảm bảo trong TOE.

Đánh giá các yêu cầu an toàn được yêu cầu để đảm bảo rằng chúng là rõ ràng, không lẫn lộn và được hoàn toàn xác định.

9.6.2. Phân mức thành phần

Các thành phần trong họ này được phân mức mà chúng được quy định hay SFR được bắt nguồn từ các mục tiêu an toàn cho TOE.

9.6.3. APE_REQ.1 Các yêu cầu an toàn được tuyên bố

Các phụ thuộc: APE_ECD.1 Định nghĩa các thành phần mở rộng

9.6.3.1. Phần tử hành động của nhà phát triển

9.6.3.1.1. APE_REQ.1.1D

Nhà phát triển cần cung cấp tuyên bố về các yêu cầu an toàn

9.6.3.1.2. APE_REQ.1.2D

Nhà phát triển cần cung cấp các sở cứ về các yêu cầu an toàn

9.6.3.2. Các phần tử nội dung và trình bày

9.6.3.2.1. APE_REQ.1.1C

Tuyên bố về các yêu cầu an toàn cần mô tả các SFR và SAR

9.6.3.2.2. APE_REQ.1.2C

Tất cả các đối tượng, mục tiêu, hoạt động, thuộc tính an toàn, các thực thể bên ngoài và các nhóm khác được sử dụng trong SFR và SAR, cần được xác định.

9.6.3.2.3 APE_REQ.1.3C

Tuyên bố về các yêu cầu an toàn cần xác định tất cả các quá trình hoạt động trong các yêu cầu an toàn.

9.6.3.2.4. APE_REQ.1.4C

Tất cả các hoạt động cần phải thực hiện đúng

9.6.3.2.5. APE_REQ.1.5C

Mỗi phụ thuộc của các yêu cầu an toàn không chỉ cần được thỏa mãn mà sở cứ các yêu cầu an toàn cần phải biện minh cho các phụ thuộc không được thỏa mãn.

9.6.3.2.6. APE_REQ.1.6C

Tuyên bố về các yêu cầu an toàn cần phải có tính nhất quán nội bộ.

9.6.3.3. Các phần tử hành động của đánh giá viên

9.6.3.3.1. APE_REQ.1.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày của các chứng cứ.

9.6.4. APE_REQ.2 Các yêu cầu an toàn thu được

Các phụ thuộc: APE_OBJ.2 Các mục tiêu an toàn

APE_ECD.1 Định nghĩa các thành phần mở rộng

9.6.4.1. Phần tử hành động của nhà phát triển

9.6.4.1.1. APE_REQ.2.1D

Nhà phát triển cần cung cấp tuyên bố về các yêu cầu an toàn

9.6.4.1.2. APE_REQ.2.2D

Nhà phát triển cần cung cấp sở cứ các yêu cầu an toàn.

9.6.4.2. Các phần tử nội dung và trình bày

9.6.4.2.1. APE_REQ.2.1C

Tuyên bố các yêu cầu an toàn cần mô tả SFR và SAR.

9.6.4.2.2. APE_REQ.2.2C

Tất cả các đối tượng, mục tiêu, hoạt động, thuộc tính an toàn, các thực thể bên ngoài và các nhóm khác được sử dụng trong SFR và SAR, cần được xác định.

9.6.4.2.3. APE_REQ.2.3C

Tuyên bố về các yêu cầu an toàn cần xác định tất cả các quá trình hoạt động trong các yêu cầu an toàn.

9.6.4.2.4. APE_REQ.2.4C

Các hoạt động cần phải được thực hiện đúng

9.6.4.2.5. APE_REQ.2.5C

Mỗi phụ thuộc của các yêu cầu an toàn không chỉ cần được thỏa mãn mà sở cứ các yêu cầu an toàn cần phải biện minh cho các phụ thuộc không được thỏa mãn.

9.6.4.2.6. APE_REQ.2.6C

Sở cứ các yêu cầu an toàn cần theo vết mỗi SFR quay lại các mục tiêu an toàn cho TOE.

9.6.4.2.7. APE_REQ.2.7C

Sở cứ các yêu cầu an toàn cần chứng minh rằng SFR đáp ứng tất cả các mục tiêu an toàn cho TOE.

9.6.4.2.8. APE_REQ.2.8C

Sở cứ các yêu cầu an toàn cần giải thích vì sao các SAP được chọn.

9.6.4.2.9. APE_REQ.2.9C

Tuyên bố về các yêu cầu an toàn cần nhất quán nội bộ

9.6.4.3. Các phần tử hành động của đánh giá viên

9.6.4.3.1. APE_REQ.2.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các chứng cứ.

10. Lớp ASE: Đánh giá đích an toàn

Mục tiêu của đánh giá ST là chứng minh rằng ST đó đã hoàn tất, nhất quán, phù hợp và nếu ST được dựa trên một hoặc nhiều PP hay các gói, khi đó ST là một thể hiệu đúng của các PP và các gói này. Các thuộc tính này là cần thiết cho ST để phù hợp cho sử dụng như là cơ sở cho đánh giá TOE.

Phần này cần được kết nối với các Phụ lục A, B và C trong TCVN 8709-1, phụ lục này làm rõ các khái niệm ở đây và cung cấp nhiều ví dụ.

Hình 9 chỉ ra các họ bên trong lớp này và phân cấp các thành phần trong các họ này.

Hình 9 - Phân cấp lớp ASE: Đánh giá Đích an toàn

10.1. Giới thiệu ST (ASE_INT)

10.1.1. Mục tiêu

Mục tiêu của họ này là mô tả TOE theo một cách hẹp theo ba mức gồm: Tham chiếu TOE, Tổng quan TOE và mô tả TOE.

Đánh giá giới thiệu ST được yêu cầu để chứng minh rằng ST và TOE được xác định đúng, do đó TOE được mô tả đúng tại 3 mức và mô tả của 3 mức này nhất quán với mỗi cái khác.

10.1.2. ASE_INT.1 Giới thiệu ST

Các mối phụ thuộc: Không có sự phụ thuộc nào.

10.1.2.1. Phần tử hành động của nhà phát triển

10.1.2.1.1. ASE_INT.1.1D

Nhà phát triển cần cung cấp giới thiệu ST.

10.1.2.2. Các phần tử nội dung và trình bày

10.1.2.2.1. ASE_INT.1.1C

Giới thiệu ST cần chứa tham chiếu ST, tham chiếu TOE, tổng quan TOE và mô tả TOE.

10.1.2.2.2. ASE_INT.1.2C

Tham chiếu ST cần xác định ST duy nhất.

10.1.2.2.3. ASE_INT.1.3C

Tham chiếu TOE cần xác định TOE.

10.1.2.2.4. ASE_INT.1.4C

Tổng quan TOE cần tóm tắt việc sử dụng các đặc trưng an toàn chính của TOE.

10.1.2.2.5. ASE_INT.1.5C

Tổng quan TOE cần xác định kiểu TOE.

10.1.2.2.6. ASE_INT.1.6C

Tổng quan TOE cần xác định bất kỳ phần cứng, phần mềm, phần sụn nào không phải TOE được yêu cầu bởi TOE.

10.1.2.2.7. ASE_INT.1.7C

Mô tả TOE cần mô tả phạm vi vật lý của TOE.

10.1.2.2.8. ASE_INT.1.8C

Mô tả TOE cần mô tả phạm vi logic của TOE.

10.1.2.3. Phần tử hành động của đánh giá viên

10.1.2.3.1 ASE_INT.1.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày của chứng cứ.

10.1.2.3.2. ASE_INT.1.2E

Đánh giá viên cần xác nhận rằng tham chiếu TOE, tổng quan TOE và mô tả TOE là nhất quán với các cái khác.

10.2. Các yêu cầu tuân thủ (ASE_CCL)

10.2.1. Mục tiêu

Mục tiêu của họ này là quyết định giá trị của yêu cầu tuân thủ. Thêm vào đó, họ này chỉ ra làm thế nào các ST yêu cầu tuân thủ với PP.

10.2.2. Mục tiêu

Mục tiêu của họ này là quyết định giá trị của yêu cầu tuân thủ. Thêm vào đó, họ này chỉ ra làm thế nào các ST yêu cầu tuân thủ với PP.

10.2.2. ACE_CCL.1 Các yêu cầu tuân thủ

Các phụ thuộc:

ASE_INT.1 ST Giới thiệu

ASE_ECD.1 Định nghĩa các thành phần mở rộng

ASE_REQ.1 Tuyên bố về các yêu cầu an toàn

10.2.2.1. Các phần tử hành động của đánh giá viên

10.2.2.1.1. ASE_CCT.1.1D

Nhà phát triển cần cung cấp yêu cầu tuân thủ

10.2.2.1.2 ASE_CCL.1.2D

Nhà phát triển cần cung cấp sở cứ yêu cầu tuân thủ

10.2.2.2. Các phần tử nội dung và trình bày

10.2.2.2.1. ASE_CCL.1.1C

Yêu cầu tuân thủ cần chứa yêu cầu tuân thủ TCVN 8709 để xác định phiên bản của TCVN 8709-2 mà yêu cầu tuân thủ TOE và ST.

10.2.2.2.2. ASE_CCL.1.2C

Yêu cầu tuân thủ TCVN 8709 cần mô tả tuân thủ của ST theo TCVN 8709-2, không chỉ tuân thủ TCVN 8709-2 mà còn TCVN 8709-2 mở rộng.

10.2.2.2.3. ASE_CCL.1.3C

Yêu cầu tuân thủ TCVN 8709 cần mô tả tuân thủ của ST theo phần này của TCVN 8709 không chỉ tuân thủ theo phần này của TCVN 8709 mà còn theo phần này của TCVN 8709 mở rộng.

10.2.2.2.4. ASE_CCL.1.4C

Yêu cầu tuân thủ TCVN 8709 cần nhất quán với định nghĩa các thành phần mở rộng.

10.2.2.2.5. ASE_CCL.1.5C

Yêu cầu tuân thủ cần chỉ ra tất cả các PP và các gói đảm bảo an toàn mà ST yêu cầu tuân thủ.

10.2.2.2.6. ASE_CCL.1.6C

Yêu cầu tuân thủ cần mô tả bất kỳ tuân thủ nào của ST theo gói, không chỉ các gói tuân thủ mà cả các gói tăng cường.

10.2.2.2.7. ASE_CCL.1.7C

Sở cứ yêu cầu tuân thủ cần chứng minh rằng kiểu TOE là nhất quán với kiểu TOE trong PP theo đó sự tuân thủ được yêu cầu.

10.2.2.2.8. ASE_CCL.1.8C

Sở cứ yêu cầu tuân thủ cần chứng minh rằng tuyên bố của định nghĩa vấn đề an toàn là nhất quán với tuyên bố định nghĩa các vấn đề an toàn trong PP theo đó sự tuân thủ được yêu cầu.

10.2.2.2.9. ASE_CCL.1.9C

Sở cứ yêu cầu tuân thủ cần chứng minh rằng các tuyên bố của mục tiêu an toàn là nhất quán với tuyên bố của mục tiêu an toàn trong PP theo đó sự tuân thủ được yêu cầu.

10.2.2.2.10. ASE_CCL.1.10C

Sở cứ yêu cầu tuân thủ cần chứng minh rằng tuyên bố của các yêu cầu an toàn là nhất quán với tuyên bố của các yêu cầu an toàn trong PP mà tại đó sự tuân thủ được yêu cầu.

10.2.2.3. Các phần tử hành động của đánh giá viên

10.2.2.3.1. ASE_CCL.1.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và biểu diễn các chứng cứ.

10.3. Định nghĩa vấn đề an toàn (ASE_SPD)

10.3.1. Mục tiêu

Trong phần này của ST định nghĩa vấn đề an toàn được đề cập bởi TOE và môi trường áp dụng TOE.

Đánh giá định nghĩa các vấn đề an toàn được yêu cầu để chứng minh rằng vấn đề an toàn dự định được đề cập bởi TOE và môi trường áp dụng của nó là được định nghĩa rõ ràng.

10.3.2. ASE_SPD.1 Định nghĩa vấn đề an toàn

Các mối phụ thuộc: không có sự phụ thuộc nào.

10.3.2.1. Phần tử hành động của nhà phát triển

10.3.2.1.1. ASE_SPD.1.1D

Nhà phát triển cần cung cấp định nghĩa các vấn đề an toàn

10.3.2.2. Các phần tử nội dung và trình bày

10.3.2.2.1. ASE_SPD.1.1C

Định nghĩa vấn đề an toàn cần mô tả các nguy cơ

10.3.2.2.2. ASE_SPD.1.2C

Tất cả các nguy cơ cần mô tả dưới dạng tác nhân nguy cơ, tài sản và hành động bất lợi.

10.3.2.2.3. ASE_SPD.1.3C

Định nghĩa vấn đề an toàn cần mô tả OSP

10.3.2.2.4. ASE_SPD.1.4C

Định nghĩa vấn đề an toàn cần mô tả giả thiết về môi trường hoạt động của TOE.

10.3.2.3. Các phần tử hành động của đánh giá viên

10.3.2.3.1. ASE_SPD.1.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày của các chứng cứ.

10.4. Mục tiêu an toàn (ASE_OBJ)

10.4.1. Mục tiêu

Các mục tiêu an toàn là tuyên bố ngắn gọn của các phản ứng dự định cho các vấn đề về an toàn được định nghĩa qua định nghĩa các vấn đề an toàn của họ (ASE_SPD)

Đánh giá các mục tiêu an toàn được yêu cầu để chứng minh rằng các mục tiêu an toàn là phù hợp và đề cập hoàn toàn đến định nghĩa các vấn đề an toàn mà sự phân chia của vấn đề này giữa TOE và môi trường hoạt động của nó được định nghĩa rõ ràng.

10.4.2. Phân mức thành phần

Các thành phần trong họ này được phân mức dựa trên có hay không việc quy định chỉ các mục tiêu an toàn cho môi trường áp dụng hay cả các mục tiêu an toàn cho TOE.

10.4.3. ASE_OBJ.1 Các mục tiêu an toàn cho môi trường hoạt động

Các mối phụ thuộc: không có sự phụ thuộc nào.

10.4.3.1. Phần tử hành động của nhà phát triển.

10.4.3.1.1. ASE_OBJ.1.1D

Nhà phát triển cần cung cấp tuyên bố về mục tiêu an toàn

10.4.3.2. Các phần tử nội dung và trình bày

10.4.3.2.1. ASE_OBJ.1.1C

Tuyên bố về các mục tiêu an toàn cần mô tả các mục tiêu an toàn cho môi trường áp dụng

10.4.3.3. Các phần tử hành động của đánh giá viên

10.4.3.3.1. ASE_OBJ.1.1E

Đánh giá viên cần xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu cho nội dung và biểu diễn các chứng cứ.

10.4.4. ASE_OBJ.2 Các mục tiêu an toàn.

Các phụ thuộc: ASE_SPD.1 định nghĩa các vấn đề an toàn.

10.4.4.1. Phần tử hành động của nhà phát triển

10.4.4.1.1. ASE_OBJ.2.1D

Nhà phát triển cần cung cấp tuyên bố về các mục tiêu an toàn.

10.4.4.1.2. ASE_OBJ.2.2D

Nhà phát triển cần cung cấp sở cứ các mục tiêu an toàn

10.4.4.2. Các phần tử nội dung và trình bày

10.4.4.2.1. ASE_OBJ.2.1C

Tuyên bố về các mục tiêu an toàn cần mô tả 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 áp dụng.

10.4.4.2.2. ASE_OBJ.2.2C

Sở cứ các mục tiêu an toàn cần theo vết mỗi mục tiêu an toàn cho TOE trở lại chống lại các nguy cơ bởi mục tiêu an toàn đó và thực thi OSP bởi mục tiêu an toàn đó.

10.4.4.2.3. ASE_OBJ.2.3C

Sở cứ các mục tiêu an toàn cần theo vết mỗi mục tiêu an toàn cho môi trường áp dụng trở lại chống lại các nguy cơ bởi mục tiêu an toàn đó, thực thi OSP bởi mục tiêu an toàn đó, và giả thiết duy trì mục tiêu an toàn đó.

10.4.4.2.4. ASE_OBJ.2.4C

Sở cứ các mục tiêu an toàn cần chứng minh rằng mục tiêu an toàn chống lại tất cả các nguy cơ.

10.4.4.2.5. ASE_OBJ.2.5C

Sở cứ các mục tiêu an toàn cần chứng minh rằng mục tiêu an toàn chống lại tất cả các OSP.

10.4.4.2.6. ASE_OBJ.2.6C

Sở cứ các mục tiêu an toàn cần chứng minh rằng mục tiêu an toàn cho môi trường áp dụng duy trì tất cả các giả thiết.

10.4.4.3. Các phần tử hành động của đánh giá viên

10.4.4.3.1. ASE_OBJ.2.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp cần đáp ứng tất cả các yêu cầu cho nội dung và trình bày các chứng cứ.

10.5. Định nghĩa các thành phần mở rộng (ASE_ECD)

10.5.1. Mục tiêu

Các yêu cầu an toàn mở rộng là các yêu cầu mà không dựa trên các thành phần từ TCVN 8709-2 hay phần này của TCVN 8709, mà dựa trên các thành phần mở rộng: Thành phần được định nghĩa bởi tác giả ST.

Đánh giá định nghĩa các thành phần mở rộng cần thiết để quyết định rằng chúng là rõ ràng và không thể nhầm lẫn, và do đó chúng là cần thiết, ví dụ chúng có thể được biểu diễn rõ ràng sử dụng TCVN 8709-2 hoặc phần này của các thành phần TCVN 8709.

10.5.2. ASE_ECD.1 Định nghĩa các thành phần mở rộng

Các mối phụ thuộc: không có sự phụ thuộc nào.

10.5.2.1.1. ASE_ECD.1.1D

Nhà phát triển cần cung cấp tuyên bố về yêu cầu an toàn.

10.5.2.1.2. ASE_ECD.1.2D

Nhà phát triển cần cung cấp định nghĩa các thành phần mở rộng.

10.5.2.2. Các phần tử nội dung và trình bày

10.5.2.2.1. ASE_ECD.1.1C

Tuyên bố các yêu cầu an toàn cần xác định tất cả các yêu cầu an toàn mở rộng.

10.5.2.2.2. ASE_ECD.1.2C

Định nghĩa các thành phần mở rộng cần định nghĩa thành phần mở rộng cho mỗi yêu cầu an toàn mở rộng.

10.5.2.2.3. ASE_ECD.1.3C

Định nghĩa các thành phần mở rộng cần mô tả mỗi thành phần mở rộng có mối quan hệ như thế nào với các thành phần, họ và lớp trong TCVN 8709 đang tồn tại.

10.5.2.2.4. ASE_ECD.1.4C

Định nghĩa các thành phần mở rộng cần sử dụng các thành phần, lớp, họ và phương pháp trong TCVN 8709 như một mô hình cho trình bày.

10.5.2.3. Các phần tử hành động của đánh giá viên

10.5.2.3.1. ASE_ECD.1.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày của chứng cứ.

10.5.2.3.2. ASE_ECD.1.2E

Đánh giá viên cần xác nhận rằng không thành phần mở rộng nào có thể biểu diễn rõ ràng mà sử dụng các thành phần đang có.

10.6. Các yêu cầu an toàn (ASE_REQ)

10.6.1. Mục tiêu

SFR được mô tả một cách rõ ràng, không lẫn lộn được xác định hoàn toàn các hành vi an toàn mong muốn của TOE. SAR được mô tả một cách rõ ràng, không lẫn lộn được hoàn toàn xác định các hoạt động mong muốn mà có trách nhiệm đạt được sự đảm bảo trong TOE.

Đánh giá các yêu cầu an toàn được yêu cầu để đảm bảo rằng chúng là rõ ràng, không lẫn lộn và được hoàn toàn xác định.

10.6.2. Phân mức thành phần

Các thành phần trong họ này được phân mức theo như chúng được tuyên bố.

10.6.3. ASE_REQ.1 Định nghĩa các thành phần mở rộng

10.6.3.1. Phần tử hành động của nhà phát triển.

10.6.3.1.1. ASE_REQ.1.1D

Nhà phát triển cần cung cấp tuyên bố về yêu cầu an toàn

10.6.3.1.2. ASE_REQ.1.2D

Nhà phát triển cần cung cấp sở cứ các yêu cầu an toàn

10.6.3.2. Các phần tử nội dung và trình bày

10.6.3.2.1. ASE_REQ.1.1C

Tuyên bố các yêu cầu an toàn cần mô tả SFR và SAR

10.6.3.2.2. ASE_REQ.1.2C

Tất cả các chủ thể, mục tiêu, hoạt động, thuộc tính an toàn, thực thể ngoài và các thuật ngữ được sử dụng trong SFR và SAR cần được định nghĩa.

10.6.3.2.3. ASE_REQ.1.3C

Tuyên bố về các yêu cầu an toàn cần xác định tất cả các hoạt động dựa trên các yêu cầu an toàn.

10.6.3.2.4. ASE_REQ.1.4C

Tất cả các hoạt động cần thực hiện chính xác.

10.6.3.2.5. ASE_REQ.1.5C

Mỗi các mối phụ thuộc của các yêu cầu an toàn cần không chỉ sự thỏa mãn mà sở cứ các yêu cầu an toàn cần biện minh cho các mối phụ thuộc không được thỏa mãn.

10.6.3.2.6. ASE_REQ.1.6C

Tuyên bố về các yêu cầu an toàn cần nhất quán nội bộ.

10.6.3.3. Các phần tử hành động của đánh giá viên

10.6.3.3.1. ASE_REQ.1.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày các chứng cứ

10.6.4. ASE_REQ.2 Các yêu cầu an toàn thu được

Các phụ thuộc:

ASE_OBJ.2 Các mục tiêu an toàn

ASE_ECD.1 Định nghĩa các thành phần mở rộng

10.6.4.1. Phần tử hành động của nhà phát triển

10.6.4.1.1. ASE_REQ.2.1D

Nhà phát triển cần cung cấp tuyên bố các yêu cầu an toàn.

10.6.4.1.2. ASE_REQ.2.2D

Nhà phát triển cần cung cấp sở cứ các yêu cầu an toàn.

10.6.4.2. Các phần tử nội dung và trình bày

10.6.4.2.1. ASE_REQ.2.1C

Tuyên bố các yêu cầu an toàn cần mô tả SFR và SAR.

10.6.4.2.2. ASE_REQ.2.2C

Tất cả các chủ thể, mục tiêu, hoạt động, thuộc tính an toàn, thực thể ngoài và các thuật ngữ được sử dụng trong SFR và SAR cần được định nghĩa.

10.6.4.2.3. ASE_REQ.2.3C

Tuyên bố các yêu cầu an toàn cần chỉ ra tất cả các hoạt động dựa trên các yêu cầu an toàn.

10.6.4.2.4. ASE_REQ.2.4C

Tất cả các hoạt động cần phải thực hiện chính xác.

10.6.4.2.5. ASE_REQ.2.5C

Mỗi phụ thuộc của các yêu cầu an toàn cần không chỉ thỏa mãn mà sở cứ các yêu cầu an toàn cần biện minh cho các phụ thuộc mà không được thỏa mãn.

10.6.4.2.6. ASE_REQ.2.6C

Sở cứ các yêu cầu an toàn cần theo vết mỗi SFR trở lại các mục tiêu an toàn cho TOE.

10.6.4.2.7. ASE_REQ.2.7C

Sở cứ các yêu cầu an toàn cần chứng minh rằng SFR đáp ứng tất cả các mục tiêu an toàn cho TOE.

10.6.4.2.8. ASE_REQ.2.8C

Sở cứ các yêu cầu an toàn cần giải thích vì sao SAR được chọn.

10.6.4.2.9. ASE_REQ.2.9C

Tuyên bố các yêu cầu an toàn cần nhất quán nội bộ.

10.6.4.3. Các phần tử hành động của đánh giá viên

10.6.4.3.1. ASE_REQ.2.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày các chứng cứ.

10.7. Đặc tả tổng quát TOE (ASE_TSS)

10.7.1. Mục tiêu

Đặc tả tổng quát TOE giúp đánh giá viên và khách hàng tiềm năng có được các hiểu biết chung về việc TOE được thực hiện như thế nào.

Đánh giá của đặc tả tổng quát TOE là cần thiết để quyết định mô tả TOE như thế nào là phù hợp:

- Đáp ứng các SFR của nó

- Bảo vệ chính nó chống lại sự can thiệp, sự giả mạo và phớt lờ ở mức logic.

Và các đặc tả tổng quát phải nhất quán với các mô tả hẹp khác của TOE.

10.7.2. Phân mức thành phần

Các thành phần trong họ này được phân mức dựa trên việc có hay không đặc tả tổng quát TOE là cần thiết để mô tả TOE đáp ứng SFR như thế nào, hay có hay không đặc tả tổng quát TOE cần thiết để mô tả làm thể nào TOE bảo vệ chính nó chống lại việc giả mạo hay phớt lờ ở mức logic. Sự mô tả bổ sung này có thể được sử dụng trong trường hợp đặc biệt tại nơi mà có thể liên quan xem xét kiến trúc an toàn TOE.

10.7.3. ASE_TSS.1 Đặc tả tổng quát TOE

Các phụ thuộc:

ASE_INT.1 Giới thiệu ST

ASE_REQ.1 Tuyên bố các yêu cầu an toàn

ASE_REQ.1 Đặc tả chức năng cơ sở

10.7.3.1. Phần tử hành động của nhà phát triển

10.7.3.1.1. ASE_TSS.1.1D

Nhà phát triển cần cung cấp đặc tả tổng quát TOE

10.7.3.2. Các phần tử nội dung và trình bày

10.7.3.2.1. ASE_TSS.1.1C

Đặc tả tổng quát TOE cần mô tả TOE đáp ứng mối SFR như thế nào

10.7.3.3. Các phần tử hành động của đánh giá viên

10.7.3.3.1. ASE_TSS.1.1E

Đánh giá viên cần xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các chứng cứ

10.7.3.3.2. ASE_TSS.1.2E

Đánh giá viên cần xác nhận rằng đặc tả tổng quát TOE nhất quán với tổng quan TOE và mô tả TOE.

10.7.4. ASE_TSS.2 Đặc tả tổng quát với kiến trúc thiết kế tổng quát.

Các phụ thuộc:

ASE_INT.1 Giới thiệu ST

ASE_REQ.1 Tuyên bố các yêu cầu an toàn

ASE_ARC.1 Mô tả các kiến trúc an toàn

10.7.4.1. Phần tử hành động của nhà phát triển

10.7.4.1.1. ASE_TSS.2.1D

Nhà phát triển cần cung cấp đặc tả tổng quát TOE

10.7.4.2. Các phần tử nội dung và trình bày

10.7.4.2.1. ASE_TSS.2.1C

Đặc tả tổng quát TOE cần mô tả TOE đáp ứng mỗi SFR như thế nào.

10.7.4.2.2. ASE_TSS.2.2C

Đặc tả tổng quát TOE cần mô tả làm thế nào TOE tự bảo vệ chống lại sự can thiệp và sự giả mạo mức logic.

10.7.4.2.3. ASE_TSS.2.3C

Đặc tả tổng quát TOE cần mô tả TOE tự bảo vệ như thế nào để chống lại sự phớt lờ.

10.7.4.3. Các phần tử hành động của đánh giá viên

10.7.4.3.1. ASE_TSS.2.1E

Đánh giá viên cần xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các chứng cứ.

10.7.4.3.2. ASE_TSS.2.2E

Đánh giá viên cần xác nhận rằng đặc tả tổng quát TOE là nhất quán với tổng quan TOE và mô tả TOE.

11. Lớp ADV: Phát triển

Yêu cầu của lớp phát triển là cung cấp thông tin về TOE. Kiến thức có được từ thông tin này phải được sử dụng như là cơ sở để tạo ra bản phân tích điểm yếu và kiểm tra trên TOE như được mô tả trong lớp AVA và ATE.

Lớp phát triển bao gồm 6 họ các yêu cầu cho việc cấu trúc và biểu diễn TSF tại các mức thay đổi và các dạng thay đổi trừu tượng. Những họ này bao gồm:

● Yêu cầu đối với mô tả thiết kế và thực hiện các SFR (ADV_FSP, ADV_TDS, ADV_IMP) (ở các mức độ trừu tượng khác nhau)

● Yêu cầu đối với mô tả về các tính năng hướng dẫn kiến trúc theo định hướng tách miền, khả năng tự bảo vệ và không thể vượt qua của TSF trong chức năng an toàn (ADV_ARC)

● Yêu cầu mô hình chính sách an toàn và cho ánh xạ tương ứng giữa các mô hình chính sách an toàn và đặc tả chức năng (ADV_SPM)

● Yêu cầu về cơ cấu nội bộ của TSF, bao gồm các khía cạnh như mô đun, phân lớp, và giảm thiểu độ phức tạp (ADV_INT).

Khi lập tài liệu các chức năng an toàn của TOE, có hai thuộc tính cần phải được chứng minh. Thuộc tính đầu tiên là các chức năng an toàn làm việc chính xác, có nghĩa là, nó thực hiện theo quy định. Thuộc tính thứ hai, đòi hỏi một cách tiếp cận khó khăn hơn trong để chứng minh, theo đó TOE không thể được sử dụng theo cách như vậy mà các chức năng bảo mật có thể bị hỏng hoặc bỏ qua. Hai thuộc tính này yêu cầu một cách khác trong tiếp cận phân tích, và vì thế họ ADV được cấu trúc để hỗ trợ các phương pháp tiếp cận khác nhau. Các họ đặc tả chức năng (ADV_FSP), thiết kế TOE (ADV_TDS), biểu diễn triển khai (ADV_IMP), và mô hình chính sách an toàn (ADV_SPM) sẽ thực hiện với thuộc tính đầu tiên: đặc tả của chức năng an toàn. Các họ Kiến trúc (ADV_ARC) và TSF internals (ADV_INT) đối phó với các bất động sản thứ hai: các đặc điểm kỹ thuật của các thiết kế của TOE thể hiện các chức năng bảo mật không thể bị hỏng hoặc bỏ qua. Cần lưu ý rằng cả hai thuộc tính cần phải được nhận biết: thuộc tính càng bí mật được thỏa mãn thì TOE càng tin cậy. Các thành phần trong họ được thiết kế bởi vì sự đảm bảo tăng khi có được sự phân cấp tăng.

Các mô hình cho các họ nhắm mục tiêu vào các thuộc tính đầu tiên là một trong phân rã thiết kế. Ở mức cao nhất, có một đặc tả chức năng của TSF về giao diện của nó (mô tả những gì TSF làm để yêu cầu TSF cho các dịch vụ và trả lời kết quả), phân rã các TSF thành các đơn vị nhỏ hơn (Phụ thuộc vào việc bảo đảm mong muốn và sự phức tạp của TOE) và mô tả cách TSF đã thực hiện được chức năng của mình (với một mức độ chi tiết tương xứng với mức độ bảo đảm), và cho thấy việc thực hiện các TSF. Một mô hình chính thức của các hành vi an toàn cũng có thể được đưa ra. Tất cả các mức phân rã thường được sử dụng trong việc xác định tính đầy đủ và chính xác của các mức khác nhau, để đảm bảo rằng các mức có hỗ trợ lẫn nhau. Các yêu cầu để biểu diễn TSF khác nhau được tách thành các họ khác nhau, để cho phép các tác giả PP/ST chỉ ra các biểu diễn TSF nào được yêu cầu. Mức độ được lựa chọn sẽ quyết định dự đoán bảo đảm hay mong muốn sẽ đạt được.

Hình 10 chỉ ra các mối quan hệ giữa sự biểu diễn TSF khác nhau của lớp ADV, cũng như mối quan hệ của chúng với các lớp khác. Số liệu cho thấy, các lớp APE và ASE định nghĩa các yêu cầu về sự tương ứng giữa các SFR và các mục tiêu an toàn cho TOE. Lớp ASE cũng định nghĩa các yêu cầu cho sự tương ứng giữa hai mục tiêu an toàn và SFR, và với các đặc tả tóm tắt TOE để giải thích làm thế nào TOE đáp ứng SFR của nó. Các hoạt động của ALC_CMC.5.2E bao gồm việc xác minh rằng các TSF đã được kiểm thử với lớp ATE và AVA trong thực tế, một trong những mô tả của tất cả các cấp mức độ phân rã ADV.

Hình 10 - Mối quan hệ của các cấu trúc ADV với lớp khác và các họ khác

Các yêu cầu cho tất cả các đáp ứng khác thể hiện trong hình 10 được định nghĩa trong lớp ADV. Các mô hình chính sách an toàn họ (ADV_SPM) xác định các yêu cầu về mô hình chính thức SFR được chọn, và cung cấp đáp ứng giữa các đặc tả chức năng và mô hình chính thức. Mỗi họ đảm bảo cụ thể cho một đại diện TSF (tức là chức năng đặc điểm kỹ thuật (ADV_FSP), thiết kế TOE (ADV_TDS) và biểu diễn triển khai (ADV_IMP)) xác định các yêu cầu liên quan mà TSF đại diện cho các SFR. Tất cả các phân rã phải phản ánh chính xác tất cả các phân rã khác (ví dụ, có thể hỗ trợ lẫn nhau); Nhà phát triển cung cấp khả năng theo vết với phần tử C cuối của các thành phần. Bảo đảm liên quan đến yếu tố này là thu được trong quá trình phân tích cho từng mức độ phân rã bằng cách tham chiếu đến mức độ khác của sự phân rã (một cách đệ quy) trong khi các phân tích của một mức độ cụ thể của việc phân rã đang được thực hiện; Đánh giá viên thẩm tra sự tương ứng như là một phần của phần tử E thứ hai. Những hiểu biết thu được từ các mức độ phân rã tạo thành cơ sở của những nỗ lực kiểm thử chức năng và thâm nhập.

Họ ADV_INT không được biểu diễn trong hình này, vì nó có liên quan đến cấu trúc bên trong của TSF, và liên quan gián tiếp đến quá trình tinh chỉnh các đại diện của TSF. Tương tự, họ ADV_ARC là không được biểu diễn trong hình vì nó liên quan đến tính hợp lý kiến trúc, hơn là việc biểu diễn, của các TSF. Cả ADV_INT và ADV_ARC liên quan đến việc phân tích các thuộc tính mà các TOE không thể thực hiện để phá vỡ hoặc làm hỏng chức năng an toàn của nó.

Chức năng an toàn TOE (TSF) bao gồm tất cả các phần của TOE mà cần phải dựa vào thực thi của SFR. TSF bao gồm cả chức năng trực tiếp thực thi các SFR, cũng như các chức năng đó, mà không trực tiếp thực thi các SFR, góp phần thực thi của chúng một cách gián tiếp nhiều hơn, bao gồm cả chức năng với khả năng là nguyên nhân các SFR bị vi phạm. Điều này bao gồm các phần của TOE được viện dẫn lúc bắt đầu mà có trách nhiệm đưa TSF vào trạng thái an toàn ban đầu của nó.

Một số khái niệm quan trọng được sử dụng trong sự phát triển của các thành phần của họ ADV. Những khái niệm, được giới thiệu ngắn gọn ở đây, được giải thích đầy đủ hơn trong các ghi chú cho các họ.

Một quan điểm chỉ ra là càng nhiều thông tin sẵn sàng thì càng đạt được mức độ đảm bảo cao hơn về chức năng an toàn thông tin. 1) được thực hiện chính xác, 2) không thể bị sửa đổi và 3) không thể bị vượt qua. Điều này được thực hiện thông qua việc thẩm tra sự nhất quán và chính xác của các tài liệu với các tài liệu khác, và với việc cung cấp thông tin có thể được sử dụng để đảm bảo rằng các hoạt động kiểm tra là toàn diện (cả hai kiểm tra về chức năng và thâm nhập). Điều này được phản ánh sự phân mức thành phần của họ. Nhìn chung, các thành phần được phân mức dựa trên số lượng thông tin mà được cung cấp (và được phân tích sau đó).

Mặc dù không phải đúng với tất cả các TOE, trong trường hợp nói chung khi TSF có đủ phức tạp mà có các phần của TSF được kiểm tra tăng cường hơn các phần khác của TSF. Không may việc quyết định các phần này có phần chủ quan, do đó thuật ngữ và thành phần đã được định nghĩa như vậy mà là mức tăng đảm bảo, trách nhiệm trong việc quyết định các phần nào của TSF cần phải xem xét thay đổi chi tiết từ nhà phát triển đến đánh giá viên. Để hỗ trợ trong việc thể hiện khái niệm này, theo các thuật ngữ được giới thiệu. Cần lưu ý rằng trong các họ của lớp, thuật ngữ này được sử dụng khi biểu diễn các phần liên quan đến SFR của TOE (nghĩa là, các phần tử và các đơn vị làm việc thể hiện bên trong các đặc tả chức năng (ADV_FSP), thiết kế TOE (ADV_TDS), và biểu diễn thực hiện của các họ (ADV_IMP)). Khi đó, khái niệm chung (với một số phần của TOE hấp dẫn hơn các phần khác) được áp dụng với các họ khác, tiêu chí này được biểu diễn dưới cách khác để đạt được yêu cầu đảm bảo.

Tất cả các phần của TSF là phù hợp an toàn, nghĩa là chúng cần phải bảo vệ an toàn của TOE như được biểu diễn bởi các SFR và các yêu cầu cho việc chia cắt miền và không thể đi đường vòng. Một khía cạnh phù hợp an toàn khác là mức độ mà một phần của TSF thực thi yêu cầu an toàn. Các phần khác nhau của TOE thực hiện các vai trò khác nhau (hoặc vai trò không rõ ràng ở tất cả) trong việc thực thi các yêu cầu an toàn, điều này tạo ra một sự liên tục với SFR liên quan: tại một đầu của sự liên tục này là các phần của TOE được gọi là thực thi-SFR. Các phần này đóng một vai trò trực tiếp trong việc thực hiện bất kỳ SFR nào trong TOE này. SFR như thế tham chiếu đến bất kỳ chức năng cung cấp bởi một trong những SFR có trong ST này. Cần lưu ý rằng việc định nghĩa của việc thực hiện vai trò trong chức năng thực thi-SFR là không thể biểu diễn số lượng. Ví dụ, trong việc thực hiện cơ chế kiểm soát truy nhập tùy ý (DAC), cái nhìn hẹp thực thi-SFR có thể chỉ là một vài dòng mã thực sự thực hiện việc kiểm tra các thuộc tính của chủ thể chống lại các thuộc tính của đối tượng. Một cái nhìn rộng hơn sẽ bao gồm các thực thể phần mềm (ví dụ, chức năng C) có chứa một số dòng mã. Một cái nhìn rộng hơn vẫn sẽ bao gồm những người gọi của chức năng C, bởi vì chúng sẽ chịu trách nhiệm thi hành quyết định được trả về bởi việc kiểm tra thuộc tính. Một cái nhìn rộng hơn sẽ bao gồm bất kỳ mã nào trong cây gọi (hoặc chương trình tương đương cho việc thực hiện các ngôn ngữ được sử dụng) cho chức năng C đó (ví dụ, một chức năng sắp xếp mà các thực thể trong danh sách điều khiển truy cập được sắp xếp sử dụng thuật toán first-match - chọn phù hợp đầu tiên). Tại một số điểm, thành phần này không được thực thi nhiều trong sách an toàn, mà đóng vai trò hỗ trợ, các thành phần như vậy được gọi là hỗ trợ SFR.

Một trong các tính chất của chức năng hỗ trợ SFR là nó được tin cậy để thực hiện việc chỉnh sửa việc thực hiện SFR trong quá trình áp dụng mà không có lỗi. Chức năng này có thể bị phụ thuộc vào chức năng thực thi SFR, nhưng các mối phụ thuộc này thường ở mức độ chức năng, ví dụ như quản lý bộ nhớ, quản lý bộ đệm, v.v… Việc giảm liên tục độ tương quan an toàn được gọi là không can thiệp vào SFR (SFR no-interfering). Chức năng như vậy không có vai trò trong việc thực hiện các SFR, và là một phần tương tự của TSF vì môi trường của nó: ví dụ, bất kỳ mã chạy trong một chế độ phần cứng đặc quyền của hệ điều hành. Nó cần phải được coi là một phần của TSF bởi vì, nếu bị xâm nhập (hoặc thay thế bởi mã độc hại), nó có thể làm ảnh hưởng tới hoạt động chính xác của SFR bởi ưu điểm của việc hoạt động trong chế độ phần cứng đặc quyền. Một ví dụ về chức năng không can thiệp vào SFR có thể là một tập hợp các ứng dụng dấu chấm động trong toán học nổi thực hiện chế độ nhân cho các suy xét về tốc độ.

Họ kiến trúc (Kiến trúc an toàn (ADV_ARC)) cung cấp các yêu cầu và phân tích của TOE dựa trên các thuộc tính phân tách miền, tự bảo vệ, và không thể vượt qua. Những thuộc tính liên quan đến các SFR trong đó, nếu những thuộc tính này không có mặt, nó có thể sẽ dẫn đến lỗi của các cơ chế thực hiện SFR. Chức năng và thiết kế liên quan đến các thuộc tính này không được coi là một phần trong mô tả liên tục ở trên, nhưng thay vì được xử lý riêng do bản chất khác nhau của nó và các yêu cầu phân tích.

Sự khác biệt trong phân tích việc thực hiện các SFR (chức năng thực thi SFR và hỗ trợ SFR) và thực hiện một số thuộc tính an toàn nền tảng khác của TOE, bao gồm các vấn đề liên quan khởi tạo, tự bảo vệ và không thể vượt qua, đó là chức năng liên quan đến SFR mà nhiều hay ít có thể thấy được trực tiếp và tương đối dễ dàng cho việc kiểm tra, khi đó các thuộc tính được đề cập ở trên yêu cầu các mức độ phân tích khác nhau trong các tập rộng hơn nhiều của chức năng. Hơn nữa, độ sâu phân tích các thuộc tính đó sẽ thay đổi phụ thuộc vào thiết kế của TOE. Họ ADV được xây dựng để giải quyết điều này bằng một họ riêng biệt (Kiến trúc an toàn (ADV_ARC)) dành cho việc phân tích các yêu cầu khởi tạo, tự bảo vệ, và không thể vượt qua, trong khi các họ khác có liên quan với phân tích các chức năng hỗ trợ SFR.

Ngay cả trong trường hợp các mô tả khác nhau là cần thiết cho nhiều cấp độ trừu tượng, nó không phải là hoàn toàn cần thiết cho mỗi và mọi đại diện TSF chứa trong một văn bản riêng. Thật vậy, nó có thể là trường hợp mà một tài liệu duy nhất đáp ứng các yêu cầu lập tài liệu cho việc biểu diễn nhiều hơn một TSF, vì nó là thông tin về mỗi cái trong các đại diện TSF đó là cần thiết, hơn là các cấu trúc tài liệu kết quả. Trong trường hợp nhiều đại diện TSF được kết hợp trong một tài liệu duy nhất, các nhà phát triển nên chỉ ra các phần của tài liệu đáp ứng được yêu cầu.

Ba loại kiểu đặc tả kỹ thuật được ủy quyền của lớp này: không chính thức, bán chính thức và chính thức. Các đặc tả chức năng và tài liệu thiết kế TOE luôn luôn được viết bằng một trong hai phong cách chính thức hoặc bán chính thức. Kiểu bán chính thức làm giảm sự không rõ ràng trong các tài liệu này trên một bài trình bày không chính thức. Một đặc tả chính thức có thể được yêu cầu thêm vào các bài trình bày bán chính thức, giá trị này là một mô tả của TSF trong nhiều hơn một cách sẽ tăng thêm bảo đảm rằng các TSF đã được xác định hoàn toàn và chính xác.

Một đặc điểm kỹ thuật không chính thức được viết dưới dạng văn xuôi trong ngôn ngữ thông dụng. Ngôn ngữ được sử dụng ở đây là ý nghĩa truyền thông trong bất kỳ tiếng nói chung (ví dụ như tiếng Tây Ban Nha, tiếng Đức, tiếng Pháp, tiếng Anh, tiếng Hà Lan). Một đặc tả kỹ thuật không chính thức không phải là chủ thể của bất kỳ ký hiệu hoặc sự hạn chế đặc biệt nào khác so với những yêu cầu như quy ước thông thường cho ngôn ngữ đó (ví dụ văn phạm và cú pháp). Trong khi không áp dụng hạn chế các chú giải, các đặc tả không chính thức cũng được yêu cầu để cung cấp các định nghĩa có ý nghĩa cho các thuật ngữ được sử dụng trong một ngữ cảnh khác hơn là chấp nhận sử dụng thông thường.

Sự khác biệt giữa tài liệu bán chính thức và chính thức chỉ là vấn đề định dạng hay trình bày: một ký hiệu bán chính thức bao gồm những thứ như một ký hiệu rõ ràng, một định dạng trình bày tiêu chuẩn hóa, v.v…Một đặc tả bán chính thức được viết theo mẫu trình bày tiêu chuẩn. Các bài trình bày nên sử dụng các thuật ngữ nhất quán khi viết bằng một ngôn ngữ thông dụng. Bài trình bày cũng có thể sử dụng ngôn ngữ nhiều cấu trúc/biểu đồ hơn (ví dụ như sơ đồ lưu lượng dữ liệu, biểu đồ chuyển trạng thái, sơ đồ mối quan hệ các thực thể, sơ đồ cấu trúc dữ liệu, và sơ đồ tiến trình hay sơ đồ cấu trúc chương trình). Cho dù có dựa trên sơ đồ hoặc ngôn ngữ thông dụng, một tập hợp các quy ước phải được sử dụng khi trình bày. Thuật ngữ này xác định một cách rõ ràng các từ đang được sử dụng một cách chính xác và không thay đổi; tương tự, định dạng chuẩn nói lên việc quan tâm đặc biệt được thực hiện công tác chuẩn bị tài liệu một cách rõ ràng nhất. Nó nên được lưu ý rằng phần cơ bản khác nhau của TSF có thể có các quy ước và kiểu biểu diễn ký hiệu bán hình thức khác nhau (miễn là số lượng “ký hiệu bán hình thức” khác nhau là nhỏ), điều này vẫn tuân thủ các khái niệm về trình bày bán hình thức.

Một đặc tả chính thức được viết dưới dạng ký hiệu dựa trên các khái niệm toán học được xây dựng tốt, và thường đi kèm với hỗ trợ giải thích (chính thức) dưới dạng văn xuôi. Những khái niệm toán học được sử dụng để định nghĩa cú pháp và ngữ nghĩa của các ký hiệu và các quy tắc chứng minh có hỗ trợ nguyên nhân về mặt logic. Các quy tắc cú pháp và ngữ nghĩa hỗ trợ một ký hiệu chính thức mà định nghĩa làm thế nào để nhận biết các cấu trúc rõ ràng và xác định ý nghĩa của chúng. Cần có bằng chứng rằng không thể là nguồn gốc mâu thuẫn, và tất cả các quy tắc hỗ trợ các ký hiệu cần phải được xác định hoặc tham chiếu.

Hình 11 cho thấy các Họ bên trong lớp này, và phân cấp của các thành phần bên trong họ.

Hình 11 - Phân cấp lớp ADV: Phát triển

11.1. Kiến trúc an toàn (ADV_ARC)

11.1.1. Mục tiêu

Các mục tiêu của họ này là phục vụ nhà phát triển để cung cấp khả năng mô tả kiến trúc an toàn của TSF. Điều này sẽ cho phép phân tích thông tin, khi kết hợp với các chứng cứ khác để biểu diễn cho các TSF, để xác nhận TSF các đạt được các thuộc tính mong muốn. Mô tả kiến trúc an toàn hỗ trợ giải thích các yêu cầu ngầm hiểu về phân tích an toàn của TOE có thể đạt được bằng cách kiểm tra các TSF, mà không có một kiến trúc rõ ràng, toàn bộ các chức năng TOE cần phải được kiểm tra.

11.1.2. Phân mức thành phần

Họ này chỉ chứa một thành phần.

11.1.3. Chú thích ứng dụng

Các thuộc tính tự bảo vệ, tách miền, và không thể vượt qua được phân biệt với chức năng an toàn thể hiện bằng Phần 2 SFR vì tự bảo vệ và không thể vượt qua phần lớn không có giao diện trực tiếp quan sát tại các TSF. Thay vào đó, chúng là thuộc tính của TSF được đạt được thông qua thiết kế của TOE và TSF, và được thực thi bởi việc thực hiện chính xác thiết kế đó.

Cách tiếp cận sử dụng họ này là dành cho nhà phát triển để thiết kế và cung cấp TSF trình bày các thuộc tính nêu trên, và để cung cấp bằng chứng (dưới dạng tài liệu) để giải thích các thuộc tính của TSF. Việc giải thích này cung cấp mức độ cụ thể như mô tả các phần tử thực thi SFR của TOE trong tài liệu thiết kế TOE. Đánh giá viên có trách nhiệm xem xét chứng cứ và, cùng với các bằng chứng khác của TOE và TSF, quyết định các thuộc tính này sẽ đạt được.

Đặc tả của thực hiện chức năng an toàn cho các SFR (trong đặc tả chức năng (ADV_FSP) và thiết kế TOE (ADV_TDS) sẽ không cần thiết có các cơ chế mô tả được sử dụng trong việc thực hiện cơ chế tự bảo vệ và không thể vượt qua (ví dụ cơ chế quản lý bộ nhớ). Do đó, cần thiết cung cấp sự đảm bảo rằng các yêu cầu được đạt được là phù hợp hơn để biểu diễn phân tách giữa sự phân rã thành phần thiết kế của TSF như thể hiện trong ADV_FSP và ADV_TDS. Điều này không có hàm ý rằng mô tả kiến trúc an toàn được gọi bởi thành phần này có thể không tham khảo hoặc sử dụng phân rã thiết kế, như dường như có rất nhiều chi tiết hiện tại trong tài liệu phân rã sẽ không có liên quan đến các đối số được cung cấp cho tài liệu mô tả kiến trúc an toàn.

Mô tả kiến trúc hợp lý có thể được dùng như phân tích tính dễ tổn thương của nhà phát triển, trong đó nó cung cấp sự biện minh cho lý do tại sao TSF là hợp lý và thực thi tất cả các SFR của nó. Tính hợp lý đạt được tại thông qua cơ chế an toàn cụ thể, chúng sẽ được kiểm tra như một phần của yêu cầu độ sâu (ATE_DPT), tại nơi tính hợp lý đạt được chỉ duy nhất thông qua kiến trúc, hành vi đó sẽ được kiểm thử như là một phần của AVA: yêu cầu đánh giá tính dễ tổn thương.

Họ này bao gồm các yêu cầu cho mô tả kiến trúc an toàn mà mô tả tính chất tự bảo vệ, tách miền, không thể vượt qua, bao gồm một mô tả về việc làm thế nào mà các tính chất này được hỗ trợ bởi các phần của TOE mà được sử dụng cho khởi tạo TSF.

Thông tin bổ sung về các thuộc tính kiến trúc an toàn về tự bảo vệ, tách miền, và không thể vượt qua có thể được tìm thấy trong Phụ lục A.1, ADV_ARC: bổ sung tài liệu về kiến trúc an toàn.

11.1.4. ADV_ARC: Mô tả kiến trúc an toàn

Các phụ thuộc:

ADV_FSP.1 Đặc tả chức năng cơ sở

ADV_TDS.1 Thiết kế cơ sở

11.1.4.1. Phần tử hành động của nhà phát triển

11.1.4.1.1. ADV_ARC.1.1D

Nhà phát triển cần thiết kế và thực hiện TOE mà các đặc trưng an toàn của TSF không thể bị vượt qua.

11.1.4.1.2. ADV_ARC.1.2D

Nhà phát triển cần thiết kế và thực hiện TSF mà có thể bảo vệ chính nó bởi sự pha trộn của các thực thể không tin cậy.

11.1.4.1.3. ADV_ARC.1.3D

Nhà phát triển cần cung cấp mô tả kiến trúc an toàn của TSF.

11.1.4.2. Các phần tử nội dung và trình bày

11.1.4.2.1. ADV_ARC.1.1C

Mô tả kiến trúc an toàn cần thực hiện tại mức độ chi tiết bằng với mô tả tóm tắt thực thi SFR trong tài liệu thiết kế TOE.

11.1.4.2.2. ADV_ARC.1.2C

Mô tả kiến trúc an toàn cần mô tả việc bảo trì các miền an toàn với sự nhất quán của TSF so với SFR.

11.1.4.2.3. ADV_ARC.1.3C

Mô tả kiến trúc an toàn cần mô tả làm thế nào tiến trình khởi tạo TSF là an toàn.

11.1.4.2.4. ADV_ARC.1.4C

Mô tả kiến trúc an toàn cần chứng minh rằng TSF bảo vệ chính nó khỏi bị can thiệp.

11.1.4.2.5. ADV_ARC.1.5C

Mô tả kiến trúc an toàn cần chứng minh rằng TSF chống lại việc vượt qua của chức năng thực thi SFR.

11.1.4.3. Phần tử hành động của đánh giá viên

11.1.4.3.1. ADV_ARC.1.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu cho nội dung và biểu diễn các chứng cứ.

11.2. Đặc tả chức năng (ADV_FSP)

11.2.1. Mục tiêu

Các yêu cầu họ dựa trên các đặc tả chức năng, trong đó mô tả các giao diện TSF (TSFI). Các TSFI bao gồm tất cả các phương tiện cho người dùng để gọi một dịch vụ từ TSF (bằng cách cung cấp dữ liệu được xử lý bởi TSF) và các câu trả lời tương ứng với những lệnh gọi dịch vụ. Nó không mô tả cách các tiến trình TSF yêu cầu các dịch vụ, cũng không mô tả cách thức truyền thông khi TSF các gọi dịch vụ từ môi trường áp dụng của nó; thông tin này được đề cập thông qua việc thiết kế TOE (ADV_TDS) và sự tin cậy của các thành phần phụ thuộc của họ (ACO_REL) tương ứng.

Họ này cung cấp đảm bảo trực tiếp bằng cách cho phép đánh giá viên hiểu cách TSF đáp ứng các SFR đã tuyên bố. Nó cũng cung cấp bảo đảm gián tiếp, như là đầu vào cho các họ và lớp đảm bảo:

● ADV_ARC, nơi mà sự mô tả của các TSFI có thể được sử dụng để đạt được sự hiểu biết tốt hơn về cách TSF được bảo vệ chống lại sự phá hủy (như tự bảo vệ chống lại sự phá hoại hay tách miền) và/hoặc bỏ qua;

● ATE, nơi mà sự mô tả của các TSFI là một đầu vào quan trọng cho cả nhà phát triển và đánh giá viên kiểm thử;

● AVA, là nơi việc mô tả của các TSFI được sử dụng để tìm kiếm các điểm yếu.

11.2.2. Phân mức thành phần

Các thành phần trong họ này được phân mức dựa trên mức độ yêu cầu chi tiết của việc mô tả TSFI, và mức độ yêu cầu về hình thức việc mô tả các TSFI.

11.2.3. Chú thích ứng dụng

Một khi các TSFI được xác định (xem A.2.1, Xác định TSFI để được hướng dẫn và ví dụ về xác định TSFI), chúng đã được mô tả. Tại các thành phần mức thấp hơn, nhà phát triển tập trung vào các tài liệu của họ (và đánh giá viên tập trung vào các phân tích của họ) trên nhiều khía cạnh an toàn liên của TOE. Ba loại TSFI được xác định, dựa trên quan hệ của các dịch vụ có sẵn thông qua đó chúng để có các SFR được tuyên bố:

● Nếu một dịch vụ có sẵn thông qua một giao diện có thể được truy nguồn từ một trong những SFR áp cho TSF, khi đó giao diện được gọi là thực thi-SFR. Lưu ý rằng có thể xảy ra trường hợp một giao diện có thể có nhiều loại dịch vụ và kết quả, một số trong đó có thể thực thi SFR và một số khác có thể không.

● Giao diện (hoặc dịch vụ có sẵn thông qua một giao diện liên quan) cho các dịch vụ mà chức năng thực thi SFR được dựa trên đó, nhưng chỉ cần thực hiện chức năng chính xác để cho các chính sách an toàn của TOE được bảo vệ, được gọi là hỗ trợ SFR.

● Giao diện với các dịch vụ trên đó chức năng thực thi SFR không có các mối phụ thuộc được gọi là không can thiệp vào SFR.

Cần lưu ý rằng để cho một giao diện được hỗ trợ SFR hay không can thiệp SFR thì nó phải không có các kết quả hay dịch vụ thực thi SFR. Ngược lại, giao diện thực thi SFR có thể có các dịch vụ hỗ trợ SFR (Ví dụ như khả năng thiết lập đồng hồ hệ thống có thể là một dịch vụ thực thi SFR của giao diện, nhưng nếu cùng một giao diện được sử dụng để hiển thị ngày hệ thống dịch vụ có thể hỗ trợ SFR). Một ví dụ về một giao diện hoàn toàn hỗ trợ SFR là một giao diện cuộc gọi hệ thống được sử dụng cả bởi người dùng và do một phần của TSF nghĩa là đang hoạt động dựa trên hành vi của người dùng.

Khi có thêm thông tin về các TSFI, mức độ lớn hơn của đảm bảo có thể đạt được với giao diện được phân loại/phân tích chính xác. Các yêu cầu được cấu trúc như vậy, ở mức thấp nhất, các thông tin cần thiết cho giao diện không can thiệp SFR là tối thiểu cần thiết để đánh giá viên quyết định theo một cách hiệu quả. Ở cấp độ cao hơn, nếu có thêm thông tin đánh giá viên sẽ có thêm sự tin cậy trong các thiết kế.

Mục đích trong việc xác định các nhãn này (Thực thi, hỗ trợ, không can thiệp với SFR) và đưa ra các yêu cầu khác nhau theo từng cái (ở các thành phần đảm bảo mức thấp hơn) để cung cấp một phép xấp xỉ bước đầu của nơi tập trung phân tích và bằng chứng mà phân tích được thực hiện dựa trên nó. Nếu các tài liệu của nhà phát triển của các giao diện TSF mô tả tất cả các giao diện theo mức quy định trong các yêu cầu đối với các giao diện thực thi SFR (có nghĩa là, nếu lập tài liệu vượt quá yêu cầu), không cần thiết phải cho phát triển tạo ra các bằng chứng mới phù hợp với yêu cầu. Tương tự như vậy, bởi vì các nhãn chỉ đơn thuần là một phương tiện phân biệt các loại giao diện trong các yêu cầu, nó không cần cho các nhà phát triển khi cập nhật các bằng chứng duy nhất để gán cho các giao diện như thực thi-SFR, hỗ trợ SFR, không can thiệp SFR. Mục đích chính của nhãn này là cho phép nhà phát triển có ít kiến thức để phát triển phương pháp luận (và hiện vật, chẳng hạn như giao diện chi tiết và tài liệu thiết kế) để cung cấp bằng chứng cần thiết mà không phải chi phí quá mức.

Các phần tử C cuối cùng của mỗi thành phần trong họ này cung cấp một sự tương ứng trực tiếp giữa các SFR và đặc tả chức năng, đó là một dấu hiệu trong đó có giao diện được sử dụng để gọi đến từng tuyên bố SFR. Trong trường hợp ST có chứa các yêu cầu chức năng như: Bảo vệ thông tin còn sót lại (FDP_RIP) - TCVN 8709-2, mà có chức năng có thể không biểu hiện chính mình trong TSFIs, các đặc tả chức năng và/hoặc các truy gốc được chờ đợi sẽ xác định các SFR này, bao gồm chúng trong các đặc tả chức năng giúp đảm bảo rằng chúng không bị mất ở mức thấp hơn của phân rã, nơi chúng có liên quan.

11.2.3.1. Chi tiết về các giao diện

Các yêu cầu định nghĩa các bộ sưu tập của các chi tiết về TSFI là được cung cấp. Với mục đích của các yêu cầu, giao diện được chỉ ra (trong mức độ chi tiết khác nhau) về mục tiêu của chúng, phương pháp sử dụng, thông số, mô tả thông số, và thông báo lỗi.

Mục đích của giao diện là một mô tả mức cao các mục tiêu chung của giao diện (ví dụ các lệnh tiến trình GUI, tiếp nhận các gói tin mạng, cung cấp đầu ra máy in v.v…).

Phương pháp sử dụng của giao diện mô tả việc làm thế nào giao diện được hỗ trợ để sử dụng. Mô tả này nên được xây dựng xung quanh các tương tác khác nhau hiện có tại giao diện đó. Ví dụ, nếu giao diện là một dấu nhắc lệnh Unix, ls, mv và cp có thể tương tác với giao diện đó. Đối với mỗi tương tác phương pháp sử dụng mô tả những gì tương tác này thực hiện, cả hành vi nhìn thấy ở giao diện (ví dụ như chương trình gọi các API, người dùng Windowns thay đổi một thiết lập trong thanh ghi v.v…) cũng như hành vi tại các giao diện khác (ví dụ như tạo ra một bản ghi phục vụ kiểm tra).

Tham số được đầu vào và đầu ra rõ ràng từ một giao diện điều khiển hành vi của giao diện đó. Ví dụ, các thông số là các đối số cung cấp cho một API; các lĩnh vực khác nhau trong một gói tin cho một giao thức mạng nhất định; các giá trị khóa riêng trong thanh ghi của Windows, các tín hiệu trên một tập hợp các chân trên một con chip, những cờ có thể được thiết lập cho lệnh ls v.v… Các tham số được “nhận diện” với một danh sách đơn giản của những gì chúng đang có.

Mô tả tham số nói lên rằng tham số này có ý nghĩa gì. Ví dụ, một mô tả tham số chấp nhận được đối với giao diện foo (i) sẽ là “tham số i là một số nguyên cho biết số lượng người dùng hiện đang đăng nhập vào hệ thống”. Một mô tả như là “tham số i là một số nguyên” là không thể chấp nhận được.

Mô tả các hành động của một giao diện mô tả những gì mà giao diện thực hiện. Điều này là chi tiết hơn mục đích trong đó, trong khi các “mục đích” giải thích lý do tại sao người ta muốn sử dụng nó, còn “hành động” cho thấy tất cả mọi thứ mà nó làm. Những hành động này có thể liên quan hoặc không liên quan đến các SFR. Trong trường hợp hành động của giao diện không có liên quan đến SFR, mô tả của nó được nói tóm tắt, có nghĩa là mô tả chỉ nêu rõ rằng nó thực sự là không liên quan đến SFR.

Các mô tả thông báo lỗi xác định các điều kiện tạo ra nó, thông điệp là gì, và ý nghĩa của bất kỳ mã lỗi nào. Một thông báo lỗi được tạo ra bởi các TSF để chỉ ra rằng một vấn đề hoặc sự bất thường ở một mức độ nào đó đã thu được. Các yêu cầu trong họ này đề cập đến các loại thông báo lỗi khác nhau:

● Một thông báo lỗi “trực tiếp” là một phản ứng an toàn có liên quan thông qua lệnh gọi TSFI cụ thể.

● Lỗi “gián tiếp” có thể không được gắn với một lời gọi TSFI cụ thể bởi vì nó là kết quả của điều kiện toàn hệ thống (ví dụ như cạn kiệt tài nguyên, gián đoạn kết nối, v.v…) Thông báo lỗi mà không liên quan bảo mật cũng được xem là “gián tiếp”.

● Lỗi “còn lại” là bất kỳ lỗi nào khác, chẳng hạn như những cái mà có thể được tham chiếu trong mã. Ví dụ, việc sử dụng đoạn mã kiểm tra điều kiện để kiểm tra các điều kiện mà xuất hiện không hợp lý (ví dụ như một kết thúc “else” sau khi một danh sách các “case”), sẽ cung cấp để tạo ra thông điệp bắt lỗi, trong TOE sử dụng, các thông báo lỗi này sẽ không bao giờ được nhìn thấy.

Một ví dụ về đặc tả chức năng được cung cấp trong A.2.3.

11.2.3.2. Các thành phần của họ này

Tăng cường bảo đảm thông qua sự tăng hoàn thiện và độ chính xác trong đặc tả giao diện được phản ánh trong các tài liệu cần thiết từ nhà phát triển như chi tiết trong các thành phần phân cấp trong họ này.

Trong đặc tả chức năng cơ bản ADV_FSP.1, chỉ các tài liệu hướng dẫn được yêu cầu có tính chất của tất cả các TSFIs và mô tả ở mức cao của TSFI thực thi SFR và hỗ trợ SFR. Để cung cấp thêm một vài đảm bảo, mà các khía cạnh “quan trọng” của TSF có tính chất chính xác tại các TSFI, nhà phát triển được yêu cầu cung cấp mục đích và phương pháp sử dụng, các tham số cho thực thi SFR và hỗ trợ SFR của TSFIs.

Tại đặc tả chức năng thực thi an toàn ADV_FSP.2, nhà phát triển được yêu cầu cung cấp các mục đích, phương pháp sử dụng, thông số, và mô tả thông số cho tất cả TSFIs. Thêm vào đó, đối với TSFI thực thi SFR, nhà phát triển cần phải mô tả các hành động thực thi SFR và các thông báo lỗi trực tiếp.

Theo đặc tả chức năng với bản tóm tắt hoàn chỉnh ADV_FSP.3, nhà phát triển phải cung cấp ngay, ngoài các thông tin cần thiết tại ADV_FSP.2, cung cấp đủ thông tin về hỗ trợ SFR và không can thiệp SFR để chứng minh rằng chúng không phải là thực thi SFR. Thêm vào đó, nhà phát triển phải lập tài liệu tất cả các thông báo lỗi trực tiếp do việc gọi các TSFI của thực thi SFR.

Theo đặc tả chức năng đầy đủ ADV_FSP.4, tất cả các TSFI - cho dù thực thi SFR, hỗ trợ SFR, không can thiệp SFR - phải được mô tả ở cùng mức độ như nhau, bao gồm tất cả các thông báo lỗi trực tiếp.

Theo đặc tả chức năng bán chính thức đầy đủ với các thông tin lỗi bổ sung ADV_FSP.5, mô tả TSFI cũng bao gồm các thông báo lỗi mà không phải là kết quả của việc gọi của TSFI.

Theo ADV_FSP.6 đặc tả chức năng bán chính thức đầy đủ với bổ sung đặc tả chính thức, ngoài các thông tin theo yêu cầu của ADV_FSP.5, tất cả các thông báo lỗi còn lại đã được bao gồm. Nhà phát triển cũng phải cung cấp mô tả chính thức của TSFI. Điều này cung cấp một cái nhìn khác của TSFI có thể phơi bày các đặc tả không nhất quán hay không hoàn tất.

11.2.4. ADV_FSP.1 Đặc tả chức năng cơ sở

Các mối phụ thuộc: không có sự phụ thuộc nào

11.2.4.1. Các phần tử của nhà phát triển

11.2.4.1.1. ADV_FSP.1.1D

Nhà phát triển cần cung cấp đặc tả chức năng.

11.2.4.1.2. ADV_FSP.1.2D

Nhà phát triển cần cung cấp truy vết từ đặc tả chức năng đến các SFR.

11.2.4.2. Các phần tử nội dung và trình bày

11.2.4.2.1. ADV_FSP.1.1C

Đặc tả chức năng cần mô tả mục tiêu và phương pháp sử dụng cho mỗi TSFI của thực thi SFR và hỗ trợ SFR.

11.2.4.2.2. ADV_FSP.1.2C

Đặc tả chức năng cần xác định tất cả các tham số liên quan với mỗi TSFI của thực thi SFR và hỗ trợ SFR.

11.2.4.2.3. ADV_FSP.1.3C

Đặc tả chức năng cần cung cấp sở cứ cho việc phân nhóm rõ ràng của các giao diện như không can thiệp SFR.

11.2.4.2.4. ADV_FSP.1.4C

Truy vết cần chứng minh rằng truy vết SFR theo TSFI trong đặc tả chức năng.

11.2.4.3. Các phần tử hành động của đánh giá viên

11.2.4.3.1. ADV_FSP.1.1E

Đánh giá viên cần xác nhận rằng thông tin cung cấp sự phù hợp với tất cả các yêu cầu cho nội dung và trình bày các chứng cứ.

11.2.4.3.2. ADV_FSP.1.2E

Đánh giá viên cần quyết định rằng đặc tả chức năng được khởi tạo chính xác và hoàn toàn của các SFR.

11.2.5. ADV_FSP.2 Đặc tả chức năng thực thi an toàn

Các phụ thuộc: ADV_TDS.1 Thiết kế cơ sở

11.2.5.1. Phần tử hành động của nhà phát triển

11.2.5.1.1. ADV_FSP.2.1D

Nhà phát triển cần cung cấp đặc tả chức năng

11.2.5.1.2. ADV_FSP.2.2D

Nhà phát triển cần cung cấp truy vết từ đặc tả chức năng đến các SFR.

11.2.5.2. Các phần tử nội dung và trình bày

11.2.5.2.1. ADV_FSP.2.1C

Đặc tả chức năng cần biểu diễn toàn bộ TSF.

11.2.5.2.2. ADV_FSP.2.2C

Đặc tả chức năng cần mô tả mục tiêu và phương pháp sử dụng cho tất cả TSFI.

11.2.5.2.3. ADV_FSP.2.3C

Đặc tả chức năng cần xác định và mô tả tất cả các tham số liên quan đến mỗi TSFI.

11.2.5.2.4. ADV_FSP.2.4C

Với mỗi TSFI thực thi SFR, đặc tả chức năng cần mô tả các hành động thực thi SFR liên quan đến mỗi TSFI.

11.2.5.2.5. ADV_FSP.2.5C

Với các TSFI thực thi SFR, đặc tả chức năng cần mô tả các thông báo lỗi trực tiếp có kết quả từ xử lý liên quan với các hành động thực thi SFR.

11.2.5.2.6. ADV_FSP.2.6C

Truy vết cần chứng minh rằng truy vết SFR từ các TSFI theo các đặc tả chức năng.

11.2.5.3. Các phần tử hành động của đánh giá viên

11.2.5.3.1. ADV_FSP.2.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các bằng chứng.

11.2.5.3.2. ADV_FSP.2.2E

Đánh giá viên cần quyết định rằng đặc tả chức năng là một sự khởi tạo chính xác và hoàn toàn của các SFR.

11.2.6. ADV_FSP.3 Đặc tả chức năng với tóm tắt đầy đủ

Các phụ thuộc: ADV_TDS.1 Thiết kế cơ sở

11.2.6.1. Phần tử hành động của nhà phát triển

11.2.6.1.1. ADV_FSP.3.1D

Nhà phát triển cần cung cấp đặc tả chức năng.

11.2.6.1.2. ADV_FSP.3.2D

Nhà phát triển cần cung cấp truy vết từ đặc tả chức năng đến các SFR.

11.2.6.2. Các phần tử nội dung và trình bày

11.2.6.2.1. ADV_FSP.3.1C

Đặc tả chức năng cần biểu diễn đầy đủ TSF

11.2.6.2.2. ADV_FSP.3.2C

Đặc tả chức năng cần mô tả mục tiêu và phương pháp sử dụng cho tất cả TSFI.

11.2.6.2.3. ADV_FSP.3.3C

Đặc tả chức năng cần xác định và mô tả tất cả các tham số liên quan với mỗi TSFI.

11.2.6.2.4. ADV_FSP.3.4C

Với mỗi TSFI của thực thi SFR, đặc tả chức năng cần mô tả các hành động thực thi SFR liên quan với TSFI.

11.2.6.2.5. ADV_FSP.3.5C

Với mỗi TSFI thực thi SFR, đặc tả chức năng cần mô tả trực tiếp các thông báo lỗi thu được từ các kết quả và ngoại lệ liên quan đến các lệnh gọi của TSFI.

11.2.6.2.6. ADV_FSP.3.6

Đặc tả chức năng cần tóm tắt các hành động hỗ trợ SFR và không can thiệp SFR liên quan đến mỗi TSFI.

11.2.6.2.7. ADV_FSP.3.7C

Truy vết cần chứng minh rằng SFR truy vết từ TSFI trong đặc tả chức năng.

11.2.6.3. Các phần tử hành động của đánh giá viên

11.2.6.3.1. ADV_FSP.3.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày chứng cứ.

11.2.6.3.2. ADV_FSP.3.2E

Đánh giá viên cần quyết định rằng đặc tả chức năng là chính xác và đầy đủ của các SFR.

11.2.7. ADV_FSP.4 Đặc tả chức năng đầy đủ

Các phụ thuộc: ADV_TDS.1 Thiết kế cơ sở

11.2.7.1. Phần tử hành động của nhà phát triển

11.2.7.1.1. ADV_FSP.4.1D

Nhà phát triển cần cung cấp đặc tả chức năng.

11.2.7.1.2. ADV_FSP.4.2D

Nhà phát triển cần cung cấp truy vết từ đặc tả chức năng đến các SFR.

11.2.7.2. Các phần tử nội dung và trình bày

11.2.7.2.1. ADV_FSP.4.1C

Đặc tả chức năng cần biểu diễn đầy đủ TSF.

11.2.7.2.2. ADV_FSP.4.2C

Đặc tả chức năng cần mô tả mục tiêu và phương pháp sử dụng của tất cả TSFI.

11.2.7.2.3. ADV_FSP.4.3C

Đặc tả chức năng cần xác định và mô tả tất cả các tham số liên quan với mỗi TSFI.

11.2.7.2.4. ADV_FSP.4.4C

Đặc tả chức năng cần mô tả tất cả các hành động liên quan với mỗi TSFI.

11.2.7.2.5. ADV_FSP.4.5C

Đặc tả chức năng cần mô tả tất cả các thông báo lỗi trực tiếp mà có kết quả từ việc gọi đến mối TSFI.

11.2.7.2.6. ADV_FSP.4.6C

Truy vết cần chứng minh rằng các SFR truy vết TSFI trong đặc tả chức năng.

11.2.7.3. Các phần tử hành động của đánh giá viên

11.2.7.3.1. ADV_FSP.4.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các chứng cứ.

11.2.7.3.2. ADV_FSP.4.2E

Đánh giá viên cần quyết định rằng đặc tả chức năng là chính xác và đầy đủ của các SFR.

11.2.8. ADV_FSP.5. Đặc tả chức năng bán chính thức đầy đủ với thông tin lỗi bổ sung

Các phụ thuộc:

ADV_TDS.1 Thiết kế cơ sở

ADV_IMP.1 Biểu diễn thực hiện của TSF.

11.2.8.1. Phần tử hành động của nhà phát triển

11.2.8.1.1. ADV_FSP.5.1D

Nhà phát triển cần cung cấp đặc tả chức năng.

11.2.8.1.2. ADV_FSP.5.2D

Nhà phát triển cần cung cấp truy vết từ đặc tả chức năng đến các SFR.

11.2.8.2. Các phần tử nội dung và trình bày

11.2.8.2.1. ADV_FSP.5.1C

Đặc tả chức năng cần biểu diễn hoàn toàn TSF.

11.2.8.2.2. ADV_FSP.5.2C

Đặc tả chức năng cần mô tả TSFI sử dụng kiểu bán hình thức.

11.2.8.2.3. ADV_FSP.5.3C

Đặc tả chức năng cần mô tả mục tiêu và phương pháp sử dụng cho tất cả TSFI.

11.2.8.2.4. ADV_FSP.5.4C

Đặc tả chức năng cần xác nhận và mô tả tất cả các tham số liên quan với mối TSFI.

11.2.8.2.5. ADV_FSP.5.5C

Đặc tả chức năng cần mô tả tất cả các hành động liên quan đến mỗi TSFI.

11.2.8.2.6. ADV_FSP.5.6C

Đặc tả chức năng cần mô tả tất cả các thông báo lỗi trực tiếp mà có kết quả từ việc gọi đến từ mối TSFI.

11.2.8.2.7. ADV_FSP.5.7C

Đặc tả chức năng cần mô tả tất cả các thông báo lỗi mà không phải được gọi đến từ TSFI.

11.2.8.2.8. ADV_FSP.5.8C

Đặc tả chức năng cần cung cấp sở cứ cho mỗi thông báo lỗi chứa trong thực hiện TSF nhưng kết quả không phải từ lệnh gọi đến TSFI.

11.2.8.2.9. ADV_FSP.5.9C

Truy vết cần chứng minh rằng SFR truy vết đến các TSFI trong các đặc tả chức năng.

11.2.8.3. Các phần tử hành động của đánh giá viên

11.2.8.3.1. ADV_FSP.5.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các chứng cứ.

11.2.8.3.2. ADV_FSP.5.2E

Đánh giá viên cần quyết định rằng đặc tả chức năng là đầy đủ và chính xác của các SFR.

11.2.9. ADV_FSP.6 Đặc tả chức năng bán chính thức đầy đủ với đặc tả chính thức bổ sung

Các phụ thuộc:

ADV_TDS.1 Thiết kế cơ sở

ADV_IMP.1 Biểu diễn thực hiện của TSF

11.2.9.1. Phần tử hành động của nhà phát triển

11.2.9.1.1. ADV_FSP.6.1D

Nhà phát triển cần cung cấp đặc tả chức năng.

11.2.9.1.2. ADV_FSP.6.2D

Nhà phát triển cần cung cấp biểu diễn chính thức của đặc tả chức năng của TSF.

11.2.9.1.3. ADV_FSP.6.3D

Nhà phát triển cần cung cấp truy vết từ đặc tả chức năng đến các SFR.

11.2.9.2. Các phần tử nội dung và trình bày

11.2.9.2.1. ADV_FSP.6.1C

Đặc tả chức năng cần biểu diễn đầy đủ TSF.

11.2.9.2.2. ADV_FSP.6.2C

Đặc tả chức năng cần mô tả TSFI sử dụng kiểu chính thức.

11.2.9.2.3. ADV_FSP.6.3C

Đặc tả chức năng cần mô tả mục tiêu và phương pháp sử dụng tất cả TSFI.

11.2.9.2.4. ADV_FSP.6.4C

Đặc tả chức năng cần chỉ ra và mô tả tất cả các tham số liên quan với mối TSFI.

11.2.9.2.5. ADV_FSP.6.5C

Đặc tả chức năng cần mô tả tất cả các hành động liên quan đến mỗi TSFI.

11.2.9.2.6. ADV_FSP.6.6C

Đặc tả chức năng cần mô tả tất cả các thông báo lỗi trực tiếp mà kết quả từ lệnh gọi của mỗi TSFI.

11.2.9.2.7. ADV_FSP.6.7C

Đặc tả chức năng cần mô tả tất cả thông báo lỗi chứa trong biểu diễn thực hiện TSF.

11.2.9.2.8. ADV_FSP.6.8C

Đặc tả chức năng cần cung cấp các sở cứ cho mỗi thông báo lỗi chứa trong việc thực hiện TSF mà không được mô tả trong việc giải trình vì sao đặc tả chức năng không liên quan với TSFI.

11.2.9.2.9. ADV_FSP.6.9C

Trình bày chính thức của các đặc tả chức năng của TSF cần mô tả TSF sử dụng kiểu chính thức, hỗ trợ bởi các văn bản giải thích không chính thức tại các nơi phù hợp.

11.2.9.2.10. ADV_FSP.6.10C

Truy vết cần chứng minh rằng SFR truy vết TSFI trong đặc tả chức năng.

11.2.9.3. Các phần tử hành động của đánh giá viên

11.2.9.3.1. ADV_FSP.6.1E

Đánh giá viên cần xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày các chứng cứ.

11.2.9.3.2. ADV_FSP.6.2E

Đánh giá viên cần quyết định rằng đặc tả chức năng là đầy đủ và chính xác với SFR.

11.3. Biểu diễn triển khai (ADV_IMP)

11.3.1. Mục tiêu

Chức năng của họ biểu diễn triển khai (ADV_IMP) là cho nhà phát triển làm sẵn sàng biểu diễn triển khai (và, ở mức độ cao hơn, việc tự thực hiện) của TOE trong một hình thức có thể được phân tích bằng đánh giá viên. Biểu diễn triển khai được sử dụng trong các hoạt động phân tích cho các họ khác (ví dụ, phân tích thiết kế TOE) để chứng minh rằng TOE sự phù hợp thiết kế của nó và để cung cấp một cơ sở cho việc phân tích ở các vùng khác của đánh giá (ví dụ, việc tìm kiếm các điểm yếu). Các biểu diễn triển khai được chờ đợi ở dưới dạng để chụp các hoạt động nội bộ chi tiết của TSF. Đây có thể là mã nguồn phần mềm, mã nguồn phần sụn, sơ đồ phần cứng và/hoặc thiết kế phần cứng IC mã ngôn ngữ hoặc dữ liệu lớp.

11.3.2. Phân mức thành phần

Thành phần trong họ này được phân mức dựa trên số lượng thực hiện được ánh xạ vào mô tả thiết kế TOE.

11.3.3. Chú thích ứng dụng

Sơ đồ mã nguồn hoặc phần cứng và/hoặc thiết kế phần cứng IC mã ngôn ngữ hoặc bố trí dữ liệu được sử dụng để xây dựng phần cứng thực tế là những ví dụ của các bộ phận của biểu diễn triển khai. Điều quan trọng cần lưu ý rằng trong khi các biểu diễn triển khai phải được sẵn sàng cho đánh giá viên, điều này không có nghĩa là đánh giá viên cần phải sở hữu đại diện đó. Ví dụ, nhà phát triển có thể yêu cầu đánh giá viên xem xét lại các biểu diễn triển khai tại một trang web lựa chọn của nhà phát triển.

Các biểu diễn triển khai toàn bộ được sẵn sàng để đảm bảo rằng các hoạt động phân tích không được rút ngắn do thiếu thông tin. Tuy vậy, điều này không có hàm ý rằng tất cả các đại diện được xem xét khi thực hiện phân tích các hoạt động đang được thực hiện. Điều này không thực tế ở hầu hết các trường hợp, thêm vào đó là nó rất có thể sẽ không dẫn đến một TOE có mức đảm bảo cao hơn so với mẫu mục tiêu của biểu diễn triển khai. Biểu diễn triển khai được làm sẵn để cho phép phân tích các phân tích phân rã thiết kế TOE khác (ví dụ như chức tả chức năng, thiết kế TOE), và để đạt được sự tin cậy mà các chức năng an toàn được mô tả ở mức độ cao hơn trong việc thiết kế thực sự xuất hiện để được thực hiện trong TOE.

Quy ước trong một số dạng của các biểu diễn triển khai có thể làm cho nó khó hoặc không thể xác định từ chính các biểu diễn triển khai những gì kết quả thực tế của việc biên dịch hoặc thông dịch thời gian thực. Ví dụ, chỉ thị, trình biên dịch cho các trình biên dịch ngôn ngữ C sẽ là nguyên nhân để các trình biên dịch loại trừ hoặc bao gồm toàn bộ các phần của mã này. Vì lý do này, điều quan trọng là các công cụ cung cấp “thêm” thông tin hoặc công cụ liên quan (kịch bản, trình biên dịch, vv) được cung cấp để các biểu diễn triển khai có thể được xác định chính xác.

Mục đích của các ánh xạ giữa các biểu diễn triển khai và mô tả thiết kế TOE là để trợ giúp phân tích của đánh giá viên. Các hoạt động nội bộ của TOE có thể được hiểu rõ hơn khi thiết kế TOE được phân tích với các phần tương ứng của biểu diễn triển khai. Lập bản đồ phục vụ như một chỉ mục trong các biểu diễn triển khai. Tại các thành phần thấp hơn, chỉ có một tập hợp con của các biểu diễn triển khai được ánh xạ tới các mô tả thiết kế TOE. Bởi vì sự không chắc chắn trong đó phần của biểu diễn triển khai sẽ cần ánh xạ như thế, nhà phát triển có thể chọn một trong hai ánh xạ đến biểu diễn triển khai toàn bộ trước, hoặc phải chờ đợi để xem những phần của biểu diễn triển khai, đánh giá viên yêu cầu để được ánh xạ.

Các biểu diễn triển khai được thao tác bởi nhà phát triển dưới các hình thức thích hợp cho chuyển đổi để thực hiện trong thực tế. Ví dụ, nhà phát triển có thể làm việc với các tập tin có chứa mã nguồn, mà là cuối cùng đã được biên dịch để trở thành một phần của TSF. Nhà phát triển làm cho biểu diễn triển khai sẵn sàng dưới dạng để sử dụng bởi nhà phát triển, do đó đánh giá viên có thể sử dụng kỹ thuật tự động trong phân tích. Điều này cũng làm tăng sự tin cậy rằng việc kiểm tra các biểu diễn triển khai thực sự là một trong những sử dụng trong sản xuất của các TSF (như trái ngược với các trường hợp được cung cấp theo định dạng trình bày thay thế, như một phần mềm xử lý văn bản). Cần lưu ý rằng các hình thức khác của các biểu diễn triển khai cũng có thể được sử dụng bởi nhà phát triển, các mẫu này được cung cấp. Mục tiêu tổng thể là để cung cấp cho đánh giá viên với các thông tin sẽ phát huy tối đa hiệu quả của các nỗ lực phân tích của đánh giá viên.

Một số hình thức của biểu diễn triển khai có thể yêu cầu thêm thông tin, bởi vì họ giới thiệu những rào cản đáng kể cho sự hiểu biết và phân tích. Ví dụ như mã nguồn “bị che khuất” hoặc mã nguồn đã được làm cho khó hiểu theo những cách khác do đó nó ngăn cản sự hiểu biết và/hoặc phân tích. Các dạng biểu diễn triển khai thường do kết quả của nhà phát triển TOE đưa ra một phiên bản của biểu diễn triển khai và chạy một chương trình bị che khuất hay làm cho khó hiểu trong đó. Trong khi đại diện bị che khuất là những gì được biên dịch và có thể được gần hơn để thực hiện (về mặt cấu trúc) so với ban đầu, đại diện bị làm cho khó hiểu, cung cấp mã khó hiểu có thể tiêu tốn thời gian đáng kể khi thực hiện việc phân tích liên quan đến đại diện. Khi các hình thức biểu diễn được tạo ra, các thành phần yêu cầu chi tiết về các công cụ liệm/ thuật toán che khuất được sử dụng để đại diện không bị che khuất có thể được cung cấp, và các thông tin bổ sung có thể được sử dụng để đạt được sự tin cậy về tiến trình che khuất không làm tổn hại bất kỳ chức năng an toàn nào.

11.3.4. ADV_IMP.1 Biểu diễn triển khai của TSF

Các phụ thuộc:

ADV_TDS.3 Thiết kế mô đun cơ sở

ALC_TAT.1 Các công cụ phát triển được xác định rõ ràng

11.3.4.1. Phần tử hành động của nhà phát triển

11.3.4.1.1. ADV_IMP.1.1D

Nhà phát triển cần tạo ra sự sẵn sàng của biểu diễn triển khai cho toàn bộ TSF.

11.3.4.1.2. ADV_IMP.1.2D

Nhà phát triển cần cung cấp ánh xạ giữa mô tả thiết kế TOE và ví dụ của biểu diễn triển khai.

11.3.4.2. Các phần tử nội dung và trình bày

11.3.4.2.1. ADV_IMP.1.1C

Biểu diễn triển khai cần định nghĩa TSF theo một mức độ chi tiết như TSF có thể được tạo ra mà không cần các quyết định thiết kế thêm nào.

11.3.4.2.2. ADV_IMP.1.2C

Biểu diễn triển khai cần dưới dạng được sử dụng bởi các cá nhân phát triển.

11.3.4.2.3. ADV_IMP.1.3C

Ánh xạ giữa mô tả thiết kế TOE và ví dụ thực hiện cần chứng minh sự đáp ứng của nó.

11.3.4.3. Các phần tử hành động của đánh giá viên

11.3.4.3.1. ADV_IMP.1.1E

Đánh giá viên cần xác nhận rằng, với các mẫu được lựa chọn của biểu diễn triển khai, thông tin được cung cấp đáp ứng tất cả nội dung và trình bày các chứng cứ.

11.3.5. ADV_IMP.2 Ánh xạ đầy đủ của biểu diễn triển khai của TSF.

Các phụ thuộc:

ADV_TDS.3 Thiết kế mô đun cơ sở

ALC_TAT.1 Các công cụ phát triển được định nghĩa rõ ràng

ALC_CMS.5 Hỗ trợ nâng cao

11.3.5.1. Các hành động của nhà phát triển

11.3.5.1.1. ADV_IMP.2.1D

Nhà phát triển cần tạo ra biểu diễn triển khai sẵn sàng cho toàn bộ TSF.

11.3.5.1.2. ADV_IMP.2.2D

Nhà phát triển cần cung cấp ánh xạ giữa mô tả thiết kế TOE và toàn bộ biểu diễn triển khai.

11.3.5.2. Các phần tử nội dung và trình bày

11.3.5.2.1. ADV_IMP.2.1C

Biểu diễn thực hiện cần xác định TSF theo các mức chi tiết mà TSF có thể được tạo ra mà không cần các quyết định thiết kế thêm.

11.3.5.2.2. ADV_IMP.2.2C

Biểu diễn triển khai cần được định dạng dưới dạng được bởi nhà phát triển.

11.3.5.2.3. ADV_IMP.2.3C

Ánh xạ giữa mô tả thiết kế TOE và toàn bộ biểu diễn triển khai cần chứng minh sự đáp ứng.

11.3.5.3. Các phần tử hành động của đánh giá viên

11.3.5.3.1. ADV_IMP.2.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các chứng cứ.

11.4. Nội bộ TSF (ADV_INT)

11.4.1. Mục tiêu

Họ này đề cập đến việc đánh giá cấu trúc trong của TSF. Một TSF có bản chất được cấu trúc rõ ràng sẽ dễ dàng hơn để thực hiện và ít có khả năng chứa lỗ hổng mà có thể dẫn đến các điểm yếu, nó cũng dễ dàng hơn để duy trì không cần đưa vào các lỗ hổng.

11.4.2. Phân mức thành phần

Các thành phần trong họ này được phân mức trên cơ sở số lượng cấu trúc và giảm thiểu độ phức tạp cần thiết. Tập con được cấu trúc rõ ràng ADV_INT.1 của các chỗ bản chất TSF yêu cầu bản chất được cấu trúc rõ ràng trên chỉ các phần lựa chọn của TSF. Thành phần này không bao gồm trong EAL bởi vì thành phần này được xem xét để sử dụng trong các trường hợp đặc biệt (ví dụ, người tài trợ có một mối quan tâm cụ thể về một mô-đun mã hóa, mà bị cô lập với phần còn lại của TSF) và sẽ không được áp dụng rộng rãi. Ở mức độ tiếp theo, các yêu cầu về bản chất được cấu trúc rõ ràng được đặt trên toàn bộ TSF. Cuối cùng, giảm thiểu độ phức tạp được giới thiệu trong các thành phần cao nhất.

11.4.3. Chú thích ứng dụng

Những yêu cầu này, khi áp dụng cho các cấu trúc bên trong của TSF, thường dẫn đến những cải thiện mà hỗ trợ cả nhà phát triển và đánh giá viên trong sự hiểu biết về TSF, và cũng cung cấp cơ sở cho việc thiết kế và đánh giá các bộ kiểm thử. Hơn nữa, nâng cao hiểu biết của các TSF sẽ hỗ trợ nhà phát triển đơn giản hóa bảo trì nó.

Các yêu cầu trong họ này được trình bày ở mức độ khá trừu tượng. Sự đa dạng của TOE làm cho nó không thể biên soạn thành bất cứ điều gì cụ thể hơn là “có cấu trúc rõ ràng” hay “phức tạp tối thiểu”. Sự biện minh về cấu trúc và tính phức tạp được chờ đợi được cung cấp từ các kỹ thuật đặc biệt được sử dụng trong các TOE. Ví dụ, phần mềm có thể được xem xét cấu trúc rõ ràng khi nó thể hiện những đặc điểm được trích dẫn trong các ngành kỹ nghệ phần mềm. Các thành phần bên trong họ này gọi để xác định các tiêu chuẩn để đo các tính chất được cấu trúc tốt và không quá phức tạp.

11.4.4. ADV_INT.1 Tập con cấu trúc rõ ràng của nội bộ TSF

Các phụ thuộc:

ADV_IMP.1 Biểu diễn triển khai của TSF

ADV_TDS.3 Thiết kế mô đun cơ sở

ALC_TAT.1 Các công cụ phát triển được định nghĩa rõ ràng

11.4.4.1. Các mục tiêu

Mục tiêu của thành phần này là cung cấp theo cách làm cho việc yêu cầu các phần đặc biệt của TSF được cấu trúc rõ ràng.

Theo dự định toàn bộ TSF đã được thiết kế và thực hiện bằng cách sử dụng các nguyên tắc kỹ thuật phù hợp, nhưng phân tích được thực hiện dựa trên một tập con cụ thể.

11.4.4.2. Chú thích ứng dụng

Thành phần này yêu cầu tác giả PP và ST sẽ được gán đầy đủ với các tập con của TSF. Tập con này sẽ được xác định theo dạng bên trong của TSF tại bất kỳ lớp trừu tượng nào. Ví dụ:

a) các phần tử cấu trúc của TSF được xác định trong thiết kế TOE (ví dụ: “Nhà phát triển cần thiết kế và thực hiện kiểm tra hệ thống con theo cách mà nó có bản chất cấu trúc rõ ràng”)

b) thực hiện (ví dụ: “nhà phát triển cần thiết kế và thực hiện các tập tin encrypt.c và decrypt.c theo cách chúng có bản chất cấu trúc rõ ràng.” hoặc “Nhà phát triển cần thiết kế và thực hiện chíp vi mạch 6.227 theo cách mà nó có bản chất cấu trúc rõ ràng”.”)

Điều này dường như chưa sẵn sàng thực hiện bằng cách tham khảo các tuyên bố SFR (ví dụ: “Nhà phát triển cần thiết kế và thực hiện phần của TSF để cung cấp khả năng nặc danh như được định nghĩa trong FPR_ANO.2 như vậy mà nó có bản chất cấu trúc rõ ràng.”) Bởi vì điều này không chỉ ra nơi tập trung phân tích.

Thành phần này có giá trị giới hạn và sẽ thích hợp trong trường hợp mà người sử dụng/chủ thể của các mã độc hại bị hạn chế hoặc truy cập kiểm soát truy nhập chặt chẽ các TSFI hoặc nơi có phương tiện bảo vệ khác (ví dụ, miền tách) để đảm bảo tập con được lựa chọn của TSF không thể bị ảnh hưởng bởi phần còn lại của TSF (ví dụ, các chức năng mã hóa, mà bị cô lập với phần còn lại của TS, có cấu trúc rõ ràng).

11.4.4.3. Phần tử hành động của nhà phát triển

11.4.4.3.1. ADV_INT.1.1D

Nhà phát triển cần thiết kế và thực hiện [gán: tập con của TSF] theo đó nó có bản chất được cấu trúc rõ ràng.

11.4.4.3.2. ADV_INT.1.2D

Nhà phát triển cần cung cấp mô tả và biện minh cho nội bộ.

11.4.4.4. Các phần tử nội dung và trình bày

11.4.4.4.1. ADV_INT.1.1C

Biện minh cần giải thích các bản chất được sử dụng để xem xét ý nghĩa của “cấu trúc rõ ràng”.

11.4.4.4.2. ADV_INT.1.2C

Mô tả các tính chất TSF cần chứng minh rằng tập con được gán của TSF là được cấu trúc rõ ràng.

11.4.4.5. Các phần tử hành động của đánh giá viên

11.4.4.5.1. ADV_INT.1.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày các chứng cứ.

11.4.4.5.2. ADV_INT.1.2E

Đánh giá viên cần thực hiện phân tích bản chất dựa trên các tập con được gán của TSF.

11.4.5. ADV_INT.2 Nội bộ với cấu trúc rõ ràng

Các phụ thuộc:

ADV_IMP.1 Biểu diễn triển khai của TSF.

ADV_TDS.3 Thiết kế mô đun cơ sở

ALC_TAT.1 Các công cụ phát triển được định nghĩa rõ ràng.

11.4.5.1. Mục tiêu

Mục tiêu của thành phần này là cung cấp theo cách làm cho việc yêu cầu TSF được cấu trúc rõ ràng. Theo dự định toàn bộ TSF đã được thiết kế và thực hiện bằng cách sử dụng các nguyên tắc kỹ thuật phù hợp.

11.4.5.2. Chú thích ứng dụng

Sự biện minh về tính đầy đủ của cấu trúc và sự phức tạp được chờ đợi sẽ nhận được từ kỹ thuật đặc biệt được sử dụng trong TOE. Thành phần này gọi để xác định các tiêu chuẩn để đo đạc tính chất của các cấu trúc rõ ràng.

11.4.5.3. Phần tử hành động của nhà phát triển

11.4.5.3.1. ADV_INT.2.1D

Nhà phát triển cần thiết kế và thực hiện toàn bộ TSF mà bản chất có cấu trúc rõ ràng.

11.4.5.3.2. ADV_INT.2.2D

Nhà phát triển cần cung cấp mô tả và biện minh cho bản chất.

11.4.5.4. Các phần tử nội dung và trình bày

11.4.5.4.1. ADV_INT.2.1C

Sự biện minh cần mô tả các tính chất sử dụng để xem xét ý nghĩa của “cấu trúc rõ ràng”.

11.4.5.4.2. ADV_INT.2.2C

Mô tả bản chất TSF cần chứng minh rằng toàn bộ TSF có cấu trúc rõ ràng.

11.4.5.5. Các phần tử hành động của đánh giá viên

11.4.5.5.1. ADV_INT.2.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng đầy đủ các yêu cầu cho nội dung và trình bày chứng cứ.

11.4.5.5.2. ADV_INT.2.2E

Đánh giá viên cần thực hiện phân tích bản chất bên trong TSF.

11.4.6. ADV_INT.3 Nội bộ với độ phức tạp tối thiểu

Các phụ thuộc:

ADV_IMP.1 Biểu diễn triển khai của TSF

ADV_TDS.3 Thiết kế mô đun cơ sở

ALC_TAT.1 Các công cụ phát triển được định nghĩa rõ ràng

11.4.6.1. Mục tiêu

Mục tiêu của thành phần này là cung cấp theo cách làm cho việc yêu cầu TSF được cấu trúc rõ ràng và sự phức tạp nhỏ nhất. Theo dự định toàn bộ TSF đã được thiết kế và thực hiện bằng cách sử dụng các nguyên tắc kỹ thuật phù hợp.

11.4.6.2. Chú thích ứng dụng

Sự biện minh về tính đầy đủ của cấu trúc và sự phức tạp được chờ đợi sẽ nhận được từ kỹ thuật đặc biệt được sử dụng trong TOE. Thành phần này gọi để xác định các tiêu chuẩn để đo đạc cấu trúc và độ phức tạp.

11.4.6.3. Phần tử hành động của nhà phát triển

11.4.6.3.1. ADV_INT.3.1D

Nhà phát triển cần thiết kế và thực hiện toàn bộ TSF mà bản chất được cấu trúc rõ ràng.

11.4.6.3.2. ADV_INT.3.2D

Nhà phát triển cần cung cấp mô tả và biện minh cho bản chất

11.4.6.4. Các phần tử nội dung và trình bày

11.4.6.4.1. ADV_INT.3.1C

Sự biện minh cần mô tả các tính chất được sử dụng để xem xét ý nghĩa của “Cấu trúc rõ ràng” và “phức tạp”.

11.4.6.4.2. ADV_INT.3.2C

Mô tả các bản chất của TSF cần chứng minh rằng toàn bộ TSF được cấu trúc rõ ràng và không phức tạp quá.

11.4.6.5. Các phần tử hành động của đánh giá viên

11.4.6.5.1. ADV_INT.3.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày các chứng cứ.

11.4.6.5.2. ADV_INT.3.2E

Đánh giá viên cần thực hiện phân tích bản chất của trên toàn TSF.

11.5. Mô hình hóa chính sách an toàn (ADV_SPM)

11.5.1. Mục tiêu

Mục tiêu của họ này là cung cấp sự bảo đảm bổ sung từ sự phát triển của một mô hình chính sách an toàn chính thức của TSF, và thiết lập một sự tương ứng giữa các đặc tả chức năng và mô hình chính sách an toàn. Bảo vệ sự nhất quán nội bộ mô hình chính sách an toàn được chờ đợi để thiết lập các nguyên tắc an toàn từ các tính chất của nó bằng một chứng minh toán học.

11.5.2. Phân mức thành phần

Họ này chứa chỉ một thành phần.

11.5.3. Chú thích ứng dụng

Bất cập trong một TOE có thể dẫn đến kết quả là thất bại trong việc tìm hiểu các yêu cầu an toàn và, từ một thiếu sót trong thực hiện các yêu cầu an toàn. Việc xác định các yêu cầu an toàn đầy đủ để đảm bảo sự hiểu biết của họ có thể có vấn đề bởi vì các định nghĩa cần phải đủ chính xác để tránh kết quả không mong muốn hoặc sai sót trong quá trình thực hiện của TOE. Qua việc thực hiện, thiết kế, và quy trình soát xét, các yêu cầu bảo vệ được mô hình hóa có thể được sử dụng như là thiết kế chính xác và hướng dẫn thực hiện, qua đó cung cấp đảm bảo tăng lên đáp ứng các yêu cầu an toàn được thỏa mãn bởi TOE. Độ chính xác của mô hình và kết quả hướng dẫn là dấu hiệu cải thiện đáng kể bằng việc tạo các mô hình trong một ngôn ngữ chính thức và xác minh các yêu cầu an toàn bởi chứng minh hình thức.

Việc tạo ra một mô hình chính sách an toàn chính thức giúp xác định và loại bỏ các phần tử chính sách an toàn không rõ ràng, không phù hợp, mâu thuẫn, hoặc không thể thực thi. Chỉ khi TOE đã được xây dựng, mô hình chính thức phục vụ các nỗ lực đánh giá góp phần cho các phán xét của đánh giá viên về việc nhà phát triển có hiểu biết thế nào về chức năng an toàn đang được thực hiện và có sự nhất quán giữa yêu cầu an toàn và thiết kế TOE. Sự tin cậy trong mô hình này được đi kèm với bằng chứng rằng nó không chứa mâu thuẫn.

Mô hình chính sách an toàn chính thức là một bài thuyết trình chính thức chính xác về các khía cạnh quan trọng của an toàn và mối quan hệ của chúng với các hành vi của TOE, nó xác định tập các quy tắc và thông lệ điều chỉnh làm thế nào TSF quản lý, bảo vệ, và kiểm soát các tài nguyên hệ thống. Mô hình này bao gồm việc thiết lập các hạn chế và các thuộc tính mà chỉ ra làm thế nào thông tin và tài nguyên tính toán bị ngăn không cho sử dụng khi vi phạm các SFR, kèm theo một tập thuyết phục các đối số kỹ thuật cho thấy rằng những hạn chế này và các thuộc tính đóng một vai trò quan trọng trong việc thực thi SFR. Nó bao gồm cả hình thức hóa mà biểu diễn các chức năng an toàn, cũng như các văn bản phụ trợ để giải thích các mô hình và cung cấp cho nó với ngữ cảnh. Các hành vi an toàn của TSF được mô hình hóa cả về hành vi bên ngoài (tức là làm thế nào TSF tương tác với phần còn lại của TOE và với môi trường hoạt động của nó), cũng như các hành vi nội bộ của nó.

Các mô hình chính sách an toàn của TOE được trích dẫn không chính thức từ thực tế của nó bằng cách xem xét các yêu cầu an toàn được đề nghị của ST này. Việc trích dẫn không chính thức được thực hiện thành công nếu các nguyên tắc của TOE (còn gọi là “bất biến”) đưa ra được thực thi bởi các đặc tính của nó. Mục đích của các phương pháp chính thức nằm trong việc tăng cường sự chặt chẽ của việc thực thi. Đối số không chính thức luôn dễ bị sai lầm, đặc biệt là nếu các mối quan hệ giữa các chủ thể, đối tượng và hoạt động nhận được tham gia nhiều hơn và nhiều hơn nữa. Để giảm thiểu nguy cơ về trạng thái không an toàn đưa đến các quy tắc và tính chất của mô hình chính sách an toàn được ánh xạ tới các thuộc tính tương ứng và các đặc trưng bên trong một số hệ thống chính thức, với sự chặt chẽ và mạnh mẽ có thể được sử dụng sau đó để có được các thuộc tính an toàn qua các định lý và bằng chứng chính thức.

Trong khi thuật ngữ “mô hình chính sách an toàn chính thức” được sử dụng trong giới học thuật, cách tiếp cận của TCVN 8709 không có nghĩa cố định về “an toàn”, nó sẽ tương đương với bất cứ điều gì SFR được tuyên bố. Vì vậy, mô hình chính sách an toàn chính thức chỉ là một đại diện chính thức của tập SFR được tuyên bố.

Các chính sách an toàn có kết hợp truyền thống chỉ với chính sách kiểm soát truy cập, mà dựa trên nhãn (bắt buộc kiểm soát truy cập), hoặc dựa trên người dùng (kiểm soát truy cập tùy ý). Tuy nhiên, một chính sách an toàn không giới hạn kiểm soát truy cập, còn có những chính sách kiểm tra, chính sách xác định, chính sách xác thực, chính sách mã hóa, chính sách quản lý, và các chính sách an toàn khác mà được thực thi bởi các TOE, như mô tả trong PP/ST.ADV_SPM.1.1D chứa phần để xác định các chính sách này được mô hình hóa chính thức.

11.5.4. ADV_SPM.1 Mô hình chính sách an toàn TOE chính thức

Các phụ thuộc: ADV_FSP.4 Đặc tả chức năng đầy đủ.

11.5.4.1. Phần tử hành động của nhà phát triển

11.5.4.1.1. ADV_SPM.1.1D

Nhà phát triển cần cung cấp mô hình chính sách an toàn chính thức cho [gán: danh sách các chính sách mà được mô hình hóa chính thức].

11.5.4.1.2. ADV_SPM.1.2D

Mỗi chính sách bao gồm mô hình chính sách an toàn chính thức, mô hình này cần chỉ ra các phần phù hợp của tuyên bố của SFR mà là sự phối hợp chính sách đó.

11.5.4.1.3. ADV_SPM.1.3D

Nhà phát triển cần cung cấp chứng minh chính thức về sự tương ứng giữa mô hình và bất kỳ đặc tả chức năng chính thức nào.

11.5.4.1.4. ADV_SPM.1.4D

Nhà phát triển cần cung cấp chứng minh sự tương ứng giữa mô hình và đặc tả chức năng.

11.5.4.2. Các phần tử nội dung và trình bày

11.5.4.2.1. ADV_SPM.1.1C

Mô hình cần cung cấp kiểu chính thức, được hỗ trợ bởi văn bản giải thích được yêu cầu và xác định các chính sách an toàn của TSF được mô hình hóa.

11.5.4.2.2. ADV_SPM.1.2C

Tất cả các chính sách mà được mô hình hóa, mô hình cần định nghĩa an toàn cho TOE và cung cấp chứng minh chính thức mà TOE không thể tiếp cận đến trạng thái không an toàn.

11.5.4.2.3. ADV_SPM.1.3C

Sự phù hợp giữa mô hình và đặc tả chức năng cần ở mức chính xác của quy cách.

11.5.4.2.4. ADV_SPM.1.4C

Sự phù hợp cần chỉ ra đặc tả chức năng là nhất quán và đầy đủ với toàn bộ về mô hình.

11.5.4.2.5. ADV_SPM.1.5C

Chứng minh sự phù hợp cần chỉ ra rằng các giao diện trong đặc tả chức năng là nhất quán và đầy đủ về các chính sách được phân trong ADV_SPM.1.1D.

11.5.4.3. Các phần tử hành động của đánh giá viên

11.5.4.3.1. ADV_SPM.1.1E

Đánh giá viên cần xác nhận rằng thông tin được cung cấp đáp ứng đầy đủ tất cả các yêu cầu về nội dung và trình bày chứng cứ.

11.6. Thiết kế TOE (ADV_TDS)

11.6.1. Mục tiêu

Bản mô tả thiết kế cho một TOE đưa ra ngữ cảnh mô tả cho TSF đồng thời mô tả chi tiết cho TSF. Khi nhu cầu đảm bảo tăng, mức chi tiết trong mô tả cũng tăng. Khi phạm vi và độ phức tạp của TSF tăng, việc phân tách nhiều mức là thích hợp. Các yêu cầu thiết kế đưa ra các thông tin với chủ ý (tương xứng với mức đảm bảo cho trước) sao cho có thể đưa ra quyết định về việc các yêu cầu chức năng an toàn đã được thực hiện.

11.6.2. Phân mức thành phần

Các thành phần trong họ này được phân mức trên cơ sở tổng số thông tin đòi hỏi phải thể hiện ứng với TSF và tùy vào mức độ hình thức yêu cầu của mô tả thiết kế.

11.6.3. Chú thích ứng dụng

Mục tiêu của tài liệu thiết kế là đưa ra thông tin đầy đủ để xác định ranh giới TSF và mô tả TSF triển khai các yêu cầu chức năng an toàn như thế nào. Số lượng và cấu trúc của tài liệu thiết kế phụ thuộc vào độ phức tạp của TOE và số các SFR. Thông thường, một TOE khá phức tạp với một lượng lớn SFR sẽ đòi hỏi nhiều tài liệu thiết kế hơn một TOE đơn giản chi triển khai cho một vài SFR. Các TOE phức tạp hơn sẽ được lợi từ việc tạo ra các mức phân tách khác nhau trong mô tả thiết kế, trong khi các TOE đơn giản hơn không đòi hỏi mô tả mức cao và mức thấp việc triển khai chúng.

Họ này có hai mức phân tách: hệ thống con và mô đun. Một mô đun là bản mô tả chức năng đặc trưng nhất, nó chính là bản mô tả triển khai. Một nhà phát triển cần có khả năng triển khai một phần TOE mô tả trong mô đun mà không cần thêm các giải trình về thiết kế khác. Một hệ thống con là bản mô tả thiết kế TOE, nó giúp đưa ra mô tả mức cao về một thành phần TOE đang làm gì và như thế nào. Do vậy, một hệ thống con có thể được chia ra các hệ thống con mức thấp hơn, hoặc chia ra thành các mô đun. Các TOE phức tạp có thể đòi hỏi một số mức hệ thống con khác nhau nhằm truyền đạt phù hợp thông tin mô tả hữu ích về việc TOE làm việc như thế nào. Các TOE đơn giản hơn thì ngược lại không đòi hỏi mô tả cấp hệ thống con nào, mô đun của nó có thể mô tả rõ ràng cách thức làm việc của TOE.

Cách thức chung cho tài liệu thiết kế là tùy theo mức độ đảm bảo tăng dẫn, mức độ chi tiết của mô tả đi từ mô tả chung (mức hệ thống con) đến mô tả chi tiết hơn (mức đô mun). Trong các trường hợp mức độ trừu tượng ở mức mô đun là phù hợp vì TOE đơn giản đủ để mô tả ở mức mô đun song mức đảm bảo yêu cầu mô tả ở mức hệ thống con, thì chỉ cần mô tả ở mức mô đun là đủ. Tuy nhiên, đối với các TOE phức tạp thì không phải như vậy: một lượng lớn các chi tiết (mức mô đun) cũng sẽ không đủ nếu không có kèm theo mô tả ở mức hệ thống con.

Phương thức này tuân theo một mô hình chung là cung cấp chi tiết bổ sung khi triển khai TSF sẽ đem lại sự đảm bảo tốt hơn về việc các SFR được thực thi chính xác và đưa ra thông tin sử dụng để biểu thị điều này trong kiểm thử (Kiểm thử ATE).

Trong các yêu cầu của họ này, khái niệm giao diện dùng để chỉ phương tiện trao đổi (giữa hai hệ thống con hoặc hai mô đun). Nó mô tả cách thức thực hiện trao đổi, tương tự như các chi tiết của TSFI (xem Đặc tả chức năng ADV_FSP). Khái niệm tương tác dùng để chỉ ra mục đích trao đổi, nó chỉ ra lý do hai hệ thống con hoặc hai mô đun trao đổi với nhau.

11.6.3.1. Chi tiết về các hệ thống con và các mô đun

Các yêu cầu xác định ra tập các chi tiết về các hệ thống con và các mô đun cần đưa ra gồm:

a) Các hệ thống con và các mô đun được xác định với một danh sách đơn giản mô tả chúng là những gì.

b) Các hệ thống con và các mô đun có thể được phân loại (rõ ràng hoặc ngầm định) thành “bắt buộc theo SFR”, “Hỗ trợ SFR”, hoặc “Không liên quan đến SFR”. Các khái niệm này được dùng tương tự như trong phần đặc tả chức năng (ADV_FSP).

c) Hoạt động của một hệ thống con chỉ ra nó làm những gì. Hoạt động này có thể phân loại thành “bắt buộc theo SFR”, “Hỗ trợ SFR”, hoặc “Không liên quan đến SFR”. Hoạt động của hệ thống con không bao giờ được phân loại khi phân ra nhiều SFR phù hợp hơn là phân loại hệ thống con. Ví dụ, một hệ thống con bắt buộc theo SFR có thể có hoạt động bắt buộc theo SFR và cũng có thể là hoạt động Hỗ trợ SFR hoặc Không liên quan đến SFR.

d) Tóm tắt hoạt động của một hệ thống con là một mô tả tổng quát về các hành động nó thực hiện (ví dụ “hệ thống con TCP tập hợp các IP datagram vào các luồng byte tin cậy”).

e) Mô tả hoạt động của một hệ thống con là một bản giải thích về mọi điều nó làm. Mô tả này cần ở mức chi tiết để có thể xác định rõ ràng là hoạt động này có bất kỳ sự liên quan nào đến việc thực thi các SFR hay không.

f) Mô tả các tương tác của các hệ thống con và các mô đun hoặc tương tác giữa chúng chỉ ra lý do trao đổi thông tin giữa các hệ thống con hoặc các mô đun, và đặc tả thông tin chuyển qua nó. Không cần phải xác định thông tin chi tiết như đặc tả của một giao diện. Ví dụ, sẽ đủ khi nói rằng “hệ thống con X yêu cầu một khối bộ nhớ từ bộ quản lý bộ nhớ, và nhận được vị trí bộ nhớ đã cấp phát”.

g) Mô tả giao diện cung cấp chi tiết về cách thứ thực hiện các tương tác giữa các mô đun. Thay vì mô tả lý do các mô đun trao đổi với nhau hay mục đích việc trao đổi thông tin của chúng (nghĩa là mô tả các tương tác), mô tả giao diện mô tả chi tiết cách thức thực hiện trao đổi thông tin với các thuật ngữ về cấu trúc, nội dung các bản tin, đánh tín hiệu, các trao đổi tiến trình nội bộ,…

h) Mục đích mô tả phương thức một mô đun cung cấp chức năng của nó. Nó đưa ra chi tiết đủ để không cần phải thêm giải trình thiết kế nào khác. Cần thể hiện rõ tính phù hợp mô tả triển khai mô đun và mục đích của mô đun.

i) Một mô đun được mô tả theo các khác với các thuật ngữ được xác định trong phần tử của nó.

Các hệ thống con và các mô đun, khái niệm “Bắt buộc theo SFR”, v.v. sẽ được giải thích chi tiết hơn trong Phụ lục A.4: Các hệ thống con và các mô đun: ADV_TDS.

11.6.4. ADV_TDS.1 Thiết kế cơ sở

Các phụ thuộc: ADV_FSP.2 Đặc tả chức năng thực thi an toàn

11.6.4.1. Phần tử hành động của nhà phát triển

11.6.4.1.1. ADV_TDS.1.1D

Nhà phát triển cần đưa ra được bản thiết kế của TOE.

11.6.4.1.2. ADV_TDS.1.2D

Nhà phát triển cần đưa ra được bản ánh xạ giữa TSFI về đặc tả chức năng và mức phân tách thấp nhất dùng được trong thiết kế TOE.

11.6.4.2. Các phần tử nội dung và trình bày

11.6.4.2.1. ADV_TDS.1.1C

Bản thiết kế cần mô tả cấu trúc TOE với các hệ thống con.

11.6.4.2.2. ADV_TDS.1.2C

Bản thiết kế cần chỉ ra tất cả các hệ thống con của TSF.

11.6.4.2.3. ADV_TDS.1.3C

Bản thiết kế cần mô tả hoạt động của mỗi hệ thống con TSF kiểu “hỗ trợ SFR” hoặc “không liên quan SFR” ở mức độ chi tiết đủ để khẳng định nó không phải là kiểu “bắt buộc theo SFR”.

11.6.4.2.4. ADV_TDS.1.4C

Bản thiết kế cần tóm lược hoạt động bắt buộc theo SFR cho các hệ thống con kiểu “bắt buộc theo SFR”.

11.6.4.2.5. ADV_TDS.1.5C

Bản thiết kế cần đưa ra mô tả về tương tác của các hệ thống con kiểu “bắt buộc theo SFR” của TSF, và giữa các hệ thống con đó với các hệ thống con của TSF khác.

11.6.4.2.6. ADV_TDS.1.6C

Bản thiết kế cần biểu thị rằng mọi hoạt động mô tả trong thiết kế TOE được ánh xạ vào trong các TSFI thực thi chúng.

11.6.4.3. Các phần tử hành động của đánh giá viên

11.6.4.3.1. ADV_TDS.1.1E

Đánh giá viên cần khẳng định rằng thông tin đã cung cấp đáp ứng mọi yêu cầu về nội dung và biểu thị bằng chứng.

11.6.4.3.2. ADV_TDS.1.2E

Đánh giá viên cần xác định rằng bản thiết kế là một bản sao chính xác và đầy đủ mọi yêu cầu chức năng an toàn.

11.6.5. ADV_TDS.2 Thiết kế kiến trúc

Các phụ thuộc: ADV_FSP.3 Đặc tả chức năng với bản tổng hợp đầy đủ.

11.6.5.1. Phần tử hành động của nhà phát triển

11.6.5.1.1. ADV_TDS.2.1D

Nhà phát triển cần đưa ra được bản thiết kế của TOE.

11.6.5.1.2. ADV_TDS.2.2D

Nhà phát triển cần đưa ra được bản ánh xạ giữa TSFI về đặc tả chức năng và mức phân tách thấp nhất dùng được trong thiết kế TOE.

11.6.5.2. Các phần tử nội dung và trình bày

11.6.5.2.1. ADV_TDS.2.1C

Bản thiết kế cần mô tả cấu trúc TOE với các hệ thống con.

11.6.5.2.2. ADV_TDS.2.2C

Bản thiết kế cần chỉ ra tất cả các hệ thống con của TSF.

11.6.5.2.3. ADV_TDS.2.3C

Bản thiết kế cần mô tả hoạt động của mỗi hệ thống con TSF kiểu “không liên quan SFR” ở mức độ chi tiết đủ để khẳng định nó là kiểu “không liên quan SFR”.

11.6.5.2.4. ADV_TDS.2.4C

Bản thiết kế cần tóm lược hoạt động bắt buộc theo SFR cho các hệ thống con kiểu “bắt buộc theo SFR”.

11.6.5.2.5. ADV_TDS.2.5C

Bản thiết kế cần tóm tắt hoạt động “hỗ trợ SFR” và “không liên quan SFR” của các hệ thống con kiểu “bắt buộc theo SFR”.

11.6.5.2.6. ADV_TDS.2.6C

Bản thiết kế cần tóm tắt hoạt động của các hệ thống con kiểu “hỗ trợ SFR”.

11.6.5.2.7. ADV_TDS.2.7C

Bản thiết kế cần đưa ra mô tả về tương tác của tất cả các hệ thống con của TSF.

11.6.5.2.8. ADV_TDS.2.8C

Bản thiết kế cần biểu thị rằng mọi hoạt động mô tả trong thiết kế TOE được ánh xạ vào trong các TSFI thực thi chúng.

11.6.5.3. Các phần tử hành động của đánh giá viên

11.6.5.3.1. ADV_TDS.2.1E

Đánh giá viên cần khẳng định rằng thông tin đã cung cấp đáp ứng mọi yêu cầu về nội dung và biểu thị bằng chứng.

11.6.5.3.2. ADV_TDS.2.2E

Đánh giá viên cần xác định rằng bản thiết kế là một bản sao chính xác và đầy đủ mọi yêu cầu chức năng an toàn.

11.6.6. ADV_TDS.3 Thiết kế mô đun cơ sở

Các phụ thuộc: ADV_FSP.4 Đặc tả chức năng đầy đủ

11.6.6.1. Phần tử hành động của nhà phát triển

11.6.6.1.1. ADV_TDS.3.1D

Nhà phát triển cần đưa ra được bản thiết kế của TOE.

11.6.6.1.2. ADV_TDS.3.2D

Nhà phát triển cần đưa ra được bản ánh xạ giữa TSFI về đặc tả chức năng và mức phân tách thấp nhất dùng được trong thiết kế TOE.

11.6.6.2. Các phần tử nội dung và trình bày

11.6.6.2.1. ADV_TDS.3.1C

Bản thiết kế cần mô tả cấu trúc TOE với các hệ thống con.

11.6.6.2.2 ADV_TDS.3.2C

Bản thiết kế cần mô tả tất cả các mô đun của TSF.

11.6.6.2.3. ADV_TDS.3.3C

Bản thiết kế cần chỉ ra tất cả các hệ thống con của TSF.

11.6.6.2.4. ADV_TDS.3.4C

Bản thiết kế cần đưa ra mô tả cho mỗi hệ thống con của TSF.

11.6.6.2.5. ADV_TDS.3.5C

Bản thiết kế cần đưa ra mô tả cho các tương tác của mọi hệ thống con của TSF.

11.6.6.2.6. ADV_TDS.3.6C

Bản thiết kế cần đưa ra ánh xạ từ các hệ thống con của TSF đến các mô đun của TSF.

11.6.6.2.7. ADV_TDS.3.7C

Bản thiết kế cần mô tả mỗi mô đun “hỗ trợ SFR” và “không liên quan SFR” với mục đích và tương tác của chúng với các mô đun khác.

11.6.6.2.8. ADV_TDS.3.8C

Bản thiết kế cần mô tả mỗi mô đun “bắt buộc theo SFR” với các giao diện liên quan SFR của chúng, cho lại các giá trị từ các giao diện này, tương tác với và gọi các giao diện tới các mô đun khác.

11.6.6.2.9. ADV_TDS.3.9C

Bản thiết kế cần mô tả mỗi mô đun “hỗ trợ SFR” hoặc “không liên quan SFR” với mục đích và tương tác của chúng với các mô đun khác.

11.6.6.2.10. ADV_TDS.3.10C

Bản thiết kế cần biểu thị rằng mọi hoạt động mô tả trong thiết kế TOE được ánh xạ vào trong các TSFI thực thi chúng.

11.6.6.3. Các phần tử hành động của đánh giá viên

11.6.6.3.1. ADV_TDS.3.1E

Đánh giá viên cần khẳng định rằng thông tin đã cung cấp đáp ứng mọi yêu cầu về nội dung và biểu thị bằng chứng.

11.6.6.3.2. ADV_TDS.3.2E

Đánh giá viên cần xác định rằng bản thiết kế là một bản sao chính xác và đầy đủ mọi yêu cầu chức năng an toàn.

11.6.7. ADV_TDS.4 Thiết kế mô đun bán chính thức

Các phụ thuộc: ADV_FSP.5 Đặc tả chức năng bán chính thức đầy đủ với thông tin lỗi bổ sung

11.6.7.1. Phần tử hành động của nhà phát triển

11.6.7.1.1. ADV_TDS.4.1D

Nhà phát triển cần đưa ra được bản thiết kế của TOE.

11.6.7.1.2. ADV_TDS.4.2D

Nhà phát triển cần đưa ra được bản ánh xạ giữa TSFI về đặc tả chức năng và mức phân tách thấp nhất dùng được trong thiết kế TOE.

11.6.7.2. Các phần tử nội dung và trình bày

11.6.7.2.1. ADV_TDS.4.1C

Bản thiết kế cần mô tả cấu trúc TOE với các hệ thống con.

11.6.7.2.2. ADV_TDS.4.2C

Bản thiết kế cần mô tả TSF với các mô đun, thiết kế mỗi mô đun theo “bắt buộc theo SFR”, “hỗ trợ SFR”, hoặc “không liên quan SFR”.

11.6.7.2.3. ADV_TDS.4.3C

Bản thiết kế cần chỉ ra tất cả các hệ thống con của TSF.

11.6.7.2.4. ADV_TDS.4.4C

Bản thiết kế cần đưa ra mô tả bán chính thức cho mỗi hệ thống con của TSF, với văn bản giải thích không chính thức phù hợp.

11.6.7.2.5. ADV_TDS.4.5C

Bản thiết kế cần đưa ra mô tả cho các tương tác của mọi hệ thống con của TSF.

11.6.7.2.6. ADV_TDS.4.6C

Bản thiết kế cần đưa ra ánh xạ từ các hệ thống con của TSF đến các mô đun của TSF.

11.6.7.2.7. ADV_TDS.4.7C

Bản thiết kế cần mô tả mỗi mô đun “bắt buộc SFR” và “hỗ trợ SFR” với mục đích và tương tác của chúng với các mô đun khác.

11.6.7.2.8. ADV_TDS.4.8C

Bản thiết kế cần mô tả mỗi mô đun “bắt buộc theo SFR” với các giao diện liên quan SFR của chúng, cho lại các giá trị các giao diện này, tương tác với và gọi các giao diện tới các mô đun khác.

11.6.7.2.9. ADV_TDS.4.9C

Bản thiết kế cần mô tả mỗi mô đun “không liên quan SFR” với mục đích và tương tác của chúng với các mô đun khác.

11.6.7.2.10. ADV_TDS.4.10C

Bản thiết kế cần biểu thị rằng mọi hoạt động mô tả trong thiết kế TOE được ánh xạ vào trong các TSFI thực thi chúng.

11.6.7.3. Các phần tử hành động của đánh giá viên

11.6.7.3.1. ADV_TDS.4.1E

Đánh giá viên cần khẳng định rằng thông tin đã cung cấp đáp ứng mọi yêu cầu về nội dung và biểu thị bằng chứng.

11.6.7.3.2. ADV_TDS.4.2E

Đánh giá viên cần xác định rằng bản thiết kế là một bản sao chính xác và đầy đủ mọi yêu cầu chức năng an toàn.

11.6.8. ADV_TDS.5 Thiết kế mô đun bán chính thức đầy đủ

Các phụ thuộc: ADV_FSP.5 Đặc tả chức năng bán chính thức đầy đủ với thông tin lỗi bổ sung

11.6.8.1. Phần tử hành động của nhà phát triển

11.6.8.1.1. ADV_TDS.5.1D

Nhà phát triển cần đưa ra được bản thiết kế của TOE.

11.6.8.1.2. ADV_TDS.5.2D

Nhà phát triển cần đưa ra được bản ánh xạ giữa TSFI về đặc tả chức năng và mức phân tách thấp nhất dùng được trong thiết kế TOE.

11.6.8.2. Các phần tử nội dung và trình bày

11.6.8.2.1. ADV_TDS.5.1C

Bản thiết kế cần mô tả cấu trúc TOE với các hệ thống con.

11.6.8.2.2. ADV_TDS.5.2C

Bản thiết kế cần mô tả TSF với các mô đun, thiết kế mỗi mô đun theo “bắt buộc theo SFR”, “hỗ trợ SFR”, hoặc “không liên quan SFR”.

11.6.8.2.3. ADV_TDS.5.3C

Bản thiết kế cần chỉ ra tất cả các hệ thống con của TSF.

11.6.8.2.4. ADV_TDS.5.4C

Bản thiết kế cần đưa ra mô tả bán chính thức cho mỗi hệ thống con của TSF, với văn bản giải thích không chính thức phù hợp.

11.6.8.2.5. ADV_TDS.5.5C

Bản thiết kế cần đưa ra mô tả cho các tương tác của mọi hệ thống con của TSF.

11.6.8.2.6. ADV_TDS.5.6C

Bản thiết kế cần đưa ra ánh xạ từ các hệ thống con của TSF đến các mô đun của TSF.

11.6.8.2.7. ADV_TDS.5.7C

Bản thiết kế cần mô tả bán chính thức mỗi mô đun với mục đích, tương tác, giao diện của chúng, cho lại các giá trị từ các giao diện này, tương tác với và gọi các giao diện tới các mô đun khác, với văn bản giải thích không chính thức phù hợp.

11.6.8.2.8. ADV_TDS.5.8C

Bản thiết kế cần biểu thị rằng mọi hoạt động mô tả trong thiết kế TOE được ánh xạ vào trong các TSFI thực thi chúng.

11.6.8.3. Các phần tử hành động của đánh giá viên

11.6.8.3.1. ADV_TDS.5.1E

Đánh giá viên cần khẳng định rằng thông tin đã cung cấp đáp ứng mọi yêu cầu về nội dung và biểu thị bằng chứng.

11.6.8.3.2. ADV_TDS.5.2E

Đánh giá viên cần xác định rằng bản thiết kế là một bản sao chính xác và đầy đủ mọi yêu cầu chức năng an toàn.

11.6.9. ADV_TDS.6 Thiết kế mô đun bán chính thức đầy đủ với bản thể hiện thiết kế chính thức mức cao

Các phụ thuộc: ADV_FSP.6 Đặc tả chức năng bán chính thức đầy đủ với bổ sung đặc tả chính thức

11.6.9.1. Phần tử hành động của nhà phát triển

11.6.9.1.1. ADV_TDS.6.1D

Nhà phát triển cần đưa ra được bản thiết kế của TOE.

11.6.9.1.2. ADV_TDS.6.2D

Nhà phát triển cần đưa ra được bản ánh xạ giữa TSFI về đặc tả chức năng và mức phân tách thấp nhất dùng được trong thiết kế TOE.

11.6.9.1.3. ADV_TDS.6.3D

Nhà phát triển cần đưa ra được đặc tả chính thức cho các hệ thống con TSF.

11.6.9.1.4. ADV_TDS.6.4D

Nhà phát triển cần đưa ra được minh chứng về sự phù hợp giữa các đặc tả chính thức cho các hệ thống con TSF và cho đặc tả chức năng.

11.6.9.2. Các phần tử nội dung và trình bày

11.6.9.2.1 ADV_TDS.6.1C

Bản thiết kế cần mô tả cấu trúc TOE với các hệ thống con.

11.6.9.2.2 ADV_TDS.6.2C

Bản thiết kế cần mô tả TSF với các mô đun, thiết kế mỗi mô đun theo “bắt buộc theo SFR”, “hỗ trợ SFR”, hoặc “không liên quan SFR”.

11.6.9.2.3. ADV_TDS.6.3C

Bản thiết kế cần chỉ ra tất cả các hệ thống con của TSF.

11.6.9.2.4. ADV_TDS.6.4C

Bản thiết kế cần đưa ra mô tả bán chính thức cho mỗi hệ thống con của TSF, với văn bản giải thích không chính thức phù hợp.

11.6.9.2.5. ADV_TDS.6.5C

Bản thiết kế cần đưa ra mô tả cho các tương tác của mọi hệ thống con của TSF.

11.6.9.2.6. ADV_TDS.6.6C

Bản thiết kế cần đưa ra ánh xạ từ các hệ thống con của TSF đến các mô đun của TSF.

11.6.9.2.7. ADV_TDS.6.7C

Bản thiết kế cần mô tả theo kiểu bán chính thức cho mỗi mô đun với mục đích, tương tác, các giá trị cho lại từ các giao diện này, và các giao diện được gọi tới các mô đun khác, với văn bản giải thích không chính thức phù hợp.

11.6.9.2.8. ADV_TDS.6.8C

Đặc tả chính thức của các hệ thống con TSF cần mô tả TSF theo kiểu chính thức, kèm văn bản giải thích không chính thức phù hợp.

11.6.9.2.9. ADV_TDS.6.9C

Ánh xạ cần biểu thị rằng mọi hoạt động mô tả trong thiết kế TOE được ánh xạ vào trong các TSFI thực thi chúng.

11.6.9.2.10. ADV_TDS.6.10C

Minh chứng cho sự phù hợp giữa các đặc tả chính thức cho các hệ thống con TSF và cho đặc tả chức năng cần biểu thị rằng mọi hoạt động mô tả trong thiết kế TOE là bản chi tiết hóa một cách đầy đủ và chính xác của TSFI thực thi chúng.

11.6.9.3. Các phần tử hành động của đánh giá viên

11.6.9.3.1. ADV_TDS.6.1E

Đánh giá viên cần khẳng định rằng thông tin đã cung cấp đáp ứng mọi yêu cầu về nội dung và biểu thị bằng chứng.

11.6.9.3.2. ADV_TDS.6.2E

Đánh giá viên cần xác định rằng bản thiết kế là một bản sao chính xác và đầy đủ mọi yêu cầu chức năng an toàn.

12. Lớp AGD: Tài liệu hướng dẫn

Lớp tài liệu hướng dẫn đưa ra những yêu cầu cho tài liệu hướng dẫn cho người sử dụng. Đối với việc chuẩn bị và vận hành an toàn TOE, điều này là cần thiết để mô tả tất cả những vấn đề về xử lý an toàn của TOE. Lớp cũng đề cập đến khả năng cấu hình không đúng như mong muốn hoặc việc xử lý TOE.

Trong nhiều trường hợp, có thể thích hợp hơn là hướng dẫn được chia ra nhiều tài liệu cho chuẩn bị và vận hành an toàn TOE, hoặc các tài liệu riêng cho những người sử dụng khác nhau như: người dùng đầu cuối, quản trị viên, người lập trình ứng dụng sử dụng các giao diện phần cứng, phần mềm…

Lớp tài liệu hướng dẫn được chia thành hai họ, có liên quan đến phần hướng dẫn chuẩn bị cho người dùng (là điều cần thực hiện khi chuyển đổi TOE đã bàn giao sang cấu hình đã đánh giá trong môi trường vận hành như đã mô tả trong ST) và với phần hướng dẫn người dùng vận hành (những gì cần thực hiện trong quá trình khai thác TOE trong cấu hình đã đánh giá của nó.

Hình 12 biểu thị các họ trong lớp này, phân lớp thành phần trong các họ.

Hình 12 - Phân cấp lớp AGC: Các tài liệu hướng dẫn

12.1. Hướng dẫn người dùng vận hành (AGD_OPE)

12.1.1. Mục tiêu

Tài liệu hướng dẫn này đề cập đến các tài liệu văn bản dành cho những người dùng TOE trong cấu hình đã đánh giá của nó bao gồm: người dùng đầu cuối, người có trách nhiệm duy trì và quản lý TOE theo cách đúng nhằm đạt sự an toàn tối đa, và những người dùng khác (ví dụ các lập trình viên) sử dụng các giao diện TOE với bên ngoài. Tài liệu hướng dẫn người dùng vận hành mô tả chức năng an toàn cung cấp bởi TSF, đưa ra các lệnh và hướng dẫn (gồm cả cảnh báo), giúp hiểu được TSF và bao gồm thông tin an toàn trọng yếu, các hành động an toàn trọng yếu cần có, nhằm đảm bảo sử dụng chúng an toàn. Hướng dẫn sai hoặc không hợp lý cần loại bỏ khỏi tài liệu hướng dẫn, các thủ tục an toàn cho mọi chế độ hoạt động cần được xem xét. Các trạng thái không an toàn cần dễ phát hiện.

Hướng dẫn người dùng vận hành đưa ra biện pháp tin cậy giúp các người sử dụng thông thường, các quản trị viên, các nhà cung cấp ứng dụng và những đối tượng khác liên quan đến giao diện bên ngoài TOE hiểu được hoạt động an toàn của TOE và sử dụng nó như đã dự kiến. Đánh giá hướng dẫn người dùng bao gồm cả việc xem xét xem TOE có thể sử dụng theo cách không an toàn như thế nào và người dùng TOE cần tin là nó hoạt động an toàn. Mục tiêu là giảm thiểu rủi ro do con người và các lỗi khác khi hoạt động có thể gây ra ngăn cản, làm sai hoặc chặn chức năng an toàn để đưa TOE vào trạng thái không an toàn không thể phát hiện được.

12.1.2. Phân mức thành phần

Họ này chỉ gồm một thành phần.

12.1.3. Chú thích ứng dụng

Có thể các vai trò người dùng và nhóm người dùng khác nhau được chấp thuận trong TOE và họ có thể tương tác với TSF. Vai trò người dùng và các nhóm này cần được xem xét trong tài liệu hướng dẫn người dùng vận hành. Họ có thể được nhóm vào quản trị viên và những người dùng không có vai trò quản trị, hoặc cụ thể hơn được nhóm vào các cá nhân có trách nhiệm về việc: nhận, chấp thuận, cài đặt và duy trì TOE, lập trình viên các ứng dụng, người soát xét, kiểm toán viên, quản trị viên hàng ngày, người dùng đầu cuối. Mỗi vai trò có thể bao hàm một tập năng lực hoặc chỉ một quyền duy nhất.

Yêu cầu AGD_OPE.1.1C bao hàm khía cạnh mọi cảnh báo tới người dùng trong khi vận hành TOE sẽ liên quan đến định nghĩa vấn đề an toàn và các mục tiêu an toàn cho môi trường vận hành được mô tả trong PP/ST là phù hợp trong hướng dẫn người dùng.

Khái niệm các giá trị an toàn, như đã nêu trong AGD_OPE.1.3.C có liên quan về vị trí người dùng có quyền kiểm soát các tham số an toàn. Hướng dẫn cần đưa ra đối với việc đặt đúng và không an toàn các tham số trên.

AGD_OPE.1.4C đòi hỏi hướng dẫn người dùng phải mô tả các phản ứng phù hợp với các sự kiện an toàn liên quan. Mặc dù nhiều sự kiện an toàn là kết quả của thực hiện các chức năng, cũng không nhất thiết phải như vậy trong một số trường hợp (ví dụ kiểm toán bản ghi nhật ký, phát hiện một xâm nhập). Ngoài ra, một sự kiện liên quan an toàn có thể xảy ra là kết quả của một chuỗi các chức năng, hoặc, ngược lại, một số sự kiện an toàn có thể xảy ra với một chức năng.

AGD_OPE.1.7C đòi hỏi rằng hướng dẫn người dùng phải rõ ràng và hợp lý. Hướng dẫn sai hoặc không hợp lý có thể dẫn đến việc một người dùng TOE tin rằng TOE an toàn trong khi nó không phải như vậy.

Một ví dụ về hướng dẫn sai có thể là mô tả về một lệnh hướng dẫn đơn lẻ có thể truyền theo nhiều cách, một trong những cách đó có thể dẫn đến trạng thái không an toàn.

Một ví dụ về hướng dẫn không an toàn có thể là một khuyến nghị tuân theo một thủ tục mà nó quá phức tạp không thể kỳ vọng như mong muốn là người dùng thực hiện theo.

12.1.4. Hướng dẫn người dùng vận hành AGD_OPE.1

Phụ thuộc: ADV_FSP.1 Đặc tả chức năng cơ bản

12.1.4.1. Các thành phần hành động nhà phát triển

12.1.4.1.1. AGD_OPE.1.1D

Nhà phát triển cần đưa ra tài liệu hướng dẫn người dùng vận hành.

12.1.4.2. Các phần tử nội dung và trình bày

12.1.4.2.1. AGD_OPE.1.1C

Tài liệu hướng dẫn người dùng vận hành cần mô tả các vai trò từng người, các chức năng truy nhập người dùng và các đặc quyền cần được kiểm soát trong môi trường xử lý an toàn, bao gồm các cảnh báo phù hợp.

12.1.4.2.2. AGD_OPE.1.2C

Tài liệu hướng dẫn người dùng vận hành cần mô tả các vai trò từng người, cách thức sử dụng các giao diện sẵn có cung cấp bởi TOE theo cách an toàn.

12.1.4.2.3. AGD_OPE.1.3C

Tài liệu hướng dẫn người dùng vận hành cần mô tả các vai trò từng người, các chức năng sẵn có và các giao diện, cụ thể là một tham số an toàn dưới sự kiểm soát của người dùng, biểu thị các giá trị an toàn phù hợp.

12.1.4.2.4. AGD_OPE.1.4C

Tài liệu hướng dẫn người dùng vận hành cần mô tả các vai trò từng người, định rõ mỗi kiểu sự kiện an toàn liên quan tương đối so với các chức năng truy nhập người dùng cần thực hiện, bao gồm việc thay đổi các đặc tính an toàn của các thực thể dưới sự kiểm soát của TSF.

12.1.4.2.5. AGD_OPE.1.5C

Tài liệu hướng dẫn người dùng vận hành cần xác định mọi chế độ hoạt động có thể của TOE (bao gồm hoạt động sau lỗi và lỗi vận hành), tính hợp lý của chúng và các ngầm định nhằm duy trì hoạt động an toàn.

12.1.4.2.6. AGD_OPE.1.6C

Tài liệu hướng dẫn người dùng vận hành cần mô tả cho vai trò từng người, các biện pháp an toàn cần theo nhằm thỏa mãn các mục tiêu an toàn cho môi trường hoạt động như đã mô tả trong ST.

12.1.4.2.7. AGD_OPE.1.7C

Tài liệu hướng dẫn người dùng vận hành cần rõ ràng và hợp lý.

12.1.4.3. Các phần tử hành động của đánh giá viên

12.1.4.3.1. AGD_OPE.1.1E

Đánh giá viên cần xác nhận thông tin đưa ra đáp ứng mọi nhu cầu về nội dung và trình bày của chứng cứ.

12.2. Các thủ tục chuẩn bị (AGD_PRE)

12.2.1. Mục tiêu

Các thủ tục chuẩn bị dùng để đảm bảo rằng TOE đã được nhận, cài đặt theo cách an toàn như dự kiến bởi nhà phát triển. Các yêu cầu chuẩn bị đặt ra nhiệm vụ chuyển đổi an toàn từ TOE đã bàn giao sang môi trường vận hành ban đầu của nó. Điều này bao gồm việc xem xét xem TOE có thể được cấu hình hoặc cài đặt theo cách không an toàn mà người dùng TOE vẫn tin rằng nó an toàn hay không.

12.2.2. Phân mức thành phần

Họ này chỉ gồm một thành phần

12.2.3. Chú thích ứng dụng

Có thể thấy áp dụng các yêu cầu này sẽ khác nhau tùy theo góc độ TOE có được chuyển giao vào trạng thái vận hành hay không, hay nó được cài đặt tại địa điểm của chủ sở hữu TOE,….

Quy trình đầu tiên liên quan các thủ tục chuẩn bị là việc chấp nhận an toàn của người tiêu dùng khi nhận TOE tuân theo các thủ tục chuyển giao từ nhà phát triển. Nếu nhà phát triển không định nghĩa các thủ tục chuyển giao, thì an toàn cho việc chấp nhận cũng cần đảm bảo.

Việc cài đặt TOE bao gồm chuyển đổi môi trường vận hành của nó vào trạng thái tuân thủ theo các mục tiêu an toàn cho môi trường vận hành đã đưa ra trong ST.

Có thể có trường hợp không cần thiết phải cài đặt, ví dụ một thẻ thông minh. Trong trường hợp này, có thể không phù hợp nếu yêu cầu và phân tích các thủ tục cài đặt.

Các yêu cầu trong họ bảo đảm này được trình bày tách biệt với họ Hướng dẫn người dùng vận hành (AGD_OPE), bởi vì việc sử dụng không thường xuyên và chỉ một lần của các thủ tục chuẩn bị.

12.2.4. Các thủ tục chuẩn bị AGD_PRE.1

Các mối phụ thuộc: không có sự phụ thuộc nào.

12.2.4.1. Phần tử hành động của nhà phát triển

12.2.4.1.1. AGD_PRE.1.1D

Nhà phát triển cần cung cấp TOE bao gồm các thủ tục chuẩn bị nó.

12.2.4.2. Các phần tử nội dung và trình bày

12.2.4.2.1. AGD_PRE.1.1C

Các thủ tục chuẩn bị cần mô tả mọi bước cần thiết để chấp nhận an toàn cho TOE đã chuyển giao tuân theo các thủ tục chuyển giao của nhà phát triển.

12.2.4.2.2. AGD_PRE.1.2C

Các thủ tục chuẩn bị cần mô tả mọi bước cần thiết cho cài đặt an toàn TOE và chuẩn bị an toàn môi trường vận hành tuân theo các mục tiêu an toàn cho môi trường vận hành đã mô tả trong ST.

12.2.4.3. Các phần tử hành động của đánh giá viên

12.2.4.3.1. AGD_PRE.1.1E

Đánh giá viên cần xác nhận thông tin cung cấp đáp ứng mọi nhu cầu về nội dung và trình bày của chứng cứ.

12.2.4.3.2. AGD_PRE.1.2E

Đánh giá viên cần áp dụng các thủ tục chuẩn bị để khẳng định rằng TOE cần được chuẩn bị an toàn cho hoạt động.

13. Lớp ALC: Hỗ trợ vòng đời

Hỗ trợ vòng đời là một khía cạnh của tạo lập qui tắc và kiểm soát trong quá trình bổ sung chi tiết của TOE trong khi phát triển và duy trì nó. Tính tin cậy trong trao đổi giữa các yêu cầu an toàn TOE và TOE là lớn hơn nếu phân tích an toàn và việc đưa ra chứng cứ được làm trên cơ sở điều tiết như một phần toàn vẹn của các hoạt động phát triển và duy trì.

Trong vòng đời sản phẩm, việc phân biệt xem TOE là trách nhiệm của nhà phát triển hay người dùng được quan tâm hơn là nó thuộc môi trường phát triển hay môi trường người dùng. Ranh giới chuyển đổi là thời điểm bàn giao TOE cho người dùng. Đó cũng là thời điểm chuyển đổi từ lớp ALC sang lớp AGD.

Lớp ALC bao gồm 7 họ. Họ Định nghĩa vòng đời (ALC_LCD) mô tả mức cao cho vòng đời TOE. Họ Năng lực CM (ALC_CM) mô tả chi tiết hơn về việc quản lý các danh mục lập cấu hình. Phạm vi CM (ALC_CMS) đòi hỏi một tập danh mục cấu hình tối thiểu cần quản lý theo cách đã xác định. An toàn phát triển (ALC_DVS) liên quan đến các biện pháp về vật lý, thủ tục và con người cũng như các biện pháp an toàn khác của nhà phát triển. Công cụ và kỹ thuật (ALC_TAT) liên quan đến các công cụ phát triển và tiêu chuẩn triển khai do nhà phát triển sử dụng. Sửa lỗi (ALC_FLR) liên quan đến việc xử lý các khiếm khuyết về an toàn. Chuyển giao (ALC_DEL) định nghĩa các thủ tục dùng cho chuyển giao TOE tới khách hàng. Các quy trình chuyển giao xuất hiện trong phát triển TOE nặng về nghĩa vận chuyển, chúng được sử dụng trong ngữ cảnh các thủ tục tích hợp và chấp nhận trong các họ khác của lớp này.

Trong toàn bộ lớp này, phát triển và các thuật ngữ liên quan (nhà phát triển, động từ phát triển) được hiểu với nghĩa rộng hơn bao gồm phát triển và sản xuất, trong đó sản xuất có nghĩa đặc biệt là quy trình chuyển đổi biểu diễn triển khai sang TOE thành phẩm.

Hình 13 cho thấy các họ trong lớp này, và phân cấp các thành phần trong các họ.

Hình 13 - Phân cấp lớp ALC: Hỗ trợ vòng đời

13.1. Năng lực CM (ALC_CMC)

13.1.1. Mục tiêu

Quản lý cấu hình (CM) là cách để tăng thêm tính đảm bảo về việc TOE thỏa mãn các SFRs. CM tạo ra điều đó bằng cách yêu cầu nguyên tắc và biện pháp quản lý trong các quy trình cụ thể hóa và sửa đổi TOE và thông tin liên quan. Các hệ thống CM được đưa ra nhằm đảm bảo tính toàn vẹn cho các phần của TOE mà chúng kiểm soát, bằng cách đưa ra phương pháp theo dấu các thay đổi và qua việc đảm bảo rằng mọi thay đổi đều được phép.

Mục tiêu của họ này là yêu cầu hệ thống CM của nhà phát triển có một số năng lực nhất định. Nghĩa là có thể giảm khả năng xảy ra việc sửa đổi ngẫu nhiên hoặc trái phép các danh mục trong cấu hình. Hệ thống CM cần đảm bảo tính toàn vẹn của TOE từ khâu thiết kế ban đầu trong suốt quá trình duy trì hoạt động sau đó.

Mục tiêu của việc đưa vào các công cụ CM tự động hóa là làm tăng hiệu quả của hệ thống CM. Trong khi các hệ thống CM tự động và thủ công có thể bị vượt qua, bỏ qua hoặc chứng tỏ là không đủ để phòng chống các sửa đổi trái phép, các hệ thống tự động hóa ít chịu ảnh hưởng hơn bởi lỗi của con người hoặc những sơ suất.

Mục đích của họ này bao gồm:

a) Đảm bảo rằng TOE là chính xác và toàn vẹn trước khi được gửi tới khách hàng.

b) Đảm bảo không có danh mục cấu hình bị thiếu trong quá trình đánh giá.

c) Chống lại sự thay đổi, thêm vào, hay xóa trái phép các danh mục cấu hình TOE.

13.1.2. Phân mức thành phần

Các thành phần trong họ này được phân mức trên cơ sở năng lực hệ thống CM, phạm vi của tài liệu CM và chứng cứ cung cấp bởi nhà phát triển.

13.1.3. Chú thích ứng dụng

Mặc dù mong muốn CM được áp dụng ngay từ khâu thiết kế ban đầu và tiếp tục sau đó, họ này đòi hỏi CM cần được đặt ra và sử dụng trước khi kết thúc đánh giá.

Trong trường hợp TOE là một phần nhỏ của sản phẩm, các yêu cầu của họ này chỉ áp dụng cho danh mục cấu hình TOE mà không cho toàn bộ sản phẩm.

Đối với nhà phát triển có các hệ thống CM riêng cho các chu trình vòng đời khác nhau (ví dụ phát triển, sản xuất và/hoặc sản phẩm cuối), cần văn bản hóa mọi quá trình này. Cho các mục đích đánh giá, các hệ thống CM riêng biệt cần được xem như các phần của một hệ thống CM tổng quát được đề cập trong các tiêu chí.

Tương tự, nếu các phần của TOE được tạo ra bởi các nhà phát triển khác nhau ở các nơi khác nhau, các hệ thống CM đang sử dụng ở các địa điểm khác nhau cần được xem như các phần của một hệ thống CM tổng quát được đề cập trong các tiêu chí. Trong tình huống này, cần xem xét thêm các vấn đề tích hợp.

Một số phần tử của họ này tham chiếu tới danh mục cấu hình. Các phần tử này xác định các yêu cầu CM cần được áp đặt vào mọi mục đã nêu trong danh sách cấu hình, song nội dung cụ thể của danh sách sẽ là phần việc của nhà phát triển. Phạm vi CM (ALC_CMS) có thể dùng để hạn chế việc cụ thể hóa này bằng việc xác định ra các mục đặc trưng cần phải có trong danh sách cấu hình, nghĩa là có trong CM.

ALC_CMC.2.3C đưa ra một yêu cầu về việc hệ thống CM định danh thống nhất mọi danh mục cấu hình. Điều này cũng đòi hỏi các sửa đổi danh mục cấu hình mang lại một định danh mới, duy nhất được gán cho danh mục cấu hình.

ACM_CAP.3.8C đưa ra một yêu cầu là cần có bằng chứng thể hiện rằng hệ thống CM hoạt động tuân theo kế hoạch CM. Ví dụ các bằng chứng có thể là tài liệu như là bản chụp màn hình hoặc kết quả vết kiểm toán đưa ra từ hệ thống CM, hoặc một công bố chi tiết về hệ thống CM bởi nhà phát triển. Đánh giá viên có trách nhiệm xác định bằng chứng nào là đủ để chỉ ra rằng hệ thống CM hoạt động tuân theo kế hoạch CM.

ALC_CMC4.5C đưa ra một yêu cầu là hệ thống CM cung cấp một phương pháp tự động để hỗ trợ sản phẩm TOE. Điều này đòi hỏi hệ thống CM cung cấp một phương pháp hỗ trợ việc xác định rằng danh mục cấu hình chính xác đã được sử dụng để tạo ra TOE.

ALC_CMC5.10C đưa ra một yêu cầu là hệ thống CM cung cấp một phương pháp tự động để xác nhận những thay đổi của TOE và phiên bản trước đó. Nếu không có phiên bản trước đó của TOE, nhà phát triển vẫn cần cung cấp một phương pháp để xác nhận sự thay đổi của TOE và phiên bản tương lai.

13.1.4. ALC_CMC.1 Gán nhãn TOE

Các mối phụ thuộc: ALC_CMS.1 TOE CM Tổng quát

13.1.4.1. Mục tiêu

Một tham chiếu duy nhất được yêu cầu để đảm bảo rằng không có sự mơ hồ về trường hợp TOE được đánh giá. Gán nhãn TOE với tham chiếu đó đảm bảo rằng người sử dụng TOE có thể nhận thức được tình huống TOE nào thì họ sử dụng.

13.1.4.2. Các thành phần hành động nhà phát triển

13.1.4.2.1. ALC_CMC.1.1D

Nhà phát triển cần cung cấp TOE và một tham chiếu đến TOE.

13.1.4.3. Các phần tử nội dung và trình bày

13.1.4.3.1. ALC_CMC.1.1C

TOE cần được gán nhãn bằng tham chiếu duy nhất của nó.

13.1.4.4. Các phần tử hành động của đánh giá viên

13.1.4.4.1. ALC_CMC.1.1E

Đánh giá viên cần xác nhận rằng thông tin đưa ra thỏa mãn tất cả các yêu cầu về nội dung và thể hiện của chứng cứ.

13.1.5. ALC_CMC.2 Sử dụng hệ thống CM

Các mối phụ thuộc: ALC_CMS.1 TOE CM Tổng quát

13.1.5.1. Mục tiêu

Một tham chiếu duy nhất được yêu cầu để đảm bảo rằng không có sự mơ hồ về bản TOE đang được đánh giá. Gán nhãn TOE với tham chiếu đó đảm bảo rằng người sử dụng TOE có thể nhận thức được bản TOE nào họ đang sử dụng.

Định danh duy nhất của danh mục cấu hình dẫn đến việc hiểu rõ ràng về việc tổng hợp TOE, từ đó giúp xác định các mục nào cần đối với các yêu cầu đánh giá TOE.

Việc sử dụng một hệ thống CM làm tăng tính bảo đảm rằng danh mục cấu hình đang được duy trì có kiểm soát.

13.1.5.2. Phần tử hành động của nhà phát triển

13.1.5.2.1. ALC_CMC.2.1D

Nhà phát triển cần cung cấp TOE và một tham chiếu đến TOE.

13.1.5.2.2. ALC_CMC2.2D

Nhà phát triển cần cung cấp tài liệu CM

13.1.5.2.3. ALC_CMC2.3D

Nhà phát triển cần sử dụng một hệ thống CM

13.1.5.3. Các phần tử nội dung và trình bày

13.1.5.3.1. ALC_CMC2.1C

TOE cần gán nhãn với tham chiếu duy nhất của nó.

13.1.5.3.2. ALC_CMC2.2C

Tài liệu CM cần miêu tả phương thức sử dụng để xác định một cách duy nhất danh mục cấu hình.

13.1.5.3.3. ALC_CMC2.3C

Hệ thống CM cần xác định một cách duy nhất tất cả các mục cấu hình.

13.1.5.4. Các phần tử hành động của đánh giá viên

13.1.5.4.1. ACM_CMC.2.1E

Đánh giá viên cần xác nhận rằng thông tin được đưa ra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.

13.1.6. ALC_CMC.3 Kiểm soát cấp phép

Các mối phụ thuộc:

ALC_CMS.1 TOE CM Tổng quát

ALC_DVS.1 xác định các biện pháp an toàn

ALC_LCD.1 mô hình vòng đời xác định bởi nhà phát triển

13.1.6.1. Mục tiêu

Một tham chiếu duy nhất được yêu cầu để đảm bảo rằng không có sự mơ hồ về trường hợp TOE được đánh giá. Gán nhãn TOE với tham chiếu đó đảm bảo rằng người sử dụng TOE có thể nhận thức được tình huống TOE nào thì họ sử dụng.

Sự xác định duy nhất của danh mục cấu hình hướng dẫn để hiểu rõ hơn cấu trúc TOE, nó giúp xác định danh mục nào là chính đối với các yêu cầu đánh giá cho TOE.

Việc sử dụng một hệ thống CM làm tăng tính đảm bảo rằng danh mục cấu hình đang được duy trì có kiểm soát.

Cung cấp kiểm soát để đảm bảo rằng các thay đổi trái phép không xảy ra trong TOE (“kiểm soát truy nhập CM”), đảm bảo chức năng thích hợp và sử dụng của hệ thống CM, giúp để duy trì tính toàn vẹn trong TOE.

13.1.6.2. Phần tử hành động của nhà phát triển

13.1.6.2.1. ACM_CMC.3.1D

Nhà phát triển cần cung cấp TOE và một tham chiếu đến TOE.

13.1.6.2.2. ACM_CMC.3.2D

Nhà phát triển cần cung cấp tài liệu CM

13.1.6.2.3. ACM_CMC.3.3D

Nhà phát triển cần sử dụng hệ thống CM.

13.1.6.3. Các phần tử nội dung và trình bày

13.1.6.3.1. ACM_CMC.3.1C

TOE cần được gán nhãn với tham chiếu duy nhất của nó.

13.1.6.3.2. ACM_CMC.3.2C

Tài liệu CM cần miêu tả phương thức sử dụng để xác định một cách duy nhất danh mục cấu hình.

13.1.6.3.3. ACM_CMC.3.3C

Hệ thống CM cần xác định một cách duy nhất tất cả các mục cấu hình.

13.1.6.3.4. ACM_CMC.3.4C

Hệ thống CM cần cung cấp các biện pháp như chỉ các thay đổi hợp lệ mới được chấp nhận cho các mục cấu hình.

13.1.6.3.5. ACM_CMC.3.5C

Tài liệu CM cần bao gồm kế hoạch CM.

13.1.6.3.6. ACM_CMC.3.6C

Kế hoạch CM cần mô tả hệ thống CM được dùng để phát triển TOE như thế nào.

13.1.6.3.7. ACM_CMC.3.7C

Bằng chứng cần chứng tỏ rằng tất cả các mục cấu hình đang được duy trì bởi hệ thống CM.

13.1.6.3.8. ACM_CMC.3.8C

Bằng chứng cần chứng tỏ rằng hệ thống CM đang hoạt động theo kế hoạch CM.

13.1.6.4. Các phần tử hành động của đánh giá viên

13.1.6.4.1. ACM_CMC.3.1E

Đánh giá viên cần xác nhận rằng thông tin được đưa ra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.

13.1.7. ACM_CMC.4 Hỗ trợ sản xuất và các thủ tục chấp nhận và tự động hóa

Các mối phụ thuộc:

ALC_CMS.1 TOE CM Tổng quát

ALC_DVS.1 xác định các biện pháp an toàn

ALC_LCD.1 mô hình vòng đời xác định bởi nhà phát triển

13.1.7.1. Mục tiêu

Một tham chiếu duy nhất được yêu cầu để đảm bảo rằng không có sự mơ hồ về trường hợp TOE được đánh giá. Gán nhãn TOE với tham chiếu đó đảm bảo rằng người sử dụng TOE có thể nhận thức được tình huống TOE nào thì họ sử dụng.

Sự xác định duy nhất của danh mục cấu hình hướng dẫn để hiểu rõ hơn cấu trúc TOE, nó giúp xác định danh mục nào là chính đối với các yêu cầu đánh giá cho TOE.

Sử dụng hệ thống CM tăng cường đảm bảo rằng các danh mục cấu hình được duy trì một cách có kiểm soát.

Cung cấp kiểm soát để đảm bảo rằng các thay đổi trái phép không xảy ra trong TOE (“kiểm soát truy nhập CM”), và đảm bảo chức năng thích hợp và sử dụng của hệ thống CM, giúp để duy trì tính toàn vẹn trong TOE.

Mục đích của các thủ tục chấp nhận là đảm bảo rằng các phần của TOE có chất lượng phù hợp và khẳng định rằng mọi sự tạo mới hoặc sửa đổi danh mục cấu hình là được phép. Các thủ tục chấp nhận là một phần tử quan trọng trong các quy trình tích hợp và trong quản lý vòng đời của TOE.

Trong các môi trường phát triển với danh mục cấu hình phức tạp, rất khó có thể kiểm soát thay đổi mà không có sự hỗ trợ của các công cụ tự động hóa. Cụ thể là các công cụ tự động hóa này cần thiết để có thể hỗ trợ một số lớn các thay đổi xuất hiện trong phát triển và đảm bảo rằng các thay đổi đó là được phép. Một mục tiêu của thành phần này là đảm bảo rằng danh mục cấu hình được kiểm soát thông qua phương pháp tự động hóa. Nếu TOE được phát triển bởi nhiều nhà phát triển, nghĩa là có sự tích hợp, sử dụng công cụ tự động hóa là điều hợp lý.

Các thủ tục hỗ trợ sản xuất giúp đảm bảo rằng việc sinh ra TOE từ một tập danh mục cấu hình có kiểm soát được thực hiện chính xác theo phương thức được phép, cụ thể là trong trường hợp khi có nhiều nhà phát triển khác nhau liên quan và các quy trình tích hợp khác nhau cần thực hiện.

13.1.7.2. Phần tử hành động của nhà phát triển

13.1.7.2.1. ACM_CMC.4.1D

Nhà phát triển cần cung cấp TOE và một tham chiếu đến TOE.

13.1.7.2.2. ACM_CMC.4.2D

Nhà phát triển cần cung cấp tài liệu CM.

13.1.7.2.3. ACM_CMC.4.3D

Nhà phát triển cần sử dụng một hệ thống CM.

13.1.7.3. Các phần tử nội dung và trình bày

13.1.7.3.1. ALC_CMC.4.1C

TOE cần được gán nhãn với tham chiếu duy nhất của nó.

13.1.7.3.2. ALC_CMC.4.2C

Tài liệu CM cần miêu tả phương thức sử dụng để xác định một cách duy nhất danh mục cấu hình.

13.1.7.3.3. ALC_CMC.4.3C

Hệ thống CM cần xác định một cách duy nhất tất cả các mục cấu hình.

13.1.7.3.4. ALC_CMC.4.4C

Hệ thống CM cần cung cấp các biện pháp tự động hóa để chỉ các thay đổi hợp lệ mới được chấp nhận đối với các mục cấu hình.

13.1.7.3.5. ALC_CMC.4.5C

Hệ thống CM cần hỗ trợ sự sản xuất TOE bằng phương thức tự động.

13.1.7.3.6. ALC_CMC.4.6C

Tài liệu CM cần bao gồm kế hoạch CM.

13.1.7.3.7. ALC_CMC.4.7C

Kế hoạch CM cần mô tả hệ thống CM được dùng để phát triển TOE như thế nào.

13.1.7.3.8. ALC_CMC.4.8C

Kế hoạch CM cần mô tả các thủ tục sử dụng để chấp nhận các thay đổi hoặc các mục cấu hình được tạo mới như là một phần của TOE.

13.1.7.3.9. ALC_CMC.4.9C

Bằng chứng cần chứng tỏ rằng tất cả các mục cấu hình đang được duy trì dưới hệ thống CM.

13.1.7.3.10. ALC_CMC.4.10C

Bằng chứng cần chứng tỏ rằng hệ thống CM đang được hoạt động phù hợp với kế hoạch CM.

13.1.7.4. Các phần tử hành động của đánh giá viên

13.1.7.4.1. ALC_CMC.4.1E

Đánh giá viên cần xác nhận rằng thông tin đưa ra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.

13.1.8. ALC_CMC.5 Hỗ trợ cải tiến

Các mối phụ thuộc:

ALC_CMS.1 TOE CM Tổng quát

ALC_DVS.2 Sự đầy đủ của các biện pháp an toàn

ALC_LCD.1 mô hình vòng đời xác định bởi nhà phát triển

13.1.8.1. Mục tiêu

Một tham chiếu duy nhất được yêu cầu để đảm bảo rằng không có sự mơ hồ về trường hợp TOE được đánh giá. Gán nhãn TOE với tham chiếu đó đảm bảo rằng người sử dụng TOE có thể nhận thức được tình huống TOE nào thì họ sử dụng.

Sự xác định duy nhất của danh mục cấu hình hướng dẫn để hiểu rõ hơn cấu trúc TOE, nó giúp xác định danh mục nào là chính đối với các yêu cầu đánh giá cho TOE.

Sử dụng hệ thống CM tăng cường đảm bảo rằng các danh mục cấu hình được duy trì một cách có kiểm soát.

Cung cấp kiểm soát để đảm bảo rằng các thay đổi trái phép không xảy ra trong TOE (“kiểm soát truy nhập CM”), và đảm bảo chức năng thích hợp và sử dụng của hệ thống CM, giúp để duy trì tính toàn vẹn trong TOE.

Mục đích của các thủ tục chấp nhận là đảm bảo rằng các phần của TOE, có chất lượng phù hợp và khẳng định rằng mọi sự tạo mới hoặc sửa đổi danh mục cấu hình là được phép. Các thủ tục chấp nhận là một phần tử quan trọng trong các quy trình tích hợp và trong quản lý vòng đời của TOE.

Trong các môi trường phát triển với danh mục cấu hình phức tạp, rất khó có thể kiểm soát thay đổi mà không có sự hỗ trợ của các công cụ tự động hóa. Cụ thể là các công cụ tự động hóa này cần thiết để có thể hỗ trợ một số lớn các thay đổi xuất hiện trong phát triển và đảm bảo rằng các thay đổi đó là được phép. Một mục tiêu của thành phần này là đảm bảo rằng danh mục cấu hình được kiểm soát thông qua phương pháp tự động hóa. Nếu TOE được phát triển bởi nhiều nhà phát triển, nghĩa là có sự tích hợp, sử dụng công cụ tự động hóa là điều hợp lý.

Các thủ tục hỗ trợ sản xuất giúp đảm bảo rằng việc sinh ra TOE từ một tập danh mục cấu hình có kiểm soát được thực hiện chính xác theo phương thức được phép, cụ thể là trong trường hợp khi có nhiều nhà phát triển khác nhau liên quan và các quy trình tích hợp khác nhau cần thực hiện.

Yêu cầu là hệ thống CM cần có khả năng xác định phiên bản biểu diễn triển khai để tạo ra TOE. Điều đó sẽ giúp đảm bảo rằng tính toàn vẹn của tài liệu này được bảo vệ phù hợp về mặt kỹ thuật, vật lý và quy trình.

Cung cấp một phương thức tự động hóa để xác nhận các thay đổi phiên bản của TOE, xác định ra các mục cấu hình nào bị ảnh hưởng bởi việc sửa đổi các mục cấu hình khác và hỗ trợ việc xác định ảnh hưởng của thay đổi giữa các phiên bản trước đó của TOE. Từ đó giúp cung cấp thông tin quý giá để xác định xem các thay đổi TOE mang đến cho mọi danh mục cấu hình có đang nhất quán với nhau hay không.

13.1.8.2. Phần tử hành động của nhà phát triển

13.1.8.2.1. ALC_CMC.5.1D

Nhà phát triển cần cung cấp TOE và một tham chiếu đến TOE.

13.1.8.2.2. ALC_CMC.5.2D

Nhà phát triển cần cung cấp tài liệu CM.

13.1.8.2.3. ALC_CMC.5.3D       

Nhà phát triển cần sử dụng một hệ thống CM.

13.1.8.3. Các phần tử nội dung và trình bày

13.1.8.3.1. ALC_CMC.5.1C

TOE cần được gán nhãn với tham chiếu duy nhất của nó.

13.1.8.3.2. ALC_CMC.5.2C

Tài liệu CM cần miêu tả phương thức sử dụng để xác định một cách duy nhất danh mục cấu hình.

13.1.8.3.3. ALC_CMC.5.3C

Tài liệu CM cần điều chỉnh để các thủ tục chấp thuận cung cấp một soát xét đầy đủ và thích hợp các thay đổi đối với tất cả các mục cấu hình.

13.1.8.3.4. ALC_CMC.5.4C

Hệ thống CM cần xác định một cách duy nhất tất cả các mục cấu hình.

13.1.8.3.5. ALC_CMC.5.5C

Hệ thống CM cần cung cấp các biện pháp tự động để chỉ các thay đổi hợp lệ mới được chấp nhận đối với các mục cấu hình.

13.1.8.3.6. ALC_CMC.5.6C

Hệ thống CM cần hỗ trợ sản xuất TOE bằng cách tự động.

13.1.8.3.7. ALC_CMC.5.7C

Hệ thống CM cần bảo đảm rằng người chịu trách nhiệm chấp nhận một mục cấu hình vào CM không phải là nhà phát triển nó.

13.1.8.3.8. ALC_CMC.5.8C

Hệ thống CM cần xác thực các mục cấu hình có trong TSF.

13.1.8.3.9. ALC_CMC.5.9C

Hệ thống CM cần hỗ trợ kiểm toán tất cả sự thay đổi TOE theo phương thức tự động hóa, bao gồm người khởi xướng, ngày và thời gian trong vết kiểm toán.

13.1.8.3.10. ALC_CMC.5.10C

Hệ thống CM cần cung cấp một phương thức tự động để xác định mọi mục cấu hình khác bị ảnh hưởng bởi sự thay đổi của một mục cấu hình đã cho.

13.1.8.3.11. ALC_CMC.5.11C

Hệ thống CM cần có khả năng xác định phiên bản biểu diễn triển khai tạo ra TOE.

13.1.8.3.12. ALC_CMC.5.12C

Tài liệu CM cần bao gồm kế hoạch CM.

13.1.8.3.13. ALC_CMC.5.13C

Kế hoạch CM cần mô tả hệ thống CM được dùng để phát triển TOE như thế nào.

13.1.8.3.14. ALC_CMC.5.14C

Kế hoạch CM cần mô tả các thủ tục sử dụng để chấp nhận các thay đổi hoặc các mục cấu hình được tạo mới như là một phần của TOE.

13.1.8.3.15. ALC_CMC.5.15C

Bằng chứng cần chứng tỏ rằng tất cả các mục cấu hình đang được duy trì dưới hệ thống CM.

13.1.8.3.16. ALC_CMC.5.16C

Bằng chứng cần chứng tỏ rằng hệ thống CM đang được hoạt động phù hợp với kế hoạch CM.

13.1.8.4. Các phần tử hành động của đánh giá viên

13.1.8.4.1. ALC_CMC.5.1E

Đánh giá viên cần xác nhận rằng thông tin đưa ra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.

13.1.8.4.2. ALC_CMC.5.2E

Đánh giá viên cần xác định rằng việc áp dụng các thủ tục hỗ trợ sản xuất sẽ tạo ra TOE như đã được nhà phát triển đưa ra cho các hoạt động kiểm thử.

13.2. Phạm vi CM (ALC_CMS)

13.2.1. Mục tiêu

Mục tiêu của họ này là xác định các mục cần đưa vào danh mục cấu hình và vì vậy đưa vào dưới dạng các yêu cầu CM về năng lực CM (ALC_CMC). Áp dụng quản lý cấu hình cho các mục bổ sung này đưa ra sự đảm bảo rằng tính toàn vẹn của TOE được duy trì.

13.2.2. Phân mức thành phần

Các thành phần trong họ này được phân mức trên cơ sở những gì sau đây được yêu cầu đưa vào danh mục cấu hình: TOE và bằng chứng đánh giá đòi hỏi bởi các SÁ; các phần của TOE; biểu diễn triển khai; các lỗi an toàn; các công cụ phát triển và thông tin liên quan.

13.2.3. Chú thích ứng dụng

Mặc dù phạm vi CM (ALC_CMS) đòi hỏi một danh sách các mục cấu hình và mỗi mục trong danh sách này thuộc CM, năng lực CM (ALC_CMC) dành phần cụ thể hóa nội dung của danh sách cấu hình cho nhà phát triển. Phạm vi CM (ALC_CMS) hạn chế bớt việc cụ thể hóa này bằng việc xác định các mục bắt buộc phải có trong danh sách cấu hình, do vậy có trong các yêu cầu CM về năng lực CM (ALC_CMC).

13.2.4. ALC_CMS.1 TOE CM Tổng quát

Các mối phụ thuộc: Không có các mối phụ thuộc.

13.2.4.1. Mục tiêu

Một hệ thống CM có thể kiểm soát các thay đổi chỉ với các mục đã đưa vào CM (nghĩa là các mục cấu hình đã xác định trong danh sách cấu hình). Việc đặt bản thân TOE và bằng chứng đánh giá yêu cầu bởi các SAR khác trong ST dưới CM đưa ra sự bảo đảm về việc chúng đã được sửa đổi theo phương thức có kiểm soát với việc cấp quyền chính xác.

13.2.4.2. Chú thích ứng dụng

ALC_CMS.1.1C đưa ra yêu cầu về việc bản thân TOE và bằng chứng đánh giá yêu cầu bởi các SAR khác trong ST đã có trong danh sách cấu hình, và do vậy là chủ thể cho các yêu cầu CM về năng lực CM (ALC_CMC).

13.2.4.3. Phần tử hành động của nhà phát triển

13.2.4.3.1. ALC_CMS.1.1D

Nhà phát triển cần cung cấp một danh sách cấu hình cho TOE.

13.2.4.4. Các phần tử nội dung và trình bày

13.2.4.1. ALC_CMS.1.1C

Danh sách cấu hình cần chứa thông tin sau: bản thân TOE; bằng chứng đánh giá đòi hỏi bởi các SAR.

13.2.4.4.2. ALC_CMS.1.2C

Danh sách cấu hình cần xác định duy nhất các mục cấu hình.

13.2.4.5. Các phần tử hành động của đánh giá viên

13.2.4.5.1. ALC_CMS.1.1E

Đánh giá viên cần xác nhận rằng thông tin đưa ra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.

13.2.5. ALC_CMS.2 Các phần của TOE CM tổng quát

Các mối phụ thuộc: Không có các mối phụ thuộc.

13.2.5.1. Mục tiêu

Một hệ thống CM có thể kiểm soát các thay đổi chỉ với các mục đã đưa vào CM (nghĩa là các mục cấu hình đã xác định trong danh sách cấu hình). Việc đặt bản thân TOE, các thành phần cấu thành TOE, và bằng chứng đánh giá yêu cầu bởi các SAR dưới CM đưa ra sự bảo đảm về việc chúng đã được sửa đổi theo phương thức có kiểm soát với các quyền hợp thức.

13.2.5.2. Chú thích ứng dụng

ALC_CMS.2.1C đưa ra yêu cầu các thành phần cấu thành TOE (tất cả các phần được chuyển giao cho khách hàng, ví dụ như các thành phần phần cứng, hoặc các tệp thi hành được) đã được đưa vào danh sách cấu hình, và do vậy là chủ thể cho các yêu cầu CM về năng lực CM (ALC_CMC).

ALC_CMS.2.3.C đưa ra yêu cầu về việc danh sách cấu hình chỉ ra nhà phát triển của mỗi mục cấu hình liên quan đến TSF. Khái niệm “Nhà phát triển” ở đây không có nghĩa là một người cụ thể mà là một tổ chức có trách nhiệm phát triển danh mục cấu hình.

13.2.5.3. Phần tử hành động của nhà phát triển

13.2.5.3.1. ALC_CMS.2.1D

Nhà phát triển cần cung cấp một danh sách cấu hình cho TOE.

13.2.5.4. Các phần tử nội dung và trình bày

13.2.5.4.1. ALC_CMS.2.1C

Danh sách cấu hình cần chứa thông tin sau: bản thân TOE; bằng chứng đánh giá đòi hỏi bởi các SAR, tất cả các thành phần cấu hình TOE.

13.2.5.4.2. ALC_CMS.2.2C

Danh sách cấu hình cần xác định duy nhất các mục cấu hình.

13.2.5.4.3. ALC_CMS.2.3C

Đối với mỗi mục cấu hình liên quan TSF, danh sách cấu hình cần chỉ ra nhà phát triển của mục đó.

13.2.5.5. Các phần tử hành động của đánh giá viên

13.2.5.5.1. ALC_CMS.2.1E

Đánh giá viên cần xác nhận rằng thông tin đưa ra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.

13.2.6. ALC_CMS.3 Biểu diễn triển khai CM tổng quát

Các mối phụ thuộc: Không có các mối phụ thuộc.

13.2.6.1. Mục tiêu

Một hệ thống CM có thể kiểm soát các thay đổi chỉ với các mục đã đưa vào CM (nghĩa là các mục cấu hình đã xác định trong danh sách cấu hình). Việc đặt bản thân TOE, các thành phần cấu thành TOE, biểu diễn triển khai TOE và bằng chứng đánh giá yêu cầu bởi các SAR dưới CM đưa ra sự bảo đảm về việc chúng đã được sửa đổi theo phương thức có kiểm soát với các quyền hợp thức.

13.2.6.2. Chú thích ứng dụng

ALC_CMS.3.1C đưa ra yêu cầu về việc biểu diễn triển khai TOE đã được đưa vào danh sách cấu hình, và do vậy là chủ thể cho các yêu cầu CM về năng lực CM (ALC_CMC).

13.2.6.3. Phần tử hành động của nhà phát triển

13.2.6.3.1. ALC_CMS.3.1D

Nhà phát triển cần cung cấp một danh sách cấu hình cho TOE.

13.2.6.4. Các phần tử nội dung và trình bày

13.2.6.4.1. ALC_CMS.3.1C

Danh sách cấu hình cần chứa thông tin sau: bản thân TOE; bằng chứng đánh giá đòi hỏi bởi các SAR, tất cả các thành phần cấu thành TOE; biểu diễn triển khai TOE.

13.2.6.4.2. ALC_CMS.3.2C

Danh sách cấu hình cần xác định duy nhất các mục cấu hình.

13.2.6.4.3. ALC_CMS.3.3C

Đối với mỗi mục cấu hình liên quan TSF, danh sách cấu hình cần chỉ ra nhà phát triển của mục đó.

13.2.6.5. Các phần tử hành động của đánh giá viên

13.2.6.5.1. ALC_CMS.3.1E

Đánh giá viên cần xác nhận rằng thông tin đưa ra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.

13.2.7. ALC_CMS.4 Theo dấu vết vấn đề CM tổng quát

Các mối phụ thuộc: Không có các mối phụ thuộc.

13.2.7.1. Mục tiêu

Một hệ thống CM có thể kiểm soát các thay đổi chỉ với các mục đã đưa vào CM (nghĩa là các mục cấu hình đã xác định trong danh sách cấu hình). Việc đặt bản thân TOE, các thành phần cấu thành TOE, và bằng chứng đánh giá yêu cầu bởi các SAR dưới CM đưa ra sự bảo đảm về việc chúng đã được sửa đổi theo phương thức có kiểm soát với các quyền hợp thức.

Đặt các lỗi an toàn dưới CM đảm bảo rằng báo cáo về lỗi an toàn không bị mất hoặc bỏ quên, cho phép nhà phát triển theo dấu lỗi an toàn và giải quyết chúng.

13.2.7.2. Chú thích ứng dụng

ALC_CMS.4.1C đưa ra yêu cầu các lỗi an toàn được đưa vào danh sách cấu hình, và do vậy là chủ thể cho các yêu cầu CM về năng lực CM (ALC_CMC). Điều này đòi hỏi thông tin liên quan đến các lỗi an toàn trước đó và việc giải quyết chúng cần được duy trì, cũng như các chi tiết liên quan đến các lỗi an toàn hiện tại.

13.2.7.3. Phần tử hành động của nhà phát triển

13.2.7.3.1. ALC_CMS.4.1D

Nhà phát triển cần cung cấp một danh sách cấu hình cho TOE.

13.2.7.4. Các phần tử nội dung và trình bày

13.2.7.4.1. ALC_CMS.4.1C

Danh sách cấu hình cần chứa thông tin sau: bản thân TOE; bằng chứng đánh giá đòi hỏi bởi các SAR, tất cả các thành phần cấu thành TOE, biểu diễn triển khai TOE; các báo cáo lỗi an toàn và trạng thái giải quyết.

13.2.7.4.2. ALC_CMS.4.2C

Danh sách cấu hình cần xác định duy nhất các mục cấu hình.

13.2.7.4.3. ALC_CMS.4.3C

Đối với mỗi cấu hình liên quan TSF, danh sách cấu hình cần chỉ ra nhà phát triển của mục đó.

13.2.7.5. Các phần tử hành động của đánh giá viên

13.2.7.5.1. ALC_CMS.4.1E

Đánh giá viên cần xác nhận rằng thông tin đưa ra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.

13.2.8. ALC_CMS.5 Các công cụ phát triển CM Tổng quát

Các mối phụ thuộc: Không có các mối phụ thuộc.

13.2.8.1. Mục tiêu

Một hệ thống CM có thể kiểm soát các thay đổi chỉ với các mục đã đưa vào CM (nghĩa là các mục cấu hình đã xác định trong danh sách cấu hình). Việc đặt bản thân TOE, các thành phần cấu thành TOE, và bằng chứng đánh giá yêu cầu bởi các SAR dưới CM đưa ra sự bảo đảm về việc chúng đã được sửa đổi theo phương thức có kiểm soát với các quyền hợp thức.

Đặt các lỗi an toàn dưới CM đảm bảo rằng báo cáo về lỗi an toàn không bị mất hoặc bỏ quên, cho phép nhà phát triển theo dấu lỗi an toàn và giải quyết chúng.

Các công cụ phát triển đóng một vai trò quan trọng nhằm đảm bảo sản xuất ra một phiên bản TOE chất lượng. Do đó, việc kiểm soát các sửa đổi các công cụ này là rất quan trọng.

13.2.8.2. Chú thích ứng dụng

ALC_CMS.5.1C đưa ra yêu cầu về việc các công cụ phát triển và thông tin liên quan được đưa vào danh sách cấu hình, và do vậy là chủ thể cho các yêu cầu CM về năng lực CM (ALC_CMC).

Ví dụ về các công cụ phát triển là các ngôn ngữ lập trình, các trình biên dịch. Thông tin gắn liền với các mục tạo ra TOE (như tùy chọn trình biên dịch, tùy chọn tạo phần mềm, tùy chọn tạo tệp thực thi) là ví dụ về thông tin liên quan đến các công cụ phát triển.

13.2.8.3. Phần tử hành động của nhà phát triển

13.2.8.3.1. ALC_CMS.5.1D

Nhà phát triển cần cung cấp một danh sách cấu hình cho TOE.

13.2.8.4. Các phần tử nội dung và trình bày

13.2.8.4.1. ALC_CMS.5.1C

Danh sách cấu hình cần chứa thông tin sau: bản thân TOE; bằng chứng đánh giá đòi hỏi bởi các SAR, tất cả các thành phần cấu thành TOE, biểu diễn triển khai TOE; các báo cáo lỗi an toàn và trạng thái giải quyết; các công cụ phát triển và thông tin liên quan.

13.2.8.4.2. ALC_CMS.5.2C

Danh sách cấu hình cần xác định duy nhất các mục cấu hình.

13.2.8.4.3. ALC_CMS.5.3C

Đối với mỗi mục cấu hình liên quan TSF, danh sách cấu hình cần chỉ ra nhà phát triển của mục đó.

13.2.8.5. Các phần tử hành động của đánh giá viên

13.2.8.5.1. ALC_CMS.5.1E

Đánh giá viên cần xác nhận rằng thông tin đưa ra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.

13.3. Chuyển giao (ALC_DEL)

13.3.1. Mục tiêu

Mối quan tâm của họ này là truyền một cách an toàn TOE đã hoàn thiện từ môi trường phát triển sang trách nhiệm của người dùng.

Các yêu cầu cho chuyển giao đòi hỏi các phương tiện kiểm soát hệ thống và phân phối, các thủ tục chỉ ra chi tiết các biện pháp cần thiết nhằm đưa ra sự bảo đảm rằng an toàn của TOE được duy trì trong suốt quá trình phân phối TOE tới người dùng. Cho việc phân phối hợp lệ TOE, các thủ tục sử dụng cho phân phối TOE xem xét Mục tiêu đã xác định trong PP/ST liên quan đến an toàn của TOE trong chuyển giao.

13.3.2. Phân mức thành phần

Họ này chỉ chứa một thành phần. Mức tăng dần tính bảo vệ được tạo ra qua việc đòi hỏi tính tương xứng của các thủ tục chuyển giao với tiềm năng tấn công giả thuyết có trong họ Phân tích điểm yếu (AVA_VAN).

13.3.3. Chú thích ứng dụng

Việc vận chuyển từ nhà thầu phụ tới nhà phát triển hoặc giữa các điểm phát triển khác nhau không được xem xét ở đây mà ở họ An toàn phát triển (ALC_DVS).

Kết thúc chu trình chuyển giao đánh dấu bởi việc vận chuyển TOE tới tay người dùng. Điều này không nhất thiết phải có nghĩa là việc TOE đến tận địa điểm người dùng.

Các thủ tục chuyển giao cần xem xét, nếu có thể, các vấn đề sau:

a) đảm bảo rằng TOE được nhận bởi khách hàng tương ứng chính xác với phiên bản đã đánh giá của TOE;

b) tránh hoặc phát hiện các giả mạo với phiên bản thực tế của TOE;

c) ngăn chặn gửi phiên bản TOE sai;

d) tránh phân phối TOE một cách quá lộ liễu tới khách hàng: có thể xem những trường hợp hạn chế tin tặc biết rõ về việc TOE được chuyển giao khi nào và như thế nào;

e) tránh hoặc phát hiện việc TOE bị can thiệp trong quá trình chuyển giao;

f) tránh việc gửi TOE bị trễ hoặc chặn khi phân phối.

Các thủ tục chuyển giao cần đưa ra các hành động của người nhận sẵn sàng đối với các vấn đề trên. Mô tả nhất quán các hành động sẵn sàng nêu trên được kiểm tra trong họ “Các thủ tục chuẩn bị” (AGD_PRE), nếu có.

13.3.4. ALC_DEL.1 Các thủ tục chuyển giao

Các mối phụ thuộc: Không có các mối phụ thuộc.

13.3.4.1. Phần tử hành động của nhà phát triển

13.3.4.1.1. ALC_DEL.1.1D

Nhà phát triển cần văn bản hóa các thủ tục chuyển giao TOE hoặc các thành phần của nó tới người tiêu dùng.

13.3.4.1.2. ALC_DEL.2.1D

Nhà phát triển cần sử dụng các thủ tục chuyển giao.

13.3.4.2. Các phần tử nội dung và trình bày

13.3.4.2.1. ALC_DEL.1.1C

Tài liệu chuyển giao cần mô tả mọi thủ tục cần thiết để duy trì an toàn khi phân phối các phiên bản TOE tới người tiêu dùng.

13.3.4.3. Các phần tử hành động của đánh giá viên

13.3.4.3.1. ALC_DEL.1.1E

Đánh giá viên cần xác nhận rằng thông tin đưa ra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.

13.4. An toàn phát triển (ALC_DVS)

13.4.1. Mục tiêu

An toàn phát triển liên quan đến các biện pháp vật lý, quy trình, nhân sự và các biện pháp an toàn khác có thể dùng trong môi trường phát triển nhằm bảo vệ TOE và các thành phần của nó. Nó bao gồm an toàn vật lý cho địa điểm phát triển, các quy trình dùng để chọn lựa nhân viên phát triển.

13.4.2. Phân mức thành phần

Các thành phần trong họ này được phân mức trên cơ sở có cần điều chỉnh về việc các biện pháp an toàn đã đầy đủ hay chưa.

13.4.3. Chú thích ứng dụng

Họ này liên quan đến các biện pháp nhằm loại bỏ hoặc giảm thiểu nguy cơ tồn tại ở phía nhà phát triển.

Đánh giá viên nên tham quan các địa điểm nhằm đánh giá chứng cứu về an toàn phát triển. Việc này có thể bao gồm các địa điểm của các nhà thầu phụ liên quan đến phát triển và sản xuất TOE. Mọi quyết định về việc không đến tham quan cần được phép của cơ quan đánh giá.

Mặc dù an toàn phát triển liên quan đến việc duy trì TOE và do vậy đến các yếu tố có thể liên quan sau khi kết thúc đánh giá, các yêu cầu An toàn phát triển (ALC_DVS) chỉ đặc trưng rằng các biện pháp an toàn phát triển đã có ở thời điểm đánh giá. Ngoài ra an toàn phát triển (ALC_DVS) không chứa bất kỳ yêu cầu nào liên quan đến ý định của nhà tài trợ về việc áp dụng các biện pháp an toàn phát triển trong tương lai, sau khi kết thúc đánh giá.

Có thể thấy là tính tin cậy không phải lúc nào cũng là vấn đề đối với việc bảo vệ TOE trong môi trường phát triển. Việc sử dụng từ “cần thiết” cho phép chọn lựa sự bảo vệ phù hợp.

13.4.4. ALC_DVS.1 Định danh các biện pháp an toàn

Các mối phụ thuộc: không có sự phụ thuộc nào.

13.4.4.1. Phần tử hành động của nhà phát triển.

13.4.4.1.1. ALC_DVS.1.1D

Nhà phát triển cần tạo ra tài liệu an toàn phát triển.

13.4.4.2. Các phần tử nội dung và trình bày

13.4.4.2.1. ALC_DVS.1.1C

Tài liệu an toàn phát triển cần mô tả tất cả các biện pháp vật lý, thủ tục, nhân sự và các biện pháp an toàn khác cần thiết để bảo vệ tính tin cậy và tính toàn vẹn của thiết kế và thực thi TOE trong môi trường phát triển của nó.

13.4.4.3. Các phần tử hành động của đánh giá viên

13.4.4.3.1. ALC_DVS.1.1E

Đánh giá viên cần khẳng định rằng thông tin được cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng cớ.

13.4.4.3.2. ALC_DVS.1.2E

Đánh giá viên cần khẳng định rằng các biện pháp an toàn đang được áp dụng.

13.4.5. ALC_DVS.2 Sự đầy đủ các biện pháp an toàn

Các mối phụ thuộc: không có sự phụ thuộc nào.

13.4.5.1. Phần tử hành động của nhà phát triển

13.4.5.1.1. ALC_DVS.2.1D

Nhà phát triển cần tạo ra tài liệu an toàn phát triển.

13.4.5.2. Các phần tử nội dung và trình bày

13.4.5.2.1. ALC_DVS.2.1C

Tài liệu an toàn phát triển cần mô tả tất cả các biện pháp vật lý, thủ tục, nhân sự và các biện pháp an toàn khác mà cần để bảo vệ tính tin cậy và tính toàn vẹn của thiết kế và thực thi TOE trong môi trường phát triển của nó.

13.4.5.2.2. ALC_DVS.2.2C

Tài liệu an toàn phát triển cần biện minh về việc các biện pháp an toàn đưa ra mức độ bảo vệ cần thiết nhằm duy trì tính tin cậy và toàn vẹn cho TOE.

13.4.5.3. Các phần tử hành động của đánh giá viên

13.4.5.3.1. ALC_DVS.2.1E

Đánh giá viên cần khẳng định rằng thông tin được cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng cớ.

13.4.5.3.2. ALC_DVS.2.2E

Đánh giá viên cần khẳng định rằng các biện pháp an toàn đang được áp dụng.

13.5. Sửa lỗi (ALC_FLR)

13.5.1. Mục tiêu

Sửa lỗi yêu cầu các lỗi an toàn phát hiện được phải do nhà phát triển lần theo dấu vết và sửa chữa. Dù cho sự tương thích tương lai với các thủ tục sửa lỗi không thể xác định được tại thời điểm đánh giá TOE, thì vẫn có thể đánh giá các thủ tục và chính sách mà nhà phát triển đang có để lần theo dấu vết và sửa lỗi, và để phân loại các chỉnh sửa và thông tin lỗi.

13.5.2. Phân mức thành phần

Các thành phần trong họ này được phân mức trên cơ sở của việc mở rộng phạm vi các thủ tục sửa lỗi và tính chính xác của các thủ tục sửa lỗi.

13.5.3. Chú thích ứng dụng

Họ này đảm bảo rằng TOE được bảo hành và hỗ trợ trong tương lai, yêu cầu nhà phát triển TOE lần theo dấu vết và sửa các lỗi trong TOE. Hơn nữa, các yêu cầu được kèm theo khi phân loại sửa lỗi. Tuy nhiên, họ này không áp đặt các yêu cầu đánh giá ngoài đánh giá hiện tại.

Người sử dụng TOE được coi là tâm điểm của đơn vị sử dụng mà chịu trách nhiệm nhận và thực hiện chữa các lỗi an toàn. Đó không cần phải là cá nhân người sử dụng, mà có thể là đại diện của tổ chức người chịu trách nhiệm khắc phục lỗi an toàn. Việc sử dụng thuật ngữ người sử dụng TOE nhận ra rằng các tổ chức khác nhau có các thủ tục khác nhau trong xử lý báo cáo lỗi, mà có thể do cá nhân người sử dụng hoặc do một cơ quan quản lý trung tâm thực hiện.

Các thủ tục sửa lỗi cần mô tả các phương pháp để xử lý với tất cả các kiểu lỗi gặp phải. Các lỗi này có thể do nhà phát triển, do những người sử dụng của TOE, hoặc các bên khác quen thuộc với TOE báo cáo. Một số lỗi có thể không được sửa ngay lập tức. Có thể có một số trường hợp mà lỗi không thể xử lý được ngay mà phải thực hiện các biện pháp khác (ví dụ biện pháp thủ tục). Những tài liệu ghi lại được đưa ra có thể khôi phục các thủ tục để cung cấp cho nơi vận hành các xử lý, và cung cấp thông tin về các lỗi mà việc xử lý đã hoãn lại (và làm gì trong tạm thời) hoặc khi mà việc sửa chữa là không thể.

Các thay đổi đối với TOE sau khi phát hành được coi là chưa đánh giá; mặc dù một số thông tin từ bản đánh giá chính thức vẫn có thể áp dụng. Cụm từ “phát hành TOE” dùng trong họ này do đó tham chiếu đến một phiên bản của một sản phẩm là phát hành một TOE đã chứng nhận với các thay đổi đã áp dụng.

13.5.4. ALC_FLR.1 Sửa lỗi cơ bản

Tính Các mối phụ thuộc: không có sự phụ thuộc nào

13.5.4.1. Phần tử hành động của nhà phát triển

13.5.4.1.1. ALC_FLR.1.1D

Nhà phát triển cần văn bản hóa các thủ tục sửa lỗi chỉ định cho nhà phát triển TOE.

13.5.4.2. Các phần tử nội dung và trình bày

13.5.4.2.1. ALC_FLR.1.1C

Tài liệu các thủ tục sửa lỗi cần mô tả các thủ tục được sử dụng để theo dấu tất cả các lỗi an toàn đã báo cáo trong mỗi phát hành của TOE.

13.5.4.2.2. ALC_FLR.1.2C

Các thủ tục sửa lỗi cần yêu cầu việc mô tả bản chất và ảnh hưởng của từng lỗi an toàn được cung cấp, cũng như hiện trạng tìm thấy cách sửa lỗi đó.

13.5.4.2.3. ALC_FLR.1.3C

Các thủ tục sửa lỗi cần yêu cầu các hành động sửa chữa được xác định cho từng lỗi an toàn.

13.5.4.2.4. ALC_FLR.1.4C

Tài liệu các thủ tục sửa lỗi cần mô tả các phương pháp sử dụng để cung cấp thông tin, sửa chữa, hướng dẫn về các hành động sửa lỗi cho người sử dụng TOE.

13.5.4.3. Các phần tử hành động của đánh giá viên

13.5.4.3.1. ALC_FLR.1.1E

Đánh giá viên cần khẳng định rằng thông tin được cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng cứ.

13.5.5. ALC_FLR.2 Các thủ tục báo cáo lỗi

Tính Các mối phụ thuộc: không có sự phụ thuộc nào.

13.5.5.1. Mục tiêu

Để nhà phát triển có thể hành động phù hợp với các báo cáo lỗi an toàn từ những người sử dụng TOE, và để biết ai gửi các xử lý sửa chữa, người sử dụng TOE cần hiểu cách gửi báo cáo lỗi an toàn tới nhà phát triển thế nào. Hướng dẫn sửa lỗi từ nhà phát triển tới người sử dụng TOE đảm bảo rằng những người sử dụng TOE nhận thức được thông tin quan trọng này.

13.5.5.2. Phần tử hành động của nhà phát triển

13.5.5.2.1. ALC_FLR.2.1D

Nhà phát triển cần văn bản hóa các thủ tục sửa lỗi chỉ định cho nhà phát triển TOE.

13.5.5.2.2. ALC_FLR.2.2D

Nhà phát triển cần tạo ra một thủ tục để chấp nhận và hành động khi có mọi báo cáo lỗi an toàn và các yêu cầu sửa chữa đối với các lỗi đó.

13.5.5.2.3. ALC_FLR.2.3D

Nhà phát triển cần cung cấp hướng dẫn sửa lỗi chỉ định cho người sử dụng TOE

13.5.5.3. Các phần tử nội dung và trình bày

13.5.5.3.1. ALC_FLR.2.1C

Tài liệu các thủ tục sửa lỗi cần mô tả các thủ tục được sử dụng để lần theo dấu vết tất cả các lỗi an toàn đã báo cáo trong mỗi phát hành của TOE.

13.5.5.3.2. ALC_FLR.2.2C

Các thủ tục sửa lỗi cần yêu cầu việc mô tả bản chất và ảnh hưởng của từng lỗi an toàn được cung cấp, cũng như hiện trạng tìm thấy cách sửa lỗi đó.

13.5.5.3.3. ALC_FLR.2.3C

Các thủ tục sửa lỗi cần yêu cầu các hành động sửa chữa được xác định cho từng lỗi an toàn.

13.5.5.3.4. ALC_FLR.2.4C

Tài liệu các thủ tục sửa lỗi cần mô tả các phương pháp được sử dụng để cung cấp hướng dẫn, sửa chữa, thông tin lỗi trong các hành động sửa lỗi cho người sử dụng TOE.

13.5.5.3.5. ALC_FLR.2.5C

Các thủ tục sửa lỗi cần mô tả các phương thức nhà phát triển nhận các báo cáo từ người sử dụng TOE và các yêu cầu về lỗi an toàn nghi ngờ trong TOE.

13.5.5.3.6. ALC_FLR.2.6C

Các thủ tục xử lý các lỗi an toàn đã báo cáo cần đảm bảo rằng bất cứ lỗi đã báo cáo nào đang được sửa và việc sửa chữa đã được báo cho người dùng TOE.

13.5.5.3.7. ALC_FLR.2.7C

Các thủ tục xử lý lỗi an toàn đã báo cáo cần cung cấp sự bảo vệ an toàn sao cho bất cứ sửa chữa nào đối với lỗi an toàn này không làm nảy sinh các lỗi nào mới.

13.5.5.3.8. ALC_FLR.2.8C

Hướng dẫn sửa lỗi cần mô tả các phương thức người sử dụng TOE báo cáo cho nhà phát triển về bất cứ lỗi an toàn khả nghi nào trong TOE.

13.5.5.4. Các phần tử hành động của đánh giá viên

13.5.5.4.1. ALC_FLR.2.1E

Đánh giá viên cần khẳng định rằng thông tin được cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng cớ.

13.5.6. ALC_FLR.3 Sửa lỗi hệ thống

Các mối phụ thuộc: không có sự phụ thuộc nào.

13.5.6.1. Mục tiêu

Để nhà phát triển có thể hành động phù hợp với các báo cáo lỗi an toàn từ những người sử dụng TOE, và để biết ai gửi các xử lý sửa chữa, người sử dụng TOE cần hiểu cách gửi báo cáo lỗi an toàn tới nhà phát triển thế nào. Hướng dẫn sửa lỗi từ nhà phát triển tới người sử dụng TOE đảm bảo rằng những người sử dụng TOE nhận thức được thông tin quan trọng này.

13.5.6.2. Phần tử hành động của nhà phát triển

13.5.6.2.1. ALC_FLR.3.1D

Nhà phát triển cần văn bản hóa các thủ tục sửa lỗi chỉ định cho nhà phát triển TOE.

13.5.6.2.2. ALC_FLR.3.2D

Nhà phát triển cần tạo ra một thủ tục để chấp nhận và hành động khi có mọi báo cáo lỗi an toàn và các yêu cầu sửa chữa đối với các lỗi đó.

13.5.6.2.3. ALC_FLR.3.3D

Nhà phát triển cần cung cấp hướng dẫn sửa lỗi chỉ định cho người sử dụng TOE

13.5.6.3. Các phần tử nội dung và trình bày

13.5.6.3.1. ALC_FLR.3.1C

Tài liệu các thủ tục sửa lỗi cần mô tả các thủ tục được sử dụng để lần theo dấu vết tất cả các lỗi an toàn đã báo cáo trong mỗi phát hành của TOE.

13.5.6.3.2. ALC_FLR.3.2C

Các thủ tục sửa lỗi cần yêu cầu việc mô tả bản chất và ảnh hưởng của từng lỗi an toàn được cung cấp, cũng như hiện trạng tìm thấy cách sửa lỗi đó.

13.5.6.3.3. ALC_FLR.3.3C

Các thủ tục sửa lỗi cần yêu cầu các hành động sửa chữa được xác định cho từng lỗi an toàn.

13.5.6.3.4. ALC_FLR.3.4C

Tài liệu các thủ tục sửa lỗi cần mô tả các phương pháp được sử dụng để cung cấp hướng dẫn, sửa chữa, thông tin lỗi trong các hành động sửa lỗi cho người sử dụng TOE.

13.5.6.3.5. ALC_FLR.3.5C

Các thủ tục sửa lỗi cần mô tả các phương thức nhà phát triển nhận các báo cáo từ người sử dụng TOE và các yêu cầu về lỗi an toàn nghi ngờ trong TOE.

13.5.6.3.6. ALC_FLR.3.6C

Các thủ tục xử lý các lỗi an toàn đã báo cáo cần gồm một thủ tục yêu cầu phản hồi kịp thời và phân phối tự động các báo cáo lỗi an toàn cũng như các sửa đổi liên quan tới người dùng đã đăng ký đã có thể chịu ảnh hưởng của lỗi an toàn.

13.5.6.3.7. ALC_FLR.3.7C

Các thủ tục xử lý các lỗi an toàn đã báo cáo cần đảm bảo rằng bất cứ lỗi đã báo cáo nào đang được sửa và việc sửa chữa đã được báo cho người dùng TOE.

13.5.6.3.8. ALC_FLR.3.8C

Các thủ tục xử lý lỗi an toàn đã báo cáo cần cung cấp sự bảo vệ an toàn cho bất cứ sửa chữa nào đối với lỗi an toàn này không làm nảy sinh các lỗi nào mới.

13.5.6.3.9. ALC_FLR.3.9C

Hướng dẫn sửa lỗi cần mô tả các phương thức người sử dụng TOE báo cáo cho nhà phát triển về bất cứ lỗi an toàn khả nghi nào trong TOE.

13.5.6.3.10. ALC_FLR.3.10C

Hướng dẫn sửa lỗi cần mô tả phương thức người dùng TOE có thể đăng ký với nhà phát triển nhằm có thể nhận được các báo cáo và sửa chữa lỗi an toàn một cách hợp thức.

13.5.6.3.11. ALC_FLR.3.11C

Hướng dẫn sửa lỗi cần xác định các đầu mối liên lạc cụ thể cho tất cả các báo cáo và yêu cầu về các vấn đề an toàn liên quan đến TOE.

13.5.6.4. Các phần tử hành động của đánh giá viên

13.5.6.4.1. ALC_FLR.3.1E

Đánh giá viên sẽ khẳng định rằng thông tin được cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng cớ.

13.6. Định nghĩa vòng đời (ALC_LCD)

13.6.1. Mục tiêu

Việc phát triển và duy trì TOE với kiểm soát nghèo nàn có thể mang lại một TOE không đáp ứng được tất cả các yêu cầu an toàn SFRs của nó. Do đó, điều quan trọng là cần tạo ra một mô hình cho phát triển và duy trì TOE càng sớm càng tốt trong vòng đời của TOE.

Sử dụng một mô hình cho việc phát triển và duy trì TOE không bảo đảm rằng TOE đáp ứng được tất cả các yêu cầu chức năng an toàn SFRs của nó. Có thể là một mô hình được chọn sẽ thiếu hoặc không thỏa đáng và do đó sẽ không thấy lợi ích về chất lượng của TOE. Việc sử dụng một mô hình vòng đời đã được một số nhóm các chuyên gia phê duyệt (ví dụ các chuyên gia hàn lâm, các cơ quan định chuẩn) làm tăng cơ hội cho các mô hình phát triển và duy trì nhằm làm cho TOE đáp ứng các SFRs của nó. Sử dụng một mô hình vòng đời bao hàm một số định lượng sẽ làm tăng tính đảm bảo về chất lượng chung của quy trình phát triển TOE.

13.6.2. Phân mức thành phần

Các thành phần trong họ này được phân mức trên cơ sở các yêu cầu tăng dần về định lượng của mô hình vòng đời, và việc tương thích với mô hình đó.

13.6.3. Chú thích ứng dụng

Một mô hình vòng đời chứa đựng các thủ tục, công cụ và kỹ thuật được sử dụng để phát triển và duy trì TOE. Các khía cạnh của quá trình có thể được bao hàm bởi một mô hình như vậy gồm các phương pháp thiết kế, các thủ tục soát xét, các biện pháp quản lý dự án, các thủ tục kiểm soát thay đổi, các phương pháp kiểm thử và các thủ tục chấp nhận. Một mô hình vòng đời hiệu quả sẽ chỉ ra những khía cạnh này của quá trình phát triển và duy trì này trong một cấu trúc quản lý tổng thể chỉ định trách nhiệm và qui trình giám sát.

Có nhiều kiểu tình huống chấp thuận khác nhau liên quan đến các vị trí khác nhau trong tiêu chí: chấp thuận các thành phần chuyển giao từ các nhà thầu phụ (“tích hợp”) nên được xem trong họ Định nghĩa vòng đời (ALC_LCD) này, chấp thuận liên quan đến vận chuyển nội bộ trong An toàn phát triển (ALC_DVS), chấp thuận các thành phần vào hệ thống CM trong năng lực CM (ALC_CMC), chấp thuận của người tiêu dùng với TOE đã chuyển giao trong họ Chuyển giao (ALC_DEL). Ba kiểu đầu tiên có thể giao nhau.

Mặc dù định nghĩa vòng đời liên quan đến duy trì TOE và do đó các khía cạnh trở lên thích hợp sau khi hoàn tất việc đánh giá, việc đánh giá nó bổ sung thêm sự đảm bảo thông qua phân tích thông tin vòng đời cho TOE được cung cấp tại thời điểm đánh giá.

Một mô hình vòng đời cung cấp biện pháp quản lý cần thiết trong phát triển và duy trì TOE, nếu mô hình cho phép tối thiểu hóa vừa đủ nguy cơ TOE không đáp ứng yêu cầu an toàn của nó.

Một mô hình vòng đời là mô hình dùng một số giá trị định lượng (tham số số học và/hoặc số đo) cho sản phẩm được quản lý nhằm đo lường các đặc điểm phát triển sản phẩm. Các số đo điển hình là số đo độ phức tạp của mã nguồn, mật độ lỗi (số lỗi trên kích thước mã nguồn) hoặc thời gian lỗi trung bình. Đối với đánh giá an toàn, mọi số đo trên đều phù hợp, chúng được sử dụng để tăng chất lượng bằng cách giảm xác suất lỗi, do đó tăng tính bảo đảm an toàn cho TOE.

Cần lưu ý một điều là sẵn có các mô hình vòng đời tiêu chuẩn (ví dụ mô hình thác nước), mặt khác cũng có các đại lượng đo tiêu chuẩn (ví dụ mật độ lỗi) và chúng có thể kết hợp với nhau. TCVN 8709 không yêu cầu vòng đời phải tuân theo chính xác một tiêu chuẩn phản ánh cả hai khía cạnh trên.

13.6.4. ALC-LCD.1 Mô hình vòng đời định nghĩa bởi nhà phát triển

Các mối phụ thuộc: không có sự phụ thuộc nào

13.6.4.1. Phần tử hành động của nhà phát triển

13.6.4.1.1. ALC_LCD.1.1D

Nhà phát triển cần tạo ra mô hình vòng đời được sử dụng trong phát triển và duy trì của TOE.

13.6.4.1.2. ALC_LCD.1.2D

Nhà phát triển cần cung cấp tài liệu định nghĩa vòng đời.

13.6.4.2. Các phần tử nội dung và trình bày

13.6.4.2.1. ALC_LCD.1.1C

Tài liệu định nghĩa vòng đời cần mô tả mô hình được sử dụng để phát triển và duy trì TOE.

13.6.4.2.2. ALC_LCD.1.2C

Mô hình vòng đời cần cung cấp kiểm soát cần thiết cho việc phát triển và duy trì TOE.

13.6.4.3. Các phần tử hành động của đánh giá viên

13.6.4.3.1. ALC_LCD.1.1E

Đánh giá viên cần khẳng định rằng thông tin được cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng cớ.

13.6.5. ALC_LCD.2 Mô hình vòng đời định lượng

Tính Các mối phụ thuộc: không có sự phụ thuộc nào

13.6.5.1. Phần tử hành động của nhà phát triển

13.6.5.1.1. ALC_LCD.2.1D

Nhà phát triển cần tạo ra mô hình vòng đời được sử dụng trong phát triển và duy trì của TOE, và nó được dựa trên một mô hình vòng đời định lượng.

13.6.5.1.2. ALC_LCD.2.2D

Nhà phát triển cần cung cấp tài liệu định nghĩa vòng đời.

13.6.5.1.3. ALC_LCD.2.3D

Nhà phát triển cần đo lường việc phát triển TOE sử dụng một mô hình vòng đời định lượng.

13.6.5.2. Nội dung và trình bày của phần tử chứng cớ

13.6.5.2.1. ALC_LCD.2.1C

Tài liệu định nghĩa vòng đời cần mô tả mô hình được sử dụng để phát triển và duy trì TOE, bao gồm các chi tiết về tham số số học của nó và/hoặc các số đo dùng để đo lường chất lượng TOE và/hoặc việc phát triển nó.

13.6.5.2.2. ALC_LCD.2.2C

Mô hình vòng đời cần cung cấp kiểm soát cần thiết cho việc phát triển và duy trì TOE.

13.6.5.2.3. ALC_LCD.2.3C

Tài liệu đầu ra của vòng đời cần đưa ra kết quả về các phép đo sự phát triển TOE với mô hình vòng đời định lượng.

13.6.5.3. Phần tử hành động đánh giá viên

13.6.5.3.1. ALC_LCD.2.1E

Đánh giá viên cần khẳng định rằng thông tin được cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng cớ.

13.7. Các công cụ và các kỹ thuật (ALC_TAT)

13.7.1. Mục tiêu

Các công cụ và kỹ thuật là một khía cạnh chọn lựa công cụ được sử dụng để phát triển, phân tích và triển khai TOE. Nó bao gồm các yêu cầu tránh các công cụ phát triển không đúng, mâu thuẫn, mập mờ khi sử dụng phát triển TOE. Điều này bao gồm, nhưng không giới hạn, cả các ngôn ngữ lập trình, tài liệu, các chuẩn triển khai, các thành phần khác của TOE ví như là hỗ trợ thư viện thời gian thực.

13.7.2. Phân mức thành phần

Các thành phần trong họ này được phân mức trên cơ sở các yêu cầu tăng dẫn về mô tả và phạm vi của các tiêu chuẩn triển khai và tài liệu về các tùy chọn phụ thuộc triển khai.

13.7.3. Chú thích ứng dụng

Có một yêu cầu đối với các công cụ phát triển được xác định rõ. Đó là các công cụ được mô tả rõ ràng và đầy đủ. Ví dụ, các ngôn ngữ lập trình và các hệ thống thiết kế có trợ giúp của máy tính (CAD) chúng đều dựa trên một tiêu chuẩn đã công bố bởi các cơ quan tiêu chuẩn và được xem là xác định rõ. Các công cụ tự làm cần được xem xét thêm nhằm làm rõ chúng có thuộc loại xác định rõ hay không.

Yêu cầu trong ALC_TAT.1.2C được áp dụng đặc biệt cho các ngôn ngữ lập trình để đảm bảo rằng tất cả các tuyên bố trong mã nguồn đều có một nghĩa rõ ràng.

Trong ALC_TAT.2 và ALC_TAT.3, các hướng dẫn triển khai có thể được chấp nhận làm tiêu chuẩn triển khai nếu như chúng được phê chuẩn bởi một số nhóm chuyên gia (ví dụ chuyên gia khoa học, các cơ quan tiêu chuẩn). Các tiêu chuẩn triển khai thường công khai, được chấp thuận rộng rãi và thực hành chung trong một lĩnh vực đặc trưng, tuy nhiên các hướng dẫn triển khai đặc trưng của nhà phát triển cũng có thể được chấp nhận làm tiêu chuẩn; quan trọng là ý kiến chuyên gia.

Các công cụ và kỹ thuật phân biệt giữa các tiêu chuẩn triển khai áp dụng bởi nhà phát triển (ALC_TAT.2.3D) và các tiêu chuẩn triển khai cho “mọi thành phần TOE” (ALC_TAT.3.3D) trong đó bao gồm phần mềm, phần cứng hoặc phần sụn của bên thứ ba. Danh sách cấu hình có trong phạm vi CM (ALC_CMS) đòi hỏi rằng mỗi mục cấu hình tương ứng TSF biểu thị việc nó được tạo ra bởi nhà phát triển TOE hay nhà phát triển bên thứ ba.

13.7.4. ALC_TAT.1 Các công cụ phát triển được định nghĩa rõ ràng.

Các mối phụ thuộc: ADV_IMP.1 Biểu diễn triển khai của TSF

13.7.4.1. Phần tử hành động của nhà phát triển

13.7.4.1.1. ALC_TAT.1.1D

Nhà phát triển cần xác định mọi công cụ phát triển được sử dụng cho TOE

13.7.4.1.2. ALC_TAT.1.2D

Nhà phát triển cần văn bản hóa các tùy chọn phụ thuộc triển khai đã được lựa chọn cho mỗi công cụ phát triển.

13.7.4.2. Các phần tử nội dung và trình bày

13.7.4.2.1. ALC_TAT.1.1C

Mọi công cụ phát triển sử dụng cho triển khai cần xác định rõ ràng.

13.7.4.2.2. ALC_TAT.1.2C

Tài liệu cho mỗi công cụ phát triển cần định nghĩa rõ ràng ý nghĩa của tất cả các tuyên bố cũng như các quy ước và các chỉ dẫn sử dụng trong triển khai.

13.7.4.2.3. ALC_TAT.1.3C

Tài liệu cho mỗi công cụ phát triển cần định nghĩa rõ ràng ý nghĩa của tất cả các tùy chọn phụ thuộc triển khai.

13.7.4.3. Các phần tử hành động của đánh giá viên

13.7.4.3.1. ALC_TAT.1.1E

Đánh giá viên cần khẳng định rằng thông tin được cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng cớ.

13.7.5. ALC_TAT.2 Tương thích với các tiêu chuẩn triển khai

Các mối phụ thuộc: ADV_IMP.1 Biểu diễn triển khai của TSF

13.7.5.1. Phần tử hành động của nhà phát triển

13.7.5.1.1. ALC_TAT.2.1D

Nhà phát triển cần xác định mọi công cụ phát triển sử dụng cho TOE

13.7.5.1.2. ALC_TAT.2.2D

Nhà phát triển cần văn bản hóa các tùy chọn phụ thuộc triển khai đã được lựa chọn cho mỗi công cụ phát triển.

13.7.5.1.3. ALC_TAT.2.3D

Nhà phát triển cần mô tả các tiêu chuẩn triển khai đang được nhà phát triển áp dụng.

13.7.5.2. Các phần tử nội dung và trình bày

13.7.5.2.1. ALC_TAT.2.1C

Mọi công cụ phát triển sử dụng cho triển khai cần xác định rõ ràng.

13.7.5.2.2. ALC_TAT.2.2C

Tài liệu cho mỗi công cụ phát triển cần định nghĩa rõ ràng ý nghĩa của tất cả các tuyên bố cũng như các quy ước và các chỉ dẫn sử dụng trong triển khai.

13.7.5.2.3. ALC_TAT.2.3C

Tài liệu cho mỗi công cụ phát triển cần định nghĩa rõ ràng ý nghĩa của tất cả các tùy chọn phụ thuộc triển khai.

13.7.5.3. Các phần tử hành động của đánh giá viên

13.7.5.3.1. ALC_TAT.2.1E

Đánh giá viên cần khẳng định rằng thông tin được cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng cớ.

13.7.5.3.2. ALC_TAT.2.2E

Đánh giá viên cần khẳng định rằng các tiêu chuẩn triển khai đã được áp dụng.

13.7.6. ALC_TAT.3 Tương thích với tiêu chuẩn triển khai - tất cả các thành phần.

Tính phụ thuộc: ADV_IMP.1 Biểu diễn triển khai của TSF

13.7.6.1. Phần tử hành động của nhà phát triển

13.7.6.1.1. ALC_TAT.3.1D

Nhà phát triển cần xác định mọi công cụ phát triển sử dụng cho TOE

13.7.6.1.2. ALC_TAT.3.2D

Nhà phát triển cần văn bản hóa các tùy chọn phụ thuộc triển khai đã được lựa chọn cho mỗi công cụ phát triển.

13.7.6.1.3. ALC_TAT.3.3D

Nhà phát triển cần mô tả các tiêu chuẩn triển khai đang được nhà phát triển áp dụng và đang được áp dụng bởi mọi nhà cung cấp thứ ba cho mọi thành phần của TOE.

13.7.6.2. Các phần tử nội dung và trình bày

13.7.6.2.1. ALC_TAT.3.1C

Mọi công cụ phát triển sử dụng cho triển khai cần xác định rõ ràng.

13.7.6.2.2. ALC_TAT.3.2C

Tài liệu cho mỗi công cụ phát triển cần định nghĩa rõ ràng ý nghĩa của tất cả các tuyên bố cũng như các quy ước và các chỉ dẫn sử dụng trong triển khai.

13.7.6.2.3. ALC_TAT.3.3C

Tài liệu cho mỗi công cụ phát triển cần định nghĩa rõ ràng ý nghĩa của tất cả các tùy chọn phụ thuộc triển khai.

13.7.6.3. Các phần tử hành động của đánh giá viên

13.7.6.3.1. ALC_TAT.3.1E

Đánh giá viên cần khẳng định rằng thông tin được cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng cớ.

13.7.6.3.2. ALC_TAT.3.2E

Đánh giá viên cần khẳng định rằng các tiêu chuẩn triển khai đã được áp dụng.

14. Lớp ATE: Các kiểm thử

Lớp “Các kiểm thử” bao gồm 4 họ chính: Tổng quát (ATE_COV), Chuyên sâu (ATE_DPT), Kiểm thử độc lập (ATE_IND) (ví dụ kiểm thử chức năng bởi đánh giá viên) và Kiểm thử chức năng (ATE_FUN). Việc kiểm thử nhằm đảm bảo rằng TSF vận hành như đã mô tả (trong đặc tả chức năng, thiết kế TOE, và triển khai mẫu).

Điểm nhấn trong lớp này là khẳng định rằng TSF hoạt động theo như các mô tả thiết kế của nó. Lớp này không đề cập đến kiểm thử thâm nhập dựa trên việc phân tích TSF theo các tìm kiếm đặc trưng nhằm xác định các điểm yếu trong thiết kế và thực thi TSF. Kiểm thử thâm nhập được đề cập riêng trong mục đánh giá điểm yếu ở lớp AVA: đánh giá điểm yếu.

ATE: Lớp các kiểm thử phân chia việc kiểm thử thành các kiểm thử bởi nhà phát triển và các kiểm thử bởi đánh giá viên. Nhóm tổng quát (ATE_COV) và Chuyên sâu (ATE_DPT) đề cập đến tính đầy đủ của các kiểm thử bởi nhà phát triển. Tổng quát (ATE_COV) đề cập đến tính chặt chẽ cùng với đặc tả chức năng đã được kiểm thử; Chuyên sâu (ATE_DPT) đề cập đến việc có nên kiểm thử căn cứ vào các mô tả thiết kế khác (kiến trúc an toàn, thiết kế TOE, triển khai mẫu) đã được yêu cầu hay không.

Các kiểm thử chức năng đề cập đến việc thực hiện các kiểm thử bởi nhà phát triển và cách thức ghi lại bằng văn bản cho kiểm thử này như thế nào. Cuối cùng, kiểm thử độc lập (ATE_IND) đề cập đến việc kiểm thử bởi đánh giá viên: đánh giá viên nên lặp lại từng phần việc hoặc toàn bộ quá trình kiểm thử bởi nhà phát triển và bao nhiêu phép thử độc lập nên thực hiện.

Hình 14 trình bày các họ thuộc lớp này, và phân lớp các thành phần bên trong các họ.

Hình 14 - Phân rã lớp ATE: Kiểm thử

14.1. Tổng quát (ATE_COV)

14.1.1. Mục tiêu

Họ này xác minh rằng TSF đã được kiểm thử theo đặc tả chức năng của nó. Điều này đạt được thông qua việc kiểm tra chứng cứ tương ứng của nhà phát triển.

14.1.2. Phân mức thành phần

Các thành phần trong họ này được phân mức dựa vào đặc tả.

14.1.3. Chú thích ứng dụng

14.1.4. ATE_COV.1 Chứng cứ tổng quát

Các phụ thuộc:

ADV_FSP.2 Đặc tả chức năng thực thi an toàn

ATE_FUN.1 Kiểm thử chức năng

14.1.4.1. Mục tiêu

Mục tiêu của thành phần này là việc một số các TSFI đã được kiểm thử.

14.1.4.2. Chú thích ứng dụng

Trong thành phần này nhà phát triển chỉ ra các kiểm thử trong tài liệu kiểm thử tương ứng với các TSFI trong đặc tả chức năng như thế nào. Điều này có thể đạt được với một khai báo tương hợp, có thể sử dụng một bảng.

14.1.4.3. Phần tử hành động của nhà phát triển

14.1.4.3.1. ATE_COV.1.1D

Nhà phát triển cần đưa ra được chứng cứ của tổng quan kiểm thử.

14.1.4.4. Các phần tử nội dung và trình bày

14.1.4.4.1. ATE_COV.1.1C

Chứng cứ của tổng quan kiểm thử cần chỉ ra sự tương ứng giữa các kiểm thử trong tài liệu kiểm thử và các TSFI trong đặc tả chức năng.

14.1.4.5. Các phần tử hành động của đánh giá viên

14.1.4.5.1. ATE_COV.1.1E

Đánh giá viên sẽ xác nhận rằng thông tin đưa ra đáp ứng tất cả các yêu cầu về nội dung và biểu thị của chứng cứ.

14.1.5. ATE_COV.2. Phân tích tổng quát

Các phụ thuộc:

ADV_FSP.2 Đặc tả chức năng thực thi an toàn

ADV_FUN.1 Kiểm thử chức năng

14.1.5.1. Mục tiêu

Mục tiêu của thành phần này là xác nhận rằng tất cả các TSFI đã được kiểm thử.

14.1.5.2. Chú thích ứng dụng

Trong thành phần này, nhà phát triển xác nhận rằng các kiểm thử trong tài liệu kiểm thử tương ứng với tất cả các TSFI trong đặc tả chức năng. Điều này có thể đạt được được qua một khai báo tương ứng, có thể sử dụng một bảng, tuy nhiên nhà phát triển cũng đưa ra bản phân tích tổng quan kiểm thử.

14.1.5.3. Phần tử hành động của nhà phát triển

14.1.5.3.1. ATE_COV.2.1D

Nhà phát triển cần cung cấp bản phân tích tổng quan kiểm thử.

14.1.5.4. Các phần tử nội dung và trình bày

14.1.5.4.1. ATE_COV.2.1C

Bản phân tích tổng quan kiểm thử cần chỉ ra sự tương ứng giữa các kiểm thử trong tài liệu kiểm thử và các TSFI trong đặc tả chức năng.

14.1.5.4.2. ATE_COV.2.2C

Bản phân tích tổng quan kiểm thử cần minh chứng rằng tất cả các TSFI trong đặc tả chức năng đã được kiểm thử.

14.1.5.5. Phần tử hành động của đánh giá viên

14.1.5.5.1. ATE_COV.2.1E

Đánh giá viên cần xác nhận rằng thông tin có được đã đạt tất cả các yêu cầu về nội dung và hình thức của chứng cứ.

14.1.6. ATE_COV.3. Phân tích tổng quát chặt chẽ

Các phụ thuộc:

ADV_FSP.2 Đặc tả chức năng thực thi an toàn

ADV_FUN.1 Kiểm thử chức năng

14.1.6.1. Mục tiêu

Trong phần này, mục tiêu là xác nhận rằng nhà phát triển sản phẩm đã thực hiện các kiểm thử một cách toàn diện về tất cả những cái chung trong đặc tả chức năng.

Mục tiêu của phần này là xác nhận rằng toàn bộ tham số trong tất cả các TSFI đã được kiểm thử.

14.1.6.2. Chú thích ứng dụng

Ở phần này, nhà phát triển sản phẩm được yêu cầu chỉ ra xem các kiểm thử trong tài kiểm thử tương ứng với tất cả các TSFI trong đặc tả chức năng như thế nào. Điều này có thể được thực hiện bởi một khai báo tương ứng, cũng có thể sử dụng một bảng, ngoài ra, nhà phát triển sản phẩm được yêu cầu chứng minh rằng các kiểm thử sử dụng toàn bộ các tham số của tất các TSFI. Yêu cầu bổ sung này bao gồm việc kiểm thử giới hạn và kiểm thử phủ nhận. Kiểu kiểm thử này là không thấu đáo (toàn diện) bởi vì không phải mọi giá trị có thể của tham số đều mong muốn được kiểm tra.

14.1.6.3. Phần tử hành động của nhà phát triển

14.1.6.3.1. ATE_COV.3.1D

Nhà phát triển sản phẩm cần đưa ra bản phân tích tổng quan kiểm thử

14.1.6.4. Các phần tử nội dung và trình bày

14.1.6.4.1. ATE_COV.3.1C

Bản phân tích tổng quan kiểm thử cần đưa ra sự tương đương giữa các kiểm thử trong tài liệu kiểm thử và các TSFI trong đặc tả chức năng.

14.1.6.4.2. ATE_COV.3.2C

Bản phân tích tổng quan kiểm thử cần chỉ ra rằng tất cả các TSFI trong đặc tả chức năng đã được kiểm thử một cách hoàn chỉnh.

14.1.6.5. Phần tử hành động của đánh giá viên

14.1.6.5.1. ATE_COV.3.1E

Đánh giá viên cần xác nhận rằng các thông tin có được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.

14.2. Chuyên sâu (ATE_DPT)

14.2.1. Mục tiêu

Các thành phần trong họ này đề cập đến mức chi tiết mà TSF được kiểm thử bởi nhà phát triển. Việc kiểm thử TSF dựa vào các thông tin chuyên sâu nhận được từ các biểu diễn thiết kế bổ sung và các mô tả.

Mục đích là nhằm tính đến các nguy cơ bỏ qua một số lỗi trong giai đoạn triển khai TOE. Việc kiểm thử cho các giao diện đối nội chuyên biệt không những chỉ cung cấp sự đảm bảo cho các hành vi mong muốn vĩ mô như đã thể hiện trong TSF, mà còn đảm bảo các hành vi liên quan đến các cơ chế hoạt động bên trong.

14.2.2. Phân mức thành phần

Các thành phần trong nhóm kiểu thử này được phân theo cấp độ dựa trên cơ sở của mức độ chi tiết có được trong các miêu tả TSF, từ thiết kế TOE đến miêu tả thực thi. Các cấp độ này phản ánh các miêu tả của TSF thể hiện trong lớp ADV.

14.2.3. Chú thích ứng dụng

Thiết kế TOE mô tả các thành phần bên trong (“các hệ thống thành phần - subsystems) và có thể là các modul của TSF, cùng với sự mô tả về giao diện giữa các thành phần này và các mô đun. Chứng cứ của việc kiểm thử thiết kế TOE này cần phải chỉ ra rằng các giao diện bên trong đều đã qua kiểm thử và bảo đảm rằng nó vận hành như đã mô tả. Điều này có thể được thực hiện bằng cách tiến hành các kiểm thử liên quan đến các giao diện ngoài của TSF, hoặc kiểm thử “hệ thống thành phần” TOE hoặc các giao diện mô đun một cách biệt lập. Quá trình kiểm thử các giao diện bên trong có thể được tiến hành theo các cách thức trực tiếp hoặc gián tiếp. Trong trường hợp chậm trễ, thiết kế TOE cần đủ chi tiết để có thể hỗ trợ triển khai các kiểm thử trực tiếp.

Trong trường hợp ở phần mô tả tính đúng đắn về mặt kiến trúc của TSF có trích dẫn các cơ chế đặc biệt, thì các kiểm thử đã thực hiện bởi nhà phát triển sản phẩm cần phải chỉ ra rằng các cơ chế đều đã qua kiểm thử và bảo đảm rằng nó vận hành như đã mô tả.

Tại thành phần cao nhất của nhóm này, việc kiểm thử được thực hiện không chỉ theo thiết kế TOE mà còn theo sự mô tả thực thi.

14.2.4. ATE_DEPT.1 Kiểm thử: thiết kế cơ bản

Các phụ thuộc: 

ADV_ARC.1 Mô tả kiến trúc an toàn

ADV_TDS.2 Thiết kế kiến trúc

ATE_FUN.1 Kiểm thử chức năng

14.2.4.1. Mục tiêu

Các mô tả “hệ thống thành phần” của một TSF cung cấp sự mô tả ở mức độ cao về các quá trình vận hành nội tại của TSF. Việc kiểm thử ở cấp độ này của “các hệ thống thành phần” TOE nhằm đảm bảo rằng “các hệ thống thành phần” của một TSF vận hành và tác động lẫn nhau như đã được mô tả trong thiết kế TOE và mô tả kiến trúc an toàn.

14.2.4.2. Phần tử hành động của nhà phát triển

14.2.4.2.1. ATE_DPT.1.1D

Nhà phát triển sản phẩm cần trình ra được bản phân tích chuyên sâu của các kiểm thử đã tiến hành.

14.2.4.3. Các phần tử nội dung và trình bày

14.2.4.3.1. ATE_DPT.1.1C

Bản phân tích chuyên sâu cần chỉ ra sự tương ứng giữa các kiểm thử trong tài liệu kiểm thử và “các hệ thống thành phần” trong thiết kế TOE.

14.2.4.3.2. ATE_DPT.1.2C

Bản phân tích chuyên sâu cần chỉ ra rằng tất cả “các hệ thống thành phần” trong thiết kế TOE đã được kiểm thử.

14.2.4.4. Phần tử hành động của đánh giá viên

14.2.4.4.1. ATE_DTP.1.1E

Đánh giá viên cần xác nhận rằng các thông tin có được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.

14.2.5. ATE_DPT.2 Kiểm thử: các mô đun thực thi an toàn

Các phụ thuộc: 

ADV_ARC.1 Mô tả kiến trúc an toàn

ADV_TDS.3 Thiết kế mang tính mô đun cơ bản

ATE_FUN.1 Kiểm thử chức năng

14.2.5.1. Mục tiêu

“Hệ thống thành phần” và các mô tả mô đun của một TSF cung cấp sự mô tả ở mức độ cao về các quá trình vận hành nội tại của TSF, và sự mô tả các giao diện của các mô đun thực thi SFR của TSF. Việc kiểm thử ở cấp độ này của mô tả TOE nhằm đảm bảo rằng “các hệ thống thành phần” của một TSF và các mô đun thực thi SFR vận hành và tác động lẫn nhau như đã được mô tả trong thiết kế TOE và mô tả kiến trúc an toàn.

14.2.5.2. Phần tử hành động của nhà phát triển

14.2.5.2.1. ATE_DPT.2.1D

Nhà phát triển sản phẩm cần trình ra được bản phân tích về mức độ chi tiết (chuyên sâu) các kiểm thử đã tiến hành.

14.2.5.3. Các phần tử nội dung và trình bày

14.2.5.3.1. ATE_DPT.2.1C

Bản phân tích chuyên sâu cấn chỉ ra được sự tương ứng giữa các kiểm thử trong tài liệu kiểm thử và “các hệ thống thành phần” TSF và các mô đun thực thi SFR trong thiết kế TOE.

14.2.5.3.2. ATE_DPT.2.2C

Bản phân tích chuyên sâu của các kiểm thử đã tiến hành cần chỉ ra rằng “các hệ thống thành phần” TSF trong thiết kế TOE đã được kiểm thử.

14.2.5.3.3. ATE_DPT.2.3C

Bản phân tích chuyên sâu của các kiểm thử đã tiến hành cần chỉ ra rằng các mô đun thực thi SFR trong thiết kế TOE đã được kiểm thử.

14.2.5.4. Phần tử hành động của đánh giá viên

14.2.5.4.1. ATE_DPT.2.1E

Đánh giá viên cần xác nhận rằng các thông tin có được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.

14.2.6. ATE_DEPT.3 Kiểm thử. Thiết kế mang tính mô đun.

Các phụ thuộc:

ADV_ARC.1 Mô tả kiến trúc an toàn.

ADV_TDS.4 Thiết kế mang tính mô đun nửa chính thức

ATE_FUN.1 Kiểm thử chức năng

14.2.6.1. Mục tiêu

“Các hệ thống thành phần” và các mô tả mô đun của một TSF đưa ra sự mô tả mức cao quá trình vận hành nội tại của TSF và sự mô tả các giao diện của các mô đun của TSF. Việc kiểm thử ở cấp độ này của mô tả TOE nhằm đảm bảo rằng “các hệ thống thành phần” TSF và các mô đun vận hành và tác động lẫn nhau như đã được mô tả trong thiết kế TOE và mô tả kiến trúc an toàn.

14.2.6.2. Phần tử hành động của nhà phát triển

14.2.6.2.1. ATE_DPT.3.1D

Nhà phát triển sản phẩm cần trình ra được bản phân tích chuyên sâu các kiểm thử đã tiến hành.

14.2.6.3. Các phần tử nội dung và trình bày

14.2.6.3.1. ATE_DPT.3.1C

Bản phân tích chuyên sâu của việc kiểm thử cấn chỉ ra sự tương ứng giữa các kiểm thử trong tài liệu kiểm thử và “các hệ thống thành phần” TSF và các mô đun trong thiết kế.

14.2.6.3.2. ATE_DPT.3.2C

Bản phân tích chuyên sâu của việc kiểm thử cấn chỉ ra rằng tất cả “các hệ thống thành phần” TSF trong thiết kế TOE đã được kiểm thử.

14.2.6.3.3. ATE_DPT.3.3C

Bản phân tích chuyên sâu của việc kiểm thử cấn chỉ ra rằng tất cả các mô đun TSF trong thiết kế TOE đã được kiểm thử.

14.2.6.4. Phần tử hành động của đánh giá viên

14.2.6.4.1. ATE_DTP.3.1E

Đánh giá viên cần xác nhận rằng các thông tin có được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.

14.2.7. ATE_DPT.4 Kiểm thử: Biểu diễn thực thi

Các phụ thuộc:

ADV_ARC.1 Mô tả kiến trúc an toàn

ADV_TDS.4 Thiết kế mang tính mô đun nửa chính thức

ADV_IMP.1 Sự thực thi của TSF

ATE_FUN.1 Kiểm thử chức năng

14.2.7.1. Mục tiêu

“Hệ thống thành phần” và các mô tả mô đun của một TSF đưa ra sự mô tả mức cao quá trình vận hành nội tại của TSF và sự mô tả các giao diện của các mô đun của TSF. Việc kiểm thử ở cấp độ này của mô tả TOE nhằm đảm bảo rằng “các hệ thống thành phần” TSF và các mô đun vận hành và tác động lẫn nhau như đã được mô tả trong thiết kế TOE và mô tả kiến trúc an toàn, và theo đúng biểu diễn thực thi.

14.2.7.2. Phần tử hành động của nhà phát triển

14.2.7.2.1. ATE_DPT.4.1D

Nhà phát triển sản phẩm cần trình ra được bản phân tích chuyên sâu các kiểm thử đã tiến hành.

14.2.7.3. Các phần tử nội dung và trình bày

14.2.7.3.1. ATE_DPT.4.1C

Bản phân tích chuyên sâu của việc kiểm thử cấn chỉ ra sự tương ứng giữa các kiểm thử trong tài liệu kiểm thử và “các hệ thống thành phần” TSF và các mô đun trong thiết kế.

14.2.7.3.2. ATE_DPT.4.2C

Bản phân tích chuyên sâu của việc kiểm thử cấn chỉ ra rằng tất cả “các hệ thống thành phần” TSF trong thiết kế TOE đã được kiểm thử.

14.2.7.3.3. ATE_DPT.4.3C

Bản phân tích chuyên sâu của việc kiểm thử cấn chỉ ra rằng TSF hoạt động theo đúng như biểu diễn thực thi.

14.2.7.4. Phần tử hành động của đánh giá viên

14.2.7.4.1. ATE_DTP.4.1E

Đánh giá viên cần xác nhận rằng các thông tin có được đã được tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.

14.3. Các kiểm thử chức năng (ATE_FUN)

14.3.1. Mục tiêu

Việc kiểm thử chức năng được các nhà phát triển sản phẩm tiến hành nhằm đảm bảo rằng các kiểm thử trong tài liệu kiểm thử được thực hiện và đưa thành tài liệu một cách đúng đắn. Sự tương ứng của các kiểm thử này với mô tả thiết kế TSF có được thông qua các họ Tổng quan (ATE-COV) và Chiều sâu (ATE-DPT).

Họ này góp phần vào việc đảm bảo rằng xác suất có các lỗi không bị phát hiện trong sản phẩm là tương đối nhỏ.

Tập hợp các loại kiểm thử bao gồm nhóm (họ/lớp): Tổng quan (ATE_COV), chuyên sâu ATE_DPT), và nhóm các kiểm thử chức năng (ATE_FUN) được sử dụng kết hợp nhằm định dạng các chứng cứ kiểm thử được nhà phát triển sản phẩm cung cấp (cùng với sản phẩm). Việc kiểm thử chức năng không phụ thuộc được thực hiện bởi đánh giá viên sản phẩm được phân loại vào nhóm “kiểm thử không phụ thuộc” (ATE_IDN).

14.3.2. Phân mức thành phần

Các thành phần thuộc nhóm kiểm thử này được phân làm 2 cấp độ. Trong đó, ở thành phần ở cấp độ cao hơn, các kiểm thử phụ thuộc kèm theo sẽ phải được phân tích cặn kẽ.

14.3.3. Chú thích ứng dụng

Các quy trình của các kiểm thử cần được tiến hành chính là các hướng dẫn nhằm sử dụng chương trình kiểm thử cũng như làm chủ các thiết bị hoặc công nghệ liên quan, bao gồm cả các vấn đề liên quan đến môi trường kiểm thử, điều kiện kiểm thử, các biến số và đánh giá số liệu,… Quy trình kiểm thử cần phải chỉ ra được rằng, kết quả kiểm thử được tính toán như thế nào từ các số liệu đầu vào của các kiểm thử này.

Các kiểm thử phụ thuộc có liên quan, khi mà quá trình tiến hành các kiểm thử riêng biệt có thành công hay không phụ thuộc vào sự tồn tại các trạng thái riêng biệt đó. Ví dụ: có thể có các đòi hỏi như kiểm thử A phải được tiến hành trước khi thực hiện kiểm thử B, bởi vì trạng thái của sản phẩm được hình thành từ việc tiến hành thành công kiểm thử A là sự tiên quyết cho việc thực hiện thành công kiểm thử B. Như vậy, khi kiểm thử B hoạt động không như mong đợi, có thể liên quan đến vấn đề nào đó của kiểm thử phụ thuộc liên quan trước đó (trong trường hợp này là kiểm thử A).

14.3.4. ATE_FUN.1 Kiểm thử chức năng

Các phụ thuộc: ATE_COV.1 Chứng cứ tổng quan

14.3.4.1. Mục tiêu

Trong phần này, mục đích là các nhà phát triển sản phẩm dùng các kiểm thử trong nhóm này để thể hiện rằng các kiểm thử trong tài liệu kiểm thử đều được và đưa thành tài liệu chính xác.

14.3.4.2. Phần tử hành động của nhà phát triển

14.3.4.2.1. ATE_FUN.1.1D

Nhà phát triển sản phẩm cần thực hiện kiểm thử TSF và tập hợp các kết quả kiểm thử thành văn bản.

14.3.4.2.2. ATE_FUN.1.2D

Nhà phát triển sản phẩm cần đưa ra được các tài liệu kiểm thử.

14.3.4.3. Các phần tử nội dung và trình bày

14.3.4.3.1. ATE_FUN.1.1C

Tài liệu kiểm thử cần trình bày nhất quán các kế hoạch kiểm thử, các kết quả kiểm thử mong muốn và các kết quả đo được thực tế.

14.3.4.3.2. ATE_FUN.1.2C

Kế hoạch kiểm thử cần xác định các kiểm thử cần phải được tiến hành và mô tả các kịch bản cho mỗi hoạt động kiểm thử. Các kịch bản này bao gồm bất kỳ các kiểm thử phụ thuộc có trình tự nào dựa trên các kết quả của các kiểm thử khác.

14.3.4.3.3. ATE_FUN.1.3C

Các kết quả kiểm thử mong muốn cần chỉ ra các kết quả mang tính dự báo từ các kiểm thử được thực hiện thành công.

14.3.4.3.4. ATE_FUN.1.4C

Các kết quả kiểm thử thực sự cần phải phù hợp với các kết quả kiểm thử mong muốn.

14.3.4.4. Phần tử hành động của đánh giá viên

14.3.4.4.1. ATE_FUN.1.1E

Đánh giá viên cần xác nhận rằng các thông tin có được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.

14.3.5. ATE_FUN.2 Kiểm thử chức năng theo trình tự

Các phụ thuộc: ATE_COV.1 Chứng cứ tổng quan

14.3.5.1. Mục tiêu

Mục đích là để nhà phát triển sản phẩm chỉ ra rằng các kiểm thử trong tài liệu kiểm thử được thực hiện và đưa thành tài liệu chính xác, và đảm bảo rằng việc kiểm thử có cấu trúc giống như là để bác bỏ các minh chứng xung quanh sự đúng đắn của các giao diện đã được kiểm thử.

14.3.5.2. Chú thích ứng dụng

Mặc dù quy trình kiểm thử có thể chỉ ra các điều kiện tất yếu trong quá trình bố trí trình tự các kiểm thử phụ thuộc, các quy trình này chưa thể cho thấy một trình tự tối ưu hợp lý. Việc phân tích các quá trình tiến hành các kiểm thử phụ thuộc là một yếu tố quan trọng nhằm đánh giá tính tương đương của các quá trình kiểm thử khác nhau, bởi vì có khả năng các lỗi được giấu kỹ trong khi trình tự để tiến hành kiểm thử bị thay đổi.

14.3.5.3. Phần tử hành động của nhà phát triển

14.3.5.3.1. ATE_FUN.2.1D

Nhà phát triển sản phẩm cần thực hiện các kiểm thử liên quan đến TSF và tập hợp các kết quả kiểm thử thành văn bản.

14.3.5.3.2. ATE_FUN.2.2D

Nhà phát triển sản phẩm cần đưa ra được các tài liệu liên quan đến các kiểm thử đã tiến hành và các kết quả kiểm thử.

14.3.5.4. Các phần tử nội dung và trình bày

14.3.5.4.1. ATE_FUN.2.1C

Tài liệu kiểm thử cần trình bày đầy đủ các kế hoạch kiểm thử, các kết quả kiểm thử mong muốn và các kết quả kiểm thử thực sự.

14.3.5.4.2. ATE_FUN.2.2C

Các kế hoạch kiểm thử cần xác định các kiểm thử được thực hiện và mô tả các kịch bản cho mỗi hoạt động kiểm thử. Các kịch bản này bao gồm bất kỳ các kiểm thử phụ thuộc có trình tự nào dựa trên các kết quả của các kiểm thử khác.

14.3.5.4.3. ATE_FUN.2.3C

Các kết quả kiểm thử mong muốn chỉ ra các kết quả mang tính dự báo nếu như các kiểm thử được thực hiện thành công.

14.3.5.4.4. ATE_FUN.2.4C

Các kết quả kiểm thử thực sự cần bao gồm cả các kết quả kiểm thử mong muốn.

14.3.5.4.5. ATE_FUN.2.5C

Tài liệu kiểm thử cần phải bao gồm cả phần phân tích quy trình kiểm thử của các kiểm thử phụ thuộc theo trình tự.

14.3.5.4.6. ATE_FUN.2.6C

Tài liệu kiểm thử cần phải bao gồm cả phần phân tích quy trình kiểm thử của các kiểm thử phụ thuộc theo trình tự.

14.3.5.5. Phần tử hành động của đánh giá viên

14.3.5.5.1. ATE_FUN.2.1E

Đánh giá viên cần xác nhận rằng các thông tin có được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.

14.4. Kiểm thử độc lập (ATE_IND)

14.4.1. Mục tiêu

Mục đích của nhóm này là dựa vào các sự đảm bảo có được trong các nhóm ATE_FUN, ATE_COV, và ATE_DPT bằng việc xác minh sự kiểm thử bởi nhà phát triển sản phẩm và thực hiện các kiểm thử bổ sung bởi đánh giá viên.

14.4.2. Phân mức thành phần

Các cấp độ được đề xuất trên cơ sở liên quan đến số lượng của các tài liệu kiểm thử bởi nhà phát triển sản phẩm, các hỗ trợ kiểm thử kèm theo và số lượng các kiểm thử của đánh giá viên.

14.4.3. Chú thích ứng dụng

Nhóm các kiểm thử này được đề cập đến một khi có sự đòi hỏi phải tiến hành các kiểm thử không phụ thuộc trong khuôn khổ TSF. Các kiểm thử chức năng không phụ thuộc có thể có hình thức là lặp lại (toàn bộ hoặc từng phần) các kiểm thử chức năng đã được các nhà phát triển sản phẩm tiến hành hoặc mở rộng phạm vi hay mức độ chuyên sâu của các kiểm thử đã được nhà phát triển sản phẩm tiến hành. Các hoạt động này là có tính bù trừ và một sự kết hợp hợp lý cần phải được tính đến cho mỗi TOE, trên cơ sở đảm bảo tính khả thi và tính bao trùm của các kết quả kiểm thử thu được, cũng như phải đảm bảo tính toàn vẹn chức năng của TSF.

Nhóm mẫu các kiểm thử được nhà phát triển sản phẩm đề xuất nhằm mục đích đưa ra sự chứng thực là nhà phát triển sản phẩm đã thực hiện chương trình các kiểm thử trên cơ sở TSF và đã thu được chính xác các kết quả chính thức. Phạm vi số lượng các mẫu được thu thập để tiến hành kiểm thử sẽ ảnh hưởng đến chi tiết, cũng như chất lượng của các kết quả các kiểm thử chức năng do nhà phát triển sản phẩm đã đưa ra. Phía đánh giá viên cần tính đến phạm vi các kiểm thử cần đề xuất thêm và cân đối lợi ích tương đối có thể thu được khi quan tâm đến cả hai lĩnh vực này của các kiểm thử không phụ thuộc. Cũng cần thừa nhận rằng, đôi khi việc lặp lại tất cả các kiểm thử của nhà phát triển sản phẩm đưa ra là mong muốn và khả thi, nhưng trong các trường hợp khác có thể là khá khó khăn và không hiệu quả. Cho nên cần hạn chế các thử nghiệm thực sự khó triển khai. Quá trình tiến hành lấy mẫu cần tập trung vào toàn bộ phổ của các kết quả thử nghiệm đã thu được, hơn nữa cần bao gồm cả các kết quả thỏa mãn được những đòi hỏi của các kiểm thử chung (ATE_COV) và các kiểm thử chuyên biệt (ATE_DPT).

Cũng cần xem xét đến các cấu hình (cấu trúc) khác nhau của TOE trong quá trình tiến hành đánh giá. Đánh giá viên cũng cần cân nhắc tới khả năng sử dụng ngay các kết quả kiểm thử được cung cấp và căn cứ vào đó để lên kế hoạch cho các kiểm thử của riêng mình.

Sự thích hợp của TOE đối với các kiểm thử căn cứ vào khả năng truy cập vào TOE, và các tài liệu hỗ trợ cũng như các thông tin đòi hỏi (cũng liên quan đến các chương trình phần mềm kiểm thử hoặc các công cụ) để tiến hành kiểm thử. Sự cần thiết của các hỗ trợ đó chủ yếu là liên quan đến các kiểm thử phụ thuộc thuộc các nhóm (lớp) khác.

Ngoài ra, Sự thích hợp của TOE đối với các kiểm thử còn có thể nằm ở những lý do khác. Ví dụ, định dạng của TOE do nhà phát triển sản phẩm cung cấp không phải là phiên bản (ver-sion) mới nhất.

Thuật ngữ “các giao diện” chỉ các giao diện được mô tả trong đặc tả chức năng và thiết kế TOE, các tham số truyền qua các dẫn chứng đã đồng nhất trong mô tả thực thi. Tập hợp chính xác các giao diện đã sử dụng được lựa chọn qua các thành phần Tổng quan (ATE_COV) và Chiều sâu (ATE_DPT).

Các căn cứ cho một tập hợp con của TSF chú trọng tới khả năng cho phép đánh giá viên thiết kế một tập hợp các kiểm thử thích hợp, phù hợp với các mục tiêu mà đánh giá viên theo đuổi từ đầu.

14.4.4. ATE_IND.1 Kiểm thử độc lập - tuân thủ

Các phụ thuộc:

ADV_FSP.1 Đặc tả chức năng cơ bản

AGD_OPE.1 Hướng dẫn thao tác người dùng.

SGD_PRE.1 Các quy trình chuẩn bị

14.4.4.1. Mục tiêu

Trong phần này, mục đích là để thể hiện rằng TOE hoạt động theo đúng mô tả thiết kế và các tài liệu hướng dẫn của nó.

14.4.4.2. Chú thích ứng dụng

Thành phần này không đề cập đến việc sử dụng các kết quả kiểm thử bởi nhà phát triển sản phẩm. Điều đó phù hợp với nơi mà các kết quả không thể có được và trong trường hợp việc kiểm thử bởi nhà phát triển sản phẩm được chấp nhận nhưng không có sự phê chuẩn. Đánh giá viên được yêu cầu lập ra và tiến hành các kiểm thử với mục đích xác nhận rằng TOE hoạt động đúng theo các mô tả thiết kế của nó, bao gồm cả đặc tả chức năng. Cách tiếp cận này là để đạt được sự tin cậy trong thao tác chỉnh sửa qua việc kiểm thử mẫu, hơn nữa để tiến hành mọi kiểm thử có thể. Phạm vi của kiểm thử được lập ra cho mục đích này là một sản phẩm phương pháp luận, và cần phải được xem xét trong phạm vi một TOE riêng biệt và sự cân nhắc của các hoạt động đánh giá khác.

14.4.4.3. Phần tử hành động của nhà phát triển

14.4.4.3.1. ATE_IND.1.1D

Nhà phát triển sản phẩm cần đưa ra TOE cho các kiểm thử này

14.4.4.4. Các phần tử nội dung và trình bày

14.4.4.4.1. ATE_IND.1.1C

TOE cần thích hợp cho kiểm thử.

14.4.4.5. Phần tử hành động của đánh giá viên

14.4.4.5.1. ATE_IND.1.1E

Đánh giá viên cần xác nhận rằng các thông tin có được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.

14.4.4.5.2. ATE_IND.1.2E

Đánh giá viên cần kiểm thử một tập hợp con của TSF nhằm xác nhận rằng TOE hoạt động như đã được xác định ban đầu.

14.4.5. ATE_IND.2 Kiểm thử độc lập - lấy mẫu

Các phụ thuộc:

ADV_FSP.2 Mô tả chức năng thực thi an toàn

AGD_OPE.1 Hướng dẫn thao tác người sử dụng

AGD_PRE.1 Các quy trình chuẩn bị

ATE_COV.1 Chứng cứ tổng quan

ATE_FUN.1 Kiểm thử chức năng

14.4.5.1. Mục tiêu

Trong phần này, mục đích là để thể hiện rằng TOE hoạt động đúng theo các mô tả thiết kế và các tài liệu hướng dẫn của nó. Việc kiểm thử bởi đánh giá viên xác nhận rằng nhà phát triển sản phẩm đã thực hiện một số kiểm thử của một vài giao diện trong đặc tả chức năng.

14.4.5.2. Chú thích ứng dụng

Điểm mấu chốt ở đây là nhà phát triển sản phẩm cần phải cung cấp các tài liệu cần thiết sao cho đánh giá viên có thể tái tạo lại các kiểm thử đã được tiến hành bởi nhà phát triển sản phẩm, trong đó có thể bao gồm các tài liệu kiểm thử mà máy đọc được, các chương trình (phần mềm) kiểm thử, v.v…

Đánh giá viên phải có được các kết quả (số liệu) kiểm thử từ nhà phát triển sản phẩm để hỗ trợ chương trình kiểm thử của mình. Nhà đánh giá sẽ lặp lại một loạt (mẫu) các kiểm thử của nhà phát triển sản phẩm nhằm thu được sự tin chắc vào các kết quả nhận được. Trên cơ sở có được, đánh giá viên sẽ tiến hành thêm các kiểu thử cho phép sử dụng TOE theo các cách khác, sau đó đánh giá viên sẽ tập trung kiểm thử ở những khu vực quan tâm riêng.

14.4.5.3. Phần tử hành động của nhà phát triển

14.4.5.3.1. ATE_IND.2.1D

Nhà phát triển sản phẩm cần đưa ra TOE cho các kiểm thử này.

14.4.5.4. Các phần tử nội dung và trình bày

14.4.5.4.1. ATE_IND.2.1C

TOE cần thích hợp cho kiểm thử.

14.4.5.4.2. ATE_IND.2.2C

Nhà phát triển sản phẩm cần phải đưa ra được một tập hợp các nguồn gốc tương thích với các kiểm thử chức năng đã được họ tiến hành đối với TSF.

14.4.5.5. Phần tử hành động của đánh giá viên

14.4.5.5.1. ATE_IND.2.1E

Đánh giá viên cần xác nhận rằng các thông tin có được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.

14.4.5.5.2. ATE_IND.2.2E

Đánh giá viên cần thực hiện một bộ mẫu trong phạm vi các kiểm thử được mô tả trong tài liệu kiểm thử nhằm thẩm định các kết quả kiểm thử có được từ các nhà phát triển sản phẩm.

14.4.5.5.3. ATE_IND.2.3E

Đánh giá viên cần kiểm thử một tập hợp con thích hợp của TSF nhằm xác nhận rằng TSF hoạt động như đã được xác định ban đầu.

14.4.6. ATE_IND.3 Kiểm thử độc lập - toàn diện

Các phụ thuộc:

ADV_FSP.4 Đặc tả chức năng toàn diện

AGD_OPE.1 Hướng dẫn thao tác người sử dụng

AGD_PRE.1 Các quy trình chuẩn bị

ATE_COV.1 Chứng cứ tổng quan

ATE_FUN.1 Kiểm thử chức năng

14.4.6.1. Mục tiêu

Trong phần này, mục đích là để thể hiện rằng TOE hoạt động đúng theo các mô tả thiết kế và các tài liệu hướng dẫn của nó. Việc kiểm thử bởi đánh giá viên bao gồm cả việc lặp lại toàn bộ các kiểm thử do nhà phát triển sản phẩm đã tiến hành.

14.4.6.2. Chú thích ứng dụng

Điểm mấu chốt ở đây là nhà phát triển sản phẩm cần phải cung cấp các tài liệu cần thiết sao cho đánh giá viên có thể tái tạo lại các kiểm thử đã được tiến hành bởi nhà phát triển sản phẩm, trong đó có thể bao gồm các tài liệu kiểm thử mà máy đọc được, các chương trình (phần mềm) kiểm thử, v.v…

Đánh giá viên phải có lặp lại tất cả các kiểm thử của nhà phát triển sản phẩm như là một phần trong chương trình kiểm thử của mình. Đánh giá viên sẽ lặp lại một loạt (mẫu) các kiểm thử của nhà phát triển sản phẩm nhằm thu được sự tin chắc vào các kết quả nhận được. Trên cơ sở có được, đánh giá viên sẽ tiến hành thêm các kiểm thử cho phép sử dụng TOE theo các cách khác so với cách thông thường mà nhà phát triển sản phẩm trình bày. Trừ trường hợp các kiểm thử của nhà phát triển sản phẩm tỏ ra là đã thấu đáo.

14.4.6.3. Phần tử hành động của nhà phát triển

14.4.6.3.1. ATE_IND.3.1D

Nhà phát triển sản phẩm cần đưa ra TOE cho các kiểm thử

14.4.6.4. Các phần tử nội dung và trình bày

14.4.6.4.1. ATE_IND.3.1C

TOE cần thích hợp cho kiểm thử.

14.4.6.4.2. ATE_IND.3.2C

Nhà phát triển sản phẩm cần phải đưa ra được một tập hợp các nguồn gốc tương thích với các kiểm thử chức năng đã được họ tiến hành đối với TSF.

14.4.6.5. Phần tử hành động của đánh giá viên

14.4.6.5.1. ATE_IND.3.1E

Đánh giá viên cần xác nhận rằng các thông tin có được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.

14.4.6.5.2. ATE_IND.3.2E

Đánh giá viên cần thực hiện toàn bộ các kiểm thử được mô tả trong tài liệu kiểm thử nhằm thẩm định các kết quả kiểm thử có được từ các nhà phát triển sản phẩm.

14.4.6.5.3. ATE_IND.3.3E

Đánh giá viên cần kiểm thử TSF nhằm xác nhận rằng toàn bộ TSF hoạt động như đã được xác định ban đầu.

15. Lớp AVA: Đánh giá điểm yếu

Lớp này đề cập đến khả năng khai thác các điểm yếu được giới thiệu trong quá trình phát triển.

Hình sau thể hiện các họ trong lớp này, và phân cấp các thành phần trong các họ.

Hình 15 - Phân cấp lớp AVA: Đánh giá điểm yếu

15.1. Chú thích ứng dụng

Nhìn chung, hoạt động đánh giá điểm yếu xuyên suốt các điểm yếu khác nhau trong phát triển và hoạt động của TOE. Các điểm yếu trong phát triển lợi dụng một số đặc tính của TOE được giới thiệu trong quá trình phát triển nó, như hủy bỏ tự bảo vệ của TSF thông qua việc giả mạo, trực tiếp tấn công hoặc giám sát TSF, hủy bỏ phân vùng TSF qua giám sát hoặc tấn công trực tiếp TSF, hoặc hủy bỏ không cần mật khẩu qua việc phá hủy (bằng mật khẩu) TSF. Các điểm yếu trong hoạt động lợi dụng các nhược điểm của các biện pháp phòng chống không mang tính kỹ thuật để vi phạm TOE SFR, như lạm dụng hoặc cấu hình không đúng. Lạm dụng nhằm kiểm tra xem TOE có thể được cấu hình hoặc sử dụng theo cách không an toàn mà người quản trị hoặc người dùng TOE vẫn tin rằng nó an toàn.

Việc đánh giá các điểm yếu trong phát triển được nêu trong họ đảm bảo AVA_VAN. Về cơ bản, tất cả các điểm yếu trong phát triển đều có thể được xem xét liên quan trong thành phần AVA_VAN bởi vì thực tế họ này cho phép ứng dụng với nhiều hệ phương pháp đánh giá không đặc trưng cho một kịch bản tấn công nào. Các hệ phương pháp đánh giá không đặc trưng này bao gồm cả các hệ phương pháp đặc trưng cho các TSF đó, trong đó xem xét đến các kênh trái phép (ước lượng dung lượng kênh có thể thực hiện bằng các phép đo kỹ thuật không chính thức, và các phép đo kiểm tra thực tế) hoặc có thể khắc phục bằng việc sử dụng nguồn tài nguyên đầy đủ theo hình thức tấn công trực tiếp (mô hình kỹ thuật nền tảng của các TSF này dựa trên các cơ chế xác suất hoặc hoán vị; cải thiện hoạt động an toàn của chúng và các biện pháp khắc phục có thể thực hiện thông qua phân tích xác suất hay định lượng).

Nếu có các mục tiêu an toàn đã chỉ rõ trong ST để ngăn chặn sự theo dõi của một người dùng TOE khỏi người dùng khác, hoặc để đảm bảo rằng các luồng thông tin không thể được sử dụng để thu lại các tín hiệu dữ liệu trái phép đã thực thi, thì phân tích kênh trái phép cần được xét đến trong suốt quá trình tiến hành phân tích điểm yếu. Điều này thường được phản ánh trong Khả năng ẩn dấu (FPR_UNO) của TCVN 8709-2 và các chính sách kiểm soát truy cập nhiều mức đã chỉ ra thông qua chính sách kiểm soát truy cập (FDP_ACC) trong 15408-2 và/hoặc các yêu cầu chính sách kiểm soát luồng thông tin (FDP_IFC) trong ST trong 15408-2.

15.2. Phân tích điểm yếu (AVA_VAN)

15.2.1. Mục tiêu

Phân tích điểm yếu là đánh giá xem các điểm yếu tiềm ẩn được xác định trong quá trình đánh giá, trong hoạt động đoán trước được của TOE hoặc bằng các phương thức khác (ví dụ như các giả thuyết sai, các phân tích định lượng hay thống kê về hoạt động an toàn của các cơ chế an toàn đang xét) có thể cho phép những kẻ tấn công vi phạm các SFR hay không.

Phân tích điểm yếu đề cập đến các mối đe dọa do kẻ tấn công có thể phát hiện các chỗ sơ hở cho phép truy cập trái phép dữ liệu và chức năng, cho phép can thiệp hoặc sửa đổi TSF, hoặc can thiệp các quyền của các người sử dụng khác.

15.2.2. Phân mức thành phần

Phân mức thành phần dựa trên độ phức tạp tăng dần của phân tích điểm yếu thực hiện bởi  đánh giá viên và mức độ tăng của khả năng tấn công gây ra bởi một kẻ tấn công để xác định và khai thác các điểm yếu tiềm ẩn.

15.2.3. AVA_VAN.1 Tổng quan điểm yếu

Các phụ thuộc:

ADV_FSP.1 Đặc tả chức năng cơ bản

AGD_OPE.1 Hướng dẫn người dùng vận hành

AGD_PRE.1 Các thủ tục chuẩn bị

15.2.3.1. Mục tiêu

Khảo sát điểm yếu của thông tin có sẵn thông báo công khai được thực hiện bởi đánh giá viên để xác định các điểm yếu tiềm ẩn có thể dễ dàng bị một kẻ tấn công tìm ra.

Đánh giá viên thực hiện việc kiểm thử xâm nhập để xác nhận rằng các điểm yếu tiềm ẩn không thể bị khai thác trong môi trường vận hành TOE. Kiểm thử xâm nhập được thực hiện bởi đánh giá viên giả thiết khả năng tấn công ở mức cơ bản.

15.2.3.2. Phần tử hành động của nhà phát triển

15.2.3.2.1. AVA_VAN.1.1D

Nhà phát triển sản phẩm cần đưa ra TOE cho các kiểm thử này.

15.2.3.3. Các phần tử nội dung và trình bày

15.2.3.3.1. AVA_VAN1.1C

TOE cần thích hợp cho kiểm thử.

15.2.3.4. Phần tử hành động của đánh giá viên

15.2.3.4.1. AVA_VAN.1.1E

Đánh giá viên cần xác nhận rằng các thông tin có được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.

15.2.3.4.2. AVA_VAN.1.2E

Đánh giá viên cần thực hiện việc tìm kiếm các nguồn thông tin công cộng để nhận biết các điểm yếu tiềm ẩn trong TOE

15.2.3.4.3. AVA_VAN.1.3E

Đánh giá viên cần tiến hành việc kiểm thử xâm nhập dựa trên các điểm yếu tiềm ẩn đã biết để xác nhận rằng TOE được bảo vệ trước các tấn công của kẻ tấn công với khả năng tấn công cơ bản.

15.2.4. AVA_VAN.2 Phân tích điểm yếu

Các phụ thuộc:

ADV_ARC.1 Mô tả kiến trúc an toàn.

ADV_FSP.1 Đặc tả chức năng cơ bản

ADV_TDS.1 Thiết kế cơ bản

AGD_OPE.1 Hướng dẫn người dùng vận hành

AGD_PRE.1 Các thủ tục chuẩn bị

15.2.4.1. Mục tiêu

Phân tích điểm yếu được thực hiện bởi đánh giá viên nhằm xác định chắc chắn sự có mặt của các điểm yếu tiềm ẩn.

Đánh giá viên thực hiện việc kiểm thử xâm nhập để xác nhận rằng các điểm yếu tiềm ẩn không thể bị khai thác trong môi trường vận hành TOE. Kiểm thử xâm nhập được thực hiện bởi đánh giá viên áp dụng khả năng tấn công ở mức cơ bản.

15.2.4.2. Phần tử hành động của nhà phát triển

15.2.4.2.1. AVA_VAN.2.1D

Nhà phát triển cần cung cấp TOE để kiểm thử.

15.2.4.3. Các phần tử nội dung và trình bày

15.2.4.3.1. AVA_VAN.2.1C

TOE cần thích hợp cho kiểm thử.

15.2.4.4. Phần tử hành động của đánh giá viên

15.2.4.4.1. AVA_VAN.2.1E

Đánh giá viên cần xác nhận rằng các thông tin có được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.

15.2.4.4.2. AVA_VAN.2.2E

Đánh giá viên cần thực hiện việc tìm kiếm các nguồn thông tin công cộng để nhận biết các điểm yếu tiềm ẩn trong TOE.

15.2.4.4.3. AVA_VAN.2.3E

Đánh giá viên cần thực hiện phân tích điểm yếu độc lập của TOE thông qua tài liệu hướng dẫn, đặc tả chức năng, thiết kế TOE và mô tả kiến trúc an toàn để xác định các điểm yếu tiềm ẩn trong TOE.

15.2.4.4.4. AVA_VAN.2.4E

Đánh giá viên cần tiến hành việc kiểm thử xâm nhập dựa trên các điểm yếu tiềm ẩn đã biết để xác nhận rằng TOE được bảo vệ các tấn công của kẻ tấn công với khả năng tấn công cơ bản.

15.2.5. AVA_VAN.3 Phân tích các điểm yếu trọng tâm

Các phụ thuộc:

ADV_ARC.1 Mô tả kiến trúc an toàn

ADV_FSP.2 Đặc tả chức năng thực thi an toàn

ADV_TDS.3 Thiết kế mô đun cơ bản

ADV_TMP.1 Biểu diễn triển khai của TSF

AGD_OPE.1 Hướng dẫn người dùng vận hành

AGD_PRE.1 Các thủ tục chuẩn bị

15.2.5.1. Mục tiêu

Phân tích điểm yếu được thực hiện bởi đánh giá viên nhằm xác định chắc chắn sự có mặt của các điểm yếu tiềm ẩn.

Đánh giá viên thực hiện việc kiểm thử xâm nhập để xác nhận rằng các điểm yếu tiềm ẩn không thể bị khai thác trong môi trường vận hành TOE. Kiểm thử xâm nhập được thực hiện bởi đánh giá viên áp dụng khả năng tấn công ở mức cơ bản nâng cao.

15.2.5.2. Phần tử hành động của nhà phát triển

15.2.5.2.1. AVA_VAN.3.1D

Nhà phát triển cần cung cấp TOE cho kiểm thử.

15.2.5.3. Các phần tử nội dung và trình bày

15.2.5.3.1. AVA_VAN.3.1C

TOE cần thích hợp cho kiểm thử.

15.2.5.4. Phần tử hành động của đánh giá viên

15.2.5.4.1. AVA_VAN.3.1E

Đánh giá viên cần xác nhận rằng các thông tin có được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.

15.2.5.4.2. AVA_VAN.3.2E

Đánh giá viên cần thực hiện việc tìm kiếm các nguồn thông tin công cộng để nhận biết các điểm yếu tiềm ẩn trong TOE.

15.2.5.4.3. AVA_VAN.3.3E

Đánh giá viên cần thực hiện phân tích điểm yếu độc lập của TOE thông qua tài liệu hướng dẫn, đặc tả chức năng, thiết kế TOE và mô tả kiến trúc an toàn và biểu diễn triển khai để xác định các điểm yếu tiềm ẩn trong TOE.

15.2.5.4.4. AVA_VAN.3.4E

Đánh giá viên cần tiến hành việc kiểm thử xâm nhập dựa trên các điểm yếu tiềm ẩn đã biết để xác nhận rằng TOE được bảo vệ trước các tấn công của kẻ tấn công với khả năng tấn công cơ bản nâng cao.

15.2.6. AVA_VAN.4 Phân tích điểm yếu có hệ thống

Các phụ thuộc:

ADV_ARC.1 Mô tả kiến trúc an toàn

ADV_FSP.2 Đặc tả chức năng thực thi an toàn

ADV_TDS.3 Thiết kế mô đun cơ bản

ADV_TMP.1 Biểu diễn triển khai của TSF

AGD_OPE.1 Hướng dẫn người dùng vận hành

AGD_PRE.1 Các thủ tục chuẩn bị

15.2.6.1. Mục tiêu

Phân tích điểm yếu có hệ thống được thực hiện bởi đánh giá viên nhằm xác định chắc chắn sự có mặt của các điểm yếu tiềm ẩn.

Đánh giá viên thực hiện việc kiểm thử xâm nhập để xác nhận rằng các điểm yếu tiềm ẩn không thể bị khai thác trong môi trường vận hành TOE. Kiểm thử xâm nhập được thực hiện bởi đánh giá viên áp dụng khả năng tấn công ở mức vừa phải.

15.2.6.2. Phần tử hành động của nhà phát triển

15.2.6.2.1. AVA_VAN.4.1D

Nhà phát triển cần cung cấp TOE cho kiểm thử.

15.2.6.3. Các phần tử nội dung và trình bày

15.2.6.3.1. AVA_VAN.4.1C

TOE cần thích hợp cho kiểm thử.

15.2.6.4. Phần tử hành động của đánh giá viên

15.2.6.4.1. AVA_VAN.4.1E

Đánh giá viên cần xác nhận rằng các thông tin có được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.

15.2.6.4.2. AVA_VAN.4.2E

Đánh giá viên cần thực hiện việc tìm kiếm các nguồn thông tin công cộng để nhận biết các điểm yếu tiềm ẩn trong TOE.

15.2.6.4.3. AVA_VAN.4.3E

Đánh giá viên cần thực hiện phân tích điểm yếu có hệ thống, độc lập của OTE sử dụng tài liệu hướng dẫn, đặc tả chức năng, thiết kế TOE và mô tả kiến trúc an toàn và biểu diễn triển khai để xác định các điểm yếu tiềm ẩn trong TOE.

15.2.6.4.4. AVA_VAN.4.4E

Đánh giá viên cần tiến hành việc kiểm thử xâm nhập dựa trên các điểm yếu tiềm ẩn đã biết để xác nhận rằng TOE được bảo vệ trước các tấn công của kẻ tấn công với khả năng tấn công vừa phải.

15.2.7. AVA_VAN.5 Phân tích điểm yếu có hệ thống nâng cao

Các phụ thuộc:

ADV_ARC.1 Mô tả kiến trúc an toàn

ADV_FSP.2 Đặc tả chức năng thực thi an toàn

ADV_TDS.3 Thiết kế mô đun cơ bản

ADV_TMP.1 Biểu diễn triển khai của TSF

AGD_OPE.1 Hướng dẫn người dùng vận hành

AGD_PRE.1 Các thủ tục chuẩn bị

15.2.7.1. Mục tiêu

Phân tích điểm yếu có hệ thống được thực hiện bởi đánh giá viên nhằm xác định chắc chắn sự có mặt của các điểm yếu tiềm ẩn.

Đánh giá viên thực hiện việc kiểm thử xâm nhập để xác nhận rằng các điểm yếu tiềm ẩn không thể bị khai thác trong môi trường vận hành TOE. Kiểm thử xâm nhập được thực hiện bởi đánh giá viên áp dụng khả năng tấn công ở mức cao.

15.2.7.2. Phần tử hành động của nhà phát triển

15.2.7.2.1. AVA_VAN.5.1D

Nhà phát triển cần cung cấp TOE cho kiểm thử.

15.2.7.3. Các phần tử nội dung và trình bày

15.2.7.3.1. AVA_VAN.5.1C

TOE cần thích hợp cho kiểm thử.

15.2.7.4. Phần tử hành động của đánh giá viên

15.2.7.4.1. AVA_VAN.5.1E

Đánh giá viên cần xác nhận rằng các thông tin có được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.

15.2.7.4.2. AVA_VAN.5.2E

Đánh giá viên cần thực hiện việc tìm kiếm thông tin công cộng để nhận biết các điểm yếu tiềm ẩn trong TOE.

15.2.7.4.3. AVA_VAN.5.3E

Đánh giá viên cần thực hiện phân tích điểm yếu có hệ thống, độc lập của TOE thông qua tài liệu hướng dẫn, đặc tả chức năng, thiết kế TOE, mô tả kiến trúc an toàn và biểu diễn triển khai để xác định các điểm yếu tiềm ẩn trong TOE.

15.2.7.4.4. AVA_VAN.5.4E

Đánh giá viên cần tiến hành việc kiểm thử xâm nhập dựa trên các điểm yếu tiềm ẩn đã biết để xác nhận rằng TOE được bảo vệ trước các tấn công của kẻ tấn công với khả năng tấn công cao.

16. Lớp ACO: Tổng hợp

Lớp tổng hợp ACO bao gồm năm họ. Những họ này xác định các yêu cầu đảm bảo được thiết kế để đưa ra sự tin cậy về việc một TOE được tổng hợp sẽ hoạt động an toàn dựa vào chức năng an toàn cung cấp bởi các thành phần phần mềm, phần sụn hoặc phần cứng đã được đánh giá trước đó.

Tổng hợp là việc gộp hai hay nhiều thực thể CNTT đã được đánh giá thỏa mãn các gói yêu cầu đảm bảo an toàn trong TCVN 8709 (các thành phần cơ sở và thành phần phụ thuộc, xem Phụ lục B) và kết hợp chúng để sử dụng không cần phát triển thêm một thực thể CNTT nào khác. Việc phát triển thêm các thực thể CNTT không được xét đến (các thực thể chưa được xem xét trước đó trong đánh giá thành phần). Các TOE tổng hợp tạo thành một sản phẩm mới có thể được cài đặt và tích hợp vào bất kỳ môi trường cụ thể nào đáp ứng các mục tiêu của môi trường đánh giá.

Cách tiếp cận này không đưa ra một phương pháp thay thế cho đánh giá thành phần. Tổng hợp thuộc ACO cung cấp một phương pháp cho việc tích hợp TOE tổng hợp, phương pháp này có thể dùng thay thế cho các mức đảm bảo khác đã nêu trong TCVN 870, nhằm đạt được sự tin cậy trong một TOE tạo thành qua kết hợp hai hay nhiều thành phần đã đánh giá tuân thủ mà không cần phải đánh giá lại TSF tổng hợp. (Người tích hợp TOE tổng hợp còn được gọi là “nhà phát triển” trong toàn bộ lớp ACO, với mọi tham chiếu đến nhà phát triển các thành phần cơ sở hoặc thành phần phụ thuộc khi được nêu rõ như vậy).

Các gói bảo đảm tổng hợp được định nghĩa tại điều khoản 8 và 6.3, là một thang bậc đảm bảo cho các TOE tổng hợp. Thang bậc đảm bảo này được đòi hỏi thêm cho EAL vì để kết hợp các thành phần đã được đánh giá theo EALs và đạt được kết quả bảo đảm theo EAL, tất cả các SAR trong EAL phải được áp dụng cho các TOE tổng hợp. Dù rằng có thể tái sử dụng các kết quả đánh giá TOE thành phần, vẫn thường cần xem xét thêm các khía cạnh khác của các thành phần của TOE tổng hợp, như đã nêu trong Phụ lục B.3. Do trong hoạt động đánh giá một TOE tổng hợp có sự tham gia của các bên khác nhau, nói chung là không thể có được mọi chứng cứ cần thiết về các khía cạnh khác của các thành phần này để áp dụng EAL phù hợp. Do đó, các CAPs được định nghĩa nhằm giải quyết vấn đề về kết hợp các thành phần đã đánh giá và nhằm đạt một kết quả có nghĩa hơn. Điều này được thảo luận thêm trong Phụ lục B.

Hình 16 - Mối quan hệ giữa các họ ACO và tương tác giữa các thành phần

Thông thường trong một TOE tổng hợp, một thành phần dựa trên các dịch vụ do thành phần khác cung cấp. Các thành phần yêu cầu dịch vụ được gọi là thành phần phụ thuộc và các thành phần cung cấp dịch vụ được gọi là thành phần cơ sở. Sự tương tác và phân biệt này được bàn thêm tại Phụ lục B. Giả thiết là nhà phát triển thành phần phụ thuộc hỗ trợ đánh giá TOE theo một số cách thức nào đó (như nhà phát triển, người tài trợ, hoặc chỉ là hợp tác và cung cấp các chứng cứ đánh giá cần thiết từ việc đánh giá thành phần phụ thuộc). Các thành phần ACO trong các gói bảo đảm CAP không được sử dụng như một sự gia tăng các đánh giá TOE thành phần, vì điều này không đem lại đảm bảo có nghĩa cho thành phần.

Các họ trong lớp ACO tương tác một cách tương tự với các lớp ADV, ATE và AVA trong đánh giá TOE thành phần và do đó có thể chịu ảnh hưởng của đặc tả các yêu cầu từ những lớp này. Tuy nhiên, có một số điều khoản đặc trưng cho đánh giá TOE tổng hợp. Để xác định cách thức các thành phần tương tác và tìm ra những sai lệch trong đánh giá các thành phần, cần xác định các mối phụ thuộc (ACO_REL) của các thành phần phụ thuộc vào các thành phần cơ sở. Các mối phụ thuộc vào thành phần cơ sở này được quy định trong điều khoản về giao diện qua đó thành phần phụ thuộc gọi các dịch vụ với sự hỗ trợ của các SFR thành phần phụ thuộc. Các giao diện, và ở mức cao hơn là các hoạt động hỗ trợ, được cung cấp bởi các thành phần cơ sở để đáp ứng những yêu cầu dịch vụ được phân tích trong ACO_DEV. Các họ ACO_DEV dựa trên họ ADV_TDS, do đó tại mức đơn giản nhất, TSF của mỗi thành phần có thể được xem như là một hệ thống con của TOE tổng hợp, với các phần bổ sung thêm cho mỗi thành phần được xem là các hệ thống con bổ sung. Vì vậy, các giao diện giữa các thành phần được xem là tương tác giữa các hệ thống con trong đánh giá TOE thành phần.

Có thể là các giao diện và mô tả hoạt động hỗ trợ cung cấp cho ACO_DEV chưa đầy đủ. Điều này được xác định trong quản lý ACO_COR. Họ ACO_COR nhận kết quả từ ACO_REL và ACO_DEL, xác định việc các thành phần đang được sử dụng trong cấu hình đánh giá của chúng hay không, và xác định vị trí đặc tả nào đó chưa đầy đủ, từ đó xác định làm yếu tố đầu vào cho các hoạt động kiểm thử (ACO_CTT) và phân tích điểm yếu (ACO_VUL) cho TOE tổng hợp.

Kiểm thử TOE tổng hợp được thực hiện để xác định rằng các TOE tổng hợp có hoạt động dự kiến như đã xác định bởi các SFRs của TOE tổng hợp và nhằm biểu diễn sự phù hợp của các giao diện giữa các thành phần của TOE tổng hợp ở các mức cao hơn.

Các phân tích điểm yếu của TOE tổng hợp có được từ những kết quả đầu ra của phân tích điểm yếu của các đánh giá thành phần. Phân tích điểm yếu TOE tổng hợp xem xét mọi điểm yếu sẵn có từ các đánh giá thành phần nhằm xác định rằng các điểm yếu đó không áp dụng cho các TOE tổng hợp. Việc tìm kiếm thông tin công bố công khai liên quan đến các thành phần cũng được thực hiện để xác định ra mọi vấn đề đã báo cáo trong các thành phần sau khi hoàn thành đánh giá tương ứng.

Sự tương tác giữa các họ ACO được mô tả trong Hình 17 dưới đây. Tương tác này thể hiện bằng các đường mũi tên liền nét, trong đó chứng cứ và hiểu biết về một họ được chuyển vào hoạt động tiếp theo. Các đường mũi tên đứt nét xác định dấu vết rõ ràng về một hoạt động có từ các SFR của TOE tổng hợp như mô tả ở trên.

Hình 17 - Mối quan hệ giữa các họ ACO

Thảo luận thêm về định nghĩa và tương tác trong các TOE tổng hợp được đưa ra trong Phụ lục B.

Hình 18 cho thấy các họ trong lớp này, và phân cấp các thành phần trong các họ.

Hình 18 - Phân cấp lớp ACO: Tổng hợp

16.1. Sở cứ tổng hợp (ACO_COR)

16.1.1. Mục tiêu

Họ này đề cập đến yêu cầu chứng minh rằng thành phần cơ sở có thể cung cấp một mức độ bảo đảm thích hợp để sử dụng vào việc tổng hợp.

16.1.2. Phân mức thành phần

Chỉ có một thành phần duy nhất trong họ này.

16.1.3. ACO_COR.1 Sở cứ tổng hợp

Phụ thuộc:

ACO_DEV.1 Mô tả chức năng

ALC_CMC.1 Ghi nhãn cho TOE

ACO_REL.1 Thông tin tin cậy cơ bản

16.1.3.1. Phần tử hành động của nhà phát triển

16.1.3.1.1. ACO_COR.1.1D

Nhà phát triển cần cung cấp sở cứ tổng hợp cho thành phần cơ sở.

16.1.3.2. Các phần tử nội dung và trình bày

16.1.3.2.1. ACO_COR.1.1C

Sở cứ tổng hợp cần biểu thị rằng một mức bảo đảm ít nhất đạt ngang như mức của thành phần phụ thuộc đã thu được nhằm hỗ trợ chức năng thành phần cơ sở, khi thành phần cơ sở được cấu hình theo yêu cầu để hỗ trợ TSF của thành phần phụ thuộc.

16.1.3.3. Phần tử hành động của đánh giá viên

16.1.3.3.1. ACO_COR.1.1E

Đánh giá viên phải xác nhận rằng thông tin đáp ứng tất cả yêu cầu đối với nội dung và hình thức của chứng cứ.

16.2. Chứng cứ phát triển (ACO_DEV)

16.2.1. Mục tiêu

Họ này đặt ra yêu cầu về đặc tả cho thành phần cơ sở theo các mức tăng dần về chi tiết. Thông tin này cần có thể đạt được sự tin cậy về việc chức năng an toàn thích hợp được đưa ra nhằm hỗ trợ yêu cầu của thành phần phụ thuộc (như đã xác định trong thông tin tin cậy).

16.2.2. Phân mức thành phần

Các thành phần được phân mức trên cơ sở tăng dần chi tiết về các giao diện đã đưa ra, cách thức chúng được triển khai.

16.2.3. Chú thích ứng dụng

TSF của thành phần cơ sở thường được xác định không cần biết đến các mối phụ thuộc của các ứng dụng có thể có khi chúng được tổng hợp. TSF của thành phần cơ sở này được định nghĩa bao gồm tất cả các phần của thành phần cơ sở dựa vào việc thực thi các SFRs của thành phần cơ sở. Điều đó cũng nghĩa là bao gồm tất cả các phần của thành phần cơ sở cần thiết để triển khai các SFRs của thành phần cơ sở.

Đặc tả chức năng của thành phần cơ sở sẽ mô tả TSFI với những điều khoản về giao diện do thành phần cơ sở đưa ra nhằm cho phép thực thể bên ngoài thực thi các hoạt động của TSF. Nó gồm giao diện với người dùng nhằm cho phép tương tác với hoạt động của TSF thực thi các SFRs và giao diện cho phép một thực thể CNTT bên ngoài tạo các lời gọi tới TSF.

Đặc tả chức năng chỉ mô tả những gì TSF đưa ra ở giao diện của nó và phương thức chức năng TSF được thực hiện. Do đó, đặc tả chức năng không cần thiết phải cung cấp một đặc tả giao diện đầy đủ cho tất cả các giao diện khả thi giữa một thực thể bên ngoài và thành phần cơ sở. Nó không bao gồm những gì TSF muốn có/yêu cầu từ môi trường hoạt động. Mô tả về những gì một TSF thành phần phụ thuộc dựa vào một thành phần cơ sở được xem xét trong lớp Độ tin cậy của thành phần phụ thuộc (ACO_REL), và chứng cứ thông tin phát triển cung cấp phản hồi về các giao diện đã xác định.

Chứng cứ thông tin phát triển bao gồm một đặc tả thành phần cơ sở. Đó có thể là chứng cứ sử dụng trong đánh giá thành phần cơ sở nhằm thỏa mãn các yêu cầu ADV, hoặc có thể là hình thức chứng cứ khác tạo bởi hoặc nhà phát triển thành phần cơ sở hay nhà phát triển TOE tổng hợp. Đặc tả thành phần cơ sở được sử dụng trong lớp Chứng cứ phát triển (ACO_DEV) nhằm đạt được sự tin cậy về việc chức năng an toàn thích hợp được đưa ra để hỗ trợ các yêu cầu của thành phần phụ thuộc. Mức chi tiết đòi hỏi của chứng cứ này tăng dần nhằm phản ánh mức bảo đảm đã yêu cầu trong TOE tổng hợp. Điều này được mong đợi nhằm phản ánh chung về sự tin cậy tăng dần đạt được từ việc ứng dụng các gói đảm bảo cho các thành phần. Đánh giá viên xác định rằng mô tả về thành phần cơ sở này nhất quán với thông tin tin cậy đã cung cấp cho thành phần phụ thuộc.

16.2.4. ACO_DEV.1 Mô tả chức năng

Phụ thuộc: ACO_REL.1 Thông tin tin cậy cơ bản

16.2.4.1. Mục tiêu

Cần có một mô tả về các giao diện trong thành phần cơ sở làm nền tảng cho thành phần phụ thuộc. Cần kiểm tra để xác định xem nó nhất quán với mô tả các giao diện làm nền tảng cho thành phần phụ thuộc hay không, như đã cung cấp trong thông tin tin cậy.

16.2.4.2. Phần tử hành động của nhà phát triển

16.2.4.2.1. ACO_DEV.1.1D

Nhà phát triển cần đưa ra thông tin phát triển cho thành phần cơ sở.

16.2.4.3. Các thành phần nội dung và trình bày

16.2.4.3.1. ACO_DEV.1.1C

Thông tin phát triển cần mô tả mục đích mỗi giao diện thành phần cơ sở sử dụng trong TOE tổng hợp.

16.2.4.3.2. ACO_DEV.1.2C

Thông tin phát triển cần chỉ ra sự phù hợp giữa các giao diện, sử dụng trong TOE tổng hợp, của thành phần cơ sở và thành phần phụ thuộc nhằm hỗ trợ TSF của thành phần phụ thuộc.

16.2.4.4. Phần tử hành động của đánh giá viên

16.2.4.4.1. ACO_DEV.1.1E

Đánh giá viên cần xác nhận rằng thông tin đáp ứng tất cả yêu cầu về nội dung và trình bày của chứng cứ.

16.2.4.4.2. ACO_DEV.1.2E

Đánh giá viên cần xác định rằng mô tả giao diện đã cung cấp nhất quán với thông tin tin cậy đã cung cấp cho thành phần phụ thuộc.

16.2.5. ACO_DEV.2 Chứng cứ cơ bản của thiết kế

Phụ thuộc: ACO_REL.1 Thông tin tin cậy cơ bản

16.2.5.1. Mục tiêu

Cần có một mô tả về các giao diện trong thành phần cơ sở làm nền tảng cho thành phần phụ thuộc. Cần kiểm tra để xác định xem nó có nhất quán với mô tả các giao diện làm nền tảng cho thành phần phụ thuộc hay không, như đã cung cấp trong thông tin tin cậy.

Ngoài ra, hoạt động an toàn của thành phần cơ sở có hỗ trợ thành phần phụ thuộc TSF được mô tả.

16.2.5.2. Phần tử hành động của nhà phát triển

16.2.5.2.1. ACO_DEV.2.1D

Nhà phát triển cần đưa ra thông tin phát triển cho thành phần cơ sở.

16.2.5.3. Các phần tử nội dung và trình bày

16.2.5.3.1. ACO_DEV.2.1C

Các thông tin phát triển sẽ mô tả các mục đích và phương pháp sử dụng của từng giao diện thành phần cơ sở được sử dụng trong TOE tổng hợp.

16.2.5.3.2. ACO_DEV.2.2C

Thông tin phát triển cần đưa ra mô tả mức cao về hoạt động của thành phần cơ sở hỗ trợ việc thực thi các SFRs của thành phần phụ thuộc.

16.2.5.3.3. ACO_DEV.2.3C

Thông tin phát triển cần chỉ ra sự phù hợp giữa các giao diện, sử dụng trong TOE tổng hợp, của thành phần cơ sở và thành phần phụ thuộc nhằm hỗ trợ TSF của thành phần phụ thuộc.

16.2.5.4. Phần tử hành động của đánh giá viên

16.2.5.4.1. ACO_DEV.2.1E

Đánh giá viên cần xác nhận rằng thông tin đáp ứng tất cả yêu cầu về nội dung và trình bày của chứng cứ.

16.2.5.4.2. ACO_DEV.2.2E

Đánh giá viên cần xác định rằng mô tả giao diện đã cung cấp nhất quán với thông tin tin cậy đã cung cấp cho thành phần phụ thuộc.

16.2.6. ACO_DEV.3 Chứng cứ chi tiết của thiết kế

Phụ thuộc: ACO_REL.2 Thông tin tin cậy

16.2.6.1. Mục tiêu

Cần có một mô tả về các giao diện trong thành phần cơ sở làm nền tảng cho thành phần phụ thuộc. Cần kiểm tra để xác định xem nó có nhất quán với mô tả các giao diện làm nền tảng cho thành phần phụ thuộc hay không, như đã cung cấp trong thông tin tin cậy.

Mô tả giao diện kiến trúc của thành phần cơ sở được cung cấp để cho phép đánh giá viên xác định giao diện này có tạo thành một phần của TSF của thành phần cơ sở hay không.

16.2.6.2. Phần tử hành động của nhà phát triển

16.2.6.2.1. ACO_DEV.3.1D

Nhà phát triển cần đưa ra thông tin phát triển cho thành phần cơ sở.

16.2.6.3. Các phần tử nội dung và trình bày

16.2.6.3.1. ACO_DEV.3.1C

Các thông tin phát triển sẽ mô tả các mục đích và phương pháp sử dụng của từng giao diện thành phần cơ sở được sử dụng trong TOE tổng hợp.

16.2.6.3.2. ACO_DEV.3.2C

Thông tin phát triển cần xác định các hệ thống con của thành phần cơ sở, cung cấp các giao diện của thành phần cơ sở dùng trong TOE tổng hợp.

16.2.6.3.3. ACO_DEV.3.3C

Thông tin phát triển cần đưa ra mô tả mức cao về hoạt động của thành phần cơ sở hỗ trợ việc thực thi các SFRs của thành phần phụ thuộc.

16.2.6.3.4. ACO_DEV.3.4C

Thông tin phát triển cần cung cấp một ánh xạ từ các giao diện tới các hệ thống con của thành phần cơ sở.

16.2.6.3.5. ACO_DEV.3.5C

Thông tin phát triển cần chỉ ra sự phù hợp giữa các giao diện, sử dụng trong TOE tổng hợp, của thành phần cơ sở và thành phần phụ thuộc nhằm hỗ trợ TSF của thành phần phụ thuộc.

16.2.6.4. Phần tử hành động của đánh giá viên

16.2.6.4.1. ACO_DEV.3.1E

Đánh giá viên cần xác nhận rằng thông tin đáp ứng tất cả yêu cầu về nội dung và trình bày của chứng cứ.

16.2.6.4.2. ACO_DEV.3.2E

Đánh giá viên cần xác định rằng mô tả giao diện đã cung cấp nhất quán với thông tin tin cậy đã cung cấp cho thành phần phụ thuộc.

16.3. Tính tin cậy của thành phần phụ thuộc (ACO_REL)

16.3.1. Mục tiêu

Mục đích của họ này là cung cấp chứng cứ mô tả sự tin cậy mà một thành phần phụ thuộc có được khi dựa vào thành phần cơ sở. Thông tin này hữu ích để người có trách nhiệm tích hợp thành phần với các thành phần CNTT đã được đánh giá khác nhằm tạo ra TOE tổng hợp, và cung cấp chi tiết về các đặc tính an toàn của sản phẩm tổng hợp.

Họ này đưa ra mô tả về giao diện giữa thành phần phụ thuộc và thành phần cơ sở của TOE tổng hợp. Giao diện này có thể không được phân tích trong đánh giá từng thành phần, vì các giao diện không phải là TSFIs của các TOE thành phần riêng lẻ.

16.3.2. Phân mức thành phần

Các thành phần trong họ này được phân mức tương ứng với số lượng chi tiết cung cấp trong mô tả về sự tin cậy của thành phần phụ thuộc vào thành phần cơ sở.

16.3.3. Chú thích ứng dụng

Họ “Sự tin cậy của thành phần phụ thuộc” (ACO_REL) xem xét tương tác giữa các thành phần, trong đó thành phần phụ thuộc dựa vào một dịch vụ của thành phần cơ sở để hỗ trợ hoạt động của chức năng an toàn của thành phần phụ thuộc. Các giao diện tới các dịch vụ này của thành phần cơ sở có thể đã không được xem xét trong đánh giá thành phần cơ sở do dịch vụ trong thành phần cơ sở đã không được xem xét tính an toàn liên quan trong đánh giá thành phần, hoặc vì mục đích kế thừa của dịch vụ (ví dụ, điều chỉnh kiểu font) hoặc bởi vì các SFRs liên quan tới TCVN 8709 đã không được yêu cầu trong ST của thành phần cơ sở (ví dụ giao diện đăng nhập khi không có yêu cầu về “FIA: các SFRs định danh và xác thực” theo TCVN 8709-2). Các giao diện tới thành phần cơ sở này thường được xem như giao diện chức năng trong đánh giá thành phần cơ sở, và xem xét thêm trong đặc tả chức năng cùng với các giao diện an toàn (TSFI).

Tóm lại, các TSFI được mô tả trong đặc tả chức năng chỉ bao gồm các lời gọi vào một TSF thực hiện bởi các thực thể bên ngoài và phản hồi với các lời gọi này. Các lời gọi thực hiện bởi một TSF không được xem xét rõ ràng trong đánh giá các thành phần, sẽ được mô tả bởi thông tin tin cậy đưa ra nhằm thỏa mãn lớp “Sự tin cậy của thành phần phụ thuộc” (ACO_REL).

16.3.4. ACO_REL.1 Thông tin tin cậy cơ bản

Các mối phụ thuộc: không có sự phụ thuộc nào.

16.3.4.1. Phần tử hành động của nhà phát triển

16.3.4.1.1. ACO_REL.1.1D

Nhà phát triển cung cấp thông tin tin cậy của thành phần phụ thuộc.

16.3.4.2. Các phần tử nội dung và trình bày

16.3.4.2.1. ACO_REL.1.1C

Thông tin tin cậy cần mô tả chức năng của thành phần cơ sở như phần cứng, phần sụn và/hoặc phần mềm làm nền tảng cho TSF của thành phần phụ thuộc.

16.3.4.2.2. ACO_REL.1.2C

Thông tin tin cậy cần mô tả tất cả các tương tác thông qua đó TSF của thành phần phụ thuộc yêu cầu dịch vụ từ thành phần cơ sở.

16.3.4.2.3. ACO_REL.1.3C

Thông tin tin cậy cần mô tả cách thức TSF phụ thuộc tự bảo vệ trước sự can thiệp và giả mạo của thành phần cơ sở.

16.3.4.3. Phần tử hành động của đánh giá viên

16.3.4.3.1. ACO_REL.1.1E

Đánh giá viên cần xác nhận rằng thông tin đã cung cấp đáp ứng mọi yêu cầu cho nội dung và hình thức của chứng cứ.

16.3.5. ACO_REL.2 Thông tin tin cậy

Các mối phụ thuộc: không có sự phụ thuộc nào.

16.3.5.1. Phần tử hành động của nhà phát triển

16.3.5.1.1. ACO_REL.2.1D

Nhà phát triển cần cung cấp thông tin tin cậy của thành phần phụ thuộc.

16.3.5.2. Các phần tử nội dung và trình bày

16.3.5.2.1. ACO_REL.2.1C

Thông tin tin cậy cần mô tả chức năng của thành phần cơ sở như phần cứng, phần sụn và/hoặc phần mềm nền tảng cho TSF của thành phần phụ thuộc.

16.3.5.2.2. ACO_REL.2.2C

Thông tin tin cậy cần mô tả tất cả các tương tác thông qua đó TSF của thành phần phụ thuộc yêu cầu dịch vụ từ thành phần cơ sở.

16.3.5.2.3. ACO_REL.2.3C

Thông tin tin cậy cần mô tả từng tương tác về giao diện sử dụng và trả lại giá trị từ những giao diện đó.

16.3.5.2.4. ACO_REL.2.4C

Thông tin tin cậy cần mô tả cách thức TSF phụ thuộc tự bảo vệ trước sự can thiệp và giả mạo của thành phần cơ sở.

16.3.5.3. Phần tử hành động của đánh giá viên

16.3.5.3.1. ACO_REL.2.1E

Đánh giá viên cần xác nhận rằng thông tin đã cung cấp đáp ứng mọi yêu cầu cho nội dung và hình thức của chứng cứ.

16.4. Kiểm thử TOE tổng hợp (ACO_CTT)

16.4.1. Mục tiêu

Họ này đòi hỏi thực hiện kiểm thử TOE tổng hợp và kiểm thử thành phần cơ sở, khi được sử dụng trong TOE tổng hợp.

16.4.2. Phân mức thành phần

Các thành phần trong họ này được phân mức trên cơ sở mức chặt chẽ tăng dần của kiểm thử giao diện và mức chặt chẽ tăng dần của phân tích tính đầy đủ của các kiểm thử nhằm thể hiện rằng TSF hoạt động tương ứng với thông tin tin cậy và các SFRs của TOE tổng hợp.

16.4.3. Chú thích ứng dụng

Có hai khía cạnh khác biệt của kiểm thử liên quan tới họ này:

a) Kiểm thử các giao diện giữa thành phần cơ sở và thành phần phụ thuộc, mà thành phần phụ thuộc dựa vào đó để thực thi chức năng an toàn, nhằm thể hiện tính tương thích của chúng.

b) Kiểm thử TOE tổng hợp để thể hiện rằng TOE ứng xử tương ứng với các SFRs của TOE tổng hợp.

Nếu các cấu hình kiểm thử dùng trong đánh giá thành phần phụ thuộc bao gồm việc sử dụng thành phần cơ bản làm “một nền tảng” và việc phân tích kiểm thử đủ để thể hiện rằng TSF tuân thủ với SFRs, nhà phát triển sẽ không cần thực hiện thêm kiểm thử nào nữa cho chức năng của TOE tổng hợp. Tuy nhiên, nếu thành phần cơ sở đã không được sử dụng trong kiểm thử thành phần phụ thuộc, hay cấu hình của một trong hai thành phần thay đổi, khi đó nhà phát triển cần thực hiện kiểm thử cho TOE tổng hợp. Điều đó có thể dẫn đến hình thức nhà phát triển lặp lại các kiểm thử cho thành phần phụ thuộc nhằm đưa ra bằng chứng phù hợp về việc TOE tổng hợp tuân thủ với các SFRs.

Nhà phát triển cần đưa ra chứng cứ về kiểm thử các giao diện thành phần cơ sở đã dùng khi tổng hợp. Hoạt động của TSFIs của thành phần cơ sở có thể đã được kiểm thử trong một phần của lớp ATE: “Các hoạt động kiểm thử” trong đánh giá thành phần cơ sở. Vì vậy, nếu các giao diện thích hợp đã được đưa vào mẫu kiểm thử trong đánh giá thành phần cơ sở và trong lớp “Sở cứ tổng hợp (ACO_COR) đã xác định rằng thành phần cơ sở đang hoạt động tuân theo cấu hình thành phần cơ sở đã đánh giá, với việc mọi chức năng an toàn đòi hỏi bởi thành phần cơ sở đã có trong TSF, thì hành động của đánh giá viên ACO_CTT.1.1E có thể thỏa mãn thông qua việc tái sử dụng thành phần cơ sở ATE: Quyết định kiểm thử.

Nếu không phải như vậy thì các giao diện thành phần cơ sở đã dùng tương ứng cho tổng hợp với sự ảnh hưởng bởi mọi biến đổi về cấu hình đánh giá và mọi chức năng an toàn bổ sung sẽ được kiểm thử nhằm đảm bảo chúng thể hiện hoạt động như mong đợi. Hoạt động mong đợi được kiểm thử là hoạt động đã được mô tả trong thông tin tin cậy (bằng chứng về Sự tin cậy của thành phần phụ thuộc (ACO_REL)).

16.4.4. ACO_CTT.1 Kiểm thử giao diện

Phụ thuộc:

ACO_REL.1 Thông tin tin cậy cơ bản

ACO_DEV.1 Mô tả chức năng

16.4.4.1. Mục tiêu

Mục tiêu của thành phần này là nhằm đảm bảo rằng mỗi giao diện của thành phần cơ sở, mà thành phần phụ thuộc dựa vào đó, được kiểm thử.

16.4.4.2. Phần tử hành động của nhà phát triển

16.4.4.2.1. ACO_CTT.1.1D

Nhà phát triển cần đưa ra tài liệu kiểm thử TOE tổng hợp.

16.4.4.2.2. ACO_CTT.1.2D

Nhà phát triển cần đưa ra tài liệu kiểm thử giao diện thành phần cơ sở.

16.4.4.2.3. ACO_CTT.1.3D

Nhà phát triển cần đưa ra TOE tổng hợp để kiểm thử.

16.4.4.2.4. ACO_CTT.1.4D

Nhà phát triển cần đưa ra một tập tài nguyên tương đương với tập dùng trong kiểm thử chức năng thành phần cơ sở của nhà phát triển.

16.4.4.3. Các phần tử nội dung và trình bày

16.4.4.3.1. ACO_CTT.1.1C

Tài liệu kiểm thử cho TOE tổng hợp và giao diện thành phần cơ sở cần bao gồm kế hoạch kiếm thử, kết quả kiểm thử dự kiến kết quả kiểm thử thực tế.

16.4.4.3.2. ACO_CTT.1.2C

Tài liệu kiểm thử có được từ việc nhà phát triển thực hiện kiểm thử TOE tổng hợp cần chứng tỏ rằng TSF tuân thủ theo quy định.

16.4.4.3.3. ACO_CTT.1.3C

Tài liệu kiểm thử có được từ việc nhà phát triển thực hiện kiểm thử thành phần cơ sở cần chứng tỏ rằng giao diện thành phần cơ sở mà thành phần cơ sở dựa vào tuân thủ theo quy định.

16.4.4.3.4. ACO_CTT.1.4C

Thành phần cơ sở cần thích hợp cho kiểm thử.

16.4.4.4. Phần tử hành động của đánh giá viên

16.4.4.4.1. ACO_CTT.1.1E

Đánh giá viên cần xác nhận rằng thông tin đã cung cấp đáp ứng mọi yêu cầu cho nội dung và hình thức của chứng cứ.

16.4.4.4.2. ACO_CTT.1.2E

Đánh giá viên cần thực hiện một kiểm thử mẫu trong tài liệu kiểm thử để kiểm nghiệm các kết quả kiểm thử của nhà phát triển.

16.4.4.4.3. ACO_CTT.1.3E

Đánh giá viên cần kiểm thử một tập con các giao diện TSF của TOE tổng hợp để khẳng định rằng TSF tổng hợp hoạt động theo quy định.

16.4.5. ACO_CTT.2 Kiểm thử giao diện chặt chẽ

Phụ thuộc:

ACO_REL.2 Thông tin tin cậy

ACO_DEV.2 Chứng cứ cơ bản của thiết kế.

16.4.5.1. Mục tiêu

Mục tiêu của thành phần này là để đảm bảo rằng mỗi giao diện của thành phần cơ sở, mà thành phần phụ thuộc dựa vào nó, được kiểm thử.

16.4.5.2. Phần tử hành động của nhà phát triển

16.4.5.2.1. ACO_CTT.2.1D

Nhà phát triển cần đưa ra tài liệu kiểm thử TOE tổng hợp.

16.4.5.2.2. ACO_CTT.2.2D

Nhà phát triển cần đưa ra tài liệu kiểm thử giao diện thành phần cơ sở.

16.4.5.2.3. ACO_CTT.2.3D

Nhà phát triển cần đưa ra TOE tổng hợp để kiểm thử.

16.4.5.2.4. ACO_CTT.2.4D

Nhà phát triển cần đưa ra một tập tài nguyên tương đương với tập dùng trong kiểm thử chức năng thành phần cơ sở của nhà phát triển.

16.4.5.3. Các phần tử nội dung và trình bày

16.4.5.3.1. ACO_CTT.2.1C

Tài liệu kiểm thử cho TOE tổng hợp và giao diện thành phần cơ sở cần bao gồm kế hoạch kiểm thử, kết quả kiểm thử dự kiến kết quả kiểm thử thực tế.

16.4.5.3.2. ACO_CTT.2.2C

Tài liệu kiểm thử có được từ việc nhà phát triển thực hiện kiểm thử TOE tổng hợp cần chứng tỏ rằng TSF tuân thủ theo quy định và đầy đủ.

16.4.5.3.3. ACO_CTT.2.3C

Tài liệu kiểm thử có được từ việc nhà phát triển thực hiện kiểm thử thành phần cơ sở cần chứng tỏ rằng giao diện thành phần cơ sở mà thành phần cơ sở dựa vào tuân thủ theo quy định và đầy đủ.

16.4.5.3.4. ACO_CTT.2.4C

Thành phần cơ sở cần thích hợp cho kiểm thử.

16.4.5.4. Phần tử hành động của đánh giá viên

16.4.5.4.1. ACO_CTT.2.1E

Đánh giá viên cần xác nhận rằng thông tin đã cung cấp đáp ứng mọi yêu cầu cho nội dung và hình thức của chứng cứ.

16.4.5.4.2. ACO_CTT.2.2E

Đánh giá viên cần thực hiện một kiểm thử mẫu trong tài liệu kiểm thử để kiểm nghiệm các kết quả kiểm thử của nhà phát triển.

16.4.5.4.3. ACO_CTT.2.3E

Đánh giá viên cần kiểm thử một tập con các giao diện TSF của TOE tổng hợp để khẳng định rằng TSF tổng hợp hoạt động theo quy định.

16.5. Phân tích điểm yếu tổng hợp (ACO_VUL)

16.5.1. Mục tiêu

Họ này dùng cho phân tích thông tin điểm yếu sẵn có thông báo công khai và các điểm yếu có thể sẽ nảy sinh khi tổng hợp.

16.5.2. Phân mức thành phần

Các thành phần trong họ này được phân mức trên cơ sở khảo sát kỹ lưỡng với mức tăng dần thông tin điểm yếu đã thông báo công khai và phân tích điểm yếu một cách độc lập.

16.5.3. Chú thích ứng dụng

Nhà phát triển sẽ cung cấp chi tiết của mọi điểm yếu còn lại ghi nhận trong đánh giá các thành phần. Điều này có thể đạt được từ các nhà phát triển thành phần hoặc từ các báo cáo đánh giá thành phần. Những thông tin này sẽ được sử dụng làm đầu vào cho phân tích điểm yếu của TOE tổng hợp trong môi trường vận hành.

Môi trường vận hành của TOE tổng hợp được kiểm tra nhằm đảm bảo rằng các giả định và mục tiêu cho môi trường vận hành thành phần (quy định cho từng ST thành phần) được thỏa mãn trong TOE tổng hợp. Một phân tích ban đầu về tính nhất quán của các giả định và mục tiêu giữa các thành phần và các STs của TOE tổng hợp sẽ được thực hiện trong khi tiến hành các hoạt động ASE cho TOE tổng hợp. Tuy nhiên, việc phân tích này được nhắc lại với những hiểu biết thu được trong các hoạt động ACO_REL, ACO_DEV và ACO_COR nhằm đảm bảo rằng, ví dụ, các giả định về thành phần phụ thuộc đã được đề cập đến trong môi trường trong ST của thành phần phụ thuộc sẽ không được nhắc lại trong kết quả tổng hợp (nghĩa là thành phần cơ sở đề cập một cách tương xứng các giả định về ST của thành phần phụ thuộc trong TOE tổng hợp).

Đánh giá viên sẽ tìm kiếm các vấn đề trong mỗi thành phần, xác định các điểm yếu tiềm ẩn đã thông báo trên phạm vi công cộng sau khi hoàn tất đánh giá các thành phần. Mọi điểm yếu tiềm ẩn sẽ được kiểm thử.

Nếu thành phần cơ sở đã dùng trong TOE tổng hợp trở thành chủ đề của các hoạt động duy trì bảo đảm từ khi có chứng nhận, đánh giá viên sẽ xem xét trong các hoạt động phân tích điểm yếu của TOE tổng hợp những thay đổi đã thực hiện trong thành phần cơ sở.

16.5.4. ACO_VUL.1 Soát xét điểm yếu tổng hợp

Phụ thuộc: ACO_DEV.1 Mô tả chức năng

16.5.4.1. Phần tử hành động của nhà phát triển

16.5.4.1.1. ACO_VUL.1.1D

Nhà phát triển cần đưa ra TOE tổng hợp để kiểm thử.

16.5.4.2. Các phần tử nội dung và trình bày

16.5.4.2.1. ACO_VUL.1.1C

TOE tổng hợp cần thích hợp cho kiểm thử.

16.5.4.3. Phần tử hành động của đánh giá viên

16.5.4.3.1. ACO_VUL.1.1E

Đánh giá viên cần xác nhận rằng thông tin đã cung cấp đáp ứng mọi yêu cầu cho nội dung và hình thức của chứng cứ.

16.5.4.3.2. ACO_VUL.1.2E

Đánh giá viên cần thực hiện phân tích nhằm xác định mọi điểm yếu vốn có xác định cho thành phần cơ sở và thành phần phụ thuộc không bị khai thác trong TOE tổng hợp và môi trường vận hành của nó.

16.5.4.3.3. ACO_VUL.1.3E

Đánh giá viên cần thực hiện tìm kiếm các nguồn thông tin công cộng để xác định các điểm yếu có thể phát sinh từ việc dùng các thành phần cơ sở và thành phần phụ thuộc trong môi trường vận hành TOE tổng hợp.

16.5.4.3.4. ACO_VUL.1.4E

Đánh giá viên cần tiến hành kiểm thử xâm nhập, dựa trên các điểm yếu đã xác định, để chứng minh rằng TOE tổng hợp được bảo vệ trước các tấn công bởi kẻ tấn công có tiềm năng tấn công cơ bản.

16.5.5. ACO_VUL.2 Phân tích điểm yếu tổng hợp

Phụ thuộc: ACO_DEV.2 Chứng cứ cơ bản của thiết kế

16.5.5.1. Phần tử hành động của nhà phát triển

16.5.5.1.1. ACO_VUL.2.1D

Nhà phát triển cần đưa ra TOE tổng hợp để kiểm thử.

16.5.5.2. Các phần tử nội dung và trình bày

16.5.5.2.1. ACO_VUL.2.1C

TOE tổng hợp cần thích hợp cho kiểm thử.

16.5.5.3. Phần tử hành động của đánh giá viên

16.5.5.3.1. ACO_VUL.2.1E

Đánh giá viên cần xác nhận rằng thông tin đã cung cấp đáp ứng mọi yêu cầu cho nội dung và hình thức của chứng cứ.

16.5.5.3.2. ACO_VUL.2.2E

Đánh giá viên cần thực hiện phân tích nhằm xác định mọi điểm yếu vốn có xác định cho thành phần cơ sở và thành phần phụ thuộc không bị khai thác trong TOE tổng hợp và môi trường vận hành của nó.

16.5.5.3.3. ACO_VUL.2.2E

Đánh giá viên cần thực hiện tìm kiếm các nguồn thông tin công cộng để xác định các điểm yếu có thể phát sinh từ việc dùng các thành phần cơ sở và thành phần phụ thuộc trong môi trường vận hành TOE tổng hợp.

16.5.5.3.4. ACO_VUL.2.4E

Đánh giá viên cần thực hiện phân tích điểm yếu độc lập cho TOE tổng hợp thông qua sử dụng tài liệu hướng dẫn, thông tin tin cậy và sở cứ tổng hợp nhằm xác định các điểm yếu tiềm ẩn trong TOE tổng hợp.

16.5.5.3.5. ACO_VUL.2.5E

Đánh giá viên cần tiến hành kiểm thử xâm nhập, dựa trên các điểm yếu đã xác định, để chứng minh rằng TOE tổng hợp được bảo vệ trước các tấn công bởi kẻ tấn công có tiềm năng tấn công cơ bản.

16.5.6. ACO_VUL.3 Phân tích điểm yếu tổng hợp cơ bản - nâng cao

Phụ thuộc: ACO_DEV.3 Chứng cứ chi tiết về thiết kế

16.5.6.1. Phần tử hành động của nhà phát triển

16.5.6.1.1. ACO_VUL.3.1D

Nhà phát triển cần đưa ra TOE tổng hợp để kiểm thử.

16.5.6.2. Các phần tử nội dung và trình bày

16.5.6.2.1. ACO_VUL.3.1C

TOE tổng hợp cần thích hợp cho kiểm thử

16.5.6.3. Phần tử hành động của đánh giá viên

16.5.6.3.1. ACO_VUL.3.1E

Đánh giá viên cần xác nhận rằng thông tin đã cung cấp đáp ứng mọi yêu cầu cho nội dung và hình thức của chứng cứ.

16.5.6.3.2. ACO_VUL.3.2E

Đánh giá viên cần thực hiện phân tích nhằm xác định mọi điểm yếu vốn có xác định cho thành phần cơ sở và thành phần phụ thuộc không bị khai thác trong TOE tổng hợp và môi trường vận hành của nó.

16.5.6.3.3. ACO_VUL.3.3E

Đánh giá viên cần thực hiện tìm kiếm các nguồn thông tin công cộng để xác định các điểm yếu có thể phát sinh từ việc dùng các thành phần cơ sở và thành phần phụ thuộc trong môi trường vận hành TOE tổng hợp.

16.5.6.3.4. ACO_VUL.3.4E

Đánh giá viên cần thực hiện phân tích điểm yếu độc lập cho TOE tổng hợp thông qua sử dụng tài liệu hướng dẫn, thông tin tin cậy và sở cứ tổng hợp nhằm xác định các điểm yếu tiềm ẩn trong TOE tổng hợp.

16.5.6.3.5. ACO_VUL.3.5E

Đánh giá viên cần tiến hành kiểm thử xâm nhập, dựa trên các điểm yếu đã xác định, để chứng minh rằng TOE tổng hợp được bảo vệ trước các tấn công bởi kẻ tấn công có tiềm năng tấn công cơ bản.

 

Phụ lục A

(Tham khảo)

Lớp phát triển (ADV)

Phụ lục này có chứa tài liệu phụ trợ để tiếp tục giải thích và cung cấp các ví dụ bổ sung cho các chủ đề đưa ra trong các họ của lớp ADV: Lớp Phát triển.

A.1. ADV_ARC: Bổ sung các tài liệu trên kiến trúc an toàn

Một kiến trúc an toàn là một bộ các thuộc tính mà TSF trình bày; những thuộc tính này bao gồm tự bảo vệ, tách miền, và non-bypassability. Có những thuộc tính cung cấp cơ sở tin cậy để TSF cung cấp những dịch vụ an toàn của nó. Phụ lục này cung cấp tài liệu bổ sung trên các thuộc tính đó, cũng như những thảo luận về nội dung của một mô tả kiến trúc an toàn.

Ngoài ra mục này, trước hết sẽ giải thích những thuộc tính đó, sau đó thảo luận về những loại thông tin cần thiết để mô tả cách TSF trình bày những thuộc tính đó.

A.1.1. Các thuộc tính trong kiến trúc an toàn

Tự bảo vệ đề cập đến khả năng TSF bảo vệ cho chính nó bằng thao tác từ các thực thể bên ngoài mà vẫn có thể dẫn đến những thay đổi trong TSF. Nếu thiếu những thuộc tính này, các TSF có thể bị vô hiệu hóa khi thực hiện các dịch vụ an toàn của nó.

Đôi khi có trường hợp mà một TOE sử dụng các dịch vụ hoặc nguồn tài nguyên cung cấp bởi các thực thể CNTT khác để thực hiện chức năng của nó (ví dụ như một ứng dụng dựa trên hệ điều hành cơ bản của nó). Trong những trường hợp này, các TSF không tự bảo vệ mình hoàn toàn, bởi vì nó phụ thuộc vào các thực thể IT khác để bảo vệ các dịch vụ nó sử dụng.

Tách miền là một thuộc tính theo đó TSF tạo ra các miền an toàn riêng cho từng thực thể hành động không tin cậy để hoạt động trên tài nguyên của nó, và sau đó giữ những miền đó được tách biệt khỏi những thực thể còn lại để không thực thể nào có thể chạy trên miền của bất kỳ thực thể khác. Ví dụ, một TOE hệ điều hành sẽ cấp một tên miền (không gian địa chỉ, biến môi trường trên một tiến trình) cho từng tiến trình liên kết với các thực thể không tin cậy.

Đối với một số TOE tên miền không tồn tại vì tất cả các hành động của các thực thể không tin cậy được đưa ra bởi TSF. Một bức tường lửa lọc gói là một ví dụ của TOE như vậy, nơi không có những tên miền của thực thể không tin cậy; chỉ có những cấu trúc dữ liệu chỉ được duy trì bởi các TSF. Trong trường hợp mà ở đó TOE không cung cấp tên miền cho những thực thể không tin cậy, họ này yêu cầu những tên miền đó phải được cô lập khỏi những miền khác, như vậy những thực thể không tin cậy trong một miền bị ngăn chặn việc giả mạo từ các miền khác của thực thể không tin cậy.

Non-bypassability là một thuộc tính mà các chức năng an toàn của TSF (đặc tả bởi SFR) luôn được yêu cầu và không thể bị phá vỡ, thích hợp cho cơ chế cụ thể. Ví dụ, nếu việc điều khiển truy cập vào các tệp được quy định như một khả năng của TSF qua một SFR, thì không cần có giao diện mà thông qua đó các tập tin có thể được truy cập mà không cần viện dẫn cơ chế điều khiển truy cập của TSF.

Như là trường hợp tự bảo vệ, chính bản chất của một số TOE có thể phụ thuộc vào môi trường của chúng để đóng vai trò trong non-bypassability của TSF. Ví dụ, một TOE ứng dụng an toàn yêu cầu rằng nó được gọi bởi hệ điều hành cơ bản. Tương tự như vậy, tường lửa phụ thuộc vào thực tế là không có kết nối trực tiếp giữa các mạng nội bộ và bên ngoài và tất cả lưu lượng giữa chúng phải đi qua tường lửa.

A.1.2. Mô tả kiến trúc an toàn

Mô tả kiến trúc an toàn giải thích cách các thuộc tính mô tả ở trên được trình bày bởi các TSF. Nó mô tả các miền được định nghĩa thế nào và TSF giữ chúng riêng biệt như thế nào. Nó mô tả cái gì ngăn chặn các tiến trình không tin cậy khỏi việc nhận TSF và sửa đổi nó. Nó mô tả các gì đảm bảo rằng tất cả các tài nguyên thuộc thẩm quyền kiểm soát của TSF được bảo vệ đầy đủ và tất cả hành động liên quan đến SFR được dàn xếp bởi TSF. Nó giải thích vai trò bất kỳ mà môi trường đó thực hiện trong bất kỳ những vai trò