Lời nói đầu
\r\n\r\nTCVN 8709-1:2011 hoàn\r\ntoàn tương đương ISO/IEC 15408-1:2008
\r\n\r\nTCVN 8709-1:2011 do\r\nTrung tâm Ứng cứu khẩn cấp máy tính Việt Nam biên\r\nsoạn, Bộ Thông tin và Truyền thông đề nghị, Tổng cục Tiêu chuẩn Đo lường Chất\r\nlượng thẩm định, Bộ Khoa học và Công nghệ công bố. .
\r\n\r\nLời giới thiệu
\r\n\r\nTiêu chuẩn này cho\r\nphép thực hiện so sánh các kết quả đánh\r\ngiá 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\r\nan 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\r\ná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\r\nCNTT này có thể dưới dạng phần cứng, phần sụn hay phần mềm.
\r\n\r\nQuy tr
TCVN 8709 là một chỉ\r\ndẫ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\r\nnăng an toàn.
\r\n\r\nTCVN 8709 có tính mềm\r\ndẻ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\r\nđa dạng sản phẩm CNTT. Chính vì vậy, người dùng tiêu chuẩn này cầ
Do vậy, thực tế là một\r\nsản phẩm CNTT đã được đánh giá chỉ có ý nghĩa trong phạm vi ngữ cảnh các đặc\r\ntính an toàn được đánh giá với các phương pháp đán
TCVN 8709 đề cập đến\r\nviệ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\r\nmá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\r\ntươ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ể\r\ná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\r\nphá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\r\nro không do con người tạo ra. Ngoài an toàn CNTT, TCVN 8709 có thể áp dụng cho\r\ncá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\r\nđó.
\r\n\r\nMột số chủ đề do liên\r\nquan đế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ẽ\r\nđược coi là nằm ngoài phạm vi TCVN 8709. Một số chủ đề trong số đó như sau:
\r\n\r\na) TCVN\r\n8709 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\r\nquả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\r\nthừ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\r\ncá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\r\nsoát.
\r\n\r\nb) Đánh\r\ngiá 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ỉ\r\nthông tin qua điện từ trường không được đề cập riêng biệt, mặc dù nhiều khái
c) TCVN\r\n8709 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.\r\nHệ phương pháp này được nêu trong ISO/IEC 18045.
\r\n\r\nd) TCVN\r\n8709 không đề cập đến bộ khung pháp lý và quản lý mà các tiêu ch
e) Các\r\nthủ 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.\r\nCô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\r\nCNTT (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\r\ntấ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\r\nquy 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\r\nđá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\r\ntoàn CNTT, việc công nhận cần xem xét riêng các khía cạnh này.
\r\n\r\nf) Chủ\r\nđề tiêu chí đánh giá cho chất lượng vốn có của các thuật toán mã h
Các\r\nthuật ngữ ISO, như “có khả năng”, “tham khảo“,“có thể”, “bắt buộc”, “cần” và “nên”\r\nsử dụng xuyên suốt trong văn bản tiêu chuẩn được định nghĩa trong Các chỉ thị\r\nISO/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\r\nchuẩn này. Xem lưu ý dưới đây. Định nghĩa sau đây quy định việc sử dụng từ\r\n“nên” trong TCVN 8709.
\r\n\r\nNên
\r\n\r\nTrong văn bản quy chuẩn,\r\ntừ “nên” dùng để biểu thị “trong một số khả năng, có một khả năng được khuyến\r\nnghị 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\r\nkhá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\r\nbuộc” (ISO/IEC Directives, Part 2).
\r\n\r\nCHÚ TH
\r\n\r\n
Tiêu chuẩn này thiết\r\nlập các khái niệm và nguyên lý chung cho đánh giá an toàn CNTT và đặc tả mô\r\nhì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\r\ndiện, được sử dụng làm cơ sở cho đánh giá các thuộc\r\ntính an toàn của các sản phẩm CNTT.
\r\n\r\nTiêu chuẩn này trình\r\nbà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\r\nnghĩ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\r\ncủ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\r\nđánh giá; mô tả đối tượng độc giả mà các tiêu chí đánh giá hướng đến. Tiêu chu
Tiêu chuẩn định nghĩa\r\ncác thao tác làm cơ sở để đưa ra các thành phần chức năng trong TCVN 8709
Các khái niệm cơ bản\r\nvề 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\r\nnê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\r\ntiê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\r\nmô 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ề\r\nphương pháp luận đánh giá và phạm vi các lược đồ đánh giá được đưa ra trong\r\nISO/IEC 18045.
\r\n\r\n\r\n\r\nTài liệu viện dẫn sau\r\nđây không thể thiếu được khi áp dụng tài liệu tiêu chuẩn này:
\r\n\r\nTCVN 8709-2, “Công\r\nnghệ thông tin - Các kỹ thuật an toàn - Các tiêu chí đánh giá an toàn CNTT - Phần\r\n2: Các thành phần chức năng an toàn".
\r\n\r\nTCVN 8709 - 3, “Công\r\nnghệ thông tin - Các kỹ thuật an toàn - Các tiêu chí đánh giá an toàn CNTT - Phần\r\n3: Các thành phần đảm bảo an toàn".
\r\n\r\nISO/IEC 18045, “Công\r\nnghệ thông tin - Các kỹ thuật an toàn - Hệ phương pháp cho đánh giá an toàn\r\nCNTT” (ISO/IEC 18045, “In
Tiêu chuẩn này sử dụng\r\ncác thuật ngữ và định nghĩa sau đây.
\r\n\r\nCHÚ TH
3.1.1
\r\n\r\nCác hành động có hại\r\n(adverse actions)
\r\n\r\nCác hành động thực hiện\r\nbởi một tác nhân đe dọa vào một tài sản.
\r\n\r\n3.1.2
\r\n\r\nTài sản
Các thực thể mà chủ sở\r\nhữu TOE đặt giá trị vào đó.
\r\n\r\n3.1.3
\r\n\r\nChỉ định
Định r
3.1.4.
\r\n\r\nBảo đảm
Cơ s
3.1.5
\r\n\r\nKhả năng t
Ước lượng về khả năng\r\ntấ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\r\ncông.
\r\n\r\n3.1.6
\r\n\r\nGia tăng
Việc thêm một hoặc\r\nnhiều yêu cầu vào một gói.
\r\n\r\n3.1.7
\r\n\r\nDữ liệu xác thực
Thông tin được dùng để\r\nxác minh định danh đã tuyên bố của một người dùng.
\r\n\r\n3.1.8
\r\n\r\nNgười dùng có thẩm\r\nquyền (authorised user)
\r\n\r\nNgười dùng có thể thực\r\nthi một thao tác tương ứng với các SFR.
\r\n\r\n3.1.9
\r\n\r\nLớp
Tập các họ TCVN 8709\r\ncùng chia sẻ một mục tiêu chung.
\r\n\r\n3.1.10
\r\n\r\nTính mạch lạc
Sắp sếp thứ tự logic,\r\ncó nghĩa rõ ràng.
\r\n\r\nCHÚ THÍCH: Đối với\r\ntà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ị\r\nviệc độc giả có hiểu được văn bản đó hay\r\nkhông.
\r\n\r\n3.1.11
\r\n\r\nTính hoàn thiện
Tính chất thể hiện rằng\r\ntất cả các thành phần cần thiết của một thực thể đều được cung cấp.
\r\n\r\nCHÚ TH
3.1.12
\r\n\r\nThành phần
Tập nhỏ nhất lựa chọn\r\nđược của các phần tử mà các yêu cầu có thể dựa vào.
\r\n\r\n3.1.13
\r\n\r\nGói đảm bảo tổng hợp
Gói đảm bảo này gồm\r\ncá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\r\ncấp độ đảm bảo tổng hợp đã định nghĩa trước trong TCVN 8709.
\r\n\r\n3.1.14
\r\n\r\nXác nhận
Công bố một việc đã\r\nđược soát xét chi tiết với việc xác định\r\ntính đầy đủ một cách độc lập.
\r\n\r\nCHÚ THÍCH: Mức độ ch
3.1.15.
\r\n\r\nTính kết nối
Đặc tính của TOE cho\r\nphép tương tác với các thực thể CNTT bên ngoài TOE.
\r\n\r\nCHÚ THÍCH: đặc tính này\r\nbao 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\r\nkhoảng cách bất kỳ trong một môi trường hoặc cấu hình bất kỳ.
\r\n\r\n3.1.16
\r\n\r\nTính nhất quán
Mối quan hệ giữa hai\r\nhoặc nhiều thực thể trong đó không có sự đối lập rõ rệt nào giữa chúng.
\r\n\r\n3.1.17
\r\n\r\nChổng đỡ
Đối đầu với một tấn\r\ncô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ừ
\r\n\r\n3.1.18
\r\n\r\nTính tuân thủ diễn giải\r\nđược (demonstrable conformance)
\r\n\r\nMối quan hệ giữa một\r\nST và một PP, trong đó ST cung cấp một giải pháp để giải quyết vấn đề an toàn\r\nchung nêu trong PP.
\r\n\r\nCHÚ THÍCH: PP và ST\r\ncó thể chứa các phát biểu khác nhau hoàn toàn\r\nmô tả về các thực thể, khái niệm,...\r\nkhá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\r\ntại một số PP tương tự nhau, vì thế cho phép tác giả\r\nST tuyên bố tuân thủ đồng thời theo các PP này\r\nđể giúp tiết kiệm thời gian.
\r\n\r\n3.1.19
\r\n\r\nSự chứng minh
Đưa ra một kết luận\r\nrút ra từ việc phân tích, tuy có kém chặt chẽ hơn một “bằng ch
3.1.20
\r\n\r\nTính phụ thuộc
Mối quan hệ giữa các\r\nthà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
3.1.21
\r\n\r\nMô tả
Cung cấp các chi tiết\r\nđặc trưng của một thực thể.
\r\n\r\n3.1.22.
\r\n\r\nXác định
Khẳng định một kết luận\r\nriê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ụ\r\nthể.
\r\n\r\nCHÚ THÍCH: Việc sử dụng\r\nkhá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\r\nphân tích trước đó. So sánh với các khái niệm “xác\r\nnhậ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\r\nsoát xét lại.
\r\n\r\n3.1.23
\r\n\r\nMôi trường phát triển
Môi trường để phát\r\ntriển TOE.
\r\n\r\n3.1.24
\r\n\r\nPhần tử
Phát biểu cơ bản nhất\r\nvề một yêu cầu an toàn.
\r\n\r\n3.1.25
\r\n\r\nBảo đảm
Sự bảo đảm về mối\r\nquan hệ nhân quả chắc chắn giữa một hành động và các hệ quả của nó.
\r\n\r\nCHÚ TH
3.1.26
\r\n\r\nĐánh giá
Đá
3.1.27
\r\n\r\nMức bảo đảm đánh giá
Tập các yêu cầu đảm bảo\r\nrú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\r\ntrước trong TCVN 8709, tạo thành một gói đảm bảo.
\r\n\r\n3.1.28
\r\n\r\nCơ quan đánh giá
Cơ quan thiết lập\r\ntiê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ị\r\ntrong một cộng đồng cụ thể và là đơn vị thực thi TCVN 8709 cho cộng đồng thông\r\nqua một lược đồ đánh giá.
\r\n\r\n3.1.29
\r\n\r\nLược đồ đánh giá
Bộ khung quản lý và\r\nquy định về việc áp dụng TCVN 8709 cho một cơ quan đánh giá trong một cộng đồng\r\ncụ thể.
\r\n\r\n3.1.30
\r\n\r\nThấu đáo
Đặc trưng của một\r\nphươ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\r\ntheo một kế hoạch rõ ràng.
\r\n\r\nCHÚ TH
3.1.31
\r\n\r\nGiải thích
Đưa ra luận cứ về lý\r\ndo thực hiện một hành động.
\r\n\r\n3.1.32
\r\n\r\nMở rộng
Bổ sung thêm vào một\r\nST hoặc PP các yêu cầu chức năng không chứa trong\r\nTCVN 8709-2 và/hoặc các yêu cầu đảm bảo không chứa trong TCVN 8709-3.
\r\n\r\n3.1.33
\r\n\r\nThực thể bên ngoài
Một người dùng hay\r\nthiết bị CNTT có thể tương tác với TOE từ bên ngoài ranh giới TOE.
\r\n\r\nCHÚ TH
3.1.34
\r\n\r\nHọ
Một nhóm các thành phần\r\ncù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\r\nchặt chẽ.
\r\n\r\n3.1.35
\r\n\r\nHình thức
Cách biểu thị bằng một\r\nngô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\r\nđược thiết lập rõ ràng.
\r\n\r\n3.1.36
\r\n\r\nTài liệu hướng dẫn
Tài liệu mô tả về việc\r\nvận chuyển, chuẩn bị, vận hành, quản lý và/hoặc sử dụng cho TOE.
\r\n\r\n3.1.37
\r\n\r\nĐịnh danh
Việc biểu diễn các thực\r\nthể (chẳng hạn như người dùng, tiến trình hoặc ổ đĩa) xác đị
CH
3.1.38
\r\n\r\nKhông hình thức
Cách diễn tả bằng\r\nngôn ngữ tự nhiên.
\r\n\r\n3.1.39
\r\n\r\nVận chuyển giữa các\r\nTSF (inter TSF transfers)
\r\n\r\nTrao đổi dữ liệu giữa\r\nTOE với chức năng an toàn của các sản phẩm CNTT tin cậy khác.
\r\n\r\n3.1.40
\r\n\r\nKênh truyền thông nội\r\nbộ (internal communication channel)
\r\n\r\nKênh truyền thông giữa\r\ncác phần tách biệt của TOE.
\r\n\r\n3.1.41
\r\n\r\nVận chuyển nội bộ TOE
Trao đổi dữ liệu giữa\r\ncác phần tách biệt của TOE.
\r\n\r\n3.1.42
\r\n\r\nTính nh
Là không có đối lập\r\nrõ nét nào trong mọi khía cạnh của một thực thể.
\r\n\r\nCH
3.1.43
\r\n\r\nPhép lặp
Là việc sử dụng lặp lại\r\nmột thành phần để thể hiện hai hoặc nhiều yêu cầu riêng biệt.
\r\n\r\n3.1.44.
\r\n\r\nBiện minh
Là việc phân tích để\r\nđi đến một kết luận.
\r\n\r\nCHÚ THÍCH: Khái niệm\r\n“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
3.1.45
\r\n\r\nĐối tượng
Thực thể thụ động\r\ntrong TOE có chứa hoặc tiếp nhận thông tin, mà dựa vào\r\nđó các chủ thể thực thi các hoạt động.
\r\n\r\n3.1.46
\r\n\r\nHoạt động
(đối với một thành phần\r\ncủa TCVN 8709) là sự sửa đổi hoặc lặp lại một thành phần.
\r\n\r\nCHÚ TH
3.1.47
\r\n\r\nHoạt động
(đối với một đối tượng)\r\nlà kiểu đặc trưng của một hành động do một chủ thể thực hiện tr
3.1.48
\r\n\r\nMôi trường vận hành
Môi trường trong đó\r\nTOE hoạt động.
\r\n\r\n3.1.49
\r\n\r\nChính sách an toàn của\r\ntổ chức (organizational security policy)
\r\n\r\nTập các quy tắc, thủ\r\ntục, hoặc hướng dẫn an toàn cho một tổ chức.
\r\n\r\nCHÚ THÍCH: Một chính\r\nsách có thể chỉ áp dụng cho một môi trường vận hành cụ thể.
\r\n\r\n3.1.50
\r\n\r\nGói
Tập được đặt tên của\r\ncác yêu cầu chức năng an toàn hoặc đảm bảo an toàn.
\r\n\r\nCHÚ THÍCH: Một ví dụ\r\nvề gói là “EAL 3".
\r\n\r\n3.1.51
\r\n\r\nĐánh giá Hồ sơ bảo vệ
Đánh giá một PP theo\r\ncác tiêu chí định sẵn.
\r\n\r\n3.1.52
\r\n\r\nH
Phát biểu độc lập về\r\nmặt thực thi các yêu cầu cho một kiểu TOE.
\r\n\r\n3.1.53
\r\n\r\nChứng minh
Chỉ ra sự phù hợp bằng\r\nviệc phân tích hình thức theo cách tiếp cận toán học.
\r\n\r\nCHÚ TH
3.1.54
\r\n\r\nTinh chỉnh
B
3.1.55
\r\n\r\nVai trò
Một tập các quy tắc\r\nxá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.
\r\n\r\n3.1.56
\r\n\r\nBí mật
Là thông tin chỉ được\r\nngười có thẩm quyền và / hoặc TSF biết để thực thi một SFP cụ\r\nthể.
\r\n\r\n3.1.57
\r\n\r\nTrạng thái an toàn
Trạng thái mà dữ liệu\r\nTSF là nhất quán và TSF tiếp tục thực thi chuẩn xác các SFR.
\r\n\r\n3.1.58
\r\n\r\nThuộc tính an toàn
Các đặc tính của các\r\nchủ thể, người dùng (bao gồm các sản phẩm CNTT bên ngoài), đối tượng, thông\r\ntin, 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à\r\ncác giá trị của chúng được dùng trong thực thi các SFR.
\r\n\r\n3.1.59
\r\n\r\nChính sách chức năng\r\nan toàn (security function polic
Tập các quy tắc mô tả\r\nhà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\r\nSFR.
\r\n\r\n3.1.60
\r\n\r\nMục tiêu an toàn
Phát biểu về hướng đối\r\nphó 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\r\nxác định của tổ chức cũng như hướng thỏa mãn các giả định.
\r\n\r\n3.1.61
\r\n\r\nVấn đề an toàn
Phát biểu dạng hình\r\nthức định nghĩa bản chất và phạm vi an toàn mà TOE chủ ý đề cập đến.
\r\n\r\nCHÚ THÍCH: Phát biểu\r\nlà sự kết hợp của:
\r\n\r\n- Các\r\nmối đe dọa mà TOE cần chống trả,
\r\n\r\n- Các\r\nOSP được thực thi bởi TOE, và
\r\n\r\n- Các\r\ngiả định đặt ra cho TOE và môi trường vận hành của n
3.1.62
\r\n\r\nYêu cầu an toàn
Yêu cầu được phát biểu\r\ntrong ngôn ngữ tiêu chuẩn, dùng để đạt được các mục tiêu an toàn cho một TOE.
\r\n\r\n3.1.63
\r\n\r\nĐích an toàn
Phát biểu phụ thuộc\r\nthực thi về các yêu cầu cần thiết của một TOE xác định.
\r\n\r\n3.1.64
\r\n\r\nLựa chọn
Việc định rõ một hoặc\r\nnhiều khoản mục từ một danh sách trong một thành phần.
\r\n\r\n3.1.65
\r\n\r\nBán hình thức
Biểu thị bằng một\r\nngôn ngữ cú pháp hạn chế với ngữ nghĩa xác định trước.
\r\n\r\n3.1.66
\r\n\r\nĐặc tả
Là đưa ra chi tiết đặc\r\ntrưng về một thực thể theo một cách chính xác và chặt chẽ.
\r\n\r\n3.1.67
\r\n\r\nTuân thủ chặt chẽ
Mối quan hệ có thứ bậc\r\ngiữa một PP và một ST trong đó mọi yêu cầu có trong
CHÚ THÍCH: Mối quan hệ\r\nnày có thể được xác định như „ST sẽ chứa tất cả các phát biể
3.1.68
\r\n\r\nĐánh giá ST
Đánh giá một ST theo\r\ncác tiêu chí định sẵn.
\r\n\r\n3.1.69
\r\n\r\nChủ th
Một thực thể chủ động\r\nthuộc TOE thực thi các thao tác trên đối tượng.
\r\n\r\n3.1.70
\r\n\r\nĐích đánh giá
Một tập phầ
3.1.71
\r\n\r\nTác nhân đe dọa
Thực thể có thể gây\r\ntác động không mong muốn vào tài sản.
\r\n\r\n3.1.72
\r\n\r\nĐánh giá TOE
Đánh giá một TOE theo\r\ncác tiêu chí định sẵn.
\r\n\r\n3.1.73
\r\n\r\nTài nguyên TOE
Những gì được dùng hoặc\r\ntiêu tốn trong TOE.
\r\n\r\n3.1.74
\r\n\r\nChức năng an toàn của\r\nTOE (TSF-TOE security functionality)
\r\n\r\nTính năng kết hợp tất\r\ncả 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\r\nchính xác các SFR.
\r\n\r\n3.1.75
\r\n\r\nTheo dấu
Thực hiện phân tích\r\nphù 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\r\nthiểu.
\r\n\r\n3.1.76
\r\n\r\nVận chuyển bên ngoài\r\nTOE (transfers outside of the TOE)
\r\n\r\nTrung chuyển dữ liệu\r\nđến các thực thể ngoài tầm kiểm soát của TSF.
\r\n\r\n3.1.77
\r\n\r\nChuyển đổi
Quá trì
CHÚ TH
3.1.78
\r\n\r\nKê
Phương tiện qua đó một\r\nTSF 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\r\nthiết.
\r\n\r\n3.1.79
\r\n\r\nSản phẩm CNTT tin cậy
Sản phẩm CNTT - không\r\nphả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\r\nTOE 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\r\ncách chuẩn xác.
\r\n\r\nCHÚ TH
3.1.80
\r\n\r\nĐường dẫn tin cậy
Phương tiện để một\r\nngười dùng và TSF có thể truyền thông với nhau ở mức tin tưởng cần thiết.
\r\n\r\n3.1.81
\r\n\r\nDữ liệu TSF
Dữ liệu cho việc hoạt\r\nđộng mà TOE dựa vào để thực thi các SFR.
\r\n\r\n3.1.82
\r\n\r\nGiao diện TSF
Phương tiện để một thực\r\nthể 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\r\nTSF, nhận dữ liệu từ TSF và thực thi các dịch vụ từ TSF.
\r\n\r\n3.1.83
\r\n\r\nDữ liệu người dùng
Dữ liệu dùng cho người\r\ndùng và không ảnh hưởng đến hoạt động của TSF.
\r\n\r\n3.1.84
\r\n\r\nThẩm tra
Soát xét kỹ ở mức chi\r\ntiết với việc xác định độc lập về tính đầy đủ.
\r\n\r\nCHÚ THÍCH: Xem khá
CHÚ THÍCH: Các khái\r\nniệ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\r\nsố khái niệm rút ra từ IEEE Std 610.12-1990 - Tập\r\ncá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ử.
\r\n\r\n3.2.1
\r\n\r\nNgười quản trị
Thực thể có mức độ\r\ntin cậy tương ứng với mọi chính sách thực thi bởi TSF.
\r\n\r\nCH
3.2.2
\r\n\r\nCây truy xuất
Xác định các mô đun\r\ntrong một hệ thống theo dạng biểu đồ, chỉ ra những mô đun nào gọi đến một mô\r\nđun khác.
\r\n\r\nCHÚ THÍCH: Vận dụng\r\ntheo IEEE Std 610.12-1990.
\r\n\r\n3.2.3
\r\n\r\nTính gắn kết
Cách thức và mức độ\r\nchặ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
CHÚ TH
3.2.4
\r\n\r\nGắn kết trùng hợp
Mô đun với các đặc\r\ntrư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\r\nIEEE Std 610-12-1990).
\r\n\r\nCH
3.2.5
\r\n\r\nGắn kết truyền thông
Mô đun chứa các chức\r\nnă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\r\ncùng mô đun.
\r\n\r\n(Theo IEEE
CHÚ THÍCH 1: Xem khái\r\nniệm 3.2.3 ở trên.
\r\n\r\nCHÚ TH
3.2.6
\r\n\r\nĐộ phức tạp
Đại lượng đo mức độ\r\nkhó hiểu của phần mềm, khó để phân tích, kiểm\r\nthử và duy trì nó.
\r\n\r\n(Theo IEEE
CHÚ THÍCH: Giảm độ phức\r\ntạ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\r\ngiả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.
\r\n\r\nMột nỗ lực trong lĩnh\r\nvự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 đ
Họ nội bộ TSF\r\n(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.\r\nKế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 đã\r\ncó 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\r\ncho 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\r\ncó 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ó\r\nthể 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\r\nmã nguồn, hoặc có thể chứa hỗ trợ khác cho nhà phát triển cần đến.
\r\n\r\n3.2.7
\r\n\r\nGhép n
Cách thức và mức độ của\r\nsự không liên thuộc giữa các mô đun phần mềm.
\r\n\r\n(Theo IEEE
CHÚ THÍCH: Các kiểu\r\nghé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\r\ndưới).
\r\n\r\n3.2.8
\r\n\r\nGhép n
Quan hệ giữa hai mô\r\nđun trao đổi với nhau một cách chặt chẽ qua các lời\r\ngọi hàm chức năng được ghi lại tài liệu.
\r\n\r\nCHÚ THÍCH: V
3.2.9
\r\n\r\nGhép n
(về dữ liệu). Quan hệ\r\ndữ liệu giữa hai mô đun trao đ
CHÚ THÍCH: Xem ghép nối\r\ntruy xuất (3.2.8)
\r\n\r\n3.2.10
\r\n\r\nGhép n
(về nhãn tem). Quan hệ\r\nvề 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ố\r\nlờ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.
\r\n\r\nCHÚ TH
3.2.11
\r\n\r\nGhép n
(về điều khiển). Quan\r\nhệ 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\r\nđể gây ảnh hưởng đến logic bên trong của mô đun
CHÚ THÍCH: Xem ghép nối\r\ntruy xuất (3.2.8)
\r\n\r\n3.2.12
\r\n\r\nGhép n
Quan hệ giữa hai mô\r\nđun cùng chia sẻ một vùng dữ liệu chung hoặc một tài nguyên\r\nhệ thống chung khác.
\r\n\r\nCHÚ THÍCH: Các biến\r\ntoà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\r\nchung. Ghép nối chung thông qua các biến toàn cục nh
Ví dụ: Các biến được\r\nđặt trong một vùng toàn cục, song chỉ dùng trong một mô đun, sẽ coi là đặt chỗ\r\nsai 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 độ\r\nphù hợp của các biến toàn cục là:
\r\n\r\n- Số\r\ncá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\r\ncấ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ể\r\ncó các tình huống trong đó một mô đun thứ hai có thể chia sẻ trách nhiệm này.\r\nTrong tình hướng đó, cần có sự biện minh thỏa đáng. Không thể chấp nhận được việc\r\nchia sẻ trách nhiệm trên cho nhiều hơn hai mô đun. (Để thực hiện đánh giá này,\r\ncầ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\r\nbiế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\r\ngiả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\r\nnày là mô đun chịu trách nhiệm và
- S
3.2.13
\r\n\r\nGhép n
Quan hệ giữa hai mô\r\nđ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ô\r\nđun kia.
\r\n\r\nCHÚ THÍCH: Các ví dụ\r\nnhư: 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ả\r\nlà 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\r\nkia. Việc ghép nối nội dung có thể liên tưởng\r\ngiố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\r\nvới ghép nối truy xuất chỉ sử dụng các giao diện mô đun quảng cáo.
\r\n\r\n3.2.14
\r\n\r\nPhân cách miền
Đặc tính kiến trúc bảo\r\nan trong đó TSF định nghĩa các miền an toàn tách biệt\r\ncho 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\r\ndù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\r\ncủa TSF.
\r\n\r\n3.2.15
\r\n\r\nGắn kết chức năng
Đặc tính của một mô\r\nđun để thực hiện các hành động liên\r\nquan đến một mục đích riêng.
\r\n\r\n(Theo IEEE
CH
3.2.16
\r\n\r\nTương tác
Hoạt động dựa trên việc\r\ntruyền thông chung giữa các thực thể.
\r\n\r\n3.2.17
\r\n\r\nGiao diện
Phương tiện tương tác\r\nvới một thành phần hoặc một mô đun.
\r\n\r\n3.2.18
\r\n\r\nPhân lớp
Kỹ thuật thiết kế\r\ntrong đó các nhóm mô đun tách biệt (các lớp) được tổ chức\r\nphân cấp để có trách nhiệm riêng biệt sao cho một lớp chỉ phụ\r\nthuộc vào dịch vụ các lớp bên dưới nó, và cung cấp dịch vụ
CHÚ THÍCH: Phân lớp\r\nchặt chẽ bổ sung điều kiện là mỗi lớp chỉ nhận dịch vụ từ lớp ngay
3.2.19
\r\n\r\nGắn kết logic, gắn kết\r\nthủ tục (logical cohesion, procedural cohesion)
\r\n\r\nCác đặc trưng của một\r\nmô đun thực hiện các động thái giống nhau trên
CHÚ THÍCH:
3.2.20
\r\n\r\nPhân tách mô đun
Quá trình chia một hệ\r\nthống ra nhiều thành phần để thuận tiện cho thiết kế, phát triển và đánh giá.\r\n(Theo IEEE Std 610-12-1990).
\r\n\r\n3.2.21
\r\n\r\nKhả năng không đi\r\nvòng (non-bypassability)
\r\n\r\n(của TSF) là đặc tính\r\nkiến trúc an toàn trong đó mọi hành động liên quan đến SFR được đều được trung\r\nchuyển qua TSF.
\r\n\r\n3.2.22
\r\n\r\nMiền an toàn
Tập hợp tài nguyên mà\r\nmột thực thể chủ động có đặc quyền truy nhập đến.
\r\n\r\n3.2.23
\r\n\r\nGắn kết tuần tự
Mô đun chứa các chức\r\nnă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\r\nmô đun.
\r\n\r\n(Theo IEEE
CHÚ TH
3.2.24
\r\n\r\nCông nghệ phần mềm
Ứng dụng\r\ncá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\r\ntrì phần mềm, nghĩa là ứng dụng kỹ thuật cho phần mềm.
\r\n\r\n(Theo IEEE
CHÚ THÍCH: Như với thực\r\ntiễ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
3.2.25
\r\n\r\nGắn kết tạm thời
Các đặc trưng của một\r\nmô đ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.
\r\n\r\nCHÚ TH
CHÚ TH
3.2.26
\r\n\r\nTự bảo vệ TSF
Đặc tính kiến trúc an\r\ntoàn trong đó TSF không thể bị gián đoạn bởi các mã\r\ncủa TSF khác hoặc bởi các thực thể khác.
\r\n\r\n3.3.1
\r\n\r\nCài đặt
Thủ tục thực hiện bởi\r\nngườ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\r\nđộng.
\r\n\r\nCHÚ THÍCH: Hoạt động\r\nnà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\r\nTOE tiến hành theo cấu hình cho phép bởi\r\nST. 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\r\nthị là “khởi tạo” trong suốt quá trình hỗ\r\ntrợ vòng đời ALC. Nếu TOE yêu cầu khởi động ban đầu mà không cần nh
3.3.2
\r\n\r\nHoạt động
Giai đoạn sử dụng TOE\r\ngồm: “sử dụng bình thường”, quản trị và bảo dưỡng TOE\r\nsau khi chuyển giao và chuẩn bị.
\r\n\r\n3.3.3
\r\n\r\nChuẩn bị
Hoạt động trong giai\r\nđ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\r\nTOE đã chuyển giao và cài đặt nó, có thể gồm cả những việc như khởi động, khởi\r\ntạ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.
\r\n\r\n3.4.1
\r\n\r\nCác tiêu chí chấp thuận
Các tiêu chí cần áp dụng\r\nkhi thực hiện các thủ tục chấp thuận (ví dụ
3.4.2
\r\n\r\nCác thủ tục chấp thuận
Các thủ tục nối tiếp\r\ntheo 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\r\ncho TOE, hoặc để xóa bỏ chúng ở bước tiếp theo trong vòng đời.
\r\n\r\nCHÚ THÍCH: Các thủ tục\r\nnày định dạng các vai trò hoặc trách nhiệm riêng đối với
Có một số loại hình\r\nchấp thuận, một số có thể gối lên nhau, đó là:
\r\n\r\na) Chấp\r\nthuận một khoản mục vào hệ thống quản lý cấu hì
b) Tiến\r\nhành các khoản mục cấu hình trong giai đoạn tiếp theo của vòng đời\r\ntại mỗi tầng kiến thiết TOE (ví dụ mô
c) Kế\r\ntiế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\r\ncác sản phẩm ban đầu) giữa các địa điểm\r\nphát triển khác nhau.
\r\n\r\nd) Kế\r\ntiếp với việc chuyển giao TOE tới người tiêu dùng.
\r\n\r\n3.4.3
\r\n\r\nQuản l
Nguyên tắc áp dụng chỉ\r\nđạo và giám sát về mặt kỹ thuật và quản lý để định dạng và\r\ntà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
CHÚ TH
3.4.4
\r\n\r\nTài liệu CM
Tất cả tài liệu CM\r\nbao 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,\r\nkế hoạch CM và tài liệu sử dụng CM.
\r\n\r\n3.4.5
\r\n\r\nBằng chứng quản lý cấu\r\nhình (configuration management evidence)
\r\n\r\nLà mọi thứ có thể\r\ndùng để thiết lập sự tin cậy trong hoạt động đú
CH
3.4.6
\r\n\r\nKhoản mục cấu hình
Đối tượng quản lý bởi\r\nhệ thống CM trong quá trình phát triển TOE.
\r\n\r\nCHÚ THÍCH: Các khoản\r\nmụ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\r\nphá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\r\nkhoản mục CM có thể được lưu trữ trực tiếp trong hệ thống\r\nCM (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\r\ncủa chúng.
\r\n\r\n3.4.7
\r\n\r\nDanh sách cấu hình
Tài liệu đầu ra quản\r\nlý 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\r\nphiê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ụ\r\nthể của sản phẩm hoàn chỉnh.
\r\n\r\nCHÚ THÍCH: Danh sách\r\nnà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.\r\nDanh sách quản lý cấu hình là một tài liệu cụ thể\r\ncho 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à\r\nmộ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\r\nnà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ệ\r\nthố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á,\r\ndanh 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á).\r\nDanh sách cấu hình định nghĩa các khoản mục thuộc các\r\nyêu cầu quản lý cấu hình của ALC_CMC.
\r\n\r\n3.4.8
\r\n\r\nĐầu ra quản lý cấu\r\nhình (configuration management outpu
Các kết quả liên quan\r\nđế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.
\r\n\r\nCHÚ TH
3.4.9
\r\n\r\nK
Mô tả về việc hệ thống\r\nquản lý cấu hình được sử dụng cho TOE như thế nào.
\r\n\r\nCHÚ THÍCH: Mục tiêu của\r\nviệ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\r\nlàm gì. Từ quan điểm của hệ thống quản lý cấu\r\nhì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ể\r\ntạ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\r\ndự á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ó\r\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
3.4.10
\r\n\r\nHệ thống quản lý cấu\r\nhình (configuration management system)
\r\n\r\nTập các thủ tục và\r\ncông cụ (bao gồm cả tài liệu của chúng) dùng bởi
CHÚ TH
3.4.11
\r\n\r\nCác bản ghi hệ th
Kết xuất tạo ra trong\r\nquá trình hoạt động của hệ thống quản lý cấu hình được tài liệu
CHÚ THÍCH: Các ví dụ\r\nvề bản ghi hệ thống quản lý cấu hình\r\nlà các khuôn dạng điều khiển thay đổi
3.4.12
\r\n\r\nCác công cụ quản lý cấu\r\nhình (configuration management tools)
\r\n\r\nCác công cụ hoạt động\r\nthủ công hoặc tự động nhằm thực hiện hoặc hỗ trợ một hệ thống quản
CHÚ THÍCH: Ví dụ các\r\ncông cụ cho quản lý phiên bản cho các phần của TOE.
\r\n\r\n3.4.13
\r\n\r\nTài liệu s
Phần của hệ thống quản\r\nlý 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\r\nnhư thế nào. Ví dụ, các sổ tay, các quy định và/hoặc tài liệu về\r\ncác công cụ và các thủ tục.
\r\n\r\n3.4.14
\r\n\r\nChuyển giao
Vận chuyển một TOE\r\nhoàn chỉnh từ môi trường sản xuất tới tay khách hàng.
\r\n\r\nCHÚ THÍCH: Giai đoạn\r\nvòng đời sản phẩm này bao gồm cả việc đóng gói và\r\nlư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\r\nhoà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 đ
3.4.15
\r\n\r\nNhà phát triển
Tổ chức có trách nhiệm\r\nvới việc phát triển TOE.
\r\n\r\n3.4.16
\r\n\r\nPhát triển
Giai đoạn trong vòng\r\nđời sản phẩm liên quan đến việc biểu thị sự triển khai TOE.
\r\n\r\nCHÚ TH
3.4.17
\r\n\r\nCác công cụ phát triển
Các công cụ (bao gồm\r\nphần mềm kiểm thử nếu có) hỗ trợ việc phát triển và sản xuất TOE.
\r\n\r\nCHÚ TH
3.4.18
\r\n\r\nMô tả triển khai
Mô tả trừu tượng tối\r\nthiể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\r\nthiết kế nào thêm.
\r\n\r\nCHÚ TH
3.4.19
\r\n\r\nVòng đời
Chuỗi các giai đoạn tồn\r\ntạ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.
\r\n\r\n3.4.20
\r\n\r\nĐịnh nghĩa vòng đời
Định nghĩa cho một mô\r\nhình vòng đời.
\r\n\r\n3.4.21
\r\n\r\nMô hình vòng đời
Mô tả các giai đoạn\r\nvà 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\r\ncủ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\r\ncác giai đoạn cần phải như thế nào.
\r\n\r\nCHÚ TH
3.4.22
\r\n\r\nSản xuất
Giai đoạn vòng đời sản\r\nxuất kế tiếp giai đoạn phát triển và bao gồm việc chuyển tải b
CHÚ TH
CHÚ TH
3.5.1
\r\n\r\nKênh bất hợp pháp
Kênh tín hiệu cưỡng\r\nép trái phép, cho phép một người dùng lén lút vi phạm chính
3.5.2
\r\n\r\nCác điểm yếu tiềm ẩn\r\nphải đối mặt
Các yếu điểm tiềm ẩn\r\ntrong TOE có thể dùng để vi phạm các SFR được đánh
3.5.3
\r\n\r\nCác điểm yếu có thể\r\nkhai thác (exploitable vulnerability)
\r\n\r\nCác yếu điểm trong\r\nTOE có thể dùng để vi phạm các SFR trong môi\r\ntrường vận hành của TOE.
\r\n\r\n3.5.4
\r\n\r\nCác tấn công giám sát
Phân loại chung của\r\ncá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\r\nbà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\r\ntài liệu hướng dẫn.
\r\n\r\n3.5.5
\r\n\r\nCác điểm yếu tiềm ẩn
Các yếu điểm nghi vấn\r\nsong chưa được khẳng định.
\r\n\r\n3.5.6
\r\n\r\nCác điểm yếu còn t
Các yếu điểm không thể\r\nkhai 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\r\nđể 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\r\nhành của TOE.
\r\n\r\n3.5.7
\r\n\r\nĐiểm yếu
Y
3.6.1
\r\n\r\nThành phần cơ sở
Thực thể trong một\r\nTOE 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\r\nnguyên cho một thành phần phụ thuộc.
\r\n\r\n3.6.2
\r\n\r\nTương thích
(Thành phần) Là đặc\r\ntí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\r\nphầ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\r\nvận hành nhất quán.
\r\n\r\n3.6.3
\r\n\r\nTOE thành ph
TOE đã được đánh giá\r\nthành công và là một phần của một TOE tổng hợp khác.
\r\n\r\n3.6.4
\r\n\r\nTOE tổng hợp
TOE bao gồm hai hoặc\r\nnhiều thành phần đã được đánh giá thành công trước đó.
\r\n\r\n3.6.5
\r\n\r\nThành phần phụ thuộc
Thực thể trong một\r\nTOE 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\r\nvụ bởi một thành phần cơ sở.
\r\n\r\n3.6.6
\r\n\r\nGiao diện chức năng
Giao diện với bên\r\nngoài cung cấp cho người dùng khả năng truy xuất đến chức
CHÚ TH
Nội dung này liệt kê\r\ncác thuật ngữ viết tắt trong tiêu chuẩn và các ký hiệu cần thiết để hiểu rõ hơn\r\nvề tiêu chuẩn.
\r\n\r\nCHÚ THÍCH: Tiêu chuẩn\r\nnày đưa ra các thuật ngữ bằng tiếng Việt, các thuật ngữ tiếng Anh tương đương\r\nvà các thuật ngữ viết tắt tiếng Anh. Tuy chỉ có các thuật ngữ tiếng Việt mới được\r\ncoi là của tiêu chuẩn, song các viết tắt thuật ngữ tiếng Anh giữ nguyên giúp\r\ncho việc tham chiếu tới tiêu chuẩn gốc thuận lợi hơn.
\r\n\r\n| \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n API \r\n | \r\n \r\n A | \r\n \r\n Giao diện lập trình\r\n ứng dụng \r\n | \r\n
| \r\n CAP \r\n | \r\n \r\n Composed Assurance\r\n Package \r\n | \r\n \r\n Gói đảm bảo tổng hợp \r\n | \r\n
| \r\n CM \r\n | \r\n \r\n Con | \r\n \r\n Quản lý cấu hình \r\n | \r\n
| \r\n CNTT \r\n | \r\n \r\n lnformation\r\n Technology (IT) \r\n | \r\n \r\n Công nghệ thông tin\r\n (CNTT) \r\n | \r\n
| \r\n DAC \r\n | \r\n \r\n Discretionary\r\n Access Control \r\n | \r\n \r\n Kiểm soát truy nhập\r\n tùy ý \r\n | \r\n
| \r\n EAL \r\n | \r\n \r\n Evaluation\r\n Assurance Level \r\n | \r\n \r\n Mức bảo đảm đánh\r\n giá \r\n | \r\n
| \r\n GHz \r\n | \r\n \r\n Gigahertz \r\n | \r\n \r\n Số đo tần số\r\n Gigahertz \r\n | \r\n
| \r\n GUI \r\n | \r\n \r\n Graphical User\r\n Interface \r\n | \r\n \r\n Giao diện người\r\n dùng dạng đồ họa \r\n | \r\n
| \r\n IC \r\n | \r\n \r\n Integrated Circuit \r\n | \r\n \r\n Mạch tích hợp \r\n | \r\n
| \r\n IOCTL \r\n | \r\n \r\n Input Output\r\n Control \r\n | \r\n \r\n Kiểm soát vào ra \r\n | \r\n
| \r\n IP \r\n | \r\n \r\n Internet Protocol \r\n | \r\n \r\n Giao thức Internet \r\n | \r\n
| \r\n IT \r\n | \r\n \r\n In | \r\n \r\n Công nghệ thông tin\r\n (CNTT) \r\n | \r\n
| \r\n MB \r\n | \r\n \r\n Mega Byte \r\n | \r\n \r\n Đơn vị thông tin\r\n Mega Byte (MB) \r\n | \r\n
| \r\n OS \r\n | \r\n \r\n Operating System \r\n | \r\n \r\n Hệ điều hành \r\n | \r\n
| \r\n OSP \r\n | \r\n \r\n Organization | \r\n \r\n Chính sách an toàn\r\n của tổ chức \r\n | \r\n
| \r\n PC \r\n | \r\n \r\n Personal Computer \r\n | \r\n \r\n Máy tính cá nhân \r\n | \r\n
| \r\n PCI \r\n | \r\n \r\n Peripheral\r\n Component Interconnect \r\n | \r\n \r\n Liên kết nối các\r\n thành phần ngoại vi \r\n | \r\n
| \r\n PKI \r\n | \r\n \r\n Public Key In | \r\n \r\n Hạ tầng cơ s | \r\n
| \r\n PP \r\n | \r\n \r\n Protection Pro | \r\n \r\n Hồ sơ bảo vệ \r\n | \r\n
| \r\n RAM \r\n | \r\n \r\n Random Access\r\n Memory \r\n | \r\n \r\n Bộ nhớ truy nhập ngẫu\r\n nhiên \r\n | \r\n
| \r\n RPC \r\n | \r\n \r\n Remote Procedure\r\n Call \r\n | \r\n \r\n Lời gọi thủ tục từ\r\n xa \r\n | \r\n
| \r\n SAR \r\n | \r\n \r\n Security Assurance\r\n Requirement \r\n | \r\n \r\n Yêu cầu đảm bảo an\r\n toàn \r\n | \r\n
| \r\n SF \r\n | \r\n \r\n Security Function \r\n | \r\n \r\n Chức năng an toàn \r\n | \r\n
| \r\n SFR \r\n | \r\n \r\n Security Functional\r\n Requirement \r\n | \r\n \r\n Yêu cầu chức năng\r\n an toàn \r\n | \r\n
| \r\n SFP \r\n | \r\n \r\n Security Function\r\n Policy \r\n | \r\n \r\n Chính sách chức\r\n năng an toàn \r\n | \r\n
| \r\n SPD \r\n | \r\n \r\n Security Problem De | \r\n \r\n Định nghĩa vấn đề\r\n an toàn \r\n | \r\n
| \r\n SOF \r\n | \r\n \r\n Strength\r\n of Function \r\n | \r\n \r\n Độ mạnh của chức\r\n năng \r\n | \r\n
| \r\n ST \r\n | \r\n \r\n Security Target \r\n | \r\n \r\n Đích an toàn \r\n | \r\n
| \r\n TCP \r\n | \r\n \r\n Transmission\r\n Control Protocol \r\n | \r\n \r\n Giao thức điều khiển\r\n truyền tải \r\n | \r\n
| \r\n TOE \r\n | \r\n \r\n Target of\r\n Evaluation \r\n | \r\n \r\n Đích đánh giá \r\n | \r\n
| \r\n TSC \r\n | \r\n \r\n TSF Scope of\r\n Control \r\n | \r\n \r\n Phạm vi giám sát\r\n TSF \r\n | \r\n
| \r\n TSF \r\n | \r\n \r\n TOE Security\r\n Functions \r\n | \r\n \r\n Các chức năng an\r\n toàn của TOE \r\n | \r\n
| \r\n TSFI \r\n | \r\n \r\n TSF Inter | \r\n \r\n Giao diện TSF \r\n | \r\n
| \r\n TSP \r\n | \r\n \r\n TOE Security Policy \r\n | \r\n \r\n Chính sách an toàn\r\n TOE \r\n | \r\n
| \r\n VPN \r\n | \r\n \r\n Virtual Private Net | \r\n \r\n Mạng riêng ảo \r\n | \r\n
Mục này giới thiệu\r\ncác khái niệm chính của tiêu chuẩn TCVN 8709. Nó chỉ ra khái niệm “TOE”, các đối\r\ntượng sử dụng tiêu chuẩn, và cách thức tiếp cận để trình bày tiêu chuẩn.
\r\n\r\n\r\n\r\nTiêu chuẩn TCVN 8709\r\nlinh hoạt trong việc đánh giá, do đó không bị bó hẹp trong giới hạn các sản phẩm\r\nCNTT như đa số vẫn hiểu. Bởi vậy, trong ngữ cảnh đánh giá, tiêu chuẩn này sử dụng\r\nkhái niệm “TOE” (Đích đánh giá).
\r\n\r\nMột TOE được định\r\nnghĩa là một tập phần mềm, phần sụn và/hoặc phần cứng có thể kèm theo hướng
Trong một số trường hợp\r\nTOE gồm có một sản phẩm CNTT, song đó\r\nkhông phải là cần thiết. TOE có thể\r\nlà một sản phẩm CNTT, một phần của một sản phẩm CNTT, một tập\r\ncác sản phẩm CNTT, một công nghệ độc nhất có\r\nthể chẳng khi nào dùng để sản sinh ra một sản phẩm, hoặc một tổ hợp của các\r\nthành phần trên.
\r\n\r\nTrong liên quan đến\r\nTCVN 8709, quan hệ chính xác giữa TOE và bất kỳ sản phẩm CNTT nào chỉ quan trọng\r\nở một khía cạnh: đánh giá cho một TOE chỉ\r\nchứa một phần sản phẩm CNTT cần không thể hiện sai là đánh giá cho toàn bộ sản\r\nphẩm CNTT đó.
\r\n\r\nVí dụ về các TOE là:
\r\n\r\n
5.2.1.
Trong TCVN 8709, một\r\nTOE có thể xuất hiện theo một số cách thể hiện khác nhau, ví dụ (đối với TOE l
Tất cả những thể hiện\r\nnêu trên đều được xem là TOE: mỗi khi khái niệm “TOE” được dùng trong phần còn\r\nlại của tiêu chuẩn này, ngữ cảnh sẽ xác định cách thể hiện của nó.
\r\n\r\n5.2.2.
Nói chung, các sản phẩm\r\nCNTT có thể được cấu hình theo nhiều cách: cài đặt theo các cách khác nhau, với\r\ncác tùy chọn khác nhau hoặc mở hoặc chặn. Vì khi đánh giá với TCVN 8709, TOE sẽ\r\nđược xác định xem có thỏa mãn các yêu cầu xác định không, sự mềm dẻo trong cầu\r\nhình này có thể dẫn đến các vấn đề, do tất cả mọi cấu hình c
Một ví dụ là với sản\r\nphẩm CNTT là hệ điều hành. Sản phẩm này có thể được cấu hình theo nhiều cách\r\n(ví dụ các kiểu người dùng, số người dùng, kiểu các kết nối ra ngoài cho phép/cấm,\r\ncác tùy chọn mở/chặn ...)
\r\n\r\nNếu sản phẩm CNTT\r\ncũng chính là một TOE, và được đánh giá theo một tập hợp lý các yêu cầu, cấu\r\nhình cần được kiểm soát chặt chẽ hơn, vì nhiều tùy chọn (ví dụ cho phép mọi kiểu\r\nkết nối ngoài hoặc quản trị hệ thống không cần phải được\r\nxác thực) sẽ dẫn đến vấn đề TOE không thỏa mãn các yêu cầu.
\r\n\r\nVì lý do này, thông\r\nthường sẽ có sự khác biệt giữa hướng dẫn cho sản phẩm CNTT (cho phép nhiều cấu\r\nhình) và hướng dẫn cho TOE (cho phép chỉ một hoặc chỉ những cấu hình không c
Lưu ý là nếu hướng dẫn\r\ncho TOE vẫn cho phép nhiều hơn một cấu hình, các cấu hình này được gọi chung là\r\n“cho TOE” và mỗi cấu hình như vậy phải thỏa mãn các yêu cầu tập trung vào TOE.
\r\n\r\nBa nhóm người có mối\r\nquan tâm chung trong đánh giá các thuộc tính an toàn của các sản phẩm và hệ thống\r\nCNTT là: Người tiêu dùng TOE, nhà phát triển TOE và đánh giá viên TOE.
5.3.1.
Tiêu chuẩn này được\r\nbiên soạn nhằm đảm bảo rằng, việc đánh giá thỏa mãn các nhu cầu của người tiêu\r\ndùng vì đó là mục đích cơ bản và là biện minh\r\ncho quy trình đánh giá.
\r\n\r\nNgười tiêu dùng có khả\r\nnăng sử dụng kết quả đánh giá để giúp quyết định xem sản phẩm hoặc hệ thống đã\r\nđánh giá có thỏa mãn các nhu cầu an toàn của họ hay không. Những nhu cầu an\r\ntoàn này thường được xác định qua kết quả của cả việc phân tích rủi ro và định\r\nhướng chính sách. Người tiêu dùng cũng có thể sử dụng các kết quả đánh giá để\r\nso sánh các TOE khác nhau.
\r\n\r\nTCVN 8709 mang lại\r\ncho người tiêu dùng - đặc biệt cho các nhóm người tiêu dùng và cộng đồng quan\r\ntâm - một cấu trúc độc lập với việc triển khai, được gọi là Hồ sơ bảo vệ\r\n(Protected Profile - PP), trong đó biểu thị các yêu cầu\r\ncủa họ về an toàn theo một cách rõ ràng.
\r\n\r\n5.3.2.
TCVN 8709 hỗ trợ các\r\nnhà phát triển trong việc chuẩn bị và trợ giúp đánh giá các sản phẩm hoặc hệ thống,\r\ntrong xác định các yêu cầu an toàn cần thỏa mãn cho các TOE. Các yêu cầu này được\r\nchứa trong một kết cấu phụ thuộc vào việc triển khai, được gọi là Đích An toàn\r\n(ST). Kết cấu ST này có thể dựa\r\nvào một hoặc nhiều PP để chỉ ra rằng ST tuân thủ các yêu cầu\r\nan toàn từ phía người tiêu dùng như đã sắp đặt trong\r\ncác PP này.
\r\n\r\nTCVN 8709 có thể dùng\r\nđể xác định trách nhiệm và các hành động để cung cấp bằng ch
5.3.3.
TCVN 8709 chứa các\r\ntiêu chí được đánh giá viên sử dụng khi lập ra các phán xét về sự tuân thủ của\r\ncác TOE theo các yêu cầu an toàn của chúng. TCVN 8709 mô tả một tập hợp các\r\ncông việc chung mà đánh giá viên cần thực hiện và các chức năng an toàn, căn cứ\r\ntheo đó để thực hiện các công việc trên. Lưu ý là TCVN 8709 không chỉ ra các thủ\r\ntục hướng dẫn thực hiện các công việc này. Xem thêm thông tin về các thủ tục\r\nnày ở Mục 5.5.
\r\n\r\n5.3.4.
TCVN 8709 hướng tới\r\nviệc định rõ và đánh giá các thuộc tính an toàn CNTT của các TOE, đồng thời nó\r\ncũng có thể là một tài liệu tham khảo hữu ích cho tất cả những ai quan tâm đến\r\nhoặc có trách nhiệm về an toàn CNTT. Một vài nhóm đối tượng quan tâm khác cũng\r\ncó khả năng có lợi ích từ các thông tin trong TCVN 8709 bao gồm:
\r\n\r\na) Các\r\nnhân viên bảo vệ hệ thống và các nhân viên an toàn hệ thống, những người có\r\ntrách nhiệm trong việc xác định và đáp ứng các chính sách và yêu cầu an toàn\r\nCNTT cho tổ chức.
\r\n\r\nb) Các\r\nkiểm toán viên, cả bên trong và bên ngoài, có trách nhiệm lượng giá mức tương xứng\r\nvề an toàn của một hệ thống.
\r\n\r\nc) Các\r\nnhân viên thiết kế và xây dựng hệ thống, có trách nhiệm định rõ nội dung an\r\ntoàn cho các sản phẩm và hệ thống CNTT.
\r\n\r\nd) Những\r\nngười được ủy quyền, có trách nhiệm chấp thuận việc một giải pháp CNTT đưa vào\r\nsử dụng trong một môi trường cụ thể.
\r\n\r\ne) Những\r\nngười bảo trợ đánh giá, có trách nhiệm yêu cầu và hỗ trợ việc đánh giá.
\r\n\r\nf) Các\r\ncơ quan đánh giá, có trách nhiệm quản lý và giám sát các chương trình đánh giá\r\nan toàn CNTT.
\r\n\r\nTCVN 8709 được trình\r\nbày dưới dạng một tập hợp ba phần riêng biệt song có liên quan như tóm tắt dưới\r\nđây. Các thuật ngữ sử dụng để mô tả các phần này được giải thích trong Điều 6.
\r\n\r\na)
b)
c)
Để hỗ trợ ba phần của\r\ntiêu chuẩn như nêu ở trên, các tài liệu khác cũng đã được công bố, ví dụ\r\nISO/IEC 18045 cung cấp hệ thống phương pháp cho đánh giá an toàn CNTT sử dụng\r\nISO/IEC 15408 làm cơ sở. Dự đoán là sẽ có thêm các tài liệu khác được công bố,\r\nbao gồm các tư liệu sơ cứ kỹ thuật và các tài liệu hướng dẫn.
\r\n\r\nBảng dưới đây biểu diễn\r\nba nhóm đối tượng sử dụng tiêu chuẩn chủ chốt, dựa trên mức độ quan tâm đến các\r\nphần của tiêu chuẩn TCVN 8709:
\r\n\r\n| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n Dùng làm thông tin\r\n cơ sở và bắt buộc sử dụng để tham chiếu. | \r\n \r\n Dùng làm thông tin\r\n cơ sở và tham chiếu. Bắt buộc sử dụng để phát triển các đặc tả an toàn cho\r\n các TOE. \r\n | \r\n \r\n Bắt buộc sử dụng để\r\n tham chiếu và hướng dẫn trong cấu trúc cho các PP | \r\n
| \r\n | \r\n \r\n Dùng để hướng dẫn\r\n và tham chiếu khi lập các phát biểu về yêu cầu các chức năng an toàn của một\r\n TOE \r\n | \r\n \r\n Dùng để tham chiếu\r\n khi diễn giải các phát biểu về yêu cầu chức năng, và khi lập các đặc tả chức\r\n năng cho các TOE. \r\n | \r\n \r\n Bắt buộc sử dụng để\r\n tham chiếu khi diễn giải các phát biểu về các yêu cầu chứ | \r\n
| \r\n | \r\n \r\n Dùng để hướng dẫn\r\n khi xác định cấp bảo đảm yêu cầu. \r\n | \r\n \r\n Dùng để tham chiếu\r\n khi diễn giải các phát biểu về yêu cầu đảm bảo, và khi xác định các cách đảm\r\n bảo các TOE. \r\n | \r\n \r\n Dùng để tham chiếu\r\n khi diễn giải các phát biểu về các yêu cầu đảm bảo. \r\n | \r\n
Đ
TCVN 8709 không nêu\r\nrõ các yêu cầu về bộ khung điều chỉnh. Mặc dù vậy, sự nhất quán giữa các bộ\r\nkhung điều chỉnh của những người có thẩm quyền đánh giá khác nhau
Một cách thứ hai để đạt\r\nđược tính tương thích nhiều hơn giữa các kết quả đánh giá là sử dụng hệ phương\r\npháp luận chung để đạt các kết quả này. Hệ phương pháp này được công bố trong\r\ntiêu chuẩn ISO/IEC 18045 cho tiêu chuẩn TCVN\r\n8709.
\r\n\r\nSử dụng một hệ phương\r\npháp đánh giá chung giúp làm tăng khả năng lặp lại và tính khách quan của các kết\r\nquả, tuy nhiên như vậy vẫn chưa đủ. Nhiều tiêu chí đánh giá đòi hỏi vận dụng\r\nsuy xét chuyên gia và kiến thức cơ bản, khi đó sẽ khó khăn hơn để đạt được sự\r\nnhất quán. Để nâng cao sự nhất quán của các nhận xét đánh giá, các kết quả đánh\r\ngiá cuối cùng cần được thông qua một quy trình chứng nhận.
\r\n\r\nQuy trình chứng nhận\r\nlà việc thanh tra độc lập các kết quả đánh giá, dẫn đến đưa ra chứng nhận cuối\r\ncùng hoặc công nhận. Chứng nhận thường được đưa ra công khai. Điều này chỉ ra rằng\r\nquy trình chứng nhận là một cách để đạt\r\nđược một sự nhất quán hơn khi ứng dụng các tiêu chí an toàn CNTT.
\r\n\r\nLược đồ đánh giá và\r\ncác quy trình chứng nhận là trách nhiệm của những cơ quan đánh giá khi thực hiện\r\ncác lược đồ đánh giá và không thuộc phạm vi của TCVN 8709.
\r\n\r\n\r\n\r\nPhần này trình bày\r\ncác khái niệm chung được sử dụng trong TCVN 8709, bao gồm ngữ cảnh trong đó các\r\nkhái niệm được sử dụng và cách thức TCVN 8709 áp dụng các khái niệm này. TCVN\r\n8709-2 và TCVN 8709-3 là các tài liệu bắt buộc người dùng phần 1 của tiêu chuẩn\r\nTCVN 8709 phải tư vấn. Chúng mở rộng việc sử dụng các khái niệm này và giả định\r\ncách tiếp cận trên được dùng. Ngoài ra, đối với người dùng tiêu chuẩn TCVN\r\n8709-1 nhằm thực hiện các hoạt động đánh giá, tiêu chuẩn ISO/IEC 18045 có thể\r\náp dụng. Phần này giả thiết một số hiểu biết về an toàn CNTT và không dự định\r\nthực hiện vai trò hướng dẫn trong lĩnh vực này.
\r\n\r\nTCVN 8709 bàn về an\r\ntoàn dựa trên một tập các khái niệm và thuật ngữ an toàn. Hiểu biết các khái niệm\r\nvà thuật ngữ này được xem như một điều kiện tiên quyết để sử dụng hiệu quả TCVN\r\n8709. Mặc dù vậy, bản thân các khái niệm này rất tổng quát, không dự kiến hạn\r\nchế sử dụng chỉ cho lớp các vấn đề an toàn CNTT mà trong đó TCVN 8709 được áp dụng.
\r\n\r\nAn toàn liên quan đến\r\nviệc bảo vệ các tài sản. Các tài sản là các thực thể mà ai đó c
Tuy vậy, do các giá\r\ntrị có tính chủ quan cao, hầu hết các thứ đều có thể là một tài sản.
\r\n\r\n(Các) môi trường\r\ntrong đó các tài sản này được đặt, được gọi là môi trường vận hành. Ví dụ về\r\n(các khía cạnh của) môi trường vận hành là:
\r\n\r\n
Rất nhiều tài sản ở dạng\r\nthông tin được lưu trữ, xử lý, truyền tải bởi\r\ncác sản phẩm CNTT để thỏa mãn các yêu cầu đặt ra b
Đảm bảo an toàn cho\r\ntài sản là trách nhiệm của người chủ sở hữu,\r\nngười đưa các giá trị vào các tài sản đó. Các tác nhân đe dọa hiện hữu hoặc dự\r\nđoán cũng có thể đưa các giá trị vào tài sản và tìm cách lạm dụng tài sản theo\r\ncách trái ngược với lợi ích của chủ sờ hữu. Ví dụ về các tác nhân đe dọa là các\r\ntin tặc, kẻ ác ý, những người vô ý (những người đôi lúc gây lỗi), các tiến\r\ntrình và các tai họa trong máy tính.
\r\n\r\nChủ s
Các mối đe dọa nêu\r\ntrên sẽ làm gia tăng các rủi ro cho tài sản, dựa trên khả năng một đe dọa đang\r\nhình thành và ảnh hưởng vào tài sản khi m
Các chủ sở hữu tài sản\r\ncó thể chịu trách nhiệm về các tài sản trên và do vậy cần có khả năng bảo vệ\r\nquyết định chấp nhận các rủi ro phơi bày tài sản trước các mối đe dọa.
\r\n\r\nC
Nhiều chủ sở hữu tài\r\nsản thiếu nhận thức, kinh nghiệm hay tài nguyên cần thiết để suy xét mức độ đầy\r\nđủ và chính xác của các biện pháp đối phó, và họ\r\ncó thể không muốn chỉ đơn thuần dựa vào sự xác nhận của của các nhà phát triển\r\ncác biện pháp đối phó. Những người tiêu dùng này, do vậy, có thể chọn cách tăng\r\nđộ tin cậy trong mức độ đủ và chính xác của một số hoặc toàn bộ các biện pháp đối\r\nphó thông qua việc đặt hàng đánh giá các biện pháp đối phó này.
\r\n\r\n6.2.1.
Trong khi đánh giá,\r\ntính đầy đủ của các biện pháp đối phó được phân tích thông qua một kết cấu gọi\r\nlà Đích an toàn (ST). Mục này trình bày một cách sơ lược về kết cấu này, chi tiết\r\nvà mô tả đầy đủ về ST có thể xem trong Phụ lục A.
\r\n\r\nĐích an toàn bắt đầu\r\nbăng việc mô tả các tài sản và các mối đe dọa tới chúng. Tiếp đó, Đích an toàn\r\nmô tả các biện pháp đối phó (dưới dạng các Mục tiêu an toàn) và diễn giải rằng\r\ncác biện pháp đối phó này là đủ để chổng lại các mối đe dọa kể trên: Nếu các biện\r\npháp đối phó thực hiện những gì chúng cần phải thực hiện, các mối đe dọa sẽ được\r\nngăn chặn.
\r\n\r\nTiếp theo, Đích an\r\ntoàn chia các biện pháp đối phó này thành hai nhóm:
\r\n\r\na) Các\r\nmục tiêu an toàn cho TOE: Đây là mô tả các biện pháp đối phó mà tính chính xác\r\nsẽ được xác định trong khi đánh giá;
\r\n\r\nb) Các\r\nmục tiêu an toàn cho môi trường vận hành: Đây là mô tả các biện pháp đối phó mà\r\ntính chính xác sẽ không được xác định trong khi đánh giá;
\r\n\r\nLý do để chia ra hai\r\nnhóm trên như sau:
\r\n\r\n
Đối với TOE (các biện\r\npháp đối phó thuộc CNTT với tính chính xác sẽ được đánh giá trong quá trình\r\nđánh giá), Đích an toàn đòi hỏi có thêm chi tiết về các mục tiêu an toàn cho\r\nTOE trong các yêu cầu chức năng an toàn (SFR). Các SFR này được trình bày trong\r\nmột ngôn ngữ chuẩn (mô tả trong TCVN 8709-2) để bảo đảm sự chính xác và dễ\r\ntương thích.
\r\n\r\nTóm lại, Đích an toàn\r\ndiễn giải:
\r\n\r\n
Từ đây suy ra rằng, một\r\nTOE đúng (thỏa mãn các SFR) trong sự kết hợp với một môi tr
6.2.2.
Một Toe có thể được\r\nthiết kế và triển khai không chính xác, do đó có thể chứa các lỗi dẫn đến điểm\r\nyếu. Qua khai thác các điểm yếu này, tin tặc vẫn có thể phá hoại và/hoặc lạm dụng\r\ncác tài sản.
\r\n\r\nCác điểm yếu trên có\r\nthể xuất hiện từ các lỗi ngẫu nhiên có trong quá trình phát triển, thiết kế sơ\r\nsài, việc cố ý chèn thêm mã độc, kiểm thử sơ sài, v.v.
\r\n\r\nĐ
Đích an toàn cung cấp\r\nmột mô tả có cấu trúc của các động thái này để xác định tính chính xác dưới dạng\r\nCác yêu cầu đảm bảo an toàn (Security Assurance\r\nRequirements - SAR). Các SAR này được biểu thị trong một ngôn ngữ chuẩn (mô tả\r\ntrong TCVN 8709-3) để bảo đảm sự chính xác và dễ tương thích.
\r\n\r\nNếu các SAR được thỏa\r\nmãn, sẽ có sự bảo đảm về tính chính xác của TOE, và do đ
6.2.3.
Môi trường vận hành\r\ncó thể được thiết kế và triển khai không đúng, do\r\nđó có thể chứa các lỗi dẫn đến điểm yếu. Qua khai thác các điểm yếu này, tin tặc\r\nvẫn có thể phá hoại và/hoặc lạm dụng các tài sản.
\r\n\r\nTuy nhiên, trong tiêu\r\nchuẩn TCVN 8709, không có sự bảo đảm nào đạt được liên quan đến tính chính xác\r\ncủa môi trường vận hành. Hay nói một cách khác, môi trường vận hành không được\r\nđánh giá (xem mục 6.3).
\r\n\r\nTrong liên quan đến\r\nđánh giá, môi trường vận hành được giả định là thuyết minh đúng 100% về các mục\r\ntiêu an toàn cho môi trường vận hành.
\r\n\r\nĐiều này không cản trở\r\nngười tiêu dùng một TOE sử dụng các phương pháp khác để xác định tính chính xác\r\ncủa môi trường vận hành đó, ví dụ:
\r\n\r\n
Các chủ sở hữu tài sản\r\nsẽ phân tích các mối đe dọa có thể xảy ra với tài sản và môi trường của họ, xác\r\nđịnh các rủi ro liên quan tới chúng. Phân tích trên có thể hỗ trợ trong việc lựa\r\nchọn các biện pháp phòng chống để chống lại các rủi ro và giảm chúng xuống một\r\nmức độ chấp nhận được.
\r\n\r\nCác biện pháp phòng\r\nchống được áp đặt để làm giảm các điểm yếu và để đáp ứng các chính sách an toàn\r\ncủa chủ sở hữu tài sản (hoặc trực tiếp hoặc gián\r\ntiếp thông qua chỉ dẫn tới các phần khác). Các điểm yếu còn lại có thể vẫn tồn\r\ntại sau khi áp đặt các biện pháp phòng chống. Các điểm yếu đó có thể bị khai\r\nthác bởi các tác nhân đe dọa thể hiện một mức độ rủi ro tồn đọng cho tài sản.\r\nCác chủ sở hữu sẽ tìm cách giảm thiểu rủi ro đó theo những ràng buộc khác.
\r\n\r\n\r\n\r\nTCVN 8709 thừa nhận\r\nhai kiểu đánh giá: đánh giá một ST/TOE như được mô tả sau đây, và đánh giá các PP\r\nđược định nghĩa trong TCVN 8709-3. Tại nhiều vị trí, TCVN 8709 sử dụng khái niệm\r\nđánh giá (không có bổ nghĩa) để chỉ đánh giá ST/TOE.
\r\n\r\nTrong TCVN 8709, đánh\r\ngiá ST/TOE được thực hiện theo hai bước sau:
\r\n\r\na) Đánh\r\ngiá ST: xác định tính đầy đủ của TOE và môi trường vận hành.
\r\n\r\nb) Đánh\r\ngiá TOE: Xác định tính chính xác của TOE. Như đã nêu ở trên, đánh giá TOE không\r\nhàm ý đánh giá tính chính xác của môi trường vận hành.
\r\n\r\nĐánh giá ST được thực\r\nhiện bằng việc áp dụng các tiêu chí đánh giá Đích an toàn (như đ
Đánh giá TOE phức tạp\r\nhơn. Các đầu vào chính của đánh giá TOE là: bằng chứng đánh giá bao gồm TOE và\r\nST, song thường cũng bao gồm cả đầu vào từ môi trường phát triển, v
Đánh giá TOE gồm việc\r\náp dụng các SAR (từ Đích an toàn) vào bằng chứng đánh giá. Phương pháp chuẩn\r\nxác để áp dụng một SAR cụ thể được xác định bở
Việc tài liệu hóa các\r\nkết quả áp dụng SAR như thế nào, các báo cáo nào cần tạo ra v
Kết quả của quá trình\r\nđánh giá TOE là một trong hai phát biểu sau:
\r\n\r\n
Đánh giá TOE có thể\r\nthực hiện sau khi bước phát triển TOE hoàn tất, hoặc song song với quá trình\r\nphát triển TOE.
\r\n\r\nPhương pháp công bố kết\r\nquả đánh giá ST/TOE được mô tả trong Điều 9. Các kết quả này cũng định danh các\r\nPP và các gói mà TOE đòi hỏi tuân thủ, các\r\nkết cấu này được mô tả trong Điều 7.
\r\n\r\nCác thành phần chức\r\nnăng và đảm bảo của tiêu chuẩn có thể sử dụng chín
Các hoạt động chỉ định\r\nvà chọn được cho phép chỉ khi thể hiện một cách rõ rệt trong một thành phần.\r\nCác hoạt động lặp và bổ sung chi tiết được phép cho mọi thành phần. Các hoạt động\r\nđược mô tả chi tiết ở phần sau.
\r\n\r\nCác phụ lục của TCVN\r\n8709-2 cung cấp hướng dẫn về việc hoàn thiện hợp lệ các lựa chọn và chỉ định.\r\nHướng dẫn này cung cấp các lệnh chuẩn về việc hoàn thành các hoạt động như thế\r\nnào, các lệnh đó sẽ kế tiếp ngoại trừ tác giả PP/ST bố trí lại các lệch lạc\r\nsau:
\r\n\r\na) Từ\r\n“Không” chỉ có thể dùng làm một lựa chọn để hoàn tất một phép lựa chọn
Các danh sách đã cung\r\ncấp cho việc hoàn thiện các phép lựa chọn cần không được là danh sách trắng. Nếu\r\ntùy chọn “Không” được chọn, sẽ không có tùy chọn phép lựa chọn bổ sung nào có\r\nthể được chọn. Nếu “Không” đưa ra trong một phép lựa chọn không phải là tùy chọn,\r\nnó cho phép kết hợp các chọn lựa trong một phép lựa chọn với “và” và “hoặc",\r\nngoại trừ phép lựa chọn công bố rõ “chọn một trong số
Các hoạt động chọn có\r\nthể kết hợp bởi phép lặp khi cần. Trong trường hợp này, khả năng áp dụng được của\r\ntùy chọn đã chọn cho mỗi phép lặp cần không chồng lấn lên cơ quan của các phép\r\nlựa chọn có lặp khác, vì chúng dự kiến là bị loại trừ.
\r\n\r\nb) Để\r\nhoàn thành các phép gán, các phụ lục của TCVN 8709-2 sẽ được tham khảo để xác định\r\nra khi nào “không” có thể là một hoàn tất hợp lệ.
\r\n\r\n7.1.1.
Hoạt động lặp có thể\r\nđược thực hiện ở mọi thành phần. Tác giả PP/ST thực hiện một hoạt động lặp bằng\r\ncách đưa vào nhiều yêu cầu dựa trên cùng một thành phần. Mỗi phép lặp của m
Các phép lặp khác\r\nnhau nên định danh duy nhất để cho phép các sở cứ và các dấu vết đến từ và đi từ\r\ncác yêu cầu này.
\r\n\r\nQuan trọng là cần lưu\r\ný rằng đôi lúc một hoạt động lặp có thể được dùng với các thành phần, khi đó\r\ncũng có thể thực hiện một phép chỉ định với một khoảng giá trị hoặc một danh\r\nsách các giá trị thay vì lặp lại chúng. Trong trường hợp này, tác giả có thể chọn\r\nra phương án thích hợp nhất, xem xét xem cs cần cung cấp toàn bộ sở cứ cho một\r\nkhoảng giá trị hoặc xem có cần có riêng từng sở cứ tách biệt cho mỗi khoảng.\r\nTác giả nên lưu ý nếu việc ghi dấu vết riêng được yêu cầu cho các giá trị này.
\r\n\r\n7.1.2.
Một hoạt động chỉ định\r\nxảy ra khi một thành phần cho trước chứa một phần tử với tham số có thể đặt bởi\r\ntác giả PP/ST. Tham số có thể là một biến không giới hạn, một quy tắc hạn chế\r\nbiến trong một khoảng giá trị nhất định.
\r\n\r\nMỗi khi một phần tử\r\ntrong một PP có chứa một phép chỉ định, tác giả của
a) Rời\r\nbỏ phép chỉ định không hoàn tất. Tác giả PP có\r\nthể đưa vào FIA_ASL.1.2 “Khi một số lượng xác định phép thử xác thực không\r\nthành công đạt được hoặc vượt qua, TSF cần [
b) Hoàn\r\ntất phép chỉ định: ví dụ, tác giả PP có\r\nthể đưa vào FIA_ASL .1.2 “Khi một số lượng xác
c) Thu\r\nhẹp phép chỉ định, tiếp đó giới hạn khoảng giá trị cho phép. Ví dụ, tác giả PP'có\r\nthể đưa vào FIA_ÀL.1.1 “TSF cần phát hiện khi nào [
d) Chuyển\r\nđổi phép chỉ định thành một phép lựa chọn, qua đó thu hẹp phép chỉ định. Ví dụ,\r\ntác giả PP có thể đưa vào FIA_ÀL.1.2 “Khi một số\r\nxác định số lần thử xác thực không thành công đã đạt được hoặc
Mỗi khi một phần tử\r\ntrong một ST chứa một phép chỉ định, tác giả ST cần hoàn\r\ntất phép gán này, như đã biểu thị ở mục b) nêu trên. Các tùy chọn a), c) và d)\r\nkhông cho phép đối với ST.
\r\n\r\nCác giá trị được chọn\r\ntrong các tùy chọn b), c) và d) cần tuân thủ theo kiểu đã chỉ ra yêu cầu bởi\r\nphép chỉ định.
\r\n\r\nKhi một phép chỉ định\r\ncần được hoàn thành với một tập (ví dụ các cơ quan), n
Chừng nào còn rõ các\r\ncơ quan nào được xét tới.
\r\n\r\n7.1.3.
Một hoạt động lựa chọn\r\nxảy ra khi một thành phần cho trước chứa một phần tử và một chọn lựa từ các biểu\r\nthức cần được lập bởi tác giả PP/ST.
\r\n\r\nMỗi khi một phần tử\r\ntrong một PP có chứa một phép lựa chọn, tác gi
e) Rời\r\nbỏ phép lựa chọn không hoàn tất.
\r\n\r\nf) Hoàn\r\ntất phép lựa chọn bằng việc lựa chọn một hoặc nhiều biểu thức.
\r\n\r\ng) Giới\r\nhạn phép lựa chọn qua việc xóa bỏ một số lựa chọn,\r\nsong để lại 2 hoặc nhiều hơn.
\r\n\r\nMỗi khi một phần tử\r\ntrong 1 ST chứa một phép lựa chọn, tác giả ST cần hoàn tất phép lựa chọn này,\r\nnhư đã biểu thị ở mục b) nêu trên. Các tùy chọn a), c) và d) không cho phép đối\r\nvới ST.
\r\n\r\nBiểu thức hoặc các biểu\r\nthức được chọn ở b) và c) cần lấy từ các biểu thức đã cung cấp
7.1.4.
Hoạt động bổ sung chi\r\ntiết có thể được thực hiện ở mọi yêu cầu. Tác giả PP/ST thực hiện một phép bổ sung\r\nchi tiết bằng cách thay đổi yêu cầu này. Quy tắc đầu tiên cho một phép bổ sung\r\nchi tiết là một TOE đáp ứng yêu cầu đã chi tiết hó
Chỉ có một ngoại lệ\r\ncho quy tắc này là một tác giả PP/ST được phép bổ
Tuy nhiên, ngoại lệ\r\nnày không áp dụng cho bổ sung chi tiết SFR lấy từ các PP đang đòi hỏi tuân thủ.\r\nCác SFR này có thể không được bổ sung chi tiết để áp dụng to một vài cả cơ\r\nquan, đối tượng, hoạt động, thuộc tính an toàn và/hoặc các thực thể bên ngoài\r\nso với SFR trong PP.
\r\n\r\nQuy tắc thứ hai cho một\r\nphép bổ sung chi tiết là một phép bổ sung chi tiết cần liên quan đến thành phần\r\nchính hiệu.
\r\n\r\nMột trường hợp đặc biệt\r\ncủa phép bổ sung chi tiết là một bổ sung chi tiết biên soạn, trong đó một thay\r\nđổi nhỏ được tạo trong một yêu cầu, nghĩa là làm rõ nghĩa một câu để trung\r\nthành với ngữ pháp tiếng Anh đúng, hoặc làm cho nó dễ hiểu hơn cho người đọc. Sự\r\nthay đổi này không được phép sửa đổi ý nghĩa của yêu cầu theo bất kỳ cách nào.
\r\n\r\nGiữa các thành phần\r\ncó thể có các quan hệ phụ thuộc. Các quan hệ phụ thuộc nảy sinh khi một thành\r\nphần không đủ và phải tồn tại khi có mặt thành phần khác để cung cấp tính năng\r\nan toàn hay đảm bảo.
\r\n\r\nCác thành phần chức\r\nnăng trong TCVN 8709-2 điển hình có sự phụ thuộc vào các thành phần chức năng\r\nkhác như một số thành phần đảm bảo trong TCVN 8709-3 đã có, chúng có thể có sự\r\nphụ thuộc vào các thành phần khác của TCVN 8709-3. Sự phụ thuộc của TCVN 8709-2\r\nvào các thành phần TCVN 8709-3 cũng có thể được định nghĩa. Tuy nhiên, điều này\r\nkhông ngăn cản các thành phần chức năng\r\nngoài có sự phụ thuộc vào các thành phần đảm bảo và ngược lại.
\r\n\r\nCác mô tả sự phụ thuộc\r\ncủa thành phần được xác định qua tham khảo các định nghĩa thành phần trong TCVN\r\n8709-2 và TCVN 8709-3. Để đảm bảo mô tả sự hoàn thiện các yêu cầu an toàn TOE,\r\ncác phụ thuộc cần được thỏa mãn khi các yêu cầu dựa trên các thành phần với sự\r\nphụ thuộc được kết hợp vào PP và ST. Các phụ thuộc nên được xem xét khi cấu\r\ntrúc các gói.
\r\n\r\nNói một cách khác, nếu\r\nthành phần A có sự phụ thuộc vào thành phần B, điều đó nghĩa là mỗi khi một PP/ST\r\ncó chứa một yêu cầu an toàn dựa trên thành phần A, PP/ST cũng cần ch
a) Một\r\nyêu cầu an toàn dựa trên thành phần B, hoặc
\r\n\r\nb) Một\r\nyêu cầu an toàn dựa trên một thành phần nằm ở phân cấp cao hơn B, hoặc
\r\n\r\nc) Một\r\nbiện minh tại sao PP/ST không chưa một yêu cầu an toàn dựa trên thành phần B.
\r\n\r\nTrong các trường hợp\r\na) và b), khi một yêu cầu an toàn được bao hàm do tính phụ thuộc, có thể c
Trong trường hợp c),\r\nbiện minh cho việc không chứa một yêu cầu an toàn nên đề cập đến:
\r\n\r\n
Trong TCVN 8709, các\r\nyêu cầu bắt buộc phải dựa vào các thành phần trong TCVN 8709-2 hoặc TCVN 8709-3\r\nvới 2 ngoại lệ sau:
\r\n\r\na) Có\r\ncác mục tiêu an toàn cho TOE không thể chuyển đổi sang các SFR của phần 2, hoặc\r\ncó các yêu cầu của bên thứ ba (ví dụ luật pháp,\r\ntiêu chuẩn) không thể chuyển đổi sang các SAR của phần 3 (ví dụ liên quan đến\r\nđánh giá mật mã).
\r\n\r\nb) Một\r\nmục tiêu an toàn có thể được chuyển đổi, song chỉ với mức độ phức tạp cao hoặc/và\r\nkhó khăn lớn trên cơ sở các thành phần trong TCVN 8709-2 hoặc TCVN 8709-3.
\r\n\r\nTrong cả hai trường hợp,\r\ntác giả PP/ST được đòi hỏi phải định nghĩa các thành phần riêng của họ. Các\r\nthành phần mới được định nghĩa này được gọi là các thành phần mở rộng. Một\r\nthành phần mở rộng được định nghĩa chính xác là cần\r\nthiết để đưa ra ngữ cảnh và ý nghĩa cho các SFR\r\nvà SAR mở rộng dựa trên thành phần này.
\r\n\r\nSau khi các thành phần\r\nmới đã được định nghĩa chính xác, tác giả PP/ST có thể đưa ra một hoặc nhiều\r\nSFR hoặc SAR trên cơ sở các thành phần mở rộng đ
Đ
Một gói là một tập định\r\ndanh các yêu cầu an toàn. Một gói có thể là:
\r\n\r\n
Không được phép có\r\ncác gói hỗn hợp chứa cả SFR và SAR.
\r\n\r\nMột gói có thể được định\r\nnghĩa bởi bất kỳ bên nào và dự kiến là có thể tái sử dụng. Để đạt được mục tiêu\r\nnày, nó cần chứa các yêu cầu hữu ích và hiệu quả kết hợp với nhau. Các gói có\r\nthể được dùng trong kiến thiết các gói lớn hơn, các PP và ST. Hiện tại không có\r\ntiêu chí nào cho việc đánh giá các gói, do vậy bất kỳ tập SAR hay SFR có thể là\r\nmột gói.
\r\n\r\nVí dụ về các gói đảm\r\nbảo như: các mức đảm bảo đánh giá (EAL) được định nghĩa trong TCVN 8709-3. Hiện\r\ntại, chưa có các gói chức năng cho phiên bản tiêu chuẩn\r\nnày.
\r\n\r\n\r\n\r\nTrong khi một ST luôn\r\nmô tả một TOE nhất định (ví dụ thiết bị tường lửa FW MinuteGap V18.5), một PP dự\r\nkiến mô tả một kiểu TOE (ví dụ các tường lửa). Cũng PP này do đó có thể sử dụng\r\nlàm bản mẫu cho nhiều ST khác để sử dụng trong các phép đánh giá khác nhau. Mô\r\ntả chi tiết của các PP được đưa ra trong Phụ lục B.
\r\n\r\nNói chung, một ST mô\r\ntả các yêu cầu cho một TOE, và được viết bởi nhà\r\nphát triển TOE này, trong khi đó một PP mô tả các yêu cầu chung co một kiểu\r\nTOE, và do đó thường được viết bởi:
\r\n\r\n
PP xác định kiểu được\r\nphép cho tính tuân thủ của ST với PP. Nghĩa là PP công bố (trong phát biểu tuân\r\nthủ PP, sem B.5) rằng các kiểu tuân thủ được phép cho ST là:
\r\n\r\n
Tường trình lại điều\r\ntrên theo một cách nói khác, một ST chỉ được phép tuân thủ trong một PP theo
Nếu một ST đòi hỏi sự\r\ntuân thủ với nhiều PP, nó cần tuân thủ (như đã mô tả ở trên) cho mỗi PP theo\r\ncách được quy định bởi PP này. Điều này có thể nghĩa là ST tuân thủ chặt chẽ với\r\nmột số PP và có thể diễn giải tới các PP khác.
\r\n\r\nLưu ý rằng hoặc ST\r\ntuân thủ theo PP trong yêu cầu hoặc nó không tuân thủ. TCVN 8709 không chấp thuận\r\ntính tuân thủ “từng phần”. Do đó, trách nhiệm của tác giả PP là đảm bảo PP\r\nkhông phiền hà thái quá, ngăn cấm tác giả PP/ST trong đòi hỏi tuân thủ theo PP.
\r\n\r\nMột ST tương đương hoặc\r\ngới hạn hơn nhiều so với một P nếu:
\r\n\r\n
Hay nói một cách thân\r\nthuộc hơn, ST cần tập trung cùng hoặc nhiều hạn chế hơn ở TOE và cùng hoặc
Phát biểu chung này\r\ncó thể được tạo ra một cách đặc trưng hơn cho nhiều khoản mục khác nhau của ST\r\nnhư sau:
\r\n\r\nĐịnh nghĩa vấn đề an\r\ntoàn: Sở cứ tuân thủ trong ST cần diễn giải rằng định nghĩa v
Các mục tiêu an toàn:
Nếu tính tuân thủ chặt\r\nchẽ cho các hồ sơ bảo vệ được chỉ ra, thì các yêu cầu sau sẽ áp dụng:
\r\n\r\na) Định\r\nnghĩa vấn đề an toàn: ST cần chứa định nghĩa vấn đề\r\nan toàn của PP, có thể chỉ ra các mối đe dọa bổ sung và các OSPs,\r\nsong có thể không chỉ ra các giả thiết bổ\r\nsung.
\r\n\r\nb)
c)
Nếu tính tuân thủ có\r\nthể biểu diễn được cho các hồ sơ bảo vệ được chỉ ra, thì các yêu cầu sau sẽ được\r\náp dụng:
\r\n\r\n
Đánh giá PP là tùy ý.\r\nViệc đánh giá được thực hiện qua việc áp dụng\r\ncác tiêu chí APE cho chúng như liệt kê trong TCVN 8709-3. Mục đích của việc\r\nđánh giá như vậy là để diễn giải rằng PP là hoàn tất, nhất\r\nquán, và và phù hợp về mặt kỹ thuật, thích hợp để dùng làm bản mẫu cho việc tạo\r\nra PP hoặc một ST khác.
\r\n\r\nTạo ra một PP/ST dựa\r\ntrên một PP đã đánh giá có hai ưu điểm:
\r\n\r\n
Nếu một ST đòi hỏi được\r\ntuân thủ theo một hoặc nhiều gói và/hoặc các Hồ sơ bảo vệ, việc đánh giá ST này\r\nsẽ (theo như các đặc tính khác của ST) diễn giải rằng ST thực tế tuân thủ với\r\ncác gói này và/hoặc các PP mà chúng đòi hỏi tuân thủ theo. Chi tiết về việc xác\r\nđịnh tính tuân thủ này được nêu trong Phụ lục A.
\r\n\r\nĐiều trên cho phép tiến\r\ntrình sau đây:
\r\n\r\na) Một\r\ntổ chức tìm kiếm thu thập một kiểu cá biệt về sản phẩm an toàn CNTT, thực hiện\r\nxây dựng các nhu cầu an toàn của nó trong một PP, tiếp đó đánh giá n
b) Một\r\nnhà phát triển lấy PP này, viết một ST yêu cầu tuân thủ theo PP và đã đánh giá\r\nST này;
\r\n\r\nc) Nhà\r\nphát triển tiếp đó tạo ra một TOE (hoặc sử dụng một TOE có sẵn) và thực hiện\r\nđánh giá theo ST.
\r\n\r\nKết quả lả nhà phát\r\ntriển có, thể chứng minh rằng TOE của hj tuân thủ\r\ntheo các nhu cầu an toàn của tổ chức. Do vậy, tổ chức đạt được TOE này. Cách\r\ntương tự cũng được áp dụng cho các gói.
\r\n\r\nTCVN 8709 cũng cho\r\nphép các PP tuân thủ theo các PP khác, cho phép kiến thiết chuỗi các PP, mỗi\r\ncái dựa vào một cái (hoặc nhiều cái) trước đó.
\r\n\r\nVí dụ, có thể lấy một\r\nPP cho một mạch tổ hợp và một PP cho một OS\r\ndùng thẻ thông minh, và dùng chúng để
Phần này trình b
Các ST có thể dựa\r\ntrên các gói, các PP đã đánh giá hoặc các PP chưa\r\nđánh giá. Tuy nhiên, điều này không bắt buộc vì các ST không cần phải dựa trên\r\nmột thứ gì cả.
\r\n\r\nViệc đánh giá nên dẫn\r\ntới các kết quả khách quan và nhắc lại được để được coi l
Một kết quả đánh giá\r\nthể hiện việc tìm ra một kiểu xác định cho điều tra các đặc tính an toàn của một\r\nTOE. Một kết quả như vậy không tự động bảo đảm tính phù hợp cho sử dụng trong bất\r\nkỳ môi trường ứng dụng đặc biệt nào. Quyết định\r\nchấp nhận một TOE để sử dụng trong một môi trường ứng dụng đặc trưng dựa trên\r\ncơ sở xem xét nhiều vấn đề an toàn, bao gồm cả những kết luận\r\nđánh giá.
\r\n\r\nTCVN 8709-3 chứ
Các kết quả đánh giá PP\r\ncần chứa “Tuyên bố tuân thủ” (xem 9.4).
\r\n\r\nTCVN 8709-3 chứa các\r\ntiêu chí đánh giá mà một đánh giá viên bắt buộc phải tham khảo để xác định
Có thể có trường hợp\r\ncác kết quả đánh giá được sử dụng tiếp đó trong một tiến trình xác nhận, song\r\ntiến trình này nằm ngoài phạm vi của TCVN 8709.
\r\n\r\n\r\n\r\nTuyên bố tuân thủ chỉ\r\nra nguồn tập hợp các yêu cầu được thoả mãn cho một PP hay ST đã vượt qua bước\r\nđánh giá. Tuyên bố tuân thủ này chưa một tuyên bố tuân thủ TCVN 8709 như sau:
\r\n\r\na) Mô tả\r\nphiên bản TCVN 8709 mà PP hay ST tuân thủ theo.
\r\n\r\nb) Mô tả\r\nsự tuân thủ theo TCVN 8709-2 (các yêu cầu chức năng an toàn) là:
\r\n\r\n
c) Mô tả\r\nsự tuân thủ theo TCVN 8709-3 (các yêu cầu đảm bảo an toàn) là:
\r\n\r\n
Ngoài ra, Tuyên bố\r\ntuân thủ có thể bao gồm cả một phát biểu liên quan đ
Lưu ý rằng khi một\r\nTOE đã đánh giá thành công theo một ST, bất kỳ một tuyên bố tuân thủ nào của ST\r\ncũng sẽ dùng được cho TOE. Một TOE như vậy có thể ví dụ là tuân thủ theo TCVN\r\n8709-2.
\r\n\r\nCuối cùng, tuyên bố\r\ntuân thủ cũng chứa hai phát biểu sau đây liên quan đến Hồ s
a) Tuân\r\nthủ PP: Một PP hay TOE thoả mãn các PP(s) xác định như đã được liệt\r\nkê là một phần của kết quả tuân thủ.
\r\n\r\nb) Phát\r\nbiểu tuân thủ (chỉ cho PPs): Phát biểu này mô tả cách thức mà các PP hay\r\ncác ST tuân thủ theo PP này, chặt chẽ hay diễn giải được.\r\nXem Phụ lục B để có thêm thông tin về phát biểu tuân
Một khi một ST và một\r\nTOE đã được đánh giá, chủ sở hữu tài sản có thể\r\ncó sự đảm bảo (như đã định nghĩa trong ST) rằng TOE, cùng với\r\nmôi trường vận hành, chống lại được các mối đe dọa. Các kết quả đánh giá có thể\r\nđược dùng bởi chủ sở hữu tài sản để ra quyết định về việc có chấp nhận rủi ro\r\nphơi bày tài sản trước các mối đe dọa hay không.
\r\n\r\nTuy nhiên, chủ sở hữu\r\ntài sản nên thận trọng kiểm tra xem:
\r\n\r\n
Nếu không có điều nào\r\ntrên là đúng, TOE có thể không thích hợp cho các mục đích của chủ sở hữu tài
Ngoài ra, một khi một\r\nTOE đã đánh giá đang hoạt đông, vẫn có khả năng các lỗi không biết trước đó, hoặc\r\ncác điểm yếu trong TOE có thể lộ diện. Trong trường hợp này, nhà phát triển có\r\nthể sửa TOE (để sửa chữa các điểm yếu) hoặc thay đổi ST để
Nếu như cảm thấy cần\r\nthiết phải lấy lại sự tin cậy, việc đánh giá lại là cần thiết. TCVN 8709 có thể\r\nđược sử dụng để thực hiện đánh giá lại, song các thủ tục chi tiết cho việc đánh\r\ngiá lại nằm ngoài phạm vi phần này của tiêu chuẩn TCVN 8709.
\r\n\r\n\r\n\r\n
A.1
Phụ lục này giải\r\nthích khái niệm Đích an toàn (ST). Phụ lục này không định nghĩa các tiêu chí\r\nASE; định nghĩa này có thể tìm thấy trong TCVN 8709-3 và các tài liệu đã cho\r\ntrong tài liệu tham khảo.
\r\n\r\nPhụ lục này gồm bốn\r\nphần chính sau:
\r\n\r\na) Một\r\nST phải có những gì. Điều này được tóm tắt trong A.2, và được\r\nmô tả chi tiết hơn trong A.4 đến A.10. Các mục nhỏ này mô tả các nội dung bắt\r\nbuộc của ST, các mối quan hệ bên trong giữa các nội dung này và đưa ra các ví dụ.
\r\n\r\nb) Một\r\nST nên được sử dụng thế nào. Điều này được tóm tắt\r\ntrong A.3, và được mô tả chi tiết trong A.11. Mục này mô tả một ST nên được sử\r\ndụng như thế nào, và một số câu hỏi có thể được trả lời với một ST.
\r\n\r\nc) Các\r\nST mức đảm bảo thấp. Các ST này là các ST có nội dung được\r\ngiản bớt. Chúng được mô tả chi tiết trong A.12
\r\n\r\nd) Tuyên\r\nbố tuân thủ theo tiêu chuẩn
A.2 Những nội dung bắt\r\nbuộc của một ST
\r\n\r\nHình A.1 miêu tả những\r\nnội dung bắt buộc của ST được đưa ra trong TCVN 8709-3. Hình A.1 cũng có thể được\r\ndùng làm một phác thảo cấu trúc của ST, qua đó cho phép lựa chọn các cấu trúc\r\nkhác nhau. Ví dụ, nếu sở cử các yêu cầu an toàn đặc biệt lớn, nó có thể được\r\nđưa vào trong một phụ lục của ST thay vì đưa vào trong mục nhỏ về các yêu cầu\r\nan toàn. Mỗi mục con riêng biệt của một ST và nội dung của những mục đó được\r\ntóm tắt ngắn gọn ở dưới và được giải thích chi tiết hơn trong A.4 tới A.10. Một\r\nST thông thường bao gồm:
\r\n\r\na) Giới\r\nthiệu về ST gồm ba mô tả tường thuật về TOE
b) Định\r\nnghĩa vấn đề an toàn, chỉ ra các mối đe dọa, OSP\r\nvà những giả định.
\r\n\r\nc) Các\r\nmục tiêu an toàn, chỉ ra giải pháp cho vấn đề an toàn được\r\nphân chia giữa các mục tiêu an toàn cho TOE và các mục tiêu an toàn cho môi trường\r\nvận hành của TOE thế nào;
\r\n\r\nd) Định\r\nnghĩa các thành phần mở rộng (Tùy chọn),
e) Những\r\nyêu cầu an toàn, nơi chuyển đổi các mục tiêu an toàn\r\ncho TOE sang một ngôn ngữ được chuẩn hóa. Ngôn ngữ chuẩn hóa này dưới dạng các\r\nSFR. Thêm vào đó, nó định nghĩa các SAR
\r\n\r\nf) Đặc\r\ntả tóm tắt TOE, cho thấy các SFR được thực thi thế nào\r\ntrong TOE.
\r\n\r\nHiện cũng tồn tại các\r\nST đảm bảo thấp đã giảm bớt nội dung, chúng\r\nđược mô tả chi tiết trong A.12. Tất cả các phần khác của phụ lục này giả định một\r\nST với đầy đủ nội dung.
\r\n\r\nA.3
A.3.1
Một ST điển hình đáp ứng\r\nhai vai trò sau:
\r\n\r\n Trước\r\nvà trong suốt khi đánh giá, ST xác định “cái gì được đánh giá". Trong vai\r\ntrò này, ST phục vụ như nền tảng cơ bản cho việc thỏa thuận\r\ngiữa nhà phát triển và đánh giá viên trên các đặc tính an toàn chính xác của\r\nTOE và phạm vi chính xác của việc đánh giá. Tính đúng đắn và hoàn chỉnh về mặt\r\nkỹ thuật là những vấn đề chính trong vai trò này.\r\nĐiều A.7 mô tả một ST được sử dụng thế nào trong\r\nvai trò này.
\r\n\r\n Sau\r\nkhi đánh giá, ST xác định “cái gì đã được đánh giá”. Trong vai trò này, ST phục\r\nvụ như nền tảng cơ bản cho sự thỏa thuận giữa nhà\r\nphát triển hay người bán lại TOE và người tiêu dùng tiềm
A.3.2 Cách một ST\r\nkhông nên sử dụng
\r\n\r\nCó hai vai trò (trong\r\nsố nhiều vai trò) mà một ST không nên đáp ứng là:
\r\n\r\n Một\r\nđặc tả chi tiết: Một ST được thiết kế là một đặc tả an toàn ở một mức cao\r\ntương đối về sự trừu tượng. Một ST, nói chung, không ch
Một\r\nđặc tả đầy đủ: Một ST được thiết kế là một đặc tả an toàn và không phải là\r\nmột đặc tả tổng quát. Ngoại trừ chức năng an toàn liên quan, các đặc tính như\r\nkhả năng tương tác, kích cỡ và trọng lượng vật lý, điện thế yêu cầu..v.v có thể\r\nlà một phần của ST. Điều này có nghĩa một ST nói chung có thể là một phần của một\r\nđặc tả hoàn chỉnh, nhưng bản thân nó không phải là một đặc tả hoàn chỉnh.
\r\n\r\nA.4 Giới thiệu ST\r\n(ASE_INT)
\r\n\r\nGiới thiệu về ST mô tả\r\nTOE trên ba mức trừu tượng:
\r\n\r\na) Tham\r\nchiếu ST và tham chiếu TOE: cung cấp tư liệu nhận dạng ST và TOE mà ST tham chiếu\r\ntới;
\r\n\r\nb) Tổng\r\nquan về TOE: mô tả tóm tắt về TOE;
\r\n\r\nc) Mô tả\r\nTOE: mô tả chi tiết hơn về TOE;
\r\n\r\nA.4.1 Tham chiếu ST\r\nvà tham chiếu TOE
\r\n\r\nMột ST gồm có phần\r\ntham chiếu rõ ràng về ST xác định cho từng ST cụ thể. Một ST điển hình bao gồm\r\ntựa đề, phiên bản, các tác giả và ngày phát hành. Ví dụ về một tham chiếu ST\r\nnhư sau “MauveRAM Database ST, phiên bản 1.3, Nhỏm MauveCorp Speci
Một ST cũng bao gồm cả\r\ntham chiếu TOE để định danh TOE, đòi hỏi tuân thủ với ST đ
Nếu TOE được tạo nên\r\ntừ một hoặc nhiều sản phẩm nổi tiếng, sẽ được phép thể hiện điều đó trong phần\r\ntham chiếu TOE, bằng cách tham chiếu đến tên (các) sản phẩm. Tuy nhiên, điều đó\r\nkhông nên dùng để gây nhầm lẫn cho khách hàng: các trường hợp trong đó những phần\r\nchính hay những chức năng an toàn không được\r\nxem xét trong đánh giá, do đó tham chiếu TOE không phán ánh điều này, là không\r\nđược phép.
\r\n\r\nTham chiếu ST và tham\r\nchiếu TOE tạo điều kiện cho việc lập chỉ mục, tham chiếu đến ST và TOE và đưa\r\nchúng vào tóm tắt danh sách các TOE/ các sản phẩm đã được đánh giá,
\r\n\r\nA.4.2 Tổng quan về\r\nTOE
\r\n\r\nTổng quan TOE nhằm hướng\r\ntới những khách hàng tiềm năng của TOE, giúp họ lướt nhanh qua danh mục các\r\nTOE/các sản phẩm đã đánh giá để tìm kiếm các TOE có khả năng đáp ứng cho nhu cầu\r\nan toàn của họ, và được hỗ trợ bởi phần cứng, phần mềm và phần sụn của chúng.\r\nChiều dài thông thường của phần tổng quan TOE khoảng vài đoạn văn bản.
\r\n\r\nCuối cùng, phần tổng\r\nquan TOE mô tả tóm tắt cách sử dụng TOE và những đặc điểm an toàn chính của nó,\r\nchỉ rõ loại TOE và xác định bất kỳ phần cứng/phần mềm/phần sụn chủ yếu nào phi-\r\nTOE được yêu cầu bởi TOE.
\r\n\r\nA.4.2.1 Cách sử dụng\r\nvà các đặc điểm an toàn chính của một TOE
\r\n\r\nViệc mô tả cách sử dụng\r\nvà các đặc điểm an toàn chính của TOE chủ ý đưa ra một ý tường chung về việc\r\nTOE có khả năng về an toàn thế nào, và nó có thể sử dụng trong một ngữ cảnh an\r\ntoàn thế nào. Nên biên soạn chúng cho những khách hàng (tiềm năng) của TOE, mô\r\ntả cách sử dụng TOE và các đặc điểm an toàn chính theo các hoạt động kinh\r\ndoanh, sử dụng ngôn ngữ mà khách hàng TOE hiểu được.
\r\n\r\nVí dụ “MauveCorp\r\nMauveRAM Database v2.11 là một cơ sở dữ liệu nhiều người dùng được hướng đến việc\r\nsử dụng trong một môi trường mạng. Nó cho phép 1024 người dùng sử dụng đồng thời.\r\nNó cho phép xác thực mật khẩu/thẻ và sinh trắc học, bảo vệ chống lại việc dữ liệu\r\nbị hư hỏng đột ngột, và có thể kéo lại 10 nghìn giao dịch. Các đặc điểm kiểm chứng\r\ncủa nó có khả năng cấu hình cao, do đó cho phép thực hiện kiểm chứng chi tiết\r\ncho một số người dùng và giao dịch trong khi bảo vệ quyền riêng tư của những\r\nngười dùng và giao dịch khác."
\r\n\r\nA.4.2.2 Kiểu TOE
\r\n\r\nPhần tổng quan TOE\r\nxác định kiểu TOE chung, chẳng hạn như: tường lửa, tưởng lửa VPN, thẻ thông\r\nminh, modem mã hóa, intranet, web server, cơ sở dữ liệu, web server và cơ sở dữ\r\nliệu, LAN, LAN với web server và cơ sở dữ liệu, v.v...
\r\n\r\nCó thể có trường hợp\r\nTOE không phải là kiểu sẵn sàng để dùng, trong trường hợp này từ “không” ghi\r\ncho kiểu TOE được chấp thuận.
\r\n\r\nTrong một vài trường\r\nhợp , một kiểu TOE có thể làm cho các khách hàng nhầm lẫn. Ví dụ:
\r\n\r\n Chức\r\nnăng nào đó có thể được mong đợi ở TOE\r\ndo kiểu TOE của nó, nhưng TOE đó không có chức năng này. Ví dụ:
\r\n\r\n+ Một TOE kiểu thẻ\r\nATM không hỗ trợ bất kỳ chức năng định danh/xác thực nào;
\r\n\r\n+ Một TOE kiểu\r\nfirewall không hỗ trợ các giao thức được sử dụng hầu như phổ biến;
\r\n\r\n+ Một TOE kiểu PKI\r\nkhông có chức năng thu hồi chứng chỉ.
\r\n\r\n. TOE có thể được\r\nmong đợi hoạt động trong những môi trường vận hành nhất đ
+ Một TOE kiểu hệ điều\r\nhành PC không có khả năng hoạt động an toàn trừ khi PC đó không kết nối mạng,\r\nkhông có ổ đĩa mềm và không có ở đĩa CD/DVD-player;
\r\n\r\n+ Một tường lửa không\r\ncó khả năng hoạt động an toàn trừ khi tất cả người dùng có kết nối qua tường lửa\r\nnày đều là những người không phải là tin tặc.
\r\n\r\nA.4.2.3 Phần cứng/phần\r\nmềm/phần sụn phi- TOE cần\r\nthiết
\r\n\r\nTrong khi một số TOE\r\nkhông dựa vào CNTT
Ví dụ về các định\r\ndanh phần cứng/phần mềm/phần sụn này là:
\r\n\r\n. Một PC chuẩn với bộ\r\nxử lý 1GHz hoặc nhanh hơn và RAM 512MB hoặc hơn, chạy phiên b
Một\r\nPC chuẩn với bộ xử lý 1GHz hoặc nhanh hơn và RAM 512MB hoặc hơn, chạy phiên bản\r\n3.0 Update 6b, c hoặc 7 hoặc phiên bản 4.0 của hệ điều hành Yaiza và cạc đồ họa\r\nWonderMagic 1.0 với bộ Driver WM 1.0;
\r\n\r\n
Một\r\nmạch tích hợp CleverCard SB2067;
\r\n\r\n Một\r\nmạch tích hợp CleverCard SB2067 chạy v2.0 của hệ điều hành thẻ thông minh\r\nQuickOS;
\r\n\r\n Bản\r\ncài đặt cài đặt mạng LAN tháng 12 năm 2002 của Văn phòng Giám Đốc Sở Giao\r\nThông.
\r\n\r\nA.4.3 Mô tả TOE
\r\n\r\nMột mô tả TOE l
Mô tả TOE bàn đến phạm\r\nvi vật lý của TOE: danh sách tất cả các phần cứng, phần mềm, phần sụn và các phần\r\nhướng dẫn tạo thành TOE. Danh sách này nên được mô tả
Mô tả TOE cũng nên\r\nbàn về phạm vi logic của TOE: các đặc điểm an toàn về mặt
Một đặc tính quan trọng\r\nvề phạm vi vật lý và logic của TOE là chúng mô tả TOE theo cách mà ở đó không\r\ncó sự hồ nghi nào về việc một phần hay một đặc điểm nào đó là trong TOE hay\r\nkhông, hoặc phần đó hay đặc điểm
Các ví dụ về việc TOE\r\nđược kết hợp với các thực thể phi-TOE là:
\r\n\r\n TOE\r\nlà một bộ đồng xử lý mật mã của IC thẻ thông minh, thay vì toàn bộ IC;
\r\n\r\n TOE\r\nlà một IC thẻ thông minh, ngoại trừ bộ xử lý mật mã;
\r\n\r\n TOE\r\nlà phần chuyển đổi địa chỉ mạng (NAT) của MinuteGap Firewall
A.5 Các tuyên b
Mục này của một ST mô\r\ntả cách thức ST tuân thủ với:
\r\n\r\n Phần\r\n2 và Phần 3 của Tiêu chuẩn này;
\r\n\r\n Hồ\r\nsơ bảo vệ (nếu có);
\r\n\r\n Các\r\ngói (nếu có);
\r\n\r\nCác mô tả về cách ST\r\ntuân thủ với TCVN 8709 bao gồm hai phần: phiên bản của ISO /IEC 15408 đã sử dụng\r\nvà liệu các ST có chứa các yêu cầu an toàn mở rộng hay không (xem A.8).
\r\n\r\nCác mô tả về sự tuân\r\nthủ của ST với Hồ sơ Bảo vệ, có nghĩa là ST liệt kê các gói đang yêu cầu tuân\r\nthủ. Để giải thích về điều này, xem 9.4.
\r\n\r\nCác mô tả về sự tuân\r\nthủ của ST với các gói, có nghĩa là ST liệt kê các gói đang yêu cầu tuân thủ. Để\r\ngiải thích về điều này, xem 9.4.
\r\n\r\nA.6 Định nghĩa vấn đề\r\nan toàn (ASE_SPD)
\r\n\r\nA.6.1 Giới thiệu
\r\n\r\nĐịnh nghĩa vấn đề an\r\ntoàn xác định vấn đề an toàn cần đề cập đến. Định nghĩa vấn đề an toàn là một\r\nđiều hiển nhiên trong TCVN 8709. Như vậy, quá trình đi đến định nghĩa vấn đề an\r\ntoàn nằm ngoài phạm vi của TCVN 8709.
\r\n\r\nTuy nhiên, cần lưu ý\r\nrằng, tính hữu ích của kết quả đánh giá phụ thuộc\r\nrất nhiều vào ST, và tính hữu ích của ST phụ thuộc nhiều vào chất lượng của định\r\nnghĩa vấn đề an toàn. Do đó
Lưu ý rằng theo TCVN\r\n8709-3, không bắt buộc phải có các phát biểu trong tất cả các mụ
Cũng lưu ý rằng tại\r\nnhững nơi TOE được phân phối về mặt vật lý, tốt hơn là nên bàn về các mối đe dọa\r\nliên quan, các OSP và các giả định riêng rẽ cho các miền riêng biệt của môi trường\r\nvận hành TOE.
\r\n\r\nA.6.2 Các m
Mục này của định\r\nnghĩa vấn đề an toàn chỉ ra các mối đe dọa được tính đến bởi TOE, môi trường vận\r\nhành của TOE, hay kết hợp của cả hai.
\r\n\r\nMột mối đe dọa bao gồm\r\nmột hành động có hại được thực hiện bới một tác nhân gây nguy cơ trên một tài sản.
\r\n\r\nNhững hành động có hại\r\nlà những hành động thực hiện bởi một tác nhân gây nguy cơ trên một tài sản. Những\r\nhành động này ảnh hưởng đến một hoặc nhiều đặc tính của một tài sản mà giá tr
Những tác nhân gây\r\nnguy cơ có thể được mô tả như những thực thể riêng, nhưng trong một số trường hợp\r\nsẽ tốt hơn nếu mô tả chúng theo từng loại thực thể, các nhóm thực thể, v.v...
\r\n\r\nVí dụ về các tác nhân\r\ngây hại là những tin tặc, người dùng, các tiến trình máy tính, và các tai họa.\r\nNhững tác nhân gây hại có thể được mô tả hơn nữa về các mặt như kinh nghiệm,\r\nnguồn lực, cơ hội và động lực.
\r\n\r\nVí dụ về các mối đe dọa\r\nlà:
\r\n\r\n
A.6.3 Các chính sách\r\nan toàn của tổ chức tổ chức (OSPs)
\r\n\r\nMục này trong định\r\nnghĩa vấn đề an toàn cho thấy OSP cần được thực thi b
OSP là những quy tắc,\r\nthủ tục, hoặc hướng dẫn an toàn được áp đặt (hoặc coi là sẽ áp đặt) hiện tại\r\nvà/hoặc trong tương lai bởi một tổ chức thực tế hoặc giả thuyết trong môi trường\r\nvận hành. OSP có thể được đặt ra bởi một\r\ntổ chức kiểm soát môi trường vận hành của TOE, hoặc chúng có thể được đặt ra bởi\r\ncác cơ quan lập pháp hay điều tiết. OSP có thể áp dụng cho các TOE và / hoặc\r\nmôi trường vận hành của các TOE.
\r\n\r\nVí dụ về các OSP là:
\r\n\r\n
A.6.4 Các giả định
\r\n\r\nMục này của định\r\nnghĩa vấn đề an toàn chỉ ra các giả định cho môi trường vận hành để có thể cung\r\ncấp chức năng an toàn. Nếu TOE được đặt trong một môi trường vận hành không đáp\r\nứng được các giả định này, thì TOE có thể không có khả năng cung cấp tất cả các\r\nchức năng an toàn nữa. Những giả định có thể về mặt vật lý, con người và kết nối\r\ncủa môi trường vận hành.
\r\n\r\nVí dụ về các giả định\r\nlà:
\r\n\r\n
- Giả định\r\nlà TOE sẽ được đặt trong một căn phòng được thiết kế để giảm thiểu phát xạ điện\r\ntừ;
\r\n\r\n- Giả\r\nđịnh là các bàn điều khiển quản trị của TOE sẽ được đặt\r\ntrong một khu vực hạn chế truy
- Giả định\r\nlà người dùng TOE sẽ được đào tạo đầy đủ để vận hành TOE;
\r\n\r\n- Giả\r\nđịnh là người dùng TOE chấp thuận những thông tin được phân loại là Bí mật Quốc\r\ngia;
\r\n\r\n- Giả\r\nđịnh là người dùng TOE sẽ không viết ra mật khẩu của họ.
\r\n\r\n
- Giả\r\nđịnh là một máy trạm PC có ít nhất 10GB không gian đĩa sẵn cho việc chạy TOE\r\ntrên đó;
\r\n\r\n- Giả\r\nđịnh là TOE là ứng dụng phi-OS duy nhất đang chạy trên máy trạm này;
\r\n\r\n- Giả\r\nđịnh là TOE sẽ không kết nối với một mạng không tin cậy.
\r\n\r\nLưu ý rằng trong quá\r\ntrình đánh giá, những giả định này được coi là đúng: chúng không được kiểm tra\r\ntheo bất kỳ cách nào. Vì những lý do này, các giả định chỉ có thể được tạo ra\r\ntrên môi trường vận hành. Những giả định có thể chưa bao giờ được tạo ra trên\r\nhành vi của TOE vì một đánh giá bao gồm
A.7 Các mục tiêu an\r\ntoàn (ASE_OBJ)
\r\n\r\nCác mục tiêu an toàn\r\nlà một phát biểu ngắn gọn và trừu tượng về giả
A.7.1 Giải pháp mức\r\ncao
\r\n\r\nCác mục tiêu an toàn\r\nbao gồm một tập hợp các phát biểu ngắn gọn và rõ ràng mà không quá chi tiết, phối\r\nhợp với nhau hình thành một giải pháp mức\r\ncao cho vấn đề an toàn. Mức độ trừu tượng của các mục tiêu an toàn\r\nnhằm vào tính rõ ràng và dễ hiểu giúp cho người tiêu dùng tiềm năng có thể hiểu\r\nđược TOE đó. Các mục tiêu an toàn thể hiện theo\r\nngôn ngữ tự nhiên.
\r\n\r\nA.7.2 Các giải pháp từng\r\nphần
\r\n\r\nTrong một ST, giải\r\npháp an toàn mức cao, như được mô tả với các mục tiêu an toàn, sẽ được chia\r\nthành hai giải pháp từng phần. Những giải pháp từng phần này được gọi là các mục\r\ntiêu an toàn cho TOE và các mục tiêu an toàn cho môi trường vận hành. Điều này\r\nphản ánh rằng các giải pháp từng phần sẽ được cung cấp bởi hai thực thể khác\r\nnhau: TOE, và môi trường vận hành.
\r\n\r\nA.7.2.1 Các mục tiêu\r\nan toàn cho TOE
\r\n\r\nTOE cung cấp chức\r\nnăng an toàn để giải quyết một phần nhất định của vấn đề được xác định trong định\r\nnghĩa vấn đề an toàn. Giải pháp từng phần này được gọi l
Ví dụ về các mục tiêu\r\nan toàn cho TOE là:
\r\n\r\n
Nếu TOE được phân phối\r\nvề mặt vật lý, tốt hơn là chia nhỏ điều khoản ST chứa các mục tiêu an toàn cho\r\nTOE thành một vài mục con để phản ánh điều này.
\r\n\r\nA.
Môi trường vận hành của\r\nTOE thực hiện các biện pháp kỹ thuật và thủ tục để hỗ trợ TOE cung cấp đúng chức\r\nnăng an toàn của nó (được định nghĩa bởi các mục tiêu an toà
Ví dụ về các mục tiêu\r\nan toàn đối với môi trường vận hành là:
\r\n\r\n
Nếu môi trường vận\r\nhành của TOE bao gồm nhiều địa điểm, mỗi địa điểm có những đặc tính khác nhau,\r\ntốt hơn là chia nhỏ điều khoản ST chứa các mục tiêu an toàn cho môi trường vận\r\nhành thành các mục nhỏ để phản ánh điều này.
\r\n\r\nA.
ST cũng chứa một s
A.
Dấu vết cho thấy cách\r\ncác mục tiêu toàn truy dấu vết các mối đe dọa, các OSP và các giả định như mô tả\r\ntrong định nghĩa vấn đề an toàn.
\r\n\r\na) Không\r\nmục tiêu giả mạo: Mỗi mục tiêu an toàn ghi vết theo ít\r\nnhất một mối đe dọa, một OSP hoặc một giả định.
\r\n\r\nb) Hoàn\r\nthành theo định nghĩa vấn đề an toàn: Mỗi mối đe dọa, OSP\r\nvà giả định có ít nhất một dấu vết mục tiêu an toàn ghi theo nó.
\r\n\r\nc) Ghi\r\nvết đúng: Vì những giả định luôn được tạo bởi TOE trên môi trường vận\r\nhành, các mục tiêu an toàn cho TOE không truy vết về những giả định. Các dấu vết\r\nđược phép trong TCVN 8709-3 được miêu tả trong Hình A.2.
\r\n\r\nNhiều mục tiêu an\r\ntoàn có thể ghi vết theo cùng mối đe dọa, biểu thị rằng sự kết hợp của các mục\r\ntiêu an toàn là để chống lại mối đe dọa đó. Một luận cứ tương\r\ntự cũng dùng cho các OSP và các giả định.
\r\n\r\nA.
Sở cứ cho các mục\r\ntiêu an toàn cũng diễn giải rằng việc ghi vết có hiệu quả: Tất cả các mối đe dọa,\r\ncác OSP và các giả định được đề cập đến (nghĩa là
Luận cứ này phân tích\r\ntác động của việc đạt được các mục tiêu an toàn tương ứng về việc chống lại các\r\nmối đe dọa, việc thực thi các OSP và duy trì các\r\ngiả định để đưa đến kết luận rằng luận cứ trên là đúng.
\r\n\r\nTrong một số trường hợp,\r\nkhi các phần của định nghĩa vấn đề an toàn rất giống với một số mục tiêu an\r\ntoàn, thì luận cứ có thể rất đơn giản. Một ví dụ là: một mối đe dọa "T17:\r\ntác nhân gây nguy cơ X đọc được các Thông tin Bí mật truyền qua lại giữa A và B",\r\nmột mục tiêu an toàn cho TOE: "OT12: TOE phải đảm bảo rằng tất cả các\r\nthông tin được truyền giữa A và B được giữ bí mật", và một luận cứ “T17 được\r\nđối phó trực tiếp bằng OT12”
\r\n\r\nA.
Chống lại một mối đe\r\ndọa không cần thiết có nghĩa lả loại bỏ mối đe dọa đó, nó có thể cũng nghĩa là\r\ngiảm thiểu mối đe dọa đó, hoặc giảm nhẹ mối đe dọa.
\r\n\r\nVí dụ về loại bỏ một\r\nmối đe dọa là:
\r\n\r\n
Ví dụ về làm giảm nhẹ\r\nmột mối đe dọa là:
\r\n\r\n
Giảm\r\nđộng lực để thực hiện một hành động có hại của một tác nhân gây hại bằng cách\r\nlàm nhụt chí;
\r\n\r\n
Ví dụ về giảm tác động\r\ncủa một mối đe dọa là:
\r\n\r\n
A.
Căn cứ vào các mục\r\ntiêu an toàn và sở cứ các mục tiêu an toàn an toàn, kết luận\r\nsau đây có thể được rút ra: nếu tất cả các mục tiêu an toàn đạt được thì vấn đề\r\nan toàn như đã định nghĩa trong ASE_SPD được giải quyết: tất cả các mối đe dọa\r\nsẽ được chống lại, tất cả các OSP được\r\nthi hành, và tất cả các giả đ
A.
Trong nhiều trường hợp,\r\ncác yêu cầu an toàn (xem A.9) trong một ST dựa trên các thành phần trong TCVN\r\n8709-2 hoặc TCVN 8709-2. Tuy nhiên, trong một số trường hợp, có thể có các yêu\r\ncầu trong một ST không dựa trên các thành phần trong TCVN 8709-2 hoặc TCVN\r\n8709-2. Trong trường hợp này, các thành phần mới (các thành phần mở rộng) cần\r\nđược định nghĩa, và việc định nghĩa này nên thực hiện trong phần “Định nghĩa\r\ncác thành phần mở rộng”. Để có thêm thông tin, xem Phụ lục\r\nC.4.
\r\n\r\nLưu ý rằng, mục này\r\nchỉ bao gồm các thành phần mở rộng và chứ không gồm\r\nnhững yêu cầu mở rộng (những yêu cầu dựa trên các thành\r\nphần mở rộng). Những yêu cầu mở rộng sẽ được đặt\r\ntrong những yêu cầu an toàn (xem A.9) và cũng là những yêu cầu dựa trên các\r\nthành phần trong TCVN 8709-2 hoặc TCVN 8709-3 đối với mọi mục đích.
\r\n\r\nA.
Các yêu cầu an toàn\r\nbao gồm hai nhóm sau:
\r\n\r\na) Các\r\nyêu cầu về chức năng an toàn (SFR): Chuyển đ
b) Các\r\nyêu cầu về đảm bảo an toàn (SAR): Mô tả cách đạt được sự đảm\r\nbảo là TOE đáp ứng các
Hai nhóm này được thảo\r\nluận trong A.9.1 và A.9.2.
\r\n\r\nA.
Các SFR là một bản dịch\r\ncủa các mục tiêu an toàn cho TOE. Chúng thường ở mức độ trừu tượng chi tiết\r\nhơn, nhưng chúng phải là một bản dịch hoàn chỉnh (các mục tiêu\r\nan toàn phải được đề cập đến một cách đầy đủ) và độc lập với bất kỳ giải pháp kỹ\r\nthuật cụ thể nào (sự thực thi). TCVN 8709 yêu cầu chuyển đổi sang một ngôn ngữ\r\nchuẩn hóa vì những lý do:
\r\n\r\n
Trong TCVN 8709 không\r\nyêu cầu có sự chuyển đổi cho các mục tiêu an toàn đối với môi trường vận hành,\r\nbởi vì không đánh giá môi trường vận hành và do đó không đòi hỏi việc mô tả nhằm\r\ncho việc đánh giá đó. Xem tài liệu tham khảo cho các danh mục liên quan đến\r\nđánh giá an toàn cho các hệ thống vận hành.
\r\n\r\nCó thể có trường hợp,\r\ncác phần của môi trường vận hành được đánh giá trong một đánh giá khác, nhưng\r\nđiều này nằm ngoài phạm vi đối với việc đánh giá hiện tại. Ví dụ: một TOE
A.
TCVN 8709 hỗ trợ việc\r\nchuyển đổi trên theo ba cách:
\r\n\r\na) Bằng\r\ncách cung cấp một "ngôn ngữ" rõ ràng xác định trước, dành cho việc mô\r\ntả chính xác những gì sẽ được đánh giá. Ngôn ngữ này cũng được định nghĩa là một\r\ntập các thành phần đã được định nghĩa trong TCVN 8709-2. Việc sử dụng ngôn ngữ\r\nnày để chuyển đổi rành mạch các mục tiêu an toàn cho TOE thành các SFR là bắt\r\nbuộc, cho dù tồn tại một số ngoại lệ (xem 7.3).
\r\n\r\nb) Bằng\r\ncách cung cấp các hoạt động: các cơ chế cho phép tác giả của ST sửa đổi các SFR\r\nđể cung cấp một bản dịch chính xác hơn cho\r\ncác mục tiêu an toàn cho TOE. Phần này của TCVN 8709 định nghĩa bốn hoạt động\r\nđược phép: Ấn định, lựa chọn, lặp lại, và bổ sung\r\nchi tiết. Những điều này sẽ được mô tả rõ hơn trong C.2.
\r\n\r\nc) Bằng\r\ncách đưa ra những phụ thuộc: một cơ chế hỗ trợ một bản dịch hoàn chỉnh hơn tới\r\ncác SFR. Trong ngôn ngữ TCVN 8709-2, một SFR có thể có một sự phụ thuộc vào các\r\nSFR khác. Điều này có ý nghĩa rằng, nếu một ST sử dụng một SFR đó, nó thường cần\r\nphải sử dụng cả những SFR khác đó. Điều này làm cho tác\r\ngiả của ST không dễ dàng để bỏ qua những SFR cần thiết và do đó cải thiện tính\r\nđầy đủ của các ST. Sự phụ thuộc được mô tả rõ hơn trong 7.2.
\r\n\r\nA.
ST cũng chứa một sở cứ\r\nvề những yêu cầu an toàn, bao gồm hai mục sau về SFR:
\r\n\r\n
A.
Dấu vết cho thấy các\r\nSFR truy vết các mục tiêu an toàn cho TOE như sau:
\r\n\r\na) Không\r\ncó SFR giả mạo: Mỗi dấu vết SFR truy vết tới ít nhất một\r\nmục tiêu an toàn.
\r\n\r\nb) Hoàn\r\nthành theo các mục tiêu an toàn cho TOE:
Nhiều SFR có thể ghi\r\nvết đến cùng một mục tiêu an toàn cho TOE, điều này chỉ ra rằng sự kết hợp của\r\nnhững yêu cầu an toàn an toàn sẽ đáp ứng được mục tiêu an toàn của TOE.
\r\n\r\nA.
Sở cứ cho những yêu cầu\r\nan toàn diễn giải rằng việc truy vết này có hiệu quả: nếu tất cả SFR truy vết đến\r\nmột mục tiêu an toàn cụ thể đối với TOE được thỏa mãn, thì mục tiêu an toàn của\r\nTOE sẽ đạt được.
\r\n\r\nLuận cứ trên nên phân\r\ntích những ảnh hưởng của việc thỏa mãn SFR có liên quan về việc đạt được các mục\r\ntiêu an toàn cho TOE và đưa đến kết luận luận cứ trên là đúng.
\r\n\r\nTrong các trường hợp\r\nSFR rất gần giống các mục tiêu an toàn cho TOE, thì luận cứ có thể rất đơn
A.
Các SAR là mô tả về việc\r\nTOE được đánh giá thế nào. Mô tả này sử dụng một ngôn ngữ chuẩn hóa vì hai lý\r\ndo sau:
\r\n\r\n
Chuẩn hóa ngôn ngữ\r\nnày được định nghĩa là một tập hợp các thành phần được định nghĩa trong TCVN\r\n8709-3. Việc sử dụng ngôn ngữ này là bắt buộc, mặc dù có một số ngoại lệ tồn tại.\r\nTCVN 8709 nâng cao ngôn ngữ này theo hai cách:
\r\n\r\na) cung\r\ncấp các hoạt động: các cơ chế cho phép tác giả
b) đưa\r\nra những phụ thuộc: một cơ chế hỗ trợ một bản dịch hoàn chỉnh hơn tới SFR.\r\nTrong ngôn ngữ TCVN 8709-2, một SFR có thể có một sự phụ thuộc vào các SFR\r\nkhác. Điều này có ý nghĩa rằng, nếu một ST sử dụng một SFR đó, nó thường cần phải\r\nsử dụng cả những SFR khác đó. Điều này làm cho tác giả của ST không dễ dàng để\r\nbỏ qua những SFR cần thiết và do đó cải\r\nthiện tính đầy đủ của các ST. Sự phụ thuộc được mô tả rõ hơn trong 7.2.
\r\n\r\nA.
ST cũng chứa một sở cứ\r\nvề các yêu cầu an toàn, giải thích lý do tại sao tập các SAR cụ thể này được\r\ncoi là thích hợp. Không có yêu cầu đặc trưng nào cho lời giải thích này. Mục\r\ntiêu cho lời giải thích này là để cho phép người đọc ST để hiểu lý do tại sao tập\r\nđó được chọn.
\r\n\r\nMột ví dụ về sự thiếu\r\nnhất quán là nếu mô tả vấn đề an toàn đề cập đến các mối đe dọa mà ở đó tác\r\nnhân gây hại là rất có khả năng, thì một ít (hoặc không) AVA_VAN được đưa vào\r\ntrong SAR.
\r\n\r\nA.
Trong định nghĩa vấn\r\nđề an toàn của ST, vấn đề an toàn được định nghĩa là bao gồm các mối đe dọa,\r\ncác OSP và các giả định. Trong điều khoản về các mục tiêu an toàn của ST, giải\r\npháp được đưa ra dưới dạng của hai giải pháp con:
\r\n\r\n
Ngoài ra, một sở cứ\r\ncác mục tiêu an toàn được đưa ra cho thấy rằng nếu tất cả các mục tiêu an toàn\r\nđạt được, thì vấn đề an toàn được giải quyết: tất cả các mối đe dọa sẽ được chống\r\nlại, tất cả các OSP được thực thi, và tất cả các giả định được gìn giữ.
\r\n\r\nTrong mục những yêu cầu\r\nan toàn của ST, các mục tiêu an toàn cho TOE được dịch sang SFR và sở cứ các\r\nyêu cầu an toàn được đưa ra cho thấy rằng nếu tất cả SFR được thỏa mãn, thì tất\r\ncả các mục tiêu an toàn cho TOE là đạt được.
\r\n\r\nNgoài ra, một bộ SAR\r\nđược cung cấp để thể hiện TOE được đánh giá thế nào, cùng với lời giải thích\r\ncho việc lựa chọn các SAR đó.
\r\n\r\nTất cả điều bên trên\r\ncó thể được kết hợp thành một phát biểu: Nếu tất cả SFR và S
Lượng bảo đảm đạt được\r\nđược định nghĩa bởi các SAR, và việc lượng này có đủ hay không được định nghĩa\r\nbởi phần giải thích về việc chọn các SAR\r\nnày.
\r\n\r\nA.
Mục tiêu đối với đặc\r\ntả tóm tắt TOE là cung cấp tới người tiêu dùng tiềm năng của TOE một mô tả về\r\nTOE thỏa mãn tất cả các SFR như thế nào. Đặc tả tóm\r\ntắt TOE nên đưa ra các cơ chế kỹ thuật chung mà TOE sử dụng cho mục đích này. Mức\r\nđộ chi tiết của mô tả đó nên đủ để cho phép người tiêu dùng tiềm năng hiểu được\r\nnhững dạng và sự thực thi chung của các TOE.
\r\n\r\nVí dụ nếu TOE là một\r\nPC trên Internet và các SFR chứa FIA_UAU.1 để đặc tả việc xác thực, đặc t
A.
Sau khi đánh giá, ST\r\nquy định "những gì được đánh giá". Trong vai trò này, ST phục vụ như\r\nmột cơ sở để thỏa thuận giữa các nhà phát triển hoặc người bán lại TOE và người\r\ntiêu dùng tiềm năng của các TOE đó. ST do đó có\r\nthể trả lời các câu hỏi sau đây (và nhiều hơn):
\r\n\r\na) Làm\r\nthế nào tôi có thể tìm thấy ST/TOE mà tôi cần\r\ntrong vô số những ST/TOE đang hiện tại được đưa ra? Câu hỏi này được đề cập\r\ntrong phần tổng quan TOE, trong đó đưa ra một tóm tắt ngắn gọn (khoảng vài đoạn\r\nvăn bản) cho TOE;
\r\n\r\nb) TOE\r\nnày có phù hợp với cơ sở hạ tầng CNTT hiện tại của tôi không?
c)
d)
e) TOE\r\nlàm gì (người tiêu dùng tiềm năng)? Câu hỏi này được đề\r\ncập trong phần tổng quan TOE, nó đưa ra một tóm tắt ngắn gọn (vài trang) về\r\nTOE;
\r\n\r\nf) TOE\r\nlàm gì (kỹ thuật viên)? Câu hỏi này được đề cập\r\ntrong phần đặc tả tóm tắt TOE, ở đó cung cấp
g) TOE\r\nlàm gì (chuyên gia)? Câu hỏi này được đề cập\r\ntrong các SFR, ở đó cung cấp một mô tả kỹ
h) TOE\r\ncó đề cập đến vấn đề theo quy định của chính phủ
i) Có\r\nTOE có đề cập đến vấn đề an toàn của tôi không (chuyên gia)?
j) Tôi có thể tin\r\ncậy TOE đến mức nào? Điều này có thể được tìm thấy trong các SAR ở mục những\r\nyêu cầu an toàn, ở đó cung cấp các cấp đảm bảo được sử dụng để đánh giá TOE, và\r\ndo đó độ tin cậy mà việc đánh giá cung cấp trong tính chính xác của TOE.
\r\n\r\nA.
Biên soạn một ST\r\nkhông phải là một công việc tầm thường, và có thể, đặc biệt l
TCVN 8709 cho p
Một ST đảm bảo thấp\r\ncó giảm đáng kể nội dung so với một ST thông thường:
\r\n\r\n
Tất cả những thứ ST vẫn\r\nduy trì là:
\r\n\r\na) Các\r\ntham chiếu tới TOE và ST;
\r\n\r\nb) Một\r\ntuyên bố tuân thủ;
\r\n\r\nc) Các\r\nmô tả tường tận khác nhau;
\r\n\r\n1) Tổng\r\nquan TOE;
\r\n\r\n2) Mô tả\r\nTOE;
\r\n\r\n3) Đặc\r\ntả tóm tắt TOE.
\r\n\r\nd) Các\r\nmục tiêu an toàn cho môi trường vận hành;
\r\n\r\ne) Các\r\nSFR và SAR (bao gồm cả định nghĩa các thành phần mở rộng) và sở cứ các yêu cầu\r\nan toàn (chỉ khi sự phụ thuộc không được thỏa mãn).
\r\n\r\nNội dung đã giản lược\r\ncủa một ST đảm bảo thấp được thể hiện trong Hình A.4.
\r\n\r\nA.
Trong một số trường hợp,\r\ntác giả biên soạn ST có thể muốn tham chiếu tới một tiêu chuẩn bên ngoài, chẳng\r\nhạn như một tiêu chuẩn hoặc giao thức mã hóa cụ thể. TCVN 8709 cho phép ba cách\r\nthực hiện sau:
\r\n\r\na) Như\r\nmột chính sách an toàn về mặt tổ chức (hoặc một phần của n
Nếu, chẳng hạn, tồn tại\r\nmột tiêu chuẩn chính phủ quy định mật khẩu phải được\r\nchọn ra sao, điều này có thể được phát biểu như một chính sách an toàn về tổ chức\r\ntrong một ST. Điều này có thể một đối tuợng cho môi trường (ví dụ nếu người sử\r\ndụng TOE cần chọn các mật khẩu phù hợp), hoặc nó có thể dẫn đến các mục tiêu an\r\ntoàn cho TOE và tiếp đó cho các SFR thích hợp (giống như
b) Như\r\nmột tiêu chuẩn kỹ thuật (ví dụ một tiêu chuẩn mật mã) được sử dụng trong một\r\nphép bổ sung chi tiết cho một SFR.
\r\n\r\nTrường hợp này, tuân\r\nthủ theo tiêu chuẩn là một phần của việc thỏa mãn các SFR bởi TOE và được xử lý\r\nnhư kiểu một văn bản đầy đủ của tiêu chuẩn là một phần của SFR. Tính tuân thủ\r\ntiếp đó được xác định giống như bất kỳ sự tuân thủ khác theo các SFR: trong ADV\r\nvà ATE, nó được phân tích, qua phân\r\ntích thiết kế và kiểm thử, để chỉ ra SFR là đầy đủ và được triển khai hoàn toàn\r\ntrong TOE. Nếu chỉ muốn tham chiếu tới một phần nhất định của tiêu chuẩn, thì\r\nphần đó cần được nêu rõ ràng trong phần bổ sung chi tiết trong SFR.
\r\n\r\nc) Như\r\nmột tiêu chuẩn kỹ thuật (ví dụ như một tiêu chuẩn mật mã) được đề cập trong đặc\r\ntả tóm tắt TOE.
\r\n\r\nĐặc tả tóm tắt TOE chỉ\r\nđược xem xét đến như một giải thích về cách các SFR được thực hiện, và sử dụng\r\nkhông chặt chẽ như một yêu cầu thực thi chặt chẽ giống như SFR hoặc các tài liệu\r\nchuyển giao cho ADV. Như vậy, đánh giá viên có thể phát hiện một sự không nhất\r\nquán nếu TSS tham chiếu đến một tiêu chuẩn kỹ thuật và điều này không được phản\r\nánh trong tài liệu ADV, nhưng không có động thái thường kỳ để kiểm thử sự đáp ứng\r\ncủa tiêu chuẩn.
\r\n\r\n\r\n\r\n
B.
Mục tiêu của phụ lục\r\nnày là giải thích các khái niệm Hồ sơ Bảo vệ (PP). Phụ lục này không định nghĩa\r\ncác tiêu chí APE, định nghĩa này có thể được tìm thấy trong TCVN 8709-3 và các\r\ntài liệu tham khảo.
\r\n\r\nVì PP v
Phụ lục này bao gồm bốn\r\nphần chính:
\r\n\r\na)
b) Một PP\r\nnên được sử dụng như thế nào. Điều này được tóm tắt\r\ntrong B.3.
\r\n\r\nc) PP đảm\r\nbảo thấp. PP đảm bảo thấp là PP có nội dung được giản lược.\r\nChúng được mô tả chi tiết\r\ntrong B.11.
\r\n\r\nd) Yêu\r\ncầu tuân thủ càc tiêu chuẩn. B.12 mô tả cách một tác giả\r\nPP có thể yêu cầu TOE là để đáp ứng một tiêu chuẩn cụ thể.
\r\n\r\nB.
Hình B.1 miêu tả nội\r\ndung bắt buộc đối với một PP mà TCVN 8709-3 đưa ra. Hình B.1 cũng có thể được sử\r\ndụng như là một phác thảo cấu trúc của PP, mặc dù cấu trúc thay thế được cho\r\nphép. Ví dụ, nếu các lý do những yêu cầu an toàn đặc biệt cồng kềnh, nó có thể\r\nđược bao gồm trong một phụ lục của PP thay vì\r\ntrong mục những yêu cầu an toàn. Các mục riêng biệt của một PP và nội dung của\r\nnhững mục đó được tóm tắt ngắn gọn dưới đây và được giải thích chi tiết hơn nữa\r\ntrong B.4 đến B.9. Một PP chứa:
\r\n\r\na) Giới\r\nthiệu PP chứa đựng một mô tả tường tận loại TOE;
\r\n\r\nb) Một\r\ntuyên bố tuân thủ, chỉ ra PP có tuân thủ với bất kỳ các PP\r\nvà /hoặc các gói hay không, và nếu có, thì với các PP và /hoặc các gói nào.
\r\n\r\nc) Một\r\nđịnh nghĩa vấn đề an toàn, chỉ ra các mối đe dọa, OSP\r\nvà giả định;
\r\n\r\nd) Các\r\nmục tiêu an toàn, biểu thị giải pháp cho vấn đề an toàn được chia thành các mục\r\ntiêu an toàn cho TOE và mục tiêu an toàn cho môi trường vận hành của TOE;
\r\n\r\ne) Định\r\nnghĩa các thành phần mở rộng, ở đó các thành phần mới (tức\r\nlà những thành phần không có trong TCVN 8709-2 hoặc TCVN 8709-3) có thể được định\r\nnghĩa. Các thành phần mới này cần được định nghĩa những yêu cầu chức năng mở rộng\r\nvà yêu cầu đảm bảo mở rộng;
\r\n\r\nf) Những\r\nyêu cầu an toàn, ở đó những mục tiêu an toàn cho TOE được chuyển sang một ngôn\r\nngữ tiêu chuẩn hóa. Ngôn ngữ tiêu chuẩn hóa này là ở dạng các SFR. Ngoài ra mục\r\nnày còn định nghĩa các SAR;
\r\n\r\nCũng tồn tại các PP đảm\r\nbảo mức thấp, chúng có các nội dung được giảm bớt; chúng được mô tả chi tiết\r\ntrong B.11. Ngoài ngoại lệ này, tất cả các phần khác trong phụ lục này giả thiết\r\nmột PP với đầy đủ các nội dung.
\r\n\r\nB.
B.
Một PP điển hình là một\r\nphát biểu về sự cần thiết, trong đó cộng đồng người dùng, một thực thể pháp lý,\r\nhoặc một nhóm các nhà phát triển định nghĩa ra một tập hợp chung của các nhu cầu\r\nan toàn. Một PP cung cấp cho người tiêu dùng một phương tiện tham chiếu đến tập\r\nnày, và tạo điều kiện cho đánh giá tương lai theo những nhu cầu này.
\r\n\r\nMột PP vì thế thường\r\nđược sử dụng như:
\r\n\r\n
mặc dù điều này không\r\nngăn cản các sử dụng khác của PP.
\r\n\r\nB.
Ba vai trò (trong số\r\nnhiều vai trò) mà một PP không nên thực hiện là:
\r\n\r\n
B.
Giới thiệu PP mô tả\r\ncác TOE một cách tường tận theo hai mức độ trừu tượng:
\r\n\r\na) tham\r\nchiếu PP, cung cấp tài liệu định danh cho PP;
\r\n\r\nb) tổng\r\nquan về TOE, trong đó mô tả ngắn gọn TOE.
\r\n\r\nB.
PP chứa đựng một tham\r\nchiếu PP rõ ràng, định rõ một PP cụ thể. Một tham chiếu PP điển hình bao
Tham chiếu PP giúp lập\r\nchỉ mục dễ dàng và tham khảo các PP và đưa nó vào danh sách các PP.
\r\n\r\nB.
Tổng quan TOE nhằm hướng\r\ntới những khách hàng tiềm năng của TOE, giúp họ lướt nhanh qua danh mục các\r\nTOE/sản phẩm đã được đánh giá để tìm kiếm TOE có khả năng đáp ứng cho nhu cầu\r\nan toàn của họ, và được hỗ trợ bởi phần cứng, phần mềm và phần sụn của họ.
\r\n\r\nTổng quan TOE cũng nhằm\r\nhướng đến những nhà phát triển, những người có thể sử dụng PP trong
Thông thường chiều\r\ndài của một tổng quan về TOE là một vài đoạn văn bản.
\r\n\r\nCuối cùng, phần tổng\r\nquan TOE mô tả tóm tắt cách sử dụng của TOE và những đặc điểm an toàn
B.
Việc mô tả cách sử dụng\r\nvà các đặc điểm an toàn chính của TOE được hướng đến để đưa ra một ý tưởng\r\nchung về TOE nào có khả năng, và TOE nào nó có thể sử dụng cho một bối cảnh an\r\ntoàn. Nó có thể được viết cho những khách hàng (tiềm năng) của TOE, mô tả cách\r\nsử dụng TOE và các đặc điểm an toàn chính trong nh
Một ví dụ " The\r\nAtlantean Navy CablePhone Encryptor là một thiết bị mã hóa cho ph
B.
Tổng quan TOE xác định\r\nloại TOE chung, chẳng hạn như: tường lửa, tường lửa VPN, thẻ thông minh, modem\r\nmã hóa, intranet, web server, cơ s
B.
Trong khi một số TOE\r\nkhông dựa vào CNTT khác, nhiều TOE (đặc biệt là TOE\r\nphần mềm) dựa vào phi-TOE phần cứng, phần mềm và / hoặc phần sụn bổ sung. Trong\r\ntrường hợp thứ hai, tổng quan về TOE là cần thiết để xác định các phi-TOE phần\r\ncứng / phần mềm / phần sụn.
\r\n\r\nV
Ví dụ về sự nhận biết\r\ncác phần cứng / phần mềm / phần sụn này là:
\r\n\r\n
B.
Mục này của một PP mô\r\ntả cách thức PP tuân thủ với các PP khác và với các gói. Nó giống mục tuyên bố\r\ntuân thủ đối với ST (xem A.5), với một ngoại lệ: phát biểu tuân thủ.
\r\n\r\nPhát biểu tuân thủ\r\ntrong PP tuyên bố về việc ST và / hoặc PP khác phải tuân thủ với PP đ
B.
Mục này giống hệt mục\r\nđịnh nghĩa vấn đề an toàn của một ST như được giải thích trong A.6.
\r\n\r\nB.
Mục này giống hệt với\r\ncác mục mục tiêu an toàn của một ST như được giải thích trong A.7.
\r\n\r\nB.
Mục này giống hệt với\r\nmục định nghĩa các thành phần mở rộng của một ST như được giải thích trong
B.
Mục này giống hệt mục\r\nnhững yêu cầu an toàn của một ST như được giải thích trong A.9. Tuy nhiên lưu ý\r\nrằng các quy tắc để hoàn thành các hoạt động trong một PP hơi khác các quy tắc\r\nđể hoàn thành các hoạt động trong một ST. Điều này được giải thích cụ thể hơn\r\ntrong 7.1.
\r\n\r\nB.
PP không có đặc tả kỹ\r\nthuật tóm tắt TOE.
\r\n\r\nB.
Một PP đảm bảo thấp\r\ncó cùng một mối quan hệ với một PP thông thường (PP có nội dung đầy đủ), cũng\r\nnhư một bảo đảm ST thấp có một ST thông thường. Điều này có nghĩa rằng một PP đảm\r\nbảo thấp bao gồm
\r\n\r\na) Giới\r\nthiệu PP, bao gồm phần tham chiếu PP và tổng quan về một TOE;
\r\n\r\nb) Tuyên\r\nbố tuân thủ;
\r\n\r\nc) Các\r\nmục tiêu an toàn cho môi trường vận hành;
\r\n\r\nd) các\r\nSFR và SAR (bao gồm cả định nghĩa các thành phần m
Một PP đảm bảo thấp\r\nchỉ có thể tuyên bố tuân thủ với một PP đảm bảo thấp (xem B.5). Một PP thông\r\nthường có thể tuyên bố tuân thủ với một PP đảm bảo thấp.
\r\n\r\nNội dung đã giản lược\r\ncủa một PP bảo đảm thấp được thể hiện trong Hình B.2.
\r\n\r\nB.
Mục này giống hệt mục\r\ncác tiêu chuẩn cho ST như mô tả trong A.13, ngoại trừ: vì một PP không có đặc tả\r\ntóm tắt TOE, nên tùy chọn thứ ba là không hợp lệ cho PP.
\r\n\r\n\r\n\r\n
C.
Như được mô tả trong\r\nphần này của TCVN 8709, Hồ sơ Bảo vệ và Đích an toàn có chứa các yêu cầu an\r\ntoàn được xác định trước, cũng như cung cấp cho tác giả của PP và ST khả năng mở\r\nrộng danh sách thành phần trong một số trường hợp.
\r\n\r\nC.
Bốn loại hoạt động được\r\nđưa ra trong 7.1. Ví dụ về các hoạt động khác nhau được mô tả dưới đây:
\r\n\r\nC
Như được mô tả trong\r\n7.1.1, hoạt động lặp có thể được thực hiện trên mỗi thành phần. Tác giả PP/ST\r\nthực hiện một hoạt động lặp lại bằng cách đưa vào nhiều yêu cầu cho cùng một\r\nthành phần. Mỗi lần lặp lại của một thành phần đều khác với tất cả các lần lặp\r\nlại khác của thành phần đó. Sự khác biệt này có được nhờ thực hiện chỉ định và\r\nlựa chọn theo cách khác nhau, hoặc áp dụng các bổ sung chi tiết theo cách khác\r\nnhau. Sự lặp lại khác nhau nên được xác định duy nhất để cho phép những sở cứ\r\nvà dấu vết vào/ra các yêu cầu này được rõ ràng.
\r\n\r\nMột ví dụ điển hình của\r\nphép lặp là FCS_COP.1 được lặp hai lần để yêu cầu thực hiện hai thuật toán mã\r\nhóa khác nhau. Ví dụ về mỗi lần lặp lại được xác định duy nhất là:
\r\n\r\nMật mã hoạt động (chữ\r\nký RSA và DSA) (FCS_COP.1 (1))
\r\n\r\nMật mã hoạt động (TLS\r\n/ SSL: hoạt động đối xứng) (FCS_COP.1 (2))
\r\n\r\nC
Như mô tả trong\r\n7.1.2, một hoạt động chỉ định xảy ra khi thành phần đưa ra chứa một phần tử với\r\nmột tham số có thể được thiết lập bởi tác giả\r\nPP/ST. Tham số có thể là một biến không hạn chế, hay quy
Một ví dụ của một phần\r\ntử chỉ định là: FIA_AFL.1.2 "Khi số lượng quy định của nỗ lực xác thực\r\nkhông thành công đạt được hoặc vượt qua, thì các TSF cần [chỉ định: danh\r\nsách các hành động]."
\r\n\r\nC
Như mô tả trong\r\n7.1.3, hoạt động lựa chọn xảy ra khi thành phần đưa ra c
Một ví dụ về một phần\r\ntử với lựa chọn là: FPT_TST.1.1 "The TSF phải thực hiện một bộ các kiểm thử\r\n[lựa chọn: trong suốt thời gian khởi tạo\r\nban đầu, định kỳ trong quá trình hoạt động bình thường, the
C
Như mô tả trong\r\n7.1.4, hoạt động bổ sung chi tiết có thể được thực hiện trên mọi yêu cầu. Tác\r\ngiả PP / ST thực hiện một bổ sung chi tiết bằng cách thay đổi yêu cầu đó.
\r\n\r\nMột ví dụ về một bổ\r\nsung chi tiết hợp lệ là FIA_UAU.2.1 "The TSF cần yêu cầu mỗi người dùng phải\r\nxác thực thành công trước khi cho phép bất kỳ hành động trung gian TSF nào thay\r\nmặt cho người dùng đó." được bổ sung chi tiết để trở thành "TSF cần\r\nyêu cầu mỗi người sử dụng xác thực thành công bằng tên người dùng / mật khẩu\r\ntrước khi cho phép bất kỳ hành động trung gian TSF nào thay mặt cho người dùng\r\nđó."
\r\n\r\nQuy tắc đầu tiên để bổ\r\nsung chi tiết là một TOE đáp ứng yêu cầu đã tinh lọc\r\ncũng cần đáp ứng các yêu cầu chưa tinh lọc trong ngữ cảnh của PP/ST\r\n(tức là một yêu cầu đã tinh lọc phải "chặt chẽ" hơn so với yêu cầu\r\nban đầu). Ngoại lệ duy nhất cho quy tắc này là một tác giả PP/ST được phép tinh\r\nlọc một SFR để áp dụng cho một số nhưng không phải tất cả các chủ thể, đối tượng,\r\ncác hoạt động, các thuộc tính an toàn và / hoặc các thực thể bên ngoài.
\r\n\r\nMột ví dụ về một trường\r\nhợp ngoại lệ như vậy là FIA_UAU.2.1 "The TSF cần yêu cầu mỗi người dùng phải\r\nxác thực thành công trước khi cho phép bất kỳ hành động trung gian TSF nào thay\r\nmặt cho người dùng đó" được bổ sung chi tiết để trở thành "TSF cần\r\nyêu cầu mỗi người sử dụng có nguồn gốc từ\r\nInternet phải xác thực thành công trước khi cho phép bất kỳ hành động trung\r\ngian TSF nào thay mặt cho người dùng đó."
\r\n\r\nQuy tắc thứ hai cho một\r\nbổ sung chi tiết được đưa ra là bổ sung chi tiết phải liên quan đến các thành\r\nphần gốc. Ví dụ, tinh lọc một thành phần kiểm toán với một phần tử bổ sung chống\r\nbức xạ điện từ là không được phép.
\r\n\r\nMột trường hợp đặc biệt\r\ncủa bổ sung chi tiết là một bổ sung chi tiết biên tập, ở đó, một\r\nsự thay đổi nhỏ sẽ\r\nđược tạo ra trong một yêu cầu, nghĩa là diễn tả lại một câu để giữ đúng ngữ\r\npháp tiếng Anh, hoặc để làm cho nó dễ hiểu hơn đối với người đọc. Sự thay đổi\r\nnày không được phép sửa đổi ý nghĩa của yêu cầu. Ví dụ về bổ sung chi tiết biên\r\ntập bao gồm:
\r\n\r\n
C.
TCVN 8709 tổ chức các\r\nthành phần trong TCVN 8709-2 và TCVN 8709-3 thành các cấu trúc có thứ
T
TCVN 8709 trình bày\r\ncác thành phần chức năng và đảm bảo theo cùng kiểu phân cấp, sử dụng mô hình tổ\r\nchức và các khái niệm như nhau.
\r\n\r\nC
Ví dụ về một lớp là lớp\r\nFIA, lớp này tập trung vào việc định danh người dùng, xác thực người dùng và\r\nràng buộc các người dùng với các chủ thể.
\r\n\r\nC
Ví dụ về một họ là họ\r\nXác thực người dùng (FIA_UAU), họ này là một phần của lớp FIA. Họ này tập trung\r\nvào việc xác thực người sử dụng.
\r\n\r\nC
Một ví dụ về một\r\nthành phần là FIA_UAU.3 Xác thực chống giả mạo, thành phần này tập trung vào\r\nxác thực chống giả mạo.
\r\n\r\nC
Một ví dụ về một phần\r\ntử là FIA_UAU.3.2, phần tử này tập trung vào\r\nviệc ngăn chặn việc sử dụng dữ liệu chứng thực đã sao chép.
\r\n\r\nC.
C
Mỗi khi tác giả PP/ST\r\nđịnh nghĩa một thành phần mở rộng, việc đó cần thực hiện theo phương thức tương\r\ntự như các thành phần đã có trong TCVN 8709: rõ ràng, không mơ hồ và có thể\r\nđánh giá được (có thể diễn giải một cách hệ thống về việc liệu một yêu cầu dựa\r\ntrên thành phần đó có áp dụng được cho một TOE hay không). Các thành phần m
Tác giả PP / ST cũng\r\ncần phải chắc chắn rằng mọi sự phụ thuộc áp dụng cho một thành phần mở rộng đã\r\nđược đưa vào trong định nghĩa thành phần mở rộng\r\nđó. Ví dụ về sự phụ thuộc có thể là:
\r\n\r\na) nếu\r\nmột thành phần mở rộng tham chiếu đến kiểm toán, thì sự phụ thuộc đến các thành\r\nphần của lớp Fau có thể phải được đưa vào;
\r\n\r\nb) nếu\r\nmột thành phần mở rộng sửa đổi hoặc truy xuất dữ liệu, sự phụ thuộc đến các\r\nthành phần của họ FDP_ACC có thể phải được đưa vào;
\r\n\r\nc) nếu\r\nmột thành phần mở rộng sử dụng một mô tả thiết kế cụ thể, sự phụ thuộc v
Trong trường hợp một\r\nthành phần chức năng mở rộng, tác giả PP / ST cũng cần phải đưa vào mọi kiểm\r\ntoán phù hợp và thông tin về các hoạt động liên quan trong định nghĩa của thành\r\nphần đó, tương tự như các thành phần sẵn có trong tiêu chuẩn TCVN 8709-2. Trong\r\ntrường hợp một thành phần đảm bảo mở rộng, tác giả PP/ST cần phải cung cấp\r\nphương pháp luận đánh giá thích hợp cho thành phần, tương tự như phương pháp luận\r\nđã có trong ISO/IEC 18045.
\r\n\r\nCác thành phần mở rộng\r\ncó thể được đặt trong các họ hiện có, trong đó
Các họ mới có thể được\r\nđặt trong các lớp hiện tại, trong đó người\r\nbiên soạn PP / ST phải chỉ ra các lớp này thay đổi như thế nào. Nếu chúng không\r\nphù hợp với một lớp hiện có, chúng sẽ được đặt trong\r\nmột lớp mới. Lớp mới này phải được định nghĩa tương tự theo TCVN 8709.
\r\n\r\n\r\n\r\n
D.
Một PP được hưởng đến\r\nsử dụng như là một "mẫu" cho một ST. Nghĩa là: PP mô tả một tập hợp\r\ncác nhu cầu của người sử dụng, trong khi một ST tuân thủ với PP đó mô tả một\r\nTOE thỏa mãn những nhu cầu đó.
\r\n\r\nLưu ý rằng cũng có thể\r\nmột PP được sử dụng như một mẫu cho một PP khác. Đó là các PP có thể tuyên bố\r\ntuân thủ với các PP khác. Trường hợp này là hoàn toàn tương tự như của một ST\r\nso với một PP. Phụ lục này chỉ mô tả trường hợp ST/PP, còn nó được tổ chức như\r\nđối với trường hợp PP/ PP.
\r\n\r\nTCVN 8709 không cho\r\nphép bất kỳ hình thức tuân thủ từng phần nào, vì vậy nếu một PP được yêu cầu,\r\ncác PP hoặc ST phải tuân thủ đầy đủ với PP hoặc các PP tham chiếu. Tuy nhiên,\r\ncó hai kiểu tuân thủ ("hoàn toàn" và "có thể diễn giải") và\r\nkiểu tuân thủ cho phép được xác định bởi PP. Như vậy, PP tuyên bố (trong phát\r\nbiểu tuân thủ PP, xem B.5) về những kiểu tuân thủ được phép cho ST. Sự phân biệt\r\ngiữa tuân thủ chặt chẽ và tuân thủ có thể diễn giải có thể áp dụng cho mỗi PP\r\nmà một ST có thể yêu cầu tuân thủ theo cách riêng. Điều này có thể nghĩa là ST\r\ntuân thủ chặt chẽ với một số’PP và tuân thủ có diễn giải với một số PP khác. Một\r\nST chỉ được phép tuân thủ với một PP theo phương thức diễn giải, nếu PP cho\r\nphép một cách rõ ràng điều này, trong khi đó một ST luôn có thể tuân thủ chặt\r\nchẽ với mọi PP.
\r\n\r\nPhát biểu điều trên bằng\r\nmột cách khác là, một ST chỉ được phép tuân thủ với một PP theo phương thức diễn\r\ngiải, nếu PP cho phép một cách rõ ràng điều này.
\r\n\r\nTuân thủ với một PP\r\nnghĩa là PP hoặc ST (vả nếu một ST là một sản phẩm đã được đánh giá, cũng như một\r\nsản phẩm) đáp ứng mọi yêu cầu của PP này.
\r\n\r\nCác PP được công bố sẽ\r\nthường yêu cầu tuân thủ có thể diễn giải. Điều đó nghĩa là các ST đòi hỏi tuân\r\nthủ với PP sẽ phải đưa ra một giải pháp cho vấn đề an toàn chung đã nêu trong PP,\r\nsong có thể thực hiện điều đó theo bất kỳ cách nào tương đương hoặc chặt chẽ\r\nhơn cách đã mô tả trong PP. “Tương đương song chặt chẽ hơn” được định nghĩa về\r\nđộ dài trong TCVN 8709, song về nguyên tắc, điều đó nghĩa là PP và ST có thể chứa\r\ntoàn bộ các phát biểu khác nhau về các thực thể khác nhau, sử dụng các khái niệm\r\nkhác nhau.., với điều kiện tổng quát là ST thu được cùng hoặc nhiều hạn chế hơn\r\nvề TOE, và cùng hoặc ít hạn chế hơn về môi trường hoạt động của TOE.
\r\n\r\nD.
Tuân thủ chặt chẽ hướng\r\nđến tác giả PP, người đòi hỏi bằng chứng về việc các yêu cầu trong PP được đáp ứng,\r\nvề việc ST là một bản sao của PP, mặc dù ST có thể là rộng hơn so với PP.
Một ví dụ điển hình của\r\nviệc sử dụng tuân thủ chặt chẽ là việc lựa chọn dựa trên mua sắm, trong đó các\r\nyêu cầu an toàn của sản phẩm được kỳ vọng trùng hợp chính xác với những quy định\r\ntrong PP.
\r\n\r\nTuân thủ chặt chẽ với\r\nmột PP cho một bản sao của một ST có thể vẫn có một số hạn chế b
D.
Tuân thủ có thể diễn\r\ngiải hướng tới tác giả PP, người yêu cầu bằng chứng về việc ST l
Khi có một mối quan hệ\r\nkiểu tập con - tập lớn rõ rệt giữa PP và ST trong trường hợp tuân thủ chặt chẽ,\r\nmối quan hệ này sẽ bị giảm tính rõ ràng trong trường hợp tuân thủ có thể diễn\r\ngiải. Các ST yêu cầu tuân thủ với PP phải đưa ra một giải\r\npháp cho vấn đề an toàn chung được mô tả trong PP.
\r\n\r\nTuy nhiên, việc đòi hỏi\r\ntuân thủ chỉ được phép trong trường hợp ST áp đặt tương tự hoặc nhiều hơn các hạn\r\nchế trên TOE, và tương tự hoặc ít hơn các hạn chế về môi trường vận hành của\r\nTOE.
\r\n\r\n\r\n\r\n
Các tiêu chuẩn\r\nISO/IEC và hướng dẫn
\r\n\r\n[1] ISO/IEC\r\n15292, lnformation technology - Security techniques - Protection Pro
[2] ISO/IEC\r\n15443 (all parts), Information technology - Security techniques\r\n- A framework for IT security assurance
\r\n\r\n[3] ISO/IEC\r\n15446, Information technology - Security\r\ntechniques - Guide for
[4] ISO/IEC\r\n19790, Information technology - Security\r\ntechniques - Security requirements for cryptographic modules
\r\n\r\n[5] ISO/IEC\r\n19791, Information technology - Security\r\ntechniques - Security assessment of operational systems
\r\n\r\n[6] ISO/IEC\r\n27001:2005, Information technology - Security\r\ntechniques - lnformation security management systems - Requirements
\r\n\r\n[7] ISO/IEC\r\n27002:2005, Information technology - Security\r\ntechniques - Code of practice for information\r\nsecurity management
\r\n\r\n[8] ISO/IEC\r\n15408 - 1 : 2005, Information Technology - Security\r\nTechniques - Evaluation Criteria for IT Security - Part 1: Introduction and\r\ngeneral model.
\r\n\r\n[9] ISO/IEC\r\n15408 - 2 : 2005, Information Technology - Security\r\nTechniques - Evaluation Criteria for IT Security - Part 2: Security
[10] ISO/IEC\r\n15408 - 3 : 2005, Information Technology - Security\r\nTechniques - Evaluation Criteria for IT Security - Part 3: Security assurance\r\nrequirements.
\r\n\r\n[11] ISO/IEC\r\n15408 - 1 : 2009, Information Technology - Security\r\nTechniques - Evaluation Criteria for IT Security - Part 1: Introduction and\r\ngeneral model.
\r\n\r\n[12] ISO/IEC\r\n15408 - 2 : 2008, Information Technology - Security\r\nTechniques - Evaluation Criteria for IT Security - Part 2: Security
[13] ISO/IEC\r\n15408 - 3 : 2008, Information Technology - Security\r\nTechniques - Evaluation Criteria for IT Security - Part 3: Security assurance\r\nrequirements.
\r\n\r\nCác tiêu chuẩn và hướng\r\ndẫn khác
\r\n\r\n[14] IEEE\r\nStd 610.12-1990, Institute of Electrical\r\nand Electronics Engineers, Standard Glossary of
[15] Common\r\nCriteria portal, February 2009. CCRA,
[16] TCVN\r\n27001: 2009, Công nghệ thông tin - Các kỹ thuật an toàn - Các hệ thống quản lý\r\nan toàn thông tin - Các yêu cầu
\r\n\r\n\r\n\r\n
CHÚ TH
| \r\n | \r\n \r\n Acceptance criteria \r\n | \r\n \r\n Các tiêu chí ch | \r\n
| \r\n | \r\n \r\n Acceptance\r\n procedures \r\n | \r\n \r\n Các thủ tục chấp\r\n thuận \r\n | \r\n
| \r\n | \r\n \r\n Administrator \r\n | \r\n \r\n Người quản trị \r\n | \r\n
| \r\n | \r\n \r\n adverse actions \r\n | \r\n \r\n Các hành động có hại \r\n | \r\n
| \r\n | \r\n \r\n Assets \r\n | \r\n \r\n Tài sản \r\n | \r\n
| \r\n | \r\n \r\n Assignment \r\n | \r\n \r\n Chỉ định \r\n | \r\n
| \r\n | \r\n \r\n Assurance \r\n | \r\n \r\n Bảo đảm \r\n | \r\n
| \r\n | \r\n \r\n Attack potential \r\n | \r\n \r\n Khả năng t | \r\n
| \r\n | \r\n \r\n Augmentation \r\n | \r\n \r\n Gia tăng \r\n | \r\n
| \r\n | \r\n \r\n Authentication data \r\n | \r\n \r\n Dữ liệu xác thực \r\n | \r\n
| \r\n | \r\n \r\n Authorized user \r\n | \r\n \r\n Người dùng có thẩm\r\n quyền \r\n | \r\n
| \r\n | \r\n \r\n Base component \r\n | \r\n \r\n Thành ph | \r\n
| \r\n | \r\n \r\n Call coupling \r\n | \r\n \r\n Ghép n | \r\n
| \r\n | \r\n \r\n Call tree \r\n | \r\n \r\n Cây truy xu | \r\n
| \r\n | \r\n \r\n Class \r\n | \r\n \r\n Lớp \r\n | \r\n
| \r\n | \r\n \r\n CM documentation \r\n | \r\n \r\n Tài liệu CM \r\n | \r\n
| \r\n | \r\n \r\n Coherent \r\n | \r\n \r\n Tính mạch lạc \r\n | \r\n
| \r\n | \r\n \r\n Cohesion \r\n | \r\n \r\n Tính g | \r\n
| \r\n | \r\n \r\n Coincidental\r\n cohesion \r\n | \r\n \r\n Gắn kết trùng hợp \r\n | \r\n
| \r\n | \r\n \r\n Common coupling \r\n | \r\n \r\n Ghép n | \r\n
| \r\n | \r\n \r\n Communication\r\n cohesion \r\n | \r\n \r\n Gắn kết truyền\r\n thông \r\n | \r\n
| \r\n | \r\n \r\n Compatible \r\n | \r\n \r\n Tương thích \r\n | \r\n
| \r\n | \r\n \r\n Complete \r\n | \r\n \r\n Tính hoàn thiện \r\n | \r\n
| \r\n | \r\n \r\n Complexity \r\n | \r\n \r\n Độ phức tạp \r\n | \r\n
| \r\n | \r\n \r\n Component \r\n | \r\n \r\n Thành phần \r\n | \r\n
| \r\n | \r\n \r\n Component | \r\n \r\n TOE thành phần \r\n | \r\n
| \r\n | \r\n \r\n Composed Assurance\r\n package \r\n | \r\n \r\n Gói đảm bảo t | \r\n
| \r\n | \r\n \r\n Composed TOE \r\n | \r\n \r\n TOE t | \r\n
| \r\n | \r\n \r\n Con | \r\n \r\n Quản lý c | \r\n
| \r\n | \r\n \r\n Con | \r\n \r\n Bằng chứng quản lý\r\n cấu hình \r\n | \r\n
| \r\n | \r\n \r\n Con | \r\n \r\n K | \r\n
| \r\n | \r\n \r\n Con | \r\n \r\n Đ | \r\n
| \r\n | \r\n \r\n Con | \r\n \r\n Hệ th | \r\n
| \r\n | \r\n \r\n Con | \r\n \r\n Các bản ghi hệ thống\r\n quản lý cấu hình \r\n | \r\n
| \r\n | \r\n \r\n Con | \r\n \r\n Các công cụ quản lý\r\n cấu hình \r\n | \r\n
| \r\n | \r\n \r\n Con | \r\n \r\n Tài liệu sử dụng quản\r\n lý cấu hình \r\n | \r\n
| \r\n | \r\n \r\n Configuration item \r\n | \r\n \r\n Khoản mục c | \r\n
| \r\n | \r\n \r\n Con | \r\n \r\n Danh sách c | \r\n
| \r\n | \r\n \r\n Con | \r\n \r\n Xác nhận \r\n | \r\n
| \r\n | \r\n \r\n Connectivity \r\n | \r\n \r\n Tính k | \r\n
| \r\n | \r\n \r\n Consistent \r\n | \r\n \r\n Tính nh | \r\n
| \r\n | \r\n \r\n Content coupling \r\n | \r\n \r\n Ghép n | \r\n
| \r\n | \r\n \r\n Counter (verb) \r\n | \r\n \r\n Ch | \r\n
| \r\n | \r\n \r\n Coupling \r\n | \r\n \r\n Ghép n | \r\n
| \r\n | \r\n \r\n Covert channel \r\n | \r\n \r\n Kênh b | \r\n
| \r\n | \r\n \r\n Delivery \r\n | \r\n \r\n Chuy | \r\n
| \r\n | \r\n \r\n Demonstable\r\n contormance \r\n | \r\n \r\n Tính tuân thủ diễn\r\n giải được \r\n | \r\n
| \r\n | \r\n \r\n Demontrate \r\n | \r\n \r\n Diễn giải \r\n | \r\n
| \r\n | \r\n \r\n Dependency \r\n | \r\n \r\n Tính phụ thuộc \r\n | \r\n
| \r\n | \r\n \r\n Dependent component \r\n | \r\n \r\n Thành ph | \r\n
| \r\n | \r\n \r\n Describe \r\n | \r\n \r\n Mô tả \r\n | \r\n
| \r\n | \r\n \r\n Determine \r\n | \r\n \r\n Xác định \r\n | \r\n
| \r\n | \r\n \r\n Developer \r\n | \r\n \r\n Nhà phát tri | \r\n
| \r\n | \r\n \r\n Development \r\n | \r\n \r\n Phát tri | \r\n
| \r\n | \r\n \r\n Development\r\n environment \r\n | \r\n \r\n Môi trường phát triển \r\n | \r\n
| \r\n | \r\n \r\n Development tools \r\n | \r\n \r\n Các công cụ phát\r\n triển \r\n | \r\n
| \r\n | \r\n \r\n Domain separation \r\n | \r\n \r\n Phân cách mi | \r\n
| \r\n | \r\n \r\n Element \r\n | \r\n \r\n Ph | \r\n
| \r\n | \r\n \r\n Encountered\r\n potential vulnerabilities \r\n | \r\n \r\n Các điểm yếu tiềm ẩn\r\n phải đối mặt \r\n | \r\n
| \r\n | \r\n \r\n Ensure \r\n | \r\n \r\n Bảo đảm \r\n | \r\n
| \r\n | \r\n \r\n Evaluation \r\n | \r\n \r\n Đánh giá \r\n | \r\n
| \r\n | \r\n \r\n Evaluation\r\n assurance level (EAL) \r\n | \r\n \r\n Mức bảo đảm đánh\r\n giá (EAL) \r\n | \r\n
| \r\n | \r\n \r\n Evaluation\r\n authority \r\n | \r\n \r\n Cơ quan đánh giá \r\n | \r\n
| \r\n | \r\n \r\n Evaluation scheme \r\n | \r\n \r\n Lược đ | \r\n
| \r\n | \r\n \r\n Exhaustive \r\n | \r\n \r\n Th | \r\n
| \r\n | \r\n \r\n Explain \r\n | \r\n \r\n Giải thích \r\n | \r\n
| \r\n | \r\n \r\n Exploitable\r\n vulnerability \r\n | \r\n \r\n Các đi | \r\n
| \r\n | \r\n \r\n Extension \r\n | \r\n \r\n Mở rộng \r\n | \r\n
| \r\n | \r\n \r\n External entity \r\n | \r\n \r\n Thực th | \r\n
| \r\n | \r\n \r\n Family \r\n | \r\n \r\n Họ \r\n | \r\n
| \r\n | \r\n \r\n Formal \r\n | \r\n \r\n Hình thức \r\n | \r\n
| \r\n | \r\n \r\n Functional cohesion \r\n | \r\n \r\n G | \r\n
| \r\n | \r\n \r\n Functional inter | \r\n \r\n Giao diện chức năng \r\n | \r\n
| \r\n | \r\n \r\n Guidance\r\n documentation \r\n | \r\n \r\n Tài liệu hướng dẫn \r\n | \r\n
| \r\n | \r\n \r\n Identity \r\n | \r\n \r\n Định danh \r\n | \r\n
| \r\n | \r\n \r\n Implementation representation \r\n | \r\n \r\n Mô tả triển khai \r\n | \r\n
| \r\n | \r\n \r\n In | \r\n \r\n Không hình thức \r\n | \r\n
| \r\n | \r\n \r\n Installation \r\n | \r\n \r\n Cài đặt \r\n | \r\n
| \r\n | \r\n \r\n Inter TSF trans | \r\n \r\n Vận chuy | \r\n
| \r\n | \r\n \r\n Interaction \r\n | \r\n \r\n Tương tác \r\n | \r\n
| \r\n | \r\n \r\n Inter | \r\n \r\n Giao diện \r\n | \r\n
| \r\n | \r\n \r\n Internal\r\n communication channel \r\n | \r\n \r\n Kênh truyền thông nội\r\n bộ \r\n | \r\n
| \r\n | \r\n \r\n Internal TOE trans | \r\n \r\n Vận chuyển nội bộ\r\n TOE \r\n | \r\n
| \r\n | \r\n \r\n Internally\r\n consistent \r\n | \r\n \r\n Tính nh | \r\n
| \r\n | \r\n \r\n iteration \r\n | \r\n \r\n Phép lặp \r\n | \r\n
| \r\n | \r\n \r\n Justification \r\n | \r\n \r\n Biện minh \r\n | \r\n
| \r\n | \r\n \r\n Layering \r\n | \r\n \r\n Phân lớp \r\n | \r\n
| \r\n | \r\n \r\n Life-cycle \r\n | \r\n \r\n Vòng đời \r\n | \r\n
| \r\n | \r\n \r\n Life-cycle de | \r\n \r\n Định nghĩa vòng đời \r\n | \r\n
| \r\n | \r\n \r\n Life-cycle model \r\n | \r\n \r\n Mô hình vòng đời \r\n | \r\n
| \r\n | \r\n \r\n Logical cohesion,\r\n procedural cohesion \r\n | \r\n \r\n Gắn kết logic, gắn\r\n kết thủ tục \r\n | \r\n
| \r\n | \r\n \r\n Modular\r\n decomposition \r\n | \r\n \r\n Phân tách mô đun \r\n | \r\n
| \r\n | \r\n \r\n Monitoring attacks \r\n | \r\n \r\n Các tấn công (kiểu)\r\n giám sát \r\n | \r\n
| \r\n | \r\n \r\n Non-bypassability \r\n | \r\n \r\n Khả năng không đi\r\n vòng \r\n | \r\n
| \r\n | \r\n \r\n Object \r\n | \r\n \r\n Đ | \r\n
| \r\n | \r\n \r\n Operation \r\n | \r\n \r\n Hoạt động \r\n | \r\n
| \r\n | \r\n \r\n Operational\r\n environment \r\n | \r\n \r\n Môi trường vận hành \r\n | \r\n
| \r\n | \r\n \r\n Organizational\r\n security policy \r\n | \r\n \r\n Chính sách an toàn của\r\n tổ chức \r\n | \r\n
| \r\n | \r\n \r\n Package \r\n | \r\n \r\n Gói \r\n | \r\n
| \r\n | \r\n \r\n Potential\r\n vulnerability \r\n | \r\n \r\n Các điểm yếu tiềm ẩn \r\n | \r\n
| \r\n | \r\n \r\n Preparation \r\n | \r\n \r\n Chu | \r\n
| \r\n | \r\n \r\n Production \r\n | \r\n \r\n Sản xu | \r\n
| \r\n | \r\n \r\n Protection pro | \r\n \r\n H | \r\n
| \r\n | \r\n \r\n Protection pro | \r\n \r\n Đánh giá Hồ sơ bảo\r\n vệ \r\n | \r\n
| \r\n | \r\n \r\n Prove \r\n | \r\n \r\n Chứng minh \r\n | \r\n
| \r\n | \r\n \r\n Re | \r\n \r\n Bổ sung chi tiết \r\n | \r\n
| \r\n | \r\n \r\n Residual\r\n vulnerability \r\n | \r\n \r\n Các điểm yếu còn tồn\r\n tại \r\n | \r\n
| \r\n | \r\n \r\n Role \r\n | \r\n \r\n Tập phân vai \r\n | \r\n
| \r\n | \r\n \r\n Secret \r\n | \r\n \r\n Bí mật \r\n | \r\n
| \r\n | \r\n \r\n Secure | \r\n \r\n Trạng thái an toàn \r\n | \r\n
| \r\n | \r\n \r\n Security attribute \r\n | \r\n \r\n Thuộc tính an toàn \r\n | \r\n
| \r\n | \r\n \r\n Security domain \r\n | \r\n \r\n Mi | \r\n
| \r\n | \r\n \r\n Security | \r\n \r\n Chính sách chức\r\n năng an toàn \r\n | \r\n
| \r\n | \r\n \r\n Security objective \r\n | \r\n \r\n Mục tiêu an toàn \r\n | \r\n
| \r\n | \r\n \r\n Security problem \r\n | \r\n \r\n V | \r\n
| \r\n | \r\n \r\n Security\r\n requirement \r\n | \r\n \r\n Yêu c | \r\n
| \r\n | \r\n \r\n Security Target \r\n | \r\n \r\n Đích an toàn (ST) \r\n | \r\n
| \r\n | \r\n \r\n Selection \r\n | \r\n \r\n Lựa chọn \r\n | \r\n
| \r\n | \r\n \r\n Semiformal \r\n | \r\n \r\n Bán hình thức \r\n | \r\n
| \r\n | \r\n \r\n Sequential cohesion \r\n | \r\n \r\n G | \r\n
| \r\n | \r\n \r\n Software\r\n engineering \r\n | \r\n \r\n Công nghệ phần mềm \r\n | \r\n
| \r\n | \r\n \r\n Specify \r\n | \r\n \r\n Đặc tả \r\n | \r\n
| \r\n | \r\n \r\n Strict\r\n conformance \r\n | \r\n \r\n Tuân thủ chặt chẽ \r\n | \r\n
| \r\n | \r\n \r\n ST evaluation \r\n | \r\n \r\n Đánh giá ST \r\n | \r\n
| \r\n | \r\n \r\n Subject \r\n | \r\n \r\n Chủ th | \r\n
| \r\n | \r\n \r\n Target of\r\n Evaluation (TOE) \r\n | \r\n \r\n Đích đánh giá (TOE) \r\n | \r\n
| \r\n | \r\n \r\n Temporal cohesion \r\n | \r\n \r\n G | \r\n
| \r\n | \r\n \r\n Threat agent \r\n | \r\n \r\n Tác nhân đe dọa \r\n | \r\n
| \r\n | \r\n \r\n TOE Evaluation \r\n | \r\n \r\n Đánh giá TOE \r\n | \r\n
| \r\n | \r\n \r\n TOE resource \r\n | \r\n \r\n Tài nguyên TOE \r\n | \r\n
| \r\n | \r\n \r\n TOE security\r\n functionality \r\n | \r\n \r\n Chức năng an toàn của\r\n TOE (TSF) , \r\n | \r\n
| \r\n | \r\n \r\n Trace (verb) \r\n | \r\n \r\n Theo dấu \r\n | \r\n
| \r\n | \r\n \r\n Transfers outside\r\n of the TOE \r\n | \r\n \r\n Vận chuyển bên\r\n ngoài TOE \r\n | \r\n
| \r\n | \r\n \r\n Translation \r\n | \r\n \r\n Chuyên đ | \r\n
| \r\n | \r\n \r\n Trusted channel \r\n | \r\n \r\n Kênh tin cậy \r\n | \r\n
| \r\n | \r\n \r\n Trusted IT product \r\n | \r\n \r\n Sản phẩm CNTT tin cậy \r\n | \r\n
| \r\n | \r\n \r\n Trusted path \r\n | \r\n \r\n Đường dẫn tin cậy \r\n | \r\n
| \r\n | \r\n \r\n TSF self-protection \r\n | \r\n \r\n Tự bảo vệ TSF \r\n | \r\n
| \r\n | \r\n \r\n TSF data \r\n | \r\n \r\n Dữ liệu TSF \r\n | \r\n
| \r\n | \r\n \r\n TSF inter | \r\n \r\n Giao diện TSF \r\n | \r\n
| \r\n | \r\n \r\n User data \r\n | \r\n \r\n Dữ liệu người dùng \r\n | \r\n
| \r\n | \r\n \r\n Verify \r\n | \r\n \r\n Th | \r\n
| \r\n | \r\n \r\n Vulnerability \r\n | \r\n \r\n Đi | \r\n
\r\n\r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n ADV \r\n | \r\n \r\n ADV:Development \r\n | \r\n \r\n Lớp\r\n ADV: Phát triển \r\n | \r\n
| \r\n ADV_ARC \r\n | \r\n \r\n ADV_ARC: | \r\n \r\n ADV_FSP: Đặc tả kiến\r\n trúc an toàn \r\n | \r\n
| \r\n ADV_FSP \r\n | \r\n \r\n ADV_FSP:Basic | \r\n \r\n ADV_FSP: Đặc tả chức\r\n năng cơ bản \r\n | \r\n
| \r\n ADV_TDS \r\n | \r\n \r\n ADV_TDS: Basic\r\n design \r\n | \r\n \r\n ADV_TDS: Thiết kế\r\n cơ bản \r\n | \r\n
| \r\n AGD \r\n | \r\n \r\n AGD:Guidance\r\n documents \r\n | \r\n \r\n Lớp AGD: Tài liệu\r\n hướng dẫn \r\n | \r\n
| \r\n AGD_OPE \r\n | \r\n \r\n AGD_OPE:Operational\r\n user guidance \r\n | \r\n \r\n AGD_OPE: Hướng dẫn\r\n người dùng vận hành \r\n | \r\n
| \r\n AGD_PRE \r\n | \r\n \r\n AGD_PRE:Preparative\r\n procedures \r\n | \r\n \r\n AGD_PRE: Các thủ tục\r\n chuẩn bị \r\n | \r\n
| \r\n ALC \r\n | \r\n \r\n ALC:Life-cycle\r\n support \r\n | \r\n \r\n Lớp\r\n ALC: Hỗ trợ vòng đời \r\n | \r\n
| \r\n ALC_CMC \r\n | \r\n \r\n ALC_CMC: Labelling\r\n of the TOE \r\n | \r\n \r\n ALC_CMC: Dán nhãn\r\n TOE \r\n | \r\n
| \r\n ALC_CMC \r\n | \r\n \r\n ALC_CMS: TOE CM\r\n Coverage \r\n | \r\n \r\n ALC_CMS: Tổng quát\r\n TOE CM \r\n | \r\n
| \r\n ALC_DEL \r\n | \r\n \r\n ALC_DEL: Delivery\r\n procedures \r\n | \r\n \r\n ALC_DEL: Các thủ tục\r\n chuyển giao \r\n | \r\n
| \r\n ALC_DVS \r\n | \r\n \r\n ALC_DVS: Identi | \r\n \r\n ALC_DVS: Định danh\r\n các biện pháp an toàn \r\n | \r\n
| \r\n ASE \r\n | \r\n \r\n ASE:Security Target\r\n evaluation \r\n | \r\n \r\n Lớp ASE: Đánh giá\r\n đích an toàn \r\n | \r\n
| \r\n ASE_CCL \r\n | \r\n \r\n ASE_CCL: Con | \r\n \r\n ASE_CCL: Các yêu cầu\r\n tuân thủ \r\n | \r\n
| \r\n ASE_ECD \r\n | \r\n \r\n ASE_ECD: extended\r\n components definition \r\n | \r\n \r\n ASE_ECD: Định nghĩa\r\n các thành phần mở rộng \r\n | \r\n
| \r\n ASE_INT \r\n | \r\n \r\n ASE_INT: ST\r\n introduction \r\n | \r\n \r\n ASE_INT: Giới thiệu\r\n ST \r\n | \r\n
| \r\n ASE_OBJ \r\n | \r\n \r\n ASE_OBJ: Security\r\n objectives for the operational environment \r\n | \r\n \r\n ASE_OBJ: Các mục\r\n tiêu an toàn cho môi trường vận hành \r\n | \r\n
| \r\n ASE_REQ \r\n | \r\n \r\n ASE_REQ: stated\r\n security requirements \r\n | \r\n \r\n ASE_REQ: Các yêu cầu\r\n an toàn đã công bố \r\n | \r\n
| \r\n ASE_SPD \r\n | \r\n \r\n ASE_SPD: Security\r\n problem definition \r\n | \r\n \r\n ASE_SPD: Định nghĩa\r\n vấn đề an toàn \r\n | \r\n
| \r\n ASE_TSS \r\n | \r\n \r\n ASE_TSS: TOE\r\n summary specification \r\n | \r\n \r\n ASE_TSS: Đặc tả tóm\r\n tắt TOE \r\n | \r\n
| \r\n ATE \r\n | \r\n \r\n ATE:Tests \r\n | \r\n \r\n Lớp ATE: Ki | \r\n
| \r\n ATE_COV \r\n | \r\n \r\n ATE_COV:Evidence of\r\n coverage \r\n | \r\n \r\n ATE_COV: Chứng cứ về\r\n tính tổng quát \r\n | \r\n
| \r\n ATE_DPT \r\n | \r\n \r\n ATE_DPT: Testing:\r\n basic design \r\n | \r\n \r\n ATE_DPT: Kiểm thử:\r\n thiết kế cơ bản \r\n | \r\n
| \r\n ATE_FUN \r\n | \r\n \r\n ATE_FUN:Functional\r\n Testing \r\n | \r\n \r\n ATE_FUN: Kiểm thử\r\n chức năng \r\n | \r\n
| \r\n ATE_IND \r\n | \r\n \r\n ATE_IND:lndependent\r\n testing - conformance \r\n | \r\n \r\n ATE_IND: Kiểm thử độc\r\n lập - Tuân thủ \r\n | \r\n
| \r\n AVA \r\n | \r\n \r\n AVA:Vulnerability\r\n assessment \r\n | \r\n \r\n Lớp AVA:.Đánh giá\r\n điểm yếu \r\n | \r\n
| \r\n AVA_VAN \r\n | \r\n \r\n AVA_VAN:Vulnerability\r\n survey \r\n | \r\n \r\n AVA_VAN: Khảo sát\r\n điểm yếu \r\n | \r\n
| \r\n API \r\n | \r\n \r\n A | \r\n \r\n Giao diện lập trình\r\n ứng dụng \r\n | \r\n
| \r\n CAP \r\n | \r\n \r\n Composed Assurance\r\n Package \r\n | \r\n \r\n Gói đảm bảo tổng hợp \r\n | \r\n
| \r\n CM \r\n | \r\n \r\n Con | \r\n \r\n Quản lý cấu hình \r\n | \r\n
| \r\n CNTT \r\n | \r\n \r\n In | \r\n \r\n Công nghệ thông tin\r\n (CNTT) \r\n | \r\n
| \r\n D | \r\n \r\n Discretionary Access\r\n Control \r\n | \r\n \r\n Kiểm soát truy nhập\r\n tùy ý \r\n | \r\n
| \r\n EAL \r\n | \r\n \r\n Evaluation\r\n Assurance Level \r\n | \r\n \r\n Mức bảo đảm đánh\r\n giá \r\n | \r\n
| \r\n FAU \r\n | \r\n \r\n Function Security\r\n Audit Class \r\n | \r\n \r\n Lớp kiểm toán an\r\n toàn (FAU) \r\n | \r\n
| \r\n FAU_ARP \r\n | \r\n \r\n FAU: Security audit\r\n automatic response \r\n | \r\n \r\n FAU: Phản hồi tự động\r\n kiểm toán an toàn \r\n | \r\n
| \r\n FAU_GEN \r\n | \r\n \r\n FAU: Security audit\r\n data generation \r\n | \r\n \r\n FAU: Tạo dữ liệu kiểm\r\n toán an toàn \r\n | \r\n
| \r\n FAU_SAA \r\n | \r\n \r\n FAU: Security audit\r\n analysis \r\n | \r\n \r\n FAU: Phân tích kiểm\r\n toán an toàn \r\n | \r\n
| \r\n FAU | \r\n \r\n FAU: Security audit\r\n review \r\n | \r\n \r\n FAU: Soát xét kiểm\r\n toán an toàn \r\n | \r\n
| \r\n FAU_SEL \r\n | \r\n \r\n FAU: Security audit\r\n event selection \r\n | \r\n \r\n FAU: Lựa chọn sự kiện\r\n kiểm toán an toàn \r\n | \r\n
| \r\n FAU_STG \r\n | \r\n \r\n FAU: Security audit\r\n event storage \r\n | \r\n \r\n FAU: Lưu trữ sự kiện\r\n kiểm toán an toàn \r\n | \r\n
| \r\n FCO \r\n | \r\n \r\n Function\r\n Communication \r\n | \r\n \r\n Lớp FCO: | \r\n
| \r\n FCO_NRO \r\n | \r\n \r\n FCO_NRO:\r\n Non-repudiation of origin \r\n | \r\n \r\n FCO_NRO: Không từ\r\n chối nguồn gốc \r\n | \r\n
| \r\n FCO_NRR \r\n | \r\n \r\n FCO_NRR:\r\n Non-repudiation of receipt \r\n | \r\n \r\n FCO_NRR: Không từ\r\n chối khi nhận \r\n | \r\n
| \r\n FCS \r\n | \r\n \r\n Function\r\n Cryptographic support \r\n | \r\n \r\n Lớp FCS: Hỗ trợ mật\r\n mã \r\n | \r\n
| \r\n FCS_CKM \r\n | \r\n \r\n FCS_CKM:\r\n Cryptographic key management \r\n | \r\n \r\n FCS_CKM: Quản lý\r\n khóa mật mã \r\n | \r\n
| \r\n FCS_COP \r\n | \r\n \r\n FCS_COP:\r\n Cryptographic operation \r\n | \r\n \r\n FCS_COP: Hoạt động\r\n mật mã \r\n | \r\n
| \r\n FDP \r\n | \r\n \r\n Function User Data\r\n Protection \r\n | \r\n \r\n Lớp FDP: Bảo vệ dữ\r\n liệu người dùng \r\n | \r\n
| \r\n FDP_ACC \r\n | \r\n \r\n FDP: | \r\n \r\n FDP: Chính sách ki | \r\n
| \r\n FDP_ACF \r\n | \r\n \r\n FDP: | \r\n \r\n FDP: Các chức năng\r\n kiểm soát truy nhập \r\n | \r\n
| \r\n FDP_DAU \r\n | \r\n \r\n FDP: | \r\n \r\n FDP_DAU: Xác thực dữ\r\n liệu \r\n | \r\n
| \r\n FDP_ETC \r\n | \r\n \r\n FDP: | \r\n \r\n FDP_ETC: Xuất dữ liệu\r\n ra khỏi TOE \r\n | \r\n
| \r\n FDP_IFC \r\n | \r\n \r\n FDP: | \r\n \r\n FDP | \r\n
| \r\n FDP_IFF \r\n | \r\n \r\n FDP: | \r\n \r\n FDP_IFF: Các chức\r\n năng kiểm soát luồng tin \r\n | \r\n
| \r\n FDP_ITC \r\n | \r\n \r\n FDP: | \r\n \r\n FDP_ITC: Nhập dữ liệu\r\n từ bên ngoài TOE \r\n | \r\n
| \r\n FDP_ITT \r\n | \r\n \r\n FDP: | \r\n \r\n FDP_ITT: Vận chuyển\r\n nội bộ TOE \r\n | \r\n
| \r\n FDP_RIP \r\n | \r\n \r\n FDP: | \r\n \r\n FDP_RIP: Bảo vệ\r\n thông tin còn sót lại. \r\n | \r\n
| \r\n FDP_ROL \r\n | \r\n \r\n FDP: | \r\n \r\n FDP_ROL: Khôi phục\r\n lại \r\n | \r\n
| \r\n FDP_SDI \r\n | \r\n \r\n FDP: | \r\n \r\n FDP_SDI: Toàn vẹn dữ\r\n liệu đã lưu trữ \r\n | \r\n
| \r\n FDP_UCT \r\n | \r\n \r\n FDP: | \r\n \r\n FDP_UCT: Bảo vệ\r\n truyền bí mật dữ liệu\r\n người dùng liên - TSF \r\n | \r\n
| \r\n FDP_UIT \r\n | \r\n \r\n FDP: | \r\n \r\n FDP_UIT: Bảo vệ\r\n truyền vẹn toàn dữ liệu người dùng liên -TSF \r\n | \r\n
| \r\n FIA \r\n | \r\n \r\n Function Identi | \r\n \r\n Lớp FIA: Định danh\r\n và xác thực \r\n | \r\n
| \r\n FIA_AFL \r\n | \r\n \r\n FIA_AFL:\r\n Authentication failures \r\n | \r\n \r\n FIA_AFL: Các l | \r\n
| \r\n FIA_ATD \r\n | \r\n \r\n FIA_ATD: User\r\n attribute definition \r\n | \r\n \r\n FIA_ATD: Định nghĩa\r\n thuộc tính người dùng \r\n | \r\n
| \r\n FIA_SOS \r\n | \r\n \r\n FIA_SOS:\r\n Specification of secrets \r\n | \r\n \r\n FIA_SOS: Đặc tả các\r\n bí mật \r\n | \r\n
| \r\n FIA_UAU \r\n | \r\n \r\n FIA_UAU: User\r\n Authentication \r\n | \r\n \r\n FIA_UAU: Xác thực\r\n người dùng \r\n | \r\n
| \r\n FIA_UID \r\n | \r\n \r\n FIA_UID: User\r\n identification \r\n | \r\n \r\n FIA_UID: Định danh\r\n người dùng \r\n | \r\n
| \r\n FIA_USB \r\n | \r\n \r\n FIA_USB:\r\n User-subject binding \r\n | \r\n \r\n FIA_USB: Liên kết\r\n người dùng-chủ thể \r\n | \r\n
| \r\n FMT \r\n | \r\n \r\n Function Security\r\n Management \r\n | \r\n \r\n Lớp FMT: Quản lý an\r\n toàn \r\n | \r\n
| \r\n FMT_MOF \r\n | \r\n \r\n FMT_MOF: Management\r\n of functions in TSF \r\n | \r\n \r\n FMT_MOF: Quản lý\r\n các chức năng trong TSF \r\n | \r\n
| \r\n FMT_MSA \r\n | \r\n \r\n FMT_MSA: Management\r\n of Security attributes \r\n | \r\n \r\n FMT_MSA: Quản lý\r\n các thuộc tính an toàn \r\n | \r\n
| \r\n FMT_MTD \r\n | \r\n \r\n FMT_MTD: Management\r\n of TSF data \r\n | \r\n \r\n FMT_MTD: Quản lý dữ\r\n liệu TSF \r\n | \r\n
| \r\n FMT_REV \r\n | \r\n \r\n FMT_REV: Revocation \r\n | \r\n \r\n FMT_REV: Hủy bỏ \r\n | \r\n
| \r\n FMT_SAE \r\n | \r\n \r\n FMT_SAE: Security\r\n attribute expiration \r\n | \r\n \r\n FMT_SAE: Các thuộc\r\n tính an toàn quá hạn \r\n | \r\n
| \r\n FMT_SMF \r\n | \r\n \r\n FMT_SMF: Speci | \r\n \r\n FMT_SMF: Đặc tả các\r\n chức năng quản lý \r\n | \r\n
| \r\n FMT_SMR \r\n | \r\n \r\n FMT_SMR: Security\r\n Management roles \r\n | \r\n \r\n FMT_SMR: Các vai\r\n trò quản lý an toàn \r\n | \r\n
| \r\n FPR \r\n | \r\n \r\n Function Privacy \r\n | \r\n \r\n Lớp FPR: Riêng tư \r\n | \r\n
| \r\n FPR_ANO \r\n | \r\n \r\n FPR_ANO: Anonymity \r\n | \r\n \r\n FPR_ANO: Nặc danh \r\n | \r\n
| \r\n FPR_PSE \r\n | \r\n \r\n FPR_PSE:\r\n Pseudonymity \r\n | \r\n \r\n FPR_PSE: Biệt danh \r\n | \r\n
| \r\n FPR_UNL \r\n | \r\n \r\n FPR_UNL:\r\n Unlinkability \r\n | \r\n \r\n FPR_UNL: Không thể\r\n liên kết \r\n | \r\n
| \r\n FPR_UNO \r\n | \r\n \r\n FPR_UNO:\r\n Unobservability \r\n | \r\n \r\n FPR_UNO: Không thể\r\n quan sát \r\n | \r\n
| \r\n FPT \r\n | \r\n \r\n Function Protection\r\n of the TSF \r\n | \r\n \r\n Lớp FPT: Bảo vệ TSF \r\n | \r\n
| \r\n FPT_FLS \r\n | \r\n \r\n FPT_FLS: | \r\n \r\n FPT_FLS: An toàn\r\n khi có lỗi \r\n | \r\n
| \r\n FPT_ITA \r\n | \r\n \r\n FPT_ITA: | \r\n \r\n FPT_ITA:Tính sẵn\r\n sàng của dữ liệu TSF xuất ra \r\n | \r\n
| \r\n FPT_ITC \r\n | \r\n \r\n FPT_ITC: | \r\n \r\n FPT_ITC: Tính bí mật\r\n của dữ liệu TSF xuất ra \r\n | \r\n
| \r\n FPT_ITL \r\n | \r\n \r\n FPT_ITL: | \r\n \r\n FPT_ITL: Tính toàn\r\n vẹn của dữ liệu TSF xuất ra \r\n | \r\n
| \r\n FPT_ITT \r\n | \r\n \r\n FPT_ITT: Internal\r\n TOE TSF data transfer \r\n | \r\n \r\n FPT_ITT: Vận chuyển\r\n dữ liệu nội bộ TOE TSF \r\n | \r\n
| \r\n FPT_PHP \r\n | \r\n \r\n FPT_PHP: TSF\r\n physical protection \r\n | \r\n \r\n FPT_PHP: Bảo vệ vật\r\n lý cho TSF \r\n | \r\n
| \r\n FPT_RCV \r\n | \r\n \r\n FPT_RCV:Trusted\r\n recovery \r\n | \r\n \r\n FPT_RCV: Khôi phục\r\n tin cậy \r\n | \r\n
| \r\n FPT_RPL \r\n | \r\n \r\n FPT_RPL: Replay\r\n detection \r\n | \r\n \r\n FPT_RPL: Phát hiện\r\n chạy lại \r\n | \r\n
| \r\n FPT_SSP \r\n | \r\n \r\n FPT_SSP: | \r\n \r\n FPT_SSP: Giao thức\r\n đồng bộ trạng thái \r\n | \r\n
| \r\n FPT_STM \r\n | \r\n \r\n FPT_STM: Time\r\n stamps \r\n | \r\n \r\n FPT_STM: Các nhãn\r\n thời gian \r\n | \r\n
| \r\n FPT_TDC \r\n | \r\n \r\n FPT_TDC: lnter-TSF\r\n TSF data consistency \r\n | \r\n \r\n FPT_TDC: Sự nhất\r\n quán dữ liệu TSF liên TSF \r\n | \r\n
| \r\n FPT_TEE \r\n | \r\n \r\n FPT_TEE: Testing of\r\n external entitites \r\n | \r\n \r\n FPT_TEE: Kiểm thử\r\n các thực thể bên ngoải \r\n | \r\n
| \r\n FPT_TRC \r\n | \r\n \r\n FPT_TRC: Internal\r\n TOE TSF data replication consistency \r\n | \r\n \r\n FPT_TRC:Tính nhất\r\n quán của bản sao dữ liệu nội bộ của TOE TSF \r\n | \r\n
| \r\n FPT_TST \r\n | \r\n \r\n FPT_TST: TSF\r\n selftest \r\n | \r\n \r\n FPT_TST: Tự kiểm\r\n tra TSF \r\n | \r\n
| \r\n FRU \r\n | \r\n \r\n Function Resource\r\n utilisation \r\n | \r\n \r\n Lớp FRU: Sử dụng\r\n tài nguyên \r\n | \r\n
| \r\n FRU_FLT \r\n | \r\n \r\n FRU_FLT: Fault\r\n tolerance \r\n | \r\n \r\n FRU_FLT: Khả năng\r\n chịu lỗi \r\n | \r\n
| \r\n FRU_PRS \r\n | \r\n \r\n FRU_PRS: Priority\r\n of Service \r\n | \r\n \r\n FRU_PRS: ưu tiên dịch\r\n vụ \r\n | \r\n
| \r\n FRU_RSA \r\n | \r\n \r\n FRU_RSA: Resource\r\n allocation \r\n | \r\n \r\n FRU_RSA: cấp phát\r\n tài nguyên \r\n | \r\n
| \r\n FTA \r\n | \r\n \r\n Function TOE Access \r\n | \r\n \r\n Lớp FTA: Truy nhập\r\n TOE \r\n | \r\n
| \r\n FTA_LSA \r\n | \r\n \r\n FTA_LSA: | \r\n \r\n FTA_LSA: | \r\n
| \r\n FTA_MCS \r\n | \r\n \r\n FTA_MCS: Limitation\r\n on multiple concurrent sessions \r\n | \r\n \r\n FTA_MCS: Giới hạn số\r\n lượng phiên đồng thời \r\n | \r\n
| \r\n FTA_SSL \r\n | \r\n \r\n FTA_SSL: Session\r\n locking and termination \r\n | \r\n \r\n FTA_SSL: Khoa phiên\r\n và kết thúc \r\n | \r\n
| \r\n FTA_TAB \r\n | \r\n \r\n FTA_TAB: TOE access\r\n banners \r\n | \r\n \r\n FTA_TAB: Các tiêu đề\r\n truy nhập TOE \r\n | \r\n
| \r\n FTA_TAH \r\n | \r\n \r\n FTA_TAH: TOE access\r\n history \r\n | \r\n \r\n FTA_TAH: Lịch sử\r\n truy cập TOE \r\n | \r\n
| \r\n FTA_TSE \r\n | \r\n \r\n FTA_TSE: TOE\r\n session establishment \r\n | \r\n \r\n FTA_TSE: Thiết lập\r\n phiên TOE \r\n | \r\n
| \r\n FTP \r\n | \r\n \r\n Function Trusted\r\n Path/Channel \r\n | \r\n \r\n Lớp FTP: Tuyến/Kênh\r\n tin cậy \r\n | \r\n
| \r\n FTP_ITC \r\n | \r\n \r\n FTP_ITC: lnter-TSF\r\n trusted channel \r\n | \r\n \r\n FTP | \r\n
| \r\n FTP_TRP \r\n | \r\n \r\n FTP_TRP: Trusted\r\n path \r\n | \r\n \r\n FTP_TRP: Đường dẫn\r\n tin cậy \r\n | \r\n
| \r\n GHz \r\n | \r\n \r\n Gigahertz \r\n | \r\n \r\n Số đo tần số\r\n Gigahertz \r\n | \r\n
| \r\n GUI \r\n | \r\n \r\n Graphical User\r\n Interface \r\n | \r\n \r\n Giao diện người\r\n dùng dạng đồ họa \r\n | \r\n
| \r\n IC \r\n | \r\n \r\n Integrated Circuit \r\n | \r\n \r\n Mạch tổ hợp \r\n | \r\n
| \r\n IOCTL \r\n | \r\n \r\n Input Output\r\n Control \r\n | \r\n \r\n Kiểm soát vào ra \r\n | \r\n
| \r\n IP \r\n | \r\n \r\n Internet Protocol \r\n | \r\n \r\n Giao thức Internet \r\n | \r\n
| \r\n IT \r\n | \r\n \r\n lnformation\r\n Technology \r\n | \r\n \r\n Công nghệ thông tin\r\n (CNTT) \r\n | \r\n
| \r\n MB \r\n | \r\n \r\n Mega Byte \r\n | \r\n \r\n Đơn vị thông tin\r\n Mega Byte (MB) \r\n | \r\n
| \r\n OS \r\n | \r\n \r\n Operating System \r\n | \r\n \r\n Hệ điều hành \r\n | \r\n
| \r\n OSP \r\n | \r\n \r\n Organizational\r\n Security Policy \r\n | \r\n \r\n Chính sách an toàn\r\n của tổ chức \r\n | \r\n
| \r\n PC \r\n | \r\n \r\n Personal Computer \r\n | \r\n \r\n Máy tính cá nhân \r\n | \r\n
| \r\n PCI \r\n | \r\n \r\n Peripheral\r\n Component Interconnect \r\n | \r\n \r\n Liên kết nối các\r\n thành phần ngoại vi \r\n | \r\n
| \r\n PKI \r\n | \r\n \r\n Public Key In | \r\n \r\n Hạ tầng cơ sở khóa\r\n công khai \r\n | \r\n
| \r\n PP \r\n | \r\n \r\n Protection Pro | \r\n \r\n Hồ sơ bảo vệ \r\n | \r\n
| \r\n RAM \r\n | \r\n \r\n Random Access\r\n Memory \r\n | \r\n \r\n Bộ nhớ truy nhập ngẫu\r\n nhiên \r\n | \r\n
| \r\n RPC \r\n | \r\n \r\n Remote Procedure\r\n Call \r\n | \r\n \r\n Lời gọi thủ tục từ\r\n xa \r\n | \r\n
| \r\n SAR \r\n | \r\n \r\n Security | \r\n \r\n Yêu cầu đảm b | \r\n
| \r\n SF \r\n | \r\n \r\n Security Function \r\n | \r\n \r\n Chức năng an toàn \r\n | \r\n
| \r\n SFR \r\n | \r\n \r\n Security Functional\r\n Requirement \r\n | \r\n \r\n Yêu cầu chức năng\r\n an toàn \r\n | \r\n
| \r\n SFP \r\n | \r\n \r\n Secur | \r\n \r\n Chính sách chức\r\n năng an toàn \r\n | \r\n
| \r\n SPD \r\n | \r\n \r\n Security Problem De | \r\n \r\n Định nghĩa vấn đề\r\n an toàn \r\n | \r\n
| \r\n SOF \r\n | \r\n \r\n Strength\r\n of Function \r\n | \r\n \r\n Độ mạnh của chức\r\n năng \r\n | \r\n
| \r\n ST \r\n | \r\n \r\n Security Target \r\n | \r\n \r\n Đích an toàn \r\n | \r\n
| \r\n TCP \r\n | \r\n \r\n Transmission\r\n Control Protocol \r\n | \r\n \r\n Giao thức điều khiển\r\n truyền tải \r\n | \r\n
| \r\n TOE \r\n | \r\n \r\n Target of\r\n Evaluation \r\n | \r\n \r\n Đích đánh giá \r\n | \r\n
| \r\n TSC \r\n | \r\n \r\n TSF Scope of\r\n Control \r\n | \r\n \r\n Phạm vi giám sát\r\n TSF \r\n | \r\n
| \r\n TSF \r\n | \r\n \r\n TOE Security\r\n Functions \r\n | \r\n \r\n Các chức năng an\r\n toàn của TOE \r\n | \r\n
| \r\n TSFI \r\n | \r\n \r\n TSF Inter | \r\n \r\n Giao diện TSF \r\n | \r\n
| \r\n TSP \r\n | \r\n \r\n TOE Security Policy \r\n | \r\n \r\n Ch | \r\n
| \r\n VPN \r\n | \r\n \r\n Virtual Private Net | \r\n \r\n Mạng riêng ảo \r\n | \r\n
\r\n\r\n
Lời giới thiệu
1.
2.
3.
3.1. Các\r\nthuật ngữ và định nghĩa chung trong TCVN 8709 ………………………………………
\r\n\r\n3.2. Các\r\nthuật ngữ và định
3.3. Các\r\nthuật ngữ và định
3.4. Các\r\nthuật ngữ và định
3.5. Các\r\nthuật ngữ và định
3.6. Các\r\nthuật ngữ và định
4.
5.
5.1.
5.2.
5.2.1. Các\r\nmô tả khác nhau về TOE …………………………………………………………………
\r\n\r\n5.2.2.
5.3.
5.3.1.
5.3.2.
5.3.3. Đánh\r\ngiá viên ………………………………………………………………………………….
\r\n\r\n5.3.4. Các\r\nđối tượng khác …………………………………………………………………………..
\r\n\r\n5.4. Các\r\nphần khác nhau của bộ tiêu chuẩn ……………………………………………………..
\r\n\r\n5.5.
6.
6.1. Giới\r\nthiệu mô hình tổng quát ………………………………………………………………….
\r\n\r\n6.2. Tài\r\nsản và các biện pháp đối phó ……………………………………………………………..
\r\n\r\n6.2.1.
6.2.2.
6.2.3. Tính\r\nchính xác của môi
6.3. Đánh\r\ngiá …………………………………………………………………………………………….
\r\n\r\n7.
7.1. Các\r\nhoạt động ……………………………………………………………………………………..
\r\n\r\n7.1.1.
7.1.2.
7.1.3. Hoạt\r\nđộng lựa chọn …………………………………………………………………………….
\r\n\r\n7.1.4. Hoạt\r\nđộng bổ sung chi tiết …………………………………………………………………….
\r\n\r\n7.2.
7.3. Các\r\nthành phần mở rộng ………………………………………………………………………..
\r\n\r\n8.
8.1. Giới\r\nthiệu ………………………………………………………………………………………….
\r\n\r\n8.2. Các\r\ngói ……………………………………………………………………………………………
\r\n\r\n8.3. Các\r\nhồ sơ bảo vệ ………………………………………………………………………………..
\r\n\r\n8.4. Sử dụng\r\nPP và các gói
8.5. Sử dụng\r\nnhiều Hồ sơ bảo vệ ………………………………………………………………….
\r\n\r\n9.
9.1. Giới\r\nthiệu ………………………………………………………………………………………….
\r\n\r\n9.2. Các\r\nkết quả đánh giá PP ……………………………………………………………………….
\r\n\r\n9.3. Các\r\nkết quả đánh giá ST/TOE …………………………………………………………………
\r\n\r\n9.4.\r\nTuyên bố tuân thủ ……………………………………………………………………………….
\r\n\r\n9.5. Sử dụng\r\ncác kết quả đánh giá ST/TOE ………………………………………………………
\r\n\r\nPhụ lục A_(Tham khảo)_Đặc\r\ntả của các đích an toàn
Phụ lục B_(Tham khảo)_Đặc\r\ntả của Hồ sơ bảo vệ PP ………………………………………
\r\n\r\nPhụ lục C_(Tham khảo)_Hướng\r\ndẫn vận hành ………………………………………………
\r\n\r\nPhụ lục D_(Tham khảo)_Tuân\r\nthủ PP ………………………………………………………….
\r\n\r\nTh
CÁC THUẬT NGỮ S
CÁC KÝ HIỆU VÀ TỪ VI
File gốc của 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 đang được cập nhật.
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
Tóm tắt
| Cơ quan ban hành | Đã xác định |
| Số hiệu | TCVN8709-1:2011 |
| Loại văn bản | Tiêu chuẩn Việt Nam |
| Người ký | Đã xác định |
| Ngày ban hành | 2011-01-01 |
| Ngày hiệu lực | |
| Lĩnh vực | Xây dựng - Đô thị |
| Tình trạng | Còn hiệu lực |