Domain 6 : Business Continuity and Disaster Recovery P.18

{password}

Lĩnh vực Business Continuity and Disaster Recovery đề cập đến những vấn đề sau :

• Những bước khởi đầu dự án (Project)
• Các yêu cầu cần thiết cho việc lập kế hoạch Recovery và Continuity
• Phân tích tác động Business
• Lựa chọn, phát triển và thực hiện kế hoạch phòng chống Thảm Họa và Kinh Doanh Liên Tục
• Backup và cơ sở Offsite
• Các loại diễn tập (drills) và thử nghiệm

Chúng ta không thể nào chuẩn bị, lường trước được mọi khả năng có thể xảy ra giống như các sự kiện trong những năm gần đây. Năm 2005, cơn bão Katrina đã tàn phá, gây ra thiệt hại hết sức nặng nề. Các doanh nghiệp không chỉ đơn thuần bị ảnh hưởng, các tòa nhà của họ bị phá hủy, sự sống của con người bị tước đoạt. Thảm họa sóng thần ở Ấn Độ Dương Tsunami tháng 12 2004.

Tòa tháp trung tâm thương mại thế giới đã bị đổ sụp xuống, ngay sau khi bọn khủng bố đâm máy bay vào chúng, ảnh hưởng nặng nề đến rất nhiều doanh nghiệp, con người, chính phủ, và thế giới, theo một cách mà có nằm mơ mọi người cũng không bao giờ tưởng tượng được.

Mỗi năm, hàng ngàn doanh nghiệp bị ảnh hưởng bởi lũ lụt, hỏa hoạn, lốc xoáy, khủng bố và phá hoại. Các công ty còn sống sót sau những thảm họa này, đa phần là do đã suy nghĩ trước về nó, lên kế hoạch cho tình huống xấu nhất (worst), ước tính thiệt hại có thể xảy ra, và triển khai các kiểm soát cần thiết để bảo vệ bản thân họ. Đây là một tỉ lệ rất nhỏ đối với các doanh nghiệp ngày nay.

Hầu hết các doanh nghiệp bị ảnh hưởng bởi những thảm họa này thường dẫn đến phá sản. Các công ty tồn tại được trong những tình huống tiêu cực, là do họ đã đo lường, phê duyệt thiết lập trước các bước sắp xếp và thủ tục (procedures).

Tổ chức phụ thuộc vào các nguồn tài nguyên, nhân sự, nhiệm vụ, được thực hiện mỗi ngày để giữ gìn sức khỏe, hạnh phúc, và lợi nhuận. Hầu hết các tổ chức đều có nguồn tài hữu hình, tài sản trí tuệ, nhân viên, máy tính, kết nối thông tin liên lạc, cơ sở, và các dịch vụ cơ sở. Nếu một trong những thứ này bị hư hỏng hoặc không thể tiếp cận được vì một lý do gì đó, nói cách khác công ty có thể bị Crippled - Tê liệt.

Nếu có nhiều hơn một bị hư hỏng, công ty có thể phải đối mặt với tình huống tối tệ hơn. Một số tổ chức không bao giờ có thể khôi phục lại được sau thảm họa. Tuy nhiên, có một số tổ chức đã nghĩ trước về những điều này, đã lên kế hoạch để đối mặt với thảm họa có thể xảy ra, họ không "đặt tất cả trứng vào một giỏ", khi đó các tổ chức này có cơ hội sẽ khôi phục lại được kinh doanh và đứng vững trên thương trường.

Business Continuity and Disaster Recovery - Kinh doanh liên tục và Khôi phục thảm họa

Mục tiêu của Disaster Recovery - Khôi phục Thảm Họa là để giảm thiểu những ảnh hưởng của thảm họa và đưa ra các bước cần thiết để đảm bảo tài nguyên, nhân lực, business processes có thể hoạt động trở lại một cách kịp thời. Điều này khác với Business Continuity Planning (BCP) - Lên kế hoạch Kinh Doanh Liên Tục, nhằm cung cấp phương pháp và procedures để đối phó với việc ngừng hoạt động dài hạn (longer-term outages) và thảm họa.

Mục tiêu của Disaster Recovery Plan (DRP) - Kế hoạch Khôi Phục Thảm Họa là để xử lý thảm họa và hậu quả của nó, sau khi thảm họa xảy ra; Disaster Recovery Plan thường tập trung rất nhiều vào CNTT. Disaster Recovery Plan được tiến hành khi mọi thứ vẫn còn nằm trong Emergency Mode, tất cả mọi người đang vật lộn để đưa được Systems quan trọng Online trở lại.

Business Continuity Plan có một cách tiếp cận rộng hơn đối với Problem. Nó bao gồm việc đem tất cả các hệ thống quan trọng đến một môi trường khác, trong khi đang sửa chữa cơ sở ban đầu (original facility), tiến hành kinh doanh trong một chế độ khác cho đến khi trở lại điều kiện thông thường. Nó cũng liên quan đến việc giao dịch với khách hàng, đối tác, và các cổ đông qua các channels khác nhau, cho đến khi mọi thứ trở lại bình thường.

Cho nên, Disaster Recovery tập trung giải quyết việc : "Ôi má ơi, trời đang sập xuống kìa" còn Business Continuity Planning thì : "Thôi, dù sao trời cũng sập rồi. Bây giờ chúng ta làm thế nào để có thể tiếp tục kinh doanh, cho đến khi có siêu anh hùng nào đó đem bầu trời lắp lại chỗ thuộc về nó ?"

Có một Chủ đề liên tục xuyên suốt khắp cuốn sách này chính là : Availability, Integrity, Confidentiality. Bởi vì mỗi Domain có mỗi topic khác nhau, cho nên cách nhìn về 3 yếu tố an ninh này cũng có một chút khác nhau. Trong Domain : Access Control, Availability có nghĩa là tài nguyên cần phải luôn luôn sẵn sàng cho người dùng và các chủ thể, theo một cách an toàn và có kiểm soát. Phương pháp Access Control cần phải bảo vệ được Integrity và Confidentiality của tài nguyên.

Trong thực tế, phương pháp kiểm soát truy cập cần phải qua nhiều bước để đảm bảo tài nguyên luôn được giữ bí mật, và không để xảy ra trường hợp nội dung của nó bị thay đổi trong khi nó đang được truy cập.

Trong Domain : BCP & DRP, sẽ chỉ cho chúng ta thấy rằng Integrity và Confidentiality cần phải được xem xét không chỉ trong các Procedure hàng ngày, mà còn trong những Procedures thuộc dạng thực hiện Immediately - Ngay lập tức, sau khi thảm họa hoặc sự gián đoạn xảy ra. Ví dụ, sẽ không thích hợp cho lắm nếu để lại Server chứa thông tin Confidential của tổ chức trong tòa nhà A, trong khi tất cả mọi người đều chuyển sang tòa nhà B.

Còn một điều nữa mà chúng ta cần phải lưu ý, đó là tổ chức có thể sẽ bị tổn thương nhiều hơn nữa (more vulnerable), sau khi xảy ra thảm họa. Bởi vì Security Services được sử dụng để bảo vệ tổ chức, có thể Unavailable hoặc giảm năng lực hoạt động. Vì vậy, điều quan trọng đó là nếu tổ chức có những thứ Secret, thì nó vẫn phải Secret và Integrity của dữ liệu, hệ thống, cần được đảm bảo ngay cả khi mọi người và tổ chức đang phải đối mặt với những điều thảm khốc.

Availability là một trong 3 chủ đề chính nằm sau Business Continuity Planning, nó đảm bảo rằng các nguồn tài nguyên cần thiết cho Business sẽ vẫn tiếp tục Available cho mọi người và hệ thống, dù cho thảm họa đã xảy ra. Điều này có nghĩa cần phải thực hiện Backups một cách đều đặn, Redundancy - Khả năng dự phòng cần được triển khai cho tất cả các kiến trúc của systems, networks, và operations.

Nếu Communication Lines - Đường liên lạc bị vô hiệu hóa, hoặc Services quan trọng không thể sử dụng được nữa (unusable), cần phải nhanh chóng có ngay biện pháp thay thế (đã được thử nghiệm) cho Communications và Services.

Khi xem xét Business Continuity Planning, đa phần các tổ chức thường chỉ tập trung chủ yếu vào Backup Data và triển khai Redundant Hardware. Mặc dù những hạng mục này cực kỳ quan trọng, nhưng chúng chỉ là những "mẩu bánh nhỏ" trong toàn "miếng bánh" hoạt động tổng thể của tổ chức.

Hardware và Computers cần con người cấu hình và vận hành chúng, Data thông thường sẽ không có gì ích lợi, trừ khi nó được truy cập bởi những Systems khác, và có thể là cả những tổ chức bên ngoài. Do đó, chúng ta cần phải hiểu về "Bức tranh lớn", tổng thể về các Processes cùng kết hợp với nhau bên trong tổ chức.

Planning - Lập kế hoạch phải bao gồm đúng người đúng chỗ, documenting các configurations cần thiết, thiết lập Alternate communications channels (voice & data) - Kênh liên lạc thay thế, cung cấp điện (power), đảm bảo tất cả những thứ phụ thuộc vào những hạng mục này, bao gồm processes và applications, tất cả đều phải được hiểu rõ ràng và đưa vào kế hoạch. Ví dụ, rất có thể sẽ tạm không đưa một Server trở về trạng thái Online, nếu DNS Server chưa hoạt động lại trong Network.

Ngoài ra còn một điều cũng rất quan trọng, đó là phải hiểu được Automated Tasks hoạt động như thế nào, để có thể thực hiện nó theo cách Manually nếu cần thiết, phải hiểu cách có thể thay đổi Business Processes an toàn để có thể tiếp tục vận hành tổ chức. Điều này có thể là yếu tố quan trọng trong việc đảm bảo cho tổ chức khi sống sót qua khỏi thảm họa, vẫn có thể tiếp tục hoạt động.

Nếu không có tầm nhìn và lên kế hoạch kiểu này, khi thảm họa xảy ra, tổ chức tuy đã có Backup Data và Redundant Servers sẵn sàng thay thế tại cơ sở dự phòng, nhưng những người chịu trách nhiệm kích hoạt chúng có thể "đứng như trời tròng", không biết phải bắt đầu từ đâu hoặc làm thế nào để thực hiện trong một môi trường khác như vậy.

Business Continuity Planning - Lập kế hoạch liên tục Kinh Doanh

Là các Procedures đã được lên kế hoạch trước (preplanned), cho phép tổ chức :

•  Cung cấp khả năng phản ứng Immediate và Appropriate - phù hợp cho các tình huống khẩn cấp (emergency)
•  Bảo vệ cuộc sống và đảm bảo an toàn Safety
•  Giảm thiểu Business Impact - Tác động đến kinh doanh
•  Resume - Tiếp tục những chức năng Business quan trọng
•  Làm việc với các Vendors bên ngoài trong thời gian Recovery
•  Giảm thiểu rối loạn (confusion) trong khi diễn ra khủng hoảng
•  Đảm bảo Survivability - Khả năng sống sót của tổ chức
•  “up and running” nhanh chóng sau khi xảy ra thảm họa

Là một phần trong các quyết định kinh doanh ngày nay - Business Decisions, bao gồm những điều sau :

•  Cho các đối tác kinh doanh biết được tổ chức của chúng ta đã có sự chuẩn bị.
•  Làm "yên lòng" các cổ đông và HĐQT về tính sẵn sàng của tổ chức.
•  Đảm bảo BCP được triển khai, nếu đó là quy định của ngành công nghiệp.

 

Business Continuity Steps

Mặc dù hiện tại không có bất kỳ công thức khoa học nào dùng để tạo ra Business Continuity Plans, nhưng cũng có một số Best Practices đã được chứng minh qua một thời gian dài, dùng để tạo ra BCP. National Institute of Standards and Technology (NIST), chịu trách nhiệm trong việc phát triển các Best Practices này và documenting chúng lại để có thể dễ dàng cung cấp cho mọi người. NIST đã phát thảo ra các bước thiết lập BCP, trong Special Publication 800-34, Continuity Planning Guide for Information Technology Systems :

 1.  Develop the continuity planning policy statement - Phát triển chính sách tuyên bố về việc lập kế hoạch Business Continuity. Viết một Policy cung cấp hướng dẫn phát triển BCP và phân công quyền hạn cho những vai trò cần thiết để thực hiện những nhiệm vụ này.

 2.  Conduct the business impact analysis (BIA) - Tiến hành phân tích tác động kinh doanh. Xác định các chức năng và hệ thống quan trọng, cho phép tổ chức sắp xếp mức độ ưu tiên (priority) dựa trên sự cần thiết của chúng. Xác định vulnerabilities, threats và tính toán Risks.

 3.  Identify preventive controls - Xác định các kiểm soát phòng chống. Sau khi đã xác định xong Threats, cần tiến hành xác định và triển khai các cơ chế kiểm soát và countermeasures để giảm thiểu mức độ rủi ro của tổ chức đến mức độ Acceptance.

 4.  Develop recovery strategies - Phát triển chiến lược Phục Hồi. Xây dựng các phương pháp để đảm bảo cho những hệ thống và chức năng quan trọng có thể Back Online một cách nhanh chóng.

 5.  Develop the contingency plan - Phát triển kế hoạch kinh doanh liên tục. Viết các Prodecures và Guidelines, hướng dẫn cho tổ chức cách có thể giữ cho các chức năng quan trọng vẫn tiếp tục hoạt động trong trường hợp cả tổ chức bị tê liệt.

 6.  Test the plan and conduct training and exercises - Kiểm tra kế hoạch và tiến hành đào tạo, diễn tập. Kiểm tra kế hoạch để xác định những thiếu sót trong BCP, tiến hành đào tạo để chuẩn bị chính xác cho các cá nhân về nhiệm vụ dự kiến của họ.

 7.  Maintain the plan - Duy trì kế hoạch. Đưa vào các bước cần thiết để đảm bảo BCP là một Living Document, được cập nhật thường xuyên.

Các tổ chức và guidelines có thể bao gồm những thông tin trên, nhưng có thể đặt tên khác nhau cho từng bước. (ISC)2 cũng có những bước này với cùng một thông tin :

 1.  Project initiation : Bắt đầu dự án
 2.  BIA : Phân tích tác động kinh doanh
 3.  Recovery strategy : Chiến lược Phục Hồi
 4.  Plan design and development : Lên kế hoạch thiết kế và phát triển
 5.  Implementation : Triển khai
 6.  Testing : Thử nghiệm
 7.  Continual maintenance : Liên tục bảo trì

Các bước cần thiết để tung ra BCP được minh họa trong Figure 9-1.

 

     

Mặc dù tài liệu NIST 800-34 giải quyết cụ thể về IT Contigency Plans, tuy nhiên các bước này đều giống nhau khi tạo BCPs cho toàn doanh nghiệp. Chương này sẽ dẫn dắt chúng ta đi qua từng giai đoạn khác nhau này, cho chúng ta biết những gì chúng ta nên làm nếu muốn xây dựng được một BCP có hiệu quả và hữu ích.

Making BCP Part of the Security Policy and Program

Như đã giải thích trong Domain : Information Risk Management, mọi tổ chức đều cần có Security Policies, Procedures, Standards và Guidelines. Chúng cùng nhau cung cấp Framework cho Security Program của tổ chức. Như vậy, Program cần phải là một Living Entity - Thực thể sống. Khi doanh nghiệp trải qua những sự thay đổi, Program vẫn đảm bảo thông dụng, có thể sử dụng và có hiệu quả.

Business Continuity nên là một phần của Security Program và Business Decisions. Khi tích hợp chính xác vào Change Management Processes, nó sẽ có cơ hội tốt hơn trong việc được cập nhật và cải thiện thường xuyên. Business Continuity là một phần nền tảng của Security Program hiệu quả.

Một câu hỏi rất quan trọng khi lần đầu tiên phát triển BCP, đó là : Tại sao nó được phát triển ?  Why ? Điều này nghe có vẻ ngớ ngẩn và quá dễ dàng để trả lời ngay lập tức, nhưng không phải lúc nào cũng luôn luôn như vậy. Bạn có thể nghĩ rằng lý do chúng ta cần phát triển những kế hoạch này, là để đối phó với những thảm họa bất ngờ và đưa mọi người trở lại công việc một cách nhanh chóng và an toàn nhất có thể, nhưng toàn bộ câu chuyện thật sự có một chút khác biệt.

Tại sao hầu hết các doanh nghiệp đều kinh doanh ? Để kiếm tiền và lợi nhuận. Nếu những điều này là mục tiêu chính của các doanh nghiệp, thì BCP cần được phát triển để giúp đạt được, quan trọng hơn là để duy trì những mục tiêu này. Lý do chính để phát triển BCP chính là để giảm thiểu Risk thất thoát tài chính (financial loss), bằng cách cải thiện khả năng Recover và Restore Operations. Điều này cũng bao gồm luôn cả mục tiêu giảm thiểu ảnh hưởng của thảm họa.

Tất nhiên, không phải tổ chức nào cũng tồn tại để kiếm lợi nhuận. Các tổ chức chính phủ, quân đội, phi lợi nhuận, và các tổ chức tương tự khác, tồn tại để cung cấp một số loại bảo vệ hoặc dịch vụ cho quốc gia, xã hội. Trong khi các tổ chức vì lợi nhuận bắt buộc phải tạo ra BCP để đảm bảo doanh thu của họ không bị đình trệ, thì các tổ chức phi lợi nhuận bắt buộc phải có BCP để đảm bảo họ vẫn có thể thực hiện công việc quan trọng của mình, nếu thảm họa xảy ra.

Mặc dù mục tiêu và định hướng kinh doanh của các tổ chức có thể khác nhau, nhưng BCP của họ thông thường sẽ có chung một cấu trúc tương tự - Similar Constructs : Đó là để giữ cho các Processes quan trọng Up và Running.

Bảo vệ những gì quan trọng nhất đối với một tổ chức có thể khá khó khăn, nếu như những thứ quan trọng đó không được xác định ngay lúc đầu. Senior Management thường phải tham gia vào bước này, bởi vì họ có góc nhìn rộng hơn so với trưởng các bộ phận trong tổ chức.

Business Plan - Kế hoạch kinh doanh của công ty thông thường sẽ xác định sứ mệnh quan trọng và chức năng kinh doanh của công ty. Các chức năng cần phải được thiết lập mức độ ưu tiên, để tổ chức biết được điều gì là quan trọng nhất, ảnh hưởng đến sự sống còn của công ty.

Đối với nhiều công ty, Financial Operations - Hoạt động tài chính là quan trọng nhất. Ví dụ, một ngân hàng sẽ bị ảnh hưởng cực kỳ nghiêm trọng nếu như dịch vụ tín dụng và cho vay Unavailable trong một ngày, sẽ ảnh hưởng nhiều hơn so với việc E-Banking bị downtime 1 ngày, bởi vì dịch vụ tín dụng và cho vay là nơi tạo ra nhiều doanh thu nhất cho ngân hàng.

Đối với các tổ chức khác, Customer Service có thể là phần trọng nhất. Ví dụ, nếu một tổ chức chuyên tạo ra máy điều hòa nhịp tim và cung cấp nó cho các bệnh viện bị Unavailable tại một thời điểm, khi phòng phẫu thuật cần đến chúng bởi vì diễn biến phức tạp của bệnh nhân, kết quả có thể dẫn đến thảm họa cho bệnh nhân bởi sự gián đoạn dịch vụ.

Bác sĩ phẫu thuật và công ty sản xuất máy điều hòa nhịp tim có thể bị khởi kiện, công ty đó sẽ có khả năng không bao giờ có thể bán được một chiếc máy điều hòa nhịp tim nào nữa. Sẽ rất khó khăn để gầy dựng lại danh tiếng, sau khi những vụ kiểu này xảy ra.

Advanced Planning - Lập kế hoạch chi tiết cho các trường hợp khẩn cấp bao gồm các vấn đề đã được tính và dự kiến trước. Nhiều vấn đề khác có thể phát sinh mà không nằm trong kế hoạch; Do đó, Flexibility - Tính linh hoạt trong kế hoạch rất là quan trọng. Kế hoạch là một Systematic Way - phương pháp có hệ thống, cung cấp checklist các hành động sẽ diễn ra sau khi xảy ra thảm họa. Những hành động này đã được tính đến, được thông qua để giúp những người liên quan có thể đối phó với tình huống thảm họa một cách có hiệu quả.

