Soát xét đầu ra

Một phần của tài liệu TCVN :CÔNG NGHỆ THÔNG TIN – KỸ THUẬT AN TOÀN – HƯỚNG DẪN CHO CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG CHO TÍNH LIÊN TỤC NGHIỆP VỤ (Trang 37)

8 Theo dõi và soát xét

8.3.3 Soát xét đầu ra

Đầu ra từ việc soát xét phải được ký duyệt bởi lãnh đạo cao nhất và bao gồm: a) Thay đổi phạm vi của hệ thống quản lý IRBC;

c) Các yêu cầu sửa đổi IRBC, bao gồm định nghĩa dịch vụ ICT, danh sách tài liệu các dịch vụ ICT trọng yếu và các rủi ro liên quan đến việc xác định khoảng trống giữa khả năng sẵn sàng ICT trọng yếu và các yêu cầu tính liên tục nghiệp vụ;

d) Sửa đổi các thủ tục và chiến lược IRBC khi cần thiết để đáp ứng tới các sự kiện bên ngoài và/hoặc bên trong mà có thể ảnh hưởng đến các dịch vụ ICT, bao gồm các thay đổi

i) Yêu cầu tính liên tục nghiệp vụ; ii) Yêu cầu khả năng phục hồi;

iii) Mức độ rủi ro và/hoặc mức độ rủi ro có thể chấp nhận. e) Nhu cầu về tài nguyên;

f) Các yêu cầu về kinh phí và ngân sách.

8.4 Tiêu chí hiệu năng sự sẵn sàng ICT8.4.1 Giám sát và đo lường sự sẵn sàng ICT 8.4.1 Giám sát và đo lường sự sẵn sàng ICT

Các tổ chức phải giám sát và đo lường sự sẵn sàng ICT của mình thông qua việc thực hiện các quy trình đo lường tiêu chí hiệu năng sẵn sàng ICT đã xác định (xem 6.7).

8.4.2 Định lượng và định tính tiêu chí hiệu năng

Tiêu chí hiệu năng cho IRBC phải được định tính và định lượng. Tiêu chí định lượng có thể bao gồm:

a) Trong một thời gian nhất định, số lượng các sự cố chưa được phát hiện trước khi gián đoạn (điều này có thể cung cấp một chỉ số hoàn thành của các cơ chế phát hiện và cảnh báo);

b) Thời gian phát hiện các sự cố;

c) Số lượng các sự cố không thể ngăn chặn hiệu quả để giảm thiểu tác động;

d) Tính sẵn sàng của các nguồn dữ liệu để cho biết sự khẩn cấp của các sự cố thông qua giám sát xu hướng các sự kiện;

e) Thời gian phản ứng lại các sự cố khẩn cấp đã phát hiện.

Tiêu chí định tính mang tính chủ quan khi được sử dụng để nhận biết hiệu năng của IRBC nhưng thường đòi hỏi ít tài nguyên trong quy trình đo lường (có thể thích hợp cho một tổ chức quy mô vừa và nhỏ đó là tùy thuộc vào nguồn tài nguyên hạn chế). Nó có thể bao gồm việc nhận biết hiệu quả của các quy trình được sử dụng trong hoạch định, chuẩn bị và thực thi các hoạt động của IRBC và có thể được đánh giá thông qua:

a) Khảo sát sử dụng bảng câu hỏi có cấu trúc hoặc không có cấu trúc; b) Thông tin phản hồi từ các bên tham gia và các bên liên quan; c) Tiến hành hội thảo phản hồi;

9 Cải tiến IRBC

9.1 Cải tiến liên tục

Tổ chức cần cải tiến liên tục IRBC thông qua việc áp dụng các hành động ngăn chặn và khắc phục phù hợp với các tác động tiềm ẩn được nhận biết bằng cách phân tích các tác động nghiệp vụ của tổ chức và chấp nhận rủi ro của nó.

9.2 Hành động sửa lỗi

Tổ chức nên có hoạt động để sửa chữa bất kỳ các lỗi trên thực tế của dịch vụ ICT và các yếu tố của IRBC. Các thủ tục tài liệu về hành động khắc phục phải xác định các yêu cầu để:

a) Xác định các lỗi;

b) Xác định nguyên nhân của lỗi;

c) Ước lượng sự cần thiết phải hành động để đảm bảo sự không phù hợp không tái diễn; d) Xác định và thực hiện các hành động khắc phục cần thiết;

e) Ghi nhận các kết quả của hành động đưa ra; f) Soát xét các hành động khắc phục đã thực hiện.

9.3 Hành động phòng ngừa

Tổ chức cần xác định các điểm yếu tiềm ẩn trong các yếu tố của IRBC và thiết lập một thủ tục tài liệu để:

a) Xác định các lỗi tiềm ẩn; b) Xác định nguyên nhân của lỗi;

