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.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;

...

...

...

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

...

...

...

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).

...

...

...

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

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

Đố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.

...

...

...

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á.

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

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

...

...

...

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ì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.

...

...

...

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".

...

...

...

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.

...

...

...

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.

...

...

...

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ó.

...

...

...

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á.

...

...

...

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.

...

...

...

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á.

...

...

...

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.

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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.

...

...

...

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á.

...

...

...

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.

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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ý

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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

...

...

...

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ả

...

...

...

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.

...

...

...

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

...

...

...

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:

...

...

...

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:

...

...

...

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ủ

...

...

...

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 đó.

...

...

...

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ị;

...

...

...

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.

...

...

...

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.

...

...

...

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.

...

...

...

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

...

...

...

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.

...

...

...

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ả.

...

...

...

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ủ;

...

...

...

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.

...

...

...

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.

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.

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.

...

...

...

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

...

...

...

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.

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

...

...

...

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)

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.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ô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

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.2.8  Các yêu cầu an toàn

...

...

...

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

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.

...

...

...

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.

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.

...

...

...

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.

...

...

...

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ý 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)

...

...

...

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)

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)

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ị đ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)

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ý 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.2

FOS_POL.1

FOS_POL.4

FOS_NET.1

FOA_POL.3

FOM_PRM.2

FOM_INC.1

FOD_INC.1

...