Thành phần quan trọng nhất trong việc thiết lập và duy trì Business Continuity Plan chính là Management Support (lại nữa!) - Sự hỗ trợ của quản lý. Cần phải thuyết phục được Management về sự cần thiết của BCP. Vì thế cho nên, Business Case cần phải được thực hiện để nhận được sự hỗ trợ này. Business Case bao gồm : Vulnerabilities đang tồn tại, Regulatory và Legal Obligations (nghĩa vụ pháp lý), tình trạng hiện tại của Recovery Plans, và Recommendations - Các khuyến nghị.

Management chủ yếu quan tâm đến vấn đề Cost/Benefit, cho nên cần thu thập những con số sơ bộ và ước tính thiệt hại tiềm năng. Việc quyết định Recover tổ chức như thế nào nếu thảm họa xảy ra, chính là một Business Decision.

Project Initiation - Bắt đầu dự án

Trước khi mọi người bỏ chạy tán loạn, chúng ta hãy tìm hiểu xem cần phải thực hiện những gì trong giai đoạn Project Initiation - Bắt đầu dự án. Đây là gian đoạn mà tổ chức thật sự cần phải tìm ra xem nên làm điều gì, và lý do tại sao phải làm chuyện đó. Sau khi sự hỗ trợ của Manegement đã được củng cố hóa (solidified), Business Continuity Coordinator - Điều phối viên BCP cần phải được xác định.

Người này sẽ là leader của nhóm BCP, sẽ giám sát việc phát triển, thực hiện, và thử nghiệm BCP & DRP. Tốt nhất người này nên có kỹ năng giao tiếp tốt, có thể là một chính trị gia, hoặc là một chuyên gia "vỗ mông ngựa".

Bởi vì anh ta sẽ phải phối hợp với rất nhiều bộ phận khác nhau, với những nhân vật thường rất "bận rộn" bởi công việc riêng của họ. Người này cần phải có quyền làm việc trực tiếp với Management, có Sự tín nhiệm - Credibility và Thẩm quyền - Authority để thực hiện nhiệm vụ với vai trò lãnh đạo.

Có lãnh đạo thì phải có một đội ngũ, do đó BCP Committee - Ủy Ban BCP cần được thành lập. Management và BCP Coordinator cần phối hợp cùng nhau để chỉ định cụ thể, những người có đủ điều kiện để tham gia vào ủy ban này. Đội ngũ phải bao gồm những người có kinh nghiệm ở những bộ phận khác nhau bên trong tổ chức, bởi vì mỗi bộ phận chính là một chức năng độc lập, có những rủi ro và mối đe dọa riêng biệt.

Best Plan - Kế hoạch tốt nhất chính là khi tất cả những vấn đề và mối đe dọa được đưa ra để thảo luận. Đại diện của từng bộ phận cần phải tham gia không chỉ ở giai đoạn Planning, mà còn phải tham gia ở giai đoạn Testing và Implementation. Ủy Ban BCP "at least - ít nhất" phải có các đại diện đến từ những phòng ban sau :

• Business units
• Senior management
• IT department
• Security department
• Communications department
• Legal department

Nếu BCP Coordinator là một leader giỏi, anh ta sẽ hiểu rằng tốt nhất là phải làm cho các thành viên trong đội cảm giác được trách nhiệm của họ đối với các nhiệm vụ và vai trò liên quan đến họ. Những người phát triển BCP cũng nên là những người thực hiện nó. Nếu bạn biết rằng trong thời kỳ khủng hoảng bạn dự kiến sẽ phải thực hiện một số nhiệm vụ quan trọng, khi đó bạn cần chú ý nhiều hơn nữa trong giai đoạn Planning và Testing.

Đội ngũ sau đó phải làm việc với Management để phát triển ra các mục tiêu "tối thượng" của kế hoạch, xác định những phần quan trọng của Business cần phải xử lý đầu tiên khi diễn ra thảm họa, và xác định mức độ ưu tiên của các bộ phận (departments) cũng như các nhiệm vụ (tasks).

Management cần trợ giúp trực tiếp cho đội ngũ trong việc xác định phạm vi của dự án và các mục tiêu cụ thể. Thoạt nhìn, có vẻ như phạm vi và mục tiêu khá rõ ràng, đó là bảo vệ tổ chức. Nhưng thực tế nó không đơn giản như vậy.

Đội ngũ có nghĩa vụ phải phát triển BCP cho một cơ sở hay nhiều cơ sở ? Kế hoạch chỉ bao gồm các mối đe dọa lớn (bão, lốc xoáy, lũ lụt) hay cả các mối đe dọa nhỏ (mất đường liên lạc, mất điện, Internet hỏng) ? Kế hoạch có cần giải quyết cả mối đe dọa tấn công khủng bố hoặc đánh bomb cảm tử hay không ? Threat Profile của tổ chức là gì ?

Nếu phạm vi (scope) của dự án không được xác định rõ ràng, làm thế nào chúng ta biết được lúc nào thì hoàn thành dự án ?

Chú ý : Hầu hết các tổ chức đều vạch ra phạm vi BCP của họ chỉ gồm các mối đe dọa lớn. Các mối đe dọa nhỏ hơn sẽ được đề cập đến bởi Independent Departmental Contingency Plans - Kế hoạch dự phòng độc lập của các bộ phận.

Ở giai đoạn này, đội ngũ hợp tác với Management để phát triển Continuity Planning Policy Statement. Chính sách này đưa ra phạm vi của dự án BCP, Team Member Roles và các mục tiêu - Goals của dự án. Về cơ bản, nó là tài liệu vạch ra những gì cần được thực hiện, sau khi đội ngũ bắt tay hợp tác với Management và đi đến thỏa thuận các giới hạn của dự án.

Tài liệu này nên được gửi lại cho Management review, để đảm bảo không có bất kỳ sai sót nào xảy ra trong các giới hạn thỏa thuận. BCP Coordinator sau đó cần phải thực hiện một số kỹ năng quản lý dự án; xem Table 9-1. Project Plan cần được phát triển bao gồm các thành phần sau đây :

• Objective-to-task mapping  : Ánh xạ mục tiêu đến công việc
• Resource-to-task mapping  : Ánh xạ tài nguyên đến công việc
• Milestones                         :  Lịch sử phát triển
• Budget estimates                : Dự toán ngân sách  
• Success factors                  : Các yếu tố để thành công
• Deadlines                           : Thời hạn
 

    

Sau khi Project Plan đã hoàn tất, cần phải trình bày nó cho Management để anh ta Written Approval - Phê duyệt bằng văn bản, trước khi thực hiện bất kỳ điều gì tiếp theo. Điều quan trọng là không có bất kỳ Assumptions - Giả thiết nào nằm trong kế hoạch và Coordinator có quyền hạn sử dụng các tài nguyên cần thiết để thực hiện nhiệm vụ.

Business Continuity Planning Requirements

Yêu cầu chủ yếu đối với bất kỳ điều gì có tầm ảnh hưởng sâu rộng như BCP chính là Management Support. Điều quan trọng là Management phải hiểu được những mối đe dọa thực sự đối với tổ chức, hậu quả của những mối đe dọa này, và giá trị thiệt hại tiềm năng của mỗi mối đe dọa. Nếu không hiểu điều này, Management có thể chỉ "hứa miệng" cho việc lập kế hoạch BCP, tồi tệ hơn nữa là không có bất kỳ kế hoạch nào luôn, bởi vì Management đã hiểu sai về Security.

Không có sự hỗ trợ của Management, đồng nghĩa với việc các nguồn tài nguyên, kinh phí và thời gian sẽ bị giới hạn cực kỳ, dẫn đến một kế hoạch tồi tệ ... Thất bại của kế hoạch này thông thường là sự thất bại trong việc hiểu biết của Management, tầm nhìn và trách nhiệm Due-care.

Những người điều hành có thể phải chịu trách nhiệm trước pháp luật, họ có thể bị khởi kiện bởi các cổ đông và khách hàng nếu họ không thực hành Due Diligence và Due-care, không thực hiện đầy đủ trách nhiệm của họ khi nói đến hạng mục Disaster Recovery & Business Continuity. Các tổ chức làm việc trong ngành công nghiệp đặc thù có quy định rất nghiêm ngặt, bắt buộc họ phải tuân theo, những điều này cần được nghiên cứu và tích hợp vào Plan ngay từ lúc bắt đầu.

Ví dụ, các tổ chức đầu tư và ngân hàng bắt buộc phải đảm bảo ngay cả khi thảm họa xảy ra, thì thông tin bí mật của khách hàng cũng sẽ không bị tiết lộ hoặc thay đổi trái phép trong bất kỳ cách nào. Disaster Recovery, Continuity Development và Planning hoạt động tốt nhất bởi phương pháp Top-down. Điều này có nghĩa nên bắt đầu từ Management, không phải từ Staff, Management nên định hướng cho dự án.

Nhiều công ty hiện giờ đang phải chạy với tốc độ rất nhanh để cố bắt kịp sự thay đổi trong thế giới Business, có thể họ sẽ không thấy Immediate Benefit - Lợi ích ngay tức thì khi phải chi tiêu thời gian và tài nguyên dành cho những vấn đề Disaster Recovery. Những cá nhân nhìn ra được giá trị của DRP, BCP có thể phải tốn rất nhiều thời gian, khó thuyết phục tầng lớp Top Management, nếu như Management không nhìn thấy được lợi nhuận tiềm năng hoặc kết quả tăng trưởng thị phần.

Nhưng nếu thảm họa xảy ra và họ đã có sự chuẩn bị tốt, kết quả đem lại có thể được xem là Priceless - Vô giá !

Thế giới kinh doanh ngày nay yêu cầu hai đặc điểm quan trọng :

1. Xu hướng tạo ra sản phẩm hoặc dịch vụ tuyệt vời và đưa nó ra thị trường.
2. Sự thấu hiểu và khôn ngoan để biết trước được những sự cố bất ngờ có thể ập đến tổ chức.

Điều quan trọng là Management cần phải thiết lập mục tiêu tổng thể của Continuity Planning, và cần thiết lập mức độ ưu tiên những gì cần được giải quyết đầu tiên. Sau khi Management đã thiết lập mục tiêu, chính sách và mức độ ưu tiên; các thành viên khác, những người chịu trách nhiệm cho Plan này có thể phụ trách những phần còn lại. Tuy nhiên, Management Support không dừng lại ở đây.

Nó cần phải đảm bảo rằng Plans và Procedures đã phát triển thực sự phải được thực hiện. Management bắt buộc phải đảm bảo Plans được Update và thể hiện những mức độ ưu tiên thực tế, không chỉ đơn giản tạo ra một lần rồi xong, nó sẽ thay đổi theo thời gian.

Business Impact Analysis (BIA) - Phân tích tác động ảnh hưởng đến kinh doanh

Business Continuity Planning giải quyết Uncertainty - Sự bất trắc và Chance - Sự may rủi. Điều quan trọng cần lưu ý ở đây là ngay cả khi bạn không thể dự đoán hoặc không biết khi nào thảm họa xảy ra, điều đó không có nghĩa bạn không thể lập kế hoạch cho nó. Chỉ vì chúng ta không lập kế hoạch cho trận động đất có thể xảy ra vào lúc 10h00 sáng ngày mai, không có nghĩa chúng ta không thể lập kế hoạch các hoạt động cần thiết để có thể sống sót khi một trận động đất hoặc thảm họa tương tự diễn ra.

Điểm cốt yếu khi tạo ra kế hoạch này là để cố gắng suy nghĩ về tất cả các thảm họa có thể xảy ra, ước tính thiệt hại và tổn thất tiềm năng, phân loại và sắp xếp mức độ ưu tiên cho thảm họa tiềm năng, và phát triển các giải pháp thay thế trong trường hợp những sự kiện này thực sự diễn ra.

Business Impact Analysis (BIA) được xem là  một cuộc Functional Analysis - Phân tích chức năng, theo đó đội ngũ sẽ thu thập dữ liệu thông qua các cuộc Interviews và các nguồn Documentary; Documents Business Functions, activities, transactions; phát triển một hệ thống phân cấp (hierarchy) Business functions; cuối cùng là áp dụng một chương trình phân loại (classification scheme) để chỉ ra mức độ quan trọng của mỗi chức năng.

Nhưng làm thế nào chúng ta có thể xác định phân loại dựa trên mức độ quan trọng (criticality levels) ?

Ủy ban BCP cần phải xác định Threats để ánh xạ chúng đến những đặc điểm sau đây :

• Maximum tolerable downtime : Thời gian downtime tối đa có thể chấp nhận được
• Operational disruption and productivity : Sự gián đoạn hoạt động và năng suất
• Financial considerations : Cân nhắc về mặt tài chính
• Regulatory responsibilities : Trách nhiệm về mặt quy định
• Reputation : Danh tiếng, uy tín

Ủy ban thật sự không thể nào hiểu được tất cả các quy trình kinh doanh. Cho nên ủy ban phải thu thập thông tin này từ những người hiểu biết về những quy trình đó, có thể là Department Managers hoặc một nhân viên đặc biệt nào đó trong tổ chức. Ủy ban sẽ bắt đầu xác định những người cần thiết cho việc BIA Data-gathering - Thu thập dữ liệu BIA.

Ủy ban cần phải xác định xem làm thế nào để thu thập dữ liệu từ những người này, có thể là thông qua surveys, interviews hoặc workshops. Dữ liệu thu thập được sẽ dùng cho sau này, trong giai đoạn Analysis. Điều quan trọng là các thành viên trong đội ngũ phải đặt câu hỏi về những công việc khác nhau của người được phỏng vấn, bất kể là processes, transactions hay services. Process Flow Diagrams cũng nên được xây dựng, nó sẽ được sử dụng trong suốt quá trình BIA và giai đoạn Development kế hoạch.

Sau khi hoàn thành giai đoạn Data Collection - Thu Thập Dữ Liệu, ủy ban BCP cần tiến hành một cuộc phân tích, để thiết lập sắp xếp cho các processes, devices hoặc các hoạt động quan trọng. Nếu một System hoạt động riêng lẻ, không ảnh hưởng đến các hệ thống khác và có mức độ quan trọng thấp, khi đó nó có thể được phân vào loại 2 hoặc loại 3 của giai đoạn Recovery.

Điều này có nghĩa những tài nguyên này (loại 2 hoặc 3) sẽ không được xử lý trong giai đoạn Recovery, cho đến khi những tài nguyên thuộc loại quan trọng nhất (loại 1) được Up & Running trở lại. Cuộc Phân tích này có thể được hoàn thành bằng cách sử dụng phương pháp Standard Risk Assessment & Analysis. (Domain IS&RM).

Threats có thể là do con người gây ra (manmade), do thiên nhiên hoặc do vấn đề kỹ thuật (technical). Manmade Threat - Mối đe dọa do con người tạo ra có thể có thể là một tên khủng bố, một kẻ gây hỏa hoạn (arsonist), hay một sai lầm đơn giản dẫn đến những hậu quả nghiêm trọng. Natural Threat - Mối đe dọa do thiên nhiên có thể là lốc xoáy, lũ lụt, bão táp, hoặc động đất.

Technical Threat - Mối đe dọa kỹ thuật có thể là do hỏng hóc data, mất điện, hỏng thiết bị, hoặc mất đường truyền data. Điều quan trọng ở đây là phải xác định được tất cả các Threats có thể xảy ra, và ước tính xác suất có thể xảy ra của chúng.

Một số vấn đề có thể chúng ta quên không nhớ đến khi phát triển kế hoạch, chẳng hạn như : cuộc đình công của nhân viên, những kẻ phá hoại (vandals), những nhân viên bất mãn, hoặc Hackers chẳng hạn, nhưng chúng cũng cần phải được xác định.

Những vấn đề này thường được xử lý theo cách diễn tập dựa trên các kịch bản - Scenario-based exercises. Điều này đảm bảo rằng nếu một mối đe dọa có trở thành sự thật thì chúng ta cũng đã chuẩn bị sẵn tinh thần để xử lý. Những vấn đề mà chúng ta đã lên kế hoạch tốt hơn hết là phải có sự diễn tập để đảm bảo mọi thứ đều nằm trong dự đoán.

BIA Steps - Các bước phân tích tác động kinh doanh

Chi tiết các bước BIA :

1. Lựa chọn các cá nhân để interview thu thập data.
2. Tạo ra các kỹ thuật thu thập data (suveys, questionnaires - bảng câu hỏi, qualitative & quantitative risk assessment)
3. Xác định các Business Functions quan trọng của tổ chức
4. Xác định các tài nguyên phụ thuộc vào những Functions này
5. Tính toán xem làm thế nào để các Business Functions quan trọng này có thể tồn tại, mà không phụ thuộc vào tài nguyên ở bước 4
6. Xác định Vulnerabilities và Threats của những Fuctions này
7. Tính toán Risk cho từng Business Fuction
8. Document lại kết quả và report chúng đến Management.

Chúng ta sẽ đi xuyên qua từng bước một trong chương này, nhưng nhiều khi xem kiểu này có vẻ lại dễ hiểu hơn.

Ủy ban BCP cần thực hiện những bước này, thông qua nhiều Scenarios - Kịch bản như sau :

•  Thiết bị gặp sự cố hoặc Unavailable (không có sẵn)
•  Unvailable các tiện ích (HVAC, power, communications lines)
•  Facility trở nên Unavailable
•  Nhân viên chủ chốt, quan trọng cũng Unavailable !
•  Vendor và Service Provide trở thành Unavailable
•  Software và/hoặc Data bị hỏng

Bước tiếp theo là Risk Analysis để gán giá trị cho tài sản, mà có thể bị ảnh hưởng bởi các Threats. Điều này giúp thiết lập Economic Feasibility - Tính khả thi về mặt kinh tế cho tổng thể kế hoạch. Như đã thảo luận trong Domain IS&RM, gán giá trị cho tài sản không dễ như chúng ta tưởng chút nào đâu. Giá trị của một tài sản không chỉ là số tiền bạn bỏ ra để mua nó về. Vai trò của tài sản trong công ty phải được xem xét, cùng với thời gian đã tạo ra nó nếu nó là một Software.

Giá trị của tài sản cũng có thể bao gồm các vấn đề trách nhiệm pháp lý xung quanh tài sản, nếu nó bị hỏng hóc hoặc không an toàn trong bất kỳ hình thức nào.

Thông tin tác động Qualitative và Quantitative cần được thu thập, sau đó phân tích và giải thích. Mục đích là để xem coi chính xác tổ chức sẽ bị ảnh hưởng như thế nào bởi các mối đe dọa khác nhau. Ảnh hưởng có thể về mặt kinh tế, vận hành, hoặc cả hai. Sau khi hoàn thành Data Analysis, nó cần được review bởi những người có kinh nghiệm nhất trong tổ chức, nhằm đảm bảo rằng kết quả tìm thấy phù hợp với những rủi ro và tác động thực tế mà tổ chức phải đối mặt.

Điều này sẽ giúp "xả" hết ra những Data không được thu thập lúc ban đầu, và sẽ cung cấp một sự hiểu biết đầy đủ hơn về tất cả các Business Impacts có thể xảy ra. Loss Criteria - Tiêu chuẩn mất mát cần phải được áp dụng cho các mối đe dọa đã được xác định. Tiêu chuẩn có thể bao gồm những điều sau đây :

•  Tổn thất về uy tín và niềm tin của công chúng
•  Mất lợi thế cạnh tranh
•  Tăng chi phí vận hành
•  Vi phạm các thỏa thuận hợp đồng
•  Vi phạm luật pháp và quy định
•  Trì hoãn chi phí thu nhập (Delayed)
•  Tổn thất doanh thu
•  Tổn thất năng suất hoạt động

Những chi phí tổn thất này có thể là trực tiếp hoặc gián tiếp, cần được hạch toán đúng.

Vì vậy, nếu đội ngũ BCP đang tìm hiểu mối đe dọa về việc đánh bomb khủng bố, điều quan trọng là phải xác định xem Business Function nào có thể sẽ trở thành mục tiêu của bọn khủng bố, tất cả các Business Functions sẽ bị ảnh hưởng như thế nào, và mỗi hạng mục trong Loss Criteria sẽ liên quan trực tiếp hay gián tiếp ra làm sao. Timeliness - Kịp thời Recovery có thể là một yếu tố quan trọng trong quá trình kinh doanh và sự sống còn của công ty.

Ví dụ, chức năng Customer Support của công ty có thể chấp nhận downtime trong vòng 2 ngày, nhưng nếu downtime trong 5 ngày thì có thể làm thất thoát tài chính của công ty.

Sau khi đã xác định các Functions quan trọng, kế tiếp ta cần phải tìm hiểu xem chính xác những gì cần thiết để các Business Processes có thể diễn ra. Những Resources được yêu cầu cho các Business Processes đã xác định, không nhất thiết chỉ là Computer Systems, mà còn có thể bao gồm : nhân sự, procedures, tasks, supplies và vendor support.

