TIÊU CHUẨN QUỐC GIA TCVN 8709-1:2011 (ISO/IEC 15408-1:2009) VỀ CÔNG NGHỆ THÔNG TIN – CÁC KỸ THUẬT AN TOÀN – CÁC TIÊU CHÍ ĐÁNH GIÁ AN TOÀN CNTT – PHẦN 1: GIỚI THIỆU VÀ MÔ HÌNH TỔNG QUÁT

TIÊU CHUẨN QUỐC GIA

TCVN 8709-1 : 2011

ISO/IEC 15408-1:2009

CÔNG NGHỆ THÔNG TIN – CÁC KỸ THUẬT AN TOÀN CÁC TIÊU CHÍ ĐÁNH GIÁ AN TOÀN CNTT – PHẦN 1: GIỚI THIỆU VÀ MÔ HÌNH TỔNG QUÁT

lnformation Technology – Security Techniques – Evaluation Criteria for IT Security -Part 1: Introduction and General Model

Lời nói đầu

TCVN 8709-1:2011 hoàn toàn tương đương ISO/IEC 15408-1:2008

TCVN 8709-1:2011 do Trung tâm Ứng cứu khẩn cấp máy tính Việt Nam biên soạn, Bộ Thông tin và Truyền thông đề nghị, Tổng cục Tiêu chuẩn Đo lường Chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố. .

Lời giới thiệu

Tiêu chuẩn này cho phép thực hiện so sánh các kết quả đánh giá an toàn độc lập. Tiêu chuẩn cung cấp một tập các yêu cầu chung về chức năng an toàn cho các sản phẩm công nghệ thông tin (CNTT), và về các biện pháp đảm bảo áp dụng cho các sản phẩm này trong quá trình đánh giá an toàn. Các sản phẩm CNTT này có thể dưới dạng phần cứng, phần sụn hay phần mềm.

Quy trình đánh giá thiết lập một mức tin cậy về việc các chức năng an toàn cho các sản phẩm CNTT và các biện pháp đảm bảo áp dụng cho chúng thỏa mãn các yêu cầu nêu trên. Các kết quả đánh giá có thể giúp người dùng xác định xem sản phẩm hoặc hệ thống CNTT có thỏa mãn yêu cầu đảm bảo an toàn của chúng hay không.

TCVN 8709 là một chỉ dẫn bổ ích cho phát triển, đánh giá và/hoặc đầu tư các sản phẩm CNTT với chức năng an toàn.

TCVN 8709 có tính mềm dẻo, cho phép áp dụng nhiều phương pháp đánh giá cho nhiều đặc tính an toàn của đa dạng sản phẩm CNTT. Chính vì vậy, người dùng tiêu chuẩn này cần thận trọng khi áp dụng để tránh lạm dụng nó. Ví dụ, nếu sử dụng TCVN 8709 kết hợp với các phương pháp đánh giá không phù hợp, các đặc tính an toàn không thích hợp, hoặc các sản phẩm CNTT không phù hợp sẽ dẫn đến các kết quả đánh giá vô nghĩa.

Do vậy, thực tế là một sản phẩm CNTT đã được đánh giá chỉ có ý nghĩa trong phạm vi ngữ cảnh các đặc tính an toàn được đánh giá với các phương pháp đánh giá cụ thể đã sử dụng. Các cơ quan đánh giá cần kiểm tra thận trọng các sản phẩm, đặc tính và các phương pháp để xác định rõ việc đánh giá đem lại kết quả có nghĩa. Ngoài ra, người mua các sản phẩm đã được đánh giá cũng cần xem xét kỹ lưỡng ngữ cảnh này để xác định xem sản phẩm đã đánh giá có hữu ích và áp dụng được cho trường hợp cụ thể của mình và đáp ứng yêu cầu hay không.

TCVN 8709 đề cập đến việc bảo vệ tài sản thông tin chống các truy nhập trái phép, các sửa đổi hoặc mất mát trong sử dụng. Phân loại bảo vệ liên quan đến ba kiểu lỗi an toàn kể trên tương ứng với tính bí mật, tính toàn vẹn và tính sẵn sàng. TCVN 8709 cũng có thể áp dụng cho các đánh giá ngoài ba nhóm trên. TCVN 8709 áp dụng cho các rủi ro phát sinh từ các hành vi của con người (ác ý hoặc lý do khác), và cho các rủi ro không do con người tạo ra. Ngoài an toàn CNTT, TCVN 8709 có thể áp dụng cho các lĩnh vực CNTT khác, song không có ràng buộc nào khi áp dụng cho các lĩnh vực đó.

Một số chủ đề do liên quan đến các kỹ thuật đặc biệt hoặc do chúng nằm ngoài lĩnh vực an toàn CNTT sẽ được coi là nằm ngoài phạm vi TCVN 8709. Một số chủ đề trong số đó như sau:

a) TCVN 8709 không gồm các tiêu chí đánh giá an toàn gắn liền với các biện pháp an toàn quản lý không liên quan trực tiếp tới chức năng an toàn CNTT. Tuy vậy, cũng phải thừa nhận rằng an toàn cơ bản thường đạt được thông qua hoặc được hỗ trợ bởi các biện pháp quản lý ví dụ về mặt tổ chức, nhân sự, vật lý và các thủ tục kiểm soát.

b) Đánh giá các khía cạnh vật lý kỹ thuật của an toàn CNTT ví dụ như kiểm soát dò rỉ thông tin qua điện từ trường không được đề cập riêng biệt, mặc dù nhiều khái niệm đã đề cập có thể áp dụng cho lĩnh vực này.

c) TCVN 8709 không đề cập đến hệ phương pháp đánh giá mà các tiêu chí này sẽ được áp dụng. Hệ phương pháp này được nêu trong ISO/IEC 18045.

d) TCVN 8709 không đề cập đến bộ khung pháp lý và quản lý mà các tiêu chí này sẽ được áp dụng bởi các cơ quan đánh giá. Tuy nhiên, có thể coi là TCVN 8709 sẽ được sử dụng cho các mục đích đánh giá trong ngữ cảnh các bộ khung đó.

e) Các thủ tục sử dụng các kết quả đánh giá để công nhận nằm ngoài phạm vi TCVN 8709. Công nhận là một quy trình quản lý trong đó cho phép quyền khai thác một sản phẩm CNTT (hoặc một tập các sản phẩm) trong mỗi trường hoạt động đầy đủ của nó bao gồm tất cả các phần phi- CNTT. Các kết quả của quy trình đánh giá là đầu vào cho quy trình công nhận. Tuy nhiên, do các kỹ thuật khác thường phù hợp hơn cho việc đánh giá các đặc tính phi- CNTT và mối quan hệ của chúng với các thành phần an toàn CNTT, việc công nhận cần xem xét riêng các khía cạnh này.

f) Chủ đề tiêu chí đánh giá cho chất lượng vốn có của các thuật toán mã hóa không nằm trong TCVN 8709. Nếu cần có đánh giá độc lập cho các đặc tính toán học của mã hóa, lược đồ đánh giá áp dụng TCVN 8709 sẽ phải cung cấp thêm các đánh giá này.

Các thuật ngữ ISO, như “có khả năng”, “tham khảo“,“có thể”, “bắt buộc”, “cần” và “nên” sử dụng xuyên suốt trong văn bản tiêu chuẩn được định nghĩa trong Các chỉ thị ISO/IEC, phần 2. Lưu ý rằng khái niệm “nên” có nghĩa bổ sung khi áp dụng tiêu chuẩn này. Xem lưu ý dưới đây. Định nghĩa sau đây quy định việc sử dụng từ “nên” trong TCVN 8709.

Nên

