TCVNTCVN xxxx-1:201x

TIÊU CHUẨN QUỐC GIA

TCVN xxxx-1:201x

2

3

TCVN xxxx-1:201x

MỤC LỤC

Giới thiệu………................................................................................................................................7

1 Phạm vi áp dụng............................................................................................................................9

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

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

4 Các thuật ngữ viết tắt.................................................................................................................14

5 Khái niệm bảo đảm an toàn........................................................................................................15

5.1 Bảo đảm an toàn........................................................................................................................16

5.2 Bảo đảm khác với tính tin cậy....................................................................................................17

5.3 Nhu cầu bảo đảm an toàn..........................................................................................................17

5.4 Bảo đảm an toàn là không hữu hình..........................................................................................18

5.5 Bảo đảm an toàn nhằmlàm giảm rủi ro an toàn.........................................................................18

5.6 Bảo đảm an toàn được cung cấp có liên quan đến các nỗ lực đã thực hiện.............................19

5.7 Bảo đảm an toàn không cải thiện sản phẩm..............................................................................19

5.8 Các bên liên quan đến bảo đảm an toàn...................................................................................20

5.9 Phổ biến rộng rãi bảo đảm an toàn............................................................................................21

5.10 Các khía cạnh tổ chức của SACA............................................................................................28

6 Cấu trúc bảo đảm an toàn..........................................................................................................28

6.1 Đặc tả yêu cầu bảo đảm an toàn...............................................................................................28

6.2 Các trường hợp bảo đảm an toàn..............................................................................................29

6.3 Bằng chứng bảo đảm an toàn....................................................................................................30

6.4 Tuyên bố bảo đảm an toàn........................................................................................................31

6.5 Luận cứ đảm bảo an toàn..........................................................................................................31

7 Kỹ thuật SACA.............................................................................................................................33

7.1 Kỹ thuật......................................................................................................................................33

7.2 Lựa chọn kỹ thuật bảo đảm an toàn...........................................................................................35

8 Phương pháp SACA...................................................................................................................36

8.1 Phương pháp đánh giá sự phù hợp bảo đảm an toàn (SACA)..................................................36

8.2 Tiếp cận các phương pháp SACA.............................................................................................40

8.3 Phạm vi của các giai đoạn vòng đời..........................................................................................42

8.4 Mối quan hệ giữa các tiêu chí an toàn và phương pháp đánh giá.............................................44

8.5 Xếp hạng bảo đảm an toàn........................................................................................................44

8.6 Công cụ SACA...........................................................................................................................45

4

TCVN xxxx-1:201x

8.7 Kết quả áp dụng các phương pháp SACA.................................................................................46

9 CASCO……..................................................................................................................................46

9.1 Tiêu chuẩn hỗ trợ đánh giá sự phù hợp.....................................................................................47

10 Mô hình SACA...........................................................................................................................48

10.1 Lưu đồ SACA...........................................................................................................................48

10.2 Cơ quan đánh giá sự phù hợp SACA......................................................................................49

10.3 Ví dụ mẫu về mô hình SACA...................................................................................................50

11 Các khía cạnh tạo nên sự bảo đảm an toàn...........................................................................53

11.1 Phát triển một trường hợp bảo đảm trong thiết lập một cách hợp nhất...................................54

11.2 Các loại cấu thành....................................................................................................................56

11.3 Hoạt động nâng cao.................................................................................................................62

Thư mục tài liệu tham khảo...........................................................................................................63

5

Lời nói đầu

6

TCVN xxxx-1:201xhoà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 xxxx:201xdoHọ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ố.

TCVN xxxx-1:201x

7

TCVN xxxx-1:201x

Giới thiệu

Bộ tiêu chuẩn TCVN xxxx:201xđượ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 bảo đảm 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à ETSI).

Bộ tiêu chuẩn này tập trung vào bảo đảm 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 TCVN xxxx:201x là mô tả vềchủ đề bảo đảm 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 bảo đảman 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 bảo đảman 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àncông nghệ thông tin trong việc sử dụng bảo đảm để đạt được tính tin cậymà

một giao phẩm được đưa ra đáp ứng các yêu cầu về bảo đảman toàn công nghệ thông tin. Bộ tiêu

chuẩn nàynghiên cứu các kỹ thuật bảo đảman toàn, các phương pháp bảo đảman toàn được đề xuất

bởi nhiều tổ chức.

Bộ tiêu chuẩnTCVN xxxx:201x bao gồm các nội dung sau:

a) Các thuật ngữ và định nghĩa liên quan đến chủ đề bảo đảman toàn

b) Các khái niệm cơ bản liên quan đến bảo đảman 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ậncủa các phương pháp bảo đảm

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 bảo đảm

e) Một khungmẫuđể xác định vị trí của phương pháp bảo đảm 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, TCVNxxxx-1:201x 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ề bảo đảman 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 xxxx-2:201xmột cách thích hợp.

Tiêu chuẩn TCVN xxxx-1:201x hướng đến:

a) Cơ quan bảo đảman toànchịu trách nhiệm về các quyết định liên quan đến bảo đảman toàn của

giao phẩm,

b) Cơ quan bảo đảman toànchịu 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, như là nhân viên an toàn, kiến trúc sư an toàncông nghệ thông tin,bên phát triển và bêntích

hợp.

c) Cơ quan bảo đảman toànchịu trách nhiệm quyết định việc bảo đảman 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.

8

TCVN xxxx-1:201x

d) Khách hàng của bảo đảm an toàncông nghệ thông tin chẳng hạn như bên thâu nhận 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ẩmmà đư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 xxxx-2:201xCác phân tích: mô tảkhung mẫu bảo đảm an toàn có thể được sử dụng để

đánh giá một số phương pháp bảo đảm và phương pháp tiếp cận và liên kết chúng với TCVN xxxx-

1:201x. Quan trọng ở đây làxác định thuộc tính chất lượng của các phương pháp bảo đảm an toàn góp

phần bảo đảm 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 đượccác bảo đảm an toàn trong giai đoạn vòng đời của giao phẩm.

TCVN xxxx:201x có liên quan tới phương pháp bảo đảm 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.

9

Công nghệ thông tin – Các kỹ thuật an toàn – Bộ khung đả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 định nghĩa 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 bảo đảm an toàncô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 xxxx-2:201x.

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

Các tài liệu viện dẫn dưới đây là cần thiết để áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi

năm công bố thì áp dụng bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp

dụng phiên bản mới nhất, bao gồm cả các sửa đổi, bổ sung (nếu có).

ISO/IEC TR 15026-1:2010Systems and software engineering – Systems and software assurance – Part