Đội ngũ cần phải xác định xem, trong trường hợp những Resources và Systems này Unavailable, thì những Functions quan trọng mà chúng ta đã xác định sẽ bị ảnh hưởng như thế nào ?

Business Impact Analysis xác định những hệ thống Critical cần có cho sự tồn tại (survival) của công ty, và ước tính Outage Time - Thời gian ngưng hoạt động có thể chấp nhận được (tolerated) của công ty, khi nhiều Events bất hạnh diễn ra. Outage Time có thể chịu đựng được (endured) của tổ chức, còn được gọi là Maximum Tolerable Downtime (MTD) - Thời giang ngừng hoạt động tối đa.

Sau đây là một số ước tính MTD có thể được sử dụng bên trong một tổ chức :

•  Nonessential - Không thiết yếu : Có thể tạm ngừng hoạt động trong 30 ngày
•  Normal - Bình thường : Có thể tạm ngừng hoạt động trong 7 ngày
•  Important - Quan trọng : Chỉ có thể tạm ngừng hoạt động trong 72 giờ
•  Urgent - Khẩn cấp : Chỉ có thể tạm ngừng hoạt động trong 24 giờ
•  Critical - Vô cùng quan trọng :  Chỉ có thể tạm ngừng tính từ Phút đến Giờ

Mỗi Business Function và tài sản nên được đặt vào một trong những categories này, tùy thuộc vào khả năng mà tổ chức có thể tồn tại trong bao lâu khi không có nó. Những ước tính này sẽ giúp tổ chức xác định những giải pháp Backup cần thiết để đảm bảo tính Availability của những tài nguyên này. Ví dụ, nếu không có đường truyền T1 trong vòng 3 giờ, công ty sẽ phải tiêu tốn $120.000 USD thì T1 được xem là Critical, do đó công ty nên đặt thêm một đường truyền T1 từ nhà cung cấp dịch vụ khác để Backup.

Nếu một Server bị ngưng hoạt động trong vòng 10 ngày, chỉ tiêu tốn của công ty $250 thì nó được xếp vào loại Normal category, do đó có thể công ty không cần thiết phải trang bị thêm Redundant server để hoán đổi khi có thảm họa xảy ra. Thay vào đó, công ty có thể chọn cách dựa vào SLA của Vendor, trong đó có thể chứa cam kết sẽ đem Server back-online trong 8 ngày.

Đội ngũ BCP cần phải cố gắng suy nghĩ về tất cả các Events có thể xảy ra, mà có thể gây bất lợi cho công ty. Đội ngũ BCP cũng cần phải hiểu không thể nào định liệu được hết tất cả các Events, do đó sự bảo vệ có thể không có sẵn cho tất cả các kịch bản được đưa ra. Việc chuẩn bị đối phó với những sự kiện đặc biệt như : Lũ lụt, động đất, khủng bố tấn công, sét đánh; thực sự không quan trọng bằng việc chuẩn bị đối phó với bất kỳ điều gì gây ra thiệt hại hoặc làm gián đoạn Business Functions.

Chú ý : BIA được thực hiện trong giai đoạn bắt đầu Business Continuity Planning, nhằm xác định phạm vi có thể sẽ phải gánh chịu những tổn thất tài chính hoặc vận hành hỏng hóc, trong trường hợp thảm họa hoặc sự gián đoạn xảy ra. BIA xác định các hệ thống, các Business Functions quan trọng cho mục đích sống còn của công ty và ước tính Outage Time mà công ty có thể chịu đựng khi xảy ra thảm họa hoặc gián đoạn.

Interdependencies - Phụ thuộc lẫn nhau
Operations phụ thuộc vào việc sản xuất, việc sản xuất phụ thuộc vào R&D, bảng lương phụ thuộc vào kế toán, và tất cả phụ thuộc vào CNTT.

Điều quan trọng khi chúng ta nhìn vào một tổ chức, ta cần xem nó như một loài động vật phức tạp thay vì một thực thể tĩnh lặng. Nó bao gồm nhiều loại thiết bị, con người, công việc, phòng ban, các cơ chế liên lạc và các loại giao tiếp với thế giới bên ngoài. Thách thức lớn nhất của Business Continuity Planning thực sự chính là tất cả những sự phức tạp này và những mối liên quan đến chúng.

Đội ngũ có thể phát triển kế hoạch để Backup và Restore data, triển khai thiết bị Redundant Data Processing, giáo dục nhân viên cách thực hiện công việc tự động bằng cách thủ công, và trang bị Redundant Power Supplies. Nhưng nếu tất cả những thành phần này không biết làm thế nào để cùng "bắt tay hợp tác" với nhau, thì chúng chỉ tổ làm chúng ta thêm lãng phí thời gian, tiền bạc và công sức mà thôi.

Sau đây là các công việc Interrelation - Có Quan Hệ Với Nhau và Interdependency - Phụ Thuộc Lẫn Nhau cần được thực hiện bởi đội ngũ BCP và được đề cập đến trong kết quả của Plan :

•  Xác định các Business Functions thiết yếu và hỗ trợ cho các Departments.

•  Xác định Interdependencies - Những sự phụ thuộc lẫn nhau giữa các chức năng này và các Departments.

•  Khảo sát tất cả những Discruptions - Sự gián đoạn tiềm năng, có thể gây ảnh hưởng đến các cơ chế cần thiết cho các phòng ban và các functions hoạt động cùng nhau,

•  Xác định và document lại các Threats tiềm năng, có thể làm gián đoạn khả năng liên lạc giữa các Departments với nhau.

•  Thu thập thông tin Quantitative và Qualitative liên quan đến những Threats này.

•  Cung cấp những phương pháp Alternative - Thay thế trong việc phục hồi các chức năng và communication.

•  Cung cấp văn bản trình bày tuyên bố vắn tắt về mỗi Threat và thông tin liên quan đến chúng.

Main Goal - Mục tiêu chính của Business Continuity chính là để Resume Business - Tiếp tục kinh doanh càng nhanh càng tốt. Overwall Business Inerruption - Gián đoạn kinh doanh tổng thể và Resumption Plan nên bao gồm tất cả các yếu tố của tổ chức, xác định critical services, systems & functions, cung cấp các lựa chọn alternatives cho các hoạt động khẩn cấp, và tích hợp với mỗi Departmental Plan.

Điều này có thể được thực hiện bởi nhân viên bên trong tổ chức, chuyên viên tư vấn bên ngoài hoặc kế hợp cả hai.

Sự kết hợp có thể mang lại nhiều lợi ích cho công ty, bởi vì các chuyên gia tư vấn bên ngoài là những chuyên gia trong lĩnh vực này, họ biết cần phải làm cái gì, đặt những câu hỏi ra làm sao và tìm kiếm những vấn đề đúng trọng tâm, cung cấp những lời khuyên hợp lý. Trong khi đó nhân viên bên trong tổ chức thì lại hiểu rõ mật thiết về công ty của họ, hiểu biết trọn vẹn về các Threats có thể gây ảnh hưởng đến hoạt động.

Rất nhiều lần, các chuyên gia đồng khẳng định sự kết hợp giữa các Consultants bên ngoài và nhân viên nội bộ chính là một phương pháp đúng đắn.

Enterprisewide - Trên toàn doanh nghiệp

Phạm vi đã thỏa thuận của BCP sẽ cho chúng ta biết có một hay nhiều cơ sở được đề cập đến trong Plan. Hầu hết các BCPs được phát triển cho phạm vi khắp toàn doanh nghiệp, thay vì chỉ xử lý một phần cụ thể nào đó bên trong tổ chức. Trong các tổ chức có tầm quy mô quá lớn, họ có thể cho phép mỗi bộ phận có Contigency Plan riêng của họ, điều đó khá hữu ích vì nó giúp giải quyết những vấn đề đặc thù trong quá trình Recovery. Tuy nhiên, những Contigency Plan cá nhân này cần phải tương thích với BCP Enterprisewide.

Cho đến thời điểm này, chúng ta đã thiết lập được những trách nhiệm của Management như sau :

•  Cam kết hỗ trợ - Committing fully cho BCP
•  Thiết lập Policy và Goals
•  Cung cấp kinh phí và những nguồn tài nguyên cần thiết
•  Chịu trách nhiệm về kết quả của việc phát triển BCP
•  Thành lập, bổ nhiệm một đội ngũ cho quá trình BCP

Sau đây là trách nhiệm của đội ngũ BCP :

•  Xác định các yêu cầu và quy định pháp lý bắt buộc phải được đáp ứng
•  Xác định tất cả Vulnerabilities và Threats tiềm năng
•  Ước tính khả năng xảy ra của Threats và những mất mát tiềm năng
•  Thực hiện BIA
•  Phác thảo ra : Những bộ phận, hệ thống, quy trình nào bắt buộc phải được Up & Running trước bất kỳ điều gì khác.
•  Phát triển Procedures và Steps trong quá trình Resuming Business sau khi xảy ra thảm họa.

Có một số công cụ sẵn có cho việc phát triển BCP, giúp đơn giản hóa quy trình này. Automation - Tự động hóa những Procedures này có thể đẩy nhanh tốc độ của dự án và giúp cho việc thu thập một số lượng lớn thông tin trở nên dễ dàng hơn. Rất nhiều các hạng mục cần thiết được cung cấp trong Boilerplate Templates - Các mẫu soạn sẵn.

Những thông tin này, cùng với các Data đã được giải thích trong phần trước, cần được trình bày đến Senior Management. Management thường quan tâm đến thông tin về chi phí, về định lượng, về định tính, không chủ quan.

Nó là một trong những điều cần biết nếu một cơn thảm họa Tornado (lốc xoáy) xảy ra, kết quả thực sự sẽ rất xấu - really bad, nhưng còn phải biết thêm nữa nếu một cơn lốc xoáy đã xảy ra và gây ảnh hưởng đến 65% cho cơ sở, công ty có thể có nguy ngơ mất khả năng Computing lên đến 72 giờ, mất điện trong 24 giờ, dừng mọi hoạt động trong 76 giờ, tương đương với việc mất $125,000 USD/ngày.

Management sẽ rất khó khăn khi phải đối phó với Really Bad hơn Real Numbers.

Management cần phải xem xét những phát hiện của đội ngũ BCP và đưa ra cảm kết "Okay" cho đội ngũ, để họ tiếp tục tiến về phía trước và thực sự phát triển Plan. Trong kịch bản của chúng ta, chúng ta sẽ giả định rằng Management đã giơ ngón cái lên (biểu hiện OK các chú làm đi), thế là đội ngũ sẽ tiếp tục tiến về các giai đoạn tiếp theo.

Preventive Measures - Biện pháp ngăn ngừa

Trong quá trình BIA, đội ngũ BCP đã xác định được Maximum Tolerable Downtime của những nguồn tài nguyên Critical. Điều này được thực hiện để chúng ta có thể hiểu được tác động đến kinh doanh có thể xảy ra, nếu những nguồn tài nguyên Critical trở nên Unavailable vì một lý do nào đó. Nó giúp cho đội ngũ ý thức được rằng, cần phải giảm bớt tác động và giảm thiểu những Risks này bằng cách thực hiện Preventive Measures - Những Biện pháp ngăn ngừa.

Không triển khai thực hiện các biện pháp ngăn ngừa nó cũng tương tự như việc đi bác sĩ, bác sĩ bảo bớt ăn chất béo, tăng cường thể thao .... Sau đó chúng ta lựa chọn không làm theo bất kỳ biện pháp ngăn ngừa nào bác sĩ đưa ra. Vậy tại sao chúng ta phải đi bác sĩ làm gì ? Khái niệm này cũng tương tự đúng với nhiều tổ chức.

Nếu một đội ngũ đã được thành lập, nhằm mục đích thực hiện việc xác định rủi ro và đưa ra những giải pháp thiết yếu, nhưng tổ chức không thực hiện bất kỳ giải pháp nào được đưa ra, vậy thành lập đội ngũ này làm chi ?

Vì vậy, thay vì chỉ chờ đợi xem thảm họa sẽ ảnh hưởng đến tổ chức như thế nào, chúng ta nên chủ động thực hiện các Countermeasures cần thiết để làm giảm thiểu những tác động mà chúng ta đã tìm ra. Những phương pháp Preventive và Proactive hiệu quả và thích hợp hơn so với những phương pháp Reactionary.

Những cơ chế Preventive mà đội ngũ chúng ta đưa ra cần dựa vào kết quả của BIA, chúng có thể bao gồm một số thành phần sau đây :

•  Fortification - Củng cố, gia cố cho các vật liệu xây dựng trong cơ sở
•  Redundant servers và Communications links
•  Power lines - Các đường dây điện đến từ những trạm biến áp khác nhau
•  Redundant vendor support - Hỗ trợ từ nhà cung cấp dự phòng (Ví dụ nhà cung cấp A bị phá sản thì phải còn nhà cung cấp khác hỗ trợ)
•  Purchasing of insurance - Mua bảo hiểm
•  Purchasing of UPS and generators - Mua UPS và máy phát điện
•  Data backup technologies - Các công nghệ sao lưu phục hồi dữ liệu
•  Media protection safeguards - Các biện pháp bảo vệ Media
•  Increased inventory of critical equipment - Mua thêm các thiết bị quan trọng để vào kho
•  Fire detection and suppression systems - Trang bị hệ thống PCCC

 

Recovery Strategies - Những chiến lược Phục Hồi

Tính đến thời điểm này, đội ngũ BCP đã thực hiện xong giai đoạn Project Initiation - Bắt đầu dự án. Trong giai đoạn này, đội ngũ đã nhận được sự hỗ trợ của Management, những Resources cần thiết, xác định scope của dự án và thành lập đội ngũ BCP. Đội ngũ cũng đã hoàn thành giai đoạn BIA. Điều này có nghĩa chúng ta đã thực hiện xong Risk Assessment và Analysis, đã có kết quả báo cáo mức độ rủi ro thật sự (real risk) mà tổ chức phải đối mặt.

Ủy ban BCP cũng đã tìm hiểu ra được cách hoạt động của tổ chức trong giai đoạn BIA. Cũng như đã đi sâu vào bên trong tổ chức và xác định những Critical Functions mà nhất định phải Up và Running khi thảm họa xảy ra. Ủy ban BCP cũng đã xác định những resources cần thiết cho Critical Functions và tính toán các giá trị MTD cho các resources cá nhân và các Functions tương tự.

Trong giai đoạn Recovery Strategy, đội ngũ sẽ tiếp cận thông tin từ một góc độ khác. Giai đoạn này chủ yếu là để xác định những gì tổ chức cần phải làm, để thực sự Recover được những hạng mục mà chúng ta đã xác định nó rất quan trọng đối với tổ chức. BIA cung cấp Blueprint - các kế hoạch chi tiết Recovery Strategies dành cho tất cả các thành phần, bởi vì Business Processes hoàn toàn phụ thuộc vào việc diễn ra đúng cách những Recovery Strategies này.

Tại thời điểm này, kết quả từ giai đoạn BIA đã được báo cáo đến cho Management và Management đã phân bổ những resources cần thiết để tiến đến giai đoạn tiếp theo. Ủy Ban BCP ngay lúc này cần phải khảo sát những giải pháp Recovery hiệu quả (cost-effective hehe) và triển khai chúng để xử lý các mối đe dọa đã tìm ra trong giai đoạn BIA.

Hãy nhớ rằng trong giai đoạn BIA, đội ngũ đã tính toán các mất mát tiềm năng của mỗi mối đe dọa. (nếu cơ sở trở Unavailable, nó sẽ làm tổ chức tổn thất $200,000/ngày; nếu đường truyền Internet bị down, nó sẽ làm tổ chức tổn thất $12,000/giờ, vân vân). Đội ngũ sẽ sử dụng những giá trị này để phân tích Cost-Benefit khi xem xét và lựa chọn giải pháp Recovery, nhằm mục đích triển khai sử dụng để giảm thiểu mức độ rủi ro của tổ chức.

Vậy đội ngũ BCP anh em ta cần phải hoàn thành những gì trong giai đoạn Recovery Strategy ? Đội ngũ cần xác định Recovery Strategies - Những chiến lược Phục Hồi, đó là một tập hợp các hoạt động sẽ được thực hiện để ứng phó với thảm họa. Nghe có vẻ đơn giản đấy, nhưng thực tế trong giai đoạn này cũng đòi hỏi phải làm việc rất nhiều như giai đoạn BIA.

Trong giai đoạn BIA, đội ngũ đã tính toán được Recovery Times cần thiết phải được đáp ứng cho mỗi Critical Business Functions và các resources dựa vào những Functions này. Ví dụ, chúng ta hãy giả định rằng đội ngũ đã tìm ra được công ty sẽ bị tổn thất $200,000 mỗi ngày nếu cơ sở bị phá hủy hoặc không sử dụng được. Đội ngũ biết rằng công ty có thể phục hồi lại cơ sở trong 5 đến 6 tiếng, hoặc nếu không sẽ bị tê liệt hoàn toàn. Điều này có nghĩa công ty cần phải có Hot Site hoặc Redundant Facility, cho phép công ty vận hành tạm thời Up & Running trong khoảng thời gian 5 - 6 tiếng này.

Đội ngũ đã tìm ra Timelines dành cho các Business Functions, Operations và Resources. Bây giờ đội ngũ phải xác định các cơ chế Recovery, triển khai nó để đảm bảo tất cả mọi thứ đều Up & Running đúng như Timelines mà chúng ta đã tính toán.

Đội  ngũ cần tập trung vào những phần Recovery Strategies sau đây :

1. Business process recovery : Khôi phục quy trình kinh doanh
2. Facility recovery : Khôi phục cơ sở
3. Supply and technology recovery : Khôi phục công nghệ và quy trình cung cấp
4. User environment recovery : Khôi phục môi trường của người dùng
5. Data recovery : Khôi phục dữ liệu

Business Process Recovery - Khôi phục quy trình kinh doanh

Business Process - Quy trình kinh doanh là một tập hợp các bước có liên quan với nhau, được liên kết thông qua các hoạt động để thực hiện một nhiệm vụ cụ thể. Business Processes có điểm bắt đầu và điểm kết thúc lặp đi lặp lại.

Ví dụ về Business Process : Khi một khách hàng yêu cầu mua một chiếc xe hơi thông qua Website Thương Mại Điện Tử của công ty, một tập hợp các bước sau đây cần phải được diễn ra, như thế này :

 1.  Kiểm tra xem chiếc xe hiện có sẵn (available) hay không.
 2.  Kiểm tra xem xe đang ở đâu và bao nhiêu lâu sẽ ship nó đến địa điểm giao hàng.
 3.  Cung cấp cho khách hàng giá cả và ngày giao hàng.
 4.  Chấp nhận thông tin Credit Card của khách hàng.
 5.  Kiểm tra và xử lý thông tin Credit Card.
 6.  Gửi Receipt và Tracking Number đến khách hàng.
 7.  Gửi đơn đặt hàng đến kho chứa xe.
 8.  Bổ sung lại (restock) mẫu xe đó vào kho hàng.
 9.  Gửi đơn đặt hàng đến bộ phận kế toán.

Đội ngũ BCP cần phải hiểu về những bước này. Data thường được thể hiện như là Workflow Document - Văn bản tiến trình công việc, chứa các vai trò và tài nguyên cần thiết cho mỗi process. Đội ngũ BCP cần phải hiểu được những thứ sau đây về Critical Business Processes :

• Required roles : Các vai trò cần thiết
• Required resources : Các nguồn tài nguyên cần thiết
• Input and output mechanisms : Các cơ chế đầu vào & đầu ra
• Workflow steps : Các bước tiến trình công việc
• Required time for completion : Thời gian cần thiết để hoàn thành
• Interfaces with other processes : Tương tác với những quy trình khác

Điều này giúp cho đội ngũ có thể xác định được các mối đe dọa và các kiểm soát cần thiết, nhằm đảm bảo giới hạn việc gián đoạn Process.

What Is the Difference Between Preventive Measures and Recovery Strategies ?

Preventive Mechanisms - Cơ chế Ngăn Ngừa được đặt vào để làm giảm thiểu khả năng xảy ra thảm họa của tổ chức. Nếu thảm họa xảy ra thì nó cũng sẽ làm giảm thiểu tối đa thiệt hại. Recovery Strategies - Chiến lược Phục Hồi là những tiến trình Rescue - Giải cứu công ty sau khi thảm họa xảy ra.