Trong văn bản quy chuẩn, từ “nên” dùng để biểu thị “trong một số khả năng, có một khả năng được khuyến nghị là đặc biệt thích hợp mà không cần quan tâm hay loại trừ những khả năng khác, hoặc một diễn biến hành động nào đó được coi là ưa chuộng chứ không cần bắt buộc” (ISO/IEC Directives, Part 2).

CHÚ THÍCH: TCVN 8709 giải thích cụm từ “không cần bắt buộc” nghĩa là việc lựa chọn một khả năng khác đòi hỏi phải giải thích vì sao phương án ưa chuộng hơn không được chọn.

 

CÔNG NGHỆ THÔNG TIN – CÁC KỸ THUẬT AN TOÀN CÁC TIÊU CHÍ ĐÁNH GIÁ AN TOÀN CNTT – PHẦN 1: GIỚI THIỆU VÀ MÔ HÌNH TỔNG QUÁT

lnformation Technology – Security Techniques – Evaluation Criteria for IT Security -Part 1: Introduction and General Model

1. Phạm vi áp dụng

Tiêu chuẩn này thiết lập các khái niệm và nguyên lý chung cho đánh giá an toàn CNTT và đặc tả mô hình đánh giá tổng quát tạo bởi các phần của tiêu chuẩn quốc tế một cách toàn diện, được sử dụng làm cơ sở cho đánh giá các thuộc tính an toàn của các sản phẩm CNTT.

Tiêu chuẩn này trình bày tổng quan về các phần của bộ TCVN 8709. Nó mô tả các phần của chuẩn; định nghĩa các khái niệm và các từ viết tắt sử dụng xuyên suốt trong toàn bộ các phần của tiêu chuẩn; thiết lập khái niệm cốt lõi về Đích đánh giá (TOE); ngữ cảnh đánh giá; mô tả đối tượng độc giả mà các tiêu chí đánh giá hướng đến. Tiêu chuẩn này cũng đưa ra các khái niệm an toàn cơ bản cần thiết cho việc đánh giá các sản phẩm CNTT.

Tiêu chuẩn định nghĩa các thao tác làm cơ sở để đưa ra các thành phần chức năng trong TCVN 8709­–2 và các thành phần đảm bảo trong TCVN 8709-3 thông qua việc sử dụng các thao tác cho phép.

Các khái niệm cơ bản về Hồ sơ bảo vệ (PP), các gói yêu cầu an toàn và chủ đề về tính tuân thủ sẽ được nêu; các hệ quả đánh giá và các kết quả đánh giá cũng được mô tả. Phần này của tiêu chuẩn đưa ra hướng dẫn cho việc đặc tả Đích an toàn (ST) và cung cấp bản mô tả về tổ chức các thành phần xuyên suốt mô hình. Thông tin tổng quan về phương pháp luận đánh giá và phạm vi các lược đồ đánh giá được đưa ra trong ISO/IEC 18045.

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

Tài liệu viện dẫn sau đây không thể thiếu được khi áp dụng tài liệu tiêu chuẩn này:

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

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

ISO/IEC 18045, “Công nghệ thông tin – Các kỹ thuật an toàn – Hệ phương pháp cho đánh giá an toàn CNTT” (ISO/IEC 18045, “Information Technology – Security Techniques – Methodology for IT security evaluation”).

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

Tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa sau đây.

CHÚ THÍCH: Điều khoản này chỉ gồm các thuật ngữ sử dụng riêng trong TCVN 8709. Một số kết hợp của các thuật ngữ chung dùng trong TCVN không có trong điều khoản này sẽ được giải thích rõ trong ngữ cảnh nơi chúng được sử dụng.

3.1. Các thuật ngữ và định nghĩa chung trong TCVN 8709

3.1.1

Các hành động có hại (adverse actions)

Các hành động thực hiện bởi một tác nhân đe dọa vào một tài sản.

3.1.2

Tài sản (assets)

Các thực thể mà chủ sở hữu TOE đặt giá trị vào đó.

3.1.3

Chỉ định (assignment)

Định rõ một tham số định danh trong một thành phần (của TCVN 8709) hoặc một yêu cầu.

3.1.4.

Bảo đảm (assurance)

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

3.1.5

Khả năng tấn công (attack potential)

Ước lượng về khả năng tấn công vào TOE biểu thị qua kinh nghiệm, tài nguyên và động cơ của kẻ tấn công.

3.1.6

Gia tăng (augmentation)

Việc thêm một hoặc nhiều yêu cầu vào một gói.

3.1.7

Dữ liệu xác thực (authentication data)

Thông tin được dùng để xác minh định danh đã tuyên bố của một người dùng.

3.1.8

Người dùng có thẩm quyền (authorised user)

Người dùng có thể thực thi một thao tác tương ứng với các SFR.

3.1.9

Lớp (class)

Tập các họ TCVN 8709 cùng chia sẻ một mục tiêu chung.

3.1.10

Tính mạch lạc (coherent)

Sắp sếp thứ tự logic, có nghĩa rõ ràng.

CHÚ THÍCH: Đối với tài liệu, thuật ngữ này dùng cho cả nội dung và cấu trúc của văn bản, biểu thị việc độc giả có hiểu được văn bản đó hay không.

3.1.11

Tính hoàn thiện (complete)

Tính chất thể hiện rằng tất cả các thành phần cần thiết của một thực thể đều được cung cấp.

CHÚ THÍCH: Đối với tài liệu, tính hoàn thiện nghĩa là mọi thông tin liên quan đều có trong tài liệu, ở mức độ chi tiết đến mức không cần có giải thích gì thêm.

3.1.12

Thành phần (component)

Tập nhỏ nhất lựa chọn được của các phần tử mà các yêu cầu có thể dựa vào.

3.1.13

Gói đảm bảo tổng hợp (composed assurance package)

Gói đảm bảo này gồm các yêu cầu rút ra từ TCVN 8709-3 (chủ yêu từ lớp ACO), biểu thị một điểm trong cấp độ đảm bảo tổng hợp đã định nghĩa trước trong TCVN 8709.

3.1.14

Xác nhận (confirm)

Công bố một việc đã được soát xét chi tiết với việc xác định tính đầy đủ một cách độc lập.

CHÚ THÍCH: Mức độ chính xác theo yêu cầu phụ thuộc vào bản chất của sự việc. Khái niệm trên chỉ áp dụng cho các hành động của đánh giá viên.

3.1.15.

Tính kết nối (connectivity)

Đặc tính của TOE cho phép tương tác với các thực thể CNTT bên ngoài TOE.

CHÚ THÍCH: đặc tính này bao gồm việc trao đổi dữ liệu qua phương thức hữu tuyến hoặc vô tuyến, qua một khoảng cách bất kỳ trong một môi trường hoặc cấu hình bất kỳ.

3.1.16

Tính nhất quán (consistent)

Mối quan hệ giữa hai hoặc nhiều thực thể trong đó không có sự đối lập rõ rệt nào giữa chúng.

3.1.17

Chổng đỡ (counter, verb)

Đối đầu với một tấn công, làm giảm thiểu tác động của mối đe dọa song không nhất thiết phải loại trừ

3.1.18

Tính tuân thủ diễn giải được (demonstrable conformance)

Mối quan hệ giữa một ST và một PP, trong đó ST cung cấp một giải pháp để giải quyết vấn đề an toàn chung nêu trong PP.

CHÚ THÍCH: PP và ST có thể chứa các phát biểu khác nhau hoàn toàn mô tả về các thực thể, khái niệm,… khác nhau. Tính tuân thủ diễn giải được cũng thích hợp với một kiểu TOE khi tồn tại một số PP tương tự nhau, vì thế cho phép tác giả ST tuyên bố tuân thủ đồng thời theo các PP này để giúp tiết kiệm thời gian.

3.1.19

Sự chứng minh (demonstrate)