1: Concepts and vocabulary (Kỹ thuật hệ thống và phần mềm – Bảo đảm phần mềm và hệ thống –

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

Các thuật ngữ và định nghĩanêu trong tiêu chuẩn TCVN ISO/IEC 17000:2007, TCVN ISO/IEC 8709-

1:2011, ISO/IEC TR 15026-1 và bộ TCVN ISO/IEC 27000được áp dụng trong tiêu chuẩn này.CHÚ THÍCH:Việc xác định thuật ngữ cho khung bảo đảm an toàn chung là một nhiệm vụ khó khăn vì nhiều thuật ngữ vềbảo

đảm an toàn đã được đưa ra để đáp ứng các nhu cầu bảo đảman 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 bảo đảm 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.

3.1 Công nhận (accreditation)

Xác nhận của bên thứ ba đối với cơ quan đá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 17000:2007, Điều 5.6]

3.2 Công nhận (accreditation)

10

TIÊU CHUẨN QUỐC GIA TCVN xxxx-1:201x

TCVN xxxx-1:201x

Tuyên bố chính thức của cơ quan phê chuẩn được chỉ định cho rằng một hệ thống được phê chuẩn để

hoạt động trong một chế độ an toàn riêng sử dụng một bộ quy định các biện pháp bảo vệ.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 bảo đảm và phạm vibảo đảm mà nó cung cấp là đạt

yêu cầuCHÚ 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ẩnthường thuộc vềbên thâu nhận. 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ẩmtrê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 thâu nhận.

