5. Tổng quan

5.1. Giới thiệu chung

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

5.2. TOE

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

5.3.3. Đánh giá viên

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

Người tiêu dùng

...

...

...

Đánh giá viên

Phần 1

Dùng làm thông tin cơ sở và bắt buộc sử dụng để tham chiếu. Cấu trúc hướng dẫn cho các PP.

Dùng làm thông tin cơ sở và tham chiếu. Bắt buộc sử dụng để phát triển các đặc tả an toàn cho các TOE.

Bắt buộc sử dụng để tham chiếu và hướng dẫn trong cấu trúc cho các PP và các ST.

Phần 2

Dùng để hướng dẫn và tham chiếu khi lập các phát biểu về yêu cầu các chức năng an toàn của một TOE

Dùng để tham chiếu khi diễn giải các phát biểu về yêu cầu chức năng, và khi lập các đặc tả chức năng cho các TOE.

Bắt buộc sử dụng để tham chiếu khi diễn giải các phát biểu về các yêu cầu chức năng.

...

...

...

Dùng để hướng dẫn khi xác định cấp bảo đảm yêu cầu.

Dùng để tham chiếu khi diễn giải các phát biểu về yêu cầu đảm bảo, và khi xác định các cách đảm bảo các TOE.

Dùng để tham chiếu khi diễn giải các phát biểu về các yêu cầu đảm bảo.

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

— Kiểm thử TOE;

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

6.3. Đánh giá

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

7.1. Các hoạt động

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

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

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

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

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

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

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

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

...

...

...

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

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

7.1.1. Hoạt động lặp

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

8.1. Giới thiệu

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

8.2. Các gói

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

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

...

...

...

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

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

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

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

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

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

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

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

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

...

...

...

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

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

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

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

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

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

— Tất cả các TOE thỏa mãn ST cũng thỏa mãn PP, và

— Tất cả các môi trường vận hành thỏa mãn PP cũng thỏa mãn ST.

Hay nói một cách thân thuộc hơn, ST cần tập trung cùng hoặc nhiều hạn chế hơn ở TOE và cùng hoặc ít hạn chế hơn ở môi trường vận hành của TOE.

...

...

...

Định nghĩa vấn đề an toàn: Sở cứ tuân thủ trong ST cần diễn giải rằng định nghĩa vấn đề an toàn trong ST tương đương (hoặc nhiều hạn chế hơn) định nghĩa vấn đề an toàn trong PP. Điều đó nghĩa là:

— Tất cả các TOE có thể thỏa mãn định nghĩa vấn đề an toàn trong ST cũng thỏa mãn định nghĩa vấn đề an toàn trong PP;

— Tất cả các môi trường vận hành có thể thỏa mãn định nghĩa vấn đề an toàn trong PP cũng sẽ thỏa mãn định nghĩa vấn đề an toàn trong ST;

Các mục tiêu an toàn: Sở cứ tuân thủ trong ST cần diễn giải rằng các mục tiêu an toàn trong ST tương đương (hoặc nhiều hạn chế hơn) các mục tiêu an toàn trong PP. Điều đó nghĩa là:

— Tất cả các TOE có thể thỏa mãn các mục tiêu an toàn trong ST cũng thỏa mãn các mục tiêu an toàn cho TOE trong PP;

— Tất cả các môi trường vận hành có thể thỏa mãn các mục tiêu an toàn trong PP cũng sẽ thỏa mãn các mục tiêu an toàn cho môi trường vận hành trong ST;

Nếu tính tuân thủ chặt chẽ cho các hồ sơ bảo vệ được chỉ ra, thì các yêu cầu sau sẽ áp dụng:

a) Định nghĩa vấn đề an toàn: ST cần chứa định nghĩa vấn đề an toàn của PP, có thể chỉ ra các mối đe dọa bổ sung và các OSPs, song có thể không chỉ ra các giả thiết bổ sung.

b) Các mục tiêu an toàn: ST cần:

...

...

...

— Cần chứa tất cả các mục tiêu an toàn cho môi trường vận hành (với một ngoại lệ trong mục con tiếp theo), song có thể không chỉ ra các mục tiêu an toàn bổ sung cho môi trường vận hành;

— Có thể chỉ ra các mục tiêu nhất định cho môi trường vận hành trong PP là các mục tiêu an toàn cho TOE trong ST. Điều này gọi là chỉ định lại một mục tiêu an toàn. Nếu một mục tiêu an toàn được chỉ đjnh lại cho TOE, sở cứ cho các mục tiêu an toàn cần làm rõ ràng là giả thiết nào hoặc phần giả thiết nào không cần thiết nữa.

c) Các yêu cầu an toàn: ST cần chứa tất cả các SFR và SAR trong PP, song có thể đòi hỏi các SFR và SAR bổ sung hoặc phân cấp mạnh hơn. Sự hoàn tất các hoạt động trong ST cần phải nhất quán với các hoạt động trong PP, hoặc là cùng có sự hoàn tất trong ST như trong PP hoặc một hoạt động nào đó làm cho yêu cầu trở nên hạn chế hơn (áp dụng các quy tắc bổ sung chi tiết).

Nếu tính tuân thủ có thể biểu diễn được cho các hồ sơ bảo vệ được chỉ ra, thì các yêu cầu sau sẽ được áp dụng:

— ST cần chứa một sở cứ về việc tại sao ST được xem xét là “tương đương hoặc hạn chế hơn" là so với PP.

— Tính tuân thủ biểu hiện được cho phép một tác giả PP mô tả vấn đề an toàn chung cần được giải quyết và cung cấp các hướng dẫn chung cho các yêu cầu cần thiết đối với việc giải quyết nó, với nhận thức rằng có thể có nhiều hơn một cách để chỉ ra lời giải.

Đánh giá PP là tùy ý. Việc đánh giá được thực hiện qua việc áp dụng các tiêu chí APE cho chúng như liệt kê trong TCVN 8709-3. Mục đích của việc đánh giá như vậy là để diễn giải rằng PP là hoàn tất, nhất quán, và và phù hợp về mặt kỹ thuật, thích hợp để dùng làm bản mẫu cho việc tạo ra PP hoặc một ST khác.

Tạo ra một PP/ST dựa trên một PP đã đánh giá có hai ưu điểm:

— Có ít rủi ro hơn về các lỗi, chỗ không rõ ràng, hoặc kẽ hở trong PP. Nếu bất kỳ vấn đề nào với một PP (có thể phát hiện ra khi đánh giá PP) được tìm ra trong quá trình viết hoặc đánh giá một ST mới, một khoảng thời gian đáng kể đã qua đi trước khi PP được sửa lại.

...

...

...

Hình 4 - Các mối quan hệ giữa PP, ST và các nội dung TOE

8.4. Sử dụng PP và các gói

Nếu một ST đòi hỏi được tuân thủ theo một hoặc nhiều gói và/hoặc các Hồ sơ bảo vệ, việc đánh giá ST này sẽ (theo như các đặc tính khác của ST) diễn giải rằng ST thực tế tuân thủ với các gói này và/hoặc các PP mà chúng đòi hỏi tuân thủ theo. Chi tiết về việc xác định tính tuân thủ này được nêu trong Phụ lục A.

Điều trên cho phép tiến trình sau đây:

a) Một tổ chức tìm kiếm thu thập một kiểu cá biệt về sản phẩm an toàn CNTT, thực hiện xây dựng các nhu cầu an toàn của nó trong một PP, tiếp đó đánh giá nó và công bố nó;

b) Một nhà phát triển lấy PP này, viết một ST yêu cầu tuân thủ theo PP và đã đánh giá ST này;

c) Nhà phát triển tiếp đó tạo ra một TOE (hoặc sử dụng một TOE có sẵn) và thực hiện đánh giá theo ST.

Kết quả lả nhà phát triển có, thể chứng minh rằng TOE của hj tuân thủ theo các nhu cầu an toàn của tổ chức. Do vậy, tổ chức đạt được TOE này. Cách tương tự cũng được áp dụng cho các gói.

...

...

...

TCVN 8709 cũng cho phép các PP tuân thủ theo các PP khác, cho phép kiến thiết chuỗi các PP, mỗi cái dựa vào một cái (hoặc nhiều cái) trước đó.

Ví dụ, có thể lấy một PP cho một mạch tổ hợp và một PP cho một OS dùng thẻ thông minh, và dùng chúng để kiến thiết ra một PP cho thẻ thông minh (IC và OS) với yêu cầu tuân thủ theo hai PP khác. Có thể viết một PP về các thẻ thông minh cho vận tải công cộng dựa trên PP cho thẻ thông minh và viết một PP cho việc tải Applet. Kế đó, một nhà phát triển có thể kiến thiết một ST dựa theo các thẻ thông minh này cho PP vận tải công cộng.

9. Các kết quả đánh giá

9.1. Giới thiệu

Phần này trình bày các kết quả mong muốn qua đánh giá PP và ST/TOE thực hiện theo TCVN 8709.

— Các đánh giá PP cho ta được danh mục các PP đã được đánh giá.

— Việc đánh giá ST cho các kết quả trung gian để sử dụng trong khuôn khổ đánh giá TOE.

— Các đánh giá ST/TOE cho ta được danh mục các ST/TOE đã được đánh giá. Trong nhiều trường hợp các danh mục này sẽ tham chiếu tới các sản phẩm CNTT mà các TOE được dẫn xuất ra hơn là TOE xác định. Bởi vậy, sự tồn tại của một sản phẩm CNTT trong một danh mục không nên được kiến thiết theo nghĩa là toàn bộ sản phẩm CNTT đã được đánh giá. Thay vào đó việc mở rộng thực tế của đánh giá ST/TOE được định nghĩa qua ST. Tham chiếu đến thư mục cá ví dụ của các danh mục đó.

Các ST có thể dựa trên các gói, các PP đã đánh giá hoặc các PP chưa đánh giá. Tuy nhiên, điều này không bắt buộc vì các ST không cần phải dựa trên một thứ gì cả.

...

...

...

Hình 5 - Các kết quả đánh giá

Một kết quả đánh giá thể hiện việc tìm ra một kiểu xác định cho điều tra các đặc tính an toàn của một TOE. Một kết quả như vậy không tự động bảo đảm tính phù hợp cho sử dụng trong bất kỳ môi trường ứng dụng đặc biệt nào. Quyết định chấp nhận một TOE để sử dụng trong một môi trường ứng dụng đặc trưng dựa trên cơ sở xem xét nhiều vấn đề an toàn, bao gồm cả những kết luận đánh giá.

9.2. Các kết quả đánh giá PP

TCVN 8709-3 chứa các tiêu chí đánh giá mà một đánh giá viên bắt buộc phải tham khảo để xác định xem một PP có hoàn thiện, nhất quán và phù hợp về mặt kỹ thuật và do vậy thích hợp dùng để phát triển một ST hay chưa.

Các kết quả đánh giá PP cần chứa “Tuyên bố tuân thủ” (xem 9.4).

9.3. Các kết quả đánh giá ST/TOE

TCVN 8709-3 chứa các tiêu chí đánh giá mà một đánh giá viên bắt buộc phải tham khảo để xác định xem có tồn tại sự đảm bảo rằng TOE thỏa mãn các SFR trong ST hay không. Do đó, đánh giá TOE cần cho kết quả là một phát biểu đạt/không đạt cho ST. Nếu việc đánh giá cho cả hai ST và TOE cho lại kết quả trong công bố đạt, sản phẩm đang xét có thể sẵn sàng đưa vào bản đăng ký. Các kết quả đánh giá cần chứa một “Tuyên bố tuân thủ" như định nghĩa trong 9.4.

Có thể có trường hợp các kết quả đánh giá được sử dụng tiếp đó trong một tiến trình xác nhận, song tiến trình này nằm ngoài phạm vi của TCVN 8709.

...

...

...

Tuyên bố tuân thủ chỉ ra nguồn tập hợp các yêu cầu được thoả mãn cho một PP hay ST đã vượt qua bước đánh giá. Tuyên bố tuân thủ này chưa một tuyên bố tuân thủ TCVN 8709 như sau:

a) Mô tả phiên bản TCVN 8709 mà PP hay ST tuân thủ theo.

b) Mô tả sự tuân thủ theo TCVN 8709-2 (các yêu cầu chức năng an toàn) là:

— Tuân thủ TCVN 8709-2 (ISO/IEC 15408-2 conformant): Một PP hoặc ST là tuân thủ theo TCVN 8709-2 nếu mọi SFR trong PP hay ST này chỉ dựa trên các thành phần chức năng trong TCVN 8709 - 2. Hoặc

— Mở rộng TCVN 8709-2 (ISO/IEC 15408-2 extended): Một PP hoặc ST là mở rộng của TCVN 8709-2 nếu ít nhất có một SFR trong PP hay ST này không thuộc các thành phần chức năng trong TCVN 8709-2.

c) Mô tả sự tuân thủ theo TCVN 8709-3 (các yêu cầu đảm bảo an toàn) là:

— Tuân thủ TCVN 8709-3 (ISO/IEC 15408-3 conformant): Một PP hoặc ST là tuân thủ theo TCVN 8709-3 nếu tất cả các SAR trong PP hay ST này chỉ dựa trên các thành phần đảm bảo trong TCVN 8709 - 3. Hoặc

— Mở rộng TCVN 8709-3 (ISO/IEC 15408-3 extended): Một PP hoặc ST là mở rộng của TCVN 8709-3 nếu tất cả các SAR trong PP hay ST này không thuộc trên các thành phần đảm bảo trong TCVN 8709-3.

Ngoài ra, Tuyên bố tuân thủ có thể bao gồm cả một phát biểu liên quan đến các gói, trong đó có chứa một trong các điều sau:

...

...

...

— Các SFR của PP hay ST này trùng với các SFR trong gói, hoặc

— Các SAR của PP hay ST này trùng với các SAR trong gói.

— Gia tăng tên gói: Một PP hoặc ST là một phần gia tăng của một gói xác định trước, nếu:

— Các SFR của PP hay ST này chứa tất cả các SFR trong gói, song có ít nhất một SFR bổ sung hoặc một SFR có phần cấp cao hơn SFR tương ứng trong gói.

— Các SAR của PP hay ST này chứa tất cả các SAR trong gói, song có ít nhất một SAR bổ sung hoặc một SAR có phần cấp cao hơn SAR tương ứng trong gói.

Lưu ý rằng khi một TOE đã đánh giá thành công theo một ST, bất kỳ một tuyên bố tuân thủ nào của ST cũng sẽ dùng được cho TOE. Một TOE như vậy có thể ví dụ là tuân thủ theo TCVN 8709-2.

Cuối cùng, tuyên bố tuân thủ cũng chứa hai phát biểu sau đây liên quan đến Hồ sơ bảo vệ:

a) Tuân thủ PP: Một PP hay TOE thoả mãn các PP(s) xác định như đã được liệt kê là một phần của kết quả tuân thủ.

b) Phát biểu tuân thủ (chỉ cho PPs): Phát biểu này mô tả cách thức mà các PP hay các ST tuân thủ theo PP này, chặt chẽ hay diễn giải được. Xem Phụ lục B để có thêm thông tin về phát biểu tuân thủ này.

...

...

...

Một khi một ST và một TOE đã được đánh giá, chủ sở hữu tài sản có thể có sự đảm bảo (như đã định nghĩa trong ST) rằng TOE, cùng với môi trường vận hành, chống lại được các mối đe dọa. Các kết quả đánh giá có thể được dùng bởi chủ sở hữu tài sản để ra quyết định về việc có chấp nhận rủi ro phơi bày tài sản trước các mối đe dọa hay không.

Tuy nhiên, chủ sở hữu tài sản nên thận trọng kiểm tra xem:

— Định nghĩa vấn đề an toàn trong ST có phù hợp với vấn đề an toàn của mình hay không

— Môi trường vận hành của chủ sở hữu tài sản tuân thủ (hoặc có thể làm cho tuân thủ) theo các mục tiêu an toàn cho môi trường vận hành đã mô tả trong ST hay không.

Nếu không có điều nào trên là đúng, TOE có thể không thích hợp cho các mục đích của chủ sở hữu tài sản.

Ngoài ra, một khi một TOE đã đánh giá đang hoạt đông, vẫn có khả năng các lỗi không biết trước đó, hoặc các điểm yếu trong TOE có thể lộ diện. Trong trường hợp này, nhà phát triển có thể sửa TOE (để sửa chữa các điểm yếu) hoặc thay đổi ST để loại trừ điểm yếu ra khỏi phạm vi đánh giá. Trong cả hai trường hợp, các kết quả đánh giá cũ có thể không còn hợp lệ nữa.

Nếu như cảm thấy cần thiết phải lấy lại sự tin cậy, việc đánh giá lại là cần thiết. TCVN 8709 có thể được sử dụng để thực hiện đánh giá lại, song các thủ tục chi tiết cho việc đánh giá lại nằm ngoài phạm vi phần này của tiêu chuẩn TCVN 8709.

PHỤ LỤC A

...

...

...

Đặc tả của các đích an toàn

A.1. Mục tiêu và cấu trúc của phụ lục

Phụ lục này giải thích khái niệm Đích an toàn (ST). Phụ lục này không định nghĩa các tiêu chí ASE; định nghĩa này có thể tìm thấy trong TCVN 8709-3 và các tài liệu đã cho trong tài liệu tham khảo.

Phụ lục này gồm bốn phần chính sau:

a) Một ST phải có những gì. Điều này được tóm tắt trong A.2, và được mô tả chi tiết hơn trong A.4 đến A.10. Các mục nhỏ này mô tả các nội dung bắt buộc của ST, các mối quan hệ bên trong giữa các nội dung này và đưa ra các ví dụ.

b) Một ST nên được sử dụng thế nào. Điều này được tóm tắt trong A.3, và được mô tả chi tiết trong A.11. Mục này mô tả một ST nên được sử dụng như thế nào, và một số câu hỏi có thể được trả lời với một ST.

c) Các ST mức đảm bảo thấp. Các ST này là các ST có nội dung được giản bớt. Chúng được mô tả chi tiết trong A.12

d) Tuyên bố tuân thủ theo tiêu chuẩn. Điều A.13 mô tả người soạn ST có thể tuyên bố rằng TOE đáp ứng một chuẩn cụ thể như thế nào.

A.2 Những nội dung bắt buộc của một ST

...

...

...

a) Giới thiệu về ST gồm ba mô tả tường thuật về TOE ở các mức trừu tượng khác nhau;

b) Định nghĩa vấn đề an toàn, chỉ ra các mối đe dọa, OSP và những giả định.

c) Các mục tiêu an toàn, chỉ ra giải pháp cho vấn đề an toàn được phân chia giữa các mục tiêu an toàn cho TOE và các mục tiêu an toàn cho môi trường vận hành của TOE thế nào;

d) Định nghĩa các thành phần mở rộng (Tùy chọn), ở đây các thành phần mới (nghĩa là các thành phần không có trong TCVN 8709-2 hay TCVN 8709-3) có thể được định nghĩa. Các thành phần mới này cần để định nghĩa các yêu cầu chức năng và các yêu cầu đảm bảo mở rộng;

e) Những yêu cầu an toàn, nơi chuyển đổi các mục tiêu an toàn cho TOE sang một ngôn ngữ được chuẩn hóa. Ngôn ngữ chuẩn hóa này dưới dạng các SFR. Thêm vào đó, nó định nghĩa các SAR

f) Đặc tả tóm tắt TOE, cho thấy các SFR được thực thi thế nào trong TOE.

Hiện cũng tồn tại các ST đảm bảo thấp đã giảm bớt nội dung, chúng được mô tả chi tiết trong A.12. Tất cả các phần khác của phụ lục này giả định một ST với đầy đủ nội dung.

Hình A.1 - Nội dung đích an toàn

...

...

...

A.3.1. Một ST nên được sử dụng thế nào

Một ST điển hình đáp ứng hai vai trò sau:

– Trước và trong suốt khi đánh giá, ST xác định “cái gì được đánh giá". Trong vai trò này, ST phục vụ như nền tảng cơ bản cho việc thỏa thuận giữa nhà phát triển và đánh giá viên trên các đặc tính an toàn chính xác của TOE và phạm vi chính xác của việc đánh giá. Tính đúng đắn và hoàn chỉnh về mặt kỹ thuật là những vấn đề chính trong vai trò này. Điều A.7 mô tả một ST được sử dụng thế nào trong vai trò này.

– Sau khi đánh giá, ST xác định “cái gì đã được đánh giá”. Trong vai trò này, ST phục vụ như nền tảng cơ bản cho sự thỏa thuận giữa nhà phát triển hay người bán lại TOE và người tiêu dùng tiềm năng của TOE. ST mô tả các đặc tính an toàn chính xác của TOE một cách trừu tượng, và người tiêu dùng tiềm năng có thể dựa vào mô tả này vì TOE đã được đánh giá đáp ứng cho ST đó. Dễ sử dụng và dễ hiểu là những vấn đề chính trong vai trò này. Mục A.11 mô tả một ST sẽ được sử dụng thế nào trong vai trò này.

A.3.2 Cách một ST không nên sử dụng

Có hai vai trò (trong số nhiều vai trò) mà một ST không nên đáp ứng là:

– Một đặc tả chi tiết: Một ST được thiết kế là một đặc tả an toàn ở một mức cao tương đối về sự trừu tượng. Một ST, nói chung, không chứa các đặc tả giao thức chi tiết, các mô tả chi tiết về thuật toán và/hay cơ chế, không mô tả nhiều về hoạt động chi tiết v.v...

– Một đặc tả đầy đủ: Một ST được thiết kế là một đặc tả an toàn và không phải là một đặc tả tổng quát. Ngoại trừ chức năng an toàn liên quan, các đặc tính như khả năng tương tác, kích cỡ và trọng lượng vật lý, điện thế yêu cầu..v.v có thể là một phần của ST. Điều này có nghĩa một ST nói chung có thể là một phần của một đặc tả hoàn chỉnh, nhưng bản thân nó không phải là một đặc tả hoàn chỉnh.

A.4 Giới thiệu ST (ASE_INT)

...

...

...

a) Tham chiếu ST và tham chiếu TOE: cung cấp tư liệu nhận dạng ST và TOE mà ST tham chiếu tới;

b) Tổng quan về TOE: mô tả tóm tắt về TOE;

c) Mô tả TOE: mô tả chi tiết hơn về TOE;

A.4.1 Tham chiếu ST và tham chiếu TOE

Một ST gồm có phần tham chiếu rõ ràng về ST xác định cho từng ST cụ thể. Một ST điển hình bao gồm tựa đề, phiên bản, các tác giả và ngày phát hành. Ví dụ về một tham chiếu ST như sau “MauveRAM Database ST, phiên bản 1.3, Nhỏm MauveCorp Specification, ngày 11 tháng 10 năm 2002”.

Một ST cũng bao gồm cả tham chiếu TOE để định danh TOE, đòi hỏi tuân thủ với ST đó. Một tham chiếu TOE điển hình gồm tên nhà phát triển, tên TOE và số phiên bản TOE. Ví dụ như “MauveCorp MauveRAM Database v2.11”. Vì một TOE đơn lẻ có thể được đánh giá nhiều lần, ví dụ bởi những người tiêu dùng khác nhau của TOE này, do đó có nhiều ST, nên phần tham chiếu này không phải là cái nhất thiết duy nhất.

Nếu TOE được tạo nên từ một hoặc nhiều sản phẩm nổi tiếng, sẽ được phép thể hiện điều đó trong phần tham chiếu TOE, bằng cách tham chiếu đến tên (các) sản phẩm. Tuy nhiên, điều đó không nên dùng để gây nhầm lẫn cho khách hàng: các trường hợp trong đó những phần chính hay những chức năng an toàn không được xem xét trong đánh giá, do đó tham chiếu TOE không phán ánh điều này, là không được phép.

Tham chiếu ST và tham chiếu TOE tạo điều kiện cho việc lập chỉ mục, tham chiếu đến ST và TOE và đưa chúng vào tóm tắt danh sách các TOE/ các sản phẩm đã được đánh giá,

A.4.2 Tổng quan về TOE

...

...

...

Cuối cùng, phần tổng quan TOE mô tả tóm tắt cách sử dụng TOE và những đặc điểm an toàn chính của nó, chỉ rõ loại TOE và xác định bất kỳ phần cứng/phần mềm/phần sụn chủ yếu nào phi- TOE được yêu cầu bởi TOE.

A.4.2.1 Cách sử dụng và các đặc điểm an toàn chính của một TOE

Việc mô tả cách sử dụng và các đặc điểm an toàn chính của TOE chủ ý đưa ra một ý tường chung về việc TOE có khả năng về an toàn thế nào, và nó có thể sử dụng trong một ngữ cảnh an toàn thế nào. Nên biên soạn chúng cho những khách hàng (tiềm năng) của TOE, mô tả cách sử dụng TOE và các đặc điểm an toàn chính theo các hoạt động kinh doanh, sử dụng ngôn ngữ mà khách hàng TOE hiểu được.

Ví dụ “MauveCorp MauveRAM Database v2.11 là một cơ sở dữ liệu nhiều người dùng được hướng đến việc sử dụng trong một môi trường mạng. Nó cho phép 1024 người dùng sử dụng đồng thời. Nó cho phép xác thực mật khẩu/thẻ và sinh trắc học, bảo vệ chống lại việc dữ liệu bị hư hỏng đột ngột, và có thể kéo lại 10 nghìn giao dịch. Các đặc điểm kiểm chứng của nó có khả năng cấu hình cao, do đó cho phép thực hiện kiểm chứng chi tiết cho một số người dùng và giao dịch trong khi bảo vệ quyền riêng tư của những người dùng và giao dịch khác."

A.4.2.2 Kiểu TOE

Phần tổng quan TOE xác định kiểu TOE chung, chẳng hạn như: tường lửa, tưởng lửa VPN, thẻ thông minh, modem mã hóa, intranet, web server, cơ sở dữ liệu, web server và cơ sở dữ liệu, LAN, LAN với web server và cơ sở dữ liệu, v.v...

Có thể có trường hợp TOE không phải là kiểu sẵn sàng để dùng, trong trường hợp này từ “không” ghi cho kiểu TOE được chấp thuận.

Trong một vài trường hợp , một kiểu TOE có thể làm cho các khách hàng nhầm lẫn. Ví dụ:

– Chức năng nào đó có thể được mong đợi ở TOE do kiểu TOE của nó, nhưng TOE đó không có chức năng này. Ví dụ:

...

...

...

+ Một TOE kiểu firewall không hỗ trợ các giao thức được sử dụng hầu như phổ biến;

+ Một TOE kiểu PKI không có chức năng thu hồi chứng chỉ.

. TOE có thể được mong đợi hoạt động trong những môi trường vận hành nhất định vì kiểu TOE của nó, nhưng nó không thể làm như vậy. Ví dụ:

+ Một TOE kiểu hệ điều hành PC không có khả năng hoạt động an toàn trừ khi PC đó không kết nối mạng, không có ổ đĩa mềm và không có ở đĩa CD/DVD-player;

+ Một tường lửa không có khả năng hoạt động an toàn trừ khi tất cả người dùng có kết nối qua tường lửa này đều là những người không phải là tin tặc.

A.4.2.3 Phần cứng/phần mềm/phần sụn phi- TOE cần thiết