Đưa ra một kết luận rút ra từ việc phân tích, tuy có kém chặt chẽ hơn một “bằng chứng”.

3.1.20

Tính phụ thuộc (dependency)

Mối quan hệ giữa các thành phần mà nếu trong đó một yêu cầu dựa trên thành phần phụ thuộc được đưa vào một PP, ST hoặc một gói thì yêu cầu dựa trên thành phần được phụ thuộc cũng thường phải được đưa vào PP, ST hoặc gói đó.

3.1.21

Mô tả (describe)

Cung cấp các chi tiết đặc trưng của một thực thể.

3.1.22.

Xác định (determine)

Khẳng định một kết luận riêng dựa trên một phép phân tích độc lập với mục tiêu đạt được một kết luận cụ thể.

CHÚ THÍCH: Việc sử dụng khái niệm này ngầm chỉ một phép phân tích độc lập tin cậy, thường dùng khi thiếu phân tích trước đó. So sánh với các khái niệm “xác nhận” hay “thâm tra“ ngầm chỉ một phân tích đã thực hiện trước đó cần thiết phải soát xét lại.

3.1.23

Môi trường phát triển (development environment)

Môi trường để phát triển TOE.

3.1.24

Phần tử (element)

Phát biểu cơ bản nhất về một yêu cầu an toàn.

3.1.25

Bảo đảm (ensure)

Sự bảo đảm về mối quan hệ nhân quả chắc chắn giữa một hành động và các hệ quả của nó.

CHÚ THÍCH: Thuật ngữ này với từ „giúp” đặt trước sẽ biểu thị rằng hệ quả không hoàn toàn chắc chắn nếu chỉ có hành động đó.

3.1.26

Đánh giá (evaluation)

Đánh giá một PP, một ST hoặc một TOE theo các tiêu chí đã xác định.

3.1.27

Mức bảo đảm đánh giá (evaluation assurance level – EAL)

Tập các yêu cầu đảm bảo rút ra từ bộ TCVN 8709-3, biểu thị một điểm mốc trên cấp bậc bảo đảm được xác định trước trong TCVN 8709, tạo thành một gói đảm bảo.

3.1.28

Cơ quan đánh giá (evaluation authority)

Cơ quan thiết lập tiêu chuẩn và giám sát chất lượng các đánh giá được thực hiện bởi các đơn vị trong một cộng đồng cụ thể và là đơn vị thực thi TCVN 8709 cho cộng đồng thông qua một lược đồ đánh giá.

3.1.29

Lược đồ đánh giá (evaluation scheme)

Bộ khung quản lý và quy định về việc áp dụng TCVN 8709 cho một cơ quan đánh giá trong một cộng đồng cụ thể.

3.1.30

Thấu đáo (exhaustive)

Đặc trưng của một phương pháp tiếp cận được sử dụng để thực hiện một phân tích hoặc hoạt động theo một kế hoạch rõ ràng.

CHÚ THÍCH: Khái niệm này sử dụng trong TCVN 8709 chú trọng đến việc hướng dẫn phân tích hoặc các hoạt động khác. Nó liên quan đến tính hệ thống song được coi là mạnh hơn. Với nghĩa này, nó không chỉ biểu thị một cách tiếp cận có phương pháp đã được dùng để thực hiện phân tích hay thực hiện công việc theo một kế hoạch rõ ràng, mà còn biểu thị rằng kế hoạch này là đầy đủ để bảo đảm rằng đã thực hiện theo mọi con đường có thể.

3.1.31

Giải thích (explain)

Đưa ra luận cứ về lý do thực hiện một hành động.

3.1.32

Mở rộng (extension)

Bổ sung thêm vào một ST hoặc PP các yêu cầu chức năng không chứa trong TCVN 8709-2 và/hoặc các yêu cầu đảm bảo không chứa trong TCVN 8709-3.

3.1.33

Thực thể bên ngoài (external entity)

Một người dùng hay thiết bị CNTT có thể tương tác với TOE từ bên ngoài ranh giới TOE.

CHÚ THÍCH: Một thực thể bên ngoài có thể được coi là một người dùng.

3.1.34

Họ (family)

Một nhóm các thành phần cùng chia sẻ một mục tiêu giống nhau song khác nhau về tầm quan trọng hay tính chặt chẽ.

3.1.35

Hình thức (formal)

Cách biểu thị bằng một ngôn ngữ cú pháp hạn chế với ngữ nghĩa xác định trên cơ sở các khái niệm toán học được thiết lập rõ ràng.

3.1.36

Tài liệu hướng dẫn (guidance documentation)

Tài liệu mô tả về việc vận chuyển, chuẩn bị, vận hành, quản lý và/hoặc sử dụng cho TOE.

3.1.37

Định danh (identity)

Việc biểu diễn các thực thể (chẳng hạn như người dùng, tiến trình hoặc ổ đĩa) xác định duy nhất trong ngữ cảnh của TOE.

CHÚ THÍCH: Một ví dụ về việc biểu diễn này là một chuỗi ký tự. Đối với người dùng, biểu diễn có thể là tên đầy đủ, hoặc tên viết tắt hoặc một bí danh (duy nhất) của người dùng.

3.1.38

Không hình thức (informal)

Cách diễn tả bằng ngôn ngữ tự nhiên.

3.1.39

Vận chuyển giữa các TSF (inter TSF transfers)

Trao đổi dữ liệu giữa TOE với chức năng an toàn của các sản phẩm CNTT tin cậy khác.

3.1.40

Kênh truyền thông nội bộ (internal communication channel)

Kênh truyền thông giữa các phần tách biệt của TOE.

3.1.41

Vận chuyển nội bộ TOE (internal TOE transfer)

Trao đổi dữ liệu giữa các phần tách biệt của TOE.

3.1.42

Tính nhất quán nội bộ (internally consistent)

Là không có đối lập rõ nét nào trong mọi khía cạnh của một thực thể.

CHÚ THÍCH: Trong tài liệu, điều này có nghĩa là không có phát biểu nào đối lập với phát biểu khác.

3.1.43

Phép lặp (iteration)

Là việc sử dụng lặp lại một thành phần để thể hiện hai hoặc nhiều yêu cầu riêng biệt.

3.1.44.

Biện minh (justification)

Là việc phân tích để đi đến một kết luận.

CHÚ THÍCH: Khái niệm “biện minh” chặt chẽ hơn là “diễn giải”. Khái niệm này đòi hỏi tính chính xác đáng kể về việc giải thích một cách đặc biệt thận trọng và kỹ lưỡng từng bước cho một luận cứ logic.

3.1.45

Đối tượng (object)

Thực thể thụ động trong TOE có chứa hoặc tiếp nhận thông tin, mà dựa vào đó các chủ thể thực thi các hoạt động.

3.1.46

Hoạt động (operation)

(đối với một thành phần của TCVN 8709) là sự sửa đổi hoặc lặp lại một thành phần.

CHÚ THÍCH: Các hoạt động được phép cho thành phần là chỉ định, phép lặp, bổ sung chi tiết và lựa chọn.

3.1.47

Hoạt động (operation)

(đối với một đối tượng) là kiểu đặc trưng của một hành động do một chủ thể thực hiện trên một đối tượng.

3.1.48

Môi trường vận hành (operational environment)

Môi trường trong đó TOE hoạt động.

3.1.49

Chính sách an toàn của tổ chức (organizational security policy)

Tập các quy tắc, thủ tục, hoặc hướng dẫn an toàn cho một tổ chức.

CHÚ THÍCH: Một chính sách có thể chỉ áp dụng cho một môi trường vận hành cụ thể.

3.1.50

Gói (package)

Tập được đặt tên của các yêu cầu chức năng an toàn hoặc đảm bảo an toàn.

CHÚ THÍCH: Một ví dụ về gói là “EAL 3″.