c) Nhận biết và thực hiện các hành động phòng ngừa cần thiết; d) Ghi lại và soát xét các kết quả của hành động đã đưa ra.

Phụ lục A

(tham khảo)

IRBC và các mốc trong một gián đoạn

Hình A.1 minh họa các phần tử của IRBC hỗ trợ các mốc chính trong một gián đoạn. Các sự kiện và các mốc quan trọng xảy ra theo thời gian bắt đầu từ thời điểm gốc (thời điểm gốc - thời điểm gián đoạn bắt đầu xảy ra) khi một sự kiện dịch vụ gián đoạn/thảm họa ICT xảy ra. Một ví dụ về kịch bản thảm họa là một trong những phát sinh từ cuộc tấn công xâm nhập nhắm vào mục tiêu của hệ thống (thường được gọi là “hacking”) vào các hệ thống ICT trọng yếu của tổ chức.

RPO liên quan đến lượng dữ liệu bị mất và không thể phục hồi do gián đoạn. Điều này được thể hiện trên luồng thời gian là khoảng thời gian giữa lần sao lưu tốt nhất cuối cùng và thời điểm gián đoạn xảy ra. Các RPO thay đổi tùy theo chiến lược phục hồi dịch vụ ICT đã áp dụng, đặc biệt là việc sắp xếp sao lưu.

Tại thời điểm gốc hệ thống ICT trọng yếu đã bị tin tặc xâm nhập và các dịch vụ đã bị ảnh hưởng. Mốc quan trọng đầu tiên sau khi gián đoạn dịch vụ xảy ra là việc phát hiện trực tiếp sự cố an toàn (tức là sự kiện xâm nhập) hoặc sự phát hiện trực tiếp việc mất dịch vụ (hoặc suy giảm), mà sẽ có một khoảng thời gian đã trôi qua trước khi thông báo; ví dụ, trong một số trường hợp thông báo gián đoạn phải đi qua một cuộc gọi tới trung tâm hỗ trợ IT từ một người dùng.

Thời gian có thể tiếp tục trôi qua trong khi gián đoạn dịch vụ ICT được điều tra, phân tích, truyền đạt và đưa ra quyết định để gọi IRBC. Có thể mất vài giờ từ thời điểm bắt đầu gián đoạn dịch vụ ICT cho tới khi một quyết định gọi IRBC được đưa ra khi thời gian truyền đạt và làm quyết định được tính đến. Quyết định gọi có thể phải yêu cầu xem xét cẩn thận trong một số trường hợp, ví dụ khi dịch vụ chưa hoàn toàn bị mất hoặc khả năng phục hồi dịch vụ sắp được thực hiện, do quyết định gọi IRBC thường tác động vào hoạt động nghiệp vụ thông thường.

Khi đã được gọi, việc phục hồi dịch vụ ICT có thể bắt đầu. Việc này có thể được chia thành phục hồi cơ sở hạ tầng (mạng, phần cứng, hệ điều hành, phần mềm sao lưu,...) và phục hồi ứng dụng (cơ sở dữ liệu, ứng dụng, các quy trình xử lý hàng loạt, các giao diện). (Tham khảo thêm tiêu chuẩn ISO/IEC 24762).

Một khi dịch vụ ICT đã được phục hồi và việc thử nghiệm hệ thống đã được thực hiện bởi nhân viên ICT thì dịch vụ có thể được cung cấp cho người sử dụng kiểm tra nghiệm thu trước khi nó được phát hành tới nhân viên để sử dụng trong tính liên tục nghiệp vụ.

Từ góc độ tính liên tục nghiệp vụ, có một RTO cho mỗi sản phẩm, dịch vụ hoặc hoạt động và RTO này bắt đầu từ thời điểm gián đoạn xảy ra và kéo dài cho tới khi sản phẩm, dịch vụ hoặc hoạt động được phục hồi, nhưng có thể một số dịch vụ ICT yêu cầu có tính năng này, và mỗi dịch vụ ICT có thể bao gồm một số hệ thống hoặc ứng dụng ICT. Mỗi phần tử hệ thống hoặc ứng dụng ICT có RTO của mình là một tập RTO dịch vụ ICT đầu-cuối và phải ít hơn so với RTO của tính liên tục nghiệp vụ, đưa vào được tính đến phát hiện và quyết định thời gian và người dụng kiểm tra nghiệm thu thời gian thử

nghiệm (trừ khi tính liên tục nghiệp vụ sản phẩm, dịch vụ, và hoạt động có thể được hỗ trợ không có ICT trong một khoảng thời gian, ví dụ sử dụng các thủ tục thủ công).