[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ẩnvà/hoặc đánh giá

các chức năng an toàn.CHÚ THÍC: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 trasẽ 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 thẩm tra 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 bảo đảm.

[ISO/IEC 21827, Điều 3.3]

3.6 Bảo đảm (assurance)

Cơ sở để tin cậy rằng một công bố đã hoặc sẽ đạt được.

[ISO/IEC TR 15026-1:2010, Điều 2.1]

3.7 Bảo đảm (assurance)

<TCVN 8709>Cơ sở để tin cậy rằng một TOE thỏa mãn các TSF.

[TCVN 8709-1:2011, Điều 3.1.4]

3.8 Cơ quan bảo đảm (assurance authority)

Cá nhân hoặc tổ chức chịu trách nhiệm chỉ rõ các yêu cầu bảo đảman toàn để đạt được sự bảo đảm.CHÚ THÍCH: Một cơ quan bảo đảm 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.

11

TCVN xxxx-1:201x

3.9 Trường hợp bảo đảm (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 bảo đảm 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ểmlà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 lôgicgiữ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ố bảo đảm (assurance claim)

Xác nhận hoặc hỗ trợ xác nhậnrằ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 cơ quanđá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 là chỉ mục đích hay mong muốn có thểđể chỉ ra 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 vấn đề đú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àngvề 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ự có mục tiêu an toàn

12

TCVN xxxx-1:201x

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ênquan 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 Ước lượng(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 Ước lượng(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 đồước lượng(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ứbảo đảm chứng minh tuyên bố bảo đảm.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 Bảo đảm 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 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ôngkhai 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 trách nhiệm, tính xác

thực, và tính tin cậy.

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ườihoặ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 Bảo đảm an toàn(security assurance)

13

TCVN xxxx-1:201x

Cơ sở cho tính tin cậy 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ứ bảo đảm an toàn(security assurance argument)

Tập các tuyên bố bảo đảm 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 bảo đảman toàn.

3.25 Bằng chứng bảo đảm 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ố bảo đảm an toàn có thể dựa vàoCHÚ 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 bảo đảm an toàn(security assurance conformance assessment method)Phương pháp SACA (SACA method)

Quy trình, thủ tục hoặc kỹ thuật có hệ thống cho việc thu thập bằng chứng bảo đảm an toàn và xác

nhận chắc chắn các tuyên bố bảo đảman toànCHÚ 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 bảo đảm 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 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 bảo đảm 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 bảo đảm 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 bảo đảm 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 bảo đảm an toàn theo thang đo cụ thể đã sử

dụng bởi các phương pháp bảo đảm an toàn.CHÚ THÍCH 1: Mức bảo đảm có thể không đo lường được về mặt định lượng.

CHÚ THÍCH 2: Mức độ bảo đảman 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ả bảo đảm an toàn(security assurance result)

Tuyên bố bảo đảm an toàn định lượng hay định tính đã được tài liệu hoá đi kèm với giao phẩm.

3.31

14

TCVN xxxx-1:201x

Mục tiêu an toàn(security objective)

Tuyên bố hướng đố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ànmà TOE chủ ý đề cập đến.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 ước lượng 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àncông nghệ thông tin Canada)

EAL Evaluation Assurance level Mứcbảo đảmước lượng

IEC International Eclectrotechnical 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 hoá quốc tế

IT Information Technology Công nghệ thông tin

15

TCVN xxxx-1:201x

ITSEC Information Technology Security Evaluation

Criteria (Office for Official Publications of

the European Communities)

Tiêu chí ước lượngan 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ởước lượngan 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 ước lượngan 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 bảo đảman 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)

16

TCVN xxxx-1:201x

5 Khái niệm bảo đảman toàn

Phần này giới thiệu các khái niệm về bảo đảman toàn và nhằm mục đích bổ sung thêm các khái niệm

bảo đảm chung được đưa ra trong ISO/IEC 15026-1:2010 cho bảo đảm phần mềm và hệ thống.

Cấu trúc bảo đảman toàn được đưa ra tại Điều 6, các khái niệm về sự phù hợp trong đánh giá bảo

đảman toàn được giải thích tại Điều 7, 8 và 9, khái niệm mới về bảo đảman toàn được giới thiệu tại

Điều 10.

5.1 Bảo đảman 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áctí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ủ đề bảo đảm, 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.

Bảo đảman toàn có thể được xem xét liên quan đến bảo đảm 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).

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

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

Việc cung cấp bảo đảm an toàn đóng góp vào các mô hìnhnà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 đòi hỏi việc cung cấp sự bảo đảm an toànchính là nguồn lựcthiếtyếu và bao gồm cảchi phí

phát sinh và sự chậm trễ. Khối lượng nguồn lực sử dụng phải phù hợp với bảo đảm an toànđược cung

cấp. Hơn nữa, bảo đảman 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ư bảo đảm an toàn có thể được đobằ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 bảo đảman toàn của một tổ chứcdo đó để 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áchệ thống công

nghệ thông tin, cho rằnggiao phẩmlà không thể được tạo ra một cách an toàn tuyệt đối. Ngược lại, chỉ

cho rằngsẽ bảo đảm an toàn cho giao phẩmphứ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êumà hệ thốngcô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

17

TCVN xxxx-1:201x

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ôngkhai thác lỗ hổng thành công.

Việc cung cấp sự bảo đảm 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 tin cậymà họ có thểgiả định giao phẩm là bảo mật.

5.2 Sự khác biệt giữa bảo đảm với tính tin cậy

Điều quan trọng là chỉ rabảo đảm và tính tin cậy 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 ở đâytính tin cậy liên quan đến việc tin tưởng vào việc bảo đảm của giao phẩm trong

khi bảo đảm 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 tin cậykhô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ự bảo đảm.

Bảo đảmđược xác định từ bằng chứng được đưa ra bởiquy trình đánh giá giao phẩm. Các bằng chứng

thường bao gồm luận cứ, tài liệubảo đảm, và các thứ khác liên quan tới sản phẩm, chứng minh tuyên

bố bảo đảm dựa trên hoạt động đánh giá và kỹ thuật an toàn.

Tính tin cậy phụ thuộc vào nhận thức của cá nhân về yêu cầu an toàn đã chỉ địnhvà để 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ábảo đảm

đã 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 tin cậy 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 tin cậy

khác nhau sau khi thực hiện phương pháp bảo đảm bởi một cá nhân hay một tổ chức.

5.3 Nhu cầu bảo đảm an toàn

Trong vài thập kỷ qua, sự tin tưởngcủ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ênphổ 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ạiqua 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ínhcó thể bị ảnh hưởng, ít nhất là

một phần nào đó, thông quaan 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

tinliên quanvượ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.

18

TCVN xxxx-1:201x

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 tintriể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ể bảo đảm 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ý bởi hệ thống công nghệ thông tin cùng 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 bảo đảman 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ứcan toàn để đạt được một hệ thống công nghệ thông tin với

bảo đảman 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 tin cậy hợp lý rằng hệ thống công nghệ thông tinthự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 tin cậy mà giao phẩm đã được áp dụng các chính

sách an toàn.

5.4 Bảo đảm an toàn là không hữu hình

Bảo đảman toànkhông “thêm” bất kỳ biện pháp bảo vệ hoặc dịch vụ nào vàogiao phẩm. Vì vậy, đôi khi

nó rất khó để cá nhân chưa có nhận thứcan toàn hiểu được những lợi ích họ đang nhận được từ việc

đầu tư tài nguyênbảo đảm. Ví dụ, đối với một sản phẩm an toàncông nghệ thông tinthìviệc bảo đảm

góp phần vào “tăng cường” cơ chế bảo mật; tuy nhiên, việc bảo đảm thực ra chỉ góp phần vào tính tin

cậy 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à bảo

đảm 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ựchai 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ự bảo đảm từ khi nó là

các hoạt động bảo đảm trong khi phát triển cơ chế góp phần vào sự bảo đảm cho cơ chế.

Điều quan trọng là phải hiểu được bảo đảm không nghĩa làan toàn tốt: bảo đảm 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 bảo đảm cung cấp tính tin cậy 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 bảo

đảm 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

19

TCVN xxxx-1:201x

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 bảo đảm 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 Bảo đảm an toànnhằmlàm giảm rủi ro an toàn

Bảo đảman toàn góp phần làm giảm rủi ro, giống như bảo đảm 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, bảo đảman 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 bảo đảm 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 bảo đảm và lý do để cung cấp tính tin cậy 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 bảo đảm an toàn (hoặc bảo đảm an toàn tăng cường)

tới tổ chức là không dễ dàng đạt được. Tuy nhiên, bảo đảman toàn tăng cường của một biện pháp

kiểm soátan toàn làm giảm bớt tínhbấ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ếutrong rủi ro. Như vậy giá trị của việc bảo đảm 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ự bảo đảm 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 bảo đảm;số lượng sự bất

định của rủi ro xuấthiện nhiều hơnviệc bảo đảm cho nó. Các phương phápbảo đảm 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.6Bảo đảm 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 bảo đảman 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 bảo đảm 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ì bảo đảm an toàncó thể đạt ở một mức độ thấp hơntừ đánh giá. Nếu mã nguồn không được phân tích thì

việc bảo đảman toànrõ rang là ở các mức độ thấp hơn.

Các nỗ lực yêu cầu để cung cấp bảo đảman 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ápbảo đảm 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ápbảo đảm được áp dụng;

h. sự kết hợp cụ thể của phương pháp bảo đảman toàn được triển khai.

20

TCVN xxxx-1:201x

5.7 Bảo đảm 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 bảo đảman toàn không hướng trực tiếp tớigiao phẩm. Một giao

phẩm tuyên bố về bảo đảm 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 bảo đảm an toànthườ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ăngtính an toàn có thể

đạt được.

5.8 Các bên liên quan đến bảo đảm an toàn

5.8.1 Các bên yêu cầu giữ bí mật kết quả SACA

Tóm lại bảo đảm 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 độ bảo đảman toànchấ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 bảo đảman 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 thâu nhận.

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ànmộ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 bảo đảm và cơ quan phê chuẩn

Cơ quản bảo đảm là các cá nhân hoặc tổ chức chịu trách nhiệm về các yêu cầu bảo đảm 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 tin cậy 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 bảo đảm SACA, hoặc có nghĩa là các cơ

quan bảo đảm 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 bảo đảman 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

21

TCVN xxxx-1:201x

trách nhiệm chắc chắn rằng các yêu cầu bảo đảm 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 chobộ 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 bảo đảmcủa sản phẩmCOTS, ứng dụngtù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 bảo đảm với trách nhiệm chắc chắn rằng các chính sách bảo đảm an toàntổ chức được đáp ứng,

lựa chọn lưu đồ SACAhoặc hệ thống SACA thích hợp và xác định mức độ đòi hỏi và loại bảo đảm đòi

hỏi để thỏa mãn yêu cầu cụ thể của họ. Cơ quanbảo đảm cũng có trách nhiệm chắc chắn rằng các

chính sách bảo đảman toàn được đáp ứng, liên lạc với các tổ chức bảo đảman 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 SACAchịu trách

nhiệm trong việc triển khai hiện mộtphươ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 gianvà chi phí của các hoạt động đánh giá liên

quan.

5.9Phổ biến rộng rãi bảo đảman toàn

Phải thừa nhận rằng để giải quyết việc bảo đảm 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ốngcông nghệ thông tin. Mục đích của sơ đồ này là để minh họasự phức tạp liên quan

và chỉ ra rằng tuyên bố bảo đảm 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 bảo đảman 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)

22

TCVN xxxx-1:201x

góp phần tạo những lỗ hổng tiềm năng cho hệ thống công nghệ thông tinvà nên cung cấp sự bảo đảm

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:2016,Công nghệ thông tin – các kỹ thuật an toàn – Bộ khung bảo đảm 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ìnhCá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ố bảo đảman 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àncông nghệ thông tin;

d) cá nhân đóng góp cho tình hìnhan toàncông nghệ thông tin hoặc cho các điều khoản về bảo

đảman toàncông nghệ thông tin;

23

TCVN xxxx-1:201x

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 bảo đảm cho một vấn đề an toàn lớn hơn hoặc có thể là một hệ thống bảo

đảm 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 bảo đảman toàn được đề cập trong điều 10.

Một số giao phẩmcũng có thể góp phần bảo đảman 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.

Bảo đảman toànlà 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ànhmột hệ thống.

5.9.1 Bảo đảman toàn xuyên suốt

Bảo đảman toàn xuyên suốt cung cấp bảo đảm cho các bên liên quan xa hơn ngược chuỗi cung ứng.