3.1.51

Đánh giá Hồ sơ bảo vệ (Protection Profile evaluation)

Đánh giá một PP theo các tiêu chí định sẵn.

3.1.52

Hồ sơ bảo vệ (Protection Profile – PP)

Phát biểu độc lập về mặt thực thi các yêu cầu cho một kiểu TOE.

3.1.53

Chứng minh (prove)

Chỉ ra sự phù hợp bằng việc phân tích hình thức theo cách tiếp cận toán học.

CHÚ THÍCH : Khái niệm này chính xác toàn diện theo mọi mặt. Điển hình, khái niệm chứng minh được dùng khi mong muốn chỉ ra sự phù hợp giữa 2 biểu diễn TSF ở một mức chính xác cao.

3.1.54

Tinh chỉnh (refinement)

Bổ sung thêm các chi tiết cho một thành phần.

3.1.55

Vai trò (role)

Một tập các quy tắc xác định trước để thiết lập các tương tác được phép giữa một người dùng và TOE.

3.1.56

Bí mật (secret)

Là thông tin chỉ được người có thẩm quyền và / hoặc TSF biết để thực thi một SFP cụ thể.

3.1.57

Trạng thái an toàn (secure State)

Trạng thái mà dữ liệu TSF là nhất quán và TSF tiếp tục thực thi chuẩn xác các SFR.

3.1.58

Thuộc tính an toàn (security attribute)

Các đặc tính của các chủ thể, người dùng (bao gồm các sản phẩm CNTT bên ngoài), đối tượng, thông tin, các phiên và/hoặc các tài nguyên được dùng cho việc xác định các SFR và các giá trị của chúng được dùng trong thực thi các SFR.

3.1.59

Chính sách chức năng an toàn (security function policy)

Tập các quy tắc mô tả hành vi an toàn cụ thể được thực thi bởi TSF và được biểu thị như một tập các SFR.

3.1.60

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

Phát biểu về hướng đối phó với các mối đe dọa xác định và/hoặc hướng thỏa mãn các chính sách an toàn xác định của tổ chức cũng như hướng thỏa mãn các giả định.

3.1.61

Vấn đề an toàn (security problem)

Phát biểu dạng hình thức định nghĩa bản chất và phạm vi an toàn mà TOE chủ ý đề cập đến.

CHÚ THÍCH: Phát biểu là sự kết hợp của:

– Các mối đe dọa mà TOE cần chống trả,

– Các OSP được thực thi bởi TOE, và

– Các giả định đặt ra cho TOE và môi trường vận hành của nó.

3.1.62

Yêu cầu an toàn (security requirement)

Yêu cầu được phát biểu trong ngôn ngữ tiêu chuẩn, dùng để đạt được các mục tiêu an toàn cho một TOE.

3.1.63

Đích an toàn (Security Target – ST)

Phát biểu phụ thuộc thực thi về các yêu cầu cần thiết của một TOE xác định.

3.1.64

Lựa chọn (selection)

Việc định rõ một hoặc nhiều khoản mục từ một danh sách trong một thành phần.

3.1.65

Bán hình thức (semiformal)

Biểu thị bằng một ngôn ngữ cú pháp hạn chế với ngữ nghĩa xác định trước.

3.1.66

Đặc tả (specify)

Là đưa ra chi tiết đặc trưng về một thực thể theo một cách chính xác và chặt chẽ.

3.1.67

Tuân thủ chặt chẽ (strict conformance)

Mối quan hệ có thứ bậc giữa một PP và một ST trong đó mọi yêu cầu có trong PP thì cũng tồn tại trong ST.

CHÚ THÍCH: Mối quan hệ này có thể được xác định như „ST sẽ chứa tất cả các phát biểu có trong PP, nhưng có thể chứa thêm các phát biểu khác“. Tuân thủ chặt chẽ dự kiến dùng cho các yêu cầu nghiêm ngặt và đơn giản là chúng cần được giữ gìn triệt để.

3.1.68

Đánh giá ST (ST evaluation)

Đánh giá một ST theo các tiêu chí định sẵn.

3.1.69

Chủ thể (subject)

Một thực thể chủ động thuộc TOE thực thi các thao tác trên đối tượng.

3.1.70

Đích đánh giá (target of evaluation – TOE)

Một tập phần mềm, phần sụn và/hoặc phần cứng cùng với tài liệu hướng dẫn nếu có.

3.1.71

Tác nhân đe dọa (threat agent)

Thực thể có thể gây tác động không mong muốn vào tài sản.

3.1.72

Đánh giá TOE (TOE evaluation)

Đánh giá một TOE theo các tiêu chí định sẵn.

3.1.73

Tài nguyên TOE (TOE resource)

Những gì được dùng hoặc tiêu tốn trong TOE.

3.1.74

Chức năng an toàn của TOE (TSF-TOE security functionality)

Tính năng kết hợp tất cả phần cứng, phần mềm, và phần sụn của TOE mà dựa vào đó TOE mới thực thi được chính xác các SFR.

3.1.75

Theo dấu (trace, verb)

Thực hiện phân tích phù hợp một cách không hình thức giữa hai thực thể chỉ ở mức độ chính xác tối thiểu.

3.1.76

Vận chuyển bên ngoài TOE (transfers outside of the TOE)

Trung chuyển dữ liệu đến các thực thể ngoài tầm kiểm soát của TSF.

3.1.77

Chuyển đổi (translation)

Quá trình mô tả các yêu cầu an toàn sang một ngôn ngữ tiêu chuẩn.

CHÚ THÍCH: Khái niệm chuyển đổi trong ngữ cảnh này không có nghĩa dịch thuật và không ngầm chỉ rằng mọi SFR biểu diễn trong ngôn ngữ chuẩn có thể được dịch ngược lại thành các mục tiêu an toàn.

3.1.78

Kênh tin cậy (trusted channel)

Phương tiện qua đó một TSF và một sản phẩm CNTT tin cậy khác có thể liên lạc với nhau ở độ tin cậy cần thiết.

3.1.79

Sản phẩm CNTT tin cậy (trusted IT product)

Sản phẩm CNTT – không phải là TOE – mà các yêu cầu chức năng an toàn của nó kết hợp về mặt quản trị với TOE và được giả thiết là để thực thi các yêu cầu chức năng an toàn của nó một cách chuẩn xác.

CHÚ THÍCH: Ví dụ về một sản phẩm CNTT tin cậy có thể là một sản phẩm đã được đánh giá tách biệt khác.

3.1.80

Đường dẫn tin cậy (trusted path)

Phương tiện để một người dùng và TSF có thể truyền thông với nhau ở mức tin tưởng cần thiết.

3.1.81

Dữ liệu TSF (TSF data)

Dữ liệu cho việc hoạt động mà TOE dựa vào để thực thi các SFR.

3.1.82

Giao diện TSF (TSF interface)

Phương tiện để một thực thể bên ngoài (hoặc chủ thể thuộc TOE nhưng nằm ngoài TSF) cung cấp dữ liệu cho TSF, nhận dữ liệu từ TSF và thực thi các dịch vụ từ TSF.

3.1.83

Dữ liệu người dùng (user data)

Dữ liệu dùng cho người dùng và không ảnh hưởng đến hoạt động của TSF.

3.1.84

Thẩm tra (verify)

Soát xét kỹ ở mức chi tiết với việc xác định độc lập về tính đầy đủ.

CHÚ THÍCH: Xem khái niệm “Xác nhận” (ở 3.1.14). Khái niệm „thẩm tra“ có ý nghĩa chặt chẽ hơn. Nó được dùng trong ngữ cảnh các hành động của đánh giá viên, trong đó đòi hỏi sự nỗ lực độc lập của đánh giá viên.

