Sự cố bảo mật và hoạt động ứng phó sự cố
28 min read
Trước hết chúng ta phải thừa nhận với nhau rằng, những năm gần đây các tổ chức, doanh nghiệp bắt đầu có ý thức hơn trong việc đầu tư cho ATTT, ít nhiều thì hệ thống phòng thủ của chúng ta đang trở nên mạnh hơn, được đầu tư trang bị nhiều giải pháp, công nghệ bảo mật tiên tiến. Nhưng ở bên kia chiến tuyến khác, các cuộc tấn công chống lại các hệ thống máy tính sẽ ngày càng phức tạp, gia tăng về tần suất và mức độ tinh vi. Khi việc phòng thủ thất bại những gì còn lại của an toàn thông tin chỉ có thể là xử lý, phản hồi. Nói cách khác xử lý, phản hồi là tuyến phòng thủ cuối cùng của an toàn thông tin.
Những vụ việc lớn trong nước những năm gần đây như VCCORP, VNA bị hack hay rộng hơn trên thế giới như Sony Picture, Ebay, Target hay HackingTeam một công ty chuyên cung cấp “vũ khí tấn công mạng” bị tấn công thâm nhập dữ liệu, hay những báo cáo về sự gia tăng các cuộc tấn công APT cho thấy những hệ thống phòng thủ tưởng như rất kiên cố, cuối cùng cũng thất bại. Rõ ràng. Kẻ tấn công đang ngày càng trở nên tinh nhuệ và khó lường hơn, được trang bị và hậu thuẫn, chống lưng bởi những tổ chức có tiềm lực, mục tiêu nhắm đến vẫn là những dữ liệu có giá trị như thông tin tình báo, sở hữu trí tuệ, kinh doanh… Bất cứ tổ chức nào cũng có thể là mục tiêu tiếp theo. Lúc này khả năng phản ứng của một tổ chức đối với các sự cố mà mình gặp phải sẽ tạo nên sự khác biệt so với những phần còn lại. Trước khi đi vào chi tiết, tôi muốn kể một vài câu chuyện về vấn đề xử lý, phản hồi các sự cố an toàn thông tin (sự cố) tại Việt Nam mà tôi từng tham gia.
Câu chuyện đầu tiên diễn ra vào tháng 8/2014 khi tôi tham gia Forensic cho một máy chủ bị tấn công, kẻ tấn công khi đã khai thác thành công lỗ hổng File upload của một website, có được quyền điều khiển máy chủ cung cấp dịch vụ, sau đó tiến hành Deface một loạt các site trên máy chủ đấy. Từ những thông tin có được từ phía nhà cung cấp dịch vụ, theo họ thì vấn đề này sẽ được đội ngũ kỹ thuật của họ giải quyết êm đẹp bằng việc restore lại dữ liệu mới nhất mà trước đó họ đã update.? Tất nhiên dữ liệu đó sạch hay không nó lại nằm ngoài khả năng của họ. May mắn là trên hệ thống của họ host site của một số cơ quan quan trọng. Nên nhóm của tôi mới có cơ hội tiếp cận. Nhiệm vụ của chúng tôi là điều tra tìm ra thông tin về cuộc tấn công (càng nhiều càng tốt). Câu chuyện thứ hai diễn ra vào tháng 10/2014, một trong những tổ chức hoạt động trong lĩnh vực internet, truyền thông lớn nhất của Việt Nam bị tấn công gây thiệt hại lớn về uy tín lẫn tài chính cho đơn vị này. Công ty chúng tôi nhận được yêu cầu hỗ trợ, mục tiêu cuối cùng vẫn là tìm ra thủ phạm tấn công, tuy nhiện ở vụ này không chỉ chúng tôi mà ngay cả VNCERT, và một số đơn vị khác tham gia ứng phó đều không được tiếp cận nhiều đến hệ thống của khách hàng bởi vì nhiều lý do. Hai câu chuyện trên đều có 1 điểm chung đó là khả năng xử lý, phản hồi của họ rất yếu. Họ không có quy trình, công cụ, cũng như một đội ngũ lành nghề để đáp ứng những công việc trên.
Ở vụ thứ nhất, trong quá trình phân tích các bản ghi sự kiện, chúng tôi tìm thấy nhiều bằng chứng cho thấy kẻ tấn công đã thực hiện quá trình Cover Track. Chính vì thế chúng tôi cần những bản ghi từ hệ thống quản lý log tập trung của nhà cung cấp dịch vụ để phân tích rõ hơn. Tuy nhiên, thật đáng tiếc khi một nhà cung cấp dịch vụ Hosting mà lại không xây dựng một hệ thống như vậy.Ở vụ thứ hai, lúc chúng tôi trao đổi thông tin với khách hàng, thì phần lớn các máy bị tấn công đều đã được tắt nguồn và niêm phong để tiến hành Dead analysis, đây là một cách làm thiếu sót, bởi vì những chứng cứ liên quan đến kẻ tấn công như dữ liệu trong bộ nhớ RAM, dữ liệu mạng, các truy cập… vô tình được phá hủy. Ở vụ này họ chỉ cung cấp cho chúng tôi mẫu mã độc để phân tích, câu chuyện vui nhưng kết thúc chỉ có thế. Tất nhiên là công cụ tìm diệt mã độc sau đó đã ra đời và “làm sạch” đáng kể hệ thống của khách hàng. Ở hai câu chuyện trên, cái mà chúng tôi cần nhất là dữ liệu, càng nhiều, càng tin cậy càng tốt. Chúng tôi cần tiếp cận và thu thập càng nhiều thông tin về hệ thống để xây dựng timeline phục vụ cho việc phân tích. Trong xử lý, phản hồi thì Forensics được xem là một trong những key quan trọng nhất, và một trong những key quan trọng nhất trong Forensics chính là dữ liệu để phân tích. Ở 2 trường hợp trên chúng tôi đều không có những thứ chúng tôi cần.
Hai câu chuyện ở 2 tổ chức, nhưng cũng là câu chuyện của rất rất nhiều công ty, cơ quan khác mà tôi có cơ hội làm việc. Tất cả những sự cố đều thực hiện sau khi việc đã rồi, có nghĩa là họ không có các quy trình cụ thể để thu thập, lưu trữ cũng như bảo vệ những dữ liệu cần thiết phục vụ cho những công việc phản hồi sau này. Công việc của những đơn vị, cá nhân tham gia xử lý sự cố gặp rất nhiều khó khăn vì dữ liệu bị phá hủy, không đủ dữ liệu để phân tích.
Lướt qua những báo cáo gần đây của Trustwave hay Mandiant, cho biết các tổ chức phải mất rất nhiều thời gian để phát hiện sự xâm nhập vào tổ chức mình. Để phát hiện hệ thống của mình bị xâm nhập có tới hơn 64% tổ chức mất 3 tháng liền (Trustwave Global Security Report), và con số 243 ngày cũng là số thời gian mà kẻ tấn công âm thầm hoạt động trên các hệ thống nạn nhân, mà các tổ chức không hề hay biết (Mandiant M-Trend Report) . Trong khi 46% thời gian để tấn công thỏa hiệp hệ thống diễn ra trong vài phút (Verizon Data Breach Report).Khi mà chúng ta đang cần một phương pháp để phản ứng nhanh với các sự cố, thì hiện tại những gì tôi quan sát được, phần lớn công việc ứng phó sự cố trong các tổ chức tại Việt Nam, vẫn đang bỏ ngõ. Nhiều tổ chức, công ty lớn trên thế giới, họ duy trì một đội phản ứng sự cố, sẵn sàng 24/7 để đối phó với các sự cố tiềm năng có thể xảy ra với đơn vị mình. Trong khi ở Việt Nam khi nhắc đến ứng phó sự cố đồng nghĩa với việc nhắc đến VNCERT hay CMC hay BKAV.
Tại sao các tổ chức không đầu tư nhiều hơn cho Incident Response? Để chúng ta có thể phát hiện và ứng phó nhanh các tấn công nhắm vào tổ chức mình. Trước khi trả lời câu hỏi này tôi muốn nói qua một chút về góc nhìn của kẻ xâm nhập, để mọi người thấy sự cần thiết của ứng phó sự cố, và nếu chúng ta làm tốt công việc này thì sẽ giảm thiểu rất nhiều thiệt hại cho tổ chức mình khi sự cố xảy ra. Ở đây có lẽ chúng ta đều biết những thỏa hiệp ban đầu chỉ cung cấp một bàn đạp để từ đó từng bước tấn công sâu hơn hệ thống. Các công việc trong thực tế của kẻ tấn công thường bắt đầu sau khi đã thiết lập được vị trí của mình trên hệ thống Victim. Từ việc tìm hiểu về môi trường, tiến hành lây lan, mở rộng phạm vi tiếp cận sang các hệ thống khác, leo thang đặc quyền trở thành người quản trị và đánh cắp dữ liệu. Đây là công việc mất nhiều thời gian mới có thể đạt được mục đích, đôi khi tính bằng ngày, tuần hoặc thậm chí cả tháng. Điển hình như vụ siêu thị bán lẻ Target bị tấn công bởi mã độc BlackPOS dẫn đến việc hơn 70 triệu thông tin tài khoản người dùng bị rò rỉ. Bằng cách sử dụng kỹ thuật “ RAM scarping” để phân tích bộ nhớ tiến trình trên thiết bị đầu cuối của hệ thống POS, trước khi dữ liệu được mã hóa. Điều này cho phép kẻ tấn công trích xuất dữ liệu từ bộ nhớ khi dữ liệu đang trong quá trình xử lý của thiết bị đầu cuối trước khi được truyền thông qua mạng. Không chỉ Target mà phần lớn các cuộc tấn công vào hệ thống POS đòi hỏi cần nhiều thời gian để thu thập dữ liệu, lúc này mã độc được sử dụng phải đảm bảo được việc cư trú thời gian dài trên thiết bị đầu cuối đã bị xâm nhập. Không giống như đánh cắp cơ sở dữ liệu khi hàng triệu bản ghi được truy cập, đánh cắp dữ liệu trên hệ thống POS đòi hỏi kẻ tấn công phải chờ đợi tới khi giao dịch diễn ra và thu thập dữ liệu theo thời gian thực, mỗi khi một thẻ tín dụng được sử dụng. Chính vì thế việc phát hiện ra sớm các dấu hiệu của việc hệ thống bị thỏa hiệp, và đáp trả một cách nhanh chóng, chính xác sẽ giúp các tổ chức giảm thiểu thiệt hại và các chi phí phục hồi. Các công việc cần làm tôi sẽ nói rõ hơn ở phần tiếp theo.
Quay lại vấn đề tại sao các tổ chức không đầu tư nhiều hơn cho Incident Response? Để chúng ta có thể phát hiện và ứng phó nhanh các tấn công nhắm vào tổ chức mình.Với câu hỏi trên, câu trả lời tôi nhận được ở nhiều tổ chức khá mơ hồ, kiểu như “Hệ thống của chúng tôi có gì đâu, ai tấn công làm gì” hay “Hệ thống của chúng tôi rất an toàn, được trang bị nhiều thiết bị bảo mật hiện đại nhất nên IR thấy chưa cần thiết”. Đây là những suy nghĩ đầy sai lầm. John chambers CEO của Cisco từng nói “There are two types of companies: those who have been hacked and those who don’t yet know they have been hacked.” Thế nên chúng ta nên bỏ suy nghĩ “nếu chúng ta bị tấn công” (có nghĩa là có hoặc không) mà hãy suy nghĩ là “khi nào thì điều đó diễn ra”. Lấy ví dụ về cuộc chiến sinh tồn nơi hoang dã, chúng ta thấy khi sư tử săn mồi thì những con ngựa yếu nhất và chậm nhất so với những con còn lại sẽ bị ăn thịt. Trong an toàn thông tin cũng thế, chừng nào mà hệ thống của chúng ta yếu hơn so với những tổ chức còn lại, thì chúng ta vẫn là mục tiêu ưa thích, việc tấn công đôi khi không nhằm vào dữ liệu hay tài sản mà chúng ta đang có, đơn giản công việc đó chỉ là một thú vui, hay sử dụng hệ thống tấn công làm nơi phát tán mã độc hoặc sử dụng những hệ thống đó để làm bàn đạp tấn công các hệ thống của những tổ chức khác.
Trong thực tế Pentest, Audit cho rất nhiều cơ quan, doanh nghiệp trong và ngoài nước, với hàng trăm ứng dụng, thiết bị, hệ thống chúng tôi đều phát hiện ra lỗi, tất cả những lỗ hổng ở đây không phải là zero-day, phần lớn thuộc top 10 OWASP, và các sai sót trong cấu hình các thiết bị, một số lỗi nghiêm trọng như shellshock, Jboss (CVE-2010-0738), Padding Oracle… vẫn chưa được khắc phục. Những thiết bị đình đám như F5, SourceFire hay của nhiều hãng nữa… sau khi được đưa vào triển khai thì vẫn giữ nguyên hiện trạng như ban đầu trước khi được bàn giao, hoặc được “tối ưu” không đáng kể, tất cả các cấu hình gần như được thiết lập là mặc định. Nhiều thiết bị dễ dàng đạt được quyền quản trị thông qua tấn công từ điển. Cho nên suy nghĩ rằng “hệ thống chúng tôi đã an toàn, vì chúng tôi có những thiết bị bảo mật tuyệt vời” cần được điều chỉnh. Cũng liên quan đến các thiết bị bảo mật. Cách đây hơn 2 năm, tôi có nhận được yêu cầu hỗ trợ từ một đơn vị nhà nước làm về truyền hình, viễn thông. Một trong rất nhiều website của tổ chức này bị tấn công thay đổi giao diện. Điều đáng nói ở đây khiến tôi vô cùng ngạc nhiên khi ngồi review lại toàn bộ hệ thống của khách hàng. Trong mô hình tổng thể tổ chức này được trang bị gần như đầy đủ các thiết bị bảo mật tiên tiến nhất đang có trên thị trường, từ F5, SourceFire, PaloAlto cho đến FireEye…Vậy câu hỏi đặt ra là vai trò của những thiết bị này ở đâu khi hệ thống của tổ chức này bị tấn công. Ở đây cụ thể tôi muốn nói đến thiết bị F5, câu trả lời cho điều này chỉ có một. Đó là thiết bị F5 được cài đặt với tất cả mọi thứ đều ở chế độ mặc định, các tính năng, tập luật (ngăn chặn sql injection, file upload, xss… đều không được tinh chỉnh) ngay cả username/password cũng được để mặc định. Chúng ta đều đồng ý rằng khi hệ thống được trang bị nhiều thiết bị thì sẽ an tâm hơn phần nào, nhưng khi mà bản thân các thiết bị đó không được đảm bảo an toàn, gặp nhiều sai sót trong cấu hình an ninh, thiết bị tồn tại lỗ hổng bảo mật dẫn đến bị thỏa hiệp thì lúc đó việc đầu tư nhiều vào thiết bị với việc không đầu tư đều có một kết quả như nhau là chúng ta đã không bảo vệ được tổ chức mình trước các cuộc tấn công từ không gian mạng.
Ngoài hai câu trả lời trên thì vấn đề tài chính và nhân lực cũng là một trong những thách thức lớn cho các tổ chức khi duy trì một đội ngũ để ứng phó sự cố 24/7. Tôi hiểu và chia sẻ với điều này, vấn đề này không thể giải quyết ngày một ngày hai, hơn nữa cũng phụ thuộc nhiều vào tiềm lực, hướng kinh doanh và nhiều vấn đề khác của tổ chức nữa.
Không có quy trình, công cụ và những kỹ sư lành nghề. Hiện tại nhiều tổ chức phát hiện ra các sự cố của mình thông qua hệ thống phần mềm diệt virus hay cảnh báo từ thiết bị IDS, tường lửa, và thường thì những cảnh báo ít được phân tích chuyên sâu, bởi vì họ không có một đội ngũ kỹ sư lành nghề để đáp ứng những yêu cầu đó. Thông thường các cảnh báo được đưa ra, nhưng không đánh giá hết được mức độ nghiêm trọng nếu như sự cố đó xảy ra. Chưa nói đến việc rất rất nhiều thiết bị như IDS và Firewall đang được cấu hình sai, cảnh báo nhầm, dẫn đến hạn chế trong việc phát hiện sự cố. Bên cạnh những thiết bị bảo mật, các tổ chức cũng phát hiện sự cố của mình thông qua các report của đội ngũ đánh giá bảo mật ở công ty ngoài, khi họ phát hiện có dấu hiệu xâm nhập vào tổ chức, hay những thông báo từ kẻ tấn công, hoặc người dùng cuối khi họ thấy mạng trong công ty bất thường. Nhiều đơn vị, thậm chí không phát hiện rằng hệ thống, thiết bị của mình đã và đang bị thỏa hiệp. Đặt câu hỏi, bạn sẽ là người thành công hay thất bại? Thì rõ ràng câu trả lời chúng ta muốn là thành công. Điều đó đồng nghĩa với việc đã đến lúc chúng ta đầu tư nhiều hơn cho Incident Response, chúng ta cần lựa chọn quy trình, phương pháp, công cụ kết hợp với những chuyên viên lành nghề để có thể xử lý, phản hồi nhanh các cuộc tấn công vào tổ chức mình.Để làm được điều đó, trước hết chúng ta cần một đội ngũ những kỹ sư lành nghề, có võ và một quy trình tốt để ứng phó sự cố. Quy trình này phải xuyên suốt từ việc Chuẩn bị cho đến tiến hành Phát hiện và phân tích, thực hiện các biện pháp ngăn chặn, loại bỏ, phục hồi cũng như những hoạt động cần thiết sau sự cố.
Trước hết là khâu chuẩn bị. Hầu hết các quy trình ứng phó sự cố thường nhấn mạnh vào công tác này. Công tác chuẩn bị tạo điều kiện thuận lợi cho các giai đoạn tiếp theo của quá trình ứng phó sự cố. Để qúa trình ứng phó được xuyên suốt cần có những hệ thống phục vụ cho việc thu thập và lưu trữ dữ liệu (Log Management, hệ thống live response từ xa) , những phần mềm chuyên dụng (Suricata, Grr, volatility, FTK, The sleuthkit, wireshark, IDA, Xplico,…) đội nào có tiền thì chơi sang xài Encase, X-ways Forensics, McAfee…) Ngoài ra thì cần chuẩn bị phương thức liên lạc và truyền thông (các kênh liện lạc của đội, số điện thoại, email..) nhằm đảm bảo cho hoạt động ứng phó sự cố được tiến thành xuyên suốt. À chú ý privacy, nên duy trì một kênh kết nối tốt, an toàn trong tổ chức cũng như với các đội bên ngoài, ở Việt Nam thì có thể thiết lập mối liên hệ với Vnsecurity (nơi tập trung nhiều chuyên gia giỏi, có trách nhiệm với cộng đồng, Vncert (trung tâm ứng cứu khẩn cấp sự cố máy tính) CMC InfoSec, và một số hiệp khách võ công thâm hậu khác không thuộc những tổ chức trên,… Việc chuẩn bị cần đảm bảo đầy đủ các công cụ và thiết bị cần thiết để đội ứng phó sự cố có thể thực hiện các công việc từ sao lưu dữ liệu, thu thập thông tin (thu thập bộ nhớ ram, clone đĩa cứng..), cho đến phân tích dữ liệu và kênh kết nối để thực hiện leo thang thông tin khi có trường hợp khẩn cấp.
Sau khi hoàn tất việc chuẩn bị, những kỹ sư lành nghề cần trang bị cho mình những bí kíp, chiêu thức để phát hiện và phân tích (phân tích dữ liệu mạng, bản ghi sự kiện, bộ nhớ RAM, khôi phục dữ liệu bị xóa, trích xuất và phân tích mã độc…). Đây là giai đoạn khó khăn nhất trong quá trình ứng phó sự cố. Để phát hiện chính xác và đánh giá xem sự cố đã xảy ra hay chưa, cần lưu ý rằng sự cố có thể được phát hiện thông qua nhiều công cụ khác nhau, các mức độ và tính trung thực cũng khác nhau. Việc phát hiện sự cố phụ thuộc vào kiến thức kỹ thuật, kinh nghiệm trong việc phân tích các dữ liệu liên quan đến sự cố. Chúng ta cần xác định rõ đâu là dấu hiệu hiện hữu, đâu là dấu hiệu tiềm năng. Ví dụ như log của máy chủ web ghi nhận được các bản ghi của các công cụ dò quét lỗ hổng bảo mật (Acunetix, nikto, sqlmap, w3af…) hay một lời tuyên bố sẽ tấn công nhằm vào các máy chủ, ứng dụng của tổ chức thì nó được xem là dấu hiệu tiềm năng. Trong khi đó, dấu hiệu hiện hữu là những dấu hiệu cho thấy sự cố đã hoặc đang xảy ra. Nếu một dấu hiệu tiềm năng được phát hiện, tổ chức có thể thực hiện ngăn chặn sự cố này trước khi sự cố này xảy ra. Trong khi các dấu hiệu tiềm năng là khá ít thì các dấu hiệu hiện hữu thì lại rất phổ biến. Ví dụ như các thiết bị phát hiện xâm nhập cảnh báo kẻ tấn công đang khai thác lỗi tràn bộ đệm, phần mềm chống mã độc hại cảnh báo một máy chủ bị nhiễm phần mềm độc hại, một quản trị viên nhìn thấy một tệp tin khác thường trên máy chủ hay máy chủ ghi lại sự thay đổi cấu hình.
Việc phân tích sự cố sẽ dễ dàng hơn nếu các dấu hiệu được đảm bảo là chính xác. Tuy nhiên các dấu hiệu không phải lúc nào cũng đúng. Ví dụ như các hệ thống phát hiện xâm nhập có thể đưa ra những cảnh báo sai. Hoặc tệ hơn, hệ thống phát hiện xâm nhập đưa ra quá nhiều cảnh báo làm cho việc phân tích trở nên vô cùng khó khăn.Đội ứng phó sự cố nên phân tích một cách nhanh chóng và xác định xem sự cố đã thật sự xảy ra hay chưa. Khi đã xác định một sự cố đã thật sự xảy ra, nhóm nghiên cứu bắt đầu thực hiện các bước phân tích ban đầu đề xác định phạm vi của sự việc. Ví dụ như vùng mạng, máy chủ bị ảnh hưởng, nguồn gốc của vụ việc, làm thế nào để sự việc xảy ra. Những phân tích ban đầu sẽ cung cấp thông tin cho các hoạt động phân tích sâu tiếp theo.
Xác định mức độ ưu tiên cho các sự kiện cũng là một vấn đề quan trọng. Các sự cố không nên được xử lý theo thứ tự thời gian phát hiện. Thay vào đó, việc xử lý các sự cố cần được ưu tiên dựa vào các yếu tố như mức độ ảnh hưởng đến hoạt động của hệ thống, ảnh hưởng về mặt thông tin đến hoạt động bình thường của tổ chức và các tổ chức khác nếu như sự cố ảnh hưởng đến các dữ liệu gắn liền với tổ chức đó, ảnh hưởng đến chi phí khôi phục, thời gian và nguồn lực của tổ chức trong đó chưa kể đến một số trường hợp các sự cố xảy ra không thể phục hồi.
Sau khi phát hiện và phân tích sự cố đang diễn ra đối với tổ chức mình, những kỹ sư lành nghề sẽ tiền hành các biện pháp nghiệp vụ để ngăn chặn, loại bỏ và phục hồi. Ở giai đoạn này chúng ta nên biết, đối với các loại sự cố khác nhau thì chiến lược ngăn chặn cũng khác nhau. Ví dụ chiến lược ngăn chặn đối với sự cố lây nhiễm phần mềm độc hại, sẽ khác so với chiến lược ngăn chặn sự cố tấn công từ chối dịch vụ. Các tổ chức nên tạo ra các chiến lược ngắn hạn riêng biệt cho từng loại sự cố lớn, có các tài liệu chuẩn, nội dung chiến lược rõ ràng để tạo điều kiện thuận lợi cho việc đưa ra quyết định.Sau khi sự cố đã được ngăn chặn, việc loại bỏ các thành phần của sự cố ra khỏi hệ thống là cần thiết. Ví dụ như sự cố về lây lan mã độc hại. Trong quá trình clean, điều quan trọng là xác định tất cả các ảnh hưởng đối với tổ chức để có kế hoạch xử lý.
Trong quá trình phục hồi, các quản trị viên hệ thống khôi phục lại hoạt động bình thường của hệ thống và xác nhận rằng hệ thống đang hoạt động bình thường. Quá trình phục hồi có liên quan đến các hành động như khôi phục lại từ các bản sao lưu hệ thống sạch, xây dựng lại hệ thống từ đầu, thay thế tệp tin bị thỏa hiệp, cài đặt các bản vá lỗi, thay đổi mật khẩu, thắt chặt các chính sách an toàn thông tin. Việc loại bỏ và phục hồi nên được thực hiện theo từng giai đoạn. Đối với các sự cố có quy mô lớn, việc phục hồi có thể mất rất nhiều thời gian, vì vậy việc chia giai đoạn đảm bảo trong giai đoạn đầu tiên, các cơ chế an ninh tổng thể được tăng cường để ngăn chặn các sự cố tương tự trong tương lai. Giai đoạn sau nên tập trung vào những thay đổi dài hạn (ví dụ như những thay đổi về có sở hạ tầng…).
Công việc cuối cùng của quy trình ứng phó sự cố là hoạt động sau sự cố. Đây là một phần quan trọng trong quá trình xử lý sự cố, nhằm việc rút ra các bài học kinh nghiệm về cuộc ứng phó sự cố. Sau khi sự cố đã xảy ra, chúng ta cần phải giải quyết được các câu hỏi như: Chính xác điều gì đã xảy ra? vào thời gian nào? Nhân viên và các quản lý thực hiện giải quyết vụ việc có tốt không? Những điều gì mà nhân viên và các quản lý nên làm khi có sự cố xảy ra? Làm thế nào để chia sẻ thông tin với các tổ chức khác? Các hành động để ngăn chặn sự cố tương tự trong tương lai là gì? Các dấu hiệu về sự cố tương tự là gì? Những công cụ hay nguồn lực nào cần thiết để giải quyết nhanh sự cố trong tương lai?Tổ chức nên thực hiện các buổi nói chuyện giữa các bên liên quan và rút ra các bài học kinh nghiệm cần thiết để đảm bảo sự cố tương tự sẽ không xảy ra. Buổi nói chuyện như thế này sẽ chỉ ra được cách thức phối hợp giữa các bên liên quan khi có sự cố xảy ra.
Tác giả: LÊ CÔNG PHÚ
English