Dạng tuyên bố bảo đảm này được dành cho bên thâu nhận 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 bảo đảm máy tính xách tay. Các tuyên bố

bảo đảm khác về trường hợp bảo đảmcủ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 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ố bảo đảm. Chúngcho 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ồmlà 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 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ố bảo đảm. Các loại tuyên

bố bảo đảm cùng với nhau đã tạo nên các trường hợp bảo đảm 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ự bảo đảman 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ườidù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 bảo đảm khác nhau mô tả ranh giới sử dụng các cơ chế khác nhau.

VÍ DỤ:

24

TCVN xxxx-1:201x

- Việc ước lượng 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 bổ sung

về người dùng bổ sung và người quản trị.

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 ước lượng (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 ước lượng).

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 ước lượng đượ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ăngphần cứng cũng như các chức năng phần sụn được bao phủ bởi

ước lượng này trong phạm vi mà các khả năngsau đâ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 chomã 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 danhvà xác thực người dùng trong TOE bao gồm tất cả các hình

thức đăng nhậptươ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

25

TCVN xxxx-1:201x

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ậpcấ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 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 đó. 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ãnlấ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 ước lượng đảmbả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 ước lượng. 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 ước lượng và Hướng dẫn Cấu hình ước lượngcung 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 ước lượng. Ví dụ,

BSDJails được cung cấp với TOE và được cho phép trong việc cấu hình ước lượng mặc dù

nó không lệ thuộc vào việcước lượng 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 ước lượng (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 ước

26

TCVN xxxx-1:201x

lượng không phân tích nếukhông có tuyên bố nào áp dụng lên nó.

Chức năng Thảo luận về việc loại trừ

Open SSL, beecrypt,

gnutls

Thư viện OpenSSL, thư viện Beecrypt cũng như các thư viện

Gnutls không nhằm mục đích cung cấp chức năng mật mã tuyên

bố bởi ST và do đó không được đánh giá. Người dùng và người

quản trị được cung cấp hướng dẫn về cách sử dụng các chức

năng NSS để thay thế.

Việc thực hiện chính xác của tính toán mã hóa được cung cấp bởi

các thư viện được đề cập bởi các nhà cung cấp.

Mật mã được cung cấp

bởi gnupg, duplicity

Các ứng dụng của gnupg và duplicity cung cấp mật mã sẽ không

bao gồm trong ước lượng này.

OpenSSH Các khía cạnh mật mã của OpenSSH không được đánh giá.

eCryptFS không được phép sử dụng trong cấu hình đánh giá. Khả năng mật

mã hóa được cung cấp với hệ thống tập tin này sẽ không sẵn có

cho bất kỳ người sử dụng nào.

GRSecurity Các chức năng được cung cấp bởi GRSecurity không được đánh

giá như là một phần của việc ước lượng.

PaX Các chức năng ngăn chặn việc khai thác lỗi phần mềm không

được đánh giá như là một phần của việc ước lượng.

SMACK Chức năng kiểm soát truy cập bắt buộc được cung cấp bởi

SMACK LSM không sẵn có trong cấu hình ước lượng. SELinux

LSM cung cấp việc thực thi chính sách kiểm soát truy cập bắt

buộc

IPSEC IPSEC phải được sử dụng với TOE, nhưng các khía cạnh mật mã

của IPSEC không được đánh giá.

IPSEC tunnel chỉ được sử dụng để cung

cấp một kênh

truyền thông có khả năng vận chuyển dữ liệu được gán nhãn.

Đường hầm SSL/TLS TOE cung cấp các ứng dụng stunnel được sử dụng để thiết lập

các đường hầm SSL và TLS với các đối tượng ngang hàng từ xa.

Tuy nhiên ứng dụng này không được đánh giá.

…. ….

Bảng 1: các hàm không được ước lượng

27

TCVN xxxx-1:201x

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 ước

lượng 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ước lượng 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 ước lượng 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 ước lượng, 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

28

TCVN xxxx-1:201x

chuỗi cung ứng, bảo đảman toàn này được áp dụng không chỉ đối với “việctạo thành” của giao

phẩmmà còn cả với “việc chuyển giao ” của chúng.

Việc bảo đảm trong khi phân phốikhông chỉ có nghĩa là bảo đảmgiao 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ạnhan 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 bảo đảm 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ồmvấ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ợpbảo đảman 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 bảo đảm phản ánhcá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 bảo đảm 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 bảo đảm;

b) trong trường hợp nào một giao phẩmcầ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 bảo đảm an toàn

Biểu đồ dưới đây mô tả quan hệ giữa các an toànmong đợi của giao phẩmvà các quy trình bảo đảman

toàn, góp phần cung cấp sự bảo đảman toàn cần thiết.

29

TCVN xxxx-1:201x

Hình 2: Mối quan hệ giữa an toàn trong giao phẩm và bảo đảman toàn

6.1 Đặc tả yêu cầu bảo đảm an toàn

Trong thuật ngữ về an toàncông nghệ thông tin, việc bảo đảm an toàn đầy đủ nghĩa là các yêu cầu bảo

đảm 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

bảo đảm an toàn – đó là kết quả của việc thực hiện các hoạt động và quy trình bảo đảman toàn thích

hợp. Yêu cầu bảo đảman toàn được xác định từ các vấn đề an toàncủagiao phẩm (và các yếu tố tiềm

ẩn khác).

Yêu cầu bảo đảman 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 bảo đảm 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á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 bảo đảman toàn và có liên quan đến việc hình thành một trường hợp bảo đảm.

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 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 bảo đảm cho sản

phẩm và hệ thốngcông nghệ thông tin cụ thể cho việcước lượngan toàncô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 rõ ràng để xác định các yêu cầu liên quan đến

việc cung cấp bảo đảman 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 bảo đảman 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 bảo đảm cụ thể như việc ước lượng 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 bảo đảman toàn có thể

bao gồm sự công nhận và chấp nhận các phương pháp bảo đảman toàn hoặc lưu đồ bảo đảman toàn,

sự công nhận lẫn nhau và mức bảo đảm tối thiểu.

Ví dụ, các yêu cầu bảo đảman 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 bảo đảman toàncầ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 bảo đảman toàn hỗ trợ lẫn nhau như bảo đảm tính chính xác và

bảo đảmtính hiệu quả. Hơn nữa, các kỹ thuật bảo đảm đượ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 bảo đảm, trách nhiệm của họ và các kênh truyền thông.

30

TCVN xxxx-1:201x

6.2 Các trường hợp bảo đảm an toàn

Một trường hợp bảo đảm 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ênkếtgiữa tuyên bố mức cao với các bằng chứng và giả định.

Một trường hợp bảo đảman toàn là một gói bảo đảman 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 bảo đảman 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 bảo đảman 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 bảo đảman toàn cung cấp tính tin cậy 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 bảo đảman toàn được hỗ trợ bởi một hoặc nhiều tuyên bốbảo đảm. Những tuyên bố bảo