3.2. Các thuật ngữ và định nghĩa liên quan đến lớp ADV

CHÚ THÍCH: Các khái niệm sau được dùng trong các yêu cầu đối với kiến trúc bên trong phần mềm. Một số khái niệm rút ra từ IEEE Std 610.12-1990 – Tập các khái niệm chuẩn trong công nghệ phần mềm của Viện Công nghệ Điện và Điện tử.

3.2.1

Người quản trị (administrator)

Thực thể có mức độ tin cậy tương ứng với mọi chính sách thực thi bởi TSF.

CHÚ THÍCH: Không phải tất cả PP hoặc ST giả định có cùng mức tin cậy cho người quản trị. Các nhà quản trị điển hình được coi là trung thành mọi lúc với các chính sách trong ST của TOE. Một số chính sách có thể liên quan đến chức năng của TOE, một số khác có thể liên quan đến môi trường vận hành.

3.2.2

Cây truy xuất (call tree)

Xác định các mô đun trong một hệ thống theo dạng biểu đồ, chỉ ra những mô đun nào gọi đến một mô đun khác.

CHÚ THÍCH: Vận dụng theo IEEE Std 610.12-1990.

3.2.3

Tính gắn kết (cohesion)

Cách thức và mức độ chặt chẽ của mô đun liên quan đến một mô đun khác của các tác vụ thực hiện bởi một mô đun phần mềm đơn lẻ. (Theo IEEE Std 610-12-1990).

CHÚ THÍCH: Các kiểu gắn kết gồm: kiểu trùng hợp, truyền thông, tính năng, logic, tuần tự và tạm thời. Các kiểu gắn kết này được mô tả bởi một khái niệm tương ứng nêu trên.

3.2.4

Gắn kết trùng hợp (coincidental cohesion)

Mô đun với các đặc trưng của việc thực hiện các hành động liên quan hoặc liên quan lỏng lẻo. (Theo IEEE Std 610-12-1990).

CHÚ THÍCH: Xem khái niệm 3.2.3 ở trên.

3.2.5

Gắn kết truyền thông (communicational cohesion)

Mô đun chứa các chức năng tạo ra kết xuất cho hoặc dùng kết xuất lấy từ các chức năng khác trong cùng mô đun.

(Theo IEEE Std 610-12-1990).

CHÚ THÍCH 1: Xem khái niệm 3.2.3 ở trên.

CHÚ THÍCH 2: Ví dụ về một mô đun gắn kết truyền thông là mô đun kiểm tra truy nhập, mô đun này chứa các hàm kiểm tra bắt buộc, tùy biến và kiểm tra năng lực.

3.2.6

Độ phức tạp (complexity)

Đại lượng đo mức độ khó hiểu của phần mềm, khó để phân tích, kiểm thử và duy trì nó.

(Theo IEEE Std 610-12-1990).

CHÚ THÍCH: Giảm độ phức tạp là đích chung của việc sử dụng phương pháp phân rã mô đun, phân lớp và tối giản hóa. Ghép điều khiển và gắn kết có vai trò quan trọng để đạt mục đích này.

Một nỗ lực trong lĩnh vực công nghệ phần mềm đã thể hiện trong việc cố gắng phát triển các thước đo để đo lường độ phức tạp của mã nguồn. Hầu hết các thước đo này sử dụng các đặc tính dễ tính toán của mã nguồn như số các biểu thức và toán hạng, độ phức tạp của đồ thị luồng điều khiển (độ phức tạp vòng lặp), số các dòng mã nguồn, tỷ lệ chú giải so với mã thực hiện, và các thước đo tương tự khác. Các chuẩn mã hóa cũng đã được tìm ra để có công cụ hữu ích trong việc tạo mã sao cho dễ hiểu hơn.

Họ nội bộ TSF (ADV_INT) gọi đến một hàm phân tích độ phức tạp trong mọi thành phần của chúng. Kết quả dự kiến là nhà phát triển sẽ đưa ra hỗ trợ cho các đòi hỏi về việc đã có giảm đáng kể trong độ phức tạp. Hỗ trợ này có thể gồm các chuẩn lập trình cho nhà phát triển, và một chỉ số về việc mọi mô đun thỏa mãn tiêu chuẩn (hoặc có một số ngoại lệ được biện minh bằng các luận cứ công nghệ phần mềm). Nó có thể chứa các kết quả của các bộ công cụ dùng để đo lượng một số tính chất của mã nguồn, hoặc có thể chứa hỗ trợ khác cho nhà phát triển cần đến.

3.2.7

Ghép nối (coupling)

Cách thức và mức độ của sự không liên thuộc giữa các mô đun phần mềm.

(Theo IEEE Std 610-12-1990).

CHÚ THÍCH: Các kiểu ghép nối gồm ghép nối truy xuất, ghép nối chung và ghép nối nội dung (xem bên dưới).

3.2.8

Ghép nối truy xuất (call coupling)

Quan hệ giữa hai mô đun trao đổi với nhau một cách chặt chẽ qua các lời gọi hàm chức năng được ghi lại tài liệu.

CHÚ THÍCH: Ví dụ về ghép nối truy xuất là dữ liệu, nhãn tem và điều khiển. (Xem phần tiếp theo).

3.2.9

Ghép nối truy xuất (call coupling)

(về dữ liệu). Quan hệ dữ liệu giữa hai mô đun trao đổi chặt chẽ với nhau thông qua việc sử dụng các tham số biểu diễn các biểu thức dữ liệu đơn lẻ.

CHÚ THÍCH: Xem ghép nối truy xuất (3.2.8)

3.2.10

Ghép nối truy xuất (call coupling)

(về nhãn tem). Quan hệ về nhãn tem giữa hai mô đun trao đổi với nhau thông qua việc sử dụng các tham số lời gọi có chứa nhiều trường hoặc có các cấu trúc bên trong có nghĩa.

CHÚ THÍCH: Xem ghép nối truy xuất (3.2.8)

3.2.11

Ghép nối truy xuất (call coupling)

(về điều khiển). Quan hệ về điều khiển giữa hai mô đun nếu một mô đun chuyển thông tin mà nó định gửi để gây ảnh hưởng đến logic bên trong của mô đun kia.

CHÚ THÍCH: Xem ghép nối truy xuất (3.2.8)

3.2.12

Ghép nối chung (common coupling)

Quan hệ giữa hai mô đun cùng chia sẻ một vùng dữ liệu chung hoặc một tài nguyên hệ thống chung khác.

CHÚ THÍCH: Các biến toàn cục chỉ ra rằng các mô đun sử dụng các biến toàn cục này là các ghép nối chung. Ghép nối chung thông qua các biến toàn cục nhìn chung được phép, song chỉ ở mức độ hạn chế.

Ví dụ: Các biến được đặt trong một vùng toàn cục, song chỉ dùng trong một mô đun, sẽ coi là đặt chỗ sai và cần phải hủy bỏ. Các yếu tố khác cần được xem xét khi đánh giá mức độ phù hợp của các biến toàn cục là:

– Số các mô đun có sửa đổi một biến toàn cục: Nói chung, chỉ một mô đun đơn nên được cấp cho trách nhiệm kiểm soát nội dung của một biến toàn cục. Tuy nhiên có thể có các tình huống trong đó một mô đun thứ hai có thể chia sẻ trách nhiệm này. Trong tình hướng đó, cần có sự biện minh thỏa đáng. Không thể chấp nhận được việc chia sẻ trách nhiệm trên cho nhiều hơn hai mô đun. (Để thực hiện đánh giá này, cần thận trọng khi xác định mô đun thực sự có trách nhiệm đối với nội dung của biến. Ví dụ, nếu có 1 trình đơn lẻ dùng để sửa đổi biến này, song trình này đơn giản chỉ thực hiện việc sửa đổi theo yêu cầu của mô đun gọi đến nó, thì mô đun này là mô đun chịu trách nhiệm và có thể có nhiều hơn một mô đun như vậy). Tiếp đó, về việc xác định độ phức tạp, nếu 2 mô đun có trách nhiệm đối với nội dung của biến toàn cục, cần có các chỉ số rõ ràng về mức độ phối hợp giữa các sửa đổi này.