Trong khi một số TOE không dựa vào CNTT khác, thì có nhiều TOE (đặc biệt là các TOE phần mềm) dựa trên vào phần cứng, phần mềm và/hoặc phần sụn phi- TOE bổ sung thêm. Trong trường hợp thứ 2, phần tổng quan TOE là cần thiết để xác định phần cứng, phần mềm và/hoặc phần sụn phi- TOE đó. Một định danh chi tiết và thực sự đầy đủ của phần cứng, phần mềm và/hoặc phần sụn bổ sung là không cần thiết, nhưng việc định danh nên đầy đủ và chi tiết đủ để người tiêu dùng tiềm năng xác định được phần cứng, phần mềm và/hoặc phần sụn chính đáp ứng cho nhu cầu sử dụng TOE.

Ví dụ về các định danh phần cứng/phần mềm/phần sụn này là:

. Một PC chuẩn với bộ xử lý 1GHz hoặc nhanh hơn và RAM 512MB hoặc hơn, chạy phiên bản 3.0 Update 6b, c hoặc 7 hoặc phiên bản 4.0 của hệ điều hành Yaiza;

...

...

...

– Một PC chuẩn với phiên bản 3.0 của Yaiza OS (hoặc cao hơn)

– Một mạch tích hợp CleverCard SB2067;

– Một mạch tích hợp CleverCard SB2067 chạy v2.0 của hệ điều hành thẻ thông minh QuickOS;

– Bản cài đặt cài đặt mạng LAN tháng 12 năm 2002 của Văn phòng Giám Đốc Sở Giao Thông.

A.4.3 Mô tả TOE

Một mô tả TOE là một mô tả tường tận về TOE, có thể dài nhiều trang. Mô tả TOE nên đưa ra cho những đánh giá viên và người tiêu dùng tiềm năng những hiểu biết chung về khả năng an toàn của TOE, chi tiết hơn sẽ được cung cấp trong phần tổng quan về TOE. Mô tả TOE cũng có thể mô tả ngữ cảnh ứng dụng rộng hơn phù hợp với TOE.

Mô tả TOE bàn đến phạm vi vật lý của TOE: danh sách tất cả các phần cứng, phần mềm, phần sụn và các phần hướng dẫn tạo thành TOE. Danh sách này nên được mô tả ở mức độ chi tiết đủ để đưa ra cho người đọc cái nhìn chung nhất về những thành phần đó.

Mô tả TOE cũng nên bàn về phạm vi logic của TOE: các đặc điểm an toàn về mặt logic cung cấp bởi TOE ở một mức độ chi tiết phù hợp để đưa cho người đọc cái nhìn chung về những đặc điểm đó. Mô tả này được đòi hỏi chi tiết hơn so với các đặc điểm an toàn chủ yếu mô tả trong phần tổng quan TOE.

Một đặc tính quan trọng về phạm vi vật lý và logic của TOE là chúng mô tả TOE theo cách mà ở đó không có sự hồ nghi nào về việc một phần hay một đặc điểm nào đó là trong TOE hay không, hoặc phần đó hay đặc điểm đó là bên ngoài TOE hay không. Điều này đặc biệt quan trọng khi TOE được kết hợp với và không thể dễ dàng tách ra khỏi các thực thể phi-TOE.

...

...

...

– TOE là một bộ đồng xử lý mật mã của IC thẻ thông minh, thay vì toàn bộ IC;

– TOE là một IC thẻ thông minh, ngoại trừ bộ xử lý mật mã;

– TOE là phần chuyển đổi địa chỉ mạng (NAT) của MinuteGap Firewall v18.5.

A.5 Các tuyên bố tuân thủ (ASE_CCL)

Mục này của một ST mô tả cách thức ST tuân thủ với:

– Phần 2 và Phần 3 của Tiêu chuẩn này;

– Hồ sơ bảo vệ (nếu có);

– Các gói (nếu có);

Các mô tả về cách ST tuân thủ với TCVN 8709 bao gồm hai phần: phiên bản của ISO /IEC 15408 đã sử dụng và liệu các ST có chứa các yêu cầu an toàn mở rộng hay không (xem A.8).

...

...

...

Các mô tả về sự tuân thủ của ST với các gói, có nghĩa là ST liệt kê các gói đang yêu cầu tuân thủ. Để giải thích về điều này, xem 9.4.

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

A.6.1 Giới thiệu

Định nghĩa vấn đề an toàn xác định vấn đề an toàn cần đề cập đến. Định nghĩa vấn đề an toàn là một điều hiển nhiên trong TCVN 8709. Như vậy, quá trình đi đến định nghĩa vấn đề an toàn nằm ngoài phạm vi của TCVN 8709.

Tuy nhiên, cần lưu ý rằng, tính hữu ích của kết quả đánh giá phụ thuộc rất nhiều vào ST, và tính hữu ích của ST phụ thuộc nhiều vào chất lượng của định nghĩa vấn đề an toàn. Do đó, thật xác đáng khi dành nguồn lực đáng kể và sử dụng những quy trình và phân tích đã biết để đưa ra một định nghĩa tốt về vấn đề an toàn.

Lưu ý rằng theo TCVN 8709-3, không bắt buộc phải có các phát biểu trong tất cả các mục con, một ST với những mối đe dọa không nhất thiết cần có các OSP và ngược lại. Ngoài ra, mọi ST đều có thể bỏ qua các giả định.

Cũng lưu ý rằng tại những nơi TOE được phân phối về mặt vật lý, tốt hơn là nên bàn về các mối đe dọa liên quan, các OSP và các giả định riêng rẽ cho các miền riêng biệt của môi trường vận hành TOE.

A.6.2 Các mối đe dọa

Mục này của định nghĩa vấn đề an toàn chỉ ra các mối đe dọa được tính đến bởi TOE, môi trường vận hành của TOE, hay kết hợp của cả hai.

...

...

...

Những hành động có hại là những hành động thực hiện bởi một tác nhân gây nguy cơ trên một tài sản. Những hành động này ảnh hưởng đến một hoặc nhiều đặc tính của một tài sản mà giá trị tài sản xác định từ các đặc tính đó.

Những tác nhân gây nguy cơ có thể được mô tả như những thực thể riêng, nhưng trong một số trường hợp sẽ tốt hơn nếu mô tả chúng theo từng loại thực thể, các nhóm thực thể, v.v...

Ví dụ về các tác nhân gây hại là những tin tặc, người dùng, các tiến trình máy tính, và các tai họa. Những tác nhân gây hại có thể được mô tả hơn nữa về các mặt như kinh nghiệm, nguồn lực, cơ hội và động lực.

Ví dụ về các mối đe dọa là:

– Một tin tặc (có chuyên môn đáng kể, thiết bị chuẩn, và được trả tiền để làm điều đó) sẽ sao chép từ xa các tập tin mật từ một mạng máy tính công ty;

– Một sâu máy tính sẽ làm xuống cấp nghiêm trọng hiệu năng của một mạng máy tính diện rộng;

– Một quản trị viên hệ thống vi phạm quyền riêng tư cá nhân người dùng;

– Một người nào đó trên Internet nghe lén giao tiếp điện tử mật;

A.6.3 Các chính sách an toàn của tổ chức tổ chức (OSPs)

...

...

...

OSP là những quy tắc, thủ tục, hoặc hướng dẫn an toàn được áp đặt (hoặc coi là sẽ áp đặt) hiện tại và/hoặc trong tương lai bởi một tổ chức thực tế hoặc giả thuyết trong môi trường vận hành. OSP có thể được đặt ra bởi một tổ chức kiểm soát môi trường vận hành của TOE, hoặc chúng có thể được đặt ra bởi các cơ quan lập pháp hay điều tiết. OSP có thể áp dụng cho các TOE và / hoặc môi trường vận hành của các TOE.

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

– Tất cả các sản phẩm được sử dụng bởi Chính phủ phải tuân thủ theo tiêu chuẩn quốc gia trong việc mã hóa và việc phát sinh mật khẩu;

– Chỉ những người dùng có đặc quyền Quản trị Hệ thống và được phép của phòng kiểm tra an ninh mới được phép quản trị máy chủ của cơ quan.

A.6.4 Các giả định

Mục này của định nghĩa vấn đề an toàn chỉ ra các giả định cho môi trường vận hành để có thể cung cấp chức năng an toàn. Nếu TOE được đặt trong một môi trường vận hành không đáp ứng được các giả định này, thì TOE có thể không có khả năng cung cấp tất cả các chức năng an toàn nữa. Những giả định có thể về mặt vật lý, con người và kết nối của môi trường vận hành.

Ví dụ về các giả định là:

– Các giả định về các khía cạnh vật lý của môi trường vận hành:

- Giả định là TOE sẽ được đặt trong một căn phòng được thiết kế để giảm thiểu phát xạ điện từ;

...

...

...

– Các giả định về khía cạnh con người của môi trường vận hành:

- Giả định là người dùng TOE sẽ được đào tạo đầy đủ để vận hành TOE;

- Giả định là người dùng TOE chấp thuận những thông tin được phân loại là Bí mật Quốc gia;

- Giả định là người dùng TOE sẽ không viết ra mật khẩu của họ.

– Giả định các khía cạnh kết nối của môi trường vận hành:

- Giả định là một máy trạm PC có ít nhất 10GB không gian đĩa sẵn cho việc chạy TOE trên đó;

- Giả định là TOE là ứng dụng phi-OS duy nhất đang chạy trên máy trạm này;

- Giả định là TOE sẽ không kết nối với một mạng không tin cậy.

Lưu ý rằng trong quá trình đánh giá, những giả định này được coi là đúng: chúng không được kiểm tra theo bất kỳ cách nào. Vì những lý do này, các giả định chỉ có thể được tạo ra trên môi trường vận hành. Những giả định có thể chưa bao giờ được tạo ra trên hành vi của TOE vì một đánh giá bao gồm các xác nhận đánh giá được tạo ra về TOE và không phải bằng cách giả định là các xác nhận trên TOE là đúng.

...

...

...

Các mục tiêu an toàn là một phát biểu ngắn gọn và trừu tượng về giải pháp dự kiến cho vấn đề được xác định trong định nghĩa vấn đề an toàn. Vai trò của các mục tiêu an toàn là:

– Cung cấp một giải pháp bậc cao, theo ngôn ngữ tự nhiên cho vấn đề;

– Chia giải pháp này thành hai giải pháp từng phần, phản ánh các thực thể khác nhau, mỗi giải pháp đề cập đến một phần của vấn đề;

– Diễn giải rằng các giải pháp từng phần nêu trên hình thành nên một giải pháp hoàn chỉnh cho vấn đề.

A.7.1 Giải pháp mức cao

Các mục tiêu an toàn bao gồm một tập hợp các phát biểu ngắn gọn và rõ ràng mà không quá chi tiết, phối hợp với nhau hình thành một giải pháp mức cao cho vấn đề an toàn. Mức độ trừu tượng của các mục tiêu an toàn nhằm vào tính rõ ràng và dễ hiểu giúp cho người tiêu dùng tiềm năng có thể hiểu được TOE đó. Các mục tiêu an toàn thể hiện theo ngôn ngữ tự nhiên.

A.7.2 Các giải pháp từng phần

Trong một ST, giải pháp an toàn mức cao, như được mô tả với các mục tiêu an toàn, sẽ được chia thành hai giải pháp từng phần. Những giải pháp từng phần này được gọi là các mục tiêu an toàn cho TOE và các mục tiêu an toàn cho môi trường vận hành. Điều này phản ánh rằng các giải pháp từng phần sẽ được cung cấp bởi hai thực thể khác nhau: TOE, và môi trường vận hành.

A.7.2.1 Các mục tiêu an toàn cho TOE

...

...

...

Ví dụ về các mục tiêu an toàn cho TOE là:

– TOE phải giữ bí mật nội dung của tất cả các tệp được truyền giữa nó và một máy chủ;

– TOE phải định danh và xác thực tất cả người dùng trước khi cho phép họ truy cập tới Dịch vụ truyền phát cung cấp bởi TOE;

– TOE phải hạn chế người dùng truy cập vào dữ liệu theo chính sách Truy cập Dữ liệu được mô tả trong Phụ lục 3 của ST.

Nếu TOE được phân phối về mặt vật lý, tốt hơn là chia nhỏ điều khoản ST chứa các mục tiêu an toàn cho TOE thành một vài mục con để phản ánh điều này.

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

Môi trường vận hành của TOE thực hiện các biện pháp kỹ thuật và thủ tục để hỗ trợ TOE cung cấp đúng chức năng an toàn của nó (được định nghĩa bởi các mục tiêu an toàn cho TOE). Giải pháp từng phần này được gọi là các mục tiêu an toàn cho môi trường vận hành và bao gồm một tập hợp các phát biểu mô tả các mục tiêu mà môi trường vận hành cần đạt được.

Ví dụ về các mục tiêu an toàn đối với môi trường vận hành là:

– Môi trường vận hành phải cung cấp một máy trạm với hệ điều hành Inux OS phiên bản 3.01b để thực thi TOE trên đó;

...

...

...

– Môi trường vận hành của TOE phải giới hạn truy cập vật lý vào TOE cho nhân viên hành chính và cho nhân viên bảo trì có nhân viên hành chính kèm theo;

– Môi trường vận hành phải đảm bảo tính bí mật của các bản ghi kiểm toán tạo ra bởi TOE trước khi gửi chúng tới máy chủ kiểm toán trung tâm.

Nếu môi trường vận hành của TOE bao gồm nhiều địa điểm, mỗi địa điểm có những đặc tính khác nhau, tốt hơn là chia nhỏ điều khoản ST chứa các mục tiêu an toàn cho môi trường vận hành thành các mục nhỏ để phản ánh điều này.

A.7.3 Mối quan hệ giữa các mục tiêu an toàn và định nghĩa vấn đề an toàn

ST cũng chứa một sở cứ cho các mục tiêu an toàn với hai mục con như sau:

– Một dấu vết chỉ ra các mục tiêu an toàn nào nhắm tới các mối đe dọa, các OSP và những giả định nào;

– Một tập các biện minh chỉ ra tất cả các mối đe dọa, các OSP, và các giả định được đề cập đến một cách hiệu quả qua các mục tiêu về an toàn.