Những tiến trình này sẽ tích hợp vào tổ chức các cơ chế chẳng hạn như : thiết lập Alternate Sites Faclities - Địa điểm cơ sở thay thế, triển khai Emergency Response Procedures, kích hoạt Preventive Mechanisms đã được triển khai.

Facility Recovery - Khôi phục Cơ Sở
Cơn động đất đã làm thiệt hại đến văn phòng của chúng ta mất rồi ! Chúng ta hãy đi tìm tòa nhà khác để làm việc thôi.

Disruptions - Sự gián đoạn có 3 loại chính : Nondisasters, Disasters và Catastrophes.

Nondisaster là sự gián đoạn trong dịch vụ do trục trặc hoặc hỏng hóc thiết bị. Giải pháp dành cho nó có thể bao gồm hardware, software hoặc File Restoration.

Disaster là một sự kiện có thể khiến cho Facility trở nên không sử dụng được trong một ngày hoặc lâu hơn. Điều này thường đòi hỏi phải dùng đến Alternate Facility - Cơ sở thay thế và Restoration lại Software & Data từ Offsite Copies. Alternate Site - Vị trí thay thế bắt buộc phải có sẵn cho tổ chức, cho đến khi Main Facility - Cơ sở chính được sửa chữa và có thể sử dụng lại được.

Catastrophe là một sự gián đoạn lớn, có thể là những sự kiện phá hủy toàn bộ Facility. Điều này thường đòi hỏi cả hai loại giải pháp Short-term (ngắn hạn) và Long-term (dài hạn). Đối với ngắn hạn, tổ chức sẽ cần Offsite Facility, còn đối với dài hạn tổ chức cần phải xây dựng lại Original Facility.

Disaster và Catastrophes thường rất rất hiếm khi xảy ra so với Nondisaster, cảm ơn chúa (Phèo ...). Nondisaster thường có thể được "săn sóc" bằng cách thay thế thiết bị hoặc restoring lại files từ Onsite backups. Đội ngũ BCP cần phải suy nghĩ về sự cần thiết của Onsite Backup. Đội ngũ phải xác định Critical Equipment, ước tính Mean Time Between Failures (MTBF) và Mean Time To Repair (MTTR) để cung cấp các số liệu thống kê khi cần thiết (Xem lại Domain : Operation Security).

Đối với các Disasters lớn gây ảnh hưởng trực tiếp đến cơ sở chính thì Offsite Backup Facility là một giải pháp bắt buộc phải có. Thông thường sẽ ký hợp đồng để các bên thứ ba cung cấp những dịch vụ này.

Khách hàng sẽ trả một khoản chi phí hàng tháng để duy trì quyền sử dụng Facility trong một khoảng thời gian, sau này khách hàng sẽ phải trả thêm một khoảng chi phí lớn hơn khi Activation cơ sở lúc thực sự dùng đến nó. Ngoài ra có thể sẽ phải tốn thêm phí trả theo Giờ hoặc theo Ngày trong thời gian lưu trú.

Đây là lý do tại sao Subscription Services cho các Backup Facilities cần được xem là giải pháp ngắn hạn, chứ không phải là giải pháp lâu dài (lâu dài tiền đâu chịu nổi !). Điều quan trọng cần phải lưu ý, hầu hết Recovery Site Contracts đều không cam kết một địa điểm cụ thể cho tổ chức, mà chỉ cam kết có một địa điểm nằm trong địa phương của tổ chức.

Ví dụ : Ngày 11 tháng 9 năm 2011, nhiều tổ chức có văn phòng đặt tại Manhattan đã hết sức ngạc nhiên bởi địa điểm của Backup Site Vendor không nằm trong New Jersey (vì nó đã đặt nghẹt), thay vào đó họ phải di chuyển đến tận Boston, Chicago hoặc Atlanta.

Điều này lại làm tăng thêm mức độ phức tạp cho quá trình phục hồi, đặc biệt là công tác hậu cần vận chuyển người và thiết bị đến các địa điểm không nằm trong kế hoạch lúc ban.đầu

Tổ chức có 3 loại lựa chọn chính trong việc thuê hoặc cho thuê Offsite Facilities :

Hot Site - Vị trí "Nóng" : Là loại cơ sở đã được cấu hình đầy đủ và sẵn sàng hoạt động trong một vài giờ. Điểm thiếu sót duy nhất của Hot Site thông thường chính là Data, nó sẽ được lấy từ Backup Site và mọi người sẽ được xử lý dữ liệu như bình thường. Thiết bị và System Software bắt buộc hoàn toàn phải Compatible - Tương thích với các Data đã được restored từ Main Site, không xảy ra bất kỳ vấn đề tiêu cực nào trong khả năng tương thích.

Hot Sites là một sự lựa chọn tốt cho những tổ chức có nhu cầu đảm bảo một Site có sẵn (available) càng sớm càng tốt khi xảy ra thảm họa. Hầu hết các cơ sở Hot Sites đều hỗ trợ Annual Tests - Kiểm tra hàng năm được thực hiện bởi tổ chức, nhằm bảo đảm Site đang hoạt động trong trạng thái cần thiết. Đây là loại Đắt Nhất trong 3 loại Offsite Facilities và có khả năng xảy ra Problems nếu như tổ chức yêu cầu các Hardware hoặc Software độc quyền hoặc quá lạ lùng.
 

Chú ý : Vendor cung cấp Hot Site thông thường sẽ cung cấp các sản phẩm Hardware và Software được sử dụng phổ biến nhất để thu hút phần đông khách hàng. Điều này rất có thể sẽ không bao gồm các Hardware hoặc Software chuyên dụng độc quyền của một khách hàng cụ thể.

Warm Site - Vị trí "Ấm" : Là loại cơ sở đã được cấu hình sẵn một số thiết bị, nhưng thực tế không hẳn là một hệ thống trọn vẹn. Nói cách khác, Warm Site là một Hot Site mà không có các thiết bị đắt tiền. Xây dựng một cơ sở chứa các thiết bị Duplicate Hardware được cấu hình sẵn để hoạt động ngay lập tức là một việc cực kỳ tốn kém !

Do đó, Warm Site thường chỉ là một Alternate Facility với một số thiết bị ngoại vi. Đây là mô hình được sử dụng rộng rãi nhất. Nó ít tốn kém hơn so với Hot Site và có thể Up & Runing trong một khoảng thời gian hợp lý chấp nhận được.

Warm Site có thể là một sự lựa chọn tốt cho những tổ chức phụ thuộc vào Hardware và Software chuyên dụng, bởi vì họ thường sẽ mang Hardware và Software của họ sang Warm Site sau khi thảm họa xảy ra. Tuy nhiên, nhược điểm của Warm Site chính là thường không có sẵn Annual Testing đối với Warm-site Contracts, do đó tổ chức sẽ không thể chắc chắn rằng họ có thể trở lại trạng thái hoạt động trong vòng vài giờ sau khi thảm họa xảy ra.

Cold site - Vị trí "Lạnh" : Là loại cơ sở cung cấp môi trường cơ bản, hệ thống điện, điều hòa không khí, hệ thống nước, sàn nhà, nhưng không có bất kỳ một thiết bị hoặc dịch vụ cộng thêm nào cả. Nó có thể phải mất đến vài tuần để kích hoạt cơ sở và sẵn sàng cho công việc.

Cold Site có thể có Equipment Racks - Giá đỡ thiết bị và Dark Fiber (đường cáp quang mà không có thiết bị kết nối, tổ chức phải tự đầu tư thiết bị), thậm chí có thể có bàn làm việc, nhưng đòi hỏi tất cả các thiết bị tổ chức đều phải tự chuẩn bị, vì loại cơ sở này sẽ không được cung cấp bất kỳ thứ gì khác ngoài những thứ đã kể trên.

Cold Site là lựa chọn ít tốn kém nhất, nhưng đổi lại phải mất nhiều thời gian và công sức mới có thể trở về trạng thái tiếp tục hoạt động sau khi thảm họa xảy ra. Cold Sites thường được sử dụng như là giải pháp Backups cho Call Centers, Manufacturing Plants (nhà máy sản xuất), hoặc các dịch vụ mà có thể di chuyển dễ dàng, hoặc dùng để làm kho và mở rộng thêm cơ sở.

Chú ý : Điều quan trọng mà chúng ta cần phải hiểu, đó là các Sites đã được liệt kê ở trên (Hot Site, Warm Site, Cold Site) được cung cấp bởi nhà cung cấp dịch vụ. Có nghĩa là tổ chức bỏ ra một khoản chi phí thuê bao hàng tháng trả cho nhà cung cấp dịch vụ, nhà cung cấp sẽ cho thuê không gian và dịch vụ này. Hot Site, Warm Site và Cold Site là dạng Subscription Service - Dịch vụ thuê bao.

Redundant Site - Cơ sở Dự Phòng mới là vị trí thuộc quyền sở hữu và duy trì bởi tổ chức, có nghĩa tổ chức không phải trả tiền thuê như mấy Site kia. Redundant Site có thể được xem là "Hot", nó có thể sẵn sàng cho việc hoạt động một cách nhanh chóng, kỳ thi CISSP đòi hỏi chúng ta phải phân biệt được sự khác nhau giữa Hot Site (subscription service) và Redundant site (owned by the company).

Hầu hết các tổ chức đều sử dụng Warm Sites, trong đó có một số thiết bị đơn giản như ổ đĩa, ổ băng và các controller, ngoài ra rất ít các thiết bị khác. Những tổ chức này thường không có đủ khả năng để thuê Hot Site, ngoài ra thời gian Downtime cũng không gây thiệt hại quá nhiều cho họ. Warm Site có thể cung cấp một giải pháp dài hạn hơn (longer-term) so với Hot Site.

Những tổ chức chọn Cold Site phải có khả năng chịu đựng ngừng hoạt động trong 1 đến 2 tuần. Cold Site thường có power, sàn nâng, hệ thống điện và kiểm soát không khí.

Sau đây là một cái nhìn tổng quan về sự khác biệt của mỗi Offsite Facilities :

Hot Site Advantages - Ưu điểm của Hot Site

•  Dễ dàng chuyển đổi để hoạt động chỉ trong vài giờ
•  Highly available : Tính sẵn sàng cao
•  Thường được sử dụng như là giải pháp Short-term (ngắn hạn), nhưng Available lâu
•  Annual testing : Có kiểm tra hàng năm

Hot Site Disadvantages - Khuyết điểm của Hot Site

•  Cực kỳ đắt tiền
•  Giới hạn trong việc chọn lựa Hardware và Software

Warm and Cold Site Advantages - Ưu điểm của Warm và Cold Site

•  Chi phí hợp lý, ít tốn kém
•  Available - Có tính sẵn sàng lâu bởi vì chi phí thấp
•  Trên thực tế có thể sử dụng Hardware và Software độc quyền

Warm and Cold Site Disadvantages - Khuyết điểm của Warm và Cold Site

•  Không Available ngay lập tức sau khi thảm họa xảy ra
•  Operation Testing thường không có sẵn
•  Resources cho việc vận hành không có sẵn ngay lập tức

Tertiary Sites - Những vị trí "Thứ ba"

Trong giai đoạn tiến hành BIA, đội ngũ có thể nhận ra sự nguy hiểm của Primary Backup Facility khi không available lúc cần thiết ! Dẫn đến việc cần có một Tertiary Site. Đây là một Secondary Backup Site, chỉ sử dụng trong trường hợp Primary Backup Site bị unavailable. Secondary Backup Site thông thường còn được gọi là "Backup to the Backup". Điều này về cơ bản ta có thể xem là kế hoạch B khi kế hoạch A không hoạt động hoặc thất bại.

 

 

 

Backup Tapes hoặc các loại Media khác cần được kiểm tra định kỳ trên các thiết bị đặt tại Hot Site, để đảm bảo Media có thể đọc được bởi những thiết bị này. Nếu sử dụng Warm Site, Tapes cần được chuyển đến Original Site và được kiểm tra trên các hệ thống.

Lý do có sự khác biệt này là do khi công ty sử dụng Hot Site, họ phụ thuộc vào các hệ thống đặt ở Hot Site khi thảm họa xảy ra; Do đó, Media bắt buộc phải đọc được trên các hệ thống đặt tại Hot Site. Nếu công ty sử dụng Warm Site, rất có thể họ sẽ phải mang Original Equipment sang Warm Site, cho nên Media bắt buộc phải đọc được trên các hệ thống đang đặt tại công ty.

Reciprocal Agreements - Hiệp định hỗ trợ lẫn nhau
Nếu cơ sở của đệ bị sập, đệ có thể đến ở ké huynh không ?
Phản hồi : Chỉ khi đệ đến với tấm lòng + quà cáp thì huynh sẽ suy nghĩ về điều đó !

Một phương pháp tiếp cận khác của tổ chức đối với Alternate Offsite Facilities đó là thiết lập Reciprocal Agreement, hay còn gọi là Mutual Aid - Hỗ trợ lẫn nhau, với một công ty khác. Có nghĩa là Công Ty A chấp thuận cho để Công Ty B sử dụng Facilities của Công Ty A, nếu như Công Ty B gặp thảm họa, và ngược lại Công Ty B cũng hỗ trợ cho Công Ty A như vậy.

Đây là một phương pháp rẻ hơn nhiều so với các loại lựa chọn Offsite Facilities khác, nhưng nó không phải là một sự lựa chọn tốt nhất. Hầu hết các môi trường, các cơ sở của một công ty đều được sử dụng tối đa (không bao giờ để trống) cho việc lưu trữ, sử dụng không gian, làm kho chứa hàng, vân vân. Việc cho phép một công ty khác đến và làm việc trong cùng một cơ sở có thể đem lại Detrimental - Sự Bất Lợi cho cả song phương.

Sự căng thẳng của hai công ty làm việc chung trong một môi trường có thể đem lại rất nhiều tác hại. Nếu thật sự giải pháp này diễn ra, thì nó chỉ là loại giải pháp Short-term. Điều hành quản lý có thể trở thành một cơn ác mộng và sự pha trộn của các hoạt động có thể mang đến nhiều vấn đề về Security.

Nếu chúng ta cho phép một công ty khác chuyển vào cơ sở của chúng ta và làm việc tại đó, chúng ta có thể tin tưởng vào người bạn thân, người anh em của chúng ta là CEO, nhưng tất cả các nhân viên còn lại của anh ta thì sao ? Chúng ta sẽ phải đối mặt với một nhóm người, những người có thể cần sở hữu quyền truy cập trực tiếp vào Resources của chúng ta (Internet, Wifi, Print ..) trong một môi trường chia sẻ.

Tuy chúng ta ra tay tương trợ giúp đỡ, nhưng nhân viên của công ty B có thể lại xem chúng ta là một mối đe dọa hơn là một bàn tay nhân ái... Cần phải chú ý đặc biệt nếu giao quyền hạn truy cập vào Critical Assets & Resources của công ty bạn cho những người này.

Reciprocal agreements đã được biết đến trong nhiều lĩnh vực kinh doanh đặc thù, chẳng hạn như Newspaper Printing - Ngành in báo chí. Những doanh nghiệp trong lĩnh vực in ấn báo chí thường đòi hỏi thiết bị và công nghệ rất đặc thù, cực kỳ chuyên dụng, điều mà không có bất kỳ Subscription Service nào đáp ứng được.

Những Agreements này thường tuân theo tâm lý "Anh hỗ trợ tui ngày sau có chuyện tui sẽ hỗ trợ lại anh". Đối với hầu hết các tổ chức, họ thường xem đây là Secondary Option - Sự lựa chọn thứ hai đối với Disaster Protection.

Còn một vấn đề cần phải cân nhắc đối với những hiệp định này chính là việc hiệp định Not Enforceable - Không có hiệu lực. Có nghĩa là mặc dù Công Ty A đã nói với Công Ty B họ có thể sử dụng cơ sở của Công Ty A khi cần thiết, nhưng về mặt pháp lý Công Ty A có thể không thực hiện lời hứa này.

Tuy nhiên, vẫn còn nhiều tổ chức lựa chọn giải pháp này, hoặc là do sự hấp dẫn của chi phí thấp, hoặc cũng có thể bởi vì nó là giải pháp khả thi duy nhất trong một số trường hợp.

Những vấn đề quan trọng sau đây cần phải được giải quyết trước khi thảm họa xảy ra nếu tổ chức quyết định lựa chọn giải pháp Reciprocal Agreement với một công ty khác :

•  Bao nhiêu lâu Facility sẽ sẵn sàng khi tổ chức cần đến nó ?

•  Có bao nhiêu nhân viên sẽ hỗ trợ cho việc tích hợp hai môi trường lại với nhau và hỗ trợ liên tục ?

•  Làm thế nào tổ chức có thể nhanh chóng di chuyển sang Facility dự trù này ?

•  Các vấn đề liên quan đến Interoperability - khả năng tương thích ?

•  Có bao nhiêu nguồn tài nguyên sẽ được cung cấp cho tổ chức khi cần đến ?

•  Sự xung đột và Sự khác biệt sẽ giải quyết như thế nào ?

•  Làm thế nào để Change Control và Configuration Management có thể diễn ra ?

•  Bao nhiêu lâu có thể thực hiện việc diễn tập và thử nghiệm ?

•  Làm thế nào để Critical Assets của cả hai công ty được bảo vệ đúng cách ?

 

Redundant Sites - Vị Trí Dự Phòng
Nó là vị trí của chúng ta, chỉ riêng chúng ta sở hữu nó.

Một số công ty sẽ chọn giải pháp Redundant Sites - Vị trí Dự Phòng, có nghĩa nó là một vị trí được trang bị và được cấu hình chính xác y như Primary Site - Vị trí Chính (là vị trí công ty đang sử dụng), nó được xem như một môi trường dự phòng. Những vị trí này thuộc quyền sở hữu của công ty và nó được sao y 100% như môi trường gốc.

Đây là một trong những lựa chọn Backup Facility đắt tiền nhất, bởi vì một môi trường trọn vẹn phải được duy trì thường xuyên ngay cả khi nó không được sử dụng đến, duy trì cho đến khi thảm họa xảy ra thì tổ chức mới di chuyển sang vị trí dự phòng này, nó vô cùng tốn kém ! Tuy nhiên "Đắt xắt ra miếng", nếu công ty có thể tiết kiệm hàng triệu đô la trong vài tiếng đồng hồ sau khi thảm họa xảy ra, thì nó cũng là một sự lựa chọn xứng đáng.

Có nhiều tổ chức bị ràng buộc bởi quy định bắt buộc phải có Redundant Site, cho nên chi phí không phải là vấn đề trong những tình huống này.

Còn có một lựa chọn Backup Facility khác chính là Rolling Hot Site hay còn gọi là Mobile Hot Site, sử dụng phần phía sau của một chiếc xe tải lớn hoặc xe moóc để biến nó thành khu vực xử lý dữ liệu hoặc khu vực làm việc mà chúng ta thường thấy trên phim truyền hình. Rolling Hot Site có tất cả những thứ cần thiết như điện, viễn thông và các hệ thống giúp cho khả năng xử lý công việc diễn ra ngay lập tức.

Rolling HotSite có thể được đậu ở bãi đỗ xe của công ty hoặc một vị trí khác. Ngoài ra, nó còn có thể nhanh chóng dễ dàng được đặt lại với nhau cùng một chỗ, nếu chúng ta sử dụng nhiều Rolling Hot Sites. Các tổ chức quân sự và các công ty bảo hiểm lớn thường hay sử dụng giải pháp này, bởi vì họ cần sự linh hoạt để nhanh chóng di chuyển toàn bộ hoặc một phần cơ sở của họ đến khắp nơi trên thế giới, tùy thuộc vào nhu cầu của họ.

Ngoài ra còn một lựa chọn khác dành cho tổ chức chính là phải có Multiple Processing Centers, nhiều trung tâm xử lý. Một tổ chức có thể sở hữu 10 trung tâm xử lý khác nhau đặt trên toàn thế giới, mà trong các trung tâm này được trang bị sản phẩm và công nghệ có thể giúp di chuyển tất cả Data Processing từ 1 trung tâm này sang tất cả các trung tâm còn lại chỉ trong vài phút nếu như một trung tâm bị gián đoạn.

Công nghệ này có thể được thực hiện bên trong tổ chức hoặc từ một cơ sở của tổ chức đến một cơ sở của bên thứ ba. Một số nhà cung cấp Bureaus - Văn Phòng cũng cung cấp chức năng này cho khách hàng của họ. Nếu Data Process của tổ chức bị gián đoạn, tất cả hoặc một phần Processing sẽ được di chuyển đến Servers của nhà cung cấp văn phòng.

Supply and Technology Recovery - Khôi phục Công Nghệ & Nguồn Cung Cấp