– Số các mô đun có tham chiếu đến 1 biến toàn cục: Mặc dù nhìn chung không có hạn chế nào về số lượng các mô đun có tham chiếu đến 1 biến toàn cục, các trường hợp nhiều mô đun có tham chiếu tương tự sẽ cần được kiểm tra về tính hợp lệ và sự cần thiết.

3.2.13

Ghép nối nội dung (content coupling)

Quan hệ giữa hai mô đun trong đó một mô đun tạo tham chiếu trực tiếp đến nội dung bên trong của mô đun kia.

CHÚ THÍCH: Các ví dụ như: sửa đổi mã của – hoặc tham chiếu các nhãn nội bộ tới – mô đun khác. Kết quả là một số hoặc toàn bộ nội dung của một mô đun được ghép hiệu quả vào mô đun kia. Việc ghép nối nội dung có thể liên tưởng giống như việc sử dụng các giao diện mô đun không quảng cáo. Đây là cách đối lập với ghép nối truy xuất chỉ sử dụng các giao diện mô đun quảng cáo.

3.2.14

Phân cách miền (domain separation)

Đặc tính kiến trúc bảo an trong đó TSF định nghĩa các miền an toàn tách biệt cho mỗi người dùng và cho TSF và bảo đảm rằng không có một tiến trình người dùng nào có thể ảnh hưởng đến nội dung của một miền an toàn của người khác hoặc của TSF.

3.2.15

Gắn kết chức năng (functional cohesion)

Đặc tính của một mô đun để thực hiện các hành động liên quan đến một mục đích riêng.

(Theo IEEE Std 610-12-1990).

CHÚ THÍCH: Một mô đun gắn kết chức năng chuyển đổi một kiểu đơn của đầu vào thành một kiểu đơn đầu ra, ví dụ như một khối quản trị tác vụ hoặc quản trị hàng đợi (xem thêm tính gắn kết ở 3.2.3).

3.2.16

Tương tác (interaction)

Hoạt động dựa trên việc truyền thông chung giữa các thực thể.

3.2.17

Giao diện (interface)

Phương tiện tương tác với một thành phần hoặc một mô đun.

3.2.18

Phân lớp (layering)

Kỹ thuật thiết kế trong đó các nhóm mô đun tách biệt (các lớp) được tổ chức phân cấp để có trách nhiệm riêng biệt sao cho một lớp chỉ phụ thuộc vào dịch vụ các lớp bên dưới nó, và cung cấp dịch vụ chỉ cho các lớp trên nó.

CHÚ THÍCH: Phân lớp chặt chẽ bổ sung điều kiện là mỗi lớp chỉ nhận dịch vụ từ lớp ngay dưới nó và cung cấp dịch vụ chỉ cho lớp ngay trên nó.

3.2.19

Gắn kết logic, gắn kết thủ tục (logical cohesion, procedural cohesion)

Các đặc trưng của một mô đun thực hiện các động thái giống nhau trên các cấu trúc dữ liệu khác nhau.

CHÚ THÍCH: Một mô đun biểu thị gắn kết logic khi các chức năng của nó thực hiện các hành động liên quan – song khác biệt ở các đầu ra khác nhau (xem tính gắn kết ở 3.2.3).

3.2.20

Phân tách mô đun (modular decomposition)

Quá trình chia một hệ thống ra nhiều thành phần để thuận tiện cho thiết kế, phát triển và đánh giá. (Theo IEEE Std 610-12-1990).

3.2.21

Khả năng không đi vòng (non-bypassability)

(của TSF) là đặc tính kiến trúc an toàn trong đó mọi hành động liên quan đến SFR được đều được trung chuyển qua TSF.

3.2.22

Miền an toàn (security domain)

Tập hợp tài nguyên mà một thực thể chủ động có đặc quyền truy nhập đến.

3.2.23

Gắn kết tuần tự (sequential cohesion)

Mô đun chứa các chức năng mà kết xuất của mỗi chức năng này là đầu vào cho chức năng tiếp theo trong mô đun.

(Theo IEEE Std 610-12-1990).

CHÚ THÍCH: Một ví dụ về mô đun gắn kết tuần tự là mô đun có chứa các chức năng để ghi các bản ghi kiểm toán và để duy trì một bộ đếm động về số lượng tích lũy các vi phạm kiểm chứng của một kiểu đặc trưng.

3.2.24

Công nghệ phần mềm (software engineering)

Ứng dụng cách tiếp cận định lượng, có hệ thống, có nguyên tắc cho việc phát triển và bảo trì phần mềm, nghĩa là ứng dụng kỹ thuật cho phần mềm.

(Theo IEEE Std 610-12-1990).

CHÚ THÍCH: Như với thực tiễn công nghệ nói chung, cần có một vài suy xét trong khi áp dụng các nguyên tắc kỹ thuật. Nhiều yếu tố ảnh hưởng đến việc chọn lựa, không chỉ việc ứng dụng các thước đo về việc phân tách mô đun, phân lớp và tối giản. Ví dụ, một nhà phát triển có thể thiết kế một hệ thống với các ứng dụng tương lai theo ý tưởng chúng vẫn chưa được triển khai từ khởi điểm. Nhà phát triển có thể chọn đưa vào một vài logic để xử lý các ứng dụng tương lai này mà không cần phải triển khai chúng một cách hoàn thiện. Tiếp đó, nhà phát triển có thể đưa vào một số lời gọi đến các mô đun thực sự vẫn chưa triển khai này, song chỉ là các lời gọi cụt (không thực hiện gì và quay về luôn). Sự biện minh của nhà phát triển về những sai lệch so với các chương trình có kiến trúc hoàn hảo sẽ cần được đánh giá có suy xét, so với việc áp dụng nguyên tắc công nghệ phần mềm.

3.2.25

Gắn kết tạm thời (temporal cohesion)

Các đặc trưng của một mô đun có chứa các chức năng cần thiết để thực hiện tại cùng thời điểm.

CHÚ THÍCH 1: Dựa theo IEEE Std 610-12-1990.

CHÚ THÍCH 2: Các ví dụ về mô đun gắn kết tạm thời gồm các mô đun khởi tạo, khôi phục và ngừng hoạt động.

3.2.26

Tự bảo vệ TSF (TSF self-protection)

Đặc tính kiến trúc an toàn trong đó TSF không thể bị gián đoạn bởi các mã của TSF khác hoặc bởi các thực thể khác.

3.3. Các thuật ngữ và định nghĩa liên quan đến lớp AGD

3.3.1

Cài đặt (installation)

Thủ tục thực hiện bởi người dùng đưa TOE vào môi trường vận hành của nó và đưa nó vào trạng thái hoạt động.

CHÚ THÍCH: Hoạt động này thường chỉ thực hiện một lần, sau khi nhận được và chấp thuận TOE. Dự kiến TOE tiến hành theo cấu hình cho phép bởi ST. Nếu các quá trình tương tự cần được nhà phát triển thực hiện, chúng được biểu thị là “khởi tạo” trong suốt quá trình hỗ trợ vòng đời ALC. Nếu TOE yêu cầu khởi động ban đầu mà không cần nhắc lại định kỳ, quá trình này được phân loại là cài đặt.

3.3.2

Hoạt động (operation)

Giai đoạn sử dụng TOE gồm: “sử dụng bình thường”, quản trị và bảo dưỡng TOE sau khi chuyển giao và chuẩn bị.

