TIÊU CHUẨN QUỐC GIA TCVN 11778-1:2017 (ISO/IEC TR 15443-1:2012) VỀ CÔNG NGHỆ THÔNG TIN – CÁC KỸ THUẬT AN TOÀN – KHUNG CHO ĐẢM BẢO AN TOÀN CÔNG NGHỆ THÔNG TIN – PHẦN 1: GIỚI THIỆU VÀ KHÁI NIỆM
TCVN 11778-1:2017
ISO/IEC TR 15443-1:2012
CÔNG NGHỆ THÔNG TIN – CÁC KỸ THUẬT AN TOÀN – KHUNG CHO ĐẢM BẢO AN TOÀN CÔNG NGHỆ THÔNG TIN – PHẦN 1: GIỚI THIỆU VÀ KHÁI NIỆM
Information technology – Security techniques – Security assurance framework – Part 1: Introduction and concepts
Mục lục
1 Phạm vi áp dụng
2 Tài liệu viện dẫn
3 Thuật ngữ và định nghĩa
4 Các thuật ngữ viết tắt
5 Khái niệm đảm bảo an toàn
5.1 Đảm bảo an toàn
5.2 Sự khác biệt giữa đảm bảo và tính bí mật
5.3 Nhu cầu đảm bảo an toàn
5.4 Đảm bảo an toàn là điều không thể nắm bắt được
5.5 Đảm bảo an toàn nhằm làm giảm rủi ro an toàn
5.6 Đảm bảo an toàn được cung cấp có liên quan đến các nỗ lực đã thực hiện
5.7 Đảm bảo an toàn không cải thiện sản phẩm
5.8 Các bên liên quan đến đảm bảo an toàn
5.9 Phổ biến rộng rãi đảm bảo an toàn
5.10 Các khía cạnh tổ chức của SACA
6 Cấu trúc đảm bảo an toàn
6.1 Đặc tả yêu cầu đảm bảo an toàn
6.2 Các trường hợp đảm bảo an toàn
6.3 Bằng chứng đảm bảo an toàn
6.4 Tuyên bố đảm bảo an toàn
6.5 Luận cứ đảm bảo an toàn
7 Kỹ thuật SACA
7.1 Kỹ thuật
7.2 Lựa chọn kỹ thuật đảm bảo an toàn
8 Phương pháp SACA
8.1 Phương pháp đánh giá sự phù hợp đảm bảo an toàn (SACA)
8.2 Tiếp cận các phương pháp SACA
8.3 Phân tách các giai đoạn vòng đời
8.4 Mối quan hệ giữa các tiêu chí an toàn và phương pháp đánh giá
8.5 Xếp hạng đảm bảo an toàn
8.6 Công cụ SACA
8.7 Kết quả áp dụng các phương pháp SACA
9 CASCO
9.1 Tiêu chuẩn hỗ trợ đánh giá sự phù hợp
10 Mô hình SACA
10.1 Lưu đồ SACA
10.2 Tổ chức đánh giá sự phù hợp SACA
10.3 Ví dụ mẫu về mô hình SACA
11 Các khía cạnh tạo nên sự đảm bảo an toàn
11.1 Phát triển một trường hợp đảm bảo trong một thiết lập thành phần
11.2 Các loại thành phần
11.3 Hoạt động nâng cao
Thư mục tài liệu tham khảo
Lời nói đầu
TCVN 11778-1:2017 hoàn toàn tương đương với tiêu chuẩn ISO/IEC TR 15443-1:2012 Information technology – Security techniques – Security assurance framework – Part 1: Introduction and concepts.
TCVN 11778-1:2017 do Học viện Công nghệ Bưu chính Viễn thông biên soạn, Bộ Thông tin và Truyền thông đề nghị, Tổng cục Tiêu chuẩn Đo lường Chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố.
Lời giới thiệu
Bộ tiêu chuẩn ISO/IEC TR 15443 được xây dựng trên cơ sở xem xét, kiểm tra và đánh giá các phương pháp góp phần đảm bảo các sản phẩm và hệ thống công nghệ thông tin phù hợp với các tiêu chuẩn an toàn từ SC 27 và những tiêu chuẩn khác (ví dụ như SC 21 và SC 21 và ETSI).
Bộ tiêu chuẩn ISO/IEC TR 15443 tập trung vào đảm bảo an toàn thông tin. Các thuộc tính an toàn hệ thống công nghệ thông tin như khả năng sử dụng, khả năng tương tác, chất lượng, độ tin cậy và nhiều thuộc tính khác nằm ngoài phạm vi của bộ tiêu chuẩn này.
Mục tiêu của bộ tiêu chuẩn này là mô tả về chủ đề đảm bảo an toàn, cung cấp các khái niệm cơ bản và trình bày các kỹ thuật đảm bảo an toàn khác nhau. Bộ tiêu chuẩn này cung cấp một khung đưa ra các trường hợp đảm bảo an toàn thích hợp. Khung này cũng cung cấp hướng dẫn cho các chuyên gia an toàn công nghệ thông tin trong việc sử dụng đảm bảo để đạt được tính bí mật mà một giao phẩm được đưa ra đáp ứng các yêu cầu về đảm bảo an toàn công nghệ thông tin. Bộ tiêu chuẩn này nghiên cứu các kỹ thuật đảm bảo an toàn, các phương pháp đảm bảo an toàn được đề xuất bởi nhiều tổ chức.
Bộ tiêu chuẩn bao gồm các nội dung sau:
a) Các thuật ngữ và định nghĩa liên quan đến chủ đề đảm bảo an toàn
b) Các khái niệm cơ bản liên quan đến đảm bảo an toàn
c) Hướng dẫn cho việc lựa chọn, áp dụng, phối hợp và công nhận của các phương pháp đảm bảo
d) Trình bày các thuộc tính chung và thuộc tính riêng biệt của các phương pháp đảm bảo
e) Một khung mẫu để xác định vị trí của phương pháp đảm bảo hiện có và chỉ ra mối quan hệ giữa các phương pháp đó.
ISO/IEC TR 15443 được tổ chức thành hai phần:
Phần 1, TCVN 11778-1:2017 giới thiệu và khái niệm: cung cấp tổng quan về các định nghĩa, khái niệm cơ bản và mô tả chung về đảm bảo an toàn. Phần này nhằm mục đích cung cấp các kiến thức cơ bản cần thiết để sử dụng khung cho việc phân tích được trình bày trong TCVN 11778-2:2017 một cách thích hợp.
Tiêu chuẩn TCVN 11778-1:2017 hướng đến:
a) Trách nhiệm của các cơ quan đảm bảo an toàn đối với các quyết định liên quan đến đảm bảo an toàn của giao phẩm,
b) Trách nhiệm về việc phát triển các giao phẩm cùng chức năng an toàn, đó là nhân viên an toàn, kiến trúc sư an toàn công nghệ thông tin, bên phát triển và bên tích hợp,
c) Cơ quan đảm bảo an toàn chịu trách nhiệm quyết định việc đảm bảo an toàn của giao phẩm, ví dụ, thông qua việc sử dụng phương pháp SACA được cung cấp bởi tiêu chuẩn TCVN ISO/IEC 27001:2009, TCVN 8709:2011 và ISO/IEC 19790. Đối tượng này có thể bao gồm các cơ quan chính phủ, bên cung cấp và bên tích hợp,
d) Khách hàng của đảm bảo an toàn công nghệ thông tin chẳng hạn như bên thu mua và người sử dụng cuối, những người chịu trách nhiệm thu mua hoặc sử dụng các giao phẩm mà đưa ra những công bố về các thuộc tính an toàn của chúng.
Phần 2, TCVN 11778-2:2017 Phân tích: mô tả khung mẫu đảm bảo an toàn có thể được sử dụng để đánh giá một số phương pháp đảm bảo và phương pháp tiếp cận. Quan trọng ở đây là xác định thuộc tính chất lượng của các phương pháp đảm bảo an toàn góp phần đảm bảo an toàn. Phần này phục vụ cho chuyên gia an toàn công nghệ thông tin, cung cấp cách thức để đạt được các đảm bảo an toàn trong giai đoạn vòng đời của giao phẩm.
TCVN 11778-2:2017 có liên quan tới phương pháp đảm bảo an toàn có thể không là duy nhất đối với an toàn công nghệ thông tin, tuy nhiên hướng dẫn được đưa ra trong bộ tiêu chuẩn này sẽ được giới hạn cho yêu cầu an toàn công nghệ thông tin.
CÔNG NGHỆ THÔNG TIN – CÁC KỸ THUẬT AN TOÀN – KHUNG CHO ĐẢM BẢO AN TOÀN CÔNG NGHỆ THÔNG TIN – PHẦN 1: GIỚI THIỆU VÀ KHÁI NIỆM
Information technology – Security techniques – Security assurance framework – Part 1: Introduction and concepts
1 Phạm vi áp dụng
Tiêu chuẩn này cung cấp các thuật ngữ và thiết lập một tập hợp các khái niệm và mối quan hệ giữa chúng đã được khái quát và tổ chức lại để hiểu rõ về việc đảm bảo an toàn công nghệ thông tin, nhờ đó tạo ra được một cơ sở để chia sẻ hiểu biết về các khái niệm và nguyên tắc trọng tâm của bộ tiêu chuẩn này qua cộng đồng người dùng. Tiêu chuẩn này cũng cung cấp thông tin cơ bản cho người sử dụng của tiêu chuẩn TCVN 11778-2:2017.
2 Tài liệu viện dẫn
Các tài liệu viện dẫn sau rất cần thiết cho việc áp dụng tiêu chuẩn này. Với những tài liệu viện ghi năm ban hành thì áp dụng phiên bản được nêu. Với những tài liệu không ghi rõ ngày tháng, áp dụng lần phiên bản mới nhất (bao gồm tất cả các sửa đổi).
ISO/IEC TR 15026-1:2010 Systems and software engineering – Systems and software assurance – Part 1: Concepts and vocabulary (Kỹ thuật hệ thống và phần mềm – Đảm bảo hệ thống và phần mềm – Phần 1: Khái niệm và từ vựng).
TCVN ISO/IEC 17000:2007 Đánh giá sự phù hợp – Từ vựng và các nguyên tắc chung.
3 Thuật ngữ và định nghĩa
Tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa nêu trong TCVN ISO/IEC 17000:2007, ISO/IEC TR 15026-1:2010 và các thuật ngữ và định nghĩa sau.
CHÚ THÍCH: Việc xác định thuật ngữ cho khung đảm bảo an toàn chung là một nhiệm vụ khó khăn vì nhiều thuật ngữ về đảm bảo an toàn đã được đưa ra để đáp ứng các nhu cầu đảm bảo an toàn cụ thể. Trong nhiều trường hợp, các thuật ngữ tương tự có những định nghĩa khác nhau gây khó khăn để xây dựng một ngôn ngữ chung cho khung đảm bảo an toàn. Các định nghĩa xung đột với nhau và các định nghĩa thuật ngữ trong tiêu chuẩn này sẽ được chỉ ra dưới đây. Đặc biệt, các định nghĩa trong tiêu chuẩn ISO/IEC 17000, ISO/IEC TR 15026, ISO/IEC 15408 phần 1 và bộ tiêu chuẩn ISO/IEC 27000 có thể được đưa ra dưới đây.
3.1
Công nhận (accreditation)
Xác nhận của bên thứ ba đối với tổ chức đánh giá sự phù hợp thể hiện chính thức rằng tổ chức đó có đủ năng lực để tiến hành các kết quả đánh giá sự phù hợp một cách cụ thể.
[TCVN ISO/IEC 17000:2007, Định nghĩa 5.6]
3.2
Công nhận (accreditation)
Tuyên bố chính thức của cơ quan phê duyệt thiết kế về một hệ thống được chấp thuận hoạt động trong một chế độ an toàn cụ thể sử dụng một tập hợp các biện pháp bảo vệ theo quy định.
CHÚ THÍCH 1: định nghĩa về thuật ngữ “công nhận” áp dụng cho tiêu chuẩn này là từ ISO/IEC 17000:2004, điều 5.6.
CHÚ THÍCH 2: chú thích 1 không phải là một phần định nghĩa của ISO/IEC 21827.
[ISO/IEC 21827:2008, Điều 3.2]
3.3
Cơ quan phê chuẩn (approval authority)
Cơ quan phê chuẩn SACA (SACA approval authority)
Cơ quan có thẩm quyền quyết định trường hợp đảm bảo và mức độ đảm bảo mà nó cung cấp là thoả đáng
CHÚ THÍCH 1: Cơ quan phê chuẩn có thể bao gồm nhiều đối tượng, ví dụ các cá nhân hoặc tổ chức. Cơ quan phê chuẩn này có thể bao gồm các đối tượng khác nhau ở các mức độ phê chuẩn khác nhau và/hoặc các lĩnh vực quan tâm khác nhau.
CHÚ THÍCH 2: Trong tình huống có hai bên, cơ quan phê chuẩn thường thuộc về bên thu mua. Trong tình huống về pháp lý, cơ quan phê chuẩn có thể là bên thứ ba như tổ chức chính phủ hoặc đại diện của tổ chức chính phủ. Trong tình huống khác, ví dụ như việc mua bán các sản phẩm trên kệ được phát triển bởi một tổ chức đơn lẻ, sự độc lập của cơ quan phê chuẩn có thể là vấn đề liên quan đến bên thu mua.
[ISO/IEC 15026-1:2010, Điều 2.3]
3.4
Cơ quan phê chuẩn (approval authority)
Bất kỳ tổ chức hay cơ quan quốc gia hoặc quốc tế nào được ủy nhiệm để phê chuẩn và/hoặc đánh giá các chức năng an toàn.
CHÚ THÍCH: Trong ngữ cảnh của định nghĩa này, cơ quan phê chuẩn đánh giá và phê chuẩn các chức năng an toàn dựa trên giá trị mật mã hoặc toán học của chúng, nhưng không phải là cơ quan kiểm tra sẽ kiểm tra sự phù hợp với tiêu chuẩn quốc tế này và tiêu chuẩn ISO/IEC 19790:2006.
[ISO/IEC 19790:2006, Điều 3.1]
3.5
Đánh giá (assessment)
Việc xác minh một sản phẩm, hệ thống hoặc dịch vụ theo một tiêu chuẩn bằng cách sử dụng phương pháp đánh giá tương ứng để thiết lập sự tuân thủ và xác định việc đảm bảo.
[ISO/IEC 21827, Điều 3.3]
3.6
Đảm bảo (assurance)
Căn cứ tin cậy là các yêu cầu tuyên bố đã hoặc sẽ đạt được.
[ISO/IEC TR 15026-1:2010, Điều 2.1]
3.7
Đảm bảo (assurance)
<TCVN 8709> Căn cứ tin cậy là một TOE thỏa mãn các TSF.
[TCVN 8709-1:2011, Điều 3.1.4]
3.8
Cơ quan đảm bảo (assurance authority)
Cá nhân hoặc tổ chức chịu trách nhiệm chỉ rõ các yêu cầu đảm bảo an toàn để đạt được sự đảm bảo.
CHÚ THÍCH: Một cơ quan đảm bảo có thể là cùng một cá nhân hoặc tổ chức như cơ quan phê chuẩn được định nghĩa trong Điều 3.3.
3.9
Trường hợp đảm bảo (assurance case)
Đưa ra một hoặc nhiều tuyên bố và sự hỗ trợ cho các tuyên bố này.
CHÚ THÍCH: Một trường hợp đảm bảo là một giả định có thể kiểm tra được, có tính hợp lý được tạo ra để hỗ trợ luận điểm làm thoả mãn các tuyên bố. Nó bao gồm các điều sau và mối quan hệ của chúng:
– một hay nhiều tuyên bố về các thuộc tính.
– luận cứ về mối liên kết logic giữa các bằng chứng và các giả thuyết với các tuyên bố
– nhóm các bằng chứng và giả thuyết có thể để hỗ trợ những luận cứ cho các tuyên bố
[ISO/IEC TR 15026-1, Điều 2.2]
3.10
Tuyên bố đảm bảo (assurance claim)
Xác nhận hoặc hỗ trợ xác nhận rằng hệ thống đáp ứng nhu cầu an toàn đã đưa ra.
CHÚ THÍCH 1: Các tuyên bố giải quyết các mối đe dọa trực tiếp (ví dụ như dữ liệu hệ thống được bảo vệ khỏi các cuộc tấn công từ bên ngoài) và các mối đe dọa gián tiếp (ví dụ như mã hệ thống có lỗi rất nhỏ).
CHÚ THÍCH 2: So sánh với định nghĩa “tuyên bố” với Điều 3.11.
[ISO/IEC 21827, Điều 3.7]
3.11
Sự chứng nhận (certification)
Xác nhận của bên thứ ba đối với các sản phẩm, quy trình, hệ thống hoặc con người.
CHÚ THÍCH 1: Sự chứng nhận một hệ thống quản lý đôi khi cũng được gọi là sự đăng ký.
CHÚ THÍCH 2: Sự chứng nhận được áp dụng cho tất cả các đối tượng đánh giá sự phù hợp ngoại trừ các tổ chức đánh giá sự phù hợp là các đối tượng của công nhận.
[TCVN ISO/IEC 17000:2005, Điều 5.5]
3.12
Tuyên bố (claim)
Tuyên bố về một vấn đề nào đó là đúng gồm các điều kiện và hạn chế liên quan.
CHÚ THÍCH 1: Phát biểu của một tuyên bố không có nghĩa mục đích hay mong muốn của nó là đúng. Đôi khi, tuyên bố được đưa ra với mục đích đánh giá xem vấn đề đó là đúng hay sai hoặc nỗ lực để thiết lập những cái gì là đúng.
CHÚ THÍCH 2: Một tuyên bố phù hợp với ISO/IEC 15026-2 là tuyên bố rõ ràng về việc xác nhận với bất kỳ điều kiện nào liên quan đưa ra các chi tiết một cách rõ ràng bao gồm cả những hạn chế và không chắc chắn về giá trị. Tuyên bố có thể được dùng cho tương lai, hiện tại hoặc quá khứ.
[ISO/IEC 15026-1:2010, Điều 2.4]
3.13
Lưu đồ đánh giá sự phù hợp (conformity assessment scheme)
Chương trình đánh giá sự phù hợp (conformity assessment programme)
Hệ thống đánh giá sự phù hợp liên quan đến các đối tượng đánh giá sự phù hợp đã xác định, cái mà áp dụng cùng những yêu cầu, quy tắc và thủ tục cụ thể
CHÚ THÍCH: Lưu đồ đánh giá sự phù hợp có thể hoạt động tại cấp độ quốc tế, khu vực, quốc gia hoặc địa phương.
[ISO/IEC 17000:2010, Điều 2.8]
3.14
Giao phẩm (deliverable)
Thành phần, sản phẩm, hệ thống, dịch vụ, quy trình, tổ chức hoặc nhân sự mà có mục tiêu an toàn
CHÚ THÍCH: Ranh giới của giao phẩm có thể là một hoặc nhiều thành phần bao gồm bộ vi xử lý, thiết bị ngoại vi, công nghệ truyền thống, các dịch vụ ngoại vi, môi trường liên quan mà nó hoạt động, quy trình tổ chức liên quan cũng như các thành phần chịu trách nhiệm cho việc phát triển, vận hành, duy trì và sử dụng nó.
3.15
Đánh giá (evaluation)
Việc xác định có hệ thống về mức độ đáp ứng của một thực thể theo tiêu chí quy định.
[ISO/IEC 12207:2007, Điều 4.12]
3.16
Đánh giá (evaluation)
<TCVN 8709> đánh giá một PP, một ST hoặc một TOE dựa vào các tiêu chí đã xác định.
[TCVN 8709-1:2011, Điều 3.1.26]
3.17
Lưu đồ đánh giá (evaluation scheme)
Khung quy định và quản lý về việc áp dụng bộ TCVN 8709 bởi cơ quan đánh giá trong một cộng đồng cụ thể
CHÚ THÍCH: So sánh TCVN ISO/IEC 17000, định nghĩa 2.8 “lưu đồ đánh giá sự phù hợp”.
[TCVN 8709-1:2011, Điều 3.1.29]
3.18
Nhãn hiệu (mark)
Luận cứ đảm bảo chứng minh tuyên bố đảm bảo.
CHÚ THÍCH 1: ISO/IEC 17030:2003 cung cấp yêu cầu chung đối với nhãn hiệu của bên thứ ba về sự phù hợp.
3.19
Đảm bảo dự đoán (predictive assurance)
Việc công nhận lặp lại sự phù hợp của nhà cung cấp để cung cấp các giao phẩm đáp ứng chính sách an toàn của mình hoặc thực hiện như đã tuyên bố.
3.20
Bảo mật (secure)
Không dễ bị tổn thương đối với hầu hết các cuộc tấn công, có thể chịu được nhiều cuộc tấn công dễ gây tổn thương và có thể phục hồi nhanh chóng với thiệt hại tối thiểu từ một vài cuộc tấn công khai thác lỗ hổng thành công.
3.21
An toàn (security)
Đặc tính của hệ thống phải đạt được tính bí mật, tính toàn vẹn, tính sẵn sàng, tính kiểm toán, tính xác thực, và tính bí mật.
3.22
An toàn (security)
Khả năng của sản phẩm phần mềm để bảo vệ thông tin và dữ liệu mà những người hoặc hệ thống khác không được phân quyền không thể đọc hoặc chỉnh sửa chúng và những người hoặc hệ thống được phân quyền không bị từ chối truy cập vào chúng.
[ISO/IEC 12207:2007, Điều 4.39]
3.23
Đảm bảo an toàn (security assurance)
Cơ sở cho tính bí mật mà tuyên bố về mục tiêu an toàn đã đạt được hoặc sẽ đạt được.
[ISO/IEC 15025-1:2010, Điều 2.11]
3.24
Luận cứ đảm bảo an toàn (security assurance argument)
Tập các tuyên bố đảm bảo an toàn có cấu trúc, được hỗ trợ bởi những bằng chứng và luận cứ, chứng minh một cách rõ ràng cách thức đáp ứng nhu cầu đảm bảo an toàn.
3.25
Bằng chứng đảm bảo an toàn (security assurance evidence)
Dữ liệu mà một phán quyết hoặc kết luận về một tuyên bố đảm bảo an toàn có thể dựa vào
CHÚ THÍCH: Bằng chứng có thể bao gồm: kết quả giám sát, kết quả kiểm tra, kết quả phân tích, đánh giá và kiểm định.
[ISO/IEC 21827, Điều 3.8]
3.26
Phương pháp đánh giá sự phù hợp đảm bảo an toàn (security assurance conformance assessment method)
Phương pháp SACA (SACA method)
Quy trình hệ thống, thủ tục hoặc kỹ thuật cho việc thu thập bằng chứng đảm bảo an toàn và xác nhận chắc chắn các tuyên bố đảm bảo an toàn
CHÚ THÍCH: So sánh với lưu đồ đánh giá sự phù hợp, định nghĩa 2.8 trong TCVN ISO/IEC 17000.
3.27
Mô hình đánh giá sự phù hợp đảm bảo an toàn (security assurance conformance assessment paradigm)
Mô hình SACA (SACA paradigm)
Hệ thống hoàn chỉnh việc cung cấp và công nhận một hoặc một số nhãn hiệu SACA liên quan bao gồm cả đặc tả về phương pháp SACA, lưu đồ SACA và tập hợp các bên liên quan.
3.28
Lưu đồ đánh giá sự phù hợp đảm bảo an toàn (security assurance conformance assessment scheme)
Lưu đồ SACA (SACA scheme)
Hệ thống các quy tắc, thủ tục và quản lý chung để chứng minh về các yêu cầu đảm bảo quy định liên quan đến sản phẩm, quy trình, hệ thống, con người hoặc tổ chức được áp dụng phù hợp cho đối tượng cụ thể của đánh giá sự phù hợp.
CHÚ THÍCH 1: Lưu đồ đánh giá sự phù hợp có thể được vận hành ở cấp quốc tế, quốc gia hay địa phương.
CHÚ THÍCH 2: Chấp nhận theo ISO/IEC 17000:2004 Điều 2.8.
CHÚ THÍCH 3: So sánh với “lưu đồ đánh giá” ở Điều 3.17.
3.29
Xếp hạng đảm bảo an toàn (security assurance rating)
Chỉ số về tính chặt chẽ đánh giá và phạm vi các yêu cầu đảm bảo an toàn theo thang đo cụ thể đã sử dụng bởi các phương pháp đảm bảo an toàn.
CHÚ THÍCH 1: Mức đảm bảo có thể không đo lường được về mặt định lượng.
CHÚ THÍCH 2: Mức độ đảm bảo an toàn đạt được thường liên quan đến việc nỗ lực thực hiện các hoạt động.
3.30
Kết quả đảm bảo an toàn (security assurance result)
Tuyên bố đảm bảo an toàn định lượng hay định tính đã được tài liệu hóa đi kèm với giao phẩm.
3.31
Mục tiêu an toàn (security objective)
Tuyên bố về ý định đối phó với các mối đe dọa xác định và/hoặc đáp ứng các chính sách an toàn xác định của tổ chức và các giả định.
[TCVN 8709-1:2011, Điều 3.1.60]
3.32
Vấn đề an toàn (security problem)
Tuyên bố một cách chính thức định nghĩa bản chất và phạm vi an toàn mà TOE hướng đến để giải quyết.
CHÚ THÍCH: tuyên bố này là sự kết hợp của:
a) Những mối đe dọa sẽ được đáp trả của giao phẩm.
b) Các OSP được thực thi bởi giao phẩm.
c) Các giả định được giữ cho giao phẩm và môi trường hoạt động của nó.
[TCVN 8709-1:2011, Điều 3.1.61]
3.33
Hệ thống (system)
Sự kết hợp của các yếu tố tương tác được tổ chức để đạt một hoặc nhiều mục đích đã đề ra.
CHÚ THÍCH 1: Một hệ thống có thể được coi là một sản phẩm hoặc dịch vụ mà nó cung cấp.
CHÚ THÍCH 2: Trong thực tế, từ “hệ thống” thường được làm rõ nghĩa bằng cách sử dụng một danh từ kết hợp, ví dụ như “hệ thống máy bay”. Ngoài ra, từ “hệ thống” có thể được thay thế đơn giản bằng một từ đồng nghĩa tùy thuộc vào ngữ cảnh, ví dụ như “máy bay”, mặc dù điều này có thể làm không rõ nghĩa từ “hệ thống”.
[ISO/IEC 15288:2008, Điều 4.31]
4 Các thuật ngữ viết tắt
| CASCO | ISO Committee on conformity assessment | Ủy ban ISO về đánh giá sự phù hợp |
| CC | Common Criteria | Tiêu chí chung |
| CCMC | Common Criteria Management Committee | Ủy ban quản lý tiêu chí chung |
| CCRA | Common Criteria Recognition Arrangement | Tổ chức thừa nhận lẫn nhau về tiêu chí chung |
| CEM | Common Evaluation Methodogoly | Phương pháp đánh giá chung |
| CMM | Capability Maturity Model | Mô hình hoàn thiện năng lực |
| COTS | Commercial off the shef | Sẵn sàng phổ biến và thương mại hóa |
| CSEC | Communications Security Establishment of Canada (Canada IT Security Agency) | Tổ chức an toàn truyền thông Canada (cơ quan an toàn công nghệ thông tin Canada) |
| EAL | Evaluation Assurance level | Mức đảm bảo đánh giá |
| IEC | International Electrotechnical Commission | Ủy ban kỹ thuật điện quốc tế |
| ISMS | Information Security Management System | Hệ thống quản lý an toàn thông tin |
| ISO | International Organization for Standardization | Tổ chức tiêu chuẩn hóa quốc tế |
| IT | Information Technology | Công nghệ thông tin |
| ITSEC | Information Technology Security Evaluation Criteria (Office for Official Publications of the European Communities) | Tiêu chí đánh giá an toàn Công nghệ thông tin (Cơ quan phát hành chính thức của cộng đồng Châu Âu) |
| ITSEF | Information Technology Security Evaluation Facility | Cơ sở đánh giá an toàn Công nghệ thông tin |
| ITSEM | Information Technology Security Evaluation Methodology (Office for Official Publications of the European Communities) | Phương pháp đánh giá an toàn Công nghệ thông tin (Cơ quan phát hành chính thức của cộng đồng Châu Âu) |
| NIST | National Institute of Standards and Technology (Government Agency of the USA) | Viện Công nghệ và tiêu chuẩn quốc gia (Cơ quan chính phủ Hoa Kỳ) |
| NSA | National Security Agency (Government Agency of the USA) | Cơ quan an toàn quốc gia (Cơ quan chính phủ Hoa Kỳ) |
| PCI DSS | Payment Card Industry Data Security Standard | Tiêu chuẩn bảo mật dữ liệu thẻ thanh toán |
| PCI SSC | Payment Card Industry Security Standard Council | Hội đồng tiêu chuẩn bảo mật thẻ thanh toán |
| PP | Protection Profile (defined in TCVN 8709-1:2011) | Hồ sơ bảo vệ (quy định tại TCVN 8709-1:2011) |
| SACA | Security assurance conformance assessment | Đánh giá sự phù hợp đảm bảo an toàn |
| SCT | Strict (Security) Conformance Testing | Kiểm tra nghiêm ngặt sự phù hợp |
| SDO | Standards Development Organization | Tổ chức phát triển các tiêu chuẩn |
| SOG-IS | Senior Officials Group, Information System Security | Nhóm các quan chức cấp cao, an toàn hệ thống thông tin |
| SSE- CMM | System Security Engineering – Capability Maturity Model ISO/IEC 21827 | Kỹ thuật an toàn hệ thống – Mô hình hoàn thiện năng lực ISO/IEC 21827 |
| ST | Security Target | Đích an toàn (theo định nghĩa trong TCVN 8709-1:2011) |
| TOE | Target of Evaluation | Đích đánh giá (theo định nghĩa trong TCVN 8709-1:2011) |
5 Khái niệm đảm bảo an toàn
Điều này giới thiệu các khái niệm về đảm bảo an toàn và nhằm mục đích bổ sung thêm các khái niệm đảm bảo chung được đưa ra trong ISO/IEC 15026-1:2010 cho đảm bảo phần mềm và hệ thống.
Cấu trúc đảm bảo an toàn được đưa ra tại Điều 6, các khái niệm về sự phù hợp trong đánh giá đảm bảo an toàn được giải thích tại Điều 7, 8 và 9, khái niệm mới về đảm bảo an toàn được giới thiệu tại Điều 10.
5.1 Đảm bảo an toàn
An toàn thường được mô tả trong các thuật ngữ về thuộc tính an toàn then chốt, gồm tính bí mật, tính toàn vẹn và tính sẵn sàng. Hơn nữa, còn bao gồm các tính chống chối bỏ và tính xác thực thường được trích dẫn bởi các chuyên gia an toàn. Đối với chủ đề đảm bảo, các thuộc tính được xem xét đến có thể bao gồm độ tin cậy, tính chắc chắn, chất lượng, tính sống còn và tùy thuộc vào một số tính bảo mật cá nhân.
Đảm bảo an toàn có thể được xem xét liên quan đến đảm bảo chất lượng. Chất lượng được định nghĩa theo nhiều cách, bao gồm:
– Xuất sắc (Socrates, Plato, Aristotle).
– Giá trị (Feigenbaum).
– Phù hợp với đặc tả (Gilmore, Levitt, Crosby, Deming, Feigenbaum, Juran).
– Đáp ứng/ vượt qua được sự mong muốn của khách hàng (Feigenbaum, Juran).
– Phù hợp với các yêu cầu (Crosby).
– Tránh mất mát (Taguchi).
– Phù hợp với mục đích (Juran).
Điều khoản của đảm bảo an toàn đóng góp vào các mô hình này và do đó có thể được coi là một bên đóng góp cho thuộc tính chất lượng và liên quan đến sự hài lòng của các bên liên quan.
Điều này tuyên bố rằng điều khoản của đảm bảo an toàn chính là nguồn tài nguyên thiết yếu và bao gồm cả chi phí và sự chậm trễ phát sinh. Khối lượng nguồn lực sử dụng phải phù hợp với đảm bảo an toàn được cung cấp. Hơn nữa, đảm bảo an toàn là hướng để ngăn chặn thiệt hại và không trực tiếp góp phần vào doanh thu hay lợi nhuận. Do đó lợi ích của việc đầu tư đảm bảo an toàn có thể được đo bằng chi phí xử lý lỗi. Những người không liên quan đến vấn đề an toàn sẽ không nhận thấy được lợi ích từ việc đầu tư các nguồn lực trong đảm bảo an toàn của một tổ chức do đó để nhận được sự chấp thuận ở mức quản lý có thể yêu cầu phải mở rộng các minh chứng và trình bày tốt.
Người đọc cần lưu ý rằng một tuyên bố về giao phẩm phức hợp chẳng hạn như các hệ thống công nghệ thông tin, cho rằng giao phẩm là không thể được tạo ra một cách an toàn tuyệt đối. Ngược lại, chỉ cho rằng sẽ đảm bảo an toàn cho giao phẩm phức hợp, mặc dù sớm hay muộn giao phẩm đó cũng sẽ gặp lỗi. Do đó có thể thấy rằng mục tiêu mà hệ thống công nghệ thông tin chỉ ra ở đây, đó là “bảo mật” là đặc tả kỹ thuật của hệ thống công nghệ thông tin hoặc giao phẩm sẽ không dễ bị tổn thương đối với hầu hết các cuộc tấn công, có thể chịu được nhiều cuộc tấn công vào lỗ hổng hệ thống và có thể phục hồi một cách nhanh chóng với thiệt hại tối thiểu từ một vài cuộc tấn công khai thác lỗ hổng thành công.
Việc cung cấp sự đảm bảo an toàn là để đủ tiêu chuẩn cho mục tiêu mức cao và để cung cấp cho các bên liên quan những chỉ dẫn về tính bí mật mà họ có thể giả định giao phẩm là bảo mật.
5.2 Sự khác biệt giữa đảm bảo và tính bí mật
Điều quan trọng là chỉ ra đảm bảo và tính bí mật là không giống nhau và không thể được sử dụng thay cho nhau. Thông thường, những thuật ngữ này được sử dụng không chính xác giống như chúng liên quan chặt chẽ với nhau. Điều quan trọng là người đọc tài liệu hiểu được sự khác biệt giữa hai thuật ngữ này. Đặc biệt ở đây tính bí mật liên quan đến việc tin tưởng vào việc đảm bảo của giao phẩm trong khi đảm bảo liên quan đến việc chứng minh khả năng của giao phẩm để thực hiện mục tiêu an toàn của nó. Do đó, tính bí mật không phải là một điều chắc chắn nhưng là một biểu hiện của sự tin tưởng và niềm tin tạo ra thông qua sự đảm bảo.
Đảm bảo được xác định từ bằng chứng được đưa ra bởi quy trình đánh giá giao phẩm. Các bằng chứng thường bao gồm luận cứ, tài liệu đảm bảo, và các thứ khác liên quan tới sản phẩm, chứng minh tuyên bố đảm bảo dựa trên hoạt động đánh giá và kỹ thuật an toàn.
Tính bí mật phụ thuộc vào nhận thức của cá nhân về yêu cầu an toàn đã chỉ định và để thu được kiến thức trong quá trình đánh giá mà giao phẩm được thực hiện theo cách đã dự kiến hoặc đã tuyên bố.
Điều này bao gồm các kiến thức về các tiêu chí, phương pháp, lưu đồ và quy trình đánh giá đảm bảo đã sử dụng. Hơn nữa, danh tiếng của bên đánh giá và bên vận hành là yếu tố quan trọng trong việc thiết lập tính bí mật của giao phẩm vì trình độ và kinh nghiệm của họ có thể hoặc không thể được công nhận. Kết quả là, theo nhận thức của các cá nhân, các bên liên quan có thể có mức độ tính bí mật khác nhau sau khi thực hiện phương pháp đảm bảo bởi một cá nhân hay một tổ chức.
5.3 Nhu cầu đảm bảo an toàn
Trong vài thập kỷ qua, sự tin tưởng của chúng ta vào các hệ thống công nghệ thông tin đã tăng lên đáng kể. Hiện nay, hệ thống công nghệ thông tin trở nên phổ biến và đóng vai trò quan trọng trong cơ sở hạ tầng của xã hội. Phải thừa nhận thực tế rằng giá trị của tài sản có thể bị tổn hại qua một hệ thống công nghệ thông tin vượt quá giá trị tiền tệ mà còn có thể ảnh hưởng đến các quy trình cơ bản của xã hội hiện đại.
Ví dụ: Sự tin tưởng của chúng ta vào sự ổn định của hệ thống tài chính có thể bị ảnh hưởng, ít nhất là một phần nào đó, thông qua an toàn của các hệ thống công nghệ thông tin được triển khai để hỗ trợ ngành công nghiệp đó. Một lỗi của hệ thống then chốt có thể làm gián đoạn kinh tế một khu vực, quốc gia hoặc thế giới.
Tương tự như vậy, việc sản xuất và phân phối điện phụ thuộc vào các hệ thống công nghệ thông tin được sử dụng để kiểm soát và quản lý các tài nguyên. Giá trị tài sản mà các hệ thống công nghệ thông tin liên quan vượt qua giá trị của bản thân hệ thống đó, vượt qua giá trị của các thiết bị hình thành nên cơ sở hạ tầng, ảnh hưởng tới giá trị xã hội.
Hệ thống công nghệ thông tin rất dễ xảy ra lỗi trong việc duy trì an toàn một phần là do ngày càng gia tăng sự phức tạp của hệ thống, khả năng cải tiến của những kẻ tấn công, giá trị tài sản ngày càng tăng mà chúng nắm giữ. Các lỗ hổng có thể khai thác được đưa ra do công nghệ thay đổi nhanh chóng, lỗi con người, đặc tả yêu cầu, quy trình phát triển kém hoặc do đánh giá thấp mối đe dọa. Khi hệ thống công nghệ thông tin triển khai kèm theo các chức năng bổ sung, giảm thiểu hệ thống, bảo trì hệ thống và thay đổi yêu cầu nghiệp vụ thường đóng góp vào khả năng làm gia tăng số lượng lỗ hổng có thể khai thác và sự vi phạm an toàn xảy ra trong suốt vòng đời của hệ thống công nghệ thông tin. Điều này đưa ra thực tế là không thể đảm bảo một hệ thống công nghệ thông tin không có lỗi và không có rủi ro và bảo mật.
Như trên đã đề cập cho thấy rằng các lỗi, lỗ hổng có thể khai thác và rủi ro sẽ luôn luôn tồn tại và đặc tính của chúng sẽ thay đổi trong vòng đời hệ thống công nghệ thông tin. Do đó, các lỗi, lỗ hổng và rủi ro sẽ phải được quản lý trong suốt vòng đời của hệ thống công nghệ thông tin trong phạm vi các thông số có thể chấp nhận được.
Nhiệm vụ của những cá nhân chịu trách nhiệm về an toàn của hệ thống công nghệ thông tin là thiết lập mức chấp nhận được của đảm bảo an toàn và các mục tiêu rủi ro cho hệ thống công nghệ thông tin. Họ phải quản lý những rủi ro an toàn bằng cách giảm thiểu các lỗ hổng và các mối đe dọa bằng các biện pháp an toàn có tính kỹ thuật và có tổ chức an toàn để đạt được một hệ thống công nghệ thông tin với đảm bảo an toàn chấp nhận được. Bằng cách này, các bên liên quan của một hệ thống công nghệ thông tin sẽ đạt được tính bí mật hợp lý rằng hệ thống công nghệ thông tin thực hiện theo cách đã định.
Theo quan điểm an toàn, điều này có thể hiểu là tính bí mật mà giao phẩm đã được áp dụng các chính sách an toàn.
5.4 Đảm bảo an toàn là điều không thể nắm bắt được
Đảm bảo an toàn không “thêm” bất kỳ biện pháp bảo vệ hoặc dịch vụ nào vào giao phẩm. Vì vậy, đôi khi nó rất khó để cá nhân chưa có nhận thức an toàn hiểu được những lợi ích họ đang nhận được từ việc đầu tư tài nguyên đảm bảo. Ví dụ, đối với một sản phẩm an toàn công nghệ thông tin thì việc đảm bảo góp phần vào “tăng cường” cơ chế bảo mật; tuy nhiên, việc đảm bảo thực ra chỉ góp phần vào tính bí mật mà nó có cơ chế bảo mật mạnh bằng cách giảm tính không chắc chắn (hay khả năng) xuất hiện mối đe dọa mà có thể gây ra vi phạm an toàn. Ví dụ, xác thực hai yếu tố thường bị nhầm lẫn là đảm bảo hơn cơ chế mật khẩu đơn giản, nhưng mà trong thực tế thì nó chỉ là một cơ chế xác thực mạnh. Xác thực hai yếu tố là một cơ chế xác thực mạnh vì nó kiểm tra hai thuộc tính người dùng so với việc xác nhận một thuộc tính trong cơ chế mật khẩu. Điều này tự thân không đưa ra sự đảm bảo từ khi nó là các hoạt động đảm bảo trong khi phát triển cơ chế góp phần vào sự đảm bảo cho cơ chế.
Điều quan trọng là phải hiểu được đảm bảo không nghĩa là an toàn tốt: đảm bảo chỉ đáp ứng được các mục tiêu an toàn (chính sách an toàn). Nói cách khác, việc đảm bảo cung cấp tính bí mật mà các giao phẩm thực thi các mục tiêu an toàn không cần kiểm tra xem các mục tiêu an toàn đó có giải quyết thích hợp được các rủi ro và các mối đe dọa hay không. Ví dụ, khi một sản phẩm công nghệ thông tin đảm bảo cao có thể được tin tưởng để đáp ứng mục tiêu an toàn của nó, phụ thuộc vào bản chất của các mục tiêu này để sản phẩm hoạt động một cách an toàn. Ngược lại, một sản phẩm đảm bảo an toàn thấp với mục tiêu thích hợp hơn có thể thực sự bảo mật hơn.
5.5 Đảm bảo an toàn nhằm làm giảm rủi ro an toàn
Đảm bảo an toàn góp phần làm giảm rủi ro, giống như đảm bảo làm giảm xác suất các lỗ hổng của giao phẩm. Các lỗ hổng tiềm năng được giảm bớt, giúp giảm thiểu toàn bộ rủi ro liên quan tới giao phẩm. Như đã thảo luận trong điều trước, đảm bảo an toàn không thêm bất kỳ biện pháp kiểm soát gì để đối phó với những rủi ro liên quan đến an toàn: hơn nữa, các hoạt động đảm bảo cố gắng chứng minh rằng giao phẩm đáp ứng các mục tiêu an toàn. Điều này liên quan đến việc đưa ra các bằng chứng liên quan tới đảm bảo và lý do để cung cấp tính bí mật mà các biện pháp kiểm soát triển khai sẽ làm giảm các rủi ro đoán trước.
Tính chất hoặc giá trị trực tiếp góp phần vào việc đảm bảo an toàn (hoặc đảm bảo an toàn tăng cường) tới tổ chức là không dễ dàng đạt được. Tuy nhiên, đảm bảo an toàn tăng cường của một biện pháp kiểm soát an toàn làm giảm bớt tính bất định liên quan đến rủi ro. Các biện pháp kiểm soát được thực hiện để xử lý các điểm yếu trong rủi ro. Như vậy giá trị của việc đảm bảo trong trường hợp này có thể được suy ra từ việc giảm thiểu tính bất định của rủi ro. Sự đảm bảo liên quan đến tính bất định của rủi ro hoặc các bộ phận cấu thành của nó, tạo thuận lợi cho các phương pháp đảm bảo; số lượng sự bất định của rủi ro xuất hiện nhiều hơn việc đảm bảo cho nó. Các phương pháp đảm bảo có thể được thực hiện gián tiếp bằng cách tính toán khả năng xảy ra rủi ro và sau đó sẽ được điều chỉnh theo tỉ lệ nghịch.
5.6 Đảm bảo an toàn được cung cấp có liên quan đến các nỗ lực đã thực hiện
Nói chung, việc đảm bảo an toàn đạt được có liên quan đến các nỗ lực đã thực hiện trong việc đạt được nó.
VÍ DỤ: Để cung cấp một mức độ cao của đảm bảo an toàn trong việc triển khai các tính năng an toàn của một ứng dụng phần mềm nào đó thì sẽ cần thiết thực hiện phân tích toàn bộ mã nguồn của giao phẩm phần mềm. Việc này có thể quyết định một kỹ thuật lấy mẫu mã nguồn được áp dụng như một phương pháp làm giảm nỗ lực yêu cầu phân tích nhưng khi kỹ thuật này được sử dụng thì đảm bảo an toàn có thể đạt ở một mức độ thấp hơn từ đánh giá. Nếu mã nguồn không được phân tích thì việc đảm bảo an toàn rõ ràng là ở các mức độ thấp hơn.
Các nỗ lực yêu cầu để cung cấp đảm bảo an toàn tương tự cho các giao phẩm khác nhau có thể thay đổi tùy theo:
a. độ hoàn thiện an toàn của giao phẩm;
b. kích cỡ và độ phức tạp của giao phẩm;
c. bản chất của các mục tiêu an toàn được đáp ứng;
d. số lượng của chức năng an toàn được đánh giá;
e. áp dụng một phương pháp đảm bảo chặt chẽ và nỗ lực hạn chế;
f. môi trường cụ thể;
g. sự khác biệt trong các phương pháp đảm bảo được áp dụng;
h. sự kết hợp cụ thể của phương pháp đảm bảo an toàn được triển khai.
5.7 Đảm bảo an toàn không cải thiện sản phẩm
Theo cùng một cách mà chất lượng sản phẩm không thể kiểm tra hay thử nghiệm bên trong sản phẩm cuối cùng, hiệu suất của hoạt động đảm bảo an toàn không hướng trực tiếp tới giao phẩm. Một giao phẩm tuyên bố về đảm bảo an toàn mức độ cao nhất đã được đánh giá độc lập không nhất thiết phải tốt hơn so với bất kỳ sản phẩm khác không có những tuyên bố tương tự.
Tuy nhiên, quy trình kiểm tra sự phù hợp đảm bảo an toàn thường chứa vòng lặp phản hồi tới các nhà phát triển sản phẩm cho phép quy trình đánh giá sự phù hợp để cung cấp cho việc thiết kế và phát triển sản phẩm.Thông qua quy trình phản hồi này mà lợi nhuận trong việc gia tăng tính an toàn có thể đạt được.
5.8 Các bên liên quan đến đảm bảo an toàn
5.8.1 Các bên yêu cầu tính bí mật trong kết quả SACA
Tóm lại đảm bảo an toàn được yêu cầu bởi những cá nhân có tài sản gặp rủi ro thông qua việc vận hành của giao phẩm. Vì vậy, việc xác định mức độ đảm bảo an toàn chấp nhận được là cần thiết và/hoặc chịu ảnh hưởng của các bên liên quan như một nhóm liệt kê dưới đây:
a) chính phủ, những người có thể yêu cầu đảm bảo an toàn thông qua pháp luật và quy định.
b) nhóm người cụ thể có sở hữu tài sản (kể cả danh tiếng của họ) có rủi ro và là người điều tiết hay quy định thông lệ tốt nhất cho nhóm người đó (ví dụ như ngành công nghiệp thẻ thanh toán).
c) tổ chức, những người có trách nhiệm bảo vệ tài sản riêng của họ, hoặc những người vận hành hệ thống công nghệ thông tin bảo vệ các tài sản của bên thứ ba khác.
d) bên tích hợp và cung cấp các hệ thống công nghệ thông tin cho bên thu mua.
e) người dùng cuối, những người có vấn đề an toàn cần giải quyết và những người có thể ảnh hưởng đến đặc tả kỹ thuật của yêu cầu an toàn một cách trực tiếp hoặc gián tiếp.
f) bên phát triển và bên cung cấp các giao phẩm tạo thành các thành phần của một hệ thống công nghệ thông tin.
5.8.2 Cơ quan đảm bảo và cơ quan phê chuẩn
Cơ quan đảm bảo là các cá nhân hoặc tổ chức chịu trách nhiệm về các yêu cầu đảm bảo an toàn quy định trong khi cơ quan phê chuẩn SACA là các cá nhân hoặc tổ chức có thẩm quyền quyết định liên quan đến kết quả SACA của giao phẩm, sau cùng là dẫn đến việc thiết lập tính bí mật của giao phẩm. Trong các tổ chức nhất định, đặc biệt là trong các tổ chức chính phủ và quân sự, SACA có thể được điều chỉnh hoặc giới hạn các lựa chọn có sẵn cho cơ quan đảm bảo SACA, hoặc có nghĩa là các cơ quan đảm bảo SACA là tổ chức chính phủ hoặc quân sự.
Cho rằng có rất nhiều giai đoạn trong vòng đời của một giao phẩm, chuỗi cung ứng của nó và một số bên liên quan tham gia, có thể có một số cơ quan phê chuẩn SACA, mỗi cơ quan đều có quyền lợi và trách nhiệm cụ thể. Ví dụ, trong giai đoạn phát triển, cơ quan SACA có thể là một kỹ sư an toàn trong tổ chức của bên cung cấp chịu trách nhiệm chắc chắn rằng việc đảm bảo an toàn thích hợp là thuộc tính của giao phẩm. Đồng thời, các tổ chức thu mua có thể có cơ quan phê chuẩn SACA của riêng họ chịu trách nhiệm chắc chắn rằng các yêu cầu đảm bảo an toàn của họ được tổ chức cung ứng giải quyết. Cơ quan phê chuẩn SACA khác có thể được đại diện cho bộ phận thu mua của chính phủ, quản lý một danh sách các sản phẩm đã được phê duyệt.
Có ba cơ quan phê chuẩn SACA, mỗi cơ quan chịu trách nhiệm cho mỗi một giai đoạn cụ thể của giao phẩm và từ những góc độ khác nhau. Hơn nữa, cơ quan phê chuẩn SACA có thể chịu trách nhiệm cho nhiều giai đoạn của vòng đời. Ví dụ trường hợp cơ quan phê chuẩn SACA đã nêu ở trên, chịu trách nhiệm cho tính bí mật trong việc đảm bảo của sản phẩm COTS, ứng dụng tùy chỉnh, và cũng chịu trách nhiệm cho việc chấp nhận kết quả đánh giá sự phù hợp liên quan đến cấp phép hoạt động cho hệ thống hoàn chỉnh.
Tùy thuộc vào tổ chức và trách nhiệm của họ, cơ quan phê chuẩn SACA cũng có thể hoạt động như cơ quan đảm bảo với trách nhiệm chắc chắn rằng các chính sách đảm bảo an toàn tổ chức được đáp ứng, lựa chọn lưu đồ SACA hoặc hệ thống SACA thích hợp và xác định mức độ đòi hỏi và loại đảm bảo đòi hỏi để thỏa mãn yêu cầu cụ thể của họ. Cơ quan đảm bảo cũng có trách nhiệm chắc chắn rằng các chính sách đảm bảo an toàn được đáp ứng, liên lạc với các tổ chức đảm bảo an toàn khác (chẳng hạn như lưu đồ SACA hoặc hệ thống SACA).
Các tổ chức có thể chỉ định vai trò khác nhau như cơ quan phê chuẩn SACA và các nhiệm vụ có thể khác nhau tùy theo mô hình hoạt động duy nhất của họ; tuy nhiên, cơ quan phê chuẩn SACA vẫn sẽ chịu trách nhiệm mà nhiệm vụ đòi hỏi. Trong các tổ chức nhỏ, một nhân viên thường sẽ có nhiệm vụ khác ngoài việc là cơ quan phê chuẩn SACA trong khi các tổ chức lớn hơn có thể có một nhân viên duy nhất dành riêng cho vị trí này.
Các tổ chức lớn hơn thường chỉ định một nhân viên cao cấp là cơ quan phê chuẩn SACA chịu trách nhiệm trong việc triển khai hiện một phương pháp SACA và nghiệm thu kết quả SACA. Tùy thuộc vào tổ chức, người có trách nhiệm nghiệm thu kết quả cuối cùng của SACA có thể cũng phải chịu trách nhiệm về việc vận hành của giao phẩm (ví dụ: đưa hệ thống vào hoạt động hoặc chấp nhận phân phối dịch vụ). Do đó, cơ quan phê chuẩn SACA sẽ phải xác định mức cân bằng thích hợp giữa quy mô và độ sâu mà SACA được thực hiện, và theo đó là khung thời gian và chi phí của các hoạt động đánh giá liên quan.
5.9 Phổ biến rộng rãi đảm bảo an toàn
Phải thừa nhận rằng để giải quyết việc đảm bảo an toàn đầy đủ cho tài nguyên, một loạt các giao phẩm góp phần vào việc cấu tạo của một hệ thống công nghệ thông tin hay sản phẩm cần phải được xem xét.
Biểu đồ dưới đây đưa ra một chuỗi cung ứng điển hình có liên quan đến việc tạo ra, bảo trì và vận hành của hệ thống công nghệ thông tin. Mục đích của sơ đồ này là để minh họa sự phức tạp liên quan và chỉ ra rằng tuyên bố đảm bảo cho một hệ thống công nghệ thông tin là không chỉ phụ thuộc vào một bên, mà trong thực tế còn phụ thuộc vào nhiều nhà cung cấp đảm bảo an toàn. Mỗi thành phần của hệ thống (cho dù đó là một nhà cung cấp dịch vụ dựa trên đám mây, hoặc nhà sản xuất mạch tích hợp) góp phần tạo những lỗ hổng tiềm năng cho hệ thống công nghệ thông tin và nên cung cấp sự đảm bảo phù hợp cho các bên liên quan của hệ thống công nghệ thông tin.
ISO/IEC 27036-1:2014, Công nghệ thông tin – các kỹ thuật an toàn – Khung đảm bảo an toàn Công nghệ thông tin – Phần 1: Giới thiệu và định nghĩa mô tả các khái niệm chung cho tất cả các loại khác nhau của các mối quan hệ nhà cung cấp và xác định các rủi ro an toàn thông tin điển hình mà một tổ chức có thể phải đối mặt khi tham gia vào mối quan hệ nhà cung cấp, tùy thuộc vào loại truy cập các nhà cung cấp có các thông tin và hệ thống thông tin của tổ chức.
Hình 1 – Minh họa của một chuỗi cung ứng điển hình
Các yếu tố có thể ảnh hưởng đến tình hình an toàn của hệ thống công nghệ thông tin và do đó cần cung cấp các tuyên bố đảm bảo an toàn thích hợp, bao gồm:
a) các sản phẩm cung cấp chức năng an toàn như máy chủ, hệ điều hành, các thành phần mạng, thẻ thông minh và các ứng dụng phần mềm;
b) các dịch vụ liên quan tới khía cạnh an toàn như dịch vụ thuê ngoài (ví dụ như các nhà cung cấp sao lưu, quản lý IDS, dịch vụ phần mềm, điện toán đám mây cung cấp cung cấp tài nguyên và dịch vụ quản lý an toàn);
c) các quy trình nội bộ có ảnh hưởng đến an toàn công nghệ thông tin;
d) cá nhân đóng góp cho tình hình an toàn công nghệ thông tin hoặc cho các điều khoản về đảm bảo an toàn công nghệ thông tin;
e) Các tổ chức ảnh hưởng đến hệ thống;
f) các yếu tố môi trường khác.
Để giải quyết yêu cầu này, thuật ngữ “giao phẩm” được sử dụng để tham chiếu tới yếu tố đó, đó có thể là một thành phần góp phần đảm bảo cho một vấn đề an toàn lớn hơn hoặc có thể là một hệ thống đảm bảo hoàn chỉnh liên quan tới vấn đề an toàn của giao phẩm đó. Phần này giới thiệu các khái niệm về thành phần đảm bảo an toàn được đề cập trong điều 10.
Một số giao phẩm cũng có thể góp phần đảm bảo an toàn. Ví dụ, một thành phần của phần cứng như một tụ điện đơn giản, tỉ lệ xả sau đó có thể ảnh hưởng đến độ dài thời gian hoạt động bộ nhớ RAM và do đó nội dung của nó có thể bị kẻ tấn công truy cập. Nếu thành phần cơ bản không có đặc tả thì lỗ hổng có thể được giới thiệu.
Đảm bảo an toàn là việc xem xét tất cả các giai đoạn của vòng đời của mỗi thành phần của mỗi giao phẩm hình thành một hệ thống.
5.9.1 Đảm bảo an toàn xuyên suốt
Đảm bảo an toàn xuyên suốt cung cấp đảm bảo cho các bên liên quan trong toàn bộ chuỗi cung ứng. Dạng tuyên bố đảm bảo này được dành cho bên thu mua cuối hoặc người dùng cuối của sản phẩm đã lắp ráp, không dành trực tiếp cho bên tích hợp các bộ phận để tạo ra sản phẩm cuối cùng. Nó được bên tích hợp sử dụng như một phần của toàn bộ trường hợp đảm bảo máy tính xách tay. Các tuyên bố đảm bảo khác về trường hợp đảm bảo của các chip vi xử lý sẽ là mục tiêu nhắm tới của các nhà tích hợp và không trình diễn cho người dùng sản phẩm cuối.
VÍ DỤ: Bên dưới máy tính xách tay và nguồn cung cấp điện của nó, thường có một loạt các nhãn hiệu liên quan đến an toàn điện, điện tử và cách can thiệp sản phẩm đó. Đó là những tuyên bố đảm bảo. Chúng cho người dùng biết rằng các sản phẩm đã được thử nghiệm và an toàn để sử dụng. Trong một số trường hợp, chúng có thể bao gồm là sự hạn chế trong sử dụng, chẳng hạn như giới hạn về phạm vi sử dụng điện áp của nguồn điện. Một loại nhãn hiệu khác, đúng hơn là một biểu tượng cũng có thể được nhìn thấy trên rất nhiều sản phẩm nhưng thường là nằm bên trong máy tính xách tay. Biểu tượng này biểu thị chip vi xử lý được sử dụng trong các máy tính xách tay, ví dụ như “Intel Inside”. Đây cũng là một loại tuyên bố đảm bảo. Các loại tuyên bố đảm bảo cùng với nhau đã tạo nên các trường hợp đảm bảo liên quan đến sản phẩm.
5.9.2 Ranh giới của giao phẩm
Điều quan trọng là phải hiểu và xác định phạm vi, ranh giới cho một giao phẩm, đó là đối tượng của việc đánh giá an toàn bởi vì ranh giới được mô tả có thể không liên kết với những mong đợi của người dùng vì phương pháp cung cấp sự đảm bảo an toàn có thể:
– tập trung vào một nhóm các chức năng nhất định, những nhóm được chỉ định có chức năng an toàn.
– được chế tác để giải quyết các vấn đề an toàn của một bên liên quan đặc thù.
– bị hạn chế bởi nguồn tài nguyên sẵn có để thực hiện một đánh giá.
Do đó, quan trọng là người dùng hiểu được ranh giới trong đánh giá an toàn bao gồm những điểm nào. Các phương pháp đảm bảo khác nhau mô tả ranh giới sử dụng các cơ chế khác nhau.
VÍ DỤ:
– Việc đánh giá sản phẩm công nghệ thông tin sử dụng TCVN 8709 – phạm vi và ranh giới được xác định rõ ràng trong tài liệu “Mục tiêu an toàn”.
– ISO/IEC 19790 thử nghiệm sự phù hợp của một modun mã hóa – ranh giới được mô tả trong tài liệu “Tài liệu chính sách an toàn”.
– Một hệ thống quản lý an toàn thông tin (ISMS) – ISO/IEC 27001 đòi hỏi ranh giới được xác định rõ ràng bằng cách sử dụng một phạm vi báo cáo chi tiết cho ISMS.
– Đánh giá PCI DSS – phạm vi của môi trường dữ liệu chủ thẻ được xác định bởi bên đánh giá và ghi nhận trong báo cáo về sự hài lòng
VÍ DỤ 1: Sau đây là một ví dụ về tuyên bố ranh giới được trích ra từ một Mục tiêu an toàn cho hệ điều hành được đánh giá theo phương pháp TCVN 8709.
| 1.5.2. Ranh giới TOE
1.5.2.1. Vật lý Các TOE được dựa trên hệ thống phần mềm sau đây: • Phiên bản Linux được đề cập TOE và tài liệu của nó được cung cấp trên đĩa CD-ROM. TOE bao gồm một gói giữ tài liệu quản trị về người dùng bổ sung. Ngoài các tài liệu cài đặt phương tiện truyền thông, tài liệu hướng dẫn dưới đây cũng được cung cấp: • Hướng dẫn cấu hình đánh giá (lưu ý rằng hướng dẫn này là hướng dẫn chính bao gồm các thiết lập và các yêu cầu cấu hình đánh giá). • Hướng dẫn an toàn Linux dành cho người quản trị. • Hướng dẫn cấu hình an toàn Linux. Phần cứng áp dụng cho việc cấu hình đánh giá được liệt kê trong phần khác của mục tiêu an toàn. Việc phân tích khả năng phần cứng cũng như các chức năng phần sụn được bao phủ bởi đánh giá này trong phạm vi mà các khả năng sau đây hỗ trợ cho các chức năng an toàn được phân tích và thử nghiệm: • Khả năng phân chia của bộ nhớ. • Trạng thái không sẵn sàng của bộ xử lý đặc quyền cho mã người dùng không tin cậy (như trạng thái ảo hóa của SMM). • Thử nghiệm đầy đủ các chức năng an toàn trên tất cả các bảng đã liệt kê. 1.5.2.2. Lôgic Các tính năng an toàn chính của TOE là: • Định danh và xác thực: Định danh và xác thực người dùng trong TOE bao gồm tất cả các hình thức đăng nhập tương tác (ví dụ: sử dụng các giao thức SSH hoặc đăng nhập tại giao diện điều khiển cục bộ) cũng như nhận dạng thay đổi thông qua câu lệnh “su”. Tất cả đều dựa trên thông tin xác thực cung cấp tương tác rõ ràng bởi người dùng. • Kiểm toán: Khung kiểm toán đơn giản hóa (LAF) được thiết kế để có một hệ thống kiểm toán phù hợp cho Linux với các đòi hỏi từ tiêu chuẩn chung. LAF có thể chặn bắt tất cả các cuộc gọi hệ thống cũng như lấy bản ghi kiểm toán đầu vào từ các ứng dụng có đặc quyền người dùng. Các hệ thống phụ cho phép cấu hình các sự kiện để kiểm toán từ bộ các sự kiện có thể được kiểm toán. • Điều khiển truy cập tùy ý (DAC): cho phép chủ sở hữu của các đối tượng đã đặt tên để kiểm soát quyền truy cập đến các đối tượng đó. Các chủ sở hữu có thể cho phép hoặc từ chối người dùng khác truy cập dựa trên việc thiết lập cấu hình cho phép. • Điều khiển truy cập bắt buộc (MAC): TOE hỗ trợ điều khiển truy cập bắt buộc sử dụng các nhãn hiệu nhạy cảm được gắn tự động với quy trình và đối tượng. Người dùng không thể can thiệp vào các nhãn hiệu đó. Các chính sách điều khiển truy cập bắt buộc được thực thi bằng cách sử dụng các nhãn hiệu lấy từ mô hình kiểm soát truy cập Bell-LaPadula. TOE sử dụng SELinux với một chính sách thích hợp để thực thi điều khiển truy cập bắt buộc. • Dịch vụ mật mã: TOE cung cấp thư viện NSS được bao phủ bởi chứng nhận FIPS 140-2. Thư viện NSS được sử dụng trong một chế độ phù hợp FIPS 140-2 cho dịch vụ mật mã và kiểm tra tính toàn vẹn chung của TSF. Các cơ chế mật mã, các chức năng an toàn của tài liệu này được xác nhận theo chứng nhận FIPS 140-2 số 9999. • Quản lý an toàn: Các phương tiện quản lý an toàn cung cấp bởi TOE có thể được sử dụng bởi người dùng được ủy quyền hoặc người quản trị được ủy quyền sử dụng để thay đổi cấu hình của TSF. • Bảo vệ TFS: TFS được cấu trúc để có quyền truy cập đặc quyền vào tài nguyên hệ thống. Các yêu cầu truy cập vào tài nguyên của người dùng phải qua trung gian TSF. Các cơ chế bảo vệ bổ sung khác nhau được đưa ra để tránh lạm dụng TOE. TOE cung cấp nhiều chức năng và cơ chế hơn. Việc đánh giá đảm bảo rằng tất cả các chức năng bổ sung sẽ không can thiệp vào các cơ chế an toàn đã đề cập ở trên trong việc cấu hình đánh giá. Các cơ chế và chức năng sẽ can thiệp vào việc vận hành của các chức năng an toàn sẽ không được cho phép trong việc cấu hình đánh giá và Hướng dẫn Cấu hình đánh giá cung cấp cho người quản trị làm thế nào để vô hiệu hóa chúng. Lưu ý: Cơ chế TOE cung cấp các hạn chế bổ sung vào các chức năng an toàn đã tuyên bố ở trên được cho phép trong cấu hình đánh giá. Ví dụ, BSDJails được cung cấp với TOE và được cho phép trong việc cấu hình đánh giá mặc dù nó không lệ thuộc vào việc đánh giá này. BDSJails cung cấp nhiều hạn chế hơn nữa, ví dụ như chức năng an toàn của cơ chế kiểm soát truy cập tùy ý cho các đối tượng IPC và do đó không thể vi phạm chức năng an toàn. Bảng dưới đây liệt kê các cơ chế được cung cấp với TOE nhưng đã bị loại bỏ khỏi việc đánh giá (lưu ý rằng nếu một chức năng được đánh dấu là “Không sẵn có” tức là nó sẽ không hoạt động hoặc không có mặt trong TOE, nếu một chức năng được đánh dấu là “Không được đánh giá” tức là nó đang hoạt động nhưng việc đánh giá không phân tích nếu không có tuyên bố nào áp dụng lên nó.
Bảng 1 – Các hàm không được đánh giá Mật mã trong sản phẩm không liên quan đến các yêu cầu chức năng an toàn sẽ không được đánh giá và giá trị của nó được nhà cung cấp xác nhận. Điều này áp dụng cho tất cả các ứng dụng không liên quan đến thư viện NSS được cung cấp với khung mật mã hợp lệ trong chứng nhận FIPS 140-2. Các ví dụ được xác định trong việc đánh giá bao gồm: các chức năng OpenSSL, beecrypt, gnutls, gnugp, duplicity, OpenSSH, eCryptFS, IPSEC, stunnel, samhain, và crypt(). Lưu ý: việc loại bỏ các gói và cơ chế ở trên từ việc đánh giá này đã được loại trừ do hạn chế về tài nguyên. Việc loại trừ này không bao gồm các gói được thực thi không an toàn. Tuy nhiên, khi chúng không được đánh giá, người quản trị nên sử dụng chúng khi họ gặp rủi ro riêng. Lưu ý: Để phù hợp với việc chọn EAL, không thực hiện bất cứ việc phân tích kênh bí mật chính thức nào. |
VÍ DỤ 2: Dưới đây là một ví dụ về tuyên bố ranh giới giả định của tài liệu Chính sách an toàn cho một chủ đề modun mật mã để kiểm tra sự phù hợp bằng cách sử dụng đặc tả FIPS 140-2 (tương tự như ISO/IEC 19790).
| Tổng quan Modun
Bộ định tuyến XYZ S999 Whizz, hay được gọi là S999, là một modun mật mã đa chip độc lập được bọc trong một lớp vỏ kim loại thương mại làm bằng thép cán nguội. Ranh giới modun mật mã là các bộ định tuyến xung quanh bao gồm tất cả các thành phần, cả modun mã hóa. Hình dưới minh họa ranh giới mật mã của bộ định tuyến XYZ S999 Whizz. Trong ảnh, phần trống của tấm chứa các lỗ có thể giữ các thẻ giao diện mạng tùy chọn được mở rộng ra ranh giới của modun. FIPS xác nhận phiên bản phần sụn (firmware) là AA-19.6.2.75.
|
5.9.3 Việc chuyển giao giao phẩm
Xác định ranh giới trong suốt chuỗi cung ứng giúp cho việc phân công trách nhiệm các giao phẩm khác nhau và khung thời gian khác nhau trong suốt thời gian giao phẩm được xử lý. Trong trường hợp của chuỗi cung ứng, đảm bảo an toàn này được áp dụng không chỉ đối với “việc tạo thành” của giao phẩm mà còn cả với “việc chuyển giao” của chúng.
Việc đảm bảo trong khi phân phối không chỉ có nghĩa là đảm bảo giao phẩm được chuyển từ A đến B mà điều quan trọng là các thuộc tính được duy trì ở cùng trạng thái trong suốt quá trình.
Mặc dù một số phương pháp SACA giải quyết khía cạnh an toàn trong việc chuyển giao bao gồm TCVN 8709-3:2011 đề cập đến khái niệm này trong lớp đảm bảo hỗ trợ vòng đời (ALC), ISO/IEC 19790 đề cập đến việc phân phối và ISO/IEC 16125 đã đề xuất cũng bao gồm vấn đề này; điều này được xem như một khía cạnh chưa hoàn thiện cho việc đánh giá sự phù hợp đảm bảo an toàn.
5.10 Các khía cạnh tổ chức của SACA
Điều quan trọng là nhận ra môi trường an toàn và đặc biệt là hiểu các yêu cầu đảm bảo phản ánh các yêu cầu văn hóa và kinh doanh của tổ chức. Việc hiểu về các yêu cầu tổ chức là cần thiết để quyết định một phương pháp SACA có được chấp nhận hay không hoặc đảm bảo bao nhiêu là đủ. Chính sách SACA của tổ chức nên được xác định như sau:
a) làm cách nào xác định được các yêu cầu đảm bảo;
b) trong trường hợp nào một giao phẩm cần phải được chứng nhận theo một tiêu chuẩn cụ thể;
c) sản phẩm phải được chứng nhận theo tiêu chuẩn nào;
d) mức độ bí mật trong SACA được mong đợi trong trường hợp được chỉ định;
e) trách nhiệm đối với cơ quan đảm bảo SACA và cơ quan phê chuẩn SACA;
f) trường hợp nào cần giấy chứng nhận của giao phẩm.
6 Cấu trúc đảm bảo an toàn
Biểu đồ dưới đây mô tả quan hệ giữa các an toàn mong đợi của giao phẩm và các quy trình đảm bảo an toàn, góp phần cung cấp sự đảm bảo an toàn cần thiết.
Hình 2 – Mối quan hệ giữa an toàn trong giao phẩm và đảm bảo an toàn
6.1 Đặc tả yêu cầu đảm bảo an toàn
Trong thuật ngữ về an toàn công nghệ thông tin, việc đảm bảo an toàn đầy đủ nghĩa là các yêu cầu đảm bảo an toàn được xác định trước đặc trưng được giải quyết thông qua việc trình diễn một trường hợp đảm bảo an toàn – đó là kết quả của việc thực hiện các hoạt động và quy trình đảm bảo an toàn thích hợp. Yêu cầu đảm bảo an toàn được xác định từ các vấn đề an toàn của giao phẩm (và các yếu tố tiềm ẩn khác).
Yêu cầu đảm bảo an toàn được làm sáng tỏ bằng việc phân tích các yêu cầu an toàn cho giao phẩm, những người có ảnh hưởng, các yêu cầu an toàn (chính sách), các định hướng kinh doanh và môi trường đích của giao phẩm. Những người có ảnh hưởng được xem xét giải quyết vì họ có thể gây ảnh hưởng tới các yêu cầu đảm bảo của giao phẩm. Các ảnh hưởng có thể xuất phát từ bất kỳ nguồn gốc nào và thậm chí có thể là không hữu hình (chẳng hạn như chính trị, văn hóa, luật pháp địa phương hay các yêu cầu bắt buộc).
Việc đánh giá rủi ro sau đó được thực hiện để cung cấp một cái nhìn chuyên sâu vào tính nhạy cảm của tài sản, các lỗ hổng và các mối đe dọa nhằm xác định rủi ro còn lại và khuyến nghị các biện pháp bảo vệ được đề xuất và hiện có. Các khuyến nghị thực hiện được xem như là nhân tố trong các yêu cầu an toàn gốc để xem lại các yêu cầu đảm bảo an toàn và có liên quan đến việc hình thành một trường hợp đảm bảo.
Hướng dẫn chung về quản lý an toàn và thực hiện một phân tích rủi ro được trình bày trong TCVN 10295 (ISO/IEC 27005). TCVN 8709 có chứa thông tin về các chức năng an toàn và các yêu cầu đảm bảo cho sản phẩm và hệ thống công nghệ thông tin cụ thể cho việc đánh giá an toàn công nghệ thông tin truyền thống.
Các kỹ thuật liên quan đến quản lý rủi ro được phát triển để xác định các yêu cầu liên quan đến việc cung cấp đảm bảo an toàn, bao gồm việc xác định các điểm yếu, lỗ hổng và các mối đe dọa và xây dựng một mô hình mối đe dọa thích hợp.
Các yêu cầu đảm bảo an toàn cũng có thể bao gồm các khía cạnh khu vực và kinh doanh, chẳng hạn như khi một bên liên quan đòi hỏi một kỹ thuật đảm bảo cụ thể như việc đánh giá bằng cách sử dụng TCVN 8709 và ISO/IEC 18045 để đáp ứng các yêu cầu thụ hưởng hay nội bộ.
Để giải quyết các yêu cầu của bên liên quan, đặc tả kỹ thuật của các yêu cầu đảm bảo an toàn có thể bao gồm sự công nhận và chấp nhận các phương pháp đảm bảo an toàn hoặc lưu đồ đảm bảo an toàn, sự công nhận lẫn nhau và mức đảm bảo tối thiểu.
Ví dụ, các yêu cầu đảm bảo an toàn bao gồm những ràng buộc về tính khắt khe của quy trình phát triển và/hoặc các yêu cầu để tìm kiếm và phân tích tác động của những lỗ hổng an toàn tiềm ẩn.
Các đặc tả kỹ thuật về yêu cầu đảm bảo an toàn cần giải quyết tất cả các yêu cầu bảo mật các bên liên quan và chứa tất cả các thành phần đảm bảo an toàn hỗ trợ lẫn nhau như đảm bảo tính chính xác và đảm bảo tính hiệu quả. Hơn nữa, các kỹ thuật đảm bảo được chấp nhận cần phải chi tiết hơn chẳng hạn như chỉ ra cụ thể các cơ quan đảm bảo, trách nhiệm của họ và các kênh truyền thông.
6.2 Các trường hợp đảm bảo an toàn
Một trường hợp đảm bảo bao gồm tuyên bố mức cao (hoặc một tập các tuyên bố) về thuộc tính của một hệ thống hoặc sản phẩm, các luận cứ có hệ thống liên quan đến các tuyên bố này và các bằng chứng và giả định rõ ràng làm cơ sở cho các luận cứ này. Luận cứ thông qua nhiều mức tuyên bố bên dưới, luận cứ có cấu trúc này sẽ liên kết giữa tuyên bố mức cao với các bằng chứng và giả định.
Một trường hợp đảm bảo an toàn là một gói đảm bảo an toàn tổng thể liên quan đến hệ thống công nghệ thông tin. Nó giải thích cách thức đáp ứng các yêu cầu đảm bảo an toàn cho hệ thống công nghệ thông tin, với độ tin cậy như thế nào. Trường hợp đảm bảo an toàn có thể được thể hiện theo nhiều cách và hình thức khác nhau. Trường hợp đảm bảo an toàn cung cấp tính bí mật và độ tin cậy cho người sử dụng hệ thống công nghệ thông tin trong vấn đề an toàn của hệ thống công nghệ thông tin.
Trường hợp đảm bảo an toàn được hỗ trợ bởi một hoặc nhiều tuyên bố đảm bảo. Những tuyên bố đảm bảo này có thể được thể hiện công khai như một phần của hệ thống công nghệ thông tin hoặc không thể hiện rõ ràng trong ví dụ, các mục trong ngôn ngữ hợp đồng liên quan tới hệ thống công nghệ thông tin hoặc được tìm thấy trong các tài liệu hỗ trợ.
Một trường hợp đảm bảo an toàn có thể giải quyết các yêu cầu an toàn thông qua việc đáp ứng các vấn đề chất lượng, độ tin cậy,… Điều này có thể được ban hành thông qua chuỗi cung ứng trong các điều khoản về các yêu cầu bằng hợp đồng để phù hợp với ISO/IEC 27001, ISO 9001 và các tiêu chuẩn tương tự.
6.2.1 Phát triển một trường hợp đảm bảo an toàn
Xây dựng một trường hợp đảm bảo an toàn liên quan đến việc xem xét các lỗ hổng, các mối đe dọa, các tác nhân đe dọa và những rủi ro là một phần của vấn đề an toàn. Tiêu chuẩn ISO/IEC 15026-2 có thể được sử dụng để cung cấp các yêu cầu tối thiểu cụ thể cho cấu trúc và các nội dung của một trường hợp đảm bảo để cải thiện tính nhất quán và tính so sánh được của các trường hợp đảm bảo và tạo điều kiện truyền thông giữa các bên liên quan, các quyết định kỹ thuật, và các cách sử dụng của các trường hợp đảm bảo.
6.2.2 Truyền thông một trường hợp đảm bảo an toàn
Trường hợp đảm bảo an toàn giải quyết các mục tiêu an toàn cho giao phẩm. Khi hệ thống công nghệ thông tin bao gồm một vài giao phẩm, các bằng chứng đảm bảo an toàn rõ ràng được trình bày tại mỗi điểm khác nhau. Khi được chấp nhận bởi một nhà cung cấp, tuyên bố đảm bảo an toàn có thể không được truyền thông thông qua chuỗi cung ứng.
Trong thực tế, bên thu mua chỉ xem xét hoặc chỉ định một trường hợp đảm bảo an toàn thích hợp với giao phẩm và không xem xét các trường hợp đảm bảo an toàn, các luận cứ và các tuyên bố vượt quá các thành phần cấp cao liên quan đến giao phẩm, điều này có nghĩa là bên cung cấp giao phẩm phải có một mối quan hệ đáng tin với bên thu mua vì an toàn theo dòng chuỗi cung ứng là một vấn đề giả định.
6.3 Bằng chứng đảm bảo an toàn
Trường hợp đảm bảo an toàn được hỗ trợ bởi các bằng chứng đảm bảo an toàn được tạo ra từ việc hỗ trợ các tuyên bố đảm bảo an toàn. Có nhiều hình thức về bằng chứng đảm bảo an toàn được trình bày để hỗ trợ một trường hợp đảm bảo an toàn. Tuy nhiên, điều quan trọng về các bằng chứng là nó có thể chứng minh được, có thể lặp lại, và có thể bảo vệ được.
Một số ví dụ về bằng chứng đảm bảo an toàn:
a) kết quả của việc kiểm tra được thực hiện trên giao phẩm và kỹ thuật lấy mẫu được sử dụng (Nhãn hiệu).
b) lịch sử quá khứ của tổ chức và những chứng nhận về sự hài lòng của khách hàng (Biểu tượng).
c) năng lực các chuyên gia – số lượng giấy chứng chỉ chuyên gia và giáo án mà các chuyên gia sử dụng để kiểm tra.
d) tính thuần thục của quy trình – kết quả đánh giá các quy trình tổ chức.
e) việc đánh giá độc lập – mục tiêu an toàn của hệ thống và kết quả đánh giá.
f) các công cụ và các phương pháp – các kiểm tra độc lập của các công cụ và đánh giá của chúng, danh tiếng của chúng về sự hoàn chỉnh, chắc chắn và hiệu quả.
g) giấy chứng nhận đưa ra bởi lưu đồ.
6.4 Tuyên bố đảm bảo an toàn
Tuyên bố đảm bảo an toàn có nhiều loại khác nhau và cũng có thể được sử dụng theo nhiều cách khác nhau, cho các mục đích khác nhau. Ví dụ, Biểu tượng (Symbol) được dùng để biểu thị các loại chip vi xử lý trong máy tính xách tay là một ví dụ về đảm bảo xuyên suốt. Hình thức này của tuyên bố đảm bảo nhằm dành cho các bên thu mua các sản phẩm đã được lắp ráp cuối cùng, không trực tiếp hướng tới các bên tích hợp các bộ phận để tạo ra sản phẩm cuối cùng. Nó được các bên tích hợp sử dụng như một phần của trường hợp đảm bảo máy tính xách tay nói chung. Các tuyên bố đảm bảo khác của trường hợp đảm bảo các chip vi xử lý sẽ được hướng trực tiếp cho các bên tích hợp và không được trình bày cho bên thu mua.
Tuyên bố đảm bảo thường được trình diễn như “Nhãn hiệu hay Biểu tượng” có thể được áp dụng cho sản phẩm hoặc dịch vụ. Các nhãn hiệu và biểu tượng có nhiều loại từ nhãn hiệu đăng ký và nhãn hiệu chứng nhận bao gồm việc kiểm tra và cấp giấy chứng nhận “bên thứ ba” của sản phẩm hoặc dịch vụ, đến các biểu tượng bao gồm logo đã đăng ký cho sản phẩm hoặc bộ phận lắp ráp phụ. Biểu tượng thường được sử dụng để “xác thực” nguồn gốc của sản phẩm hoặc dịch vụ.
Điều 8 mô tả khái niệm của phương pháp SACA, một yếu tố quan trọng trong việc đưa ra tuyên bố đảm bảo an toàn. Tuyên bố về các bẫy cần tránh là một tuyên bố tiêu cực. Ví dụ là kiểu tuyên bố này là “quái vật hồ Loch Ness không tồn tại”. Kiểu tuyên bố này không thể chứng minh được, ta chỉ có thể chứng minh quái vật hồ Loch Ness tồn tại, nếu nó không tồn tại thì không thể chứng minh được.
Một thuộc tính quan trọng của tuyên bố đảm bảo là chúng phải có khả năng chứng minh, ở ví dụ trên, đó là điều phi vật thể cho dù ta “tin tưởng” rằng quái vật hồ Loch Ness tồn tại hay không, đây là vấn đề của sự tin tưởng; tuy nhiên bằng chứng không thể chứng minh rằng nó không tồn tại. Các tuyên bố đảm bảo là về các bằng chứng, không phải sự tin tưởng, vì vậy các tuyên bố tiêu cực cần được tránh dùng.
6.5 Luận cứ đảm bảo an toàn
Vấn đề chung của các luận cứ đảm bảo được mô tả trong ISO/IEC 15026 -1.
Các luận cứ đảm bảo an toàn chứng minh các tuyên bố đảm bảo an toàn. Có thể một hoặc nhiều luận cứ đảm bảo an toàn để chứng minh một tuyên bố đảm bảo an toàn. Trong một số trường hợp, một luận cứ đảm bảo an toàn duy nhất có thể được sử dụng để chứng minh nhiều tuyên bố đảm bảo an toàn.
Luận cứ đảm bảo an toàn có thể được xây dựng theo nhiều cách, tuy nhiên điều quan trọng phải nhớ rằng chúng là những bằng chứng được cung cấp để chứng minh các đảm bảo được tuyên bố và do đó các luận cứ cần được cấu trúc theo cách thức thích hợp.
VÍ DỤ: Xem xét một tuyên bố đảm bảo rằng một sản phẩm phần mềm có “không có khả năng khai thác lỗi tràn bộ đệm”. Luận cứ đảm bảo được đưa ra để chứng minh tuyên bố đó có thể là sản phẩm phần mềm là đối tượng để phân tích tĩnh bằng một công cụ được thiết kế để kiểm tra khả năng khai thác lỗi tràn bộ đệm. Cung cấp một công cụ uy tín và được công nhận đã được sử dụng, luận cứ này có thể gọi là “Bằng chứng” đầy đủ.
Trong trường hợp của một Nhãn hiệu, luận cứ đảm bảo an toàn chứng minh tuyên bố đảm bảo an toàn được thể hiện bởi Nhãn hiệu là các yêu cầu và chi tiết kiểm tra liên quan đến việc sử dụng Nhãn hiệu. Trong trường hợp của một Biểu tượng, tình huống có khác một chút với luận cứ đảm bảo an toàn đã được chứng minh bằng danh tiếng của tổ chức mà họ sở hữu Biểu tượng hoặc thứ mà Biểu tượng thể hiện. Điều này cũng có thể được thể hiện bằng các bảo hành và đảm bảo từ bên cung cấp có liên quan đến sản phẩm hoặc dịch vụ.
Các luận cứ đảm bảo an toàn khác chứng minh các tuyên bố đảm bảo an toàn, đặc biệt là liên quan đến an toàn, có thể liên quan đến các kỹ sư an toàn, những người đã thiết kế sản phẩm hoặc dịch vụ, và khả năng chuyên môn của họ để thực hiện công việc.
VÍ DỤ: Luận cứ có thể tuyên bố rằng các kỹ sư an toàn đã được chứng nhận chuyên môn bởi Chương trình chứng nhận chuyên gia an toàn hệ thống quốc tế (ISSPCS).
Các loại khác của luận cứ đảm bảo an toàn có thể liên quan đến các quy trình dùng để thiết kế và sản xuất các sản phẩm hoặc các quy trình dùng để cung cấp dịch vụ. Trong trường hợp này, các luận cứ có thể sẽ liên quan đến mức độ chắc chắn của quy trình, hoặc tính chắc chắn của hồ sơ của quy trình.
VÍ DỤ: Sử dụng ISO/IEC 21827 SSE-CMM để tuyên bố một mức độ chắn chắn cho quy trình đảm bảo an toàn trong một tổ chức.
Một luận cứ đảm bảo an toàn có thể được xây dựng dựa trên việc đánh giá và kiểm tra của một sản phẩm. Phương pháp tiếp cận này thường được sử dụng cho vấn đề an toàn liên quan sản phẩm.
VÍ DỤ: Với việc đánh giá an toàn hay lưu đồ tiêu chí chung, tiêu chuẩn ISO/IEC TCVN 8709. Trong trường hợp này, các luận cứ đảm bảo dựa trên các hồ sơ bảo vệ (PP) của sản phẩm và một gói các yêu cầu liên quan, chẳng hạn như mức đảm bảo đánh giá (EAL) đạt được.
Như đã được chứng minh, luận cứ đảm bảo an toàn có thể được xây dựng bằng nhiều cách khác nhau và rút ra từ nhiều nguồn khác nhau. Trong các ví dụ nêu trên, các luận cứ đảm bảo an toàn đã được dựa trên:
a) việc kiểm tra và đánh giá các sản phẩm hoặc dịch vụ;
b) danh tiếng của nhà cung cấp;
c) năng lực chuyên môn của các kỹ sư thực hiện công việc;
d) tính chắc chắn của quy trình được sử dụng.
Các yếu tố khác có thể được sử dụng như một cơ sở cho việc hình thành một luận cứ bao gồm:
a) các phương pháp được sử dụng trong thiết kế sản phẩm hoặc dịch vụ;
b) các công cụ được sử dụng trong thiết kế của sản phẩm;
c) các công cụ sử dụng trong việc thực hiện dịch vụ.
Tất cả những điều trên có thể được sử dụng để chứng minh tuyên bố đảm bảo an toàn. Như đã thảo luận ở trên, chúng được sử dụng trong trường hợp riêng biệt phụ thuộc phần lớn vào nhu cầu của người nhận đảm bảo và cách mà họ sẽ sử dụng các trường hợp đảm bảo an toàn liên quan đến sản phẩm hoặc dịch vụ.
7 Kỹ thuật SACA
Điều này giới thiệu khái niệm về kỹ thuật SACA, các quy trình cơ bản mà các phương pháp đảm bảo an toàn dựa vào. Chủ đề này và khung cho việc so sánh các phương pháp đảm bảo an toàn khác nhau dựa trên những kỹ thuật được trình bày chi tiết hơn trong phần 2 của tiêu chuẩn này.
7.1 Kỹ thuật
Thông thường, các yêu cầu kỹ thuật để cung cấp kết quả SACA được trình bày riêng biệt với các phương pháp để kiểm tra sự đáp ứng các yêu cầu. Điều này cho phép các phương pháp SACA khác nhau có thể được áp dụng cho một tập hợp các yêu cầu đặc thù, sự hiểu biết về phương pháp được áp dụng là một phần quan trọng của việc hiểu biết về sự đảm bảo được đưa ra.
Hiệu quả ám chỉ đến sự thích hợp của các chức năng an toàn của giao phẩm để chống lại các mối đe dọa đã nhận biết và xác định được. Ngược lại, đảm bảo tính chính xác liên quan đến việc đánh giá giao phẩm để xác minh việc thực hiện đúng theo thiết kế. Phần tiếp theo sẽ cho thấy tính hiệu quả và tính chính xác là hai thuộc tính quan trọng trong đảm bảo và không thể đứng một mình vì chúng giải quyết các khía cạnh quan trọng của giao phẩm.
Nếu chức năng an toàn của giao phẩm giải quyết được các mối đe dọa tiềm năng, nhưng các chức năng này không được phân tích để thiết lập việc thiết kế và triển khai đúng của nó, thì nó không thể có được sự tin cậy rằng giao phẩm sẽ chịu được một cuộc tấn công. Trong ví dụ này, nó được xem là việc đảm bảo tính hiệu quả được thiết lập nhưng việc đảm bảo tính chính xác không có do thiếu xác minh chức năng an toàn. Tương tự như vậy, nếu việc phân tích được tìm thấy trong việc thiết kế và triển khai các chức năng an toàn của giao phẩm là đúng; tuy nhiên, việc thiết kế không bao gồm các chức năng an toàn thích hợp để giải quyết các mối đe dọa có thể xảy ra, thì nó không thể có được sự tin cậy rằng giao phẩm sẽ chịu một cuộc tấn công bởi những mối đe dọa. Trong ví dụ này, mặc dù việc đảm bảo tính chính xác là có, nhưng nó thiếu sự đảm bảo tính hiệu quả do việc triển khai các chức năng an toàn không hiệu quả chống lại các mối đe dọa có thể xảy ra. Để đạt được sự đảm bảo toàn diện, giao phẩm phải được đánh giá để đảm bảo thiết kế, triển khai và vận hành chính xác (yếu tố chính xác) và giao phẩm phải cung cấp các chức năng an toàn thích hợp để chống lại các mối đe dọa được xác định (yếu tố hiệu quả).
7.1.1 Hiệu quả (hoặc đánh giá)
Một phương pháp đánh giá cho phép tuyên bố đảm bảo an toàn được điều chỉnh để đáp ứng giao phẩm hoặc các yêu cầu đảm bảo cụ thể của các bên liên quan. Nó cung cấp một cách rất linh hoạt việc cung cấp một hay nhiều tuyên bố đảm bảo an toàn, nhưng đòi hỏi những người dùng tuyên bố đảm bảo an toàn này hiểu được hoàn toàn các đảm bảo thực sự được cung cấp. Thông thường, các tuyên bố đảm bảo được tạo bởi một trường hợp về phương pháp áp dụng có thể không được so sánh trực tiếp với các trường hợp khác.
VÍ DỤ: TCVN 8709 cùng với phương pháp kiểm tra trong ISO/IEC 18405 cung cấp một phương pháp đảm bảo an toàn có tạo ra các bằng chứng đảm bảo bằng cách đánh giá các tuyên bố an toàn tạo bởi bên phát triển sử dụng một danh mục chức năng an toàn và thành phần đảm bảo. Phương pháp này cũng xem xét các vấn đề an toàn trình bày cho bên đánh giá, những người mà sau đó có thể đánh giá tính hiệu quả của đích đánh giá trong việc giải quyết vấn đề an toàn.
VÍ DỤ: TCVN ISO/IEC 27001 là một tiêu chuẩn cung cấp yêu cầu cho một hệ thống quản lý thông tin được phát triển và vận hành bởi một tổ chức. Phương pháp đảm bảo tính hiệu quả được xây dựng vào hệ thống quản lý như vậy được cung cấp bởi các quy trình xem xét giám sát bắt buộc.
7.1.2 Tính đúng đắn (hoặc phù hợp)
Một phương pháp đúng đắn tạo nên một tuyên bố đảm bảo dựa trên sự phù hợp với đặc tả được tiêu chuẩn hóa, thường có ít sự linh hoạt. Hệ thống hoặc đáp ứng các yêu cầu quy định cho hoặc không.
VÍ DỤ: Đảm bảo hình thành từ sự kết hợp của các đặc tả được đưa ra trong ISO/IEC 19790 – Yêu cầu an toàn cho các mô-đun mã hóa và sử dụng các phương pháp được đưa ra trong ISO/IEC 24759 – Yêu cầu kiểm tra cho mô-đun mã hóa cung cấp bằng chứng đảm bảo rằng những tuyên bố an toàn được thực hiện bởi các nhà phát triển. Mô đun mã hóa này thích hợp với các yêu cầu trong ISO/IEC 19790.
Đối với những giao phẩm ít phức tạp hơn chẳng hạn như thuật toán mã hóa hoặc một số giao thức tiêu chuẩn thì có thể cung cấp sự đảm bảo rằng các đặc tả đã được triển khai một cách chính xác. Phương pháp này đương nhiên bao gồm sự phù hợp của các đặc tả và cũng cung cấp đảm bảo hơn nữa rằng không có lỗi xảy ra tức thì trong thời gian triển khai. Khái niệm này thường được gọi là “tính đúng đắn trong triển khai”.
VÍ DỤ: Kiểm tra các thuật toán mã hóa đã tiêu chuẩn hóa, chẳng hạn như trong ISO/IEC 18033 hỗ trợ một tuyên bố rằng chúng đã được triển khai đúng đắn.
7.1.3 Đảm bảo dự đoán
Đây là một yếu tố môi trường liên quan đến tổ chức chịu trách nhiệm về giao phẩm (ví dụ bên phát triển, bên tích hợp, bên cung cấp hoặc bên điều hành), mà mặc dù tính năng động không thể được giảm do lịch sử công nhận về thực hiện đặc biệt chẳng hạn như việc thực hiện nhất quán và lặp đi lặp lại để đáp ứng chính sách an toàn của nó hoặc để đáp ứng các tuyên bố đảm bảo. Nhiều mô hình hoàn thiện năng lực giải quyết đảm bảo dự đoán.
VÍ DỤ: chứng nhận một vị trí thực hiện theo một số lưu đồ tiêu chí chung là hỗ trợ một tuyên bố rằng quá trình phát triển tổ chức là lặp lại và có khả năng tạo ra kết quả phù hợp.
VÍ DỤ: ISO/IEC 21827 là một tiêu chuẩn cung cấp các yêu cầu về đảm bảo đưa ra bằng chứng đảm bảo bằng cách đánh giá các quy trình kỹ thuật an toàn của tổ chức và không phải là chuyển giao trực tiếp. Mặc dù yêu cầu này được công bố như là một tiêu chuẩn ISO/IEC nhưng các phương pháp kiểm tra chúng không ghi thời gian tiêu chuẩn hóa trong ISO/IEC.
Nhìn chung, các kỹ thuật dựa trên việc đánh giá hoặc đảm bảo dự đoán không cung cấp số lượng mức độ của tính bí mật trong việc đảm bảo nhưng thay vì cung cấp một bản tường thuật hoặc các phương tiện khác về việc cung cấp thông tin chủ quan mà có thể được sử dụng theo một cách nào đó để xác định số lượng đảm bảo. Các công nghệ phù hợp có nhiều khả năng để triển khai thành công các phương pháp định lượng.
7.2 Lựa chọn kỹ thuật đảm bảo an toàn
Việc xác định đảm bảo an toàn và kỹ thuật thích hợp là một quyết định dựa trên các chính sách đảm bảo an toàn tổ chức, các yêu cầu kinh doanh, và các loại giao phẩm (ví dụ như sản phẩm, quy trình, môi trường, hệ thống, dịch vụ hoặc nhân viên). Ví dụ, một số kỹ thuật đảm bảo an toàn chỉ áp dụng cho quy trình tổ chức (ví dụ như kỹ thuật dựa theo ISO/IEC 21827 và TCVN ISO/IEC 27001) trong khi các kỹ thuật khác được áp dụng cho các sản phẩm (ví dụ như ISO/IEC 19790). Một số được áp dụng cho cả hai (ví dụ TCVN 8709).
Kỹ thuật đảm bảo đã chọn nên phù hợp với môi trường hoạt động của tổ chức và có khả năng kiểm tra các tính chất mong muốn và các giai đoạn vòng đời của giao phẩm. Việc lựa chọn phương pháp đảm bảo phải đưa vào bản kê khai các tài nguyên sẵn có (thời gian, nhân sự, ngân sách, vv) để đảm bảo rằng các nguồn tài nguyên được sử dụng một cách hợp lý đối với các loại hình và số lượng đảm bảo thu được. Ví dụ, thêm một biện pháp bảo vệ có giá 50.000 $ vào một giao phẩm có mức đảm bảo thấp sẽ là không hợp lý. Tương tự như vậy, không cần chọn những kỹ thuật đảm bảo đánh giá có chi phí cao khi mà công nghệ chi phí thấp cũng có thể chấp nhận được. Một tổ chức có thể xem xét việc đánh giá rủi ro của họ, bất kỳ ủy nhiệm nào có liên quan, cũng như ngân sách và thời gian hiện có. Đối với tổ chức (ví dụ như ban quản trị) được yêu cầu lựa chọn các nhà cung cấp có các sản phẩm an toàn công nghệ thông tin đã được đánh giá và phát triển, và sử dụng sản phẩm đã được đánh giá an toàn công nghệ thông tin để đạt được sự đảm bảo, điều này có thể có ít cơ sở cho một quá trình quyết định kéo dài do đó loại trừ hầu hết hoặc tất cả các chi phí các nguồn lực cho việc xem xét các tùy chọn.
VÍ DỤ: Một tổ chức sử dụng một tiêu chuẩn ISO/IEC 21827 dựa vào những kĩ thuật đảm bảo để thiết lập đảm bảo dự đoán cho ứng dụng web của họ để ngăn chặn những người truy cập trái phép vào các dữ liệu nhạy cảm. Điều này đòi hỏi một đánh giá các quy trình xung quanh việc phát triển, triển khai và vận hành của trang web bao gồm các quy trình triển khai an toàn và các chính sách hoạt động. Dựa vào kết quả, một luận cứ đảm bảo sẽ được đưa ra cùng với một xếp hạng mức độ hoàn thiện của tổ chức. Với việc đảm bảo này, một kỹ thuật là đủ, chẳng hạn như cơ quan đảm bảo chỉ cần để giải quyết chính sách đảm bảo an toàn nội bộ của họ.
VÍ DỤ: Một ban quản trị sử dụng tiêu chuẩn TCVN 8709 (tiêu chí chung) dựa trên phương pháp đảm bảo để đạt được sự đảm bảo cao. Bởi vì nó được yêu cầu phải sử dụng phương pháp đảm bảo đặc thù này để đáp ứng yêu cầu an toàn của việc quản trị cụ thể, các kỹ thuật đánh giá đã được triển khai. Ví dụ này cũng minh họa vai trò của các cơ quan phê chuẩn trong việc quyết định các phương pháp và kỹ thuật có thể áp dụng được.
Ở nơi mà chính sách hay quy định hiện hành không quy định kỹ thuật đảm bảo, phương pháp hoặc xếp hạng cụ thể, việc lựa chọn một phương pháp đảm bảo và mức độ đảm bảo được lựa chọn trong thực hiện các yêu cầu đảm bảo an toàn xác định. Tuy nhiên, có thể là quá trình quản lý rủi ro cho bên thu mua đặc thù có thể chỉ ra các tình huống mà đảm bảo an toàn khác nhau được chỉ định.
Ngay cả khi một phương pháp đảm bảo được ủy quyền, có thể có một số tùy chọn có sẵn, chẳng hạn như:
a) cái gì cần đảm bảo.
b) mức độ đảm bảo nào là cần thiết.
c) phòng thử nghiệm đánh giá nào được sử dụng;
d) các dịch vụ công nhận và chứng nhận nào được sử dụng.
Có rất nhiều kỹ thuật đảm bảo an toàn khác nhau có sẵn do đó các hướng dẫn là cần thiết để hỗ trợ các bên liên quan trong việc lựa chọn và áp dụng một kỹ thuật đảm bảo.
7.2.1 Xem xét tối ưu hóa
Cơ quan đảm bảo cần phải xác định sự kết hợp đúng đắn của các kỹ thuật đảm bảo để đáp ứng các yêu cầu của tổ chức.
Cơ quan đảm bảo có thể xem xét các trường hợp đảm bảo trước đó hoặc hoàn toàn hoặc một phần và có thể phải thực hiện đánh giá nếu kết quả đảm bảo trước là chưa thỏa đáng. Hơn nữa, là cơ quan đảm bảo sẽ chịu trách nhiệm cuối cùng về việc đảm bảo an toàn cuối cùng của giao phẩm.
Đảm bảo an toàn có thể được trình bày với các bên thu mua như một sự đảm bảo xuyên suốt từ bên cung ứng của một thành phần, sản phẩm COTS, bên tích hợp hệ thống hoặc bên cung cấp dịch vụ theo một số hình thức bảo lãnh hoặc bảo hành về hiệu suất của giao phẩm. Việc xem xét thành phần giao phẩm cung cấp đảm bảo an toàn cần lưu ý rằng trong việc tích hợp một hoặc nhiều giao phẩm vào hệ thống mục tiêu và môi trường cuối cùng của họ có tác động tiêu cực đến kết quả mức độ đảm bảo an toàn. Do đó, điều khoản về đảm bảo an toàn bổ sung có thể được đưa ra.
8 Phương pháp SACA
Điều khoản này mở rộng định nghĩa phương pháp SACA (định nghĩa trong 3.26). Thảo luận các khía cạnh khác nhau của đảm bảo an toàn nhằm giải thích các khía cạnh khác nhau của đảm bảo an toàn có thể ảnh hưởng như thế nào tới an toàn công nghệ thông tin.
Việc áp dụng có tính hệ thống các hoạt động đảm bảo an toàn thích hợp là thiết lập nên tính bí mật đáp ứng mục tiêu an toàn của giao phẩm. Tính bí mật thu được bằng cách xem xét lại bằng chứng đảm bảo đã đạt được thông qua các quy trình đánh giá và hành động trong việc phát triển, triển khai, hoạt động, và kinh nghiệm trong việc sử dụng thực tế của giao phẩm. Bất kỳ các hành động có thể làm giảm sự không chắc chắn bởi việc đưa ra các bằng chứng chứng nhận tính hữu ích của các thuộc tính đúng đắn, hiệu quả và chất lượng của giao phẩm trong việc xác định đảm bảo an toàn. Thừa nhận một số loại bằng chứng đưa ra các tuyên bố mà chúng hỗ trợ rõ ràng hơn các loại khác, quan trọng là tạo ra một luận cứ đảm bảo toàn diện mà thiết lập chắc chắn các loại và số lượng đảm bảo đạt được từ các phương pháp đảm bảo đã áp dụng.
CHÚ THÍCH: Khái niệm về một phương pháp đánh giá sự phù hợp (như là một tập hợp con của hệ thống đánh giá sự phù hợp) được giới thiệu trong Tiêu chuẩn này từ khi nó không được đưa ra trong ISO/IEC 17000.
8.1 Phương pháp đánh giá sự phù hợp đảm bảo an toàn (SACA)
Phương pháp SACA đã chọn nên là phù hợp với môi trường của tổ chức và có khả năng kiểm tra các tuyên bố đã thực hiện bao gồm các yêu cầu an toàn chức năng thích hợp và đảm bảo đã cung cấp thông qua các quy trình đã định nghĩa trong các giai đoạn vòng đời khác nhau của giao phẩm.
Việc lựa chọn phương pháp đưa vào tính toán nguồn lực sẵn sàng (thời gian, nhân sự, ngân sách,…) để đảm bảo rằng các nguồn lực chi tiêu vào việc cung cấp đảm bảo an toàn là hợp lý cho loại và số lượng đảm bảo cần thiết. Việc xem xét như là thêm một bảo vệ an toàn cho giao phẩm với chi phí rất cao để cung cấp đảm bảo “thấp” là không hợp lý, cũng tương tự vậy, không có nhu cầu lựa chọn phương pháp đánh giá sự phù hợp đảm bảo an toàn với chi phí cao khi mà phương pháp với chi phí thấp hơn sẽ được chấp nhận.
Một tổ chức có thể xem xét mục đích sử dụng của giao phẩm, đánh giá rủi ro, bất kỳ yêu cầu có liên quan từ các chính sách, quy định,…, cũng như ngân sách và thời gian sẵn sàng trong việc lựa chọn phương pháp SACA thích hợp. Đối với một số tổ chức (ví dụ như cơ quan chính phủ) được yêu cầu thông qua chính sách để lựa chọn nhà cung cấp cung cấp giao phẩm với các tuyên bố đã xác nhận thông qua một lưu đồ SACA riêng biệt, có thể đó là cơ sở cho một quá trình ra quyết định lâu dài.
VÍ DỤ 1: Một tổ chức sử dụng phương pháp ISO/IEC 21827 để thiết lập đảm bảo tiên đoán về ứng dụng web của họ để ngăn chặn người truy cập trái phép vào dữ liệu nhạy cảm. Điều này đòi hỏi việc đánh giá các quy trình xung quanh việc phát triển, triển khai và hoạt động của ứng dụng bao gồm các quy trình thực thi các chính sách an toàn và điều hành. Dựa trên những phát hiện, một tuyên bố đảm bảo cùng với đánh giá mức độ hoàn thiện của việc tổ chức có thể được thực hiện. Phương pháp đảm bảo này nên đáp ứng giống như tổ chức là cơ quan đảm bảo chỉ cần giải quyết chính sách đảm bảo an toàn bên trong của tổ chức đó.
VÍ DỤ 2: Cơ quan chính phủ đã yêu cầu bằng quy định đưa ra rằng nhà cung cấp sử dụng phương pháp đảm bảo an toàn dựa theo tiêu chuẩn TCVN 8709 cung cấp đánh giá bên thứ 3 về các tuyên bố đảm bảo an toàn cho sản phẩm.
Ví dụ thứ hai giải thích phạm vi mà cơ quan đảm bảo có thể có trong các phương pháp và kỹ thuật đảm bảo an toàn định rõ. Trong một số trường hợp không đưa ra được tuyên bố liên quan đến phương pháp đảm bảo nào được ưu tiên bởi cơ quan đảm bảo. Tại nơi chính sách hay quy định hiện hành không quy định một phương pháp hay đánh giá đảm bảo an toàn riêng biệt, việc lựa chọn một phương pháp đảm bảo và mức độ đảm bảo phù hợp đã cung cấp nên được lựa chọn dựa vào việc xem xét các yêu cầu đảm bảo nguồn gốc từ các mục tiêu an toàn của giao phẩm và các nguồn yêu cầu an toàn khác.
Ngay cả khi một phương pháp đánh giá đảm bảo an toàn được yêu cầu, có thể có một số tùy chọn sẵn có, chẳng hạn như:
– Đánh giá cái gì.
– Mức độ đảm bảo an toàn đã cung cấp.
– Phòng thử nghiệm nào được sử dụng để đánh giá.
– Lưu đồ nào được sử dụng để chứng nhận và công nhận.
8.1.1 Các đặc điểm của phương pháp SACA
Các phương pháp SACA khác nhau có thể được định nghĩa, xác định mục tiêu đảm bảo khác nhau, các kiểu công nghệ khác nhau và mức độ bảo đảm khác nhau. Tất cả các phương pháp đó cần có các đặc điểm chung sau:
– Cần xác định rõ mục tiêu đảm bảo.
– Cần xác định rõ công nghệ nào có thể được áp dụng
– Cần xác định rõ đầu vào cần thiết để thực hiện việc đánh giá.
– Cần xác định rõ phương thức đánh giá và các bước thực hiện từng phần đánh giá.
– Cần xác định rõ các kết quả đánh giá và cách thức mà các kết quả đó có thể và nên được sử dụng bởi người sử dụng sản phẩm, nhà tích hợp sản phẩm hay là đầu vào để đánh giá đảm bảo sản phẩm đó là bao gồm đối tượng đánh giá như là một thành phần.
– Cần xác định rõ những hạn chế của phương pháp đánh giá, đưa ra cái gì không thể được đánh giá qua phương pháp cũng như những hạn chế về việc sử dụng các kết quả đánh giá.
8.1.2 Thành phần của phương pháp đánh giá sự phù hợp đảm bảo an toàn
Một phương pháp đánh giá đảm bảo an toàn bao gồm:
– Mô tả các tuyên bố đảm bảo an toàn đã đưa ra. Trong nhiều trường hợp đây là một tiêu chuẩn hoặc đặc tả mô tả chi tiết các gói yêu cầu đảm bảo an toàn.
Một hay nhiều phương pháp đánh giá để đánh giá, đánh giá hay kiểm định các tuyên bố đảm bảo an toàn đã đưa ra.
– Hướng dẫn hoặc tài liệu hỗ trợ.
– Giải thích về tiêu chuẩn, đặc tả hoặc phương pháp cần thiết cho các công nghệ đặc trưng, chính sách lưu đồ, hoặc do đưa ra kiến thức về phương pháp.
– Bên đánh giá, bên kiểm định hay bên đánh giá có năng lực
– Một lưu đồ đánh giá sự phù hợp tùy chọn cung cấp tính bí mật trong bằng chứng đã đưa ra thông qua việc cung cấp một hệ thống đánh giá sự phù hợp.
– Các công cụ có thể được sử dụng để hỗ trợ phương pháp.
CHÚ THÍCH: Trong một số trường hợp tiêu chuẩn hoặc đặc tả có thể được kết hợp với phương pháp kiểm định hoặc đánh giá trong một tài liệu duy nhất, Ví dụ PCI DSS.
Hình 3- Đánh giá sự phù hợp đảm bảo an toàn, hình sau đây cho thấy các thành phần của phương pháp SACA trong bối cảnh với mô hình được mô tả trong Hình 2 – Mối quan hệ giữa đảm bảo an toàn và an toàn cho giao phẩm.
Hình 3 – Đánh giá sự phù hợp đảm bảo an toàn
8.1.3 Phương pháp chuyên biệt về đảm bảo an toàn
Hiện tại có nhiều phương pháp đánh giá sự phù hợp đảm bảo với một số đặc trưng ít hơn cho việc đảm bảo an toàn. Tuy nhiên, các phương pháp đảm bảo không về an toàn cũng có thể chứa các thuộc tính đảm bảo liên quan đến đảm bảo an toàn.
Các phương pháp đánh giá chắc chắn đặc biệt tập trung vào việc định rõ tập tính năng an toàn đầy đủ và phù hợp, thường phản ánh một kịch bản hay bản thực hành tốt về các nguy cơ tiêu biểu. Các phương pháp đảm bảo khác nhau có thể có một số thành phần hoặc các khía cạnh đảm bảo chung.
Tất cả những yếu tố này sẽ có một ảnh hưởng tới khung đảm bảo an toàn, đặc biệt về định nghĩa liên quan tới hệ thống đo lường (metrics). Mối quan hệ giữa các phương pháp đảm bảo sẽ đưa ra những tính toán cho các yếu tố này.
Ví dụ về các phương pháp đánh giá đảm bảo an toàn bao gồm việc sử dụng các tiêu chuẩn TCVN 8709, ISO/IEC 18045; ISO/IEC 19790 với ISO/IEC 24759; TCVN ISO/IEC 27001 có sự tham chiếu tới ISO/IEC 27007; FIPS 140-2 với các yêu cầu kiểm định nguồn gốc liên quan; PCI DSS dưới sự bảo trợ của PCI SSC.
8.1.4 Phương pháp không chuyên biệt về đảm bảo an toàn
Do sẵn có số lượng nhỏ các phương pháp chuyên biệt về đảm bảo an toàn, quan trọng là nhận ra giá trị của tất cả các phương pháp đảm bảo từ nhiều phương pháp đảm bảo không liên quan đến an toàn được sử dụng trong khắp ngành công nghiệp công nghệ thông tin. Bằng chứng đảm bảo thường xuyên có trong các dạng tài liệu được phát triển trong suốt quá trình thông thường của các hành động kỹ thuật công nghệ thông tin. Bất cứ điều gì có thể được sử dụng để xây dựng một luận cứ đảm bảo và qua đó làm giảm rủi ro không chắc chắn được kết hợp với một giao phẩm riêng biệt có tầm quan trọng đáng kể.
Mục đích ở đây là để truyền đạt các giá trị của phương pháp đảm bảo an toàn không thuộc công nghệ thông tin và không hạ thấp giá trị của các phương pháp chuyên biệt về đảm bảo an toàn. Đảm bảo an toàn có thể được bắt nguồn từ nhiều nguồn và không nên giảm giá đơn giản bởi vì nó không đến từ một phương pháp đảm bảo an toàn nào đã được công nhận. Ngoài ra, quan trọng là nhận ra nguồn gốc bằng chứng và đưa ra việc tính toán khi phát triển các luận cứ đảm bảo. Hơn nữa, người ta phải làm quen với các yêu cầu đảm bảo và an toàn của từng phương pháp và hiểu được giá trị của bằng chứng và nguồn gốc của nó để đảm bảo rằng nó đáp ứng được nhu cầu của họ. Phần 2 của bộ tiêu chuẩn này cung cấp hướng dẫn về quá trình này.
Trên thực tế, các phương pháp đảm bảo không liên quan về an toàn này là một phần quan trọng trong việc phát triển một trường hợp đảm bảo. Xem xét ví dụ trước đó về mỗi tụ điện là sự chịu lỗi. Không giống như nhà sản xuất tụ điện cung cấp bằng chứng đảm bảo an toàn riêng biệt. Tuy nhiên việc áp dụng phương pháp đảm bảo chất lượng sẽ cung cấp tính bí mật mà các tụ điện có trong đặc tả mà tuyên bố an toàn dựa vào.
Ví dụ về các phương pháp không chuyên biệt về đảm bảo an toàn bao gồm việc sử dụng các tiêu chuẩn ISO 9001, ISO 15504, và CMMI và RMM của SEI.
8.2 Tiếp cận các phương pháp SACA
Nhiều phương pháp đảm bảo luôn sẵn sàng để lựa chọn và thực hiện một sự lựa chọn dựa trên các thuộc tính của phương pháp quan trọng đối với khả năng phục vụ bên liên quan để tối ưu hóa trong giới hạn về nguồn lực và khung thời gian. Phương pháp đảm bảo an toàn có thể được phân loại theo các cách tiếp cận đã sử dụng.
8.2.1 Các cách tiếp cận
Bất kể giao phẩm là một sản phẩm, quá trình hay dịch vụ…, phương pháp kiểm định đảm bảo an toàn sử dụng phương pháp tiếp cận đảm bảo mức cao nhất định.
8.2.1.1 Đánh giá trực tiếp
Đánh giá trực tiếp giao phẩm liên quan đến việc kiểm tra giao phẩm (có thể bao gồm sản phẩm, hệ thống, dịch vụ, quy trình phát triển,…). Các thành phần tiên đoán, như là việc kiểm tra các yếu tố môi trường đóng góp vào chất lượng của các quy trình và việc sản xuất giao phẩm bao gồm ví dụ như nhân sự và cơ sở vật chất (sự phát triển, sản xuất, phân phát, hoạt động, …) và có thể không bao gồm tất cả.
8.2.1.2 Đánh giá gián tiếp
Đánh giá gián tiếp thông qua phân tích quy trình liên quan đến việc kiểm tra các quy trình tổ chức đã sử dụng trong việc sản xuất và hoạt động của giao phẩm trong suốt vòng đời (phát triển, triển khai, phân phát, kiểm định, bảo trì, xử lý, vv.) Đảm bảo thu được thông qua việc kết luận rằng các quá trình đã thực hiện bởi những người làm ảnh hưởng tới chất lượng của sự phát triển và thực thi giao phẩm và qua đó mang lại sự đảm bảo an toàn khi áp dụng cho giao phẩm an toàn công nghệ thông tin. Đánh giá gián tiếp hoặc bảo mật bằng mật khẩu, có một thành phần tiên đoán mạnh đặc trưng.
8.2.1.3 Đánh giá tĩnh
Trong đánh giá tĩnh mục tiêu đánh được thực hiện bên ngoài môi trường dự kiến và giả định hoạt động của nó.
8.2.1.4 Đánh giá động
Trong đánh giá động việc đánh giá được thực hiện trong môi trường hoạt động dự kiến.
8.2.2 Tiếp cận kết hợp
Thông thường phương pháp đánh giá an toàn riêng biệt sử dụng các thành phần của cả hai tiếp cận trực tiếp và gián tiếp. Mức độ mà mỗi phương pháp sử dụng tiếp cận có thể được mô tả đặc điểm bằng cách sử dụng sự đo lường để chỉ ra trọng tâm của phương pháp. Trong bảng dưới đây một số phương pháp ví dụ được đưa ra cùng với dấu chỉ trọng tâm của chúng. Một ô trống thể hiện tiếp cận là không được áp dụng, và “+”, “+ +” và “+ + +” thể hiện cấp độ trọng tâm được sử dụng bởi phương pháp đó với “+” là ít được chú trọng và “+ + +” là chú trọng nhiều.
Bảng 1 – Ví dụ về các phương pháp đảm bảo an toàn chỉ ra cách tiếp cận và cấp độ
|
Phương pháp SACA |
Tiếp cận |
||
|
Hiệu quả trực tiếp |
Phù hợp trực tiếp |
Gián tiếp |
|
| ISO/IEC 18045 | +++ | + | ++ |
| ISO/IEC 19790 | + | +++ | |
| ISO/IEC 21827 | +++ | ||
| ISO/IEC 27001 | +++ | + | ++ |
| PCI DSS | +++ | ||
Dưới đây là kết hợp các tiếp cận có thể xảy ra
a) Tĩnh Trực tiếp
Một tiếp cận tĩnh trực tiếp được áp dụng cho giao phẩm công nghệ thông tin, ví dụ, COTS phân phát trước khi chúng hoạt động.
VÍ DỤ: Một đánh giá tiêu chí chung của chức năng an toàn về một sản phẩm công nghệ thông tin.
b) Động Trực tiếp
Một tiếp cận động trực tiếp được áp dụng cho giao phẩm công nghệ thông tin trong hoạt động.
VÍ DỤ: Tiêu chuẩn ISO/IEC 19791, đánh giá an toàn về các hệ thống hoạt động, chứng nhận và công nhận của hệ thống tuân theo các yêu cầu pháp lý, giám sát liên tục.
c) Tĩnh Gián tiếp
Một tiếp cận tĩnh gián tiếp được áp dụng cho quy trình vòng đời sử dụng để tạo ra và cung cấp giao phẩm.
VÍ DỤ: SEI CMMi; Chứng nhận bên tiêu chí chung.
d) Động Gián tiếp
Một tiếp cận tĩnh gián tiếp kiểm tra quy trình đã sử dụng trong hoạt động của giao phẩm.
VÍ DỤ: Phù hợp ISO/IEC 27001, CMMI.
8.3 Phân tách các giai đoạn vòng đời
Như lỗi do con người, các lỗi thiết bị, các lỗ hổng mới và các nguy cơ có thể xuất hiện trong bất kỳ giai đoạn vòng đời của giao phẩm, đảm bảo thích hợp là cần thiết tại mỗi giai đoạn vòng đời của giao phẩm (ví dụ: khái niệm, phát triển, tích hợp, triển khai, vận hành và xử lý ). Vì vậy, các phương pháp đảm bảo an toàn phải phù hợp với giai đoạn riêng biệt. Thiếu chức năng, thay đổi yêu cầu, và các lỗ hổng mới sẽ ảnh hưởng đến đảm bảo an toàn và yêu cầu giai đoạn vòng đời được gia nhập lại sớm hơn. Vì vậy, mô hình vòng đời phải cho phép một mối quan hệ lặp đi lặp lại. chồng chéo hoặc lặp lại giữa các giai đoạn.
Một mô hình vòng đời mẫu (hình 1) được sử dụng để mô tả mối quan hệ của các phương pháp đảm bảo với giai đoạn vòng đời của giao phẩm. Mô hình vòng đời mẫu chứa các giai đoạn cơ bản nói chung đủ để được ánh xạ tới bất kỳ mô hình vòng đời riêng biệt nào. Mặc dù biểu tượng của từng giai đoạn trong hình 1 là giống nhau; các hoạt động và phản hồi sẽ thay đổi tùy theo phương pháp đảm bảo duy nhất được áp dụng. Ví dụ, một số phương pháp đảm bảo sử dụng một phương pháp giai đoạn bảo trì (ví dụ như khắc phục thiếu sót của TCVN 8709) đã có trong giai đoạn vận hành để giải quyết các lỗi và thay đổi các yêu cầu mà chỉ ảnh hưởng đến đảm bảo vận hành.
Ví dụ này mô tả mô hình có thể hỗ trợ phương pháp đảm bảo riêng biệt mà sẽ chỉ ra liệu các phản hồi tới giai đoạn riêng biệt của nó hoặc trả lại từ bắt đầu của giai đoạn thiết kế /phát triển giao phẩm.
Các kỹ thuật đảm bảo an toàn công nghệ thông tin có thể là xác định cho một giai đoạn cụ thể (ví dụ như sự công nhận hệ thống) hoặc áp dụng cho một số giai đoạn vòng đời của giao phẩm như có thể thấy bằng cách kiểm tra tiêu chuẩn TCVN 8709, TCVN ISO/IEC 27001, và ISO/IEC 21827.
Để đạt được sự đảm bảo kết quả thì đảm bảo thu được ở từng giai đoạn phải được chuyển sang giai đoạn tiếp theo ở đó nó sẽ được tính vào việc đảm bảo của giai đoạn đó. Phương pháp này gia tăng đảm bảo liên tiếp cho tới giai đoạn cuối cùng của mô hình vòng đời, đó là giai đoạn vận hành trong mô hình mẫu chỉ ra trong hình 4.
Hình 4 – Phương pháp SACA liên quan đến một mô hình đơn giản của giai đoạn vòng đời hệ thống
CHÚ THÍCH: Mô hình vòng đời chỉ ra trong hình 4 là một ví dụ để mô tả một mô hình tương thích với khung và mô hình vòng đời khác để dễ dàng phân tích đảm bảo an toàn công nghệ thông tin trong ISO/IEC TR 15443. Nó không có ý định giới thiệu một mô hình vòng đời xác định.
Hình 5 – Tính ứng dụng của mô hình SACA trong vòng đời
8.3.1 Bên đánh giá sự phù hợp đảm bảo an toàn
Hoạt động đánh giá sự phù hợp bên thứ nhất được thực hiện bởi bên đánh giá mà tham gia trực tiếp trong đặc tả, phát triển hoặc hoạt động của giao phẩm, ví dụ như bên phát triển, bên tích hợp hay bên cung cấp thành phần.
Hoạt động đánh giá sự phù hợp bên thứ hai được thực hiện bởi bên đánh giá mà có sự quan tâm bên trong đặc tả, phát triển hay hoạt động của giao phẩm, ví dụ như bên thu mua. Điều này có thể cung cấp cho bên thu mua tính bí mật trong các tuyên bố đảm bảo an toàn đã đưa ra cho giao phẩm dựa trên hiểu biết trực tiếp.
Hoạt động đánh giá sự phù hợp bên thứ ba được thực hiện bởi bên đánh giá là độc lập về đặc tả, phát triển hoặc hoạt động của giao phẩm. Điều này có thể cung cấp cho bên thu mua về tính bí mật nhiều hơn trong các tuyên bố đảm bảo an toàn đã đưa ra cho giao phẩm.
Phương pháp SACA có thể dựa vào các hoạt động đã cung cấp bởi bên đánh giá thứ nhất, thứ hai, thứ ba, hoặc cả sự kết hợp. Việc sử dụng các loại đánh giá khác nhau ảnh hưởng đến tính bí mật mà bên thu mua có thể có trong các tuyên bố đảm bảo an toàn đã đưa ra cho giao phẩm.
8.3.2 Hiệu quả của phương pháp SACA
Hiệu quả có thể được rút ra từ đánh giá lặp lại cho giao phẩm để:
a) Hiểu biết hơn về khả năng an toàn công nghệ thông tin mà nó có trước đó.
b) Năng lực về các chức năng an toàn công nghệ thông tin được nâng cao
c) Quy trình được cải thiện.
VÍ DỤ: Khi một hệ thống được triển khai bao gồm một bộ sản phẩm (mức độ đảm bảo có thể có hoặc không được biết đến hay được chấp nhận do các phương pháp đảm bảo đã sử dụng) mức đảm bảo có thể thừa nhận thường được xác định bởi việc áp dụng trường hợp an toàn mức cao trước khi hoạt động.
Một số phương pháp có thể tốt hơn cho giao phẩm đơn giản so với giao phẩm phức tạp. Ví dụ, thường dễ dàng hơn để xác minh giao phẩm với chức năng an toàn tối thiểu (ví dụ hàng ngàn dòng mã lệnh) và đạt được kết quả bảo mật cao hơn so với giao phẩm với chức năng an toàn mở rộng bao gồm hàng triệu dòng mã lệnh.
8.4 Mối quan hệ giữa các tiêu chí an toàn và phương pháp đánh giá
Phương pháp SACA dựa vào các đặc tả tiêu chí an toàn để mô tả yêu cầu chức năng an toàn và đánh giá, kiểm định hoặc đánh giá tiêu chí. Trong một số trường hợp cả hai tiêu chí và phương pháp đánh giá được kết hợp trong một tài liệu duy nhất.
VÍ DỤ 1: Tiêu chuẩn TCVN 8709 định nghĩa các tiêu chí khác nhau để đánh giá các sản phẩm công nghệ thông tin. Một tiêu chuẩn cùng cặp, ISO/IEC 18045 cung cấp phương pháp luận cho bên đánh giá tuân theo. Các tài liệu khác như ISO/IEC 20004 “Công nghệ thông tin – Kỹ thuật an toàn – Công nghệ thông tin – Kỹ thuật an toàn – Phân tích lỗ hổng phần mềm tinh chỉnh theo tiêu chuẩn TCVN 8709 và ISO/IEC 18045 cung cấp hướng dẫn thêm hoặc giải thích cho ngữ cảnh cụ thể.
VÍ DỤ 2: ISO/IEC 19790 xác định tiêu chí cho an toàn mô-đun mã hóa. Một tiêu chuẩn cùng cặp, ISO/IEC 24759 cung cấp các yêu cầu kiểm tra xuất phát từ đặc tả và cung cấp chi tiết cần thiết để hỗ trợ phù hợp trong việc kiểm tra sử dụng tiêu chí.
VÍ DỤ 3: PCI DSS cung cấp cả hai tiêu chí để được đánh giá và phương pháp đánh giá được sử dụng trong cùng một tài liệu.
8.5 Xếp hạng đảm bảo an toàn
Một số phương pháp đảm bảo an toàn cung cấp cơ chế để xác định số lượng phương pháp đảm bảo đã cung cấp. Có thể được tuyên bố như mức độ an toàn, mức độ đảm bảo đánh giá, điểm số, mức độ chặt chẽ,….
Một phương pháp đảm bảo có thể cung cấp đảm bảo an toàn với các mức đảm bảo bí mật khác nhau. Điều này thường được thể hiện bằng cách tăng tính chặt chẽ trong kỹ thuật đánh giá đã sử dụng, hoặc thông qua đặc tả bổ sung các yêu cầu đảm bảo an toàn và đã thể hiện như một số loại đánh giá.
Lưu ý rằng thêm tính chặt chẽ trong việc áp dụng các kỹ thuật đánh giá có thể cung cấp tính bí mật lớn hơn cho người dùng đảm bảo an toàn trong các yêu cầu đảm bảo an toàn đã đánh giá (Phân tích theo chiều sâu), đánh giá một số lượng lớn các yêu cầu cung cấp phạm vi đánh giá nhiều hơn nữa.
VÍ DỤ 1: Tiêu chuẩn TCVN 8709-1 giới thiệu các khái niệm về mức độ đảm bảo an toàn đánh giá (EAL), có thể được định nghĩa bởi người sử dụng phương pháp. TCVN 8709 định nghĩa trước bảy gói đảm bảo được đặt tên là EAL 1 tới EAL 7 và EAL 7 thể hiện là mức cao nhất được định nghĩa về đảm bảo an toàn đã rút ra từ các thành phần đảm bảo an toàn được đưa ra trong TCVN 8709-3. Với việc gia tăng các gói EALs bao gồm tăng đánh giá theo chiều sâu cũng như ngày càng có nhiều yêu cầu bao gồm trong dự án đánh giá được mô tả.
VÍ DỤ 2: FIPS 140-2 và ISO/IEC 19790 xác định bốn mức độ an toàn. Mức an toàn 4 thể hiện tính chặt chẽ cao nhất về kiểm định và yêu cầu an toàn áp dụng do đó có khả năng làm tăng tính bí mật bên thu mua trong việc đảm bảo các chức năng an toàn về các mô-đun mã hóa.
VÍ DỤ 3: Một phương pháp đảm bảo dự đoán, chẳng hạn như SSE CMM (ISO / IEC 21827) cung cấp đánh giá về mức độ bí mật có thể được đặt trong các quy trình xây dựng mục tiêu. Trong trường hợp của SSE CMM là tính hoàn thiện của quy trình được đánh giá và xếp hạng theo thang điểm sau:
– Mức 1: Thực hiện chưa chính thức.
– Mức 2: Lập kế hoạch và theo dõi.
– Mức 3: Định nghĩa tốt.
– Mức 4: Kiểm soát định lượng.
– Mức 5: Tiếp tục phát triển.
Một phương pháp khác cung cấp biện pháp định lượng về tính bí mật là để sử dụng kỹ thuật điểm số. Tuy nhiên lưu ý rằng kỹ thuật điểm số phải dựa vào phương pháp đánh giá định lượng. Nếu phương pháp đánh giá định nghĩa kỹ thuật chủ quan định tính thì sau đó số lượng phần lớn là vô nghĩa.
Không chính xác khi cho rằng xếp hạng đảm bảo “mức cao” đưa ra là tất yếu nhiều hơn đảm bảo an toàn. Bối cảnh cho việc xếp hạng phải được xem xét bao gồm ranh giới đánh giá, và thực chất về độ xếp hạng.
CHÚ THÍCH: ISO/IEC 15026-3 Hệ thống và công nghệ phần mềm – Hệ thống và đảm bảo phần mềm – Phần 3: mức toàn vẹn hệ thống có liên quan đến thảo luận này và nêu rõ khái niệm về mức toàn vẹn với yêu cầu mức toàn vẹn thích hợp là cần thiết được đáp ứng để hiển thị sự đạt được của mức toàn vẹn. Nó đưa ra các yêu cầu và phương pháp khuyến nghị để xác định và sử dụng mức toàn vẹn và yêu cầu mức toàn vẹn của chúng. Nó bao gồm hệ thống, sản phẩm phần mềm, và các thành phần của chúng cũng như sự phụ thuộc bên ngoài có liên quan. Trong khi mức toàn vẹn hệ thống mô tả đánh giá các thuộc tính rộng hơn nhiều so với vấn đề an toàn thích đáng.
8.6 Công cụ SACA
Một loạt các công cụ và kỹ thuật có thể được sử dụng để hỗ trợ việc cung cấp các đảm bảo an toàn thông qua phương pháp hoặc kỹ thuật cụ thể. Chúng bao gồm:
– Phân tích kiến trúc.
– Phân tích tĩnh.
– Chèn lỗi mã nguồn.
– Phân tích động.
– Phân tích phả hệ.
– Phân tích mã nhị phân.
– Phân tích phân rã.
– Chèn lỗi nhị phân.
– Kỹ thuật fuzzing (là kỹ thuật đưa dữ liệu không hợp lệ vào trong các ứng dụng hoặc các thành phần hệ điều hành để xem có lỗi xảy ra hay không).
– Phát hiện mã độc.
– Phân tích và cấu hình các công cụ xây dựng.
– Quản lý cấu hình hệ thống.
– Xác định các điểm yếu và lỗ hổng.
Việc sử dụng các công cụ có thể góp phần làm giảm khó khăn trong việc đánh giá, tuy nhiên đặc tính của một số công cụ có thể làm giảm độ đảm bảo nếu không hiểu rõ những hạn chế của chúng.
Phạm vi của tiêu chuẩn này không đề cập sâu về các công cụ và kỹ thuật cụ thể.
8.7 Kết quả áp dụng các phương pháp SACA
Phương pháp đảm bảo an toàn phù hợp cung cấp một loạt các bằng chứng hỗ trợ các tuyên bố đảm bảo an toàn. Do đó bằng chứng có thể sẵn có cho bên thu mua hoặc cho bên xác nhận độc lập về hoạt động đảm bảo. Nhìn chung bằng chứng mức cao về hoàn thành thành công việc đánh giá là được công khai. Như vậy kết quả có thể bao gồm:
– Chứng nhận chính thức cho biết việc hoàn thành thành công các hoạt động đánh giá.
– Danh mục sản phẩm đã được phê duyệt.
– Quyền hạn sử dụng Nhãn hiệu hoặc Biểu tượng được quản lý bởi lưu đồ đánh giá sự phù hợp.
– Mô tả mức cao các kết quả đánh giá (ví dụ một báo cáo kỹ thuật đánh giá công khai).
Lưu ý rằng người dùng đảm bảo an toàn sẽ xem xét về nguồn gốc của kết quả
9 CASCO
Điều khoản này mô tả cần thiết về sự phù hợp trong việc áp dụng phương pháp đánh giá nếu kết quả thu được là lặp lại và được sử dụng để so sánh đảm bảo an toàn đã cung cấp bởi các giao phẩm khác nhau.
ISO/CASCO là Ủy ban phát triển chính sách của ISO về đánh giá sự phù hợp, báo cáo cho Hội đồng ISO. CASCO được thành lập vào năm 1970 để nghiên cứu các cách thức đánh giá sự phù hợp, chuẩn bị tài liệu liên quan đến thực hành và hoạt động đánh giá sự phù hợp, để xúc tiến việc sử dụng các thuật ngữ tham khảo của Ủy ban:
– Nghiên cứu phương tiện đánh giá sự phù hợp cho sản phẩm, quy trình, dịch vụ và hệ thống quản lý theo tiêu chuẩn thích hợp hoặc đặc tả kỹ thuật khác.
– Chuẩn bị bản hướng dẫn quốc tế và tiêu chuẩn quốc tế liên quan đến việc thực hành thử nghiệm, điều tra và chứng nhận cho sản phẩm, quy trình và dịch vụ, và đánh giá hệ thống quản lý, các phòng thử nghiệm, cơ quan điều tra, cơ quan chứng nhận, tổ chức công nhận và hoạt động cũng như sự chấp nhận của họ.
– Thúc đẩy công nhận lẫn nhau và chấp nhận hệ thống đánh giá sự phù hợp quốc gia và khu vực, và việc sử dụng tiêu chuẩn quốc tế thích hợp để kiểm thử, điều tra, chứng nhận, đánh giá và những mục đích có liên quan.
9.1 Tiêu chuẩn hỗ trợ đánh giá sự phù hợp
Nhiều tiêu chuẩn hỗ trợ đánh giá sự phù hợp có quan tâm đến việc thiết lập hoặc điều hành lưu đồ đánh giá an toàn gồm nhiều tài liệu được sản xuất thông qua CASCO bao gồm:
– ISO/IEC Guide 23: Phương pháp chỉ ra sự phù hợp với các tiêu chuẩn cho hệ thống chứng nhận bên thứ ba.
– ISO/IEC Guide 28: Đánh giá sự phù hợp – Hướng dẫn về hệ thống chứng nhận bên thứ ba cho các sản phẩm.
– ISO/IEC Guide 53: Đánh giá sự phù hợp – Hướng dẫn sử dụng hệ thống quản lý chất lượng của tổ chức trong việc chứng nhận sản phẩm.
– ISO / IEC Guide 60: Đánh giá sự phù hợp – Quy tắc thực hành tốt.
– ISO/IEC 17000: Đánh giá sự phù hợp – Từ vựng và các nguyên tắc chung.
– ISO / PAS 17001: Đánh giá sự phù hợp – Tính khách quan – Nguyên tắc và yêu cầu.
– ISO / PAS 17003: Đánh giá sự phù hợp – Khiếu nại và kháng cáo – Nguyên tắc và yêu cầu.
– ISO / IEC 17011: Đánh giá sự phù hợp – Yêu cầu chung cho tổ chức công nhận công nhận tổ chức đánh giá sự phù hợp.
– ISO/IEC 17021: Đánh giá sự phù hợp – Yêu cầu đối với cơ quan cung cấp kiểm toán và chứng nhận hệ thống quản lý.
– ISO/IEC 17024: Đánh giá sự phù hợp – Yêu cầu chung cho cơ quan về chứng nhận hoạt động của con người.
– ISO / IEC 17025: Yêu cầu chung về năng lực của phòng thử nghiệm và kiểm thử.
– ISO / IEC 17030: Đánh giá sự phù hợp – Yêu cầu chung về sự phù hợp Nhãn hiệu bên thứ ba.
– ISO / IEC 17040: Đánh giá sự phù hợp – Yêu cầu chung cho đánh giá ngang hàng về tổ chức đánh giá sự phù hợp và tổ chức công nhận.
– ISO/IEC 17043: Đánh giá sự phù hợp – Yêu cầu chung về thử nghiệm thành thạo.
– ISO/IEC DIS 17065: Đánh giá sự phù hợp – Yêu cầu đối với cơ quan chứng nhận sản phẩm, quy trình và dịch vụ.
Ngoài ra, một số tiêu chuẩn khác hỗ trợ đánh giá sự phù hợp được đưa ra bởi các tổ chức khác:
VÍ DỤ: ISO/IEC JTC1 SC 27/WG1 đã đưa ra tiêu chuẩn và hướng dẫn hỗ trợ sự phù hợp về đánh giá cho các tuyên bố của ISO/IEC 27001. Những tài liệu này bao gồm:
– ISO/IEC 27006: Công nghệ thông tin – Kỹ thuật an toàn – Yêu cầu đối với các cơ quan cung cấp kiểm toán và chứng nhận hệ thống quản lý an toàn thông tin.
– ISO/IEC 27008: Công nghệ thông tin – Kỹ thuật an toàn – Hướng dẫn kiểm toán viên về kiểm soát an toàn thông tin.
10 Mô hình SACA
10.1 Lưu đồ SACA
Một phương pháp SACA cụ thể được thực hiện bằng cách nhấn mạnh đến bối cảnh trong đó phương pháp được thực thi được định nghĩa bởi CASCO như một “Đề án đánh giá sự phù hợp” thường được gọi là một “lưu đồ” hay “chương trình” trong lĩnh vực an toàn công nghệ thông tin. Trong một lưu đồ chính bên thứ ba đáng tin cậy có trách nhiệm đảm bảo sự phù hợp của việc đánh giá đảm bảo an toàn. Ví dụ một số quốc gia lưu đồ được tổ chức để giám sát hoạt động đánh giá bằng cách sử dụng tiêu chuẩn chung và tiêu chuẩn TCVN 8709. Một số quốc gia thì lưu đồ thực hiện các bước xa hơn là đảm bảo việc đánh giá được so sánh giữa các quốc gia thông qua việc thành lập và hỗ trợ của CCRA, đảm bảo rằng các phòng thử nghiệm được quản lý theo tiêu chuẩn ISO / IEC 17025 và duy trì sự phù hợp về đánh giá giữa các lưu đồ.
Ví dụ khác về đề án SACA như vậy bao gồm:
– Tiêu chuẩn hóa các yêu cầu đối với tổ chức công nhận giám sát việc đánh giá theo chuẩn ISO / IEC 27001 thông qua sự phù hợp với ISO/IEC 27006 – Công nghệ thông tin – Kỹ thuật an toàn – Yêu cầu đối với cơ quan cung cấp kiểm toán và chứng nhận hệ thống quản lý an toàn thông tin.
– Viện Công nghệ và Tiêu chuẩn quốc gia Hoa Kỳ (NIST) và Liên kết thiết lập an toàn của Canada (CSEC) như là Chương trình xác thực Mô-đun mã hóa có sử dụng tiêu chuẩn FIPS 140-2 của Mỹ. Lưu đồ được biết như là chương trình xác thực mô-đun mật mã (CMVP).
– Chương trình xác thực Mô-đun mã hóa của Nhật Bản (JCMVP) đã được thành lập với mục tiêu là bên thứ ba thực hiện kiểm tra và xác nhận các quy trình một cách có hệ thống để cho phép người dùng Mô-đun mã hóa nhận ra một cách chính xác và chi tiết rằng Mô-đun mật mã bao gồm phần cứng, phần mềm và/hoặc các thành phần phần sụn, trong đó chức năng an toàn đã phê chuẩn có trong Danh sách mã hóa được khuyến nghị cho chính phủ điện tử,… (ví dụ như chức năng mã hóa, hàm băm và chức năng chữ ký) được thực hiện, bảo vệ chức năng an toàn thích hợp, khóa mật mã, mật khẩu và các thông tin quan trọng khác được lưu trữ trong đó.
– Giám sát PCI SSC của tiêu chuẩn PCI DSS và các hoạt động liên quan, qua đó cung cấp chương trình an toàn của thẻ tín dụng với một mức phù hợp.
Như vậy lưu đồ có thể bao gồm các hoạt động đóng góp cho tính bí mật có thể được đưa ra trong các bằng chứng đảm bảo an toàn như:
– Cung cấp các chính sách như là xác định phương pháp đánh giá được sử dụng.
– Xác nhận cuối cùng các hoạt động công việc tại phòng thử nghiệm.
– Phát hành bằng chứng đảm bảo an toàn (như giấy chứng nhận, hoặc nơi cấp danh sách sản phẩm được phê duyệt);
– Đảm bảo các kỹ năng của nhân lực được chuẩn bị các hoạt động về đánh giá, đánh giá và kiểm tra đáp ứng tiêu chuẩn tối thiểu.
– Đảm bảo sự thành thạo của phòng thử nghiệm đáp ứng yêu cầu tối thiểu.
– Cung cấp giải thích về các tiêu chuẩn khi cần thiết để đối phó với công nghệ phát triển, các vấn đề phù hợp, hoặc tình huống mà các tiêu chuẩn không bao gồm.
– Cung cấp các công cụ, kỹ thuật và phương pháp bổ sung hỗ trợ các hoạt động đánh giá, đánh giá và kiểm định.
– Ban hành hướng dẫn và tư vấn cho người dùng đảm bảo an toàn.
– Thiết lập các chính sách đạo đức để đảm bảo sự độc lập của phòng thử nghiệm từ bên phát triển hoặc bên cung cấp giao phẩm.
Theo như hoạt động dưới một lưu đồ đánh giá sự phù hợp đảm bảo chính thức đã công nhận dễ dàng và bên đánh giá có thể được giả định một cách có lý để cung cấp mức đảm bảo an toàn cao hơn đạt được bằng cách sử dụng phương pháp đảm bảo tương ứng.
10.2 Tổ chức đánh giá sự phù hợp SACA
Tổ chức đánh giá sự phù hợp được định nghĩa trong tiêu chuẩn ISO/IEC 17000 được đặt tên khác nhau trong lĩnh vực đánh giá sự phù hợp đảm bảo an toàn. Ví dụ, trong lưu đồ tiêu chí chung, chúng có thể được đặt tên là “Phòng thử nghiệm” hoặc “điều kiện đánh giá an toàn công nghệ thông tin” (ITSEF); Trong tiêu chuẩn ISO/IEC 27001 chúng có thể được đặt tên là “cơ quan xác nhận” hoặc “đăng kiểm”, đối với ngành công nghiệp thẻ thanh toán chúng được đặt tên là “công ty đánh giá an toàn đạt chuẩn.”
Tổ chức đánh giá sự phù hợp SACA chịu trách nhiệm về hoạt động dưới sự bảo trợ của một lưu đồ SACA, thực hiện các hoạt động đánh giá sự phù hợp theo một phương pháp SACA, và đưa ra các kết quả SACA.
Có ba loại tổ chức đánh giá sự phù hợp SACA:
10.2.1 Loại A Đánh giá sự phù hợp
Đánh giá sự phù hợp loại A, bên thứ nhất được thực hiện bởi cơ quan đại diện nhà sản xuất đối tượng đánh giá. Nó thường được biết đến như là “tự đánh giá”. Điều này có thể là bên phát triển, bên tích hợp hoặc trong trường hợp chứng nhận nhân lực, người thực sự nhận được giáo dục hay đào tạo.
Đánh giá bên thứ nhất cung cấp đảm bảo thấp nhất đối với các bên liên quan từ đó thường được quan tâm và bên đánh giá thứ nhất thường mô tả một cách “mù mờ” tại các khu vực mà họ thấy khó khăn hoặc bị bỏ qua trong việc phát triển kế hoạch kiểm tra.
10.2.2 Tổ chức đánh giá sự phù hợp bên thứ hai
Loại B hoặc đánh giá sự phù hợp bên thứ hai được thực hiện bởi cơ quan đại diện tổ chức của bên liên quan khác, khác với tổ chức sản xuất các sản phẩm hoặc dịch vụ. Ví dụ người dùng cuối.
Đánh giá bên thứ hai cung cấp đảm bảo cao hơn cho người dùng cuối và có thể được làm trực tiếp nhưng đối với một giao phẩm hoặc dịch vụ có thể được cung cấp cho nhiều người dùng cuối là không hiệu quả và cho thấy bên phát triển hoặc bên tích hợp mang nhiều rủi ro trong phương pháp SACA. Một số tổ chức công nghiệp đã phát triển lưu đồ đánh giá bên thứ hai được chia sẻ hy vọng sẽ làm giảm nhược điểm. Có nhiều mức độ thành công khác nhau kể từ khi chúng dựa trên độ tin cậy giữa các thành viên của chương trình người mà thường xuyên là đối thủ cạnh tranh.
10.2.3 Tổ chức đánh giá sự phù hợp bên thứ ba
Loại C hoặc đánh giá bên thứ ba được thực hiện bởi tổ chức độc lập với các bên liên quan thực hiện các tuyên bố, hoặc dựa vào tính hợp lệ của các tuyên bố như vậy và cung cấp mức độ đảm bảo cao nhất, cơ hội tốt nhất cho sự phù hợp của kết quả đánh giá và hiệu quả trong việc cung cấp đảm bảo an toàn trong một cộng đồng lớn. Nhìn chung, xung đột lợi ích bởi các cơ quan đánh giá bên thứ ba có thể được giảm nhẹ thông qua thành viên quản trị lưu đồ SACA, tuy nhiên trong nhiều trường hợp đây vẫn là một mối quan tâm kể từ khi nó thường là tổ chức đại diện cho bên sản xuất hoặc người sử dụng các sản phẩm và dịch vụ được đánh giá là tài trợ cho các hoạt động đánh giá.
10.3 Ví dụ mẫu về mô hình SACA
Lưu đồ đánh giá sự phù hợp, hay chương trình được định nghĩa trong ISO/IEC17000, và đánh giá sự phù hợp đảm bảo an toàn thường mô tả một tổ chức chịu trách nhiệm giám sát chất lượng của kết quả SACA.
Hình 6 – Mối quan hệ tổng quát giữa các thực thể trong đảm bảo an toàn
Hình 6 – Mối quan hệ tổng quát giữa các thực thể trong đảm bảo an toàn, mô tả một số thực thể và mối quan hệ giữa chúng được thảo luận trong tiêu chuẩn này. Các điều khoản được rút ra phần lớn từ ISO/IEC 17000 và ISO/IEC 15026 nhưng có thể được sửa đổi để đáp ứng các nhu cầu của Báo cáo kỹ thuật này và mô hình đảm bảo an toàn.
Trong thực tế, mô hình này là đặc biệt đơn giản và các thực thể được thể hiện trong mô hình có thể được kết hợp, hoặc được xuất hiện nhiều lần.
Các điều khoản con sau đây cung cấp ví dụ về một số ứng dụng thực tế của mô hình.
10.3.1 Tiêu chí chung
VÍ DỤ: Lưu đồ quốc gia tiêu chí chung (CC) là một ví dụ về lưu đồ, có trách nhiệm đảm bảo rằng hệ thống SACA hoạt động, và phương pháp SACA mà họ sử dụng cung cấp kết quả phù hợp trong phạm vi quốc gia thường hoạt động. Trong trường hợp này, ban quản lý tiêu chí chung như là một tổ chức công nhận có trách nhiệm công nhận và theo dõi từng lưu đồ quốc gia để đảm bảo rằng hệ thống đánh giá sự phù hợp hoạt động bởi lưu đồ SACA tạo ra kết quả lặp lại và phù hợp, bằng cách sử dụng chính sách đã quy định (như là việc sử dụng hoạt động đánh giá sự phù hợp bên thứ ba, bao gồm sử dụng “Phương pháp đánh giá chung” như một cơ sở cho việc đánh giá. Mỗi lưu đồ quốc gia phát triển hệ thống đánh giá sự phù hợp riêng của họ, cung cấp các quy tắc, thủ tục và quản lý thực hiện dự án đánh giá CC. Lưu ý rằng mỗi tổ chức đánh giá sự phù hợp, được biết đến trong lĩnh vực CC như là một phòng thử nghiệm hoặc ITSEF là chính nó được công nhận bởi lưu đồ quốc gia để thực hiện phương pháp SACA và cung cấp kết quả SACA tới lưu đồ. Như là một phần của hệ thống SACA điều hành bởi lưu đồ, và được quy định bởi chính sách của tổ chức công nhận CC, đó là một yêu cầu mà tổ chức đánh giá sự phù hợp được xác nhận là phù hợp với tiêu chuẩn ISO / IEC 17025, đòi hỏi đảm bảo sự phù hợp này thông qua kết quả được cung cấp bởi cơ quan chứng nhận, và lưu đồ được công nhận liên quan đến sự phù hợp tiêu chuẩn ISO / IEC 17025
Hình 7 – Mẫu mô hình SACA tiêu chí chung, sử dụng thuật ngữ ISO
10.3.2 Chương trình phê chuẩn mô-đun mật mã (CMVP)
Chương trình phê chuẩn mô-đun mật mã (CMVP) là một ví dụ về tổ chức công nhận, với mục tiêu đảm bảo rằng các kết quả đưa ra thông qua sự bảo trợ của nó tạo ra kết quả lặp lại và phù hợp. Tại thời điểm viết bài có hai lưu đồ SACA tham gia trong chương trình. Chương trình (tổ chức công nhận) quy định chính sách (như là việc sử dụng các hoạt động đánh giá sự phù hợp bên thứ ba và một số khía cạnh phương pháp SACA đã sử dụng như là cung cấp giải thích về đặc tả làm cơ sở cho việc xác nhận và chứng thực các kết quả SAGA được đưa ra bởi tổ chức đánh giá sự phù hợp (phòng thử nghiệm) được phổ biến cho mỗi lưu đồ. Mỗi lưu đồ, (trong ví dụ này, tại thời điểm viết báo cáo kỹ thuật, NIST và CSEC) phát triển hệ thống SACA riêng của họ cái mà cung cấp các quy tắc, thủ tục và quản lý để thực hiện kiểm tra trong lưu đồ, mặc dù trong thực tế đây là những sự sắp xếp rất chặt chẽ.
Hình 8 – Mẫu mô hình SACA chương trình phê chuẩn mô-đun mật mã sử dụng thuật ngữ ISO
10.3.3 Công nghiệp thẻ thanh toán
Mô hình Công nghiệp thẻ thanh toán cho đảm bảo an toàn, sử dụng PCI DSS, bao gồm các hoạt động đánh giá loại A và loại C. Các thương hiệu thẻ cá nhân phát triển các trường hợp đảm bảo khác nhau cho các thương gia, bên cung cấp dịch vụ, bên thu mua; SACA được thực hiện không những bởi vấn đề đánh giá mà còn bởi bên đánh giá an toàn có chất lượng bên thứ ba tùy thuộc vào từng trường hợp đảm bảo. Đối với một số trường hợp đảm bảo các chính sách xung quanh đánh giá loại A là khác nhau
Hình 9 – Mẫu mô hình SACA PCI sử dụng thuật ngữ ISO
11 Các khía cạnh tạo nên sự đảm bảo an toàn
Những sản phẩm công nghệ thông tin hầu hết đều được cấu thành bởi phần cứng và phần mềm, đánh giá độc lập các thành phần nhìn chung đảm bảo để giảm hoàn toàn nỗ lực thực thi đánh giá sự phù hợp.
Điều quan trọng để hiểu chủ đề của sự hình thành và đảm bảo là một vấn đề mang tính công nghệ không được giải quyết. Trong điều khoản này một vài khía cạnh của chủ đề được đưa ra thảo luận nhằm mô tả trạng thái hiện tại của nghệ thuật. Thông thường, cơ quan đảm bảo quan tâm các trường hợp đảm bảo khác nhau như một tập các đảm bảo tách rời, các mối quan hệ của chúng nhìn chung không được biết đến và nó cũng giống như một mối đe dọa còn tiềm ẩn.
Điều khoản này xem xét một vài khía cạnh của thành phần và sự liên quan của nó trong việc đảm bảo an toàn. Nó thích hợp với chủ đề từ đó nhiều trường hợp và tuyên bố đảm bảo an toàn được hợp lại một cách tự nhiên, và đây cũng là một điều thiết yếu khi xem xét đảm bảo an toàn trong ngữ cảnh cho dây chuyền cung ứng các sản phẩm tích hợp. Sự xem xét về cách thức đánh giá một sản phẩm, có thể được sử dụng lại bao nhiêu các đánh giá thành phần cá nhân và cái gì là cần thiết khi tái sử dụng kết quả SACA đã thảo luận.
Thành phần cần xem xét:
– Các kiểu thành phần.
– Chính sách an toàn mà đánh giá thành phần dựa vào.
– Phương pháp đảm bảo an toàn đã sử dụng cho việc đánh giá các thành phần.
– Xếp hạng đảm bảo an toàn.
– Chính sách an toàn tổng thể về sản phẩm phức hợp.
Một số thành phần đảm bảo an toàn là có thể được thông qua hình thức thỏa thuận đảm bảo và luận cứ chủ quan của các chuyên gia an toàn công nghệ thông tin có kinh nghiệm và rút ra từ kiến thức cơ bản theo chủ đề. Hơn nữa, cơ quan an toàn cuối cùng xác định sự đảm bảo chấp nhận được cũng như sự liên kết và đóng một vai trò trong việc chấp nhận những rủi ro tồn tại.
Sự hợp thành của các trường hợp an toàn riêng biệt rất khó để thực hiện vì sự đa dạng của các mô hình được sử dụng trong mô tả về phương pháp đảm bảo an toàn và vì thang chuẩn hóa hoặc phương thức đảm bảo qua những phương pháp đảm bảo khác nhau không tồn tại.
Những ví dụ dưới đây giải thích các kịch bản đảm bảo hợp thành có thể xảy ra và minh hoạ một số câu hỏi được đưa ra bởi sự hợp thành.
11.1 Phát triển một trường hợp đảm bảo trong một thiết lập thành phần
Để giải quyết các thành phần nhiều kỹ thuật đảm bảo được áp dụng tới giao phẩm cụ thể, tốt nhất để xây dựng mô hình đảm bảo an toàn thể hiện các loại hình đánh giá đảm bảo khác nhau như thế nào được dùng để cùng làm việc góp phần vào sự đảm bảo tổng thể được kết hợp cùng giao phẩm. Mô hình đảm bảo an toàn cho giao phẩm có thể bao gồm các mô hình đảm bảo hợp thành khác nhau – mỗi loại phù hợp với công nghệ đảm bảo riêng biệt (ví dụ đảm bảo đánh giá, đảm bảo quy trình, đảm bảo phát triển). Theo đó, mô hình đảm bảo phân phối do là một kết hợp một số mô hình đảm bảo riêng biệt, sẽ chỉ ra các mô hình đảm bảo này được kết hợp với nhau như thế nào bất chấp giai đoạn đảm bảo tới những gì chúng đã được áp dụng.
Hơn nữa, nó có thể là một số đảm bảo an toàn liên quan đến giao phẩm không trực tiếp dành cho người nhận tiếp theo về giao phẩm mà thay vào đó là để dành cho bên thu mua hệ thống tích hợp hoặc người dùng cuối. Mô hình có thể chỉ ra điều này một cách rõ ràng, và giúp đảm bảo rằng người nhận cuối cùng nhận được một bức tranh rõ ràng về việc đảm bảo an toàn liên quan.
Mỗi mô hình đảm bảo có thể xác định loại và số lượng đảm bảo cho một giai đoạn vòng đời cụ thể của giao phẩm để thuận tiện so sánh. Mô hình đảm bảo phân phối sẽ gộp các mô hình riêng biệt lại với nhau bằng cách mô tả sự cân bằng và cung cấp sự hợp lý để mô tả đảm bảo kết quả cho giao phẩm.
Một kỹ thuật thường được sử dụng là việc sử dụng một số khung bao quát mà hỗ trợ sự cần thiết của cơ quan đảm bảo. Một ví dụ là việc sử dụng ISO/IEC 27001 cung cấp khung xây dựng một hệ thống quản lý an toàn thông tin. Mô hình này dựa trên:
a) Đầu tiên xác định mục tiêu đảm bảo (tuyên bố phạm vi).
b) Thực hiện đánh giá rủi ro an toàn tập trung vào mục tiêu đảm bảo.
c) Lựa chọn biện pháp kiểm soát thích hợp để đáp ứng việc đảm bảo đã yêu cầu cho tài sản được xác định (mỗi kiểm soát là đã từng có trong tuyên bố đảm bảo chính nó).
d) Đo hiệu quả của các biện pháp kiểm soát đã thực thi.
Cơ quan đảm bảo có thể tăng tính bí mật khi mà hệ thống quản lý được đánh giá bởi bên thứ ba độc lập với mục tiêu để đạt chứng nhận sự phù hợp, bằng chứng đảm bảo mà hệ thống đã thực thi là có hiệu quả.
Khung tương tự khác tồn tại bao gồm những điều đó đã hoạt động bởi một số thương hiệu thẻ tín dụng sử dụng phương pháp chung được phát triển bởi PCI SSC, và mô hình thực thi đã phát triển bởi NIST cho phù hợp với các yêu cầu của Hiệp hội quản lý an toàn thông tin Mỹ.
11.1.1 Vấn đề chung của các thành phần
Những vấn đề của các thành phần liên quan tới mỗi kiểu thành phần được đưa ra dưới đây, vấn đề cụ thể đối với một loại riêng biệt được thảo luận trong các điều khoản con dưới đây. Trong khi yêu cầu an toàn chức năng thuần túy như việc xác thực thực thể hay biện pháp kiểm soát truy cập thường có thể được ánh xạ tới thành phần đơn hoặc tập con các thành phần được xác định với sự tương tác cũng được xác định, việc đánh giá các thuộc tính an toàn được duy trì trong thành phần là khó khăn hơn đáng kể để xác minh. Khía cạnh khác mà khó để xác định là khả năng xử lý lỗi, chỉ ra rằng phản ứng tới điều kiện gây lỗi là ở cả hai dạng thức cho đầy đủ sản phẩm được tạo thành hoặc những lỗi với một thành phần bị giới hạn với thành phần đó mà không có bất cứ ảnh hưởng nào đến các phần tử khác của sản phẩm được tạo thành.
Ví dụ về các thuộc tính là khó để phân tích khi kết hợp các thành phần:
– Biện pháp kiểm soát luồng thông tin.
– Khả năng chịu lỗi.
– Sự phân chia.
Khía cạnh quan trọng khác là việc phân tích các lỗi ảnh hưởng hoặc có trường hợp ngoại lệ. Trong nhiều trường hợp ảnh hưởng của một lỗi hoặc một ngoại lệ không thể là chứa đầy đủ trong một thành phần và sẽ có một số ảnh hưởng đến các thành phần khác trong sản phẩm được tạo ra.
Vấn đề bao gồm cả hai bảo vệ thuộc tính và lan truyền lỗi là cái mà chúng không thể được phân tích hoàn toàn bởi cách xem xét giao diện được định nghĩa giữa các thành phần. Chúng có thể ảnh hưởng đến các thành phần khác thông qua tác dụng phụ không được xem xét như “giao diện” kinh điển giữa các thành phần. Một ví dụ đơn giản là tác động vào thời gian xử lý lỗi với một thành phần. Mặc dù việc xử lý lỗi có thể được hoàn toàn giới hạn trong một thành phần, sự thay đổi kết quả trong thời gian cần một thành phần để xử lý lỗi có thể làm hỏng các tuyên bố sẵn sàng thực hiện cho sản phẩm được tạo ra hay kết quả trong kênh bí mật vi phạm thuộc tính biện pháp kiểm soát luồng thông tin hoặc các kênh phụ có thể dẫn đến việc rò rỉ các tài liệu chính được sử dụng cho các hoạt động mật mã.
11.1.2 Những mặt chung của các thành phần tái sử dụng
Các mặt chung của việc tái sử dụng, phù hợp với từng loại thành phần được đưa ra dưới đây, các vấn đề cụ thể liên quan đến một loại hình cụ thể được thảo luận trong điều khoản con thích hợp dưới đây. Luồng thông tin cần thiết cho kết quả đánh giá và bằng chứng đánh giá phụ thuộc vào:
– Xếp hạng SACA.
– Loại thành phần.
– Tính tương thích của các mục tiêu an toàn và các giả định.
– Các phương pháp đánh giá đảm bảo.
– Trong trường hợp, nếu có, thì các thuộc tính sẽ được tuyên bố.
Bất kỳ phương pháp SACA nào liên quan đến thành phần phải xác định thông tin cần được thông qua từ đánh giá về các thành phần tới đánh giá về sản phẩm được tạo ra. Phương pháp này cần phải xác minh tại sao thông tin là đủ.
CHÚ THÍCH: Nếu chỉ là một phần của thông tin đã yêu cầu được cung cấp thì việc tái sử dụng là không có khả năng.
Trong mỗi kịch bản thành phần, phân tích điểm yếu là một xem xét quan trọng. Phân tích lỗ hổng có thể là một quy trình phức tạp đặc biệt khó khăn khi những thuộc tính an toàn được tuyên bố trong giao phẩm được tạo ra, ví dụ:
– Sự phân chia.
– Biện pháp kiểm soát luồng thông tin.
– Khả năng chịu lỗi.
Khi xem xét các hoạt động SACA (thử nghiệm) điều quan trọng là phải xem xét làm thế nào tái sử dụng việc kiểm thử thành phần trong các kiểm thử sản phẩm.
11.1.3 Thành phần sử dụng kỹ thuật đảm bảo khác nhau
Các kỹ thuật liên quan đến việc cung cấp kết quả SACA ảnh hưởng đến thành phần và mô hình tái sử dụng đã phát triển. Nếu kỹ thuật giống nhau (sự đánh giá, sự phù hợp hoặc dự đoán) được sử dụng cho các thành phần khác nhau thì một số mức độ so sánh của kết quả có thể là rõ ràng, nhưng nếu kỹ thuật khác nhau thì một thành phần như vậy sẽ là khó khăn và phụ thuộc nhiều vào quyết định chủ quan. Trong trường hợp này nó là quan trọng mà các chuyên gia an toàn có nhiều kinh nghiệm tham gia vào quá trình và thông tin đầy đủ về việc đánh giá thành phần được thông qua tới chúng.
Đáng chú ý rằng nhiều phương pháp SACA dựa theo chuẩn hiện đang chuyển hướng theo mô hình cơ bản giống nhau của cải tiến quy trình liên tục. Một ví dụ là PDCA (Plan, Do, Check, Act) mô hình đã sử dụng bởi cả hai tiêu chuẩn ISO 9001 về chất lượng và ISO / IEC 27001 cho hệ thống quản lý an toàn thông tin.
11.2 Các loại thành phần
Điều này giới thiệu ba loại thành phần. Chúng có thể được áp dụng một mình hoặc sử dụng cùng nhau để tạo ra một kịch bản thành phần phức tạp. Chúng tôi cũng xem xét chủ đề tái sử dụng các kết quả SACA hiện có. Đáng giá không chú ý một sản phẩm bao gồm nhiều thành phần có thể gặp tất cả ba loại thành phần.
11.2.1 Phân lớp
Trong kỹ thuật này một thành phần được xây dựng trên thành phần khác. Thành phần phân lớp là một kỹ thuật phức tạp, mặc dù nó là rất quan trọng đối với hầu hết các kịch bản thành phần. Lưu ý rằng kỹ thuật này có một đặc điểm là sự phụ thuộc ở mức độ cao hơn so với thành phần mạng
11.2.1.1 Mô tả
Hình 10 – Thành phần phân lớp
11.2.1.2 Các giả định
Giả định nào đó thường được thực hiện khi sử dụng kỹ thuật này:
– Các thành phần thấp hơn là độc lập so với thành phần cao hơn.
– Các thành phần thấp hơn không được sửa đổi với thành phần cao hơn.
– Các thành phần cao hơn sử dụng các chức năng của thành phần thấp hơn và ngược lại thì không.
VÍ DỤ: Lớp phần cứng – phần mềm, lớp hệ điều hành – ứng dụng.
11.2.1.3 Các yêu cầu phân tích
– Bảo vệ thuộc tính đòi hỏi phân tích đầy đủ điểm yếu của các sản phẩm tạo ra.
– Mức độ phân tích điểm yếu được xác định bởi xếp hạng SACA (đối với tiêu chuẩn TCVN 8709 thường được mô tả như một mức độ đảm bảo đánh giá).
11.2.1.4 Những vấn đề cần được xem xét
Ở đây chúng tôi sử dụng một ví dụ để mô tả các vấn đề có thể gặp phải khi sử dụng kỹ thuật này. Xem xét thành phần đảm bảo an toàn cho một ứng dụng (“B”) trên đầu của một hệ điều hành (“A”).
Trong ví dụ này chúng ta rút ra một tình huống mà mỗi thành phần đã được đánh giá sử dụng phương pháp đảm bảo như nhau. Trong trường hợp này TCVN 8709 được sử dụng để cung cấp đảm bảo mà chức năng an toàn của các thành phần khác nhau được thực hiện như đã tuyên bố.
Hình 11 – Một hệ thống khái niệm với một số thành phần đánh giá
Để giải thích việc phân lớp, Hình 11 – Một hệ thống khái niệm với một số thành phần đánh giá, cho thấy một mô hình trừu tượng của một hệ thống. Một lớp phần cứng, ảo hóa, máy ảo, hệ điều hành và ứng dụng được mô tả như một hệ thống hoạt động. Hình này cho thấy một số các hoán vị của các thành phần đánh giá có thể nhưng người đọc nên lưu ý rằng trong cuộc sống thực số hoán vị và kết hợp có thể sẽ rất lớn.
Có thể có giấy chứng nhận (dấu) sự phù hợp khác nhau sẵn sàng cho các phiên bản khác nhau hoặc cấu hình của một thành phần, mức độ đảm bảo đánh giá khác nhau hoặc các gói yêu cầu khác để xem xét, và các mục tiêu an toàn thêm vào có thể bao gồm đánh giá các yêu cầu về chức năng an toàn khác nhau và đưa ra các tuyên bố cho sự phù hợp tới các hồ sơ bảo vệ.
CHÚ THÍCH: TCVN 8709-3 bao gồm tiêu chí cho thành phần, ứng dụng này có các tính năng sau:
– Sử dụng định danh và xác thực cung cấp bởi hệ điều hành.
– Xây dựng các đối tượng riêng của nó thuộc tốp đầu của hệ thống tập tin hệ điều hành.
– Xây dựng cấu trúc ứng dụng riêng của nó thuộc tốp đầu của phân tách và quản lý không gian địa chỉ hệ điều hành.
– Muốn thực thi thuộc tính cụ thể (VD: khả năng chịu lỗi, biện pháp kiểm soát luồng thông tin).
Vấn đề tiền năng trong kịch bản này bao gồm:
– Bảo vệ đối tượng hệ điều hành (A) là ở mức file, không phải mức đối tượng mà ứng dụng tạo ra.
– Hệ điều hành có thể cung cấp một đường dẫn truy cập thay thế tới các đối tượng được quản lý bởi ứng dụng.
– Sự tách biệt không gian địa chỉ của hệ điều hành có thể cho phép các kênh truyền thông ứng dụng không được quan tâm.
– Thuộc tính của giao phẩm hoàn chỉnh có thể bị phá vỡ bởi các tác dụng phụ không xác định của hệ điều hành.
– Lớp cao hơn có thể phụ thuộc vào chức năng không được coi là chức năng an toàn trong việc đánh giá lớp thấp hơn và do đó đã không là vấn đề để đánh giá đảm bảo.
• Phần mềm phần cứng: gần như tất cả các lệnh của phần cứng được sử dụng để thực hiện các chức năng an toàn.
• Phân lớp phần mềm: các lớp cao hơn (cơ sở dữ liệu) có thể phụ thuộc vào một số chức năng (chức năng khoá) không được xem xét trong đánh giá của lớp thấp hơn (hệ điều hành).
11.2.1.5 Yêu cầu sử dụng lại
Yêu cầu tái sử dụng các kết quả đánh giá của các lớp thấp hơn bằng cách sử dụng cách tiếp cận đơn giản bao gồm:
– Có thể có một số chức năng an toàn của lớp cao hơn mà chúng có thể bị phá vỡ rõ ràng cho tới chức năng an toàn đã đánh giá của lớp thấp hơn. Trong trường hợp này nếu các giả định được thực hiện bởi các lớp cao hơn đã được đưa vào tài khoản trong việc đánh giá các lớp thấp hơn, có thể sử dụng lại các kết quả đánh giá.
– Nơi là không thể, lớp cao hơn thực hiện các chức năng an toàn riêng của mình, sử dụng các chức năng của lớp thấp hơn đã không được coi như chức năng an toàn trong việc đánh giá lớp thấp hơn. Đây là một tình huống như một phần của đánh giá lớp cao hơn, cũng là lớp thấp hơn cần phải được đánh giá lại.
– Phân lớp thể hiện mức độ cao hơn của sự phụ thuộc hơn thành phần mạng.
– Bảo vệ thuộc tính đòi hỏi phải phân tích điểm yếu đầy đủ về giao phẩm được tạo ra.
– Mức độ phân tích điểm yếu được xác định bởi xếp hạng SACA (trong tiêu chí chung được xác định bởi các gói yêu cầu, ví dụ mức độ đảm bảo đánh giá).
11.2.2 Mạng
Trong trường hợp này chúng ta xem xét một thành phần sử dụng các chức năng cụ thể của các thành phần khác kết nối qua một số kênh truyền thông.
11.2.2.1 Mô tả
Hình 12 – Thành phần mạng
VÍ DỤ: Một sản phẩm sử dụng các chức năng của một máy chủ LDAP bên ngoài.
11.2.2.2 Các giả định
Giả định chắc chắn thường được thực hiện sử dụng kỹ thuật này:
– Sự phụ thuộc an toàn được mô tả một cách rõ ràng.
– Cả hai sản phẩm được tách ra như vậy mà không có kênh khác hoặc ảnh hưởng hơn cái đã xác định.
– Cả hai sản phẩm thực thi các chức năng cần thiết để bảo vệ các kênh truyền thông.
11.2.2.3 Các yêu cầu phân tích
Thành phần mạng là kiểu thành phần phức tạp nhất, tuy nhiên cần xem xét các vấn đề sau đây:
– Một phân tích kỹ lưỡng về sự phù hợp mục tiêu an toàn và các giả định được thực hiện trong đánh giá thành phần được yêu cầu.
– Đánh giá bảo vệ thuộc tính có thể vẫn là một vấn đề.
– Đánh giá độc lập đến mức đảm bảo trung bình dường như có thể cho phép phần lớn sử dụng lại.
11.2.2.4 Những vấn đề cần được xem xét
Khi đánh giá thành phần A một tuyên bố yêu cầu an toàn cho các thành phần khác, nhưng vẫn còn:
– Chức năng an toàn có thể không phù hợp với nhau.
VÍ DỤ: Biện pháp kiểm soát truy cập có thể dựa trên các đối tượng khác nhau.
– Giả định được thực hiện trên một thành phần có thể không hợp lệ.
VÍ DỤ: Giả định về bảo vệ dữ liệu quan trọng truyền cho các thành phần khác.
– Chức năng bảo mật có thể có tác dụng phụ không mong muốn.
VÍ DỤ Một kênh bí mật để lộ khóa mật mã.
11.2.2.5 Yêu cầu sử dụng lại
Yêu cầu sử dụng lại các kết quả đánh giá về cách tiếp cận thành phần mạng bao gồm:
– Sự phụ thuộc an toàn được hiểu, vẫn còn được áp dụng.
– Bất kỳ giả định hoặc yêu cầu được thực hiện trên các thành phần mới vẫn còn có giá trị.
– Không có bất kỳ kênh khác hoặc ảnh hưởng khác hơn kênh đã được xác định.
– Cả hai thành phần thực hiện tốt chức năng cần thiết để bảo vệ kênh truyền thông.
– Một phân tích điểm yếu về sản phẩm được tạo ra là cần thiết, bao gồm phân tích tác dụng phụ không mong muốn.
11.2.3 Thành phần
Trong loại thành phần này một thành phần được sử dụng như là một phần của sản phẩm hay thành phần lớn hơn.
11.2.3.1 Mô tả
Hình 13 – Thành phần cấu thành
VÍ DỤ: Một thư viện hay hệ thống con cung cấp các chức năng an toàn cụ thể như là một phần của sản phẩm lớn hơn.
11.2.3.2 Các giả định
Các giả định chắc chắn thường được thực hiện khi sử dụng kỹ thuật này:
– Thường là không có sự tách biệt giữa các bộ phận cấu thành.
– Mỗi thành phần có thể ảnh hưởng đến cái khác thông qua nhiều kênh khác nhau và giao diện khác so với cái đã dự định.
11.2.3.3 Phân tích các mô hình thành phần
Đối với một phân tích thành phần dựa trên tích hợp các phân tích sau được yêu cầu:
– Phân tích loại thành phần.
– Phân tích các giao diện và sự phụ thuộc của các chức năng (không chỉ các chức năng an toàn).
– Phân tích khả năng biên soạn chính sách.
– Phân tích duy trì an toàn và thuộc tính khác.
CHÚ THÍCH 3: phân tích cuối cùng là quan trọng, nhưng trong thực tế thường bị bỏ quên.
11.2.3.4 Những vấn đề cần được xem xét
Vì thiếu tách biệt các thành phần có thể:
– Bỏ qua chức năng an toàn của các thành phần khác.
– Sửa đổi chức năng an toàn và chính sách của các thành phần khác và toàn bộ sản phẩm.
– Chỉ ra một số tác dụng phụ quan trọng.
Vấn đề chung được xem xét bao gồm:
Thuộc tính được bảo vệ như thế nào?
• Biện pháp kiểm soát luồng thông tin.
• Khả năng chịu lỗi.
• Sự phân chia.
– Cách thức kiểm soát lan truyền lỗi?.
• Hậu quả của lỗi trong một thành phần lên thành phần khác là gì?
– Tác dụng phụ không xác định của một thành phần có thể ảnh hưởng đến sự an toàn của những thành phần khác.
11.2.3.5 Yêu cầu sử dụng lại
Thành phần cấu thành là loại quan trọng nhất của thành phần. Khi sử dụng lại kết quả SACA thành phần cần xem xét các vấn đề sau:
– Ngay cả các khía cạnh đúng đắn có thể cần được xem xét lại.
– Phân tích đầy đủ điểm yếu của sản phẩm tạo ra là luôn luôn cần thiết.
11.3 Hoạt động nâng cao
Như đã đề cập trong tiêu chuẩn này, chủ đề về đảm bảo an toàn thành phần tương đối chưa hoàn thiện, chưa được xem là quan trọng để cung cấp đảm bảo an toàn trong bối cảnh của giao phẩm COTS, tích hợp các thành phần khác nhau để tạo thành hệ thống phức tạp, và khi xem xét đảm bảo an toàn chuỗi cung ứng. Trong điều này một số lĩnh vực đề cập tiếp theo có thể được thừa kế từ chủ đề này.
a) Một phân tích về các phương pháp để xử lý thành phần trong các lĩnh vực khác, ví dụ như trong các lĩnh vực an toàn và Độ tin cậy, Kỹ thuật cổ điển.
b) Phương pháp mới cho việc phân tích điểm yếu và phân tích bảo vệ các thuộc tính nên được xem xét.
– Thành phần có thể nhưng phụ thuộc vào một số yếu tố.
– Một số loại thành phần được xử lý dễ dàng hơn thành phần khác.
– Bảo vệ thuộc tính là thách thức.
– Đưa ra khung tiêu chuẩn cho thành phần.
– Thành phần cho các mức đảm bảo cao hơn yêu cầu nghiên cứu thêm.
Thư mục tài liệu tham khảo
[1] ISO/IEC 14598(all parts), Information technology – Software product evalution (ISO/IEC 14598 (tất cả các phần) Công nghệ thông tin – Đánh giá sản phẩm phần mềm).
[2] ISO/IEC TR 15026-1:2010, System and software engineering – Systems and software assurance – Part 1: Concept and vocabulary (ISO/IEC TR 15026-1:2010 Hệ thống và công nghệ phần mềm – Đảm bảo hệ thống và phần mềm – Phần 1: Các khái niệm và từ vựng).
[3] ISO/IEC FDIS 15026-2:2011, System and software engineering-Systems and software assurance – Part 2: Assurance case (ISO/IEC FDIS 15026-2:2011 Hệ thống và công nghệ phần mềm – Hệ thống và đảm bảo phần mềm – Phần 2: Trường hợp đảm bảo).
[4] ISO/IEC FCD 15026-3: To be published, System and software engineering – Systems and software assurance – Part 3: System integrity levels (ISO/IEC PCD 15026-3: đã công bố, Hệ thống và công nghệ phần mềm – Hệ thống và đảm bảo phần mềm – Phần 3: Toàn vẹn hệ thống).
[5] ISO/IEC 15408:2008, (all parts), Information technology – Security techniques – Evaluation criteria for IT security (TCVN 8709: 2011 (tất cả các phần), Công nghệ thông tin – Kỹ thuật an toàn – Tiêu chí đánh giá an toàn công nghệ thông tin).
[6] ISO/IEC 15504:2004 (all part), Information technology – Process assessment (ISO/IEC 15504:2004 (tất cả các phần), Công nghệ thông tin – Đánh giá quy trình).
[7] TCVN ISO/IEC 17000 : 2005, Đánh giá sự phù hợp – Từ vựng và các nguyên tắc chung.
[8] ISO/PAS 17005:2008, Conformity assessment – Use of management systems – Principles and requirements (ISO/PAS 17005: 2008, Đánh giá sự phù hợp – Sử dụng hệ thống quản lý – Nguyên tắc và yêu cầu).
[9] ISO/IEC 17007:2009, Conformity assessment – Guidance for drafting normative documents suitable for use for conformity assessment (ISO/IEC 17007: 2009, Đánh giá sự phù hợp – Hướng dẫn soạn thảo văn bản quy phạm phù hợp để sử dụng cho việc đánh giá sự phù hợp).
[10] ISO/IEC 17020:1998 Conformity assessment – General criteria for the operation of various types of bodies performing inspection (ISO/IEC 17020: 1998, Đánh giá sự phù hợp – Tiêu chuẩn chung cho hoạt động của các phần khác nhau của các cơ quan thực hiện kiểm tra).
[11] ISO/IEC 17021: 2011, Đánh giá sự phù hợp – Yêu cầu đối với cơ quan đánh giá và chứng nhận hệ thống quản lý.
[12] ISO/IEC 17021:2011, Conformity assessment – Requirements for bodies providing audit and certification of management systems (ISO/IEC 17021: 2011, Đánh giá sự phù hợp – Yêu cầu đối với cơ quan kiểm toán và chứng nhận hệ thống quản lý).
[13] ISO/IEC 17024:2003, Conformity assessment – General requirements for bodies operating certification of persons (ISO/IEC 17024:2003, Đánh giá sự phù hợp – Yêu cầu chung đối với cơ quan cấp giấy chứng nhận hoạt động nhân lực).
[14] ISO/IEC 17025:2005, Conformity assessment – General requirements for the competence of testing and calibration laboratories (ISO/IEC 17025: 2005, Đánh giá sự phù hợp – Yêu cầu chung về năng lực thử nghiệm và hiệu chuẩn).
[15] ISO/IEC 17030:2003, Conformity assessment – General requirements for third-party marks of conformity (ISO/IEC 17030: 2003, Đánh giá sự phù hợp – Yêu cầu chung đối với nhãn hiệu của bên thứ ba về sự phù hợp).
[16] ISO/IEC 18045:2009, Information technology – Security techniques – Methodology for IT security evaluation (ISO/IEC 18045: 2009, Công nghệ thông tin – Kỹ thuật an toàn – Phương pháp đánh giá an toàn công nghệ thông tin).
[17] ISO/IEC 19790:2006, Information technology – Security techniques – Security requirements for cryptographic modules (ISO/IEC 19790: 2006, Công nghệ thông tin – Kỹ thuật an toàn – Yêu cầu an toàn cho các mô-đun mã hóa).
[18] ISO/IEC 19791:2006, Information technology – Security techniques – Security assessment of operational systems (ISO/IEC 19791:2006, Công nghệ thông tin – Kỹ thuật an toàn – Hoạt động đánh giá an toàn của hệ thống).
[19] ISO/IEC 23988:2007, Information technology – A code of practice for the use of information technology (IT) in the delivery of assessment (ISO/IEC 23988: 2007, Công nghệ thông tin – Quy tắc thực hành cho việc sử dụng công nghệ thông tin (IT) trong việc cung cấp các đánh giá).
[20] TCVN ISO/IEC 27001:2009, Công nghệ thông tin – Kỹ thuật an toàn – Hệ thống quản lý an toàn thông tin – Yêu cầu).
[21] TCVN ISO/IEC 27002:2011, Công nghệ thông tin – Kỹ thuật an toàn – Quy tắc thực hành quản lý an toàn thông tin.
[22] TCVN 10295:2014, Công nghệ thông tin – Các kỹ thuật an toàn – Quản lý rủi ro an toàn thông tin.
[23] ISO/IEC 27036-1: (draft), Information technology – Security techniques – Information Security for Supplier Relationships – Part 1: Overview and Concepts (ISO/IEC 27036-1: (dự thảo), Công nghệ thông tin – Kỹ thuật an toàn – Các mối quan hệ An toàn thông tin cho nhà cung cấp – Phần 1: Tổng quan và khái niệm).
| TIÊU CHUẨN QUỐC GIA TCVN 11778-1:2017 (ISO/IEC TR 15443-1:2012) VỀ CÔNG NGHỆ THÔNG TIN – CÁC KỸ THUẬT AN TOÀN – KHUNG CHO ĐẢM BẢO AN TOÀN CÔNG NGHỆ THÔNG TIN – PHẦN 1: GIỚI THIỆU VÀ KHÁI NIỆM | |||
| Số, ký hiệu văn bản | TCVN11778-1:2017 | Ngày hiệu lực | |
| Loại văn bản | Tiêu chuẩn Việt Nam | Ngày đăng công báo | |
| Lĩnh vực |
Giao dịch điện tử |
Ngày ban hành | 01/01/2017 |
| Cơ quan ban hành | Tình trạng | Còn hiệu lực | |
Các văn bản liên kết
| Văn bản được hướng dẫn | Văn bản hướng dẫn | ||
| Văn bản được hợp nhất | Văn bản hợp nhất | ||
| Văn bản bị sửa đổi, bổ sung | Văn bản sửa đổi, bổ sung | ||
| Văn bản bị đính chính | Văn bản đính chính | ||
| Văn bản bị thay thế | Văn bản thay thế | ||
| Văn bản được dẫn chiếu | Văn bản căn cứ |