Tại thời điểm này, đội ngũ BCP đã vạch ra được các Business Functions cần thiết phải Up & Running sau khi thảm họa xảy ra, cũng như đã lựa chọn xong giải pháp Backup Facility tốt nhất cho tổ chức của mình. Bước kế tiếp đội ngũ sẽ phải tập trung khai thác vào các mục chi tiết hơn, chẳng hạn như giải pháp Backup cho những điều sau đây :

• Network and computer equipment
• Voice and data communications resources
• Human resources
• Transportation of equipment and personnel
• Environment issues (HVAC)
• Data and personnel security issues
• Supplies (paper, forms, cabling, and so on)
• Documentation

Môi trường kỹ thuật hiện tại của tổ chức cần phải được hiểu rõ. Có nghĩa là Planners - Những người lập kế hoạch phải biết chi tiết về network, công nghệ communications, computers, thiết bị network, và các Softwares cần thiết để những chức năng quan trọng Up & Running.

Có rất nhiều thứ có thể gây ngạc nhiên cho một số người, những người không hoàn toàn hiểu rõ về mạng lưới của tổ chức được cấu hình như thế nào và hoạt động ra làm sao. Bởi vì mạng lưới có thể đã được thiết lập cách đây từ 5 đến 10 năm, đã qua nhiều giai đoạn phát triển như một thiếu niên đi qua tuổi dậy thì.

Có những thiết bị mới, những máy tính mới, những Software mới được thêm vào, VoIP có thể được tích hợp, và DMZ có thể đã chia thành ba DMZs tách biệt, ngoài ra còn xuất hiện thêm Extranet cho các đối tác của công ty. Hoặc có thể công ty đã mua lại và sát nhập với một công ty khác, sát nhập luôn cả hệ thống mạng của công ty đó vào cùng. Hơn mười năm trôi qua, công nghệ thay đổi từng giây từng phút và những người đang bảo trì cho môi trường công nghệ hiện tại không phải là những người đã xây dựng nó từ 10 năm về trước.

Nhiều bộ phận IT đã trải qua kinh nghiệm thay đổi nhân sự liên tù tì mỗi năm, và hầu hết các sơ đồ hệ thống mạng đều bị out-of-date, bởi vì ai cũng bận bịu với công việc của riêng mình, chỉ trừ khi có lúc cần dùng đến sơ đồ mạng thì họ mới update mà thôi. Cho nên đội ngũ BCP cần phải đảm bảo rằng, nếu môi trường mạng bị phá hủy một phần hoặc toàn phần, thì đội ngũ phải có đủ kiến thức cũng như kỹ năng để xây dựng lại nó.

Chú ý : Nhiều tổ chức đang có xu hướng chuyển sang sử dụng Voice over IP (VoIP), có nghĩa nếu như mạng bị downtime, Network và Voice Capability sẽ trở thành unavailable. Đội ngũ cần xem xét vấn đề trang bị Redundant Voice Systems.

Hardware Backups - Sao lưu Phần Cứng

Đội ngũ đã xác định xong các thiết bị cần thiết để giữ cho Critical Functions Up & Running. Chúng có thể bao gồm : Servers, User Workstations, Routers, Switches, Tape Backup Devices, Hubs, và nhiều hơn thế nữa. Việc thống kê các thiết bị cần thiết trong có vẻ đơn giản, cho đến khi các cuộc diễn tập của đội ngũ diễn ra sẽ đi sâu vào chi tiết hơn.

Nếu đội ngũ đang lên kế hoạch sử dụng Images để rebuild lại hệ thống lên Servers mới (bởi vì hệ thống cũ đã bị phá hủy do thảm họa) thì phải đảm bảo Images này hoạt động trên những Servers hoặc thiết bị được dùng để rebuild.

Sử dụng Images Rebuild thay vì phải xây dựng lại hệ thống có thể giúp tiết kiệm được thời gian rất nhiều, trừ khi đội ngũ phát hiện ra rằng các thiết bị thay thế là một Version mới, Images không thể hoạt động trên những Version mới này cho nên sẽ không dùng đến giải pháp Images Rebuild.

Đội ngũ BCP nên lập kế hoạch cho đội ngũ Recovery sử dụng những Current Images của tổ chức, ngoài ra cũng cần phải có Manual Process - Hướng dẫn sử dụng cách build lại Critical System từ những cấu hình cần thiết nếu như mọi thứ đều sụp đổ.

Đội ngũ BCP cũng cần phải xác định thời gian bao nhiêu lâu thiết bị mới sẽ được chuyển đến. Ví dụ, nếu tổ chức xác định ABCDEF sẽ là nhà cung cấp dịch vụ thay thế thiết bị cho họ, thì đội ngũ BCP sẽ phải xác định xem thời gian bao lâu để nhà cung cấp dịch vụ này gửi 20 Servers và 30 Workstations đến Offsite Facility của tổ chức ?

Sau khi thảm họa xảy ra, lỡ lúc đó công ty mới phát hiện ra thiết bị thay thế cần đến 1 tháng mới có thể được giao đến, khi đó thật sự là thảm họa trong thảm họa. Cho nên, SLA của các nhà cung cấp cần phải được thẩm định, để đảm bảo công ty sẽ không bị một thảm họa kép do sự chậm trễ gây ra.

Sau khi các điều khoản trong SLA đã được hiểu rõ ràng, đội ngũ cần phải đưa ra quyết định giữa hai việc : phụ thuộc vào Vendor hay trang bị luôn Redundant System trong trường hợp thiết bị chính bị phá hủy. Như đã mô tả trước đây, khi rủi ro tiềm ẩn của tổ chức đã được xác định, tốt nhất là phải tiến hành phân tích Cost/Benefit và triển khai các bước Preventive để giảm thiểu bớt thiệt hại tiềm năng.

Sau khi tính toán xong giá trị MTD, đội ngũ sẽ biết được công ty có thể tồn tại trong bao nhiêu lâu khi không có một thiết bị cụ thể nào đó. Dữ liệu này nên được sử dụng để đưa ra quyết định công ty sẽ phụ thuộc vào SLA của Vendor hay tự trang bị sẵn Hot-swappable Redundant System.

Chú ý : Các loại công nghệ Backup Tape khác nhau có thể được sử dụng như : Digital Linear Tape, Digital Audio Tape, Advance Intelligent Tape. Đội ngũ cần phải đảm bảo họ hiểu về loại công nghệ mà tổ chức sẽ sử dụng và xác định các nhà cung cấp cần thiết, trong trường hợp Tape-Reading Device cần phải được thay thế.

Software Backups - Sao lưu phần mềm

Hầu hết bộ phận IT của các tổ chức đều có hàng loạt các đĩa Software và thông tin Licensing được tập trung quản lý ở một chỗ. Nếu cơ sở đã bị phá hủy và môi trường hiện tại của bộ phận IT đã được xây dựng lại, làm thế nào để bộ phận IT truy cập vào những Software Packages này ? Đội ngũ BCP cần đảm bảo phải có một bảng thống kê (inventory) các Software cần thiết dành cho Critical Functions và có bản backup copies của chúng đặt tại Offsite Facility.

Hardware sẽ trở nên vô giá trị đối với tổ chức nếu như không có Software cần thiết chạy trên nó. Software cần được backup có thể thuộc nhiều loại như : ứng dụng, tiện ích, databases hoặc có thể là hệ điều hành. Continuity Plan cần phải có Provisions - Các điều khoản quy định về Backup và bảo vệ những hạng mục này cùng với Hardware và Data.

Đội ngũ BCP cần phải đảm bảo có tối thiểu 2 bản Copies các HĐH và Critical Applications của công ty. Một bản được lưu trữ tại chỗ còn các bản copies khác cần được lưu trữ an toàn tại Offsite (địa điểm dự phòng). Những bản copies này cần được kiểm tra định kỳ và cần được re-create khi có những Versions mới của software được tung ra.

Thời nay rất hay phổ biến chuyện các tổ chức làm việc với Software Developers để tạo ra Customize Software Programs. Ví dụ trong thế giới ngân hàng, các tổ chức tài chính cần Software để cho phép giao dịch viên của họ tương tác với Accounts, lưu trữ thông tin Account trong Database và Mainframes, cung cấp Online Banking, thực hiện sao chép dữ liệu, và thực hiện hàng ngàn loại chức năng khác nhau cho nghiệp vụ ngân hàng.

Đây là loại Software chuyên dụng được phát triển và cung cấp thông qua một số ít Software Vendors tại thị trường này. Khi ngân hàng A mua loại Software này cho tất cả các chi nhánh của họ, Software này đã được customized đặc biệt cho môi trường và nhu cầu của họ. Sau khi Banking Software này được cài đặt, toàn bộ tổ chức sẽ hoạt động phụ thuộc vào nó từng phút từng giây.

Khi ngân hàng A nhận được Software và tùy chỉnh chuyên dụng từ Software Vendor, thông thường họ không nhận được Source Code. Thay vào đó, Software Vendor cung cấp cho ngân hàng A phiên bản đã compiled. Điều gì sẽ xảy ra nếu như Software Vendor này bị phá sản bởi thảm họa hoặc bởi thất bại trong kinh doanh ? Khi đó, ngân hàng A sẽ cần một Vendor mới để bảo trì và cập nhật Banking Software của họ; Lúc này, Vendor mới sẽ cần đến Source Code của Software này, đào đâu ra bây giờ ?

Cơ chế bảo vệ mà ngân hàng A cần thực hiện gọi là Software Escrow. Software Escrow nghĩa là có một bên thứ ba đứng trung gian để nắm giữ source code, bản sao lưu compiled code, manuals hướng dẫn và các tài liệu hỗ trợ khác. Sẽ có một Contract giữa 3 bên : Software Vendor, Customer và Third Party, vạch ra những ai có thể tác động đến Source code, tác động cái gì và khi nào thì được phép động đến source code.

Hợp đồng này thường tuyên bố rằng Customer sẽ có thể tác động đến Source Code khi và chỉ khi Vendor phá sản hoặc ngừng kinh doanh, không thể thực hiện các trách nhiệm đã cam kết, hoặc có hành vi vi phạm hợp đồng gốc (original contract). Nếu bất kỳ hành vi nào trong các hành vi này diễn ra, khi đó Customer vẫn được bảo vệ bởi vì họ có quyền truy cập vào source code và các tài liệu cần thiết khác thông qua phía đại diện Third-party.

Rất nhiều tổ chức đã bị tê liệt (crippled) hoàn toàn bởi vì không thực hiện giải pháp Software Escrow. Đội ngũ BCP cần phải xác định vấn đề này như một Vulnerability trong quá trình Analysis và triển khai các biện pháp Preventive.

Documentation
Chúng ta đã đưa ra một kế hoạch tuyệt vời vào 6 tháng trước. Có ai đã ghi nó lại không ?

Documentation dường như là một nhiệm vụ đáng sợ đối với hầu hết tất cả mọi người, những người này sẽ cố gắng tìm nhiệm vụ khác để làm nhằm đảm bảo họ không phải bị mắc kẹt (stuck) trong việc ghi chép tài liệu Processes và Procedures. Mặc dù tổ chức đã phân bổ tài nguyên, trách nhiệm Backup Hardware & Software đến Offsite Facility, duy trì nó và luôn giữ cho mọi thứ up-to-date nhưng nếu như không documentation lại, khi thảm họa xảy ra sẽ không ai biết cách làm thế nào để đặt một đống bùi nhùi này lại với nhau.

Restoration - Phục hồi Files có thể là một sự thách thức nhưng cũng chẳng thấm vào đâu so với việc phục hồi toàn bộ môi trường đã ngập trong lũ lụt của tổ chức. Procedures cần được ghi chép lại bởi vì chúng thật sự cần thiết. Documentation cần phải bao gồm các thông tin như : Cách cài đặt Images, cấu hình OS và Servers, cách cài đặt Software đúng cách, vân vân.

Ngoài ra còn các Documentation khác chẳng hạn như : Danh bạ điện thoại, vạch ra những người cần được liên lạc, theo thứ tự nào và ai là người chịu trách nhiệm thực hiện các cuộc gọi điện này. Documentation cũng phải có thông tin liên lạc đến các Vendors cụ thể, cơ quan khẩn cấp, Offsite Facilities và bất kỳ mối liên hệ nào trong lúc cần thiết phải được gọi đến.

Hầu hết các môi trường mạng đều phát triển theo thời gian. Configurations đã thay đổi trong nhiều năm để hoạt động trong một môi trường độc đáo, Service Packs và Patches được cài đặt để sửa chữa nhiều Problem. Mong đợi một người hoặc một nhóm người xuyên qua tất cả các bước này, trong khi diễn ra khủng hoảng để thực hiện công việc của họ giống lúc bình thường trong đó tất cả mọi thành phần đều hoạt động liền mạch với nhau thật sự là một giấc mơ đẹp.

Cho nên Documentation là một phần tất yếu của Business, là một phần tất yếu của Disaster Recovery và Business Continuity.

Điều quan trọng là chúng ta cần phải tạo ra một hoặc nhiều vai trò chịu trách nhiệm về Documentation. Như tất cả các hạng mục đã được đề cập trong chương này, chúng ta chỉ nói "Tất cả Documentation cần up-to-date và được bảo vệ hợp lý" là một chuyện dễ dàng, tuy nhiên nói và làm là hai việc hoàn toàn khác nhau. Một khi đội ngũ BCP đã xác định ra các nhiệm vụ cần phải được thực hiện, các nhiệm vụ này bắt buộc phải được "assign" đến những cá nhân có trách nhiệm cho việc đó.

Nếu những bước này không được thực hiện, đội ngũ BCP có thể sẽ lãng phí rất nhiều thời gian và tài nguyên để xác định những nhiệm vụ này, tổ chức có thể gặp nguy hiểm nghiêm trọng nếu thảm họa xảy ra.

Chú ý: Tổ chức có thể cần phải củng cố Communications Channels - Kênh liên lạc và Relationships - Mối quan hệ với cơ quan chính phủ và các lực lượng ứng phó khẩn cấp. Trong giai đoạn BIA, đội ngũ cần phải liên hệ với Local Authorities - Chính quyền địa phương để tìm hiểu về những rủi ro vị trí địa lý và cách truy cập vào khu vực Emergency. Nếu tổ chức đã bắt đầu khởi tạo BCP, sẽ có nhiều nhóm Emergency Response cần phải liên lạc trong giai đoạn Recovery.

Human Resources - Nhân sự

Một trong các nguồn tài nguyên phổ biến nhất chính là Con Người. Human Resources - Nhân sự là một thành phần quan trọng đối với bất kỳ mọi Process, nó cần phải được nghĩ đến và tích hợp vào trong kế hoạch. Điều gì sẽ xảy ra nếu chúng ta phải di chuyển tổ chức sang địa điểm dự phòng cách 520km ? Chúng ta không thể mong chờ mọi người sẽ lái xe đến địa điểm mới và đi về trong ngày. Chúng ta có nên trả tiền thuê nhà tạm thời cho những người này ? Có phải trả phí di chuyển, phí xa nhà hay không ?

Chúng ta có nên thuê nhân viên mới trong khu vực địa phương của Offsite Facility hay không ? Nếu vậy, ta cần kỹ năng gì từ họ ? Đội ngũ BCP nên xuyên qua một loạt các câu hỏi này.

Nếu một thảm họa cực lớn xảy ra không chỉ gây ảnh hưởng đến cơ sở của tổ chức mà còn đến các vùng lân cận, bao gồm cả nhà dân, bạn nghĩ nhân viên của bạn sẽ lo lắng cho gia đình họ hay cho tổ chức nhiều hơn ?

Thật đáng tiếc, một số nhân viên có thể bị tử vong trong cuộc thảm họa, đội ngũ cần phải xem xét việc làm thế nào để có thể thay thế những nhân viên này một cách nhanh chóng thông qua các Headhunter hoặc một số Agency tạm thời. Điều này thật sự là một chuyện cực kỳ đau lòng, không ai muốn nhắc đến, nhưng thực tế vẫn là thực tế. Đội ngũ chịu trách nhiệm xác định Threats và Solutions cần phải suy nghĩ về tất cả những đề này.

Các tổ chức nên chuẩn bị sẵn Executive Succession Planning - Kế hoạch kế nhiếm vị trí điều hành. Có nghĩa nếu một người nào đó ở vị trí điều hành cấp cao nghỉ hưu, rời khỏi công ty, hoặc bị giết thì tổ chức vẫn chủ động được do đã xác định trước các bước cần thiết để bảo vệ công ty.

Việc mất mát một nhà quản lý cấp cao có thể để lại vài "lỗ thủng" cho công ty, cần phải nhanh chóng đưa ra một người kế nhiệm mới để đảm trách vị trí đó. Mục đích của Succession Plan là xác định những người sẽ chịu trách nhiệm cho vị trí khuyết này. Các tổ chức thông thường đều có vai trò "Phó - Deputy". Ví dụ, một tổ chức có thể có Deputy CIO, Deputy CFO và Deputy CEO sẵn sàng tiếp nhận nhiệm vụ cần thiết nếu như CIO, CFO hoặc CFO trở nên Unavailable.

Thông thường ở các tổ chức lớn còn có một loại Policy chỉ ra rằng : Hai hoặc nhiều nhân viên cấp cao không được phép tiếp xúc cùng một Risk đặc biệt trong cùng một thời điểm. Ví dụ, CEO và CFO không được phép đi du lịch trên cùng một chuyến bay. Nếu máy bay bị rơi mà cả 2 đều thiệt mạng, khi đó công ty có thể phải đối mặt với nguy hiểm rất lớn.

Đây là lý do tại sao bạn không bao giờ nhìn thấy Tổng Thống và Phó Tổng Thống Hoa Kỳ hay đi cùng nhau trên cùng một chuyến bay. Nó không phải vì họ không thích và giữ khoảng cách với nhau, mà bởi vì Hoa Kỳ có một Policy chỉ ra rằng : Để bảo vệ đất nước Mỹ, các nhà lãnh đạo hàng đầu không thể có cùng một rủi ro trong cùng một thời điểm.

 

    

The End-User Environment - Môi trường Người Dùng

Người dùng thường được xem là những con ong thợ chăm chỉ trong một tổ chức, cho nên họ phải được cung cấp môi trường hoạt động càng sớm càng tốt sau khi thảm họa xảy ra. Điều này có nghĩa đội ngũ BCP cần phải hiểu về môi trường hoạt động hiện hành và kiểm tra các thành phần Critical để có thể tái tạo lại chúng khi cần thiết.

First Issue - Vấn đề đầu tiên liên quan đến người dùng đó là : làm thế nào để thông báo đến họ về sự cố thảm họa, ai sẽ nói cho họ biết họ cần phải đi đâu và khi nào ?

Một Tree Structure - Cấu trúc cây thư mục Managers có thể được phát triển. Khi thảm họa xảy ra, người ở trên cùng Tree sẽ gọi đến 2 nhà quản lý nằm dưới, sau đó họ lần lượt cùng nhau gọi tiếp 3 nhà quản lý, cứ lần lượt như vậy cho đến khi tất cả Managers đều được thông báo. Mỗi Manager sẽ chịu trách nhiệm thông báo cho những người mà anh ta quản lý.

Sau đó, một hoặc hai người sẽ phải chịu trách nhiệm điều phối các vấn đề liên quan đến người dùng. Có nghĩa là chỉ đạo người dùng chuyển đến cơ sở mới, đảm bảo cho họ có đủ các tài nguyên cần thiết để hoàn thành công việc, phục hồi dữ liệu và làm đầu mối liên lạc - Liaison giữa các nhóm khác nhau. Những người chịu trách nhiệm điều phối chỉ đạo cần phải dễ dàng được nhận thấy----bằng cách mặc một chiếc áo hoặc đội một chiếc mũ có dấu hiệu Emergency. Ngoài ra cần đứng ở vị trí mà mọi người đều có thể nhìn thấy, điều này sẽ giúp giảm bớt sự bối rối và hoảng loạn trong lúc trải qua giai đoạn khó khăn vất vả.

Trong hầu hết các trường hợp sau khi thảm họa xảy ra, đội ngũ BCP và các nhân viên thực hiện việc xác định Critical Functions trong giai đoạn Analysis phải là những người được đưa trở lại làm việc đầu tiên (lời quá vậy !).  Cho nên quá trình Recovery cho môi trường người dùng cần được đặt trong nhiều giai đoạn khác nhau. Giai đoạn đầu tiên là đưa tất cả Critical Department trở lại hoạt động, giai đoạn tiếp theo là đưa các Departments được xếp loại quan trọng 2 trở lại hoạt động, cứ lần lượt như thế.