3.3.3

Chuẩn bị (preparation)

Hoạt động trong giai đoạn vòng đời của một sản phẩm, bao gồm việc chấp thuận của khách hàng đối với TOE đã chuyển giao và cài đặt nó, có thể gồm cả những việc như khởi động, khởi tạo, thiết lập và tiến hành TOE đưa nó vào trạng thái sẵn sàng hoạt động.

3.4. Các thuật ngữ và định nghĩa liên quan đến lớp ALC

3.4.1

Các tiêu chí chấp thuận (acceptance criteria)

Các tiêu chí cần áp dụng khi thực hiện các thủ tục chấp thuận (ví dụ như soát xét thành công tài liệu, kiểm thử thành công về phần mềm, phần sụn hoặc phần cứng).

3.4.2

Các thủ tục chấp thuận (acceptance procedures)

Các thủ tục nối tiếp theo trình tự để chấp nhận các khoản mục cấu hình mới đã tạo lập hoặc đã sửa đổi cho TOE, hoặc để xóa bỏ chúng ở bước tiếp theo trong vòng đời.

CHÚ THÍCH: Các thủ tục này định dạng các vai trò hoặc trách nhiệm riêng đối với việc chấp thuận và các tiêu chí cần áp dụng để quyết định việc chấp thuận.

Có một số loại hình chấp thuận, một số có thể gối lên nhau, đó là:

a) Chấp thuận một khoản mục vào hệ thống quản lý cấu hình cho lần đầu, cụ thể gồm các thành phần phần mềm, phần sụn hay phần cứng từ các nhà sản xuất đưa vào TOE (“tích hợp”).

b) Tiến hành các khoản mục cấu hình trong giai đoạn tiếp theo của vòng đời tại mỗi tầng kiến thiết TOE (ví dụ mô đun, hệ thống con, kiểm soát chất lượng của TOE hoàn chỉnh).

c) Kế tiếp với việc chuyển tải các khoản mục cấu hình (ví dụ các phần của TOE hoặc các sản phẩm ban đầu) giữa các địa điểm phát triển khác nhau.

d) Kế tiếp với việc chuyển giao TOE tới người tiêu dùng.

3.4.3

Quản lý cấu hình (Configuration management – CM)

Nguyên tắc áp dụng chỉ đạo và giám sát về mặt kỹ thuật và quản lý để định dạng và tài liệu hóa các đặc tính chức năng và vật lý của một khoản mục cấu hình, kiểm soát những thay đổi về những đặc tính này, ghi nhận và báo cáo sự thay đổi trạng thái xử lý và triển khai, kiểm chứng sự tuân thủ theo các yêu cầu đặc trưng.

CHÚ THÍCH: Dựa theo IEEE Std 610-12-1990.

3.4.4

Tài liệu CM (CM documentation)

Tất cả tài liệu CM bao gồm đầu ra CM, danh sách CM (danh sách cấu hình), các bản ghi hệ thống CM, kế hoạch CM và tài liệu sử dụng CM.

3.4.5

Bằng chứng quản lý cấu hình (configuration management evidence)

Là mọi thứ có thể dùng để thiết lập sự tin cậy trong hoạt động đúng của hệ thống CM.

CHÚ THÍCH: Ví dụ, đầu ra CM, các sở cứ hợp lý cung cấp bởi nhà phát triển, các quan sát, các thí nghiệm hoặc các phỏng vấn tạo ra bởi đánh giá viên khi có mặt tại cơ sở.

3.4.6

Khoản mục cấu hình (configuration item)

Đối tượng quản lý bởi hệ thống CM trong quá trình phát triển TOE.

CHÚ THÍCH: Các khoản mục này có thể là các phần của TOE hoặc là các đối tượng liên quan đến việc phát triển TOE giống như các tài liệu đánh giá hoặc các công cụ phát triển. Các khoản mục CM có thể được lưu trữ trực tiếp trong hệ thống CM (ví dụ các tệp), hoặc qua tham chiếu (ví dụ các phần cứng) cùng với phiên bản của chúng.

3.4.7

Danh sách cấu hình (configuration list)

Tài liệu đầu ra quản lý cấu hình liệt kê mọi khoản mục cấu hình cho một sản phẩm đặc trưng cùng với phiên bản chính xác của mỗi khoản mục cấu hình tương ứng cho một phiên bản cụ thể của sản phẩm hoàn chỉnh.

CHÚ THÍCH: Danh sách này phân biệt phiên bản đã đánh giá của sản phẩm so với các phiên bản khác. Danh sách quản lý cấu hình là một tài liệu cụ thể cho một phiên bản cụ thể của một sản phẩm cụ thể. (Dĩ nhiên danh sách có thể là một tài liệu điện tử nằm trong một công cụ quản lý cấu hình. Trong trường hợp này, nó có thể coi là là một bản thuyết minh về hệ thống hoặc một phần của hệ thống hơn là phần kết xuất của hệ thống. Tuy nhiên, để sử dụng vào đánh giá, danh sách cấu hình có thể được chuyển giao như một phần của tài liệu đánh giá). Danh sách cấu hình định nghĩa các khoản mục thuộc các yêu cầu quản lý cấu hình của ALC_CMC.

3.4.8

Đầu ra quản lý cấu hình (configuration management output)

Các kết quả liên quan đến quản lý cấu hình, được tạo ra hoặc thực thi bởi hệ thống quản lý cấu hình.

CHÚ THÍCH: Các kết quả liên quan đến quản lý cấu hình này có thể là các tài liệu (ví dụ như các mẫu giấy tờ, các bản ghi hệ thống quản lý cấu hình, dữ liệu ghi nhật ký, các bản giấy sao chụp, dữ liệu kết xuất điện tử) cũng như các hành động (ví dụ các phép đo thủ công để thực hiện các lệnh quản lý cấu hình). Ví dụ về các đầu ra quản lý cấu hình như các danh sách cấu hình, các kế hoạch quản lý cấu hình, và/hoặc các hành vi trong vòng đời sản phẩm.

3.4.9

Kế hoạch quản lý cấu hình (configuration management plan)

Mô tả về việc hệ thống quản lý cấu hình được sử dụng cho TOE như thế nào.

CHÚ THÍCH: Mục tiêu của việc đưa ra một kế hoạch quản lý cấu hình là các nhân viên có thể thấy rõ họ cần làm gì. Từ quan điểm của hệ thống quản lý cấu hình nói chung, kế hoạch này có thể coi như một tài liệu kết xuất (vì nó có thể tạo ra như một phần ứng dụng của hệ thống quản lý cấu hình). Từ quan điểm của một dự án cụ thể, nó là một tài liệu sử dụng vi các thành viên của dự án sử dụng nó để hiểu được các bước cần thực hiện trong dự án. Kế hoạch quản lý cấu hình định nghĩa việc sử dụng hệ thống đối với một sản phẩm cụ thể; hệ thống này có thể mở rộng để dùng cho các sản phẩm khác. Nghĩa là kế hoạch quản lý cấu hình định nghĩa và mô tả đầu ra của một hệ thống quản lý cấu hình cho một công ty sử dụng trong quá trình phát triển TOE.

3.4.10

Hệ thống quản lý cấu hình (configuration management system)

Tập các thủ tục và công cụ (bao gồm cả tài liệu của chúng) dùng bởi nhà phát triển để phát triển và bảo trì các cấu hình cho sản phẩm của họ trong vòng đời sản phẩm.

CHÚ THÍCH: Các hệ thống quản lý cấu hình có thể khác nhau về mức độ chặt chẽ và chức năng, ở các mức cao, các hệ thống quản lý cấu hình có thể tự động hóa, với việc sửa chữa khiếm khuyết, kiểm soát thay đổi, và các cơ chế theo dấu khác.