A.7.3.1 Dấu vết giữa các mục tiêu an toàn và định nghĩa vấn đề an toàn

Dấu vết cho thấy cách các mục tiêu toàn truy dấu vết các mối đe dọa, các OSP và các giả định như mô tả trong định nghĩa vấn đề an toàn.

...

...

...

b) Hoàn thành theo định nghĩa vấn đề an toàn: Mỗi mối đe dọa, OSP và giả định có ít nhất một dấu vết mục tiêu an toàn ghi theo nó.

c) Ghi vết đúng: Vì những giả định luôn được tạo bởi TOE trên môi trường vận hành, các mục tiêu an toàn cho TOE không truy vết về những giả định. Các dấu vết được phép trong TCVN 8709-3 được miêu tả trong Hình A.2.

Hình A.2 - Dấu vết giữa các mục tiêu an toàn và định nghĩa vấn đề an toàn

Nhiều mục tiêu an toàn có thể ghi vết theo cùng mối đe dọa, biểu thị rằng sự kết hợp của các mục tiêu an toàn là để chống lại mối đe dọa đó. Một luận cứ tương tự cũng dùng cho các OSP và các giả định.

A.7.3.2 Cung cấp biện minh cho việc ghi vết

Sở cứ cho các mục tiêu an toàn cũng diễn giải rằng việc ghi vết có hiệu quả: Tất cả các mối đe dọa, các OSP và các giả định được đề cập đến (nghĩa là được đối phó, thực thi và gìn giữ thích đáng) nếu có được tất cả các dấu vết cho các mục tiêu an toàn đến một mối đe dọa, một OSP hoặc một giả định cụ thể.

Luận cứ này phân tích tác động của việc đạt được các mục tiêu an toàn tương ứng về việc chống lại các mối đe dọa, việc thực thi các OSP và duy trì các giả định để đưa đến kết luận rằng luận cứ trên là đúng.

Trong một số trường hợp, khi các phần của định nghĩa vấn đề an toàn rất giống với một số mục tiêu an toàn, thì luận cứ có thể rất đơn giản. Một ví dụ là: một mối đe dọa "T17: tác nhân gây nguy cơ X đọc được các Thông tin Bí mật truyền qua lại giữa A và B", một mục tiêu an toàn cho TOE: "OT12: TOE phải đảm bảo rằng tất cả các thông tin được truyền giữa A và B được giữ bí mật", và một luận cứ “T17 được đối phó trực tiếp bằng OT12”

...

...

...

Chống lại một mối đe dọa không cần thiết có nghĩa lả loại bỏ mối đe dọa đó, nó có thể cũng nghĩa là giảm thiểu mối đe dọa đó, hoặc giảm nhẹ mối đe dọa.

Ví dụ về loại bỏ một mối đe dọa là:

– Loại bỏ khả năng thực hiện hành động có hại từ tác nhân gây hại;

– Di chuyển, thay đổi hoặc bảo vệ tài sản theo một cách mà hành động có hại không còn áp dụng đối với nó được nữa;

– Loại bỏ các tác nhân gây nguy cơ (ví dụ loại bỏ các máy trong một mạng máy tính thường xuyên làm sập mạng đó).

Ví dụ về làm giảm nhẹ một mối đe dọa là:

– Hạn chế khả năng của tác nhân gây hại thực hiện các hành động có hại;

– Hạn chế cơ hội để thực hiện một hành động có hại của một tác nhân gây hại;

– Giảm khả năng xảy ra của một hành động có hại đang được thực hiện thành công;

...

...

...

– Yêu cầu chuyên môn cao hơn hoặc nhiều tài nguyên hơn từ phía tác nhân gây nguy cơ.

Ví dụ về giảm tác động của một mối đe dọa là:

– Tạo back-up thường xuyên của tài sản đó;

– Có được bản sao dự phòng của một tài sản;

– Bảo hiểm tài sản;

– Đảm bảo rằng khi các hành động có hại thành công thì luôn kịp thời phát hiện, từ đó có thể đưa ra hành động thích hợp.

A.7.4. Các mục tiêu an toàn: kết luận

Căn cứ vào các mục tiêu an toàn và sở cứ các mục tiêu an toàn an toàn, kết luận sau đây có thể được rút ra: nếu tất cả các mục tiêu an toàn đạt được thì vấn đề an toàn như đã định nghĩa trong ASE_SPD được giải quyết: tất cả các mối đe dọa sẽ được chống lại, tất cả các OSP được thi hành, và tất cả các giả định được gìn giữ.

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

...

...

...

Lưu ý rằng, mục này chỉ bao gồm các thành phần mở rộng và chứ không gồm những yêu cầu mở rộng (những yêu cầu dựa trên các thành phần mở rộng). Những yêu cầu mở rộng sẽ được đặt trong những yêu cầu an toàn (xem A.9) và cũng là những yêu cầu dựa trên các thành phần trong TCVN 8709-2 hoặc TCVN 8709-3 đối với mọi mục đích.

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

Các yêu cầu an toàn bao gồm hai nhóm sau:

a) Các yêu cầu về chức năng an toàn (SFR): Chuyển đổi các mục tiêu an toàn cho TOE sang một ngôn ngữ chuẩn hóa;

b) Các yêu cầu về đảm bảo an toàn (SAR): Mô tả cách đạt được sự đảm bảo là TOE đáp ứng các SFR.

Hai nhóm này được thảo luận trong A.9.1 và A.9.2.

A.9.1. Các yêu cầu về chức năng an toàn (SFR)

Các SFR là một bản dịch của các mục tiêu an toàn cho TOE. Chúng thường ở mức độ trừu tượng chi tiết hơn, nhưng chúng phải là một bản dịch hoàn chỉnh (các mục tiêu an toàn phải được đề cập đến một cách đầy đủ) và độc lập với bất kỳ giải pháp kỹ thuật cụ thể nào (sự thực thi). TCVN 8709 yêu cầu chuyển đổi sang một ngôn ngữ chuẩn hóa vì những lý do:

– Để cung cấp một mô tả chính xác về những gì đang được đánh giá. Vì các mục tiêu an toàn cho TOE thường được phát biểu theo ngôn ngữ tự nhiên, nên việc chuyển đổi sang một ngôn ngữ chuẩn hóa cho một mô tả chính xác hơn về chức năng của TOE.

...

...

...

Trong TCVN 8709 không yêu cầu có sự chuyển đổi cho các mục tiêu an toàn đối với môi trường vận hành, bởi vì không đánh giá môi trường vận hành và do đó không đòi hỏi việc mô tả nhằm cho việc đánh giá đó. Xem tài liệu tham khảo cho các danh mục liên quan đến đánh giá an toàn cho các hệ thống vận hành.

Có thể có trường hợp, các phần của môi trường vận hành được đánh giá trong một đánh giá khác, nhưng điều này nằm ngoài phạm vi đối với việc đánh giá hiện tại. Ví dụ: một TOE OS có thể yêu cầu một tường lửa hiện diện trong môi trường vận hành của nó. Một đánh giá khác có thể tiếp tục đánh giá bức tường lửa này, song đánh giá này không liên quan gì đến việc đánh giá TOE OS.

A.9.1.1 ISO/IEC 15.408 hỗ trợ việc chuyển đổi này thế nào

TCVN 8709 hỗ trợ việc chuyển đổi trên theo ba cách:

a) Bằng cách cung cấp một "ngôn ngữ" rõ ràng xác định trước, dành cho việc mô tả chính xác những gì sẽ được đánh giá. Ngôn ngữ này cũng được định nghĩa là một tập các thành phần đã được định nghĩa trong TCVN 8709-2. Việc sử dụng ngôn ngữ này để chuyển đổi rành mạch các mục tiêu an toàn cho TOE thành các SFR là bắt buộc, cho dù tồn tại một số ngoại lệ (xem 7.3).

b) Bằng cách cung cấp các hoạt động: các cơ chế cho phép tác giả của ST sửa đổi các SFR để cung cấp một bản dịch chính xác hơn cho các mục tiêu an toàn cho TOE. Phần này của TCVN 8709 định nghĩa bốn hoạt động được phép: Ấn định, lựa chọn, lặp lại, và bổ sung chi tiết. Những điều này sẽ được mô tả rõ hơn trong C.2.

c) Bằng cách đưa ra những phụ thuộc: một cơ chế hỗ trợ một bản dịch hoàn chỉnh hơn tới các SFR. Trong ngôn ngữ TCVN 8709-2, một SFR có thể có một sự phụ thuộc vào các SFR khác. Điều này có ý nghĩa rằng, nếu một ST sử dụng một SFR đó, nó thường cần phải sử dụng cả những SFR khác đó. Điều này làm cho tác giả của ST không dễ dàng để bỏ qua những SFR cần thiết và do đó cải thiện tính đầy đủ của các ST. Sự phụ thuộc được mô tả rõ hơn trong 7.2.

A.9.1.2. Mối quan hệ giữa SFR và các mục tiêu an toàn

ST cũng chứa một sở cứ về những yêu cầu an toàn, bao gồm hai mục sau về SFR:

...

...

...

– Một tập các biện minh chỉ ra tất cả các mục tiêu an toàn cho TOE được đề cập đến một cách hiệu quả nhờ các SFR.

A.9.1.2.1. Dấu vết giữa SFR và các mục tiêu an toàn cho TOE

Dấu vết cho thấy các SFR truy vết các mục tiêu an toàn cho TOE như sau:

a) Không có SFR giả mạo: Mỗi dấu vết SFR truy vết tới ít nhất một mục tiêu an toàn.

b) Hoàn thành theo các mục tiêu an toàn cho TOE: Mỗi mục tiêu an toàn cho TOE có ít nhất một SFR truy vết đến nó.

Nhiều SFR có thể ghi vết đến cùng một mục tiêu an toàn cho TOE, điều này chỉ ra rằng sự kết hợp của những yêu cầu an toàn an toàn sẽ đáp ứng được mục tiêu an toàn của TOE.

A.9.1.2.2. Cung cấp biện minh cho ghi vết

Sở cứ cho những yêu cầu an toàn diễn giải rằng việc truy vết này có hiệu quả: nếu tất cả SFR truy vết đến một mục tiêu an toàn cụ thể đối với TOE được thỏa mãn, thì mục tiêu an toàn của TOE sẽ đạt được.

Luận cứ trên nên phân tích những ảnh hưởng của việc thỏa mãn SFR có liên quan về việc đạt được các mục tiêu an toàn cho TOE và đưa đến kết luận luận cứ trên là đúng.

...

...

...

A.9.2. Các yêu cầu đảm bảo an toàn (SAR)

Các SAR là mô tả về việc TOE được đánh giá thế nào. Mô tả này sử dụng một ngôn ngữ chuẩn hóa vì hai lý do sau:

– để cung cấp một mô tả chính xác về cách TOE được đánh giá. Sử dụng một ngôn ngữ chuẩn hóa hỗ trợ trong việc tạo ra một mô tả chính xác và tránh sự mơ hồ.

– để cho phép so sánh giữa hai ST. Vì các tác giả ST khác nhau có thể sử dụng thuật ngữ khác nhau khi mô tả việc đánh giá, nên ngôn ngữ chuẩn hóa thực thi bằng cách sử dụng cùng một thuật ngữ và khái niệm. Điều này cho phép dễ dàng so sánh.

Chuẩn hóa ngôn ngữ này được định nghĩa là một tập hợp các thành phần được định nghĩa trong TCVN 8709-3. Việc sử dụng ngôn ngữ này là bắt buộc, mặc dù có một số ngoại lệ tồn tại. TCVN 8709 nâng cao ngôn ngữ này theo hai cách:

a) cung cấp các hoạt động: các cơ chế cho phép tác giả của ST sửa đổi các SAR. TCVN 8709 có bốn hoạt động: chỉ định, lựa chọn, lặp lại, và bổ sung chi tiết. Những điều đó được mô tả rõ hơn trong 7.1.

b) đưa ra những phụ thuộc: một cơ chế hỗ trợ một bản dịch hoàn chỉnh hơn tới SFR. Trong ngôn ngữ TCVN 8709-2, một SFR có thể có một sự phụ thuộc vào các SFR khác. Điều này có ý nghĩa rằng, nếu một ST sử dụng một SFR đó, nó thường cần phải sử dụng cả những SFR khác đó. Điều này làm cho tác giả của ST không dễ dàng để bỏ qua những SFR cần thiết và do đó cải thiện tính đầy đủ của các ST. Sự phụ thuộc được mô tả rõ hơn trong 7.2.

A.9.3. Các SAR và sở cứ những yêu cầu an toàn

ST cũng chứa một sở cứ về các yêu cầu an toàn, giải thích lý do tại sao tập các SAR cụ thể này được coi là thích hợp. Không có yêu cầu đặc trưng nào cho lời giải thích này. Mục tiêu cho lời giải thích này là để cho phép người đọc ST để hiểu lý do tại sao tập đó được chọn.

...

...

...

A.9.4. Những yêu cầu an toàn: kết luận

Trong định nghĩa vấn đề an toàn của ST, vấn đề an toàn được định nghĩa là bao gồm các mối đe dọa, các OSP và các giả định. Trong điều khoản về các mục tiêu an toàn của ST, giải pháp được đưa ra dưới dạng của hai giải pháp con:

– các mục tiêu an toàn cho TOE;

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

Ngoài ra, một sở cứ các mục tiêu an toàn được đưa ra cho thấy rằng nếu tất cả các mục tiêu an toàn đạt được, thì vấn đề an toàn được giải quyết: tất cả các mối đe dọa sẽ được chống lại, tất cả các OSP được thực thi, và tất cả các giả định được gìn giữ.

Hình A.3 - Quan hệ giữa định nghĩa vấn đề an toàn, các mục tiêu an toàn và các yêu cầu an toàn

Trong mục những yêu cầu an toàn của ST, các mục tiêu an toàn cho TOE được dịch sang SFR và sở cứ các yêu cầu an toàn được đưa ra cho thấy rằng nếu tất cả SFR được thỏa mãn, thì tất cả các mục tiêu an toàn cho TOE là đạt được.