đảmnày có thể được thể hiệncông khai như một phần của hệ thống công nghệ thông tin hoặckhô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 bảo đảman 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 bảo đảman toàn

Xây dựng một trường hợp bảo đảman 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 bảo đảm để 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 bảo đảm 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 bảo đảm.

6.2.2 Truyền thông một trường hợp bảo đảman toàn

Trường hợp bảo đảman 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 bảo đảman 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ốbảo đảman toàn có thể không

được truyền thông thông qua chuỗi cung ứng.

Trong thực tế, bên thâu nhận chỉ xem xét hoặc chỉ định một trường hợp bảo đảman toàn thích hợp với

giao phẩm và không xem xét các trường hợp bảo đảman 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 thâu nhậnvì an toàn theodòng chuỗi cung ứng là một vấn đề giả

định.

31

TCVN xxxx-1:201x

6.3 Bằng chứng bảo đảm an toàn

Trường hợp bảo đảman toàn được hỗ trợ bởi các bằng chứng bảo đảman toànđược tạo ra từ việc hỗ

trợ các tuyên bốbảo đảman toàn. Có nhiều hình thức về bằng chứngbảo đảman toàn được trình bày

để hỗ trợ một trường hợp bảo đảman 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 bảo đảman 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 ước lượng độc lập – mục tiêu an toàn của hệ thống và kết quả ước lượng.

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à ước lượng của

chúng, danh tiếng của chúngvề 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ố bảo đảm an toàn

Tuyên bố bảo đảman 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ềbảo đảm xuyên suốt. Hình thức này của tuyên bố bảo đảm

nhằm dành cho các bên thâu nhậncác sản phẩm đã được lắp rápcuố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ợpbảo đảm máy tính xách tay nói chung. Các tuyên bố bảo đảm khác của

trường hợp bảo đảm 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 thâu nhận.

Tuyên bố bảo đảm thường được trình diễn như “Nhãn 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 và biểu tượng có nhiều loại từ nhãn đăng ký và nhãn 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ố bảo

đảman 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ố bảo đảm 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ố

32

TCVN xxxx-1:201x

bảo đảm 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ácluận cứbảo đảm được mô tả trong ISO/IEC 15026 -1.

Các luận cứbảo đảman toàn chứng minh các tuyên bốbảo đảman toàn. Có thể một hoặc nhiều luận cứ

bảo đảman toàn để chứng minh một tuyên bố bảo đảm an toàn. Trong một số trường hợp, một luận

cứbảo đảman toàn duy nhất có thể được sử dụng để chứng minh nhiều tuyên bố bảo đảman toàn.

Luận cứbảo đảman 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 bảo đảm đượ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ố bảo đảm 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ứ bảo đảm đượ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ứ bảo đảman toàn chứng minh tuyên bố bảo đảman toàn

được thể hiện bởi Nhãnhiệ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ứ bảo đảm 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à bảo đảm 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ứbảo đảm an toàn khác chứng minhcác tuyên bố bảo đảman 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ànhệ thống quốc tế (ISSPCS) .

Các loại khác củaluận cứbảo đảman 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 bảo đảman toàn trong một tổ

chức.

Một luận cứ bảo đảm an toàn có thể được xây dựng dựa trên việc ước lượng 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ứbảo đảm 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ứcbảo đảmước

lượng (EAL) đạt được.

Như đã được chứng minh, luận cứ bảo đảm 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ứbảo đảman toàn đã được

dựa trên:

a) kiệc kiểm tra và ước lượng các sản phẩm hoặc dịch vụ;

33

TCVN xxxx-1:201x

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ố bảo đảman 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ộcphần lớn vào nhu cầu của

người nhận bảo đảm và cách mà họ sẽ sử dụng các trường hợp bảo đảman 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 bảo đảman

toàn dựa vào. Chủ đề và khung này cho việc so sánh các phương pháp bảo đảman 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ự bảo đảm đượ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, bảo đảm 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ấytính hiệu quả và

tính chính xác là hai thuộc tính quan trọng trong bảo đảm 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ằnggiao 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

bảo đảm tính hiệu quả được thiết lập nhưng việc bảo đảm 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ồmcác chức

năng an toànthí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 bảo

đảm tính chính xác là có, nhưng nó thiếu sự bảo đảmtính hiệu quả do việc triển khai các chức năng an

toànkhông hiệu quả chống lại các mối đe dọa có thể xảy ra. Để đạt được sự bảo đảm toàn diện, giao

34

TCVN xxxx-1:201x

phẩm phải được đánh giá để bảo đảm 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ànthí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 ước lượng)

Một phương pháp ước lượng cho phép tuyên bố bảo đảm an toànđược điều chỉnh để đáp ứng giao

phẩm hoặc các yêu cầu bảo đảm 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ố bảo đảm an toàn, nhưng đòi hỏi những người dùng tuyên bố bảo

đảm an toàn này hiểu được hoàn toàn các bảo đảm thực sự được cung cấp. Thông thường, các tuyên

bố bảo đảm đượ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 bảo đảm an toàn có tạo

ra các bằng chứng bảo đảm bằng cách ước lượng 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 bảo đảm. 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ước lượng,

những người mà sau đó có thể ước lượng 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 bảo đảm 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ốbảo đảm 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Ụ: Bảo đảm 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 bảo đảm 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ớicá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ự bảo đảm 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 bảo đảm 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 Bảo đảm dự đoán

Là một yếu tố thuộc về 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ố bảo đảm. Nhiều mô

hình hoàn thiện năng lực giải quyết bảo đảm dự đoán.

35

TCVN xxxx-1:201x

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ề bảo đảmđưa ra bằng chứng bảo đảmbằ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 ước lượng hoặc bảo đảm dự đoán không cung cấp số lượng

mức độ của tính tin cậytrong việc bảo đảm 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ủ quanmà có thể được sử dụng theo một cách nào đó

để xác định số lượng bảo đảm. 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 bảo đảm an toàn

Việc xác định bảo đảm 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 bảo

đảm an toàntổ 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 bảo đảman 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à 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 bảo đảm đã 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 bảo

đảm 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) để bảo đảm

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 bảo đảm

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 bảo đảm 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 bảo đảm ước lượng 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ấpcócác sản phẩm an toàncông

nghệ thông tin đã được ước lượng và phát triển, và sử dụng sản phẩm đã được ước lượngan

toàncông nghệ thông tin để đạt được sự bảo đảm, đ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 bảo đảm để thiết lập bảo đảm 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ứbảo đảm sẽ được đưa ra cùng với một xếp hạngmức độ hoàn thiện

của tổ chức. Với việc bảo đảmnày, một kỹ thuật là đủ, chẳng hạn như cơ quan bảo đảm chỉ cần để giải quyết chính sách bảo

đảm 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 bảo đảm để đạt được sự bảo

đảm cao. Bởi vì nó được yêu cầu phải sử dụng phương pháp bảo đảm đặ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 ước lượng đã đượ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.

36

TCVN xxxx-1:201x

