Tiêu chuẩn quốc gia TCVN 12210:2018 (ISO/IEC TR 19791:2010) về Công nghệ thông tin - Các kỹ thuật an toàn

Từ khóa: Số Hiệu, Tiêu đề hoặc Nội dung Văn bản.

+ Tìm kiếm nâng cao

Loại văn bản

Lĩnh vực

Cơ quan ban hành

Người ký văn bản

Ngày ban hành

Ngày hiệu lực

Ngày hết hiệu lực

Từ khóa: Tiêu đề hoặc Nội dung ngắn gọn Tin tức...

Từ khóa: Tên thành viên

Xin mời bạn đăng nhập, đăng ký để xem/thao tác với nội dung này.

TIÊU CHUẨN QUỐC GIA

TCVN 12210:2018

ISO/IEC TR 19791:2010

CÔNG NGHỆ THÔNG TIN - CÁC KỸ THUẬT AN TOÀN - ĐÁNH GIÁ AN TOÀN HỆ THỐNG VẬN HÀNH

Information technology - Security techniques - Security assessment of operational systems

Lời nói đầu

TCVN 12210:2018 hoàn toàn tương đương với tiêu chuẩn ISO/IEC TR 19791:2010.

TCVN 12210:2018 do Học viện Công nghệ Bưu chính viễn thông biên soạn, Bộ Thông tin và Truyền thông đề nghị, Tổng cục Tiêu chuẩn Đo lường chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố.

Lời giới thiệu

Tiêu chuẩn này là tài liệu hỗ trợ, định nghĩa các phần mở rộng của TCVN 8709 để cho phép đánh giá sự an toàn của các hệ thống vận hành. TCVN 8709 đưa ra những hỗ trợ để xác định các chức năng an toàn CNTT cho các sản phẩm và các hệ thống CNTT. Tuy nhiên, TCVN 8709 không đề cập đến khía cạnh hệ thống vận hành cần được xác định một cách chính xác để đánh giá hiệu quả hệ thống vận hành.

Tiêu chuẩn này cung cấp những hướng dẫn và tiêu chí đánh giá mở rộng để đánh giá cả khía cạnh vận hành và công nghệ thông tin của các hệ thống vận hành. Tiêu chuẩn chủ yếu hỗ trợ những người có liên quan đến sự phát triển, tích hợp, triển khai và quản lý an toàn của hệ thống vận hành cũng như những người đánh giá mong muốn áp dụng chuẩn TCVN 8709 cho các hệ thống này. Tiêu chuẩn này có liên quan đến những cơ quan đánh giá có trách nhiệm phê duyệt và xác nhận hành động đánh giá.

Có một số vấn đề cơ bản liên quan đến định nghĩa và việc sử dụng thuật ngữ hệ thống. TCVN 8709 tập trung vào việc đánh giá sản phẩm nên sử dụng thuật ngữ hệ thống là chỉ bao gồm các khía cạnh công nghệ thông tin (CNTT) của hệ thống. Thuật ngữ Hệ thống vận hành được sử dụng trong tiêu chuẩn này bao gồm kết hợp cả về nhân sự, các thủ tục và các quy trình tích hợp có các chức năng và các cơ chế dựa trên công nghệ, được áp dụng cùng nhau để thiết lập một mức rủi ro còn tồn tại có thể chấp nhận được trong một môi trường hoạt động được xác định.

Tiêu chuẩn này tương thích với TCVN 8709.

CÔNG NGHỆ THÔNG TIN - CÁC KỸ THUẬT AN TOÀN - ĐÁNH GIÁ AN TOÀN CHO HỆ THỐNG VẬN HÀNH

Information technology - Security techniques - Security assessment of operational systems

1 Phạm vi áp dụng

Tiêu chuẩn này cung cấp những hướng dẫn và tiêu chí đánh giá an toàn cho các hệ thống vận hành. Tiêu chuẩn này mở rộng phạm vi của TCVN 8709 bằng cách đưa ra một số khía cạnh quan trọng đối với hệ thống vận hành mà không được đề cập khi đánh giá theo TCVN 8709. Những mở rộng chủ yếu được yêu cầu để đánh giá môi trường vận hành xung quanh đích đánh giá và phân tách các hệ thống vận hành phức tạp thành các miền an toàn mà có thể được đánh giá một cách riêng biệt.

Tiêu chuẩn này cung cấp:

a) Định nghĩa và mô hình đối với các hệ thống vận hành.

b) Mô tả những mở rộng về các khái niệm đánh giá theo TCVN 8709 để đánh giá các hệ thống vận hành.

c) Hệ phương pháp luận để đánh giá và quy trình thực hiện đánh giá an toàn cho các hệ thống vận hành.

d) Tiêu chí đánh giá an toàn bổ sung để giải quyết những khía cạnh của hệ thống vận hành mà không được trình bày trong TCVN 8709.

Tiêu chuẩn này cho phép kết hợp các sản phẩm an toàn được đánh giá dựa theo TCVN 8709 với các hệ thống vận hành được đánh giá trong tiêu chuẩn này.

Tiêu chuẩn này chỉ giới hạn việc đánh giá an toàn cho các hệ thống vận hành và không đưa ra đánh giá an toàn cho các hệ thống khác. Tiêu chuẩn này không đưa ra những kỹ thuật về định danh, đánh giá và chấp nhận rủi ro trong vận hành.

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

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

TCVN 8709-1:2011, "Công nghệ thông tin - Các kỹ thuật an toàn - Các tiêu chí đánh giá an toàn CNTT - Phần 1: Giới thiệu và mô hình tổng quát".

TCVN 8709-2:2011, "Công nghệ thông tin - Các kỹ thuật an toàn - Các tiêu chí đánh giá an toàn CNTT - Phần 2: Các thành phần chức năng an toàn".

TCVN 8709-3:2011, "Công nghệ thông tin - Các kỹ thuật an toàn - Các tiêu chí đánh giá an toàn CNTT - Phần 3: Các thành phần đảm bảo an toàn".

TCVN 11386:2016, "Công nghệ thông tin - Các kỹ thuật an toàn - Phương pháp đánh giá an toàn CNTT".

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

Tiêu chuẩn này áp dụng các thuật ngữ sau và định nghĩa nêu trong TCVN 8709-1:2011 và TCVN 11386:2016.

3.1

Thành phần (component)

Phần riêng biệt và có thể định danh của hệ thống mà thực hiện một phần chức năng của hệ thống đó.

3.2

Hệ thống vận hành bên ngoài (external operational system)

Hệ thống vận hành riêng biệt mà các giao diện với hệ thống vận hành là đối tượng đánh giá.

3.3

Biện pháp kiểm soát quản lý (management controls)

Những biện pháp kiểm soát an toàn (ví dụ: các biện pháp bảo vệ và các biện pháp đối phó) đối với một hệ thống thông tin tập trung vào quản lý rủi ro và quản lý an toàn cho hệ thống thông tin.

[NIST SP 800-53]

3.4

Biện pháp kiểm soát vận hành (operational controls)

Những biện pháp kiểm soát an toàn (ví dụ, các biện pháp bảo vệ và các biện pháp đối phó) đối với một hệ thống thông tin chủ yếu được thực hiện bởi con người (trái với các hệ thống).

[NIST SP 800-53]

3.5

Hệ thống vận hành (operational system)

Hệ thống thông tin bao gồm cả các khía cạnh phi công nghệ thông tin, được xét trong ngữ cảnh của môi trường vận hành của nó.

3.6

Rủi ro còn tồn tại (residual risk)

Rủi ro còn lại sau khi đã xử lý rủi ro.

[TCVN 9788:2013]

3.7

Rủi ro (risk)

Khả năng mà một mối đe dọa sẽ khai thác các điểm yếu của một tài sản hoặc của một nhóm tài sản và do đó sẽ gây nguy hại cho tổ chức.

CHÚ THÍCH Định nghĩa này tương tự với định nghĩa "rủi ro an toàn thông tin" trong TCVN 10295:2014.

3.6

Phân tích rủi ro (risk analysis)

Sử dụng thông tin có hệ thống để nhận dạng các nguồn rủi ro về đánh giá rủi ro.

[TCVN 9788:2013]

3.9

Đánh giá rủi ro (risk assessment)

Toàn bộ quá trình phân tích và đánh giá rủi ro.

[TCVN 9788:2013]

3.10

Quản lý rủi ro (risk management)

Các hoạt động phối hợp để quản lý và kiểm soát tổ chức có liên quan đến rủi ro.

[TCVN 9788:2013]

3.11

Xử lý rủi ro (risk treatment)

Quá trình lựa chọn và thực thi các lựa chọn để giảm thiểu rủi ro.

[TCVN 9788:2013]

3.12

Biện pháp kiểm soát an toàn (security controls)

Các quy tắc quản lý, các biện pháp kiểm soát vận hành và các biện pháp kiểm soát kỹ thuật (ví dụ: các biện pháp bảo vệ hoặc các biện pháp đối phó) quy định đối với một hệ thống thông tin để bảo vệ tính mật, tính toàn vẹn và tính sẵn sàng của hệ thống và thông tin của nó.

[NIST SP 800-53]

CHÚ THÍCH Định nghĩa này bao gồm các biện pháp kiểm soát mà cung cấp trách nhiệm, tính xác thực thực, không từ chối, riêng tư và mức độ tin cậy, mà đôi khi được coi là khác biệt với tính mật, tính toàn vẹn và tính sẵn sàng.

3.13

Miền an toàn (security domain)

Phần của hệ thống vận hành mà thực hiện cùng một tập hợp các chính sách an toàn thông tin

3.14

Phân hệ (subsystem)

Một hoặc nhiều phần tử hệ thống vận hành có khả năng thực hiện tách biệt với phần còn lại của hệ thống.

3.15 Đích đánh giá hệ thống (system target of evaluation)

Hệ thống vận hành được vận hành theo hướng dẫn vận hành của nó, bao gồm cả kiểm soát kỹ thuật và kiểm soát vận hành.

CHÚ THÍCH Những biện pháp kiểm soát vận hành tạo thành một phần của môi trường vận hành. Nó không được đánh giá theo chuẩn đánh giá TCVN 8709.

3.16

Kiểm soát kỹ thuật (technical controls)

Những biện pháp kiểm soát an toàn (ví dụ, các biện pháp bảo vệ và các biện pháp đối phó) đối với một hệ thống thông tin được thực hiện chủ yếu bởi các hệ thống thông tin thông qua các cơ chế có trong các thành phần cứng, phần mềm, phần sụn của hệ thống.

[NIST SP 800-53]

3.17

Xác minh (verification)

Các qui trình đánh giá được sử dụng để xác nhận rằng những biện pháp kiểm soát an toàn đối với hệ thống vận hành được thực hiện một cách chính xác và có hiệu quả theo ứng dụng của nó.

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

Chữ viết tắt dưới đây và được đưa ra trong TCVN 8709-1:2011 và TCVN 11386:2016 được áp dụng cho mục đích của tài liệu tiêu chuẩn này;

CNTT	Information Technology (IT)	Công nghệ thông tin (CNTT)
COTS	Commercial Off The Shelf	Sản phẩm thương mại có sẵn
OSF	Operational Security Functionality	Chức năng an toàn vận hành
SP	Special Publication	Ấn phẩm đặc biệt
SPP	System Protection Profile	Hồ sơ bảo vệ hệ thống
SSA	System Security Assurance	Đảm bảo an toàn hệ thống
SSF	System Security Functionality	Chức năng an toàn hệ thống
SST	System Security Target	Đích an toàn hệ thống
STOE	System Target of Evaluation	Đích đánh giá hệ thống

5 Cấu trúc của tiêu chuẩn

Từ điều 1 đến điều 4 giới thiệu về tiêu chuẩn, các tài liệu viện dẫn và các thuật ngữ, định nghĩa được sử dụng trong tiêu chuẩn này.

Điều 5 trình bày tổng quan các nội dung của tiêu chuẩn.

Điều 6, Phương pháp tiếp cận kỹ thuật, mô tả các phương pháp kỹ thuật đánh giá hệ thống vận hành.

Điều 7, Mở rộng các khái niệm đánh giá của tiêu chuẩn TCVN 8709 cho các hệ thống vận hành, mô tả cách mở rộng các khái niệm đánh giá của TCVN 8709 để đánh giá hệ thống vận hành.

Điều 8, Mối quan hệ với các tiêu chuẩn an toàn thông tin hiện có, mô tả mối quan hệ giữa tiêu chuẩn này và các tiêu chuẩn an toàn thông tin khác được sử dụng trong quá trình phát triển.

Điều 9, Đánh giá các hệ thống vận hành, bao gồm các yêu cầu về đặc tả các vấn đề an toàn, mục tiêu an toàn, các yêu cầu về an toàn, các nội dung của một SST và đánh giá lại SST theo định kỳ để đánh giá hệ thống vận hành.

Phụ lục A, Đích an toàn và hồ sơ bảo vệ hệ thống vận hành, định nghĩa những đặc tả yêu cầu an toàn cần thiết cho các hệ thống vận hành.

Phụ lục B, Những yêu cầu về kiểm soát chức năng hệ thống vận hành, định nghĩa các yêu cầu chức năng an toàn bổ sung cần thiết cho các hệ thống vận hành.

6 Phương pháp tiếp cận kỹ thuật

6.1 Bản chất của hệ thống vận hành

Trong tiêu chuẩn này, hệ thống vận hành được định nghĩa là một hệ thống thông tin bao gồm cả khía cạnh phi CNTT, nó được xét trong bối cảnh môi trường vận hành của nó.

Rất nhiều hệ thống vận hành có bản chất phức tạp, nó được tạo thành do kết hợp nhiều phân hệ mà một phần thuộc quyền sở hữu riêng và khác thường về bản chất, một phần được tạo ra do sử dụng những sản phẩm chung được tích hợp sẵn. Chúng tương tác với các hệ thống khác và phụ thuộc vào những hệ thống khác. Một hệ thống vận hành thường được dựng nên bằng cách sử dụng nhiều thành phần của nhiều nhà cung cấp. Những thành phần này có thể được người tích hợp để tạo thành hệ thống vận hành mà không cần thực hiện bất kỳ chức năng phát triển nào, chỉ là cấu hình và liên kết các thành phần với nhau.

Tuy nhiên, những hệ thống vận hành tiêu biểu thường:

- Nằm dưới sự kiểm soát của một thực thể duy nhất, đó là chủ sở hữu hệ thống vận hành;

- Được xây dựng dựa trên những nhu cầu cụ thể cho một loại hình hoạt động cụ thể;

- Thay đổi thường xuyên; hoặc về thiết lập kỹ thuật và/hoặc về những yêu cầu vận hành;

- Chứa một số tượng đáng kể (hoặc thậm chí rất lớn) những thành phần;

- Có chứa những thành phần được tích hợp sẵn mà có một số lượng lớn những thay thế cấu hình;

- Cho phép chủ sở hữu hệ thống vận hành cân bằng những biện pháp an toàn kỹ thuật (và đặc biệt là CNTT) và những biện pháp an toàn phi kỹ thuật;

- Chứa những thành phần có những mức độ và những kiểu đảm bảo đảm an toàn khác nhau.

6.2 Thiết lập an toàn hệ thống vận hành

Những sản phẩm an toàn thường góp phần quan trọng đối với an toàn hệ thống vận hành, thực tế việc sử dụng những sản phẩm được đánh giá theo TCVN 8709 có thể thích hợp trong việc xây dựng một hệ thống vận hành an toàn. Tuy nhiên, vấn đề an toàn trong những hệ thống vận hành không chỉ là vấn đề liên quan đến sản phẩm mà còn là vấn đề liên quan đến hệ thống vận hành trong một môi trường vận hành có thực, chẳng hạn như ứng dụng bản sửa lỗi kém, việc thiết lập những thông số kiểm soát truy cập kém hoặc những quy tắc bảo vệ của bức tường lửa kém, việc liên kết những tập tin thư mục kém, vv... Hơn nữa, đối với trường hợp của một mạng lưới, mức độ an toàn của một hệ thống vận hành được nối mạng có thể liên quan đến những hệ thống vận hành khác mà phải kết nối với nó.

Tiêu chuẩn này được dựa trên phương pháp tiếp cận ba bước để thiết lập mức an toàn cần thiết cho một hệ thống vận hành:

a) Đánh giá rủi ro, để xác định nhũng rủi ro về an toàn đối với một hệ thống;

b) Giảm thiểu rủi ro, để chống lại hoặc loại bỏ những rủi ro về an toàn bằng cách lựa chọn, áp dụng và đánh giá những biện pháp kiểm soát an toàn;

c) Công nhận, để xác nhận rằng những rủi ro còn tồn tại trong hệ thống sau khi đã áp dụng những biện pháp kiểm soát sẽ phù hợp với hệ thống được sử dụng trong môi trường vận hành của nó.

Quá trình ba bước này được thể hiện trong Hình 1 dưới đây:

Hình 1 - Quy trình thiết lập an toàn hệ thống vận hành

Tiêu chuẩn này chỉ xét đến bước giữa của quá trình ba bước, đó là giảm thiểu rủi ro thông qua việc lựa chọn, áp dụng và đánh giá những biện pháp kiểm soát an toàn. Để làm điều này, phải sử dụng một phương pháp đánh giá an toàn dựa trên mô hình đánh giá an toàn đối với những biện pháp kiểm soát an toàn CNTT được định nghĩa trong TCVN 8709 nhưng phải được mở rộng để giải quyết được tất cả những loại kiểm soát an toàn.

Những biện pháp kỹ thuật và phương pháp đánh giá rủi ro không thuộc phạm vi của tiêu chuẩn này. Để biết thêm thông tin về đánh giá rủi ro, xem TCVN 10295:2014 [1]. Những biện pháp kỹ thuật và những mô hình công nhận trở thành trách nhiệm quản lý cũng không thuộc phạm vi của tiêu chuẩn này. Để biết thêm thông tin, xem NIST SP 800-37 [2].

Mô hình đánh giá an toàn của TCVN 8709 không xét đến môi trường vận hành xung quanh phần CNTT của hệ thống thông tin. Môi trường vận hành được coi là giả định khi đánh giá theo TCVN 8709. nhưng không thể coi nhẹ đối với hệ thống vận hành. Thông thường, những hệ thống vận hành phụ thuộc vào những biện pháp an toàn phi CNTT, ví dụ như những biện pháp mang tính chất hành chính hoặc vật lý. Do đó, cần phải xác định cách để diễn tả và đánh giá những yêu cầu và những biện pháp kiểm soát này, bằng việc mở rộng tiêu chí đánh giá theo TCVN 8709. Tiêu chuẩn này mở rộng TCVN 8709 để thực hiện điều này. Những mở rộng không bị giới hạn, bao gồm:

a) Xác định vị trí đánh giá an toàn trong hệ phương pháp luận để đánh giá an toàn hệ thống vận hành kể cả môi trường vận hành của chúng.

b) Phương pháp luận để xác định cấu trúc bên trong của hệ thống vận hành, bao gồm chi tiết về những giao diện bên trong và những giao diện bên ngoài để hiểu được cách thức những phần khác nhau của hệ thống vận hành hoạt động tương tác với nhau.

c) Danh mục những tiêu chí đảm bảo diễn tả những mở rộng về phạm vi đánh giá (xem Phụ lục A).

d) Danh mục những tiêu chí chức năng diễn tả những biện pháp kiểm soát an toàn vận hành bổ sung (xem Phụ lục B).

e) Danh mục những tiêu chí đảm bảo diễn tả những nhiệm vụ đánh giá bổ sung cần thiết để đánh giá các hệ thống vận hành (xem Phụ lục C).

f) Danh mục những hoạt động đánh giá diễn tả những hoạt động bổ sung cần thiết để đánh giá các hệ thống vận hành (xem Phụ lục D).

Mở rộng cách tiếp cận TCVN 8709 đánh giá những hệ thống vận hành hoàn chỉnh mang lại lợi ích trong việc sử dụng phép đo đã được định nghĩa để biết kết quả đánh giá. Đối với một hệ thống vận hành cụ thể thì việc công khai kết quả đánh giá theo cách mà có thể tương thích với TCVN 8709 có thể mang lại lợi thế nghiệp vụ cho khách hàng, không chỉ đối với những hệ thống cung cấp dịch vụ như hệ thống ngân hàng trực tuyến, mà còn từ quan điểm trách nhiệm xã hội.

Đánh giá hệ thống vận hành cần phải có một đánh giá rủi ro trước đó để nhận biết được những rủi ro an toàn đối với một hệ thống vận hành, và xác định được những rủi ro không thể chấp nhận được và phải được giảm bớt hoặc loại bỏ thông qua những biện pháp kiểm soát kỹ thuật và những biện pháp kiểm soát vận hành. Tiếp đến, phải bao gồm những bước sau:

a) Thiết lập những mục tiêu an toàn cho hệ thống vận hành sẽ giảm bớt những rủi ro không thể chấp nhận đến một mức có thể chấp nhận được

b) Lựa chọn và xác định những biện pháp kiểm soát an toàn kỹ thuật và kiểm soát vận hành đáp ứng được những mục tiêu an toàn đối với hệ thống vận hành, có tính đến những biện pháp kiểm soát để tồn tại.

c) Xác định những yêu cầu đảm bảo cụ thể, hợp lý cho cả kiểm soát kỹ thuật và kiểm soát vận hành để có được mức độ tin cậy cần thiết để hệ thống vận hành đáp ứng được những mục tiêu an toàn của nó.

d) Ghi lại những quyết định được thực hiện trong đích an toàn hệ thống (SST).

e) Đánh giá hệ thống vận hành thực tế để thấy được việc tuân thủ với SST.

f) Định kỳ đánh giá lại những rủi ro về an toàn đối với hệ thống vận hành và khả năng đối phó của hệ thống vận hành đối với những rủi ro đó.

Mặc dù mô hình này là mở rộng của mô hình được trình bày trong TCVN 8709, nhưng nó có sự nhất quán với mô hình đó vì thế những kết quả đánh giá theo TCVN 8709 có thể tái sử dụng được.

6.3 An toàn đối với vòng đời của hệ thống vận hành

6.3.1 Tổng quan

Vòng đời của một hệ thống vận hành gồm 4 giai đoạn, đó là giai đoạn phát triển/tích hợp, giai đoạn cài đặt, giai đoạn hoạt động của hệ thống và giai đoạn sửa đổi. Những biện pháp kiểm soát an toàn hệ thống vận hành phải được đánh giá trong suốt vòng đời của hệ thống. Những giai đoạn này được trình bày ở Hình 2 dưới đây.

Hình 2 - An toàn đối với vòng đời của hệ thống vận hành

6.3.2 Giai đoạn phát triển/ tích hợp

Trong giai đoạn phát triển/tích hợp, hoạt động đảm bảo an toàn đầu tiên là xác định những rủi ro đối với hệ thống vận hành. Những rủi ro này là những rủi ro không thể chấp nhận và phải được giảm bớt hoặc loại bỏ bằng những bài đo an toàn được tạo sẵn trong hệ thống. Sau khi đánh giá rủi ro và xác định được những rủi ro đã được loại bỏ, nhân viên có thẩm quyền của tổ chức, tổ chức chứng nhận phải xem xét những rủi ro còn tồn tại dự kiến, tổng những rủi ro còn tồn tại, và xác nhận rằng chúng có thể chấp nhận được không.

Tiếp đến là thiết kế hệ thống vận hành, bao gồm việc sử dụng sản phẩm phần cứng và phần mềm, tài sản vật lý quy định, những chương trình ứng dụng nghiệp vụ cần thiết và những biện pháp kiểm soát an toàn kỹ thuật quy định. Việc thiết kế hệ thống vận hành phải được ghi vào SST. SST sẽ bao gồm phần mô tả những yêu cầu an toàn hệ thống, kể cả rủi ro đã được đối phó và những mục tiêu an toàn đã được thực hiện bằng những biện pháp kiểm soát kỹ thuật và những biện pháp kiểm soát vận hành. Danh mục những biện pháp kiểm soát kỹ thuật và kiểm soát vận hành được ghi trong SST sẽ đại diện cho một bản thuyết minh những mục tiêu an toàn hệ thống.

Các mục tiêu an toàn cần được quy định trong SST để giải quyết những rủi ro được xác định là những rủi ro không thể chấp nhận. SST sẽ xác định những yêu cầu an toàn mà hoàn toàn đáp ứng được những mục tiêu an toàn mà không có bất kỳ bổ sung hoặc thiếu sót nào. Tài liệu thiết kế hệ thống vận hành cần quy định những biện pháp đối phó an toàn rõ ràng đối với hệ thống vận hành mà đáp ứng tất cả những yêu cầu an toàn đã quy định trong SST. Những biện pháp đối phó có thể là những chức năng an toàn, những phương tiện, những thủ tục hoặc những quy định về an toàn. Những biện pháp đối phó phải được kiểm soát, quản lý và được áp dụng một cách thích hợp đối với hệ thống vận hành. Những biện pháp đối phó an toàn được thực hiện mà không cần sửa đổi, loại bỏ hoặc trái bổ sung trái phép nào. Việc thực hiện những biện pháp đối phó phải được xác minh bằng việc kiểm thử hệ thống hoặc kiểm tra tài liệu. Hoạt động của những biện pháp đối phó an toàn cần phải được mô tả đầy đủ trong những tài liệu hướng dẫn.

Để đạt được hiệu quả, các yêu cầu an toàn đã được lựa chọn sẽ giảm bớt tất cả những rủi ro về an toàn được xác định là không thể chấp nhận được đến mức có thể chấp nhận như những rủi ro còn tồn tại. Mỗi biện pháp đối phó an toàn phải hoạt động hiệu quả khi kết hợp với biện pháp đối phó khác để đáp ứng toàn bộ những yêu cầu an toàn cho hệ thống vận hành. Độ mạnh của những cơ chế an toàn phải đủ để phù hợp với khả năng tấn công dự kiến. Việc khảo sát hoặc phân tích những điểm yếu và việc kiểm thử thâm nhập có thể được yêu cầu với khả năng tấn công dự kiến.

Người đánh giá cần phải tham gia vào giai đoạn phát triển/tích hợp, đây là giai đoạn đầu trong vòng đời của hệ thống để thuận tiện cho việc nắm bắt hệ thống và môi trường dự định của nó, cũng như để chuẩn bị đầu vào từ xem xét những tài liệu thiết kế và để chuẩn bị hướng dẫn đánh giá và tài liệu hướng dẫn được sử dụng như một phần của bằng chứng đảm bảo. Lý tưởng là SST đầy đủ phải được đánh giá sơ bộ để xác nhận rằng không có những bất đồng hoặc thiếu sót trong những yêu cầu an toàn và những biện pháp kiểm soát đã đề xuất.

Những ứng dụng nghiệp vụ và phần mềm hệ thống, bao gồm cả kiểm soát an toàn kỹ thuật được tạo ra hoặc được mua, hệ thống sẽ được tích hợp, được cấu hình, và được kiểm thử bởi những người phát triển. Đồng thời, phải lập ra một tổ chức về an toàn vận hành, phải đưa ra các thủ tục, quy tắc và chính sách về an toàn và tích hợp chúng với hệ thống. Những thiết lập cấu hình an toàn thích hợp phải được xác định và thực hiện.

Tiếp theo là kiểm thử việc tích hợp, hệ thống vận hành nên được kiểm thử an toàn như phần kiểm thử xác minh những yêu cầu của nhà phát triển. Thông thường, những biện pháp kiểm soát an toàn hệ thống như kiểm soát truy cập có thể được người phát triển xác minh trước khi phát triển tại vị trí hoạt động. Việc kiểm thử những biện pháp kiểm soát an toàn (cả kiểm soát an toàn kỹ thuật và kiểm soát an toàn vận hành) sẽ bị hoãn lại cho đến khi hệ thống được cài đặt xong trong môi trường vận hành dự định của nó. Việc kiểm thử xác minh sẽ xác nhận độ mạnh của cơ chế bảo mật cũng như những hoạt động chính xác của những biện pháp kiểm soát an toàn.

Cuối cùng là đánh giá hệ thống vận hành. Việc đánh giá sẽ xác nhận những rủi ro đã được trình bày chi tiết trong SST phải được đối phó bằng những biện pháp kiểm soát an toàn được hệ thống giải quyết ở mức có thể chấp nhận được. Kết quả của việc đánh giá là xác nhận tính độc lập với chủ sở hữu hệ thống.

Báo cáo chứng nhận sẽ liệt kê bất kỳ điểm yếu nào được tìm thấy trong khi đánh giá và sẽ xác định bất kỳ những hành động nào được khuyến nghị. Sau đó, chủ sở hữu hệ thống sẽ chuẩn bị một kế hoạch hành động khắc phục để giảm bớt hoặc loại bỏ những điểm yếu đã được xác định. Kết quả của việc xác nhận hệ thống sẽ được gửi đến tổ chức chứng nhận để xác định rằng rủi ro còn tồn tại thực tế đối với những hoạt động và tài sản hệ thống là có thể chấp nhận được. Đầu ra của giai đoạn này sẽ là cấp quyền cho hệ thống vận hành.

6.3.3 Giai đoạn cài đặt

Trong giai đoạn cài đặt, phải chuẩn bị và thực hiện những biện pháp kiểm soát kỹ thuật và kiểm soát vận hành để sử dụng trong môi trường vận hành. Những biện pháp kiểm soát cụ thể sẽ được kiểm thử và những biện pháp kiểm soát khác sẽ được kiểm thử lại để xác nhận rằng chúng được thực hiện một cách chính xác trong môi trường vận hành thực tế.

Những biện pháp kiểm soát phải phù hợp với những yêu cầu an toàn được ghi trong SST và chỉ những người thành thạo mới được phép sử dụng. Để có hiệu quả, tất cả mọi người sẽ được đào tạo sử dụng những thủ tục và những biện pháp kiểm soát an toàn.

6.3.4 Giai đoạn hoạt động của hệ thống

Trong giai đoạn hoạt động của hệ thống, phải được thu thập và đánh giá các bản ghi hoạt động của những biện pháp kiểm soát kỹ thuật và kiểm soát vận hành. Những lần vết đánh giá và bản ghi giám sát tất cả những truy cập đến tài sản phải được ghi lại.

Các biện pháp đối phó an toàn cần phải được xác nhận là có hoạt động như dự định. Không có những hoạt động không được cấp phép và không được xuất hiện những rủi ro không thể chấp nhận. Trạng thái an toàn cần được phục hồi từ trạng thái không an toàn trong thời gian quy định. Những thay đổi do bảo dưỡng định kỳ phải được theo dõi và được đánh giá về những vấn đề an toàn. Hồ sơ truy cập và việc sử dụng tài sản cần được kiểm tra. Các vấn đề an toàn cần được báo cáo, xem xét và phân tích.

Mục đích của những hoạt động này là để cung cấp thông tin phản hồi đến tổ chức chứng nhận khi có những thay đổi mà có thể ảnh hưởng đến an toàn hệ thống vận hành. Thông thường, trong các hệ thống vận hành, một tập nhỏ những biện pháp kiểm soát an toàn hệ thống vận hành cần phải được xác định để giám sát thường xuyên để xác định hiệu quả của chúng. Ngoài ra, chủ sở hữu hệ thống phải có sẵn một cấu hình quản lý, cấu hình kiểm soát và hệ thống báo cáo để ghi vào tài liệu những tài sản hệ thống vận hành hiện tại, cấu hình của nó, và trình bày thông tin đó cho các tổ chức chịu trách nhiệm.

6.3.5 Giai đoạn sửa đổi

Trong giai đoạn sửa đổi hệ thống, bất kỳ thay đổi nào về hệ thống vận hành dự định hoặc hệ thống vận hành thực tế không thuộc phạm vi bảo dưỡng định kỳ sẽ được xem xét, phân tích, và nếu cần thiết, sẽ được kiểm thử để xác định tác động của nó đối với sự an toàn hệ thống vận hành trước khi được thực hiện trong môi trường hoạt động trực tiếp. Việc này bao gồm những thay đổi về thủ tục và chính sách. Thực hiện kiểm thử quá trình thâm nhập của những biện pháp kiểm soát đã được hiệu chỉnh để kiểm tra hiệu quả hoạt động của nó.

Kết quả của những phân tích tác động và kiểm thử phải được gửi đến tổ chức chứng nhận để xác định sự cần thiết phải đánh giá lại sự an toàn. Nếu những hiệu chỉnh cho thấy là không làm tăng đáng kể những rủi ro còn tồn tại có thể vì chúng đã được đánh giá theo qui trình bảo trì đảm bảo sản phẩm thì có thể được tái cấp phép mà không cần đánh giá lại. Tuy nhiên, nếu kết quả đánh giá đã hết hiệu lực thì phải yêu cầu đánh giá lại.

Hành động cuối cùng của việc sửa đổi hệ thống là ngừng hoạt động nếu hệ thống bị đóng lại và dữ liệu của nó bị nén, bị phá hủy hoặc bị chuyển sang hệ thống khác. Tổ chức chứng nhận sẽ được yêu cầu xác nhận xem hệ thống có được kết thúc thành công không.

6.4 Mối quan hệ với những hệ thống khác

Một hệ thống vận hành có thể tương tác với những hệ thống khác có liên quan và có thể tạo thành một phần tổng thể thống lớn hơn. Những STOE của hệ thống vận hành đã đánh giá được định nghĩa là một phần của một nhóm những hệ thống được đánh giá, bao gồm cả hệ thống CNTT và môi trường vận hành của nó. Phần còn lại được coi là các hệ thống vận hành bên ngoài. Một hệ thống vận hành có thể có những mục tiêu an toàn mà đáp ứng bởi những hệ thống vận hành bên ngoài, nhưng những hệ thống này không được phân tích hay đánh giá.

7 Mở rộng các khái niệm đánh giá của TCVN 8709 đối với các hệ thống vận hành

7.1 Tổng quan

Mục đích của mục này là đưa ra triết lý làm cơ sở tiếp cận chuẩn TCVN 8709 về đánh giá an toàn và sau đó mở rộng đối với các hệ thống vận hành. TCVN 8709 chỉ đề cập đến những biện pháp kiểm soát kỹ thuật và kiểm soát quản lý liên quan; trong các hệ thống vận hành, những biện pháp kiểm soát kỹ thuật và kiểm soát vận hành kết hợp với nhau để bảo vệ thông tin và các tài sản khác của tổ chức.

7.2 Triết lý chung

Đối với nhiều tổ chức, thông tin là tài sản quan trọng và cần phải bảo vệ chúng khỏi các mối đe dọa về việc sửa đổi, phát hành trái phép hoặc phá hủy. Các tài sản này được bảo vệ bằng cách sử dụng kết hợp những biện pháp kiểm soát an toàn cùng với sự hỗ trợ về nhân sự, chính sách và các thủ tục kiểm soát vận hành và biện pháp bảo vệ vật lý. Triết lý tổng quan của TCVN 8709 là những mối đe dọa đến tài sản của tổ chức cần được trình bày rõ ràng và những mối đe dọa này phải được chống lại bằng cách sử dụng kết hợp kiểm soát kỹ thuật và cơ sở hạ tầng kiểm soát vận hành. Những yêu cầu kiểm soát kỹ thuật để giải quyết các mối đe dọa được trình bày trong TCVN 8709-2. Theo TCVN 8709, các yêu cầu về kiểm soát vận hành được xem xét riêng là một phần của quá trình công nhận và do đó tiêu chuẩn TCVN 8709 không trực tiếp đưa ra việc đánh giá an toàn cho hệ thống vận hành. Tài liệu này tìm kiếm những yêu cầu đó để chính thức hóa chúng để chúng có thể được đánh giá như một phần đánh giá hệ thống vận hành.

TCVN 8709 phân chia các biện pháp an toàn thành các dịch vụ an toàn có liên quan được cung cấp và các biện pháp thực hiện để đảm bảo rằng những biện pháp đó được thực hiện một cách chính xác và hiệu quả. Trong đánh giá sản phẩm, các dịch vụ an toàn có liên quan có những chức năng về CNTT được thực hiện để đáp ứng các mục tiêu đối với phần công nghệ. Trong ngữ cảnh hệ thống vận hành, những đóng góp về mặt vật lý và về mặt thủ tục an toàn cũng có thể được xét đến. Chúng tương tự chức năng CNTT bởi vì chúng có những khả năng an toàn của hệ thống vận hành mà cùng đáp ứng các mục tiêu an toàn. Tuy nhiên, chúng thường không dựa trên công nghệ và chúng phù hợp để đánh giá trong phần kiểm soát vận hành vòng đời hệ thống vận hành hơn là trong phần phát triển hệ thống vận hành. Vì vậy, chúng được coi là khác so với yêu cầu chức năng.

Trong TCVN 8709, những biện pháp được thực hiện để đảm bảo rằng những khả năng an toàn thực hiện như mong đợi được định nghĩa là "bảo đảm" và bao gồm các bằng chứng được tạo ra và đánh giá độc lập sự phù hợp của những khả năng an toàn đó. Thuật ngữ này có thể được mở rộng bao gồm cả phần những biện pháp kiểm soát vận hành của hệ thống vận hành xuyên suốt tài liệu để mô tả những biện pháp kiểm soát vận hành đã thực hiện.

Qui trình được sử dụng để phát triển, thực hiện và duy trì cả bản thân hệ thống vận hành và cả các dịch vụ an toàn liên quan có ảnh hưởng đáng kể đến tính chính xác và hiệu quả của các dịch vụ an toàn liên quan và sự đóng góp của nó đến an toàn hệ thống vận hành. Ảnh hưởng này cũng góp phần đảm bảo trong việc thực hiện các dịch vụ an toàn liên quan. Vì vậy, qui trình này góp phần vào việc đảm bảo tổng thể hệ thống vận hành phức tạp. Cụ thể hơn, mức đảm bảo khả năng của quá trình càng lớn thì độ tin cậy về tính chính xác và hiệu quả của các dịch vụ an toàn liên quan càng cao và do đó toàn bộ đảm bảo được cung cấp.

Tóm lại, những yêu cầu chức năng an toàn vận hành là những biện pháp kiểm soát an toàn phi kỹ thuật được thực hiện trong hệ thống vận hành góp phần vào những mục tiêu an toàn tổng thể, trong khi những yêu cầu đảm bảo an toàn vận hành phản ánh bằng chứng cho thấy những yêu cầu này được thỏa mãn.

Do đó việc đánh giá an toàn cho một hệ thống vận hành có thể được chia thành các bước sau:

a) Vấn đề an toàn được trình bày là một tập hợp những rủi ro được giảm thiểu hoặc được giảm nhẹ và một tập hợp các chính sách an toàn của tổ chức được thi hành. Điều này đòi hỏi phải có sự phân tích trước khi xác định mục đích của hệ thống vận hành và đòi hỏi phải đánh giá rủi ro để xác định những rủi ro mà sẽ được chống lại bằng những biện pháp kiểm soát kỹ thuật và kiểm soát vận hành. Các kết quả phân tích được ghi lại trong SST.

b) Vấn đề an toàn được phân chia thành giải pháp an toàn mức cao, được đại diện bởi một tập hợp các mục tiêu an toàn. Những mục tiêu này được ghi lại trong SST.

c) Các mục tiêu an toàn được cải tiến thành các yêu cầu an toàn có thể được đánh giá bởi một người đánh giá độc lập. Một số mục tiêu an toàn sẽ được phân bổ cho những biện pháp kiểm soát kỹ thuật và một số khác cho kiểm soát vận hành. Một số mục tiêu an toàn có thể đòi hỏi phải có cả kiểm soát kỹ thuật và kiểm soát vận hành. Ví dụ, kiểm soát việc truy cập trái phép tài sản thông tin sẽ thường được thực hiện bằng cách trang bị an toàn vật lý cho tài sản (ví dụ như trang bị ổ khóa, có người bảo vệ) và cả bằng chức năng CNTT (ví dụ như cơ chế xác thực người dùng và kiểm soát truy cập). Các yêu cầu an toàn được ghi lại trong SST.

d) Một tập hợp các hoạt động giúp người đánh giá thực hiện trong quá trình đánh giá được định nghĩa dựa trên các mục tiêu tổng thể và đảm bảo tổng thể các biện pháp bảo vệ cần thiết. Những yêu cầu đảm bảo được ghi lại trong SST.

e) Người đánh giá độc lập xác định xem hệ thống vận hành có đáp ứng yêu cầu an toàn của nó dựa trên những yêu cầu ghi trong SST không.

f) Thực hiện những đánh giá liên tục để đảm bảo rằng hệ thống vận hành đáp ứng yêu cầu của nó trong quá trình vận hành. Những đánh giá này sẽ tập trung chủ yếu vào phần kiểm soát vận hành của hệ thống vận hành vì những biện pháp kiểm soát này phụ thuộc vào hành xử của con người, đó là kém nhất quán và kém kiểm soát hơn so với hành vi CNTT.

g) Định kỳ đánh giá lại hệ thống vận hành có thể đánh giá hệ thống vận hành tiếp tục đáp ứng yêu cầu của nó bất chấp những thay đổi đối với hệ thống vận hành hoặc môi trường của nó. Việc này bao gồm việc xác định những thay đổi đã diễn ra, đánh giá tác động an toàn của những thay đổi này, cập nhật SST theo quy định, xác định sự an toàn được duy trì trong suốt quá trình này.

Qui trình đánh giá an toàn này tương tự qui trình đánh giá theo TCVN 8709. Sự khác nhau cơ bản giữa đánh giá hệ thống vận hành trong tiêu chuẩn này và đánh giá sản phẩm theo TCVN 8709 là: khi đánh giá hệ thống vận hành thì môi trường vận hành thực tế được xét đến đầy đủ, trong khi đánh giá sản phẩm thì môi trường vận hành không được định nghĩa chi tiết, nó chỉ được mô tả như những giả định mà không được thẩm tra trong quá trình đánh giá

Mục tiêu chính của đánh giá hệ thống vận hành là đảm bảo các mục tiêu an toàn đối với hệ thống vận hành được thực hiện một cách chính xác và hiệu quả. Tuy nhiên, đánh giá những biện pháp kiểm soát an toàn, cho dù là về mặt kỹ thuật hay về mặt vận hành thì không bao giờ có thể có được sự đảm bảo tuyệt đối rằng những biện pháp kiểm soát này sẽ luôn luôn hoạt động như dự định, mọi lúc và trong mọi tình huống. Việc đánh giá đem đến sự phán quyết thành công hoặc thất bại. Ngay cả khi việc đánh giá xác định không có những điểm yếu không thể chấp nhận được thì vẫn sẽ luôn có một rủi ro còn tồn tại mà những biện pháp kiểm soát không thực hiện được như dự định. Rủi ro này có thể được giảm bằng cách thêm những biện pháp kiểm soát đảm bảo bổ sung hoặc sử dụng các biện pháp bảo đảm khác mà có độ tin cậy cao hơn. Rủi ro còn tồn tại của việc thực hiện không chính xác hoặc không hiệu quả những biện pháp kiểm soát chỉ có thể được xác định thông qua đánh giá và giám sát liên tục.

Rủi ro còn tồn tại này phải được tính đến khi quyết định xem liệu rằng một hệ thống vận hành có thể được công nhận về hoạt động trực tiếp không.

Yếu tố môi trường có thể dẫn đến sự khác biệt về môi trường tới hạn/đe dọa đối với các thành phần của hệ thống vận hành khác nhau. Có thể một số phần của hệ thống vận hành có thể đòi hỏi có sự đảm bảo nhiều hơn trong khi các phần khác đòi hỏi có đảm bảo ít hơn. Do đánh giá rủi ro có thể thiết lập các mức rủi ro có thể chấp nhận khác nhau cho các phần khác nhau của hệ thống vận hành, nên hệ thống vận hành có thể được chia thành các miền an toàn với các yêu cầu đảm bảo khác nhau. Đánh giá rủi ro sẽ xác định được khả năng chấp nhận rủi ro đối với các phần khác nhau của hệ thống vận hành và sẽ hỗ trợ trong việc xác định các biện pháp bảo đảm phù hợp với từng phần của hệ thống vận hành.

7.3 Đảm bảo hệ thống vận hành

Mô hình đảm bảo của TCVN 8709 tập trung vào việc cung cấp các bằng chứng cho thấy các chức năng an toàn tồn tại và được thực hiện một cách chính xác và hiệu quả. Các mức đảm bảo cao hơn đòi hỏi những yêu cầu chi tiết hơn về nội dung và kiểu bằng chứng. Ngoài ra, các mức đảm bảo cao hơn đôi khi cũng đòi hỏi phải tăng tính chính xác của việc phân tích các bằng chứng của cả người phát triển và người đánh giá.

Đánh giá sản phẩm theo TCVN 8709 được tiến hành theo cách giả định là có một môi trường vận hành chung mà trong đó các sản phẩm có thể được sử dụng. Việc đánh giá sản phẩm sẽ tập trung vào việc kiểm tra những khả năng an toàn được thực hiện bởi các sản phẩm, không phụ thuộc vào bất kỳ nội dung vận hành cụ thể nào. Việc đánh giá sản phẩm sử dụng những đặc tả, tài liệu thiết kế và kiểm thử khác nhau để chứng minh tính đúng đắn của phán quyết. Trong đánh giá sản phẩm, các yêu cầu đảm bảo không xuất phát từ vấn đề an toàn. Thay vào đó, chúng được lựa chọn một cách tự nhiên hoặc được lựa chọn theo quyết định chính sách.

Mục tiêu chính của đánh giá sản phẩm là đảm bảo khả năng an toàn của sản phẩm được thực hiện một cách chính xác. Cơ sở của tính chính xác được thiết lập bởi những yêu cầu an toàn được chứa trong đích an toàn của sản phẩm (ST). ST bao gồm một số khả năng theo dấu các vấn đề an toàn được giải quyết theo kết quả của các yêu cầu an toàn. Vấn đề an toàn được trình bày trong ST được giả định dựa trên đánh giá mối đe dọa đối với các loại môi trường thích hợp cho việc phát triển sản phẩm. Phạm vi đánh giá sản phẩm được giới hạn đối với các yêu cầu an toàn CNTT được phân bổ cho các sản phẩm theo đánh giá mối đe dọa này. Ngoài ra, đánh giá sản phẩm thiết lập biên đối với "các giá trị an toàn" cho các phần của sản phẩm có thể được cấu hình: được định nghĩa là "cấu hình đánh giá". Tuy nhiên, những cấu hình này không tính đến bất kỳ môi trường cụ thể nào không được biết đến tại thời điểm đánh giá. Sau khi hoàn thành việc đánh giá sản phẩm, nó vẫn còn cần thiết để tích hợp sản phẩm được đánh giá với các sản phẩm khác để tạo nên một hệ thống vận hành, và cuối cùng là để kiểm tra xem hệ thống vận hành có cung cấp các thuộc tính an toàn và hành xử trong môi trường vận hành và cấu hình hoạt động của nó không.

Thông thường, đánh giá sản phẩm có các biện pháp bảo đảm tương tự được áp dụng cho tất cả các chức năng an toàn được xác định. Mặc dù về mặt kỹ thuật có thể có miền an toàn khác nhau trong các sản phẩm, thường không được áp dụng để đánh giá sản phẩm chung.

Báo cáo đánh giá và bằng chứng đánh giá được tạo ra từ việc đánh giá sản phẩm có thể được sử dụng để hỗ trợ việc tích hợp hệ thống vận hành và nỗ lực kiểm thử hệ thống vận hành.

Về nguyên tắc, có rất ít sự khác biệt giữa các thuộc tính của một sản phẩm CNTT và hệ thống vận hành khi xét đến mục đích đánh giá an toàn. Tuy nhiên, việc đánh giá hệ thống vận hành có thể phức tạp hơn nhiều so với đường sản phẩm của TCVN 8709 vì một số lý do:

a) Hệ thống vận hành có thể bao gồm nhiều sản phẩm được tích hợp sẵn và những phát triển CNTT được phân loại thành các miền an toàn. Bố cục của từng miền an toàn hệ thống có thể dựa trên một số yếu tố, chẳng hạn như công nghệ sử dụng, chức năng được trang bị và quan trọng là các tài sản được bảo vệ.

b) Một hệ thống vận hành có thể bao gồm nhiều mẫu của cùng một sản phẩm (ví dụ, nhiều bản sao của một hệ thống vận hành được cung cấp bởi cùng nhà cung cấp) hoặc nhiều mẫu khác nhau của cùng một sản phẩm (ví dụ, nhiều tường lửa được cung cấp bởi các nhà cung cấp khác nhau).

c) Một hệ thống vận hành có thể có các chính sách an toàn chỉ áp dụng cho một số miền an toàn này mà không áp dụng cho các miền an toàn khác.

d) Rủi ro còn tồn tại khác nhau có thể chấp nhận được trong các miền khác nhau của một hệ thống vận hành, trong khi một sản phẩm có thể chống lại các mối đe dọa cụ thể đối với các loại tài sản cụ thể mà không cần xem xét đến rủi ro.

Tất cả những yếu tố này tác động đến các yêu cầu đảm bảo cho hệ thống vận hành. Cụ thể, các miền an toàn khác nhau cần có các dạng kiểm soát đảm bảo khác nhau, tùy thuộc vào các thông tin phát triển có sẵn hoặc các loại kiểm soát chức năng khác nhau được lựa chọn. Điều này có nghĩa rằng các mục tiêu đảm bảo phải được định nghĩa và giải thích là một phần của giải pháp đối với vấn đề an toàn.

Hơn nữa, việc đánh giá hệ thống vận hành phải bao gồm tất cả những biện pháp kiểm soát an toàn, kể cả những biện pháp kiểm soát được thực hiện trong môi trường vận hành, nó được xem như những giả định trong đánh giá sản phẩm. Nhìn chung, các loại yêu cầu đảm bảo đối với những biện pháp kiểm soát kỹ thuật được trình bày trong TCVN 8709-3 có thể được mở rộng để áp dụng cho những biện pháp kiểm soát vận hành. Ví dụ, khái niệm về đánh giá các tài liệu thiết kế kỹ thuật cho những biện pháp kiểm soát sẽ trở thành khái niệm đánh giá đặc tả các thủ tục vận hành đối với những biện pháp kiểm soát vận hành. Hành động của những người thực hiện kiểm soát vận hành có thể được kiểm tra theo cách tương tự với cách mà các hành động của các chương trình thực hiện những biện pháp kiểm soát kỹ thuật đã được kiểm tra.

Một số các yêu cầu đảm bảo của TCVN 8709-3 liên quan đến sự phát triển hệ thống không được áp dụng trực tiếp cho các hệ thống vận hành, hoặc việc đánh giá của chúng phải được trì hoãn cho đến giai đoạn cài đặt hệ thống. Tương tự như vậy, việc đảm bảo đối với những biện pháp kiểm soát vận hành thường chỉ có thể đạt được trong các môi trường vận hành thực tế, trong khi kiểm soát kỹ thuật thường được kiểm tra và thử nghiệm trong môi trường phát triển của chúng.

Do đó, để đánh giá những biện pháp kiểm soát an toàn của các hệ thống vận hành thì cần thiết phải tổng quát hóa và sửa đổi các lớp đảm bảo về chức năng kỹ thuật được trình bày trong TCVN 8709-3. Việc này đã được thực hiện, Phụ lục C bao gồm các định nghĩa của các lớp đảm bảo phù hợp để đánh giá hệ thống vận hành.

Vấn đề đặc biệt cần quan tâm đó là đảm bảo tính hiệu quả của những biện pháp kiểm soát thực hiện SSF. Việc đảm bảo đối với khía cạnh kiểm soát kỹ thuật này đạt được thực bằng những kỹ thuật thiết kế kiến trúc như phân chia miền, không can thiệp những biện pháp kiểm soát và khả năng không đi vòng của những biện pháp kiểm soát. Đối với kiểm soát vận hành, tương tự nhưng sử dụng những kỹ thuật khác, chẳng hạn như chia tách nhiệm vụ, kiểm tra, giám sát.

Những phạm vi mà cần đến các thành phần đảm bảo bổ sung để xử lý hệ thống vận hành là:

a) Kiến trúc an toàn tổng thể và vị trí của các thành phần trong kiến trúc;

b) Cấu hình các thành phần bao gồm hệ thống vận hành;

c) Các chính sách, quy tắc và thủ tục quản lý chi phối hoạt động của hệ thống vận hành;

d) Các yêu cầu và quy tắc tương tác với các hệ thống vận hành đáng tin cậy và không đáng tin cậy khác;

e) Giám sát những biện pháp kiểm soát phi CNTT trong giai đoạn vận hành của vòng đời hệ thống.

Do chỉ tập trung vào sản phẩm nên TCVN 8709 giả định rằng một TOE sẽ được phát triển trong một môi trường phát triển đơn khác biệt với môi trường vận hành dự định. Giả thiết này có vẻ không đúng đối với hầu hết các hệ thống vận hành. Ngay cả khi hệ thống vận hành được phát triển trong một môi trường thử nghiệm riêng biệt, giai đoạn cuối của sự phát triển hệ thống vận hành sẽ là tích hợp vào môi trường vận hành, khi các biện pháp kiểm soát vận hành được bổ sung cho hệ thống vận hành. Một số phần của hệ thống vận hành, đặc biệt là các sản phẩm được tích hợp sẵn có thể đã được phát triển trong môi trường phát triển riêng biệt và khác so với môi trường phát triển chính.

Một số thành phần của hệ thống vận hành có thể đã được đánh giá theo TCVN 8709, dựa bên các giả định về môi trường vận hành dự định. Nếu những giả định này được chứng minh là đúng khi xét trong ngữ cảnh hệ thống vận hành thì kết quả đánh giá này sẽ vẫn được áp dụng khi sử dụng những thành phần này như là một phần của hệ thống vận hành, và có thể được tái sử dụng.

Tóm lại, có 5 cách chính đảm bảo kiểm soát hệ thống vận hành đó là:

a) Phân tích thiết kế hệ thống vận hành (Lớp ASD của Phụ lục C, dựa bên lớp ADV của TCVN 8709-3);

b) Kiểm thử hệ thống vận hành (các Lớp AOT của phụ lục C, dựa trên lớp ATE của TCVN 8709-3);

c) Kiểm tra xem hệ thống vận hành có được cài đặt và cấu hình chính xác không (Lớp APR Phụ lục C, không có TCVN 8709-3 tương đương);

d) Kiểm tra hệ thống vận hành có thực hiện một cách an toàn trong khi đang hoạt động trực tiếp không (Lớp ASO của Phụ lục C, không có lớp đảm bảo tương đương của TCVN 8709-3);

e) Tái sử dụng kết quả đánh giá sẵn có (các thành phần của lớp AOC).

Ngoài ra, việc đảm bảo có thể đạt được bằng việc kiểm tra đặc tả các yêu cầu (các lớp ASP và ASS, dựa trên các lớp APE và ASE của TCVN 8709-3), tài liệu hướng dẫn vận hành (lớp AOD, dựa trên lớp AGD của TCVN 8709-3), và đánh giá điểm yếu (lớp AOV, dựa trên lớp AVA của TCVN 8709-3).

Hầu hết những đánh giá hệ thống vận hành sẽ yêu cầu phải sử dụng tất cả các kỹ thuật này.

Có thể có nhiều cách khác nhau để đạt được mức đảm bảo quy định trong một hệ thống vận hành. Không giống như việc đánh giá sản phẩm, không có các mức đảm bảo đánh giá được định nghĩa trước. Những yêu cầu đảm bảo phải được lựa chọn phù hợp với mục tiêu đảm bảo thiết tập từ phân tích các rủi ro đối với hệ thống vận hành và sự sẵn có của các các tài liệu, kết quả kiểm thử, các phương tiện tham gia vào quá trình kiểm thử vận hành và phát triển.

7.4 Các hệ thống vận hành tổng hợp

Nhiều hệ thống vận hành rất lớn và phức tạp, cung cấp nhiều chức năng và có một cấu trúc bên trong phức tạp. Do đó, tiêu chuẩn này định nghĩa một hệ phương pháp luận chuẩn để mô tả kiến trúc của các hệ thống vận hành dựa trên hai mức phân tách - các phân hệ và các thành phần.

Một thành phần là một phần riêng biệt và có thể định danh được của hệ thống vận hành mà thực hiện một phần chức năng của hệ thống vận hành đó (mặc dù vấn đề an toàn có liên quan hoặc không). Một thành phần có thể bao gồm một chức năng duy nhất được cung cấp bởi một sản phẩm duy nhất, sản phẩm này có nhiều chức năng hoặc có một tập hợp các chức năng tích hợp được thực hiện bằng cách kết hợp của phần mềm tùy biến và các thủ tục vận hành. Một phân hệ là một tập hợp một hoặc nhiều thành phần hệ thống vận hành có khả năng thực hiện độc lập với phần còn lại của hệ thống vận hành. Ví dụ, một phân hệ có thể bao gồm một máy khách hoặc máy chủ được tạo thành từ nhiều sản phẩm, nhiều máy chủ và/hoặc máy khách và mạng, hoặc một tập hợp máy khách không đồng nhất và/hoặc các máy chủ. Một số thành phần và phân hệ có thể đã được đánh giá an toàn, những thành phần khác thì không.

Trong các hệ thống vận hành đơn giản, tất cả các phân hệ có thể được tạo thành từ một thành phần; thực sự, có thể chỉ có duy nhất một phân hệ thống vận hành có thể định danh được. Tuy nhiên, hầu hết các hệ thống vận hành được tạo thành từ nhiều phân hệ, mỗi phân hệ gồm nhiều thành phần riêng biệt.

Trong TCVN 8709, thiết kế đích đánh giá hệ thống phải được chia thành các phân hệ và các mô-đun. Một phân hệ trong TCVN 8709 là một mô tả mức cao những gì mà một phần của TOE đang làm và làm như thế nào; một mô-đun là một mô tả chức năng hệ thống ở mức độ chi tiết nhất của sự phân chia được cung cấp bởi thiết kế hệ thống.

Trong thực tế, các phân hệ được định nghĩa trong tiêu chuẩn này tương đương với phân hệ được định nghĩa trong TCVN 8709. Tuy nhiên, một thành phần được định nghĩa trong tiêu chuẩn này có một phạm vi rộng hơn so với mô-đun tiêu chuẩn TCVN 8709, ví dụ, nó có thể bao gồm các chức năng được cung cấp theo nghĩa phi CNTT. Đối với chức năng được thực hiện bởi các phần mềm thì một thành phần có thể tương ứng với các tài liệu thiết kế mô-đun TCVN 8709 mức thấp, mỗi thành phần sẽ tương ứng với một mô-đun mã.

Về cơ bản, các hệ thống vận hành tổng hợp thường:

a) Chứa nhiều phân hệ, mỗi phân hệ gồm nhiều thành phần với mức độ và kiểu đảm bảo khác nhau.

b) Có một cấu trúc những biện pháp kiểm soát được định nghĩa rõ ràng. Đây có thể là "chủ sở hữu" hệ thống vận hành đơn hoặc một tập hợp các mối quan hệ quản lý đã được xác định trên các phần khác nhau của hệ thống vận hành

c) Được xây dựng dựa trên các nhu cầu cụ thể cho hoạt động cụ thể.

d) Các thành phần riêng lẻ chứa một số lượng lớn các tùy chọn cấu hình có thể, một số trong đó không phù hợp với chính sách an toàn hệ thống vận hành.

e) Cho phép chủ sở hữu hệ thống vận hành cân bằng những biện pháp kiểm soát kỹ thuật và kiểm soát vận hành trong các phần khác nhau của hệ thống vận hành.

Các chính sách an toàn có thể khác nhau khi kết hợp các mục khác nhau ở trên, trừ trường hợp hiếm gặp đó là hệ thống vận hành có một chức năng duy nhất. Về logic, tất cả các phần của hệ thống vận hành theo cùng một chính sách an toàn được gọi là một miền an toàn. Việc phân tách hệ thống vận hành thành các phân hệ và các thành phần được quản lý bởi cùng một (các) chính sách an toàn, sau đó được đặc trưng theo chính sách an toàn phù hợp với những rủi ro có thể chấp nhận được đối với miền đó. Các yêu cầu an toàn chức năng và các yêu cầu an toàn đảm bảo có thể được định nghĩa cho từng miền an toàn. Như vậy, mỗi miền an toàn sẽ có một chính sách an toàn riêng, phần định nghĩa vấn đề an toàn riêng, các mục tiêu an toàn, các yêu cầu an toàn và tài liệu an toàn riêng. Tuy nhiên, mỗi miền an toàn này hoạt động trong một mức hệ thống vận hành với các chính sách an toàn, các vấn đề an toàn, các mục tiêu an toàn, yêu cầu an toàn và tài liệu an toàn lớn hơn. Mỗi miền an toàn có thể có các yêu cầu đảm bảo riêng của mình dựa trên mức độ tin cậy cần thiết trong miền an toàn và sự đóng góp tổng thể cho hệ thống vận hành. Đích an toàn hệ thống vận hành quy định các yêu cầu an toàn hệ thống vận hành mà sẽ là một tài liệu điển hình về các miền an toàn bao gồm các hệ thống vận hành xét theo ngữ cảnh hệ thống vận hành. Khái niệm về miền an toàn được minh họa trong Hình 3.

Hình 3 - Ví dụ về các miền

Quan trọng phải biết rằng cấu trúc miền an toàn của một hệ thống vận hành tổng hợp không giống như cấu trúc kiến trúc của nó. Một phân hệ có thể mở rộng ra nhiều miền an toàn (ví dụ, một hệ thống khách - chủ có thể có các chính sách an toàn khác nhau cho các máy khách và máy chủ). Tương tự như vậy, một số sản phẩm của các nhà cung cấp khác nhau cần phải được coi như các thành phần riêng biệt của một hệ thống vận hành nhưng thực hiện các chính sách an toàn giống hệt nhau và do đó nằm trong cùng một miền an toàn.

Khi định nghĩa hệ thống vận hành tổng hợp thì cần thiết phải mô tả cấu trúc kiến trúc của hệ thống, đặc biệt là xác định và mô tả biên của hệ thống, mô tả các giao diện và những phụ thuộc giữa các thành phần của hệ thống, và mô tả các giao diện và những phụ thuộc giữa các thành phần của hệ thống và môi trường của nó (ví dụ như người dùng, hệ thống vận hành bên ngoài). Tất cả giao diện giữa các thành phần và giữa các hệ thống vận hành và môi trường xung quanh nó cần phải được định nghĩa. Những đặc tả giao diện phải bao gồm các yêu cầu an toàn cho các giao diện hoặc các kết nối truyền thông thực hiện giao diện. Ngoài ra, các đặc tả phải định danh bất kỳ mối quan hệ tin cậy hoặc các thuộc tính an toàn không thay đổi đối với giao diện.

7.5 Đảm bảo miền

Lợi ích của khái niệm miền an toàn là cho phép áp dụng các yêu cầu đảm bảo khác nhau cho các phần khác nhau của hệ thống vận hành. Hãy xem xét một hệ thống máy chủ thông thường. Nó được tạo nên từ nhiều thành phần, chẳng hạn như các chương trình ứng dụng, phần sụn và phần mềm cơ sở như một hệ điều hành. Các phần sụn và phần mềm cơ sở có thể là đối tượng đánh giá sản phẩm, nhưng có thể sẽ không được đánh giá tốt như nhau. Đối với sản phẩm không được đánh giá, các nhà cung cấp có thể phối hợp cung cấp các bằng chứng cần thiết để đánh giá, nhưng cũng có thể từ chối cung cấp các bằng chứng cần thiết có sẵn. Đối với sản phẩm đã được đánh giá, Báo cáo kỹ thuật về đánh giá (ETR) có thể giúp hỗ trợ tái sử dụng các kết quả đánh giá, nhưng quyền sử dụng báo cáo ETR có thể bị từ chối.

Hãy xem xét hệ thống được trình bày trong hình 4 dưới đây. Đối với miền an toàn A, được xây dựng từ phần mềm độc quyền, có thể có tất cả các bằng chứng cần thiết để đánh giá theo TCVN 8709. Đối với an toàn miền B, có thể có được bằng chứng thỏa mãn một số tiêu chí đánh giá của TCVN 8709 (ví dụ như các lớp ADO và AGD và ATE_FUN) nhưng một số tiêu chí khác (ví dụ như các lớp ADV và AVA và ATE_COV/DPT) là khó có thể có được vì không thể có và không bao giờ tồn tại bằng chứng cần thiết. Cần phải có được những đảm bảo thay thế (ví dụ như giấy chứng nhận đánh giá sản phẩm) hoặc rủi ro còn tồn tại chấp nhận được.

Hình 4 - Bố cục hệ thống không đồng nhất

Nói cách khác, hệ thống được trình bày trong hình 5 dưới đây được xây dựng từ các thành phần mà có thể có được bằng chứng cần thiết cho đánh giá theo TCVN 8709. Do đó, nó có thể được coi là một miền an toàn duy nhất, miền X có các yêu cầu đảm bảo đồng nhất.

Hình 5 - Bố cục hệ thống đồng nhất

Để đạt được các yêu cầu an toàn của mình, một miền trong một hệ thống vận hành tổng hợp có thể có những phụ thuộc vào các thuộc tính an toàn của các miền khác. Một miền có thể cung cấp các dịch vụ an toàn mà có thể được sử dụng bởi các miền khác nhau thông qua các giao diện truyền thông hoặc các giao diện lập trình ứng dụng, hoặc nó có thể thực thi các thuộc tính an toàn trên các miền khác. Điều này cần phải được phản ánh trong SST đối với hệ thống vận hành.

Các dịch vụ an toàn và các thuộc tính an toàn được thực thi trên các miền khác hoặc được dùng cho các miền khác phải được định danh như công bố các mục tiêu an toàn cho miền. Tương tự như vậy, nếu một miền an toàn có mục tiêu an toàn mà đáp ứng được các miền khác, thì các miền này phải được định danh như công bố các mục tiêu an toàn cho miền.

7.6 Các loại biện pháp kiểm soát an toàn

Tiêu chuẩn TCVN 8709 chủ yếu trình bày những biện pháp kiểm soát kỹ thuật, tức là những biện pháp kiểm soát an toàn được thực hiện bởi các thành phần CNTT của một hệ thống. Tuy nhiên, tiêu chuẩn này cũng cần phải chỉ rõ những biện pháp kiểm soát quản lý và những hoạt động cần thiết để kiểm soát và giám sát những biện pháp kiểm soát kỹ thuật.

Các hệ thống vận hành cũng cần phải định rõ những biện pháp kiểm soát vận hành. Tương tự với kiểm soát kỹ thuật, kiểm soát vận hành có liên quan với những hoạt động và kiểm soát quản lý mà chủ yếu để đảm bảo rằng chúng được thực hiện theo quy định, sử dụng được và có hiệu quả trong thực tế.

Do hầu hết những biện pháp kiểm soát vận hành phụ thuộc vào hành động của con người mà không nhất thiết phải đoán trước hoặc lặp lại nên việc quản lý và giám sát chúng thậm chí còn quan trọng hơn đối với những biện pháp kiểm soát kỹ thuật. Ngoài ra, để đảm bảo hệ thống vận hành an toàn, phải có những biện pháp kiểm soát được thực hiện bởi hệ thống và phải thiết kế việc quản lý chung. Những biện pháp kiểm soát này có thể được phân loại thành những biện pháp kiểm soát vận hành (khi chúng là một phần hoạt động của hệ thống) hoặc kiểm soát quản lý độc lập (khi chúng liên quan hoàn toàn đến quản lý).

Tiêu chuẩn này sử dụng phương pháp tiếp cận những biện pháp kiểm soát quản lý tương tự như TCVN 8709, cụ thể là kiểm soát quản lý luôn được coi là một phần của những biện pháp kiểm soát kỹ thuật hoặc kiểm soát vận hành mà chúng hỗ trợ.

Một ví dụ về phương pháp tiếp cận này được được trình bày trong hình 6 dưới đây. Trong ví dụ này, các chức năng kiểm soát truy cập được thực hiện bởi các máy chủ là kiểm soát kỹ thuật. Việc đăng ký các thuộc tính người dùng là một kiểm soát quản lý hỗ trợ các chức năng kiểm soát truy cập. Tuy nhiên, quy tắc chỉ định vai trò người dùng (ví dụ để thực thi riêng các nhiệm vụ) là một kiểm soát vận hành. Các thủ tục quản lý vai trò của những người dùng này là một kiểm soát quản lý, nhưng có một thủ tục hỗ trợ kiểm soát vận hành này.

Hình 6 - Ví dụ về những biện pháp kiểm soát an toàn

Những biện pháp kiểm soát vận hành có thể bao gồm các quy tắc và thủ tục cũng như bảo vệ vật lý. Ví dụ, một kiểm soát vận hành có liên quan đến các hoạt động quản lý là báo cáo các sự cố bảo mật.

Với một hệ thống vận hành được coi là an toàn nếu kiểm soát kỹ thuật và kiểm soát vận hành (bao gồm cả kiểm soát quản lý có liên quan) phải tích hợp và hoạt động cùng nhau để cung cấp thông tin về tất cả các mối đe dọa. Trong thực tế, việc đóng góp vào sự an toàn của những biện pháp kiểm soát kỹ thuật của hệ thống bị ảnh hưởng bởi những biện pháp kiểm soát vận hành và phụ thuộc vào những biện pháp kiểm soát vận hành mà quy định cho môi trường vận hành. Ví dụ, giá trị "tài sản CNTT" của hệ thống đối với các tổ chức sẽ xác định loại kiểm soát vận hành là bảo vệ vật lý mà nó được tạo ra, nhân viên sẽ phải làm gì để được cấp quyền truy cập vào nó, và dưới những điều kiện những nào nó sẽ được sao lưu để hỗ trợ tiếp tục hoạt động. Ngoài ra, có thể tích hợp kiểm soát kỹ thuật và kiểm soát vận hành như bảo vệ vật lý. Ví dụ, những biện pháp kiểm soát vận hành truy cập vật lý có thể dựa trên những biện pháp kiểm soát kỹ thuật đối với các dịch vụ xác thực và những biện pháp kiểm soát vận hành có thể cung cấp cho kiểm soát kỹ thuật thông tin về sự hiện diện vật lý hay vắng mặt của nhân viên từ một tài sản.

Sử dụng các thành phần chức năng của TCVN 8709-2 để diễn tả trực tiếp những biện pháp kiểm soát kỹ thuật đối với hệ thống vận hành. Tuy nhiên, do sự phức tạp của hệ thống vận hành có thể cần cải tiến thêm các thành phần được coi là không cần thiết khi đánh giá theo TCVN 8709. Một số ví dụ của việc này là:

a) Người quản trị cần phải có năng lực để xác định xem cấu hình hệ thống vận hành có được như mong đợi không. Các yêu cầu về khả năng này là phương pháp tự kiểm tra TSF (FPT_TST) được nói đến trong định nghĩa về "hoạt động chính xác của TOE".

b) SST có thể phân bổ các phần các chức năng an toàn cho các thành phần riêng biệt trong các miền an toàn. Điều này có nghĩa tinh chỉnh "TSF" đối với các phần riêng biệt của TSF, ví dụ: "Các miền an toàn tường lửa sẽ cung cấp một cơ chế để ..."

c) Cần thiết phải định nghĩa chức năng kiểm soát kỹ thuật liên quan đến khả năng tương tác với các hệ thống khác, hoặc liên quan đến khả năng tương tác giữa các thành phần hoặc phân hệ khác nhau của hệ thống vận hành.

Nếu ST đã có các kiểm soát kỹ thuật của một hệ thống vận hành, ví dụ nếu những biện pháp kiểm soát được cung cấp bởi một sản phẩm được tích hợp sẵn và sản phẩm đã được đánh giá, thì ST có thể được sử dụng như một khuôn mẫu để xây dựng các yêu cầu an toàn hệ thống vận hành. Tuy nhiên, do việc đánh giá hệ thống vận hành dựa trên rủi ro, nên các mối đe dọa và các giả định của ST sản phẩm và những phân tích có liên quan đến ST cần phải được đánh giá lại và cần được sửa đổi.

Hầu hết những biện pháp kiểm soát vận hành của một hệ thống vận hành đưa ra các thủ tục và quy trình quản lý và vận hành nằm ngoài phạm vi đánh giá của TCVN 8709, do đó không thể sử dụng thành phần chức năng của TCVN 8709-2 để diễn tả những biện pháp kiểm soát vận hành. Các thành phần chức năng bổ sung cần thiết để xử lý các yêu cầu này, và các thành phần thích hợp sẽ được định nghĩa trong Tiêu chuẩn này.

7.7 Chức năng an toàn của hệ thống

Mô hình dùng cho các chức năng an toàn của TCVN 8709 tập trung quanh việc cung cấp một TOE chỉ đề cập đến các chức năng an toàn. Trong hệ thống vận hành, TOE được tổng quát hóa thành STOE bao gồm cả các chức năng kiểm soát kỹ thuật và kiểm soát vận hành

Các chức năng an toàn hệ thống (SSF) bao gồm các phần đó của STOE (do đó hệ thống vận hành) dựa vào để duy trì các chính sách an toàn cho hệ thống đó. SSF chứa cả kiểm soát an toàn kỹ thuật và kiểm soát an toàn vận hành.

Khi xác định được các yêu cầu an toàn, chủ sở hữu hệ thống có thể lựa chọn để phân bổ các yêu cầu thỏa mãn mục tiêu an toàn chức năng đối với những biện pháp kiểm soát an toàn kỹ thuật, kiểm soát an toàn vận hành hoặc hoặc kết hợp cả hai.

Do đó, cả ba thuật ngữ được sử dụng khi định nghĩa các yêu cầu an toàn vận hành. Khi một kiểm soát an toàn kỹ thuật được yêu cầu thì yêu cầu này phải được diễn tả dưới dạng "TSF sẽ …". Dạng này được sử dụng bởi vì TCVN 8709 đã sử dụng thuật ngữ TSF cho những biện pháp kiểm soát an toàn kỹ thuật rồi. Nếu một kiểm soát vận hành được yêu cầu, thì yêu cầu này phải được diễn tả dưới dạng "OSF sẽ ...", để chỉ ra rằng kiểm soát đó phải là kiểm soát vật lý, kiểm soát nhân sự hoặc thủ tục. Nếu kiểm soát kỹ thuật hoặc vận hành hoặc kết hợp cả hai được yêu cầu thì yêu cầu này phải được diễn tả dưới dạng "SSF sẽ...".

Điều quan trọng là cần lưu ý rằng chỉ có các phần của STOE có liên quan đến bảo mật được tính đến trong SSF đã được đánh giá, và cần lưu ý rằng STOE không đại diện cho toàn bộ hệ thống vận hành. Hình 7 dưới đây đưa ra một minh chứng bằng hình ảnh các khái niệm này.

Hình 7 - Những biện pháp kiểm soát an toàn hệ thống

Theo đánh giá theo TCVN 8709, các chức năng an toàn kỹ thuật thường phụ thuộc vào các khía cạnh của an toàn vận hành. Một ví dụ là phần tử kiểm soát truy nhập FDP_ACC.1.1 của TCVN 8709-2

FDP_ACC.1.1 TSF cần thực thi [chỉ định: Kiểm soát truy nhập SFP] trong [chỉ định: danh sách các chủ thể, đối tượng, và các hoạt động giữa các chủ thể và đối tượng bao trùm bởi SFP]

Theo đánh giá TCVN 8709, các chính sách kiểm soát truy cập và danh sách các đối tượng, các mục tiêu và các hoạt động sẽ được ghi vào tài liệu, nói cách khác phải được giả định đúng. Khi đánh giá hệ thống vận hành, các chính sách và danh sách này sẽ được đánh giá như là một phần của việc đánh giá vai trò và trách nhiệm bảo vệ dữ liệu và nhân sự (xem B.4.2.4, FOA_INF.1.8 và B.2.2.4, FOD_PSN.1.18). Nhìn chung, các quy tắc và thủ tục được quy định bởi TSF phải được giả định đúng và có thể áp dụng khi đánh giá TCVN 8709 sẽ được đánh giá như là một phần đánh giá hệ thống vận hành

Điều quan trọng trong bất kỳ hệ thống vận hành là việc lựa chọn được một sự cân bằng tốt giữa TSF và OSF. TSF yêu cầu phải mua sản phẩm an toàn hoặc thiết kế và thực hiện các chức năng an toàn của hệ thống trong phần cứng và phần mềm. Do đó TSF cần có chi phí và thời gian phát triển hệ thống ban đầu. Nói cách khác. OSF linh hoạt nhưng có thể trở nên không hiệu quả theo thời gian nếu không được kiểm soát. Chúng thường có chi phí thiết lập ban đầu thấp nhưng chi phí vận hành cao do mất thêm các hoạt động thực hiện và kiểm tra những biện pháp kiểm soát OSF. Việc giải thích sự cân bằng mong muốn giữa TSF và OSF trong SST hoặc SPP có thể hỗ trợ trong việc tìm hiểu lựa chọn chức năng đã lựa chọn.

7.8 Thời điểm đánh giá

Việc đánh giá thường được thực hiện tại một thời điểm nhất định cho dù những biện pháp kiểm soát có đáp ứng các yêu cầu đặt ra với chúng không. Việc này có thể diễn ra bất cứ lúc nào trong vòng đời của một hệ thống hoặc một sản phẩm, nhưng trong trường hợp đánh giá sản phẩm theo TCVN 8709 thì việc đánh giá thường diễn ra sau khi việc phát triển sản phẩm hoàn tất, nhưng trước khi sản phẩm được đưa vào hoạt động.

Rất có thể một kiểm soát kỹ thuật được thử nghiệm thành công trong một môi trường phát triển cũng sẽ hoạt động tốt trong môi trường vận hành. Khả năng này chắc chắn ít hơn đối với kiểm soát vận hành. Khi hệ thống vận hành thường xuyên thì con người trong môi trường vận hành có thể ít tin cậy, ít kinh nghiệm, kém thành thạo và/hoặc ít tích cực hơn so với khi thử nghiệm trong trong môi trường phát triển. Do đó, đảm bảo những biện pháp kiểm soát vận hành từ giai đoạn phát triển có thể dùng cho môi trường vận hành ít hơn nhiều so với đảm bảo những biện pháp kiểm soát kỹ thuật. Do đó, rất có thể việc đánh giá ban đầu sẽ mở rộng trong giai đoạn hoạt động, hoặc sẽ diễn ra ở hệ thống đã đi vào hoạt động.

Lý tưởng nhất là đánh giá lại hệ thống vận hành sau những thay đổi lớn về khả năng hoặc rủi ro hệ thống. Tuy nhiên, cũng cần thiết phải đánh giá lại hệ thống vận hành định kỳ để xác định rằng nó vẫn đáp ứng được các mục tiêu của nó một cách hiệu quả và để xác định xem liệu rằng có cần thiết điều chỉnh để duy trì phạm vi chấp nhận rủi ro cần thiết không.

Trường hợp thứ nhất là đánh giá sự phát triển, việc đánh giá sẽ cung cấp bằng chứng tốt là hệ thống vận hành có khả năng đáp ứng được những mục tiêu thay đổi của nó nhưng có ít chứng đối với trường hợp hoạt động thực tế. Ngược lại với quản lý để đảm bảo rằng những biện pháp kiểm soát an toàn hệ thống vận hành được sử dụng có hiệu quả. Trường hợp thứ hai, người đánh giá có thể xác nhận bằng cách kiểm tra hồ sơ hoạt động của những biện pháp kiểm soát và hồ sơ hoạt động của những sự cố an toàn mà những biện pháp kiểm soát đó đáp ứng được yêu cầu và làm việc hiệu quả.

7.9 Sử dụng các sản phẩm đã được đánh giá

Nếu một sản phẩm đã được đánh giá thì cần phải có bằng chứng của việc đánh giá sản phẩm để có thể tái sử dụng khi đánh giá hệ thống vận hành. Tuy nhiên, những bằng chứng chi tiết không thể được công bố công khai. Trong một số trường hợp, bằng chứng này có thể có được trực tiếp thông qua thỏa thuận với người phát triển sản phẩm hoặc xin trực tiếp từ cơ quan quản lý lược đồ đánh giá. Nói cách khác, chi tiết liên quan cần thiết để xác định khả năng ứng dụng đối với vai trò của nó trong hệ thống vận hành không thể có được, và chủ sở hữu hệ thống sau đó phải xác định xem liệu rằng có thể chấp nhận các kết quả mà không cần sử dụng các bằng chứng cho những kết quả đó hay không.

Tương tự, không nhất thiết những kết quả đánh giá sản phẩm có thể được áp dụng được cho đánh giá hệ thống vận hành. Một số lý do là:

a) Cấu hình của sản phẩm trong quá trình đánh giá sản phẩm và cấu hình của sản phẩm khi được tích hợp vào các hệ thống vận hành có thể khác nhau.

b) Sự đảm bảo khi sản phẩm được đánh giá không đầy đủ so với sự đảm bảo mà khi các sản phẩm được yêu cầu khi được tích hợp là một thành phần trong hệ thống vận hành. Trong trường hợp này, có thể cần bằng chứng để tái sử dụng nhưng nếu có bằng chứng mới được tạo ra càng tốt.

Trong những trường hợp này, việc đánh giá hệ thống vận hành là rất cần thiết để xác định mức độ các kết quả được sử dụng và các biện pháp bảo đảm bổ sung có thể cần đến là gì. Trong trường hợp xấu nhất, các thành phần này coi như các thành phần chưa được đánh giá.

Khi một sản phẩm chưa hoàn tất việc đánh giá thì không thể biết được có bao nhiêu thông tin có thể dùng hỗ trợ đánh giá hệ thống vận hành và cũng không thể biết được liệu có bất kỳ thông tin về sản phẩm hiện có sẽ được xác nhận bằng đánh giá sản phẩm hay không. Khi một sản phẩm chưa được đánh giá thì thông tin được cần đến cho đánh giá sản phẩm có thể không dùng để hỗ trợ đánh giá hệ thống vận hành được. Những lưu ý này sẽ cần phải được xem xét khi đánh giá hệ thống vận hành.

Điều quan trọng là phải có thông tin về các đặc tính an toàn của các giao diện giữa các sản phẩm, tức là: chức năng an toàn của một sản phẩm này phụ thuộc vào chức năng an toàn của một sản phẩm khác. Điều cần thiết khi đánh giá hệ thống là phải xác nhận tất cả các sản phẩm phụ thuộc vào chức năng an toàn của các sản phẩm khác phải sử dụng những sản phẩm đó một cách an toàn. Thường thì các thông tin cần thiết sẽ được ghi lại trong ETR của các sản phẩm khác nhưng thông tin có thể không được trình bày theo cách thích hợp. Trong trường hợp này, cần thiết phải xem các tài liệu khác như tài liệu về các đặc tả giao diện và tài liệu hướng dẫn thiết kế kiến trúc như một phần đánh giá hệ thống và cần phải xác nhận rằng chúng phải có những thuộc tính an toàn quy định. Áp dụng tương tự nếu sử dụng sản phẩm không được đánh giá.

Sự đa dạng của các sản phẩm COTS đã được đánh giá có sẵn tích hợp vào một hệ thống vận hành giới hạn sự đảm bảo tối đa có thể đạt được bằng cách sử dụng các sản phẩm được đánh giá. Nói chung, không thiết thực khi đánh giá lại các sản phẩm đã được đánh giá ở mức đảm bảo cao hơn khi không có bằng chứng bổ sung và sự hỗ trợ của người phát triển hệ thống. Nếu không có sự đảm bảo sản phẩm thì cần thiết phải có được sự đảm bảo bổ sung từ những biện pháp kiểm soát thay thế hoặc các giải pháp mang tính kiến trúc, chẳng hạn như thêm tường lửa hoặc các thành phần kiến trúc an toàn khác.

Ngoài ra, việc đánh giá hệ thống vận hành có khả năng phân bổ các mức đảm bảo khác nhau cho các miền khác nhau của hệ thống vận hành. Nếu đảm bảo cho một miền cụ thể bị hạn chế bởi việc sử dụng các sản phẩm đã được đánh giá. Tổ chức chứng nhận có thể được yêu cầu chấp nhận hậu quả rủi ro còn tồn tại bị tăng đối với miền đơn đó.

7.10 Các yêu cầu về tài liệu

Theo đánh giá sản phẩm của chuẩn TCVN 8709 thì hầu hết các yêu cầu về tài liệu được người đánh giá sử dụng để xác nhận xem các hoạt động phát triển đã được thực hiện một cách chính xác chưa và để chắc chắn rằng người dùng có những thông tin cần thiết để cấu hình và hoạt động TOE một cách an toàn.

Trong một hệ thống vận hành, tài liệu phải đưa ra những định nghĩa về kiểm soát vận hành, để:

a) Những người đánh giá có thể xác nhận rằng những biện pháp kiểm soát này sẽ thực sự đáp ứng các mục tiêu an toàn nếu được thực hiện đúng cách;

b) Tiến hành kiểm tra trong giai đoạn hoạt động của vòng đời hệ thống rằng các thủ tục có liên quan đang được tuân thủ và cả những biện pháp kiểm soát thủ tục và kiểm soát vật lý đều có hiệu quả.

Tài liệu được cung cấp phải liên quan đến các thuộc tính an toàn của các giao diện giữa các thành phần khác nhau của hệ thống vận hành, và giữa các thành phần của hệ thống vận hành và các hệ thống khác ở trong môi trường xung quanh nó, do đó nếu một thành phần có những phụ thuộc vào các thuộc tính an toàn của một thành phần khác hoặc hệ thống thì nó có thể được người đánh giá xác nhận rằng những thuộc tính này là hợp lý theo đặc tả của thành phần hay hệ thống đó.

Các yêu cầu về tài liệu thiết kế hệ thống vận hành phải linh hoạt hơn cho phép đánh giá sản phẩm. Đối với một số phân hệ và các thành phần, có thể dùng được tài liệu về an toàn của các tiêu chuẩn được quy định để đánh giá sản phẩm ở mức đảm bảo cao. Tuy nhiên đối với phân hệ và các thành phần khác, đặc biệt là không có tính năng an toàn, có thể có ít hoặc không có tài liệu hướng dẫn an toàn cụ thể và thường rất ít tài liệu thiết kế. Điều này có nghĩa rằng bất kỳ tài liệu nào dùng để đánh giá hệ thống vận hành có thể được dùng cho mục đích đánh giá sản phẩm.

Trong một số trường hợp, các thuộc tính an toàn của một phân hệ hoặc một thành phần có thể được định nghĩa rõ ràng nhưng cách chúng được thực thi có thể chưa được biết đến. Trong trường hợp này, việc tạo ra các tài liệu thiết kế chi tiết là không thể làm được.

Yêu cầu cơ bản để đánh giá việc thiết kế một hệ thống vận hành là phải mô tả kiến trúc hệ thống. Tức là cần phải định danh hệ thống vận hành theo các phân hệ của nó và liên kết giữa các phân hệ, và giao diện bên ngoài của nó đối với các hệ thống khác. Mô tả kiến trúc không cần phải có tài liệu an toàn cụ thể. Nó cho phép người đánh giá hiểu được về kiến trúc tổng thể của hệ thống vận hành, nhưng không phải cách đạt được mục tiêu an toàn của nó.

Mức mô tả kiến trúc thứ hai là cung cấp cho những đánh giá một khái niệm an toàn về tài liệu hoạt động. Tài liệu này mô tả các thuộc tính an toàn của hệ thống vận hành ở một mức độ chi tiết phù hợp với mô tả kiến trúc. Nó bao gồm tất cả các phương thức hoạt động của hệ thống vận hành, mô tả cách các chức năng an toàn của hệ thống vận hành hợp tác với nhau để thực thi các thuộc tính an toàn của hệ thống vận hành, và cách để bảo vệ hệ thống vận hành khỏi bỏ qua hoặc làm xáo trộn chức năng an toàn của nó. Tài liệu này cho phép các kiến trúc an toàn của hệ thống được đánh giá, không phụ thuộc vào cách cách hệ thống vận hành thực thi nội bộ.

Cũng như việc đánh giá kiến trúc an toàn, việc đánh giá hệ thống vận hành biết được cách các tính năng an toàn của hệ thống đã được thực hiện. Mức đánh giá đầu tiên đòi hỏi phải cung cấp một đặc tả giao diện chức năng mà quy định tất cả các chức năng an toàn và các thuộc tính an toàn của hệ thống vận hành có thể xác định được tại các giao diện của nó nhưng không có bất kỳ chi tiết nào của việc thực hiện. Điều này cho phép đánh giá "hộp đen" của các hệ thống vận hành nếu biết được các thuộc tính dã được công bố mà không cần chi tiết về cách thức đạt được.

Cuối cùng, việc đánh giá hệ thống vận hành có thể xem trong tài liệu hướng dẫn thiết kế nội bộ cho hệ thống vận hành. Điều này có thể được thực hiện ở ba mức:

a) Tại vị trí mà tất cả các giao diện và thuộc tính của phân hệ được ghi lại;

b) Tại vị trí mà tất cả các giao diện và thuộc tính của phân hệ được ghi lại ở mức các thành phần riêng lẻ;

c) Tại vị trí mà thiết kế mức thành phần được bổ sung bởi cơ quan đại diện thực thi (mã nguồn, các kịch bản cấu hình) cho các thành phần an toàn.

Mặc dù kiểm soát vận hành không tồn tại cho đến khi hệ thống vận hành đi vào hoạt động nhưng chúng có thể được thiết kế trong quá trình phát triển hệ thống vận hành và việc thiết kế chúng được đánh giá tại thời điểm đó.

7.11 Các hoạt động kiểm thử

Các hoạt động kiểm thử được thực hiện như một phần đánh giá hệ thống vận hành với các yêu cầu mà không được trình bày trong đánh giá sản phẩm theo chuẩn TCVN 8709.

Việc kiểm thử hệ thống vận hành đánh giá hiệu quả hoạt động của các chức năng kiểm soát kỹ thuật và kiểm soát vận hành mà chống lại những rủi ro không thể chấp nhận và thực thi các chính sách an toàn được xác định. Hiệu quả hoạt động của các chức năng này được xác định một phần thông qua kiểm tra các chức năng an toàn của hệ thống vận hành và một phần thông qua tiến hành thử nghiệm. Việc thử nghiệm chỉ có ý nghĩa sau khi hệ thống vận hành đã được đặt vào một cấu hình an toàn đã được kiểm chứng, và đối với trường hợp kiểm soát vận hành, chỉ có thể được mô phỏng trong một môi trường thử nghiệm. Có hai loại cấu hình: cấu hình các sản phẩm để hoạt động tương tác như các thành phần của hệ thống vận hành và cấu hình sản phẩm để cung cấp các hành vi an toàn cần thiết để cho phép các hoạt động nghiệp vụ an toàn ngày này qua ngày khác hoặc nhiệm vụ mà hệ thống vận hành hỗ trợ. Những biện pháp kiểm soát kỹ thuật hệ thống vận hành của có thể và nên được kiểm thử trước khi người phát triển hệ thống /người tích hợp hệ thống triển khai. Việc kiểm thử này sẽ đưa ra khẳng định rằng các chức năng kiểm soát kỹ thuật của hệ thống đang làm việc đúng cách và hiệu quả chống lại các rủi ro đến mức dự kiến của các đánh giá rủi ro. Cần phải xác định những lỗi ngoài ý muốn và cần phải cung cấp cho những người phát triển hệ thống một cửa sổ để giải quyết những lỗi này trước khi đánh giá. Sau đó những biện pháp kiểm soát vận hành sẽ được tích hợp với chức năng kiểm soát kỹ thuật tại địa điểm hoạt động nơi hiệu quả của hệ thống tích hợp kiểm soát an toàn vận hành có thể được đánh giá.

Do việc kiểm thử hoạt động hệ thống không phải là một phần của đánh giá sản phẩm, và đánh giá sản phẩm theo TCVN 8709 không yêu cầu cấu hình của sản phẩm để thực thi một tập hợp cụ thể các chính sách vận hành "thế giới thực" nên tất cả các sản phẩm này cần phải được kiểm thử một cách cụ thể trong cấu hình hệ thống vận hành giống như một phần của kiểm thử toàn bộ hệ thống vận hành.

Cũng có thể có trường hợp là các sản phẩm hoặc các phân hệ trong một hệ thống vận hành không hoạt động đúng cách. Điều này có nghĩa là việc kiểm thử toàn bộ hệ thống vận hành phải được kiểm tra và xác nhận sự tương tác an toàn giữa các thành phần khác nhau và phân hệ.

Kế hoạch kiểm thử nội bộ cũng có thể khác đối với miền an toàn khác nhau mà bao gồm các hệ thống vận hành, tùy thuộc vào các đặc điểm như:

a) Mức độ bảo đảm yêu cầu đối với các phân hệ;

b) Mức độ đảm bảo đã được thành lập (hoặc chưa được thiết lập) cho các sản phẩm mà bao gồm các phân hệ.

c) Kiến trúc được lựa chọn và các sản phẩm mà bao gồm các kiến trúc đó;

d) Công nghệ sử dụng;

e) Vị trí của các thành phần trong môi trường vật lý.

7.12 Quản lý cấu hình

Việc đánh giá hệ thống vận hành có các yêu cầu quản lý cấu hình không được trình bày trong khi đánh giá sản phẩm theo TCVN 8709. Tiêu chuẩn TCVN 8709 đề cập vòng đời của các sản phẩm từ quan điểm của người phát triển hệ thống. Vòng đời của sản phẩm bắt đầu với các yêu cầu về sản phẩm và sau đó là thiết kế, phát triển, đánh giá và sản xuất sản phẩm. Vòng đời chỉ coi những liên quan đến hoạt động hệ thống như những tác động đến phiên bản tiếp theo của sản phẩm.

Do đó, quản lý cấu hình được đề cập chính như một biện pháp bảo đảm để người đánh giá có thể chắc chắn rằng TOE đang được đánh giá là phiên bản chính xác, và người đánh giá có thể chắc chắn rằng những người phát triển hiểu biết những gì cần được kết hợp với TOE đã được đánh giá được phân phối. Qui trình quản lý cấu hình không phải là một phần của TOE mà là một công cụ để tạo ra các TOE.

Trong các hệ thống vận hành điều quan trọng không chỉ là biết được các thành phần chính xác đã được tích hợp vào hệ thống vận hành mà còn phải biết và hiểu được cấu hình của hệ thống trong quá trình hoạt động của hệ thống vận hành. Vì vậy có thể có hai hệ thống quản lý cấu hình khác nhau: một cho môi trường phát triển, trong đó hệ thống vận hành được sản xuất, và một cho các môi trường hoạt động trong đó vận hành hoạt động. Hệ thống quản lý cấu hình đầu tiên của hai hệ thống này được coi như một đảm bảo đánh giá và hệ thống quản lý cấu hình còn lại chính là khả năng kiểm soát vận hành

Đối với những người quản trị hệ thống vận hành và những người quản lý an toàn hệ thống vận hành, hệ thống quản lý cấu hình vận hành tồn tại chủ yếu để thiết lập các hệ thống vận hành duy trì hoạt động trong một cấu hình an toàn và cũng để biết những ảnh hưởng của việc cập nhật, di dời và lắp ghép các thành phần hệ thống vận hành. Do đó, hệ thống vận hành cần phải có khả năng (thông qua các phương tiện hoặc thủ tục) để quản lý cấu hình và báo cáo cấu hình hiện tại. Khả năng báo cáo có thể được sử dụng để so sánh cấu hình hệ thống vận hành thực tế với cấu hình dự định của nó để xác minh rằng những biện pháp kiểm soát an toàn hệ thống đã được cấu hình một cách chính xác, và để xác minh rằng những biện pháp kiểm soát an toàn này đã không bị thay đổi do hoạt động bảo trì hoặc các hoặc cách hoạt động khác và do không được ghi vào tài liệu đúng cách. Việc báo cáo cũng sẽ được dùng để hỗ trợ sự đảm bảo của bất kỳ phân tích tác động thay đổi nào như một kết quả của hoạt động giám sát liên tục. Do đó, quản lý cấu hình trở thành một khả năng an toàn của hệ thống vận hành. Nó có thể được sử dụng để cung cấp bằng chứng đảm bảo cho thấy những biện pháp kiểm soát vận hành được thực hiện một cách chính xác và hiệu quả.

Một chức năng nữa của quản lý cấu hình nữa là đảm bảo các sản phẩm độc lập được hợp nhất thành các thành phần trong một hệ thống vận hành được cấu hình một cách an toàn, phù hợp với tài liệu hướng dẫn và yêu cầu đánh giá sản phẩm. Quản lý cấu hình hệ thống vận hành có thể thực hiện việc kiểm tra này, bằng cách so sánh cấu hình thực tế với bất kỳ ràng buộc nào được ghi trong tài liệu sản phẩm.

8 Mối quan hệ với các chuẩn an toàn thông tin hiện có

8.1 Tổng quan

Tiêu chuẩn này trình bày những mở rộng đối với tiêu chuẩn TCVN 8709 để cho phép đánh giá các hệ thống vận hành. Như đã mô tả trong các điều khoản trước đó, điều khoản này đòi hỏi phải có những mở rộng đối với các mô hình đánh giá được trình bày trong tiêu chuẩn TCVN 8709 và định nghĩa các tiêu chí đánh giá bổ sung.

Đối với hầu hết các phần, các qui trình bổ sung, tài liệu và các nhiệm vụ cần thiết để đánh giá hệ thống vận hành được định nghĩa bằng cách mở rộng khái niệm tương tự trong TCVN 8709. Tiêu chí đánh giá bổ sung chủ yếu đề cập đến các khía cạnh an toàn thông tin hệ thống và vận hành, nó được bắt nguồn từ các tiêu chuẩn không đánh giá an toàn thông tin hiện có. Cụ thể, tiêu chuẩn này chủ yếu dựa trên hai tiêu chuẩn thực hành an toàn thông tin tốt nhất, đó là tiêu chuẩn TCVN ISO/IEC 27002:2011 [3] và NIST SP 800-53 Những biện pháp kiểm soát an toàn thông tin được khuyến nghị cho các hệ thống liên bang [4]. Với sự tồn tại và chấp nhận rộng rãi các tiêu chuẩn này, nó được coi là không phù hợp để phát triển cấu trúc tiêu chí và các tiêu chí mới.

Mối quan hệ này được trình bày trong Hình 8. SST, mô hình chính xác an toàn hệ thống, đánh giá rủi ro, đánh giá điểm yếu, tài liệu hướng dẫn, các thủ tục và các tài liệu thiết kế phát triển sẽ là một phần của các tài liệu được cung cấp để đánh giá hệ thống và đã được tổng quát hóa trong TCVN 8709. Các tiêu chí để đánh giá môi trường vận hành và đặc biệt là những biện pháp kiểm soát vận hành đã được rút ra từ những tài liệu hướng dẫn và tiêu chuẩn không đánh giá.

Hình 8 - Mối quan hệ giữa tiêu chí đánh giá và môi trường vận hành

Cũng như các tiêu chuẩn TCVN ISO/IEC 27002:2011 và NIST SP 800-53, có một số tiêu chuẩn của tiểu ban SC 27, như ISO/IEC 21.827 [5] cũng được sử dụng như là những nguồn tài liệu viện dẫn. Chuẩn ISO/IEC TR 15.443 [6] cung cấp cách tiếp cận các yêu cầu đảm bảo. Chuẩn ISO/IEC TR 15446 [7] đưa ra những hướng dẫn thiết kế đích an toàn và các hồ sơ bảo vệ hệ thống vận hành.

Các tài liệu liên quan khác bao gồm NIST SP 800-53A Hướng dẫn kiểm tra tính hiệu quả của kiểm soát an toàn trong các hệ thống thông tin liên bang [8] và Sổ tay hướng dẫn bảo vệ CNTT của Đức [9].

Các khái niệm và những biện pháp kiểm soát cụ thể đã được lấy từ tất cả các tài liệu này nếu thích hợp. Tuy nhiên, tiêu chí đánh giá không dùng để xác định cách thức để thiết kế và quản lý một hệ thống vận hành an toàn. Mục đích của tiêu chí đăng ký là xác định cách thức để đánh giá hệ thống vận hành an toàn sử dụng bằng chứng được chủ sở hữu hệ thống, người phát triển, tích hợp, vận hành và quản trị hệ thống vận hành cung cấp cho những người đánh giá. Do đó, tiêu chí đánh giá sẽ bao gồm các khía cạnh khác nhau và có tầm quan trọng khác so với nguồn tài liệu từ các tiêu chuẩn và các tài liệu hướng dẫn khác.

Do những quy trình, tài liệu và các nhiệm vụ quy định trong tiêu chuẩn này được dựa trên những quy trình, các nhiệm vụ và tài liệu tương đương trong chuẩn TCVN 8709, nên những đóng góp từ các tiêu chuẩn và từ những tài liệu hướng dẫn khác đã được cấu trúc lại theo một định dạng có mở rộng các phần đã được sử dụng trong TCVN 8709.

8.2 Mối quan hệ với TCVN 8709

Phiên bản đầu tiên của tiêu chuẩn TCVN 8709 được sử dụng làm cơ sở cho sự phát triển của tiêu chuẩn này. Phiên bản sửa đổi này đã được cập nhật để tương thích với phiên bản thứ ba của tiêu chuẩn TCVN 8709.

TCVN 8709 được sử dụng làm cơ sở chính và làm khuôn mẫu để đánh giá hệ thống vận hành. Nó đưa ra các biện pháp quy định các yêu cầu đối với những biện pháp kiểm soát kỹ thuật. Ví dụ, nó bao gồm các tiêu chí về đặc tả các chính sách kiểm soát truy cập. TCVN 8709 không đưa ra các biện pháp quy định những biện pháp kiểm soát vận hành, nhưng những biện pháp kiểm soát này có thể sao chép lại theo một khuôn mẫu giống như tiêu chuẩn TCVN 8709. Điều này cho phép hệ thống vận hành được đánh giá bằng cách sử dụng tiêu chí đảm bảo giống như chuẩn TCVN 8709 được kiểm tra trong quá trình đánh giá.

Phần 1 của tiêu chuẩn TCVN 8709 định nghĩa các khái niệm về các đích an toàn và hồ sơ bảo vệ. Những khuôn đặc tả các yêu cầu làm cơ sở cho các đích an toàn và các hồ sơ nâng cao, các hồ sơ bảo vệ hệ thống (SPP) và các đích an toàn hệ thống (SST), nó cũng bao gồm những biện pháp kiểm soát vận hành.

Phần 2 của TCVN 8709 đưa ra các tiêu chí đánh giá các yêu cầu chức năng an toàn cho các sản phẩm và hệ thống CNTT. Những tiêu chí này có thể áp dụng trực tiếp cho những biện pháp kiểm soát kỹ thuật được quy định cho các hệ thống vận hành và được sử dụng làm cơ sở định nghĩa các thành phần, các họ và các lớp bổ sung mới tập trung vào những biện pháp kiểm soát vận hành của hệ thống vận hành trong Tiêu chuẩn này. Tiêu chuẩn này cũng dùng khía cạnh "như được cấu hình" của các chức năng và các cơ chế trong hệ thống vận hành, và những yêu cầu đối với các chính sách và thủ tục đó phải được thực hiện trong môi trường vận hành bởi những biện pháp kiểm soát vận hành.

Phần 3 của tiêu chuẩn TCVN 8709 xác định các tiêu chí để đánh giá các yêu cầu đảm bảo an toàn cho các sản phẩm và hệ thống CNTT. Các tiêu chí này được sử dụng làm cơ sở cho các lớp, các họ và các thành phần đảm bảo mới tập trung vào các hoạt động đánh giá phải được thực hiện để đánh giá kiểm soát an toàn cho hệ thống vận hành như một bộ phận tích hợp. Phần này bao gồm các yêu cầu về bằng chứng về các chính sách và thủ tục được thực hiện trong môi trường vận hành bởi những biện pháp kiểm soát vận hành.

8.3 Mối quan hệ với các tiêu chuẩn không dùng để đánh giá

TCVN ISO/IEC 27002:2011 là Quy tắc thực hành quản lý an toàn thông tin giúp các tổ chức có được công cụ cần thiết để quản lý an toàn các tài sản thông tin nó đưa ra khuyến nghị về những biện pháp kiểm soát an toàn để quản lý an toàn các tài sản thông tin. TCVN ISO/IEC 27002:2011 cung cấp những khuyến nghị về quản lý an toàn thông tin để chuẩn bị, thực hiện và duy trì an toàn thông tin trong một tổ chức.

TCVN ISO/IEC 27002:2011 cung cấp một khung quản lý về kiểm soát an toàn vận hành được chấp nhận rộng rãi. Nó được sử dụng như một nguồn tài liệu chính để nhận dạng và đưa ra những khía cạnh an toàn vận hành nếu quy định những biện pháp kiểm soát và để tạo ra những yêu cầu kiểm soát vận hành cụ thể.

NIST SP 800-53 cung cấp những nguyên tắc lựa chọn và quy định những biện pháp kiểm soát an toàn thông tin cho các hệ thống thông tin được sử dụng trong các hệ thống liên bang của Chính phủ Mỹ. Các tiểu bang Mỹ, địa phương cũng như các tổ chức tư nhân kể cả các cơ sở hạ tầng quan trọng của Mỹ cũng được khuyến khích để xem xét sử dụng các nguyên tắc của nó. Việc sử dụng các nguyên tắc được giao cho tiêu chuẩn liên bang Mỹ, xuất bản FIPS 200, Kiểm soát an toàn tối thiểu cho các hệ thống thông tin liên bang Mỹ [10]. Nếu thích hợp, NIST SP 800-53 mở rộng tiêu chuẩn TCVN ISO/IEC 27002:2011 về định nghĩa những biện pháp kiểm soát an toàn của nó, nhưng nó cũng bao gồm các lĩnh vực khác không liên quan trực tiếp đến quản lý an toàn thông tin.

Do đó, chuẩn NIST SP 800-53 được sử dụng như là một nguồn tài liệu chính thứ cấp về những biện pháp kiểm soát vận hành, đặc biệt trong những khu vực an toàn vận hành nằm ngoài phạm vi của tiêu chuẩn TCVN ISO/IEC 27002:2011.

Có một số tiêu chuẩn quốc tế khác cũng đưa ra các yêu cầu về kiểm soát an toàn thông tin. Tuy nhiên, nói chung các tiêu chuẩn này đưa ra những biện pháp kiểm soát an toàn thông tin ở mức quá cao được sử dụng như là một nguồn các yêu cầu kiểm soát vận hành cụ thể.

8.4 Mối quan hệ với sự phát triển tiêu chí chung (CC)

Tiêu chí chung là một chuẩn kỹ thuật tương tự TCVN 8709 được xuất bản bởi Ủy ban phát triển tiêu chí chung, hiệp hội các chương trình đánh giá quốc gia. Tiêu chí chung phiên bản 3.1 được sửa lại lần 2 [11] tương đương với phiên bản thứ 3 của TCVN 8709, nó được sử dụng làm cơ sở cho phiên bản của tiêu chuẩn này.

Ủy ban phát triển tiêu chí chung hiện đang trưng cầu ý kiến những thay đổi chính về Tiêu chí chung (CC). Nếu được chấp nhận, rất có thể sẽ được phản ánh trong các phiên bản tương lai của TCVN 8709

9 Đánh giá các hệ thống vận hành

9.1 Giới thiệu

Các hệ thống vận hành được đánh giá theo mô hình đánh giá chung được định nghĩa trong TCVN 8709-1, có các phần mở rộng được định nghĩa trong mục này.

9.2 Trách nhiệm và vai trò đánh giá an toàn hệ thống vận hành

Có 3 loại hoạt động bắt buộc khi đánh giá hệ thống vận hành, đó là:

- Tạo bằng chứng đánh giá (bao gồm cả việc đánh giá rủi ro, đặc tả SST, phát triển và tích hợp, hoạt động, hiệu chỉnh;

- Đánh giá (bao gồm việc chứng thực các kết quả đánh giá);

- Công nhận;

Mỗi hoạt động cần phải chỉ định một người thích hợp để thực hiện, những điều khoản tham chiếu được thỏa thuận và những nhiệm vụ cần thiết được thực hiện. Các hoạt động và các vai trò và trách nhiệm này được trình bày trong Bảng 1 dưới đây. Mỗi hành động được quy định trong tiêu chuẩn này sẽ ánh xạ đến các vai trò và trách nhiệm được định danh trong Bảng 1. Mỗi hành động khác nhau cũng sẽ ánh xạ đến các phần SST được định danh trong Bảng 1.

Bảng 1 - Vai trò và trách nhiệm đánh giá hệ thống vận hành

Hoạt động	Vai trò	Trách nhiệm	Các phần SST
Tạo bằng chứng đánh giá	Người quản lý cấp cao	Chịu hoàn toàn trách nhiệm về sự an toàn hệ thống. Xác định những rủi ro có thể chấp nhận được Phê chuẩn các hoạt động của các nhân viên có thẩm quyền.	N/A

	Nhân viên có thẩm quyền của tổ chức	Đánh giá và chấp nhận những rủi ro còn tồn tại.	Định nghĩa vấn đề an toàn.
	Tổ chức an toàn	Thiết lập các chính sách an toàn cho toàn tổ chức. Xác định những biện pháp kiểm soát mang tính bắt buộc được thực thi bởi các hệ thống của tổ chức.	Định nghĩa vấn đề an toàn
	Người chủ hệ thống	Đánh giá rủi ro. Định nghĩa các vấn đề an toàn được đưa ra bởi hệ thống (bao gồm những mục tiêu, những yêu cầu) Chuẩn bị SPP. Cho phép đánh giá lại hệ thống dựa trên những thay đổi về hệ thống hoặc môi trường của nó. Nhận xét trạng thái hệ thống dựa theo những báo cáo giám sát liên tục.	Định nghĩa vấn đề an toàn. Các mục tiêu an toàn Các yêu cầu an toàn Mô tả STOE
	Người phát triển hệ thống/ người tích hợp/ Người thiết kế hệ thống	Tạo hoặc hỗ trợ tạo SST dựa trên vấn đề an toàn được định nghĩa bởi chủ sở hữu hệ thống. Tạo bằng chứng triển khai. Giúp đỡ người chủ hệ thống giảm hoặc loại bỏ những điểm yếu được phát hiện trong khi đánh giá.	Mô tả STOE Những biện pháp kiểm soát kỹ thuật Những yêu cầu đảm bảo liên quan đến phát triển hệ thống Đặc tả tóm tắt và kiến trúc
	Người vận hành/ Người quản trị/ Người bảo trì	Hỗ trợ tạo SST. Tạo bằng chứng vận hành. Giúp đỡ người chủ hệ thống giảm hoặc loại bỏ những điểm yếu được phát hiện trong khi vận hành hệ thống.	Kiểm soát vận hành. Những yêu cầu đảm bảo liên quan đến hoạt động hệ thống. Đặc tả tóm tắt và kiến trúc.
Đánh giá	Người đánh giá/ Bộ phận chứng nhận	Đánh giá các hệ thống dựa trên các yêu cầu an toàn được nói đến trong SST để xác định khả năng hệ thống để đáp ứng các yêu cầu an toàn của nó tại thời điểm đó. Chuẩn bị đánh giá độc lập các hoạt động an toàn hệ thống thông qua hoạt động hệ thống Chứng thực các kết quả đánh giá. Cung cấp báo cáo kết quả đánh giá và chứng nhận cho chủ sở hữu hệ thống như quy định để hỗ trợ việc công nhận/ ủy quyền hệ thống.	Tất cả
Công nhận	Tổ chức chứng nhận	Cho phép hệ thống sử dụng hoặc xác nhận đối với nhân viên có thẩm quyền rằng những rủi ro còn tồn tại có thể chấp nhận được.	Định nghĩa vấn đề an toàn

9.3 Đánh giá rủi ro và xác định những rủi ro không thể chấp nhận được

Trước khi đánh giá hệ thống vận hành, người chủ sở hữu hệ thống phải xác định phạm vi của hệ thống vận hành, xác định các tài sản cần bảo vệ và phối hợp với cơ quan có thẩm quyền hoặc người đại diện khu vực từ cấp quản lý cao hơn để xác định mức rủi ro mà tổ chức sẵn sàng chấp nhận khi mỗi tài sản của hệ thống vận hành có thể sẽ bị mất, hư hỏng hoặc bị xâm nhập.

Sau đó chủ sở hữu hệ thống sẽ tiến hành đánh giá rủi ro bao gồm tất cả tài sản của hệ thống vận hành. Việc đánh giá rủi ro này sẽ phải xác định tất cả các rủi ro có thể xảy ra đối với hệ thống vận hành, kể cả những rủi ro mà có thể ngăn chặn được hoặc loại bỏ được bằng những biện pháp kiểm soát an toàn hiện có. Những biện pháp kiểm soát an toàn hiện có sẽ được ghi nhận như một phần của đánh giá rủi ro, vì thế nó có thể được bao gồm trong đặc tả SST của các mục tiêu an toàn.

CHÚ THÍCH: Tiêu chuẩn này không quy định bất kỳ mô hình cụ thể hoặc hình thức đánh giá rủi ro. Để biết thêm thông tin về đánh giá rủi ro các hệ thống ICT, tham khảo chuẩn TCVN 10295:2014.

Nếu rủi ro đối với tài sản nằm trên mức độ rủi ro mà tổ chức có thể chịu được thì chủ sở hữu hệ thống phải tổ chức một khóa học về hành động để giảm thiểu rủi ro đến mức chấp nhận được. Điều này có thể mang hình thức:

- Chấp nhận rủi ro, chấp nhận rủi ro tăng lên và thừa nhận trách nhiệm đối với những hậu quả xử lý rủi ro;

- Chuyển giao rủi ro, chuyển giao rủi ro hoặc trách nhiệm đối với hậu quả của nó cho tổ chức khác;

- Tránh rủi ro, chẳng hạn như loại bỏ các hoạt động gây rủi ro;

- Giảm thiểu hoặc loại bỏ rủi ro, giảm thiểu rủi ro đến một mức độ có thể chấp nhận được thông qua việc thực hiện các biện pháp đối phó đánh giá trong hệ thống vận hành để làm giảm khả năng và/hoặc tác động của rủi ro.

Theo phân tích này, mỗi rủi ro sau đó sẽ được phân loại thành rủi ro có thể chấp nhận được theo quan điểm của hệ thống vận hành. Rủi ro chấp nhận được là những rủi ro mà có thể chịu đựng được, chấp nhận được, chuyển được hoặc tránh được. Rủi ro không thể chấp nhận được là những rủi ro mà sẽ được bị loại bỏ hoặc giảm đi.

Nếu các rủi ro không thể chấp nhận, người chủ sở hữu hệ thống phải kết hợp với nhà phát triển hệ thống để nhận dạng và quy định những biện pháp kiểm soát an toàn được thực hiện như những biện pháp đối phó. Chủ sở hữu hệ thống kết hợp với nhà phát triển hệ thống để nhận dạng và quy định những biện pháp kiểm soát đảm bảo để xác nhận rằng những biện pháp kiểm soát an toàn kỹ thuật hoặc những biện pháp kiểm soát an toàn vận hành không đủ đáp ứng các mục tiêu an toàn của họ (nó) như các biện pháp đối phó được giảm xuống mức mà tổ chức có thể chịu đựng được.

Là một phần của giai đoạn hoạt động của vòng đời hệ thống vận hành, chủ sở hữu hệ thống định kỳ xem lại đánh giá rủi ro, để xác định xem:

- Có những thay đổi về tài sản nghiệp vụ;

- Có những rủi ro mới, hoặc thay đổi rủi ro đối với tài sản;

- Các biện pháp đối phó hiện nay vẫn còn phù hợp.

Chủ sở hữu sau đó sẽ quyết định xem có cần cho hệ thống đánh giá lại để xác nhận đầy đủ và tiếp tục hiệu quả của hệ thống kiểm soát an ninh hoạt động chống lại các đánh giá rủi ro điều chỉnh hay không.

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

Chủ sở hữu hệ thống định nghĩa vấn đề an toàn được hệ thống vận hành ghi lại và được ước định bằng cách đánh giá. Mô tả vấn đề an toàn bao gồm:

- Các kết quả đánh giá rủi ro;

- Bất kỳ chính sách an toàn nào của tổ chức mà áp dụng cho hệ thống.

9.5 Các mục tiêu an toàn

Chủ sở hữu hệ thống sẽ phải chuẩn bị một bảng báo cáo các mục tiêu an toàn cho hệ thống vận hành.

Các mục tiêu an toàn sẽ cung cấp một báo cáo ngắn gọn các phản ứng có chủ định đối với các vấn đề an toàn mà hệ thống vận hành phải đối mặt với.

Đối với việc đánh giá hệ thống vận hành, có 2 loại mục tiêu an toàn cần phải phân biệt

a) Các mục tiêu an toàn chức năng mà sẽ được thỏa mãn bởi các kiểm soát kỹ thuật và kiểm soát vận hành được thực hiện bên trong bởi hệ thống vận hành;

b) Các mục tiêu an toàn đảm bảo mà sẽ thỏa mãn bởi các kiểm soát đảm bảo (ví dụ các hoạt động kiểm tra).

Trong TCVN 8709, mục tiêu an toàn chức năng thường được thực hiện bởi những biện pháp kiểm soát kỹ thuật vì môi trường hoạt động không được đánh giá, nhưng được xác định bởi các giả định trong phần định nghĩa vấn đề an toàn. Trong đánh giá hệ thống vận hành, môi trường hoạt động được bao gồm trong phạm vi đánh giá và mục tiêu an toàn chức năng có thể được thực hiện như những biện pháp kiểm soát kỹ thuật, kiểm soát vận hành, hoặc kết hợp cả hai. Tất nhiên, cả kiểm soát kỹ thuật và vận hành có thể liên quan đến những hành động hoặc kiểm soát quản lý kết hợp.

Báo cáo kết quả mục tiêu bảo đảm bao gồm tất cả các mục tiêu an ninh, bao gồm cả hai mục tiêu đó đã được thỏa mãn bởi điều khiển và các mục tiêu hiện tại mà phải đáp ứng điều khiển thêm thực hiện như một phần của hệ thống vận hành

Các miền an toàn khác nhau có thể có các mục tiêu đảm bảo an toàn khác nhau cũng như các mục tiêu chức năng an toàn khác nhau. Điều này là do các mức rủi ra còn tồn tại khác nhau sẽ có thể được chấp nhận ở các miền an toàn khác nhau.

Một số mục tiêu an toàn có thể áp dụng cho toàn bộ STOE nhưng phải được thực hiện bằng cách sử dụng các yêu cầu đảm bảo an toàn hoặc chức năng an toàn khác nhau trong các miền an toàn khác nhau. Điều này là do các loại kiểm soát tương tự không thể có trong tất cả các miền an toàn khác nhau hoặc do yêu cầu đảm bảo tương đương được yêu cầu cho tất cả các miền.

9.6 Các yêu cầu an toàn

9.6.1 Giới thiệu

Người chủ sở hữu hệ thống vận hành phải chuẩn bị một bộ các yêu cầu an toàn cho hệ thống vận hành. Các yêu cầu an toàn sẽ định nghĩa một tập hợp những biện pháp kiểm soát an toàn được thực hiện trong hệ thống vận hành để thỏa mãn các mục tiêu an toàn chức năng và nó sẽ định nghĩa các yêu cầu đảm bảo để xác nhận rằng các kiểm soát này thỏa mãn các mục tiêu an toàn đảm bảo.

9.6.2 Các yêu cầu chức năng an toàn

Các kiểm soát an toàn kỹ thuật phải được lựa chọn từ các lớp chức năng được định nghĩa trong TCVN 8709-2. Các kiểm soát an toàn chức năng phải được lựa chọn từ các lớp chức năng được định nghĩa trong Phụ lục B.

Nếu các kiểm soát được thực hiện bằng cách kết hợp các biện pháp an toàn vận hành thì chúng phải được lựa chọn từ các lớp chức năng được định nghĩa trong Phụ lục B. Các kiểm soát thích hợp được chỉ định bằng cách dùng từ viết tắt SSF để chỉ định rằng biện pháp kỹ thuật hoặc biện pháp vận hành có thể được sử dụng.

TCVN 8709	Hệ thống vận hành	Khả năng áp dụng và tổng quát
Lớp FAU: Đánh giá an toàn	Có thể áp dụng cho các hệ thống vận hành	Tương tự TCVN 8709
Lớp FCO: Truyền thông
Lớp FCS: Hỗ trợ mã hóa
Lớp FDP: Bảo vệ dữ liệu người dùng
Lớp FIA: Định danh và xác thực
Lớp FMT: Quản lý an toàn
Lớp FPR: Riêng tư
Lớp FPT: Bảo vệ TSF
Lớp FRU: Sử dụng tài nguyên
Lớp FTA: Truy nhập TOE
Lớp FTP: Tuyến/Kênh tin cậy
	Lớp FOD: Kiểm soát quản trị	Quản lý chính sách, nhân sự, rủi ro, Quản lý sự cố, các tổ chức an toàn. Thỏa thuận dịch vụ.
	Lớp FOS: Kiểm soát hệ thống CNTT	Chính sách, Cấu hình, An toàn mạng, Giám sát, Kiểm soát nhân sự, Tài sản hệ thống vận hành, Báo cáo.
	Lớp FOA: Kiểm soát tài sản người dùng	Bảo vệ dữ liệu riêng tư, tài sản người dùng
	Lớp FOB: Kiểm soát nghiệp vụ	Chính sách, tính liên tục.
	Lớp FOP: Kiểm soát phương tiện và thiết bị	Thiết bị di động, Thiết bị có thể di dời, Thiết bị điều khiển từ xa, Hệ thống, Tài sản.
	Lớp FOT: Kiểm soát các tổ chức thứ 3	Quản lý
	Lớp FOM: Quản lý	Thông số an toàn, phân loại tài sản, trách nhiệm cá nhân, tổ chức an toàn, báo cáo an toàn

Các kiểm soát mà phải được thực hiện bằng cách kết hợp cụ thể các biện pháp kỹ thuật và các biện pháp vận hành thì trước tiên phải chia thành các yêu cầu kỹ thuật và các yêu cầu vận hành, sau đó sẽ quy định như trên.

Nếu không có thành phần thích hợp nào ở trong hoặc TCVN 8709-2 hoặc Phụ lục B của tài liệu này thỏa mãn một số mục tiêu chức năng an toàn cụ thể thì các thành phần tùy chỉnh bổ sung (additional custom components) được đặt ra và được định nghĩa phù hợp với các thủ tục quy định trong TCVN 8709-1, Phụ lục B.

Bảng 2 so sánh giữa các lớp chức năng được định nghĩa trong TCVN 8709 và tiêu chuẩn này, và khả năng áp dụng chúng đối với việc đánh giá hệ thống vận hành.

Bảng 2 - So sánh các lớp chức năng

9.6.3 Các yêu cầu đảm bảo an toàn

Các yêu cầu đảm bảo được lựa chọn từ các lớp đảm bảo quy định trong Phụ lục C. Các lớp đảm bảo của Phụ lục C được dựa theo phần lớn các lớp đảm bảo từ TCVN 8709-3, nhưng tổng quát để áp dụng cho cả hai phương pháp an toàn kỹ thuật và an toàn vận hành.

Nếu Phụ lục C không có thành phần đảm bảo thích hợp mà đáp ứng mục tiêu đảm bảo đặc biệt, có thể sử dụng thành phần đảm bảo quy định trong TCVN 8709-3. Nếu không có thành phần đảm bảo thích hợp nào ở trong hoặc Phụ lục C hoặc TCVN 8709-3 thì thành phần tùy chỉnh bổ sung được đặt ra và được định nghĩa phù hợp với các thủ tục quy định tại TCVN 8709-1, Phụ lục B

Bảng 3 so sánh giữa các lớp đảm bảo được định nghĩa trong TCVN 8709 và tiêu chuẩn này và khả năng áp dụng để đánh giá hệ thống vận hành.

Bảng 3 - So sánh các lớp đảm bảo

TCVN 8709	Hệ thống vận hành	Khả năng áp dụng
Lớp APE: Đánh giá hồ sơ bảo vệ	Lớp ASP: Đánh giá hồ sơ bảo vệ hệ thống	Đặc tả SPP
Lớp ASE: Đánh giá đích an toàn	Lớp ASS: Đánh giá đích an toàn hệ thống	Đặc tả SST
Lớp ADV: Phát triển	Lớp ASD: Tài liệu cấu hình và thiết kế, kiến trúc hệ thống vận hành	Các giao diện và cấu hình các thành phần Các giao diện ngoài Kiến trúc, luồng tin, truy nhập STOE Chế độ hoạt động / điều kiện chuyển tiếp
Lớp AGD: Tài liệu hướng dẫn	Lớp AOD: Tài liệu hướng dẫn hệ thống vận hành	Các qui tắc và thủ tục hướng dẫn người dùng và hướng dẫn nhà quản trị. Xác nhận và kiểm tra (thời gian vận hành)
Lớp ALC: Hỗ trợ vòng đời	Lớp AOC: Quản lý cấu hình hệ thống vận hành	Quản lý cấu hình (lập kế hoạch, hệ thống CM) Cấu hình đảm bảo các sản phẩm thành phần Sử dụng lại các kết quả đánh giá sản phẩm.
Lớp ATE: Kiểm thử	Lớp AOT: Kiểm thử hệ thống vận hành	Kiểm thử chức năng, tính tổng quát và độ sâu đối với các SSF. Kiểm thử độc lập đối với các SSF Kiểm thử hồi quy tại thời điểm bảo dưỡng/sửa đổi.
Lớp AVA: Đánh giá điểm yếu	Lớp AOV: Đánh giá điểm yếu hệ thống vận hành	Phát hiện các trạng thái không an toàn và khôi phục chúng Kiểm thử thâm nhập (cả thời điểm hoạt động và sau khi bảo dưỡng/sửa đổi)
Lớp ACO: Tổng hợp	Không có	Không thể áp dụng cho các hệ thống vận hành
	Lớp APR: Chuẩn bị cho vận hành trực tiếp	Đào tạo nhận thức và truyền thông các SSFs Xác nhận và kiểm tra (thời gian vận hành)
	Lớp ASO: Các bản ghi hệ thống vận hành	Các bản ghi SSF log Xem xét quản lý trên các SSF Kiểm tra độc lập các SSF Xác nhận và kiểm tra các bản ghi.

9.7 Đích an toàn hệ thống (SST)

Chủ sở hữu hệ thống sẽ ghi lại đị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 đối với hệ thống vận hành hoạt động trong đích an toàn hệ thống (SST). Chủ sở hữu cũng phải thu thập và ghi lại các thông tin cần thiết khác được yêu cầu để hoàn thiện SST như đã xác định trong Phụ lục A.

CHÚ THÍCH Đích an toàn hệ thống khác so với đích an toàn trang web, một dạng tài liệu được sử dụng trong một số chương trình chứng nhận để cho phép tái sử dụng các kết quả đánh giá môi trường phát triển sản phẩm. Đích an toàn trang web cũng thường được viết tắt là SST.

Trường hợp chủ sở hữu của một hệ thống vận hành mong muốn xác định các yêu cầu cho một hệ thống vận hành một cách độc lập thực hiện, đầu tiên ông có thể sản xuất hoặc thông qua một hồ sơ bảo vệ hệ thống (SPP). Các nội dung bắt buộc và tùy chọn của một SPP được quy định tại Phụ lục A.

SST là cơ sở cho cả tài liệu về khả năng bảo mật hệ thống vận hành và cho việc đánh giá những khả năng trong STOE. Như vậy, nó cung cấp các bằng chứng và thông tin cần thiết để thực hiện một đánh giá.

SST khác so với ST do tập trung vào cả kiểm soát vận hành và kiểm soát kỹ thuật của hệ thống vận hành. Một SST có thể được chia thành một số miền an toàn riêng biệt có chức năng kiểm soát và đảm bảo khác nhau. Tuy nhiên, giống như ST, SST có thể được đánh giá một cách độc lập thống nhất từ STOE.

Sau đó, đánh giá của STOE có thể xác định sự khác nhau giữa SST và STOE. Các khác biệt có thể bao gồm:

a) Các khía cạnh môi trường hệ thống vận hành khi thực hiện không giống với môi trường hệ thống vận hành như đã quy định trong SST;

b) Các khía cạnh chức năng an toàn hệ thống vận hành khi thực hiện khác so với chức năng an toàn hệ thống vận hành như đã quy định trong SST;

c) Các khía cạnh các giao diện hệ thống vận hành, những kết nối và hành xử của chúng không giống với các giao diện hệ thống vận hành như đã quy định trong SST.

Chủ sở hữu hệ thống phải xác định xem môi trường thực hiện, chức năng hoặc giao diện/ kết nối có theo yêu cầu hay không, và phần mô tả trong các SST có sai không, hoặc liệu rằng môi trường, chức năng hoặc giao diện/ kết nối cần có được quy định trong SST không. Sau khi hoàn thành việc đánh giá, thay đổi phù hợp phải được thực hiện. Những thay đổi này có thể dẫn đến những thay đổi về SST và / hoặc thay đổi đối với hệ thống vận hành. Vì những lý do này, không thể đánh giá SST để đưa ra một phán quyết cuối cùng về việc liệu SST là một đại diện chính xác của hệ thống vận hành không. Chỉ khi đánh giá STOE hoàn thành và những mâu thuẫn đã được giải quyết SST có thể được xác nhận là một đại diện chính xác.

Bảng 4 So sánh giữa ST được định nghĩa trong TCVN 8709 và SST được định nghĩa trong tiêu chuẩn này và khả năng áp dụng đánh giá hệ thống vận hành

Bảng 4 - So sánh các phần tử đích an toàn

TCVN 8709	Hệ thống vận hành	Khả năng áp dụng đối với các hệ thống vận hành
Giới thiệu	Giới thiệu	Các bộ phận IT/vận hành của TOE và các giao diện với các hệ thống vận hành bên ngoài được xác định. Tổ chức miền có thể được xác định.
Các tuyên bố tuân thủ	Các tuyên bố tuân thủ	Yêu cầu tuân thủ đối với các SPP, PP, và/hoặc các ST có thể được xác định.
Định nghĩa vấn đề an toàn	Định nghĩa vấn đề an toàn	Rủi ro được định nghĩa thay cho các mối đe dọa. Những giả định không phải định nghĩa vì các môi trường là có thực.
Các mục tiêu an toàn	Các mục tiêu an toàn	Các mục tiêu an toàn cho các phần CNTT và vận hành của STOE và các hệ thống vận hành bên ngoài sẽ được xác định.
Các yêu cầu an toàn	Các yêu cầu an toàn	Các yêu cầu chức năng cho các phần CNTT của STOE Các yêu cầu vận hành cho các phần vận hành của STOE Các yêu cầu đảm bảo sẽ được định nghĩa.
Đặc tả tóm tắt TOE	Đặc tả tóm tắt STOE	Các đặc tả chức năng, vận hành và đảm bảo sẽ được mô tả.
	Giới thiệu miền	Các phần CNTT/vận hành của các miền sẽ được xác định.
	Định nghĩa vấn đề an toàn miền	Những rủi ro và các OSP sẽ được định nghĩa
	Các mục tiêu an toàn miền	Các mục tiêu an toàn đối với các bộ phận IT và bộ phận vận hành của các miền sẽ được xác định.
	Các yêu cầu an toàn miền	Những yêu cầu về chức năng đối với các bộ phận IT và bộ phận vận hành của các miền sẽ được định nghĩa. - Những yêu cầu đảm bảo miền sẽ được định nghĩa.
	Đặc tả tóm tắt miền	Các đặc tả chức năng, vận hành và đảm bảo miền sẽ được mô tả.
	Các tuyên bố tuân thủ miền	Yêu cầu tuân thủ đối với các SPP, PP, và/hoặc ST đối với miền có thể được định nghĩa.

9.8 Đánh giá lại theo định kỳ

Chủ sở hữu hệ thống quy định những qui tắc kiểm soát để đảm bảo rằng các kết quả đánh giá hệ thống vận hành vẫn có giá trị trong khi hệ thống vận hành.

Việc này có thể được thực hiện theo hai cách:

- Kiểm soát quản lý có thể được chỉ định để kiểm tra định kỳ tức là cấu hình của những biện pháp kiểm soát kỹ thuật đã được duy trì và các biện pháp kiểm soát hoạt động đang được thực hiện một cách trung thực. Để làm điều này, phải tạo ra các quy trình về thủ tục để quản lý các tác động thay đổi an toàn khi chúng xảy ra trong môi trường vận hành. Nó phải bao gồm kiểm tra ngược lại tất cả các thay đổi hệ thống, để đảm bảo rằng kiểm soát hệ thống không được sửa đổi hoặc vô hiệu hóa.

- Người đánh giá có thể định kỳ đánh giá lại STOE hệ thống vận hành, tập trung vào việc kết hợp các biện pháp kiểm soát kỹ thuật và vận hành cần phải điều chỉnh để đáp ứng những thay đổi các yêu cầu an toàn của tổ chức, và để xác nhận rằng quy trình và thủ tục vận hành đang được áp dụng một cách hiệu quả.

Phụ lục A

(Quy định)

Các đích an toàn và hồ sơ bảo vệ hệ thống vận hành

A.1 Đặc tả đích an toàn hệ thống

A.1.1 Tổng quan

Phần này định nghĩa khái niệm và nội dung của đích an toàn hệ thống (SST).

Bảng A.1 - Tóm tắt sự khác nhau giữa ST và SST

	ST "Sản phẩm"	SST
Khung đặc tả	Trọng tâm là "hộp" đơn	Tập trung đưa ra nhóm các phần tử hệ thống phức tạp và lớn hơn mà có thể được phân tách thành các miền.
Đích an toàn	Nêu chi tiết về CNTT, không ánh xạ trực tiếp đích an toàn đến các yêu cầu đảm bảo.	Mục tiêu cụ thể bắt nguồn từ yêu cầu đảm bảo cụ thể. Mối quan hệ giữa những biện pháp kiểm soát vận hành (vật lý, thủ tục và chính sách) và sự đóng góp của chúng đối với an toàn hệ thống được dẫn chứng bằng tài liệu đối với và các biện pháp đảm bảo được lựa chọn.
Tài liệu môi trường	Giải quyết tối thiểu bên ngoài vùng đánh giá rủi ro và được xem như những giả định.	Cần được định nghĩa rõ ràng và được dẫn chứng bằng tài liệu. Không có giả định.
Đánh giá rủi ro	Nói về phi CNTT, đặc biệt là các thủ tục, như những giả định và tuân thủ sản phẩm có liên quan.	Nhận biết những rủi ro "đã biết" và những biện pháp kiểm soát vận hành có thể đánh giá về sự phù hợp của nó trong môi trường hệ thống tích hợp.
Mô tả TOE	Chỉ tập trung vào CNTT	Định nghĩa môi trường kiểm soát kỹ thuật và vận hành, các giao diện và những mối quan hệ giữa chúng.
Tuyên bố tuân thủ	Hoàn toàn nói về chức năng CNTT	Có thể phân bổ chức năng giữa các thành phần hệ thống (ví dụ: những biện pháp kiểm soát kỹ thuật và những biện pháp kiểm soát vận hành).
Kiến trúc hệ thống	Dựa trên sản phẩm "độc lập"	Được phân chia thành các miền an toàn riêng biệt với những biện pháp kiểm soát khác nhau. Giải quyết tương tác giữa các miền và giữa các miền và môi trường xung quanh.

SST cung cấp đặc tả về những khả năng an toàn của một hệ thống vận hành được thực hiện khi được sử dụng trong bối cảnh hoạt động cụ thể để đối phó với những rủi ro đã được đánh giá và /hoặc thực thi các chính sách an toàn tổ chức đã được công bố để đạt được một mức rủi ro còn tồn tại có thể chấp nhận được. Hệ thống vận hành bao gồm một tổ hợp tích hợp các chức năng kiểm soát kỹ thuật và kiểm soát vận hành. STT mô tả các yêu cầu và hành vi của các chức năng mà thực hiện đích an toàn thông qua một tổ hợp các cơ chế và hoạt động dựa trên công nghệ và dựa trên vận hành hệ thống. Ngoài ra, SST mô tả các biện pháp đảm bảo khả năng của các hệ thống vận hành để đáp ứng các mục tiêu chức năng trong khi hoạt động ở mức rủi ro còn tồn tại có thể chấp nhận.

SST sử dụng như một cơ sở thích hợp để thực hiện đánh giá hệ thống vận hành. Do đó, SST phải cung cấp một mô tả hệ thống vận hành đó là:

a) Tính hoàn thiện. Mỗi rủi ro phải được chống lại một cách thích hợp và mỗi chính sách an toàn của tổ chức phải được thực đầy đủ bằng cách kết hợp các chức năng kiểm soát kỹ thuật và chức năng kiểm soát vận hành.

b) Một giải pháp thích hợp và cần thiết cho vấn đề an toàn đã công bố. Sự kết hợp các chức năng kiểm soát kỹ thuật và chức năng kiểm soát vận hành có hiệu quả trong việc chống lại những rủi ro không thể chấp nhận và thực thi các chính sách an toàn của tổ chức, và các biện pháp đảm bảo để đảm bảo các chức năng an toàn được thực hiện một cách chính xác và hiệu quả.

c) Một mẫu chính xác của bất kỳ SPP, PP hoặc ST nào mà nó tuyên bố tuân thủ hoặc toàn bộ hoặc một phần.

Khái niệm và cấu trúc của một SST dựa trên sự mở rộng khái niệm và cấu trúc của tiêu chuẩn TCVN 8709 về các đích an toàn (ST). Bảng A.1 trên đây trình bày tóm tắt sự khác nhau về khái niệm giữa một ST và SST.

A.1.2 Những nội dung của một SST

Một SST phù hợp với các yêu cầu nội dung được mô tả trong phụ lục này. Một SST phải được trình bày như là một tài liệu định hướng người dùng để giảm thiểu tham chiếu đến các tài liệu khác có thể không có sẵn cho người dùng SST. Việc phân tích có thể được cung cấp riêng biệt, nếu nó phù hợp

Một SST sẽ bao gồm những nội dung sau:

a) Một phần chung có thể áp dụng cho toàn STOE;

b) Các phần miền an toàn, một phần dành cho mỗi miền an toàn được định nghĩa trong STOE, và mô tả những khía cạnh độc nhất của miền đó.

Phần chung của SST thông thường bao gồm những nội dung sau:

a) Giới thiệu SST;

b) Các tuyên bố tuân thủ;

c) Định nghĩa vấn đề an toàn;

d) Các mục tiêu an toàn;

e) Định nghĩa các thành phần mở rộng;

f) Những yêu cầu an toàn;

g) Đặc tả tóm tắt STOE.

Đối với từng miền an toàn của hệ thống vận hành, bao gồm những nội dung sau:

a) Giới thiệu miền an toàn;

b) Các tuyên bố tuân thủ miền an toàn;

c) Định nghĩa vấn đề an toàn miền an toàn;

d) Đích an toàn miền an toàn;

e) Các yêu cầu an toàn miền an toàn;

f) Đặc tả tóm tắt miền an toàn.

Một số phần nào đó của SST có thể trống nếu không có thông tin liên quan được cung cấp. Các tuyên bố tuân thủ chỉ xuất hiện nếu SST tuyên bố tuân thủ với một hoặc nhiều SPP, PP hoặc ST. Một số các phần phụ của thông tin miền an toàn là tùy chọn. Chúng chỉ phải xác định nếu các miền an toàn có các vấn đề an toàn, các mục tiêu, các yêu cầu mà không áp dụng cho các STOE.

Các đặc tả được trình bày trong phần này được bắt nguồn một phần tử những đặc tả ST trong TCVN 8709-1, Phụ lục A, và một phần từ yêu cầu SST bổ sung được định nghĩa trong tiêu chuẩn này.

A.1.3 Giới thiệu SST

Phần giới thiệu SST sẽ định danh SST và STOE, nó cung cấp một cái nhìn tổng quan STOE, tổ chức miền và một mô tả STOE. Phần giới thiệu này sẽ bao gồm việc quản lý tài liệu và thông tin tổng quan như sau:

a) Định danh SST/STOE cung cấp thông tin việc dán nhãn và thông tin mô tả cần thiết để kiểm soát về định danh cả SST và STOE mà nó đề cập.

b) Tổng quan STOE sẽ tóm tắt các mục tiêu của STOE dưới hình thức tường thuật. Tổng quan STOE sẽ phải đầy đủ chi tiết cho một người dùng tiềm năng của SST để xác định xem liệu rằng SST có cần quan tâm không.

c) Mô tả STOE sẽ phác thảo các chức năng và biên của STOE ở hình thức tường thuật.

d) Đặc tả tổ chức miền sẽ mô tả sự phân chia của STOE trong các miền có các yêu cầu bảo mật duy nhất.

Không cần có nội dung hoặc bố trí bắt buộc cho phần Tổng quan STOE, nhưng phải chỉ ra được mục đích hoặc nhiệm vụ của hệ thống vận hành, tổng quan về hệ thống xét trong bối cảnh môi trường vận hành và những mô tả hệ thống từ quan điểm nghiệp vụ, quản lý và kiến trúc kỹ thuật. Nó sẽ định nghĩa mối quan hệ giữa STOE và các hệ thống vận hành bên ngoài, và các giao diện giữa các STOE và các hệ thống này.

Không cần có nội dung hoặc bố trí bắt buộc cho Mô tả STOE, nhưng phải mô tả phạm vi và biên của STOE theo cả quan điểm vật lý và logic. Nó cũng phải mô tả tổ chức và vị trí nơi STOE đã được phát triển, bao gồm bất kỳ đặc điểm nào về các miền riêng lẻ, tức là dựa trên các sản phẩm thương mại.

Các hệ thống vận hành bao gồm một hoặc nhiều miền an toàn. Mỗi miền an toàn bao gồm một số thành phần và có thể có những yêu cầu bảo đảm an toàn riêng. Đặc tả tổ chức miền sẽ ghi vào tài liệu tổ chức của các miền an toàn, biên của miền và các giao diện của chúng một cách chi tiết.

Trường hợp tốt nhất là các STOE sẽ bao gồm các thành phần mà định nghĩa hệ thống vận hành như một thực thể khép kín trong đó không có giao diện đối với các hệ thống vận hành bên ngoài mà không được tính đến khi đánh giá. Từ một quan điểm thực tế, trường hợp tốt nhất này đôi khi không tồn tại và cần phải xác định sự phân chia rõ ràng giữa các phần này của hệ thống vận hành mà sẽ trải qua việc đánh giá như một đơn vị tích hợp và những phần nằm ngoài phạm vi của đánh giá. Các thành phần nằm ngoài phạm vi đánh giá được coi là một phần của hệ thống vận hành bên ngoài

Khái niệm hệ thống vận hành có cơ sở trong các giao diện mà tồn tại giữa các thành phần của hệ thống vận hành. Nếu không có giao diện, không có hệ thống vận hành. Do đó, các giao diện rất quan trọng để định nghĩa hệ thống vận hành và không kém quan trọng đối với khả năng của các hệ thống vận hành để thực thi một chính sách bảo mật trên giao diện của nó. Đặc tả tổ chức tên miền sẽ cung cấp một cái nhìn tổng quan của các thành phần khác nhau của hệ thống vận hành, bao gồm cả cách họ giao tiếp. Các chi tiết của giao diện còn lại giao diện đặc tả cho việc thiết kế và tích hợp các hệ thống vận hành. Tuy nhiên, đặc điểm kỹ thuật tổ chức tên miền phải xác định tất cả tài sản bảo đảm của các miền cá nhân được thi hành trên các miền khác, và tất cả các dịch vụ bảo mật được cung cấp bởi các miền cá nhân có sẵn cho các miền khác.

A.1.4 Các tuyên bố tuân thủ

Phần này chỉ áp dụng nếu SST tuyên bố tuân thủ với một hoặc nhiều SPP, PP, ST hoặc gói yêu cầu an toàn. Phần Các tuyên bố tuân thủ cung cấp bằng chứng cho thấy SST là một mẫu của bất kỳ SPP, PP, ST hoặc gói yêu cầu nào mà được tuyên bố tuân thủ. Việc phân tích các tuyên bố tuân thủ chứng tỏ sự nhất quán giữa các mục tiêu và yêu cầu an toàn SST và những mục tiêu và yêu cầu an toàn của bất kỳ SPP, PP, ST nào hoặc gói yêu cầu mà đã tuyên bố tuân thủ.

Trọng tâm của các tuyên bố tuân thủ là "tương đương" với việc đáp ứng một tập hợp các tiêu chí đã công bố trong các SPP, PP, ST hoặc các gói yêu cầu. SST có thể là một tập lớn các gói chức năng hoặc hồ sơ chứ không phải là một tập con.

Sự khác biệt cơ bản giữa hệ thống vận hành và yêu cầu tuân thủ sản phẩm là đối với hệ thống vận hành nó có thể tích hợp để tái phân bổ chức năng giữa các phần kỹ thuật và hoạt động của hệ thống vận hành bởi vì nó được coi là một phần của STOE. Trong đánh giá sản phẩm, việc phân bổ các chức năng CNTT đối với môi trường phi CNTT làm thay đổi toàn bộ khái niệm về sản phẩm và làm tiêu tan mục đích của hoạt động đánh giá sản phẩm.

A.1.5 Định nghĩa vấn đề an toàn

A.1.5.1 Tổng quan

Phần định nghĩa vấn đề an toàn SST sẽ cung cấp một định nghĩa mạch lạc, nhất quán và đầy đủ toàn bộ những vấn đề an toàn mà hệ thống vận hành được mong đợi để giải quyết. Các vấn đề an toàn đã công bố theo những rủi ro mà sẽ được chống trả bằng các chính sách an toàn tổ chức và hệ thống vận hành hỗ trợ và kiểm soát việc sử dụng các hệ thống vận hành để giảm rủi ro hệ thống vận hành đến mức chấp nhận được.

Định nghĩa vấn đề an toàn sẽ xác định:

a) Tất cả các rủi ro có thể chấp nhận được với STOE

b) Tất cả chính sách an toàn thông tin của tổ chức áp dụng cho STOE.

Trong phần này, cần xác định các vấn đề an toàn có liên quan đến toàn bộ STOE. Có thể là các miền an toàn khác nhau của STOE sẽ thực hiện trong các môi trường vận hành khác nhau, và kết quả là, có thể có các chính sách hoặc rủi ro duy nhất hoặc khác nhau mà phải được giải quyết một cách độc lập bởi các miền an toàn khác nhau của hệ thống vận hành khác nhau. Đối với mỗi miền an toàn, phải xác định vấn đề an toàn bổ sung có liên quan đến miền đó.

Phần này được bắt đầu trước bằng phần giới thiệu STOE, điều quan trọng là bất kỳ tài liệu trình bày trong phần này của SST phải nhất quán với các thông tin được cung cấp trong phần giới thiệu STOE.

A.1.5.2 Định danh rủi ro

Trong phần này tất cả rủi ro đối với STOE phải được mô tả dựa trên đánh giá rủi ro hệ thống vận hành. Mỗi rủi ro được phân loại thành rủi ro chấp nhận được hoặc rủi ro không chấp nhận được, tức là mong muốn giảm hoặc loại bỏ rủi ro thông qua kiểm soát kỹ thuật hoặc kiểm soát vận hành trong STOE. Những rủi ro mà chấp nhận vẫn phải được định danh vì khả năng chấp nhận các rủi ro có thể thay đổi theo thời gian.

Danh sách các rủi ro bao gồm rủi ro liên quan đến sự phát triển của hệ thống vận hành. Mô tả của mỗi rủi ro sẽ phải đầy đủ chi tiết để định danh tài sản mà có thể bị hư hỏng hoặc bị làm hại, các mối đe dọa và các điểm yếu đối với từng tài sản và tác động của cuộc tấn công thành công. Các mối đe dọa cần được mô tả theo các tác nhân đe dọa và các hành động bất lợi tiềm ẩn của nó đến tài sản. Việc đánh giá rủi ro sẽ định danh tất cả các rủi ro có thể đối với hệ thống vận hành, kể cả những rủi ro đó có được chống trả (ngăn chặn) hoặc bị loại bỏ bằng kiểm soát an toàn hiện có

CHÚ THÍCH các tác nhân đe dọa có thể bao gồm các sự kiện tự nhiên như tai nạn, cũng như con người và quy trình máy tính hoạt động dựa trên cách hành xử của chúng.

Theo thời gian, có thể xác định được rủi ro bổ sung hoặc có thể thay đổi được hậu quả của việc vi phạm an toàn. Đánh giá rủi ro phải được lặp đi lặp lại xuyên suốt vòng đời của hệ thống, và nếu cần thiết, phải cập nhật SST và phải đánh giá lại hệ thống vận hành.

Trong phần này, những rủi ro cần được xác định và phân loại có liên quan đến hoạt động của hệ thống, ví dụ những rủi ro liên quan đến nhân viên hay tài sản doanh nghiệp. Một số rủi ro, ví dụ rủi ro liên quan đến quy trình xử lý ứng dụng, chỉ có thể áp dụng cho một miền an toàn riêng biệt và do đó nó chỉ được xác định và được phân tích đối với miền đó.

A.1.5.3 Chính sách an toàn của tổ chức (OSP)

Trong các hệ thống vận hành, phạm vi OSP được mở rộng bao gồm các vấn đề quản lý vòng đời và hoạt động mà không được trình bày khi đánh giá theo TCVN 8709. Các chính sách này bao gồm:

a) Quản lý luật pháp, nhiệm vụ, chỉ thị;

b) Tính liên tục trong nghiệp vụ;

c) Những thỏa thuận sử dụng liên tổ chức (ví dụ ISA hoặc MOU).

A.1.6 Các mục tiêu an toàn

Các mục tiêu an toàn chứa trong phần các mục tiêu an toàn SST sẽ cung cấp một mô tả mạch lạc, nhất quán và đầy đủ hoàn chỉnh mức cao của các giải pháp an toàn dựa trên định nghĩa của những rủi ro không thể chấp nhận được và chính sách an toàn của tổ chức trong phần định nghĩa các vấn đề an toàn. Mô tả mức cao hơn được thực hiện theo mục tiêu an toàn chức năng mà được phân bổ cho những biện pháp kiểm soát kỹ thuật hoặc kiểm soát vận hành của hệ thống vận hành hoặc cho các hệ thống vận hành khác có giao diện với hệ thống vận hành. Việc phân tích các mục tiêu an toàn sẽ chứng minh rằng các mục tiêu an toàn đã công bố có thể theo dấu tất cả các khía cạnh được xác định trong phần định nghĩa các vấn đề an toàn SST và có thể phù hợp để cover chúng. Nó sẽ cung cấp khả năng theo dấu hoàn chỉnh giữa đích an toàn đã công bố và các khía cạnh công bố các vấn đề an toàn, và nó sẽ cung cấp đầy đủ thông tin để xác định xem liệu rằng các mục tiêu an toàn có chống trả được những rủi ro không thể chấp nhận đã công bố và thực thi các chính sách an toàn của tổ chức và công bố không.

Còn có một kiểu mục tiêu an toàn khác mà kiểm soát các hoạt động xác minh để tạo ra và phân tích các bằng chứng và để quan sát hoặc kiểm thử việc thực hiện để xác định rằng nó được thực hiện phù hợp với các yêu cầu. Kiểu mục tiêu an toàn này thường không được chứng minh trong đánh giá theo chuẩn TCVN 8709 (tức là mục tiêu cụ thể không được theo dấu các yêu cầu đảm bảo cụ thể). Kết quả là có rất ít hoặc không có phần nào trong tài liệu về PP/ST chứng minh các biện pháp đảm bảo được lựa chọn. Tuy nhiên, với một hệ thống vận hành, một tuyên bố rõ ràng về mục tiêu bảo đảm là cần thiết, xuất phát từ khía cạnh đảm bảo vấn đề an toàn, để xác minh các biện pháp đảm bảo sẽ áp dụng cho toàn bộ hệ thống vận hành. Những biện pháp này có thể áp dụng cho môi trường phát triển của TOE hoặc hoạt động của nó.

Bản công bố các mục tiêu an toàn phải bao gồm tất cả những biện pháp kiểm soát đã quy định, kể cả những biện pháp kiểm soát đã tồn tại và những biện pháp kiểm soát này phải được tạo ra như một phần của việc thực hiện các hệ thống vận hành.

Các mục tiêu an toàn được lựa chọn để thực hiện một khía cạnh của vấn đề an toàn cũng có thể cung cấp những giải pháp hoặc những giải pháp từng phần ở các khu vực khác. Cụ thể, các mục tiêu an toàn có thể giải quyết những rủi ro đã được chấp nhận sau khi đánh giá rủi ro, tức là được phân loại thành rủi ro có thể chịu được, rủi ro có thể chấp nhận được, rủi ro có thể vận chuyển hoặc có thể tránh được. Những kết nối này vẫn phải được xác định và ghi lại vì khả năng chấp nhận rủi ro có thể thay đổi theo thời gian.

Các mục tiêu an toàn cung cấp các báo cáo mức cao nhất của chiến lược và triết lý chống lại những rủi ro được xác định và thực thi các chính sách bảo mật của tổ chức được xác định. Trong các hệ thống vận hành, điều quan trọng là đích an toàn phải chính xác. Tính chính xác được yêu cầu theo các mục tiêu lần lại dấu vết và những công bố được thực hiện trong định nghĩa vấn đề an toàn và làm thế nào để các đích an toàn phân bổ giải pháp cho các thành phần hệ thống vận hành và các quá trình vật lý.

Các mục tiêu an toàn phải được xem xét dựa vào những rủi ro đã công bố và chính sách bảo mật trong tổ chức một cách chi tiết khi được so sánh về cách thức các mục tiêu an toàn được xem xét trong ý nghĩa của sản phẩm. Điều này là do tác động môi trường có liên quan đến các hệ thống đánh giá hoạt động và kiến thức chi tiết về môi trường phải được bắt trong các mục tiêu an toàn.

Ngoài ra, đích an toàn hệ thống vận hành phải đảm bảo có sự cân bằng trong công tác quản lý rủi ro tổng thể còn lại.

Các miền an toàn khác nhau của hệ thống vận hành sẽ hỗ trợ và thực hiện trong môi trường vận hành khác nhau. Ví dụ, khả năng của hệ thống vận hành theo dõi lưu lượng truy cập mạng nội bộ có thể được cấu hình là "tắt", trong khi khả năng của hệ thống vận hành theo dõi lưu lượng truy cập vào mạng nội bộ được cấu hình là "bật". Kết quả là, có thể có các mục tiêu an toàn khác nhau hoặc duy nhất cho miền an toàn khác nhau. Cũng có thể có mục tiêu đảm bảo bổ sung cho miền an toàn đặc biệt để đáp ứng yêu cầu đảm bảo duy nhất chỉ áp dụng cho những miền.

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

Trong một số trường hợp, các thành phần thích hợp để mô tả các yêu cầu an toàn sẽ không có trong TCVN 8709 hoặc Tiêu chuẩn này. Trong trường hợp này, các thành phần mới được định nghĩa trong phần này của SST. Các thành phần mở rộng này sau đó có thể được sử dụng để định nghĩa các yêu cầu đảm bảo và các yêu cầu chức năng và bổ sung.

A.1.8 Các yêu cầu an toàn

Phần các yêu cầu an toàn sẽ cung cấp một bộ hoàn chỉnh và nhất quán các yêu cầu an toàn cho STOE. Tức là bao gồm cả các yêu cầu chức năng an toàn hệ thống vận hành và các yêu cầu đảm bảo an toàn hệ thống vận hành. Nó áp dụng cho cả các biện pháp kiểm soát kỹ thuật và biện pháp kiểm soát vận hành đã được cung cấp để đáp ứng các đích an toàn hệ thống vận hành. Những yêu cầu này phải cung cấp một cơ sở đầy đủ cho sự phát triển của các quy trình an toàn, các thủ tục, cơ chế và các dịch vụ mà có thể được cấu hình để thực thi các chính sách đã quy định và để chống lại những rủi ro đã xác định. Việc phân tích các yêu cầu an toàn sẽ chứng minh được rằng tập hợp các yêu cầu an toàn phù hợp để đáp ứng và có thể theo dấu tất cả các đích an toàn SST.

Trong một số trường hợp, các yêu cầu an toàn cho một hệ thống vận hành có thể được công bố mà không cần biện minh; tức là chúng không bắt nguồn từ các mục tiêu an toàn mà bản thân chúng được bắt nguồn từ những định nghĩa của các vấn đề an toàn. Trong những trường hợp này, các định nghĩa vấn đề an toàn và các mục tiêu của SST có thể được bỏ qua.

Phần các yêu cầu an toàn mô tả tất cả các chức năng an toàn hệ thống vận hành và những đảm bảo an toàn hệ thống vận hành đã quy định bởi hệ thống vận hành theo các thành phần an toàn hoàn chỉnh.

Có thể là các miền an toàn khác nhau của hệ thống vận hành sẽ hỗ trợ và thực hiện trong các môi trường vận hành khác nhau. Kết quả là, có thể có các yêu cầu an toàn chức năng khác nhau hoặc duy nhất cho mỗi miền an toàn được quy định để đáp ứng các mục tiêu an toàn duy nhất của miền đó. Tương tự như vậy, không cần phải áp dụng các yêu cầu bảo đảm an toàn đối với tất cả các thành phần của hệ thống vận hành với cùng mức độ và sự chính xác. Cần thiết phải phân bổ mức và các loại đảm bảo thích hợp cho các miền an toàn khác nhau được định nghĩa trong SST.

A.1.9 Đặc tả tóm tắt STOE

Đặc tả tóm tắt STOE sẽ cung cấp một sự mô tả mạch lạc, nhất quán, đầy đủ mức cao của các cơ chế an toàn, các dịch vụ, các giao diện, những biện pháp kiểm soát vận hành và các biện pháp bảo đảm, và chứng minh rằng chúng đáp ứng các yêu cầu an toàn hệ thống vận hành đã quy định, việc phân tích đặc tả tóm tắt STOE cho thấy rằng các biện pháp đảm bảo và các chức năng an toàn STOE là phù hợp để đáp ứng các yêu cầu an toàn của STOE.

Cần thiết phải xác định kiến trúc hệ thống vận hành trong SST để người đọc hiểu những giải pháp được cung cấp đáp ứng yêu cầu. Tài liệu thiết kế phải bao gồm các chi tiết về định nghĩa các phân hệ, giao diện và những kết nối và việc phân bổ các yêu cầu chức năng đối với các phân hệ khác nhau mà bao gồm các hệ thống vận hành. Kiến trúc và đặc tả tóm tắt sẽ đưa ra những tương tác giữa các miền an toàn và những tương tác giữa các miền và môi trường của nó.

A.1.10 Thông tin miền an toàn

Phần thông tin miền an toàn của SST cung cấp thông tin liên quan đến miền an toàn từng miền an toàn tạo thành hệ thống vận hành hoàn chỉnh. Nó sẽ cung cấp một định danh chính xác của từng miền an toàn và bất kỳ thông tin an toàn cụ thể của miền mà được quy định.

Nếu chỉ có một miền an toàn trong STOE thì không cần phải đặt tên hoặc định danh một cách rõ ràng, và phần này sẽ được bỏ qua.

Thông tin miền an toàn cho từng miền an toàn sẽ chứa những phần sau đây:

a) Giới thiệu miền an toàn cung cấp thông tin việc dán nhãn và thông tin mô tả cần thiết để kiểm soát và xác định các miền an toàn và STOE mà nó đề cập và tóm tắt các tên miền dưới hình thức tường thuật. Phần tổng quan phải đầy đủ chi tiết để nắm bắt được các chức năng nghiệp vụ của miền an toàn và các yêu cầu an toàn của nó.

b) Các tuyên bố tuân thủ miền an toàn định nghĩa các tuyên bố tuân thủ duy nhất cho miền an toàn. Nếu miền an toàn không có các tuyên bố tuân thủ duy nhất, phần này có thể được bỏ qua.

c) Định nghĩa vấn đề an toàn miền an toàn định nghĩa các vấn đề an toàn mà duy nhất cho miền an toàn. Phần này bao gồm các chính sách và những rủi ro là duy nhất cho miền. Nếu miền an toàn không có các vấn đề an toàn duy nhất, phần này có thể được bỏ qua.

d) Các mục tiêu an toàn miền an toàn định nghĩa các mục tiêu an toàn duy nhất cho miền an toàn. Phần này bao gồm các mục tiêu an toàn mà có sẵn cho các miền khác, hoặc được thực hiện bởi các miền khác. Nếu miền an toàn không có các mục tiêu an toàn duy nhất phần này có thể được bỏ qua.

e) Các yêu cầu an toàn miền an toàn định nghĩa các yêu cầu an toàn duy nhất cho miền an toàn. Nếu miền an toàn không có các yêu cầu an toàn duy nhất, phần này có thể được bỏ qua.

e) Đặc tả tóm tắt miền an toàn định nghĩa các cơ chế, các dịch vụ, các giao diện, những biện pháp kiểm soát vận hành và các biện pháp đảm bảo duy nhất cho miền an toàn. Nếu miền an toàn không có cơ chế, các dịch vụ, các giao diện, những biện pháp kiểm soát vận hành hoặc các biện pháp đảm bảo duy nhất, phần này có thể được bỏ qua.

A.2 Đặc tả hồ sơ bảo vệ hệ thống

A.2.1 Tổng quan

Phần này định nghĩa khái niệm và nội dung của hồ sơ bảo vệ hệ thống (SPP).

Bảng A.2 - Tóm tắt sự khác nhau giữa PP và SPP

	PP "Sản phẩm"	PP hệ thống
Khung đặc tả	Trọng tâm là "hộp" đơn	Tập trung đưa ra nhóm các phần tử hệ thống phức tạp và lớn hơn mà bao gồm hệ thống vận hành, với sự phân bổ vật lý phân tán và những biện pháp kiểm soát an toàn tích hợp.
Tiêu điểm	Hạn chế hơn và cụ thể là CNTT	Rộng hơn, linh hoạt hơn và kết hợp kiểm soát an toàn các khía cạnh của an toàn hệ thống - linh hoạt để ghi chép các trường hợp nghiệp vụ khác nhau.
Kiểm soát vận hành (Vật lý, OSP, Nhân sự..)	Giải quyết tối thiểu bên ngoài vùng đánh giá rủi ro - giả định những phân bổ môi trường.	Đưa ra những biện pháp kiểm soát kỹ thuật cho đối tác giống như đưa ra cho người đóng góp đến an toàn hệ thống để đáp ứng những nhu cầu vận hành.
Đánh giá rủi ro	Nói về phi CNTT, đặc biệt là các thủ tục, như những giả định và tuân thủ sản phẩm có liên quan	Xác định những rủi ro là những rủi ro "đã biết" và những biện pháp kiểm soát vận hành có thể đánh giá về sự phù hợp của nó trong môi trường hệ thống tích hợp.
Mô tả TOE	Hạn chế và chỉ tập trung vào CNTT	Rộng hơn, kết hợp các giao diện bên trong cũng nư các giao diện với các thành phần, phân hệ và hệ thống "bên ngoài/từ xa"

SPP cung cấp các chức năng giống như hồ sơ bảo vệ trong chuẩn TCVN 8709 - SPP trình bày đặc tính của một giải pháp có thể chấp nhận đối với một vấn đề an toàn. Tuy nhiên, SPP phải xử lý sự tích hợp của kiểm soát an toàn kỹ thuật và kiểm soát an toàn vận hành và có thể cần phải xử lý tích hợp nhiều thành phần hoặc các phân hệ với các chính sách bảo mật và/hoặc các môi trường vận hành khác nhau.

SPP phải có khả năng trình bày những lựa chọn và những giải pháp có điều kiện. Một ví dụ có trong định nghĩa đích an toàn. Có thể có cả những giải pháp cho kiểm soát kỹ thuật và kiểm soát vận hành để chống lại những rủi ro cụ thể và những giải pháp mà có thể chấp nhận được theo quan điểm vận hành và chi phí. Một SPP có thể cung cấp một số giải pháp có thể áp dụng và hợp lý cho tác giả SST để lựa chọn một trong số đó.

Tương tự, một SPP phải có khả năng ủy nhiệm những biện pháp kiểm soát an toàn chung nào đó. Ví dụ, có thể có một chính sách an toàn trong một tổ chức mà những biện pháp kiểm soát nào đó sẽ được áp dụng cho tất cả các hệ thống thông tin trong tổ chức đó.

Cuối cùng, Khung đặc tả SPP phải có đủ linh hoạt để cho phép một hệ thống vận hành được đánh giá dựa trên một SPP được tái sử dụng như một thành phần đánh giá của một hệ thống lớn hơn.

Một SPP cũng có thể được sử dụng như là một phần của đặc tả để tạo thành một hệ thống vận hành. Để phù hợp với mục đích này, SPP phải cung cấp một mô tả các khả năng an toàn hệ thống vận hành, đó là:

a) Tính hoàn thiện. Mỗi rủi ro phải được chống trả một cách thích hợp và mỗi chính sách an toàn của tổ chức phải được thực đầy đủ bằng cách kết hợp các chức năng kiểm soát kỹ thuật và chức năng kiểm soát vận hành (hoặc một tùy chọn đã được lựa chọn nếu SPP cho phép những lựa chọn thay thế)

b) Một giải pháp thích hợp và cần thiết cho vấn đề an toàn đã công bố. Sự kết hợp các chức năng kiểm soát kỹ thuật và chức năng kiểm soát vận hành có hiệu quả trong việc chống trả những rủi ro không thể chấp nhận và thực thi các chính sách an toàn của tổ chức, và các biện pháp đảm bảo để đảm bảo các chức năng an toàn được thực hiện một cách chính xác và hiệu quả.

c) Một mẫu chính xác của bất kỳ SPP hoặc PP nào mà nó tuyên bố tuân thủ, hoặc toàn bộ hoặc một phần.

Khái niệm và cấu trúc của một SST dựa trên sự mở rộng khái niệm và cấu trúc của tiêu chuẩn TCVN 8709 về các hồ sơ bảo vệ (PP). Bảng A.2 trên đây trình bày tóm tắt những khác biệt về khái niệm giữa PP và SPP.

A.2.2 Những nội dung của một SPP

Một SSP phù hợp với các yêu cầu nội dung được mô tả trong phụ lục này. Một SPP phải được trình bày như là một tài liệu định hướng người dùng để giảm thiểu tham chiếu đến các tài liệu khác có thể không có sẵn cho người dùng SSP. Việc phân tích có thể được cung cấp riêng biệt, nếu nó phù hợp

Một SPP sẽ bao gồm những nội dung sau:

a) Một phần chung có thể áp dụng cho toàn STOE;

b) Các phần miền, một phần dành cho mỗi miền an toàn được định nghĩa trong STOE, và mô tả những khía cạnh độc nhất của miền đó.

Phần chung sẽ bao gồm những nội dung sau:

a) Giới thiệu SPP;

b) Các tuyên bố tuân thủ;

c) Định nghĩa vấn đề an toàn;

d) Các mục tiêu an toàn;

e) Định nghĩa các thành phần mở rộng;

f) Các yêu cầu an toàn.

Đối với từng miền an toàn tạo thành một phần của các hệ thống vận hành đáp ứng SPP, bao gồm những nội dung sau:

a) Giới thiệu miền an toàn;

b) Các tuyên bố tuân thủ miền an toàn;

c) Định nghĩa vấn đề an toàn miền an toàn;

d) Đích an toàn miền an toàn;

e) Các yêu cầu an toàn miền an toàn.

Một số phần của SSP có thể trống nếu không có thông tin liên quan được cung cấp. Một số phần phụ của thông tin miền an toàn là tùy chọn. Chúng chỉ cần phải xác định nếu các miền an toàn có các vấn đề an toàn, các mục tiêu, các yêu cầu mà không áp dụng cho các STOE.

Các đặc tả được trình bày trong phần này được bắt nguồn một phần từ những đặc tả ST trong TCVN 8709-1, Phụ lục B, và một phần từ yêu cầu SSP bổ sung được định nghĩa trong tiêu chuẩn này

A.2.3 Giới thiệu SPP

Phần giới thiệu SSP sẽ định danh SSP và cung cấp một cái nhìn Tổng quan STOE và tổ chức miền. Phần giới thiệu này sẽ bao gồm việc quản lý tài liệu và thông tin tổng quan như sau:

(a) Định danh SPP cung cấp thông tin việc dán nhãn và thông tin mô tả cần thiết để kiểm soát và định danh SPP.

b) Tổng quan STOE sẽ tóm tắt các mục tiêu của STOE được trình bày dưới hình thức tường thuật. Tổng quan STOE sẽ phải đầy đủ chi tiết cho một người dùng tiềm năng của SSP để xác định xem liệu rằng SSP có cần quan tâm không. Tổng quan STOE cũng có thể được sử dụng như một bản tóm tắt độc lập sử dụng trong các sách hoặc catalog về SPP.

c) Đặc tả tổ chức miền mô tả sự phân chia của STOE trong các miền có các yêu cầu bảo mật duy nhất.

Không cần có nội dung hoặc bố trí bắt buộc cho phần Tổng quan STOE nhưng phải chỉ ra được mục đích hoặc nhiệm vụ của hệ thống vận hành, tổng quan về hệ thống xét trong bối cảnh môi trường vận hành và những mô tả hệ thống từ quan điểm nghiệp vụ, quản lý và kiến trúc kỹ thuật. Nó sẽ định nghĩa mối quan hệ giữa STOE và các hệ thống vận hành bên ngoài, và các giao diện giữa các STOE và các hệ thống này.

Trong trường hợp tốt nhất có thể, các STOE sẽ bao gồm các thành phần để xác định đầy đủ các hệ thống vận hành như một thực thể khép kín trong đó không có giao diện cho hệ thống vận hành bên ngoài mà không được bao gồm trong việc đánh giá. Từ một quan điểm thực tế, trường hợp tốt nhất là đôi khi không thể và nó là cần thiết để xác định một phân vùng rõ ràng giữa các bộ phận của hệ thống vận hành sẽ trải qua đánh giá là một đơn vị tích hợp và những phần nằm ngoài phạm vi của đánh giá. Các thành phần nằm ngoài phạm vi của việc đánh giá đang được coi là một phần của hệ thống vận hành bên ngoài.

Khái niệm hệ thống vận hành có cơ sở trong các giao diện tồn tại trong các thành phần của hệ thống vận hành. Nếu không có giao diện, không có hệ thống vận hành. Do đó, các giao diện rất quan trọng để định nghĩa hệ thống vận hành và không kém quan trọng đối với khả năng của các hệ thống vận hành để thực thi một chính sách bảo mật trên giao diện của nó. Đặc tả tổ chức tên miền sẽ cung cấp một cái nhìn tổng quan của các thành phần khác nhau của hệ thống vận hành, bao gồm cả cách họ giao tiếp. Các chi tiết của giao diện còn lại giao diện đặc tả cho việc thiết kế và tích hợp các hệ thống vận hành. Tuy nhiên, đặc điểm kỹ thuật tổ chức tên miền phải xác định tất cả tài sản bảo đảm của các miền cá nhân sẽ được thực thi.

Danh sách các rủi ro bao gồm rủi ro liên quan đến sự phát triển của hệ thống vận hành. Mô tả của mỗi rủi ro sẽ phải đầy đủ chi tiết để định danh tài sản mà có thể bị hư hỏng hoặc bị làm hại, các mối đe dọa cần được mô tả theo các tác nhân đe dọa và các hành động bất lợi tiềm ẩn của nó đến tài sản. Việc đánh giá rủi ro sẽ định danh tất cả các rủi ro có thể đối với hệ thống vận hành đáp ứng yêu cầu của SPP.

CHÚ THÍCH các tác nhân đe dọa có thể bao gồm các sự kiện tự nhiên như tai nạn, cũng như con người và quy trình tính toán.

Với thời gian, rủi ro bổ sung có thể được xác định hoặc hậu quả của việc vi phạm an toàn có thể thay đổi. Đánh giá rủi ro phải được lặp đi lặp lại theo vòng đời của hệ thống, và, nếu cần thiết, SSP phải được cập nhật và hệ thống vận hành phải được đánh giá lại.

Trong phần này, những rủi ro cần được xác định và phân loại có liên quan đến hoạt động của hệ thống đáp ứng các yêu cầu của SSP ví dụ những rủi ro liên quan đến nhân viên hay tài sản doanh nghiệp. Một số rủi ro, ví dụ rủi ro liên quan đến quy trình xử lý ứng dụng, chỉ có thể áp dụng cho một miền an toàn riêng biệt và do đó nó chỉ được xác định và được phân tích đối với miền đó.

A.2.4 Các tuyên bố tuân thủ

Phần này chỉ áp dụng nếu SPP tuyên bố tuân thủ một hoặc nhiều SPP, PP hoặc các gói yêu cầu an toàn. Phần các tuyên bố tuân thủ cung cấp bằng chứng cho thấy SSP là một thuyết minh có thể chấp nhận được của bất kỳ SPP, PP hoặc gói yêu cầu nào mà được tuyên bố tuân thủ. Phân tích các tuyên bố tuân thủ chứng tỏ sự nhất quán giữa các mục tiêu và yêu cầu an toàn SPP và những mục tiêu và sự nhất quán của bất kỳ SPP, PP hoặc gói yêu cầu nào mà đã tuyên bố tuân thủ.

Trọng tâm của các tuyên bố tuân thủ là "tương đương" với việc đáp ứng một tập hợp các tiêu chí đã công bố trong các SPP hoặc PP. SPP có thể là một tập lớn các gói chức năng hoặc hồ sơ chứ không phải là một tập con.

Sự khác biệt cơ bản giữa hệ thống vận hành và tuyên bố tuân thủ sản phẩm là đối với hệ thống vận hành nó có thể thích hợp để tái phân bổ chức năng giữa các phần kỹ thuật và hoạt động của hệ thống vận hành bởi vì nó được coi là một phần của STOE. Trong tiêu chuẩn đánh giá sản phẩm, việc phân bổ chức năng CNTT đối với môi trường phi CNTT làm thay đổi toàn bộ khái niệm về sản phẩm và làm tiêu tan mục đích của hoạt động đánh giá sản phẩm.

A.2.5 Định nghĩa vấn đề an toàn

A.2.5.1 Tổng quan

Phần định nghĩa vấn đề an toàn SPP sẽ cung cấp một định nghĩa mạch lạc, nhất quán và đầy đủ toàn bộ những vấn đề an toàn mà các hệ thống vận hành đáp ứng được các yêu cầu của SPP được đưa ra. Các vấn đề an toàn đã công bố theo những rủi ro mà sẽ được chống trả bằng các chính sách an toàn của các tổ chức và hệ thống vận hành hỗ trợ và kiểm soát việc sử dụng các hệ thống vận hành để thỏa mãn những yêu cầu của SPP nhằm giảm rủi ro hệ thống vận hành đến mức chấp nhận được.

Phần định nghĩa vấn đề an toàn sẽ định nghĩa:

a) Tất cả những rủi ro có thể chấp nhận được với STOE

b) Tất cả chính sách an toàn thông tin của các tổ chức áp dụng cho STOE.

Trong phần này, cần xác định các vấn đề an toàn có liên quan đến toàn bộ STOE mà đáp ứng các yêu cầu của SPP. Có thể là các miền an toàn khác nhau của các hệ thống vận hành đáp ứng SPP sẽ thực hiện trong các môi trường vận hành khác nhau, và kết quả là, có thể có các chính sách hoặc rủi ro duy nhất hoặc khác nhau mà phải được giải quyết một cách độc lập bởi các miền an toàn khác nhau của hệ thống vận hành. Đối với mỗi miền an toàn, phải xác định các vấn đề an toàn bổ sung có liên quan đến miền đó. Nếu đánh giá rủi ro của một hệ thống vận hành thực tế cho thấy rằng có những rủi ro không được định danh trong SPP thì cần phải hiệu chỉnh biên của hệ thống để loại bỏ những rủi ro này hoặc đưa ra những rủi ro bổ sung vào phần định danh rủi ro SST.

A.2.5.2 Định danh rủi ro

Trong phần này tất cả rủi ro đối với STOE phải được mô tả, dựa trên đánh giá rủi ro hệ thống vận hành và loại hệ thống vận hành được bao trùm bởi SPP. Mỗi rủi ro được phân loại thành rủi ro chấp nhận được hoặc rủi ro không chấp nhận được, tức là phụ thuộc vào việc giảm bớt hoặc loại bỏ rủi ro thông qua những biện pháp kiểm soát kỹ thuật hoặc kiểm soát vận hành trong STOE. Những rủi ro mà chấp nhận vẫn phải được định danh vì khả năng chấp nhận các rủi ro có thể thay đổi theo thời gian.

Danh sách các rủi ro bao gồm những rủi ro liên quan đến sự phát triển của hệ thống vận hành. Phần mô tả của mỗi rủi ro sẽ phải đầy đủ chi tiết để định danh tài sản hoặc các loại tài sản mà có thể bị hư hỏng hoặc bị làm hại, các mối đe dọa và các điểm yếu đối với từng tài sản hoặc loại tài sản và tác động của cuộc tấn công thành công. Các mối đe dọa cần được mô tả theo các tác nhân đe dọa và các hành động bất lợi tiềm ẩn của nó đến tài sản. Việc đánh giá rủi ro sẽ định danh tất cả các rủi ro có thể đối với hệ thống vận hành đáp ứng được các yêu cầu của SPP.

CHÚ THÍCH các tác nhân đe dọa có thể bao gồm các sự kiện tự nhiên như tai nạn, cũng như con người và quy trình máy tính hoạt động theo cách hành xử của chúng.

Theo thời gian, có thể xác định được những rủi ro bổ sung hoặc có thể thay đổi hậu quả của việc vi phạm an toàn. Đánh giá rủi ro phải được lặp đi lặp lại xuyên suốt vòng đời của hệ thống; nếu cần thiết, phải cập nhật SST và phải đánh giá lại hệ thống vận hành.

Trong phần này, những rủi ro đó cần được xác định và phân loại mà có liên quan đến hoạt động của hệ thống sẽ đáp ứng được các yêu cầu của SPP, ví dụ những rủi ro liên quan đến nhân viên hay tài sản doanh nghiệp. Một số rủi ro, ví dụ rủi ro liên quan đến quy trình xử lý ứng dụng, chỉ có thể áp dụng cho một miền an toàn riêng biệt và do đó nó chỉ được xác định và được phân tích đối với miền đó.

A.2.5.3 Chính sách an toàn của tổ chức (OSP)

a) quản lý luật pháp, nhiệm vụ, chỉ thị;

b) tính liên tục trong nghiệp vụ;

c) Những thỏa thuận sử dụng liên tổ chức (ví dụ ISA hoặc MOU).

A.2.6 Các mục tiêu an toàn

Các mục tiêu an toàn chứa trong phần đích an toàn SSP sẽ cung cấp một mô tả mạch lạc, nhất quán và đầy đủ hoàn chỉnh mức cao của các giải pháp an toàn dựa trên định nghĩa của những rủi ro không thể chấp nhận được và chính sách an toàn của tổ chức trong phần định nghĩa các vấn đề an toàn. Mô tả mức cao được thực hiện trong các điều khoản mục tiêu an toàn chức năng mà được phân bổ cho những biện pháp kiểm soát kỹ thuật hoặc kiểm soát vận hành của hệ thống vận hành hoặc cho các hệ thống vận hành khác có giao diện với hệ thống vận hành. Việc phân tích đích an toàn sẽ chứng minh rằng đích an toàn đã công bố có thể theo dấu tất cả các khía cạnh được xác định trong định nghĩa các vấn đề an toàn SST và có thể phù hợp để cover chúng. Nó sẽ cung cấp khả năng theo dấu hoàn chỉnh giữa đích an toàn đã công bố và các khía cạnh công bố các vấn đề an toàn và nó sẽ cung cấp đầy đủ thông tin để xác định xem liệu rằng các mục tiêu an toàn có chống trả được những rủi ro không thể chấp nhận đã công bố và thực thi các chính sách an toàn của tổ chức đã công bố không.

Còn có một kiểu mục tiêu an toàn khác mà kiểm soát các hoạt động xác minh để tạo ra và phân tích các bằng chứng và để quan sát hoặc kiểm thử việc thực hiện để xác định rằng nó được thực hiện phù hợp với các yêu cầu. Kiểu mục tiêu an toàn này thường không được chứng minh trong đánh giá theo chuẩn TCVN 8709 (tức là mục tiêu cụ thể không được theo dấu các yêu cầu đảm bảo cụ thể). Kết quả là có rất ít hoặc không có phần nào trong tài liệu về PP/ST chứng minh các biện pháp đảm bảo được lựa chọn. Tuy nhiên, với một hệ thống vận hành, một tuyên bố rõ ràng về mục tiêu bảo đảm là cần thiết, xuất phát từ khía cạnh đảm bảo vấn đề an toàn, để chứng minh các biện pháp đảm bảo sẽ áp dụng cho toàn bộ hệ thống vận hành. Những biện pháp này có thể áp dụng cho môi trường phát triển của TOE hoặc hoạt động của nó.

Công bố những mục tiêu an toàn phải bao gồm tất cả những biện pháp kiểm soát đã quy định, kể cả những biện pháp kiểm soát đã tồn tại và những biện pháp kiểm soát này phải được tạo ra như một phần của việc thực hiện các hệ thống vận hành

Các mục tiêu an toàn được lựa chọn để thực hiện một khía cạnh của vấn đề an toàn cũng có thể cung cấp những giải pháp hoặc những giải pháp từng phần ở các khu vực khác. Đặc biệt, đích an toàn có thể giải quyết những rủi ro mà đã được chấp nhận sau khi đánh giá rủi ro, tức là được phân loại thành rủi ro có thể chịu được, rủi ro có thể chấp nhận được, rủi ro có thể vận chuyển hoặc có thể tránh được. Những liên kết này vẫn phải được xác định và ghi lại vì khả năng chấp nhận rủi ro có thể thay đổi theo thời gian.

Các mục tiêu an toàn cung cấp các báo cáo mức cao nhất của chiến lược và triết lý chống lại những rủi ro được xác định và thực thi các chính sách bảo mật của tổ chức được xác định. Trong các hệ thống vận hành, điều quan trọng là đích an toàn là chính xác. Chính xác là cần thiết cả về cách các mục tiêu tìm lại và báo cáo bìa được thực hiện trong định nghĩa vấn đề an toàn và về làm thế nào các đích an toàn cấp giải pháp cho các thành phần hệ thống vận hành và các quá trình vật lý.

Các mục tiêu an toàn phải được lưu ý những rủi ro đã nêu và chính sách bảo mật trong tổ chức chi tiết tốt hơn khi so sánh với cách thức chúng được coi là trong ý nghĩa của sản phẩm. Điều này là do tác động môi trường có liên quan đến các hệ thống đánh giá hoạt động và kiến thức chi tiết về môi trường phải được bắt trong các đích an toàn.

Ngoài ra, mục tiêu an toàn hệ thống vận hành phải đảm bảo có sự cân bằng đạt được trong công tác quản lý rủi ro còn lại tổng thể.

Có thể là miền an toàn khác nhau của các hệ thống vận hành đáp ứng các yêu cầu của SPP sẽ hỗ trợ và thực hiện trong môi trường vận hành khác nhau. Ví dụ, năng lực cho hệ thống vận hành để theo dõi lưu lượng truy cập mạng nội bộ có thể được cấu hình là "tắt" trong khi năng lực cho hệ thống vận hành để theo dõi lưu lượng truy cập vào mạng nội bộ được cấu hình như "bật". Kết quả là, có thể có đích an toàn khác nhau hoặc duy nhất cho miền an toàn khác nhau. Cũng có thể có mục tiêu đảm bảo bổ sung cho miền an toàn đặc biệt để đáp ứng các yêu cầu đảm bảo duy nhất chỉ áp dụng cho những miền.

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

A.2.8 Các yêu cầu an toàn

Phần các yêu cầu an toàn mô tả tất cả các chức năng an toàn hệ thống vận hành và những đảm bảo an toàn hệ thống vận hành đã quy định bởi hệ thống vận hành trong khoản mục các thành phần an toàn.

Các miền an toàn khác nhau của hệ thống vận hành sẽ hỗ trợ và thực hiện trong các môi trường vận hành khác nhau. Kết quả là, có thể có các yêu cầu an toàn chức năng khác nhau hoặc duy nhất cho mỗi miền an toàn, được quy định để đáp ứng các mục tiêu an toàn duy nhất của miền đó. Tương tự như vậy, các yêu cầu đảm bảo an toàn không cần phải áp dụng trên tất cả các thành phần hệ thống vận hành với cùng mức độ và sự chính xác. Cần thiết phải phân bổ mức và các loại đảm bảo thích hợp cho các miền an toàn khác nhau được định nghĩa trong SST.

A.2.9 Thông tin miền an toàn

Nếu chỉ có một miền an toàn trong STOE thì không cần phải đặt tên hoặc định danh một cách rõ ràng, và phần này sẽ được bỏ qua.

Thông tin miền an toàn cho từng miền an toàn sẽ chứa những phần sau đây:

Phụ lục B

(Quy định)

Các yêu cầu kiểm soát chức năng hệ thống vận hành

B.1 Giới thiệu

Phụ lục này định nghĩa các thành phần chức năng kiểm soát hệ thống vận hành bao gồm các khía cạnh quản lý và thủ tục của một STOE. Các thành phần được mô tả trong tài liệu này hoạt động kết hợp với các thành phần kỹ thuật quy định trong TCVN 8709-2 để thỏa mãn mục tiêu an toàn của STOE. TCVN 8709-2 được sử dụng làm cơ sở cấu trúc cho các thành phần này.

Thành phần chức năng kiểm soát vận hành được phân loại theo đối tượng, các vùng chức năng và các hành động. Đối tượng là mục tiêu trực tiếp áp dụng cho những biện pháp kiểm soát, chẳng hạn như dữ liệu nghiệp vụ, phương tiện tham gia vào quá trình xử lý thông tin hoặc các hệ thống CNTT. Các vùng chức năng là mục tiêu áp dụng cho những hoạt động xác định, chẳng hạn như chính sách an toàn thông tin, báo cáo hoặc quản lý rủi ro. Mỗi vùng chức năng sẽ tạo thành một họ của một lớp. Những hành động là một hoạt động trong một vùng chức năng đã xác định và tạo thành một thành phần trong họ đó. Các phần tử là định nghĩa cụ thể về nguyên tắc và thủ tục kiểm soát.

Có 7 lớp kiểm soát vận hành mới được định nghĩa trong phụ lục này. Đó là:

a) Quản trị (FOD), quy định các yêu cầu kiểm soát vận hành liên quan đến quản trị hệ thống;

b) Các hệ thống CNTT (FOS), quy định các yêu cầu kiểm soát vận hành hỗ trợ việc sử dụng các hệ thống và thiết bị CNTT;

c) Tài sản người dùng (FOA), quy định các yêu cầu kiểm soát vận hành liên quan đến việc kiểm soát tài sản người dùng;

d) Nghiệp vụ (FOB), quy định các yêu cầu kiểm soát vận hành liên quan đến những chức năng và quy trình nghiệp vụ;

e) Phương tiện và thiết bị (FOP), quy định các biện pháp kiểm soát vận hành liên quan đến thiết bị nghiệp vụ, tài sản;

f) Tổ chức thứ 3 (FOT), quy định các biện pháp kiểm soát vận hành liên quan đến mối quan hệ với các tổ chức thứ 3;

g) Quản lý (FOM), quy định các biện pháp kiểm soát vận hành liên quan đến các hoạt động quản lý.

Các họ của các lớp chức năng này được trình bày trong Bảng B.1 dưới đây.

Những phụ thuộc giữa các thành phần của các họ này được trình bày trong bảng B.2.

Mỗi thành phần phụ thuộc vào một vài thành phần chức năng được định rõ vị trí một cột. Mỗi thành phần chức năng có những phụ thuộc được định rõ ở một hàng. Giá trị trong mỗi ô của bảng cho biết thành phần nhãn trong cột phụ thuộc trực tiếp (được biểu thị bằng dấu ‘X’) hoặc phụ thuộc gián tiếp (được biểu thị bằng dấu gạch ngang '-') vào thành phần nhãn trong một hàng.

Một số yêu cầu đối với những biện pháp kiểm soát vận hành sẽ được thực thi như những yêu cầu vận hành và do đó nó được định nghĩa là OSF. Một số yêu cầu khác đối với những biện pháp kiểm soát kỹ thuật hoặc kiểm soát vận hành có thể được thực thi như những yêu cầu vận hành hoặc yêu cầu kỹ thuật và do đó nó được định nghĩa là SSF.

Có 4 sự khác biệt so với chuẩn TCVN 8709-2 đó là: Không có các thành phần kiểm soát vận hành theo thứ bậc, vì thế đề mục phụ được bỏ đi. Tất cả các hoạt động quản lý được xử lý bởi các thành phần rõ ràng, do đó không cần có các đề mục phụ về các hoạt động quản lý. Các đề mục phụ về đánh giá được thay bằng các bản ghi, được biểu thị rõ ràng hơn về quy trình tập hợp bằng chứng cần thiết cho những biện pháp kiểm soát vận hành. Chỉ định cho phép hoạt động được sử dụng linh hoạt hơn chỉ định cho phép hoạt động được sử dụng trong chuẩn TCVN 8709-2. Định danh các tài liệu mô tả các quy tắc, thủ tục, chính sách kết hợp, những yêu cầu an toàn và những kiểm soát khác có thể được chỉ rõ là một chỉ định.

Bảng B.1 - Các họ chức năng kiểm soát vận hành

Lớp chức năng	Họ chức năng
Quản trị (FOD)	Quản trị chính sách (FOD_POL)
	Quản trị nhân sự (FOD_PSN)
	Quản trị quản lý rủi ro (FOD_RSM)
	Quản trị quản lý sự cố (FOD_INC)
	Quản trị an toàn tổ chức (FOD_ORG)
	Quản trị những thỏa thuận dịch vụ (FOD_SER)
Các hệ thống CNTT (FOS)	Chính sách đối với các hệ thống CNTT (FOS_POL)
	Cấu hình các hệ thống CNTT (FOS_CNF)
	An toàn mạng của Các hệ thống CNTT (FOS_NET)
	Giám sát các hệ thống CNTT (FOS_MON)
	Kiểm soát nhân sự của các hệ thống CNTT (FOS_PSN)
	Tài sản hệ thống vận hành của các hệ thống CNTT (FOS_OAS)
	Các bản ghi dành cho các hệ thống CNTT (FOS_RCD)
Tài sản người dùng (FOA)	Bảo vệ dữ liệu riêng tư (FOA_PRO)
Tài sản người dùng (FOA)	Bảo vệ thông tin tài sản người dùng (FOA_INF)
Nghiệp vụ (FOB)	Các chính sách nghiệp vụ (FOB_POL)
Nghiệp vụ (FOB)	Tính liên tục của nghiệp vụ (FOB_BCN)
Phương tiện và thiết bị (FOP)	Thiết bị di động (FOP_MOB)
	Thiết bị có thể di chuyển được (FOP_RMM)
	Thiết bị điều khiển từ xa (FOP_RMT)
	Thiết bị hệ thống (FOP_SYS)
	Quản lý tài sản (FOP_MNG)
Các tổ chức thứ 3 (FOT)	Những cam kết với tổ chức thứ 3 (FOT_COM)
Các tổ chức thứ 3 (FOT)	Quản lý tổ chức thứ 3 (FOT_MNG)
Quản lý (FOM)	Quản lý các tham số an toàn (FOM_PRM)
	Quản lý phân loại tài sản (FOM_CLS)
	Quản lý trách nhiệm an toàn nhân sự (FOM_PSN)
	Quản lý tổ chức an toàn (FOM_ORG)
	Quản lý báo cáo về an toàn (FOM_INC)

Bảng B.2 - Những phụ thuộc kiểm soát vận hành

FOD_PSN.1

FOD_PSN.3

FOD_PSN.5

FOD_PSM.1

FOD_ORG.1

FOD_ORG.2

FOS_POL.1

FOS_POL.4

FOS_NET.1

FOA_POL.3

FOM_PRM.2

FOM_INC.1

FOD_INC.1

FOS_SER.1

FOS_POL.1

FOS_PSN.1

FOS_OAS.1

FOA_INF.1

FOB_POL.1

FOB_BCN.1

FOP_MNG.1

FOT_MNG.1

FOM_PRM.1

FOM_PSN.1

FOM_ORG.2

B.2 Lớp FOD: Quản trị

Lớp này cung cấp các yêu cầu kiểm soát vận hành cho quản trị hệ thống vận hành.

B.2.1 Quản trị chính sách (FOD_POL)

B.2.1.1 Hành xử của họ

Họ này định nghĩa các chính sách an toàn hệ thống vận hành cho quản trị. Nó bao gồm đặc tả chính sách an toàn, diễn đàn quản lý an toàn và nhận xét an toàn và những biện pháp kiểm soát quản lý về vi phạm an toàn hệ thống vận hành.

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

FOD_POL.1 Chính sách an toàn. Kiểm soát quản lý, các mục tiêu và đối tượng của chính sách an toàn, nhận xét và những biện pháp kiểm soát quản lý đối với vi phạm an toàn được định nghĩa.

FOD_POL.2 Bảo vệ dữ liệu và chính sách riêng tư. Bảo vệ dữ liệu và chính sách riêng tư được xác định.

B.2.1.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) Đối với thành phần FOD_POL.1: Mô tả cam kết quản lý, chính sách an toàn, xem xét quản lý và những biện pháp kiểm soát quản lý đối với vi phạm an toàn bằng những đặc tả và hành động cụ thể.

b) Đối với thành phần FOD_POL.2: Mô tả bảo vệ dữ liệu và chính sách riêng tư.

B.2.1.4 FOD_POL.1 Chính sách an toàn

Những phụ thuộc: Không phụ thuộc.

FOD_POL.1.1 OSF định nghĩa [chỉ định: cam kết quản lý] mà quản lý sẽ hỗ trợ một cách tích cực vấn đề an toàn trong các tổ chức thông qua việc định hướng rõ ràng, những cam kết đã đưa ra, chỉ định rõ và công nhận trách nhiệm an toàn thông tin.

FOD_POL.1.2 OSF định nghĩa [chỉ định: chính sách an toàn thông tin] bao gồm các mục tiêu, mục đích, phạm vi, sự tuân thủ pháp luật, hợp đồng và những yêu cầu của các tiêu chuẩn, đánh giá rủi ro và quản lý rủi ro, đào tạo, giáo dục về an toàn thông tin, những yêu cầu về kiến thức, quản lý doanh nghiệp, hậu quả của những vi phạm chính sách an toàn thông tin và trách nhiệm của tổ chức và phương pháp tiếp cận để quản lý an toàn thông tin.

FOD_POL.1.3 OSF định nghĩa [chỉ định: các thủ tục chính thức] về xem xét quản lý bao gồm thông tin về những kết quả xem xét độc lập, kết quả xem xét quản lý trước đây, những thay đổi có thể làm ảnh hưởng đến phương pháp tiếp cận của tổ chức khi thực hiện quản lý an toàn thông tin, các khuyến nghị được các cơ quan liên quan cung cấp, những khuynh hướng liên quan đến các mối đe dọa và những điểm yếu, và những sự cố an toàn đã báo cáo như là nguồn đầu vào.

FOD_POL.1.4 OSF định nghĩa [chỉ định: chính sách nhân sự] trang bị phương tiện cho nhân viên được đào tạo lại về kiểm soát vận hành.

FOD_POL.1.5 OSF định nghĩa [chỉ định: những yêu cầu an toàn] đối với các phương tiện truyền thông hành động vi phạm những biện pháp kiểm soát vận hành mà sẽ xảy ra trước khi nhân viên được truy cập vào các tài sản hệ thống.

FOD_POL.1.6 OSF định nghĩa [chỉ định: chính sách nhân sự] đưa ra biện pháp để trừng phạt như phạt tiền, tước bỏ các đặc quyền, đình chỉ, xử phạt khi vi phạm những biện pháp kiểm soát vận hành.

FOD_POL.1.7 OSF định nghĩa [chỉ định: những yêu cầu an toàn] để cách chức, hạn chế hoặc đưa ra các hành động khác đối với người vi phạm do truy cập tài sản hệ thống cho đến khi có tiêu chuẩn phục hồi chức vụ.

FOD_POL.1.8 OSF định nghĩa [chỉ định: chính sách nhân sự] bằng cách đưa ra một biện pháp đã giới hạn nhân viên vi phạm các quy tắc và thủ tục theo sự cho phép của pháp luật.

FOD_POL.1.9 OSF định nghĩa [chỉ định: những yêu cầu an toàn] đối với tất cả những yêu cầu về luật, pháp lý và hợp đồng và phương pháp tiếp cận của tổ chức để đáp ứng các yêu cầu này và được cập nhật cho từng hệ thống thông tin và tổ chức.

FOD_POL.1.10 OSF định nghĩa [chỉ định: chính sách an toàn thông tin] là một tập hợp các thủ tục về xử lý và gắn nhãn thông tin được phát triển và được thực hiện phù hợp với lược đồ phân loại được tổ chức chấp nhận

FOD_POL.1.11 OSF định nghĩa [chỉ định: chính sách an toàn thông tin] mà phương pháp tiếp cận của tổ chức để quản lý an toàn thông tin và việc thực thi của nó (tức là những biện pháp kiểm soát những mục tiêu, chính sách, các quy trình và các thủ tục kiểm soát an toàn thông tin) được xem xét một cách độc lập tại những khoảng thời gian hoạch định hoặc khi có những thay đổi về việc thực hiện chính sách an toàn thông tin.

FOD_POL.1.12 OSF định nghĩa [chỉ định: chính sách an toàn thông tin] mà tất cả những yêu cầu an toàn thông tin đã xác định được ghi lại trước khi chuyển cho những người dùng truy cập thông tin hoặc tài sản của các tổ chức.

FOD_POL.1.13 OSF định nghĩa [chỉ định: chính sách an toàn thông tin] mà tài liệu về chính sách an toàn thông tin được chấp thuận bởi ban quản lý, được xuất bản và được truyền thông đến tất cả người dùng và các bên liên quan.

B.2.1.5 FOD_POL.2 Bảo vệ dữ liệu và chính sách riêng tư

Những phụ thuộc: Không phụ thuộc.

FOD_POL.2.1 OSF phát triển và thực hiện [chỉ định: bảo vệ dữ liệu và chính sách riêng tư].

B.2.2 Quản trị nhân sự [FOD_PSN)

B.2.2.1 Hành xử của họ

Họ này định nghĩa quản trị an toàn nhân sự trong hệ thống vận hành. Nó bao gồm đặc tả vai trò và trách nhiệm quản lý nhân sự, biện pháp kỷ luật, nội dung thỏa thuận nhân sự, quản lý định danh người dùng, kiểm soát tài sản và nhận thức an toàn thông tin, đào tạo và giáo dục về an toàn thông tin.

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

FOD_PSN.1 Vai trò và trách nhiệm của nhân viên. Trách nhiệm quản lý, trách nhiệm thực hiện qui trình hiện có. trách nhiệm pháp lý và kiểm soát an toàn đối với các nhân viên làm việc trong khu vực an toàn đã được xác định. Một quy trình kỷ luật chính thức được xác định. Điều khoản và điều kiện của hợp đồng và các quy tắc để ký thỏa thuận bí mật hoặc công khai đã được xác định. Các quy tắc giám sát hoặc người kiểm tra rõ ràng phải được xác định. Các quy tắc để nhận biết phạm vi chính xác của các phép truy cập được phép phải được xác định. Quy định về việc sử dụng có chấp nhận được và trả lại tài sản của tổ chức phải được xác định.

FOD_PSN.2 Nhận biết an toàn thông tin, đào tạo và giáo dục về an toàn thông tin. Những yêu cầu về nhận biết an toàn thông tin, đào tạo và giáo dục về an toàn thông tin được định nghĩa.

B.2.2.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOD_PSN.1: Mô tả trách nhiệm quản lý, trách nhiệm thực hiện quá trình hiện có, trách nhiệm pháp lý, kiểm soát an toàn đối với các nhân viên làm việc trong khu vực an toàn, quy trình kỷ luật chính thức với các hành động cụ thể, những đặc tả và những bản ghi hướng dẫn thực hiện hành động chính thức, điều khoản và điều kiện của hợp đồng chỉ định, các quy tắc để ký những thỏa thuận bí mật hoặc công khai, qui tắc hướng dẫn định danh người dùng, qui tắc nhận biết phạm vi chính xác của truy nhập được phép và các quy tắc liên quan đến việc sử dụng và trả lại tài sản của các tổ chức bằng những hành động và đặc tả cụ thể và các bản ghi hướng dẫn kiểm soát.

b) FOD_PSN.2: Các bản ghi hướng dẫn nhận biết an toàn thông tin, đào tạo và giáo dục về an toàn thông tin.

B.2.2.4 FOD_PSN.1 Vai trò và trách nhiệm của nhân viên

Những phụ thuộc: FOD_POL.1 Chính sách an toàn

FOD_RSM.1 Quản lý rủi ro trong các tổ chức

FOD_PSN.1.1 OSF định nghĩa và ghi lại [chỉ định: vai trò và trách nhiệm] của nhân viên, nhà thầu và tổ chức thứ 3 sử dụng phù hợp với chính sách an toàn thông tin của tổ chức.

FOD_PSN.1.2 OSF định nghĩa [chỉ định: trách nhiệm] để chấm dứt việc làm hoặc thay đổi việc làm.

FOD_PSN.1.3 OSF định nghĩa [chỉ định: những yêu cầu an toàn] đối với các yêu cầu an toàn hiện có, trách nhiệm pháp lý, những thỏa thuận về tính bí mật thông tin, điều khoản và điều kiện để tiếp tục trong khoảng thời gian xác định sau khi nhân viên, chủ hợp đồng hoặc người dùng tổ chức thứ 3 để thống nhất hoàn thành nhiệm vụ theo trách nhiệm của mình.

FOD_PSN.1.4 OSF định nghĩa [chỉ định: những yêu cầu an toàn] đối với nhân viên làm việc trong các khu vực an toàn.

FOD_PSN.1.5 OSF định nghĩa [chỉ định: những yêu cầu an toàn] mà các quyền truy cập thông tin của tất cả các nhân viên, nhà thầu và người sử dụng của tổ chức thứ 3 và thiết bị xử lý thông tin sẽ bị loại bỏ khi chấm dứt việc làm, hợp đồng hoặc thỏa thuận, hoặc điều chỉnh thay đổi.

FOD_PSN.1.6 OSF định nghĩa [chỉ định: những yêu cầu an toàn] đối với tất cả các nhân viên, nhà thầu và những người dùng của tổ chức thứ 3 phù hợp với những quy định, điều luật liên quan.

FOD_PSN.1.7 OSF định nghĩa [chỉ định: các thủ tục] để phát triển và tuân thủ khi thu thập và đưa ra bằng chứng và các mục đích của hành động kỷ luật đã được xử lý trong tổ chức.

FOD_PSN.1.8 OSF định nghĩa [chỉ định: những yêu cầu an toàn] và quá trình kỷ luật chính thức đối với nhân viên, nhà thầu và những người dùng của tổ chức thứ 3, những người mà đã cam kết về sự vi phạm an toàn thông tin.

FOD_PSN.1.9 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về các điều khoản và điều kiện của hợp đồng mà công bố: trách nhiệm của nhà thầu và trách nhiệm pháp lý của người dùng của tổ chức thứ ba và trách nhiệm của người lao động và quyền và trách nhiệm phân loại và quản lý dữ liệu của tổ chức được xử lý, phân loại và quản lý dữ liệu của tổ chức được xử lý bởi các nhân viên, nhà thầu và người dùng của tổ chức thứ 3, trách nhiệm của người sử dụng lao động là xử lý các thông tin cá nhân, bao gồm cả thông tin cá nhân được tạo ra như một kết quả hoặc khi có sự phân công của tổ chức, các trách nhiệm được mở rộng bên ngoài cơ sở của tổ chức và ngoài giờ làm việc bình thường và những hành động sẽ được thực hiện nếu nhân viên, nhà thầu hoặc thứ ba bên sử dụng không quan tâm đến yêu cầu an toàn của người sử dụng lao động đối với tất cả mọi người làm việc cho tổ chức, các nhân viên mới, nhà thầu và người sử dụng của tổ chức thứ 3. Trách nhiệm bao gồm cả điều khoản và điều kiện làm việc sẽ tiếp tục trong một thời gian xác định sau khi kết thúc nhiệm vụ.

FOD_PSN.1.10 OSF định nghĩa [chỉ định: các quy tắc] như là một phần nghĩa vụ hợp đồng, nhân viên, nhà thầu và bên thứ ba sử dụng đồng ý và ký tên của họ và trách nhiệm của tổ chức an toàn thông tin.

FOD_PSN.1.11 OSF định nghĩa [chỉ định: các quy tắc] để ký thỏa thuận đảm bảo không tiết lộ như một phần của điều khoản và điều kiện thuê người lao động trước khi được phép truy cập vào các phương tiện tham gia vào quá trình xử lý thông tin và những yêu cầu về thỏa thuận không tiết lộ nhu cầu của tổ chức về bảo vệ thông tin được xác định và xem xét thường xuyên.

FOD_PSN.1.12 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về thỏa thuận khi có sự thay đổi các điều khoản chỉ định, hợp đồng, đặc biệt là khi nhân viên rời khỏi tổ chức, hoặc khi hợp đồng kết thúc.

FOD_PSN.1.13 OSF định nghĩa [chỉ định: các quy tắc] là tất cả nhân viên phải đeo thẻ định danh có thể nhìn thấy được.

FOD_PSN.1.14 OSF định nghĩa [chỉ định: các quy tắc] không được truy cập vào các thiết bị của các tổ chức trừ khi có thẩm quyền.

FOD_PSN.1.15 OSF định nghĩa [chỉ định: các quy tắc] liên quan đến việc sử dụng thông tin và tài sản của các tổ chức.

CHÚ THÍCH. Tài sản của tổ chức bao gồm phần mềm đã phát hành, tài liệu của công ty, các thiết bị điện toán di động, thẻ tín dụng, thẻ truy cập, phần mềm, tài liệu hướng dẫn sử dụng và các thông tin được lưu trữ trên thiết bị điện tử.

FOD_PSN.1.16 OSF định nghĩa [chỉ định: các quy tắc] là tất cả các nhân viên và nhà thầu và người sử dụng tổ chức thứ 3 phải trả lại tất cả tài sản của tổ chức sở hữu của họ khi chấm dứt việc làm, chấm dứt hợp đồng hoặc thỏa thuận.

FOD_PSN.1.17 OSF định nghĩa [chỉ định: các quy tắc] là tất cả các nhân viên và nhà thầu và người sử dụng của tổ chức thứ 3 không đưa tài sản tổ chức ra khỏi tổ chức mà không được phép.

FOD_PSN.1.18 OSF định nghĩa [chỉ định: các quy tắc] mà các nhiệm vụ và vùng trách nhiệm được phân tách để giảm thiểu cơ hội hiệu chỉnh trái phép hoặc không có chủ ý hoặc sử dụng sai mục đích các tài sản của tổ chức.

FOD_PSN.1.19 OSF định nghĩa [chỉ định: những yêu cầu an toàn] và quá trình xử lý kỷ luật chính thức đối với nhân viên những người đã cam kết về sự vi phạm an toàn thông tin.

B.2.2.5 FOD_PSN.2 Nhận biết an toàn thông tin, đào tạo và giáo dục về an toàn thông tin

Những phụ thuộc: Không phụ thuộc.

FOD_PSN.2.1 OSF định nghĩa và ghi lại [chỉ định: những yêu cầu an toàn] mà tất cả các nhân viên của tổ chức, các nhà thầu và người sử dụng của tổ chức thứ 3 được đào tạo nâng cao nhận thức và cập nhật thường xuyên về các chính sách và thủ tục tổ chức, có liên quan đối với chức năng công việc của họ.

FOD_PSN.2.2 OSF định nghĩa và ghi lại [chỉ định: những yêu cầu an toàn] mà đào tạo nâng cao nhận thức sẽ bắt đầu bằng việc giới thiệu các chính sách bảo mật và những kỳ vọng của tổ chức trước khi tiếp cận thông tin và dịch vụ được chấp nhận.

FOD_PSN.2.3 OSF định nghĩa và ghi lại [chỉ định: những yêu cầu an toàn] mà việc đào tạo liên tục sẽ bao gồm các yêu cầu về an toàn, trách nhiệm pháp lý và kiểm soát nghiệp vụ, cũng như đào tạo việc sử dụng đúng các phương tiện tham gia vào quá trình xử lý thông tin, việc sử dụng các gói phần mềm và thông tin về quá trình xử lý kỷ luật.

B.2.3 Quản trị quản lý rủi ro (FOD_RSM)

B.2.3.1 Hành xử của họ

Họ này định nghĩa quản lý rủi ro đối với quản trị. Nó bao gồm quản lý rủi ro đối với các tổ chức và các tổ chức thứ 3 có liên quan.

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

FOD_RSM.1 Quản lý rủi ro trong các tổ chức. Các thủ tục quản lý rủi ro đối với các tổ chức được định nghĩa.

FOD_RSM.2 Quản lý rủi ro liên quan đến việc truy nhập tổ chức thứ 3. Các thủ tục quản lý rủi ro truy cập các tổ chức thứ 3 được định nghĩa.

B.2.3.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOD_RSM.1: Mô tả quản lý rủi ro đối với các tổ chức bằng các hành động cụ thể và các đặc tả, các bản ghi hướng dẫn quản lý rủi ro.

b) FOD.RSM.2: Mô tả quản lý rủi ro của tổ chức thứ 3 bằng các hành động cụ thể và các đặc tả, các bản ghi hướng dẫn quản lý rủi ro.

B.2.3.4 FOD_RSM.1 Quản lý rủi ro trong các tổ chức

Những phụ thuộc: Không phụ thuộc.

FOD_RSM.1.1 OSF định nghĩa [chỉ định: các thủ tục] về quản lý rủi ro các danh mục thông tin của tổ chức và các phương tiện tham gia vào quá trình xử lý thông tin, bao gồm cả nhân viên làm việc tại tổ chức và những người dùng từ xa hoặc người dùng di động khác.

FOD_RSM.1.2 OSF định nghĩa [chỉ định: những yêu cầu an toàn] để thực hiện quản lý rủi ro cho hệ thống vận hành bằng quy trình nghiệp vụ.

FOD_RSM.1.3 OSF định nghĩa [chỉ định: những yêu cầu an toàn] để thu thập thông tin kịp thời về những điểm yếu kỹ thuật của hệ thống thông tin đang được sử dụng, đánh giá việc tiếp xúc của tổ chức đến những điểm yếu và đưa ra những biện pháp thích hợp để giải quyết những rủi ro liên quan.

B.2.3.5 FOD_RSM.2 Quản lý rủi ro liên quan đến truy cập tổ chức thứ 3

Những phụ thuộc: Không phụ thuộc.

FOD_RSM.2.1 OSF định nghĩa [chỉ định: các thủ tục] về quản lý rủi ro các danh mục thông tin của tổ chức và các phương tiện tham gia vào quá trình xử lý thông tin mà các tổ chức thứ 3 sẽ truy cập phải lưu ý đến những biện pháp kiểm soát được sử dụng bởi các tổ chức thứ 3, những yêu cầu pháp lý và quy định tổ chức thứ 3 phải tính toán và những điều khoản hợp đồng mà tổ chức và các tổ chức thứ 3 cần phải tính đến.

FOD_RSM.2.2 OSF định nghĩa [chỉ định: các thủ tục] mà những rủi ro đối với thông tin của tổ chức và những phương tiện tham gia vào quá trình xử lý thông tin của các quá trình nghiệp vụ liên quan đến các tổ chức bên ngoài được xác định và những biện pháp kiểm soát thích hợp được thực hiện trước khi cấp quyền truy cập.

B.2.4 Quản trị quản lý sự cố (FOD_INC)

B.2.4.1 Hành xử của họ

Họ này định nghĩa quản lý sự cố về quản trị. Nó bao gồm đặc tả quản lý sự cố.

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

FOD_INC.1 Các sự cố bảo mật. Thủ tục báo cáo sự cố bảo mật chính thức, thủ tục quản lý sự cố và hoạt động khắc phục sự cố được định nghĩa.

B.2.4.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOD_INC.1: Mô tả thủ tục báo cáo sự cố bảo mật chính thức, thủ tục quản lý sự cố và hoạt động khắc phục sự cố bằng những đặc tả và hành động cụ thể và các bản ghi về những báo cáo sự cố bảo mật và quản lý của chúng.

B.2.4.4 FOD_INC.1 Những sự cố bảo mật

Những phụ thuộc FOM_INC.1 Báo cáo những vấn đề về an toàn đã được phát hiện

FOD_ORG.2 Trách nhiệm quản lý diễn đàn.

FOD_INC.1.1 OSF định nghĩa [chỉ định: các thủ tục] về báo cáo sự cố bảo mật chính thức cũng như thủ tục đối phó sự cố, đặt ra hành động thực hiện khi nhận được báo cáo sự cố.

FOD_INC.1.2 OSF quy định [chỉ định: những yêu cầu an toàn] về điểm liên hệ nơi mà mọi người muốn báo cáo sự cố có thể gọi đến.

FOD_INC.1.3 OSF định nghĩa [chỉ định: các thủ tục] về quản lý sự cố để xử lý các loại sự cố bảo mật tiềm ẩn, bao gồm những hư hỏng hệ thống, mất dịch vụ, virus và các hình thức khác của mã độc hại, từ chối dịch vụ, lỗi do dữ liệu nghiệp vụ không đầy đủ hoặc không chính xác, những vi phạm bảo mật, tính toàn vẹn, tính trách nhiệm, tính xác thực, độ tin cậy hoặc tính riêng tư, và lạm dụng hệ thống thông tin.

FOD_INC.1.4 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về hoạt động khôi phục thông tin do vi phạm về an toàn thông tin và hư hỏng hệ thống.

FOD_INC.1.5 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về báo cáo những lỗi do người dùng thông báo có liên quan đến các vấn đề xử lý thông tin hoặc liên quan đến các hệ thống thông tin liên lạc.

FOD_INC.1.6 OSF định nghĩa [chỉ định: các thủ tục] mà các sự cố bảo mật sẽ được báo cáo thông qua các kênh quản lý thích hợp càng nhanh càng tốt.

FOD_INC.1.7 OSF định nghĩa [chỉ định: các quy tắc] để đảm bảo rằng tất cả những người lao động, nhà thầu và những người dùng các dịch vụ và hệ thống thông tin của tổ chức thứ 3 thành thạo thủ tục về báo cáo sự cố an toàn và biết được điểm liên hệ khi có sự cố.

FOD_INC.1.8 OSF định nghĩa [chỉ định: các quy tắc] mà tất cả những người lao động, nhà thầu và những người dùng các dịch vụ và hệ thống thông tin của tổ chức thứ 3 được yêu cầu ghi lại và báo cáo bất kỳ điểm yếu bảo mật nào quan sát được hoặc có nghi ngờ trong các hệ thống hoặc trong các dịch vụ.

FOD_INC.1.9 OSF định nghĩa [chỉ định: những trách nhiệm và các thủ tục] về quản lý để đảm bảo việc chống lại những sự cố về bảo mật thông tin một cách nhanh chóng, hiệu quả và có thứ tự.

FOD_INC.1.10 OSF định nghĩa [chỉ định: những cơ chế] để cho phép các loại sự cố bảo mật thông tin, số lượng sự cố bảo mật thông tin và chi phí các sự cố về bảo mật thông tin được xác định và được giám sát.

FOD_INC.1.11 OSF định nghĩa [chỉ định: những yêu cầu an toàn] khi mà một hành động tiếp theo của một người hoặc một tổ chức sau khi sự cố an toàn thông tin Iiên quan đến hành động pháp lý (hoặc dân sự hoặc hình sự), bằng chứng được thu thập, được lưu giữ và được trình bày thích hợp với các qui tắc, bằng chứng xác nhận những quyền thực thi pháp lý liên quan.

B.2.5 Quản trị an toàn tổ chức (FOD_ORG)

B.2.5.1 Hành xử của họ

Họ này định nghĩa quản trị của tổ chức an toàn. Nó bao gồm đặc tả diễn đàn quản lý.

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

FOD_ORG.1 Trách nhiệm phối hợp an toàn thông tin. Trách nhiệm phối hợp an toàn thông tin được định nghĩa.

FOD_ORG.2 Trách nhiệm quản lý diễn đàn an toàn thông tin. Trách nhiệm quản lý diễn đàn an toàn thông tin được định nghĩa.

B.2.5.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOD_ORG.1: Mô tả trách nhiệm phối hợp an toàn thông tin bằng những đặc tả và hành động cụ thể.

b) FOD_ORG.2: Mô tả trách nhiệm quản lý diễn đàn an toàn thông tin bằng những đặc tả về những hành động cụ thể.

B.2.5.4 FOD_ORG.1 Trách nhiệm phối hợp an toàn thông tin

Những phụ thuộc: Không phụ thuộc.

FOD_ORG.1.1 OSF định nghĩa (chỉ định: những trách nhiệm] mà những hoạt động an toàn thông tin được phối hợp bởi những người đại diện từ các bộ phận khác nhau của tổ chức có chức năng công việc và vai trò liên quan.

FOD_ORG.1.2 OSF định nghĩa [chỉ định: những yêu cầu an toàn] duy trì những mối liên hệ với những người có thẩm quyền liên quan.

FOD_ORG.1.3 OSF định nghĩa [chỉ định: những yêu cầu an toàn] duy trì những mối liên hệ với các nhóm có chung lợi ích hoặc chuyên gia của các diễn đàn và những hiệp hội chuyên nghiệp.

B.2.5.5 FOD_ORG.2 Trách nhiệm quản lý diễn đàn an toàn thông tin

Những phụ thuộc: Không phụ thuộc.

FOD_ORG.2.1 OSF định nghĩa [chỉ định: những trách nhiệm] đối với một diễn đàn quản lý an toàn thông tin để giải quyết các vấn đề an toàn thông tin.

FOD_ORG.2.2 OSF định nghĩa [chỉ định: những yêu cầu] đối với diễn đàn quản lý an toàn thông tin để đảm bảo rằng các hoạt động về an toàn thông tin được thực hiện phù hợp với chính sách an toàn thông tin; phê chuẩn các phương pháp luận và các quy trình an toàn thông tin, đánh giá an toàn thông tin, phân loại thông tin, xác định mối đe dọa làm thay đổi hoặc làm lộ thông tin và những phương tiện tham gia vào quá trình xử lý thông tin đối với những mối đe dọa và đánh giá đầy đủ và phối hợp thực hiện những biện pháp kiểm soát an toàn thông tin.

B.2.6 Quản trị những thỏa thuận dịch vụ (FOD_SER)

B.2.6.1 Hành xử của họ

Họ này định nghĩa những thỏa thuận dịch vụ và quản trị an toàn. Nó bao gồm đặc tả những yêu cầu an toàn các dịch vụ mạng.

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

FOD_SER.1 Những thỏa thuận về các dịch vụ mạng. Các đặc tính an toàn, các mức dịch vụ, và những yêu cầu quản lý các dịch vụ mạng được định nghĩa.

B.2.6.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOD_SER.1: Mô tả các tính năng an toàn, các mức dịch vụ và các yêu cầu về quản lý các dịch vụ mạng bằng những đặc tả và những hành động cụ thể.

B.2.6.4 FOD_SER.1 Những thỏa thuận và dịch vụ mạng

Những phụ thuộc: FOS_NET.1 Các dịch vụ mạng.

FOD_SER.1.1 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về định danh các tính năng an toàn, các mức dịch vụ và các yêu cầu về quản lý của tất cả các dịch vụ mạng.

FOD_SER.1.2 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về khả năng của nhà cung cấp dịch vụ mạng để quản lý những dịch vụ đã thỏa thuận theo một cách an toàn và thỏa thuận về quyền đối với đánh giá.

FOD_SER.1.3 OSF thiết lập [chỉ định: những thỏa thuận] và trao đổi thông tin và phần mềm giữa tổ chức với các tổ chức bên ngoài.

B.3 Lớp FOS: Các hệ thống công nghệ thông tin

Lớp này cung cấp các yêu cầu kiểm soát vận hành cho các hệ thống CNTT trong hệ thống vận hành.

B.3.1 Chính sách đối với các hệ thống CNTT (FOS_POL)

B.3.1.1 Hành xử của họ

Họ này định nghĩa các chính sách an toàn cho các hệ thống CNTT trong các hệ thống vận hành. Nó bao gồm đặc tả các yêu cầu an toàn, kiểm soát thay đổi, kiểm soát mã độc hại và mật mã.

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

FOS_POL.1 Những yêu cầu an toàn. Cập nhật các thủ tục quản lý và định danh những thay đổi, kiểm soát thay đổi và giới thiệu hệ thống thay đổi được định nghĩa.

FOS_POL.2 Chính sách mã độc hại. Các thủ tục quản lý để xử lý mã độc hại được định nghĩa.

FOS_POL.3 Chính sách mã di động. Các thủ tục quản lý để xử lý mã di động được định nghĩa.

FOS_POL.4 Chính sách mật mã. Các thủ tục sử dụng các kỹ thuật mật mã, các thủ tục quản lý đối với các khóa mật mã được định nghĩa.

FOS_POL.5 Các hệ thống công cộng. Các thủ tục bảo vệ đối với hệ thống công cộng được định nghĩa.

B.3.1.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOS_POL.1: Mô tả các yêu cầu an toàn và kiểm soát thay đổi bằng những đặc tả và những hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

b) FOS_POL.2: Mô tả các thủ tục quản lý để xử lý mã độc hại bằng những đặc tả và những hành động cụ thể và các bản ghi hướng dẫn kiểm soát mã độc hại.

c) FOS_POL.3: Mô tả các thủ tục quản lý để xử lý mã di động bằng những đặc tả và những hành động cụ thể và các bản ghi hướng dẫn kiểm soát mã di động.

d) FOS_POL.4: Mô tả chính sách sử dụng các kỹ thuật mật mã và các bản ghi hướng dẫn kiểm soát mật mã.

e) FOS_POL.5: Mô tả các thủ tục bảo vệ hệ thống công cộng bằng những đặc tả và những hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

B.3.1.4 FOS_POL.1 Các yêu cầu an toàn

Những phụ thuộc: FOM_PRM.2 Phân bố đặc quyền.

FOS_POL.1.1 OSF định nghĩa [chỉ định: các thủ tục] cho một qui trình quản lý nâng cấp phần mềm để đảm bảo những nâng cấp ứng dụng và các bản vá lỗi được phê duyệt mới nhất được cài đặt cho tất cả các phần mềm đã được ủy quyền.

FOS_POL.1.2 OSF định nghĩa [chỉ định: các thủ tục] về định danh những thay đổi đối với những phương tiện tham gia vào quá trình xử lý thông tin và các hệ thống và đánh giá những tác động tiềm ẩn.

FOS_POL.1.3 OSF định nghĩa [chỉ định: các thủ tục) đối với kiểm soát thay đổi chính thức để kiểm soát việc thực hiện những thay đổi đối với những phương tiện tham gia vào quá trình xử lý thông tin và các hệ thống.

FOS_POL.1.4 OSF định nghĩa [chỉ định: các thủ tục] về lưu giữ và sao chép các thư viện mã nguồn chương trình phù hợp với kiểm soát thay đổi.

FOS_POL.1.5 OSF định nghĩa [chỉ định: các thủ tục] đối với các hệ thống thông tin mà thường xuyên được kiểm tra việc tuân thủ các tiêu chuẩn thực hiện an toàn.

FOS_POL.1.6 OSF cần định rõ [chỉ định: những biện pháp kiểm soát an toàn] về những báo cáo yêu cầu nghiệp vụ cho các hệ thống thông tin mới, hoặc cải tiến các hệ thống thông tin hiện có.

FOS_POL.1.7 OSF định nghĩa [chỉ định: các thủ tục] để kiểm soát việc cài đặt phần mềm trên các hệ thống vận hành.

FOS_POL.1.8 OSF định nghĩa [chỉ định: các thủ tục] khi mà hệ thống vận hành được thay đổi, các ứng dụng nghiệp vụ quan trọng được xem xét và kiểm tra để đảm bảo không có ảnh hưởng xấu đến hoạt động an toàn của tổ chức.

FOS_POL.1.9 OSF định nghĩa [chỉ định: các quy tắc] mà những hiệu chỉnh đối với các gói phần mềm không được khuyến khích, hạn chế những thay đổi cần thiết, và tất cả các thay đổi được kiểm soát chặt chẽ.

FOS_POL.1.10 OSF sẽ ghi lại, duy trì và thực hiện [chỉ định: các thủ tục] cho tất cả người dùng cần đến chúng.

B.3.1.5 FOS_POL.2 Chính sách mã độc hại

Những phụ thuộc: Không phụ thuộc.

FOS_POL.2.1 OSF định nghĩa [chỉ định: các thủ tục] về quản lý để xử lý mã độc hại bảo vệ các hệ thống, báo cáo và phục hồi thông tin từ những cuộc tấn công của các mã độc hại.

FOS_POL.2.2 OSF định nghĩa [chỉ định: các thủ tục] để phát hiện và bảo vệ chống lại các mã độc hại mà có thể được truyền đi thông qua việc sử dụng các phương tiện truyền thông.

FOS_POL.2.3 OSF định nghĩa [chỉ định: những trách nhiệm] để xử lý mã độc hại bảo vệ các hệ thống, đào tạo việc sử dụng, báo cáo và phục hồi thông tin từ những cuộc tấn công của mã độc hại.

FOS_POL.2.4 OSF định nghĩa [chỉ định: các thủ tục] phát hiện, phòng ngừa, phục hồi và kiểm soát để bảo vệ chống lại các mã độc hại và nhận thức người dùng.

B.3.1.6 FOS_POL.3 Chính sách mã di động

Những phụ thuộc: Không phụ thuộc.

FOS_POL.3.1 OSF định nghĩa [chỉ định: các thủ tục] về quản lý để cho phép việc sử dụng mã di động.

FOS_POL.3.2 SSF định nghĩa [chỉ định: những yêu cầu an toàn] đối với cấu hình của mã di động để đảm bảo rằng mã di động đã được cấp phép hoạt động theo một chính sách bảo mật đã được xác định rõ ràng, và để đảm bảo rằng mã di động không được cấp phép bị ngăn cấm thực hiện.

B.3.1.7 FOS_POL.4 Chính sách mật mã

Những phụ thuộc: Không phụ thuộc.

FOS_POL.4.1 OSF định nghĩa [chỉ định: chính sách mật mã] về việc sử dụng những biện pháp kiểm soát mật mã để bảo vệ các thông tin phù hợp với các thỏa thuận, pháp luật và các quy định liên quan.

FOS_POL.4.2 OSF định nghĩa [chỉ định: chính sách mật mã] về việc sử dụng những biện pháp kiểm soát mật mã để bảo vệ thông tin.

FOS_POL.4.3 OSF định nghĩa [chỉ định: các thủ tục] về quản lý khóa để hỗ trợ việc sử dụng các kỹ thuật mật mã của tổ chức.

FOS_POL.4.4 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về Tư vấn pháp luật trước khi thông tin mật mã hoặc kiểm soát mật mã được chuyển đến một vùng khác

FOS_POL.4.5 SSF cung cấp [chỉ định: những biện pháp kiểm soát] mà bất kỳ khóa mã liên quan được kết hợp với các tập nén được mật mã hoặc chữ ký số được lưu giữ một cách an toàn và có sẵn cho những người có thẩm quyền khi họ cần đến.

B.3.1.8 FOS_POL.5 Các hệ thống công cộng

Những phụ thuộc: Không phụ thuộc.

FOS_POL.5.1 SSF cung cấp [chỉ định: những biện pháp kiểm soát] để bảo vệ các phần mềm, dữ liệu và các thông tin khác đòi hỏi phải có mức toàn vẹn cao đang được thực hiện có sẵn trong hệ thống công cộng.

FOS_POL.5.2 OSF cung cấp [chỉ định: những yêu cầu an toàn] đối với hệ thống truy cập công cộng được kiểm thử chống lại những điểm yếu và những hư hỏng trước khi thông tin sử dụng được.

FOS_POL.5.3 SSF cung cấp [chỉ định: những yêu cầu an toàn] mà có một qui trình phê duyệt chính thức trước khi thông tin có hiệu lực.

FOS_POL.5.4 SSF cung cấp [chỉ định: những yêu cầu an toàn] mà tất cả đầu vào được cung cấp từ bên ngoài hệ thống được thẩm tra và được chấp thuận.

B.3.2 Cấu hình các hệ thống CNTT (FOS_CNF)

B.3.2.1 Hành xử của họ

Họ này định nghĩa cấu hình của hệ thống CNTT. Nó bao gồm việc tách môi trường vận hành và phát triển, và cấu hình hệ thống.

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

FOS_CNF.1 Phân tách tình trạng phát triển và môi trường vận hành. Phân tách tình trạng phát triển và môi trường vận hành và kiểm soát truy cập được định nghĩa.

FOS_CNF.2 Cấu hình hệ thống. Quản lý tài nguyên được chia sẻ và cấu hình hệ thống được định nghĩa.

B.3.2.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOS_CNF.1: Mô tả việc phân tách môi trường vận hành và phát triển bằng những đặc tả và những hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

b) FOS_CNF.2: Mô tả việc quản lý tài nguyên được chia sẻ và cấu hình hệ thống bằng những đặc tả và những hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

B.3.2.4 FOS_CNF.1 Phân tách môi trường vận hành và phát triển

Những phụ thuộc: Không phụ thuộc.

FOS_CNF.1.1 OSF định nghĩa [chỉ định: các quy tắc] về mức phân tách cần thiết giữa môi trường vận hành, kiểm thử và môi trường phát triển, để ngăn ngừa các vấn đề vận hành.

FOS_CNF.1.2 OSF định nghĩa [chỉ định: các quy tắc] về việc chuyển giao phần mềm từ trạng thái phát triển đến trạng thái vận hành.

FOS_CNF.1.3 SSF cung cấp [chỉ định: những biện pháp] kiểm soát truy cập áp dụng cho các hệ thống ứng dụng vận hành, kiểm thử các hệ thống ứng dụng để bảo vệ dữ liệu vận hành.

FOS_CNF.1.4 SSF cung cấp [chỉ định: những biện pháp kiểm soát] hạn chế nhân viên hỗ trợ CNTT truy cập vào thư viện mã nguồn chương trình.

FOS_CNF.1.5 OSF định nghĩa [chỉ định: các quy tắc] phát triển và vận hành phần mềm chạy trên hệ thống khác nhau hoặc bộ vi xử lý khác nhau.

FOS_CNF.1.6 OSF định nghĩa [chỉ định: các quy tắc] khi thông tin vận hành được sao chép đến một hệ thống ứng dụng kiểm thử.

B.3.2.5 FOS_CNF.2 Cấu hình hệ thống

Những phụ thuộc: Không phụ thuộc.

FOS_CNF.2.1 OSF định nghĩa [chỉ định: các quy tắc] tách các nhóm dịch vụ thông tin, người dùng và hệ thống thông tin trên các mạng lưới.

FOS_CNF.2.2 Khi một ứng dụng nhạy cảm chạy trên một môi trường được chia sẻ, OSF định nghĩa [chỉ định: các quy tắc] định danh các hệ thống ứng dụng mà nó sẽ chia sẻ tài nguyên với chủ sở hữu của các ứng dụng nhạy cảm.

FOS_CNF.2.3 OSF định nghĩa [chỉ định: các quy tắc] mà các hệ thống nhạy cảm có môi trường tính toán chuyên dụng (tách biệt).

B.3.3 An toàn mạng của các hệ thống CNTT (FOS_NET)

B.3.3.1 Hành xử của họ

Họ này định nghĩa an toàn mạng của các hệ thống CNTT. Nó bao gồm đặc tả an toàn mạng và các dịch vụ mạng.

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

FOS_NET.1 Các dịch vụ mạng. Các dịch vụ mạng và truy cập của nó được định nghĩa.

FOS_NET.2 An toàn mạng lưới. Bảo vệ các mạng lưới, an toàn thông tin trong các mạng, tính bảo mật và tính toàn vẹn của dữ liệu truyền được định nghĩa.

B.3.3.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOS_NET.1: Mô tả các dịch vụ mạng bằng những đặc tả và những hành động cụ thể và các bản ghi dựa trên việc truy cập mạng.

b) FOS_NET.2: Mô tả bảo vệ các mạng, an toàn thông tin trên mạng bằng những đặc tả và những hành động cụ thể và các bản ghi dựa trên việc kiểm soát.

B.3.3.4 FOS_NET.1 Các dịch vụ mạng

Những phụ thuộc: Không phụ thuộc.

FOS_NET.1.1 OSF định nghĩa [chỉ định: các quy tắc] cho các mạng và các dịch vụ mạng được phép truy cập, các thủ tục ủy quyền để xác định ai được phép truy cập các mạng và các dịch vụ mạng.

B.3.3.5 FOS_NET.2 An toàn mạng

Những phụ thuộc: Không phụ thuộc.

FOS_NET.2.1 SSF cung cấp [chỉ định: những biện pháp kiểm soát] để shut down các phiên không hoạt động tại các vị trí rủi ro cao sau một thời gian được xác định không hoạt động.

FOS_NET.2.2 SSF cung cấp [chỉ định: những biện pháp kiểm soát] để xóa màn hình thiết bị đầu cuối và đóng cả phiên ứng dụng và phiên mạng lưới sau một thời gian được xác định không hoạt động trên time-out facility.

FOS_NET.2.3 SSF cung cấp [chỉ định: những biện pháp kiểm soát] để hạn chế thời gian kết nối để thiết lập an toàn cho các ứng dụng có nguy cơ rủi ro cao.

FOS_NET.2.4 SSF cung cấp [chỉ định: những biện pháp] để liên kết các quyền truy cập mạng trước thời điểm nào đó trong ngày hoặc các ngày.

FOS_NET.2.5 SSF cung cấp [chỉ định: những biện pháp kiểm soát] để phân tách các nhóm dịch vụ thông tin, người dùng, và các hệ thống thông tin trên các mạng.

FOS_NET.2.6 SSF cung cấp [chỉ định: những biện pháp kiểm soát] để hạn chế khả năng của người dùng nối mạng với các mạng được chia sẻ, đặc biệt là các mạng đó mở rộng các biên của tổ chức, phù hợp với chính sách kiểm soát truy cập và các yêu cầu của các ứng dụng nghiệp vụ.

FOS_NET.2.7 SSF cung cấp [chỉ định: những biện pháp kiểm soát] để định tuyến cho các mạng để đảm bảo rằng các kết nối máy tính và các luồng thông tin không vi phạm các chính sách kiểm soát truy cập của các ứng dụng nghiệp vụ.

B.3.4 Giám sát các hệ thống CNTT (FOS_MON)

B.3.4.1 Hành xử của họ

Lớp này định nghĩa việc giám sát các hệ thống CNTT. Nó bao gồm đặc tả các nhật ký đánh giá, tư vấn pháp luật, những yêu cầu cảnh báo và những yêu cầu giám sát.

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

FOS_MON.1 Các nhật ký đánh giá. Các yêu cầu về đánh giá, quản lý việc đánh giá, tạo thông tin đánh giá, thông tin được ghi lại trong log và phải xác định việc người quản trị hệ thống ghi lại số liệu.

FOS_MON.2 Tư vấn pháp luật. Tư vấn pháp luật trước khi thực hiện các thủ tục giám sát được định nghĩa.

FOS_MON.3 Những yêu cầu cảnh báo. Những thiết lập các tham số cảnh báo và đáp ứng cảnh báo được định nghĩa.

FOS_MON.4 Giám sát sử dụng hệ thống. Giám sát sử dụng hệ thống được định nghĩa.

B.3.4.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOS_MON.1: Mô tả các thủ tục tạo các nhật ký đánh giá bằng những đặc tả và hành động cụ thể và các bản ghi của các nhật ký đánh giá chi tiết.

b) FOS_MON.2: Mô tả tư vấn pháp luật bằng những đặc tả và hành động cụ thể.

c) FOS MON.3: Mô tả những cài đặt tham số cảnh báo và các bản ghi đáp ứng cảnh báo bằng những đặc tả và những hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

d) FOS_MON.4: Mô tả các thủ tục xem xét các hoạt động giám sát bằng những đặc tả và những hành động cụ thể và các bản ghi hướng dẫn việc xem xét.

B.3.4.4 FOS_MON.1 Nhật ký đánh giá

Những phụ thuộc: Không phụ thuộc.

FOS_MON.1.1 OSF lập kế hoạch [chỉ định: những yêu cầu an toàn] về đánh giá và các hoạt động liên quan đến kiểm tra trên hệ thống vận hành và thỏa thuận để giảm thiểu nguy cơ gián đoạn trong quá trình nghiệp vụ.

FOS_MON.1.2 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về đánh giá bằng quản lý thích hợp.

FOS_MON.1.3 SSF cần đưa ra [chỉ định: việc ghi số liệu] của người quản trị hệ thống và các hoạt động người vận hành hệ thống. Các log bao gồm thời gian mà một sự việc hoặc hư hỏng xảy ra, thông tin về các sự việc hoặc hư hỏng và người quản trị hoặc điều hành hệ thống đã tham gia, tất cả thay đổi đến thiết bị, phần mềm hoặc các thủ tục.

FOS_MON.1.4 OSF định nghĩa [chỉ định: các quy tắc] để ghi lại thiết bị đã đăng xuất và đăng nhập trở lại.

FOS_MON.1.5 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về việc logging của sao chép và sử dụng thông tin vận hành để cung cấp một dấu vết đánh giá.

FOS_MON.1.6 OSF định nghĩa [chỉ định: các thủ tục] về việc tập hợp những dấu vết đánh giá và bằng chứng tương tự.

FOS_MON.1.7 OSF định nghĩa [chỉ định: những yêu cầu an toàn] để ghi lại một bản ghi về việc di dời tất cả các phương tiện có thể di dời khỏi tổ chức để duy trì dấu vết đánh giá.

FOS_MON.1.8 OSF thiết lập [chỉ định: các thủ tục] để giám sát việc sử dụng những phương tiện tham gia vào quá trình xử lý thông tin và xem xét kết quả giám sát một cách thường xuyên.

FOS_MON.1.9 SSF cung cấp (chỉ định: những biện pháp an toàn] để bảo vệ các tài sản logging và thông tin log khỏi sự can thiệp và truy nhập trái phép.

FOS_MON.1.10 SSF cần đưa ra (chỉ định: các thủ tục] để ghi lại các lỗi, phân tích lỗi và đưa ra hành động thích hợp.

B.3.4.5 FOS_MON.2 Tư vấn pháp luật

Những phụ thuộc: Không phụ thuộc.

FOS_MON.2.1 OSF định nghĩa [chỉ định: các quy tắc] để đưa ra tư vấn pháp luật trước khi thực hiện các thủ tục giám sát.

B.3.4.6 FOS_MON.3 Những yêu cầu cảnh báo

Những phụ thuộc: Không phụ thuộc.

FOS_MON.3.1 SSF cung cấp [chỉ định: những biện pháp] để cảnh báo các hệ thống vận hành.

FOS_MON.3.2 SSF cung cấp [chỉ định: những khả năng] để thiết lập các tham số cảnh báo, định nghĩa trước các sự kiện cảnh báo và những thay đổi cảnh báo của những thiết lập cảnh báo của hệ thống vận hành.

FOS_MON.3.3 OSF định nghĩa (chỉ định: các quy tắc và các thủ tục) mà được xác định để thực hiện khi nhận được những cảnh báo và những hoạt động cần thiết, kể cả những ràng buộc về thời gian, những người có trách nhiệm và báo cáo.

B.3.4.7 FOS_MON.4 Giám sát sử dụng hệ thống

Những phụ thuộc: Không phụ thuộc.

FOS_MON.4.1 OSF cung cấp [chỉ định: các thủ tục] để giám sát việc sử dụng những phương tiện tham gia vào quá trình xử lý thông tin và xem xét lại kết quả các hoạt động giám sát.

FOS_MON.4.2 OSF định nghĩa [chỉ định: những yêu cầu an toàn] mà mức giám sát được quy định cho các tài sản cá nhân được xác định bằng định giá rủi ro.

B.3.5 Kiểm soát nhân sự của các hệ thống CNTT (FOS_PSN)

B.3.5.1 Hành xử của họ

Họ này định nghĩa những biện pháp kiểm soát nhân sự cho các hệ thống CNTT. Nó bao gồm đặc tả xác thực người dùng, mã độc hại, các thiết bị và sử dụng hệ thống.

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

FOS_PSN.1 Xác thực người dùng. Đăng ký tài khoản người dùng, xác thực người dùng và các các quy tắc để giữ cho thông tin xác thực như password bảo mật được định nghĩa.

FOS_PSN.2 Sử dụng hệ thống. Các thủ tục để chấm dứt các phiên kích hoạt được định nghĩa.

B.3.5.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOS_PSN.1: Mô tả đăng ký người dùng, xác thực người dùng và các quy tắc để giữ thông tin xác thực bảo mật bằng những đặc tả và hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

b) FOS_PSN.2: Mô tả các thủ tục để chấm dứt các phiên kích hoạt bằng những đặc tả và hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

B.3.5.4 FOS_PSN.1 Xác thực người dùng

Những phụ thuộc: FOM_PRM.2 Phân tách đặc quyền

FOD_PSN.1 Vai trò và trách nhiệm của nhân viên

FOD_PSN.3 Thỏa thuận nhân sự

FO5_PSN.1.1 OSF định nghĩa [chỉ định: các thủ tục] về việc đăng ký và đăng ký lại người dùng chính thức để cấp và thu hồi quyền truy cập vào tất cả các hệ thống và dịch vụ thông tin

FOS_PSN.1.2 OSF định nghĩa [chỉ định: các thủ tục] mà bao gồm việc sử dụng các ID người dùng duy nhất để người dùng có thể được liên kết với và chịu trách nhiệm về hành động của mình (sử dụng ID nhóm chỉ nên được cho phép nếu phù hợp với công việc được thực hiện), kiểm tra xem người dùng có sự cho phép của chủ sở hữu hệ thống để sử dụng hệ thống đã yêu cầu hoặc dịch vụ bằng các thủ tục kiểm soát truy cập trong quá trình đăng ký và đăng ký lại người dùng.

FOS_PSN.1.3 OSF định nghĩa [chỉ định: các thủ tục] mà đưa ra thông tin xác thực tạm thời theo định danh tích cực của người dùng khi người dùng quên hoặc làm mất thông tin xác thực của họ. Thông tin xác thực tạm thời được đưa đến cho người dùng một cách an toàn

FOS_PSN.1.4 OSF định nghĩa [chỉ định: các quy tắc] để tránh mất hoặc làm hư hại các thông tin xác thực, ví dụ, tránh lưu giữ hồ sơ về những mật khẩu trừ khi hồ sơ này có thể được lưu trữ an toàn, lựa chọn mật khẩu có chất lượng có đầy đủ độ dài tối thiểu, mật khẩu này không được dựa trên bất cứ điều gì mà người khác có thể dễ dàng đoán được hoặc sử dụng thông tin cá nhân liên quan để đặt mật khẩu, thay đổi mật khẩu thường xuyên hoặc dựa trên số lần truy cập và tránh sử dụng lại hoặc quay lại dùng mật khẩu cũ, thay đổi mật khẩu tạm thời ngay lần đầu tiên đăng nhập, không để mật khẩu trong quá trình đăng nhập tự động và không chia sẻ mật khẩu người dùng cá nhân.

POS_PSN.1.5 OSF định nghĩa [chỉ định: các quy tắc] ký một cam kết để tránh làm mất, hư hại hoặc dùng sai mục đích các thông tin xác thực, ví dụ, giữ mật khẩu cá nhân bí mật và mật khẩu nhóm làm việc chỉ các thành viên của nhóm mới được biết.

FOS_PSN.1.6 SSF cung cấp [chỉ định: những biện pháp] cung cấp cho người dùng thông tin xác thực tạm thời an toàn mà họ buộc phải thay đổi hoặc xác nhận ngay lập tức.

FOS_PSN.1.7 OSF định nghĩa [chỉ định: các quy tắc] mà thông tin xác thực người dùng không bao giờ được lưu trữ trên hệ thống máy tính trong một biểu mẫu không được bảo vệ

FOS_PSN.1.8 OSF định nghĩa [chỉ định: qui trình quản lý chính thức] để kiểm soát việc phân bổ dữ liệu xác thực cho người dùng

B.3.5.5 FOS_PSN.2 Sử dụng hệ thống

Những phụ thuộc: Không phụ thuộc.

FOS_PSN.2.1 OSF định nghĩa [chỉ định: các thủ tục] để chấm dứt các phiên kích hoạt khi đã kết thúc, trừ khi chúng có thể được đảm bảo bằng một cơ chế khóa thích hợp.

FOS_PSN.2.2 OSF định nghĩa [chỉ định: các thủ tục] để đăng xuất các siêu máy tính, máy chủ và máy tính văn phòng khi kết thúc phiên.

FOS_PSN.2.3 OSF định nghĩa [chỉ định: các quy tắc] để sử dụng hồ sơ người dùng khác nhau cho các hệ thống vận hành và các hệ thống thử nghiệm hệ thống và các trình đơn.

FOS_PSN.2.4 OSF định nghĩa [chỉ định: các quy tắc] không được dời khỏi máy tính cá nhân và thiết bị đầu cuối máy tính và máy in đã đăng nhập khi chúng không được giám sát và bảo vệ bằng khóa phím, mật khẩu, hoặc những biện pháp kiểm soát khác khi không sử dụng.

B.3.6 Tài sản hệ thống vận hành của các hệ thống CNTT (FOS_OAS)

B.3.6.1 Hành xử của họ

Họ này định nghĩa sự an toàn của các tài sản vận hành của các hệ thống CNTT. Nó bao gồm đặc tả bảo vệ các tài sản vận hành, chương trình hệ thống, thông tin sao lưu và xác thực.

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

FOS_OAS.1 Bảo vệ tài sản vận hành. Xóa các thông tin vận hành, kiểm soát truy cập và lưu giữ an toàn các tài liệu hệ thống được định nghĩa. Tiêu chí chấp nhận các hệ thống mới, các quy tắc sử dụng các chương trình tiện ích, thủ tục thẩm định quyền đối với các tiện ích hệ thống, thủ tục cập nhật phần mềm vận hành, các quy tắc không sử dụng phần mềm không được cấp phép và trách nhiệm bám sát các nhà cung cấp phát hành bản vá lỗi được định nghĩa.

FOS_OAS.2 Các thủ tục sao lưu. Các thủ tục để sao lưu các bản sao của thông tin và phần mềm được định nghĩa.

B.3.6.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây:

a) FOS_OAS.1: Mô tả việc xóa thông tin vận hành, kiểm soát truy cập và lưu giữ an toàn các tài liệu hệ thống bằng những hành động và đặc tả cụ thể và các bản ghi hướng dẫn kiểm soát. Mô tả tiêu chí chấp nhận các hệ thống mới, các quy tắc sử dụng các chương trình tiện ích, các thủ tục xác thực cho các tiện ích hệ thống, các thủ tục cập nhật phần mềm vận hành, các quy tắc không sử dụng phần mềm không được cấp phép và trách nhiệm bám sát các nhà cung cấp phát hành bản vá lỗi bằng những đặc tả và những hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

b) FOS_OAS.2: Mô tả các thủ tục để sao lưu các bản sao của thông tin và phần mềm bằng những đặc tả và những hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

B.3.6.4 FOS_OAS.1 Bảo vệ tài sản vận hành

Những phụ thuộc: FOS_POL.1 Các yêu cầu an toàn

FOS_OAS.1.1 OSF định nghĩa [chỉ định: các quy tắc] để xóa các thông tin vận hành khỏi hệ thống ứng dụng thử nghiệm ngay sau khi việc thử nghiệm hoàn tất.

FOS_OAS.1.2 OSF định nghĩa [chỉ định: những yêu cầu an toàn] để kiểm soát các danh sách chương trình trong một môi trường đảm bảo.

FOS_OAS.1.3 SSF cung cấp [chỉ định: những biện pháp kiểm soát] để bảo vệ và giữ an toàn tài liệu hệ thống khỏi bị truy cập trái phép

FOS_OAS.1.4 SSF cung cấp [chỉ định: những biện pháp kiểm soát] không cho phép những trình biên dịch, trình soạn thảo và các dụng cụ phát triển khác hoặc các tiện ích truy cập từ hệ thống vận hành.

FOS_OAS.1.5 OSF định nghĩa [chỉ định: tiêu chí chấp nhận] đối với các hệ thống thông tin và những nâng cấp mới, và cho các phiên bản mới được thiết lập và thử nghiệm thích hợp được tiến hành trong quá trình phát triển trước khi chấp nhận.

FOS_OAS.1.6 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về việc phát hiện, phòng ngừa và phục hồi thông tin để bảo vệ chống lại mã độc hại và nhận thức người dùng.

FOS_OAS.1.7 OSF định nghĩa [chỉ định: các quy tắc] để hạn chế sử dụng và kiểm soát các chương trình tiện ích mà có khả năng ghi đè những biện pháp kiểm soát ứng dụng và hệ thống.

FOS_OAS.1.8 SSF cung cấp [chỉ định: những biện pháp kiểm soát] để xác thực các tiện ích hệ thống, tách biệt các tiện ích hệ thống khỏi các ứng dụng phần mềm, hạn chế việc sử dụng các tiện ích hệ thống với số lượng người dùng có thẩm quyền, đáng tin cậy tối thiểu.

FOS_OAS.1.9 OSF định nghĩa [chỉ định: các thủ tục] để cập nhật phần mềm vận hành, các ứng dụng về các thư viện chương trình bởi các quản trị viên đã được đào tạo dựa trên ủy quyền quản lý.

FOS_OAS.1.10 OSF định nghĩa [chỉ định: các quy tắc] mà chỉ có mã có thể thực thi trên hệ thống vận hành.

FOS_OAS.1.11 OSF định nghĩa [chỉ định: các quy tắc] mà các ứng dụng và phần mềm hệ thống vận hành được thực hiện sau khi thử nghiệm rộng rãi và thành công.

FOS_OAS.1.12 OSF định nghĩa [chỉ định: các quy tắc] mà chỉ có truy cập vật lý hoặc logic được dùng cho các nhà cung cấp với mục đích hỗ trợ khi cần thiết, và có sự chấp thuận quản lý.

FOS_OAS.1.13 OSF định nghĩa [chỉ định: các quy tắc] không sử dụng phần mềm không được cấp phép.

FOS_OAS.1.14 OSF định nghĩa [chỉ định: trách nhiệm] để làm theo các nhà cung cấp phát hành các bản vá lỗi và sửa lỗi cho các chương trình ứng dụng.

FOS_OAS.1.15 OSF định nghĩa [chỉ định: các thủ tục] để nâng cấp lên một phiên bản mới có tính đến sự an toàn của việc phát hành, việc giới thiệu chức năng an toàn mới hoặc số lượng và mức độ nghiêm trọng của các vấn đề an toàn ảnh hưởng đến phiên bản hiện tại.

FOS_OAS.1.16 OSF định nghĩa [chỉ định: các quy tắc] về việc sử dụng thông tin và tài sản gắn liền với các phương tiện tham gia vào quá trình xử lý thông tin được xác định, được ghi lại và được thực hiện.

B.3.6.5 FOS_OAS.2 Các thủ tục sao lưu

Những phụ thuộc: Không phụ thuộc.

FOS_OAS.2.1 SSF cung cấp [chỉ định: các thủ tục] để thực hiện và kiểm tra các bản sao lưu của thông tin và phần mềm phù hợp với một chính sách sao lưu đã thỏa thuận.

FOS_OAS.2.2 OSF định nghĩa [chỉ định: các thủ tục] để tạo ra mức cần thiết của thông tin sao lưu, cùng với các bản ghi của các bản sao lưu và thủ tục phục hồi tài liệu chính xác và đầy đủ.

FOS_OAS.2.3 OSF định nghĩa [chỉ định: các thủ tục] đối với các phương tiện sao lưu để đảm bảo rằng chúng có thể tin cậy để sử dụng khẩn cấp khi cần thiết.

FOS_OAS.2.4 OSF định nghĩa [chỉ định: các thủ tục] để đảm bảo chúng có hiệu quả và có thể được hoàn thành trong thời gian quy định trong quy trình vận hành phục hồi.

FOS_OAS.2.5 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về bố trí dự phòng cho các hệ thống cá nhân để đảm bảo rằng chúng đáp ứng yêu cầu của kế hoạch nghiệp vụ liên tục.

B.3.7 Các bản ghi dành cho các hệ thống CNTT (FOS_RCD)

B.3.7.1 Hành xử của họ

Họ này định nghĩa các bản ghi được lưu giữ cho các hệ thống CNTT. Nó bao gồm đặc tả các bản ghi.

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

FOS_RCD.1 Các bản ghi. Ghi lại tất cả các lỗi nghi ngờ đã được xác định.

B.3.7.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOS_RCD.1: Mô tả tất cả các lỗi nghi ngờ bằng những đặc tả và những hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

B.3.7.4 FOS_RCD.1 Các bản ghi

Những phụ thuộc: Không phụ thuộc.

FOS_RCD.1.1 SSF cung cấp [chỉ định: những biện pháp] để ghi lại tất cả các lỗi nghi ngờ hoặc các lỗi thực tế và bảo trì sửa chữa thiết bị chính xác.

B.4 Lớp FOA: Tài sản người dùng

Lớp này cung cấp các yêu cầu kiểm soát vận hành cho tài sản người dùng của hệ thống vận hành.

B.4.1 Bảo vệ dữ liệu riêng tư (FOA_PRO)

B.4.1.1 Hành xử của họ

Họ này định nghĩa các chính sách đối với tài sản người dùng. Nó bao gồm đặc tả dữ liệu riêng tư, mật mã, và những qui tắc và trách nhiệm quản lý tài sản người dùng.

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

FOA_PRO.1 Dữ liệu riêng tư. Những qui tắc không sử dụng cơ sở dữ liệu hoạt động có chứa thông tin cá nhân đã thử nghiệm, các quy tắc để có được thông tin công bố công khai theo đúng luật bảo vệ dữ liệu, và trách nhiệm của chủ sở hữu dữ liệu để thông báo cho nhân viên có thẩm quyền của tổ chức chịu trách nhiệm về bảo vệ dữ liệu được định nghĩa.

8.4.1.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOA_PRO.1: Mô tả những qui tắc không sử dụng cơ sở dữ liệu hoạt động có chứa thông tin cá nhân để thử nghiệm, các quy tắc để có được thông tin công bố công khai theo đúng luật bảo vệ dữ liệu, và trách nhiệm của chủ sở hữu dữ liệu để thông báo cho nhân viên có thẩm quyền của tổ chức chịu trách nhiệm về bảo vệ dữ liệu bằng những đặc tả và những hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

B.4.1.4 FOA_PRO.1 Dữ liệu riêng tư

Những phụ thuộc: Không phụ thuộc.

FOA_PRO.1.1 OSF định nghĩa [chỉ định: các quy tắc] không sử dụng cơ sở dữ liệu hoạt động có chứa thông tin cá nhân cho mục đích thử nghiệm.

FOA_PRO.1.2 OSF định nghĩa [chỉ định: các quy tắc] để có được thông tin công khai phù hợp với luật bảo vệ dữ liệu, để xử lý hoàn toàn và chính xác một cách kịp thời và bảo vệ trong quá trình thu thập và khi lưu trữ.

FOA_PRO.1.3 OSF định nghĩa [chỉ định: những trách nhiệm và quy tắc] đối với chủ sở hữu của các dữ liệu để thông báo cho nhân viên có thẩm quyền của tổ chức chịu trách nhiệm về bảo vệ dữ liệu liên quan đến những đề xuất để giữ thông tin cá nhân, và để đảm bảo nhận thức về các nguyên tắc bảo vệ dữ liệu quy định tại pháp luật có liên quan.

B.4.2 Bảo vệ thông tin tài sản người dùng (FOA_INF)

B.4.2.1 Hành xử của họ

Họ này định nghĩa bảo vệ thông tin đối với tài sản người dùng. Nó bao gồm việc bảo vệ dữ liệu, các thủ tục và các quy tắc.

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

FOA_INF.1 Bảo vệ dữ liệu. Hướng dẫn sử dụng các bản ghi chuyển giao, các thủ tục cho phép phá hủy các bản ghi và an toàn cho thông tin liên lạc điện tử được xác định. Thủ tục dán nhãn và xử lý thông tin được định nghĩa.

B.4.2.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOA_INF.1: Hướng dẫn sử dụng các bản ghi chuyển giao, các thủ tục cho phép hủy bỏ các bản ghi thích hợp và an toàn đối với truyền thông điện tử bằng những đặc tả và hành động cụ thể. Mô tả các thủ tục gán nhãn và xử lý thông tin bằng những đặc tả và hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

B.4.2.4 FOA_INF.1 Bảo vệ dữ liệu

Những phụ thuộc: FOS_POL.1 Các yêu cầu an toàn

FOA_INF.1.1 OSF định nghĩa [chỉ định: những nguyên tắc] về việc sử dụng, lưu trữ, xử lý và loại bỏ các bản ghi và thông tin.

FOA_INF.1.2 OSF định nghĩa [chỉ định: các quy tắc] về lịch trình sử dụng để xác định các loại hồ sơ cần thiết và khoảng thời gian mà chúng tiếp tục được sử dụng.

FOA_INF.1.3 OSF định nghĩa [chỉ định: các thủ tục] cho phép hủy bỏ các bản ghi sau khi tổ chức không cần đến.

FOA_INF.1.4 SSF cung cấp [chỉ định: những biện pháp] mà thông tin sẽ bị hủy bỏ, bị xóa hoặc ghi đè bằng kỹ thuật đã được phê duyệt cho các thiết bị chứa thông tin nhạy cảm.

FOA_INF.1.5 SSF cung cấp [chỉ định: những biện pháp] đối với thông tin liên lạc điện tử bằng cách bảo vệ các bản tin từ truy cập trái phép, sửa đổi hoặc từ chối dịch vụ, bảo đảm đúng địa chỉ và truyền tải bản tin, độ tin cậy và tính sẵn sàng của dịch vụ, sự lưu ý pháp luật.

FOA_INF.1.6 OSF định nghĩa [chỉ định: các thủ tục] để gán nhãn và xử lý thông tin bao gồm cả các định dạng vật lý và điện tử phù hợp với chương trình phân loại mà được tổ chức chấp nhận.

FOA_INF.1.7 OSF định nghĩa [chỉ định: các quy tắc] để xác định các đặc quyền liên quan với từng sản phẩm hệ thống và từng ứng dụng, và các nhóm nhân viên mà cần phải được phân bổ.

FOA_INF.1.8 OSF định nghĩa [chỉ định: các quy tắc] về phân bổ quyền cho người dùng trên cơ sở từ nhu cầu đến sử dụng và trên cơ sở từ sự kiện đến sự kiện phù hợp với chính sách kiểm soát truy cập.

FOA_INF.1.9 OSF định nghĩa [chỉ định: những yêu cầu an toàn] để bảo vệ các thông tin liên quan đến thương mại điện tử qua các mạng công cộng khỏi các hoạt động lừa đảo, tranh chấp hợp đồng, và tiết lộ và sửa đổi trái phép.

B.5 Lớp FOB: Nghiệp vụ

Lớp này cung cấp các yêu cầu kiểm soát vận hành cho nghiệp vụ của hệ thống vận hành.

B.5.1 Các chính sách nghiệp vụ (FOB_POL)

B.5.1.1 Hành xử của họ

Họ này định nghĩa các chính sách nghiệp vụ. Nó bao gồm đặc tả các yêu cầu an toàn và tài sản trí tuệ.

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

FOB_POL.1 Yêu cầu bảo mật. Giá trị nghiệp vụ của các tài sản thông tin có liên quan, yêu cầu an toàn của các ứng dụng nghiệp vụ cá nhân, xác thực các thông tin liên quan đến các ứng dụng nghiệp vụ và trách nhiệm và vai trò an toàn để thực hiện và duy trì chính sách an toàn được định nghĩa. Các thủ tục thích hợp để đảm bảo tuân thủ những giới hạn của pháp luật về việc sử dụng vật liệu được định nghĩa.

B.5.1.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOB_POL.1: Mô tả giá trị nghiệp vụ của các tài sản thông tin có liên quan, yêu cầu an toàn của các ứng dụng nghiệp vụ cá nhân, xác định các thông tin liên quan đến các ứng dụng nghiệp vụ và trách nhiệm và vai trò an toàn để thi và duy trì chính sách an toàn được định nghĩa. Các thủ tục thích hợp để đảm bảo tuân thủ những giới hạn của pháp luật về việc sử dụng vật liệu bằng những đặc tả và hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

B.5.1.4 FOB_POL.1 Những yêu cầu an toàn

Những phụ thuộc: FOS_POL.1 Những yêu cầu an toàn

FOB_POL.1.1 OSF qui định [chỉ định: chính sách an toàn] để xác định giá trị nghiệp vụ của những tài sản hệ thống và thông tin mà tạo thành một phần của hệ thống tổng thể.

FOB_POL.1.2 OSF định nghĩa [chỉ định: những yêu cầu an toàn] của các ứng dụng nghiệp vụ cá nhân, định danh tất cả thông tin liên quan đến các ứng dụng nghiệp vụ và những rủi ro mà thông tin đang phải đối mặt, chính sách phổ biến thông tin và ủy quyền, tính nhất quán giữa những biện pháp kiểm soát truy cập và chính sách phân loại thông tin của các mạng và các hệ thống khác nhau, pháp luật có liên quan và các nghĩa vụ hợp đồng liên quan đến bảo vệ truy cập dữ liệu hoặc dịch vụ, quản lý quyền truy cập trong một môi trường được nối mạng và được phân bổ mà nhận được tất cả những kết nối đang có.

FOB_POL.1.3 OSF định nghĩa [chỉ định: vai trò và trách nhiệm] để thực hiện và duy trì các chính sách an toàn, bảo vệ tài sản.

FOB_POL.1.4 OSF định nghĩa [chỉ định: vai trò và trách nhiệm] và truyền thông để tìm những ứng cử viên trước khi bổ nhiệm.

FOB_POL.1.5 OSF định nghĩa [chỉ định: các thủ tục] để đảm bảo tuân thủ các yêu cầu pháp lý, quy định và những điều luật hợp đồng về việc sử dụng vật liệu liên quan trong đó có thể có quyền sở hữu trí tuệ và về việc sử dụng các sản phẩm phần mềm độc quyền.

FOB_POL.1.6 OSF phát triển và thực hiện [chỉ định: các chính sách và các thủ tục] để bảo vệ thông tin có liên quan đến kết nối của hệ thống thông tin nghiệp vụ.

B.5.2 Tính liên tục của nghiệp vụ (FOB_BCN)

B.5.2.1 Hành xử của họ

Họ này định nghĩa các hoạt động nghiệp vụ liên tục. Nó bao gồm đặc tả phân tích tác động nghiệp vụ, cách ly lỗi và các kế hoạch nghiệp vụ liên tục.

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

FOB_BCN.1 Phân tích tác động. Phân tích tác động đối với tính liên tục nghiệp vụ, các kế hoạch nghiệp vụ liên tục để duy trì hoặc khôi phục lại các hoạt động nghiệp vụ, cô lập các lỗi bảo mật và cấp quyền truy cập đặc biệt vào thời điểm các lỗi bảo mật được xác định.

B.5.2.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOB_BCN.1: Mô tả tính liên tục nghiệp vụ, phân tích tác động đối với các kế hoạch liên tục nghiệp vụ để duy trì khôi phục lại các hoạt động nghiệp vụ, các kế hoạch cô lập các lỗi bảo mật và cấp quyền truy cập đặc biệt vào thời điểm các lỗi bảo mật bằng những đặc tả và những hành động cụ thể.

B.5.2.4 FOB_BCN.1 Phân tích tác động

Những phụ thuộc: FOD_RSM.1 Quản lý rủi ro trong các tổ chức

FOB_BCN.1.1 OSF định nghĩa [chỉ định: những yêu cầu an toàn] để thực hiện phân tích tác động nghiệp vụ để xác định các sự kiện có thể gây gián đoạn các quá trình nghiệp vụ cùng với khả năng và tác động của những gián đoạn này và tầm quan trọng của an toàn thông tin.

FOB_BCN.1.2 OSF định nghĩa [chỉ định: những yêu cầu an toàn] để thực hiện phân tích tác động nghiệp vụ liên tục với sự tham gia đầy đủ của các chủ sở hữu tài nguyên doanh nghiệp và chủ sở hữu các quy trình.

FOB_BCN.1.3 OSF định nghĩa [chỉ định: những yêu cầu an toàn] cho các kế hoạch nghiệp vụ liên tục để phục hồi từ các cuộc tấn mã độc hại, bao gồm tất cả dữ liệu cần thiết, phần mềm sao lưu và những bản sao khôi phục.

FOB_BCN.1.4 OSF qui định [chỉ định: những yêu cầu an toàn] để nhận biết những rủi ro mà tổ chức đang phải đối mặt, những tác động mà có thể làm gián đoạn nghiệp vụ, trình bày có hệ thống và ghi lại chiến lược nghiệp vụ liên tục phù hợp với những quyền ưu tiên và mục tiêu nghiệp vụ đã thỏa thuận, trình bày có hệ thống và ghi lại các kế hoạch nghiệp vụ liên tục phù hợp với chiến lược đã thống nhất, thử nghiệm và cập nhật thường xuyên các kế hoạch và các quy trình đưa ra và đảm bảo rằng các việc quản lý nghiệp vụ liên tục được sát nhập trong cấu trúc và các quy trình của tổ chức dành cho nghiệp vụ liên tục.

FOB_BCN.1.5 OSF định nghĩa [chỉ định: những yêu cầu an toàn] phát triển và thực hiện các kế hoạch nghiệp vụ liên tục để duy trì hoặc khôi phục lại hoạt động và đảm bảo tính sẵn có của thông tin ở mức độ cần thiết và trong thời gian quy mô yêu cầu sau đây bị gián đoạn, hay thất bại của, quy trình nghiệp vụ quan trọng.

FOB_BCN.1.6 OSF định nghĩa [chỉ định: các thủ tục] là một bản sao của kế hoạch nghiệp vụ liên tục được lưu trữ ở một khu vực xa, ở một khoảng cách đủ để tránh được bất kỳ hư hỏng nào do thảm họa xảy ra tại vị trí quan trọng nhất. Nó được đảm bảo rằng các bản sao này được cập nhật và được bảo vệ bằng mức bảo mật tương tự như ở vị trí quan trọng nhất.

FOB_BCN.1.7 OSF định rõ [chỉ định: những yêu cầu an toàn] đối với các điều kiện kích hoạt nó, cũng như đối với những cá nhân chịu trách nhiệm thực hiện từng thành phần của kế hoạch cho từng kế hoạch nghiệp vụ liên tục.

FOB_BCN.1.8 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về việc kiểm thử và cập nhật các kế hoạch nghiệp vụ tính liên tục để đảm bảo rằng chúng được cập nhật và có hiệu quả.

FOB_BCN.1.9 OSF định nghĩa [chỉ định: những yêu cầu an toàn] cho các kế hoạch cách ly lỗi bảo mật để nó có tác động tối thiểu đến tính liên tục của nghiệp vụ khi xảy ra sự cố bảo mật.

FOB_BCN.1.10 OSF định nghĩa [chỉ định: các quy tắc) dùng để truy cập đặc biệt vào tài sản hệ thống vận hành tại thời điểm xảy ra lỗi bảo mật.

FOB_BCN.1.11 OSF định nghĩa [chỉ định: những yêu cầu an toàn] mà một quá trình quản lý được phát triển và duy trì tính liên tục nghiệp vụ trong toàn tổ chức để xử lý những yêu cầu an toàn thông tin cần thiết đối với tính liên tục của nghiệp vụ của các tổ chức.

FOB_BCN.1.12 OSF định nghĩa [chỉ định: những yêu cầu an toàn] đối với một khuôn khổ duy nhất các kế hoạch nghiệp vụ liên tục để đảm bảo rằng tất cả các kế hoạch phù hợp, giải quyết nhất quán các yêu cầu an toàn thông tin, và xác định những ưu tiên đối với việc kiểm thử và bảo trì.

B.6 Lớp FOP: Phương tiện và thiết bị

Lớp này cung cấp những yêu cầu kiểm soát vận hành đối với thiết bị, phương tiện và tài sản trong hệ thống vận hành.

B.6.1 Thiết bị di động (FOP_MOB)

B.6.1.1 Hành xử của họ

Họ này định nghĩa những yêu cầu an toàn đối với thiết bị di động. Nó bao gồm đặc tả các yêu cầu an toàn và vai trò và trách nhiệm đối với an toàn thông tin.

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

FOP_MOB.1 Các yêu cầu an toàn cho các thiết bị di động. Các yêu cầu đối với các thủ tục và biện pháp bảo vệ vật lý để thực hiện các biện pháp an toàn khi sử dụng các phương tiện tham gia vào quá trình tính toán di động ở những nơi công cộng phải được xác định. Quy định về việc sử dụng các phương tiện tham gia vào quá trình xử lý thông tin cá nhân hoặc riêng tư và quy định về các thiết bị không được giám sát được định nghĩa.

B.6.1.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOP_MOB.1: Mô tả những yêu cầu về các thủ tục và bảo vệ vật lý để thực hiện các biện pháp an toàn khi sử dụng các phương tiện tham gia vào quá trình tính toán di động ở những nơi công cộng bằng những đặc tả và hành động cụ thể. Mô tả những quy định về việc sử dụng các phương tiện tham gia vào quá trình xử lý thông tin cá nhân hoặc riêng tư và quy định về các thiết bị không được giám sát bằng những đặc tả và hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

B.6.1.4 FOP_MOB.1 Các yêu cầu an toàn đối với các thiết bị di động

Những phụ thuộc: Không phụ thuộc.

FOP_MOB.1.1 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về những rủi ro khi làm việc với các thiết bị tính toán di động trong các môi trường không được bảo vệ theo chính sách tính toán di động.

FOP_MOB.1.2 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về bảo vệ vật lý, kiểm soát truy cập, các kỹ thuật mật mã, các thủ tục sao lưu và bảo vệ chống virus theo chính sách tính toán di động.

FOP_MOB.1.3 SSF cung cấp [chỉ định: những biện pháp] để bảo vệ chống lại những rủi ro khi sử dụng các phương tiện tham gia vào quá trình tính toán di động.

FOP_MOB.1.4 OSF định nghĩa [chỉ định: các thủ tục] để thực hiện các biện pháp an toàn khi sử dụng các phương tiện tham gia vào quá trình tính toán di động ở những nơi công cộng, các phòng họp và các khu vực khác không được bảo vệ bên ngoài các tòa nhà của các tổ chức. OSF sẽ cung cấp biện pháp bảo vệ phù hợp để sử dụng các tài sản di động được kết nối với các mạng lưới.

FOP_MOB.1.5 SSF cung cấp [chỉ định: những biện pháp] để bảo vệ các phương tiện tham gia vào quá trình tính toán di động khỏi bị trộm cắp đặc biệt là khi không được giám sát bằng biện pháp bảo vệ vật lý.

FOP_MOB.1.6 OSF định nghĩa [chỉ định: các quy tắc] về việc sử dụng các phương tiện tham gia vào quá trình xử lý thông tin cá nhân hoặc riêng tư để xử lý thông tin nghiệp vụ.

FOP_MOB.1.7 OSF định nghĩa [chỉ định: các quy tắc] mà các phương tiện và thiết bị không được giám sát tại các tòa nhà của tổ chức không được để ở nơi công cộng và máy tính xách tay phải được mang theo người nếu có thể khi di chuyển.

B.6.2 Thiết bị có thể di dời (FOP_RMM)

B.6.2.1 Hành xử của họ

Họ này định nghĩa các thủ tục an toàn đối với thiết bị có thể di dời được. Nó bao gồm đặc tả quản lý thiết bị có thể di dời.

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

FOP_RMM.1 Quản lý phương tiện có thể di dời được. Các thủ tục quản lý thiết bị máy tính có thể di dời, thủ tục cấp phép cho các thiết bị được di dời ra khỏi tổ chức và các thủ tục xóa các nội dung của bất kỳ thiết bị nào có thể tái sử dụng phải được xác định.

B.6.2.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOP_RMM.1: Mô tả các thủ tục quản lý thiết bị máy tính có thể di dời được, thủ tục cấp phép cho các thiết bị được di dời ra khỏi tổ chức và các thủ tục xóa các nội dung của bất kỳ phương tiện nào có thể tái sử dụng bằng những đặc tả và những hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

B.6.2.4 FOP_RMM.1 Quản lý phương tiện có thể di dời được

Những phụ thuộc: Không phụ thuộc.

FOP_RMM.1.1 OSF định nghĩa [chỉ định: các thủ tục] và quản lý thiết bị máy tính có thể di dời được.

FOP_RMM.1.2 OSF định nghĩa [chỉ định: các thủ tục] về cấp phép cho các thiết bị được di dời ra khỏi tổ chức.

FOP_RMM.1.3 OSF định nghĩa [chỉ định: các thủ tục] để giảm thiểu những rủi ro liên quan đến việc rò rỉ thông tin nhạy cảm cho những người không có thẩm quyền khi thiết lập các thủ tục chính thức về việc chuyển nhượng thiết bị.

FOP_RMM.1.4 OSF định nghĩa [chỉ định: các thủ tục] để xóa các nội dung, bao gồm bất kỳ dữ liệu nhạy cảm và phần mềm được cấp phép nào, của bất kỳ thiết bị và phương tiện mà có thể sử dụng lại có chứa phương tiện lưu trữ mà sẽ được di dời khỏi tổ chức khi không còn cần thiết và kiểm tra chúng khi hoàn tất.

B.6.3 Thiết bị điều khiển từ xa (FOP_RMT)

B.6.3.1 Hành xử của họ

Họ này định nghĩa các thủ tục an toàn cho thiết bị điều khiển từ xa. Nó bao gồm đặc tả quản lý các thiết bị điều khiển từ xa.

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

FOP_RMT.1 Quản lý thiết bị điều khiển từ xa. Trách nhiệm và thủ tục quản lý và sử dụng thiết bị điều khiển từ xa và các thủ tục truy cập thông tin nghiệp vụ từ xa phải định nghĩa.

B.6.3.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOP_RMT.1: Mô tả trách nhiệm và thủ tục quản lý và sử dụng thiết bị điều khiển từ xa và các thủ tục truy cập thông tin nghiệp vụ từ xa bằng những đặc tả và hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

B.6.3.4 FOP_RMT.1 Quản lý Thiết bị điều khiển từ xa

Những phụ thuộc: Không phụ thuộc.

FOP_RMT.1.1 OSF định nghĩa [chỉ định: những trách nhiệm và thủ tục] về quản lý và sử dụng thiết bị điều khiển từ xa kể cả thiết bị ở trong khu vực người dùng.

FOP_RMT.1.2 OSF định nghĩa [chỉ định: các thủ tục] về việc truy cập thông tin nghiệp vụ từ xa thông qua mạng công cộng sử dụng các phương tiện tham gia vào quá trình tính toán di động sau khi định danh và xác thực thành công, và có cơ chế kiểm soát truy cập phù hợp.

FOP_RMT.1.3 SSF cung cấp [chỉ định: những biện pháp] đối với khóa phím hoặc một kiểm soát tương đương cho các máy tính hoặc thiết bị đầu cuối bảo mật khỏi bị sử dụng trái phép.

FOP_RMT.1.4 SSF cung cấp [chỉ định: những biện pháp] để định danh thiết bị tự động theo cách xác thực các kết nối từ các địa điểm và thiết bị cụ thể.

FOP_RMT.1.5 SSF cung cấp [chỉ định: những biện pháp kiểm soát] đối với truy cập vật lý và logic đến các cổng cấu hình và diagnostic.

B.6.4 Thiết bị hệ thống (FOP_SYS)

B.6.4.1 Hành xử của họ

Họ này định nghĩa các thủ tục an toàn cho thiết bị hệ thống. Nó bao gồm đặc tả quản lý thiết bị hệ thống.

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

FOP_SYS.1 Quản lý thiết bị hệ thống. Vị trí thiết bị dự phòng và phương tiện sao lưu, các quy định để giữ các chất độc hại hoặc dễ cháy, các thủ tục kiểm tra vật liệu đầu vào và bảo vệ hệ thống cáp mạng phải được định nghĩa.

B.6.4.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOP_SYS.1: Mô tả thiết bị dự phòng và phương tiện sao lưu, các quy định để giữ các chất độc hại hoặc dễ cháy, các thủ tục kiểm tra vật liệu đầu vào và bảo vệ hệ thống cáp mạng bằng những đặc tả và những hành động cụ thể.

B.6.4.4 FOP_SYS.1 Quản lý thiết bị hệ thống

Những phụ thuộc: Không phụ thuộc.

FOP_SYS.1.1 OSF định nghĩa [chỉ định: các quy tắc] về vị trí thiết bị dự phòng và phương tiện sao lưu ở một khoảng cách an toàn để tránh hư hỏng do thảm họa xảy ra tại vị trí quan trọng nhất.

FOP_SYS.1.2 OSF định nghĩa [chỉ định: các quy tắc] về việc cất giữ các chất độc hại hoặc dễ cháy ở một khoảng cách an toàn so với vùng đảm bảo.

FOP_SYS.1.3 OSF định nghĩa [chỉ định: các quy tắc] về việc cất giữ danh mục điện thoại và các sổ sách điện thoại nội bộ xác định vị trí của các tài cảm tham gia vào quá trình xử lý thông tin nhạy cảm không thể truy cập công cộng được.

FOP_SYS.1.4 OSF định nghĩa [chỉ định: các thủ tục] để kiểm tra vật liệu đầu vào về các mối đe dọa tiềm ẩn trước khi nó được chuyển từ các khu vực nhập và xuất đến các điểm sử dụng.

FOP_SYS.1.5 SSF cung cấp [chỉ định: những biện pháp] để bảo vệ hệ thống cáp khỏi bị can thiệp trái phép hoặc khỏi bị hư hỏng qua các khu vực công cộng.

FOP_SYS.1.6 OSF định nghĩa [chỉ định: các quy tắc] về bảo trì thiết bị phù hợp với những đặc tả và khoảng thời gian khuyến cáo của nhà cung cấp.

FOP_SYS.1.7 OSF định nghĩa [chỉ định: các quy tắc] mà chỉ những nhân viên bảo trì có thẩm quyền mới được sửa chữa và bảo dưỡng thiết bị.

FOP_SYS.1.8 OSF định nghĩa [chỉ định: những biện pháp kiểm soát] đối với một mức bảo vệ môi trường và vật lý thích hợp với các tiêu chuẩn được áp dụng tại vị trí quan trọng nhất đối với thông tin sao lưu. Những biện pháp kiểm soát được áp dụng cho thiết bị tại vị trí chính sẽ được mở rộng bao gồm cả vị trí sao lưu.

FOP_SYS.1.9 OSF định nghĩa [chỉ định: các quy tắc] về việc lưu giữ tất cả thiết bị trong một môi trường an toàn và phù hợp với yêu cầu kỹ thuật của các nhà sản xuất.

FOP_SYS.1.10 OSF định nghĩa [chỉ định: những trách nhiệm] để bảo vệ thiết bị không được giám sát dùng cho các nhân viên, nhà thầu và người dùng những yêu cầu và các thủ tục về an toàn của tổ chức thứ 3.

FOP_SYS.1.11 OSF định nghĩa [chỉ định: các thủ tục] để đảm bảo rằng tất cả các thông tin liên quan được chuyển đến các tổ chức và sẽ bị xóa khỏi thiết bị một cách an toàn trong trường hợp một nhân viên hay nhà thầu hoặc người dùng của tổ chức thứ ba mua thiết bị của tổ chức hoặc sử dụng thiết bị cá nhân của họ.

FOP_SYS.1.12 OSF cung cấp [chỉ định: những biện pháp kiểm soát] đối với các thiết bị có chứa thông tin được bảo vệ khỏi bị truy cập trái phép, sử dụng sai hoặc sửa đổi nội dung trong quá trình vận chuyển đến các biên vật lý của tổ chức.

B.6.5 Quản lý tài sản (FOP_MNG)

B.6.5.1 Hành xử của họ

Họ này định nghĩa việc quản lý các tài sản. Nó bao gồm những đặc tả an toàn vật lý, các thực thể hỗ trợ và những kết nối truyền thông.

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

FOP_MNG.1 An toàn vật lý. An toàn vật lý đối với các phòng ốc, cơ quan và tài sản được định nghĩa. Phân tách tình trạng phát triển, thử nghiệm và tình trạng hoạt động của tài sản được định nghĩa. Những yêu cầu và các tài sản sao lưu thích hợp và việc bảo vệ những phương tiện tham gia vào quá trình xử lý thông tin được định nghĩa.

FOP_MNG.2 Thiết bị cấp nguồn. Việc kiểm soát các thiết bị cấp nguồn và sử dụng một máy phát điện dự phòng được định nghĩa.

FOP_MNG.3 những kết nối truyền thông. Kiểm soát những kết nối truyền thông bên ngoài được định nghĩa.

B.6.5.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOP_MNG.1: Mô tả an toàn vật lý đối với các phòng ốc, cơ quan và tài sản được định nghĩa. Phân tách tình trạng phát triển, thử nghiệm và tình trạng hoạt động của tài sản được định nghĩa. Những yêu cầu về các tài sản sao lưu thích hợp và việc bảo vệ những phương tiện tham gia vào quá trình xử lý thông tin bằng những đặc tả và những hành động cụ thể.

b) FOP_MNG.2: Mô tả việc kiểm soát các thiết bị cấp nguồn và sử dụng máy phát điện dự phòng bằng những đặc tả và những hành động cụ thể.

c) FOP_MNG.3: Mô tả việc kiểm soát những kết nối truyền thông và những xử lý hư hỏng bằng những đặc tả và những hành động cụ thể.

B.6.5.4 FOP_MNG.1 An toàn vật lý

Những phụ thuộc: FOD_PSN.5 Truy cập phương tiện và thiết bị

FOP_MNG.1.1 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về an toàn vật lý cho các phòng ốc, cơ quan và tài sản khỏi bị hư hỏng do hỏa hoạn, lũ lụt, động đất, cháy nổ, tình trạng bất ổn của dân chúng và các thảm họa thiên nhiên hoặc nhân tạo khác.

FOP_MNG.1.2 OSF định nghĩa [chỉ định: những yêu cầu an toàn] đối với việc phân tách tình trạng phát triển, thử nghiệm và tình trạng hoạt động của tài sản để giảm thiểu rủi ro truy cập trái phép hoặc làm thay đổi hệ thống vận hành.

FOP_MNG.1.3 OSF định nghĩa [chỉ định: những yêu cầu an toàn] đối với các tài sản sao lưu để đảm bảo rằng tất cả phần mềm và thông tin thiết yếu có thể được phục hồi sau một thảm họa hoặc hư hỏng thiết bị.

FOR_MNG.1.4 OSF định nghĩa [chỉ định: những yêu cầu an toàn] để bảo vệ các phương tiện tham gia vào quá trình xử lý thông tin khỏi bị truy cập trái phép hoặc bị lộ các thông tin được lưu trữ và được xử lý bởi các phương tiện tham gia vào quá trình xử lý thông tin này.

B.6.5.5 FOP_MNG.2 Các thiết bị cấp nguồn

Những phụ thuộc: Không phụ thuộc.

FOP_MNG.2.1 SSF cung cấp [chỉ định: những biện pháp kiểm soát] để bảo vệ các thiết bị khỏi hư hỏng nguồn và những gián đoạn khác gây ra bởi hư hỏng thiết bị cấp nguồn.

FOP_MNG.2.2 OSF định nghĩa [chỉ định: những yêu cầu an toàn] đối với việc sử dụng thiết bị UPS.

FOP_MNG.2.3 OSF định nghĩa [chỉ định: những yêu cầu an toàn] đối với việc sử dụng máy phát điện dự phòng nếu quá trình xử lý thông tin vẫn đang tiếp tục trong trường hợp hỏng nguồn kéo dài.

B.6.5.6 FOP_MNG.3 Những kết nối truyền thông

Những phụ thuộc: Không phụ thuộc.

FOP_MNG.3.1 SSF cung cấp [chỉ định: những biện pháp kiểm soát] để bảo vệ cáp điện lực và cáp viễn thông khi đang truyền dữ liệu hoặc hỗ trợ các dịch vụ thông tin khỏi bị chặn lại hoặc hư hỏng.

FOP_MNG.3.2 SSF định nghĩa [chỉ định: những yêu cầu an toàn] để đảm bảo rằng việc kết nối thông tin liên lạc có thể được duy trì trong trường hợp thiết bị thông tin liên lạc bị gián đoạn hoặc hư hỏng.

B.7 Lớp FOT: Các tổ chức thứ 3

Lớp này cung cấp các yêu cầu kiểm soát vận hành cho các tổ chức thứ 3.

B.7.1 Quản lý tổ chức thứ 3 (FOT_MNG)

B.7.1.1 Hành xử của họ

Họ này định nghĩa quản lý các tổ chức thứ 3 và những cam kết với các tổ chức thứ 3. Nó bao gồm đặc tả thuê khoán và các yêu cầu an toàn đối với tổ chức thứ 3.

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

FOT_MNG.1 Thuê khoán. Một kế hoạch chuyển tiếp thông tin, thỏa thuận cấp phép, quyền sở hữu mã và các quyền sở hữu tài sản trí tuệ được định nghĩa.

FOT_MNG.2 Các yêu cầu an toàn đối với tổ chức thứ 3. Tất cả các yêu cầu an toàn khi làm việc cùng với các tổ chức thứ 3 được định nghĩa. Toàn bộ kiểm soát và những quy định không được truy cập vào thông tin của các tổ chức được định nghĩa. Quản lý rủi ro thích hợp với các mối quan hệ tổ chức thứ 3 được định nghĩa.

B.7.1.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOT_MNG.1: kế hoạch cho quá trình chuyển tiếp thông tin, thỏa thuận cấp phép, quyền sở hữu mã và các quyền sở hữu tài sản trí tuệ bằng những đặc tả và những hành động cụ thể.

b) FOT_MNG.2: Mô tả tất cả những yêu cầu an toàn khi làm việc cùng với các tổ chức thứ 3, toàn bộ kiểm soát và các quy tắc không được truy cập vào thông tin của các tổ chức và quản lý rủi ro bằng những đặc tả và hành động cụ thể.

B.7.1.4 FOT_MNG.1 Thuê khoán

Những phụ thuộc: FOD_PSN.3 Hợp đồng lao động.

FOT_MNG.1.1 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về kế hoạch chuyển tiếp thông tin, những phương tiện tham gia vào quá trình xử lý thông tin và bất kỳ cái gì khác mà cần phải được di dời và duy trì an ninh trong giai đoạn chuyển tiếp để chuẩn bị thuê khoán.

FOT_MNG.1.2 OSF định nghĩa [chỉ định: những yêu cầu an toàn] để chuẩn bị cấp phép, quyền sở hữu mã và sở hữu tài sản trí tuệ, chứng nhận chất lượng và độ chính xác của công việc được thực hiện, chuẩn bị bản giao kèo trong trường hợp tổ chức thứ 3 không tuân thủ, các quyền truy cập để đánh giá chất lượng và độ chính xác của công việc đã thực hiện xong, những thỏa thuận bằng hợp đồng về chất lượng mã và thử nghiệm trước khi cài đặt để tìm ra mã Trojan ở nơi mà việc phát triển phần mềm được thuê khoán.

B.7.1.5 FOT_MNG.2 Các yêu cầu an toàn đối với tổ chức thứ 3

Những phụ thuộc: Không phụ thuộc.

FOT_MNG.2.1 OSF định nghĩa [chỉ định: những yêu cầu an toàn] khi làm việc cùng với các tổ chức thứ 3 hoặc những qui tắc nội bộ khi thỏa thuận với tổ chức thứ 3.

FOT_MNG.2.2 OSF định nghĩa [chỉ định: những yêu cầu an toàn] để đảm bảo phù hợp với các tiêu chuẩn và chính sách an toàn của tổ chức khi thỏa thuận với các tổ chức thứ 3 liên quan đến việc truy cập, xử lý, truyền thông hoặc quản lý thông tin của tổ chức hoặc các phương tiện tham gia vào quá trình xử lý thông tin.

FOT_MNG.2.3 OSF định nghĩa [chỉ định: những yêu cầu an toàn] đối với kiểm soát toàn bộ và những khía cạnh an toàn cho thông tin nhạy cảm hoặc quan trọng hoặc những phương tiện tham gia vào quá trình xử lý thông tin được truy cập, được xử lý hoặc được quản lý bởi một tổ chức thứ 3.

FOT_MNG.2.4 OSF định nghĩa [chỉ định: các quy tắc] các tổ chức thứ 3 không được truy cập vào thông tin của tổ chức cho đến khi những qui tắc được đưa ra và sự thỏa thuận đã được ký kết để xác định các điều khoản và điều kiện để kết nối hoặc truy cập và bố trí làm việc.

FOT_MNG.2.5 OSF định nghĩa [chỉ định: những yêu cầu an toàn] để thực hiện quản lý rủi ro của quá trình nghiệp vụ với các tổ chức thứ 3 và nhân viên tổ chức thứ 3.

FOT_MNG.2.6 OSF định nghĩa [chỉ định: những yêu cầu an toàn] để thực hiện quản lý rủi ro của các phương tiện lưu trữ và xử lý thông tin khác nhau mà tổ chức thứ 3 thuê.

FOT_MNG.2.7 OSF định nghĩa [chỉ định: các thủ tục] về phát triển phần mềm thuê khoán được các tổ chức giám sát và theo dõi.

FOT_MNG.2.8 OSF định nghĩa [chỉ định: những yêu cầu an toàn] để xác nhận rằng những biện pháp kiểm soát an toàn, những định nghĩa dịch vụ và các mức độ cung cấp bao gồm trong thỏa thuận cung cấp dịch vụ của tổ chức thứ ba được thực hiện, vận hành, và bảo trì bởi các tổ chức thứ ba.

FOT_MNG.2.9 OSF định nghĩa [chỉ định: những yêu cầu an toàn] mà các dịch vụ, các báo cáo các bản ghi được cung cấp bởi tổ chức thứ ba thường xuyên được theo dõi và xem xét và những đánh giá được kiểm tra thường xuyên.

FOT_MNG.2.10 OSF định nghĩa [chỉ định: những yêu cầu an toàn] mà những thay về việc cung cấp dịch vụ, bao gồm cả việc bảo trì và cải tiến các thủ tục, qui tắc, chính sách an toàn thông tin hiện có phải được quản lý, có tính đến mức độ quan trọng của các qui trình và hệ thống nghiệp vụ có liên quan và việc đánh giá lại các rủi ro.

FOT_MNG.2.11 OSF định nghĩa [chỉ định: những yêu cầu an toàn] được đề cập trong những hợp đồng với các tổ chức ba liên quan đến việc truy cập, xử lý, truyền thông hoặc quản lý thông tin hoặc các phương tiện tham gia vào quá trình xử lý thông tin của các tổ chức, hoặc các sản phẩm, dịch vụ bổ sung cho các phương tiện tham gia vào quá trình xử lý thông tin.

B.8 Lớp FOM: Quản lý

Lớp này cung cấp những yêu cầu về quản lý những biện pháp kiểm soát vận hành.

B.8.1 Quản lý các tham số an toàn (FOM_PRM)

B.8.1.1 Hành xử của họ

Họ này định nghĩa việc quản lý các tham số an toàn. Nó bao gồm đặc tả sử dụng mật mã về các đặc quyền.

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

FOM_PRM.1 Sử dụng mật mã. Phương pháp tiếp cận quản lý khóa mật mã bao gồm các phương pháp để xử lý bảo vệ các khóa mật mã và khôi phục thông tin đã được mã hóa được định nghĩa.

FOM_PRM.2 Phân bố đặc quyền. Phân bố đặc quyền được định nghĩa.

B.8.1.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOM_PRM.1: Mô tả phương pháp tiếp cận quản lý khóa mật mã bao gồm các phương pháp để xử lý bảo vệ các khóa mã và khôi phục thông tin đã được mã hóa bằng những đặc tả và hành động cụ thể.

b) FOM_PRM.2: Mô tả phân bố đặc quyền bằng những đặc tả và hành động cụ thể.

B.8.1.4 FOM_PRM.1 Sử dụng mật mã

Những phụ thuộc: FOS_POL.4 Chính sách mật mã.

FOM_PRM.1.1 OSF định nghĩa (chỉ định: những yêu cầu an toàn] về phương pháp tiếp cận việc quản lý sử dụng kiểm soát mật mã trong tổ chức, phương pháp tiếp cận quản lý khóa mật mã bao gồm các phương pháp để xử lý bảo vệ các khóa mã và khôi phục thông tin đã được mã hóa trong trường hợp các khóa mật mã bị mất, bị hư hại hoặc bị hư hỏng, vai trò và trách nhiệm của người mà chịu trách nhiệm thực thi chính sách; những quy định và những giới hạn quốc gia có thể áp dụng cho việc sử dụng các kỹ thuật mật mã ở các vùng khác nhau trên thế giới và áp dụng cho sự phát hành các luồng tin được mã hóa dùng cho chính sách mật mã của tổ chức.

B.8.1.5 FOM_PRM.2 Phân bố đặc quyền

Những phụ thuộc: Không phụ thuộc.

FOM_PRM.2.1 OSF định nghĩa [chỉ định: các quy tắc] về phân chia đặc quyền để giảm cơ hội sửa đổi trái phép hoặc lạm dụng tài sản, cách ly ban đầu sự kiện khỏi việc cấp phép của nó.

FOM_PRM.2.2 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về việc chỉ định đặc quyền để định danh người dùng khác nhau từ những người được sử dụng cho nghiệp vụ thông thường.

B.8.2 Quản lý phân loại tài sản (FOM_CLS)

B.8.2.1 Hành xử của họ

Họ này định nghĩa việc phân loại các tài sản. Nó bao gồm việc phân loại.

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

FOM_CLS.1 Phân loại. Việc phân loại các bản ghi được định nghĩa.

FOM_CLS.2 Định danh tài sản. Định danh tài sản được định nghĩa.

B.8.2.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOM_CLS.1: Mô tả việc phân loại các bản ghi bằng những đặc tả cụ thể.

b) FOM_CLS.2: Mô tả định danh tài sản bằng những đặc tả cụ thể.

B.8.2.4 FOM_CLS.1 Phân loại

Những phụ thuộc: Không phụ thuộc.

FOM_CLS.1.1 OSF định nghĩa (chỉ định: những yêu cầu an toàn] về việc phân loại các bản ghi thành thành các loại bản ghi, các bản ghi cơ sở dữ liệu, các log giao dịch, log đánh giá và thủ tục hoạt động, mỗi loại có các chi tiết và thời gian lưu giữ và loại phương tiện lưu trữ.

B.8.2.5 FOM_CLS.2 Định danh tài sản

Những phụ thuộc: Không phụ thuộc.

FOM_CLS.2.1 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về đặc tả định danh, đặc tả loại tài sản, chức năng tài sản, những yêu cầu về quản lý, cung cấp mức bảo vệ tương xứng với tầm quan trọng của tài sản phù hợp với quyền sở hữu và Phân loại an toàn và ghi lại địa điểm kiểm kê của từng tài sản.

FOM_CLS.2.2 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về việc lập kế hoạch và duy trì việc kiểm kê tất cả các tài sản quan trọng.

FOM_CLS-2.3 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về thời gian lưu giữ các thông tin nghiệp vụ quan trọng cũng như những yêu cầu về các bản sao lưu trữ được tiếp tục sử dụng lâu dài.

B.8.3 Quản lý trách nhiệm an toàn nhân sự (FOM_PSN)

B.8.3.1 Hành xử của họ

Họ này định nghĩa trách nhiệm quản lý an toàn thông tin của những người có liên quan. Nó bao gồm các chủ sở hữu tài sản và người quản lý an toàn thông tin.

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

FOM_PSN.1 Quyền sở hữu tài sản. Quyền sở hữu tài sản được định nghĩa.

FOM_PSN.2 Người quản lý an toàn thông tin. Chỉ định những người quản lý an toàn thông tin được định nghĩa.

B.8.3.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOM_PSN.1: Mô tả Quyền sở hữu tài sản bằng những đặc tả cụ thể.

b) FOM_CLS.2: Mô tả việc chỉ định người quản lý an toàn thông tin bằng những đặc tả cụ thể.

B.8.3.4 FOM_PSN.1 Quyền sở hữu tài sản

Những phụ thuộc: FOA_POL.3 Quản lý tài sản người dùng

FOM_PSN.1.1 OSF định nghĩa [chỉ định: những yêu cầu an toàn] mà tất cả các thông tin và tài sản gắn liền với những phương tiện tham gia vào quá trình xử lý thông tin thuộc sở hữu một phần của tổ chức.

B.8.3.5 FOM_PSN.2 Người quản lý an toàn thông tin

Những phụ thuộc: Không phụ thuộc.

FOM_PSN.2.1 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về việc chỉ định một người quản lý chịu trách nhiệm cụ thể đối với từng kiểm soát an toàn thông tin.

FOM_PSN.2.2 OSF định nghĩa [chỉ định: những yêu cầu an toàn] về quản lý bắt buộc người lao động, nhà thầu và người dùng của tổ chức thứ ba áp dụng chính sách an toàn thông tin phù hợp với chính sách và thủ tục của tổ chức đã thiết lập.

B.8.4 Quản lý tổ chức an toàn (FOM_ORG)

B.8.4.1 Hành xử của họ

Họ này định nghĩa tổ chức quản lý an toàn thông tin. Nó bao gồm các trách nhiệm quản lý an toàn thông tin và quản lý thành viên diễn đàn an toàn thông tin.

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

FOM_ORG.1 Trách nhiệm quản lý an toàn thông tin. Trách nhiệm quản lý an toàn thông tin được xác định.

FOM_ORG.2 Quản lý thành viên diễn đàn an toàn thông tin. Thành viên của diễn đàn quản lý an toàn thông tin được xác định.

B.8.4.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây:

a) FOM_ORG.1: Mô tả các trách nhiệm quản lý an toàn thông tin bằng những đặc tả và những hành động cụ thể.

b) FOM ORG.2: Mô tả việc quản lý thành viên diễn đàn an toàn thông tin bằng những đặc tả cụ thể.

B.8.4.4 FOM_ORG.1 Trách nhiệm quản lý an toàn thông tin

Những phụ thuộc: FOD_ORG.1 Trách nhiệm phối hợp về vấn đề an toàn thông tin

FOM_ORG.1.1 OSF định nghĩa [chỉ định: những trách nhiệm] về quản lý để đảm bảo hoạt động an toàn thông tin phù hợp với chính sách an toàn, phê duyệt các phương pháp luận và các quy trình cụ thể về an toàn thông tin, theo dõi những thay đổi đáng kể về mối đe dọa và exposure các tài sản thông tin bị đe dọa, đánh giá đầy đủ những biện pháp kiểm soát an toàn thông tin cụ thể và phối hợp thực hiện những biện pháp kiểm soát an toàn thông tin cụ thể cho các hệ thống hoặc dịch vụ mới, thúc đẩy việc hỗ trợ cho an toàn thông tin trong toàn tổ chức.

FOM_ORG.1.2 OSF định nghĩa [chỉ định: những trách nhiệm] đối với các nhà quản lý để đảm bảo rằng tất cả các thủ tục quản lý an toàn thông tin trong khu vực thuộc trách nhiệm của họ được thực hiện một cách chính xác để phù hợp với chính sách và tiêu chuẩn an toàn thông tin.

FOM_ORG.1.3 OSF định nghĩa [chỉ định: những trách nhiệm] về quản lý để xem xét các chính sách an toàn thông tin tại các khoảng thời gian theo kế hoạch hoặc khi có những thay đổi đáng kể để đảm bảo tín hiệu quả, thích hợp, an toàn và tính liên tục.

B.8.4.5 FOM_ORG.2 Quản lý thành viên diễn đàn an toàn thông tin

Những phụ thuộc: FOD_ORG.2 Trách nhiệm quản lý diễn đàn an toàn thông tin

FOM_ORG.2.1 OSF định nghĩa [chỉ định: bổ nhiệm những người đại diện quản lý từ các bộ phận khác nhau của các tổ chức có vai trò và chức năng công việc liên quan] để quản lý diễn đàn an toàn thông tin để đảm bảo rằng các hoạt động an toàn thông tin đã được phối hợp.

B.8.5 Quản lý báo cáo sự cố bảo mật (FOM_INC)

B.3.5.1 Hành xử của họ

Họ này định nghĩa việc quản lý báo cáo các sự cố bảo mật. Nó bao gồm việc quản lý các vấn đề bảo mật đã báo cáo.

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

FOM_INC.1 Báo cáo các vấn đề về an toàn. Quản lý các vấn đề bảo mật đã báo cáo được định nghĩa.

B.8.5.3 Các bản ghi

Hệ thống vận hành sẽ duy trì và kiểm tra các bằng chứng sau đây.

a) FOM_INC.1: Mô tả các thủ tục báo cáo các sự cố bảo mật bằng những đặc tả và những hành động cụ thể và các bản ghi hướng dẫn kiểm soát.

B.8.5.4 FOM_INC.1 Báo cáo những vấn đề về an toàn

Những phụ thuộc: Không phụ thuộc.

FOM_INC.1.1 OSF định nghĩa [chỉ định: các thủ tục] để ghi chép và báo cáo bất kỳ điểm yếu nào về bảo mật quan sát được hoặc có nghi ngờ, hoặc các mối đe dọa đến các hệ thống và dịch vụ dưới quản lý của họ hoặc trực tiếp đến nhà cung cấp dịch vụ của họ càng nhanh càng tốt để ngăn chặn các sự cố bảo mật.

FOM_INC.1.2 OSF định nghĩa [chỉ định: các quy tắc] để ngăn cản lỗ lực chứng minh có những điểm yếu bị nghi ngờ tồn tại qua việc lỗ lực khai thác.

Phụ lục C

(Quy định)

Các yêu cầu đảm bảo cho các hệ thống vận hành

C.1 Giới thiệu

Phần này xác định các thành phần đảm bảo bổ sung cần thiết cho hoạt động của hệ thống bên cạnh những quy định tại TCVN 8709-3:2011. TCVN 8709-3:2011 được sử dụng làm cơ sở để tổ chức cho các thành phần này.

Bảo đảm an toàn được xem xét từ hai khía cạnh: Chính xác và Hiệu quả. Chính xác có nghĩa là các cơ chế an toàn đã được thực hiện một cách chính xác; Việc vận hành phù hợp với các thông số kỹ thuật an toàn và các đơn vị an toàn có sẵn được duy trì. Hiệu quả có nghĩa là các cơ chế an toàn chống lại các mối đe dọa an ninh, các điểm yếu và ngăn chặn việc xâm nhập hệ thống trái phép, ví dụ: bỏ qua các cơ chế an toàn hoặc can thiệp trái phép cơ chế an toàn. Đảm bảo có thể đạt được thông qua các hoạt động trên tất cả các giai đoạn của chu kỳ vòng đời hệ thống. Khái niệm này được minh họa trong Bảng C.1 sau

Chính xác và hiệu quả có thể được xác định bằng cách đánh giá an toàn. Ngoài ra, các hình thức đảm bảo có thể cần phải được đưa vào tài khoản, chẳng hạn như đảm bảo liên quan đến uy tín của các nhà phát triển hệ thống và đảm bảo có nguồn gốc từ sự trưởng thành của quá trình phát triển hệ thống sử dụng.

Nhiều khía cạnh đảm bảo của hệ thống vận hành được xác định bởi các tiêu chí đánh giá trong TCVN 8709-3:2011. Tuy nhiên, có một số khía cạnh đảm bảo của hệ thống vận hành cần bổ sung thêm các tiêu chí cần thiết.

Bảng C.2 - Đảm bảo hoạt động của hệ thống

Các yếu tố	Giai đoạn vòng đời	Mục tiêu đảm bảo	Đảm bảo lớp/họ	Hoạt động đánh giá
Hiệu quả	Phát triển/Tích hợp	Đối phó rủi ro Các yêu cầu an toàn cho đánh giá rủi ro được nêu cụ thể trong SST có hiệu quả trong việc giảm thiểu rủi ro từ mức không thể chấp nhận được đến mức có thể chấp nhận được.	Đánh giá SST/SPP (AST/ASP)	Mục tiêu an toàn giải quyết tất cả những rủi ro được xác định là không thể chấp nhận. Các yêu cầu an toàn phải phù hợp với các mục tiêu an toàn. Biện pháp đối phó an toàn phải đáp ứng các đặc điểm kỹ thuật tổng thể STOE.
	Phát triển/Tích hợp	Kiến trúc vận hành hệ thống. Biện pháp đối phó an toàn của các phân hệ, các thành phần, … tích hợp cùng nhau để tạo ra các thuộc tính an toàn cho toàn bộ hệ thống.	Mô tả kiến vận hành hệ thống ASD_SAD) Khái niệm an toàn vận hành (ASD_CON) Giao diện an toàn (ASD_IFS) Thiết kế STOE (ASD_STD)	Biện pháp đối phó an toàn thực hiện có hiệu quả khi kết hợp với các biện pháp đối phó khác.
	Cài đặt	Độ mạnh của các cơ chế an toàn. Độ mạnh của các cơ chế an toàn có hiệu quả cho hệ thống.	Đánh giá điểm yếu (AOV_VAN)	Thực hiện phân tích điểm yếu và các điểm yếu này không thể bị khai thác bởi (cuộc) tấn công tiềm ẩn được giả định. Tiến hành thâm nhập thử nghiệm và không có các vấn đề về an toàn
	Cài đặt	Trao đổi và đào tạo nâng cao kiến thức. Các quy tắc và thủ tục được truyền đạt và đào tạo cho nhân viên phù hợp có hiệu quả.	Xác nhận trao đổi và nhận thức (APR_CMM, APR_AWA)	Trao đổi và nhận thức được xác nhận bởi hồ sơ và phỏng vấn.
	Vận hành	Giám sát đối phó an toàn Nhật ký đánh giá và hồ sơ giám sát được tập hợp cho thấy biện pháp đối phó an toàn hoạt động đúng dự định.	Giám sát SSF (ASO_MON)	Biện pháp đối phó an toàn được xác nhận là vận hành đúng như dự định.
	Vận hành	Xác minh Phải xác nhận rằng không có rủi ro nào được phát hiện mà không được đối phó và thực hiện các biện pháp an toàn như mong muốn.	Kiểm tra hoạt động của SSF (AOD_OGD, APR_AWA, APR_CMM, ASO_RCD, ASO_VER)	Xác nhận rằng không có rủi ro không thể chấp nhận được phát hiện.
	Hiệu chỉnh	Kiểm tra hồi quy Kiểm soát an toàn tiếp tục làm việc đúng dự định.	Kiểm tra hồi quy (AOT_REG)	Các vấn đề an toàn phát hiện ra sẽ được điều tra và có kết quả trả lời.
	Hiệu chỉnh	Thâm nhập thử nghiệm Các thay đổi hệ thống không các yếu điểm trong phạm vi kiểm soát an toàn.	Thâm nhập thử nghiệm (AOV_VAN) Xác minh cấu hình chính xác (AOD_OCD)	Các vấn đề an toàn phát hiện được sẽ được nghiên cứu kỹ và lặp lại quá trình.
Chính xác	Phát triển/Tích hợp	Sự tương ứng giữa các rủi ro an toàn và các yêu cầu an toàn, giữa các yêu cầu an toàn và biện pháp đối phó an toàn. Các yêu cầu an toàn giải quyết tất cả các rủi ro không thể chấp nhận. Biện pháp đối phó an toàn đáp ứng tất cả các yêu cầu an toàn.	Đánh giá SST/SPP (AST/ASP)	Các mục tiêu an toàn đưa ra tất cả các rủi ro được xác định là không thể chấp nhận Các yêu cầu an toàn phải tương ứng với các mục tiêu an toàn Biện pháp đối phó an toàn phải đáp ứng các đặc điểm kỹ thuật tổng thể STOE
		Tương ứng với quá trình phát triển, Các biện pháp đối phó an toàn được thực hiện một cách chính xác. Các biện pháp đối phó an toàn à phân loại à triển khai	Mô tả kiến trúc hoạt động hệ thống (ASD_SAD) Giao diện an toàn (ASD_IFS) Khái niệm an toàn vận hành (ASD_CON) Thiết kế STOE (ASO_STD) Thử nghiệm (AOT)	Biện pháp đối phó an toàn được thực hiện mà không sửa đổi trái phép, bổ sung hoặc xóa bỏ.
		Mô tả các tài liệu hướng dẫn Hoạt động an toàn được mô tả chính xác trong các tài liệu hướng dẫn.	Mô tả (AOD_OCD, AOD_OGD)	Cấu hình và hoạt động của biện pháp đối phó an toàn phải được mô tả đầy đủ.
	Cài đặt	Cấu hình Các thành phần và các phân hệ được cấu hình đúng.	Cấu hình (AOD_OCD, AOC) Kiểm tra (AOT)	Kiểm soát xác nhận việc cấu hình và hoạt động của thành phần và phân hệ.
	Cài đặt	Khởi động Khởi động STOE thực hiện một cách chính xác.	Cài đặt và khởi động (APR_SIC)	Xác nhận cài đặt và khởi động chính xác.
	Vận hành	Giám sát biện pháp đối phó an toàn Biện pháp đối phó an toàn được điều hành một cách chính xác.	Giám sát (ASO_MON)	Kiểm tra vết, giám sát bản ghi truy nhập truy nhập và hiệu quả sử dụng tài nguyên.
		Xác minh Phải khẳng định rằng không có rủi ro bị phát hiện cần khắc phục và kiểm soát an toàn thực hiện như mong đợi	Xác minh cài đặt an toàn (APR_SIC) Xác minh các hồ sơ (ASO_RCD) Xác minh độc lập (ASO_VER)	Xác nhận kiểm soát an toàn
		Xác minh yêu cầu Khẳng định việc hiệu chỉnh, sửa đổi không làm mất hiệu lực các yêu cầu SST	Yêu cầu xác minh (ASD_RVR)	Phân tích các yêu cầu thay đổi.
	Hiệu chỉnh	Xác minh thiết kế Khẳng định việc hiệu chỉnh, sửa đổi không làm mất hiệu lực các thành phần của thiết kế.	Xác minh thiết kế (AOD_GVR, ASD_DVR)	Phân tích các thay đổi thiết kế.
	Hiệu chỉnh	Thử nghiệm hồi quy khẳng định kiểm soát an toàn thay đổi làm việc như dự định.	Thử nghiệm hồi quy (AOT_REG)	Các vấn đề an toàn phát hiện được sẽ được điều tra và có kết quả trả lời

Chín yêu cầu đảm bảo mới được quy định tại mục này là:

a) Đánh giá SPP (ASP);

b) Đánh giá SST (ASS);

c) Tài liệu hướng dẫn hệ thống vận hành (AOD);

d) Kiến trúc hoạt động của hệ thống, Tài liệu thiết kế và cấu hình (ASD);

e) Quản lý cấu hình hoạt động của hệ thống (AOC);

f) Kiểm thử hoạt động của hệ thống (AOT);

g) Đánh giá điểm yếu hệ thống vận hành (AOV);

h) Chuẩn bị vận hành, khai thác (APR);

i) Hồ sơ hoạt động của hệ thống (ASO).

Có lớp đảm bảo mới cho việc đánh giá hồ sơ bảo vệ hệ thống (SPP), đích an toàn hệ thống (SST), khi nội dung của SPP hoặc SST được nâng cấp, mở rộng bởi nhà sản xuất PP hoặc ST, cần bổ sung các yêu cầu đảm bảo mới cho việc đánh giá hồ sơ bảo vệ hệ thống (SPP) và mục tiêu an toàn hệ thống (SST).

Mối quan hệ giữa các yêu cầu đảm bảo bổ sung quy định tại phụ lục này và bốn giai đoạn của vòng đời được mô tả trong Bảng C.2.

Bảng C.2 - Các yêu cầu đảm bảo và vòng đời của hệ thống vận hành

Vòng đời	Yêu cầu đảm bảo
	AOD_OCD.1	Mô tả các đặc điểm kỹ thuật cấu hình.
	AOD_OGD.1	Mô tả người sử dụng liên quan SSFs trong hướng dẫn sử dụng.
	ASD_SAD.1	Mô tả kiến trúc.
	ASD_CON.1	Khái niệm an toàn vận hành.
	ASD_IFS.1	Mô tả các giao diện bên ngoài.
Phát triển / Tích hợp	ASD_STD.1-3	Mô tả thiết kế STOE
Phát triển / Tích hợp	AOT_COV.1	Kiểm thử tổng thể đối với SSFs
	AOT_COV.2	Kết thúc kiểm thử tổng thể đối với SSFs
	AOT_DPT.1	Kiểm thử năng lực đối với thiết kế phân hệ
	AOT_DPT.2	Kiểm thử năng lực đối với thiết kế thành phần
	AOT_DPT.3	Kiểm thử năng lực triển khai
	AOT_FUN.1	Kiểm thử chức năng đối với SSFs
	AOD_OCD.2	Xác minh đặc điểm kỹ thuật cấu hình
	AOC_OBM.1-2	Quản lý cấu hình hoạt động
	AOC_ECP.1-2	Cấu hình của sản phẩm phần đánh giá
	AOC_UCP.1-2	Cấu hình của sản phẩm phần không được đánh giá
	AOT_COV.1	Kiểm thử tổng thể đối với SSFs
	AOT_COV.2	Kết thúc kiểm thử tổng thể đối với SSFs
	AOT_DPT.1	Kiểm thử độ sâu đối với thiết kế phân hệ
Cài đặt	AOT_DPT.2	Kiểm thử độ sâu đối với thiết kế thành phần
	AOT_DPT.3	Kiểm thử độ sâu triển khai
	AOT_FUN.1	Kiểm thử chức năng đối với SSFs
	AOT_IND.1-3	Kiểm thử độc lập
	AOV_VAN.1-7	Đánh giá điểm yếu
	APR_AWA.1	Đào tạo nâng cao
	APR_CMM.1	Truyền đạt về SSFs cho nhân viên thích hợp
	APR_SIC.1	Cài đặt an toàn và khởi động STOE
	AOD_OGD.2	Xác minh sử dụng SSFs trong hướng dẫn sử dụng
	APR_AWA.2	Xác minh đào tạo nâng cao
	APR_CMM.2	Xác minh truyền đạt về SSFs cho nhân viên thích hợp
Vận hành	APR_SIC-2	Xác minh cài đặt an toàn và khởi động
	ASO_RCD.1-2	Xác minh hồ sơ hoạt động
	ASO_VER.1-2	Xác minh kiểm soát hoạt động
	ASO-MON.1-2	Giám sát quản lý đối với SSFs
Hiệu chỉnh	AOD_GVR.1	Xác minh tài liệu hướng dẫn
	ASD_RVR.1	Xác minh yêu cầu
	ASD_DVR.1	Xác minh thiết kế
	AOT_REG.1	Thử nghiệm hồi quy
	AOV_VAN.1-7	Thử nghiệm thâm nhập

Có hai điểm khác biệt trình bày trong phụ lục này so với TCVN 8709-3. Thành phần nhà phát triển (Developer) đã được đổi tên thành nhà phát triển/nhà tích hợp (devetoper/integrator), để chỉ ra rằng một hệ thống vận hành có thể xây dựng bởi nhà tích hợp hệ thống khác biệt với nhà phát triển các thành phần và sản phẩm sử dụng trong hệ thống và cả hai có thể hợp tác trong việc sản xuất và cung cấp chứng chỉ cần thiết. Trong một số trường hợp, quản lý hệ thống vận hành là người chịu trách nhiệm cung cấp các bằng chứng và như vậy trong họ đủ các yếu tố hành động để cung cấp bằng chứng được xác định là hoạt động quản lý.

Sư phụ thuộc giữa các thành phần đảm bảo được thể hiện trong các bảng C.3 đến C.5 dưới đây. Ba bảng đánh giá được sử dụng là SPP, SST và STOE thực hiện một cách độc lập và không phụ thuộc lẫn nhau giữa các bảng. Mỗi thành phần là một sự phụ thuộc của một số thành phần đảm bảo trong một cột. Mỗi thành phần đảm bảo có sự phụ thuộc nằm trong một bảng. Các giá trị trong bảng nếu yêu cầu được biểu thị là 'X', không yêu cầu biểu thị là '-'.

Bảng C.3 - Phụ thuộc đảm bảo SPP

	ASP_INT.1	ASP_ECD.1	ASP_SPD.1	ASP_OBJ.1	ASP_REQ.1	ASP_DMP.1	ASP_DMO.	ASP_DMR.
ASP_CCL.1	X	X	X	X	X
ASP_OBJ.1			X
ASP_REQ.1		X
ASP_REQ.2		X	-	X
ASP_DMI.1	X
ASP_DMC.1	-	-				X	X	X
ASP_DMO.1	X					X
ASP_DMR.1		X
ASP_DMR.2	-	X				-	X

Bảng C.4 - Phụ thuộc đảm bảo SST

	ASS_INT.1	ASS_ECD.1	ASS_SPD.1	ASS_OBJ.1	ASS_REQ.1	ASS_DMP.1	ASS_DMP.1	ASS_DMO.	ASS_DMR.
ASS_CCL.1	X	X	X	X	X
ASS_OBJ.1			X
ASS_REQ.1		X	-	X
ASS_REQ.2		X
ASS_TSS.1	X	-			X
ASS_DMI.1	X
ASS_DMC.1	-	-					X	X	X
ASS_DMO.1	X						X
ASS_DMR.1		X
ASS_DMR.2	-	X					-	X
ASS_DMS.1	-	-				X			X

Bảng C.5 - Phụ thuộc đảm bảo STOE

	AOD_OCD.	AOD_OGD.	ASD_SAD.1	ASD_CON.	ASD_IFS.1	ASD_STD.1	ASD_STD.2	ASD_STD.3	AOC_OBM.	AOT_FUN.1
AOD_OCD.1/2			-	X	-		X
AOD_OGD.1/2			X
AOD_GVR.1	X	X	-	-		-
ASD_CON.1			X
ASD_IFS.1			X
ASD_STD.1-3			X		X
ASD_DVR.1			X	X	X	X
AOC_ECP.1/2									X
AOC_UCP.1/2									X
AOT_COV.1/2			-		X					X
AOT_DPT.1			-		-	X				X
AOT_DPT.2			-		-		X			X
AOT_DPT.3			-		-			X		X
AOT_IND.1		X	-		X
AOT_IND.2/3		X	-		X					X
AOV_VAN.1		X	X
OV_VAN.2		X	X	X
AOV_VAN.3		X	X	X	X
AOV_VAN.4-7		X	X	X	X	X

C.2 Lớp ASP: Đánh giá hồ sơ bảo vệ hệ thống

C.2.1 Giới thiệu

Mục này cung cấp các tiêu chí đảm bảo cho việc đánh giá hồ sơ bảo vệ hệ thống (SPP). Đánh giá SPP là cần thiết để chứng minh rằng một SPP là đúng đắn, có nguồn gốc phù hợp và nếu một SPP được hình thành từ một hoặc nhiều SPPs hoặc các gói thì SPP được cài đặt chính xác của nhiều SPPs hoặc các gói đó. Các tính chất này là cần thiết đối với SPP được sử dụng làm cơ sở để đánh giá STOE tiếp theo. Các tính chất này gồm:

a) ASP_INT: Giới thiệu SPP;

b) ASP_CCL: Tuyên bố sự phù hợp;

c) ASP_SPD: Định nghĩa vấn đề an toàn;

d) ASP_OBJ: Mục tiêu an toàn;

e) ASP_ECD: Định nghĩa thành phần mở rộng;

f) ASP_REQ: Các yêu cầu an toàn;

g) ASP_DMI: Giới thiệu miền an toàn;

h) ASP_DMC: Tuyên bố sự phù hợp miền an toàn;

i) ASP_DMP: Định nghĩa vấn đề an toàn miền an toàn;

j) ASP_DMO: Mục tiêu an toàn miền an toàn;

k) ASP_DMR: Các yêu cầu an toàn miền an toàn.

C.2.2 Lớp ASP: Đánh giá hồ sơ bảo vệ hệ thống

Các thông số kỹ thuật sau đây áp dụng cho SPP. Thông số kỹ thuật cho các miền cụ thể sẽ được mô tả bằng cách sử dụng các họ miền (xem mục C.2.9).

C.2.3 Giới thiệu SPP (ASP_INT)

C.2.3.1 Mục tiêu

Để mô tả STOE một cách tường minh.

Đánh giá việc giới thiệu SPP là cần thiết để chứng minh rằng SPP được xác định một cách chính xác và cung cấp cái nhìn tổng quan về STOE cũng như các đặc tả tổ chức miền phù hợp. Miền an toàn cụ thể được mô tả trong mục C.2.10: Giới thiệu miền an toàn.

C.2.3.2 Giới thiệu SPP ASP_INT.1

C.2.3.2.1 Phát triển/tích hợp

ASP_INT.1.1D - Nhà phát triển/tích hợp sẽ cung cấp một giới thiệu SPP.

C.2.3.2.2 Nội dung và mô tả các bằng chứng

ASP_INT.1.1C - Việc giới thiệu SPP phải có tài liệu tham chiếu SPP, tổng quan về STOE và đặc tả tổ chức miền.

ASP_INT.1.2C - Tài liệu tham chiếu SPP xác định một SPP duy nhất.

ASP_INT.1.3C - Tổng quan STOE tổng hợp việc sử dụng và các tính năng an toàn chính của STOE.

ASP_INT.1.4C - Tổng quan STOE xác định loại STOE.

ASP_INT.1.5C - Tổng quan STOE xác định các được mối quan hệ và giao tiếp với bất kỳ hệ thống hoạt động bên ngoài theo yêu cầu của STOE.

ASP_INT.1.6C - Đặc tả tổ chức miền mô tả việc tổ chức các miền an toàn bắt buộc và nhận dạng chúng.

ASP_INT.1.7C - Đối với từng miền, đặc tả tổ chức miền phải mô tả bất kỳ dịch vụ an toàn nào được cung cấp bởi miền đó mà có sẵn cho các miền khác và các tính chất an toàn bất kỳ của miền đó sẽ được thực thi trên các miền khác.

C.2.3.2.3 Hành động đánh giá

ASP_INT.1.1E: Người đánh giá sẽ xác nhận các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các bằng chứng.

ASP_INT.1.2E: Người đánh giá sẽ xác nhận tổng quan STOE và đặc tả tổ chức miền phù hợp với nhau.

C.2.4 Tuyên bố phù hợp (ASP_CLL)

C.2.4.1 Mục tiêu

Để xác định tính hợp lệ của các tuyên bố phù hợp khác nhau: tuyên bố phù hợp tiêu chuẩn TCVN 8709, tuyên bố phù hợp SPP, tuyên bố phù hợp PPs và yêu cầu tuyên bố gói. Tuyên bố phù hợp tiêu chuẩn TCVN 8709 mô tả các phiên bản của tiêu chuẩn TCVN 8709 mà SPP và STOE tuyên bố tuân thủ, tuyên bố PPs (nếu có) mô tả cách thức SPP tuyên bố phù hợp với các PP xác định, tuyên bố gói (nếu có) mô tả cách thức SPP tuyên bố phù hợp với các gói đó khi yêu cầu SPP xác định SPPs (nếu có) SPP phù hợp tuyên bố.

Tuyên bố sự phù hợp đối với một miền an toàn cụ thể được quy định tại mục C.2.11: Tuyên bố phù hợp miền an toàn

C.2.4.2 Các lưu ý áp dụng

Nếu một SPP tuyên bố phù hợp với một PP, nó phải thể hiện như một phần của tính nhất quán của các yêu cầu an toàn và định nghĩa OSF phải đáp ứng các giả định về môi trường vận hành trong phần định nghĩa vấn đề an toàn của PP.

C.2.4.3 Tuyên bố phù hợp ASP_CCL.1

Những phụ thuộc:

ASP_INT.1 - Giới thiệu SPP

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

ASP_OBJ.1 - Mục tiêu an toàn

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

ASP_REQ.1 - Yêu cầu an toàn đã quy định

C.2.4.3.1 Hành động phát triển/tích hợp

ASP_CCL.1.1D - Nhà phát triển/tích hợp cung cấp tuyên bố phù hợp.

ASP_CCL.1.2D - Nhà phát triển/tích hợp cung cấp sở cứ của tuyên bố phù hợp.

C.2.4.3.2 Nội dung và mô tả các bằng chứng

ASP_CCL.1.1C - Tuyên bố phù hợp phải có tuyên bố phù hợp tiêu chuẩn để xác định các phiên bản của tiêu chuẩn TCVN xxxx:201x mà SPP tuyên bố phù hợp.

ASP_CCL.1.2C - Tuyên bố phù hợp tiêu chuẩn phải mô tả sự phù hợp chức năng của SPP với tiêu chuẩn ISO/IEC TR 19791 là chức năng tuân thủ tiêu chuẩn ISO/IEC TR 19791 hoặc chức năng mở rộng tiêu chuẩn TCVN xxxx:201x.

ASP_CCL.1.3C - Tuyên bố phù hợp tiêu chuẩn phải mô tả sự phù hợp đảm bảo của SPP với tiêu chuẩn TCVN xxxx:201x là đảm bảo tuân thủ tiêu chuẩn TCVN xxxx:201x hoặc đảm bảo mở rộng tiêu chuẩn TCVN xxxx:201x.

ASP_CCL.1.4C - Tuyên bố phù hợp tiêu chuẩn phải phù hợp với các thành phần định nghĩa mở rộng.

ASP_CCL.1.5C - Tuyên bố phù hợp phải xác định tất cả SPPs, PP và các gói yêu cầu an toàn mà SPP tuyên bố phù hợp.

ASP_CCL.1.6C - Tuyên bố phù hợp phải mô tả sự phù hợp bất kỳ nào của SPP với một gói là gói tuân thủ (package-conformant) hoặc gói tăng cường (package-augmented).

ASP_CCL.1.7C - Sở cứ tuyên bố phù hợp phải chứng minh rằng loại STOE phù hợp với loại STOE trong SPPs và PP là phù hợp với tuyên bố.

ASP_CCL.1.8C - Sở cứ tuyên bố phù hợp phải chứng minh rằng nội dung định nghĩa vấn đề an toàn phù hợp với nội dung định nghĩa vấn đề an toàn trong SPPs và PP là phù hợp với tuyên bố.

ASP_CCL.1.9C - Sở cứ tuyên bố phù hợp phải chứng minh rằng nội dung mục tiêu phù hợp với nội dung mục tiêu trong SPPs và PP là phù hợp với tuyên bố.

ASP_CCL.1.10C - Sở cứ tuyên bố phù hợp phải chứng minh rằng nội dung yêu cầu an toàn phù hợp với nội dung yêu cầu an toàn trong SPPs, PP và gói là phù hợp với tuyên bố.

C.2.4.3.3 Hành động đánh giá

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

C.2.5 Định nghĩa vấn đề an toàn (ASP_SPD)

C.2.5.1 Mục tiêu

SPP định nghĩa các vấn đề an toàn áp dụng cho các STOE. Vấn đề an toàn cho một miền an toàn cụ thể được quy định tại mục C.2.12: Định nghĩa vấn đề miền an toàn. Hoạt động đánh giá định nghĩa vấn đề an toàn là cần thiết để chứng minh rằng các vấn đề an toàn dự định áp dụng cho các STOE được định nghĩa tường minh.

C.2.5.2 Định nghĩa vấn đề an toàn ASP_SPD.1

C.2.5.2.1 Hành động phát triển/tích hợp

ASP_SPD.1.1D - Nhà phát triển/tích hợp phải đưa ra định nghĩa vấn đề an toàn.

C.2.5.2.2 Nội dung và mô tả các bằng chứng

ASP_SPD.1.1C - Định nghĩa vấn đề an toàn sẽ mô tả tất cả những rủi ro đối với STOE. Rủi ro được phân loại là rủi ro chấp nhận được hoặc rủi ro không chấp nhận được.

ASP_SPD.1.2C - Tất cả những rủi ro không thể chấp nhận được mô tả là các mối đe dọa và các điểm yếu. Mối đe dọa được mô tả là tác nhân đe dọa, tài sản, và hành động có hại.

ASP_SPD.1.3C - Định nghĩa vấn đề an toàn mô tả các OSPs.

C.2.5.3 Hành động đánh giá

ASP_SPD.1.1E - Người đánh giá sẽ xác nhận các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và trình bày các bằng chứng.

C.2.6 Mục tiêu an toàn (ASP_OBJ)

C.2.6.1 Mục tiêu

Các mục tiêu an ninh là một tuyên bố ngắn gọn của các phản ứng có ý định về vấn đề an toàn được xác định thông qua họ ASP_SPD. Mục tiêu an toàn quy định tại phần này áp dụng cho các STOE. Mục tiêu an toàn cho một miền an toàn cụ thể được quy định tại mục C.2.13: Mục tiêu an toàn miền an toàn.

Hoạt động đánh giá mục tiêu an ninh là cần thiết để chứng minh rằng các mục tiêu an toàn chức năng đầy đủ và quyết định hoàn toàn định nghĩa vấn đề an toàn, ranh giới phân chia giữa STOE và hệ thống hoạt động bên ngoài được xác định tường minh.

C.2.6.2 Các lưu ý áp dụng

Sở cứ mục tiêu an toàn phải giải thích tại sao các mục tiêu an toàn đảm bảo đã được lựa chọn. Điều này là kết quả của việc phân tích rủi ro, nhưng cũng có thể phụ thuộc vào thực tế và khả năng đạt được và thậm chí có thể tùy chọn. Các sở cứ đưa ra không cần phải được xác minh.

C.2.6.3 Mục tiêu an toàn ASP_OBJ.1

Mục tiêu an toàn ASP_OBJ.1 phụ thuộc vào định nghĩa vấn đề an toàn ASP_SPD.1

C.2.6.3.1 Hành động phát triển/tích hợp

ASP_OBJ.1.1D - Nhà phát triển/tích hợp phải cung cấp nội dung mục tiêu an toàn.

ASP_OBJ.1.2D - Nhà phát triển/tích hợp phải cung cấp sở cứ mục tiêu an toàn.

C.2.6.3.2 Nội dung và mô tả các bằng chứng

ASP_OBJ.1.1C - Nội dung của mục tiêu an toàn phải mô tả mục tiêu an toàn chức năng cho STOE.

ASP_OBJ.1.2C - Nội dung của mục tiêu an toàn phải mô tả mục tiêu an toàn chức năng bất kỳ đáp ứng bởi hệ thống hoạt động bên ngoài.

ASP_OBJ.1.3C - Nội dung của mục tiêu an toàn phải mô tả mục tiêu an toàn bảo đảm cho STOE.

ASP_OBJ.1.4C - Sở cứ mục tiêu an toàn phải theo dõi từng mục tiêu an toàn mà hệ thống hoạt động bên ngoài mang lại để chống đỡ rủi ro bởi mục tiêu an toàn đó và OSPs được thực thi bởi các mục tiêu an toàn đó.

ASP_OBJ.1.5C - Sở cứ mục tiêu an toàn phải theo dõi từng mục tiêu an toàn mà STOE mang lại để chống đỡ rủi ro bởi mục tiêu an toàn đó và OSPs được thực thi bởi các mục tiêu an toàn đó.

ASP_OBJ.1.6C - Sở cứ mục tiêu an toàn phải chứng minh rằng các mục tiêu an toàn chức năng chống lại tất cả những rủi ro không thể chấp nhận.

ASP_OBJ.17C - Sở cứ mục tiêu an toàn phải chứng minh rằng các mục tiêu an toàn chức năng thực thi trên tất cả các OSP.

ASP_OBJ.1.8C - Sở cứ mục tiêu an toàn phải giải thích tại sao các mục tiêu an toàn đảm bảo cho STOE đã được lựa chọn.

C.2.6.3.3 Hành động đánh giá

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

C.2.7 Định nghĩa thành phần mở rộng (ASP_ECD)

C.2.7.1 Mục tiêu

Yêu cầu an toàn mở rộng là các yêu cầu không dựa trên các thành phần từ tiêu chuẩn TCVN 8709 hoặc tiêu chuẩn này, nhưng vẫn dựa trên các thành phần mở rộng được xác định bởi tác giả SPP. Việc đánh giá định nghĩa thành phần mở rộng là cần thiết để xác định chúng rõ ràng, tường minh và cần thiết.

C.2.7.2 Định nghĩa thành phần mở rộng ASP_ECD.1

Thành phần mở rộng ASP_ECD.1 là phụ thuộc hoặc không phụ thuộc.

C.2.7.2.1 Hành động phát triển/tích hợp

ASP_ECD.1.1D - Nhà phát triển/tích hợp phải cung cấp nội dung các yêu cầu an toàn.

ASP_ECD.1.2D - Nhà phát triển/tích hợp phải cung cấp định nghĩa thành phần mở rộng.

C.2.7.2.2 Nội dung và mô tả các bằng chứng

ASP_ECD. 1.1C - Nội dung của yêu cầu an toàn phải xác định tất cả các yêu cầu an toàn mở rộng.

ASP_ECD.1.2C - Định nghĩa thành phần mở rộng phải quy định thành phần mở rộng cho từng yêu cầu an toàn mở rộng.

ASP_ECD.1.3C - Định nghĩa thành phần mở rộng phải mô tả quan hệ của mỗi thành phần mở rộng với các thành phần hiện có, họ và lớp trong tiêu chuẩn TCVN 8709 hoặc tiêu chuẩn này.

ASP_ECD.1.4C - Định nghĩa thành phần mở rộng sử dụng các thành phần hiện có, họ, lớp và phương pháp trong tiêu chuẩn TCVN 8709 hoặc tiêu chuẩn này làm mô hình thực hiện.

ASP_ECD.1.5C - Thành phần mở rộng sẽ bao gồm các phần tử đo lường được và khách quan và có thể chứng minh được đó là thành phần mở rộng tuân thủ hay không tuân thủ.

C.2.7.3 Hành động đánh giá

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

ASP_ECD.1.2E - Người đánh giá phải xác nhận rằng không có phần mở rộng có thể được thể hiện rõ ràng bằng cách sử dụng các thành phần hiện có.

C.2.8 Yêu cầu an toàn (ASP_REQ)

C.2.8.1 Mục tiêu

SSFs tạo thành một mô tả rõ ràng và tường minh về các cơ chế an toàn dự kiến của STOE. SSAS tạo thành một mô tả rõ ràng và tường minh các hoạt động dự kiến sẽ được thực hiện để đạt được sự đảm bảo trong STOE. Các yêu cầu an toàn trong mục này được áp dụng cho các STOE

Yêu cầu an toàn cho một miền an toàn cụ thể được quy định tại mục C.2.14: Yêu cầu an toàn miền an toàn. Việc đánh giá về các yêu cầu an toàn là cần thiết để đảm bảo rằng chúng là rõ ràng và tường minh.

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

Họ này có hai thành phần. Các thành phần trong họ này được phân mức theo thành phần được công nhận hoặc thành phần phát sinh từ các mục tiêu an toàn cho STOE.

C.2.8.3 Yêu cầu an toàn thành phần công nhận ASP_REQ.1

Thành phần an toàn công nhận ASP_REQ.1 phụ thuộc vào định nghĩa thành phần mở rộng ASP_ECD.1.

C.5.2.8.3.1 Hành động phát triển tích hợp

ASP_REQ.1.1D - Nhà phát triển/tích hợp phải cung cấp nội dung các yêu cầu an toàn

ASP_REG.1.2D - Nhà phát triển/tích hợp phải cung cấp sở cứ các yêu cầu an toàn.

C.2.8.3.2 Nội dung và mô tả các bằng chứng

ASP_REQ. 1.1C - Nội dung của yêu cầu an toàn phải mô tả SSPs và SSAS.

ASP_REQ.1.2C - Tất cả các lĩnh vực, đối tượng, hoạt động, thuộc tính an toàn, thực thể bên ngoài và các thuật ngữ khác được sử dụng trong SSFs và SSAS phải được xác định.

ASP_REQ.1.3C - Nội dung của yêu cầu an toàn phải xác định tất cả các hoạt động về các yêu cầu an toàn.

ASP_REQ.1.4C - Mọi hoạt động phải được thực hiện một cách chính xác.

ASP_REQ.1.5C - Sự phụ thuộc giữa yêu cầu an toàn hoặc được đáp ứng hoặc các sở cứ yêu cầu an toàn biện minh cho sự phụ thuộc không được đáp ứng.

ASP_REQ.1.6C - Nội dung của yêu cầu an toàn phải có nguồn gốc phù hợp.

C.2.8.3.3 Hành động đánh giá

ASP_REQ.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.2.8.4 Yêu cầu an toàn thành phần phát sinh ASP_REQ.2

Phân cấp theo yêu cầu an toàn thành phần công nhận ASP_REQ.1;

Phụ thuộc vào: - Mục tiêu an toàn ASP_OBJ.1

- Định nghĩa thành phần mở rộng ASP_ECD.1

C.2.8.4.1 Hành động phát triển/tích hợp

ASP_REQ.2.1D - Nhà phát triển/tích hợp phải cung cấp nội dung các yêu cầu an toàn.

ASP_REQ.2.2D - Nhà phát triển/tích hợp phải cung cấp sở cứ các yêu cầu an toàn.

C.2.8.4.2 Nội dung và mô tả các bằng chứng

ASP_REQ.2.1C - Nội dung của yêu cầu an toàn phải được mô tả trong SSFs và SSAS.

ASP_REQ.2.2C - Tất cả các lĩnh vực, đối tượng, hoạt động, thuộc tính an toàn, thực thể bên ngoài và các thuật ngữ khác được sử dụng trong SSFs và SSAS phải được xác định.

ASP_REQ.2.3C - Nội dung của yêu cầu an toàn phải xác định tất cả các hoạt động về các yêu cầu an toàn.

ASP_REQ.2.4C - Mọi hoạt động phải được thực hiện một cách chính xác.

ASP_REQ.2.5C - Sự phụ thuộc giữa yêu cầu an toàn hoặc được đáp ứng hoặc các sở cứ yêu cầu an toàn biện minh cho sự phụ thuộc không được đáp ứng.

ASP_REQ.2.6C - Sở cứ yêu cầu an toàn phải theo dõi từng mục tiêu an toàn chức năng mà SSF trả về cho STOE.

ASP_REQ.2.7C - Sở cứ yêu cầu an toàn phải chứng minh rằng SSFs đáp ứng tất cả mục tiêu an toàn chức năng cho STOE mà không đáp ứng bởi hệ thống bên ngoài hoặc miền riêng.

ASP_REQ.2.8C - Sở cứ yêu cầu an toàn theo dõi từng SSA trở lại các mục tiêu an toàn đảm bảo cho STOE.

ASP_REQ.2.9C - Sở cứ yêu cầu an toàn phải chứng minh rằng SSAS đáp ứng tất cả các mục tiêu an toàn đảm bảo cho STOE mà không đáp ứng bởi các miền riêng

ASP_REQ.2.10C - Nội dung của yêu cầu an toàn phải có nguồn gốc phù hợp.

C.2.8.4.3 Hành động đánh giá

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

C.2.9 Miền an toàn SPP

Mỗi một miền an toàn SPP xác định các vấn đề an toàn, mục tiêu an toàn và các yêu cầu an toàn là duy nhất cho một miền an toàn cụ thể.

Mục này định nghĩa các họ được sử dụng để xác định các miền an toàn trong SPP.

C.2.10 Giới thiệu miền an toàn (ASP_DMI)

C.2.10.1 Mục tiêu

Mục tiêu của họ này là để mô tả một miền an toàn một cách chi tiết theo ba cấp độ trừu tượng: miền an toàn tham chiếu, miền an toàn tổng quan và miền an toàn mô tả.

C.2.10.2 Giới thiệu miền an toàn ASP_DMI.1

Phụ thuộc vào giới thiệu SPP ASP_INT.1

C.2.10.2.1 Hành động phát triển/tích hợp

ASP_DMI.1.1D - Nhà phát triển/tích hợp phải cung cấp giới thiệu miền an toàn.

C.2.10.2.2 Nội dung và mô tả các bằng chứng

ASP_DMI.1.1C - Giới thiệu miền an toàn phải bao gồm miền an toàn tham chiếu, miền an toàn tổng quan và miền an toàn mô tả.

ASP_DMI.1.2C - Tham chiếu miền an toàn được xác định là duy nhất trong một miền an toàn.

ASP_DMI.1.3C - Tổng quan miền an toàn phải tóm tắt cách sử dụng và các tính năng an toàn chính của miền an toàn.

ASP_DMI.1.4C - Mô tả miền an toàn phải trình bày các đầy đủ các phân hệ và/hoặc các thành phần.

ASP_DMI.1.5C - Mô tả miền an toàn phải trình bày các mối quan hệ và giao diện với các miền an toàn khác.

C.2.10.2.3 Hành động đánh giá

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

ASP_DMI.1.2E - Người đánh giá phải xác nhận rằng miền an toàn tham chiếu, miền an toàn tổng quan và miền an toàn mô tả phù hợp với nhau và với giới thiệu SPP.

C.2.11 Tuyên bố phù hợp miền an toàn (ASP_DMC)

C.2.11.1 Mục tiêu

SPP xác định các tuyên bố phù hợp duy nhất cho một an toàn.

C.2.11.2 Tuyên bố phù hợp miền an toàn ASP_DMC.1

Phụ thuộc vào: ASP_DMP.1 - Định nghĩa vấn đề an toàn miền an toàn;

ASP_DMO.1 - Mục tiêu an toàn miền an toàn;

ASP_DMR.1 - Yêu cầu an toàn miền tuyên bố.

C.2.11.2.1 Hành động phát triển/tích hợp

ASP_DMC.1.1D - Nhà phát triển/tích hợp phải cung cấp một tuyên bố phù hợp miền.

ASP_DMC.1.2D - Nhà phát triển/tích hợp phải cung cấp sở cứ tuyên bố phù hợp miền.

C.2.11.2.2 Nội dung và mô tả các bằng chứng

ASP_DMC.1.1C - Tuyên bố phù hợp miền phải xác định tất cả SPPs, PP và các gói yêu cầu an toàn mà miền tuyên bố phù hợp.

ASP_DMC.1.2C - Tuyên bố phù hợp miền phải mô tả sự phù hợp bất kỳ nào của miền với một gói là gói tuân thủ hoặc gói tăng cường.

ASP_DMC.1.3C - Sở cứ tuyên bố phù hợp miền phải chứng minh rằng các loại STOE là phù hợp với các loại STOE trong SPPs và PP phù hợp với tuyên bố.

ASP_DMC.1.4C - Sở cứ tuyên bố phù hợp miền phải chứng minh rằng nội dung định nghĩa vấn đề an toàn miền phù hợp với nội dung định nghĩa vấn đề an toàn trong SPPs và PP phù hợp với tuyên bố.

ASP_DMC.1.5C - Sở cứ tuyên bố phù hợp miền phải chứng minh rằng nội dung của mục tiêu an toàn miền phù hợp với nội dung của mục tiêu trong SPPs và PP phù hợp với tuyên bố.

ASP_DMC.1.6C - Sở cứ tuyên bố phù hợp miền phải chứng minh rằng nội dung của yêu cầu an toàn miền phù hợp với nội dung của yêu cầu an toàn trong SPPs, PP và các gói phù hợp với tuyên bố.

C.2.11.2.3 Hành động đánh giá

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

C.2.12 Định nghĩa vấn đề an toàn miền an toàn (ASP_DMP)

C.2.12.1 Mục tiêu

SPP xác định các vấn đề an toàn duy nhất cho một miền an toàn.

C.2.12.2 Định nghĩa vấn đề an toàn miền an toàn ASP_DMP.1

C.2.12.2.1 Hành động phát triển/tích hợp

ASP_DMP.1.1D - Nhà phát triển/tích hợp sẽ cung cấp định nghĩa vấn đề an toàn miền.

C.2.12.2.2 Nội dung và mô tả các bằng chứng

ASP_DMP.1.1C - Định nghĩa vấn đề an toàn miền sẽ mô tả tất cả các rủi ro đặc biệt áp dụng cho miền. Rủi ro được phân loại là rủi ro chấp nhận được và rủi ro không chấp nhận được.

ASP_DMP.1.2C - Tất cả những rủi ro không thể chấp nhận được mô tả là các mối đe dọa và các điểm yếu. Mối đe dọa được mô tả là tác nhân đe dọa, tài sản, và hành động có hại.

ASP_DMP.1.30 - Định nghĩa vấn đề an toàn miền sẽ mô tả OSPs duy nhất có thể áp dụng cho miền.

C.2.12.3 Hoạt động đánh giá

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

C.2.13 Mục tiêu an toàn miền an toàn (ASP_DMO)

C.2.13.1 Mục tiêu

SPP xác định nội dung ngắn gọn của các phản ứng có dự định về vấn đề an toàn duy nhất được xác định thông qua họ ASP_DMP.

C.2.13.2 Mục tiêu an toàn miền an toàn ASP_DMO.1

Phụ thuộc vào: - Giới thiệu SPP ASP_INT.1

- Định nghĩa vấn đề an toàn miền an toàn ASP_DMP.1

C.2.13.2.1 Hành động phát triển/tích hợp

ASP_DMO.1.1D - Nhà phát triển/tích hợp sẽ cung cấp nội dung của các mục tiêu an toàn miền.

ASP_DMO.1.2D - Nhà phát triển/tích hợp sẽ cung cấp sở cứ mục tiêu an toàn miền.

C.2.13.2.2 Nội dung và mô tả các bằng chứng

ASP_DMO.1.1C - Nội dung của mục tiêu an toàn miền sẽ mô tả các mục tiêu an toàn chức năng duy nhất của miền.

ASP_DMO.1.2C - Tuyên bố mục tiêu an toàn miền sẽ mô tả các mục tiêu an toàn chức năng bất kỳ của miền được đáp ứng bởi các miền khác hoặc các hệ thống hoạt động bên ngoài.

ASP_DMO.1.3C - Tuyên bố mục tiêu an toàn miền sẽ mô tả các mục tiêu an toàn đảm bảo duy nhất cho của miền.

ASP_DMO.1.4C - Tuyên bố mục tiêu an toàn miền sẽ mô tả mục tiêu an toàn chức năng bất kỳ của miền đó được thực thi hoặc có sẵn trên miền khác.

ASP_DMO.1.5C- Sở cứ mục tiêu an toàn miền sẽ theo dõi từng mục tiêu an toàn chức năng duy nhất của miền đó mang lại để các rủi ro được khắc phục bởi các mục tiêu an toàn đó và OSP được thực thi bởi mục tiêu an toàn đó.

ASP_DMO.1.6C - Sở cứ mục tiêu an toàn miền sẽ theo dõi từng mục tiêu an toàn chức năng duy nhất của các miền khác mang lại nhằm khắc phục được các rủi ro bởi mục tiêu an toàn và OSPs được thực thi bởi mục tiêu an toàn đó.

ASP_DMO.1.7C - Sở cứ mục tiêu an toàn miền phải chứng minh rằng các mục tiêu an toàn chức năng chống lại các rủi ro không thể chấp nhận duy nhất cho miền.

ASP_DMO.1.8C - Sở cứ mục tiêu an toàn miền phải chứng minh rằng các mục tiêu an toàn chức năng thực thi tất cả các OSP duy nhất cho miền.

ASP_DMO.1.9C - Sở cứ mục tiêu an toàn miền sẽ giải thích tại sao các mục tiêu an toàn đảm bảo duy nhất cho miền được chọn.

C.2.13.2.3 Hoạt động đánh giá

ASP_DMO.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

ASP_DMO.1.2E - Người đánh giá sẽ xác nhận rằng tuyên bố các mục tiêu an toàn miền phù hợp với đặc điểm kỹ thuật tổ chức miền.

C.2.14 Các yêu cầu an toàn miền an toàn (ASP_DMR)

C.2.14.1 Mục tiêu

SPP cung cấp một mô tả rõ ràng và tường minh cơ chế an toàn duy nhất dự kiến của miền an toàn.

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

Họ này gồm hai thành phần. Các thành phần trong họ được phân mức là thành phần công nhận và thành phần phát sinh từ mục tiêu an toàn miền.

C.2.14.3 Yêu cầu an toàn miền công nhận ASP_DMR.1

Phụ thuộc vào: Định nghĩa thành phần mở rộng ASP_ECD.1

C.2.14.3.1 Hành động phát triển/tích hợp

ASP_DMR.1.1D - Nhà phát triển/tích hợp sẽ cung cấp tuyên bố các yêu cầu an toàn miền.

ASP_DMR.1.2D - Nhà phát triển/tích hợp sẽ cung cấp sở cứ các yêu cầu an toàn miền.

C.2.14.3.2 Nội dung và mô tả các bằng chứng

ASP_DMR.1.1C - Tuyên bố các yêu cầu an toàn miền sẽ mô tả các SSFs và SSAS duy nhất áp dụng cho miền.

ASP_DMR.1.2C - Tất cả các lĩnh vực, đối tượng, hoạt động, thuộc tính an toàn, thực thể bên ngoài và các thực thể khác được sử dụng trong SSFs và SSAS duy nhất áp dụng cho miền được xác định.

ASP_DMR.1.3C - Tuyên bố các yêu cầu an toàn miền sẽ xác định tất cả các hoạt động trên các yêu cầu an toàn.

ASP_DMR.1.4C - Mọi hoạt động phải được thực hiện một cách chính xác.

ASP_DMR.1.5C - Mỗi phụ thuộc giữa các yêu cầu an ninh miền sẽ được thỏa mãn, nếu không thỏa mãn thì sở cứ yêu cầu an toàn miền phải biện minh tại sao sự phụ thuộc không được thỏa mãn.

ASP_DMR.1.6C -Tuyên bố các yêu cầu an toàn miền là nhất quán.

C.2.14.3.3 Hành động đánh giá

ASP_DMR.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.2.14.4 Yêu cầu an toàn miền phát sinh ASP_DMR.2

Phân cấp theo: Các yêu cầu an toàn miền mặc định ASP_DMR.1

Phụ thuộc vào: - Các yêu cầu an toàn mặc định ASP_REQ.2

- Định nghĩa thành phần mở rộng ASP_ECD.1

- Mục tiêu an toàn miền an toàn ASP_DMO.1

C.2.14.4.1 Hành động phát triển/tích hợp

ASP_DMR.2.1 D - Nhà phát triển/tích hợp sẽ cung cấp tuyên bố các yêu cầu an toàn miền.

ASP_DMR.2.2D - Nhà phát triển/tích hợp sẽ cung cấp sở cứ yêu cầu an toàn miền.

C.2.14.4.2 Nội dung và mô tả các bằng chứng

ASP.DMR.2.1C - Tuyên bố yêu cầu an toàn miền sẽ mô tả SSFs và SSAS duy nhất áp dụng cho miền.

ASP_DMR.2.2C - Tất cả các lĩnh vực, đối tượng, hoạt động, thuộc tính an toàn, thực thể bên ngoài và các thực thể khác được sử dụng trong SSFs duy nhất và SSAS áp dụng cho miền phải được xác định.

ASP_DMR.2.3C - Tuyên bố yêu cầu an toàn miền sẽ xác định tất cả các hoạt động trên các yêu cầu an toàn.

ASP_DMR.2.4C - Tất cả các hoạt động phải được thực hiện một cách chính xác.

ASP_DMR.2.5C - Mỗi phụ thuộc giữa các yêu cầu an ninh miền sẽ được thỏa mãn, nếu không thỏa mãn thì sở cứ yêu cầu an toàn miền phải biện minh tại sao sự phụ thuộc không được thỏa mãn.

ASP_DMR.2.6C - Sở cứ yêu cầu an toàn miền sẽ theo dõi từng miền SSF trở lại các mục tiêu an toàn chức năng đối với miền.

ASP_DMR.2.7C - Sở cứ yêu cầu an toàn miền phải chứng minh rằng miền SSFs đáp ứng tất cả các mục tiêu an toàn chức năng duy nhất cho miền không được đáp ứng bởi các miền khác hoặc các hệ thống bên ngoài.

ASP_DMR.2.8C - Sở cứ yêu cầu an toàn miền phải chứng minh rằng miền SSFs đáp ứng tất cả các mục tiêu an toàn chức năng cho STOE được xác định trong sở cứ yêu cầu an toàn cho STOE như đáp ứng các miền riêng.

ASP_DMR.2.9C - Sở cứ yêu cầu an toàn miền sẽ theo dõi từng miền SSA trở lại các mục tiêu an toàn đảm bảo cho miền.

ASP_DMR.2.10C - Sở yêu cầu an toàn miền phải chứng minh rằng miền SSAS đáp ứng tất cả các mục tiêu an toàn đảm bảo duy nhất cho miền.

ASP_DMR.2.11C - Sở cứ yêu cầu an toàn miền phải chứng minh rằng miền SSAS đáp ứng tất cả các mục tiêu an toàn đảm bảo cho STOE được xác định trong sở cứ yêu cầu an toàn cho STOE như đáp ứng các miền riêng.

ASP_DMR.2.12C - Tuyên bố yêu cầu an toàn miền là phải nhất quán.

C.2.14.4.3 Hành động đánh giá

ASP_DMR.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.3 Lớp ASS: Đánh giá đích an toàn hệ thống

C.3.1 Giới thiệu

Phần này cung cấp các tiêu chí đảm bảo cho việc đánh giá mục tiêu an toàn hệ thống (SST). Đánh giá mục tiêu an toàn hệ thống (SST) là cần thiết để chứng minh rằng mục tiêu an toàn hệ thống (SST) là phù hợp và nhất quán, và SST được đưa trên một hoặc nhiều SPPs hoặc gói nghĩa là SST được cài đặt chính xác của các SPPs và các gói đó. Các thuộc tính này cần thiết cho SST để sử dụng làm cơ sở phù hợp cho việc đánh giá phần còn lại của STOE.

Các họ trong lớp này bao gồm:

ASS_INT: Giới thiệu SST;

ASS_CCL: Tuyên bố phù hợp;

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

ASS_OBJ: Mục tiêu an toàn;

ASS_ECD: Định nghĩa thành phần mở rộng;

ASS_REQ: Yêu cầu an toàn;

ASS_TSS: Tóm tắt đặc điểm kỹ thuật của STOE;

ASS_DMI: Giới thiệu miền an toàn;

ASS_DMC: Tuyên bố phù hợp miền an toàn;

ASS_DMP: Định nghĩa vấn đề an toàn miền an toàn;

ASS_DMO: Mục tiêu an toàn miền an toàn;

ASS_DMR: Yêu cầu an toàn miền an toàn;

ASS_DMS: Đặc tả tóm tắt miền an toàn.

C.3.2 Phần SST chung

Các thông số kỹ thuật sau đây áp dụng cho SST. Thông số kỹ thuật cho các miền cụ thể sẽ được mô tả bằng cách sử dụng các họ miền (xem mục C.3.10).

C.3.3 Giới thiệu SST (ASS_INT)

C.3.3.1 Mục tiêu

Mục tiêu của họ này là để mô tả STOE một cách chi tiết trên bốn mức trừu tượng gồm: Tham chiếu SST/STOE, Tổng quan STOE, Mô tả chi tiết STOE và tổ chức miền.

Đánh giá việc giới thiệu SST là cần thiết để chứng minh rằng SST và STOE được xác định một cách chính xác, rằng STOE được mô tả một cách chính xác theo bốn mức độ trừu tượng và bốn mô tả đó là nhất quán với nhau. Miền an ninh cụ thể được trình bày ở mục C.3.11: Giới thiệu miền an toàn.

C.3.3.2 Giới thiệu SST (ASS_INT.1)

C.3.3.2.1 Hành động phát triển/tích hợp

ASS_INT.1.1D - Nhà phát triển/tích hợp sẽ cung cấp giới thiệu SST.

C.3.3.2.2 Nội dung và mô tả các bằng chứng

ASS_INT.1.1C Giới thiệu SST phải bao gồm tham chiếu SST, tham chiếu STOE, tổng quan STOE, mô tả chi tiết STOE và đặc điểm kỹ thuật tổ chức miền.

ASS_INT.1.2C - Tham chiếu SST sẽ xác định duy nhất một SST.

ASS_INT.1.3C - Tham chiếu STOE phải xác định được STOE.

ASS_INT.1.4C - Tổng quan STOE phải mô tả việc sử dụng và các tính năng an toàn chính của STOE.

ASS_INT.1.5C - Tổng quan STOE sẽ xác định loại STOE.

ASS_INT.1.6C - Tổng quan STOE phải xác định được mối quan hệ và giao tiếp với bất kỳ hệ thống hoạt động bên ngoài nào theo yêu cầu của STOE.

ASS_INT.1.7C - Mô tả STOE phải mô tả phạm vi vật lý của STOE.

ASS_INT.1.8C- Mô tả STOE phải mô tả phạm vi lô gic của STOE.

ASS_INT.1.9C- Mô tả STOE phải xác định được môi trường phát triển cho STOE, bao gồm các đặc điểm duy nhất bất kỳ của môi trường phát triển miền riêng.

ASS_INT.1.10C - Các đặc điểm kỹ thuật tổ chức miền phải mô tả việc tổ chức các miền an toàn được thiết lập và nhận dạng phạm vi vật lý của mỗi miền an toàn.

ASS_INT.1.11C - Đối với từng miền, các đặc điểm kỹ thuật tổ chức miền sẽ xác định bất kỳ dịch vụ an toàn nào được cung cấp bởi miền đó là có sẵn cho các miền khác và các thuộc tính an toàn bất kỳ của miền được thực thi bên các miền khác.

C.3.3.2.3 Hành động đánh giá

ASS_INT.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

ASS_INT.1.2E - Người đánh giá sẽ xác nhận rằng các tham chiếu STOE, tổng quan STOE, mô tả STOE và đặc điểm kỹ thuật tổ chức miền phù hợp với nhau.

C.3.4 Tuyên bố phù hợp (ASS_CCL)

C.3.4.1 Mục tiêu

Mục tiêu của họ này là để xác định tính hợp lệ của các tuyên bố phù hợp khác nhau: Tuyên bố phù hợp tiêu chuẩn TCVN 8709, tuyên bố SPP, tuyên bố PPs, tuyên bố STs và tuyên bố gói yêu cầu.

Tuyên bố phù hợp tiêu chuẩn TCVN 8709 mô tả phiên bản của tiêu chuẩn TCVN 8709 mà SPP và STOE tuyên bố sự phù hợp, tuyên bố PPs, STs và/hoặc gói (nếu có) mô tả cách SST tuyên bố sự phù hợp với PP, ST và/hoặc gói đã quy định, trong khi tuyên bố SPP xác định SPPs (nếu có) mà SST tuyên bố sự phù hợp.

C.3.4.2 Các lưu ý áp dụng

Nếu một SST tuyên bố phù hợp với một PP hoặc ST, nó phải thể hiện là một phần nhất quán của các yêu cầu an toàn mà nó xác định OSF sẽ đáp ứng các giả định về môi trường hoạt động trong phần định nghĩa vấn đề an toàn của PP/ST.

C.3.4.3 Tuyên bố phù hợp ASS_CCL.1

Phụ thuộc vào: ASS_INT.1 - giới thiệu SST

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

ASS_OBJ.1 - Mục tiêu an toàn

ASS_ECD.1 - Định nghĩa thành phần mở rộng

ASS_REQ.1 - Yêu cầu an toàn quy định

C.3.4.3.1 Hành động phát triển/tích hợp

ASS_CCL.1.1D - Nhà phát triển/tích hợp sẽ cung cấp một tuyên bố sự phù hợp.

ASS_CCL.1.2D - Nhà phát triển/tích hợp sẽ cung cấp một sở cứ tuyên bố sự phù hợp.

C.3.4.3.2 Nội dung và mô tả các bằng chứng

ASS_CCL.1.1C - Tuyên bố phù hợp phải nói rõ tuyên bố phù hợp tiêu chuẩn để xác định phiên bản của tiêu chuẩn ISO/IEC TR 19791 mà SST và STOE tuyên bố sự phù hợp.

ASS_CCL.1.2C - Tuyên bố phù hợp tiêu chuẩn phải mô tả phù hợp chức năng của SST theo tiêu chuẩn ISO/IEC TR 19791 là chức năng tuân thủ tiêu chuẩn ISO/IEC TR 19791 hay là chức năng mở rộng tiêu chuẩn ISO/IEC TR 19791.

ASS_CCL.1.3C - Tuyên bố phù hợp tiêu chuẩn phải mô tả sự phù hợp đảm bảo của SST theo tiêu chuẩn ISO/IEC TR 19791 là đảm bảo tuân thủ tiêu chuẩn ISO/IEC TR 19791 hay là đảm bảo mở rộng tiêu chuẩn ISO/IEC TR 19791.

ASS_CCL.1.4C - Tuyên bố phù hợp tiêu chuẩn phải phù hợp với định nghĩa thành phần mở rộng.

ASS_CCL.1.5C - Tuyên bố phù hợp phải xác định tất cả SPPs, PPs, STs và các gói yêu cầu an toàn mà SST tuyên bố sự phù hợp.

ASS_CCL.1.6C - Tuyên bố phù hợp phải mô tả sự phù hợp bất kỳ của SST với một gói là gói tuân thủ hoặc gói tăng cường.

ASS_CCL.1.7C - Sở cứ tuyên bố phù hợp phải chứng minh rằng loại STOE là nhất quán với loại STOE trong SPPs, PPs và STs phù hợp với tuyên bố.

ASS_CCL.1.8C - Sở cứ tuyên bố phù hợp phải chứng minh rằng tuyên bố định nghĩa vấn đề an toàn là nhất quán với tuyên bố định nghĩa vấn đề an toàn trong SPPs, PPs và STs đã tuyên bố.

ASS_CCL.1.9C - Sở cứ tuyên bố phù hợp phải chứng minh rằng tuyên bố các mục tiêu là nhất quán với tuyên bố các mục tiêu trong SPPs, PPs và STs đã tuyên bố.

ASS_CCL.1.10C - Sở cứ tuyên bố phù hợp phải chứng minh rằng tuyên bố các yêu cầu an toàn là nhất quán với tuyên bố các yêu cầu an toàn trong SPPs, PPs, STs và các gói đã tuyên bố.

C.3.4.3.3 Hành động đánh giá

ASS_CCL.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.3.5 Định nghĩa vấn đề an toàn (ASS_SPD)

C.3.5.1 Mục tiêu

SST xác định các vấn đề an toàn và áp dụng cho STOE. Các vấn đề an toàn cho một miền an toàn cụ thể được quy định tại mục C.3.13: Định nghĩa vấn đề an toàn miền an toàn. Đánh giá định nghĩa vấn đề an toàn là cần thiết để chứng minh rằng các vấn đề an toàn có ý định được giải quyết bằng các STOE.

Đánh giá định nghĩa vấn đề an toàn là cần thiết để chứng minh rằng các vấn đề an toàn dự định sẽ được giải quyết bởi STOE.

C.3.5.2 Định nghĩa vấn đề an toàn ASS_SPD.1

C.3.5.2.1 Hành động phát triển/tích hợp

ASS_SPD.1.1D Nhà phát triển/tích hợp sẽ cung cấp một định nghĩa vấn đề an toàn.

C.3.5.2.2 Nội dung và mô tả các bằng chứng

ASS_SPD.1.1C - Định nghĩa vấn đề an toàn sẽ mô tả tất cả các rủi ro có thể đối với STOE. Rủi ro được phân loại là rủi ro có thể chấp nhận hoặc không chấp nhận được.

ASS_SPD.1.2C - Tất cả các rủi ro không thể chấp nhận được mô tả về các mối đe dọa và các điểm yếu. Mỗi mối đe dọa được hiểu là tác nhân đe dọa, tài sản và hành động có hại.

ASS_SPO.1.3C - Định nghĩa vấn đề an toàn sẽ mô tả OSP.

C.3.5.2.3 Hành động đánh giá

ASS_SPD.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.3.6 Mục tiêu an toàn (ASS_OBJ)

C.3.6.1 Mục tiêu

Các mục tiêu an ninh là một tuyên bố súc tích các phản ứng có dự định về vấn đề an toàn được xác định thông qua họ ASS_SPD. Các mục tiêu an toàn quy định tại phần này được áp dụng cho STOE. Mục tiêu an toàn cho một miền an toàn cụ thể được quy định tại mục C.3.14; Mục tiêu an toàn miền an toàn. Đánh giá mục tiêu an toàn là cần thiết để chứng minh rằng các mục tiêu an toàn chức năng là đầy đủ và quyết định hoàn toàn định nghĩa vấn đề an toàn, sự phân chia vấn đề giữa STOE và hệ thống hoạt động bên ngoài được xác định rõ ràng và các mục tiêu an toàn đảm bảo được chứng minh bằng tài liệu và giải thích.

C.3.6.2 Các lưu ý áp dụng

Sở cứ mục tiêu an toàn phải giải thích tại sao các mục tiêu an toàn đảm bảo đã được chọn. Điều này có thể là kết quả của việc phân tích rủi ro, nhưng cũng có thể phụ thuộc vào thực tiễn, và khả năng đạt được và thậm chí có thể tùy chọn. Các sở cứ nên được trình bày rõ ràng, nhưng không cần phải chứng minh.

C.3.6.3 Mục tiêu an toàn ASS_OBJ.1

Phụ thuộc vào: Định nghĩa vấn đề an toàn ASS_SPD.1

C.3.6.3.1 Hành động phát triển/tích hợp

ASS_OBJ.1.1D - Nhà phát triển/tích hợp sẽ cung cấp tuyên bố các mục tiêu an toàn.

ASS_OBJ.1.2D - Nhà phát triển/tích hợp sẽ cung cấp sở cứ mục tiêu an toàn.

5.3.6.3.2 Nội dung và mô tả các bằng chứng

ASS_OBJ.1.1C - Tuyên bố mục tiêu an toàn phải mô tả các mục tiêu an toàn chức năng cho STOE.

ASS_OBJ.1.2C - Tuyên bố mục tiêu an toàn phải mô tả các mục tiêu an toàn chức năng bất kỳ đáp ứng bởi hệ thống hoạt động bên ngoài.

ASS_OBJ.1.3C - Tuyên bố mục tiêu an toàn phải mô tả các mục tiêu an toàn đảm bảo cho STOE.

ASS_OSJ.1.4C - Sở cứ mục tiêu an toàn sẽ theo dõi từng mục tiêu an toàn chức năng cho STOE để chống đỡ các rủi ro bởi mục tiêu an toàn và OSP được thực thi bởi mục tiêu an toàn đó.

ASS_OBJ.1.5C - Sở cứ mục tiêu an toàn sẽ theo dõi từng mục tiêu an toàn chức năng đối với các hệ thống vận hành bên ngoài mang lại rủi ro chống đỡ bởi mục tiêu an toàn và OSP được thực thi bởi mục tiêu an toàn đó.

ASS_OBJ.1.6C - Sở cứ mục tiêu an toàn phải chứng minh rằng các mục tiêu an toàn chức năng chống lại tất cả những rủi ro không thể chấp nhận.

ASS_OBJ.1.7C - Sở cứ mục tiêu an toàn phải chứng minh rằng các mục tiêu an toàn chức năng thực thi tất cả OSPs.

ASS_OBJ.1.8C - Sở cứ mục tiêu an toàn phải giải thích tại sao các mục tiêu an toàn đảm bảo cho STOE được chọn.

C.3.6.3.3 Hành động đánh giá

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

C.3.7 Định nghĩa thành phần mở rộng (ASS_ECD)

C.3.7.1 Mục tiêu

Yêu cầu an toàn mở rộng là yêu cầu không dựa trên các thành phần từ tiêu chuẩn TCVN 8709 hoặc tiêu chuẩn này, mà dựa trên các thành phần mở rộng được xác định bởi tác giả SST.

Đánh giá định nghĩa thành phần mở rộng là cần thiết để xác định rằng chúng là rõ ràng, tường minh và cần thiết, nghĩa là thành phần mở rộng không được mô tả rõ ràng trong tiêu chuẩn TCVN 8709 hiện tại hoặc tiêu chuẩn này.

C.3.7.2 Định nghĩa thành phần mở rộng ASS_ECD.1

C.3.7.2.1 Hành động phát triển/tích hợp

ASS_ECD.1.1D - Nhà phát triển/tích hợp sẽ cung cấp tuyên bố các yêu cầu an toàn.

ASS_ECD.1.2D - Nhà phát triển/tích hợp sẽ cung cấp định nghĩa thành phần mở rộng.

C.3.7.2.2 Nội dung và mô tả các bằng chứng

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

ASS_ECD.1.2C - Định nghĩa thành phần mở rộng sẽ quy định thành phần mở rộng cho từng yêu cầu an toàn mở rộng.

ASS_ECD.1.3C - Định nghĩa thành phần mở rộng sẽ mô tả mối quan hệ của từng thành phần mở rộng với các thành phần hiện có, họ và lớp trong tiêu chuẩn TCVN 8709 hoặc tiêu chuẩn này.

ASS_ECD.1.4C - Định nghĩa thành phần mở rộng sẽ sử dụng các thành phần hiện có, họ, lớp và phương pháp trong tiêu chuẩn TCVN 8709 hoặc tiêu chuẩn này làm mô hình để trình bày.

ASS_ECD.1.5C - Các thành phần mở rộng sẽ bao gồm các phần tử đo lường được và khách quan và có thể chứng minh được các phần tử là tuân thủ hoặc không tuân thủ.

C.3.7.2.3 Hành động đánh giá

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

ASS_ECD.1.2E - Người đánh giá sẽ xác nhận rằng không có phần mở rộng có thể được thể hiện rõ ràng bằng cách sử dụng các thành phần hiện có.

C.3.8 Các yêu cầu an toàn (ASS_REQ)

C.3.8.1 Mục tiêu

SSFs tạo thành một mô tả rõ ràng và tường minh về cơ chế an toàn dự kiến của STOE. SSAS tạo thành một mô tả rõ ràng và tường minh các hoạt động dự kiến sẽ được thực hiện để đạt được sự đảm bảo trong STOE. Các yêu cầu an toàn trong mục này được áp dụng cho STOE. Yêu cầu toàn cho một miền an toàn cụ thể được quy định tại mục C.3.15: Các yêu cầu an toàn miền an toàn. Việc đánh giá các yêu cầu an toàn là cần thiết để đảm bảo rằng các yêu cầu an toàn là rõ ràng và tường minh.

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

Họ này có hai thành phần, các thành phần trong họ này được phân mức là thành phần công nhận hoặc là thành phần phát sinh từ mục tiêu an toàn đối với STOE.

C.3.8.3 Yêu cầu an toàn thành phần công nhận ASS_REQ.

Phụ thuộc vào định nghĩa thành phần mở rộng ASS_ECD.1

C.3.8.3.1 Hành động phát triển/tích hợp

ASS_REQ.1.1D - Nhà phát triển/tích hợp sẽ cung cấp tuyên bố các yêu cầu an toàn.

ASS_REQ.1.2D Nhà phát triển/tích hợp sẽ cung cấp sở cứ yêu cầu an toàn

C.3.8.3.2 Nội dung và mô tả các bằng chứng

ASS_REQ.1.1C - Tuyên bố yêu cầu an toàn phải mô tả SSFs và SSAS.

ASS_REQ.1.2C - Tất cả các lĩnh vực, đối tượng, hoạt động, thuộc tính an toàn, thực thể bên ngoài và các thực thể khác được sử dụng trong SSFs và SSAS phải được xác định.

ASS_REQ.1.3C - Tuyên bố yêu cầu an toàn sẽ xác định tất cả các hoạt động trên các yêu cầu an toàn.

ASS_REQ.1.4C - Tất cả các hoạt động phải được thực hiện một cách chính xác.

ASS_REQ.1.5C - Mỗi sự phụ thuộc giữa các yêu cầu an toàn hoặc được thỏa mãn, hoặc không được thỏa mãn và sở cứ các yêu cầu an toàn phải biện minh cho sự phụ thuộc đó không được thỏa mãn.

ASS_REQ.1.6C - Tuyên bố yêu cầu an toàn phải là nhất quán.

C.3.8.3.3 Hoạt động đánh giá

ASS_REQ.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.3.8.4 Yêu cầu an toàn phát sinh ASS_REQ.2

Phân cấp theo các yêu cầu an toàn công nhận ASS_REQ.1

Phụ thuộc vào: - Mục tiêu an toàn ASS_OBJ.1

- Định nghĩa thành phần mở rộng ASS_ECD.1

C.3.8.4.1 Hành động phát triển/tích hợp

ASS_REQ.2.1D - Nhà phát triển/tích hợp sẽ cung cấp tuyên bố các yêu cầu an toàn.

ASS_REQ.2.2D - Nhà phát triển/tích hợp sẽ cung cấp sở cứ các yêu cầu an toàn.

C.3.8.4.2 Nội dung và mô tả các bằng chứng

ASS_REQ.2.1C - Tuyên bố các yêu cầu an toàn phải mô tả SSFs và SSAS.

ASS_REQ.2.2C - Tất cả các lĩnh vực, các đối tượng, hoạt động, thuộc tính an toàn, thực thể bên ngoài và các thực thể khác được sử dụng trong SSFs và SSAS phải được xác định.

ASS_REQ.2.3C - Tuyên bố các yêu cầu an toàn phải xác định tất cả các hoạt động trên các yêu cầu an toàn.

ASS_REQ.2.4C - Tất cả các hoạt động phải được thực hiện một cách chính xác.

ASS_REQ.2.5C - Mỗi sự phụ thuộc giữa các yêu cầu an toàn hoặc được thỏa mãn, hoặc không được thỏa mãn và sở cứ các yêu cầu an toàn phải biện minh cho sự phụ thuộc đó không được thỏa mãn.

ASS_REQ.2.6C - Sở cứ yêu cầu an toàn sẽ theo dõi từng SSF trở lại các mục tiêu an toàn chức năng cho STOE.

ASS_REQ.2.7C - Sở cứ yêu cầu an toàn phải chứng minh rằng SSFs đáp ứng tất cả các mục tiêu an toàn chức năng cho STOE không được đáp ứng bởi hệ thống bên ngoài hoặc các miền riêng.

ASS_REQ.2.8C - Sở cứ yêu cầu an toàn sẽ theo dõi từng SSA trở lại các mục tiêu an toàn đảm bảo cho STOE.

ASS_REQ.2.9C - Sở cứ yêu cầu an toàn phải chứng minh rằng SSAs đáp ứng tất cả các mục tiêu an toàn đảm bảo cho STOE không được đáp ứng bởi các miền riêng.

ASS_REQ.2.10C - Tuyên bố các yêu cầu an toàn phải nhất quán.

C.3.8.4.3 Hành động đánh giá

ASS_REQ.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.3.9 Đặc điểm kỹ thuật tổng thể STOE (ASS_TSS)

C.3.9.1 Mục tiêu

Mục tiêu của các đặc điểm kỹ thuật tổng thể STOE là cung cấp cho người tiêu dùng tiềm năng của STOE một mô tả mức cao các dự định của nhà phát triển/tích hợp nhằm đáp ứng SSFs và SSAS của nó. Các đặc điểm kỹ thuật tổng thể STOE nên cho phép người đánh giá và người tiêu dùng tiềm năng nắm được cách STOE đáp ứng SSFs và SSAs của nó, đặc điểm kỹ thuật tổng thể STOE quy định trong mục này được áp dụng cho STOE. Các đặc điểm kỹ thuật tổng thể an toàn cho một miền an toàn cụ thể được quy định tại mục C.3.16: Đặc điểm kỹ thuật tổng thể miền an toàn STOE

Việc đánh giá các đặc điểm kỹ thuật tổng thể STOE là cần thiết để xác định xem tất cả SSFs đã được giải quyết thỏa đáng cho dù các đặc điểm kỹ thuật tổng thể STOE phù hợp với các mô tả chi tiết khác của STOE.

C.3.9.2 Đặc điểm kỹ thuật tổng thể STOE (ASS_TSS.1)

Phụ thuộc vào: - Giới thiệu SST (ASS_INT.1)

- Yêu cầu an toàn công nhận ASS_REQ.1

C.3.9.2.1 Hành động phát triển/tích hợp

ASS_TSS.1.1D - Nhà phát triển/tích hợp sẽ cung cấp các đặc điểm kỹ thuật tổng thể STOE.

C.3.9.2.2 Nội dung và mô tả các bằng chứng

ASS_TSS.1.1C - Các đặc điểm kỹ thuật tổng thể STOE phải mô tả cách thức STOE đáp ứng từng SSF.

ASS_TSS.1.2C - đặc điểm kỹ thuật tổng thể STOE phải mô tả cách thức STOE đáp ứng từng SSA.

C.3.9.2.3 Hành động đánh giá

ASS_TSS.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

ASS_TSS.1.2E - Người đánh giá sẽ xác nhận rằng các đặc điểm kỹ thuật tổng thể STOE là nhất quán với tổng quan STOE và mô tả STOE.

C.3.10 Miền an toàn STOE

Mỗi miền an toàn STOE xác định các vấn đề an toàn, mục tiêu an toàn và các yêu cầu an toàn là duy nhất cho miền an toàn cụ thể đó.

Các phần sau đây xác định các họ được sử dụng để xác định các miền an toàn trong STOE.

C.3.11 Giới thiệu miền an toàn (ASS_DMI)

C.3.11.1 Mục tiêu

Mục tiêu của họ này là mô tả chi tiết một miền an toàn theo ba cấp độ trừu tượng, gồm: tham chiếu miền an toàn, tổng quan miền an toàn và mô tả miền an toàn.

C.3.11.2 Giới thiệu miền an toàn ASS_DMI.1

Phụ thuộc vào giới thiệu SST (ASS_INT.1)

C.3.11.2.1 Hành động phát triển/tích hợp

ASS_DMI.1.1D - Nhà phát triển/tích hợp sẽ cung cấp giới thiệu miền an toàn.

C.3.11.2.2 Nội dung và mô tả các bằng chứng

ASS_DMI.1.1C - Việc giới thiệu miền an toàn phải bao gồm tham chiếu miền an toàn, tổng quan miền an toàn và mô tả miền an toàn.

ASS_DMI.1.2C - Tham chiếu miền an toàn sẽ nhận diện duy nhất một miền an toàn.

ASS_DMI.1.3C - Tổng quan miền an toàn sẽ tóm tắt cách sử dụng và các tính năng an toàn chính của miền an toàn.

ASS_DMI.1.4C - Mô tả miền an toàn sẽ xác định các phân hệ và/hoặc các thành phần.

ASS_DMI.1.5C - Mô tả miền an toàn sẽ xác định các mối quan hệ và giao tiếp với các miền khác.

C.3.11.2.3 Hành động đánh giá

ASS_DMI.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

ASS_DMI.1.2E - Người đánh giá sẽ xác nhận rằng tham chiếu miền an toàn, tổng quan miền an toàn và mô tả miền an toàn là phù hợp với nhau và với giới thiệu SST.

C.3.12 Tuyên bố phù hợp miền an toàn (ASS_DMC)

C.3.12.1 Mục tiêu

SST xác định tuyên bố phù hợp cụ thể cho miền an toàn.

C.3.12.2 Tuyên bố phù hợp miền an toàn ASS_DMC.1

Phụ thuộc vào: - Định nghĩa vấn đề an toàn miền an toàn ASS_DMP.1;

- Mục tiêu an toàn miền an toàn ASS_DMO.1;

- Yêu cầu an toàn miền công nhận ASS_DMR.1

C.3.12.2.1 Hành động phát triển/tích hợp

ASS_DMC.1.1D - Nhà phát triển/tích hợp sẽ cung cấp tuyên bố phù hợp miền.

ASS_DMC.1.2D - Nhà phát triển/tích hợp sẽ cung cấp sở cứ tuyên bố phù hợp miền.

C.3.12.2.2 Nội dung và mô tả các bằng chứng

ASS_DMC.1.1C - Tuyên bố phù hợp miền sẽ xác định tất cả SPPs, PPs, STs và các gói yêu cầu an toàn mà miền tuyên bố sự phù hợp.

ASS_DMC.1.2C - Tuyên bố phù hợp miền sẽ mô tả sự phù hợp bất kỳ của miền cho một gói là gói tuân thủ hoặc gói tăng cường.

ASS_DMC.1.3C - Sở cứ tuyên bố phù hợp miền phải chứng minh rằng các loại STOE phù hợp nhất quán với các loại STOE trong SPPs, PPs và STs phù hợp với tuyên bố.

ASS_DMC.1.4C - Sở cứ tuyên bố phù hợp miền phải chứng minh rằng tuyên bố định nghĩa vấn đề an toàn miền phù hợp nhất quán với tuyên bố định nghĩa vấn đề an toàn trong SPPs, PPs và STs phù hợp với tuyên bố.

ASS_DMC.1.5C - Sở cứ tuyên bố phù hợp miền phải chứng minh rằng tuyên bố các mục tiêu an toàn miền phù hợp nhất quán với tuyên bố các mục tiêu trong SPPs, PPs và STs phù hợp với tuyên bố.

ASS_DMC.1.6C - Sở cứ tuyên bố phù hợp miền phải chứng minh rằng tuyên bố các yêu cầu an toàn miền phù hợp nhất quán với tuyên bố yêu cầu an toàn trong SPPs, PPs, STs và các gói phù hợp với tuyên bố.

C.3.12.2.3 Hành động đánh giá

ASS_DMC.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.3.13 Định nghĩa vấn đề an toàn miền an toàn (ASS_DMP)

C.3.13.1 Mục tiêu

SST xác định các vấn đề an toàn cụ thể giải quyết bởi một miền an toàn.

C.3.13.2 Định nghĩa vấn đề an toàn miền an toàn ASS_DMP.1

C.3.13.2.1 Hành động phát triển/tích hợp

ASS_DMP.1.1D - Nhà phát triển/tích hợp sẽ cung cấp định nghĩa vấn đề an toàn miền.

C.3.13.2.2 Nội dung và mô tả các bằng chứng

ASS_DMP.1.1C - Định nghĩa vấn đề an toàn miền sẽ mô tả tất cả các rủi ro đặc biệt có thể áp dụng cho miền. Mỗi rủi ro được phân loại là rủi ro chấp nhận được hoặc không chấp nhận được.

ASS_DMP.1.2C - Tất cả các rủi ro không thể chấp nhận được mô tả là các mối đe dọa và các điểm yếu. Mỗi mối đe dọa được mô tả dưới thuật ngữ là tác nhân đe dọa, tài sản và hành động có hại.

ASS_DMP.1.3C - Định nghĩa vấn đề an toàn miền sẽ mô tả OSPs duy nhất có thể áp dụng cho miền.

C.3.13.2.3 Hành động đánh giá

ASS_DMP.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.3.14 Mục tiêu an toàn miền an toàn (ASS_DMO)

C.3.14.1 Mục tiêu

SST quy định cụ thể một tuyên bố xúc tích các đáp ứng dự kiến cho các vấn đề an toàn miền duy nhất được xác định thông qua họ ASS_DMP.

C.3.14.2 Mục tiêu an toàn miền an toàn ASS_DMO.1

Phụ thuộc vào: - Giới thiệu SST (ASS_INT.1);

- Định nghĩa vấn đề an toàn miền an toàn ASS_DMP.1

C.3.14.2.1 Hành động phát triển/tích hợp

ASS_DMO.1.1D - Nhà phát triển/tích hợp sẽ cung cấp tuyên bố mục tiêu an toàn miền.

ASS_DMO.1.2D - Nhà phát triển/tích hợp sẽ cung cấp sở cứ mục tiêu an toàn miền.

C.3.14.2.2 Nội dung và mô tả các bằng chứng

ASS_DMO.1.1C - Tuyên bố mục tiêu an toàn miền phải mô tả các mục tiêu an toàn chức năng duy nhất cho miền.

ASS_DMO.1.2C - Tuyên bố mục tiêu an toàn miền phải mô tả các mục tiêu an toàn chức năng bất kỳ cho miền đó được đáp ứng bởi các miền khác hoặc các hệ thống hoạt động bên ngoài.

ASS_DMO.1.3C - Tuyên bố mục tiêu an toàn miền phải mô tả các mục tiêu an toàn đảm bảo duy nhất cho miền.

ASS_DMO.1.4C - Tuyên bố mục tiêu an toàn miền phải mô tả các mục tiêu an toàn chức năng bất kỳ cho miền đó được thực thi hoặc có sẵn cho các miền khác

ASS_DMO.1.5C - Sở cứ mục tiêu an toàn miền sẽ theo dõi từng mục tiêu an toàn chức năng duy nhất cho miền trở lại chống đỡ các rủi ro bởi các mục tiêu an toàn đó và OSPs được thực thi bởi các mục tiêu an toàn đó.

ASS_DMO.1.6C - Sở cứ mục tiêu an toàn miền sẽ theo dõi từng mục tiêu an toàn chức năng duy nhất cho các miền khác trở lại chống đỡ các rủi ro bởi các mục tiêu an toàn đó và OSPs được thực thi bởi mục tiêu an toàn đó.

ASS_DMO.1.7C - Sở cứ mục tiêu an toàn miền phải chứng minh rằng các mục tiêu an toàn chức năng chống đỡ tất cả các rủi ro không chấp nhận được cho miền.

ASS_DMO.1.8C - Sở cứ mục tiêu an toàn miền phải chứng minh rằng các mục tiêu an toàn chức năng thực thi tất cả OSPs duy nhất cho miền

ASS_DMO.1.9C - Sở cứ mục tiêu an toàn miền phải giải thích tại sao các mục tiêu an toàn đảm bảo duy nhất cho miền được chọn.

C.3.14.2.3 Hành động đánh giá

ASS_DMO.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

ASS_DMO.1.2E - Người đánh giá sẽ xác nhận rằng tuyên bố mục tiêu an toàn miền là phù hợp nhất quán với đặc điểm kỹ thuật tổ chức miền.

C.3.15 Yêu cầu an toàn miền an toàn (ASS_DMR)

C.3.15.1 Mục tiêu

SST cung cấp một mô tả rõ ràng và tường minh các cơ chế an toàn duy nhất dự kiến của một miền an toàn.

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

Họ này gồm hai thành phần, các thành phần trong họ được phân mức là thành phần công nhận hoặc là thành phần phát sinh từ các mục tiêu an toàn của miền.

C.3.15.3 Yêu cầu an toàn miền công nhận (ASS_DMR.1)

Phụ thuộc vào định nghĩa thành phần mở rộng ASS_ECD.1

C.3.15.3.1 Hành động phát triển/tích hợp

ASS_DMR.1.1D - Nhà phát triển/tích hợp sẽ cung cấp tuyên bố các yêu cầu an toàn miền.

ASS_DMR.1.2D - Nhà phát triển/tích hợp sẽ cung cấp sở cứ yêu cầu an toàn miền.

C.3.15.3.2 Nội dung và mô tả các bằng chứng

ASS_DMR.1.1C - Tuyên bố các yêu cầu an toàn miền phải mô tả SSFs và SSAS duy nhất có thể áp dụng cho miền.

ASS_DMR.1.2C - Tất cả các lĩnh vực, các đối tượng, hoạt động, thuộc tính an toàn, thực thể bên ngoài và các thực thể khác được sử dụng trong SSFs duy nhất và SSAS có thể áp dụng cho miền phải được xác định.

ASS_DMR.1.3C -Tuyên bố các yêu cầu an toàn miền phải xác định tất cả các hoạt động trên các yêu cầu an toàn.

ASS_DMR.1.4C - Tất cả các hoạt động phải được thực hiện một cách chính xác.

ASS_DMR.1.5C - Mỗi sự phụ thuộc giữa các yêu cầu an toàn miền hoặc được thỏa mãn, hoặc không được thỏa mãn thì sở cứ các yêu cầu an toàn miền phải biện minh cho sự phụ thuộc đó không được thỏa mãn.

ASS_DMR.1.6C - Tuyên bố yêu cầu an toàn miền phải nhất quán.

C.3.15.3.3 Hành động đánh giá

ASS_DMR.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.3.15.4 Yêu cầu an toàn miền phát sinh ASS_DMR.2

Phân cấp theo các yêu cầu an toàn miền phát sinh ASS_DMR.1

Phụ thuộc vào: - Các yêu cầu an toàn phát sinh ASS_REQ.2

- Định nghĩa thành phần mở rộng ASS_ECD.1

- Mục tiêu an toàn miền an toàn ASS_DMO.1

C.3.15.4.1 Hành động phát triển/tích hợp

ASS_DMR.2.1D - Nhà phát triển/tích hợp sẽ cung cấp tuyên bố các yêu cầu an toàn miền.

ASS_DMR.2.2D - Nhà phát triển/tích hợp sẽ cung cấp sở cứ yêu cầu an toàn miền.

C.3.15.4.2 Nội dung và mô tả các bằng chứng

ASS_DMR.2.1C - Tuyên bố các yêu cầu an toàn miền phải mô tả SSFs và SSAS duy nhất có thể áp dụng cho miền.

ASS_DMR.2.2C - Tất cả các lĩnh vực, các đối tượng, hoạt động, thuộc tính an toàn, thực thể bên ngoài và các thực thể khác được sử dụng trong SSFs duy nhất và SSAS có thể áp dụng cho miền phải được xác định.

ASS_DMR.2.3C - Tuyên bố các yêu cầu an toàn miền phải xác định tất cả các hoạt động trên các yêu cầu an toàn.

ASS_DMR.2.4C - Tất cả các hoạt động phải được thực hiện một cách chính xác.

ASS_DMR.2.5C - Mỗi sự phụ thuộc giữa các yêu cầu an toàn miền hoặc được thỏa mãn, hoặc không được thỏa mãn thì sở cứ các yêu cầu an toàn miền phải biện minh cho sự phụ thuộc đó không được thỏa mãn.

ASS_DMR.2.6C - Sở cứ yêu cầu an toàn miền sẽ theo dõi từng miền SSF trở tại các mục tiêu an toàn chức năng cho miền.

ASS_DMR.2.7C - Sở cứ yêu cầu an toàn miền phải chứng minh rằng miền SSFs đáp ứng tất cả các mục tiêu an toàn chức năng duy nhất cho miền không được đáp ứng bởi miền khác hoặc các hệ thống bên ngoài

ASS_DMR.2.8C - Sở cứ yêu cầu an toàn miền phải chứng minh rằng miền SSFs đáp ứng tất cả các mục tiêu an toàn chức năng cho STOE được xác định trong sở cứ yêu cầu an toàn của STOE như đáp các miền riêng

ASS_DMR.2.9C -Sở cứ yêu cầu an toàn miền sẽ theo dõi từng miền SSA trở lại các mục tiêu an toàn đảm bảo cho miền.

ASS_DMR.2.10C - Sở cứ yêu cầu an toàn miền phải chứng minh rằng miền SSAs đáp ứng tất cả các mục tiêu an toàn đảm bảo duy nhất cho miền.

ASS_DMR.2.11C - Sở cứ yêu cầu an toàn miền phải chứng minh rằng miền SSAs đáp ứng tất cả các mục tiêu an toàn đảm bảo cho STOE được xác định trong sở cứ yêu cầu an toàn của STOE như đáp ứng các miền riêng.

ASS_DMR.2.12C - Tuyên bố yêu cầu an toàn miền phải nhất quán.

C.3.15.4.3 Hành động đánh giá

ASS_DMR.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.3.16 Đặc điểm kỹ thuật tổng thể miền an toàn (ASS_DMS)

C.3.16.1 Mục tiêu

SST quy định các đặc điểm kỹ thuật tổng thể miền an toàn.

C.3.16.2 Đặc điểm kỹ thuật tổng thể miền an toàn ASS_DMS.1

Phụ thuộc vào: - Giới thiệu miền an toàn ASS_DMI.1;

- Yêu cầu an toàn miền công nhận ASS_DMR.1

C.3.16.2.1 Hành động phát triển/tích hợp

ASS_DMS.1.1D - Nhà phát triển/tích hợp sẽ cung cấp đặc điểm kỹ thuật tổng thể miền.

C.3.16.2.2 Nội dung và mô tả các bằng chứng

ASS_DMS.1.1C - Đặc điểm kỹ thuật tổng thể miền phải mô tả cách thức STOE đáp ứng từng miền SSF.

ASS_DMS.1.2C - Đặc điểm kỹ thuật tổng thể miền phải mô tả cách thức STOE đáp ứng từng miền SSA.

C.3.16.2.3 Hành động đánh giá

ASS_DMS.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

ASS_DMS.1.2E - Người đánh giá sẽ xác nhận rằng đặc điểm kỹ thuật tổng thể miền phù hợp nhất quán với tổng quan miền và mô tả miền.

C.4 Lớp AOD: Tài liệu hướng dẫn hệ thống vận hành

C.4.1 Giới thiệu

Mục đích của lớp tài liệu hướng dẫn hệ thống vận hành là để đánh giá sự phù hợp của tài liệu mô tả sự tích hợp và sử dụng hoạt động của hệ thống hoạt động. Tài liệu này tập trung mô tả các đối tượng gồm các nhà tích hợp hệ thống vận hành, quản trị viên và người sử dụng không quản trị viên có hành động không đúng có thể ảnh hưởng xấu đến cơ chế an toàn và đặc điểm của hệ thống vận hành, cũng như người dùng bình thường có hành động không đúng có thể ảnh hưởng xấu đến khả năng của hệ thống vận hành để cung cấp khả năng bảo vệ cần thiết cho dữ liệu hệ thống. Do đó, hoạt động AOD có liên quan chặt chẽ đến các quy trình và thủ tục được quy định bởi các yêu cầu an toàn vận hành. Hướng dẫn người sử dụng bao gồm các thông tin liên quan đến các khía cạnh công nghệ của hệ thống vận hành cũng như quy trình hoạt động và nhân lực của hệ thống vận hành.

C.4.2 Các lưu ý áp dụng

Các yêu cầu OSP được định nghĩa trong SST khi áp dụng cho cơ chế yêu cầu nhân viên phải được mô tả trong tài liệu hướng hệ thống vận hành phù hợp.

Chế độ bảo trì, chế độ người dùng duy nhất và bất kỳ chế độ hoạt động đặc biệt nào gây ra lỗi hoặc ngoại lệ cần được xác định và cân nhắc kỹ hậu quả và tác động của chúng đến việc duy trì hoạt động an toàn.

Tài liệu hướng dẫn quản trị phải xác định các thông tin sau:

- Các chức năng và đặc quyền phải được kiểm soát;

- Các loại kiểm soát cần thiết;

- Các lý do của việc kiểm soát đó.

Lưu ý: Cần bao quát các ảnh hưởng dự kiến, tác dụng phụ và tương tác tốt với các chức năng về các đặc quyền khác.

Tài liệu hướng dẫn cần mô tả tổng thể việc quản trị hệ thống vận hành bao gồm các sản phẩm cá nhân và các phân hệ. Tài liệu hướng dẫn quản trị không chỉ dùng cho các chương trình ứng dụng mà còn cho toàn bộ hệ thống vận hành phải được ghi lại.

C.4.3 Đặc điểm kỹ thuật cấu hình hệ thống vận hành (AOD_OCD)

C.4.3.1 Mục tiêu

Mục đích của đặc điểm kỹ thuật cấu hình hệ thống vận hành là để xác định các thông số cấu hình an toàn có liên quan để hỗ trợ cho việc tích hợp các thành phần hệ thống vận hành và cho phép các chức năng an toàn hệ thống vận hành để thực hiện và thực thi các khái niệm an toàn hệ thống vận hành và các chính sách liên quan.

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

Họ này gồm có hai thành phần, các thành phần trong họ được phân mức trên cơ sở xác nhận mô tả của tài liệu và xác minh trong hệ thống vận hành.

C.4.3.3 Đặc điểm kỹ thuật cấu hình hệ thống vận hành AOD_OCD.1

Phụ thuộc vào: - Các khái niệm an toàn của vận hành ASD_CON.1

- Thiết kế thành phần ASD_STD.2

C.4.3.3.1 Hành động phát triển/tích hợp

AOD_OCD.1.1D - Nhà phát triển/tích hợp phải mô tả đặc điểm kỹ thuật cấu hình để xác định các thông số cấu hình an toàn liên quan nhằm hỗ trợ cho việc tích hợp các thành phần hệ thống và cho phép các chức năng an toàn hệ thống thực hiện và thực thi các khái niệm an toàn hệ thống của hoạt động và các chính sách liên quan.

C.4.3.3.2 Nội dung và mô tả các bằng chứng

AOD_OCD.1.1C - Đặc điểm kỹ thuật cấu hình sẽ mô tả tất cả các yêu cầu cấu hình liên quan tới STOE bao gồm cả môi trường hoạt động.

AOD_OCD.1.2C - Đặc điểm kỹ thuật cấu hình sẽ mô tả các thông số cấu hình an toàn sẵn có cho các nhà tích hợp hệ thống hoặc người dùng /người quản trị tương đương của STOE có vai trò và trách nhiệm đó.

AOD_OCD.1.3C - Đặc điểm kỹ thuật cấu hình sẽ xác định tất cả các chế độ hoạt động có thể của STOE (bao gồm cả hoạt động khi có sự cố hoặc lỗi hoạt động), hậu quả và tác động đối với việc duy trì hoạt động an toàn.

AOD_OCD.1.4C - Đặc điểm kỹ thuật cấu hình phải có cảnh báo về chức năng có thể truy nhập cấu hình và đặc quyền đó phải được kiểm soát trong một môi trường xử lý an toàn.

AOD_OCD.1.5C - Đặc điểm kỹ thuật cấu hình cần nêu rõ tất cả các trách nhiệm liên quan đến cấu hình cần thiết cho hoạt động an toàn của STOE, bao gồm cả sự phụ thuộc vào hệ thống hoạt động bên ngoài.

AOD_OCD.16C - Đặc điểm kỹ thuật cấu hình phải phù hợp nhất quán với khái niệm an toàn của hoạt động.

AOD_OCD.1.7C - Đặc điểm kỹ thuật cấu hình sẽ hiển thị tất cả các thông số an toàn thành phần theo yêu cầu của khái niệm an toàn của hoạt động được thực hiện bởi thiết kế thành phần.

C.4.3.3.3 Hành động đánh giá

AOD_OCD.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.4.3.4 Xác minh đặc điểm kỹ thuật cấu hình hệ thống vận hành AOD_OCD.2

Phân cấp theo đặc điểm kỹ thuật cấu hình hệ thống hoạt động AOD_OCD.1

Phụ thuộc vào: - Khái niệm an toàn của hoạt động ASD_CON.1;

- Thiết kế thành phần ASD_STD.2

C.4.3.4.1 Hành động phát triển/tích hợp

AOD_OCD.2.1D - Nhà phát triển/tích hợp sẽ cung cấp một đặc điểm kỹ thuật cấu hình để xác định các thông số cấu hình an toàn có liên quan nhằm hỗ trợ việc tích hợp của các thành phần hệ thống và cho phép các chức năng an toàn hệ thống thực hiện và thực thi các khái niệm an toàn hệ thống của hoạt động và các chính sách liên quan.

C.4.3.4.2 Nội dung và mô tả các bằng chứng

AOD_OCD.2.1C - Đặc điểm kỹ thuật cấu hình phải mô tả tất cả các yêu cầu cấu hình liên quan với STOE bao gồm cả môi trường hoạt động.

AOD_OCD.2.2C - Đặc điểm kỹ thuật cấu hình sẽ mô tả các thông số cấu hình an toàn sẵn có cho nhà tích hợp hệ thống hoặc người dùng/người quản trị tương đương của STOE có vai trò và trách nhiệm đó.

AOD_OCD.2.3C - Đặc điểm kỹ thuật cấu hình sẽ xác định tất cả các chế độ hoạt động có thể của STOE (bao gồm cả hoạt động khi có sự cố hoặc lỗi hoạt động), hậu quả và tác động đến việc duy trì hoạt động an toàn.

AOD_OCD.2.4C - Đặc điểm kỹ thuật cấu hình phải có cảnh báo về chức năng có thể truy cập cấu hình và đặc quyền đó phải được kiểm soát trong một môi trường xử lý an toàn.

AOD_OCD.2.5C - Đặc điểm kỹ thuật cấu hình cần trình bày rõ ràng tất cả các trách nhiệm liên quan đến cấu hình cần thiết cho hoạt động an toàn của STOE, bao gồm cả sự phụ thuộc vào hệ thống hoạt động bên ngoài.

AOD_OCD.2.6C - Đặc điểm kỹ thuật cấu hình phải phù hợp nhất quán với khái niệm an toàn của hoạt động.

AOD_OCD.2.7C - Đặc điểm kỹ thuật cấu hình sẽ hiển thị tất cả các thông số an toàn thành phần được yêu cầu bởi khái niệm an toàn của hoạt động được thực hiện bởi thiết kế thành phần.

C.4.3.4.3 Hành động đánh giá

AOD_OCD.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

AOD_OCD.2.2E - Hoạt động đánh giá sẽ lặp lại tất cả các thủ tục cài đặt và cấu hình để xác nhận rằng STOE đã được cấu hình và sử dụng một cách an toàn bởi chỉ sử dụng đặc điểm kỹ thuật cấu hình được cung cấp.

AOD_OCD.2.3E - Hoạt động đánh giá sẽ thực hiện kiểm tra độc lập để xác định rằng người sử dụng với sự hiểu biết về đặc điểm kỹ thuật cấu hình sẽ có thể xác định được lý do nếu STOE được cấu hình và hoạt động không an toàn

C.4.4 Tài liệu hướng dẫn sử dụng hệ thống vận hành (AOD_OGD)

C.4.4.1 Mục tiêu

Tài liệu hướng dẫn sử dụng hệ thống vận hành được thiết kế để cho tất cả người dùng của STOE, bao gồm cả người sử dụng đặc quyền như quản trị hệ thống. Chính sách an toàn, các thủ tục, quy tắc, trách nhiệm và các yêu cầu an toàn khác được xác định bởi các yêu cầu hoạt động và dự kiến được sử dụng bởi người sử dụng sẽ được mô tả trong tài liệu hướng dẫn sử dụng. Tài liệu hướng dẫn sử dụng nên mô tả các kiểm soát an toàn được cung cấp bởi SSF và cung cấp hướng dẫn trực tiếp trên hệ thống, bao gồm cả cảnh báo sử dụng an toàn tài liệu.

Hướng dẫn cho người dùng thông thường cung cấp cơ sở về sự hiểu biết các hoạt động của STOE và đánh giá chắc chắn rằng người dùng sẽ không độc hại cho hệ thống, các nhà cung cấp ứng dụng và những người khác thực hiện các giao tiếp bên ngoài của STOE sẽ tuân thủ các yêu cầu an toàn và phải sử dụng nó như dự định.

Hướng dẫn quản trị nhằm giúp các quản trị viên nắm được các kiểm soát an toàn được cung cấp bởi STOE, bao gồm cả kiểm soát kỹ thuật và hoạt động yêu cầu với người quản trị để thực hiện các hành động an toàn quan trọng và các chức năng đó cung cấp thông tin an toàn quan trọng.

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

Họ này gồm có hai thành phần, các thành phần trong họ được phân mức trên cơ sở xác nhận mô tả trong tài liệu và xác minh trong hệ thống hoạt động.

C.4.4.3 Các lưu ý áp dụng

Nội dung của tài liệu hướng dẫn sử dụng hệ thống vận hành sẽ được phản ánh trực tiếp bởi các chính sách, quy định, trách nhiệm, thủ tục và các biện pháp an toàn hoạt động có liên quan với người sử dụng và được quy định trong các kiểm soát vận hành.

Yêu cầu AOD_OGD.1.4.C đảm bảo rằng bất kỳ cảnh báo cho người sử dụng của STOE liên quan đến môi trường an toàn STOE và các mục tiêu an toàn được mô tả trong SPP/SST một cách phù hợp trong hướng dẫn sử dụng.

C.4.4.4 Hướng dẫn sử dụng AOD_OGD.1

Phụ thuộc vào các khái niệm an toàn của hoạt động ASO_CON.1

C.4.4.4.1 Hành động quản lý

Hành động quản lý sẽ cung cấp hướng dẫn sử dụng AOD_OGD.1.1M.

C.4.4.4.2 Nội dung và mô tả các bằng chứng

AOD_OGD.1.1C - Hướng dẫn sử dụng sẽ mô tả từng vai trò người sử dụng, các chức năng, các giao tiếp có sẵn cho các mức người dùng của STOE.

AOD_OGD.1.2C - Hướng dẫn sử dụng sẽ mô tả từng vai trò người sử dụng, các kiểm soát hoạt động có liên quan tới các mức người dùng đó.

AOD_OGD.1.3C - Hướng dẫn sử dụng sẽ mô tả việc sử dụng các chức năng an toàn người dùng có thể truy nhập được cung cấp bởi STOE.

A0D_OGD.1.4C - Hướng dẫn sử dụng sẽ mô tả từng vai trò người dùng, tất cả các thông số an toàn dưới sự kinh doanh của mức người dùng để đưa ra các giá trị an toàn phù hợp.

AOD_OGD.1.5C - Hướng dẫn sử dụng phải có cảnh báo về các chức năng người dùng truy nhập có thể và các đặc quyền đó phải được kiểm soát trong môi trường xử lý an toàn.

AOD_OGD.1.6C - Hướng dẫn người sử dụng cần nêu rõ trách nhiệm của tất cả người dùng cần thiết cho hoạt động an toàn của STOE, bao gồm cả những người liên quan đến cơ chế người dùng trong quá trình hoạt động hệ thống.

AOD_OGD.1.7C - Hướng dẫn người sử dụng phải phù hợp nhất quán với khái niệm an toàn của hoạt động.

C.4.4.4.3 Hoạt động đánh giá

AOD_OGD.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.4.4.5 Xác minh hướng dẫn sử dụng AOD_OGD.2

Phân cấp theo hướng dẫn sử dụng AOD_OGD.1

Phụ thuộc vào khái niệm an toàn của hoạt động ASD_CON.1

C.4.4.5.1 Hành động quản lý

AOD_OGD.2.1M - Hành động quản lý sẽ sung cấp hướng dẫn sử dụng AOD_OGD.1.1M.

C.4.4.5.2 Nội dung và mô tả các bằng chứng

AOD_OGD.2.1C - Hướng dẫn sử dụng sẽ mô tả từng vai trò người sử dụng, các chức năng, các giao tiếp có sẵn cho các mức người dùng của STOE.

AOD_OGD.2.2C - Hướng dẫn sử dụng sẽ mô tả từng vai trò người sử dụng, các kiểm soát hoạt động có liên quan tới các mức người dùng đó.

AOD_OGD.2.3C - Hướng dẫn sử dụng sẽ mô tả việc sử dụng các chức năng an toàn người dùng có thể truy nhập được cung cấp bởi STOE.

AOD_OGD.2.4C - Hướng dẫn sử dụng sẽ mô tả từng vai trò người dùng, tất cả các thông số an toàn dưới sự kiểm soát của mức người dùng để đưa ra các giá trị an toàn phù hợp.

AOD_OGD.2.5C - Hướng dẫn sử dụng phải có cảnh báo về các chức năng người dùng truy nhập có thể và các đặc quyền đó phải được kiểm soát trong môi trường xử lý an toàn.

AOD_OGD.2.6C - Hướng dẫn người sử dụng cần nêu rõ trách nhiệm của tất cả người dùng cần thiết cho hoạt động an toàn của STOE, bao gồm cả những người liên quan đến cơ chế người dùng trong quá trình hoạt động hệ thống.

AOD_OGD.2.7C - Hướng dẫn người sử dụng phải phù hợp nhất quán với khái niệm an toàn của hoạt động.

C.4.4.5.3 Hoạt động đánh giá

AOD_OGD.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

AOD_OGD.2.2E - Người đánh giá sẽ tiến hành thẩm tra khả năng sử dụng các hướng dẫn sử dụng.

C.4.5 Xác minh tài liệu hướng dẫn (AOD_GRV)

C.4.5.1 Mục tiêu

Nhằm chứng minh rằng tài liệu hướng dẫn vẫn đúng sau khi thay đổi hoặc điều chỉnh các thành phần hệ thống, cấu hình hệ thống hoặc môi trường hoạt động.

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

Họ này có một thành phần

C.4.5.3 Xác minh hướng dẫn AOD_GVR.1

Phụ thuộc vào: - Đặc điểm kỹ thuật cấu hình hệ thống hoạt động AOD_OCD.1

- Hướng dẫn sử dụng AOD_OGD.1

C.4.5.3.1 Mục tiêu

Để chứng minh rằng tài liệu hướng dẫn vẫn đúng sau khi thay đổi hoặc điều chỉnh các thành phần hệ thống, cấu hình hệ thống hoặc môi trường hoạt động.

C.4.3.3.2 Các lưu ý áp dụng

Thành phần này không chỉ làm thay đổi địa chỉ hoặc điều chỉnh các phần của tài liệu hướng dẫn hệ thống hoạt động mà các bộ phận khác cũng có thể trở thành không hợp lệ.

C.4.5.3.3 Hành động phát triển/tích hợp

AOD_GVR.1.1D - Sau khi thay đổi hoặc điều chỉnh các thành phần hệ thống, cấu hình hệ thống hoặc môi trường hoạt động, Nhà phát triển/tích hợp sẽ thực hiện phân tích kiểm tra tài liệu hướng dẫn để kiểm tra tất cả các cấu hình hệ thống hoạt động và tài liệu hướng dẫn vẫn chính xác và nhất quán.

C.4.5.3.4 Nội dung và mô tả các bằng chứng

AOD_GVR.1.1C - Các phân tích xác minh tài liệu hướng dẫn sẽ cho thấy đặc điểm kỹ thuật cấu hình không bị ảnh hưởng bởi những thay đổi hoặc hiệu chỉnh hoặc đã được cập nhật một cách chính xác để phản ánh những thay đổi hoặc hiệu chỉnh.

AOD_GVR.1.2C - Các phân tích xác minh tài liệu hướng dẫn sẽ cho thấy hướng dẫn người sử dụng không bị ảnh hưởng bởi những thay đổi hoặc hiệu chỉnh, hoặc đã được cập nhật một cách chính xác để phản ánh những thay đổi hoặc hiệu chỉnh.

C.4.5.3.5 Hành động đánh giá

AOD_GVR.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.5 Lớp ASD: Tài liệu kiến trúc, thiết kế và cấu hình hệ thống vận hành

C.5.1 Giới thiệu

Lớp bảo đảm ASD tương đương với lớp ADV trong tiêu chuẩn TCVN 8709-3. Tuy nhiên, sự phát triển và hội nhập thông tin cần thiết và thích hợp cho các hệ thống vận hành là khác biệt với định nghĩa trong lớp ADV đòi hỏi phải xác định một lớp mới.

Mục đích của lớp này là để đánh giá các quyết định kiến trúc, thiết kế và cấu hình đã được thiết lập để đảm bảo rằng họ là đầy đủ và hoàn chỉnh về mặt đáp ứng các yêu cầu chức năng đánh chống lại hệ thống vận hành. Thông qua tài liệu kiến trúc, thiết kế cấu hình để có cái nhìn sâu sắc về những quyết định này. Mục đích thứ hai của mục này là để xác minh rằng kiến trúc hệ thống hoạt động, thiết kế và cấu hình phản ánh các yêu cầu an toàn phân bổ cho các phân hệ và thành phần khác nhau của hệ thống vận hành. Để làm điều này, các thuộc tính an toàn của tất cả các giao tiếp nội bộ phải được xác định và các thuộc tính an toàn (như phân tách không gian địa chỉ) được thực thi bởi một phần tử của kiến trúc.

C.5.2 Mô tả kiến trúc (ASD_SAD)

C.5.2.1 Mục tiêu

Mục đích mô tả kiến trúc hệ thống vận hành là trình bày tổng quan về hệ thống vận hành về mặt cấu trúc (các phân hệ, các giao tiếp cho hệ thống vận hành bên ngoài), hoạt động tương tác (giao diện, liên kết nối, dữ liệu và luồng kiểm soát) và mục đích. Thông tin này hỗ trợ sự hiểu biết và thực hiện các khía cạnh khác nhau của việc đánh giá hệ thống hoạt động như: việc phân bổ các bảo đảm cho việc phân chia của hệ thống vận hành, khái niệm an toàn hệ thống hoạt động của các hoạt động, chiến lược kiểm tra hệ thống vận hành, kế hoạch và các thủ tục. Cần được xác định rõ:

a) Các phân hệ của hệ thống vận hành;

b) Các giao tiếp bên trong và bên ngoài để các phân hệ và các chức năng được cung cấp thông qua các giao diện được xác định;

c) Các kết nối tương tác giữa các phân hệ và luồng thông tin giữa các phân hệ trên các kết nối tương tác;

d) Các hệ thống hoạt động bên ngoài mà các giao tiếp hệ thống vận hành và các mối quan hệ giữa hệ thống vận hành và các hệ thống bên ngoài này trao đổi;

e) Các kết nối tương tác với các hệ thống vận hành bên ngoài và các luồng thông tin giữa hệ thống hoạt động và các hệ thống vận hành bên ngoài qua các kết nối tương tác.

C.5.2.2 Các lưu ý áp dụng

Mô tả kiến trúc là một tài liệu tổng quát mô tả kiến trúc hệ thống, không phải là một tài liệu an toàn cụ thể. Các khía cạnh an toàn của thiết kế kiến trúc được giải quyết trong ASD_CON.

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

Họ này có một thành phần.

C.5.2.4 Mô tả kiến trúc ASD_SAD.1

C.5.2.4.1 Hành động phát triển/tích hợp

ASD_SAD.1.1D - Nhà phát triển/tích hợp sẽ cung cấp mô tả kiến trúc của hệ thống.

C.5.2.4.2 Nội dung và mô tả các bằng chứng

ASD_SAD.1.1C - Mô tả kiến trúc phải nhận biết được STOE về phân hệ và các giao tiếp và kết nối tương tác giữa các phân hệ.

ASD_SAD.1.2C - Mô tả kiến trúc phải nhận biết được các hệ thống vận hành bên ngoài tương tác với STOE và các giao tiếp, kết nối tương tác giữa STOE và hệ thống vận hành bên ngoài.

ASD_SAD.1.3C - Mô tả kiến trúc sẽ mô tả mục đích và chức năng của các phân hệ xác định, kết nối tương tác và giao tiếp của STOE.

ASD_SAD.1.4C - Mô tả kiến trúc phải mô tả mục đích của kết nối tương tác và các giao tiếp xác định từ STOE tới hệ thống vận hành bên ngoài và phải mô tả các dịch vụ từ nhà cung cấp tới các hệ thống vận hành bên ngoài.

ASD_SAD.1.5C - Mô tả kiến trúc phải nhất quán.

C.5.2.4.3 Hành động đánh giá

ASD_SAD.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.5.3 Khái niệm an toàn của vận hành (ASD_CON)

C.5.3.1 Mục tiêu

Mục đích của khái niệm an toàn của vận hành là để mô tả các chính sách an toàn, các thuộc tính và tính chất đặc điểm của hệ thống vận hành khi được cung cấp và thực thi trong việc hỗ trợ doanh nghiệp. Điều này sẽ cho phép phân tích bằng chứng của kiến trúc và thiết kế để xác nhận rằng STOE thực thi các chính sách và thuộc tính cần thiết.

C.5.3.2 Các lưu ý áp dụng

Các kỹ thuật khác nhau thường được sử dụng để đảm bảo tính hiệu quả của các kiểm soát kỹ thuật và hoạt động thực hiện cho SSF. Trong trường hợp kiểm soát kỹ thuật, các cơ chế phổ biến cần thiết thường được thực hiện ở mức phần cứng (ví dụ như các cơ chế quản lý bộ nhớ). Trong trường hợp điều khiển hoạt động, các cơ chế thủ tục tổ chức rộng thường được sử dụng (ví dụ như phân chia nhiệm vụ).

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

Họ này có một thành phần

C.5.3.4 Khái niệm an toàn vận hành ASD_CON.1

Phụ thuộc vào mô tả kiến trúc ASD_SAD.1

C.5.3.4.1 Hành động phát triển/tích hợp

ASD_CON.1.1D - Nhà phát triển/tích hợp sẽ cung cấp tài liệu khái niệm an toàn của vận hành cho tất cả SSF.

C.5.3.4.2 Nội dung và mô tả các bằng chứng

ASD_CON.1.1C - Tài liệu khái niệm an toàn của vận hành phải ở mức độ chi tiết phù hợp với mô tả của các giao tiếp và kết nối tương tác được cung cấp trong mô tả kiến trúc.

ASD_CON.1.2C - Tài liệu khái niệm an toàn của vận hành phải mô tả tất cả các chính sách an toàn, thuộc tính và đặc điểm của STOE.

ASD_CON.1.3C - Tài liệu khái niệm an toàn của vận hành phải bao gồm tất cả các chế độ hoạt động của STOE (ví dụ: chế độ sao lưu hoặc chế độ suy thoái của hoạt động).

ASD_CON.1.4C - Tài liệu khái niệm an toàn của vận hành phải mô tả tùy chọn cấu hình an toàn bắt buộc đối với các cản phẩn thành phần

ASD_CON.1.5C - Tài liệu khái niệm an toàn của vận hành phải mô tả các miền an toàn của STOE.

ASD_CON1.6C - Tài liệu khái niệm an toàn của vận hành phải mô tả các thuộc tính an toàn rằng miền an toàn thực thi trên các miền khác, bao gồm cả các biện pháp để đảm bảo hoạt động chính xác của SSF.

ASD_CON1.7C - Tài liệu khái niệm an toàn của vận hành phải chứng minh rằng quá trình khởi tạo SSF ngăn ngừa việc bỏ qua hoặc làm xáo trộn thiết lập chức năng - thực thi SFR.

ASD_CON.1.8C - Tài liệu khái niệm an toàn của vận hành phải chứng minh rằng SSF có khả năng tự bảo vệ bởi việc xáo trộn.

ASD_CON.1.9C - Tài liệu khái niệm an toàn của vận hành phải chứng minh rằng SSF ngăn ngừa việc bỏ qua chức năng thực thi SFR.

ASD_CON.1.10C - Tài liệu khái niệm an toàn của vận hành phải chứng minh rằng luồng thông tin giữa các miền của STOE, và giữa các STOE và các hệ thống vận hành bên ngoài không bỏ qua, gây cản trở hoặc giả mạo chức năng SFR thực thi.

ASD_CON.1.11C - Tài liệu khái niệm an toàn của vận hành phải nhất quán.

C.5.3.4.3 Hành động đánh giá

ASD_CON.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

ASD_CON.1.2E - Người đánh giá sẽ xác nhận rằng tài liệu khái niệm an toàn vận hành là phù hợp nhất quán với mô tả kiến trúc.

C.5.4 Đặc điểm kỹ thuật chức năng của giao diện (ASD_IFS)

C.5.4.1 Mục tiêu

Mục đích của đặc điểm kỹ thuật chức năng giao diện hệ thống vận hành là cung cấp một mô tả về các chức năng an toàn hệ thống vận hành có thể truy cập vào giao diện và các thuộc tính an toàn của chúng.

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

Họ này có một thành phần

C.5.4.3 Đặc điểm kỹ thuật chức năng giao diện ASD_IFS.1

Phụ thuộc vào mô tả kiến trúc ASD_SAD.1

C.5.4.3.1 Hành động phát triển/tích hợp

ASD_IFS.1.1D - Nhà phát triển/tích hợp sẽ cung cấp đặc điểm kỹ thuật chức năng giao diện.

C.5.4.3.2 Nội dung và mô tả các bằng chứng

ASD_IFS.1.1C - Đặc điểm kỹ thuật chức năng giao diện phải xác nhận và mô tả tất cả các giao diện STOE có sẵn, các thuộc tính an toàn của các giao diện đó và các chức năng an toàn có thể truy nhập thông qua các giao diện đó.

ASD_IFS.1.2C - Đặc điểm kỹ thuật chức năng giao diện phải phù hợp nhất quán

C.5.4.3.3 Hành động đánh giá

ASD_IFS.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

ASD_IFS.1.2E - Người đánh giá sẽ xác nhận rằng đặc điểm kỹ thuật chức năng giao diện phù hợp nhất quán với mô tả kiến trúc.

C.5.5 Thiết kế STOE (ASD_STD)

C.5.5.1 Mục tiêu

Mục đích của họ thiết kế STOE để cung cấp một mô tả về thiết kế hệ thống và SSF của nó, chỉ ra cách thức chức năng được phân bổ cho các bộ phận khác nhau của hệ thống.

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

Họ này có ba thành phần, các thành phần được phân mức trên cơ sở gia tăng chi tiết được cung cấp trong mô tả SSF từ việc thiết kế phân hệ đến triển khai thực hiện.

C.5.5.3 Thiết kế phân hệ ASD_STD.1

Phụ thuộc vào: - Mô tả kiến trúc ASD_SAD.1

- Đặc điểm kỹ thuật chức năng giao diện ASD_IFS.1

C.5.5.3.1 Mục tiêu

Trong thành phần này, TOE hệ thống được mô tả ở mức của phân hệ. Mục tiêu của thành phần này là để đảm bảo rằng thiết kế hệ thống quy định cụ thể gồm:

a) Các phân hệ;

b) Phân bổ chức năng an toàn cho các phân hệ;

c) Các thuộc tính an toàn cho từng phân hệ;

d) Các giao diện cho từng phân hệ và chức năng được cung cấp thông qua từng giao diện;

e) Các thành phần của từng phân hệ được thiết lập.

C.5.5.3.2 Các lưu ý áp dụng

Tại mức phân tích thiết kế STOE, người đánh giá chỉ kiểm tra việc phân bổ SSF ở mức phân hệ thông qua kiểm tra thiết kế phân hệ. Thiết kế phân hệ không cần thiết phải xây dựng tài liệu riêng cho phân hệ mà cần cung cấp các thông tin thiết kế đáp ứng tất cả các yêu cầu về nội dung và trình bày được xác định dưới đây và các thông tin liên quan có thể dễ dàng xác định bởi người đánh giá trong tài liệu đi kèm.

C.5.5.3.3 Hành động phát triển/tích hợp

ASD_STD.1.1D - Nhà phát triển/tích hợp sẽ cung cấp tài liệu thiết kế phân hệ The

ASD_STD.1.2D - Nhà phát triển/tích hợp sẽ cung cấp việc ánh xạ từ thiết kế phân hệ đến mô tả kiến trúc.

C.5.5.3.4 Nội dung và mô tả các bằng chứng

ASD_STD.1.1C - Thiết kế phân hệ phải mô tả các chức năng an toàn được cung cấp cho từng hệ thống.

ASD_STD.1.2C - Thiết kế phân hệ phải sẽ xác định tất cả phần cứng, phần sụn và phần mềm được yêu cầu bởi các chức năng an toàn được phân bổ cho các phân hệ.

ASD_STD.1.3C - Thiết kế phân hệ phải xác định các giao diện cho từng phân hệ.

ASD_STD.1.4C -Thiết kế phân hệ phải xác định các thuộc tính an toàn cho từng phân hệ.

ASD_STD.1.5C - Thiết kế phân hệ phải mô tả các giao diện cho từng phân hệ về mặt mục đích và phương pháp sử dụng, các ngoại lệ và bản tin thông báo lỗi.

ASD_STD.1.6C - Thiết kế phân hệ phải xác định các thành phần của từng phân hệ được thiết lập.

ASD_STD.1.7C - Thiết kế phân hệ phải phù hợp nhất quán.

ASD_STD.1.8C - Thiết kế phân hệ phải là một cài đặt hoàn chỉnh các chức năng an toàn của STOE bao gồm cả chức năng miền cụ thể

ASD_STD.1.9C - Việc ánh xạ từ thiết kế phân hệ đến mô tả kiến trúc phải chứng minh rằng tất cả các phần tử của mô tả kiến trúc được trình bày trong thiết kế phân hệ.

C.5.5.3.5 Hành động đánh giá

ASD_STD.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

ASD_STD.1.2E - Người đánh giá sẽ xác nhận rằng thiết kế phân hệ phù hợp với mô tả kiến trúc và các đặc điểm kỹ thuật chức năng giao diện.

C.5.5.4 Thiết kế thành phần ASD_STD.2

Phụ thuộc vào: - Mô tả kiến trúc ASD_SAD.1;

- Đặc điểm kỹ thuật chức năng giao diện ASD_IFS.1

C.5.5.4.1 Mục tiêu

STOE được mô tả ở cả hai mức là phân hệ và các thành phần. Mức thành phần bổ sung của thiết kế quy định cụ thể, gồm:

a) Mục đích và các chức năng của từng thành phần hệ thống vận hành;

b) Phân bổ các chức năng an toàn cho từng thành phần;

c) Các thuộc tính an toàn của từng thành phần;

d) Các giao diện hệ thống phụ được cung cấp bởi mỗi thành phần;

e) Các giao diện của phân hệ được cung cấp bởi từng thành phần;

f) Các chức năng được cung cấp thông qua các giao diện xác định cho các thành phần;

g) Cách thức cung cấp chức năng an toàn và các thuộc tính an toàn của từng thành phần.

C.5.5.4.2 Các lưu ý áp dụng

Ở mức phân tích thiết kế STOE, người đánh giá kiểm tra việc phân bổ SSF ở cả mức phân hệ và thành phần. Thiết kế phân hệ không cần thiết phải xây dựng tài liệu riêng cho các phân hệ mà cần cung cấp các thông tin thiết kế đáp ứng tất cả các yêu cầu về nội dung và trình bày được xác định dưới đây và các thông tin liên quan có thể dễ dàng xác định bởi người đánh giá trong tài liệu đi kèm. Một phân hệ được xây dựng từ một thành phần duy nhất thì cùng một tài liệu có thể đáp ứng cả các yêu cầu thiết kế phân hệ và thành phần nó.

Việc thiết kế thành phần cung cấp một mô tả chi tiết về các hoạt động nội bộ của SSF và tất cả các thành phần được xác định trong thiết kế thành phần do đó cần có chức năng SSF-thực thi. Đối với các thành phần phần mềm, thiết kế thành phần ở một mức độ chi tiết hơn so với các mô-đun mã riêng. Nếu việc xác định thiết kế ở mức độ mô-đun mã là cần thiết, phù hợp với các thành phần được quy định trong tiêu chuẩn TCVN 8709:2011.

C.5.5.4.3 Hành động phát triển/tích hợp

ASD_STD.2.1D - Nhà phát triển/tích hợp phải cung cấp tài liệu thiết kế phân hệ và thiết kế thành phần.

ASD_STD.2.2D - Nhà phát triển/tích hợp phải cung cấp ánh xạ từ thiết kế phân hệ đến mô tả kiến trúc.

ASD_STD.2.3D - Nhà phát triển/tích hợp phải cung cấp ánh xạ từ thiết kế thành phần tới thiết kế phân hệ.

ASD_STD.2.4D - Nhà phát triển/tích hợp phải cung cấp các phân tích phù hợp đặc điểm kỹ thuật tổng thể STOE.

C.5.5.4.4 Nội dung và mô tả các bằng chứng

ASD_STD.2.1C - thiết kế phân hệ phải mô tả các chức năng an toàn được cung cấp cho từng phân hệ.

ASD_STD.2.2C - Thiết kế phân hệ phải xác định tất cả phần cứng, phần sụn và phần mềm được yêu cầu bởi chức năng an toàn được phân bổ cho từng phân hệ.

ASD_STD.2.3C - Thiết kế phân hệ phải xác định các giao diện cho từng phân hệ.

ASD_STD.2.4C - Thiết kế phân hệ phải xác định các thuộc tính an toàn cho từng phân hệ.

ASD_STD.2.5C - Thiết kế phân hệ phải mô tả các giao diện cho từng phân hệ về mục đích và phương pháp sử dụng, các ngoại lệ và bản tin thông báo lỗi của chúng.

ASD_STD.2.6C - Thiết kế phân hệ phải xác định các thành phần của từng phân hệ được thiết lập.

ASD_STD.2.7C - Thiết kế phân hệ phải phù hợp nhất quán.

ASD_STD.2.8C - Thiết kế phân hệ phải là một cài đặt hoàn chỉnh các chức năng an toàn của STOE bao gồm cả chức năng miền cụ thể

ASD_STD.2.9C - Việc ánh xạ từ thiết kế phân hệ đến mô tả kiến trúc phải chứng minh rằng tất cả các phần tử của mô tả kiến trúc được trình bày trong thiết kế phân hệ.

ASD_STD.2.10C - Thiết kế phân hệ phải mô tả mục đích và chức năng của các thành phần của từng phân hệ.

ASD_STD.2.11C - Thiết kế thành phần phải xác định các mối quan hệ tương tác giữa các thành phần của từng phân hệ.

ASD_STD.2.12C - Thiết kế thành phần phải xác định các giao diện cho phân hệ STOE đáp ứng cho từng thành phần.

ASD_STD.2.13C - Thiết kế thành phần phải mô tả các giao diện cho phân hệ STOE đáp ứng cho từng thành phần về mục đích và phương pháp sử dụng của chúng.

ASD_STD.2.14C - Thiết kế thành phần phải mô tả các chức năng an toàn được cung cấp của từng thành phần

ASD_STD.2.15C - Thiết kế thành phần phải xác định các thuộc tính an toàn cho từng thành phần.

ASD_STD.2.16C - Thiết kế thành phần phải mô tả cách thức cung cấp các chức năng an toàn và các thuộc tính an toàn của từng thành phần.

ASD_STD.2.17C - Thiết kế thành phần cho từng phân hệ phải phù hợp nhất quán.

ASD_STD.2.18C - Thiết kế thành phần cho từng phân hệ phải cung cấp một cài đặt hoàn chỉnh các chức năng an toàn được gán cho từng phân hệ bao gồm cả chức năng tên miền cụ thể.

ASD_STD.2.19C - Việc ánh xạ từ thiết kế thành phần đến thiết kế phân hệ phải chứng minh rằng tất cả các phần tử của thiết kế phân hệ được thể hiện trong thiết kế thành phần.

ASD_STD.2.20C - Các phân tích phù hợp đặc điểm kỹ thuật tổng thể STOE phải chứng minh rằng thiết kế thành phần phù hợp với mô tả thực hiện của SSFs trong đặc điểm kỹ thuật tổng thể STOE của SST và các đặc điểm kỹ thuật tổng thể miền STOE bất kỳ.

C.5.5.4.5 Hành động đánh giá

ASD_STD.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

ASD_STD.2.2E - Người đánh giá phải xác định rằng thiết kế phân hệ phù hợp với mô tả kiến trúc và các đặc điểm kỹ thuật chức năng giao diện.

ASD_STD.2.3E - Người đánh giá phải xác định rằng thiết kế thành phần phù hợp với thiết kế phân hệ và các đặc điểm kỹ thuật chức năng giao diện.

C.5.5.5 Mô tả triển khai bổ sung thiết kế ASD_STD.3

Phụ thuộc vào: - Mô tả kiến trúc ASD_SAD.1

- Đặc điểm kỹ thuật chức năng giao diện ASD_IFS.1

C.5.5.5.1 Mục tiêu

Trong thành phần này, các thông tin thiết kế STOE được bổ sung bằng cách kiểm tra việc trình bày thực hiện của các thành phần tới hạn, đặc biệt là trong trường hợp SSF được thực hiện bởi cấu hình của các thành phần, chứ không phải là một thuộc tính vốn có của các thành phần.

C.5.5.5.2 Các lưu ý áp dụng

Phần này không dự định thực hiện (ví dụ mã nguồn) để cung cấp cho tất cả các thành phần của hệ thống hoạt động, mà chỉ cho những người có cấu hình phần khác của hệ thống hoạt động hoặc thực hiện chức năng an toàn tới hạn để hỗ trợ các thành phần khác. Các chương trình tích hợp hoặc các chương trình thông thường được phát triển riêng cho hệ thống hoạt động sẽ là mục tiêu đối với họ này.

C.5.5.5.3 Hành động phát triển/tích hợp

ASO_STD.3.1D - Nhà phát triển/tích hợp sẽ cung cấp thiết kế phân hệ và thiết kế thành phần.

ASO_STD.3.2D - Nhà phát triển/tích hợp sẽ cung cấp trình bày thực hiện thiết kế thành phần đối với việc phân chia danh sách các thành phần.

ASD_STD.3.3D - Nhà phát triển/tích hợp sẽ cung cấp ánh xạ từ thiết kế phân hệ tới mô tả kiến trúc.

ASD_STD.3.4D - Nhà phát triển/tích hợp sẽ cung cấp ánh xạ từ thiết kế thành phần tới thiết kế phân hệ.

ASD_STD.3.5D - Nhà phát triển/tích hợp sẽ cung cấp các phân tích sự phù hợp đặc điểm kỹ thuật tổng thể STOE.

C.5.5.5.4 Nội dung và mô tả các bằng chứng

ASD_STD.3.1C - Thiết kế phân hệ phải mô tả các chức năng an toàn được cung cấp cho từng phân hệ.

ASD_STD.3.2C - Thiết kế phân hệ phải xác định tất cả phần cứng, phần sụn và phần mềm được yêu cầu bởi chức năng an toàn được phân bổ cho từng phân hệ.

ASD_STD.3.3C - Thiết kế phân hệ phải xác định các giao diện cho từng phân hệ.

ASD_STD.3.4C - Thiết kế phân hệ phải xác định các thuộc tính an toàn cho từng phân hệ.

ASD_STD.3.5C - Thiết kế phân hệ phải mô tả các giao diện của từng phân hệ về mục đích và phương pháp sử dụng, các ngoại lệ và các bản tin thông báo lỗi của chúng.

ASD_STD.3.6C - Thiết kế phân hệ phải xác định các thành phần của từng phân hệ được thiết lập.

ASD_STD.3.7C - Thiết kế phân hệ phải phù hợp nhất quán.

ASD_STD.3.8C - Thiết kế phân hệ phải là một cài đặt hoàn chỉnh các chức năng an toàn của STOE bao gồm cả chức năng tên miền cụ thể.

ASD_STD.3.9C - Việc ánh xạ từ thiết kế phân hệ tới mô tả kiến trúc phải chứng minh tất cả các phần tử của mô tả kiến trúc được thể hiện trong thiết kế phân hệ.

ASD_STD.3.10C - Thiết kế thành phần phải mô tả mục tiêu và các chức năng thành phần của từng phân hệ.

ASD_STD.3.11C - Thiết kế thành phần phải xác định các mối quan hệ tương tác giữa các thành phần của từng phân hệ.

ASD_STD.3.12C - Thiết kế thành phần phải xác định các giao diện của phân hệ STOE đáp ứng bởi từng thành phần.

ASD_STD.3.13C - Thiết kế thành phần phải mô tả các giao diện của phân hệ STOE đáp ứng bởi từng thành phần về mục tiêu và phương pháp sử dụng của chúng.

ASD_STD.3.14C - Thiết kế thành phần phải các chức năng an toàn được cung cấp bởi từng thành phần

ASD_STD.3.15C - Thiết kế thành phần phải xác định các thuộc tính an toàn của từng thành phần.

ASD_STD.3.16C - Thiết kế thành phần phải mô tả cách thức cung cấp các chức năng an toàn và thuộc tính an toàn của từng thành phần.

ASD_STD.3.17C - Thiết kế thành phần cho từng phân hệ phải phù hợp nhất quán.

ASD_STD.3.18C - Thiết kế thành phần cho từng phân hệ phải cung cấp một cài đặt hoàn chỉnh các chức năng an toàn được gán cho từng phân hệ bao gồm cả chức năng miền cụ thể.

ASO_STD.3.19C - Việc ánh xạ từ thiết kế thành phần đến thiết kế phân hệ phải chứng minh rằng tất cả các phần tử của thiết kế phân hệ được thể hiện trong thiết kế thành phần.

ASD_STD.3.20C - Các phân tích sự phù hợp đặc điểm kỹ thuật tổng thể STOE phải chứng minh rằng thiết kế thành phần phù hợp với mô tả thực hiện của SSFs trong đặc điểm kỹ thuật tổng thể STOE của SST và các đặc điểm kỹ thuật tổng thể miền STOE bất kỳ.

ASD_STD.3.21C - Trình bày thực hiện phải là một cài đặt hoàn chỉnh của thiết kế thành phần cho các thành phần xác định bao gồm tất cả các chức năng an toàn và thuộc tính an toàn được gán cho các thành phần đó.

ASD_STD.3.22C - Trình bày thực hiện phải thiết lập chức năng an toàn được cung cấp bởi các thành phần xác định về các yêu cầu cấu hình cụ thể của chúng.

ASD_STD.3.23C - Trình bày thực hiện phải phù hợp nhất quán.

C.5.5.5.5 Hành động đánh giá

ASD_STD.3.1 E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

ASD_STD.3.2E - Người đánh giá phải xác định rằng thiết kế phân hệ phù hợp với mô tả kiến trúc và các đặc điểm kỹ thuật chức năng giao diện.

ASD_STD.3.3E - Người đánh giá phải xác định rằng thiết kế thành phần phù hợp với thiết kế phân hệ và các đặc điểm kỹ thuật chức năng giao diện.

C.5.6 Xác minh yêu cầu (ASD_RVR)

C.5.6.1 Mục tiêu

Mục tiêu là để chứng minh rằng các yêu cầu an toàn được xác định trong SST vẫn có hiệu lực sau khi thay đổi hoặc hiệu chỉnh các rủi ro hoặc môi trường hệ thống.

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

Họ này có một thành phần.

C.5.6.3 Xác minh yêu cầu ASD_RVR.1

Không phụ thuộc.

C.5.6.3.1 Mục tiêu

Trong thành phần này, mục tiêu là để chứng minh rằng SST vẫn hợp lệ sau khi thay đổi hoặc hiệu chỉnh các rủi ro được đưa ra bởi hệ thống vận hành hoặc những ràng buộc khác về đánh giá.

C.5.6.3.2 Các lưu ý áp dụng

Thành phần này yêu cầu có một đánh giá rủi ro mới được thực hiện bởi chủ sở hữu hệ thống, hoặc đánh giá rủi ro hiện có được sửa đổi. Các mô hình, hình thức đánh giá rủi ro này nằm ngoài phạm vi của tiêu chuẩn này.

Thành phần này cũng có thể áp dụng khi các thay đổi để SSF hoặc SSA được yêu cầu vì lý do khác (ví dụ, kiểm soát đặc biệt hoặc bảo đảm đã được tìm thấy không có hiệu quả hoặc không thực tế trong thực tế).

C.5.6.3.3 Hành động phát triển/tích hợp

ASD_RVR.1.1D Nhà phát triển/tích hợp sẽ thực hiện các phân tích xác minh yêu cầu tra để xác nhận rằng SSFs và SSAS được định nghĩa trong SST tiếp tục áp dụng và phù hợp.

C.5.6.3.4 Nội dung và mô tả các bằng chứng

ASD_RVR.1.1C - Phân tích xác minh yêu cầu sẽ cho thấy định nghĩa vấn đề an toàn trong SST là không bị ảnh hưởng bởi những thay đổi hoặc hiệu chỉnh các rủi ro hoặc đã được cập nhật một cách chính xác để phản ánh những thay đổi hoặc hiệu chỉnh.

ASD_RVR.1.2C - Phân tích xác minh yêu cầu sẽ cho thấy các mục tiêu an toàn chức năng trong SST không bị ảnh hưởng bởi những thay đổi hoặc hiệu chỉnh định nghĩa vấn đề an toàn hoặc đã được cập nhật một cách chính xác để phản ánh những thay đổi hoặc hiệu chỉnh.

ASD_RVR.1.3C - Phân tích xác minh yêu cầu sẽ cho thấy các mục tiêu an toàn đảm bảo trong SST vẫn còn hiệu lực hoặc đã được cập nhật một cách chính xác để phản ánh những thay đổi hoặc hiệu chỉnh được yêu cầu.

ASD_RVR.1.4C - Phân tích xác minh yêu cầu sẽ cho thấy SSFs và SSAS phản ánh một cách chính xác các mục tiêu an toàn hiện tại trong SST.

C.5.6.3.5 Hành động đánh giá

ASD_RVR.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.5.7 Xác minh tài liệu thiết kế (ASD_DRV)

C.5.7.1 Mục tiêu

Mục tiêu là để chứng minh rằng tài liệu thiết kế an toàn vẫn đúng sau khi thay đổi hoặc hiệu chỉnh các thành phần hệ thống.

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

Họ này có một thành phần.

C.5.7.3 Xác minh thiết kế ASD_DVR.1

Phụ thuộc vào: - Mô tả kiến trúc ASO_SAD.1;

- Khái niệm an toàn của hoạt động ASD_CON.1;

- Đặc điểm kỹ thuật chức năng giao diện ASD_IFS.1;

- Thiết kế phân hệ ASD_STD.1

C.5.7.3.1 Mục tiêu

Trong thành phần này, mục tiêu là để chứng minh rằng các tài liệu an toàn vẫn đúng sau khi thay đổi hoặc hiệu chỉnh các thành phần hệ thống.

C.5.7.3.2 Các lưu ý áp dụng

Thành phần này không chỉ thay đổi địa chỉ hoặc hiệu chỉnh các phần của tài liệu thiết kế hệ thống hoạt động, mà các bộ phận khác có thể đã trở thành không hợp lệ.

Xác minh thiết kế sử dụng ASD_DVR có thể được thực hiện chỉ ở mô tả kiến trúc, đặc điểm kỹ thuật chức năng giao diện, thiết kế phân hệ và khái niệm an toàn của tài liệu hướng dẫn hoạt động có sẵn. Tuy nhiên, "tất cả các tài liệu thiết kế STOE" bao gồm thiết kế thành phần và trình bày thực hiện đại, nếu các thành phần mức cao hơn của ASD_STD được bao gồm trong SST.

C.5.7.3.3 Hành động phát triển/tích hợp

Sau khi thay đổi hoặc hiệu chỉnh các thành phần hệ thống, cấu hình hệ thống hoặc môi trường hoạt động, nhà phát triển/tích hợp sẽ thực hiện các phân tích xác minh tra thiết kế để kiểm tra tất cả các tài liệu thiết kế STOE vẫn chính xác và nhất quán.

C.5.7.3.4 Nội dung và mô tả các bằng chứng

ASD_DVR.1.1C - Đối với mỗi tài liệu thiết kế việc phân tích xác minh thiết kế sẽ cho thấy tài liệu không bị ảnh hưởng bởi các thay đổi hoặc hiệu chỉnh hoặc đã được cập nhật một cách chính xác để phản ánh những thay đổi hoặc hiệu chỉnh.

C.5.7.3.5 Hành động đánh giá

ASD_DVR.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.6 Lớp AOC: Quản lý cấu hình hệ thống vận hành

C.6.1 Giới thiệu

Mục đích của lớp quản lý cấu hình là đảm bảo rằng hệ thống được cài đặt trong môi trường vận hành được cấu hình đúng và nếu hệ thống sau đó được sửa đổi, những thay đổi có liên quan được kiểm soát CM.

Trường hợp sản phẩm COTS được kết hợp trong hệ thống vận hành, lớp này có thể được sử dụng để xác định xem các sản phẩm có đáp ứng các yêu cầu bảo đảm an toàn và được cấu hình chính xác tuân theo các hướng dẫn của các nhà cung cấp sản phẩm.

C.6.2 Cấu hình hệ thống vận hành (AOC_OBM)

C.6.2.1 Mục tiêu

Họ này xác định các tùy chọn cấu hình cho hệ thống vận hành phải được thiết lập trong khi cài đặt và đòi hỏi một hệ thống quản lý cấu hình để thông báo về việc xây dựng hệ thống hoạt động sử dụng các tùy chọn đó. Họ cũng yêu cầu hiệu chỉnh hệ thống vận hành sau khi cài đặt để được theo dõi và kiểm soát để hệ thống có thể được cài đặt lại một cách chính xác.

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

Họ này có hai thành phần. Các thành phần trong họ này được phân mức trên cơ sở xác nhận mô tả trong tài liệu và xác minh độc lập của người đánh giá.

C.6.2.3 Cấu hình hệ thống vận hành AOC_OBM.1

Không phụ thuộc.

C.6.2.3.1 Hành động phát triển/tích hợp

AOC_OBM.1.1D - Nhà phát triển/tích hợp phải cung cấp kế hoạch CM.

AOC_OBM.1.2D - Nhà phát triển/tích hợp phải sử dụng hệ thống CM để cung cấp một STOE được cài đặt phù hợp với kế hoạch CM.

C.6.2.3.2 Nội dung và mô tả các bằng chứng

AOC_OBM.1.1C - Kế hoạch CM phải mô tả cách thức STOE được cấu hình trong khi cài đặt.

AOC_OBM.1.2C - Kế hoạch CM phải mô tả cách thức các thay đổi cài đặt STOE được theo dõi và kiểm soát.

AOC_OBM.1.3C - Hệ thống CM phải thông báo các tùy chọn cấu hình của STOE được cài đặt.

AOC_OBM.1.4C - Hệ thống CM phải nhận dạng duy nhất STOE được cài đặt, mỗi thay đổi liên quan và trạng thái đánh giá.

C.6.2.3.3 Hành động đánh giá

AOC_OBM.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

AOC_OBM.2.2E - Người đánh giá sẽ xác minh một cách độc lập STOE được cài đặt ngược lại với kế hoạch CM và hệ thống CM.

C.6.2.4 Xác minh cấu hình hệ thống vận hành AOC_OBM.2

Phân cấp theo: cấu hình hệ thống vận hành AOC_OBM.1

Phụ thuộc: Không phụ thuộc.

C.6.2.4.1 Hành động phát triển/tích hợp

AOC_OBM.2.1D - Nhà phát triển/tích hợp sẽ cung cấp một kế hoạch CM.

AOC_OBM.2.2D - Nhà phát triển/tích hợp phải sử dụng một hệ thống CM để cung cấp một STOE được cài đặt phù hợp với kế hoạch CM.

C.6.2.4.2 Nội dung và mô tả các bằng chứng

AOC_OBM.2.1C - Kế hoạch CM phải mô tả cách thức STOE được cấu hình trong khi cài đặt.

AOC_OBM.2.2C - Kế hoạch CM phải mô tả cách thức thay đổi để cài đặt STOE được theo dõi và kiểm soát.

AOC_OBM.2.3C - Hệ thống CM trách phải thông báo các tùy chọn cấu hình của STOE được cài đặt.

AOC_OBM.2.4C - Hệ thống CM phải nhận dạng duy nhất STOE được cài đặt, mỗi thay đổi liên quan, trạng thái đánh giá.

C.6.2.4.3 Hành động đánh giá

AOC_OBM.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

AOC_OBM.2.2E - Người đánh giá sẽ xác minh một cách độc lập STOE được cài đặt ngược lại với kế hoạch CM và hệ thống CM.

C.6.3 Các sản phẩm thành phần được đánh giá (AOC_ECP)

C.6.3.1 Mục tiêu

Họ này xác định các yêu cầu đảm bảo và cấu hình cho các thành phần hệ thống hoạt động được tạo thành từ các sản phẩm được đánh giá. Khi tạo ra một hệ thống hoạt động từ các thành phần sản phẩm, cần phải xác định đảm bảo được yêu cầu từ các khía cạnh của hoạt động phát triển và tích hợp. Trường hợp sử dụng sản phẩm COTS được đánh giá thông thường sẽ không có các hoạt động phát triển thực hiện riêng biệt cho hệ thống hoạt động. Bảo đảm do đó phải được thu được từ đánh giá và chứng nhận sản phẩm, chẳng hạn như có giấy chứng nhận chính thức nói rằng sản phẩm đã được chứng nhận, ví dụ, tại EAL4 theo quy định tại tiêu chuẩn TCVN 8709.

Yêu cầu đảm bảo có thể được quy định như gói đảm bảo, chẳng hạn như EAL là một phần của PP hoặc SPP, hoặc xác định rõ ràng.

Trường hợp các thành phần sản phẩm có thông số cụ thể cho hoạt động an toàn, các thông số này phải được thiết lập một cách chính xác.

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

Họ này có hai thành phần. Các thành phần trong họ này được phân mức trên cơ sở xác nhận mô tả trong tài liệu và xác minh độc lập của người đánh giá.

C.6.3.3 Các sản phẩm thành phần được đánh giá AOC_ECP.1

Phụ thuộc vào: Cấu hình hệ thống hoạt động AOC_OBM.1

C.6.3.3.1 Hành động phát triển/tích hợp

AOC_ECP.1.1D - Nhà phát triển/tích hợp sẽ quy định gói đảm bảo được yêu cầu cho các sản phẩm thành phần hoặc miền an toàn chứa sản phẩm đó.

AOC_ECP.1.2D - Nhà phát triển/tích hợp sẽ cung cấp các thủ tục dự phòng cho từng sản phẩm được đánh giá.

AOC_ECP.1.3D - Nhà phát triển/tích hợp sẽ cung cấp một báo cáo chứng nhận độc lập hoặc báo cáo kỹ thuật đánh giá cho từng sản phẩm được đánh giá.

C.6.3.3.2 Nội dung và mô tả các bằng chứng

AOC_ECP.1.1C - Kế hoạch CM sẽ cho thấy các thông số hoạt động cho mỗi sản phẩm đánh giá được cấu hình phù hợp với thủ tục các thủ tục dự phòng.

AOC_ECP.1.2C - Đối với từng sản phẩm được đánh giá, báo cáo chứng nhận độc lập hoặc Báo cáo kỹ thuật đánh giá sẽ cho thấy các gói đảm bảo yêu cầu được thỏa mãn.

C.6.3.3.3 Hành động đánh giá

AOC_ECP.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.6.3.4 Xác minh sản phẩm thành phần được đánh giá AOC_ECP.2

Phân cấp theo: Các sản phẩm thành phần được đánh giá AOC_ECP.1

Phụ thuộc vào: Cấu hình hệ thống hoạt động AOC_OBM.1

C.6.3.4.1 Hành động phát triển/tích hợp

AOC_ECP.2.1D - Nhà phát triển/tích hợp sẽ quy định gói đảm bảo được đánh giá cho các sản phẩm thành phần hoặc miền an toàn chứa sản phẩm đó.

AOC_ECP.2.2D - Nhà phát triển/tích hợp sẽ cung cấp các thủ tục dự phòng cho từng sản phẩm được đánh giá.

AOC_ECP.2.3D - Nhà phát triển/tích hợp sẽ cung cấp một báo cáo chứng nhận độc lập hoặc báo cáo kỹ thuật đánh giá cho từng sản phẩm được đánh giá.

C.6.3.4.2 Nội dung và mô tả các bằng chứng

AOC_ECP.2.1C - Kế hoạch CM sẽ cho thấy các thông số hoạt động cho mỗi sản phẩm đánh giá được cấu hình phù hợp với thủ tục các thủ tục dự phòng.

AOC_ECP.2.2C - Đối với từng sản phẩm được đánh giá, báo cáo chứng nhận độc lập hoặc Báo cáo kỹ thuật đánh giá sẽ cho thấy các gói đảm bảo yêu cầu được thỏa mãn.

C.6.3.4.3 Hành động đánh giá

AOC_ECP.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

AOC_ECP.2.2E Người đánh giá sẽ xác nhận rằng các giả định về môi trường hoạt động được mô tả trong báo cáo xác nhận độc lập hoặc báo cáo kỹ thuật đánh giá của sản phẩm được đánh giá đáp ứng các yêu cầu về môi trường hoạt động của STOE.

C.6.4 Các sản phẩm thành phần không được đánh giá (AOC_UCP)

C.6.4.1 Mục tiêu

Họ này xác định các yêu cầu đảm bảo và cấu hình cho các thành phần hệ thống hoạt động được tạo thành từ các sản phẩm không được đánh giá. Khi tạo ra một hệ thống hoạt động từ các thành phần sản phẩm không được đánh giá, cần phải xác định đảm bảo được yêu cầu từ các khía cạnh của hoạt động phát triển và tích hợp. Đối với các sản phẩm như các chương trình ứng dụng kinh doanh được phát triển cho hệ thống hoạt động cụ thể, trong các hoạt động phát triển của chúng là bằng chứng đảm bảo tương tự như yêu cầu để đánh giá sản phẩm có thể được sản xuất bởi nhà phát triển sản phẩm.

Những tuyên bố bảo đảm của nhà phát triển sản phẩm có thể được thực hiện trên sự tin tưởng. Ngoài ra, để đạt được sự đảm bảo cao hơn, những tuyên bố có thể được xác minh qua việc thực hiện đánh giá sản phẩm.

Yêu cầu đảm bảo có thể được quy định như gói đảm bảo, chẳng hạn như một EAL là một phần của PP hoặc SPP hoặc được xác định rõ ràng.

Trường hợp các thành phần sản phẩm có thông số cụ thể cho hoạt động an toàn, các thông số này phải được thiết lập một cách chính xác.

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

Họ này có hai thành phần, các thành phần trong họ được phân mức trên cơ sở xác nhận mô tả trong tài liệu và xác minh độc lập của người đánh giá.

C.6.4.3 Sản phẩm thành phần không được đánh giá AOC_UCP.1

Phụ thuộc vào: Cấu hình hệ thống hoạt động AOC_OBM.1

C.6.4.3.1 Hành động phát triển/tích hợp

AOC_UCP.1.1D - Nhà phát triển/tích hợp sẽ quy định gói đảm bảo được yêu cầu cho các sản phẩm thành phần hoặc miền an toàn chứa sản phẩm đó.

AOC_UCP.1.2D - Nhà phát triển/tích hợp sẽ cung cấp tài liệu cấu hình cho từng sản phẩm thành phần không được đánh giá.

AOC_UCP.1.3D - Nhà phát triển/tích hợp sẽ cung cấp tuyên bố an toàn cho từng sản phẩm thành phần không được đánh giá.

C.6.4.3.2 Nội dung và mô tả các bằng chứng

AOC_UCP.1.1C - Kế hoạch CM sẽ cho thấy các thông số hoạt động cho từng sản phẩm không đánh giá được cấu hình phù hợp với tài liệu cấu hình của chúng.

AOC_UCP.1.2C - Đối với từng sản phẩm không được đánh giá, phát biểu của tuyên bố an toàn sẽ cho thấy gói đảm bảo yêu cầu được thỏa mãn.

C.6.4.3.3 Hành động đánh giá

AOC_UCP.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.6.4.4 Xác minh sản phẩm thành phần không được đánh giá AOC_UCP-2

Phân cấp theo: Sản phẩm thành phần không được đánh giá AOC_UCP.1

Phụ thuộc vào: Cấu hình hệ thống hoạt động AOC_OBM.1

C.6.4.4.1 Hành động phát triển/tích hợp

AOC_UCP.2.1D - Nhà phát triển/tích hợp sẽ quy định gói đảm bảo được yêu cầu cho các sản phẩm thành phần hoặc miền an toàn chứa sản phẩm đó.

AOC_UCP.2.2D - Nhà phát triển/tích hợp sẽ cung cấp tài liệu cấu hình cho từng sản phẩm thành phần không được đánh giá.

AOC_UCP.2.3D - Nhà phát triển/tích hợp sẽ cung cấp tuyên bố an toàn cho từng sản phẩm thành phần không được đánh giá.

C.6.4.4.2 Nội dung và mô tả các bằng chứng

AOC_UCP.2.1C - Kế hoạch CM sẽ cho thấy các thông số hoạt động cho từng sản phẩm không đánh giá được cấu hình phù hợp với tài liệu cấu hình của chúng.

AOC_UCP.2.2C - Đối với từng sản phẩm không được đánh giá, phát biểu của tuyên bố an toàn sẽ cho thấy gói đảm bảo yêu cầu được thỏa mãn.

C.6.4.4.3 Hành động đánh giá

AOC_UCP.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

AOC_UCP.2.2E - Người đánh giá thực hiện đánh giá sản phẩm và xác nhận rằng các sản phẩm không được đánh giá đáp ứng các gói đảm bảo được yêu cầu trong môi trường hoạt động của STOE.

C.7 Lớp AOT: Kiểm thử hệ thống vận hành

C.7.1 Giới thiệu

Mục đích của lớp này là để xác minh rằng các thành phần hệ thống vận hành khi cài đặt, tích hợp và cấu hình phù hợp với kiến trúc hệ thống vận hành và bằng chứng cấu hình hệ thống vận hành đáp ứng các yêu cầu an toàn chức năng quy định trong SST và có hiệu quả trong việc thực thi các khái niệm an toàn hệ thống vận hành của hoạt động. Kiến trúc hệ thống vận hành, tích hợp và tài liệu thiết kế hỗ trợ kế hoạch kiểm thử và thực hiện. Điều này được thực hiện bằng cách xác định rằng SSF đã được cấu hình theo quy định của các đặc điểm kỹ thuật cấu hình, kiểm tra ngược lại so với bằng chứng kiến trúc và thiết kế có liên quan bằng cách thực hiện một kiểm thử mẫu của các nhà phát triển/tích hợp và bằng cách kiểm thử độc lập một tập con của SSF.

Lớp này gồm có năm họ, bốn họ gồm: Phạm vi thử nghiệm hệ thống vận hành (AOT_COV), Thử nghiệm năng lực hệ thống vận hành (AOT_DPT), Thử nghiệm chức năng hệ thống vận hành (AOT_FUN) và Thử nghiệm độc lập hệ thống vận hành (AOT_IND) được dựa trên các họ trong tiêu chuẩn ISO/IEC 15408 để thử nghiệm sản phẩm. Họ cuối cùng, Thử nghiệm hồi quy hệ thống vận hành (AOT_REG) được sử dụng để kiểm tra các hiệu chỉnh của hệ thống vận hành khi đưa vào hoạt động.

Thử nghiệm sử dụng lớp AOT luôn được thực hiện trong môi trường thử nghiệm, vì vậy nó là các kiểm soát hoạt động trong môi trường vận hành sẽ thực hiện khác nhau để quan sát hành vi của chúng trong môi trường thử nghiệm. Do vậy các kết quả thử nghiệm thường phải được bổ sung bằng cách kiểm tra và xác minh các hồ sơ hoạt động và kiểm soát trong quá trình vận hành hệ thống.

C.7.2 Phạm vi kiểm thử hệ thống vận hành (AOT_COV)

C.7.2.1 Mục tiêu

Họ này đưa ra những khía cạnh của thử nghiệm để giải quyết tính đầy đủ của phạm vi thử nghiệm. Nghĩa là, nó đề cập đến phạm vi mà SSF được thử nghiệm và phạm vi thử nghiệm có đủ mức bao quát để chứng minh rằng SSF hoạt động theo quy định.

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

Họ này có hai thành phần, các thành phần trong họ được phân mức trên cơ sở thử nghiệm của tất cả các giao diện được định nghĩa trong đặc tả chức năng giao diện và thử nghiệm tất cả các thông số của các giao diện đó.

C.7.2.3 Bằng chứng phạm vi AOT_COV.1

Phụ thuộc vào: - Đặc tả chức năng giao diện ASD_IFS.1

- Thử nghiệm chức năng AOT_FUN.1

C.7.2.3.1 Mục tiêu

Mục tiêu của thành phần này là để thiết lập tất cả các giao diện cho SSF đã được thử nghiệm. Để đạt mục tiêu này phải được thông qua việc kiểm tra các phân tích về phạm vi thử nghiệm của AOT_FUN.

C.7.2.3.2 Các lưu ý áp dụng

Trong thành phần này, yêu cầu các nhà phát triển/tích hợp chứng minh rằng việc thử nghiệm đã thử nghiệm tất cả các chức năng an toàn xác định có sẵn theo mô tả trong đặc tả chức năng giao diện. Các phân tích không chỉ trình bày sự phù hợp giữa việc thử nghiệm và chức năng an toàn, mà cần cung cấp thông tin đầy đủ cho người đánh giá để xác định cách thức các chức năng đã được thực hiện. Thông tin này có thể được sử dụng trong việc lập kế hoạch cho các thử nghiệm đánh giá bổ sung. Mặc dù ở mức này các nhà phát triển/tích hợp đã chứng minh rằng từng chức năng trong đặc tả chức năng giao diện đã được thử nghiệm, số lần thử nghiệm từng chức năng không cần thiết phải đầy đủ.

C.7.2.3.3 Hành động phát triển/tích hợp

AOT_COV.1.1D - Nhà phát triển/tích hợp phải cung cấp các phân tích về phạm vi thử nghiệm.

C.7.2.3.4 Nội dung và mô tả các bằng chứng

AOT_COV.1.1C - Phân tích phạm vi thử nghiệm sẽ chứng minh sự phù hợp giữa việc thử nghiệm được xác định trong tài liệu hướng dẫn thử nghiệm và SSF có khả năng truy nhập thông qua các giao diện hệ thống hoạt động có sẵn theo mô tả trong đặc tả chức năng giao diện.

AOT_COV.1.2C - Phân tích phạm vi thử nghiệm sẽ chứng minh rằng tất cả các SSF có khả năng truy nhập thông qua các giao diện hệ thống hoạt động có sẵn theo mô tả trong đặc tả chức năng giao diện đã được thử nghiệm.

C.7.2.3.5 Hành động đánh giá

AOT_COV.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.7.2.4 Phân tích chính xác về phạm vi AOT_COV.2

Phân cấp theo: Bằng chứng của phạm vi AOT_COV.1

Phụ thuộc vào: - Đặc tả chức năng giao diện ASD_IFS.1

- Thử nghiệm chức năng AOT_FUN.1

C.7.2.4.1 Mục tiêu

Mục tiêu của thành phần này là thiết lập tất cả các thông số của tất cả các giao diện cho SSF đã được kiểm nghiệm qua thử nghiệm thấu đáo. Điều này đạt được thông qua việc kiểm tra phân tích về phạm vi thử nghiệm của AOT_FUN.

C.7.2.4.2 Các lưu ý áp dụng

Trong thành phần này, yêu cầu các nhà phát triển/tích hợp chứng minh rằng việc thử nghiệm đã xác nhận thử nghiệm tất cả các thông số cho tất cả các chức năng an toàn có sẵn theo mô tả trong đặc tả chức năng giao diện. Yêu cầu bổ sung này bao gồm cả việc thử nghiệm giới hạn (tức là xác minh rằng các lỗi được tạo ra khi vượt quá các giới hạn quy định) và Thử nghiệm phủ nhận (ví dụ như khi truy cập được gán cho người A, xác minh rằng người dùng B không đột nhiên truy cập). Đây là kiểu thử nghiệm không thấu đáo vì không phải tất cả các giá trị có thể có của các thông số hoặc mọi hành động người dùng dự kiến có thể được kiểm tra.

C.7.2.4.3 Hành động phát triển/tích hợp

AOT_COV.2.1D - Nhà phát triển/tích hợp phải cung cấp các phân tích về phạm vi thử nghiệm.

C.7.2.4.4 Nội dung và mô tả các bằng chứng

AOT_COV.2.1C - Phân tích phạm vi thử nghiệm sẽ chứng minh sự phù hợp giữa việc thử nghiệm được xác định trong tài liệu hướng dẫn thử nghiệm và SSF có khả năng truy nhập thông qua các giao diện hệ thống hoạt động có sẵn theo mô tả trong đặc tả chức năng giao diện.

AOT_COV.2.2C - Phân tích phạm vi thử nghiệm sẽ chứng minh rằng tất cả các SSF có khả năng truy nhập thông qua các giao diện hệ thống hoạt động có sẵn theo mô tả trong đặc tả chức năng giao diện đã được thử nghiệm đầy đủ.

C.7.2.4.5 Hành động đánh giá

AOT_COV.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.7.3 Thử nghiệm độ sâu hệ thống vận hành (AOT_DPT)

C.7.3.1 Mục tiêu

Các thành phần trong họ này phân chia mức chi tiết mà SSF được thử nghiệm bởi các nhà phát triển hoặc tích hợp dựa trên kiến thức về thiết kế hệ thống. Đặc điểm kỹ thuật dựa trên độ sâu của thông tin thu được từ phân tích của mô tả thiết kế bổ sung ngày càng tăng.

Mục tiêu là để đối phó với rủi ro mất lỗi trong việc phát triển và tích hợp của STOE.

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

Họ này có ba thành phần, các thành phần trong họ được phân mức trên cơ sở tăng chi tiết được cung cấp trong mô tả SSF, từ việc thiết kế phân hệ đến mô tả thực hiện. Phân mức này phản ánh mô tả SSF được trình bày trong lớp ASD.

C.7.3.3 Các lưu ý áp dụng

Số lượng cụ thể, loại tài liệu và bằng chứng nói chung sẽ được xác định bởi các thành phần được lựa chọn từ AOT_FUN. Lưu ý rằng thử nghiệm cơ bản ở mức đặc tả chức năng giao diện được trình bày bởi AOT_COV.

Nguyên tắc áp dụng trong họ này là mức thử nghiệm phù hợp với mức độ đảm bảo được yêu cầu. Trường hợp các thành phần cao hơn được áp dụng thì kết quả thử nghiệm cần phải chứng minh rằng việc thực hiện SSF là phù hợp với thiết kế của nó. Ví dụ, việc thiết kế phân hệ nên mô tả từng phân hệ và mô tả các giao diện giữa các phân hệ đầy đủ chi tiết với mục đích, hiệu quả và các lỗi của từng giao diện được xác định rõ ràng. Bằng chứng của sự thử nghiệm ở mức thiết kế phân hệ phải chỉ ra rằng các giao diện nội bộ giữa các phân hệ đã được thực hiện. Điều này có thể đạt được thông qua thử nghiệm qua các giao diện bên ngoài của SSF, hoặc bằng cách thử nghiệm các giao diện phân hệ độc lập, có thể sử dụng một công cụ khai thác thử nghiệm hoặc hệ thống thử nghiệm. Các thành phần cao hơn trong họ này nhằm mục đích kiểm tra các hoạt động chính xác của giao diện nội bộ có sẵn khi các thiết kế ít trừu tượng. Khi các thành phần này được áp dụng nó sẽ khó khăn hơn để cung cấp bằng chứng đầy đủ về độ sâu của thử nghiệm bằng cách sử dụng giao diện bên ngoài của SSF độc lập.

C.7.3.4 Thử nghiệm thiết kế phân hệ AOT_DPT.1

Phụ thuộc vào: - Thiết kế phân hệ ASD_STD.1

- Thử nghiệm chức năng AOT_FUN.1

C.7.3.4.1 Mục tiêu

Thiết kế phân hệ cung cấp một mô tả mức cao của các hoạt động nội bộ của SSF. Thử nghiệm ở mức các phân hệ cung cấp đảm bảo rằng các phân hệ SSF đã được thực hiện một cách chính xác.

C.7.3.4.2 Hành động phát triển/tích hợp

AOT_DPT.1.1D - Nhà phát triển/tích hợp sẽ cung cấp một phân tích về độ sâu của thử nghiệm.

C.7.3.4.3 Nội dung và mô tả các bằng chứng

AOT_DPT.1.1C - Việc phân tích độ sâu của thử nghiệm sẽ chứng minh sự phù hợp giữa thử nghiệm được xác định trong tài liệu hướng dẫn thử nghiệm và các phân hệ của STOE được xác định trong thiết kế phân hệ.

AOT_DPT.1.2C - Việc phân tích độ sâu của thử nghiệm sẽ chứng minh rằng tất cả các phân hệ của STOE được xác định trong thiết kế phân hệ đã được thử nghiệm.

C.7.3.4.4 Hành động đánh giá

AOT_DPT.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.7.3.5 Thử nghiệm thiết kế thành phần AOT_DPT.2

Phân cấp theo: - Thử nghiệm thiết kế phân hệ AOT_DPT.1

Phụ thuộc vào: - Thiết kế thành phần ASD_STD.2

- Thử nghiệm chức năng AOT_FUN.1

C.7.3.5.1 Mục tiêu

Việc thiết kế thành phần cung cấp một mô tả chi tiết về các hoạt động nội bộ của SSF. Thử nghiệm ở mức độ của các thành phần cung cấp đảm bảo rằng thiết kế chi tiết của tất cả các SSFs đã được thực hiện một cách chính xác.

C.7.3.5.2 Các lưu ý áp dụng

Tất cả các thành phần được xác định trong thiết kế thành phần thông thường sẽ có chức năng SSF- thực thi và do đó cần phải được thử nghiệm. Đối với các thành phần phần mềm, thiết kế thành phần thường ở một mức độ chi tiết hơn so với mô-đun mã riêng.

C.7.3.5.3 Hành động phát triển/tích hợp

AOT_DPT.2.1 D - Nhà phát triển/tích hợp sẽ cung cấp một phân tích về độ sâu của thử nghiệm.

C.7.3.5.4 Nội dung và mô tả các bằng chứng

AOT_DPT.2.1C - Việc phân tích độ sâu của thử nghiệm sẽ chứng minh sự phù hợp giữa thử nghiệm được xác định trong tài liệu hướng dẫn thử nghiệm và các phân hệ và các thành phần của STOE xác định trong thiết kế phân hệ và thành phần.

AOT_DPT.2.2C - Việc phân tích độ sâu của thử nghiệm sẽ chứng minh rằng tất cả các phân hệ của STOE được xác định trong thiết kế phân hệ đã được thử nghiệm.

AOT_DPT.2.3C - Việc phân tích độ sâu của thử nghiệm sẽ chứng minh rằng tất cả các thành phần của STOE được xác định trong thiết kế thành phần đã được thử nghiệm.

C.7.3.5.5 Hành động đánh giá

AOT_DPT.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.7.3.6 Thử nghiệm mô tả thực hiện AOT_DPT.3

Phân cấp theo: - Thử nghiệm thiết kế thành phần AOT_DPT.2

Phụ thuộc vào: - Mô tả thực hiện mở rộng thiết kế ASD_STD.3

- Thử nghiệm chức năng AOT_FUN.1

C.7.3.6.1 Mục tiêu

Mô tả thực hiện của một SSF xác định hành vi thực tế của nó. Thử nghiệm ở mức độ mô tả thực hiện cung cấp đảm bảo rằng SSF có liên quan đã được thực hiện một cách chính xác trong tất cả các cách khác nhau.

C.7.3.6.2 Các lưu ý áp dụng

Mô tả thực hiện được cung cấp hoặc thử nghiệm cho tất cả các thành phần của hệ thống hoạt động, chỉ có những người có cấu hình phần khác của hệ thống hoạt động hoặc thực hiện chức năng an toàn quan trọng để hỗ trợ các thành phần khác. Chương trình tích hợp hoặc các chương trình thông dụng được phát triển dành riêng cho hệ thống hoạt động có thể là mục tiêu của họ này.

C.7.3.6.3 Hành động phát triển/tích hợp

AOT_DPT.3.1 D - Nhà phát triển/tích hợp sẽ cung cấp một phân tích về độ sâu của thử nghiệm.

C.7.3.6.4 Nội dung và mô tả các bằng chứng

AOT_DPT.3.1C - Việc phân tích độ sâu của thử nghiệm sẽ chứng minh sự phù hợp giữa thử nghiệm được xác định trong tài liệu hướng dẫn thử nghiệm và các phân hệ và các thành phần của STOE xác định trong thiết kế phân hệ và thành phần.

AOT_DPT.3.2C - Việc phân tích độ sâu của thử nghiệm sẽ chứng minh rằng tất cả các phân hệ của STOE được xác định trong thiết kế phân hệ đã được thử nghiệm.

AOT_DPT.3.3C - Việc phân tích độ sâu của thử nghiệm sẽ chứng minh rằng tất cả các thành phần của STOE được xác định trong thiết kế thành phần đã được thử nghiệm.

AOT_DPT.3.4C - Việc phân tích độ sâu của thử nghiệm sẽ chứng minh rằng mà mô tả thực hiện được cung cấp hoạt động tuân theo mô tả đó.

C.7.3.6.5 Hành động đánh giá

AOT_DPT.3.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.7.4 Thử nghiệm chức năng hệ thống vận hành (AOT_FUN)

C.7.4.1 Mục tiêu

Mục tiêu của thành phần này là để các nhà phát triển/tích hợp chứng minh rằng tất cả các chức năng an toàn thực hiện theo quy định. Yêu cầu các nhà phát triển thực hiện thử nghiệm và cung cấp tài liệu hướng dẫn thử nghiệm.

Thử nghiệm chức năng được thực hiện bởi các nhà phát triển và/hoặc nhà tích hợp xác định rằng SSF có những thuộc tính cần thiết để đáp ứng các yêu cầu chức năng của PP/ST. Thử nghiệm chức năng này cung cấp đảm bảo rằng SSF đáp ứng ít nhất các yêu cầu chức năng an toàn, mặc dù SSF có thể không thiết lập nhiều hơn so với quy định. Họ "thử nghiệm chức năng" tập trung vào các loại, số lượng tài liệu hoặc công cụ hỗ trợ cần thiết và được chứng minh thông qua thử nghiệm phát triển. Thử nghiệm chức năng không giới hạn xác nhận tích cực các chức năng an toàn yêu cầu được cung cấp, nhưng cũng có thể bao gồm cả thử nghiệm tiêu cực để kiểm tra sự vắng mặt của hành vi không mong muốn cụ thể (thường dựa trên các yêu cầu chức năng đảo ngược).

Họ này góp phần cung cấp đảm bảo rằng khả năng xảy ra sai sót chưa được khám phá là tương đối thấp.

Các họ AOT_COV, AOT_DPT và AOT_FUN được sử dụng kết hợp để xác định các bằng chứng thử nghiệm được cung cấp bởi nhà phát triển và/hoặc nhà tích hợp. thử nghiệm chức năng độc lập bởi người đánh giá được quy định bởi AOT_IND.

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

Họ này có một thành phần.

C.7.4.3 Các lưu ý áp dụng

Thủ tục thực hiện thử nghiệm dự kiến sẽ cung cấp hướng dẫn sử dụng chương trình thử nghiệm và phòng thử nghiệm, bao gồm cả môi trường, điều kiện, các thông số dữ liệu thử nghiệm và các giá trị. Các thủ tục thử nghiệm cũng sẽ hiển thị các kết quả thử nghiệm bắt nguồn từ đầu vào thử nghiệm.

Các yêu cầu cụ thể của họ này là để mô tả của tất cả các kế hoạch thử nghiệm, thủ tục và các kết quả. Do đó, số lượng thông tin phải được trình bày sẽ thay đổi phù hợp với việc sử dụng các AOT_COV và AOT_DPT.

Thứ tự phụ thuộc có liên quan khi thực hiện thành công một thử nghiệm cụ thể phụ thuộc vào sự tồn tại của một trạng thái cụ thể. Ví dụ, yêu cầu thử nghiệm A thực hiện ngay lập tức trước khi thử nghiệm B thực hiện, khi trạng thái thu được kết quả từ việc thực hiện thành công thử nghiệm A là một điều kiện tiên quyết để thực hiện thành công thử nghiệm B. Như vậy, sự thất bại của thử nghiệm B có thể liên quan đến vấn đề thứ tự phụ thuộc. Trong ví dụ trên, thử nghiệm B có thể thất bại vì thử nghiệm C (chứ không phải là thử nghiệm A) được thực hiện ngay lập tức trước khi thử nghiệm B thực hiện, hoặc sự thất bại của thử nghiệm B có thể liên quan đến một sự thất bại của thử nghiệm A. Một phân tích về sự phụ thuộc giữa các thử nghiệm chức năng là rất cần thiết trong các hệ thống hoạt động vì người dùng không thể được giả định để thực hiện các hành động trong thứ tự cụ thể bất kỳ.

C.7.4.4 Thử nghiệm chức năng AOT_FUN.1

Phụ thuộc: Không phụ thuộc.

C.7.4.4.1 Hành động phát triển/tích hợp

AOT_FUN.1.1D - Nhà phát triển/tích hợp sẽ tiến hành thử nghiệm SSF và dẫn chứng kết quả.

AOT_FUN.1.2D - Nhà phát triển/tích hợp sẽ cung cấp tài liệu hướng dẫn thử nghiệm.

C.7.4.4.2 Nội dung và mô tả các bằng chứng

AOT_FUN.1.1C - Tài liệu hướng dẫn thử nghiệm phải bao gồm kế hoạch thử nghiệm, các kết quả thử nghiệm dự kiến và các kết quả thử nghiệm thực tế.

AOT_FUN.1.2C - Các kế hoạch thử nghiệm phải xác định các thử nghiệm sẽ được thực hiện và mô tả các kịch bản để thực hiện từng thử nghiệm. Các kịch bản này sẽ bao gồm thứ tự phụ thuộc bất kỳ lên các kết quả của các thử nghiệm khác.

AOT_FUN.1.3C - Các kết quả thử nghiệm dự kiến sẽ trình bày các kết quả đầu ra mong đợi từ việc thực hiện thành công của các thử nghiệm.

AOT_FUN.1.4C - Kết quả thử nghiệm thực tế phải phù hợp với kết quả thử nghiệm dự kiến.

AOT_FUN.1.5C - Tài liệu thử nghiệm sẽ bao gồm một phân tích của sự phụ thuộc thứ tự thủ tục thử nghiệm bất kỳ.

C.7.4.4.3 Hành động đánh giá

AOT_FUN.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.7.5 Thử nghiệm độc lập hệ thống vận hành (AOT_IND)

C.7.5.1 Mục tiêu

Mục tiêu của họ này là để cung cấp bằng chứng độc lập các chức năng an toàn thực hiện như quy định.

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

Họ này có ba thành phần, phân mức thành phần dựa trên việc có hay không các truy nhập vào các tài liệu hướng dẫn thử nghiệm của nhà phát triển/tích hợp và tính toàn diện của thử nghiệm.

C.7.5.3 Các lưu ý áp dụng

Việc thử nghiệm được xác định trong họ này có thể được hỗ trợ bởi một bên với kiến thức chuyên môn khác so với người đánh giá (ví dụ như một phòng thí nghiệm độc lập, một tổ chức người tiêu dùng mục tiêu). Thử nghiệm đòi hỏi sự hiểu biết về STOE phù hợp với việc thực hiện các hoạt động đảm bảo khác và người đánh giá vẫn giữ trách nhiệm đảm bảo rằng các yêu cầu của họ này được giải quyết thỏa đáng khi sự hỗ trợ đó được sử dụng.

Chức năng thử nghiệm độc lập có thể mang hình thức lặp đi lặp lại thử nghiệm chức năng của nhà phát triển trong toàn bộ hoặc một phần. Nó cũng có thể mang hình thức thử nghiệm chức năng đưa ra bởi người đánh giá, hoặc là để mở rộng phạm vi hoặc độ sâu của các bài thử nghiệm của nhà phát triển, hoặc do kết quả phát triển không có sẵn. Những hoạt động này được bổ sung, và một sự pha trộn thích hợp phải được quy hoạch cho từng STOE, có tính đến sự sẵn có và phạm vi của các kết quả thử nghiệm và sự phức tạp chức năng của SSF.

Lấy mẫu thử nghiệm của phát triển nhằm cung cấp xác nhận rằng các nhà phát triển đã thực hiện chương trình thử nghiệm của mình trên SSF và đã ghi nhận chính xác kết quả. Kích thước của mẫu được chọn sẽ bị ảnh hưởng bởi chi tiết và chất lượng của kết quả thử nghiệm chức năng của nhà phát triển. Người đánh giá cũng cần phải xem xét phạm vi của việc xây dựng các bài kiểm tra bổ sung và lợi ích liên quan có thể được thu được từ nỗ lực trong hai lĩnh vực này. Phải thừa nhận rằng sự lặp lại của tất cả các thử nghiệm của nhà phát triển có thể khả thi và mong muốn trong một số trường hợp, nhưng có thể rất khó khăn và kém hiệu quả ở những người khác. Các thành phần cao nhất trong họ này nên được sử dụng một cách thận trọng. Lấy mẫu sẽ giải quyết toàn bộ các kết quả thử nghiệm có sẵn, bao gồm cả những người cung cấp để đáp ứng các yêu cầu của cả AOT_COV và AOT_DPT.

Ngoài ra cũng cần phải xem xét các cấu hình khác nhau của STOE được bao gồm trong đánh giá. Người đánh giá cần phải đánh giá khả năng áp dụng các kết quả được cung cấp và lên kế hoạch thử nghiệm của mình cho phù hợp.

Thử nghiệm chức năng độc lập khác biệt với thử nghiệm thâm nhập, Thử nghiệm thâm nhập được xác định bằng cách sử dụng AOV_VAN gia đình.

Sự phù hợp của STOE để thử nghiệm dựa trên cơ sở truy nhập vào STOE, các tài liệu hỗ trợ và thông tin cần thiết (bao gồm phần mềm hoặc các công cụ thử nghiệm bất kỳ) để thử nghiệm. Sự cần thiết phải hỗ trợ này được giải quyết bằng các phụ thuộc cho các họ bảo đảm khác.

Ngoài ra, sự phù hợp của các STOE để thử nghiệm có thể dựa trên những cân nhắc khác. Ví dụ, các phiên bản của STOE được thử nghiệm bởi các nhà phát triển có thể không phải là phiên bản cuối cùng.

Tài liệu tham chiếu cho một tập con của SSF được dự định để cho phép người đánh giá thiết kế một bộ các bài thử nghiệm là phù hợp với các mục tiêu của việc đánh giá được tiến hành.

C.7.5.4 Thử nghiệm độc lập sự tương ứng AOT_IND.1

Phụ thuộc vào: - Đặc tả chức năng giao diện ASD_IFS.1

- Hướng dẫn sử dụng AOD_OGD.1

C.7.5.4.1 Mục tiêu

Trong thành phần này, mục tiêu là để chứng minh rằng SSF hoạt động phù hợp với các đặc tả giao diện và tài liệu hướng dẫn sử dụng cho STOE, mà không cần truy nhập vào kết quả thử nghiệm của nhà phát triển.

C.7.5.4.2 Các lưu ý áp dụng

Thành phần này không đề cập đến việc sử dụng các kết quả thử nghiệm của nhà phát triển. Nó được áp dụng mà kết quả như vậy là không có, và cũng trong trường hợp thử nghiệm của nhà phát triển được chấp nhận mà không có xác nhận. Người đánh giá là cần thiết để xây dựng và thực hiện các bài thử nghiệm với mục tiêu khẳng định rằng STOE hoạt động phù hợp với đặc tả giao diện của nó và các tài liệu hướng dẫn sử dụng. Cách tiếp cận này là để đạt được sự tự tin trong hoạt động chính xác thông qua thử nghiệm mô tả, chứ không phải để thực hiện tất cả các bài thử nghiệm có thể. Mức độ thử nghiệm được quy hoạch cho mục đích này là vấn đề phương pháp luận, và cần phải được xem xét trong bối cảnh của một STOE riêng và cân bằng các hoạt động đánh giá khác.

C.7.5.4.3 Hành động phát triển/tích hợp

AOT_IND.1.1.D - Nhà phát triển/tích hợp sẽ cung cấp STOE và môi trường thử nghiệm để thử nghiệm

C.7.5.4.4 Nội dung và mô tả các bằng chứng

AOT_IND.1.1C - Nhà phát triển/tích hợp sẽ cung cấp STOE và môi trường thử nghiệm để thử nghiệm.

AOT_IND.1.1C - Các tài liệu hướng dẫn STOE và người sử dụng sẽ cho phép người đánh giá chuẩn bị và thực hiện các thử nghiệm.

C.7.5.4.5 Hành động đánh giá

AOT_IND.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

AOT_IND.1.2E - Người đánh giá sẽ thử nghiệm một tập hợp các giao diện STOE để xác nhận rằng SSF hoạt động theo quy định.

C.7.5.5 Thử nghiệm độc lập - Mẫu AOT_IND.2

Phân cấp theo: - Thử nghiệm độc lập - Tương ứng AOT_IND.1

Phụ thuộc vào: - Đặc tả chức năng giao diện ASD_IFS.1

- Hướng dẫn sử dụng AOD_OGD.1

- Thử nghiệm chức năng AOT_FUN.1

C.7.5.5.1 Mục tiêu

Trong thành phần này, mục tiêu là để chứng minh rằng SSF hoạt động phù hợp với các đặc tả giao diện và tài liệu hướng dẫn sử dụng cho STOE. Thử nghiệm đánh giá xác nhận các kết quả thử nghiệm của nhà phát triển/tích hợp bằng cách lặp lại một mẫu thử nghiệm của nhà phát triển và cũng có thể thực hiện một số thử nghiệm bổ sung.

C.7.5.5.2 Các lưu ý áp dụng

Mục đích là nhà phát triển cần cung cấp các đánh giá với các vật liệu cần thiết cho việc tái sản xuất hiệu quả của các thử nghiệm của nhà phát triển. Điều này có thể bao gồm những thứ như tài liệu hướng dẫn thử nghiệm máy tính có thể đọc được, các chương trình thử nghiệm, vv

Thành phần này có chứa một yêu cầu mà người đánh giá có kết quả thử nghiệm có sẵn từ các nhà phát triển để bổ sung vào chương trình thử nghiệm. Người đánh giá sẽ lặp lại một mẫu thử nghiệm của nhà phát triển để đạt được sự tự tin trong các kết quả thu được. Sau khi đã thiết lập sự tự tin người đánh giá sẽ xây dựng dựa trên thử nghiệm của nhà phát triển bằng cách thực hiện các bài thử nghiệm bổ sung thực hiện STOE một cách khác nhau. Bằng cách sử dụng một nền tảng kết quả thử nghiệm của nhà phát triển, người đánh giá có thể đạt được sự tin tưởng rằng STOE hoạt động chính xác trong một phạm vi điều kiện rộng lớn hơn sẽ có thể hoàn toàn sử dụng những nỗ lực riêng của nhà phát triển, đưa ra một mức cố định của tài nguyên. Tin rằng các nhà phát triển đã thử nghiệm STOE, người đánh giá cũng sẽ có nhiều lựa chọn hơn để tập trung kiểm tra tại các khu vực kiểm tra tài liệu hoặc kiến thức chuyên môn đã bày tỏ quan ngại đặc biệt.

C.7.5.5.3 Hành động phát triển/tích hợp

AOT_IND.2.1 D - Nhà phát triển/tích hợp sẽ cung cấp STOE và môi trường thử nghiệm để thử nghiệm.

C.7.5.5.4 Nội dung và mô tả các bằng chứng

AOT_IND.2.1C - Các tài liệu hướng dẫn STOE và người sử dụng sẽ cho phép người đánh giá chuẩn bị và thực hiện các thử nghiệm.

AOT_IND.2.2C - Nhà phát triển/tích hợp sẽ cung cấp một bộ tài nguyên tương đương cho những người đã được sử dụng trong thử nghiệm chức năng của nhà phát triển của SSF.

C.7.5.5.5 Hành động đánh giá

AOT_IND.2.1 E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

AOT_IND.2.2E - Người đánh giá sẽ thực hiện một mẫu thử nghiệm trong tài liệu hướng dẫn thử nghiệm để xác minh kết quả thử nghiệm của nhà phát triển.

AOT_IND.2.3E - Người đánh giá sẽ thử nghiệm một tập hợp các giao diện STOE để xác nhận rằng SSF hoạt động theo quy định.

C.7.5.6 Thử nghiệm độc lập - đầy đủ AOT_IND.3

Phân cấp theo: - Thử nghiệm độc lập - Mẫu AOT_IND.2

Phụ thuộc vào: - Đặc tả chức năng giao diện ASD_IFS.1

- Hướng dẫn người sử dụng AOD_OGD.1

- Thử nghiệm chức năng AOT_FUN.1

C.7.5.6.1 Mục tiêu

Trong thành phần này, mục tiêu là để chứng minh rằng SSF hoạt động phù hợp với các đặc tả giao diện và tài liệu hướng dẫn người sử dụng cho STOE. Thử nghiệm của người đánh giá xác nhận các kết quả của thử nghiệm của nhà phát triển/tích hợp bằng cách lặp lại tất cả các bài thử nghiệm của nhà phát triển và cũng thực hiện thử nghiệm bổ sung toàn bộ STOE.

C.7.5.6.2 Các lưu ý áp dụng

Mục đích là nhà phát triển nên cung cấp cho người đánh giá các vật liệu cần thiết cho việc tái thực hiện hiệu quả của các thử nghiệm của nhà phát triển/tích hợp. Điều này có thể bao gồm những thứ như tài liệu hướng dẫn kiểm tra máy tính có thể đọc được, các chương trình thử nghiệm, vv

Trọng phần này người đánh giá phải lặp lại tất cả các bài thử nghiệm của nhà phát triển như là một phần của chương trình thử nghiệm. Như trong thành phần trước người đánh giá cũng sẽ tiến hành thử nghiệm nhằm mục đích STOE để thực hiện một cách khác nhau từ đó đạt được bởi các nhà phát triển. Trong trường hợp thử nghiệm đã được phát triển đầy đủ, có thể vẫn còn ít cơ hội cho việc này.

C.7.5.6.3 Hành động phát triển/tích hợp

AOT_IND.3.1 D - Nhà phát triển/tích hợp sẽ cung cấp STOE và môi trường thử nghiệm để thử nghiệm

C.7.5.6.4 Nội dung và mô tả các bằng chứng

AOT_IND.3.1C - Các tài liệu hướng dẫn STOE và người sử dụng sẽ cho phép người đánh giá chuẩn bị và thực hiện các thử nghiệm.

AOT_IND.3.2C - Nhà phát triển/tích hợp sẽ cung cấp một bộ tài nguyên tương đương cho những người đã được sử dụng trong thử nghiệm chức năng của nhà phát triển của SSF.

C.7.5.6.5 Hành động đánh giá

AOT_IND.3.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

AOT_IND.3.2E - Người đánh giá sẽ thực hiện tất cả các thử nghiệm trong tài liệu hướng dẫn thử nghiệm để xác minh kết quả thử nghiệm của nhà phát triển.

AOT_IND.3.3E - Người đánh giá sẽ thử nghiệm tất cả các giao diện STOE để xác nhận rằng toàn bộ SSF hoạt động theo quy định.

C.7.6 Thử nghiệm hồi quy hệ thống vận hành (AOT_REG)

C.7.6.1 Mục tiêu

Mục tiêu của thành phần này là để chứng minh rằng các chức năng an toàn thực hiện theo quy định sau khi thay đổi hoặc hiệu chỉnh các thành phần hệ thống, cấu hình hệ thống hoặc môi trường vận hành.

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

Họ này có một thành phần.

C.7.6.3 Thử nghiệm hồi quy AOT_REG.1

Phụ thuộc: Không phụ thuộc.

C.7.6.3.1 Mục tiêu

Trong thành phần này, mục tiêu là để chứng minh rằng các chức năng an toàn thực hiện theo quy định sau khi thay đổi hoặc hiệu chỉnh các thành phần hệ thống, cấu hình hệ thống hoặc môi trường vận hành.

C.7.6.3.2 Các lưu ý áp dụng

Thành phần này không chỉ giải quyết các thử nghiệm của các thay đổi hoặc các phần hiệu chỉnh của hệ thống hoạt động mà còn các bộ phận khác.

C.7.6.3.3 Hành động phát triển/tích hợp

AOT_REG.1.1D - Nhà phát triển/tích hợp sẽ tiến hành thử nghiệm SSF thực hiện bởi vùng thay đổi hoặc hiệu chỉnh của STOE và cung cấp kết quả.

AOT_REG.1.2D - Nhà phát triển/tích hợp sẽ một phân tích thử nghiệm hồi quy

AOT_REG.1.3D - Nhà phát triển/tích hợp sẽ cấp tài liệu hướng dẫn thử nghiệm hồi quy.

C.7.6.3.4 Nội dung và mô tả các bằng chứng

AOT_REG.1.1C - Phân tích thử nghiệm hồi quy phải xác định những SSF được thực hiện bởi vùng thay đổi hoặc hiệu chỉnh của STOE và những thay đổi dự định hay nói cách khác là các hành vi của những SSF.

AOT_REG.1.2C - Các tài liệu thử nghiệm hồi quy sẽ bao gồm những SSF được thực hiện bởi vùng thay đổi hoặc hiệu chỉnh của STOE

AOT_REG.1.3C - Các tài liệu thử nghiệm hồi quy sẽ bao gồm kế hoạch thử nghiệm, kết quả thử nghiệm dự kiến và kết quả thử nghiệm thực tế.

AOT_REG.1.4C - Các kế hoạch thử nghiệm phải xác định các bài thử nghiệm sẽ được thực hiện và mô tả các kịch bản cho mỗi bài thử nghiệm. Các kịch bản này sẽ bao gồm các thứ tự phụ thuộc bất kỳ lên các kết quả của các thử nghiệm khác.

AOT_REG.1.5C - Kết quả thử nghiệm dự kiến sẽ hiển thị các kết quả đầu ra mong đợi từ việc thực hiện thành công các bài thử nghiệm.

AOT_REG.1.6C - Kết quả thử nghiệm thực tế phải phù hợp với kết quả thử nghiệm dự kiến.

AOT_REG.1.7C - Kết quả thử nghiệm thực tế phải chứng minh rằng hành vi của từng SSF được thử nghiệm đúng với quy định trong phân tích thử nghiệm hồi quy.

AOT_REG.1.8C - Các tài liệu thử nghiệm sẽ bao gồm một phân tích của sự phụ thuộc thứ tự thủ tục thử nghiệm bất kỳ.

C.7.6.3.5 Hành động đánh giá

AOT_REG.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.8 Lớp AOV: Đánh giá điểm yếu hệ thống vận hành

C.8.1 Giới thiệu

Mục đích của việc đánh giá điểm yếu là để xác định xem các điểm yếu tiềm ẩn trong STOE đại diện cho các điểm yếu thực tế mà có thể bị khai thác bởi kẻ tấn công. Việc xác định này dựa trên các phân tích của người đánh giá bằng cách kiểm tra các điểm yếu phổ biến được tìm thấy trong các hệ thống tương tự và ở mức độ cao hơn, sẽ điều tra nghiên cứu các điểm yếu tiềm ẩn được xác định trong nhiệm vụ đánh giá khác.

Đánh giá điểm yếu cần xem xét cả khía cạnh kiểm soát kỹ thuật và vận hành. Tuy nhiên, bất kỳ thử nghiệm nào để xác định xem các điểm yếu tiềm ẩn có thể khai thác trong thực tế được thực hiện trong một môi trường phát triển. Do đó, có thể là điểm yếu thực tế bổ sung sẽ tồn tại vì các kiểm soát vận hành trong môi trường vận hành khác nhau để thực hiện hành vi quan sát chúng trong môi trường thử nghiệm. Đánh giá điểm yếu do đó thường phải được bổ sung bằng cách kiểm tra và xác minh các hồ sơ và kiểm soát trong quá trình vận hành hoạt động của hệ thống.

Lớp này thực hiện chức năng đánh giá duy nhất và do đó có một họ của các thành phần đảm bảo.

C.8.2 Phân tích các điểm yếu (AOV_VAN)

C.8.2.1 Mục tiêu

Mục tiêu của phân tích điểm yếu là để xác định xem các điểm yếu tiềm ẩn được xác định trong quá trình đánh giá việc xây dựng và hoạt động mong muốn của STOE thực sự có thể cho phép kẻ tấn công xâm nhập SFRs.

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

Họ này có bảy thành phần, các thành phần trong họ này được phân mức ban đầu theo hình thức phân tích dự kiến điểm yếu tiềm ẩn và sau đó ở mức độ cao hơn là mức xem xét giả lập một cuộc tấn công thực sự.

C.8.2.3 Tổng quan điểm yếu kiến trúc AOV_VAN.1

Phụ thuộc vào: - Mô tả kiến trúc ASD_SAD.1

- Hướng dẫn người sử dụng AOD_OGD.1

C.8.2.3.1 Mục tiêu

Một thống kê điểm yếu của các thông tin có sẵn trong một miền công cộng được thực hiện bởi người đánh giá để xác định các điểm yếu tiềm ẩn có thể dễ dàng tìm thấy bởi một kẻ tấn công.

Người đánh giá sau đó thực hiện thử nghiệm thâm nhập, để xác nhận rằng điểm yếu tiềm ẩn không thể được khai thác trong môi trường hoạt động được đề xuất cho STOE. Thâm nhập thử nghiệm được thực hiện bởi người đánh giá giả định một cuộc tấn công tiềm năng cơ bản.

C.8.2.3.2 Các lưu ý áp dụng

Thành phần này không đòi hỏi tài liệu an toàn có sẵn khi lập kế hoạch thử nghiệm thâm nhập. Do đó, nó là thích hợp nhất cho các miền mà ở đó STOE không có chức năng an toàn, là một cách để đảm bảo rằng các miền này không thể được sử dụng để gây ảnh hưởng cho (phá vỡ) các miền khác.

C.8.2.3.3 Hành động phát triển/tích hợp

AOV_VAN.1.1D - Nhà phát triển/tích hợp sẽ cung cấp STOE và môi trường thử nghiệm để thử nghiệm.

C.8.2.3.4 Nội dung và mô tả các bằng chứng

AOV_VAN.1.1C - Các tài liệu hướng dẫn STOE và người sử dụng sẽ cho phép người đánh giá chuẩn bị và thực hiện các thử nghiệm.

C.8.2.3.5 Hành động đánh giá

AOV_VAN.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

AOV_VAN.1.2E - Người đánh giá sẽ thực hiện nghiên cứu tài nguyên miền công cộng để xác định các điểm yếu tiềm ẩn trong STOE dựa trên mô tả kiến trúc.

AOV_VAN.1.3E - Người đánh giá sẽ tiến hành thử nghiệm thâm nhập dựa trên cơ sở các điểm yếu tiềm ẩn xác định, để xác định rằng STOE có khả năng chống các cuộc tấn công được thực hiện bởi một kẻ tấn công có khả năng tấn công cơ bản.

C.8.2.4 Tổng quan các điểm yếu nâng cao AOV_VAN.2

Phân cấp theo: - Khảo sát điểm yếu kiến trúc AOV_VAN.1

Phụ thuộc vào: - Mô tả kiến trúc ASD_SAD.1

- Khái niệm an toàn của hoạt động ASD_CON.1

- Hướng dẫn người sử dụng AOD_OGD.1

C.8.2.4.1 Mục tiêu

Khảo sát điểm yếu của các thông tin có sẵn trong miền công cộng được thực hiện bởi người đánh giá để xác định các điểm yếu tiềm ẩn có thể dễ dàng tìm thấy bởi một kẻ tấn công. Khảo sát có tính đến các thuộc tính an toàn dự định của STOE hoặc miền STOE.

Người đánh giá sau đó thực hiện thử nghiệm thâm nhập, để xác nhận rằng điểm yếu tiềm ẩn không thể được khai thác trong môi trường hoạt động đề xuất cho STOE. Thâm nhập thử nghiệm được thực hiện bởi người đánh giá giả định một cuộc tấn công tiềm năng cơ bản.

C.8.2.4.2 Các lưu ý áp dụng

Thành phần này yêu cầu tài liệu hướng dẫn khái niệm an toàn của hoạt động có sẵn khi xác định các điểm yếu tiềm ẩn. Thâm nhập thử nghiệm do đó có thể được nhắm mục đích vào các thuộc tính an toàn dự định của STOE hoặc miền STOE mà nó được áp dụng.

C.8.2.4.3 Hành động phát triển/tích hợp

AOV_VAN.2.1D - Nhà phát triển/tích hợp sẽ cung cấp STOE và môi trường thử nghiệm để thử nghiệm.

C.8.2.4.4 Nội dung và mô tả các bằng chứng

AOV_VAN.2.1C - Các tài liệu STOE và hướng dẫn người sử dụng sẽ cho phép người đánh giá chuẩn bị và thực hiện các thử nghiệm.

C.8.2.4.5 Hành động đánh giá

AOV_VAN.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

AOV_VAN.2.2E - Người đánh giá sẽ thực hiện nghiên cứu tài nguyên miền công cộng để xác định các điểm yếu tiềm ẩn trong STOE dựa trên tài liệu mô tả kiến trúc và khái niệm an toàn của vận hành.

AOV_VAN.2.3E - Người đánh giá sẽ tiến hành thử nghiệm thâm nhập dựa trên cơ sở các điểm yếu tiềm ẩn xác định, để xác định rằng STOE có khả năng chống các cuộc tấn công được thực hiện bởi một kẻ tấn công có khả năng tấn công cơ bản.

C.8.2.5 Phân tích các điểm yếu giao diện AOV_VAN.

Phân cấp theo: - Khảo sát điểm yếu Enhanced AOV_VAN.2

Phụ thuộc vào: - Mô tả kiến trúc ASD_SAD.1;

- Khái niệm an toàn của hoạt động ASD_CON.1;

- Đặc tả chức năng giao diện ASD_IFS.1;

- Hướng dẫn người sử dụng AOD_OGD.1

C.8.2.5.1 Mục tiêu

Cũng như một thống kê điểm yếu của thông tin có sẵn trong miền công cộng, người đánh giá thực hiện một phân tích điểm yếu của các giao diện trong STOE để xác định các điểm yếu tiềm ẩn.

C.8.2.5.2 Các lưu ý áp dụng

Thành phần này yêu cầu một tài liệu khái niệm an toàn của hoạt động và đặc tả chức năng giao diện chức năng có sẵn, mà không yêu cầu bất kỳ về tài liệu thiết kế. Do đó, phân tích điểm yếu chỉ có thể xác định sự khác biệt về chức năng.

C.8.2.5.3 Hành động phát triển/tích hợp

AOV_VAN.3.1 D - Nhà phát triển/tích hợp sẽ cung cấp STOE và môi trường thử nghiệm để thử nghiệm.

C.8.2.5.4 Nội dung và mô tả các bằng chứng

AOV_VAN.3.1C - Các tài liệu STOE và hướng dẫn người sử dụng sẽ cho phép người đánh giá chuẩn bị và thực hiện các thử nghiệm.

C.8.2.5.5 Hành động đánh giá

AOV_VAN.3.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

AOV_VAN.3.2E - Người đánh giá sẽ thực hiện nghiên cứu tài nguyên miền công cộng để xác định các điểm yếu tiềm ẩn trong STOE dựa trên mô tả kiến trúc và tài liệu khái niệm an toàn của vận hành.

AOV_VAN.3.3E - Người đánh giá thực hiện một phân tích điểm yếu độc lập của STOE để xác định các điểm yếu tiềm ẩn trong STOE bằng cách sử dụng tài liệu mô tả kiến trúc, tài liệu khái niệm an toàn của vận hành, các đặc tả chức năng giao diện và hướng dẫn người sử dụng.

AOV_VAN.3.4E - Người đánh giá sẽ tiến hành thử nghiệm thâm nhập dựa trên cơ sở các điểm yếu tiềm ẩn xác định, để xác định rằng STOE có khả năng chống các cuộc tấn công được thực hiện bởi một kẻ tấn công có khả năng tấn công cơ bản.

C.8.2.6 Phân tích điểm yếu thiết kế AOV_VAN.4

Phân cấp theo: - Phân tích điểm yếu giao diện AOV_VAN.3

Phụ thuộc vào: - Mô tả kiến trúc ASD_SAD.1;

- Khái niệm an toàn của vận hành ASD_CON.1;

- Đặc tả chức năng giao diện ASD_IFS.1;

- Thiết kế phân hệ ASD_STD.1;

- Hướng dẫn người sử dụng AOD_OGD.1

C.8.2.6.1 Mục tiêu

Cũng như một thống điểm yếu của thông tin có sẵn trong miền công cộng, người đánh giá thực hiện một phân tích điểm yếu về đặc tả và thiết kế của STOE để xác định các điểm yếu tiềm ẩn.

C.8.2.6.2 Các lưu ý áp dụng

Phân tích điểm yếu của thiết kế STOE có thể được thực hiện mà ở đó chỉ có một thiết kế phân hệ có sẵn. Tuy nhiên, "tất cả các tài liệu thiết kế có sẵn" bao gồm thiết kế thành phần và mô tả thực hiện nếu các thành phần mức cao hơn của ASD_STD có trong SST.

C.8.2.6.3 Hành động phát triển/tích hợp

AOV_VAN.4.1D - Nhà phát triển/tích hợp sẽ cung cấp STOE và môi trường thử nghiệm để thử nghiệm.

C.8.2.6.4 Nội dung và mô tả các bằng chứng

AOV_VAN.4.1C - STOE và tài liệu hướng dẫn người sử dụng sẽ cho phép người đánh giá chuẩn bị và thực hiện các thử nghiệm.

C.8.2.6.5 Hành động đánh giá

AOV_VAN.4.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

AOV_VAN.4.2E - Người đánh giá sẽ thực hiện nghiên cứu tài nguyên miền công cộng để xác định các điểm yếu tiềm ẩn trong STOE dựa trên mô tả kiến trúc và tài liệu khái niệm an toàn của hoạt động.

AOV_VAN.4.3E - Người đánh giá thực hiện một phân tích điểm yếu độc lập của STOE để xác định các điểm yếu tiềm ẩn trong STOE bằng cách sử dụng mô tả kiến trúc, tài liệu khái niệm an toàn của hoạt động, các đặc tả chức năng giao diện, tất cả các tài liệu thiết kế có sẵn và tài liệu hướng dẫn người sử dụng.

AOV_VAN.4.4E - Người đánh giá sẽ tiến hành thử nghiệm thâm nhập dựa trên cơ sở các điểm yếu tiềm ẩn xác định, để xác định rằng STOE có khả năng chống các cuộc tấn công được thực hiện bởi một kẻ tấn công có khả năng tấn công cơ bản.

C.8.2.7 Phân tích các điểm yếu trọng tâm AOV_VAN.5

Phân cấp theo: - Phân tích điểm yếu thiết kế AOV_VAN.4

Phụ thuộc vào: - Mô tả kiến trúc ASD_SAD.1 ;

- Khái niệm an toàn của hoạt động ASD_CON.1;

- Đặc tả chức năng giao diện ASD_IFS.1;

- Thiết kế phân hệ ASD_STD.1;

- Hướng dẫn người sử dụng AOD_OGD.1

C.8.2.7.1 Mục tiêu

Cũng như một thống kê điểm yếu của thông tin có sẵn trong miền công cộng, người đánh giá thực hiện một phân tích điểm yếu trọng tâm về các đặc tả và thiết kế của STOE để xác định các điểm yếu tiềm ẩn.

Người đánh giá sau đó thực hiện thử nghiệm thâm nhập, để xác nhận rằng điểm yếu tiềm ẩn không thể được khai thác trong môi trường vận hành đề xuất cho STOE. Thâm nhập thử nghiệm được thực hiện bởi người đánh giá giả định một cuộc tấn công tiềm năng được cơ bản nâng cao.

C.8.2.7.2 Các lưu ý áp dụng

C.8.2.7.3 Hành động phát triển/tích hợp

AOV_VAN.5.1 D - Nhà phát triển/tích hợp sẽ cung cấp STOE và môi trường thử nghiệm để thử nghiệm.

C.8.2.7.4 Nội dung và mô tả các bằng chứng

AOV_VAN.5.1C - STOE và tài liệu hướng dẫn người sử dụng sẽ cho phép người đánh giá chuẩn bị và thực hiện các thử nghiệm.

C.8.2.7.5 Hành động đánh giá

AOV_VAN.5.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

AOV_VAN.5.2E - Người đánh giá sẽ thực hiện nghiên cứu tài nguyên miền công cộng để xác định các điểm yếu tiềm ẩn trong STOE dựa trên mô tả kiến trúc và tài liệu khái niệm an toàn của vận hành.

AOV_VAN.5.3E - Người đánh giá thực hiện phân tích điểm yếu tập trọng tâm độc lập của STOE để xác định các điểm yếu tiềm ẩn trong STOE bằng cách sử dụng tài liệu mô tả kiến trúc, khái niệm an toàn của vận hành, các đặc tả chức năng giao diện, tất cả các tài liệu thiết kế có sẵn và tài liệu hướng dẫn người sử dụng.

AOV_VAN.5.4E - Người đánh giá sẽ tiến hành thử nghiệm thâm nhập dựa trên cơ sở các điểm yếu tiềm ẩn xác định để xác định rằng STOE có khả năng chống lại các cuộc tấn công được thực hiện bởi một kẻ tấn công có khả năng tấn công cơ bản nâng cao.

C.8.2.8 Phương pháp phân tích điểm yếu có hệ thống AOV_VAN.6

Phân cấp theo: - Phân tích điểm yếu trọng tâm AOV_VAN.5

Phụ thuộc vào: - Mô tả kiến trúc ASD_SAD.1;

- Khái niệm an toàn của các vận hành ASD_CON.1 ;

- Đặc tả chức năng giao diện ASD_IFS.1 ;

- Thiết kế phân hệ ASD_STD.1;

- Hướng dẫn người sử dụng AOD_OGD.1

C.8.2.8.1 Mục tiêu

Cũng như một thống kê điểm yếu của thông tin có sẵn trong miền công cộng, người đánh giá thực hiện một phân tích điểm yếu về đặc tả và thiết kế của STOE để xác định các điểm yếu tiềm ẩn.

C.8.2.8.2 Các lưu ý áp dụng

C.8.2.8.3 Hành động phát triển/tích hợp

AOV_VAN.6.1D - Nhà phát triển/tích hợp sẽ cung cấp STOE và môi trường thử nghiệm để thử nghiệm.

C.8.2.8.4 Nội dung và mô tả các bằng chứng

AOV_VAN.6.1C - STOE và tài liệu hướng dẫn người sử dụng sẽ cho phép người đánh giá chuẩn bị và thực hiện các thử nghiệm.

C.8.2.8.5 Hành động đánh giá

AOV_VAN.6.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

AOV_VAN.6.2E - Người đánh giá sẽ thực hiện nghiên cứu tài nguyên miền công cộng để xác định các điểm yếu tiềm ẩn trong STOE dựa trên mô tả kiến trúc và tài liệu khái niệm an toàn của vận hành.

AOV_VAN.6.3E - Người đánh giá sẽ thực hiện độc lập phân tích điểm yếu có hệ thống của STOE để xác định các điểm yếu tiềm ẩn trong STOE bằng cách sử dụng tài liệu mô tả kiến trúc, khái niệm an toàn của vận hành, các đặc tả chức năng giao diện, tất cả các tài liệu thiết kế có sẵn và tài liệu hướng dẫn người sử dụng.

AOV_VAN.6.4E - Người đánh giá sẽ tiến hành thử nghiệm thâm nhập dựa trên cơ sở các điểm yếu tiềm ẩn xác định, để xác định rằng STOE có khả năng chống các cuộc tấn công được thực hiện bởi một kẻ tấn công có khả năng tấn công trung bình.

C.8.2.9 Phân tích điểm yếu có hệ thống nâng cao AOV_VAN.7

Phân cấp theo: - Phân tích điểm yếu có hệ thống AOV_VAN.6

Phụ thuộc vào: - Mô tả kiến trúc ASD_SAD.1;

- Khái niệm an toàn của vận hành ASD_CON.1;

- Đặc tả chức năng giao diện ASD_IFS.1;

- Thiết kế phân hệ ASD_STD.1;

- Hướng dẫn người sử dụng AOD_OGD.1

C.8.2.9.1 Mục tiêu

Khảo sát điểm yếu của thông tin có sẵn trong miền công cộng, người đánh giá thực hiện phân tích điểm yếu về đặc tả và thiết kế của STOE để xác định các điểm yếu tiềm ẩn.

C.8.2.9.2 Các lưu ý áp dụng

C.8.2.9.3 Hành động phát triển/tích hợp

AOV_VAN.7.1D - Nhà phát triển/tích hợp sẽ cung cấp STOE và môi trường thử nghiệm để thử nghiệm.

C.8.2.6.4 Nội dung và mô tả các bằng chứng

AOV_VAN.7.1C - STOE và tài liệu hướng dẫn người sử dụng sẽ cho phép người đánh giá chuẩn bị và thực hiện thử nghiệm.

C.8.2.9.5 Hành động đánh giá

AOV_VAN.7.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

AOV_VAN.7.2E - Người đánh giá sẽ thực hiện nghiên cứu tài nguyên miền công cộng để xác định các điểm yếu tiềm ẩn trong STOE dựa trên tài liệu mô tả kiến trúc và khái niệm an toàn của vận hành.

AOV_VAN.7.3E - Người đánh giá sẽ thực hiện độc lập phân tích điểm yếu có hệ thống của STOE để xác định các điểm yếu tiềm ẩn trong STOE bằng cách sử dụng tài liệu mô tả kiến trúc, khái niệm an toàn của vận hành, các đặc tả chức năng giao diện, tất cả các tài liệu thiết kế có sẵn và tài liệu hướng dẫn người sử dụng.

AOV_VAN.7.4E - Người đánh giá sẽ tiến hành thử nghiệm thâm nhập dựa trên cơ sở các điểm yếu tiềm ẩn xác định, để xác định rằng STOE có khả năng chống các cuộc tấn công được thực hiện bởi một kẻ tấn công có khả năng tấn công mức cao.

C.9 Lớp APR: Chuẩn bị vận hành khai thác

C.9.1 Giới thiệu

Trước khi vận hành khai thác là cần thiết để thiết lập và xác định cấu trúc quản lý an toàn với mục đích là để ban hành và tuyên truyền cho chính sách an toàn và nâng cao nhận thức cho tổ chức. Quản lý rõ ràng nên thúc đẩy và hỗ trợ an toàn trong tổ chức thông qua sự tham gia tích cực trong việc thực hiện an toàn trong tổ chức. Hoạt động quản lý bao gồm các mục tiêu an toàn cơ bản để đáp ứng yêu cầu tổ chức, và được tích hợp trong quy trình nghiệp vụ có liên quan. Các hoạt động bao gồm việc xây dựng, rà soát và phê duyệt chính sách an toàn, đảm bảo có sự hỗ trợ quản lý rõ ràng và có thể nhìn thấy, và cung cấp các chương trình đào tạo và nâng cao nhận thức về an toàn để hỗ trợ các chính sách an toàn của tổ chức. Nó cũng chỉ định một người quản lý là cơ quan an toàn của tổ chức.

Chuẩn bị vận hành khai thác cũng là cần thiết để xác nhận sự phù hợp của các thủ tục được sử dụng để cấu hình hệ thống vận hành cả về cài đặt và khởi động hàng ngày.

C.9.2 Đào tạo nâng cao nhận thức (APR_AWA)

C.9.2.1 Mục tiêu

Họ này yêu cầu công tác quản lý đào tạo như một phương tiện cho nhân viên để tìm hiểu vai trò an toàn và trách nhiệm của mình đối với hoạt động nghiệp vụ của họ trong hệ thống vận hành.

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

Họ này có hai thành phần, các thành phần trong họ này được phân mức trên cơ sở xác nhận mô tả trong tài liệu hướng dẫn và xác minh trong hệ thống vận hành.

C.9.2.3 Đào tạo nâng cao nhận thức APR_AWA.1

Phụ thuộc: Không phụ thuộc.

C.9.2.3.1 Hành động quản lý

APR_AWA.1.1M - Quản lý thực hiện việc đào tạo nâng cao nhận thức với một phương pháp giới thiệu chính thức được thiết kế để giới thiệu [lựa chọn: kiểm soát tất cả hoạt động, [Phân chia: kiểm soát hoạt động]] và kỳ vọng của họ [lựa chọn: trước, trong [Phân chia: khung thời gian], định kỳ [Phân chia: chu kỳ thời gian]] cho nhân viên truy cập vào các tài sản hệ thống hoạt động.

C.9.2.3.2 Nội dung và mô tả các bằng chứng

APR_AWA.1.1C - Việc đào tạo nâng cao nhận thức phải được ghi vào hồ sơ.

APR_AWA.1.2C - Các hồ sơ phải có ngày tháng và thời gian, người có thẩm quyền, mục tiêu nhân sự, nội dung và kết quả của việc đào tạo.

C.9.2.3.3 Hành động đánh giá

APR_AWA.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.9.2.4 Xác minh đào tạo nâng cao nhận thức APR_AWA.2

Phân cấp theo: - Đào tạo nâng cao nhận thức APR_AWA.1

Phụ thuộc: Không phụ thuộc.

C.9.2.4.1 Hành động quản lý

APR_AWA.2.1M - Quản lý thực hiện việc đào tạo nâng cao nhận thức với một phương pháp giới thiệu chính thức được thiết kế để giới thiệu [lựa chọn: kiểm soát tất cả hoạt động, [Phân chia: kiểm soát hoạt động]] và kỳ vọng của họ [lựa chọn: trước, trong [Phân chia: khung thời gian], định kỳ [Phân chia: chu kỳ thời gian ]] cho nhân viên truy cập vào các tài sản hệ thống hoạt động.

C.9.2.4.2 Nội dung và mô tả các bằng chứng

APR_AWA.2.1C - Việc đào tạo nâng cao nhận thức phải được ghi vào hồ sơ.

APR_AWA.2.2C - Các hồ sơ phải có ngày tháng và thời gian, người có thẩm quyền, mục tiêu nhân sự, nội dung và kết quả của việc đào tạo.

C.9.2.4.3 Hành động đánh giá

APR_AWA.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

APR_AWA.2.2E - Người đánh sẽ thẩm tra độc lập tính xác thực của thực hiện việc đào tạo nâng cao nhận thức.

C.9.3 Truyền thông (APR_CMM)

C.9.3.1 Mục tiêu

Họ này yêu cầu quản lý có một số tài liệu hướng dẫn hoạt động xác định và SSFs cụ thể cho nhân viên thích hợp.

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

Họ này có hai thành phần, các thành phần trong họ này được phân mức trên cơ sở xác nhận mô tả trong tài liệu hướng dẫn và xác minh trong hệ thống hoạt động.

C.9.3.3 Thông tin về kiểm soát APR_CMM.1

Phụ thuộc: Không phụ thuộc.

C.9.3.3.1 Hành động quản lý

APR_CMM.1.1M Việc quản lý sẽ thông tin [lựa chọn: tất cả SSFs, [Phân chia: SSFs]] cho tất cả các nhân viên liên quan đến kiểm soát hoạt động trước khi cho họ truy cập vào các tài sản hệ thống hoạt động.

C.9.3.3.2 Nội dung và mô tả các bằng chứng

APR_CMM.1.1C - Thông tin sẽ được ghi vào hồ sơ.

APR_CMM.1.2C Hồ sơ phải có ngày tháng và thời gian, người có thẩm quyền, mục tiêu nhân sự và các nội dung của thông tin.

C.9.3.3.3 Hành động đánh giá

APR_CMM.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.9.3.4 Xác minh thông tin về kiểm soát APR_CMM.2

Phân cấp theo: Thông tin về kiểm soát APR_CMM.1

Phụ thuộc: Không phụ thuộc.

C.9.3.4.1 Hành động quản lý

APR_CMM.2.1M - Việc quản lý sẽ thông tin [lựa chọn: tất cả SSFs, [Phân chia: SSFs]] cho tất cả các nhân viên liên quan đến kiểm soát hoạt động trước khi cho họ truy cập vào các tài sản hệ thống hoạt động.

C.9.3.4.2 Nội dung và mô tả các bằng chứng

APR_CMM.2.1C - Thông tin sẽ được ghi vào hồ sơ.

APR_CMM.2.2C Hồ sơ phải có ngày tháng và thời gian, người có thẩm quyền, mục tiêu nhân sự và các nội dung của thông tin.

C.9.3.4.3 Hành động đánh giá

APR_CMM.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

APR_CMM.2.2E - Người đánh sẽ thẩm tra độc lập tính xác thực truyền thông của kiểm soát hoạt động.

C.9.4 Kiểm tra cài đặt an toàn

C.9.4.1 Mục tiêu

Họ này cung cấp một phương tiện để xác minh việc cài đặt và khởi động của STOE. Việc cài đặt và khởi động của STOE cần được thực hiện và hoạt động một cách chính xác và hiệu quả phù hợp với chính sách an toàn của hệ thống hoạt động.

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

Họ này có hai thành phần, các thành phần trong họ được phân mức trên cơ sở xác nhận mô tả trong tài liệu hướng dẫn và xác minh trong hệ thống hoạt động.

C.9.4.3 Kiểm tra cài đặt an toàn APR_SIC.1

Phụ thuộc: Không phụ thuộc.

C.9.4.3.1 Hành động quản lý

APR_SIC.1.1M - Nhà phát triển/tích hợp sẽ cung cấp tài liệu các thủ tục cài đặt an toàn cần thiết để đảm bảo rằng các thành phần và giao diện bao gồm của STOE, đặc biệt là để kiểm soát an toàn tài sản và giao diện có thể được cài đặt, khởi động và hoạt động tương tác một cách an toàn.

C.9.4.3.2 Nội dung và mô tả các bằng chứng

APR_SIC.1.1C - Tài liệu thủ tục cài đặt an toàn sẽ mô tả các bước cần thiết để xác minh cài đặt an toàn, khởi động và hoạt động tương tác của STOE trong môi trường của nó.

C.9.4.3.3 Hành động đánh giá

APR_SIC.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.9.4.4 Xác minh kiểm tra cài đặt an toàn APR_SIC.2

Phân cấp theo: Kiểm tra cài đặt an toàn APR_SIC.1

Phụ thuộc: Không phụ thuộc.

C.9.4.4.1 Hành động quản lý

APR_SIC.2.1M - Nhà phát triển/tích hợp sẽ cung cấp tài liệu các thủ tục cài đặt an toàn cần thiết để đảm bảo rằng các thành phần và giao diện bao gồm của STOE, đặc biệt là để kiểm soát an toàn tài sản và giao diện có thể được cài đặt, khởi động và hoạt động tương tác một cách an toàn.

C.9.4.4.2 Nội dung và mô tả các bằng chứng

APR_SIC.2.1C - Tài liệu thủ tục cài đặt an toàn sẽ mô tả các bước cần thiết để xác minh cài đặt an toàn, khởi động và hoạt động tương tác của STOE trong môi trường của nó.

C.9.4.4.3 Hành động đánh giá

APR_SIC.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

APR_SIC.2.2E - Người đánh giá sẽ xác minh rằng các thủ tục cài đặt an toàn dẫn đến một cấu hình an toàn.

C.10 Lớp ASO: Hồ sơ về hệ thống vận hành

C.10.1 Giới thiệu

Hầu hết các hoạt động đảm bảo được thực hiện trong môi trường phát triển hoặc môi trường thử nghiệm. Do đó, để có thể kiểm soát hoạt động trong môi trường vận hành cần thực hiện quan sát hành vi khác nhau của chúng trong môi trường thử nghiệm. Do đó, hoạt động đảm bảo phát triển thường phải được bổ sung bằng cách kiểm tra và xác minh các hồ sơ hoạt động và kiểm soát trong quá trình vận hành hệ thống.

Lớp này có họ chi phối SSFs thực hiện một cách chính xác và hiệu quả trong quá trình vận hành của hệ thống. Mục đích chính của hoạt động an toàn hệ thống là có thể xác định rằng hệ thống vận hành đang hoạt động một cách an toàn mà không vi phạm các chính sách an toàn hệ thống vận hành. Nó cũng xác định các hành động sẽ diễn ra nếu và khi xảy ra các sự kiện liên quan an toàn. Lớp này đảm bảo rằng các hành động thích hợp được thực hiện để phát hiện, ghi nhận và đáp ứng với sự kiện đó có thể là hành vi vi phạm có thể có của chính sách an toàn hệ thống vận hành.

Các họ trong lớp này định nghĩa một phương tiện quản lý để giám sát và xác minh kiểm soát vận hành.

C.10.2 Lớp ASO: Hồ sơ hệ thống vận hành

C.10.2.1 Mục tiêu

Họ này cung cấp hồ sơ hoạt động cho SSFs trong quá trình vận hành. Các kiểm soát hoạt động cần được thực hiện và vận hành một cách chính xác và hiệu quả phù hợp với chính sách an toàn của hệ thống vận hành.

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

Họ này có hai thành phần, các thành phần trong họ được phân mức trên cơ sở xác nhận mô tả trong tài liệu hướng dẫn và xác minh trong hệ thống vận hành.

C.10.2.3 Hồ sơ kiểm soát vận hành ASO_RCD.1

Phụ thuộc: Không phụ thuộc.

C.10.2.3.1 Hành động quản lý

ASO_RCD.1.1M Việc quản lý phải ghi lại các bằng chứng vận hành theo quy định bởi [lựa chọn: tất cả các kiểm soát vận hành hoặc [phân chia: kiểm soát vận hành]].

C.10.2.3.2 Nội dung và mô tả các bằng chứng

ASO_RCD.1.1C Các thông tin liên quan đến các bằng chứng vận hành phải được ghi lại trong hồ sơ.

ASO_RCD.1.2C - Hồ sơ phải có ngày tháng và thời gian, người chịu trách nhiệm, mục đích kiểm soát vận hành và các kết quả của vận hành.

C.10.2.3.3 Hành động đánh giá

ASO_RCD.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.10.2.4 Xác minh hồ sơ vận hành ASO_RCD.2

Phân cấp theo: - Hồ sơ kiểm soát vận hành ASO_RCD.1

Phụ thuộc: Không phụ thuộc.

C.10.2.4.1 Hành động quản lý

ASO_RCD.2.1M Việc quản lý phải ghi lại các bằng chứng vận hành theo quy định bởi [lựa chọn: tất cả các kiểm soát vận hành hoặc [phân chia: kiểm soát vận hành]].

C.10.2.4.2 Nội dung và mô tả các bằng chứng

ASO_RCD.2.1C - Các thông tin liên quan đến các bằng chứng vận hành phải được ghi lại trong hồ sơ.

ASO_RCD.2.2C - Hồ sơ phải có ngày tháng và thời gian, người chịu trách nhiệm, mục đích kiểm soát vận hành và các kết quả của vận hành.

C.10.2.4.3 Hành động đánh giá

ASO_RCD.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

ASO_RCD.2.2E - Người đánh giá sẽ xác minh độc lập rằng các thông tin liên quan đến hoạt động kiểm soát vận hành được ghi lại một cách chính xác.

C.10.3 Xác minh kiểm soát vận hành (ASO_VER)

C.10.3.1 Mục tiêu

Họ này cung cấp một phương tiện để xác minh kiểm soát vận hành trong quá trình vận hành, kiểm soát vận hành cần được thực hiện và vận hành một cách chính xác và hiệu quả phù hợp với chính sách an toàn của hệ thống vận hành.

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

Họ này có hai thành phần, các thành phần trong họ được phân mức trên cơ sở xác nhận mô tả trong tài liệu hướng dẫn và xác minh trong hệ thống vận hành.

C.10.3.3 Xác minh kiểm soát vận hành ASO_VER.1

Phụ thuộc: Không phụ thuộc.

C.10.3.3.1 Hành động quản lý

ASO_VER.1.1M - Việc quản lý phải xác minh rằng [lựa chọn: tất cả các kiểm soát vận hành hoặc [phân chia: kiểm soát vận hành]] được cài đặt và vận hành một cách chính xác và hiệu quả.

C.10.3.3.2 Nội dung và mô tả các bằng chứng

ASO_VER.1.1C 1C - Các thông tin liên quan đến việc xác minh phải được ghi lại trong hồ sơ.

ASO_VER.1.2C - Hồ sơ phải có ngày tháng và thời gian, người chịu trách nhiệm, mục đích kiểm soát vận hành và các kết quả xác minh.

C.10.3.3.3 Hành động đánh giá

ASO_VER.1.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.10.3.4 Xác minh độc lập kiểm soát vận hành ASO_VER.2

Phân cấp theo: Xác minh kiểm soát vận hành ASO_VER.1

Phụ thuộc: Không phụ thuộc.

C.10.3.4.1 Hành động quản lý

ASO_VER.2.1M - Việc quản lý phải xác minh rằng [lựa chọn: tất cả các kiểm soát vận hành hoặc [phân chia: kiểm soát vận hành]] được cài đặt và vận hành một cách chính xác và hiệu quả.

C.10.3.4.2 Nội dung và mô tả các bằng chứng

ASO_VER.2.1C - Các thông tin liên quan đến việc xác minh phải được ghi lại trong hồ sơ.

ASO_VER.2.2C - Hồ sơ phải có ngày tháng và thời gian, người chịu trách nhiệm, mục đích kiểm soát vận hành và các kết quả xác minh.

C.10.3.4.3 Hành động đánh giá

ASO_VER.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

ASO_VER.2.2E - Người đánh giá sẽ xác minh độc lập rằng kiểm soát vận hành được cài đặt và vận hành một cách chính xác và hiệu quả.

C.10.4 Giám sát kiểm soát vận hành (ASO_MON)

C.10.4.1 Mục tiêu

Họ này cung cấp một phương tiện để giám sát kiểm soát vận hành trong quá trình vận hành. Mục đích chính của giám sát kiểm soát vận hành là cho phép xác định rằng kiểm soát vận hành đang vận hành một cách an toàn mà không vi phạm các chính sách an toàn hệ thống vận hành. Kiểm soát vận hành cần được thực hiện và vận hành một cách chính xác và hiệu quả phù hợp với chính sách an toàn của hệ thống vận hành. Nó cũng xác định các hành động sẽ diễn ra nếu và khi một số thay đổi xảy ra trong hệ thống vận hành.

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

Họ này có hai thành phần, các thành phần trong họ được phân mức trên cơ sở xác nhận mô tả trong tài liệu hướng dẫn và xác minh trong hệ thống vận hành.

C.10.4.3 Giám sát kiểm soát vận hành bằng quản lý ASO_MON.1

Phụ thuộc: Không phụ thuộc.

C.10.4.3.1 Hành động quản lý

ASO_MON.1.1M - Việc quản lý phải giám sát các điều khoản và mức độ hoạt động của [lựa chọn: tất cả các kiểm soát vận hành hoặc [Phân chia: kiểm soát vận hành]] theo chu kỳ quy định.

ASO_MON.1.2M - Việc quản lý phải giám sát những thay đổi để cung cấp các dịch vụ bao gồm bảo dưỡng và cải tiến các chính sách an toàn, thủ tục và kiểm soát, có tính đến tính quan trọng của các hệ thống nghiệp vụ và tham gia quá trình đánh giá lại rủi ro.

C.10.4.3.2 Nội dung và mô tả các bằng chứng

ASO_MON.1.1C - Các thông tin liên quan đến việc giám sát phải được ghi lại trong hồ sơ.

ASO_MON.1.2C - Hồ sơ phải có ngày tháng và thời gian, người chịu trách nhiệm, mục đích kiểm soát vận hành và các kết quả giám sát.

C.10.4.3.3 Hành động đánh giá

ASO_MON.1.1 E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

C.10.4.4 Xác minh giám sát kiểm soát vận hành ASO_MON.2

Phân cấp theo: Giám sát kiểm soát vận hành bằng quản lý ASO_MON.1

Phụ thuộc: Không phụ thuộc.

C.10.4.4.1 Hành động quản lý

ASO_MON.2.1M - Việc quản lý phải giám sát các điều khoản và mức độ hoạt động của [lựa chọn: tất cả các kiểm soát vận hành hoặc [Phân chia: kiểm soát vận hành]] theo chu kỳ quy định.

ASO_MON.2.2M - Việc quản lý phải giám sát những thay đổi để cung cấp các dịch vụ bao gồm bảo dưỡng và cải tiến các chính sách an toàn, thủ tục và kiểm soát, có tính đến tính quan trọng của các hệ thống nghiệp vụ và tham gia quá trình đánh giá lại rủi ro.

C.10.4.4.2 Nội dung và mô tả các bằng chứng

ASO_MON.2.1C - Các thông tin liên quan đến việc giám sát phải được ghi lại trong hồ sơ.

ASO_MON.2.2C - Hồ sơ phải có ngày tháng và thời gian, người chịu trách nhiệm, mục đích kiểm soát vận hành và các kết quả giám sát.

C.10.4.4.3 Hành động đánh giá

ASO_MON.2.1E - Người đánh giá sẽ xác nhận rằng các thông tin được cung cấp đáp ứng tất cả các yêu cầu về nội dung và mô tả các bằng chứng.

ASO_MON.2.2E - Người đánh giá phải xác minh một cách độc lập rằng việc giám sát được thực hiện phù hợp với chính sách an toàn.

Phụ lục D

(Quy định)

Phương pháp luận đánh giá hệ thống vận hành

D.1 Phương pháp tiếp cận kỹ thuật

D.1.1 Phương pháp tiếp cận tài liệu

TCVN 11386:2016 là một tài liệu trọn bộ lặp lại và mở rộng cấu trúc các thành phần đảm bảo, phạm vi và khả năng áp dụng trong TCVN 8709-3. Tiêu chuẩn này sử dụng một hướng tiếp cận khác, nó được sử dụng để đọc kết hợp với Phụ lục C và TCVN 11386:2016. Thông tin ở đây không được lặp lại nếu mối quan hệ với khoản mục liên quan của phụ lục rõ ràng. Ví dụ, tài liệu về các yếu tố tiêu chuẩn không được lặp lại nhưng được tham chiếu khi cần thiết. Khi các phương pháp và cách tiếp cận từ TCVN 11386:2016 được áp dụng được cho phương pháp luận này và được tham chiếu nhiều hơn là lặp lại.

Mỗi lớp đảm bảo được định nghĩa trong Phần 2 do một điều khoản phụ của phương pháp luận trong Tiêu chuẩn này hỗ trợ. Mỗi thành phần của từng hệ thống trong lớp được coi là hoạt động phụ đánh giá riêng rẽ, với khoản mục lựa chọn riêng trong điều khoản phụ, nêu chi tiết các đơn vị làm việc của cán bộ thẩm tra liên quan. Khi có mối quan hệ phân cấp giữa các thành phần, các đơn vị làm việc trước không thay đổi được tham chiếu bởi các thành phần cao hơn thay vì bị lặp lại. Để đơn giản hóa của cấu trúc tài liệu, các đơn vị làm việc không được đặt tiêu đề phụ riêng.

D.1.2 Lớp bằng chứng

Bằng chứng để hỗ trợ việc đánh giá các hệ thống vận hành có thể được lấy theo các mẫu bổ sung của các mẫu theo quy định trong việc đánh giá tại TCVN 8709. Bằng chứng thuyết phục nhất được thu thập từ việc quan sát trực tiếp của cán bộ thẩm tra; việc áp dụng đặc biệt này dùng cho chức năng hoạt động an toàn khi một biện pháp có thể được lập thành tài liệu nhưng không được sử dụng trong thực tế. Tuy nhiên, có thể không phải lúc nào cũng có thể ứng dụng thực tế để chứng minh các biện pháp bằng cách quan sát trực tiếp.

Bằng chứng cũng có thể được thiết lập từ việc quan sát các kết quả thực hiện các biện pháp (nhật ký khách ghé thăm, lịch sử hoạt động, v.v). Cuối cùng thì bằng chứng có thể lấy từ các tài liệu thiết kế các biện pháp và các liên kết của chúng từ các chính sách an toàn. Việc kiểm tra tài liệu đặc biệt hữu ích cho các biện pháp an toàn kỹ thuật khi có một biện pháp được thiết kế, kiểm tra và sau đó cài đặt đúng, nó sẽ được sử dụng hiệu quả hơn trong thực tế.

Tất cả các động từ đơn vị làm việc thể hiện những hành động của cán bộ thẩm tra bắt buộc được đứng trước bởi trợ động từ phải và bằng cách thể hiện cả động từ, và phải ở dạng nét đậm và nghiêng. Trong một số trường hợp, văn bản hướng dẫn đi kèm các đơn vị làm việc đưa ra đề xuất về một phương pháp hoặc cơ chế thực hiện công việc. Trợ động từ cần được dùng khi thích dùng phương pháp miêu tả. Tất cả các trợ động từ khác, bao gồm có thể, được sử dụng khi phương pháp miêu tả cũng được cho phép nhưng không khuyến khích hoặc cũng không đặc biệt thích dùng; đây chỉ là một gợi ý.

Cán bộ thẩm tra được yêu cầu xác minh một vài khía cạnh độc lập của SSF mà không dùng cơ chế xác minh xác thực được định nghĩa trong một số trường hợp. Trong những trường hợp này, phụ thuộc vào việc cán bộ thẩm tra lựa chọn cách thực hiện việc xác minh. Cán bộ thẩm tra nên lựa chọn một phương pháp hiệu quả và hữu dụng nhưng có đủ tự tin rằng SSF đang được nói đến được áp dụng một cách đúng đắn. Phương pháp được chọn cần được ghi lại trong ETR.

D.2 Lớp ASP: Đánh giá hồ sơ bảo vệ hệ thống

D.2.1 Giới thiệu

Mục đích của lớp đánh giá tài liệu bảo vệ hệ thống là để chứng nhận rằng một SPP là một đặc tính phù hợp với và hoàn chỉnh của một loại STOE; và nếu nó đề cập tới các SPPs, PPs hoặc các gói khác thì đây là một cách giải thích đúng của các thông số kỹ thuật đó.

Có mười một hệ thống trong lớp này, giải quyết các khía cạnh khác nhau của thông số kỹ thuật SPP. Năm hệ thống cuối được sử dụng để xác định các khía cạnh miền cụ thể của STOEs phù hợp với SPP.

D.2.2 Giới thiệu về SPP (ASP_INT)

D.2.2.1 Cấu trúc họ

Hệ thống bao gồm một thành phần, ASP_INT.1 Giới thiệu về SPP.

D.2.2.2 Đánh giá hoạt động phụ ASP_INT.1

D.2.2.2.1 Hoạt động ASP_INT.1.1E

Hoạt động này yêu cầu cán bộ thẩm tra kiểm tra việc giới thiệu SPP về nội dung và việc trình bày và được lập bởi bảy đơn vị làm việc. Hoạt động thất bại nếu các đơn vị làm việc không xác định được các yêu cầu liên quan.

ASP_INT.1-1 Cán bộ thẩm tra phải kiểm tra việc giới thiệu SPP bao gồm một tham chiếu SPP, tổng quan STOE và thông số kỹ thuật tổ chức miền.

ASP_INT.1-2 Cán bộ thẩm tra phải kiểm tra tham chiếu SPP để xác nhận rằng nó chỉ xác định SPP.

ASP_INT.1-3 Cán bộ thẩm tra phải kiểm tra tổng quan SPP để xác nhận việc nêu tóm tắt cách dùng và đặc điểm an toàn chính của STOE.

ASP_INT.1-4 Cán bộ thẩm tra phải kiểm tra tổng quan STOE để xác nhận việc xác định loại STOE.

Loại STOE có thể là "hệ thống vận hành" hoặc một số định nghĩa chính xác hơn.

ASP_INT.1-5 Cán bộ thẩm tra phải kiểm tra tổng quan STOE để xác nhận việc nhận dạng các mối quan hệ và các giao diện đối với các hệ thống vận hành ngoài do STOE yêu cầu.

Việc nhận dạng có thể giúp bất cứ người đọc bản giới thiệu SPP nào thiết lập các hệ thống vận hành ngoài ghép nối với STOE và lý do ghép nối.

ASP_INT.1-6 Cán bộ thẩm tra phải kiểm tra thông số kỹ thuật tổ chức miền để khẳng định rằng nó chỉ miêu tả tổ chức của các miền an toàn bắt buộc và việc nhận dạng chúng.

Nếu hệ thống vận hành bao hàm một miền đơn, đơn vị làm việc này được đáp ứng bởi một lệnh rằng đó là một miền đơn.

ASP_INT.1-7 Cán bộ thẩm tra phải kiểm tra thông số kỹ thuật tổ chức miền để xác nhận rằng đối với mỗi miền, nó sẽ nhận dạng bất cứ dịch vụ an toàn nào do miền đó cung cấp có thể dùng cho các miền khác và các đặc tính an toàn của miền mà có thể được dùng trên các miền khác.

Nếu hệ thống vận hành bao hàm một miền đơn, đơn vị làm việc này được đáp ứng bởi một lệnh rằng đó là một miền đơn.

D.2.2.2.2 Hoạt động ASP_INT.1.2E

Hoạt động này yêu cầu cán bộ thẩm tra tìm kiếm tính không phù hợp trong việc giới thiệu SPP và được lập bởi một đơn vị làm việc. Hoạt động thất bại nếu các đơn vị làm việc không xác định được yêu cầu liên quan.

ASP_INT.1-8 Cán bộ thẩm tra phải xác nhận rằng tổng quan STOE và thông số kỹ thuật tổ chức miền phù hợp với nhau.

Cán bộ thẩm tra cần tìm kiếm thông tin trong thông số kỹ thuật tổ chức miền phù hợp với các tuyên bố trong tổng quan STOE. Ví dụ, nếu theo tổng quan STOE, SPP xác định các hệ thống với các chức năng tính toán, nhưng thông số kỹ thuật tổ chức miền chỉ định nghĩa các miền giải quyết các tiện ích tự động văn phòng, thì điều này là không phù hợp.

D.2.3 Các tuyên bố tuân thủ

D.2.3.1 Cấu trúc Họ

Họ này bao gồm một thành phần, ASP_CCL.1 Các tuyên bố tuân thủ

D.2.2.2 Đánh giá hoạt động phụ ASP_CCL.1

D.2.3.2.1 Hoạt động ASP_CCL.1.1E

Hoạt động này yêu cầu cán bộ thẩm tra kiểm tra tuyên bố tuân thủ và các yêu cầu hợp lý về nội dung và việc trình bày, và được lập bởi mười đơn vị làm việc. Hoạt động thất bại nếu các đơn vị làm việc không xác định được các yêu cầu liên quan.

ASP_CCL.1-1 Cán bộ thẩm tra phải kiểm tra tuyên bố tuân thủ để xác nhận việc bao hàm tuyên bố tuân thủ tiêu chuẩn nhận dạng phiên bản của Báo cáo kỹ thuật đối với việc tương thích các yêu cầu của SPP.

ASP_CCL.1-2 Cán bộ thẩm tra phải kiểm tra tuyên bố tuân thủ tiêu chuẩn để xác nhận việc miêu tả tương thích chức năng của SPP đối với Tiêu chuẩn này hoặc tương thích chức năng tiêu chuẩn này hoặc tương thích chức năng mở rộng của tiêu chuẩn này

ASP_CCL.1-2 Cán bộ thẩm tra phải kiểm tra tuyên bố tuân thủ tiêu chuẩn để xác nhận việc miêu tả tương thích đảm bảo của SPP đối với tiêu chuẩn này hoặc tương thích đảm bảo hoặc đảm bảo mở rộng của tiêu chuẩn này.

ASP_CCL.1-4 Cán bộ thẩm tra phải đánh giá tuyên bố tuân thủ tiêu chuẩn để xác nhận việc phù hợp với định nghĩa các thành phần mở rộng.

Nếu các thành phần mở rộng được định nghĩa, khi đó tuyên bố tuân thủ tiêu chuẩn cần được mở rộng về chức năng hoặc đảm bảo, hoặc cả hai.

ASP_CCL.1-5 Cán bộ thẩm tra phải đánh giá tuyên bố tuân thủ để khẳng định việc nhận dạng tất cả các SPPs, PPs và các gói yêu cầu an toàn đối với Các tuyên bố tuân thủ của SPP.

Cán bộ thẩm tra cần xác định bất cứ SPPs, PPs và các gói yêu cầu an toàn được tham chiếu nào được nhận dạng không rõ ràng, và không có tham chiếu miêu tả cho SPPs, PPs hoặc các gói yêu cầu an toàn trong giới thiệu SPP mà không được liệt kê ở đây.

ASP_CCL.1-6 Cán bộ thẩm tra phải kiểm tra tuyên bố tuân thủ để xác định việc miêu tả việc tương thích của SPP đối với gói hoặc tương thích gói hoặc bổ sung gói.

Nếu SPP không tuyên bố tuân thủ đối với bất kỳ gói nào, đơn vị làm việc này không được áp dụng và do đó được coi là đáp ứng yêu cầu. Nếu không thì, cán bộ thẩm tra cần kiểm tra rằng SSFs và SSAs được định nghĩa trong SPP phù hợp với lớp tương thích được yêu cầu cho mỗi gói đã nhận dạng.

ASP_CCL.1-7 Cán bộ thẩm tra phải kiểm tra Các tuyên bố tuân thủ hợp lý để xác nhận việc chứng minh loại STOE phù hợp với loại STOE trong SPPs về tương thích được yêu cầu.

Nếu SPP không tuyên bố tuân thủ đối với bất cứ SPPs hoặc PPs nào, đơn vị làm việc này không thể áp dụng và do đó nó được coi là đã đáp ứng yêu cầu. Để chứng tỏ tính nhất quán, mối quan hệ trực tiếp giữa các loại STOE là không cần thiết; chỉ cần không có mâu thuẫn trong các thông tin cung cấp.

ASP_CCL.1-8 Cán bộ thẩm tra phải kiểm tra Các tuyên bố tuân thủ hợp lý để chứng nhận việc chứng minh lệnh định nghĩa vấn đề an toàn phù hợp với lệnh định nghĩa vấn đề an toàn trong SPPs và PPs khi tuyên bố tuân thủ.

Nếu SPP không tuyên bố tuân thủ đối với bất cứ SPPs hoặc PPs nào, đơn vị làm việc này không thể áp dụng và do đó nó được coi là đã đáp ứng yêu cầu. Nếu một SPP hoặc PP được tham chiếu không có định nghĩa về chính sách an toàn, nó được xem như là đã phù hợp mà không cần phải xem xét kỹ hơn.

ASP_CCL.1-9 Cán bộ thẩm tra phải kiểm tra tuyên bố tuân thủ hợp lý để chứng nhận việc chứng minh lệnh mục tiêu phù hợp với lệnh mục tiêu trong SPPs và PPs khi tuyên bố tuân thủ.

Nếu SPP không tuyên bố tuân thủ đối với bất cứ SPPs hoặc PPs nào, đơn vị làm việc này không thể áp dụng và do đó nó được coi là đã đáp ứng yêu cầu. Nếu một SPP hoặc PP được tham chiếu không có các đích an toàn, nó được xem như là đã phù hợp mà không cần phải xem xét kỹ hơn.

ASP_CCL.1-10 Cán bộ thẩm tra phải kiểm tra Các tuyên bố tuân thủ hợp lý để chứng nhận việc chứng minh lệnh các yêu cầu an toàn phù hợp với lệnh các yêu cầu an toàn trong SPPs, PPs và các gói khi tuyên bố tuân thủ.

Nếu SPP không tuyên bố tuân thủ đối với bất kỳ SPPs, PPs hoặc gói nào, đơn vị làm việc này không được áp dụng và do đó được coi là đáp ứng yêu cầu.

Nếu một SPP tuyên bố tuân thủ với một PP, chỉ cần chỉ rõ rằng OSF được định nghĩa đúng với các giả định về môi trường vận hành trong phần định nghĩa vấn đề an toàn của PP.

D.2.4 Định nghĩa vấn đề an toàn (ASP_SPD)

D.2.4.1 Cấu trúc Họ

Họ này bao gồm một thành phần, ASP_SPD.1 Định nghĩa vấn đề an toàn.

D.2.4.2 Đánh giá hoạt động phụ ASP_SPD.1

D.2.4.2.1 Hoạt động ASP_SPD.1.1E

Hoạt động này yêu cầu cán bộ thẩm tra kiểm tra việc định nghĩa vấn đề an toàn về nội dung và việc trình bày và được lập bởi ba đơn vị làm việc. Hoạt động thất bại nếu các đơn vị làm việc không xác định được các yêu cầu liên quan.

ASP_SPD.1-1 Cán bộ thẩm tra phải kiểm tra định nghĩa vấn đề an toàn để xác nhận việc miêu tả tất cả các rủi ro có thể có đối với STOE và mỗi rủi ro được phân loại thành có thể chấp nhận được hoặc không thể chấp nhận được.

Nếu tất cả các đích an toàn xuất phát từ các chính sách, không cần miêu tả rủi ro trong SPD. Trong trường hợp này, đơn vị làm việc không được áp dụng, và do đó được coi là đã đáp ứng yêu cầu.

Các rủi ro cần được nhận dạng trong đánh giá rủi ro, và mỗi rủi ro được phân tích và phân lớp thành có thể chấp nhận được hoặc không thể chấp nhận được.

ASP_SPD.1-2 Cán bộ thẩm tra phải kiểm tra định nghĩa vấn đề an toàn để xác nhận rằng tất cả các rủi ro không thể chấp nhận được được miêu tả về mặt các đe dọa và các điểm yếu, và tất cả các mối đe dọa được miêu tả về tác nhân đe dọa, tài sản và hành động gây hại.

Nếu tất cả các đích an toàn xuất phát từ các chính sách, hoặc tất cả các rủi ro được phân lớp thành có thể chấp nhận được, đơn vị làm việc này không được áp dụng, và do đó được coi là đã đáp ứng yêu cầu.

Các mối đe dọa có thể được miêu tả cụ thể hơn bởi các khía cạnh như chuyên môn, tài nguyên, cơ hội và động lực.

ASP_INT.1-3 Cán bộ thẩm tra phải kiểm tra định nghĩa vấn đề an toàn để xác nhận việc miêu tả OSPs.

Nếu tất cả các đích an toàn xuất phát từ các mối đe dọa, không cần miêu tả OSPs trong SPD. Trong trường hợp này, đơn vị làm việc không được áp dụng, và do đó được coi là đã đáp ứng yêu cầu.

D.2.5 Các đích an toàn (ASP_OBJ)

D.2.5.1 Cấu trúc Họ

Họ này bao gồm một thành phần, ASP_OBJ.1 Các đích an toàn

D.2.5.2 Đánh giá hoạt động phụ ASP_OBJ.1

D.2.5.2.1 Hoạt động ASP_OBJ.1.1E

Hoạt động này yêu cầu cán bộ thẩm tra kiểm tra lệnh các đích an toàn và các đích an toàn hợp lý về nội dung và việc trình bày và được lập bởi tám đơn vị làm việc. Hoạt động thất bại nếu các đơn vị làm việc không xác định được các yêu cầu liên quan.

ASP_OBJ.1-1 Cán bộ thẩm tra phải kiểm tra lệnh các đích an toàn để xác nhận việc miêu tả các đích an toàn chức năng cho STOE.

ASP_OBJ.1-2 Cán bộ thẩm tra phải kiểm tra lệnh các đích an toàn để xác nhận việc miêu tả các đích an toàn chức năng đáp ứng bởi các hệ thống vận hành ngoài.

Nếu không có đích an toàn chức năng nào được đáp ứng bởi các hệ thống vận hành ngoài, đơn vị làm việc này không được áp dụng, và do đó được coi là đã đáp ứng yêu cầu.

Các đích an toàn chức năng đáp ứng bởi các hệ thống vận hành ngoài không được cân nhắc thêm trong việc đánh giá SPP, nhưng sẽ có hiệu lực trong bất cứ đánh giá STOE nào.

ASP_OBJ.1-3 Cán bộ thẩm tra phải kiểm tra lệnh các đích an toàn để xác nhận việc miêu tả các đích an toàn đảm bảo cho STOE.

ASP_OBJ.1-4 Cán bộ thẩm tra phải kiểm tra các đích an toàn hợp lý để chứng nhận việc tìm ra từng đích an toàn chức năng cho STOE về các rủi ro phải chịu bởi đích an toàn đó và/ hoặc OSPs do đích an toàn đó gây ra.

Mỗi đích an toàn chức năng đối với STOE có thể truy vết ngược các mối đe dọa hoặc OSPs, hoặc việc liên kết các mối đe dọa và OSPs, nhưng nó phải truy vết ngược ít nhất một mối đe dọa hoặc OSP.

ASP_OBJ.1-5 Cán bộ thẩm tra phải kiểm tra các đích an toàn hợp lý để chứng nhận việc tìm ra từng đích an toàn chức năng cho STOE đối với các rủi ro phải chịu bởi đích an toàn đó và/ hoặc OSPs do đích an toàn đó gây ra.

Nếu không có đích an toàn chức năng nào đáp ứng bởi các hệ thống vận hành ngoài, đơn vị làm việc này không được áp dụng, và do đó được coi là đã đáp ứng yêu cầu.

Mỗi đích an toàn chức năng đối với các hệ thống vận hành ngoài có thể truy vết ngược các mối đe dọa hoặc OSPs, hoặc việc liên kết các mối đe dọa và OSPs, nhưng nó phải truy vết ngược ít nhất một mối đe dọa hoặc OSP.

ASP_OBJ.1-6 Cán bộ thẩm tra phải kiểm tra các đích an toàn hợp lý để chứng nhận việc chứng minh các đích an toàn chức năng chống lại được tất cả các rủi ro không thể chấp nhận được.

Đối với mỗi rủi ro không thể chấp nhận được, cán bộ thẩm tra cần xác nhận rằng nếu các đích an toàn chức năng truy vết ngược rủi ro nhận được, rủi ro sẽ bị loại bỏ hoặc bị giảm nhẹ xuống mức độ có thể chấp nhận được.

Cán bộ thẩm tra cũng khẳng định rằng mỗi đích an toàn chức năng truy vết ngược một rủi ro không thể chấp nhận được là cần thiết: nếu nhận được đích an toàn, nó góp phần xóa bỏ hoặc hạn chế mức độ rủi ro.

Nếu đối với bất cứ rủi ro không thể chấp nhận nào, không có đích an toàn chức năng nào truy vết ngược rủi ro đó, đơn vị làm việc này thất bại.

ASP_OBJ.1-7 Cán bộ thẩm tra phải kiểm tra các đích an toàn hợp lý để chứng nhận việc chứng minh các đích an toàn chức năng có hiệu lực trên tất cả các OSPs.

Đối với từng OSP, cán bộ thẩm tra cần xác nhận rằng tất cả các đích an toàn chức năng truy vết ngược OSP đã nhận được, OSP có hiệu lực.

Cận bộ thẩm tra cũng khẳng định rằng mỗi đích an toàn chức năng truy vết ngược OSP là cần thiết: nếu nhận được đích an toàn, nó góp phần tạo hiệu lực của OSP đó.

Nếu đối với bất cứ OSP nào, không có đích an toàn chức năng nào truy vết ngược OSP đó, đơn vị làm việc này thất bại.

ASP_OBJ.1-8 Cán bộ thẩm tra phải kiểm tra các đích an toàn hợp lý để chứng nhận việc giải thích nguyên nhân chọn các đích an toàn đảm bảo.

Cán bộ thẩm tra xác nhận các lý do đưa ra các mục tiêu đã chọn. Tuy nhiên, các lý do này không được đảm bảo, và thậm chí có thể được coi là lựa chọn tùy ý.

D.2.6 Định nghĩa thành phần mở rộng (ASP_ECD)

D.2.6.1 Cấu trúc Họ

Họ này bao gồm một thành phần, ASP_ECD.1 Định nghĩa thành phần mở rộng.

D.2.6.2 Đánh giá hoạt động phụ ASP_ECD.1

D.2.6.2.1 Hoạt động ASP_ECD.1.1 E

Hoạt động này yêu cầu cán bộ thẩm tra phải kiểm tra lệnh định nghĩa thành phần mở rộng và các yêu cầu an toàn về nội dung và cách trình bày và được lập bởi năm đơn vị làm việc. Hoạt động này sẽ thất bại nếu bất kỳ đơn vị làm việc nào không xác định được yêu cầu liên quan.

ASP_ECD.1-1 Cán bộ thẩm tra phải kiểm tra lệnh về các yêu cầu an toàn để xác nhận việc nhận dạng được tất cả các yêu cầu an toàn mở rộng.

Cán bộ thẩm tra cần kiểm tra tất cả các yêu cầu an toàn không được nhận dạng khi các yêu cầu an toàn mở rộng được dựa trên cơ sở các thành phần từ TCVN 8709 hoặc trong báo cáo kỹ thuật này.

ASP_ECD.1-2 Cán bộ thẩm tra phải kiểm tra định nghĩa các thành phần mở rộng để xác nhận việc định nghĩa một thành phần mở rộng cho mỗi yêu cầu an toàn mở rộng.

Cán bộ thẩm tra cần kiểm tra tất cả các yêu cầu an toàn đã được nhận dạng khi các yêu cầu an toàn mở rộng được dựa trên cơ sở các thành phần đã định nghĩa trong định nghĩa thành phần mở rộng.

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

ASP_ECD.1-3 Cán bộ thẩm tra phải kiểm tra định nghĩa các thành phần mở rộng để xác nhận việc miêu tả mỗi thành phần mở rộng liên quan đến các thành phần, các hệ thống và các lớp hiện có trong TCVN 8709 hay trong báo cáo kỹ thuật này.

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

ASP_ECD.1-4 Cán bộ thẩm tra phải kiểm tra định nghĩa các thành phần mở rộng để xác nhận rằng mỗi định nghĩa sử dụng các thành phần, các hệ thống, các lớp và phương pháp trong TCVN 8709 hay trong báo cáo kỹ thuật này như một mẫu trình bày.

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

Nếu một định nghĩa thành phần mở rộng không tuân theo mẫu trình bày của TCVN 8709, điều này sẽ ngăn cản việc áp dụng theo phương pháp này trong việc sử dụng, và đơn vị làm việc này sẽ thất bại. Đơn vị làm việc này cũng sẽ thất bại nếu một thành phần mở rộng được định nghĩa không phù hợp với với mối quan hệ yêu cầu với các thành phần, hệ thống và các lớp đang tồn tại.

ASP_ECD.1-5 Cán bộ thẩm tra phải kiểm tra định nghĩa các thành phần mở rộng để xác nhận rằng mỗi thành phần mở rộng bao gồm các yếu tố khách quan có thể đo lường, như vậy có thể chứng minh được sự phù hợp hay không phù hợp với các yếu tố này.

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

Cán bộ thẩm tra cần quyết định rằng các yêu cầu này dựa trên cơ sở mỗi định nghĩa thành phần mở rộng có thể được đánh giá mà không cần suy xét đến cán bộ thẩm tra theo cách chủ quan.

D.2.6.2.2 Hoạt động ASP_ECD.1.2E

Hoạt động này yêu cầu cán bộ thẩm tra phải chỉ ra rằng không có thành phần mở rộng nào trong định nghĩa các thành phần mở rộng có thể sao chép các thành phần hiện có một cách dễ dàng, và được lập bởi bởi một đơn vị làm việc. Hoạt động này sẽ thất bại nếu bất kỳ đơn vị làm việc nào không xác định được yêu cầu liên quan.

ASP_ECD.1-6 Cán bộ thẩm tra phải xác nhận rằng không có thành phần mở rộng nào có thể thể hiện rõ việc sử dụng các thành phần hiện có.

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

Để thực hiện việc kiểm tra này, cán bộ thẩm tra cần tính đến các thành phần từ TCVN 8709, báo cáo kỹ thuật này, và các thành phần mở rộng khác được định nghĩa trong SPP, bao gồm việc sàng lọc, thay thế và kết hợp thành phần. Không cần thiết phải kiểm tra một cách toàn diện, chỉ cần đủ để phát hiện và không bao gồm những rắc rối không cần thiết, nếu các yêu cầu có thể được hiện rõ bằng việc sử dụng các thành phần khác.

D.2.7 Yêu cầu an toàn (ASP_REQ)

D.2.7.1 Cấu trúc họ

Họ này bao gồm hai thành phần, ASP_REQ.1 các yêu cầu an toàn đã nêu và các yêu cầu an toàn phát sinh ASP_REQ.2.

D.2.7.2 Đánh giá về hoạt động phụ ASP_REQ.1

D.2.7.2.1 Hoạt động ASP_REQ.1.1

Hoạt động này đòi hỏi cán bộ thẩm tra phải kiểm tra báo cáo về các yêu cầu an toàn và hợp lý các yêu cầu an toàn về nội dung và cách trình bày và được lập bởi sáu đơn vị làm việc. Hoạt động này sẽ thất bại nếu bất kỳ đơn vị làm việc nào không xác định được yêu cầu liên quan.

ASP_REQ.1-1 Cán bộ thẩm tra phải kiểm tra báo cáo yêu cầu an toàn để xác nhận rằng nó miêu tả các SSF và các SSA. Các SSF và các SSA có thể được bao hàm trong SPP bằng việc tham chiếu một SPP, PP hoặc gói như đã chỉ rõ.

ASP_REQ.1-2 Cán bộ thẩm tra phải kiểm tra SPP để xác nhận rằng nó miêu tả tất cả các chủ thể, đối tượng, các hoạt động, thuộc tính an toàn, các thực thể bên ngoài và các thuật ngữ khác được sử dụng trong các SSF và các SSA.

Mục tiêu của đơn vị làm việc này nhằm đảm bảo rằng các SFR và SAR được xác định rõ và không có sự hiểu lầm nào có thể xảy ra do các thuật ngữ mơ hồ được đưa ra. Đơn vị làm việc này không nên kiểm tra tới các thái cực, bằng cách buộc người viết SPP phải xác định mỗi từ đơn. Các thuật ngữ có thể được xác định trong báo cáo về yêu cầu an toàn, nhưng cũng có thể được xác định ở bất cứ đâu trong SPP.

ASP_REQ.1-3 Cán bộ thẩm tra phải kiểm tra báo cáo về yêu cầu an toàn để xác nhận rằng nó nhận dạng được tất cả các hoạt động trong yêu cầu an toàn.

Có thể đạt được việc nhận dạng qua sự khác nhau khi in, hoặc bằng việc nhận dạng rõ nét trong toàn văn bản, hoặc bằng bất cứ phương tiện đặc biệt khác.

ASP_REQ.1-4 Cán bộ thẩm tra phải kiểm tra báo cáo về yêu cầu an toàn để xác nhận rằng tất cả các hoạt động được thực hiện đúng.

Điều này áp dụng cho các hoạt động sàng lọc, lặp đi lặp lại, tuyển chọn và chuyển nhượng như đã quy định trong TCVN 8709.

ASP_REQ.1-5 Cán bộ thẩm tra phải kiểm tra hợp lý các yêu cầu an toàn để xác nhận rằng mỗi sự lệ thuộc giữa các yêu cầu an toàn được đáp ứng hoặc được biện minh là không đáp ứng yêu cầu.

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

Đây là chức năng duy nhất để phân tích các yêu cầu an toàn đối với thành phần của hệ thống yêu cầu an toàn này. Một danh sách đơn giản chỉ ra rằng cách mỗi sự lệ thuộc được đáp ứng, hoặc xác nhận rõ ràng là nó “không đáp ứng yêu cầu”, đủ để đáp ứng yêu cầu của đơn vị làm việc này: không cần một sự biện minh nào khác.

ASP_REQ.1-6 Cán bộ thẩm tra phải kiểm tra báo cáo về yêu cầu an toàn để xác nhận tính phù hợp.

Cán bộ thẩm tra cần quyết định rằng khi nào các yêu cầu an toàn khác nhau thích hợp với các lớp tương tự về bằng chứng, các sự kiện, hoạt động, dữ liệu, kiểm tra được thực hiện...hoặc “tất cả các đối tượng”, “tất cả các chủ thể”...mà các yêu cầu này không mâu thuẫn.

D.2.7.3 Đánh giá các hoạt động phụ ASP_REQ.2

D.2.7.3.1 Hoạt động ASP_REQ.2.1E

Hoạt động này yêu cầu cán bộ thẩm tra kiểm tra báo cáo về các yêu cầu an toàn và hợp lý các yêu cầu an toàn về nội dung và cách trình bày và được lập bởi 10 đơn vị làm việc, từ ASP_REQ.2-1 đến ASP_REQ.2-10. Các đơn vị làm việc từ ASP_REQ.2-1 đến ASP_REQ.2-4 lần lượt giống với từ ASP_REQ.1-1 đến ASP_REQ.1-4. Đơn vị làm việc ASP_REQ.2-10 giống với đơn vị làm việc ASP_REQ.1-6.

Hoạt động này sẽ thất bại nếu bất kỳ đơn vị làm việc nào không xác định được yêu cầu liên quan.

ASF_REQ.2-5 Cán bộ thẩm tra phải kiểm tra hợp lý các yêu cầu an toàn để xác nhận rằng mỗi sự lệ thuộc giữa các yêu cầu an toàn được đáp ứng hoặc được biện minh là không được đáp ứng yêu cầu.

Đơn vị làm việc này giống hệt với ASP_REQ.1-5 về đặc điểm kỹ thuật. Tuy nhiên, nếu một sự lệ thuộc không được đáp ứng thì việc biện minh cần phải được giải thích, bằng cách tham khảo các đích an toàn hoặc bằng cách khác, nguyên nhân việc lệ thuộc là không cần thiết và không hữu ích.

ASP_REQ.2-6 Cán bộ thẩm tra phải kiểm tra hợp lý các yêu cầu an toàn để xác nhận rằng nó truy vết ngược mỗi SSF ra các đích an toàn chức năng đối với STOE.

Cán bộ thẩm tra cần xác định rằng mỗi truy vết ngược ít nhất một đích an toàn chức năng đối với STOF. Việc truy vết ngược thất bại là do hợp lý yêu cầu an toàn chưa đầy đủ, các đích an toàn đối với STOF chưa đầy đủ hoặc SSF không có mục đích hữu ích.

ASP_REQ.2-7 Cán bộ thẩm tra phải kiểm tra hợp lý các yêu cầu an toàn để xác nhận rằng nó biểu thị các SSF đáp ứng được tất cả các đích an toàn chức năng đối với STOF chưa đáp ứng bởi các hệ thống bên ngoài hoặc các tên miền cá nhân.

Nếu có một đích an toàn chức năng đối với STOF, không có SSF nào truy vết ngược, và đích an toàn chức năng này không được xác định là đã được đáp ứng bởi các hệ thống bên ngoài hoặc tên miền cá nhân, đơn vị làm việc này sẽ thất bại.

Cán bộ thẩm tra cần xác định rằng các SSF là đầy đủ: nếu tất cả các SSF mà truy vết ngược mỗi mục tiêu được đáp ứng, thì đích an toàn chức năng đó đối với STOF hoàn thành.

Cán bộ thẩm tra cũng cần xác định rằng mỗi SSF truy vết ngược một đích an toàn chức năng đối với STOF là cần thiết: khi SSF đáp ứng yêu cầu, nó thực sự góp phần vào việc hoàn thành đích an toàn.

ASP_REQ.2-8 Cán bộ thẩm tra phải kiểm tra hợp lý các yêu cầu an toàn để xác định rằng nó truy vết ngược mỗi SSA ra các đích an toàn đảm bảo đối với STOF.

Cán bộ thẩm tra cần xác định rằng mỗi SSA truy vết ngược ít nhất một đích an toàn đảm bảo đối với STOF. Việc truy vết ngược bị thất bại là do các yêu cầu an toàn hợp lý chưa đầy đủ, các đích an toàn đối với STOF cũng chưa đầy đủ hoặc SSA không có mục đích hữu ích.

ASP_REQ.2-9 Cán bộ thẩm tra phải kiểm tra hợp lý các yêu cầu an toàn để xác nhận rằng nó biểu thị các SSA đáp ứng tất cả các đích an toàn bảo đảm đối với STOE chưa được đáp ứng bởi tên miên cá nhân.

Nếu có một đích an toàn đảm bảo đối với STOF, không có SSA nào truy vết ngược, và đích an toàn này không được xác định là đã được đáp ứng bởi các hệ thống bên ngoài hoặc tên miền cá nhân, đơn vị làm việc này sẽ thất bại.

Cán bộ thẩm tra cần xác định rằng các SSA đầy đủ: nếu tất cả các SSA truy vết ngược mỗi mục tiêu được đáp ứng, đích an toàn đảm bảo đó đối với STOF hoàn thành.

Cán bộ thẩm tra cũng cần xác định rằng mỗi SSA truy vết ngược một đích an toàn đảm bảo đối với STOF là cần thiết: khi SSA đáp ứng, nó thực sự góp phần vào việc hoàn thành đích an toàn.

D.2.8 Giới thiệu miền an toàn (ASP_DMI)

D.2.8.1 Cấu trúc họ

Họ này bao gồm một thành phần, ASP_DMI.1 Giới thiệu miền an toàn.

D.2.8.2 Đánh giá về hoạt động phụ ASP_DMI.1

D.2.8.2.1 Hoạt động ASP_DMI.1.1E

Hoạt động này yêu cầu cán bộ thẩm tra phải kiểm tra từng giới thiệu về nội dung và cách trình bày miền an toàn và được tạo ra bởi năm đơn vị làm việc. Hoạt động này sẽ thất bại nếu như bất cứ đơn vị làm việc nào không xác định được yêu cầu liên quan.

ASP_DMI.1-1 Cán bộ thẩm tra phải xác nhận rằng giới thiệu miền an toàn bao gồm miền an toàn tham chiếu, miền an toàn tổng quan và miền an toàn mô tả.

ASP_DMI.1-2 Cán bộ thẩm tra phải kiểm tra miền an toàn tham chiếu để xác nhận rằng chỉ có nó xác định miền an toàn.

ASP_DMI.1-3 Cán bộ thẩm tra phải kiểm tra miền an toàn tổng quan để xác nhận rằng việc tóm tắt các đặc tính an toàn chính và cách sử dụng miền an toàn.

ASP_DMI.1-4 Cán bộ thẩm tra phải kiểm tra về miền an toàn mô tả để xác nhận rằng nó nhận dạng các phân hệ bao gồm và/hoặc các thành phần.

Việc nhận dạng cần cho phép bất kỳ người đọc Giới thiệu miền an toàn nào để thiết lập mối quan hệ giữa miền an toàn này với các phân hệ/các thành phần, từ đó các hệ thống vận hành phù hợp với SPP phải được xây dựng.

ASP_DMI.1-5 Cán bộ thẩm tra phải kiểm tra việc mô tả miền an toàn để xác nhận việc nhận dạng được các mối quan hệ và các giao diện cho các tên miền khác.

Việc nhận dạng cần cho phép bất kỳ người đọc Giới thiệu miền an toàn nào để thiết lập mối quan hệ giữa miền an toàn này với các miền an toàn khác.

D.2.8.2.2 Hoạt động ASP_DMI.1.2E

Hoạt động này yêu cầu Cán bộ thẩm tra tìm kiếm sự mâu thuẫn trong Giới thiệu miền an toàn và được lập bởi một đơn vị làm việc.

ASP_DMI.1-6 Cán bộ thẩm tra phải xác nhận rằng miền an toàn tham chiếu, miền an toàn tổng quan và miền an mô tả toàn là phù hợp với nhau và phù hợp với giới thiệu SPP.

Cán bộ thẩm tra cần phải nhìn vào mỗi thông số kỹ thuật đến thông tin xác định mà không phù hợp với các báo cáo về thực tế trong các thông số kỹ thuật khác. Ví dụ, nếu thông số kỹ thuật tổ chức miền trong giới thiệu SPP cho rằng tên miền này có hai giao diện cho các tên miền khác, tuy nhiên phần mô tả miền an toàn lại cho rằng có ba giao diện, như vậy sẽ không nhất quán.

D.2.9 Các tuyên bố tuân thủ miền an toàn (ASP_DMC)

D.2.9.1 Cấu trúc Họ

Họ này bao gồm một thành phần, ASP_DMC.1 tuyên bố tuân thủ miền an toàn.

D.2.9.2 Đánh giá hoạt động phụ ASP_DMC.1

D.2.9.2.1 Hoạt động ASP_DMC.1.1E

Hoạt động này yêu cầu Cán bộ thẩm tra kiểm tra từng tuyên bố tuân thủ miền an toàn và hợp lý về nội dung và cách trình bày các yêu cầu về tương thích tên miền và được tạo ra bởi sáu đơn vị làm việc. Hoạt động này sẽ thất bại nếu bất kỳ đơn vị làm việc nào không xác định được yêu cầu liên quan.

ASP_DMC.1-1 Cán bộ thẩm tra phải kiểm tra tuyên bố tuân thủ miền an toàn để xác nhận rằng nó định danh tất cả các SPP, PP và các gói yêu cầu an toàn mà miền an toàn tuyên bố tuân thủ.

Cán bộ thẩm tra cần kiểm tra rằng bất cứ các SPP, các PP và các gói yêu cầu an toàn tham khảo nào đều được xác định một cách rõ ràng, và không có tài liệu tham khảo miêu tả nào về các SPP, các PP và các gói yêu cầu an toàn trong giới thiệu tên miền được liệt kê ở đây.

ASP_DMC.1-2 Cán bộ thẩm tra phải kiểm tra tuyên bố tuân thủ miền an toàn để xác nhận rằng nó miêu tả bất cứ sự tuân thủ nào về tên miền đối với một gói là yêu cầu về tuân thủ gói hoặc gia tăng gói.

Nếu tên miền không tuyên bố tuân thủ đối với bất kỳ gói nào, đơn vị làm việc này sẽ không thể áp dụng và do đó nó được coi là đã đáp ứng yêu cầu. Ngược lại, cán bộ thẩm tra cần kiểm tra việc các SSF và SSA được định nghĩa trong SPP phù hợp với các kiểu tuân thủ đã được tuyên bố đối với mỗi gói xác định.

ASP_DMC.1-3 Cán bộ thẩm tra phải kiểm tra lý do tuyên bố tuân thủ miền an toàn để xác nhận rằng nó chứng minh loại STOE phù hợp với loại STOE trong các SPP và các PP đang được tuyên bố tuân thủ.

Nếu tên miền không tuyên bố tuân thủ đối với bất kỳ SPP hay PP nào thì đơn vị làm việc này không thể áp dụng và do đó nó được coi là đã đáp ứng yêu cầu. Để chứng minh về tính nhất quán một mối quan hệ trực tiếp giữa các loại STOE là không cần thiết; chỉ là không có sự mâu thuẫn nào trong các thông tin đã được cung cấp.

ASP_DMC.1-4 Cán bộ thẩm tra phải kiểm tra lý do tuyên bố tuân thủ miền an toàn để xác nhận rằng nó chứng minh là báo cáo định nghĩa về vấn đề an toàn miền an toàn phù hợp với báo cáo định nghĩa về vấn đề an toàn trong các SPP và PP đang được tuyên bố tuân thủ.

Nếu tên miền không tuyên bố tuân thủ bất kỳ SPP hay PP nào thì đơn vị làm việc này sẽ không thể áp dụng và do đó nó được coi là đáp ứng yêu cầu. Nếu một SPP hay PP được tham khảo không có sự định rõ về chính sách an toàn, nó được coi là phù hợp mà không cần kiểm tra thêm.

ASP_DMC.1-5 Cán bộ thẩm tra phải kiểm tra lý do tuyên bố tuân thủ miền an toàn để xác nhận việc chứng minh là báo cáo về các đích an toàn tên miền trong các SPP và PP đang được tuyên bố tuân thủ.

Nếu tên miền không tuyên bố tuân thủ bất kỳ SPP hay PP nào thì đơn vị làm việc này sẽ không thể áp dụng và do đó nó được coi là đáp ứng yêu cầu. Nếu một SPP hay PP được tham khảo không có báo cáo về các đích an toàn, nó được coi là phù hợp mà không cần kiểm tra thêm.

ASP_DMC.1-6 Cán bộ thẩm tra phải kiểm tra lý do tuyên bố tuân thủ miền an toàn để xác nhận việc chứng minh là báo cáo về các yêu cầu an toàn miền an toàn phù hợp với báo cáo về các yêu cầu an toàn trong các SPP, PP và các gói yêu cầu phải tuân theo.

Nếu tên miền không tuyên bố tuân thủ bất kỳ SPP hay PP nào thì đơn vị làm việc này sẽ không thể áp dụng và do đó nó được coi là đã đáp ứng yêu cầu.

D.2.10 Định nghĩa về vấn đề an toàn miền an toàn. (ASP_DMP)

D.2.10.1 Cấu trúc Họ

Họ này bao gồm một thành phần, ASP_DMP.1 Định nghĩa về vấn đề an toàn miền an toàn.

D.2.10.2 Đánh giá hoạt động phụ ASP_DMP.1

D.2.10.2.1 Hoạt động ASP_DMP.1.1E

Hoạt động này yêu cầu cán bộ thẩm tra kiểm tra mỗi định nghĩa về nội dung và cách trình bày về vấn đề an toàn miền an toàn và được tạo ra bởi ba đơn vị làm việc. Hoạt động này sẽ thất bại nếu bất kỳ đơn vị làm việc nào không xác định được yêu cầu liên quan.

ASP_DMP.1-1 Cán bộ thẩm tra phải kiểm tra định nghĩa về vấn đề an toàn miền an toàn để xác nhận rằng nó diễn tả tất cả các rủi ro khác đối với tên miền, và mỗi rủi ro đó được phân loại thành rủi ro có thể chấp nhận hoặc rủi ro không thể chấp nhận được.

Nếu tất cả các đích an toàn xuất phát từ các chính sách, thì không cần có miêu tả về các rủi ro trong tên miền SPD. Trong trường hợp này, đơn vị làm việc này sẽ không thể áp dụng và do đó nó được coi là đã đáp ứng yêu cầu.

Các rủi ro cần được xác định trong đánh giá rủi ro và trong từng rủi ro, sau đó được phân tích và phân loại thành các rủi ro có thể chấp nhận được và rủi ro không thể chấp nhận được.

ASP_DMP.1-2 Cán bộ thẩm tra phải kiểm tra định nghĩa về vấn đề an toàn miền an toàn để xác nhận rằng tất cả các rủi ro không thể chấp nhận được miêu tả trong các thuật ngữ về mối các mối đe dọa và các lỗ hổng và tất cả các mối đe dọa này được miêu tả trong các thuật ngữ về tác nhân của một mối đe dọa tài sản và một hoạt động bất lợi. Nếu tất cả các đích an toàn xuất phát từ các chính sách, hoặc tất cả các rủi ro được phân loại thành các rủi ro có thể chấp nhận được, thì đơn vị làm việc này không thể áp dụng, và do đó nó được coi là đã đáp ứng yêu cầu.

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

ASP_DMP.1-3 Cán bộ thẩm tra phải kiểm tra định nghĩa về vấn đề an toàn miền an toàn để xác nhận rằng nó miêu tả các OSP duy nhất có thể áp dụng cho các tên miền.

Nếu tất cả các đích an toàn xuất phát từ những mối đe dọa, thì miêu tả về các OSP không cần thiết có trong tên miền SPD. Trong trường hợp này, đơn vị làm việc này sẽ không thể áp dụng và do đó nó được coi là đáp ứng yêu cầu.

D.2.11 Các mục tiêu an toàn miền an toàn (ASP_DMO)

D.2.11.1 Cấu trúc Họ

Họ này bao gồm một thành phần, ASP_DMO.1 Mục tiêu về an toàn miền an toàn.

D.2.11.2 Đánh giá hoạt động phụ ASP_DMO.1

D.2.11.2.1 Hoạt động ASP_DMO.1.1E

Hoạt động này yêu cầu Cán bộ thẩm tra kiểm tra mỗi báo cáo về các các mục tiêu an toàn miền an toàn và hợp lý về nội dung và cách trình bày các mục tiêu an toàn miền an toàn và được tạo ra bởi chín đơn vị làm việc. Hoạt động này sẽ thất bại nếu bất kỳ đơn vị làm việc nào không xác nhận yêu cầu liên quan.

ASP_DMO.1-1 Cán bộ thẩm tra phải kiểm tra báo cáo về các mục tiêu an toàn miền an toàn để xác nhận rằng nó miêu tả về các mục tiêu an toàn chức năng duy nhất cho các tên miền.

Nếu không có mục tiêu an toàn chức năng cho các tên miền thì đơn vị làm việc này không thể áp dụng, và do đó nó được coi là đáp ứng yêu cầu.

ASP_DMO.1-2 Cán bộ thẩm tra phải kiểm tra báo cáo về các mục tiêu an toàn miền an toàn để xác nhận rằng nó miêu tả về bất cứ mục tiêu an toàn chức năng nào mà được đáp ứng bởi các tên miền khác hoặc các hệ thống vận hành bên ngoài.

Nếu không có các mục tiêu an toàn chức năng được đáp ứng bởi các tên miền khác hoặc các hệ thống vận hành bên ngoài thì đơn vị làm việc này không thể áp dụng, và do đó nó được coi là đáp ứng yêu cầu.

Cán bộ thẩm tra cần kiểm tra rằng các mục tiêu an toàn chức năng được đáp ứng bởi các tên miền khác được miêu tả trong các báo cáo về các mục tiêu an toàn miền an toàn cho các tên miền khác như đã được làm hoặc có sẵn cho các tên miền khác.

Các mục tiêu an toàn đáp ứng bởi hệ thống vận hành bên ngoài không được tiếp tục kiểm tra trong đánh giá STOE, nhưng sẽ được kiểm tra trong việc đánh giá SST.

ASP_DMO.1-3 Cán bộ thẩm tra phải kiểm tra báo cáo về các mục tiêu an toàn miền an toàn để xác nhận rằng nó miêu tả về các mục tiêu an toàn đảm bảo riêng cho các tên miền.

Nếu không có các mục tiêu an toàn đảm bảo cho các tên miền, đơn vị làm việc này không được áp dụng, và do đó nó được coi là đã đáp ứng yêu cầu.

ASP_DMO.1-4 Cán bộ thẩm tra phải kiểm tra báo cáo về các mục tiêu an toàn miền an toàn để xác nhận rằng nó miêu tả về các mục tiêu an toàn chức năng cho miền an toàn mà đã có hiệu lực hoặc có sẵn cho các miền khác.

Nếu không có các mục tiêu an toàn chức năng cho miền an toàn thì đơn vị làm việc này không được áp dụng, và do đó nó được coi là đáp ứng yêu cầu.

Nó có thể chấp nhận đối với các mục tiêu được làm hoặc có sẵn cho các tên miền khác hoặc các tên miền khác không sử dụng các mục tiêu đó.

ASP_DMO.1-5 Cán bộ thẩm tra phải kiểm tra hợp lý về các mục tiêu an toàn miền an toàn để xác nhận rằng nó truy mỗi nguyên mục tiêu an toàn chức năng duy nhất cho tên miền ra các rủi ro bị phản bác bởi mục tiêu an toàn và/hoặc các OSP được làm bởi mục tiêu an toàn đó.

Nếu không có các mục tiêu an toàn chức năng cho các miền an toàn thì đơn vị làm việc này không được áp dụng, và do đó nó được coi là đáp ứng yêu cầu.

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

ASP_DMO.1-6 Cán bộ thẩm tra phải kiểm tra nguồn gốc các mục tiêu an toàn miền an toàn để xác nhận rằng nó truy vết ngược mỗi mục tiêu an toàn chức năng duy nhất cho các tên miền khác ra các rủi ro đã bị phản bác bởi mục tiêu an toàn và các OSP đó đã được làm bởi mục tiêu an toàn đó.

Nếu không có các mục tiêu an toàn chức năng cho các tên miền, đơn vị làm việc này không được áp dụng, và do đó nó được coi là đã đáp ứng yêu cầu.

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

ASP_DMO.1-7 Cán bộ thẩm tra phải kiểm tra hợp lý về các các mục tiêu an toàn miền an toàn để xác nhận rằng nó chứng minh là các mục tiêu an toàn chức năng phản bác tất cả các rủi ro không thể chấp nhận duy nhất cho các tên miền này.

Nếu không có các mục tiêu an toàn chức năng và không có rủi ro không thể chấp nhận được nào duy nhất cho tên miền này, đơn vị làm việc này không thể áp dụng, và do đó nó được coi là đáp ứng yêu cầu.

Đối với mỗi rủi ro không thể chấp nhận duy nhất cho tên miền này, Cán bộ thẩm tra cần kiểm tra rằng nếu tất cả các mục tiêu an toàn chức năng truy vết ngược ra rủi ro được hoàn thành, các rủi ro được lớp bỏ, hoặc giảm nhẹ xuống mức có thể chấp nhận được.

Cán bộ thẩm tra cũng xác nhận rằng mỗi mục tiêu an toàn chức năng mà truy vết ngược ra một rủi ro không thể chấp nhận duy nhất cho tên miền là cần thiết: nếu mục tiêu an toàn hoàn thành, nó thực sự góp phần vào việc lớp bỏ hoặc giảm nhẹ rủi ro đó.

Nếu bất cứ rủi ro không thể chấp nhận được duy nhất cho tên miền này, không có mục tiêu an toàn chức năng nào truy vết ngược ra rủi ro đó, đơn vị làm việc này sẽ thất bại.

ASP_DMO.1-8 Cán bộ thẩm tra phải kiểm tra hợp lý về các mục tiêu an toàn miền an toàn để xác nhận rằng nó chứng minh là các mục tiêu an toàn chức năng thực hiện tất cả các OSP duy nhất cho các tên miền.

Nếu không có mục tiêu an toàn chức năng và không có các OSP nào duy nhất cho tên miền, đơn vị làm việc này không thể áp dụng, và do đó nó được coi là đáp ứng yêu cầu.

Đối với mỗi OSP duy nhất cho tên miền, cán bộ thẩm tra cần kiểm tra rằng nếu tất cả các mục tiêu an toàn chức năng truy vết ngược ra OSP đó hoàn thành, OSP được thực thi.

Cán bộ thẩm tra cũng cần xác nhận rằng mỗi mục tiêu an toàn chức năng mà truy vết ngược ra một OSP duy nhất cho tên miền là cần thiết: nếu mục tiêu an toàn hoàn thành, nó thực sự góp phần vào việc tuân theo OSP đó.

Nếu đối với bất kỳ OSP duy nhất cho tên miền, không có mục tiêu an toàn chức năng nào truy vết ngược ra OSP đó thì đơn vị làm việc này sẽ thất bại.

ASP_DMO.1-9 Cán bộ thẩm tra phải kiểm tra hợp lý về các các mục tiêu an toàn miền an toàn để xác nhận rằng nó giải thích tại sao các mục tiêu an toàn đảm bảo duy nhất cho tên miền được chọn.

Nếu không có mục tiêu an toàn đảm bảo duy nhất cho tên miền, đơn vị làm việc này không thể áp dụng, và do đó nó được coi là đáp ứng yêu cầu.

Cán bộ thẩm tra xác nhận lý do tại sao các mục tiêu được chọn. Tuy nhiên, những lý do này không cần phải chứng minh là đúng, và thậm chí có thể được chỉ ra như một lựa chọn độc đoán.

D.2.11.2.2 Hoạt động ASP_DMO.1.2E

Hoạt động này yêu cầu cán bộ thẩm tra tìm kiếm những mâu thuẫn giữa mỗi báo cáo về các mục tiêu an toàn miền an toàn và giới thiệu SPP và được lập bởi từ một đơn vị làm việc.

ASP_DMO.1-8 Cán bộ thẩm tra sẽ xác nhận rằng báo cáo về các mục tiêu an toàn miền an toàn phù hợp với thông số kỹ thuật tổ chức miền.

Cán bộ thẩm tra cần nhìn vào mỗi thông số kỹ thuật rồi xác định thông tin chưa phù hợp với các báo cáo về thực tế trong các thông số kỹ thuật khác. Ví dụ, nếu thông số kỹ thuật tổ chức miền cho rằng tất cả các tên miền là độc lập, tuy nhiên báo cáo về các mục tiêu an toàn miền an toàn lại cho rằng một vài mục tiêu được đáp ứng bởi tên miền khác, điều này là không nhất quán.

D.2.12 Yêu cầu an toàn miền an toàn (ASP_DMR)

D.2.12.1 Cấu trúc Họ

Họ này bao gồm hai thành phần, ASP_DMR.1 Các yêu cầu an toàn miền an toàn đã công bố và ASP_DMR.2 Các yêu cầu an toàn miền an toàn phát sinh.

D.2.12.2 Đánh giá hoạt động phụ ASP_DMR.1

D.2.12.2.1 Hoạt động ASP_DMR.1.1E

Hoạt động này yêu cầu Cán bộ thẩm tra kiểm tra mỗi báo cáo của các yêu cầu an toàn miền an toàn và hợp lý về nội dung và cách trình bày các yêu cầu an toàn miền an toàn và được lập bởi từ sáu đơn vị làm việc. Hoạt động này sẽ thất bại nếu bất kỳ đơn vị làm việc nào không xác nhận yêu cầu liên quan.

ASP_DMR.1-1 Cán bộ thẩm tra phải kiểm tra báo cáo về các yêu cầu an toàn miền an toàn để xác nhận rằng nó chỉ miêu tả các SSA có thể áp dụng cho các tên miền.

Các SSF và SSA có thể được bao gồm trong các thông số kỹ thuật miền bằng việc tham khảo một SPP, PP hoặc gói, cũng như đã được chỉ rõ.

ASP_DMR.1-2 Cán bộ thẩm tra phải kiểm tra SPP để xác nhận rằng nó xác định tất cả các chủ thể, đối tượng, các hoạt động, thuộc tính an toàn, các thực thể bên ngoài và các thuật ngữ khác được sử dụng trong các SSF và các SSA có thể áp dụng cho tên miền.

Mục tiêu của đơn vị làm việc này là nhằm đảm bảo rằng các SFR và SAR được xác định rõ và không có sự hiểu lầm nào có thể xảy ra do các thuật ngữ mơ hồ được đưa ra. Đơn vị làm việc này không nên kiểm tra tới các thái cực, bằng cách buộc người viết SPP phải xác định mỗi từ đơn. Các thuật ngữ có thể được xác định trong báo cáo về yêu cầu an toàn miền, nhưng cũng có thể được xác định ở bất cứ đâu trong SPP.

ASP_DMR.1-3 Cán bộ thẩm tra sẽ phải kiểm tra báo cáo về yêu cầu an toàn miền an toàn nhằm xác nhận rằng chúng sẽ định danh được tất cả các hoạt động về yêu cầu về an toàn.

Việc định danh này có thể đạt được do các nét đặc thù in ấn, hoặc bằng cách xác định rõ ràng theo mạch văn lân cận, hoặc bằng bất kỳ phương tiện duy nhất khác.

ASP_DMR.1-4 Cán bộ thẩm tra sẽ phải kiểm tra báo cáo về các yêu cầu an toàn miền an toàn nhằm xác nhận rằng tất cả các hoạt động được thực hiện một cách chính xác và đúng đắn.

Điều này sẽ áp dụng các quá trình gán, lựa chọn, lặp lại và sàng lọc, như quy định trong bộ tiêu chuẩn TCVN 8709.

ASP_DMR.1-5 Cán bộ thẩm tra sẽ phải kiểm tra báo cáo về các yêu cầu an toàn miền an toàn hợp lý để xác nhận rằng mỗi phần phụ thuộc giữa các yêu cầu về an toàn được thỏa mãn, hoặc điều chỉnh nếu chưa được thỏa mãn.

Một phần phụ thuộc được thỏa mãn do có sự bao hàm của các thành phần liên quan (hoặc một thành phần là thứ bậc với nó) nằm trong báo cáo về các yêu cầu về an toàn miền. Thành phần này được sử dụng nhằm thỏa mãn phần phụ thuộc, nếu cần thiết, sẽ được sửa đổi, điều chỉnh bởi các hoạt động để đảm bảo rằng nó thực sự có thể đáp ứng được phần phụ thuộc đó. Đây là chức năng duy nhất của nhân tố căn bản các yêu cầu về an toàn miền cho thành viên của họ có yêu cầu về an toàn này. Một danh sách đơn giản cho thấy làm thế nào để mỗi phần phụ thuộc được thỏa mãn, hoặc xác định thành phần này một cách rõ ràng là "không thỏa mãn", là đủ để đáp ứng đơn vị làm việc này: không cần sửa đổi hoặc điều chỉnh gì thêm.

ASP_DMR.1-6 Cán bộ thẩm tra phải kiểm tra báo cáo về các yêu cầu an toàn miền an toàn để khẳng định rằng báo cáo có tính nhất quán từ bên trong.

Cán bộ thẩm tra cần xác định rằng trên tất cả các dịp mà các yêu cầu về an toàn khác nhau áp dụng cho cùng một loại bằng chứng của nhà phát triển, các sự kiện, quá trình hoạt động, dữ liệu, việc kiểm thử được thực hiện ...hoặc để "tất cả các đối tượng", "tất cả chủ thể" ..., mà các yêu cầu này không gây ra mâu thuẫn.

D.2.12.3 Đánh giá hoạt động phụ ASP_DMR.2

D.2.12.3.1 Hoạt động ASP_DMR.2.1E

Hoạt động này đòi hỏi cán bộ thẩm tra phải kiểm tra từng báo cáo về các yêu cầu về an toàn miền và các nhân tố cơ bản về yêu cầu về an toàn miền đối với nội dung và việc trình diễn và chúng sẽ cấu thành nên 12 đơn vị làm việc, ASP_DMR.2-1 đến ASP_DMR.2-12. Các đơn vị làm việc ASP_DMR.2-1 đến ASP_DMR.2-4 là giống hệt với ASP_DMR.1-1 đến ASP_DMR.1-4 tương ứng. Đơn vị làm việc ASP_DMR.2-12 giống hệt với đơn vị làm việc ASP_DMR.1-6.

Hoạt động sẽ không đạt nếu có các đơn vị công việc không xác nhận được các yêu cầu liên quan.

ASP_DMR.2-5 Cán bộ thẩm tra phải kiểm tra báo cáo về các yêu cầu an toàn miền an toàn hợp lý để xác nhận rằng mỗi phần phụ thuộc giữa các yêu cầu về an toàn được thỏa mãn, hoặc điều chỉnh nếu chưa được thỏa mãn.

Đơn vị công việc này giống hệt về đặc tính kỹ thuật với ASP_DMR.1-5. Tuy nhiên, nếu một phần phụ thuộc không được thỏa mãn, việc điều chỉnh phải giải thích, bằng việc tham chiếu các mục tiêu an toàn hoặc tiêu chuẩn khác, lý do tại sao phần lệ thuộc không cần thiết hoặc không hữu ích.

ASP_DMR.2-6 Cán bộ thẩm tra phải xem xét nhân tố cơ bản các yêu cầu về an toàn miền để xác nhận chúng theo dõi mỗi SSF ngược về các mục tiêu an toàn chức năng cho các miền.

Nếu không có yêu cầu về an toàn chức năng duy nhất cho các miền, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Cán bộ thẩm tra cần xác định rằng mỗi SSF theo dõi vết ngược về ít nhất một mục tiêu an toàn chức năng cho các miền. Việc không thể theo dõi có nghĩa là một trong hai nhân tố cơ bản yêu cầu về an toàn miền chưa đầy đủ, các mục tiêu an toàn cho các miền chưa đầy đủ, hoặc SSF không có mục đích hữu dụng nào.

ASP_DMR.2-7 Cán bộ thẩm tra phải xem xét nhân tố cơ bản các yêu cầu về an toàn miền để xác nhận rằng chúng chứng minh được rằng các SSF miền đáp ứng tất cả các mục tiêu an toàn chức năng độc đáo cho các miền không được đáp ứng bởi các miền khác hoặc các hệ thống bên ngoài.

Nếu không có các yêu cầu về an toàn chức năng duy nhất và các mục tiêu an toàn chức năng cho các miền, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Nếu có một mục tiêu an toàn chức năng cho các miền, mà không có các SSF theo dõi ngược trở về, và không được đáp ứng bởi các miền khác hoặc các hệ thống bên ngoài, đơn vị làm việc này được coi là không đạt.

Cán bộ thẩm tra cần xác định rằng các SSF phải đủ: nếu tất cả các SSF theo dõi ngược trở lại mỗi từng mục tiêu được thỏa mãn, sau đó mục tiêu an toàn chức năng cho các miền được thực hiện.

Cán bộ thẩm tra cũng nên xác định rằng mỗi SSF mà dấu vết ngược về một mục tiêu an toàn chức năng cho các miền là cần thiết: khi SSF được thỏa mãn, nó thực sự góp phần vào việc đạt được các mục tiêu an toàn.

ASP_DMR.2-8 Cán bộ thẩm tra phải xem xét lý do cơ bản yêu cầu về an toàn miền để khẳng định rằng chúng chứng minh rằng các SSF miền đáp ứng tất cả các mục tiêu an toàn chức năng cho STOE được xác định trong các yêu cầu về an toàn hợp lý cho cả STOE như được đáp ứng bởi các miền đơn.

Nếu không có yêu cầu về an toàn chức năng duy nhất cho miền và không có mục tiêu an toàn chức năng cho toàn bộ STOE được đáp ứng bởi các miền đơn, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Nếu có một mục tiêu an toàn chức năng cho toàn bộ STOE được đáp ứng bởi các miền đơn, mà không có các SSF miền theo dõi ngược trở về, đơn vị làm việc này được coi là không đạt.

Cán bộ thẩm tra cần xác định rằng các SSF phải đủ: nếu tất cả SSF theo dõi ngược trở về từng mục tiêu cho toàn bộ STOE được đáp ứng bởi các miền đơn được thỏa mãn, thì mục tiêu an toàn chức năng cho toàn bộ STOE đã đạt được.

Cán bộ thẩm tra cũng phải xác định rằng mỗi SSF theo dõi ngược trở về mỗi mục tiêu an toàn chức năng cho toàn bộ STOE được đáp ứng bởi các miền đơn là cần thiết: khi SSF được thỏa mãn, nó thực sự góp phần vào việc đạt được các mục tiêu an toàn.

ASP_DMR.2-9 Cán bộ thẩm tra phải xem xét các yêu cầu về an toàn hợp lý để xác nhận rằng chúng theo dõi mỗi SSA ngược trở lại các mục tiêu an toàn đảm bảo cho miền.

Nếu không có các yêu cầu an ninh đảm bảo duy nhất cho miền, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Cán bộ thẩm tra cần xác định rằng mỗi SSA theo dõi ngược trở về ít nhất một mục tiêu an toàn đảm bảo cho miền. Việc không thực hiện theo dõi có nghĩa là một trong hai lý do yêu cầu về an toàn chưa đầy đủ, các mục tiêu an toàn cho các miền chưa đầy đủ, hoặc SSA không có mục đích hữu ích nào.

ASP_DMR.2-10 Cán bộ thẩm tra phải xem xét các yêu cầu về an toàn hợp lý để khẳng định rằng chúng chứng minh rằng các SSA đáp ứng tất cả các mục tiêu an toàn đảm bảo duy nhất cho miền.

Nếu không có yêu cầu về an toàn đảm bảo duy nhất và các mục tiêu an toàn đảm bảo cho các miền, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Nếu có một mục tiêu an toàn đảm bảo cho các miền, mà không có SSA theo dõi ngược trở về, đơn vị làm việc này được coi là không đạt.

Cán bộ thẩm tra cần xác định rằng các SSA phải đủ: nếu tất cả SSA theo dấu ngược về mỗi mục tiêu được thỏa mãn, thì mục tiêu an toàn đảm bảo đó cho các miền được thực hiện.

Cán bộ thẩm tra cũng nên xác định rằng mỗi SSA mà dấu ngược về một mục tiêu an toàn đảm bảo cho các miền là cần thiết: khi SSA được thỏa mãn, nó thực sự góp phần vào việc đạt được các mục tiêu an toàn.

ASP_DMR.2-11 Cán bộ thẩm tra phải xem xét các yêu cầu về an toàn hợp lý để xác nhận rằng chúng chứng minh được rằng các SSA miền đáp ứng tất cả các mục tiêu an toàn đảm bảo cho STOE được xác định trong các yêu cầu an ninh hợp lý cho toàn bộ STOE như được đáp ứng bởi các miền đơn.

Nếu không có yêu cầu về an toàn đảm bảo duy nhất và không có các mục tiêu an toàn đảm bảo cho toàn bộ STOE được đáp ứng bởi các miền đơn, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Nếu có một mục tiêu an toàn đảm bảo cho toàn bộ STOE được đáp ứng bởi các miền đơn, mà không có các SSA miền theo dõi ngược trở về, đơn vị làm việc này được coi là không đạt.

Cán bộ thẩm tra cần xác định rằng các SSA phải đủ: nếu tất cả SSA mà theo dõi ngược lại từng mục tiêu cho toàn bộ STOE được đáp ứng bởi các miền đơn được thỏa mãn, thì mục tiêu an toàn đảm bảo cho toàn bộ STOE đã đạt được.

Cán bộ thẩm tra cũng nên xác định rằng mỗi SSA theo dõi ngược trở về một mục tiêu an toàn đảm bảo cho toàn bộ STOE là cần thiết: khi SSA được thỏa mãn, nó thực sự góp phần vào việc đạt được các mục tiêu an toàn.

D.3 Lớp ASS: Đánh giá đích An toàn hệ thống

D.3.1 Giới thiệu

Mục đích của lớp Đánh giá đích An toàn hệ thống là nhằm xác nhận rằng một SST là một đặc tả kỹ thuật đầy đủ và nhất quán của các đặc tính an toàn của STOE mà nó đại diện, và nếu nó tham chiếu đến các SPP, PP, hoặc gói tin, thì đó là một sự thuyết minh chính xác của các đặc tả kỹ thuật đó.

Trong lớp này có mười ba nhóm họ, việc xử lý các dạng khác nhau của đặc tả kỹ thuật SST. Sáu họ sau cùng được sử dụng để đánh giá các dạng miền cụ thể của STOE cho mỗi miền trong STOE.

D.3.2 Giới thiệu SST (ASS_INT)

D.3.2.1 Cấu trúc Họ

Họ này chứa một thành phần, ASS_INT.1 giới thiệu SST.

D.3.2.2 Đánh giá hoạt động phụ ASS_INT.1

D.3.2.2.1 Hoạt động ASS_INT.1.1E

Hoạt động này đòi hỏi cán bộ thẩm tra phải xem xét phần giới thiệu SST cho nội dung và trình bày và được tạo thành từ mười một đơn vị làm việc. Hoạt động sẽ không đạt nếu có các đơn vị công việc không xác nhận được các yêu cầu liên quan.

ASS_INT.1-1 Cán bộ thẩm tra phải kiểm tra phần giới thiệu SST phải chứa một tham chiếu SST, một tham chiếu STOE, một phần tổng quan STOE, mô tả STOE và một bản đặc tả kỹ thuật tổ chức miền.

ASS_INT.1-2 Cán bộ thẩm tra phải kiểm tra các tài liệu tham khảo SST để xác nhận rằng chúng nhận diện SST là duy nhất.

ASS_INT.1-3 Cán bộ thẩm tra phải kiểm tra các tài liệu tham khảo STOE để xác nhận rằng chúng nhận diện STOE duy nhất.

Điều này bao gồm việc xác định các phiên bản của STOE phù hợp với phiên bản của STT, nếu có thể tồn tại nhiều hơn một phiên bản.

ASS_INT.1-4 Cán bộ thẩm tra sẽ xem xét tổng quan STOE để xác nhận rằng nó tóm tắt việc sử dụng và các chức năng an toàn chính của STOE.

ASS_INT.1-5 Cán bộ thẩm tra sẽ xem xét tổng quan STOE để xác nhận rằng nó nhận dạng được loại STOE.

Các loại STOE có thể là "hệ thống vận hành", hoặc một số định nghĩa chính xác hơn.

ASS_INT.1-6 Cán bộ thẩm tra sẽ xem xét tổng quan STOE để xác minh mối quan hệ và giao diện cho bất kỳ hệ thống vận hành bên ngoài theo yêu cầu của STOE.

Việc xác định sẽ cho phép bất kỳ người đọc của phần giới thiệu SST thiết lập giao diện hệ thống vận hành bên ngoài nào với STOE và tại sao.

ASS_INT.1-7 Cán bộ thẩm tra trách nhiệm kiểm tra các mô tả STOE để xác nhận rằng chúng mô tả phạm vi vật lý của STOE.

Mô tả nên thiết lập ranh giới vật lý của STOE để chúng được rõ ràng cho dù các đặc tính vật lý duy nhất có phải là một phần của STOE hay không.

ASS_INT.1-7 Cán bộ thẩm tra trách nhiệm kiểm tra các mô tả STOE để xác nhận rằng chúng mô tả phạm vi vật lý của STOE.

Việc mô tả phải thiết lập ranh giới vật lý của STOE để rõ ràng xác định liệu các Tài sản vật chất đặc biệt là một phần của STOE hay không.

ASS_INT.1-8 Cán bộ thẩm tra phải kiểm tra các mô tả STOE để xác nhận rằng chúng mô tả phạm vi logic của STOE.

Việc mô tả nên thiết lập ranh giới hợp lý của STOE để xác định rõ ràng liệu các chức năng hoặc thủ tục đặc thù có phải là một phần của STOE hay không.

ASS_INT.1-9 Cán bộ thẩm tra phải kiểm tra các mô tả STOE để xác nhận rằng chúng xác định được các môi trường phát triển cho STOE, bao gồm bất kỳ đặc điểm đặc biệt của môi trường phát triển miền cá nhân.

Việc mô tả nên xác định những phần đó của sự phát triển STOE diễn ra bên ngoài hệ thống vận hành. Thông thường, hệ thống vận hành bao gồm các sản phẩm được mua vào và các ứng dụng sản xuất bởi các bên bên ngoài, và chúng có thể được tích hợp với nhau trong một môi trường phát triển khác biệt với môi trường hệ thống vận hành.

ASS_INT.1-10 Cán bộ thẩm tra phải kiểm tra các đặc tả kỹ thuật tổ chức miền để xác nhận rằng chúng có thể mô tả việc tổ chức các miền an toàn được xây dựng và việc xác nhận diện phạm vi vật lý của mỗi miền an toàn.

Nếu hệ thống vận hành bao gồm một miền đơn, đơn vị làm việc này được thỏa mãn bởi một thông báo rằng có một miền duy nhất.

ASS_INT.1-11 Cán bộ thẩm tra phải kiểm tra các đặc tả kỹ thuật tổ chức miền để xác nhận rằng đối với từng miền, chúng có thể xác định bất kỳ dịch vụ an toàn được cung cấp bởi miền đó sẵn có cho các miền khác và bất kỳ đặc tính an toàn của miền đó được thi hành trên các miền khác.

Nếu hệ thống vận hành bao gồm một miền đơn, đơn vị làm việc này được thỏa mãn bởi một thông báo rằng có một miền duy nhất.

D.3.2.2.2 Hoạt động ASS_INT.1.2E

Hoạt động này đòi hỏi cán bộ thẩm tra phải tìm sự mâu thuẫn trong phần giới thiệu SST và được tạo thành một đơn vị làm việc. Hoạt động sẽ không đạt nếu đơn vị làm việc không xác nhận các yêu cầu có liên quan.

ASS_INT.1-12 Cán bộ thẩm tra sẽ phải xác nhận rằng các tài liệu tham khảo STOE, tổng quan STOE, mô tả STOE và đặc tả kỹ thuật tổ chức miền phải phù hợp và nhất quán với nhau.

Cán bộ thẩm tra cần xem xét từng hạng mục lần lượt để xác định thông tin đó là không phù hợp với báo cáo thực tế, trong các bộ phận khác. Ví dụ, nếu tổng quan STOE cho thấy rằng hệ thống này có các chức năng kế toán, nhưng các đặc tả kỹ thuật tổ chức miền chỉ định nghĩa các miền xử lý các trang thiết bị văn phòng tự động, điều này sẽ là không phù hợp.

D.3.3 Các tuyên bố tuân thủ phù hợp (ASS_CCL)

D.3.3.1 Cấu trúc Họ

Họ này gồm một thành phần, ASS_CCL.1 Tuyên bố tuân thủ phù hợp.

D.3.3.2 Đánh giá hoạt động phụ ASS_CCL.1

D.3.3.2.1 Hoạt động ASS_CCL.1.1E

Hoạt động này đòi hỏi cán bộ thẩm tra phải kiểm tra tuyên bố tuân thủ và Các tuyên bố tuân thủ hợp lý về nội dung và trình bày và tạo thành một đơn vị làm việc. Hoạt động sẽ không đạt nếu có các đơn vị công việc không xác nhận được các yêu cầu liên quan.

ASS_CCL.1-1 Cán bộ thẩm tra sẽ xem xét tuyên bố tuân thủ để xác nhận rằng chúng có chứa một yêu cầu phù hợp tiêu chí xác định các phiên bản của Báo cáo kỹ thuật này mà SST và STOE yêu cầu sự tương thích.

ASS_CCL.1-2 Cán bộ thẩm tra sẽ xem xét yêu cầu tiêu chí phù hợp để xác nhận rằng chúng mô tả sự tương thích chức năng của SST với báo cáo kỹ thuật này như là một trong hai chức năng hợp quy TR 19.791 hoặc 19.791 TR chức năng mở rộng.

ASS_CCL.1-3 Cán bộ thẩm tra sẽ xem xét tuyên bố tuân thủ tiêu chí để xác nhận rằng chúng có thể mô tả sự tương thích đảm bảo của SST đến báo cáo kỹ thuật này như là một trong hai thích ứng bảo đảm TR 19.791 hoặc 19.791 TR đảm bảo mở rộng.

ASS_CCL.1-4 Cán bộ thẩm tra sẽ phải xem xét tuyên bố tuân thủ các tiêu chí để xác nhận rằng chúng phù hợp với các định nghĩa về thành phần mở rộng.

Nếu các thành phần mở rộng được xác định, thì tuyên bố tuân thủ tiêu chí phải được đảm bảo chức năng mở rộng hoặc đảm bảo mở rộng, hoặc cả hai.

ASS_CCL.1-5 Cán bộ thẩm tra sẽ xem xét tuyên bố tuân thủ để xác nhận rằng có thể xác định tất cả các SPP, PP, ST và các gói yêu cầu về an toàn mà SST yêu cầu sự phù hợp.

Cán bộ thẩm tra cần xác nhận rằng bất kỳ các SPP, PP, ST và các gói yêu cầu về an toàn được tham chiếu được xác định một cách rõ ràng, và rằng không có tài liệu tham khảo mang tính mô tả đối với các SPP, PP, ST hoặc gói yêu cầu về an toàn trong phần giới thiệu STT không được liệt kê ở đây.

ASS_CCL.1-6 Cán bộ thẩm tra sẽ xem xét tuyên bố tuân thủ để xác nhận rằng có thể tả bất kỳ sự phù hợp của SST cho một gói hoặc tương thích gói hoặc bổ sung gói.

Nếu STT không yêu cầu tính tương thích với các gói bất kỳ, đơn vị làm việc này không áp dụng và do đó được coi là thỏa mãn. Nếu không, cán bộ thẩm tra cần phải kiểm tra xem các FFS và SSAs được định nghĩa trong SST phù hợp với các hình thức tương thích được yêu cầu cho mỗi gói được xác định.

ASS_CCL.1-7 Cán bộ thẩm tra phải kiểm tra sự tương thích hợp lý để xác nhận rằng có thể chứng minh rằng các loại STOE là phù hợp với các loại STOE trong các SPP, PP và ST đối với tính tương thích đang được yêu cầu.

Nếu STT không yêu cầu sự tương thích với bất kỳ các SPP, PP hoặc ST, đơn vị làm việc này không áp dụng và do đó được coi là thỏa mãn. Để chứng minh tính nhất quán, một mối quan hệ trực tiếp giữa các loại STOE là không cần thiết; mà chỉ là không có mâu thuẫn trong các thông tin được cung cấp.

ASS_CCL.1-8 Cán bộ thẩm tra trách nhiệm kiểm tra tuyên bố tuân thủ hợp lý để khẳng định rằng có thể chứng minh rằng báo cáo về định nghĩa về các vấn đề an toàn phù hợp với báo cáo định nghĩa an toàn trong các SPP, PP và ST đối với khả năng tương thích đang được yêu cầu.

Nếu STT không tuyên bố tuân thủ với các SPP, PP hoặc ST bất kỳ, đơn vị làm việc này không áp dụng và do đó được coi là thỏa mãn. Nếu một SPP, PP hoặc ST được tham chiếu không có định nghĩa chính sách an toàn, chúng sẽ được coi là phù hợp mà không cần kiểm tra thêm.

ASS_CCL.1-9 Cán bộ thẩm tra phải kiểm tra Các tuyên bố tuân thủ phù hợp nhằm xác nhận rằng chúng có thể chứng minh rằng các thông báo về mục tiêu phù hợp với báo cáo kết quả các mục tiêu trong các SPP, PP và ST đối với khả năng tương thích đang được yêu cầu.

Nếu SST không yêu cầu tính tương thích với bất kỳ các SPP, PP hoặc ST, đơn vị làm việc này không áp dụng và do đó được coi là thỏa mãn. Nếu một SPP, PP hoặc ST được tham chiếu không có thông báo các đích an toàn, chúng được coi là phù hợp mà không cần kiểm tra thêm.

ASS_CCL.1-10 Cán bộ thẩm tra phải kiểm tra Các tuyên bố tuân thủ hợp lý để xác nhận rằng chúng có thể chứng minh báo cáo yêu cầu về an toàn phù hợp với báo cáo kết quả yêu cầu về an toàn trong SPP, PP, ST và các gói tin đối với sự phù hợp đang được yêu cầu.

Nếu STT không tuyên bố tuân thủ với các SPP, PP hoặc ST bất kỳ, đơn vị làm việc này không áp dụng và do đó được coi là thỏa mãn.

Nếu một SST yêu cầu tự tương thích với một PP hoặc ST, lý do cơ bản phải cho thấy rằng OSF được xác định đáp ứng các giả định về môi trường hoạt động trong phần định nghĩa vấn đề an toàn của PP / ST.

D.3.4 Định nghĩa vấn đề an toàn (ASS_SPD)

D.3.4.1 Cấu trúc Họ

Họ này gồm một thành phần, ASS_SPD.1 định nghĩa vấn đề an toàn.

D.3.4.2 Đánh giá hoạt động phụ ASS_SPD.1

D.3.4.2.1 Hoạt động ASS_SPD.1.1E

Hoạt động này đòi hỏi cán bộ thẩm tra phải kiểm tra định nghĩa vấn đề an toàn đối với nội dung và việc trình bày và được tạo thành ba đơn vị làm việc. Hoạt động sẽ không đạt nếu có các đơn vị công việc không xác nhận được các yêu cầu liên quan.

ASS_SPD.1-1 Cán bộ thẩm tra phải kiểm tra định nghĩa vấn đề an toàn để xác nhận rằng chúng có thể mô tả tất cả những rủi ro đối với STOE, và mỗi rủi ro được phân loại là có thể chấp nhận hoặc không chấp nhận được.

Nếu tất cả các đích an toàn được bắt nguồn từ chính sách, không cần thiết phải mô tả rủi ro trong SPD. Trong trường hợp này, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Rủi ro cần được xác định trong đánh giá rủi ro, và mỗi rủi ro sau đó phân tích và phân loại là có thể chấp nhận được hoặc không.

ASS_SPD.1-2 Cán bộ thẩm tra phải kiểm tra định nghĩa vấn đề an toàn để xác nhận rằng tất cả những rủi ro không thể chấp nhận phải được mô tả về các mối đe dọa và các lỗ hổng, và tất cả các mối đe dọa được mô tả về một tác nhân của mối đe dọa, một tài sản, và một hành động bất lợi.

Nếu tất cả các đích an toàn được bắt nguồn từ chính sách, hoặc tất cả các rủi ro được phân loại chấp nhận được, đơn vị làm việc này không được áp dụng, và do đó được coi là đã thỏa mãn.

Tác nhân của mối đe dọa có thể được mô tả bằng các khía cạnh như chuyên môn, nguồn lực, cơ hội và động lực.

ASS_SPD.1-3 Cán bộ thẩm tra phải kiểm tra định nghĩa vấn đề an toàn để xác nhận rằng chúng có thể mô tả các OSP.

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

D.3.5 Đích an toàn (ASS_OBJ)

D.3.5.1 Cấu trúc Họ

Họ này gồm một thành phần, ASS_OBJ.1 Các đích an toàn.

D.3.5.2 Đánh giá hoạt động phụ ASS_OBJ.1

D.3.5.2.1 Hoạt động ASS_OBJ.1.1E

Hoạt động này đòi hỏi cán bộ thẩm tra xem xét báo cáo kết quả các đích an toàn và các đích an toàn hợp lý cho nội dung và việc trình bày và được tạo thành từ tám đơn vị làm việc. Hoạt động sẽ không đạt nếu có các đơn vị công việc không xác nhận được các yêu cầu liên quan.

ASS_OBJ.1-1 Cán bộ thẩm tra sẽ phải xem xét báo cáo các đích an toàn để xác nhận rằng chúng có thể mô tả các đích an toàn chức năng cho STOE.

ASS_OBJ.1-2 Cán bộ thẩm tra sẽ xem xét báo cáo các đích an toàn để xác nhận rằng chúng có thể mô tả bất kỳ đích an toàn chức năng đáp ứng bởi các hệ thống vận hành bên ngoài.

Nếu không có các đích an toàn chức năng được đáp ứng bởi các hệ thống vận hành bên ngoài, đơn vị làm việc này không được áp dụng, và do đó được coi là đã thỏa mãn.

Các đích an toàn được đáp ứng bởi các hệ thống vận hành bên ngoài không được tiếp tục xem xét trong quá trình đánh giá thuế SST, nhưng sẽ được xác nhận trong bất kỳ hoạt động đánh giá STOE nào.

ASS_OBJ.1-3 Cán bộ thẩm tra sẽ phải xem xét báo cáo các đích an toàn để xác nhận rằng chúng có thể mô tả các đích an toàn đảm bảo cho STOE.

ASS_OBJ.1-4 Cán bộ thẩm tra sẽ xem xét các đích an toàn hợp lý để xác nhận rằng chúng có thể theo dõi từng đích an toàn chức năng cho STOE ngược trở lại các rủi ro chống lại bởi các đích an toàn và/ hoặc các OSP được thực thi bởi đích an toàn đó.

Mỗi đích an toàn chức năng cho STOE có thể theo dõi ngược lại các mối đe dọa hoặc các OSP, hoặc sự kết hợp của các mối đe dọa và các OSP, nhưng nó phải theo dõi ngược lại cho ít nhất một mối đe dọa hoặc OSP.

ASS_OBJ.1-5 Cán bộ thẩm tra sẽ phải xem xét các đích an toàn hợp lý để xác nhận rằng nó có thể theo dõi từng đích an toàn chức năng cho các hệ thống vận hành bên ngoài ngược trở lại các rủi ro chống lại bởi đích các an toàn và / hoặc các OSP được thực thi bởi rằng đích an toàn.

Nếu không một đích an toàn chức năng nào được đáp ứng bởi các hệ thống vận hành bên ngoài, đơn vị làm việc này không được áp dụng, và do đó được coi là đã thỏa mãn.

Mỗi đích an toàn cho các hệ thống chức năng hoạt động bên ngoài có thể theo dõi ngược lại mối đe dọa hoặc OSP, hoặc sự kết hợp của các mối đe dọa và OSP, nhưng nó phải theo dõi lại ít nhất một mối đe dọa hoặc OSP.

ASS_OBJ.1-6 Cán bộ thẩm tra sẽ phải xem xét các đích an toàn hợp lý để xác nhận rằng nó có thể chứng minh rằng các đích an toàn chức năng chống lại tất cả những rủi ro không thể chấp nhận

Đối với mỗi rủi ro không thể chấp nhận, cán bộ thẩm tra cần xác nhận rằng nếu tất cả các đích an toàn chức năng theo dõi ngược lại của nguy cơ được thực hiện, nguy cơ sẽ bị loại bỏ, hoặc giảm nhẹ mức chấp nhận được.

Cán bộ thẩm tra cũng phải xác nhận rằng từng đích an toàn chức năng mà theo dõi ngược trở lại một nguy cơ không thể chấp nhận là cần thiết: nếu đích an toàn được thực hiện, nó thực sự góp phần vào việc loại bỏ hoặc giảm thiểu các rủi ro đó.

Nếu đối với bất kỳ rủi ro không thể chấp nhận, không một đích an toàn chức năng nào theo dõi ngược lại nguy cơ đó, đơn vị làm việc này được coi là không đạt.

ASS_OBJ.1-7 Cán bộ thẩm tra sẽ phải xem xét các đích an toàn hợp lý để xác nhận rằng nó có thể chứng minh rằng các đích an toàn chức năng thực thi tất cả các OSP.

Đối với mỗi OSP, cán bộ thẩm tra cần xác nhận rằng nếu tất cả các đích an toàn chức năng theo dõi ngược lại OSP đó được thực hiện, OSP sẽ được thi hành.

Cán bộ thẩm tra cũng xác nhận rằng mỗi đích an toàn chức năng theo dõi ngược lại một OSP là cần thiết: nếu đích an toàn được thực hiện, nó thực sự góp phần vào việc thực thi các OSP đó.

Nếu đối với bất kỳ OSP, không một đích an toàn chức năng nào theo dõi ngược trở lại OSP đó, đơn vị làm việc này được coi là không đạt.

ASS_OBJ.1-8 Cán bộ thẩm tra sẽ xem xét các đích an toàn hợp lý để xác nhận rằng nó có thể giải thích lý do tại sao các đích an toàn đảm bảo đã được lựa chọn.

Cán bộ thẩm tra xác nhận rằng lý do tại sao các đích đã được lựa chọn được đưa ra. Tuy nhiên, những lý do này không cần phải được chứng minh, và thậm chí có thể khai báo là sự lựa chọn tùy ý.

D.3.6 Định nghĩa thành phần mở rộng (ASS_ECD)

D.3.6.1 Cấu trúc Họ

Họ này gồm một thành phần, ASS_ECD.1 Định nghĩa thành phần mở rộng.

D.3.6.2 Đánh giá hoạt động phụ ASS_ECD.1

D.3.6.2.1 Hoạt động ASS_ECD.1.1 E

Hoạt động này đòi hỏi cán bộ thẩm tra phải xem xét báo các yêu cầu về an toàn và định nghĩa các thành phần mở rộng cho nội dung và việc trình bày và được tạo thành từ năm đơn vị làm việc. Hoạt động sẽ không đạt nếu có các đơn vị công việc không xác nhận được các yêu cầu liên quan.

ASS_ECD.1-1 Cán bộ thẩm tra sẽ xem xét báo cáo yêu cầu về an toàn để xác nhận rằng nó có thể xác định tất cả các yêu cầu về an toàn mở rộng.

Cán bộ thẩm tra cần kiểm tra tất cả các yêu cầu về an toàn không được xác định là các yêu cầu về an toàn mở rộng dựa trên các thành phần tử trong TCVN 8709 hoặc Báo cáo kỹ thuật này.

ASS_ECD.1-2 Cán bộ thẩm tra phải kiểm tra định nghĩa các thành phần mở rộng đề xác nhận rằng nó định nghĩa một thành phần mở rộng cho từng yêu cầu về an toàn mở rộng.

Cán bộ thẩm tra cần kiểm tra tất cả các yêu cầu về an toàn được xác định là yêu cầu về an toàn mở rộng dựa trên các thành phần được định nghĩa trong định nghĩa các thành phần mở rộng.

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

ASS_ECD.1-3 Cán bộ thẩm tra phải kiểm tra định nghĩa các thành phần mở rộng để xác nhận rằng chúng mô tả cách mỗi thành phần mở rộng có liên quan đến các thành phần, nhóm họ, và các lớp hiện có trong TCVN 8709 hoặc Báo cáo kỹ thuật này.

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

ASS_ECD.1-4 Cán bộ thẩm tra phải kiểm tra định nghĩa các thành phần mở rộng để xác nhận rằng mỗi định nghĩa sử dụng các thành phần, nhóm họ, lớp, và phương pháp hiện có trong tiêu chuẩn TCVN 8709 hoặc Báo cáo kỹ thuật này như là một mô hình phục vụ cho việc trình bày.

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

Nếu một định nghĩa thành phần mở rộng không theo các mô hình trong TCVN 8709 về việc trình bày theo cách có thể ngăn chặn phương pháp này được áp dụng cho việc sử dụng của nó, đơn vị làm việc này cũng không đạt. Các đơn vị làm việc cũng không đạt nếu một thành phần mở rộng được định nghĩa theo một cách không phù hợp với mối quan hệ được yêu cầu cùng với các thành phần, nhóm họ, và các lớp hiện có.

ASS_ECD.1-5 Cán bộ thẩm tra phải kiểm tra định nghĩa các thành phần mở rộng để xác nhận rằng mỗi thành phần mở rộng bao gồm các yếu tố đo lường được và khách quan mà việc tuân thủ hoặc không tuân thủ các yếu tố này có thể được chứng minh.

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

Cán bộ thẩm tra cần xác định rằng các yêu cầu theo từng định nghĩa thành phần mở rộng có thể được đánh giá mà cần phải đánh giá cán bộ thẩm tra chủ quan.

D.3.6.2.2 Hoạt động ASS_ECD.1.2E

Hoạt động này đòi hỏi cán bộ thẩm tra phải tỏ rõ rằng không có một thành phần mở rộng nào trong định nghĩa các thành phần mở rộng dễ dàng nhân đôi thành phần hiện có, và được tạo thành từ một đơn vị làm việc. Hoạt động không đạt nếu đơn vị làm việc không xác nhận các yêu cầu có liên quan.

ASS_ECD.1-6 Cán bộ thẩm tra sẽ phải xác nhận rằng không có phần mở rộng nào có thể được thể hiện rõ ràng bằng cách sử dụng các thành phần hiện có.

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

Trong việc thực hiện kiểm tra này, cán bộ thẩm tra cần chú tâm vào các thành phần trong TCVN 8709, Báo cáo kỹ thuật này, và các thành phần mở rộng khác quy định tại các SST, bao gồm các cải tiến, thay thế và sự kết hợp của các thành phần. Việc kiểm tra không nhất thiết phải đầy đủ mọi khía cạnh mà chỉ đủ để phát hiện và loại trừ rắc rối không cần thiết, nếu các yêu cầu có thể được thể hiện rõ ràng bằng cách sử dụng các thành phần khác.

D.3.7 Các yêu cầu về an toàn (ASS_REQ)

D.3.7.1 Cấu trúc Họ

Họ này có chứa hai thành phần, ASS_REQ.1 Các yêu cầu về an toàn được thông báo và ASS_REQ.2 Các yêu cầu về an toàn phái sinh.

D.3.7.2 Đánh giá hoạt động phụ ASS_REQ.1

D.3.7.2.1 Hoạt động ASS_REQ.1.1E

Hoạt động này đòi hỏi cán bộ thẩm tra xem xét báo cáo yêu cầu về an toàn và các yêu cầu về an toàn hợp lý cho nội dung và việc trình bày và được tạo thành sáu đơn vị làm việc. Hoạt động sẽ không đạt nếu có các đơn vị công việc không xác nhận được các yêu cầu liên quan.

ASS_REQ.1-1 Cán bộ thẩm tra sẽ phải xem xét báo cáo yêu cầu về an toàn để xác nhận rằng chúng có thể mô tả các SSF và SSA.

Các FFS và SSAS có thể được bao gồm trong SST bằng cách tham chiếu đến một SPP, PP, ST hoặc gói như được khai báo rõ ràng.

ASS_REQ.1-2 Cán bộ thẩm tra phải kiểm tra SST để xác nhận rằng nó có thể xác định tất cả các chủ thể, các đối tượng, hoạt động, thuộc tính an toàn, các thực thể bên ngoài và các điều kiện khác được sử dụng trong các SSF và SSA.

Đích của đơn vị làm việc này là để đảm bảo rằng các SFR và SAR được xác định rõ ràng và không có sự hiểu lầm có thể xảy ra do sự giới thiệu của các điều kiện mơ hồ. Đơn vị làm việc này không cần phải xem xét thái quá, bằng cách buộc các bộ ghi SST xác định tất cả các từ đơn lẻ. Điều kiện này có thể được xác định trong báo cáo về yêu cầu về an toàn, nhưng cũng có thể được xác định ở những nơi khác trong SST.

ASS_REQ.1-3 Cán bộ thẩm tra sẽ phải xem xét báo cáo yêu cầu về an toàn để xác nhận rằng chúng xác định tất cả các hoạt động về các yêu cầu về an toàn.

Việc xác định có thể đạt được bằng các nét đặc thù đánh máy, hoặc bằng cách xác định rõ ràng trong các văn bản xung quanh, hoặc bằng bất kỳ phương tiện đặc biệt nào khác.

ASS_REQ.1-4 Cán bộ thẩm tra sẽ phải xem xét báo cáo yêu cầu về an toàn để xác nhận rằng tất cả các hoạt động được thực hiện một cách chính xác.

Điều này áp dụng cho việc gán, lựa chọn, lặp lại và sàng lọc các hoạt động, như quy định trong tiêu chuẩn TCVN 8709.

ASS_REQ.1-5 Cán bộ thẩm tra sẽ phải xem xét các yêu cầu về an toàn hợp lý để xác nhận rằng mỗi phần phụ thuộc giữa yêu cầu về an toàn được thỏa mãn, hoặc phải điều chỉnh hoặc không được thỏa mãn.

Một phần phụ thuộc được thỏa mãn do sự bao hàm các thành phần có liên quan (hoặc một trong đó là thứ bậc với nó) trong báo cáo yêu cầu về an toàn. Các thành phần được sử dụng để đáp ứng phần phụ thuộc, nếu cần thiết, phải được sửa đổi bởi các hoạt động để đảm bảo rằng nó thực sự thỏa mãn phần phụ thuộc đó.

Đây chỉ là chức năng chỉ đối với các yêu cầu về an toàn hợp lý cho thành phần này của nhóm họ yêu cầu về an toàn. Một danh sách đơn giản cho thấy cách mà mỗi phần phụ thuộc được thỏa mãn, hoặc xác định một cách rõ ràng là "không thỏa mãn", là đủ để đáp ứng đơn vị làm việc này: việc căn chỉnh nhiều hơn là không cần thiết.

ASS_REQ.1-6 Cán bộ thẩm tra sẽ phải xem xét báo cáo yêu cầu về an toàn để xác nhận rằng có tính nhất quán từ bên trong.

Cán bộ thẩm tra cần xác định rằng trên tất cả các dịp khi mà các yêu cầu về an toàn khác nhau áp dụng cho cùng một loại bằng chứng của nhà phát triển, các sự kiện, hoạt động, dữ liệu, kiểm tra để được thực hiện... hoặc để "tất cả các đối tượng", "tất cả chủ thể" .... mà các yêu cầu này không gây mâu thuẫn.

D.3.7.3 Đánh giá hoạt động phụ ASS_REQ.2

D.3.7.3.1 Hoạt động ASS_REQ.2.1E

Hoạt động này đòi hỏi cán bộ thẩm tra phải xem xét báo cáo yêu cầu về an toàn và các yêu cầu về an toàn hợp lý cho nội dung và việc trình bày và được tạo thành từ mười đơn vị làm việc, ASS_REQ.2-1 để ASS_REQ.2-10. Đơn vị làm việc ASS_REQ.2-1 đến ASS_REQ.2-4 là tương tự so với ASS_REQ.1-1 đến ASS_REQ.1-4 tương ứng. Đơn vị làm việc ASS_REQ.2-10 giống với đơn vị làm việc ASS_REQ.1-6.

Hoạt động sẽ không đạt nếu có các đơn vị công việc không xác nhận được các yêu cầu liên quan.

Đơn vị công việc này giống hệt về đặc tính kỹ thuật với ASS_REQ.1-5. Tuy nhiên, nếu một phần phụ thuộc không được thỏa mãn, việc điều chỉnh phải giải thích, bằng việc tham chiếu các đích an toàn hoặc tiêu chuẩn khác, lý do tại sao phần lệ thuộc không cần thiết hoặc không hữu ích.

ASS_REQ.2-6 Cán bộ thẩm tra sẽ xem xét các yêu cầu về an toàn hợp lý để xác nhận rằng nó có thể theo dõi mỗi SSF ngược trở lại các đích an toàn chức năng cho STOE.

Cán bộ thẩm tra cần xác định rằng mỗi SSF theo dõi ngược trở lại ít nhất một đích an toàn chức năng cho STOE. Không thực hiện theo dõi có nghĩa là hoặc các yêu cầu về an toàn chưa đầy đủ, các đích an toàn cho STOE chưa đầy đủ, hoặc SSF không có mục đích hữu ích nào.

ASS_REQ.2-7 Cán bộ thẩm tra sẽ phải xem xét các yêu cầu về an toàn hợp lý để xác nhận rằng nó có thể chứng minh rằng các SSF đáp ứng tất cả các đích an toàn chức năng cho STOE không được đáp ứng bởi các hệ thống bên ngoài, miền đơn.

Nếu có một đích an toàn chức năng cho STOE, mà không có một SSF nào theo dõi ngược trở lại, và không được xác định là được đáp ứng bởi hệ thống bên ngoài, miền đơn, đơn vị làm việc này được coi là không đạt.

Cán bộ thẩm tra cần xác định rằng các SSF phải đủ: nếu tất cả các SSF theo dõi ngược trở lại từng mục tiêu được thỏa mãn, thì đích an toàn chức năng cho STOE đã đạt được.

Cán bộ thẩm tra cũng phải xác định rằng mỗi SSF theo dõi ngược trở lại đích an toàn chức năng cho STOE là cần thiết: khi SSF được thỏa mãn, nó thực sự góp phần vào việc đạt được các đích an toàn.

ASS_REQ.2-8 Cán bộ thẩm tra sẽ xem xét các yêu cầu về an toàn hợp lý để xác nhận rằng chúng theo dõi mỗi SSA ngược trở lại các đích an toàn đảm bảo cho STOE.

Cán bộ thẩm tra cần xác định rằng mỗi SSA theo dõi ngược trở lại ít nhất một đích an toàn đảm bảo cho STOE. Việc không thực hiện theo dõi có nghĩa là hoặc các yêu cầu về an toàn chưa đầy đủ, các đích an toàn cho STOE chưa đầy đủ, hoặc SSA không có mục đích hữu ích nào.

ASS_REQ.2-9 Cán bộ thẩm tra sẽ xem xét các yêu cầu về an toàn lý do để khẳng định rằng chúng chứng minh rằng các SSA đáp ứng tất cả các đích an toàn đảm bảo cho STOE không được đáp ứng bởi các miền đơn.

Nếu có một đích an toàn đảm bảo cho STOE, mà không có một SSA nào theo dõi ngược trở lại, và không được xác định là được đáp ứng bởi hệ thống bên ngoài, miền đơn, đơn vị làm việc này được coi là không đạt.

Cán bộ thẩm tra cần xác định rằng các SSA phải đủ: nếu tất cả các SSA theo dõi ngược trở lại từng đích được thỏa mãn, thì đích an toàn chức năng cho STOE đã đạt được.

Cán bộ thẩm tra cũng phải xác định rằng mỗi SSA theo dõi ngược trở lại đích an toàn chức năng cho STOE là cần thiết: khi SSA được thỏa mãn, nó thực sự góp phần vào việc đạt được các đích an toàn.

D.3.8 STOE đặc tả kỹ thuật tóm tắt (ASS_TSS)

D.3.8.1 Cấu trúc Họ

Họ này gồm một thành phần, ASS_TSS.1 STOE đặc tả kỹ thuật tóm tắt.

D.3.8.2 Đánh giá hoạt động phụ ASS_TSS.1

D.3.8.2.1 Hoạt động ASS_TSS.1.1E

Hoạt động này đòi hỏi cán bộ thẩm tra phải kiểm tra các bản đặc tả kỹ thuật tóm tắt STOE cho nội dung và việc trình bày và được tạo thành từ hai đơn vị làm việc. Các hoạt động sẽ không đạt nếu một trong các đơn vị làm việc không xác nhận các yêu cầu có liên quan.

ASS_TSS.1-1 Cán bộ thẩm tra phải kiểm tra các đặc tả kỹ thuật tóm tắt STOE để xác nhận rằng chúng mô tả cách thức STOE đáp ứng mỗi SSF.

Mô tả này được thiết kế như là một cái nhìn tổng quan, và không nên quá chi tiết. Chức năng chính của nó là nhằm xác định trường hợp khi mà các phân hệ khác nhau đạt được SSF tương tự nhưng theo những phương cách khác nhau.

ASS_TSS.1-2 Cán bộ thẩm tra phải kiểm tra các đặc tả kỹ thuật tóm tắt STOE để xác nhận rằng chúng mô tả cách thức STOE đáp ứng mỗi SSA.

Mô tả này được thiết kế như là một cái nhìn tổng quan, và không nên quá chi tiết. Chức năng chính của nó là nhằm xác định trường hợp khi mà các miền khác nhau đạt được SSA tương tự nhưng theo những phương cách khác nhau.

D.3.8.2.2 Hoạt động ASS_TSS.1.2E

Hoạt động này đòi hỏi cán bộ thẩm tra phải xác nhận rằng các đặc tả kỹ thuật tóm tắt STOE phù hợp với các yếu tố mô tả của phần giới thiệu SST. Nó được tạo thành từ một đơn vị làm việc.

ASS_TSS.1-3 Cán bộ thẩm tra sẽ phải xác nhận rằng các đặc tả kỹ thuật tóm tắt STOE là phù hợp với tổng quan STOE và mô tả STOE.

Cán bộ thẩm tra cần xem xét từng đặc tả kỹ thuật lần lượt để xác định thông tin nào không phù hợp với báo cáo thực tế trong các đặc tả kỹ thuật khác. Ví dụ, nếu mô tả STOE khai báo rằng STOE cung cấp dịch vụ truy cập web từ xa, nhưng các đặc tả kỹ thuật tóm tắt STOE chỉ mô tả cơ sở truy cập địa phương, điều này sẽ là không phù hợp và nhất quán.

Cán bộ thẩm tra cũng phải kiểm tra rằng không có chức năng an toàn nào được mô tả trong phần tổng quan STOE mà không có mặt trong các đặc tả kỹ thuật tóm tắt STOE, và do đó có thể truy vết ngược các đích an toàn và định nghĩa các vấn đề an toàn.

D.3.9 Giới thiệu về miền an toàn (ASS_DMI)

D.3.9.1 Cấu trúc Họ

Họ này gồm một thành phần, ASS_DMI.1 Giới thiệu về miền an toàn.

D.3.9.2 Đánh giá hoạt động phụ ASS_DMI.1

D.3.9.2.1 Hoạt động ASS_DMI.1.1E

Hoạt động này đòi hỏi cán bộ thẩm tra phải kiểm tra từng phần giới miền an toàn cho nội dung và việc trình bày và được tạo thành từ năm đơn vị làm việc. Hoạt động sẽ không đạt nếu có các đơn vị công việc không xác nhận được các yêu cầu liên quan.

ASS_DMI.1-1 Cán bộ thẩm tra phải kiểm tra bản giới thiệu miền an toàn bao gồm một bản tham chiếu miền an toàn, một tổng quan về miền an toàn và mô tả miền an toàn.

ASS_DMI.1-2 Cán bộ thẩm tra phải kiểm tra các tài liệu tham khảo miền an toàn để xác nhận rằng chúng xác định miền an toàn một cách duy nhất.

ASS_DMI.1-3 Cán bộ thẩm tra sẽ phải xem xét tổng quan về miền an toàn để xác nhận rằng nó tóm tắt việc sử dụng và các chức năng an toàn quan trọng của miền an toàn.

ASS_DMI.1-4 Cán bộ thẩm tra phải kiểm tra phần mô tả miền an toàn để xác nhận rằng chúng xác định các phân hệ và/hoặc các thành phần bao hàm.

Việc xác định này sẽ cho phép bộ đọc bất kỳ của phần giới thiệu miền an toàn để thiết lập mối quan hệ giữa miền an toàn và các phân hệ / thành phần mà từ đó hệ thống vận hành được xây dựng nên.

ASS_DMI.1-5 Cán bộ thẩm tra phải kiểm tra các mô tả miền an toàn để xác nhận rằng chúng xác định các mối quan hệ và giao diện cho các miền khác.

Việc xác định phải cho phép bộ đọc bất kỳ của phần giới thiệu miền an toàn nhằm thiết lập mối quan hệ giữa miền an toàn và những miền khác.

D.3.9.2.2 Hoạt động ASS_DMI.1.2E

Hoạt động này đòi hỏi cán bộ thẩm tra phải tìm kiếm sự mâu thuẫn trong mỗi phần giới thiệu miền an toàn và được tạo thành từ một đơn vị làm việc.

ASS_DMI.1-6 Cán bộ thẩm tra sẽ phải xác nhận rằng phần tham chiếu miền an toàn, tổng quan miền an toàn và mô tả miền an toàn phù hợp với nhau, và với phần giới thiệu SST.

Cán bộ thẩm tra cần xem xét từng đặc tả kỹ thuật lần lượt để xác định thông tin nào là không phù hợp với báo cáo thực tế trong phần đặc kỹ thuật khác. Ví dụ, nếu các đặc tả kỹ thuật tổ chức miền trong phần giới thiệu SST khai báo rằng miền này có hai giao diện đối với các miền nhưng phân mô tả miền an toàn xác định có ba thì điều này sẽ là không phù hợp và nhất quán.

D.3.10 Tuyên bố tuân thủ miền an toàn (ASS_DMC)

D.3.10.1 Cấu trúc Họ

Họ này gồm một thành phần, ASS_DMC.1 Tuyên bố tuân thủ miền an toàn.

D.3.10.2 Đánh giá hoạt động phụ ASS_DMC.1

D.3.10.2.1 Hoạt động ASS_DMC.1.1E

Hoạt động này đòi hỏi cán bộ thẩm tra phải kiểm tra từng tuyên bố tuân thủ miền và Các tuyên bố tuân thủ miền hợp lý cho nội dung và trình bày và được tạo thành sáu đơn vị làm việc. Hoạt động sẽ không đạt nếu có các đơn vị công việc không xác nhận được các yêu cầu liên quan.

ASS_DMC.1-1 Cán bộ thẩm tra sẽ phải xem xét tuyên bố tuân thủ miền để xác nhận rằng chúng xác định tất cả các SPP, PP, ST và các gói yêu cầu về an toàn mà các miền tuyên bố phù hợp.

Cán bộ thẩm tra cần xác nhận rằng các SPP, PP, ST và các gói yêu cầu về an toàn tham chiếu được xác định một cách rõ ràng, và rằng không có tài liệu tham chiếu có tính mô tả SPP, PP, ST hoặc gói yêu cầu về an toàn trong phần giới thiệu miền không được liệt kê ở đây.

ASS_DMC.1-2 Cán bộ thẩm tra sẽ phải xem xét tuyên bố phù hợp để xác nhận rằng chúng mô tả bất kỳ sự phù hợp của miền đối với một một gói tin như hoặc phù hợp theo gói hoặc gói tăng cường.

Nếu miền không yêu cầu phù hợp với bất kỳ các gói, đơn vị làm việc này không áp dụng và do đó nó được coi là thỏa mãn. Nếu không, cán bộ thẩm tra cần phải kiểm tra xem các SSF và SSA được định nghĩa trong SST phù hợp với các loại hình tương thích được yêu cầu cho mỗi gói được xác định.

ASS_DMC.1-3 Cán bộ thẩm tra phải kiểm tra các tuyên bố phù hợp miền để xác nhận chúng chứng minh rằng các loại STOE là phù hợp với các loại STOE trong các SPP, PP và ST cho sự phù hợp đang được tuyên bố.

Nếu miền không yêu cầu phù hợp với bất kỳ các SPP, PP hoặc ST, đơn vị làm việc này không áp dụng và do đó được coi là thỏa mãn. Để chứng minh tính nhất quán, một mối quan hệ trực tiếp giữa các loại STOE là không cần thiết; mà chỉ không có mâu thuẫn trong các thông tin được cung cấp.

ASS_DMC.1-4 Cán bộ thẩm tra phải kiểm tra các tuyên bố phù hợp miền hợp lý nhằm khẳng định chúng chứng minh được rằng báo cáo định nghĩa vấn đề an toàn phù hợp với báo cáo định nghĩa vấn đề an toàn trong các SPP, PP và ST mà sự phù hợp đang được tuyên bố.

Nếu miền không yêu cầu sự phù hợp đối với bất kỳ các SPP, PP hoặc ST, đơn vị làm việc này không áp dụng và do đó được coi là thỏa mãn. Nếu một SPP, PP hoặc ST được tham chiếu không có định nghĩa chính sách an toàn, chúng được coi là phù hợp mà không cần kiểm tra thêm.

ASS_DMC.1-5 Cán bộ thẩm tra phải kiểm tra các tuyên bố về sự phù hợp miền để khẳng định chúng chứng minh được rằng thông báo các đích an toàn phù hợp với báo cáo các đích trong các SPP, PP và ST khả năng phù hợp đang được tuyên bố.

Nếu miền không yêu cầu tính tương thích với bất kỳ các SPP, PP hoặc ST, đơn vị làm việc này không áp dụng và do đó được coi là thỏa mãn. Nếu một SPP, PP hoặc ST được tham chiếu không có thông báo các đích an toàn, nó được coi là phù hợp mà không cần kiểm tra thêm.

ASS_DMC.1-6 Cán bộ thẩm tra trách phải tra các tuyên bố sự phù hợp miền hợp lý để khẳng định chúng chứng minh được rằng thông báo các yêu cầu về an toàn miền phù hợp với báo cáo yêu cầu về an toàn trong các SPP, PP, ST và các gói mà tính phù hợp đang được tuyên bố.

Nếu miền không yêu cầu phù hợp với bất kỳ các SPP, PP, ST, gói tin, đơn vị làm việc này không áp dụng và do đó được coi là thỏa mãn.

D.3.11 Định nghĩa vấn đề an toàn miền an toàn (ASS_DMP)

D.3.11.1 Cấu trúc Họ

Họ này gồm một thành phần, ASS_DMP.1 Định nghĩa vấn đề an toàn miền an toàn.

D.3.11.2 Đánh giá hoạt động phụ ASS_DMP.1

D.3.11.2.1 Hoạt động ASS_DMP.1.1E

Hoạt động này đòi hỏi cán bộ thẩm tra phải kiểm tra từng định nghĩa vấn đề an toàn miền nội dung và trình bày và được tạo thành từ ba đơn vị làm việc. Hoạt động sẽ không đạt nếu có các đơn vị công việc không xác nhận được các yêu cầu liên quan.

ASS_DMP.1-1 Cán bộ thẩm tra phải kiểm tra các miền định nghĩa vấn đề an toàn miền để xác nhận rằng chúng mô tả được tất cả các rủi ro đặc thù áp dụng cho các miền, và mỗi rủi ro đó được phân loại là hoặc có thể chấp nhận hoặc không chấp nhận được.

Nếu tất cả các đích an toàn được bắt nguồn từ chính sách, thì không cần thiết mô tả các rủi ro trong SPD miền. Trong trường hợp này, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Các rủi ro cần được xác định trong đánh giá rủi ro, và mỗi rủi ro sau đó phân tích và phân loại là hoặc chấp nhận được hoặc không thể chấp nhận.

ASS_DMP.1-2 Cán bộ thẩm tra phải kiểm tra định nghĩa vấn đề an toàn miền để xác nhận rằng tất cả những rủi ro không thể chấp nhận được mô tả về các mối đe dọa và các lỗ hổng, và tất cả các mối đe dọa được mô tả về tác nhân đe dọa, một tài sản, và một hành động bất lợi.

Nếu tất cả các đích an toàn được bắt nguồn từ các chính sách, hoặc tất cả các rủi ro được phân loại là chấp nhận được, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

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

ASS_DMP.1-3 Cán bộ thẩm tra phải kiểm tra định nghĩa vấn đề an toàn miền để xác nhận rằng chúng mô tả các OSP duy nhất áp dụng cho các miền.

Nếu tất cả các đích an toàn được bắt nguồn từ các mối đe dọa, không cần thiết mô tả các OSP trong SPD miền. Trong trường hợp này, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

D.3.12 Đích an toàn miền an toàn (ASS_DMO)

D.3.12.1 Cấu trúc Họ

Họ này gồm một thành phần, ASS_DMO.1 Đích an toàn miền an toàn.

D.3.12.2 Đánh giá hoạt động phụ ASS_DMO.1

D.3.12.2.1 Hoạt động ASS_DMO.1.1E

Hoạt động này đòi hỏi cán bộ thẩm tra phải kiểm tra từng báo cáo các đích an toàn miền và đích an toàn miền hợp lý cho nội dung và trình bày và được tạo thành chín đơn vị làm việc. Hoạt động sẽ không đạt nếu có các đơn vị công việc không xác nhận được các yêu cầu liên quan.

ASS_DMO.1-1 Cán bộ thẩm tra sẽ phải xem xét báo cáo các đích an toàn miền để xác nhận rằng chúng mô tả các đích an toàn chức năng duy nhất cho các miền.

Nếu không có các đích an toàn chức năng nào cho các miền, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

ASS_DMO.1-2 Cán bộ thẩm tra sẽ phải xem xét báo cáo các đích an toàn miền để xác nhận rằng chúng mô tả bất kỳ đích an toàn chức năng đáp ứng bởi các miền khác hoặc các hệ thống vận hành bên ngoài.

Nếu không có đích an toàn chức năng năng đáp ứng các miền khác hoặc các hệ thống vận hành bên ngoài, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Cán bộ thẩm tra cần kiểm tra các đích an toàn chức năng được đáp ứng các miền khác được mô tả trong các báo cáo đích an toàn miền với các miền khác như đang được thực thi trên hoặc có khả dụng cho các miền khác.

Đích an toàn được đáp ứng bởi các hệ thống vận hành bên ngoài không được xem xét trong quá trình đánh giá STOE, nhưng sẽ được xác nhận trong việc đánh giá SST.

ASS_DMO.1-3 Cán bộ thẩm tra sẽ phải xem xét báo cáo các đích an toàn miền để xác nhận rằng chúng mô tả các đích an toàn đảm bảo duy nhất cho miền đó.

Nếu không có đích đảm an toàn đảm bảo cho các miền, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

ASS_DMO.1-4 Cán bộ thẩm tra sẽ phải xem xét báo cáo các đích an toàn miền để xác nhận rằng chúng mô tả bất kỳ đích an toàn chức năng cho miền được thực thi trên hoặc khả dụng cho các miền khác.

Nếu không có các đích an toàn chức năng cho các miền, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Các mục tiêu có thể được chấp nhận để được thực thi trên hoặc khả dụng cho các miền khác mà không có các miền khác sử dụng các mục tiêu này.

ASS_DMO.1-5 Cán bộ thẩm tra sẽ phải xem xét các đích an toàn miền hợp lý để xác nhận rằng chúng theo dõi từng đích an toàn chức năng duy nhất cho các miền ngược trở lại các rủi ro chống lại bởi đích an toàn và / hoặc các OSP được thực thi bởi đích an toàn đó.

Nếu không có đích an toàn chức năng cho các miền, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Mỗi đích an toàn chức năng cho các miền có thể theo dõi ngược lại các mối đe dọa hoặc các OSP, hoặc sự kết hợp của các mối đe dọa và OSP, nhưng nó phải theo dõi lại đối với ít nhất một mối đe dọa hoặc OSP.

ASS_DMO.1-6 Cán bộ thẩm tra sẽ xem xét các đích an toàn miền hợp lý để xác nhận rằng chúng theo dõi từng đích an toàn chức năng duy nhất cho các miền khác ngược trở lại các rủi ro chống lại bởi đích an toàn và OSP được thực thi bởi đích an toàn đó.

Nếu không có đích an toàn chức năng cho các miền khác, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Mỗi đích an toàn chức năng cho các miền khác có thể theo dõi ngược lại các mối đe dọa hoặc các OSP, hoặc sự kết hợp của các mối đe dọa và OSP, nhưng nó phải theo dõi ngược lại cho ít nhất một mối đe dọa hoặc OSP.

ASS_DMO.1-7 Cán bộ thẩm tra sẽ phải xem xét các đích an toàn miền phù hợp để xác nhận chúng chứng minh được rằng các đích an toàn chức năng chống lại tất cả những rủi ro không thể chấp nhận là duy nhất đối với miền.

Nếu không có đích an toàn chức năng và không có rủi ro không thể chấp nhận duy nhất cho miền, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Đối với mỗi rủi ro không thể chấp nhận duy nhất đối với miền, cán bộ thẩm tra cần xác nhận rằng nếu tất cả các đích an toàn chức năng mà theo dõi ngược trở lại của nguy cơ thì đã đạt được, nguy cơ bị loại bỏ, hoặc giảm nhẹ đến mức chấp nhận được.

Cán bộ thẩm tra cũng xác nhận rằng từng đích an toàn chức năng theo dõi ngược lại một nguy cơ không thể chấp nhận duy nhất đối với miền là cần thiết: nếu đích an toàn được thực hiện, nó thực sự góp phần vào việc loại bỏ hoặc giảm thiểu các rủi ro đó.

Nếu vì bất kỳ rủi ro không thể chấp nhận duy nhất cho miền, không có đích an toàn chức năng nào theo dõi ngược lại các rủi ro, đơn vị làm việc này được coi là không đạt.

ASS_DMO.1-8 Cán bộ thẩm tra sẽ xem xét các đích an toàn miền hợp lý để xác nhận rằng chúng chứng minh được rằng các đích an toàn chức năng thực thi tất cả các OSP duy nhất cho miền.

Nếu không có đích an toàn chức năng nào và không có các OSP duy nhất cho miền, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Đối với mỗi OSP duy nhất cho miền, cán bộ thẩm tra cần xác nhận rằng nếu tất cả các đích an toàn chức năng theo dõi ngược trở lại OSP đó được thực hiện, OSP được thực thi.

Cán bộ thẩm tra cũng xác nhận rằng từng đích an toàn chức năng theo dõi ngược trở về một OSP duy nhất cho miền là cần thiết: nếu đích an toàn được thực hiện, nó thực sự góp phần vào việc thực thi các OSP đó.

Nếu vì bất kỳ OSP duy nhất cho miền, không có đích an toàn chức năng theo dõi ngược trở lại OSP đó, đơn vị làm việc này được coi là không đạt.

ASS_DMO.1-9 Cán bộ thẩm tra sẽ xem các đích an toàn miền hợp lý để xác nhận rằng nó giải thích được lý do tại sao các đích an toàn đảm bảo duy nhất cho các miền đã được chọn.

Nếu không có đích an toàn đảm bảo duy nhất cho miền, đơn vị làm việc này không được áp dụng và do đó được coi là thỏa mãn.

Cán bộ thẩm tra xác nhận rằng các lý do tại sao các mục tiêu đã lựa chọn được đưa ra. Tuy nhiên những lý do này không cần phải được chứng minh, và thậm chí có thể nói là sự lựa chọn tùy ý.

D.3.12.2.2 Hoạt động ASS_DMO.1.2E

Hoạt động này đòi hỏi cán bộ thẩm tra phải tìm kiếm sự mâu thuẫn giữa mỗi thông báo các đích an toàn miền và giới thiệu SST và được tạo thành từ một đơn vị làm việc.

ASS_DMO.1-8 Cán bộ thẩm tra sẽ phải xác nhận rằng báo cáo đích an toàn miền là phù hợp với đặc tả kỹ thuật tổ chức miền.

Cán bộ thẩm tra cần xem xét từng đặc tả kỹ thuật lần lượt để xác định thông tin không phù hợp với báo cáo thực tế trong các đặc tả kỹ thuật khác. Ví dụ, nếu các đặc tả kỹ thuật tổ chức miền khai báo rằng tất cả các miền là độc lập, nhưng báo cáo các đích an toàn miền cho thấy một số mục tiêu được đáp ứng bởi các miền khác, điều này sẽ là không nhất quán và phù hợp.

D.3.13 Các yêu cầu về an toàn miền (ASS_DMR)

D.3.13.1 Cấu trúc Họ

Nhóm họ này gồm có hai thành phần, ASS_DMR.1 Các yêu cầu về an toàn miền được khai báo và ASS_DMR.2 Các yêu cầu về an toàn miền phái sinh.

D.3.13.2 Đánh giá hoạt động phụ ASS_DMR.1

D.3.13.2.1 Hoạt động ASS_DMR.1.1E

Hoạt động này đòi hỏi cán bộ thẩm tra phải kiểm tra từng báo cáo các yêu cầu về an toàn miền và các yêu cầu về an toàn miền hợp lý cho nội dung và việc trình bày và được tạo thành sáu đơn vị làm việc. Hoạt động sẽ không đạt nếu có các đơn vị công việc không xác nhận được các yêu cầu liên quan.

ASS_DMR.1-1 Cán bộ thẩm tra sẽ phải xem xét báo cáo yêu cầu về an toàn miền để xác nhận rằng chúng mô tả các SSF duy nhất và SSA áp dụng cho các miền.

Các SSF và SSA có thể được bao hàm trong các đặc tả kỹ thuật miền bằng cách tham chiếu đến một SPP, PP, ST hoặc gói, cũng như được khai báo rõ ràng.

ASS_DMR.1-2 Cán bộ thẩm tra phải kiểm tra SST để xác nhận rằng chúng xác định tất cả các đối tượng, các chủ thể, hoạt động, thuộc tính an toàn, các thực thể bên ngoài và các điều kiện khác được sử dụng trong các SSF duy nhất và SSA áp dụng cho các miền.

Mục tiêu của đơn vị làm việc này là để đảm bảo rằng các SFR miền và SAR được xác định rõ ràng và không có sự hiểu lầm có thể xảy ra do sự giới thiệu các điều kiện mơ hồ. Đơn vị làm việc này không cần cân nhắc thái quá, bằng cách thực thi các bộ ghi SST để xác định mỗi từ đơn lẻ. Điều kiện có thể được xác định trong báo cáo yêu cầu về an toàn miền, nhưng cũng có thể được xác định ở những nơi khác trong SST.

ASS_DMR.1-3 Cán bộ thẩm tra sẽ phải xem xét báo cáo yêu cầu về an toàn miền để xác nhận rằng chúng xác định tất cả các hoạt động trên các yêu cầu về an toàn.

Việc xác định có thể đạt được bằng đặc thù đánh máy, hoặc bằng cách xác định rõ ràng trong các văn bản xung quanh, hoặc bằng bất kỳ phương tiện đặc biệt khác.

ASS_DMR.1-4 Cán bộ thẩm tra sẽ phải xem xét báo cáo yêu cầu về an toàn miền để xác nhận rằng tất cả các hoạt động được thực hiện một cách chính xác.

Điều này áp dụng cho việc gán, lựa chọn, lặp đi lặp lại và sàng lọc các hoạt động, như quy định trong tiêu chuẩn TCVN 8709.

ASS_DMR.1-5 Cán bộ thẩm tra sẽ phải kiểm tra báo cáo về các yêu cầu an toàn miền an toàn hợp lý để xác nhận rằng mỗi phần phụ thuộc giữa các yêu cầu về an toàn được thỏa mãn, hoặc điều chỉnh nếu chưa được thỏa mãn.

Một phần phụ thuộc được thỏa mãn do có sự bao hàm của các thành phần liên quan (hoặc một thành phần là thứ bậc với nó) nằm trong báo cáo về các yêu cầu về an toàn miền. Thành phần này được sử dụng nhằm thỏa mãn phần phụ thuộc, nếu cần thiết, sẽ được sửa đổi, điều chỉnh bởi các hoạt động để đảm bảo rằng nó thực sự có thể đáp ứng được phần phụ thuộc đó. Đây là chức năng duy nhất của nhân tố căn bản các yêu cầu về an toàn miền cho thành viên của họ có yêu cầu về an toàn này. Một danh sách đơn giản cho thấy làm thế nào để mỗi phần phụ thuộc được thỏa mãn, hoặc xác định thành phần này một cách rõ ràng là “không thỏa mãn”, là đủ để đáp ứng đơn vị làm việc này: không cần sửa đổi hoặc điều chỉnh gì thêm.

ASS_DMR.1-6 Cán bộ thẩm tra sẽ phải kiểm tra báo cáo về các yêu cầu về an toàn miền để khẳng định rằng báo cáo có tính nhất quán từ bên trong.

Cán bộ thẩm tra cần xác định rằng trên tất cả các dịp mà các yêu cầu về an toàn khác nhau áp dụng cho cùng một loại bằng chứng của nhà phát triển, các sự kiện, quá trình hoạt động, dữ liệu, việc kiểm thử được thực hiện ...hoặc để "tất cả các đối tượng", "tất cả chủ thể" .... mà các yêu cầu này không gây ra mâu thuẫn.

D.3.13.3 Đánh giá hoạt động phụ ASS_DMR.2

D.3.13.3.1 Hoạt động ASS_DMR.2.1E

Hoạt động này đòi hỏi cán bộ thẩm tra phải kiểm tra từng báo cáo về các yêu cầu về an toàn miền và các nhân tố cơ bản về yêu cầu về an toàn miền đối với nội dung và việc trình diện và chúng sẽ cấu thành nên 12 đơn vị làm việc, ASS_DMR.2-1 đến ASS_DMR.2-12. Các đơn vị làm việc ASP_DMR.2-1 đến ASP_DMR.2-4 là giống hệt với ASP_DMR.1-1 đến ASS_DMR.1-4 tương ứng. Đơn vị làm việc ASS_DMR.2-12 giống hệt với đơn vị làm việc ASS_DMR.1-6.

Hoạt động sẽ không đạt nếu có các đơn vị công việc không xác nhận được các yêu cầu liên quan.

ASS_DMR.2-5 Cán bộ thẩm tra sẽ phải kiểm tra báo cáo về các yêu cầu an toàn miền an toàn hợp lý để xác nhận rằng mỗi phần phụ thuộc giữa các yêu cầu về an toàn được thỏa mãn, hoặc điều chỉnh nếu chưa được thỏa mãn.

Đơn vị công việc này giống hệt về đặc tính kỹ thuật với ASS_DMR.1-5. Tuy nhiên, nếu một phần phụ thuộc không được thỏa mãn, việc điều chỉnh phải giải thích, bằng việc tham chiếu các đích an toàn hoặc tiêu chuẩn khác, lý do tại sao phần lệ thuộc không cần thiết hoặc không hữu ích.

ASS_DMR.2-6 Cán bộ thẩm tra sẽ phải xem xét nhân tố cơ bản các yêu cầu về an toàn miền để xác nhận chúng theo dõi mỗi SSF ngược về các đích an toàn chức năng cho các miền.

Nếu không có yêu cầu về an toàn chức năng duy nhất cho các miền, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Cán bộ thẩm tra cần xác định rằng mỗi SSF theo dõi vết ngược về ít nhất một đích an toàn chức năng cho các miền, việc không thể theo dõi có nghĩa là một trong hai nhân tố cơ bản yêu cầu về an toàn miền chưa đầy đủ, các đích an toàn cho các miền chưa đầy đủ, hoặc SSF không có mục đích hữu dụng nào.

ASS_DMR.2-7 Cán bộ thẩm tra sẽ phải xem xét nhân tố cơ bản các yêu cầu về an toàn miền để xác nhận rằng chúng chứng minh được rằng các SSF miền đáp ứng tất cả các đích an toàn chức năng độc đáo cho các miền không được đáp ứng bởi các miền khác hoặc các hệ thống bên ngoài.

Nếu không có các yêu cầu về an toàn chức năng duy nhất và các đích an toàn chức năng cho các miền, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Nếu có một đích an toàn chức năng cho các miền, mà không có các SSF theo dõi ngược trở về, và không được đáp ứng bởi các miền khác hoặc các hệ thống bên ngoài, đơn vị làm việc này được coi là không đạt.

Cán bộ thẩm tra cần xác định rằng các SSF phải đủ: nếu tất cả các SSF theo dõi ngược trở lại mỗi từng mục tiêu được thỏa mãn, sau đó đích an toàn chức năng cho các miền được thực hiện.

Cán bộ thẩm tra cũng nên xác định rằng mỗi SSF mà dấu vết ngược về một đích an toàn chức năng cho các miền là cần thiết: khi SSF được thỏa mãn, nó thực sự góp phần vào việc đạt được các đích an toàn.

ASS_DMR.2-8 Cán bộ thẩm tra sẽ phải xem xét lý do cơ bản yêu cầu về an toàn miền để khẳng định rằng chúng chứng minh rằng các SSF miền đáp ứng tất cả các đích an toàn chức năng cho STOE được xác định trong các yêu cầu về an toàn hợp lý cho cả STOE như được đáp ứng bởi các miền đơn.

Nếu không có yêu cầu về an toàn chức năng duy nhất cho miền và không có đích an toàn chức năng cho toàn bộ STOE được đáp ứng bởi các miền đơn, đơn vị làm việc này không được áp dụng và do đó được coi là thỏa mãn.

Nếu có một đích an toàn chức năng cho toàn bộ STOE được đáp ứng bởi các miền đơn, mà không có các SSF miền theo dõi ngược trở về, đơn vị làm việc này được coi là không đạt.

Cán bộ thẩm tra cần xác định rằng các SSF phải đủ: nếu tất cả SSF theo dõi ngược trở về từng mục tiêu cho toàn bộ STOE được đáp ứng bởi các miền đơn được thỏa mãn, thì đích an toàn chức năng cho toàn bộ STOE đã đạt được.

Cán bộ thẩm tra cũng phải xác định rằng mỗi SSF theo dõi ngược trở về mỗi đích an toàn chức năng cho toàn bộ STOE được đáp ứng bởi các miền đơn là cần thiết: khi SSF được thỏa mãn, nó thực sự góp phần vào việc đạt được các đích an toàn.

ASS_DMR.2-9 Cán bộ thẩm tra sẽ phải xem xét các yêu cầu về an toàn hợp lý để xác nhận rằng chúng theo dõi mỗi SSA ngược trở lại các đích an toàn đảm bảo cho miền.

Nếu không có các yêu cầu an ninh đảm bảo duy nhất cho miền, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Cán bộ thẩm tra cần xác định rằng mỗi SSA theo dõi ngược trở về ít nhất một đích an toàn đảm bảo cho miền. Việc không thực hiện theo dõi có nghĩa là một trong hai lý do yêu cầu về an toàn chưa đầy đủ, các đích an toàn cho các miền chưa đầy đủ, hoặc SSA không có mục đích hữu ích nào.

ASS_DMR.2-10 Cán bộ thẩm tra sẽ phải xem xét các yêu cầu về an toàn hợp lý để khẳng định rằng chúng chứng minh rằng các SSA đáp ứng tất cả các đích an toàn đảm bảo duy nhất cho miền.

Nếu không có yêu cầu về an toàn đảm bảo duy nhất và các đích an toàn đảm bảo cho các miền, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Nếu có một đích an toàn đảm bảo cho các miền, mà không có SSA theo dõi ngược trở về, đơn vị làm việc này được coi là không đạt.

Cán bộ thẩm tra cần xác định rằng các SSA phải đủ: nếu tất cả SSA theo dấu ngược về mỗi mục tiêu được thỏa mãn, thì đích an toàn đảm bảo đó cho các miền được thực hiện.

Cán bộ thẩm tra cũng nên xác định rằng mỗi SSA mà dấu ngược về một đích an toàn đảm bảo cho các miền là cần thiết: khi SSA được thỏa mãn, nó thực sự góp phần vào việc đạt được các đích an toàn.

ASS_DMR.2-11 Cán bộ thẩm tra sẽ phải xem xét các yêu cầu về an toàn hợp lý để xác nhận rằng chúng chứng minh được rằng các SSA miền đáp ứng tất cả các đích an toàn đảm bảo cho STOE được xác định trong các yêu cầu an ninh hợp lý cho toàn bộ STOE như được đáp ứng bởi các miền đơn.

Nếu không có yêu cầu về an toàn đảm bảo duy nhất và không có các đích an toàn đảm bảo cho toàn bộ STOE được đáp ứng bởi các miền đơn, đơn vị làm việc này không được áp dụng, và do đó được coi là thỏa mãn.

Nếu có một đích an toàn đảm bảo cho toàn bộ STOE được đáp ứng bởi các miền đơn, mà không có các SSA miền theo dõi ngược trở về, đơn vị làm việc này được coi là không đạt.

Cán bộ thẩm tra cần xác định rằng các SSA phải đủ: nếu tất cả SSA mà theo dõi ngược lại từng mục tiêu cho toàn bộ STOE được đáp ứng bởi các miền đơn được thỏa mãn, thì đích an toàn đảm bảo cho toàn bộ STOE đã đạt được.

Cán bộ thẩm tra cũng nên xác định rằng mỗi SSA theo dõi ngược trở về một đích an toàn đảm bảo cho toàn bộ STOE là cần thiết: khi SSA được thỏa mãn, nó thực sự góp phần vào việc đạt được các đích an toàn.

D.3.14 Đặc tả tóm tắt miền an toàn (ASS_DMS)

D.3.14.1 Cấu trúc Họ

Họ này gồm một thành phần, ASS_DMS.1 Đặc tả tóm tắt miền an toàn.

D.3.14.2 Đánh giá hoạt động phụ ASS_DMS.1

D.3.14.2.1 Hoạt động ASS_DMS.1.1E

Hoạt động này đòi hỏi cán bộ thẩm tra phải kiểm tra các bản đặc tả tóm tắt miền an toàn cho nội dung và việc trình bày và được tạo thành từ hai đơn vị làm việc. Các hoạt động sẽ không đạt nếu một trong các đơn vị làm việc không xác nhận các yêu cầu có liên quan.

ASS_DMS.1-1 Cán bộ thẩm tra phải kiểm tra các đặc tả tóm tắt miền an toàn để xác nhận rằng chúng mô tả cách thức STOE đáp ứng mỗi SSF.

ASS_DMS.1-2 Cán bộ thẩm tra phải kiểm tra các đặc tả tóm tắt miền an toàn để xác nhận rằng chúng mô tả cách thức STOE đáp ứng mỗi SSA.

Mô tả này được thiết kế như là một cái nhìn tổng quan, và không nên quá chi tiết. Chức năng chính của nó là nhằm xác định những phương cách an toàn miền duy nhất.

D.3.14.2.2 Hoạt động ASS_DMS.1.2E

Hoạt động này đòi hỏi cán bộ thẩm tra phải xác nhận rằng các đặc tả tóm tắt miền an toàn phù hợp với các yếu tố mô tả của phần giới thiệu miền. Nó được tạo thành từ một đơn vị làm việc.

ASS_DMS.1-3 Cán bộ thẩm tra sẽ phải xác nhận rằng các đặc tả tóm tắt miền an toàn là phù hợp với tổng quan miền và mô tả miền.

Cán bộ thẩm tra cần xem xét từng đặc tả kỹ thuật lần lượt để xác định thông tin nào không phù hợp với báo cáo thực tế trong các đặc tả kỹ thuật khác. Ví dụ, nếu mô tả miền khai báo rằng STOE cung cấp dịch vụ truy cập web từ xa, nhưng các đặc tả tóm tắt miền an toàn chỉ mô tả cơ sở truy cập địa phương, điều này sẽ là không phù hợp và nhất quán.

Cán bộ thẩm tra cũng phải kiểm tra rằng không có chức năng an toàn nào được mô tả trong phần tổng quan miền mà không có mặt trong các đặc tả tóm tắt miền an toàn an toàn, và do đó có thể truy vết ngược các đích an toàn và định nghĩa các vấn đề an toàn miền.

D.4 Lớp AOD: Tài liệu hướng dẫn hệ thống vận hành

D.4.1 Giới thiệu

Mục đích của lớp tài liệu hướng dẫn hệ thống hoạt động là nhằm đánh giá sự phù hợp của tài liệu mô tả sự tích hợp và sử dụng hoạt động của hệ thống vận hành.

Có ba nhóm họ trong lớp này, xử lý việc cấu hình hóa và tài liệu hướng dẫn hoạt động, và xác minh tài liệu vẫn còn được áp dụng sau khi điều chỉnh hệ thống.

D.4.2 Đặc tả kỹ thuật hệ thống vận hành (AOD_OCD)

D.4.2.1 Cấu trúc Họ

Nhóm họ này có chứa hai thành phần phân cấp, AOD_OCD.1 Đặc tả cấu hình hệ thống vận hành, và AOD_OC5.2 Xác minh Đặc tả cấu hình hệ thống vận hành.

D.4.2.2 Đánh giá hoạt động phụ AOD_OCD.1

D.4.2.2.1 Hoạt động AOD_OCD.1.1E

Hoạt động này đòi hỏi cán bộ thẩm tra phải kiểm tra các Đặc tả cấu hình cho nội dung và trình bày và được tạo thành trong bảy đơn vị làm việc. Hoạt động sẽ không đạt nếu có các đơn vị công việc không xác nhận được các yêu cầu liên quan.

AOD_OCD.1-1 Cán bộ thẩm tra phải kiểm tra các Đặc tả cấu hình để xác nhận rằng chúng mô tả tất cả các yêu cầu cấu hình tương đương so với STOE bao gồm cả môi trường hoạt động của nó.

AOD_OCD.1-2 Cán bộ thẩm tra phải kiểm tra các Đặc tả cấu hình để xác nhận rằng chúng mô tả các thông số cấu hình an toàn khả dụng cho các nhà tích hợp hệ thống hoặc người dùng/ quản trị viên tương đương của STOE với vai trò và trách nhiệm.

AOD_OCD.1-3 Cán bộ thẩm tra phải kiểm tra các Đặc tả cấu hình để xác nhận rằng nó có thể xác định tất cả các chế độ hoạt động khả dĩ của STOE (bao gồm cả hoạt động sau khi sự cố hoặc lỗi hoạt động), hậu quả và tác động đối với việc duy trì hoạt động an toàn của chúng.

AOD_OCD.1-4 Cán bộ thẩm tra phải kiểm tra các Đặc tả cấu hình để xác nhận rằng nó có chứa những cảnh báo về các chức năng cấu hình có thể truy cập và đặc quyền đó phải được kiểm soát trong một môi trường xử lý an toàn.

AOD_OCD.1-5 Cán bộ thẩm tra phải kiểm tra các Đặc tả cấu hình để xác nhận rằng nó trình bày rõ ràng mọi trách nhiệm liên quan đến cấu hình cần thiết cho hoạt động an toàn của STOE, bao gồm cả các phần phụ thuộc vào hệ thống vận hành bên ngoài.

AOD_OCD.1-6 Cán bộ thẩm tra phải kiểm tra các Đặc tả cấu hình để xác nhận rằng nó phù hợp với các khái niệm an toàn hoạt động.

AOD_OCD.1-7 Cán bộ thẩm tra phải kiểm tra các Đặc tả cấu hình để xác nhận rằng chúng cho thấy tất cả các thông số an toàn thành phần theo yêu cầu của khái niệm an toàn hoạt động được thực hiện bởi các thiết kế thành phần.

Để hoàn thành đơn vị làm việc này, cán bộ thẩm tra nên thực hiện một chuyển tác hoàn chỉnh thông qua khái niệm an toàn hoạt động để liệt kê tất cả các hoạt động cấu hình hoạt động được xác định là cần thiết bởi các khái niệm về hoạt động. Cán bộ thẩm tra sau đó nên kiểm tra xem chúng đã được mô tả trong các Đặc tả cấu hình hay chưa. Cán bộ thẩm tra có thể cần phải tham khảo các thiết kế thành phần để thiết lập cách các thông số được thực hiện để xác định việc mô tả tương ứng.

D.4.2.3 Đánh giá hoạt động phụ AOD_OCD.2

D.4.2.3.1 Hoạt động AOD_OCD.2.1E

Hoạt động này đòi hỏi cán bộ thẩm tra phải kiểm tra các Đặc tả cấu hình cho nội dung và trình bày và được tạo thành trong bảy đơn vị làm việc, AOD_OCD.2-1 đến AOD_OCD.2-7. Những cái này giống hệt với AOD_OCD.1-1 đến AOD_OCD.1-7 tương ứng.

D.4.2.3.2 Hoạt động AOD_OCD.2.2E

Hành động này đòi hỏi cán bộ thẩm tra phải lập lại một cách độc lập tất cả các thủ tục đặt cấu hình và được tạo thành từ một đơn vị làm việc.

AOD_OCD.2-8 Cán bộ thẩm tra sẽ phải lặp lại tất cả các thủ tục đặt cấu hình và cài đặt để xác nhận rằng STOE có thể được cấu hình hóa và sử dụng một cách an toàn chỉ bằng cách sử dụng các Đặc tả thiết lập cấu hình được cung cấp.

Đơn vị làm việc này được giới hạn các thủ tục đó được áp dụng cho hệ thống vận hành trong môi trường hoạt động của nó, tức là những yêu cầu trong quá trình sử dụng vận hành (nhưng bao gồm cả việc phục hồi từ các lỗi hệ thống).

Có thể không thực tế để tạo ra tất cả các tình huống lỗi được mô tả bởi các Đặc tả cấu hình để thực hiện các thủ tục phục hồi liên quan. Trong các trường hợp này các thủ tục quy định cần được kiểm tra và thực hiện đến mức có thể.

Hoạt động của cán bộ thẩm tra là không đạt nếu một thủ tục như tài liệu không thể thực hiện vì các bước bị thiếu hoặc không phù hợp với hệ thống thực tế. Nó cũng không đạt nếu việc thực hiện một thủ tục đặt hệ thống vào trạng thái không an toàn mà không cảnh báo rằng đây là trường hợp.

D.4.2.3.3 Hoạt động AOD_OCD.2.3E

Ngày bắt đầu hiệu lực: -

Tình trạng: Còn hiệu lực

Đăng bởi Vanbanphapluat

Xin mời bạn đăng nhập, đăng ký để xem/thao tác với nội dung này.

Sửa

Theo dõi

Thích

Yêu cầu cập nhật lại

Ý kiến bạn đọc

ĐĂNG KÝ THÀNH VIÊN

Thống kê văn bản

Hệ thống văn bản pháp luật Việt Nam

Cộng đồng chung về văn bản, với cơ sở dữ liệu văn bản lớn; người dùng được phép tự xây dựng, thiết lập trang văn bản riêng cho cá nhân, cơ quan, đơn vị; khi tra cứu một văn bản thì người dùng biết được tình trạng văn bản (văn bản còn hiệu lực hay không còn hiệu lực,…), xem được “Sơ đồ” văn bản để biết được mối liên hệ của văn bản đang xem với các văn bản liên quan và nhiều tiện tính năng, tiện ích khác; người dùng hoàn toàn đượn “MIỄN PHÍ” sử dụng tính năng, tiện ích của website

Đơn vị chủ quản: Công ty Cổ phần luật AZ; Địa chỉ: Quận 1, thành phố Hồ Chí Minh

Tiêu chuẩn quốc gia TCVN 12210:2018 (ISO/IEC TR 19791:2010) về Công nghệ thông tin - Các kỹ thuật an toàn - Đánh giá an toàn hệ thống vận hành