Các dịch vụ ICT đã phục hồi thường hoạt động trong một khoảng thời gian hành động tính liên tục nghiệp vụ hỗ trợ và nếu việc này mở rộng khoảng thời gian sau khi các dịch vụ ICT đã phục hồi có thể cần phải mở rộng để hỗ trợ tăng số lượng hành động giao dịch, có khả năng tăng tới điểm mà sản phẩm, dịch vụ, hoặc hành động đã phục hồi hoàn toàn đạt tới trạng thái số lượng giao dịch bình thường.

Sau đó, tại một số thời điểm trên luồng thời gian, việc phục hồi sẽ có khả năng và các hoạt động DR sẽ được đưa trở lại các hoạt động bình thường. Các hoạt động đã trở lại bình thường có thể ở môi trường hoặc trạng thái bắt đầu trước gián đoạn, hoặc một thỏa thuận hoạt động mới (đặc biệt khi thảm họa gián đoạn bắt buộc phải thay đổi nghiệp vụ).

Trong khi nhân viên ICT có cơ hội để lên kế hoạch phục hồi cẩn thận và lập lịch để kế hoạch đó diễn ra trong khoảng thời gian hoạt động thấp, đây vẫn là một công việc quan trọng trong quyền của nó

Các mũi tên trên sơ đồ chỉ ra nguyên tắc của IRBC trong chuẩn ISO/IEC 27031 kết hợp với dòng thời gian gián đoạn.

Phụ lục B

(tham khảo)

Hệ thống nhúng sẵn sàng cao

Trong công nghệ thông tin và truyền thông, “tính sẵn sàng cao” đề cập tới các hệ thống hoặc phần tử có hoạt động liên lục cho một khoảng thời gian dài. Tính sẵn sàng cao có thể được đo tương đối tới “hoạt động 100%” hoặc “không bao giờ lỗi”. Có một phạm vi rộng nhưng khó để đạt được chuẩn tính sẵn sàng cho hệ thống hoặc sản phẩm được biết như là sẵn sàng “năm số 9” (99.999%)

Một hệ thống hoặc mạng máy tính được tạo thành từ nhiều phần tử, tất cả trong số đó đều thường phải có mặt và chức năng để cho toàn bộ đi vào hoạt động, và trong khi hoạch định cho tính sẵn sàng cao thường tập trung vào sao lưu và xử lý dự phòng lỗi, lưu trữ và truy cập dữ liệu, các thành phần khác như nguồn điện, làm mát là quan trọng không kém.

Ví dụ, tính sẵn sàng nguồn điện có thể được đảm bảo bằng các biện pháp như: a) Bộ lưu điện UPS;

b) Máy phát điện khẩn cấp;

c) Hai nguồn điện song song từ một lưới điện.

Sao lưu dữ liệu và tính sẵn sàng có thể đạt được bằng cách sử dụng một loạt các công nghệ lưu trữ như mảng dư thừa ổ đĩa RAID, mạng lưu trữ SAN.

Tính sẵn sàng ứng dụng cũng cần được xem xét và thường đạt được thông qua công nghệ “Song hành”

Các công nghệ này chỉ có thể thực sự hiệu quả trong việc cung cấp tính sẵn sàng cao thông qua việc thực hiện đồng thời ở một hoặc nhiều vị trí. Ví dụ đơn giản có một máy chủ “dự phòng lỗi” ở cùng một vị trí như một máy chủ chính hoặc “sản xuất” là không cung cấp mức độ cần thiết khả năng phục hồi nếu vị trí này bị ảnh hưởng bởi cùng một gián đoạn nghiêm trọng. Cả hai máy chủ sẽ bị ảnh hưởng bởi cùng một gián đoạn. Máy chủ “dự phòng lỗi” và các công nghệ có thể được đặt ở các vị trí khác nhau để đạt được các mức độ của tính sẵn sàng.

Với nhiều tổ chức, chi phí và nỗ lực liên quan để đạt được mức độ sẵn sàng cao có thể gặp khó khăn và trong những năm gần đây đã có sự phát triển trong việc sử dụng nhà cung cấp dịch vụ thứ ba, bêncó thể cung cấp các kỹ năng, tài nguyên và công nghệ mềm dẻo với mức giá có thể chấp nhận hoặc thông qua các dịch vụ điện toán đám mây.

Tuy nhiên khi tính sẵn sàng cao là cách hiệu quả để tăng khả năng phục hồi, thì khả năng lỗi vẫn còn. Vì vậy việc hoạch định và thử nghiệm các quy trình DR và các thủ thục cũng quan trọng.

Phụ lục C

(tham khảo)

Đánh giá kịch bản lỗi

C.1 Tổng quát

Một loạt kỹ thuật quản lý rủi rõ tiềm ần tồn tại có thể bao gồm việc đánh giá sự sẵn sàng ICT cho BC và việc phát triển khung phù hợp cho phát triển liên tục và nâng cao khả năng phục hồi ICT.