Ở nơi mà chính sách hay quy định hiện hành không quy định kỹ thuật bảo đảm, phương pháp hoặc

xếp hạng cụ thể, việc lựa chọn một phương pháp bảo đảm và mức độ bảo đảm được lựa chọn trong

thực hiện các yêu cầu bảo đảman toàn xác định. Tuy nhiên, có thể là quá trình quản lý rủi ro cho bên

thâu nhận đặc thù có thể chỉ ra các tình huống mà bảo đảman toàn khác nhau được chỉ định.

Ngay cả khi một phương pháp bảo đảm đượ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 bảo đảm.

b) mức độ bảo đảmnào là cần thiết.

c) phòng thí nghiệmước lượngnà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 bảo đảman 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 bảo đảm.

7.2.1 Xem xét tối ưu hóa

Cơ quan bảo đảm cần phải xác định sự kết hợp đúng đắn của các kỹ thuật bảo đảm để đáp ứng các

yêu cầu của tổ chức.

Cơ quan bảo đảm có thể xem xét các trường hợp bảo đảm 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ả bảo đảm trước là chưa thỏa đáng. Hơn nữa, là cơ quan

bảo đảm sẽ chịu trách nhiệm cuối cùng về việc bảo đảm an toàn cuối cùng của giao phẩm.

Bảo đảman toàn có thể được trình bày với các bên thâu nhận như một sự bảo đảm xuyên suốt từ bên

cung ứng củamột thành phần, sản phẩmCOTS, 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 bảo đảman 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 độ bảo đảman

toàn. Do đó, điều khoản vềbảo đảman 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 bảo đảman toàn nhằm giải thích các khía cạnh khác nhau của bảo đảman 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 bảo đảman toàn thích hợp là thiết lập nên tính tin cậy đáp

ứng mục tiêu an toàn của giao phẩm. Tính tin cậy thu được bằng cách xem xét lại bằng chứng bảo

đảm đã đạ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 độngcó 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 bảo đảman 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

37

TCVN xxxx-1:201x

một luận cứbảo đảm toàn diện mà thiết lập chắc chắn các loại và số lượng bảo đảmđạt được từ các

phương pháp bảo đảmđã á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/IEC17000.

8.1 Phương pháp đánh giá sự phù hợp bảo đảman 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à bảo đảmđã 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,…)

để bảo đảm rằng các nguồn lực chi tiêu vào việc cung cấp bảo đảman toàn là hợp lý cho loại và số

lượng bảo đảm 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 bảo đảm "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 bảo đảman toàn với chi phí cao khimà 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 SACAthí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 đồ SACAriê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 bảo đảm 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 xunh 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ố bảo đảm 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

bảo đảm này nên đáp ứng giống như tổ chức là cơ quan bảo đảm chỉ cần giải quyết chính sách bảo đảm 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 bảo đảm an toàn dựa

theo tiêu chuẩnTCVN 8709 cung cấp đánh giá bên thứ 3 về các tuyên bố bảo đảm an toàn cho sản phẩm.

Ví dụ thứ hai giải thích phạm vi mà cơ quan bảo đảm có thể có trong các phương pháp và kỹ thuậtbảo

đảm 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 bảo đảmnào được ưu tiên bởi cơ quan bảo đảm. 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á bảo đảman toàn riêng biệt, việc lựa chọn một phương

pháp bảo đảm và mức độ bảo đảmphù 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 bảo đảm 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ànkhác.

Ngay cả khi một phương pháp đánh giá bảo đảman 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ì.

38

TCVN xxxx-1:201x

- Mức độ bảo đảman 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.1Cá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 bảo đảm khác nhau,

các kiểu công nghệ khác nhau và mức độ bảo đảo 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 bảo đảm.

- 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á bảo đảm 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 bảo đảman toàn

Một phương pháp đánh giá bảo đảman toàn bao gồm:

- Mô tả các tuyên bố bảo đảm 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 bảo đảm an toàn.

- Một hay nhiều phương pháp đánh giá để đánh giá, ước lượng hay kiểm định các tuyên bố bảo

đảm 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 ước lượng có năng lực

- Một lưu đồ đánh giá sự phù hợp tùy chọn cung cấp tính tin cậy 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 bảo đảman 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 bảo đảm an toàn

và an toàn cho giao phẩm

39

TCVN xxxx-1:201x

Hình 3: Đánh giá sự phù hợp bảo đảman toàn

8.1.3 Phương pháp chuyên biệtvề bảo đảman toàn

Hiện tại có nhiều phương pháp đánh giá sự phù hợp bảo đảm với một số đặc trưng ít hơn cho việcbảo

đảman toàn. Tuy nhiên, các phương pháp bảo đảm khôngvề an toàncũng có thể chứa các thuộc tính

bảo đảm liên quan đến bảo đảman 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 bảo đảm khác nhau có thể có một số thành phần hoặc các khía cạnh bảo đảm chung.

Tất cả những yếu tố này sẽ có một ảnh hưởngtới khungbảo đảman 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 bảo đảm 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á bảo đảman 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

40

TCVN xxxx-1:201x

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ệtvề bảo đảman toàn

Do sẵn có số lượng nhỏ các phương pháp chuyên biệt về bảo đảman toàn, quan trọng là nhận ra giá

trị của tất cả các phương pháp bảo đảm từ nhiều phương pháp bảo đảm 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 bảo đảm 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ứbảo đảm 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ẩmriê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 bảo đảman toànkhô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ề bảo đảman toàn. Bảo đảman

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 bảo đảman toànnà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ácluận cứbảo đảm. Hơn nữa, người ta phải làm

quen với các yêu cầu bảo đảm và an toàncủ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ó để bảo đảm 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 bảo đảm 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 bảo đảm. 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 bảo đảman toàn riêng biệt. Tuy nhiên việc áp

dụng phương pháp bảo đảm chất lượng sẽ cung cấp tính tin cậymà 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ề bảo đảman 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 bảo đảmluô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 bảo đảman 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 địnhbảo đảman toàn sử

dụng phương pháp tiếp cận bảo đảmmức cao nhất định.

41

TCVN xxxx-1:201x

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 tragiao 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.) Bảo đảm 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 thigiao phẩm và

qua đó mang lại sự bảo đảman toàn khi áp dụng cho giao phẩman 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 bảo đảman 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 +++ + ++

42

TCVN xxxx-1:201x

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ụ, COTSphân phát

trước khi chúng hoạt động.VÍ DỤ:Một ước lượng tiêu chí chung của chức năng an toànvề 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ànvề 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, bảo đảm 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

bảo đảman 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 bảo đảman 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 bảo

đảm 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 bảo đảm

duy nhất được áp dụng. Ví dụ, một số phương pháp bảo đảm 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 bảo đảm vận hành.

Ví dụ này mô tả mô hình có thể hỗ trợ phương pháp bảo đảm 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.

43

TCVN xxxx-1:201x

Các kỹ thuật bảo đảman 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ẩnTCVN 8709, TCVN ISO/IEC 27001, và ISO/IEC 21827.