Ngoài ra, một bộ SAR được cung cấp để thể hiện TOE được đánh giá thế nào, cùng với lời giải thích cho việc lựa chọn các SAR đó.

...

...

...

Lượng bảo đảm đạt được được định nghĩa bởi các SAR, và việc lượng này có đủ hay không được định nghĩa bởi phần giải thích về việc chọn các SAR này.

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

Mục tiêu đối với đặc tả tóm tắt TOE là cung cấp tới người tiêu dùng tiềm năng của TOE một mô tả về TOE thỏa mãn tất cả các SFR như thế nào. Đặc tả tóm tắt TOE nên đưa ra các cơ chế kỹ thuật chung mà TOE sử dụng cho mục đích này. Mức độ chi tiết của mô tả đó nên đủ để cho phép người tiêu dùng tiềm năng hiểu được những dạng và sự thực thi chung của các TOE.

Ví dụ nếu TOE là một PC trên Internet và các SFR chứa FIA_UAU.1 để đặc tả việc xác thực, đặc tả tóm tắt TOE nên chỉ ra làm thế nào xác thực này được thực hiện: mật khẩu, token, quét võng mạc, vv. Các thông tin khác, như các tiêu chuẩn áp dụng mà TOE sử dụng để đáp ứng các SFR, hoặc mô tả chi tiết hơn cũng có thể được đưa ra.

A.11. Những câu hỏi có thể được trả lời với một ST

Sau khi đánh giá, ST quy định "những gì được đánh giá". Trong vai trò này, ST phục vụ như một cơ sở để thỏa thuận giữa các nhà phát triển hoặc người bán lại TOE và người tiêu dùng tiềm năng của các TOE đó. ST do đó có thể trả lời các câu hỏi sau đây (và nhiều hơn):

a) Làm thế nào tôi có thể tìm thấy ST/TOE mà tôi cần trong vô số những ST/TOE đang hiện tại được đưa ra? Câu hỏi này được đề cập trong phần tổng quan TOE, trong đó đưa ra một tóm tắt ngắn gọn (khoảng vài đoạn văn bản) cho TOE;

b) TOE này có phù hợp với cơ sở hạ tầng CNTT hiện tại của tôi không? Câu hỏi này được đề cập trong phần tổng quan TOE, trong đó xác định các phần tử phần cứng/phần mềm/phần sụn cần thiết để chạy TOE;

c) TOE này có phù hợp với môi trường vận hành hiện tại của tôi không? Câu hỏi này được đề cập trong phần các mục tiêu an toàn cho môi trường vận hành, trong đó xác định tất cả các hạn chế mà TOE đặt ra cho môi trường vận hành để hoạt động;

...

...

...

e) TOE làm gì (người tiêu dùng tiềm năng)? Câu hỏi này được đề cập trong phần tổng quan TOE, nó đưa ra một tóm tắt ngắn gọn (vài trang) về TOE;

f) TOE làm gì (kỹ thuật viên)? Câu hỏi này được đề cập trong phần đặc tả tóm tắt TOE, ở đó cung cấp một mô tả mức cao về các cơ chế mà TOE sử dụng;

g) TOE làm gì (chuyên gia)? Câu hỏi này được đề cập trong các SFR, ở đó cung cấp một mô tả kỹ thuật trừu tượng mức cao và đặc tả tóm tắt TOE cung cấp chi tiết thông tin bổ sung;

h) TOE có đề cập đến vấn đề theo quy định của chính phủ /tổ chức của tôi không? Nếu chính phủ/tổ chức của bạn đã định nghĩa các gói và/hoặc các PP để xác định giải pháp này, thì câu trả lời có thể tìm thấy trong mục Các tuyên bố tuân thủ của ST, trong đó liệt kê tất cả các gói và các PP mà ST tuân thủ theo.

i) Có TOE có đề cập đến vấn đề an toàn của tôi không (chuyên gia)? Các mối đe dọa nào mà TOE chống lại được? Nó thực thi các chính sách bảo mật về mặt tổ chức nào? Nó tạo ra các giả định nào về môi trường vận hành? Những câu hỏi này được đề cập trong định nghĩa vấn đề an toàn;

j) Tôi có thể tin cậy TOE đến mức nào? Điều này có thể được tìm thấy trong các SAR ở mục những yêu cầu an toàn, ở đó cung cấp các cấp đảm bảo được sử dụng để đánh giá TOE, và do đó độ tin cậy mà việc đánh giá cung cấp trong tính chính xác của TOE.

A.12. Các đích an toàn đảm bảo mức thấp

Biên soạn một ST không phải là một công việc tầm thường, và có thể, đặc biệt là trong đánh giá đảm bảo mức thấp, đây là một phần chính trong toàn bộ nỗ lực bỏ ra của nhà phát triển và đánh giá viên trong toàn bộ quá trình đánh giá. Vì lý do này, cũng có thể viết một ST đảm bảo mức thấp.

TCVN 8709 cho phép sử dụng một ST đảm bảo mức thấp cho một đánh giá EAL 1, nhưng không dùng cho EAL 2 trở lên. Một ST đảm bảo thấp chỉ có thể đòi hỏi phù hợp với một PP đảm bảo thấp (xem Phụ lục B). Một ST thông thường (ví dụ, một ST có nội dung đầy đủ) có thể đòi hỏi phù hợp với một PP đảm bảo thấp.

...

...

...

– không cần mô tả định nghĩa vấn đề an an toàn;

– không cần mô tả các mục tiêu an toàn cho TOE. Các mục tiêu an toàn cho môi trường vận hành vẫn phải được mô tả;

– không cần mô tả sở cứ các mục tiêu an toàn vì không có định nghĩa vấn đề an toàn trong ST;

– Sở cứ các yêu cầu an toàn chỉ cần để chứng tỏ sự phụ thuộc không được thỏa mãn vì không có những mục tiêu an toàn cho TOE trong ST này.

Tất cả những thứ ST vẫn duy trì là:

a) Các tham chiếu tới TOE và ST;

b) Một tuyên bố tuân thủ;

c) Các mô tả tường tận khác nhau;

1) Tổng quan TOE;

...

...

...

3) Đặc tả tóm tắt TOE.

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

e) Các SFR và SAR (bao gồm cả định nghĩa các thành phần mở rộng) và sở cứ các yêu cầu an toàn (chỉ khi sự phụ thuộc không được thỏa mãn).

Nội dung đã giản lược của một ST đảm bảo thấp được thể hiện trong Hình A.4.

Hình A.4 - Các nội dung của một đích an toàn đảm bảo mức thấp

A.13. Tham chiếu tới tiêu chuẩn khác trong một ST

Trong một số trường hợp, tác giả biên soạn ST có thể muốn tham chiếu tới một tiêu chuẩn bên ngoài, chẳng hạn như một tiêu chuẩn hoặc giao thức mã hóa cụ thể. TCVN 8709 cho phép ba cách thực hiện sau:

a) Như một chính sách an toàn về mặt tổ chức (hoặc một phần của nó).

...

...

...

b) Như một tiêu chuẩn kỹ thuật (ví dụ một tiêu chuẩn mật mã) được sử dụng trong một phép bổ sung chi tiết cho một SFR.

Trường hợp này, tuân thủ theo tiêu chuẩn là một phần của việc thỏa mãn các SFR bởi TOE và được xử lý như kiểu một văn bản đầy đủ của tiêu chuẩn là một phần của SFR. Tính tuân thủ tiếp đó được xác định giống như bất kỳ sự tuân thủ khác theo các SFR: trong ADV và ATE, nó được phân tích, qua phân tích thiết kế và kiểm thử, để chỉ ra SFR là đầy đủ và được triển khai hoàn toàn trong TOE. Nếu chỉ muốn tham chiếu tới một phần nhất định của tiêu chuẩn, thì phần đó cần được nêu rõ ràng trong phần bổ sung chi tiết trong SFR.

c) Như một tiêu chuẩn kỹ thuật (ví dụ như một tiêu chuẩn mật mã) được đề cập trong đặc tả tóm tắt  TOE.

Đặc tả tóm tắt TOE chỉ được xem xét đến như một giải thích về cách các SFR được thực hiện, và sử dụng không chặt chẽ như một yêu cầu thực thi chặt chẽ giống như SFR hoặc các tài liệu chuyển giao cho ADV. Như vậy, đánh giá viên có thể phát hiện một sự không nhất quán nếu TSS tham chiếu đến một tiêu chuẩn kỹ thuật và điều này không được phản ánh trong tài liệu ADV, nhưng không có động thái thường kỳ để kiểm thử sự đáp ứng của tiêu chuẩn.

PHỤ LỤC B

(Tham khảo)

Đặc tả của Hồ sơ bảo vệ PP

B.1. Mục tiêu và cấu trúc của phụ lục

...

...

...

Vì PP và ST có chồng chéo đáng kể lên nhau, nên phụ lục này tập trung vào sự khác biệt giữa PP và ST. Các tài liệu giống hệt nhau giữa ST và PP được mô tả trong Phụ lục A.

Phụ lục này bao gồm bốn phần chính:

a) Những gì một PP phải có. Điều này được tóm tắt trong B.2, và mô tả chi tiết hơn trong B.4 đến B.9. Những điều khoản này mô tả các nội dung bắt buộc của PP, mối tương quan giữa những nội dung này, và đưa ra các ví dụ.

b) Một PP nên được sử dụng như thế nào. Điều này được tóm tắt trong B.3.

c) PP đảm bảo thấp. PP đảm bảo thấp là PP có nội dung được giản lược. Chúng được mô tả chi tiết trong B.11.

d) Yêu cầu tuân thủ càc tiêu chuẩn. B.12 mô tả cách một tác giả PP có thể yêu cầu TOE là để đáp ứng một tiêu chuẩn cụ thể.

B.2. Các nội dung bắt buộc của một PP

Hình B.1 miêu tả nội dung bắt buộc đối với một PP mà TCVN 8709-3 đưa ra. Hình B.1 cũng có thể được sử dụng như là một phác thảo cấu trúc của PP, mặc dù cấu trúc thay thế được cho phép. Ví dụ, nếu các lý do những yêu cầu an toàn đặc biệt cồng kềnh, nó có thể được bao gồm trong một phụ lục của PP thay vì trong mục những yêu cầu an toàn. Các mục riêng biệt của một PP và nội dung của những mục đó được tóm tắt ngắn gọn dưới đây và được giải thích chi tiết hơn nữa trong B.4 đến B.9. Một PP chứa:

a) Giới thiệu PP chứa đựng một mô tả tường tận loại TOE;

...

...

...

c) Một định nghĩa vấn đề an toàn, chỉ ra các mối đe dọa, OSP và giả định;

d) Các mục tiêu an toàn, biểu thị giải pháp cho vấn đề an toàn được chia thành các mục tiêu an toàn cho TOE và mục tiêu an toàn cho môi trường vận hành của TOE;

e) Định nghĩa các thành phần mở rộng, ở đó các thành phần mới (tức là những thành phần không có trong TCVN 8709-2 hoặc TCVN 8709-3) có thể được định nghĩa. Các thành phần mới này cần được định nghĩa những yêu cầu chức năng mở rộng và yêu cầu đảm bảo mở rộng;

f) Những yêu cầu an toàn, ở đó những mục tiêu an toàn cho TOE được chuyển sang một ngôn ngữ tiêu chuẩn hóa. Ngôn ngữ tiêu chuẩn hóa này là ở dạng các SFR. Ngoài ra mục này còn định nghĩa các SAR;

Cũng tồn tại các PP đảm bảo mức thấp, chúng có các nội dung được giảm bớt; chúng được mô tả chi tiết trong B.11. Ngoài ngoại lệ này, tất cả các phần khác trong phụ lục này giả thiết một PP với đầy đủ các nội dung.

Hình B.1 - Các nội dung hồ sơ bảo vệ

B.3. Sử dụng PP

B.3.1. Một PP nên được sử dụng thế nào

...

...

...

Một PP vì thế thường được sử dụng như:

– một phần của một đặc tả yêu cầu đối với một người tiêu dùng hoặc một nhóm người tiêu dùng xác định, những người sẽ chỉ xem xét việc mua một loại cụ thể của CNTT nếu nó đáp ứng PP;

– một phần của một quy định từ một thực thể pháp lý cụ thể, những người sẽ chỉ cho phép một loại cụ thể của CNTT được sử dụng nếu đáp ứng PP;

– một cơ sở giới hạn xác định bởi một nhóm các nhà phát triển CNTT, những người sẽ đồng ý rằng tất cả các sản phẩm CNTT mà họ sản xuất theo loại này sẽ đáp ứng cơ sở giới hạn này.

mặc dù điều này không ngăn cản các sử dụng khác của PP.

B.3.2. Cách một PP không nên được sử dụng

Ba vai trò (trong số nhiều vai trò) mà một PP không nên thực hiện là:

– một đặc tả chi tiết: Một PP được thiết kế để là một đặc tả an toàn trên một mức độ trừu tượng tương đối cao. Một PP nói chung, không nên chứa đặc tả giao thức chi tiết, những mô tả chi tiết về các thuật toán và/hoặc các cơ chế, mô tả dài về các hoạt động chi tiết, vv...

– một đặc tả hoàn chỉnh: Một PP được thiết kế để là một đặc tả an toàn và không phải là một đặc tả chung. Ngoại trừ liên quan đến an toàn, các đặc tính chẳng hạn như khả năng tương tác, kích thước và trọng lượng vật lý, điện áp yêu cầu vv... không nên là một phần của PP. Điều này có nghĩa rằng, một PP là một phần của một đặc tả hoàn chỉnh, nhưng không phải là một đặc tả hoàn chỉnh.

...

...

...

B.4. Giới thiệu PP (APE_INT)

Giới thiệu PP mô tả các TOE một cách tường tận theo hai mức độ trừu tượng:

a) tham chiếu PP, cung cấp tài liệu định danh cho PP;

b) tổng quan về TOE, trong đó mô tả ngắn gọn TOE.

B.4.1. Tham chiếu PP

PP chứa đựng một tham chiếu PP rõ ràng, định rõ một PP cụ thể. Một tham chiếu PP điển hình bao gồm tiêu đề, phiên bản, tác giả và ngày xuất bản. Ví dụ về một tham chiếu PP là "Atlantean Navy CablePhone Encryptor PP, phiên bản 2b, Atlantean Navy Procurement Office, 07 tháng 4 năm 2003". Tham chiếu phải là duy nhất để có thể kể đến PP khác và các phiên bản khác của cùng một PP.

Tham chiếu PP giúp lập chỉ mục dễ dàng và tham khảo các PP và đưa nó vào danh sách các PP.

B.4.2. Tổng quan TOE

Tổng quan TOE nhằm hướng tới những khách hàng tiềm năng của TOE, giúp họ lướt nhanh qua danh mục các TOE/sản phẩm đã được đánh giá để tìm kiếm TOE có khả năng đáp ứng cho nhu cầu an toàn của họ, và được hỗ trợ bởi phần cứng, phần mềm và phần sụn của họ.

...

...

...

Thông thường chiều dài của một tổng quan về TOE là một vài đoạn văn bản.

Cuối cùng, phần tổng quan TOE mô tả tóm tắt cách sử dụng của TOE và những đặc điểm an toàn chính của nó, chỉ rõ loại TOE và xác định bất kỳ phần cứng/phần mềm/phần phi-TOE chính nào sẵn dùng cho TOE.

B.4.2.1. Cách sử dụng và các đặc điểm an toàn chính của một TOE

Việc mô tả cách sử dụng và các đặc điểm an toàn chính của TOE được hướng đến để đưa ra một ý tưởng chung về TOE nào có khả năng, và TOE nào nó có thể sử dụng cho một bối cảnh an toàn. Nó có thể được viết cho những khách hàng (tiềm năng) của TOE, mô tả cách sử dụng TOE và các đặc điểm an toàn chính trong nhóm hoạt động kinh doanh, sử dụng ngôn ngữ mà người dùng TOE hiểu được.

Một ví dụ " The Atlantean Navy CablePhone Encryptor là một thiết bị mã hóa cho phép truyền thông tin bảo mật giữa các tàu qua hệ thống Atlantean Navy CablePhone. Nó cho phép ít nhất 32 người dùng khác nhau và hỗ trợ ít nhất là 100 Mbps tốc độ mã hóa. Nó sẽ cho phép cả hai giao tiếp song phương giữa các tàu và quảng bá trên toàn bộ mạng."

B.4.2.2. Kiểu TOE

Tổng quan TOE xác định loại TOE chung, chẳng hạn như: tường lửa, tường lửa VPN, thẻ thông minh, modem mã hóa, intranet, web server, cơ sở dữ liệu, web server và cơ sở dữ liệu, LAN, LAN với web server và cơ sở dữ liệu, v.v. .

B.4.2.3 Các phần cứng/phần mềm/phần sụn phi-TOE sẵn dùng

Trong khi một số TOE không dựa vào CNTT khác, nhiều TOE (đặc biệt là TOE phần mềm) dựa vào phi-TOE phần cứng, phần mềm và / hoặc phần sụn bổ sung. Trong trường hợp thứ hai, tổng quan về TOE là cần thiết để xác định các phi-TOE phần cứng / phần mềm / phần sụn.

...

...

...

Ví dụ về sự nhận biết các phần cứng / phần mềm / phần sụn này là:

– Không có. (đối với một TOE hoàn toàn độc lập);

– Hệ điều hành Yaiza 3,0 chạy trên một máy tính nói chung;

– Mạch tích hợp CleverCard SB2067;

– Một CleverCard SB2067 IC chạy v2.0 với hệ điều hành thẻ thông minh QuickOS;

– Bản cài đặt tháng 12 năm 2002 cho các mạng LAN của Văn phòng Giám đốc Sở Giao thông.

B.5. Các tuyên bố tuân thủ (APE_CCL)

Mục này của một PP mô tả cách thức PP tuân thủ với các PP khác và với các gói. Nó giống mục tuyên bố tuân thủ đối với ST (xem A.5), với một ngoại lệ: phát biểu tuân thủ.

Phát biểu tuân thủ trong PP tuyên bố về việc ST và / hoặc PP khác phải tuân thủ với PP đó như thế nào. Tác giả PP lựa chọn xem yêu cầu là tuân thủ "chặt chẽ" hay tuân thủ "biểu hiện". Phụ lục D sẽ cho biết thêm chi tiết về điều này.

...

...

...

Mục này giống hệt mục định nghĩa vấn đề an toàn của một ST như được giải thích trong A.6.

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

Mục này giống hệt với các mục mục tiêu an toàn của một ST như được giải thích trong A.7.

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

Mục này giống hệt với mục định nghĩa các thành phần mở rộng của một ST như được giải thích trong A.8

B.9. Những yêu cầu an toàn (APE_REQ)

Mục này giống hệt mục những yêu cầu an toàn của một ST như được giải thích trong A.9. Tuy nhiên lưu ý rằng các quy tắc để hoàn thành các hoạt động trong một PP hơi khác các quy tắc để hoàn thành các hoạt động trong một ST. Điều này được giải thích cụ thể hơn trong 7.1.

B.10. Đặc tả tóm tắt TOE

PP không có đặc tả kỹ thuật tóm tắt TOE.

...

...

...

Một PP đảm bảo thấp có cùng một mối quan hệ với một PP thông thường (PP có nội dung đầy đủ), cũng như một bảo đảm ST thấp có một ST thông thường. Điều này có nghĩa rằng một PP đảm bảo thấp bao gồm

a) Giới thiệu PP, bao gồm phần tham chiếu PP và tổng quan về một TOE;

b) Tuyên bố tuân thủ;

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

d) các SFR và SAR (bao gồm cả định nghĩa các thành phần mở rộng) và sở cứ yêu cầu an toàn (chỉ khi sự phụ thuộc không thỏa mãn).

Một PP đảm bảo thấp chỉ có thể tuyên bố tuân thủ với một PP đảm bảo thấp (xem B.5). Một PP thông thường có thể tuyên bố tuân thủ với một PP đảm bảo thấp.

Nội dung đã giản lược của một PP bảo đảm thấp được thể hiện trong Hình B.2.

Hình B.2 - Các nội dung một hồ sơ bảo vệ mức đảm bảo thấp

...

...

...

Mục này giống hệt mục các tiêu chuẩn cho ST như mô tả trong A.13, ngoại trừ: vì một PP không có đặc tả tóm tắt TOE, nên tùy chọn thứ ba là không hợp lệ cho PP.

PHỤ LỤC C

(Tham khảo)

Hướng dẫn vận hành

C.1. Giới thiệu

Như được mô tả trong phần này của TCVN 8709, Hồ sơ Bảo vệ và Đích an toàn có chứa các yêu cầu an toàn được xác định trước, cũng như cung cấp cho tác giả của PP và ST khả năng mở rộng danh sách thành phần trong một số trường hợp.

C.2. Ví dụ về các hoạt động

Bốn loại hoạt động được đưa ra trong 7.1. Ví dụ về các hoạt động khác nhau được mô tả dưới đây:

...

...

...

Như được mô tả trong 7.1.1, hoạt động lặp có thể được thực hiện trên mỗi thành phần. Tác giả PP/ST thực hiện một hoạt động lặp lại bằng cách đưa vào nhiều yêu cầu cho cùng một thành phần. Mỗi lần lặp lại của một thành phần đều khác với tất cả các lần lặp lại khác của thành phần đó. Sự khác biệt này có được nhờ thực hiện chỉ định và lựa chọn theo cách khác nhau, hoặc áp dụng các bổ sung chi tiết theo cách khác nhau. Sự lặp lại khác nhau nên được xác định duy nhất để cho phép những sở cứ và dấu vết vào/ra các yêu cầu này được rõ ràng.

Một ví dụ điển hình của phép lặp là FCS_COP.1 được lặp hai lần để yêu cầu thực hiện hai thuật toán mã hóa khác nhau. Ví dụ về mỗi lần lặp lại được xác định duy nhất là:

Mật mã hoạt động (chữ ký RSA và DSA) (FCS_COP.1 (1))

Mật mã hoạt động (TLS / SSL: hoạt động đối xứng) (FCS_COP.1 (2))

C.2.2. Hoạt động chỉ định

Như mô tả trong 7.1.2, một hoạt động chỉ định xảy ra khi thành phần đưa ra chứa một phần tử với một tham số có thể được thiết lập bởi tác giả PP/ST. Tham số có thể là một biến không hạn chế, hay quy luật thu hẹp một biến số thành một dãy các giá trị cụ thể.

Một ví dụ của một phần tử chỉ định là: FIA_AFL.1.2 "Khi số lượng quy định của nỗ lực xác thực không thành công đạt được hoặc vượt qua, thì các TSF cần [chỉ định: danh sách các hành động]."

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

Như mô tả trong 7.1.3, hoạt động lựa chọn xảy ra khi thành phần đưa ra chứa một phần tử mà ở đó việc lựa chọn một số tiêu chí phải được thực hiện bởi tác giả PP/ ST.

...

...

...

C.2.4. Các hoạt động bổ sung chi tiết

Như mô tả trong 7.1.4, hoạt động bổ sung chi tiết có thể được thực hiện trên mọi yêu cầu. Tác giả PP / ST thực hiện một bổ sung chi tiết bằng cách thay đổi yêu cầu đó.

Một ví dụ về một bổ sung chi tiết hợp lệ là FIA_UAU.2.1 "The TSF cần yêu cầu mỗi người dùng phải xác thực thành công trước khi cho phép bất kỳ hành động trung gian TSF nào thay mặt cho người dùng đó." được bổ sung chi tiết để trở thành "TSF cần yêu cầu mỗi người sử dụng xác thực thành công bằng tên người dùng / mật khẩu trước khi cho phép bất kỳ hành động trung gian TSF nào thay mặt cho người dùng đó."

Quy tắc đầu tiên để bổ sung chi tiết là một TOE đáp ứng yêu cầu đã tinh lọc cũng cần đáp ứng các yêu cầu chưa tinh lọc trong ngữ cảnh của PP/ST (tức là một yêu cầu đã tinh lọc phải "chặt chẽ" hơn so với yêu cầu ban đầu). Ngoại lệ duy nhất cho quy tắc này là một tác giả PP/ST được phép tinh lọc một SFR để áp dụng cho một số nhưng không phải tất cả các chủ thể, đối tượng, các hoạt động, các thuộc tính an toàn và / hoặc các thực thể bên ngoài.

Một ví dụ về một trường hợp ngoại lệ như vậy là FIA_UAU.2.1 "The TSF cần yêu cầu mỗi người dùng phải xác thực thành công trước khi cho phép bất kỳ hành động trung gian TSF nào thay mặt cho người dùng đó" được bổ sung chi tiết để trở thành "TSF cần yêu cầu mỗi người sử dụng có nguồn gốc từ Internet phải xác thực thành công trước khi cho phép bất kỳ hành động trung gian TSF nào thay mặt cho người dùng đó."

Quy tắc thứ hai cho một bổ sung chi tiết được đưa ra là bổ sung chi tiết phải liên quan đến các thành phần gốc. Ví dụ, tinh lọc một thành phần kiểm toán với một phần tử bổ sung chống bức xạ điện từ là không được phép.

Một trường hợp đặc biệt của bổ sung chi tiết là một bổ sung chi tiết biên tập, ở đó, một sự thay đổi nhỏ sẽ được tạo ra trong một yêu cầu, nghĩa là diễn tả lại một câu để giữ đúng ngữ pháp tiếng Anh, hoặc để làm cho nó dễ hiểu hơn đối với người đọc. Sự thay đổi này không được phép sửa đổi ý nghĩa của yêu cầu. Ví dụ về bổ sung chi tiết biên tập bao gồm:

– SFR FPT_FLS.1 "TSF cần tiếp tục duy trì một trạng thái an toàn khi các lỗi sau đây xảy ra: sự cố của một CPU" có thể được bổ sung chi tiết thành FPT_FLS.1 "TSF cần tiếp tục duy trì một trạng thái an toàn khi xảy ra lỗi sau đây: sự cố của một CPU" hoặc thậm chí FPT_FLS.1 "TSF cần tiếp tục duy trì một trạng thái an toàn khi một CPU bị hỏng".

C.3. Tổ chức của các thành phần

...

...

...

– Các lớp, bao gồm

– Các họ, bao gồm

– Các thành phần, bao gồm

– Các phần tử.

Tổ chức thành một hệ thống các lớp - họ - thành phần - phần tử được cung cấp để trợ giúp người tiêu dùng, nhà phát triển và đánh giá viên trong xác định các thành phần cụ thể.

TCVN 8709 trình bày các thành phần chức năng và đảm bảo theo cùng kiểu phân cấp, sử dụng mô hình tổ chức và các khái niệm như nhau.

C.3.1. Lớp

Ví dụ về một lớp là lớp FIA, lớp này tập trung vào việc định danh người dùng, xác thực người dùng và ràng buộc các người dùng với các chủ thể.

C.3.2. Họ

...

...

...

C.3.3. Thành phần

Một ví dụ về một thành phần là FIA_UAU.3 Xác thực chống giả mạo, thành phần này tập trung vào xác thực chống giả mạo.

C.3.4. Phần tử

Một ví dụ về một phần tử là FIA_UAU.3.2, phần tử này tập trung vào việc ngăn chặn việc sử dụng dữ liệu chứng thực đã sao chép.

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

C.4.1. Cách xác định thành phần mở rộng