Đội ngũ BCP cần phải xác định môi trường người dùng, chẳng hạn như người dùng có thể làm việc trên Stand-alone PCs không ? Hay cần phải kết nối vào Network mới có thể thực hiện công việc ? Ví dụ trong một tổ chức tài chính, người dùng có thể làm một số việc nhỏ trên Stand-alone PCs như điền Account Forms, xử lý văn bản, công việc kế toán, nhưng nếu muốn cập nhật hồ sơ khách hàng và tương tác với Database thì họ phải được kết nối vào hệ thống máy chủ.

Đội ngũ BCP cũng cần phải xác định các công việc Automated hiện tại, làm thế nào để có thể tiến hành Manually các công việc này nếu đó là điều bắt buộc khi thảm họa xảy ra ?

Nếu mạng lưới bị downtime trong vòng 12 giờ, các công việc cần thiết có thể được thực hiện thông qua phương pháp sử dụng bút và giấy hay không ? Nếu kết nối Internet bị "rớt" trong vòng 5 giờ, các kênh liên lạc cần thiết có thể thông qua điện thoại hay không ? Thay vì chuyển thông điệp qua hệ thống Email, ta có thể tạm thay bằng bác đưa thư để chuyển thông tin qua lại hay không ?

Ngày nay, chúng ta phụ thuộc rất nhiều vào công nghệ, chúng ta thường nghĩ rằng nó luôn luôn có sẵn cho chúng ta sử dụng. Đội ngũ BCP phải nhận thức được rằng công nghệ có thể Unavailable trong một khoảng thời gian nhất định, anh em ta phải tìm ra được giải pháp thay thế cho những tình huống này.

Data Backup Alternatives - Giải pháp sao lưu thay thế dữ liệu

Như những điều chúng ta đã thảo luận cho đến nay, các giải pháp Backup cần thiết cho Hardware, Software, Data, Personnel và Offisite Facilities, đều tùy thuộc vào mỗi công ty và đội ngũ BCP của họ, khi họ quyết định tất cả những thành phần này đều cần thiết cho sự sống còn của họ.

Data - Dữ liệu ngày nay đã trở thành một trong các tài sản quan trọng nhất đối với mọi tổ chức. Những Data này có thể bao gồm : bảng tính tài chính, kế hoạch chi tiết về các sản phẩm mới, thông tin khách hàng, bảng thống kê sản phẩm, bí mật thương mại và còn nhiều thứ hơn nữa.

Trong Domain Information Security & Risk Management, chúng ta đã xuyên qua Risk Analysis Procedures và Data Classification Processes. Đội ngũ BCP không chịu trách nhiệm cho việc thiết lập và duy trì Data Classification Procedures của tổ chức, mà đội ngũ có thể nhận ra rằng tổ chức sẽ phải đối mặt với rủi ro nếu như các Procedures này không được phát triển.

Điều này nên được xem là một Vulnerability và phải báo cáo đến cho Management. Management sẽ phải thiết lập một nhóm khác để xác định Data của công ty, xác định Loss Criteria và thiết lập Data Classification Structure & Processes.

Trách nhiệm của đội ngũ BCP là cung cấp giải pháp để bảo vệ dữ liệu và xác định phương pháp khôi phục chúng sau khi thảm họa xảy ra. Trong phần này, chúng ta sẽ được truyền thụ những "bí kíp" khác nhau để bảo vệ và khôi phục Data khi cần thiết. Data thường xuyên thay đổi hơn Hardware và Software, cho nên Backup Procedures của nó cần phải dựa trên cơ sở Continual - Liên Tục.

Data Backup Process - Quá trình sao lưu dữ liệu cần phải hợp lý và hiệu quả. Nếu dữ liệu trong các Files thay đổi nhiều lần trong ngày, Backup Procedures sẽ diễn ra vài lần trong ngày hoặc buổi tối để đảm bảo tất cả mọi sự thay đổi đề được capture lại và lưu trữ. Nếu dữ liệu thay đổi mỗi tháng, Backup Data hàng đêm là một sự lãng phí thời gian và tài nguyên rất vô ích.

Backup một File thường tốt hơn nhiều so với việc copy nó thành nhiều Files.

Đội ngũ Operations sẽ chịu trách nhiệm cho việc xác định Data nào được backup và bao nhiêu lâu sẽ Backup. Các bản Backups này có thể thuộc nhiều loại như Full, Differential hoặc Incremental, đôi khi còn có thể kết hợp các loại này lại với nhau để sử dụng. Hầu hết các Files thường sẽ không thay đổi mỗi ngày, vì vậy để tiết kiệm thời gian và tài nguyên, cách tốt nhất là nên đưa ra Backup Plan thật chi tiết và hợp lý.

Vậy làm thế nào để chúng ta biết được Data đã thay đổi và nó cần được Backup mà không phải lúc nào cũng nhìn vào Modification Date của mỗi File ? Điều này có thể được thực hiện bởi Archive Bit. File Systems của các HĐH theo dõi, phát hiện Files đã được chỉnh sửa hoặc thay đổi bằng cách thiết lập Archive Bit. Nếu File được sửa đổi hoặc được tạo mới, File System sẽ thiết lập giá trị Archive Bit = 1.

Backup Software có thể dựa vào thiết lập Archive Bit này trong khi ra quyết định những gì được Backup và những gì không được Backup.

Full Backup - Sao lưu toàn phần, đúng như tên gọi của nó : Backup tất cả các Data và lưu vào một số loại thiết bị lưu trữ. Trong khi diễn ra Full Backup, Archive Bit được "cleared", có nghĩa nó được thiết lập = 0. Công ty có thể chọn chỉ sử dụng Full Backup, trong trường hợp Restoration Process chỉ là một bước, nhưng việc Backup và Restore có thể mất một khoảng thời gian rất dài.

Hầu hết các công ty thường lựa chọn kết hợp Full Backup với Differential hoặc Incremental Backup. Differential Backup sẽ sao lưu các Files mới được thay đổi hoặc được cập nhật (modified) kể từ lần Full Backup trước đó. Khi dữ liệu cần được khôi phục lại (restored), Full Backup sẽ diễn ra đầu tiên sau đó là đến lượt Differential Backup gần nhất diễn ra. Differential Process sẽ không làm thay đổi giá trị Archive Bit.

Incremental Backup sẽ sao lưu tất cả các Files đã có sự thay đổi diễn ra (changed hoặc modified) so với lần Full hoặc Incremental Backup trước đó và thiết lập Archive Bit = 0. Khi dữ liệu cần được khôi phục lại, Full Backup sẽ diễn ra đầu tiên, sau đó lần lượt sẽ đến Incremental Backup theo thứ tự thích hợp (xem Figure 9-2)

 
    

 

Nếu tổ chức vừa trải qua một trận thảm họa và họ sử dụng Incremental Backup, lúc này đầu tiên tổ chức cần phải Restore Full Backup lên các ổ cứng của tổ chức, sau đó tiếp tục tới mỗi Incremental Backup đã được sao lưu trước khi thảm họa xảy ra (và sau lần Full Backup cuối cùng).

Cho nên nếu Full Backup đã được thực hiện vào 6 tháng trước và bộ phận Operations đều thực hiện Incremental Backup hàng tháng, khi đó đội ngũ khôi phục sẽ Restore Full Backup đầu tiên và lần lượt đến từng Incremental Backups cũ hơn cho đến khi tất cả chúng đều được khôi phục lại.

Vậy quá trình Backup nào là tốt nhất ? Nếu công ty muốn thực hiện sao lưu và phục hồi một cách thật đơn giản, có thể chọn chỉ dùng Full Backups nhưng quá trình này tốn rất nhiều thời gian và dung lượng lưu trữ. Mặc dù sử dụng Differential và Incremental Backup Processess sẽ gia tăng sự phức tạp nhiều hơn, nhưng đổi lại chúng ta sẽ tốn ít thời gian và dung lượng lưu trữ hơn.

Differential Backup sẽ mất nhiều thời gian sao lưu hơn so với Incremental Backup, nhưng nó sẽ tốn ít thời gian phục hồi (restore) hơn so với Incremental Backup. Bởi vì khi tiến hành phục hồi, Differential Backup sẽ diễn ra trong 2 bước, trong khi đó Incremental Backup cần phải khôi phục đúng trình tự chính xác cho nên sẽ lâu hơn (corret sequence).

Dù cho tổ chức thân yêu của chúng ta lựa chọn bất kỳ loại Backup nào, nhưng có một điều quan trọng cần phải nhớ đó là tuyệt đối không được Mix - Kết hợp hai quá trình Differential và Incremental Backups lại với nhau ! Điều này có thể dẫn đến Overlap - Sự chồng chéo lên nhau khiến cho Files có thể bị bỏ qua (missed).

Critical Data - Dữ liệu quan trọng cần được sao lưu và lưu trữ tại khu vực Onsite và Offsite. Các bản sao lưu tại Onsite cần có thể dễ dàng truy cập đến trong trường hợp Nondisasters và cần cung cấp quá trình Restore nhanh chóng để các hoạt động có thể trở lại trạng thái bình thường. Tuy nhiên, các bản sao lưu tại Onsite không đủ để cung cấp khả năng bảo vệ thật sự.

Dữ liệu còn cần phải lưu trữ tại cơ sở Offsite trong trường hợp xảy ra Disasters hoặc Catastrophes. Ngoài ra còn một lựa chọn nên thực hiện đó là vị trí cơ sở Offsite cần được tham chiếu (reference) đến cơ sở chính. Vị trí lưu trữ các bản sao lưu Offsite càng gần thì càng dễ dàng cho việc truy cập đến chúng, nhưng điều này có thể rất nguy hiểm nếu xảy ra thảm họa thuộc tầm quy mô lớn, gây ảnh hưởng đến cơ sở chính lẫn cơ sở Backup.

Tổ chức có thể lựa chọn cơ sở Backup đặt xa hơn so với cơ sở chính, điều này khiến cho việc truy cập đến trở nên khó khăn hơn nhưng sẽ làm giảm nguy cơ như đã nói qua. Một số tổ chức có tài chính dồi dào thường chọn giải pháp : Có nhiều hơn một cơ sở Backup, một đặt gần cơ sở chính và một đặt ở vị trí xa hơn.

Onsite Backup Information cần được lưu trữ trong khu vực an toàn có khả năng chống cháy (fire-resistant), chịu nhiệt (heat-resistant) và chống thấm nước (waterproof). Procedures dành cho việc sao lưu và phục hồi dữ liệu cần có thể dễ dàng truy cập đến, ngoài ra nó cũng cần phải dễ hiểu đối với Operators hoặc Administrators, những người không quen thuộc với một hệ thống đặc thù nào đó.

Trong những tình huống khẩn cấp, những anh chàng phụ trách việc sao lưu và phục hồi dữ liệu đôi khi lại không có mặt ở xung quanh, lúc này cần phải thuê tạm thời các chuyên gia bên ngoài để đáp ứng được thời gian phục hồi có phần hạn chế. Backup Strategy - Chiến lược sao lưu dự phòng cần phải được đưa vào một bảng kiểm kê (account), để nếu bất kỳ bước nào gặp phải sự hỏng hóc chúng ta cũng có thể "Backing Out - quay ngược trở lại" hoặc tiến hành xây dựng lại Data.

Chúng ta thực sự có thể phục hồi lại dữ liệu ? Backing up Data - Sao lưu dữ liệu là một điều tuyệt vời trong cuộc sống này, nó có thể được phục hồi đúng cách thậm chí còn tốt hơn. Đã có rất nhiều tổ chức mắc phải cảm giác sai lầm (false sense) về sự an toàn trong quá trình Backup dữ liệu của họ. Cảm giác an toàn của họ có thể sẽ biến mất trong tích tắc, khi họ đang phải đối mặt với thảm họa mà quá trình Restore lại không hoạt động.

Ví dụ, tổ chức đã trả tiền để thuê một cơ sở Backup nhằm mục đích sử dụng để lưu trữ an toàn các bản sao lưu, hàng tuần tổ chức sẽ vận chuyển các bản sao lưu đến cơ sở này. Các bản sao lưu được vận chuyển bằng tàu điện ngầm, có đôi lần các Tapes sao lưu bị đặt trên mặt đất trong lúc chờ tàu đến. Tàu điện ngầm lại có động cơ rất lớn tạo ra từ trường riêng của chúng, điều này có thể gây ảnh hưởng trực tiếp lên Tapes sao lưu, nghĩa là dữ liệu có thể dễ dàng bị xóa bỏ hoặc bị hỏng hóc.

Tổ chức lại không bao giờ Test quá trình phục hồi của họ, cho đến ngày họ gặp phải thảm họa. Họ bối rối hoảng loạn và ngạc nhiên tột cùng khi phát hiện ra dữ liệu họ liên tục sao lưu trong 3 năm đã hoàn toàn bị hư hỏng khiến không thể nào sử dụng được.

Electronic Backup Solutions

Manually Backing Up - Sao lưu hệ thống và dữ liệu thủ công có thể mất nhiều thời gian (time-consuming), dễ bị lỗi (error-prone) và khá tốn kém (costly). Một số công nghệ sao lưu tự động có thể được lựa chọn để thay thế cho sao lưu thủ công. Mặc dù các công nghệ này thường đắt hơn so với sao lưu thủ công, nhưng đổi lại nó nhanh hơn và chính xác hơn, có thể cần thiết cho những thông tin mang tính chất thay đổi thường xuyên.

Trong số các công nghệ và phương pháp sao lưu dữ liệu điện tử thì Disk Shadowing rất giống với Data Mirroring.

Disk Shadowing được sử dụng để đảm bảo tính sẵn sàng của Data và cung cấp giải pháp Fault-Tolerant, bằng cách Duplicating Hardware và tạo ra thêm nhiều bản sao cho Data. Data sẽ tự động được tạo ra và duy trì trên hai hoặc nhiều ổ đĩa giống hệt nhau. Systems cần tương tác với những Data này sẽ kết nối đến tất cả các ổ đĩa cùng một lúc. Tất cả các ổ đĩa này dưới "góc nhìn" của người dùng sẽ như là 1 ổ duy nhất.

Điều này cung cấp khả năng "transparency" với người dùng, để khi ai đó cần lấy dữ liệu, anh ta sẽ không phải quan tâm xem dữ liệu đó nằm trên ở đĩa nào. Khi anh ta "Write" dữ liệu vào ổ đĩa, dữ liệu này sẽ được ghi lên tất cả các ổ đã thiết lập Shadow.

Disk Shadowing cung cấp Online Backup Storage - Lưu trữ sao lưu trực tuyến, nó có thể làm giảm thiểu hoặc thay thế các hoạt động vận hành Offline Backup định kỳ. Ngoài ra giải pháp này còn có một lợi ích khác nữa, đó chính là khả năng tăng hiệu suất Đọc - Read operation performance. Multiple Paths - Đa đường cung cấp Duplicate Data, Shadow có thể thực hiện Multiple Read Request song song.

Disk Shadowing thường được xem là một giải pháp đắt tiền, bởi vì nó yêu cầu từ hai ổ cứng trở lên để lưu trữ cùng một Data. Nếu một công ty có lượng Data chứa đầy 100 ổ cứng, họ cần phải mua thêm ít nhất 100 ổ cứng nữa mới triển khai được Disk Shadowing, chưa tính phần phí phải duy trì số lượng ổ cứng đó nữa. Công ty sẽ chọn giải pháp này nếu như họ thật sự có nhu cầu về Fault-Tolerance.

Nếu một ổ đĩa bị hỏng, ít nhất Shadow Set vẫn available trên các ổ khác. Khi đó một ổ đĩa mới có thể được gán vào và các Data ở những ổ khác có thể được sao chép qua từ Shadow Set. Việc sao chép có thể diễn ra Offline, nhưng điều này có thể khiến cho Data trở nên Unavailable trong một khoảng thời gian nhất định.

Hầu hết các giải pháp cung cấp chức năng Disk Shadowing đều cho phép tiến hành sao chép Online, ổ đĩa mới được Hot-swapped và có thể thực hiện chức năng sao chép mà không cần thiết phải Offline các ổ đĩa.

Electronic Vaulting và Remote Journaling là những giải pháp mà các công ty cần phải nhận thức được.

Electronic Vaulting tạo ra các bản copies cho Files, khi chúng được modified và vận chuyển định kỳ sang Offsite Backup. Việc vận chuyển không diễn ra trong thời gian thực, mà chúng được thực hiện theo từng đợt - Batches. Cho nên công ty có thể chọn tất cả các Files đã có sự thay đổi (changed) để gửi sang Offsite Backup theo giờ, theo ngày, theo tuần hoặc theo tháng.

Loại hình sao lưu này thường diễn ra trong nhiều tổ chức tài chính, khi nhân viên giao dịch chấp nhận một khoản tiền gửi (deposit) hoặc rút tiền (withdrawal), sự thay đổi trên tài khoản của khách hàng có thể diễn ra tại nội bộ Database của chi nhánh giao dịch, ngoài ra còn có những bản sao lưu tất cả Customer Records được gửi đến Remote Site.

Electronic Vaulting là phương pháp vận chuyển hàng loạt thông tin dữ liệu sang Offsite Facilities cho mục đích sao lưu dự phòng.

Remote Journaling cũng là một phương pháp vận chuyển dữ liệu sang Offsite Facility, nhưng nó thường chỉ dành để vận chuyển Transaction Logs và Journal (nhật ký), chứ không phải tất cả mọi Files. Những bản Logs này thường chứa Deltas (những sự thay đổi) đã diễn ra trong từng Files riêng lẻ. Nếu trường hợp dữ liệu bị hỏng cần được khôi phục lại, tổ chức sẽ lấy những bản Logs này để rebuild lại dữ liệu đã bị hỏng.

Journaling - Ghi nhật ký là một việc rất có hiệu quả đối với quá trình Database Recovery, nó có thể cần thiết trong việc giữ các Versions khác nhau đối với Software và Files, đặc biệt trong môi trường phát triển phần mềm. Object và Source Code cần phải được sao lưu cùng với Libraries, Patches và Fixes. Offsite Facility cần phải mirror với Onsite Facility, nghĩa là mỗi Facility cần phải có Full Set về thông tin và các Files hiện tại, được up-to-date thường xuyên.

 

 

 

 

Một loại công nghệ Software Backup khác mà chúng ta sẽ đề cập đến, đó chính là Tape Vaulting. Có rất nhiều doanh nghiệp sao lưu dữ liệu của họ vào Tapes, sau đó chuyển giao thủ công chúng sang Offsite Facility bằng phương thức chuyển phát nhanh hoặc một nhân viên giao nhận. Với công nghệ tự động Tape Vaulting, dữ liệu sẽ được vận chuyển qua đường Serial đến Backup Tape System tại Offsite Facility.

Offsite Facility của doanh nghiệp sẽ duy trì Backup Tape Systems và thay đổi Tapes khi cần thiết. Dữ liệu có thể được sao lưu truy xuất nhanh chóng khi cần thiết. Công nghệ này sẽ làm giảm thiểu các bước thủ công so với quy trình Tape Backup truyền thống.

Việc vận chuyển thủ công Tape Data sang Offsite Facility thường rất dễ bị lỗi (error-prone). Trong khi đó đối với Electronic Tape Vaulting, việc vận chuyển Data qua mạng lưới điện tử có thể làm giảm thiểu sai sót, cải thiện tốc độ Recovery và việc Backups có thể diễn ra thường xuyên hơn, tất nhiên chi phí sẽ đắt hơn, tiền nào của đó mà ...

 

 

Choosing a Software Backup Facility
Tui thích cơ sở này bởi vì phong thủy của nó rất tốt !

Tổ chức cần phải giải quyết một số vấn đề và đặt ra một số câu hỏi cụ thể khi quyết định lựa chọn cơ sở để lưu trữ Backups. Sau đây là danh sách chỉ ra một số vấn đề cần phải được thông qua, trước khi giao phó cho Vendor cung cấp dịch vụ cơ sở Backup :

•  Media có thể được truy cập trong khoảng thời gian cần thiết hay không ?
•  Facility có phải đóng cửa vào cuối tuần và những ngày lễ, chỉ hoạt động khoảng thời gian cụ thể trong ngày hay không ?
•  Các cơ chế kiểm soát truy cập có được gắn liền với hệ thống báo động đến đồn công an gần nhất hay không ?
•  Facility có khả năng bảo vệ Media khỏi một loại các mối đe dọa hay không ?
•  Tính sẵn sàng của dịch vụ vận chuyển đến kho chứa Backup Data ?
•  Có bất kỳ mối đe dọa địa lý nào ở Facility như lũ lụt, động đất, lốc xoáy hay không ?
•  Có hệ thống PCCC hay không ?
•  Facility có cung cấp hệ thống kiểm soát và giám sát nhiệt độ & độ ẩm hay không ?
•  Loại kiểm soát truy cập physical, administrative và technical nào được sử dụng ?