Để đạt được sự bảo đảm kết quả thì bảo đảmthu đượ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 bảo đảm của giai đoạn đó. Phương pháp này gia tăngbảo

đảmliê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 bảo đảm 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 bảo đảm 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 haybên

cung cấp thành phần.

44

TCVN xxxx-1:201x

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âmbên

trongđặc tả, phát triển hay hoạt động của giao phẩm, ví dụ như bên thâu nhận. Điều này có thể cung

cấp cho bên thâu nhậntính tin cậy trong các tuyên bố bảo đảman toàn đã đưa ra cho giao phẩm dựa

trênhiểu biết trực tiếp.

Hoạt động đánh giá sự phù hợpbê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 thâu nhậnvềtính tin cậynhiều

hơntrong các tuyên bố bảo đảman 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 tin cậy mà

bên thâu nhận có thể có trong các tuyên bố bảo đảman 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 độ bảo đảm có thể có hoặc không được biết đến

hay được chấp nhận do các phương pháp bảo đảmđã sử dụng) mức bảo đảmcó 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ẩmvớ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ànmở 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 8709và 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.

45

TCVN xxxx-1:201x

8.5 Xếp hạng bảo đảman toàn

Một số phương pháp bảo đảm an toàn cung cấp cơ chế để xác định số lượng phương phápbảo đảmđã

cung cấp. Có thể được tuyên bố như mức độ an toàn, mức độ bảo đảm ước lượng, điểm số, mức độ

chặt chẽ,….

Một phương pháp bảo đảm có thể cung cấp bảo đảman toàn với các mức bảo đảm 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 bảo đảman toànvà đã 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 tin cậy lớn

hơn cho người dùng bảo đảman toàn trong các yêu cầu bảo đảman 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 độ bảo đảman toànước lượng (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 bảo đảm đượ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ĩavề bảo đảm an toànđã rút ra từ các thành phần bảo đảman toàn được đưa ra

trongTCVN 8709-3. Với việc gia tăng các gói EALs bao gồm tăng ước lượngtheo chiều sâu cũng như ngày càng có nhiều yêu

cầu bao gồm trong dự án ước lượng đượ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ấtvề 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 tin cậybên thâu nhậntrong việc bảo đảm 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 bảo đảm 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 tin cậylà để 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ạngbảo đảm“mức cao” đưa ra là tất yếu nhiều hơnbảo đảman 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à bảo đảm 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ànthích đáng.

46

TCVN xxxx-1:201x

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 bảo đảman

toànthô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 độbảo đảmnế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 bảo đảman 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ố bảo

đảman toàn. Do đó bằng chứng có thểsẵn cócho bên thâu nhận hoặc cho bên xác nhận độc lập vềhoạt

động bảo đảm. 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 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 bảo đảm an toàn sẽ xem xét về nguồn gốc cảu 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 bảo đảman toàn đã cung cấp bởi các giao phẩmkhác

nhau.

47

TCVN xxxx-1:201x

ISO/CASCO là uỷ 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 Uỷ 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, cơ quan 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àngồ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 cơ quan công nhận công nhận cơ quan

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 chungcho đánh giá ngang hàng về cơ quan đánh

giá sự phù hợp vàcơ quan 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.

48

TCVN xxxx-1:201x

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

10Mô 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á bảo đảman 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àbảo

đảm 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, bảo

đảm 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 cơ quan 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óacủ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àncủa thẻ tín dụng với một mức phù hợp.

49

TCVN xxxx-1:201x

Như vậy lưu đồ có thể bao gồm các hoạt động đóng góp cho tính tin cậy có thể được đưa ra trong các

bằng chứng bảo đảman 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 bảo đảm 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ủanhân lực được chuẩn bịcác hoạt động về đánh giá, ước lượng và kiểm

tra đáp ứng tiêu chuẩn tối thiểu.

- Bảo đảmsự 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á, ước

lượng và kiểm định.

- Ban hành hướng dẫn và tư vấn cho người dùng bảo đảm an toàn.

- Thiết lập các chính sách đạo đức để bảo đảm 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ộtlưu đồ đánh giá sự phù hợp bảo đảm 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 bảo đảman toàn cao hơnđạt

được bằng cách sử dụng phương pháp bảo đảm tương ứng.

10.2 Cơ quan đánh giá sự phù hợp SACA

Cơ quan đá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 bảo đảman 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 ước lượng 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."

Cơ quan đá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 cơ quan đánh giá sự phù hợp SACA:

10.2.1Loại A Đánh giá sự phù hợp

Loại A, hay đánh giá sự phù hợp 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.

50

TCVN xxxx-1:201x

Đánh giá bên thứ nhất cung cấp bảo đảmthấ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.2Cơ quan đá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ứccủ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 bảo đảm 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.3Cơ quan đá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 độ bảo đảm 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 bảo đảman

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, haychương trình được định nghĩa trong ISO/IEC17000, và đánh giá sự

phù hợp bảo đảman 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

51

TCVN xxxx-1:201x

Hình 6: Mối quan hệ tổng quát giữa các thực thể trong bảo đảman toàn

Hình 6 - Mối quan hệ tổng quát giữa các thực thể trong bảo đảman 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 bảo đảman 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.1Tiê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 bảo đảm 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 cơ quan công nhận có trách nhiệm công nhận và theo dõi từng lưu đồ quốc gia để

bảo đảm rằng hệ thống đánh giá sự phù hợp hoạt động bởilư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 cơ quanđá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 cơ quan công nhận CC, đó là một yêu cầu mà cơ quan đá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 bảo đảm 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

52

TCVN xxxx-1:201x

Hình 7: Mẫu mô hình SACA tiêu chí chung, sử dụng thuật ngữ ISO

10.3.2Chươ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ề cơ quan công nhận, với mục tiêu bảo

đảm 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 (cơ quan 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 cơ quan đá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ẽ.

53

TCVN xxxx-1:201x

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.3Công nghiệp thẻ thanh toán

Mô hình Công nghiệp thẻ thanh toán cho bảo đảman 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 bảo đảm khác nhau

cho các thương gia, bên cung cấp dịch vụ,bên thâu nhận; 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

bảo đảm. Đối với một số trường hợp bảo đảm các chính sách xung quanh đánh giá loại A là khác nhau

54

TCVN xxxx-1:201x

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ự bảo đảm 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 bảo đảm để 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à bảo đảmlà 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ơ quanbảo đảmquan tâm các trường

hợp bảo đảm khác nhau như một tập các bảo đảm 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 bảo

đảman toàn. Nó thích hợp với chủ đề từ đó nhiều trường hợp và tuyên bốbảo đảman 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 bảo đảman 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ânvà 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.

55

TCVN xxxx-1:201x

- Phương pháp bảo đảm an toàn đã sử dụng cho việc đánh giá các thành phần.

- Xếp hạng bảo đảm an toàn.

- Chính sách an toàn toàn diện về sản phẩm thành phần.

Một số thành phần bảo đảm an toàn là có thể được thông qua hình thức thỏa thuận bảo đảm 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àncuối cùng xác định sự bảo đảmchấ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 bảo đảm an toàn và vì thang chuẩn hóa hoặc phương

thức bảo đảm qua những phương pháp bảo đảm khác nhau không tồn tại.

Những ví dụ dưới dây giải thích các kịch bản bảo đảm 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.1Phát triển một trường hợp bảo đảm trong thiết lập một cách hợp nhất

Để giải quyết các thành phần đa công nghệ bảo đảm được áp dụng tới giao phẩmcụ thể, tốt nhất để

xây dựng mô hình bảo đảm an toàn thể hiện các loại hình đánh giá bảo đảm khác nhau như thế nào

được dùng để cùng làm việcgóp phần vào sự bảo đảm tổng thể được kết hợp cùnggiao phẩm. Mô hình

bảo đảm an toàncho giao phẩmcó thể bao gồm các mô hình bảo đảm hợp thành khác nhau – mỗi loại

phù hợp với công nghệ bảo đảm riêng biệt (ví dụ bảo đảmước lượng, bảo đảm quy trình, bảo đảm

phát triển). Theo đó, mô hình bảo đảm phân phối do là một kết hợp một số mô hình bảo đảm riêng biệt,

sẽ chỉ ra các mô hình bảo đảm này được kết hợp với nhau như thế nào bất chấp giai đoạn bảo đảm tới

những gì chúng đã được áp dụng.

Hơn nữa, nó có thể là một số bảo đảm 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 thâu nhận 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 bảo đảm rằng người

nhận cuối cùng nhận được một bức tranh rõ ràng về việc bảo đảm an toàn liên quan.

Mỗi mô hình bảo đảm có thể xác định loại và số lượng bảo đảm 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 bảo đảm phân phốisẽ 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ả bảo đảm 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 bảo đảm. 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 bảo đảm (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 bảo đảm.

c) Lựa chọn biện pháp kiểm soát thích hợp để đáp ứng việc bảo đảm đã 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ố bảo đảm chính nó).

d) Đo hiệu quả của các biện pháp kiểm soátđã thực thi.