Mỗi khi tác giả PP/ST định nghĩa một thành phần mở rộng, việc đó cần thực hiện theo phương thức tương tự như các thành phần đã có trong TCVN 8709: rõ ràng, không mơ hồ và có thể đánh giá được (có thể diễn giải một cách hệ thống về việc liệu một yêu cầu dựa trên thành phần đó có áp dụng được cho một TOE hay không). Các thành phần mở rộng phải sử dụng ghi nhãn, cách thức thể hiện, mức độ chi tiết tương tự như các thành phần đã có trong TCVN 8709.

Tác giả PP / ST cũng cần phải chắc chắn rằng mọi sự phụ thuộc áp dụng cho một thành phần mở rộng đã được đưa vào trong định nghĩa thành phần mở rộng đó. Ví dụ về sự phụ thuộc có thể là:

a) nếu một thành phần mở rộng tham chiếu đến kiểm toán, thì sự phụ thuộc đến các thành phần của lớp Fau có thể phải được đưa vào;

...

...

...

c) nếu một thành phần mở rộng sử dụng một mô tả thiết kế cụ thể, sự phụ thuộc vào họ ADV tương ứng (ví dụ Đặc tả chức năng) có thể phải được đưa vào.

Trong trường hợp một thành phần chức năng mở rộng, tác giả PP / ST cũng cần phải đưa vào mọi kiểm toán phù hợp và thông tin về các hoạt động liên quan trong định nghĩa của thành phần đó, tương tự như các thành phần sẵn có trong tiêu chuẩn TCVN 8709-2. Trong trường hợp một thành phần đảm bảo mở rộng, tác giả PP/ST cần phải cung cấp phương pháp luận đánh giá thích hợp cho thành phần, tương tự như phương pháp luận đã có trong ISO/IEC 18045.

Các thành phần mở rộng có thể được đặt trong các họ hiện có, trong đó người biên soạn PP/ST phải chỉ ra sự thay đổi các họ như thế nào. Nếu chúng không phù hợp với một họ hiện có, chúng sẽ được đặt trong một họ mới. Họ mới phải được định nghĩa tương tự theo TCVN 8709.

Các họ mới có thể được đặt trong các lớp hiện tại, trong đó người biên soạn PP / ST phải chỉ ra các lớp này thay đổi như thế nào. Nếu chúng không phù hợp với một lớp hiện có, chúng sẽ được đặt trong một lớp mới. Lớp mới này phải được định nghĩa tương tự theo TCVN 8709.

PHỤ LỤC D

(Tham khảo)

Tuân thủ PP

D.1. Giới thiệu

...

...

...

Lưu ý rằng cũng có thể một PP được sử dụng như một mẫu cho một PP khác. Đó là các PP có thể tuyên bố tuân thủ với các PP khác. Trường hợp này là hoàn toàn tương tự như của một ST so với một PP. Phụ lục này chỉ mô tả trường hợp ST/PP, còn nó được tổ chức như đối với trường hợp PP/ PP.

TCVN 8709 không cho phép bất kỳ hình thức tuân thủ từng phần nào, vì vậy nếu một PP được yêu cầu, các PP hoặc ST phải tuân thủ đầy đủ với PP hoặc các PP tham chiếu. Tuy nhiên, có hai kiểu tuân thủ ("hoàn toàn" và "có thể diễn giải") và kiểu tuân thủ cho phép được xác định bởi PP. Như vậy, PP tuyên bố (trong phát biểu tuân thủ PP, xem B.5) về những kiểu tuân thủ được phép cho ST. Sự phân biệt giữa tuân thủ chặt chẽ và tuân thủ có thể diễn giải có thể áp dụng cho mỗi PP mà một ST có thể yêu cầu tuân thủ theo cách riêng. Điều này có thể nghĩa là ST tuân thủ chặt chẽ với một số’PP và tuân thủ có diễn giải với một số PP khác. Một ST chỉ được phép tuân thủ với một PP theo phương thức diễn giải, nếu PP cho phép một cách rõ ràng điều này, trong khi đó một ST luôn có thể tuân thủ chặt chẽ với mọi PP.

Phát biểu điều trên bằng một cách khác là, một ST chỉ được phép tuân thủ với một PP theo phương thức diễn giải, nếu PP cho phép một cách rõ ràng điều này.

Tuân thủ với một PP nghĩa là PP hoặc ST (vả nếu một ST là một sản phẩm đã được đánh giá, cũng như một sản phẩm) đáp ứng mọi yêu cầu của PP này.

Các PP được công bố sẽ thường yêu cầu tuân thủ có thể diễn giải. Điều đó nghĩa là các ST đòi hỏi tuân thủ với PP sẽ phải đưa ra một giải pháp cho vấn đề an toàn chung đã nêu trong PP, song có thể thực hiện điều đó theo bất kỳ cách nào tương đương hoặc chặt chẽ hơn cách đã mô tả trong PP. “Tương đương song chặt chẽ hơn” được định nghĩa về độ dài trong TCVN 8709, song về nguyên tắc, điều đó nghĩa là PP và ST có thể chứa toàn bộ các phát biểu khác nhau về các thực thể khác nhau, sử dụng các khái niệm khác nhau.., với điều kiện tổng quát là ST thu được cùng hoặc nhiều hạn chế hơn về TOE, và cùng hoặc ít hạn chế hơn về môi trường hoạt động của TOE.

D.2. Tuân thủ chặt chẽ

Tuân thủ chặt chẽ hướng đến tác giả PP, người đòi hỏi bằng chứng về việc các yêu cầu trong PP được đáp ứng, về việc ST là một bản sao của PP, mặc dù ST có thể là rộng hơn so với PP. Về bản chất, ST quy định TOE đạt ít nhất tương tự như trong PP, trong khi môi trường vận hành hầu như giống trong PP.

Một ví dụ điển hình của việc sử dụng tuân thủ chặt chẽ là việc lựa chọn dựa trên mua sắm, trong đó các yêu cầu an toàn của sản phẩm được kỳ vọng trùng hợp chính xác với những quy định trong PP.

Tuân thủ chặt chẽ với một PP cho một bản sao của một ST có thể vẫn có một số hạn chế bổ sung so với những gì đã có trong PP.

...

...

...

Tuân thủ có thể diễn giải hướng tới tác giả PP, người yêu cầu bằng chứng về việc ST là một giải pháp thích hợp cho vấn đề an toàn chung được mô tả trong PP.

Khi có một mối quan hệ kiểu tập con - tập lớn rõ rệt giữa PP và ST trong trường hợp tuân thủ chặt chẽ, mối quan hệ này sẽ bị giảm tính rõ ràng trong trường hợp tuân thủ có thể diễn giải. Các ST yêu cầu tuân thủ với PP phải đưa ra một giải pháp cho vấn đề an toàn chung được mô tả trong PP.

Tuy nhiên, việc đòi hỏi tuân thủ chỉ được phép trong trường hợp ST áp đặt tương tự hoặc nhiều hơn các hạn chế trên TOE, và tương tự hoặc ít hơn các hạn chế về môi trường vận hành của TOE.

THƯ MỤC TÀI LIỆU THAM KHẢO

Các tiêu chuẩn ISO/IEC và hướng dẫn

[1] ISO/IEC 15292, lnformation technology - Security techniques - Protection Profile registration procedures

[2] ISO/IEC 15443 (all parts), Information technology - Security techniques - A framework for IT security assurance

[3] ISO/IEC 15446, Information technology - Security techniques - Guide for the production of Protection Profiles and Security Targets

...

...

...

[5] ISO/IEC 19791, Information technology - Security techniques - Security assessment of operational systems

[6] ISO/IEC 27001:2005, Information technology - Security techniques - lnformation security management systems - Requirements

[7] ISO/IEC 27002:2005, Information technology - Security techniques - Code of practice for information security management

[8] ISO/IEC 15408 - 1 : 2005, Information Technology - Security Techniques - Evaluation Criteria for IT Security - Part 1: Introduction and general model.

[9] ISO/IEC 15408 - 2 : 2005, Information Technology - Security Techniques - Evaluation Criteria for IT Security - Part 2: Security functional requirements.

[10] ISO/IEC 15408 - 3 : 2005, Information Technology - Security Techniques - Evaluation Criteria for IT Security - Part 3: Security assurance requirements.

[11] ISO/IEC 15408 - 1 : 2009, Information Technology - Security Techniques - Evaluation Criteria for IT Security - Part 1: Introduction and general model.

[12] ISO/IEC 15408 - 2 : 2008, Information Technology - Security Techniques - Evaluation Criteria for IT Security - Part 2: Security functional requirements.

[13] ISO/IEC 15408 - 3 : 2008, Information Technology - Security Techniques - Evaluation Criteria for IT Security - Part 3: Security assurance requirements.

...

...

...

[14] IEEE Std 610.12-1990, Institute of Electrical and Electronics Engineers, Standard Glossary of Software Engineering Terminology

[15] Common Criteria portal, February 2009. CCRA, www.commoncriteriaportal.org.

[16] TCVN 27001: 2009, Công nghệ thông tin - Các kỹ 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

CÁC THUẬT NGỮ SỬ DỤNG TRONG TIÊU CHUẨN

CHÚ THÍCH: Tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa trong bảng sau đây. Lưu ý là các thuật ngữ này được sử dụng riêng trong TCVN 8709 và ý nghĩa của chúng được hiểu trong ngữ cảnh của tiêu chuẩn TCVN 8709 nơi chúng được sử dụng.

1

Acceptance criteria

Các tiêu chí chấp thuận

...

...

...

Acceptance procedures

Các thủ tục chấp thuận

3

Administrator

Người quản trị

4

adverse actions

Các hành động có hại

5

...

...

...

Tài sản

6

Assignment

Chỉ định

7

Assurance

Bảo đảm

8

Attack potential

...

...

...

9

Augmentation

Gia tăng

10

Authentication data

Dữ liệu xác thực

11

Authorized user

Người dùng có thẩm quyền

...

...

...

Base component

Thành phần cơ sở

13

Call coupling

Ghép nối truy xuất

14

Call tree

Cây truy xuất

15

...

...

...

Lớp

16

CM documentation

Tài liệu CM

17

Coherent

Tính mạch lạc

18

Cohesion

...

...

...

19

Coincidental cohesion

Gắn kết trùng hợp

20

Common coupling

Ghép nối chung

21

Communication cohesion

Gắn kết truyền thông

...

...

...

Compatible

Tương thích

23

Complete

Tính hoàn thiện

24

Complexity

Độ phức tạp

25

...

...

...

Thành phần

26

Component TOE

TOE thành phần

27

Composed Assurance package

Gói đảm bảo tổng hợp

28

Composed TOE

...

...

...

29

Configuration management (CM)

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

30

Configuration management evidence

Bằng chứng quản lý cấu hình

31

Configuration management plan

Kế hoạch quản lý cấu hình

...

...

...

Configuration management output

Đầu ra quản lý câu hình

33

Configuration management system

Hệ thống quản lý cấu hình

34

Configuration management system records

Các bản ghi hệ thống quản lý cấu hình

35

...

...

...

Các công cụ quản lý cấu hình

36

Configuration management usage documentation

Tài liệu sử dụng quản lý cấu hình

37

Configuration item

Khoản mục cấu hình

38

Configuration list

...

...

...

39

Confirm

Xác nhận

40

Connectivity

Tính kết nối

41

Consistent

Tính nhất quán

...

...

...

Content coupling

Ghép nối nội dung

43

Counter (verb)

Chống trả

44

Coupling

Ghép nối

45

...

...

...

Kênh bất hợp pháp

46

Delivery

Chuyển giao

47

Demonstable contormance

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

48

Demontrate

...

...

...

49

Dependency

Tính phụ thuộc

50

Dependent component

Thành phần phụ thuộc

51

Describe

Mô tả

...

...

...

Determine

Xác định

53

Developer

Nhà phát triển

54

Development

Phát triển

55

...

...

...

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

56

Development tools

Các công cụ phát triển

57

Domain separation

Phân cách miền

58

Element

...

...

...

59

Encountered potential vulnerabilities

Các điểm yếu tiềm ẩn phải đối mặt

60

Ensure

Bảo đảm

61

Evaluation

Đánh giá

...

...

...

Evaluation assurance level (EAL)

Mức bảo đảm đánh giá (EAL)

63

Evaluation authority

Cơ quan đánh giá

64

Evaluation scheme

Lược đồ đánh giá

65

...

...

...

Thấu đáo

66

Explain

Giải thích

67

Exploitable vulnerability

Các điểm yếu có thể khai thác

68

Extension

...

...

...

69

External entity

Thực thể bên ngoài

70

Family

Họ

71

Formal

Hình thức

...

...

...

Functional cohesion

Gắn kết chức năng

73

Functional interface

Giao diện chức năng

74

Guidance documentation

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

75

...

...

...

Định danh

76

Implementation representation

Mô tả triển khai

77

Informal

Không hình thức

78

Installation

...

...

...

79

Inter TSF transfer

Vận chuyển giữa các TSF

80

Interaction

Tương tác

81

Interface

Giao diện

...

...

...

Internal communication channel

Kênh truyền thông nội bộ

83

Internal TOE transfer

Vận chuyển nội bộ TOE

84

Internally consistent

Tính nhất quán nội bộ

85

...

...

...

Phép lặp

86

Justification

Biện minh

87

Layering

Phân lớp

88

Life-cycle

...

...

...

89

Life-cycle definition

Định nghĩa vòng đời

90

Life-cycle model

Mô hình vòng đời

91

Logical cohesion, procedural cohesion

Gắn kết logic, gắn kết thủ tục

...

...

...

Modular decomposition

Phân tách mô đun

93

Monitoring attacks

Các tấn công (kiểu) giám sát

94

Non-bypassability

Khả năng không đi vòng

95

...

...

...

Đối tượng

96

Operation

Hoạt động

97

Operational environment

Môi trường vận hành

98

Organizational security policy

...

...

...

99

Package

Gói

100

Potential vulnerability

Các điểm yếu tiềm ẩn

101

Preparation

Chuẩn bị

...

...