Chuẩn ISO 31010:2009 “Quản lý rủi ro - Các kỹ thuật quản lý rủi ro” cung cấp thực hành tốt nhất trong việc lựa chọn và sử dụng các kỹ thuật đánh giá rủi ro. Có thể tham khảo chuẩn này để xác định kỹ thuật phù hợp nhất được sử dụng trong một tổ chức.

Việc đánh giá các kịch bản lỗi là một kỹ thuật có thể có ích trong việc nâng cao hiệu quả của IRBC và phụ lục này cung cấp thông tin bổ sung về việc làm thế nào nó có thể được thực hiện.

C.2 Phương pháp đánh giá

Vấn đề rủi ro chưa biết có thể xuất hiện giữa các đánh giá như một kết quả của các thay đổi bên trong và bên ngoài môi trường tổ chức mà có thể cản trở tính liên tục và khả năng phục hồi nghiệp vụ. Mục đích của việc đánh giá kịch bản lỗi là để xác định chỉ số các sự kiện phù hợp và đảm bảo các kế hoạch IRBC có khả năng phát hiện các vấn đề rủi ro và chuẩn bị hành động phù hợp có thể được thực hiện trước khi lỗi xảy ra.

Một số phương pháp cụ thể phục vụ sẵn cho mục đích này, bao gồm Phân tích hiệu quả chế độ lỗi (FMEA - Failure Mode Effect Analysis) và Phân tích tác động lỗi phần tử (CFIA - Component Failure Impact Analysis). Nhằm mục đích chứng minh, phụ lục này làm rõ phương pháp FMEA cụ thể mặc dù tổ chức phải chọn phương pháp phù hợp với môi trường và nền tảng của họ.

FMEA là một quy trình để định danh và phân tích chế độ lỗi tiềm ẩn của hệ thống để phân loại bằng mức độ nghiêm trọng và xác định ảnh hưởng của lỗi tới hệ thống. Trong phạm vi tiêu chuẩn này, FMEA có thể được áp dụng để xác định các chỉ số sự kiện quan trọng phải được giám sát để phát hiện các chế độ lỗi tiềm ẩn trong một hệ thống ICT của tổ chức. Quy trình, dựa trên cách tiếp cận FMEA, có thể được áp dụng tới mỗi phần tử trọng yếu của dịch vụ ICT như mô tả trong 6.3.2.

Cho mỗi phần tử trọng yếu: a) Xác định chế độ lỗi tiềm ẩn;

b) Xác định ảnh hưởng tiềm ẩn tới dịch vụ ICT, tức là mức độ nghiêm trọng của mỗi chế độ lỗi, và hậu quả có thể của mỗi kết quả;

c) Xác định tần số xuất hiện chế độ lỗi mà tổ chức phải có kinh nghiệm trước như giám sát và theo dõi chế độ lỗi;

d) Xác định các chỉ số sẽ cung cấp một dấu hiệu hoặc thông tin khi phần tử đang lỗi;

f) Xác định các kiểm soát đang tồn tại để tránh các phần tử quan trọng từ lỗi hoặc có thể phát hiện các lỗi xảy ra.

g) Xác định tài nguyên dữ liệu liên quan, và các phương pháp giám sát có thể phát hiện thay đổi giá trị của các chỉ số, phân loại các chỉ số sự kiện bằng tính sẵn sàng của phương pháp giám sát.

h) Xác định liệu việc giảm hoặc kiểm soát triệt để rủi ro phù hợp có thể được áp dụng để ngăn chặn sự xuất hiện của nó.

C.3 Kết quả đánh giá

Đầu ra FMEA bao gồm danh sách các chế độ lỗi tiềm ẩn và các ảnh hưởng, các sự kiện liên quan có thể được sử dụng để xác định chỉ số sự kiện cần được giám sát.

Các chế độ lỗi đã xác định thông qua quy trình FMEA có thể được ưu tiên theo mức độ nghiêm trọng đã đánh giá, tần số xuất hiện lỗi, và việc dễ dàng giám sát và phát hiện.

Một FMEA cũng ghi nhận kiến thức và các hành động về rủi ro của các lỗi, để sử dụng trong cải tiến tính liên tục. Nếu FMEA được sử dụng trong giai đoạn thiết kế với mục đích để tránh các lỗi trong tương lai thì nó có thể sử dụng cho quy trình kiểm soát trước khi và trong suốt quy trình vận hành. Lý

Một phần của tài liệu TCVN :CÔNG NGHỆ THÔNG TIN – KỸ THUẬT AN TOÀN – HƯỚNG DẪN CHO CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG CHO TÍNH LIÊN TỤC NGHIỆP VỤ (Trang 37)

Tải bản đầy đủ (DOC)

(46 trang)
w