56

TCVN xxxx-1:201x

Cơ quan bảo đảm có thể tăng tính tin cậykhi mà hệ thống quản lý được đánh giá bởibê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 bảo đảmmà 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.1Vấ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.2Nhữ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:

57

TCVN xxxx-1:201x

- 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á bảo đảm.

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

- Sức 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ầntrong các kiểm thử sản phẩm.

11.1.3Thành phần sử dụng kỹ thuật bảo đảm 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ự ước lượng, 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 cấu thành

Đ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.1Phân lớp

58

TCVN xxxx-1:201x

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 độ bảo đảm đá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 bảo đảman 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 bảo đảm như nhau. Trong trường hợp này TCVN 8709 được sử dụng để cung cấp bảo đảm mà

chức năng an toàncủa các thành phần khác nhau được thực hiện như đã tuyên bố.

59

TCVN xxxx-1:201x

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 ước lượng 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 độ bảo đảmước lượng 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 ước lượng 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ộctố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).

60

TCVN xxxx-1:201x

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ụngtạ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 ước

lượng lớp thấp hơn và do đó đã không là vấn đề để đánh giábảo đảm.

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 ước lượng 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 đã ước lượng 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 độ bảo đảm ước lượng).

11.2.2Mạ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.

61

TCVN xxxx-1:201x

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.

- Ước lượng bảo vệ thuộc tính có thể vẫn là một vấn đề.

- Ước lượng độc lập đến mức bảo đảm 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:

62

TCVN xxxx-1:201x

- 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.3Thà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ànhVÍ DỤ: Một thư viện hay hệ thống con cung cấp các chức năng an toàncụ 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íchkhả 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.4Những vấn đề cần được xem xét

Vì thiếu các thành phần tách biệt có thể:

- Bỏ qua chức năng an toàn củacác thành phần khác.

63

TCVN xxxx-1:201x

- 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 độngnâng cao

Như đãđề cập trước trong tiêu chuẩn này, chủ đề về bảo đảm an toàn thành phần của thành phần bảo

đảman toàn tương đối chưa trưởng thành, vẫn chưa được xem là quan trọng để cung cấp bảo đảman

toàn trong bối cảnh của giao phẩmCOTS, 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 bảo đảman toàn chuỗi cung ứng. Trong điều này một số lĩnh vực nơi công

việc tiếp theo có thể được hưởng lợi mà chủ đề này đề cập.

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 bảo đảm cao hơn yêu cầu nghiên cứu thêm.

64

TCVN xxxx-1:201x

Thư mục tài liệu tham khảo

Tài liệu ISO và ISO/IEC có liên quan đến bảo đảman toàn Công nghệ thông tin.

[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-Ước lượng 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:2010Hệ thống và công nghệ

phần mềm - Hệ thống và bảo đảm 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à bảo đảm phần mềm - Phần 2: Trường hợp bảo đảm).

[4] ISO/IEC FCD 15026-3: To be published, System and software engineering- Systems and

software assurance - Part 3: System integrity levels (ISO/IEC FCD 15026-3: đã công bố, Hệ

thống và công nghệ phần mềm - Hệ thống và bảo đảm 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 (ISO/IEC 15408:2008 (tất cả các phần), Công nghệ thông tin - Kỹ thuật an

toàn – Tiêu chí ước lượngan toàncô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] ISO/IEC 17000:2004, Conformity assessment - Vocabulary and general principles (ISO/IEC

17000: 2004, Đá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/lEC 17020:1998 Conformity assessment - General criteria fortheoperation ofvarious types

ofbodies performing inspection (ISO/lEC 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 forbodies providing

auditandcertification of management systems (ISO/IEC 17021: 2011, Đánh giá sự phù hợp -

65

TCVN xxxx-1:201x

Yêu cầu đối với cơ quankiể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 forthe competence

oftesting 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/lEC 17030:2003, Conformity assessment - Generalrequirements forthird-party

marksofconformity (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/IEC18045:2009, Information technology - Securitytechniques - Methodology

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

ofoperational 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- Acodeofpractice fortheuseofinformation

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] ISO/IEC 27001:2005, Information technoloqy - Security techniques - Information security

management systems - Requirements(ISO/IEC 27001: 2005, 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] ISO/IEC 27002:2005, Information technology- Security techniques - Code of practice for

information securitymanagement (ISO/IEC 27002: 2005, Công nghệ thông tin - Kỹ thuật an

toàn - Quy phạm thực hành quản lý an toàn thông tin).

[22] ISO/IEC27005:2011,Information technology - Securitytechniques - Information

securityriskmanagement(ISO/IEC 27005: 2011, Công nghệ thông tin - Kỹ thuật an toàn - Thông

tin quản lý rủi ro an toàn).

[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

66

TCVN xxxx-1:201x

1: Tổng quan và khái niệm)

67