...

Production

Sản xuất

103

Protection profile

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

104

Protection profile evaluation

Đánh giá Hồ sơ bảo vệ

105

...

...

...

Chứng minh

106

Refinement

Bổ sung chi tiết

107

Residual vulnerability

Các điểm yếu còn tồn tại

108

Role

...

...

...

109

Secret

Bí mật

110

Secure state

Trạng thái an toàn

111

Security attribute

Thuộc tính an toàn

...

...

...

Security domain

Miền an toàn

113

Security function policy

Chính sách chức năng an toàn

114

Security objective

Mục tiêu an toàn

115

...

...

...

Vấn đề an toàn

116

Security requirement

Yêu cầu an toàn

117

Security Target

Đích an toàn (ST)

118

Selection

...

...

...

119

Semiformal

Bán hình thức

120

Sequential cohesion

Gắn kết tuần tự

121

Software engineering

Công nghệ phần mềm

...

...

...

Specify

Đặc tả

123

Strict conformance

Tuân thủ chặt chẽ

124

ST evaluation

Đánh giá ST

125

...

...

...

Chủ thể

126

Target of Evaluation (TOE)

Đích đánh giá (TOE)

127

Temporal cohesion

Gắn kết tạm thời

128

Threat agent

...

...

...

129

TOE Evaluation

Đánh giá TOE

130

TOE resource

Tài nguyên TOE

131

TOE security functionality

Chức năng an toàn của TOE (TSF) ,

...

...

...

Trace (verb)

Theo dấu

133

Transfers outside of the TOE

Vận chuyển bên ngoài TOE

134

Translation

Chuyên đổi

135

...

...

...

Kênh tin cậy

136

Trusted IT product

Sản phẩm CNTT tin cậy

137

Trusted path

Đường dẫn tin cậy

138

TSF self-protection

...

...

...

139

TSF data

Dữ liệu TSF

140

TSF interface

Giao diện TSF

141

User data

Dữ liệu người dùng

...

...

...

Verify

Thẩm tra

143

Vulnerability

Điểm yếu

CÁC KÝ HIỆU VÀ TỪ VIẾT TẮT TRONG TIÊU CHUẨN

Viết tắt

Tiếng Anh tương đương

...

...

...

ADV

ADV:Development

Lớp ADV: Phát triển

ADV_ARC

ADV_ARC: Security architecture Description

ADV_FSP: Đặc tả kiến trúc an toàn

ADV_FSP

ADV_FSP:Basic functional specification

ADV_FSP: Đặc tả chức năng cơ bản

...

...

...

ADV_TDS: Basic design

ADV_TDS: Thiết kế cơ bản

AGD

AGD:Guidance documents

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

AGD_OPE

AGD_OPE:Operational user guidance

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

AGD_PRE

...

...

...

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

ALC

ALC:Life-cycle support

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

ALC_CMC

ALC_CMC: Labelling of the TOE

ALC_CMC: Dán nhãn TOE

ALC_CMC

ALC_CMS: TOE CM Coverage

...

...

...

ALC_DEL

ALC_DEL: Delivery procedures

ALC_DEL: Các thủ tục chuyển giao

ALC_DVS

ALC_DVS: Identification of security measures

ALC_DVS: Định danh các biện pháp an toàn

ASE

ASE:Security Target evaluation

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

...

...

...

ASE_CCL: Conformance claims

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

ASE_ECD

ASE_ECD: extended components definition

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

ASE_INT

ASE_INT: ST introduction

ASE_INT: Giới thiệu ST

ASE_OBJ

...

...

...

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

ASE_REQ

ASE_REQ: stated security requirements

ASE_REQ: Các yêu cầu an toàn đã công bố

ASE_SPD

ASE_SPD: Security problem definition

ASE_SPD: Định nghĩa vấn đề an toàn

ASE_TSS

ASE_TSS: TOE summary specification

...

...

...

ATE

ATE:Tests

Lớp ATE: Kiểm thử

ATE_COV

ATE_COV:Evidence of coverage

ATE_COV: Chứng cứ về tính tổng quát

ATE_DPT

ATE_DPT: Testing: basic design

ATE_DPT: Kiểm thử: thiết kế cơ bản

...

...

...

ATE_FUN:Functional Testing

ATE_FUN: Kiểm thử chức năng

ATE_IND

ATE_IND:lndependent testing - conformance

ATE_IND: Kiểm thử độc lập - Tuân thủ

AVA

AVA:Vulnerability assessment

Lớp AVA:.Đánh giá điểm yếu

AVA_VAN

...

...

...

AVA_VAN: Khảo sát điểm yếu

API

Application Programming Interface

Giao diện lập trình ứng dụng

CAP

Composed Assurance Package

Gói đảm bảo tổng hợp

CM

Configuration Management

...

...

...

CNTT

Information Technology (IT)

Công nghệ thông tin (CNTT)

DAC

Discretionary Access Control

Kiểm soát truy nhập tùy ý

EAL

Evaluation Assurance Level

Mức bảo đảm đánh giá

...

...

...

Function Security Audit Class

Lớp kiểm toán an toàn (FAU)

FAU_ARP

FAU: Security audit automatic response

FAU: Phản hồi tự động kiểm toán an toàn

FAU_GEN

FAU: Security audit data generation

FAU: Tạo dữ liệu kiểm toán an toàn

FAU_SAA

...

...

...

FAU: Phân tích kiểm toán an toàn

FAU_SAR

FAU: Security audit review

FAU: Soát xét kiểm toán an toàn

FAU_SEL

FAU: Security audit event selection

FAU: Lựa chọn sự kiện kiểm toán an toàn

FAU_STG

FAU: Security audit event storage

...

...

...

FCO

Function Communication

Lớp FCO: truyền thông

FCO_NRO

FCO_NRO: Non-repudiation of origin

FCO_NRO: Không từ chối nguồn gốc

FCO_NRR

FCO_NRR: Non-repudiation of receipt

FCO_NRR: Không từ chối khi nhận

...

...

...

Function Cryptographic support

Lớp FCS: Hỗ trợ mật mã

FCS_CKM

FCS_CKM: Cryptographic key management

FCS_CKM: Quản lý khóa mật mã

FCS_COP

FCS_COP: Cryptographic operation

FCS_COP: Hoạt động mật mã

FDP

...

...

...

Lớp FDP: Bảo vệ dữ liệu người dùng

FDP_ACC

FDP: Access control policy

FDP: Chính sách kiểm soát truy nhập

FDP_ACF

FDP: Access control functions

FDP: Các chức năng kiểm soát truy nhập

FDP_DAU

FDP: Data authentication

...

...

...

FDP_ETC

FDP: Export from TOE

FDP_ETC: Xuất dữ liệu ra khỏi TOE

FDP_IFC

FDP: lnformation flow control policy

FDP_IFC: Chính sách kiểm soát luồng tin

FDP_IFF

FDP: lnformation flow control functions

FDP_IFF: Các chức năng kiểm soát luồng tin

...

...

...

FDP: lmport from outside of the TOE

FDP_ITC: Nhập dữ liệu từ bên ngoài TOE

FDP_ITT

FDP: lnternal TOE transfer

FDP_ITT: Vận chuyển nội bộ TOE

FDP_RIP

FDP: Residual information protection

FDP_RIP: Bảo vệ thông tin còn sót lại.

FDP_ROL

...

...

...

FDP_ROL: Khôi phục lại

FDP_SDI

FDP: Stored data integrity

FDP_SDI: Toàn vẹn dữ liệu đã lưu trữ

FDP_UCT

FDP: lnter-TSF user data confidentiality transfer protection

FDP_UCT: Bảo vệ truyền bí mật dữ liệu người dùng liên - TSF

FDP_UIT

FDP: lnter-TSF user data integrity transfer protection

...

...

...

FIA

Function Identification and Authentication

Lớp FIA: Định danh và xác thực

FIA_AFL

FIA_AFL: Authentication failures

FIA_AFL: Các lỗi xác thực

FIA_ATD

FIA_ATD: User attribute definition

FIA_ATD: Định nghĩa thuộc tính người dùng

...

...

...

FIA_SOS: Specification of secrets

FIA_SOS: Đặc tả các bí mật

FIA_UAU

FIA_UAU: User Authentication

FIA_UAU: Xác thực người dùng

FIA_UID

FIA_UID: User identification

FIA_UID: Định danh người dùng

FIA_USB

...

...

...

FIA_USB: Liên kết người dùng-chủ thể

FMT

Function Security Management

Lớp FMT: Quản lý an toàn

FMT_MOF

FMT_MOF: Management of functions in TSF

FMT_MOF: Quản lý các chức năng trong TSF

FMT_MSA

FMT_MSA: Management of Security attributes

...

...

...

FMT_MTD

FMT_MTD: Management of TSF data

FMT_MTD: Quản lý dữ liệu TSF

FMT_REV

FMT_REV: Revocation

FMT_REV: Hủy bỏ

FMT_SAE

FMT_SAE: Security attribute expiration

FMT_SAE: Các thuộc tính an toàn quá hạn

...

...

...

FMT_SMF: Specification of Management functions

FMT_SMF: Đặc tả các chức năng quản lý

FMT_SMR

FMT_SMR: Security Management roles

FMT_SMR: Các vai trò quản lý an toàn

FPR

Function Privacy

Lớp FPR: Riêng tư

FPR_ANO

...

...

...

FPR_ANO: Nặc danh

FPR_PSE

FPR_PSE: Pseudonymity

FPR_PSE: Biệt danh

FPR_UNL

FPR_UNL: Unlinkability

FPR_UNL: Không thể liên kết

FPR_UNO

FPR_UNO: Unobservability

...

...

...

FPT

Function Protection of the TSF

Lớp FPT: Bảo vệ TSF

FPT_FLS

FPT_FLS: Fail secure

FPT_FLS: An toàn khi có lỗi

FPT_ITA

FPT_ITA: Availability of exported TSF data

FPT_ITA:Tính sẵn sàng của dữ liệu TSF xuất ra

...

...

...

FPT_ITC: Confidentiality of exported TSF data

FPT_ITC: Tính bí mật của dữ liệu TSF xuất ra

FPT_ITL

FPT_ITL: lntegrity of exported TSF data

FPT_ITL: Tính toàn vẹn của dữ liệu TSF xuất ra

FPT_ITT

FPT_ITT: Internal TOE TSF data transfer

FPT_ITT: Vận chuyển dữ liệu nội bộ TOE TSF

FPT_PHP

...

...

...

FPT_PHP: Bảo vệ vật lý cho TSF

FPT_RCV

FPT_RCV:Trusted recovery

FPT_RCV: Khôi phục tin cậy

FPT_RPL

FPT_RPL: Replay detection

FPT_RPL: Phát hiện chạy lại

FPT_SSP

FPT_SSP: State synchrony protocol

...

...

...

FPT_STM

FPT_STM: Time stamps

FPT_STM: Các nhãn thời gian

FPT_TDC

FPT_TDC: lnter-TSF TSF data consistency

FPT_TDC: Sự nhất quán dữ liệu TSF liên TSF

FPT_TEE

FPT_TEE: Testing of external entitites

FPT_TEE: Kiểm thử các thực thể bên ngoải

...

...

...

FPT_TRC: Internal TOE TSF data replication consistency

FPT_TRC:Tính nhất quán của bản sao dữ liệu nội bộ của TOE TSF

FPT_TST

FPT_TST: TSF selftest

FPT_TST: Tự kiểm tra TSF

FRU

Function Resource utilisation

Lớp FRU: Sử dụng tài nguyên

FRU_FLT

...

...

...

FRU_FLT: Khả năng chịu lỗi

FRU_PRS

FRU_PRS: Priority of Service

FRU_PRS: ưu tiên dịch vụ

FRU_RSA

FRU_RSA: Resource allocation

FRU_RSA: cấp phát tài nguyên

FTA

Function TOE Access

...

...

...

FTA_LSA

FTA_LSA: Limitation on scope of selectable attributes

FTA_LSA: Giới hạn phạm vi các thuộc tính có thể chọn lựa

FTA_MCS

FTA_MCS: Limitation on multiple concurrent sessions

FTA_MCS: Giới hạn số lượng phiên đồng thời

FTA_SSL

FTA_SSL: Session locking and termination

FTA_SSL: Khoa phiên và kết thúc

...

...

...

FTA_TAB: TOE access banners

FTA_TAB: Các tiêu đề truy nhập TOE

FTA_TAH

FTA_TAH: TOE access history

FTA_TAH: Lịch sử truy cập TOE

FTA_TSE

FTA_TSE: TOE session establishment

FTA_TSE: Thiết lập phiên TOE

FTP

...

...

...

Lớp FTP: Tuyến/Kênh tin cậy

FTP_ITC

FTP_ITC: lnter-TSF trusted channel

FTP_ITC: Kênh tin cậy liên TSF

FTP_TRP

FTP_TRP: Trusted path

FTP_TRP: Đường dẫn tin cậy

GHz

Gigahertz

...

...

...

GUI

Graphical User Interface

Giao diện người dùng dạng đồ họa

IC

Integrated Circuit

Mạch tổ hợp

IOCTL

Input Output Control

Kiểm soát vào ra

...

...

...

Internet Protocol

Giao thức Internet

IT

lnformation Technology

Công nghệ thông tin (CNTT)

MB

Mega Byte

Đơn vị thông tin Mega Byte (MB)

OS

...

...

...

Hệ điều hành

OSP

Organizational Security Policy

Chính sách an toàn của tổ chức

PC

Personal Computer

Máy tính cá nhân

PCI

Peripheral Component Interconnect

...

...

...

PKI

Public Key Infrastructure

Hạ tầng cơ sở khóa công khai

PP

Protection Profile

Hồ sơ bảo vệ

RAM

Random Access Memory

Bộ nhớ truy nhập ngẫu nhiên

...

...

...

Remote Procedure Call

Lời gọi thủ tục từ xa

SAR

Security Assurance Requirement