Lời nói đầu
\r\n\r\nTCVN 8709-3:2011 hoàn toàn tương đương\r\nISO/IEC 15408-3:2008
\r\n\r\nTCVN 8709-3:2011 do Trung tâm Ứng cứu khẩn\r\ncấp máy tính Việt Nam biên soạn, Bộ Thông tin và Truyền thông đề nghị, Tổng cục\r\nTiêu chuẩn Đo lường Chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố.
\r\n\r\nLời giới thiệu
\r\n\r\nCác thành phần đảm bảo an toàn như định nghĩa\r\ntrong tiêu chuẩn này của TCVN 8709 là cơ sở cho các yêu cầu đảm bảo an toàn\r\nđược biểu thị trong một Hồ sơ bảo vệ (PP) hoặc một Đích An toàn (ST).
\r\n\r\nCác yêu cầu này tạo thành một cách thức chuẩn\r\nđể biểu thị các yêu cầu đảm bảo cho một Đích đánh giá (TOE). Phần này của tiêu\r\nchuẩn TCVN 8709 liệt kê danh mục các thành phần, các họ và lớp đảm bảo. Tiêu\r\nchuẩn TCVN 8709-3 cũng đồng thời xác định các tiêu chí đánh giá cho các PP và\r\ncác ST, biểu thị các mức đảm bảo đánh giá dùng để xác định các thang bậc mà\r\nTCVN 8709 định trước cho việc đánh giá tính đảm bảo của các T, còn lại là các\r\nMức đảm bảo đánh giá (EAL).
\r\n\r\nĐối tượng của tiêu chuẩn này bao gồm các\r\nkhách hàng, nhà phát triển và đánh giá viên cho các sản phẩm công nghệ thông\r\ntin (CNTT) an toàn. Tiêu chuẩn TCVN 8709-1 cung cấp thông tin bổ sung về các\r\nđối tượng mục tiêu của bộ tiêu chuẩn TCVN 8709, và về khả năng các nhóm đối\r\ntượng sử dụng TCVN 8709. Các nhóm này có thể gồm:
\r\n\r\na) Các khách hàng, sử dụng phần này của TCVN\r\n8709 khi chọn lựa các thành phần để biểu thị các yêu cầu đảm bảo nhằm thỏa mãn\r\ncác mục tiêu an toàn đã biểu thị trong một PP hoặc ST, xác định các mức đảm bảo\r\nan toàn cho TOE theo yêu cầu.
\r\n\r\nb) Nhà phát triển, phản ánh lại thực tế hoặc\r\nnhận thức được các yêu cầu an toàn của khách hàng để thiết kế TOE, tham chiếu\r\nphần này của TCVN 8709 để diễn đạt các yêu cầu đảm bảo và xác định các phương\r\nthức đảm bảo cho các TOE.
\r\n\r\nc) Đánh giá viên, sử dụng các yêu cầu đảm bảo\r\nđịnh nghĩa trong phần này của TCVN 8709 như một tuyên bố bắt buộc về các tiêu\r\nchí đánh giá khi xác định tính đảm bảo của các TOE và khi đánh giá các PP và\r\ncác ST.
\r\n\r\n\r\n\r\n
Tiêu chuẩn này định nghĩa các yêu cầu đảm bảo\r\ncho bộ tiêu chuẩn. Tiêu chuẩn này gồm các mức đảm bảo đánh giá (EAL) dùng để\r\nxác định một cấp độ đo lường đảm bảo cho các TOE thành phần; các gói đảm bảo\r\ntổng hợp (CAP) dùng để xác định một cấp độ đo lường mức đảm bảo cho các TOE\r\ntổng hợp; các thành phần đảm bảo riêng biệt dùng cho việc tổng hợp các mức đảm\r\nbảo và các gói, và các tiêu chí đánh giá cho các PP và ST.
\r\n\r\n\r\n\r\nTài liệu viện dẫn sau đây không thể thiếu\r\nđược khi áp dụng tài liệu tiêu chuẩn này:
\r\n\r\nTCVN 8709-1, “Công nghệ thông tin - Các kỹ\r\nthuật an toàn - Các tiêu chí đánh giá an toàn CNTT - Phần 1: Giới thiệu và mô\r\nhình tổng quát”.
\r\n\r\nTCVN 8709-2, “Công nghệ thông tin - Các kỹ\r\nthuật an toàn - Các tiêu chí đánh giá an toàn CNTT - Phần 2: Các thành phần\r\nchức năng an toàn”.
\r\n\r\nCác thuật ngữ, định nghĩa, ký hiệu và các từ\r\nviết tắt được nêu trong TCVN 8709-1.
\r\n\r\n\r\n\r\n4.1. Bố cục của tiêu chuẩn
\r\n\r\nĐiều 5 mô tả mô hình sử dụng trong các yêu\r\ncầu đảm bảo an toàn thuộc phần này của TCVN 8709.
\r\n\r\nĐiều 6 mô tả cấu trúc trình bày của các lớp,\r\nhọ, thành phần, các mức đảm bảo đánh giá trong mối quan hệ giữa chúng và cấu\r\ntrúc của các gói đảm bảo tổng hợp, nêu đặc trưng các lớp và họ đảm bảo dùng\r\ntrong các điều từ 9 đến điều 16.
\r\n\r\nĐiều 7 cung cấp các định nghĩa chi tiết về\r\ncác mức bảo đảm đánh giá (EAL).
\r\n\r\nĐiều 8 cung cấp các định nghĩa chi tiết về\r\ncác gói đảm bảo tổng hợp (CAP).
\r\n\r\nĐiều 9 đến điều 16 cung cấp các định nghĩa\r\nchi tiết các lớp đảm bảo của tiêu chuẩn TCVN 8709-3.
\r\n\r\nPhụ lục A giải thích thêm và cung cấp các ví\r\ndụ về các khái niệm bên trong lớp phát triển.
\r\n\r\nPhụ lục B giải thích các khái niệm bên trong\r\ncác đánh giá cho TOE tổng hợp và các lớp tổng hợp.
\r\n\r\nPhụ lục C tóm lược các liên thuộc giữa các\r\nthành phần đảm bảo.
\r\n\r\nPhụ lục D cung cấp một bảng tham chiếu chéo\r\ngiữa các hồ sơ bảo vệ (PP) và các họ cũng như các thành phần của lớp APE.
\r\n\r\nPhụ lục E cung cấp một bảng tham chiếu chéo\r\ngiữa các mức đảm bảo đánh giá (EAL) và các thành phần đảm bảo.
\r\n\r\nPhụ lục F cung cấp một bảng tham chiếu chéo\r\ngiữa các gói đảm bảo tổng hợp (CAP) và các thành phần đảm bảo.
\r\n\r\n\r\n\r\nMục đích của điều này là trình bày triết lý\r\nnền tảng của TCVN 8709 trong việc đảm bảo. Hiểu được điều này, độc giả sẽ hiểu\r\nđược sở cứ của các yêu cầu đảm bảo trong TCVN 8709-3.
\r\n\r\n5.1. Triết lý của TCVN 8709
\r\n\r\nTriết lý TCVN 8709 thể hiện ở chỗ các nguy cơ\r\nmất an toàn và xâm hại cam kết chính sách an toàn của tổ chức cần được thể hiện\r\nrõ ràng và các biện pháp an toàn đã đề xuất cần biểu thị đầy đủ các mục đích dự\r\nkiến của chúng.
\r\n\r\nMặt khác, các biện pháp cần được chọn để giảm\r\nthiểu khả năng điểm yếu, khả năng sử dụng một điểm yếu (ví dụ cố ý lợi dụng\r\nhoặc vô ý gây ra), và phạm vi thiệt hại có thể xảy ra từ việc một điểm yếu bị\r\nsử dụng. Ngoài ra, các biện pháp cần được chọn sao cho thuận tiện việc nhận\r\ndiện tiếp tục các điểm yếu và giảm bớt, hạn chế và/hoặc thông báo về việc một\r\nđiểm yếu đã bị lợi dụng hoặc bị khai thác.
\r\n\r\n5.2. Tiếp cận đảm bảo
\r\n\r\nTriết lý của bộ tiêu chuẩn là cung cấp sự đảm\r\nbảo dựa trên một phép đánh giá (kiểm tra một cách tích cực) sản phẩm CNTT để có\r\nthể đưa ra tính tin cậy. Đánh giá là phương thức truyền thống để bảo đảm và là\r\ncơ sở cho các tài liệu tiêu chí đánh giá trước đó. Tương tự với các phương thức\r\nđã có, TCVN 8709 kế thừa triết lý trước đó. TCVN 8709 đưa ra định mức giá trị\r\npháp lý của văn bản và các sản phẩm CNTT bởi các chuyên gia đánh giá với mức\r\nnhấn mạnh tăng dần về phạm vi, mức chuyên sâu và tính chặt chẽ.
\r\n\r\nTCVN 8709 không loại trừ và cũng không diễn\r\ngiải các đặc điểm liên quan của các phương thức đảm bảo khác. Nghiên cứu của\r\nTCVN 8709 tiếp tục theo hướng tìm các đường khác nhau để đạt được sự bảo đảm.\r\nKết quả là những phương thức khác đạt được từ các hoạt động nghiên cứu sẽ được\r\nxem xét đưa vào TCVN 8709, và tiêu chuẩn này được cấu trúc để cho phép cập nhật\r\nthêm các phương thức mới.
\r\n\r\n5.2.1. Tầm quan trọng của các điểm yếu
\r\n\r\nGiả thiết rằng có các tác nhân đe dọa đang\r\ntích cực tìm kiếm cơ hội khai thác để xâm phạm các chính sách an toàn kể cả\r\ntheo ý tốt và ý xấu, song đều là các hành động không an toàn. Các tác nhân đe\r\ndọa này có thể ngẫu nhiên lôi ra các điểm yếu an toàn, gây hại cho tổ chức. Do\r\nnhu cầu xử lý các thông tin nhạy cảm và do thiếu các sản phẩm đủ tin cậy, luôn\r\ntồn tại rủi ro do lỗi của CNTT. Nghĩa là, các lỗ hỗng an toàn CNTT có thể dẫn\r\nđến mất mát đáng kể.
\r\n\r\nCác lỗ hổng an toàn CNTT xuất hiện thông qua việc\r\nkhai thác có chủ ý hoặc vô tình làm phát sinh các điểm yếu khi ứng dụng CNTT\r\nvào hoạt động liên quan.
\r\n\r\nCần có các bước thực hiện nhằm chống lại các\r\nđiểm yếu phát sinh trong các sản phẩm CNTT. Trong các bước này, các điểm yếu\r\ncần được:
\r\n\r\na) loại bỏ - nghĩa là cần có các bước thực\r\nhiện tích cực nhằm vạch rõ, xóa bỏ hoặc vô hiệu hóa mọi điểm yếu có tác dụng;
\r\n\r\nb) giảm thiểu - nghĩa là cần có các bước thực\r\nhiện tích cực nhằm giảm bớt, đến một mức độ chấp nhận được, ảnh hưởng có thể\r\nkhi một điểm yếu bất kỳ được khai thác;
\r\n\r\nc) theo dõi - nghĩa là cần có các bước thực\r\nhiện tích cực nhằm đảm bảo mọi cố gắng khai thác một điểm yếu hiện hữu sẽ bị\r\nphát hiện và thiệt hại gây ra bị hạn chế;
\r\n\r\n5.2.2. Nguyên nhân của các điểm yếu
\r\n\r\nCác điểm yếu có thể nảy sinh qua các lỗi\r\ntrong:
\r\n\r\na) các yêu cầu - nghĩa là, một sản phẩm CNTT\r\ncó thể có mọi chức năng và đặc trưng theo yêu cầu đối với chúng, song luôn chứa\r\ncác điểm yếu thể hiện chúng không phù hợp hoặc không hiệu quả về góc độ an\r\ntoàn;
\r\n\r\nb) phát triển - nghĩa là, một sản phẩm CNTT\r\nkhông đáp ứng các đặc tả và các điểm yếu nảy sinh là kết quả của các chuẩn phát\r\ntriển không đủ hoặc lựa chọn thiết kế không phù hợp;
\r\n\r\nc) khai thác - nghĩa là, một sản phẩm CNTT đã\r\nđược thiết kế phù hợp cho đặc tả đúng song các điểm yếu có thể nảy sinh là kết\r\nquả của việc kiểm soát hoạt động không phù hợp.
\r\n\r\n5.2.3. Đảm bảo trong bộ TCVN 8709
\r\n\r\nĐảm bảo là cơ sở cho tính tin cậy mà một sản\r\nphẩm CNTT cần thỏa mãn các mục tiêu an toàn của chúng. Đảm bảo có thể nhận được\r\ntừ tham chiếu tới các nguồn như các xác nhận không có minh chứng, kinh nghiệm\r\nliên quan trước đó, hoặc kinh nghiệm xác định nào đó. Tuy nhiên, TCVN 8709 cung\r\ncấp sự đảm bảo thông qua điều tra tích cực. Điều tra tích cực là một cách đánh\r\ngiá các sản phẩm CNTT nhằm xác định các đặc tính an toàn của chúng.
\r\n\r\n5.2.4. Đảm bảo thông qua đánh giá
\r\n\r\nĐánh giá là phương thức truyền thống để đạt\r\nđược sự đảm bảo, và là cơ sở của phương pháp TCVN 8709. Các kỹ thuật đánh giá\r\ncó thể bao gồm song không hạn chế các nội dung sau:
\r\n\r\na) Phân tích và kiểm tra các tiến trình và\r\ncác thủ tục;
\r\n\r\nb) Kiểm tra hiện trạng áp dụng các tiến trình\r\nvà các thủ tục;
\r\n\r\nc) Phân tích tính tương hợp giữa các mô tả\r\nthiết kế TOE;
\r\n\r\nd) Phân tích mô tả thiết kế TOE so với các\r\nyêu cầu;
\r\n\r\ne) Kiểm tra các bằng chứng;
\r\n\r\nf) Phân tích các tài liệu hướng dẫn;
\r\n\r\ng) Phân tích các phép đo kiểm tra chức năng\r\nđã thiết lập và các kết quả đạt được;
\r\n\r\nh) Kiểm thử chức năng độc lập;
\r\n\r\ni) Phân tích các điểm yếu (bao gồm các giả\r\nthiết về khiếm khuyết);
\r\n\r\nj) Kiểm thử độ thẩm thấu;
\r\n\r\n5.3. Cấp độ đảm bảo đánh giá của bộ TCVN 8709
\r\n\r\nTriết lý của TCVN 8709 xác nhận rằng khi có\r\nnhiều nỗ lực đánh giá hơn thì sẽ đạt được các kết quả bảo đảm hơn, đích đặt ra\r\nlà áp dụng nỗ lực tối thiểu theo yêu cầu để đưa ra mức độ đảm bảo cần thiết.\r\nMức độ tăng dần các nỗ lực dựa vào:
\r\n\r\na) Phạm vi - nghĩa là nỗ lực nhiều hơn do một\r\nphần lớn hơn của sản phẩm CNTT được xem xét;
\r\n\r\nb) Chuyên sâu - nghĩa là nỗ lực nhiều hơn do\r\ncần triển khai một mức thiết kế và triển khai chi tiết hơn;
\r\n\r\nc) Chặt chẽ - nghĩa là nỗ lực nhiều hơn do\r\nphải áp dụng theo một phương thức bắt buộc có cấu trúc hơn.
\r\n\r\nCác điều khoản con sau đây mô tả các kết cấu\r\nsử dụng để biểu thị các lớp, thành phần và các họ đảm bảo.
\r\n\r\nHình 1 trình bày các yêu cầu đảm bảo (SAR)\r\nđược xác định trong tiêu chuẩn này (TCVN 8709-3). Lưu ý rằng tập hợp trừu tượng\r\nnhất của các yêu cầu đảm bảo SAR được coi là một lớp. Mỗi lớp chứa các họ đảm\r\nbảo, mỗi họ lại chứa các thành phần đảm bảo, còn thành phần thì chứa các phần\r\ntử đảm bảo. Các lớp và các họ được dùng để cung cấp một tập hợp phân loại các\r\nyêu cầu đảm bảo, còn các thành phần dùng để đặc tả các yêu cầu đảm bảo SAR\r\ntrong một PP/ST.
\r\n\r\n6.1.1. Cấu trúc lớp đảm bảo
\r\n\r\nHình 1 biểu diễn cấu trúc lớp đảm bảo.
\r\n\r\n6.1.1.1. Tên lớp
\r\n\r\nMỗi lớp đảm bảo được gán một tên duy nhất.\r\nTên biểu thị các chủ đề nêu trong lớp đảm bảo.
\r\n\r\nMột dạng viết tắt thống nhất cho tên lớp đảm\r\nbảo cũng được cung cấp. Đây là phương thức cơ bản để tham chiếu tới lớp đảm\r\nbảo. Quy ước đặt ra là một chữ “A” nối tiếp bởi 2 chữ cái biểu thị tên lớp.
\r\n\r\n6.1.1.2. Giới thiệu lớp
\r\n\r\nMỗi lớp đảm bảo có một điều khoản nhỏ giới\r\nthiệu nhằm mô tả tập hợp của lớp và chứa thông tin hỗ trợ về mục đích của lớp.
\r\n\r\n6.1.1.3. Các họ đảm bảo
\r\n\r\nMỗi lớp đảm bảo chứa ít nhất một họ đảm bảo.\r\nCấu trúc của các họ đảm bảo được mô tả trong điều khoản sau đây.
\r\n\r\n![](\"00907948_files/image001.jpg\")
6.1.2. Cấu trúc họ đảm bảo
\r\n\r\nHình 1 mô tả cấu trúc họ đảm bảo.
\r\n\r\n6.1.2.1. Tên họ
\r\n\r\nMỗi họ đảm bảo được gán một tên duy nhất. Tên\r\ncung cấp thông tin mô tả về các chủ đề nêu trong họ đảm bảo. Mỗi họ đảm bảo\r\nđược đặt trong lớp đảm bảo có chứa các họ khác với cùng mục đích.
\r\n\r\nMột dạng viết tắt thống nhất cho tên họ đảm\r\nbảo cũng được cung cấp. Đây là phương thức cơ bản để tham chiếu tới họ đảm bảo.\r\nQuy ước đặt ra là sử dụng dạng viết tắt của tên lớp nối tiếp bởi một gạch dưới,\r\ntiếp đó là 3 chữ cái biểu thị tên họ.
\r\n\r\n6.1.2.2. Các mục tiêu
\r\n\r\nĐiều khoản các mục tiêu của họ đảm bảo biểu\r\nthị mục đích của họ đảm bảo.
\r\n\r\nĐiều khoản này mô tả các mục tiêu, cụ thể là\r\ncác mục tiêu liên quan trong mô hình đảm bảo của TCVN 8709 mà họ này sẽ đề cập\r\nđến. Việc mô tả cho một họ đảm bảo được duy trì ở một mức tổng quát. Mọi chi\r\ntiết đặc trưng theo yêu cầu của các mục tiêu được kết hợp trong một thành phần\r\nđảm bảo riêng.
\r\n\r\n6.1.2.3. Phân mức thành phần
\r\n\r\nMỗi họ đảm bảo chứa một hoặc nhiều thành phần\r\nđảm bảo. Điều khoản này của họ đảm bảo mô tả các thành phần sẵn có và giải\r\nthích sự khác biệt giữa chúng. Mục đích chính của chúng là nhằm phân biệt giữa\r\ncác thành phần đảm bảo một khi đã xác định rằng họ đảm bảo là một phần hữu ích\r\nvà cần thiết cho các yêu cầu đảm bảo (SAR) của một PP/ST.
\r\n\r\nCác họ đảm bảo chứa nhiều hơn một thành phần\r\nđược phân mức và sở cứ được cung cấp về việc phân mức các thành phần như thế\r\nnào. Sở cứ này gồm phạm vi, chiều sâu và/hoặc tính chặt chẽ.
\r\n\r\n6.1.2.4. Chú thích ứng dụng
\r\n\r\nĐiều khoản về chú thích ứng dụng của họ đảm\r\nbảo, nếu có, sẽ chứa thông tin bổ trợ thêm cho họ đảm bảo. Thông tin này cần\r\nthể hiện sự quan tâm cụ thể cho những người sử dụng họ đảm bảo (ví dụ các chủ\r\nthể PP hoặc ST, các nhà thiết kế TOE, những đánh giá viên). Việc biểu diễn\r\nthông tin là không bắt buộc và bao gồm, ví dụ như các cảnh báo về giới hạn và\r\nphạm vi sử dụng, trong đó cần có những lưu ý đặc biệt.
\r\n\r\n6.1.2.5. Các thành phần đảm bảo
\r\n\r\nMỗi họ đảm bảo có ít nhất một thành phần đảm\r\nbảo. Cấu trúc của các thành phần đảm bảo được cung cấp ở điều khoản con sau\r\nđây.
\r\n\r\n6.1.3. Cấu trúc thành phần đảm bảo
\r\n\r\nHình 2 biểu diễn cấu trúc thành phần đảm bảo
\r\n\r\n![](\"00907948_files/image002.jpg\")
Mối quan hệ giữa các thành phần trong một họ\r\nđược nhấn mạnh qua quy ước viết đậm. Các phần này của các yêu cầu là mới, cải\r\ntiến hoặc hiệu chỉnh theo các yêu cầu của thành phần trước đó trong phân lớp\r\ncấu trúc đã nhấn mạnh.
\r\n\r\n6.1.3.1. Định danh thành phần
\r\n\r\nĐiều khoản định danh thành phần cung cấp các\r\nthông tin mô tả cần thiết để định danh, phân nhóm, đăng ký và tham chiếu cho\r\nmột thành phần.
\r\n\r\nMỗi thành phần đảm bảo được gán một tên duy\r\nnhất. Tên cung cấp thông tin mô tả về các chủ đề nêu trong thành phần đảm bảo.\r\nMỗi thành phần đảm bảo được đặt trong họ đảm bảo có chia sẻ mục tiêu an toàn\r\ncủa chúng.
\r\n\r\nMột dạng viết tắt thống nhất cho tên thành\r\nphần đảm bảo cũng được cung cấp. Đây là phương thức cơ bản để tham chiếu tới\r\nthành phần đảm bảo. Quy ước đặt ra là sử dụng dạng viết tắt của tên họ nối tiếp\r\nbởi một thời kỳ và tiếp đó là một ký tự số. Các ký tự số cho các thành phần bên\r\ntrong một họ được gán tuần tự, bắt đầu từ 1.
\r\n\r\n6.1.3.2. Các mục tiêu
\r\n\r\nĐiều khoản các mục tiêu của thành phần đảm\r\nbảo, nếu có, sẽ chứa các mục tiêu đặc trưng cho thành phần đảm bảo cụ thể. Đối\r\nvới các thành phần đảm bảo có điều khoản con này, điều khoản sẽ biểu thị mục\r\nđích đặc trưng của thành phần và giải thích chi tiết về các mục tiêu.
\r\n\r\n6.1.3.3. Chú thích ứng dụng
\r\n\r\nĐiều khoản về chú thích ứng dụng của thành\r\nphần đảm bảo, nếu có, sẽ chứa thông tin bổ trợ thêm cho phép sử dụng thành\r\nphần.
\r\n\r\n6.1.3.4. Các mối phụ thuộc
\r\n\r\nCác mối phụ thuộc giữa các thành phần đảm bảo\r\nnảy sinh khi một thành phần không tự nó tồn tại mà phải dựa trên sự hiện diện\r\ncủa thành phần khác.
\r\n\r\nMỗi thành phần đảm bảo cung cấp một danh sách\r\nđầy đủ các mối phụ thuộc với các thành phần đảm bảo khác. Một vài thành phần có\r\nthể liệt kê “không phụ thuộc” để chỉ ra sự không phụ thuộc. Các thành phần phụ\r\nthuộc nêu trên có thể có các mối phụ thuộc trong các thành phần khác.
\r\n\r\nDanh sách phụ thuộc xác định ra tập tối thiểu\r\ncác thành phần đảm bảo mà chúng dựa vào. Các thành phần được phân cấp theo\r\nthành phần trong danh sách phụ thuộc có thể được dùng để thỏa mãn tính phụ\r\nthuộc.
\r\n\r\nTrong một số trường hợp đặc biệt, tính phụ\r\nthuộc đã biểu thị có thể không áp dụng được. Chủ thể PP/ST có thể tùy chọn\r\nkhông thỏa mãn tính phụ thuộc này thông qua việc cung cấp sở cứ tại sao các mối\r\nphụ thuộc đã cho không áp dụng được.
\r\n\r\n6.1.3.5. Các thành phần đảm bảo
\r\n\r\nMột tập các thành phần đảm bảo được cung cấp\r\ncho mỗi thành phần đảm bảo. Một phần tử đảm bảo là một yêu cầu an toàn và nếu\r\ntiếp tục chia nhỏ, sẽ không cho một kết quả đánh giá có nghĩa. Đó là yêu cầu an\r\ntoàn nhỏ nhất chấp nhận được trong TCVN 8709.
\r\n\r\nMỗi thành phần đảm bảo được xác định là thuộc\r\nmột trong 3 tập các phần tử đảm bảo sau đây:
\r\n\r\na) Phần tử hành động của nhà phát triển: Là\r\ncác hành động cần được thực thi bởi nhà phát triển. Tập các hành động này tiếp\r\ntục được nêu rõ trong tài liệu chứng cứ được tham chiếu trong tập các phần tử\r\nsau đây. Các yêu cầu cho các hành động của nhà phát triển được xác định bởi\r\nviệc thêm chữ cái “D” vào số hiệu phân tử.
\r\n\r\nb) Nội dung và biểu diễn của các phần tử\r\nchứng cứ: là chứng cứ yêu cầu, nghĩa là chứng cứ cần biểu thị gì, thông tin nào\r\ncần có trong chứng cứ. Các yêu cầu về nội dung và biểu diễn chứng cứ được xác\r\nđịnh bởi việc thêm chữ cái “C” vào số hiệu phần tử.
\r\n\r\nc) Các phần tử hành động của đánh giá viên:\r\nLà các hành động cần được thực thi bởi đánh giá viên. Tập các hành động chứa sự\r\nkhẳng định rõ ràng về sự thỏa mãn các yêu cầu đã mô tả trước đó trong Các phần\r\ntử nội dung và trình bày. Nó cũng chứa các hành động và phân tích rõ ràng cần\r\nthực hiện bổ sung thêm cho những gì nhà phát triển đã làm. Các hành động đánh\r\ngiá ngầm định cũng được thực hiện như là kết quả của các phần tử hành động của\r\nnhà phát triển do các hành động này không chứa trong nội dung và biểu diễn của\r\ncác phần tử chứng cứ. Các yêu cầu về hành động của đánh giá viên được xác định\r\nbởi việc thêm chữ cái “E” vào số hiệu phần tử.
\r\n\r\nCác hành động của nhà phát triển, nội dung và\r\nbiểu diễn chứng cứ xác định các yêu cầu đảm bảo được dùng để biểu thị trách\r\nnhiệm của nhà phát triển trong việc biểu diễn sự đảm bảo khi đích đánh giá\r\n(TOE) thỏa mãn các yêu cầu đảm bảo cho một PP hoặc một ST.
\r\n\r\nCác hành động của đánh giá viên xác định\r\ntrách nhiệm của đánh giá viên ở 2 khía cạnh đánh giá. Khía cạnh thứ nhất là\r\ntính hợp lệ của PP/ST, trong tương quan với các lớp APE và ASE trong các điều\r\nkhoản APE: Đánh giá hồ sơ bảo vệ và ASE: Đánh giá đích an toàn. Khía cạnh thứ 2\r\nlà kiểm chứng tính tuân thủ của các TOE với các yêu cầu chức năng (SFR) và yêu\r\ncầu đảm bảo (SAR) của chúng. Qua việc biểu thị PP/ST hợp lệ và các yêu cầu thỏa\r\nmãn bởi TOE, đánh giá viên có thể cung cấp một cơ sở tin cậy rằng TOE giải\r\nquyết vấn đề bảo mật đã được đặt ra trong môi trường xử lý của nó.
\r\n\r\nPhần tử hành động của nhà phát triển, Các\r\nphần tử nội dung và trình bày, và các phần tử hành động rõ ràng của đánh giá\r\nviên sẽ xác định nỗ lực của đánh giá viên cần sử dụng để kiểm chứng các đòi hỏi\r\nan toàn tạo ra trong ST của TOE.
\r\n\r\n6.1.4. Các phần tử đảm bảo
\r\n\r\nMỗi phần tử biểu thị một yêu cầu cần thỏa\r\nmãn. Các công bố yêu cầu này cần rõ ràng, chính xác và không mập mờ. Bởi vậy,\r\nchúng không có các câu phức hợp: mỗi yêu cầu riêng biệt được công bố là một\r\nphần tử riêng.
\r\n\r\n6.1.5. Danh mục các thành phần
\r\n\r\nTrong phần này của TCVN 8709 chứa các lớp của\r\ncác họ và các thành phần, chúng được phân nhóm dựa trên cơ sở của các đảm bảo\r\nliên quan. Tại điểm bắt đầu của mỗi lớp là một đồ thị thông tin về các họ trong\r\nlớp và các thành phần trong mỗi họ.
\r\n\r\n![](\"00907948_files/image003.jpg\")
Trong hình 3 ở trên, lớp được thể hiện với\r\nmột họ duy nhất. Họ này chứa 3 thành phần theo kiến trúc tuyến tính (nghĩa là\r\nthành phần 2 đòi hỏi nhiều hơn thành phần 1 với các biểu thức về hành động đặc\r\ntrưng, chứng cứ đặc trưng, hoặc tính chặt chẽ của các hành động hoặc chứng cứ).\r\nCác họ đảm bảo trong phần này của TCVN 8709 đều thuộc phân lớp tuyến tính, mặc\r\ndù tính tuyến tính không phải là tiêu chí bắt buộc cho các họ đảm bảo có thể bổ\r\nsung thêm trong tương lai.
\r\n\r\n\r\n\r\nHình 4 trình bày các EAL và cấu trúc liên\r\nquan định nghĩa trong tiêu chuẩn này. Lưu ý rằng trong khi hình chỉ ra các nội\r\ndung của các thành phần đảm bảo, thông tin này dự kiến sẽ đưa vào trong một EAL\r\nqua tham chiếu tới các thành phần thực tế được định nghĩa trong TCVN 8709.
\r\n\r\n![](\"00907948_files/image004.jpg\")
6.2.1. Tên EAL
\r\n\r\nMỗi EAL được gán một tên duy nhất. Tên cung\r\ncấp thông tin mô tả về nội dung của EAL.
\r\n\r\nMột dạng viết tắt thống nhất cho tên EAL cũng\r\nđược cung cấp. Đây là phương thức cơ bản để tham chiếu tới EAL.
\r\n\r\n6.2.2. Mục tiêu
\r\n\r\nĐiều khoản mục tiêu của EAL biểu thị mục đích\r\ncủa EAL.
\r\n\r\n6.2.3. Chú thích ứng dụng
\r\n\r\nĐiều khoản về chú thích ứng dụng của EAL, nếu\r\ncó, sẽ chứa thông tin thể hiện sự quan tâm cụ thể cho những người sử dụng EAL\r\n(ví dụ các chủ thể PP hoặc ST, các nhà thiết kế TOE với mục tiêu hướng tới EAL\r\nnày, các đánh giá viên). Việc biểu diễn thông tin là không bắt buộc và bao gồm,\r\nví dụ như các cảnh báo về giới hạn và phạm vi sử dụng, trong đó cần có những\r\nlưu ý đặc biệt.
\r\n\r\n6.2.4. Các thành phần đảm bảo
\r\n\r\nMột tập các thành phần đảm bảo đã được chọn\r\ncho mỗi EAL.
\r\n\r\nMột mức cao của đảm bảo hơn mức được cung cấp\r\nbởi một EAL cho trước có thể đạt được qua:
\r\n\r\na) chứa các thành phần đảm bảo bổ sung từ các\r\nhọ đảm bảo khác hoặc
\r\n\r\nb) thay thế một thành phần đảm bảo với một\r\nthành phần đảm bảo mức cao hơn từ cùng một họ đảm bảo.
\r\n\r\n6.2.5. Mối quan hệ giữa đảm bảo và các mức\r\nđảm bảo
\r\n\r\nHình 5 trình bày mối quan hệ giữa các yêu cầu\r\nđảm bảo (SAR) và các mức đảm bảo xác định trong TCVN 8709. Trong khi các thành\r\nphần đảm bảo tiếp tục phân tách ra thành các phần tử đảm bảo, các phần tử đảm\r\nbảo không thể tham chiếu riêng biệt bởi các mức đảm bảo. Lưu ý rằng mũi tên ở\r\ntrong hình biểu thị tham chiếu từ một EAL đến một thành phần đảm bảo bên trong\r\nlớp nơi nó được xác định.
\r\n\r\n![](\"00907948_files/image005.jpg\")
Cấu trúc của gói đảm bảo tổng hợp (CAP) tương\r\ntự như của các mức đảm bảo đánh giá (EAL). Khác nhau chính giữa chúng là kiểu\r\ncủa đích đánh giá (TOE) mà chúng áp dụng; các EAL áp dụng cho thành phần của\r\nTOE còn CAP áp dụng cho các đích đánh giá tổng hợp.
\r\n\r\nHình 6 trình bày các gói đảm bảo tổng hợp\r\n(CAP) và cấu trúc kết hợp được định nghĩa trong TCVN 8709-3. Lưu ý rằng trong\r\nkhi hình chỉ ra các nội dung của các thành phần đảm bảo, thông tin này dự kiến\r\nsẽ đưa vào trong một CAP qua tham chiếu tới các thành phần thực tế định nghĩa\r\ntrong TCVN 8709.
\r\n\r\n![](\"00907948_files/image006.jpg\")
6.3.1. Tên CAP
\r\n\r\nMỗi CAP được gán một tên duy nhất. Tên cung\r\ncấp thông tin mô tả về nội dung của CAP.
\r\n\r\nMột dạng viết tắt thống nhất cho tên CAP cũng\r\nđược cung cấp. Đây là phương thức cơ bản để tham chiếu tới CAP.
\r\n\r\n6.3.2. Mục tiêu
\r\n\r\nĐiều khoản mục tiêu của CAP biểu thị mục đích\r\ncủa CAP.
\r\n\r\n6.3.3. Chú thích ứng dụng
\r\n\r\nĐiều khoản về chú thích ứng dụng của CAP, nếu\r\ncó, sẽ chứa thông tin thể hiện sự quan tâm cụ thể cho những người sử dụng CAP\r\n(ví dụ các chủ thể PP hoặc ST, những người hợp nhất các TOE tổng hợp với mục\r\ntiêu hướng tới CAP này, các đánh giá viên). Việc biểu diễn thông tin là không\r\nbắt buộc và bao gồm, ví dụ như các cảnh báo về giới hạn và phạm vi sử dụng,\r\ntrong đó cần có những lưu ý đặc biệt.
\r\n\r\n6.3.4. Các thành phần đảm bảo
\r\n\r\nMột tập các thành phần đảm bảo đã được chọn\r\ncho mỗi CAP.
\r\n\r\nMột vài các mối phụ thuộc nhận dạng các hoạt\r\nđộng diễn ra trong khi đánh giá các thành phần phụ thuộc dựa vào hoạt động của\r\nTOE tổng hợp. Nếu không nhận dạng rõ ràng được các mối phụ thuộc trong hoạt\r\nđộng của thành phần phụ thuộc thì các mối phụ thuộc sẽ là một cách đánh giá\r\nkhác của TOE tổng hợp.
\r\n\r\nMột mức cao của đảm bảo hơn mức được cung cấp\r\nbởi CAP cho trước có thể đạt được qua:
\r\n\r\na) chứa các thành phần đảm bảo bổ sung từ các\r\nhọ đảm bảo khác hoặc
\r\n\r\nb) thay thế một thành phần đảm bảo với một\r\nthành phần đảm bảo mức cao hơn từ cùng một họ đảm bảo.
\r\n\r\nCác thành phần kết cấu trong các gói đảm bảo\r\nCAP không nên sử dụng làm phần mở rộng cho các đánh giá thành phần TOE vì nó có\r\nthể cung cấp sự đảm bảo không đầy đủ cho những thành phần đó.
\r\n\r\n6.3.5. Mối quan hệ giữa đảm bảo và các mức\r\nđảm bảo
\r\n\r\nHình 7 trình bày mối quan hệ giữa các yêu cầu\r\nđảm bảo (SAR) và các gói đảm bảo tổng hợp định nghĩa trong TCVN 8709. Trong khi\r\ncác thành phần đảm bảo tiếp tục phân tách ra thành các phần tử đảm bảo, các\r\nphần tử đảm bảo không thể tham chiếu riêng biệt bởi các gói đảm bảo. Lưu ý rằng\r\nmũi tên ở trong hình biểu thị tham chiếu từ CAP đến một thành phần đảm bảo bên\r\ntrong lớp nơi nó được xác định.
\r\n\r\n![](\"00907948_files/image007.jpg\")
Các mức đảm bảo đánh giá (EAL) cung cấp một\r\nthang bậc tăng dần có cân bằng giữa mức độ đảm bảo đạt được với chi phí và tính\r\nkhả thi đạt được cấp độ đảm bảo đó. TCVN 8709 xác định các khái niệm khác nhau\r\nvề đảm bảo trong TOE ở cuối của phần đánh giá, và duy trì sự đảm bảo đó trong\r\nquá trình sử dụng TOE.
\r\n\r\nChú ý quan trọng rằng không phải tất cả các\r\nhọ (families) và các thành phần (components) trong phần này của TCVN 8709 được\r\nbao gồm trong EAL. Điều này không phải nói rằng nó không cung cấp các đảm bảo\r\ncó ý nghĩa và mong muốn. Thay vào đó được mong đợi rằng các họ và thành phần\r\nnày sẽ xem xét thêm vào EAL trong các PP và ST
\r\n\r\nBảng 1 trình bày một tổng kết của EAL. Các\r\ncột thể hiện một tập các EAL sắp xếp từ 1 đến 7, các dòng thể hiện các họ đảm\r\nbảo. Mỗi một số trong ma trận xác định một thành phần đảm bảo cụ thể có thể áp\r\ndụng được.
\r\n\r\nNhư đã nêu ở phần sau, 7 cấp đảm bảo đánh giá\r\nđược định nghĩa phân lớp trong TCVN 8709 nhằm đánh giá mức độ đảm bảo cho một\r\nTOE. Mức đảm bảo tăng lên từ EAL này đến EAL khác được thực hiện bởi việc thay\r\nthế một thành phần đảm bảo có cấp cao hơn từ cùng một họ đảm bảo (ví dụ tăng về\r\ntính chuẩn xác, phạm vi và/hoặc độ sâu) và từ việc thêm vào các thành phần đảm\r\nbảo từ các họ đảm bảo khác (ví dụ như thêm các yêu cầu mới).
\r\n\r\nCác EAL bao gồm một tổ hợp thích hợp các\r\nthành phần đảm bảo như được miêu tả trong phần 6 của TCVN 8709-3. Một cách\r\nchính xác hơn, mỗi EAL bao gồm không hơn một thành phần của mỗi họ bảo đảm và\r\ntất cả sự lệ thuộc đảm bảo của mỗi thành phần được xác định.
\r\n\r\nEAL được định nghĩa trong TCVN 8709, nó có\r\nthể được thể hiện bằng tổ hợp khác của sự đảm bảo. Đặc biệt, khái niệm “sự mở\r\nrộng” (augumentation) cho phép thêm vào các thành phần đảm bảo (từ họ đảm bảo\r\nkhông sẵn sàng trong EAL) hoặc thay thế thành phần đảm bảo (bằng một thành phần\r\nđảm bảo có cấp cao hơn trong cùng một họ đảm bảo) trong một EAL. Xây dựng nên\r\nsự đảm bảo được định nghĩa trong TCVN 8709, thì chỉ EAL có thể được mở rộng.\r\nThuật ngữ “EAL trừ đi một thành phần đảm bảo” không được công nhận bởi chuẩn\r\nnày. Khả năng mở rộng cho phép điều chỉnh tính hữu ích và thêm giá trị vào\r\nthành phần đảm bảo mở rộng trong EAL. Một EAL có thể cũng được mở rộng với các\r\nyêu cầu đảm bảo rõ ràng.
\r\n\r\n| \r\n | \r\n \r\n | \r\n \r\n | \r\n ||||||
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n ||
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
Các phần sau trình bày các định nghĩa của\r\nEAL, nêu rõ sự khác nhau giữa các yêu cầu cụ thể với các diễn tả văn xuôi của\r\ncác yêu cầu đó sử dụng kiểu tô đậm.
\r\n\r\n7.3.1. Mục tiêu
\r\n\r\nEAL1 có thể áp dụng nơi mà tính bí mật trong\r\nhoạt động chính xác được yêu cầu, nhưng nguy cơ an toàn không được xem là quan\r\ntrọng. Nó sẽ có giá trị khi sự bảo đảm độc lập được đòi hỏi để hỗ trợ luận điểm\r\nđã được áp dụng đối với sự bảo vệ thông tin cá nhân hoặc thông tin tương tự.
\r\n\r\nEAL1 chỉ đòi hỏi một đích an toàn giới hạn.\r\nĐơn giản chỉ là tuyên bố các yêu cầu chức năng an toàn (SFR) mà đích đánh giá\r\n(TOE) phải đáp ứng chứ không cần phải diễn giải xuất xứ của chúng xuất phát từ\r\ncác nguy cơ đe dọa.
\r\n\r\nEAL1 đưa ra một đánh giá cho TOE đáp ứng cho\r\nkhách hàng, bao gồm cả kiểm thử độc lập với một bảng mô tả đặc tính, và cung\r\ncấp một văn bản kiểm tra tài liệu hướng dẫn. Ý đồ hướng đến là đánh giá EAL1 có\r\nthể được thực hiện một cách thành công mà không cần sự trợ giúp của nhà phát\r\ntriển TOE, và với chi phí nhỏ nhất.
\r\n\r\nMột đánh giá ở mức này có thể cung cấp bằng\r\nchứng về các chức năng TOE phù hợp với tài liệu của nó.
\r\n\r\n7.3.2. Các thành phần đảm bảo
\r\n\r\nEAL1 đưa ra một mức đảm bảo cơ bản bởi một\r\nđích an toàn giới hạn và sự phân tích các yêu cầu chức năng an toàn (SFR) trong\r\nđó ST sử dụng một đặc tả chức năng và giao diện kèm theo tài liệu hướng dẫn để\r\ndiễn tả hoạt động an toàn.
\r\n\r\nSự phân tích được hỗ trợ bởi việc tìm kiếm\r\nnhững điểm yếu tiềm năng thông báo công khai và kiểm tra độc lập các chức năng\r\ncũng như sự thâm nhập của các chức năng an toàn TOE (các TSF).
\r\n\r\nEAL1 cung cấp sự đảm bảo thông qua việc nhận\r\ndạng duy nhất cho TOE và tài liệu đánh giá liên quan.
\r\n\r\nEAL này có ý nghĩa hơn trong việc đảm bảo đối\r\nvới một sản phẩm CNTT không được đánh giá.
\r\n\r\n| \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n Đặc tả chức năng cơ bản (ADV_FSP.1) \r\n | \r\n
| \r\n | \r\n \r\n Hướng dẫn người dùng vận hành (AGD_OPE.1) \r\n | \r\n
| \r\n Các thủ tục chuẩn bị (AGD_PRE.1) \r\n | \r\n |
| \r\n | \r\n \r\n Dán nhãn TOE (ALC_CMC.1) \r\n | \r\n
| \r\n Tổng quát TOE CM (ALC_CMS.1) \r\n | \r\n |
| \r\n | \r\n \r\n Yêu cầu tuân thủ (ASE_CCL.1) \r\n | \r\n
| \r\n Định nghĩa các thành phần mở rộng\r\n (ASE_ECD.1) \r\n | \r\n |
| \r\n Giới thiệu ST (ASE_INT.1) \r\n | \r\n |
| \r\n Các mục tiêu an toàn cho môi trường vận\r\n hành (ASE_OBJ.1) \r\n | \r\n |
| \r\n Các yêu cầu an toàn đã công bố (ASE_REQ.1) \r\n | \r\n |
| \r\n Đặc tả tóm tắt TOE (ASE_TSS.1) \r\n | \r\n |
| \r\n | \r\n \r\n Kiểm thử độc lập - Tuân thủ (ATE_IND.1) \r\n | \r\n
| \r\n | \r\n \r\n Khảo sát điểm yếu (AVA_VAN.1) \r\n | \r\n
7.4.1. Mục tiêu
\r\n\r\nEAL2 yêu cầu sự hợp tác của nhà phát triển\r\ndưới dạng thông tin thiết kế và các kết quả kiểm tra, nhưng không yêu cầu nhiều\r\nhơn về tính hiệu quả của các bộ phận phát triển so với tính phù hợp thực tế về\r\nthương mại. Như vậy đó không yêu cầu một sự gia tăng về đầu tư chi phí và thời\r\ngian.
\r\n\r\nEAL2 vì vậy có thể áp dụng trong các trường hợp\r\nnhà phát triển và người sử dụng yêu cầu một mức thấp đến trung bình về đảm bảo\r\nan toàn một cách độc lập khi thiếu hồ sơ phát triển đầy đủ. Một tình huống như\r\nvậy có thể xảy ra khi đảm bảo cho các hệ thống kế thừa, hoặc ở nơi truy nhập\r\nđến nhà phát triển có thể bị giới hạn.
\r\n\r\n7.4.2. Các thành phần đảm bảo
\r\n\r\nEAL2 cung cấp sự đảm bảo bằng một đích an\r\ntoàn đầy đủ và thông qua phân tích các đòi hỏi chức năng an toàn (SFR) của ST,\r\nsử dụng một đặc tả chức năng và giao diện, tài liệu hướng dẫn và các mô tả cơ\r\nsở về kiến trúc của TOE để hiểu hành vi an toàn.
\r\n\r\nSự phân tích được hỗ trợ bằng việc kiểm tra\r\nđộc lập các chức năng an toàn TOE, bằng chứng về việc kiểm tra của nhà phát\r\ntriển dựa trên đặc tính chức năng, sự xác nhận độc lập có chọn lọc các kết quả\r\nkiểm tra của nhà phát triển, phân tích những điểm yếu (dựa trên các đặc tính\r\nchức năng, thiết kế TOE, mô tả kiến trúc an toàn và bằng chứng hướng dẫn được\r\ncung cấp) để thể hiện khả năng phản ứng trước một xâm nhập của kẻ tấn công với\r\nmột tiền lực tấn công cơ sở.
\r\n\r\nEAL2 cũng như cung cấp sự đảm bảo thông qua\r\nhệ thống quản lý cấu hình và bằng chứng của các thủ tục chuyển giao an toàn.
\r\n\r\nEAL này thể hiện sự đảm bảo có ý nghĩa hơn so\r\nvới EAL1 bằng việc yêu cầu kiểm tra của nhà phát triển, phân tích lỗ hổng,\r\n(ngoài ra tìm kiếm thông tin công cộng) và kiểm tra độc lập dựa trên đặc tả TOE\r\nchi tiết hơn.
\r\n\r\n| \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n Đặc tả kiến trúc an toàn (ADV_ARC.1) \r\n | \r\n
| \r\n Đặc tả chức năng bắt buộc an toàn\r\n (ADV_FSP.2) \r\n | \r\n |
| \r\n Thiết kế cơ bản (ADV_TDS.1) \r\n | \r\n |
| \r\n | \r\n \r\n Hướng dẫn người dùng vận hành (AGD_OPE.1) \r\n | \r\n
| \r\n Các thủ tục chuẩn bị (AGD_PRE.1) \r\n | \r\n |
| \r\n | \r\n \r\n Sử dụng một hệ thống CM (ALC_CMC.2) \r\n | \r\n
| \r\n Các phần tổng quát TOE CM (ALC_CMS.2) \r\n | \r\n |
| \r\n Các thủ tục chuyển giao (ALC_DEL.1) \r\n | \r\n |
| \r\n | \r\n \r\n Yêu cầu tuân thủ (ASE_CCL.1) \r\n | \r\n
| \r\n Định nghĩa các thành phần mở rộng\r\n (ASE_ECD.1) \r\n | \r\n |
| \r\n Giới thiệu ST (ASE_INT.1) \r\n | \r\n |
| \r\n Các mục tiêu an toàn (ASE_OBJ.2) \r\n | \r\n |
| \r\n Các yêu cầu an toàn thu được (ASE_REQ.2) \r\n | \r\n |
| \r\n Định nghĩa vấn đề an toàn (ASE_SPD.1) \r\n | \r\n |
| \r\n Đặc tả tóm tắt TOE (ASE_TSS.1) \r\n | \r\n |
| \r\n | \r\n \r\n Chứng cứ về tính tổng quát (ATE_COV.1) \r\n | \r\n
| \r\n Kiểm thử chức năng (ATE_FUN.1) \r\n | \r\n |
| \r\n Kiểm thử độc lập - ví dụ (ATE_IND.2) \r\n | \r\n |
| \r\n | \r\n \r\n Khảo sát điểm yếu (AVA_VAN.2) \r\n | \r\n
7.5.1. Mục tiêu
\r\n\r\nEAL3 cho phép một nhà phát triển tận tâm đạt\r\nđược sự đảm bảo tối đa với công nghệ an toàn tốt ở mức thiết kế mà không cần\r\nthay đổi các cơ chế phát triển đang có sẵn.
\r\n\r\nEAL3 có thể ứng dụng trong các tình huống mà\r\nnhà phát triển hoặc người sử dụng yêu cầu ở mức vừa phải về đảm bảo an toàn độc\r\nlập, và yêu cầu một sự điều tra tỉ mỉ về TOE và phát triển nó không cần bước\r\nthiết kế lại đáng kể nào.
\r\n\r\n7.5.2. Các thành phần đảm bảo
\r\n\r\nEAL3 cung cấp đảm bảo bởi một đích an toàn\r\nđầy đủ và phân tích các yêu cầu chức năng an toàn (SFR) của ST, sử dụng một đặc\r\ntả chức năng và giao diện, tài liệu hướng dẫn và các mô tả về kiến trúc thiết\r\nkế của TOE, để diễn giải hoạt động an toàn.
\r\n\r\nSự phân tích được hỗ trợ bằng việc kiểm tra\r\nmột cách độc lập các chức năng an toàn của TOE, chứng cứ về việc kiểm thử của\r\nnhà phát triển dựa trên đặc tả chức năng và thiết kế TOE, sự xác nhận độc lập\r\ncó chọn lọc các kết quả kiểm tra của nhà phát triển, phân tích các lỗ hổng/điểm\r\nyếu (dựa trên các đặc tính chức năng, thiết kế TOE, mô tả kiến trúc an toàn và\r\nbằng chứng hướng dẫn được cung cấp) để thể hiện khả năng bảo vệ trước xâm nhập\r\ncủa kẻ tấn công với một tiềm lực tấn công cơ bản.
\r\n\r\nEAL3 cung cấp đảm bảo thông qua sử dụng các\r\nbiện pháp quản lý môi trường phát triển, quản lý cấu hình TOE, và chứng cứ về\r\ncác thủ tục chuyển giao an toàn.
\r\n\r\nEAL này thể hiện sự đảm bảo có ý nghĩa hơn so\r\nvới EAL2 bằng việc đòi hỏi tổng quát việc kiểm thử hoàn thiện hơn về chức năng\r\nan toàn và cơ chế và/hoặc thủ tục nhằm đưa ra một sự tin cậy nào đó về việc TOE\r\nsẽ không bị giả mạo trong quá trình phát triển.
\r\n\r\n| \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n Đặc tả kiến trúc an toàn (ADV_ARC.1) \r\n | \r\n
| \r\n Đặc tả chức năng với tóm tắt đầy đủ\r\n (ADV_FSP.3) \r\n | \r\n |
| \r\n Thiết kế kiến trúc (ADV_TDS.2) \r\n | \r\n |
| \r\n | \r\n \r\n Hướng dẫn người dùng vận hành (AGD_OPE.1) \r\n | \r\n
| \r\n Các thủ tục chuẩn bị (AGD_PRE.1) \r\n | \r\n |
| \r\n | \r\n \r\n Các biện pháp quản lý cấp quyền (ALC_CMC.3) \r\n | \r\n
| \r\n Tổng quát CM biểu diễn triển khai\r\n (ALC_CMS.3) \r\n | \r\n |
| \r\n Các thủ tục chuyển giao (ALC_DEL.1) \r\n | \r\n |
| \r\n Định danh các biện pháp an toàn (ALC_DVS.1) \r\n | \r\n |
| \r\n Mô hình vòng đời định nghĩa cho nhà phát\r\n triển (ALC_LCD.1) \r\n | \r\n |
| \r\n | \r\n \r\n Yêu cầu tuân thủ (ASE_CCL.1) \r\n | \r\n
| \r\n Định nghĩa các thành phần mở rộng\r\n (ASE_ECD.1) \r\n | \r\n |
| \r\n Giới thiệu ST (ASE_INT.1) \r\n | \r\n |
| \r\n Các mục tiêu an toàn (ASE_OBJ.2) \r\n | \r\n |
| \r\n Các yêu cầu an toàn thu được (ASE_REQ.2) \r\n | \r\n |
| \r\n Định nghĩa vấn đề an toàn (ASE_SPD.1) \r\n | \r\n |
| \r\n Đặc tả tóm tắt TOE (ASE_TSS.1) \r\n | \r\n |
| \r\n | \r\n \r\n Phân tích tổng quát (ATE_COV.2) \r\n | \r\n
| \r\n Kiểm thử: Thiết kế cơ bản (ATE_DPT.1) \r\n | \r\n |
| \r\n Kiểm thử chức năng (ATE_FUN.1) \r\n | \r\n |
| \r\n Kiểm thử độc lập - ví dụ (ATE_IND.2) \r\n | \r\n |
| \r\n | \r\n \r\n Phân tích điểm yếu (AVA_VAN.2) \r\n | \r\n
7.6.1. Mục tiêu
\r\n\r\nEAL4 cho phép một nhà phát triển đạt được sự\r\nđảm bảo tối đa về kỹ thuật an toàn tốt dựa trên các thực tế phát triển thương\r\nmại tốt, tuy chặt chẽ, song không yêu cầu kiến thức chuyên gia, kỹ năng, và các\r\ntài nguyên đáng kể nào khác. EAL4 là mức cao nhất khả thi về mặt kinh tế đưa\r\nvào một dòng sản phẩm đang tồn tại.
\r\n\r\nEAL4 vì vậy có thể ứng dụng trong các trường\r\nhợp mà ở đó các nhà phát triển và người sử dụng yêu cầu một mức từ trung bình\r\nđến cao đảm bảo an toàn độc lập trong TOE thông thường và được chuẩn bị để đưa\r\nvào các chi phí mở rộng công trình an toàn cụ thể.
\r\n\r\n7.6.2. Các thành phần đảm bảo
\r\n\r\nEAL4 cung cấp khả năng đảm bảo bởi một đích\r\nan toàn đầy đủ và sự phân tích các yêu cầu chức năng an toàn (SFR) của ST, sử\r\ndụng một đặc tả chức năng và giao diện, tài liệu hướng dẫn, mô tả về thiết kế\r\nmô-đun cơ bản của TOE và một tập triển khai, nhằm diễn giải hoạt động an toàn.
\r\n\r\nSự phân tích được hỗ trợ bởi việc kiểm tra\r\nđộc lập các chức năng an toàn TOE, chứng cứ về việc kiểm thử của nhà phát triển\r\ndựa trên đặc tả chức năng và thiết kế của TOE, sự khẳng định độc lập có lựa\r\nchọn về các kết quả kiểm thử của nhà phát triển, phân tích các lỗ hổng/điểm yếu\r\n(dựa trên các đặc tính chức năng, thiết kế TOE, trình diễn thực thi, thiết kế\r\nkiến trúc và bằng chứng hướng dẫn được cung cấp) để thể hiện khả năng bảo vệ\r\ntrước xâm nhập của kẻ tấn công với một tiềm lực tấn công trên mức cơ bản.
\r\n\r\nEAL4 cũng cung cấp đảm bảo thông qua sử dụng\r\ncác biện pháp quản lý môi trường phát triển và quản lý cấu hình TOE mở rộng bao\r\ngồm tự động hóa và bằng chứng về các thủ tục chuyển giao an toàn.
\r\n\r\nEAL này thể hiện sự đảm bảo hơn EAL3 bằng\r\nviệc yêu cầu mô tả thiết kế tỉ mỉ hơn, trình diễn thực thi cho toàn bộ các chức\r\nnăng an toàn TOE và cơ chế cải thiện và/hoặc các thủ tục nhằm đưa ra sự tin cậy\r\nrằng TOE sẽ không bị giả mạo trong quá trình phát triển.
\r\n\r\n| \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n Đặc tả kiến trúc an toàn (ADV_ARC.1) \r\n | \r\n
| \r\n Đặc tả chức năng đầy đủ (ADV_FSP.4) \r\n | \r\n |
| \r\n Mô tả triển khai TSF (ADV_IMP.1) \r\n | \r\n |
| \r\n Thiết kế kiến trúc cơ sở (ADV_TDS.3) \r\n | \r\n |
| \r\n | \r\n \r\n Hướng dẫn người dùng vận hành (AGD_OPE.1) \r\n | \r\n
| \r\n Các thủ tục chuẩn bị (AGD_PRE.1) \r\n | \r\n |
| \r\n | \r\n \r\n Tự động hóa, các thủ tục chấp nhận và hỗ\r\n trợ sản xuất (ALC_CMC.4) \r\n | \r\n
| \r\n Tổng quan CM theo dấu vết vấn đề\r\n (ALC_CMS.4) \r\n | \r\n |
| \r\n Các thủ tục chuyển giao (ALC_DEL.1) \r\n | \r\n |
| \r\n Định danh các biện pháp an toàn (ALC_DVS.1) \r\n | \r\n |
| \r\n Mô hình vòng đời định nghĩa cho nhà phát\r\n triển (ALC_LCD.1) \r\n | \r\n |
| \r\n Các công cụ phát triển xác định rõ\r\n (ALC_TAT.1) \r\n | \r\n |
| \r\n | \r\n \r\n Yêu cầu tuân thủ (ASE_CCL.1) \r\n | \r\n
| \r\n Định nghĩa các thành phần mở rộng\r\n (ASE_ECD.1) \r\n | \r\n |
| \r\n Giới thiệu ST (ASE_INT.1) \r\n | \r\n |
| \r\n Các mục tiêu an toàn (ASE_OBJ.2) \r\n | \r\n |
| \r\n Các yêu cầu an toàn thu được (ASE_REQ.2) \r\n | \r\n |
| \r\n Định nghĩa vấn đề an toàn (ASE_SPD.1) \r\n | \r\n |
| \r\n Đặc tả tóm tắt TOE (ASE_TSS.1) \r\n | \r\n |
| \r\n | \r\n \r\n Phân tích tổng quát (ATE_COV.2) \r\n | \r\n
| \r\n Kiểm thử: Các mô đun bắt buộc an toàn\r\n (ATE_DPT.2) \r\n | \r\n |
| \r\n Kiểm thử chức năng (ATE_FUN.1) \r\n | \r\n |
| \r\n Kiểm thử độc lập - ví dụ (ATE_IND.2) \r\n | \r\n |
| \r\n | \r\n \r\n Phân tích điểm yếu trọng tâm (AVA_VAN.3) \r\n | \r\n
7.7.1. Mục tiêu
\r\n\r\nEAL5 cho phép một nhà phát triển đạt được đảm\r\nbảo tối đa với kỹ thuật an toàn dựa trên thực tế sự phát triển thương mại\r\nnghiêm ngặt hỗ trợ bởi việc ứng dụng ở mức trung bình các kỹ thuật an toàn đặc\r\nbiệt. Như vậy một TOE sẽ có thể được thiết kế và phát triển với mục đích đạt\r\nđược đảm bảo EAL5. Nó tương tự như các chi phí mở rộng đưa vào các yêu cầu\r\nEAL5, liên quan đến sự phát triển nghiêm ngặt không ứng dụng các kỹ thuật đặc\r\nbiệt.
\r\n\r\nEAL5 vì vậy có khả năng ứng dụng trong các\r\ntrường hợp mà ở đó nhà phát triển và người sử dụng yêu cầu ở mức cao đảm bảo an\r\ntoàn độc lập trong sự phát triển đã được kế hoạch và đòi hỏi một nghiên cứu\r\nphát triển nghiêm ngặt không chịu các chi phí có thể quy cho các kỹ thuật an\r\ntoàn đặc biệt.
\r\n\r\n7.7.2. Các thành phần đảm bảo
\r\n\r\nEAL5 cung cấp khả năng đảm bảo bằng một đích\r\nan toàn đầy đủ và việc phân tích các đòi hỏi chức năng an toàn (SFR) của ST, sử\r\ndụng một đặc tả chức năng và giao diện, tài liệu hướng dẫn, mô tả thiết kế của\r\nTOE, và ứng dụng, để hiểu hành vi an toàn. Như vậy đòi hỏi TSF thiết kế theo\r\nmô-đun.
\r\n\r\nSự phân tích được hỗ trợ bởi việc kiểm tra\r\nđộc lập các chức năng an toàn TOE, bằng chứng kiểm tra nhà phát triển dựa trên\r\ncác đặc tả chức năng, thiết kế TOE, sự khẳng định độc lập có lựa chọn các kết\r\nquả kiểm tra nhà phát triển, và một sự phân tích lỗ hổng độc lập thể hiện sự\r\nphản ứng đối với các xâm nhập của kẻ tấn công với một khả năng tấn công mức vừa\r\nphải.
\r\n\r\nEAL5 cũng cung cấp khả năng đảm bảo thông qua\r\nsử dụng các kiểm soát môi trường phát triển, và quản lý cấu hình TOE tổng thể\r\nbao gồm thông tin và bằng chứng của các thủ tục chuyển giao an toàn.
\r\n\r\nEAL này thể hiện sự đảm bảo hơn EAL4 bằng\r\nviệc yêu cầu mô tả thiết kế bán chính thức, kiến trúc có cấu trúc hơn (và từ\r\nđây có thể phân tích) và cơ chế cải thiện và/hoặc các thủ tục mà nó cung cấp sự\r\nchắc chắn mà TOE sẽ không bị ảnh hưởng trong quá trình phát triển.
\r\n\r\n| \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n Đặc tả kiến trúc an toàn (ADV_ARC.1) \r\n | \r\n
| \r\n Đặc tả chức năng đầy đủ bán chính thức với\r\n thông tin lỗ bổ sung (ADV_FSP.5) \r\n | \r\n |
| \r\n Mô tả triển khai TSF (ADV_IMP.1) \r\n | \r\n |
| \r\n Thiết kế mô đun bán chính thức (ADV_TDS.4) \r\n | \r\n |
| \r\n | \r\n \r\n Hướng dẫn người dùng vận hành (AGD_OPE.1) \r\n | \r\n
| \r\n Các thủ tục chuẩn bị (AGD_PRE.1) \r\n | \r\n |
| \r\n | \r\n \r\n Tự động hóa, các thủ tục chấp nhận và hỗ\r\n trợ sản xuất (ALC_CMC.4) \r\n | \r\n
| \r\n Tổng quan CM các công cụ phát triển\r\n (ALC_CMS.5) \r\n | \r\n |
| \r\n Các thủ tục chuyển giao (ALC_DEL.1) \r\n | \r\n |
| \r\n Định danh các biện pháp an toàn (ALC_DVS.1) \r\n | \r\n |
| \r\n Mô hình vòng đời định nghĩa cho nhà phát\r\n triển (ALC_LCD.1) \r\n | \r\n |
| \r\n Tuân thủ với các tiêu chuẩn triển khai\r\n (ALC_TAT.2) \r\n | \r\n |
| \r\n | \r\n \r\n Yêu cầu tuân thủ (ASE_CCL.1) \r\n | \r\n
| \r\n Định nghĩa các thành phần mở rộng\r\n (ASE_ECD.1) \r\n | \r\n |
| \r\n Giới thiệu ST (ASE_INT.1) \r\n | \r\n |
| \r\n Các mục tiêu an toàn (ASE_OBJ.2) \r\n | \r\n |
| \r\n Các yêu cầu an toàn thu được (ASE_REQ.2) \r\n | \r\n |
| \r\n Định nghĩa vấn đề an toàn (ASE_SPD.1) \r\n | \r\n |
| \r\n Đặc tả tóm tắt TOE (ASE_TSS.1) \r\n | \r\n |
| \r\n | \r\n \r\n Phân tích tổng quát (ATE_COV.2) \r\n | \r\n
| \r\n Kiểm thử: Thiết kế mô đun (ATE_DPT.3) \r\n | \r\n |
| \r\n Kiểm thử chức năng (ATE_FUN.1) \r\n | \r\n |
| \r\n Kiểm thử độc lập - ví dụ (ATE_IND.2) \r\n | \r\n |
| \r\n | \r\n \r\n Phân tích điểm yếu theo phương pháp\r\n (AVA_VAN.4) \r\n | \r\n
7.8.1. Mục tiêu
\r\n\r\nEAL6 cho phép nhà phát triển đạt tới độ đảm\r\nbảo cao từ việc ứng dụng các kỹ thuật an toàn đối với môi trường phát triển\r\nnghiêm ngặt để đưa ra TOE cho việc bảo vệ dữ liệu có giá trị cao trước các rủi\r\nro.
\r\n\r\nEAL6 vì vậy có thể ứng dụng để phát triển TOE\r\ncho ứng dụng có độ rủi ro cao mà ở đó giá trị của tài sản bảo vệ điều chỉnh\r\ntheo chi phí phát sinh.
\r\n\r\n7.8.2. Các thành phần đảm bảo
\r\n\r\nEAL6 cung cấp khả năng đảm bảo bởi một đích\r\nan toàn đầy đủ và sự phân tích các yêu cầu chức năng an toàn (SFR) của ST, sử\r\ndụng đặc tả chức năng và giao diện tổng thể, tài liệu hướng dẫn, thiết kế của\r\nTOE, và triển khai, nhằm diễn giải hoạt động an toàn. Ngoài ra, đảm bảo còn đạt\r\nđược thông qua một mô hình chính thức về lựa chọn các chính sách an toàn TOE và\r\nmột thể hiện bán chính thức của các đặc tả chức năng, thiết kế TOE. Điều đó đòi\r\nhỏi thiết kế TOE theo mô-đun và phân lớp.
\r\n\r\nSự phân tích được hỗ trợ bởi việc kiểm tra\r\nđộc lập các chức năng an toàn TOE, bằng chứng về việc kiểm thử của nhà phát\r\ntriển dựa trên đặc tả chức năng, thiết kế TOE, sự xác nhận độc lập có lựa chọn\r\nvề các kết quả kiểm thử của nhà phát triển, và một sự phân tích lỗ hổng độc lập\r\nthể hiện bảo vệ trước xâm nhập của kẻ tấn công với một khả năng tấn công mức\r\ncao.
\r\n\r\nEAL6 cũng cung cấp khả năng đảm bảo thông qua\r\nsử dụng một quy trình phát triển có cấu trúc, các biện pháp quản lý môi trường\r\nphát triển, và quản lý cấu hình TOE tổng thể bao gồm thông tin và bằng chứng\r\ncủa các thủ tục chuyển giao an toàn.
\r\n\r\nEAL này đưa ra một sự đảm bảo có ý nghĩa hơn\r\nso với EAL5 bằng việc yêu cầu phân tích toàn diện hơn, thể hiện ứng dụng có cấu\r\ntrúc, kiến trúc có cấu trúc hơn (ví dụ phân lớp), sự phân tích lỗ hổng độc lập\r\ntoàn diện hơn, cải thiện quản lý cấu hình và kiểm soát môi trường phát triển.
\r\n\r\n| \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n Đặc tả kiến trúc an toàn (ADV_ARC.1) \r\n | \r\n
| \r\n Đặc tả chức năng đầy đủ bán chính thức với\r\n thông tin lỗi bổ sung (ADV_FSP.5) \r\n | \r\n |
| \r\n Ánh xạ đầy đủ mô tả triển khai TSF\r\n (ADV_IMP.2) \r\n | \r\n |
| \r\n Nội bộ tổ hợp tối thiểu (ADV_INT.3) \r\n | \r\n |
| \r\n Mô hình chính sách an toàn TOE chính thức\r\n (ADV_SPM.1) \r\n | \r\n |
| \r\n Thiết kế mô đun đầy đủ bán chính thức\r\n (ADV_TDS.5) \r\n | \r\n |
| \r\n | \r\n \r\n Hướng dẫn người dùng vận hành (AGD_OPE.1) \r\n | \r\n
| \r\n Các thủ tục chuẩn bị (AGD_PRE.1) \r\n | \r\n |
| \r\n | \r\n \r\n Hỗ trợ cải tiến (ALC_CMC.5) \r\n | \r\n
| \r\n Tổng quan CM các công cụ phát triển\r\n (ALC_CMS.5) \r\n | \r\n |
| \r\n Các thủ tục chuyển giao (ALC_DEL.1) \r\n | \r\n |
| \r\n Sự đầy đủ của các biện pháp an toàn\r\n (ALC_DVS.2) \r\n | \r\n |
| \r\n Mô hình vòng đời định nghĩa cho nhà phát\r\n triển (ALC_LCD.1) \r\n | \r\n |
| \r\n Tuân thủ với các tiêu chuẩn triển khai -\r\n tất cả các phần (ALC_TAT.3) \r\n | \r\n |
| \r\n | \r\n \r\n Yêu cầu tuân thủ (ASE_CCL.1) \r\n | \r\n
| \r\n Định nghĩa các thành phần mở rộng\r\n (ASE_ECD.1) \r\n | \r\n |
| \r\n Giới thiệu ST (ASE_INT.1) \r\n | \r\n |
| \r\n Các mục tiêu an toàn (ASE_OBJ.2) \r\n | \r\n |
| \r\n Các yêu cầu an toàn thu được (ASE_REQ.2) \r\n | \r\n |
| \r\n Định nghĩa vấn đề an toàn (ASE_SPD.1) \r\n | \r\n |
| \r\n Đặc tả tóm tắt TOE (ASE_TSS.1) \r\n | \r\n |
| \r\n | \r\n \r\n Phân tích tổng quát nghiêm ngặt (ATE_COV.3) \r\n | \r\n
| \r\n Kiểm thử: Thiết kế mô đun (ATE_DPT.3) \r\n | \r\n |
| \r\n Kiểm thử chức năng theo thứ tự (ATE_FUN.2) \r\n | \r\n |
| \r\n Kiểm thử độc lập - ví dụ (ATE_IND.2) \r\n | \r\n |
| \r\n | \r\n \r\n Phân tích điểm yếu theo phương pháp cải\r\n tiến (AVA_VAN.5) \r\n | \r\n
7.9.1. Mục tiêu
\r\n\r\nEAL7 được ứng dụng để phát triển TOE cho ứng\r\ndụng có độ rủi ro rất cao hoặc ở đó tài sản có giá trị cao điều chỉnh chi phí\r\nlớn hơn. Ứng dụng thực tế của EAL7 hiện nay giới hạn cho TOE tập trung vào chức\r\nnăng an toàn tuân theo phân tích chính thức mở rộng.
\r\n\r\n7.9.2. Các thành phần đảm bảo
\r\n\r\nEAL7 cung cấp khả năng đảm bảo bởi một đích\r\nan toàn đầy đủ và sự phân tích các yêu cầu chức năng an toàn (SFRs) của ST, sử\r\ndụng đặc tả chức năng và giao diện tổng thể, tài liệu hướng dẫn, thiết kế TOE,\r\nvà một thể hiện triển khai có cấu trúc, nhằm diễn giải hoạt động an toàn. Ngoài\r\nra, đảm bảo còn đạt được thông qua một mô hình chính thức về chọn lựa các chính\r\nsách an toàn TOE, và một thể hiện bán chính thức các đặc tả chức năng và thiết\r\nkế TOE. Điều đó đòi hỏi thiết kế TSF có tính mô-đun, đơn giản và có phân lớp.
\r\n\r\nSự phân tích được hỗ trợ bởi việc kiểm thử\r\nđộc lập các chức năng an toàn TOE, bằng chứng về việc kiểm thử của nhà phát\r\ntriển dựa trên đặc tả chức năng, thiết kế TOE và thể hiện triển khai, xác nhận\r\nđộc lập có lựa chọn về các kết quả kiểm tra của nhà phát triển, một phân tích\r\nlỗ hổng độc lập thể hiện sự bảo vệ trước xâm nhập của kẻ tấn công với một khả\r\nnăng tấn công mức cao.
\r\n\r\nEAL7 cũng cung cấp khả năng đảm bảo thông qua\r\nsử dụng một quy trình phát triển có cấu trúc, các biện pháp quản lý môi trường\r\nphát triển, quản lý cấu hình TOE tổng thể bao gồm tự động hóa đầy đủ và bằng\r\nchứng về các thủ tục chuyển giao an toàn.
\r\n\r\nEAL này đưa ra một sự đảm bảo có ý nghĩa hơn\r\nso với EAL6 bằng việc yêu cầu phân tích toàn diện hơn, sử dụng các thể hiện\r\nchính thức, phù hợp chính thức và kiểm thử toàn diện.
\r\n\r\n| \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n Đặc tả kiến trúc an toàn (ADV_ARC.1) \r\n | \r\n
| \r\n Đặc tả chức năng đầy đủ bán chính thức với\r\n đặc tả chính thức bổ sung (ADV_FSP.6) \r\n | \r\n |
| \r\n Ánh xạ đầy đủ mô tả triển khai TSF\r\n (ADV_IMP.2) \r\n | \r\n |
| \r\n Nội bộ tổ hợp tối thiểu (ADV_INT.3) \r\n | \r\n |
| \r\n Mô hình chính sách an toàn TOE chính thức\r\n (ADV_SPM.1) \r\n | \r\n |
| \r\n Thiết kế mô đun đầy đủ bán chính thức với\r\n thể hiện thiết kế mức cao (ADV_TDS.6) \r\n | \r\n |
| \r\n | \r\n \r\n Hướng dẫn người dùng vận hành (AGD_OPE.1) \r\n | \r\n
| \r\n Các thủ tục chuẩn bị (AGD_PRE.1) \r\n | \r\n |
| \r\n | \r\n \r\n Hỗ trợ cải tiến (ALC_CMC.5) \r\n | \r\n
| \r\n Tổng quan CM các công cụ phát triển\r\n (ALC_CMS.5) \r\n | \r\n |
| \r\n Các thủ tục chuyển giao (ALC_DEL.1) \r\n | \r\n |
| \r\n Sự đầy đủ của các biện pháp an toàn\r\n (ALC_DVS.2) \r\n | \r\n |
| \r\n Mô hình vòng đời định mức được (ALC_LCD.2) \r\n | \r\n |
| \r\n Tuân thủ với các tiêu chuẩn triển khai -\r\n tất cả các phần (ALC_TAT.3) \r\n | \r\n |
| \r\n | \r\n \r\n Yêu cầu tuân thủ (ASE_CCL.1) \r\n | \r\n
| \r\n Định nghĩa các thành phần mở rộng\r\n (ASE_ECD.1) \r\n | \r\n |
| \r\n Giới thiệu ST (ASE_INT.1) \r\n | \r\n |
| \r\n Các mục tiêu an toàn (ASE_OBJ.2) \r\n | \r\n |
| \r\n Các yêu cầu an toàn thu được (ASE_REQ.2) \r\n | \r\n |
| \r\n Định nghĩa vấn đề an toàn (ASE_SPD.1) \r\n | \r\n |
| \r\n Đặc tả tóm tắt TOE (ASE_TSS.1) \r\n | \r\n |
| \r\n | \r\n \r\n Phân tích tổng quát nghiêm ngặt (ATE_COV.3) \r\n | \r\n
| \r\n Kiểm thử: Biểu diễn triển khai (ATE_DPT.4) \r\n | \r\n |
| \r\n Kiểm thử chức năng theo thứ tự (ATE_FUN.2) \r\n | \r\n |
| \r\n Kiểm thử độc lập - đầy đủ (ATE_IND.3) \r\n | \r\n |
| \r\n | \r\n \r\n Phân tích điểm yếu theo phương pháp cải\r\n tiến (AVA_VAN.5) \r\n | \r\n
Các gói đảm bảo tổng hợp (CAP) cung cấp một\r\nthang đo tăng dần để cân bằng mức độ đảm bảo đạt được với giá thành và sự khả\r\nthi có thể đạt được mà mức độ đảm bảo cho TOE tổng hợp.
\r\n\r\nĐiểm quan trọng cần chú ý là chỉ có một số\r\nlượng nhỏ các họ và thành phần trong phần này của ISO 15408 được chứa trong\r\nCAP. Đây là tính tất yếu của việc xây dựng dựa trên các kết quả đánh giá các\r\nthực thể được đánh giá trước đó (dựa trên các thành phần và các thành phần phụ\r\nthuộc), điều này không nói lên rằng chúng không cung cấp các đảm bảo được mong\r\nmuốn và đầy đủ ý nghĩa.
\r\n\r\nCAP có thể được sử dụng để đưa ra các TOE\r\ntổng hợp, bao gồm các thành phần mà đã hoặc sẽ được đánh giá TOE thành phần\r\n(xem Phụ lục B). Các thành phần riêng sẽ được chứng nhận EAL hoặc gói bảo đảm\r\nkhác được chỉ ra trong ST. Với mong muốn, mức độ cơ bản của bảo đảm trong TOE\r\nthành phần sẽ đạt được thông qua áp dụng các EAL1, mà có thể đạt được với các\r\nthông tin về thành phần thường có sẵn trong một miền chung. (EAL1 có thể được\r\náp dụng như được chỉ ra trong cả TOE tổng hợp và thành phần). CAP cung cấp một\r\ncách tiếp cận khác để đạt được cấp độ cao hơn bảo đảm cho TOE thành phần hơn\r\nviệc áp dụng các EAL trên EAL1.
\r\n\r\nKhi một thành phần phụ thuộc có thể được đánh\r\ngiá bằng cách sử dụng các đánh giá và chứng nhận trước đó để thỏa mãn đòi hỏi\r\nvề nền tảng CNTT trong môi trường, điều này không cung cấp bất kỳ sự bảo đảm\r\nchính thức của tương tác giữa các thành phần hoặc đưa ra các lỗ hổng có thể xảy\r\nra thu được từ sự tổng hợp. Các gói đảm bảo tổng hợp xem xét các tương tác này,\r\nở các mức đảm bảo cao hơn, đảm bảo rằng tương tác giữa các thành phần mà chính\r\nnó là mục tiêu để kiểm thử. Phân tích điểm yếu của TOE tổng hợp sẽ được thực\r\nhiện để xem xét việc đưa ra các điểm yếu như là kết quả của sự tổng hợp các\r\nthành phần.
\r\n\r\nBảng 9 biểu diễn tóm tắt của các CAP. Các cột\r\nbiểu diễn sự phân cấp có trật tự của các tập của các CAP, còn các hàng biểu\r\ndiễn các họ đảm bảo. Mỗi số trong ma trận kết quả chỉ ra một thành phần đảm bảo\r\ntại các chỗ có thể áp dụng.
\r\n\r\nNhư được nêu trong mục con tiếp theo, ba gói\r\nđảm bảo tổng hợp được phân cấp có trật tự được định nghĩa trong TCVN 8709 để\r\nxếp hạng mức độ đảm bảo của các TOE tổng hợp. Chúng được phân cấp theo trật tự\r\nđể đảm bảo rằng mỗi biểu diễn CAP là chính xác hơn tất cả CAP thấp hơn. Việc\r\ntăng mức độ đảm bảo từ CAP đến CAP được thực hiện bằng việc thay thế bằng thành\r\nphần đảm bảo có mức độ phân cấp cao hơn từ các họ đảm bảo tương tự (ví dụ tăng\r\ntính nghiêm ngặt, phạm vi và độ sâu) và từ việc bổ sung các thành phần đảm bảo\r\ntừ các họ đảm bảo khác (ví dụ như thêm các đòi hỏi mới). Điều này làm việc phân\r\ntích lớn hơn với các tập hợp để chỉ ra tác động trong các kết quả đánh giá đạt\r\nđược với TOE tổng hợp.
\r\n\r\nCác CAP bao gồm một sự phối hợp thích hợp của\r\ncác thành phần đảm bảo như mô tả trong điều 6 trong phần TCVN 8709 này. Chính\r\nxác hơn, mỗi CAP chứa không nhiều hơn một thành phần của mỗi họ đảm bảo và tất\r\ncả các phụ thuộc đảm bảo trong mọi thành phần được đề cập đến.
\r\n\r\nCác CAP chỉ xem xét khả năng chống lại kẻ tấn\r\ncông với khả năng tấn công lên trên mức cơ bản. Đây là do mức độ thông tin\r\nthiết kế được cung cấp bởi ACO_DEV, hạn chế một số yếu tố kết hợp với khả năng\r\ntấn công (hiểu biết về các thành phần cấu thành TOE) và sau đó ảnh hưởng đến sự\r\nchặt chẽ của phân tích điểm yếu được thực hiện bởi đánh giá viên. Vì vậy, mức\r\nđộ đảm bảo trong TOE tổng hợp sẽ bị giới hạn, mặc dù vậy việc đảm bảo trong các\r\nthành phần riêng trong TOE tổng hợp cao hơn nhiều.
\r\n\r\n| \r\n | \r\n \r\n | \r\n \r\n | \r\n ||
| \r\n | \r\n \r\n | \r\n \r\n | \r\n ||
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
Các điều khoản sau đây sẽ cung cấp các định\r\nnghĩa của các CAP, phần khác nhau giữa các yêu cầu riêng và các đặc trưng\r\nthường của các yêu cầu này sử dụng chữ in đậm.
\r\n\r\n8.3.1. Mục tiêu
\r\n\r\nCAP-A được áp dụng khi TOE tổng hợp được tích\r\nhợp và tin cậy với hoạt động an toàn thực hiện đúng theo tổng hợp kết quả được\r\nyêu cầu. Điều này đòi hỏi sự hợp tác của nhà phát triển của thành phần phụ\r\nthuộc về việc cung cấp thông tin thiết kế và kết quả kiểm tra từ việc chứng\r\nnhận các thành phần phụ thuộc, mà không đòi hỏi sự tham gia của nhà phát triển\r\nthành phần cơ sở.
\r\n\r\nCAP-A do đó áp dụng trong các trường hợp này,\r\nnơi các nhà phát triển hoặc người dùng yêu cầu một mức thấp đến trung bình mức\r\nđộ an toàn được đảm bảo một cách độc lập trong trường hợp không sẵn có toàn bộ\r\nbản ghi phát triển.
\r\n\r\n8.3.2. Các thành phần đảm bảo
\r\n\r\nCAP-A cung cấp đảm bảo thông qua phân tích đích\r\nan toàn cho TOE tổng hợp. Các SFR trong ST của TOE tổng hợp được phân tích bằng\r\ncách sử dụng kết quả đầu ra từ đánh giá của các TOE thành phần (ví dụ ST, tài\r\nliệu hướng dẫn) và đặc tả cho các giao diện giữa các TOE thành phần trong TOE\r\ntổng hợp để hiểu về hành vi an toàn.
\r\n\r\nPhân tích này được hỗ trợ bằng cách kiểm tra\r\nđộc lập của các giao diện của các thành phần cơ sở dựa trên thành phần phụ\r\nthuộc, như được mô tả trong thông tin tin cậy, bằng chứng về nhà phát triển các\r\nphép thử dựa trên thông tin tin cậy, thông tin phát triển và các sở cứ tổng\r\nhợp, và lựa chọn xác nhận độc lập có chọn lọc các kết quả kiểm tra của nhà phát\r\ntriển. Phân tích này cũng được hỗ trợ bởi việc xem xét lại điểm yếu trong TOE\r\ntổng hợp bởi đánh giá viên.
\r\n\r\nCAP-A cũng cung cấp bảo đảm thông qua nhận\r\ndạng duy nhất của TOE tổng hợp (ví dụ TOE CNTT và tài liệu hướng dẫn).
\r\n\r\n| \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n ACO_COR.1 Sở cứ tổng hợp \r\n | \r\n
| \r\n ACO_CTT.1 Kiểm thử giao diện \r\n | \r\n |
| \r\n ACO_DEV.1: Mô tả chức năng \r\n | \r\n |
| \r\n ACO_REL.1: Thông tin tin cậy cơ sở \r\n | \r\n |
| \r\n ACO_VUL.1: Soát xét các điểm yếu tổng hợp \r\n | \r\n |
| \r\n | \r\n \r\n AGD_OPE.1 Hướng dẫn người dùng vận hành \r\n | \r\n
| \r\n AGD_PRE.1 Các thủ tục chuẩn bị \r\n | \r\n |
| \r\n | \r\n \r\n ACL_CMC.1 Gắn nhãn cho TOE \r\n | \r\n
| \r\n ACL_CMS.2: Các thành phần của TOE CM tổng\r\n quát \r\n | \r\n |
| \r\n | \r\n \r\n ASE_CCL.1 Các yêu cầu tuân thủ \r\n | \r\n
| \r\n ASE_ECD.1 Định nghĩa các thành phần mở rộng \r\n | \r\n |
| \r\n ASE_INT.1: Giới thiệu ST \r\n | \r\n |
| \r\n ASE_OBJ.1: Các mục tiêu an toàn cho môi\r\n trường vận hành \r\n | \r\n |
| \r\n ASE_REQ.1: Các yêu cầu an toàn đã xác nhận \r\n | \r\n |
| \r\n ASE_TSS.1: Đặc tả tổng quát TOE \r\n | \r\n
8.4.1. Mục tiêu
\r\n\r\nCAP-B cho phép nhà phát triển đạt được đảm\r\nbảo tối đa từ sự hiểu biết, tại mức hệ thống con, các ảnh hưởng của tương tác\r\ngiữa các TOE thành phần được tích hợp trong các TOE tổng hợp, trong khi giảm\r\nthiểu nhu cầu về sự tham gia của các nhà phát triển thành phần cơ sở.
\r\n\r\nCAP-B được áp dụng trong các trường hợp này,\r\nnơi các nhà phát triển hay người dùng đòi hỏi một mức độ vừa phải về an toàn\r\nđược đảm bảo độc lập, và yêu cầu một cuộc điều tra kỹ lưỡng về TOE tổng hợp và\r\nsự phát triển của nó mà không có kỹ thuật quan trọng.
\r\n\r\n8.4.2. Các thành phần đảm bảo
\r\n\r\nCAP-B cung cấp đảm bảo bằng phân tích một đích an\r\ntoàn đầy đủ cho TOE tổng hợp. Các SFR trong ST của TOE tổng hợp sẽ được phân\r\ntích bằng cách sử dụng kết quả đầu ra từ đánh giá của các TOE thành phần (ví dụ\r\nnhư ST, tài liệu hướng dẫn), đặc tả cho các giao diện giữa các TOE thành phần\r\nvà thiết kế TOE (mô tả hệ thống con TSF) chứa trong thông tin phát triển\r\ntổng hợp để hiểu về các hành vi an toàn.
\r\n\r\nPhân tích này được hỗ trợ bằng cách kiểm tra\r\nđộc lập của các giao diện của thành phần cơ sở được dựa trên các thành phần phụ\r\nthuộc, như mô tả trong thông tin tin cậy (bây giờ cũng bao gồm thiết kế TOE),\r\nbằng chứng kiểm thử phát triển dựa trên thông tin tin cậy, thông tin phát triển\r\nvà sở cứ tạo ra, xác nhận độc lập có chọn lọc kết quả kiểm thử của nhà phát\r\ntriển. Phân tích cũng được hỗ trợ bởi một phân tích điểm yếu trong TOE tổng hợp\r\nbởi đánh giá viên chứng minh khả năng chống kẻ tấn công với các khả năng tấn\r\ncông.
\r\n\r\nCAP biểu diễn sự gia tăng có ý nghĩa trong sự\r\nbảo đảm từ CAP-A bằng cách yêu cầu vùng bao phủ đầy đủ của các chức năng an\r\ntoàn.
\r\n\r\n| \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n ACO_COR.1 Sở cứ tổng hợp \r\n | \r\n
| \r\n ACO_CTT.2 Kiểm thử giao diện nghiêm ngặt \r\n | \r\n |
| \r\n ACO_DEV.2: Mô tả chứng cứ cơ sở \r\n | \r\n |
| \r\n ACO_REL.1: Thông tin tin cậy cơ sở \r\n | \r\n |
| \r\n ACO_VUL.2: Soát xét các điểm yếu thành phần \r\n | \r\n |
| \r\n | \r\n \r\n AGD_OPE.1 Hướng dẫn người dùng vận hành \r\n | \r\n
| \r\n AGD_PRE.1 Các thủ tục chuẩn bị \r\n | \r\n |
| \r\n | \r\n \r\n ACL_CMC.1 Gắn nhãn cho TOE \r\n | \r\n
| \r\n ACL_CMS.2: Các phần của TOE CM tổng quát \r\n | \r\n |
| \r\n | \r\n \r\n ASE_CCL.1 Các yêu cầu tuân thủ \r\n | \r\n
| \r\n ASE_ECD.1 Định nghĩa các thành phần mở rộng \r\n | \r\n |
| \r\n ASE_INT.1: Giới thiệu ST \r\n | \r\n |
| \r\n ASE_OBJ.2: Các mục tiêu an toàn \r\n | \r\n |
| \r\n ASE_REQ.2: Các yêu cầu an toàn được cung\r\n cấp \r\n | \r\n |
| \r\n ASE_SPD.1 Định nghĩa các vấn đề an toàn \r\n | \r\n |
| \r\n ASE_TSS.1: Đặc tả tổng quát TOE \r\n | \r\n
8.5.1. Mục tiêu
\r\n\r\nCAP-C cho phép nhà phát triển đạt được mức\r\nđảm bảo cao nhất từ việc phân tích chủ động sự tương tác giữa các thành phần\r\ncủa TOE tổng hợp, mà không đòi hỏi phải truy cập đầy đủ đến tất cả các chứng cứ\r\nđánh giá của thành phần cơ sở.
\r\n\r\nCAP-C do đó áp dụng trong các trường hợp này,\r\nnơi các nhà phát triển hoặc người sử dụng đòi hỏi phải có mức độ an toàn độc lập\r\nđược đảm bảo ở mức trung bình đến cao trong TOE tổng hợp thông thường truyền\r\nthống và được chuẩn bị để phải chịu thêm chi phí liên quan đến vấn đề an toàn\r\nđặc trưng.
\r\n\r\n8.5.2. Các thành phần đảm bảo
\r\n\r\nCAP-C cung cấp đảm bảo bằng phân tích của một\r\nđích an toàn đầy đủ cho TOE tổng hợp. Các SFR trong ST của TOE tổng hợp được\r\nphân tích bằng cách sử dụng kết quả đầu ra thông qua đánh giá các TOE thành\r\nphần (ví dụ như ST, tài liệu hướng dẫn), đặc tả cho các giao diện giữa các TOE\r\nthành phần và thiết kế TOE (mô tả các mô đun TSF) được chứa trong thông tin\r\nphát triển tổng hợp để hiểu về hành vi an toàn.
\r\n\r\nPhân tích được hỗ trợ bằng cách kiểm tra độc\r\nlập của các giao diện của thành phần cơ sở được dựa trên thành phần phụ thuộc,\r\nnhư mô tả trong thông tin tin cậy (nay bao gồm cả thiết kế TOE), kiểm tra chứng\r\ncứ của nhà phát triển dựa trên thông tin tin cậy, thông tin phát triển và sở cứ\r\ntổng hợp và chọn lọc độc lập xác nhận kết quả kiểm thử của nhà phát triển. Phân\r\ntích này cũng được hỗ trợ với việc phân tích điểm yếu của TOE tổng hợp bởi đánh\r\ngiá viên để chứng minh khả năng chống kẻ tấn công với khả năng tấn công trên\r\nmức cơ bản.
\r\n\r\nCAP này thể hiện sự gia tăng có ý nghĩa trong\r\nsự bảo đảm từ CAP-B bằng cách yêu cầu mô tả chi tiết thiết kế và thể hiện khả\r\nnăng chống lại khả năng bị tấn công cao hơn.
\r\n\r\n| \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n ACO_COR.1 Sở cứ tổng hợp \r\n | \r\n
| \r\n ACO_CTT.2 Kiểm thử giao diện nghiêm ngặt \r\n | \r\n |
| \r\n ACO_DEV.3: Chứng cứ chi tiết cho thiết kế \r\n | \r\n |
| \r\n ACO_REL.2: Thông tin tin cậy \r\n | \r\n |
| \r\n ACO_VUL.3: Phân tích điểm yếu tổng hợp mức\r\n cao hơn cơ bản \r\n | \r\n |
| \r\n | \r\n \r\n AGD_OPE.1 Hướng dẫn người dùng vận hành \r\n | \r\n
| \r\n AGD_PRE.1 Các thủ tục chuẩn bị \r\n | \r\n |
| \r\n | \r\n \r\n ACL_CMC.1 Gắn nhãn cho TOE \r\n | \r\n
| \r\n ACL_CMS.2 Các phần của TOE CM tổng quát \r\n | \r\n |
| \r\n | \r\n \r\n ASE_CCL.1 Các yêu cầu tuân thủ \r\n | \r\n
| \r\n ASE_ECD.1 Định nghĩa các thành phần mở rộng \r\n | \r\n |
| \r\n ASE_INT.1: Giới thiệu ST \r\n | \r\n |
| \r\n ASE_OBJ.2: Các mục tiêu an toàn \r\n | \r\n |
| \r\n ASE_REQ.2: Các yêu cầu an toàn được cung\r\n cấp \r\n | \r\n |
| \r\n ASE_SPD.1 Định nghĩa các vấn đề an toàn \r\n | \r\n |
| \r\n ASE_TSS.1: Đặc tả tổng quát TOE \r\n | \r\n
Đánh giá một PP được yêu cầu để chứng minh\r\nrằng PP là nhất quán và nếu là PP dựa trên một hoặc nhiều PP khác hoặc trong\r\ncác gói, mà PP là một thể hiện đúng của các PP này và các gói. Các thuộc tính\r\nnày là cần thiết cho PP cho phù hợp để sử dụng làm cơ sở để viết ST hay PP\r\nkhác.
\r\n\r\nMục này nên được sử dụng cùng với các Phụ lục\r\nA, B và C trong TCVN 8709-1, như các phụ lục để làm rõ các khái niệm ở đây và\r\ncung cấp nhiều ví dụ.
\r\n\r\nHình 8 cho thấy các họ trong lớp này, và hệ\r\nthống phân cấp của các thành phần trong họ.
\r\n\r\n![](\"00907948_files/image008.jpg\")
9.1.1. Mục tiêu
\r\n\r\nMục tiêu của họ này là mô tả TOE theo một\r\nphạm vi hẹp.
\r\n\r\nĐánh giá giới thiệu PP được đòi hỏi để chứng\r\nminh rằng PP được xác định đúng và tham chiếu PP và tổng quan TOE là nhất quán\r\nvới các thành phần khác.
\r\n\r\n9.1.2. APE_INT.1 Giới thiệu PP
\r\n\r\nCác mối phụ thuộc: không có sự phụ thuộc nào.
\r\n\r\n9.1.2.1. Phần tử hành động của nhà phát triển
\r\n\r\n9.1.2.1.1. APE_INT.1.1D
\r\n\r\nNhà phát triển PP cần cung cấp giới thiệu PP
\r\n\r\n9.1.2.2. Các phần tử nội dung và trình bày
\r\n\r\n9.1.2.2.1. APE_INT.1.1C
\r\n\r\nGiới thiệu PP cần chứa tham chiếu PP và tổng\r\nquan TOE
\r\n\r\n9.1.2.2.2. APE_INT.1.2C
\r\n\r\nTham chiếu PP cần là định danh duy nhất của\r\nPP
\r\n\r\n9.1.2.2.3. APE_INT.1.3C
\r\n\r\nTổng quan TOE cần tóm tắt việc sử dụng và các\r\nđặc trưng an toàn chính của TOE
\r\n\r\n9.1.2.2.4. APE_INT.1.4C
\r\n\r\nTổng quan TOE cần xác định kiểu TOE.
\r\n\r\n9.1.2.2.5. APE_INT_1.5C
\r\n\r\nTổng quan TOE cần xác định bất kỳ phần cứng,\r\nphần mềm và phần sụn không phải TOE có trong TOE.
\r\n\r\n9.1.2.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n9.1.2.3.1. APE_INT.1.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\ncung cấp đáp ứng mọi yêu cầu về chứng cứ cho nội dung và trình bày.
\r\n\r\n9.2.1. Mục tiêu
\r\n\r\nMục tiêu của họ này là quyết định giá trị của\r\ncác yêu cầu tuân thủ. Thêm vào đó, họ này chỉ ra làm sao mà ST và các PP khác\r\nđược yêu cầu tuân thủ với PP.
\r\n\r\n9.2.2. APE_CCL.1 Các yêu cầu tuân thủ
\r\n\r\nCác phụ thuộc:
\r\n\r\nAPE_INT.1 Giới thiệu PP
\r\n\r\nAPE_ECD.1 Định nghĩa các thành phần mở rộng
\r\n\r\nAPE_REQ.1 Nêu các yêu cầu an toàn.
\r\n\r\n9.2.2.1. Phần tử hành động của nhà phát triển
\r\n\r\n9.2.2.1.1. APE_CCL.1.1D
\r\n\r\nNhà phát triển cần cung cấp yêu cầu tuân thủ
\r\n\r\n9.2.2.1.2. APE_CCL.1.2D
\r\n\r\nNhà phát triển cần cung cấp sở cứ các yêu cầu\r\ntuân thủ
\r\n\r\n9.2.2.1.3. APE_CCL.1.3D
\r\n\r\nNhà phát triển cần cung cấp các tuyên bố về\r\ntuân thủ
\r\n\r\n9.2.2.2. Các phần tử nội dung và trình bày
\r\n\r\n9.2.2.2.1. APE_CCL.1.1C
\r\n\r\nCác yêu cầu tuân thủ cần chứa yêu cầu tuân\r\nthủ TCVN 8709 mà xác định phiên bản của TCVN 8709 mà PP yêu cầu tuân thủ.
\r\n\r\n9.2.2.2.2. APE_CCL.1.2C
\r\n\r\nCác yêu cầu tuân thủ TCVN 8709 cần mô tả sự\r\ntuân thủ của PP theo TCVN 8709-2 cũng như là sự tuân thủ TCVN 8709-2 hoặc mở\r\nrộng của TCVN 8709-2.
\r\n\r\n9.2.2.2.3. APE_CCL.1.3C
\r\n\r\nCác yêu cầu tuân thủ TCVN 8709 cần mô tả sự\r\ntuân thủ của PP theo phần này của TCVN 8709 cũng như là sự tuân thủ phần này\r\ncủa TCVN 8709 hoặc phần này của phần mở rộng TCVN 8709.
\r\n\r\n9.2.2.2.4. APE_CCL.1.4C
\r\n\r\nYêu cầu tuân thủ TCVN 8709 cần nhất quán với\r\nđịnh nghĩa các thành phần mở rộng
\r\n\r\n9.2.2.2.5. APE_CCL.1.5C
\r\n\r\nYêu cầu tuân thủ TCVN 8709 cần chỉ ra tất cả\r\nPP và các gói yêu cầu an toàn mà PP yêu cầu tuân thủ.
\r\n\r\n9.2.2.2.6. APE_CCL.1.6C
\r\n\r\nYêu cầu tuân thủ cần mô tả bất kỳ sự tuân thủ\r\nnào của PP theo gói cũng như gói tuân thủ hay gói tăng cường khác.
\r\n\r\n9.2.2.2.7. APE_CCL.1.7C
\r\n\r\nSở cứ cho yêu cầu tuân thủ về cần chứng minh\r\nrằng kiểu TOE này là nhất quán với kiểu TOE trong các PP mà sự tuân thủ đang\r\nđược yêu cầu.
\r\n\r\n9.2.2.2.8. APE_CCL.1.8C
\r\n\r\nSở cứ cho yêu cầu tuân thủ sẽ chứng minh rằng\r\ntuyên bố định nghĩa các vấn đề an toàn là nhất quán với tuyên bố về định nghĩa\r\ncác vấn đề an toàn bên trong các PP mà sự tuân thủ đang được yêu cầu.
\r\n\r\n9.2.2.2.9. APE_CCL.1.9C
\r\n\r\nSở cứ cho yêu cầu tuân thủ cần chứng minh\r\nrằng tuyên bố các mục tiêu an toàn là nhất quán với tuyên bố về định nghĩa các\r\nmục tiêu an toàn bên trong các PP mà sự tuân thủ đang được yêu cầu.
\r\n\r\n9.2.2.2.10. APE_CCL.1.10C
\r\n\r\nSở cứ cho yêu cầu tuân thủ cần chứng minh\r\nrằng tuyên bố định nghĩa các yêu cầu an toàn là nhất quán với tuyên bố về định\r\nnghĩa các yêu cầu an toàn bên trong các PP mà sự tuân thủ đang được yêu cầu.
\r\n\r\n9.2.2.2.11. APE_CCL.1.11C
\r\n\r\nTuyên bố tuân thủ cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày các chứng\r\ncứ.
\r\n\r\n9.2.2.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n9.2.2.3.1. APE_CCL.1.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\ncung cấp đáp ứng mọi yêu cầu về chứng cứ cho nội dung và trình bày.
\r\n\r\n9.3.1. Mục tiêu
\r\n\r\nPhần này của PP định nghĩa các vấn đề an toàn\r\nđược đề cập đến trong TOE và môi trường áp dụng của TOE.
\r\n\r\nĐánh giá định nghĩa các vấn đề an toàn được\r\nyêu cầu để chứng minh rằng các vấn đề an toàn dự kiến được đề cập bởi TOE và\r\nmôi trường áp dụng của nó, được định nghĩa rõ ràng.
\r\n\r\n9.3.2. APE_SPD.1 định nghĩa các vấn đề an\r\ntoàn
\r\n\r\nCác mối phụ thuộc: không có sự phụ thuộc nào
\r\n\r\n9.3.2.1. Phần tử hành động của nhà phát triển
\r\n\r\n9.3.2.1.1. APE_SPD.1.1D
\r\n\r\nNhà phát triển cần cung cấp định nghĩa các\r\nvấn đề an toàn
\r\n\r\n9.3.2.2. Nội dung và trình bày của các thành\r\nphần
\r\n\r\n9.3.2.2.1. APE_SPD.1.1C
\r\n\r\nĐịnh nghĩa các vấn đề an toàn cần mô tả các\r\nmối đe dọa.
\r\n\r\n9.3.2.2.2. APE_SPD.1.2C
\r\n\r\nTất cả các mối đe dọa cần được mô tả dưới\r\ndạng tác nhân gây nguy cơ, tài sản và các hành động thù địch.
\r\n\r\n9.3.2.2.3. APE_SPD.1.3C
\r\n\r\nĐịnh nghĩa vấn đề an toàn cần mô tả các OSP.
\r\n\r\n9.3.2.2.4. APE_SPD.1.4C
\r\n\r\nĐịnh nghĩa các vấn đề an toàn cần mô tả giả\r\nthiết về môi trường vận hành của TOE.
\r\n\r\n9.3.2.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n9.3.2.3.1. APE_SPD.1.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\ncung cấp đáp ứng mọi yêu cầu về chứng cứ cho nội dung và trình bày.
\r\n\r\n9.4.1. Mục tiêu
\r\n\r\nCác mục tiêu an toàn là tuyên bố ngắn gọn của\r\nphản ứng dự định cho vấn đề an toàn được định nghĩa thông qua định nghĩa các\r\nvấn đề an toàn (họ APE_SPD).
\r\n\r\nĐánh giá các mục tiêu an toàn được đòi hỏi để\r\nchứng minh rằng các mục tiêu an toàn được đề cập đến là tương xứng và đầy đủ\r\ncho các vấn đề an toàn và sự phân tách giữa TOE và môi trường áp dụng nó sẽ\r\nđược định nghĩa rõ ràng.
\r\n\r\n9.4.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức ra\r\ndựa trên việc quy định chúng là mục tiêu an toàn cho môi trường áp dụng hay mục\r\ntiêu an toàn cho TOE.
\r\n\r\n9.4.3. APE_OBJ.1 Các mục tiêu an toàn cho môi\r\ntrường áp dụng
\r\n\r\nCác mối phụ thuộc: không có sự phụ thuộc nào.
\r\n\r\n9.4.3.1. Phần tử hành động của nhà phát triển
\r\n\r\n9.4.3.1.1. APE_OBJ.1.1D
\r\n\r\nNhà phát triển PP cần cung cấp tuyên bố các\r\nmục tiêu an toàn.
\r\n\r\n9.4.3.2. Các phần tử nội dung và trình bày
\r\n\r\n9.4.3.2.1. APE_OBJ.1.1C
\r\n\r\nTuyên bố các mục tiêu an toàn cần mô tả các\r\nmục tiêu an toàn cho môi trường vận hành.
\r\n\r\n9.4.3.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n9.4.3.3.1. APE_OBJ.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các chứng cứ.
\r\n\r\n9.4.4. APE_OBJ.2 Các mục tiêu an toàn
\r\n\r\nCác phụ thuộc: APE_SPD.1 định nghĩa vấn đề an\r\ntoàn
\r\n\r\n9.4.4.1. Phần tử hành động của nhà phát triển
\r\n\r\n9.4.4.1.1. APE_OBJ.2.1D
\r\n\r\nNhà phát triển cần cung cấp tuyên bố về các\r\nmục tiêu an toàn
\r\n\r\n9.4.4.1.2. APE_OBJ.2.2D
\r\n\r\nNhà phát triển cần cung cấp sở cứ cho các mục\r\ntiêu an toàn.
\r\n\r\n9.4.4.2. Các phần tử nội dung và trình bày
\r\n\r\n9.4.4.2.1. APE_OBJ.2.1C
\r\n\r\nTuyên bố về mục tiêu an toàn cần mô tả các\r\nmục tiêu an toàn cho TOE và các mục tiêu an toàn cho môi trường áp dụng.
\r\n\r\n9.4.4.2.2. APE_OBJ.2.2C
\r\n\r\nSở cứ các mục tiêu an toàn cần theo vết từng\r\nmục tiêu an toàn cho TOE chống lại các nguy cơ bởi các mục tiêu an toàn đó và\r\ncác OSP được thực hiện bởi các mục tiêu an toàn.
\r\n\r\n9.4.4.2.3. APE_OBJ.2.3C
\r\n\r\nSở cứ các mục tiêu an toàn cần theo vết từng\r\nmục tiêu an toàn cho môi trường áp dụng chống lại các nguy cơ bởi các mục tiêu\r\nan toàn đó và các OSP được thực hiện bởi các mục tiêu an toàn và giả định duy\r\ntrì các mục tiêu an toàn.
\r\n\r\n9.4.4.2.4. APE_OBJ.2.4C
\r\n\r\nSở cứ các mục tiêu an toàn cần chứng minh\r\nrằng các mục tiêu an toàn chống lại tất cả các nguy cơ.
\r\n\r\n9.4.4.2.5. APE_OBJ.2.5C
\r\n\r\nSở cứ các mục tiêu an toàn cần chứng minh\r\nrằng các mục tiêu an toàn thực thi tất cả OSP.
\r\n\r\n9.4.4.2.6. APE_OBJ.2.6C
\r\n\r\nSở cứ các mục tiêu an toàn cần chứng minh\r\nrằng các mục tiêu an toàn cho môi trường áp dụng duy trì tất cả các giả định.
\r\n\r\n9.4.4.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n9.4.4.3.1. APE_OBJ.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày các chứng\r\ncứ.
\r\n\r\n9.5.1. Mục tiêu
\r\n\r\nCác yêu cầu an toàn mở rộng là các yêu cầu mà\r\nkhông dựa trên các thành phần từ TCVN 8709-2 hay phần này của TCVN 8709 mà dựa\r\ntrên các thành phần mở rộng: các thành phần được định nghĩa bởi tác giả PP.
\r\n\r\nĐánh giá định nghĩa các thành phần mở rộng là\r\ncần thiết để quyết định rằng chúng rất rõ ràng và không mập mờ, và chúng là cần\r\nthiết, ví dụ chúng không thể được biểu diễn rõ ràng nếu sử dụng các thành phần\r\nđang có trong TCVN 8709-2 hoặc phần này của TCVN 8709
\r\n\r\n9.5.2. APE_ECD.1 định nghĩa các thành phần mở\r\nrộng
\r\n\r\nCác mối phụ thuộc: không có sự phụ thuộc nào.
\r\n\r\n9.5.2.1. Phần tử hành động của nhà phát triển
\r\n\r\n9.5.2.1.1. APE_ECD.1.1D
\r\n\r\nNhà phát triển cần cung cấp tuyên bố về các yêu\r\ncầu an toàn
\r\n\r\n9.5.2.1.2. APE_ECD.1.2D
\r\n\r\nNhà phát triển cần cung cấp định nghĩa các\r\nthành phần mở rộng
\r\n\r\n9.5.2.2. Các phần tử nội dung và trình bày
\r\n\r\n9.5.2.2.1. APE_ECD.1.1C
\r\n\r\nTuyên bố các yêu cầu an toàn cần xác định tất\r\ncả các yêu cầu an toàn mở rộng.
\r\n\r\n9.5.2.2.2. APE_ECD.1.2C
\r\n\r\nĐịnh nghĩa các thành phần mở rộng cần xác\r\nđịnh thành phần mở rộng cho từng yêu cầu an toàn mở rộng.
\r\n\r\n9.5.2.2.3. APE_ECD.1.3C
\r\n\r\nĐịnh nghĩa các thành phần mở rộng cần được mô\r\ntả mỗi thành phần mở rộng có quan hệ thế nào với các lớp, họ và thành phần đang\r\ncó trong TCVN 8709.
\r\n\r\n9.5.2.2.4. APE_ECD.1.4C
\r\n\r\nĐịnh nghĩa các thành phần mở rộng cần sử dụng\r\ncác lớp, họ, thành phần của TCVN 8709 đang tồn tại như là mô hình cho sự trình\r\nbày.
\r\n\r\n9.5.2.2.5. APE_ECD.1.5C
\r\n\r\nCác thành phần mở rộng cần sử dụng phương\r\npháp, lớp, họ và thành phần đang có trong TCVN 8709 như là mô hình trong sự\r\ntrình bày.
\r\n\r\n9.5.2.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n9.5.2.3.1. APE_ECD.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày của các\r\nchứng cứ.
\r\n\r\n9.5.2.3.2. APE_ECD.1.2E
\r\n\r\nĐánh giá viên cần xác nhận rằng không thành\r\nphần mở rộng nào được biểu diễn rõ ràng sử dụng các thành phần đang tồn tại.
\r\n\r\n9.6.1. Mục tiêu
\r\n\r\nSFR được mô tả một cách rõ ràng, không lẫn\r\nlộn được xác định hoàn toàn các hành vi an toàn mong muốn của TOE. SAR được mô\r\ntả một cách rõ ràng, không lẫn lộn được hoàn toàn xác định các hoạt động mong\r\nmuốn mà có trách nhiệm đạt được sự đảm bảo trong TOE.
\r\n\r\nĐánh giá các yêu cầu an toàn được yêu cầu để\r\nđảm bảo rằng chúng là rõ ràng, không lẫn lộn và được hoàn toàn xác định.
\r\n\r\n9.6.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức mà\r\nchúng được quy định hay SFR được bắt nguồn từ các mục tiêu an toàn cho TOE.
\r\n\r\n9.6.3. APE_REQ.1 Các yêu cầu an toàn được\r\ntuyên bố
\r\n\r\nCác phụ thuộc: APE_ECD.1 Định nghĩa các thành\r\nphần mở rộng
\r\n\r\n9.6.3.1. Phần tử hành động của nhà phát triển
\r\n\r\n9.6.3.1.1. APE_REQ.1.1D
\r\n\r\nNhà phát triển cần cung cấp tuyên bố về các\r\nyêu cầu an toàn
\r\n\r\n9.6.3.1.2. APE_REQ.1.2D
\r\n\r\nNhà phát triển cần cung cấp các sở cứ về các\r\nyêu cầu an toàn
\r\n\r\n9.6.3.2. Các phần tử nội dung và trình bày
\r\n\r\n9.6.3.2.1. APE_REQ.1.1C
\r\n\r\nTuyên bố về các yêu cầu an toàn cần mô tả các\r\nSFR và SAR
\r\n\r\n9.6.3.2.2. APE_REQ.1.2C
\r\n\r\nTất cả các đối tượng, mục tiêu, hoạt động,\r\nthuộc tính an toàn, các thực thể bên ngoài và các nhóm khác được sử dụng trong\r\nSFR và SAR, cần được xác định.
\r\n\r\n9.6.3.2.3 APE_REQ.1.3C
\r\n\r\nTuyên bố về các yêu cầu an toàn cần xác định\r\ntất cả các quá trình hoạt động trong các yêu cầu an toàn.
\r\n\r\n9.6.3.2.4. APE_REQ.1.4C
\r\n\r\nTất cả các hoạt động cần phải thực hiện đúng
\r\n\r\n9.6.3.2.5. APE_REQ.1.5C
\r\n\r\nMỗi phụ thuộc của các yêu cầu an toàn không\r\nchỉ cần được thỏa mãn mà sở cứ các yêu cầu an toàn cần phải biện minh cho các\r\nphụ thuộc không được thỏa mãn.
\r\n\r\n9.6.3.2.6. APE_REQ.1.6C
\r\n\r\nTuyên bố về các yêu cầu an toàn cần phải có\r\ntính nhất quán nội bộ.
\r\n\r\n9.6.3.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n9.6.3.3.1. APE_REQ.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày của các\r\nchứng cứ.
\r\n\r\n9.6.4. APE_REQ.2 Các yêu cầu an toàn thu được
\r\n\r\nCác phụ thuộc: APE_OBJ.2 Các mục tiêu an toàn
\r\n\r\nAPE_ECD.1 Định nghĩa các thành phần mở rộng
\r\n\r\n9.6.4.1. Phần tử hành động của nhà phát triển
\r\n\r\n9.6.4.1.1. APE_REQ.2.1D
\r\n\r\nNhà phát triển cần cung cấp tuyên bố về các\r\nyêu cầu an toàn
\r\n\r\n9.6.4.1.2. APE_REQ.2.2D
\r\n\r\nNhà phát triển cần cung cấp sở cứ các yêu cầu\r\nan toàn.
\r\n\r\n9.6.4.2. Các phần tử nội dung và trình bày
\r\n\r\n9.6.4.2.1. APE_REQ.2.1C
\r\n\r\nTuyên bố các yêu cầu an toàn cần mô tả SFR và\r\nSAR.
\r\n\r\n9.6.4.2.2. APE_REQ.2.2C
\r\n\r\nTất cả các đối tượng, mục tiêu, hoạt động,\r\nthuộc tính an toàn, các thực thể bên ngoài và các nhóm khác được sử dụng trong\r\nSFR và SAR, cần được xác định.
\r\n\r\n9.6.4.2.3. APE_REQ.2.3C
\r\n\r\nTuyên bố về các yêu cầu an toàn cần xác định\r\ntất cả các quá trình hoạt động trong các yêu cầu an toàn.
\r\n\r\n9.6.4.2.4. APE_REQ.2.4C
\r\n\r\nCác hoạt động cần phải được thực hiện đúng
\r\n\r\n9.6.4.2.5. APE_REQ.2.5C
\r\n\r\nMỗi phụ thuộc của các yêu cầu an toàn không\r\nchỉ cần được thỏa mãn mà sở cứ các yêu cầu an toàn cần phải biện minh cho các\r\nphụ thuộc không được thỏa mãn.
\r\n\r\n9.6.4.2.6. APE_REQ.2.6C
\r\n\r\nSở cứ các yêu cầu an toàn cần theo vết mỗi\r\nSFR quay lại các mục tiêu an toàn cho TOE.
\r\n\r\n9.6.4.2.7. APE_REQ.2.7C
\r\n\r\nSở cứ các yêu cầu an toàn cần chứng minh rằng\r\nSFR đáp ứng tất cả các mục tiêu an toàn cho TOE.
\r\n\r\n9.6.4.2.8. APE_REQ.2.8C
\r\n\r\nSở cứ các yêu cầu an toàn cần giải thích vì\r\nsao các SAP được chọn.
\r\n\r\n9.6.4.2.9. APE_REQ.2.9C
\r\n\r\nTuyên bố về các yêu cầu an toàn cần nhất quán\r\nnội bộ
\r\n\r\n9.6.4.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n9.6.4.3.1. APE_REQ.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các chứng cứ.
\r\n\r\nMục tiêu của đánh giá ST là chứng minh rằng\r\nST đó đã hoàn tất, nhất quán, phù hợp và nếu ST được dựa trên một hoặc nhiều PP\r\nhay các gói, khi đó ST là một thể hiệu đúng của các PP và các gói này. Các\r\nthuộc tính này là cần thiết cho ST để phù hợp cho sử dụng như là cơ sở cho đánh\r\ngiá TOE.
\r\n\r\nPhần này cần được kết nối với các Phụ lục A,\r\nB và C trong TCVN 8709-1, phụ lục này làm rõ các khái niệm ở đây và cung cấp\r\nnhiều ví dụ.
\r\n\r\nHình 9 chỉ ra các họ bên trong lớp này và\r\nphân cấp các thành phần trong các họ này.
\r\n\r\n![](\"00907948_files/image009.jpg\")
10.1.1. Mục tiêu
\r\n\r\nMục tiêu của họ này là mô tả TOE theo một\r\ncách hẹp theo ba mức gồm: Tham chiếu TOE, Tổng quan TOE và mô tả TOE.
\r\n\r\nĐánh giá giới thiệu ST được yêu cầu để chứng\r\nminh rằng ST và TOE được xác định đúng, do đó TOE được mô tả đúng tại 3 mức và\r\nmô tả của 3 mức này nhất quán với mỗi cái khác.
\r\n\r\n10.1.2. ASE_INT.1 Giới thiệu ST
\r\n\r\nCác mối phụ thuộc: Không có sự phụ thuộc nào.
\r\n\r\n10.1.2.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n10.1.2.1.1. ASE_INT.1.1D
\r\n\r\nNhà phát triển cần cung cấp giới thiệu ST.
\r\n\r\n10.1.2.2. Các phần tử nội dung và trình bày
\r\n\r\n10.1.2.2.1. ASE_INT.1.1C
\r\n\r\nGiới thiệu ST cần chứa tham chiếu ST, tham\r\nchiếu TOE, tổng quan TOE và mô tả TOE.
\r\n\r\n10.1.2.2.2. ASE_INT.1.2C
\r\n\r\nTham chiếu ST cần xác định ST duy nhất.
\r\n\r\n10.1.2.2.3. ASE_INT.1.3C
\r\n\r\nTham chiếu TOE cần xác định TOE.
\r\n\r\n10.1.2.2.4. ASE_INT.1.4C
\r\n\r\nTổng quan TOE cần tóm tắt việc sử dụng các\r\nđặc trưng an toàn chính của TOE.
\r\n\r\n10.1.2.2.5. ASE_INT.1.5C
\r\n\r\nTổng quan TOE cần xác định kiểu TOE.
\r\n\r\n10.1.2.2.6. ASE_INT.1.6C
\r\n\r\nTổng quan TOE cần xác định bất kỳ phần cứng,\r\nphần mềm, phần sụn nào không phải TOE được yêu cầu bởi TOE.
\r\n\r\n10.1.2.2.7. ASE_INT.1.7C
\r\n\r\nMô tả TOE cần mô tả phạm vi vật lý của TOE.
\r\n\r\n10.1.2.2.8. ASE_INT.1.8C
\r\n\r\nMô tả TOE cần mô tả phạm vi logic của TOE.
\r\n\r\n10.1.2.3. Phần tử hành động của đánh giá viên
\r\n\r\n10.1.2.3.1 ASE_INT.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày của chứng cứ.
\r\n\r\n10.1.2.3.2. ASE_INT.1.2E
\r\n\r\nĐánh giá viên cần xác nhận rằng tham chiếu\r\nTOE, tổng quan TOE và mô tả TOE là nhất quán với các cái khác.
\r\n\r\n10.2.1. Mục tiêu
\r\n\r\nMục tiêu của họ này là quyết định giá trị của\r\nyêu cầu tuân thủ. Thêm vào đó, họ này chỉ ra làm thế nào các ST yêu cầu tuân\r\nthủ với PP.
\r\n\r\n10.2.2. Mục tiêu
\r\n\r\nMục tiêu của họ này là quyết định giá trị của\r\nyêu cầu tuân thủ. Thêm vào đó, họ này chỉ ra làm thế nào các ST yêu cầu tuân\r\nthủ với PP.
\r\n\r\n10.2.2. ACE_CCL.1 Các yêu cầu tuân thủ
\r\n\r\nCác phụ thuộc:
\r\n\r\nASE_INT.1 ST Giới thiệu
\r\n\r\nASE_ECD.1 Định nghĩa các thành phần mở rộng
\r\n\r\nASE_REQ.1 Tuyên bố về các yêu cầu an toàn
\r\n\r\n10.2.2.1. Các phần tử hành động của đánh giá viên
\r\n\r\n10.2.2.1.1. ASE_CCT.1.1D
\r\n\r\nNhà phát triển cần cung cấp yêu cầu tuân thủ
\r\n\r\n10.2.2.1.2 ASE_CCL.1.2D
\r\n\r\nNhà phát triển cần cung cấp sở cứ yêu cầu\r\ntuân thủ
\r\n\r\n10.2.2.2. Các phần tử nội dung và trình bày
\r\n\r\n10.2.2.2.1. ASE_CCL.1.1C
\r\n\r\nYêu cầu tuân thủ cần chứa yêu cầu tuân thủ\r\nTCVN 8709 để xác định phiên bản của TCVN 8709-2 mà yêu cầu tuân thủ TOE và ST.
\r\n\r\n10.2.2.2.2. ASE_CCL.1.2C
\r\n\r\nYêu cầu tuân thủ TCVN 8709 cần mô tả tuân thủ\r\ncủa ST theo TCVN 8709-2, không chỉ tuân thủ TCVN 8709-2 mà còn TCVN 8709-2 mở\r\nrộng.
\r\n\r\n10.2.2.2.3. ASE_CCL.1.3C
\r\n\r\nYêu cầu tuân thủ TCVN 8709 cần mô tả tuân thủ\r\ncủa ST theo phần này của TCVN 8709 không chỉ tuân thủ theo phần này của TCVN\r\n8709 mà còn theo phần này của TCVN 8709 mở rộng.
\r\n\r\n10.2.2.2.4. ASE_CCL.1.4C
\r\n\r\nYêu cầu tuân thủ TCVN 8709 cần nhất quán với\r\nđịnh nghĩa các thành phần mở rộng.
\r\n\r\n10.2.2.2.5. ASE_CCL.1.5C
\r\n\r\nYêu cầu tuân thủ cần chỉ ra tất cả các PP và\r\ncác gói đảm bảo an toàn mà ST yêu cầu tuân thủ.
\r\n\r\n10.2.2.2.6. ASE_CCL.1.6C
\r\n\r\nYêu cầu tuân thủ cần mô tả bất kỳ tuân thủ\r\nnào của ST theo gói, không chỉ các gói tuân thủ mà cả các gói tăng cường.
\r\n\r\n10.2.2.2.7. ASE_CCL.1.7C
\r\n\r\nSở cứ yêu cầu tuân thủ cần chứng minh rằng\r\nkiểu TOE là nhất quán với kiểu TOE trong PP theo đó sự tuân thủ được yêu cầu.
\r\n\r\n10.2.2.2.8. ASE_CCL.1.8C
\r\n\r\nSở cứ yêu cầu tuân thủ cần chứng minh rằng\r\ntuyên bố của định nghĩa vấn đề an toàn là nhất quán với tuyên bố định nghĩa các\r\nvấn đề an toàn trong PP theo đó sự tuân thủ được yêu cầu.
\r\n\r\n10.2.2.2.9. ASE_CCL.1.9C
\r\n\r\nSở cứ yêu cầu tuân thủ cần chứng minh rằng\r\ncá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\r\ntoàn trong PP theo đó sự tuân thủ được yêu cầu.
\r\n\r\n10.2.2.2.10. ASE_CCL.1.10C
\r\n\r\nSở cứ yêu cầu tuân thủ cần chứng minh rằng\r\ntuyê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\r\ntoàn trong PP mà tại đó sự tuân thủ được yêu cầu.
\r\n\r\n10.2.2.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n10.2.2.3.1. ASE_CCL.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu về nội dung và biểu diễn các chứng cứ.
\r\n\r\n10.3.1. Mục tiêu
\r\n\r\nTrong phần này của ST định nghĩa vấn đề an\r\ntoàn được đề cập bởi TOE và môi trường áp dụng TOE.
\r\n\r\nĐánh giá định nghĩa các vấn đề an toàn được\r\nyêu cầu để chứng minh rằng vấn đề an toàn dự định được đề cập bởi TOE và môi\r\ntrường áp dụng của nó là được định nghĩa rõ ràng.
\r\n\r\n10.3.2. ASE_SPD.1 Định nghĩa vấn đề an toàn
\r\n\r\nCác mối phụ thuộc: không có sự phụ thuộc nào.
\r\n\r\n10.3.2.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n10.3.2.1.1. ASE_SPD.1.1D
\r\n\r\nNhà phát triển cần cung cấp định nghĩa các\r\nvấn đề an toàn
\r\n\r\n10.3.2.2. Các phần tử nội dung và trình bày
\r\n\r\n10.3.2.2.1. ASE_SPD.1.1C
\r\n\r\nĐịnh nghĩa vấn đề an toàn cần mô tả các nguy\r\ncơ
\r\n\r\n10.3.2.2.2. ASE_SPD.1.2C
\r\n\r\nTất cả các nguy cơ cần mô tả dưới dạng tác\r\nnhân nguy cơ, tài sản và hành động bất lợi.
\r\n\r\n10.3.2.2.3. ASE_SPD.1.3C
\r\n\r\nĐịnh nghĩa vấn đề an toàn cần mô tả OSP
\r\n\r\n10.3.2.2.4. ASE_SPD.1.4C
\r\n\r\nĐịnh nghĩa vấn đề an toàn cần mô tả giả thiết\r\nvề môi trường hoạt động của TOE.
\r\n\r\n10.3.2.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n10.3.2.3.1. ASE_SPD.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày của các\r\nchứng cứ.
\r\n\r\n10.4.1. Mục tiêu
\r\n\r\nCác mục tiêu an toàn là tuyên bố ngắn gọn của\r\ncác phản ứng dự định cho các vấn đề về an toàn được định nghĩa qua định nghĩa\r\ncác vấn đề an toàn của họ (ASE_SPD)
\r\n\r\nĐánh giá các mục tiêu an toàn được yêu cầu để\r\nchứng minh rằng các mục tiêu an toàn là phù hợp và đề cập hoàn toàn đến định\r\nnghĩa các vấn đề an toàn mà sự phân chia của vấn đề này giữa TOE và môi trường\r\nhoạt động của nó được định nghĩa rõ ràng.
\r\n\r\n10.4.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức dựa\r\ntrên có hay không việc quy định chỉ các mục tiêu an toàn cho môi trường áp dụng\r\nhay cả các mục tiêu an toàn cho TOE.
\r\n\r\n10.4.3. ASE_OBJ.1 Các mục tiêu an toàn cho\r\nmôi trường hoạt động
\r\n\r\nCác mối phụ thuộc: không có sự phụ thuộc nào.
\r\n\r\n10.4.3.1. Phần tử hành động của nhà phát\r\ntriển.
\r\n\r\n10.4.3.1.1. ASE_OBJ.1.1D
\r\n\r\nNhà phát triển cần cung cấp tuyên bố về mục\r\ntiêu an toàn
\r\n\r\n10.4.3.2. Các phần tử nội dung và trình bày
\r\n\r\n10.4.3.2.1. ASE_OBJ.1.1C
\r\n\r\nTuyên bố về các mục tiêu an toàn cần mô tả\r\ncác mục tiêu an toàn cho môi trường áp dụng
\r\n\r\n10.4.3.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n10.4.3.3.1. ASE_OBJ.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu cho nội dung và biểu diễn các chứng\r\ncứ.
\r\n\r\n10.4.4. ASE_OBJ.2 Các mục tiêu an toàn.
\r\n\r\nCác phụ thuộc: ASE_SPD.1 định nghĩa các vấn\r\nđề an toàn.
\r\n\r\n10.4.4.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n10.4.4.1.1. ASE_OBJ.2.1D
\r\n\r\nNhà phát triển cần cung cấp tuyên bố về các\r\nmục tiêu an toàn.
\r\n\r\n10.4.4.1.2. ASE_OBJ.2.2D
\r\n\r\nNhà phát triển cần cung cấp sở cứ các mục\r\ntiêu an toàn
\r\n\r\n10.4.4.2. Các phần tử nội dung và trình bày
\r\n\r\n10.4.4.2.1. ASE_OBJ.2.1C
\r\n\r\nTuyên bố về các mục tiêu an toàn cần mô tả\r\ncác mục tiêu an toàn cho TOE và các mục tiêu an toàn cho môi trường áp dụng.
\r\n\r\n10.4.4.2.2. ASE_OBJ.2.2C
\r\n\r\nSở cứ các mục tiêu an toàn cần theo vết mỗi\r\nmục tiêu an toàn cho TOE trở lại chống lại các nguy cơ bởi mục tiêu an toàn đó\r\nvà thực thi OSP bởi mục tiêu an toàn đó.
\r\n\r\n10.4.4.2.3. ASE_OBJ.2.3C
\r\n\r\nSở cứ các mục tiêu an toàn cần theo vết mỗi\r\nmục tiêu an toàn cho môi trường áp dụng trở lại chống lại các nguy cơ bởi mục\r\ntiêu an toàn đó, thực thi OSP bởi mục tiêu an toàn đó, và giả thiết duy trì mục\r\ntiêu an toàn đó.
\r\n\r\n10.4.4.2.4. ASE_OBJ.2.4C
\r\n\r\nSở cứ các mục tiêu an toàn cần chứng minh\r\nrằng mục tiêu an toàn chống lại tất cả các nguy cơ.
\r\n\r\n10.4.4.2.5. ASE_OBJ.2.5C
\r\n\r\nSở cứ các mục tiêu an toàn cần chứng minh\r\nrằng mục tiêu an toàn chống lại tất cả các OSP.
\r\n\r\n10.4.4.2.6. ASE_OBJ.2.6C
\r\n\r\nSở cứ các mục tiêu an toàn cần chứng minh\r\nrằng mục tiêu an toàn cho môi trường áp dụng duy trì tất cả các giả thiết.
\r\n\r\n10.4.4.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n10.4.4.3.1. ASE_OBJ.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp cần đáp ứng tất cả các yêu cầu cho nội dung và trình bày các chứng\r\ncứ.
\r\n\r\n10.5.1. Mục tiêu
\r\n\r\nCác yêu cầu an toàn mở rộng là các yêu cầu mà\r\nkhông dựa trên các thành phần từ TCVN 8709-2 hay phần này của TCVN 8709, mà dựa\r\ntrên các thành phần mở rộng: Thành phần được định nghĩa bởi tác giả ST.
\r\n\r\nĐánh giá định nghĩa các thành phần mở rộng\r\ncần thiết để quyết định rằng chúng là rõ ràng và không thể nhầm lẫn, và do đó\r\nchúng là cần thiết, ví dụ chúng có thể được biểu diễn rõ ràng sử dụng TCVN\r\n8709-2 hoặc phần này của các thành phần TCVN 8709.
\r\n\r\n10.5.2. ASE_ECD.1 Định nghĩa các thành phần\r\nmở rộng
\r\n\r\nCác mối phụ thuộc: không có sự phụ thuộc nào.
\r\n\r\n10.5.2.1.1. ASE_ECD.1.1D
\r\n\r\nNhà phát triển cần cung cấp tuyên bố về yêu\r\ncầu an toàn.
\r\n\r\n10.5.2.1.2. ASE_ECD.1
Nhà phát triển cần cung cấp định nghĩa các\r\nthành phần mở rộng.
\r\n\r\n10.5.2.2. Các phần tử nội dung và trình bày
\r\n\r\n10.5.2.2.1. ASE_ECD.1.1C
\r\n\r\nTuyên bố các yêu cầu an toàn cần xác định tất\r\ncả các yêu cầu an toàn mở rộng.
\r\n\r\n10.5.2.2.2. ASE_ECD.1
Định nghĩa các thành phần mở rộng cần định\r\nnghĩa thành phần mở rộng cho mỗi yêu cầu an toàn mở rộng.
\r\n\r\n10.5.2.2.3. ASE_ECD.1
Định nghĩa các thành phần mở rộng cần mô tả\r\nmỗi thành phần mở rộng có mối quan hệ như thế nào với các thành phần, họ và lớp\r\ntrong TCVN 8709 đang tồn tại.
\r\n\r\n10.5.2.2.4. ASE_ECD.1
Định nghĩa các thành phần mở rộng cần sử dụng\r\ncác thành phần, lớp, họ và phương pháp trong TCVN 8709 như một mô hình cho\r\ntrình bày.
\r\n\r\n10.5.2.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n10.5.2.3.1. ASE_ECD.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày của chứng cứ.
\r\n\r\n10.5.2.3.2. ASE_ECD.1
Đánh giá viên cần xác nhận rằng không thành\r\nphần mở rộng nào có thể biểu diễn rõ ràng mà sử dụng các thành phần đang có.
\r\n\r\n10.6.1. Mục tiêu
\r\n\r\nSFR được mô tả một cách rõ ràng, không lẫn\r\nlộn được xác định hoàn toàn các hành vi an toàn mong muốn của TOE. SAR được mô\r\ntả một cách rõ ràng, không lẫn lộn được hoàn toàn xác định các hoạt động mong\r\nmuốn mà có trách nhiệm đạt được sự đảm bảo trong TOE.
\r\n\r\nĐánh giá các yêu cầu an toàn được yêu cầu để\r\nđảm bảo rằng chúng là rõ ràng, không lẫn lộn và được hoàn toàn xác định.
\r\n\r\n10.6.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức\r\ntheo như chúng được tuyên bố.
\r\n\r\n10.6.3. ASE_REQ.1 Định nghĩa các thành phần\r\nmở rộng
\r\n\r\n10.6.3.1. Phần tử hành động của nhà phát\r\ntriển.
\r\n\r\n10.6.3.1.1. ASE_REQ.1.1D
\r\n\r\nNhà phát triển cần cung cấp tuyên bố về yêu\r\ncầu an toàn
\r\n\r\n10.6.3.1.2. ASE_REQ.1.2D
\r\n\r\nNhà phát triển cần cung cấp sở cứ các yêu cầu\r\nan toàn
\r\n\r\n10.6.3.2. Các phần tử nội dung và trình bày
\r\n\r\n10.6.3.2.1. ASE_REQ.1.1C
\r\n\r\nTuyên bố các yêu cầu an toàn cần mô tả SFR và\r\nSAR
\r\n\r\n10.6.3.2.2. ASE_REQ.1.2C
\r\n\r\nTất cả các chủ thể, mục tiêu, hoạt động,\r\nthuộc tính an toàn, thực thể ngoài và các thuật ngữ được sử dụng trong SFR và\r\nSAR cần được định nghĩa.
\r\n\r\n10.6.3.2.3. ASE_REQ.1.3C
\r\n\r\nTuyên bố về các yêu cầu an toàn cần xác định\r\ntất cả các hoạt động dựa trên các yêu cầu an toàn.
\r\n\r\n10.6.3.2.4. ASE_REQ.1.4C
\r\n\r\nTất cả các hoạt động cần thực hiện chính xác.
\r\n\r\n10.6.3.2.5. ASE_REQ.1.5C
\r\n\r\nMỗi các mối phụ thuộc của các yêu cầu an toàn\r\ncần không chỉ sự thỏa mãn mà sở cứ các yêu cầu an toàn cần biện minh cho các\r\nmối phụ thuộc không được thỏa mãn.
\r\n\r\n10.6.3.2.6. ASE_REQ.1.6C
\r\n\r\nTuyên bố về các yêu cầu an toàn cần nhất quán\r\nnội bộ.
\r\n\r\n10.6.3.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n10.6.3.3.1. ASE_REQ.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày các chứng cứ
\r\n\r\n10.6.4. ASE_REQ.2 Các yêu cầu an toàn thu\r\nđược
\r\n\r\nCác phụ thuộc:
\r\n\r\nASE_OBJ.2 Các mục tiêu an toàn
\r\n\r\nASE_ECD.1 Định nghĩa các thành phần mở rộng
\r\n\r\n10.6.4.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n10.6.4.1.1. ASE_REQ.2.1D
\r\n\r\nNhà phát triển cần cung cấp tuyên bố các yêu\r\ncầu an toàn.
\r\n\r\n10.6.4.1.2. ASE_REQ.2.2D
\r\n\r\nNhà phát triển cần cung cấp sở cứ các yêu cầu\r\nan toàn.
\r\n\r\n10.6.4.2. Các phần tử nội dung và trình bày
\r\n\r\n10.6.4.2.1. ASE_REQ.2.1C
\r\n\r\nTuyên bố các yêu cầu an toàn cần mô tả SFR và\r\nSAR.
\r\n\r\n10.6.4.2.2. ASE_REQ.2.2C
\r\n\r\nTất cả các chủ thể, mục tiêu, hoạt động,\r\nthuộc tính an toàn, thực thể ngoài và các thuật ngữ được sử dụng trong SFR và\r\nSAR cần được định nghĩa.
\r\n\r\n10.6.4.2.3. ASE_REQ.2.3C
\r\n\r\nTuyên bố các yêu cầu an toàn cần chỉ ra tất\r\ncả các hoạt động dựa trên các yêu cầu an toàn.
\r\n\r\n10.6.4.2.4. ASE_REQ.2.4C
\r\n\r\nTất cả các hoạt động cần phải thực hiện chính\r\nxác.
\r\n\r\n10.6.4.2.5. ASE_REQ.2.5C
\r\n\r\nMỗi phụ thuộc của các yêu cầu an toàn cần\r\nkhông chỉ thỏa mãn mà sở cứ các yêu cầu an toàn cần biện minh cho các phụ thuộc\r\nmà không được thỏa mãn.
\r\n\r\n10.6.4.2.6. ASE_REQ.2.6C
\r\n\r\nSở cứ các yêu cầu an toàn cần theo vết mỗi\r\nSFR trở lại các mục tiêu an toàn cho TOE.
\r\n\r\n10.6.4.2.7. ASE_REQ.2.7C
\r\n\r\nSở cứ các yêu cầu an toàn cần chứng minh rằng\r\nSFR đáp ứng tất cả các mục tiêu an toàn cho TOE.
\r\n\r\n10.6.4.2.8. ASE_REQ.2.8C
\r\n\r\nSở cứ các yêu cầu an toàn cần giải thích vì\r\nsao SAR được chọn.
\r\n\r\n10.6.4.2.9. ASE_REQ.2.9C
\r\n\r\nTuyên bố các yêu cầu an toàn cần nhất quán\r\nnội bộ.
\r\n\r\n10.6.4.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n10.6.4.3.1. ASE_REQ.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày các chứng\r\ncứ.
\r\n\r\n10.7.1. Mục tiêu
\r\n\r\nĐặc tả tổng quát TOE giúp đánh giá viên và\r\nkhách hàng tiềm năng có được các hiểu biết chung về việc TOE được thực hiện như\r\nthế nào.
\r\n\r\nĐánh giá của đặc tả tổng quát TOE là cần\r\nthiết để quyết định mô tả TOE như thế nào là phù hợp:
\r\n\r\n- Đáp ứng các SFR của nó
\r\n\r\n- Bảo vệ chính nó chống lại sự can thiệp, sự\r\ngiả mạo và phớt lờ ở mức logic.
\r\n\r\nVà các đặc tả tổng quát phải nhất quán với\r\ncác mô tả hẹp khác của TOE.
\r\n\r\n10.7.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức dựa\r\ntrên việc có hay không đặc tả tổng quát TOE là cần thiết để mô tả TOE đáp ứng\r\nSFR như thế nào, hay có hay không đặc tả tổng quát TOE cần thiết để mô tả làm\r\nthể nào TOE bảo vệ chính nó chống lại việc giả mạo hay phớt lờ ở mức logic. Sự\r\nmô tả bổ sung này có thể được sử dụng trong trường hợp đặc biệt tại nơi mà có\r\nthể liên quan xem xét kiến trúc an toàn TOE.
\r\n\r\n10.7.3. ASE_TSS.1 Đặc tả tổng quát TOE
\r\n\r\nCác phụ thuộc:
\r\n\r\nASE_INT.1 Giới thiệu ST
\r\n\r\nASE_REQ.1 Tuyên bố các yêu cầu an toàn
\r\n\r\nASE_REQ.1 Đặc tả chức năng cơ sở
\r\n\r\n10.7.3.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n10.7.3.1.1. ASE_TSS.1.1D
\r\n\r\nNhà phát triển cần cung cấp đặc tả tổng quát\r\nTOE
\r\n\r\n10.7.3.2. Các phần tử nội dung và trình bày
\r\n\r\n10.7.3.2.1. ASE_TSS.1.1C
\r\n\r\nĐặc tả tổng quát TOE cần mô tả TOE đáp ứng\r\nmối SFR như thế nào
\r\n\r\n10.7.3.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n10.7.3.3.1. ASE_TSS.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các chứng cứ
\r\n\r\n10.7.3.3.2. ASE_TSS.1.2E
\r\n\r\nĐánh giá viên cần xác nhận rằng đặc tả tổng\r\nquát TOE nhất quán với tổng quan TOE và mô tả TOE.
\r\n\r\n10.7.4. ASE_TSS.2 Đặc tả tổng quát với kiến\r\ntrúc thiết kế tổng quát.
\r\n\r\nCác phụ thuộc:
\r\n\r\nASE_INT.1 Giới thiệu ST
\r\n\r\nASE_REQ.1 Tuyên bố các yêu cầu an toàn
\r\n\r\nASE_ARC.1 Mô tả các kiến trúc an toàn
\r\n\r\n10.7.4.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n10.7.4.1.1. ASE_TSS.2.1D
\r\n\r\nNhà phát triển cần cung cấp đặc tả tổng quát\r\nTOE
\r\n\r\n10.7.4.2. Các phần tử nội dung và trình bày
\r\n\r\n10.7.4.2.1. ASE_TSS.2.1C
\r\n\r\nĐặc tả tổng quát TOE cần mô tả TOE đáp ứng\r\nmỗi SFR như thế nào.
\r\n\r\n10.7.4.2.2. ASE_TSS.2.2C
\r\n\r\nĐặc tả tổng quát TOE cần mô tả làm thế nào\r\nTOE tự bảo vệ chống lại sự can thiệp và sự giả mạo mức logic.
\r\n\r\n10.7.4.2.3. ASE_TSS.2.3C
\r\n\r\nĐặc tả tổng quát TOE cần mô tả TOE tự bảo vệ\r\nnhư thế nào để chống lại sự phớt lờ.
\r\n\r\n10.7.4.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n10.7.4.3.1. ASE_TSS.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các chứng cứ.
\r\n\r\n10.7.4.3.2. ASE_TSS.2.2E
\r\n\r\nĐánh giá viên cần xác nhận rằng đặc tả tổng\r\nquát TOE là nhất quán với tổng quan TOE và mô tả TOE.
\r\n\r\n\r\n\r\nYêu cầu của lớp phát triển là cung cấp thông\r\ntin về TOE. Kiến thức có được từ thông tin này phải được sử dụng như là cơ sở\r\nđể tạo ra bản phân tích điểm yếu và kiểm tra trên TOE như được mô tả trong lớp\r\nAVA và ATE.
\r\n\r\nLớp phát triển bao gồm 6 họ các yêu cầu cho\r\nviệc cấu trúc và biểu diễn TSF tại các mức thay đổi và các dạng thay đổi trừu\r\ntượng. Những họ này bao gồm:
\r\n\r\n● Yêu cầu đối với mô tả thiết kế và thực hiện\r\ncác SFR (ADV_FSP, ADV_TDS, ADV_IMP) (ở các mức độ trừu tượng khác nhau)
\r\n\r\n● Yêu cầu đối với mô tả về các tính năng\r\nhướng dẫn kiến trúc theo định hướng tách miền, khả năng tự bảo vệ và không thể\r\nvượt qua của TSF trong chức năng an toàn (ADV_ARC)
\r\n\r\n● Yêu cầu mô hình chính sách an toàn và cho\r\nánh xạ tương ứng giữa các mô hình chính sách an toàn và đặc tả chức năng\r\n(ADV_SPM)
\r\n\r\n● Yêu cầu về cơ cấu nội bộ của TSF, bao gồm\r\ncác khía cạnh như mô đun, phân lớp, và giảm thiểu độ phức tạp (ADV_INT).
\r\n\r\nKhi lập tài liệu các chức năng an toàn của\r\nTOE, có hai thuộc tính cần phải được chứng minh. Thuộc tính đầu tiên là các\r\nchức năng an toàn làm việc chính xác, có nghĩa là, nó thực hiện theo quy định.\r\nThuộc tính thứ hai, đòi hỏi một cách tiếp cận khó khăn hơn trong để chứng minh,\r\ntheo đó TOE không thể được sử dụng theo cách như vậy mà các chức năng bảo mật\r\ncó thể bị hỏng hoặc bỏ qua. Hai thuộc tính này yêu cầu một cách khác trong tiếp\r\ncận phân tích, và vì thế họ ADV được cấu trúc để hỗ trợ các phương pháp tiếp\r\ncận khác nhau. Các họ đặc tả chức năng (ADV_FSP), thiết kế TOE (ADV_TDS), biểu\r\ndiễn triển khai (ADV_IMP), và mô hình chính sách an toàn (ADV_SPM) sẽ thực hiện\r\nvới thuộc tính đầu tiên: đặc tả của chức năng an toàn. Các họ Kiến trúc\r\n(ADV_ARC) và TSF internals (ADV_INT) đối phó với các bất động sản thứ hai: các\r\nđặc điểm kỹ thuật của các thiết kế của TOE thể hiện các chức năng bảo mật không\r\nthể bị hỏng hoặc bỏ qua. Cần lưu ý rằng cả hai thuộc tính cần phải được nhận\r\nbiết: thuộc tính càng bí mật được thỏa mãn thì TOE càng tin cậy. Các thành phần\r\ntrong họ được thiết kế bởi vì sự đảm bảo tăng khi có được sự phân cấp tăng.
\r\n\r\nCác mô hình cho các họ nhắm mục tiêu vào các\r\nthuộc tính đầu tiên là một trong phân rã thiết kế. Ở mức cao nhất, có một đặc\r\ntả chức năng của TSF về giao diện của nó (mô tả những gì TSF làm để yêu cầu TSF\r\ncho các dịch vụ và trả lời kết quả), phân rã các TSF thành các đơn vị nhỏ hơn\r\n(Phụ thuộc vào việc bảo đảm mong muốn và sự phức tạp của TOE) và mô tả cách TSF\r\nđã thực hiện được chức năng của mình (với một mức độ chi tiết tương xứng với\r\nmức độ bảo đảm), và cho thấy việc thực hiện các TSF. Một mô hình chính thức của\r\ncác hành vi an toàn cũng có thể được đưa ra. Tất cả các mức phân rã thường được\r\nsử dụng trong việc xác định tính đầy đủ và chính xác của các mức khác nhau, để\r\nđảm bảo rằng các mức có hỗ trợ lẫn nhau. Các yêu cầu để biểu diễn TSF khác nhau\r\nđược tách thành các họ khác nhau, để cho phép các tác giả PP/ST chỉ ra các biểu\r\ndiễn TSF nào được yêu cầu. Mức độ được lựa chọn sẽ quyết định dự đoán bảo đảm\r\nhay mong muốn sẽ đạt được.
\r\n\r\nHình 10 chỉ ra các mối quan hệ giữa sự biểu\r\ndiễn TSF khác nhau của lớp ADV, cũng như mối quan hệ của chúng với các lớp\r\nkhác. Số liệu cho thấy, các lớp APE và ASE định nghĩa các yêu cầu về sự tương\r\nứng giữa các SFR và các mục tiêu an toàn cho TOE. Lớp ASE cũng định nghĩa các\r\nyêu cầu cho sự tương ứng giữa hai mục tiêu an toàn và SFR, và với các đặc tả\r\ntóm tắt TOE để giải thích làm thế nào TOE đáp ứng SFR của nó. Các hoạt động của\r\nALC_CMC.5.2E bao gồm việc xác minh rằng các TSF đã được kiểm thử với lớp ATE và\r\nAVA trong thực tế, một trong những mô tả của tất cả các cấp mức độ phân rã ADV.
\r\n\r\n![](\"00907948_files/image010.jpg\")
Các yêu cầu cho tất cả các đáp ứng khác thể\r\nhiện trong hình 10 được định nghĩa trong lớp ADV. Các mô hình chính sách an\r\ntoàn họ (ADV_SPM) xác định các yêu cầu về mô hình chính thức SFR được chọn, và\r\ncung cấp đáp ứng giữa các đặc tả chức năng và mô hình chính thức. Mỗi họ đảm\r\nbảo cụ thể cho một đại diện TSF (tức là chức năng đặc điểm kỹ thuật (ADV_FSP),\r\nthiết kế TOE (ADV_TDS) và biểu diễn triển khai (ADV_IMP)) xác định các yêu cầu\r\nliên quan mà TSF đại diện cho các SFR. Tất cả các phân rã phải phản ánh chính\r\nxác tất cả các phân rã khác (ví dụ, có thể hỗ trợ lẫn nhau); Nhà phát triển\r\ncung cấp khả năng theo vết với phần tử C cuối của các thành phần. Bảo đảm liên\r\nquan đến yếu tố này là thu được trong quá trình phân tích cho từng mức độ phân\r\nrã bằng cách tham chiếu đến mức độ khác của sự phân rã (một cách đệ quy) trong\r\nkhi các phân tích của một mức độ cụ thể của việc phân rã đang được thực hiện;\r\nĐánh giá viên thẩm tra sự tương ứng như là một phần của phần tử E thứ hai.\r\nNhững hiểu biết thu được từ các mức độ phân rã tạo thành cơ sở của những nỗ lực\r\nkiểm thử chức năng và thâm nhập.
\r\n\r\nHọ ADV_INT không được biểu diễn trong hình\r\nnày, vì nó có liên quan đến cấu trúc bên trong của TSF, và liên quan gián tiếp\r\nđến quá trình tinh chỉnh các đại diện của TSF. Tương tự, họ ADV_ARC là không\r\nđược biểu diễn trong hình vì nó liên quan đến tính hợp lý kiến trúc, hơn là\r\nviệc biểu diễn, của các TSF. Cả ADV_INT và ADV_ARC liên quan đến việc phân tích\r\ncác thuộc tính mà các TOE không thể thực hiện để phá vỡ hoặc làm hỏng chức năng\r\nan toàn của nó.
\r\n\r\nChức năng an toàn TOE (TSF) bao gồm tất cả\r\ncác phần của TOE mà cần phải dựa vào thực thi của SFR. TSF bao gồm cả chức năng\r\ntrực tiếp thực thi các SFR, cũng như các chức năng đó, mà không trực tiếp thực\r\nthi các SFR, góp phần thực thi của chúng một cách gián tiếp nhiều hơn, bao gồm\r\ncả chức năng với khả năng là nguyên nhân các SFR bị vi phạm. Điều này bao gồm\r\ncác phần của TOE được viện dẫn lúc bắt đầu mà có trách nhiệm đưa TSF vào trạng thái\r\nan toàn ban đầu của nó.
\r\n\r\nMột số khái niệm quan trọng được sử dụng\r\ntrong sự phát triển của các thành phần của họ ADV. Những khái niệm, được giới\r\nthiệu ngắn gọn ở đây, được giải thích đầy đủ hơn trong các ghi chú cho các họ.
\r\n\r\nMột quan điểm chỉ ra là càng nhiều thông tin\r\nsẵn sàng thì càng đạt được mức độ đảm bảo cao hơn về chức năng an toàn thông\r\ntin. 1) được thực hiện chính xác, 2) không thể bị sửa đổi và 3) không thể bị\r\nvượt qua. Điều này được thực hiện thông qua việc thẩm tra sự nhất quán và chính\r\nxác của các tài liệu với các tài liệu khác, và với việc cung cấp thông tin có\r\nthể được sử dụng để đảm bảo rằng các hoạt động kiểm tra là toàn diện (cả hai\r\nkiểm tra về chức năng và thâm nhập). Điều này được phản ánh sự phân mức thành\r\nphần của họ. Nhìn chung, các thành phần được phân mức dựa trên số lượng thông\r\ntin mà được cung cấp (và được phân tích sau đó).
\r\n\r\nMặc dù không phải đúng với tất cả các TOE,\r\ntrong trường hợp nói chung khi TSF có đủ phức tạp mà có các phần của TSF được\r\nkiểm tra tăng cường hơn các phần khác của TSF. Không may việc quyết định các\r\nphần này có phần chủ quan, do đó thuật ngữ và thành phần đã được định nghĩa như\r\nvậy mà là mức tăng đảm bảo, trách nhiệm trong việc quyết định các phần nào của\r\nTSF cần phải xem xét thay đổi chi tiết từ nhà phát triển đến đánh giá viên. Để\r\nhỗ trợ trong việc thể hiện khái niệm này, theo các thuật ngữ được giới thiệu.\r\nCần lưu ý rằng trong các họ của lớp, thuật ngữ này được sử dụng khi biểu diễn\r\ncác phần liên quan đến SFR của TOE (nghĩa là, các phần tử và các đơn vị làm việc\r\nthể hiện bên trong các đặc tả chức năng (ADV_FSP), thiết kế TOE (ADV_TDS), và\r\nbiểu diễn thực hiện của các họ (ADV_IMP)). Khi đó, khái niệm chung (với một số\r\nphần của TOE hấp dẫn hơn các phần khác) được áp dụng với các họ khác, tiêu chí\r\nnày được biểu diễn dưới cách khác để đạt được yêu cầu đảm bảo.
\r\n\r\nTất cả các phần của TSF là phù hợp an toàn,\r\nnghĩa là chúng cần phải bảo vệ an toàn của TOE như được biểu diễn bởi các SFR\r\nvà các yêu cầu cho việc chia cắt miền và không thể đi đường vòng. Một khía cạnh\r\nphù hợp an toàn khác là mức độ mà một phần của TSF thực thi yêu cầu an toàn.\r\nCác phần khác nhau của TOE thực hiện các vai trò khác nhau (hoặc vai trò không\r\nrõ ràng ở tất cả) trong việc thực thi các yêu cầu an toàn, điều này tạo ra một\r\nsự liên tục với SFR liên quan: tại một đầu của sự liên tục này là các phần của\r\nTOE được gọi là thực thi-SFR. Các phần này đóng một vai trò trực tiếp trong\r\nviệc thực hiện bất kỳ SFR nào trong TOE này. SFR như thế tham chiếu đến bất kỳ\r\nchức năng cung cấp bởi một trong những SFR có trong ST này. Cần lưu ý rằng việc\r\nđịnh nghĩa của việc thực hiện vai trò trong chức năng thực thi-SFR là không thể\r\nbiểu diễn số lượng. Ví dụ, trong việc thực hiện cơ chế kiểm soát truy nhập tùy\r\ný (DAC), cái nhìn hẹp thực thi-SFR có thể chỉ là một vài dòng mã thực sự thực\r\nhiện việc kiểm tra các thuộc tính của chủ thể chống lại các thuộc tính của đối\r\ntượng. Một cái nhìn rộng hơn sẽ bao gồm các thực thể phần mềm (ví dụ, chức năng\r\nC) có chứa một số dòng mã. Một cái nhìn rộng hơn vẫn sẽ bao gồm những người gọi\r\ncủa chức năng C, bởi vì chúng sẽ chịu trách nhiệm thi hành quyết định được trả\r\nvề bởi việc kiểm tra thuộc tính. Một cái nhìn rộng hơn sẽ bao gồm bất kỳ mã nào\r\ntrong cây gọi (hoặc chương trình tương đương cho việc thực hiện các ngôn ngữ\r\nđược sử dụng) cho chức năng C đó (ví dụ, một chức năng sắp xếp mà các thực thể\r\ntrong danh sách điều khiển truy cập được sắp xếp sử dụng thuật toán first-match\r\n- chọn phù hợp đầu tiên). Tại một số điểm, thành phần này không được thực thi\r\nnhiều trong sách an toàn, mà đóng vai trò hỗ trợ, các thành phần như vậy được\r\ngọi là hỗ trợ SFR.
\r\n\r\nMột trong các tính chất của chức năng hỗ trợ\r\nSFR là nó được tin cậy để thực hiện việc chỉnh sửa việc thực hiện SFR trong quá\r\ntrình áp dụng mà không có lỗi. Chức năng này có thể bị phụ thuộc vào chức năng\r\nthực thi SFR, nhưng các mối phụ thuộc này thường ở mức độ chức năng, ví dụ như\r\nquản lý bộ nhớ, quản lý bộ đệm, v.v… Việc giảm liên tục độ tương quan an toàn\r\nđược gọi là không can thiệp vào SFR (SFR no-interfering). Chức năng như vậy\r\nkhông có vai trò trong việc thực hiện các SFR, và là một phần tương tự của TSF\r\nvì môi trường của nó: ví dụ, bất kỳ mã chạy trong một chế độ phần cứng đặc\r\nquyền của hệ điều hành. Nó cần phải được coi là một phần của TSF bởi vì, nếu bị\r\nxâm nhập (hoặc thay thế bởi mã độc hại), nó có thể làm ảnh hưởng tới hoạt động\r\nchính xác của SFR bởi ưu điểm của việc hoạt động trong chế độ phần cứng đặc\r\nquyền. Một ví dụ về chức năng không can thiệp vào SFR có thể là một tập hợp các\r\nứng dụng dấu chấm động trong toán học nổi thực hiện chế độ nhân cho các suy xét\r\nvề tốc độ.
\r\n\r\nHọ kiến trúc (Kiến trúc an toàn (ADV_ARC))\r\ncung cấp các yêu cầu và phân tích của TOE dựa trên các thuộc tính phân tách\r\nmiền, tự bảo vệ, và không thể vượt qua. Những thuộc tính liên quan đến các SFR\r\ntrong đó, nếu những thuộc tính này không có mặt, nó có thể sẽ dẫn đến lỗi của\r\ncác cơ chế thực hiện SFR. Chức năng và thiết kế liên quan đến các thuộc tính\r\nnày không được coi là một phần trong mô tả liên tục ở trên, nhưng thay vì được\r\nxử lý riêng do bản chất khác nhau của nó và các yêu cầu phân tích.
\r\n\r\nSự khác biệt trong phân tích việc thực hiện\r\ncác SFR (chức năng thực thi SFR và hỗ trợ SFR) và thực hiện một số thuộc tính\r\nan toàn nền tảng khác của TOE, bao gồm các vấn đề liên quan khởi tạo, tự bảo vệ\r\nvà không thể vượt qua, đó là chức năng liên quan đến SFR mà nhiều hay ít có thể\r\nthấy được trực tiếp và tương đối dễ dàng cho việc kiểm tra, khi đó các thuộc\r\ntính được đề cập ở trên yêu cầu các mức độ phân tích khác nhau trong các tập\r\nrộng hơn nhiều của chức năng. Hơn nữa, độ sâu phân tích các thuộc tính đó sẽ\r\nthay đổi phụ thuộc vào thiết kế của TOE. Họ ADV được xây dựng để giải quyết\r\nđiều này bằng một họ riêng biệt (Kiến trúc an toàn (ADV_ARC)) dành cho việc\r\nphân tích các yêu cầu khởi tạo, tự bảo vệ, và không thể vượt qua, trong khi các\r\nhọ khác có liên quan với phân tích các chức năng hỗ trợ SFR.
\r\n\r\nNgay cả trong trường hợp các mô tả khác nhau\r\nlà cần thiết cho nhiều cấp độ trừu tượng, nó không phải là hoàn toàn cần thiết\r\ncho mỗi và mọi đại diện TSF chứa trong một văn bản riêng. Thật vậy, nó có thể\r\nlà trường hợp mà một tài liệu duy nhất đáp ứng các yêu cầu lập tài liệu cho\r\nviệc biểu diễn nhiều hơn một TSF, vì nó là thông tin về mỗi cái trong các đại\r\ndiện TSF đó là cần thiết, hơn là các cấu trúc tài liệu kết quả. Trong trường\r\nhợp nhiều đại diện TSF được kết hợp trong một tài liệu duy nhất, các nhà phát\r\ntriển nên chỉ ra các phần của tài liệu đáp ứng được yêu cầu.
\r\n\r\nBa loại kiểu đặc tả kỹ thuật được ủy quyền\r\ncủa lớp này: không chính thức, bán chính thức và chính thức. Các đặc tả chức\r\nnăng và tài liệu thiết kế TOE luôn luôn được viết bằng một trong hai phong cách\r\nchính thức hoặc bán chính thức. Kiểu bán chính thức làm giảm sự không rõ ràng\r\ntrong các tài liệu này trên một bài trình bày không chính thức. Một đặc tả chính\r\nthức có thể được yêu cầu thêm vào các bài trình bày bán chính thức, giá trị này\r\nlà một mô tả của TSF trong nhiều hơn một cách sẽ tăng thêm bảo đảm rằng các TSF\r\nđã được xác định hoàn toàn và chính xác.
\r\n\r\nMột đặc điểm kỹ thuật không chính thức được\r\nviết dưới dạng văn xuôi trong ngôn ngữ thông dụng. Ngôn ngữ được sử dụng ở đây\r\nlà ý nghĩa truyền thông trong bất kỳ tiếng nói chung (ví dụ như tiếng Tây Ban\r\nNha, tiếng Đức, tiếng Pháp, tiếng Anh, tiếng Hà Lan). Một đặc tả kỹ thuật không\r\nchính thức không phải là chủ thể của bất kỳ ký hiệu hoặc sự hạn chế đặc biệt\r\nnào khác so với những yêu cầu như quy ước thông thường cho ngôn ngữ đó (ví dụ\r\nvăn phạm và cú pháp). Trong khi không áp dụng hạn chế các chú giải, các đặc tả\r\nkhông chính thức cũng được yêu cầu để cung cấp các định nghĩa có ý nghĩa cho\r\ncác thuật ngữ được sử dụng trong một ngữ cảnh khác hơn là chấp nhận sử dụng\r\nthông thường.
\r\n\r\nSự khác biệt giữa tài liệu bán chính thức và\r\nchính thức chỉ là vấn đề định dạng hay trình bày: một ký hiệu bán chính thức\r\nbao gồm những thứ như một ký hiệu rõ ràng, một định dạng trình bày tiêu chuẩn\r\nhóa, v.v…Một đặc tả bán chính thức được viết theo mẫu trình bày tiêu chuẩn. Các\r\nbài trình bày nên sử dụng các thuật ngữ nhất quán khi viết bằng một ngôn ngữ\r\nthông dụng. Bài trình bày cũng có thể sử dụng ngôn ngữ nhiều cấu trúc/biểu đồ\r\nhơn (ví dụ như sơ đồ lưu lượng dữ liệu, biểu đồ chuyển trạng thái, sơ đồ mối\r\nquan hệ các thực thể, sơ đồ cấu trúc dữ liệu, và sơ đồ tiến trình hay sơ đồ cấu\r\ntrúc chương trình). Cho dù có dựa trên sơ đồ hoặc ngôn ngữ thông dụng, một tập\r\nhợp các quy ước phải được sử dụng khi trình bày. Thuật ngữ này xác định một\r\ncách rõ ràng các từ đang được sử dụng một cách chính xác và không thay đổi;\r\ntương tự, định dạng chuẩn nói lên việc quan tâm đặc biệt được thực hiện công\r\ntác chuẩn bị tài liệu một cách rõ ràng nhất. Nó nên được lưu ý rằng phần cơ bản\r\nkhác nhau của TSF có thể có các quy ước và kiểu biểu diễn ký hiệu bán hình thức\r\nkhác nhau (miễn là số lượng “ký hiệu bán hình thức” khác nhau là nhỏ), điều này\r\nvẫn tuân thủ các khái niệm về trình bày bán hình thức.
\r\n\r\nMột đặc tả chính thức được viết dưới dạng ký\r\nhiệu dựa trên các khái niệm toán học được xây dựng tốt, và thường đi kèm với hỗ\r\ntrợ giải thích (chính thức) dưới dạng văn xuôi. Những khái niệm toán học được\r\nsử dụng để định nghĩa cú pháp và ngữ nghĩa của các ký hiệu và các quy tắc chứng\r\nminh có hỗ trợ nguyên nhân về mặt logic. Các quy tắc cú pháp và ngữ nghĩa hỗ\r\ntrợ một ký hiệu chính thức mà định nghĩa làm thế nào để nhận biết các cấu trúc\r\nrõ ràng và xác định ý nghĩa của chúng. Cần có bằng chứng rằng không thể là\r\nnguồn gốc mâu thuẫn, và tất cả các quy tắc hỗ trợ các ký hiệu cần phải được xác\r\nđịnh hoặc tham chiếu.
\r\n\r\nHình 11 cho thấy các Họ bên trong lớp này, và\r\nphân cấp của các thành phần bên trong họ.
\r\n\r\n![](\"00907948_files/image011.jpg\")
11.1.1. Mục tiêu
\r\n\r\nCác mục tiêu của họ này là phục vụ nhà phát\r\ntriển để cung cấp khả năng mô tả kiến trúc an toàn của TSF. Điều này sẽ cho\r\nphép phân tích thông tin, khi kết hợp với các chứng cứ khác để biểu diễn cho\r\ncác TSF, để xác nhận TSF các đạt được các thuộc tính mong muốn. Mô tả kiến trúc\r\nan toàn hỗ trợ giải thích các yêu cầu ngầm hiểu về phân tích an toàn của TOE có\r\nthể đạt được bằng cách kiểm tra các TSF, mà không có một kiến trúc rõ ràng,\r\ntoàn bộ các chức năng TOE cần phải được kiểm tra.
\r\n\r\n11.1.2. Phân mức thành phần
\r\n\r\nHọ này chỉ chứa một thành phần.
\r\n\r\n11.1.3. Chú thích ứng dụng
\r\n\r\nCác thuộc tính tự bảo vệ, tách miền, và không\r\nthể vượt qua được phân biệt với chức năng an toàn thể hiện bằng Phần 2 SFR vì\r\ntự bảo vệ và không thể vượt qua phần lớn không có giao diện trực tiếp quan sát\r\ntại các TSF. Thay vào đó, chúng là thuộc tính của TSF được đạt được thông qua\r\nthiế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ế\r\nđó.
\r\n\r\nCách tiếp cận sử dụng họ này là dành cho nhà\r\nphát triển để thiết kế và cung cấp TSF trình bày các thuộc tính nêu trên, và để\r\ncung cấp bằng chứng (dưới dạng tài liệu) để giải thích các thuộc tính của TSF.\r\nViệc giải thích này cung cấp mức độ cụ thể như mô tả các phần tử thực thi SFR\r\ncủa TOE trong tài liệu thiết kế TOE. Đánh giá viên có trách nhiệm xem xét chứng\r\ncứ và, cùng với các bằng chứng khác của TOE và TSF, quyết định các thuộc tính\r\nnày sẽ đạt được.
\r\n\r\nĐặc tả của thực hiện chức năng an toàn cho\r\ncác SFR (trong đặc tả chức năng (ADV_FSP) và thiết kế TOE (ADV_TDS) sẽ không\r\ncần thiết có các cơ chế mô tả được sử dụng trong việc thực hiện cơ chế tự bảo\r\nvệ và không thể vượt qua (ví dụ cơ chế quản lý bộ nhớ). Do đó, cần thiết cung\r\ncấp sự đảm bảo rằng các yêu cầu được đạt được là phù hợp hơn để biểu diễn phân\r\ntách giữa sự phân rã thành phần thiết kế của TSF như thể hiện trong ADV_FSP và\r\nADV_TDS. Điều này không có hàm ý rằng mô tả kiến trúc an toàn được gọi bởi\r\nthành phần này có thể không tham khảo hoặc sử dụng phân rã thiết kế, như dường\r\nnhư có rất nhiều chi tiết hiện tại trong tài liệu phân rã sẽ không có liên quan\r\nđến các đối số được cung cấp cho tài liệu mô tả kiến trúc an toàn.
\r\n\r\nMô tả kiến trúc hợp lý có thể được dùng như\r\nphân tích tính dễ tổn thương của nhà phát triển, trong đó nó cung cấp sự biện\r\nminh cho lý do tại sao TSF là hợp lý và thực thi tất cả các SFR của nó. Tính\r\nhợp lý đạt được tại thông qua cơ chế an toàn cụ thể, chúng sẽ được kiểm tra như\r\nmột phần của yêu cầu độ sâu (ATE_DPT), tại nơi tính hợp lý đạt được chỉ duy\r\nnhất thông qua kiến trúc, hành vi đó sẽ được kiểm thử như là một phần của AVA:\r\nyêu cầu đánh giá tính dễ tổn thương.
\r\n\r\nHọ này bao gồm các yêu cầu cho mô tả kiến\r\ntrúc an toàn mà mô tả tính chất tự bảo vệ, tách miền, không thể vượt qua, bao\r\ngồm một mô tả về việc làm thế nào mà các tính chất này được hỗ trợ bởi các phần\r\ncủa TOE mà được sử dụng cho khởi tạo TSF.
\r\n\r\nThông tin bổ sung về các thuộc tính kiến trúc\r\nan toàn về tự bảo vệ, tách miền, và không thể vượt qua có thể được tìm thấy\r\ntrong Phụ lục A.1, ADV_ARC: bổ sung tài liệu về kiến trúc an toàn.
\r\n\r\n11.1.4. ADV_ARC: Mô tả kiến trúc an toàn
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_FSP.1 Đặc tả chức năng cơ sở
\r\n\r\nADV_TDS.1 Thiết kế cơ sở
\r\n\r\n11.1.4.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.1.4.1.1. ADV_ARC.1.1D
\r\n\r\nNhà phát triển cần thiết kế và thực hiện TOE\r\nmà các đặc trưng an toàn của TSF không thể bị vượt qua.
\r\n\r\n11.1.4.1.2. ADV_ARC.1.2D
\r\n\r\nNhà phát triển cần thiết kế và thực hiện TSF\r\nmà có thể bảo vệ chính nó bởi sự pha trộn của các thực thể không tin cậy.
\r\n\r\n11.1.4.1.3. ADV_ARC.1.3D
\r\n\r\nNhà phát triển cần cung cấp mô tả kiến trúc\r\nan toàn của TSF.
\r\n\r\n11.1.4.2. Các phần tử nội dung và trình bày
\r\n\r\n11.1.4.2.1. ADV_ARC.1.1C
\r\n\r\nMô tả kiến trúc an toàn cần thực hiện tại mức\r\nđộ chi tiết bằng với mô tả tóm tắt thực thi SFR trong tài liệu thiết kế TOE.
\r\n\r\n11.1.4.2.2. ADV_ARC.1.2C
\r\n\r\nMô tả kiến trúc an toàn cần mô tả việc bảo\r\ntrì các miền an toàn với sự nhất quán của TSF so với SFR.
\r\n\r\n11.1.4.2.3. ADV_ARC.1.3C
\r\n\r\nMô tả kiến trúc an toàn cần mô tả làm thế nào\r\ntiến trình khởi tạo TSF là an toàn.
\r\n\r\n11.1.4.2.4. ADV_ARC.1.4C
\r\n\r\nMô tả kiến trúc an toàn cần chứng minh rằng\r\nTSF bảo vệ chính nó khỏi bị can thiệp.
\r\n\r\n11.1.4.2.5. ADV_ARC.1.5C
\r\n\r\nMô tả kiến trúc an toàn cần chứng minh rằng\r\nTSF chống lại việc vượt qua của chức năng thực thi SFR.
\r\n\r\n11.1.4.3. Phần tử hành động của đánh giá viên
\r\n\r\n11.1.4.3.1. ADV_ARC.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu cho nội dung và biểu diễn các chứng\r\ncứ.
\r\n\r\n11.2.1. Mục tiêu
\r\n\r\nCác yêu cầu họ dựa trên các đặc tả chức năng,\r\ntrong đó mô tả các giao diện TSF (TSFI). Các TSFI bao gồm tất cả các phương\r\ntiện cho người dùng để gọi một dịch vụ từ TSF (bằng cách cung cấp dữ liệu được\r\nxử lý bởi TSF) và các câu trả lời tương ứng với những lệnh gọi dịch vụ. Nó\r\nkhông mô tả cách các tiến trình TSF yêu cầu các dịch vụ, cũng không mô tả cách\r\nthức truyền thông khi TSF các gọi dịch vụ từ môi trường áp dụng của nó; thông\r\ntin này được đề cập thông qua việc thiết kế TOE (ADV_TDS) và sự tin cậy của các\r\nthành phần phụ thuộc của họ (ACO_REL) tương ứng.
\r\n\r\nHọ này cung cấp đảm bảo trực tiếp bằng cách\r\ncho phép đánh giá viên hiểu cách TSF đáp ứng các SFR đã tuyên bố. Nó cũng cung\r\ncấp bảo đảm gián tiếp, như là đầu vào cho các họ và lớp đảm bảo:
\r\n\r\n● ADV_ARC, nơi mà sự mô tả của các TSFI có\r\nthể được sử dụng để đạt được sự hiểu biết tốt hơn về cách TSF được bảo vệ chống\r\nlại sự phá hủy (như tự bảo vệ chống lại sự phá hoại hay tách miền) và/hoặc bỏ\r\nqua;
\r\n\r\n● ATE, nơi mà sự mô tả của các TSFI là một\r\nđầu vào quan trọng cho cả nhà phát triển và đánh giá viên kiểm thử;
\r\n\r\n● AVA, là nơi việc mô tả của các TSFI được sử\r\ndụng để tìm kiếm các điểm yếu.
\r\n\r\n11.2.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức dựa\r\ntrên mức độ yêu cầu chi tiết của việc mô tả TSFI, và mức độ yêu cầu về hình\r\nthức việc mô tả các TSFI.
\r\n\r\n11.2.3. Chú thích ứng dụng
\r\n\r\nMột khi các TSFI được xác định (xem A.2.1,\r\nXác định TSFI để được hướng dẫn và ví dụ về xác định TSFI), chúng đã được mô\r\ntả. Tại các thành phần mức thấp hơn, nhà phát triển tập trung vào các tài liệu\r\ncủa họ (và đánh giá viên tập trung vào các phân tích của họ) trên nhiều khía\r\ncạnh an toàn liên của TOE. Ba loại TSFI được xác định, dựa trên quan hệ của các\r\ndịch vụ có sẵn thông qua đó chúng để có các SFR được tuyên bố:
\r\n\r\n● Nếu một dịch vụ có sẵn thông qua một giao\r\ndiện có thể được truy nguồn từ một trong những SFR áp cho TSF, khi đó giao diện\r\nđược gọi là thực thi-SFR. Lưu ý rằng có thể xảy ra trường hợp một giao diện có\r\nthể có nhiều loại dịch vụ và kết quả, một số trong đó có thể thực thi SFR và\r\nmột số khác có thể không.
\r\n\r\n● Giao diện (hoặc dịch vụ có sẵn thông qua\r\nmột giao diện liên quan) cho các dịch vụ mà chức năng thực thi SFR được dựa\r\ntrên đó, nhưng chỉ cần thực hiện chức năng chính xác để cho các chính sách an\r\ntoàn của TOE được bảo vệ, được gọi là hỗ trợ SFR.
\r\n\r\n● Giao diện với các dịch vụ trên đó chức năng\r\nthực thi SFR không có các mối phụ thuộc được gọi là không can thiệp vào SFR.
\r\n\r\nCần lưu ý rằng để cho một giao diện được hỗ\r\ntrợ SFR hay không can thiệp SFR thì nó phải không có các kết quả hay dịch vụ\r\nthực thi SFR. Ngược lại, giao diện thực thi SFR có thể có các dịch vụ hỗ trợ\r\nSFR (Ví dụ như khả năng thiết lập đồng hồ hệ thống có thể là một dịch vụ thực\r\nthi SFR của giao diện, nhưng nếu cùng một giao diện được sử dụng để hiển thị\r\nngày hệ thống dịch vụ có thể hỗ trợ SFR). Một ví dụ về một giao diện hoàn toàn\r\nhỗ trợ SFR là một giao diện cuộc gọi hệ thống được sử dụng cả bởi người dùng và\r\ndo một phần của TSF nghĩa là đang hoạt động dựa trên hành vi của người dùng.
\r\n\r\nKhi có thêm thông tin về các TSFI, mức độ lớn\r\nhơn của đảm bảo có thể đạt được với giao diện được phân loại/phân tích chính\r\nxác. Các yêu cầu được cấu trúc như vậy, ở mức thấp nhất, các thông tin cần\r\nthiết cho giao diện không can thiệp SFR là tối thiểu cần thiết để đánh giá viên\r\nquyết định theo một cách hiệu quả. Ở cấp độ cao hơn, nếu có thêm thông tin đánh\r\ngiá viên sẽ có thêm sự tin cậy trong các thiết kế.
\r\n\r\nMục đích trong việc xác định các nhãn này\r\n(Thực thi, hỗ trợ, không can thiệp với SFR) và đưa ra các yêu cầu khác nhau\r\ntheo từng cái (ở các thành phần đảm bảo mức thấp hơn) để cung cấp một phép xấp\r\nxỉ bước đầu của nơi tập trung phân tích và bằng chứng mà phân tích được thực\r\nhiện dựa trên nó. Nếu các tài liệu của nhà phát triển của các giao diện TSF mô\r\ntả tất cả các giao diện theo mức quy định trong các yêu cầu đối với các giao\r\ndiện thực thi SFR (có nghĩa là, nếu lập tài liệu vượt quá yêu cầu), không cần\r\nthiết phải cho phát triển tạo ra các bằng chứng mới phù hợp với yêu cầu. Tương\r\ntự như vậy, bởi vì các nhãn chỉ đơn thuần là một phương tiện phân biệt các loại\r\ngiao diện trong các yêu cầu, nó không cần cho các nhà phát triển khi cập nhật\r\ncác bằng chứng duy nhất để gán cho các giao diện như thực thi-SFR, hỗ trợ SFR,\r\nkhông can thiệp SFR. Mục đích chính của nhãn này là cho phép nhà phát triển có\r\nít kiến thức để phát triển phương pháp luận (và hiện vật, chẳng hạn như giao\r\ndiện chi tiết và tài liệu thiết kế) để cung cấp bằng chứng cần thiết mà không\r\nphải chi phí quá mức.
\r\n\r\nCác phần tử C cuối cùng của mỗi thành phần\r\ntrong họ này cung cấp một sự tương ứng trực tiếp giữa các SFR và đặc tả chức\r\nnăng, đó là một dấu hiệu trong đó có giao diện được sử dụng để gọi đến từng\r\ntuyên bố SFR. Trong trường hợp ST có chứa các yêu cầu chức năng như: Bảo vệ\r\nthông tin còn sót lại (FDP_RIP) - TCVN 8709-2, mà có chức năng có thể không\r\nbiểu hiện chính mình trong TSFIs, các đặc tả chức năng và/hoặc các truy gốc\r\nđược chờ đợi sẽ xác định các SFR này, bao gồm chúng trong các đặc tả chức năng\r\ngiúp đảm bảo rằng chúng không bị mất ở mức thấp hơn của phân rã, nơi chúng có\r\nliên quan.
\r\n\r\n11.2.3.1. Chi tiết về các giao diện
\r\n\r\nCác yêu cầu định nghĩa các bộ sưu tập của các\r\nchi tiết về TSFI là được cung cấp. Với mục đích của các yêu cầu, giao diện được\r\nchỉ ra (trong mức độ chi tiết khác nhau) về mục tiêu của chúng, phương pháp sử\r\ndụng, thông số, mô tả thông số, và thông báo lỗi.
\r\n\r\nMục đích của giao diện là một mô tả mức cao\r\ncác mục tiêu chung của giao diện (ví dụ các lệnh tiến trình GUI, tiếp nhận các\r\ngói tin mạng, cung cấp đầu ra máy in v.v…).
\r\n\r\nPhương pháp sử dụng của giao diện mô tả việc\r\nlàm thế nào giao diện được hỗ trợ để sử dụng. Mô tả này nên được xây dựng xung\r\nquanh các tương tác khác nhau hiện có tại giao diện đó. Ví dụ, nếu giao diện là\r\nmột dấu nhắc lệnh Unix, ls, mv và cp có thể tương tác với giao diện đó. Đối với\r\nmỗi tương tác phương pháp sử dụng mô tả những gì tương tác này thực hiện, cả\r\nhành vi nhìn thấy ở giao diện (ví dụ như chương trình gọi các API, người dùng\r\nWindowns thay đổi một thiết lập trong thanh ghi v.v…) cũng như hành vi tại các\r\ngiao diện khác (ví dụ như tạo ra một bản ghi phục vụ kiểm tra).
\r\n\r\nTham số được đầu vào và đầu ra rõ ràng từ một\r\ngiao diện điều khiển hành vi của giao diện đó. Ví dụ, các thông số là các đối\r\nsố cung cấp cho một API; các lĩnh vực khác nhau trong một gói tin cho một giao\r\nthức mạng nhất định; các giá trị khóa riêng trong thanh ghi của Windows, các\r\ntín hiệu trên một tập hợp các chân trên một con chip, những cờ có thể được\r\nthiết lập cho lệnh ls v.v… Các tham số được “nhận diện” với một danh sách đơn\r\ngiản của những gì chúng đang có.
\r\n\r\nMô tả tham số nói lên rằng tham số này có ý\r\nnghĩa gì. Ví dụ, một mô tả tham số chấp nhận được đối với giao diện foo (i) sẽ\r\nlà “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\r\nvào hệ thống”. Một mô tả như là “tham số i là một số nguyên” là không thể chấp\r\nnhận được.
\r\n\r\nMô tả các hành động của một giao diện mô tả\r\nnhững gì mà giao diện thực hiện. Điều này là chi tiết hơn mục đích trong đó,\r\ntrong khi các “mục đích” giải thích lý do tại sao người ta muốn sử dụng nó, còn\r\n“hành động” cho thấy tất cả mọi thứ mà nó làm. Những hành động này có thể liên\r\nquan hoặc không liên quan đến các SFR. Trong trường hợp hành động của giao diện\r\nkhông có liên quan đến SFR, mô tả của nó được nói tóm tắt, có nghĩa là mô tả\r\nchỉ nêu rõ rằng nó thực sự là không liên quan đến SFR.
\r\n\r\nCác mô tả thông báo lỗi xác định các điều\r\nkiện tạo ra nó, thông điệp là gì, và ý nghĩa của bất kỳ mã lỗi nào. Một thông\r\nbáo lỗi được tạo ra bởi các TSF để chỉ ra rằng một vấn đề hoặc sự bất thường ở\r\nmột mức độ nào đó đã thu được. Các yêu cầu trong họ này đề cập đến các loại\r\nthông báo lỗi khác nhau:
\r\n\r\n● Một thông báo lỗi “trực tiếp” là một phản\r\nứng an toàn có liên quan thông qua lệnh gọi TSFI cụ thể.
\r\n\r\n● Lỗi “gián tiếp” có thể không được gắn với\r\nmột lời gọi TSFI cụ thể bởi vì nó là kết quả của điều kiện toàn hệ thống (ví dụ\r\nnhư cạn kiệt tài nguyên, gián đoạn kết nối, v.v…) Thông báo lỗi mà không liên\r\nquan bảo mật cũng được xem là “gián tiếp”.
\r\n\r\n● Lỗi “còn lại” là bất kỳ lỗi nào khác, chẳng\r\nhạn như những cái mà có thể được tham chiếu trong mã. Ví dụ, việc sử dụng đoạn\r\nmã kiểm tra điều kiện để kiểm tra các điều kiện mà xuất hiện không hợp lý (ví\r\ndụ như một kết thúc “else” sau khi một danh sách các “case”), sẽ cung cấp để\r\ntạo ra thông điệp bắt lỗi, trong TOE sử dụng, các thông báo lỗi này sẽ không\r\nbao giờ được nhìn thấy.
\r\n\r\nMột ví dụ về đặc tả chức năng được cung cấp\r\ntrong A.2.3.
\r\n\r\n11.2.3.2. Các thành phần của họ này
\r\n\r\nTăng cường bảo đảm thông qua sự tăng hoàn\r\nthiện và độ chính xác trong đặc tả giao diện được phản ánh trong các tài liệu\r\ncần thiết từ nhà phát triển như chi tiết trong các thành phần phân cấp trong họ\r\nnày.
\r\n\r\nTrong đặc tả chức năng cơ bản ADV_FSP.1, chỉ\r\ncác tài liệu hướng dẫn được yêu cầu có tính chất của tất cả các TSFIs và mô tả ở\r\nmức cao của TSFI thực thi SFR và hỗ trợ SFR. Để cung cấp thêm một vài đảm bảo,\r\nmà các khía cạnh “quan trọng” của TSF có tính chất chính xác tại các TSFI, nhà\r\nphát triển được yêu cầu cung cấp mục đích và phương pháp sử dụng, các tham số\r\ncho thực thi SFR và hỗ trợ SFR của TSFIs.
\r\n\r\nTại đặc tả chức năng thực thi an toàn\r\nADV_FSP.2, nhà phát triển được yêu cầu cung cấp các mục đích, phương pháp sử\r\ndụng, thông số, và mô tả thông số cho tất cả TSFIs. Thêm vào đó, đối với TSFI\r\nthực thi SFR, nhà phát triển cần phải mô tả các hành động thực thi SFR và các\r\nthông báo lỗi trực tiếp.
\r\n\r\nTheo đặc tả chức năng với bản tóm tắt hoàn\r\nchỉnh ADV_FSP.3, nhà phát triển phải cung cấp ngay, ngoài các thông tin cần\r\nthiết tại ADV_FSP.2, cung cấp đủ thông tin về hỗ trợ SFR và không can thiệp SFR\r\nđể chứng minh rằng chúng không phải là thực thi SFR. Thêm vào đó, nhà phát\r\ntriển phải lập tài liệu tất cả các thông báo lỗi trực tiếp do việc gọi các TSFI\r\ncủa thực thi SFR.
\r\n\r\nTheo đặc tả chức năng đầy đủ ADV_FSP.4, tất\r\ncả các TSFI - cho dù thực thi SFR, hỗ trợ SFR, không can thiệp SFR - phải được\r\nmô tả ở cùng mức độ như nhau, bao gồm tất cả các thông báo lỗi trực tiếp.
\r\n\r\nTheo đặc tả chức năng bán chính thức đầy đủ\r\nvới các thông tin lỗi bổ sung ADV_FSP.5, mô tả TSFI cũng bao gồm các thông báo\r\nlỗi mà không phải là kết quả của việc gọi của TSFI.
\r\n\r\nTheo ADV_FSP.6 đặc tả chức năng bán chính\r\nthức đầy đủ với bổ sung đặc tả chính thức, ngoài các thông tin theo yêu cầu của\r\nADV_FSP.5, tất cả các thông báo lỗi còn lại đã được bao gồm. Nhà phát triển\r\ncũng phải cung cấp mô tả chính thức của TSFI. Điều này cung cấp một cái nhìn\r\nkhác của TSFI có thể phơi bày các đặc tả không nhất quán hay không hoàn tất.
\r\n\r\n11.2.4. ADV_FSP.1 Đặc tả chức năng cơ sở
\r\n\r\nCác mối phụ thuộc: không có sự phụ thuộc nào
\r\n\r\n11.2.4.1. Các phần tử của nhà phát triển
\r\n\r\n11.2.4.1.1. ADV_FSP.1.1D
\r\n\r\nNhà phát triển cần cung cấp đặc tả chức năng.
\r\n\r\n11.2.4.1.2. ADV_FSP.1.2D
\r\n\r\nNhà phát triển cần cung cấp truy vết từ đặc\r\ntả chức năng đến các SFR.
\r\n\r\n11.2.4.2. Các phần tử nội dung và trình bày
\r\n\r\n11.2.4.2.1. ADV_FSP.1.1C
\r\n\r\nĐặc tả chức năng cần mô tả mục tiêu và phương\r\npháp sử dụng cho mỗi TSFI của thực thi SFR và hỗ trợ SFR.
\r\n\r\n11.2.4.2.2. ADV_FSP.1.2C
\r\n\r\nĐặc tả chức năng cần xác định tất cả các tham\r\nsố liên quan với mỗi TSFI của thực thi SFR và hỗ trợ SFR.
\r\n\r\n11.2.4.2.3. ADV_FSP.1.3C
\r\n\r\nĐặc tả chức năng cần cung cấp sở cứ cho việc\r\nphân nhóm rõ ràng của các giao diện như không can thiệp SFR.
\r\n\r\n11.2.4.2.4. ADV_FSP.1.4C
\r\n\r\nTruy vết cần chứng minh rằng truy vết SFR\r\ntheo TSFI trong đặc tả chức năng.
\r\n\r\n11.2.4.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.2.4.3.1. ADV_FSP.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\ncung cấp sự phù hợp với tất cả các yêu cầu cho nội dung và trình bày các chứng\r\ncứ.
\r\n\r\n11.2.4.3.2. ADV_FSP.1.2E
\r\n\r\nĐánh giá viên cần quyết định rằng đặc tả chức\r\nnăng được khởi tạo chính xác và hoàn toàn của các SFR.
\r\n\r\n11.2.5. ADV_FSP.2 Đặc tả chức năng thực thi\r\nan toàn
\r\n\r\nCác phụ thuộc: ADV_TDS.1 Thiết kế cơ sở
\r\n\r\n11.2.5.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.2.5.1.1. ADV_FSP.2.1D
\r\n\r\nNhà phát triển cần cung cấp đặc tả chức năng
\r\n\r\n11.2.5.1.2. ADV_FSP.2.2D
\r\n\r\nNhà phát triển cần cung cấp truy vết từ đặc\r\ntả chức năng đến các SFR.
\r\n\r\n11.2.5.2. Các phần tử nội dung và trình bày
\r\n\r\n11.2.5.2.1. ADV_FSP.2.1C
\r\n\r\nĐặc tả chức năng cần biểu diễn toàn bộ TSF.
\r\n\r\n11.2.5.2.2. ADV_FSP.2.2C
\r\n\r\nĐặc tả chức năng cần mô tả mục tiêu và phương\r\npháp sử dụng cho tất cả TSFI.
\r\n\r\n11.2.5.2.3. ADV_FSP.2.3C
\r\n\r\nĐặc tả chức năng cần xác định và mô tả tất cả\r\ncác tham số liên quan đến mỗi TSFI.
\r\n\r\n11.2.5.2.4. ADV_FSP.2.4C
\r\n\r\nVới mỗi TSFI thực thi SFR, đặc tả chức năng\r\ncần mô tả các hành động thực thi SFR liên quan đến mỗi TSFI.
\r\n\r\n11.2.5.2.5. ADV_FSP.2.5C
\r\n\r\nVới các TSFI thực thi SFR, đặc tả chức năng\r\ncần mô tả các thông báo lỗi trực tiếp có kết quả từ xử lý liên quan với các\r\nhành động thực thi SFR.
\r\n\r\n11.2.5.2.6. ADV_FSP.2.6C
\r\n\r\nTruy vết cần chứng minh rằng truy vết SFR từ\r\ncác TSFI theo các đặc tả chức năng.
\r\n\r\n11.2.5.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.2.5.3.1. ADV_FSP.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các bằng\r\nchứng.
\r\n\r\n11.2.5.3.2. ADV_FSP.2.2E
\r\n\r\nĐánh giá viên cần quyết định rằng đặc tả chức\r\nnăng là một sự khởi tạo chính xác và hoàn toàn của các SFR.
\r\n\r\n11.2.6. ADV_FSP.3 Đặc tả chức năng với tóm\r\ntắt đầy đủ
\r\n\r\nCác phụ thuộc: ADV_TDS.1 Thiết kế cơ sở
\r\n\r\n11.2.6.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.2.6.1.1. ADV_FSP.3.1D
\r\n\r\nNhà phát triển cần cung cấp đặc tả chức năng.
\r\n\r\n11.2.6.1.2. ADV_FSP.3.2D
\r\n\r\nNhà phát triển cần cung cấp truy vết từ đặc\r\ntả chức năng đến các SFR.
\r\n\r\n11.2.6.2. Các phần tử nội dung và trình bày
\r\n\r\n11.2.6.2.1. ADV_FSP.3.1C
\r\n\r\nĐặc tả chức năng cần biểu diễn đầy đủ TSF
\r\n\r\n11.2.6.2.2. ADV_FSP.3.2C
\r\n\r\nĐặc tả chức năng cần mô tả mục tiêu và phương\r\npháp sử dụng cho tất cả TSFI.
\r\n\r\n11.2.6.2.3. ADV_FSP.3.3C
\r\n\r\nĐặc tả chức năng cần xác định và mô tả tất cả\r\ncác tham số liên quan với mỗi TSFI.
\r\n\r\n11.2.6.2.4. ADV_FSP.3.4C
\r\n\r\nVới mỗi TSFI của thực thi SFR, đặc tả chức\r\nnăng cần mô tả các hành động thực thi SFR liên quan với TSFI.
\r\n\r\n11.2.6.2.5. ADV_FSP.3.5C
\r\n\r\nVới mỗi TSFI thực thi SFR, đặc tả chức năng\r\ncầ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\r\nquan đến các lệnh gọi của TSFI.
\r\n\r\n11.2.6.2.6. ADV_FSP.3.6
\r\n\r\nĐặc tả chức năng cần tóm tắt các hành động hỗ\r\ntrợ SFR và không can thiệp SFR liên quan đến mỗi TSFI.
\r\n\r\n11.2.6.2.7. ADV_FSP.3.7C
\r\n\r\nTruy vết cần chứng minh rằng SFR truy vết từ\r\nTSFI trong đặc tả chức năng.
\r\n\r\n11.2.6.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.2.6.3.1. ADV_FSP.3.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày chứng cứ.
\r\n\r\n11.2.6.3.2. ADV_FSP.3.2E
\r\n\r\nĐánh giá viên cần quyết định rằng đặc tả chức\r\nnăng là chính xác và đầy đủ của các SFR.
\r\n\r\n11.2.7. ADV_FSP.4 Đặc tả chức năng đầy đủ
\r\n\r\nCác phụ thuộc: ADV_TDS.1 Thiết kế cơ sở
\r\n\r\n11.2.7.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.2.7.1.1. ADV_FSP.4.1D
\r\n\r\nNhà phát triển cần cung cấp đặc tả chức năng.
\r\n\r\n11.2.7.1.2. ADV_FSP.4.2D
\r\n\r\nNhà phát triển cần cung cấp truy vết từ đặc\r\ntả chức năng đến các SFR.
\r\n\r\n11.2.7.2. Các phần tử nội dung và trình bày
\r\n\r\n11.2.7.2.1. ADV_FSP.4.1C
\r\n\r\nĐặc tả chức năng cần biểu diễn đầy đủ TSF.
\r\n\r\n11.2.7.2.2. ADV_FSP.4.2C
\r\n\r\nĐặc tả chức năng cần mô tả mục tiêu và phương\r\npháp sử dụng của tất cả TSFI.
\r\n\r\n11.2.7.2.3. ADV_FSP.4.3C
\r\n\r\nĐặc tả chức năng cần xác định và mô tả tất cả\r\ncác tham số liên quan với mỗi TSFI.
\r\n\r\n11.2.7.2.4. ADV_FSP.4.4C
\r\n\r\nĐặc tả chức năng cần mô tả tất cả các hành\r\nđộng liên quan với mỗi TSFI.
\r\n\r\n11.2.7.2.5. ADV_FSP.4.5C
\r\n\r\nĐặc tả chức năng cần mô tả tất cả các thông\r\nbáo lỗi trực tiếp mà có kết quả từ việc gọi đến mối TSFI.
\r\n\r\n11.2.7.2.6. ADV_FSP.4.6C
\r\n\r\nTruy vết cần chứng minh rằng các SFR truy vết\r\nTSFI trong đặc tả chức năng.
\r\n\r\n11.2.7.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.2.7.3.1. ADV_FSP.4.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các chứng cứ.
\r\n\r\n11.2.7.3.2. ADV_FSP.4.2E
\r\n\r\nĐánh giá viên cần quyết định rằng đặc tả chức\r\nnăng là chính xác và đầy đủ của các SFR.
\r\n\r\n11.2.8. ADV_FSP.5. Đặc tả chức năng bán chính\r\nthức đầy đủ với thông tin lỗi bổ sung
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_TDS.1 Thiết kế cơ sở
\r\n\r\nADV_IMP.1 Biểu diễn thực hiện của TSF.
\r\n\r\n11.2.8.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.2.8.1.1. ADV_FSP.5.1D
\r\n\r\nNhà phát triển cần cung cấp đặc tả chức năng.
\r\n\r\n11.2.8.1.2. ADV_FSP.5.2D
\r\n\r\nNhà phát triển cần cung cấp truy vết từ đặc\r\ntả chức năng đến các SFR.
\r\n\r\n11.2.8.2. Các phần tử nội dung và trình bày
\r\n\r\n11.2.8.2.1. ADV_FSP.5.1C
\r\n\r\nĐặc tả chức năng cần biểu diễn hoàn toàn TSF.
\r\n\r\n11.2.8.2.2. ADV_FSP.5.2C
\r\n\r\nĐặc tả chức năng cần mô tả TSFI sử dụng kiểu\r\nbán hình thức.
\r\n\r\n11.2.8.2.3. ADV_FSP.5.3C
\r\n\r\nĐặc tả chức năng cần mô tả mục tiêu và phương\r\npháp sử dụng cho tất cả TSFI.
\r\n\r\n11.2.8.2.4. ADV_FSP.5.4C
\r\n\r\nĐặc tả chức năng cần xác nhận và mô tả tất cả\r\ncác tham số liên quan với mối TSFI.
\r\n\r\n11.2.8.2.5. ADV_FSP.5.5C
\r\n\r\nĐặc tả chức năng cần mô tả tất cả các hành\r\nđộng liên quan đến mỗi TSFI.
\r\n\r\n11.2.8.2.6. ADV_FSP.5.6C
\r\n\r\nĐặc tả chức năng cần mô tả tất cả các thông\r\nbáo lỗi trực tiếp mà có kết quả từ việc gọi đến từ mối TSFI.
\r\n\r\n11.2.8.2.7. ADV_FSP.5.7C
\r\n\r\nĐặc tả chức năng cần mô tả tất cả các thông\r\nbáo lỗi mà không phải được gọi đến từ TSFI.
\r\n\r\n11.2.8.2.8. ADV_FSP.5.8C
\r\n\r\nĐặc tả chức năng cần cung cấp sở cứ cho mỗi\r\nthông báo lỗi chứa trong thực hiện TSF nhưng kết quả không phải từ lệnh gọi đến\r\nTSFI.
\r\n\r\n11.2.8.2.9. ADV_FSP.5.9C
\r\n\r\nTruy vết cần chứng minh rằng SFR truy vết đến\r\ncác TSFI trong các đặc tả chức năng.
\r\n\r\n11.2.8.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.2.8.3.1. ADV_FSP.5.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các chứng cứ.
\r\n\r\n11.2.8.3.2. ADV_FSP.5.2E
\r\n\r\nĐánh giá viên cần quyết định rằng đặc tả chức\r\nnăng là đầy đủ và chính xác của các SFR.
\r\n\r\n11.2.9. ADV_FSP.6 Đặc tả chức năng bán chính\r\nthức đầy đủ với đặc tả chính thức bổ sung
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_TDS.1 Thiết kế cơ sở
\r\n\r\nADV_IMP.1 Biểu diễn thực hiện của TSF
\r\n\r\n11.2.9.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.2.9.1.1. ADV_FSP.6.1D
\r\n\r\nNhà phát triển cần cung cấp đặc tả chức năng.
\r\n\r\n11.2.9.1.2. ADV_FSP.6.2D
\r\n\r\nNhà phát triển cần cung cấp biểu diễn chính\r\nthức của đặc tả chức năng của TSF.
\r\n\r\n11.2.9.1.3. ADV_FSP.6.3D
\r\n\r\nNhà phát triển cần cung cấp truy vết từ đặc\r\ntả chức năng đến các SFR.
\r\n\r\n11.2.9.2. Các phần tử nội dung và trình bày
\r\n\r\n11.2.9.2.1. ADV_FSP.6.1C
\r\n\r\nĐặc tả chức năng cần biểu diễn đầy đủ TSF.
\r\n\r\n11.2.9.2.2. ADV_FSP.6.2C
\r\n\r\nĐặc tả chức năng cần mô tả TSFI sử dụng kiểu\r\nchính thức.
\r\n\r\n11.2.9.2.3. ADV_FSP.6.3C
\r\n\r\nĐặc tả chức năng cần mô tả mục tiêu và phương\r\npháp sử dụng tất cả TSFI.
\r\n\r\n11.2.9.2.4. ADV_FSP.6.4C
\r\n\r\nĐặc tả chức năng cần chỉ ra và mô tả tất cả\r\ncác tham số liên quan với mối TSFI.
\r\n\r\n11.2.9.2.5. ADV_FSP.6.5C
\r\n\r\nĐặc tả chức năng cần mô tả tất cả các hành\r\nđộng liên quan đến mỗi TSFI.
\r\n\r\n11.2.9.2.6. ADV_FSP.6.6C
\r\n\r\nĐặc tả chức năng cần mô tả tất cả các thông\r\nbáo lỗi trực tiếp mà kết quả từ lệnh gọi của mỗi TSFI.
\r\n\r\n11.2.9.2.7. ADV_FSP.6.7C
\r\n\r\nĐặc tả chức năng cần mô tả tất cả thông báo\r\nlỗi chứa trong biểu diễn thực hiện TSF.
\r\n\r\n11.2.9.2.8. ADV_FSP.6.8C
\r\n\r\nĐặc tả chức năng cần cung cấp các sở cứ cho\r\nmỗi thông báo lỗi chứa trong việc thực hiện TSF mà không được mô tả trong\r\nviệc giải trình vì sao đặc tả chức năng không liên quan với TSFI.
\r\n\r\n11.2.9.2.9. ADV_FSP.6.9C
\r\n\r\nTrình bày chính thức của các đặc tả chức năng\r\ncủa TSF cần mô tả TSF sử dụng kiểu chính thức, hỗ trợ bởi các văn bản giải\r\nthích không chính thức tại các nơi phù hợp.
\r\n\r\n11.2.9.2.10. ADV_FSP.6.10C
\r\n\r\nTruy vết cần chứng minh rằng SFR truy vết\r\nTSFI trong đặc tả chức năng.
\r\n\r\n11.2.9.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.2.9.3.1. ADV_FSP.6.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày các chứng\r\ncứ.
\r\n\r\n11.2.9.3.2. ADV_FSP.6.2E
\r\n\r\nĐánh giá viên cần quyết định rằng đặc tả chức\r\nnăng là đầy đủ và chính xác với SFR.
\r\n\r\n11.3.1. Mục tiêu
\r\n\r\nChức năng của họ biểu diễn triển khai\r\n(ADV_IMP) là cho nhà phát triển làm sẵn sàng biểu diễn triển khai (và, ở mức độ\r\ncao hơn, việc tự thực hiện) của TOE trong một hình thức có thể được phân tích\r\nbằng đánh giá viên. Biểu diễn triển khai được sử dụng trong các hoạt động phân\r\ntích cho các họ khác (ví dụ, phân tích thiết kế TOE) để chứng minh rằng TOE sự\r\nphù hợp thiết kế của nó và để cung cấp một cơ sở cho việc phân tích ở các vùng\r\nkhác của đánh giá (ví dụ, việc tìm kiếm các điểm yếu). Các biểu diễn triển khai\r\nđược chờ đợi ở dưới dạng để chụp các hoạt động nội bộ chi tiết của TSF. Đây có\r\nthể là mã nguồn phần mềm, mã nguồn phần sụn, sơ đồ phần cứng và/hoặc thiết kế\r\nphần cứng IC mã ngôn ngữ hoặc dữ liệu lớp.
\r\n\r\n11.3.2. Phân mức thành phần
\r\n\r\nThành phần trong họ này được phân mức dựa\r\ntrên số lượng thực hiện được ánh xạ vào mô tả thiết kế TOE.
\r\n\r\n11.3.3. Chú thích ứng dụng
\r\n\r\nSơ đồ mã nguồn hoặc phần cứng và/hoặc thiết\r\nkế phần cứng IC mã ngôn ngữ hoặc bố trí dữ liệu được sử dụng để xây dựng phần\r\ncứng thực tế là những ví dụ của các bộ phận của biểu diễn triển khai. Điều quan\r\ntrọng cần lưu ý rằng trong khi các biểu diễn triển khai phải được sẵn sàng cho\r\nđánh giá viên, điều này không có nghĩa là đánh giá viên cần phải sở hữu đại\r\ndiện đó. Ví dụ, nhà phát triển có thể yêu cầu đánh giá viên xem xét lại các\r\nbiểu diễn triển khai tại một trang web lựa chọn của nhà phát triển.
\r\n\r\nCác biểu diễn triển khai toàn bộ được sẵn\r\nsàng để đảm bảo rằng các hoạt động phân tích không được rút ngắn do thiếu thông\r\ntin. Tuy vậy, điều này không có hàm ý rằng tất cả các đại diện được xem xét khi\r\nthực hiện phân tích các hoạt động đang được thực hiện. Điều này không thực tế ở\r\nhầu hết các trường hợp, thêm vào đó là nó rất có thể sẽ không dẫn đến một TOE\r\ncó mức đảm bảo cao hơn so với mẫu mục tiêu của biểu diễn triển khai. Biểu diễn\r\ntriển khai được làm sẵn để cho phép phân tích các phân tích phân rã thiết kế\r\nTOE khác (ví dụ như chức tả chức năng, thiết kế TOE), và để đạt được sự tin cậy\r\nmà các chức năng an toàn được mô tả ở mức độ cao hơn trong việc thiết kế thực\r\nsự xuất hiện để được thực hiện trong TOE.
\r\n\r\nQuy ước trong một số dạng của các biểu diễn\r\ntriển khai có thể làm cho nó khó hoặc không thể xác định từ chính các biểu diễn\r\ntriển khai những gì kết quả thực tế của việc biên dịch hoặc thông dịch thời\r\ngian thực. Ví dụ, chỉ thị, trình biên dịch cho các trình biên dịch ngôn ngữ C\r\nsẽ là nguyên nhân để các trình biên dịch loại trừ hoặc bao gồm toàn bộ các phần\r\ncủa mã này. Vì lý do này, điều quan trọng là các công cụ cung cấp “thêm” thông\r\ntin hoặc công cụ liên quan (kịch bản, trình biên dịch, vv) được cung cấp để các\r\nbiểu diễn triển khai có thể được xác định chính xác.
\r\n\r\nMục đích của các ánh xạ giữa các biểu diễn\r\ntriển khai và mô tả thiết kế TOE là để trợ giúp phân tích của đánh giá viên.\r\nCác hoạt động nội bộ của TOE có thể được hiểu rõ hơn khi thiết kế TOE được phân\r\ntích với các phần tương ứng của biểu diễn triển khai. Lập bản đồ phục vụ như\r\nmột chỉ mục trong các biểu diễn triển khai. Tại các thành phần thấp hơn, chỉ có\r\nmột tập hợp con của các biểu diễn triển khai được ánh xạ tới các mô tả thiết kế\r\nTOE. Bởi vì sự không chắc chắn trong đó phần của biểu diễn triển khai sẽ cần\r\nánh xạ như thế, nhà phát triển có thể chọn một trong hai ánh xạ đến biểu diễn\r\ntriển khai toàn bộ trước, hoặc phải chờ đợi để xem những phần của biểu diễn\r\ntriển khai, đánh giá viên yêu cầu để được ánh xạ.
\r\n\r\nCác biểu diễn triển khai được thao tác bởi\r\nnhà phát triển dưới các hình thức thích hợp cho chuyển đổi để thực hiện trong\r\nthự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ã\r\nnguồn, mà là cuối cùng đã được biên dịch để trở thành một phần của TSF. Nhà\r\nphát triển làm cho biểu diễn triển khai sẵn sàng dưới dạng để sử dụng bởi nhà\r\nphát triển, do đó đánh giá viên có thể sử dụng kỹ thuật tự động trong phân\r\ntích. Điều này cũng làm tăng sự tin cậy rằng việc kiểm tra các biểu diễn triển\r\nkhai thực sự là một trong những sử dụng trong sản xuất của các TSF (như trái\r\nngược với các trường hợp được cung cấp theo định dạng trình bày thay thế, như\r\nmột phần mềm xử lý văn bản). Cần lưu ý rằng các hình thức khác của các biểu\r\ndiễ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\r\ncung cấp. Mục tiêu tổng thể là để cung cấp cho đánh giá viên với các thông tin\r\nsẽ phát huy tối đa hiệu quả của các nỗ lực phân tích của đánh giá viên.
\r\n\r\nMột số hình thức của biểu diễn triển khai có\r\nthể yêu cầu thêm thông tin, bởi vì họ giới thiệu những rào cản đáng kể cho sự\r\nhiểu biết và phân tích. Ví dụ như mã nguồn “bị che khuất” hoặc mã nguồn đã được\r\nlàm cho khó hiểu theo những cách khác do đó nó ngăn cản sự hiểu biết và/hoặc\r\nphâ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\r\nđưa ra một phiên bản của biểu diễn triển khai và chạy một chương trình bị che\r\nkhuất hay làm cho khó hiểu trong đó. Trong khi đại diện bị che khuất là những\r\ngì được biên dịch và có thể được gần hơn để thực hiện (về mặt cấu trúc) so với\r\nban đầu, đại diện bị làm cho khó hiểu, cung cấp mã khó hiểu có thể tiêu tốn\r\nthời gian đáng kể khi thực hiện việc phân tích liên quan đến đại diện. Khi các\r\nhì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ụ\r\nliệm/ thuật toán che khuất được sử dụng để đại diện không bị che khuất có thể\r\nđược cung cấp, và các thông tin bổ sung có thể được sử dụng để đạt được sự tin\r\ncậy về tiến trình che khuất không làm tổn hại bất kỳ chức năng an toàn nào.
\r\n\r\n11.3.4. ADV_IMP.1 Biểu diễn triển khai của\r\nTSF
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_TDS.3 Thiết kế mô đun cơ sở
\r\n\r\nALC_TAT.1 Các công cụ phát triển được xác\r\nđịnh rõ ràng
\r\n\r\n11.3.4.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.3.4.1.1. ADV_IMP.1.1D
\r\n\r\nNhà phát triển cần tạo ra sự sẵn sàng của\r\nbiểu diễn triển khai cho toàn bộ TSF.
\r\n\r\n11.3.4.1.2. ADV_IMP.1.2D
\r\n\r\nNhà phát triển cần cung cấp ánh xạ giữa mô tả\r\nthiết kế TOE và ví dụ của biểu diễn triển khai.
\r\n\r\n11.3.4.2. Các phần tử nội dung và trình bày
\r\n\r\n11.3.4.2.1. ADV_IMP.1.1C
\r\n\r\nBiểu diễn triển khai cần định nghĩa TSF theo\r\nmột mức độ chi tiết như TSF có thể được tạo ra mà không cần các quyết định\r\nthiết kế thêm nào.
\r\n\r\n11.3.4.2.2. ADV_IMP.1.2C
\r\n\r\nBiểu diễn triển khai cần dưới dạng được sử\r\ndụng bởi các cá nhân phát triển.
\r\n\r\n11.3.4.2.3. ADV_IMP.1.3C
\r\n\r\nÁnh xạ giữa mô tả thiết kế TOE và ví dụ thực\r\nhiện cần chứng minh sự đáp ứng của nó.
\r\n\r\n11.3.4.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.3.4.3.1. ADV_IMP.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng, với các mẫu\r\nđược lựa chọn của biểu diễn triển khai, thông tin được cung cấp đáp ứng tất cả\r\nnội dung và trình bày các chứng cứ.
\r\n\r\n11.3.5. ADV_IMP.2 Ánh xạ đầy đủ của biểu diễn\r\ntriển khai của TSF.
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_TDS.3 Thiết kế mô đun cơ sở
\r\n\r\nALC_TAT.1 Các công cụ phát triển được định\r\nnghĩa rõ ràng
\r\n\r\nALC_CMS.5 Hỗ trợ nâng cao
\r\n\r\n11.3.5.1. Các hành động của nhà phát triển
\r\n\r\n11.3.5.1.1. ADV_IMP.2.1D
\r\n\r\nNhà phát triển cần tạo ra biểu diễn triển\r\nkhai sẵn sàng cho toàn bộ TSF.
\r\n\r\n11.3.5.1.2. ADV_IMP.2.2D
\r\n\r\nNhà phát triển cần cung cấp ánh xạ giữa mô tả\r\nthiết kế TOE và toàn bộ biểu diễn triển khai.
\r\n\r\n11.3.5.2. Các phần tử nội dung và trình bày
\r\n\r\n11.3.5.2.1. ADV_IMP.2.1C
\r\n\r\nBiểu diễn thực hiện cần xác định TSF theo các\r\nmức chi tiết mà TSF có thể được tạo ra mà không cần các quyết định thiết kế\r\nthêm.
\r\n\r\n11.3.5.2.2. ADV_IMP.2.2C
\r\n\r\nBiểu diễn triển khai cần được định dạng dưới\r\ndạng được bởi nhà phát triển.
\r\n\r\n11.3.5.2.3. ADV_IMP.2.3C
\r\n\r\nÁnh xạ giữa mô tả thiết kế TOE và toàn bộ\r\nbiểu diễn triển khai cần chứng minh sự đáp ứng.
\r\n\r\n11.3.5.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.3.5.3.1. ADV_IMP.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các chứng cứ.
\r\n\r\n\r\n\r\n11.4.1. Mục tiêu
\r\n\r\nHọ này đề cập đến việc đánh giá cấu trúc\r\ntrong của TSF. Một TSF có bản chất được cấu trúc rõ ràng sẽ dễ dàng hơn để thực\r\nhiện và ít có khả năng chứa lỗ hổng mà có thể dẫn đến các điểm yếu, nó cũng dễ\r\ndàng hơn để duy trì không cần đưa vào các lỗ hổng.
\r\n\r\n11.4.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức\r\ntrên cơ sở số lượng cấu trúc và giảm thiểu độ phức tạp cần thiết. Tập con được\r\ncấu trúc rõ ràng ADV_INT.1 của các chỗ bản chất TSF yêu cầu bản chất được cấu\r\ntrúc rõ ràng trên chỉ các phần lựa chọn của TSF. Thành phần này không bao gồm\r\ntrong EAL bởi vì thành phần này được xem xét để sử dụng trong các trường hợp\r\nđặc biệt (ví dụ, người tài trợ có một mối quan tâm cụ thể về một mô-đun mã hóa,\r\nmà bị cô lập với phần còn lại của TSF) và sẽ không được áp dụng rộng rãi. Ở mức\r\nđộ tiếp theo, các yêu cầu về bản chất được cấu trúc rõ ràng được đặt trên toàn\r\nbộ TSF. Cuối cùng, giảm thiểu độ phức tạp được giới thiệu trong các thành phần\r\ncao nhất.
\r\n\r\n11.4.3. Chú thích ứng dụng
\r\n\r\nNhững yêu cầu này, khi áp dụng cho các cấu\r\ntrúc bên trong của TSF, thường dẫn đến những cải thiện mà hỗ trợ cả nhà phát\r\ntriển và đánh giá viên trong sự hiểu biết về TSF, và cũng cung cấp cơ sở cho\r\nviệc thiết kế và đánh giá các bộ kiểm thử. Hơn nữa, nâng cao hiểu biết của các\r\nTSF sẽ hỗ trợ nhà phát triển đơn giản hóa bảo trì nó.
\r\n\r\nCác yêu cầu trong họ này được trình bày ở mức\r\nđộ khá trừu tượng. Sự đa dạng của TOE làm cho nó không thể biên soạn thành bất\r\ncứ điều gì cụ thể hơn là “có cấu trúc rõ ràng” hay “phức tạp tối thiểu”. Sự\r\nbiện minh về cấu trúc và tính phức tạp được chờ đợi được cung cấp từ các kỹ\r\nthuật đặc biệt được sử dụng trong các TOE. Ví dụ, phần mềm có thể được xem xét\r\ncấu trúc rõ ràng khi nó thể hiện những đặc điểm được trích dẫn trong các ngành\r\nkỹ nghệ phần mềm. Các thành phần bên trong họ này gọi để xác định các tiêu\r\nchuẩn để đo các tính chất được cấu trúc tốt và không quá phức tạp.
\r\n\r\n11.4.4. ADV_INT.1 Tập con cấu trúc rõ ràng\r\ncủa nội bộ TSF
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_IMP.1 Biểu diễn triển khai của TSF
\r\n\r\nADV_TDS.3 Thiết kế mô đun cơ sở
\r\n\r\nALC_TAT.1 Các công cụ phát triển được định\r\nnghĩa rõ ràng
\r\n\r\n11.4.4.1. Các mục tiêu
\r\n\r\nMục tiêu của thành phần này là cung cấp theo\r\ncách làm cho việc yêu cầu các phần đặc biệt của TSF được cấu trúc rõ ràng.
\r\n\r\nTheo dự định toàn bộ TSF đã được thiết kế và\r\nthực hiện bằng cách sử dụng các nguyên tắc kỹ thuật phù hợp, nhưng phân tích\r\nđược thực hiện dựa trên một tập con cụ thể.
\r\n\r\n11.4.4.2. Chú thích ứng dụng
\r\n\r\nThành phần này yêu cầu tác giả PP và ST sẽ\r\nđược gán đầy đủ với các tập con của TSF. Tập con này sẽ được xác định theo dạng\r\nbên trong của TSF tại bất kỳ lớp trừu tượng nào. Ví dụ:
\r\n\r\na) các phần tử cấu trúc của TSF được xác định\r\ntrong thiết kế TOE (ví dụ: “Nhà phát triển cần thiết kế và thực hiện kiểm tra\r\nhệ thống con theo cách mà nó có bản chất cấu trúc rõ ràng”)
\r\n\r\nb) thực hiện (ví dụ: “nhà phát triển cần\r\nthiết kế và thực hiện các tập tin encrypt.c và decrypt.c theo cách chúng có bản\r\nchất cấu trúc rõ ràng.” hoặc “Nhà phát triển cần thiết kế và thực hiện chíp vi\r\nmạch 6.227 theo cách mà nó có bản chất cấu trúc rõ ràng”.”)
\r\n\r\nĐiều này dường như chưa sẵn sàng thực hiện\r\nbằng cách tham khảo các tuyên bố SFR (ví dụ: “Nhà phát triển cần thiết kế và\r\nthực hiện phần của TSF để cung cấp khả năng nặc danh như được định nghĩa trong\r\nFPR_ANO.2 như vậy mà nó có bản chất cấu trúc rõ ràng.”) Bởi vì điều này không\r\nchỉ ra nơi tập trung phân tích.
\r\n\r\nThành phần này có giá trị giới hạn và sẽ\r\nthích hợp trong trường hợp mà người sử dụng/chủ thể của các mã độc hại bị hạn\r\nchế hoặc truy cập kiểm soát truy nhập chặt chẽ các TSFI hoặc nơi có phương tiện\r\nbảo vệ khác (ví dụ, miền tách) để đảm bảo tập con được lựa chọn của TSF không\r\nthể bị ảnh hưởng bởi phần còn lại của TSF (ví dụ, các chức năng mã hóa, mà bị\r\ncô lập với phần còn lại của TS, có cấu trúc rõ ràng).
\r\n\r\n11.4.4.3. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.4.4.3.1. ADV_INT.1.1D
\r\n\r\nNhà phát triển cần thiết kế và thực hiện\r\n[gán: tập con của TSF] theo đó nó có bản chất được cấu trúc rõ ràng.
\r\n\r\n11.4.4.3.2. ADV_INT.1.2D
\r\n\r\nNhà phát triển cần cung cấp mô tả và biện\r\nminh cho nội bộ.
\r\n\r\n11.4.4.4. Các phần tử nội dung và trình bày
\r\n\r\n11.4.4.4.1. ADV_INT.1.1C
\r\n\r\nBiện minh cần giải thích các bản chất được sử\r\ndụng để xem xét ý nghĩa của “cấu trúc rõ ràng”.
\r\n\r\n11.4.4.4.2. ADV_INT.1.2C
\r\n\r\nMô tả các tính chất TSF cần chứng minh rằng\r\ntập con được gán của TSF là được cấu trúc rõ ràng.
\r\n\r\n11.4.4.5. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.4.4.5.1. ADV_INT.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày các chứng\r\ncứ.
\r\n\r\n11.4.4.5.2. ADV_INT.1.2E
\r\n\r\nĐánh giá viên cần thực hiện phân tích bản\r\nchất dựa trên các tập con được gán của TSF.
\r\n\r\n11.4.5. ADV_INT.2 Nội bộ với cấu trúc rõ ràng
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_IMP.1 Biểu diễn triển khai của TSF.
\r\n\r\nADV_TDS.3 Thiết kế mô đun cơ sở
\r\n\r\nALC_TAT.1 Các công cụ phát triển được định\r\nnghĩa rõ ràng.
\r\n\r\n11.4.5.1. Mục tiêu
\r\n\r\nMục tiêu của thành phần này là cung cấp theo\r\ncách làm cho việc yêu cầu TSF được cấu trúc rõ ràng. Theo dự định toàn bộ TSF\r\nđã được thiết kế và thực hiện bằng cách sử dụng các nguyên tắc kỹ thuật phù\r\nhợp.
\r\n\r\n11.4.5.2. Chú thích ứng dụng
\r\n\r\nSự biện minh về tính đầy đủ của cấu trúc và\r\nsự phức tạp được chờ đợi sẽ nhận được từ kỹ thuật đặc biệt được sử dụng trong\r\nTOE. Thành phần này gọi để xác định các tiêu chuẩn để đo đạc tính chất của các\r\ncấu trúc rõ ràng.
\r\n\r\n11.4.5.3. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.4.5.3.1. ADV_INT.2.1D
\r\n\r\nNhà phát triển cần thiết kế và thực hiện toàn\r\nbộ TSF mà bản chất có cấu trúc rõ ràng.
\r\n\r\n11.4.5.3.2. ADV_INT.2.2D
\r\n\r\nNhà phát triển cần cung cấp mô tả và biện\r\nminh cho bản chất.
\r\n\r\n11.4.5.4. Các phần tử nội dung và trình bày
\r\n\r\n11.4.5.4.1. ADV_INT.2.1C
\r\n\r\nSự biện minh cần mô tả các tính chất sử dụng\r\nđể xem xét ý nghĩa của “cấu trúc rõ ràng”.
\r\n\r\n11.4.5.4.2. ADV_INT.2.2C
\r\n\r\nMô tả bản chất TSF cần chứng minh rằng toàn\r\nbộ TSF có cấu trúc rõ ràng.
\r\n\r\n11.4.5.5. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.4.5.5.1. ADV_INT.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng đầy đủ các yêu cầu cho nội dung và trình bày chứng cứ.
\r\n\r\n11.4.5.5.2. ADV_INT.2.2E
\r\n\r\nĐánh giá viên cần thực hiện phân tích bản\r\nchất bên trong TSF.
\r\n\r\n11.4.6. ADV_INT.3 Nội bộ với độ phức tạp tối\r\nthiểu
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_IMP.1 Biểu diễn triển khai của TSF
\r\n\r\nADV_TDS.3 Thiết kế mô đun cơ sở
\r\n\r\nALC_TAT.1 Các công cụ phát triển được định\r\nnghĩa rõ ràng
\r\n\r\n11.4.6.1. Mục tiêu
\r\n\r\nMục tiêu của thành phần này là cung cấp theo\r\ncách làm cho việc yêu cầu TSF được cấu trúc rõ ràng và sự phức tạp nhỏ nhất.\r\nTheo dự định toàn bộ TSF đã được thiết kế và thực hiện bằng cách sử dụng các\r\nnguyên tắc kỹ thuật phù hợp.
\r\n\r\n11.4.6.2. Chú thích ứng dụng
\r\n\r\nSự biện minh về tính đầy đủ của cấu trúc và\r\nsự phức tạp được chờ đợi sẽ nhận được từ kỹ thuật đặc biệt được sử dụng trong\r\nTOE. Thành phần này gọi để xác định các tiêu chuẩn để đo đạc cấu trúc và độ\r\nphức tạp.
\r\n\r\n11.4.6.3. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.4.6.3.1. ADV_INT.3.1D
\r\n\r\nNhà phát triển cần thiết kế và thực hiện toàn\r\nbộ TSF mà bản chất được cấu trúc rõ ràng.
\r\n\r\n11.4.6.3.2. ADV_INT.3.2D
\r\n\r\nNhà phát triển cần cung cấp mô tả và biện\r\nminh cho bản chất
\r\n\r\n11.4.6.4. Các phần tử nội dung và trình bày
\r\n\r\n11.4.6.4.1. ADV_INT.3.1C
\r\n\r\nSự biện minh cần mô tả các tính chất được sử\r\ndụng để xem xét ý nghĩa của “Cấu trúc rõ ràng” và “phức tạp”.
\r\n\r\n11.4.6.4.2. ADV_INT.3.2C
\r\n\r\nMô tả các bản chất của TSF cần chứng minh\r\nrằng toàn bộ TSF được cấu trúc rõ ràng và không phức tạp quá.
\r\n\r\n11.4.6.5. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.4.6.5.1. ADV_INT.3.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng tất cả các yêu cầu cho nội dung và trình bày các chứng\r\ncứ.
\r\n\r\n11.4.6.5.2. ADV_INT.3.2E
\r\n\r\nĐánh giá viên cần thực hiện phân tích bản\r\nchất của trên toàn TSF.
\r\n\r\n11.5.1. Mục tiêu
\r\n\r\nMục tiêu của họ này là cung cấp sự bảo đảm bổ\r\nsung từ sự phát triển của một mô hình chính sách an toàn chính thức của TSF, và\r\nthiết lập một sự tương ứng giữa các đặc tả chức năng và mô hình chính sách an\r\ntoàn. Bảo vệ sự nhất quán nội bộ mô hình chính sách an toàn được chờ đợi để\r\nthiết lập các nguyên tắc an toàn từ các tính chất của nó bằng một chứng minh\r\ntoán học.
\r\n\r\n11.5.2. Phân mức thành phần
\r\n\r\nHọ này chứa chỉ một thành phần.
\r\n\r\n11.5.3. Chú thích ứng dụng
\r\n\r\nBất cập trong một TOE có thể dẫn đến kết quả\r\nlà thất bại trong việc tìm hiểu các yêu cầu an toàn và, từ một thiếu sót trong\r\nthực hiện các yêu cầu an toàn. Việc xác định các yêu cầu an toàn đầy đủ để đảm\r\nbảo sự hiểu biết của họ có thể có vấn đề bởi vì các định nghĩa cần phải đủ\r\nchính xác để tránh kết quả không mong muốn hoặc sai sót trong quá trình thực\r\nhiện của TOE. Qua việc thực hiện, thiết kế, và quy trình soát xét, các yêu cầu\r\nbảo vệ được mô hình hóa có thể được sử dụng như là thiết kế chính xác và hướng\r\ndẫn thực hiện, qua đó cung cấp đảm bảo tăng lên đáp ứng các yêu cầu an toàn\r\nđược thỏa mãn bởi TOE. Độ chính xác của mô hình và kết quả hướng dẫn là dấu\r\nhiệu cải thiện đáng kể bằng việc tạo các mô hình trong một ngôn ngữ chính thức\r\nvà xác minh các yêu cầu an toàn bởi chứng minh hình thức.
\r\n\r\nViệc tạo ra một mô hình chính sách an toàn\r\nchính thức giúp xác định và loại bỏ các phần tử chính sách an toàn không rõ\r\nràng, không phù hợp, mâu thuẫn, hoặc không thể thực thi. Chỉ khi TOE đã được\r\nxây dựng, mô hình chính thức phục vụ các nỗ lực đánh giá góp phần cho các phán\r\nxét của đánh giá viên về việc nhà phát triển có hiểu biết thế nào về chức năng\r\nan toàn đang được thực hiện và có sự nhất quán giữa yêu cầu an toàn và thiết kế\r\nTOE. Sự tin cậy trong mô hình này được đi kèm với bằng chứng rằng nó không chứa\r\nmâu thuẫn.
\r\n\r\nMô hình chính sách an toàn chính thức là một\r\nbài thuyết trình chính thức chính xác về các khía cạnh quan trọng của an toàn\r\nvà mối quan hệ của chúng với các hành vi của TOE, nó xác định tập các quy tắc\r\nvà thông lệ điều chỉnh làm thế nào TSF quản lý, bảo vệ, và kiểm soát các tài\r\nnguyên hệ thống. Mô hình này bao gồm việc thiết lập các hạn chế và các thuộc\r\ntính mà chỉ ra làm thế nào thông tin và tài nguyên tính toán bị ngăn không cho\r\nsử dụng khi vi phạm các SFR, kèm theo một tập thuyết phục các đối số kỹ thuật\r\ncho thấy rằng những hạn chế này và các thuộc tính đóng một vai trò quan trọng\r\ntrong việc thực thi SFR. Nó bao gồm cả hình thức hóa mà biểu diễn các chức năng\r\nan toàn, cũng như các văn bản phụ trợ để giải thích các mô hình và cung cấp cho\r\nnó với ngữ cảnh. Các hành vi an toàn của TSF được mô hình hóa cả về hành vi bên\r\nngoài (tức là làm thế nào TSF tương tác với phần còn lại của TOE và với môi\r\ntrường hoạt động của nó), cũng như các hành vi nội bộ của nó.
\r\n\r\nCác mô hình chính sách an toàn của TOE được\r\ntrích dẫn không chính thức từ thực tế của nó bằng cách xem xét các yêu cầu an\r\ntoàn được đề nghị của ST này. Việc trích dẫn không chính thức được thực hiện\r\nthành công nếu các nguyên tắc của TOE (còn gọi là “bất biến”) đưa ra được thực\r\nthi bởi các đặc tính của nó. Mục đích của các phương pháp chính thức nằm trong\r\nviệc tăng cường sự chặt chẽ của việc thực thi. Đối số không chính thức luôn dễ\r\nbị sai lầm, đặc biệt là nếu các mối quan hệ giữa các chủ thể, đối tượng và hoạt\r\nđộng nhận được tham gia nhiều hơn và nhiều hơn nữa. Để giảm thiểu nguy cơ về\r\ntrạng thái không an toàn đưa đến các quy tắc và tính chất của mô hình chính\r\nsách an toàn được ánh xạ tới các thuộc tính tương ứng và các đặc trưng bên\r\ntrong một số hệ thống chính thức, với sự chặt chẽ và mạnh mẽ có thể được sử\r\ndụng sau đó để có được các thuộc tính an toàn qua các định lý và bằng chứng\r\nchính thức.
\r\n\r\nTrong khi thuật ngữ “mô hình chính sách an\r\ntoàn chính thức” được sử dụng trong giới học thuật, cách tiếp cận của TCVN 8709\r\nkhông có nghĩa cố định về “an toàn”, nó sẽ tương đương với bất cứ điều gì SFR\r\nđược tuyên bố. Vì vậy, mô hình chính sách an toàn chính thức chỉ là một đại\r\ndiện chính thức của tập SFR được tuyên bố.
\r\n\r\nCác chính sách an toàn có kết hợp truyền\r\nthống chỉ với chính sách kiểm soát truy cập, mà dựa trên nhãn (bắt buộc kiểm\r\nsoát truy cập), hoặc dựa trên người dùng (kiểm soát truy cập tùy ý). Tuy nhiên,\r\nmột chính sách an toàn không giới hạn kiểm soát truy cập, còn có những chính\r\nsách kiểm tra, chính sách xác định, chính sách xác thực, chính sách mã hóa,\r\nchính sách quản lý, và các chính sách an toàn khác mà được thực thi bởi các\r\nTOE, như mô tả trong PP/ST.ADV_SPM.1.1D chứa phần để xác định các chính sách\r\nnày được mô hình hóa chính thức.
\r\n\r\n11.5.4. ADV_SPM.1 Mô hình chính sách an toàn\r\nTOE chính thức
\r\n\r\nCác phụ thuộc: ADV_FSP.4 Đặc tả chức năng đầy\r\nđủ.
\r\n\r\n11.5.4.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.5.4.1.1. ADV_SPM.1.1D
\r\n\r\nNhà phát triển cần cung cấp mô hình chính\r\nsách an toàn chính thức cho [gán: danh sách các chính sách mà được mô hình hóa\r\nchính thức].
\r\n\r\n11.5.4.1.2. ADV_SPM.1.2D
\r\n\r\nMỗi chính sách bao gồm mô hình chính sách an\r\ntoàn chính thức, mô hình này cần chỉ ra các phần phù hợp của tuyên bố của SFR\r\nmà là sự phối hợp chính sách đó.
\r\n\r\n11.5.4.1.3. ADV_SPM.1.3D
\r\n\r\nNhà phát triển cần cung cấp chứng minh chính\r\nthức về sự tương ứng giữa mô hình và bất kỳ đặc tả chức năng chính thức nào.
\r\n\r\n11.5.4.1.4. ADV_SPM.1.4D
\r\n\r\nNhà phát triển cần cung cấp chứng minh sự\r\ntương ứng giữa mô hình và đặc tả chức năng.
\r\n\r\n11.5.4.2. Các phần tử nội dung và trình bày
\r\n\r\n11.5.4.2.1. ADV_SPM.1.1C
\r\n\r\nMô hình cần cung cấp kiểu chính thức, được hỗ\r\ntrợ bởi văn bản giải thích được yêu cầu và xác định các chính sách an toàn của\r\nTSF được mô hình hóa.
\r\n\r\n11.5.4.2.2. ADV_SPM.1
Tất cả các chính sách mà được mô hình hóa, mô\r\nhình cần định nghĩa an toàn cho TOE và cung cấp chứng minh chính thức mà TOE\r\nkhông thể tiếp cận đến trạng thái không an toàn.
\r\n\r\n11.5.4.2.3. ADV_SPM.1.3C
\r\n\r\nSự phù hợp giữa mô hình và đặc tả chức năng\r\ncần ở mức chính xác của quy cách.
\r\n\r\n11.5.4.2.4. ADV_SPM.1.4C
\r\n\r\nSự phù hợp cần chỉ ra đặc tả chức năng là\r\nnhất quán và đầy đủ với toàn bộ về mô hình.
\r\n\r\n11.5.4.2.5. ADV_SPM.1.5C
\r\n\r\nChứng minh sự phù hợp cần chỉ ra rằng các\r\ngiao diện trong đặc tả chức năng là nhất quán và đầy đủ về các chính sách được\r\nphân trong ADV_SPM.1.1D.
\r\n\r\n11.5.4.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.5.4.3.1. ADV_SPM.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược cung cấp đáp ứng đầy đủ tất cả các yêu cầu về nội dung và trình bày chứng\r\ncứ.
\r\n\r\n11.6.1. Mục tiêu
\r\n\r\nBản mô tả thiết kế cho một TOE đưa ra ngữ\r\ncảnh mô tả cho TSF đồng thời mô tả chi tiết cho TSF. Khi nhu cầu đảm bảo tăng,\r\nmức chi tiết trong mô tả cũng tăng. Khi phạm vi và độ phức tạp của TSF tăng,\r\nviệc phân tách nhiều mức là thích hợp. Các yêu cầu thiết kế đưa ra các thông\r\ntin với chủ ý (tương xứng với mức đảm bảo cho trước) sao cho có thể đưa ra\r\nquyết định về việc các yêu cầu chức năng an toàn đã được thực hiện.
\r\n\r\n11.6.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức\r\ntrên cơ sở tổng số thông tin đòi hỏi phải thể hiện ứng với TSF và tùy vào mức\r\nđộ hình thức yêu cầu của mô tả thiết kế.
\r\n\r\n11.6.3. Chú thích ứng dụng
\r\n\r\nMục tiêu của tài liệu thiết kế là đưa ra\r\nthông tin đầy đủ để xác định ranh giới TSF và mô tả TSF triển khai các yêu cầu\r\nchức năng an toàn như thế nào. Số lượng và cấu trúc của tài liệu thiết kế phụ\r\nthuộc vào độ phức tạp của TOE và số các SFR. Thông thường, một TOE khá phức tạp\r\nvới một lượng lớn SFR sẽ đòi hỏi nhiều tài liệu thiết kế hơn một TOE đơn giản\r\nchi triển khai cho một vài SFR. Các TOE phức tạp hơn sẽ được lợi từ việc tạo ra\r\ncác mức phân tách khác nhau trong mô tả thiết kế, trong khi các TOE đơn giản\r\nhơn không đòi hỏi mô tả mức cao và mức thấp việc triển khai chúng.
\r\n\r\nHọ này có hai mức phân tách: hệ thống con và\r\nmô đun. Một mô đun là bản mô tả chức năng đặc trưng nhất, nó chính là bản mô tả\r\ntriển khai. Một nhà phát triển cần có khả năng triển khai một phần TOE mô tả\r\ntrong mô đun mà không cần thêm các giải trình về thiết kế khác. Một hệ thống\r\ncon là bản mô tả thiết kế TOE, nó giúp đưa ra mô tả mức cao về một thành phần TOE\r\nđang làm gì và như thế nào. Do vậy, một hệ thống con có thể được chia ra các hệ\r\nthống con mức thấp hơn, hoặc chia ra thành các mô đun. Các TOE phức tạp có thể\r\nđòi hỏi một số mức hệ thống con khác nhau nhằm truyền đạt phù hợp thông tin mô\r\ntả hữu ích về việc TOE làm việc như thế nào. Các TOE đơn giản hơn thì ngược lại\r\nkhông đòi hỏi mô tả cấp hệ thống con nào, mô đun của nó có thể mô tả rõ ràng\r\ncách thức làm việc của TOE.
\r\n\r\nCách thức chung cho tài liệu thiết kế là tùy\r\ntheo mức độ đảm bảo tăng dẫn, mức độ chi tiết của mô tả đi từ mô tả chung (mức\r\nhệ thống con) đến mô tả chi tiết hơn (mức đô mun). Trong các trường hợp mức độ\r\ntrừu tượng ở mức mô đun là phù hợp vì TOE đơn giản đủ để mô tả ở mức mô đun\r\nsong mức đảm bảo yêu cầu mô tả ở mức hệ thống con, thì chỉ cần mô tả ở mức mô\r\nđun là đủ. Tuy nhiên, đối với các TOE phức tạp thì không phải như vậy: một\r\nlượng lớn các chi tiết (mức mô đun) cũng sẽ không đủ nếu không có kèm theo mô\r\ntả ở mức hệ thống con.
\r\n\r\nPhương thức này tuân theo một mô hình chung\r\nlà cung cấp chi tiết bổ sung khi triển khai TSF sẽ đem lại sự đảm bảo tốt hơn\r\nvề việc các SFR được thực thi chính xác và đưa ra thông tin sử dụng để biểu thị\r\nđiều này trong kiểm thử (Kiểm thử ATE).
\r\n\r\nTrong các yêu cầu của họ này, khái niệm giao\r\ndiện dùng để chỉ phương tiện trao đổi (giữa hai hệ thống con hoặc hai mô đun).\r\nNó mô tả cách thức thực hiện trao đổi, tương tự như các chi tiết của TSFI (xem\r\nĐặc tả chức năng ADV_FSP). Khái niệm tương tác dùng để chỉ ra mục đích trao\r\nđổi, nó chỉ ra lý do hai hệ thống con hoặc hai mô đun trao đổi với nhau.
\r\n\r\n11.6.3.1. Chi tiết về các hệ thống con và các\r\nmô đun
\r\n\r\nCác yêu cầu xác định ra tập các chi tiết về\r\ncác hệ thống con và các mô đun cần đưa ra gồm:
\r\n\r\na) Các hệ thống con và các mô đun được xác\r\nđịnh với một danh sách đơn giản mô tả chúng là những gì.
\r\n\r\nb) Các hệ thống con và các mô đun có thể được\r\nphân loại (rõ ràng hoặc ngầm định) thành “bắt buộc theo SFR”, “Hỗ trợ SFR”,\r\nhoặc “Không liên quan đến SFR”. Các khái niệm này được dùng tương tự như trong\r\nphần đặc tả chức năng (ADV_FSP).
\r\n\r\nc) Hoạt động của một hệ thống con chỉ ra nó\r\nlàm những gì. Hoạt động này có thể phân loại thành “bắt buộc theo SFR”, “Hỗ trợ\r\nSFR”, hoặc “Không liên quan đến SFR”. Hoạt động của hệ thống con không bao giờ\r\nđược phân loại khi phân ra nhiều SFR phù hợp hơn là phân loại hệ thống con. Ví\r\ndụ, một hệ thống con bắt buộc theo SFR có thể có hoạt động bắt buộc theo SFR và\r\ncũng có thể là hoạt động Hỗ trợ SFR hoặc Không liên quan đến SFR.
\r\n\r\nd) Tóm tắt hoạt động của một hệ thống con là\r\nmột mô tả tổng quát về các hành động nó thực hiện (ví dụ “hệ thống con TCP tập\r\nhợp các IP datagram vào các luồng byte tin cậy”).
\r\n\r\ne) Mô tả hoạt động của một hệ thống con là\r\nmột bản giải thích về mọi điều nó làm. Mô tả này cần ở mức chi tiết để có thể\r\nxác định rõ ràng là hoạt động này có bất kỳ sự liên quan nào đến việc thực thi\r\ncác SFR hay không.
\r\n\r\nf) Mô tả các tương tác của các hệ thống con\r\nvà các mô đun hoặc tương tác giữa chúng chỉ ra lý do trao đổi thông tin giữa\r\ncác hệ thống con hoặc các mô đun, và đặc tả thông tin chuyển qua nó. Không cần\r\nphải xác định thông tin chi tiết như đặc tả của một giao diện. Ví dụ, sẽ đủ khi\r\nnói rằng “hệ thống con X yêu cầu một khối bộ nhớ từ bộ quản lý bộ nhớ, và nhận\r\nđược vị trí bộ nhớ đã cấp phát”.
\r\n\r\ng) Mô tả giao diện cung cấp chi tiết về cách\r\nthứ thực hiện các tương tác giữa các mô đun. Thay vì mô tả lý do các mô đun\r\ntrao đổi với nhau hay mục đích việc trao đổi thông tin của chúng (nghĩa là mô\r\ntả các tương tác), mô tả giao diện mô tả chi tiết cách thức thực hiện trao đổi\r\nthông tin với các thuật ngữ về cấu trúc, nội dung các bản tin, đánh tín hiệu,\r\ncác trao đổi tiến trình nội bộ,…
\r\n\r\nh) Mục đích mô tả phương thức một mô đun cung\r\ncấp chức năng của nó. Nó đưa ra chi tiết đủ để không cần phải thêm giải trình\r\nthiết kế nào khác. Cần thể hiện rõ tính phù hợp mô tả triển khai mô đun và mục\r\nđích của mô đun.
\r\n\r\ni) Một mô đun được mô tả theo các khác với\r\ncác thuật ngữ được xác định trong phần tử của nó.
\r\n\r\nCác hệ thống con và các mô đun, khái niệm\r\n“Bắt buộc theo SFR”, v.v. sẽ được giải thích chi tiết hơn trong Phụ lục A.4:\r\nCác hệ thống con và các mô đun: ADV_TDS.
\r\n\r\n11.6.4. ADV_TDS.1 Thiết kế cơ sở
\r\n\r\nCác phụ thuộc: ADV_FSP.2 Đặc tả chức năng\r\nthực thi an toàn
\r\n\r\n11.6.4.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.6.4.1.1. ADV_TDS.1.1D
\r\n\r\nNhà phát triển cần đưa ra được bản thiết kế\r\ncủa TOE.
\r\n\r\n11.6.4.1.2. ADV_TDS.1.2D
\r\n\r\nNhà phát triển cần đưa ra được bản ánh xạ\r\ngiữa TSFI về đặc tả chức năng và mức phân tách thấp nhất dùng được trong thiết\r\nkế TOE.
\r\n\r\n11.6.4.2. Các phần tử nội dung và trình bày
\r\n\r\n11.6.4.2.1. ADV_TDS.1.1C
\r\n\r\nBản thiết kế cần mô tả cấu trúc TOE với các\r\nhệ thống con.
\r\n\r\n11.6.4.2.2. ADV_TDS.1.2C
\r\n\r\nBản thiết kế cần chỉ ra tất cả các hệ thống\r\ncon của TSF.
\r\n\r\n11.6.4.2.3. ADV_TDS.1.3C
\r\n\r\nBản thiết kế cần mô tả hoạt động của mỗi hệ\r\nthống con TSF kiểu “hỗ trợ SFR” hoặc “không liên quan SFR” ở mức độ chi tiết đủ\r\nđể khẳng định nó không phải là kiểu “bắt buộc theo SFR”.
\r\n\r\n11.6.4.2.4. ADV_TDS.1.4C
\r\n\r\nBản thiết kế cần tóm lược hoạt động bắt buộc\r\ntheo SFR cho các hệ thống con kiểu “bắt buộc theo SFR”.
\r\n\r\n11.6.4.2.5. ADV_TDS.1.5C
\r\n\r\nBản thiết kế cần đưa ra mô tả về tương tác\r\ncủa các hệ thống con kiểu “bắt buộc theo SFR” của TSF, và giữa các hệ thống con\r\nđó với các hệ thống con của TSF khác.
\r\n\r\n11.6.4.2.6. ADV_TDS.1.6C
\r\n\r\nBản thiết kế cần biểu thị rằng mọi hoạt động\r\nmô tả trong thiết kế TOE được ánh xạ vào trong các TSFI thực thi chúng.
\r\n\r\n11.6.4.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.6.4.3.1. ADV_TDS.1.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\nđã cung cấp đáp ứng mọi yêu cầu về nội dung và biểu thị bằng chứng.
\r\n\r\n11.6.4.3.2. ADV_TDS.1.2E
\r\n\r\nĐánh giá viên cần xác định rằng bản thiết kế\r\nlà một bản sao chính xác và đầy đủ mọi yêu cầu chức năng an toàn.
\r\n\r\n11.6.5. ADV_TDS.2 Thiết kế kiến trúc
\r\n\r\nCác phụ thuộc: ADV_FSP.3 Đặc tả chức năng với\r\nbản tổng hợp đầy đủ.
\r\n\r\n11.6.5.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.6.5.1.1. ADV_TDS.2.1D
\r\n\r\nNhà phát triển cần đưa ra được bản thiết kế của\r\nTOE.
\r\n\r\n11.6.5.1.2. ADV_TDS.2.2D
\r\n\r\nNhà phát triển cần đưa ra được bản ánh xạ giữa\r\nTSFI về đặc tả chức năng và mức phân tách thấp nhất dùng được trong thiết kế\r\nTOE.
\r\n\r\n11.6.5.2. Các phần tử nội dung và trình bày
\r\n\r\n11.6.5.2.1. ADV_TDS.2.1C
\r\n\r\nBản thiết kế cần mô tả cấu trúc TOE với các\r\nhệ thống con.
\r\n\r\n11.6.5.2.2. ADV_TDS.2.2C
\r\n\r\nBản thiết kế cần chỉ ra tất cả các hệ thống\r\ncon của TSF.
\r\n\r\n11.6.5.2.3. ADV_TDS.2.3C
\r\n\r\nBản thiết kế cần mô tả hoạt động của mỗi hệ\r\nthống con TSF kiểu “không liên quan SFR” ở mức độ chi tiết đủ để khẳng định nó\r\nlà kiểu “không liên quan SFR”.
\r\n\r\n11.6.5.2.4. ADV_TDS.2.4C
\r\n\r\nBản thiết kế cần tóm lược hoạt động bắt buộc\r\ntheo SFR cho các hệ thống con kiểu “bắt buộc theo SFR”.
\r\n\r\n11.6.5.2.5. ADV_TDS.2.5C
\r\n\r\nBản thiết kế cần tóm tắt hoạt động “hỗ trợ\r\nSFR” và “không liên quan SFR” của các hệ thống con kiểu “bắt buộc theo SFR”.
\r\n\r\n11.6.5.2.6. ADV_TDS.2.6C
\r\n\r\nBản thiết kế cần tóm tắt hoạt động của các hệ\r\nthống con kiểu “hỗ trợ SFR”.
\r\n\r\n11.6.5.2.7. ADV_TDS.2.7C
\r\n\r\nBản thiết kế cần đưa ra mô tả về tương tác\r\ncủa tất cả các hệ thống con của TSF.
\r\n\r\n11.6.5.2.8. ADV_TDS.2.8C
\r\n\r\nBản thiết kế cần biểu thị rằng mọi hoạt động\r\nmô tả trong thiết kế TOE được ánh xạ vào trong các TSFI thực thi chúng.
\r\n\r\n11.6.5.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.6.5.3.1. ADV_TDS.2.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\nđã cung cấp đáp ứng mọi yêu cầu về nội dung và biểu thị bằng chứng.
\r\n\r\n11.6.5.3.2. ADV_TDS.2.2E
\r\n\r\nĐánh giá viên cần xác định rằng bản thiết kế\r\nlà một bản sao chính xác và đầy đủ mọi yêu cầu chức năng an toàn.
\r\n\r\n11.6.6. ADV_TDS.3 Thiết kế mô đun cơ sở
\r\n\r\nCác phụ thuộc: ADV_FSP.4 Đặc tả chức năng đầy\r\nđủ
\r\n\r\n11.6.6.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.6.6.1.1. ADV_TDS.3.1D
\r\n\r\nNhà phát triển cần đưa ra được bản thiết kế\r\ncủa TOE.
\r\n\r\n11.6.6.1.2. ADV_TDS.3.2D
\r\n\r\nNhà phát triển cần đưa ra được bản ánh xạ\r\ngiữa TSFI về đặc tả chức năng và mức phân tách thấp nhất dùng được trong thiết\r\nkế TOE.
\r\n\r\n11.6.6.2. Các phần tử nội dung và trình bày
\r\n\r\n11.6.6.2.1. ADV_TDS.3.1C
\r\n\r\nBản thiết kế cần mô tả cấu trúc TOE với các\r\nhệ thống con.
\r\n\r\n11.6.6.2.2 ADV_TDS.3.2C
\r\n\r\nBản thiết kế cần mô tả tất cả các mô đun của\r\nTSF.
\r\n\r\n11.6.6.2.3. ADV_TDS.3.3C
\r\n\r\nBản thiết kế cần chỉ ra tất cả các hệ thống\r\ncon của TSF.
\r\n\r\n11.6.6.2.4. ADV_TDS.3.4C
\r\n\r\nBản thiết kế cần đưa ra mô tả cho mỗi hệ\r\nthống con của TSF.
\r\n\r\n11.6.6.2.5. ADV_TDS.3.5C
\r\n\r\nBản thiết kế cần đưa ra mô tả cho các tương\r\ntác của mọi hệ thống con của TSF.
\r\n\r\n11.6.6.2.6. ADV_TDS.3.6C
\r\n\r\nBản thiết kế cần đưa ra ánh xạ từ các hệ\r\nthống con của TSF đến các mô đun của TSF.
\r\n\r\n11.6.6.2.7. ADV_TDS.3.7C
\r\n\r\nBản thiết kế cần mô tả mỗi mô đun “hỗ trợ\r\nSFR” và “không liên quan SFR” với mục đích và tương tác của chúng với các mô\r\nđun khác.
\r\n\r\n11.6.6.2.8. ADV_TDS.3.8C
\r\n\r\nBản thiết kế cần mô tả mỗi mô đun “bắt buộc\r\ntheo 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\r\ngiao 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.
\r\n\r\n11.6.6.2.9. ADV_TDS.3.9C
\r\n\r\nBản thiết kế cần mô tả mỗi mô đun “hỗ trợ\r\nSFR” hoặc “không liên quan SFR” với mục đích và tương tác của chúng với\r\ncác mô đun khác.
\r\n\r\n11.6.6.2.10. ADV_TDS.3.10C
\r\n\r\nBản thiết kế cần biểu thị rằng mọi hoạt động\r\nmô tả trong thiết kế TOE được ánh xạ vào trong các TSFI thực thi chúng.
\r\n\r\n11.6.6.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.6.6.3.1. ADV_TDS.3.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\nđã cung cấp đáp ứng mọi yêu cầu về nội dung và biểu thị bằng chứng.
\r\n\r\n11.6.6.3.2. ADV_TDS.3.2E
\r\n\r\nĐánh giá viên cần xác định rằng bản thiết kế\r\nlà một bản sao chính xác và đầy đủ mọi yêu cầu chức năng an toàn.
\r\n\r\n11.6.7. ADV_TDS.4 Thiết kế mô đun bán chính\r\nthức
\r\n\r\nCác phụ thuộc: ADV_FSP.5 Đặc tả chức năng bán\r\nchính thức đầy đủ với thông tin lỗi bổ sung
\r\n\r\n11.6.7.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.6.7.1.1. ADV_TDS.4.1D
\r\n\r\nNhà phát triển cần đưa ra được bản thiết kế\r\ncủa TOE.
\r\n\r\n11.6.7.1.2. ADV_TDS.4.2D
\r\n\r\nNhà phát triển cần đưa ra được bản ánh xạ\r\ngiữa TSFI về đặc tả chức năng và mức phân tách thấp nhất dùng được trong thiết\r\nkế TOE.
\r\n\r\n11.6.7.2. Các phần tử nội dung và trình bày
\r\n\r\n11.6.7.2.1. ADV_TDS.4.1C
\r\n\r\nBản thiết kế cần mô tả cấu trúc TOE với các\r\nhệ thống con.
\r\n\r\n11.6.7.2.2. ADV_TDS.4.2C
\r\n\r\nBản thiết kế cần mô tả TSF với các mô đun,\r\nthiết kế mỗi mô đun theo “bắt buộc theo SFR”, “hỗ trợ SFR”, hoặc “không liên\r\nquan SFR”.
\r\n\r\n11.6.7.2.3. ADV_TDS.4.3C
\r\n\r\nBản thiết kế cần chỉ ra tất cả các hệ thống\r\ncon của TSF.
\r\n\r\n11.6.7.2.4. ADV_TDS.4.4C
\r\n\r\nBản thiết kế cần đưa ra mô tả bán chính\r\nthứ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\r\nthức phù hợp.
\r\n\r\n11.6.7.2.5. ADV_TDS.4.5C
\r\n\r\nBản thiết kế cần đưa ra mô tả cho các tương\r\ntác của mọi hệ thống con của TSF.
\r\n\r\n11.6.7.2.6. ADV_TDS.4.6C
\r\n\r\nBản thiết kế cần đưa ra ánh xạ từ các hệ\r\nthống con của TSF đến các mô đun của TSF.
\r\n\r\n11.6.7.2.7. ADV_TDS.4.7C
\r\n\r\nBản thiết kế cần mô tả mỗi mô đun “bắt\r\nbuộc SFR” và “hỗ trợ SFR” với mục đích và tương tác của chúng với các mô\r\nđun khác.
\r\n\r\n11.6.7.2.8. ADV_TDS.4.8C
\r\n\r\nBản thiết kế cần mô tả mỗi mô đun “bắt buộc\r\ntheo SFR” với các giao diện liên quan SFR của chúng, cho lại các giá trị các\r\ngiao 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.
\r\n\r\n11.6.7.2.9. ADV_TDS.4.9C
\r\n\r\nBản thiết kế cần mô tả mỗi mô đun “không liên\r\nquan SFR” với mục đích và tương tác của chúng với các mô đun khác.
\r\n\r\n11.6.7.2.10. ADV_TDS.4.10C
\r\n\r\nBản thiết kế cần biểu thị rằng mọi hoạt động\r\nmô tả trong thiết kế TOE được ánh xạ vào trong các TSFI thực thi chúng.
\r\n\r\n11.6.7.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.6.7.3.1. ADV_TDS.4.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\nđã cung cấp đáp ứng mọi yêu cầu về nội dung và biểu thị bằng chứng.
\r\n\r\n11.6.7.3.2. ADV_TDS.4.2E
\r\n\r\nĐánh giá viên cần xác định rằng bản thiết kế\r\nlà một bản sao chính xác và đầy đủ mọi yêu cầu chức năng an toàn.
\r\n\r\n11.6.8. ADV_TDS.5 Thiết kế mô đun bán chính\r\nthức đầy đủ
\r\n\r\nCác phụ thuộc: ADV_FSP.5 Đặc tả chức năng bán\r\nchính thức đầy đủ với thông tin lỗi bổ sung
\r\n\r\n11.6.8.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.6.8.1.1. ADV_TDS.5.1D
\r\n\r\nNhà phát triển cần đưa ra được bản thiết kế\r\ncủa TOE.
\r\n\r\n11.6.8.1.2. ADV_TDS.5.2D
\r\n\r\nNhà phát triển cần đưa ra được bản ánh xạ giữa\r\nTSFI về đặc tả chức năng và mức phân tách thấp nhất dùng được trong thiết kế\r\nTOE.
\r\n\r\n11.6.8.2. Các phần tử nội dung và trình bày
\r\n\r\n11.6.8.2.1. ADV_TDS.5.1C
\r\n\r\nBản thiết kế cần mô tả cấu trúc TOE với các\r\nhệ thống con.
\r\n\r\n11.6.8.2.2. ADV_TDS.5.2C
\r\n\r\nBản thiết kế cần mô tả TSF với các mô đun,\r\nthiết kế mỗi mô đun theo “bắt buộc theo SFR”, “hỗ trợ SFR”, hoặc “không liên\r\nquan SFR”.
\r\n\r\n11.6.8.2.3. ADV_TDS.5.3C
\r\n\r\nBản thiết kế cần chỉ ra tất cả các hệ thống\r\ncon của TSF.
\r\n\r\n11.6.8.2.4. ADV_TDS.5.4C
\r\n\r\nBản thiết kế cần đưa ra mô tả bán chính thức\r\ncho 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.
\r\n\r\n11.6.8.2.5. ADV_TDS.5.5C
\r\n\r\nBản thiết kế cần đưa ra mô tả cho các tương\r\ntác của mọi hệ thống con của TSF.
\r\n\r\n11.6.8.2.6. ADV_TDS.5.6C
\r\n\r\nBản thiết kế cần đưa ra ánh xạ từ các hệ thống\r\ncon của TSF đến các mô đun của TSF.
\r\n\r\n11.6.8.2.7. ADV_TDS.5.7C
\r\n\r\nBản thiết kế cần mô tả bán chính thức mỗi\r\nmô đun với mục đích, tương tác, giao diện của chúng, cho lại các giá trị\r\ntừ các giao diện này, tương tác với và gọi các giao diện tới các mô đun khác, với\r\nvăn bản giải thích không chính thức phù hợp.
\r\n\r\n11.6.8.2.8. ADV_TDS.5.8C
\r\n\r\nBản thiết kế cần biểu thị rằng mọi hoạt động\r\nmô tả trong thiết kế TOE được ánh xạ vào trong các TSFI thực thi chúng.
\r\n\r\n11.6.8.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.6.8.3.1. ADV_TDS.5.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\nđã cung cấp đáp ứng mọi yêu cầu về nội dung và biểu thị bằng chứng.
\r\n\r\n11.6.8.3.2. ADV_TDS.5.2E
\r\n\r\nĐánh giá viên cần xác định rằng bản thiết kế\r\nlà một bản sao chính xác và đầy đủ mọi yêu cầu chức năng an toàn.
\r\n\r\n11.6.9. ADV_TDS.6 Thiết kế mô đun bán chính\r\nthức đầy đủ với bản thể hiện thiết kế chính thức mức cao
\r\n\r\nCác phụ thuộc: ADV_FSP.6 Đặc tả chức năng bán\r\nchính thức đầy đủ với bổ sung đặc tả chính thức
\r\n\r\n11.6.9.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n11.6.9.1.1. ADV_TDS.6.1D
\r\n\r\nNhà phát triển cần đưa ra được bản thiết kế\r\ncủa TOE.
\r\n\r\n11.6.9.1.2. ADV_TDS.6.2D
\r\n\r\nNhà phát triển cần đưa ra được bản ánh xạ\r\ngiữa TSFI về đặc tả chức năng và mức phân tách thấp nhất dùng được trong thiết\r\nkế TOE.
\r\n\r\n11.6.9.1.3. ADV_TDS.6.3D
\r\n\r\nNhà phát triển cần đưa ra được đặc tả chính\r\nthức cho các hệ thống con TSF.
\r\n\r\n11.6.9.1.4. ADV_TDS.6.4D
\r\n\r\nNhà phát triển cần đưa ra được minh chứng về\r\nsự phù hợp giữa các đặc tả chính thức cho các hệ thống con TSF và cho đặc tả\r\nchức năng.
\r\n\r\n11.6.9.2. Các phần tử nội dung và trình bày
\r\n\r\n11.6.9.2.1 ADV_TDS.6.1C
\r\n\r\nBản thiết kế cần mô tả cấu trúc TOE với các\r\nhệ thống con.
\r\n\r\n11.6.9.2.2 ADV_TDS.6.2C
\r\n\r\nBản thiết kế cần mô tả TSF với các mô đun,\r\nthiết kế mỗi mô đun theo “bắt buộc theo SFR”, “hỗ trợ SFR”, hoặc “không liên\r\nquan SFR”.
\r\n\r\n11.6.9.2.3. ADV_TDS.6.3C
\r\n\r\nBản thiết kế cần chỉ ra tất cả các hệ thống\r\ncon của TSF.
\r\n\r\n11.6.9.2.4. ADV_TDS.6.4C
\r\n\r\nBản thiết kế cần đưa ra mô tả bán chính thức\r\ncho 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.
\r\n\r\n11.6.9.2.5. ADV_TDS.6.5C
\r\n\r\nBản thiết kế cần đưa ra mô tả cho các tương\r\ntác của mọi hệ thống con của TSF.
\r\n\r\n11.6.9.2.6. ADV_TDS.6.6C
\r\n\r\nBản thiết kế cần đưa ra ánh xạ từ các hệ\r\nthống con của TSF đến các mô đun của TSF.
\r\n\r\n11.6.9.2.7. ADV_TDS.6.7C
\r\n\r\nBản thiết kế cần mô tả theo kiểu bán chính\r\nthức cho mỗi mô đun với mục đích, tương tác, các giá trị cho lại từ các\r\ngiao diện này, và các giao diện được gọi tới các mô đun khác, với văn bản giải\r\nthích không chính thức phù hợp.
\r\n\r\n11.6.9.2.8. ADV_TDS.6.8C
\r\n\r\nĐặc tả chính thức của các hệ thống con TSF\r\ncần mô tả TSF theo kiểu chính thức, kèm văn bản giải thích không chính thức phù\r\nhợp.
\r\n\r\n11.6.9.2.9. ADV_TDS.6.9C
\r\n\r\nÁnh xạ cần biểu thị rằng mọi hoạt động mô tả\r\ntrong thiết kế TOE được ánh xạ vào trong các TSFI thực thi chúng.
\r\n\r\n11.6.9.2.10. ADV_TDS.6.10C
\r\n\r\nMinh chứng cho sự phù hợp giữa các đặc tả\r\nchính thức cho các hệ thống con TSF và cho đặc tả chức năng cần biểu thị rằng\r\nmọi hoạt động mô tả trong thiết kế TOE là bản chi tiết hóa một cách đầy đủ và\r\nchính xác của TSFI thực thi chúng.
\r\n\r\n11.6.9.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n11.6.9.3.1. ADV_TDS.6.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\nđã cung cấp đáp ứng mọi yêu cầu về nội dung và biểu thị bằng chứng.
\r\n\r\n11.6.9.3.2. ADV_TDS.6.2E
\r\n\r\nĐánh giá viên cần xác định rằng bản thiết kế\r\nlà một bản sao chính xác và đầy đủ mọi yêu cầu chức năng an toàn.
\r\n\r\nLớp tài liệu hướng dẫn đưa ra những yêu cầu\r\ncho tài liệu hướng dẫn cho người sử dụng. Đối với việc chuẩn bị và vận hành an\r\ntoàn TOE, điều này là cần thiết để mô tả tất cả những vấn đề về xử lý an toàn\r\ncủa TOE. Lớp cũng đề cập đến khả năng cấu hình không đúng như mong muốn hoặc\r\nviệc xử lý TOE.
\r\n\r\nTrong nhiều trường hợp, có thể thích hợp hơn\r\nlà hướng dẫn được chia ra nhiều tài liệu cho chuẩn bị và vận hành an toàn TOE,\r\nhoặc các tài liệu riêng cho những người sử dụng khác nhau như: người dùng đầu\r\ncuối, quản trị viên, người lập trình ứng dụng sử dụng các giao diện phần cứng,\r\nphần mềm…
\r\n\r\nLớp tài liệu hướng dẫn được chia thành hai\r\nhọ, có liên quan đến phần hướng dẫn chuẩn bị cho người dùng (là điều cần thực\r\nhiện khi chuyển đổi TOE đã bàn giao sang cấu hình đã đánh giá trong môi trường\r\nvận hành như đã mô tả trong ST) và với phần hướng dẫn người dùng vận hành\r\n(những gì cần thực hiện trong quá trình khai thác TOE trong cấu hình đã đánh\r\ngiá của nó.
\r\n\r\nHình 12 biểu thị các họ trong lớp này, phân\r\nlớp thành phần trong các họ.
\r\n\r\n![](\"00907948_files/image012.jpg\")
12.1.1. Mục tiêu
\r\n\r\nTài liệu hướng dẫn này đề cập đến các tài\r\nliệu văn bản dành cho những người dùng TOE trong cấu hình đã đánh giá của nó\r\nbao gồm: người dùng đầu cuối, người có trách nhiệm duy trì và quản lý TOE theo\r\ncách đúng nhằm đạt sự an toàn tối đa, và những người dùng khác (ví dụ các lập\r\ntrình viên) sử dụng các giao diện TOE với bên ngoài. Tài liệu hướng dẫn người\r\ndùng vận hành mô tả chức năng an toàn cung cấp bởi TSF, đưa ra các lệnh và\r\nhướng dẫn (gồm cả cảnh báo), giúp hiểu được TSF và bao gồm thông tin an toàn\r\ntrọng yếu, các hành động an toàn trọng yếu cần có, nhằm đảm bảo sử dụng chúng\r\nan toàn. Hướng dẫn sai hoặc không hợp lý cần loại bỏ khỏi tài liệu hướng dẫn,\r\ncác thủ tục an toàn cho mọi chế độ hoạt động cần được xem xét. Các trạng thái\r\nkhông an toàn cần dễ phát hiện.
\r\n\r\nHướng dẫn người dùng vận hành đưa ra biện\r\npháp tin cậy giúp các người sử dụng thông thường, các quản trị viên, các nhà\r\ncung cấp ứng dụng và những đối tượng khác liên quan đến giao diện bên ngoài TOE\r\nhiểu được hoạt động an toàn của TOE và sử dụng nó như đã dự kiến. Đánh giá\r\nhướng dẫn người dùng bao gồm cả việc xem xét xem TOE có thể sử dụng theo cách\r\nkhông an toàn như thế nào và người dùng TOE cần tin là nó hoạt động an toàn.\r\nMục tiêu là giảm thiểu rủi ro do con người và các lỗi khác khi hoạt động có thể\r\ngây ra ngăn cản, làm sai hoặc chặn chức năng an toàn để đưa TOE vào trạng thái\r\nkhông an toàn không thể phát hiện được.
\r\n\r\n12.1.2. Phân mức thành phần
\r\n\r\nHọ này chỉ gồm một thành phần.
\r\n\r\n12.1.3. Chú thích ứng dụng
\r\n\r\nCó thể các vai trò người dùng và nhóm người\r\ndùng khác nhau được chấp thuận trong TOE và họ có thể tương tác với TSF. Vai\r\ntrò người dùng và các nhóm này cần được xem xét trong tài liệu hướng dẫn người\r\ndùng vận hành. Họ có thể được nhóm vào quản trị viên và những người dùng không\r\ncó vai trò quản trị, hoặc cụ thể hơn được nhóm vào các cá nhân có trách nhiệm\r\nvề việc: nhận, chấp thuận, cài đặt và duy trì TOE, lập trình viên các ứng dụng,\r\nngười soát xét, kiểm toán viên, quản trị viên hàng ngày, người dùng đầu cuối.\r\nMỗi vai trò có thể bao hàm một tập năng lực hoặc chỉ một quyền duy nhất.
\r\n\r\nYêu cầu AGD_OPE.1.1C bao hàm khía cạnh mọi\r\ncảnh báo tới người dùng trong khi vận hành TOE sẽ liên quan đến định nghĩa vấn\r\nđề an toàn và các mục tiêu an toàn cho môi trường vận hành được mô tả trong\r\nPP/ST là phù hợp trong hướng dẫn người dùng.
\r\n\r\nKhái niệm các giá trị an toàn, như đã nêu\r\ntrong AGD_OPE.1.3.C có liên quan về vị trí người dùng có quyền kiểm soát các\r\ntham số an toàn. Hướng dẫn cần đưa ra đối với việc đặt đúng và không an toàn\r\ncác tham số trên.
\r\n\r\nAGD_OPE.1.4C đòi hỏi hướng dẫn người dùng\r\nphải mô tả các phản ứng phù hợp với các sự kiện an toàn liên quan. Mặc dù nhiều\r\nsự kiện an toàn là kết quả của thực hiện các chức năng, cũng không nhất thiết\r\nphải như vậy trong một số trường hợp (ví dụ kiểm toán bản ghi nhật ký, phát\r\nhiện một xâm nhập). Ngoài ra, một sự kiện liên quan an toàn có thể xảy ra là\r\nkết quả của một chuỗi các chức năng, hoặc, ngược lại, một số sự kiện an toàn có\r\nthể xảy ra với một chức năng.
\r\n\r\nAGD_OPE.1.7C đòi hỏi rằng hướng dẫn người\r\ndùng phải rõ ràng và hợp lý. Hướng dẫn sai hoặc không hợp lý có thể dẫn đến\r\nviệc một người dùng TOE tin rằng TOE an toàn trong khi nó không phải như vậy.
\r\n\r\nMột ví dụ về hướng dẫn sai có thể là mô tả về\r\nmột lệnh hướng dẫn đơn lẻ có thể truyền theo nhiều cách, một trong những cách\r\nđó có thể dẫn đến trạng thái không an toàn.
\r\n\r\nMột ví dụ về hướng dẫn không an toàn có thể\r\nlà một khuyến nghị tuân theo một thủ tục mà nó quá phức tạp không thể kỳ vọng\r\nnhư mong muốn là người dùng thực hiện theo.
\r\n\r\n12.1.4. Hướng dẫn người dùng vận hành\r\nAGD_OPE.1
\r\n\r\nPhụ thuộc: ADV_FSP.1 Đặc tả chức năng cơ bản
\r\n\r\n12.1.4.1. Các thành phần hành động nhà phát\r\ntriển
\r\n\r\n12.1.4.1.1. AGD_OPE.1.1D
\r\n\r\nNhà phát triển cần đưa ra tài liệu hướng dẫn\r\nngười dùng vận hành.
\r\n\r\n12.1.4.2. Các phần tử nội dung và trình bày
\r\n\r\n12.1.4.2.1. AGD_OPE.1
Tài liệu hướng dẫn người dùng vận hành cần mô\r\ntả các vai trò từng người, các chức năng truy nhập người dùng và các đặc quyền\r\ncần được kiểm soát trong môi trường xử lý an toàn, bao gồm các cảnh báo phù\r\nhợp.
\r\n\r\n12.1.4.2.2. AGD_OPE.1.2C
\r\n\r\nTài liệu hướng dẫn người dùng vận hành cần mô\r\ntả các vai trò từng người, cách thức sử dụng các giao diện sẵn có cung cấp bởi TOE\r\ntheo cách an toàn.
\r\n\r\n12.1.4.2.3. AGD_OPE.1.3C
\r\n\r\nTài liệu hướng dẫn người dùng vận hành cần mô\r\ntả các vai trò từng người, các chức năng sẵn có và các giao diện, cụ thể là một\r\ntham số an toàn dưới sự kiểm soát của người dùng, biểu thị các giá trị an toàn\r\nphù hợp.
\r\n\r\n12.1.4.2.4. AGD_OPE.1.4C
\r\n\r\nTài liệu hướng dẫn người dùng vận hành cần mô\r\ntả các vai trò từng người, định rõ mỗi kiểu sự kiện an toàn liên quan tương đối\r\nso với các chức năng truy nhập người dùng cần thực hiện, bao gồm việc thay đổi\r\ncác đặc tính an toàn của các thực thể dưới sự kiểm soát của TSF.
\r\n\r\n12.1.4.2.5. AGD_OPE.1.5C
\r\n\r\nTài liệu hướng dẫn người dùng vận hành cần\r\nxác định mọi chế độ hoạt động có thể của TOE (bao gồm hoạt động sau lỗi và lỗi\r\nvận hành), tính hợp lý của chúng và các ngầm định nhằm duy trì hoạt động an\r\ntoàn.
\r\n\r\n12.1.4.2.6. AGD_OPE.1.6C
\r\n\r\nTài liệu hướng dẫn người dùng vận hành cần mô\r\ntả cho vai trò từng người, các biện pháp an toàn cần theo nhằm thỏa mãn các mục\r\ntiêu an toàn cho môi trường hoạt động như đã mô tả trong ST.
\r\n\r\n12.1.4.2.7. AGD_OPE.1.7C
\r\n\r\nTài liệu hướng dẫn người dùng vận hành cần rõ\r\nràng và hợp lý.
\r\n\r\n12.1.4.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n12.1.4.3.1. AGD_OPE.1.1E
\r\n\r\nĐánh giá viên cần xác nhận thông tin đưa ra\r\nđáp ứng mọi nhu cầu về nội dung và trình bày của chứng cứ.
\r\n\r\n12.2.1. Mục tiêu
\r\n\r\nCác thủ tục chuẩn bị dùng để đảm bảo rằng TOE\r\nđã được nhận, cài đặt theo cách an toàn như dự kiến bởi nhà phát triển. Các yêu\r\ncầu chuẩn bị đặt ra nhiệm vụ chuyển đổi an toàn từ TOE đã bàn giao sang môi\r\ntrường vận hành ban đầu của nó. Điều này bao gồm việc xem xét xem TOE có thể\r\nđược cấu hình hoặc cài đặt theo cách không an toàn mà người dùng TOE vẫn tin\r\nrằng nó an toàn hay không.
\r\n\r\n12.2.2. Phân mức thành phần
\r\n\r\nHọ này chỉ gồm một thành phần
\r\n\r\n12.2.3. Chú thích ứng dụng
\r\n\r\nCó thể thấy áp dụng các yêu cầu này sẽ khác\r\nnhau tùy theo góc độ TOE có được chuyển giao vào trạng thái vận hành hay không,\r\nhay nó được cài đặt tại địa điểm của chủ sở hữu TOE,….
\r\n\r\nQuy trình đầu tiên liên quan các thủ tục\r\nchuẩn bị là việc chấp nhận an toàn của người tiêu dùng khi nhận TOE tuân theo\r\ncác thủ tục chuyển giao từ nhà phát triển. Nếu nhà phát triển không định nghĩa\r\ncác thủ tục chuyển giao, thì an toàn cho việc chấp nhận cũng cần đảm bảo.
\r\n\r\nViệc cài đặt TOE bao gồm chuyển đổi môi\r\ntrường vận hành của nó vào trạng thái tuân thủ theo các mục tiêu an toàn cho\r\nmôi trường vận hành đã đưa ra trong ST.
\r\n\r\nCó thể có trường hợp không cần thiết phải cài\r\nđặt, ví dụ một thẻ thông minh. Trong trường hợp này, có thể không phù hợp nếu\r\nyêu cầu và phân tích các thủ tục cài đặt.
\r\n\r\nCác yêu cầu trong họ bảo đảm này được trình\r\nbày tách biệt với họ Hướng dẫn người dùng vận hành (AGD_OPE), bởi vì việc sử\r\ndụng không thường xuyên và chỉ một lần của các thủ tục chuẩn bị.
\r\n\r\n12.2.4. Các thủ tục chuẩn bị AGD_PRE.1
\r\n\r\nCác mối phụ thuộc: không có sự phụ thuộc nào.
\r\n\r\n12.2.4.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n12.2.4.1.1. AGD_PRE.1.1D
\r\n\r\nNhà phát triển cần cung cấp TOE bao gồm các\r\nthủ tục chuẩn bị nó.
\r\n\r\n12.2.4.2. Các phần tử nội dung và trình bày
\r\n\r\n12.2.4.2.1. AGD_PRE.1.1C
\r\n\r\nCác thủ tục chuẩn bị cần mô tả mọi bước cần\r\nthiết để chấp nhận an toàn cho TOE đã chuyển giao tuân theo các thủ tục chuyển\r\ngiao của nhà phát triển.
\r\n\r\n12.2.4.2.2. AGD_PRE.1.2C
\r\n\r\nCác thủ tục chuẩn bị cần mô tả mọi bước cần\r\nthiết cho cài đặt an toàn TOE và chuẩn bị an toàn môi trường vận hành tuân theo\r\ncác mục tiêu an toàn cho môi trường vận hành đã mô tả trong ST.
\r\n\r\n12.2.4.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n12.2.4.3.1. AGD_PRE.1.1E
\r\n\r\nĐánh giá viên cần xác nhận thông tin cung cấp\r\nđáp ứng mọi nhu cầu về nội dung và trình bày của chứng cứ.
\r\n\r\n12.2.4.3.2. AGD_PRE.1.2E
\r\n\r\nĐánh giá viên cần áp dụng các thủ tục chuẩn\r\nbị để khẳng định rằng TOE cần được chuẩn bị an toàn cho hoạt động.
\r\n\r\nHỗ trợ vòng đời là một khía cạnh của tạo lập\r\nqui tắc và kiểm soát trong quá trình bổ sung chi tiết của TOE trong khi phát\r\ntriển và duy trì nó. Tính tin cậy trong trao đổi giữa các yêu cầu an toàn TOE\r\nvà TOE là lớn hơn nếu phân tích an toàn và việc đưa ra chứng cứ được làm trên\r\ncơ sở điều tiết như một phần toàn vẹn của các hoạt động phát triển và duy trì.
\r\n\r\nTrong vòng đời sản phẩm, việc phân biệt xem\r\nTOE là trách nhiệm của nhà phát triển hay người dùng được quan tâm hơn là nó thuộc\r\nmôi trường phát triển hay môi trường người dùng. Ranh giới chuyển đổi là thời\r\nđiểm bàn giao TOE cho người dùng. Đó cũng là thời điểm chuyển đổi từ lớp ALC\r\nsang lớp AGD.
\r\n\r\nLớp ALC bao gồm 7 họ. Họ Định nghĩa vòng đời\r\n(ALC_LCD) mô tả mức cao cho vòng đời TOE. Họ Năng lực CM (ALC_CM) mô tả chi\r\ntiết hơn về việc quản lý các danh mục lập cấu hình. Phạm vi CM (ALC_CMS) đòi\r\nhỏi một tập danh mục cấu hình tối thiểu cần quản lý theo cách đã xác định. An\r\ntoàn phát triển (ALC_DVS) liên quan đến các biện pháp về vật lý, thủ tục và con\r\nngười cũng như các biện pháp an toàn khác của nhà phát triển. Công cụ và kỹ\r\nthuật (ALC_TAT) liên quan đến các công cụ phát triển và tiêu chuẩn triển khai\r\ndo nhà phát triển sử dụng. Sửa lỗi (ALC_FLR) liên quan đến việc xử lý các khiếm\r\nkhuyết về an toàn. Chuyển giao (ALC_DEL) định nghĩa các thủ tục dùng cho chuyển\r\ngiao TOE tới khách hàng. Các quy trình chuyển giao xuất hiện trong phát triển\r\nTOE nặng về nghĩa vận chuyển, chúng được sử dụng trong ngữ cảnh các thủ tục\r\ntích hợp và chấp nhận trong các họ khác của lớp này.
\r\n\r\nTrong toàn bộ lớp này, phát triển và các\r\nthuật ngữ liên quan (nhà phát triển, động từ phát triển) được hiểu với nghĩa\r\nrộng hơn bao gồm phát triển và sản xuất, trong đó sản xuất có nghĩa đặc\r\nbiệt là quy trình chuyển đổi biểu diễn triển khai sang TOE thành phẩm.
\r\n\r\nHình 13 cho thấy các họ trong lớp này, và\r\nphân cấp các thành phần trong các họ.
\r\n\r\n![](\"00907948_files/image013.jpg\")
13.1.1. Mục tiêu
\r\n\r\nQuản lý cấu hình (CM) là cách để tăng thêm\r\ntính đảm bảo về việc TOE thỏa mãn các SFRs. CM tạo ra điều đó bằng cách yêu cầu\r\nnguyên tắc và biện pháp quản lý trong các quy trình cụ thể hóa và sửa đổi TOE\r\nvà thông tin liên quan. Các hệ thống CM được đưa ra nhằm đảm bảo tính toàn vẹn\r\ncho các phần của TOE mà chúng kiểm soát, bằng cách đưa ra phương pháp theo dấu\r\ncác thay đổi và qua việc đảm bảo rằng mọi thay đổi đều được phép.
\r\n\r\nMục tiêu của họ này là yêu cầu hệ thống CM\r\ncủa nhà phát triển có một số năng lực nhất định. Nghĩa là có thể giảm khả năng\r\nxảy ra việc sửa đổi ngẫu nhiên hoặc trái phép các danh mục trong cấu hình. Hệ\r\nthống CM cần đảm bảo tính toàn vẹn của TOE từ khâu thiết kế ban đầu trong suốt\r\nquá trình duy trì hoạt động sau đó.
\r\n\r\nMục tiêu của việc đưa vào các công cụ CM tự\r\nđộng hóa là làm tăng hiệu quả của hệ thống CM. Trong khi các hệ thống CM tự\r\nđộng và thủ công có thể bị vượt qua, bỏ qua hoặc chứng tỏ là không đủ để phòng\r\nchống các sửa đổi trái phép, các hệ thống tự động hóa ít chịu ảnh hưởng hơn bởi\r\nlỗi của con người hoặc những sơ suất.
\r\n\r\nMục đích của họ này bao gồm:
\r\n\r\na) Đảm bảo rằng TOE là chính xác và toàn vẹn\r\ntrước khi được gửi tới khách hàng.
\r\n\r\nb) Đảm bảo không có danh mục cấu hình bị thiếu\r\ntrong quá trình đánh giá.
\r\n\r\nc) Chống lại sự thay đổi, thêm vào, hay xóa\r\ntrái phép các danh mục cấu hình TOE.
\r\n\r\n13.1.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức\r\ntrên cơ sở năng lực hệ thống CM, phạm vi của tài liệu CM và chứng cứ cung cấp\r\nbởi nhà phát triển.
\r\n\r\n13.1.3. Chú thích ứng dụng
\r\n\r\nMặc dù mong muốn CM được áp dụng ngay từ khâu\r\nthiết kế ban đầu và tiếp tục sau đó, họ này đòi hỏi CM cần được đặt ra và sử\r\ndụng trước khi kết thúc đánh giá.
\r\n\r\nTrong trường hợp TOE là một phần nhỏ của sản\r\nphẩm, các yêu cầu của họ này chỉ áp dụng cho danh mục cấu hình TOE mà không cho\r\ntoàn bộ sản phẩm.
\r\n\r\nĐối với nhà phát triển có các hệ thống CM\r\nriêng cho các chu trình vòng đời khác nhau (ví dụ phát triển, sản xuất và/hoặc\r\nsản phẩm cuối), cần văn bản hóa mọi quá trình này. Cho các mục đích đánh giá,\r\ncác hệ thống CM riêng biệt cần được xem như các phần của một hệ thống CM tổng\r\nquát được đề cập trong các tiêu chí.
\r\n\r\nTương tự, nếu các phần của TOE được tạo ra\r\nbởi các nhà phát triển khác nhau ở các nơi khác nhau, các hệ thống CM đang sử\r\ndụng ở các địa điểm khác nhau cần được xem như các phần của một hệ thống CM\r\ntổng quát được đề cập trong các tiêu chí. Trong tình huống này, cần xem xét\r\nthêm các vấn đề tích hợp.
\r\n\r\nMột số phần tử của họ này tham chiếu tới danh\r\nmục cấu hình. Các phần tử này xác định các yêu cầu CM cần được áp đặt vào mọi\r\nmục đã nêu trong danh sách cấu hình, song nội dung cụ thể của danh sách sẽ là\r\nphần việc của nhà phát triển. Phạm vi CM (ALC_CMS) có thể dùng để hạn chế việc\r\ncụ thể hóa này bằng việc xác định ra các mục đặc trưng cần phải có trong danh\r\nsách cấu hình, nghĩa là có trong CM.
\r\n\r\nALC_CMC.2.3C đưa ra một yêu cầu về việc hệ\r\nthống CM định danh thống nhất mọi danh mục cấu hình. Điều này cũng đòi hỏi các\r\nsửa đổi danh mục cấu hình mang lại một định danh mới, duy nhất được gán cho\r\ndanh mục cấu hình.
\r\n\r\nACM_CAP.3.8C đưa ra một yêu cầu là cần có\r\nbằng chứng thể hiện rằng hệ thống CM hoạt động tuân theo kế hoạch CM. Ví dụ các\r\nbằng chứng có thể là tài liệu như là bản chụp màn hình hoặc kết quả vết kiểm\r\ntoán đưa ra từ hệ thống CM, hoặc một công bố chi tiết về hệ thống CM bởi nhà\r\nphát triển. Đánh giá viên có trách nhiệm xác định bằng chứng nào là đủ để chỉ\r\nra rằng hệ thống CM hoạt động tuân theo kế hoạch CM.
\r\n\r\nALC_CMC4.5C đưa ra một yêu cầu là hệ thống CM\r\ncung cấp một phương pháp tự động để hỗ trợ sản phẩm TOE. Điều này đòi hỏi hệ\r\nthống CM cung cấp một phương pháp hỗ trợ việc xác định rằng danh mục cấu hình\r\nchính xác đã được sử dụng để tạo ra TOE.
\r\n\r\nALC_CMC5.10C đưa ra một yêu cầu là hệ thống\r\nCM cung cấp một phương pháp tự động để xác nhận những thay đổi của TOE và phiên\r\nbản trước đó. Nếu không có phiên bản trước đó của TOE, nhà phát triển vẫn cần\r\ncung cấp một phương pháp để xác nhận sự thay đổi của TOE và phiên bản tương\r\nlai.
\r\n\r\n13.1.4. ALC_CMC.1 Gán nhãn TOE
\r\n\r\nCác mối phụ thuộc: ALC_CMS.1 TOE CM Tổng quát
\r\n\r\n13.1.4.1. Mục tiêu
\r\n\r\nMột tham chiếu duy nhất được yêu cầu để đảm\r\nbảo rằng không có sự mơ hồ về trường hợp TOE được đánh giá. Gán nhãn TOE với\r\ntham chiếu đó đảm bảo rằng người sử dụng TOE có thể nhận thức được tình huống\r\nTOE nào thì họ sử dụng.
\r\n\r\n13.1.4.2. Các thành phần hành động nhà phát\r\ntriển
\r\n\r\n13.1.4.2.1. ALC_CMC.1.1D
\r\n\r\nNhà phát triển cần cung cấp TOE và một tham\r\nchiếu đến TOE.
\r\n\r\n13.1.4.3. Các phần tử nội dung và trình bày
\r\n\r\n13.1.4.3.1. ALC_CMC.1.1C
\r\n\r\nTOE cần được gán nhãn bằng tham chiếu duy\r\nnhất của nó.
\r\n\r\n13.1.4.4. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.1.4.4.1. ALC_CMC.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đưa\r\nra thỏa mãn tất cả các yêu cầu về nội dung và thể hiện của chứng cứ.
\r\n\r\n13.1.5. ALC_CMC.2 Sử dụng hệ thống CM
\r\n\r\nCác mối phụ thuộc: ALC_CMS.1 TOE CM Tổng quát
\r\n\r\n13.1.5.1. Mục tiêu
\r\n\r\nMột tham chiếu duy nhất được yêu cầu để đảm\r\nbảo rằng không có sự mơ hồ về bản TOE đang được đánh giá. Gán nhãn TOE với tham\r\nchiếu đó đảm bảo rằng người sử dụng TOE có thể nhận thức được bản TOE nào họ đang\r\nsử dụng.
\r\n\r\nĐịnh danh duy nhất của danh mục cấu hình dẫn\r\nđến việc hiểu rõ ràng về việc tổng hợp TOE, từ đó giúp xác định các mục nào cần\r\nđối với các yêu cầu đánh giá TOE.
\r\n\r\nViệc sử dụng một hệ thống CM làm tăng tính bảo\r\nđảm rằng danh mục cấu hình đang được duy trì có kiểm soát.
\r\n\r\n13.1.5.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.1.5.2.1. ALC_CMC.2.1D
\r\n\r\nNhà phát triển cần cung cấp TOE và một tham\r\nchiếu đến TOE.
\r\n\r\n13.1.5.2.2. ALC_CMC2.2D
\r\n\r\nNhà phát triển cần cung cấp tài liệu CM
\r\n\r\n13.1.5.2.3. ALC_CMC2.3D
\r\n\r\nNhà phát triển cần sử dụng một hệ thống CM
\r\n\r\n13.1.5.3. Các phần tử nội dung và trình bày
\r\n\r\n13.1.5.3.1. ALC_CMC2.1C
\r\n\r\nTOE cần gán nhãn với tham chiếu duy nhất của\r\nnó.
\r\n\r\n13.1.5.3.2. ALC_CMC2.2C
\r\n\r\nTài liệu CM cần miêu tả phương thức sử dụng\r\nđể xác định một cách duy nhất danh mục cấu hình.
\r\n\r\n13.1.5.3.3. ALC_CMC2.3C
\r\n\r\nHệ thống CM cần xác định một cách duy nhất\r\ntất cả các mục cấu hình.
\r\n\r\n13.1.5.4. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.1.5.4.1. ACM_CMC.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược đưa ra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.
\r\n\r\n13.1.6. ALC_CMC.3 Kiểm soát cấp phép
\r\n\r\nCác mối phụ thuộc:
\r\n\r\nALC_CMS.1 TOE CM Tổng quát
\r\n\r\nALC_DVS.1 xác định các biện pháp an toàn
\r\n\r\nALC_LCD.1 mô hình vòng đời xác định bởi nhà\r\nphát triển
\r\n\r\n13.1.6.1. Mục tiêu
\r\n\r\nMột tham chiếu duy nhất được yêu cầu để đảm\r\nbảo rằng không có sự mơ hồ về trường hợp TOE được đánh giá. Gán nhãn TOE với\r\ntham chiếu đó đảm bảo rằng người sử dụng TOE có thể nhận thức được tình huống\r\nTOE nào thì họ sử dụng.
\r\n\r\nSự xác định duy nhất của danh mục cấu hình\r\nhướng dẫn để hiểu rõ hơn cấu trúc TOE, nó giúp xác định danh mục nào là chính\r\nđối với các yêu cầu đánh giá cho TOE.
\r\n\r\nViệc sử dụng một hệ thống CM làm tăng tính\r\nđảm bảo rằng danh mục cấu hình đang được duy trì có kiểm soát.
\r\n\r\nCung cấp kiểm soát để đảm bảo rằng các thay đổi\r\ntrái phép không xảy ra trong TOE (“kiểm soát truy nhập CM”), đảm bảo chức năng\r\nthích hợp và sử dụng của hệ thống CM, giúp để duy trì tính toàn vẹn trong TOE.
\r\n\r\n13.1.6.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.1.6.2.1. ACM_CMC.3.1D
\r\n\r\nNhà phát triển cần cung cấp TOE và một tham\r\nchiếu đến TOE.
\r\n\r\n13.1.6.2.2. ACM_CMC.3.2D
\r\n\r\nNhà phát triển cần cung cấp tài liệu CM
\r\n\r\n13.1.6.2.3. ACM_CMC.3.3D
\r\n\r\nNhà phát triển cần sử dụng hệ thống CM.
\r\n\r\n13.1.6.3. Các phần tử nội dung và trình bày
\r\n\r\n13.1.6.3.1. ACM_CMC.3.1C
\r\n\r\nTOE cần được gán nhãn với tham chiếu duy nhất\r\ncủa nó.
\r\n\r\n13.1.6.3.2. ACM_CMC.3.2C
\r\n\r\nTài liệu CM cần miêu tả phương thức sử dụng\r\nđể xác định một cách duy nhất danh mục cấu hình.
\r\n\r\n13.1.6.3.3. ACM_CMC.3.3C
\r\n\r\nHệ thống CM cần xác định một cách duy nhất\r\ntất cả các mục cấu hình.
\r\n\r\n13.1.6.3.4. ACM_CMC.3.4C
\r\n\r\nHệ thống CM cần cung cấp các biện pháp như\r\nchỉ các thay đổi hợp lệ mới được chấp nhận cho các mục cấu hình.
\r\n\r\n13.1.6.3.5. ACM_CMC.3.5C
\r\n\r\nTài liệu CM cần bao gồm kế hoạch CM.
\r\n\r\n13.1.6.3.6. ACM_CMC.3.6C
\r\n\r\nKế hoạch CM cần mô tả hệ thống CM được dùng\r\nđể phát triển TOE như thế nào.
\r\n\r\n13.1.6.3.7. ACM_CMC.3.7C
\r\n\r\nBằng chứng cần chứng tỏ rằng tất cả các mục\r\ncấu hình đang được duy trì bởi hệ thống CM.
\r\n\r\n13.1.6.3.8. ACM_CMC.3.8C
\r\n\r\nBằng chứng cần chứng tỏ rằng hệ thống CM đang\r\nhoạt động theo kế hoạch CM.
\r\n\r\n13.1.6.4. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.1.6.4.1. ACM_CMC.3.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin\r\nđược đưa ra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.
\r\n\r\n13.1.7. ACM_CMC.4 Hỗ trợ sản xuất và các thủ\r\ntục chấp nhận và tự động hóa
\r\n\r\nCác mối phụ thuộc:
\r\n\r\nALC_CMS.1 TOE CM Tổng quát
\r\n\r\nALC_DVS.1 xác định các biện pháp an toàn
\r\n\r\nALC_LCD.1 mô hình vòng đời xác định bởi nhà\r\nphát triển
\r\n\r\n13.1.7.1. Mục tiêu
\r\n\r\nMột tham chiếu duy nhất được yêu cầu để đảm\r\nbảo rằng không có sự mơ hồ về trường hợp TOE được đánh giá. Gán nhãn TOE với\r\ntham chiếu đó đảm bảo rằng người sử dụng TOE có thể nhận thức được tình huống\r\nTOE nào thì họ sử dụng.
\r\n\r\nSự xác định duy nhất của danh mục cấu hình\r\nhướng dẫn để hiểu rõ hơn cấu trúc TOE, nó giúp xác định danh mục nào là chính\r\nđối với các yêu cầu đánh giá cho TOE.
\r\n\r\nSử dụng hệ thống CM tăng cường đảm bảo rằng\r\ncác danh mục cấu hình được duy trì một cách có kiểm soát.
\r\n\r\nCung cấp kiểm soát để đảm bảo rằng các thay\r\nđổi trái phép không xảy ra trong TOE (“kiểm soát truy nhập CM”), và đảm bảo\r\nchức năng thích hợp và sử dụng của hệ thống CM, giúp để duy trì tính toàn vẹn\r\ntrong TOE.
\r\n\r\nMục đích của các thủ tục chấp nhận là đảm bảo\r\nrằng các phần của TOE có chất lượng phù hợp và khẳng định rằng mọi sự tạo mới\r\nhoặc sửa đổi danh mục cấu hình là được phép. Các thủ tục chấp nhận là một phần\r\ntử quan trọng trong các quy trình tích hợp và trong quản lý vòng đời của TOE.
\r\n\r\nTrong các môi trường phát triển với danh mục\r\ncấu hình phức tạp, rất khó có thể kiểm soát thay đổi mà không có sự hỗ trợ của\r\ncác công cụ tự động hóa. Cụ thể là các công cụ tự động hóa này cần thiết để có\r\nthể hỗ trợ một số lớn các thay đổi xuất hiện trong phát triển và đảm bảo rằng\r\ncác thay đổi đó là được phép. Một mục tiêu của thành phần này là đảm bảo rằng\r\ndanh mục cấu hình được kiểm soát thông qua phương pháp tự động hóa. Nếu TOE\r\nđược phát triển bởi nhiều nhà phát triển, nghĩa là có sự tích hợp, sử dụng công\r\ncụ tự động hóa là điều hợp lý.
\r\n\r\nCác thủ tục hỗ trợ sản xuất giúp đảm bảo rằng\r\nviệc sinh ra TOE từ một tập danh mục cấu hình có kiểm soát được thực hiện chính\r\nxác theo phương thức được phép, cụ thể là trong trường hợp khi có nhiều nhà\r\nphát triển khác nhau liên quan và các quy trình tích hợp khác nhau cần thực\r\nhiện.
\r\n\r\n13.1.7.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.1.7.2.1. ACM_CMC.4.1D
\r\n\r\nNhà phát triển cần cung cấp TOE và một tham\r\nchiếu đến TOE.
\r\n\r\n13.1.7.2.2. ACM_CMC.4.2D
\r\n\r\nNhà phát triển cần cung cấp tài liệu CM.
\r\n\r\n13.1.7.2.3. ACM_CMC.4.3D
\r\n\r\nNhà phát triển cần sử dụng một hệ thống CM.
\r\n\r\n13.1.7.3. Các phần tử nội dung và trình bày
\r\n\r\n13.1.7.3.1. ALC_CMC.4.1C
\r\n\r\nTOE cần được gán nhãn với tham chiếu duy nhất\r\ncủa nó.
\r\n\r\n13.1.7.3.2. ALC_CMC.4.2C
\r\n\r\nTài liệu CM cần miêu tả phương thức sử dụng\r\nđể xác định một cách duy nhất danh mục cấu hình.
\r\n\r\n13.1.7.3.3. ALC_CMC.4.3C
\r\n\r\nHệ thống CM cần xác định một cách duy nhất\r\ntất cả các mục cấu hình.
\r\n\r\n13.1.7.3.4. ALC_CMC.4.4C
\r\n\r\nHệ thống CM cần cung cấp các biện pháp tự\r\nđộng hóa để chỉ các thay đổi hợp lệ mới được chấp nhận đối với các mục cấu\r\nhình.
\r\n\r\n13.1.7.3.5. ALC_CMC.4.5C
\r\n\r\nHệ thống CM cần hỗ trợ sự sản xuất TOE bằng\r\nphương thức tự động.
\r\n\r\n13.1.7.3.6. ALC_CMC.4.6C
\r\n\r\nTài liệu CM cần bao gồm kế hoạch CM.
\r\n\r\n13.1.7.3.7. ALC_CMC.4.7C
\r\n\r\nKế hoạch CM cần mô tả hệ thống CM được dùng\r\nđể phát triển TOE như thế nào.
\r\n\r\n13.1.7.3.8. ALC_CMC.4.8C
\r\n\r\nKế hoạch CM cần mô tả các thủ tục sử dụng để\r\nchấp nhận các thay đổi hoặc các mục cấu hình được tạo mới như là một phần của\r\nTOE.
\r\n\r\n13.1.7.3.9. ALC_CMC.4.9C
\r\n\r\nBằng chứng cần chứng tỏ rằng tất cả các mục\r\ncấu hình đang được duy trì dưới hệ thống CM.
\r\n\r\n13.1.7.3.10. ALC_CMC.4.10C
\r\n\r\nBằng chứng cần chứng tỏ rằng hệ thống CM đang\r\nđược hoạt động phù hợp với kế hoạch CM.
\r\n\r\n13.1.7.4. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.1.7.4.1. ALC_CMC.4.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đưa\r\nra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.
\r\n\r\n13.1.8. ALC_CMC.5 Hỗ trợ cải tiến
\r\n\r\nCác mối phụ thuộc:
\r\n\r\nALC_CMS.1 TOE CM Tổng quát
\r\n\r\nALC_DVS.2 Sự đầy đủ của các biện pháp an toàn
\r\n\r\nALC_LCD.1 mô hình vòng đời xác định bởi nhà\r\nphát triển
\r\n\r\n13.1.8.1. Mục tiêu
\r\n\r\nMột tham chiếu duy nhất được yêu cầu để đảm\r\nbảo rằng không có sự mơ hồ về trường hợp TOE được đánh giá. Gán nhãn TOE với\r\ntham chiếu đó đảm bảo rằng người sử dụng TOE có thể nhận thức được tình huống\r\nTOE nào thì họ sử dụng.
\r\n\r\nSự xác định duy nhất của danh mục cấu hình\r\nhướng dẫn để hiểu rõ hơn cấu trúc TOE, nó giúp xác định danh mục nào là chính\r\nđối với các yêu cầu đánh giá cho TOE.
\r\n\r\nSử dụng hệ thống CM tăng cường đảm bảo rằng\r\ncác danh mục cấu hình được duy trì một cách có kiểm soát.
\r\n\r\nCung cấp kiểm soát để đảm bảo rằng các thay\r\nđổi trái phép không xảy ra trong TOE (“kiểm soát truy nhập CM”), và đảm bảo\r\nchức năng thích hợp và sử dụng của hệ thống CM, giúp để duy trì tính toàn vẹn\r\ntrong TOE.
\r\n\r\nMục đích của các thủ tục chấp nhận là đảm bảo\r\nrằng các phần của TOE, có chất lượng phù hợp và khẳng định rằng mọi sự tạo mới\r\nhoặc sửa đổi danh mục cấu hình là được phép. Các thủ tục chấp nhận là một phần\r\ntử quan trọng trong các quy trình tích hợp và trong quản lý vòng đời của TOE.
\r\n\r\nTrong các môi trường phát triển với danh mục\r\ncấu hình phức tạp, rất khó có thể kiểm soát thay đổi mà không có sự hỗ trợ của\r\ncác công cụ tự động hóa. Cụ thể là các công cụ tự động hóa này cần thiết để có\r\nthể hỗ trợ một số lớn các thay đổi xuất hiện trong phát triển và đảm bảo rằng\r\ncác thay đổi đó là được phép. Một mục tiêu của thành phần này là đảm bảo rằng\r\ndanh mục cấu hình được kiểm soát thông qua phương pháp tự động hóa. Nếu TOE\r\nđược phát triển bởi nhiều nhà phát triển, nghĩa là có sự tích hợp, sử dụng công\r\ncụ tự động hóa là điều hợp lý.
\r\n\r\nCác thủ tục hỗ trợ sản xuất giúp đảm bảo rằng\r\nviệc sinh ra TOE từ một tập danh mục cấu hình có kiểm soát được thực hiện chính\r\nxác theo phương thức được phép, cụ thể là trong trường hợp khi có nhiều nhà\r\nphát triển khác nhau liên quan và các quy trình tích hợp khác nhau cần thực\r\nhiện.
\r\n\r\nYêu cầu là hệ thống CM cần có khả năng xác\r\nđịnh phiên bản biểu diễn triển khai để tạo ra TOE. Điều đó sẽ giúp đảm bảo rằng\r\ntính toàn vẹn của tài liệu này được bảo vệ phù hợp về mặt kỹ thuật, vật lý và\r\nquy trình.
\r\n\r\nCung cấp một phương thức tự động hóa để xác\r\nnhận các thay đổi phiên bản của TOE, xác định ra các mục cấu hình nào bị ảnh\r\nhưởng bởi việc sửa đổi các mục cấu hình khác và hỗ trợ việc xác định ảnh hưởng\r\ncủa thay đổi giữa các phiên bản trước đó của TOE. Từ đó giúp cung cấp thông tin\r\nquý giá để xác định xem các thay đổi TOE mang đến cho mọi danh mục cấu hình có\r\nđang nhất quán với nhau hay không.
\r\n\r\n13.1.8.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.1.8.2.1. ALC_CMC.5.1D
\r\n\r\nNhà phát triển cần cung cấp TOE và một tham\r\nchiếu đến TOE.
\r\n\r\n13.1.8.2.2. ALC_CMC.5.2D
\r\n\r\nNhà phát triển cần cung cấp tài liệu CM.
\r\n\r\n13.1.8.2.3. ALC_CMC.5.3D
Nhà phát triển cần sử dụng một hệ thống CM.
\r\n\r\n13.1.8.3. Các phần tử nội dung và trình bày
\r\n\r\n13.1.8.3.1. ALC_CMC.5.1C
\r\n\r\nTOE cần được gán nhãn với tham chiếu duy nhất\r\ncủa nó.
\r\n\r\n13.1.8.3.2. ALC_CMC.5.2C
\r\n\r\nTài liệu CM cần miêu tả phương thức sử dụng\r\nđể xác định một cách duy nhất danh mục cấu hình.
\r\n\r\n13.1.8.3.3. ALC_CMC.5.3C
\r\n\r\nTài liệu CM cần điều chỉnh để các thủ tục\r\nchấ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\r\ncả các mục cấu hình.
\r\n\r\n13.1.8.3.4. ALC_CMC.5.4C
\r\n\r\nHệ thống CM cần xác định một cách duy nhất\r\ntất cả các mục cấu hình.
\r\n\r\n13.1.8.3.5. ALC_CMC.5.5C
\r\n\r\nHệ thống CM cần cung cấp các biện pháp tự\r\nđộng để chỉ các thay đổi hợp lệ mới được chấp nhận đối với các mục cấu hình.
\r\n\r\n13.1.8.3.6. ALC_CMC.5.6C
\r\n\r\nHệ thống CM cần hỗ trợ sản xuất TOE bằng cách\r\ntự động.
\r\n\r\n13.1.8.3.7. ALC_CMC.5.7C
\r\n\r\nHệ thống CM cần bảo đảm rằng người chịu trách\r\nnhiệm chấp nhận một mục cấu hình vào CM không phải là nhà phát triển nó.
\r\n\r\n13.1.8.3.8. ALC_CMC.5.8C
\r\n\r\nHệ thống CM cần xác thực các mục cấu hình có\r\ntrong TSF.
\r\n\r\n13.1.8.3.9. ALC_CMC.5.9C
\r\n\r\nHệ thống CM cần hỗ trợ kiểm toán tất cả sự\r\nthay đổi TOE theo phương thức tự động hóa, bao gồm người khởi xướng, ngày và\r\nthời gian trong vết kiểm toán.
\r\n\r\n13.1.8.3.10. ALC_CMC.5.10C
\r\n\r\nHệ thống CM cần cung cấp một phương thức tự động\r\nđể xác định mọi mục cấu hình khác bị ảnh hưởng bởi sự thay đổi của một mục cấu\r\nhình đã cho.
\r\n\r\n13.1.8.3.11. ALC_CMC.5.11C
\r\n\r\nHệ thống CM cần có khả năng xác định phiên\r\nbản biểu diễn triển khai tạo ra TOE.
\r\n\r\n13.1.8.3.12. ALC_CMC.5.12C
\r\n\r\nTài liệu CM cần bao gồm kế hoạch CM.
\r\n\r\n13.1.8.3.13. ALC_CMC.5.13C
\r\n\r\nKế hoạch CM cần mô tả hệ thống CM được dùng\r\nđể phát triển TOE như thế nào.
\r\n\r\n13.1.8.3.14. ALC_CMC.5.14C
\r\n\r\nKế hoạch CM cần mô tả các thủ tục sử dụng để\r\nchấp nhận các thay đổi hoặc các mục cấu hình được tạo mới như là một phần của\r\nTOE.
\r\n\r\n13.1.8.3.15. ALC_CMC.5.15C
\r\n\r\nBằng chứng cần chứng tỏ rằng tất cả các mục\r\ncấu hình đang được duy trì dưới hệ thống CM.
\r\n\r\n13.1.8.3.16. ALC_CMC.5.16C
\r\n\r\nBằng chứng cần chứng tỏ rằng hệ thống CM đang\r\nđược hoạt động phù hợp với kế hoạch CM.
\r\n\r\n13.1.8.4. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.1.8.4.1. ALC_CMC.5.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đưa\r\nra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.
\r\n\r\n13.1.8.4.2. ALC_CMC.5.2E
\r\n\r\nĐánh giá viên cần xác định rằng việc áp dụng\r\ncác thủ tục hỗ trợ sản xuất sẽ tạo ra TOE như đã được nhà phát triển đưa ra cho\r\ncác hoạt động kiểm thử.
\r\n\r\n\r\n\r\n13.2.1. Mục tiêu
\r\n\r\nMục tiêu của họ này là xác định các mục cần\r\nđưa vào danh mục cấu hình và vì vậy đưa vào dưới dạng các yêu cầu CM về năng\r\nlực CM (ALC_CMC). Áp dụng quản lý cấu hình cho các mục bổ sung này đưa ra sự\r\nđảm bảo rằng tính toàn vẹn của TOE được duy trì.
\r\n\r\n13.2.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức\r\ntrên cơ sở những gì sau đây được yêu cầu đưa vào danh mục cấu hình: TOE và bằng\r\nchứng đánh giá đòi hỏi bởi các SÁ; các phần của TOE; biểu diễn triển khai; các\r\nlỗi an toàn; các công cụ phát triển và thông tin liên quan.
\r\n\r\n13.2.3. Chú thích ứng dụng
\r\n\r\nMặc dù phạm vi CM (ALC_CMS) đòi hỏi một danh\r\nsách các mục cấu hình và mỗi mục trong danh sách này thuộc CM, năng lực CM\r\n(ALC_CMC) dành phần cụ thể hóa nội dung của danh sách cấu hình cho nhà phát\r\ntriển. Phạm vi CM (ALC_CMS) hạn chế bớt việc cụ thể hóa này bằng việc xác định\r\ncác mục bắt buộc phải có trong danh sách cấu hình, do vậy có trong các yêu cầu\r\nCM về năng lực CM (ALC_CMC).
\r\n\r\n13.2.4. ALC_CMS.1 TOE CM Tổng quát
\r\n\r\nCác mối phụ thuộc: Không có các mối phụ\r\nthuộc.
\r\n\r\n13.2.4.1. Mục tiêu
\r\n\r\nMột hệ thống CM có thể kiểm soát các thay đổi\r\nchỉ với các mục đã đưa vào CM (nghĩa là các mục cấu hình đã xác định trong danh\r\nsách cấu hình). Việc đặt bản thân TOE và bằng chứng đánh giá yêu cầu bởi các SAR\r\nkhác trong ST dưới CM đưa ra sự bảo đảm về việc chúng đã được sửa đổi theo\r\nphương thức có kiểm soát với việc cấp quyền chính xác.
\r\n\r\n13.2.4.2. Chú thích ứng dụng
\r\n\r\nALC_CMS.1.1C đưa ra yêu cầu về việc bản thân\r\nTOE và bằng chứng đánh giá yêu cầu bởi các SAR khác trong ST đã có trong danh\r\nsách cấu hình, và do vậy là chủ thể cho các yêu cầu CM về năng lực CM\r\n(ALC_CMC).
\r\n\r\n13.2.4.3. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.2.4.3.1. ALC_CMS.1.1D
\r\n\r\nNhà phát triển cần cung cấp một danh sách cấu\r\nhình cho TOE.
\r\n\r\n13.2.4.4. Các phần tử nội dung và trình bày
\r\n\r\n13.2.4.1. ALC_CMS.1.1C
\r\n\r\nDanh sách cấu hình cần chứa thông tin sau:\r\nbản thân TOE; bằng chứng đánh giá đòi hỏi bởi các SAR.
\r\n\r\n13.2.4.4.2. ALC_CMS.1.2C
\r\n\r\nDanh sách cấu hình cần xác định duy nhất các\r\nmục cấu hình.
\r\n\r\n13.2.4.5. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.2.4.5.1. ALC_CMS.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đưa\r\nra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.
\r\n\r\n13.2.5. ALC_CMS.2 Các phần của TOE CM tổng\r\nquát
\r\n\r\nCác mối phụ thuộc: Không có các mối phụ\r\nthuộc.
\r\n\r\n13.2.5.1. Mục tiêu
\r\n\r\nMột hệ thống CM có thể kiểm soát các thay đổi\r\nchỉ với các mục đã đưa vào CM (nghĩa là các mục cấu hình đã xác định trong danh\r\nsách cấu hình). Việc đặt bản thân TOE, các thành phần cấu thành TOE, và bằng\r\nchứng đánh giá yêu cầu bởi các SAR dưới CM đưa ra sự bảo đảm về việc chúng đã\r\nđược sửa đổi theo phương thức có kiểm soát với các quyền hợp thức.
\r\n\r\n13.2.5.2. Chú thích ứng dụng
\r\n\r\nALC_CMS.2.1C đưa ra yêu cầu các thành phần\r\ncấu thành TOE (tất cả các phần được chuyển giao cho khách hàng, ví dụ như các\r\nthành phần phần cứng, hoặc các tệp thi hành được) đã được đưa vào danh sách cấu\r\nhình, và do vậy là chủ thể cho các yêu cầu CM về năng lực CM (ALC_CMC).
\r\n\r\nALC_CMS.2.3.C đưa ra yêu cầu về việc danh\r\nsách cấu hình chỉ ra nhà phát triển của mỗi mục cấu hình liên quan đến TSF.\r\nKhái niệm “Nhà phát triển” ở đây không có nghĩa là một người cụ thể mà là một\r\ntổ chức có trách nhiệm phát triển danh mục cấu hình.
\r\n\r\n13.2.5.3. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.2.5.3.1. ALC_CMS.2.1D
\r\n\r\nNhà phát triển cần cung cấp một danh sách cấu\r\nhình cho TOE.
\r\n\r\n13.2.5.4. Các phần tử nội dung và trình bày
\r\n\r\n13.2.5.4.1. ALC_CMS.2.1C
\r\n\r\nDanh sách cấu hình cần chứa thông tin sau:\r\nbản thân TOE; bằng chứng đánh giá đòi hỏi bởi các SAR, tất cả các thành phần\r\ncấu hình TOE.
\r\n\r\n13.2.5.4.2. ALC_CMS.2.2C
\r\n\r\nDanh sách cấu hình cần xác định duy nhất các\r\nmục cấu hình.
\r\n\r\n13.2.5.4.3. ALC_CMS.2.3C
\r\n\r\nĐối với mỗi mục cấu hình liên quan TSF, danh\r\nsách cấu hình cần chỉ ra nhà phát triển của mục đó.
\r\n\r\n13.2.5.5. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.2.5.5.1. ALC_CMS.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đưa\r\nra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.
\r\n\r\n13.2.6. ALC_CMS.3 Biểu diễn triển khai CM\r\ntổng quát
\r\n\r\nCác mối phụ thuộc: Không có các mối phụ thuộc.
\r\n\r\n13.2.6.1. Mục tiêu
\r\n\r\nMột hệ thống CM có thể kiểm soát các thay đổi\r\nchỉ với các mục đã đưa vào CM (nghĩa là các mục cấu hình đã xác định trong danh\r\nsách cấu hình). Việc đặt bản thân TOE, các thành phần cấu thành TOE, biểu\r\ndiễn triển khai TOE và bằng chứng đánh giá yêu cầu bởi các SAR dưới CM đưa\r\nra sự bảo đảm về việc chúng đã được sửa đổi theo phương thức có kiểm soát với\r\ncác quyền hợp thức.
\r\n\r\n13.2.6.2. Chú thích ứng dụng
\r\n\r\nALC_CMS.3.1C đưa ra yêu cầu về việc biểu diễn\r\ntriển khai TOE đã được đưa vào danh sách cấu hình, và do vậy là chủ thể cho các\r\nyêu cầu CM về năng lực CM (ALC_CMC).
\r\n\r\n13.2.6.3. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.2.6.3.1. ALC_CMS.3.1D
\r\n\r\nNhà phát triển cần cung cấp một danh sách cấu\r\nhình cho TOE.
\r\n\r\n13.2.6.4. Các phần tử nội dung và trình bày
\r\n\r\n13.2.6.4.1. ALC_CMS.3.1C
\r\n\r\nDanh sách cấu hình cần chứa thông tin sau:\r\nbản thân TOE; bằng chứng đánh giá đòi hỏi bởi các SAR, tất cả các thành phần\r\ncấu thành TOE; biểu diễn triển khai TOE.
\r\n\r\n13.2.6.4.2. ALC_CMS.3.2C
\r\n\r\nDanh sách cấu hình cần xác định duy nhất các\r\nmục cấu hình.
\r\n\r\n13.2.6.4.3. ALC_CMS.3.3C
\r\n\r\nĐối với mỗi mục cấu hình liên quan TSF, danh\r\nsách cấu hình cần chỉ ra nhà phát triển của mục đó.
\r\n\r\n13.2.6.5. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.2.6.5.1. ALC_CMS.3.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đưa\r\nra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.
\r\n\r\n13.2.7. ALC_CMS.4 Theo dấu vết vấn đề CM tổng\r\nquát
\r\n\r\nCác mối phụ thuộc: Không có các mối phụ\r\nthuộc.
\r\n\r\n13.2.7.1. Mục tiêu
\r\n\r\nMột hệ thống CM có thể kiểm soát các thay đổi\r\nchỉ với các mục đã đưa vào CM (nghĩa là các mục cấu hình đã xác định trong danh\r\nsách cấu hình). Việc đặt bản thân TOE, các thành phần cấu thành TOE, và bằng\r\nchứng đánh giá yêu cầu bởi các SAR dưới CM đưa ra sự bảo đảm về việc chúng đã\r\nđược sửa đổi theo phương thức có kiểm soát với các quyền hợp thức.
\r\n\r\nĐặt các lỗi an toàn dưới CM đảm bảo rằng báo\r\ncáo về lỗi an toàn không bị mất hoặc bỏ quên, cho phép nhà phát triển theo dấu\r\nlỗi an toàn và giải quyết chúng.
\r\n\r\n13.2.7.2. Chú thích ứng dụng
\r\n\r\nALC_CMS.4.1C đưa ra yêu cầu các lỗi an toàn\r\nđược đưa vào danh sách cấu hình, và do vậy là chủ thể cho các yêu cầu CM về\r\nnăng lực CM (ALC_CMC). Điều này đòi hỏi thông tin liên quan đến các lỗi an toàn\r\ntrước đó và việc giải quyết chúng cần được duy trì, cũng như các chi tiết liên\r\nquan đến các lỗi an toàn hiện tại.
\r\n\r\n13.2.7.3. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.2.7.3.1. ALC_CMS.4.1D
\r\n\r\nNhà phát triển cần cung cấp một danh sách cấu\r\nhình cho TOE.
\r\n\r\n13.2.7.4. Các phần tử nội dung và trình bày
\r\n\r\n13.2.7.4.1. ALC_CMS.4.1C
\r\n\r\nDanh sách cấu hình cần chứa thông tin sau:\r\nbản thân TOE; bằng chứng đánh giá đòi hỏi bởi các SAR, tất cả các thành phần\r\ncấu thành TOE, biểu diễn triển khai TOE; các báo cáo lỗi an toàn và trạng\r\nthái giải quyết.
\r\n\r\n13.2.7.4.2. ALC_CMS.4.2C
\r\n\r\nDanh sách cấu hình cần xác định duy nhất các\r\nmục cấu hình.
\r\n\r\n13.2.7.4.3. ALC_CMS.4.3C
\r\n\r\nĐối với mỗi cấu hình liên quan TSF, danh sách\r\ncấu hình cần chỉ ra nhà phát triển của mục đó.
\r\n\r\n13.2.7.5. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.2.7.5.1. ALC_CMS.4.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đưa\r\nra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.
\r\n\r\n13.2.8. ALC_CMS.5 Các công cụ phát triển CM\r\nTổng quát
\r\n\r\nCác mối phụ thuộc: Không có các mối phụ\r\nthuộc.
\r\n\r\n13.2.8.1. Mục tiêu
\r\n\r\nMột hệ thống CM có thể kiểm soát các thay đổi\r\nchỉ với các mục đã đưa vào CM (nghĩa là các mục cấu hình đã xác định trong danh\r\nsách cấu hình). Việc đặt bản thân TOE, các thành phần cấu thành TOE, và bằng\r\nchứng đánh giá yêu cầu bởi các SAR dưới CM đưa ra sự bảo đảm về việc chúng đã\r\nđược sửa đổi theo phương thức có kiểm soát với các quyền hợp thức.
\r\n\r\nĐặt các lỗi an toàn dưới CM đảm bảo rằng báo\r\ncáo về lỗi an toàn không bị mất hoặc bỏ quên, cho phép nhà phát triển theo dấu\r\nlỗi an toàn và giải quyết chúng.
\r\n\r\nCác công cụ phát triển đóng một vai trò quan\r\ntrọng nhằm đảm bảo sản xuất ra một phiên bản TOE chất lượng. Do đó, việc kiểm\r\nsoát các sửa đổi các công cụ này là rất quan trọng.
\r\n\r\n13.2.8.2. Chú thích ứng dụng
\r\n\r\nALC_CMS.5.1C đưa ra yêu cầu về việc các công\r\ncụ phát triển và thông tin liên quan được đưa vào danh sách cấu hình, và do vậy\r\nlà chủ thể cho các yêu cầu CM về năng lực CM (ALC_CMC).
\r\n\r\nVí dụ về các công cụ phát triển là các ngôn\r\nngữ lập trình, các trình biên dịch. Thông tin gắn liền với các mục tạo ra TOE\r\n(như tùy chọn trình biên dịch, tùy chọn tạo phần mềm, tùy chọn tạo tệp thực\r\nthi) là ví dụ về thông tin liên quan đến các công cụ phát triển.
\r\n\r\n13.2.8.3. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.2.8.3.1. ALC_CMS.5.1D
\r\n\r\nNhà phát triển cần cung cấp một danh sách cấu\r\nhình cho TOE.
\r\n\r\n13.2.8.4. Các phần tử nội dung và trình bày
\r\n\r\n13.2.8.4.1. ALC_CMS.5.1C
\r\n\r\nDanh sách cấu hình cần chứa thông tin sau:\r\nbản thân TOE; bằng chứng đánh giá đòi hỏi bởi các SAR, tất cả các thành phần\r\ncấu thành TOE, biểu diễn triển khai TOE; các báo cáo lỗi an toàn và trạng thái\r\ngiải quyết; các công cụ phát triển và thông tin liên quan.
\r\n\r\n13.2.8.4.2. ALC_CMS.5.2C
\r\n\r\nDanh sách cấu hình cần xác định duy nhất các\r\nmục cấu hình.
\r\n\r\n13.2.8.4.3. ALC_CMS.5.3C
\r\n\r\nĐối với mỗi mục cấu hình liên quan TSF, danh\r\nsách cấu hình cần chỉ ra nhà phát triển của mục đó.
\r\n\r\n13.2.8.5. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.2.8.5.1. ALC_CMS.5.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đưa\r\nra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.
\r\n\r\n13.3.1. Mục tiêu
\r\n\r\nMối quan tâm của họ này là truyền một cách an\r\ntoàn TOE đã hoàn thiện từ môi trường phát triển sang trách nhiệm của người\r\ndùng.
\r\n\r\nCác yêu cầu cho chuyển giao đòi hỏi các\r\nphương tiện kiểm soát hệ thống và phân phối, các thủ tục chỉ ra chi tiết các\r\nbiện pháp cần thiết nhằm đưa ra sự bảo đảm rằng an toàn của TOE được duy trì\r\ntrong suốt quá trình phân phối TOE tới người dùng. Cho việc phân phối hợp lệ\r\nTOE, các thủ tục sử dụng cho phân phối TOE xem xét Mục tiêu đã xác định trong\r\nPP/ST liên quan đến an toàn của TOE trong chuyển giao.
\r\n\r\n13.3.2. Phân mức thành phần
\r\n\r\nHọ này chỉ chứa một thành phần. Mức tăng dần\r\ntính bảo vệ được tạo ra qua việc đòi hỏi tính tương xứng của các thủ tục chuyển\r\ngiao với tiềm năng tấn công giả thuyết có trong họ Phân tích điểm yếu\r\n(AVA_VAN).
\r\n\r\n13.3.3. Chú thích ứng dụng
\r\n\r\nViệc vận chuyển từ nhà thầu phụ tới nhà phát\r\ntriển hoặc giữa các điểm phát triển khác nhau không được xem xét ở đây mà ở họ\r\nAn toàn phát triển (ALC_DVS).
\r\n\r\nKết thúc chu trình chuyển giao đánh dấu bởi\r\nviệc vận chuyển TOE tới tay người dùng. Điều này không nhất thiết phải có nghĩa\r\nlà việc TOE đến tận địa điểm người dùng.
\r\n\r\nCác thủ tục chuyển giao cần xem xét, nếu có\r\nthể, các vấn đề sau:
\r\n\r\na) đảm bảo rằng TOE được nhận bởi khách hàng\r\ntương ứng chính xác với phiên bản đã đánh giá của TOE;
\r\n\r\nb) tránh hoặc phát hiện các giả mạo với phiên\r\nbản thực tế của TOE;
\r\n\r\nc) ngăn chặn gửi phiên bản TOE sai;
\r\n\r\nd) tránh phân phối TOE một cách quá lộ liễu\r\ntới khách hàng: có thể xem những trường hợp hạn chế tin tặc biết rõ về việc TOE\r\nđược chuyển giao khi nào và như thế nào;
\r\n\r\ne) tránh hoặc phát hiện việc TOE bị can thiệp\r\ntrong quá trình chuyển giao;
\r\n\r\nf) tránh việc gửi TOE bị trễ hoặc chặn khi\r\nphân phối.
\r\n\r\nCác thủ tục chuyển giao cần đưa ra các hành\r\nđộng của người nhận sẵn sàng đối với các vấn đề trên. Mô tả nhất quán các hành\r\nđộng sẵn sàng nêu trên được kiểm tra trong họ “Các thủ tục chuẩn bị” (AGD_PRE),\r\nnếu có.
\r\n\r\n13.3.4. ALC_DEL.1 Các thủ tục chuyển giao
\r\n\r\nCác mối phụ thuộc: Không có các mối phụ\r\nthuộc.
\r\n\r\n13.3.4.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.3.4.1.1. ALC_DEL.1.1D
\r\n\r\nNhà phát triển cần văn bản hóa các thủ tục\r\nchuyển giao TOE hoặc các thành phần của nó tới người tiêu dùng.
\r\n\r\n13.3.4.1.2. ALC_DEL.2.1D
\r\n\r\nNhà phát triển cần sử dụng các thủ tục chuyển\r\ngiao.
\r\n\r\n13.3.4.2. Các phần tử nội dung và trình bày
\r\n\r\n13.3.4.2.1. ALC_DEL.1.1C
\r\n\r\nTài liệu chuyển giao cần mô tả mọi thủ tục\r\ncầ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\r\ndùng.
\r\n\r\n13.3.4.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.3.4.3.1. ALC_DEL.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đưa\r\nra thỏa mãn tất cả các yêu cầu về nội dung và sự thể hiện bằng chứng.
\r\n\r\n13.4.1. Mục tiêu
\r\n\r\nAn toàn phát triển liên quan đến các biện\r\npháp vật lý, quy trình, nhân sự và các biện pháp an toàn khác có thể dùng trong\r\nmôi trường phát triển nhằm bảo vệ TOE và các thành phần của nó. Nó bao gồm an\r\ntoàn vật lý cho địa điểm phát triển, các quy trình dùng để chọn lựa nhân viên\r\nphát triển.
\r\n\r\n13.4.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức\r\ntrên cơ sở có cần điều chỉnh về việc các biện pháp an toàn đã đầy đủ hay chưa.
\r\n\r\n13.4.3. Chú thích ứng dụng
\r\n\r\nHọ này liên quan đến các biện pháp nhằm loại\r\nbỏ hoặc giảm thiểu nguy cơ tồn tại ở phía nhà phát triển.
\r\n\r\nĐánh giá viên nên tham quan các địa điểm nhằm\r\nđánh giá chứng cứu về an toàn phát triển. Việc này có thể bao gồm các địa điểm\r\ncủa các nhà thầu phụ liên quan đến phát triển và sản xuất TOE. Mọi quyết định\r\nvề việc không đến tham quan cần được phép của cơ quan đánh giá.
\r\n\r\nMặc dù an toàn phát triển liên quan đến việc\r\nduy trì TOE và do vậy đến các yếu tố có thể liên quan sau khi kết thúc đánh\r\ngiá, các yêu cầu An toàn phát triển (ALC_DVS) chỉ đặc trưng rằng các biện pháp\r\nan toàn phát triển đã có ở thời điểm đánh giá. Ngoài ra an toàn phát triển\r\n(ALC_DVS) không chứa bất kỳ yêu cầu nào liên quan đến ý định của nhà tài trợ về\r\nviệc áp dụng các biện pháp an toàn phát triển trong tương lai, sau khi kết thúc\r\nđánh giá.
\r\n\r\nCó thể thấy là tính tin cậy không phải lúc\r\nnào cũng là vấn đề đối với việc bảo vệ TOE trong môi trường phát triển. Việc sử\r\ndụng từ “cần thiết” cho phép chọn lựa sự bảo vệ phù hợp.
\r\n\r\n13.4.4. ALC_DVS.1 Định danh các biện pháp an\r\ntoàn
\r\n\r\nCác mối phụ thuộc: không có sự phụ thuộc nào.
\r\n\r\n13.4.4.1. Phần tử hành động của nhà phát\r\ntriển.
\r\n\r\n13.4.4.1.1. ALC_DVS.1.1D
\r\n\r\nNhà phát triển cần tạo ra tài liệu an toàn\r\nphát triển.
\r\n\r\n13.4.4.2. Các phần tử nội dung và trình bày
\r\n\r\n13.4.4.2.1. ALC_DVS.1.1C
\r\n\r\nTài liệu an toàn phát triển cần mô tả tất cả\r\ncá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\r\nđể bảo vệ tính tin cậy và tính toàn vẹn của thiết kế và thực thi TOE trong môi\r\ntrường phát triển của nó.
\r\n\r\n13.4.4.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.4.4.3.1. ALC_DVS.1.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\nđược cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng cớ.
\r\n\r\n13.4.4.3.2. ALC_DVS.1.2E
\r\n\r\nĐánh giá viên cần khẳng định rằng các biện\r\npháp an toàn đang được áp dụng.
\r\n\r\n13.4.5. ALC_DVS.2 Sự đầy đủ các biện pháp an\r\ntoàn
\r\n\r\nCác mối phụ thuộc: không có sự phụ thuộc nào.
\r\n\r\n13.4.5.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.4.5.1.1. ALC_DVS.2.1D
\r\n\r\nNhà phát triển cần tạo ra tài liệu an toàn\r\nphát triển.
\r\n\r\n13.4.5.2. Các phần tử nội dung và trình bày
\r\n\r\n13.4.5.2.1. ALC_DVS.2.1C
\r\n\r\nTài liệu an toàn phát triển cần mô tả tất cả\r\ncá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 để\r\nbảo vệ tính tin cậy và tính toàn vẹn của thiết kế và thực thi TOE trong môi\r\ntrường phát triển của nó.
\r\n\r\n13.4.5.2.2. ALC_DVS.2.2C
\r\n\r\nTài liệu an toàn phát triển cần biện minh về\r\nviệc các biện pháp an toàn đưa ra mức độ bảo vệ cần thiết nhằm duy trì tính tin\r\ncậy và toàn vẹn cho TOE.
\r\n\r\n13.4.5.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.4.5.3.1. ALC_DVS.2.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\nđược cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng cớ.
\r\n\r\n13.4.5.3.2. ALC_DVS.2.2E
\r\n\r\nĐánh giá viên cần khẳng định rằng các biện\r\npháp an toàn đang được áp dụng.
\r\n\r\n\r\n\r\n13.5.1. Mục tiêu
\r\n\r\nSửa lỗi yêu cầu các lỗi an toàn phát hiện\r\nđược phải do nhà phát triển lần theo dấu vết và sửa chữa. Dù cho sự tương thích\r\ntương lai với các thủ tục sửa lỗi không thể xác định được tại thời điểm đánh\r\ngiá TOE, thì vẫn có thể đánh giá các thủ tục và chính sách mà nhà phát triển\r\nđang có để lần theo dấu vết và sửa lỗi, và để phân loại các chỉnh sửa và thông\r\ntin lỗi.
\r\n\r\n13.5.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức\r\ntrên cơ sở của việc mở rộng phạm vi các thủ tục sửa lỗi và tính chính xác của\r\ncác thủ tục sửa lỗi.
\r\n\r\n13.5.3. Chú thích ứng dụng
\r\n\r\nHọ này đảm bảo rằng TOE được bảo hành và hỗ\r\ntrợ trong tương lai, yêu cầu nhà phát triển TOE lần theo dấu vết và sửa các lỗi\r\ntrong TOE. Hơn nữa, các yêu cầu được kèm theo khi phân loại sửa lỗi. Tuy nhiên,\r\nhọ này không áp đặt các yêu cầu đánh giá ngoài đánh giá hiện tại.
\r\n\r\nNgười sử dụng TOE được coi là tâm điểm của\r\nđơn vị sử dụng mà chịu trách nhiệm nhận và thực hiện chữa các lỗi an toàn. Đó\r\nkhông cần phải là cá nhân người sử dụng, mà có thể là đại diện của tổ chức người\r\nchịu trách nhiệm khắc phục lỗi an toàn. Việc sử dụng thuật ngữ người sử dụng\r\nTOE nhận ra rằng các tổ chức khác nhau có các thủ tục khác nhau trong xử lý báo\r\ncáo lỗi, mà có thể do cá nhân người sử dụng hoặc do một cơ quan quản lý trung\r\ntâm thực hiện.
\r\n\r\nCác thủ tục sửa lỗi cần mô tả các phương pháp\r\nđể xử lý với tất cả các kiểu lỗi gặp phải. Các lỗi này có thể do nhà phát\r\ntriển, do những người sử dụng của TOE, hoặc các bên khác quen thuộc với TOE báo\r\ncáo. Một số lỗi có thể không được sửa ngay lập tức. Có thể có một số trường hợp\r\nmà lỗi không thể xử lý được ngay mà phải thực hiện các biện pháp khác (ví dụ\r\nbiện pháp thủ tục). Những tài liệu ghi lại được đưa ra có thể khôi phục các thủ\r\ntục để cung cấp cho nơi vận hành các xử lý, và cung cấp thông tin về các lỗi mà\r\nviệc xử lý đã hoãn lại (và làm gì trong tạm thời) hoặc khi mà việc sửa chữa là\r\nkhông thể.
\r\n\r\nCác thay đổi đối với TOE sau khi phát hành\r\nđược coi là chưa đánh giá; mặc dù một số thông tin từ bản đánh giá chính thức\r\nvẫn có thể áp dụng. Cụm từ “phát hành TOE” dùng trong họ này do đó tham chiếu\r\nđến một phiên bản của một sản phẩm là phát hành một TOE đã chứng nhận với các\r\nthay đổi đã áp dụng.
\r\n\r\n13.5.4. ALC_FLR.1 Sửa lỗi cơ bản
\r\n\r\nTính Các mối phụ thuộc: không có sự phụ thuộc\r\nnào
\r\n\r\n13.5.4.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.5.4.1.1. ALC_FLR.1.1D
\r\n\r\nNhà phát triển cần văn bản hóa các thủ tục\r\nsửa lỗi chỉ định cho nhà phát triển TOE.
\r\n\r\n13.5.4.2. Các phần tử nội dung và trình bày
\r\n\r\n13.5.4.2.1. ALC_FLR.1.1C
\r\n\r\nTài liệu các thủ tục sửa lỗi cần mô tả các\r\nthủ tục được sử dụng để theo dấu tất cả các lỗi an toàn đã báo cáo trong mỗi\r\nphát hành của TOE.
\r\n\r\n13.5.4.2.2. ALC_FLR.1.2C
\r\n\r\nCác thủ tục sửa lỗi cần yêu cầu việc mô tả\r\nbản chất và ảnh hưởng của từng lỗi an toàn được cung cấp, cũng như hiện trạng\r\ntìm thấy cách sửa lỗi đó.
\r\n\r\n13.5.4.2.3. ALC_FLR.1.3C
\r\n\r\nCác thủ tục sửa lỗi cần yêu cầu các hành động\r\nsửa chữa được xác định cho từng lỗi an toàn.
\r\n\r\n13.5.4.2.4. ALC_FLR.1.4C
\r\n\r\nTài liệu các thủ tục sửa lỗi cần mô tả các\r\nphương pháp sử dụng để cung cấp thông tin, sửa chữa, hướng dẫn về các hành động\r\nsửa lỗi cho người sử dụng TOE.
\r\n\r\n13.5.4.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.5.4.3.1. ALC_FLR.1.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\nđược cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng\r\ncứ.
\r\n\r\n13.5.5. ALC_FLR.2 Các thủ tục báo cáo lỗi
\r\n\r\nTính Các mối phụ thuộc: không có sự phụ thuộc\r\nnào.
\r\n\r\n13.5.5.1. Mục tiêu
\r\n\r\nĐể nhà phát triển có thể hành động phù hợp\r\nvới các báo cáo lỗi an toàn từ những người sử dụng TOE, và để biết ai gửi các\r\nxử lý sửa chữa, người sử dụng TOE cần hiểu cách gửi báo cáo lỗi an toàn tới nhà\r\nphát triển thế nào. Hướng dẫn sửa lỗi từ nhà phát triển tới người sử dụng TOE\r\nđảm bảo rằng những người sử dụng TOE nhận thức được thông tin quan trọng này.
\r\n\r\n13.5.5.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.5.5.2.1. ALC_FLR.2.1D
\r\n\r\nNhà phát triển cần văn bản hóa các thủ tục\r\nsửa lỗi chỉ định cho nhà phát triển TOE.
\r\n\r\n13.5.5.2.2. ALC_FLR.2.2D
\r\n\r\nNhà phát triển cần tạo ra một thủ tục để chấp\r\nnhận và hành động khi có mọi báo cáo lỗi an toàn và các yêu cầu sửa chữa đối\r\nvới các lỗi đó.
\r\n\r\n13.5.5.2.3. ALC_FLR.2.3D
\r\n\r\nNhà phát triển cần cung cấp hướng dẫn sửa lỗi\r\nchỉ định cho người sử dụng TOE
\r\n\r\n13.5.5.3. Các phần tử nội dung và trình bày
\r\n\r\n13.5.5.3.1. ALC_FLR.2.1C
\r\n\r\nTài liệu các thủ tục sửa lỗi cần mô tả các\r\nthủ tục được sử dụng để lần theo dấu vết tất cả các lỗi an toàn đã báo cáo\r\ntrong mỗi phát hành của TOE.
\r\n\r\n13.5.5.3.2. ALC_FLR.2.2C
\r\n\r\nCác thủ tục sửa lỗi cần yêu cầu việc mô tả\r\nbản chất và ảnh hưởng của từng lỗi an toàn được cung cấp, cũng như hiện trạng\r\ntìm thấy cách sửa lỗi đó.
\r\n\r\n13.5.5.3.3. ALC_FLR.2.3C
\r\n\r\nCác thủ tục sửa lỗi cần yêu cầu các hành động\r\nsửa chữa được xác định cho từng lỗi an toàn.
\r\n\r\n13.5.5.3.4. ALC_FLR.2.4C
\r\n\r\nTài liệu các thủ tục sửa lỗi cần mô tả các\r\nphương pháp được sử dụng để cung cấp hướng dẫn, sửa chữa, thông tin lỗi trong\r\ncác hành động sửa lỗi cho người sử dụng TOE.
\r\n\r\n13.5.5.3.5. ALC_FLR.2.5C
\r\n\r\nCác thủ tục sửa lỗi cần mô tả các phương thức\r\nnhà phát triển nhận các báo cáo từ người sử dụng TOE và các yêu cầu về lỗi an\r\ntoàn nghi ngờ trong TOE.
\r\n\r\n13.5.5.3.6. ALC_FLR.2.6C
\r\n\r\nCác thủ tục xử lý các lỗi an toàn đã báo cáo\r\ncần đảm bảo rằng bất cứ lỗi đã báo cáo nào đang được sửa và việc sửa chữa đã\r\nđược báo cho người dùng TOE.
\r\n\r\n13.5.5.3.7. ALC_FLR.2.7C
\r\n\r\nCác thủ tục xử lý lỗi an toàn đã báo cáo cần\r\ncung cấp sự bảo vệ an toàn sao cho bất cứ sửa chữa nào đối với lỗi an toàn này\r\nkhông làm nảy sinh các lỗi nào mới.
\r\n\r\n13.5.5.3.8. ALC_FLR.2.8C
\r\n\r\nHướng dẫn sửa lỗi cần mô tả các phương thức\r\nngười sử dụng TOE báo cáo cho nhà phát triển về bất cứ lỗi an toàn khả nghi nào\r\ntrong TOE.
\r\n\r\n13.5.5.4. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.5.5.4.1. ALC_FLR.2.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\nđược cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng\r\ncớ.
\r\n\r\n13.5.6. ALC_FLR.3 Sửa lỗi hệ thống
\r\n\r\nCác mối phụ thuộc: không có sự phụ thuộc nào.
\r\n\r\n13.5.6.1. Mục tiêu
\r\n\r\nĐể nhà phát triển có thể hành động phù hợp\r\nvới các báo cáo lỗi an toàn từ những người sử dụng TOE, và để biết ai gửi các\r\nxử lý sửa chữa, người sử dụng TOE cần hiểu cách gửi báo cáo lỗi an toàn tới nhà\r\nphát triển thế nào. Hướng dẫn sửa lỗi từ nhà phát triển tới người sử dụng TOE\r\nđảm bảo rằng những người sử dụng TOE nhận thức được thông tin quan trọng này.
\r\n\r\n13.5.6.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.5.6.2.1. ALC_FLR.3.1D
\r\n\r\nNhà phát triển cần văn bản hóa các thủ tục\r\nsửa lỗi chỉ định cho nhà phát triển TOE.
\r\n\r\n13.5.6.2.2. ALC_FLR.3.2D
\r\n\r\nNhà phát triển cần tạo ra một thủ tục để chấp\r\nnhận và hành động khi có mọi báo cáo lỗi an toàn và các yêu cầu sửa chữa đối\r\nvới các lỗi đó.
\r\n\r\n13.5.6.2.3. ALC_FLR.3.3D
\r\n\r\nNhà phát triển cần cung cấp hướng dẫn sửa lỗi\r\nchỉ định cho người sử dụng TOE
\r\n\r\n13.5.6.3. Các phần tử nội dung và trình bày
\r\n\r\n13.5.6.3.1. ALC_FLR.3.1C
\r\n\r\nTài liệu các thủ tục sửa lỗi cần mô tả các\r\nthủ tục được sử dụng để lần theo dấu vết tất cả các lỗi an toàn đã báo cáo\r\ntrong mỗi phát hành của TOE.
\r\n\r\n13.5.6.3.2. ALC_FLR.3.2C
\r\n\r\nCác thủ tục sửa lỗi cần yêu cầu việc mô tả\r\nbản chất và ảnh hưởng của từng lỗi an toàn được cung cấp, cũng như hiện trạng\r\ntìm thấy cách sửa lỗi đó.
\r\n\r\n13.5.6.3.3. ALC_FLR.3.3C
\r\n\r\nCác thủ tục sửa lỗi cần yêu cầu các hành động\r\nsửa chữa được xác định cho từng lỗi an toàn.
\r\n\r\n13.5.6.3.4. ALC_FLR.3.4C
\r\n\r\nTài liệu các thủ tục sửa lỗi cần mô tả các\r\nphương pháp được sử dụng để cung cấp hướng dẫn, sửa chữa, thông tin lỗi trong\r\ncác hành động sửa lỗi cho người sử dụng TOE.
\r\n\r\n13.5.6.3.5. ALC_FLR.3.5C
\r\n\r\nCác thủ tục sửa lỗi cần mô tả các phương thức\r\nnhà phát triển nhận các báo cáo từ người sử dụng TOE và các yêu cầu về lỗi an\r\ntoàn nghi ngờ trong TOE.
\r\n\r\n13.5.6.3.6. ALC_FLR.3.6C
\r\n\r\nCác thủ tục xử lý các lỗi an toàn đã báo cáo\r\ncần gồm một thủ tục yêu cầu phản hồi kịp thời và phân phối tự động các báo cáo\r\nlỗi an toàn cũng như các sửa đổi liên quan tới người dùng đã đăng ký đã có thể\r\nchịu ảnh hưởng của lỗi an toàn.
\r\n\r\n13.5.6.3.7. ALC_FLR.3.7C
\r\n\r\nCác thủ tục xử lý các lỗi an toàn đã báo cáo\r\ncần đảm bảo rằng bất cứ lỗi đã báo cáo nào đang được sửa và việc sửa chữa đã\r\nđược báo cho người dùng TOE.
\r\n\r\n13.5.6.3.8. ALC_FLR.3.8C
\r\n\r\nCác thủ tục xử lý lỗi an toàn đã báo cáo cần\r\ncung cấp sự bảo vệ an toàn cho bất cứ sửa chữa nào đối với lỗi an toàn này\r\nkhông làm nảy sinh các lỗi nào mới.
\r\n\r\n13.5.6.3.9. ALC_FLR.3.9C
\r\n\r\nHướng dẫn sửa lỗi cần mô tả các phương thức\r\nngười sử dụng TOE báo cáo cho nhà phát triển về bất cứ lỗi an toàn khả nghi nào\r\ntrong TOE.
\r\n\r\n13.5.6.3.10. ALC_FLR.3.10C
\r\n\r\nHướng dẫn sửa lỗi cần mô tả phương thức người\r\ndùng TOE có thể đăng ký với nhà phát triển nhằm có thể nhận được các báo cáo và\r\nsửa chữa lỗi an toàn một cách hợp thức.
\r\n\r\n13.5.6.3.11. ALC_FLR.3.11C
\r\n\r\nHướng dẫn sửa lỗi cần xác định các đầu mối\r\nliên lạc cụ thể cho tất cả các báo cáo và yêu cầu về các vấn đề an toàn liên\r\nquan đến TOE.
\r\n\r\n13.5.6.4. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.5.6.4.1. ALC_FLR.3.1E
\r\n\r\nĐánh giá viên sẽ khẳng định rằng thông tin\r\nđược cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng\r\ncớ.
\r\n\r\n13.6.1. Mục tiêu
\r\n\r\nViệc phát triển và duy trì TOE với kiểm soát\r\nnghèo nàn có thể mang lại một TOE không đáp ứng được tất cả các yêu cầu an toàn\r\nSFRs của nó. Do đó, điều quan trọng là cần tạo ra một mô hình cho phát triển và\r\nduy trì TOE càng sớm càng tốt trong vòng đời của TOE.
\r\n\r\nSử dụng một mô hình cho việc phát triển và\r\nduy trì TOE không bảo đảm rằng TOE đáp ứng được tất cả các yêu cầu chức năng an\r\ntoàn SFRs của nó. Có thể là một mô hình được chọn sẽ thiếu hoặc không thỏa đáng\r\nvà do đó sẽ không thấy lợi ích về chất lượng của TOE. Việc sử dụng một mô hình\r\nvòng đời đã được một số nhóm các chuyên gia phê duyệt (ví dụ các chuyên gia hàn\r\nlâm, các cơ quan định chuẩn) làm tăng cơ hội cho các mô hình phát triển và duy\r\ntrì nhằm làm cho TOE đáp ứng các SFRs của nó. Sử dụng một mô hình vòng đời bao\r\nhàm một số định lượng sẽ làm tăng tính đảm bảo về chất lượng chung của quy\r\ntrình phát triển TOE.
\r\n\r\n13.6.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức\r\ntrên cơ sở các yêu cầu tăng dần về định lượng của mô hình vòng đời, và việc\r\ntương thích với mô hình đó.
\r\n\r\n13.6.3. Chú thích ứng dụng
\r\n\r\nMột mô hình vòng đời chứa đựng các thủ tục,\r\ncông cụ và kỹ thuật được sử dụng để phát triển và duy trì TOE. Các khía cạnh\r\ncủa quá trình có thể được bao hàm bởi một mô hình như vậy gồm các phương pháp\r\nthiết kế, các thủ tục soát xét, các biện pháp quản lý dự án, các thủ tục kiểm\r\nsoát thay đổi, các phương pháp kiểm thử và các thủ tục chấp nhận. Một mô hình\r\nvòng đời hiệu quả sẽ chỉ ra những khía cạnh này của quá trình phát triển và duy\r\ntrì này trong một cấu trúc quản lý tổng thể chỉ định trách nhiệm và qui trình\r\ngiám sát.
\r\n\r\nCó nhiều kiểu tình huống chấp thuận khác nhau\r\nliên quan đến các vị trí khác nhau trong tiêu chí: chấp thuận các thành phần\r\nchuyển giao từ các nhà thầu phụ (“tích hợp”) nên được xem trong họ Định nghĩa\r\nvòng đời (ALC_LCD) này, chấp thuận liên quan đến vận chuyển nội bộ trong An\r\ntoàn phát triển (ALC_DVS), chấp thuận các thành phần vào hệ thống CM trong năng\r\nlực CM (ALC_CMC), chấp thuận của người tiêu dùng với TOE đã chuyển giao trong\r\nhọ Chuyển giao (ALC_DEL). Ba kiểu đầu tiên có thể giao nhau.
\r\n\r\nMặc dù định nghĩa vòng đời liên quan đến duy\r\ntrì TOE và do đó các khía cạnh trở lên thích hợp sau khi hoàn tất việc đánh\r\ngiá, việc đánh giá nó bổ sung thêm sự đảm bảo thông qua phân tích thông tin\r\nvòng đời cho TOE được cung cấp tại thời điểm đánh giá.
\r\n\r\nMột mô hình vòng đời cung cấp biện pháp quản\r\nlý cần thiết trong phát triển và duy trì TOE, nếu mô hình cho phép tối thiểu\r\nhóa vừa đủ nguy cơ TOE không đáp ứng yêu cầu an toàn của nó.
\r\n\r\nMột mô hình vòng đời là mô hình dùng một số\r\ngiá trị định lượng (tham số số học và/hoặc số đo) cho sản phẩm được quản lý\r\nnhằm đo lường các đặc điểm phát triển sản phẩm. Các số đo điển hình là số đo độ\r\nphức tạp của mã nguồn, mật độ lỗi (số lỗi trên kích thước mã nguồn) hoặc thời\r\ngian lỗi trung bình. Đối với đánh giá an toàn, mọi số đo trên đều phù hợp,\r\nchúng được sử dụng để tăng chất lượng bằng cách giảm xác suất lỗi, do đó tăng\r\ntính bảo đảm an toàn cho TOE.
\r\n\r\nCần lưu ý một điều là sẵn có các mô hình vòng\r\nđời tiêu chuẩn (ví dụ mô hình thác nước), mặt khác cũng có các đại lượng đo\r\ntiêu chuẩn (ví dụ mật độ lỗi) và chúng có thể kết hợp với nhau. TCVN 8709 không\r\nyêu cầu vòng đời phải tuân theo chính xác một tiêu chuẩn phản ánh cả hai khía\r\ncạnh trên.
\r\n\r\n13.6.4. ALC-LCD.1 Mô hình vòng đời định nghĩa\r\nbởi nhà phát triển
\r\n\r\nCác mối phụ thuộc: không có sự phụ thuộc nào
\r\n\r\n13.6.4.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.6.4.1.1. ALC_LCD.1.1D
\r\n\r\nNhà phát triển cần tạo ra mô hình vòng đời\r\nđược sử dụng trong phát triển và duy trì của TOE.
\r\n\r\n13.6.4.1.2. ALC_LCD.1.2D
\r\n\r\nNhà phát triển cần cung cấp tài liệu định\r\nnghĩa vòng đời.
\r\n\r\n13.6.4.2. Các phần tử nội dung và trình bày
\r\n\r\n13.6.4.2.1. ALC_LCD.1.1C
\r\n\r\nTài liệu định nghĩa vòng đời cần mô tả mô\r\nhình được sử dụng để phát triển và duy trì TOE.
\r\n\r\n13.6.4.2.2. ALC_LCD.1.2C
\r\n\r\nMô hình vòng đời cần cung cấp kiểm soát cần\r\nthiết cho việc phát triển và duy trì TOE.
\r\n\r\n13.6.4.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.6.4.3.1. ALC_LCD.1.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\nđược cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng\r\ncớ.
\r\n\r\n13.6.5. ALC_LCD.2 Mô hình vòng đời định lượng
\r\n\r\nTính Các mối phụ thuộc: không có sự phụ thuộc\r\nnào
\r\n\r\n13.6.5.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.6.5.1.1. ALC_LCD.2.1D
\r\n\r\nNhà phát triển cần tạo ra mô hình vòng đời\r\nđược sử dụng trong phát triển và duy trì của TOE, và nó được dựa trên một mô\r\nhình vòng đời định lượng.
\r\n\r\n13.6.5.1.2. ALC_LCD.2.2D
\r\n\r\nNhà phát triển cần cung cấp tài liệu định\r\nnghĩa vòng đời.
\r\n\r\n13.6.5.1.3. ALC_LCD.2.3D
\r\n\r\nNhà phát triển cần đo lường việc phát triển\r\nTOE sử dụng một mô hình vòng đời định lượng.
\r\n\r\n13.6.5.2. Nội dung và trình bày của phần tử\r\nchứng cớ
\r\n\r\n13.6.5.2.1. ALC_LCD.2.1C
\r\n\r\nTài liệu định nghĩa vòng đời cần mô tả mô hình\r\nđược sử dụng để phát triển và duy trì TOE, bao gồm các chi tiết về tham số số\r\nhọc của nó và/hoặc các số đo dùng để đo lường chất lượng TOE và/hoặc việc phát\r\ntriển nó.
\r\n\r\n13.6.5.2.2. ALC_LCD.2.2C
\r\n\r\nMô hình vòng đời cần cung cấp kiểm soát cần\r\nthiết cho việc phát triển và duy trì TOE.
\r\n\r\n13.6.5.2.3. ALC_LCD.2.3C
\r\n\r\nTài liệu đầu ra của vòng đời cần đưa ra kết\r\nquả về các phép đo sự phát triển TOE với mô hình vòng đời định lượng.
\r\n\r\n13.6.5.3. Phần tử hành động đánh giá viên
\r\n\r\n13.6.5.3.1. ALC_LCD.2.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\nđược cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng cớ.
\r\n\r\n13.7.1. Mục tiêu
\r\n\r\nCác công cụ và kỹ thuật là một khía cạnh chọn\r\nlựa công cụ được sử dụng để phát triển, phân tích và triển khai TOE. Nó bao gồm\r\ncác yêu cầu tránh các công cụ phát triển không đúng, mâu thuẫn, mập mờ khi sử\r\ndụng phát triển TOE. Điều này bao gồm, nhưng không giới hạn, cả các ngôn ngữ\r\nlập trình, tài liệu, các chuẩn triển khai, các thành phần khác của TOE ví như\r\nlà hỗ trợ thư viện thời gian thực.
\r\n\r\n13.7.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức\r\ntrên cơ sở các yêu cầu tăng dẫn về mô tả và phạm vi của các tiêu chuẩn triển\r\nkhai và tài liệu về các tùy chọn phụ thuộc triển khai.
\r\n\r\n13.7.3. Chú thích ứng dụng
\r\n\r\nCó một yêu cầu đối với các công cụ phát triển\r\nđược xác định rõ. Đó là các công cụ được mô tả rõ ràng và đầy đủ. Ví dụ, các\r\nngôn ngữ lập trình và các hệ thống thiết kế có trợ giúp của máy tính (CAD)\r\nchúng đều dựa trên một tiêu chuẩn đã công bố bởi các cơ quan tiêu chuẩn và được\r\nxem là xác định rõ. Các công cụ tự làm cần được xem xét thêm nhằm làm rõ chúng\r\ncó thuộc loại xác định rõ hay không.
\r\n\r\nYêu cầu trong ALC_TAT.1.2C được áp dụng đặc\r\nbiệt cho các ngôn ngữ lập trình để đảm bảo rằng tất cả các tuyên bố trong mã\r\nnguồn đều có một nghĩa rõ ràng.
\r\n\r\nTrong ALC_TAT.2 và ALC_TAT.3, các hướng dẫn\r\ntriển khai có thể được chấp nhận làm tiêu chuẩn triển khai nếu như chúng được\r\nphê chuẩn bởi một số nhóm chuyên gia (ví dụ chuyên gia khoa học, các cơ quan\r\ntiêu chuẩn). Các tiêu chuẩn triển khai thường công khai, được chấp thuận rộng\r\nrãi và thực hành chung trong một lĩnh vực đặc trưng, tuy nhiên các hướng dẫn\r\ntriển khai đặc trưng của nhà phát triển cũng có thể được chấp nhận làm tiêu\r\nchuẩn; quan trọng là ý kiến chuyên gia.
\r\n\r\nCác công cụ và kỹ thuật phân biệt giữa các\r\ntiêu chuẩn triển khai áp dụng bởi nhà phát triển (ALC_TAT.2.3D) và các tiêu\r\nchuẩn triển khai cho “mọi thành phần TOE” (ALC_TAT.3.3D) trong đó bao gồm phần\r\nmềm, phần cứng hoặc phần sụn của bên thứ ba. Danh sách cấu hình có trong phạm\r\nvi CM (ALC_CMS) đòi hỏi rằng mỗi mục cấu hình tương ứng TSF biểu thị việc nó\r\nđược tạo ra bởi nhà phát triển TOE hay nhà phát triển bên thứ ba.
\r\n\r\n13.7.4. ALC_TAT.1 Các công cụ phát triển được\r\nđịnh nghĩa rõ ràng.
\r\n\r\nCác mối phụ thuộc: ADV_IMP.1 Biểu diễn triển\r\nkhai của TSF
\r\n\r\n13.7.4.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.7.4.1.1. ALC_TAT.1.1D
\r\n\r\nNhà phát triển cần xác định mọi công cụ phát\r\ntriển được sử dụng cho TOE
\r\n\r\n13.7.4.1.2. ALC_TAT.1.2D
\r\n\r\nNhà phát triển cần văn bản hóa các tùy chọn\r\nphụ thuộc triển khai đã được lựa chọn cho mỗi công cụ phát triển.
\r\n\r\n13.7.4.2. Các phần tử nội dung và trình bày
\r\n\r\n13.7.4.2.1. ALC_TAT.1.1C
\r\n\r\nMọi công cụ phát triển sử dụng cho triển khai\r\ncần xác định rõ ràng.
\r\n\r\n13.7.4.2.2. ALC_TAT.1.2C
\r\n\r\nTài liệu cho mỗi công cụ phát triển cần định\r\nnghĩa rõ ràng ý nghĩa của tất cả các tuyên bố cũng như các quy ước và các chỉ\r\ndẫn sử dụng trong triển khai.
\r\n\r\n13.7.4.2.3. ALC_TAT.1.3C
\r\n\r\nTài liệu cho mỗi công cụ phát triển cần định\r\nnghĩa rõ ràng ý nghĩa của tất cả các tùy chọn phụ thuộc triển khai.
\r\n\r\n13.7.4.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.7.4.3.1. ALC_TAT.1.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\nđược cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng cớ.
\r\n\r\n13.7.5. ALC_TAT.2 Tương thích với các tiêu\r\nchuẩn triển khai
\r\n\r\nCác mối phụ thuộc: ADV_IMP.1 Biểu diễn triển\r\nkhai của TSF
\r\n\r\n13.7.5.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.7.5.1.1. ALC_TAT.2.1D
\r\n\r\nNhà phát triển cần xác định mọi công cụ phát\r\ntriển sử dụng cho TOE
\r\n\r\n13.7.5.1.2. ALC_TAT.2.2D
\r\n\r\nNhà phát triển cần văn bản hóa các tùy chọn\r\nphụ thuộc triển khai đã được lựa chọn cho mỗi công cụ phát triển.
\r\n\r\n13.7.5.1.3. ALC_TAT.2.3D
\r\n\r\nNhà phát triển cần mô tả các tiêu chuẩn triển\r\nkhai đang được nhà phát triển áp dụng.
\r\n\r\n13.7.5.2. Các phần tử nội dung và trình bày
\r\n\r\n13.7.5.2.1. ALC_TAT.2.1C
\r\n\r\nMọi công cụ phát triển sử dụng cho triển khai\r\ncần xác định rõ ràng.
\r\n\r\n13.7.5.2.2. ALC_TAT.2.2C
\r\n\r\nTài liệu cho mỗi công cụ phát triển cần định\r\nnghĩa rõ ràng ý nghĩa của tất cả các tuyên bố cũng như các quy ước và các chỉ\r\ndẫn sử dụng trong triển khai.
\r\n\r\n13.7.5.2.3. ALC_TAT.2.3C
\r\n\r\nTài liệu cho mỗi công cụ phát triển cần định\r\nnghĩa rõ ràng ý nghĩa của tất cả các tùy chọn phụ thuộc triển khai.
\r\n\r\n13.7.5.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.7.5.3.1. ALC_TAT.2.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\nđược cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng cớ.
\r\n\r\n13.7.5.3.2. ALC_TAT.2.2E
\r\n\r\nĐánh giá viên cần khẳng định rằng các tiêu\r\nchuẩn triển khai đã được áp dụng.
\r\n\r\n13.7.6. ALC_TAT.3 Tương thích với tiêu chuẩn\r\ntriển khai - tất cả các thành phần.
\r\n\r\nTính phụ thuộc: ADV_IMP.1 Biểu diễn triển\r\nkhai của TSF
\r\n\r\n13.7.6.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n13.7.6.1.1. ALC_TAT.3.1D
\r\n\r\nNhà phát triển cần xác định mọi công cụ phát\r\ntriển sử dụng cho TOE
\r\n\r\n13.7.6.1.2. ALC_TAT.3.2D
\r\n\r\nNhà phát triển cần văn bản hóa các tùy chọn\r\nphụ thuộc triển khai đã được lựa chọn cho mỗi công cụ phát triển.
\r\n\r\n13.7.6.1.3. ALC_TAT.3.3D
\r\n\r\nNhà phát triển cần mô tả các tiêu chuẩn triển\r\nkhai đang được nhà phát triển áp dụng và đang được áp dụng bởi mọi nhà cung\r\ncấp thứ ba cho mọi thành phần của TOE.
\r\n\r\n13.7.6.2. Các phần tử nội dung và trình bày
\r\n\r\n13.7.6.2.1. ALC_TAT.3.1C
\r\n\r\nMọi công cụ phát triển sử dụng cho triển khai\r\ncần xác định rõ ràng.
\r\n\r\n13.7.6.2.2. ALC_TAT.3.2C
\r\n\r\nTài liệu cho mỗi công cụ phát triển cần định\r\nnghĩa rõ ràng ý nghĩa của tất cả các tuyên bố cũng như các quy ước và các chỉ\r\ndẫn sử dụng trong triển khai.
\r\n\r\n13.7.6.2.3. ALC_TAT.3.3C
\r\n\r\nTài liệu cho mỗi công cụ phát triển cần định\r\nnghĩa rõ ràng ý nghĩa của tất cả các tùy chọn phụ thuộc triển khai.
\r\n\r\n13.7.6.3. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n13.7.6.3.1. ALC_TAT.3.1E
\r\n\r\nĐánh giá viên cần khẳng định rằng thông tin\r\nđược cung cấp đáp ứng được tất cả các yêu cầu về nội dung và trình bày chứng cớ.
\r\n\r\n13.7.6.3.2. ALC_TAT.3.2E
\r\n\r\nĐánh giá viên cần khẳng định rằng các tiêu\r\nchuẩn triển khai đã được áp dụng.
\r\n\r\n\r\n\r\nLớp “Các kiểm thử” bao gồm 4 họ chính: Tổng\r\nquát (ATE_COV), Chuyên sâu (ATE_DPT), Kiểm thử độc lập (ATE_IND) (ví dụ kiểm\r\nthử chức năng bởi đánh giá viên) và Kiểm thử chức năng (ATE_FUN). Việc kiểm thử\r\nnhằm đảm bảo rằng TSF vận hành như đã mô tả (trong đặc tả chức năng, thiết kế\r\nTOE, và triển khai mẫu).
\r\n\r\nĐiểm nhấn trong lớp này là khẳng định rằng\r\nTSF hoạt động theo như các mô tả thiết kế của nó. Lớp này không đề cập đến kiểm\r\nthử thâm nhập dựa trên việc phân tích TSF theo các tìm kiếm đặc trưng nhằm xác\r\nđịnh các điểm yếu trong thiết kế và thực thi TSF. Kiểm thử thâm nhập được đề\r\ncập riêng trong mục đánh giá điểm yếu ở lớp AVA: đánh giá điểm yếu.
\r\n\r\nATE: Lớp các kiểm thử phân chia việc kiểm thử\r\nthành các kiểm thử bởi nhà phát triển và các kiểm thử bởi đánh giá viên. Nhóm\r\ntổng quát (ATE_COV) và Chuyên sâu (ATE_DPT) đề cập đến tính đầy đủ của các kiểm\r\nthử bởi nhà phát triển. Tổng quát (ATE_COV) đề cập đến tính chặt chẽ cùng với\r\nđặc tả chức năng đã được kiểm thử; Chuyên sâu (ATE_DPT) đề cập đến việc có nên\r\nkiểm thử căn cứ vào các mô tả thiết kế khác (kiến trúc an toàn, thiết kế TOE,\r\ntriển khai mẫu) đã được yêu cầu hay không.
\r\n\r\nCác kiểm thử chức năng đề cập đến việc thực\r\nhiện các kiểm thử bởi nhà phát triển và cách thức ghi lại bằng văn bản cho kiểm\r\nthử này như thế nào. Cuối cùng, kiểm thử độc lập (ATE_IND) đề cập đến việc kiểm\r\nthử bởi đánh giá viên: đánh giá viên nên lặp lại từng phần việc hoặc toàn bộ\r\nquá trình kiểm thử bởi nhà phát triển và bao nhiêu phép thử độc lập nên thực\r\nhiện.
\r\n\r\nHình 14 trình bày các họ thuộc lớp này, và\r\nphân lớp các thành phần bên trong các họ.
\r\n\r\n![](\"00907948_files/image014.jpg\")
14.1.1. Mục tiêu
\r\n\r\nHọ này xác minh rằng TSF đã được kiểm thử\r\ntheo đặc tả chức năng của nó. Điều này đạt được thông qua việc kiểm tra chứng\r\ncứ tương ứng của nhà phát triển.
\r\n\r\n14.1.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức dựa\r\nvào đặc tả.
\r\n\r\n14.1.3. Chú thích ứng dụng
\r\n\r\n14.1.4. ATE_COV.1 Chứng cứ tổng quát
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_FSP.2 Đặc tả chức năng thực thi an toàn
\r\n\r\nATE_FUN.1 Kiểm thử chức năng
\r\n\r\n14.1.4.1. Mục tiêu
\r\n\r\nMục tiêu của thành phần này là việc một số\r\ncác TSFI đã được kiểm thử.
\r\n\r\n14.1.4.2. Chú thích ứng dụng
\r\n\r\nTrong thành phần này nhà phát triển chỉ ra\r\ncác kiểm thử trong tài liệu kiểm thử tương ứng với các TSFI trong đặc tả chức\r\nnăng như thế nào. Điều này có thể đạt được với một khai báo tương hợp, có thể\r\nsử dụng một bảng.
\r\n\r\n14.1.4.3. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n14.1.4.3.1. ATE_COV.1.1D
\r\n\r\nNhà phát triển cần đưa ra được chứng cứ của\r\ntổng quan kiểm thử.
\r\n\r\n14.1.4.4. Các phần tử nội dung và trình bày
\r\n\r\n14.1.4.4.1. ATE_COV.1.1C
\r\n\r\nChứng cứ của tổng quan kiểm thử cần chỉ ra sự\r\ntương ứng giữa các kiểm thử trong tài liệu kiểm thử và các TSFI trong đặc tả\r\nchức năng.
\r\n\r\n14.1.4.5. Các phần tử hành động của đánh giá\r\nviên
\r\n\r\n14.1.4.5.1. ATE_COV.1.1E
\r\n\r\nĐánh giá viên sẽ xác nhận rằng thông tin đưa\r\nra đáp ứng tất cả các yêu cầu về nội dung và biểu thị của chứng cứ.
\r\n\r\n14.1.5. ATE_COV.2. Phân tích tổng quát
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_FSP.2 Đặc tả chức năng thực thi an toàn
\r\n\r\nADV_FUN.1 Kiểm thử chức năng
\r\n\r\n14.1.5.1. Mục tiêu
\r\n\r\nMục tiêu của thành phần này là xác nhận rằng\r\ntất cả các TSFI đã được kiểm thử.
\r\n\r\n14.1.5.2. Chú thích ứng dụng
\r\n\r\nTrong thành phần này, nhà phát triển xác nhận\r\nrằng các kiểm thử trong tài liệu kiểm thử tương ứng với tất cả các TSFI trong\r\nđặc tả chức năng. Điều này có thể đạt được được qua một khai báo tương ứng, có\r\nthể sử dụng một bảng, tuy nhiên nhà phát triển cũng đưa ra bản phân tích tổng\r\nquan kiểm thử.
\r\n\r\n14.1.5.3. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n14.1.5.3.1. ATE_COV.2.1D
\r\n\r\nNhà phát triển cần cung cấp bản phân tích tổng\r\nquan kiểm thử.
\r\n\r\n14.1.5.4. Các phần tử nội dung và trình bày
\r\n\r\n14.1.5.4.1. ATE_COV.2.1C
\r\n\r\nBản phân tích tổng quan kiểm thử cần chỉ\r\nra sự tương ứng giữa các kiểm thử trong tài liệu kiểm thử và các TSFI trong\r\nđặc tả chức năng.
\r\n\r\n14.1.5.4.2. ATE_COV.2.2C
\r\n\r\nBản phân tích tổng quan kiểm thử cần minh\r\nchứng rằng tất cả các TSFI trong đặc tả chức năng đã được kiểm thử.
\r\n\r\n14.1.5.5. Phần tử hành động của đánh giá viên
\r\n\r\n14.1.5.5.1. ATE_COV.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin có\r\nđược đã đạt tất cả các yêu cầu về nội dung và hình thức của chứng cứ.
\r\n\r\n14.1.6. ATE_COV.3. Phân tích tổng quát chặt\r\nchẽ
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_FSP.2 Đặc tả chức năng thực thi an toàn
\r\n\r\nADV_FUN.1 Kiểm thử chức năng
\r\n\r\n14.1.6.1. Mục tiêu
\r\n\r\nTrong phần này, mục tiêu là xác nhận rằng nhà\r\nphát triển sản phẩm đã thực hiện các kiểm thử một cách toàn diện về tất cả\r\nnhững cái chung trong đặc tả chức năng.
\r\n\r\nMục tiêu của phần này là xác nhận rằng toàn\r\nbộ tham số trong tất cả các TSFI đã được kiểm thử.
\r\n\r\n14.1.6.2. Chú thích ứng dụng
\r\n\r\nỞ phần này, nhà phát triển sản phẩm được yêu\r\ncầu chỉ ra xem các kiểm thử trong tài kiểm thử tương ứng với tất cả các TSFI\r\ntrong đặc tả chức năng như thế nào. Điều này có thể được thực hiện bởi một khai\r\nbáo tương ứng, cũng có thể sử dụng một bảng, ngoài ra, nhà phát triển sản phẩm\r\nđược yêu cầu chứng minh rằng các kiểm thử sử dụng toàn bộ các tham số của tất các\r\nTSFI. Yêu cầu bổ sung này bao gồm việc kiểm thử giới hạn và kiểm thử phủ nhận.\r\nKiểu kiểm thử này là không thấu đáo (toàn diện) bởi vì không phải mọi giá trị\r\ncó thể của tham số đều mong muốn được kiểm tra.
\r\n\r\n14.1.6.3. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n14.1.6.3.1. ATE_COV.3.1D
\r\n\r\nNhà phát triển sản phẩm cần đưa ra bản phân tích\r\ntổng quan kiểm thử
\r\n\r\n14.1.6.4. Các phần tử nội dung và trình bày
\r\n\r\n14.1.6.4.1. ATE_COV.3.1C
\r\n\r\nBản phân tích tổng quan kiểm thử cần đưa ra\r\nsự tương đương giữa các kiểm thử trong tài liệu kiểm thử và các TSFI trong đặc\r\ntả chức năng.
\r\n\r\n14.1.6.4.2. ATE_COV.3.2C
\r\n\r\nBản phân tích tổng quan kiểm thử cần chỉ ra\r\nrằng tất cả các TSFI trong đặc tả chức năng đã được kiểm thử một cách hoàn\r\nchỉnh.
\r\n\r\n14.1.6.5. Phần tử hành động của đánh giá viên
\r\n\r\n14.1.6.5.1. ATE_COV.3.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\ncó được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.
\r\n\r\n\r\n\r\n14.2.1. Mục tiêu
\r\n\r\nCác thành phần trong họ này đề cập đến mức\r\nchi tiết mà TSF được kiểm thử bởi nhà phát triển. Việc kiểm thử TSF dựa vào các\r\nthông tin chuyên sâu nhận được từ các biểu diễn thiết kế bổ sung và các mô tả.
\r\n\r\nMục đích là nhằm tính đến các nguy cơ bỏ qua\r\nmột số lỗi trong giai đoạn triển khai TOE. Việc kiểm thử cho các giao diện đối\r\nnội chuyên biệt không những chỉ cung cấp sự đảm bảo cho các hành vi mong muốn vĩ\r\nmô như đã thể hiện trong TSF, mà còn đảm bảo các hành vi liên quan đến các cơ\r\nchế hoạt động bên trong.
\r\n\r\n14.2.2. Phân mức thành phần
\r\n\r\nCác thành phần trong nhóm kiểu thử này được\r\nphân theo cấp độ dựa trên cơ sở của mức độ chi tiết có được trong các miêu tả TSF,\r\ntừ thiết kế TOE đến miêu tả thực thi. Các cấp độ này phản ánh các miêu tả của\r\nTSF thể hiện trong lớp ADV.
\r\n\r\n14.2.3. Chú thích ứng dụng
\r\n\r\nThiết kế TOE mô tả các thành phần bên trong\r\n(“các hệ thống thành phần - subsystems) và có thể là các modul của TSF, cùng\r\nvới sự mô tả về giao diện giữa các thành phần này và các mô đun. Chứng cứ của\r\nviệc kiểm thử thiết kế TOE này cần phải chỉ ra rằng các giao diện bên trong đều\r\nđã qua kiểm thử và bảo đảm rằng nó vận hành như đã mô tả. Điều này có thể được\r\nthực hiện bằng cách tiến hành các kiểm thử liên quan đến các giao diện ngoài\r\ncủa TSF, hoặc kiểm thử “hệ thống thành phần” TOE hoặc các giao diện mô đun một\r\ncách biệt lập. Quá trình kiểm thử các giao diện bên trong có thể được tiến hành\r\ntheo các cách thức trực tiếp hoặc gián tiếp. Trong trường hợp chậm trễ, thiết\r\nkế TOE cần đủ chi tiết để có thể hỗ trợ triển khai các kiểm thử trực tiếp.
\r\n\r\nTrong trường hợp ở phần mô tả tính đúng đắn\r\nvề mặt kiến trúc của TSF có trích dẫn các cơ chế đặc biệt, thì các kiểm thử đã\r\nthực hiện bởi nhà phát triển sản phẩm cần phải chỉ ra rằng các cơ chế đều đã\r\nqua kiểm thử và bảo đảm rằng nó vận hành như đã mô tả.
\r\n\r\nTại thành phần cao nhất của nhóm này, việc\r\nkiểm thử được thực hiện không chỉ theo thiết kế TOE mà còn theo sự mô tả thực\r\nthi.
\r\n\r\n14.2.4. ATE_DEPT.1 Kiểm thử: thiết kế cơ bản
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_ARC.1 Mô tả kiến trúc an toàn
\r\n\r\nADV_TDS.2 Thiết kế kiến trúc
\r\n\r\nATE_FUN.1 Kiểm thử chức năng
\r\n\r\n14.2.4.1. Mục tiêu
\r\n\r\nCác mô tả “hệ thống thành phần” của một TSF\r\ncung cấp sự mô tả ở mức độ cao về các quá trình vận hành nội tại của TSF. Việc\r\nkiểm thử ở cấp độ này của “các hệ thống thành phần” TOE nhằm đảm bảo rằng “các\r\nhệ thống thành phần” của một TSF vận hành và tác động lẫn nhau như đã được mô\r\ntả trong thiết kế TOE và mô tả kiến trúc an toàn.
\r\n\r\n14.2.4.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n14.2.4.2.1. ATE_DPT.1.1D
\r\n\r\nNhà phát triển sản phẩm cần trình ra được bản\r\nphân tích chuyên sâu của các kiểm thử đã tiến hành.
\r\n\r\n14.2.4.3. Các phần tử nội dung và trình bày
\r\n\r\n14.2.4.3.1. ATE_DPT.1.1C
\r\n\r\nBản phân tích chuyên sâu cần chỉ ra sự tương\r\nứng giữa các kiểm thử trong tài liệu kiểm thử và “các hệ thống thành phần”\r\ntrong thiết kế TOE.
\r\n\r\n14.2.4.3.2. ATE_DPT.1.2C
\r\n\r\nBản phân tích chuyên sâu cần chỉ ra rằng tất\r\ncả “các hệ thống thành phần” trong thiết kế TOE đã được kiểm thử.
\r\n\r\n14.2.4.4. Phần tử hành động của đánh giá viên
\r\n\r\n14.2.4.4.1. ATE_DTP.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\ncó được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.
\r\n\r\n14.2.5. ATE_DPT.2 Kiểm thử: các mô đun thực\r\nthi an toàn
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_ARC.1 Mô tả kiến trúc an toàn
\r\n\r\nADV_TDS.3 Thiết kế mang tính mô đun cơ bản
\r\n\r\nATE_FUN.1 Kiểm thử chức năng
\r\n\r\n14.2.5.1. Mục tiêu
\r\n\r\n“Hệ thống thành phần” và các mô tả mô đun của\r\nmột TSF cung cấp sự mô tả ở mức độ cao về các quá trình vận hành nội tại của\r\nTSF, và sự mô tả các giao diện của các mô đun thực thi SFR của TSF. Việc kiểm\r\nthử ở cấp độ này của mô tả TOE nhằm đảm bảo rằng “các hệ thống thành phần” của\r\nmột TSF và các mô đun thực thi SFR vận hành và tác động lẫn nhau như đã được mô\r\ntả trong thiết kế TOE và mô tả kiến trúc an toàn.
\r\n\r\n14.2.5.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n14.2.5.2.1. ATE_DPT.2.1D
\r\n\r\nNhà phát triển sản phẩm cần trình ra được bản\r\nphân tích về mức độ chi tiết (chuyên sâu) các kiểm thử đã tiến hành.
\r\n\r\n14.2.5.3. Các phần tử nội dung và trình bày
\r\n\r\n14.2.5.3.1. ATE_DPT.2.1C
\r\n\r\nBản phân tích chuyên sâu cấn chỉ ra được sự\r\ntương ứng giữa các kiểm thử trong tài liệu kiểm thử và “các hệ thống thành\r\nphần” TSF và các mô đun thực thi SFR trong thiết kế TOE.
\r\n\r\n14.2.5.3.2. ATE_DPT.2.2C
\r\n\r\nBản phân tích chuyên sâu của các kiểm thử đã\r\ntiến hành cần chỉ ra rằng “các hệ thống thành phần” TSF trong thiết kế TOE đã\r\nđược kiểm thử.
\r\n\r\n14.2.5.3.3. ATE_DPT.2.3C
\r\n\r\nBản phân tích chuyên sâu của các kiểm thử đã\r\ntiến hành cần chỉ ra rằng các mô đun thực thi SFR trong thiết kế TOE đã được\r\nkiểm thử.
\r\n\r\n14.2.5.4. Phần tử hành động của đánh giá viên
\r\n\r\n14.2.5.4.1. ATE_DPT.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\ncó được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.
\r\n\r\n14.2.6. ATE_DEPT.3 Kiểm thử. Thiết kế mang\r\ntính mô đun.
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_ARC.1 Mô tả kiến trúc an toàn.
\r\n\r\nADV_TDS.4 Thiết kế mang tính mô đun nửa chính\r\nthức
\r\n\r\nATE_FUN.1 Kiểm thử chức năng
\r\n\r\n14.2.6.1. Mục tiêu
\r\n\r\n“Các hệ thống thành phần” và các mô tả mô đun\r\ncủa một TSF đưa ra sự mô tả mức cao quá trình vận hành nội tại của TSF và sự mô\r\ntả các giao diện của các mô đun của TSF. Việc kiểm thử ở cấp độ này của mô tả\r\nTOE nhằm đảm bảo rằng “các hệ thống thành phần” TSF và các mô đun vận hành và\r\ntác động lẫn nhau như đã được mô tả trong thiết kế TOE và mô tả kiến trúc an\r\ntoàn.
\r\n\r\n14.2.6.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n14.2.6.2.1. ATE_DPT.3.1D
\r\n\r\nNhà phát triển sản phẩm cần trình ra được bản\r\nphân tích chuyên sâu các kiểm thử đã tiến hành.
\r\n\r\n14.2.6.3. Các phần tử nội dung và trình bày
\r\n\r\n14.2.6.3.1. ATE_DPT.3.1C
\r\n\r\nBản phân tích chuyên sâu của việc kiểm thử cấn\r\nchỉ ra sự tương ứng giữa các kiểm thử trong tài liệu kiểm thử và “các hệ thống\r\nthành phần” TSF và các mô đun trong thiết kế.
\r\n\r\n14.2.6.3.2. ATE_DPT.3.2C
\r\n\r\nBản phân tích chuyên sâu của việc kiểm thử cấn\r\nchỉ ra rằng tất cả “các hệ thống thành phần” TSF trong thiết kế TOE đã được\r\nkiểm thử.
\r\n\r\n14.2.6.3.3. ATE_DPT.3.3C
\r\n\r\nBản phân tích chuyên sâu của việc kiểm thử\r\ncấn chỉ ra rằng tất cả các mô đun TSF trong thiết kế TOE đã được kiểm thử.
\r\n\r\n14.2.6.4. Phần tử hành động của đánh giá viên
\r\n\r\n14.2.6.4.1. ATE_DTP.3.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\ncó được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.
\r\n\r\n14.2.7. ATE_DPT.4 Kiểm thử: Biểu diễn thực\r\nthi
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_ARC.1 Mô tả kiến trúc an toàn
\r\n\r\nADV_TDS.4 Thiết kế mang tính mô đun nửa chính\r\nthức
\r\n\r\nADV_IMP.1 Sự thực thi của TSF
\r\n\r\nATE_FUN.1 Kiểm thử chức năng
\r\n\r\n14.2.7.1. Mục tiêu
\r\n\r\n“Hệ thống thành phần” và các mô tả mô đun của\r\nmột TSF đưa ra sự mô tả mức cao quá trình vận hành nội tại của TSF và sự mô tả\r\ncác giao diện của các mô đun của TSF. Việc kiểm thử ở cấp độ này của mô tả TOE\r\nnhằm đảm bảo rằng “các hệ thống thành phần” TSF và các mô đun vận hành và tác\r\nđộng lẫn nhau như đã được mô tả trong thiết kế TOE và mô tả kiến trúc an toàn,\r\nvà theo đúng biểu diễn thực thi.
\r\n\r\n14.2.7.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n14.2.7.2.1. ATE_DPT.4.1D
\r\n\r\nNhà phát triển sản phẩm cần trình ra được bản\r\nphân tích chuyên sâu các kiểm thử đã tiến hành.
\r\n\r\n14.2.7.3. Các phần tử nội dung và trình bày
\r\n\r\n14.2.7.3.1. ATE_DPT.4.1C
\r\n\r\nBản phân tích chuyên sâu của việc kiểm thử cấn\r\nchỉ ra sự tương ứng giữa các kiểm thử trong tài liệu kiểm thử và “các hệ thống\r\nthành phần” TSF và các mô đun trong thiết kế.
\r\n\r\n14.2.7.3.2. ATE_DPT.4.2C
\r\n\r\nBản phân tích chuyên sâu của việc kiểm thử\r\ncấn chỉ ra rằng tất cả “các hệ thống thành phần” TSF trong thiết kế TOE đã được\r\nkiểm thử.
\r\n\r\n14.2.7.3.3. ATE_DPT.4.3C
\r\n\r\nBản phân tích chuyên sâu của việc kiểm thử\r\ncấn chỉ ra rằng TSF hoạt động theo đúng như biểu diễn thực thi.
\r\n\r\n14.2.7.4. Phần tử hành động của đánh giá viên
\r\n\r\n14.2.7.4.1. ATE_DTP.4.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\ncó được đã được tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.
\r\n\r\n14.3.1. Mục tiêu
\r\n\r\nViệc kiểm thử chức năng được các nhà phát\r\ntriển sản phẩm tiến hành nhằm đảm bảo rằng các kiểm thử trong tài liệu kiểm thử\r\nđược thực hiện và đưa thành tài liệu một cách đúng đắn. Sự tương ứng của các\r\nkiểm thử này với mô tả thiết kế TSF có được thông qua các họ Tổng quan (ATE-COV)\r\nvà Chiều sâu (ATE-DPT).
\r\n\r\nHọ này góp phần vào việc đảm bảo rằng xác\r\nsuất có các lỗi không bị phát hiện trong sản phẩm là tương đối nhỏ.
\r\n\r\nTập hợp các loại kiểm thử bao gồm nhóm\r\n(họ/lớp): Tổng quan (ATE_COV), chuyên sâu ATE_DPT), và nhóm các kiểm thử chức\r\nnăng (ATE_FUN) được sử dụng kết hợp nhằm định dạng các chứng cứ kiểm thử được\r\nnhà phát triển sản phẩm cung cấp (cùng với sản phẩm). Việc kiểm thử chức năng\r\nkhông phụ thuộc được thực hiện bởi đánh giá viên sản phẩm được phân loại vào\r\nnhóm “kiểm thử không phụ thuộc” (ATE_IDN).
\r\n\r\n14.3.2. Phân mức thành phần
\r\n\r\nCác thành phần thuộc nhóm kiểm thử này được\r\nphân làm 2 cấp độ. Trong đó, ở thành phần ở cấp độ cao hơn, các kiểm thử phụ\r\nthuộc kèm theo sẽ phải được phân tích cặn kẽ.
\r\n\r\n14.3.3. Chú thích ứng dụng
\r\n\r\nCác quy trình của các kiểm thử cần được tiến\r\nhành chính là các hướng dẫn nhằm sử dụng chương trình kiểm thử cũng như làm chủ\r\ncác thiết bị hoặc công nghệ liên quan, bao gồm cả các vấn đề liên quan đến môi\r\ntrường kiểm thử, điều kiện kiểm thử, các biến số và đánh giá số liệu,… Quy\r\ntrình kiểm thử cần phải chỉ ra được rằng, kết quả kiểm thử được tính toán như\r\nthế nào từ các số liệu đầu vào của các kiểm thử này.
\r\n\r\nCác kiểm thử phụ thuộc có liên quan, khi mà\r\nquá trình tiến hành các kiểm thử riêng biệt có thành công hay không phụ thuộc\r\nvào sự tồn tại các trạng thái riêng biệt đó. Ví dụ: có thể có các đòi hỏi như\r\nkiểm thử A phải được tiến hành trước khi thực hiện kiểm thử B, bởi vì trạng\r\nthái của sản phẩm được hình thành từ việc tiến hành thành công kiểm thử A là sự\r\ntiên quyết cho việc thực hiện thành công kiểm thử B. Như vậy, khi kiểm thử B\r\nhoạt động không như mong đợi, có thể liên quan đến vấn đề nào đó của kiểm thử\r\nphụ thuộc liên quan trước đó (trong trường hợp này là kiểm thử A).
\r\n\r\n14.3.4. ATE_FUN.1 Kiểm thử chức năng
\r\n\r\nCác phụ thuộc: ATE_COV.1 Chứng cứ tổng quan
\r\n\r\n14.3.4.1. Mục tiêu
\r\n\r\nTrong phần này, mục đích là các nhà phát\r\ntriển sản phẩm dùng các kiểm thử trong nhóm này để thể hiện rằng các kiểm thử\r\ntrong tài liệu kiểm thử đều được và đưa thành tài liệu chính xác.
\r\n\r\n14.3.4.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n14.3.4.2.1. ATE_FUN.1.1D
\r\n\r\nNhà phát triển sản phẩm cần thực hiện kiểm\r\nthử TSF và tập hợp các kết quả kiểm thử thành văn bản.
\r\n\r\n14.3.4.2.2. ATE_FUN.1.2D
\r\n\r\nNhà phát triển sản phẩm cần đưa ra được các\r\ntài liệu kiểm thử.
\r\n\r\n14.3.4.3. Các phần tử nội dung và trình bày
\r\n\r\n14.3.4.3.1. ATE_FUN.1.1C
\r\n\r\nTài liệu kiểm thử cần trình bày nhất quán các\r\nkế hoạch kiểm thử, các kết quả kiểm thử mong muốn và các kết quả đo được thực\r\ntế.
\r\n\r\n14.3.4.3.2. ATE_FUN.1.2C
\r\n\r\nKế hoạch kiểm thử cần xác định các kiểm thử\r\ncần phải được tiến hành và mô tả các kịch bản cho mỗi hoạt động kiểm thử. Các\r\nkịch bản này bao gồm bất kỳ các kiểm thử phụ thuộc có trình tự nào dựa trên các\r\nkết quả của các kiểm thử khác.
\r\n\r\n14.3.4.3.3. ATE_FUN.1.3C
\r\n\r\nCác kết quả kiểm thử mong muốn cần chỉ ra các\r\nkết quả mang tính dự báo từ các kiểm thử được thực hiện thành công.
\r\n\r\n14.3.4.3.4. ATE_FUN.1.4C
\r\n\r\nCác kết quả kiểm thử thực sự cần phải phù hợp\r\nvới các kết quả kiểm thử mong muốn.
\r\n\r\n14.3.4.4. Phần tử hành động của đánh giá viên
\r\n\r\n14.3.4.4.1. ATE_FUN.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\ncó được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.
\r\n\r\n14.3.5. ATE_FUN.2 Kiểm thử chức năng theo\r\ntrình tự
\r\n\r\nCác phụ thuộc: ATE_COV.1 Chứng cứ tổng quan
\r\n\r\n14.3.5.1. Mục tiêu
\r\n\r\nMục đích là để nhà phát triển sản phẩm chỉ ra\r\nrằng các kiểm thử trong tài liệu kiểm thử được thực hiện và đưa thành tài liệu\r\nchính xác, và đảm bảo rằng việc kiểm thử có cấu trúc giống như là để bác bỏ các\r\nminh chứng xung quanh sự đúng đắn của các giao diện đã được kiểm thử.
\r\n\r\n14.3.5.2. Chú thích ứng dụng
\r\n\r\nMặc dù quy trình kiểm thử có thể chỉ ra các\r\nđiều kiện tất yếu trong quá trình bố trí trình tự các kiểm thử phụ thuộc, các\r\nquy trình này chưa thể cho thấy một trình tự tối ưu hợp lý. Việc phân tích các\r\nquá trình tiến hành các kiểm thử phụ thuộc là một yếu tố quan trọng nhằm đánh\r\ngiá tính tương đương của các quá trình kiểm thử khác nhau, bởi vì có khả năng\r\ncác lỗi được giấu kỹ trong khi trình tự để tiến hành kiểm thử bị thay đổi.
\r\n\r\n14.3.5.3. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n14.3.5.3.1. ATE_FUN.2.1D
\r\n\r\nNhà phát triển sản phẩm cần thực hiện các\r\nkiểm thử liên quan đến TSF và tập hợp các kết quả kiểm thử thành văn bản.
\r\n\r\n14.3.5.3.2. ATE_FUN.2.2D
\r\n\r\nNhà phát triển sản phẩm cần đưa ra được các\r\ntài liệu liên quan đến các kiểm thử đã tiến hành và các kết quả kiểm thử.
\r\n\r\n14.3.5.4. Các phần tử nội dung và trình bày
\r\n\r\n14.3.5.4.1. ATE_FUN.2.1C
\r\n\r\nTài liệu kiểm thử cần trình bày đầy đủ các kế\r\nhoạch kiểm thử, các kết quả kiểm thử mong muốn và các kết quả kiểm thử thực sự.
\r\n\r\n14.3.5.4.2. ATE_FUN.2.2C
\r\n\r\nCác kế hoạch kiểm thử cần xác định các kiểm\r\nthử được thực hiện và mô tả các kịch bản cho mỗi hoạt động kiểm thử. Các kịch\r\nbản này bao gồm bất kỳ các kiểm thử phụ thuộc có trình tự nào dựa trên các kết\r\nquả của các kiểm thử khác.
\r\n\r\n14.3.5.4.3. ATE_FUN.2.3C
\r\n\r\nCác kết quả kiểm thử mong muốn chỉ ra các kết\r\nquả mang tính dự báo nếu như các kiểm thử được thực hiện thành công.
\r\n\r\n14.3.5.4.4. ATE_FUN.2.4C
\r\n\r\nCác kết quả kiểm thử thực sự cần bao gồm cả\r\ncác kết quả kiểm thử mong muốn.
\r\n\r\n14.3.5.4.5. ATE_FUN.2.5C
\r\n\r\nTài liệu kiểm thử cần phải bao gồm cả phần\r\nphân tích quy trình kiểm thử của các kiểm thử phụ thuộc theo trình tự.
\r\n\r\n14.3.5.4.6. ATE_FUN.2.6C
\r\n\r\nTài liệu kiểm thử cần phải bao gồm cả phần\r\nphân tích quy trình kiểm thử của các kiểm thử phụ thuộc theo trình tự.
\r\n\r\n14.3.5.5. Phần tử hành động của đánh giá viên
\r\n\r\n14.3.5.5.1. ATE_FUN.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\ncó được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.
\r\n\r\n14.4.1. Mục tiêu
\r\n\r\nMục đích của nhóm này là dựa vào các sự đảm\r\nbảo có được trong các nhóm ATE_FUN, ATE_COV, và ATE_DPT bằng việc xác minh sự\r\nkiểm thử bởi nhà phát triển sản phẩm và thực hiện các kiểm thử bổ sung bởi đánh\r\ngiá viên.
\r\n\r\n14.4.2. Phân mức thành phần
\r\n\r\nCác cấp độ được đề xuất trên cơ sở liên quan\r\nđến số lượng của các tài liệu kiểm thử bởi nhà phát triển sản phẩm, các hỗ trợ\r\nkiểm thử kèm theo và số lượng các kiểm thử của đánh giá viên.
\r\n\r\n14.4.3. Chú thích ứng dụng
\r\n\r\nNhóm các kiểm thử này được đề cập đến một khi\r\ncó sự đòi hỏi phải tiến hành các kiểm thử không phụ thuộc trong khuôn khổ TSF.\r\nCác kiểm thử chức năng không phụ thuộc có thể có hình thức là lặp lại (toàn bộ\r\nhoặc từng phần) các kiểm thử chức năng đã được các nhà phát triển sản phẩm tiến\r\nhành hoặc mở rộng phạm vi hay mức độ chuyên sâu của các kiểm thử đã được nhà\r\nphát triển sản phẩm tiến hành. Các hoạt động này là có tính bù trừ và một sự\r\nkết hợp hợp lý cần phải được tính đến cho mỗi TOE, trên cơ sở đảm bảo tính khả\r\nthi và tính bao trùm của các kết quả kiểm thử thu được, cũng như phải đảm bảo\r\ntính toàn vẹn chức năng của TSF.
\r\n\r\nNhóm mẫu các kiểm thử được nhà phát triển sản\r\nphẩm đề xuất nhằm mục đích đưa ra sự chứng thực là nhà phát triển sản phẩm đã\r\nthực hiện chương trình các kiểm thử trên cơ sở TSF và đã thu được chính xác các\r\nkết quả chính thức. Phạm vi số lượng các mẫu được thu thập để tiến hành kiểm\r\nthử sẽ ảnh hưởng đến chi tiết, cũng như chất lượng của các kết quả các kiểm thử\r\nchức năng do nhà phát triển sản phẩm đã đưa ra. Phía đánh giá viên cần tính đến\r\nphạm vi các kiểm thử cần đề xuất thêm và cân đối lợi ích tương đối có thể thu\r\nđược khi quan tâm đến cả hai lĩnh vực này của các kiểm thử không phụ thuộc. Cũng\r\ncần thừa nhận rằng, đôi khi việc lặp lại tất cả các kiểm thử của nhà phát triển\r\nsản phẩm đưa ra là mong muốn và khả thi, nhưng trong các trường hợp khác có thể\r\nlà khá khó khăn và không hiệu quả. Cho nên cần hạn chế các thử nghiệm thực sự\r\nkhó triển khai. Quá trình tiến hành lấy mẫu cần tập trung vào toàn bộ phổ của\r\ncác kết quả thử nghiệm đã thu được, hơn nữa cần bao gồm cả các kết quả thỏa mãn\r\nđược những đòi hỏi của các kiểm thử chung (ATE_COV) và các kiểm thử chuyên biệt\r\n(ATE_DPT).
\r\n\r\nCũng cần xem xét đến các cấu hình (cấu trúc)\r\nkhác nhau của TOE trong quá trình tiến hành đánh giá. Đánh giá viên cũng cần\r\ncân nhắc tới khả năng sử dụng ngay các kết quả kiểm thử được cung cấp và căn cứ\r\nvào đó để lên kế hoạch cho các kiểm thử của riêng mình.
\r\n\r\nSự thích hợp của TOE đối với các kiểm thử căn\r\ncứ vào khả năng truy cập vào TOE, và các tài liệu hỗ trợ cũng như các thông tin\r\nđòi hỏi (cũng liên quan đến các chương trình phần mềm kiểm thử hoặc các công\r\ncụ) để tiến hành kiểm thử. Sự cần thiết của các hỗ trợ đó chủ yếu là liên quan\r\nđến các kiểm thử phụ thuộc thuộc các nhóm (lớp) khác.
\r\n\r\nNgoài ra, Sự thích hợp của TOE đối với các\r\nkiểm thử còn có thể nằm ở những lý do khác. Ví dụ, định dạng của TOE do nhà\r\nphát triển sản phẩm cung cấp không phải là phiên bản (ver-sion) mới nhất.
\r\n\r\nThuật ngữ “các giao diện” chỉ các giao\r\ndiện được mô tả trong đặc tả chức năng và thiết kế TOE, các tham số truyền qua\r\ncác dẫn chứng đã đồng nhất trong mô tả thực thi. Tập hợp chính xác các giao\r\ndiện đã sử dụng được lựa chọn qua các thành phần Tổng quan (ATE_COV) và Chiều\r\nsâu (ATE_DPT).
\r\n\r\nCác căn cứ cho một tập hợp con của TSF chú\r\ntrọng tới khả năng cho phép đánh giá viên thiết kế một tập hợp các kiểm thử\r\nthích hợp, phù hợp với các mục tiêu mà đánh giá viên theo đuổi từ đầu.
\r\n\r\n14.4.4. ATE_IND.1 Kiểm thử độc lập - tuân thủ
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_FSP.1 Đặc tả chức năng cơ bản
\r\n\r\nAGD_OPE.1 Hướng dẫn thao tác người dùng.
\r\n\r\nSGD_PRE.1 Các quy trình chuẩn bị
\r\n\r\n14.4.4.1. Mục tiêu
\r\n\r\nTrong phần này, mục đích là để thể hiện rằng\r\nTOE hoạt động theo đúng mô tả thiết kế và các tài liệu hướng dẫn của nó.
\r\n\r\n14.4.4.2. Chú thích ứng dụng
\r\n\r\nThành phần này không đề cập đến việc sử dụng\r\ncác kết quả kiểm thử bởi nhà phát triển sản phẩm. Điều đó phù hợp với nơi mà\r\ncác kết quả không thể có được và trong trường hợp việc kiểm thử bởi nhà phát\r\ntriển sản phẩm được chấp nhận nhưng không có sự phê chuẩn. Đánh giá viên được\r\nyêu cầu lập ra và tiến hành các kiểm thử với mục đích xác nhận rằng TOE hoạt\r\nđộng đúng theo các mô tả thiết kế của nó, bao gồm cả đặc tả chức năng. Cách\r\ntiếp cận này là để đạt được sự tin cậy trong thao tác chỉnh sửa qua việc kiểm\r\nthử mẫu, hơn nữa để tiến hành mọi kiểm thử có thể. Phạm vi của kiểm thử được\r\nlập ra cho mục đích này là một sản phẩm phương pháp luận, và cần phải được xem\r\nxét trong phạm vi một TOE riêng biệt và sự cân nhắc của các hoạt động đánh giá\r\nkhác.
\r\n\r\n14.4.4.3. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n14.4.4.3.1. ATE_IND.1.1D
\r\n\r\nNhà phát triển sản phẩm cần đưa ra TOE cho\r\ncác kiểm thử này
\r\n\r\n14.4.4.4. Các phần tử nội dung và trình bày
\r\n\r\n14.4.4.4.1. ATE_IND.1.1C
\r\n\r\nTOE cần thích hợp cho kiểm thử.
\r\n\r\n14.4.4.5. Phần tử hành động của đánh giá viên
\r\n\r\n14.4.4.5.1. ATE_IND.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\ncó được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.
\r\n\r\n14.4.4.5.2. ATE_IND.1.2E
\r\n\r\nĐánh giá viên cần kiểm thử một tập hợp con\r\ncủa TSF nhằm xác nhận rằng TOE hoạt động như đã được xác định ban đầu.
\r\n\r\n14.4.5. ATE_IND.2 Kiểm thử độc lập - lấy mẫu
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_FSP.2 Mô tả chức năng thực thi an toàn
\r\n\r\nAGD_OPE.1 Hướng dẫn thao tác người sử dụng
\r\n\r\nAGD_PRE.1 Các quy trình chuẩn bị
\r\n\r\nATE_COV.1 Chứng cứ tổng quan
\r\n\r\nATE_FUN.1 Kiểm thử chức năng
\r\n\r\n14.4.5.1. Mục tiêu
\r\n\r\nTrong phần này, mục đích là để thể hiện rằng\r\nTOE hoạt động đúng theo các mô tả thiết kế và các tài liệu hướng dẫn của nó.\r\nViệc kiểm thử bởi đánh giá viên xác nhận rằng nhà phát triển sản phẩm đã thực\r\nhiện một số kiểm thử của một vài giao diện trong đặc tả chức năng.
\r\n\r\n14.4.5.2. Chú thích ứng dụng
\r\n\r\nĐiểm mấu chốt ở đây là nhà phát triển sản\r\nphẩm cần phải cung cấp các tài liệu cần thiết sao cho đánh giá viên có thể tái\r\ntạo lại các kiểm thử đã được tiến hành bởi nhà phát triển sản phẩm, trong đó có\r\nthể bao gồm các tài liệu kiểm thử mà máy đọc được, các chương trình (phần mềm)\r\nkiểm thử, v.v…
\r\n\r\nĐánh giá viên phải có được các kết quả (số\r\nliệu) kiểm thử từ nhà phát triển sản phẩm để hỗ trợ chương trình kiểm thử của\r\nmình. Nhà đánh giá sẽ lặp lại một loạt (mẫu) các kiểm thử của nhà phát triển\r\nsản phẩm nhằm thu được sự tin chắc vào các kết quả nhận được. Trên cơ sở có\r\nđược, đánh giá viên sẽ tiến hành thêm các kiểu thử cho phép sử dụng TOE theo các\r\ncách khác, sau đó đánh giá viên sẽ tập trung kiểm thử ở những khu vực quan tâm\r\nriêng.
\r\n\r\n14.4.5.3. Phần tử hành động của nhà phát triển
\r\n\r\n14.4.5.3.1. ATE_IND.2.1D
\r\n\r\nNhà phát triển sản phẩm cần đưa ra TOE cho các\r\nkiểm thử này.
\r\n\r\n14.4.5.4. Các phần tử nội dung và trình bày
\r\n\r\n14.4.5.4.1. ATE_IND.2.1C
\r\n\r\nTOE cần thích hợp cho kiểm thử.
\r\n\r\n14.4.5.4.2. ATE_IND.2.2C
\r\n\r\nNhà phát triển sản phẩm cần phải đưa ra được\r\nmột tập hợp các nguồn gốc tương thích với các kiểm thử chức năng đã được họ\r\ntiến hành đối với TSF.
\r\n\r\n14.4.5.5. Phần tử hành động của đánh giá viên
\r\n\r\n14.4.5.5.1. ATE_IND.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\ncó được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.
\r\n\r\n14.4.5.5.2. ATE_IND.2.2E
\r\n\r\nĐánh giá viên cần thực hiện một bộ mẫu trong\r\nphạm vi các kiểm thử được mô tả trong tài liệu kiểm thử nhằm thẩm định các kết\r\nquả kiểm thử có được từ các nhà phát triển sản phẩm.
\r\n\r\n14.4.5.5.3. ATE_IND.2.3E
\r\n\r\nĐánh giá viên cần kiểm thử một tập hợp con\r\nthích hợp của TSF nhằm xác nhận rằng TSF hoạt động như đã được xác định ban\r\nđầu.
\r\n\r\n14.4.6. ATE_IND.3 Kiểm thử độc lập - toàn\r\ndiện
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_FSP.4 Đặc tả chức năng toàn diện
\r\n\r\nAGD_OPE.1 Hướng dẫn thao tác người sử dụng
\r\n\r\nAGD_PRE.1 Các quy trình chuẩn bị
\r\n\r\nATE_COV.1 Chứng cứ tổng quan
\r\n\r\nATE_FUN.1 Kiểm thử chức năng
\r\n\r\n14.4.6.1. Mục tiêu
\r\n\r\nTrong phần này, mục đích là để thể hiện rằng\r\nTOE hoạt động đúng theo các mô tả thiết kế và các tài liệu hướng dẫn của nó.\r\nViệc kiểm thử bởi đánh giá viên bao gồm cả việc lặp lại toàn bộ các kiểm thử do\r\nnhà phát triển sản phẩm đã tiến hành.
\r\n\r\n14.4.6.2. Chú thích ứng dụng
\r\n\r\nĐiểm mấu chốt ở đây là nhà phát triển sản\r\nphẩm cần phải cung cấp các tài liệu cần thiết sao cho đánh giá viên có thể tái\r\ntạo lại các kiểm thử đã được tiến hành bởi nhà phát triển sản phẩm, trong đó có\r\nthể bao gồm các tài liệu kiểm thử mà máy đọc được, các chương trình (phần mềm)\r\nkiểm thử, v.v…
\r\n\r\nĐánh giá viên phải có lặp lại tất cả các kiểm\r\nthử của nhà phát triển sản phẩm như là một phần trong chương trình kiểm thử của\r\nmình. Đánh giá viên sẽ lặp lại một loạt (mẫu) các kiểm thử của nhà phát triển\r\nsản phẩm nhằm thu được sự tin chắc vào các kết quả nhận được. Trên cơ sở có\r\nđược, đánh giá viên sẽ tiến hành thêm các kiểm thử cho phép sử dụng TOE theo\r\ncác cách khác so với cách thông thường mà nhà phát triển sản phẩm trình bày.\r\nTrừ trường hợp các kiểm thử của nhà phát triển sản phẩm tỏ ra là đã thấu đáo.
\r\n\r\n14.4.6.3. Phần tử hành động của nhà phát triển
\r\n\r\n14.4.6.3.1. ATE_IND.3.1D
\r\n\r\nNhà phát triển sản phẩm cần đưa ra TOE cho các\r\nkiểm thử
\r\n\r\n14.4.6.4. Các phần tử nội dung và trình bày
\r\n\r\n14.4.6.4.1. ATE_IND.3.1C
\r\n\r\nTOE cần thích hợp cho kiểm thử.
\r\n\r\n14.4.6.4.2. ATE_IND.3.2C
\r\n\r\nNhà phát triển sản phẩm cần phải đưa ra được\r\nmột tập hợp các nguồn gốc tương thích với các kiểm thử chức năng đã được họ\r\ntiến hành đối với TSF.
\r\n\r\n14.4.6.5. Phần tử hành động của đánh giá viên
\r\n\r\n14.4.6.5.1. ATE_IND.3.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\ncó được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.
\r\n\r\n14.4.6.5.2. ATE_IND.3.2E
\r\n\r\nĐánh giá viên cần thực hiện toàn bộ các\r\nkiểm thử được mô tả trong tài liệu kiểm thử nhằm thẩm định các kết quả kiểm\r\nthử có được từ các nhà phát triển sản phẩm.
\r\n\r\n14.4.6.5.3. ATE_IND.3.3E
\r\n\r\nĐánh giá viên cần kiểm thử TSF nhằm xác nhận\r\nrằng toàn bộ TSF hoạt động như đã được xác định ban đầu.
\r\n\r\nLớp này đề cập đến khả năng khai thác các\r\nđiểm yếu được giới thiệu trong quá trình phát triển.
\r\n\r\nHình sau thể hiện các họ trong lớp này, và\r\nphân cấp các thành phần trong các họ.
\r\n\r\n![](\"00907948_files/image015.jpg\")
Nhìn chung, hoạt động đánh giá điểm yếu xuyên\r\nsuốt các điểm yếu khác nhau trong phát triển và hoạt động của TOE. Các điểm yếu\r\ntrong phát triển lợi dụng một số đặc tính của TOE được giới thiệu trong quá\r\ntrình phát triển nó, như hủy bỏ tự bảo vệ của TSF thông qua việc giả mạo, trực\r\ntiếp tấn công hoặc giám sát TSF, hủy bỏ phân vùng TSF qua giám sát hoặc tấn\r\ncông trực tiếp TSF, hoặc hủy bỏ không cần mật khẩu qua việc phá hủy (bằng mật\r\nkhẩu) TSF. Các điểm yếu trong hoạt động lợi dụng các nhược điểm của các biện\r\npháp phòng chống không mang tính kỹ thuật để vi phạm TOE SFR, như lạm dụng hoặc\r\ncấu hình không đúng. Lạm dụng nhằm kiểm tra xem TOE có thể được cấu hình hoặc\r\nsử dụng theo cách không an toàn mà người quản trị hoặc người dùng TOE vẫn tin\r\nrằng nó an toàn.
\r\n\r\nViệc đánh giá các điểm yếu trong phát triển\r\nđược nêu trong họ đảm bảo AVA_VAN. Về cơ bản, tất cả các điểm yếu trong phát\r\ntriển đều có thể được xem xét liên quan trong thành phần AVA_VAN bởi vì thực tế\r\nhọ này cho phép ứng dụng với nhiều hệ phương pháp đánh giá không đặc trưng cho\r\nmột kịch bản tấn công nào. Các hệ phương pháp đánh giá không đặc trưng này bao\r\ngồm cả các hệ phương pháp đặc trưng cho các TSF đó, trong đó xem xét đến các\r\nkênh trái phép (ước lượng dung lượng kênh có thể thực hiện bằng các phép đo kỹ\r\nthuật không chính thức, và các phép đo kiểm tra thực tế) hoặc có thể khắc phục\r\nbằng việc sử dụng nguồn tài nguyên đầy đủ theo hình thức tấn công trực tiếp (mô\r\nhình kỹ thuật nền tảng của các TSF này dựa trên các cơ chế xác suất hoặc hoán\r\nvị; cải thiện hoạt động an toàn của chúng và các biện pháp khắc phục có thể\r\nthực hiện thông qua phân tích xác suất hay định lượng).
\r\n\r\nNếu có các mục tiêu an toàn đã chỉ rõ trong\r\nST để ngăn chặn sự theo dõi của một người dùng TOE khỏi người dùng khác, hoặc\r\nđể đảm bảo rằng các luồng thông tin không thể được sử dụng để thu lại các tín\r\nhiệu dữ liệu trái phép đã thực thi, thì phân tích kênh trái phép cần được xét\r\nđến trong suốt quá trình tiến hành phân tích điểm yếu. Điều này thường được\r\nphản ánh trong Khả năng ẩn dấu (FPR_UNO) của TCVN 8709-2 và các chính sách kiểm\r\nsoát truy cập nhiều mức đã chỉ ra thông qua chính sách kiểm soát truy cập\r\n(FDP_ACC) trong 15408-2 và/hoặc các yêu cầu chính sách kiểm soát luồng thông\r\ntin (FDP_IFC) trong ST trong 15408-2.
\r\n\r\n15.2.1. Mục tiêu
\r\n\r\nPhân tích điểm yếu là đánh giá xem các điểm\r\nyếu tiềm ẩn được xác định trong quá trình đánh giá, trong hoạt động đoán trước\r\nđược của TOE hoặc bằng các phương thức khác (ví dụ như các giả thuyết sai, các\r\nphân tích định lượng hay thống kê về hoạt động an toàn của các cơ chế an toàn\r\nđang xét) có thể cho phép những kẻ tấn công vi phạm các SFR hay không.
\r\n\r\nPhân tích điểm yếu đề cập đến các mối đe dọa\r\ndo kẻ tấn công có thể phát hiện các chỗ sơ hở cho phép truy cập trái phép dữ\r\nliệu và chức năng, cho phép can thiệp hoặc sửa đổi TSF, hoặc can thiệp các\r\nquyền của các người sử dụng khác.
\r\n\r\n15.2.2. Phân mức thành phần
\r\n\r\nPhân mức thành phần dựa trên độ phức tạp tăng\r\ndần của phân tích điểm yếu thực hiện bởi đánh giá viên và mức độ tăng của khả\r\nnăng tấn công gây ra bởi một kẻ tấn công để xác định và khai thác các điểm yếu\r\ntiềm ẩn.
\r\n\r\n15.2.3. AVA_VAN.1 Tổng quan điểm yếu
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_FSP.1 Đặc tả chức năng cơ bản
\r\n\r\nAGD_OPE.1 Hướng dẫn người dùng vận hành
\r\n\r\nAGD_PRE.1 Các thủ tục chuẩn bị
\r\n\r\n15.2.3.1. Mục tiêu
\r\n\r\nKhảo sát điểm yếu của thông tin có sẵn thông\r\nbáo công khai được thực hiện bởi đánh giá viên để xác định các điểm yếu tiềm ẩn\r\ncó thể dễ dàng bị một kẻ tấn công tìm ra.
\r\n\r\nĐánh giá viên thực hiện việc kiểm thử xâm\r\nnhập để xác nhận rằng các điểm yếu tiềm ẩn không thể bị khai thác trong môi\r\ntrường vận hành TOE. Kiểm thử xâm nhập được thực hiện bởi đánh giá viên giả\r\nthiết khả năng tấn công ở mức cơ bản.
\r\n\r\n15.2.3.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n15.2.3.2.1. AVA_VAN.1.1D
\r\n\r\nNhà phát triển sản phẩm cần đưa ra TOE cho\r\ncác kiểm thử này.
\r\n\r\n15.2.3.3. Các phần tử nội dung và trình bày
\r\n\r\n15.2.3.3.1. AVA_VAN1.1C
\r\n\r\nTOE cần thích hợp cho kiểm thử.
\r\n\r\n15.2.3.4. Phần tử hành động của đánh giá viên
\r\n\r\n15.2.3.4.1. AVA_VAN.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\ncó được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.
\r\n\r\n15.2.3.4.2. AVA_VAN.1.2E
\r\n\r\nĐánh giá viên cần thực hiện việc tìm kiếm các\r\nnguồn thông tin công cộng để nhận biết các điểm yếu tiềm ẩn trong TOE
\r\n\r\n15.2.3.4.3. AVA_VAN.1.3E
\r\n\r\nĐánh giá viên cần tiến hành việc kiểm thử xâm\r\nnhập dựa trên các điểm yếu tiềm ẩn đã biết để xác nhận rằng TOE được bảo vệ\r\ntrước các tấn công của kẻ tấn công với khả năng tấn công cơ bản.
\r\n\r\n15.2.4. AVA_VAN.2 Phân tích điểm yếu
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_ARC.1 Mô tả kiến trúc an toàn.
\r\n\r\nADV_FSP.1 Đặc tả chức năng cơ bản
\r\n\r\nADV_TDS.1 Thiết kế cơ bản
\r\n\r\nAGD_OPE.1 Hướng dẫn người dùng vận hành
\r\n\r\nAGD_PRE.1 Các thủ tục chuẩn bị
\r\n\r\n15.2.4.1. Mục tiêu
\r\n\r\nPhân tích điểm yếu được thực hiện bởi đánh\r\ngiá viên nhằm xác định chắc chắn sự có mặt của các điểm yếu tiềm ẩn.
\r\n\r\nĐánh giá viên thực hiện việc kiểm thử xâm\r\nnhập để xác nhận rằng các điểm yếu tiềm ẩn không thể bị khai thác trong môi\r\ntrường vận hành TOE. Kiểm thử xâm nhập được thực hiện bởi đánh giá viên áp dụng\r\nkhả năng tấn công ở mức cơ bản.
\r\n\r\n15.2.4.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n15.2.4.2.1. AVA_VAN.2.1D
\r\n\r\nNhà phát triển cần cung cấp TOE để kiểm thử.
\r\n\r\n15.2.4.3. Các phần tử nội dung và trình bày
\r\n\r\n15.2.4.3.1. AVA_VAN.2.1C
\r\n\r\nTOE cần thích hợp cho kiểm thử.
\r\n\r\n15.2.4.4. Phần tử hành động của đánh giá viên
\r\n\r\n15.2.4.4.1. AVA_VAN.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\ncó được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.
\r\n\r\n15.2.4.4.2. AVA_VAN.2.2E
\r\n\r\nĐánh giá viên cần thực hiện việc tìm kiếm các\r\nnguồn thông tin công cộng để nhận biết các điểm yếu tiềm ẩn trong TOE.
\r\n\r\n15.2.4.4.3. AVA_VAN.2.3E
\r\n\r\nĐánh giá viên cần thực hiện phân tích điểm\r\nyếu độc lập của TOE thông qua tài liệu hướng dẫn, đặc tả chức năng, thiết kế\r\nTOE và mô tả kiến trúc an toàn để xác định các điểm yếu tiềm ẩn trong TOE.
\r\n\r\n15.2.4.4.4. AVA_VAN.2.4E
\r\n\r\nĐánh giá viên cần tiến hành việc kiểm thử xâm\r\nnhập dựa trên các điểm yếu tiềm ẩn đã biết để xác nhận rằng TOE được bảo vệ các\r\ntấn công của kẻ tấn công với khả năng tấn công cơ bản.
\r\n\r\n15.2.5. AVA_VAN.3 Phân tích các điểm yếu\r\ntrọng tâm
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_ARC.1 Mô tả kiến trúc an toàn
\r\n\r\nADV_FSP.2 Đặc tả chức năng thực thi an toàn
\r\n\r\nADV_TDS.3 Thiết kế mô đun cơ bản
\r\n\r\nADV_TMP.1 Biểu diễn triển khai của TSF
\r\n\r\nAGD_OPE.1 Hướng dẫn người dùng vận hành
\r\n\r\nAGD_PRE.1 Các thủ tục chuẩn bị
\r\n\r\n15.2.5.1. Mục tiêu
\r\n\r\nPhân tích điểm yếu được thực hiện bởi đánh\r\ngiá viên nhằm xác định chắc chắn sự có mặt của các điểm yếu tiềm ẩn.
\r\n\r\nĐánh giá viên thực hiện việc kiểm thử xâm\r\nnhập để xác nhận rằng các điểm yếu tiềm ẩn không thể bị khai thác trong môi\r\ntrường vận hành TOE. Kiểm thử xâm nhập được thực hiện bởi đánh giá viên áp dụng\r\nkhả năng tấn công ở mức cơ bản nâng cao.
\r\n\r\n15.2.5.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n15.2.5.2.1. AVA_VAN.3.1D
\r\n\r\nNhà phát triển cần cung cấp TOE cho kiểm thử.
\r\n\r\n15.2.5.3. Các phần tử nội dung và trình bày
\r\n\r\n15.2.5.3.1. AVA_VAN.3.1C
\r\n\r\nTOE cần thích hợp cho kiểm thử.
\r\n\r\n15.2.5.4. Phần tử hành động của đánh giá viên
\r\n\r\n15.2.5.4.1. AVA_VAN.3.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\ncó được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.
\r\n\r\n15.2.5.4.2. AVA_VAN.3.2E
\r\n\r\nĐánh giá viên cần thực hiện việc tìm kiếm các\r\nnguồn thông tin công cộng để nhận biết các điểm yếu tiềm ẩn trong TOE.
\r\n\r\n15.2.5.4.3. AVA_VAN.3.3E
\r\n\r\nĐánh giá viên cần thực hiện phân tích điểm\r\nyếu độc lập của TOE thông qua tài liệu hướng dẫn, đặc tả chức năng, thiết kế\r\nTOE và mô tả kiến trúc an toàn và biểu diễn triển khai để xác định các\r\nđiểm yếu tiềm ẩn trong TOE.
\r\n\r\n15.2.5.4.4. AVA_VAN.3.4E
\r\n\r\nĐánh giá viên cần tiến hành việc kiểm thử xâm\r\nnhập dựa trên các điểm yếu tiềm ẩn đã biết để xác nhận rằng TOE được bảo vệ\r\ntrước các tấn công của kẻ tấn công với khả năng tấn công cơ bản nâng cao.
\r\n\r\n15.2.6. AVA_VAN.4 Phân tích điểm yếu có hệ\r\nthống
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_ARC.1 Mô tả kiến trúc an toàn
\r\n\r\nADV_FSP.2 Đặc tả chức năng thực thi an toàn
\r\n\r\nADV_TDS.3 Thiết kế mô đun cơ bản
\r\n\r\nADV_TMP.1 Biểu diễn triển khai của TSF
\r\n\r\nAGD_OPE.1 Hướng dẫn người dùng vận hành
\r\n\r\nAGD_PRE.1 Các thủ tục chuẩn bị
\r\n\r\n15.2.6.1. Mục tiêu
\r\n\r\nPhân tích điểm yếu có hệ thống được thực hiện\r\nbởi đánh giá viên nhằm xác định chắc chắn sự có mặt của các điểm yếu tiềm ẩn.
\r\n\r\nĐánh giá viên thực hiện việc kiểm thử xâm\r\nnhập để xác nhận rằng các điểm yếu tiềm ẩn không thể bị khai thác trong môi\r\ntrường vận hành TOE. Kiểm thử xâm nhập được thực hiện bởi đánh giá viên áp dụng\r\nkhả năng tấn công ở mức vừa phải.
\r\n\r\n15.2.6.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n15.2.6.2.1. AVA_VAN.4.1D
\r\n\r\nNhà phát triển cần cung cấp TOE cho kiểm thử.
\r\n\r\n15.2.6.3. Các phần tử nội dung và trình bày
\r\n\r\n15.2.6.3.1. AVA_VAN.4.1C
\r\n\r\nTOE cần thích hợp cho kiểm thử.
\r\n\r\n15.2.6.4. Phần tử hành động của đánh giá viên
\r\n\r\n15.2.6.4.1. AVA_VAN.4.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\ncó được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.
\r\n\r\n15.2.6.4.2. AVA_VAN.4.2E
\r\n\r\nĐánh giá viên cần thực hiện việc tìm kiếm các\r\nnguồn thông tin công cộng để nhận biết các điểm yếu tiềm ẩn trong TOE.
\r\n\r\n15.2.6.4.3. AVA_VAN.4.3E
\r\n\r\nĐánh giá viên cần thực hiện phân tích điểm yếu\r\ncó hệ thống, độc lập của OTE sử dụng tài liệu hướng dẫn, đặc tả chức năng, thiết\r\nkế TOE và mô tả kiến trúc an toàn và biểu diễn triển khai để xác định các điểm\r\nyếu tiềm ẩn trong TOE.
\r\n\r\n15.2.6.4.4. AVA_VAN.4.4E
\r\n\r\nĐánh giá viên cần tiến hành việc kiểm thử xâm\r\nnhập dựa trên các điểm yếu tiềm ẩn đã biết để xác nhận rằng TOE được bảo vệ\r\ntrước các tấn công của kẻ tấn công với khả năng tấn công vừa phải.
\r\n\r\n15.2.7. AVA_VAN.5 Phân tích điểm yếu có hệ\r\nthống nâng cao
\r\n\r\nCác phụ thuộc:
\r\n\r\nADV_ARC.1 Mô tả kiến trúc an toàn
\r\n\r\nADV_FSP.2 Đặc tả chức năng thực thi an toàn
\r\n\r\nADV_TDS.3 Thiết kế mô đun cơ bản
\r\n\r\nADV_TMP.1 Biểu diễn triển khai của TSF
\r\n\r\nAGD_OPE.1 Hướng dẫn người dùng vận hành
\r\n\r\nAGD_PRE.1 Các thủ tục chuẩn bị
\r\n\r\n15.2.7.1. Mục tiêu
\r\n\r\nPhân tích điểm yếu có hệ thống được thực hiện\r\nbởi đánh giá viên nhằm xác định chắc chắn sự có mặt của các điểm yếu tiềm ẩn.
\r\n\r\nĐánh giá viên thực hiện việc kiểm thử xâm\r\nnhập để xác nhận rằng các điểm yếu tiềm ẩn không thể bị khai thác trong môi\r\ntrường vận hành TOE. Kiểm thử xâm nhập được thực hiện bởi đánh giá viên áp dụng\r\nkhả năng tấn công ở mức cao.
\r\n\r\n15.2.7.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n15.2.7.2.1. AVA_VAN.5.1D
\r\n\r\nNhà phát triển cần cung cấp TOE cho kiểm thử.
\r\n\r\n15.2.7.3. Các phần tử nội dung và trình bày
\r\n\r\n15.2.7.3.1. AVA_VAN.5.1C
\r\n\r\nTOE cần thích hợp cho kiểm thử.
\r\n\r\n15.2.7.4. Phần tử hành động của đánh giá viên
\r\n\r\n15.2.7.4.1. AVA_VAN.5.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng các thông tin\r\ncó được đã đạt tất cả các yêu cầu về nội dung và hình thức của các chứng cứ.
\r\n\r\n15.2.7.4.2. AVA_VAN.5.2E
\r\n\r\nĐánh giá viên cần thực hiện việc tìm kiếm\r\nthông tin công cộng để nhận biết các điểm yếu tiềm ẩn trong TOE.
\r\n\r\n15.2.7.4.3. AVA_VAN.5.3E
\r\n\r\nĐánh giá viên cần thực hiện phân tích điểm\r\nyếu có hệ thống, độc lập của TOE thông qua tài liệu hướng dẫn, đặc tả chức\r\nnăng, thiết kế TOE, mô tả kiến trúc an toàn và biểu diễn triển khai để xác định\r\ncác điểm yếu tiềm ẩn trong TOE.
\r\n\r\n15.2.7.4.4. AVA_VAN.5.4E
\r\n\r\nĐánh giá viên cần tiến hành việc kiểm thử xâm\r\nnhập dựa trên các điểm yếu tiềm ẩn đã biết để xác nhận rằng TOE được bảo vệ\r\ntrước các tấn công của kẻ tấn công với khả năng tấn công cao.
\r\n\r\n\r\n\r\nLớp tổng hợp ACO bao gồm năm họ. Những họ này\r\nxác định các yêu cầu đảm bảo được thiết kế để đưa ra sự tin cậy về việc một TOE\r\nđược tổng hợp sẽ hoạt động an toàn dựa vào chức năng an toàn cung cấp bởi các\r\nthành phần phần mềm, phần sụn hoặc phần cứng đã được đánh giá trước đó.
\r\n\r\nTổng hợp là việc gộp hai hay nhiều thực thể\r\nCNTT đã được đánh giá thỏa mãn các gói yêu cầu đảm bảo an toàn trong TCVN 8709\r\n(các thành phần cơ sở và thành phần phụ thuộc, xem Phụ lục B) và kết hợp chúng\r\nđể sử dụng không cần phát triển thêm một thực thể CNTT nào khác. Việc phát\r\ntriển thêm các thực thể CNTT không được xét đến (các thực thể chưa được xem xét\r\ntrước đó trong đánh giá thành phần). Các TOE tổng hợp tạo thành một sản phẩm\r\nmới có thể được cài đặt và tích hợp vào bất kỳ môi trường cụ thể nào đáp ứng\r\ncác mục tiêu của môi trường đánh giá.
\r\n\r\nCách tiếp cận này không đưa ra một phương\r\npháp thay thế cho đánh giá thành phần. Tổng hợp thuộc ACO cung cấp một phương\r\npháp cho việc tích hợp TOE tổng hợp, phương pháp này có thể dùng thay thế cho\r\ncác mức đảm bảo khác đã nêu trong TCVN 870, nhằm đạt được sự tin cậy trong một\r\nTOE tạo thành qua kết hợp hai hay nhiều thành phần đã đánh giá tuân thủ mà\r\nkhông cần phải đánh giá lại TSF tổng hợp. (Người tích hợp TOE tổng hợp còn được\r\ngọi là “nhà phát triển” trong toàn bộ lớp ACO, với mọi tham chiếu đến nhà phát\r\ntriển các thành phần cơ sở hoặc thành phần phụ thuộc khi được nêu rõ như vậy).
\r\n\r\nCác gói bảo đảm tổng hợp được định nghĩa tại\r\nđiều khoản 8 và 6.3, là một thang bậc đảm bảo cho các TOE tổng hợp. Thang bậc\r\nđảm bảo này được đòi hỏi thêm cho EAL vì để kết hợp các thành phần đã được đánh\r\ngiá theo EALs và đạt được kết quả bảo đảm theo EAL, tất cả các SAR trong EAL\r\nphải được áp dụng cho các TOE tổng hợp. Dù rằng có thể tái sử dụng các kết quả\r\nđánh giá TOE thành phần, vẫn thường cần xem xét thêm các khía cạnh khác của các\r\nthành phần của TOE tổng hợp, như đã nêu trong Phụ lục B.3. Do trong hoạt động\r\nđánh giá một TOE tổng hợp có sự tham gia của các bên khác nhau, nói chung là\r\nkhông thể có được mọi chứng cứ cần thiết về các khía cạnh khác của các thành\r\nphần này để áp dụng EAL phù hợp. Do đó, các CAPs được định nghĩa nhằm giải\r\nquyết vấn đề về kết hợp các thành phần đã đánh giá và nhằm đạt một kết quả có\r\nnghĩa hơn. Điều này được thảo luận thêm trong Phụ lục B.
\r\n\r\n![](\"00907948_files/image016.jpg\")
Thông thường trong một TOE tổng hợp, một\r\nthành phần dựa trên các dịch vụ do thành phần khác cung cấp. Các thành phần yêu\r\ncầu dịch vụ được gọi là thành phần phụ thuộc và các thành phần cung cấp dịch vụ\r\nđược gọi là thành phần cơ sở. Sự tương tác và phân biệt này được bàn thêm tại\r\nPhụ lục B. Giả thiết là nhà phát triển thành phần phụ thuộc hỗ trợ đánh giá TOE\r\ntheo một số cách thức nào đó (như nhà phát triển, người tài trợ, hoặc chỉ là\r\nhợp tác và cung cấp các chứng cứ đánh giá cần thiết từ việc đánh giá thành phần\r\nphụ thuộc). Các thành phần ACO trong các gói bảo đảm CAP không được sử dụng như\r\nmột sự gia tăng các đánh giá TOE thành phần, vì điều này không đem lại đảm bảo\r\ncó nghĩa cho thành phần.
\r\n\r\nCác họ trong lớp ACO tương tác một cách tương\r\ntự với các lớp ADV, ATE và AVA trong đánh giá TOE thành phần và do đó có thể chịu\r\nảnh hưởng của đặc tả các yêu cầu từ những lớp này. Tuy nhiên, có một số điều\r\nkhoản đặc trưng cho đánh giá TOE tổng hợp. Để xác định cách thức các thành phần\r\ntương tác và tìm ra những sai lệch trong đánh giá các thành phần, cần xác định\r\ncác mối phụ thuộc (ACO_REL) của các thành phần phụ thuộc vào các thành phần cơ sở.\r\nCác mối phụ thuộc vào thành phần cơ sở này được quy định trong điều khoản về\r\ngiao diện qua đó thành phần phụ thuộc gọi các dịch vụ với sự hỗ trợ của các SFR\r\nthành phần phụ thuộc. Các giao diện, và ở mức cao hơn là các hoạt động hỗ trợ,\r\nđược cung cấp bởi các thành phần cơ sở để đáp ứng những yêu cầu dịch vụ được\r\nphân tích trong ACO_DEV. Các họ ACO_DEV dựa trên họ ADV_TDS, do đó tại mức đơn\r\ngiản nhất, TSF của mỗi thành phần có thể được xem như là một hệ thống con của\r\nTOE tổng hợp, với các phần bổ sung thêm cho mỗi thành phần được xem là các hệ\r\nthống con bổ sung. Vì vậy, các giao diện giữa các thành phần được xem là tương\r\ntác giữa các hệ thống con trong đánh giá TOE thành phần.
\r\n\r\nCó thể là các giao diện và mô tả hoạt động hỗ\r\ntrợ cung cấp cho ACO_DEV chưa đầy đủ. Điều này được xác định trong quản lý\r\nACO_COR. Họ ACO_COR nhận kết quả từ ACO_REL và ACO_DEL, xác định việc các thành\r\nphần đang được sử dụng trong cấu hình đánh giá của chúng hay không, và xác định\r\nvị trí đặc tả nào đó chưa đầy đủ, từ đó xác định làm yếu tố đầu vào cho các\r\nhoạt động kiểm thử (ACO_CTT) và phân tích điểm yếu (ACO_VUL) cho TOE tổng hợp.
\r\n\r\nKiểm thử TOE tổng hợp được thực hiện để xác\r\nđịnh rằng các TOE tổng hợp có hoạt động dự kiến như đã xác định bởi các SFRs\r\ncủa TOE tổng hợp và nhằm biểu diễn sự phù hợp của các giao diện giữa các thành\r\nphần của TOE tổng hợp ở các mức cao hơn.
\r\n\r\nCác phân tích điểm yếu của TOE tổng hợp có\r\nđược từ những kết quả đầu ra của phân tích điểm yếu của các đánh giá thành phần.\r\nPhân tích điểm yếu TOE tổng hợp xem xét mọi điểm yếu sẵn có từ các đánh giá thành\r\nphần nhằm xác định rằng các điểm yếu đó không áp dụng cho các TOE tổng hợp.\r\nViệc tìm kiếm thông tin công bố công khai liên quan đến các thành phần cũng\r\nđược thực hiện để xác định ra mọi vấn đề đã báo cáo trong các thành phần sau\r\nkhi hoàn thành đánh giá tương ứng.
\r\n\r\nSự tương tác giữa các họ ACO được mô tả trong\r\nHình 17 dưới đây. Tương tác này thể hiện bằng các đường mũi tên liền nét, trong\r\nđó chứng cứ và hiểu biết về một họ được chuyển vào hoạt động tiếp theo. Các\r\nđường mũi tên đứt nét xác định dấu vết rõ ràng về một hoạt động có từ các SFR\r\ncủa TOE tổng hợp như mô tả ở trên.
\r\n\r\n![](\"00907948_files/image017.jpg\")
Thảo luận thêm về định nghĩa và tương tác\r\ntrong các TOE tổng hợp được đưa ra trong Phụ lục B.
\r\n\r\nHình 18 cho thấy các họ trong lớp này, và\r\nphân cấp các thành phần trong các họ.
\r\n\r\n![](\"00907948_files/image018.gif\")
16.1.1. Mục tiêu
\r\n\r\nHọ này đề cập đến yêu cầu chứng minh rằng\r\nthành phần cơ sở có thể cung cấp một mức độ bảo đảm thích hợp để sử dụng vào\r\nviệc tổng hợp.
\r\n\r\n16.1.2. Phân mức thành phần
\r\n\r\nChỉ có một thành phần duy nhất trong họ này.
\r\n\r\n16.1.3. ACO_COR.1 Sở cứ tổng hợp
\r\n\r\nPhụ thuộc:
\r\n\r\nACO_DEV.1 Mô tả chức năng
\r\n\r\nALC_CMC.1 Ghi nhãn cho TOE
\r\n\r\nACO_REL.1 Thông tin tin cậy cơ bản
\r\n\r\n16.1.3.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n16.1.3.1.1. ACO_COR.1.1D
\r\n\r\nNhà phát triển cần cung cấp sở cứ tổng hợp\r\ncho thành phần cơ sở.
\r\n\r\n16.1.3.2. Các phần tử nội dung và trình bày
\r\n\r\n16.1.3.2.1. ACO_COR.1.1C
\r\n\r\nSở cứ tổng hợp cần biểu thị rằng một mức bảo\r\nđảm ít nhất đạt ngang như mức của thành phần phụ thuộc đã thu được nhằm hỗ trợ\r\nchức năng thành phần cơ sở, khi thành phần cơ sở được cấu hình theo yêu cầu để\r\nhỗ trợ TSF của thành phần phụ thuộc.
\r\n\r\n16.1.3.3. Phần tử hành động của đánh giá viên
\r\n\r\n16.1.3.3.1. ACO_COR.1.1E
\r\n\r\nĐánh giá viên phải xác nhận rằng thông tin\r\nđáp ứng tất cả yêu cầu đối với nội dung và hình thức của chứng cứ.
\r\n\r\n16.2.1. Mục tiêu
\r\n\r\nHọ này đặt ra yêu cầu về đặc tả cho thành\r\nphần cơ sở theo các mức tăng dần về chi tiết. Thông tin này cần có thể đạt được\r\nsự tin cậy về việc chức năng an toàn thích hợp được đưa ra nhằm hỗ trợ yêu cầu\r\ncủa thành phần phụ thuộc (như đã xác định trong thông tin tin cậy).
\r\n\r\n16.2.2. Phân mức thành phần
\r\n\r\nCác thành phần được phân mức trên cơ sở tăng\r\ndần chi tiết về các giao diện đã đưa ra, cách thức chúng được triển khai.
\r\n\r\n16.2.3. Chú thích ứng dụng
\r\n\r\nTSF của thành phần cơ sở thường được xác định\r\nkhông cần biết đến các mối phụ thuộc của các ứng dụng có thể có khi chúng được\r\ntổng hợp. TSF của thành phần cơ sở này được định nghĩa bao gồm tất cả các phần\r\ncủa thành phần cơ sở dựa vào việc thực thi các SFRs của thành phần cơ sở. Điều\r\nđó cũng nghĩa là bao gồm tất cả các phần của thành phần cơ sở cần thiết để\r\ntriển khai các SFRs của thành phần cơ sở.
\r\n\r\nĐặc tả chức năng của thành phần cơ sở sẽ mô\r\ntả TSFI với những điều khoản về giao diện do thành phần cơ sở đưa ra nhằm cho\r\nphép thực thể bên ngoài thực thi các hoạt động của TSF. Nó gồm giao diện với\r\nngười dùng nhằm cho phép tương tác với hoạt động của TSF thực thi các SFRs và\r\ngiao diện cho phép một thực thể CNTT bên ngoài tạo các lời gọi tới TSF.
\r\n\r\nĐặc tả chức năng chỉ mô tả những gì TSF đưa\r\nra ở giao diện của nó và phương thức chức năng TSF được thực hiện. Do đó, đặc\r\ntả chức năng không cần thiết phải cung cấp một đặc tả giao diện đầy đủ cho tất cả\r\ncác giao diện khả thi giữa một thực thể bên ngoài và thành phần cơ sở. Nó không\r\nbao gồm những gì TSF muốn có/yêu cầu từ môi trường hoạt động. Mô tả về những gì\r\nmột TSF thành phần phụ thuộc dựa vào một thành phần cơ sở được xem xét trong\r\nlớp Độ tin cậy của thành phần phụ thuộc (ACO_REL), và chứng cứ thông tin phát\r\ntriển cung cấp phản hồi về các giao diện đã xác định.
\r\n\r\nChứng cứ thông tin phát triển bao gồm một đặc\r\ntả thành phần cơ sở. Đó có thể là chứng cứ sử dụng trong đánh giá thành phần cơ\r\nsở nhằm thỏa mãn các yêu cầu ADV, hoặc có thể là hình thức chứng cứ khác tạo\r\nbởi hoặc nhà phát triển thành phần cơ sở hay nhà phát triển TOE tổng hợp. Đặc\r\ntả thành phần cơ sở được sử dụng trong lớp Chứng cứ phát triển (ACO_DEV) nhằm\r\nđạt được sự tin cậy về việc chức năng an toàn thích hợp được đưa ra để hỗ trợ\r\ncác yêu cầu của thành phần phụ thuộc. Mức chi tiết đòi hỏi của chứng cứ này\r\ntăng dần nhằm phản ánh mức bảo đảm đã yêu cầu trong TOE tổng hợp. Điều này được\r\nmong đợi nhằm phản ánh chung về sự tin cậy tăng dần đạt được từ việc ứng dụng\r\ncác gói đảm bảo cho các thành phần. Đánh giá viên xác định rằng mô tả về thành\r\nphần cơ sở này nhất quán với thông tin tin cậy đã cung cấp cho thành phần phụ\r\nthuộc.
\r\n\r\n16.2.4. ACO_DEV.1 Mô tả chức năng
\r\n\r\nPhụ thuộc: ACO_REL.1 Thông tin tin cậy cơ bản
\r\n\r\n16.2.4.1. Mục tiêu
\r\n\r\nCần có một mô tả về các giao diện trong thành\r\nphần cơ sở làm nền tảng cho thành phần phụ thuộc. Cần kiểm tra để xác định xem\r\nnó nhất quán với mô tả các giao diện làm nền tảng cho thành phần phụ thuộc hay\r\nkhông, như đã cung cấp trong thông tin tin cậy.
\r\n\r\n16.2.4.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n16.2.4.2.1. ACO_DEV.1.1D
\r\n\r\nNhà phát triển cần đưa ra thông tin phát\r\ntriển cho thành phần cơ sở.
\r\n\r\n16.2.4.3. Các thành phần nội dung và trình\r\nbày
\r\n\r\n16.2.4.3.1. ACO_DEV.1.1C
\r\n\r\nThông tin phát triển cần mô tả mục đích mỗi\r\ngiao diện thành phần cơ sở sử dụng trong TOE tổng hợp.
\r\n\r\n16.2.4.3.2. ACO_DEV.1.2C
\r\n\r\nThông tin phát triển cần chỉ ra sự phù hợp\r\ngiữa các giao diện, sử dụng trong TOE tổng hợp, của thành phần cơ sở và thành\r\nphần phụ thuộc nhằm hỗ trợ TSF của thành phần phụ thuộc.
\r\n\r\n16.2.4.4. Phần tử hành động của đánh giá viên
\r\n\r\n16.2.4.4.1. ACO_DEV.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đáp\r\nứng tất cả yêu cầu về nội dung và trình bày của chứng cứ.
\r\n\r\n16.2.4.4.2. ACO_DEV.1.2E
\r\n\r\nĐánh giá viên cần xác định rằng mô tả giao\r\ndiện đã cung cấp nhất quán với thông tin tin cậy đã cung cấp cho thành phần phụ\r\nthuộc.
\r\n\r\n16.2.5. ACO_DEV.2 Chứng cứ cơ bản của thiết\r\nkế
\r\n\r\nPhụ thuộc: ACO_REL.1 Thông tin tin cậy cơ bản
\r\n\r\n16.2.5.1. Mục tiêu
\r\n\r\nCần có một mô tả về các giao diện trong thành\r\nphần cơ sở làm nền tảng cho thành phần phụ thuộc. Cần kiểm tra để xác định xem\r\nnó có nhất quán với mô tả các giao diện làm nền tảng cho thành phần phụ thuộc\r\nhay không, như đã cung cấp trong thông tin tin cậy.
\r\n\r\nNgoài ra, hoạt động an toàn của thành phần cơ\r\nsở có hỗ trợ thành phần phụ thuộc TSF được mô tả.
\r\n\r\n16.2.5.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n16.2.5.2.1. ACO_DEV.2.1D
\r\n\r\nNhà phát triển cần đưa ra thông tin phát\r\ntriển cho thành phần cơ sở.
\r\n\r\n16.2.5.3. Các phần tử nội dung và trình bày
\r\n\r\n16.2.5.3.1. ACO_DEV.2.1C
\r\n\r\nCác thông tin phát triển sẽ mô tả các mục\r\nđích và phương pháp sử dụng của từng giao diện thành phần cơ sở được sử\r\ndụng trong TOE tổng hợp.
\r\n\r\n16.2.5.3.2. ACO_DEV.2.2C
\r\n\r\nThông tin phát triển cần đưa ra mô tả mức cao\r\nvề hoạt động của thành phần cơ sở hỗ trợ việc thực thi các SFRs của thành phần\r\nphụ thuộc.
\r\n\r\n16.2.5.3.3. ACO_DEV.2.3C
\r\n\r\nThông tin phát triển cần chỉ ra sự phù hợp giữa\r\ncác giao diện, sử dụng trong TOE tổng hợp, của thành phần cơ sở và thành phần\r\nphụ thuộc nhằm hỗ trợ TSF của thành phần phụ thuộc.
\r\n\r\n16.2.5.4. Phần tử hành động của đánh giá viên
\r\n\r\n16.2.5.4.1. ACO_DEV.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đáp\r\nứng tất cả yêu cầu về nội dung và trình bày của chứng cứ.
\r\n\r\n16.2.5.4.2. ACO_DEV.2.2E
\r\n\r\nĐánh giá viên cần xác định rằng mô tả giao\r\ndiện đã cung cấp nhất quán với thông tin tin cậy đã cung cấp cho thành phần phụ\r\nthuộc.
\r\n\r\n16.2.6. ACO_DEV.3 Chứng cứ chi tiết của thiết\r\nkế
\r\n\r\nPhụ thuộc: ACO_REL.2 Thông tin tin cậy
\r\n\r\n16.2.6.1. Mục tiêu
\r\n\r\nCần có một mô tả về các giao diện trong thành\r\nphần cơ sở làm nền tảng cho thành phần phụ thuộc. Cần kiểm tra để xác định xem\r\nnó có nhất quán với mô tả các giao diện làm nền tảng cho thành phần phụ thuộc\r\nhay không, như đã cung cấp trong thông tin tin cậy.
\r\n\r\nMô tả giao diện kiến trúc của thành phần cơ\r\nsở được cung cấp để cho phép đánh giá viên xác định giao diện này có tạo thành\r\nmột phần của TSF của thành phần cơ sở hay không.
\r\n\r\n16.2.6.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n16.2.6.2.1. ACO_DEV.3.1D
\r\n\r\nNhà phát triển cần đưa ra thông tin phát\r\ntriển cho thành phần cơ sở.
\r\n\r\n16.2.6.3. Các phần tử nội dung và trình bày
\r\n\r\n16.2.6.3.1. ACO_DEV.3.1C
\r\n\r\nCác thông tin phát triển sẽ mô tả các mục\r\nđích và phương pháp sử dụng của từng giao diện thành phần cơ sở được sử dụng\r\ntrong TOE tổng hợp.
\r\n\r\n16.2.6.3.2. ACO_DEV.3.2C
\r\n\r\nThông tin phát triển cần xác định các hệ\r\nthống con của thành phần cơ sở, cung cấp các giao diện của thành phần cơ sở\r\ndùng trong TOE tổng hợp.
\r\n\r\n16.2.6.3.3. ACO_DEV.3.3C
\r\n\r\nThông tin phát triển cần đưa ra mô tả mức cao\r\nvề hoạt động của thành phần cơ sở hỗ trợ việc thực thi các SFRs của thành phần\r\nphụ thuộc.
\r\n\r\n16.2.6.3.4. ACO_DEV.3.4C
\r\n\r\nThông tin phát triển cần cung cấp một ánh xạ\r\ntừ các giao diện tới các hệ thống con của thành phần cơ sở.
\r\n\r\n16.2.6.3.5. ACO_DEV.3.5C
\r\n\r\nThông tin phát triển cần chỉ ra sự phù hợp\r\ngiữa các giao diện, sử dụng trong TOE tổng hợp, của thành phần cơ sở và thành\r\nphần phụ thuộc nhằm hỗ trợ TSF của thành phần phụ thuộc.
\r\n\r\n16.2.6.4. Phần tử hành động của đánh giá viên
\r\n\r\n16.2.6.4.1. ACO_DEV.3.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đáp\r\nứng tất cả yêu cầu về nội dung và trình bày của chứng cứ.
\r\n\r\n16.2.6.4.2. ACO_DEV.3.2E
\r\n\r\nĐánh giá viên cần xác định rằng mô tả giao\r\ndiện đã cung cấp nhất quán với thông tin tin cậy đã cung cấp cho thành phần phụ\r\nthuộc.
\r\n\r\n16.3.1. Mục tiêu
\r\n\r\nMục đích của họ này là cung cấp chứng cứ mô\r\ntả sự tin cậy mà một thành phần phụ thuộc có được khi dựa vào thành phần cơ sở.\r\nThông tin này hữu ích để người có trách nhiệm tích hợp thành phần với các thành\r\nphần CNTT đã được đánh giá khác nhằm tạo ra TOE tổng hợp, và cung cấp chi tiết\r\nvề các đặc tính an toàn của sản phẩm tổng hợp.
\r\n\r\nHọ này đưa ra mô tả về giao diện giữa thành\r\nphần phụ thuộc và thành phần cơ sở của TOE tổng hợp. Giao diện này có thể không\r\nđược phân tích trong đánh giá từng thành phần, vì các giao diện không phải là\r\nTSFIs của các TOE thành phần riêng lẻ.
\r\n\r\n16.3.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức\r\ntương ứng với số lượng chi tiết cung cấp trong mô tả về sự tin cậy của thành\r\nphần phụ thuộc vào thành phần cơ sở.
\r\n\r\n16.3.3. Chú thích ứng dụng
\r\n\r\nHọ “Sự tin cậy của thành phần phụ thuộc”\r\n(ACO_REL) xem xét tương tác giữa các thành phần, trong đó thành phần phụ thuộc\r\ndựa vào một dịch vụ của thành phần cơ sở để hỗ trợ hoạt động của chức năng an\r\ntoàn của thành phần phụ thuộc. Các giao diện tới các dịch vụ này của thành phần\r\ncơ sở có thể đã không được xem xét trong đánh giá thành phần cơ sở do dịch vụ\r\ntrong thành phần cơ sở đã không được xem xét tính an toàn liên quan trong đánh\r\ngiá thành phần, hoặc vì mục đích kế thừa của dịch vụ (ví dụ, điều chỉnh kiểu\r\nfont) hoặc bởi vì các SFRs liên quan tới TCVN 8709 đã không được yêu cầu trong\r\nST của thành phần cơ sở (ví dụ giao diện đăng nhập khi không có yêu cầu về\r\n“FIA: các SFRs định danh và xác thực” theo TCVN 8709-2). Các giao diện tới\r\nthành phần cơ sở này thường được xem như giao diện chức năng trong đánh giá\r\nthành phần cơ sở, và xem xét thêm trong đặc tả chức năng cùng với các giao diện\r\nan toàn (TSFI).
\r\n\r\nTóm lại, các TSFI được mô tả trong đặc tả\r\nchức năng chỉ bao gồm các lời gọi vào một TSF thực hiện bởi các thực thể bên\r\nngoài và phản hồi với các lời gọi này. Các lời gọi thực hiện bởi một TSF không\r\nđược xem xét rõ ràng trong đánh giá các thành phần, sẽ được mô tả bởi thông tin\r\ntin cậy đưa ra nhằm thỏa mãn lớp “Sự tin cậy của thành phần phụ thuộc”\r\n(ACO_REL).
\r\n\r\n16.3.4. ACO_REL.1 Thông tin tin cậy cơ bản
\r\n\r\nCác mối phụ thuộc: không có sự phụ thuộc nào.
\r\n\r\n16.3.4.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n16.3.4.1.1. ACO_REL.1.1D
\r\n\r\nNhà phát triển cung cấp thông tin tin cậy của\r\nthành phần phụ thuộc.
\r\n\r\n16.3.4.2. Các phần tử nội dung và trình bày
\r\n\r\n16.3.4.2.1. ACO_REL.1.1C
\r\n\r\nThông tin tin cậy cần mô tả chức năng của\r\nthành phần cơ sở như phần cứng, phần sụn và/hoặc phần mềm làm nền tảng cho TSF\r\ncủa thành phần phụ thuộc.
\r\n\r\n16.3.4.2.2. ACO_REL.1.2C
\r\n\r\nThông tin tin cậy cần mô tả tất cả các tương\r\ntác thông qua đó TSF của thành phần phụ thuộc yêu cầu dịch vụ từ thành phần cơ\r\nsở.
\r\n\r\n16.3.4.2.3. ACO_REL.1.3C
\r\n\r\nThông tin tin cậy cần mô tả cách thức TSF phụ\r\nthuộc tự bảo vệ trước sự can thiệp và giả mạo của thành phần cơ sở.
\r\n\r\n16.3.4.3. Phần tử hành động của đánh giá viên
\r\n\r\n16.3.4.3.1. ACO_REL.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đã\r\ncung cấp đáp ứng mọi yêu cầu cho nội dung và hình thức của chứng cứ.
\r\n\r\n16.3.5. ACO_REL.2 Thông tin tin cậy
\r\n\r\nCác mối phụ thuộc: không có sự phụ thuộc nào.
\r\n\r\n16.3.5.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n16.3.5.1.1. ACO_REL.2.1D
\r\n\r\nNhà phát triển cần cung cấp thông tin tin cậy\r\ncủa thành phần phụ thuộc.
\r\n\r\n16.3.5.2. Các phần tử nội dung và trình bày
\r\n\r\n16.3.5.2.1. ACO_REL.2.1C
\r\n\r\nThông tin tin cậy cần mô tả chức năng của\r\nthành phần cơ sở như phần cứng, phần sụn và/hoặc phần mềm nền tảng cho TSF của\r\nthành phần phụ thuộc.
\r\n\r\n16.3.5.2.2. ACO_REL.2.2C
\r\n\r\nThông tin tin cậy cần mô tả tất cả các tương\r\ntác thông qua đó TSF của thành phần phụ thuộc yêu cầu dịch vụ từ thành phần cơ\r\nsở.
\r\n\r\n16.3.5.2.3. ACO_REL.2.3C
\r\n\r\nThông tin tin cậy cần mô tả từng tương tác về\r\ngiao diện sử dụng và trả lại giá trị từ những giao diện đó.
\r\n\r\n16.3.5.2.4. ACO_REL.2.4C
\r\n\r\nThông tin tin cậy cần mô tả cách thức TSF phụ\r\nthuộc tự bảo vệ trước sự can thiệp và giả mạo của thành phần cơ sở.
\r\n\r\n16.3.5.3. Phần tử hành động của đánh giá viên
\r\n\r\n16.3.5.3.1. ACO_REL.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đã\r\ncung cấp đáp ứng mọi yêu cầu cho nội dung và hình thức của chứng cứ.
\r\n\r\n16.4.1. Mục tiêu
\r\n\r\nHọ này đòi hỏi thực hiện kiểm thử TOE tổng\r\nhợp và kiểm thử thành phần cơ sở, khi được sử dụng trong TOE tổng hợp.
\r\n\r\n16.4.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức\r\ntrên cơ sở mức chặt chẽ tăng dần của kiểm thử giao diện và mức chặt chẽ tăng\r\ndần của phân tích tính đầy đủ của các kiểm thử nhằm thể hiện rằng TSF hoạt động\r\ntương ứng với thông tin tin cậy và các SFRs của TOE tổng hợp.
\r\n\r\n16.4.3. Chú thích ứng dụng
\r\n\r\nCó hai khía cạnh khác biệt của kiểm thử liên\r\nquan tới họ này:
\r\n\r\na) Kiểm thử các giao diện giữa thành phần cơ\r\nsở và thành phần phụ thuộc, mà thành phần phụ thuộc dựa vào đó để thực thi chức\r\nnăng an toàn, nhằm thể hiện tính tương thích của chúng.
\r\n\r\nb) Kiểm thử TOE tổng hợp để thể hiện rằng TOE\r\nứng xử tương ứng với các SFRs của TOE tổng hợp.
\r\n\r\nNếu các cấu hình kiểm thử dùng trong đánh giá\r\nthành phần phụ thuộc bao gồm việc sử dụng thành phần cơ bản làm “một nền tảng”\r\nvà việc phân tích kiểm thử đủ để thể hiện rằng TSF tuân thủ với SFRs, nhà phát\r\ntriển sẽ không cần thực hiện thêm kiểm thử nào nữa cho chức năng của TOE tổng\r\nhợp. Tuy nhiên, nếu thành phần cơ sở đã không được sử dụng trong kiểm thử thành\r\nphần phụ thuộc, hay cấu hình của một trong hai thành phần thay đổi, khi đó nhà\r\nphát triển cần thực hiện kiểm thử cho TOE tổng hợp. Điều đó có thể dẫn đến hình\r\nthức nhà phát triển lặp lại các kiểm thử cho thành phần phụ thuộc nhằm đưa ra\r\nbằng chứng phù hợp về việc TOE tổng hợp tuân thủ với các SFRs.
\r\n\r\nNhà phát triển cần đưa ra chứng cứ về kiểm\r\nthử các giao diện thành phần cơ sở đã dùng khi tổng hợp. Hoạt động của TSFIs\r\ncủa thành phần cơ sở có thể đã được kiểm thử trong một phần của lớp ATE: “Các\r\nhoạt động kiểm thử” trong đánh giá thành phần cơ sở. Vì vậy, nếu các giao diện\r\nthích hợp đã được đưa vào mẫu kiểm thử trong đánh giá thành phần cơ sở và trong\r\nlớp “Sở cứ tổng hợp (ACO_COR) đã xác định rằng thành phần cơ sở đang hoạt động\r\ntuân theo cấu hình thành phần cơ sở đã đánh giá, với việc mọi chức năng an toàn\r\nđòi hỏi bởi thành phần cơ sở đã có trong TSF, thì hành động của đánh giá viên\r\nACO_CTT.1.1E có thể thỏa mãn thông qua việc tái sử dụng thành phần cơ sở ATE:\r\nQuyết định kiểm thử.
\r\n\r\nNếu không phải như vậy thì các giao diện\r\nthành phần cơ sở đã dùng tương ứng cho tổng hợp với sự ảnh hưởng bởi mọi biến\r\nđổi về cấu hình đánh giá và mọi chức năng an toàn bổ sung sẽ được kiểm thử nhằm\r\nđảm bảo chúng thể hiện hoạt động như mong đợi. Hoạt động mong đợi được kiểm thử\r\nlà hoạt động đã được mô tả trong thông tin tin cậy (bằng chứng về Sự tin cậy\r\ncủa thành phần phụ thuộc (ACO_REL)).
\r\n\r\n16.4.4. ACO_CTT.1 Kiểm thử giao diện
\r\n\r\nPhụ thuộc:
\r\n\r\nACO_REL.1 Thông tin tin cậy cơ bản
\r\n\r\nACO_DEV.1 Mô tả chức năng
\r\n\r\n16.4.4.1. Mục tiêu
\r\n\r\nMục tiêu của thành phần này là nhằm đảm bảo\r\nrằng mỗi giao diện của thành phần cơ sở, mà thành phần phụ thuộc dựa vào đó,\r\nđược kiểm thử.
\r\n\r\n16.4.4.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n16.4.4.2.1. ACO_CTT.1.1D
\r\n\r\nNhà phát triển cần đưa ra tài liệu kiểm thử\r\nTOE tổng hợp.
\r\n\r\n16.4.4.2.2. ACO_CTT.1.2D
\r\n\r\nNhà phát triển cần đưa ra tài liệu kiểm thử\r\ngiao diện thành phần cơ sở.
\r\n\r\n16.4.4.2.3. ACO_CTT.1.3D
\r\n\r\nNhà phát triển cần đưa ra TOE tổng hợp để\r\nkiểm thử.
\r\n\r\n16.4.4.2.4. ACO_CTT.1.4D
\r\n\r\nNhà phát triển cần đưa ra một tập tài nguyên\r\ntương đương với tập dùng trong kiểm thử chức năng thành phần cơ sở của nhà phát\r\ntriển.
\r\n\r\n16.4.4.3. Các phần tử nội dung và trình bày
\r\n\r\n16.4.4.3.1. ACO_CTT.1.1C
\r\n\r\nTài liệu kiểm thử cho TOE tổng hợp và giao\r\ndiện thành phần cơ sở cần bao gồm kế hoạch kiếm thử, kết quả kiểm thử dự kiến\r\nkết quả kiểm thử thực tế.
\r\n\r\n16.4.4.3.2. ACO_CTT.1.2C
\r\n\r\nTài liệu kiểm thử có được từ việc nhà phát\r\ntriển thực hiện kiểm thử TOE tổng hợp cần chứng tỏ rằng TSF tuân thủ theo quy\r\nđịnh.
\r\n\r\n16.4.4.3.3. ACO_CTT.1.3C
\r\n\r\nTài liệu kiểm thử có được từ việc nhà phát\r\ntriển thực hiện kiểm thử thành phần cơ sở cần chứng tỏ rằng giao diện thành\r\nphần cơ sở mà thành phần cơ sở dựa vào tuân thủ theo quy định.
\r\n\r\n16.4.4.3.4. ACO_CTT.1.4C
\r\n\r\nThành phần cơ sở cần thích hợp cho kiểm thử.
\r\n\r\n16.4.4.4. Phần tử hành động của đánh giá viên
\r\n\r\n16.4.4.4.1. ACO_CTT.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đã\r\ncung cấp đáp ứng mọi yêu cầu cho nội dung và hình thức của chứng cứ.
\r\n\r\n16.4.4.4.2. ACO_CTT.1.2E
\r\n\r\nĐánh giá viên cần thực hiện một kiểm thử mẫu\r\ntrong tài liệu kiểm thử để kiểm nghiệm các kết quả kiểm thử của nhà phát triển.
\r\n\r\n16.4.4.4.3. ACO_CTT.1.3E
\r\n\r\nĐánh giá viên cần kiểm thử một tập con các\r\ngiao diện TSF của TOE tổng hợp để khẳng định rằng TSF tổng hợp hoạt động theo\r\nquy định.
\r\n\r\n16.4.5. ACO_CTT.2 Kiểm thử giao diện chặt chẽ
\r\n\r\nPhụ thuộc:
\r\n\r\nACO_REL.2 Thông tin tin cậy
\r\n\r\nACO_DEV.2 Chứng cứ cơ bản của thiết kế.
\r\n\r\n16.4.5.1. Mục tiêu
\r\n\r\nMục tiêu của thành phần này là để đảm bảo\r\nrằng mỗi giao diện của thành phần cơ sở, mà thành phần phụ thuộc dựa vào nó,\r\nđược kiểm thử.
\r\n\r\n16.4.5.2. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n16.4.5.2.1. ACO_CTT.2.1D
\r\n\r\nNhà phát triển cần đưa ra tài liệu kiểm thử\r\nTOE tổng hợp.
\r\n\r\n16.4.5.2.2. ACO_CTT.2.2D
\r\n\r\nNhà phát triển cần đưa ra tài liệu kiểm thử\r\ngiao diện thành phần cơ sở.
\r\n\r\n16.4.5.2.3. ACO_CTT.2.3D
\r\n\r\nNhà phát triển cần đưa ra TOE tổng hợp để\r\nkiểm thử.
\r\n\r\n16.4.5.2.4. ACO_CTT.2.4D
\r\n\r\nNhà phát triển cần đưa ra một tập tài nguyên\r\ntương đương với tập dùng trong kiểm thử chức năng thành phần cơ sở của nhà phát\r\ntriển.
\r\n\r\n16.4.5.3. Các phần tử nội dung và trình bày
\r\n\r\n16.4.5.3.1. ACO_CTT.2.1C
\r\n\r\nTài liệu kiểm thử cho TOE tổng hợp và giao\r\ndiện thành phần cơ sở cần bao gồm kế hoạch kiểm thử, kết quả kiểm thử dự kiến\r\nkết quả kiểm thử thực tế.
\r\n\r\n16.4.5.3.2. ACO_CTT.2.2C
\r\n\r\nTài liệu kiểm thử có được từ việc nhà phát\r\ntriển thực hiện kiểm thử TOE tổng hợp cần chứng tỏ rằng TSF tuân thủ theo quy\r\nđịnh và đầy đủ.
\r\n\r\n16.4.5.3.3. ACO_CTT.2.3C
\r\n\r\nTài liệu kiểm thử có được từ việc nhà phát\r\ntriển thực hiện kiểm thử thành phần cơ sở cần chứng tỏ rằng giao diện thành\r\nphần cơ sở mà thành phần cơ sở dựa vào tuân thủ theo quy định và đầy đủ.
\r\n\r\n16.4.5.3.4. ACO_CTT.2.4C
\r\n\r\nThành phần cơ sở cần thích hợp cho kiểm thử.
\r\n\r\n16.4.5.4. Phần tử hành động của đánh giá viên
\r\n\r\n16.4.5.4.1. ACO_CTT.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đã\r\ncung cấp đáp ứng mọi yêu cầu cho nội dung và hình thức của chứng cứ.
\r\n\r\n16.4.5.4.2. ACO_CTT.2.2E
\r\n\r\nĐánh giá viên cần thực hiện một kiểm thử mẫu\r\ntrong tài liệu kiểm thử để kiểm nghiệm các kết quả kiểm thử của nhà phát triển.
\r\n\r\n16.4.5.4.3. ACO_CTT.2.3E
\r\n\r\nĐánh giá viên cần kiểm thử một tập con các\r\ngiao diện TSF của TOE tổng hợp để khẳng định rằng TSF tổng hợp hoạt động theo\r\nquy định.
\r\n\r\n16.5.1. Mục tiêu
\r\n\r\nHọ này dùng cho phân tích thông tin điểm yếu\r\nsẵn có thông báo công khai và các điểm yếu có thể sẽ nảy sinh khi tổng hợp.
\r\n\r\n16.5.2. Phân mức thành phần
\r\n\r\nCác thành phần trong họ này được phân mức\r\ntrên cơ sở khảo sát kỹ lưỡng với mức tăng dần thông tin điểm yếu đã thông báo\r\ncông khai và phân tích điểm yếu một cách độc lập.
\r\n\r\n16.5.3. Chú thích ứng dụng
\r\n\r\nNhà phát triển sẽ cung cấp chi tiết của mọi\r\nđiểm yếu còn lại ghi nhận trong đánh giá các thành phần. Điều này có thể đạt\r\nđược từ các nhà phát triển thành phần hoặc từ các báo cáo đánh giá thành phần.\r\nNhững thông tin này sẽ được sử dụng làm đầu vào cho phân tích điểm yếu của TOE\r\ntổng hợp trong môi trường vận hành.
\r\n\r\nMôi trường vận hành của TOE tổng hợp được\r\nkiểm tra nhằm đảm bảo rằng các giả định và mục tiêu cho môi trường vận hành\r\nthành phần (quy định cho từng ST thành phần) được thỏa mãn trong TOE tổng hợp.\r\nMột phân tích ban đầu về tính nhất quán của các giả định và mục tiêu giữa các\r\nthành phần và các STs của TOE tổng hợp sẽ được thực hiện trong khi tiến hành\r\ncác hoạt động ASE cho TOE tổng hợp. Tuy nhiên, việc phân tích này được nhắc lại\r\nvới những hiểu biết thu được trong các hoạt động ACO_REL, ACO_DEV và ACO_COR\r\nnhằm đảm bảo rằng, ví dụ, các giả định về thành phần phụ thuộc đã được đề cập\r\nđến trong môi trường trong ST của thành phần phụ thuộc sẽ không được nhắc lại\r\ntrong kết quả tổng hợp (nghĩa là thành phần cơ sở đề cập một cách tương xứng\r\ncác giả định về ST của thành phần phụ thuộc trong TOE tổng hợp).
\r\n\r\nĐánh giá viên sẽ tìm kiếm các vấn đề trong\r\nmỗi thành phần, xác định các điểm yếu tiềm ẩn đã thông báo trên phạm vi công\r\ncộng sau khi hoàn tất đánh giá các thành phần. Mọi điểm yếu tiềm ẩn sẽ được\r\nkiểm thử.
\r\n\r\nNếu thành phần cơ sở đã dùng trong TOE tổng\r\nhợp trở thành chủ đề của các hoạt động duy trì bảo đảm từ khi có chứng nhận,\r\nđánh giá viên sẽ xem xét trong các hoạt động phân tích điểm yếu của TOE tổng\r\nhợp những thay đổi đã thực hiện trong thành phần cơ sở.
\r\n\r\n16.5.4. ACO_VUL.1 Soát xét điểm yếu tổng hợp
\r\n\r\nPhụ thuộc: ACO_DEV.1 Mô tả chức năng
\r\n\r\n16.5.4.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n16.5.4.1.1. ACO_VUL.1.1D
\r\n\r\nNhà phát triển cần đưa ra TOE tổng hợp để\r\nkiểm thử.
\r\n\r\n16.5.4.2. Các phần tử nội dung và trình bày
\r\n\r\n16.5.4.2.1. ACO_VUL.1.1C
\r\n\r\nTOE tổng hợp cần thích hợp cho kiểm thử.
\r\n\r\n16.5.4.3. Phần tử hành động của đánh giá viên
\r\n\r\n16.5.4.3.1. ACO_VUL.1.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đã\r\ncung cấp đáp ứng mọi yêu cầu cho nội dung và hình thức của chứng cứ.
\r\n\r\n16.5.4.3.2. ACO_VUL.1.2E
\r\n\r\nĐánh giá viên cần thực hiện phân tích nhằm\r\nxác định mọi điểm yếu vốn có xác định cho thành phần cơ sở và thành phần phụ\r\nthuộc không bị khai thác trong TOE tổng hợp và môi trường vận hành của nó.
\r\n\r\n16.5.4.3.3. ACO_VUL.1.3E
\r\n\r\nĐánh giá viên cần thực hiện tìm kiếm các\r\nnguồn thông tin công cộng để xác định các điểm yếu có thể phát sinh từ việc\r\ndùng các thành phần cơ sở và thành phần phụ thuộc trong môi trường vận hành TOE\r\ntổng hợp.
\r\n\r\n16.5.4.3.4. ACO_VUL.1.4E
\r\n\r\nĐánh giá viên cần tiến hành kiểm thử xâm\r\nnhập, dựa trên các điểm yếu đã xác định, để chứng minh rằng TOE tổng hợp được\r\nbảo vệ trước các tấn công bởi kẻ tấn công có tiềm năng tấn công cơ bản.
\r\n\r\n16.5.5. ACO_VUL.2 Phân tích điểm yếu tổng hợp
\r\n\r\nPhụ thuộc: ACO_DEV.2 Chứng cứ cơ bản của\r\nthiết kế
\r\n\r\n16.5.5.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n16.5.5.1.1. ACO_VUL.2.1D
\r\n\r\nNhà phát triển cần đưa ra TOE tổng hợp để\r\nkiểm thử.
\r\n\r\n16.5.5.2. Các phần tử nội dung và trình bày
\r\n\r\n16.5.5.2.1. ACO_VUL.2.1C
\r\n\r\nTOE tổng hợp cần thích hợp cho kiểm thử.
\r\n\r\n16.5.5.3. Phần tử hành động của đánh giá viên
\r\n\r\n16.5.5.3.1. ACO_VUL.2.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đã\r\ncung cấp đáp ứng mọi yêu cầu cho nội dung và hình thức của chứng cứ.
\r\n\r\n16.5.5.3.2. ACO_VUL.2.2E
\r\n\r\nĐánh giá viên cần thực hiện phân tích nhằm\r\nxác định mọi điểm yếu vốn có xác định cho thành phần cơ sở và thành phần phụ\r\nthuộc không bị khai thác trong TOE tổng hợp và môi trường vận hành của nó.
\r\n\r\n16.5.5.3.3. ACO_VUL.2.2E
\r\n\r\nĐánh giá viên cần thực hiện tìm kiếm các\r\nnguồn thông tin công cộng để xác định các điểm yếu có thể phát sinh từ việc\r\ndùng các thành phần cơ sở và thành phần phụ thuộc trong môi trường vận hành TOE\r\ntổng hợp.
\r\n\r\n16.5.5.3.4. ACO_VUL.2.4E
\r\n\r\nĐánh giá viên cần thực hiện phân tích điểm\r\nyếu độc lập cho TOE tổng hợp thông qua sử dụng tài liệu hướng dẫn, thông tin\r\ntin cậy và sở cứ tổng hợp nhằm xác định các điểm yếu tiềm ẩn trong TOE tổng\r\nhợp.
\r\n\r\n16.5.5.3.5. ACO_VUL.2.5E
\r\n\r\nĐánh giá viên cần tiến hành kiểm thử xâm\r\nnhập, dựa trên các điểm yếu đã xác định, để chứng minh rằng TOE tổng hợp được\r\nbảo vệ trước các tấn công bởi kẻ tấn công có tiềm năng tấn công cơ bản.
\r\n\r\n16.5.6. ACO_VUL.3 Phân tích điểm yếu tổng hợp\r\ncơ bản - nâng cao
\r\n\r\nPhụ thuộc: ACO_DEV.3 Chứng cứ chi tiết về\r\nthiết kế
\r\n\r\n16.5.6.1. Phần tử hành động của nhà phát\r\ntriển
\r\n\r\n16.5.6.1.1. ACO_VUL.3.1D
\r\n\r\nNhà phát triển cần đưa ra TOE tổng hợp để\r\nkiểm thử.
\r\n\r\n16.5.6.2. Các phần tử nội dung và trình bày
\r\n\r\n16.5.6.2.1. ACO_VUL.3.1C
\r\n\r\nTOE tổng hợp cần thích hợp cho kiểm thử
\r\n\r\n16.5.6.3. Phần tử hành động của đánh giá viên
\r\n\r\n16.5.6.3.1. ACO_VUL.3.1E
\r\n\r\nĐánh giá viên cần xác nhận rằng thông tin đã\r\ncung cấp đáp ứng mọi yêu cầu cho nội dung và hình thức của chứng cứ.
\r\n\r\n16.5.6.3.2. ACO_VUL.3.2E
\r\n\r\nĐánh giá viên cần thực hiện phân tích nhằm\r\nxác định mọi điểm yếu vốn có xác định cho thành phần cơ sở và thành phần phụ\r\nthuộc không bị khai thác trong TOE tổng hợp và môi trường vận hành của nó.
\r\n\r\n16.5.6.3.3. ACO_VUL.3.3E
\r\n\r\nĐánh giá viên cần thực hiện tìm kiếm các\r\nnguồn thông tin công cộng để xác định các điểm yếu có thể phát sinh từ việc\r\ndùng các thành phần cơ sở và thành phần phụ thuộc trong môi trường vận hành TOE\r\ntổng hợp.
\r\n\r\n16.5.6.3.4. ACO_VUL.3.4E
\r\n\r\nĐánh giá viên cần thực hiện phân tích điểm\r\nyếu độc lập cho TOE tổng hợp thông qua sử dụng tài liệu hướng dẫn, thông tin\r\ntin cậy và sở cứ tổng hợp nhằm xác định các điểm yếu tiềm ẩn trong TOE tổng\r\nhợp.
\r\n\r\n16.5.6.3.5. ACO_VUL.3.5E
\r\n\r\nĐánh giá viên cần tiến hành kiểm thử xâm\r\nnhập, dựa trên các điểm yếu đã xác định, để chứng minh rằng TOE tổng hợp được\r\nbảo vệ trước các tấn công bởi kẻ tấn công có tiềm năng tấn công cơ bản.
\r\n\r\nPhụ lục này có chứa tài liệu phụ trợ để tiếp\r\ntục giải thích và cung cấp các ví dụ bổ sung cho các chủ đề đưa ra trong các họ\r\ncủa lớp ADV: Lớp Phát triển.
\r\n\r\nA.1. ADV_ARC: Bổ sung các tài liệu trên kiến\r\ntrúc an toàn
\r\n\r\nMột kiến trúc an toàn là một bộ các thuộc\r\ntính mà TSF trình bày; những thuộc tính này bao gồm tự bảo vệ, tách miền, và\r\nnon-bypassability. Có những thuộc tính cung cấp cơ sở tin cậy để TSF cung cấp\r\nnhững dịch vụ an toàn của nó. Phụ lục này cung cấp tài liệu bổ sung trên các\r\nthuộc tính đó, cũng như những thảo luận về nội dung của một mô tả kiến trúc an\r\ntoàn.
\r\n\r\nNgoài ra mục này, trước hết sẽ giải thích\r\nnhững thuộc tính đó, sau đó thảo luận về những loại thông tin cần thiết để mô\r\ntả cách TSF trình bày những thuộc tính đó.
\r\n\r\nA.1.1. Các thuộc tính trong kiến trúc an toàn
\r\n\r\nTự bảo vệ đề cập đến khả năng TSF bảo vệ cho\r\nchính nó bằng thao tác từ các thực thể bên ngoài mà vẫn có thể dẫn đến những\r\nthay đổi trong TSF. Nếu thiếu những thuộc tính này, các TSF có thể bị vô hiệu\r\nhóa khi thực hiện các dịch vụ an toàn của nó.
\r\n\r\nĐôi khi có trường hợp mà một TOE sử dụng các\r\ndịch vụ hoặc nguồn tài nguyên cung cấp bởi các thực thể CNTT khác để thực hiện\r\nchức năng của nó (ví dụ như một ứng dụng dựa trên hệ điều hành cơ bản của nó).\r\nTrong những trường hợp này, các TSF không tự bảo vệ mình hoàn toàn, bởi vì nó\r\nphụ thuộc vào các thực thể IT khác để bảo vệ các dịch vụ nó sử dụng.
\r\n\r\nTách miền là một thuộc tính theo đó TSF tạo\r\nra các miền an toàn riêng cho từng thực thể hành động không tin cậy để hoạt\r\nđộng trên tài nguyên của nó, và sau đó giữ những miền đó được tách biệt khỏi\r\nnhững thực thể còn lại để không thực thể nào có thể chạy trên miền của bất kỳ\r\nthực thể khác. Ví dụ, một TOE hệ điều hành sẽ cấp một tên miền (không gian địa\r\nchỉ, biến môi trường trên một tiến trình) cho từng tiến trình liên kết với các\r\nthực thể không tin cậy.
\r\n\r\nĐối với một số TOE tên miền không tồn tại vì\r\ntất cả các hành động của các thực thể không tin cậy được đưa ra bởi TSF. Một\r\nbức tường lửa lọc gói là một ví dụ của TOE như vậy, nơi không có những tên miền\r\ncủa thực thể không tin cậy; chỉ có những cấu trúc dữ liệu chỉ được duy trì bởi\r\ncác TSF. Trong trường hợp mà ở đó TOE không cung cấp tên miền cho những thực\r\nthể không tin cậy, họ này yêu cầu những tên miền đó phải được cô lập khỏi những\r\nmiền khác, như vậy những thực thể không tin cậy trong một miền bị ngăn chặn việc\r\ngiả mạo từ các miền khác của thực thể không tin cậy.
\r\n\r\nNon-bypassability là một thuộc tính mà các\r\nchức năng an toàn của TSF (đặc tả bởi SFR) luôn được yêu cầu và không thể bị\r\nphá vỡ, thích hợp cho cơ chế cụ thể. Ví dụ, nếu việc điều khiển truy cập vào\r\ncác tệp được quy định như một khả năng của TSF qua một SFR, thì không cần có\r\ngiao diện mà thông qua đó các tập tin có thể được truy cập mà không cần viện\r\ndẫn cơ chế điều khiển truy cập của TSF.
\r\n\r\nNhư là trường hợp tự bảo vệ, chính bản chất\r\ncủa một số TOE có thể phụ thuộc vào môi trường của chúng để đóng vai trò trong\r\nnon-bypassability của TSF. Ví dụ, một TOE ứng dụng an toàn yêu cầu rằng nó được\r\ngọi bởi hệ điều hành cơ bản. Tương tự như vậy, tường lửa phụ thuộc vào thực tế\r\nlà không có kết nối trực tiếp giữa các mạng nội bộ và bên ngoài và tất cả lưu\r\nlượng giữa chúng phải đi qua tường lửa.
\r\n\r\nA.1.2. Mô tả kiến trúc an toàn
\r\n\r\nMô tả kiến trúc an toàn giải thích cách các\r\nthuộc tính mô tả ở trên được trình bày bởi các TSF. Nó mô tả các miền được định\r\nnghĩa thế nào và TSF giữ chúng riêng biệt như thế nào. Nó mô tả cái gì ngăn\r\nchặn các tiến trình không tin cậy khỏi việc nhận TSF và sửa đổi nó. Nó mô tả\r\ncác gì đảm bảo rằng tất cả các tài nguyên thuộc thẩm quyền kiểm soát của TSF\r\nđược bảo vệ đầy đủ và tất cả hành động liên quan đến SFR được dàn xếp bởi TSF.\r\nNó giải thích vai trò bất kỳ mà môi trường đó thực hiện trong bất kỳ những vai\r\ntrò đó (ví dụ: giả sử nó được gọi ra một cách chính xác bởi môi trường cơ sở\r\ncủa nó, làm thế nào các chức năng an toàn của nó được gọi ra?).
\r\n\r\nMô tả kiến trúc an toàn trình bày các thuộc\r\ntính tự bảo vệ, tách miền, và non-bypassability của TSF trong một giới hạn mô\r\ntả phân tích. Mức độ mô tả này là tương xứng với sự mô tả TSF yêu cầu bởi những\r\nyêu cầu ADV_FSP, ADV_TDS và ADV_IMP đang được tuyên bố. Ví dụ, nếu ADV_FSP chỉ\r\nlà mô tả TSF sẵn có, thì ADV_FSP sẽ thật khó để đưa ra bất kỳ thiết kế kiến\r\ntrúc có ý nghĩa bởi vì không chi tiết nào của bất kỳ hoạt động bên trong TSF sẽ\r\nđược sẵn sàng.
\r\n\r\nTuy nhiên, nếu thiết kế TOE cũng có sẵn, ngay\r\ncả ở mức cơ bản nhất (ADV_TDS.1) thì sẽ có các thông tin liên quan đến các hệ\r\nthống con tạo nên TSF, và sẽ có một mô tả về cách chúng làm việc thế nào để\r\nthực thi những thuộc tính tự bảo vệ, tách miền, và none-bypassability. Ví dụ,\r\ncó thể tất cả các tương tác người dùng với TOE là hạn chế thông qua một tiến\r\ntrình mà có các hành động đại diện cho người dùng, chấp nhận tất cả các thuộc\r\ntính an toàn của người dùng; các thiết kế kiến trúc sẽ mô tả một tiến trình\r\ndiễn ra thế nào, cách xử lý của tiến trình bị hạn chế bởi các TSF thế nào (để\r\nnó có thể không bị ngắt bởi TSF), tất cả các hành động của tiến trình đó được\r\ngiàn xếp bởi TSF thế nào (do đó giải thích tại sao các TSF không thể bỏ qua),\r\nv.v…
\r\n\r\nNếu việc thiết kế một TOE chi tiết hơn (ví dụ\r\nnhư ở cấp độ mô-đun), hoặc các đại diện thực thi cũng sẵn sàng, thì sau đó mô\r\ntả của thiết kế kiến trúc tương ứng chi tiết hơn, giải thích được tiến trình\r\nngười dùng truyền thông với tiến trình TSF thế nào, cách các yêu cầu khác nhau\r\nđược xử lý bởi các TSF thế nào, những tham số gì được thông qua, những chương\r\ntrình bảo vệ nào (chống tràn bộ đệm, kiểm tra các thông số giới hạn, thời gian\r\nkiểm tra/thời gian kiểm tra sử dụng, v.v…) được đưa ra. Tương tự, một TOE, mà\r\nST của TOE này yêu cầu có thành phần ADV_IMP, sẽ đi vào chi tiết thực thi cụ\r\nthể.
\r\n\r\nCác giải trình cung cấp trong mô tả kiến trúc\r\nan toàn dự kiến sẽ được chi tiết đầy đủ, có thể kiểm thử tính chính xác của\r\nchúng. Chẳng hạn, một khẳng định đơn giản (ví dụ: “TSF duy trì sự riêng rẽ các\r\nmiền” không cung cấp thông tin hữu ích để thuyết phục người đọc rằng TSF quả\r\nthực tạo và phân tách miền riêng biệt.
\r\n\r\nA.1.2.1. Tách miền
\r\n\r\nTrong trường hợp TOE trình bày sự phân tách\r\nmiền một cách hoàn toàn riêng mình nó, sẽ có một mô tả đơn giản về cách mà điều\r\nnày đạt được. Mô tả kiến trúc an toàn có thể giải thích các loại khác nhau của\r\ncác miền được xác định bởi TSF, cách chúng được định nghĩa (tức là những tài\r\nnguyên nào được phân bổ cho từng miền), và cách các miền được giữ phân tách ra\r\nđể các thực thể hành động trong một miền không thể làm xáo trộn các tài nguyên\r\ntrong miền khác.
\r\n\r\nĐối với trường hợp TOE phụ thuộc vào các thực\r\nthể CNTT khác để thực thực hiện một vai trò trong miền tách, thì việc chia sẻ\r\nvề vai trò đó phải được làm rõ. Ví dụ, một TOE mà chỉ duy nhất phần mềm ứng\r\ndụng dựa vào hệ điều hành cơ sở để khởi tạo chính xác các miền mà TOE có định\r\nnghĩa; nếu TOE đó định nghĩa không gian xử lý riêng biệt, không gian bộ nhớ,\r\nv.v…đối với mỗi miền, thì nó phụ thuộc vào hệ điều hành cơ sở để hoạt động một\r\ncách chính xác và benignly (ví dụ như cho phép quá trình thực hiện chỉ trong\r\nkhông gian thực hiện được yêu cầu bởi phần mềm TOE).
\r\n\r\nVí dụ, cơ chế thực hiện tách miền (ví dụ như\r\nquản lý bộ nhớ, bảo vệ chế độ quy trình cung cấp bởi phần cứng, v.v…) sẽ được\r\nxác định và mô tả. Hoặc, TSF có thể thực thi các cấu trúc bảo vệ phần mềm hoặc\r\ncác quy ước mã hóa góp phần thực thi việc tách của các miền phần mềm, có thể\r\nbằng cách phân định không gian địa chỉ người sử dụng từ không gian địa chỉ hệ\r\nthống.
\r\n\r\nCác phân tích tính điểm yếu và hoạt động kiểm\r\nthử (xem AVA_VAN) có khả năng sẽ bao gồm các nỗ lực để làm hỏng sự phân tách\r\nmiền TSF được mô tả, thông qua việc sử dụng các giám sát hoặc tấn công trực\r\ntiếp các TSF.
\r\n\r\nA.1.2.2. TSF Tự bảo vệ
\r\n\r\nTrong trường hợp TOE trình bày tự bảo vệ hoàn\r\ntoàn tự nó, sẽ có một mô tả đơn giản về cách tự bảo vệ này đạt được. Cơ chế\r\ncung cấp cho việc tách miền để xác định một miền TSF được bảo vệ khỏi những\r\nmiền khác (người sử dụng) sẽ được xác định và mô tả.
\r\n\r\nĐối với trường hợp TOE phụ thuộc vào các thực\r\nthể CNTT khác để thực hiện vai trò trong việc bảo vệ chính nó, thì việc chia sẻ\r\nvề vai trò đó phải được làm rõ. Ví dụ, một TOE mà chỉ duy nhất phần mềm ứng\r\ndụng dựa vào hệ điều hành cơ sở để hoạt động chính xác; các ứng dụng không thể\r\ntự bảo vệ mình chống lại một hệ điều hành độc hại mà phá hoại nó (ví dụ, bằng\r\ncách ghi đè mã thực thi của nó hoặc TSF dữ liệu).
\r\n\r\nMô tả kiến trúc bảo mật cũng bao trùm việc\r\nđầu vào người dùng được xử lý bởi các TSF như thế nào theo cách mà các TSF\r\nkhông để chính bản thân chủ thể bị ngắt bởi đầu vào người dùng nó. Ví dụ, TSF\r\ncó thể thực thi khái niệm đặc quyền và tự bảo vệ mình bằng cách sử dụng các\r\nroutines chế độ có đặc quyền xử lý dữ liệu người dùng. Các TSF có thể tận dụng\r\ncác cơ chế phân chia bộ xử lý cơ sở (ví dụ như các mức độ hoặc vòng đặc quyền)\r\nđể tách mã và dữ liệu TSF từ mã và dữ liệu người dùng. Các TSF có thể thực thi\r\ncác cấu trúc bảo vệ phần mềm hoặc các quy ước mã hóa đó góp phần thực thi việc\r\ntách của phần mềm, có thể bằng cách phân định không gian địa chỉ người sử dụng\r\ntừ không gian địa chỉ hệ thống.
\r\n\r\nĐối với các TOE khởi động trong một chế độ\r\nchức năng thấp (ví dụ, một chế độ một người dùng đơn chỉ có thể dùng đối với\r\nngười cài đặt hoặc các quản trị viên) và sau đó chuyển tiếp sáng cấu hình an\r\ntoàn đã được đánh giá (một chế độ mà nhờ đó những người dùng không tin cậy có\r\nthể đăng nhập và sử dụng dịch vụ và tài nguyên của TOE), mô tả kiến trúc an\r\ntoàn cũng bao gồm phần giải thích về cách các TSF được bảo vệ chống lại các mã\r\nkhởi động mà không chạy trong cấu hình đã được đánh giá. Đối với các TOE như\r\nvậy, sự mô tả kiến trúc an toàn sẽ giải thích cái gì ngăn cản các dịch vụ mà\r\nnên sẵn có trong suốt thời gian khởi động (ví dụ như truy cập trực tiếp đến các\r\nnguồn tài nguyên) khỏi bị truy cập trong cấu hình đánh giá. Nó cũng sẽ giải\r\nthích cái gì ngăn cản mã khởi động chạy khi các TOE là đang trong cấu hình đã\r\nđược đánh giá đó.
\r\n\r\nCũng phải có một giải thích về cách mã khởi\r\nđộng tin cậy sẽ duy trì tính toàn vẹn của TSF (và của quá trình khởi động của\r\nnó), như vậy mà quá trình khởi động có thể phát hiện bất kỳ sửa đổi nào cho kết\r\nquả trong TSF là giả mạo để tin rằng đó là một trạng thái an toàn ban đầu.
\r\n\r\nCác phân tích tính điểm yếu và hoạt động kiểm\r\nthử (xem AVA_VAN) có khả năng sẽ bao gồm các nỗ lực để làm hỏng TSF tự bảo vệ\r\nđược mô tả, thông qua việc sử dụng các can thiệp, tấn công trực tiếp, hoặc giám\r\nsát của TSF.
\r\n\r\nA.1.2.3. TSF Không bỏ qua
\r\n\r\nThuộc tính của không bỏ qua liên quan với các\r\ngiao diện cho phép bỏ qua các cơ chế thực thi bắt buộc. Trong hầu hết các\r\ntrường hợp điều này là hệ quả của việc thực thi, nơi mà nếu một người lập trình\r\nđang viết giao diện để truy cập hoặc thao tác một đối tượng, thì đó là trách\r\nnhiệm của người lập trình sử dụng giao diện mà giao diện đó là một phần của cơ\r\nchế thực thi SFR cho đối tượng và không để cố gắng phá vỡ những giao diện đó. Đối\r\nvới các mô tả gắn liền với non-bypassability có hai phạm vi khái quát phải được\r\nbao trùm.
\r\n\r\nĐầu tiên bao gồm các giao diện cho việc thi\r\nhành-SFR. Các thuộc tính cho các giao diện này là để chúng không chứa các hoạt\r\nđộng hoặc chế độ cho phép chúng được sử dụng để bỏ qua các TSF. Có khả năng là\r\ncác bằng chứng cho ADV_FSP và ADV_TDS có thể được sử dụng trong phần lớn để\r\nquyết định. Bởi vì non-bypassability là mối quan tâm, nếu chỉ các hoạt động\r\nnhất định sẵn có thông qua các TSFI được tài liệu hóa (vì chúng là SFR- thi\r\nhành) còn những hoạt động khác thì không, thì nhà phát triển nên cân nhắc liệu\r\nthông tin bổ sung (trình bày trong ADV_FSP và ADV_TDS) có cần thiết để thực\r\nhiện một quyết định rằng hoạt động của TSFI SFR- hỗ trợ và SFR-không can thiệp\r\nkhông đủ điều kiện cho một thực thể không tin cậy có khả năng bỏ qua các chính\r\nsách được thi hành. Nếu như các thông tin là cần thiết, nó sẽ có trong các mô\r\ntả kiến trúc an ninh.
\r\n\r\nPhạm vi thứ hai của non-bypassability quan\r\ntâm đến những giao diện mà tương tác của nó không liên quan đến SFR-thực thi.\r\nTùy thuộc vào thành phần ADV_FSP và ADV_TDS được tuyên bố, một số thông tin về\r\ncác giao diện này có thể hoặc không thể tồn tại trong đặc tả chức năng và tài\r\nliệu thiết kế TOE. Thông tin trình bày cho các giao diện đó (hoặc nhóm các giao\r\ndiện) nên đầy đủ để người đọc có thể đưa ra một quyết định (ở mức độ chi tiết\r\ntương xứng với phần còn lại của bằng chứng được cung cấp trong ADV: Lớp phát\r\ntriển) mà các cơ chế thi hành không thể được bỏ qua.
\r\n\r\nThuộc tính mà các chức năng an toàn không thể\r\nbỏ qua áp dụng như nhau cho tất cả các chức năng an toàn. Đó là, mô tả thiết kế\r\nnên bao trùm các đối tượng được bảo vệ dưới các SFR (ví dụ như các thành phần *\r\nFDP_) và chức năng (ví dụ, kiểm toán) được cung cấp bởi TSF. Mô tả cũng nên xác\r\nđịnh giao diện có liên quan đến chức năng an toàn; điều này có thể tạo việc sử\r\ndụng các thông tin trong các đặc tả chức năng. Mô tả này cũng nên mô tả bất kỳ\r\ncấu trúc thiết kế nào, chẳng hạn như các nhà quản lý đối tượng, và phương pháp\r\nsử dụng của họ. Ví dụ, nếu các thường trình (routines) sử dụng một macro tiêu\r\nchuẩn để tạo ra một bản ghi kiểm toán, quy ước này là một phần của thiết kế mà\r\nnó góp phần vào việc non-bypassability của cơ chế kiểm toán. Điều quan trọng\r\ncần lưu ý là non-bypassability trong bối cảnh này không phải là một cố gắng để\r\ntrả lời câu hỏi “có thể là một phần của việc thực hiện TSF, nếu là các mã độc,\r\nthì bỏ qua các chức năng an toàn”, mà nên đưa ra cách làm thế nào để việc thực\r\nthi không bỏ qua chức năng an toàn.
\r\n\r\nCác phân tích tính điểm yếu và hoạt động kiểm\r\nthử (xem AVA_VAN) có thể sẽ bao gồm các nỗ lực để thất bại non-bypassability đã\r\nđược mô tả, nhờ việc phá hỏng các TSF.
\r\n\r\nA.2. ADV_FSP: Bổ sung các tài liệu trên các\r\nTSFI
\r\n\r\nMục đích cụ thể TSFIs là cung cấp những thông\r\ntin cần thiết để tiến hành kiểm thử; thiếu những thông tin về phương tiện có\r\nthể tương tác với các TSF, thì TSFI đó không thể kiểm thử cách xử lý của các\r\nTSF.
\r\n\r\nCó hai phần để xác định TSFIs: xác định chúng\r\nvà mô tả chúng. Vì sự đa dạng của các TOE, và của TSF khác nhau trong đó, không\r\ncó bộ tiêu chuẩn giao diện tạo thành “TSFI”. Phụ lục này cung cấp hướng dẫn về\r\ncác yếu tố xác định các giao diện nào là TSFIs.
\r\n\r\nA.2.1. Xác định TSFI
\r\n\r\nĐể xác định các giao diện cho TSF, các phần\r\ncủa TOE tạo nên TSF trước tiên phải được xác định. Nhận dạng này thực sự là một\r\nphần của các phân tích thiết kế TOE (ADV_TDS), nhưng cũng được thực hiện hoàn\r\ntoàn (thông qua nhận dạng và mô tả của các TSFI) bởi nhà phát triển trong\r\ntrường hợp thiết kế TOE (ADV_TDS) không nằm trong gói đảm bảo. Trong phân tích\r\nnày, một phần của TOE phải được coi là trong TSF nếu nó góp phần vào sự đáp ứng\r\ncủa một SFR trong ST (toàn bộ hoặc một phần). Điều này bao gồm, ví dụ, tất cả\r\nmọi thứ trong TOE góp phần cho TSF sự khởi động chạy theo thời gian, chẳng hạn\r\nnhư phần mềm chạy trước khi TSF có khả năng tự bảo vệ mình vì việc thi hành SFR\r\nchưa bắt đầu (Ví dụ, trong khi khởi động lên). Cũng bao gồm trong TSF là tất cả\r\ncác phần của TOE đóng góp vào các nguyên tắc kiến trúc của TSF tự bảo vệ, tách\r\nmiền, và non-bypassability (xem Kiến trúc an toàn (ADV_ARC)).
\r\n\r\nMột khi các TSF đã được định nghĩa, các TSFI\r\nđược xác định. Các TSFI bao gồm tất cả các phương tiện cho người dùng gọi một\r\ndịch vụ từ TSF (bằng cách cung cấp dữ liệu được xử lý bởi các TSF) và các phản\r\nứng tương ứng với những yêu cầu dịch vụ đó. Những yêu cầu và hồi đáp dịch vụ là\r\ncác phương tiện đi qua ranh giới TSF. Trong khi nhiều yêu cầu và hồi đáp dịch vụ\r\ntrong số này là rõ ràng, còn lại có thể không rõ ràng. Một câu hỏi nên được yêu\r\ncầu khi xác định TSFI là: “Làm thế nào một kẻ tấn công tiềm ẩn có thể tương tác\r\nvới các TSF trong một nỗ lực để phá vỡ các SFR?” Các cuộc thảo luận sau đây\r\nminh họa việc áp dụng định nghĩa TSFI trong các ngữ cảnh khác nhau.
\r\n\r\nA.2.1.1. Giao diện điện
\r\n\r\nTrong các TOE chẳng hạn như thẻ thông minh,\r\nnơi mà kẻ thù không chỉ truy cập vào TOE về logic, mà còn hoàn toàn truy cập\r\nvật lý vào TOE, ranh giới TSF là ranh giới vật lý. Do đó, giao diện điện tử phô\r\nra được xem là TSFI bởi vì thao tác của chúng có thể ảnh hưởng đến cách xử lý\r\ncủa TSF. Như vậy, tất cả các giao diện này (các liên hệ điện tử) cần phải được\r\nmô tả: các điện áp khác nhau có thể được áp dụng, v.v…
\r\n\r\nA.2.1.2. Ngăn xếp giao thức mạng
\r\n\r\nCác TSFIs của một TOE mà thực hiện xử lý giao\r\nthức sẽ là những lớp giao thức mà một kẻ tấn công tiềm ẩn có thể truy cập trực\r\ntiếp. Điều này không nhất thiết là toàn bộ chồng giao thức.
\r\n\r\nVí dụ, nếu các TOE là một số loại của một\r\nthiết bị mạng cho phép kẻ tấn công tiềm ẩn làm ảnh hưởng đến các lớp của chồng\r\ngiao thức (tức là để gửi tín hiệu tùy ý, điện áp bất kỳ, các gói tin bất kỳ,\r\ngói dữ liệu bất kỳ, v.v…) sau đó là ranh giới TSF tồn tại ở mỗi lớp của chồng\r\ngiao thức đó. Do đó, đặc tả chức năng sẽ phải hướng đến giao thức ở mỗi lớp của\r\nchồng giao thức đó.
\r\n\r\nTuy nhiên, nếu các TOE là một tường lửa bảo\r\nvệ mạng nội bộ từ Internet, một kẻ tấn công tiềm ẩn sẽ không có phương tiện\r\nthao tác trực tiếp điện áp vào TOE; bất kỳ điện áp cực đại nào cũng sẽ không\r\nđơn giản được cho qua thông qua Internet. Đó là, kẻ tấn công sẽ có quyền truy\r\ncập chỉ với những giao thức tại lớp Internet hoặc ở trên. Ranh giới TSF tồn tại\r\nở mỗi lớp của chồng giao thức. Vì vậy, đặc tả chức năng sẽ phải nhắm đến chỉ\r\nnhững giao thức ở tại lớp Internet hoặc lớp phía trên: nó sẽ mô tả mỗi lớp\r\ntruyền thông khác nhau mà tại đó tường lửa được phô ra dưới dạng những thứ tạo\r\nnên đầu vào đúng cho cái có thể xuất hiện trên đường truyền, và kết quả của cả\r\nhai đầu vào đúng và dị hình. Ví dụ, mô tả về lớp giao thức Internet sẽ mô tả\r\ncái tạo ra một gói tin IP đúng và những gì xảy ra khi cả hai dạng gói tin đúng\r\nvà gói tin dị hình đều được nhận. Tương tự, sự mô tả của lớp TCP sẽ mô tả một\r\nkết nối TCP thành công và những gì xảy ra cả khi các kết nối thành công được\r\nthiết lập và khi kết nối không thể được thiết lập hoặc bị mất không cố ý. Lợi\r\ndụng mục đích của tường lửa là để lọc các lệnh ở cấp ứng dụng (như FTP hoặc\r\ntelnet), mô tả lớp ứng dụng sẽ mô tả các lệnh ở cấp ứng dụng đó để tường lửa\r\nnhận ra và lọc, cũng như kết quả của việc gặp phải lệnh không rõ.
\r\n\r\nNhững mô tả của các lớp này có thể tham khảo\r\nở các tiêu chuẩn truyền thông đã phát hành (telnet, FTP, TCP, v.v…) đang được\r\nsử dụng.
\r\n\r\nA.2.1.3. Trình bao bọc (Wrappers)
\r\n\r\n![](\"00907948_files/image019.jpg\")
“Wrappers” biên dịch loạt các tương tác phức\r\ntạp thành các dịch vụ phổ biến đơn giản hóa, chẳng hạn như khi Hệ điều hành tạo\r\nra các API để sử dụng bởi các ứng dụng (như trong Hình A.1). Cho dù các TSFI sẽ\r\nlà các cuộc gọi hệ thống hoặc API phụ thuộc vào những gì có sẵn cho ứng dụng:\r\nnếu các ứng dụng có thể sử dụng các cuộc gọi hệ thống trực tiếp, sau đó các\r\ncuộc gọi hệ thống là các TSFI. Tuy nhiên, nếu có một vài thứ ngăn cấm sử dụng\r\ntrực tiếp của chúng và yêu cầu tất cả các truyền thông thông qua các API, sau\r\nđó các API sẽ là TSFI.
\r\n\r\nMột giao diện người dùng đồ họa tương tự: nó\r\nbiên dịch giữa các lệnh máy dễ hiểu và đồ họa người dùng thân thiện. Tương tự,\r\nTSFI sẽ là các lệnh nếu người dùng có quyền truy cập tới chúng, hoặc các đồ họa\r\n(pull-down menu, kiểm tra hộp, các trường văn bản) nếu người sử dụng thường bị\r\nhạn chế sử dụng chúng.
\r\n\r\nĐáng chú ý là, trong cả hai ví dụ, nếu người\r\ndùng là bị cấm sử dụng các giao diện nguyên sơ (tức là các cuộc gọi hệ thống\r\nhay các lệnh), thì mô tả các hạn chế này và thực thi của nó sẽ được nêu trong\r\ncác Mô tả Kiến trúc An toàn (xem A.1). Các wrapper cũng là một phần của TSF.
\r\n\r\nA.2.1.4. Các giao diện không được phép truy\r\ncập
\r\n\r\nĐối với một TOE đưa ra, không phải tất cả các\r\ngiao diện có thể được truy cập. Đó là, các mục tiêu an toàn cho môi trường vận\r\nhành (trong Đích An toàn) có thể ngăn chặn việc truy cập vào các giao diện này\r\nhoặc giới hạn các truy cập trong một cách mà chúng không thể tiếp cận về mặt\r\nthực tế. Giao diện như vậy sẽ không được xem là TSFI. Một số ví dụ:
\r\n\r\na) Nếu các mục tiêu an toàn cho môi trường\r\nvận hành đối với trạng thái stand-alone của tường lửa, nghĩa là trạng thái\r\n“tường lửa có thể là hoạt động trong một môi trường phòng máy chủ nơi mà chỉ\r\nnhân viên đáng tin cậy và được đào tạo có quyền truy cập, và sẽ được trang bị\r\nquyền có khả năng ngắt được việc cấp năng lượng (chống lại sự thất bại về năng\r\nlượng)”, thì các giao diện vật lý và nguồn điện sẽ không thể truy cập được, vì\r\nmột nhân viên đáng tin cậy và được đào tạo sẽ không cố gắng tháo dỡ tường lửa\r\nđó và/hoặc vô hiệu hóa nguồn cấp điện của nó.
\r\n\r\nb) Nếu các mục tiêu an toàn cho môi trường\r\nvận hành đối với trạng thái tường lửa phần mềm (ứng dụng), là trạng thái “hệ\r\nđiều hành OS và phần cứng sẽ cung cấp một miền an toàn cho các ứng dụng tự do\r\nkhỏi việc giả mạo của các chương trình khác”, thì các giao diện mà qua đó tường\r\nlửa có thể được truy cập bởi các ứng dụng khác trên OS đó (ví dụ như xóa, sửa\r\nchữa khả năng thực thi của tường lửa, đọc hoặc ghi trực tiếp vào không gian bộ\r\nnhớ của tường lửa) sẽ không thể truy cập được, vì bộ phận OS/phần cứng của môi\r\ntrường vận hành đó khiến cho giao diện này không thể tiếp cận.
\r\n\r\nc) Nếu các mục tiêu an toàn cho môi trường\r\nvận hành đối với trạng thái tường lửa phần mềm bổ sung, trạng thái mà OS và\r\nphần cứng sẽ thực hiện chính xác các lệnh của TOE, và sẽ không can thiệp vào\r\nTOE theo bất kỳ cách nào, thì các giao diện mà qua đó tường lửa có được chức\r\nnăng nguyên sơ từ OS và phần cứng (thực hiện các chỉ dẫn mã máy, hệ điều hành\r\nAPI, như tạo, đọc, ghi hoặc xóa các tập tin, các API đồ họa v.v…) sẽ không thể\r\ntruy cập được, vì hệ điều hành/phần cứng là các thực thể duy nhất có thể truy\r\ncập vào giao diện, và chúng hoàn toàn đáng tin cậy.
\r\n\r\nĐối với tất cả các ví dụ này, các giao diện\r\nnày không thể truy cập sẽ không thể là TSFI.
\r\n\r\nA.2.2. Ví dụ: một DBMS phức tạp
\r\n\r\nHình A.2 minh họa một TOE phức tạp: một hệ\r\nthống quản lý cơ sở dữ liệu dựa trên phần cứng và phần mềm nằm ở bên ngoài ranh\r\ngiới TOE (gọi tắt là môi trường CNTT trong phần còn lại của cuộc thảo luận\r\nnày). Để đơn giản hóa ví dụ này, TOE là giống hệt với TSF. Các hộp tô màu sậm\r\nđại diện cho TSF, còn các hộp không tô màu đại diện cho các thực thể CNTT trong\r\nmôi trường đó. TSF này bao gồm các công cụ và GUI quản lý cơ sở dữ liệu (đại\r\ndiện bởi các hộp có nhãn DB) và mô-đun nhân chạy như một phần của hệ điều hành,\r\nthực hiện một số chức năng an toàn (đại diện bởi các hộp có nhãn PLG). Các\r\nmô-đun nhân TSF có các điểm nhập vào xác định bởi các đặc tả OS, cái mà OS sẽ\r\nviễn dẫn ra một số chức năng (điều này có thể là một trình điều khiển thiết bị,\r\nhoặc mô đune xác thực, vv). Điều quan trọng là mô-đun nhân này có thể cắm nối\r\nnày là cung cấp dịch vụ an toàn theo quy định của các yêu cầu chức năng trong\r\nST này.
\r\n\r\n![](\"00907948_files/image020.jpg\")
Môi trường CNTT bao gồm các hệ điều hành của\r\nchính nó (thể hiện qua hộp có nhãn OS), cũng như các máy chủ bên ngoài (có tên\r\nlà SRV). Máy chủ bên ngoài này, giống như OS, cung cấp một dịch vụ mà TSF phụ\r\nthuộc vào, và do đó cần phải được đặt trong môi trường CNTT. Giao diện trong\r\nhình được gắn nhãn Ax cho TSFI, và Bx cho các giao diện khác sẽ tài liệu hóa\r\ntrong ACO là: Tổng hợp. Mỗi một nhóm các giao diện sẽ được thảo luận.
\r\n\r\nGiao diện nhóm A1 đại diện cho bộ rõ ràng\r\nnhất của TSFI. Đây là giao diện được sử dụng bởi người dùng truy cập trực tiếp\r\ncơ sở dữ liệu và chức năng và các tài nguyên an toàn của nó.
\r\n\r\nGiao diện A2 nhóm đại diện cho TSFI mà OS\r\nviện dẫn ra để đạt được những chức năng cung cấp bởi các module có thể cắm nối.\r\nNhững giao diện này tương phản với nhóm giao diện B3, nhóm đại diện cho các\r\ncuộc gọi mà các module cắm nối tạo ra để đạt được các dịch vụ từ môi trường\r\nCNTT.
\r\n\r\nGiao diện nhóm A3 đại diện TSFI đi qua môi\r\ntrường CNTT. Trong trường hợp này, các truyền thông DBMS qua mạng sử dụng một\r\ngiao thức ở lớp ứng dụng. Trong khi môi trường CNTT có trách nhiệm cung cấp các\r\ngiao thức hỗ trợ khác nhau (ví dụ, Ethernet, IP, TCP) giao thức lớp ứng dụng\r\nđược sử dụng để đạt được các dịch vụ từ các DBMS, là một TSFI và phải được ghi\r\nnhận như vậy. Các đường chấm chấm biểu thị giá trị trả lại / dịch vụ từ các TSF\r\nqua kết nối mạng.
\r\n\r\nCác giao diện có nhãn Bx đại diện cho các\r\ngiao diện đến các chức năng trong môi trường CNTT. Các giao diện này không phải\r\nlà TSFI và chỉ cần được thảo luận và phân tích khi TOE đang được sử dụng trong\r\nmột đánh giá tổng hợp như một phần của các hoạt động liên kết với các lớp ACO.
\r\n\r\nA.2.3. Ví dụ Đặc tả chức năng
\r\n\r\nVí dụ tường lửa được sử dụng giữa một mạng\r\nnội bộ và mạng bên ngoài. Nó xác minh địa chỉ nguồn của các dữ liệu nhận được\r\n(để đảm bảo rằng dữ liệu bên ngoài không cố gắng giả mạo là có nguồn gốc từ các\r\ndữ liệu nội bộ), nếu nó phát hiện bất kỳ nỗ lực nào như vậy, nó sẽ giảm được sự\r\ntấn công vào các bản ghi kiểm toán. Các quản trị viên kết nối với tường lửa\r\nbằng cách thiết lập một kết nối telnet vào firewall từ các mạng nội bộ. Các\r\nhành động của quản trị viên bao gồm xác thực, thay đổi mật khẩu, xem xét các\r\nbản ghi kiểm toán, và thiết lập hoặc thay đổi địa chỉ của các mạng nội bộ và\r\nbên ngoài.
\r\n\r\nVí dụ tường lửa đưa ra các giao diện sau đây\r\nvới mạng nội bộ:
\r\n\r\na) Các gói dữ liệu IP
\r\n\r\nb) Các lệnh nhà quản trị
\r\n\r\nvà giao diện sau với mạng bên ngoài:
\r\n\r\nCác gói dữ liệu IP
\r\n\r\nMô tả giao diện: Các gói dữ liệu IP
\r\n\r\nCác datagrams có định dạng theo quy định của\r\nRFC 791.
\r\n\r\n● Mục đích - để truyền tải các khối dữ liệu\r\n(“datagrams”) từ host nguồn đến host đích được xác định bởi chiều dài địa chỉ\r\ncố định; cũng cung cấp cho các phân mảnh và hợp mảnh của gói dữ liệu dài, nếu\r\ncần thiết, cho việc truyền thông qua các mạng gói nhỏ.
\r\n\r\n● Phương pháp sử dụng - chúng đến từ các giao\r\nthức lớp thấp hơn (ví dụ như liên kết dữ liệu).
\r\n\r\n● Tham số - gồm các trường sau của tiêu đề\r\ngói tin IP: địa chỉ nguồn, đích đến địa chỉ, cờ không phân mảnh.
\r\n\r\n● Mô tả các thông số - [Như được định nghĩa\r\nbởi RFC 791, mục 3.1 (“Định dạng tiêu đề mạng”)]
\r\n\r\n● Hành động - Truyền gói dữ liệu mà không\r\nphải là giả mạo; phân mảnh các gói dữ liệu lớn nếu cần thiết; lắp ghép các mảnh\r\nthành các gói dữ liệu.
\r\n\r\n● Bản tin báo lỗi - (không có). Không có các\r\ngói tin không thể phân phát (ví dụ như phải được phân mảnh để truyền, nhưng cờ\r\nkhông phân mảnh được thiết lập) được đảm bảo độ tin cậy (độ tin cậy để được\r\ncung cấp bởi các giao thức lớp trên) bị mất.
\r\n\r\nGiao diện mô tả: Các lệnh quản trị
\r\n\r\nCác lệnh quản trị cung cấp một phương tiện\r\ncho người quản trị tương tác với các tường lửa. Những lệnh và sự đáp lại này đi\r\ntrên kết nối telnet (RFC 854) được thiết lập từ bất kỳ host nào trong mạng nội\r\nbộ. Các lệnh sẵn có là:
\r\n\r\n● Passwd
\r\n\r\n● Mục đích - đặt mật khẩu quản trị
\r\n\r\n● Phương pháp Sử dụng - passwd <mật\r\nkhẩu>
\r\n\r\n● Thông số - mật khẩu
\r\n\r\n● Mô tả thông số - giá trị của mật khẩu mới
\r\n\r\n● Hành động - thay đổi mật khẩu để thêm giá\r\ntrị mới. Không có giới hạn.
\r\n\r\n● Bản tin báo lỗi - không có.
\r\n\r\n● Readaudit
\r\n\r\n● Mục đích - trình bày các bản ghi kiểm toán\r\ncho các quản trị viên
\r\n\r\n● Phương pháp sử dụng - Readaudit
\r\n\r\n● Thông số - không có
\r\n\r\n● Mô tả thông số - không
\r\n\r\n● Hành động - cung cấp các văn bản của các\r\nbản ghi kiểm toán
\r\n\r\n● Thông báo lỗi - không có.
\r\n\r\n● Setintaddr
\r\n\r\n● Mục đích - tập địa chỉ của các địa chỉ nội\r\nbộ
\r\n\r\n● Phương pháp sử dụng - Setintaddr <địa\r\nchỉ>
\r\n\r\n● Tham số - địa chỉ
\r\n\r\n● Mô tả tham số - ba trường đầu tiên của một\r\nđịa chỉ IP (được định nghĩa trong RFC 791). Ví dụ: 123.123.123
\r\n\r\n● Hành động - thay đổi giá trị nội bộ của\r\nbiến số xác định mạng nội bộ, giá trị này của nó được sử dụng để phân định sự\r\ngiả mạo
\r\n\r\n● Thông báo lỗi - “địa chỉ được sử dụng”: chỉ\r\nra mạng nội bộ được đã định danh là giống như các mạng bên ngoài.
\r\n\r\n● Setextaddr
\r\n\r\n● Mục đích - bộ địa chỉ của địa chỉ bên ngoài
\r\n\r\n● Phương pháp sử dụng - Setextaddr <địa\r\nchỉ>
\r\n\r\n● Tham số - địa chỉ
\r\n\r\n● Mô tả tham số - ba trường đầu tiên của một\r\nđịa chỉ IP (như được định nghĩa trong RFC 791). Ví dụ: 123.123.123
\r\n\r\n● Hành động - thay đổi giá trị nội bộ của\r\nbiến xác định các mạng bên ngoài
\r\n\r\n● Thông báo lỗi - “địa chỉ được sử dụng”: chỉ\r\nra mạng bên ngoài được định danh giống như các mạng nội bộ.
\r\n\r\nA.3. ADV_INT: Tài liệu bổ sung trên TSF nội\r\nbộ
\r\n\r\nSự đa dạng của các TOE làm cho nó không thể\r\nhệ thống hóa bất cứ cái gì xác định hơn “có cấu trúc” hay “phức tạp tối thiểu”.\r\nSự phán đoán trên cấu trúc và tính phức tạp được dự kiến sẽ xuất phát từ các\r\ncông nghệ cụ thể sử dụng trong các TOE. Ví dụ, phần mềm có thể được xem xét cấu\r\ntrúc tốt khi nó biểu lộ đặc điểm được trích dẫn trong các ngành kỹ thuật phần\r\nmềm.
\r\n\r\nPhụ lục này cung cấp tài liệu bổ sung về việc\r\nđánh giá cấu trúc và sự phức tạp của các thành phần phần mềm thủ tục cơ sở của\r\nTSF. Tài liệu này dựa trên các thông tin có sẵn trong các tài liệu kỹ thuật\r\nphần mềm. Đối với các loại khác của TSF nội bộ (ví dụ như phần cứng, không phần\r\nmềm không thủ tục như mã hướng đối tượng, vv), tương ứng với tài liệu để thực\r\nhành tốt nên được tư vấn.
\r\n\r\nA.3.1. Cấu trúc phần mềm thủ tục
\r\n\r\nCấu trúc của phần mềm thủ tục được đánh giá\r\ntruyền thống theo mô đun của nó. Phần mềm được viết với sự hỗ trợ của thiết kế\r\nmô-đun trong việc đạt được sự dễ hiểu bằng cách làm rõ các mối phụ thuộc nào mà\r\nmodule có trên các module khác (khớp nối) và nêu rõ các nhiệm vụ chỉ trong một\r\nmodule là có liên quan rõ rệt với nhau (gắn kết). Việc sử dụng các thiết kế mô\r\nđun làm giảm các mối phụ thuộc lẫn nhau giữa các phần tử của TSF và do đó làm\r\ngiảm rủi ro mà sự thay đổi hoặc lỗi trong một module sẽ có ảnh hưởng trong suốt\r\nTOE. Việc sử dụng của nó tăng cường độ rõ nét của thiết kế và cung cấp sự đảm\r\nbảo cao, nghĩa là các tác động không mong đợi sẽ không xảy ra. Các thuộc tính\r\nmong muốn của sự phân tách mô-đun là giảm số lượng mã dư thừa hoặc không cần\r\nthiết.
\r\n\r\nGiảm thiểu số lượng các chức năng trong TSF\r\ncho phép các thẩm định viên cũng như các nhà phát triển chỉ tập chung vào các\r\nchức năng nào cần thiết cho SFR thực thi, giúp dễ hiểu hơn và tiếp tục hạ thấp\r\nkhả năng các lỗi thiết kế hoặc thực hiện.
\r\n\r\nSự hợp nhất của việc phân tách, xếp lớp và\r\nhạn chế tối đa mô đun vào quá trình thiết kế và thực thi phải được đi kèm với\r\nnhững cân nhắc kỹ thuật phần mềm âm thanh. Một hệ thống phần mềm thực tế, hữu\r\ních thường sẽ kéo theo một số khớp nối mong muốn giữa các module, một số mô-đun\r\nbao gồm các chức năng liên kết rời rạc, và một số lại tinh vi hoặc phức tạp\r\ntrong thiết kế của một module. Những sai lệnh so với những lý tưởng của sự phân\r\ntách mô đun thường được coi là cần thiết để đạt được một số mục tiêu hoặc hạn\r\nchế, có thể là liên quan đến hiệu năng, tính tương thích, chức năng lên kế\r\nhoạch trong tương lai, hoặc một số yếu tố khác, và có thể chấp nhận được, dựa\r\ntrên sự điều chỉnh của nhà phát triển cho chúng. Khi áp dụng các yêu cầu của\r\nlớp này, vì việc xem xét phải đưa đến nguyên tắc kỹ thuật phần mềm âm thanh,\r\ntuy nhiên, mục tiêu tổng thể của tính dễ hiểu phải đạt được.
\r\n\r\nA.3.1.1. Sự gắn kết
\r\n\r\nSự gắn kết là cách thức và mức độ mà ở đó các\r\nnhiệm vụ được thực hiện bởi một module phần mềm đơn nhất, có liên quan với sự\r\ngắn kết khác; các loại gắn kết bao gồm sự trùng khớp, khả năng truyền thông,\r\nchức năng, logic, tuần tự, và về thời gian. Những loại gắn kết được đặc trưng\r\ndưới đây, được liệt kê theo thứ tự giảm dần về mong muốn.
\r\n\r\na) gắn kết về chức năng - một module với gắn\r\nkết về chức năng thực hiện các hoạt động liên quan đến một mục đích đơn nhất.\r\nMột module gắn kết về chức năng chuyển đổi một loại đầu vào đơn của thành một\r\nloại đầu ra đơn, cũng như một quản lý ngăn xếp hoặc một quản lý một hàng đợi.
\r\n\r\nb) gắn kết tuần tự - một mô-đun gắn kết tuần\r\ntự chứa mỗi chức năng của có đầu ra của nó là đầu vào cho các chức năng theo\r\nsau trong module. Một ví dụ về một mô-đun gắn kết tuần tự là một mô đun trong\r\nđó chứa các chức năng ghi hồ sơ kiểm toán và duy trì hoạt động đếm của số tích\r\nlũy của các hành vi vi phạm kiểm toán theo một loại cụ thể.
\r\n\r\nc) gắn kết truyền thông - một mô-đun gắn kết\r\ntruyền thông chứa những chức năng mà tạo ra đầu ra, hoặc sử dụng đầu ra từ, các\r\nchức năng khác trong module. Một ví dụ về mô-đun gắn kết truyền thông là một mô\r\nđun kiểm tra truy cập bao gồm kiểm tra bắt buộc, tùy ý, và năng lực.
\r\n\r\nd) gắn kết về thời gian - chứa các chức năng\r\ncần thiết để thực hiện tại cùng một thời điểm. Ví dụ về các mô-đun gắn kết bao\r\ngồm khởi động, phục hồi, và các mô-đun tắt máy.
\r\n\r\ne) gắn kết về logic (hoặc thủ tục) - một\r\nmô-đun với sự gắn kết về logic sẽ thực hiện các hoạt động tương tự nhau trên\r\ncấu trúc dữ liệu khác nhau. Một cuộc mô-đun trình bày sự gắn kết về logic nếu\r\ncác chức năng của nó thực hiện các hoạt động liên quan, nhưng khác nhau trên\r\ncác đầu vào khác nhau.
\r\n\r\nf) gắn kết trùng khớp - một mô-đun với sự gắn\r\nkết trùng khớp thực hiện các hoạt động ngẫu nhiên không liên quan, hoặc liên\r\nquan lỏng lẻo.
\r\n\r\nA.3.1.2. Ghép nối
\r\n\r\nGhép nối là cách thức và mức độ phụ thuộc lẫn\r\nnhau giữa các module phần mềm; các loại khớp nối bao gồm nối cuộc gọi, chung và\r\nnội dung. Các loại khớp nối được miêu tả dưới đây, liệt kê theo thứ tự mong\r\nmuốn giảm dần:
\r\n\r\na) lời gọi: hai mô-đun được gọi cùng nếu\r\nchúng truyền thông chặt chẽ thông qua việc sử dụng các cuộc gọi chức năng được\r\nviện dẫn của chúng, ví dụ về khớp nối gọi là dữ liệu, nhãn hiệu, và kiểm soát,\r\nđược định nghĩa dưới đây.
\r\n\r\n1) dữ liệu: hai mô-đun được khớp nối dữ liệu nếu\r\nchúng truyền thông chặt chẽ thông qua việc sử dụng các thông số cuộc gọi dữ\r\nliệu duy nhất đại diện cho các mục dữ liệu.
\r\n\r\n2) nhãn hiệu: hai mô-đun được khớp nối nhãn\r\nhiệu nếu chúng giao tiếp thông qua việc sử dụng các thông số cuộc gọi mà bao\r\ngồm nhiều trường hoặc có cấu trúc có ý nghĩa nội bộ.
\r\n\r\n3) Kiểm soát: hai mô-đun được khớp nối điều\r\nkhiển nếu một mô đun vượt qua thông tin được dùng để gây ảnh hưởng đến logic\r\nnội bộ của nhau.
\r\n\r\nb) chung: hai mô-đun được khớp nối chung nếu\r\nchúng chia sẻ một vùng dữ liệu chung hoặc một tài nguyên hệ thống chung. Biến\r\nchung chỉ ra rằng các mô-đun bằng cách sử dụng các biến chung được ghép nối\r\nchung. Khớp nối chung thông qua các biến chung thường được cho phép, nhưng chỉ\r\nđến một mức độ hạn chế. Ví dụ, các biến được đặt vào một khu vực toàn cầu,\r\nnhưng được sử dụng chỉ bởi một module đơn nhất, và được đặt không thích hợp, và\r\nnên xóa bỏ. Các yếu tố khác cần được xem xét trong đánh giá phù hợp của các\r\nbiến chung là:
\r\n\r\n1) Một số mô đun thay đổi biến toàn cầu: Nói\r\nchung, chỉ có một mô-đun duy nhất nên được giao trách nhiệm cho việc kiểm soát\r\ncác nội dung của một biến toàn cầu, nhưng có thể có các tình huống trong đó một\r\nmô-đun thứ hai có thể chia sẻ trách nhiệm đó, trong trường hợp đó, lý lẽ bào\r\nchữa đầy đủ phải được cung cấp. Không chấp nhận trách nhiệm này cho việc chia\r\nsẻ bởi nhiều hơn hai mô-đun. (Trong việc đánh giá này, điều quan tâm nên được\r\nđưa ra để xác định mô-đun thực sự chịu trách nhiệm về nội dung của biến, ví dụ,\r\nnếu một thường trình đơn nhất được sử dụng để sửa đổi các biến, nhưng thường trình\r\nđó chỉ đơn giản thực hiện việc sửa đổi theo yêu cầu của người gọi của nó, thì\r\nđó là module gọi có trách nhiệm, và có thể có nhiều hơn một mô đun như vậy).\r\nHơn nữa, như một phần của việc xác định phức tạp, nếu hai module chịu trách nhiệm\r\nvề nội dung của một biến toàn cầu, cần có chỉ dẫn rõ ràng về cách sửa đổi được\r\nđiều phối giữa chúng.
\r\n\r\n2) Một số mô đun tham chiếu một biến toàn\r\ncầu: Mặc dù nói chung không có giới hạn về số lượng các module tham chiếu một\r\nbiến toàn cầu, các trường hợp trong đó nhiều mô-đun thực hiện như một tham\r\nchiếu thì nên được kiểm tra về tính hợp lệ và cần thiết.
\r\n\r\nc) nội dung: Hai mô-đun được ghép nối nội\r\ndung nếu một mô đun có thể tham chiếu trực tiếp vào bên trong của mô-đun kia\r\n(ví dụ sửa đổi mã của mô đun còn lại, hoặc tham chiếu nhãn nội bộ tới các\r\nmodule còn lại). Kết quả là một số hoặc tất cả các nội dung của một module được\r\nchứa một cách có hiệu quả trong việc mô đun kia. Khớp nối nội dung có thể được\r\ndùng như cách sử dụng giao diện mô đun không quảng bá, điều này trái ngược với\r\ncuộc gọi ghép đôi, chỉ sử dụng giao diện module quảng bá.
\r\n\r\nA.3.2. Tính phức tạp của phần mềm thủ tục
\r\n\r\nPhức tạp là biện pháp điểm quyết định và\r\ntuyến logic của việc thực hiện mà các mã đưa ra tài liệu kỹ thuật phần mềm\r\ntrích dẫn sự phức tạp như là một đặc tính tiêu cực của phần mềm bởi vì nó cản\r\ntrở tính thông minh về sự logic và flow của mã đó. Một trở ngại khác cho sự\r\nthông minh của mã là sự hiện diện của những mã không cần thiết, mà ở đó nó không\r\nđược sử dụng hoặc thừa.
\r\n\r\nViệc sử dụng cách phân lớp để chia thành các\r\nmức độ trừu tượng và giảm thiểu phụ thuộc vòng tròn hơn nữa cho phép một sự\r\nhiểu biết tốt hơn về TSF, cung cấp sự bảo đảm hơn, điều mà các yêu cầu chức\r\nnăng an toàn TOE chính xác và hoàn toàn được thuyết minh trong việc thực thi.
\r\n\r\nGiảm sự phức tạp cũng bao gồm việc giảm hoặc\r\nloại bỏ các mối phụ thuộc lẫn nhau, mà gắn liền cả hai với mô-đun trong một lớp\r\nđơn nhất và để chúng trong các lớp riêng biệt. Module phụ thuộc lẫn nhau có thể\r\ndựa vào nhau để xây dựng một kết quả duy nhất, mà có thể dẫn đến một tình trạng\r\nbế tắc, hoặc tệ hơn, một điều kiện tranh đua (ví dụ, thời gian kiểm tra so với\r\nthời gian quan tâm sử dụng), nơi mà các kết luận cuối cùng có thể không xác\r\nđịnh được và lệ thuộc vào môi trường điện toán tại thời điểm được đưa ra tức\r\nthì.
\r\n\r\nGiảm thiểu sự phức tạp của thiết kế là một\r\nđặc tính quan trọng của một cơ chế xác nhận tính hợp lệ của sự tham chiếu, mục\r\nđích của nó là để đi đến việc dễ dàng hiểu một TSF để nó có thể được phân tích\r\nhoàn toàn. (Có những đặc điểm quan trọng khác của một cơ chế xác tính hợp lệ\r\ntham chiếu, như TSF tự bảo vệ và non-bypassability; các đặc tính khác được bao\r\ntrùm bởi các yêu cầu trong họ ADV_ARC.)
\r\n\r\nA.4. ADV_TDS: Các hệ thống con và mô đun
\r\n\r\nMục này cung cấp hướng dẫn bổ sung về họ TDS,\r\nvà cách sử dụng của nó trong thuật ngữ “hệ thống con” và “mô đun”. Tiếp theo là\r\nmột thảo luận về cách có nhiều chi tiết được thêm thế nào, yêu cầu đối với một\r\nsố chi tiết được giảm như thế nào.
\r\n\r\nA.4.1. Các hệ thống con
\r\n\r\nHình A.3 cho thấy rằng, việc phụ thuộc vào sự\r\nphức tạp của TSF, thiết kế có thể được mô tả trong phạm vi hệ thống con và các\r\nmô-đun (nơi mà các hệ thống con có một mức độ trừu tượng cao hơn so với các\r\nmô-đun), hoặc nó chỉ có thể được mô tả trong phạm vi của một mức độ trừu tượng\r\n(ví dụ, các hệ thống con ở các cấp độ đảm bảo thấp hơn, mô-đun ở các cấp cao\r\nhơn). Trong trường hợp mức trừu tượng thấp hơn (modules) được trình bày, các\r\nyêu cầu đánh vào cấp trừu tượng (các hệ thống con) được về cơ bản đáp ứng theo\r\nmặc định. Khái niệm này là tiếp tục xây dựng trong các cuộc thảo luận về hệ\r\nthống con và các module dưới đây.
\r\n\r\n![](\"00907948_files/image021.jpg\")
Nhà phát triển được trông đợi mô tả việc\r\nthiết kế các TOE trong phạm vi của hệ thống con. Thuật ngữ “hệ thống con” đã\r\nđược lựa chọn không rõ ràng để nó có thể tham khảo các khối phù hợp với TOE (ví\r\ndụ, các hệ thống con, mô-đun). Các hệ thống con thậm chí có thể không đồng đều\r\ntrong phạm vi, miễn là các yêu cầu về mô tả của các hệ thống con được đáp ứng.
\r\n\r\nViệc sử dụng đầu tiên của các hệ thống con là\r\nđể phân biệt ranh giới TSF, đó là, các phần của TOE đó bao gồm các TSF. Nói\r\nchung, một hệ thống con là một phần của TSF nếu nó có khả năng (dù theo thiết\r\nkế hoặc thực thi) để ảnh hưởng đến các hoạt động chính xác của bất kỳ SFR. Ví\r\ndụ, đối với phần mềm phụ thuộc vào phương thức thực hiện phần cứng khác nhau để\r\nđưa ra sự phân tách miền (xem A.1) nơi mã SFT thực thi được thực hiện trong một\r\nmiền, sau đó tất cả các hệ thống con mà thực hiện ở miền đó có thể coi là một\r\nphần của TSF. Tương tự như vậy, nếu một máy chủ bên ngoài miền đó thực thi một\r\nSFR (ví dụ như thi hành một chính sách kiểm soát truy cập đối với các đối tượng\r\nnó được quản lý), thì sau đó nó cũng sẽ được coi là một phần của TSF.
\r\n\r\nViệc sử dụng thứ hai của các hệ thống con là\r\ncung cấp một cấu trúc để mô tả các TSF ở một mức độ mô tả đó, trong việc mô tả\r\ncách TSF làm việc thế nào, không nhất thiết phải bao gồm chi tiết thực hiện ở\r\nmức thấp được tìm thấy trong các mô tả module (thảo luận sau). Các hệ thống con\r\nnày được mô tả ở hoặc ở một cấp độ cao (thiếu đa dạng về chi tiết thi hành)\r\nhoặc ở một cấp độ chi tiết (cung cấp cái nhìn sâu hơn trong việc thi hành). Cấp\r\nđộ mô tả cung cấp cho một hệ thống con được xác định bởi mức độ mà hệ thống con\r\nđó có trách nhiệm thi hành một SFR.
\r\n\r\nMột hệ thống con SFR-thực thi là một hệ thống\r\ncon cung cấp cơ chế để thi hành một phần tử của SFR bất kỳ, hoặc trực tiếp hỗ\r\ntrợ một hệ thống con có trách nhiệm thi hành một SFR. Nếu một hệ thống con cung\r\ncấp (các thực thi) một TSFI SFR-thực thi, thì sau đó hệ thống con là SFR thực\r\nthi.
\r\n\r\nCác hệ thống con cũng có thể được xác định là\r\nSFR hỗ trợ và SFR không can thiệp. Một hệ thống con SFR hỗ trợ là một hệ thống\r\nbị phụ thuộc bởi một hệ thống con SFR thực thi, để thi hành SFR, nhưng không có\r\nvai trò trực tiếp như một hệ thống con SFR thực thi. Một hệ thống con SFR không\r\ncan thiệp là một hệ thống trong đó không phụ thuộc vào cả hai vai trò hỗ trợ\r\nhoặc thực thi, để thi hành một SFR.
\r\n\r\nA.4.2. Các mô đun
\r\n\r\nModule tổng quan là một khối kiến trúc tương\r\nđối nhỏ có thể được đặc trưng trong giới hạn các thuộc tính được thảo luận\r\ntrong nội bộ TSF (ADV_INT). Khi cả hai yêu cầu thiết kế mô-đun cơ bản ADV_TDS.3\r\n(hoặc ở trên) và yêu cầu nội bộ TSF (ADV_INT) có mặt trong một PP hoặc ST, thì\r\nmột “module” trong giới hạn các yêu cầu thiết kế TOE (ADV_TDS) đề cập đến cùng\r\nmột thực thể như là một “module” cho yêu cầu nội bộ TSF (ADV_INT). Không giống\r\nnhư các hệ thống con, module mô tả việc thực thi ở một mức độ chi tiết có thể\r\nphục vụ như một hướng dẫn để xem xét các đại diện thực thi.
\r\n\r\nĐiều quan trọng cần lưu ý rằng, tùy thuộc vào\r\nTOE, các mô-đun và các hệ thống con có thể đề cập đến cùng sự trừu tượng. Đối\r\nvới thiết kế cơ bản ADV_TDS.1 và thiết kế kiến trúc ADV_TDS.2 (mà không yêu cầu\r\nmô tả ở cấp module), mô tả hệ thống con cung cấp các chi tiết mức thấp nhất sẵn\r\ncó về các TSF. Đối với thiết kế mô-đun cơ bản ADV_TDS.3 (mà yêu cầu mô tả\r\nmodule), thì những mô tả này cung cấp mức thấp nhất của chi tiết, trong khi mô\r\ntả hệ thống con (nếu chúng tồn tại như những thực thể riêng biệt) chỉ đơn thuần\r\nphục vụ cho việc đưa vào các mô tả module. Đó là, nó không nhất thiết để cung\r\ncấp các mô tả hệ thống con chi tiết nếu mô tả module tồn tại. Trong các TOE đơn\r\ngiản, một “mô tả hệ thống con” riêng biệt là không cần thiết; các yêu cầu có\r\nthể đáp ứng thông qua các tài liệu được cung cấp bởi mô-đun. Đối với các TOE\r\nphức tạp, mục đích của các mô tả hệ thống con (đối với các TSF) là cung cấp cho\r\nngười đọc bối cảnh để họ có thể tập trung vào những phân tích của họ một cách\r\nthích hợp. Sự khác biệt này được minh họa trong Hình A.3.
\r\n\r\nMột mô đun SFR - thực thi là một mô-đun trực\r\ntiếp thi hành một yêu cầu chức năng an toàn (SFR) trong ST. Mô-đun như vậy\r\nthường sẽ thi hành một TSFI SFR-thực thi, nhưng một số chức năng thể hiện trong\r\nmột SFR (ví dụ đối với kiểm toán và các chức năng tái sử dụng đối tượng) có thể\r\nkhông trực tiếp gắn liền với một TSFI đơn nhất. Như trường hợp với các hệ thống\r\ncon, module SFR hỗ trợ là những module bị phụ thuộc bởi module SFR thực thi,\r\nnhưng không chịu trách nhiệm trực tiếp thi hành một SFR. Các mô đun SFR không\r\ncan thiệp là những module mà không xử lý, trực tiếp hoặc gián tiếp, với việc\r\nthi hành SFR.
\r\n\r\nĐiều quan trọng cần lưu ý rằng việc xác định\r\n“thực thi trực tiếp” nào có nghĩa là hơi chủ quan. Trong nghĩa hẹp của thuật\r\nngữ, nó có thể được giải thích theo nghĩa một hoặc hai đường của mã thực sự\r\nthực hiện một so sánh, hoạt động zeroing, v.v… mà thi hành một yêu cầu. Một\r\ngiải thích rộng hơn có thể bao gồm các module viện dẫn ra để trả lời một TSFI\r\nSFR thực thi, và tất cả các module có thể được gọi lần lượt bởi module đó (và\r\nnhư vậy cho đến khi hoàn thành cuộc gọi). Cả hai giải thích đó đều không đặc\r\nbiệt đáp ứng, vì theo nghĩa hẹp của sự giải thích đầu tiên có thể dẫn đến các\r\nmodule quan trọng không được phân loại chính xác như SFR hỗ trợ, và thứ hai là\r\ndẫn đến các mô đun thực sự không phải SFR thực thi đang được phân loại như vậy.
\r\n\r\nMột mô tả của một module nên được như vậy để\r\nngười ta có thể tạo ra một thực thi của các mô-đun từ mô tả, và việc thực thi\r\nkết quả sẽ là 1) trùng với việc thực thi TSF thực tế trong giới hạn các giao diện\r\ntrình bày và sử dụng bởi mô-đun, và 2) thuật toán giống với các module TSF. Ví\r\ndụ, RFC 793 cung cấp một mô tả cấp cao của giao thức TCP. Nó nhất thiết sự độc\r\nlập trong thực thi. Trong khi nó cung cấp rất nhiều chi tiết, thì nó không phải\r\nlà một mô tả thiết kế phù hợp bởi vì nó không cụ thể cho một thực thi. Một thực\r\nthi thực tế có thể thêm vào các giao thức được quy định trong RFC, và sự lựa\r\nchọn thực thi (ví dụ, việc sử dụng các dữ liệu toàn cầu so với dữ liệu cục bộ ở\r\nnhiều phần thực thi) có thể có tác động tới các phân tích đang thực hiện. Mô tả\r\nthiết kế của module TCP sẽ lập nên danh sách các giao diện trình bày sự thực\r\nthi (thay vì chỉ những cái được định nghĩa trong RFC 793), cũng như một mô tả\r\nthuật toán xử lý các liên kết với các mô-đun thực thi TCP (Giả sử họ là một\r\nphần của TSF).
\r\n\r\nTrong thiết kế, mô-đun mô tả chi tiết trong\r\ngiới hạn chức năng mà chúng cung cấp (mục đích); các giao diện chúng trình bày,\r\ncác giá trị trở về từ các giao diện như vậy, các giao diện (được trình bày bởi\r\ncác module khác) mà chúng sử dụng, và một mô tả về cách chúng cung cấp chức\r\nnăng của mình (một cách có thể cho mô tả các chức năng là một mô tả thuật\r\ntoán).
\r\n\r\nMục đích của một module nên được mô tả thấy\r\nđược chức nào mà module cung cấp. Nó nên đầy đủ để người đọc có thể nắm bắt\r\nđược một ý tưởng chung của những chức năng của mô-đun trong kiến trúc.
\r\n\r\nCác giao diện trình bày của một module là\r\nnhững giao diện được sử dụng bởi các module khác để viện dẫn chức năng cung\r\ncấp. Giao diện bao gồm cả giao diện hiện (ví dụ, một trình tự gọi viện dẫn bởi\r\ncác mô đun khác) cũng như các giao diện ẩn (ví dụ dữ liệu toàn cầu thao tác bởi\r\nmodule). Giao diện này được mô tả trong giới hạn chúng được viện dẫn thế nào,\r\nvà bất kỳ giá trị được trả về. Mô tả này sẽ bao gồm một danh sách các thông số,\r\nvà những mô tả về các thông số này. Nếu một tham số được dự kiến sẽ đưa vào một\r\ntập hợp các giá trị (ví dụ, một tham số “cờ”), thì việc thiết lập đầy đủ các\r\ngiá trị của tham số đó có thể đảm nhận, sẽ tác dụng trên mô đun đang trong tiến\r\ntrình được chỉ định. Tương tự như vậy, các thông số đại diện cho cấu trúc dữ\r\nliệu được mô tả tới mức mỗi trường của cấu trúc dữ liệu cũng được xác định và\r\nmô tả. Dữ liệu toàn cầu nên được mô tả như dù là nó được đọc hoặc ghi (hoặc cả\r\nhai) bởi module.
\r\n\r\nLưu ý rằng ngôn ngữ lập trình khác nhau có\r\nthể có thêm các “giao diện” mà có thể không rõ ràng; chẳng hạn sẽ là người vận\r\nhành/chức năng quá tải trong C++. “giao diện ẩn” này trong mô tả lớp cũng sẽ\r\nđược mô tả như là một phần của thiết kế mô-đun. Lưu ý rằng mặc dù một module có\r\nthể chỉ trình bày một giao diện, nó phổ biến hơn là một mô-đun trình bày một\r\ntập hợp nhỏ các giao diện liên quan.
\r\n\r\nNgược lại, giao diện sử dụng bởi các module\r\nphải được nhận biết rõ để có thể xác định được module nào đang được viện dẫn\r\nbởi mô đun được mô tả. Cần phải rõ ràng từ mô tả thiết kế, sở cứ thuật toán\r\nhọc, mô đun đang được viện dẫn ra. Ví dụ, nếu Module A được mô tả, và nó sử\r\ndụng thường trình sắp xếp bubble của Module B, thì một mô tả thuật toán không\r\nđầy đủ sẽ là “Module A viện dẫn ra giao diện double_bubble () trong Module B để\r\nthực hiện một sắp xếp bubble”. Một mô tả thuật toán đầy đủ sẽ là “Module A viện\r\ndẫn ra thường trình double_bubble với danh sách các mục điều khiển truy cập;\r\ndouble_bubble () sẽ trả về các mục được sắp xếp đầu tiên là tên người dùng, sau\r\nđó là trường access_allowed theo quy tắc sau đây…” Mô tả chi tiết của một\r\nmodule trong thiết kế phải cung cấp đủ chi tiết để thấy rõ được tác dụng nào mà\r\nModule A là mong đợi từ giao diện sắp xếp bubble. Lưu ý rằng một trong những\r\nphương pháp trình bày này được gọi là các giao diện thông qua một cây cuộc gọi,\r\nvà khi đó mô tả thuật toán có thể được bao gồm trong mô tả thuật toán của các\r\nmodule gọi.
\r\n\r\nNhư đã thảo luận trước, mô tả thuật toán của\r\nmodule nên mô tả một cách thuật toán thực thi các module. Điều này có thể được\r\nthực hiện trong mã giả, thông qua các biểu đồ dòng chảy, hoặc (ADV_TDS.3 thiết\r\nkế mô-đun cơ bản) dạng văn bản. Nó bàn về cách thức các đầu vào mô-đun và các\r\nchức năng gọi được sử dụng để hoàn thành chức năng của module. Nó ghi chú sự\r\nthay đổi dữ liệu toàn cầu, trạng thái hệ thống, và các giá trị trả lại được tạo\r\nbởi module. Đó là ở cấp độ chi tiết mà một thực thi có thể phát sinh, có thể\r\nrất giống với một thực thi thực tế của TOE.
\r\n\r\nCần lưu ý rằng mã nguồn không đáp ứng yêu cầu\r\ntài liệu minh chứng mô-đun. Mặc dù thiết kế module mô tả việc thực thi đó,\r\nnhưng nó không phải là một thực thi. Các ý kiến xung quanh các mã nguồn có thể\r\nlà tài liệu minh chứng đầy đủ nếu chúng cung cấp một lời giải thích về mục đích\r\ncủa mã nguồn.
\r\n\r\nTrong các phần tử dưới đây, các nhãn (SFR\r\nthực thi, SFR hỗ trợ, và SFR không can thiệp) được thảo luận đối với các hệ\r\nthống con và các mô-đun được sử dụng để mô tả số lượng và loại thông tin cần\r\ntạo sẵn bởi nhà phát triển. Các phần tử đã được cấu trúc như vậy là để không có\r\nkỳ vọng để các nhà phát triển cung cấp chỉ thông tin được quy định. Đó là, nếu\r\ntài liệu minh chứng của TSF của nhà phát triển cung cấp các thông tin trong các\r\nyêu cầu dưới đây, không có kỳ vọng rằng các nhà phát triển cập nhật tài liệu\r\nminh chứng của họ và các hệ thống con và mô-đun nhãn như SFR thực thi, SFR hỗ\r\ntrợ, và SFR không can thiệp. Mục đích chính của việc gán nhãn này là cho phép\r\ncác nhà phát triển với những phương pháp phát triển chưa hoàn thiện (và hiện\r\nvật liên quan, chẳng hạn như giao diện chi tiết và tài liệu minh chứng thiết\r\nkế) cung cấp bằng chứng cần thiết mà không cần chi phí quá mức.
\r\n\r\nA.4.3. Phương thức phân mức
\r\n\r\n| \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n ||||
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n ADV_TDS.1 Thiết kế cơ bản (trình bày không\r\n chính thức) \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n ADV_TDS.2 Thiết kế kiến trúc (trình bày\r\n không chính thức) \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n ADV_TDS.3 Thiết kế mô đun cơ bản (trình bày\r\n không chính thức) \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n ADV_TDS.4 Thiết kế mô đun bán chính thức\r\n (trình bày bán chính thức) \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n ADV_TDS.5 Thiết kế mô đun bán chính thức\r\n đầy đủ (trình bày bán chính thức) \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n ADV_TDS.6 Thiết kế mô đun bán chính thức\r\n đầy đủ với trình bày thiết kế mức cao chính thức (trình bày bán chính thức;\r\n trình bày chính thức bổ sung) \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
(1) Hỗ trợ thiết kế: nghĩa là chỉ cần\r\ncác tài liệu đủ cho hỗ trợ phân loại hệ thống con/mô đun.
\r\n\r\n(2) Giao diện SFR: nghĩa là mô tả mô\r\nđun có chứa các giá trị trả về và các giao diện được gọi tới các mô đun khác\r\ncho mỗi giao diện liên quan SFR.
\r\n\r\n(3) Mọi giao diện: nghĩa là mô tả mô\r\nđun có chứa các giá trị trả về và các giao diện được gọi tới các mô đun khác\r\ncho mỗi giao diện.
\r\n\r\nBởi vì có tính chủ quan trong việc xác định\r\ncái nào là SFR thực thi với SFR hỗ trợ (và trong một số trường hợp, thậm chí\r\nxác định cái nào là SFR không can thiệp) các mô hình sau đây đã được áp dụng\r\ntrong họ này. Trong phần đầu của họ, nhà phát triển tạo ra một quyết định về\r\nviệc phân loại các hệ thống con thành SFR thực thi, v.v..., cung cấp các thông\r\ntin thích hợp, và có một số bằng chứng bổ sung cho các thẩm định viên xem xét\r\nđể hỗ trợ tuyên bố này. Vì mức độ đảm bảo mong muốn gia tăng, trong khi nhà\r\nphát triển vẫn tạo một quyết định phân loại, thì thẩm định viên có được càng\r\nnhiều bằng chứng được sử dụng để xác nhận việc phân loại của nhà phát triển.
\r\n\r\nĐể tập trung phân tích các đánh giá thẩm định\r\nviên trên các phần SFR liên quan của TOE, đặc biệt là ở cấp đảm bảo thấp hơn,\r\ncác thành phần của họ được phân mức để thông tin chi tiết ban đầu được yêu cầu\r\nchỉ cho các thực thể kiến trúc SFR thực thi. Vì mức độ đảm bảo gia tăng, nên\r\nnhiều thông tin được yêu cầu cho SFR hỗ trợ và (cuối cùng) các thực thể SFR-không\r\ncan thiệp. Cần lưu ý rằng ngay cả khi thông tin đầy đủ được yêu cầu, thì nó\r\ncũng không được yêu cầu để tất cả các thông tin này được phân tích trong cùng\r\nmột mức độ chi tiết. Trong mọi trường hợp nên tập trung vào việc liệu các thông\r\ntin cần thiết đã được cung cấp và phân tích.
\r\n\r\nBảng A.1 tóm tắt các thông tin yêu cầu tại\r\nmỗi của những thành phần họ đối với các thực thể kiến trúc được mô tả.
\r\n\r\nA.5. Tài liệu bổ trợ về phương pháp chính\r\nthức
\r\n\r\nPhương pháp chính quy cung cấp sự trình bày\r\nvề toán học của TSF và cách xử lý của nó và được yêu cầu bởi ADV_FSP.6 Đặc tả\r\nchức năng bán chính thức đầy đủ, ADV_SPM.1 mô hình chính sách an toàn TOE chính\r\nthức, và ADV_TDS.6 thiết kế mô-đun chính thức đầy đủ với các thành phần trình\r\nbày thiết kế cấp cao chính quy. Có hai khía cạnh của phương pháp chính quy:\r\nngôn ngữ đặc tả được sử dụng để biểu thị chính thức, và định lý chứng minh để\r\nchứng minh sự đầy đủ và chính xác về toán học của các đặc tả chính thức.
\r\n\r\nMột đặc tả chính thức được thể hiện trong một\r\nhệ thống dựa trên các khái niệm toán học đã được xác minh. Những khái niệm toán\r\nhọc này được sử dụng để xác định rõ ràng ngữ nghĩa, cú pháp và các quy tắc của\r\nsuy luận. Một hệ thống chính quy là một hệ thống nhận dạng và mối quan hệ trừu\r\ntượng có thể được mô tả bằng cách chỉ định một bảng chữ cái chính thức, một\r\nngôn ngữ chính thức trên bảng chữ cái dựa trên một cú pháp chính thức, và một\r\ntập quy tắc chính thức của suy luận cho việc xây dựng các dẫn xuất của câu\r\ntrong ngôn ngữ chính quy.
\r\n\r\nCác thẩm định viên phải kiểm tra việc hệ\r\nthống chính quy nhận dạng để đảm bảo rằng:
\r\n\r\n● Các quy tắc ngữ nghĩa, cú pháp và suy luận\r\ncủa hệ thống chính quy được định nghĩa hay định nghĩa được tham chiếu.
\r\n\r\n● Mỗi hệ thống chính quy có kèm theo văn bản\r\ngiải thích để cung cấp nghĩa ngữ được định nghĩa sao cho
\r\n\r\n1) các văn bản giải thích đưa ra ý nghĩa được\r\nđịnh nghĩa của các từ ngữ, chữ viết tắt và từ viết tắt được sử dụng trong một\r\nngữ cảnh khác được chấp nhận sử dụng bình thường;
\r\n\r\n2) việc sử dụng một hệ thống chính thức và sử\r\ndụng ký hiệu bán chính thức được đi kèm bằng cách hỗ trợ văn bản giải thích\r\ntheo cách thức phù hợp với ý nghĩa rõ ràng;
\r\n\r\n3) hệ thống chính thức có thể thể hiện các\r\nquy tắc và đặc điểm của SFP áp dụng, chức năng bảo mật và các giao diện (quy\r\nđịnh chi tiết các hiệu ứng, ngoại lệ và thông báo lỗi) của TSF, hệ thống phụ\r\nhoặc các mô-đun của chúng được chỉ định cho các họ đảm bảo với ký hiệu được sử\r\ndụng;
\r\n\r\n4) ký hiệu cung cấp các quy tắc để xác định ý\r\nnghĩa của các cấu trúc cú pháp hợp lệ.
\r\n\r\n● Mỗi hệ thống chính thức sử dụng một cú pháp\r\nchính thức cung cấp các quy tắc để nhận ra các cấu trúc rõ ràng.
\r\n\r\n● Mỗi hệ thống các quy tắc chính thức cung\r\ncấp bằng chứng mà
\r\n\r\n5) hỗ trợ lý luận hợp lý của các khái niệm\r\ntoán học thiết lập tốt,
\r\n\r\n6) giúp ngăn chặn nguồn gốc của mâu thuẫn.
\r\n\r\nNếu nhà phát triển sử dụng một hệ thống chính\r\nthức mà đã được chấp nhận bởi cơ quan đánh giá, thẩm định viên có thể dựa vào\r\nmức độ hình thức và sức mạnh của hệ thống và tập trung vào các thuyết minh của\r\nhệ thống chính thức cho các đặc tả TOE và chứng minh thư.
\r\n\r\nCách thức chính quy hỗ trợ chứng minh toán\r\nhọc của tài sản bảo đảm dựa trên các tính năng bảo mật, tính thống nhất của các\r\nsàng lọc và thư từ của các cơ quan đại diện.
\r\n\r\nVí dụ về các hệ thống chính thức:
\r\n\r\n● Ngôn ngữ đặc tả Z là có ý, và hỗ trợ nhiều\r\nphương pháp khác nhau hoặc phong cách của đặc tả kỹ thuật chính thức
\r\n\r\n● Việc sử dụng Z đã được chủ yếu cho các đặc\r\nđiểm kỹ thuật theo định hướng mô hình, sử dụng lược đồ để chính thức chỉ định\r\nhoạt động. Xem http://vl.zuser.org/.
\r\n\r\n● ACL2 là một mã nguồn mở chính thức hệ thống\r\nbao gồm một ngôn ngữ dựa trên đặc điểm kỹ thuật LISP và Prover một định lý. Xem\r\nhttp://www.cs.utexas.edu/users/moore/acl2/ cho biết thêm thông tin.
\r\n\r\n● Isabelle là một định lý chung phổ biến\r\nchứng minh môi trường cho phép các công thức toán học được thể hiện bằng một\r\nngôn ngữ chính thức và cung cấp công cụ thể chứng minh những công thức trong\r\nmột tính toán hợp lý (http://www.cl.cam.ac.uk/Research/HVG/Isabelle /).
\r\n\r\n● Phương pháp B là một hệ thống chính thức\r\ndựa trên các phép tính mệnh đề, các phép tính đơn hàng đầu tiên vị với các quy\r\ntắc suy luận và lý thuyết tập hợp (ví dụ http://vl.fmnet.info/b/).
\r\n\r\nMục tiêu của phụ lục này là để giải thích các\r\nkhái niệm đằng sau đánh giá tổng hợp và các tiêu chuẩn ACO. Phụ lục này không\r\nđịnh nghĩa các tiêu chí ASE; định nghĩa này có thể được tìm thấy tại mục 10.
\r\n\r\nB.1. Sự cần thiết đối với các đánh giá TOE\r\ntổng hợp
\r\n\r\nThị trường CNTT được tạo thành từ sự cung cấp\r\nmột loại hình sản phẩm/công nghệ của nhà cung cấp. Mặc dù có một số loại hình\r\nchồng lẫn nhau, khi mà một nhà cung cấp phần cứng máy tính cũng có thể cung cấp\r\nphần mềm ứng dụng và/hoặc hệ điều hành hoặc nhà sản xuất chip cũng có thể phát\r\ntriển một hệ điều hành dành riêng cho các chipset của chính họ, thường thấy đó\r\nlà trường hợp một giải pháp CNTT được thực hiện bởi nhiều nhà cung cấp khác\r\nnhau.
\r\n\r\nĐôi khi cần phải đảm bảo trong sự kết hợp (sự\r\ntổng hợp) của các thành phần ngoài sự đảm bảo của các thành phần riêng lẻ. Mặc\r\ndù có sự hợp tác giữa các nhà cung cấp, trong việc phổ biến của vật chất nhất\r\nđịnh cần thiết cho việc tích hợp kỹ thuật của các thành phần, các thỏa thuận\r\nhiếm khi kéo dài đến mức cung cấp thông tin thiết kế chi tiết và quá trình phát\r\ntriển/thủ tục bằng chứng. Việc thiếu thông tin từ nhà phát triển về một thành\r\nphần mà thành phần khác phụ thuộc, có nghĩa là các nhà phát triển thành phần\r\nphụ thuộc không có quyền truy cập vào các loại thông tin cần thiết để thực hiện\r\nmột đánh giá của cả hai thành phần phần phụ thuộc và cơ sở tại EAL2 hoặc cao hơn.\r\nVì vậy, trong khi một đánh giá của các thành phần phụ thuộc vẫn có thể được\r\nthực hiện ở bất cứ cấp đảm bảo nào, để soạn các thành phần với bảo đảm tại EAL2\r\nhoặc ở trên, nó là cần thiết để tái sử dụng các bằng chứng và kết quả đánh giá\r\nđược thực hiện đối với các nhà phát triển thành phần.
\r\n\r\nĐiều mong đợi là các tiêu chí ACO có thể áp\r\ndụng trong hoàn cảnh mà một thực thể IT phụ thuộc vào thực thể IT khác để cung\r\ncấp các dịch vụ an toàn. Các thực thể cung cấp các dịch vụ được gọi là, “thành\r\nphần cơ sở”, và nhận các dịch vụ được gọi là, “thành phần phụ thuộc”. Mối quan\r\nhệ này có thể tồn tại trong một số ngữ cảnh. Ví dụ, một ứng dụng (thành phần\r\nphụ thuộc) có thể sử dụng dịch vụ được cung cấp bởi một hệ điều hành (thành\r\nphần cơ sở). Ngoài ra, mối quan hệ có thể là peer-to-peer, trong ý nghĩa của\r\nhai ứng dụng liên kết, hoặc là đang chạy trong một môi trường hệ điều hành phổ\r\nbiến, hoặc trên các nền tảng phần cứng riêng biệt. Nếu có một đồng đẳng chi\r\nphối cung cấp các dịch vụ cho các đồng đẳng thứ yếu, thì các đồng đẳng chi phối\r\nđược coi là thành phần cơ sở và đồng đẳng thứ yếu là thành phần phụ thuộc. Nếu\r\ncác đồng đẳng cung cấp dịch vụ với nhau theo một cách thức chung nhau, mỗi đồng\r\nđẳng sẽ được coi là thành phần cơ sở cho các dịch vụ được cung cấp và thành\r\nphần phụ thuộc cho các dịch vụ được yêu cầu. Điều này đòi hỏi sự lặp lại của\r\nnhững thành phần ACO áp dụng tất cả các yêu cầu với từng loại thành phần đồng\r\nđẳng.
\r\n\r\nCác tiêu chí này cũng dự định sẽ được áp dụng\r\nrộng rãi hơn, từng bước (nơi một TOE tổng hợp bao gồm một thành phần phụ thuộc\r\nvà một thành phần cơ sở mà bản thân nó đã trở thành một thành phần cơ sở của\r\nmột TOE tổng hợp khác), trong nhiều mối quan hệ phức tạp, nhưng điều này có thể\r\nyêu cầu giải thích thêm.
\r\n\r\nĐiều cần thiết các đánh giá TOE tổng hợp là\r\ncác thành phần riêng rẽ được đánh giá độc lập, vì việc đánh giá tổng hợp xây\r\ndựng dựa trên các kết quả đánh giá thành phần riêng rẽ. Việc đánh giá của các\r\nthành phần phụ thuộc có thể vẫn đang được tiến hành khi bắt đầu đánh giá TOE\r\ntổng hợp. Tuy nhiên, việc đánh giá thành phần phụ thuộc phải hoàn thành trước\r\nkhi đánh giá TOE tổng hợp hoàn tất.
\r\n\r\nCác hoạt động đánh giá tổng hợp có thể diễn\r\nra đồng thời với đánh giá thành phần phụ thuộc. Điều này là do hai yếu tố:
\r\n\r\na) Những bộ phận điều khiển về kinh tế/thương\r\nmại - nhà phát triển thành phần phụ thuộc hoặc là sẽ tài trợ cho các hoạt động\r\nđánh giá tổng hợp hoặc hỗ trợ các hoạt động này như các đánh giá phân rã từ\r\nviệc đánh giá thành phần phụ thuộc được yêu cầu cho hoạt động đánh giá tổng\r\nhợp.
\r\n\r\nb) Những bộ phận điều khiển về kỹ thuật - các\r\nthành phần xem xét liệu việc bảo đảm cần thiết có được cung cấp bởi các thành\r\nphần cơ sở (ví dụ như xem xét các thay đổi trong thành phần cơ sở kể từ khi\r\nhoàn thành việc đánh giá thành phần) với sự hiểu biết về các thành phần phụ\r\nthuộc gần đây đã trải qua (đang trải qua) đánh giá thành phần và tất cả các\r\nđánh giá phân rã được kết hợp với đánh giá sẵn có. Vì vậy, không có các hoạt\r\nđộng trong khi tổng hợp, khi tổng hợp đó có yêu cầu các hoạt động đánh giá\r\nthành phần phụ thuộc phải được thẩm tra lại. Ngoài ra, nó được thẩm tra rằng\r\ncác thành phần cơ sở tạo thành (một trong) các cấu hình kiểm thử cho việc kiểm\r\nthử các thành phần phụ thuộc trong việc đánh giá thành phần phụ thuộc, để lại\r\nACO_CTT để xem xét các thành phần cơ sở trong cấu hình này.
\r\n\r\nCác bằng chứng đánh giá từ việc đánh giá các\r\nthành phần phụ thuộc là yêu cầu đầu vào cho các hoạt động đánh giá TOE tổng\r\nhợp. Chỉ các tài liệu đánh giá từ việc đánh giá của các thành phần cơ sở mà\r\nđược yêu cầu như là đầu vào cho các hoạt động đánh giá TOE tổng hợp:
\r\n\r\na) Các điểm yếu dư trong thành phần cơ sở,\r\nđược báo cáo trong quá trình đánh giá thành phần cơ sở. Điều này được yêu cầu\r\ncho các hoạt động ACO_VUL.
\r\n\r\nKhông có bằng chứng đánh giá khác từ thành\r\nphần cơ sở các hoạt động nên được yêu cầu cho việc đánh giá TOE tổng hợp, khi đó\r\nkết quả đánh giá từ việc đánh giá thành phần của các thành phần cơ sở nên được\r\nsử dụng lại. Thông tin thêm về các thành phần cơ sở có thể được yêu cầu nếu các\r\nTOE tổng hợp TSF gồm nhiều thành phần cơ sở hơn đã được xem xét là TSF trong\r\ncác đánh giá thành phần của các thành phần cơ sở.
\r\n\r\nViệc đánh giá thành phần của các thành phần\r\ncơ sở và phụ thuộc được giả định là hoàn thành vào thời gian phán quyết cuối\r\ncùng được giao cho các thành phần ACO.
\r\n\r\nCác thành phần ACO_VUL chỉ xem xét sức bền\r\nchống lại kẻ tấn công với một cuộc tấn công tiềm ẩn lên đến Cơ bản được nâng\r\ncao. Điều này là do mức độ thông tin thiết kế cho biết cách thành phần cơ sở\r\ncung cấp các dịch vụ mà ở đó các thành phần phụ thuộc dựa vào như thế nào thông\r\nqua các ứng dụng của các hoạt động ACO_DEV. Do đó, tính bí mật phát sinh từ\r\nđánh giá TOE tổng hợp sử dụng CAP được giới hạn trong một mức độ tương tự như\r\nthu được từ đánh giá TOE thành phần EAL4. Mặc dù bảo đảm trong các thành phần\r\nđó bao gồm các TOE tổng hợp có thể cao hơn EAL4.
\r\n\r\nB.2. Thực hiện đánh giá Mục tiêu An toàn đánh\r\ngiá đối với một TOE tổng hợp
\r\n\r\nMột ST sẽ được đệ trình bởi nhà phát triển\r\ncho việc đánh giá các TOE tổng hợp (thành phần cơ sở + thành phần phụ thuộc).\r\nST này sẽ xác định các gói đảm bảo được áp dụng cho các TOE tổng hợp, cung cấp\r\nsự bảo đảm trong thực thể được tổng hợp bằng cách lấy ra khi sự đảm bảo đã đạt\r\nđược trong các đánh giá thành phần.
\r\n\r\nMục đích của việc xem xét sự tổng hợp của các\r\nthành phần trong ST một là để xác nhận sự phù hợp của các thành phần từ điểm\r\nnhìn của cả môi trường và các yêu cầu, và cũng để đánh giá rằng các ST TOE tổng\r\nhợp là phù hợp với các ST thành phần và chính sách an toàn thể hiện trong chúng.\r\nĐiều này bao gồm việc xác định rằng các ST thành phần và chính sách an toàn thể\r\nhiện trong đó là tương thích.
\r\n\r\nCác ST TOE tổng hợp có thể nhắc đến bên ngoài\r\nnội dung của ST thành phần, hoặc tác giả ST có thể chọn để nhắc lại những tài\r\nliệu của ST thành phần bên trong ST TOE tổng hợp cung cấp một sở cứ về ST thành\r\nphần được thể hiện trong ST TOE tổng hợp như thế nào.
\r\n\r\nTrong việc thực hiện các hoạt động đánh giá ASE_CCL\r\ncho một ST TOE tổng hợp, nhà đánh giá xác định rằng các ST thành phần là đại diện\r\nchính xác trong các ST TOE tổng hợp. Điều này đạt được thông qua việc xác định\r\nrằng các ST TOE tổng hợp phù hợp với các ST TOE thành phần. Ngoài ra, các nhà\r\nđánh giá sẽ cần phải xác định rằng sự phụ thuộc của các thành phần phụ thuộc\r\ntrên môi trường hoạt động được đáp ứng đầy đủ trong TOE tổng hợp.
\r\n\r\nMô tả TOE tổng hợp sẽ mô tả giải pháp được\r\ntổng hợp. Phạm vi logic và vật lý và ranh giới của giải pháp tổng hợp sẽ được\r\nmô tả, và (các) ranh giới về logic giữa các thành phần cũng sẽ được xác định.\r\nNhững mô tả này sẽ xác định các chức năng an toàn được cung cấp bởi mỗi thành\r\nphần.
\r\n\r\nTuyên bố của các SFR đối với TOE tổng hợp sẽ\r\nxác định được thành phần nào là thỏa mãn một SFR. Nếu một SFR được đáp ứng bởi\r\ncả hai thành phần, thì tuyên bố đó sẽ xác định được thành phần nào đáp ứng các\r\nkhía cạnh khác nhau của SFR. Tương tự, Đặc điểm Tóm tắt TOE tổng hợp sẽ xác\r\nđịnh thành phần nào cung cấp chức năng an toàn được mô tả.
\r\n\r\nCác gói của ASE: các yêu cầu đánh giá Mục\r\ntiêu An toàn áp dụng cho các ST TOE tổng hợp nên nhất quán với các gói của ASE:\r\ncác yêu cầu đánh giá Mục tiêu An toàn được sử dụng trong các đánh giá thành\r\nphần.
\r\n\r\nTái sử dụng kết quả đánh giá từ đánh giá của\r\ncác ST thành phần có thể được thực hiện trong các trường hợp mà các ST TOE tổng\r\nhợp trực tiếp đề cập đến các ST thành phần, ví dụ: nếu ST TOE tổng hợp đề cập\r\nđến một ST thành phần đối với một phần tuyên bố của SFR của nó, nhà đánh giá có\r\nthể hiểu rằng các yêu cầu cho việc hoàn thành tất cả các hoạt động chỉ định và\r\nlựa chọn (như đã nêu trong ASE_REQ.*.3C) đã được thỏa mãn trong các đánh giá\r\nthành phần.
\r\n\r\nB.3. Các tương tác giữa các thực thể CNTT\r\ntổng hợp
\r\n\r\nCác TSF của thành phần cơ sở thường được xác\r\nđịnh mà không biết về sự phụ thuộc của các ứng dụng có thể có mà nó có thể có\r\nnhờ được tổng hợp. Các TSF của thành phần cơ sở này được định nghĩa bao gồm tất\r\ncả các bộ phận của các thành phần cơ sở, là các thành phần phải dựa vào thực\r\nthi của SFR thành phần cơ sở. Điều này sẽ bao gồm tất cả các bộ phận của các\r\nthành phần cơ sở được yêu cầu để thực thi các SFR thành phần cơ sở.
\r\n\r\nTSFI của thành phần cơ sở này đại diện cho\r\ncác giao diện được cung cấp bởi các TSF đối với các thực thể bên ngoài, các\r\nthực thể này đã được định nghĩa trong tuyên bố của SFR để gọi một dịch vụ của\r\nTSF. Điều này bao gồm các giao diện cho người sử dụng thuộc về con người và\r\ncũng có giao diện cho các thực thể CNTT bên ngoài. Tuy nhiên, TSFI chỉ bao gồm\r\nnhững giao diện cho các TSF, và do đó không nhất thiết phải là một đặc tả giao\r\ndiện đầy đủ của tất cả các giao diện có thể có giữa một thực thể bên ngoài và\r\nthành phần cơ sở. Thành phần cơ sở có thể trình bày các giao diện cho các dịch\r\nvụ không được coi là an toàn-có liên quan, hoặc vì mục đích vốn có của các dịch\r\nvụ (ví dụ, điều chỉnh phông chữ) hoặc bởi vì SFR theo tiêu chuẩn ISO/IEC 15408\r\nliên quan, không được tuyên bố trong ST của các thành phần cơ sở (ví dụ như\r\ngiao diện đăng nhập khi không có FIA theo tiêu chuẩn ISO/IEC 15408-2: SFR Định\r\ndanh và xác thực được xác nhận).
\r\n\r\n![](\"00907948_files/image022.gif\")
Các giao diện chức năng cung cấp bởi các\r\nthành phần cơ sở nằm ngoài các giao diện an toàn (TSFIs), và không cần phải\r\nđược xem xét trong quá trình đánh giá thành phần cơ sở. Những giao diện này\r\nthường bao gồm các giao diện được sử dụng bởi một thành phần phụ thuộc để viện\r\ndẫn một dịch vụ được cung cấp bởi các thành phần cơ sở.
\r\n\r\nCác thành phần cơ sở có thể bao gồm một số\r\ncác giao diện gián tiếp thông qua đó TSFIs có thể được gọi, ví dụ: các API có\r\nthể được dùng để viện dẫn một dịch vụ của TSF, mà không được xem xét trong đánh\r\ngiá của các thành phần cơ sở.
\r\n\r\nCác thành phần phụ thuộc, dựa vào các thành\r\nphần cơ sở, được xác định tương tự: giao diện cho các thực thể bên ngoài định\r\nnghĩa trong các SFR của ST thành phần được phân loại như TSFI và được kiểm tra\r\ntrong ADV_FSP.
\r\n\r\nBất kỳ cuộc gọi ra từ các TSF phụ thuộc tới\r\nmôi trường hỗ trợ của một SFR sẽ cho thấy các TSF phụ thuộc yêu cầu một số dịch\r\nvụ từ môi trường để đáp ứng việc thực thi của các SFR thành phần phụ thuộc. Như\r\nmột dịch vụ nằm ngoài ranh giới thành phần phụ thuộc và các thành phần cơ sở là\r\nkhông được quy định tại các ST phụ thuộc như là một thực thể bên ngoài. Do đó,\r\ncác cuộc gọi cho các dịch vụ được thực hiện bởi các TSF phụ thuộc đến nền tảng\r\ncơ bản của nó (các thành phần cơ sở) sẽ không được phân tích như là một phần\r\ncủa hoạt động các đặc tả chức năng (ADV_FSP). Những phụ thuộc dựa vào thành\r\nphần cơ sở này được thể hiện trong ST thành phần phụ thuộc như mục tiêu an toàn\r\ncho môi trường.
\r\n\r\nSự trừu tượng này của các thành phần và các\r\ngiao diện phụ thuộc được hiển thị trong Hình B.2 dưới đây.
\r\n\r\n![](\"00907948_files/image023.jpg\")
Khi xem xét các thành phần của các thành phần\r\ncơ sở và thành phần phụ thuộc, nếu các thành phần phụ thuộc của TSF yêu cầu\r\ndịch vụ từ các thành phần cơ sở để hỗ trợ việc thực thi của SFR, thì giao diện\r\ncho dịch vụ sẽ cần phải được định nghĩa. Nếu dịch vụ được cung cấp bởi TSF của\r\nthành phần cơ sở, thì giao diện đó nên là một TSFI của thành phần cơ sở và do\r\nđó sẽ được xác định trong đặc tả chức năng của thành phần cơ sở.
\r\n\r\nTuy nhiên, nếu dịch vụ được gọi là bởi TSF\r\ncủa thành phần phụ thuộc không được cung cấp bởi TSF của thành phần cơ sở (tức\r\nlà, nó được thực thi trong các phần không phải TSF của thành phần cơ sở hoặc có\r\nthể ngay cả trong những phần không phải TOE của các thành phần cơ sở (không\r\nminh họa trong Hình B.3), không thể xảy ra là một TSFI của thành phần cơ sở\r\nliên quan đến dịch vụ đó, trừ các dịch vụ là trung gian của TSF của thành phần\r\ncơ sở. Các giao diện cho các dịch vụ này từ các thành phần phụ thuộc đến môi\r\ntrường hoạt động được xem xét trong họ Sự tin cậy của các thành phần phụ thuộc\r\n(ACO_REL).
\r\n\r\nCác phần không phải-TSF của thành phần cơ sở\r\nđược lấy vào trong TSF của TOE được tổng hợp do các sự phụ thuộc các thành phần\r\nphụ thuộc có trên thành phần cơ sở để hỗ trợ các SFR của thành phần phụ thuộc.\r\nDo vậy, trong trường hợp này, TSF của TOE tổng hợp lớn hơn tổng số các của các\r\nTSF của thành phần.
\r\n\r\n![](\"00907948_files/image024.jpg\")
Có thể là trường hợp, các thành phần cơ sở\r\nTSFI được gọi một cách không lường trước trong việc đánh giá thành phần cơ sở.\r\nDo đó sẽ có một yêu cầu cho việc thử nghiệm xa hơn của thành phần cơ sở TSFI.
\r\n\r\nCác giao diện có thể được tiếp tục được mô tả\r\ntrong sơ đồ (Hình B.4) và văn bản hỗ trợ sau.
\r\n\r\n![](\"00907948_files/image025.jpg\")
(1) Các mũi tên đi vào “thành phần phụ\r\nthuộc-a '(A và B) = nơi thành phần mong đợi môi trường đáp ứng một yêu cầu dịch\r\nvụ (trả lời các cuộc gọi ra từ các thành phần phụ thuộc vào môi trường);
\r\n\r\n(2) Các mũi tên ra khỏi “thành phần cơ sở-b '(C\r\nvà D) = các giao diện của các dịch vụ cung cấp bởi thành phần cơ sở cho môi\r\ntrường;
\r\n\r\n(3) đường gạch chấm giữa các thành phần = các\r\nloại thông tin liên lạc giữa các cặp của các giao diện;
\r\n\r\n(4) Các mũi tên (màu xám) còn lại = các giao\r\ndiện được mô tả bởi các tiêu chí nhất định.
\r\n\r\nSau đây là một trường hợp đơn giản, nhưng\r\ngiải thích những yếu tố cần được thực hiện.
\r\n\r\nCó thành phần một (‘thành phần phụ thuộc-a’)\r\nvà b (‘thành phần cơ sở-b’): các mũi tên ra khỏi TSF-a là các dịch vụ cung cấp\r\nbởi TSF-a và do đó là TSFI (a); tương tự, các mũi tên ra khỏi TSF-b (“C”) là\r\nTSFI (b). Thành phần a là để yêu cầu các dịch vụ từ môi trường của nó: chúng\r\ncần TSF (a) được gắn nhãn “A”, còn dịch vụ kia (không liên quan đến TSF-a) được\r\ngắn nhãn “B”.
\r\n\r\nKhi thành phần-a và thành phần-b được kết\r\nhợp, có bốn tổ hợp có thể có của {dịch vụ cần thiết bởi thành phần-a} và {dịch\r\nvụ được cung cấp bởi thành phần- b}, hiển thị như các đường đứt nét (các loại\r\nhình truyền thông giữa các cặp của các giao diện). Bất kỳ tập hợp nào của chúng\r\nđều có thể tồn tại cho một tổng hợp cụ thể:
\r\n\r\na) TSF-a yêu cầu các dịch vụ được cung cấp\r\nbởi TSF-b (“A” được kết nối với “C”); trường hợp đơn giản: các chi tiết về “C”\r\nđược đặt ở FSP cho thành phần-b. Trong trường hợp này các giao diện nên được\r\nđịnh nghĩa trong đặc tả chức năng cho thành phần-b.
\r\n\r\nb) Non-TSF-a yêu cầu các dịch vụ được cung\r\ncấp bởi TSF-b (“B” được kết nối với “C”): trường hợp đơn giản (lặp lại, các chi\r\ntiết về “C” được đặt ở FSP cho thành phần-b), nhưng không quan trọng: an toàn\r\nkhôn ngoan.
\r\n\r\nc) Non-TSF-a yêu cầu các dịch vụ được cung cấp\r\nbởi non-TSF-b (“B” được kết nối với “D”): chúng ta không có thông tin chi tiết\r\nvề D, nhưng không có sự liên quan an toàn về việc sử dụng các giao diện này, vì\r\nvậy chúng không cần phải được xem xét trong đánh giá, mặc dù chúng có thể sẽ là\r\nmột vấn đề hội nhập cho các nhà phát triển.
\r\n\r\nd) TSF-a yêu cầu các dịch vụ được cung cấp\r\nbởi không-TSF-b (“A” được kết nối với “D”): điều này sẽ xuất hiện khi thành\r\nphần-a và thành phần-b có nghĩa khác nhau về những gì một “dịch vụ bảo vệ”\r\nđược. Có lẽ b-thành phần làm cho không có tuyên bố về I & A (không có SFR\r\nFIA trong ST của nó), nhưng thành phần cần chứng thực được cung cấp bởi môi\r\ntrường của nó. Không có thông tin chi tiết về “D” giao diện có sẵn (họ không\r\nTSFI (b), vì vậy chúng không có trong thành phần SFP-b này).
\r\n\r\nLưu ý: nếu các loại tương tác được mô tả\r\ntrong trường hợp d trên tồn tại, sau đó là TSF của TOE sáng tác sẽ được TSF-a +\r\nTSF-b + Non-TSF-b. Nếu không, TSF của TOE sáng tác sẽ được TSF-a + TSF-b.
\r\n\r\nGiao diện loại 2 và 4 của Hình B.4 không trực\r\ntiếp liên quan đến việc thẩm định gồm TOE. Giao diện 1 và 3 sẽ được xem xét\r\ntrong quá trình ứng dụng của các gia đình khác nhau:
\r\n\r\na) đặc tả chức năng (ADV_FSP) (cho thành phần-b)\r\nsẽ mô tả các giao diện C.
\r\n\r\nb) Sự tin cậy của các thành phần phụ thuộc\r\n(ACO_REL) sẽ mô tả các giao diện A.
\r\n\r\nc) Bằng chứng phát triển (ACO_DEV) sẽ mô tả\r\ncác giao diện C cho kết nối loại 1 và các D giao diện cho kết nối loại 3.
\r\n\r\nMột ví dụ điển hình mà thành phần có thể được\r\náp dụng là một hệ thống quản lý cơ sở dữ liệu (DBMS) dựa vào hệ điều hành cơ\r\nbản của nó (OS). Trong đánh giá của các thành phần DBMS, sẽ có một đánh giá tạo\r\nnên từ các thuộc tính an toàn của DBMS đó (đến bất cứ độ nghiêm ngặt được quyết\r\nđịnh bởi thành phần bảo đảm sử dụng trong thẩm định): ranh giới TSF của nó sẽ\r\nđược xác định, đặc tả chức năng của nó được đánh giá để quyết định xem liệu nó\r\nmô tả các giao diện tới các dịch vụ an toàn cung cấp bởi TSF, có thể thông tin\r\nbổ sung về các TSF (thiết kế, kiến trúc, cấu trúc nội bộ của nó) sẽ được cung\r\ncấp, các TSF sẽ được thử nghiệm, các khía cạnh về vòng đời của nó và tài liệu\r\nhướng dẫn của nó sẽ được đánh giá, v.v…
\r\n\r\nTuy nhiên, việc đánh giá DBMS sẽ không gọi\r\ncho bất kỳ bằng chứng liên quan đến sự phụ thuộc DBMS có trên hệ điều hành. Các\r\nST của DBMS hầu như có khả năng phát biểu các giả định về hệ điều hành trong\r\nmục giả định của nó và phát biểu các mục tiêu an toàn cho hệ điều hành trong\r\nmục Môi trường của nó. Các ST DBMS thậm chí có thể thuyết minh những mục tiêu\r\nđó cho môi trường trong điều khoản của SFR cho hệ điều hành. Tuy nhiên, sẽ\r\nkhông có đặc tả cho hệ điều hành phản ánh chi tiết trong các đặc tả chức năng,\r\nmô tả kiến trúc, hoặc bằng chứng ADV khác như đối với các DBMS. Sự tin cậy của\r\ncác thành phần phụ thuộc (ACO_REL) sẽ đáp ứng yêu cầu đó.
\r\n\r\nSự tin cậy của các thành phần phụ thuộc\r\n(ACO_REL) mô tả các giao diện của TOE phụ thuộc tạo ra các cuộc gọi đến các\r\nthành phần cơ sở cho việc cung cấp các dịch vụ. Đây là những giao diện mà các\r\nthành phần cơ sở là để đáp ứng. Những mô tả giao diện được cung cấp từ quan\r\nđiểm của các thành phần phụ thuộc.
\r\n\r\nPhát triển bằng chứng (ACO_DEV) mô tả các\r\ngiao diện được cung cấp bởi các thành phần cơ sở, trong đó đáp ứng các yêu cầu\r\ndịch vụ thành phần phụ thuộc. Các giao diện này được ánh xạ tới các giao diện\r\nthành phần phụ thuộc có liên quan được xác định trong các thông tin tin cậy.\r\n(liệu khi các giao diện thành phần cơ sở đã mô tả trình bày tất cả các giao\r\ndiện thành phần đại diện phụ thuộc. Tính đầy đủ của việc ánh xạ này không xác\r\nminh ở đây, nhưng có trong phần sở cứ (ACO_COR)). Ở cấp cao hơn của ACO_DEV các\r\nhệ thống con cung cấp các giao diện được mô tả.
\r\n\r\nBất kỳ giao diện nào theo yêu cầu của các\r\nthành phần phụ thuộc chưa được mô tả cho các thành phần cơ sở được báo cáo\r\ntrong các lý do cho phần sở cứ (ACO_COR). Sở cứ này cũng báo cáo có các giao\r\ndiện của các thành phần cơ sở mà trên đó các thành phần phụ thuộc dựa vào được\r\nxem xét bên trong đánh giá thành phần cơ sở. Đối với bất kỳ giao diện nào mà\r\nkhông được xem xét trong việc đánh giá thành phần cơ sở, thì sở cứ quy định về\r\ntác động của việc sử dụng giao diện trên TSF thành phần cơ sở.
\r\n\r\nCác mối phụ thuộc được dẫn chứng trong các thành\r\nphần của mục 9 và 10-16 là những phụ thuộc trực tiếp giữa các thành phần bảo\r\nđảm.
\r\n\r\nCác bảng phụ thuộc đối với các thành phần đảm\r\nbảo sau đây chỉ ra các mối phụ thuộc trực tiếp, gián tiếp hay tùy ý của chúng.\r\nMỗi thành phần đó là một các mối phụ thuộc của một số thành phần đảm bảo được\r\nphân bổ theo mỗi cột. Còn mỗi thành phần đảm bảo được phân bổ theo hàng ngang.\r\nGiá trị mỗi ô trong bảng được đánh dấu “X”: chỉ ra các mối phụ thuộc trực tiếp,\r\ndấu “-”: chỉ sự gián tiếp. Còn nếu trong mỗi ô không có ký tự nào thì các thành\r\nphần đó không phụ thuộc.
\r\n\r\n| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n
| \r\n AGD_OPE.1 \r\n | \r\n \r\n | \r\n
| \r\n AGD_PRE.1 \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
\r\n\r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n ||
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n ||||||
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n ||
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n ||
| \r\n | \r\n \r\n | \r\n \r\n | \r\n ||
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
[1] ISO/IEC 15408-1:2005, Information\r\nTechnology - Security Techniques - Evaluation Criteria for IT Security - Part\r\n1: Introduction and general model.
\r\n\r\n[2] ISO/IEC 15408-2:2005, Information\r\nTechnology - Security Techniques - Evaluation Criteria for IT Security - Part\r\n2: Security functional requirements.
\r\n\r\n[3] ISO/IEC 15408-3:2005, Information\r\nTechnology - Security Techniques - Evaluation Criteria for IT Security - Part\r\n3: Security assurance requirements.
\r\n\r\n[4] ISO/IEC 15408-1:2009, Information\r\nTechnology - Security Techniques - Evaluation Criteria for IT Security - Part 1:\r\nIntroduction and general model.
\r\n\r\n[5] ISO/IEC 15408-2:2008, Information\r\nTechnology - Security Techniques - Evaluation Criteria for IT Security - Part\r\n2: Security functional requirements.
\r\n\r\n[6] ISO/IEC 15408-3:2008, Information\r\nTechnology - Security Techniques - Evaluation Criteria for IT Security - Part\r\n3: Security assurance requirements.
\r\n\r\n[7] ISO/IEC 27001:2005, Information\r\ntechnology - Security techniques - Information security management systems -\r\nRequirements
\r\n\r\n[8] ISO/IEC 27002:2005, Information\r\ntechnology - Security techniques - Code of practice for information security\r\nmanagement
\r\n\r\n[9] TCVN 27001:2009, Công nghệ thông tin - Các\r\nkỹ thuật an toàn - Các hệ thống quản lý an toàn thông tin - Các yêu cầu.
\r\n\r\n\r\n\r\n
Lời giới thiệu
\r\n\r\n1 Phạm vi áp dụng
\r\n\r\n2 Tài liệu viện dẫn
\r\n\r\n3 Thuật ngữ, định nghĩa, ký hiệu và các từ\r\nviết tắt
\r\n\r\n4 Tổng quan
\r\n\r\n4.1 Bố cục của tiêu chuẩn
\r\n\r\n5 Mô hình đảm bảo
\r\n\r\n5.1 Triết lý của TCVN 8709
\r\n\r\n5.2 Tiếp cận đảm bảo
\r\n\r\n5.2.1 Tầm quan trọng của các điểm yếu
\r\n\r\n5.2.2 Nguyên nhân của các điểm yếu
\r\n\r\n5.2.3 Đảm bảo trong bộ TCVN 8709
\r\n\r\n5.2.4 Đảm bảo thông qua đánh giá
\r\n\r\n5.3 Cấp độ đảm bảo đánh giá của bộ TCVN 8709
\r\n\r\n6 Các thành phần đảm bảo an toàn
\r\n\r\n6.1 Cấu trúc các lớp, họ và thành phần đảm\r\nbảo an toàn
\r\n\r\n6.1.1 Cấu trúc lớp đảm bảo
\r\n\r\n6.1.2 Cấu trúc họ đảm bảo
\r\n\r\n6.1.3 Cấu trúc thành phần đảm bảo
\r\n\r\n6.1.4 Các phần tử đảm bảo
\r\n\r\n6.1.5 Danh mục các thành phần
\r\n\r\n6.2 Cấu trúc EAL
\r\n\r\n6.2.1 Tên EAL
\r\n\r\n6.2.2 Mục tiêu
\r\n\r\n6.2.3 Chú thích ứng dụng
\r\n\r\n6.2.4 Các thành phần đảm bảo
\r\n\r\n6.2.5 Mối quan hệ giữa đảm bảo và các mức đảm\r\nbảo
\r\n\r\n6.3 Cấu trúc CAP
\r\n\r\n6.3.1 Tên CAP
\r\n\r\n6.3.2 Mục tiêu
\r\n\r\n6.3.3 Chú thích ứng dụng
\r\n\r\n6.3.4 Các thành phần đảm bảo
\r\n\r\n6.3.5 Mối quan hệ giữa đảm bảo và các mức đảm\r\nbảo
\r\n\r\n7 Các mức đảm bảo đánh giá
\r\n\r\n7.1 Tổng quan về các mức đảm bảo đánh giá\r\n(EAL)
\r\n\r\n7.2 Chi tiết cho mức đảm bảo đánh giá
\r\n\r\n7.3 Mức đảm bảo đánh giá mức 1 (EAL1) - Kiểm\r\nthử chức năng
\r\n\r\n7.3.1 Mục tiêu
\r\n\r\n7.3.2 Các thành phần đảm bảo
\r\n\r\n7.4 Mức đảm bảo đánh giá 2 (EAL2) - Kiểm thử\r\ncấu trúc
\r\n\r\n7.4.1 Mục tiêu
\r\n\r\n7.4.2 Các thành phần đảm bảo
\r\n\r\n7.5 Mức đảm bảo đánh giá 3 (EAL3) - Kiểm thử\r\nvà kiểm tra phương pháp
\r\n\r\n7.5.1 Mục tiêu
\r\n\r\n7.5.2 Các thành phần đảm bảo
\r\n\r\n7.6 Mức đảm bảo đánh giá 4 (EAL4) - Thiết kế,\r\nkiểm thử, soát xét phương pháp
\r\n\r\n7.6.1 Mục tiêu
\r\n\r\n7.6.2 Các thành phần đảm bảo
\r\n\r\n7.7 Mức đảm bảo đánh giá 5 (EAL5) - Thiết kế\r\nvà kiểm thử bán chính thức
\r\n\r\n7.7.1 Mục tiêu
\r\n\r\n7.7.2 Các thành phần đảm bảo
\r\n\r\n7.8 Mức đảm bảo đánh giá 6 (EAL6) - Xác minh\r\nthiết kế và kiểm thử bán chính thức
\r\n\r\n7.8.1 Mục tiêu
\r\n\r\n7.8.2 Các thành phần đảm bảo
\r\n\r\n7.9 Mức đảm bảo đánh giá 7 (EAL7) - Xác định\r\nthiết kế và kiểm thử chính thức
\r\n\r\n7.9.1 Mục tiêu
\r\n\r\n7.9.2 Các thành phần đảm bảo
\r\n\r\n8 Các gói đảm bảo tổng hợp
\r\n\r\n8.1 Tổng quan về gói đảm bảo tổng hợp (CAP)
\r\n\r\n8.2 Chi tiết về gói đảm bảo tổng hợp
\r\n\r\n8.3 Mức đảm bảo tổng hợp A (CAP-A) - Tổng hợp\r\ntheo cấu trúc
\r\n\r\n8.3.1 Mục tiêu
\r\n\r\n8.3.2 Các thành phần đảm bảo
\r\n\r\n8.4 Mức đảm bảo tổng hợp B (CAP-B) - Tổng hợp\r\ntheo phương pháp
\r\n\r\n8.4.1 Mục tiêu
\r\n\r\n8.4.2 Các thành phần đảm bảo
\r\n\r\n8.5 Mức đảm bảo tổng hợp C (CAP-C) - Tổng hợp\r\ntheo phương pháp, kiểm tra và soát xét
\r\n\r\n8.5.1 Mục tiêu
\r\n\r\n8.5.2 Các thành phần đảm bảo
\r\n\r\n9 Lớp APE: Đánh giá hồ sơ bảo vệ
\r\n\r\n9.1 Giới thiệu PP (APE_INT)
\r\n\r\n9.1.1 Mục tiêu
\r\n\r\n9.1.2 APE_INT.1 Giới thiệu PP
\r\n\r\n9.2 Các yêu cầu tuân thủ (APE_CCL)
\r\n\r\n9.2.1 Mục tiêu
\r\n\r\n9.2.2 APE_CCL.1 Các yêu cầu tuân thủ
\r\n\r\n9.3 Định nghĩa vấn đề an toàn (APE_SPD)
\r\n\r\n9.3.1 Mục tiêu
\r\n\r\n9.3.2 APE_SPD.1 định nghĩa các vấn đề an toàn
\r\n\r\n9.4 Các mục tiêu an toàn (APE_OBJ)
\r\n\r\n9.4.1 Mục tiêu
\r\n\r\n9.4.2 Phân mức thành phần
\r\n\r\n9.4.3 APE_OBJ.1 Các mục tiêu an toàn cho môi\r\ntrường áp dụng
\r\n\r\n9.4.4 APE_OBJ.2 Các mục tiêu an toàn
\r\n\r\n9.5 Định nghĩa các thành phần mở rộng\r\n(APE_ECD)
\r\n\r\n9.5.1 Mục tiêu
\r\n\r\n9.5.2 APE_ECD.1 định nghĩa các thành phần mở\r\nrộng
\r\n\r\n9.6 Các yêu cầu an toàn (APE_REQ)
\r\n\r\n9.6.1 Mục tiêu
\r\n\r\n9.6.2 Phân mức thành phần
\r\n\r\n9.6.3 APE_REQ.1 Các yêu cầu an toàn được\r\ntuyên bố
\r\n\r\n9.6.4 APE_REQ.2 Các yêu cầu an toàn thu được
\r\n\r\n10 Lớp ASE: Đánh giá đích an toàn
\r\n\r\n10.1 Giới thiệu ST (ASE_INT)
\r\n\r\n10.1.1 Mục tiêu
\r\n\r\n10.1.2 ASE_INT.1 Giới thiệu ST
\r\n\r\n10.2 Các yêu cầu tuân thủ (ASE_CCL)
\r\n\r\n10.2.1 Mục tiêu
\r\n\r\n10.2.2 ACE_CCL.1 Các yêu cầu tuân thủ
\r\n\r\n10.3 Định nghĩa vấn đề an toàn (ASE_SPD)
\r\n\r\n10.3.1 Mục tiêu
\r\n\r\n10.3.2 ASE_SPD.1 Định nghĩa vấn đề an toàn
\r\n\r\n10.4 Mục tiêu an toàn (ASE_OBJ)
\r\n\r\n10.4.1 Mục tiêu
\r\n\r\n10.4.2 Phân mức thành phần
\r\n\r\n10.4.3 ASE_OBJ.1 Các mục tiêu an toàn cho môi\r\ntrường hoạt động
\r\n\r\n10.4.4 ASE_OBJ.2 Các mục tiêu an toàn
\r\n\r\n10.5 Định nghĩa các thành phần mở rộng\r\n(ASE_ECD)
\r\n\r\n10.5.1 Mục tiêu
\r\n\r\n10.5.2 ASE_ECD.1 Định nghĩa các thành phần mở\r\nrộng
\r\n\r\n10.6 Các yêu cầu an toàn (ASE_REQ)
\r\n\r\n10.6.1 Mục tiêu
\r\n\r\n10.6.2 Phân mức thành phần
\r\n\r\n10.6.3 ASE_REQ.1 Định nghĩa các thành phần mở\r\nrộng
\r\n\r\n10.6.4 ASE_REQ.2 Các yêu cầu an toàn thu\r\nđược.
\r\n\r\n10.7 Đặc tả tổng quát TOE (ASE_TSS)
\r\n\r\n10.7.1 Mục tiêu
\r\n\r\n10.7.2 Phân mức thành phần
\r\n\r\n10.7.3 ASE_TSS.1 Đặc tả tổng quát TOE
\r\n\r\n10.7.4 ASE_TSS.2 Đặc tả tổng quát với kiến\r\ntrúc thiết kế tổng quát
\r\n\r\n11 Lớp ADV: Phát triển
\r\n\r\n11.1 Kiến trúc an toàn (ADV_ARC)
\r\n\r\n11.1.1 Mục tiêu
\r\n\r\n11.1.2 Phân mức thành phần
\r\n\r\n11.1.3 Chú thích ứng dụng
\r\n\r\n11.1.4 ADV_ARC.1 Mô tả kiến trúc an toàn
\r\n\r\n11.2 Đặc tả chức năng (ADV_FSP)
\r\n\r\n11.2.1 Mục tiêu
\r\n\r\n11.2.2 Phân mức thành phần
\r\n\r\n11.2.3 Chú thích ứng dụng
\r\n\r\n11.2.4 ADV_FSP.1 Đặc tả chức năng cơ sở
\r\n\r\n11.2.5 ADV_FSP.2 Đặc tả chức năng thực thi an\r\ntoàn
\r\n\r\n11.2.6 ADV_FSP.3 Đặc tả chức năng với tóm tắt\r\nđầy đủ
\r\n\r\n11.2.7 ADV_FSP.4 Đặc tả chức năng đầy đủ
\r\n\r\n11.2.8 ADV_FSP.5 Đặc tả chức năng bán chính\r\nthức đầy đủ với thông tin lỗi bổ sung
\r\n\r\n11.2.9 ADV_FSP.6 Đặc tả chức năng bán chính\r\nthức đầy đủ với đặc tả chính thức bổ sung
\r\n\r\n11.3 Biểu diễn triển khai (ADV_IMP)
\r\n\r\n11.3.1 Mục tiêu
\r\n\r\n11.3.2 Phân mức thành phần
\r\n\r\n11.3.3 Chú thích ứng dụng
\r\n\r\n11.3.4 ADV_IMP.1 Biểu diễn triển khai của TSF
\r\n\r\n11.3.5 ADV_IMP.2 Ánh xạ đầy đủ của biểu diễn\r\ntriển khai của TSF
\r\n\r\n11.4 Nội bộ TSF (ADV_INT)
\r\n\r\n11.4.1 Mục tiêu
\r\n\r\n11.4.2 Phân mức thành phần
\r\n\r\n11.4.3 Chú thích ứng dụng
\r\n\r\n11.4.4 ADV_INT.1 Tập con cấu trúc rõ ràng của\r\nnội bộ TSF
\r\n\r\n11.4.5 ADV_INT.2 Nội bộ với cấu trúc rõ ràng
\r\n\r\n11.4.6 ADV_INT.3 Nội bộ với độ phức tạp tối\r\nthiểu
\r\n\r\n11.5 Mô hình hóa chính sách an toàn (ADV_SPM)
\r\n\r\n11.5.1 Mục tiêu
\r\n\r\n11.5.2 Phân mức thành phần
\r\n\r\n11.5.3 Chú thích ứng dụng
\r\n\r\n11.5.4 ADV_SPM.1 Mô hình chính sách an toàn\r\nTOE chính thức
\r\n\r\n11.6 Thiết kế TOE (ADV_TDS)
\r\n\r\n11.6.1 Mục tiêu
\r\n\r\n11.6.2 Phân mức thành phần
\r\n\r\n11.6.3 Chú thích ứng dụng
\r\n\r\n11.6.4 ADV_TDS.1 Thiết kế cơ sở
\r\n\r\n11.6.5 ADV_TDS.2 Thiết kế kiến trúc
\r\n\r\n11.6.6 ADV_TDS.3 Thiết kế mô đun cơ sở
\r\n\r\n11.6.7 ADV_TDS.4 Thiết kế mô đun bán chính\r\nthức
\r\n\r\n11.6.8 ADV_TDS.5 Thiết kế mô đun bán chính\r\nthức đầy đủ
\r\n\r\n11.6.9 ADV_TDS.6 Thiết kế mô đun bán chính\r\nthức đầy đủ với bản thể hiện thiết kế chính thức mức cao
\r\n\r\n12 Lớp AGD: Tài liệu hướng dẫn
\r\n\r\n12.1 Hướng dẫn người dùng vận hành (AGD_OPE)
\r\n\r\n12.1.1 Mục tiêu
\r\n\r\n12.1.2 Phân mức thành phần
\r\n\r\n12.1.3 Chú thích ứng dụng
\r\n\r\n12.1.4 Hướng dẫn người dùng vận hành\r\nAGD_OPE.1
\r\n\r\n12.2 Các thủ tục chuẩn bị (AGD_PRE)
\r\n\r\n12.2.1 Mục tiêu
\r\n\r\n12.2.2 Phân mức thành phần
\r\n\r\n12.2.3 Chú thích ứng dụng
\r\n\r\n12.2.4 Các thủ tục chuẩn bị AGD_PRE.1
\r\n\r\n13 Lớp ALC: Hỗ trợ vòng đời
\r\n\r\n13.1 Năng lực CM (ALC_CMC)
\r\n\r\n13.1.1 Mục tiêu
\r\n\r\n13.1.2 Phân mức thành phần
\r\n\r\n13.1.3 Chú thích ứng dụng
\r\n\r\n13.1.4 ALC_CMC.1 Gán nhãn TOE
\r\n\r\n13.1.5 ALC_CMC.2 Sử dụng hệ thống CM
\r\n\r\n13.1.6 ALC_CMC.3 Kiểm soát cấp phép
\r\n\r\n13.1.7 ALC_CMC.4 Hỗ trợ sản xuất và các thủ\r\ntục chấp nhận và tự động hóa
\r\n\r\n13.1.8 ALC_CMC.5 Hỗ trợ cải tiến
\r\n\r\n13.2 Phạm vi CM (ALC_CMS)
\r\n\r\n13.2.1 Mục tiêu
\r\n\r\n13.2.2 Phân mức thành phần
\r\n\r\n13.2.3 Chú thích ứng dụng
\r\n\r\n13.2.4 ALC_CMS.1 TOE CM Tổng quát
\r\n\r\n13.2.5 ALC_CMS.2 Các phần của TOE CM tổng\r\nquát
\r\n\r\n13.2.6 ALC_CMS.3 Biểu diễn triển khai CM tổng\r\nquát
\r\n\r\n13.2.7 ALC_CMS.4 Theo dấu vấn đề CM tổng quát
\r\n\r\n13.2.8 ALC_CMS.5 Các công cụ phát triển CM\r\nTổng quát
\r\n\r\n13.3 Chuyển giao (ALC_DEL)
\r\n\r\n13.3.1 Mục tiêu
\r\n\r\n13.3.2 Phân mức thành phần
\r\n\r\n13.3.3 Chú thích ứng dụng
\r\n\r\n13.3.4 ALC_DEL.1 Các thủ tục chuyển giao
\r\n\r\n13.4 An toàn phát triển (ALC_DVS)
\r\n\r\n13.4.1 Mục tiêu
\r\n\r\n13.4.2 Phân mức thành phần
\r\n\r\n13.4.3 Chú thích ứng dụng
\r\n\r\n13.4.4 ALC_DVS.1 Định danh các biện pháp an\r\ntoàn
\r\n\r\n13.4.5 ALC_DVS.2 Sự đầy đủ các biện pháp an\r\ntoàn
\r\n\r\n13.5 Sửa lỗi (ALC_FLR)
\r\n\r\n13.5.1 Mục tiêu
\r\n\r\n13.5.2 Phân mức thành phần
\r\n\r\n13.5.3 Chú thích ứng dụng
\r\n\r\n13.5.4 ALC_FLR.1 Sửa lỗi cơ bản
\r\n\r\n13.5.5 ALC_FLR.2 Các thủ tục báo cáo lỗi
\r\n\r\n13.5.6 ALC_FLR.3 Sửa lỗi hệ thống
\r\n\r\n13.6 Định nghĩa vòng đời (ALC_LCD)
\r\n\r\n13.6.1 Mục tiêu
\r\n\r\n13.6.2 Phân mức thành phần
\r\n\r\n13.6.3 Chú thích ứng dụng
\r\n\r\n13.6.4 ALC_LCD.1 Mô hình vòng đời định nghĩa\r\nbởi nhà phát triển
\r\n\r\n13.6.5 ALC_LCD.2 Mô hình vòng đời định lượng
\r\n\r\n13.7 Các công cụ và các kỹ thuật (ALC_TAT)
\r\n\r\n13.7.1 Mục tiêu
\r\n\r\n13.7.2 Phân mức thành phần
\r\n\r\n13.7.3 Chú thích ứng dụng
\r\n\r\n13.7.4 ALC_TAT.1 Các công cụ phát triển được\r\nđịnh nghĩa rõ ràng
\r\n\r\n13.7.5 ALC_TAT.2 Tương thích với các tiêu\r\nchuẩn triển khai
\r\n\r\n13.7.6 ALC_TAT.3 Tương thích với tiêu chuẩn\r\ntriển khai - tất cả các thành phần
\r\n\r\n14 Lớp ATE: Các kiểm thử
\r\n\r\n14.1 Tổng quát (ATE_COV)
\r\n\r\n14.1.1 Mục tiêu
\r\n\r\n14.1.2 Phân mức thành phần
\r\n\r\n14.1.3 Chú thích ứng dụng
\r\n\r\n14.1.4 ATE_COV.1 Chứng cứ tổng quát
\r\n\r\n14.1.5 ATE_COV.2 Phân tích tổng quát
\r\n\r\n14.1.6 ATE_COV.3 Phân tích tổng quát chặt chẽ
\r\n\r\n14.2 Chuyên sâu (ATE_DPT)
\r\n\r\n14.2.1 Mục tiêu
\r\n\r\n14.2.2 Phân mức thành phần
\r\n\r\n14.2.3 Chú thích ứng dụng
\r\n\r\n14.2.4 ATE_DEPT.1 Kiểm thử: thiết kế cơ bản
\r\n\r\n14.2.5 ATE_DPT.2 Kiểm thử: các mô đun thực\r\nthi an toàn
\r\n\r\n14.2.6 ATE_DEPT.3 Kiểm thử: Thiết kế mang\r\ntính mô đun
\r\n\r\n14.2.7 ATE_DPT.4 Kiểm thử: Biểu diễn thực thi
\r\n\r\n14.3 Các kiểm thử chức năng (ATE_FUN)
\r\n\r\n14.3.1 Mục tiêu
\r\n\r\n14.3.2 Phân mức thành phần
\r\n\r\n14.3.3 Chú thích ứng dụng
\r\n\r\n14.3.4 ATE_FUN.1 Kiểm thử chức năng
\r\n\r\n14.3.5 ATE_FUN.2 Kiểm thử chức năng theo\r\ntrình tự
\r\n\r\n14.4 Kiểm thử độc lập (ATE_IND)
\r\n\r\n14.4.1 Mục tiêu
\r\n\r\n14.4.2 Phân mức thành phần
\r\n\r\n14.4.3 Chú thích ứng dụng
\r\n\r\n14.4.4 ATE_IND.1 Kiểm thử độc lập - tuân thủ
\r\n\r\n14.4.5 ATE_IND.2 Kiểm thử độc lập - lấy mẫu
\r\n\r\n14.4.6 ATE_IND.3 Kiểm thử độc lập - toàn diện
\r\n\r\n15 Lớp AVA: Đánh giá điểm yếu
\r\n\r\n15.1 Chú thích ứng dụng
\r\n\r\n15.2 Phân tích điểm yếu (AVA_VAN)
\r\n\r\n15.2.1 Mục tiêu
\r\n\r\n15.2.2 Phân mức thành phần
\r\n\r\n15.2.3 AVA_VAN.1 Tổng quan điểm yếu
\r\n\r\n15.2.4 AVA_VAN.2 Phân tích điểm yếu
\r\n\r\n15.2.5 AVA_VAN.3 Phân tích các điểm yếu trọng\r\ntâm
\r\n\r\n15.2.6 AVA_VAN.4 Phân tích điểm yếu có hệ\r\nthống
\r\n\r\n15.2.7 AVA_VAN.5 Phân tích điểm yếu có hệ\r\nthống nâng cao
\r\n\r\n16 Lớp ACO: Tổng hợp
\r\n\r\n16.1 Sở cứ tổng hợp (ACO_COR)
\r\n\r\n16.1.1 Mục tiêu
\r\n\r\n16.1.2 Phân mức thành phần
\r\n\r\n16.1.3 ACO_COR.1 Sở cứ tổng hợp
\r\n\r\n16.2 Chứng cứ phát triển (ACO_DEV)
\r\n\r\n16.2.1 Mục tiêu
\r\n\r\n16.2.2 Phân mức thành phần
\r\n\r\n16.2.3 Chú thích ứng dụng
\r\n\r\n16.2.4 ACO_DEV.1 Mô tả chức năng
\r\n\r\n16.2.5 ACO_DEV.2 Chứng cứ cơ bản của thiết kế
\r\n\r\n16.2.6 ACO_DEV.3 Chứng cứ chi tiết của thiết\r\nkế
\r\n\r\n16.3 Tính tin cậy của thành phần phụ thuộc\r\n(ACO_REL)
\r\n\r\n16.3.1 Mục tiêu
\r\n\r\n16.3.2 Phân mức thành phần
\r\n\r\n16.3.3 Chú thích ứng dụng
\r\n\r\n16.3.4 ACO_REL.1 Thông tin tin cậy cơ bản
\r\n\r\n16.3.5 ACO_REL.2 Thông tin tin cậy
\r\n\r\n16.4 Kiểm thử TOE tổng hợp (ACO_CTT)
\r\n\r\n16.4.1 Mục tiêu
\r\n\r\n16.4.2 Phân mức thành phần
\r\n\r\n16.4.3 Chú thích ứng dụng
\r\n\r\n16.4.4 ACO_CTT.1 Soát xét điểm yếu tổng hợp
\r\n\r\n16.4.5 ACO_CTT.2 Kiểm thử giao diện chặt chẽ
\r\n\r\n16.5 Phân tích điểm yếu tổng hợp (ACO_VUL)
\r\n\r\n16.5.1 Mục tiêu
\r\n\r\n16.5.2 Phân mức thành phần
\r\n\r\n16.5.3 Chú thích ứng dụng
\r\n\r\n16.5.4 ACO_VUL.1 Soát xét điểm yếu tổng hợp
\r\n\r\n16.5.5 ACO_VUL.2 Phân tích điểm yếu tổng hợp
\r\n\r\n16.5.6 ACO_VUL.3 Phân tích điểm yếu tổng hợp\r\ncơ bản - nâng cao
\r\n\r\nPhụ lục A (Tham khảo) _ Lớp phát triển (ADV)
\r\n\r\nA.1 ADV_ARC: Bổ sung các tài liệu trên kiến\r\ntrúc an toàn
\r\n\r\nA.1.1 Các thuộc tính trong kiến trúc an toàn
\r\n\r\nA.1.2 Mô tả kiến trúc an toàn
\r\n\r\nA.2 ADV_FSP: Bổ sung các tài liệu trên các\r\nTSFI
\r\n\r\nA.2.1 Xác định TSFI
\r\n\r\nA.2.2 Ví dụ: một DBMS phức tạp
\r\n\r\nA.2.3 Ví dụ Đặc tả chức năng
\r\n\r\nA.3 ADV_INT: Tài liệu bổ sung trên TSF nội bộ
\r\n\r\nA.3.1 Cấu trúc phần mềm thủ tục
\r\n\r\nA.3.2 Tính phức tạp của phần mềm thủ tục
\r\n\r\nA.4 ADV_TDS: Các hệ thống con và mô đun
\r\n\r\nA.4.1 Các hệ thống con
\r\n\r\nA.4.2 Các mô đun
\r\n\r\nA.4.3 Phương thức phân mức
\r\n\r\nA.5 Tài liệu bổ trợ về phương pháp chính thức
\r\n\r\nPhụ lục B (Quy định) Tổng hợp (ACO)
\r\n\r\nB.1 Sự cần thiết đối với các đánh giá TOE\r\ntổng hợp
\r\n\r\nB.2 Thực hiện đánh giá Mục tiêu An toàn đánh\r\ngiá đối với một TOE tổng hợp
\r\n\r\nB.3 Các tương tác giữa các thực thể CNTT tổng\r\nhợp
\r\n\r\nPhụ lục C _ (Tham khảo) _ Chỉ dẫn tham khảo\r\nvề các mối phụ thuộc thành phần đảm bảo
\r\n\r\nPhụ lục D _ (Tham khảo) _ Tham chiếu chéo của\r\nPPs và các thành phần đảm bảo
\r\n\r\nPhụ lục E _ (Tham khảo) _ Tham chiếu chéo của\r\nEALs và các thành phần đảm bảo
\r\n\r\nPhụ lục F _ (Tham khảo) _ Chỉ dẫn tham khảo\r\ncho các CAP và các thành phần đảm bảo
\r\n\r\nFile gốc của Tiêu chuẩn Việt Nam TCVN 8709-3:2011 (ISO/IEC 15408-3:2008) về Công nghệ thông tin – Các kỹ thuật an toàn – Các tiêu chí đánh giá an toàn CNTT – Phần 3: Các thành phần đảm bảo an toàn đang được cập nhật.
Tiêu chuẩn Việt Nam TCVN 8709-3:2011 (ISO/IEC 15408-3:2008) về Công nghệ thông tin – Các kỹ thuật an toàn – Các tiêu chí đánh giá an toàn CNTT – Phần 3: Các thành phần đảm bảo an toàn
Tóm tắt
| Cơ quan ban hành | Đã xác định |
| Số hiệu | TCVN8709-3:2011 |
| Loại văn bản | Tiêu chuẩn Việt Nam |
| Người ký | Đã xác định |
| Ngày ban hành | 2011-01-01 |
| Ngày hiệu lực | |
| Lĩnh vực | Xây dựng - Đô thị |
| Tình trạng | Còn hiệu lực |