Tiêu chuẩn Quốc gia TCVN 11386:2016 ISO/IEC 18045:2008 Công nghệ thông tin-Các kỹ thuật an toàn-Phương pháp đánh giá an toàn công nghệ thông tin

  • 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 11386:2016

Tiêu chuẩn Quốc gia TCVN 11386:2016 ISO/IEC 18045:2008 Công nghệ thông tin-Các kỹ thuật an toàn-Phương pháp đánh giá an toàn công nghệ thông tin
Số hiệu:TCVN 11386:2016Loạ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
Ngày ban hành:31/08/2016Hiệu lực:
Đã biết

Vui lòng đăng nhập tài khoản để xem Ngày áp dụng. Nếu chưa có tài khoản Quý khách đăng ký tại đây!

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 11386:2016

ISO/IEC 18045:2008

CÔNG NGHỆ THÔNG TIN - CÁC KỸ THUẬT AN TOÀN - PHƯƠNG PHÁP ĐÁNH GIÁ AN TOÀN CÔNG NGHỆ THÔNG TIN

Information technology - Security techniques - Methodology for IT security evaluation

Lời nói đầu

TCVN 11386:2016 (ISO/IEC 18045:2008) hoàn toàn tương đương với ISO/IEC 18045:2008

TCVN 11386:2016 (ISO/IEC 18045: 2008) do Học viện Công nghệ Bưu chính Viễn thông 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ố.

Giới thiệu

Đối tượng hướng tới đối với tiêu chuẩn này chủ yếu là những người đánh giá áp dụng TCVN 8709 (ISO/IEC 15408) và các chứng nhận viên khẳng định các hoạt động người đánh giá; các nhà bảo trợ đánh giá, các nhà phát triển, các tác giả PP/ST và các bên khác quan tâm đến an toàn công nghệ thông tin là đối tượng thứ yếu.

Tiêu chuẩn này thừa nhận rằng, không phải tất cả các câu hỏi liên quan đến đánh giá an toàn công nghệ thông tin sẽ được trả lời ở đây và sẽ cần các diễn giải tiếp theo. Các lược đồ riêng sẽ quyết định cách xử lý những diễn giải đó mặc dù chúng có thể là chủ đề cho các thỏa thuận công nhận lẫn nhau. Danh sách các hoạt động liên quan đến phương pháp luận có thể được xử lý bởi các lược đồ riêng nằm trong Phụ lục A.

 

CÔNG NGHỆ THÔNG TIN - CÁC KỸ THUẬT AN TOÀN - PHƯƠNG PHÁP ĐÁNH GIÁ AN TOÀN CÔNG NGHỆ THÔNG TIN

Information technology - Security techniques - Methodology for IT Evaluation

1  Phạm vi áp dụng

Tiêu chuẩn này là tài liệu đi kèm với các tiêu chí đánh giá an toàn công nghệ thông tin đã được quy định trong TCVN 8709 (ISO/IEC 15408). Tiêu chuẩn này quy định các hành động tối thiểu cần được thực hiện bởi người đánh giá để tiến hành việc đánh giá theo TCVN 8709 (ISO/IEC 15408), sử dụng tiêu chí và bằng chứng đánh giá quy định trong TCVN 8709 (ISO/IEC 15408).

Tiêu chuẩn này không quy định các hành động của người đánh giá đối với các thành phần đảm bảo mức cao nhất định trong TCVN 8709 (ISO/IEC 15408), vì ở đó không đưa ra hướng dẫn được chấp thuận rộng rãi.

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

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

TCVN 8709 (ISO/IEC 15408 (tất cả các phần)), công nghệ thông tin - Các kỹ thuật an toàn - Các tiêu chí đánh giá an toàn công nghệ thông tin.

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

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

CHÚ THÍCH: Các thuật ngữ được in đm là những thuật ngữ được định nghĩa tại điều này.

3.1

Hành động (action)

Phần t hành động của người đánh giá trong TCVN 8709-3 (ISO/IEC 15408-3).

CHÚ THÍCH: Những hành động này hoặc được chỉ rõ là các hành động của người đánh giá hoặc ngm định xuất phát từ các hành động của nhà phát trin (ngầm đnh là các hành động của người đánh giá) trong các thành phần đảm bảo của TCVN 8709-3 (ISO/IEC 15408-3).

3.2 

Hoạt động (activity)

Việc áp dụng theo một lớp bảo đảm của TCVN 8709-3 (ISO/IEC 15408-3).

3.3

Kiểm tra (check)

Tạo ra nhận định bằng một so sánh đơn giản.

CHÚ THÍCH: Không yêu cầu ý kiến chuyên môn của người đánh giá. Phát biểu sử dụng động từ này mô tả những gì được ánh xạ.

3.4

Giao phm đánh giá (evaluation deliverable)

Tài nguyên bất kỳ được yêu cầu từ nhà bảo trợ hoặc nhà phát triển bởi người đánh giá hoặc tổ chức đánh giá để thực hiện một hoặc nhiều đánh giá hoặc các hoạt động giám sát đánh giá.

3.5

Bằng chứng đánh giá (evaluation evidence)

Giao phẩm đánh giá hữu hình.

3.6

Báo cáo kỹ thuật đánh giá (evaluation technical report)

Báo cáo ghi lại nhận định tổng thể và lời biện minh, được đưa ra bởi người đánh giá và được đệ trình lên một tổ chức đánh giá.

3.7

Thẩm tra (examine)

Tạo ra một nhận định bằng cách phân tích theo ý kiến chuyên môn của người đánh giá.

CHÚ THÍCH: Phát biểu sử dụng động từ này xác định những gì được phân tích và các thuộc tính mà nó được phân tích.

3.8

Diễn giải (interpretation)

Sự làm rõ hoặc mở rộng một yêu cầu của TCVN 8709 (ISO/IEC 15408), TCVN 11386:2016 (ISO/IEC 18045:2008) hoặc lược đồ.

3.9

Phương pháp luận (methodology)

Hệ thống các nguyên tắc, thủ tục và quy trình áp dụng cho đánh giá an toàn công nghệ thông tin.

3.10

Báo cáo quan sát (observation report)

Báo cáo được viết bởi người đánh giá để yêu cầu làm rõ hoặc để xác định một vấn đề trong khi đánh giá.

3.11

Nhận định tổng thể (overall verdict)

Phát biểu "đạt" hay "không đạt" được đưa ra bởi một người đánh giá đối với kết quả của một đánh giá.

3.12

Nhận định giám sát (oversight verdict)

Tuyên bố được tạo ra bởi tổ chức đánh giá khẳng định hay phủ nhận một "nhận định tổng thể" dựa trên các kết quả của các hoạt động giám sát đánh giá.

3.13

Hồ sơ (record)

Lưu lại một mô tả bằng văn bản của các thủ tục, sự kiện, quan sát, những hiểu biết và các kết quả một cách đầy đ chi tiết cho phép tái tạo dừng lại công việc đã thực hiện trong khi đánh giá ở một thời điểm sau đó.

3.14 

Báo cáo (report)

Gồm Kết quả đánh giá và các tài liệu hỗ trợ trong bn báo cáo kỹ thuật đánh giá hoặc báo cáo quan sát.

3.15

Lược đồ (scheme)

Tập hợp các quy tắc, được lập bởi một tổ chức đánh giá, xác định môi trường đánh giá, bao gồm các tiêu chí và phương pháp luận được yêu cầu để tiến hành các đánh giá an toàn công nghệ thông tin.

3.16

Hoạt động con (sub-activity)

Việc áp dụng theo một thành phần đảm bảo của TCVN 8709-3 (ISO/IEC 15408-3).

CHÚ THÍCH: Các họ đảm bảo không được đề cập rõ ràng trong tiêu chuẩn này vì các đánh giá được tiến hành trên một thành phần đảm bảo đơn nhất từ một họ đảm bảo.

3.17

Theo dấu (tracing)

Mối quan hệ định hướng đơn nhất giữa hai tập thực thể cho thy các thực th nào trong tập đầu tiên tương ứng với thực thể nào trong tập th hai.

3.18 

Nhận định (verdict)

Tuyên bố "đạt", "không đạt" hoặc "không thể kết luận" được tạo ra bởi một người đánh giá với phần tử hành động của người đánh giá, thành phần đảm bảo hoặc lớp của TCVN 8709 (ISO/IEC 15408).

CHÚ THÍCH: Xem thêm nhận định tổng thể.

3.19 

Đơn v công việc (work unit)

Mức chi tiết nhất của công việc đánh giá

CHÚ THÍCH: Mỗi hành động của phương pháp lun đánh giá bao gồm một hoặc nhiều đơn vị công việc được nhóm lại trong hành động của phương pháp đánh giá theo nội dung TCVN 8709 (ISO/IEC 15408) và trình bày các bằng chứng hoặc phn t hành động của nhà phát triển. Các đơn vị công việc được thể hiện trong tiêu chuẩn này theo cùng thứ tự như các phần tử trong TCVN 8709 (ISO/IEC 15408) nơi chúng được bắt nguồn. Các đơn vị công việc được định dạng l trái được ký hiệu như ALC_TAT.1-2. Trong ký hiệu này, chuỗi ALC_TAT.1 biểu thị thành phần TCVN 8709 (ISO/IEC 15408) (nghĩa là hoạt động con trong tiêu chuẩn này) và chữ số cuối cùng (2) biu thị đây là đơn vị công việc thứ hai trong hoạt động con ALC_TAT.1.

4  Ký hiệu và chữ viết tắt

ETR

Báo cáo kỹ thuật đánh giá

OR

Báo cáo quan sát

Các ký hiệu và chữ viết tắt khác tham khảo TCVN 8709 (ISO/IEC 15408).

5  Tổng quan

5.1  Bố cục của TCVN 11386:2016 (ISO/IEC 18045:2008)

Điều 6 xác định các quy ước được sử dụng trong tiêu chuẩn này.

Điều 7 mô tả các nhiệm vụ đánh giá chung không có nhận định liên quan đến chúng vì chúng không ánh xạ đến các phần tử hành động của người đánh giá trong TCVN 8709 (ISO/IEC 15408).

Điều 8 đề cập công việc được yêu cầu đ đạt được một kết quả đánh giá trên một PP.

Từ Điều 9 đến Điều 15 xác định các hoạt động đánh giá được tổ chức bởi các lớp đảm bảo.

Phụ lục A bao gồm các kỹ thuật đánh giá cơ bản được sử dụng để cung cấp các bằng chứng kỹ thuật của kết quả đánh giá.

Phụ lục B cung cấp diễn giải của các tiêu chí phân tích điểm yếu và những ví dụ về ứng dụng của chúng.

6  Quy ước trong tiêu chuẩn

6.1  Thuật ngữ

Không giống như TCVN 8709 (ISO/IEC 15408), trong đó mỗi phần tử duy trì chữ số cuối cùng của ký hiệu định dạng của nó cho tất cả các thành phần trong họ, tiêu chuẩn này có thể tạo ra các đơn vị công việc mới khi một phần tử hành động của người đánh giá trong TCVN 8709 (ISO/IEC 15408) thay đổi từ hoạt động con này sang hoạt động con khác; kết quả là chữ số cuối cùng của ký hiệu định dạng đơn vị công việc có thể thay đổi mặc dù đơn vị công việc giữ nguyên không thay đổi.

Một công việc đánh giá cụ thể theo phương pháp luận bất kỳ nào được yêu cầu mà không bắt nguồn trực tiếp từ các yêu cầu trong TCVN 8709 (ISO/IEC 15408) được gọi là "nhiệm vụ" hoặc "nhiệm vụ con".

6.2  Cách sử dụng động từ

Từ "cần" (shall) ch được sử dụng khi văn bản được cung cấp là bắt buộc và do vậy chỉ dùng trong các đơn vị công việc và các nhiệm vụ con. Các đơn vị công việc và các nhiệm vụ con bao gồm các hoạt động bắt buộc mà người đánh giá phải thực hiện để chỉ định các nhận định.

Văn bản hướng dẫn kèm theo các đơn vị công việc và nhiệm vụ con đưa ra giải thích thêm về cách áp dụng các từ ngữ TCVN 8709 (ISO/IEC 15408) trong phép đánh giá. Cách sử dụng động từ phù hợp với các định nghĩa ISO cho các động từ này. Từ "nên" (should) được sử dụng khi phương pháp được mô tả là ưa chuộng hơn. Tất cả các từ khác, bao gồm "có thể" (may), được sử dụng khi (các) phương pháp được mô tả là được cho phép song không được khuyến cáo cũng như được ưa chuộng hơn, chúng chỉ dùng để diễn gii.

Các động từ kiểm tra, thẩm tra, báo cáoghi lại được sử dụng với ý nghĩa chính xác trong phần này của tiêu chuẩn và nên tham chiếu Điều 3 về các định nghĩa của chúng.

6.3  Hướng dẫn đánh giá tổng quát

Tài liệu có tính ứng dụng cho nhiều hơn một hoạt động con được tập hợp ở một vị trí. Hướng dẫn có tính ứng dụng phổ biến (xuyên suốt các hoạt động và các EAL) được tập hợp trong Phụ lục A. Hướng dẫn gắn liền với nhiều hoạt động con trong một hoạt động đơn l đã được cung cấp trong phần giới thiệu của hoạt động đó. Nếu hướng dn liên quan đến ch một hoạt động con đơn lẻ thì nó được trình bày trong hoạt động con đó.

6.4  Mối quan hệ giữa các cấu trúc TCVN 8709 (ISO/IEC 15408) và TCVN 11386:2016 (ISO/IEC 18045:2008)

Giữa cấu trúc của TCVN 8709 (ISO/IEC 15408) (tức là lớp, họ, thành phần và phần tử) và cấu trúc của tiêu chuẩn này có các mi quan hệ trực tiếp. Hình 1 minh ha sự tương ứng giữa các kết cấu TCVN 8709 (ISO/IEC 15408) về lớp, họ và các phần tử hành động của người đánh giá với các hoạt động, hoạt động con và hành động trong phương pháp đánh giá. Tuy nhiên, một số đơn vị công việc trong phương pháp đánh giá có thể là kết quả từ các yêu cầu đã được ghi chú trong các phần tử hành động của nhà phát triển trong TCVN 8709 (ISO/IEC 15408) và phần tử nội dung và trình bày.

Hình 1 - Ánh xạ của các cấu trúc của TCVN 8709 (ISO/IEC 15408) và TCVN 11386:2016 (ISO/IEC 18045:2008)

7  Quy trình đánh giá và các nhiệm vụ liên quan

7.1  Giới thiệu

Điều này cung cấp tổng quan về quy trình đánh giá và xác định các nhiệm vụ của người đánh giá được dự định thực hiện khi tiến hành đánh giá.

Mỗi một đánh giá hoặc là một PP hoặc là một TOE (bao gồm cả ST), đều theo quy trình như nhau và có bốn nhiệm vụ chung của người đánh giá là: nhiệm vụ đầu vào, nhiệm vụ đầu ra, hoạt động con đánh giá và sự thuyết minh về năng lực kỹ thuật đối với nhiệm vụ của tổ chức đánh giá.

Nhiệm vụ đầu vào và các nhiệm vụ đầu ra có liên quan đến quản lý bằng chứng đánh giá và phát sinh báo cáo được mô tả trọn vẹn trong điều này. Mỗi nhiệm vụ có các nhiệm vụ con liên quan được áp dụng và quy định cho tất cả các đánh giá của TCVN 8709 (ISO/IEC 15408) (đánh giá một PP hoặc một TOE).

Các hoạt động con đánh giá chỉ được giới thiệu trong điều này và được mô tả đầy đủ trong các điều tiếp theo.

Trái ngược với các hoạt động con đánh giá, các nhiệm vụ đầu vào và đầu ra không có nhận định liên quan đến chúng vì chúng không ánh xạ tới các phần tử hành động của người đánh giá trong TCVN 8709 (ISO/IEC 15408); các nhiệm vụ này được thực hiện để đảm bảo phù hợp với các nguyên tắc phổ biến và tuân thủ tiêu chuẩn này.

Sự thuyết minh về năng lực kỹ thuật đối với nhiệm vụ của tổ chức đánh giá có thể được hoàn thiện bằng phép phân tích của tổ chức đánh giá về các kết quả nhiệm v đầu ra hoặc có thể bao gồm sự thuyết minh của người đánh giá từ sự hiu biết của họ về các đầu vào đối với các hoạt động con đánh giá. Nhiệm vụ này không có nhận định của người đánh giá liên quan nhưng có nhận định của tổ chức đánh giá. Các tiêu chí chi tiết để đạt nhiệm vụ này là theo quyết định của tổ chức đánh giá, như đã nêu trong Phụ lục A.5.

7.2  Tng quan v quá trình đánh giá

7.2.1  Mục tiêu

Điều này trình bày mô hình chung của phương pháp luận và xác định:

a) Các vai trò và trách nhiệm của các bên liên quan trong quy trình đánh giá;

b) Mô hình đánh giá chung.

7.2.2  Trách nhiệm của các vai trò

Mô hình chung xác định đặc điểm của các vai trò sau: nhà bảo trợ, nhà phát triển, người đánh giá và tổ chức đánh giá.

Nhà bảo trợ có trách nhiệm yêu cầu và hỗ trợ việc đánh giá. Điều này có nghĩa là nhà bảo trợ thiết lập các thỏa thuận khác nhau cho việc đánh giá (ví dụ như ủy thác đánh giá). Ngoài ra, nhà bảo trợ có trách nhiệm đảm bảo rằng người đánh giá được cung cấp bằng chứng đánh giá.

Nhà phát triển tạo ra TOE và chịu trách nhiệm cung cấp các bằng chứng được yêu cầu cho việc đánh giá (ví dụ như đào tạo, thông tin thiết kế), thay mặt cho nhà bảo trợ.

Người đánh giá thực hiện các nhiệm vụ đánh giá được yêu cầu trong bi cnh của một đánh giá: người đánh giá tiếp nhận bằng chứng đánh giá từ nhà phát triển thay mặt cho nhà bảo trợ hoặc trực tiếp từ nhà bảo trợ, thực hiện các hoạt động con đánh giá và cung cấp các kết quả ước định đánh giá cho tổ chức đánh giá.

Tổ chức đánh giá thiết lập và duy trì lược đồ, giám sát việc đánh giá được thực hiện bởi người đánh giá và tạo ra các báo cáo chứng nhận/công nhận cũng như các chứng chỉ dựa trên Kết quả đánh giá được cung cấp bởi người đánh giá.

7.2.3  Mối quan hệ của các vai trò

Để tránh ảnh hưởng quá mức từ tác động không đúng đến việc đánh giá, việc phân tách vai trò của các bên được yêu cầu. Điều này có nghĩa là các vai trò được mô tả ở trên được thực hiện bởi các thực thể khác nhau, ngoại trừ vai trò của nhà phát triển và nhà bảo trợ có thể được tha mãn bởi một thực thể đơn nhất.

Ngoài ra, một số đánh giá (ví dụ như đánh giá EAL1) có thể không yêu cầu các nhà phát triển tham gia vào dự án. Trong trường hợp này, nhà bảo trợ là người cung cấp TOE cho người đánh giá và là người tạo ra bằng chứng đánh giá.

7.2.4  Mô hình đánh giá chung

Quy trình đánh giá bao gồm người đánh giá thực hiện nhiệm vụ đầu vào đánh giá, nhiệm vụ đầu ra đánh giá và các hoạt động con đánh giá. Hình 2 cung cấp tổng quan về mối quan hệ giữa các nhiệm vụ này và các hoạt động con.

Quy trình đánh giá có thể được bắt đầu bằng giai đoạn chuẩn bị, tại đó cuộc gặp gỡ đầu tiên giữa nhà bảo trợ và người đánh giá được thiết lập. Công việc được thực hiện và sự tham gia của các vai trò khác nhau trong giai đoạn này có thể thay đổi. Đin hình trong bước này là người đánh giá thực hiện một phân tích tính khả thi nhằm ước định khả năng một đánh giá thành công.

Hình 2 - Mô hình đánh giá chung

7.2.5  Nhận đỊnh của người đánh giá

Người đánh giá chỉ định các nhận định cho các yêu cầu trong TCVN 8709 (ISO/IEC 15408) và không chỉ định cho các yêu cầu của tiêu chuẩn này. Cấu trúc của TCVN 8709 (ISO/IEC 15408) chi tiết nhất mà một nhận định được chỉ định là phần tử hành động của người đánh giá (tường minh hay ngầm định). Một nhận định được chỉ định cho một phần tử hành động của người đánh giá trong TCVN 8709 (ISO/IEC 15408) như là một kết quả thực hiện hành động theo phương pháp đánh giá tương ứng và các đơn vị công việc cấu thành của nó. Cuối cùng, một kết quả đánh giá được chỉ định như đã mô tả trong Điều 9 TCVN 8709-1 (ISO/IEC 15408-1), Kết quả đánh giá.

Tiêu chuẩn này công nhận ba trạng thái nhận định loại trừ lẫn nhau:

a) Các điều kiện cho một nhận định "đạt" được xác định là một việc hoàn thành của người đánh giá cho phần tử hành động của người đánh giá trong TCVN 8709 (ISO/IEC 15408) và quyết định rằng các yêu cầu đối với PP, ST hoặc TOE cần được đánh giá là đáp ứng. Các điều kiện đ các phần tử "đạt" được xác định là:

1) Các đơn vị công việc cấu thành của hành động phương pháp đánh giá có liên quan và;

2) Tất cả các bằng chứng đánh giá đã được yêu cầu để thực hiện các đơn vị công việc này là mạch lạc, có nghĩa là người đánh giá có thể hiu được đầy đủ và trọn vẹn về nó và

3) Tất cả các bằng chứng đánh giá đã được yêu cầu để thực hiện các đơn vị công việc này không có bất kỳ sự không nhất quán nội bộ rõ ràng nào hoặc sự không nhất quán với bằng chứng đánh giá khác. Lưu ý rằng ý nghĩa rõ ràng ở đây là người đánh giá phát hiện ra sự không nhất quán này trong khi thực hiện các đơn vị công việc: người đánh giá không nên thực hiện các phân tích sự không nhất quán đầy đủ trên toàn bộ bằng chứng đánh giá mỗi khi một đơn vị công việc được thực hiện.

b) Các điều kiện cho một nhận định "không đạt" được xác định là một việc hoàn thành của người đánh giá cho phần tử hành động của người đánh giá trong TCVN 8709 (ISO/IEC 15408) và quyết định rằng các yêu cầu đối với PP, ST hoặc TOE cần được đánh giá là không đáp ứng hoặc bằng chứng không mạch lạc hoặc một sự không nhất quán rõ ràng trong bằng chứng đánh giá được tìm ra;

c) Tất cả các nhận định đều được chỉ định ban đầu là "không kết luận" và giữ nguyên như vậy cho đến khi nhận định "đạt" hoặc "không đạt" được chỉ định.

Hình 3 - Ví dụ về quy tắc chỉ định nhiệm vụ

Nhận định tổng thể là "đạt" khi và ch khi tất cả các nhận định thành phần cùng là "đạt". Trong ví dụ minh họa ở Hình 3, nếu nhận định cho một phần tử hành động của người đánh giá là "không đạt" thì các nhận định cho thành phần đảm bảo, lớp đảm bảo và nhận định tổng thể tương ứng cũng là "không đạt".

7.3  Nhiệm vụ đầu vào đánh giá

7.3.1  Mục tiêu

Mục tiêu của nhiệm vụ này là đảm bảo rằng người đánh giá có sẵn phiên bản chính xác của các bằng chứng đánh giá được yêu cầu cho việc đánh giá và nó được bảo vệ thích đáng. Nếu không, độ chính xác kỹ thuật của việc đánh giá không được đảm bảo, việc đánh giá được tiến hành đ tạo ra các kết quả có thể lặp lại và có thể tái sản xuất cũng không được đảm bảo.

7.3.2  Lưu ý áp dụng

Trách nhiệm cung cấp tất cả các bằng chứng đánh giá được yêu cầu thuộc về nhà bảo trợ. Tuy nhiên, hầu hết các bằng chứng đánh giá có khả năng được tạo ra và cung cấp bởi nhà phát triển, thay mặt nhà bảo trợ.

Do các yêu cầu đảm bảo áp dụng cho toàn bộ TOE, tất cả bằng chứng đánh giá liên quan đến tất cả các phn của TOE cần được sn sàng cung cấp cho người đánh giá. Phạm vi áp dụng và nội dung được yêu cầu của bằng chứng đánh giá như vậy là độc lập với mức độ kiểm soát mà nhà phát triển đã có trên mỗi phn của TOE. Ví dụ, nếu thiết kế được yêu cầu, thì các yêu cầu thiết kế TOE (ADV_TDS) sẽ áp dụng cho tất cả các hệ thống con mà chúng là một phần của TSF. Ngoài ra, các yêu cầu đảm bảo có yêu cầu các thủ tục cần có (ví dụ, các năng lực CM (ALC_CMC) và chuyển giao (ALC_DEL)) cũng sẽ áp dụng cho toàn bộ TOE (bao gồm mọi phần được tạo ra bởi nhà phát triển khác).

Khuyến nghị người đánh giá, kết hợp với các nhà bảo trợ, đưa ra một ch mục với bằng chứng đánh giá được yêu cầu. Chỉ mục này có thể là một tập các tham chiếu tới tài liệu. Chỉ mục này nên có đ thông tin (ví dụ như một bn tóm tắt ngắn gọn của mỗi tài liệu hoặc ít nhất là một tiêu đề, du hiệu rõ ràng của các Điều cn quan tâm) đ giúp người đánh giá dễ dàng tìm thấy bằng chứng được yêu cầu. Thông tin trong bằng chứng đánh giá được yêu cầu chứ không phải cấu trúc tài liệu cụ thể nào. Bằng chứng đánh giá cho một hoạt động con có thể được cung cấp bởi các tài liệu riêng biệt hoặc một tài liệu đơn nhất có thể thỏa mãn một số các yêu cầu đầu vào của một hoạt động con.

Người đánh giá yêu cầu các phiên bản ổn định và được cung cấp chính thức của bằng chứng đánh giá. Tuy nhiên, dự thảo bằng chứng đánh giá có thể được cung cấp trong một phép đánh giá, ví dụ, để giúp một người đánh giá đưa ra một ước định không chính thức sớm, nhưng không được sử dụng làm cơ sở cho các nhận định. Có thể sẽ hữu ích nếu người đánh giá để xem các bản thảo của một bằng chứng đánh giá phù hợp cụ thể, chẳng hạn như:

a) Tài liệu kiểm thử, để cho phép người đánh giá thực hiện một ước định sớm về các kiểm thử và các thủ tục kiểm thử;

b) Các tài liệu thiết kế, để cung cấp cho người đánh giá nền tảng để thiết kế TOE;

c) Mã nguồn hoặc bản vẽ phần cứng, để cho phép người đánh giá ước định việc áp dụng các tiêu chuẩn của nhà phát triển.

Bằng chứng đánh giá sơ bộ thường được xử lý khi việc đánh giá một TOE được thực hiện đồng thời với việc phát triển nó. Tuy nhiên, chúng cũng có thể được xử lý trong quá trình đánh giá TOE đã phát triển nơi mà các nhà phát triển đã phải thực hiện công việc bổ sung để giải quyết vấn đề xác định bởi người đánh giá (ví dụ như để sửa một lỗi trong thiết kế hoặc triển khai) hoặc cung cấp bằng chứng đánh giá an toàn mà không được cung cấp trong tài liệu hiện có (ví dụ như trong trường hợp TOE không được phát triển để đáp ứng các yêu cầu của TCVN 8709 (ISO/IEC 15408)).

7.3.3  Quản lý nhiệm vụ con bng chứng đánh giá

7.3.3.1  Kiểm soát cấu hình

Người đánh giá cần thực hiện kiểm soát cấu hình của bằng chứng đánh giá.

TCVN 8709 (ISO/IEC 15408) ngầm định rằng người đánh giá có khả năng xác định và chỉ rõ từng khoản mục của bằng chứng đánh giá sau khi chúng đã được tiếp nhận và có khả năng xác định liệu họ có đang giữ một phiên bản cụ thể của một tài liệu không.

Người đánh giá cần bảo vệ bằng chứng đánh giá tránh việc thay đổi hoặc bị mất khi đang giữ chúng.

7.3.3.2  Hủy bỏ

Các lược đồ có thể mong muốn kiểm soát việc hủy bỏ bằng chứng đánh giá khi kết thúc một đánh giá. Việc hủy bỏ các bằng chứng đánh giá nên đạt được bằng một hoặc nhiều cách sau:

a) Tr lại bằng chứng đánh giá;

b) Lưu trữ bằng chứng đánh giá;

c) Phá hy bằng chứng đánh giá

7.3.3.3  Tính bí mật

Người đánh giá có thể truy nhập thông tin thương mại nhạy cảm của nhà bảo trợ và nhà phát triển (ví dụ như thông tin thiết kế TOE, các công cụ chuyên dụng) và có thể truy nhập thông tin quốc gia nhạy cảm trong quá trình đánh giá. Các lược đồ có thể mong muốn áp đặt các yêu cầu đ người đánh giá duy trì tính bảo mật của các bằng chứng đánh giá. Nhà bảo trợ và người đánh giá có thể cùng đồng ý với các yêu cầu bổ sung, miễn là nhất quán với lược đồ đó.

Các yêu cầu tính bí mật ảnh hưởng đến nhiều mặt của công việc đánh giá, bao gồm cả việc tiếp nhận, giải quyết, lưu trữ và hủy b bằng chứng đánh giá.

7.4  Hoạt động con đánh giá

Hoạt động con đánh giá thay đổi tùy thuộc đó là đánh giá PP hay TOE. Hơn nữa, trong trường hợp đánh giá TOE, hoạt động con phụ thuộc vào các yêu cầu đảm bảo đã được chọn.

7.5  Nhiệm vụ đầu ra đánh giá

7.5.1  Mục tiêu

Mục tiêu của Điều này là mô tả Báo cáo quan sát (OR) và Báo cáo kỹ thuật đánh giá (ETR). Các lược đồ có thể yêu cầu các báo cáo bổ sung của người đánh giá như báo cáo về các đơn vị công việc riêng hoặc có thể yêu cầu thông tin bổ sung cần có trong OR và ETR. Tiêu chuẩn này không ngăn cn việc bổ sung thông tin vào các báo cáo do tiêu chuẩn này chỉ quy định nội dung thông tin tối thiểu.

Việc báo cáo nhất quán về Kết quả đánh giá sẽ tạo điều kiện đạt được các nguyên tắc chung trong việc lặp lại và tái tạo các kết quả. Tính nhất quán bao gồm c v kiểu và số lượng thông tin đã báo cáo trong ETR và OR. Tính nhất quán của ETR và OR giữa các đánh giá khác nhau là trách nhiệm của tổ chức đánh giá.

Người đánh giá thực hiện hai nhiệm vụ con sau đây đ đạt được các yêu cầu của tiêu chuẩn này về nội dung thông tin của các báo cáo:

a) Nhiệm vụ con viết OR (nếu được yêu cầu trong bối cảnh của việc đánh giá);

b) Nhiệm vụ con viết ETR.

7.5.2  Quản lý đu ra đánh giá

Người đánh giá cung cấp ETR và cả các OR khi chúng sẵn sàng, cho tổ chức đánh giá. Các yêu cầu đối với các kiểm soát việc xử lý ETR và các OR được thiết lập bởi lược đồ trong đó có thể bao gồm c chuyển giao cho nhà bảo trợ hoặc nhà phát triển. ETR và các OR có thể bao gồm các thông tin nhạy cảm hoặc độc quyền và có thể cần phải được tinh chế lại trước khi chúng được trao cho nhà bảo trợ.

7.5.3  Lưu ý áp dụng

Trong phiên bản của tiêu chuẩn này, các yêu cầu về việc cung cấp bằng chứng đánh giá để hỗ trợ đánh giá lại và tái sử dụng chưa được quy định rõ ràng. Trường hợp nhà bảo trợ yêu cầu thông tin để đánh giá lại hoặc tái sử dụng, nên tư vấn cho nhà bảo trợ lược đồ đánh giá đang được thực hiện.

7.5.4  Nhiệm vụ con viết OR

Các OR cung cấp cho người đánh giá cơ chế để yêu cầu làm rõ (ví dụ từ tổ chức đánh giá đối với việc áp dụng một yêu cầu) hoặc xác định một vấn đề liên quan đến một khía cạnh của việc đánh giá.

Trong trường hợp nhận định không đạt, người đánh giá cần cung cấp OR để phản hồi kết quả đánh giá. Nếu không, người đánh giá có thể sử dụng các OR như một cách diễn tả các yêu cầu làm rõ.

Đối với mỗi OR, người đánh giá cần báo cáo như sau:

a) định danh của PP hay TOE được đánh giá;

b) nhiệm vụ/hoạt động con đánh giá trong đó việc quan sát được tạo ra;

c) sự quan sát;

d) ước định mức độ an toàn của nó (ví dụ ngầm định một nhận định không đạt, giữ tiến độ việc đánh giá, yêu cầu giải quyết trước khi hoàn thành đánh giá);

e) xác định tổ chức chịu trách nhiệm giải quyết vấn đề;

f) lịch biểu đề xuất để giải quyết;

g) ước định tác động đối với việc đánh giá không đạt đến quyết định việc quan sát.

Người sử dụng hướng đến của OR và các thủ tục xử lý báo cáo này sẽ phụ thuộc vào bản chất nội dung báo cáo và lược đồ. Các lược đồ có thể phân biệt các loại OR khác nhau hoặc xác định các loại bổ sung, cùng với những khác biệt liên quan trong thông tin yêu cầu và việc phân bố (ví dụ, các OR đánh giá tới các tổ chức đánh giá và các nhà bảo trợ).

7.5.5  Nhiệm vụ con viết ETR

7.5.5.1  Mục tiêu

Người đánh giá cần cung cấp ETR để thể hiện biện minh kỹ thuật của các nhận định.

Tiêu chuẩn này xác định yêu cầu nội dung ti thiểu của ETR; tuy nhiên, các lược đồ có thể chỉ rõ nội dung bổ sung và các yêu cầu về trình bày và cấu trúc riêng. Ví dụ, các lược đồ có thể yêu cầu tài liệu giới thiệu cụ thể (ví dụ các Điều từ chối yêu cầu và bản quyền) được báo cáo trong ETR.

Người đọc ETR được giả thiết đã làm quen với các khái niệm chung về an toàn công nghệ thông tin trong TCVN 8709 (ISO/IEC 15408) - các phương pháp đánh giá và công nghệ thông tin.

ETR hỗ trợ tổ chức đánh giá đ xác nhận rằng việc đánh giá đã được thực hiện theo tiêu chuẩn yêu cầu, song tổ chức đánh giá thấy trước rằng các kết quả đã ghi văn bản có thể không cung cấp tất cả thông tin được yêu cầu, do đó thông tin bổ sung theo yêu cầu của lược đ có thể được yêu cầu. Lĩnh vực này nằm ngoài phạm vi của tiêu chuẩn.

7.5.5.2  ETR cho đánh giá PP

Điều này mô tả nội dung tối thiểu của ETR cho một đánh giá PP. Các nội dung của ETR được miêu tả trong Hình 4; hình này có thể sử dụng như một hướng dẫn khi xây dựng đề cương kết cấu của tài liệu ETR.

Hình 4 - Nội dung thông tin ETR cho một đánh giá PP

7.5.5.2.1  Giới thiệu

Người đánh giá cần báo cáo các định danh lược đồ đánh giá.

Các định danh lược đồ đánh giá (ví dụ như logo) là thông tin được yêu cầu để xác định rõ lược đồ chịu trách nhiệm cho giám sát đánh giá.

Người đánh giá cần báo cáo các định danh kiểm soát cấu hình ETR.

Các định danh kiểm soát cấu hình ETR chứa thông tin định danh ETR (ví dụ như tên, ngày tháng và số hiệu phiên bản).

Người đánh giá cần báo cáo định danh kiểm soát cấu hình PP.

Định danh kiểm soát cấu hình PP (ví dụ như tên, ngày tháng và số hiệu phiên bản) được yêu cầu đ định danh những gì đang được đánh giá để tổ chức đánh giá xác định rằng nhận định đã được ch định chính xác bởi người đánh giá.

Người đánh giá cần báo cáo định danh của nhà phát triển.

Định danh của nhà phát triển PP được yêu cầu đ xác định các bên chịu trách nhiệm tạo ra PP.

Người đánh giá phải báo cáo định danh của nhà bảo trợ.

Định danh của nhà bảo trợ được yêu cầu để xác định các bên chịu trách nhiệm cung cấp bằng chứng đánh giá đến người đánh giá.

Người đánh giá cần báo cáo định danh của người đánh giá.

Định danh của người đánh giá được yêu cầu để xác định bên thực hiện việc đánh giá và chịu trách nhiệm về các nhận định đánh giá.

7.5.5.2.2  Đánh giá

Người đánh giá cần báo cáo phương pháp, kỹ thuật, công cụ và tiêu chuẩn đánh giá đã sử dụng.

Người đánh giá tham khảo tiêu chí đánh giá, phương pháp luận và các diễn giải dùng đ đánh giá PP.

Người đánh giá cần báo cáo mọi ràng buộc trong việc đánh giá, những ràng buộc về việc xử lý kết quả đánh giá và các giả định đã được đưa ra khi đánh giá có tác động đến Kết quả đánh giá.

Người đánh giá có thể đưa vào thông tin liên quan đến vấn đề pháp lý hoặc phương diện luật định, tổ chức, bảo mật, v.v.

7.5.5.2.3  Kết quả đánh giá

Người đánh giá cần báo cáo một nhận định và một sở cứ hỗ trợ đối với mỗi thành phần đảm bảo cấu thành nên một hoạt động của APE, như là kết quả của việc thực hiện hành động phương pháp luận đánh giá tương ứng và các đơn vị công việc cấu thành của nó.

Sở c biện minh cho nhận định sử dụng TCVN 8709 (ISO/IEC 15408) này là mọi cách diễn giải và bằng chứng đánh giá được thẩm tra và cho thấy cách bằng chứng đánh giá đáp ứng hoặc không đáp ứng mỗi khía cạnh của tiêu chí. Nó bao gồm việc mô tả về công việc được thực hiện, phương pháp được sử dụng và nguồn gốc bất kỳ của các kết quả. Sở cứ có thể cung cấp chi tiết đến cấp độ của đơn vị công việc phương pháp đánh giá.

7.5.5.2.4  Kết luận và khuyến nghị

Người đánh giá cần báo cáo kết luận đánh giá, đặc biệt là nhận định tổng thể theo quy định tại Điều 9 TCVN 8709-1 (ISO/IEC 15408-1), Kết quả đánh giá và được xác định bằng cách áp dụng việc chỉ định nhận định được mô tả trong 7.2.5.

Người đánh giá cung cấp các khuyến nghị có thể hữu ích cho tổ chức đánh giá. Những khuyến nghị này có thể đưa vào các bất cập của PP được phát hiện ra trong quá trình đánh giá hoặc đề cập đến các tính năng đặc biệt hữu ích.

7.5.5.2.5  Danh sách bằng chứng đánh giá

Người đánh giá cần báo cáo các thông tin sau cho từng khoản mục bằng chứng đánh giá:

• Tổ chức phát hành (ví dụ như nhà phát triển, nhà bảo trợ);

• Tiêu đề;

• Tham chiếu duy nhất (ví dụ như ngày phát hành và số hiệu phiên bản).

7.5.5.2.6  Danh sách các cụm từ viết tắt / giải thích các thuật ngữ

Người đánh giá cn báo cáo mi từ viết tắt hoặc tên viết tắt được sử dụng trong ETR.

Các định nghĩa thuật ngữ đã được định nghĩa tại TCVN 8709 (ISO/IEC 15408) hoặc tại tiêu chuẩn này không cần lặp lại trong ETR.

7.5.5.2.7  Báo cáo quan sát

Người đánh giá cần báo cáo danh sách đầy đủ xác định duy nhất các OR được tạo ra trong quá trình đánh giá và tình trạng của chúng.

Đối với mỗi OR, danh sách nên có định danh cũng như tiêu đề của nó hoặc bn tóm tắt ngắn gọn về nội dung của nó.

7.5.5.3  ETR cho một đánh giá TOE

Điều này mô tả nội dung tối thiểu của ETR cho một đánh giá TOE. Các nội dung của ETR được miêu tả trong Hình 5; hình này có thể sử dụng như một hướng dẫn khi xây dựng đề cương kết cấu của tài liệu ETR.

Hình 5 - Nội dung thông tin ETR cho một đánh giá TOE

7.5.5.3.1  Giới thiệu

Người đánh giá cần báo cáo các định danh lược đồ đánh giá.

Định danh lược đồ đánh giá (ví dụ như logo) là thông tin yêu cầu để xác định rõ lược đồ chịu trách nhiệm cho giám sát đánh giá.

Người đánh giá cần báo cáo các định danh kiểm soát cấu hình ETR.

Các xác định kiểm soát cấu hình ETR chứa thông tin xác định ETR (ví dụ như tên, ngày tháng  và số phiên bản).

Người đánh giá cần báo cáo xác định kiểm soát cấu hình ST và TOE.

Các xác định kiểm soát cấu hình ST và TOE xác định những gì đang được đánh giá để các tổ chức đánh giá xác minh rằng các nhận định đã được chỉ định chính xác bởi người đánh giá.

Nếu ST yêu cầu là TOE phù hợp với các yêu cầu của một hoặc nhiều PP, ETR cần báo cáo tham chiếu của các PP tương ứng.

Tham chiếu của các PP chứa thông tin xác định duy nhất các PP (ví dụ như tiêu đề, ngày tháng và số hiệu phiên bản).

Người đánh giá cần báo cáo xác định của nhà phát triển.

Xác định của các nhà phát triển TOE được yêu cầu để xác định các bên chịu trách nhiệm tạo ra TOE. Người đánh giá phải báo cáo xác định của nhà bảo trợ.

Xác định của nhà bảo trợ được yêu cầu đ xác định các bên chịu trách nhiệm cung cấp bằng chứng đánh giá đến người đánh giá.

Người đánh giá cần báo cáo xác định của người đánh giá.

Xác định của người đánh giá được yêu cầu để xác định bên thực hiện việc đánh giá và chịu trách nhiệm về các nhận định đánh giá.

7.5.5.3.2  Mô tả kiến trúc của TOE

Người đánh giá cần báo cáo sự mô tả cấp độ cao của TOE và các thành phần chính của nó dựa trên bằng chứng đánh giá đã mô tả trong họ đảm bảo của TCVN 8709 (ISO/IEC 15408) được gắn thiết kế TOE (ADV_TDS), khi áp dụng.

Mục đích của Điều này là mô tả mức độ phân chia kiến trúc của các thành phần chính. Nếu không có yêu cầu thiết kế TOE (ADV_TDS) trong ST, điều này không áp dụng và được coi là thỏa mãn.

7.5.5.3.3  Đánh giá

Người đánh giá cần báo cáo phương pháp, kỹ thuật, công cụ và tiêu chuẩn đánh giá đã sử dụng, Người đánh giá tham khảo tiêu chí đánh giá, phương pháp luận và các diễn giải dùng để đánh giá TOE

Người đánh giá cần báo cáo mọi hạn chế dựa trên việc đánh giá, những hạn chế về việc xử lý kết quả đánh giá và giả định được thực hiện trong việc đánh giá có tác động đến Kết quả đánh giá.

Người đánh giá có thể đưa vào thông tin liên quan đến vấn đề pháp lý hoặc phương diện luật định, tổ chức, bảo mật, v.v.

7.5.5.3.4  Kết quả đánh giá

Đối với mỗi hoạt động trong đó TOE được đánh giá, người đánh giá cần báo cáo:

• Tiêu đề của hoạt động đã được xem xét;

• Nhận định và sở cứ hỗ trợ cho mỗi thành phần đảm bảo cấu thành nên hoạt động này, như là kết quả của việc thực hiện hành động phương pháp đánh giá tương ứng và các đơn vị công việc cấu thành của nó.

Sở cứ biện minh cho nhận định sử dụng TCVN 8709 (ISO/IEC 15408) này là mọi cách diễn giải và bằng chứng đánh giá được thẩm tra và cho thy cách bằng chứng đánh giá đáp ứng hoặc không đáp ứng mỗi khía cạnh của tiêu chí. Nó bao gồm việc mô tả về công việc được thực hiện, phương pháp được sử dụng và ngun gốc bất kỳ của các kết quả. Sở cứ có thể cung cấp chi tiết đến cấp độ của đơn vị công việc phương pháp đánh giá.

Người đánh giá cần báo cáo tất cả các thông tin cụ thể do đơn vị công việc đã yêu cầu.

Đối với các hoạt động AVA và ATE, các đơn vị công việc để xác định thông tin được báo cáo trong ETR đã định nghĩa.

7.5.5.3.5  Kết luận và kiến nghị

Người đánh giá cần báo cáo các kết luận đánh giá sẽ liên quan đến việc liệu TOE có thỏa mãn ST liên quan của nó không, đặc biệt là nhận định tổng thể như đã quy định tại Điều 9 TCVN 8709-1 (ISO/IEC 15408-1), Kết quả đánh giá và được xác định bằng cách áp dụng việc chỉ định nhận định đã mô tả trong 7.2.5.

Người đánh giá cung cấp các khuyến nghị có thể hữu ích cho tổ chức đánh giá. Những khuyến nghị này có thể đưa vào các bất cập của PP đã phát hiện ra trong quá trình đánh giá hoặc đề cập đến các tính năng đặc biệt hữu ích.

7.5.5.3.6  Danh sách bằng chứng đánh giá

Người đánh giá cần báo cáo từng khoản mục bằng chứng đánh giá theo các thông tin sau đây:

• Tổ chức phát hành (ví dụ như nhà phát triển, nhà bảo trợ);

• Tiêu đề;

• Tham chiếu duy nhất (ví dụ như ngày phát hành và số phiên bản).

7.5.5.3.7  Danh sách các cụm từ viết tắt / Gii thích các thuật ngữ

Người đánh giá cần báo cáo mọi từ viết tắt hoặc tên viết tắt được sử dụng trong ETR.

Các định nghĩa thuật ngữ đã được định nghĩa tại TCVN 8709 (ISO/IEC 15408) hoặc tại tiêu chuẩn này không cần lặp lại trong ETR.

7.5.5.3.8  Báo cáo quan sát

Người đánh giá cần báo cáo danh sách đầy đủ xác định duy nhất của các OR tạo ra trong quá trình đánh giá và tình trạng của chúng.

Đối với mỗi OR, danh sách nên có xác định cũng như tiêu đề của nó hoặc bản tóm tắt ngắn gọn về nội dung của nó.

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

8.1  Giới thiệu

Điều này mô tả việc đánh giá PP. Các yêu cầu và phương pháp luận để đánh giá PP là giống nhau đối với mỗi đánh giá PP, không phụ thuộc vào EAL (hoặc tập các yêu cầu đảm bảo khác) được đòi hỏi trong PP. Phương pháp đánh giá trong Điều này dựa trên vào các yêu cầu về PP như đã quy định tại TCVN 8709-3 (ISO/IEC 15408-3) lớp APE.

Điều này nên được sử dụng kết hợp với các Phụ lục A, B và C trong TCVN 8709-1 (ISO/IEC 15408-1), vì các Phụ lục này làm rõ các khái niệm nêu ở đây và cung cấp nhiều ví dụ.

8.2  Lưu ý áp dụng

8.2.1  Tái sử dụng Kết quả đánh giá của các PP đã được chứng nhận

Trong khi việc đánh giá một PP dựa trên một hoặc nhiều PP đã được chứng nhận, có thể tái sử dụng các PP đã được chứng nhận. Khả năng tái sử dụng kết quả của một PP đã được chứng nhận lớn hơn nếu PP đang được đánh giá không có thêm các mối đe dọa, các OSP, các mục tiêu an toàn và/hoặc các yêu cầu an toàn so với PP mà sự tuân thủ đang được yêu cầu. Nếu PP đang được đánh giá chứa nhiều thứ hơn so với PP đã chứng nhận, việc tái sử dụng có thể thực sự không có tác dụng.

Người đánh giá được phép tái sử dụng Kết quả đánh giá PP khi thực hiện những phân tích nhất định theo từng phần hoặc không được phép nếu những phân tích hoặc các phần của chúng đã được thực hiện như một phần của việc đánh giá PP. Trong khi làm điều này, người đánh giá nên giả định rằng những phân tích trong PP được thực hiện đúng.

Ví dụ khi PP tuân thủ đang được yêu cầu có chứa một tập hợp các yêu cầu an toàn và chúng được xác định là nht quán nội bộ trong quá trình đánh giá nó. Nếu PP được đánh giá sử dụng các yêu cầu đúng như vậy, phân tích tính nhất quán không phải lặp lại trong quá trình đánh giá PP. Nếu PP được đánh giá có thêm một hoặc nhiều yêu cầu hoặc thực hiện các hoạt động trên các yêu cầu này, thì việc phân tích sẽ phải được lặp lại. Tuy nhiên, có thể giảm bớt công việc trong việc phân tích tính nhất quán này bng cách sử dụng thực tế là các yêu cầu ban đầu là nhất quán nội bộ. Nếu các yêu cầu ban đầu là nhất quán nội bộ, người đánh giá chỉ cần xác định rằng:

a) Tập hợp tất cả các yêu cầu mới và/hoặc thay đổi là nhất quán nội bộ và

b) Tập tất cả các yêu cầu mới và/hoặc thay đổi nhất quán với yêu cầu ban đầu.

Người đánh giá ghi lưu ý trong ETR về từng trường hợp khi việc phân tích chưa được thực hiện xong hoặc chỉ được thực hiện một phần vì lý do này.

8.3  Giới thiệu PP (APE_INT)

8.3.1  Đánh giá hoạt động con (APE_INT.1)

8.3.1.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu PP có được xác định đúng không và liệu phần tham chiếu PP và tổng quan TOE có nhất quán với nhau không.

8.3.1.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) PP.

8.3.1.3  Hành động APE_INT.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) APE_INT.1.1C: Giới thiệu PP cần chứa một tham chiếu PP và một tng quan TOE.

8.3.1.3.1  Đơn vị công việc APE_INT.1-1

Người đánh giá cần kiểm tra rằng giới thiệu PP chứa một tham chiếu PP và một tổng quan TOE.

TCVN 8709-3 (ISO/IEC 15408-3) APE_INT.1.2C: Tham chiếu PP cần xác định duy nhất cho PP.

8.3.1.3.2  Đơn vị công việc APE_INT.1-2

Người đánh giá cần thẩm tra tham chiếu PP đ xác định rằng nó xác định duy nhất cho PP.

Người đánh giá xác định rằng tham chiếu PP xác định cho chính PP, do đó nó có thể dễ dàng phân biệt với các PP khác và nó cũng xác định duy nhất cho mỗi phiên bản của PP, ví dụ: bằng cách đưa vào số phiên bản và/hoặc ngày công bố.

PP nên có một hệ thống tham chiếu nào đó để có thể hỗ trợ các tham chiếu duy nhất (ví dụ như sử dụng các s, các chữ cái hoặc ngày).

TCVN 8709-3 (ISO/IEC 15408-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.

8.3.1.3.3  Đơn vị công việc APE INT.1-3

Người đánh giá cần thẩm tra tổng quan TOE đ xác định rằng nó mô tả việc sử dụng và các đặc trưng an toàn chính của TOE.

Tổng quan TOE nên ngắn gọn (ví dụ như một vài đoạn) mô tả việc sử dụng và đặc trưng an toàn chính dự kiến của TOE. Tng quan TOE nên cho phép người tiêu dùng và các nhà phát triển TOE tiềm năng nhanh chóng xác định xem liệu PP có được họ quan tâm không.

Người đánh giá xác định rằng tổng quan là đ rõ ràng đối với các nhà phát triển TOE và người tiêu dùng và đủ để cung cấp cho họ sự hiểu biết chung về việc sử dụng và đặc trưng an toàn chính dự kiến của TOE.

TCVN 8709-3 (ISO/IEC 15408-3) APE_INT.1.4C: Tổng quan TOE cần xác định kiểu TOE.

8.3.1.3.4  Đơn vị công việc APE_INT.1-4

Người đánh giá cần kiểm tra rằng tổng quan TOE xác định kiểu TOE.

TCVN 8709-3 (ISO/IEC 15408-3) APE_INT.1.5C: Tổng quan TOE cần xác định bt kỳ phần cứng, phần mềm và phần sụn không phải TOE sẵn có cho TOE.

8.3.1.3.5  Đơn vị công việc APE_INT.1-5

Người đánh giá cần thẩm tra tổng quan TOE để xác định rằng nó xác định phần cứng/phần mềm/phần sụn không phải TOE sẵn sàng cho TOE đó.

Trong khi một số TOE có thể chạy độc lập thì một số TOE khác (đáng lưu ý là các TOE phần mềm) cần thêm phần cứng, phần mềm và phn sụn để hoạt động. Trong Điều này của PP, tác giả của PP liệt kê tất cả phần cứng, phần mềm và/hoặc phần sụn sẽ được dùng để chạy TOE.

Việc xác định này nên chi tiết đ để người tiêu dùng và các nhà phát triển TOE tiềm năng xác định xem liệu TOE của họ có thể hoạt động với các phần cứng, phần mềm và phần sụn đã được liệt kê không.

8.4  Yêu cầu tuân thủ (APE_CCL)

8.4.1  Đánh giá hoạt động con (APE_CCL.1)

8.4.1.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định tính hợp lệ của các yêu cầu tuân thủ khác nhau. Chúng mô tả PP phù hợp với TCVN 8709 (ISO/IEC 15408), các PP và các gói khác như thế nào.

8.4.1.2  Đu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) PP;

b) (các) PP mà PP yêu cầu tuân thủ theo;

c) (các) gói mà PP yêu cầu tuân thủ theo.

8.4.1.3  Hành động APE_CCL.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) APE_CCL.1.1C: Tuyên bố tuân thủ cần bao gồm tuyên bố tuân thủ TCVN 8709 (ISO/IEC 15408) để xác định phiên bản của TCVN 8709 (ISO/IEC 15408) mà PP tuân thủ tuyên bố.

8.4.1.3.1  Đơn vị công việc APE_CCL.1-1

Người đánh giá cần kiểm tra xem yêu cầu tuân thủ có chứa một yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) về việc xác định phiên bản của TCVN 8709 (ISO/IEC 15408) mà PP yêu cầu tuân thủ không.

Người đánh giá xác định rng yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) xác định phiên bản TCVN 8709 (ISO/IEC 15408) đã được sử dụng để phát triển PP này. Điều này nên bao gồm số phiên bản của TCVN 8709 (ISO/IEC 15408) và sử dụng ngôn ngữ của phiên bản TCVN 8709 (ISO/IEC 15408) trừ khi phiên bản tiếng Anh quốc tế của TCVN 8709 (ISO/IEC 15408) được sử dụng.

TCVN 8709-3 (ISO/IEC 15408-3) APE_CCL.1.2C: Yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) cần mô tả sự tuân thủ của PP theo TCVN 8709-2 (ISO/IEC 15408-2) như là hoặc tuân thủ TCVN 8709-2 (ISO/IEC 15408-2) hoặc mở rộng của TCVN 8709-2 (ISO/IEC 15408-2).

8.4.1.3.2  Đơn vị công việc APE_CCL.1-2

Người đánh giá cần kiểm tra rằng yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) đưa ra yêu cầu tuân th TCVN 8709-2 (ISO/IEC 15408-2) hoặc mở rộng TCVN 8709-2 (ISO/IEC 15408-2) đối với PP.

TCVN 8709-3 (ISO/IEC 15408-3) APE_CCL.1.3C: Yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) cần mô tả sự tuân thủ của PP theo TCVN 8709-3 (ISO/IEC 15408-3) như là tuân thủ TCVN 8709-3 (ISO/IEC 15408-3) hoặc mở rộng TCVN 8709-3 (ISO/IEC 15408-3).

8.4.1.3.3  Đơn vị công việc APE_CCL.1-3

Người đánh giá cần kiểm tra rằng yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) đưa ra yêu cầu tuân thủ TCVN 8709-3 (ISO/IEC 15408-3) hoặc mở rộng TCVN 8709-3 (ISO/IEC 15408-3) đối với PP.

TCVN 8709-3 (ISO/IEC 15408-3) APE_CCL.1.4C: Yêu cầu tuân th TCVN 8709 (ISO/IEC 15408) cần nhất quán với định nghĩa các thành phần mở rộng.

8.4.1.3.4  Đơn vị công việc APE_CCL.1-4

Người đánh giá cần thẩm tra yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) đối với TCVN 8709-2 (ISO/IEC 15408-2) để xác định rằng nó nhất quán với định nghĩa các thành phần mở rộng.

Nếu yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) có chứa tuân thủ TCVN 8709-2 (ISO/IEC 15408-2), người đánh giá xác định rằng định nghĩa các thành phần mở rộng không định nghĩa các thành phần chức năng.

Nếu yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) có chứa mở rộng TCVN 8709-2 (ISO/IEC 15408-2), người đánh giá xác định rằng định nghĩa các thành phần mở rộng định nghĩa ít nhất một thành phần chức năng mở rộng.

8.4.1.3.5  Đơn vị công việc APE_CCL.1-5

Người đánh giá cần thẩm tra yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) đối với TCVN 8709-2 (ISO/IEC 15408-2) để xác định rằng nó nhất quán với định nghĩa các thành phần mở rộng.

Nếu yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) có chứa tuân thủ TCVN 8709-3 (ISO/IEC 15408-3), người đánh giá xác định rằng định nghĩa các thành phần mở rộng không định nghĩa các thành phần chức năng.

Nếu yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) có chứa mở rộng TCVN 8709-3 (ISO/IEC 15408-3), người đánh giá xác định rằng định nghĩa các thành phần mở rộng định nghĩa ít nhất một thành phần chức năng mở rộng.

TCVN 8709-3 (ISO/IEC 15408-3) APE_CCL.1.5C: Yêu cầu tuân thủ cần xác định cả các PP và các gói yêu cầu an toàn mà PP yêu cầu tuân thủ theo.

8.4.1.3.6  Đơn vị công việc APE_CCL.1-6

Người đánh giá cần kiểm tra xem yêu cầu tuân th có chứa một yêu cầu PP xác định tt c các PP mà PP đó yêu cầu tuân thủ không.

Nếu PP không yêu cầu tuân thủ theo PP khác, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng bất kỳ PP tham chiếu nào cũng được xác định một cách rõ ràng (ví dụ như theo tiêu đề và s phiên bản hoặc bằng cách xác định có trong phần giới thiệu của PP đó).

Người đánh giá được nhắc nhở rằng không được phép có yêu cầu tuân thủ một phần đối với PP.

8.4.1.3.7  Đơn vị công việc APE_CCL.1-7

Người đánh giá cần kiểm tra xem yêu cầu tuân thủ có bao gồm một yêu cầu gói xác định tất cả các gói mà PP yêu cầu tuân thủ.

Nếu PP không yêu cầu tuân thủ theo gói, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng bất kỳ gói tham chiếu nào cũng được xác định một cách rõ ràng (ví dụ như theo tiêu đề và số phiên bản hoặc bằng cách xác định có trong phần giới thiệu của gói đó).

Người đánh giá được nhắc nh rằng không được phép có yêu cầu tuân thủ một phần đối với gói.

TCVN 8709-3 (ISO/IEC 15408-3) 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 hoặc gói tuân thủ hoặc gói gia tăng.

8.4.1.3.8  Đơn vị công việc APE_CCL.1-8

Người đánh giá cần kiểm tra xem với mỗi gói đã được xác định, yêu cầu tuân thủ đưa ra yêu cầu tuân thủ tên gói hoặc gia tăng tên gói.

Nếu PP không yêu cầu tuân thủ theo gói, đơn vị công việc này không áp dụng và do đó được coi là tha mãn.

Nếu yêu cầu tuân thủ gói cha tuân thủ tên gói, người đánh giá xác định rằng:

a) nếu gói là một gói đảm bảo, thì PP có chứa tất cả các SAR kèm theo gói, nhưng không thêm các SAR.

b) nếu gói là một gói chức năng, thì PP chứa tất cả các SFR kèm theo gói, nhưng không thêm các SFR.

Nếu yêu cầu tuân thủ gói cha gia tăng tên gói, người đánh giá xác định rằng:

a) nếu gói là một gói đảm bảo, thì PP có chứa tất cả các SAR kèm theo gói và thêm ít nhất một SAR hoặc ít nhất một SAR là phân cấp của một SAR trong gói.

b) nếu gói là một gói chức năng, thì PP chứa tất cả các SFR kèm theo gói và thêm ít nhất một SFR hoặc ít nhất một SFR là phân cấp của một SFR trong gói.

TCVN 8709-3 (ISO/IEC 15408-3) APE_CCL.1.7C: Sở cứ cho yêu cầu tuân thủ cần chứng minh rằng kiểu TOE này là nhất quán với kiu TOE trong các PP mà sự tuân thủ được yêu cầu.

8.4.1.3.9  Đơn vị công việc APE_CCL.1-9

Người đánh giá cần thẩm tra sở cứ yêu cầu tuân thủ để xác định rằng kiểu TOE của TOE là nhất quán với tất cả các kiểu TOE của các PP.

Nếu PP không yêu cầu tuân thủ theo PP khác, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Mối quan hệ giữa các kiểu có thể đơn giản là: yêu cầu tuân thủ PP tường lửa với PP tường lửa khác hoặc phức tạp hơn: một PP thẻ thông minh yêu cầu tuân thủ đối với một số PP khác cùng một thời điểm: một PP cho các mạch tích hợp, một PP cho hệ điều hành th thông minh và hai PP cho hai ứng dụng trên thẻ thông minh.

TCVN 8709-3 (ISO/IEC 15408-3) APE_CCL.1.8C: Sở cứ cho yêu cầu tuân thủ cần chứng minh rằng tuyên bố định nghĩa 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ủ được yêu cầu.

8.4.1.3.10  Đơn vị công việc APE_CCL.1-10

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

Nếu PP được đánh giá không yêu cầu tuân thủ theo PP khác, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Nếu PP mà sự tuân thủ được yêu cầu không tuyên bố định nghĩa vấn đề an toàn, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Nếu tuân thủ chặt chẽ được yêu cầu bởi PP mà sự tuân thủ được yêu cầu, không yêu cầu sở cứ yêu cầu tuân thủ. Thay vào đó, người đánh giá xác định rằng liệu:

a) các mối đe dọa trong PP có được đánh giá là một tập lớn của hoặc giống với các mối đe da trong PP mà sự tuân thủ được yêu cầu không;

b) các OSP trong PP có được đánh giá là một tập lớn của hoặc giống với các OSP trong PP mà sự tuân thủ được yêu cầu không;

c) các giả thiết trong PP có được đánh giá là giống với các giả thiết trong PP mà sự tuân thủ được yêu cầu không;

Nếu tuân thủ diễn giải được được yêu cầu bởi PP mà tuân thủ đang được yêu cầu, người đánh giá thẩm tra sở cứ yêu cầu tuân thủ để xác định nó chứng minh rằng tuyên bố định nghĩa vấn đề an toàn của PP được đánh giá là tương đương hoặc chặt chẽ hơn so với tuyên bố định nghĩa vấn đề an toàn trong PP mà sự tuân thủ được yêu cầu.

Hướng dn về "tương đương hoặc chặt chẽ hơn" xem Phụ lục D TCVN 8709-1 (ISO/IEC 15408-1), tuân thủ PP.

TCVN 8709-3 (ISO/IEC 15408-3) 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ề các mục tiêu an toàn trong các PP mà sự tuân thủ được yêu cầu.

8.4.1.3.11  Đơn vị công việc APE_CCL.1-11

Người đánh giá cần thẩm tra sở cứ tuyên bố tuân thủ để xác định rằng tuyên bố các mục tiêu an toàn là nhất quán, như đã được định nghĩa bởi tuyên bố tuân thủ của các PP, với tuyên bố mục tiêu an toàn trong các PP.

Nếu PP không yêu cầu tuân thủ theo PP khác, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Nếu tuân thủ chặt chẽ được yêu cầu bởi PP đã tuân thủ với tuyên bố, không nhất thiết phải có sở cứ tuyên bố tuân thủ. Thay vào đó, người đánh giá xác định liệu:

• PP được đánh giá chứa tất cả mục tiêu an toàn cho TOE của PP đã tuân thủ với tuyên bố. Lưu ý rằng nó cho phép PP được đánh giá bổ sung mục tiêu có an toàn cho TOE;

• PP được đánh giá chứa tất cả các mục tiêu an toàn chính xác đối với môi trường vận hành (với ngoại lệ được trình bày ở ý tiếp theo) không. Lưu ý rằng không cho phép PP được đánh giá bổ sung mục tiêu an toàn đối với môi trường vận hành;

• PP được đánh giá có thể xác định các mục tiêu nhất định đối với môi trường vận hành trong PP đã tuân thủ với tuyên bố là các mục tiêu an toàn cho TOE trong PP được đánh giá. Đây là trường hợp ngoại lệ được trình bày ở ý trước.

Nếu tuân thủ diễn giải được được yêu cầu bởi PP mà tuân thủ đang được yêu cầu, người đánh giá thẩm tra sở cứ tuyên bố tuân thủ để xác định rằng nó chứng minh tuyên bố các mục tiêu an toàn của PP được đánh giá là tương đương hoặc chặt chẽ hơn so với tuyên bố các mục tiêu an toàn trong PP đã tuân thủ với tuyên bố.

Hướng dẫn về "tương đương hoặc chặt chẽ hơn" xem Phụ lục D TCVN 8709-1 (ISO/IEC 15408-1), tuân thủ PP.

TCVN 8709-3 (ISO/IEC 15408-3) APE_CCL.1.10C: Sở cứ tuyên bố tuân thủ cần chứng minh rằng các yêu cầu tuyên bố an toàn là nhất quán với các yêu cầu tuyên bố về an toàn trong các PP đã tuân thủ với tuyên bố.

8.4.1.3.12  Đơn vị công việc APE_CCL.1-12

Người đánh giá cần thẩm tra PP để xác định rằng nó là nhất quán, như đã được xác định bởi tuyên bố tuân thủ của PP, với tất cả các yêu cầu an toàn trong các PP mà sự tuân thủ được yêu cầu.

Nếu PP không yêu cầu tuân thủ theo PP khác, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Nếu tuân thủ chặt chẽ được yêu cầu bởi PP mà sự tuân thủ được yêu cầu, không cần sở cứ yêu cầu tuân thủ. Thay vào đó, Người đánh giá xác định xem tuyên bố các yêu cầu an toàn trong PP được đánh giá có là một tập lớn hoặc giống với tuyên bố về các yêu cầu an toàn trong PP mà sự tuân thủ được yêu cầu không (đối với tuân thủ chặt chẽ).

Nếu tính tuân thủ diễn giải được được yêu cầu bởi PP mà sự tuân thủ được yêu cầu, người đánh giá thẩm tra sở cứ yêu cầu tuân thủ để xác định nó chứng minh rằng tuyên bố các yêu cầu an toàn của PP được đánh giá là tương đương hoặc chặt chẽ hơn so với tuyên bố các yêu cầu an toàn trong PP mà sự tuân thủ được yêu cầu.

Hướng dẫn về "tương đương hoặc chặt chẽ hơn" xem Phụ lục D TCVN 8709-1 (ISO/IEC 15408-1), tuân thủ PP.

TCVN 8709-3 (ISO/IEC 15408-3) APE_CCL.1.11C: Tuyên bố tuân thủ cần mô tả sự tuân thủ đã yêu cầu của bất kỳ các PP/ST trong PP như tuân thủ PP chặt chẽ hoặc PP diễn gii được.

8.4.1.3.13  Đơn vị công việc APE_CCL.1-13

Người đánh giá cần kiểm tra rằng tuyên bố tuân thủ PP đưa ra yêu cầu tuân thủ PP chặt chẽ hoặc PP diễn giải được.

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

8.5.1  Đánh giá hoạt động con (APE_SPD.1)

8.5.1.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định rằng vấn đề an toàn dự kiến được đề cập đến bởi TOE và môi trường vận hành của nó được xác định rõ ràng.

8.5.1.2  Đu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) PP.

8.5.1.3  Hành động APE_SPD.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) APE_SPD.1.1C: Định nghĩa vấn đề an toàn cần mô tả các mối đe dọa.

8.5.1.3.1  Đơn vị công việc APE_SPD.1-1

Người đánh giá cần kiểm tra rằng định nghĩa vấn đề an toàn mô tả các mối đe dọa.

Nếu tất cả các mục tiêu an toàn xuất phát từ các giả thiết và/hoặc chỉ các OSP, tuyên bố các mối đe dọa không cần có trong PP. Trong trường hợp này, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng định nghĩa vấn đề an toàn mô tả các mối đe dọa phải được chống lại bởi TOE và/hoặc môi trường vận hành của nó.

TCVN 8709-3 (ISO/IEC 15408-3) 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 đe dọa, tài sản và hành động có hại.

8.5.1.3.2  Đơn vị công việc APE_SPD.1-2

Người đánh giá cần thẩm tra định nghĩa vấn đề an toàn để xác định rằng tất cả các mối đe dọa được mô tả dưới dạng tác nhân đe dọa, tài sản và hành động có hại.

Nếu tất cả các mục tiêu an toàn chỉ xuất phát từ giả thiết và các OSP, tuyên bố các mối đe dọa không cần có trong PP. Trong trường hợp này, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Các tác nhân đe dọa có thể được mô tả bằng cách thêm các phương diện như chuyên môn, nguồn lực, cơ hội và động lực.

TCVN 8709-3 (ISO/IEC 15408-3) APE_SPD.1,3C: Định nghĩa vấn đề an toàn cần mô tả các OSP.

8.5.1.3.3  Đơn vị công việc APE_SPD.1-3

Người đánh giá cần kiểm tra rằng định nghĩa vấn đề an toàn mô tả các OSP.

Nếu tất cả các mục tiêu an toàn ch xuất phát từ giả thiết và/hoặc các mối đe dọa, các OSP không cần có trong PP. Trong trường hợp này, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng các tuyên bố OSP được thực hiện trong điều khoản quy tắc hoặc hướng dẫn phải theo TOE và/hoặc môi trường vận hành của nó.

Người đánh giá xác định rằng mỗi OSP được giải thích và/hoặc diễn dịch đầy đủ chi tiết để nó rõ ràng dễ hiểu; trình bày rõ ràng về các tuyên bố chính sách là được yêu cầu để cho phép theo dấu mc tiêu an toàn cho chúng.

TCVN 8709-3 (ISO/IEC 15408-3) APE_SPD.1.4C: Định nghĩa vấn đề an toàn cần mô tả các giả thiết về môi trường vận hành của TOE.

8.5.1.3.4  Đơn vị công việc APE_SPD.1-4

Người đánh giá cần thẩm tra định nghĩa vấn đề an toàn để xác định rng nó mô tả các giả thiết về môi trường vận hành của TOE.

Nếu không có các giả thiết, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng mỗi giả thiết về môi trường vận hành của TOE được diễn giải đầy đủ chi tiết, cho phép người sử dng xác định môi trường vận hành của chúng phù hợp với giả thiết. Nếu các giả thiết chưa được hiểu rõ, kết quả cuối cùng là TOE có thể được sử dụng trong môi trường vận hành theo cách không an toàn.

8.6  Mục tiêu an toàn (APE_OBJ)

8.6.1  Đánh giá hoạt động con (APE_OBJ.1)

8.6.1.1  Mục tiêu

Mục tiêu của hoạt động con này đ xác định liệu mục tiêu an toàn cho môi trường vận hành có được xác định rõ ràng không.

8.6.1.2  Đu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) PP.

8.6.1.3  Hành động APE_OBJ.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) 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.

8.6.1.3.1  Đơn vị công việc APE_OBJ.1-1

Người đánh giá cần kiểm tra rằng tuyên bố của các mục tiêu an toàn định nghĩa các mục tiêu an toàn cho môi trường vận hành.

Người đánh giá kiểm tra rằng các mục tiêu an toàn cho môi trường vận hành đã được xác định.

8.6.2  Đánh giá hoạt động con (APE_OBJ.2)

8.6.2.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu các mục tiêu an toàn có đề cập đến định nghĩa vấn đề an toàn một cách thỏa đáng và đầy đủ không và việc phân chia vấn đề này giữa TOE và môi trường vận hành của nó có được xác định rõ ràng không.

8.6.2.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) PP.

8.6.2.3  Hành động APE_OBJ.2.1E

TCVN 8709-3 (ISO/IEC 15408-3) APE_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 vận hành.

8.6.2.3.1  Đơn vị công việc APE_OBJ.2-1

Người đánh giá cần kiểm tra rằng tuyên bố các mục tiêu an toàn định nghĩa các mục tiêu an toàn cho TOE và các mục tiêu an toàn cho môi trường vận hành.

Người đánh giá kiểm tra rằng cả hai phạm trù mục tiêu an toàn đã được xác định rõ ràng và tách bạch với nhau.

TCVN 8709-3 (ISO/IEC 15408-3) APE_OBJ.2.2C: Sở cứ các mục tiêu an toàn cần theo dấu từng mục tiêu an toàn cho TOE chống lại các mối đe dọa bởi mục tiêu an toàn đó và các OSP được thực thi bởi mục tiêu an toàn.

8.6.2.3.2  Đơn vị công việc APE_OBJ.2-2

Người đánh giá cần kiểm tra rng sở cứ các mục tiêu an toàn theo du tất cả các mục tiêu an toàn cho TOE đến các mối đe dọa được chống lại bởi các mục tiêu và/hoặc các OSP được thực thi bởi mục tiêu an toàn.

Mỗi mục tiêu an toàn cho TOE có thể theo dấu đến các mối đe dọa hoặc các OSP hoặc sự kết hợp của các mối đe dọa và các OSP, nhưng nó phải theo dấu đến ít nhất một mối đe dọa hoặc một OSP.

Lỗi khi thực hiện theo dấu có nghĩa là sở cứ mục tiêu an toàn không đầy đủ, định nghĩa vấn đề an toàn không đầy đủ hoặc mục tiêu an toàn cho TOE không có mục đích hữu ích.

TCVN 8709-3 (ISO/IEC 15408-3) APE_OBJ.2.3C: Sở cứ các mục tiêu an toàn cn theo dấu từng mục tiêu an toàn cho môi trường vận hành chống lại các mối đe dọa bởi mục tiêu an toàn đó và các OSP được thực thi bởi mục tiêu an toàn và giả thiết duy trì mục tiêu an toàn.

8.6.2.3.3  Đơn vị công việc APE_OBJ.2-3

Người đánh giá cần kiểm tra rằng sở cứ các mục tiêu an toàn theo dấu các mục tiêu an toàn cho môi trường vận hành đến các mi đe dọa được chống lại bởi mục tiêu an toàn, đến các OSP được thực thi bởi mục tiêu an toàn và đến các giả thiết được duy trì bởi mục tiêu an toàn đó.

Mỗi mục tiêu an toàn cho môi trường vận hành có thể theo dấu các mối đe dọa, các OSP, các giả thiết hoặc sự kết hợp của các mối đe dọa, các OSP và/hoặc các giả thiết, nhưng nó phải theo dấu ít nhất một mối đe dọa, một OSP hoặc một giả thiết.

Lỗi khi thực hiện theo dấu có nghĩa là sở cứ mục tiêu an toàn không đầy đủ, định nghĩa vấn đề an toàn không đầy đủ hoặc mục tiêu an toàn cho môi trường vận hành không có mục đích hữu ích.

TCVN 8709-3 (ISO/IEC 15408-3) 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 mối đe dọa.

8.6.2.3.4  Đơn vị công việc APE_OBJ.2-4

Người đánh giá cần thẩm tra sở cứ các mục tiêu an toàn để xác định rằng nó biện minh cho mỗi mối đe dọa rằng các mục tiêu an toàn là phù hợp để chống lại mối đe dọa đó.

Nếu không có mục tiêu an toàn theo dấu mối đe dọa, thì hành động của người đánh giá liên quan đến đơn vị công việc này được chỉ định là một nhận định không đạt.

Người đánh giá xác định rằng việc biện minh cho một mối đe dọa cho thấy liệu mối đe dọa có được loại bỏ, gim bớt hoặc giảm nhẹ hay không.

Người đánh giá xác định rằng biện minh cho một mối đe dọa chứng minh rằng các mục tiêu an toàn là đầy đủ: nếu tt c các mục tiêu an toàn theo dấu mối đe dọa đã đạt được, thì mối đe dọa đã được loại bỏ, giảm nhẹ hoặc những ảnh hưởng của các mối đe dọa được giảm nhẹ.

Lưu ý rằng việc theo dấu từ các mục tiêu an toàn đến các mối đe dọa được cung cấp trong sở cứ mục tiêu an toàn có thể là một phần của một sự biện minh, nhưng không được coi là biện minh của chính nó. Ngay c trong trường hợp một mục tiêu an toàn chỉ là một tuyên bố phn ánh mục đích để ngăn chặn một mối đe dọa cụ thể đang được thực hiện, thì sự biện minh được yêu cầu, nhưng biện minh này có thể là tối thiểu như "mục tiêu an toàn X trực tiếp chống lại mối đe dọa Y".

Người đánh giá cũng xác định rằng mỗi mục tiêu an toàn theo dấu mối đe dọa là cần thiết: khi mục tiêu an toàn đã đạt được nó thực sự góp phần vào việc loại bỏ, gim bớt hoặc giảm thiu mối đe dọa đó.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

8.6.2.3.5  Đơn vị công việc APE_OBJ.2-5

Người đánh giá cần thẩm tra sở cứ các mục tiêu an toàn đ xác định rằng đối với mỗi OSP nó biện minh rằng các mục tiêu an toàn là phù hợp để thực thi OSP đó.

Nếu không có mục tiêu an toàn theo dấu OSP, hành động của người đánh giá liên quan đến đơn vị công việc này được chỉ định là nhận định không đạt.

Người đánh giá xác định rằng biện minh cho các diễn gii mối đe dọa tại các mục tiêu an toàn là đầy đủ: nếu tt cả các mục tiêu an toàn theo dấu OSP đạt được, OSP được thực thi.

Người đánh giá cũng xác định mỗi mục tiêu an toàn theo dấu quay lại OSP là được yêu cầu: khi mục tiêu an toàn đạt được nó thực sự góp phần vào việc thực thi của OSP.

Lưu ý rằng việc theo dấu từ các mục tiêu an toàn đến các mi đe dọa được cung cấp trong sở cứ mục tiêu an toàn có thể là một phần của một sự biện minh, nhưng không được coi là biện minh của chính nó. Ngay cả trong trường hợp đó, mục tiêu an toàn chỉ là một tuyên bố phản ánh mục đích để ngăn chặn một mối đe dọa cụ thể đang được thực hiện, một sự biện minh là được yêu cầu, nhưng biện minh này là tối thiểu "Mục tiêu an toàn X trực tiếp chống lại mối đe dọa Y".

TCVN 8709-3 (ISO/IEC 15408-3) 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 vận hành duy trì tất cả các giả thiết.

8.6.2.3.6  Đơn vị công việc APE_OBJ.2-6

Người đánh giá cần thẩm tra sở cứ các mục tiêu an toàn để xác định rằng đối với mỗi giả thiết cho môi trường vận hành nó có chứa một sự biện minh hợp lý mà các mục tiêu an toàn cho môi trường vận hành phù hợp để duy trì giả thiết đó.

Nếu không có các mục tiêu an toàn cho môi trường vận hành theo du giả thiết, hành động của người đánh giá liên quan đến đơn vị công việc này được chỉ định là nhận định không đạt.

Người đánh giá xác định rằng biện minh cho một giả thiết về môi trường vận hành của TOE diễn giải rằng các mục tiêu an toàn là đầy đủ: nếu tất cả các mục tiêu an toàn cho môi trường vận hành theo dấu giả thiết đạt được, môi trường vận hành duy trì giả thiết.

Người đánh giá cũng xác định mỗi mục tiêu an toàn cho môi trường vận hành theo dấu giả thiết về môi trường vận hành của TOE là được yêu cầu: khi mục tiêu an toàn đạt được nó thực sự góp phần vào việc duy trì môi trường vận hành giả thiết.

Lưu ý rằng việc theo dấu từ các mục tiêu an toàn cho môi trường vận hành đến các giả thiết đã cung cấp trong sở cứ các mục tiêu an toàn có thể là một phần của một sự biện minh, nhưng không được coi là biện minh của chính nó. Trong trường hợp đó, mục tiêu an toàn của môi trường vận hành chđơn thuần là trình bày lại một giả thiết, một sự biện minh sẽ được yêu cầu, nhưng biện minh này là tối thiểu "Mục tiêu an toàn X trực tiếp chống lại mối đe dọa Y".

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

8.7.1  Đánh giá hoạt động con (APE_ECD.1)

8.7.1.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu các thành phần mở rộng có được định nghĩa rõ ràng và mạch lạc không và chúng có cần thiết không, nghĩa là chúng có thể đã không được thể hiện rõ ràng khi sử dụng các thành phần TCVN 8709-2 (ISO/IEC 15408-2) hoặc TCVN 8709-3 (ISO/IEC 15408-3) đang tồn tại.

8.7.1.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) PP.

8.7.1.3  Hành động APE_ECD.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) 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.

8.7.1.3.1  Đơn vị công việc APE_ECD.1-1

Người đánh giá cần kiểm tra rằng tất cả các yêu cầu an toàn trong tuyên bố về các yêu cầu an toàn mà không được xác định là các yêu cầu mở rộng đều có trong TCVN 8709 (ISO/IEC 15408) -2 hoặc TCVN 8709-3 (ISO/IEC 15408-3).

TCVN 8709-3 (ISO/IEC 15408-3) APE_ECD.1.2C: Định nghĩa các thành phần mở rộng cn xác định thành phần mở rộng cho từng yêu cầu an toàn mở rộng.

8.7.1.3.2  Đơn vị công việc APE_ECD.1-2

Người đánh giá cần kiểm tra rằng định nghĩa các thành phần mở rộng xác định thành phần mở rộng cho từng yêu cầu an toàn mở rộng.

Nếu PP không chứa các yêu cầu an toàn mở rộng, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Thành phần mở rộng đơn nhất có thể được sử dụng để định nghĩa nhiều phép lặp của yêu cầu an toàn mở rộng, không nhất thiết phải nhắc lại định nghĩa này cho mỗi lần lặp.

TCVN 8709-3 (ISO/IEC 15408-3) APE_ECD.1.3C: Định nghĩa các thành phần mở rộng cần mô tả cách thức mỗi thành phần mở rộng quan hệ thế nào với các lớp, họ thành phần TCVN 8709 (ISO/IEC 15408) đang tồn tại.

8.7.1.3.3  Đơn vị công việc APE_ECD.1-3

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng để xác định rằng nó mô tả mỗi thành phần mở rộng phù hợp thế nào với các lớp, họ, thành phần TCVN 8709 (ISO/IEC 15408) đang tồn tại.

Nếu PP không có các yêu cầu an toàn mở rộng, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng mỗi thành phần mở rộng hoặc là:

a) thành phần của họ TCVN 8709-2 (ISO/IEC 15408-2) hoặc TCVN 8709-3 (ISO/IEC 15408-3) đang tồn tại hoặc là

b) thành phần của một họ mới được định nghĩa trong PP.

Nếu thành phần mở rộng là thành phần của họ TCVN 8709-2 (ISO/IEC 15408-2) hoặc TCVN 8709-3 (ISO/IEC 15408-3) đang tồn tại, người đánh giá xác định rằng định nghĩa các thành phần mở rộng mô t đầy đủ lý do tại sao các thành phần mở rộng nên là một thành phần của họ và nó liên quan với các thành phần khác của họ đó như thế nào.

Nếu các thành phần mở rộng là một thành phần của một họ mới được định nghĩa trong PP, người đánh giá xác nhận rằng các thành phần mở rộng là không phù hợp với họ đang tồn tại.

Nếu PP định nghĩa các họ mới, người đánh giá xác định rằng mỗi họ mới hoặc là:

a) thành phần của lớp trong TCVN 8709-2 (ISO/IEC 15408-2) hoặc TCVN 8709-3 (ISO/IEC 15408-3) đang tồn tại hoặc là

b) thành phần của một lớp mới được định nghĩa trong PP.

Nếu họ là thành phần của lớp trong TCVN 8709-2 (ISO/IEC 15408-2) hoặc TCVN 8709-3 (ISO/IEC 15408-3) đang tồn tại, người đánh giá xác định rằng định nghĩa các thành phần mở rộng mô tả đầy đủ tại sao nó nên là một thành phần của lớp đó và nó liên quan đến họ khác trong lớp đó như thế nào.

Nếu họ là thành phần của một lớp mới được định nghĩa trong PP, người đánh giá xác nhận rằng họ không thích hợp đối với lớp đang tồn tại.

8.7.1.3.4  Đơn vị công việc APE_ECD.1-4

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng để xác định rằng mỗi định nghĩa của một thành phần mở rộng xác định tất cả các phụ thuộc có thể áp dụng của thành phần đó.

Nếu PP không có các yêu cầu an toàn mở rộng, đơn vị công việc này không áp dụng và do đó được coi là tha mãn.

Người đánh giá xác nhận rằng các phụ thuộc không thể áp dụng đã được bỏ qua bởi tác giả PP.

TCVN 8709-3 (ISO/IEC 15408-3) 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 TCVN 8709 (ISO/IEC 15408) đang tồn tại và phương pháp luận như là mô hình cho trình bày.

8.7.1.3.4  Đơn vị công việc APE_ECD.1-5

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng để xác định rằng mỗi thành phần chức năng mở rộng sử dụng các thành phần TCVN 8709-2 (ISO/IEC 15408-2) đang tồn tại như là mô hình cho trình bày.

Nếu PP không có các SFR mở rộng, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng thành phần chức năng mở rộng là nhất quán với TCVN 8709-2 (ISO/IEC 15408-2): Điều 6.1.3, cấu trúc thành phần.

Nếu thành phần chức năng mở rộng sử dụng các hoạt động, người đánh giá xác định rằng thành phần chức năng mở rộng là nhất quán với Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động. Nếu thành phần chức năng mở rộng là phân cấp của thành phần chức năng đang tồn tại, người đánh giá xác định rằng thành phần chức năng mở rộng là nhất quán với TCVN 8709-2 (ISO/IEC 15408-2), Điều 6.2.1, Nhấn mạnh các thay đổi thành phần.

8.7.1.3.6  Đơn vị công việc APE_ECD.1-6

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng để xác định rằng mỗi định nghĩa của họ chức năng mới sử dụng các họ chức năng của TCVN 8709 (ISO/IEC 15408) đang tn tại như là mô hình cho trình bày.

Nếu PP không định nghĩa các họ chức năng mới, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng tất cả các họ chức năng mới được định nghĩa nhất quán với Điều 6.1.2 TCVN 8709-2 (ISO/IEC 15408-2), Cấu trúc họ.

8.7.1.3.7  Đơn vị công việc APE_ECD.1-7

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng để xác định rằng mỗi định nghĩa của lớp chức năng mới sử dụng các lớp chức năng TCVN 8709 (ISO/IEC 15408) đang tồn tại như là mô hình cho trình bày.

Nếu PP không định nghĩa các lớp chức năng mới, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng tất cả lớp chức năng mới được định nghĩa nhất quán với Điều 6.1.1 TCVN 8709-2 (ISO/IEC 15408-2), Cấu trúc lớp.

8.7.1.3.8  Đơn vị công việc APE_ECD.1-8

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng đ xác định rằng mỗi định nghĩa của thành phần đảm bảo mở rộng sử dụng các thành phần trong TCVN 8709-3 (ISO/IEC 15408-3) đang tồn tại như là mô hình cho trình bày.

Nếu PP không chứa các SAR mở rộng, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng định nghĩa thành phần đảm bảo mở rộng là nhất quán với Điều 6.1.3 TCVN 8709-3 (ISO/IEC 15408-3), Cấu trúc thành phần đảm bảo.

Nếu thành phần đảm bảo mở rộng sử dụng các hoạt động, người đánh giá xác định rằng các thành phần đảm bảo mở rộng là nhất quán với Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động. Nếu thành phần bảo đảm mở rộng là phân cấp của thành phần đảm bảo đang tồn tại, người đánh giá xác định rằng thành phần đảm bảo mở rộng là nhất quán với Điều 6.1.3 TCVN 8709-3 (ISO/IEC 15408-3), Cấu trúc thành phần đảm bảo.

8.7.1.3.9  Đơn vị công việc APE_ECD.1-9

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng đ xác định rằng, đối với mỗi thành phần đảm bảo mở rộng định nghĩa, phương pháp luận áp dụng đã được cung cấp.

Nếu PP không chứa các SAR mở rộng, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rng, cho mỗi phần tử hành động của người đánh giá của mỗi SAR mở rộng, được cung cấp một hoặc nhiều đơn vị công việc và thực hiện thành công tất cả các đơn vị công việc cho yếu tố hành động được đánh giá sẽ chứng minh rằng các phần tử đã đạt được.

8.7.1.3.10  Đơn vị công việc APE_ECD.1-10

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng để xác định rằng mỗi định nghĩa của họ đảm bảo sử dụng các họ đảm bảo trong TCVN 8709 (ISO/IEC 15408) đang tồn tại như là mô hình cho trình bày.

Nếu PP không định nghĩa các họ bảo đảm mới, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng tất cả các họ bảo đảm mới được định nghĩa nhất quán với Điều 6.1.2 TCVN 8709-3 (ISO/IEC 15408-3), Cấu trúc h đảm bảo.

8.7.1.3.11  Đơn vị công việc APE_ECD.1-11

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng để xác định rằng mỗi định nghĩa của một lớp đảm bảo mới sử dụng các lớp đảm bảo trong TCVN 8709 (ISO/IEC 15408) đang tồn tại như là mô hình cho trình bày.

Nếu PP không định nghĩa các lớp bảo đảm mới, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng tất cả các lớp đảm bảo mới được định nghĩa nhất quán với Điều 6.1.1 TCVN 8709-3 (ISO/IEC 15408-3), Cấu trúc lớp đảm bảo.

TCVN 8709-3 (ISO/IEC 15408-3) APE_ECD.1.5C: Các thành phần mở rộng cần bao gồm các phần tử mục tiêu và các phần tử đo lường sao cho sự tuân thủ hoặc không tuân thủ theo những phần tử này có thể được chứng minh.

8.7.1.3.12  Đơn vị công việc APE_ECD.1-12

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng để xác định rằng mỗi phần tử trong mỗi thành phần mở rộng là đo được và các yêu cầu đánh giá mục tiêu trạng thái như là tuân thủ hoặc không tuân thủ có thể được chứng minh.

Nếu PP không có các yêu cầu an toàn mở rộng, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng các phần tử của các thành phần chức năng mở rộng được thể hiện theo cách mà chúng có thể kiểm chứng và có thể theo dấu thông qua các đại diện TSF thích hợp.

Người đánh giá cũng xác định các phần tử của các thành phần đảm bảo mở rộng tránh tạo ra phán xét đánh giá chủ quan.

Người đánh giá được nhắc nh rằng khi đo lường và mục tiêu phù hợp với tất cả các tiêu chí đánh giá, phải thừa nhận rằng không tồn tại phương pháp chính thức đ chứng minh đặc tính đó. Do đó, các thành phần chức năng và đảm bảo của TCVN 8709 (ISO/IEC 15408) đang tồn tại sẽ được sử dụng như một mô hình để xác định thế nào là tuân thủ với yêu cầu này.

8.7.1.4  Hành động APE_ECD.1.2E

8.7.1.4.1  Đơn vị công việc APE_ECD.1-13

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng để xác định rằng mỗi thành phần mở rộng có thể đã không được thể hiện rõ ràng khi sử dụng các thành phần đang tồn tại.

Nếu PP không có yêu cầu an toàn mở rộng, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá nên xem xét các thành phần từ TCVN 8709-2 (ISO/IEC 15408-2) và TCVN 8709-3 (ISO/IEC 15408-3), các thành phần mở rộng khác đã được định nghĩa trong PP, sự kết hợp của các thành phần này và các hoạt động có thể trên các thành phần này trong khi đưa ra quyết định này.

Người đánh giá được nhắc nhở rằng vai trò của đơn vị công việc này là để loại trừ sự trùng lặp không được yêu cầu của các thành phần, có nghĩa là, các thành phần có thể được thể hiện rõ ràng bằng cách sử dụng các thành phần khác. Người đánh giá không nên thực hiện việc tìm kiếm đầy đủ tất cả các kết hợp có thể bao gồm các hoạt động trong nỗ lực để tìm một cách thể hiện các thành phần mở rộng bằng cách sử dụng các thành phần đang tồn tại.

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

8.8.1  Đánh giá hoạt động con (APE_REQ.1)

8.8.1.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu các SFR và SAR có rõ ràng, mạch lạc và được định nghĩa rõ ràng không và liệu chúng có nhất quán nội bộ không.

8.8.1.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) PP.

8.8.1.3  Hành động APE_REQ.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) 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.

8.8.1.3.1  Đơn vị công việc APE_REQ.1-1

Người đánh giá cần kiểm tra rằng tuyên bố các yêu cầu an toàn mô tả các SFR.

Người đánh giá xác định rằng mỗi SFR được xác định bởi một trong những cách sau đây:

a) bằng cách tham chiếu đến thành phần riêng lẻ trong TCVN 8709-2 (ISO/IEC 15408-2);

b) bằng cách tham chiếu đến thành phần mở rộng trong định nghĩa các thành phần mở rộng của PP;

c) bằng cách tham chiếu đến một PP mà các yêu cầu PP tuân thủ;

d) bằng cách tham chiếu đến gói các yêu cầu an toàn mà các yêu cầu PP tuân thủ;

e) bằng việc tái sản xuất trong PP.

Không yêu cầu sử dụng cùng một phương tiện nhận dạng cho tất cả các SFR.

8.8.1.3.2  Đơn vị công việc APE_REQ.1-2

Người đánh giá cần kiểm tra rằng tuyên bố các yêu cầu an toàn mô tả các SAR.

Người đánh giá xác định rằng mỗi SFR được xác định bởi một trong những cách sau đây:

a) bằng cách tham chiếu đến thành phần riêng lẻ trong TCVN 8709-3 (ISO/IEC 15408-3);

b) bằng cách tham chiếu đến thành phần mở rộng trong định nghĩa các thành phần mở rộng của PP;

c) bằng cách tham chiếu đến một PP mà các yêu cầu PP tuân thủ;

d) bằng cách tham chiếu đến gói các yêu cầu an toàn mà các yêu cầu PP tuân thủ;

e) bằng việc tái sản xuất trong PP.

Không yêu cầu sử dụng cùng một phương tiện nhận dạng cho tất cả các SAR.

TCVN 8709-3 (ISO/IEC 15408-3) 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 thuật ngữ khác được sử dụng trong các SFR và SAR, cần được xác định.

8.8.1.3.3  Đơn vị công việc APE_REQ.1-3

Người đánh giá cần thẩm tra PP để xác định rằng 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 thuật ngữ khác được sử dụng trong các SFR và SAR được xác định.

Người đánh giá xác định rằng PP xác định tất cả:

• (các kiểu của) các đối tượng và mục tiêu được sử dụng trong các SFR;

• (các kiểu của) thuộc tính an toàn của các đối tượng, người sử dụng, mục tiêu, thông tin, phiên bản và/hoặc tài nguyên, các giá trị mà thuộc tính này có thể cần và bất kỳ các sở cứ giữa các giá trị này (ví dụ như top_secret là "cao hơn" secret);

• (các kiểu của) các hoạt động được sử dụng trong các SFR, bao gồm cả những ảnh hưởng của các hoạt động này;

• (các kiểu của) các thực thể bên ngoài trong SFR;

• các thuật ngữ khác được giới thiệu trong các SFR và/hoặc SAR bằng cách hoàn thành các thao tác, nếu các thuật ngữ này không rõ ràng ngay hoặc được sử dụng bên ngoài định nghĩa từ điển của chúng.

Mục tiêu của đơn vị công việc này là để đảm bảo rằng các SFR và SAR dễ phân biệt và không gây hiểu lầm có thể xảy ra do việc giới thiệu các thuật ngữ không rõ ràng. Đơn vị công việc này không nên đưa vào giới hạn, bằng cách buộc người viết PP xác định tất cả các từ đơn nhất. Các khán giả chung của tập hợp các yêu cầu an toàn nên được giả thiết có kiến thức hợp lý về công nghệ thông tin, an toàn và "Tiêu chí đánh giá về an toàn công nghệ thông tin".

Tất cả các vấn đề trên có thể được trình bày trong các nhóm, các lớp, các vai trò, các kiểu hoặc nhóm khác hoặc đặc trưng khác để cho dễ hiểu.

Người đánh giá được nhắc nhở rằng các danh sách và định nghĩa không phải là một phn của tuyên bố về các yêu cầu an toàn, nhưng có thể được đặt (một phần hoặc toàn bộ) tại các mục khác nhau. Điều này có thể áp dụng đặc biệt nếu các thuật ngữ tương tự được sử dụng trong phần còn tại của PP.

TCVN 8709-3 (ISO/IEC 15408-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 hoạt động trên các yêu cầu an toàn.

8.8.1.3.4  Đơn vị công việc APE_REQ.1-4

Người đánh giá cần kiểm tra tuyên bố các yêu cầu an toàn để xác định tất cả các hoạt động trên các yêu cầu an toàn.

Người đánh giá xác định rằng tất cả các quá trình hoạt động được xác định trong mỗi SFR hoặc SAR nơi quá trình hoạt động được sử dụng. Điều này bao gồm cả các quá trình hoạt động đã hoàn thành và còn dở dang. Nhận dạng có thể thực hiện được bằng cách phân biệt các bản in hoặc bằng cách xác định tường minh trong các văn bản xung quanh hoặc bằng bất kỳ phương tiện đặc trưng khác.

TCVN 8709-3 (ISO/IEC 15408-3) APE_REQ.1.4C: Tất cả các hoạt động cần phải thực hiện đúng.

8.8.1.3.5  Đơn vị công việc APE_REQ.1-5

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng tất cả các hoạt động chỉ định đã thực hiện đúng.

Hướng dẫn thực hiện đúng các hoạt động có thể tìm thy trong Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

8.8.1.3.6  Đơn vị công việc APE_REQ.1-6

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng tất cả các hoạt động lặp lại đã được thực hiện đúng.

Hướng dẫn thực hiện đúng các hoạt động có thể tìm thấy trong Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

8.8.1.3.7  Đơn vị công việc APE_REQ.1-7

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng tất cả các hoạt động lựa chọn đã được thực hiện đúng.

Hướng dẫn thực hiện đúng các hoạt động có thể được tìm thấy trong Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

8.8.1.3.8  Đơn vị công việc APE_REQ.1-8

Người đánh giá cn thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng tất cả các hoạt động bổ sung chi tiết đã được thực hiện đúng.

Hướng dn thực hiện đúng các hoạt động có thể được tìm thấy trong Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

TCVN 8709-3 (ISO/IEC 15408-3) APE_REQ.1.5C: Mỗi sự phụ thuộc của các yêu cầu an toàn cần hoặc được thỏa mãn hoặc sở cứ các yêu cầu an toàn cn biện minh sự phụ thuộc còn chưa được thỏa mãn.

8.8.1.3.9  Đơn vị công việc APE_REQ.1-9

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng mỗi sự phụ thuộc của các yêu cầu an toàn cần hoặc được thỏa mãn hoặc sở cứ các yêu cầu an toàn cần biện minh sự phụ thuộc còn chưa được thỏa mãn.

Sự phụ thuộc được thỏa mãn bao gồm các thành phần có liên quan (hoặc một trong số đó là phân cấp của nó) trong tuyên bố các yêu cầu an toàn. Thành phần được sử dụng đ đáp ứng sự phụ thuộc nên, nếu được yêu cầu, được sa đổi bởi các hoạt động để đảm bảo rằng nó thỏa mãn đúng sự phụ thuộc đó.

Biện minh về việc một sự phụ thuộc không được đáp ứng cần đề cập:

a) lý do tại sao sự phụ thuộc là không được yêu cầu hoặc hữu ích, trường hợp nào không yêu cầu thêm thông tin; hoặc

b) sự phụ thuộc đã được đề cập bởi môi trường vận hành của TOE, trường hợp nào biện minh nên mô tả cách thức mà các mục tiêu an toàn cho môi trường vận hành đề cập sự phụ thuộc này.

TCVN 8709-3 (ISO/IEC 15408-3) APE_REQ.1.6C: Tuyên bố về các yêu cầu an toàn cần có tính nhất quán nội bộ.

8.8.1.3.10  Đơn vị công việc APE_REQ.1-10

Người đánh giá cần thẩm tra tuyên bố các yêu cầu an toàn để xác định rằng nó có tính nhất quán nội b.

Người đánh giá xác định rằng các thiết lập liên hợp của tất cả các SFR và SAR có tính nhất quán nội bộ.

Người đánh giá xác định rằng trong tt cả các cơ hội mà tại đó các yêu cầu an toàn khác nhau áp dụng cho cùng một loại bằng chứng của nhà phát triển, các sự kiện, các hoạt động, dữ liệu, kiểm thử được thực hiện v.v.. hoặc "tất cả các đối tượng", "tất cả các mục tiêu" v.v..., mà các yêu cầu này không mâu thuẫn.

Một số mâu thuẫn có thể là:

a) một SAR mở rộng xác định rằng thiết kế của thuật toán mã hóa cụ thể phải được giữ bí mật và SAR mở rộng khác xác định việc thẩm tra mã nguồn m;

b) FAU_GEN.1 Tạo ra thế hệ dữ liệu kiểm toán xác định rằng danh tính đối tượng để đăng nhập, FDP_ACC.1 Tập con kiểm soát truy cập xác định những người có quyền truy nhập vào các hồ sơ và FPR_UNO.1 Tính không thể quan sát xác định rằng một số hành động của các đối tượng nên có thể không quan sát được các đối tượng khác. Nếu đối tượng đó không thể quan sát một hoạt động có thể truy nhập các hồ sơ của các hoạt động này, các SFR này mâu thuẫn;

c) FDP_RIP.1 Bảo vệ thông tin còn dư thừa của tập con xác định cụ thể việc xóa các thông tin không còn được yêu cầu và FDP_ROL.1 Khôi phục cơ bản xác định rằng một TOE có thể trở lại trạng thái trước đó. Nếu thông tin đó là được yêu cầu cho việc khôi phục trạng thái trước đó đã bị xóa, các yêu cầu này mâu thuẫn;

d) nhiều phép lặp của FDP_ACC.1 Kiểm soát truy nhập của tập con đặc biệt khi số phép lặp bao gồm cùng các đối tượng, mục tiêu hoặc hoạt động. Nếu một SFR kiểm soát truy cập cho phép đối tượng thực hiện hoạt động trên mục tiêu, trong khi một SFR khác kiểm soát truy nhập không cho phép, các yêu cầu này mâu thuẫn.

8.8.2  Đánh giá hoạt động con (APE_REQ.2)

8.8.2.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu các SFR và SAR có rõ ràng, mạch lạc và được xác định rõ ràng không, liệu chúng có nhất quán nội bộ không và liệu các SFR có đáp ứng các mục tiêu an toàn của TOE không.

8.8.2.2  Đu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) PP.

8.8.2.3  Hành động APE_REQ.2.1E

TCVN 8709-3 (ISO/IEC 15408-3) APE_REQ.2.1C: Tuyên bố các yêu cầu an toàn cần mô tả các SFR và SAR.

8.8.2.3.1  Đơn vị công việc APE_REQ.2-1

Người đánh giá cần kiểm tra rằng tuyên bố các yêu cầu an toàn mô tả các SFR.

Người đánh giá xác định rằng mỗi SFR được xác định bởi một trong những cách sau đây:

a) bằng cách tham chiếu đến thành phần riêng l trong TCVN 8709-2 (ISO/IEC 15408-2);

b) bằng cách tham chiếu đến thành phần mở rộng trong định nghĩa các thành phần mở rộng của PP;

c) bằng cách tham chiếu đến thành phần riêng lẻ trong PP mà các yêu cầu PP tuân thủ;

d) bằng cách tham chiếu đến thành phần riêng lẻ trong gói các yêu cầu an toàn mà các yêu cầu PP tuân thủ;

e) bằng việc tái sản xuất trong PP.

Không yêu cầu sử dụng cùng một phương tiện nhận dạng cho tất cả các SFR.

8.8.2.3.2  Đơn vị công việc APE_REQ.2-2

Người đánh giá cần kiểm tra rằng tuyên bố các yêu cầu an toàn mô tả các SAR.

Người đánh giá xác định rằng mỗi SFR được xác định bởi một trong những cách sau đây:

a) bằng cách tham chiếu đến thành phần riêng lẻ trong TCVN 8709-3 (ISO/IEC 15408-3);

b) bằng cách tham chiếu đến thành phần mở rộng trong định nghĩa các thành phần mở rộng của PP;

c) bằng cách tham chiếu đến thành phần riêng lẻ trong PP mà các yêu cầu PP tuân thủ;

d) bằng cách tham chiếu đến thành phần riêng lẻ trong gói các yêu cầu an toàn mà các yêu cầu PP tuân thủ;

e) bằng việc tái sản xuất trong PP.

Không yêu cầu sử dụng cùng một phương tiện nhận dạng cho tất cả các SAR.

TCVN 8709-3 (ISO/IEC 15408-3) APE_REQ.2.2C: Tt 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 thuật ngữ khác được sử dụng trong các SFR và SAR cần được định nghĩa.

8.8.2.3.3  Đơn vị công việc APE_REQ.2-3

Người đánh giá cần thẩm tra PP để xác định rằng 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 thuật ngữ khác được sử dụng trong các SFR và SAR được định nghĩa.

Người đánh giá xác định rằng PP định nghĩa tất cả:

• (các kiểu của) các đối tượng và mục tiêu được sử dụng trong các SFR;

• (các kiểu của) thuộc tính an toàn của các đối tượng, người sử dụng, mục tiêu, thông tin, phiên bản và/hoặc tài nguyên, các giá trị mà thuộc tính này có thể cần và bất k các sở cứ giữa các giá trị này (ví dụ như top_secret là "cao hơn" secret);

• (các kiểu của) các hoạt động được sử dụng trong các SFR, bao gồm c những ảnh hưởng của các hoạt động này;

• (các kiu của) các thực thể bên ngoài trong SFR;

• các thuật ngữ khác được giới thiệu trong SFR và/hoặc SAR bằng cách hoàn thành các thao tác, nếu các thuật ngữ này không rõ ràng hoặc được sử dụng bên ngoài định nghĩa từ điển của chúng.

Mục tiêu của đơn vị công việc này là để đảm bảo rằng các SFR và SAR dễ phân biệt và không gây hiểu lầm có thể xảy ra do việc giới thiệu các thuật ngữ không rõ ràng. Đơn vị công việc này không nên đưa vào giới hạn, bằng cách buộc người viết PP xác định tất cả các từ đơn nhất. Các khán giả chung của tập hợp các yêu cầu an toàn nên được giả thiết có kiến thức hợp lý về công nghệ thông tin, an toàn và "Tiêu chí đánh giá an toàn công nghệ thông tin".

Tất cả các vấn đề trên có thể được trình bày trong các nhóm, các lớp, các vai trò, kiểu hoặc nhóm khác hoặc đặc trưng khác để cho dễ hiểu.

Người đánh giá được nhắc nhở rằng các danh sách và định nghĩa không phải là một phần của tuyên bố về các yêu cầu an toàn, nhưng có thể được đặt (một phần hoặc toàn bộ) tại các mục khác nhau. Điều này có thể áp dụng đặc biệt nếu các thuật ngữ tương tự được sử dụng trong phần còn lại của PP.

TCVN 8709-3 (ISO/IEC 15408-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 hoạt động trên các yêu cầu an toàn.

8.8.2.3.4  Đơn vị công việc APE_REQ.2-4

Người đánh giá cần kiểm tra tuyên bố các yêu cầu an toàn để xác định tất cả các hoạt động trên các yêu cầu an toàn.

Người đánh giá xác định rằng tất cả các quá trình hoạt động được xác định trong mỗi SFR hoặc SAR nơi quá trình hoạt động được sử dụng. Điều này bao gồm cả các quá trình hoạt động đã hoàn thành và còn dở dang. Nhận dạng có thể thực hiện được bằng cách phân biệt các bản in hoặc bằng cách xác định tường minh trong các văn bản xung quanh hoặc bằng bất kỳ phương tiện đặc trưng khác.

TCVN 8709-3 (ISO/IEC 15408-3) APE_REQ.2.4C: Tất cả các hoạt động cần phải được thực hiện đúng.

8.8.2.3.5  Đơn vị công việc APE_REQ.2-5

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn đ xác định rằng tất cả các hoạt động chỉ định đã thực hiện đúng.

Hướng dẫn thực hiện đúng các hoạt động có thể tìm thấy trong Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

8.8.2.3.6  Đơn v công việc APE_REQ.2-6

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng tất cả các hoạt động lặp lại đã được thực hiện đúng.

Hướng dẫn thực hiện đúng các hoạt động có thể tìm thấy trong Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

8.8.2.3.7  Đơn vị công việc APE_REQ.2-7

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng tất cả các hoạt động lặp đã được thực hiện đúng.

Hướng dẫn thực hiện đúng các hoạt động có thể được tìm thấy trong Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

8.8.2.3.8  Đơn vị công việc APE_REQ.2-8

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn đ xác định rằng tất cả các hoạt động bổ sung chi tiết đã được thực hiện đúng.

Hướng dẫn thực hiện đúng các hoạt động có thể được tìm thy trong Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

TCVN 8709-3 (ISO/IEC 15408-3) APE_REQ.2.5C: Mỗi sự phụ thuộc của các yêu cầu an toàn cần hoặc là thỏa mãn hoặc sở cứ các yêu cầu an toàn cần biện minh sự phụ thuộc còn chưa được thỏa mãn.

8.8.2.3.9  Đơn vị công việc APE_REQ.2-9

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng mỗi phụ thuộc của các yêu cầu an toàn cần là thỏa mãn hoặc sở cứ các yêu cầu an toàn cần biện minh sự phụ thuộc còn chưa được thỏa mãn.

Sự phụ thuộc được thỏa mãn bao gồm các thành phần có liên quan (hoặc một trong số đó là phân cấp của nó) trong tuyên bố các yêu cầu an toàn. Thành phần được sử dụng để đáp ứng sự phụ thuộc nên, nếu được yêu cầu, được sửa đổi bởi các hoạt động để đảm bảo rằng nó thỏa mãn đúng sự phụ thuộc đó.

Biện minh sự phụ thuộc không được đáp ứng nên đề cập:

a) lý do tại sao sự phụ thuộc không được yêu cầu hoặc hữu ích, trường hợp nào thông tin không được yêu cầu thêm; hoặc

b) sự phụ thuộc đã được đề cập bởi các môi trường vận hành của TOE, trong trường hợp nào biện minh nên mô tả các mục tiêu an toàn để môi trường vận hành đề cập sự phụ thuộc này.

TCVN 8709-3 (ISO/IEC 15408-3) APE_REQ.2.6C: Sở cứ các yêu cầu an toàn cần theo dấu mỗi SFR theo các mục tiêu an toàn cho TOE.

8.8.2.3.10  Đơn vị công việc APE_REQ.2-10

Người đánh giá cần kiểm tra rằng sở cứ các yêu cầu an toàn theo dấu mỗi SFR đến các mục tiêu an toàn cho TOE.

Người đánh giá xác định rằng mỗi SFR được theo dấu ít nhất một mục tiêu an toàn cho TOE.

Lỗi khi thực hiện theo dấu có nghĩa là sở cứ các yêu cầu an toàn không đầy đủ, các mục tiêu an toàn cho TOE không đầy đủ hoặc SFR không có mục đích hữu ích.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

8.8.2.3.11  Đơn vị công việc APE_REQ.2-11

Người đánh giá cần thẩm tra sở cứ các yêu cầu an toàn để xác định rằng mỗi mục tiêu an toàn cho TOE nó biện minh rằng các SFR phù hợp đ đáp ứng mục tiêu an toàn cho TOE.

Nếu các SFR không theo du mục tiêu an toàn cho TOE, hành động của người đánh giá liên quan đến đơn vị công việc này được chỉ định là nhận định không đạt.

Người đánh giá xác định rằng biện minh mục tiêu an toàn cho TOE chứng minh rằng các SFR là đầy đủ: nếu tất cả các SFR theo dấu mục tiêu được thỏa mãn thì sẽ đạt được mục tiêu an toàn cho TOE. Nếu các SFR theo du mục tiêu an toàn cho TOE có bất kỳ chỉ định chưa hoàn thành hoặc các lựa chọn chưa hoàn thành hoặc dở dang, người đánh giá xác định rằng đối với mỗi hoàn thành có thể hiểu được hoặc sự kết hợp các hoàn tất các hoạt động này, các mục tiêu an toàn vẫn được đáp ứng.

Người đánh giá cũng xác định rằng mỗi SFR theo dấu một mục tiêu an toàn cho TOE là được yêu cầu: khi SFR được thỏa mãn, nó thực sự góp phần vào việc đạt được các mục tiêu an toàn.

Lưu ý rằng theo dấu từ các SFR tại các mục tiêu an toàn cho TOE được cung cấp trong sở cứ các yêu cầu an toàn có thể là một phần của một sự biện minh, nhưng không được coi là biện minh của chính nó.

TCVN 8709-3 (ISO/IEC 15408-3) APE_REQ.2.8C: Sở cứ các yêu cầu an toàn cn giải thích vì sao các SAP đã được chọn.

8.8.2.3.12  Đơn vị công việc APE_REQ.2-12

Người đánh giá cần kiểm tra rằng sở cứ các yêu cầu an toàn giải thích tại sao các SAR được lựa chọn.

Người đánh giá được nhắc nhở rằng mọi lời giải thích là chính xác, miễn là nó mạch lạc và c các SAR và phần giải thích đều không có sự không nhất quán hin nhiên với phần còn lại của PP.

Ví dụ sự không nhất quán hiển nhiên giữa các SAR và phần còn lại của PP sẽ là các tác nhân đe dọa rất có năng lực, nhưng AVA_VAN SAR không bảo vệ chống lại các tác nhân đe dọa này.

TCVN 8709-3 (ISO/IEC 15408-3) 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ộ.

8.8.2.3.13  Đơn vị công việc APE_REQ.2-13

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định nó là nhất quán nội bộ. Người đánh giá xác định rằng các thiết lập liên hợp của tất cả các SFR và SAR là nhất quán nội bộ. Người đánh giá xác định rằng trong tất cả các cơ hội mà tại đó các yêu cầu an toàn khác nhau áp dụng cho cùng một loại bằng chứng của nhà phát triển, các sự kiện, các hoạt động, dữ liệu, kiểm thử cần được thực hiện v.v.. hoặc "tất cả các đối tượng", "tất cả các mục tiêu" v.v..., mà các yêu cầu này không mâu thuẫn.

Một số mâu thuẫn có thể là:

a) một SAR mở rộng xác định rằng thiết kế của thuật toán mã hóa cụ thể phải được giữ bí mật và SAR mở rộng khác xác định một việc soát xét mã nguồn m;

b) FAU_GEN.1 Tạo ra thế hệ dữ liệu kiểm toán xác định rằng xác định đối tượng cần được đăng nhập, FDP_ACC.1 Tập con kiểm soát truy nhập xác định những người có quyền truy nhập vào các hồ sơ và FPR_UNO.1 Tính không thể quan sát xác định rằng một số hành động của các đối tượng nên có thể không quan sát được các đối tượng khác. Nếu đối tượng đó không thể quan sát một hoạt động có thể truy nhập các hồ sơ của các hoạt động này, các SFR này mâu thuẫn;

c) FDP_RIP.1 Bảo vệ thông tin còn dư thừa của tập con xác định cụ thể việc xóa các thông tin không còn được yêu cầu và FDP_ROL.1 Khôi phục cơ bản xác định rằng một TOE có thể trở lại trạng thái trước đó. Nếu thông tin đó là được yêu cầu cho việc khôi phục trạng thái trước đó đã bị xóa, các yêu cầu này mâu thuẫn;

d) nhiều phép lặp của FDP_ACC.1 Kiểm soát truy nhập của tập con đặc biệt khi số phép lặp bao gồm cùng các đối tượng, mục tiêu hoặc hoạt động. Nếu một SFR kiểm soát truy nhập cho phép đối tượng thực hiện hoạt động trên mục tiêu, trong khi một SFR khác kiểm soát truy nhập không cho phép, các yêu cầu này mâu thuẫn.

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

9.1  Giới thiệu

Điều này mô tả việc đánh giá một ST. Việc đánh giá ST nên được bắt đầu trước khi có bất kỳ hoạt động con đánh giá TOE do ST cung cấp cơ sở và bối cảnh đ thực hiện các hoạt động con này. Phương pháp luận đánh giá trong Điều này căn cứ vào các yêu cầu dựa trên ST theo quy định tại TCVN 8709-3 (ISO/IEC 15408-3) lớp ASE.

Điều này nên sử dụng kết hợp với các Phụ lục A, B và C trong TCVN 8709-1 (ISO/IEC 15408-1), vì các Phụ lục này làm rõ các khái niệm nêu ở đây và cung cấp nhiều ví dụ.

9.2  Lưu ý áp dụng

9.2.1  Tái sử dụng kết quả đánh giá của các PP đã được chứng nhận

Trong khi việc đánh giá một ST dựa trên một hoặc nhiều PP đã được chứng nhận, có thể tái sử dụng một thực tế rằng các PP này đã được chứng nhận. Khả năng tái sử dụng kết quả của một PP đã được chứng nhận lớn hơn nếu ST không đưa thêm các mối đe dọa, các OSP, các mục tiêu an toàn và/hoặc các yêu cầu an toàn vào những PP đó. Nếu ST đó chứa nhiều hơn PP đã được chứng nhận thì tái sử dụng có thể thực sự không có tác dụng.

Người đánh giá được phép tái sử dụng Kết quả đánh giá PP bằng cách thực hiện phân tích ch một phần hoặc không được phép nếu những phân tích hoặc các phần của chúng đã được thực hiện như một phần của việc đánh giá PP. Trong khi làm điều này, người đánh giá nên giả định rằng những phân tích trong PP được thực hiện đúng.

Ví dụ khi PP tuân thủ đang được yêu cầu có chứa một tập hợp các yêu cầu an toàn và chúng được xác định là nhất quán nội bộ trong quá trình đánh giá nó. Nếu PP được đánh giá sử dụng các yêu cầu đúng như vậy, phân tích tính nhất quán không phải lặp lại trong quá trình đánh giá PP. Nếu PP được đánh giá thêm một hoặc nhiều yêu cầu hoặc thực hiện các hoạt động trên các yêu cầu này, việc phân tích sẽ phải được lặp lại. Tuy nhiên, có thể tiết kiệm việc phân tích tính nhất quán này bằng cách sử dụng thực tế các yêu cầu ban đầu là nhất quán nội bộ. Nếu các yêu cầu ban đầu là nhất quán nội bộ, người đánh giá ch cn xác định rằng:

a) tập hợp tất cả các yêu cầu mới và/hoặc thay đổi là nhất quán nội bộ và

b) tập tất cả các yêu cầu mới và/hoặc thay đổi nhất quán với yêu cầu ban đầu.

Người đánh giá lưu ý trong ETR các trường hợp khi việc phân tích không được thực hiện hoặc chỉ được thực hiện một phần vì lý do này.

9.3  Giới thiệu ST (ASE_INT)

9.3.1  Đánh giá hoạt động con (ASE_INT.1)

9.3.1.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu ST và TOE có được nhận dạng đúng không, liệu TOE có được mô tả đúng trong cách tường thuật ở ba cấp độ trừu tượng (tham chiếu TOE, tổng quan TOE và mô tả TOE) không và liệu ba mô tả này có nhất quán với nhau không.

9.3.1.2  Đu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) ST.

9.3.1.3  Hành động ASE_INT.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) 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.

9.3.1.3.1  Đơn vị công việc ASE_INT.1-1

Người đánh giá cần kiểm tra rằng gii thiệu ST có chứa tham chiếu ST, tham chiếu TOE, tổng quan TOE và mô tả TOE.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_INT.1.2C: Tham chiếu ST cần xác định duy nhất cho ST.

9.3.1.3.2  Đơn vị công việc ASE_INT.1-2

Người đánh giá cần kiểm tra tham chiếu ST để xác định rng nó xác định duy nhất cho ST.

Người đánh giá xác định rằng tham chiếu ST xác định chính bản thân ST, do đó nó có thể dễ dàng phân biệt với các ST khác và nó cũng xác định duy nhất trong mỗi phiên bản của ST, ví dụ: bằng cách đưa vào số phiên bản và/hoặc ngày công bố.

Trong các đánh giá nơi mà một hệ thống CM được cung cấp, người đánh giá có thể xác nhận tính duy nhất của các tài liệu tham khảo bằng cách kiểm tra danh sách cấu hình. Trong trường hợp khác, ST nên có một số hệ thống tham khảo có khả năng hỗ trợ tham chiếu duy nhất (ví dụ như sử dụng các số, chữ cái hoặc ngày).

TCVN 8709-3 (ISO/IEC 15408-3) ASE_INT.1.3C: Tham chiếu TOE cần xác định TOE.

9.3.1.3.3  Đơn vị công việc ASE_INT.1-3

Người đánh giá cần thm tra tham chiếu TOE để xác định rằng nó xác định TOE.

Người đánh giá xác định rằng tham chiếu TOE xác định TOE, do đó, TOE rõ ràng tham chiếu đến ST và nó cũng xác định các phiên bản của TOE, ví dụ: bằng cách đưa vào số phiên bản/phát hành/thiết kế hoặc ngày phát hành.

9.3.1.3.4  Đơn vị công việc ASE_INT.1-4

Người đánh giá cần thẩm tra tham chiếu TOE để xác định rằng nó không sai lệch.

Nếu TOE có liên quan đến một hoặc nhiều sản phẩm nổi tiếng, nó được cho phép phản ánh điều này trong các tham chiếu TOE. Tuy nhiên, điều này không nên sử dụng để đánh lừa người tiêu dùng: trạng thái này chỉ là một phần nh của một Giao phm đánh giá, nhưng tham chiếu TOE không được phép không phản ánh điều này.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_INT.1.4C: 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.3.1.3.5  Đơn vị công việc ASE_INT.1-5

Người đánh giá cần thẩm tra tổng quan TOE để xác định rằng nó mô tả việc sử dụng và các đặc trưng an toàn chính của TOE.

Tổng quan TOE nên ngắn gọn (ví dụ một vài đoạn) mô tả việc sử dụng và các đặc trưng an toàn chính của TOE. Tổng quan TOE nên cho phép người tiêu dùng tiềm năng nhanh chóng xác định liệu TOE có phù hợp cho các nhu cầu an toàn của họ không.

Tổng quan TOE trong ST cho một TOE tổng hợp nên mô tả việc sử dụng và đặc trưng an toàn chính của TOE tổng hợp chứ không phải là các TOE thành phần riêng lẻ.

Người đánh giá xác định rằng tổng quan đ rõ ràng cho người tiêu dùng và đủ để cung cấp cho họ một sự hiểu biết chung về dự định sử dụng và các đặc trưng an toàn chính của TOE.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_INT.1.5C: Tổng quan TOE cần xác định kiểu TOE.

9.3.1.3.6  Đơn vị công việc ASE_INT.1-6

Người đánh giá cần kiểm tra tổng quan TOE xác định kiểu TOE.

9.3.1.3.7  Đơn vị công việc ASE_INT.1-7

Người đánh giá cần thẩm tra tổng quan TOE để xác định rằng kiểu TOE không sai lệch.

Có những tình huống mà người tiêu dùng nói chung sẽ kỳ vọng một số chức năng của TOE vì kiểu TOE của nó. Nếu chức năng này không có trong TOE, người đánh giá xác định rằng tổng quan TOE đã thảo luận thỏa đáng về việc không có chức năng này.

Cũng có các TOE mà người tiêu dùng nói chung kỳ vọng rằng TOE có thể nên hoạt động trong môi trường vận hành nhất định vì kiểu TOE của nó. Nếu TOE không thể hoạt động trong môi trường vận hành như vậy, người đánh giá xác định rằng tổng quan TOE này đã tho luận đầy đủ.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

9.3.1.3.8  Đơn vị công việc ASE_INT.1-8

Ngưi đánh giá cần thẩm tra tổng quan TOE đ xác định rằng nó xác định bất kỳ phần cứng/phần mềm/phần sụn không phải TOE được yêu cầu bi TOE.

Trong khi một số TOE có thể chạy độc lập, một số TOE khác (đặc biệt là các TOE phần mềm) cn thêm phần cứng, phần mềm và phn sụn để hoạt động. Nếu TOE không yêu cầu bất kỳ phần cứng, phần mềm và phần sụn nào, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn. Người đánh giá xác định rằng tổng quan TOE xác định bất kỳ phn cứng, phần mềm và phần sụn được yêu cầu cho TOE đ hoạt động. Sự xác định này không phải là đầy đủ, nhưng chi tiết này đủ cho người tiêu dùng tiềm năng của TOE xác định liệu phần cứng, phần mềm và phần sụn đang tồn tại của họ có hỗ trợ sử dụng của TOE không và nếu không phải là trường hợp này, có cn phải thêm phần cứng, phần mềm và phần sụn không.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_INT.1.7C: Mô tả TOE cần mô tả phạm vi vật lý của TOE.

9.3.1.3.9  Đơn vị công việc ASE_INT.1-9

Người đánh giá cần thẩm tra mô tả TOE để xác định rằng nó mô tả phạm vi vật lý của TOE.

Người đánh giá xác định rằng các mô tả TOE liệt kê các phần cứng, phần mềm, phần sụn và hướng dẫn các thành phần cấu thành TOE và mô tả chúng ở một mức độ chi tiết đủ để cung cấp cho người đọc một sự hiểu biết chung về những thành phần này.

Người đánh giá cũng xác định rằng không thể hiểu sai về việc liệu một phần cứng, phần mềm, phần sụn hoặc hướng dẫn nào đó có là một phần của TOE không.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_INT.1.8C: Mô tả TOE cn mô tả phạm vi logic của TOE.

9.3.1.3.10  Đơn vị công việc ASE_INT.1-10

Người đánh giá cn thẩm tra mô tả TOE để xác định rằng nó mô tả phạm vi logic của TOE.

Người đánh giá xác định rằng các mô tả TOE thảo luận về các tính năng an toàn logic được cung cấp bởi TOE ở mức độ chi tiết đó đ để cung cấp cho người đọc sự hiểu biết chung về các tính năng này. Người đánh giá cũng xác định rằng không thể hiểu sai về việc liệu một tính năng an toàn logic nào đó có được cung cấp bởi TOE hay không.

Một ST cho một TOE tổng hợp có thể đưa ra mô tả về phạm vi logic của các TOE thành phần, được cung cấp trong các ST của TOE thành phần để cung cấp phần lớn mô tả này cho TOE tổng hợp. Tuy nhiên, người đánh giá xác định rằng ST của TOE tổng hợp thảo luận rõ ràng các tính năng của các thành phần riêng lẻ không nằm trong TOE tổng hợp và do đó không phải là một tính năng của TOE tổng hợp.

9.3.1.4  Hành động ASE_INT.1.2E

9.3.1.4.1  Đơn vị công việc ASE_INT.1-11

Người đánh giá cần thẩm tra tham chiếu TOE, tổng quan TOE và mô tả TOE để xác định rằng chúng nhất quán với nhau.

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

9.4.1  Đánh giá hoạt động con (ASE_CCL.1)

9.4.1.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định tính hợp lệ của các yêu cầu tuân thủ khác nhau. Các yêu cầu này mô tả cách thức ST và TOE tuân thủ với TCVN 8709 (ISO/IEC 15408) và cách thức ST tuân thủ với PP và các gói.

9.4.1.2  Đu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) (các) PP mà ST yêu cầu tuân thủ;

c) (các) gói mà ST yêu cầu tuân thủ.

9.4.1.3  Hành động ASE_CCL.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) ASE_CCL.1.1C: Yêu cầu tuân thủ cần cha yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) để xác định phiên bản của TCVN 8709 (ISO/IEC 15408) mà yêu cầu tuân thủ TOE và ST.

9.4.1.3.1  Đơn vị công việc ASE_CCL.1-1

Người đánh giá cần kiểm tra xem yêu cầu tuân thủ có chứa yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) đ xác định phiên bản của TCVN 8709 (ISO/IEC 15408) mà yêu cầu tuân thủ TOE và ST. Người đánh giá xác định rằng yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) để xác định phiên bn TCVN 8709 (ISO/IEC 15408) đã được sử dụng để phát triển ST này. Điều này nên bao gồm số phiên bản của TCVN 8709 (ISO/IEC 15408) và sử dụng ngôn ngữ của phiên bản TCVN 8709 (ISO/IEC 15408) trừ khi phiên bản tiếng Anh quốc tế của TCVN 8709 (ISO/IEC 15408) được sử dụng.

Đối với TOE tổng hợp, người đánh giá sẽ xem xét bất kỳ sự khác biệt giữa phiên bản của TCVN 8709 (ISO/IEC 15408) đã yêu cầu đối với TOE thành phần và phiên bản của TCVN 8709 (ISO/IEC 15408) yêu cầu đối với TOE tổng hợp. Nếu các phiên bản khác nhau người đánh giá sẽ đánh giá liệu sự khác biệt giữa các phiên bản có dẫn đến các mâu thuẫn yêu cầu không.

Đối với trường hợp khi các yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) cho TOE cơ sở và TOE phụ thuộc là các bn phát hành chính thức khác nhau của TCVN 8709 (ISO/IEC 15408) (ví dụ như một yêu cầu tuân thủ TOE thành phần là TCVN 8709 (ISO/IEC 15408) v2.x và yêu cầu tuân thủ TOE thành phần khác là TCVN 8709 (ISO/IEC 15408) v3.x), yêu cầu tuân thủ cho TOE tổng hợp sẽ là phiên bn trước đó của TCVN 8709 (ISO/IEC 15408), TCVN 8709 (ISO/IEC 15408) được phát triển vi mục tiêu cung cấp tính tương thích ngược (mặc dù điều này có thể không đạt được ý nghĩa chặt chẽ, nó được hiu phải đạt được về nguyên tắc).

TCVN 8709-3 (ISO/IEC 15408-3) ASE_CCL.1.2C: Yêu cu tuân th TCVN 8709 (ISO/IEC 15408) cn mô t tuân thủ của ST theo TCVN 8709-2 (ISO/IEC 15408-2) như là hoặc tuân thủ TCVN 8709-2 (ISO/IEC 15408-2) hoặc mở rộng của TCVN 8709-2 (ISO/IEC 15408-2).

9.4.1.3.2  Đơn vị công việc ASE_CCL.1-2

Người đánh giá cần kiểm tra xem các trạng thái yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) yêu cầu hoặc tuân thủ TCVN 8709-2 (ISO/IEC 15408-2) hoặc mở rộng của TCVN 8709-3 (ISO/IEC 15408-3) đối với ST.

Đối với một TOE tổng hợp, người đánh giá sẽ xem xét liệu yêu cầu này có nhất quán không ch với TCVN 8709-2 (ISO/IEC 15408-2) mà còn với những yêu cầu tuân thủ TCVN 8709-2 (ISO/IEC 15408-2) của các TOE thành phần không. Nghĩa là: nếu một hoặc nhiều yêu cầu các TOE thành phần là phần mở rộng của TCVN 8709-2 (ISO/IEC 15408-2), thì TOE tổng hợp cũng nên yêu cầu phần mở rộng của TCVN 8709-2 (ISO/IEC 15408-2).

Yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) cho TOE tổng hợp có thể theo phần mở rộng của TCVN 8709-2 (ISO/IEC 15408-2), dù các TOE thành phần là tuân thủ Phần 2, trong trường hợp các SFR bổ sung được yêu cầu cho TOE cơ sở (xem hướng dẫn TOE tổng hợp cho ASE CCL.1.6C).

TCVN 8709-3 (ISO/IEC 15408-3) ASE CCL.1.3C: Yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) cần mô tả sự tuân thủ của ST theo TCVN 8709-3 (ISO/IEC 15408-3) như là hoặc tuân thủ TCVN 8709-3 (ISO/IEC 15408-3) hoặc mở rộng của TCVN 8709-3 (ISO/IEC 15408-3).

9.4.1.3.3  Đơn vị công việc ASE_CCL.1-3

Người đánh giá cần kiểm tra xem các trạng thái yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) yêu cầu hoặc tuân thủ TCVN 8709-3 (ISO/IEC 15408-3) hoặc mở rộng TCVN 8709-3 (ISO/IEC 15408-3) đối với ST.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_CCL.1.4C: Yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) cần nhất quán với định nghĩa các thành phần mở rộng.

9.4.1.3.4  Đơn vị công việc ASE_CCL.1-4

Người đánh giá cần thẩm tra yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) đối với TCVN 8709-2 (ISO/IEC 15408-2) để xác định rằng nó nhất quán với định nghĩa các thành phần mở rộng.

Nếu yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) có chứa tuân thủ TCVN 8709-2 (ISO/IEC 15408-2), người đánh giá xác định rằng định nghĩa các thành phần mở rộng mà không định nghĩa các thành phần chức năng.

Nếu yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) có chứa mở rộng của TCVN 8709-2 (ISO/IEC 15408-2), người đánh giá xác định rằng định nghĩa các thành phần mở rộng định nghĩa ít nhất một thành phần chức năng mở rộng.

9.4.1.3.5  Đơn vị công việc ASE_CCL.1-5

Người đánh giá cần thẩm tra yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) đối với TCVN 8709-2 (ISO/IEC 15408-2) [3] để xác định rằng nó nhất quán với định nghĩa các thành phần mở rộng.

Nếu yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) có chứa tuân thủ TCVN 8709-3 (ISO/IEC 15408-3), người đánh giá xác định rằng định nghĩa các thành phần m rộng mà không định nghĩa các thành phần chức năng.

Nếu yêu cầu tuân thủ TCVN 8709 (ISO/IEC 15408) có chứa mở rộng của TCVN 8709-3 (ISO/IEC 15408-3), người đánh giá xác định rằng định nghĩa các thành phần mở rộng định nghĩa ít nhất một thành phần chức năng mở rộng.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_CCL.1.5C: Yêu cầu tuân thủ cn 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ủ.

9.4.1.3.6  Đơn vị công việc ASE_CCL.1-6

Người đánh giá cần kiểm tra xem yêu cầu tuân thủ có chứa yêu cầu PP để xác định tất cả các PP mà ST yêu cầu tuân thủ.

Nếu ST không yêu cầu tuân thủ theo PP, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng bất kỳ PP tham chiếu nào cũng được xác định một cách rõ ràng (ví dụ như theo tiêu đề và số phiên bản hoặc bằng cách xác định có trong phần giới thiệu của PP đó).

Người đánh giá được nhắc nhở rằng không được phép yêu cầu tuân thủ một phần với PP. Vì vậy, tuân thủ theo PP đòi hỏi một giải pháp tổng hợp có thể được yêu cầu trong ST cho TOE tổng hợp. Tuân thủ theo PP như vậy sẽ không thể thực hiện được trong quá trình đánh giá của các TOE thành phần, như các thành phần này sẽ không thỏa mãn các giải pháp tổng hợp. Điều này chỉ có thể có trong các trường hợp PP "tổng hợp" cho phép sử dụng các phương pháp đánh giá thành phần (sử dụng các thành phần ACO).

ST cho TOE tổng hợp sẽ xác định các ST của các TOE thành phần t ST tổng hợp đã bao gồm. TOE tổng hợp tuân thủ yêu cầu được yêu cầu theo các ST của các TOE thành phần.

9.4.1.3.7  Đơn vị công việc ASE CCL.1-7

Người đánh giá cần kiểm tra xem yêu cầu tuân thủ có bao gồm yêu cầu gói đ xác định tất cả các gói mà ST yêu cầu tuân thủ.

Nếu ST không yêu cầu tuân thủ theo gói, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng bất kỳ gói tham chiếu nào cũng được xác định một cách rõ ràng (ví dụ như theo tiêu đề và số phiên bản hoặc bằng cách xác định có trong phần giới thiệu của gói đó).

Người đánh giá xác định rằng các ST của TOE thành phần t các TOE tổng hợp có nguồn gốc rõ ràng cũng được xác định.

Người đánh giá được nhắc nhở rằng không được phép có yêu cầu tuân thủ một phần đối với gói.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_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 ST theo hoặc gói tuân thủ hoặc gói tăng cường.

9.4.1.3.8  Đơn vị công việc ASE_CCL.1-8

Người đánh giá cần kiểm tra xem với mỗi gói đã được xác định, trạng thái yêu cầu tuân thủ là yêu cầu của tên gói tuân thủ hoặc gia tăng tên gói.

Nếu ST không yêu cầu tuân thủ theo gói, đơn vị công việc này không áp dụng và do đó được coi là tha mãn.

Nếu yêu cầu tuân thủ gói chứa tên gói tuân thủ, người đánh giá xác định rằng:

a) nếu gói là một gói đảm bảo, thì ST có chứa tất cả các SAR kèm theo gói, nhưng không thêm các SAR.

b) nếu gói là một gói chức năng, thì ST chứa tất cả các SFR kèm theo gói, nhưng không thêm các SFR.

Nếu yêu cầu tuân thủ gói chứa gia tăng tên gói, người đánh giá xác định rằng:

a) nếu gói là một gói đảm bảo, thì ST có chứa tất cả các SAR kèm theo gói và thêm ít nhất một SAR hoặc ít nhất một SAR là phân cấp của một SAR trong gói.

b) nếu gói là một gói chức năng, thì ST chứa tất cả các SFR kèm theo trong gói và thêm ít nhất một SFR hoặc ít nhất một SFR là phân cấp của một SFR trong gói.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

9.4.1.3.9  Đơn vị công việc ASE_CCL.1-9

Người đánh giá cần thẩm tra sở cứ yêu cầu tuân thủ để xác định rằng kiểu TOE của TOE là nhất quán với tất cả các kiểu TOE của PP.

Nếu ST không yêu cầu tuân thủ theo PP, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Mi quan hệ giữa các kiu có thể đơn giản là: yêu cầu tuân thủ ST tường lửa theo PP tường lửa hoặc phức tạp hơn: một ST thẻ thông minh yêu cầu tuân thủ đối với một số PP cùng một thời điểm (một PP cho các mạch tích hợp, một PP cho hệ điều hành thẻ thông minh và hai PP cho hai ứng dụng trên thẻ thông minh).

Đối với TOE tổng hợp, người đánh giá sẽ xác định liệu sở cứ yêu cầu tuân thủ có chứng minh rằng các loại TOE của TOE thành phần nhất quán với các kiểu TOE tổng hợp không. Điều này không có nghĩa là cả hai loại TOE thành phần và TOE tổng hợp phải giống nhau, nhưng đúng hơn là các TOE thành phần phù hợp để tích hợp cung cấp TOE tổng hợp. Nó nên thực hiện rõ ràng trong ST của TOE tổng hợp mà các SFR chỉ bao gồm kết quả của thành phần và không được thẩm tra như các SFR trong đánh giá TOE cơ sở và phụ thuộc (ví dụ EALx).

TCVN 8709-3 (ISO/IEC 15408-3) 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 vn đề 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.

9.4.1.3.10  Đơn vị công việc ASE CCL.1-10

Người đánh giá cần thẩm tra sở cứ cho yêu cầu tuân thủ để xác định rằng nó chứng minh tuyên bố của định nghĩa vấn đề an toàn là nht quán, như định nghĩa tuyên bố tuân thủ của PP, với các tuyên bố định nghĩa vấn đề an toàn nêu trong PP mà sự tuân thủ được yêu cầu.

Nếu ST không yêu cầu tuân thủ theo PP, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Nếu ST không tuyên bố định nghĩa vấn đề an toàn, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Nếu tuân thủ chặt chẽ được yêu cầu bởi PP mà sự tuân thủ được yêu cầu, không được yêu cầu lý do yêu cầu tuân thủ. Thay vào đó, người đánh giá xác định liệu:

a) các mối đe dọa trong ST có là một tập lớn của hoặc giống với các mối đe dọa trong PP mà sự tuân thủ được yêu cầu không;

b) các OSP trong ST có là một tập lớn của hoặc giống với các OSP trong PP mà sự tuân thủ được yêu cầu không;

c) các giả thiết trong ST có giống với các giả thiết trong PP mà sự tuân thủ được yêu cầu không;

Nếu tính tuân thủ diễn giải được được yêu cầu bởi PP, người đánh giá thẩm tra sở cứ yêu cầu tuân th đ xác định nó chứng minh rằng tuyên bố định nghĩa vấn đề an toàn của ST được đánh giá là tương đương hoặc chặt chẽ hơn so với tuyên bố định nghĩa vấn đề an toàn trong PP mà sự tuân thủ được yêu cầu.

Hướng dẫn về "tương đương hoặc chặt chẽ hơn" xem Phụ lục D TCVN 8709-1 (ISO/IEC 15408-1), tuân thủ PP.

Đối với một TOE tổng hợp, người đánh giá sẽ xem xét liệu định nghĩa vấn đề an toàn của TOE tổng hợp có nhất quán với quy định tại các ST trong các TOE thành phần không. Điều này được xác định trong nhóm tính tuân thủ diễn giải được. Đặc biệt, người đánh giá thẩm tra sở cứ yêu cầu tuân thủ để xác định rằng:

a) các tuyên bố mối đe dọa và các OSP trong ST của TOE tổng hợp không mâu thuẫn với những nội dung từ các ST thành phần.

b) bất kỳ giả thiết nào được thực hiện trong các ST thành phần cũng được duy trì trong ST của TOE tổng hợp. Nghĩa là hoặc giả thiết cũng nên có mặt trong ST tổng hợp hoặc giả thiết nên đề cập một cách tích cực trong ST tổng hợp. Giả thiết có thể được đề cập một cách tích cực thông qua các các yêu cầu về đặc điểm kỹ thuật trong TOE tổng hợp để cung cấp chức năng thực hiện liên quan trong các giả thiết.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_CCL.1.9C: Sở cứ yêu cầu tuân thủ cn 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.

9.4.1.3.11  Đơn vị công việc ASE_CCL.1-11

Người đánh giá cần thẩm tra sở cứ yêu cầu tuân thủ để xác định rằng tuyên bố các mục tiêu an toàn là nhất quán, như định nghĩa tuyên bố sự tuân thủ của các PP, với tuyên bố mục tiêu an toàn trong các PP theo đó sự tuân thủ được yêu cầu..

Nếu ST không yêu cầu tuân thủ theo PP, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Nếu tuân thủ chặt chẽ được yêu cầu bởi PP, không cần sở cứ yêu cầu tuân thủ. Thay vào đó, người đánh giá xác định liệu:

• ST có chứa tất cả mục tiêu an toàn cho TOE của PP mà sự tuân thủ được yêu cầu không. Lưu ý rằng nó được phép để ST được đánh giá có mục tiêu an toàn bổ sung cho TOE;

• ST có cha chính xác tất cả các mục tiêu an toàn đối với môi trường vận hành (với ngoại lệ được trình bày ở ý tiếp theo) không. Lưu ý rằng không được phép để ST được đánh giá có mục tiêu an toàn bổ sung đối với môi trường vận hành;

• ST có thể chỉ định các mục tiêu nhất định cho môi trường vận hành trong PP mà tuân thủ đang được yêu cầu có là những mục tiêu an toàn cho TOE trong ST được đánh giá không. Đây là trường hợp ngoại lệ được trình bày ý trước.

Nếu tính tuân thủ diễn giải được được yêu cầu bởi PP mà sự tuân thủ được yêu cầu, người đánh giá thẩm tra sở cứ yêu cầu tuân thủ để xác định nó chứng minh rằng tuyên b các mục tiêu an toàn của ST là tương đương hoặc chặt chẽ hơn so với tuyên bố các mục tiêu an toàn trong PP mà sự tuân thủ được yêu cầu.

Hướng dẫn về "tương đương hoặc chặt chẽ hơn" xem Phụ lục D TCVN 8709-1 (ISO/IEC 15408-1), tuân thủ PP.

Đối với một TOE tổng hợp, người đánh giá sẽ xem xét liệu các mục tiêu an toàn của TOE tổng hợp có nhất quán với quy định tại các ST trong các TOE thành phần không. Điều này được xác định trong các thuật ngữ của tính tuân thủ diễn gii được. Đặc biệt, người đánh giá thẩm tra sở cứ yêu cầu tuân thủ để xác định rằng:

a) tuyên bố các mục tiêu an toàn trong ST của TOE phụ thuộc liên quan đến bất kỳ công nghệ thông tin trong môi trường vận hành là nhất quán với tuyên bố các mục tiêu an toàn cho TOE trong ST của TOE cơ sở. Nó không phải là dự kiến tuyên bố các mục tiêu an toàn cho môi trường trong ST của TOE phụ thuộc sẽ bao gồm tất cả các nội dung của tuyên bố các mục tiêu an toàn cho TOE trong ST của TOE cơ sở.

b) tuyên bố các mục tiêu an toàn trong ST tổng hợp là nhất quán với tuyên bố các mục tiêu an toàn trong các ST đối với các TOE thành phần.

Nếu tuân thủ có thể chng minh được yêu cầu bởi PP, người đánh giá thẩm tra sở cứ tuyên bố tuân thủ đ xác định rằng nó chứng minh tuyên bố các mục tiêu an toàn của ST ít nhất là tương đương với tuyên bố các mục tiêu an toàn trong PP hoặc ST của TOE thành phần trong trường hợp ST của TOE tổng hợp.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_CCL.1.10C: Sở cứ tuyên bố 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à theo đó sự tuân thủ được yêu cu.

9.4.1.3.12  Đơn vị công việc ASE_CCL.1-12

Người đánh giá cần thm tra ST để xác định rằng nó là nhất quán, như định nghĩa tuyên bố tuân thủ của PP, với tất cả các yêu cầu an toàn trong các PP mà sự tuân thủ được yêu cầu.

Nếu ST không yêu cầu tuân thủ theo PP, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Nếu tuân thủ chặt chẽ được yêu cầu bởi PP mà sự tuân thủ được yêu cầu, không cần thiết phải có sở cứ yêu cầu tuân thủ. Thay vào đó, người đánh giá xác định xem tuyên bố các yêu cầu an toàn trong ST có là một tập lớn của hoặc giống hệt tuyên bố các yêu cầu an toàn trong PP mà sự tuân thủ được yêu cầu không (cho tuân thủ chặt chẽ).

Nếu tuân thủ diễn giải được được yêu cầu bởi PP mà sự tuân thủ được yêu cầu, người đánh giá thẩm tra sở cứ tuyên bố tuân thủ để xác định nó chứng minh rằng tuyên bố các yêu cầu an toàn của ST là tương đương hoặc chặt chẽ hơn so với tuyên bố các yêu cầu an toàn trong PP mà sự tuân thủ được yêu cầu.

Hướng dẫn về "tương đương hoặc chặt chẽ hơn" xem Phụ lục D TCVN 8709-1 (ISO/IEC 15408-1), tuân thủ PP.

Đối với một TOE tổng hợp, người đánh giá sẽ xem xét liệu các yêu cầu an toàn của TOE tổng hợp có nhất quán với quy định tại các ST trong các TOE thành phần không. Điều này được xác định trong nhóm của tính tuân thủ diễn giải được. Đặc biệt, người đánh giá thẩm tra sở cứ yêu cầu tuân thủ để xác định rằng:

a) tuyên bố các mục tiêu an toàn trong ST của TOE phụ thuộc liên quan đến bất kỳ công nghệ thông tin trong môi trường vận hành là nhất quán với tuyên bố các yêu cầu an toàn đối với TOE trong ST của TOE cơ sở. Nó không phải là dự kiến tuyên bố các yêu cầu an toàn cho môi trường trong ST của TOE phụ thuộc sẽ bao gồm tất cả các nội dung của tuyên bố các yêu cầu an toàn trong TOE trong ST TOE cơ sở, như một số SFR có thể phải được bổ sung tuyên bố của các yêu cầu an toàn trong ST của TOE tổng hợp. Tuy nhiên, tuyên bố các yêu cầu an toàn trong cơ sở nên hỗ trợ các hoạt động của thành phần phụ thuộc.

b) tuyên bố các mục tiêu an toàn trong ST của TOE phụ thuộc liên quan đến bt kỳ công nghệ thông tin trong môi trường vận hành là nhất quán với tuyên bố các yêu cầu an toàn đối với TOE trong ST của TOE cơ sở. Nó không phải là dự kiến tuyên bố các mục tiêu an toàn cho môi trường trong ST của TOE phụ thuộc sẽ bao gồm tất cả các nội dung của tuyên bố các yêu cầu an toàn đối với TOE trong ST của TOE cơ sở.

c) tuyên bố các yêu cầu an toàn trong ST tổng hợp là nhất quán với tuyên bố các yêu cầu an toàn trong các ST đối với các TOE thành phần.

Nếu tuân thủ diễn giải được được yêu cầu bởi PP mà sự tuân thủ được yêu cầu, người đánh giá thẩm tra sở cứ tuyên bố tuân thủ để xác định rằng nó chứng minh tuyên bố các yêu cầu an toàn của ST ít nhất là tương đương với tuyên bố các yêu cầu an toàn trong PP hoặc ST của TOE thành phần trong trường hợp ST của TOE tổng hợp.

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

9.5.1  Đánh giá hoạt động con (ASE_SPD.1)

9.5.1.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định rằng vấn đề an toàn dự kiến được đề cập đến bởi TOE và môi trường vận hành của nó được xác định rõ ràng.

9.5.1.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) ST.

9.5.1.3  Hành động ASE_SPD.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) ASE_SPD.1.1C: Định nghĩa vấn đề an toàn cần mô tả các mối đe dọa.

9.5.1.3.1  Đơn vị công việc ASE_SPD.1-1

Người đánh giá cần kiểm tra rằng định nghĩa vấn đề an toàn mô tả các mối đe dọa.

Nếu tt c các mục tiêu an toàn xuất phát từ các giả thiết và/hoặc chỉ các OSP, tuyên bố các mối đe dọa không cần có trong ST. Trong trường hợp này, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng định nghĩa vấn đề an toàn mô tả các mối đe dọa phải được chống lại bởi TOE và/hoặc môi trường vận hành của nó.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_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 đe dọa, tài sản và hành động có hại.

9.5.1.3.2  Đơn vị công việc ASE_SPD.1-2

Người đánh giá cần thẩm tra định nghĩa vấn đề an toàn để xác định rằng tất cả các mối đe dọa được mô tả dưới dạng tác nhân đe dọa, tài sản và hành động có hại.

Nếu tất cả các mục tiêu an toàn xuất phát từ giả thiết và ch các OSP, tuyên bố các mối đe dọa không cần có trong ST. Trong trường hợp này, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Các tác nhân đe dọa có thể được mô tả bằng cách thêm các phương diện như chuyên môn, nguồn lực, cơ hội và động lực.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_SPD. 1.3C: Định nghĩa vấn đề an toàn cần mô tả các OSP.

9.5.1.3.3  Đơn vị công việc ASE SPD.1-3

Người đánh giá cần kiểm tra rằng định nghĩa vấn đề an toàn mô tả các OSP.

Nếu tất cả các mục tiêu an toàn xuất phát từ giả thiết và/hoặc chỉ các mối đe dọa, các OSP không cần có trong ST. Trong trường hợp này, đơn vị công việc này không áp dụng và do đó được coi là tha mãn.

Người đánh giá xác định rằng các tuyên bố OSP được thực hiện trong các thuật ngữ quy tắc hoặc hướng dẫn phải theo TOE và/hoặc môi trường vận hành của nó.

Người đánh giá xác định rằng mỗi OSP được giải thích và/hoặc diễn dịch đầy đủ chi tiết để nó rõ ràng dễ hiểu; trình bày rõ ràng về các tuyên bố chính sách là được yêu cầu để cho phép theo du mục tiêu an toàn cho chúng.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_SPD.1.4C: Định nghĩa 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.5.1.3.4  Đơn vị công việc ASE_SPD.1-4

Người đánh giá cần thẩm tra định nghĩa vấn đề an toàn để xác định rằng nó mô tả các giả thiết về môi trường vận hành của TOE.

Nếu không có các giả thiết, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng mỗi giả thiết về môi trường vận hành của TOE được giải thích đầy đủ chi tiết, cho phép người sử dng xác định môi trường vận hành của họ phù hợp với giả thiết. Nếu các giả thiết chưa được hiểu rõ, kết quả cuối cùng có thể TOE được sử dụng trong môi trường vận hành, khi đó nó sẽ không hoạt động theo cách an toàn.

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

9.6.1  Đánh giá hoạt động con (ASE_OBJ.1)

9.6.1.1  Mục tiêu

Mục tiêu của hoạt động con này đ xác định liệu mục tiêu an toàn cho môi trường vận hành có được xác định rõ ràng không.

9.6.1.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) ST.

9.6.1.3  Hành động ASE_OBJ.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) 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 vận hành.

9.6.1.3.1  Đơn vị công việc ASE_OBJ.1-1

Người đánh giá cần kiểm tra rằng tuyên bố của các mục tiêu an toàn định nghĩa các mục tiêu an toàn cho môi trường vận hành.

Người đánh giá kiểm tra rằng các mục tiêu an toàn cho môi trường vận hành được xác định.

9.6.2  Đánh giá hoạt động con (ASE_OBJ.2)

9.6.2.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu các mục tiêu an toàn có đề cập đến định nghĩa vấn đề an toàn một cách tha đáng và đầy đủ không và việc phân chia vấn đề này giữa TOE và môi trường vận hành của nó có được xác định rõ ràng không.

9.6.2.2  Đu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) ST.

9.6.2.3  Hành động ASE_OBJ.2.1E

TCVN 8709-3 (ISO/IEC 15408-3) 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 vận hành.

9.6.2.3.1  Đơn vị công việc ASE_OBJ.2-1

Người đánh giá cần kiểm tra rằng tuyên bố các mục tiêu an toàn định nghĩa các mục tiêu an toàn cho TOE và các mục tiêu an toàn cho môi trường vận hành.

Người đánh giá kiểm tra rằng cả hai phạm trù mục tiêu an toàn đã được xác định rõ ràng và tách ra từ phạm trù khác.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_OBJ.2.2C: Sở cứ các mục tiêu an toàn cần theo dấu từng mục tiêu an toàn cho TOE chống lại các mối đe dọa bởi mục tiêu an toàn đó và các OSP được thực thi bởi mục tiêu an toàn.

9.6.2.3.2  Đơn vị công việc ASE_OBJ.2-2

Người đánh giá cần kiểm tra rằng sở cứ các mục tiêu an toàn theo dấu tất cả các mục tiêu an toàn cho TOE chống lại các mối đe dọa bởi các mục tiêu và/hoặc thực thi các OSP bởi các mục tiêu.

Mỗi mục tiêu an toàn cho TOE có thể theo dấu các mối đe da hoặc các OSP hoặc s kết hợp của các mối đe dọa và OSP, nhưng nó phải theo dấu ít nhất một mối đe dọa hoặc một OSP.

Lỗi khi thực hiện theo du có nghĩa là sở cứ mục tiêu an toàn không đầy đ, định nghĩa vấn đề an toàn không đầy đủ hoặc mục tiêu an toàn cho TOE không có mục đích hữu ích.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_OBJ.2.3C: Sở cứ các mục tiêu an toàn cn theo dấu từng mục tiêu an toàn cho môi trường vận hành chống lại các mối đe dọa bởi mục tiêu an toàn đó và các OSP được thực thi bởi mục tiêu an toàn và giả thiết duy trì mục tiêu an toàn.

9.6.2.3.3  Đơn vị công việc ASE_OBJ.2-3

Người đánh giá cần kiểm tra rằng sở cứ các mục tiêu an toàn theo dấu các mục tiêu an toàn cho môi trường vận hành chống lại các mối đe dọa bởi mục tiêu an toàn đó và 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 đó.

Mỗi mục tiêu an toàn cho môi trường vận hành có thể theo dấu các mối đe dọa, OSP, giả thiết hoặc sự kết hợp của các mối đe dọa, các OSP và/hoặc các giả thiết, nhưng nó phải theo dấu ít nhất một mối đe dọa, một OSP hoặc một giả thiết.

Lỗi khi thực hiện theo dấu có nghĩa là sở cứ mục tiêu an toàn không đầy đủ, định nghĩa vấn đề an toàn không đầy đủ hoặc mc tiêu an toàn cho môi trường vận hành không có mc đích hữu ích.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_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 mối đe dọa.

9.6.2.3.4  Đơn vị công việc ASE_OBJ.2-4

Người đánh giá cần thẩm tra sở cứ các mục tiêu an toàn đ xác định rằng nó biện minh cho mỗi mối đe dọa rằng các mục tiêu an toàn là phù hợp để chống lại mối đe dọa đó.

Nếu không có mục tiêu an toàn theo dấu mối đe dọa, thì hành động của người đánh giá liên quan đến đơn vị công việc này được chỉ định là một nhận định không đạt.

Người đánh giá xác định rằng việc biện minh cho một mối đe dọa cho thấy liệu mối đe dọa có được loại bỏ, gim bớt hoặc giảm nhẹ hay không.

Người đánh giá xác định rằng biện minh cho một mối đe dọa chứng minh rằng các mục tiêu an toàn là đầy đủ: nếu tất cả các mục tiêu an toàn theo dấu mối đe dọa đã đạt được, thì mối đe dọa đã được loại bỏ, giảm bớt hoặc những ảnh hưởng của các mối đe dọa được giảm nhẹ.

Lưu ý rằng việc theo dấu từ các mục tiêu an toàn đến các mối đe dọa được cung cấp trong sở cứ mục tiêu an toàn có thể là một phần của một sự biện minh, nhưng không được coi là biện minh của chính nó. Ngay c trong trường hợp một mục tiêu an toàn chỉ là một tuyên bố phản ánh mục đích để ngăn chặn một mối đe dọa cụ thể đang được thực hiện, thì một sự biện minh được yêu cầu, nhưng biện minh này có thể là tối thiểu như "mục tiêu an toàn X trực tiếp chống lại mối đe dọa Y".

Người đánh giá cũng xác định rằng mỗi mục tiêu an toàn theo dấu mối đe dọa là cần thiết; khi mục tiêu an toàn đã đạt được nó thực sự góp phần vào việc loại bỏ, giảm bớt hoặc giảm thiểu mối đe dọa đó.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_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.6.2.3.5  Đơn vị công việc ASE_OBJ.2-5

Người đánh giá cần thẩm tra sở cứ các mục tiêu an toàn để xác định rằng đối với mỗi OSP nó biện minh rằng các mục tiêu an toàn là phù hợp để thực thi OSP đó.

Nếu không có mục tiêu an toàn theo dấu OSP, hành động của người đánh giá liên quan đến đơn vị công việc này được chỉ định là nhận định không đạt.

Người đánh giá xác định rằng biện minh cho các diễn giải mối đe dọa tại các mục tiêu an toàn là đầy đủ: nếu tất cả các mục tiêu an toàn theo dấu mối đe dọa đạt được, OSP được thực thi.

Người đánh giá cũng xác định mỗi mục tiêu an toàn theo dấu OSP là được yêu cầu: khi mục tiêu an toàn đạt được nó thực sự góp phần vào việc thực thi của OSP.

Lưu ý rằng các theo dấu từ các mục tiêu an toàn đến các mối đe dọa được cung cấp trong sở cứ mục tiêu an toàn có thể là một phần của một sự biện minh, nhưng không được coi là biện minh của chính nó. Ngay c trong trường hợp đó, mục tiêu an toàn chỉ là một tuyên bố phản ánh mục đích để ngăn chặn một mối đe dọa cụ thể đang được thực hiện, một sự biện minh là được yêu cầu, nhưng biện minh này là tối thiểu "Mục tiêu an toàn X trực tiếp chống lại mối đe dọa Y".

TCVN 8709-3 (ISO/IEC 15408-3) ASE_OBJ.2.6C: Sở cứ các mục tiêu an toàn cn chứng minh rằng các mục tiêu an toàn cho môi trường vận hành duy trì tất cả các giả thiết.

9.6.2.3.6  Đơn vị công việc ASE_OBJ.2-6

Người đánh giá cần thẩm tra sở cứ các mục tiêu an toàn để xác định rằng đối với mỗi giả thiết cho môi trường vận hành nó có chứa một sự biện minh hợp lý mà các mục tiêu an toàn cho môi trường vận hành phù hợp để duy trì giả thiết đó.

Nếu không có các mục tiêu an toàn cho môi trường vận hành theo dấu giả thiết, hành động của người đánh giá liên quan đến đơn vị công việc này được chỉ định là nhận định không đạt.

Người đánh giá xác định rằng biện minh cho một giả thiết về môi trường vận hành của TOE diễn giải rằng các mục tiêu an toàn là đầy đủ: nếu tất cả các mục tiêu an toàn cho môi trường vận hành theo dấu giả thiết đạt được, môi trường vận hành duy trì giả thiết.

Người đánh giá cũng xác định mỗi mục tiêu an toàn cho môi trường vận hành theo du giả thiết về môi trường vận hành của TOE là được yêu cầu: khi mục tiêu an toàn đạt được nó thực sự góp phần vào việc duy trì môi trường vận hành giả thiết.

Lưu ý rằng các theo dấu từ các mục tiêu an toàn cho môi trường vận hành đến các giả thiết đã cung cấp trong sở cứ các mục tiêu an toàn có thể là một phần của một sự biện minh, nhưng không được coi là biện minh của chính nó. Trong trường hợp đó, mục tiêu an toàn của môi trường vận hành chỉ đơn thuần là trình bày lại một giả thiết, một sự biện minh là được yêu cầu, nhưng biện minh này là tối thiểu "Mục tiêu an toàn X trực tiếp chống lại mối đe dọa Y".

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

9.7.1  Đánh giá hoạt động con (ASE_ECD.1)

9.7.1.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu các thành phần mở rộng có được định nghĩa rõ ràng và mạch lạc không và nó có được yêu cầu không, nghĩa là nó có thể đã không được thể hiện rõ ràng khi sử dụng các thành phần TCVN 8709-2 (ISO/IEC 15408-2) hoặc TCVN 8709-3 (ISO/IEC 15408-3) đang tồn tại.

9.7.1.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) ST.

9.7.1.3  Hành động ASE_ECD.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) 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.

9.7.1.3.1  Đơn vị công việc ASE_ECD.1-1

Người đánh giá cần kiểm tra rằng tất cả các yêu cầu an toàn trong tuyên bố các yêu cầu an toàn mà không được xác định là các yêu cầu mở rộng đều có trong TCVN 8709-2 (ISO/IEC 15408-2) hoặc TCVN 8709-3 (ISO/IEC 15408-3).

TCVN 8709-3 (ISO/IEC 15408-3) ASE_ECD.1.2C: Định nghĩa các thành phần mở rộng cần định nghĩa một thành phần mở rộng cho mỗi yêu cầu an toàn mở rộng.

9.7.1.3.2  Đơn vị công việc ASE_ECD.1-2

Người đánh giá cần kiểm tra rng định nghĩa các thành phần mở rộng định nghĩa thành phần mở rộng cho mỗi yêu cầu an toàn mở rộng.

Nếu ST không chứa các yêu cầu an toàn mở rộng, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Thành phần mở rộng đơn nhất có thể được sử dụng để định nghĩa nhiều phép lặp của yêu cầu an toàn mở rộng, không được yêu cầu nhắc lại định nghĩa này cho mỗi phép lặp.

TCVN 8709-3 (ISO/IEC 15408-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 lớp, các họ và các thành phần TCVN 8709 (ISO/IEC 15408) đang tồn tại.

9.7.1.3.3  Đơn vị công việc ASE_ECD.1-3

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng đ xác định rằng nó mô tả mỗi thành phần mở rộng phù hợp thế nào với các lớp, h, thành phần TCVN 8709 (ISO/IEC 15408) đang tồn tại. Nếu ST không có các yêu cầu an toàn mở rộng, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng mỗi thành phần mở rộng là:

a) thành phần của họ TCVN 8709-2 (ISO/IEC 15408-2) hoặc TCVN 8709-3 (ISO/IEC 15408-3) đang tồn tại hoặc

b) thành phần của một họ mới được định nghĩa trong ST.

Nếu thành phần mở rộng là thành phần của họ TCVN 8709-2 (ISO/IEC 15408-2) hoặc TCVN 8709-3 (ISO/IEC 15408-3) đang tồn tại, người đánh giá xác định rằng định nghĩa các thành phần mở rộng mô tả đầy đủ lý do tại sao các thành phần mở rộng nên là một thành phần của họ và nó liên quan với các thành phần khác của họ đó như thế nào.

Nếu các thành phần mở rộng là một thành phần của một h mới được định nghĩa trong PP, người đánh giá xác nhận rng các thành phần mở rộng là không phù hợp với họ đang tồn tại.

Nếu ST định nghĩa các họ mới, người đánh giá xác định rằng mỗi họ mới là:

a) thành phần của lớp trong TCVN 8709-2 (ISO/IEC 15408-2) hoặc TCVN 8709-3 (ISO/IEC 15408-3) đang tồn tại hoặc

b) thành phần của một lớp mới được định nghĩa trong ST.

Nếu họ là thành phần của lớp trong TCVN 8709-2 (ISO/IEC 15408-2) hoặc TCVN 8709-3 (ISO/IEC 15408-3) đang tồn tại, người đánh giá xác định rằng định nghĩa các thành phần mở rộng mô tả đầy đủ tại sao nó nên là một thành phần của lớp đó và nó liên quan đến họ khác trong lớp đó như thế nào.

Nếu họ là thành phần của một lớp mới được định nghĩa trong ST, người đánh giá xác nhận rng họ không thích hợp đối với lớp đang tồn tại.

9.7.1.3.4  Đơn vị công việc ASE_ECD.1-4

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng để xác định rằng mỗi định nghĩa của một thành phần mở rộng xác định tất cả các phụ thuộc có thể áp dụng của thành phần đó.

Nếu PP không có các yêu cầu an toàn mở rộng, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác nhận rằng các phụ thuộc không thể áp dụng đã được bỏ qua bởi tác giả ST.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_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 TCVN 8709 (ISO/IEC 15408) đang tồn tại và phương pháp luận như là mô hình cho trình bày.

9.7.1.3.5  Đơn vị công việc ASE_ECD.1-5

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng để xác định rng mỗi thành phần chức năng mở rộng sử dụng các thành phần TCVN 8709-2 (ISO/IEC 15408-2) đang tồn tại như là mô hình cho trình bày.

Nếu ST không có các SFR mở rộng, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng thành phần chức năng mở rộng là nhất quán với TCVN 8709-2 (ISO/IEC 15408-2); Điều 6.1.3, cấu trúc thành phần.

Nếu thành phần chức năng mở rộng sử dụng các hoạt động, người đánh giá xác định rng thành phần chức năng mở rộng là nhất quán với Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

Nếu thành phần chức năng mở rộng là phân cấp của thành phần chức năng đang tồn tại, người đánh giá xác định rằng thành phần chức năng mở rộng là nhất quán với TCVN 8709-2 (ISO/IEC 15408-2): Điều 6.2.1, Nhấn mạnh các thay đổi thành phần.

9.7.1.3.6  Đơn vị công việc ASE_ECD.1-6

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng đ xác định rằng mỗi định nghĩa của họ chức năng mới sử dụng các họ chức năng của TCVN 8709 (ISO/IEC 15408) đang tồn tại như là mô hình cho trình bày.

Nếu ST không định nghĩa các h chức năng mới, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng tất cả các họ chức năng mới được định nghĩa nhất quán với TCVN 8709-2 (ISO/IEC 15408-2): Điều 6.1.2, Cấu trúc họ.

9.7.1.3.7  Đơn vị công việc ASE_ECD.1-7

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng đ xác định rng mỗi định nghĩa của lớp chức năng mới sử dụng các lớp chức năng TCVN 8709 (ISO/IEC 15408) đang tồn tại như là mô hình cho trình bày.

Nếu ST không định nghĩa các lớp chức năng mới, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng tất cả lớp chức năng mới được định nghĩa nhất quán với TCVN 8709-2 (ISO/IEC 15408-2): Điều 6.1.1, Cấu trúc lớp.

9.7.1.3.8  Đơn vị công việc ASE_ECD.1-8

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng để xác định rằng mỗi định nghĩa của thành phần đảm bảo mở rộng sử dụng các thành phần TCVN 8709-3 (ISO/IEC 15408-3) đang tồn tại như là mô hình cho trình bày.

Nếu ST không chứa các SAR mở rộng, đơn vị công việc này không áp dng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng định nghĩa thành phần đảm bảo mở rộng là nhất quán với TCVN 8709-3 (ISO/IEC 15408-3): Điều c 6.1.3, cấu trúc thành phần đảm bảo.

Nếu thành phần đảm bảo mở rộng sử dụng các hoạt động, người đánh giá xác định rằng các thành phần đảm bảo mở rộng là nhất quán với Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

Nếu thành phần bảo đảm mở rộng là phân cấp của thành phần đảm bảo đang tồn tại, người đánh giá xác định rằng thành phần đảm bảo mở rộng là nhất quán với TCVN 8709-3 (ISO/IEC 15408-3): Điều 6.1.3, Cấu trúc thành phần đảm bảo.

9.7.1.3.9  Đơn vị công việc ASE_ECD.1-9

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng đ xác định rằng, đối với mỗi thành phần đảm bảo mở rộng định nghĩa, phương pháp luận áp dụng đã được cung cấp.

Nếu ST không chứa các SAR mở rộng, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng, cho mỗi phần tử hành động của người đánh giá của mỗi SAR mở rộng, được cung cấp một hoặc nhiều đơn vị công việc và thực hiện thành công tất cả các đơn vị công việc cho yếu tố hành động được đánh giá sẽ chứng minh rằng các phần tử đã đạt được.

9.7.1.3.10  Đơn vị công việc ASE_ECD.1-10

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng để xác định rằng mỗi định nghĩa của họ đảm bảo mới sử dụng các họ đảm bảo trong TCVN 8709 (ISO/IEC 15408) đang tồn tại như là mô hình cho trình bày.

Nếu ST không định nghĩa các họ bảo đảm mới, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng tất cả các họ bảo đảm mới được định nghĩa nhất quán với Điều 6.1.2 TCVN 8709-3 (ISO/IEC 15408-3), Cấu trúc họ đảm bảo.

9.7.1.3.11  Đơn vị công việc ASE_ECD.1-11

Người đánh cần thẩm tra định nghĩa các thành phần mở rộng để xác định rằng mỗi định nghĩa của một lớp đảm bảo mới sử dụng các lớp đảm bảo trong TCVN 8709 (ISO/IEC 15408) đang tồn tại như là mô hình cho trình bày.

Nếu ST không định nghĩa các lớp bảo đảm mới, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng tất cả các lớp đảm bảo mới được định nghĩa nhất quán với Điều 6.1.1 TCVN 8709-3 (ISO/IEC 15408-3), Cấu trúc lớp đảm bảo.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_ECD.1.5C: Các thành phần mở rộng cần bao gồm các phần tử mục tiêu và các phần tử đo lường được sao cho sự tuân thủ hoặc không tuân thủ theo những phần tử có thể được chứng minh.

9.7.1.3.12  Đơn v công việc ASE_ECD.1-12

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng đ xác định rằng mỗi phần tử trong mỗi thành phần mở rộng là đo được và các yêu cầu đánh giá mục tiêu trạng thái như là tuân thủ hoặc không tuân thủ có thể được chứng minh.

Nếu ST không có các yêu cầu an toàn mở rộng, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá xác định rằng các phần tử của các thành phần chức năng mở rộng được thể hiện theo cách mà chúng có thể kiểm chứng và có thể theo dấu thông qua các đại diện TSF thích hợp.

Người đánh giá cũng xác định các phần tử của các thành phần đảm bảo mở rộng tránh tạo ra phán xét đánh giá chủ quan.

Người đánh giá được nhắc nhở rằng khi đo lường và mục tiêu phù hợp với tất cả các tiêu chí đánh giá, phải thừa nhận rằng không tồn tại phương pháp chính thức để chứng minh đặc tính đó. Do đó, các thành phần chức năng và đảm bảo của TCVN 8709 (ISO/IEC 15408) đang tồn tại sẽ được sử dụng như một mô hình để xác định thế nào là tuân thủ với yêu cầu này.

9.7.1.4  Hành động ASE_ECD.1.2E

9.7.1.4.1  Đơn vị công việc ASE_ECD.1-13

Người đánh giá cần thẩm tra định nghĩa các thành phần mở rộng đ xác định rằng mỗi thành phần mở rộng có thể đã không được thể hiện rõ ràng khi sử dụng các thành phần đang tồn tại.

Nếu ST không có yêu cầu an toàn mở rộng, đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá nên xem xét các thành phần của TCVN 8709-2 (ISO/IEC 15408-2) và TCVN 8709-3 (ISO/IEC 15408-3), các thành phần mở rộng khác đã được định nghĩa trong PP, sự kết hợp của các thành phần này và các hoạt động có thể trên các thành phần này trong khi đưa ra quyết định này. Người đánh giá được nhắc nhở rằng vai trò của đơn vị công việc này là để loại trừ sự trùng lặp không được yêu cầu của các thành phần, có nghĩa là, các thành phần có thể được thể hiện rõ ràng bằng cách sử dụng các thành phần khác. Người đánh giá không nên thực hiện việc tìm kiếm đầy đủ tất cả các kết hợp có thể bao gồm các hoạt động trong nỗ lực để tìm một cách thể hiện các thành phần mở rộng bằng cách sử dụng các thành phần đang tồn tại.

9.8  Yêu cầu an toàn (ASE_REQ)

9.8.1  Đánh giá hoạt động con (ASE_REQ.1)

9.8.1.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định xem các SFR và SAR có rõ ràng, mạch lạc và được định nghĩa rõ ràng không và liệu chúng có nht quán nội bộ không.

9.8.1.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) ST.

9.8.1.3  Hành động ASE_REQ.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) ASE_REQ.1.1C: Tuyên bố về các yêu cầu an toàn cn mô tả các SFR và SAR.

9.8.1.3.1  Đơn vị công việc ASE_REQ.1-1

Người đánh giá cần kiểm tra tuyên bố yêu cầu an toàn mô tả các SFR.

Người đánh giá xác định rằng mỗi SFR được xác định bởi một trong những cách sau đây:

a) bằng cách tham chiếu đến thành phần riêng lẻ trong TCVN 8709-2 (ISO/IEC 15408-2);

b) bằng cách tham chiếu đến thành phần mở rộng trong định nghĩa các thành phần mở rộng của ST;

c) bằng cách tham chiếu đến một PP mà các yêu cầu PP tuân thủ;

d) bằng cách tham chiếu đến gối các yêu cầu an toàn mà các yêu cầu PP tuân thủ;

e) bằng việc tái sản xuất trong ST.

Không yêu cầu sử dụng cùng một phương tiện nhận dạng cho tất cả các SFR.

9.8.1.3.2  Đơn vị công việc ASE_REQ.1-2

Người đánh giá cần kiểm tra tuyên bố các yêu cầu an toàn mô tả các SAR.

Người đánh giá xác định rằng mỗi SAR được xác định bởi một trong những cách sau đây:

a) bằng cách tham chiếu đến thành phần riêng lẻ trong TCVN 8709-3 (ISO/IEC 15408-3);

b) bằng cách tham chiếu đến thành phần mở rộng trong định nghĩa các thành phần mở rộng của ST;

c) bằng cách tham chiếu đến một PP mà các yêu cầu PP tuân thủ;

d) bằng cách tham chiếu đến gói các yêu cầu an toàn mà các yêu cầu PP tuân thủ;

e) bằng việc tái sản xuất trong ST.

Không yêu cầu sử dụng cùng một phương tiện nhận dạng cho tất cả các SAR.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_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 thuật ngữ khác được sử dụng trong các SFR và SAR, cần được xác định.

9.8.1.3.3  Đơn vị công việc ASE_REQ.1-3

Người đánh giá cần thẩm tra ST để xác định rằng 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 thuật ngữ khác được sử dụng trong các SFR và SAR được xác định.

Người đánh giá xác định rằng ST xác định tất cả:

• (các kiu của) các đối tượng và mục tiêu được sử dụng trong các SFR;

• (các kiểu của) thuộc tính an toàn của các đối tượng, người sử dụng, mục tiêu, thông tin, phiên bản và/hoặc tài nguyên, các giá trị mà thuộc tính này có thể cần và bất kỳ các sở cứ giữa các giá trị này (ví dụ như top_secret là "cao hơn" secret);

• (các kiểu của) các hoạt động được sử dụng trong các SFR, bao gồm cả những ảnh hưởng của các hoạt động này;

• (các kiểu của) các thực thể bên ngoài trong SFR;

• các thuật ngữ khác được giới thiệu trong các SFR và/hoặc SAR bằng cách hoàn thành các thao tác, nếu các thuật ngữ này không rõ ràng ngay hoặc được sử dụng bên ngoài định nghĩa từ điển của chúng.

Mục tiêu của đơn vị công việc này là để đảm bảo rằng các SFR và SAR dễ phân biệt và không gây hiểu lầm có thể xảy ra do việc giới thiệu các thuật ngữ không rõ ràng. Đơn vị công việc này không nên đưa vào giới hạn, bằng cách buộc người viết PP xác định tất cả các từ đơn nhất. Các khán giả chung của tập hợp các yêu cầu an toàn nên được giả thiết có kiến thức hợp lý về công nghệ thông tin, an toàn và "Tiêu chí đánh giá an toàn công nghệ thông tin".

Tất cả các vấn đề trên có thể được trình bày trong các nhóm, các lớp, các vai trò, kiểu hoặc nhóm khác hoặc đặc trưng khác để cho dễ hiu.

Người đánh giá được nhắc nhở rằng các danh sách và định nghĩa không phải là một phần của tuyên bố về các yêu cầu an toàn, nhưng có thể được đặt (một phần hoặc toàn bộ) tại các mục khác nhau. Điều này có thể áp dụng đặc biệt nếu các thuật ngữ tương tự được sử dụng trong phần còn lại của ST.

TCVN 8709-3 (ISO/IEC 15408-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 trên các yêu cầu an toàn.

9.8.1.3.4  Đơn vị công việc ASE_REQ.1-4

Người đánh giá cần kiểm tra tuyên bố các yêu cầu an toàn đ xác định rằng tất cả các hoạt động trên các yêu cầu an toàn.

Người đánh giá xác định rằng tất cả các hoạt động được xác định trong mỗi SFR hoặc SAR nơi hoạt động được sử dụng. Nhận dạng có thể thực hiện được bằng cách phân biệt các bản in hoặc bằng cách xác định tường minh trong các văn bản xung quanh hoặc bằng bất kỳ phương tiện đặc trưng khác.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_REQ.1.4C: Tất cả các hoạt động cần phải thực hiện đúng.

9.8.1.3.5  Đơn vị công việc ASE_REQ.1-5

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng tất cả các hoạt động chỉ định đã thực hiện đúng.

Hướng dẫn thực hiện đúng các hoạt động có thể tìm thấy trong Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

9.8.1.3.6  Đơn vị công việc ASE_REQ.1-6

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng tất cả các hoạt động lặp lại đã được thực hiện đúng.

Hướng dẫn thực hiện đúng các hoạt động có thể tìm thấy trong Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

9.8.1.3.7  Đơn vị công việc ASE_REQ.1-7

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng tất cả các hoạt động lựa chọn đã được thực hiện đúng.

Hướng dẫn thực hiện đúng các hoạt động có thể được tìm thấy trong Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

9.8.1.3.8  Đơn vị công việc ASE_REQ.1-8

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng tất cả các hoạt động bổ sung chi tiết đã được thực hiện đúng.

Hướng dẫn thực hiện đúng các hoạt động có thể được tìm thấy trong Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_REQ.1.5C: Mỗi sự phụ thuộc của các yêu cầu an toàn cần hoặc thỏa mãn hoặc sở cứ các yêu cầu an toàn cần biện minh sự phụ thuộc còn chưa được thỏa mãn.

9.8.1.3.9  Đơn vị công việc ASE_REQ.1-9

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng mỗi phụ thuộc của các yêu cầu an toàn hoặc thỏa mãn hoặc sở cứ các yêu cầu an toàn biện minh sự phụ thuộc còn chưa được thỏa mãn.

Sự phụ thuộc được thỏa mãn bao gồm các thành phần có liên quan (hoặc một trong số đó là phân cấp của nó) trong tuyên bố các yêu cầu an toàn. Thành phần được sử dụng để đáp ứng sự phụ thuộc nên, nếu được yêu cầu, được sửa đổi bởi các hoạt động đ đảm bảo rằng nó tha mãn đúng sự phụ thuộc đó.

Biện minh về việc một sự phụ thuộc không được đáp ứng cần đề cập:

a) do tại sao sự phụ thuộc là không được yêu cầu hoặc hữu ích, trường hợp nào thông tin không được yêu cầu thêm; hoặc

b) sự phụ thuộc đã được đề cp bởi môi trường vận hành của TOE, trường hợp nào biện minh nên mô tả cách thức các mục tiêu an toàn cho môi trường vận hành đề cập sự phụ thuộc này.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_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.8.1.3.10  Đơn vị công việc ASE_REQ.1-10

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định nó có tính nhất quán nội bộ.

Người đánh giá xác định rằng các thiết lập liên hợp của tất cả các SFR và SAR có tính nhất quán nội bộ.

Người đánh giá xác định rằng trong tất cả các cơ hội mà tại đó các yêu cầu an toàn khác nhau áp dụng cho cùng một loại bằng chứng của nhà phát triển, các sự kiện, các hoạt động, dữ liệu, kiểm thử được thực hiện v.v.. hoặc "tất cả các đối tượng", "tất cả các mục tiêu" v.v..., mà các yêu cầu không mâu thuẫn.

Một số mâu thuẫn có thể là:

a) SAR mở rộng xác định rằng thiết kế của thuật toán mã hóa cụ thể phải được giữ bí mật và SAR mở rộng khác xác định việc thẩm tra mã nguồn m;

b) FAU_GEN.1 Tạo ra thế hệ dữ liệu kiểm toán xác định rằng danh tính đối tượng để đăng nhập, FDP_ACC.1 Tập con kiểm soát truy nhập xác định những người có quyền truy nhập vào các hồ sơ và FPR_UNO.1 Tính không thể quan sát xác định rng một số hành động của các đối tượng nên có thể không quan sát được các đối tượng khác. Nếu đối tượng đó không thể quan sát một hoạt động có thể truy nhập các hồ sơ của các hoạt động này, các SFR này mâu thuẫn;

c) FDP_RIP.1 Bảo vệ thông tin còn dư thừa của tập con xác định cụ thể việc xóa các thông tin không còn được yêu cầu và FDP_ROL.1 Khôi phục cơ bản xác định rằng một TOE có th tr lại trạng thái trước đó. Nếu thông tin đó là được yêu cầu cho việc khôi phục trạng thái trước đó đã bị xóa, các yêu cầu này mâu thuẫn;

d) nhiều phép lặp của FDP_ACC.1 Kiểm soát truy nhập của tập con đặc biệt khi số phép lặp bao gồm cùng các đối tượng, mục tiêu hoặc hoạt động. Nếu một SFR kiểm soát truy nhập cho phép đối tượng thực hiện hoạt động trên mục tiêu, trong khi một SFR khác kiểm soát truy nhập không cho phép, các yêu cầu này mâu thuẫn.

9.8.2  Đánh giá hoạt động con (ASE_REQ.2)

9.8.2.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu các SFR và SAR có rõ ràng, mạch lạc và được xác định rõ ràng không, liệu chúng có nhất quán nội bộ không và liệu các SFR có đáp ứng các mục tiêu an toàn của TOE không.

9.8.2.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) ST.

9.8.2.3  Hành động ASE_REQ.2.1E

TCVN 8709-3 (ISO/IEC 15408-3) ASE_REQ.2.1C: Tuyên bố các yêu cầu an toàn cần mô tả các SFR và SAR.

9.8.2.3.1  Đơn vị công việc ASE_REQ.2-1

Người đánh giá cần kiểm tra rằng tuyên bố các yêu cầu an toàn mô tả các SFR.

Người đánh giá xác định rằng mỗi SFR được xác định bởi một trong những cách sau đây:

a) bằng cách tham chiếu đến thành phần riêng lẻ trong TCVN 8709-2 (ISO/IEC 15408-2);

b) bằng cách tham chiếu đến thành phần mở rộng trong định nghĩa các thành phần mở rộng của ST;

c) bằng cách tham chiếu đến thành phần riêng lẻ trong PP mà các yêu cầu ST tuân thủ;

d) bằng cách tham chiếu đến thành phần riêng lẻ trong gói các yêu cầu an toàn mà các yêu cầu ST tuân thủ;

e) bằng việc tái sản xuất trong ST.

Không yêu cầu sử dụng cùng một phương tiện nhận dạng cho tất cả các SFR.

9.8.2.3.2  Đơn vị công việc ASE_REQ.2-2

Người đánh giá cần kiểm tra tuyên bố các yêu cầu an toàn mô tả các SAR.

Người đánh giá xác định rằng mỗi SAR được xác định bởi một trong những cách sau đây:

a) bằng cách tham chiếu đến thành phần riêng lẻ trong TCVN 8709-3 (ISO/IEC 15408-3);

b) bằng cách tham chiếu đến thành phần mở rộng trong định nghĩa các thành phần mở rộng của ST;

c) bằng cách tham chiếu đến thành phần riêng lẻ trong PP mà các yêu cầu ST tuân thủ;

d) bằng cách tham chiếu đến thành phần riêng lẻ trong gói các yêu cầu an toàn mà các yêu cầu ST tuân thủ;

e) bằng việc tái sản xuất trong ST.

Không yêu cầu sử dụng cùng một phương tiện nhận dạng cho tất cả các SAR.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_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 thuật ngữ khác được sử dụng trong các SFR và SAR, cần được định nghĩa.

9.8.2.3.3  Đơn vị công việc ASE_REQ.2-3

Người đánh giá cần thẩm tra PP đ xác định rằng 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 thuật ngữ khác được sử dụng trong các SFR và SAR được xác định.

Người đánh giá xác định rằng PP xác định tất cả:

• (các kiểu của) các đối tượng và mục tiêu được sử dụng trong các SFR;

• (các kiểu của) thuộc tính an toàn của các đối tượng, người sử dụng, mục tiêu, thông tin, phiên bản và/hoặc tài nguyên, các giá trị mà thuộc tính này có thể cần và bất kỳ các sở cứ giữa các giá trị này (ví dụ như top_secret là "cao hơn" secret);

• (các kiểu của) các hoạt động được sử dụng trong các SFR, bao gồm c những ảnh hưởng của các hoạt động này;

• (các kiểu của) các thực thể bên ngoài trong SFR;

• các thuật ngữ khác được giới thiệu trong các SFR và/hoặc SAR bằng cách hoàn thành các thao tác, nếu các thuật ngữ này không rõ ràng ngay hoặc được sử dụng bên ngoài định nghĩa từ điển của chúng.

Mục tiêu của đơn vị công việc này là đ đảm bảo rằng các SFR và SAR dễ phân biệt và không gây hiểu lầm có thể xảy ra do việc giới thiệu các thuật ngữ không rõ ràng. Đơn vị công việc này không nên đưa vào giới hạn, bằng cách buộc người viết ST xác định tất cả các từ đơn nhất. Các khán giả chung của tập hợp các yêu cầu an toàn nên được giả thiết có kiến thức hợp lý về công nghệ thông tin, an toàn và "Tiêu chí đánh giá về an toàn công nghệ thông tin".

Tất cả các vấn đề trên có thể được trình bày trong các nhóm, các lớp, các vai trò, kiểu hoặc nhóm khác hoặc đặc trưng khác để cho dễ hiểu.

Người đánh giá được nhắc nhở rằng các danh sách và định nghĩa không phải là một phn của tuyên bố về các yêu cầu an toàn, nhưng có thể được đặt (một phần hoặc toàn bộ) tại các mục khác nhau. Điều này có thể áp dụng đặc biệt nếu các thuật ngữ tương tự được sử dụng trong phần còn lại của ST.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_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 trên các yêu cầu an toàn.

9.8.2.3.4  Đơn vị công việc ASE_REQ.2-4

Người đánh giá cần kiểm tra tuyên bố các yêu cầu an toàn để xác định rằng tất cả các hoạt động trên các yêu cầu an toàn.

Người đánh giá xác định rằng tất cả các hoạt động được xác định trong mỗi SFR hoặc SAR nơi hoạt động được sử dụng. Nhận dng có thể thực hiện được bằng cách phân biệt các bản in hoặc bằng cách xác định tường minh trong các văn bản xung quanh hoặc bằng bất kỳ phương tiện đặc trưng khác.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_REQ.2.4C: Tất cả các hoạt động cần phải được thực hiện đúng.

9.8.2.3.5  Đơn vị công việc ASE_REQ.2-5

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn đ xác định rằng tt cả các hoạt động chỉ định đã thực hiện đúng.

Hướng dẫn thực hiện đúng các hoạt động có thể tìm thấy trong Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

9.8.2.3.6  Đơn vị công việc ASE_REQ.2-6

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng tất cả các hoạt động lặp lại đã được thực hiện đúng.

Hướng dẫn thực hiện đúng các hoạt động có thể tìm thấy trong Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

9.8.2.3.7  Đơn vị công việc ASE_REQ.2-7

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng tất cả các hoạt động lựa chọn đã được thực hiện đúng.

Hướng dẫn thực hiện đúng các hoạt động có thể được tìm thấy trong Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

9.8.2.3.8  Đơn vị công việc ASE_REQ.2-8

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng tất cả các hoạt động bổ sung chi tiết đã được thực hiện đúng.

Hướng dẫn thực hiện đúng các hoạt động có thể được tìm thấy trong Phụ lục 7 TCVN 8709-1 (ISO/IEC 15408-1), Các hoạt động.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_REQ.2.5C: Mỗi sự phụ thuộc của các yêu cầu an toàn cần hoặc thỏa mãn hoặc sở cứ các yêu cầu an toàn cần biện minh sự phụ thuộc còn chưa được thỏa mãn.

9.8.2.3.9  Đơn vị công việc ASE_REQ.2-9

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định rằng mỗi phụ thuộc của các yêu cầu an toàn hoặc thỏa mãn hoặc sở cứ các yêu cầu an toàn biện minh sự phụ thuộc vẫn chưa được thỏa mãn.

Sự phụ thuộc được thỏa mãn bao gồm các thành phần có liên quan (hoặc một trong số đó là phân cấp của nó) trong tuyên bố các yêu cầu an toàn. Thành phần được sử dụng để đáp ứng sự phụ thuộc nên, nếu được yêu cầu, được sửa đổi bởi các hoạt động để đảm bảo rằng nó thỏa mãn đúng sự phụ thuộc đó.

Biện minh sự phụ thuộc không được đáp ứng nên đề cập bằng một trong hai cách sau:

a) lý do tại sao sự phụ thuộc không được yêu cầu hoặc hữu ích, trường hợp nào thông tin không được yêu cầu thêm; hoặc

b) sự phụ thuộc đã được đề cập bởi các môi trường vận hành của TOE, trường hợp nào biện minh nên mô tả các mục tiêu an toàn để môi trường vận hành đề cập sự phụ thuộc này.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_REQ.2.6C: Sở cứ các yêu cầu an toàn cần theo dấu mỗi SFR theo các mục tiêu an toàn cho TOE.

9.8.2.3.10  Đơn vị công việc ASE_REQ.2-10

Người đánh giá cần kiểm tra rằng sở cứ các yêu cầu an toàn theo dấu mỗi SFR đến các mục tiêu an toàn cho TOE.

Người đánh giá xác định rằng mỗi SFR được theo dấu ít nhất một mục tiêu an toàn cho TOE.

Lỗi khi thực hiện theo dấu có nghĩa là sở cứ các yêu cầu an toàn không đầy đủ, các mục tiêu an toàn cho TOE không đầy đủ hoặc SFR không có mục đích hữu ích.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

9.8.2.3.11  Đơn vị công việc ASE_REQ.2-11

Người đánh giá cần thẩm tra sở cứ các yêu cầu an toàn đ xác định rằng mỗi mục tiêu an toàn cho TOE nó biện minh rằng các SFR phù hợp đ đáp ứng mục tiêu an toàn cho TOE.

Nếu các SFR không theo dấu mục tiêu an toàn cho TOE, hành động của người đánh giá liên quan đến đơn vị công việc này được chỉ định là nhận định không đạt.

Người đánh giá xác định rằng biện minh mục tiêu an toàn cho TOE chứng minh rằng các SFR là đầy đủ: nếu tất cả các SFR theo dấu mục tiêu được thỏa mãn thì sẽ đạt được mục tiêu an toàn cho TOE. Người đánh giá cũng xác định rằng mỗi SFR theo dấu mục tiêu an toàn cho TOE là được yêu cầu: khi SFR được thỏa mãn, nó thực sự góp phần vào việc đạt được các mục tiêu an toàn.

Lưu ý rng theo dấu từ các SFR tại các mục tiêu an toàn cho TOE được cung cấp trong sở cứ các yêu cầu an toàn có thể là một phần của một sự biện minh, nhưng không được coi là biện minh của chính nó.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_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.8.2.3.12  Đơn vị công việc ASE_REQ.2-12

Người đánh giá cần kiểm tra sở cứ các yêu cầu an toàn để giải thích tại sao các SAR được lựa chọn. Người đánh giá được nhắc nhở rằng mọi lời giải thích là chính xác, miễn là nó mạch lạc và c các SAR và phần giải thích đều không có sự không nhất quán hiển nhiên với phần còn lại của ST.

Ví dụ sự không nhất quán hin nhiên giữa các SAR và phần còn lại của ST sẽ là các tác nhân đe dọa rất có năng lực, nhưng AVA_VAN SAR không bảo vệ chống lại các tác nhân đe dọa này.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_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.8.2.3.13  Đơn vị công việc ASE_REQ.2-13

Người đánh giá cần thẩm tra tuyên bố của các yêu cầu an toàn để xác định nó có tính nhất quán nội bộ.

Người đánh giá xác định rằng các thiết lập liên hợp của tất cả các SFR và SAR có tính nhất quán nội b.

Người đánh giá xác định rằng trong tất c các cơ hội mà tại đó các yêu cầu an toàn khác nhau áp dụng cho cùng một loại bằng chứng của nhà phát triển, các sự kiện, các hoạt động, dữ liệu, kiểm thử cần được thực hiện v.v.. hoặc "tất cả các đối tượng", "tất cả các mục tiêu" v.v..., mà các yêu cầu không mâu thuẫn.

Một số mâu thuẫn có thể là:

a) một SAR mở rộng xác định rằng thiết kế của thuật toán mã hóa cụ thể phải được giữ bí mật và SAR mở rộng khác xác định một việc soát xét mã nguồn mở;

b) FAU_GEN.1 Tạo ra thế hệ dữ liệu kiểm toán xác định rằng xác định đối tượng cần được đăng nhập, FDP_ACC.1 Tập con kiểm soát truy nhập xác định những người có quyền truy nhập vào các hồ sơ và FPR_UNO.1 Tính không thể quan sát xác định rằng một số hành động của các đối tượng nên có thể không quan sát được các đối tượng khác. Nếu đối tượng đó không thể quan sát một hoạt động có thể truy nhập các hồ sơ của các hoạt động này, các SFR này mâu thuẫn;

c) FDP_RIP.1 Bảo vệ thông tin còn dư thừa của tập con xác định cụ thể việc xóa các thông tin không còn được yêu cầu và FDP_ROL.1 Khôi phục cơ bản xác định rằng một TOE có thể trở lại trạng thái trước đó. Nếu thông tin đó là được yêu cầu cho việc khôi phục trạng thái trước đó đã bị xóa, các yêu cầu này mâu thuẫn;

d) nhiều phép lặp của FDP_ACC.1 Kiểm soát truy nhập của tập con đặc biệt khi số phép lặp bao gồm cùng các đối tượng, mục tiêu hoặc hoạt động. Nếu một SFR kiểm soát truy nhập cho phép đối tượng thực hiện hoạt động trên mục tiêu, trong khi một SFR khác kiểm soát truy nhập không cho phép, các yêu cầu này mâu thuẫn.

9.9  Đặc t tng quát TOE (ASE_TSS)

9.9.1  Đánh giá hoạt động con (ASE_TSS.1)

9.9.1.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu đặc tả tổng quát TOE có đề cập đến tất cả các SFR không và liệu đặc tả tổng quát TOE có nhất quán với các mô tả tường thuật khác của TOE không.

9.9.1.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) ST.

9.9.1.3  Hành động ASE_TSS.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) 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.

9.9.1.3.1  Đơn vị công việc ASE_TSS.1-1

Người đánh giá cần thẩm tra đặc tả tổng quát TOE để xác định rằng nó mô tả TOE đáp ứng mỗi SFR như thế nào.

Người đánh giá xác định rằng các đặc tả tổng quát TOE cung cấp, đối với mỗi SFR từ tuyên bố các yêu cầu an toàn, sự mô tả cách mà SFR đáp ứng.

Người đánh giá cần nhớ rằng mục tiêu của từng mô t là cung cấp cho khách hàng tiềm năng của TOE một cái nhìn ở mức cao cách mà các nhà phát triển làm bn sao thỏa mãn mỗi SFR và các mô t do đó không nên quá chi tiết.

Đối với một TOE tổng hợp, người đánh giá cũng xác định rằng nó là thành phần rõ ràng cung cấp mỗi SFR hoặc cách mà các thành phần kết hợp để đáp ứng mỗi SFR.

9.9.1.4  Hành động ASE_TSS.1.2E

9.9.1.4.1  Đơn vị công việc ASE_TSS.1-2

Người đánh giá cần thẩm tra đặc tả tổng quát TOE để xác định rằng nó nhất quán với tổng quan TOE và mô tả TOE.

Tổng quan TOE, mô tả TOE và đặc tả tổng quát TOE mô tả TOE dưới dạng tường thuật là tăng mức độ chi tiết. Do đó, những mô tả này cần phải nhất quán.

9.9.2  Đánh giá hoạt động con (ASE_TSS.2)

9.9.2.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu đặc tả tổng quát TOE có đề cập đến tất cả các SFR không, liệu đặc tả tổng quát TOE có đề cập đến sự can thiệp, sự giả mạo mức logic và sự b bỏ qua không và liệu đặc tả tổng quát TOE có nhất quán với các mô tả tường thuật khác của TOE không.

9.9.2.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) ST.

9.9.2.3  Hành động ASE_TSS.2.1E

TCVN 8709-3 (ISO/IEC 15408-3) 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.

9.9.2.3.1  Đơn vị công việc ASE_TSS.2-1

Người đánh giá cần thẩm tra đặc tả tổng quát TOE để xác định rằng nó mô tả TOE đáp ứng mỗi SFR như thế nào.

Người đánh giá xác định rằng các đặc tả tổng quát TOE cung cấp, đối với mỗi SFR từ tuyên bố các yêu cầu an toàn, sự mô tả cách mà SFR đáp ứng.

Người đánh giá cần nhớ rằng mục tiêu của từng mô tả là cung cấp cho khách hàng tiềm năng của TOE một cái nhìn ở mức cao cách mà các nhà phát triển làm bản sao thỏa mãn mỗi SFR và các mô tả do đó không nên quá chi tiết.

Đối với một TOE tổng hợp, người đánh giá cũng xác định rằng nó là thành phần rõ ràng cung cấp mỗi SFR hoặc cách mà các thành phần kết hợp để đáp ứng mỗi SFR.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

9.9.2.3.2  Đơn vị công việc ASE_TSS.2-2

Người đánh giá cần thẩm tra đặc tả tổng quát TOE để xác định rằng nó mô tả làm thế nào TOE tự bảo vệ chống lại sự can thiệp và giả mạo mức logic

Người đánh giá cần nhớ rằng mục tiêu của từng mô tả là cung cấp cho người tiêu dùng tiềm năng của TOE có một cái nhìn ở mức cao cách mà các nhà phát triển định cung cấp sự bảo vệ chống lại sự can thiệp và sự giả mạo mức logic và các mô tả do đó không nên quá chi tiết.

Đối với một TOE tổng hợp, người đánh giá cũng xác định rằng nó là thành phần rõ ràng cung cấp sự bảo vệ hoặc cách mà các thành phần kết hợp để cung cấp sự bảo vệ.

TCVN 8709-3 (ISO/IEC 15408-3) ASE_TSS.2.3C: Đặ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ự bị bỏ qua.

9.9.2.3.3  Đơn vị công việc ASE_TSS.2-3

Người đánh giá cần thẩm tra đặc tả tổng quát TOE để xác định rằng nó mô tả cách mà TOE tự bảo vệ chống lại sự bị bỏ qua.

Người đánh giá cần nhớ rằng các mục tiêu của từng mô tả là cung cấp cho người tiêu dùng tiềm năng của TOE với một cái nhìn ở mức cao cách mà các nhà phát triển định cung cấp sự bảo vệ chống lại sự bị bỏ qua và các mô tả do đó không nên quá chi tiết.

Đối với một TOE tng hợp, người đánh giá cũng xác định rằng nó là thành phần rõ ràng cung cấp sự bảo vệ hoặc cách mà các thành phần kết hợp đ cung cấp sự bảo vệ.

9.9.2.4  Hành động ASE_TSS.2.2E

9.9.2.4.1  Đơn vị công việc ASE_TSS.2-4

Người đánh giá cần thẩm tra đặc tả tổng quát TOE để xác định rằng nó nhất quán với tổng quan TOE và mô t TOE.

Tổng quan TOE, mô tả TOE và đặc tả tổng quát TOE mô tả TOE trong hình thức tường thuật là tăng cường mức độ chi tiết. Do đó, những mô tả này cần phải nhất quán.

10  Lớp ADV: Phát triển

10.1  Giới thiệu

Mục đích của các hoạt động phát triển là đánh giá tài liệu thiết kế về phương diện sự thích hợp của nó để hiểu làm thế nào TSF đáp ứng các SFR và làm thế nào triển khai các SFR này mà không bị giả mạo hoặc bị bỏ qua. Sự hiểu biết này có thể đạt được thông qua thẩm tra các mô tả ngày càng tinh tế của tài liệu thiết kế TSF. Tài liệu thiết kế bao gồm đặc tả chức năng (trong đó mô tả các giao diện của TSF), mô tả thiết kế TOE (trong đó mô tả kiến trúc của TSF xét về cách thức hoạt động để thực hiện các chức năng liên quan đến các SFR được yêu cầu) và mô tả triển khai (mô tả mức mã ngun). Ngoài ra, có một mô tả kiến trúc an toàn (trong đó mô tả các đặc tính kiến trúc của TSF để giải thích cách thực thi an toàn của nó không thể b can thiệp hoặc bị bỏ qua), mô tả nội bộ (trong đó mô tả như thế nào để TSF được kết cấu một cách dễ hiểu được khuyến khích) và một mô hình chính sách an toàn (trong đó chính thức mô tả các chính sách an toàn được thực thi bởi TSF).

10.2  Lưu ý áp dụng

Các yêu cầu của TCVN 8709 (ISO/IEC 15408) đối với tài liệu thiết kế là bình đẳng v số lượng và chi tiết của thông tin được cung cấp và mức độ hình thức của việc trình bày các thông tin. Ở cấp độ thấp hơn, phần giới hạn an toàn cao hơn của TSF được mô tả chi tiết hơn, trong khi phần giới hạn an toàn thấp hơn của TSF chỉ được tóm tắt; cộng thêm sự đảm bảo đạt được bằng cách tăng số lượng thông tin phần giới hạn an toàn cao hơn của TSF và tăng các chi tiết các phần giới hạn an toàn thấp hơn. Sự bảo đảm hơn có thể đạt được khi thông qua các chi tiết và thông tin của tất cả các phần được cung cấp.

TCVN 8709 (ISO/IEC 15408) cho rằng mức độ của một tài liệu về hình thức (có nghĩa là, nó chưa chính thức hoặc bán chính thức) được phân cấp. Tài liệu không chính thức là tài liệu được thể hiện bằng một ngôn ngữ tự nhiên. Phương pháp luận này không bắt buộc phải sử dụng một ngôn ngữ cụ thể; vấn đề này dành cho lược đồ. Các phần tiếp theo phân biệt nội dung của các tài liệu không chính thức khác nhau.

Đặc tả chức năng cung cấp mô tả về mục đích và phương pháp sử dụng giao diện của TSF. Ví dụ, nếu hệ điều hành cung cấp cho người sử dụng các phương tiện tự định danh, tạo tập tin, sửa đổi hoặc xóa tập tin, thiết lập cho phép xác định những gì người dùng khác có thể truy nhập đến các tập tin và giao tiếp với các máy từ xa, đặc tả chức năng của nó sẽ chứa các mô tả của một trong số này và cách chúng được thực hiện thông qua các tương tác với các giao diện có thể nhìn thấy bên ngoài TSF. Nếu cũng có chức năng kiểm toán mà phát hiện và ghi lại các lần xuất hiện của sự kiện như vậy, mô tả chức năng kiểm toán này cũng được dự kiến là một phần của đặc tả chức năng; trong khi chức năng này là kỹ thuật không trực tiếp được gọi đến bởi người dùng ở giao diện bên ngoài, nó chắc chắn bị ảnh hưởng bởi những gì xảy ra tại giao diện bên ngoài của người dùng.

Mô tả thiết kế được thể hiện trong thuật ngữ các phân chia theo logic (hệ thống con hoặc mô đun) mà mỗi cung cấp có thể bao hàm dịch vụ hoặc chức năng. Ví dụ, tường lửa có thể tổng hợp các hệ thống con đ đối phó với việc lọc gói, với quản trị từ xa, với kiểm toán và với bộ lọc kết nối mức. Mô tả thiết kế của tường la sẽ mô tả các hành động được thực hiện, trong thuật ngữ các hành động nào mà mỗi hệ thống con thực hiện khi đi đến gói tại tường lửa.

10.3  Kiến trúc an toàn (ADV_ARC)

10.3.1  Đánh giá hoạt động con (ADV_ARC.1)

10.3.1.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu TSF có được cấu trúc như nó không bị giả mạo hoặc bị bỏ qua không và liệu các TSF có cung cấp các miền an toàn cách ly với các miền khác không.

10.3.1.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) đặc tả chức năng;

c) thiết kế TOE;

d) mô tả kiến trúc an toàn;

e) biểu diễn triển khai (nếu có);

f) hướng dẫn người sử dụng vận hành.

10.3.1.3  Lưu ý áp dụng

Các thuộc tính tự bảo vệ, phân cách miền và kh năng không đi vòng được phân biệt với chức năng an toàn thể hiện trong Phần 2 SFR vì tự bảo vệ và khả năng không đi vòng phần lớn không có giao diện trực tiếp có thể quan sát tại các TSF. Thay vào đó, chúng là thuộc tính của TSF đạ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ế đó. Ngoài ra, việc đánh giá các đặc tính này ít thuận lợi hơn so với đánh giá các cơ chế; kiểm tra sự không có chức năng thường khó khăn hơn kiểm tra sự hiện diện của chức năng. Tuy nhiên, việc xác định các đặc tính này đang được cho là thỏa mãn cũng quan trọng không kém gì việc xác định các cơ chế được triển khai một cách thích đáng.

Cách tiếp cận tổng thể được sử dụng là do nhà phát triển cung cấp TSF đáp ứng các đặc tính nêu trên và cung cấp bằng chứng (dưới dạng tài liệu) có thể được phân tích để thấy rằng tài sản thực sự được đáp ứng. Người đánh giá có trách nhiệm thẩm tra các bằng chứng và kết hợp với các bằng chứng khác dành cho TOE, xác định bằng chứng đạt được. Các đơn vị công việc có thể được mô tả dưới dạng những đơn vị công việc được chi tiết cùng với những thông tin phải được cung cấp và những đơn vị công việc giải quyết các phân tích thực tế mà người đánh giá thực hiện.

Mô tả kiến trúc an toàn là mô tả làm thế nào các miền được xác định và làm thế nào TSF giữ được nét riêng biệt của nó. Nó mô tả những gì ngăn cản quá trình không tin cậy đến được TSF và sửa đổi nó. Nó mô tả những gì đảm bảo rằng tất cả các nguồn tài nguyên dưới sự kiểm soát của TSF được bảo vệ đầy đủ và rng tất cả các hành động liên quan đến các SFR đã được sắp xếp bởi TSF. Nó giải thích bất kỳ vai trò của môi trường vận hành trong mỗi điều này (ví dụ: giả s nó được gọi đến chính xác bởi môi trường cơ bản của nó, làm thế nào gọi đến chức năng an toàn của nó?). Nói ngắn gọn là nó giải thích cách mà TOE được coi là cung cấp bất kỳ loại dịch vụ "an toàn" nào.

Thực hiện của người đánh giá về phân tích phải được thực hiện trong bối cnh tất cả các bằng chứng phát triển cung cấp cho các TOE ở mức cung cấp chi tiết các bằng chứng, ở các mức độ đảm bảo thấp hơn không nên kỳ vọng, ví dụ, TSF tự bảo vệ được phân tích hoàn toàn, bởi vì ch có đại diện thiết kế cao cấp mới được cung cấp. Người đánh giá cũng cần phải chắc chắn sử dụng thông tin thu được từ các phần khác của phân tích của họ (ví dụ, phân tích thiết kế TOE) trong việc tạo ra đánh giá của họ đối với tài sản được thẩm tra trong các đơn vị công việc sau đây.

10.3.1.4  Hành động ADV_ARC.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) 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 tóm tắt thực thi SFR được mô tả trong tài liệu thiết kế TOE.

10.3.1.4.1  Đơn vị công việc ADV_ARC.1-1

Người đánh giá cần thẩm tra mô tả kiến trúc an toàn để xác định rằng các thông tin đã cung cấp trong các bằng chứng được trình bày tại mức độ chi tiết tương xứng với mô tả tóm tắt thực thi SFR có trong các đặc tả chức năng và tài liệu thiết kế TOE.

Đối với các đặc tả chức năng, người đánh giá cần đảm bảo rằng các chức năng tự bảo vệ được mô tả bao gồm các tác động được thể hiện rõ ở TSFI. Mô tả như vậy có thể bao gồm việc bảo vệ dựa trên những hình ảnh có thể thực thi của TSF và bảo vệ lên các đối tượng (ví dụ, các tập tin được sử dụng bởi TSF). Người đánh giá đảm bảo rằng các chức năng có thể được viện dẫn thông qua các TSFl cần được mô tả.

Nếu đánh giá của các hoạt động con (ADV_TDS.1) bao gồm cả đánh giá của các hoạt động con (ADV_TDS.2), người đánh giá đảm bảo mô tả kiến trúc an toàn chứa thông tin làm thế nào các hệ thống con góp phần vào việc phân cách miền TSF.

Nếu đánh giá của các hoạt động con (ADV_TDS.3) hoặc cao hơn có sẵn, người đánh giá đảm bảo rằng các mô tả kiến trúc an toàn cũng chứa thông tin triển khai phụ thuộc. Ví dụ, mô tả như vậy có thể có những thông tin liên quan đến quy ước mã hóa cho các tham số thẩm tra có thể ngăn ngừa thỏa hiệp TSF (ví dụ như lỗi tràn bộ đệm) và thông tin về qun lý ngăn xếp cho các hoạt động gọi và gọi lại. Người đánh giá kiểm tra các mô tả của các cơ chế để đảm bảo rằng mức chi tiết như vậy là rõ ràng giữa mô tả trong mô tả kiến trúc an toàn và các biểu diễn triển khai.

Các hành động đánh giá liên quan đến đơn vị công việc này được chỉ định nhận định không đạt nếu mô tả kiến trúc an toàn đề cập đến bất kỳ mô đun, hệ thống con hoặc giao diện mà không được mô tả trong các đặc tả chức năng hoặc tài liệu thiết kế TOE.

TCVN 8709-3 (ISO/IEC 15408-3) 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 bởi sự nhất quán của TSF so với SFR.

10.3.1.4.2  Đơn vị công việc ADV_ARC.1-2

Người đánh giá cần thẩm tra mô tả kiến trúc an toàn để xác định rằng nó mô tả việc bảo trì các miền an toàn bởi các TSF.

Các miền an toàn đề cập đến môi trường được cung cấp bởi các TSF đ sử dụng với các thực thể có khả năng gây hại; Ví dụ, một hệ thống điều hành an toàn điển hình cung cấp một tập hợp các tài nguyên (không gian địa chỉ, tham số môi trường tiền tiến trình) để sử dụng các tiến trình với quyn truy nhập hạn chế và tài sản an toàn. Người đánh giá xác định rằng mô tả của nhà phát triển trong các miền an toàn có tính đến tài khoản bất kỳ của các SFR được yêu cầu bởi TOE.

Đối với một số TOE không tồn tại các miền như vậy bởi vì tất cả các tương tác có sẵn cho người dùng bị hạn chế khắt khe bởi TSF. Tường lửa bộ lọc - gói là ví dụ của một TOE như vậy. Người sử dụng LAN và WAN không tương tác được với các TOE, do đó không được yêu cầu có miền an toàn; ch có cấu trúc dữ liệu được bảo trì bởi TSF để giữ các gói tin của người sử dụng tách biệt nhau. Người đánh giá đảm bảo rằng bất kỳ yêu cầu mà không có các miền được hỗ trợ bởi các bằng chứng và không có các miền như vậy có sẵn trên thực tế.

TCVN 8709-3 (ISO/IEC 15408-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.

10.3.1.4.3  Đơn v công việc ADV_ARC.1-3

Người đánh giá cần thẩm tra mô tả kiến trúc an toàn để xác định rằng tiến trình khi tạo duy trì an toàn.

Thông tin được cung cấp trong mô tả kiến trúc an toàn liên quan đến khi tạo TSF được hướng dẫn tại các thành phần TOE có liên quan trong việc đưa TSF về trạng thái an toàn ban đầu (nghĩa là khi tất cả các phần của TSF đang vận hành) khi bật nguồn hoặc thiết lập lại được áp dụng. Thảo luận này trong phần mô tả kiến trúc an toàn nên liệt kê các thành phần khởi tạo hệ thống và việc xử lý khi xuất hiện chuyển trạng thái từ "giảm bớt" về trạng thái an toàn ban đầu.

Trường hợp thường xy ra là các thành phần thực hiện chức năng khởi tạo này không thể truy nhập sau khi thực hiện trạng thái an toàn; nếu đây là trường hợp đó, mô tả kiến trúc an toàn xác định các thành phần và giải thích làm thế nào chúng không thể truy nhập do các thực thể không tin cậy sau khi TSF đã được thiết lập. Về mặt này, đặc tính cần được lưu giữ là các thành phần này hoặc là 1) không thể truy nhập bởi các thực thể không tin cậy sau khi trạng thái an toàn được thực hiện hoặc là 2) nếu chúng cung cấp các giao diện cho các thực thể đáng tin cậy, TSFI này có thể không được sử dụng để làm giả TSF.

Các thành phần TOE liên quan đến khởi tạo TSF, khi ấy, được xem xét là một phần của TSF và được phân tích từ quan điểm đó. Cần lưu ý rằng mặc dù chúng được coi là một phần của TSF, nó có kh năng là một sự biện minh (như cho phép của nội bộ TSF (ADV_INT)) có thể được thực hiện khi chúng không đáp ứng các yêu cầu cơ cấu nội bộ của ADV_INT.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_ARC.1.4C: Mô tả kiến trúc an toàn cần chứng minh rng TSF bảo vệ chính nó từ sự giả mạo.

10.3.1.4.4  Đơn v công việc ADV_ARC.1-4

Người đánh giá cần thẩm tra mô tả kiến trúc an toàn để xác định rằng nó chứa đầy đủ thông tin để hỗ trợ việc xác định rằng TSF có thể tự bảo vệ chính nó từ sự giả mạo của các thực thể hoạt động không tin cậy.

"Tự bo vệ" đề cập đến khả năng của TSF tự bảo vệ chính nó từ thao tác của các thực thể bên ngoài mà có thể dẫn đến những thay đổi trong TSF. Đối với các TOE có phụ thuộc vào các thực thể công nghệ thông tin khác, thường xảy ra trường hợp TOE sử dụng các dịch vụ được cung cấp bởi các thc thể công nghệ thông tin khác để thực hiện các chức năng của mình. Trong trường hợp này, một mình TSF không tự bảo vệ chính nó vì nó phụ thuộc vào các thực thể công nghệ thông tin khác đ cung cấp một số sự bảo vệ. Theo mục đích của mô tả kiến trúc an toàn, quan niệm về tự bảo vệ chỉ áp dụng cho các dịch vụ được cung cấp bởi các TSF qua TSFI của nó và không để các dịch vụ được cung cấp bởi các thực thể công nghệ thông tin cơ bản mà nó sử dụng.

Tự bảo vệ thường được thực hiện bằng nhiều phương thức khác nhau, từ những hạn chế vật lý và logic về truy nhập TOE; các phương thức dựa trên phần cứng (ví dụ như "các vòng thực hiện" và chức năng quản lý bộ nhớ); phương thức dựa trên phần mềm (ví dụ như thẩm tra ranh giới của các đầu vào trên một máy chủ đáng tin cậy). Người đánh giá xác định rằng tất cả các cơ chế như vậy cần được mô tả.

Người đánh giá xác định rằng các mô tả thiết kế bao gồm làm thế nào đầu vào người sử dụng được xử lý bởi các TSF theo cách mà TSF không bị hng bởi đầu vào người sử dụng. Ví dụ, TSF có thể triển khai các khái niệm đặc quyền và tự bảo vệ chính nó bằng cách sử dụng thủ tục chế độ đặc quyền để xử lý người sử dụng. TSF có thể sử dụng các cơ chế phân chia dựa trên bộ vi xử lý như các mức hoặc các vòng đặc quyền. TSF có thể thực thi các kết cấu bảo vệ phần mềm hoặc các quy ước mã hóa góp phần thực hiện phân chia các miền phần mềm bằng cách phân định không gian địa chỉ người sử dụng từ không gian địa chỉ hệ thống. TSF có thể phụ thuộc môi trường của nó đ cung cấp một số hỗ trợ cho việc bảo vệ của TSF.

Tất cả các cơ chế góp phần vào các chức năng phân cách miền đã được mô tả. Người đánh giá cần sử dụng kiến thức thu được từ các bằng chứng khác (đặc tả chức năng, thiết kế TOE, mô tả bên trong TSF, các bộ phận khác của mô tả kiến trúc an toàn hoặc biểu diễn triển khai, như có trong gói đảm bảo cho TOE) trong việc xác định nếu có chức năng đóng góp vào tự bảo vệ được mô tả mà không hiện diện trong mô tả kiến tc an toàn.

Độ chính xác của các mô tả trong cơ chế tự bảo vệ là đặc tính mà đặc tả chung mô tả những gì đã triển khai. Người đánh giá nên sử dụng các bằng chứng khác (đặc tả chức năng, thiết kế TOE, tài liệu nội bộ của TSF, các thành phần khác của mô tả kiến trúc an toàn, biểu diễn triển khai, như có trong ST của TOE) trong việc xác định liệu có sự khác biệt trong bất kỳ mô tả của các cơ chế tự bảo vệ không. Nếu biểu diễn triển khai (ADV_IMP) được chứa trong gói đảm bảo của TOE, người đánh giá sẽ chọn một mẫu biểu diễn triển khai; người đánh giá cũng nên đảm bảo rằng mô tả là chính xác đối với các mẫu lựa chọn. Nếu người đánh giá không thể hiểu làm thế nào các cơ chế tự bảo vệ làm việc hoặc có thể làm việc trong kiến trúc hệ thống, trong trường hợp này mô tả là không chính xác.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_ARC.1.5C: Mô tả kiến trúc an toàn cần chứng minh rằng TSF phòng chống việc vượt qua của chức năng thực thi SFR.

10.3.1.4.5  Đơn vị công việc ADV_ARC.1-5

Người đánh giá cần thẩm tra mô tả kiến trúc an toàn để xác định rằng nó trình bày phân tích mô tả đầy đủ làm thế nào các cơ chế "thực thi SFR" không thể bị vượt qua.

Khả năng không đi vòng là một đặc tính chức năng an toàn của TSF (theo quy định của SFR) luôn luôn gọi đến. Ví dụ, nếu kiểm soát truy nhập vào các tập tin được quy định như khả năng của TSF qua SFR, ở đây không có giao diện thông qua các tập tin có thể được truy nhập mà không gọi đến cơ chế kiểm soát truy nhập của các TSF (chẳng hạn như giao diện thông qua đó truy nhập đĩa chưa xử lý tiếp tục diễn ra).

Mô tả làm thế nào các cơ chế TSF không thể vượt qua thường yêu cầu lập luận có hệ thống dựa trên TSF và các TSFl. Các mô tả làm thế nào TSF làm việc (có trong các bằng chứng phân tích thiết kế, chẳng hạn như đặc tả chức năng, tài liệu thiết kế TOE) - cùng với các thông tin trong TSS - cung cấp nền tảng được yêu cầu cho việc đánh giá để hiu những gì các nguồn lực đang được bảo vệ và những gì chức năng an toàn đang được cung cấp. Đặc tả chức năng cung cấp mô tả của các các TSFI thông qua đó các nguồn lực/chức năng được truy cập.

Người đánh giá đánh giá mô tả đã cung cấp (và các thông tin khác được cung cấp bởi nhà phát triển, chẳng hạn như đặc tả chức năng) để đảm bảo rằng không có giao diện có sẵn có thể được sử dụng để vượt qua các TSF. Điều này có nghĩa là tất cả các giao diện có sẵn phải không liên quan đến các SFR được yêu cầu trong ST (và không tác động tới bất cứ điều gì được sử dụng để đáp ứng các SFR) hoặc nếu không sử dụng các chức năng an toàn được mô tả trong bằng chứng phát triển khác theo cách mô tả. Ví dụ, một trò chơi có thể sẽ không liên quan đến các SFR, vì vậy phải có lời giải thích làm thế nào nó không ảnh hưởng đến an toàn. Tuy nhiên, truy nhập vào dữ liệu người dùng có thể có liên quan đến các SFR kiểm soát truy cập, vì vậy việc giải thích sẽ mô tả làm thế nào các chức năng an toàn làm việc khi được gọi đến thông qua các giao diện dữ liệu truy cập. Mô tả như vậy là được yêu cầu cho tất cả các giao diện có sẵn.

Ví dụ về mô tả sau. Giả sử TSF cung cấp bảo vệ tập tin. Hơn nữa giả sử rằng mặc dù hệ thống "truyền thống" gọi các TSFI để m, đọc, viết gọi đến các cơ chế bảo vệ tập tin được mô tả trong thiết kế TOE, tồn tại ở đó TSFI cho phép truy nhập đến chức năng công việc theo khối (tạo ra công việc theo khi, xóa công việc, thay đổi công việc chưa qua xử lý). Người đánh giá có thể nên xác định từ mô tả của nhà cung cấp với điều kiện là TSFI này gọi đến các cơ chế bảo vệ tương tự như thực hiện các giao diện "truyền thống". Điều này có thể được thực hiện, ví dụ, bằng cách tham khảo các mục phù hợp của thiết kế TOE thảo luận làm thế nào chức năng công việc theo khối của TSFI đạt được các mục tiêu an toàn của nó.

Sử dụng cùng ví dụ trên, giả sử có một TSFl với mục đích duy nhất là để hiển thị thời gian trong ngày. Người đánh giá nên xác định rằng sự mô tả lập luận đầy đủ rằng TSFI này không có khả năng thao tác với bất kỳ tài nguyên được bảo vệ và không gọi đến bất kỳ chức năng an toàn nào.

Một ví dụ khác về vượt qua là khi TSF được cho là phải bảo trì tính bảo mật của một khóa mật mã (cho phép sử dụng nó cho các hoạt động mật mã, nhưng không cho phép đọc/ghi nó). Nếu người tấn công có thể truy nhập vật lý trực tiếp vào thiết bị, họ có thể thẩm tra các kênh phụ như việc sử dụng nguồn của thiết bị, thời gian chính xác của thiết bị hoặc thậm chí bất kỳ phát xạ điện từ của các thiết bị và từ đó suy ra chìa khóa.

Nếu như các kênh phụ có thể xuất hiện, minh chứng nên giải quyết các cơ chế ngăn chặn các kênh phụ xuất hiện, chẳng hạn như đồng hồ nội bộ ngẫu nhiên, công nghệ dual-line v.v...Việc xác nhận các cơ chế này sẽ được xác nhận qua sự kết hợp hoàn toàn vào lập luận dựa trên thiết kế và kim thử.

Ví dụ cuối cùng sử dụng chức năng an toàn chứ không phải là nguồn tài nguyên được bảo vệ, giả sử một ST có chứa FCO_NRO.2 Buộc tuân theo bằng chứng về nguồn gốc, yêu cầu TSF cung cấp bằng chứng về nguồn gốc với nhiều loại thông tin quy định tại ST. Giả sử rằng "các loại thông tin" bao gồm tất cả các thông tin được gửi bởi TOE qua thư điện tử. Trong trường hợp này người đánh giá nên thẩm tra các mô tả để đảm bảo rng tất cả TSFl có thể được gọi đến để gửi qua thư điện tử thực hiện chức năng "bằng chứng về hệ nguồn gốc" là chi tiết. Mô tả có thể chỉ để hướng dẫn người sử dụng đến tất cả các địa điểm nơi mà thư điện tử có thể bắt nguồn (ví dụ, chương trình thư điện tử, thông báo từ các kịch bản/các công việc theo khối) và sau đó làm thế nào mỗi địa điểm này gọi đến chức năng hệ bằng chứng.

Người đánh giá cũng nên đảm bảo rằng các mô tả là toàn diện, trong đó mỗi giao diện được phân tích đối với toàn bộ các SFR yêu cầu. Điều này có thể yêu cầu người đánh giá thẩm tra thông tin hỗ trợ (đặc tả chức năng, thiết kế TOE, các thành phần khác của mô tả kiến trúc an toàn, Hướng dẫn người sử dụng vận hành và có lẽ ngay cả các biểu diễn triển khai theo quy định TOE) để xác định sự mô tả chính xác nắm bắt tất cả các phương diện của giao diện. Người đánh giá nên thẩm tra những gì các SFR tại mỗi TSFI có thể ảnh hưởng (từ mô tả của TSFI và triển khai nó trong các tài liệu hỗ trợ) và sau đó thẩm tra các mô tả để xác định xem nó bao trùm những phương diện gì.

10.4  Đặc tả chức năng (ADV_FSP)

10.4.1  Đánh giá hoạt động con (ADV_FSP.1)

10.4.1.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu các nhà phát triển có cung cấp mô tả mức cao của ít nhất là các TSFI của thực thi SFR và hỗ trợ SFR trong mô tả các thuật ngữ các thông số của chúng không. Không có yêu cầu khác về bằng chứng có thể được dự kiến có thể có sẵn để đo độ chính xác của những mô tả này; người đánh giá chỉ đơn thuần là đảm bảo các mô tả hợp lý.

10.4.1.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) các đặc tả chức năng;

c) hướng dẫn người sử dụng vận hành.

10.4.1.3  Hành động ADV_FSP.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) ADV_FSP.1.1C: Đặc tả chức năng cn 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.

10.4.1.3.1  Đơn vị công việc ADV_FSP.1-1

Người đánh giá cn thẩm tra các đặc tả chức năng đ xác định rằng trạng thái mục tiêu trong mỗi TSFI của hỗ trợ SFR và thực thi SFR.

Mục tiêu của TSFI là tuyên bố khái quát tóm tắt chức năng được cung cấp bởi giao diện. Nó không có ý định tuyên bố tính hoàn thiện của các hành động và kết quả liên quan đến giao diện, mà đúng hơn là một tuyên bố giúp cho người đc hiểu được khái quát những gì giao diện có ý định sử dụng. Người đánh giá không nên ch xác định mục đích tồn tại, mà còn là phản ánh chính xác TSFI bằng cách đưa vào tài khoản các thông tin khác về giao diện, như mô tả các thông số; điều này có thể được thực hiện kết hợp với các đơn vị công việc khác của thành phần này.

Nếu một hành động có sẵn thông qua giao diện đóng một vai trò trong việc thực thi các chính sách an toàn trên TOE (có nghĩa là, nếu một trong các hành động của giao diện có thể được truy nguồn từ một trong những SFR áp dụng cho TSF), sau đó giao diện thực thi SFR. Các chính sách này không giới hạn các chính sách kiểm soát truy cập, nhưng cũng đề cập đến chức năng bất kỳ xác định bởi một trong những SFR có trong ST. Lưu ý rằng nó có thể xảy ra vì giao diện có thể có những hành động và các kết quả khác nhau, một số trong đó có thể thực thi SFR và một số có thể không.

Các giao diện (hoặc hành động có sẵn thông qua một giao diện liên quan) hành động cái mà chức năng thực thi SFR phụ thuộc vào, nhưng chỉ chức năng chính xác để cho các chính sách an toàn của TOE được lưu giữ, được gọi là hỗ trợ SFR. Các giao diện hành động mà chức năng thực thi SFR không phụ thuộc được gọi là không can thiệp SFR.

Cần lưu ý rằng để cho một giao diện hỗ trợ SFR hoặc không can thiệp SFR nó phải không có các hành động hay các kết quả thực thi SFR. Ngược lại, một giao diện thực thi SFR có thể có những hành động hỗ trợ SFR (ví dụ, khả năng thiết lập đồng hồ hệ thống có thể là một hành động 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 thì hành động ch có thể được hỗ trợ SFR). Một ví dụ về một giao diện hỗ trợ SFR hoàn toàn là giao diện gọi hệ thống được sử dụng bởi c người sử dụng không tin cậy và một phần của TSF đang chạy trong chế độ người dùng.

cấp độ này, nhà phát triển có thể sẽ không nỗ lực đã mở rộng nhãn giao diện như thực thi SFR và hỗ trợ SFR. Trong trường hợp này khi đã được thực hiện, người đánh giá cần xác minh đạt đến mức mà tài liệu hỗ trợ (ví dụ, hướng dẫn người sử dụng vận hành) cho phép xác định điều này là đúng. Lưu ý rằng hoạt động xác định này là được yêu cầu cho một số đơn vị công việc cho thành phần này. Thông thường, nhà phát triển không dán nhãn các giao diện, người đánh giá phải thực hiện xác định riêng của họ về giao diện đầu tiên và sau đó xác định liệu các thông tin được yêu cầu (đối với đơn vị công việc này, mục đích) có tồn tại. Một lần nữa, vì thiếu các bằng chứng hỗ trợ về nhận dạng này sẽ rất khó khăn và đảm bảo thấp dù tất cả các giao diện phù hợp đã được xác định một cách chính xác, nhưng dù sao người đánh giá đã thẩm tra các bằng chứng khác đối với TOE để đảm bảo vùng hoạt động hoàn thành tốt.

10.4.1.3.2  Đơn vị công việc ADV_FSP.1-2

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định rằng phương pháp sử dụng cho mỗi TSFI của hỗ trợ SFR và thực thi SFR đã định sẵn.

Xem đơn vị công việc ADV_FSP.1-1 với lập luận để xác định TSFI của hỗ trợ SFR và thực thi SFR.

Phương pháp sử dụng cho TSFl tóm tắt làm thế nào giao diện được thao tác đ gọi đến các hành động và đạt được các kết quả liên quan đến TSFI. Người đánh giá nên xác định, từ việc đọc tài liệu này trong đặc tả chức năng, làm sao để sử dụng mỗi giao diện. Điều này không có nghĩa là cần phải có một phương pháp riêng biệt sử dụng cho mỗi TSFI, vì nó có thể mô tả khái quát làm thế nào các cuộc gọi cốt lõi được gọi đến, ví dụ và khi đó mỗi giao diện xác định sử dụng phong cách chung. Các kiểu giao diện khác nhau sẽ đòi hỏi phương pháp khác nhau của các thông số kỹ thuật sử dụng. Các API, giao diện giao thức mạng, các thông số cấu hình hệ thống, giao diện bus phần cứng, tất cả đều có các phương pháp rất khác nhau để sử dụng và điều này nên được đưa vào tài khoản của các nhà phát triển khi phát triển các đặc tả chức năng, cũng như thẩm định đánh giá các đặc tả chức năng.

Đối với giao diện hành chính mà chức năng của chúng được ghi là không thể tiếp cận với người sử dụng không đáng tin cậy, Người đánh giá đảm bảo rằng phương pháp làm các chức năng không thể tiếp cận được mô tả trong đặc tả chức năng. Cần lưu ý rằng tính năng không thể tiếp cận này cần phải được kiểm thử bởi các nhà phát triển trong bộ phần mềm kiểm thử của họ.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.4.1.3.3  Đơn vị công việc ADV_FSP.1-3

Người đánh giá cần thẩm tra việc trình bày của TSFI để xác định rằng nó nhận dạng tt c các thông số liên quan đến mỗi TSFI của thực thi SFR và hỗ trợ SFR.

Xem đơn vị công việc ADV_FSP.1-1 với lập luận về việc xác định TSFI của hỗ trợ SFR và thực thi SFR.

Người đánh giá thẩm tra đặc tả chức năng để đảm bảo rằng tất cả các tham số được mô tả cho TSFI đã xác định. Các tham số đầu vào và đầu ra rõ ràng trong một giao diện đ kiểm soát hoạt động của giao diện đó. Ví dụ, các thông số là các đối số cung cấp cho API; các lĩnh vực khác nhau trong gói tin cho một giao thức mạng nhất định; các giá trị riêng quan trọng trong Windows Registry; các tín hiệu là một tập hợp của các chân trên một con chip; v.v...

Trong khi khó để có được nhiều đảm bảo rằng tất cả các thông số cho TSFI áp dụng đã được xác định, người đánh giá cũng nên thẩm tra bằng chứng khác được cung cấp cho việc đánh giá (ví dụ, hưng dn người sử dụng vận hành) để xem có hành vi hoặc các tham số bổ sung được mô tả ở đó nhưng không có trong đặc tả chức năng.

TCVN 8709-3 (ISO/IEC 15408-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.

10.4.1.3.4  Đơn vị công việc ADV_FSP.1-4

Người đánh giá cần kiểm tra sở cứ do các nhà phát triển cung cấp cho việc phân loại ngầm định của giao diện như không can thiệp SFR để xác định rằng là chính xác.

Trong trường hợp nơi mà các nhà phát triển cung cấp tài liệu hướng dẫn đầy đủ để thực hiện các phân tích gọi bởi phần còn lại của các đơn vị công việc cho các thành phần này mà không cần xác định một cách rõ ràng giao diện thực thi SFR và hỗ trợ SFR, đơn vị công việc này nên được coi là thỏa mãn.

Đơn vị công tác này được dùng để áp dụng cho trường hợp nơi mà các nhà phát triển không mô tả phần của TSFI, yêu cầu rằng nó là không can thiệp SFR và do đó không có các yêu cầu khác của thành phần này. Trong trường hợp này, các nhà phát triển cung cấp sở cứ cho đặc tính này đầy đủ chi tiết sao cho người đánh giá hiểu được sở cứ, các đặc điểm của giao diện bị ảnh hưởng (ví dụ, chức năng mức cao của họ đối với các TOE, chẳng hạn như "sử dụng bng màu") và yêu cầu đây là những không can thiệp SFR được hỗ trợ. Căn cứ vào mức độ đảm bảo, người đánh giá không nên kỳ vọng được cung cấp chi tiết hơn cho các giao diện thực thi SFR hoặc hỗ trợ SFR và trong thực tế, chi tiết nên ít hơn. Trong hu hết các trường hợp, giao diện riêng không nên đề cập trong điều sở cứ nhà phát triển cung cấp.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_FSP.1.4C: Việc theo dấu cần chứng minh rằng các SFR theo dấu các TSFI trong đặc tả chức năng.

10.4.1.3.5  Đơn vị công việc ADV_FSP.1-5

Người đánh giá cần kiểm tra rằng các liên kết theo dấu các SFR theo các TSFl tương ứng.

Theo dấu được cung cấp bởi các nhà phát triển để đảm nhiệm như một hướng dẫn mà các SFR liên quan đến các TSFl. Theo dấu này có thể đơn giản là một bng; nó được sử dụng làm đầu vào cho người đánh giá sử dụng trong các đơn vị công việc tiếp theo, trong đó người đánh giá xác minh tính đầy đủ và chính xác của nó.

10.4.1.4  Hành động ADV_FSP.1.2E

10.4.1.4.1  Đơn vị công việc ADV_FSP.1-6

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định rằng đó là sự thuyết minh đầy đủ của các SFR.

Để đảm bảo rằng tất cả các SFR được đề cập bởi các đặc tả chức năng, cũng như phân tích độ bao phủ kiểm thử, người đánh giá có thể xây dựng dựa trên của nhà phát triển (xem ADV_FSP.1-5 ánh xạ giữa các yêu cầu chức năng an toàn của TOE và TSFI). Lưu ý rằng ánh xạ này có thể có ở mức độ chi tiết dưới mức thành phần hoặc thậm chí mức phần tử của các yêu cầu, vì các hoạt động (chỉ định, bổ sung chi tiết, lựa chọn) thực hiện trên các yêu cầu chức năng của tác giả ST.

Ví dụ, các thành phần FDP_ACC.1 chứa các chỉ định trong một phần tử. Ví dụ, nếu ST chứa mười quy tắc trong chỉ định FDP_ACC.1 và mười quy tắc này được bao phủ bởi ba TSFI khác nhau, nó sẽ không đủ để người đánh giá ánh xạ FDP_ACC.1 theo hướng TSFI A, B và C và yêu cầu chúng hoàn thành các đơn vị công việc. Thay vào đó, người đánh giá sẽ ánh xạ FDP_ACC.1 (quy tắc 1) theo hướng TSFI A; FDP_ACC.1 (quy tắc 2) theo hướng TSFI B; v,v... Nó cũng có thể là trường hợp mà giao diện là một giao diện bao (ví dụ IOCTL...), trong trường hợp đó ánh xạ sẽ cần phải được cụ thể để thiết tập các thông số cho giao diện nhất định.

Người đánh giá phải thừa nhận rằng với các yêu cầu có ít hoặc không có biểu hiện tại ranh giới TSF (ví dụ, FDP_RIP) nó không kỳ vọng rằng người đánh giá ánh xạ toàn bộ các yêu cầu này đến TSFI. Việc phân tích cho những yêu cầu này sẽ được thực hiện trong phân tích thiết kế TOE (ADV_TDS) khi đưa vào ST. Điều này cũng quan trọng với lưu ý rằng vì các thông số liên quan đến các TSFI phải được xác định đầy đủ, người đánh giá nên xác định nếu tất cả các khía cạnh xuất hiện trong SFR được triển khai tại mức giao diện.

10.4.1.4.2  Đơn vị công việc ADV_FSP.1-7

Người đánh giá cần thẩm tra đặc tả chức năng để xác định rằng nó là sự chứng minh chính xác của các SFR.

Đối với mi yêu cầu chức năng trong ST mà kết quả trong các hiệu ứng có thể nhìn thấy ở ranh giới TSF, thông tin trong TSFI liên quan để yêu cầu riêng của chức năng được yêu cầu đã mô tả bằng yêu cầu. Ví dụ, nếu ST có một yêu cầu đối với các danh sách kiểm soát truy cập và ch TSFl này ánh xạ để yêu cầu chỉ rõ chức năng đối với các bit bảo vệ kiu Unix, sau đó các đặc tả chức năng không chính xác đối với chi tiết của các yêu cầu.

Người đánh giá phải thừa nhận rằng đối với các yêu cầu này có ít hoặc không có biểu hiện tại ranh giới TSF (ví dụ, FDP_RIP) nó không kỳ vọng rằng người đánh giá ánh xạ toàn bộ các yêu cầu này đến TSR. Việc phân tích cho những yêu cầu này sẽ được thực hiện trong phân tích thiết kế TOE (ADV_TDS) khi nằm trong ST.

10.4.2  Đánh giá hoạt động con (ADV_FSP.2)

10.4.2.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu các nhà phát triển đã cung cấp mô tả của các TSFI trong các thuật ngữ về mục đích, phương pháp sử dụng và các thông số của chúng chưa. Ngoài ra, các hành động thực thi SFR, các kết quả và thông báo lỗi của mỗi TSFI tức là thực thi SFR cũng được mô tả.

10.4.2.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này đó là yêu cầu bởi các đơn vị công việc là:

a) ST;

b) đặc tả chức năng;

c) thiết kế TOE.

Bằng chứng đánh giá cho hoạt động con này được sử dụng nếu có trong ST của TOE là:

a) mô tả kiến trúc an toàn;

b) hướng dẫn người sử dụng vận hành.

10.4.2.3  Hành động ADV_FSP.2.1E

TCVN 8709-3 (ISO/IEC 15408-3) ADV_FSP.2.1C: Đặc tả chức năng cần biểu diễn toàn bộ TSF.

10.4.2.3.1  Đơn vị công việc ADV_FSP.2-1

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định rằng TSF được biểu diễn đầy đủ.

Việc xác định TSFI là điều kiện tiên quyết được yêu cầu cho tất cả các hoạt động khác trong hoạt động con này. TSF phải được xác định (thực hiện như một phần của đơn vị công việc thiết kế TOE (ADV_TDS)) để xác định các TSFI. Hoạt động này có thể được thực hiện ở mức cao để đảm bảo rằng không có nhóm lớn các giao diện bị bỏ qua (các giao thức mạng, các giao diện phần cứng, các tập tin cấu hình) hoặc ở mức thp như đánh giá của tiến trình đặc tả chức năng.

Khi tạo ra đánh giá cho đơn vị công việc này, người đánh giá xác định rằng tất cả các phần của TSF được đề cập trong các thuật ngữ của giao diện liệt kê trong đặc tả chức năng. Tất cả các phần của TSF cần phải có một mô tả giao diện tương ứng hoặc nếu không có giao diện tương ứng cho một phần của TSF, người đánh giá xác định rằng công việc có thể chấp nhận được.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.4.2.3.2  Đơn vị công việc ADV_FSP.2-2

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định rằng nó là trạng thái mục tiêu của mỗi TSFI.

Mục tiêu của TSFI là tuyên bố khái quát tóm tắt chức năng được cung cấp bởi giao diện. Nó không có ý định tuyên bố đầy đủ các hành động và kết quả liên quan đến giao diện, mà đúng hơn là một tuyên bố giúp cho người đọc hiểu được khái quát những gì giao diện có ý định sử dụng. Người đánh giá không nên chỉ xác định mục đích tồn tại, mà còn là phản ánh chính xác TSFI bằng cách đưa vào tài khoản các thông tin khác về giao diện, như mô tả các hành động và các thông báo lỗi.

10.4.2.3.3  Đơn vị công việc ADV_FSP.2-3

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định rằng phương pháp sử dụng cho mỗi TSFI đã định sẵn.

Phương pháp sử dụng cho TSFI tóm tắt làm thế nào giao diện được thao tác để gọi đến các hành động và đạt được các kết quả liên quan đến TSFI. Người đánh giá nên xác định, từ việc đọc vật liệu này trong đặc tả chức năng, làm sao để sử dụng mỗi giao diện. Điều này không có nghĩa là cần phải có một phương pháp riêng biệt sử dụng cho mỗi TSFI, vì nó có thể mô tả khái quát làm thế nào các cuộc gọi cốt lõi được gọi đến, ví dụ và khi đó mỗi giao diện xác định sử dụng kiểu chung. Các kiu giao diện khác nhau sẽ đòi hỏi phương pháp khác nhau của các thông số kỹ thuật sử dụng. Các API, giao diện giao thức mạng, các thông số cấu hình hệ thống, giao diện bus phần cứng, tất cả đều có các phương pháp rất khác nhau đ sử dụng và điều này nên được đưa vào tài khoản của các nhà phát triển khi phát triển các đặc tả chức năng, cũng như thm định đánh giá các đặc tả chức năng.

Đối với giao diện hành chính có chức năng là tài liệu không thể tiếp cận với người sử dụng không đáng tin cậy, Người đánh giá đảm bảo rằng phương pháp làm các chức năng không thể tiếp cận được mô tả trong đặc tả chức năng, cần lưu ý rằng không thể tiếp cận này cần phải được kiểm thử bởi các nhà phát triển trong bộ phần mềm kiểm thử của họ.

Người đánh giá không nên chỉ xác định rằng tập hợp phương pháp sử dụng các mô tả hiện tại, mà chúng cũng bao gồm chính xác mỗi TSFI.

TCVN 8709-3 (ISO/IEC 15408-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.

10.4.2.3.4  Đơn vị công việc ADV_FSP.2-4

Người đánh giá cần thẩm tra việc trình bày của TSFI để xác định rằng nó nhận dạng đầy đủ tất cả các thông số liên quan đến mỗi TSFI.

Người đánh giá thẩm tra đặc tả chức năng để đảm bảo rằng tất cả các thông số được mô tả cho mỗi TSFI. Các tham số đầu vào hoặc đầu ra rõ ràng trong một giao diện để kiểm soát hoạt động của giao diện đó. Ví dụ, các thông số là các đối số cung cấp cho APl; các lĩnh vực khác nhau trong gói tin cho một giao thức mạng nhất định; các giá trị riêng quan trọng trong Windows Registry; các tín hiệu là tập hợp của các chân trên một con chip; v.v...

Để xác định tất cả các thông số có mặt trong TSFI, người đánh giá nên thẩm tra phần còn lại của mô tả giao diện (các hành động, thông báo lỗi, v.v...) để xác định nếu ảnh hưởng của các tham số được giải thích trong mô tả. Người đánh giá cũng nên kiểm tra bằng chứng khác được cung cấp cho việc đánh giá (ví dụ, thiết kế TOE, mô tả kiến trúc an toàn, hướng dẫn người sử dụng vận hành, biểu diễn triển khai) để xem xét nếu hành vi hoặc các tham số bổ sung được mô tả ở đó nhưng không có trong đặc tả chức năng.

10.4.2.3.5  Đơn vị công việc ADV_FSP.2-5

Người đánh giá cần thẩm tra việc trình bày của TSFI để xác định rằng nó mô tả đầy đủ và chính xác tất cả các thông số liên quan đến mỗi TSFI.

Một khi tất cả các thông số đã được xác định, người đánh giá cần đảm bảo rằng chúng được mô tả một cách chính xác và mô tả của các thông số là hoàn thiện. Mô tả thông số cho biết ý nghĩa của những thông số này. Ví dụ, giao diện "foo(i)" có thể mô tả như là có "tham số i là một số nguyên"; cách mô tả tham số như thế này không được chấp nhận. Mô tả chẳng hạn như "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" được chấp nhận.

Để xác định rằng mô tả của các thông số là hoàn thiện, người đánh giá cần thẩm tra phần còn lại của mô tả giao diện (mục đích, phương pháp sử dụng, các hoạt động, thông báo lỗi, v.v...) để xác định nếu các mô tả của (các) tham số được ghi trong mô tả. Người đánh giá cũng nên kiểm tra bằng chứng khác đã cung cấp (ví dụ, thiết kế TOE, thiết kế kiến trúc, hướng dẫn người sử dụng vận hành, biểu diễn triển khai) để xem xét nếu hành vi hoặc các tham số bổ sung được mô tả ở đó nhưng không có trong đặc tả chức năng.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_FSP.2.4C: Vi 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.

10.4.2.3.6  Đơn vị công việc ADV_FSP.2-6

Người đánh giá cần thẩm tra việc trình bày của các TSFI để xác định rằng nó mô tả đầy đủ và chính xác các hành động thực thi SFR liên quan đến các TSFI thực thi SFR.

Nếu một hành động có sn thông qua một giao diện có thể được theo dấu đến một trong những SFR áp trên TSF, sau đó giao diện là thực thi SFR. Các chính sách này không giới hạn đến các chính sách kiểm soát truy cập, nhưng cũng đề cập đến bất kỳ chức năng được quy định bởi một trong những SFR có trong ST. Lưu ý rằng nó có thể là giao diện với những hành động và các kết quả khác nhau, một số trong đó có thể là thực thi SFR và một số có thể không.

Các nhà phát triển không cần giao diện "nhãn" như thực thi SFR và tương tự như vậy không cần xác định các hành động có sẵn thông qua một giao diện như thực thi SFR. Đây là trách nhiệm của người đánh giá để thẩm tra các bằng chứng đã cung cấp bởi nhà phát triển và xác định các thông tin được yêu cầu có mặt. Trong trường hợp khi mà các nhà phát triển đã xác định TSFI thực thi SFR và hành động thực thi SFR có sẵn thông qua những TSFI này, người đánh giá phải đánh giá đầy đủ và chính xác dựa trên các thông tin khác đã cung cấp cho việc đánh giá (ví dụ, thiết kế TOE, mô tả kiến trúc an toàn, hướng dẫn người sử dụng vận hành) và các thông tin khác được trình bày cho các giao diện (các thông số và mô tả thông số, các thông báo lỗi, v.v).

Trong trường hợp này (khi mà nhà phát triển chỉ cung cấp thông tin thực thi SFR cho TSFI thực thi SFR) người đánh giá cũng đảm bảo rằng không có giao diện bị phân loại sai. Điều này được thực hiện bằng cách thẩm tra các thông tin khác đã cung cấp cho việc đánh giá (ví dụ, thiết kế TOE, mô tả kiến trúc an toàn, hướng dẫn người sử dụng vận hành) và các thông tin khác được trình bày cho các giao diện (ví dụ, các thông số và mô tả thông số) không được đánh nhãn như thực thi SFR.

Trong trường hợp khi nhà phát triển đã cung cấp cùng mức thông tin dựa trên tất cả các giao diện, người đánh giá thực hiện cùng một loại phân tích đã đề cập trong nội dung phía trên. Người đánh giá cần xác định các giao diện nào là thực thi SFR và các giao diện nào không thực thi SFR và sau đó đảm bảo rằng các khía cạnh thực thi SFR của các hành động thực thi SFR được mô tả một cách thích hợp.

Các hành động thực thi SFR là những hành động có thể nhìn thy ở bất kỳ giao diện bên ngoài nào và cung cấp cho việc thi hành các SFR được yêu cầu. Ví dụ, nếu các yêu cầu thẩm tra có trong ST, sau đó hoạt động kiểm tra liên quan đến sẽ là thực thi SFR và do đó phải được mô tả ngay cả khi kết quả của hành động nói chung là không thể nhìn thy thông qua giao diện gọi đến (thường là trong trường hợp thẩm tra, nơi mà hành động của người sử dụng tại một giao diện sẽ cung cấp một hồ sơ thẩm tra có thể nhìn thấy tại giao diện khác).

Các mức mô tả đó là yêu cầu đủ đ người đọc hiểu được vai trò gì để các hành động TSFI vận hành với khía cạnh theo hướng SFR. Người đánh giá cần lưu ý rằng sự mô tả nên đầy đủ chi tiết để hỗ trợ sự hình thành (và đánh giá) của các trường hợp kiểm thử với giao diện đó. Nếu mô tả không rõ ràng hoặc thiếu chi tiết dẫn đến không thể tiến hành kiểm thử ý nghĩa chống lại các TSFI, có khả năng mô tả là không đy đ.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_FSP.2.5C: Vi 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ừ xlý liên quan với các hành động thực thi SFR.

10.4.2.3.7  Đơn vị công việc ADV_FSP.2-7

Người đánh giá cần thẩm tra việc trình bày của TSFI để xác định rằng nó mô tả đầy đủ và chính xác thông báo lỗi có thể là kết quả từ các hành động thực thi SFR liên quan đến mỗi TSFl thực thi SFR. Đơn vị công việc này nên được thực hiện kết hợp với hoặc sau đó, đơn vị công việc ADV_FSP.2-6 để đảm bảo các thiết lập của TSFI thực thi SFR và các hành động thực thi SFR được xác định một cách chính xác. Các nhà phát triển có thể cung cấp nhiều thông tin được yêu cầu hơn (ví dụ, tất cả các thông báo lỗi liên quan tới mỗi giao diện), trong trường hợp đó người đánh giá nên hạn chế đánh giá của họ về tính hoàn thiện và chính xác để ch họ thấy họ xác định được việc liên quan đến hành động thực thi SFR của TSFI thực thi SFR.

Lỗi có thể có nhiều hình thức, tùy thuộc vào giao diện được mô tả. Đối với một API, giao diện chính nó có thể tr về một mã lỗi, thiết lập một điều kiện lỗi tổng thể hoặc thiết lập một thông số nào đó với một mã lỗi. Đối với một tập tin cấu hình, thông số cấu hình không đúng có thể gây ra thông báo lỗi được ghi vào một tập tin đăng nhập. Đối với một card PCI phần cứng, điều kiện lỗi có thể làm tăng tín hiệu trên bus hoặc kích hoạt điều kiện ngoại lệ đối với CPU.

Lỗi (và các thông báo lỗi liên quan) xảy ra qua sự dẫn chứng của giao diện. Việc xử lý đáp ứng với sự dẫn chứng của giao diện có thể gặp phải các điều kiện lỗi, mà kích hoạt (thông qua một cơ chế triển khai cụ thể) một thông báo lỗi đã được tạo ra. Trong trường hợp này, có thể là giá trị trả về từ giao diện chính nó; trong trường hợp khác, giá trị tổng thể có thể được thiết lập và kiểm tra sau khi có sự dẫn chứng của giao diện. Có khả năng TOE sẽ có số thông báo lỗi ở mức độ thấp, có thể là kết quả của các điều kiện nguồn tài nguyên cơ bản, chẳng hạn như "đĩa đầy" hay "tài nguyên bị khóa". Trong khi các thông báo lỗi này có thể ánh xạ đến một số lượng lớn các TSFI, chúng có thể được sử dụng để phát hiện các trường hợp chi tiết từ mô tả giao diện đã được bỏ qua. Ví dụ, một TSFI tạo ra tin nhắn "đĩa đầy", nhưng không mô tả rõ ràng về lý do tại sao TSFl này cần tạo ra truy nhập vào đĩa trong mô tả của các hành động của nó, có thể người đánh giá thẩm tra các bằng chứng khác (Kiến trúc an toàn (ADV_ARC), thiết kế TOE (ADV_TDS)) liên quan mà TSFI xác định nếu mô tả là chính xác.

Để xác định rằng các mô tả về các thông báo lỗi của một TSFI là chính xác và đầy đủ, người đánh giá tính toán mô tả giao diện ngược lại với các bằng chứng khác đã cung cấp cho việc đánh giá (ví dụ, thiết kế TOE, mô tả kiến trúc an toàn, hướng dẫn người sử dụng vận hành), cũng như bằng chứng khác cho TSFI đó (các thông số, phân tích từ các đơn vị công việc ADV_FSP.2-6).

TCVN 8709-3 (ISO/IEC 15408-3) ADV_FSP.2.6C: Việc theo dấu cn chứng minh rằng các SFR theo dấu các TSFI theo đặc tả chức năng.

10.4.2.3.8  Đơn vị công việc ADV_FSP.2-8

Người đánh giá cần kiểm tra rằng các liên kết theo dấu các SFR theo các TSFI tương ứng.

Theo dấu được cung cấp bởi các nhà phát triển đ phục vụ như một hướng dẫn mà các SFR liên quan đến các TSFI. Theo dấu này có thể đơn giản là một bng; nó được sử dụng làm đầu vào cho người đánh giá sử dụng trong các đơn vị công việc tiếp theo, trong đó người đánh giá xác minh tính đầy đủ và chính xác của nó.

10.4.2.4  Hành động ADV_FSP.2.2E

10.4.2.4.1  Đơn vị công việc ADV_FSP.2-9

Người đánh giá cần thm tra các đặc tả chức năng để xác định rằng đó là sự thuyết minh đầy đủ của các SFR.

Để đảm bảo rằng tất cả các SFR được bao phủ bởi các đặc tả chức năng, cũng như phân tích độ bao phủ kiểm thử, người đánh giá có thể xây dựng dựa trên theo dấu của nhà phát triển (xem ADV_FSP.2-8 ánh xạ giữa các yêu cầu chức năng an toàn của TOE và TSFI). Lưu ý rằng ánh xạ này có thể có ở mức độ chi tiết dưới mức thành phần hoặc thậm chí mức phần tử của các yêu cầu, vì các hoạt động (chỉ định, bổ sung chi tiết, lựa chọn) thực hiện trên các yêu cầu chức năng của tác giả ST.

Ví dụ, các thành phần FDP_ACC.1 chứa các chỉ định trong một phần tử. Ví dụ, nếu ST chứa mười quy tắc trong chỉ định FDP_ACC.1 và mười quy tắc này được bao phủ bởi ba TSFI khác nhau, người đánh giá sẽ không đủ để ánh xạ FDP_ACC.1 theo hướng TSFI A, B và C và yêu cầu chúng hoàn thành các đơn vị công việc. Thay vào đó, người đánh giá sẽ ánh xạ FDP_ACC.1 (quy tắc 1) theo hướng TSFI A; FDP_ACC.1 (quy tắc 2) theo hướng TSFI B; v.v... Nó cũng có thể là trường hợp mà giao diện là một giao diện bao (ví dụ IOCTL...), trong trường hợp đó ánh xạ sẽ cần phải được cụ thể để thiết lập các thông số cho giao diện nhất định.

Người đánh giá phải thừa nhận rằng đối với các yêu cầu này có ít hoặc không có biểu hiện tại ranh giới TSF (ví dụ, FDP_RIP) nó không kỳ vọng rằng người đánh giá ánh xạ toàn bộ các yêu cầu này đến TSFI. Việc phân tích cho những yêu cầu này sẽ được thực hiện trong phân tích thiết kế TOE (ADV_TDS) khi đưa vào ST. Điều này cũng quan trọng với lưu ý rằng vì các thông số liên quan đến các TSFI phải được xác định đầy đủ, người đánh giá nên xác định nếu tất cả các khía cạnh xuất hiện trong SFR được triển khai tại mức giao diện.

10.4.2.4.2  Đơn vị công việc ADV_FSP.2-10

Người đánh giá cần thẩm tra đặc tả chức năng để xác định rằng nó là sự chứng minh chính xác của các SFR.

Đối với mỗi yêu cầu chức năng trong ST mà kết quả trong các hiệu ứng có thể nhìn thấy ở ranh giới TSF, thông tin trong TSFI liên quan để yêu cầu riêng của chức năng được yêu cầu đã mô tả bằng yêu cầu. Ví dụ, nếu ST có một yêu cầu đối với các danh sách kiểm soát truy cập và ch TSFl này ánh xạ để yêu cầu chỉ rõ chức năng đối với các bit bảo vệ kiểu Unix, do đó các đặc tả chức năng không chính xác đối theo yêu cầu.

Người đánh giá phải thừa nhận rằng đối với các yêu cầu này có ít hoặc không có biểu hiện tại ranh giới TSF (ví dụ, FDP_RIP) nó không kỳ vọng rằng người đánh giá ánh xạ toàn bộ các yêu cầu này đến TSFI. Việc phân tích cho những yêu cầu này sẽ được thực hiện trong phân tích thiết kế TOE (ADV_TDS) khi đưa vào ST.

10.4.3  Đánh giá hoạt động con (ADV_FSP.3)

10.4.3.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu các nhà phát triển đã cung cấp mô tả của các TSFI về mục đích, phương pháp sử dụng và các thông số của chúng không. Ngoài ra, các hành động, các kết quả và các thông báo lỗi của mỗi TSFI cũng mô tả đầy đủ rằng nó có thể được xác định dù chúng có là thực thi SFR, với TSFI thực thi SFR được mô tả chi tiết hơn các TSFI khác không.

10.4.3.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này đó là yêu cầu của các đơn vị công việc:

a) ST;

b) đặc tả chức năng;

c) thiết kế TOE.

Bằng chứng đánh giá cho hoạt động con này được sử dụng nếu có trong ST đối với TOE là:

a) mô tả kiến trúc an toàn;

b) biểu diễn triển khai;

c) mô tả nội bộ TSF;

d) hướng dẫn người sử dụng vận hành.

10.4.3.3  Hành đng ADV_FSP.3.1E

TCVN 8709-3 (ISO/IEC 15408-3) ADV_FSP.3.1C: Đặc tả chức năng cn biểu diễn đầy đủ TSF.

10.4.3.3.1  Đơn vị công việc ADV_FSP.3-1

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định rằng TSF được biểu diễn đầy đủ.

Việc xác định TSFI là điều kiện tiên quyết được yêu cầu cho tất cả các hoạt động khác trong hoạt động con này. TSF phải được xác định (thực hiện như một phần của đơn vị công việc thiết kế TOE (ADV_TDS)) để xác định các TSFI. Hoạt động này có thể được thực hiện ở mức cao để đảm bảo rằng không có nhóm lớn các giao diện b b qua (các giao thức mạng, các giao diện phần cứng, các tập tin cấu hình) hoặc ở mức thp như đánh giá của tiến hành đặc tả chức năng.

Khi tạo ra đánh giá cho đơn vị công việc này, người đánh giá xác định rằng tất cả các phần của TSF được đề cập trong các thuật ngữ của giao diện liệt kê trong đặc tả chức năng. Tất cả các phần của TSF cần phải có một mô tả giao diện tương ứng hoặc nếu không có giao diện tương ứng cho một phần của TSF, người đánh giá xác định rằng có thể chấp nhận công việc này.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.4.3.3.32  Đơn vị công việc ADV_FSP.3-2

Người đánh giá cn thẩm tra các đặc tả chức năng để xác định rằng nó là trạng thái mục tiêu của mỗi TSFI

Mục tiêu của TSFI là tuyên bố khái quát tóm tắt chức năng được cung cấp bởi giao diện. Nó không có ý định tuyên bố tính hoàn thiện của các hành động và kết quả liên quan đến giao diện, mà đúng hơn là một tuyên bố giúp cho người đọc hiểu được khái quát những gì giao diện có ý định sử dụng. Người đánh giá không nên chỉ xác định mục đích tồn tại, mà còn là phn ánh chính xác TSFI bằng cách đưa vào tài khoản các thông tin khác về giao diện, như mô tả các hành động và các thông báo lỗi.

10.4.3.3.3  Đơn vị công việc ADV_FSP.3-3

Người đánh giá cần thẩm tra các đặc tả chức năng đ xác định rằng phương pháp sử dụng cho mỗi TSFI đã định sẵn.

Phương pháp sử dụng cho TSFI tóm tắt làm thế nào giao diện được thao tác để gọi đến các hành động và đạt được các kết quả liên quan đến TSFI. Người đánh giá nên xác định, từ việc đọc vật liệu này trong đặc tả chức năng, làm sao để sử dụng mỗi giao diện. Điều này không có nghĩa là cần phải có một phương pháp riêng biệt sử dụng cho mỗi TSFI, vì nó có thể mô tả khái quát làm thế nào các cuộc gọi cốt lõi được gọi đến, ví dụ và khi đó mỗi giao diện xác định sử dụng phong cách chung. Các kiểu giao diện khác nhau sẽ đòi hỏi phương pháp khác nhau của các thông số kỹ thuật sử dụng. Các API, giao diện giao thức mạng, các thông số cấu hình hệ thống, giao diện bus phần cứng, tất cả đều có các phương pháp rất khác nhau để sử dụng và điều này nên được đưa vào tài khoản của các nhà phát triển khi phát triển các đặc tả chức năng, cũng như thẩm định đánh giá các đặc tả chức năng.

Đối với giao diện hành chính mà chức năng của chúng được ghi là không thể tiếp cận với người sử dụng không đáng tin cậy, Người đánh giá đảm bảo rằng phương pháp làm các chức năng không thể tiếp cận được mô tả trong đặc tả chức năng. Cần lưu ý rằng không thể tiếp cận này cần phải được kiểm thử bởi các nhà phát triển trong bộ phần mềm kiểm thử của họ.

Người đánh giá không nên ch xác định rằng tập hợp phương pháp sử dụng các mô tả hiện tại. mà chúng cũng bao gồm chính xác mỗi TSFI.

TCVN 8709-3 (ISO/IEC 15408-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.

10.4.3.3.4  Đơn v công việc ADV_FSP.3-4

Người đánh giá cần thẩm tra việc trình bày của TSFI để xác định rằng nó nhận dạng đầy đủ tất cả các thông số liên quan đến mỗi TSFI.

Người đánh giá thẩm tra đặc tả chức năng để đảm bảo rằng tất cả các thông số được mô tả cho mỗi TSFI. Các tham số đầu vào hoặc đầu ra rõ ràng trong một giao diện để kiểm soát hoạt động của giao diện đó. Ví dụ, các thông số là các đối số cung cấp cho API; các lĩnh vực khác nhau trong gói tin cho một giao thức mạng nhất định; các giá trị riêng quan trọng trong Windows Registry; các tín hiệu là tập hợp của các chân trên một con chip; v.v...

Đ xác định tất cả các thông số có mặt trong TSFI, người đánh giá nên thẩm tra phần còn lại của mô tả giao diện (các hành động, thông báo lỗi, v.v...) để xác định nếu ảnh hưởng của các tham số được giải thích trong mô tả. Người đánh giá cũng nên kiểm tra bằng chứng khác được cung cấp cho việc đánh giá (ví dụ, thiết kế TOE, mô tả kiến trúc an toàn, hướng dẫn người sử dụng vận hành, biu diễn triển khai) để xem xét nếu hành vi hoặc các tham số bổ sung được mô tả ở đó nhưng không có trong đặc tả chức năng.

10.4.3.3.5  Đơn vị công việc ADV_FSP.3-5

Người đánh giá cần thẩm tra việc trình bày của TSFI để xác định rằng nó mô tả đầy đủ và chính xác tất cả các thông số liên quan đến mỗi TSFI.

Một khi tất cả các thông số đã được xác định, người đánh giá cần đảm bảo rằng chúng được mô tả một cách chính xác và mô tả của các thông số là hoàn thiện. Mô tả thông số cho biết ý nghĩa của những thông số này. Ví dụ, giao diện "foo(i)" có thể mô tả như là có "tham số i là một số nguyên"; cách mô tả tham số như thế này không được chấp nhận. Mô tả 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" được chấp nhận.

Để xác định rằng mô tả của các thông số là hoàn thiện, người đánh giá cần thẩm tra phần còn lại của mô tả giao diện (mục đích, phương pháp sử dụng, các hoạt động, thông báo lỗi, v.v...) để xác định nếu các mô tả của (các) tham số được ghi trong mô tả. Người đánh giá cũng nên kiểm tra bằng chứng khác đã cung cấp (ví dụ, thiết kế TOE, thiết kế kiến trúc, hướng dẫn người sử dụng vận hành, biểu diễn triển khai) để xem xét nếu hành vi hoặc các tham số bổ sung được mô tả ở đó nhưng không có trong đặc tả chức năng.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.4.3.3.6  Đơn vị công việc ADV_FSP.3-6

Người đánh giá cần thẩm tra việc trình bày của các TSFI để xác định nó mô tả chính xác và đầy đủ các hành động thực thi SFR liên quan đến các TSFI thực thi SFR.

Nếu một hành động có sẵn thông qua giao diện đóng một vai trò trong việc thực thi các chính sách an toàn trên TOE (có nghĩa là, nếu một trong các hành động của giao diện có thể được theo du đến một trong những SFR áp theo TSF), sau đó giao diện là thực thi SFR. Các chính sách này không giới hạn đến các chính sách kiểm soát truy cập, nhưng cũng đề cập đến bất kỳ chức năng được quy định bởi một trong những SFR có trong ST. Lưu ý rằng nó có thể là giao diện với những hành động và các kết qukhác nhau, một số trong đó có thể là thực thi SFR và một số có thể không.

Các nhà phát triển không cần gắn nhãn giao diện như thực thi SFR và tương tự như vậy không cần xác định các hành động có sẵn thông qua một giao diện như thực thi SFR. Đây là trách nhiệm của người đánh giá để thẩm tra các bằng chứng đã cung cấp bởi nhà phát triển và xác định các thông tin được yêu cầu có mặt. Trong trường hợp khi mà các nhà phát triển đã xác định TSFI thực thi SFR và hành động thực thi SFR có sẵn thông qua những TSFI này, người đánh giá phải đánh giá đầy đủ và chính xác dựa trên các thông tin khác đã cung cấp cho việc đánh giá (ví dụ, thiết kế TOE, mô tả kiến trúc an toàn, hướng dẫn người sử dụng vận hành) và các thông tin khác được trình bày cho các giao diện (các thông số và mô tả thông số, các thông báo lỗi, vv).

Trong trường hợp này (nhà phát triển đã cung cấp ch là thông tin thực thi SFR cho TSFI thực thi SFR) người đánh giá cũng đảm bảo rằng không có giao diện bị phân loại sai. Điều này được thực hiện bằng cách thẩm tra các thông tin khác đã cung cấp cho việc đánh giá (ví dụ, thiết kế TOE, mô tả kiến trúc an toàn, hướng dẫn người sử dụng vận hành) và các thông tin khác được trình bày cho các giao diện (ví dụ, các thông số và mô tả thông số) không gắn nhãn thực thi SFR. Các phân tích được thực hiện với các đơn vị công việc ADV_FSP.3-7 và ADV_FSP.3-8 cũng được sử dụng trong việc tạo ra quyết định này.

Trong trường hợp khi nhà phát triển đã cung cấp cùng mức thông tin dựa trên tất cả các giao diện, người đánh giá thực hiện cùng một loại phân tích đã đề cập trong nội dung phía trên. Người đánh giá cần xác định các giao diện nào là thực thi SFR và các giao diện nào không thực thi SFR và sau đó đảm bảo rằng các khía cạnh thực thi SFR của các hành động thực thi SFR được mô tả một cách thích hợp. Lưu ý rằng trong trường hợp này, người đánh giá nên có thể thực hiện phần lớn các công việc liên quan đến đơn vị công việc ADV_FSP.3-8 trong quá trình thực hiện các phân tích thực thi SFR này.

Các hành động thực thi SFR là những hành động có thể nhìn thấy ở bất kỳ giao diện bên ngoài nào và cung cấp cho việc thi hành các SFR được yêu cầu. Ví dụ, nếu các yêu cầu thẩm tra có trong ST, sau đó hoạt động kiểm tra liên quan đến sẽ là thực thi SFR và do đó phải được mô tả ngay cả khi kết quả của hành động nói chung là không thể nhìn thấy thông qua giao diện gọi đến (thường là trong trường hợp thẩm tra, nơi mà hành động của người sử dụng tại một giao diện sẽ cung cấp một hồ sơ thẩm tra có thể nhìn thấy tại giao diện khác).

Các mức mô tả đó là yêu cầu đủ để người đọc hiểu được vai trò gì đ các hành động TSFI vận hành với khía cạnh theo hưng SFR. Người đánh giá cần lưu ý rằng sự mô tả nên được đầy đủ chi tiết để hỗ trợ sự hình thành (và đánh giá) của các trường hợp kiểm thử với giao diện đó. Nếu mô tả không rõ ràng hoặc thiếu chi tiết như vậy kiểm thcó ý nghĩa là không thể tiến hành chống lại các TSFI, có khả năng mô tả là không đầy đủ.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.4.3.3.7  Đơn vị công việc ADV_FSP.3-7

Người đánh giá cần thẩm tra việc trình bày của TSFI để xác định rằng nó mô tả đầy đủ và chính xác thông báo lỗi có thể là kết quả từ lệnh gọi của mỗi TSFl thực thi SFR.

Đơn vị công việc này nên thực hiện kết hợp cùng hoặc sau đơn vị công việc ADV_FSP.3-6 để đảm bảo các thiết lập của TSFI thực thi SFR được xác định một cách chính xác. Người đánh giá nên lưu ý rằng các yêu cầu và đơn vị công việc liên quan mà tất cả việc thông báo lỗi trực tiếp liên quan tới TSFI thực thi SFR phải được mô tả, điều đó có liên quan đến hành động thực thi SFR. Điều này là do ở mức độ đảm bảo, các thông tin "thêm" được cung cấp bởi các mô tả thông báo lỗi nên được sử dụng trong việc xác định tất cả các khía cạnh thực thi SFR của giao diện đã được mô tả một cách thích hợp. Ví dụ, nếu thông báo lỗi liên quan tới TSFI (ví dụ, "truy nhập b từ chối") chỉ ra rằng quyết định hoặc hành động thực thi SFR đã xảy ra, nhưng trong bn mô tả các hành động không thực thi SFR đề cập đến cơ chế thực thi SFR đặc biệt, do đó mô tả có thể không đầy đủ.

Lỗi có thể có nhiều hình thức, tùy thuộc vào giao diện được mô tả. Đối với một API, giao diện chính nó có thể trả về một mã lỗi, thiết lập một điều kiện lỗi toàn cầu hoặc thiết lập một thông số nào đó với một mã lỗi. Đối với một tập tin cấu hình, thông số cấu hình không đúng có thể gây ra thông báo lỗi được ghi vào một tập tin đăng nhập. Đối với một card PCI phần cứng, điều kiện lỗi có thể làm tăng tín hiệu trên bus hoặc kích hoạt điều kiện ngoại lệ đối với CPU.

Lỗi (và các thông báo lỗi liên quan) xy ra qua sự dẫn chứng của giao diện. Việc xử lý nhằm đáp ứng với sự dẫn chứng của giao diện có thể gặp phải các điều kiện lỗi, mà kích hoạt (thông qua một cơ chế triển khai cụ thể) một thông báo lỗi đã được tạo ra. Trong trường hợp này, có thể là giá trị trả về từ giao diện chính nó; trong trường hợp khác, giá trị toàn cầu có thể được thiết lập và kiểm tra sau khi có sự dẫn chứng của giao diện. Có kh năng TOE sẽ có số thông báo lỗi ở mức độ thấp, có thể là kết quả của các điều kiện nguồn tài nguyên cơ bản, chng hạn như "đĩa đầy" hay "tài nguyên bị khóa". Trong khi các thông báo lỗi này có thể ánh xạ đến một số lượng lớn các TSFI, chúng có thể được sử dụng để phát hiện các trường hợp chi tiết từ mô tả giao diện đã được bỏ qua. Ví dụ, một TSFI cung cấp tin nhắn "đĩa đầy", nhưng không có mô tả rõ ràng về lý do tại sao TSFI cần tạo ra truy nhập vào đĩa trong mô tả của các hành động của nó, có thể người đánh giá thẩm tra các bằng chứng khác (Kiến trúc an toàn (ADV_ARC), thiết kế TOE (ADV_TDS)) liên quan mà TSFI xác định nếu mô tả là chính xác.

Để xác định rằng các mô tả về các thông báo lỗi của một TSFI là chính xác và đầy đủ, người đánh giá kiểm tra mô tả giao diện ngược lại với các bằng chứng khác đã cung cấp cho việc đánh giá (ví dụ, thiết kế TOE, mô tả kiến trúc an toàn, hướng dẫn người sử dụng vận hành), cũng như bằng chứng khác cho TSFI đó (mô tả các hành động thực thi SFR, bản tóm tắt hỗ trợ SFR và các hành động không can thiệp SFR và các kết quả).

TCVN 8709-3 (ISO/IEC 15408-3) ADV_FSP.3.6C: Đặ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.

10.4.3.3.8  Đơn vị công việc ADV_FSP.3-8

Người đánh giá cần thẩm tra việc trình bày của TSFl để xác định rằng 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.

Mục đích của đơn vị công việc này là để bổ sung các chi tiết về các hành động thực thi SFR (được cung cấp trong đơn vị công việc ADV_FSP.3-6) với tóm tắt các hoạt động còn lại (nghĩa là cái đó không thực thi SFR). Điều này bao gồm "tất cả" các hành động hỗ trợ SFR và không can thiệp SFR, liệu có thể gọi đến qua TSFI thực thi SFR hoặc thông qua TSFI hỗ trợ SFR hoặc không can thiệp SFR. Bản tóm tắt này với tất cả các hành động hỗ trợ SFR và không can thiệp SFR giúp cung cấp một bức tranh hoàn chỉnh hơn về các chức năng được cung cấp bởi TSF và được người đánh giá sử dụng trong việc xác định liệu hành động hoặc TSFI có thể bị phân loại sai không.

Thông tin được cung cấp tóm tắt hơn so với các yêu cầu đối với các hoạt động thực thi SFR. Ví dụ, trong khi nó vẫn nên có đủ chi tiết để người đọc có thể hiểu những gì các hành động thực hiện, mô tả không có đ chi tiết được hỗ trợ viết kiểm thử dựa theo nó. Đối với người đánh giá, mấu chốt là thông tin phải đủ để tạo ra quyết đnh tích cực rằng các hành động này là hỗ trợ SFR hoặc không can thiệp SFR. Nếu thiếu thông tin, bản tóm tắt là không đ và phải thu thập nhiều thông tin hơn nữa.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_FSP.3.7C: Theo dấu cn chứng minh rằng các SFR theo dấu các TSFI trong đặc tả chức năng.

10.4.3.3.9  Đơn v công việc ADV_FSP.3-9

Người đánh giá cần kiểm tra rằng các liên kết theo dấu các SFR theo các TSFl tương ứng.

Theo du được cung cấp bởi các nhà phát triển để phục vụ như là một hướng dẫn mà các SFR liên quan đến các TSFI. Theo dấu này có thể đơn giản là một bảng; nó được sử dụng làm đầu vào cho người đánh giá sử dụng trong các đơn vị công việc tiếp theo, trong đó người đánh giá xác minh tính đầy đủ và chính xác của nó.

10.4.3.4  Hành động ADV_FSP.3.2E

10.4.3.4.1  Đơn vị công việc ADV_FSP.3-10

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định rằng đó là sự thuyết minh đầy đủ của các SFR.

Để đảm bảo rằng tất cả các SFR được bao phủ bởi các đặc tả chức năng, cũng như phân tích độ bao phủ kiểm thử, người đánh giá có thể xây dựng dựa trên theo dấu của nhà phát triển (xem ADV_FSP.3-9 ánh xạ giữa các yêu cầu chức năng an toàn của TOE và TSFI). Lưu ý rằng ánh xạ này có thể có được ở mức độ chi tiết dưới mức thành phần hoặc thậm chí mức phần tử của các yêu cầu, bi vì các hoạt động chỉ định, bổ sung chi tiết, lựa chọn) thực hiện trên các yêu cầu chức năng của tác giả ST.

Ví dụ, các thành phần FDP_ACC.1 chứa các chỉ định trong một phần tử. Ví dụ, nếu ST chứa mười quy tắc trong chỉ định FDP_ACC.1 và mười quy tắc này được bao phủ bởi ba TSFI khác nhau, nó sẽ không đ để người đánh giá ánh xạ FDP_ACC.1 theo hướng TSFI A, B và C và yêu cầu chúng hoàn thành các đơn vị công việc. Thay vào đó, người đánh giá sẽ ánh xạ FDP_ACC.1 (quy tắc 1) theo hướng TSFI A; FDP_ACC.1 (quy tắc 2) theo hướng TSFI B; v.v... Nó cũng có thể là trường hợp mà giao diện là một giao diện bao (ví dụ IOCTL...), trong trường hợp đó ánh xạ sẽ cần phải được cụ thể để thiết lập các thông số cho giao diện nhất định.

Người đánh giá phải thừa nhận rằng đối với các yêu cầu có ít hoặc không có biểu hiện tại ranh giới TSF (ví dụ, FDP_RIP) người đánh giá không hy vọng ánh xạ toàn bộ các yêu cầu này đến TSFI. Việc phân tích cho những yêu cầu này sẽ được thực hiện trong phân tích thiết kế TOE (ADV_TDS) khi đưa vào ST. Điều này cũng quan trọng với lưu ý rằng vì các thông số liên quan đến các TSFI phải được xác định đầy đủ, người đánh giá nên xác định nếu tất cả các khía cạnh xuất hiện trong SFR được triển khai tại mức giao diện.

10.4.3.4.2  Đơn vị công việc ADV_FSP.3-11

Người đánh giá cần thẩm tra đặc tả chức năng để xác định rằng nó là sự chứng minh chính xác của các SFR.

Đối với mỗi yêu cầu chức năng trong ST mà kết quả trong các hiệu ứng có thể nhìn thấy ở ranh giới TSF, thông tin trong TSFI liên quan đ yêu cầu riêng của chức năng được yêu cầu đã mô tả bằng yêu cầu. Ví dụ, nếu ST có một yêu cầu đối với các danh sách kiểm soát truy cập và chỉ TSFI này ánh xạ để yêu cầu chỉ rõ chức năng đối với các bit bảo vệ kiểu Unix, sau đó các đặc tả chức năng không chính xác so với các yêu cầu.

Người đánh giá phải thừa nhận rằng đối với các yêu cầu này có ít hoặc không có biểu hiện ti ranh giới TSF (ví dụ, FDP_RIP) nó không kỳ vọng rằng người đánh giá ánh xạ toàn bộ các yêu cầu này đến TSFI. Việc phân tích cho những yêu cầu này sẽ được thực hiện trong phân tích thiết kế TOE (ADV_TDS) khi đưa vào ST.

10.4.4  Đánh giá hoạt động con (ADV_FSP.4)

10.4.4.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu các nhà phát triển có mô tả đầy đủ tất cả các TSFI theo một cách sao cho người đánh giá có thể xác định liệu TSFI có mô tả đầy đủ và chính xác và có trình diện triển khai các yêu cầu chức năng an toàn của ST không.

10.4.4.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là yêu cầu các đơn vị công việc là:

a) ST;

b) các đặc tả chức năng;

c) thiết kế TOE.

Bằng chứng đánh giá cho hoạt động con này được sử dụng nếu có trong ST của TOE:

a) mô tả kiến trúc an toàn;

b) biểu diễn triển khai;

c) mô tả nội bộ TSF;

d) hướng dẫn người sử dụng vận hành.

10.4.4.3  Lưu ý áp dụng

Các đặc là chức năng mô tả các giao diện TSF (TSFI) theo kiểu cấu trúc. Do sự phụ thuộc vào đánh giá của hoạt động con (ADV_TDS.1), người đánh giá dự kiến xác định TSF trước khi bắt đầu công việc của hoạt động con này. Nếu không có kiến thức vững chắc về thành phần của TSF, sẽ không thể đánh giá tính hoàn thiện của TSFI.

Khi thực hiện các đơn vị công việc khác nhau trong họ này, người đánh giá được yêu cầu tạo ra đánh giá chính xác và đầy đủ về một số yếu tố (TSFI là chính nó, cũng như các thành phần riêng lẻ (các thông số, các hành động, các thông báo lỗi, v.v...) của TSFI). Trong việc phân tích này, người đánh giá dự kiến sẽ sử dụng tài liệu đã cung cấp cho việc đánh giá. Điều này bao gồm ST, thiết kế TOE và có thể bao gồm tài liệu khác như các hướng dẫn người sử dụng vận hành, mô tả kiến trúc an toàn và biểu diễn triển khai. Tài liệu nên được thẩm tra theo cách lặp lại. Người đánh giá có thể đọc, ví dụ, trong thiết kế TOE làm cách nào mà chức năng đã biết được triển khai, nhưng không có cách nào để gọi đến chức năng đó từ giao diện. Điều này có thể gây ra khi người đánh giá câu hỏi về tính hoàn thiện của mô tả TSFI cụ thể hoặc liệu giao diện có được b ra hoàn toàn khỏi đặc tả chức năng không. Mô tả các hoạt động phân tích loại này trong ETR là một phương pháp quan trọng trong việc cung cấp sở cứ mà các đơn vị công việc đã thực hiện một cách thích hợp.

Hoạt động con này nên được công nhận tồn tại các yêu cầu chức năng mà thể hiện toàn bộ hoặc một phần kiến trúc chức năng, chứ không phải thông qua một cơ chế cụ thể. Ví dụ của việc này là việc triển khai các cơ chế thực hiện các yêu cầu bảo vệ thông tin dư (FDP_RIP). Cơ chế như vậy thường được triển khai để đảm bảo hành vi không có mặt, đó là khó khăn để kiểm thử và thường được thẩm tra thông qua phân tích. Trong trường hợp khi các yêu cầu chức năng như có trong ST, người đánh giá dự kiến công nhận có thể có SFR của loại này mà không có các giao diện và điều này không nên coi là một sự thiếu hụt trong đặc tả chức năng.

10.4.4.4  Hành động ADV_FSP.4.1E

TCVN 8709-3 (ISO/IEC 15408-3) ADV_FSP.4.1C: Đặc tả chức năng cần biểu diễn đầy đủ TSF.

10.4.4.4.1  Đơn vị công việc ADV_FSP.4-1

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định rằng TSF được biểu diễn đầy đủ.

Việc xác định TSFI là điều kiện tiên quyết được yêu cầu cho tất cả các hoạt động khác trong hoạt động con này. TSF phải được xác định (thực hiện như một phn của đơn vị công việc thiết kế TOE (ADV_TDS)) để xác định các TSFI. Hoạt động này có thể được thực hiện ở mức cao để đảm bảo rằng không có nhóm lớn các giao diện bị bỏ qua (các giao thức mạng, các giao diện phần cứng, các tập tin cấu hình) hoặc ở mức thấp như đánh giá của tiến hành đặc tả chức năng.

Khi tạo ra đánh giá cho đơn vị công việc này, người đánh giá xác định rằng tất cả các phần của TSF được đề cập trong các thuật ngữ của giao diện liệt kê trong đặc tả chức năng. Tất cả các phần của TSF cần phải có một mô tả giao diện tương ứng hoặc nếu không có giao diện tương ứng cho một phần của TSF, người đánh giá xác định rằng điều này là có thể chấp nhận được.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_FSP.4.2C: Đặc tả chức năng cn mô tả mục tiêu và phương pháp sdụng của tất cả TSFI.

10.4.4.4.2  Đơn vị công việc ADV_FSP.4-2

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định rằng nó là trạng thái mục tiêu của mỗi TSFI.

Mục tiêu của TSFI là tuyên bố khái quát tóm tắt chức năng được cung cấp bởi giao diện. Nó không nhằm mục đích tuyên bố đy đủ các hành động và kết quả liên quan đến giao diện, mà đúng hơn là một tuyên bố giúp cho người đọc hiểu được khái quát những gì giao diện có ý định sử dụng. Người đánh giá không nên ch xác định mục đích tồn tại, mà còn là phản ánh chính xác TSFI bằng cách đưa vào tài khoản các thông tin khác về giao diện, như mô tả các hành động và các thông báo lỗi.

10.4.4.4.3  Đơn vị công việc ADV_FSP.4-3

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định rằng phương pháp sử dụng cho mỗi TSFI đã định sẵn.

Phương pháp sử dụng cho TSFI tóm tắt làm thế nào giao diện được thao tác để gi đến các hành động và đạt được các kết quả liên quan đến TSFI. Người đánh giá nên xác định, từ việc đọc vật liệu này trong đặc tả chức năng, làm sao để sử dụng mỗi giao diện. Điều này không có nghĩa là cần phải có một phương pháp riêng biệt sử dụng cho mỗi TSFl, vì nó có thể mô tả khái quát làm thế nào các cuộc gọi cốt lõi được gọi đến, ví dụ và khi đó mỗi giao diện xác định sử dụng phong cách chung. Các kiểu giao diện khác nhau sẽ đòi hỏi phương pháp khác nhau của các thông số kỹ thuật sử dụng. Các API, giao diện giao thức mạng, các thông số cấu hình hệ thống, giao diện bus phần cứng, tất cả đều có các phương pháp rất khác nhau để sử dụng và điều này nên được đưa vào tài khoản của các nhà phát triển khi phát triển các đặc tả chức năng, cũng như thẩm định đánh giá các đặc tả chức năng.

Đối với giao diện hành chính có chức năng là tài liệu không thể tiếp cận với người sử dụng không đáng tin cậy, Người đánh giá đảm bảo rằng phương pháp làm các chức năng không thể tiếp cận được mô tả trong đặc tả chức năng. Cần lưu ý rằng không thể tiếp cận này cần phải được kiểm thử bởi các nhà phát triển trong bộ phần mềm kiểm thử của họ.

Người đánh giá không nên chỉ xác định rằng tập hợp phương pháp sử dụng các mô tả hiện tại, mà chúng cũng bao gồm chính xác mỗi TSFI.

10.4.4.4.4  Đơn vị công việc ADV_FSP.4-4

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định tính chất đầy đủ của TSFI.

Người đánh giá cần sử dụng các tài liệu thiết kế để xác định các kiểu có thể có của các giao diện. Người đánh giá cần tìm kiếm các tài liệu thiết kế và các tài liệu hướng dẫn cho TSFI tiềm năng không bao gồm tài liệu của nhà phát triển, điều này chỉ ra rằng tập hợp các TSFI được xác định bi các nhà phát triển là không đầy đủ. Người đánh giá cần thẩm tra các đối số được trình bày bởi nhà phát triển mà TSFI là đầy đủ và kiểm tra xuống mức thấp nhất của thiết kế hoặc với biểu diễn triển khai mà không tồn tại thêm TSFI.

TCVN 8709-3 (ISO/IEC 15408-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.

10.4.4.4.5  Đơn vị công việc ADV_FSP.4-5

Người đánh giá cần thẩm tra việc trình bày của TSFI để xác định rằng nó nhận dạng đầy đủ tất c các thông số liên quan đến mỗi TSFI.

Người đánh giá thẩm tra đặc tả chức năng để đảm bảo rằng tất cả các thông số được mô tả cho mỗi TSFI. Các tham số đầu vào hoặc đầu ra rõ ràng trong một giao diện để kiểm soát hoạt động của giao diện đó. Ví dụ, các thông số là các đối số cung cấp cho API; các lĩnh vực khác nhau trong gói tin cho một giao thức mạng nhất định; các giá trị riêng quan trọng trong Windows Registry; các tín hiệu là tập hợp của các chân trên một con chip; v.v...

Để xác định tất cả các thông số có mặt trong TSFI, người đánh giá nên thẩm tra phần còn lại của mô tả giao diện (các hành động, thông báo lỗi, v.v...) để xác định nếu ảnh hưởng của tham số được giải thích trong mô tả. Người đánh giá cũng nên kiểm tra bằng chứng khác được cung cp cho việc đánh giá (ví dụ, thiết kế TOE, mô tả kiến trúc an toàn, hưng dẫn người sử dụng vận hành, biểu diễn triển khai) để xem xét nếu hành vi hoặc các tham số bổ sung được mô tả ở đó nhưng không có trong đặc tả chức năng.

10.4.4.4.6  Đơn vị công việc ADV_FSP.4-6

Người đánh giá cần thẩm tra việc trình bày của TSFI để xác định rằng nó mô tả đầy đủ và chính xác tất cả các thông số liên quan đến mỗi TSFI.

Một khi tất cả các thông số đã được xác định, người đánh giá cần đảm bảo rằng chúng được mô tả một cách chính xác và mô tả của các thông số là hoàn thiện. Mô tả thông số cho biết ý nghĩa của những thông số này. Ví dụ, giao diện "foo(i)" có thể mô tả như là có "tham số i là một số nguyên"; cách mô tả tham số như thế này không được chấp nhận. Mô tả 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" được chấp nhận.

Để xác định rằng mô tả của các thông số là hoàn thiện, người đánh giá cần thẩm tra phần còn lại của mô t giao diện (mục đích, phương pháp sử dụng, các hoạt động, thông báo lỗi, v.v...) để xác định nếu các mô tả của (các) tham số được ghi trong mô tả. Người đánh giá cũng nên kiểm tra bằng chứng khác đã cung cấp (ví dụ, thiết kế TOE, thiết kế kiến trúc, hướng dẫn người sử dụng vận hành, biểu diễn triển khai) để xem xét nếu hành vi hoặc các tham số bổ sung được mô tả ở đó nhưng không có trong đặc tả chức năng.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.4.4.4.7  Đơn vị công việc ADV_FSP.4-7

Người đánh giá cần thẩm tra việc trình bày của các TSFI để xác định rằng nó mô t đầy đủ và chính xác tất cả các hành động liên quan với mỗi TSFI.

Người đánh giá kiểm tra để đảm bảo rằng tất cả các hành động được mô t, hành động có thể sử dụng thông qua giao diện mô tả những gì giao diện làm (trái ngược với thiết kế TOE, trong đó mô tả làm cách nào các hành động được cung cấp bởi các TSF).

Các hành động của một giao diện mô tả theo chức năng có thể gọi đến thông qua giao diện và có thể được phân loại như các hành động thường kỳ và các hành động liên quan SFR. Hành động thường kỳ mô tả những gì giao diện có. Lượng thông tin cung cấp cho mô tả này phụ thuộc vào sự phức tạp của giao diện. Những hành động liên quan SFR là những hành động có thể nhìn thấy ở bất cứ giao diện bên ngoài nào (ví dụ, hoạt động kiểm toán là nguyên nhân bởi việc gọi đến của giao diện (giả định yêu cầu kiểm toán trong ST) nên được mô tả, mặc dù kết quả của hành động này nói chung là không thể nhìn thấy thông qua giao diện gọi đến). Tùy thuộc vào các thông số của giao diện, có thể có nhiều hành động khác nhau có thể được gọi đến thông qua giao diện (ví dụ, một APl có thể có tham số đầu tiên là một "lệnh con", và các thông số tiếp theo sẽ cụ thể của lệnh con đó. IOCTLAPI trong một vài hệ thống Unix là một ví dụ về một giao diện như vậy).

Để xác định rằng các mô tả về những hành động của TSFl là đầy đủ, người đánh giá cần soát xét phần còn lại của mô tả giao diện (mô tả tham số, các thông báo lỗi, v.v...) để xác định nếu mô tả các hành động được giải thích. Người đánh giá cũng nên phân tích các bằng chứng khác được cung cấp cho việc đánh giá (ví dụ, thiết kế TOE, mô tả kiến trúc an toàn, hướng dẫn người s hoạt động, biểu diễn triển khai) để xem xét nếu có bằng chứng về hành động được mô tả ở đó nhưng không có trong đặc tả chức năng.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.4.4.4.8  Đơn vị công việc ADV_FSP.4-8

Người đánh giá cần thẩm tra việc trình bày của TSFI để xác định rằng nó mô tả đầy đủ và chính xác tất cả các thông báo lỗi mà kết quả từ việc gọi đến mỗi TSFI.

Lỗi có thể có nhiều hình thức, tùy thuộc vào giao diện được mô tả. Đối với một API, bản thân giao diện có thể tr về một mã lỗi, thiết lập một điều kiện lỗi tổng quan hoặc thiết lập một thông số nào đó với một mã lỗi. Đối với một tập tin cấu hình, thông số cấu hình không đúng có thể gây ra thông báo lỗi được ghi vào một tập tin đăng nhập. Đối với một card PCI phần cứng, điều kiện lỗi có thể làm tăng tín hiệu trên bus hoặc kích hoạt điều kiện ngoại lệ đối với CPU.

Lỗi (và các thông báo lỗi liên quan) xảy ra qua sự dẫn chứng của giao diện. Quá trình xử lý xảy ra để đáp ứng với sự dẫn chứng của giao diện có thể gặp phải các điều kiện lỗi, mà kích hoạt (thông qua một cơ chế triển khai cụ thể) một thông báo lỗi đã được tạo ra. Trong trường hợp này, có thể là giá trị tr về từ bản thân giao diện; trong trường hợp khác, giá trị toàn cầu có thể được thiết lập và kiểm tra sau khi có sự dẫn chứng của giao diện. Có khả năng TOE sẽ có số thông báo lỗi ở mức độ thấp, có thể là kết quả của các điều kiện nguồn tài nguyên cơ bản, chẳng hạn như "đĩa đầy" hay "tài nguyên bị khóa". Trong khi các thông báo lỗi này có thể ánh xạ đến một số lượng lớn các TSFI, chúng có thể được sử dụng để phát hiện các trường hợp chi tiết từ mô tả giao diện đã được bỏ qua. Ví dụ, một TSFI cung cấp tin nhắn "đĩa đầy", nhưng không có mô tả rõ ràng về lý do tại sao TSFI cần tạo ra truy nhập vào đĩa trong mô tả của các hành động của nó, có thể người đánh giá thẩm tra các bằng chứng khác (Kiến trúc an toàn (ADV_ARC), thiết kế TOE (ADV_TDS)) liên quan mà TSFI xác định nếu mô tả là chính xác.

Người đánh giá xác định rng, đối với mỗi TSFI, việc thiết lập chính xác các thông báo lỗi có thể được trả lại dựa trên cách gi đến mà giao diện có thể được xác định. Người đánh giá soát xét các bằng chứng đã cung cấp cho giao diện để xác định nếu tập hợp các lỗi đã đầy đủ. Họ thẩm tra chéo thông tin này với bằng chứng khác được cung cấp cho việc đánh giá (ví dụ, thiết kế TOE, mô tả kiến trúc an toàn, hướng dẫn người sử dụng vận hành, biểu diễn triển khai) để đảm bảo rằng không có lỗi sinh ra trong tiến trình được đề cập tới mà không có chứa trong đặc tả chức năng.

10.4.4.4.9  Đơn vị công việc ADV_FSP.4-9

Người đánh giá cần thẩm tra việc trình bày của TSFI để xác định rằng nó mô tả đầy đủ và chính xác ý nghĩa của tất cả các lỗi liên quan với mỗi TSFI.

Đ xác định chính xác, người đánh giá phải có khả năng hiểu ý nghĩa của lỗi. Ví dụ, nếu một giao diện trả về một mã số 0, 1 hoặc 2, người đánh giá sẽ không thể hiểu được lỗi nếu đặc tả chức năng chỉ được liệt kê: "lỗi có thể phát sinh từ gọi đến của giao diện foo() là 0, 1 hoặc 2”. Thay vào đó, người đánh giá kiểm tra để đảm bảo rằng các lỗi được mô tả như: "lỗi có thể phát sinh từ gọi đến của giao diện foo() là 0 (xử lý thành công), 1 (tập tin không tìm thấy) hoặc 2 (mô tả tên tập tin không chính xác)".

Để xác định rằng các mô tả về lỗi do việc gọi đến của TSFI là đầy đủ, người đánh giá thẩm tra phần còn lại của mô tả giao diện (các mô tả tham số, các hành động, v.v..) để xác định nếu các điều kiện lỗi tiềm năng có thể là nguyên nhân do cách sử dụng như một giao diện được giải thích. Người đánh giá cũng nên kiểm tra bằng chứng khác được cung cấp cho việc đánh giá (ví dụ, thiết kế TOE, mô tả kiến trúc an toàn, hướng dẫn người sử dụng vận hành, biểu diễn triển khai) để xem xét nếu xử lý lỗi liên quan đến TSFI được mô tả ở đó nhưng không được mô tả trong đặc tả chức năng.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_FSP.4.6C: Theo dấu cần chứng minh rằng các SFR theo dấu cácTSFI trong đặc tả chức năng.

10.4.4.4.10  Đơn vị công việc ADV_FSP.4-10

Người đánh giá cần kiểm tra rằng các liên kết theo dấu các SFR theo các TSFI tương ứng.

Theo dấu được cung cấp bởi các nhà phát triển để phục vụ như một hướng dẫn mà các SFR liên quan đến các TSFI. Theo dấu này có thể đơn giản là một bảng; nó được sử dụng làm đầu vào cho người đánh giá sử dụng trong các đơn vị công việc tiếp theo, trong đó người đánh giá xác minh tính đầy đủ và chính xác của nó.

10.4.4.5  Hành động ADV_FSP.4.2E

10.4.4.5.1  Đơn vị công việc ADV_FSP.4-11

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định rằng đó là sự thuyết minh đầy đủ của các SFR.

Để đảm bảo rằng tất cả các SFR được bao phủ bởi các đặc tả chức năng, cũng như phân tích độ bao phủ kiểm thử, người đánh giá có thể xây dựng dựa trên theo dấu của nhà phát triển (xem ADV_FSP.4-10 ánh xạ giữa các yêu cầu chức năng an toàn của TOE và TSFI). Lưu ý rằng ánh xạ này có thể có được ở mức độ chi tiết dưới mức thành phần hoặc thậm chí mức phần tử của các yêu cầu, bởi vì các hoạt động (chỉ định, bổ sung chi tiết, lựa chọn) thực hiện trên các yêu cầu chức năng của tác giả ST.

Ví dụ, các thành phần FDP_ACC.1 chứa các chỉ định trong một phần tử. Ví dụ, nếu ST chứa mười quy tắc trong chỉ định FDP_ACC.1 và mười quy tắc này được bao phủ bởi ba TSFI khác nhau, nó sẽ không đ để người đánh giá ánh xạ FDP_ACC.1 theo hướng TSFl A, B và C và yêu cầu chúng hoàn thành các đơn vị công việc. Thay vào đó, người đánh giá sẽ ánh xạ FDP_ACC.1 (quy tắc 1) theo hướng TSFI A; FDP_ACC.1 (quy tắc 2) theo hướng TSFI B; v.v... Nó cũng có thể là trường hợp mà giao diện là một giao diện bao (ví dụ IOCTL...), trong trường hợp đó ánh xạ sẽ cần phải được cụ thể để thiết lập các thông số cho giao diện nhất định.

Người đánh giá phải thừa nhận rằng đối với các yêu cầu này có ít hoặc không có biểu hiện tại ranh giới TSF (ví dụ, FDP_RIP) nó không kỳ vọng rằng người đánh giá ánh xạ toàn bộ các yêu cầu này đến TSFl. Việc phân tích cho những yêu cầu này sẽ được thực hiện trong phân tích thiết kế TOE (ADV_TDS) khi đưa vào ST. Điều này cũng quan trọng với lưu ý rằng vì các thông số liên quan đến các TSFI phải được xác định đầy đủ, người đánh giá nên xác định nếu tất cả các khía cạnh xuất hiện trong SFR được triển khai tại mức giao diện.

10.4.4.5.2  Đơn v công việc ADV_FSP.4-12

Người đánh giá cần thẩm tra đặc tả chức năng để xác định rằng nó là sự chứng minh chính xác của các SFR.

Đối với mỗi yêu cầu chức năng trong ST mà kết quả trong các hiệu ứng có thể nhìn thấy ở ranh giới TSF, thông tin trong TSFl liên quan để yêu cầu riêng của chức năng được yêu cầu đã mô tả bằng yêu cầu. Ví dụ, nếu ST có một yêu cầu đối với các danh sách kiểm soát truy cập và chỉ TSFI này ánh xạ để yêu cầu ch rõ chức năng đối với các bit bảo vệ kiểu Unix, sau đó các đặc tả chức năng không chính xác đối với chi tiết của các yêu cầu.

Người đánh giá phải thừa nhận rằng đối với các yêu cầu này có ít hoặc không có biểu hiện tại ranh giới TSF (ví dụ, FDP_RIP) nó không kỳ vọng rằng người đánh giá ánh xạ toàn bộ các yêu cầu này đến TSFI. Việc phân tích cho những yêu cầu này sẽ được thực hiện trong phân tích thiết kế TOE (ADV_TDS) khi đưa vào ST.

10.4.5  Đánh giá hoạt động con (ADV_FSP.5)

10.4.5.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu các nhà phát triển có mô tả đầy đủ tất cả các TSFI theo một cách sao cho người đánh giá có thể xác định liệu TSFI có mô tả đầy đủ và chính xác và xuất hiện để triển khai các yêu cầu chức năng an toàn của ST không. Tính chất đầy đủ của các giao diện được đánh giá dựa trên biểu diễn triển khai.

10.4.5.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này đó là yêu cầu của các đơn vị công việc là:

a) ST;

b) đặc tả chức năng;

c) thiết kế TOE;

d) biểu diễn triển khai.

Bằng chứng đánh giá cho hoạt động con này được sử dụng nếu có trong ST của TOE là:

a) mô tả kiến trúc an toàn;

b) mô tả bên trong TSF;

c) mô hình chính sách bảo mật chính thức;

d) hướng dẫn người sử dụng vận hành.

10.4.5.3  Hành động ADV_FSP.5.1E

TCVN 8709-3 (ISO/IEC 15408-3) ADV_FSP.5.1C: Đặc tả chức năng cần biểu diễn đầy đủ TSF.

10.4.5.3.1  Đơn vị công việc ADV_FSP.5-1

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định rằng TSF được biểu diễn đầy đủ.

Việc xác định TSFI là điều kiện tiên quyết được yêu cầu cho tất cả các hoạt động khác trong hoạt động con này. TSF phải được xác định (thực hiện như một phn của đơn vị công việc thiết kế TOE (ADV_TDS)) để xác định các TSFI. Hoạt động này có thể được thực hiện ở mức cao để đảm bảo rằng không có nhóm lớn các giao diện bị bỏ qua (các giao thức mạng, các giao diện phần cứng, các tập tin cấu hình) hoặc ở mức thp như đánh giá của tiến hành đặc tả chức năng.

Khi tạo ra đánh giá cho đơn vị công việc này, người đánh giá xác định rằng tất cả các phn của TSF được đề cập trong các thuật ngữ của giao diện liệt kê trong đặc tả chức năng. Tất cả các phần của TSF cần phải có một mô tả giao diện tương ứng hoặc nếu không có giao diện tương ứng cho một phần của TSF, người đánh giá xác định rằng có thể chấp nhận công việc này.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.4.5.3.2  Đơn vị công việc ADV_FSP.5-2

Người đánh giá cần thẩm tra đặc tả chức năng để xác định rằng nó được trình diện bằng cách sử dụng kiểu bán chính thức.

Cách trình diện bán chính thức được đặc trưng bởi một định dạng tiêu chuẩn với một cú pháp hoàn toàn xác định làm giảm sự tối nghĩa có thể xảy ra trong cách trình diện chính thức. Do có định dạng bán chính thức là để tăng khả năng của người đọc đ hiểu được cách trình diện, sử dụng một số phương pháp trình diện được cấu trúc nào đó (mã gi, các biểu đồ, sơ đồ khối) là phù hợp, mặc dù không được yêu cầu.

Theo mục đích của hoạt động này, người đánh giá phải đảm bảo rằng các mô tả giao diện được định dạng trong cấu trúc, cách xử lý nhất quán và sử dụng thuật ngữ chung. Cách trình diện bán chính thức của các giao diện cũng có nghĩa là mức độ chi tiết của cách trình diện cho các giao diện phần lớn là nhất quán trên tất cả các TSFI. Đối với đặc tả chức năng, đó là chấp nhận được tham khảo các đặc tả bên ngoài cho các phần của giao diện miễn là các đặc tả bên ngoài đó là bán chính thức của chính nó.

TCVN 8709-3 (ISO/IEC 15408-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.

10.4.5.3.3  Đơn vị công việc ADV_FSP.5-3

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định rằng nó là trạng thái mục tiêu của mỗi TSFI.

Mục tiêu của TSFI là tuyên bố tổng quát tóm tắt chức năng được cung cấp bởi giao diện. Nó không nhằm mục đích tuyên bố hoàn thiện của các hành động và kết quả liên quan đến giao diện, mà đúng hơn là một tuyên bố giúp cho người đọc hiểu được tng thể những gì giao diện được mong đợi để sử dụng. Người đánh giá không nên chỉ xác định mục đích tồn tại, mà còn là phản ánh chính xác TSFI bằng cách xem xét các thông tin khác về giao diện, như mô t các hành động và các thông báo lỗi.

10.4.5.3.4  Đơn vị công việc ADV_FSP.5-4

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định rằng phương pháp sử dụng cho mỗi TSFI đã định sẵn.

Phương pháp sử dụng cho TSFI tóm tắt làm thế nào giao diện được thao tác để gọi ra các hành động và đạt được các kết quả liên quan đến TSFI. Người đánh giá nên xác định, từ đọc vật liệu này trong đặc tả chức năng, cách sử dụng mỗi giao diện. Điều này không có nghĩa là cần phải có một phương pháp riêng biệt sử dụng cho mỗi TSFI, vì nó có thể mô tả chung làm thế nào các cuộc gọi cốt lõi được gọi ra, ví dụ và khi đó mỗi giao diện xác định sử dụng phong cách chung. Các kiu giao diện khác nhau sẽ đòi hỏi phương pháp khác nhau của thông số kỹ thuật sử dụng, các API, giao diện giao thức mạng, các thông số cấu hình hệ thống, giao diện bus phần cứng, tt c đều có các phương pháp rất khác nhau để sử dụng và điều này nên được đưa vào tài khoản của các nhà phát triển khi phát triển các đặc tả chức năng, cũng như thẩm định đánh giá các đặc tả chức năng.

Đối với giao diện hành chính có chức năng được ghi là không thể tiếp cận với người sử dụng không đáng tin cậy, Người đánh giá đảm bảo rằng phương pháp làm các chức năng không thể tiếp cận được mô tả trong đặc tả chức năng. Cần lưu ý rằng không thể tiếp cận này cần phải được kiểm thử bởi các nhà phát triển trong bộ phần mềm kiểm thử của họ.

Người đánh giá không nên ch xác định rằng tập hợp phương pháp sử dụng các mô tả hiện tại, mà chúng cũng bao gồm chính xác mỗi TSFI.

10.4.5.3.5  Đơn vị công việc ADV_FSP.5-5

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định tính chất đầy đủ của TSFI.

Người đánh giá cần sử dụng các tài liệu thiết kế để xác định các kiểu có thể có của các giao diện. Người đánh giá cần tìm kiếm các tài liệu thiết kế và các tài liệu hướng dẫn cho TSFI tiềm năng không bao gồm tài liệu của nhà phát triển, điều này chỉ ra rằng tập hợp các TSFI được xác định bởi các nhà phát triển là không đầy đủ. Người đánh giá cần thẩm tra các đối s được trình bày bởi nhà phát triển mà TSFI là đầy đủ và kiểm tra xuống mức thấp nhất của thiết kế hoặc với biểu diễn triển khai mà không tồn tại thêm TSFI.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.4.5.3.6  Đơn vị công việc ADV_FSP.5-6

Người đánh giá cần thẩm tra việc trình bày của TSFI để xác định rằng nó nhận dạng đầy đủ tất cả các thông số liên quan đến mỗi TSFI.

Người đánh giá thẩm tra đặc tả chức năng để đảm bảo rằng tất cả các thông số được mô tả cho mỗi TSFI. Các tham số đầu vào hoặc đầu ra rõ ràng trong một giao diện để kiểm soát hoạt động của giao diện đó. Ví dụ, các thông số là các đối số cung cấp cho APl; các lĩnh vực khác nhau trong gói tin cho một giao thức mạng nhất định; các giá trị riêng quan trọng trong Windows Registry; các tín hiệu là tập hợp của các chân trên một con chip; v.v...

Để xác định tất cả các thông số có mặt trong TSFI, người đánh giá nên thẩm tra phần còn lại của mô tả giao diện (các hành động, thông báo lỗi, v.v...) để xác định nếu ảnh hưởng của tham số được giải thích trong mô tả. Người đánh giá cũng nên kiểm tra bằng chứng khác được cung cấp cho việc đánh giá (ví dụ, thiết kế TOE, mô tả kiến trúc an toàn, hướng dẫn người sử dụng vận hành, biểu diễn triển khai) để xem xét nếu hành vi hoặc các tham số bổ sung được mô tả ở đó nhưng không có trong đặc tả chức năng.

10.4.5.3.7  Đơn vị công việc ADV_FSP.5-7

Người đánh giá cần thẩm tra việc trình bày của TSFI để xác định rằng nó mô tả đầy đủ và chính xác tất cả các thông số liên quan đến mỗi TSFI.

Một khi tất cả các thông số đã được xác định, người đánh giá cần đảm bảo rằng chúng được mô tả một cách chính xác và mô tả của các thông số là hoàn thiện. Mô tả thông số cho biết ý nghĩa của những thông số này. Ví dụ, giao diện "foo(i)" có thể mô tả như là có "tham số i là một số nguyên"; cách mô tả tham số như thế này không được chấp nhận. Mô tả 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" được chấp nhận.

Để xác định rằng mô tả của các thông số là hoàn thiện, người đánh giá cần thẩm tra phần còn lại của mô tả giao diện (mục đích, phương pháp sử dụng, các hoạt động, thông báo lỗi, v.v...) để xác định nếu các mô tả của (các) tham số được ghi trong mô tả. Người đánh giá cũng nên kiểm tra bằng chứng khác đã cung cấp (ví dụ, thiết kế TOE, thiết kế kiến trúc, hướng dẫn người sử dụng vận hành, biểu diễn triển khai) để xem xét nếu hành vi hoặc các tham số bổ sung được mô tả ở đó nhưng không có trong đặc tả chức năng.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.4.5.3.8  Đơn vị công việc ADV_FSP.5-8

Người đánh giá cần thẩm tra việc trình bày của các TSFI để xác định rằng nó mô tả đầy đủ và chính xác tất cả các hành động liên quan với mỗi TSFI.

Người đánh giá kiểm tra để đảm bảo rằng tất cả các hành động được mô tả, hành động có thể sử dụng thông qua giao diện mô tả những gì giao diện làm (trái ngược với thiết kế TOE, trong đó mô tả làm cách nào các hành động được cung cấp bởi các TSF).

Các hành động của một giao diện mô tả theo chức năng có thể gọi đến thống qua giao diện và có thể được phân loại như các hành động thường kỳ và các hành động liên quan SFR. Hành động thường kỳ mô tả những giao diện có. Lượng thông tin cung cấp cho mô tả này phụ thuộc vào sự phức tạp của giao diện. Những hành động liên quan SFR là những hành động có thể nhìn thấy ở bất cứ giao diện bên ngoài nào (ví dụ, hoạt động kiểm toán là nguyên nhân bởi việc gọi đến của giao diện (yêu cầu kiểm toán giả định trong ST) nên được mô tả, mặc dù kết quả của hành động này nói chung là không thể nhìn thy thông qua giao diện gọi đến). Tùy thuộc vào các thông số của giao diện, có thể có nhiều hành động khác nhau có thể được gọi đến thông qua giao diện (ví dụ, một API có thể có tham số đầu tiên là một "lệnh con", và các thông số tiếp theo sẽ cụ thể của lệnh con đó. IOCTLAPI trong hệ thống Unix là một ví dụ về một giao diện như vậy).

Để xác định rằng các mô tả về những hành động của TSFI là đầy đủ, người đánh giá cần soát xét phần còn lại của mô tả giao diện (mô tả tham số, các thông báo lỗi, v.v...) để xác định nếu mô tả các hành động được giải thích. Người đánh giá cũng nên phân tích các bằng chứng khác được cung cấp cho việc đánh giá (ví dụ, thiết kế TOE, mô tả kiến trúc an toàn, hướng dẫn người s hoạt động, biểu diễn triển khai) để xem xét nếu có bằng chứng về hành động được mô tả ở đó nhưng không có trong đặc tả chức năng

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.4.5.3.9  Đơn vị công việc ADV_FSP.5-9

Người đánh giá cần thẩm tra việc trình bày của TSFI để xác định rằng nó mô tả đầy đủ và chính xác tất cả các thông báo lỗi mà kết quả từ việc gọi đến mỗi TSFI.

Lỗi có thể có nhiều hình thức, tùy thuộc vào giao diện được mô tả. Đối với một API, giao diện chính nó có thể trả về một mã lỗi, thiết lập một điều kiện lỗi toàn cầu hoặc thiết lập một thông số nào đó với một mã lỗi. Đối với một tập tin cấu hình, thông số cấu hình không đúng có thể gây ra thông báo lỗi được ghi vào một tập tin đăng nhập. Đối với một card PCI phần cứng, điều kiện lỗi có thể làm tăng tín hiệu trên bus hoặc kích hoạt điều kiện ngoại lệ đối với CPU.

Lỗi (và các thông báo lỗi liên quan) xảy ra qua sự dẫn chứng của giao diện. Việc xử lý xảy ra đ đáp ứng với sự dẫn chứng của giao diện có thể gặp phải các điều kiện lỗi, mà kích hoạt (thông qua một cơ chế triển khai cụ thể) một thông báo lỗi đã được tạo ra. Trong trường hợp này, có thể là giá trị tr về từ giao diện chính nó; trong trường hợp khác, giá trị toàn cầu có thể được thiết lập và kiểm tra sau khi có sự dẫn chứng của giao diện. Có khả năng TOE sẽ có số thông báo lỗi ở mức độ thấp, có thể là kết quả của các điều kiện nguồn tài nguyên cơ bản, chẳng hạn như "đĩa đầy" hay "tài nguyên b khóa". Trong khi các thông báo lỗi này có thể ánh xạ đến một số lượng lớn các TSFI, chúng có thể được sử dụng đ phát hiện các trường hợp chi tiết từ mô tả giao diện đã được bỏ qua. Ví dụ, một TSFI cung cấp tin nhắn "đĩa đầy", nhưng không có mô tả rõ ràng về lý do tại sao TSFI cần tạo ra truy nhập vào đĩa trong mô tả của các hành động của nó, có thể người đánh giá thẩm tra các bằng chứng khác ((ADV_ARC), (ADV_TDS)) liên quan mà TSFI xác định nếu mô tả là chính xác.

Người đánh giá xác định rằng, đối với mỗi TSFI, việc thiết lập chính xác các thông báo lỗi có thể được trả lại trên giao diện gọi đến có thể được xác định. Người đánh giá xem xét các bằng chứng đã cung cấp cho giao diện để xác định nếu tập hợp các lỗi đã hoàn tất. Họ thẩm tra chéo thông tin này với bằng chứng khác được cung cấp cho việc đánh giá (ví dụ, thiết kế TOE, mô tả kiến trúc an toàn, hướng dẫn người sử dụng vận hành, biểu diễn triển khai) đ đảm bảo rằng không có lỗi sinh ra trong quá trình được đề cập ti mà không có chứa trong đặc tả chức năng.

10.4.5.3.10  Đơn vị công việc ADV_FSP.5-10

Người đánh giá cần thẩm tra việc trình bày của TSFI để xác định rằng nó mô tả đầy đủ và chính xác ý nghĩa của tất cả các lỗi liên quan với mỗi TSFI.

Để xác định chính xác, người đánh giá phải có khả năng hiểu ý nghĩa của lỗi. Ví dụ, nếu một giao diện trả về một mã số 0, 1 hoặc 2, người đánh giá sẽ không thể hiểu được lỗi nếu đặc tả chức năng chỉ được liệt kê: "lỗi có thể phát sinh từ gọi đến của giao diện foo() là 0, 1 hoặc 2". Thay vào đó, người đánh giá kiểm tra để đảm bảo rằng các lỗi được mô tả như: "lỗi có thể phát sinh từ gọi đến của giao diện foo() là 0 (xử lý thành công), 1 (tập tin không tìm thấy) hoặc 2 (mô tả tên tập tin không chính xác)".

Để xác định rằng các mô tả về lỗi do việc gọi đến của TSFI là đầy đủ, người đánh giá kiểm tra phần còn lại của mô tả giao diện (các mô tả tham số, các hành động, v.v..) để xác định nếu các điều kiện lỗi tiềm năng có thể là nguyên nhân do cách sử dụng như một giao diện được giải thích. Người đánh giá cũng nên kiểm tra bằng chứng khác được cung cấp cho việc đánh giá (ví dụ, thiết kế TOE, mô tả kiến trúc an toàn, hướng dẫn người sử dụng vận hành, biểu diễn triển khai) để xem xét nếu xử lý lỗi liên quan đến TSFI được mô tả ở đó nhưng không được mô tả trong đặc tả chức năng.

TCVN 8709-3 (ISO/IEC 15408-3) 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 TSFI.

10.4.5.3.11  Đơn vị công việc ADV_FSP.5-11

Người đánh giá cần thẩm tra đặc tả chức năng để xác định rằng nó mô tả đầy đủ và chính xác tất cả các thông báo lỗi mà không phải được gọi đến từ bất kỳ TSFI nào.

Đơn vị công việc này bổ sung cho đơn vị công việc ADV_FSP.5-9, trong đó mô tả các thông báo lỗi mà phải được gọi đến từ TSFI. Tóm lại, những đơn vị công việc bao gồm tất cả các thông báo lỗi có thể được tạo ra bởi các TSF.

Người đánh giá đánh giá đầy đủ và chính xác đặc tả chức năng bằng cách so sánh nội dung của nó với các trường hợp tạo ra thông báo lỗi trong các biểu diễn triển khai. Hầu hết các thông báo lỗi này sẽ được đề cập trong đơn vị công việc ADV_FSP.5-9.

Các thông báo lỗi liên quan đến đơn vị công việc này thường là loại không mong muốn, nhưng được kết cấu như một đối tượng tốt đ thực hành lập trình. Ví dụ, trường hợp tuyên bố định nghĩa các hành động từ mỗi danh sách các trường hợp có thể kết thúc với tuyên bố "else" cuối cùng đ áp dụng cho bất cứ điều gì có thể không được dự kiến; thực hành này đảm bảo TSF không nhận vào trạng thái không xác định. Tuy nhiên, nó không phải là dự kiến đưng dẫn thực hiện sẽ nhận được tuyên bố "else" này; Vì vậy, bất kỳ sự tạo ra thông báo lỗi trong tuyên bố "else" này sẽ không bao giờ được tạo ra. Mặc dù nó sẽ không được tạo ra, nhưng nó vẫn phải bao gồm trong đặc tả chức năng.

TCVN 8709-3 (ISO/IEC 15408-3) 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 triển khai TSF nhưng kết quả không phải từ lệnh gọi đến TSFI.

10.4.5.3.12  Đơn vị công việc ADV_FSP.5-12

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định rằng nó cung cấp sở cứ cho mỗi thông báo lỗi chứa trong triển khai TSF nhưng kết quả không phải từ lệnh gọi đến TSFI.

Người đánh giá đảm bảo rằng tất cả các thông báo lỗi tìm thấy trong đơn vị công việc ADV_FSP.5-11 chứa sở cứ mô tả lý do tại sao nó không thể được gọi đến từ TSFI.

Như đã mô tả trong các đơn vị công việc trước đó, s cứ này có thể đơn giản như thực tế thông báo lỗi trong câu hỏi được cung cấp đối với tính hoàn thiện của logic thực hiện và nó không bao giờ dự kiến sẽ được tạo ra. Người đánh giá đảm bảo rằng sở cứ cho mỗi thông báo lỗi như vậy là hợp lý.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_FSP.5.9C: Theo dấu cần chứng minh rằng các SFR theo dấu đến các TSFI trong các đặc tả chức năng.

10.4.5.3.13  Đơn vị công việc ADV_FSP.5-13

Người đánh giá cần kiểm tra rằng các liên kết theo dấu các SFR theo các TSFI tương ứng.

Theo dấu được cung cấp bởi các nhà phát triển để phục vụ như một hướng dẫn mà các SFR liên quan đến các TSFI. Theo dấu này có thể đơn giản là một bảng; nó được sử dụng làm đầu vào cho người đánh giá sử dụng trong các đơn vị công việc tiếp theo, trong đó người đánh giá xác minh tính đầy đủ và chính xác của nó.

10.4.5.4  Hành động ADV_FSP.5.2E

10.4.5.4.1  Đơn vị công việc ADV_FSP.5-14

Người đánh giá cần thẩm tra các đặc tả chức năng để xác định rằng đó là thuyết minh đầy đủ của các SFR.

Đ đảm bảo rằng tất cả các SFR được bao phủ bởi các đặc tả chức năng, cũng như phân tích độ bao phủ kiểm thử, người đánh giá có thể xây dựng dựa trên theo du của nhà phát triển (xem ADV_FSP.5-13 ánh xạ giữa các yêu cầu chức năng an toàn của TOE và TSFI). Lưu ý rằng ánh xạ này có thể có được ở mức độ chi tiết dưới mức thành phần hoặc thậm chí mức phần tử của các yêu cầu, bởi vì các hoạt động (chỉ định, bổ sung chi tiết, lựa chọn) thực hiện trên các yêu cầu chức năng của tác giả ST.

Ví dụ, các thành phần FDP_ACC.1 chứa các chỉ định trong một phần tử. Ví dụ, nếu ST chứa mười quy tắc trong chỉ định FDP_ACC.1 và mười quy tắc này được bao phủ bởi ba TSFI khác nhau, nó sẽ không đ để người đánh giá ánh xạ FDP_ACC.1 theo hướng TSFI A, B và C và yêu cầu chúng hoàn thành các đơn vị công việc. Thay vào đó, người đánh giá sẽ ánh xạ FDP_ACC.1 (quy tắc 1) theo hướng TSFI A; FDP_ACC.1 (quy tắc 2) theo hướng TSFI B; v.v... Nó cũng có thể là trường hợp mà giao diện là một giao diện bao (ví dụ lOCTl...), trong trường hợp đó ánh xạ sẽ cần phải được cụ thể tới tập các thông số cho giao diện nhất định.

Người đánh giá phải thừa nhận rằng đối với các yêu cầu có ít hoặc không có biểu hiện tại ranh giới TSF (ví dụ, FDP_RIP) người đánh giá không kỳ vọng ánh xạ toàn bộ các yêu cầu này đến TSFI. Việc phân tích cho những yêu cầu này sẽ được thực hiện trong phân tích thiết kế TOE (ADV_TDS) khi đưa vào ST. Điều này cũng quan trọng với lưu ý rằng vì các thông số liên quan đến các TSFI phải được xác định đầy đủ, người đánh giá nên xác định nếu tất cả các khía cạnh xuất hiện trong SFR được triển khai tại mức giao diện.

10.4.5.4.2  Đơn vị công việc ADV_FSP.5-15

Người đánh giá cần thẩm tra đặc tả chức năng để xác định rằng nó là sự chứng minh chính xác của các SFR.

Đối với mỗi yêu cầu chức năng trong ST mà kết quả trong các hiệu ứng có thể nhìn thy ở ranh giới TSF, thông tin trong TSFI liên quan để yêu cầu riêng của chức năng được yêu cầu đã mô tả bằng yêu cầu. Ví dụ, nếu ST có một yêu cầu đối với các danh sách kiểm soát truy cập và chỉ TSFI này ánh xạ để yêu cầu ch rõ chức năng đối với các bit bảo vệ kiểu Unix, sau đó các đặc tả chức năng không chính xác đối với chi tiết của các yêu cầu.

Người đánh giá phải thừa nhận rằng đối với các yêu cầu này có ít hoặc không có biểu hiện tại ranh giới TSF (ví dụ, FDP_RIP) nó không kỳ vọng rằng người đánh giá ánh xạ toàn bộ các yêu cầu này đến TSFI. Việc phân tích cho những yêu cầu này sẽ được thực hiện trong phân tích thiết kế TOE (ADV_TDS) khi đưa vào ST.

10.4.6  Đánh giá hoạt động con (ADV_FSP.6)

Không có hướng dẫn chung; Nên tư vấn lược đồ để hướng dẫn hoạt động con này.

10.5  Biểu diễn triển khai (ADV_IMP)

10.5.1  Đánh giá hoạt động con (ADV_IMP.1)

10.5.1.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định rằng các biểu diễn triển khai được chuẩn bị sẵn sàng bởi nhà phát triển là phù hợp để sử dụng trong các hoạt động phân tích khác; phù hợp được đánh giá bằng sự tuân thủ của nó với các yêu cầu đối với phần này.

10.5.1.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) biểu diễn triển khai;

b) tài liệu của các công cụ phát triển, là kết quả của ALC_TAT;

c) mô tả thiết kế TOE.

10.5.1.3  Lưu ý áp dụng

Toàn bộ biểu diễn triển khai được chuẩn bị sẵn sàng để đảm bảo rằng các hoạt động phân tích không bị rút ngắn do thiếu thông tin. Tuy vậy, điều này không có ngầm định rằng tất cả các biểu diễn được thẩm tra khi các hoạt động phân tích đang được thực hiện. Điều này không thực tế trong hầu hết các trường hợp, ngoài thực tế 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. Đối với hoạt động con này, điều này đáng tin cậy. Nó sẽ không cung cấp cho người đánh giá mà để dành một lượng lớn thời gian xác minh các yêu cầu cho một phần của biểu diễn triển khai và sau đó sử dụng một phần khác của biểu diễn triển khai trong việc thực hiện phân tích cho các đơn vị công việc khác. Do đó, người đánh giá được khuyến khích chọn mẫu của biểu diễn triển khai từ các lĩnh vực TOE sẽ được quan tâm nhất trong việc phân tích thực hiện trong các đơn vị công việc từ các họ khác (ví dụ ATE_IND, AVA_VAN và ADV_INT).

10.5.1.4  Hành động ADV_IMP.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.5.1.4.1  Đơn vị công việc ADV_IMP.1-1

Người đánh giá cần kiểm tra rằng các biểu diễn triển khai đị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.

Mã nguồn hoặc sơ đồ phần cứng và/hoặc mã ngôn ngữ thiết kế phần cứng IC hoặc dữ liệu bố trí được sử dụng để xây dựng phần cứng thực tế là những ví dụ về các phần của biểu diễn triển khai. Người đánh giá lấy mẫu các biu diễn triển khai để tăng độ tin cậy rằng nó đang ở mức thích hợp và không thích hợp, ví dụ, một mức mã giả với yêu cầu thực hiện các quyết định thiết kế bổ sung. Người đánh giá được khuyến khích thực hiện kiểm tra nhanh khi lần đầu tiên kiểm tra biểu diễn triển khai để đảm bảo rằng bản thân các nhà phát triển đang đi đúng hướng. Tuy nhiên, người đánh giá cũng được khuyến khích thực hiện phần lớn các kiểm tra này khi làm việc trên đơn vị công việc khác khi truy xuất để thẩm tra triển khai; điều này sẽ đảm bảo mẫu thẩm tra cho đơn vị công việc này là có liên quan.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.5.1.4.2  Đơn vị công việc ADV_lMP.1-2

Người đánh giá cần kiểm tra biểu diễn triển khai dưới dạng được sử dụng bởi các cá nhân phát triển.

Biểu diễn triển khai được thao tác bởi nhà phát triển dưới hình thức phù hợp cho chuyển đổi đ triển khai 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, được biên dịch để cuối cùng tr thành một phần của TSF. Nhà phát triển chuẩn bị sẵn sàng biểu diễn triển khai dưới dạng họ sử dụng, do đó, người đánh giá 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ự tự tin cho các biểu diễn triển khai đã thẩm tra là thực sự sử dụng trong sản xuất của TSF (trái ngược với trường hợp được cung cấp theo định dạng trình diễn thay thế, chẳng hạn như một phần mềm xử lý văn bản). Cần lưu ý rằng các dạng 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 cũng tốt. Mục tiêu tổng thể là cung cấp cho người đánh giá với thông tin sẽ tối đa hóa những nỗ lực phân tích của người đánh giá.

Người đánh giá lấy mẫu các biểu diễn triển khai để tăng độ tin cậy rằng nó đang ở phiên bản có thể sử dụng bởi nhà phát triển. Mu này khiến người đánh giá đảm bảo rằng tất cả các vùng của biểu diễn triển khai là sự phù hợp với yêu cầu; tuy nhiên, thẩm tra đầy đủ toàn bộ biểu diễn triển khai là không được yêu cầu.

Quy ước trong một số hình thức biểu diễn triển khai có thể làm cho nó khó hoặc không thể xác định được từ biểu diễn triển khai của chính nó những gì mà các kết quả thực tế của việc biên soạn hoặc thời gian chạy sẽ làm sáng t. Ví dụ, chỉ thị biên dịch cho các trình biên dịch ngôn ngữ C sẽ làm cho các trình biên dịch loại trừ hoặc bao gồm toàn bộ các phần mã.

Một số hình thức của các biểu diễn triển khai có thể yêu cầu thêm thông tin vì chúng tạo ra những rào cn đáng kể để hiểu 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 hiu 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 tạo 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 biểu diễn bị che khuất là những gì được biên dịch và có thể được gần hơn để triển khai (trong các thuật ngữ về cấu trúc) so với ban đầu, biểu 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 các nhiệm v gọi đến biểu 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ụ/thuật toán b che khuất được sử dụng để biểu điệ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ự tự tin trong quá trình bị che khuất không làm tổn hại bất kỳ cơ chế an toàn nào.

Người đánh giá lấy mẫu các biểu diễn triển khai để tăng độ tin cậy rằng tất cả các thông tin được yêu cầu để giải thích cho biểu diễn triển khai đã được cung cấp. Lưu ý rằng các công cụ này là một trong số những công cụ được tham chiếu bởi các thành phần Công cụ và kỹ thuật (ALC_TAT). Người đánh giá được khuyến khích thực hiện kiểm tra nhanh khi lần đầu tiên kiểm tra biểu diễn triển khai để đảm bảo rằng bản thân các nhà phát triển đang đi đúng hướng. Tuy nhiên, người đánh giá cũng được khuyến khích thực hiện phần lớn để thẩm tra triển khai; điều này sẽ đảm bảo mẫu thẩm tra cho đơn vị công việc này là có liên quan.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_IMP.1.3C: Ánh xạ giữa mô tả thiết kế TOE và ví dụ biểu diễn triển khai cần chứng minh sự đáp ứng của nó.

10.5.1.4.3  Đơn vị công việc ADV_lMP.1-3

Người đánh giá cần thẩm tra ánh xạ giữa mô tả thiết kế TOE và mẫu của biểu diễn triển khai để xác định rằng nó là chính xác.

Người đánh giá làm tăng việc xác định sự tồn tại (quy định tại đơn vị công việc ADV_IMP.1-1) bằng cách thẩm tra độ chính xác một phần của biểu diễn triển khai và mô tả thiết kế TOE. Đối với các phần của mô tả thiết kế TOE đáng quan tâm, người đánh giá sẽ thm tra việc biểu diễn triển khai phn ánh chính xác mô tả được cung cấp trong mô tả thiết kế TOE.

Ví dụ, mô tả thiết kế TOE có thể xác định một mô đun đăng nhập được sử dụng để xác định và xác thực người dùng. Nếu xác thực người dùng là đủ lớn, người đánh giá sẽ thẩm tra các mã tương ứng trên thực tế triển khai các dịch vụ như mô tả trong mô tả thiết kế TOE. Nó cũng có thể đáng để thẩm tra rằng mã chấp nhận các thông số như mô tả trong đặc tả chức năng.

Đây là giá trị ch ra nhà phát triển phải chọn liệu có thực hiện ánh xạ cho toàn bộ biểu diễn triển khai không, do đó đảm bảo các mẫu lựa chọn sẽ được bao phủ hoặc đợi để lựa chọn mẫu trước khi thực hiện việc ánh xạ. Lựa chọn đầu tiên là công việc có khả năng hơn, nhưng có thể được hoàn thành trước khi đánh giá bắt đầu. Lựa chọn thứ hai ít khả năng hơn, nhưng sẽ tạo ra sự ngừng lại của hoạt động đánh giá trong khi bằng chứng được yêu cầu đang được tạo ra.

10.5.2  Đánh giá hoạt động con (ADV_IMP.2)

Không có hướng dẫn chung; Nên tư vấn lược đồ để hướng dẫn hoạt động con này.

10.6  Nội bộ TSF (ADV_INT)

10.6.1  Đánh giá hoạt động con (ADV_INT.1)

10.6.1.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu định nghĩa tập con của TSF được thiết kế và cấu trúc như vậy thì khả năng xảy ra lỗ hổng có giảm và bảo trì có thể được thực hiện dễ dàng hơn mà không cn tạo ra các lỗ hổng không.

10.6.1.2  Đu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) mô tả thiết kế TOE;

c) biểu diễn triển khai (nếu ADV_IMP là một phần của yêu cầu bảo đảm);

d) mô tả kiến trúc;

e) tài liệu hướng dẫn các tiêu chuẩn mã hóa, là kết quả của ALC_TAT.

10.6.1.3  Lưu ý áp dụng

Vai trò của mô tả nội bộ là cung cấp bằng chứng về cấu trúc của thiết kế và triển khai của TSF.

Cấu trúc của thiết kế có hai phần: các phần cấu thành TSF và các thủ tục được sử dụng để thiết kế TSF. Trong trường hợp khi TSF được thiết kế phù hợp với thiết kế đại diện bi các thiết kế TOE (xem ADV_TDS), việc đánh giá các thiết kế TSF là hiển nhiên. Trong trường hợp khi các thủ tục thiết kế TSF đang được quan sát (xem ALC_TAT), việc đánh giá các thủ tục thiết kế TSF là rõ ràng tương tự. Trong trường hợp khi TSF được triển khai bằng cách sử dụng phần mềm trên cơ sở thủ tục, cấu trúc này được đánh giá trên cơ sở hệ mô đun của nó; các mô đun được xác định trong mô tả nội bộ cũng giống như các mô đun được xác định trong thiết kế TOE (thiết kế TOE (ADV TDS)). Một mô đun bao gồm một hoặc nhiều tập tin mã nguồn mà không thể được phân chia thành các đơn vị biên dịch nhỏ hơn.

Việc sử dụng các ch định trong phần này hạn chế chặt chẽ các khon thu trên các tập con của TSF được xác định một cách rõ ràng trong chỉ định ADV_INT.1.1D hơn so với phần còn lại của TSF. Trong khi TSF toàn bộ được thiết kế để sử dụng các nguyên tắc kỹ thuật và kết quả của TSF cấu trúc rõ ràng, ch tập con quy định được phân tích cụ thể cho bản chất này. Người đánh giá xác định rằng kết quả tiêu chuẩn mã hóa ứng dụng của nhà phát triển trong TSF là dễ hiu.

Mục tiêu chính của phần này là đảm bảo biểu diễn triển khai các tập con của TSF là dễ hiểu để tạo điều kiện bảo trì và phân tích (của c nhà phát triển và người đánh giá).

10.6.1.4  Hành động ADV_INT.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) ADV_INT.1.1C: Biện minh cần giải thích các bản chất được sdụng đ xem xét ý nghĩa của "cấu trúc rõ ràng".

10.6.1.4.1  Đơn vị công việc ADV_INT.1-1

Người đánh giá cần thẩm tra sự biện minh để xác định rằng nó nhận dạng chuẩn để xác định liệu TSF có cấu trúc rõ ràng không.

Người đánh giá thẩm tra các tiêu chí để xác định bản chất của cấu trúc rõ ràng được định nghĩa rõ ràng trong sự biện minh. Tiêu chí có thể chấp thuận thường bắt nguồn từ tiêu chuẩn công nghiệp đối với quy tắc công nghệ. Ví dụ, phần mềm thủ tục thực thi tuyến tỉnh truyền thống được xem là có cấu trúc rõ ràng nếu nó tuân thủ các thực hành lập trình công nghệ phần mềm, chẳng hạn như những quy định trong tiêu chuẩn IEEE (IEEE Std 610.12-1990). Ví dụ, nó sẽ nhận dạng tiêu chí cho các phần của phần mềm thủ tục của các tập con TSF:

a) tiến trình được sử dụng để phân tách mô đun,

b) tiêu chuẩn mã hóa được sử dụng trong phát triển triển khai,

c) mô tả về mức độ tối đa có thể chấp nhận ghép nối liên mô đun tạo ra bởi các tập con TSF và

d) mô tả về mức độ tối thiểu có thể chấp nhận sự gắn kết tạo ra các mô đun của tập con TSF.

Đối với các loại công nghệ được sử dụng trong TOE - chẳng hạn như phần mềm không theo thủ tục (ví dụ như lập trình hướng đối tượng), phần cứng hàng hóa phổ biến (ví dụ như bộ vi xử lý máy tính) và phần cứng đặc biệt (ví dụ như bộ vi xử lý thẻ thông minh) - người đánh giá nên tìm kiếm hướng dẫn từ tổ chức đánh giá để xác định sự phù hợp của các tiêu chí đối với "cấu trúc rõ ràng".

TCVN 8709-3 (ISO/IEC 15408-3) ADV_INT.1.2C: Mô tả các tính chất của TSF cần chứng minh rằng tập con được chỉ định của TSF là được cu trúc rõ ràng.

10.6.1.4.2  Đơn vị công việc ADV_INT.1-2

Người đánh giá cần kiểm tra việc mô tả tính chất của TSF để xác định rằng nó xác định tập con được chỉ định của TSF.

Tập con này có thể được xác định trong các thuật ngữ của TSF nội bộ tại bất kỳ lớp trừu tượng nào. Ví dụ, nó có thể có trong các thuật ngữ các yếu tố cấu trúc của TSF được nhận dạng trong thiết kế TOE (ví dụ như các hệ thống con kiểm toán) hoặc trong các thuật ngữ của triển khai (ví dụ các tập tin encrypt.cdecrypt.c hoặc chip IC 6227).

Sẽ không đủ khi xác định tập con này trong các thuật ngữ các SFR được yêu cầu (ví dụ như các phần của TSF cung cấp giấu tên như xác định tại FPR_ANO.2) vì điều này không chỉ ra nơi tập trung phân tích.

10.6.1.4.3  Đơn vị công việc ADV_INT.1-3

Người đánh giá cần thẩm tra mô tả tính chất của TSF để xác định rằng nó chứng minh tập con TSF được chỉ định có cấu trúc rõ ràng.

Người đánh giá thẩm tra các mô tả tính chất để đảm bảo rằng nó cung cấp giải thích hợp lý đ tập con TSF đáp ứng các tiêu chí từ ADV_INT.1-1.

Ví dụ, nó sẽ giải thích cách thức các phần của phần mềm thủ tục của các tập con TSF đáp ứng những điều kiện sau đây:

a) rằng có một sự tương ứng một-một giữa các mô đun được xác định trong tập con TSF và các mô đun được mô tả trong thiết kế TOE (ADV_TDS),

b) cách thiết kế TSF là một sự phản ánh của quá trình phân tách mô đun,

c) sự biện minh đối với tất cả các trường hợp khi các tiêu chuẩn mã hóa không được sử dụng hoặc đáp ứng và

d) sự biện minh đối với bất kỳ ghép nối hoặc sự gắn kết bên ngoài phạm vi có thể chấp nhận được.

10.6.1.5  Hành động ADV_INT.1.2E

10.6.1.5.1  Đơn vị công việc ADV_INT.1-4

Người đánh giá cần xác định rằng thiết kế TOE cho tập con TSF được chỉ định là cấu trúc rõ ràng. Người đánh giá thẩm tra mẫu thiết kế TOE để thẩm tra tính chính xác của sự biện minh. Ví dụ, một mẫu thiết kế TOE được phân tích để xác định sự tuân thủ của nó với các tiêu chuẩn thiết kế, v.v... Như với tất cả các lĩnh vực nơi người đánh giá thực hiện các hoạt động trên một tập con, người đánh giá cung cấp một sự biện minh của kích thước và phạm vi áp dụng mẫu.

Mô tả sự phân tách của TOE thành hệ thống con và các mô đun sẽ tạo ra lập luận rằng tập con của TSF là cấu trúc rõ ràng hiển nhiên. Sự thẩm tra các thủ tục đối với cấu trúc TSF (như thẩm tra trong ALC_TAT) đang xảy ra sẽ là hiển nhiên với tập con TSF có cấu trúc rõ ràng.

10.6.1.5.2  Đơn vị công việc ADV_INT.1-5

Người đánh giá cần xác định rằng tập con TSF được chỉ định có cấu trúc rõ ràng.

Nếu ADV_IMP không phải là một phần của việc bảo đảm yêu cầu thì đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá thẩm tra mẫu của tập con TSF để thẩm tra tính chính xác của mô tả các tính chất. Ví dụ, mẫu của các phần của phần mềm thủ tục của tập con TSF được phân tích để xác định sự gắn kết và ghép nối của nó, nó gắn kết với các tiêu chuẩn mã hóa, v.v... Như với tất cả các lĩnh vực nơi người đánh giá thực hiện các hoạt động trên một tập con, người đánh giá cung cấp một sự biện minh của kích thước và phạm vi áp dụng mẫu.

10.6.2  Đánh giá hoạt động con (ADV_INT.2)

10.6.2.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu định nghĩa TSF được thiết kế và cấu trúc như vậy thì khả năng xảy ra lỗ hỗng có giảm và bảo trì có thể được thực hiện dễ dàng hơn mà không cần tạo ra các lỗ hổng.

10.6.2.2  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) mô tả thiết kế TOE;

b) biểu diễn triển khai (nếu ADV_IMP là một phần của yêu cầu bảo đảm);

c) mô tả kiến trúc;

d) tài liệu hướng dẫn các tiêu chuẩn mã hóa, là kết quả của ALC_TAT.

10.6.2.3  Lưu ý áp dụng

Vai trò của mô tả nội bộ là cung cấp bằng chứng về cấu trúc của thiết kế và triển khai của TSF.

Cấu trúc của thiết kế có hai phần: các phần cấu thành TSF và các thủ tục được sử dụng để thiết kế TSF. Trong trường hợp khi TSF được thiết kế phù hợp với thiết kế đại diện bởi các thiết kế TOE (xem ADV_TDS), việc đánh giá các thiết kế TSF là hiển nhiên. Trong trường hợp khi các thủ tục thiết kế TSF đang được quan sát (xem ALC_TAT), việc đánh giá các thủ tục thiết kế TSF là hiển nhiên tương tự.

Trong trường hợp khi TSF được triển khai bằng cách sử dụng phần mềm thủ tục cơ sở, cấu trúc này được đánh giá trên cơ sở hệ mô đun của nó; các mô đun được xác định trong mô tả nội bộ cũng giống như các mô đun được xác định trong thiết kế TOE (thiết kế TOE (ADV_TDS)). Một mô đun bao gồm một hoặc nhiều tập tin mã nguồn mà không thể được phân chia thành các đơn vị biên dịch nhỏ hơn. Mục tiêu chính của phần này là đảm bảo biểu diễn triển khai các tập con của TSF là dễ hiểu để tạo điều kiện bảo trì và phân tích (của cả nhà phát triển và người đánh giá).

10.6.2.4  Hành động ADV_INT.2.1E

TCVN 8709-3 (ISO/IEC 15408-3) ADV_INT.2.1C: Sự biện minh cần mô tả các tính chất sử dụng để thẩm tra ý nghĩa của "cấu trúc rõ ràng".

10.6.2.4.1  Đơn vị công việc ADV_INT.2-1

Người đánh giá cn thẩm tra sự biện minh để xác định rằng nó nhận dạng chuẩn để xác định liệu TSF có cấu trúc rõ ràng không.

Người đánh giá thẩm tra các tiêu chí để xác định bản chất của cấu trúc đầy đủ được định nghĩa rõ ràng trong sự biện minh. Tiêu chí có thể chấp thuận thường bắt nguồn từ tiêu chuẩn công nghiệp đối với quy tắc công nghệ. Ví dụ, phần mềm thủ tục thực thi tuyến tính truyền thống được xem là có cấu trúc rõ ràng nếu nó tuân thủ các thực hành lập trình công nghệ phần mềm, chẳng hạn như những quy định trong tiêu chuẩn IEEE (IEEE Std 610.12-1990). Ví dụ, nó sẽ nhận dạng tiêu chí cho các phần của phần mềm thủ tục của các tập con TSF:

a) quá trình được sử dụng để phân tách mô đun,

b) tiêu chuẩn mã hóa được sử dụng trong phát triển triển khai,

c) mô tả về mức độ tối đa có thể chấp nhận ghép nối liên mô đun tạo ra bởi các tập con TSF và

d) mô tả về mức độ tối thiểu có thể chấp nhận sự gắn kết tạo ra các mô đun của tập con TSF.

Đối với các loại công nghệ được sử dụng trong TOE - chẳng hạn như phần mềm không theo thủ tục (ví dụ như lập trình hướng đối tượng), phần cứng hàng hóa phổ biến (ví dụ như bộ vi xử lý máy tính) và phần cứng đặc biệt (ví dụ như bộ vi xử lý thẻ thông minh) - người đánh giá nên tìm kiếm hướng dẫn từ tổ chức đánh giá để xác định sự phù hợp của các tiêu chí đối với "cấu trúc rõ ràng".

TCVN 8709-3 (ISO/IEC 15408-3) ADV_INT.2.2C: Mô tả tính chất TSF cần chứng minh rằng toàn bộ TSF có cấu trúc rõ ràng.

10.6.2.4.2  Đơn vị công việc ADV_INT.2-2

Người đánh giá cần thẩm tra mô tả tính chất của TSF để xác định rằng nó chứng minh tập con TSF được ch đnh có cấu trúc rõ ràng.

Người đánh giá thẩm tra các mô tả tính chất để đảm bảo rằng nó cung cấp lời giải thích hợp lý như thế nào để tập con TSF đáp ứng các tiêu chí từ ADV_INT.1-1.

Ví dụ, nó sẽ giải thích cách thức các phần của phần mềm thủ tục của các tập con TSF đáp ứng những điều kiện sau đây:

a) rằng có một sự tương ứng một-một giữa các mô đun được xác định trong tập con TSF và các mô đun được mô tả trong thiết kế TOE (ADV_TDS),

b) cách thiết kế TSF là một sự phản ánh của quá trình phân tách mô đun,

c) sự biện minh đối với tất cả các trường hợp khi các tiêu chuẩn mã hóa không được sử dụng hoặc đáp ứng và

d) sự biện minh đối với bất kỳ ghép nối hoặc sự gắn kết bên ngoài phạm vi có thể chấp nhận được.

10.6.2.5  Hành động ADV_INT.2.2E

10.6.2.5.1  Đơn vị công việc ADV_INT.2-3

Người đánh giá cần xác định rằng thiết kế TOE có cấu trúc rõ ràng.

Người đánh giá thẩm tra mẫu thiết kế TOE của TSF để thẩm tra tính chính xác của sự biện minh. Ví dụ, một mẫu thiết kế TOE được phân tích để xác định sự tuân thủ của nó với các tiêu chuẩn thiết kế, v.v... Như với tất cả các lĩnh vực nơi người đánh giá thực hiện các hoạt động trên một tập con, người đánh giá cung cấp một sự biện minh của kích thước và phạm vi áp dụng mẫu.

Mô tả sự phân tách của TOE thành hệ thống con và các mô đun sẽ tạo ra lập luận rằng tập con của TSF là cấu trúc rõ ràng hiển nhiên. Sự thẩm tra các thủ tục đối với cấu trúc TSF (như thẩm tra trong ALC_TAT) đang xảy ra sẽ là hiển nhiên với tập con TSF có cấu trúc rõ ràng.

10.6.2.5.2  Đơn vị công việc ADV_INT.2-4

Người đánh giá cần xác định rằng tập con TSF được chỉ định có cấu trúc rõ ràng.

Nếu ADV_IMP không phải là một phần của việc bảo đảm yêu cầu, thì đơn vị công việc này không áp dụng và do đó được coi là thỏa mãn.

Người đánh giá thẩm tra mẫu của tập con TSF để thẩm tra tính chính xác của mô tả các tính chất. Ví dụ, mẫu của các phần của phần mềm thủ tục của tập con TSF được phân tích để xác định sự gắn kết và ghép nối của nó, nó gắn kết với các tiêu chuẩn mã hóa, v.v... Như với tất cả các lĩnh vực nơi người đánh giá thực hiện các hoạt động trên một tập con, người đánh giá cung cấp một sự biện minh của kích thước và phạm vi áp dụng mẫu.

10.6.3  Đánh giá hoạt động con (ADV_INT.3)

Không có hướng dẫn chung; Nên tư vấn lược đồ để hướng dẫn hoạt động con này.

10.7  Mô hình hóa chính sách an toàn (ADV_SPM)

10.7.1  Đánh giá hoạt động con (ADV_SPM.1)

Không có hướng dẫn chung; Nên tư vấn lược đồ để hướng dẫn hoạt động con này.

10.8  Thiết kế TOE (ADV_TDS)

10.8.1  Đánh giá hoạt động con (ADV_TDS.1)

10.8.1.1  Đầu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) đặc tính chức năng;

c) đặc tả kiến trúc an toàn;

d) thiết kế TOE.

10.8.1.2  Hành động ADV_TDS.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.8.1.2.1  Đơn vị công việc ADV.TDS.1-1

Người đánh giá cần thẩm tra thiết kế TOE đ xác định rằng cấu trúc của toàn bộ TOE được mô tả trong thuật ngữ các hệ thống con.

Người đánh giá đảm bảo rằng tất cả các hệ thống con của TOE được xác định. Đặc tả này của TOE sẽ được sử dụng như đầu vào cho đơn vị công việc ADV_TDS.1-2, nơi các thành phần của TOE tạo nên TSF được xác định. Do đó, yêu cầu này là trên toàn bộ TOE chứ không phải chỉ cho TSF.

TOE (và TSF) có thể được mô tả trong nhiều lớp trừu tượng (ví dụ: các hệ thống con và các mô đun). Tùy thuộc vào sự phức tạp của TOE, thiết kế của nó có thể được mô tả trong các thuật ngữ của các hệ thống con và mô đun, như đã mô tả trong TCVN 8709-3 (ISO/IEC 15408-3) Phụ lục A.4, ADV_TDS: Các hệ thống con và các mô đun. Ở cấp độ đảm bảo này, sự chia tách ch cần ở mức "hệ thống con".

Khi thực hiện hoạt động này, người đánh giá thẩm tra bằng chứng khác đối với TOE (ví dụ: ST, hướng dẫn người sử dụng của nhà khai thác) để xác định rằng mô tả TOE trong bằng chứng như vậy là nhất quán với mô tả có trong thiết kế TOE.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.8.1.2.2  Đơn vị công việc ADV_TDS.1-2

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng tất cả các hệ thống con của TSF được xác định.

Trong đơn vị công việc ADV_TDS.1-1, tất cả các hệ thống con của TOE đã được xác định và quyết định ch ra rằng các hệ thống con không TSF được đặc tả một cách chính xác. Dựa trên công việc đó, các hệ thống con không được đặc tả như là hệ thống con không TSF nên xác định một cách chính xác. Người đánh giá xác định rằng, trong những phần cứng và phần mềm được cài đặt và cấu hình theo hướng dẫn cho các thủ tục chuẩn bị (AGD_PRE), mỗi hệ thống con đã được xác định như là hoặc một phần của TSF hoặc không.

TCVN 8709-3 (ISO/IEC 15408-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 can thiệp SFR ở mức độ chi tiết đủ để khẳng định nó không phải là kiểu thực thi SFR.

10.8.1.2.3  Đơn vị công việc ADV_TDS.1-3

Người đánh giá cn thẩm tra thiết kế TOE để xác định rằng mỗi hệ thống con hỗ trợ SFR hoặc không can thiệp SFR của TSF được mô tả sao cho người đánh giá có thể xác định rằng hệ thống con là hỗ trợ SFR hoặc không can thiệp SFR.

Các hệ thống con hỗ trợ SFR và không can thiệp SFR không cần được mô tả chi tiết chức năng của chúng trong hệ thống như thế nào. Tuy nhiên, người đánh giá tạo ra quyết định dựa trên các bằng chứng được cung cấp bởi nhà phát triển, rằng các hệ thống con không mô tả cấp cao là hỗ trợ SFR hoặc không can thiệp SFR. Lưu ý rằng nếu nhà phát triển cung cấp một mức thống nhất tài liệu chi tiết thì đơn vị công việc này sẽ là thỏa mãn đầy đủ, kể từ thời điểm phân loại các hệ thng con cho phép nhà phát triển cung cấp ít thông tin hơn cho các hệ thống con hỗ trợ SFR và không can thiệp SFR so với các hệ thống con thực thi SFR.

Một hệ thống con hỗ trợ SFR là một hệ thống con phụ thuộc vào một hệ thống con thực thi SFR để thực hiện một SFR, nhưng không đóng vai trò trực tiếp như là một hệ thống con thực thi SFR. Một hệ thống con không can thiệp SFR là một hệ thống con không phụ thuộc, trong vai trò hoặc hỗ trợ hoặc thực thi, khi thực hiện một SFR.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.1.4C: Bản thiết kế cần tóm lược hoạt động thực thi SFR cho các hệ thống con kiểu thực thi SFR.

10.8.1.2.4  Đơn v công việc ADV_TDS.1-4

Người đánh giá cần thẩm tra việc thiết kế TOE để xác định rằng nó cung cấp một sự đặc tả cách đầy đủ, chính xác và ở mức cao của hoạt động thực thi SFR cho các hệ thống con kiểu thực thi SFR.

Nhà phát triển có thể chỉ định các hệ thống con như là thực thi SFR, hỗ trợ SFR và không can thiệp SFR, nhưng các "th" này chỉ được sử dụng để mô tả số lượng và loại thông tin mà nhà phát triển phải cung cấp và có thể được sử dụng để hạn chế số lượng thông tin nhà phát triển phải phát triển nếu quy trình kỹ thuật của họ không tạo ra các tài liệu được yêu cầu. Liệu các hệ thống con có được phân loại bởi nhà phát triển hay không, người đánh giá có trách nhiệm xác định các hệ thống con có các thông tin thích hợp cho vai trò của chúng (thực thi SFR, v.v...) trong TOE và để có được những thông tin thích hợp từ nhà phát triển nên lỗi của nhà phát triển cung cấp là thông tin được yêu cầu cho một hệ thống con cụ thể.

Hoạt động thực thi SFR liên quan đến "làm thế nào" một hệ thống con cung cấp chức năng thực hiện một SFR. Một mô tả mức cao không cần phải đề cập đến cấu trúc dữ liệu cụ thể (mặc dù có thể), mà thay vào đó đề cập nhiều hơn đến luồng dữ liệu chung, lưu lượng tin nhắn và các mối quan hệ kiểm soát trong một hệ thống con. Mục tiêu của những mô tả này là cung cấp cho người đánh giá đủ thông tin để hiểu "làm thế nào" mà hoạt động thực thi SFR được thực hiện. Lưu ý rằng người đánh giá cần tìm khẳng định không thể chấp nhn thực thi SFR trong các tài liệu thiết kế TOE cho đơn vị công việc này. Cần lưu ý rằng đó là quyết tâm của đánh giá đối với những gì "mức cao" có nghĩa là cho một TOE đặc biệt và người đánh giá thu thập đầy đủ thông tin từ nhà phát triển để tạo ra nhận định hợp lý cho đơn vị công việc này.

Đ xác định tính hoàn thiện và chính xác, người đánh giá thẩm tra các thông tin có sẵn khác (ví dụ, đặc tính kỹ thuật, mô tả kiến trúc an toàn, biểu diễn triển khai). Mô tả các chức năng trong các tài liệu này nên nhất quán với những gì đã cung cấp cho bằng chứng đối với đơn vị công việc này.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.1.5C: Bản thiết kế cn tạo ra mô tả về tương tác của các hệ thống con kiểu thực thi 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.

10.8.1.2.5  Đơn vị công việc ADV_TDS.1-5

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng sự tương tác giữa các hệ thống con của TSF đã được mô tả.

Mục tiêu của mô tả sự tương tác giữa các hệ thống con thực thi SFR và các hệ thống con khác là giúp cung cấp cho người đọc hiểu biết rõ hơn về cách TSF thực hiện các chức năng của nó. Những tương tác này không cần phải được mô tả ở mức triển khai (ví dụ, thông số được truyền từ một đoạn chương trình trong một hệ thống con đến một đoạn chương trình trong một hệ thống con khác, biến số toàn cục, tín hiệu phần cứng (ví dụ, ngắt) từ một hệ thống con phần cứng tới một hệ thống con điều khiển ngắt), nhưng các yếu tố dữ liệu xác định cho một hệ thống con đặc biệt được sử dụng bởi một hệ thống con khác cần được đề cập trong thảo luận này. Bất kỳ mối quan hệ điều khiển nào giữa hệ thống con (ví dụ, một hệ thống con chịu trách nhiệm cấu hình một nguyên tắc cơ bản cho một hệ thống tường lửa và một hệ thống con thực sự thực hiện các quy tắc này) cũng nên được mô tả.

Người đánh giá cần phải sử dụng nhận định của riêng họ trong việc đánh giá tính trọn vẹn của sự mô tả. Nếu lý do cho một tương tác là không rõ ràng hoặc nếu có những tương tác liên quan SFR (ví dụ: phát hiện trong kiểm tra các mô tả đáp ứng của hệ thống con) không được mô tả, người đánh giá đảm bảo rằng thông tin này được cung cấp bởi nhà phát triển. Tuy nhiên, nếu người đánh giá có thể xác định rằng sự tương tác trong một tập hợp riêng của các hệ thống con, trong khi nhà phát triển mô tả không đầy đủ, sẽ không hỗ trợ tìm hiểu về chức năng tổng thể cũng như chức năng an toàn được cung cấp bởi TSF, khi đó người đánh giá có thể chọn coi như mô tả đầy đủ và không theo đuổi tính trọn vẹn vì mục đích riêng của mình.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.8.1.2.6  Đơn vị công việc ADV_TDS.1-6

Người đánh giá cần thẩm tra việc thiết kế TOE để xác định rằng nó chứa ánh xạ đầy đủ và chính xác từ TSFI đã mô tả trong đặc tả chức năng đến các hệ thống con của TSF được mô tả trong thiết kế TOE.

Các hệ thống con được mô tả trong thiết kế TOE cung cấp mô tả về cách mà TSF làm việc ở mức độ chi tiết cho các phần thực thi SFR của TSF và ở một mức độ cao hơn cho các phần khác của TSF. TSFI cung cấp một mô tả về cách triển khai được tiến hành. Các bằng chứng từ nhà phát triển xác định hệ thống con phức tạp ban đầu khi một hoạt động được yêu cầu tại TSFI và xác định các hệ thống con khác nhau chịu trách nhiệm chính cho việc triển khai các chức năng. Lưu ý rằng một "cây truy xuất" hoàn thiện đối với mỗi TSFI là không được yêu cầu cho đơn vị công việc này.

Người đánh giá đánh giá tính trọn vẹn của các ánh xạ bằng cách đảm bảo rằng tất cả TSFl ánh xạ đến ít nhất một hệ thống con. Việc xác minh độ chính xác thì phức tạp hơn.

Khía cạnh đầu tiên của độ chính xác là mỗi TSFI được ánh xạ tới một hệ thống con tại ranh giới TSF. Xác định này có thể được thực hiện bằng cách thẩm tra lại các mô tả và tương tác hệ thống con và từ các thông tin này xác định vị trí của nó trong kiến trúc. Khía cạnh tiếp theo của độ chính xác là ý nghĩa của ánh xạ. Ví dụ, ánh xạ một TSFI đối phó với kiểm soát quyền truy nhập vào một hệ thống con để kiểm tra mật khẩu không chính xác. Người đánh giá nên một lần nữa sử dụng nhận định trong việc tạo ra quyết định này. Mục tiêu là thông tin này là hỗ trợ người đánh giá hiểu biết về hệ thống và triển khai các SFR và cách thức mà các tổ chức tại ranh giới TSF có thể tương tác với các TSF. Phần lớn đánh giá liệu các SFR có được mô tả chính xác bởi các hệ thống con được thực hiện trong các đơn vị công việc khác không.

10.8.1.3  Hành động ADV_TDS.1.2E

10.8.1.3.1  Đơn vị công việc ADV_TDS.1-7

Người đánh giá cần thẩm tra các yêu cầu chức năng an toàn TOE và thiết kế TOE, để xác định rằng tất cả các yêu cầu chức năng an toàn của ST được bao phủ bởi thiết kế TOE.

Người đánh giá có thể xây dựng một ánh xạ giữa các yêu cầu chức năng an toàn của TOE và thiết kế TOE. Ánh xạ này có thể từ một yêu cầu chức năng đến một tập hợp các hệ thống con. Lưu ý rằng ánh xạ này có thể có được ở một mức độ chi tiết dưới mức thành phần hoặc thậm chí mức phần tử của các yêu cầu, bởi vì các hoạt động (chỉ định, bổ sung chi tiết, lựa chọn) thực hiện trên các yêu cầu chức năng của tác giả ST.

Ví dụ, thành phần kiểm soát truy nhập tập con FDP_ACC.1 chứa một phần tử với các chỉ định. Ví dụ, nếu ST chứa mười quy tắc trong chỉ định kiểm soát truy nhập tập hợp con FDP_ACC.1 và mười quy tắc này được triển khai ở những vị trí xác định trong mười lăm mô đun, nó sẽ không thích hợp cho người đánh giá ánh xạ điều khiển truy nhập tập con FDP_ACC.1 tới một hệ thống con và yêu cầu các đơn vị công việc được hoàn thành. Thay vào đó, người đánh giá sẽ ánh xạ điều khiển truy nhập tập con FDP_ACC.1 (quy tắc 1) đến hệ thống con A, đáp ứng x, y và z; điều khiển truy nhập tập con FDP_ACC.1 (quy tắc 2) đến hệ thống con A, đáp ứng x, p và q; v.v...

10.8.1.3.2  Đơn vị công việc ADV_TDS.1-8

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng nó là một cài đặt chính xác của tất cả các yêu cầu chức năng an toàn.

Người đánh giá đảm bảo rằng mỗi yêu cầu an toàn được liệt kê trong Điều các yêu cầu chức năng an toàn TOE của ST có một mô tả thiết kế tương ứng trong thiết kế TOE mà các chi tiết chính xác như thế nào để TSF đáp ứng yêu cầu đó. Điều này đòi hỏi người đánh giá xác định rằng một tập hợp các hệ thống con chịu trách nhiệm triển khai thực hiện yêu cầu chức năng nhất định và sau đó thẩm tra các hệ thống con này để hiểu làm thế nào các yêu cầu được thực hiện. Cuối cùng, người đánh giá cần đánh giá liệu yêu cầu có được thực hiện một cách chính xác không.

Ví dụ, nếu các yêu cầu ST quy định một cơ chế kiểm soát truy nhập dựa trên vai trò, người đánh giá cần đầu tiên xác định rằng các hệ thống con đó góp phần triển khai cơ chế này. Điều này có thể được thực hiện nhờ kiến thức và sự hiểu biết chuyên sâu về thiết kế TOE hoặc bằng việc thực hiện trong đơn vị công việc trước đó. Lưu ý rằng theo dấu này chỉ để xác định các hệ thống con và không phải là phân tích đầy đủ.

Bước tiếp theo là tìm hiểu cơ chế thực hiện các hệ thống con. Ví dụ, nếu thiết kế mô tả một việc triển khai kiểm soát truy nhập dựa trên các bit bảo vệ kiểu-UNIX, thiết kế sẽ không phải là một cài đặt chính xác các yêu cầu kiểm soát truy nhập này tạo ra trong ví dụ ST sử dụng ở trên. Nếu người đánh giá không thể xác định các cơ chế đã được thực hiện chính xác vì thiếu chi tiết, người đánh giá cần phải đánh giá xem liệu tất cả các hệ thống con thực thi SFR có được xác định hoặc nếu chi tiết đầy đủ có được cung cấp cho các hệ thống con này không.

10.8.2  Đánh giá hoạt động con (ADV_TDS.2)

10.8.2.1  Đầu vào

Các bằng chứng đánh giá cho này hoạt động con là:

a) ST;

b) đặc tính chức năng;

c) đặc tả kiến trúc an toàn;

d) thiết kế TOE.

10.8.2.2  Hành động ADV_TDS.2.1E

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.2.1C: Bn thiết kế cần mô tả cấu trúc TOE với các hệ thống con.

10.8.2.2.1  Đơn vị công việc ADV_TDS.2-1

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng cấu trúc của toàn bộ TOE được mô tả trong thuật ngữ các hệ thống con.

Người đánh giá đảm bảo rằng tất cả các hệ thống con của TOE được xác định. Đặc tả này của TOE sẽ được sử dụng như đầu vào cho đơn vị công việc ADV_TDS.2-2, nơi các thành phần của TOE tạo nên TSF được xác định. Do đó, yêu cầu này là trên toàn bộ TOE ch không phải ch cho TSF.

TOE (và TSF) có thể được mô tả trong nhiều lớp trừu tượng (ví dụ: các hệ thống con và các mô đun). Tùy thuộc vào sự phức tạp của TOE, thiết kế của nó có thể được mô tả trong các thuật ngữ của các hệ thống con và mô đun, như đã mô tả trong TCVN 8709-3 (ISO/IEC 15408-3) Phụ lục A.4, ADV_TDS: Các hệ thống con và các mô đun. Ở cấp độ đảm bảo này, sự chia tách ch cần ở mức "hệ thống con".

Khi thực hiện hoạt động này, người đánh giá thẩm tra bằng chứng khác đối với TOE (ví dụ: ST, hướng dẫn người sử dụng của nhà khai thác) để xác định rằng mô tả TOE trong bằng chứng như vậy nhất quán với mô tả có trong thiết kế TOE.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.2.2C: Bn thiết kế cần chỉ ra tất cả các hệ thống con của TSF.

10.8.2.2.2  Đơn v công việc ADV_TDS.2-2

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng tất cả các hệ thống con của TSF được xác định.

Trong đơn vị công việc ADV_TDS.2-1, tất c các hệ thống con của TOE đã được xác định và quyết định chỉ ra rằng các hệ thống con không TSF được đặc tả một cách chính xác. Dựa trên công việc đó, các hệ thống con không được đặc tả như là hệ thống con không TSF nên xác định một cách chính xác. Người đánh giá xác định rằng, trong những phần cứng và phần mềm được cài đặt và cấu hình theo hướng dẫn cho các thủ tục chuẩn bị (AGD_PRE), mỗi hệ thống con đã được xác định như là hoặc một phần của TSF hoặc không.

TCVN 8709-3 (ISO/IEC 15408-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 kiu không can thiệp SFR ở mức độ chi tiết đủ đ khẳng định nó là không can thiệp SFR.

10.8.2.2.3  Đơn vị công việc ADV_TDS.2-3

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng mỗi hệ thống con không can thiệp SFR của TSF được mô tả theo cách mà người đánh giá có thể xác định rằng hệ thống con là không can thiệp SFR.

Các hệ thống con không can thiệp SFR không cần được mô tả chi tiết chức năng của chúng trong hệ thống như thế nào. Tuy nhiên, người đánh giá tạo ra quyết định dựa trên các bằng chứng được cung cấp bởi nhà phát triển, rằng các hệ thống con không được mô tả chi tiết là không can thiệp SFR. Lưu ý rằng nếu nhà phát triển cung cấp một mức thống nhất tài liệu chi tiết thì đơn vị công việc này sẽ là thỏa mãn đầy đủ, kể từ thời điểm phân loại các hệ thống con cho phép nhà phát triển cung cấp ít thông tin hơn cho các hệ thống con không can thiệp SFR so với các hệ thống con thực thi SFR và hỗ trợ SFR.

Một hệ thống con không can thiệp SFR là một trong những hệ thống con thực thi SFR và hỗ trợ SFR không phụ thuộc, đó là, chúng không đóng vai trò trong việc thực hiện chức năng SFR.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.2.4C: Bản thiết kế cần tóm lược hoạt động thực thi SFR cho các hệ thống con kiểu thực thi SFR.

10.8.2.2.4  Đơn vị công việc ADV_TDS.2-4

Người đánh giá cần thẩm tra việc thiết kế TOE để xác định rằng nó cung cấp một sự đặc tả đầy đủ, chính xác và chi tiết hoạt động thực thi SFR cho các hệ thống con kiu thực thi SFR.

Nhà phát triển có thể chỉ định các hệ thống con như là thực thi SFR, hỗ trợ SFR và không can thiệp SFR, nhưng các "thẻ" này chỉ được sử dụng để mô tả số lượng và loại thông tin mà nhà phát triển phải cung cấp và có thể được sử dụng đ hạn chế số lượng thông tin nhà phát triển phải phát triển nếu quy trình kỹ thuật của họ không tạo ra các tài liệu được yêu cầu. Liệu các hệ thống con có được phân loại bởi nhà phát triển hay không, người đánh giá có trách nhiệm xác định các hệ thống con có các thông tin thích hợp cho vai trò của chúng (thực thi SFR, v.v...) trong TOE và để có được những thông tin thích hợp từ nhà phát triển nên lỗi của nhà phát triển cung cấp là thông tin được yêu cầu cho một hệ thống con cụ thể.

Hoạt động thực thi SFR liên quan đến cách thức một hệ thống con cung cấp các chức năng triển khai một SFR. Trong khi không phải ở một cấp độ của đặc tả liên quan, một mô tả hoạt động chi tiết thường thảo luận cách thức chức năng được cung cấp theo những dữ liệu và cấu trúc dữ liệu quan trọng, các mối quan hệ kiểm soát những gì tồn tại trong một hệ thống con và làm thế nào những yếu tố này làm việc cùng nhau để cung cấp các hoạt động thực thi SFR. Một mô tả như vậy cũng tham khảo hoạt động hỗ trợ SFR, mà người đánh giá cần xem xét đ thực hiện đơn vị công việc tiếp theo.

Để xác định tính hoàn thiện và chính xác, người đánh giá thẩm tra các thông tin có sn khác (ví dụ, đặc tính kỹ thuật, mô tả kiến trúc an toàn, biểu diễn triển khai). Mô tả các chức năng trong các tài liệu này nên nhất quán với những gì đã cung cấp cho bằng chứng đối với đơn vị công việc này.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.2.5C; Bn thiết kế cần tóm tắt hoạt động hỗ trợ SFR và không can thiệp SFR của các hệ thống con kiu thực thi SFR.

10.8.2.2.5  Đơn vị công việc ADV_TDS.2-5

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng nó cung cấp mô tả đầy đủ và cấp chính xác mức độ cao của hoạt động hỗ trợ SFR và không can thiệp SFR của các hệ thống con kiu thực thi SFR.

Nhà phát triển có thể chỉ định các hệ thống con như là thực thi SFR, hỗ trợ SFR và không can thiệp SFR, nhưng các "thẻ" này chỉ được sử dụng để mô tả s lượng và loại thông tin mà nhà phát triển phải cung cấp và có thể được sử dụng đ hạn chế số lượng thông tin nhà phát triển phải phát triển nếu quy trình kỹ thuật của họ không tạo ra các tài liệu được yêu cầu. Liệu các hệ thống con có được phân loại bởi nhà phát triển hay không, người đánh giá có trách nhiệm xác định rằng các hệ thống con có các thông tin thích hợp cho vai trò của chúng (thực thi SFR, v.v..) trong TOE và để có được những thông tin thích hợp từ nhà phát triển nên lỗi của nhà phát triển cung cấp các thông tin được yêu cầu cho một hệ thống con cụ thể.

Ngược lại với các đơn vị công việc trước đó, đơn vị công việc này yêu cầu người đánh giá đánh giá các thông tin cung cấp cho hệ thống con thực thi SFR đó là hỗ trợ SFR hoặc không can thiệp SFR. Mục tiêu của đánh giá này là thực hiện hai việc. Đầu tiên, nó sẽ cung cấp những hiểu biết sâu hơn cho người đánh giá về cách mỗi hệ thống hoạt động. Thứ hai, người đánh giá xác định rằng tất cả các hoạt động thực thi SFR trình bày bởi một hệ thống con đã được mô tả. Không giống như các đơn vị công việc trước đó, thông tin được cung cấp cho các hoạt động hỗ trợ SFR hoặc không can thiệp SFR không cần phải chi tiết như đã cung cấp bởi hoạt động thực thi SFR. Ví dụ, cấu trúc dữ liệu hoặc khoản mục dữ liệu không liên quan đến chức năng thực thi SFR có thể không cần phải mô tả chi tiết. Quyết định tùy thuộc vào người đánh giá, tuy nhiên, đối với những gì ở "mức cao" cho một TOE cụ thể và người đánh giá có được đầy đủ thông tin từ nhà phát triển (thậm chí nếu nó là tương đương với thông tin cung cấp cho các bộ phận của hệ thống con là thực thi SFR) đ thực hiện một nhận định hợp lý cho đơn vị công việc này.

Người đánh giá được cảnh báo, tuy nhiên, mức độ đảm bảo "hoàn hảo" không phải là mục tiêu không yêu cầu của đơn vị công việc này, do đó nhận định sẽ được thực hiện bằng xác định các số lượng và thành phần của các bằng chứng được yêu cầu để tạo ra một nhận định về đơn vị công việc này.

Để xác định tính hoàn thiện và chính xác, người đánh giá thẩm tra các thông tin có sẵn khác (ví dụ, đặc điểm chức năng, mô tả kiến trúc an toàn, biểu diễn triển khai). Mô tả các chức năng trong các tài liệu cần phù hợp với những bằng chứng cho đơn vị công việc này. Đặc biệt, các đặc điểm chức năng nên được sử dụng để xác định rằng hoạt động được yêu cầu để thực hiện các giao diện TSF đã mô tả bởi các đặc tả chức năng là được mô tả đầy đủ bởi các hệ thống con khi mà hoạt động hoặc sẽ là thực thi SFR, hỗ trợ SFR hoặc là không can thiệp SFR.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.8.2.2.6  Đơn vị công việc ADV_TDS.2-6

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng nó cung cấp mô tả mức độ cao đầy đủ và chính xác cho hoạt động của các hệ thống con hỗ trợ SFR.

Nhà phát triển có thể chỉ định các hệ thống con như là thực thi SFR, hỗ trợ SFR và không can thiệp SFR, nhưng các "thẻ" này chỉ được sử dụng để mô tả số lượng và loại thông tin mà nhà phát triển phải cung cấp và có thể được sử dụng đ hạn chế số lượng thông tin nhà phát triển phải phát triển nếu quy trình kỹ thuật của họ không tạo ra các tài liệu được yêu cầu. Liệu các hệ thống con có được phân loại bởi nhà phát triển hay không, người đánh giá có trách nhiệm xác định rằng các hệ thống con có các thông tin thích hợp cho vai trò của chúng (thực thi SFR, v.v..) trong TOE và để có được những thông tin thích hợp từ nhà phát triển nên lỗi của nhà phát triển cung cấp các thông tin được yêu cầu cho một hệ thống con cụ thể.

Ngược với hai đơn vị công việc trước, đơn vị công việc này yêu cầu nhà phát triển cung cấp (và người đánh giá đánh giá) thông tin về các hệ thống con hỗ trợ SFR Cũng như các hệ thống con cần được tham chiếu bởi các mô tả của các hệ thống con thực thi SFR, cũng như các mô tả tương tác trong đơn vị công việc ADV_TDS.2-7. Mục tiêu đánh giá của người đánh giá, giống như cho các đơn vị công việc trước đó, là thực hiện hai việc. Đầu tiên, nó sẽ cung cấp những hiểu biết sâu hơn cho người đánh giá về cách mỗi hệ thống hoạt động. Thứ hai, người đánh giá xác định rằng tất cả các hoạt động thực thi SFR trình bày bởi một hệ thống con đã được mô tả. Không giống như các đơn vị công việc trước đó, thông tin được cung cấp cho các hoạt động hỗ trợ SFR hoặc không can thiệp SFR không cần phải chi tiết như đã cung cấp bởi hoạt động thực thi SFR. Ví dụ, cấu trúc dữ liệu hoặc khoản mục dữ liệu không liên quan đến chức năng thực thi SFR có thể không cn phải mô tả chi tiết. Quyết định tùy thuộc vào người đánh giá, tuy nhiên, đối với những gì ở "mức cao" cho một TOE cụ thể và người đánh giá có được đầy đủ thông tin từ nhà phát triển (thậm chí nếu nó là tương đương với thông tin cung cấp cho các bộ phận của hệ thống con là thực thi SFR) để thực hiện một nhận định hợp lý cho đơn vị công việc này.

Người đánh giá được cảnh báo, tuy nhiên, mức độ đảm bảo "hoàn ho" không phải là mục tiêu không yêu cầu của đơn vị công việc này, do đó nhận định sẽ được thực hiện bằng xác định các số lượng và thành phần của các bằng chứng được yêu cầu để to ra một nhận định về đơn v công việc này.

Để xác định tính hoàn thiện và chính xác, người đánh giá thẩm tra các thông tin có sẵn khác (ví dụ, đặc điểm chức năng, mô tả kiến trúc an toàn, biểu diễn triển khai). Mô tả các chức năng trong các tài liệu cần nhất quán với những gì được cung cấp cho bằng chứng cho đơn vị công việc này. Đặc biệt, các đặc điểm chức năng nên được sử dụng đ xác định rằng hoạt động được yêu cầu đ thực hiện các giao diện TSF đã mô tả bởi các đặc tả chức năng là được mô tả đầy đủ bởi các hệ thống con khi mà hoạt động hoặc sẽ là thực thi SFR, hỗ trợ SFR hoặc là không can thiệp SFR.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.2.7C: Bản thiết kế cần tạo ra mô tả về tương tác của tất cả các hệ thống con của TSF.

10.8.2.2.7  Đơn vị công việc ADV_TDS.2-7

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng sự tương tác giữa các hệ thống con của TSF được mô tả.

Mục tiêu của mô tả tương tác giữa các hệ thống con là giúp cho người đọc hiểu biết hơn cách thức TSF thực hiện chức năng của nó. Những tương tác này không cần được mô tả ở mức triển khai (ví dụ, thông số được truyền từ một đoạn chương trình trong một hệ thống con đến một đoạn chương trình trong một hệ thống con khác, biến s toàn cục, tín hiệu phần cứng (ví dụ, ngắt) từ một hệ thống con phần cứng tới một hệ thống con điều khiển ngắt), nhưng các yếu tố dữ liệu xác định cho một hệ thống con đặc biệt được sử dụng bởi một hệ thống con khác cần được đề cập trong thảo luận này. Bất kỳ mối quan hệ điều khiển nào giữa hệ thống con (ví dụ, một hệ thống con chịu trách nhiệm cấu hình một nguyên tắc cơ bản cho một hệ thống tường lửa và một hệ thống con thực sự thực hiện các quy tắc này) cũng nên được mô tả.

Người đánh giá cần phải sử dụng nhận định của riêng họ trong việc đánh giá tính trọn vẹn của sự mô tả. Nếu lý do cho một tương tác là không rõ ràng hoặc nếu có những tương tác liên quan SFR (ví dụ: phát hiện trong kiểm tra các mô tả đáp ứng của hệ thống con) không được mô tả, người đánh giá đảm bảo rằng thông tin này được cung cấp bởi nhà phát triển. Tuy nhiên, nếu người đánh giá có thể xác định rằng sự tương tác trong một tập hợp riêng của các hệ thống con, trong khi nhà phát triển mô tả không đầy đủ, sẽ không hỗ trợ tìm hiểu về chức năng tổng thể cũng như chức năng an toàn được cung cấp bởi TSF, khi đó người đánh giá có thể chọn coi như mô tả đầy đủ và không theo đui tính trọn vẹn vì mục đích riêng của mình.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.8.2.2.8  Đơn vị công việc ADV_TDS.2-8

Người đánh giá cần thẩm tra việc thiết kế TOE để xác định rằng nó chứa ánh xạ đầy đủ và chính xác từ TSFI đã mô tả trong đặc tả chức năng đến các hệ thống con của TSF được mô tả trong thiết kế TOE.

Các hệ thống con được mô tả trong thiết kế TOE cung cấp mô tả về cách mà TSF làm việc ở mức độ chi tiết cho các phần thực thi SFR của TSF và ở một mức độ cao hơn cho các phần khác của TSF. TSFI cung cấp một mô tả về cách triển khai được tiến hành. Các bằng chứng từ nhà phát triển xác định hệ thống con phức tạp ban đầu khi một hoạt động được yêu cầu tại TSFl và xác định các hệ thống con khác nhau chịu trách nhiệm chính cho việc triển khai các chức năng. Lưu ý rằng một "cây truy xuất" hoàn thiện đối với mỗi TSFI là không được yêu cầu cho đơn vị công việc này.

Người đánh giá đánh giá tính trọn vẹn của các ánh xạ bằng cách đảm bảo rằng tất cả TSFI ánh xạ đến ít nhất một hệ thống con. Việc xác minh độ chính xác thì phức tạp hơn.

Khía cạnh đầu tiên của độ chính xác là mỗi TSFI được ánh xạ tới một hệ thống con tại ranh giới TSF. Xác định này có thể được thực hiện bằng cách thẩm tra lại các mô t và tương tác hệ thống con và từ các thông tin này xác định vị trí của nó trong kiến trúc. Khía cạnh tiếp theo của độ chính xác là ý nghĩa của cách thức ánh xạ. Ví dụ, ánh xạ một TSFI đối phó với kiểm soát quyền truy nhập vào một hệ thống con để kiểm tra mật khẩu không chính xác. Người đánh giá nên lại sử dụng nhận định trong việc tạo ra quyết định này. Mục tiêu là thông tin này là hỗ trợ người đánh giá hiểu biết về hệ thống và triển khai các SFR và cách thức mà các tổ chức tại ranh giới TSF có thể tương tác với các TSF. Phần lớn đánh giá liệu các SFR có được mô tả chính xác bởi các hệ thống con được thực hiện trong các đơn vị công việc khác không.

10.8.2.3  Hành động ADV_TDS.2.2E

10.8.2.3.1  Đơn vị công việc ADV_TDS.2-9

Người đánh giá cần thẩm tra các yêu cầu chức năng an toàn TOE và thiết kế TOE, để xác định rằng tất cả các yêu cầu chức năng an toàn của ST được bao phủ bởi thiết kế TOE.

Người đánh giá có thể xây dựng một ánh xạ giữa các yêu cầu chức năng an toàn của TOE và thiết kế TOE. Ánh xạ này có thể từ một yêu cầu chức năng đến một tập hợp các hệ thống con. Lưu ý rằng ánh xạ này có thể có được ở một mức độ chi tiết dưới mức thành phần hoặc thậm chí mức phần tử của các yêu cầu, bởi vì các hoạt động (chỉ định, bổ sung chi tiết, lựa chọn) thực hiện trên các yêu cầu chức năng của tác giả ST.

Ví dụ, thành phần kiểm soát truy nhập tập con FDP_ACC.1 chứa một phần tử với các chỉ định. Ví dụ, nếu ST chứa mười quy tắc trong chỉ định kiểm soát truy nhập tập hợp con FDP_ACC.1 và mười quy tắc này được triển khai ở những v trí xác định trong mười lăm mô đun, nó sẽ không thích hợp cho người đánh giá ánh xạ điu khiển truy nhập tập con FDP_ACC.1 tới một hệ thống con và yêu cầu các đơn vị công việc được hoàn thành. Thay vào đó, người đánh giá sẽ ánh xạ điều khiển truy nhập tập con FDP_ACC.1 (quy tắc 1) đến hệ thống con A, đáp ứng x, y và z; điều khiển truy nhập tập con FDP_ACC.1 (quy tắc 2) đến hệ thống con A, đáp ứng x, p và q; v.v...

10.8.2.3.2  Đơn vị công việc ADV_TDS.2-10

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng nó là một cài đặt chính xác của tất cả các yêu cầu chức năng an toàn.

Người đánh giá đảm bảo rằng mỗi yêu cầu an toàn được liệt kê trong Điều các yêu cầu chức năng an toàn TOE của ST có một mô tả thiết kế tương ứng trong thiết kế TOE mà các chi tiết chính xác như thế nào để TSF đáp ứng yêu cầu đó. Điều này đòi hỏi người đánh giá xác định rằng một tập hợp các hệ thống con chịu trách nhiệm triển khai thực hiện yêu cầu chức năng nhất định và sau đó thẩm tra các hệ thống con này đ hiểu làm thế nào các yêu cầu được thực hiện. Cuối cùng, người đánh giá cần đánh giá liệu yêu cầu có được thực hiện một cách chính xác không.

Ví dụ, nếu các yêu cầu ST quy định một cơ chế kiểm soát truy nhập dựa trên vai trò, người đánh giá cần đầu tiên xác định rằng các hệ thống con đó góp phần triển khai cơ chế này. Điều này có thể được thực hiện nhờ kiến thức và sự hiểu biết chuyên sâu về thiết kế TOE hoặc bằng việc thực hiện trong đơn vị công việc trước đó. Lưu ý rằng theo dấu này chỉ để xác định các hệ thống con và không phải là phân tích đầy đủ.

Bước tiếp theo là hiểu xem cơ chế nào thực hiện các hệ thống con. Ví dụ, nếu thiết kế mô tả một việc triển khai kiểm soát truy nhập dựa trên các bit bảo vệ kiểu-UNIX, thiết kế sẽ không phải là một cài đặt chính xác các yêu cầu kiểm soát truy nhập này tạo ra trong ví dụ ST sử dụng ở trên. Nếu người đánh giá không thể xác định các cơ chế đã được thực hiện chính xác vì thiếu chi tiết, người đánh giá cần phải đánh giá xem liệu tất cả các hệ thống con thực thi SFR có được xác định hoặc nếu đủ chi tiết có được cung cấp cho các hệ thống con này không.

10.8.3  Đánh giá hoạt động con (ADV_TDS.3)

10.8.3.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu thiết kế TOE có cung cấp một mô tả của TOE trong thuật ngữ của hệ thống con đ để xác định ranh giới TSF và cung cấp một mô tả nội bộ TSF trong thuật ngữ của mô đun không (và tùy chọn sự trừu tượng mức cao hơn). Nó cung cấp một mô tả chi tiết các mô đun thực thi SFR và đầy đủ thông tin về các mô đun hỗ trợ SFR và không can thiệp SFR cho người đánh giá để xác định rằng các SFR được triển khai đầy đủ và chính xác, như vậy, thiết kế TOE cung cấp giải thích của biểu diễn triển khai.

10.8.3.2  Đầu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) đặc điểm kỹ thuật chức năng;

c) mô tả kiến trúc an toàn;

d) thiết kế TOE.

10.8.3.3  Lưu ý áp dụng

Có ba loại hoạt động mà người đánh giá cần thực hiện đối với thiết kế TOE. Đầu tiên, người đánh giá xác định rằng ranh giới TSF đã được mô tả đầy đủ. Thứ hai, người đánh giá xác định rằng nhà phát triển đã cung cấp tài liệu phù hợp với các yêu cầu nội dung và trình bày đối với các hệ thống con này và nó nhất quán với các tài liệu khác được cung cấp cho TOE. Cuối cùng, người đánh giá phải phân tích thông tin thiết kế đã cung cấp cho các mô đun thực thi SFR ( mức chi tiết) và các mô đun hỗ trợ SFR và không can thiệp SFR ( một mức độ ít chi tiết) để hiu cách thức hệ thống được triển khai và với kiến thức đảm bảo rằng các TSFI trong đặc tả chức năng được mô tả đầy đủ và các thông tin kiểm thử đầy đủ các kiểm thử TSF (thực hiện trong Lớp ATE: Các đơn vị công việc kiểm thử).

Điều quan trọng cần lưu ý rằng trong khi nhà phát triển có nghĩa vụ phải cung cấp một mô tả đầy đủ của TSF (mặc dù các mô đun thực thi SFR sẽ có nhiều chi tiết hơn so với mô đun hỗ trợ SFR hoặc không can thiệp SFR), người đánh giá dự kiến sẽ sử dụng nhận định trong việc thực hiện phân tích của họ. Trong khi người đánh giá dự kiến sẽ thẩm tra tất cả các mô đun, các chi tiết mà họ thẩm tra từng mô đun có thể thay đổi. Người đánh giá phân tích từng mô đun để đạt tới sự hiểu biết đầy đủ để xác định các tác động của các chức năng của mô đun dựa trên sự an toàn của hệ thống và các độ sâu mà họ cần phải phân tích các mô đun có thể thay đổi tùy thuộc vào vai trò của mô đun trong hệ thống. Một khía cạnh quan trọng của phân tích này là người đánh giá nên sử dụng các tài liệu được cung cấp khác (TSS, đặc tả chức năng, mô tả kiến trúc an toàn và tài liệu nội bộ TSF) để xác định rằng chức năng được mô tả là chính xác và rằng các quy định tiềm ẩn của các mô đun hỗ trợ SFR hoặc không can thiệp SFR (xem bên dưới) được hỗ trợ bởi vai trò của chúng trong kiến trúc hệ thống.

Nhà phát triển có thể chỉ định các mô đun là thực thi SFR, hỗ trợ SFR và không can thiệp SFR, nhưng các "thẻ" này ch được sử dụng để mô tả số lượng và loại thông tin mà nhà phát triển phải cung cấp và có thể được sử dụng để hạn chế số lượng thông tin nhà phát triển phải phát triển nếu quy trình kỹ thuật của họ không tạo ra các tài liệu được yêu cầu. Cho dù các mô đun có được phân loại bởi nhà phát triển hay không, người đánh giá có trách nhiệm xác định các mô đun có các thông tin thích hợp cho vai trò của chúng (thực thi SFR, v.v...) trong TOE và để có được những thông tin thích hợp từ nhà phát triển nên lỗi của nhà phát triển cung cấp các thông tin được yêu cầu cho một mô đun cụ thể.

10.8.3.4  Hành động ADV_TDS.3.1E

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.3.1C: Bản thiết kế cần mô tả cấu trúc của TOE với các hệ thống con.

10.8.3.4.1  Đơn vị công việc ADV_TDS.3-1

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng cấu trúc của toàn bộ TOE được mô tả trong thuật ngữ các hệ thống con.

Người đánh giá đảm bảo rằng tất cả các hệ thống con của TOE được xác định. Đặc tả này của TOE sẽ được sử dụng như đầu vào cho đơn vị công việc ADV_TDS.3-2, nơi các thành phần của TOE tạo nên TSF được xác định. Do đó, yêu cầu này là trên toàn bộ TOE chứ không phải chỉ cho TSF.

TOE (và TSF) có thể được mô tả trong nhiều lớp trừu tượng (ví dụ: các hệ thống con và các mô đun). Tùy thuộc vào sự phức tạp của TOE, thiết kế của nó có thể được mô tả trong các thuật ngữ của các hệ thống con và mô đun, như đã mô tả trong Phụ lục A.4 TCVN 8709-3 (ISO/IEC 15408-3), ADV_TDS: Các hệ thống con và các mô đun. Đối với một TOE đơn giản có thể được mô tả chỉ tại cấp độ "mô đun" (xem ADV_TDS.3-2), đơn vị công việc này không phải áp dụng và do đó được xem là thỏa mãn.

Khi thực hiện hoạt động này, người đánh giá thẩm tra bằng chứng khác đối với TOE (ví dụ: ST, hướng dẫn người sử dụng của nhà khai thác) để xác định rằng mô tả TOE trong bằng chứng như vậy là nhất quán với mô tả có trong thiết kế TOE.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.3.2C: Bn thiết kế cần mô tả TSF trong thuật ngữ của các mô đun.

10.8.3.4.2  Đơn vị công việc ADV_TDS.3-2

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng toàn bộ TSF được mô tả trong thuật ngữ các mô đun.

Người đánh giá sẽ thẩm tra các mô đun đối với các thuộc tính cụ thể trong các đơn vị công việc khác nhau; trong đơn vị công việc này người đánh giá xác định rằng mô tả mô đun bao gồm toàn bộ các TSF, không chỉ là một phần của TSF. Người đánh giá sử dụng các bằng chứng khác nhau đã cung cấp cho việc đánh giá (ví dụ, đặc tả chức năng, mô tả kiến trúc an toàn) trong việc tạo ra quyết định này. Ví dụ, nếu các đặc tả chức năng chứa giao diện chức năng mà không xut hiện đã được mô tả trong mô tả thiết kế TOE, nó có thể là trường hợp một phần của TSF đã không được đưa vào một cách thích hợp. Việc thực hiện quyết định này có thể là một quá trình lặp đi lặp lại, trong khi đó nhiều phân tích được thực hiện trên các bằng chứng khác, có thể đạt được độ tin cậy cao hơn đối với tính hoàn thiện của tài liệu.

Không giống như các hệ thống con, các mô đun mô tả việc triển khai ở một mức độ chi tiết như một hướng dẫn để xem xét các biểu diễn triển khai. Một mô tả của một mô đun nên theo cách sao cho nó có thể triển khai mô đun từ mô tả đó và kết quả việc triển khai sẽ là 1) ging như việc triển khai TSF thực tế theo các giao diện được trình bày và sử dụng bởi các mô đun và 2) thuật toán giống với mô đun TSF. Ví dụ, RFC 793 cung cấp một mô tả cấp độ cao các giao thức TCP. Điều đó nhất thiết phải triển khai độc lập. Trong khi nó cung cấp các chi tiết đầy đủ, nó không phải là một mô tả thiết kế phù hp bởi vì nó không cụ thể trong việc triển khai. Một triển khai thực tế có thể thêm giao thức quy định trong các RFC và sự lựa chọn triển khai (ví dụ, các sử dụng các dữ liệu toàn cục, so với dữ liệu cục bộ trong các phần khác nhau của việc triển khai) có thể có một tác động vào việc phân tích được thực hiện. Mô tả thiết kế của mô đun TCP sẽ liệt kê các giao diện được trình bày bởi việc triển khai (thay vì chỉ những định nghĩa trong RFC 793), cũng như một mô tả thuật toán của việc xử lý kết hợp với các mô đun triển khai TCP (giả sử nó là một phần của TSF).

TCVN 8709-3 (ISO/IEC 15408-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.

10.8.3.4.3  Đơn vị công việc ADV_TDS.3-3

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng tất cả các hệ thống con của TSF được xác định.

Nếu thiết kế được trình bày chỉ trong các thuật ngữ của các mô đun, khi đó các hệ thống con trong những yêu cầu này là tương đương với các mô đun và hoạt động nên được thực hiện ở cấp mô đun. Trong đơn vị công việc ADV_TDS.3-1, tất cả các hệ thống con của TOE đã được xác định và quyết định ch ra rằng các hệ thống con không TSF được đặc tả một cách chính xác. Dựa trên công việc đó, các hệ thống con không được đặc tả như là hệ thống con không TSF nên xác định một cách chính xác. Người đánh giá xác định rằng, trong những phần cứng và phần mềm được cài đặt và cấu hình theo hướng dẫn cho các thủ tục chuẩn bị (AGD_PRE), mỗi hệ thống con đã được xác định như là hoặc một phần của TSF hoặc không.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.3.4C: Bản thiết kế cần tạo ra mô tả cho mỗi hệ thống con của TSF.

10.8.3.4.4  Đơn vị công việc ADV_TDS.3-4

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng mỗi hệ thống con của TSF mô tả vai trò của nó trong việc thực thi các SFR đã mô tả trong ST.

Nếu thiết kế được trình bày chỉ trong các thuật ngữ của các mô đun, khi đó đơn vị công việc này sẽ được xem là thỏa mãn việc đánh giá thực hiện trong đơn vị công việc tiếp theo; trong trường hợp này không có hành động của người đánh giá.

Trên các hệ thống đủ phức tạp để đảm bảo một mô tả cấp hệ thống con của TSF ngoài việc mô tả mô đun, mục tiêu của mô tả cp hệ thống con là để cung cấp cho người đánh giá ngữ cảnh của việc mô tả mô đun tiếp theo. Do đó, người đánh giá đảm bảo rằng mô tả cấp hệ thống con chứa một mô tả cách mà các yêu cầu chức an toàn đạt được trong thiết kế, nhưng ở một mức độ trừu tượng ở trên mô tả mô đun. Mô tả này nên thảo luận các cơ chế sử dụng ở một mức độ được liên kết với mô tả mô đun; điều này sẽ cung cấp cho người đánh giá lộ trình ánh xạ được yêu cầu để đánh giá một cách thông minh các thông tin cha trong mô tả mô đun. Một mô tả tập các mô tả hệ thống con bằng văn bản một cách đầy đủ sẽ giúp hướng dẫn người đánh giá trong việc xác định các mô đun quan trọng nhất để thẩm tra, do đó tập trung vào đánh giá hoạt động trên các phần của TSF mà phù hợp nhất với việc thực thi của các SFR.

Người đánh giá đảm bảo rằng tất cả các hệ thống con của TSF có một mô tả. Trong khi mô tả nên tập trung về vai trò mà hệ thống con trong thi hành hoặc hỗ trợ triển khai các SFR, đầy đủ thông tin phải hiện thị sao cho một bối cảnh cho sự hiu biết các chức năng liên quan SFR được tạo ra.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.3.5C: Bản thiết kế cần tạo ra mô tả cho các tương tác của mọi hệ thống con của TSF.

10.8.3.4.5  Đơn vị công việc ADV_TDS.3-5

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng sự tương tác giữa các hệ thống con của TSF được mô tả.

Nếu thiết kế được trình bày chỉ trong các thuật ngữ của các mô đun, khi đó đơn vị công việc này sẽ được xem là thỏa mãn việc đánh giá thực hiện trong đơn vị công việc tiếp theo; trong trường hợp này không có hành động của người đánh giá.

Trên các hệ thống đ phức tạp để đảm bảo một mô tả cấp hệ thống con của TSF ngoài mô tả mô đun, mục tiêu của mô tả sự tương tác giữa các hệ thống con thực thi SFR và các hệ thống con khác là giúp cung cấp cho người đọc hiểu biết hơn về cách TSF thực hiện các chức năng của nó. Những tương tác này không cần phải được mô tả ở mức triển khai (ví dụ, thông số được truyền từ một đoạn chương trình trong một hệ thống con đến một đon chương trình trong một hệ thống con khác, biến số toàn cục, tín hiệu phần cứng (ví dụ, ngắt) từ một hệ thống con phần cứng ti một hệ thống con điều khiển ngắt), nhưng các yếu tố dữ liệu xác định cho một hệ thống con đặc biệt được sử dụng bởi một hệ thống con khác cần được đề cập trong thảo luận này. Bất kỳ mi quan hệ điều khiển nào giữa hệ thống con (ví dụ, một hệ thống con chịu trách nhiệm cấu hình một nguyên tắc cơ bản cho một hệ thống tường lửa và một hệ thống con thực sự thực hiện các quy tắc này) cũng nên được mô tả.

Cần phải lưu ý trong khi nhà phát triển mô tả tất cả tương tác giữa các hệ thống con, người đánh giá cần phải sử dụng nhận định của riêng họ trong việc đánh giá tính trọn vẹn của sự mô tả. Nếu lý do cho một tương tác là không rõ ràng hoặc nếu có những tương tác liên quan SFR (ví dụ: phát hiện trong kiểm tra các mô tả đáp ứng của hệ thống con) không được mô tả, người đánh giá đảm bảo rằng thông tin này được cung cấp bởi nhà phát triển. Tuy nhiên, nếu người đánh giá có thể xác định rằng sự tương tác trong một tập hợp riêng của các hệ thống con, trong khi nhà phát triển mô tả không đầy đủ, sẽ không hỗ trợ tìm hiểu về chức năng tổng thể cũng như chức năng an toàn được cung cấp bởi TSF, khi đó người đánh giá có thể chọn coi như mô tả đầy đủ và không theo đuổi tính trọn vẹn vì mục đích riêng của mình.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.3.6C: Bản thiết kế cần tạo ra ánh xạ từ các hệ thống con của TSF đến các mô đun của TSF.

10.8.3.4.6  Đơn vị công việc ADV_TDS.3-6

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng ánh xạ giữa các hệ thống con của TSF và các mô đun của TSF là đầy đủ.

Nếu thiết kế được trình bày chỉ trong các thuật ngữ của các mô đun, khi đó đơn vị công việc này sẽ được xem là thỏa mãn.

Đối với TOE đ phức tạp đ đảm bảo một mô tả cấp hệ thống con của TSF ngoài mô tả mô đun, nhà phát triển cung cấp một ánh xạ đơn cho thấy làm cách nào các mô đun của TSF phân bổ cho các hệ thống con. Điều này sẽ cung cấp cho người đánh giá một hướng dẫn trong việc thực hiện đánh giá cấp mô đun của nó. Để xác định tính toàn vẹn, người đánh giá thẩm tra từng ánh xạ và xác định rằng tất cả hệ thống con ánh xạ ít nhất đến một mô đun và tất cả các mô đun ánh xạ chính xác đến một hệ thống con.

10.8.3.4.7  Đơn vị công việc ADV_TDS.3-7

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng ánh xạ giữa các hệ thống con của TSF và các mô đun của TSF là chính xác.

Nếu thiết kế được trình bày ch trong các thuật ngữ của các mô đun, khi đó đơn vị công việc này sẽ được xem là thỏa mãn.

Đối với TOE đ phức tạp để đảm bảo một mô tả cấp hệ thống con của TSF ngoài mô tả mô đun, nhà phát triển cung cấp một ánh xạ đơn cho thấy làm cách nào các mô đun của TSF phân bổ cho các hệ thống con. Điều này sẽ cung cấp cho người đánh giá một hướng dẫn trong việc thực hiện đánh giá cấp mô đun của nó. Người đánh giá có thể lựa chọn đ kiểm tra tính chính xác của các ánh xạ kết hợp với thực hiện các đơn vị công việc khác. Một ánh xạ "không chính xác" là ánh xạ mà các mô đun liên quan chỉ định nhầm đến một hệ thống con nơi mà chức năng của nó không được sử dụng trong hệ thống con. Bởi vì ánh xạ được thiết kế để trở thành một hướng dẫn hỗ trợ các phân tích chi tiết hơn, người đánh giá được cảnh báo để cố gắng áp dụng phù hợp với đơn vị công việc này. Mở rộng nguồn tài nguyên sâu rộng của người đánh giá để xác minh tính chính xác của ánh xạ là không được yêu cầu. Tính không chính xác dẫn đến sự hiểu sai liên quan đến việc thiết kế không được đề cập ở đây hay ở các đơn vị công việc khác nên gắn với đơn vị công việc này và được sửa lại cho chính xác.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.3.7C: Bản thiết kế sẽ mô tả các mô đun thực thi SFR theo mục đích và tương tác của chúng với các mô đun khác.

10.8.3.4.8  Đơn vị công việc ADV_TDS.3-8

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng các mô tả theo mục đích của mỗi mô đun thực thi SFR là đầy đủ và chính xác.

Nhà phát triển có thể chỉ định các mô đun là thực thi SFR, hỗ trợ SFR và không can thiệp SFR, nhưng các "thẻ" này chỉ được sử dụng để mô tả số lượng và loại thông tin mà nhà phát triển phải cung cấp và có thể được sử dụng để hạn chế số lượng thông tin nhà phát triển phải phát triển nếu quy trình kỹ thuật của họ không tạo ra các tài liệu được yêu cầu. Cho dù các mô đun có được phân loại bởi nhà phát triển hay không, người đánh giá có trách nhiệm xác định các mô đun có các thông tin thích hợp cho vai trò của chúng (thực thi SFR, v.v...) trong TOE và đ có được những thông tin thích hợp từ nhà phát triển nên lỗi của nhà phát triển cung cấp các thông tin được yêu cầu cho một mô đun cụ thể.

Mục đích của mô đun là cung cấp một mô tả cho thấy chức năng gì mô đun thỏa mãn. Người đánh giá cần chú ý tới các thứ tự. Trọng tâm của đơn vị công việc này nên cung cấp cho người đánh giá các hiểu biết về cách mà các mô đun hoạt động để có thể quyết định về tính đúng đắn của việc triển khai các SFR, cũng như để hỗ trợ phân tích kiến trúc thực hiện cho thành phần ADV_ARC. Miễn là người đánh giá hiểu biết về hoạt động của mô đun và mối quan hệ của nó với các mô đun khác và TOE như một tổng thể, người đánh giá nên xem xét mục tiêu của công việc đạt được và không tham gia vào một tài liệu hướng dẫn thực hiện của nhà phát triển (bằng cách yêu cầu, ví dụ, một thuật toán hoàn chỉnh mô tả cho một biểu diễn triển khai là hiển nhiên).

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.3.8C: Bn thiết kế cần mô tả mỗi mô đun thực thi 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.

10.8.3.4.9  Đơn vị công việc ADV_TDS.3-9

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng các mô tả về giao diện được trình bày bởi mỗi mô đun thực thi SFR chứa mô tả chính xác và đầy đủ các thông số liên quan SFR, các quy ước gọi đến đối với mỗi giao diện và bất kỳ giá trị nào trả về trực tiếp từ các giao diện.

Các giao diện liên quan SFR của một mô đun là những giao diện được sử dụng bởi các mô đun khác như một phương tiện để gọi đến các hoạt động liên quan SFR đã cung cấp và để cung cấp đầu vào hoặc nhận kết quả đầu ra từ các mô đun. Mục đích của các đặc tả của các giao diện này là cho phép việc thực hiện chúng trong quá trình kiểm thử. Các giao diện liên mô đun mà không liên quan SFR không cần được quy định hoặc được mô tả, do chúng không phải là một yếu tố trong kiểm thử. Tương tự như vậy, các giao diện nội bộ khác mà không phải là một yếu tố trong liên quan SFR đến cách thức thực hiện (chẳng hạn như những đường cố định bên trong) không cần phải được quy định hoặc được mô tả, do chúng không phải là một yếu tố trong kiểm thử.

Các giao diện liên quan SFR được mô tả trong thuật ngữ theo cách chúng được gọi đến và bất kỳ các giá trị được trả về. Mô tả này sẽ bao gồm một danh sách các thông số liên quan SFR và các mô tả của các tham số này. Lưu ý rằng dữ liệu toàn cục cũng sẽ được xem là các thông số nếu được sử dụng bởi mô đun (hoặc là các đầu vào hoặc là các đầu ra) khi được gọi đến. Nếu một tham số được dự kiến sẽ đưa vào một tập các giá trị (ví dụ, một tham số "cờ"), thiết lập đầy đủ của giá trị các tham số có thể đưa vào đó sẽ có một tác động vào việc xử lý mô đun sẽ được xác định. Tương tự như vậy, các thông số đại diện cho cấu trúc dữ liệu được mô tả như các trường của cấu trúc dữ liệu được xác định và mô tả. Lưu ý rằng các ngôn ngữ lập trình khác nhau có thể có thêm "các giao diện'' không rõ ràng, ví dụ như nhà điều hành/chức năng quá tải trong C++. "Giao diện không rõ ràng" này trong các lớp mô tả cũng có thể được mô tả như là một phần của thiết kế TOE ở mức độ thấp. Lưu ý rằng mặc dù một mô đun chỉ có thể trình bày một giao diện, thông thường thì một mô đun trình bày một tập con các giao diện liên quan.

Trong thuật ngữ vầ đánh giá các thông số (các đầu vào và các đầu ra) của một mô đun, sử dụng bất kỳ dữ liệu toàn cục nào cũng phải được cân nhắc. Một mô đun "sử dụng" dữ liệu toàn cục nếu nó hoặc là đọc hoặc là ghi dữ liệu. Để đảm bảo sự mô tả các thông số như vậy (nếu sử dụng) là đầy đủ, người đánh giá sử dụng các thông tin khác được cung cấp về mô đun trong thiết kế TOE (các giao diện, thuật toán mô tả, v.v...), cũng như mô tả về tập hợp đặc biệt của dữ liệu toàn cục đã đánh giá trong đơn vị công việc ADV_TDS.3-9. Ví dụ, người đánh giá có thể đầu tiên xác định việc xử lý các mô đun thực hiện bằng cách kiểm tra chức năng và giao diện sẵn có (đặc biệt là các thông số của các giao diện). Sau đó họ có thể kiểm tra để xem xét nếu các quá trình xử lý "chạm" đến bất kỳ khu vực dữ liệu toàn cục được xác định trong thiết kế TOE. Người đánh giá sau đó xác định rằng, đối với mỗi khu vực dữ liệu toàn cục bị "chạm", khu vực dữ liệu toàn cục đó được liệt kê như là đầu vào hay đầu ra của mô đun mà người đánh giá thẩm tra.

Quy ước gọi đến là một đặc tả kiểu tham chiếu lập trình có thể sử dụng để gọi đến chính xác một giao diện của một mô đun nếu một người đang viết một chương trình đ sử dụng các chức năng của mô đun thông qua giao diện đó. Điều này bao gồm các đầu vào và các đầu ra được yêu cầu, bao gồm c các thiết lập mà có thể cn được thực hiện đối với các biến số toàn cục.

Giá trị trả về thông qua giao diện là các giá trị mà hoặc là thông qua các thông số hoặc là các thông báo; giá trị mà các chức năng truy xuất tự nó trả về trong kiểu của một truy xuất chức năng lập trình "C" hoặc giá trị được truyền thông qua phương thức toàn cục (chẳng hạn như các tuyến lỗi cụ thể trong các hệ điều hành kiu *ix).

Đ đảm bảo các mô tả là đầy đủ, người đánh giá sử dụng thông tin khác được cung cấp bởi mô đun trong thiết kế TOE (ví dụ, thuật toán mô tả, dữ liệu toàn cục được sử dụng) để đảm bảo rằng tất cả dữ liệu được yêu cầu để thực hiện các chức năng của mô đun đã sẵn có cho các mô đun và rằng bất kỳ giá trị mà các mô đun khác kỳ vọng việc thm tra mô đun để cung cấp được xác định như được phản hồi bởi các mô đun. Người đánh giá xác định độ chính xác để đảm bảo rằng mô tả của các x lý phù hợp với thông tin được liệt kê như được truyền đến hoặc đi từ một giao diện.

Vì các mô đun ở mức độ thấp như vậy, rất khó có thể xác định tính hoàn thiệt và chính xác tác động từ tài liệu khác, chẳng hạn như hướng dẫn người sử dụng vận hành, đặc tả chức năng, các tính chất TSF hoặc mô tả kiến trúc an toàn. Tuy nhiên, người đánh giá sử dụng các thông tin sẵn có trong các tài liệu này thuộc phạm vi có thể giúp để đảm bảo rằng mục đích được mô tả đầy đủ và chính xác. Các phân tích này có thể được hỗ trợ bởi các phân tích đã thực hiện cho các đơn vị công việc đối với phần tử ADV_TDS.3.10C, mà các ánh xạ TSFI trong đặc tả chức năng đến các mô đun của TSF.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.3.9C: Bản thiết kế cần mô tả mỗi mô đun hỗ trợ SFR hoặc không can thiệp SFR với mục đích và tương tác của chúng với các mô đun khác.

10.8.3.4.10  Đơn vị công việc ADV_TDS.3-10

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng mô đun hỗ trợ SFR và không can thiệp SFR được phân loại chính xác.

Trong trường hợp khi nhà phát triển đã cung cấp một lượng thông tin khác nhau cho các mô đun khác nhau, sự phân loại ngầm định đã được thực hiện. Đó là, các mô đun (ví dụ) với các chi tiết sẵn có trên các giao diện liên quan SFR (xem ADV_TDS.3.10C) là các mô đun thực thi SFR ứng cử, mặc dù việc thẩm tra bởi người đánh giá có thể dẫn đến việc quyết định rằng một số thiết lập của chúng là hỗ trợ SFR hoặc không can thiệp SFR. Phần này ch mô tả về mục đích của chúng và tương tác với các mô đun khác (ví dụ) là "phân loại không ngầm định" như hỗ trợ SFR hoặc không can thiệp SFR.

Trong những trường hợp này, trọng tâm của người đánh giá cho đơn vị công việc này là cố gắng xác định từ những bằng chứng đã cung cấp cho mỗi mô đun phân loại không ngầm định như là hỗ trợ SFR hoặc không can thiệp SFR và thông tin đánh giá về các mô đun khác (trong thiết kế TOE, các đặc tả chức năng, mô tả kiến trúc an toàn và hướng dẫn người sử dụng vận hành), liệu các mô đun có thực sự hỗ trợ SFR hoặc không can thiệp SFR không. Ở cấp độ này một s lỗi đảm bảo có thể được bỏ qua; người đánh giá không hoàn toàn chắc chắn rằng một mô đun là hỗ trợ SFR hoặc không can thiệp SFR, mặc dù nó được dán nhãn như vậy. Tuy nhiên, nếu các bằng chứng được cung cấp chỉ ra rằng một mô đun hỗ trợ SFR hoặc không can thiệp SFR là thực thi SFR, người đánh giá yêu cầu thêm thông tin từ nhà phát triển để giải quyết sự không nhất quán rõ ràng. Ví dụ, giả sử các tài liệu hướng dẫn cho Mô đun A (một mô đun thực thi SFR) chỉ ra rằng nó truy xuất Mô đun B để thực hiện kiểm tra truy nhập trên một loại kết cấu nhất đnh. Khi người đánh giá thẩm tra các thông tin liên quan đến Mô đun B, họ thấy rằng tất cả nhà phát triển đã cung cấp một mục đích và một tập hợp các tương tác (như vậy, Mô đun B phân loại không ngầm định như là hỗ trợ SFR hoặc không can thiệp SFR). Khi kiểm tra mục đích và tương tác của Mô đun A, người đánh giá thấy không đề cập đến Mô đun B thực hiện bất kỳ kiểm tra truy nhập nào và Mô đun A không được liệt kê như là một mô đun mà Mô đun B tương tác. Tại thời điểm này, người đánh giá nên tiếp cận nhà phát triển để giải quyết các khác biệt giữa thông tin đã cung cấp trong Mô đun A và trong Mô đun B.

Một ví dụ khác là nơi mà người đánh giá kiểm tra các ánh xạ của các TSFI đến các mô đun như cung cấp bởi ADV_TDS.3.2D. Việc thẩm tra này cho thấy, Mô đun C được kết hợp với một SFR yêu cầu xác định của người sử dụng. Một lần nữa, khi người đánh giá thẩm tra thông tin liên quan đến Mô đun C, người đánh giá thấy rằng tất cả nhà phát triển đã cung cấp một mục đích và một tập hợp các tương tác (như vậy, Mô đun C phân loại không ngầm đnh như là hỗ trợ SFR hoặc không can thiệp FSR). Kiểm tra mục đích và tương tác được trình bày cho Mô đun C, người đánh giá không thể xác định lý do tại sao Mô đun C, được liệt kê như ánh xạ từ TSFI liên quan đến người sử dụng xác định, sẽ không được phân loại là thực thi SFR. Một lần nữa, người đánh giá cần tiếp cận nhà phát triển để giải quyết sự khác biệt này.

Một ví dụ cuối cùng đi từ quan điểm ngược lại. Như trước đây, nhà phát triển đã cung cấp thông tin kết hợp với Mô đun D bao gồm một mục đích và một tập hợp các tương tác (như vậy, mặc nhiên phân loại Mô đun D phân loại không ngầm định như là hỗ trợ SFR hoặc không can thiệp FSR). Người đánh giá thẩm tra tất cả các bằng chứng đã cung cấp, bao gồm cả mục đích và tương tác với mô đun D. Các mục đích xuất hiện để cung cấp một mô tả ý nghĩa của chức năng Mô đun D trong TOE, sự tương tác nhất quán với mô tả đó và không có gì chỉ ra rằng Mô đun D là thực thi SFR. Trong trường hợp này, người đánh giá không nên đòi hỏi nhiều thông tin về Mô đun D "ch là để đảm bảo" nó được phân loại một cách chính xác. Nhà phát triển đã tha mãn các nghĩa vụ của họ và người đánh giá đảm bảo kết quả có trong phân loại tiềm n của Mô đun D là (theo định nghĩa) thích hợp cho mức độ đảm bảo này.

10.8.3.4.11  Đơn vị công việc ADV_TDS.3-11

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng mô tả về mục đích của mỗi mô đun hỗ trợ SFR hoặc không can thiệp SFR là đầy đủ và chính xác.

Các mô tả về mục đích của một mô đun chỉ ra những mô đun chức năng nào là thỏa mãn. Từ sự mô tả, người đánh giá có thể nên có được một ý tưởng chung về vai trò của mô đun. Để đảm bảo sự mô tả là đầy đủ, người đánh giá sử dụng các thông tin đã cung cấp về các tương tác của mô đun với các mô đun khác đ đánh giá liệu những lý do các mô đun được truy xuất có nhất quán với các mục đích của mô đun không. Nếu mô tả tương tác có chức năng không rõ ràng hoặc mâu thuẫn với, các mục đích của mô đun, người đánh giá cần xác định liệu vấn đề có ở tính chính xác hoặc tính toàn diện không. Người đánh giá nên chú ý với các mục đích quá ngn, do không thể phân tích ý nghĩa dựa trên mục đích chỉ có một câu.

Trong những trường hợp này, trọng tâm của người đánh giá cho đơn vị công việc này là cố gắng xác định từ những bằng chứng đã cung cấp cho mỗi mô đun phân loại không ngầm định như là hỗ trợ SFR hoặc không can thiệp SFR và thông tin đánh giá về các mô đun khác (trong thiết kế TOE, các đặc tả chức năng, mô tả kiến trúc an toàn và hướng dẫn người sử dụng vận hành), liệu các mô đun có thực sự hỗ trợ SFR hoặc không can thiệp SFR không. Ở cấp độ này một số lỗi đảm bảo có thể được bỏ qua; người đánh giá không hoàn toàn chắc chắn rằng một mô đun là hỗ trợ SFR hoặc không can thiệp SFR, mặc dù nó được dán nhãn như vậy. Tuy nhiên, nếu các bằng chứng được cung cấp ch ra rằng một mô đun hỗ trợ SFR hoặc không can thiệp SFR là thực thi SFR, người đánh giá yêu cầu thêm thông tin từ nhà phát triển để giải quyết sự không nhất quán rõ ràng. Ví dụ, giả sử các tài liệu hướng dẫn cho Mô đun A (một mô đun thực thi SFR) chỉ ra rằng nó truy xut Mô đun B đ thực hiện kiểm tra truy nhập trên một loại kết cấu nhất định. Khi người đánh giá thẩm tra các thông tin liên quan đến Mô đun B, họ thấy rằng tất cả nhà phát triển đã cung cấp một mục đích và một tập hợp các tương tác (như vậy, Mô đun B phân loại không ngầm định như là hỗ trợ SFR hoặc không can thiệp SFR). Khi kiểm tra mục đích và tương tác của Mô đun A, người đánh giá thấy không đề cập đến Mô đun B thực hiện bt k kiểm tra truy nhập nào và Mô đun A không được liệt kê như là một mô đun mà Mô đun B tương tác. Tại thời điểm này, người đánh giá nên tiếp cận nhà phát triển để giải quyết các khác biệt giữa thông tin đã cung cấp trong Mô đun A và trong Mô đun B.

10.8.3.4.12  Đơn vị công việc ADV_TDS.3-12

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng mô tả tương tác của mô đun hỗ trợ SFR hoặc không can thiệp SFR với các mô đun khác là đầy đủ và chính xác.

Điều quan trọng cn lưu ý là, trong các thuật ngữ của yêu cầu ở Phần 3 và đơn vị công việc này, thuật ngữ tương tác có mục đích truyền đạt ít nghiêm ngặt hơn so với thuật ng giao diện. Một tương tác không cần phải đặc tả ở cấp triển khai (ví dụ, thông số thông qua từ một tuyến trong một mô đun này tới một tuyến trong một mô đun khác; biến số toàn cục; các tín hiệu phần cứng (ví dụ, các ngắt) từ một phần cứng của hệ thống con tới một hệ thống con xử lý ngắt), nhưng các phần tử dữ liệu xác định cho một mô đun được sử dụng bởi một mô đun đặc biệt nên được đề cập trong thảo luận này. Bất kỳ mối quan hệ kiểm soát giữa các mô đun (ví dụ, một mô đun chịu trách nhiệm cho việc cấu hình một nguyên tắc cơ bản cho một hệ thống tường la và các mô đun thực sự thực hiện các quy tắc) cũng nên được mô tả.

Vì các mô đun ở mức độ thấp như vậy, rất khó có thể xác định tính hoàn thiệt và chính xác tác động từ tài liệu khác, chẳng hạn như tài liệu hướng dẫn người sử dụng vận hành, đặc tả chức năng, mô tả kiến trúc an toàn hoặc tài liệu về tính chất TSF. Tuy nhiên, người đánh giá sử dụng các thông tin sẵn có trong các tài liệu này thuộc phạm vi có thể giúp để đảm bảo rằng chức năng được mô tả đầy đủ và chính xác. Các phân tích này có thể được hỗ trợ bởi các phân tích đã thực hiện cho các đơn vị công việc đối với phần tử ADV_TDS.3.10C, mà các ánh xạ TSFI trong đặc tả chức năng đến các mô đun của TSF.

Tương tác của một mô đun với các mô đun khác vượt ra ngoài tài liệu kiểu cây truy xuất. Sự tương tác được mô tả từ góc độ chức năng lý do tại sao một mô đun tương tác với các mô đun khác. Các mục đích của mô đun mô tả những chức năng gì của mô đun cung cấp cho các mô đun khác, sự tương tác nên mô tả những gì các mô đun phụ thuộc vào các mô đun khác để thực hiện chức năng này.

Vì các mô đun ở mức độ thấp như vậy, rất khó có thể xác định tính hoàn thiệt và chính xác tác động từ tài liệu khác, chẳng hn như tài liệu hướng dẫn người sử dụng vận hành, đặc tả chức năng, mô tả kiến trúc an toàn hoặc tài liệu về tính chất TSF. Tuy nhiên, người đánh giá sử dụng các thông tin sẵn có trong các tài liệu này thuộc phạm vi có thể giúp để đảm bảo rằng các tương tác được mô tả đầy đủ và chính xác.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.8.3.4.13  Đơn vị công việc ADV_TDS.3-13

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng nó có chứa đầy đủ và chính xác ánh xạ từ TSFI được mô tả trong các đặc tả chức năng đến các mô đun của TSF đã mô tả trong thiết kế TOE.

Các mô đun được mô tả trong thiết kế TOE cung cấp mô tả về triển khai TSF. Các TSFI cung cấp một mô tả làm cách nào triển khai được thực hiện. Các bằng chứng từ nhà phát triển xác định mô đun ban đầu được gọi đến khi một hoạt động được yêu cầu tại các TSFI và xác định chuỗi các mô đun gọi đến các mô đun đó chủ yếu chịu trách nhiệm cho việc thực hiện các chức năng. Tuy nhiên, một cây truy xuất đầy đủ cho mỗi TSFI là không được yêu cầu cho đơn vị công việc này. Các trường hợp trong đó nhiều hơn một mô đun sẽ được xác định là nơi có mô đun "điểm khởi đầu" hoặc các mô đun trình bao bọc mà không có chức năng khác ngoài điều kiện đầu vào hoặc giải ghép kênh đầu vào. Ánh xạ đến một trong các mô đun không cung cấp bt kỳ thông tin hữu ích nào cho người đánh giá.

Người đánh giá đánh giá tính hoàn thiện của ánh xạ bằng cách đảm bảo rằng tất cả các TSFI ánh xạ đến ít nhất một mô đun. Các xác minh độ chính xác có nhiều phức tạp.

Vì các mô đun ở mức độ thấp như vậy, rất khó có thể xác định tính hoàn thiệt và chính xác tác động từ tài liệu khác, chẳng hạn như tài liệu hướng dẫn người sử dụng vận hành, đặc tả chức năng, mô tả kiến trúc an toàn hoặc tài liệu về tính chất TSF. Tuy nhiên, người đánh giá sử dụng các thông tin sẵn có trong các tài liệu này thuộc phạm vi có thể giúp để đảm bảo rằng các tương tác được mô tả đầy đủ và chính xác.

10.8.3.5  Hành động ADV_TDS.3.2E

10.8.3.5.1  Đơn vị công việc ADV_TDS.3-14

Người đánh giá cần thẩm tra các yêu cầu chức năng an toàn TOE và thiết kế TOE, để xác định rằng tt cả các yêu cầu chức năng an toàn của ST được bao phủ bởi thiết kế TOE.

Người đánh giá có thể xây dựng một ánh xạ giữa các yêu cầu chức năng an toàn TOE và thiết kế TOE. Ánh xạ này có thể từ một yêu cầu chức năng đến một tập hợp các hệ thống con và sau đó đến các mô đun. Lưu ý rằng ánh xạ này có thể có được ở một mức độ chi tiết dưới mức thành phần hoặc thậm chí mức phần tử của các yêu cầu, bởi vì các hoạt động (chỉ định, bổ sung chi tiết, lựa chọn) thực hiện trên các yêu cầu chức năng của tác giả ST.

Ví dụ, thành phần kiểm soát truy nhập tập con FDP_ACC.1 chứa một phần tử với các chỉ định. Ví dụ, nếu ST chứa mười quy tắc trong chỉ định kiểm soát truy nhập tập hợp con FDP_ACC.1 và mười quy tắc này được triển khai ở những vị trí xác định trong mười lăm mô đun, nó sẽ không thích hợp cho người đánh giá ánh xạ điều khiển truy nhập tập con FDP_ACC.1 tới một hệ thống con và yêu cầu các đơn vị công việc được hoàn thành. Thay vào đó, người đánh giá sẽ ánh xạ điều khiển truy nhập tập con FDP_ACC.1 (quy tắc 1) đến các mô đun x, y và z của hệ thống con A; điều khiển truy nhập tập con FDP_ACC.1 (quy tắc 2) đến các mô đun x, p và q của hệ thống con A.v.v...

10.8.3.5.2  Đơn vị công việc ADV_TDS.3-15

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng nó là một cài đặt chính xác của tất cả các yêu cầu chức năng an toàn.

Người đánh giá có thể xây dựng một ánh xạ giữa các yêu cầu chức năng an toàn của TOE và thiết kế TOE. Ánh xạ này có thể từ một yêu cầu chức năng đến một tập hợp các hệ thống con. Lưu ý rằng ánh xạ này có thể có được ở một mức độ chi tiết dưới mức thành phần hoặc thậm chí mức phần tử của các yêu cầu, bởi vì các hoạt động (chỉ định, bổ sung chi tiết, lựa chọn) thực hiện trên các yêu cầu chức năng của tác giả ST.

Ví dụ, nếu các yêu cầu ST quy định một cơ chế kiểm soát truy nhập dựa trên vai trò, người đánh giá cần đầu tiên xác định rằng các hệ thng con và các mô đun đó góp phần triển khai cơ chế này. Điều này có thể được thực hiện nhờ kiến thức và sự hiểu biết chuyên sâu về thiết kế TOE hoặc bằng việc thực hiện trong đơn vị công việc trước đó. Lưu ý rằng theo dấu này chỉ để xác định các hệ thống con và không phải là phân tích đầy đủ.

Bước tiếp theo là hiểu biết cơ chế nào thực hiện các hệ thống con và các mô đun. Ví dụ, nếu thiết kế mô tả một việc triển khai kiểm soát truy nhập dựa trên các bit bảo vệ kiểu-UNIX, thiết kế sẽ không phải là một cài đặt chính xác các yêu cầu kiểm soát truy nhập này tạo ra trong ví dụ ST sử dụng ở trên. Nếu người đánh giá không thể xác định các cơ chế đã được thực hiện chính xác vì thiếu chi tiết, người đánh giá cần phải đánh giá xem liệu tất cả các hệ thống con và các mô đun thực thi SFR có được xác định hoặc nếu đủ chi tiết có được cung cấp cho các hệ thống con này không.

10.8.4  Đánh giá hoạt động con (ADV_TDS.4)

10.8.4.1  Mục tiêu

Mục tiêu của hoạt động con này là xác định liệu thiết kế TOE có cung cấp một mô tả của TOE trong thuật ngữ của hệ thống con đ để xác định ranh giới TSF và cung cấp một mô tả nội bộ TSF trong thuật ngữ của mô đun không (và tùy chọn sự trừu tượng mức cao hơn). Nó cung cấp một mô tả chi tiết các mô đun thực thi SFR và đầy đủ thông tin về các mô đun hỗ trợ SFR và không can thiệp SFR cho người đánh giá để xác định rằng các SFR được triển khai đầy đủ và chính xác, như vậy, thiết kế TOE cung cấp giải thích của biểu diễn triển khai.

10.8.4.2  Đầu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) đặc tả chức năng;

c) mô tả kiến trúc an toàn;

d) thiết kế TOE.

10.8.4.3  Lưu ý áp dụng

Có ba loại hoạt động mà người đánh giá cần thực hiện đối với thiết kế TOE. Đầu tiên, người đánh giá xác định rằng ranh giới TSF đi được mô tả đầy đủ. Thứ hai, người đánh giá xác định rằng nhà phát triển đã cung cấp tài liệu phù hợp với các yêu cầu nội dung và trình bày đối với các hệ thống con này và nó là nhất quán với các tài liệu khác được cung cấp cho TOE. Cuối cùng, người đánh giá phải phân tích thông tin thiết kế đã cung cấp cho các mô đun thực thi SFR ( mức chi tiết) và các mô đun hỗ trợ SFR và không can thiệp SFR ( một mức độ ít chi tiết) đ hiểu làm thế nào hệ thống được triển khai và với kiến thức đảm bảo rằng các TSFI trong đặc tả chức năng được mô tả đầy đủ và các thông tin kiểm thử đầy đủ các kim thử TSF (thực hiện trong Lớp ATE: Các đơn vị công việc kiểm thử).

10.8.4.4  Hành động ADV_TDS.4.1E

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.4.1C: Bản thiết kế cn mô tả cấu trúc TOE với các hệ thống con.

10.8.4.4.1  Đơn vị công việc ADV_TDS.4-1

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng cấu trúc của toàn bộ TOE được mô tả trong thuật ngữ các hệ thống con.

Người đánh giá đảm bảo rằng tất cả các hệ thống con của TOE được xác định. Đặc tả này của TOE sẽ được sử dụng như đầu vào cho đơn vị công việc ADV_TDS.4-5, nơi các thành phần của TOE tạo nên TSF được xác định. Do đó, yêu cầu này là trên toàn bộ TOE chứ không phải ch cho TSF.

TOE (và TSF) có thể được mô t trong nhiều lớp trừu tượng (ví dụ: các hệ thống con và các mô đun). Tùy thuộc vào sự phức tạp của TOE, thiết kế của nó có thể được mô tả trong các thuật ngữ của các hệ thống con và mô đun, như đã mô tả trong TCVN 8709-3 (ISO/IEC 15408-3) Phụ lục A.4, ADV_TDS: Các hệ thống con và các mô đun. Đối với một TOE đơn giản có thể được mô tả ch tại cấp độ "mô đun" (xem ADV_TDS.4-3), đơn vị công việc này không phải áp dụng và do đó được xem là thỏa mãn.

Khi thực hiện hoạt động này, người đánh giá thẩm tra bằng chứng khác đối với TOE (ví dụ: ST, hướng dẫn người sử dụng của nhà khai thác) để xác định rằng mô tả TOE trong bằng chứng như vậy là nhất quán với mô tả có trong thiết kế TOE.

10.8.4.4.2  Đơn vị công việc ADV_TDS.4-2

Người đánh giá cần kiểm tra các tài liệu TDS để xác định rằng ghi chú không chính thức được sử dụng cho mô tả các hệ thống con, mô đun và giao diện của chúng được xác định hoặc tham chiếu.

Một ghi chú không chính thức có thể được hoặc xác định bởi các nhà bảo trợ hoặc tương ứng với tiêu chuẩn được tham chiếu. Người đánh giá nên cung cấp một ánh xạ của các chức năng an toàn và các giao diện phác tho của chúng trong phần tài liệu chức năng hoặc giao diện được mô tả bán chính thức và những gì ký hiệu được sử dụng. Người đánh giá thẩm tra tất cả ghi chú không chính thức được sử dụng để chắc chắn rằng chúng đang theo một kiểu bán chính thức và để biện minh cho sự phù hợp về cách thức làm thế nào các ghi chú không chính thức được sử dụng cho các TOE.

Người đánh giá được nhc nh rằng một bài thuyết trình bn chính thức được đặc trưng bởi một định dạng tiêu chuẩn với một cú pháp rõ ràng làm giảm sự không rõ ràng có thể xảy ra trong các bài thuyết trình chính thức. Cú pháp của tất cả các ghi chú không chính thức được sử dụng trong đặc tả chức năng cần được xác định hoặc tương đương với một tiêu chuẩn được tham chiếu. Người đánh giá xác minh rằng các ghi chú không chính thức được sử dụng để thể hiện các đặc tả chức năng có khả năng thể hiện các tính năng liên quan đến an toàn. Để xác định điều này, người đánh giá có thể tham khảo đến SFR và so sánh các tính năng an toàn của TSF đã nêu trong ST và mô tả ấy trong FSP bằng cách sử dụng các ghi chú không chính thức.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.4.2C: Bn thiết kế cn mô tả TSF với các mô đun, thiết kế mỗi mô đun theo thực thi SFR, hỗ trợ SFR hoặc không can thiệp SFR.

10.8.4.4.3  Đơn vị công việc ADV_TDS.4-3

Người đánh giá cần thẩm tra thiết kế TOE để xác định rng toàn bộ TSF được mô tả trong thuật ngữ các mô đun.

Người đánh giá sẽ thẩm tra các mô đun đối với các thuộc tính cụ thể trong các đơn vị công việc khác nhau; trong đơn vị công việc này người đánh giá xác định rằng mô tả mô đun bao gồm toàn bộ các TSF, không chỉ là một phần của TSF. Người đánh giá sử dụng các bằng chứng khác nhau đã cung cấp cho việc đánh giá (ví dụ, đặc tả chức năng, mô tả kiến trúc) trong việc tạo ra quyết định này. Ví dụ, nếu các đặc tả chức năng chứa giao diện chức năng mà không xuất hiện đã được mô tả trong mô tả thiết kế TOE, nó có thể là trường hợp một phần của TSF đã không được đưa vào một cách thích hợp. Việc thực hiện quyết định này có thể là một quá trình lặp đi lặp lại, trong khi đó nhiều phân tích được thực hiện trên các bằng chứng khác, có thể đạt được độ tin cậy cao hơn đối với tính hoàn thiện của tài liệu.

Không giống như các hệ thống con, các mô đun mô tả việc triển khai ở một mức độ chi tiết có thể phục vụ như một hướng dẫn để xem xét các biu diễn triển khai. Một mô tả của một mô đun nên theo cách sao cho nó có thể triển khai mô đun từ mô tả đó và kết quả việc triển khai sẽ là 1) giống như việc triển khai TSF thực tế theo các giao diện được trình bày và sử dụng bởi các mô đun là 2) thuật toán giống với mô đun TSF. Ví dụ, RFC 793 cung cấp một mô tả cấp độ cao các giao thức TCP. Điều đó nhất thiết phải triển khai độc lập. Trong khi nó cung cấp các chi tiết đầy đủ, nó không phải là một mô tả thiết kế phù hợp bởi vì nó không cụ thể trong việc triển khai. Một triển khai thực tế có thể thêm giao thức quy định trong các RFC và sự lựa chọn triển khai (ví dụ, các sử dụng các dữ liệu toàn cục, so với dữ liệu cục bộ trong các phần khác nhau của việc triển khai) có thể có một tác động vào việc phân tích được thực hiện. Mô tả thiết kế của mô đun TCP sẽ liệt kê các giao diện được trình bày bởi việc triển khai (thay vì ch những định nghĩa trong RFC 793), cũng như một mô tả thuật toán của việc xử lý kết hợp với các mô đun triển khai TCP (giả sử nó là một phần của TSF).

10.8.4.4.4  Đơn vị công việc ADV_TDS.4-4

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng các mô đun TSF được xác định hoặc thực thi SFR hoặc hỗ trợ SFR hoặc không can thiệp SFR.

Mục đích của việc chỉ định mỗi mô đun (theo vai trò cụ thể của mô đun trong việc thực thi các SFR) là cho phép các nhà phát triển cung cấp ít thông tin về các phần của TSF có vai trò thấp trong an toàn. Nó luôn luôn cho phép nhà phát triển cung cấp nhiều thông tin hay chi tiết hơn so với các yêu cầu, như có thể xảy ra khi các thông tin đã được tập hợp bên ngoài bối cảnh đánh giá. Trong trường hợp này nhà phát triển vẫn phải chỉ định các mô đun hoặc thực thi SFR hoặc hỗ trợ SFR hoặc không can thiệp SFR.

Độ chính xác của những chỉ định này được tiếp tục xem xét như việc tiến hành đánh giá. Mối quan tâm có chỉ định sai các mô đun là ít quan trọng (và do đó, có ít thông tin) hơn là trường hợp thực tế. Trong khi chỉ định sai rõ ràng có thể là ngay lập tức (ví dụ, chỉ định một mô đun xác thực là gì đó khác thực thi SFR nếu đnh danh người dùng (FIA_UID) là một trong những SFR đang được yêu cầu), chỉ định sai khác có thể không được phát hiện cho đến khi TSF được tìm hiểu kỹ hơn. Do đó, người đánh giá cần phải ghi nh rằng những chỉ định này là những nỗ lực ban đầu tt nhất của nhà phát triển, nhưng là chủ đề để có thể thay đổi. Hướng dẫn chi tiết được cung cấp trong đơn vị công việc ADV_TDS.4-16, thẩm tra về độ chính xác của các chỉ định này.

TCVN 8709-3 (ISO/IEC 15408-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.

10.8.4.4.5  Đơn vị công việc ADV_TDS.4-5

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng tất cả các hệ thống con của TSF được xác định.

Nếu thiết kế được trình bày chỉ trong các thuật ngữ của các mô đun, khi đó các hệ thống con trong những yêu cầu này là tương đương với các mô đun và hoạt động nên được thực hiện ở cấp mô đun.

Trong đơn vị công việc ADV_TDS.4-1, tất cả các hệ thống con của TOE đã được xác định và quyết định chỉ ra rằng các hệ thống con không TSF được đặc tả một cách chính xác. Dựa trên công việc đó, các hệ thống con không được đặc tả như là hệ thống con không TSF nên xác định một cách chính xác. Người đánh giá xác định rằng, trong những phần cứng và phần mềm được cài đặt và cấu hình theo hướng dẫn cho các thủ tục chuẩn bị (AGD_PRE), mỗi hệ thống con đã được xác định như là hoặc một phần của TSF hoặc không.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.4.4C: Bản thiết kế cn tạo 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.

10.8.4.4.6  Đơn vị công việc ADV_TDS.4-6

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng mỗi hệ thống con của TSF mô t vai trò của nó trong việc thực thi các SFR đã mô tả trong ST.

Nếu thiết kế được trình bày chỉ trong các thuật ngữ của các mô đun, khi đó đơn vị công việc này sẽ được xem là thỏa mãn việc đánh giá thực hiện trong đơn vị công việc tiếp theo; trong trường hợp này không có hành động của người đánh giá.

Trên các hệ thống đủ phức tạp đ đảm bảo một mô tả cấp hệ thống con của TSF ngoài việc mô tả mô đun, mục tiêu của mô tả cấp hệ thống con là để cung cấp cho người đánh giá ngữ cảnh của việc mô tả mô đun tiếp theo. Do đó, người đánh giá đảm bảo rằng mô tả cấp hệ thống con cha một mô tả cách mà các yêu cầu chức an toàn đạt được trong thiết kế, nhưng ở một mức độ trừu tượng ở trên mô tả mô đun. Mô tả này nên thảo luận các cơ chế sử dụng ở một mức độ được liên kết với mô tả mô đun; điều này sẽ cung cấp cho người đánh giá lộ trình ánh xạ được yêu cầu đ đánh giá một cách thông minh các thông tin chứa trong mô tả mô đun. Một tập các mô tả hệ thống con bằng văn bản một cách đầy đủ sẽ giúp hướng dẫn người đánh giá trong việc xác định các mô đun quan trọng nhất để thẩm tra, do đó tập trung vào đánh giá hoạt động trên các phần của TSF mà phù hợp nhất với việc thực thi của các SFR.

Người đánh giá đảm bảo rằng tất cả các hệ thống con của TSF có một mô tả. Trong khi mô tả nên tập trung về vai trò mà hệ thống con trong thực thi hoặc hỗ trợ triển khai các SFR, đầy đủ thông tin phải hiện thị sao cho một bối cảnh cho sự hiểu biết các chức năng liên quan SFR được tạo ra.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.4.5C: Bn thiết kế cần tạo ra mô tả cho các tương tác của mọi hệ thống con của TSF.

10.8.4.4.7  Đơn vị công việc ADV_TDS.4-7

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng sự tương tác giữa các hệ thống con của TSF được mô tả.

Nếu thiết kế được trình bày chỉ trong các thuật ngữ của các mô đun, khi đó đơn vị công việc này sẽ được xem là thỏa mãn việc đánh giá thực hiện trong đơn vị công việc tiếp theo; trong trường hợp này không có hành động của người đánh giá.

Trên các hệ thống đủ phức tạp để đảm bảo một mô tả cấp hệ thống con của TSF ngoài mô tả mô đun, mục tiêu của mô tả sự tương tác giữa các hệ thống con thực thi SFR và các hệ thống con khác là giúp cung cấp cho người đọc hiểu biết hơn về cách TSF thực hiện các chức năng của nó. Những tương tác này không cần phải được mô tả ở mức triển khai (ví dụ, thông số được truyền từ một đoạn chương trình trong một hệ thống con đến một đoạn chương trình trong một hệ thống con khác, biến số toàn cục, tín hiệu phần cứng (ví dụ, ngắt) từ một hệ thống con phần cứng tới một hệ thống con điều khiển ngắt), nhưng các yếu tố dữ liệu xác định cho một hệ thống con đặc biệt được sử dụng bởi một hệ thống con khác cần được đề cập trong thảo luận này. Bất kỳ mối quan hệ điều khiển nào giữa hệ thống con (ví dụ, một hệ thống con chịu trách nhiệm cấu hình một nguyên tắc cơ bản cho một hệ thống tường lửa và một hệ thống con thực sự thực hiện các quy tắc này) cũng nên được mô tả.

Cần phải lưu ý trong khi nhà phát triển mô tả tất cả tương tác giữa các hệ thống con, người đánh giá cần phải sử dụng nhận định của riêng họ trong việc đánh giá tính trọn vẹn của sự mô tả. Nếu lý do cho một tương tác là không rõ ràng hoặc nếu có những tương tác liên quan SFR (ví dụ: phát hiện trong kiểm tra các mô tả đáp ứng của hệ thống con) không được mô tả, người đánh giá đảm bảo rằng thông tin này được cung cấp bởi nhà phát triển. Tuy nhiên, nếu người đánh giá có thể xác định rằng sự tương tác trong một tập hợp riêng của các hệ thống con, trong khi nhà phát triển mô tả không đầy đủ, sẽ không hỗ trợ tìm hiểu về chức năng tổng thể cũng như chức năng an toàn được cung cấp bởi TSF, khi đó người đánh giá có thể chọn coi như mô tả đầy đủ và không theo đuổi tính trọn vẹn vì mục đích riêng của mình.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.4.6C: Bn thiết kế cần tạo ra ánh xạ từ các hệ thống con của TSF đến các mô đun của TSF.

10.8.4.4.8  Đơn vị công việc ADV_TDS.4-8

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng ánh xạ giữa các hệ thống con của TSF và các mô đun của TSF là đầy đủ.

Nếu thiết kế được trình bày chỉ trong các thuật ngữ của các mô đun, khi đó đơn vị công việc này sẽ được xem là thỏa mãn.

Đối với TOE đ phức tạp để đảm bảo một mô tả cấp hệ thống con của TSF ngoài mô tả mô đun, nhà phát triển cung cấp một ánh xạ đơn cho thấy làm cách nào các mô đun của TSF phân b cho các hệ thống con. Điều này sẽ cung cấp cho người đánh giá một hướng dẫn trong việc thực hiện đánh giá cấp mô đun của nó. Để xác định tính toàn vẹn, người đánh giá thẩm tra từng ánh xạ và xác định rằng tt cả hệ thống con ánh xạ ít nhất đến một mô đun và tất cả các mô đun ánh xạ chính xác đến một hệ thống con.

10.8.4.4.9  Đơn vị công việc ADV_TDS.4-9

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng ánh xạ giữa các hệ thống con của TSF và các mô đun của TSF là chính xác.

Nếu thiết kế được trình bày ch trong các thuật ngữ của các mô đun, khi đó đơn vị công việc này sẽ được xem là thỏa mãn.

Đối với TOE đ phức tạp để đảm bảo một mô tả cấp hệ thống con của TSF ngoài mô tả mô đun, nhà phát triển cung cấp một ánh xạ đơn cho thấy làm cách nào các mô đun của TSF phân bổ cho các hệ thống con. Điều này sẽ cung cấp cho người đánh giá một hướng dẫn trong việc thực hiện đánh giá cấp mô đun của nó. Người đánh giá có thể lựa chọn để kiểm tra tính chính xác của các ánh xạ kết hợp với thực hiện các đơn vị công việc khác. Một ánh xạ "không chính xác" là ánh xạ mà các mô đun liên quan chỉ định nhầm đến một hệ thống con nơi mà chức năng của nó không được sử dụng trong hệ thống con. Bởi vì ánh xạ được thiết kế để trở thành một hướng dẫn hỗ trợ các phân tích chi tiết hơn, người đánh giá được cảnh báo để cố gắng áp dụng phù hợp với đơn vị công việc này. Mở rộng nguồn tài nguyên sâu rộng của người đánh giá để xác minh tính chính xác của ánh xạ là không được yêu cầu. Tính không chính xác dẫn đến sự hiu sai liên quan đến việc thiết kế không được đề cập ở đây hay ở các đơn vị công việc khác nên gắn với đơn vị công việc này và được sửa lại cho chính xác.

TCVN 8709-3 (ISO/IEC 15408-3) ADV.TDS.4.7C: Bản thiết kế cần mô tả mỗi mô đun thực thi 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.

10.8.4.4.10  Đơn vị công việc ADV_TDS.4-10

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng các mô tả về mục đích của mỗi mô đun thực thi SFR và hỗ trợ SFR là đầy đủ và chính xác.

Nhà phát triển có thể chỉ định các mô đun là thực thi SFR, hỗ trợ SFR và không can thiệp SFR, nhưng các "thẻ" này ch được sử dụng để mô tả số lượng và loại thông tin mà nhà phát triển phải cung cấp và có thể được sử dụng để hạn chế số lượng thông tin nhà phát triển phải phát triển nếu quy trình kỹ thuật của họ không tạo ra các tài liệu được yêu cầu. Cho dù các mô đun có được phân loại bởi nhà phát triển hay không, người đánh giá có trách nhiệm xác định các mô đun có các thông tin thích hợp cho vai trò của chúng (thực thi SFR, v.v...) trong TOE và để có được những thông tin thích hợp từ nhà phát triển nên lỗi của nhà phát triển cung cấp các thông tin được yêu cầu cho một mô đun cụ thể.

Mục đích của mô đun là cung cấp một mô tả cho thấy chức năng gì mô đun thỏa mãn. Người đánh giá cần chú ý tới các thứ tự. Trọng tâm của đơn vị công việc này nên cung cấp cho người đánh giá các hiểu biết về cách mà các mô đun hoạt động để có thể quyết định về tính đúng đắn của việc triển khai các SFR, cũng như để hỗ trợ phân tích kiến trúc thực hiện cho thành phần ADV_ARC. Miễn là người đánh giá hiểu biết về hoạt động của mô đun và mối quan hệ của nó với các mô đun khác và TOE như một tổng thể, người đánh giá nên xem xét mục tiêu của công việc đạt được và không tham gia vào một tài liệu hướng dẫn thực hiện của nhà phát triển (bằng cách yêu cầu, ví dụ, một thuật toán hoàn chỉnh mô tả cho một biểu diễn triển khai là hiển nhiên).

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.4.8C: Bn thiết kế cần mô tả mỗi mô đun thực thi 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.

10.8.4.4.11  Đơn vị công việc ADV_TDS.4-11

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng các mô tả về giao diện được trình bày bởi mỗi mô đun thực thi SFR và hỗ trợ SFR cha mô tả chính xác và đầy đủ các thông số liên quan SFR, các quy ưc gọi đến đối với mỗi giao diện và bất kỳ giá trị nào tr lại trực tiếp từ các giao diện.

Các giao diện liên quan SFR của một mô đun là những giao diện được sử dụng bởi các mô đun khác như một phương tiện đ gọi các hoạt động liên quan SFR đã cung cấp và để cung cấp đầu vào hoặc nhận kết quả đầu ra từ các mô đun. Mục đích của các đặc điểm kỹ thuật của các giao diện này là cho phép việc thực hiện chúng trong quá trình kiểm thử. Giao diện liên mô đun mà không liên quan SFR không cần được quy định hoặc được mô tả, do chúng không phải là một yếu tố trong kiểm thử. Tương tự như vậy, các giao diện nội bộ khác mà không phải là một yếu tố trong liên quan SFR đến cách thức thực hiện (chẳng hạn như những đường c định bên trong).

Các giao diện liên quan SFR được mô tả trong thuật ngữ theo cách chúng được gọi đến và bất kỳ các giá trị được trả về. Mô tả này sẽ bao gồm một danh sách các thông số và các mô tả của các tham số này. Lưu ý rằng dữ liệu toàn cục cũng sẽ được xem là các thông số nếu được sử dụng bởi mô đun (hoặc là các đầu vào hoặc là các đầu ra) khi được gọi đến. Nếu một tham số được dự kiến sẽ đưa vào một tập các giá trị (ví dụ, một tham số "cờ"), thiết lập đầy đủ của giá trị các tham số có thể đưa vào đó sẽ có một tác động vào việc xử lý mô đun s được xác định. Tương tự như vậy, các thông số đại diện cho cấu trúc dữ liệu được mô tả như các trường của cấu trúc dữ liệu được xác định và mô tả. Lưu ý rằng các ngôn ngữ lập trình khác nhau có thể có thêm "các giao diện" không rõ ràng, ví dụ như nhà điều hành/chức năng quá tải trong C++. "Giao diện không rõ ràng" này trong các lớp mô tả cũng có thể được mô tả như là một phần của thiết kế TOE ở mức độ thấp. Lưu ý rằng mặc dù một mô đun chỉ có thể trình bày một giao diện, thông thường thì một mô đun trình bày một tập con các giao diện liên quan.

Trong thuật ngữ vầ đánh giá các thông số (các đầu vào và các đầu ra) của một mô đun, sử dụng bất kỳ dữ liệu toàn cục nào cũng phải được cân nhc. Một mô đun "sử dụng" dữ liệu toàn cục nếu nó hoặc là đọc hoặc là ghi dữ liệu. Để đảm bảo sự mô tả các thông số như vậy (nếu sử dụng) là đầy đủ, người đánh giá sử dụng các thông tin khác được cung cấp về mô đun trong thiết kế TOE (các giao diện, thuật toán mô tả, v.v...), cũng như mô tả về tập hợp đặc biệt của dữ liệu toàn cục đã đánh giá trong đơn vị công việc ADV_TDS.4-10. Ví dụ, người đánh giá có thể đầu tiên xác định việc xử lý các mô đun thực hiện bằng cách kiểm tra chức năng và giao diện sẵn có (đặc biệt là các thông số của các giao diện). Sau đó họ có thể kiểm tra để xem xét nếu các quá trình xử lý "chạm" đến bất kỳ khu vực dữ liệu toàn cục được xác định trong thiết kế TOE. Người đánh giá sau đó xác định rằng, đối với mỗi khu vực dữ liệu toàn cục bị "chạm", khu vực dữ liệu toàn cục đó được liệt kê như là đầu vào hay đầu ra của mô đun mà người đánh giá thẩm tra.

Quy ước gọi đến là một đặc tả kiểu tham chiếu lập trình có thể sử dụng để gọi đến chính xác một giao diện của một mô đun nếu một người đang viết một chương trình đ sử dụng các chức năng của mô đun thông qua giao diện đó. Điều này bao gồm các đầu vào và các đầu ra được yêu cầu, bao gồm cả các thiết lập mà có thể cần được thực hiện đối với các biến số toàn cục.

Giá trị trả về thông qua giao diện liên quan đến các giá trị mà hoặc là thông qua các thông số hoặc là các thông báo; giá trị mà các chức năng truy xuất tự nó trả về trong kiểu của một truy xuất chức năng lập trình "C" hoặc giá trị được truyền thông qua phương thức toàn cục (chẳng hạn như các tuyến lỗi cụ thể trong các hệ điều hành kiểu *ix).

Để đảm bảo các mô tả là đầy đủ, người đánh giá sử dụng thông tin khác được cung cấp bởi mô đun trong thiết kế TOE (ví dụ, thuật toán mô tả, dữ liệu toàn cục được sử dụng) để đảm bảo rằng tất cả dữ liệu được yêu cầu để thực hiện các chức năng của mô đun đã sẵn có cho các mô đun và rằng bất kỳ giá trị mà các mô đun khác kỳ vọng việc thẩm tra mô đun để cung cấp được xác định như được phản hồi bởi các mô đun. Người đánh giá xác định độ chính xác để đảm bảo rằng mô tả của các xử lý phù hợp với thông tin được liệt kê như được truyền đến hoặc đi từ một giao diện.

Vì các mô đun ở mức độ thấp như vậy, rất khó có thể xác định tính hoàn thiệt và chính xác tác động từ tài liệu khác, chẳng hạn như hướng dẫn người sử dụng vận hành, đặc tả chức năng, các tính chất TSF hoặc mô tả kiến trúc an toàn. Tuy nhiên, người đánh giá sử dụng các thông tin sẵn có trong các tài liệu này thuộc phạm vi có thể giúp đ đảm bảo rằng mục đích được mô tả đầy đủ và chính xác. Các phân tích này có thể được hỗ trợ bởi các phân tích đã thực hiện cho các đơn vị công việc đối với phần tử ADV_TDS.3.10C, mà các ánh xạ TSFI trong đặc tả chức năng đến các mô đun của TSF.

TCVN 8709-3 (ISO/IEC 15408-3) ADV_TDS.4.9C: Bn thiết kế cần mô tả mỗi mô đun không can thiệp SFR với mục đích và tương tác của chúng với các mô đun khác.

10.8.4.4.12  Đơn vị công việc ADV_TDS.4-12

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng mô đun không can thiệp SFR được phân loại chính xác.

Như đã đề cập trong đơn vị công việc ADV_TDS.4-3, ít thông tin được yêu cầu về mô đun không can thiệp SFR. Trọng tâm của người đánh giá cho đơn vị công việc này là cố gắng xác định từ những bằng chứng đã cung cấp cho mi mô đun phân loại không ngầm định như là không can thiệp SFR và thông tin đánh giá về các mô đun khác (trong thiết kế TOE, các đặc tả chức năng, mô tả kiến trúc an toàn và hướng dẫn người sử dụng vận hành), liệu các mô đun có thực sự không can thiệp SFR không. Ở cấp độ này một số lỗi đảm bảo có thể được bỏ qua; người đánh giá không hoàn toàn chắc chắn rằng một mô đun là không can thiệp SFR, mặc dù nó được dán nhãn như vậy. Tuy nhiên, nếu các bằng chứng được cung cấp ch ra rằng một mô đun không can thiệp SFR là thực thi SFR hoặc hỗ trợ SFR, người đánh giá yêu cầu thêm thông tin từ nhà phát triển để giải quyết sự không nhất quán rõ ràng. Ví dụ, giả sử các tài liệu hướng dẫn cho Mô đun A (một mô đun thực thi SFR) ch ra rằng nó truy xuất Mô đun B để thực hiện kiểm tra truy nhập trên một loại kết cấu nhất định. Khi người đánh giá thẩm tra các thông tin liên quan đến Mô đun B, họ thấy rằng tất cả nhà phát triển đã cung cấp một mục đích và một tập hp các tương tác (như vậy, Mô đun B phân loại không ngầm định như là hỗ trợ SFR hoặc không can thiệp SFR). Khi kiểm tra mục đích và tương tác của Mô đun A, người đánh giá thấy không đề cập đến Mô đun B thực hiện bất kỳ kiểm tra truy nhập nào và Mô đun A không được liệt kê như là một mô đun mà Mô đun B tương tác. Tại thời điểm này, người đánh giá nên tiếp cận nhà phát triển để giải quyết các khác biệt giữa thông tin đã cung cấp trong Mô đun A và trong Mô đun B.

Một ví dụ khác là nơi mà người đánh giá kiểm tra các ánh xạ của các TSFI đến các mô đun như cung cấp bởi ADV_TDS.4.2D. Việc thẩm tra này cho thấy, Mô đun C được kết hợp với một SFR yêu cầu xác định của người sử dụng. Một lần nữa, khi người đánh giá thẩm tra thông tin liên quan đến Mô đun C, người đánh giá thấy rằng tất cả nhà phát triển đã cung cấp một mục đích và một tập hợp các tương tác (như vậy, Mô đun C phân loại không ngầm định như là không can thiệp FSR). Kiểm tra mục đích và tương tác được trình bày cho Mô đun C, người đánh giá không thể xác định lý do tại sao Mô đun C, được liệt kê như ánh xạ từ TSFI liên quan đến người sử dụng xác định, sẽ không được phân loại là thực thi SFR hoặc hỗ trợ SFR. Một lần nữa, người đánh giá cần tiếp cận nhà phát triển đ giải quyết sự khác biệt này.

Một ví dụ cuối cùng đi từ quan đim ngược lại. Như trước đây, nhà phát triển đã cung cấp thông tin kết hợp với Mô đun D bao gồm một mục đích và một tập hợp các tương tác (như vậy, mặc nhiên phân loại Mô đun D phân loại không ngầm định như là hỗ trợ SFR hoặc không can thiệp FSR). Người đánh giá thẩm tra tất cả các bằng chứng đã cung cấp, bao gồm cả mục đích và tương tác với mô đun D. Các mục đích xuất hiện để cung cấp một mô tả ý nghĩa của chức năng Mô đun D trong TOE, sự tương tác nhất quán với mô t đó và không có gì chỉ ra rằng Mô đun D là thực thi SFR. Trong trường hợp này, người đánh giá không nên đòi hỏi nhiều thông tin về Mô đun D "chỉ là để đảm bảo" nó được phân loại một cách chính xác. Nhà phát triển đã thỏa mãn các nghĩa vụ của họ và người đánh giá đảm bảo kết quả có trong phân loại tiềm ẩn của Mô đun D là (theo định nghĩa) thích hợp cho mức độ đảm bảo này.

10.8.4.4.13  Đơn vị công việc ADV_TDS.4-13

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng mô tả về mục đích của mỗi mô đun không can thiệp SFR là đầy đủ và chính xác.

Các mô tả về mục đích của một mô đun chỉ ra những mô đun chức năng nào là thỏa mãn. Từ sự mô tả, người đánh giá có thể nên có được một ý tưởng chung về vai trò của mô đun. Để đảm bảo sự mô tả là đầy đủ, người đánh giá sử dụng các thông tin đã cung cấp về các tương tác của mô đun với các mô đun khác đ đánh giá liệu những lý do các mô đun được truy xuất có nhất quán với các mục đích của mô đun không. Nếu mô tả tương tác có chức năng không rõ ràng hoặc mâu thuẫn với, các mục đích của mô đun, người đánh giá cần xác định liệu vấn đề có ở tính chính xác hoặc tính toàn diện không. Người đánh giá nên chú ý với các mục đích quá ngắn, do không thể phân tích ý nghĩa dựa trên mục đích ch có một câu.

Vì các mô đun ở mức độ thấp như vậy, rất khó có thể xác định tính hoàn thiệt và chính xác tác động từ tài liệu khác, chẳng hạn như tài liệu hướng dẫn người sử dụng vận hành, đặc tả chức năng, mô tả kiến trúc an toàn, các tính chất TSF. Tuy nhiên, người đánh giá sử dụng các thông tin tạo ra trong các tài liệu thuộc phạm vi có thể giúp để đảm bảo rằng chức năng được mô tả đầy đủ và chính xác. Phân tích này có thể được hỗ trợ bởi các phân tích đã thực hiện cho các đơn vị công việc đối với phần tử ADV_TDS.4.10C, mà các ánh xạ TSFI trong đặc tả chức năng đến các mô đun của TSF.

10.8.4.4.14  Đơn v công việc ADV_TDS.4-14

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng mô tả tương tác của mô đun không can thiệp SFR với các mô đun khác là đầy đủ và chính xác.

Điều quan trọng cần lưu ý là, trong các thuật ngữ của yêu cầu ở Phần 3 và đơn vị công việc này, thuật ngữ tương tác có mục đích truyền đạt ít nghiêm ngặt hơn so với thuật ngữ giao diện. Một tương tác không cần phải đặc tả ở cấp triển khai (ví dụ, thông số thông qua từ một tuyến trong một mô đun này tới một tuyến trong một mô đun khác; biến số toàn cục; các tín hiệu phần cứng (ví dụ, các ngt) từ một phần cứng của hệ thống con tới một hệ thống con xử lý ngắt), nhưng các phần tử dữ liệu xác định cho một mô đun được sử dụng bởi một mô đun đặc biệt nên được đề cập trong thảo luận này. Bất kỳ mối quan hệ kiểm soát giữa các mô đun (ví dụ, một mô đun chịu trách nhiệm cho việc cấu hình một nguyên tắc cơ bản cho một hệ thống tường lửa và các mô đun thực sự thực hiện các quy tắc) cũng nên được mô tả.

Tương tác của một mô đun với các mô đun khác có thể được giữ lại bằng nhiều cách khác nhau. Mục đích của thiết kế TOE là cho phép người đánh giá hiểu (một phần thông qua phân tích các tương tác mô đun) vai trò của hỗ trợ SFR và không can thiệp SFR trong tổng thể thiết kế TOE. Sự hiểu biết về vai trò này sẽ giúp người đánh giá trong việc thực hiện đơn vị công việc ADV_TDS.4-7.

Tương tác của một mô đun với các mô đun khác vượt ra ngoài tài liệu kiểu cây truy xuất. Sự tương tác được mô tả từ góc độ chức năng lý do tại sao một mô đun tương tác với các mô đun khác. Các mục đích của mô đun mô tả những chức năng của mô đun cung cấp cho các mô đun, sự tương tác nên mô tả những gì các mô đun phụ thuộc vào các mô đun trong đ thực hiện chức năng này.

Vì các mô đun ở mức độ thp như vậy, rất khó có thể xác định tính hoàn thiệt và chính xác tác động từ tài liệu khác, chẳng hạn như tài liệu hướng dẫn người sử dụng vận hành, đặc tả chức năng, mô tả kiến trúc an toàn, các tính chất TSF. Tuy nhiên, người đánh giá sử dụng các thông tin tạo ra trong các tài liệu thuộc phạm vi có thể giúp để đảm bảo rằng chức năng được mô tả đầy đủ và chính xác.

TCVN 8709-3 (ISO/IEC 15408-3) 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.

10.8.4.4.15  Đơn vị công việc ADV_TDS.4-15

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng nó có chứa đầy đ và chính xác ánh xạ từ TSFI được mô tả trong các đặc tả chức năng cho các mô đun của TSF đã mô tả trong thiết kế TOE.

Các mô đun được mô tả trong thiết kế TOE cung cấp mô tả về triển khai TSF. Các TSFI cung cấp một mô tả làm thế nào các thực hiện được thực hiện. Các bằng chứng từ nhà phát triển xác định các mô đun ban đầu được gọi khi một hoạt động được yêu cầu tại các TSFI và xác định các chuỗi các mô đun gọi lên đến các mô đun đó ch yếu chịu trách nhiệm cho việc thực hiện các chức năng. Tuy nhiên, một cây truy xuất đầy đủ cho mỗi TSFI là không được yêu cầu cho đơn vị công việc này. Các trường hợp trong đó nhiều hơn một mô đun sẽ được xác định là nơi có mô đun "điểm đưa vào" hoặc các mô đun trình bao bọc mà không có chức năng khác ngoài điều kiện đầu vào hoặc giải ghép kênh đu vào. Ánh xạ là một trong các mô đun cung cấp bất kỳ thông tin hữu ích cho người đánh giá.

Người đánh giá đánh giá tính hoàn thiện của ánh xạ bằng cách đảm bảo rằng tất cả các ánh xạ TSFI ít nhất một mô đun. Các xác minh độ chính xác có nhiều phức tạp.

Khía cạnh đầu tiên của độ chính xác là mỗi TSFI được ánh xạ tới một mô đun ở ranh giới TSF. Quyết định này có thể được thực hiện bằng cách xem xét việc mô tả mô đun và các giao diện/tương tác của nó. Các khía cạnh tiếp theo của độ chính xác là mỗi TSFI xác định một chuỗi các mô đun giữa mô đun ban đầu được xác định và một mô đun chịu trách nhiệm chính cho việc thực hiện chức năng sẵn có tại TSF. Lưu ý rằng đây có thể là mô đun ban đầu hoặc có thể là một số mô đun, tùy thuộc vào số lượng điều kiện đầu của đầu vào được thực hiện. Cần lưu ý rằng một trong những chỉ thị mô đun điều kiện đầu viện dẫn tới một số lượng lớn TSFI, nơi TSFI là cùng loại (ví dụ, truy xuất hệ thống). Khía cạnh cuối cùng của độ chính xác là ánh xạ có nghĩa. Ví dụ, ánh xạ việc xử lý TSFI với kiểm soát truy nhập tới một mô đun để kiểm tra mật khẩu là không chính xác. Người đánh giá nên một lần nữa sử dụng sự phán xét trong việc tạo ra quyết định này. Mục tiêu của thông tin này là hỗ trợ người đánh giá hiểu biết về hệ thống và triển khai các SFR và cách thức mà các thực thể tại ranh giới TSF có thể tương tác với các TSF. Phần lớn đánh giá liệu các SFR có được mô tả chính xác bởi các mô đun được thực hiện trong đơn vị công việc khác không.

10.8.4.5  Hành động ADV_TDS.4.2E

10.8.4.5.1  Đơn v công việc ADV_TDS.4-16

Người đánh giá cần thẩm tra các yêu cầu chức năng an toàn TOE và thiết kế TOE, để xác định rằng tất cả các yêu cầu chức năng an toàn của ST được bao phủ bởi thiết kế TOE.

Người đánh giá có thể xây dựng một ánh xạ giữa các yêu cầu chức năng an toàn TOE và thiết kế TOE. Ánh xạ này có thể từ một yêu cầu chức năng đến một tập hợp các hệ thống con và sau đó đến các mô đun. Lưu ý rằng ánh xạ này có thể có được ở một mức độ chi tiết dưới mức thành phần hoặc thậm chí mức phần tử của các yêu cầu, bởi vì các hoạt động (chỉ định, bổ sung chi tiết, lựa chọn) thực hiện trên các yêu cầu chức năng của tác giả ST.

Ví dụ, thành phần kim soát truy nhập tập con FDP_ACC.1 chứa một phần tử với các chỉ định. Ví dụ, nếu ST chứa mười quy tắc trong chỉ định kiểm soát truy nhập tập hợp con FDP_ACC.1 và mười quy tắc này được triển khai ở những vị trí xác định trong mười lăm mô đun, nó sẽ không thích hợp cho người đánh giá ánh xạ điều khiển truy nhập tập con FDP_ACC.1 tới một hệ thống con và yêu cầu các đơn vị công việc được hoàn thành. Thay vào đó, người đánh giá sẽ ánh xạ điều khiển truy nhập tập con FDP_ACC.1 (quy tắc 1) đến các mô đun x, y và z của hệ thống con A; điều khiển truy nhập tập con FDP_ACC.1 (quy tắc 2) đến các mô đun x, p và q của hệ thống con A.v.v...

10.8.4.5.2  Đơn vị công việc ADV_TDS.4-17

Người đánh giá cần thẩm tra thiết kế TOE để xác định rằng nó là một cài đặt chính xác của tất cả các yêu cầu chức năng an toàn.

Người đánh giá có thể xây dựng một ánh xạ giữa các yêu cầu chức năng an toàn của TOE và thiết kế TOE. Ánh xạ này có thể từ một yêu cầu chức năng đến một tập hợp các hệ thống con. Lưu ý rằng ánh xạ này có thể có được ở một mức độ chi tiết dưới mức thành phần hoặc thậm chí mức phần tử của các yêu cầu, bởi vì các hoạt động (chỉ định, bổ sung chi tiết, lựa chọn) thực hiện trên các yêu cầu chức năng của tác giả ST.

Ví dụ, nếu các yêu cầu ST quy định một cơ chế kiểm soát truy nhập dựa trên vai trò, người đánh giá cn đầu tiên xác định rằng các hệ thống con và các mô đun đó góp phần triển khai cơ chế này. Điều này có thể được thực hiện nhờ kiến thức và sự hiểu biết chuyên sâu về thiết kế TOE hoặc bằng việc thực hiện trong đơn vị công việc trước đó. Lưu ý rằng theo dấu này chỉ để xác định các hệ thống con và không phải là phân tích đầy đủ.

Bước tiếp theo là hiểu biết cơ chế nào thực hiện các hệ thống con và các mô đun. Ví dụ, nếu thiết kế mô tả một việc triển khai kiểm soát truy nhập dựa trên các bit bảo vệ kiểu-UNIX, thiết kế sẽ không phải là một cài đặt chính xác các yêu cầu kiểm soát truy nhập này tạo ra trong ví dụ ST sử dụng ở trên. Nếu người đánh giá không thể xác định các cơ chế đã được thực hiện chính xác vì thiếu chi tiết, người đánh giá cần phải đánh giá xem liệu tất cả các hệ thống con và các mô đun thực thi SFR có được xác định hoặc nếu đủ chi tiết có được cung cấp cho các hệ thống con này không.

10.8.5  Đánh giá hoạt động con (ADV_TDS.5)

Không có hướng dẫn chung; Nên tư vấn lược đồ để hướng dẫn hoạt động con này.

10.8.6  Đánh giá hoạt động con (ADV_TDS.6)

Không có hướng dẫn chung; Nên tư vấn lược đồ để hướng dẫn hoạt động con này.

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

11.1  Giới thiệu

Mục đích của hoạt động tài liệu hướng dẫn là để đánh giá tính đầy đủ của các tài liệu mô tả cách người sử dụng có thể xử lý các TOE một cách an toàn. Tài liệu hướng dẫn cần phân loại tài khoản theo các kiu người sử dụng khác nhau (ví dụ như những người chp nhn, cài đặt, quản trị hoặc vận hành TOE) mà các hành động không chính xác có thể ảnh hưởng xu đến an toàn của TOE hoặc dữ liệu của nó.

Lớp tài liệu hướng dẫn được chia thành hai họ, họ thứ nhất đề cập tới hướng dẫn người dùng chuẩn bị (tất cả các công việc đã được thực hiện để chuyển đổi TOE được giao vào cấu hình đánh giá trong môi trường như được mô tả trong ST, nghĩa là là chấp nhận và cài đặt TOE) và họ thứ hai đề cập tới hướng dẫn người sử dụng vận hành (tất cả các công việc đã được thực hiện trong quá trình vận hành TOE trong cấu hình đánh giá của nó, nghĩa là vận hành và quản trị).

11.2  Lưu ý áp dụng

Hoạt động tài liệu hướng dẫn áp dụng cho các chức năng và giao diện có liên quan đến sự an toàn của TOE. Cấu hình an toàn của TOE được mô tả trong ST.

11.3  Hướng dẫn sử dụng vận hành (AGD_OPE)

11.3.1  Đánh giá hoạt động con (AGD_OPE.1)

11.3.1.1  Mục tiêu

Mục tiêu của hoạt động con này là để xác định xem liệu hướng dẫn sử dụng có mô tả với từng vai trò người dùng các chức năng an toàn và giao diện được cung cấp bởi TSF, cung cấp chỉ dẫn và hướng dẫn sử dụng an toàn TOE, giải quyết các thủ tục an toàn cho tất cả các chế độ hoạt động, tạo điều kiện cho việc phòng chống và phát hiện các trạng thái không an toàn của TOE hoặc hướng dẫn sử dụng này có ch lỗi sai hoặc không hợp lý không.

11.3.1.2  Đu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) đặc tả chức năng;

c) thiết kế TOE, nếu áp dụng;

d) hướng dẫn người sử dụng.

11.3.1.3  Hành động AGD_OPE.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) AGD_OPE.1.1C: Tài liệu hướng dẫn người dùng vận hành cần mô tả với từng vai trò người dùng, các chức năng có thể truy nhập người dùng và các đặc quyền đó cn được kiểm soát trong môi trường xử lý an toàn, bao gồm các cảnh báo thích hợp.

11.3.1.3.1  Đơn vị công việc AGD_OPE.1-1

Người đánh giá cần xem xét các hướng dẫn người dùng vận hành để xác định rằng nó mô tả với từng vai trò người dùng, các chức năng có thể truy nhập người dùng và các đặc quyền đó phải được kiểm soát trong một môi trường xử lý an toàn, bao gồm c cảnh báo thích hợp.

Cấu hình của TOE có thể cho phép các vai trò người dùng khác nhau có các đặc quyền khác nhau trong việc sử dụng các chức năng khác nhau của TOE. Điều này có nghĩa rằng một số người dùng được cấp quyền thực hiện các chức năng nhất định, trong khi những người dùng khác không được cấp quyền thì không thực hiện được. Các chức năng và đặc quyền này nên được mô tả với từng vai trò người dùng bởi tài liệu hướng dẫn người dùng.

Tài liệu hướng dẫn người dùng xác định với từng vai trò người dùng, các chức năng và đặc quyền phải được kiểm soát, các loại lệnh cần thiết và các lý do của các lệnh đó. Tài liệu hướng dẫn người dùng nên có cảnh báo về việc sử dụng các chức năng và đặc quyền này. Các cảnh báo cần đưa ra các ảnh hưởng dự kiến, tác động phụ có thể có và các tương tác có thể với các chức năng và đặc quyền khác.

TCVN 8709-3 (ISO/IEC 15408-3) AGD_OPE.1.2C: Tài liệu hướng dẫn người dùng vận hành cần mô tả với từng vai trò người dùng, cách thức sử dụng các giao diện có sẵn được cung cấp bởi TOE một cách an toàn.

11.3.1.3.2  Đơn vị công việc AGD_OPE.1-2

Người đánh giá cần kiểm tra hướng dẫn người dùng vận hành để xác định rằng nó mô tả với từng vai trò người dùng, việc sử dụng an toàn giao diện có sẵn được cung cp bởi TOE.

Tài liệu hướng dẫn người dùng nên cung cấp lời khuyên về sử dụng hiệu quả TSF (ví dụ như xem xét lại thực hành tạo mật khẩu, tần suất người dùng sao lưu tập tin, thảo luận về các tác động của việc thay đổi đặc quyền truy nhập người dùng).

TCVN 8709-3 (ISO/IEC 15408-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ả với từng vai trò người dùng, các chức năng có sẵn và các giao diện, đặc biệt là tất cả các tham số an toàn dưới sự kiểm soát của người dùng, chỉ ra các giá trị an toàn thích hợp.

11.3.1.3.3  Đơn vị công việc AGD_OPE.1-3

Người đánh giá cần kiểm tra tài liệu hướng dẫn người dùng vận hành để xác định rằng nó mô tả với từng vai trò người dùng, chức năng an toàn có sẵn và giao diện, đặc biệt là tất cả thông số an toàn dưới quyền kiểm soát của người dùng, chỉ ra các giá trị an toàn thích hợp.

Tài liệu hướng dẫn người dùng nên có một cái nhìn tổng quan về chức năng an toàn có thể nhìn thấy được ở giao diện người dùng.

Tài liệu hướng dn người dùng nên xác định và mô tả mục đích, cơ chế và mối quan hệ của các giao diện và chức năng an toàn.

Với mỗi giao diện người dùng có thể truy nhập, tài liệu hướng dẫn người dùng cần:

a) mô tả các phương pháp bằng cách đó các giao diện được gọi (ví dụ như dòng lệnh, truy xuất hệ thống ngôn ngữ lập trình, lựa chọn menu, nút lệnh);

b) mô tả các thông số được thiết lập bởi người dùng, mục đích cụ thể của chúng, các giá trị hợp lệ và mặc định và các thiết lập sử dụng an toàn và không an toàn của các thông số đó, cả riêng rẽ hoặc kết hợp;

c) mô tả các đáp ứng TSF tức thì, bản tin hoặc mã được trả về.

Người đánh giá cần xem xét đặc tả chức năng và ST để xác định rằng các TSF được mô tả trong các tài liệu này nhất quán với hướng dẫn người dùng vận hành. Người đánh giá phải đảm bảo rằng các hướng dẫn người dùng vận hành là đầy đủ đ cho phép sử dụng an toàn thông qua TSFI có sẵn cho tất cả các loại người dùng. Người đánh giá có thể, như một hỗ trợ, chuẩn bị một ánh xạ không chính thức giữa các hướng dẫn và các tài liệu này. Bất kỳ thiếu sót nào trong việc ánh xạ này có thể chỉ ra sự thiếu hoàn chỉnh.

TCVN 8709-3 (ISO/IEC 15408-3) AGD_OPE.1.4C: Tài liệu hướng dẫn người dùng vận hành với từng vai trò người dùng, cần trình bày rõ ràng từng loại sự kiện an toàn thích hợp liên quan với các chức năng người dùng có thể truy nhập cần được thực hiện, bao gồm c việc thay đổi các đặc tính an toàn của các thực thể chịu sự kiểm soát của TSF.

11.3.1.3.4  Đơn vị công việc AGD_OPE.1-4

Người đánh giá cần kiểm tra hướng dẫn người dùng vận hành để xác định rằng nó mô tả, với từng vai trò người dùng, từng loại sự kiện an toàn thích hợp liên quan đến các chức năng người dùng cần phải được thực hiện, bao gồm cả việc thay đổi các tính chất an toàn của các thực thể chịu sự kiểm soát của TSF và vận hành thất bại hoặc lỗi vận hành.

Tất cả các loại sự kiện an toàn có liên quan được trình bày chi tiết với từng vai trò người dùng, chẳng hạn mỗi người dùng biết những sự kiện gì có thể xảy ra và những hành động (nếu có), có thể duy trì sự an toàn. Các sự kiện an toàn có liên quan có thể xảy ra trong quá trình vận hành của TOE (ví dụ như tràn kiểm tra, sập hệ thống, cập nhật hồ sơ cho người sử dụng, chẳng hạn như hy một tài khoản người dùng khi người dùng rời khỏi tổ chức) được định nghĩa đầy đủ để cho phép người dùng can thiệp để duy trì hoạt động an toàn.

TCVN 8709-3 (ISO/IEC 15408-3) 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 tất cả các 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), hậu quả và tác động của của chúng đối với việc duy trì vận hành an toàn.

11.3.1.3.5  Đơn vị công việc AGD_OPE.1-5

Người đánh giá cần kiểm tra hướng dẫn người dùng vận hành và các bằng chứng đánh giá khác để xác định rằng hướng dẫn xác định tất cả các chế độ hoạt động có thể của TOE (bao gồm nếu áp dụng, hoạt động sau khi tht bại hoặc lỗi hoạt động), hậu qu và những tác động của chúng đối với việc duy trì hoạt động an toàn.

Bằng chứng đánh giá khác, đặc biệt là các đặc tả chức năng, cung cấp một nguồn thông tin mà người đánh giá cần sử dụng để xác định các hướng dẫn có chứa thông tin hướng dẫn đầy đủ.

Nếu tài liệu kiểm thử bao gồm trong các gói bảo đảm, thì thông tin được cung cấp trong bằng chứng này cũng có thể được sử dụng để xác định rằng các hướng dẫn có chứa tài liệu hướng dẫn đầy đủ. Thông tin chi tiết được cung cấp trong các bước kiểm tra có thể được sử dụng để xác nhận rằng các hướng dẫn được cung cấp là đ cho việc sử dụng và quản trị TOE.

Người đánh giá cần tập trung vào một TSFI có thể nhìn thấy duy nhất tại một thời điểm, so sánh các hướng dẫn an toàn sử dụng TSFI với bằng chứng đánh giá khác để xác định rằng hướng dẫn liên quan đến TSFI là đủ cho việc sử dụng an toàn (tức là nhất quán với các SFR) của TSFI đó. Người đánh giá cũng nên xem xét các mối quan hệ giữa các giao diện, tìm kiếm xung đột tiềm n.

TCVN 8709-3 (ISO/IEC 15408-3) AGD_OPE.1.6C: Tài liệu hướng dn người dùng vận hành với từng vai trò người dùng, cần mô tả các biện pháp an toàn kèm theo đ thực hiện các mục tiêu an toàn đối với môi trường vận hành như đã mô tả trong ST.

11.3.1.3.6  Đơn vị công việc AGD_OPE.1-6

Người đánh giá cần kiểm tra hướng dẫn người dùng vận hành để xác định rằng nó mô tả, với từng vai trò người dùng, các biện pháp an toàn kèm theo để thực hiện các mục tiêu an toàn cho môi trường vận hành như được mô tả trong ST.

Người đánh giá phân tích các mục tiêu an toàn cho các môi trường vận hành trong ST và xác định rằng với từng vai trò người dùng, các biện pháp an toàn liên quan được mô tả một cách thích hợp trong hướng dẫn người dùng.

Các biện pháp an toàn được mô tả trong hướng dẫn người dùng cần bao gồm tất cả các biện pháp về thủ tục, vật lý, nhân sự và kết nối bên ngoài có liên quan.

Lưu ý rằng các biện pháp liên quan để cài đặt an toàn của TOE được kiểm tra trong các thủ tục chuẩn bị (AGD_PRE).

TCVN 8709-3 (ISO/IEC 15408-3) AGD_OPE.1.7C: Tài liệu hướng dẫn người dùng vận hành phải rõ ràng và hợp lý.

11.3.1.3.7  Đơn vị công việc AGD_OPE.1-7

Người đánh giá cần kiểm tra hướng dẫn người dùng vận hành để xác định rằng nó là rõ ràng.

Tài liệu hướng dẫn không rõ ràng nếu nó có thể tạo ra sự hiểu nhầm cho người quản trị hoặc người dùng và được sử dụng một cách bất lợi cho TOE hoặc đến an toàn cung cấp bi TOE.

11.3.1.3.8  Đơn vị công việc AGD_OPE.1-8

Người đánh giá cần kiểm tra hướng dẫn người dùng vận hành để xác định rằng nó là hợp lý.

Tài liệu hướng dẫn là không hợp lý nếu nó tạo ra nhu cầu sử dụng TOE hoặc môi trường vận hành không nhất quán với ST hoặc vượt quá mức lựa chọn hợp lý đ duy trì an toàn.

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

11.4.1  Đánh giá hoạt động con (AGD_PRE.1)

11.4.1.1  Mục tiêu

Mục tiêu của hoạt động con này là để xác định xem liệu các thủ tục và các bước chuẩn bị an toàn của TOE đã được tài liệu hóa và kết quả trong một cấu hình an toàn.

11.4.1.2  Đu vào

Bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) TOE bao gồm cả các thủ tục chuẩn bị của nó;

c) mô tả các thủ tục chuyển giao của nhà phát triển, nếu áp dụng.

11.4.1.3  Lưu ý áp dụng

Các thủ tục chuẩn bị đề cập đến tất cả các thủ tục chấp thuận và cài đặt cần thiết cho việc ci tiến TOE theo cấu hình an toàn được mô tả trong ST.

11.4.1.4  Hành động AGD_PRE.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) AGD_PRE.1.1C: Các thủ tục chuẩn bị cần mô tả tất cả các bước cần thiết để chấp thuận an toàn của TOE đã chuyển giao phù hợp với các thủ tục chuyển giao của nhà phát triển.

11.4.1.4.1  Đơn vị công việc AGD_PRE.1-1

Người đánh giá cần kiểm tra các thủ tục chấp thuận được cung cấp đ xác định rằng chúng mô tả các bước cần thiết về chấp thuận an toàn của TOE phù hợp với các thủ tục chuyển giao của nhà phát triển. Nếu không được dự đoán các thủ tục chuyển giao bởi nhà phát triển rằng các thủ tục chấp thuận sẽ hoặc có thể được áp dụng thì đơn vị công việc này là không áp dụng và do đó được xem là thỏa mãn. Các thủ tục chấp thuận nên bao gồm tối thiểu các công việc mà người dùng phải kiểm tra xem tất cả các phần của TOE được chỉ ra trong ST đã được chuyển giao đúng phiên bản.

Các thủ tục chấp thuận cần phản ánh các bước mà người dùng phải thực hiện để chấp nhận TOE được giao bao hàm bởi các thủ tục chuyển giao của nhà phát triển.

Các thủ tục chấp thuận cần cung cấp thông tin chi tiết về những điều sau, nếu đưc áp dụng:

a) đảm bảo rằng TOE được giao là một đánh giá đầy đủ;

b) phát hiện hiệu chỉnh/giả mạo của TOE được chuyển giao.

TCVN 8709-3 (ISO/IEC 15408-3) AGD_PRE.1.2C: Các thủ tục chuẩn bị cn 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 phù hợp với các mục tiêu an toàn cho môi trường vận hành đã mô tả trong ST.

11.4.1.4.2  Đơn vị công việc AGD_PRE.1-2

Người đánh giá cần kiểm tra các các thủ tục cài đặt được cung cấp để xác định rằng chúng mô tả các bước cần thiết để cài đặt an toàn của TOE và việc chuẩn bị an toàn của môi trường vận hành phù hợp với các mục tiêu an toàn trong ST.

Nếu không dự đoán được các thủ tục cài đặt sẽ hoặc có thể được áp dụng cho TOE và môi trường vận hành (ví dụ: Do TOE có thể đã được chuyển giao trong một trạng thái vận hành và không có các yêu cầu về môi trường) đơn vị công việc này không được áp dụng và do đó được xem là thỏa mãn.

Nếu không dự đoán được các thủ tục cài đặt s hoặc có thể được áp dụng (ví dụ: Do TOE có thể đã được chuyển giao ở trạng thái vận hành), đơn vị công việc này không được áp dụng và do đó được xem là thỏa mãn.

Các thủ tục cài đặt nên cung cấp thông tin chi tiết về những điều sau, nếu được áp dụng:

a) các yêu cầu hệ thống tối thiểu để cài đặt an toàn;

b) các yêu cầu về môi trường vận hành phù hợp với các mục tiêu an toàn được cung cấp bởi ST;

c) các bước người dùng phải thực hiện đ có được một TOE vận hành phù hợp với cấu hình đánh giá của nó. Một mô tả như vậy phải bao gồm - cho mỗi bước - một lược đồ rõ ràng cho các quyết định về các bước tiếp theo phụ thuộc vào sự thành công, thất bại hoặc các vấn đề ở bước hiện tại;

d) thay đổi các tính chất an toàn cụ thể của cài đặt của các thực thể dưới sự kiểm soát của TSF (ví dụ các thông số, thiết lập, mật khẩu);

e) xử lý các ngoại lệ và vấn đề.

11.4.1.5  Hành động AGD_PRE.1.2E

11.4.1.5.1  Đơn vị công việc AGD_PRE.1-3

Người đánh giá cần thực hiện tất cả các thủ tục người dùng cần thiết để chuẩn bị cho TOE nhằm xác định rằng TOE và môi trường vận hành của nó có thể được chuẩn bị một cách an toàn chỉ bằng cách sử dụng hướng dẫn người dùng chuẩn bị đã được cung cấp.

Việc chuẩn bị đòi hỏi người đánh giá cải tiến TOE từ trạng thái có thể chuyển giao sang trạng thái vận hành, bao gồm c sự chấp nhận và cài đặt TOE, và thực thi các SFR nhất quán với các mục tiêu an toàn cho TOE được quy định tại ST.

Người đánh giá ch nên làm theo các thủ tục của nhà phát triển và có thể thực hiện các hành động mà các khách hàng thường phải thực hiện để chấp nhận và cài đặt TOE, ch sử dụng tài liệu hướng dẫn chuẩn bị được cung cấp. Bất kỳ khó khăn gặp phải trong quá trình thực hiện có thể chỉ ra hướng dẫn sử dụng không đầy đủ, không rõ ràng hoặc không hợp lý.

Đơn vị làm việc này có thể được thực hiện kết hợp với các hoạt động đánh giá theo thử nghiệm độc lập (ATE_IND).

Nếu biết rằng TOE sẽ được sử dụng như một thành phần phụ thuộc cho một đánh giá TOE đề xuất thì người đánh giá cần đảm bảo rằng môi trường vận hành được thỏa mãn bởi các thành phần cơ sở được sử dụng trong TOE đề xuất.

12  Lớp ALC: Hỗ trợ vòng đời

12.1  Giới thiệu

Mục đích của hoạt động hỗ trợ vòng đời là để xác định sự phù hợp của các thủ tục an toàn mà nhà phát triển sử dụng trong quá trình phát triển và bảo trì của TOE. Các thủ tục này bao gồm các mô hình vòng đời được sử dụng bởi nhà phát triển, quản lý cấu hình, các biện pháp an toàn được sử dụng trong suốt quá trình phát triển TOE, các công cụ được sử dụng bởi nhà phát triển trong suốt vòng đời của TOE, các xử lý lỗ hổng an toàn và hoạt động chuyển giao.

Kiểm soát kém việc phát triển và bảo trì của TOE có thể dẫn đến các điểm yếu trong triển khai thực hiện. Sự phù hợp với một mô hình vòng đời được xác định có thể giúp để ci thiện kiểm soát trong lĩnh vực này. Một mô hình vòng đời có khả năng thành công được sử dụng cho TOE có thể mang đến sự tường minh trong việc đánh giá tiến độ phát triển của TOE.

Mục đích của hoạt động quản lý cu hình là để hỗ trợ khách hàng trong việc xác định TOE được đánh giá, để đảm bảo rằng khoản mục cấu hình được xác định duy nhất và đầy đủ các thủ tục được sử dụng bởi nhà phát triển để kiểm soát và theo dõi các thay đổi được thực hiện cho TOE. Điều này bao gồm chi tiết về những thay đổi được theo dõi, cách thức các thay đổi tiềm năng được áp dụng và mức độ tự động hóa được sử dụng để giảm phạm vi lỗi.

Các thủ tục an toàn phát triển dự định để bảo vệ TOE và các thông tin thiết kế liên quan của nó khỏi sự can thiệp hoặc tiết lộ. Can thiệp vào quá trình phát triển có thể cho phép tạo ra các điểm yếu có chủ định. Tiết lộ thông tin thiết kế có thể cho phép khai thác các điểm yếu dễ dàng hơn. Tính đầy đủ của các thủ tục sẽ phụ thuộc vào bản chất của TOE và sự phát triển quá trình.

Việc sử dụng các công cụ phát triển được xác định và áp dụng các tiêu chuẩn thực hiện bởi nhà phát triển và bởi các bên thứ ba tham gia vào quá trình phát triển giúp đảm bảo rằng các điểm yếu không phát sinh trong quá trình bổ sung chi tiết.

Hoạt động khắc phục thiếu sót được dự kiến để theo dõi các thiếu sót an toàn, để xác định các hành động khắc phục và phân phối các thông tin hành động khắc phục đến người dùng TOE.

Mục đích của hoạt động chuyển giao là để đánh giá mức độ đầy đủ về tài liệu của các thủ tục được sử dụng để đảm bảo rằng TOE được chuyển giao cho khách hàng mà không sửa đổi.

12.2  Năng lực CM (ALC_CMC)

12.2.1  Đánh giá hoạt động con (ALC_CMC.1)

12.2.1.1  Mục tiêu

Mục tiêu của hoạt động con này là để xác định xem liệu nhà phát triển đã định nghĩa rõ ràng TOE hay không.

12.2.1.2  Đầu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) TOE thích hợp để thử nghiệm.

12.2.1.3  Hành động ALC_CMC.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.1.1C: TOE cần được gán nhãn với tham chiếu duy nht của nó.

12.2.1.3.1  Đơn vị công việc ALC_CMC.1-1

Người đánh giá cần kiểm tra TOE được cung cấp để đánh giá phải được dán nhãn tham chiếu của nó.

Người đánh giá cần đảm bảo rằng TOE chứa các tham chiếu duy nhất được ghi trong ST. Điều này có thể đạt được thông qua dán nhãn bao bì hoặc phương tiện truyền thông hoặc bởi một nhãn hiển thị bởi hoạt động TOE. Điều này để đảm bảo rằng nó có thể giúp cho khách hàng xác định TOE (ví dụ tại điểm mua hàng hoặc sử dụng).

TOE có thể cung cấp một phương pháp mà theo đó nó có thể được nhận dạng dễ dàng. Ví dụ, một phần mềm có thể hiển thị tên và số phiên bản của TOE trong quá trình khởi động hoặc để đáp ứng với một dòng lệnh. Phần cứng và phần sụn TOE có thể được nhận dạng bởi một số hiệu vật lý trên TOE.

Ngoài ra, các tham chiếu duy nhất được cung cấp cho TOE có thể là sự kết hợp của các tham chiếu duy nhất của mỗi thành phần mà từ đó TOE được tạo nên (ví dụ như trong trường hợp của một TOE tổng hợp).

12.2.1.3.2  Đơn vị công việc ALC_CMC.1-2

Người đánh giá cần kiểm tra xem tài liệu tham chiếu TOE được sử dụng là nhất quán.

Nếu TOE được dán nhiều hơn một nhãn thì các nhãn này phải là nhất quán. Ví dụ, chúng ta có thể dán nhãn tài liệu hướng dẫn được cung cấp như là một phần của TOE đã được đánh giá. Điều này đảm bảo người tiêu dùng có thể tự tin rằng h đã mua phiên bản TOE đã được đánh giá và đã cài đặt phiên bản này và có phiên bản hướng dẫn chính xác để vận hành TOE phù hợp với ST.

Người đánh giá cũng xác nhận rằng tài liệu tham chiếu TOE nhất quán với ST.

Nếu đơn vị công việc này được áp dụng cho một TOE tổng hợp, các điều sau đây sẽ được áp dụng. Các TOE công nghệ thông tin kết hợp sẽ không được dán nhãn với tham chiếu duy nhất, mà chỉ các thành phần riêng sẽ được dán nhãn với tham chiếu TOE thích hợp. Cần có các phát triển tiếp theo cho TOE công nghệ thông tin được dán nhãn, ví dụ quá trình khởi động và/hoặc vận hành, với tham chiếu tổng hợp. Nếu TOE tổng hợp được chuyển giao như các TOE thành phần cấu thành, thì các khoản mục TOE chuyển giao sẽ không chứa các tham chiếu tổng hợp. Tuy nhiên, TOE ST kết hợp sẽ bao gồm các tham chiếu duy nht cho TOE tổng hợp và sẽ nhận dạng các thành phần bao gồm của TOE tổng hợp mà qua đó khách hàng sẽ có thể xác định xem chúng có các khoản mục phù hợp.

12.2.2  Đánh giá hoạt động con (ALC_CMC.2)

12.2.2.1  Mục tiêu

Mục tiêu của hoạt động con này là để xác định xem liệu nhà phát triển sử dụng một hệ thống CM duy nhất để nhận dạng tất cả các khoản mục cấu hình hay không.

12.2.2.2  Đu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) TOE phù hợp để thử nghiệm;

c) tài liệu qun lý cấu hình.

12.2.2.3  Lưu ý áp dụng

Thành phần này chứa một hành động đánh giá tiềm ẩn để xác định rằng hệ thống CM đang được sử dụng. Khi các yêu cầu ở đây được giới hạn để nhận dạng TOE và cung cấp một danh sách cấu hình, thì hành động này đã bao gồm bởi bởi giới hạn và đơn vị công việc hiện tại. Ở đánh giá hoạt động con (ALC_CMC.3) các yêu cầu được mở rộng vượt ra ngoài hai khon mục này và các bằng chứng rõ ràng hơn v hoạt động được yêu cầu.

12.2.2.4  Hành động ALC_CMC.2.1E

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.2.1C: TOE cần được dán nhãn với tham chiếu duy nhất của nó.

12.2.2.4.1  Đơn vị công việc ALC_CMC.2-1

Người đánh giá cần kiểm tra rằng TOE được cung cấp để đánh giá được dán nhãn với tham chiếu của nó.

Người đánh giá cần đảm bảo rằng TOE chứa các tham chiếu duy nhất được ghi trong ST. Điều này có thể đạt được thông qua dán nhãn bao bì hoặc phương tiện truyền thông hoặc bởi một nhãn hiển thị bởi TOE hoạt động. Điều này là để đảm bảo rằng nó có thể giúp cho khách hàng nhận dạng TOE (ví dụ tại điểm mua hàng hoặc sử dụng).

TOE có thể cung cấp một phương pháp mà theo đó nó có thể được nhận dạng dễ dàng. Ví dụ, một phần mềm có thể hiển thị tên và số phiên bản của TOE trong quá trình khởi động hoặc để đáp ứng với một dòng lệnh. Phần cứng và phần sụn TOE có thể được nhận dạng bởi một số hiệu vật lý trên TOE.

Ngoài ra, các tham chiếu duy nhất được cung cấp cho TOE có thể là sự kết hợp của các tham chiếu duy nhất của mi thành phần mà từ đó TOE được tạo nên (ví dụ như trong trường hợp của một TOE tổng hợp).

12.2.2.4.2  Đơn vị công việc ALC_CMC.2-2

Người đánh giá cần kim tra rằng tham chiếu TOE được sử dụng là nhất quán.

Nếu TOE được dán nhiều hơn một nhãn thì các nhãn này phải là nhất quán. Ví dụ, chúng ta có thể dán nhãn tài liệu hướng dẫn được cung cấp như là một phần của TOE đã được đánh giá. Điều này đảm bảo người tiêu dùng có thể tự tin rằng họ đã mua phiên bản TOE đã được đánh giá và đã cài đặt phiên bản này và có phiên bản hướng dẫn chính xác để vận hành TOE phù hợp với ST.

Người đánh giá cũng xác nhận rằng tham chiếu TOE nhất quán với ST.

Nếu đơn vị công việc này được áp dụng cho một TOE tổng hợp, các điều sau đây sẽ được áp dụng. Các TOE công nghệ thông tin kết hợp sẽ không được dán nhãn với tham chiếu duy nhất, mà chỉ các thành phần riêng sẽ được dán nhãn với tham chiếu TOE thích hợp. Cần có các phát triển tiếp theo cho TOE công nghệ thông tin được dán nhãn, ví dụ quá trình khởi động và/hoặc vận hành, với tham chiếu tổng hợp. Nếu TOE tổng hợp được chuyển giao như các TOE thành phần cấu thành, thì các khon mục TOE chuyển giao sẽ không chứa các tham chiếu tổng hợp. Tuy nhiên, TOE ST kết hợp sẽ bao gồm các tham chiếu duy nhất cho TOE tổng hợp và sẽ nhận dạng các thành phần bao gồm của TOE tổng hợp mà qua đó khách hàng sẽ có thể xác định xem chúng có các khoản mục phù hợp.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.2.2C: Tài liệu CM cần miêu tả phương pháp được sử dụng để nhận dạng duy nhất các khon mục cấu hình.

12.2.2.4.3  Đơn vị công việc ALC_CMC.2-3

Người đánh giá cần xem xét các phương pháp nhận dạng các khoản mục cấu hình để xác định rằng nó mô tả cách các khoản mục cấu hình là nhận dạng duy nhất.

Các thủ tục cần mô tả cách thức có thể theo dõi được tình trạng của từng khoản mục cấu hình trong suốt vòng đời của TOE. Các thủ tục có thể được trình bày chi tiết trong kế hoạch CM hoặc trong các tài liệu CM. Các thông tin cần mô tả bao gồm:

a) phương pháp để từng khoản mục cu hình được nhận dạng duy nhất, để có thể theo dõi các phiên bản của cùng một khon mục cấu hình;

b) phương pháp để từng khoản mục cấu hình được gán nhận dạng duy nhất và cách thức cập nhập chúng vào hệ thống CM;

c) phương pháp được sử dụng để nhận dạng phiên bản thay thế của một khoản mục cấu hình.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.2.3C: Hệ thống CM cần nhận dạng một cách duy nhất tất cả các khoản mục cấu hình.

12.2.2.4.4  Đơn vị công việc ALC_CMC.2-4

Người đánh giá cần kiểm tra các khoản mục cấu hình đ xác định rằng chúng được nhận dạng theo cách nhất quán với tài liệu CM.

Đảm bảo rằng hệ thống CM nhận dạng một cách duy nhất tất cả các khoản mục cấu hình đã đạt được bằng cách kiểm tra bộ nhận dạng cho các khoản mục cấu hình. Đối với cả hai khoản mục cấu hình bao gồm TOE và dự kiến các khoản mục cấu hình được đề xuất bởi nhà phát triển là bằng chứng đánh giá, Người đánh giá xác nhận rằng mỗi khoản mục cấu hình có một số hiệu nhận dạng duy nhất theo cách nhất quán với phương pháp nhận dạng duy nhất được mô tả trong tài liệu CM.

12.2.3  Đánh giá hoạt động con (ALC_CMC.3)

12.2.3.1  Mục tiêu

Mục tiêu của hoạt động con này là để xác định xem liệu nhà phát triển sử dụng một hệ thống CM để nhận dạng duy nhất tất cả các khoản mục cấu hình và có khả năng để sửa đổi các khoản mục này được kiểm soát hợp lý hay không.

12.2.3.2  Đu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) TOE phù hợp để thử nghiệm;

c) tài liệu quản lý cấu hình.

12.2.3.3  Hành động ALC_CMC.3.1E

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.3.1C: TOE cần được dán nhãn với tham chiếu duy nhất của nó.

12.2.3.3.1  Đơn v công việc ALC_CMC.3-1

Người đánh giá cần kiểm tra rằng TOE được cung cấp để đánh giá được dán nhãn với tham chiếu của nó.

Người đánh giá cần đảm bảo rằng TOE chứa các tham chiếu duy nhất được ghi trong ST. Điều này có thể đạt được thông qua dán nhãn bao bì hoặc phương tiện truyền thông hoặc bởi một nhãn hiển thị bởi TOE hoạt động. Điều này là để đảm bảo rằng nó có thể giúp cho khách hàng nhận dạng TOE (ví dụ tại điểm mua hàng hoặc sử dụng).

TOE có thể cung cấp một phương pháp mà theo đó nó có thể được nhận dạng dễ dàng. Ví dụ, một phn mềm có thể hin thị tên và số phiên bản của TOE trong quá trình khởi động hoặc để đáp ứng với một dòng lệnh. Phần cứng và phần sụn TOE có thể được nhận dạng bởi một số hiệu vật lý trên TOE.

Ngoài ra, các tham chiếu duy nhất được cung cấp cho TOE có thể là sự kết hợp của các tham chiếu duy nhất của mỗi thành phần mà từ đó TOE được tạo nên (ví dụ như trong trường hợp của một TOE tổng hợp).

12.2.3.3.2  Đơn vị công việc ALC_CMC.3-2

Người đánh giá cần kiểm tra rằng tham chiếu TOE được sử dụng là nhất quán.

Nếu TOE được dán nhiều hơn một nhãn thì các nhãn này phải là nhất quán. Ví dụ, chúng ta có thể dán nhãn tài liệu hướng dẫn được cung cấp như là một phần của TOE đã được đánh giá. Điều này đảm bảo người tiêu dùng có thể tự tin rằng h đã mua phiên bản TOE đã được đánh giá và đã cài đặt phiên bản này và có phiên bản hướng dẫn chính xác để vận hành TOE phù hợp với ST.

Người đánh giá cũng xác nhận rằng tham chiếu TOE nhất quán với ST.

Nếu đơn vị công việc này được áp dụng cho một TOE tổng hợp, các điều sau đây sẽ được áp dụng. Các TOE công nghệ thông tin kết hợp sẽ không được dán nhãn với tham chiếu duy nhất, mà chỉ các thành phần riêng sẽ được dán nhãn với tham chiếu TOE thích hợp. Cần có các phát triển tiếp theo cho TOE công nghệ thông tin được dán nhãn, ví dụ quá trình khi động và/hoặc vận hành, với tham chiếu tổng hợp. Nếu TOE tổng hợp được chuyển giao như các TOE thành phần cấu thành, thì các khoản mục TOE chuyển giao sẽ không chứa các tham chiếu tổng hợp. Tuy nhiên, TOE ST kết hợp sẽ bao gồm các tham chiếu duy nhất cho TOE tổng hợp và sẽ nhận dạng các thành phần bao gồm của TOE tổng hợp mà qua đó khách hàng sẽ có thể xác định xem chúng có các khoản mục phù hợp.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.2.2C: Tài liệu CM cần mô tả phương pháp được sử dụng đ nhận dạng các khoản mục cấu hình một cách duy nhất.

12.2.3.3.3  Đơn vị công việc ALC_CMC.3-3

Người đánh giá cần xem xét các phương pháp nhận dạng các khoản mục cấu hình để xác định rằng nó mô tả cách các khoản mục cấu hình là nhận dạng duy nhất.

Các thủ tục cần mô tả cách thức có thể theo dõi được tình trạng của từng khoản mục cấu hình trong suốt vòng đời của TOE. Các thủ tục có thể được trình bày chi tiết trong kế hoạch CM hoặc trong các tài liệu CM. Các thông tin cần mô tả bao gồm:

a) phương pháp để từng khoản mục cấu hình được nhận dạng duy nhất, để có thể theo dõi các phiên bản của cùng một khoản mục cấu hình;

b) phương pháp để từng khoản mục cấu hình được gán nhận bộ dạng duy nhất và cách thức cập nhập chúng vào hệ thống CM;

c) phương pháp được sử dụng để nhận dạng phiên bản thay thế của một khoản mục cấu hình.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.3.3C: Hệ thống CM cần nhận dạng tất cả các khoản mục cấu hình một cách duy nhất.

12.2.3.3.4  Đơn vị công việc ALC_CMC.3-4

Người đánh giá cần kiểm tra các khoản mục cấu hình để xác định rằng chúng được nhận dạng theo cách nhất quán với tài liệu CM.

Đảm bảo rằng hệ thống CM nhận dạng một cách duy nhất tất cả các khoản mục cấu hình đã đạt được bằng cách kiểm tra bộ nhận dạng cho các khoản mục cấu hình. Đối với cả hai khoản mục cấu hình bao gồm TOE và dự kiến các khoản mục cấu hình được đề xuất bởi nhà phát triển là bằng chứng đánh giá, Người đánh giá xác nhận rằng mỗi khoản mục cấu hình có một số hiệu nhận dạng duy nhất theo cách nhất quán với phương pháp nhận dạng duy nhất được mô tả trong tài liệu CM.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.3.4C: Hệ thống CM cần cung cấp các biện pháp như các thay đổi được cấp quyền được thực thi cho các khoản mục cấu hình.

12.2.3.3.5  Đơn vị công việc ALC_CMC.3-5

Người đánh giá cần kiểm tra các biện pháp kiểm soát truy nhập CM được mô tả trong các kế hoạch CM để xác định đúng là có hiệu quả trong việc ngăn ngừa truy nhập trái phép vào các khon mục cấu hình.

Người đánh giá có thể sử dụng một số phương pháp để xác định rằng các biện pháp kiểm soát truy nhập CM là có hiệu quả. Ví dụ, người đánh giá có thể thực hiện các biện pháp kiểm soát truy nhập để đảm bảo rằng các thủ tục không thể được bỏ qua. Người đánh giá có thể sử dụng các kết quả đầu ra được tạo ra bởi các thủ tục hệ thống CM được yêu cầu bởi ALC_CMC.3.8C. Người đánh giá cũng có thể chứng kiến thực thi mô phỏng của hệ thống CM để đảm bảo rằng các biện pháp kiểm soát truy nhập được sử dụng đang hoạt động có hiệu quả.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.3.5C: Tài liệu CM cần bao gồm một kế hoạch CM.

12.2.3.3.6  Đơn vị công việc ALC_CMC.3-6

Người đánh giá cần kiểm tra rằng tài liệu CM được cung cấp bao gm một kế hoạch CM.

Kế hoạch CM không phải là một tài liệu kết nối, nhưng nó được khuyến cáo là một tài liệu duy nhất mô tả nơi mà các phần khác nhau của kế hoạch CM có thể được tìm thấy. Nếu kế hoạch CM không phải tài liệu duy nhất, danh sách các đơn vị công việc sau đây đưa ra gợi ý về bối cảnh dự kiến.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.3.6C: Kế hoạch CM cần mô tả cách hệ thống CM được sử dụng để phát triển TOE.

12.2.3.3.7  Đơn vị công việc ALC_CMC.3-7

Người đánh giá cần xem xét kế hoạch CM để xác định rằng nó mô tả cách thức hệ thống CM được sử dụng để phát triển TOE.

Các mô tả có trong một kế hoạch CM bao gồm, nếu áp dụng:

a) tất cả các hoạt động thực hiện trong sự phát triển TOE là đối tượng của các thủ tục quản lý cấu hình (Ví dụ: tạo, chỉnh sửa hoặc xóa một khoản mục cấu hình, dữ liệu sao lưu, lưu trữ);

b) các phương tiện (ví dụ: công cụ CM, mẫu) có sẵn;

c) cách sử dụng các công cụ CM: các chi tiết cần thiết cho một người sử dụng hệ thống CM để có vận hành các công cụ CM một cách chính xác nhằm duy trì tính toàn vẹn của TOE;

d) các đối tượng khác (các thành phần phát triển, các công cụ, môi trường đánh giá, vv) được thực hiện dưới kiểm soát CM;

e) các vai trò và trách nhiệm của các cá nhân cần thiết để thực hiện vận hành các hạng mục cấu hình riêng (các vai trò khác nhau có thể được nhận dạng cho các loại khoản mục cấu hình khác nhau (ví dụ như thiết kế tài liệu hoặc mã nguồn));

f) các trường hợp CM (ví dụ như bảng kiểm soát thay đổi, giao diện kiểm soát làm việc nhóm) được cung cấp và nhân viên thực hiện;

g) mô tả về quản lý sự thay đổi;

h) các thủ tục được sử dụng để đảm bảo rằng chỉ có những người được cấp quyền có thể thực hiện thay đổi các khoản mục cấu hình;

i) các thủ tục được sử dụng để đảm bảo rằng các vấn đề không xảy ra đồng thời như là kết quả của việc thay đổi đồng thời các khoản mục cấu hình;

j) bằng chứng được tạo ra như là kết quả của việc áp dụng các thủ tục. Ví dụ, đối với một sự thay đổi một khon mục cấu hình, hệ thống CM phải ghi lại mô tả về các thay đổi, giải trình về các thay đổi, nhận dạng tất cả các khoản mục cấu hình bị ảnh hưởng và trạng thái của nó (ví dụ như treo hoặc hoàn thành) và ngày giờ của sự thay đổi. Điều này có thể được ghi lại trong tệp tin log (log file) của những thay đổi được thực hiện hoặc h sơ kiểm soát thay đổi;

k) phương pháp để kiểm soát phiên bản và tham chiếu duy nhất của phiên bản TOE (ví dụ bao gồm việc phát hành bn vá lỗi trong hệ điều hành và phát hiện tiếp theo của ứng dụng của họ).

Các phương pháp tiếp cận để kiểm soát phiên bản và tham khảo duy nhất của phiên bản TOE (ví dụ bao gồm việc phát hành các bn vá lỗi trong hệ điều hành và tiếp tục theo dõi, phát hiện lỗi của ứng dụng).

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.3.7C: Bằng chứng cần chứng minh rằng tất cả các khoản mục cấu hình đang được duy trì bởi hệ thống CM.

12.2.3.3.8  Đơn vị công việc ALC_CMC.3-8

Người đánh giá cần kiểm tra các khoản mục cấu hình được nhận dạng trong danh sách cấu hình đang được duy trì bởi hệ thống CM.

Hệ thống CM được dùng bởi nhà phát triển cần phải duy trì tính toàn vẹn của TOE. Người đánh giá cần kiểm tra cho mỗi loại khoản mục cấu hình (ví dụ như tài liệu thiết kế hoặc các mô đun mã nguồn) có trong danh sách cấu hình có những ví dụ về các bằng chứng được tạo ra bởi các thủ tục được mô tả trong kế hoạch CM. Trong trường hợp này, phương pháp lấy mẫu sẽ phụ thuộc vào mức độ chi tiết được sử dụng trong các hệ thống CM để kiểm soát các khoản mục CM. Trong trường hợp, ví dụ, mô đun mã nguồn 10.000 được nhận dạng trong danh sách cấu hình, phương pháp lấy mẫu khác nhau cần phải được áp dụng so với các trường hợp mà trong đó chỉ có 5 hoặc thậm chí là 1. Tầm quan trọng của hoạt động này cần đảm bảo rằng hệ thống CM đang được vận hành một cách chính xác, chứ không phải để phát hiện bất kỳ lỗi nào.

Xem hướng dẫn v lấy mẫu tại A.2, lấy mẫu.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.3.8C: Bằng chứng phải chứng minh rằng hệ thống CM đang vận hành phù hợp với kế hoạch CM.

12.2.3.3.9  Đơn vị công việc ALC_CMC.3-9

Người đánh giá cần kiểm tra tài liệu CM để chắc chắn rằng nó bao gồm các hồ sơ hệ thống CM được nhận dạng bi kế hoạch CM.

Đầu ra của hệ thống CM cần cung cấp bằng chứng giúp người đánh giá chắc chắn rằng kế hoạch CM đang được áp dụng và tất cả các khoản mục cấu hình cũng đang được duy trì bởi hệ thống CM theo yêu cầu của ALC_CMC.3.7C. Ví dụ kết quả đầu ra có thể bao gồm các hình thức kiểm soát thay đổi hoặc các hình thức chấp thuận truy nhập khoản mục cấu hình.

12.2.3.3.10  Đơn v công việc ALC_CMC.3-10

Người đánh giá cần kiểm tra các bằng chứng để xác định rằng hệ thống CM đang được vận hành phù hợp với kế hoạch CM.

Người đánh giá cần lựa chọn và kiểm tra một mẫu bằng chứng bao gồm từng loại các hoạt động CM-có liên quan đã được thực hiện trên một khoản mục cấu hình (ví dụ như tạo, chỉnh sửa, xóa, chuyển về phiên bản trước) để xác nhận rằng tất cả các hoạt động của hệ thống CM đã được thực hiện phù hợp với thủ tục đã được chứng minh. Người đánh giá xác nhận rng các bằng chứng bao gồm tất cả các thông tin được nhận dạng là hoạt động trong kế hoạch CM. Kiểm tra các bằng chứng có thể yêu cầu truy nhập đến một công cụ CM được sử dụng. Người đánh giá có thể chọn để lấy mẫu bằng chứng. Xem hướng dẫn về ly mẫu tại A.2, Lấy mẫu.

Để tăng sự tin cậy trong hoạt động chính xác hơn của hệ thống CM và bảo trì có hiệu quả các hạng mục cấu hình có thể được thiết lập bằng cách phỏng vấn với các nhân viên phát triển được lựa chọn. Khi tiến hành phỏng vấn, người đánh giá với mục đích đạt được sự hiểu biết sâu sắc hơn về cách các hệ thống CM được sử dụng trong thực tế cũng như để xác nhận rằng các thủ tục CM đang được áp dụng như mô tả trong tài liệu CM. Lưu ý rằng phỏng vấn như vậy chỉ là bổ sung chứ không thay thế việc kiểm tra các bằng chứng tài liệu và có thể là không cần thiết nếu các bằng chứng tài liệu đáp ứng các yêu cầu. Tuy nhiên, với phạm vi rộng của kế hoạch CM nó có thể có một số khía cạnh (ví dụ như các vai trò và trách nhiệm) có thể không rõ ràng từ kế hoạch CM và hồ sơ. Đây là một trong những trường hợp cần làm rõ có thể cần thiết thông qua các cuộc phỏng vấn.

Người đánh giá cần tham khảo các trang web phát triển để hỗ trợ các hoạt động này.

Để biết thông tin về các trang web tham kho xem A.4, Các trang web tham khảo.

12.2.4  Đánh giá hoạt động con (ALC_CMC.4)

12.2.4.1  Mục tiêu

Mục tiêu hoạt động con này là để xác định xem liệu nhà phát triển đã nhận dạng rõ ràng TOE và các khon mục cấu hình liên quan và có khả năng để sửa đổi các hạng mc này được kiểm soát hợp lý bởi các công cụ tự động hay không, để cho hệ thống CM ít phụ thuộc hơn vào lỗi ch quan của con người.

12.2.4.2  Đầu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) TOE phù hợp để thử nghiệm;

c) tài liệu quản lý cấu hình.

12.2.4.3  Hành động ALC_CMC.4.1E

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.4.1C: TOE cần được dán nhãn với tham chiếu duy nhất của nó.

12.2.4.3.1  Đơn vị công việc ALC_CMC.4-1

Người đánh giá cần kiểm tra rằng TOE được cung cấp để đánh giá đã được dán nhãn với tham chiếu của nó.

Người đánh giá cần đảm bảo rằng TOE chứa các tham chiếu duy nhất được ghi trong ST. Điều này có thể đạt được thông qua dán nhãn bao bì hoặc phương tiện truyền thông hoặc bởi một nhãn hiển thị bởi TOE hoạt động. Điều này là để đảm bảo rằng nó có thể giúp cho khách hàng nhận dạng TOE (ví dụ tại điểm mua hàng hoặc sử dụng).

TOE có thể cung cấp một phương pháp mà theo đó nó có thể được nhận dạng dễ dàng. Ví dụ, một phần mềm có thể hin th tên và số phiên bản của TOE trong quá trình khởi động hoặc để đáp ứng với một dòng lệnh. Phần cứng và phần sụn TOE có thể được nhận dạng bởi một số hiệu vật lý trên TOE. Ngoài ra, các tham chiếu duy nhất được cung cấp cho TOE có thể là sự kết hợp của các tham chiếu duy nhất của mỗi thành phần mà từ tạo ra một TOE tổng hợp (ví dụ như trong trường hợp của một TOE tổng hợp).

12.2.4.3.2  Đơn vị công việc ALC_CMC.4-2

Người đánh giá cần kiểm tra rằng tham chiếu TOE được sử dụng là nhất quán.

Nếu TOE được dán nhiều hơn một nhãn thì các nhãn này phải là nhất quán. Ví dụ, chúng ta có thể dán nhãn tài liệu hướng dẫn được cung cấp như là một phần của TOE đã được đánh giá. Điều này đảm bảo người tiêu dùng có thể tự tin rằng họ đã mua phiên bản TOE đã được đánh giá và đã cài đặt phiên bản này và có phiên bản hướng dẫn chính xác để vận hành TOE phù hợp với ST.

Người đánh giá cũng xác nhận rằng tham chiếu TOE nhất quán với ST.

Nếu đơn vị công việc này được áp dụng cho một TOE tổng hợp, các điều sau đây sẽ được áp dụng. Các TOE công nghệ thông tin kết hợp sẽ không được dán nhãn với tham chiếu duy nhất (kết hợp), mà chỉ các thành phần riêng sẽ được dán nhãn với tham chiếu TOE thích hợp của chúng, cần có các phát triển tiếp theo cho TOE công nghệ thông tin được dán nhãn, ví dụ quá trình khởi động và/hoặc vận hành với tham chiếu kết hợp. Nếu TOE tổng hợp được chuyển giao như các TOE thành phần cấu thành, thì các khoản mục TOE được chuyển giao sẽ không chứa các tham chiếu kết hợp. Tuy nhiên, TOE ST kết hợp sẽ bao gồm tham chiếu duy nhất cho TOE tổng hợp và sẽ nhận dạng các thành phần cấu thành TOE tổng hợp mà qua đó khách hàng sẽ có thể xác định xem chúng có các khoản mục phù hợp.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.4.2C: Tài liệu CM cần mô tả phương pháp được sử dụng đ nhận dạng các khoản mục cấu hình một cách duy nhất.

12.2.4.3.3  Đơn vị công việc ALC_CMC.4-3

Người đánh giá cần xem xét các phương pháp nhận dạng các khoản mục cấu hình để xác định rằng nó mô tả cách các khoản mục cấu hình là nhận dạng duy nht.

Các thủ tục cần mô tả cách thức có thể theo dõi được các trạng thái của tng khoản mục cấu hình trong suốt vòng đời của TOE. Các thủ tục có thể được trình bày chi tiết trong kế hoạch CM hoặc trong các tài liệu CM. Các thông tin cần mô tả bao gồm:

a) phương pháp đ từng khon mục cấu hình được nhận dạng duy nhất, để có thể theo dõi các phiên bản của cùng một khoản mục cấu hình;

b) phương pháp để các khoản mục cấu hình được gán cho các bộ nhận dạng duy nhất và cách thức cập nhập chúng vào hệ thống CM;

c) phương pháp được sử dụng để nhận dạng phiên bản thay thế của một khoản mục cấu hình.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.4.3C: Hệ thống CM cần nhận dạng tất cả các khoản mục cấu hình một cách duy nhất.

12.2.4.3.4  Đơn vị công việc ALC_CMC.4-4

Người đánh giá cần kiểm tra các khoản mục cấu hình để xác định rằng chúng được nhận dạng theo cách nhất quán với tài liệu CM.

Đảm bảo rằng hệ thống CM nhận dạng một cách duy nhất tất cả các khoản mục cấu hình đã đạt được bằng cách kiểm tra bộ nhận dạng cho các khoản mục cấu hình. Đối với c hai khoản mục cấu hình bao gồm TOE và dự kiến các khoản mục cấu hình được đề xuất bởi nhà phát triển là bằng chứng đánh giá, người đánh giá xác nhận rằng mỗi khoản mục cấu hình có một số hiệu nhận dạng duy nhất theo cách nhất quán với phương pháp nhận dạng duy nhất được mô tả trong tài liệu CM.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.4.4C: Hệ thống CM cần cung cấp các biện pháp tự động như các thay đổi được cấp quyền được thực thi cho các khoản mục cấu hình.

12.2.4.3.5  Đơn vị công việc ALC_CMC.4-5

Người đánh giá cần kiểm tra các biện pháp kiểm soát truy nhập CM được mô tả trong các kế hoạch CM (cf. ALC_CMC.4.6C) để xác định rằng chúng là tự động và có hiệu quả trong việc ngăn ngừa truy nhập trái phép vào các khoản mục cấu hình.

Người đánh giá có thể sử dụng một số phương pháp để xác định rằng các biện pháp kiểm soát truy nhập CM là có hiệu quả. Ví dụ, người đánh giá có thể thực hiện các biện pháp kim soát truy nhập để đảm bảo rằng các thủ tục không thể được b qua. Người đánh giá có thể sử dụng các kết quả đầu ra được tạo ra bởi các thủ tục hệ thống CM được yêu cầu bi ALC_CMC.4.10C. Người đánh giá cũng có thể chứng kiến thực thi mô phng của hệ thống CM đ đảm bảo rằng các biện pháp kiểm soát truy nhập được sử dụng đang hoạt động có hiệu quả.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.4.5C: Hệ thống CM cần hỗ trợ việc sản xut của TOE bằng các phương tiện tự động.

12.2.4.3.6  Đơn vị công việc ALC_CMC.4-6

Người đánh giá cn kiểm tra các kế hoạch CM (cf. ALC_CMC.4.6C) cho các thủ tục tự động để hỗ trợ việc sản xuất của TOE.

Thuật ngữ "sn xuất" được áp dụng cho các quá trình được thông qua bởi nhà phát triển để cải tiến TOE từ triển khai thực hiện tới một trạng thái có thể chấp nhận để chuyển giao cho khách hàng. Người đánh giá xác minh sự tồn tại của thủ tục hỗ trợ sản xuất tự động hóa trong kế hoạch CM.

Sau đây là những ví dụ về các phương tiện tự động hỗ trợ sản xuất của TOE:

- công cụ "tạo" (cung cấp với nhiều công cụ phát triển phần mềm) trong trường hợp của một TOE phần mềm;

- công cụ đảm bảo tự động (ví dụ là các phương tiện mã vạch) mà chỉ có các bộ phận được kết hợp với nhau trong trường hợp là một TOE phần cứng.

12.2.4.3.7  Đơn vị công việc ALC_CMC.4-7

Người đánh giá cn kiểm tra các thủ tục hỗ trợ sản xuất TOE để xác định rằng chúng là có hiệu quả trong đảm bảo rằng một TOE được tạo ra phản ánh việc triển khai thực hiện nó.

Các thủ tục hỗ trợ sản xuất cần mô tả các công cụ đã được sử dụng để sản xuất TOE hoàn chỉnh từ việc triển khai thực hiện một cách rõ ràng. Các quy ưc, ch th hoặc cấu trúc cần thiết khác được mô tả trong ALC_TAT.

Người đánh giá xác định rằng bằng cách làm theo các thủ tục hỗ trợ sản xuất các khoản mục cấu hình chính xác sẽ được sử dụng để tạo ra TOE. Ví dụ, trong một TOE phần mềm này có thể bao gồm việc kiểm tra các thủ tục sản xuất tự động đảm bảo rằng tt c các tập tin nguồn và các thư viện liên quan đã có trong mã đối tượng biên dịch. Hơn nữa, các thủ tục cần đảm bảo rằng tùy chọn biên dịch và so sánh các lựa chọn khác được xác định duy nhất. Đối với một TOE phần cứng, đơn v công việc này có thể bao gồm việc kiểm tra các thủ tục sản xuất tự động đảm bảo rằng các bộ phận được ghép lại với nhau và không có bộ phận bị thiếu.

Khi đó khách hàng có thể chắc chắn rằng các phiên bản của TOE được chuyển giao để cài đặt có nguồn gốc từ quá trình triển khai thực hiện một cách tường minh và thực hiện các SFR như được mô tả trong ST.

Người đánh giá cần lưu ý rằng hệ thống CM không nhất thiết phải có khả năng sản xuất TOE, nhưng nên cung cấp hỗ trợ cho quá trình đó sẽ giúp làm giảm xác suất xảy ra lỗi của con người.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.4.6C: Tài liệu CM cần bao gồm một kế hoạch CM.

12.2.4.3.8  Đơn vị công việc ALC_CMC.4-8

Người đánh giá cần kiểm tra rằng tài liệu CM được cung cấp bao gồm một kế hoạch CM.

Kế hoạch CM không cần chứa trong một tài liệu duy nhất, nhưng nó được khuyến cáo rằng cần có một h sơ riêng biệt mô tả nơi mà các phần khác nhau của kế hoạch CM có thể được tìm thấy. Nếu kế hoạch CM được cung cấp bởi một tập các tài liệu, danh sách trong đơn vị công việc sau đây cung cấp hướng dẫn về nội dung yêu cầu.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.4.7C: Kế hoạch CM cần mô tả cách thức hệ thống CM được sử dụng để phát trin TOE.

12.2.4.3.9  Đơn vị công việc ALC_CMC.4-9

Người đánh giá cần kiểm tra kế hoạch CM để xác định rằng nó mô tả cách thức hệ thống CM được sử dụng để phát triển TOE.

Các mô tả có trong một kế hoạch CM bao gồm, nếu áp dụng:

a) tất c các hoạt động thực hiện trong việc phát triển TOE là đối tượng của các thủ tục quản lý cấu hình (ví dụ: tạo, chỉnh sửa hoặc xóa một khoản mục cấu hình, dữ liệu sao lưu, lưu trữ);

b) các phương tiện (ví dụ: công cụ CM, mẫu) có sẵn;

c) cách sử dụng các công cụ CM: các chi tiết cn thiết cho một người sử dụng hệ thống CM để có vận hành các công cụ CM một cách chính xác nhằm duy trì tính toàn vẹn của TOE;

d) các thủ tục hỗ trợ sản xuất;

e) các đối tượng khác (các thành phần phát triển, các công cụ, môi trường đánh giá, vv) được thực hiện dưới kiểm soát CM;

f) các vai trò và trách nhiệm của các cá nhân cần thiết để thực hiện vận hành các hạng mục cấu hình riêng (Các vai trò khác nhau có thể được nhận dạng cho các loại khoản mục cấu hình khác nhau (ví dụ như thiết kế tài liệu hoặc mã nguồn));

g) các trường hợp CM (ví dụ như bảng kiểm soát thay đổi, giao diện kiểm soát làm việc nhóm) được cung cấp và nhân viên thực hiện;

h) mô tả về quản lý thay đổi;

i) các thủ tục được sử dụng để đảm bảo rằng chỉ có những người được cấp quyền có thể thực hiện thay đổi các khoản mục cấu hình;

j) các thủ tục được sử dụng để đảm bảo rằng các vấn đề không xảy ra đng thời như là kết quả của việc thay đổi đồng thời các khoản mục cấu hình;

k) bằng chứng được tạo ra như là kết quả của việc áp dụng các thủ tục. Ví dụ, đối với một sự thay đổi một khoản mục cấu hình, hệ thống CM phải ghi lại mô tả về các thay đổi, giải trình về các thay đổi, nhận dạng tất cả các khoản mục cấu hình bị ảnh hưởng và trạng thái của nó (ví dụ như treo hoặc hoàn thành) và ngày giờ của sự thay đổi. Điều này có thể được ghi lại trong tệp tin log (log file) của những thay đổi được thực hiện hoặc hồ sơ kiểm soát thay đổi;

l) phương pháp để kiểm soát phiên bản và tham chiếu duy nhất của các phiên bản TOE (ví dụ bao gồm việc phát hành bản vá lỗi trong hệ điều hành và phát hiện tiếp theo của ứng dụng).

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.4.8C: Kế hoạch CM cần mô tả các thủ tục sử dụng đ chấp nhận sửa đổi hoặc tạo ra một khoản mục cấu hình mới như một phần của TOE.

12.2.4.3.10  Đơn vị công việc ALC_CMC.4-10

Người đánh giá cần kiểm tra kế hoạch CM để xác định rằng nó mô tả các thủ tục sử dụng đ chấp nhận sửa đổi hoặc tạo ra một khoản mục cấu hình mới như các bộ phận của TOE.

Việc mô tả của các thủ tục chp thuận trong kế hoạch CM nên bao gm các vai trò nhà phát triển hoặc cá nhân chịu trách nhiệm cho việc chấp nhận và các tiêu chí đ được sử dụng chp nhận. Nên đưa vào tài khoản tất cả tình huống chấp nhận có thể xảy ra, cụ thể:

a) chấp nhận một khoản mục vào hệ thống CM cho lần đầu tiên, đặc biệt là các thành phần phần mềm, phần sụn và phần cứng từ các nhà sản xuất khác vào TOE ("Tích hợp");

b) chuyển các khon mục cấu hình vào giai đoạn vòng đời tiếp theo tại từng giai đoạn của việc xây dựng TOE (ví dụ như mô đun, phân hệ, hệ thống);

c) tiếp theo để vận chuyển giữa các điểm phát triển khác nhau.

Nếu đơn vị làm việc này được áp dụng cho một thành phần phụ thuộc có nghĩa là sẽ được tích hợp trong một TOE tổng hợp, kế hoạch CM nên xem xét việc kiểm soát các thành phần cơ sở thu được bởi nhà phát triển TOE phụ thuộc.

Khi có được các thành phần, người đánh giá sẽ xác minh những điều sau:

a) chuyển từng thành phần cơ sở từ nhà phát triển thành phần cơ sở tới nhà tích hợp (nhà phát triển TOE phụ thuộc) được thực hiện phù hợp với các thủ tục chuyển giao an toàn của TOE thành phần cơ sở, như đưc thông báo trong báo cáo xác nhận thành phn cơ sở của TOE.

b) các thành phần nhận được có cùng số hiệu nhận dạng như đã nêu trong ST và báo cáo chứng nhận cho các thành phần TOE.

c) tất cả các vật liệu bổ sung theo yêu cầu của nhà phát triển để tích hợp được cung cấp. Điều này bao gồm các chiết xuất cần thiết của đặc tả chức năng các thành phần của TOE.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.4.9C: Bằng chứng cần chứng minh rằng tất cả các khoản mục cấu hình đang được duy trì bởi hệ thống CM.

12.2.4.3.11  Đơn vị công việc ALC_CMC.4-11

Người đánh giá cần kiểm tra các khoản mục cấu hình được nhận dạng trong danh sách cấu hình đang được duy trì bởi hệ thống CM.

Hệ thống CM được dùng bởi nhà phát triển cần phải duy trì tính toàn vẹn của TOE. Người đánh giá cần kim tra cho mỗi loại khoản mục cấu hình (ví dụ như tài liệu thiết kế hoặc các mô đun mã nguồn) có trong danh sách cấu hình có những ví dụ về các bằng chứng được tạo ra bởi các thủ tục được mô tả trong kế hoạch CM. Trong trường hợp này, phương pháp lấy mẫu sẽ phụ thuộc vào mức độ chi tiết được sử dụng trong các hệ thống CM để kiểm soát các khoản mục CM. Trong trường hợp, ví dụ, mô đun mã nguồn 10.000 được nhận dạng trong danh sách cấu hình, phương pháp lấy mẫu khác nhau cần phi được áp dụng so với các trường hợp mà trong đó ch có 5 hoặc thậm chí là 1. Tầm quan trọng của hoạt động này cần đảm bảo rằng hệ thống CM đang được vận hành một cách chính xác, chứ không phải để phát hiện bất kỳ lỗi nào.

Xem hướng dẫn về lấy mẫu tại A.2, Lấy mẫu.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.4.10C: Bằng chứng phải chứng minh rằng hệ thống CM đang vận hành phù hợp với kế hoạch CM.

12.2.4.3.12  Đơn vị công việc ALC_CMC.4-12

Người đánh giá cần kiểm tra tài liệu CM để chắc chn rằng nó bao gồm các hồ sơ hệ thống CM được nhận dạng bởi kế hoạch CM.

Đầu ra của hệ thống CM cần cung cấp bằng chứng giúp người đánh giá chắc chắn rằng kế hoạch CM đang được áp dụng và tất cả các khoản mục cấu hình cũng đang được duy trì bởi hệ thống CM theo yêu cầu của ALC_CMC.4.9C. Ví dụ kết quả đầu ra có thể bao gồm các hình thức kiểm soát thay đổi hoặc các hình thức chấp thuận truy nhập khoản mục cấu hình.

12.2.4.3.13  Đơn vị công việc ALC_CMC.4-13

Người đánh giá cần kiểm tra các bằng chứng để xác định rằng hệ thống CM đang được vận hành phù hợp với kế hoạch CM.

Người đánh giá cần lựa chọn và kiểm tra một mẫu bằng chứng bao gồm từng loại hoạt động CM có liên quan đã được thực hiện trên một khoản mục cấu hình (ví dụ như tạo, chỉnh sa, xóa, chuyển về phiên bản trước) để xác nhận rằng tất cả các hoạt động của hệ thống CM đã được thực hiện phù hợp với thủ tục đã được chứng minh. Người đánh giá xác nhận rằng các bằng chứng bao gồm tất cả các thông tin được nhận dạng là hoạt động trong kế hoạch CM. Kiểm tra các bằng chứng có thể yêu cầu truy nhập đến một công cụ CM được sử dụng. Người đánh giá có thể chọn để lấy mẫu bằng chứng. Xem hướng dẫn về lấy mẫu tại A.2, Lấy mẫu.

Để tăng sự tin cậy trong hoạt động chính xác hơn của hệ thống CM và bảo trì có hiệu quả các hạng mục cấu hình có thể được thiết lập bằng cách phỏng vấn với các nhân viên phát triển được lựa chọn. Khi tiến hành phỏng vn, người đánh giá với mục đích đạt được sự hiểu biết sâu sắc hơn về cách các hệ thống CM được sử dụng trong thực tế cũng như để xác nhận rằng các thủ tục CM đang được áp dụng như mô tả trong tài liệu CM. Lưu ý rằng phỏng vấn như vậy chỉ là bổ sung chứ không thay thế việc kiểm tra các bằng chứng tài liệu và có thể là không cần thiết nếu các bằng chứng tài liệu đáp ứng các yêu cầu. Tuy nhiên, với phạm vi rộng của kế hoạch CM nó có thể có một số khía cạnh (ví dụ như các vai trò và trách nhiệm) có thể không rõ ràng từ kế hoạch CM và hồ sơ. Đây là một trong những trường hợp cần làm rõ có thể cần thiết thông qua các cuộc phỏng vấn.

Người đánh giá cần tham khảo các trang web phát triển đ hỗ trợ các hoạt động này.

Để biết thông tin về các trang web tham khảo xem A.4, Các trang web tham khảo.

12.2.5  Đánh giá hoạt động con (ALC_CMC.5)

12.2.5.1  Mục tiêu

Mục tiêu hoạt động con này là đ xác định xem liệu nhà phát triển đã nhận dạng rõ ràng TOE và các khoản mục cấu hình liên quan và khả năng sửa đổi các hạng mc này có được kiểm soát hợp lý bởi các công cụ tự động hay không, để cho hệ thống CM ít phụ thuộc hơn vào lỗi chủ quan của con người.

12.2.5.2  Đầu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) TOE phù hợp để thử nghiệm;

c) tài liệu quản lý cấu hình.

12.2.5.3  Hành động ALC_CMC.5.1E

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.5.1C: TOE cần được dán nhãn với tham chiếu duy nhất của nó.

12.2.5.3.1  Đơn vị công việc ALC_CMC.5-1

Người đánh giá cần kiểm tra rằng TOE được cung cấp để đánh giá đã được dán nhãn với tham chiếu của nó.

Người đánh giá cần đảm bảo rằng TOE chứa các tham chiếu duy nhất được ghi trong ST. Điều này có thể đạt được thông qua dán nhãn bao bì hoặc phương tiện truyền thông hoặc bởi một nhãn hiển thị bởi TOE hoạt động. Điều này là để đảm bảo rằng nó có thể giúp cho khách hàng nhận dạng TOE (ví dụ tại điểm mua hàng hoặc sử dụng).

TOE có th cung cấp một phương pháp mà theo đó nó có thể được nhận dạng dễ dàng. Ví dụ, một phần mềm có thể hiển thị tên và số phiên bản của TOE trong quá trình khởi động hoặc để đáp ứng với một dòng lệnh. Phần cứng và phần sụn TOE có thể được nhận dạng bởi một số hiệu vật lý trên TOE. Ngoài ra, các tham chiếu duy nhất được cung cấp cho TOE có thể là sự kết hợp của các tham chiếu duy nhất của mỗi thành phần mà từ đó TOE được tổng hợp (ví dụ như trong trường hợp của một TOE tổng hợp).

12.2.5.3.2  Đơn vị công việc ALC_CMC.5-2

Người đánh giá cần kiểm tra rằng tham chiếu TOE được sử dụng là nhất quán.

Nếu TOE được dán nhiều hơn một nhãn thì các nhãn này phải là nhất quán. Ví dụ, chúng ta có thể dán nhãn tài liệu hướng dẫn được cung cấp như là một phần của TOE đã được đánh giá. Điều này đảm bảo người tiêu dùng có thể tự tin rằng họ đã mua phiên bản TOE đã được đánh giá và đã cài đặt phiên bản này và có phiên bản hướng dẫn chính xác để vận hành TOE phù hợp với ST.

Người đánh giá cũng xác nhận rằng tham chiếu TOE nhất quán với ST.

Nếu đơn vị công việc này được áp dụng cho một TOE tổng hợp, các điều sau đây sẽ được áp dụng. Các TOE công nghệ thông tin kết hợp sẽ không được dán nhãn với tham chiếu duy nhất, mà chcác thành phần riêng sẽ được dán nhãn với tham chiếu TOE thích hợp. Cần có các phát triển tiếp theo cho TOE công nghệ thông tin được dán nhãn, ví dụ quá trình khởi động và/hoặc vận hành, với tham chiếu tổng hợp. Nếu TOE tổng hợp được chuyển giao như các TOE thành phần cấu thành, thì các khoản mục TOE chuyển giao sẽ không chứa các tham chiếu tổng hợp. Tuy nhiên, TOE ST kết hợp sẽ bao gồm các tham chiếu duy nhất cho TOE tổng hợp và sẽ nhận dạng các thành phần bao gồm của TOE tổng hợp mà qua đó khách hàng sẽ có thể xác định xem chúng có các khoản mục phù hợp.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.5.2C: Tài liệu CM cần mô tả phương pháp được sử dụng để nhận dạng các khoản mục cấu hình một cách duy nhất.

12.2.5.3.3  Đơn vị công việc ALC_CMC.5-3

Người đánh giá cần xem xét các phương pháp nhận dạng các khoản mục cấu hình để xác định rằng nó mô tả cách các khoản mục cấu hình là nhận dạng duy nhất.

Các thủ tục cần mô tả cách thức có thể theo dõi được trạng thái của từng khoản mục cấu hình trong suốt vòng đời của TOE. Các thủ tục có thể được trình bày chi tiết trong kế hoạch CM hoặc trong các tài liệu CM. Các thông tin cần mô tả bao gồm:

a) phương pháp để từng khoản mục cấu hình được nhận dạng duy nhất, để có thể theo dõi các phiên bản của cùng một khoản mục cấu hình;

b) phương pháp để từng khoản mục cấu hình được gán bộ nhận dạng duy nhất và cách thức cập nhập chúng vào hệ thống CM;

c) phương pháp được sử dụng để nhận dạng phiên bản thay thế của một khoản mục cấu hình.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.5.3C: Tài liệu CM cần xác minh rằng 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 khoản mục cấu hình.

12.2.5.3.4  Đơn v công việc ALC_CMC.5-4

Người đánh giá cần kiểm tra tài liệu CM để xác định rằng nó xác minh 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 cho tất cả các khoản mục cấu hình.

Tài liệu CM nên làm đầy đủ rõ ràng bằng cách tuân theo các thủ tục chấp thuận rằng ch các bộ phận đảm bảo chất lượng được đưa vào TOE.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.5.4C: Hệ thống CM cần nhận dạng tất cả các khoản mục cấu hình một cách duy nhất.

12.2.5.3.5  Đơn vị công việc ALC_CMC.5-5

Ngưi đánh giá cần kiểm tra các khoản mục cấu hình để xác định rằng chúng được nhận dạng theo cách nhất quán với tài liệu CM.

Đảm bảo rằng hệ thống CM nhận dạng một cách duy nhất tất cả các khoản mục cấu hình đã đạt được bằng cách kiểm tra bộ nhận dạng cho các khoản mục cấu hình. Đối với c hai khoản mục cấu hình bao gồm TOE và dự kiến các khoản mục cấu hình được đề xuất bởi nhà phát triển là bằng chứng đánh giá, Người đánh giá xác nhận rằng mỗi khoản mục cấu hình có một số hiệu nhận dạng duy nht theo cách nhất quán với phương pháp nhận dạng duy nhất được mô tả trong tài liệu CM.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.5.5C: Hệ thống CM cần cung cấp các biện pháp tự động mà ch các thay đổi được cấp quyền được thực thi đối với các khoản mục cấu hình.

12.2.5.3.6  Đơn vị công việc ALC_CMC.5-6

Người đánh giá cần kiểm tra các biện pháp kiểm soát truy nhập CM được mô tả trong các kế hoạch CM (cf. ALC_CMC.5.12C) để xác định rằng chúng là t động và có hiệu quả trong việc ngăn ngừa truy nhập trái phép vào các khoản mục cấu hình.

Người đánh giá có thể sử dụng một số phương pháp để xác định rằng các biện pháp kiểm soát truy nhập CM là có hiệu quả. Ví dụ, Người đánh giá có thể thực hiện các biện pháp kiểm soát truy nhập để đảm bảo rằng các thủ tục không thể được bỏ qua. Người đánh giá có thể sử dụng các kết quả đầu ra được tạo ra bởi các thủ tục hệ thống CM được yêu cầu bởi ALC_CMC.5.16C. Người đánh giá cũng có thể chứng kiến quá trình chứng minh của hệ thống CM để đảm bảo rằng các biện pháp kiểm soát truy nhập được sử dụng đang hoạt động có hiệu quả.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.5.6C: Hệ thống CM cần hỗ trợ việc sản xuất của TOE bằng các phương tiện tự động.

12.2.5.3.7  Đơn vị công việc ALC_CMC.5-7

Người đánh giá cần kiểm tra các kế hoạch CM (cf. ALC_CMC.5.12C) cho các thủ tục tự động để hỗ trợ việc sản xuất của TOE.

Thuật ngữ "sản xuất" được áp dụng cho các quá trình được thông qua bởi nhà phát triển để cải tiến TOE từ triển khai thực hiện tới một trạng thái có thể chấp nhận đ chuyển giao cho khách hàng. Người đánh giá xác minh sự tồn tại của thủ tục hỗ trợ sản xuất tự động hóa trong kế hoạch CM.

Sau đây là những ví dụ về các phương tiện tự động hỗ trợ sản xuất của TOE:

- công cụ "tạo" (cung cấp với nhiều công cụ phát triển phần mềm) trong trường hợp của một TOE phần mềm;

- công cụ đảm bảo tự động (ví dụ là các phương tiện mã vạch) mà chỉ có các bộ phận được kết hợp với nhau trong trường hợp là một TOE phần cứng.

12.2.5.3.8  Đơn vị công việc ALC_CMC.5-8

Người đánh giá cn kiểm tra các thủ tục hỗ trợ sản xuất TOE để xác định rằng chúng là có hiệu quả trong việc đảm bảo rằng một TOE được tạo ra phản ánh việc triển khai thực hiện nó.

Các thủ tục hỗ trợ sn xuất cần mô tả các công cụ đã được sử dụng để sản xuất TOE hoàn chỉnh từ việc triển khai thực hiện một cách rõ ràng. Các quy ước, chỉ thị hoặc cấu trúc cần thiết khác được mô tả trong ALC_TAT.

Người đánh giá xác định rằng bằng cách làm theo các thủ tục hỗ trợ sản xuất các khoản mục cấu hình chính xác sẽ được sử dụng để tạo ra TOE. Ví dụ, trong một TOE phần mềm này có thể bao gồm việc kiểm tra các thủ tục sản xuất tự động đảm bảo rằng tất cả các tập tin nguồn và các thư viện liên quan đã có trong mã đối tượng biên dịch. Hơn nữa, các thủ tục cần đảm bảo rằng tùy chọn biên dịch và so sánh các lựa chọn khác được xác định duy nhất. Đối với một TOE phần cứng, đơn vị công việc này có thể bao gồm việc kiểm tra các thủ tục sản xuất tự động đảm bảo rằng các bộ phận được ghép lại với nhau và không có bộ phận bị thiếu.

Khi đó khách hàng có thể chắc chắn rằng các phiên bản của TOE được chuyển giao để cài đặt có ngun gc từ quá trình triển khai thực hiện một cách tường minh và thực hiện các SFR như được mô tả trong ST.

Người đánh giá cần lưu ý rằng hệ thống CM không nhất thiết phải có khả năng sản xuất TOE, nhưng nên cung cấp hỗ trợ cho quá trình đó sẽ giúp làm giảm xác suất lỗi của con người.

TCVN 8709-3 (ISO/IEC 15408-3) 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 khoản mục cấu hình vào CM không phải là người phát triển nó.

12.2.5.3.9  Đơn vị công việc ALC_CMC.5-9

Người đánh giá cần kiểm tra hệ thống CM để xác định rằng nó đảm bảo rằng những người chịu trách nhiệm chấp nhận một khoản mục cấu hình không phải là người phát triển nó.

Các thủ tục chấp thuận mô tả những người chịu trách nhiệm cho việc chấp nhận một khoản mục cấu hình. Từ những mô tả đó, người đánh giá có thể xác định rằng những người đã phát triển một khoản mục cấu hình trong mọi trường hợp không chịu trách nhiệm về việc chấp nhận của nó.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.5.8C: Hệ thống CM cần nhận dạng các khoản mục cấu hình có trong TSF.

12.2.5.3.10  Đơn vị công việc ALC_CMC.5-10

Người đánh giá cần kiểm tra hệ thống CM để xác định rằng nó nhận dạng các khoản mục cấu hình có trong TSF.

Tài liệu CM cần mô tả cách thức hệ thống CM nhận dạng các khoản mục cấu hình có trong TSF. Người đánh giá nên chọn một mẫu của các khoản mục cấu hình bao gồm từng loại khoản mục, đặc biệt chứa trong các khoản mục TSF và Non-TSF và kiểm tra xem chúng được phân loại chính xác bởi hệ thống CM hay không.

Xem hướng dẫn về lấy mẫu tại A.2, Lấy mẫu.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.5.9C: Hệ thống CM cần hỗ trợ kiểm soát tất cả các thay đổi của TOE bằng các phương tiện tự động, bao gồm người khởi tạo, ngày giờ trong tệp tin kiểm soát.

12.2.5.3.11  Đơn v công việc ALC_CMC.5-11

Người đánh giá cần kiểm tra hệ thống CM để xác định rằng nó hỗ trợ việc kiểm soát tất cả các thay đổi của TOE bằng các phương tiện tự động, bao gồm người khởi tạo, ngày giờ trong tệp tin kiểm soát. Người đánh giá cần kiểm tra và xem xét kỹ một mẫu của tệp tin kiểm soát, nếu chúng chứa các thông tin tối thiểu.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.5.10C: Hệ thống CM cần cung cấp các phương tiện tự động để nhận dạng tất cả các khoản mục cấu hình khác bị ảnh hưởng bởi sự thay đổi của một khoản mục cấu hình.

12.2.5.3.12  Đơn vị công việc ALC_CMC.5-12

Người đánh giá cần kiểm tra hệ thống CM để xác định rằng nó cung cấp các phương tiện tự động để nhận dạng tất c các khoản mục cấu hình khác bị ảnh hưởng bởi sự thay đổi của một khoản mục cấu hình.

Tài liệu CM cần mô tả cách thức hệ thống CM nhận dạng tất cả các khoản mục cấu hình khác bị ảnh hưởng bởi việc thay đổi một khoản mục cấu hình. Người đánh giá nên chọn một mẫu khoản mục cấu hình, bao gồm tất cả các loại khoản mục và sử dụng các phương tiện tự động để xác định rằng nó nhận dạng tất cả các khoản mục đang bị ảnh hưởng bởi sự thay đổi của khoản mục được chọn.

Xem hướng dẫn về lấy mẫu tại A.2, Lấy mẫu.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.5.11C: Hệ thống CM cần có khả năng nhận dạng phiên bản triển khai thực hiện mà từ đó tạo ra TOE.

12.2.5.3.13  Đơn vị công việc ALC_CMC.5-13

Người đánh giá cần kiểm tra hệ thống CM để xác định rằng nó có khả năng nhận dạng phiên bản triển khai thực hiện từ đó tạo ra TOE.

Tài liệu CM cần mô tả cách thức hệ thống CM nhận dạng phiên bản triển khai thực hiện từ đó tạo ra TOE. Người đánh giá cần chọn một mẫu của các bộ phận được sử dụng để sản xuất TOE và nên áp dụng hệ thống CM để xác minh rằng nó nhận dạng việc triển khai thực hiện tương ứng trong phiên bản chính xác.

Xem hướng dẫn về lấy mẫu tại A.2, Lấy mẫu.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.5.12C: Tài liệu CM cần bao gồm một kế hoạch CM.

12.2.5.3.14  Đơn vị công việc ALC_CMC.5-14

Người đánh giá cần kiểm tra rằng tài liệu CM được cung cấp bao gồm một kế hoạch CM.

Kế hoạch CM không nhất thiết phải là một tài liệu kết nối, nhưng nó được khuyến cáo rằng cần có một tài liệu riêng mô tả nơi mà các bộ phận khác nhau của kế hoạch CM có thể được tìm thấy. Nếu kế hoạch CM không phải là tài liệu riêng, danh sách đơn vị công việc sau đây đưa ra gợi ý về bối cảnh dự kiến.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.5.13C: Kế hoạch CM cần mô tả cách thức hệ thống CM được sử dụng đ phát triển TOE.

12.2.5.3.15  Đơn vị công việc ALC_CMC.5-15

Người đánh giá cần kiểm tra kế hoạch CM để xác định rằng nó mô tả cách thức hệ thống CM được sử dụng để phát triển TOE.

Các mô tả có trong một kế hoạch CM bao gồm, nếu áp dụng:

a) tất cả các hoạt động thực hiện trong việc phát triển TOE là đối tượng của các thủ tục quản lý cấu hình (Ví dụ: tạo, chỉnh sửa hoặc xóa một khoản mục cấu hình, dữ liệu sao lưu, lưu trữ);

b) các phương tiện (ví dụ: công cụ CM, mẫu) có sẵn;

c) cách sử dụng các công cụ CM: các chi tiết cần thiết cho một người sử dụng hệ thống CM để có khả năng vận hành các công cụ CM một cách chính xác nhằm duy trì tính toàn vẹn của TOE;

d) các thủ tục hỗ trợ sản xuất;

e) các đối tượng khác (các thành phần phát triển, các công cụ, môi trường đánh giá, vv) được thực hiện dưới kiểm soát CM;

f) các vai trò và trách nhiệm của các cá nhân cần thiết để thực hiện vận hành các hạng mục cấu hình riêng (Các vai trò khác nhau có thể được nhận dạng cho các loại khoản mục cấu hình khác nhau (ví dụ như thiết kế tài liệu hoặc mã nguồn));

g) các trường hợp CM (ví dụ như bảng kiểm soát thay đổi, giao diện kiểm soát làm việc nhóm) được cung cấp và nhân viên thực hiện;

h) mô tả về quản lý thay đổi;

i) các thủ tục được sử dụng để đảm bảo rằng chỉ có những người được cp quyền có thể thực hiện thay đổi các khoản mục cấu hình;

j) các thủ tục được sử dụng để đảm bảo rằng các vấn đề không xảy ra đồng thời như là kết quả của việc thay đổi đồng thời các khoản mục cấu hình;

k) bằng chứng được tạo ra như là kết quả của việc áp dụng các thủ tục. Ví dụ, đối với một sự thay đổi một khoản mục cấu hình, hệ thống CM phải ghi lại mô tả về các thay đổi, gii trình về các thay đổi, nhận dạng tt c các khoản mục cấu hình bị ảnh hưởng và trạng thái của nó (ví dụ như treo hoặc hoàn thành) và ngày giờ của sự thay đổi. Điều này có thể được ghi lại trong tệp tin log (log file) của những thay đổi được thực hiện hoặc hồ sơ kiểm soát thay đổi;

I) phương pháp để kiểm soát phiên bản và tham chiếu duy nhất của các phiên bản TOE (ví dụ bao gồm việc phát hành bản vá lỗi trong hệ điều hành và phát hiện tiếp theo của ứng dụng).

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.5.14C: Kế hoạch CM cần mô tả các thủ tục được sử dụng để chấp nhận sửa đổi hoặc tạo ra một khoản mục cấu hình mới như một phần của TOE.

12.2.5.3.16  Đơn vị công việc ALC_CMC.5-16

Người đánh giá cần kiểm tra kế hoạch CM để xác định rằng nó mô tả các thủ tục được sử dụng để chấp nhận sửa đổi hoặc tạo ra một khoản mục cấu hình mới như một phần của TOE.

Việc mô tả của các thủ tục chấp thuận trong kế hoạch CM nên bao gồm các vai trò nhà phát triển hoặc cá nhân chịu trách nhiệm cho việc chấp nhận và các tiêu chí để được sử dụng chấp nhận. Nên đưa vào tài khoản tất cả tình huống chấp nhận có thể xảy ra, cụ thể:

a) chấp nhận một khoản mục vào hệ thống CM cho lần đầu tiên, đặc biệt là các thành phần phần mềm, phần sụn và phần cứng từ các nhà sản xuất khác vào TOE ("Tích hợp");

b) chuyển các khoản mục cấu hình vào giai đoạn vòng đời tiếp theo tại từng giai đoạn của việc xây dựng TOE (ví dụ như mô đun, phân hệ, hệ thống);

c) tiếp theo là vận chuyển giữa các điểm phát triển khác nhau.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.5.15C: Bằng chứng cần chứng minh rằng tất cả các khoản mục cấu hình đang được duy trì bởi hệ thống CM.

12.2.5.3.17  Đơn v công việc ALC_CMC.5-17

Người đánh giá cần kiểm tra các khoản mục cấu hình được nhận dạng trong danh sách cấu hình đang được duy trì bởi hệ thống CM.

Hệ thống CM được dùng bởi nhà phát triển cần phải duy trì tính toàn vẹn của TOE. Người đánh giá cần kiểm tra cho mỗi loại khoản mục cấu hình (ví dụ như tài liệu thiết kế hoặc các mô đun mã ngun) có trong danh sách cấu hình có những ví dụ về các bằng chứng được tạo ra bởi các thủ tục được mô tả trong kế hoạch CM. Trong trường hợp này, phương pháp lấy mẫu sẽ phụ thuộc vào mức độ chi tiết được sử dụng trong các hệ thống CM để kiểm soát các khoản mục CM. Trong trường hợp, ví dụ, mô đun mã nguồn 10.000 được nhận dạng trong danh sách cấu hình, phương pháp lấy mẫu khác nhau cần phải được áp dụng so với các trường hợp mà trong đó ch có 5 hoặc thậm chí là 1. Tầm quan trọng của hoạt động này cần đảm bảo rằng hệ thống CM đang được vận hành một cách chính xác, chứ không phải để phát hiện bất kỳ lỗi nào.

Xem hướng dẫn về lấy mẫu tại A.2, lấy mẫu.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMC.5.16C: Bằng chứng phải chứng minh rằng hệ thống CM đang vận hành phù hợp với kế hoạch CM.

12.2.5.3.18  Đơn vị công việc ALC_CMC.5-18

Người đánh giá cần kiểm tra tài liệu CM để chắc chắn rằng nó bao gồm các hồ sơ hệ thống CM được nhận dạng bởi kế hoạch CM.

Đầu ra của hệ thống CM cần cung cấp bằng chứng giúp người đánh giá chắc chắn rằng kế hoạch CM đang được áp dụng và tất cả các khoản mục cấu hình cũng đang được duy trì bởi hệ thống CM theo yêu cầu của ALC_CMC.5.15C. Ví dụ kết quả đầu ra có thể bao gồm các hình thức kiểm soát thay đổi hoặc các hình thức chấp thuận truy nhập khoản mục cấu hình.

12.2.5.3.19  Đơn vị công việc ALC_CMC.5-19

Người đánh giá cần kiểm tra các bằng chứng để xác định rằng hệ thống CM đang được vận hành phù hợp với kế hoạch CM.

Người đánh giá cần lựa chọn và kiểm tra một mẫu bằng chứng bao gồm từng loại các hoạt động CM-có liên quan đã được thực hiện trên một khoản mục cấu hình (ví dụ như tạo, chỉnh sửa, xóa, chuyển về phiên bản trước) để xác nhận rằng tất cả các hoạt động của hệ thống CM đã được thực hiện phù hợp với các thủ tục đã được chứng minh. Người đánh giá xác nhận rằng các bằng chứng bao gồm tất cả các thông tin được nhận dạng là hoạt động trong kế hoạch CM. Kiểm tra các bằng chứng có thể yêu cầu truy nhập đến một công cụ CM được sử dụng. Người đánh giá có thể chọn để lấy mẫu bằng chứng.

Xem hướng dẫn về lấy mẫu tại A.2, Lấy mẫu.

Để tăng sự tin cậy trong hoạt động chính xác hơn của hệ thống CM và bảo trì có hiệu quả các hạng mục cấu hình có thể được thiết lập bằng cách phỏng vấn với các nhân viên phát triển được lựa chọn. Khi tiến hành phỏng vấn, người đánh giá với mục đích đạt được sự hiểu biết sâu sắc hơn về cách các hệ thống CM được sử dụng trong thực tế cũng như để xác nhận rằng các thủ tục CM đang được áp dụng như mô t trong tài liệu CM. Lưu ý rằng phỏng vấn như vậy ch là b sung chứ không thay thế việc kiểm tra các bằng chứng tài liệu và có thể là không cần thiết nếu các bằng chứng tài liệu đáp ứng các yêu cầu. Tuy nhiên, với phạm vi rộng của kế hoạch CM nó có thể có một số khía cạnh (ví dụ như các vai trò và trách nhiệm) có thể không rõ ràng từ kế hoạch CM và hồ sơ. Đây là một trong những trường hợp cần làm rõ có thể cần thiết thông qua các cuộc phỏng vấn.

Người đánh giá cần tham khảo các trang web phát triển để hỗ trợ các hoạt động này.

Để biết thông tin về các trang web tham khảo xem A.4, Các trang web tham khảo.

12.2.5.4  Hành động ALC_CMC.5.2E

12.2.5.4.1  Đơn vị công việc ALC_CMC.5-20

Người đánh giá cần kiểm tra các thủ tục hỗ trợ sản xuất để xác định rằng bằng cách làm theo các thủ tục đó một TOE sẽ được sản xuất như một sản phẩm được cung cấp bởi nhà phát triển cho hoạt động kiểm thử.

Nếu TOE là một TOE phần mềm nhỏ và việc sản xuất bao gồm các biên dịch và liên kết, người đánh giá có thể xác nhận sự phù hợp của các thủ tục hỗ trợ sản xuất bằng cách tự áp dụng lại nó.

Nếu quá trình sản xuất của TOE phức tạp hơn (ví dụ như trong trường hợp của một th thông minh), ngay khi bắt đầu, người đánh giá cần xem xét kỹ việc áp dụng các thủ tục hỗ trợ sản xuất trong quá trình tham khảo các trang web phát triển. Có thể so sánh bn sao của một TOE được sản xuất tại chỗ với các mẫu được sử dụng cho các hoạt động kiểm thử của mình.

Để biết thông tin về các trang web tham khảo xem A.4, Các trang web tham khảo.

Nếu không, quyết định của người đánh giá nên dựa trên các bằng chứng tài liệu được cung cấp bởi nhà phát triển.

Đơn vị công việc này có thể được thực hiện kết hợp với các hoạt động đánh giá theo quá trình triển khai thực hiện (ADV_IMP).

12.3  Phạm vi CM (ALC_CMS)

12.3.1  Đánh giá hoạt động con (ALC_CMS.1)

12.3.1.1  Mục tiêu

Mục tiêu hoạt động con này là để xác định xem liệu nhà phát triển có thực hiện quản lý cấu hình trên TOE và các bằng chứng đánh giá. Những khoản mục cấu hình này được kiểm soát phù hợp với khả năng của CM (ALC_CMC) hay không.

12.3.1.2  Đầu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) danh sách cấu hình.

12.3.1.3  Hành động ALC_CMS.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMS.1.1C: Danh sách cấu hình cần cha thông tin sau: TOE và các bằng chứng đánh giá được yêu cầu bởi các SAR.

12.3.1.3.1  Đơn vị công việc ALC_CMS.1-1

Người đánh giá cn kiểm tra rằng danh sách cấu hình bao gồm tập hợp các khoản mục sau đây:

a) TOE;

b) bằng chứng đánh giá được yêu cầu bởi các SAR trong ST.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMS.1.2C: Danh sách cấu hình cn xác định duy nhất các khoản mục cấu hình.

12.3.1.3.2  Đơn vị công việc ALC_CMS.1-2

Người đánh giá cn kiểm tra danh sách cấu hình để xác định rằng nó nhận dạng duy nhất từng khon mục cấu hình.

Danh sách cấu hình chứa đầy đủ thông tin để nhận dạng duy nhất phiên bản của từng khoản mục đã được sử dụng (thường là số phiên bản). Sử dụng danh sách này sẽ cho phép người đánh giá kiểm tra chính xác các khoản mục cấu hình và phiên bản chính xác của từng khoản mục đã được sử dụng trong quá trình đánh giá.

12.3.2  Đánh giá hoạt động con (ALC_CMS.2)

12.3.2.1  Mục tiêu

Mục tiêu hoạt động con này là xác định xem liệu danh sách cấu hình có bao gồm TOE, các bộ phận của TOE và các bằng chứng đánh giá. Những khoản mục cấu hình này được kiểm soát phù hợp với khả năng CM (ALC_CMC) hay không.

12.3.2.2  Đầu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) danh sách cấu hình.

12.3.2.3  Hành động ALC_CMS.2.1E

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMS.2.1C: Danh sách cấu hình cần bao gồm: TOE; các bằng chứng đánh giá được yêu cầu bởi các SAR và các bộ phn cấu thành TOE.

12.3.2.3.1  Đơn vị công việc ALC_CMS.2-1

Người đánh giá cần kiểm tra rằng danh sách cấu hình bao gồm tập hợp các khoản mục sau đây:

a) TOE;

b) các bộ phận cấu thành TOE;

c) các bằng chứng đánh giá được yêu cầu bởi các SAR.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMS.2.2C: Danh sách cấu hình cần nhận dạng duy nhất các khoản mục cấu hình.

12.3.2.3.2  Đơn vị công việc ALC_CMS.2-2

Người đánh giá cần kim tra danh sách cấu hình để xác định rằng nó nhận dạng duy nhất từng khoản mục cấu hình.

Danh sách cấu hình cha đầy đủ thông tin để nhận dạng duy nhất phiên bản của từng khoản mục đã được sử dụng (thường là s phiên bản). Sử dụng danh sách này sẽ cho phép người đánh giá kiểm tra các khoản mục cấu hình chính xác và phiên bản chính xác của từng khoản mục đã được sử dụng trong quá trình đánh giá.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMS.2.3C: Đối với từng khoản 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 khoản mục đó.

12.3.2.3.3  Đơn vị công việc ALC_CMS.2-3

Người đánh giá cần kiểm tra rằng danh sách cấu hình chỉ ra nhà phát triển của từng khoản mục cấu hình liên quan của TSF.

Nếu chỉ có một nhà phát triển có liên quan đến sự phát triển của TOE, đơn vị công việc này không được áp dụng và do đó được xem là thỏa mãn.

12.3.3  Đánh giá hoạt động con (ALC_CMS.3)

12.3.3.1  Mục tiêu

Mục tiêu hoạt động con này là để xác định xem liệu danh sách cấu hình có bao gồm TOE, các bộ phận cấu thành TOE, quá trình triển khai thực hiện TOE và các bằng chứng đánh giá. Các khoản mục cấu hình này được kiểm soát phù hợp với khả năng CM (ALC_CMC) hay không.

12.3.3.2  Đầu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) danh sách cấu hình.

12.3.3.3  Hành động ALC_CMS.3.1E

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMS.3.1C: Danh sách cấu hình cần chứa thông tin sau: TOE; các bằng chứng đánh giá được yêu cầu bởi các SAR, các bộ phận cấu thành TOE; quá trình triển khai thực hiện.

12.3.3.3.1  Đơn vị công việc ALC_CMS.3-1

Người đánh giá cần kiểm tra rằng danh sách cấu hình bao gồm tập hợp các khon mục sau đây:

a) TOE;

b) các bộ phận cấu thành TOE;

c) quá trình triển khai thực hiện TOE;

d) bằng chứng đánh giá được yêu cầu bởi các SAR trong ST.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMS.3.2C: Danh sách cấu hình cần nhận dạng duy nhất các khoản mục cấu hình.

12.3.3.3.2  Đơn vị công việc ALC_CMS.3-2

Người đánh giá cần kiểm tra danh sách cấu hình để xác định rằng nó nhận dạng duy nhất từng khon mục cấu hình.

Danh sách cấu hình chứa đầy đủ thông tin đ nhận dạng duy nhất phiên bn của từng khoản mục đã được sử dụng (thường là số phiên bản). Sử dụng danh sách này sẽ cho phép người đánh giá kiểm tra chính xác các hạng mục cấu hình và phiên bn chính xác của từng khoản mục đã được sử dụng trong quá trình đánh giá.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMS.3.3C: Đối với từng khoản mục cấu hình liên quan của TSF, danh sách cấu hình cn chỉ ra nhà phát triển của khoản mục đó.

12.3.3.3.3  Đơn vị công việc ALC_CMS.3-3

Người đánh giá cần kiểm tra rằng danh sách cấu hình chỉ ra nhà phát triển của từng khoản mục cấu hình liên quan của TSF.

Nếu chỉ có một nhà phát triển có liên quan đến sự phát triển của một TOE, đơn vị công việc này không được áp dụng và do đó được xem là tha mãn.

12.3.4  Đánh giá hoạt động con (ALC_CMS.4)

12.3.4.1  Mục tiêu

Mục tiêu hoạt động con này là để xác định xem liệu danh sách cấu hình có bao gm TOE, các bộ phận cấu thành TOE, quá trình triển khai thực hiện TOE, các sai sót an toàn và các bằng chứng đánh giá. Những khoản mục cấu hình này có được kiểm soát trong phù hợp với khả năng CM (ALC_CMC) hay không.

12.3.4.2  Đầu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) danh sách cấu hình.

12.3.4.3  hành động ALC_CMS.4.1E

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMS.4.1C: Danh sách cấu hình cần bao gồm các thông tin sau: TOE; các bằng chng đánh giá được yêu cầu bởi các SAR, các bộ phận cấu thành TOE, quá trình triển khai thực hiện; các báo cáo sai sót an toàn và tình huống giải quyết.

12.3.4.3.1  Đơn vị công việc ALC_CMS.4-1

Người đánh giá cần kiểm tra rằng danh sách cấu hình bao gồm tập hợp các khoản mục sau đây:

a) TOE;

b) các bộ phận cấu thành TOE;

c) quá trình triển khai thực hiện TOE;

d) bằng chứng đánh giá được yêu cầu bi các SAR trong ST;

e) tài liệu được sử dụng để ghi lại báo cáo chi tiết các sai sót an toàn liên quan đến việc thực hiện (ví dụ, báo cáo tình trạng vn đề bt nguồn từ cơ sở dữ liệu vn đề của nhà phát triển).

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMS.4.2C: Danh sách cấu hình cần nhận dạng duy nhất các khoản mục cấu hình.

12.3.4.3.2  Đơn vị công việc ALC_CMS.4-2

Người đánh giá cần kiểm tra danh sách cấu hình để xác định rằng nó nhận dạng duy nhất từng khoản mục cấu hình.

Danh sách cấu hình cha đầy đủ thông tin để nhận dạng duy nhất phiên bản của từng khoản mục đã được sử dụng (thường là số phiên bản). Sử dụng danh sách này cho phép người đánh giá kiểm tra chính xác các khoản mục cấu hình và phiên bản chính xác của từng khoản mục đã được sử dụng trong quá trình đánh giá.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMS.4.3C: Đối với mỗi khoản mục cấu hình liên quan của TSF, danh sách cấu hình cần chỉ ra nhà phát triển của khoản mục đó.

12.3.4.3.3  Đơn vị công việc ALC_CMS.4-3

Người đánh giá cần kiểm tra rằng danh sách cấu hình chỉ ra nhà phát triển của từng khoản mục cấu hình liên quan của TSF.

Nếu ch có một nhà phát triển có liên quan đến sự phát triển của TOE, đơn vị công việc này không được áp dng và do đó được xem là thỏa mãn.

12.3.5  Đánh giá hoạt động con (ALC_CMS.5)

12.3.5.1  Mục tiêu

Mục tiêu hoạt động con này là để xác định xem liệu danh sách cấu hình có bao gồm TOE, các bộ phận cấu thành TOE, quá trình triển khai thực hiện TOE, các sai sót an toàn, các công cụ phát triển, các thông tin liên quan và các bằng chứng đánh giá. Các khoản mục cấu hình này có được kiểm soát phù hợp với khả năng CM (ALC_CMC) hay không.

12.3.5.2  đầu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) danh sách cấu hình.

12.3.5.3  Hành động ALC_CMS.5.1E

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMS.5.1C: Danh sách cấu hình cần bao gồm các thông tin sau: TOE; các bằng chứng đánh giá được yêu cầu bởi các SAR, các bộ phận cấu thành TOE, quá trình triển khai thực hiện; báo cáo sai sót an toàn và các tình huống giải quyết; các công cụ phát triển và thông tin liên quan.

12.3.5.3.1  Đơn vị công việc ALC_CMS.5-1

Người đánh giá cần kiểm tra rằng danh sách cấu hình bao gồm tập hợp các khoản mục sau đây:

a) TOE;

b) các bộ phận cấu thành TOE;

c) quá trình triển khai thực hiện TOE;

d) bằng chứng đánh giá được yêu cầu bởi các SAR trong ST;

e) tài liệu được sử dụng để ghi lại báo cáo chi tiết các sai sót an toàn liên quan đến việc thực hiện (Ví dụ, báo cáo các tình trạng vấn đề thu được từ cơ sở dữ liệu vấn đề của nhà phát triển);

f) tất cả các công cụ (bao gồm phần mềm kiểm thử, nếu áp dụng) tham gia vào việc phát triển và sn xut TOE bao gồm tên, phiên bản, cấu hình, các vai trò của từng công cụ phát triển và các tài liệu liên quan.

Đối với một TOE phần mềm, "công cụ phát triển" thường là lập trình ngôn ngữ, trình biên dịch và "tài liệu liên quan" bao gồm trình biên dịch và mối liên kết tùy chọn. Đối với một TOE phần cứng, "công cụ phát triển" có thể là ngôn ngữ thiết kế phần cứng, các công cụ mô phng và tổng hợp, trình biên dịch và "tài liệu liên quan" có thể bao gồm c các tùy chọn trình biên dịch.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMS.5.2C: Danh sách cấu hình cần nhận dạng duy nhất các hạng mục cấu hình.

12.3.5.3.2  Đơn vị công việc ALC_CMS.5-2

Người đánh giá cần kiểm tra danh sách cấu hình để xác định rằng nó nhận dạng duy nhất từng khoản mục cấu hình.

Danh sách cấu hình chứa đầy đủ thông tin để nhận dạng duy nhất phiên bản của từng khoản mục đang được sử dụng (thường là số phiên bản). Sử dụng danh sách này cho phép người đánh giá kiểm tra chính xác các khoản mục cấu hình và phiên bản chính xác của từng khoản mục đã được sử dụng trong quá trình đánh giá.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_CMS.5.3C: Đối với tng khoản mục cấu hình liên quan của TSF, danh sách cấu hình cần chỉ ra nhà phát triển của khoản mục đó.

12.3.5.3.3  Đơn vị công việc ALC_CMS.5-3

Người đánh giá cn kiểm tra rằng danh sách cấu hình chỉ ra nhà phát triển của từng khoản mục cấu hình liên quan của TSF.

Nếu chỉ có một nhà phát triển tham gia vào việc phát triển TOE, đơn vị công việc này không được áp dụng và do đó được xem là thỏa mãn.

12.4  Chuyển giao (ALC_DEL)

12.4.1  Đánh giá hoạt động con (ALC_DEL.1)

12.4.1.1  Mục tiêu

Mục tiêu của hoạt động con này là để xác định xem liệu tài liệu chuyển giao có mô tả tất cả các thủ tục được sử dụng để duy trì an toàn của TOE khi phân phối TOE đến người sử dụng hay chưa.

12.4.1.2  Đầu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) tài liệu chuyển giao.

12.4.1.3  Hành động ALC_DEL.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) ALC_DEL.1.1C: Tài liệu chuyển giao cần mô tả tất cả các 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.

12.4.1.3.1  Đơn vị công việc ALC_DEL.1-1

Người đánh giá cần kiểm tra các tài liệu chuyển giao để xác định rằng nó mô tả tất cả các thủ tục đó cần thiết để duy trì an toàn khi phân phối các phiên bản của TOE hoặc các bộ phận của nó đến người tiêu dùng.

Các tài liệu chuyển giao mô tả các thủ tục thích hợp để duy trì an toàn của TOE trong quá trình chuyển giao TOE hoặc các bộ phận thành phần của nó và để xác định việc nhận dạng của TOE.

Các tài liệu chuyn giao nên bao gồm toàn bộ TOE, nhưng có thể chứa các thủ tục khác nhau cho các bộ phận khác nhau của TOE. Người đánh giá cần xem xét tổng thể các thủ tục.

Các thủ tục chuyển giao nên được áp dụng trên tất cả các giai đoạn của việc chuyển giao từ môi trường sản xuất đến môi trường cài đặt (ví dụ như đóng gói, lưu trữ và phân phối). Tiêu chuẩn thương mại thực hành cho việc đóng gói và chuyển giao có thể được chấp nhận. Điều này bao gồm việc đóng gói bao bì an toàn hoặc niêm phong. Đối với việc phân phối, các thủ tục vật lý (ví dụ như gửi qua đường thư hoặc một dịch vụ phân phối tư nhân) hoặc điện tử (ví dụ như thư điện tử hoặc tải từ Internet) có thể được sử dụng.

Mật mã kiểm tra hoặc chữ ký phần mềm có thể được sử dụng bởi nhà phát triển để đảm bảo rằng việc tráo đi hoặc làm gi có thể được phát hiện. Bằng chứng tráo đổi niêm phong sẽ chỉ ra nếu tính bảo mật đã bị phá v. Đối với các TOE phần mềm, bảo mật có thể được đảm bảo bằng cách sử dụng mã hóa. Việc vận chuyển an toàn được yêu cầu nếu cn thiết.

Giải thích thuật ngữ "cần thiết duy trì an toàn" cần xem xét các khía cạnh sau:

• Tính chất của TOE (ví dụ: là phần mềm hoặc phần cứng).

• Mức độ an toàn tổng thể nêu cho TOE bằng mức độ lựa chọn của các đánh giá điểm yếu. Nếu TOE yêu cầu phải có khả năng chống lại những kẻ tấn công tiềm năng nhất định trong môi trường dự định của nó, điều này cũng nên áp dụng cho việc chuyn giao TOE. Người đánh giá cần xác định một cách tiếp cận cân bằng đã được thực hiện, chng hạn việc chuyển giao không phát sinh điểm yếu trong quá trình phát triển an toàn.

• Các mục tiêu an toàn cung cấp bởi ST. Tầm quan trọng của tài liệu chuyển giao có thể là các biện pháp liên quan đến tính toàn vẹn, như tính toàn vẹn của TOE luôn luôn là quan trọng. Tuy nhiên, bảo mật và khả năng sẵn sàng của việc chuyển giao sẽ được quan tâm trong trong việc chuyển giao một số TOE; Các thủ tục liên quan đến các các khía cạnh của việc chuyển giao an toàn cũng cần được đề cập trong các thủ tục.

12.4.1.4  Hành động đánh giá có chủ ý

TCVN 8709-3 (ISO/IEC 15408-3) ALC_DEL.1.2D: Nhà phát triển cần sử dụng các thủ tục chuyển giao.

12.4.1.4.1  Đơn vị công việc ALC_DEL.1-2

Người đánh giá cần xem xét các khía cạnh của quá trình chuyển giao đ xác định các thủ tục chuyển giao sử dụng.

Các phương pháp của người đánh giá để kiểm tra việc áp dụng các thủ tục chuyển giao sẽ phụ thuộc vào bản chất của TOE và quá trình chuyển giao nó. Ngoài việc kiểm tra chính các thủ tục, người đánh giá tìm kiếm sự đảm bảo rằng chúng được áp dụng trong thực tế. Một số phương pháp có thể là:

a) đi thực tế (các) địa điểm phân phối mà ở đó ứng dụng thực tế của các thủ tục có thể được quan sát;

b) kiểm tra TOE ở một số giai đoạn trong quá trình chuyển giao hoặc sau khi người dùng đã nhận được nó (ví dụ như kiểm tra các bằng chứng giả mạo con dấu);

c) quan sát quá trình được áp dụng trong thực tế khi người đánh giá có được TOE thông qua kênh hợp lệ;

d) hi người sử dụng về cách thức TOE được chuyn giao.

Để biết thông tin về việc đi thực tế các địa điểm, xem A.4, Thực tế các địa điểm.

Có thể xảy ra trường hợp một TOE phát triển mới nhưng các thủ tục chuyển giao vẫn chưa được thực hiện. Trong trường hợp này, người đánh giá phải hài lòng rằng các thủ tục và phương tiện thích hợp đã được cung cấp cho việc chuyển giao sau này và rằng tất cả các nhân viên tham gia đều nhận thức trách nhiệm của mình. Người đánh giá có thể yêu cầu một bước "chạy thô" đối với giao phẩm nếu điều này là phù hợp. Nếu nhà phát triển đã sản xuất sản phẩm tương tự khác, thì việc kiểm tra các thủ tục trong khi sử dụng chúng có thể là hữu ích trong việc cung cấp sự đảm bảo.

12.5  An toàn phát trin (ALC_DVS)

12.5.1  Đánh giá hoạt động con (ALC_DVS.1)

12.5.1.1  Mục tiêu

Mục tiêu hoạt động con này là để xác định xem liệu kiểm soát an toàn của nhà phát triển v môi trường phát triển đủ để cung cấp tính bảo mật và toàn vẹn của thiết kế TOE và thực hiện đó là cần thiết để đảm bảo rng hoạt động an toàn của TOE không bị ảnh hưởng hay không.

12.5.1.2  Đu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) tài liệu an toàn phát triển.

Ngoài ra, người đánh giá có thể cần phải kiểm tra khả năng chuyên giao khác để xác định rằng các kiểm soát an toàn được xác định rõ và tuân thủ. Cụ thể, người đánh giá có th cần phải kiểm tra tài liệu quản lý cấu hình của nhà phát triển (đầu vào cho các đánh giá của hoạt động con (ALC_CMC.4) "hỗ trợ sản xuất và các th tc chấp thuận" và đánh giá các hoạt động con (ALC_CMS.4) "Vấn đề theo dõi bảo hiểm CM "). Bằng chứng cho thấy các thủ tục đang được áp dụng cũng được yêu cầu.

12.5.1.3  Hành động ALC_DVS.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) 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 bảo mật và 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ó.

12.5.1.3.1  Đơn vị công việc ALC_DVS.1-1

Người đánh giá cần kiểm tra tài liệu an toàn phát triển để xác định rằng nó chi tiết tất cả các biện pháp an toàn được sử dụng trong các môi trường phát triển là cần thiết để bảo vệ tính bảo mật và toàn vẹn của thiết kế và thực thi TOE.

Người đánh giá sẽ xác định những gì là cần thiết bởi lần đầu đề cập đến ST cho bất kỳ thông tin nào có thể hỗ trợ trong việc việc xác định bảo vệ cần thiết.

Nếu không có thông tin rõ ràng có sẵn từ ST, người đánh giá cần phải xác định các biện pháp cần thiết. Trong trường hợp các biện pháp của nhà phát triển được xem là ít hơn so với những gì là cần thiết, việc biện minh rõ ràng cần được cung cấp cho việc đánh giá dựa vào các điểm yếu tiềm ẩn có thể khai thác.

Các loại các biện pháp an toàn sau đây được xem xét bởi người đánh giá khi xem xét các tài liệu:

a) biện pháp vật lý, ví dụ như kim soát truy nhập vật lý được sử dụng để ngăn chặn truy nhập trái phép môi trường phát triển TOE (trong làm việc bình thường và thời gian khác);

b) biện pháp về thủ tục, ví dụ bao gồm:

• cấp quyền truy nhập môi trường phát triển hoặc các bộ phận cụ thể của môi trường như thiết bị phát triển

• thu hồi quyền truy nhập khi một người rời khỏi đội phát triển

• chuyển giao các tài liệu được bảo vệ vào và ra khỏi môi trường phát triển và giữa các địa điểm phát triển khác nhau phù hợp với các thủ tục chấp thuận xác định

• cho vào và đưa khách hàng tới môi trường phát triển

• vai trò và trách nhiệm trong việc đảm bảo tiếp tục áp dụng các biện pháp an toàn và phát hiện các vi phạm an toàn;

c) nhân sự, ví dụ như bất kỳ kiểm soát hoặc kiểm tra được thực hiện để thiết lập sự tin cậy của nhân viên phát triển mới;

d) các biện pháp an toàn khác, ví dụ như bảo vệ hợp lý các phương tiện phát triển.

Tài liệu an toàn phát triển cần xác định các địa điểm mà tại đó phát triển xy ra và mô tả các khía cạnh của sự phát triển thực hiện, cùng với các biện pháp an toàn được áp dụng tại mỗi địa điểm và vận chuyển giữa các địa điểm khác nhau. Ví dụ, phát triển có thể xảy ra ở nhiều cơ sở trong một tòa nhà duy nhất, nhiều tòa nhà tại cùng một địa điểm hoặc nhiều địa điểm. Việc vận chuyển các bộ phận của TOE hoặc TOE chưa hoàn chỉnh giữa các địa điểm phát triển khác nhau phải được bảo đảm bởi an toàn phát triển (ALC_DVS), trong khi đó việc vận chuyển TOE hoàn thành tới cho người tiêu dùng được giải quyết trong chuyển giao (ALC_DEL).

Phát triển bao gồm việc sản xuất TOE.

12.5.1.3.2  Đơn vị công việc ALC_DVS.1-2

Người đánh giá cần kiểm tra các chính sách tích hợp và bảo mật phát triển để xác định sự đầy đủ của các biện pháp an toàn được sử dụng.

Người đánh giá cần xem xét liệu các điều sau đây có bao gồm trong các chính sách:

a) các thông tin liên quan đến phát triển TOE cần được giữ bí mật và ch các nhân viên đội phát triển được phép truy nhập thông tin đó;

b) tài liệu phải được bảo vệ tránh việc sửa đổi trái phép để bảo vệ sự toàn vẹn của TOE và ch các nhân viên đội phát triển được phép chnh sửa các tài liệu này.

Người đánh giá cần xác định rằng các chính sách này đã được mô tả trong tài liệu an toàn phát triển, rằng các biện pháp an toàn được sử dụng nhất quán với các chính sách và rằng chúng là đầy đủ.

Cần lưu ý rằng các thủ tục quản lý cấu hình sẽ giúp bảo vệ sự toàn vẹn của TOE và đánh giá nên tránh chồng chéo với các đơn vị công việc áp dụng cho khả năng CM (ALC_CMC). Ví dụ, tài liệu CM có thể mô tả các thủ tục an toàn cần thiết cho việc kiểm soát các vai trò hoặc cá nhân có quyền truy nhập môi trường phát triển và những người có thể thay đổi TOE.

Trong khi đó, kh năng CM (ALC_CMC) được yêu cầu cố định, thì đối với an toàn phát triển (ALC_DVS), ch yêu cầu có biện pháp cần thiết, phụ thuộc vào bản chất của TOE và thông tin đó có thể được cung cấp trong ST. Ví dụ, ST có thể nhận dạng một mục tiêu an toàn cho môi trường phát triển đòi hỏi TOE được phát triển bởi các nhân viên có kiến thức về an toàn. Người đánh giá sau đó sẽ xác định rằng một chính sách như vậy đã được áp dụng theo hoạt động con này.

12.5.1.4  Hành động ALC_DVS.1.2E

12.5.1.4.1  Đơn vị công việc ALC_DVS.1-3

Người đánh giá cần kiểm tra tài liệu an toàn phát triển và bằng chứng liên quan đến xác định rằng các biện pháp an toàn đang được áp dụng.

Đơn vị công việc này đòi hỏi người đánh giá xác định rằng các biện pháp an toàn được mô tả trong tài liệu phát triển an toàn đang được tuân thủ, chẳng hạn như tính toàn vẹn của TOE và tính bảo mật của các tài liệu liên quan đang được bảo vệ đầy đủ. Ví dụ, điều này có thể được xác định bằng kiểm tra các bằng chứng tài liệu được cung cấp. Bằng chứng tài liệu cần được bổ sung bằng cách đi thực tế môi trường phát triển. Thực tế môi trường phát triển s cho phép người đánh giá:

a) quan sát việc áp dụng các biện pháp an toàn (ví dụ như các biện pháp vật lý);

b) kiểm tra bằng chứng tài liệu về áp dụng thủ tục;

c) phng vn nhân viên phát triển đ kiểm tra kiến thức về các chính sách và thủ tục an toàn phát triển và trách nhiệm của họ.

Thực tế địa điểm phát triển là một phương tiện hữu ích đạt được sự tin cậy trong các biện pháp đang được sử dụng. Bất kỳ quyết định nào dẫn đến việc không thực hiện đi thực tế địa điểm phát triển như vậy cn được xác định trong thảo luận với tổ chức đánh giá.

Để biết thông tin về các địa điểm phát triển, xem A.4: thực tế các địa điểm.

12.5.2  Đánh giá hoạt động con (ALC_DVS.2)

12.5.2.1  Mục tiêu

Mục tiêu của hoạt động con này là để xác định xem liệu kiểm soát an toàn của nhà phát triển về môi trường phát triển là đầy đủ đ cung cấp sự bảo mật và tính toàn vẹn của thiết kế TOE và thực hiện điều đó là cần thiết để đảm bảo rằng hoạt động an toàn của TOE không bị tổn thương. Ngoài ra, tính đầy đủ của các biện pháp dự kiến được áp dụng cần được xác minh.

12.5.2.2  Đầu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) ST;

b) tài liệu an toàn phát triển.

Ngoài ra, người đánh giá có thể cần phải kiểm tra các khả năng chuyển giao khác để xác định rằng kiểm soát an toàn được xác định rõ và tuân thủ. Cụ thể, người đánh giá có thể cần phải kiểm tra tài liệu quản lý cấu hình của nhà phát triển (đầu vào cho đánh giá của hoạt động con (ALC_CMC.4) "hỗ trợ sản xuất và thủ tục chấp thuận" và đánh giá của hoạt động con (ALC_CMS.4) "Vấn đề theo dõi CM bảo hiểm"). Bằng chứng cho thấy các thủ tục đang được áp dụng cũng được yêu cầu.

12.5.2.3  Hành động ALC_DVS.2.1E

TCVN 8709-3 (ISO/IEC 15408-3) ALC_DVS.2.1C: Tài liệu an toàn phát triển cn 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 thiết để đảm bảo tính bảo mật và 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ó.

12.5.2.3.1  Đơn vị công việc ALC_DVS.2-1

Người đánh giá cần xem xét các tài liệu an toàn phát triển để xác định rằng nó mô tả chi tiết tất cả các biện pháp an toàn được sử dụng trong môi trường phát triển là cần thiết để đảm bảo tính bảo mật và toàn vẹn của việc thiết kế và thực hiện TOE.

Người đánh giá xác định những gì là cần thiết cho lần đầu đề cập đến các ST cho bất kỳ thông tin nào có thể tham gia vào việc xác định bảo vệ cần thiết.

Nếu không có thông tin rõ ràng có sẵn từ ST, người đánh giá cần phải thực hiện xác định các biện pháp cần thiết. Trong trường hợp các biện pháp của nhà phát triển được coi là ít hơn so với những gì là cần thiết, cần cung cấp biện minh rõ ràng cho việc đánh giá dựa trên điểm yếu tiềm ẩn có thể khai thác.

Các loại các biện pháp an toàn sau được xem xét bởi người đánh giá khi kiểm tra các tài liệu:

a) vật lý, ví dụ như kiểm soát truy nhập vật lý được sử dụng để ngăn chặn truy nhập trái phép môi trường phát triển TOE (trong thời gian làm việc bình thường và thời gian khác);

b) thủ tục, ví dụ bao gồm:

• cấp quyền truy nhập môi trường phát triển hoặc các bộ phận cụ thể của môi trường như thiết bị phát triển

thu hồi quyền truy nhập khi một người rời khỏi đội phát triển

• chuyển giao các tài liệu được bảo vệ ra khỏi môi trường phát triển và giữa các địa điểm phát triển khác nhau phù hợp với các thủ tục chấp thuận xác định

• thừa nhận và đưa khách hàng tới môi trường phát triển

• vai trò và trách nhiệm trong việc đảm bảo tiếp tục áp dụng các biện pháp an toàn và phát hiện các vi phạm an toàn;

c) nhân sự, ví dụ như bất kỳ kiểm soát hoặc kiểm tra được thực hiện để thiết lập sự tin cậy của nhân viên phát triển mới;

d) các biện pháp an toàn khác, ví dụ như bảo vệ hợp lý các phương tiện phát triển.

Tài liệu an toàn phát triển cn xác định các địa điểm mà tại đó phát triển xảy ra và mô tả các khía cạnh của sự phát triển được thực hiện, cùng với các biện pháp an toàn được áp dụng tại mỗi địa điểm và vận chuyển giữa các địa điểm khác nhau. Ví dụ, phát triển có thể xảy ra ở nhiều cơ sở trong một tòa nhà duy nhất, nhiều tòa nhà tại cùng một địa điểm hoặc nhiều địa điểm. Việc vận chuyển các bộ phận của TOE hoặc TOE chưa hoàn chỉnh giữa các địa điểm phát triển khác nhau phải được bảo đảm bởi an toàn phát triển (ALC_DVS), trong khi đó việc vận chuyển TOE hoàn thành tới cho người tiêu dùng được giải quyết trong chuyển giao (ALC_DEL).

Phát triển bao gồm việc sản xuất TOE.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_DVS.2.2C: Tài liệu an toàn phát triển cần xác minh rằng các biện pháp an toàn cung cấp mức bảo vệ cần thiết nhằm duy trì tính bảo mật và toàn vẹn cho TOE.

12.5.2.3.2  Đơn vị công việc ALC_DVS.2-2

Người đánh giá cần kiểm tra các tài liệu an toàn phát triển đ xác định rằng có một biện minh phù hợp được đưa tại sao các biện pháp an toàn cung cấp mức độ bảo vệ cần thiết để duy trì tính bảo mật và toàn vẹn của TOE.

K từ khi các cuộc tấn công vào TOE hoặc các thông tin liên quan của nó được giả định trong các giai đoạn thiết kế và sản xuất khác nhau, các biện pháp và thủ tục cần phải có một mức độ phù hợp cần thiết để ngăn chặn các cuộc tấn công hoặc tạo ra nhiều khó khăn hơn.

Mức này phụ thuộc vào khả năng tấn công tổng thể cho TOE (cf. thành phần phân tích điểm yếu (AVA_VAN) được chọn), các tài liệu an toàn phát triển phải xác minh mức độ bảo vệ cần thiết để duy trì tính bảo mật và toàn vẹn của TOE. Mức độ này có đạt được bởi các các biện pháp an toàn được áp dụng.

Khái niệm về các biện pháp bảo vệ cần phải nhất quán và việc biện minh nên bao gồm một phân tích về cách thức các biện pháp hỗ trợ lẫn nhau. Tt c các khía cạnh của sự phát triển và sản xuất tại tất cả các địa điểm khác nhau với tất cả các vai trò có liên quan đến việc chuyn giao của TOE cần được phân tích.

Biện minh có thể bao gồm một phân tích về các điểm yếu tiềm ẩn áp dụng các biện pháp an toàn.

Các lập luận thuyết phục chỉ ra rằng, ví dụ:

• Các biện pháp kỹ thuật và cơ chế về cơ sở hạ tng của nhà phát triển đủ để duy trì mức độ an toàn phù hợp (ví dụ như cơ chế mã hóa cũng như các cơ chế bảo vệ vật lý, tính chất của hệ thống CM (cf. ALC_CMC.4-5));

• Các hệ thống có chứa quá trình triển khai thực hiện TOE (kể c các tài liệu hướng liên quan) cung cấp bảo vệ có hiệu quả chng lại các cuộc tấn công hợp lý, ví dụ như bởi mã "Trojan" hoặc virus. Sẽ là đầy đủ, nếu mô tả thực hiện được giữ trên một hệ thống được cô lập nơi mà chỉ có các phần mềm cần thiết để bảo quản nó được cài đặt và không cài đặt phần mềm khác sau đó.

• Dữ liệu được đưa vào hệ thống này cần phải được xem xét cn thận để ngăn chặn việc cài đặt các chức năng ẩn vào hệ thng. Hiệu quả của biện pháp này cần phải được kiểm tra, ví dụ bằng cách kiên trì thực hiện độc lập để có được quyền truy nhập vào máy tính, cài đặt một số phần mềm bổ sung (chương trình, macro v.v.) hoặc lấy một số thông tin trên máy tính sử dụng cho các cuộc tấn công hợp .

• Các biện pháp tổ chức phù hợp (thủ tục và nhân sự) được thực thi vô điều kiện.

12.5.2.3.3  Đơn vị công việc ALC_DVS.2-3

Người đánh giá cần kiểm tra các chính sách tích hợp và bảo mật phát triển để xác định tính đầy đủ của các biện pháp an toàn được sử dụng.

Người đánh giá cần xem xét liệu các điều sau đây có bao gồm trong các chính sách:

a) các thông tin nào liên quan đến việc phát triển TOE cần được giữ bí mật và các nhân viên đội phát triển được phép truy nhập các nguyên vật liu đó;

b) các tài liệu nào phải được bảo vệ tránh sự sửa đổi trái phép để đảm bảo sự toàn vẹn của TOE và các nhân viên đội phát triển được phép được phép sửa đổi các tài liệu này.

Người đánh giá cần xác định rằng các chính sách này đã được mô tả trong tài liệu an toàn phát triển, rằng các biện pháp an toàn được sử dụng là nhất quán với các chính sách và rằng chúng là đầy đủ.

Cần lưu ý rằng các thủ tục quản lý cấu hình sẽ giúp bảo vệ sự toàn vẹn của TOE và đánh giá nên tránh chồng chéo với các đơn vị công việc áp dụng cho khả năng CM (ALC_CMC). Ví dụ, tài liệu CM có thể mô tả các thủ tục an toàn cần thiết cho việc kiểm soát các vai trò hoặc cá nhân có quyền truy nhập môi trường phát triển và những người có thể thay đổi TOE.

Trong khi đó, khả năng CM (ALC_CMC) được yêu cầu cố định, thì đối với an toàn phát triển (ALC_DVS), ch yêu cầu có biện pháp cần thiết, phụ thuộc vào bản chất của TOE và thông tin đó có thể được cung cấp trong ST. Ví dụ, ST có thể nhận dạng một mục tiêu an toàn cho môi trường phát triển đòi hỏi TOE được phát triển bởi các nhân viên có kiến thức rõ ràng về an toàn. Người đánh giá sau đó sẽ xác định rằng một chính sách như vậy đã được áp dụng theo hoạt động con này.

12.5.2.4  Hành động ALC_DVS.2.2E

12.5.2.4.1  Đơn vị công việc ALC_DVS.2-4

Người đánh giá cần kiểm tra tài liệu an toàn phát triển và bằng chứng liên quan đến xác định rằng các biện pháp an toàn đang được áp dụng.

Đơn vị công việc này đòi hi người đánh giá xác định rằng các biện pháp an toàn được mô tả trong tài liệu phát triển an toàn đang được tuân thủ, chẳng hạn như tính toàn vẹn của TOE và tính bảo mật của các tài liệu liên quan đang được bảo vệ đầy đủ. Ví dụ, điều này có thể được xác định bằng kiểm tra các bằng chứng tài liệu được cung cấp. Bằng chứng tài liệu cần được bổ sung bằng cách đi thực tế môi trường phát triển. Thực tế môi trường phát triển sẽ cho phép người đánh giá:

a) quan sát việc áp dụng các biện pháp an toàn (ví dụ như các biện pháp vật lý);

b) kiểm tra bằng chứng tài liệu về việc áp dụng thủ tục;

c) phỏng vấn nhân viên phát triển để kiểm tra kiến thức về các chính sách và thủ tục an toàn phát triển và trách nhiệm của họ.

Thực tế địa điểm phát triển là một phương tiện hữu ích đạt được sự tin cậy trong các biện pháp đang được sử dụng. Bất kỳ quyết định nào dẫn đến việc không thực hiện đi thực tế đa điểm phát triển như vậy cần được xác định trong thảo luận với tổ chức đánh giá.

Để biết thông tin về các địa điểm phát triển, xem A.4: các địa điểm thực thế.

12.6  Khắc phục sai sót (ALC_FLR)

12.6.1  Đánh giá hoạt động con (ALC_FLR.1)

12.6.1.1  Mục tiêu

Mục tiêu của hoạt động con này là đ xác định xem liệu nhà phát triển đã thiết lập các thủ tục khắc phục sai sót để mô tả việc theo dõi các sai sót an toàn, chỉ ra các hành động khắc phục chính xác và các phân phối thông tin các hành động khắc phục chính xác đến người sử dụng TOE.

12.6.1.2  Đu vào

Các bằng chứng đánh giá cho hoạt động con này là:

a) tài liệu hướng dẫn thủ tục khắc phục sai sót.

12.6.1.3  Hành động ALC_FLR.1.1E

TCVN 8709-3 (ISO/IEC 15408-3) ALC_FLR.1.1C: Tài liệu các thủ tục khắc phục sai sót cần mô tả các th tục được sử dụng để theo dõi tất cả các sai sót an toàn đã báo cáo trong từng phiên bản phát hành của TOE.

12.6.1.3.1  Đơn vị công việc ALC_FLR.1-1

Người đánh giá cần kiểm tra tài liệu hướng các thủ tục khắc phục sai sót để xác định rằng nó mô tả các thủ tục được sử dụng để theo dõi tất cả các sai sót an toàn được báo cáo trong từng phiên bản phát hành của TOE.

Các thủ tục mô tả các hành động được thực hiện bởi nhà phát triển từ thời gian từng sai sót an toàn khả nghi được báo cáo đến thời gian nó được giải quyết. Điều này bao gồm toàn bộ khung thời gian của sai sót từ phát hiện ban đầu thông qua việc xác định chắc chn rằng sai sót này là một sai sót an toàn đến lúc giải quyết các sai sót an toàn.

Nếu một sai sót được phát hiện không phải là sai sót an toàn có liên quan, thì không cần thiết (cho mục đích của các yêu cầu khắc phục sai sót (ALC_FLR)) phải tiếp tục theo dõi bởi các thủ tục khắc phục sai sót, mà ch cần giải thích lý do tại sao các sai sót không phải là sai sót an toàn có liên quan.

Khi các yêu cầu này là không bắt buộc mà có thể là một phương tiện chung để người dùng TOE báo cáo các sai sót an toàn, họ không bắt buộc rằng tất c các sai sót an toàn báo cáo cần được theo dõi. Nghĩa là, sai sót an toàn được thông báo không thể bỏ qua một cách đơn giản chỉ vì nó xuất phát từ bên ngoài tổ chức của nhà phát triển.

TCVN 8709-3 (ISO/IEC 15408-3) ALC_FLR.1.2C: Các thủ tục khắc phục sai sót cần yêu cầu rằng việc mô tả bản chất và ảnh hưởng của từng sai sót an toàn được cung cấp, cũng như các trạng thái tìm kiếm việc hiệu chỉnh sai sót đó.

12.6.1.3.2  Đơn vị công việc ALC_FLR.1-2

Người đánh giá cần kiểm tra các thủ tục khắc phục sai sót để xác định rằng việc áp dụng các thủ tục này sẽ tạo ra một mô tả của từng sai sót an toàn trong các giới hạn về bản chất và ảnh hưởng của nó.

Các thủ tục chỉ ra các hành động được thực hiện bởi nhà phát triển để mô tả bản chất và ảnh hưởng của từng sai sót an toàn đầy đủ chi tiết để có thể tái tạo nó. Các mô tả về bản chất của một sai sót an toàn để xem nó là lỗi trong tài liệu hướng dẫn, sai sót trong thiết kế của TSF hay là sai sót trong việc thực hiện TSF, v.v. Các mô tả về ảnh hưởng của sai sót an toàn chỉ ra các phần của TSF bị ảnh hưởng