3.4.11

Các bản ghi hệ thống quản lý cấu hình (configuration management system records)

Kết xuất tạo ra trong quá trình hoạt động của hệ thống quản lý cấu hình được tài liệu hóa, ghi lại các động thái quản lý cấu hình.

CHÚ THÍCH: Các ví dụ về bản ghi hệ thống quản lý cấu hình là các khuôn dạng điều khiển thay đổi khoản mục trong quản lý cấu hình hoặc các khuôn dạng phê duyệt truy nhập vào khoản mục quản lý cấu hình.

3.4.12

Các công cụ quản lý cấu hình (configuration management tools)

Các công cụ hoạt động thủ công hoặc tự động nhằm thực hiện hoặc hỗ trợ một hệ thống quản lý cấu hình

CHÚ THÍCH: Ví dụ các công cụ cho quản lý phiên bản cho các phần của TOE.

3.4.13

Tài liệu sử dụng quản lý cấu hình (configuration management usage documentation)

Phần của hệ thống quản lý cấu hình dùng để mô tả hệ thống quản lý cấu hình được định nghĩa và áp dụng như thế nào. Ví dụ, các sổ tay, các quy định và/hoặc tài liệu về các công cụ và các thủ tục.

3.4.14

Chuyển giao (delivery)

Vận chuyển một TOE hoàn chỉnh từ môi trường sản xuất tới tay khách hàng.

CHÚ THÍCH: Giai đoạn vòng đời sản phẩm này bao gồm cả việc đóng gói và lưu trữ tại địa điểm phát triển, song không bao gồm việc vận chuyển TOE chưa hoàn chỉnh hoặc các phần của TOE giữa các nhà phát triển hoặc giữa các địa điểm phát triển khác nhau.

3.4.15

Nhà phát triển (developer)

Tổ chức có trách nhiệm với việc phát triển TOE.

3.4.16

Phát triển (development)

Giai đoạn trong vòng đời sản phẩm liên quan đến việc biểu thị sự triển khai TOE.

CHÚ THÍCH: Trong mọi yêu cầu ALC, khái niệm phát triển và các khái niệm liên quan (nhà phát triển, phát triển) có ý nghĩa chung bao hàm cả việc phát triển và sản xuất.

3.4.17

Các công cụ phát triển (development tools)

Các công cụ (bao gồm phần mềm kiểm thử nếu có) hỗ trợ việc phát triển và sản xuất TOE.

CHÚ THÍCH: Ví dụ cho một TOE phần mềm, các công cụ phát triển thường là các ngôn ngữ lập trình, các trình biên dịch, các trình liên kết và các công cụ tạo lập.

3.4.18

Mô tả triển khai (implementation representation)

Mô tả trừu tượng tối thiểu cho một TSF, đặc trưng cho việc tạo ra TSF mà không cần bổ sung chi tiết thiết kế nào thêm.

CHÚ THÍCH: Mã nguồn được biên dịch hoặc bản vẽ phần cứng dùng để tạo ra phần cứng cụ thể là các ví dụ về các thành phần của một bản mô tả triển khai.

3.4.19

Vòng đời (life-cycle)

Chuỗi các giai đoạn tồn tại của một đối tượng (ví dụ một sàn phẩm hoặc một hệ thống) theo thời gian.

3.4.20

Định nghĩa vòng đời (life-cycle definition)

Định nghĩa cho một mô hình vòng đời.

3.4.21

Mô hình vòng đời (life-cycle model)

Mô tả các giai đoạn và mối quan hệ của chúng với các giai đoạn khác dùng cho việc quản lý vòng đời của một đối tượng nào đó, chỉ ra chuỗi các giai đoạn và các đặc tính mức cao của các giai đoạn cần phải như thế nào.

CHÚ THÍCH: Xem Hình 1.

3.4.22

Sản xuất (production)

Giai đoạn vòng đời sản xuất kế tiếp giai đoạn phát triển và bao gồm việc chuyển tải bản mô tả triển khai vào việc triển khai cụ thể cho TOE, nghĩa là đưa nó vào trạng thái chấp nhận được để chuyển giao cho khách hàng.

CHÚ THÍCH 1: Giai đoạn này gồm sản xuất, tích hợp, tạo lập, vận chuyển nội bộ, lưu trữ và ghi nhãn cho TOE.

CHÚ THÍCH 2: Xem thêm Hình 1.

Hình 1 – Các khái niệm trong CM và vòng đời sản phẩm

3.5. Các thuật ngữ và định nghĩa liên quan đến lớp AVA

3.5.1

Kênh bất hợp pháp (covert channel)

Kênh tín hiệu cưỡng ép trái phép, cho phép một người dùng lén lút vi phạm chính sách riêng biệt đa cấp và vi phạm các yêu cầu không quan sát được của TOE.

3.5.2

Các điểm yếu tiềm ẩn phải đối mặt (encountered potential vulnerabilities)

Các yếu điểm tiềm ẩn trong TOE có thể dùng để vi phạm các SFR được đánh giá viên nhận dạng trong khi thực hiện các hoạt động đánh giá.

3.5.3

Các điểm yếu có thể khai thác (exploitable vulnerability)

Các yếu điểm trong TOE có thể dùng để vi phạm các SFR trong môi trường vận hành của TOE.

3.5.4

Các tấn công giám sát (monitoring attacks)

Phân loại chung của các phương pháp tấn công có sử dụng các kỹ thuật phân tích thụ động nhằm phơi bày dữ liệu nhạy cảm bên trong TOE khi TOE hoạt động theo theo mô tả của các tài liệu hướng dẫn.

3.5.5

Các điểm yếu tiềm ẩn (potential vulnerability)

Các yếu điểm nghi vấn song chưa được khẳng định.

3.5.6

Các điểm yếu còn tồn tại (residual vulnerability)

Các yếu điểm không thể khai thác được trong môi trường vận hành của TOE, song một tin tặc có thể dùng để vi phạm các SFR với tiềm năng tấn công lớn hơn dự đoán trong môi trường vận hành của TOE.

3.5.7

Điểm yếu (vulnerability)

Yếu điểm trong TOE có thể dùng để vi phạm các SFR trong một số môi trường.

3.6. Các thuật ngữ và định nghĩa liên quan đến lớp ACO

3.6.1

Thành phần cơ sở (base component)

Thực thể trong một TOE tổng hợp, bản thân nó là chủ thể của một đánh giá, cung cấp dịch vụ và tài nguyên cho một thành phần phụ thuộc.

3.6.2

Tương thích (compatible)

(Thành phần) Là đặc tính của một thành phần về khả năng cung cấp các dịch vụ đòi hỏi bởi một thành phần khác, thông qua các giao diện phù hợp của mỗi thành phần trong môi trường vận hành nhất quán.

3.6.3

TOE thành phần (component TOE)

TOE đã được đánh giá thành công và là một phần của một TOE tổng hợp khác.

3.6.4

TOE tổng hợp (composed TOE)

TOE bao gồm hai hoặc nhiều thành phần đã được đánh giá thành công trước đó.

3.6.5

Thành phần phụ thuộc (dependent component)

Thực thể trong một TOE tổng hợp, bản thân nó là cơ quan của một đánh giá, dựa trên việc cung cấp dịch vụ bởi một thành phần cơ sở.

3.6.6

Giao diện chức năng (functional interface)

Giao diện với bên ngoài cung cấp cho người dùng khả năng truy xuất đến chức năng của một TOE không trực tiếp liên quan đến việc thực thi các yêu cầu chức năng an toàn.

CHÚ THÍCH: Trong một TOE tổng hợp có các giao diện cung cấp bởi thành phần cơ sở, được đòi hỏi bởi thành phần phụ thuộc để hỗ trợ hoạt động của TOE tổng hợp.