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

Một phần của tài liệu CÔNG NGHỆ THÔNG TIN – CÁC KỸ THUẬT AN TOÀN – CÁC TIÊU CHÍ ĐÁNH GIÁ CHO AN TOÀN CNTT – (Trang 77)

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

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à người đánh giá trong toàn bộ quá tình đánh giá. Vì lý do này, cũng có thể viết một ST đảm bảo mức thấp.

ISO/IEC 15408 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.

Một ST đảm bảo thấp có giảm đáng kể nội dung so với một ST thông thường: • 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;

2) Mô tả 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 SFRs và SARs (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ể. ISO/IEC 15408 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ó).

Nếu, chẳng hạn, tồn tại một tiêu chuẩn chính phủ quy đinh mật khẩu phải được chọn ra sao, điều này có thể được phát biểu như một chính sách an toàn về tổ chức trong một ST. Điều này có thể một đối tuợng cho môi trường (ví dụ nếu người sử dụng TOE cần chọn các mật khẩu phù hợp), hoặc nó có thể dẫn đến các mục tiêu an toàn cho TOE và tiếp đó cho các SFRs thích hợp (giống như ở lớp FIA), nếu như TOE tạo ra các mật khẩu. Trong cả hai trường hợp, sở cứ mà nhà phát triển cần đưa ra hợp lý là các mục tiêu an toàn cho TOE và các SFRs là phù hợp để đáp ứng OSP. Người đánh giá sẽ kiểm tra nếu điều này thực tế là hợp lý (và có thể quyết định tra cứu tiêu chuẩn cho việc này), nếu OSP được thực thi bởi các SFRs như được giải thích dưới đây.

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 SFRs 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 SFRs: 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 SFRs đượ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ư SFRs hoặc các tài liệu chuyển giao cho ADV. Như vậy, người đánh giá 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

(Quy chuẩn)

Đặ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

Mục tiêu của Phụ lục này là giải thích các khái niệm Hồ sơ Bảo vệ (PP). Phụ lục này không định nghĩa các tiêu chí APE, định nghĩa này có thể được tìm thấy trong ISO/IEC 15408-3.

Vì PP và ST có một chồng chéo lên nhau đáng kể, 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à ISO/IEC 15408-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;

b) Một tuyên bố tuân thủ, chỉ ra PP có tuân thủ với bất kỳ các PPs và /hoặc các gói hay không, và nếu có, thì với các PPs và /hoặc các gói nào.

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 ISO/IEC 15408-2 hoặc ISO/IEC 15408-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 dịch sang một ngôn ngữ chuẩn hóa. Ngôn ngữ chuẩn hóa này là ở dạng các SFRs. 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 điển hình là một tường trình về sự cần thiết, trong đó cộng đồng người dùng, một thực thể pháp lý, hoặc một nhóm các nhà phát triển định nghĩa ra một tập hợp chung của các nhu cầu an toàn. Một PP cung cấp cho người tiêu dùng một phương tiện tham chiếu đến tập này, và tạo điều kiện cho đánh giá tương lai theo những nhu cầu này.

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.

một đặc tả của một sản phẩm đơn lẻ: Không giống như một ST, một PP được thiết kế để mô tả một loại IT, và không phải là một sản phẩm đơn lẻ. Khi chỉ có một sản phẩm được mô tả, sử dụng một ST sẽ tốt hơn để cho mục đích này.

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 để nó có thể nói đế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ọ.

Tổng quan TOE cũng nhằm hướng đến những nhà phát triển, những người có thể sử dụng PP trong việc thiết kế TOE hoặc trong trong sản phẩm tương thích hiện có.

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 none-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 none-TOE phần cứng / phần mềm / phần sụn. Vì một hồ sơ bảo vệ không viết cho một sản phẩm cụ thể, nên trong nhiều trường hợp chỉ có

một ý tưởng chung có thể là các phần cứng / phần mềm / phần sụn có sẵn được đưa ra. Trong một số trường hợp khác, ví dụ một đặc tả yêu cầu đối với một người tiêu dùng cụ thể như vậy sẽ có thêm (nhiều) thông tin cụ thể có thể được cung cấp.

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 của hệ điều hành thẻ thông minh QuickOS;

• Cài đặt tháng 12 năm 2002 của các mạng LAN của Văn phòng Tổng Giám đốc Department of Traffic.

B.5 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ệ: báo cáo tuân thủ.

Báo cáo tuân thủ trong PP công bố 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.

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

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

B.11 Hồ sơ Bảo vệ đảm bảo thấp

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 SFRs 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

Một phần của tài liệu CÔNG NGHỆ THÔNG TIN – CÁC KỸ THUẬT AN TOÀN – CÁC TIÊU CHÍ ĐÁNH GIÁ CHO AN TOÀN CNTT – (Trang 77)

Tải bản đầy đủ (DOC)

(92 trang)
w