Những câu hỏi và các vấn đề cần được giải quyết sẽ khác nhau, tùy thuộc vào loại hình của tổ chức, nhu cầu của tổ chức và các yêu cầu của họ về Backup Facility.

 

 

 

Insurance - Bảo hiểm

Trong quá trình BIA, đội ngũ có thể phát hiện ra một số Threats mà tổ chức không thể nào ngăn chặn được. Tất cả những rủi ro do các mối đe dọa này mang đến thường cực kỳ nguy hiểm, đó là lý do tại sao Insurance - Bảo hiểm lại tồn tại.

Quyết định mua hay không mua bảo hiểm cho một mối đe dọa cụ thể, cũng như chi phí dành cho loại bảo hiểm đó, cần dựa trên xác suất mà mối đe dọa đó sẽ trở thành sự thật, cũng như tiềm năng mất mát của tổ chức, những điều này được xác định trong quá trình BIA.

Đội ngũ BCP nên làm việc với Management để hiểu thêm về phạm vi bảo hiểm và các options bảo hiểm khác nhau, cũng như giới hạn của mỗi option. Mục đích của việc này là để đảm bảo phạm vi bảo hiểm có thể lấp đầy Gaps - những kẽ hở mà các biện pháp đối phó hiện tại không thể nào chống lại được.

Cũng giống như con người có các loại bảo hiểm khác nhau về sức khỏe và cuộc sống, các doanh nghiệp cũng có các loại hình bảo hiểm khác nhau mà họ có thể mua. CyberInsurance là một trong số đó.

CyberInsurace - Bảo hiểm công nghệ là một loại bảo hiểm mới, bảo hiểm cho những tổn thất gây ra bởi tấn công DDoS, Malware, Hacker, Electronic Theft, vân vân. Trong khi mọi người thường được hỏi : anh bao nhiêu tuổi, tiền sử sức khỏe, có hút thuốc hay không để xác định bảo hiểm sức khỏe của anh ta, thì các công ty lại được hỏi về Security Program của họ, chẳng hạn như tổ chức có IDS, Antivirus, Firewalls hoặc các biện pháp an ninh khác hay không ?

Công ty cũng có thể chọn mua Business Interruption Insurance Policy - Chính sách bảo hiểm gián đoạn kinh doanh. Với loại hình chính sách này, nếu công ty bị trì hoãn Business trong một khoảng thời gian nhất định, tổ chức bảo hiểm sẽ trả tiền cho các chi phí đã nêu cũng như khoảng doanh thu bị mất.

Bảo hiểm của công ty cần phải được Review định kỳ hàng năm, bởi vì mức độ mối đe dọa có thể thay đổi và tổ chức có thể mở rộng ra những mạo hiểm mới, cho nên cần phải được bảo hiểm thích hợp. Tuy nhiên, việc mua bao hiểm không nên đẩy tổ chức vào tình trạng "sai lầm" về nhận thức an ninh. Bảo hiểm cũng có hạn chế của nó, nếu công ty không thực hành Due Care, tổ chức bảo hiểm có thể sẽ không phải chịu trách nhiệm đền bù cho họ nếu như thảm họa xảy ra.

Điều quan trọng là chúng ta phải đọc và hiểu "HÀNG CHỮ IN NHỎ" trong những hợp đồng bảo hiểm, nhằm đảm bảo chúng ta hiểu được sự mong đợi của tổ chức về bảo hiểm, chứ không chỉ riêng sự mong đợi đơn phương từ các tổ chức bán bảo hiểm.

Recovery and Restoration

BCP Coordinator - Điều phối viên BCP phải xác định những đội ngũ cần thiết nếu thảm họa xảy ra, những đội ngũ này được đào tạo đúng cách và luôn luôn sẵn sàng. Những loại đội ngũ này thường phụ thuộc vào tổ chức. Sau đây là một số ví dụ về các loại đội ngũ mà tổ chức cần phải xây dựng :
 

•  Damage assessment team
•  Legal team
•  Media relations team
•  Network recovery team
•  Relocation team
•  Restoration team
•  Salvage team
•  Security team
•  Telecommunications team

Điều phối viên BCP cần phải có một sự hiểu biết rõ ràng về nhu cầu của tổ chức và các loại đội ngũ cần được phát triển và đào tạo. Các nhân viên cần được gán cho các đội ngũ cụ thể, dựa trên kiến thức và kỹ năng của họ. Mỗi đội ngũ cần có một Leader, người sẽ trực tiếp chỉ đạo cho thành viên và các hoạt động của đội.

Những người Team Leaders này không chỉ có trách nhiệm đảm bảo đáp ứng mục tiêu dành cho đội ngũ của mình, mà còn phải liên kết với các đội ngũ khác để đảm bảo có thể cùng làm việc trong giai đoạn song song.

Restoration Team chịu trách nhiệm cho môi trường làm việc và các hoạt động bên trong Alternate Site, còn Salvage Team chịu trách nhiệm khôi phục Original Site. Cả hai đội ngũ này cần phải biết làm rất nhiều việc, chẳng hạn như cài đặt OS, cấu hình Workstations và Servers, kéo dây Cáp và dây điện, cấu hình mạng và các dịch vụ mạng, cài đặt thiết bị và ứng dụng, vân vân.

Cả hai đội ngũ này cũng cần phải biết cách khôi phục dữ liệu từ các cơ sở Backup và phải biết cách để làm việc đó một cách an toàn, đảm bảo tính toàn vẹn, tính bí mật và tính sẵn của hệ thống và dữ liệu không bị ảnh hưởng.

BCP - Business Continuity Plan cần vạch ra rõ ra cách đội ngũ cụ thể, trách nhiệm của họ và Notification Procedures. Plan phải ghi rõ ràng phương thức sẽ sử dụng để liên lạc với các Team Leaders trong giờ làm việc và sau giờ làm việc. Một Role hoặc một Team cần phải được tạo ra để tiến hành Damage Assessment - Đánh Giá Thiệt Hại sau khi thảm họa đã xảy ra. Assessment Procedures cần phải được ghi chép rõ ràng, bao gồm các bước sau đây :

•  Xác định nguyên nhân gây ra thảm họa.
•  Xác định tiềm năng thiệt sâu xa.
•  Xác định các khu vực và các Business Functions bị ảnh hưởng.
•  Xác định mức độ chức năng đối với các nguồn tài nguyên quan trọng.
•  Xác định những nguồn tài nguyên cần phải được thay thế ngay lập tức (immediately).
•  Ước tính thời gian trong bao nhiêu lâu mới có thể mang Critical Functions trở lại hoạt động.
•  Nếu nó mất nhiều thời gian hơn so với giá trị MTD trước đây đã tính toán để phục hồi vận hành, khi đó thảm họa cần phải được công bố và BCP cần đưa vào để hành động.

Sau khi thông tin này được thu thập và đánh giá, nó sẽ cho chúng ta biết những gì đội ngũ cần phải làm và liệu có thực sự cần phải kích hoạt BCP hay không. Điều phối viên BCP và đội ngũ cần phải phát triển Activation Criteria - Tiêu chí kích hoạt. Sau khi tiến hành Đánh Giá Thiệt Hại, nếu một hoặc nhiều tình huống được vạch ra trong tiêu chí đã diễn ra, khi đó đội ngũ sẽ di chuyển đến chế độ Recovery.

Các tổ chức khác nhau có tiêu chí khác nhau, bởi vì động cơ kinh doanh và Critical Functions luôn thay đổi từ tổ chức này sang tổ chức khác. Tiêu chí có thể bao gồm một hoặc tất cả các yếu tố sau đây :

•  Nguy hiểm đến tính mạng con người
•  Nguy hiểm đến nhà nước hoặc an ninh quốc gia
•  Thiệt hại đối với cơ sở
•  Thiệt hại đối với những hệ thống quan trọng
•  Ước tính giá trị thời gian Downtime mà tổ chức phải chịu đựng

Sau khi Đánh Giá Thiệt Hại hoàn tất và Plan được kích hoạt, các đội ngũ khác nhau phải được triển khai, cùng nhập vào giai đoạn Recovery. Mỗi đội ngũ có nhiệm vụ của riêng mình, ví dụ : Restoration Team chịu trách nhiệm chuẩn bị Offsite Facility, Network Team chịu trách nhiệm rebuild lại Network và System, Relocation Team sẽ lo việc di dời nhân viên của tổ chức sang cơ sở mới.

Recovery Process - Quá trình phục hồi cần được tổ chức càng sớm càng tốt để tổ chức có thể trở lại làm việc trong thời gian sớm nhất. Điều này nói trong sách thì có vẻ dễ dàng, nhưng trong thực tế thì khó khăn hơn nhiều.

Đây là lý do tại sao Written Procedures rất quan trọng. Trong quá trình BIA, Critical Functions và những nguồn tài nguyên của nó đã được xác định. Đây là những thứ mà các đội ngũ phải ưu tiên cùng nhau làm cho nó trở lại Up & Running sớm nhất.

Templates cần phải được phát triển trong giai đoạn Plan Development. Những Templates này sẽ được sử dụng bởi các đội ngũ khác nhau để bước qua các giai đoạn cần thiết và document lại những phát hiện của họ. Ví dụ, nếu có một Step nào đó không thể thực hiện cho đến khi được trang bị hệ thống mới, thì điều này phải được ghi vào Template.

Những Templates này giúp cho đội ngũ duy trì nhiệm vụ, cũng như nhanh chóng báo cho Team Leaders biết về tiến trình, trở ngại và thời gian phục hồi tiềm năng. Vào thời điểm tổ chức di chuyển sang cơ sở hoặc địa điểm mới, tổ chức đang bước vào Reconstitution Phase - Giai đoạn tái xây dựng.

Tổ chức sẽ luôn luôn nằm trong tình trạng Emergency cho đến khi họ trở lại hoạt động tại Original Primary Site hoặc địa điểm mới được xây dựng thay thế Primary Site, bởi vì tổ chức sẽ luôn rất dễ bị tổn thương (vulnerable) trong lúc hoạt động tại Backup Facility.

Có nhiều vấn đề Logistical - Hậu cần nên được xem xét khi công ty bắt đầu trở về lại Primary Site. Sau đây là danh sách về những vấn đề này :

•  Đảm bảo Safety - An toàn cho nhân viên
•  Đảm bảo cung cấp một môi trường hoàn chỉnh (điện, cơ sở hạ tầng, nước, hệ thống HVAC)
•  Đảm bảo có đầy đủ các thiết bị và dịch vụ cần thiết để làm việc
•  Đảm bảo các kênh liên lạc và kết nối hoạt động tốt
•  Kiểm tra môi trường mới

Sau khi điều phối viên, management và đội ngũ cứu hộ (salvage) ký vào bảng cam kết sẵn sàng chuyển về Facility mới, đội ngũ cứu hộ cần phải thực hiện các bước sau đây :

•  Sao lưu dữ liệu từ Backup Facility và Restore chúng vào New Facility.
•  Terminate - Chấm dứt một cách cẩn thận các hoạt động Contingency.
•  Vận chuyển thiết bị và con người một cách an toàn về New Facility.

LEAST Critical Functions - Các chức năng ít quan trọng (chú ý là ít nhé !) cần phải được di chuyển trở lại đầu tiên. Vì nếu có vấn đề gì xảy ra, thì các hoạt động quan trọng của công ty cũng sẽ không bị ảnh hưởng tiêu cực. Hãy để các bộ phận ít quan trọng làm "quân cảm tử". Nếu họ sống sót, khi đó mới đến các thành phần quan trọng di chuyển trở lại Primary Site.

 

 

 

 

Cũng đã gần hết quyển bí kíp BCP & DRP, cho đến thời điểm này đội ngũ BCP đã thực hiện toàn bộ những bước sau :

1. Đã phát triển Continuity Planning Policy Statement
•  Đã vạch ra phạm vi và mục tiêu của Business Continuity Plan và vai trò của đội ngũ BCP

2. Đã tiến hành Business Impact Analysis (BIA)
•  Đã xác định Critical Business Functions, những tài nguyên của chúng và những giá trị MTD
•  Đã xác định Threats và đã tính toán tác động của những Threats này
•  Đã xác định Solutions
•  Đã trình bày kết quả đến Management

3. Đã xác định và đã triển khai Preventive Controls
•  Đã đưa vào các cơ chế kiểm soát để giảm thiểu rủi ro
•  Đã mua bảo hiểm, đã triển khai thực hiện Facility Structural Reinforcements (củng cố cấu trúc cơ sở), đã triển khai các giải pháp Backup cho Data, đã cài đặt các cơ chế Redundant và Fault-tolerant, vân vân.

4. Đã phát triển Recovery Strategies
•  Đã triển khai thực hiện Processes để tổ chức Up & Running trong thời gian cần thiết
•  Đã lập ra những đội ngũ cần thiết, đã phát triển mục tiêu và procedures cho mỗi đội ngũ, đã tạo ra notification steps và đã lên kế hoạch Activation Criteria, đã xác định các giải pháp Alternate Backup, vân vân.

Vậy là đội ngũ BCP đã phải làm việc rất lâu, rất khó khăn mới có được tất cả những hạng mục đã đề cập ở trên. Bây giờ anh em ta cần phải đặt tất cả các giải pháp và các steps vào trong plan, test plan, đào tạo cho mọi người và đặt ra Strategies để duy trì & giữ cho Plan luôn được up-to-date.

 
 

 

 

 
Developing Goals for the Plans
Mục tiêu của tui là sở hữu một du thuyền, nghỉ hưu ở tuổi 55 và dài ra thêm 10cm (!?)
Phản hồi : Tuyệt, chúng ta sẽ tích hợp tất cả điều này vào trong BCP (!)

Nếu chúng ta không thiết lập Goals - Mục tiêu, làm thế nào chúng ta biết được khi nào dự án hoàn thành và những cái mà chúng ta làm có thực sự thành công hay không? Việc thiết lập mục tiêu luôn là việc vô cùng quan trọng dù cho chúng ta làm bất cứ điều gì, nhưng đặc biệt nó rất quan trọng đối với Business Continuity & Recovery Plans.

Việc xác định mục tiêu giúp chúng ta phân bố trực tiếp tài nguyên và công việc một cách hợp lý, phát triển các chiến lược cần thiết, và hỗ trợ cho tổng thể chương trình. Sau khi mục tiêu đã được thiết lập, chúng gián tiếp cung cấp sự hướng dẫn thực sự cho Plan. Bất kỳ ai tham gia vào các dự án dù lớn dù nhỏ cũng đều biết rằng, các chi tiết phức tạp có thể dễ dàng bị bỏ qua và mục tiêu thực sự không được hoàn thành.

Mục tiêu được thiết lập ra để giữ cho tất cả mọi người đi đúng hướng, đảm bảo nỗ lực tới lúc cuối cùng.

Tuyệt vời, vậy là chúng ta đã thiết lập xong các mục tiêu quan trọng. Tuy nhiên, nếu có mục tiêu kiểu : "Giữ cho tổ chức luôn có thể kinh doanh nếu một trận động đất xảy ra", đây là một mục tiêu tốt, nhưng nó thật sự không mang lại hữu ích rõ ràng. Để thực sự hữu ích, mục tiêu cần phải chứa một số thông tin quan trọng như sau :

•  Responsibility - Trách nhiệm :

Mỗi cá nhân liên quan đến Recovery & Continuity cần có trách nhiệm của riêng họ, được giải thích và viết ra bằng văn bản nhằm đảm bảo họ có sự hiểu biết rõ ràng trong khi tình huống hỗn loạn xảy ra. Mỗi nhiệm vụ cần được giao cho từng cá nhân một cách hợp lý nhất để họ xử lý nó. Những cá nhân này phải biết tổ chức mong đợi những gì từ phía họ, điều đó được thực hiện thông qua những buổi đào tạo, tập huấn (drills), kênh liên lạc và thông qua Documentation.

Ví dụ : Thay vì chỉ chạy ra khỏi tòa nhà và la hét khi có thảm họa xảy ra, thì một cá nhân nào đó phải biết rằng anh ta có trách nhiệm phải tắt Servers trước khi anh ta có thể chạy ra khỏi tòa nhà và la hét như một tên điên rồ.

•  Authority - Thẩm quyền :

Trong giai đoạn xảy ra khủng hoảng, điều quan trọng là phải biết ai đang phụ trách việc gì. Teamwork - Làm việc theo nhóm rất quan trọng trong những tình huống này. Hầu như các đội ngũ sẽ trở nên tốt hơn nhiều nếu có một người lãnh đạo - Leader đáng tin cậy.

Các Leaders cần phải dự kiến những bước sẽ diễn ra trong giai đoạn khủng hoảng và phải hiểu phương hướng mà đội ngũ sẽ cung cấp cho các nhân viên. Clear-cut Authority - Thẩm quyền rõ ràng sẽ hỗ trợ cho việc giảm bớt sự nhầm lẫn và tăng cường sự hợp tác.

•  Priorities  - Ưu tiên

Priorities giúp cho chúng ta có thể biết được những gì rất quan trọng, quan trọng hơn so với những thứ khác. Các bộ phận khác nhau cung cấp những chức năng khác nhau cho tổ chức. Priorities cần thiết để chúng ta biết được những bộ phận nào bắt buộc phải được back online trước tiên ! Cũng như các ưu tiên dành cho bộ phận (department), các ưu tiên dành cho hệ thống, thông tin, và chương trình cũng phải được thiết lập.

Priorities có thể cần thiết để đảm bảo Database sẽ được trở lại Up & Running đầu tiên, sau đó mới đến File Server, vân vân. Các ưu tiên chung cần phải được thiết lập bởi Management với sự giúp đỡ của các phòng ban và các nhân viên IT.

•  Implementation and testing - Thực hiện và kiểm tra

Thật sự tuyệt vời khi viết ra những ý tưởng sâu sắc và xây dựng nó thành Plans, nhưng sẽ tuyệt vời hơn nếu chúng ta thực hiện và thử nghiệm Plans, chứ không chỉ làm việc trên bàn giấy. Sau khi Continuity Plan đã được phát triển, nó thực sự có thể được đưa vào hành động. Nó cần phải được ghi chép và đặt ở những nơi có thể dễ dàng truy cập đến trong giai đoạn khủng hoảng.

Những người được giao nhiệm vụ cụ thể cần được đào tạo và cung cấp thông tin để biết cách hoàn thành nhiệm vụ, các cuộc diễn tập cần phải được thực hiện để mọi người có thể thử nghiệm những tình huống khác nhau. Các cuộc diễn tập cần phải diễn ra ít nhất một lần trong năm, và toàn bộ chương trình phải liên tục được cập nhật và cải tiến.

Các nghiên cứu đã chỉ ra rằng 65% doanh nghiệp bị mất khả năng tính toán - Computing Capabilities trong 1 tuần, không bao giờ có thể phục hồi trở lại, dẫn đến việc phá sản thất bại trong kinh doanh. Không thể phục hồi trở lại nhanh chóng hoặc có hiệu quả, có thể khiến doanh nghiệp bị thất thoát doanh thu, tệ hơn nữa là ảnh hưởng tiêu cực đến danh tiếng của doanh nghiệp.

Trong một thế giới cạnh tranh, khách hàng họ có rất nhiều lựa chọn. Nếu tổ chức không chuẩn bị sẵn sàng để phục hồi trở lại sau một sự gián đoạn hoặc thảm họa, khách hàng có thể sẽ đi tìm nhà cung cấp khác ngay lập tức, không một chút đắn đo.

Implementing Strategies - Triển khai thực hiện các chiến lược

Sau khi các chiến lược đã được quyết định, chúng cần được ghi chép lại và đưa vào vị trí chuẩn bị bởi đội ngũ BCP. Điều này chính là động thái chuẩn bị để chuyển từ giai đoạn Planning sang giai đoạn Implementing và Action.

Như đã nêu trước đây, các bản Copies của Plans cần được lưu trữ ở một hoặc nhiều địa điểm hơn so với cơ sở chính, vì nếu cơ sở chính bị phá hủy hoặc bị ảnh hưởng tiêu cực, Continuity Plan vẫn có thể sẵn sàng cho đội ngũ sử dụng.

Ngoài ra còn một vấn đề cũng khá quan trọng, đó là Plan có thể được tạo thành nhiều định dạng khác nhau, bao gồm cả hai phiên bản giấy và điện tử. Electronic Version - Phiên bản điện tử sẽ không hữu ích cho lắm nếu như chúng ta không có điện để chạy máy tính. Tuy nhiên ngày nay ta còn có máy tính bảng như Kindle Fire, iPad 2 cho nên không lo lắm vấn đề này.

Ngoài ra bản sao của Recovery Documents cần được đặt ở văn phòng lẫn nhà của BCP Coordinator hoặc Management, những cá nhân chủ chốt nên có khả năng tiếp cận dễ dàng vào những tài liệu này, cũng như Critical Procedures và Call Tree Information. Một cách đơn giản để thực hiện việc này chính là publish Call Tree Data lên danh thiếp gắn liền với thẻ nhân viên hoặc lưu giữ trong ví.

Trong tình huống khẩn cấp, tốn vài phút đọc thông tin có ngay trong ví sẽ tốt hơn việc đi lục tìm danh sách hoặc đợi đến lúc mở Laptop lên để tìm kiếm thông tin.

Plan nên đề cập chi tiết đến tất cả các topics mà chúng ta đã được giới thiệu qua. Actual Format - Định dạng thực tế của Plan sẽ phụ thuộc vào môi trường, các mục tiêu của Plan, priorities và các Threats đã xác định. Sau khi mỗi hạng mục được kiểm tra và được documented, các topics của Plan có thể được phân chia thành các phân loại cần thiết.

Một cấu trúc thường được chấp nhận đối với BCP được minh họa trong Figure 9-3. BCP của mỗi tổ chức sẽ có cái nhìn khác nhau, nhưng Core Topics sẽ khá tương đồng nhau. Chúng ta đã xuyên qua các thành phần này ở những phần trước. Vai trò của Plan chính là cung cấp cấu trúc Preplanned và Sequenced của các Processes khác nhau. Plan cũng cần phải tích hợp vào mức độ linh hoạt, bởi vì không một ai biết chính xác những thảm họa gì sẽ xảy ra.

 

 

Một số tổ chức phát triển Plans riêng lẻ cho từng nhiệm vụ và từng mục tiêu cụ thể. Những Plans khác nhau này được mô tả trong Table 9-2. Nó tùy thuộc vào Management và đội ngũ BCP xác định số lượng và loại Plans cần được phát triển và triển khai thực hiện.
 

Table 9-2

Loại Plan	Diễn giải
Business resumption plan	Tập trung vào việc Re-Create - Tái tạo lại các quy trình kinh doanh cần thiết, chúng cần phải được Reestablished - Tái thiết lập thay vì tập trung vào các thành phần IT.
Continuity of operations plan (COOP)	Thiết lập Senior Management và Headquarters sau thảm họa. Vạch ra Roles và Authorities, thứ tự Succession (kế thừa), và nhiệm vụ của mỗi Role.
IT contingency plan	Plan dành cho Systems, Networks và Applications Recovery Procedures quan trọng sau thảm họa. Contingency Plan cần được phát triển cho mỗi System và Application quan trọng.
Crisis communications plan	Bao gồm Roles và cấu trúc thông tin liên lạc Internal và External. Xác định những cá nhân sẽ chịu trách nhiệm giao tiếp (communication) với các đơn vị bên ngoài External.
Cyber incident response plan	Tập trung vào Malware, Hackers, Intrusions, Attacks, và các vấn đề Security khác. Vạch ra các Procedures cho Incident Response.
Disaster recovery plan	Tập trung vào việc khôi phục các cơ chế CNTT sau thảm họa. Trong khi Contigency Plan thường đề cập về Nondisaster thì DRP lại chuyên đề cập Disaster về CNTT.
Occupant emergency plan	Tập trung về Personnel Safety và Evacuation Procedures - Thủ tục sơ tán.

Đội ngũ BCP có thể chọn để tích hợp những Plans này vào trong BCP. Thông thường sẽ tốt hơn so với việc dùng Stand-alone Plans, các Plans tích hợp vào sẽ được xem là một phần Appendix - Phụ lục, tài liệu lúc này sẽ rõ ràng, súc tích và rất hữu dụng.

Test & Drills - Kiểm tra và diễn tập Disaster Recovery nên được thực hiện ít nhất mỗi năm một lần. Tổ chức tuyệt đối không nên đặt niềm tin thực tế vào trong Plan đã phát triển cho đến khi nó được thử nghiệm thực sự. Test & Drills chuẩn bị nhân lực cho những gì tổ chức có thể phải đối mặt và cung cấp một môi trường có sự kiểm soát để "learn" những nhiệm vụ đã được dự kiến trong kế hoạch.

Những cuộc kiểm tra và thử nghiệm này cũng chỉ ra nhiều vấn đề (issues) cho đội ngũ Planning và Management, những vấn đề mà có thể họ lỡ bỏ qua hoặc không suy nghĩ đến trước đây trong quá trình lập kế hoạch. Các cuộc diễn tập còn có thể chứng minh cho tổ chức thấy rằng, công ty thực sự có thể phục hồi sau thảm họa.

Cuộc diễn tập cần phải có kịch bản được xác định trước, chỉ ra rằng tổ chức thực sự có thể phải đối mặt với thảm họa xảy ra trong một ngày. Parameters (tham số) và Scope của cuộc diễn tập cần phải được làm rõ trước khi tiến hành diễn tập. Tester Team - Đội ngũ thử nghiệm phải thỏa thuận với nhau chính xác về những gì sẽ được đem ra thử nghiệm, làm thế nào để xác định cuộc diễn tập mang lại kết quả thành công hay thất bại.

Đội ngũ phải thỏa thuận về thời gian diễn ra và thời gian thực hiện cuộc diễn tập, ai sẽ tham gia vào cuộc diễn tập, ai sẽ nhận được các "bài tập" cụ thể, và những bước cần thực hiện là gì ? Ngoài ra đội ngũ cũng cần phải xác định cho dù Hardware, Software, Personnel, Procedures hay Communication Lines cũng đều nên được kiểm tra.

Nếu cuộc diễn tập bao gồm luôn cả bước di chuyển một số thiết bị sang địa điểm thay thế, khi đó việc vận chuyển, mở rộng thiết bị (extra equiment) và Alternate Sites cũng cần phải được đánh giá và giải quyết.

Hầu hết các tổ chức đều không đủ khả năng cho các cuộc diễn tập như Interrupt Production (gián đoạn sản xuất) hoặc Productivity, cho nên các cuộc diễn tập này có thể sẽ phải diễn ra vào một thời điểm cụ thể khác, nó sẽ yêu cầu cần có Logistical Planning - Lập kế hoạch hậu cần.

Written Exercise Plans - Kế hoạch diễn tập bằng văn bản nên được phát triển. Cuộc diễn tập đầu tiên không nên bao gồm tất cả nhân viên, thay vào đó là một nhóm nhỏ nhân viên, cho đến khi họ hiểu rõ về trách nhiệm của mình. Khi đó, các cuộc diễn tập lớn hơn sẽ diễn ra để các hoạt động tổng thể sẽ không bị ảnh hưởng tiêu cực. Những người thực hiện các cuộc diễn tập này cần phải dự kiến trước được về Problems và Mistakes. Đây là lý do tại sao họ được chọn để diễn tập đầu tiên.

Tổ chức sẽ có nhân viên chịu trách nhiệm để tạo ra Mistake - Sai Lầm trong quá trình diễn tập, để mọi người có thể trải nghiệm những sai lầm này và thực hiện nhiệm vụ của mình một cách hiệu quả hơn khi thảm họa thực sự diễn ra.

Một vài loại hình diễn tập và kiểm tra khác nhau có thể được sử dụng, mỗi loại đều có ưu và khuyết của nó. Những phần sau đây sẽ giải thích chi tiết về các loại diễn tập này.

Checklist Test

Trong loại hình kiểm tra này, các bản sao (copies) của BCP được phân phối đến từng phòng ban và từng khu vực chức năng khác nhau cho mục đích Review. Điều này được thực hiện nhằm để các trưởng phòng ban có thể xem xét Plan và cho biết liệu có bất cứ điều gì sai sót hoặc bị bỏ qua, cần phải bổ sung, chỉnh sửa hoặc xóa bỏ hay không.

Đây là phương pháp để giảm thiểu việc sai sót và thiếu sót cho Plan. Sau khi các phòng ban đã xem xét và đóng góp ý kiến, đội ngũ Planning khi đó sẽ tích hợp những sự thay đổi này vào trong Master Plan - Kế hoạch tổng thể.

Chú ý : Checklist Test còn được gọi là Desk Check Test

Structured Walk-Through Test

Trong loại hình kiểm tra này, đại diện của mỗi phòng ban hoặc khu vực chức năng sẽ cùng ngồi lại với nhau để xem xét Plan, nhằm đảm bảo độ chính xác của kế hoạch. Cả nhóm sẽ xem xét lại Objectives của Plan, thảo luận về phạm vi và Assumptions - Các giả thiết của kế hoạch, xem xét lại cơ cấu tổ chức và Reporting, thẩm định việc kiểm tra, bảo trì và các yêu cầu về đào tạo đã mô tả trong Plan.

Điều này sẽ làm cho mọi người cùng có trách nhiệm đảm bảo việc khôi phục sau thảm họa (disaster recovery) có hiệu quả, ngoài ra loại hình kiểm tra này còn cấp cho mọi người cơ hội review lại những gì chúng ta đã quyết định (decided). Cả nhóm (Group) sẽ xuyên qua nhiều kịch bản khác nhau của kế hoạch, để đảm bảo không bỏ sót bất kỳ điều gì. Điều này cũng giúp nâng cao nhận thức của các thành viên trong nhóm về những thủ tục phục hồi - Recovery Procedures.

Simulation Test

Simulation Test là một cuộc kiểm tra diễn tập mô phỏng. Trong loại hình kiểm tra này đòi hỏi sẽ phải lên kế hoạch và có nhiều người, tất cả các nhân viên hoặc người đại diện của họ phải có mặt để cùng nhau thực hành kế hoặc khôi phục thảm họa dựa trên một kịch bản cụ thể. Scenario - Kịch bản này được sử dụng để kiểm tra phản ứng của mọi người và của từng bộ phận chịu trách nhiệm vận hành, hỗ trợ khi thảm họa xảy ra.

Loại hình này được thực hiện nhằm đảm bảo chúng ta không bỏ quên bất cứ điều gì, cũng như không bỏ qua bất kỳ mối đe dọa nào cả. Nó hoạt động như một chất xúc tác nhằm nâng cao nhận thức của mọi người liên quan đến việc khôi phục sau thảm họa.

Cuộc diễn tập chỉ bao gồm những thứ thực sự sẽ diễn ra trong một thảm họa thực tế, để miêu tả hoàn cảnh trung thực hơn. Simulation Test còn mô phỏng các cuộc di dời sang Offsite Facility, cũng như mô phỏng luôn cả việc vận chuyển các thiết bị thay thế.

Parallel Test

Kiểm tra song song được thực hiện để đảm bảo rằng các Systems cụ thể thực sự có thể được vận hành hoạt động ở Offsite Facility. Trong loại hình kiểm tra này, một số Systems sẽ được vận chuyển sang cơ sở thay thế và đưa vào tiến trình xử lý - Processing. Kết quả Processing tại cơ sở thay thế sẽ được đem ra so sánh với Processing ở cơ sở gốc.

Điều này sẽ chỉ ra cho chúng ta biết được những gì cần phải hiệu chỉnh (tweaking), reconfiguring hoặc các Steps nào khác cần phải diễn ra.

Full-Interruption Test

Đây là loại kiểm tra phổ biến nhất về sự gián đoạn của các hoạt động thường xuyên và năng suất kinh doanh. Original Site - Cơ sở chính thực sự sẽ phải đóng cửa, Processing sẽ diễn ra tại cơ sở thay thế. Recovery Team sẽ phải đáp ứng đầy đủ nhiệm vụ của họ trong việc chuẩn bị Systems và Environment tại cơ sở thay thế. Tất cả Processing chỉ được thực hiện trên các thiết bị đặt tại cơ sở thay thế.

Đây là một cuộc diễn tập Full-blown - Toàn diện, đòi hỏi rất nhiều trong việc lên kế hoạch và phối hợp nhưng đổi lại nó có thể tiết lộ ra nhiều lỗ hổng trong kế hoạch cần phải được sửa chữa trước khi thảm họa thực sự diễn ra. Full-Interruption Test chỉ nên thực hiện sau khi tất cả các loại Test đã đề cập qua (ở phần trước) thành công.

Loại hình kiểm tra diễn tập này là loại mang rủi ro cao nhất, có thể gây ảnh hưởng đến Business một cách nghiêm trọng nếu không được quản lý đúng cách. Do đó, chúng ta cần phải nhận được phê duyệt của Senior Management trước khi thực hiện Full-Interruption Tests.

Loại hình tổ chức và mục tiêu của họ sẽ chỉ ra phương pháp tiếp cận đào tạo có hiệu quả nhất. Mỗi tổ chức có một cách tiếp cận khác nhau và các khía cạnh độc nhất vô nhị. Đào tạo chất lượng cao sẽ làm tăng sự quan tâm và cam kết của nhân viên. Trong khi & Sau khi diễn ra từng loại kiểm tra, một hồ sơ về các sự kiện quan trọng cần được documented và báo cáo đến Management, để họ có nhận thức về tất cả các kết quả trong cuộc kiểm tra.

Other Types of Training

Các nhân viên cần được đào tạo bài bàn về những issues bên cạnh việc khắc phục thảm họa, bao gồm cả First Aid và CPR, làm thế nào sử dụng bình chữa cháy, các tuyến đường sơ tán và các phương pháp kiểm soát đám đông, thủ tục liên lạc khẩn cấp, làm thế nào để tắt các thiết bị đúng cách trong các loại thảm họa khác nhau.

Các nhân viên kỹ thuật có thể cần phải biết thêm về cách Redistribute - Phân phối lại tài nguyên mạng và làm thế nào để sử dụng các đường dây liên lạc khác nếu đường dây chính bị down. Redundant Power Supply cần phải được thẩm tra và các Procedures về cách di dời Critical System từ nguồn cung cấp điện này sang nguồn cung cấp điện khác cũng cần phải được hiểu và được kiểm tra.

Emergency Response

Thông thường, Initial Response - Phản ứng ban đầu trong tình huống Emergency sẽ gây ảnh hưởng đến kết quả cuối cùng. Emergency Response Procedures - Thủ tục ứng phó khẩn cấp là những hành động được chuẩn bị trước, được phát triển để giúp đỡ cho những người ở trong tình trạng khủng hoảng có khả năng đối phó với sự gián đoạn tốt hơn.

Các Procedures này là lớp phòng thủ đầu tiên - first line of defense trong việc đối phó với tình huống khủng hoảng. Những người được up-to-date kiến thức về Disaster Recovery sẽ là những người thực hiện ứng phó tốt nhất, đó là lý do tại sao việc đào tạo và diễn tập được đánh giá là rất quan trọng. Tình trạng khẩn cấp nghĩa là Unpredictable - Không thể đoán trước được, không một ai biết được khi nào nó sẽ diễn ra.

Protection of Life - Bảo vệ cuộc sống, tính mạng chính là điều quan trọng nhất ! Cần phải được ưu tiên giải quyết đầu tiên trước khi quan tâm đến những đối tượng vật chất khác. Đào tạo và các cuộc diễn tập cần giúp cho những người chịu trách nhiệm biết được cách làm thế nào để sơ tán nhân viên một cách an toàn. Xem Table 9-3

 

 

Tất cả mọi nhân viên đều phải biết lối thoát hiểm khẩn cấp, điểm đến của họ là ở đâu. Emergency Gathering Spots - Các điểm tập kết khẩn cấp cần xem xét vấn đề ảnh hưởng khí hậu theo mùa. Một người trong mỗi nhóm sẽ được chỉ định để chịu trách nhiệm đảm bảo việc điểm danh tất cả mọi người trong nhóm. Một người khác sẽ có trách nhiệm thông báo (notifying) đến các cơ quan có thẩm quyền như : sở cảnh sách, nhân viên bảo vệ, PCCC, đội cứu hộ khẩn cấp và Management.

Với việc đào tạo thích hợp, các nhân viên sẽ được trang bị kiến thức xử lý tình huống khẩn cấp tốt hơn so với việc chỉ cong đít lên lo bỏ chạy.

Nếu tình hình diễn ra không đe dọa đến tính mạng, Systems cần được đóng theo một cách có trật tự, Critical Files hoặc Resources cùng với các hạng mục quan trọng khác như túi và ví tiền nên được bỏ lại trong quá trình sơ tán - Evacuation. Có một lý do dành cho việc sắp đặt trật tự các hoạt động.

Cũng giống như tất cả mọi quy trình, đều có những sự phụ thuộc vào tất cả những gì chúng ta làm. Việc thêm hoặc bớt đi một bước nào đó trong thực tế sẽ đem lại tai hại nhiều hơn là lợi ích.

Sau khi mọi thứ đã được tiếp cận một cách hợp lý, một hoặc nhiều người sẽ được yêu cầu giao tiếp với các tổ chức bên ngoài (external), chẳng hạn như báo chí truyền thông, khách hàng, cổ đông, người dân, vân vân. Mọi người nên có sự chuẩn bị trước về phản ứng của các tổ chức bên ngoài này (giận dữ, mừng vui, cảm thông), do đó cần thống nhất cách phản hồi với nhau để giải thích một cách hợp lý, có thống nhất rõ ràng, chứ không có chuyện trống đánh xuôi kèn thổi ngược.

Tổ chức cần phải nhanh chóng trình bày thông tin thảm họa này đến các đối tượng bên ngoài thay vì đợi đến lúc có những người khác tự áp đặt kết luận của họ lên tổ chức, bắt đầu những tin đồn thất thiệt. Ít nhất nên dành một người chịu trách nhiệm giao tiếp với giới truyền thông, phát hành thông cáo báo chí để gửi đi những thông điệp thích hợp.

Ngoài ra còn có một vấn đề không may khác cần phải được xử lý khi tình huống khẩn cấp xảy ra : cướp bóc, phá hoại và gian lận từ Physical cho đến Logical. Sau khi công ty vừa trải qua một kiếp nạn thảm họa, đây thường là lúc họ dễ bị tổn thương nhất - Most Vulnerable, do đó bọn thủ ác có thể lợi dụng lúc này để tận dụng những lỗ hổng trong tổ chức.

Hãy cẩn thận suy nghĩ và lập kế hoạch để xử lý những vấn đề này một cách hợp lý ! Mức độ bảo vệ cần thiết cần phải được xem xét, có khả năng cung cấp trong mọi thời điểm.

Maintaining the Plan - Duy trì kế hoạch

Thật không may, nhiều kế hoạch khác nhau đã được đề cập trong Domain này có thể bị out-of-date một cách nhanh chóng. BCP Out-of-date có thể sẽ mang lại cho tổ chức một cảm nhận sai lầm (false sense) về Security, điều đó có thể vô cùng tai hại nếu thảm họa thực sự diễn ra.

Sau đây là những lý do chính có thể khiến cho Plans bị out-of-date :

•  Business Continuity Process không được tích hợp vào trong Change Management Process.
•  Infrastructure & Environment xảy ra những sự thay đổi.
•  Tái cơ cấu lại tổ chức, sa thải hoặc xảy ra việc sát nhập.
•  Changes - Xảy ra những sự thay đổi về Hardware, Software và Applications.
•  Sau khi Plan được xây dựng, mọi người cảm thấy họ đã hoàn thành công việc.
•  Thay đổi nhân sự.
•  Large Plans mất rất nhiều công sức để duy trì.
•  Plans không có một mối liên kết trực tiếp đến lợi nhuận (profitability).

Các tổ chức có thể giữ cho Plan luôn được up-to-date bằng những hành động sau đây :

•  Làm cho Business Continuity trở thành một phần trong tất cả các quyết định kinh doanh (business decision).
•  Chèn Maintenance Responsibilities - Trách nhiệm duy trì vào trong Job Descriptions.
•  Chèn Plan Maintenance vào trong các kỳ đánh giá hiệu quả làm việc của nhân viên
•  Tiến hành Internal Audits, bao gồm Disaster Recovery & Continuity Documentation & Procedures.
•  Tiến hành các cuộc diễn tập thường xuyên dựa trên Plan
•  Tích hợp BCP vào Change Management Process.

Một trong những cách đơn giản và có hiệu quả nhất để giữ cho Plan up-to-date chính là kết hợp nó vào Change Management Process của tổ chức.

 
    

 

 

 

 

 

Nguyễn Phước Đức - DNA

Email: This email address is being protected from spambots. You need JavaScript enabled to view it.