incident response

36
Phụ lục A - Các khuyến cáo. Phụ lục A trình bày liệt kê các khuyến cáo chính trong phần 2 đến 8 của tài liệu này. Nhóm đầu tiên của khuyến cáo áp dụng đối với tổ chức một khả năng ứng phó sự cố. Các khuyến cáo còn đã được nhóm lại theo các chu kì của vòng đời của ứng phó sự cố: chuẩn bị, phát hiện và phân tích, ngăn chặn, xoá bỏ và phục hồi, và các hoạt động sau sự cố. Mỗi nhóm có khuyến cáo chung cho giai đoạn ứng phó sự cố và những khuyến cáo áp dụng để xử lý các loại cụ thể của sự cố (ví dụ, từ chối dịch vụ DoS) trong giai đoạn. A.1 Tổ chức một khả năng ứng phó sự cố máy tính Thiết lập một khả năng ứng phó sự cố chính thức. Tổ chức cần chuẩn bị ứng phó nhanh chóng và hiệu quả khi bảo vệ an ninh máy tính bị vi phạm. Đạo luật quản lý bảo mật thông tin liên bang (FISMA) yêu cầu các cơ quan liên bang thiết lập khả năng ứng phó sự cố. A.1.1 Chính sách ứng phó sự cố và thủ tục chuẩn bị Tạo một chính sách ứng phó sự cố và sử dụng nó như là cơ sở cho các thủ tục ứng phó sự cố. Chính sách ứng phó sự cố là nền tảng của các chương trình ứng phó sự cố. Nó định nghĩa các sự kiện được coi là sự cố, thiết lập cơ cấu tổ chức cho ứng phó sự cố, xác định vai trò và trách nhiệm, và liệt kê các yêu cầu cho báo cáo sự cố, trong các mục khác. Thiết lập chính sách và thủ tục về việc chia sẻ thông tin liên quan đến sự cố. Tổ chức sẽ muốn hoặc được yêu cầu giao chi tiết về sự cố với bên ngoài, như các phương tiện truyền thông, các cơ quan thực thi pháp luật và các tổ chức báo cáo sự cố. Đội xử lý sự cố nên thảo luận độ dài yêu cầu với nhân viên đối ngoại, luật sư, và quản lý để thiết lập các chính sách và thủ tục về thông tin được chia sẻ. Nhóm cũng phải tuân thủ chính sách hiện hành của tổ chức về tương tác với giới truyền thông và các bên khác. Cung cấp thông tin cần thiết về sự cố để phù hợp tổ chức báo cáo sự cố. Cơ quan dân sự liên bang được yêu cầu phải phải báo sự cố cho Trung Tâm Ứng Phó Sự Cố Máy Tính Liên Bang (FedCIRC). Báo cáo có lợi cho các cơ quan vì tổ chức báo cáo sự cố sử dụng số liệu báo cáo cung cấp thông tin cho các cơ quan về mối đe doạ mới và xu hướng sự cố. A.1.2 Cơ cấu đội ứng phó sự cố và dịch vụ Xem xét các yếu tố liên quan khi lựa chọn một mô hình đội ứng phó sự cố thích hợp. Các tổ chức nên cân nhắc kĩ những ưu điểm và nhược điểm của mỗi mô hình của đội và mô hình nhân viên trong nhu cầu của tổ chức và tài nguyên sẵn có. Chọn những người có kỹ năng thích hợp cho đội ứng phó sự cố. Độ tin cậy và trình độ của đội phụ thuộc phần lớn và kỹ năng kỹ thuật của các thành viên. Đánh giá kỹ thuật kém có thể làm suy yếu sự tín nhiệm của đội và làm các sự cố xấu đi. Kỹ năng kĩ thuật quan trong bao gồm quản trị hệ thống, quản trị mạng, lập trình, hỗ trợ kĩ thuật và phát hiện xâm nhập. Kỹ năng làm việc theo nhóm và giao tiếp cũng cần thiết để xử

Upload: thund

Post on 09-Jul-2016

220 views

Category:

Documents


6 download

DESCRIPTION

Incident Response

TRANSCRIPT

Page 1: Incident Response

Phụ lục A - Các khuyến cáo.Phụ lục A trình bày liệt kê các khuyến cáo chính trong phần 2 đến 8 của tài liệu này. Nhóm đầu tiên của khuyến cáo áp dụng đối với tổ chức một khả năng ứng phó sự cố. Các khuyến cáo còn đã được nhóm lại theo các chu kì của vòng đời của ứng phó sự cố: chuẩn bị, phát hiện và phân tích, ngăn chặn, xoá bỏ và phục hồi, và các hoạt động sau sự cố. Mỗi nhóm có khuyến cáo chung cho giai đoạn ứng phó sự cố và những khuyến cáo áp dụng để xử lý các loại cụ thể của sự cố (ví dụ, từ chối dịch vụ DoS) trong giai đoạn.A.1 Tổ chức một khả năng ứng phó sự cố máy tính

Thiết lập một khả năng ứng phó sự cố chính thức. Tổ chức cần chuẩn bị ứng phó nhanh chóng và hiệu quả khi bảo vệ an ninh máy tính bị vi phạm. Đạo luật quản lý bảo mật thông tin liên bang (FISMA) yêu cầu các cơ quan liên bang thiết lập khả năng ứng phó sự cố.

A.1.1Chính sách ứng phó sự cố và thủ tục chuẩn bị

Tạo một chính sách ứng phó sự cố và sử dụng nó như là cơ sở cho các thủ tục ứng phó sự cố. Chính sách ứng phó sự cố là nền tảng của các chương trình ứng phó sự cố. Nó định nghĩa các sự kiện được coi là sự cố, thiết lập cơ cấu tổ chức cho ứng phó sự cố, xác định vai trò và trách nhiệm, và liệt kê các yêu cầu cho báo cáo sự cố, trong các mục khác.

Thiết lập chính sách và thủ tục về việc chia sẻ thông tin liên quan đến sự cố. Tổ chức sẽ muốn hoặc được yêu cầu giao chi tiết về sự cố với bên ngoài, như các phương tiện truyền thông, các cơ quan thực thi pháp luật và các tổ chức báo cáo sự cố. Đội xử lý sự cố nên thảo luận độ dài yêu cầu với nhân viên đối ngoại, luật sư, và quản lý để thiết lập các chính sách và thủ tục về thông tin được chia sẻ. Nhóm cũng phải tuân thủ chính sách hiện hành của tổ chức về tương tác với giới truyền thông và các bên khác.

Cung cấp thông tin cần thiết về sự cố để phù hợp tổ chức báo cáo sự cố. Cơ quan dân sự liên bang được yêu cầu phải phải báo sự cố cho Trung Tâm Ứng Phó Sự Cố Máy Tính Liên Bang (FedCIRC). Báo cáo có lợi cho các cơ quan vì tổ chức báo cáo sự cố sử dụng số liệu báo cáo cung cấp thông tin cho các cơ quan về mối đe doạ mới và xu hướng sự cố.

A.1.2 Cơ cấu đội ứng phó sự cố và dịch vụ Xem xét các yếu tố liên quan khi lựa chọn một mô hình đội ứng phó sự cố thích hợp. Các tổ chức nên

cân nhắc kĩ những ưu điểm và nhược điểm của mỗi mô hình của đội và mô hình nhân viên trong nhu cầu của tổ chức và tài nguyên sẵn có.

Chọn những người có kỹ năng thích hợp cho đội ứng phó sự cố. Độ tin cậy và trình độ của đội phụ thuộc phần lớn và kỹ năng kỹ thuật của các thành viên. Đánh giá kỹ thuật kém có thể làm suy yếu sự tín nhiệm của đội và làm các sự cố xấu đi. Kỹ năng kĩ thuật quan trong bao gồm quản trị hệ thống, quản trị mạng, lập trình, hỗ trợ kĩ thuật và phát hiện xâm nhập. Kỹ năng làm việc theo nhóm và giao tiếp cũng cần thiết để xử lý sự cố hiệu quả.

Xác định các nhóm khác trong tổ cũng có thể cần tham gia vào xử lý sự cố. Mỗi đội ứng phó sự cố dựa vào chuyên môn và đánh giá của các đội khác, bao gồm quản lý, an ninh thông tin, hỗ trợ công nghệ thông tin (IT), pháp lý, đối ngoại, và quản lý cơ sở vật chất.

Xác định dịch mà của đội nên cung cấp. Mặc dù trọng tâm của đội là ứng phó sự cố, hầu hết các đội đều thực hiện chức năng bổ xung. Ví dụ như phân phối các khuyến cáo an ninh, thực hiện đánh giá lỗ hổng, giáo dục người dùng về an ninh, và giám sát các cảm ứng phát hiện xâm nhập.

A.2 Chuẩn bị Có được các công cụ và tài nguyên có thể có giá trị trong thời gian xử lý sự cố. Nhóm sẽ hiệu quả hơn

khi xử lý sự cố nếu có sẵn các công cụ và tài nguyên khác nhau cho họ. Ví dụ bao gồm danh bạ, phần mềm mã hoá, sơ đồ mạng, thiết bị sao lưu, phần mềm điều tra máy tính, danh sách cổng, và các bản vá lỗi bảo mật.

Phòng ngừa sự cố xảy ra bằng cách đảm bảo rằng các mạng, hệ thống và các ứng dụng là đủ an toàn. Ngăn ngừa sự cố có lợi cho tổ chức và làm giảm khối lượng công việc của đội ứng phó sự cố. Thực hiện đánh giá rủi ro định kỳ và giảm những rủi ro được xác định ở mức chấp nhận được có hiệu quả trong việc giảm số lượng các sự cố. Người sử dụng, nhân viên IT, và quản lý nhận thức của chính sách và thủ tục an ninh cũng rất quan trọng.

A.2.1 Sự cố từ chối dịch vụ Cấu hình các quy tắc của tường lửa để ngăn ngừa tấn công phản xạ. Hầu hết các cuộc tấn công phản xạ

có thể được dừng thông qua các quy tắc tường lửa dựa trên mạng và máy chủ từ chối những đáng ngờ

Page 2: Incident Response

kết hợp của cổng đích và nguồn. Cấu hình các bộ định tuyến biên giới để ngăn chặn các cuộc tấn công khuếch đại. Các cuộc tấn công

khuếch đại có thể bị chặn bằng cách cấu hình bộ định tuyến biên giới không chuyển tiếp các phát sóng chỉ dẫn.

Xác định các nhà cung cấp dịch vụ Internet (ISP) và các nhà cung cấp thứ cấp có thể hỗ trợ xử lý các cuộc tấn công DOS dựa trên mạng. ISP có thể lọc hoặc hạn chế một số loại của giao thông, làm chậm và hoặc chặn đứng một cuộc tấn công DOS. Họ cũng có thể cung cấp nhật kí lưu lượng DOS và có thể hỗ trợ trong việc truy tìm nguồn gốc của cuộc tấn công. Tổ chức phải đáp ứng các ISP trước để thiết lập thủ tục cho yêu cầu như hỗ trợ.

Cấu hình phần mềm bảo mật để phát hiện các cuộc tấn công DOS. Phần mềm phát hiện xâm nhập (IDS) có thể phát hiện nhiều loại của hoạt động DOS. Thiết lập mạng và đường cơ sở hệ thống hoạt động, và giám sát nhưng sai lệch từ những đường cơ sở, cũng có thể hữu ích trong việc phát hiện các cuộc tấn công.

Cấu hình các vành đai mạng để từ chối tất cả giao thống đến và đi không được cho phép rõ ràng. Bằng cách hạn chế các loại giao thông có thể truy cấp hoặc rời khỏi môi trường, tổ chức sẽ hạn chế các phương pháp mà kẻ tấn công có thể sử dụng để thực hiện tấn công DOS.

A.2.2 Sự cố mã độc hại Làm cho người dùng biết về các vấn đề của mã độc. Người sử dụng nên quen thuộc với các phương

pháp mã độc sử dụng để lan truyền và những biểu hiện của nhiễm độc. Tổ chức các buổi giáo dục người dùng thường xuyên giúp đảm bảo rằng người dùng nhận thức được những rủi ro mà mã độc gây ra. Dạy người dùng cách xử lý an toàn các file đính kèm email để giảm số lượng nhiễm độc xảy ra.

Đọc các bản tin chống virus. Bản tin liên quan đến các mỗi đe doạ mã độc mới cung cấp thông tin kịp thời để xử lý sự cố.

Triển khai các hệ thống phát hiện xâm nhập dựa trên máy chủ, bao gồm kiểm tra tính toàn vẹn của tập tin, quan trọng cho máy chủ. phần mềm IDS dựa trên máy chủ, đặc biệt là kiểm tra tính toàn vẹn của tập tin, có thể phát hiện dấu hiệu của sự cố mã độc hại, chẳn hạn như thay đổi và sửa đổi cấu hình để thực thi.

Sử dụng phần mềm chống virus và giữu cho nó được cập nhật với chữ kí virus mới nhất. Phần mềm chống virus nên được triển khai đến tất cả các máy và tất cả các ứng dụng có thể được sử dụng để chuyển mã độc hại. Phần mềm nên được cấu hình để phát hiện và khử trùng hoặc cách ly mã độc hại. Tất cả các phần mềm chống virus khác cần được lưu giữ chữ kí virus mới nhất để các mối đe doạ mới nhất có thể được phát hiện.

Cấu hình phần mềm để khoá các tập tin khả nghi. Tập tin rất có thể là độc hại nên được cấm khỏi môi trường, chẳng hạn như những phần mở rộng của tập tin mà thường kết hợp với mã độc hại và tập tin với sự kết hợp khả nghi của các phần mở rộng tập tin.

Loại bỏ mở chia sẻ trên Windows. Nhiều sâu có thể lây lan qua các chia sẻ không có bảo mật trên các máy chạy Windows. Một máy nhiễm độc duy nhất có thể nhanh chóng lây lan sang hàng trăm hoặc hàng ngàn máy thông qua các chia sẻ không an toàn.

A.2.3 Sự cố truy cập trái phép Cấu hình phần mềm phát hiện xâm nhập để cảnh báo những nỗ lực truy cập trái phép. Phần mềm phát

hiện xâm nhập dựa trên máy chủ và mạng (bao gồm phần mềm kiểm tra toàn vẹn tập tin) rất có giá trị cho phát hiện các nỗ lực truy cập trái phép. Mỗi một loại phần mềm có thể phát hiện sự cố mà các loại phần mềm khác thì không, vì vậy việc sử dụng nhiều loại phần mềm bảo mật máy tính được khuyến khích cao.

Cấu hình tất cả các máy sử dụng nhật kí tập trung. Sự cố dễ dàng được phát hiện nếu dữ liệu từ tất cả các máy trên toàn tổ chức được lưu trữ tập trung tại một vị trí an toàn.

Thiết lập các thủ tục để tất cả người dùng thay đổi mật khẩu của họ. Một quy định về mật khẩu có thể được tổ chức sử dụng để yêu cầu tất cả người dùng của một ứng dụng, hệ thống, hoặc miền, hoặc có lẽ với toàn bộ tổ chức để thay đổi mật khẩu của họ.

Cấu hình các vành đai mạng từ chối tất cả các truy cập không được phép. Bằng cách hạn chế các giao thông đến, kẻ tấn công có để đạt được ít mục tiêu hơn và sẽ có thể tiếp cận được các mục tiêu sử dụng chỉ các giao thức chỉ định. Điều này làm giảm số lượng các sự cố truy cập trái phép.

Đảm bảo an toàn tất cả các phương pháp truy cập từ xa, bao gồm modem và mạng riêng ảo (VPN).

Page 3: Incident Response

Modem không an toàn có thể dễ dàng cung cấp truy cấp trái phép tới hệ thống nội bộ và mạng. Khách truy cập từ xa thường nằm ngoài tầm kiểm soát của tổ chức, do đó cấp quyền truy cập vào tài nguyên sẽ làm tăng nguy cơ.

Đặt tất cả các dịch vụ truy cập công khai trên vùng bảo đảm .. (DMZ) phân đoạn mạng. Hành động này cho phép các tổ chức cho phép máy chủ bên ngoài bắt đầu kết nối tới máy chỉ chỉ trên phân đoạn DMZ, không thể với các máy chủ trên các phân đoạn mạng nội bộ. Điều này sẽ giảm số lượng các sự cố truy cập trái phép.

Vô hiệu khoá tất cả các dịch vụ không cần thiết trên máy chủ và phân cách các dịch vụ quan trọng khác. Mỗi một dịch vụ đang chạy đưa ra một cơ hội tiềm năng khác cho thoả hiệp. Tách các dịch vụ quan trọng là quan trọng vì nếu một kẻ tấn công thoả hiệp với một máy chủ mà chạy một dịch vụ quan trọng, ngay lập tức truy cập nên chỉ đạt được với một dịch vụ.

Sử dụng phần mềm tường lửa trên máy chủ để hạn chế tiếp xúc với các máy cá nhân để tấn công. Triển khau phần mềm tường lửa trên máy chủ đến các máy cá nhân và cấu hình nó để từ chới tất cả các hoạt động không cho phép sẽ tiếp tục làm giảm khả năng của sự cố truy cập trái phép.

Tạo và thực thi một chính sách mật khẩu. Chính sách mật khẩu nên yêu cầu sử dụng mật khẩu phức tạp, khó đoán và phải đảm bảo rằng phương pháp xác thực là đủ mạnh để truy cập tài nguyên quan trọng. Mật khẩu mặc định và yếu là có khả năng bị đoán hoặc bẻ gãy, dẫn dến truy nhập trái phép.

A.2.4 Sự cố việc sử dụng không phù hợp Thảo luận về việc sử lý việc sử dụng không phù hợp với tài nguyên con người của tổ chức và ban pháp

chế. Quá trình theo dõi và ghi nhật kí hoạt động ngừoi dùng nên tuân thủ chính sách của tổ chức và tất cả các luật áp dụng. Thủ tục sử lý sự cố trực tiếp liên quan đến người lao động nên kết hợp thận trọng và bảo mật.

Thảo luận về các vấn đề trách nhiệm pháp lý với các cơ quan pháp lý của tổ chức. Vấn đề trách nhiệm có thể phát sinh trong quá trình các sự cố cách sử dụng không phù hợp, đặc biệt là các sự cố mà mục tiêu ở bên ngoài. Sử lý sự cố nên hiểu là khi họ thảo luận về sự cố với bên bị cáo buộc tấn công những thông tin họ tiết lộ.

Cấu hình phần mềm phát hiện xâm nhập dựa trên mạng để phát hiện một số loại …. Phần mềm phát hiện xâm nhập đã được xây dựng khả năng phát hiện một số sự cố...., chẳng hạn như việc sử dụng các dịch vụ trái phép, hoạt động gián điệp ra bên ngoài và các cuộc tấn công, và sử dụng không đúng chuyển tiếp mail (ví dụ như gửi thư rác).

Ghi nhật kí thông tin cơ bản về hoạt động của người dùng. Thông tin cơ bản về hoạt động của người dùng như lệnh giao thức chuyển file (FTP), yêu câu web, và các tiêu đề email có thể có giá trị cho mục đích điều tra và tìm chứng cớ.

Cấu hình tất cả máy chủ mail để họ không thể sử dụng chuyển tiếp email trái phép. Chuyển tiếp Email thương được sử dụng để gửi thư rác.

Thực hiện các phần mềm lọc thư rác trên tất cả máy chủ mail. Phần mềm lọc thư rác có thể chặn phần lớn các thư rác được gửi từ bên ngoài tới người dùng của tổ chức và thư rác được gửi bởi người dùng nội bộ.

Thực hiện phần mềm lọc đồng nhất vị trí tài nguyên (URL). Phần mềm lọc URL ngăn chặn truy cập vào nhiều trang web không phù hợp. Ngừoi sử dụng nên được yêu cầu sử dụng phần mềm, thường là ngăn chặn truy cập vào trang wweb bên ngoài trừ khi giao thông đi qua một máy chủ có thực hiện lọc URL.

A.2.5 Sự cố nhiều phần Sử dụng nhật ký tập trung và phần mềm xem xét sự tương đồng giữa các sự kiện. Xử lý sự cố cần xác

định một sự cố có nhiều phần một cách nhanh chóng hơn nếu tất cả tiền thân và chỉ ra là từ một điểm nhìn duy nhất.

A.3 Phát hiện và phân tích Xác định tiền thân và chỉ dẫn thông qua các cảnh báo được tạo ra bởi mộ số loại phần mềm bảo mật máy

tính. Hệ thống phát hiện xâm nhập dựa trên mạng và máy chủ, phần mềm chống virus, phầm mềm kiểm tra tính toàn vẹn của tập tin có giá trị cho việc phát hiện dấu hiệu của sự cố. Mỗi loại phần mềm có thể phát hiện sự cố mà một số loại khác không thể, vì vậy việc sử dụng vài loại phần mềm bảo mật máy tính là rất khuyến khích. Dịch vụ giám sát của bên thứ ba cũng có thể hữu ích.

Thiết lập cơ chế cho các đối tác bên ngoài để báo cáo sự cố. Các bên ở bên ngoài có thể muốn báo cáo sự cố cho tổ chức; ví dụ, họ tin rằng một trong số những người dùng của tổ chức tấn công họ. Tổ chức

Page 4: Incident Response

nên công bố số điện thoại và địa chỉ email để các bên ở bên ngoài có thể sử dụng để báo cáo những sự cố như vậy.

Yêu cầu một mức độ cơ bản của ghi nhật kí và kiểm toán trên tất cả các hệ thống, và một mức độ cơ bản cao hơn trên tất cả các hệ thống quan trọng. Các bản ghi từ các hệ điều hành, dịch vụ và ứng dụng thường xuyên cung cấp giá trị trong phân tích sự cố, đặc biệt là nếu kiểm toán được kích hoạt. Các bạn ghi có thể cung cấp thông tin như tài khoản đã truy cập và hành đông đã được thực hiện.

Hồ sơ mạng và hệ thống. Biện pháp lập hồ sơ đặc điểm của mức độ hoạt động dự kiến để những thay đổi trong mô hình có thể dễ dàng xác định hơn. Nếu quá trình lập hồ sơ là tự động, sai lệch so với mức độ hoạt động dự kiến có thể được phát hiện và báo cáo quản trị viên nhanh chóng, dẫn dến phát hiện nhanh các sự cố và các vấn đề hoạt động.

Hiểu biết về các hành vi bình thường của mạng, hệ thống và ứng dụng. Thành viên nhóm hiểu những gì là hành vi bình thường nên có thể nhận ra hành vi bất thường dễ dàng hơn. Kiến thức này tốt nhất có thể đạt được bằng cách xem lại các bản ghi và cảnh báo bảo mật; các xử lý trở nên quen thuộc với các dữ liệu điển hình và có thể điều tra các mục bất thường để đạt được nhiều hơn nữa.

Sử dụng lưu trữ nhật kí tập trung và tạo các chính sách duy trì nhật kí. Thông tin liên quan đến một sự cố có thể được ghi lại ở nhiều nơi. Các tổ chức nên triển khai máy chủ lưu trữ nhật kí tập trung và cấu hình thiết bị để gửi bản sao nhật kí của họ đến máy chủ tập trung. Các lợi ích nhóm vì nó có thể truy cập tất cả các mục đăng nhập cùng một lúc, cũng có thể việc thay đổi các bản ghi trên máy cá nhân sẽ không ảnh hưởng dến dữ liệu đã được gửi đến các máy chủ tập trung. Một chính sách duy trì nhật kí là quan trọng vì nhưng nhật kí cũ có thể chỉ ra các hành động tương tự hoặc có liên quan.

Thực hiện các sự kiện liên quan. Dấu hiệu của một sự cố có thể được chụp ở một số bản ghi. Các sự kiện tương ứng trong nhiều nguồn có thể là vô giá trong việc thu thập tất cả các thông tin có sẵn cho một sự cố và xác nhận sự việc đã xảy ra. Nhật kí tập trung tạo các sự kiện tương quan dễ dàng hơn và nhanh hơn.

Giữ tất cả đồng hồ của máy chủ được đồng bộ. Nếu thiết bị báo cáo sự kiến có các cài đặt đồng hồ không phù hợp, Các sự kiện tương quan sẽ trở nên khó hơn. Sự khác biệt đồng hồ cũng có thể gây một số vấn đề từ góc độ chứng cứ.

Duy trì và biết sử dụng một cơ sở thông tin tri thức. Người xử lý cần phải tham khảo thông tin một cách nhanh chóng trong quá trình phân tích sự cố; một cơ sở thông tin tập trung cung cấp một thông tin nhất quán. Kiến thức cơ bản nên bao gồm các thông tin chung, chẳng hạn như số cổng thường sử dụng và đường dẫn đến thông tin các virus, và dữ liệu trên dấu hiệu và điềm báo cho thấy trước sự cố.

Tạo ra một ma trận chẩn đoán cho nhân viên có ít kinh nghiệm. Nhân viên trợ giúp, quản trị hệ thống và các thành viên ứng phó sự cố có thể cần hỗ trợ trong việc xác định loại sự cố có thể xảy ra. Một ma trận chẩn đoán liệt kê các loại sự cố và các triệu chứng liên quan tới từng loại sự cố có thể cung cấp chỉ dẫn như loại sự cố nào đang xảy ra và làm thế nào có thể xác nhận sự cố.

Bắt đầu ghi tất cả thông tin ngay sau khi nhóm nghiên cứu nghi ngờ rằng một sự cố đã xảy ra. Thực hiện từng bước, từ khi vụ việc được phát hiện với phân giải cuối cùng của nó, nên được ghi chép và đánh dấu thời gian. Tính chất của thông tin này như là bằng chứng tại toà án pháp luật nếu theo đuổi truy tố vụ việc. Ghi các bước thực hiện cũng có thể chỉ dẫn hiệu quả và có hệ thống, và ít vấn đề xử lý bị lỗi.

Bảo vệ dữ liệu về sự cố. Nó thường chứa thông tin nhạy cảm liên quan đến các yếu tố như điểm yếu, lỗ hổng bảo mật và người sử dụng có thể thực hiện các hành vi không phù hợp. Nhóm cần phải đảm bảo rằng quyền truy cập vào dữ liệu của sự cố bị hạn chế đúng cách, cả logic và vật lý.

Ưu tiên sự cố do tác động kinh doanh trên cơ sở quan trọng của các tài nguyên bị ảnh hưởng và tác động về kĩ thuật của vu việc. Do hạn chế nguồn lực, sự cố không phải được xử lý trước, hay phục vụ trước. Thay vào đó, các tổ chức cần thiết lập các hướng dẫn bằng văn bản cách nhanh nhất mà các nhóm phải ứng phó với sự cố, và những hành động cần được thực hiện, dựa trên sự cố hiện tại và tác động đến tiềm năng kinh doanh. Những hướng dẫn này tiết kiệm thời gian cho xử lý sự cố và cung cấp một sự biện minh cho quản lý và chủ hệ thống cho hành động của họ. Tổ chức cũng nên thiết lập quy trình leo thang đối với những trường hợp khi nhóm nghiên cứ không ứng phó được với sự cố trong thời gian chỉ định.

Bao gồm các quy định về báo cáo sự cố trong chính sách ứng phó sự cố của tổ chức. Tổ chức nên xác định những sự cố phải báo cáo, khi nào họ phải báo cáo, báo cáo cho ai. Các bên thường được thông báo là giám đốc thông tin (CIO), người đứng đầu an toàn thông tin, nhân viên an toàn thông tin nội bộ, các đội ứng phó sự cố khác trong tổ chức và chủ sở hữu hệ thống.

Page 5: Incident Response

A.4 Ngăn chặn, xoá bỏ và phục hồi Thiết lập chiến lược và thủ tục khi có sự cố. Nó là quan trọng để ứng phó sự cố nhanh chóng và hiệu quả

để hạn chế tác động đến kinh doanh của họ. Tổ chức nên xác định những rủi ro chấp nhận được trong ngăn sự cố và phát triển các chiến lược và quy trình phù hợp. Chiến lược ngăn chặn nên thay đổi dựa trên loại sự cố.

Làm theo các thủ tục thành lập để thu thập bằng chứng và xử lý. Đội nên ghi chép rõ rằng tất cả cách bằng chứng đã được bảo tồn. Bằng chứng nên được hạch toán cho tất cả thời gian. Đội phải gặp các nhân viên pháp lý và cơ quan thực thi pháp luật để thảo luận về xử lý bằng chứng, sau đó xây dựng quy trình dựa trên các cuộc thảo luận.

Bắt các dữ liệu dễ mất từ hệ thống làm bằng chứng. Nỗ lực này bao gồm danh sách các kết nối mạng, các tiến trình, phiên đăng nhập, tập tin đã mở, cấu hình giao diện mạng, và nội dung của bộ nhớ. Chạy cẩn thận lệnh lựa chọn từ các phương tiện đang tin chậy có thể thu thập các thông tin cần thiết mà không làm hỏng bằng chứng của hệ thống.

Có được ảnh chụp hệ thống thông qua đầy đủ ảnh điều tra đĩa, không phải bản sao tập tin hệ thống. Các hình ảnh đĩa cần được tạo ra để làm cho việc ghi bảo hộ hoặc ghi nhiều lần bớt rắc rối. Quá trình này là vượt trội so với bản sao lưu tập tin hệ thống cho mục đích điều tra và làm chứng cứ. Hình ảnh cũng có gía trị ở chỗ là an toàn để phân tích một hình ảnh hơn là thực hiện phân tích trên hệ thống ban đầu vì quá trình phân tích có thể vô tình thay đổi bản gốc.

A.4.1 Sự cố từ chối dịch vụ Tạo ra một chiến lược ngăn chặn mà bao gồm một số giải pháp theo thứ tự. Quá trình ra quyết định để

ngăn sự cố DOS là dễ dang nếu các giải pháp đề nghị được xác định trước. Bởi vì hiệu của của mỗi giải pháp sẽ khác nhau trong mỗi sự cố, các tổ chức nên chọn một vài giải pháp và xác định trình tự mà các giải pháp nên được thực hiện.

A.4.2 Sự cố mã độc hại Ngăn sự cố mã độc hại càng nhanh càng tốt. Bởi vì mã độc hại hoạt động bí mật và có thể lan truyền tới

các hệ thống khác nhanh chóng, nhân chặn sớm một sự cố mã độc hại là cần thiết để dừng nó lây lan và gây hại. Hệ thống bị lây nhiễm nên được ngắt kết nối mạng ngay lập tức. Các tổ chức có thể cần phải ngăn chặn mã độc hại ở mức độ máy chủ mail, hoặc thậm trí tạm ngừng dịch vụ mail để giành quyền kiểm soát tính nghiêm trọng sự cố mã độc hại email-borne.

A.4.3 Sự cố truy cập trái phép Cung cấp thông tin quản lý thay đổi cho đội ứng phó sự cố. Dấu hiệu như tắt hệ thống, kiểm toán thay

đổi cấu hình, và sửa đổi thực thi có lẽ do hoạt động thường lệ quản trị hệ thống, chứ không phải là các cuộc tấn công. Khi các dấu hiệu đó được phát hiện, nhóm sẽ có thể sử dụng thông tin quản lý thay đổi để xác minh rằng đó chỉ là do hoạt động đã uỷ quyền.

Chọn chiến lược ngăn chặn mà cân bằng giảm thiểu rủi ro và duy trì dịch vụ. Xử lý sự cố nên cân nhắc các giải pháp ngăn chặn vừa phải, tập trung vào việc giảm thiểu rủi ro càng nhiều tính thực tiễn khi vẫn duy trì các dịch vụ không bị ảnh hưởng.

Khôi phục và cài đặt lại hệ thống mà hiện ra đã phải chịu một thoả hiệp gốc. Những ảnh hưởng của thoả hiệp gốc thường khó để xác định hoàn toàn. Hệ thống sẽ được khôi phục từ một bản sao được biết là tốt, hoặc hệ điều hành và các ứng dụng cần được cài đặt lại từ đầu. Hệ thống sau đó cần đảm bảo sự cố như vậy không thể tái diễn.

A.4.4 Sự cố nhiều phần Ngăn khởi đầu sự cố và tìm kiếm các dấu hiệu thành phần khác của sự cố. Nó có thể mất một khoảng

thời gian dài cho người xử lý để xác định sự cố chỉ có một thành phần; trong đó, sự cố ban đầu đã không được ngăn chặn. Nói chung tốt hơn nên ngăn các khởi đầu sự cố đầu tiên.

A.5 Hoạt động sau sự cố Tổ chức cuộc họp rút kinh nghiệm sau sự cố lớn. Cuộc họp rút kinh nghiệm cực kì hữu ích trong việc cải

thiện các biện pháp an ninh và quá trình xử lý sự cố của riêng mình.A.5.1 Sự cố truy nhập trái phép

Ưu tiên riêng xử lý từng thành phần của sự cố. Tài nguyên có thể quá hạn chế để xử lý tất cả các thành phần cùng một lúc. các thành phần cần được ưu tiên dựa trên nguyên tắc ứng phó dựa trên mỗi thành phần và hiện tại mỗi thành phần là gì.

Page 6: Incident Response

Phụ lục B - Kịch bản xử lý sự cốCác bài tập liên quan đến kịch bản sử lý sự cố được cung cấp rất rẻ và là cách hiệu quả để xây dựng các kĩ năng ứng phó sự cố và xác định các vấn đề tiềm năng với các quy trình ứng phó sự cố. Đội ứng phó sự cố hoặc thành viên trong đội đều có một kịch bản ngắn gọn và một danh sách các câu hỏi liên quan đến kịch bản. Đội sau đó sẽ bàn luận về từng câu hỏi và xác định câu trả lời. Mục đích là để xác định đội thực sự sẽ làm gì và so sánh với các chính sách, thủ tục và thông lệ, và các khuyến cáo thực tiễn để xác định bất kì sai biệt hoặc thiếu xót. Ví dụ, câu trả lời cho một câu hỏi có thể chỉ ra rằng phản ứng sẽ bị trì hoãn vì đội thiếu một phần mềm cụ thể hoặc đội khác trong tổ chức không phục vụ hỗ trợ ngoài giờ.Các câu hỏi được liệt kê dưới đây áp dụng cho hầu hết các kịch bản. Mỗi câu hỏi có kèm theo tham chiếu đến phần liên quan của tài liệu. Sau các câu hỏi là kịch bản, mỗi kịch bản trong số đó được thêm các câu hỏi của vụ việc cụ thể. Tổ chức được khuyến khích mạnh mẽ để thích ứng với những câu hỏi và tình huống để sử dụng trong các bài tập ứng phó sự cố của mình.B1. Kịch bản câu hỏiChuẩn bị:

1. Tổ chức sẽ xem xét hoạt động này là một sự cố? Nếu như vậy, các chính sách của tổ chức mà hoạt động này vi phạm? (Mục 2.1)

2. Những biện pháp được đưa ra để cố gắng ngăn chặn loại sự cố này xảy ra hoặc để hạn chế tác động của nó? (Mục 3.1.2)

Phát hiện và phân tích:1. Điềm báo trước của sự cố, nếu có, tổ chức có thể phát hiện? Bất kì điểm báo sẽ khiến tổ chức cố gắng để

có hành động trước khi sự việc xảy ra? (Mục 3.2.2, 3.2.3)2. Dấu hiệu gì của vụ việc cho thấy tổ chức có thể phát hiện? Dấu hiệu nào sẽ khiến một người nào đó nghĩ

rằng một sự cố có thể xảy ra? (Mục 3.2.2, 3.2.3)3. Các đội ứng phó sự cố sẽ phân tích và xác nhận sự cố này như thế nào? (Mục 3.2.4)4. Đội này sẽ báo cáo sự cố cho ai và những nhóm nào trong tổ chức? (Mục 3.2.7)5. Các đội ứng phó sự cố sẽ ưu tiên xử lý các sự cố này như thế nào? (Mục 3.2.6)

Ngăn chặn, xoá bỏ, phục hồi:1. Chiến lược gì tổ chức thực hiện để ngăn sự cố? Tại sao chiến lược này thích hợp hơn chiến lược khác?

(Mục 3.3.1)2. Điều gì có thể xảy ra nếu sự cố không được ngăn lại? (Mục 3.3.1)3. Nguồn chứng cứ gì, nếu có, tổ chức nên đạt được? Làm thế thế nào sẽ đạt được các bằng chứng? Nơi mà

nó được lưu trữ? Nó nên được giữ lại bao lâu? (Mục 3.2.5, 3.3.2, 3.4.3)Hoạt động sau sự cố

1. Ai sẽ tham dự cuộc họp rút kinh nghiệm liên quan đến sự cố? (Mục 3.4.1)2. Điều gì có thể được thực hiện để ngăn chặn sự cố tương tự xảy ra trong tương lai? (Mục 3.1.2)3. Điều gì có thể thực hiện để phát hiện một sự cố tương tự? (Mục 3.1.2)

Câu hỏi chung:1. Có bao nhiêu thành viên trong nhóm ứng phó sự cố sẽ tham gia xử lý sự cố này? (Mục 2.4.3)2. Bên cạnh đội ứng phó sự cố, những nhóm trong tổ chức sẽ được tham gia trong việc xử lý sự cố này?

(Mục 2.4.4)3. Các bên bên ngoài sẽ được team báo cáo sự cố? Khi nào sẽ diễn ra báo cáo? Cách mỗi báo cáo được đưa

ra? (Mục 2.3.2)4. Những giao tiếp khác với các bên bên ngoài có thể diễn ra? (Mục 2.3.2)5. Những công vụ và tài nguyên sẽ được đổi sử dụng trong việc xử lý sự cố này? (Mục 3.1.1)6. Những khía cạnh của việc xử lý sẽ khác nếu sự việc đã xảy ra tại một ngày và thời gian khác (trong giờ

hành chính với ngoài giờ hành chính)? (Mục 2.4.2)7. Những khía cạnh của việc xử lý sẽ khác nếu sự cố xảy ra tại một vị trí địa lý khác (tại chỗ với khác

chỗ)? (Mục 2.4.2)

Page 7: Incident Response

B.2 Kịch bảnKịch bản 1: Máy chủ phân giải tên miền (DNS) từ chối dịch vụ

Vào một buổi chiều thứ 7, người dùng bên ngoài bắt đầu có vấn đề truy cập vào trang web công cộng của tổ chức. Trong những giờ tiếp theo, vấn đề xấu đi đến mức mà gần như mọi nỗ lực truy cập bất kỳ trang web công cộng nào của tổ chức đều không thành công. Trong khi đó, một nhân viên mạng của tổ chức ứng phó bằng tạo ra các cảnh báo tự động từ bộ định tuyến Internet biên giới và xác định rằng có rất nhiều băng thông Internet của tổ chức đang bị chiếm dụng bởi một khối lượng lớn bất thường các gói UDP đến và đi từ cả hai máy chủ phân giải tên miền công cộng của tổ chức. Phân tích lưu lượng chỉ ra rằng máy chủ DNS nhận được số lượng lớn các yêu cầu từ một một địa chỉ IP duy nhất. Người quản trị mạng cũng thông báo rằng tất cả yêu cầu DNS từ địa chỉ đó có cổng nguồn là UDP 7 hoặc UDP 19. Trong khi đang phân tích, bộ cảm ứng phát hiện xâm nhập mạng của tổ chức ghi được hoạt động đáng ngờ liên quan đến dịch vụ echo và chargen.Sau đây là những câu hỏi bổ sung cho kịch bản này:

1. Tổ chức nên liên lạc ai mà liên quan đến địa chỉ IP bên ngoài sử dụng trong tất cả các gói tin?2. Giả sử sau khi các biện pháp ngăn chặn ban đầu được đưa ra, các quản trị mạng phát hiện rằng chín máy

bên trong cũng đã có yêu cầu bất thường tới các máy chủ DNS. Điều này sẽ ảnh hưởng đến việc xử lý sự cố này thế nào?

3. Giả sử hai trong số chín máy nội bộ rời mạng trước khi chủ hệ thống của họ được liên hệ. làm thế nào xác định được chủ sở hữu hệ thống.

Kịch bản 2: Nội bộ tạo ra spamVào một buổi sáng thứ năm, tài khoản emai “làm dụng” của tổ chức nhận được khiếu nại của một ngừoi về việc nhận được thư rác từ tổ chức. Tin nhắn có chứa một bản sao của thư rác (với đầy đủ các tiêu đề email) mà quảng bá một chương trình làm giàu nhanh chóng. Một quản trị an ninh – người giám sát tài khoản “lạm dụng” đánh giá email và xác định rằng các tiêu đề được chỉ ra cho thấy rằng các thư rác được tạo ra bằng cách sử dụng máy chủ email của tổ chức. Người quản trị an ninh chuyển email đến đội ứng phó sự cố, cùng với một lưu ý ngắn gọn về hoạt động này. Một thành viên của đội ứng phó sự cố phân tích hoạt động và khẳng định rằng tiêu đề thư rác là thực sự và nó được gửi từ máy chủ mail của tổ chức.Sau đây là câu hỏi bổ sung cho kịch bản này:

1. Làm thế nào các đội ứng phó xác nhận được nguồn gốc của thư rác?2. Tổ chức sẽ trả lời khiếu lại liên quan đến thư rác như thế nào?

Kịch bản 3: Sâu và ký sinh DDOS AgentVào sáng thứ ba, một con sâu mới được phát hành trên Internet. Con sâu khai thác lỗ hộng của Microsoft Windows đã được công bố công khai 2 tuần trước, mà lúc đó các bản vá lỗi được phát hành. Con sâu này lây lan chính nó thông qua hai phương pháp: (1) gửi bản thân nó trong email đến các địa chỉ mà nó có thể xác định vị trí trên máy chủ bị nhiễm và (2) xác định và gửi chính nó đến máy chủ mở chia sẻ Windows. Sâu được thiết kế để tạo ra một tên đính kèm khác nhau cho mỗi bản sao mà nó gửi; mỗi tập tin đính kèm sẽ có tên tập tin ngẫu nhiên tạo ra sử dụng một trong số hơn mười phần mở rộng tập tin. Sâu cũng chọn từ hơn 100 email subjects và một số lượng tương tự của thân email. Khi con sâu lây nhiễm một máy, nó cố gắng tăng quyền quản trị và cố tải về một phân phói DDOS agent từ địa chỉ IP khác sử dụng File Transfer Protocol(FTP). (Số lượng IP cung cấp agent là không rõ.) mặc dù các nhà cung cấp chống virú nhanh chóng gửi cảnh báo về loại sâu này, nó lây lan rất nhanh, trước khi bất kì nhà cung cấp có phát hành chữ ký. Tổ chức đã phát sinh nhiễm bệnh rộng rãi trước khi chữ ký chống virus phát hành ba giờ và sau khi sâu bắt đầu lan truyền.Sau đây là những câu hỏi bổ sung cho kịch bản này:

1. Các đội ứng phó sẽ xác định tất cả các máy bị nhiễm như thế nào?2. Tổ chức nỗ lực thế nào để ngăn chặn sự xâm nhập của sâu vào tổ chức trước khi chữ ký chống virus

được phát hành?3. Tổ chức nỗ lực thế nào để ngăn chặn sâu lây lan từ những máy bị nhiễm trước khi chữ ký chống virus

được phát hành.4. Tổ chức sẽ nỗ lực để vá tất cả máy bị tổn thương? Nếu vậy, điều này được thực hiện thế nào?5. Xử lý các thay đổi của sự cố này thế nào nếu máy bị nhiễm nhận được DDOS agent đã được cấu hình để

tấn công một trang web của tổ chức khác vào sáng hôm sau.6. Đội ứng phó sự cố sẽ thông báo cho người dùng về tình trạng của sự cố như thế nào? Điều gì xảy ra nếu

dịch vụ mail đã quá tải hoặc không hoạt động do sâu?

Page 8: Incident Response

7. Những biện pháp bổ sung, nếu có, đội sẽ sử dụng để để chăm sóc các máy hiện không kết nối vào mạng (ví dụ, nhân viên nghỉ, nhân viên sử dụng dịch vụ từ xa thỉnh thoảng thông qua đường điên thoại)?

Kịch bản 4: Sử dụng mã thẻ ngân hàng đánh cắpVào sáng thứ 2, Bộ phận pháp chế của tổ chức nhận được một cuộc gọi từ Cục Điều Tra Liên Bang (FBI) liên quan đến một số hoạt động đáng ngờ có nguồn gốc từ mạng của tổ chức. Sau ngày hôm đó, một nhân viên FBI gặp các thành viên quản lý và các bộ phận pháp lý để thảo luận về hoạt động này. FBI đã điều tra các hoạt động liên quan đến mua hàng trực tuyến được thực hiện với một số mã số thẻ tín dụng bị đánh cắp, và hơn 30 các giao dịch trong tuần qua đã được bắt nguồn từ một trong các địa chỉ IP của tổ chức. Các đại lý yêu cầu hỗ trợ của tổ chức, và đến lượt mình, các nhà quản lý yêu cầu các đội phản ứng của sự cố hỗ trợ trong việc thu được các chứng cứ cần thiết. Điều tối quan trọng là vấn đề này được giữ bí mật.Phần tiếp theo là câu hỏi bổ sung cho kịch bản này:

1. Những nguồn nào mà các đội ứng phó sự cố có thể thu thập chứng cứ?2. Các đội sẽ xác định các máy chủ hiện đang sử dụng địa chỉ IP đặc biệt như thế nào? Làm thế nào các đội

chứng minh được máy đã sử dụng địa chỉ IP được chỉ định một tuần trước đây?3. Đội sẽ làm gì để giữ bí mật điều tra?

Kịch bản 5: Máy chủ cơ sở dữ liệu bị tổn thươngVào tối thứ 3, quản trị cơ sở dữ liệu thực hiện bảo trì vài giờ một số máy chủ cơ sở dữ liệu sản xuất. Quản trị thông báo một số tên thư mục không quen thuộc và không bình thường trên một trong các máy chủ. Sau khi xem lại danh sách thư mục và xem một số các tập tin, quản trị kết luận rằng các máy chủ đã bị tấn công và gọi các đội ứng phó sự cố để được hỗ trợ. Nhóm nghiên cứu điều tra xác định rằng những kẻ tấn công đã thành công đạt được quyền truy cập root đến máy chủ 6 tuần trước.Phần tiếp theo là câu hỏi bổ sung cho kịch bản:

1. Nguồn mà đội sử dụng để xác định khi nào thoả hiệp xảy ra?2. Cách xử lý sự cố thay đổi thế nào nếu đội tìm thấy máy chủ cơ sở dữ liệu đã chạy một gói nghe lén và

bắt mật khẩu từ mạng?3. Cách xử lý sự cố thay đổi thế nào nếu đội thấy rằng các máy chủ đã chạy một tiến trình mà sao chép một

cơ sở dữ liệu chứa thông tin nhạy cảm của khách hàng mỗi đêm và gửi nó đến địa chỉ bên ngoài?Kịch bản 6: Virus chơi khămVào chiều thứ tư, một người dùng chuyển email đến phòng hỗ trợ khách hàng về một loại virus khủng khiếp mới. Người sử dụng nhận được e-mail từ một người bạn tại một tổ chức khác. Email nói rõ virus mới không thể bị phát hiện bởi phần mềm chống virus và rằng người dùng nên tìm kiếm và xóa ba tập tin virus đặc biệt từ ổ đĩa cứng của họ. Một đại diện phòng hỗ trợ nghiên cứu các tin nhắn, xác định rằng nó là virus chơi khăm, và hồi đáp cho người dùng bằng e-mail.Trong khi đó, những người dùng khác nhận được cùng một cảnh báo virus e-mail từ các bên khác và gửi nó cho người khác ở bên trong và bên ngoài tổ chức. Vào chiều thứ Năm, Trợ giúp khách hàng đã nhận được nhiều cuộc gọi xuất hiện có liên quan đến xóa ba "tập tin virus" từ ổ đĩa cứng của họ; những tập tin này là các tập tin thực sự hợp pháp mà một số ứng dụng sử dụng. Người đứng đầu phòng trợ giúp yêu cầu các đội ứng phó sự cố hỗ trợ.Phần tiếp theo là câu hỏi bổ sung cho kịch bản:

1. Tổ chức có thể nhận diện máy thiếu ba tập tin này? Nếu vậy, thực hiện điều này thế nào? Nếu không, việc này có những tác động tiêu cực nào?

Kịch bản 7: Dữ liệu trái phép trên máy chủ FTPTrong khi tạo ra báo cáo sử dụng hàng tuần, một quản trị mạng thông báo rằng sử dụng băng thông giờ thấp điểm trên phân vùng phi quân sự (DMZ) của tổ chức đã cao hơn bình thường đáng kể. Người quản trị cấu hình phần mềm giám sát để thu thập số liệu thống kê chi tiết hơn về sử dụng băng thông DMZ. Ngày hôm sau, người quản trị thấy một tỷ lệ lớn bất thường của các hoạt động liên quan đến máy chủ FTP của tổ chức. Người quản trị mạng liên hệ với quản trị máy chủ FTP, người vừa trở về từ kì nghỉ, liên quan đến vấn đề gia tăng trong các hoạt động.Người quản trị FTP nhanh chóng xác định rằng máy chủ đã lưu trữ các dữ liệu trái phép, bao gồm phần mềm vi phạm bản quyền, bài hát, phim ảnh. Người quản trị liên hệ với đội ứng phó sự cố liên quan đến hoạt đông này.Sau đây là những câu hỏi bổ sung cho kịch bản này:

1. Nhóm sẽ nỗ lực để xác định tất cả các cá nhân đã tải lên các tài liệu bất hợp pháp vào máy chủ FTP? Nếu vậy, Thực hiện việc này thế nào?

2. Nhóm sẽ nỗ lực để xác minh rằng các tài liệu trái phép là bất hợp pháp? Nếu vậy, Thực hiện điều này thế

Page 9: Incident Response

nào?Kịch bản 8: Tấn công DDOS đi ra bên ngoàiVào tối chủ nhật, một bộ cảm ứng phát hiện xâm nhập mạng của tổ chức đã cảnh báo về nghi ngờ liên quan đến hoạt động tấn công DDOS thực hiện mốt số lượng lớn ping Internet Control Message Protocol (ICMP). Các nhà phân tích đánh giá cảnh báo, mặc dù các nhà phân tích không khẳng định rằng các cảnh báo là chính xác, nó không phù hợp với bất kỳ trường hợp dương tính giả nào được biết đến. Các nhà phân tích liên lạc đội ứng phó sự cố để họ điều tra hoạt động kĩ hơn. Bởi vì hoạt động DDOS sử dụng các địa chỉ IP nguồn giả mạo, phát mất nhiều thời gian và công sức để xác định máy trong tổ chức đang tạo ra nó; trong khi đó, hành động DDOS vẫn tiếp diễn. Các cuộc điều tra cho thấy dường như 5 máy chủ tạo ra lưu lượng DDOS. Phân tích năm máy chủ chỉ ra rằng mỗi máy chủ chứa dấu hiệu của một rootkit DDOS. Thêm vào đó, ba máy chủ dường như đã được sử dụng để tấn công một máy nội bộ khác, một dường như đã được sử dụng để tấn công máy bên ngoài như đã biết. Phần tiếp theo là câu hỏi bổ sung cho kịch bản này:

1. Đội xác định máy trong tổ chức đang sản sinh ra lưu lượng bằng cách nào? Các đội khác có thể hỗ trợ nhóm ứng phó sự cố điều gì?

2. Tổ chức sẽ liên lạc với chủ sở hữu của các địa chỉ IP là mục tiêu của tấn công DDOS? Nếu vậy, Ai là người liên lạc họ, Liên lạc sẽ được thực hiện thế nào?

3. Nếu đội ứng phó sự cố xác định rằng khác thoả hiệp ban đầu đã được thực hiện thông qua một modem của một máy chủ. Các đội sẽ điều tra tiếp hành động này thế nào?

Kịch bản 9: Truy cập không xác thực tới bản ghi bảng lươngVào tối thứ tư, đội bảo vệ của tổ chức nhận được một cuộc gọi từ quản lý bảng lương- người bắt gặp một một người lạ rời khỏi văn phòng của cô ấy. Người quản lý nhìn thấy người đó chạy xuống hành lang và vào cầu thang dẫn đến lối ra toàn nhà. Người quản lý đã để lại máy tính đã được mở khoá và không được theo dõi chỉ vài phút. Phần mềm tính lương đã được đăng nhập và ở trên menu chính, như khi cô ấy rời khỏi, nhưng người quản lý thông báo rằng chuột đã được di chuyển. Đội ứng phó sự cố được yêu cầu để điều tra liên quan đến sự cố mà xác định hành động nào đã được thực hiện (ví dụ: truy cập bảng lương, sửa đổi, Troijan horse được cài đặt).Phần tiếp theo là câu hỏi bổ sung cho kịch bản:

1. Đội xác định hành động nào đã được thực hiện như thế nào?2. Cách xử lý sự cố sẽ khác như thế nào nếu quản lý bảng lương đã xác nhận người rời khỏi văn phòng cô

ấy là nhân viên cũ của phòng lương.3. Cách xử lý sự cố sẽ khác gì nếu đội bảo vệ vật lý xác nhận rằng người đó đã sử dụng kỹ thuật lừa đảo để

đạt được quyền truy cập vật lý vào toàn nhà và phòng tính toán lương.4. Cách xử lý vụ việc sẽ khác gì nếu đội có lý do để tin rằng người kia hiện tại là nhân viên tổ chức?5. Cách xử lý sẽ khác gì nếu nhật kí truy cập từ xa từ tuần trước đã cho thấy một lượng lớn bất thường lần

đăng thất bại sử dụng id người quản lý bảng lương. Kịch bản 10: Tải về công cụ hackingVào chiều thứ 6, bộ cảm ứng phát hiện xâm nhập mạng ghi lại một số hoạt động FTP đáng ngờ liên quan đến người dùng nội bộ đang tải tập tin từ máy chủ FTP bên ngoài. Các nhà phân tích đánh giá cảnh báo và thông báo rằng đây chỉ là dương tính giả. Mặc gù thông báo chỉ ra rằng một cuộc tấn công đã xảy ra, các dữ liệu hỗ trợ ghi bởi bộ cảm ứng không có dấu hiệu của một cuộc tấn công. Tuy nhiên, dữ liệu đã đề cao mối quan tâm khác vì họ cho rằng người sử dụng tải về một tập tin thực thi từ một cấu trúc thư mục đang ngờ chứa khoảng trắng và dấu chấm lặp đi lặp lại, cũng như ký tự không thường thấy trong tên thư mục FTP. Các nhà phân tích xâm nhập sử dụng một công cụ tìm kiếm Internet để tìm kiếm thôn tin về tên tập tin thực thi, và một trong số đó phù hợp với tên của các công cụ hacking. Các nhà phân tích liên lạc đội ứng phó sự cố để thực hiện phân tích và xác định cách xử lý hoạt động này.Phần tiếp theo là câu hỏi bổ sung cho kịch bản:

1. Đội xác nhận tập tin người dùng đã tải về thế nào?2. Làm thế nào mà đội khẳng định tập tin đã được tải về là công cụ hacking?3. Cách xử lý sự cố sẽ khác gì nếu người dùng bị nghi ngờ tải về công cụ là người của đội an toàn thông tin

của tổ chức?4. Cách xử lý sự cố sẽ khác gì nếu người dùng bị nghi ngờ tải về công cụ là người của đội ứng phó sự cố?5. Cách xử lý sự cố sẽ khác gì nếu người dùng bị nghi ngờ tải về công cụ là một nhà thầu vừa phát hiện ra

rằng hợp đồng của anh ta không được gia hạn?Kich bản 11: Máy chủ biến mất

Page 10: Incident Response

Vào chiều thứ năm, một cảm ứng phát hiện xâm nhập mạng ghi lại hoạt động quét lỗ hổng nhằm vào máy chủ mà được tao ra bởi một địa chỉ IP nội bộ. Bởi vì nhà phân tích phát hiện xâm nhập không hề biết đó bất kỳ hoạt động nào đã được uỳ quyền, dự kiến đó là hoạt động quét lỗ hổng, cô báo cáo haotj động cho đội ứng phó sự cố. Khi đội bắt đầu phân tích, đội phát hiện rằng hoạt động này đã dừng lại và không có một máy nào sử dụng địa chỉ IP này.Sau đây là những câu hỏi bổ sung cho kịch bản này:

1. Nguồn dữ liệu nào có thể chứa thông tin về danh tính của máy quét lỗ hổng?2. Đội xác định người đã thực hiện việc quét lỗ hổng thế nào?3. Đội làm thế nào xác nhận các tập tin đã được tải về là công cụ hack?4. Cách xử lý vụ việc này sẽ khác gì nếu hành động quét lỗ hổng hướng vào máy quan trọng nhất của tổ

chức?5. Cách xử lý vụ việc này sẽ khác gì nếu hành động quét lỗ hổng hướng vào máy tính bên ngoài?6. Cách xử lý vụ việc này sẽ khác gì nếu nhân viên an ninh vật lý phát hiện ra rằng một người nào đó đã

đột nhập vào cơ sở nửa giờ trước khi quét lỗ hổng xảy ra?

Kịch bản 12: Vào tối thứ 7, phần mềm phát hiện xâm nhập đã ghi lại một số thiết bị thăm dò và quét từ 1 ip nội bộ. Phần mềm phát hiện xâm nhập trên vài máy chủ cũng ghi lại 1 vài các đầu dò và quét . Các nhà phân tích phát hiện xâm nhập đã xác định địa chỉ ip thuộc vào máy chủ VPN của tổ chức và liên hệ với đội ứng phó sự cố. Nhóm nghiên cứu đánh giá các phát hiện xâm nhập, tường lửa, log máy chủ VPN và xác định địa chỉ ip mà tạo ra hành động, ID của người dùng đã được xác nhận cho phiên làm việc và tên người sử dụng được kết hợp với các ID của người dùng.Dưới đây là những câu hỏi bổ sung cho kịch bản này: 1, Bước tiếp theo nhóm nghiên cứu nên làm (vd: kêu gọi người sử dụng tại nhà, vô hiệu hóa các ID người sử dụng, ngắt kết nối các phiên VPN)? Tại bước này nên được thực hiện đầu tiên? Bước nào nên được thực hiện thứ hai?2, Giả sử máy tính cá nhân của người sử dụng đã bị nhiễm trojan từ 1 trò chơi được download từ 1 thành viên trong gia đình. Điều này sẽ ảnh hưởng gì đến phân tích của nhóm nghiên cứu? Điều này sẽ ảnh hưởng gì đến thu thập chứng cứ và xử lý?3, Sự cố được xử lí như thế nào nếu địa chỉ ip bên ngoài thuộc về người sử dụng xác định, nhưng địa chỉ ip là 1 thiết bị tường lửa thực hiện chuyển đổi địa chỉ mạng cho 8 máy sau nó?4, Nhóm nên làm về xoá bỏ tận gốc sự cố từ máy tính cá nhân của người dùng?5, Giả sử rằng người dùng cài phần mềm chống virus và xác định rằng con trojan còn bao gồm 1 phần mềm keylogger. Điều này sẽ ảnh hướng đến xử lý các sự cố như thế nào? Điều này sẽ ảnh hưởng đến xử lý các sự cố như thế nào nếu người dùng là 1 quản trị hệ thống? Điều này sẽ ảnh hưởng đến việc xử lý sự cố như thế nào nếu người dùng là 1 nhà quản lí cấp cao trong tổ chức?6, Sự cố sẽ được xử lí như thế nào nếu địa chỉ ip bên ngoài ko phải là của người dùng xác định?7, Sự cố sẽ được xử lý như thế nào nếu người dùng cài đặt lại hệ điều hành trên máy bị ảnh hưởng trước khi các đội thực hiện bất kì phân tích trên máy? Kịch bản 13:Vào buổi chiều thứ 5, đội ngũ an ninh vật lý của 1 tổ chức nhận được cuộc gọi từ 1 người quản lý, bảo rằng 1 trong những nhân viên của mình đã nhận được 1 cuộc điện thoại từ 1 người tuyên bố là một nhóm khủng bố. Người gọi điện đã thực hiện các mối đê dọa với công ty và nói rằng cuộc tấn công sẽ xảy ra trong tuần tới. Người gọi đã ko đưa ra kiểu tấn công hay các khía cạnh của tổ chức(vd: cơ sở vật chất, con người, máy tính..). Dựa trên điều ra đội bảo vệ vật lý đã đưa ra rằng mối đe dọa phải được thực hiện nghiêm túc và thông báo cho các đội thích hợp, bao gồm các đội phản ứng an ninh và sự cố của các mối đe dọa.Những câu hỏi bổ sung kịch bản này: 1, Đội ứng phó sự cố nên làm gì, nếu bất cứ điều gì, để ứng phó với thông báo về mối đe đoạ?2, Ảnh hưởng nào sẽ nâng cao kiểm soát an ninh vật lý trên phản ứng của nhóm đối với sự cố? .Kich bản 14: Đám cháy và quét cổngVào chiều thứ 3 sau khi nhận được mối đe dọa kịch bản 13, 1 nhà phân tích phát hiện xâm nhập thấy một số cảnh báo liên quan đến hoạt động quét bất thường tập chung vào 1 số máy chủ từ xa. Các nhà phân tích gọi đội ứng phó sự cố để được yêu cầu trợ giúp trong việc điều tra và đánh giá các hoạt động này. Trước khi bất kì ai

Page 11: Incident Response

trong đội ứng phó sự cố đáp ứng yêu cầu, nhóm nghiên cứu nhận ra rằng có một đám cháy tại cơ sở từ xa. Không có chi tiết nào sẵn sàng ngoài trừ phương tiện đã được sơ tán trong khi lửa đang được ngăn lại.Những câu hỏi bổ xung cho kịch bản này: 1, Đội ứng phó sự cố nên tiến hành như thế nào?2, Cách xử lý sự cố sẽ khác gì nếu nhà phân tích phát hiện xâm nhập đã gọi lại cho đội để báo cáo rằng cảnh báo tiếp theo cho thấy một cuộc tấn công thành công đối với một trong các máy chủ?3, Cách xử lý sự cố sẽ khác gì nếu các cơ sở từ xa bị đám cháy làm mất kết nối mạng ?4, Cách xử lý sự cố sẽ khác gì nếu các mục tiêu rõ ràng của quá trình quét đã bị hư hại do đám cháy?5, Cách xử lý sự cố sẽ khác gì nếu đám cháy xảy ra tại cơ sở của đội ứng phó sự cố?6, Cách xử lý sự cố này sẽ khác gì nếu đội ứng phó và hệ thống mục tiêu cùng làm việc trên một cơ sở đám cháy xảy ra ở đó?Kịch bản 15: Chia sẻ tập tin Peer-to-PeerTổ chức có chính sách cấm việc sử dụng các dịch vụ chia sẻ tập tin peer-to-peer, chẳng hạn những người cho phép tập tin ca nhạc được chuyển trên mạng giữa những trạm chia sẻ tập tin. Bộ cảm biến phát hiện xâm nhập của tổ chức đã kích hoạt chữ ký có thể phát hiện việc sử dụng một số dịch vụ chia sẻ tập tin phổ biến peer-to-peer. Vào tối thức hai, một nhà phân tích xâm nhập thông báo một cảnh báo vài tập tin chia sẻ đã xảy ra trong ba giờ qua, tất cả liên quan đến cùng địa chỉ IP nội bộ.Sau đây là phần câu hỏi bổ sung cho kịch bản:

1. Những yếu tố nên được sử dụng để ưu tiên xử lý sự cố này (ví dụ., nội dung rõ ràng của các tập tin đang được chia sẻ)?

2. Những yếu tố riêng tư có thể tác động đến việc xử lý sự cố này?Kịch bản 16: Bộ truy cập không dây không rõVào buổi sáng thứ hai, dịch vụ hỗ trợ của tổ chức nhận cuộc gọi từ ba người dùng trên cùng một tầng của toà nhà tuyên bố rằng họ có vấn đề với truy cập không dây của họ. Người quản trị mạng đã được yêu cầu để giải quyết vấn đề này đem máy tính với truy cập không dây tới tầng của người dùng. Như anh ấy xem cấu hình mạng của anh ấy, anh ấy nhận thấy có điểm truy cập không dây mới tồn tại. Anh kiểm tra với đồng đội và xác định rằng điểm truy cập này không được triển khai bởi nhóm anh ấy, nó có khả năng là một điểm truy cập giả mạo đã được thành lập mà không có sự cho phép.Sau đây là câu hỏi bổ sung cho kịch bản này:

1. Bước quan trọng đầu tiên nên làm trong việc xử lý vụ việc này là gì? (ví dụ: tìm kiếm theo cách vật lý điểm truy cập giả mạo, hợp lý gắn với các điểm truy cập)

2. Cách nhanh nhất để xác định vị trí các diểm truy cập là gì? Cách bí mật nhất để xác định vị trí các điểm truy cập là gì?

3. Cách xử lý vụ việc này sẽ khác gì nếu điểm truy cập được triển khai bởi một bên ngoài (ví du nhà thầu) tạm thời làm việc tại văn phòng của tổ chức?

4. Cách xử lý vụ việc này sẽ khác gì nếu một nhà phân tích phát hiện xâm nhập báo cáo có dấu hiệu hoạt động đáng ngờ liên quan đến một số các máy trạm của người sử dụng không dây trong tầng của toà nhà?

5. Cách xử lý sự cố sẽ khác gì nếu điểm truy cập đã bị loại bỏ trong khi đội vẫn cố gắng xác định vị trí vật lý của nó?

Phụ lục C - Sự cố liên quan đến các trường dữ liệuTổ chức nên xác định một bộ tiêu chuẩn của sự cố liên quan đến các trường dữ liệu được thu thập cho mỗi sự cố. Nỗ lực này không chỉ tạo điều kiên hiệu quả và phù hợp cho xử lý sự cố, mà còn hỗ trợ tổ chức trong việc đáp ứng yêu cầu bản báo cáo sự cố được áp dụng. Các tổ chức nên thiết kế một tập hợp các linh vực cơ bản (ví dụ, tên người báo cáo sự cố, số điện thoại và vị trí) được thu thập khi các vụ việc được báo cáo và thiết lập thêm các lĩnh vực được thu thập bởi người xử lý sự cố trong quá trình ứng phó của họ. Hai tập hợp các trường sẽ là cơ sở cho các cơ sở dữ liệu báo cáo sự cố, đã được thảo luận trước đây tại mục 3.2.5. Danh sách dưới đây cung cấp các đề xuất của thông tin nào được thu thập cho sự cố và không dự định đầy đủ. Mỗi tổ chức nên tạo danh sách của chính họ có các trường dựa trên một vài yếu tố, bao gồm mô hình và cấu trúc đội ứng phó sự cố và định nghĩ của thuật ngữ “sự cố”.C.1 Trường dữ liệu cơ bản

Thông tin liên lạc cho người báo cáo sự cố◦ Tên◦ Đơn vị tổ chức (ví dụ: cơ quan, phòng ban, nhóm)

Page 12: Incident Response

◦ Địa chỉ email◦ Số điện thoại◦ Địa chỉ (ví dụ: địa chỉ gửi thư, số phòng văn phòng)

Chi tiết sự cố◦ Ngày/giờ sự cố được phát hiện.◦ Loại sự cố (ví dụ: từ chối dịch vụ, mã độc hại, truy cập trái phép)◦ Ngày / thời gian sự cố xảy ra (nếu biết)◦ Trạng thái hiện thời của sự cố (ví dụ: tấn công đang tiến hành)◦ Nguồn / nguyên nhân của sự cố (nếu biết) bao gồm tên máy và địa chỉ ip◦ Mô tả về sự cố (chẳng hạn như được tìm ra thế nào, những gì xảy ra)◦ Mô tả về ảnh hưởng tài nguyên (chẳng hạn như mạng, máy, ứng dụng, dự liệu) bao gồm tên máy và

địa chỉ ip của hệ thống.◦ Ước tính tác động kỹ thuật của sự cố (ví dụ: dữ liệu bị xoá, hệ thống bị treo, ứng dụng không có sẵn)◦ Hành động ứng phó đã thực hiện (ví dụ như tắt máy chủ, ngắt máy khỏi mạng)◦ Tổ chức khác đã liên hệ (ví dụ nhà cung cấp phần mềm)

Bình luận chungC.2 Trường dữ liệu của người xử lý sự cố

Trạng thái hiện tại của ứng phó sự cố Tóm tắt các sự cố Các hành động xử lý sự cố

◦ Nhật kí của các hành động được thực hiện bởi tất cả người xử lý◦ Thông tin liên hệ cho tất cả các bên liên quan◦ Danh sách các bằng chứng thu thập được

Bình luận của người xử lý sự cố Nguyên nhân của sự cố (ví dụ: ứng dụng cấu hình sau, máy chưa được vá) Chi phí của sự cố Tác động đến doanh nghiệp của sự cố

Phụ lục D - Thuật ngữThuật ngữ sử dụng trong Hướng Dẫn Xử Lý Sự Cố Bảo Mật Máy Tính được định nghĩa dưới đây:Agent: một chương trình máy tính được sử dụng trong từ chối dịch vụ phân tán(DDOS) đưa lượng lớn truy cập độc hại vào máy chủ dựa trên các hướng dẫn của trình xử lý.Đường cơ sở: Giám sát nguồn tài nguyên để xác định mô hình sử dụng điển hình sao cho sai lệch đáng kể có thể được phát hiện.Tấn công pha trộn: mã độc hại có thể sử dụng nhiều phương pháp để lây lanVirus Boot Sector: Là một loại virus tự cấy nó vào khu vực khởi động của hệ thống và lây nhiễm bản ghi khởi động chính.Pháp y máy tính: tiến hành thu thập, duy trì và phân tích dữ liệu liên quan đến máy tính cho mục địch điều tra mà duy trì một cách toàn vẹn dữ liệu.Sự cố bảo mật máy tính: nhìn “sự cố”Đội ứng phó sự cố bảo mật máy tính (CSIRT): Có khả năng thiết lập với mục hỗ trợ ứng phó sự cố an ninh liên quan đến máy tính; còn được gọi là đội ứng phó sự cố máy tính (CIRT) hoặc một CIRC (Trung tâm ứng phó sự cố máy tính, Khả năng ứng phó sự cố máy tính)Từ chối dịch vụ (DoS): một tấn công mà ngăn chặn hoặc làm suy yếu việc uỷ quyền sử dụng của mạng, hệ thống hoặc ứng dụng bằng cách tiêu tốn tài nguyênTừ chối dịch vụ phân tán (DdoS): Một kĩ thuật DoS mà sử dụng nhiều máy để thực hiện tấn công.Lọc đầu ra: Quá trình chặn gói tin gửi đi mà sử dụng sai địa chỉ Internet Protocol (IP), chẳng hạn như địa chỉ nguồn từ các mạng nội bộ.Sự kiện: Bất kỳ hành động xảy ra quan sát được trong một mạng hoặc hệ thống.Dương tính giả: Một cảnh báo rằng không chính xác chỉ ra rằng hoạt động nguy hiểm đang xảy ra.File Infector Virus: Một virus mà tự gắn nó vào một tập tin chương trình, chẳng hạn như một trình xử lý văn bản, ứng dụng bảng tính, hoặc trò chơi.Kiểm tra tính toàn vẹn của tập tin: Phần mềm tạo ra, lưu trữ, và so sánh thông điệp phân loại cho các tập tin để phát hiện những tập tin bị thay đổi.

Page 13: Incident Response

Pháp y: Xem "pháp y máy tính."Bộ xử lý: Một loại chương trình được sử dụng trong các cuộc tấn công DDoS để kiểm soát các agent phân phối trên toàn mạng. Cũng đề cập đến một người xử lý sự cố, trong đó đề cập đến một người thực hiện công việc ứng phó sự cố.Honeypot: Một máy chủ được thiết kế để thu thập dữ liệu về hoạt động đáng ngờ và không có người sử dụng có thẩm quyền khác với các quản trị viên của mình.Cách sử dụng không phù hợp: Một người vi phạm chính sách sử dụng máy tính có thể chấp nhậnSự cố: Một vi phạm hoặc đe dọa sắp xảy ra vi phạm các chính sách bảo mật máy tính, chính sách sử dụng chấp nhận được, hoặc thực hành bảo mật máy tính tiêu chuẩn.Xử lý sự cố: Các giảm thiểu vi phạm các chính sách an ninh và thực hành được đề nghị.Ứng phó sự cố: Xem "xử lý sự cố."Chỉ định: Một dấu hiệu cho thấy một sự cố có thể xảy ra hoặc có thể xảy ra hiện tại.Lọc đầu vào: Quá trình ngăn chặn các gói tin đến mà rõ ràng là sử dụng địa chỉ IP giả, chẳng hạn như địa chỉ nguồn đã được dành riêng.Hệ thống phát hiện xâm nhập (IDS): Phần mềm mà tìm kiếm các hành động đang ngờ và cảnh báo quản trị viên.Macro Virus: Một virus mà đính kèm chính nó trong tài liệu hoặc sử dụng khả năng lập trình macro của ứng dụng tài liệu để lan truyền và thực hiện.Mã độc hại: Virus, sâu, Trojan horse, hoặc các thực thể dựa trên mã mà có thể lây nhiễm một máy chủ.Thông điệp phân loại: Một kiểm tra mật mã, thông thường tạo ra cho một tập tin mà có thể được sử dụng để phát hiện các thay đổi đối với các tập tin; Secure Hash Algorithm-1 (SHA-1) là một ví dụ của một thuật toán thông điệp phân loại.Mã điện thoại di động: Phần mềm được truyền đi từ một hệ thống từ xa đến một hệ thống nội bộ, sau đó thực hiện trên hệ thống nội bộ mà không có hướng dẫn rõ ràng của người sử dụng; ví dụ về các phần mềm mã điện thoại di động là Java, JavaScript, VBScript, và ActiveX.Sự cố nhiều phần: Một sự kiện đơn lẻ mà chứa hai hay nhiều sự kiện khác.Packet Sniffer: Phần mềm mà quan sát và ghi lại lưu lượng truy cập mạng.Quản lý bản vá lỗi: Quá trình thu thập, kiểm tra và phân phối các bản vá lỗi cho các quản trị viên và người sử dụng phù hợp của tổ chứcQuét cổng: Sử dụng một chương trình để xác định từ xa các cổng trên hệ thông đang mở (ví dụ: hệ thống cho phép kết nối thông qua các cổng)Báo trước: một dấu hiệu cho thấy kẻ tấn công có thể đang chuẩn bị gây ra một sự cố.Tạo hồ sơ: Đo lường các đặc điểm của hoạt động dự kiến để thay đổi của nó có thể được xác định dễ dàng.Rủi ro: Xác xuất mà một hay nhiều sự kiện sẽ xảy raRootkit: Một tập hợp các công cu sử dụng bởi kẻ tấn công sau khi đạt được quyền truy nhập mức độ root tới máy máy để che giấu hoạt động của kẻ tấn công trên máy chủ và cho phép kẻ tấn công duy trì quyền truy cập root tới máy thông qua phương tiện bí mật.Quét: Gửi gói tin hoặc yêu cầu tới hệ thống khác đề đạt được thông tin có thể sử dụng cho tấn công sau đó.Chữ ký: Một cái nhận biết, phân biệt mẫu liên quan tới tấn công, chẳng hạn như một chuỗi nhị phân trong một virus, hoặc một tập hợp các tổ hợp phím sử dụng để truy cập trái phép vào hệ thống.Kỹ thuật xã hội: một cố gắng để lừa một người nào đó tiết lộ thông tin (ví dụ, mật khẩu) có thể được sử dụng để tấn công các hệ thống hoặc các mạng.Mối đe doạ: Các nguồn tiềm tàng của một sự kiện bất lợi.Trojan Horse: Một chương trình không tự nhân bản mà có vẻ là có mục đích hữu ích, nhưng trong thực tế lại khác, có mục đích độc hại. Truy cập trái phép: Một người cố gắng truy cập vật lý hoặc logic không được phép tới hệ thống, mạng, ứng dụng, dữ liệu hoặc tài nguyên khác.Nạn nhân: một máy mà đã bị tấn côngVirus: một chương trình tự động nhân bản mà chạy và lây lan bằng cách thay đổi các chương trình hoặc tập tin khác.Virus chơi khăm: Một thông điệp cảnh báo khẩn cấp về một loại virus không tồn tại.Lỗ hổng: Một điểm yếu trong hệ thống, ứng dụng hoặc mạng mà đối tượng có thể khai thác hoặc lạm dụng.Sâu: Một chương trình tự sao chép, tự truyên truyền, khép kín có thể sử dụng cơ chế nối mạng để lây lan chính nó.

Page 14: Incident Response

Phụ lục F - Tài nguyênAllen, Julia H, The CERT ® Guide to System and Network Security Practices, Addison Wesley, 2001. Bace, Rebecca Gurley, Intrusion Detection, Que, 1999.

Casey, Eoghan, Digital Evidence and Computer Crime, Academic Press, 2000.

Kruse II, Warren and Heiser, Jay, Computer Forensics: Incident Response Essentials, Addison Wesley, 2001.

Mandia, Kevin and Prosise, Chris, Incident Response: Investigating Computer Crime, McGrawHill, 2001.

Marcella Jr., Albert J. (Editor) and Greenfield, Robert S. (Editor), Cyber Forensics: A Field Manual for Collecting, Examining, and Preserving Evidence of Computer Crimes, Auerbach Publications, 2002.

Northcutt, Stephen, Computer Security Incident Handling: Step-by-Step, SANS Press, 2003.

Northcutt, Stephen and Novak, Judy, Network Intrusion Detection (Third Edition), Que, 2002.

Northcutt, Stephen, et al., Inside Network Perimeter Security: The Definitive Guide to Firewalls, Virtual Private Networks (VPNs), Routers, and Intrusion Detection Systems, Que, 2002.

Schiffman, Mike, Hacker’s Challenge: Test Your Incident Response Skills Using 20 Scenarios, McGraw-Hill, 2001.

Schiffman, Mike, et al., Hacker’s Challenge 2: Test Your Network Security and Forensic Skills, McGraw-Hill, 2002.

Schultz, E. Eugene and Shumway, Russell, Incident Response: A Strategic Guide to Handling System and Network Security Breaches, Que, 2002.

Schweitzer, Douglas, Incident Response: Computer Forensics Toolkit, John Wiley and Sons, 2003.

van Wyk, Kenneth and Forno, Richard, Incident Response, O’Reilly and Associates, 2001.

Phụ lục G: Công cụ và tài nguyên trực tuyếnDanh sách dưới đây cung cấp các ví dụ về các công cụ trực tuyến và các nguồn lực có thể hữu ích trong việc thiết lập và duy trì một khả năng ứng phó sự cố.

Các tổ chức khắc phục sự cố:Tổ chức URL

AusCERT-Đội xử lý khẩn cấp máy tính ÚC h t t p: // www .a u s ce r t . or g .au

CCIPS-Tội phạm máy tính và mục sở hữu trí tuệ, Bộ Tư pháp Mỹ

h t t p: // www .c y b ercri m e.g o v

Page 15: Incident Response

CERT ® / CC-CERT ®Trung tâm phối hợp, Đại học Carnegie Mellon

h t t p: // www .cer t . o r g

CERT ® / CC hệ thống báo cáo sự cố h t t ps : / / i rf.cc.ce r t . o rg

CIAC- Cố vấn năng lực máy tính, Bộ Năng lượng Hoa Kỳ

h t t p: // www .ci a c.o r g / c i ac

CERT - Bộ Quốc phòng Mỹ, Ứng cứu máy tính khẩn cấp

h t t p: // www .cer t . m i l

FedCIRC- Trung tâm phản ứng sự cố máy tính Liên bang

h t t p: // www .fe d c i rc . g o v

FedCIRC Hệ thống báo cáo sự cố h t t ps : / / i n c i d e n t r e p o r t . fe d c i rc . g o v

FIRST-Diễn đàn của đội an ninh và khắc phục sự cố h t t p: // www .fi r st . o r g

HTCIA-Hiệp hội Điều tra Tội phạm Công nghệ cao h t t p: // www . h t c i a.o r g

AIP-Phân Tích Thông Tin Bảo Vệ Cơ Sở Hạ Tầng, Bộ An Ninh Nội Địa Mỹ

h t t p: // www . n ip c . g o v

IAIP Mẫu báo cáo sự cố h t t p: // www . n ip c . g o v/ in c i d e n t / c i rr. h t m

IETF Nhóm công tác mở rộng xử lý sự cố (inch) h t t p: // www .i e t f.o r g / h t m l .ch a r t e r s / i n c h c h a r t er . ht m l

InfraGard h t t p: // www . i n fr a g a r d . n et

ISC h t t p: / / i s c. i n c id e n ts . o r g

US-CERT-Đội ứng phó máy tính khẩn cấp Mỹ h t t p: // www . u s -ce r t . g o v

Page 16: Incident Response

Các danh sách xử lý sự cốTên URL

Bugtraq h t t p: // www .se c u r it y f o c us . c o m / arc h i v e / 1 DShield h t t p: // www . d s h i e ld . o r g /p i p er m a il/ li s t Focus-IDS h t t p: // www .se c u r it y f o c us . c o m / arc h i v e / 9 6 Kiểm tra h t t p: // www .se c u r it y f o c us . c o m / arc h i v e / 1 0 4 Các sự cố h t t p: // www .se c u r it y f o c us . c o m / arc h i v e / 7 5 Các xâm nhập h t t p: // c er t . u nis tu t t g a r t .de/ar c h i v e / i n t r u s io n s Phân tích LOG h t t p: // a i r s n arf. s h m oo .co m /p i p er m a il / l o g a n a l y si s

Nguồn kỹ thuậtTên nguồn URL

CERIAS (Trung tâm Giáo dục và Nghiên cứu Thông tin đảm bảo và an ninh) Trang phát hiện xâm nhập

h t t p: // www .cer i a s . p u r d u e.e d u / c o a s t /i nt r u s i o n - detection/welcome.html

CHIHT (Cơ quan thu thập và phân phối thông tin: Công cụ Xử lý cho sự cố)

h t t p: // c h i h t . d f n - ce r t . d e

Phát triển CSIRT, CERT ®/ CC

h t t p: // www .cer t . o r g / c si r t s

CSRC- Trung tâm Tài nguyên an ninh máy tính, NIST

h t t p: // c s rc . n is t . g o v

DShield (hệ thống phân tán phát hiện xâm phạm)

h t t p: // www . d s h i e ld . o rg

Page 17: Incident Response

Tài liệu và liên kết Xử Lý Sự Cố h t t p: // www . h on e y p ot s .n e t /i n c id e n t s / li n k s

Phát hiện xâm phạm FAQ, Viện SANS

h t t p: // w ww .s a ns . o r g/ r e s o u r c e s / i d f a q

Tài liệu và liên kết Phát Hiện Xâm Nhập

h t t p: // www .s a ns . o r g/ r e s o u r c e s / i d f a q

Loganalysis.org h t t p: // www . l og a n a l y sis . o rg

NIJ (Viện Tư pháp) Chương trình tội phạm điện tử

h t t p: // www .ojp . u sd o j .go v / n i j/ s c i e n c e t e c h / e cr i m e.h t m

Dịch vụ NIST h t t p: // www . b o ul d er. n i s t . g o v / ti m efreq/ s e r vi ce / i t s . h t m

Viện SANS - phòng đọc h t t p: // www .s a ns . o r g/ r r

SecurityFocus h t t p: // www .se c u r it y f o c us . c o m

Trung tâm Thông tin Bằng chứng điện tử

h t t p: // www .e- e v i d e n c e.i n f o

Các nguồn thông tin điểm yếu và khai thácTên nguồn URLCERT ® / CC Tư vấn h t tp : / / w w w . ce rt .o r g / ad v i so r i e s

Ghi chú sự cố CERT ® / CCh t tp : / / w w w . ce rt .o r g / i nc i den t _ n o t e s

CERT ® / CC Ghi chú cơ sở dữ liệu dễ bị tổn thương

h t tp : / / w w w . kb . ce rt .o r g / v ul s

CIAC Bản tin và Tư vấn h t tp : / / w w w . ciac . o r g / c g i - b i n / i nd e x / bulle t i n s

Lỗ hổng phổ biến(CVE) h t tp : / / w w w . c v e . mi tr e . o r g

Page 18: Incident Response

ICAT Siêu cơ sở dữ liệu khả năng bị tổn thương h t tp : / / ic a t .n i s t . go v

Bảo vệ cơ sở hạ tầng thông tin Phân tích(IAIP)

h t tp : / / w w w . nipc . go v

Packet Storm h t tp : / / w w w . packe t s t o r ms e cu r i t y . co m

Danh sách SANS / FBI Top 20 h t tp : / / w w w . sans . o r g / to p 2 0

Bảo mật lỗ hổng cơ sở dữ liệu h t tp : / / w w w . secu r i t y f o cu s . c o m / bi d

Các nguồn đào tạoTên nguồn Dạng đào tạo URL

®CERT/CC Xử lý sự cố h t tp : / / w w w . ce rt .o r g / t r a in i n g

Dịch vụ pháp y máy tính Pháp y máy tính h t tp : / / w w w . compu t e r - f o r e n si c . c o m / t r a in i ng . h t m l

Foundstone Ứng phó sự cố, pháp y máy tính h t tp : / / w w w . founds t o ne . co m

Viện Đào Tạo MIS (Misti) Ứng phó sự cố, xâm nhậpphát hiện, pháp y máy tính

h t tp : / / w w w . mis t i . co m

Viện SANS Ứng phó sự cố, xâm nhậpphát hiện, pháp y máy tính

h t tp : / / w w w . sans . o rg

NIST Special Publications

Tên nguồn URLNIST SP 800-28-Hướng dẫnNội dung hoạt động và Mã điện thoại di động

h t t p: // c s rc . n is t . g o v/ p u b l i c a t io n s/ n i s tp u bs / 8 0 0 - 2 8/ s p 8 0 0 - 2 8 . p d f

NIST SP-800-30 Hướng dẫnquản lý rủi ro cho Hệ thống công nghệ thông tin

h t t p: // c s rc . n is t . g o v/ p u b l i c a t io n s/ n i s tp u bs / 8 0 0 - 3 0/ s p 8 0 0 - 3 0 . p d f

NIST SP-800-31 Phát hiện xâm nhập hệ thống

h t t p: // c s rc . n is t . g o v/ p u b l i c a t io n s/ n i s tp u bs / 8 0 0 - 31/sp800-31.pdf

Page 19: Incident Response

NIST SP 800-35-Hướng dẫn dịch vụ an ninh thông tin công nghệ

h t t p: // c s rc . n is t . g o v/ p u b l i c a t io n s/ n i s tp u bs / 8 0 0 - 3 5 / N IS T -S P 8 0 0 - 35 . p d f

NIST SP 800-40- Thủ tục vá lỗ hổng an ninh

h t t p: // c s rc . n is t . g o v/ p u b l i c a t io n s/ n i s tp u bs / 8 0 0 - 4 0/ s p 8 0 0 - 4 0 . p d f

NIST SP 800-41-Hướng dẫn về tường lửa và chính sách tường lửa

h t t p: // c s rc . n is t . g o v/ p u b l i c a t io n s/ n i s tp u bs / 8 0 0 - 4 1/ s p 8 0 0 - 4 1 . p d f

NIST SP 800 - 42 - Hướng dẫn về mạng thử nghiệm an ninh

h t t p: // c sr c . n is t . g o v/ p u b l i c a t io n s/ n i s tp u bs / 8 0 0 - 4 2 / N IS T -S P 8 0 0 - 42 . p d f

NIST SP 800-43- Hướng dẫn quản trị hệ thông cho Windows 2000 Professional

h t t p: // c s rc . n is t . g o v/ i ts ec / g ui d a n c e _ W 2 K p r o . h t m l

NIST SP 800-44-Hướng dẫn về Bảo mật thông tin máy chủ web

h t t p: // c s rc . n is t . g o v/ p u b l i c a t io n s/ n i s tp u bs / 8 0 0 - 4 4/ s p 8 0 0 - 4 4 . p d f

NIST SP 800-45- Hướng dẫn về an ninh thư điện tử

h t t p: // c s rc . n is t . g o v/ p u b l i c a t io n s/ n i s tp u bs / 8 0 0 - 4 5/ s p 8 0 0 - 4 5 . p d f

NIST SP 800 – 48 - An ninh mạng không dây: 802.11, Bluetooth, và các thiết bị cầm tay

h t t p: // c s rc . n is t . g o v/ p u b l i c a t io n s/ n i s tp u bs / 8 0 0 - 4 8 / N IS T _ S P _8 0 0 - 4 8 .p d f

Các nguồn khác

Tên nguồn URLCERT /CC Security Improvement Modules h t t p: // www .cer t . o r g /s ec u r it y- i m p r ov e m e n t

CIO Cyberthreat Response and Reporting

Guidelines

h t t p: // www .c i o .co m / re s ea r c h / s e c u r i t y /i n c i d e n t _ r e s p on s e. p d f

Page 20: Incident Response

Đội ứng phó sự cố bảo mật máy tính (CSIRT) Những câu hỏi thường gặp (FAQ)

h t t p: // www .cer t . o r g / c si r t s/ c s i r t _ f a q . h t m l

Distributed Denial of Service Defense Tactics h t t p: // r az o r. b i nd vi e w . c o m / p u b l i sh / p a p e r s/ D D S A _ D efe n s e . ht m l

Electronic Crime Scene Investigation: A Guide for First Responders

http://www.ojp.usdoj.gov/nij/pubs-sum/187736.htmFAQ: Network Intrusion Detection Systems,

Robert Grahamh t t p: // www .r o b e r t g r a h a m .c o m /p u b s / n e t w o r k - in t r us i o n - d e t e c t i on . ht m l

Handbook for Computer SecurityIncident Response Teams (CSIRTs)

h t t p: // www .cer t . o r g / a rc h iv e / p d f / c s i r t - h a n db o o k . p d f

How to Design a Useful IncidentResponse Policy

h t t p: // www .se c u r it y f o c us . c o m /in f o c u s / 14 6 7

Incident Response: Managing Security at Microsoft

h t t p: // www . m i cr os o f t .co m /t ec h n e t / t re e v i e w /d e fa ul t .a s p ? u r l = / t e c h n e t/ i t s ol u ti o n s/ m si t/s e c u r it y / m si r s ec. a s p

Incident Response Tools for Unix, Part One: System ToolsIncident Response Tools for Unix, Part Two: File-

h t t p: // www .se c u r it y f o c us . c o m /in f o c u s / 16 7 9 h t t p: // www .se c u r it y f o c us . c o m /in f o c u s / 17 3 8

Managing the Threat of Denial-of-Service Attacks h t t p: // www .cer t . o r g / a rc h iv e / p d f / M a n a g i ng _ D o S. p d f

Responding to Intrusions h t t p: // www .s e i .c m u .edu / p u b /d o c u m e nt s / s i m s/ pd f /s i m 006 . p d f

RFC 2350: Expectations for Computer SecurityIncident Response

h t t p: // www .i e t f.o r g / r f c / rf c 2 3 5 0 . t x t

RFC 3067: TERENA’s Incident Object Description and Exchange Format Requirements

h t t p: // www .i e t f.o r g / r f c / rf c 3 0 6 7 . t x t

RFC 3227: Guidelines for Evidence Collection and Archiving

h t t p: // www .i e t f .o r g / r f c / rf c 3 2 2 7 . t x t

Page 21: Incident Response

Sample Incident Handling Forms, SANS Institute h t t p: // www .s a ns . o r g /i n c i d e n t f o r m s

A Short Narrow Look at the History and Purpose

of Information Sharing and Analysis Centers

h t t ps : / / www .i t - i s ac. o r g / i s ac i n f o wht pp r . p h p

Staffing Your CSIRT—What Basic Skills Are

Needed?

http://www.cert.org/csirts/csirt-staffing.html

State of the Practice of Computer Security Incident Response Teams

h t t p: // www .cer t . o r g / a rc h iv e / p d f / 0 3 t r 0 0 1 . p d f

System Security h t t p: // www .li n u x- m a g .co m / 2 0 0 0 - 1 0/ s e c u r i t y _ 0 1 . h t m l

A Taxonomy of DDoS Attacks and DdoS Defense Mechanisms

h t t p: / / l a s r.cs . u c l a. e d u / dd o s / u c l a _ t e c h _ re po r t _0 2 00 18 . p d f

Tài nguyên kiến thức tham khảo

Tên nguồn URLIANA Protocol Numbers and Assignment Services

h t t p: // www .i a n a. o r g/ nu m b er s . ht m l

Các thông số hệ thống tên miền h t t p: // www .i a n a. o r g/ a s si gn m e n t s /d n s - p ar a m e t ers

Loại số ICMP h t t p: // www .i a n a. o r g/ a s si gn m e n t s / i c m p - p a ra m e t ers

Địa chỉ Internet Multicast h t t p: // www .i a n a. o r g/ a s si gn m e n t s/ m ul t i c a s t - a dd r e s s e s

Không gian địa chỉ ipv4 h t t p: // www .i a n a. o r g/ a s si gn m e n t s / i pv 4 - a d d re s s - s p a c e

Số giao thức IP h t t p: // www .i a n a. o r g/ a s si gn m e n t s / p r o t o c o l - nu m b ers

Page 22: Incident Response

Số phiên bản IP h t t p: // www .i a n a. o r g/ a s si gn m e n t s / v e r s io n - nu m b ers

Số cổng h t t p: // www .i a n a. o r g/ a s si gn m e n t s /p o r t - nu m b ers

Các thông số syslog h t t p: // www .i a n a. o r g/ a s si gn m e n t s / s y sl o g - p ara m e t ers

Tiêu đề TCP Flags h t t p: // www .i a n a. o r g/ a s si gn m e n t s / t c p - h e a d e r -f l a g s

Lựa chọn số TCP h t t p: // www .i a n a. o r g/ a s si gn m e n t s / t c p - p ar a m e t ers

RFC của IETF cho giaothức thông thường (DNS, FTP, HTTP và SMTP)

h t t p: // www .i e t f.o r g / r f c.h t m l

RFC 959: File TransferProtocol (FTP)

h t t p: // www .i e t f.o r g / r f c / rf c 0 9 5 9 . t x t

RFC 1034: Tên miền- khái niệm và cơ sở

h t t p: // www .i e t f.o r g / r f c / rf c 1 0 3 4 . t x t

RFC 1035: Tên miền- Thực hiện và Thông số kỹ thuật

h t t p: // www .i e t f.o r g / r f c / rf c 1 0 3 5 . t x t

RFC 2065: An ninh phần mở rộng hệ thống tên miền

h t t p: // www .i e t f.o r g / r f c / rf c 2 0 6 5 . t x t

RFC 2228: FTP bảo mật mở rộng h t t p: // www .i e t f.o r g / r f c / rf c 2 2 2 8 . t x t

RFC 2616: HTTP/1.1 h t t p: // www .i e t f.o r g / r f c / rf c 2 6 1 6 . t x t

RFC 2617: HTTP xác thực: cơ bản và Digest truy cập xác thực

h t t p: // www .i e t f.o r g / r f c / rf c 2 6 1 7 . t x t

RFC 2821: SMTP h t t p: // www .i e t f.o r g / r f c / rf c 2 8 2 1 . t x t

Page 23: Incident Response

RFC 2822: IMF h t t p: // www .i e t f.o r g / r f c / rf c 2 8 2 2 . t x t

RFC 2965: Cơ chế quản lý Nhà nước HTTP

h t t p: // www .i e t f.o r g / r f c / rf c 2 9 6 5 . t x t

Danh sách các cổng h t t p: // www . n e o h a ps i s .co m /n e o l a b s / n e o - p o r t s /

Kiến thức cơ sở mạng ICE Cổng h t t p: // www .iss . n e t/ s e c u r it y _ c e nt e r / a d vi c e /E x p l o i ts / P o r t s

Cơ sở dữ liệu cổng Internet h t t p: // www . p o r ts db . o rg

Ví dụ về phần mềm phát hiện và phân tích sự cố miễn phí và mã nguồn mở

Tên phần mềm Dạng phần mềm URLArgus Hệ thống và

mạng lưới giám sáth t t p: // a r gu s .t c p4 m e.c o m

Bro Phát hiện xâmnhập dựa trên mạng

h t t p: // www .i c i r.o r g / v er n /b r o - i n f o . ht m l

Chkrootkit Phát hiện rootkit h t t p: // www .c h k r o ot k i t .o r g

EtherApe Giám sát mạngđồ họa

h t t p: // e t h er a p e . s o u rc e f o r g e. n et

Ethereal phân tích giaothức

h t t p: // www .e t h er e a l . c o m

paudit Giám sát hoạtđộng mạng

h t t p: / / i p a ud it . s o u r c e f o r g e.n e t

IPTraf Tiện ích thốngkê mạng

h t t p: / / i p t r a f.s e ul . o r g

Kismet 802.11 khôngdây sniffer mạng

h t t p: // www . k is m e t wi re l e ss . n e t

Kiwi Syslog Daemon Daemon syslogcho Windows h t t p: // www . k i w is y s lo g .com

NetStumbler 802.11 Nghe lén mạng không dây

h t t p: // www .n e t st u m bl er.c o m

Page 24: Incident Response

Snort Phát hiện xâmnhập dựa trên mạng

h t t p: // www . s no r t . o rg

Swatch Giám sát tập tin nhật kí

h t t p: / / s w a t c h . s o u r c e f o r g e.n e t

TCPDump Packet sniffer h t t p: // www .t c p d u m p .org

TCP Trace Phân tích filetcpdump

h t t p: // www .t c pt r ace . o r g /i n d e x . ht m l

The Coroner’s Toolkit pháp y máy tính h t t p: // www . p o r c u pin e.o r g/ f o r e n si c s / t c t . h t m l

The Sleuth Kit pháp y máy tính h t t p: // www .sle u t h k it . o r g/ sl e u t hk i t / in d e x . p h p

WinDump packet sniffer h t t p: // w i nd u m p .p o l i to .it

Phụ lục H - Câu hỏi thường gặpNgười sử dụng, quản trị hệ thống, nhân viên an ninh thông tin, và những người khác trong tổ chức có thể có thắc mắc về ứng phó sự cố. Sau đây là những câu hỏi thường gặp (FAQ) về ứng phó sự cố. Tổ chức được khuyến khích để tùy chỉnh Trợ giúp này và làm cho nó có sẵn cho cộng đồng người dùng của họ.

1. Sự cố là gì?Nói chung, một sự cố là vi phạm chính sách bảo mật máy tính, chính sách sử dụng chấp nhận được, hoặc thực hành bảo mật máy tính tiêu chuẩn. Ví dụ về các sự cố là:

Một tấn công từ chối dịch vụ phân tán chống lại một máy chủ web công cộng Một con sâu lây nhiễm hàng trăm máy trạm trên mạng và có thể gây sập mạng Một kẻ tấn công giành quyền truy cập từ xa mức độ admin đến một máy chủ e-mail Một người dùng tải các công cụ bẻ mật khẩu Một người dùng hủy hoại trang web công cộng của một tổ chức khác.

2. Xử lý sự cố là gì? Xử lý sự cố là quá trình phát hiện và phân tích sự cố và hạn chế của sự cố có hiệu lực. Ví dụ, nếu một kẻ tấn công đột nhập vào hệ thống thông qua Internet, quá trình xử lý sự cố sẽ phát hiện các vi phạm an ninh. Sau đó người xử lý sự cố sẽ phân tích dữ liệu và xác định mức độ nghiêm trọng của cuộc tấn công. Sự cố sẽ được ưu tiên, và người xử lý sự cố sẽ có hành động để đảm bảo rằng sự tiến độ của sự cố phải dừng lại và hệ thống bị ảnh hưởng trở lại hoạt động bình thường càng sớm càng tốt.3. Ứng phó sự cố là gì? Các thuật ngữ "xử lý sự cố" và "ứng phó sự cố" là đồng nghĩa trong tài liệu này.4. Một đội ứng phó sự cố là gì? Một đội ứng phó sự cố (còn được gọi là một đội ứng cứu sự cố bảo mật máy tính [CSIRT]) có trách nhiệm cung cấp dịch vụ ứng phó sự cố cho một phần hoặc tất cả của một tổ chức. Đội nhận được thông tin về sự cố có thể, điều tra chúng, và có hành động để đảm bảo rằng những thiệt hại do sự cố được giảm thiểu. Trong một số tổ chức, đội ứng phó sự cố là chính thức, nhóm chuyên trách; ở những tổ chức khác, các thành viên đội ứng phó sự cố là kéo từ công việc chức năng khác khi cần thiết. Một số tổ chức không có đội ứng phó sự cố bởi vì họ thuê từ bên ngoài nhiệm vụ ứng phó sự cố.5 . Dịch vụ gì đội ứng phó sự cố cung cấp?Các dịch vụ đặc biệt mà các đội ứng phó sự cố cung cấp khác nhau giữa các tổ chức. Ngoài việc thực hiện xử lý sự cố, một đội thường phân phối các khuyến cáo liên quan đến các mối đe dọa mới, giáo dục và nâng cao nhận thức của người sử dụng và nhân viên kỹ thuật về vai trò của họ trong phòng ngừa và xử lý sự cố. Nhiều

Page 25: Incident Response

đội cũng chịu trách nhiệm về hệ thống giám sát và quản lý phát hiện xâm nhập . Một số đội thực hiện dịch vụ bổ sung , chẳng hạn như kiểm toán và thử nghiệm thâm nhập .6 . Người nên được báo cáo sự cố?Tổ chức phải thiết lập danh bạ rõ ràng( POC) để báo cáo sự cố nội bộ. Một số tổ chức sẽ cơ cấu khả năng ứng phó sự cố của họ mà tất cả các sự cố được báo cáo trực tiếp cho đội ứng phó sự cố, trong khi những người khác sẽ sử dụng cấu trúc hỗ trợ hiện có, chẳng hạn như phòng hỗ trợ công nghệ thông tin ( IT ), cho một POC ban đầu. Các tổ chức nên nhận ra các bên bên ngoài, chẳng hạn như các đội ứng phó sự cố khác , sẽ báo cáo một số sự cố. Cơ quan liên bang được yêu cầu theo luật định để báo cáo tất cả các sự cố cho Trung tâm ứng phó sự cố máy tính liên bang (FedCIRC ).7. Báo cáo sự cố thế nào?Hầu hết các tổ chức có nhiều phương pháp để báo cáo sự cố. Phương pháp báo cáo khác nhau có thể thích hợp hơn như kết quả của sự thay đổi trong các kỹ năng của người báo cáo các hoạt động, tính cấp bách của vụ việc, và sự nhạy cảm của vụ việc. Một số điện thoại hoặc số máy nhắn tin nên được thiết lập cho trường hợp báo cáo khẩn cấp. Một địa chỉ e -mail có thể được cung cấp cho báo cáo sự cố chính thức, trong khi một mẫu dựa trên web có thể hữu ích trong báo cáo sự cố chính thức. Thông tin nhạy cảm có thể được cung cấp cho các đội bằng cách gửi fax đến một máy trong một khu vực an toàn hoặc bằng cách sử dụng một khóa công khai được công bố bởi đội để mã hóa tài liệu.8 . Những thông tin cần được cung cấp khi báo cáo một sự cố?Các thông tin chính xác hơn thì tốt hơn. Ví dụ, nếu một máy trạm xuất hiện để có bị nhiễm mã độc hại , báo cáo sự cố nên bao gồm các dữ liệu sau đây:+ Tên của người sử dụng, ID người sử dụng và thông tin liên lạc (ví dụ, số điện thoại , địa chỉ e-mail)+ Vị trí, số model, số serial, tên máy và địa chỉ IP của máy trạm+ Ngày và thời gian mà sự việc xảy ra+ Một lời giải thích từng bước những gì đã xảy ra, bao gồm cả những gì đã được thực hiện để máy trạm sau khi nhiễm bệnh đã được phát hiện. Lời giải thích này phải được trình bày chi tiết, bao gồm các từ ngữ chính xác của thông điệp, như những hiển thị bởi bằng các mã độc hại hoặc bởi những cảnh báo phần mềm chống virus .9 . Làm thế nào đội ứng phó sự cố phản ứng nhanh chóng với một báo cáo sự cố ?Thời gian phản ứng phụ thuộc vào nhiều yếu tố , chẳng hạn như các loại sự cố, mức độ quan trọng của các tài nguyên và dữ liệu bị ảnh hưởng, mức độ nghiêm trọng của sự cố, cấp độ phục vụ (SLA) hiện có cho các nguồn tài nguyên bị ảnh hưởng, thời gian và ngày trong tuần, và các sự cố khác nhóm đdang xử lý . Nói chung, ưu tiên cao nhất là xử lý sự cố có khả năng gây ra thiệt hại nhiều nhất cho tổ chức hoặc tổ chức khác.10 . Khi nào một người có liên quan với một sự cố nên liên hệ với thực thi pháp luật ?Thông tin liên lạc với các cơ quan thực thi pháp luật cần phải được khởi xướng bởi các thành viên đội ứng phó sự cố, các giám đốc thông tin (CIO) hoặc được chỉ định chính thức khác: người sử dụng, quản trị hệ thống, chủ sở hữu hệ thống , và các bên liên quan khác không nên bắt đầu liên lạc. Các đội ứng phó sự cố nên liên hệ với thực thi pháp luật tại thời điểm thích hợp theo các chính sách và thủ tục đã thành lập .11. Người phát hiện ra một hệ thống đã bị tấn công nên làm gì?Người đó nên dừng lại ngay lập tức việc sử dụng hệ thống và liên hệ với đội ứng phó sự cố. Người đó có thể cần phải hỗ trợ cho việc xử lý sự cố ban đầu, ví dụ: ngắt kết nối cáp mạng từ hệ thống đã bị tấn công hoặc giám sát vật lý hệ thống cho đến khi người xử lý sự cố đến nơi để bảo vệ bằng chứng trên hệ thống.12. Một người nào đó nên làm gì khi nhận được thư rác?Người đó nên chuyển tiếp thư rác đến địa chỉ e-mail mà tổ chức đã chỉ định cho báo cáo thư rác. Số liệu thống kê tổng hợp trên thư rác có thể được sử dụng để biện minh cho các biện phát chống thư rác bổ sung. Số liệu thống kê cũng sẽ được cung cấp cho các tổ chức báo cáo sự cố để nghiên cứu khuynh hướng trong sự cố an ninh máy tính. Người đó không nên trả lời tin nhắn thư rác bằng bất kỳ cách nào, bao gồm yêu cầu xoá khỏi danh sách gửi thư, bởi vì điều này sẽ xác nhận tới người gửi rằng địa chỉ e -mail là hợp lệ và chủ động sử dụng13. Một người nào đó nhận được một cảnh báo từ một người bạn về một loại virus mới nên làm gì?Người đó nên kiểm tra một trang web vi rút lừa bịp để xem các virus mới là hợp pháp hay một trò lừa bịp. Nhiều cảnh báo virus phân phối thông qua e -mail là trò lừa đảo, và một số các hướng dẫn được cung cấp trong trò lừa đảo có thể gây thiệt hại cho hệ thống nếu họ làm theo. Trang web nhà phân phối chống vi rút thường chứa các thông tin về các virus chơi khăm; Trang Computer Incident Advisory Capability (CIAC)

Hoaxbusters là một nguồn tốt Một người vẫn còn nghi ngờ về tính xác thực của một cảnh báo virus nên liên hệ với bộ phận hỗ trợ để được giúp đỡ thêm.

Page 26: Incident Response

14.Một người nào đó nên làm gì khi được các phương tiện truyền thông đại chúng liên lạc về sự cố?Một người đã là một phần của ứng phó sự cố có thể trả lời câu hỏi của giới truyền thông phù hợp với chính sách của tổ chức liên quan đến sự cố và các bên bên ngoài. Nếu người đó không đủ điều kiện để đại diện cho tổ chức thảo luận về vụ việc, người không nên có bình luận về vụ việc, ngoài việc chuyển cuộc gọi cho văn phòng quan hệ công chúng. Điều này sẽ cho phép các văn phòng quan hệ công chúng cung cấp chính xác và nhất quán thông tin cho các phương tiện truyền thông và công chúng.Phụ lục I - Các bước xử lý khủng hoảngPhụ lục I liệt kê các bước chính cần được thực hiện khi một chuyên gia kỹ thuật cho rằng một sự cố nghiêm trọng đã xảy ra và tổ chức không có sẵn khả năng ứng phó sự cố. Cung cấp này như là một tài liệu tham khảo cơ bản về những gì cần làm cho những người đang phải đối mặt với một cuộc khủng hoảng và không có thời gian để đọc toàn bộ tài liệu này.

1. Mọi thứ tài liệu. Nỗ lực này bao gồm mọi hành động được thực hiện, tất cả các mảnh của bằng chứng, và mỗi cuộc trò chuyện với người sử dụng, chủ sở hữu hệ thống, và những người khác liên quan đến vụ việc. 2. Tìm một đồng nghiệp có thể cung cấp hỗ trợ. Xử lý vụ việc sẽ dễ dàng hơn nhiều nếu hai hoặc nhiều người làm việc cùng nhau. Ví dụ, một người có thể thực hiện hành động trong khi người kia tìm tài liệu đó.3 . Phân tích các bằng chứng để xác nhận rằng một sự cố đã xảy ra. Thực hiện nghiên cứu bổ sung khi cần thiết (ví dụ, công cụ tìm kiếm Internet, tài liệu phần mềm) để hiểu rõ hơn bằng chứng. Tiếp cận với các chuyên gia kỹ thuật khác trong tổ chức để được giúp đỡ thêm.4 . Thông báo cho những người thích hợp trong tổ chức nếu có vẻ là một sự cố có xảy ra . Điều này sẽ bao gồm các giám đốc thông tin (CIO), người đứng đầu thông tin an ninh, và người quản lý an ninh nội bộ. Sử dụng quyết định khi thảo luận về các chi tiết của vụ việc với những người khác; chỉ nói cho những người cần phải biết và sử dụng các cơ chế truyền thông có hợp lý an toàn. (Nếu kẻ tấn công đã xâm nhập các dịch vụ email, không gửi e-mail về vụ việc).5 . Dừng sự cố nếu nó vẫn còn đang được tiến hành. Cách phổ biến nhất để làm điều này là để ngắt kết nối hệ thống bị ảnh hưởng khỏi mạng. Trong một số trường hợp , tường lửa và cấu hình bộ định tuyến có thể cần phải được sửa đổi để ngăn chặn lưu lượng mạng là một phần của một sự cố , chẳng hạn như một tấn công từ chối dịch vụ (DOS).6. Bảo tồn bằng chứng từ vụ việc. Tạo bản sao lưu (tốt hơn là sao lưu ảnh đĩa, không sao lưu tập tin hệ thống ) của hệ thống bị ảnh hưởng. Làm bản sao của tập tin nhật kí có chứa các bằng chứng liên quan đến sự cố.7. Quét sạch tất cả các tác động của vụ việc. Nỗ lực này bao gồm nhiễm mã độc hại, vật liệu không phù hợp (ví dụ , phần mềm vi phạm bản quyền ) , các tập tin Trojan horse, và bất kỳ thay đổi khác được thực hiện tới hệ thống xảy ra sự cố. Nếu một hệ thống đã bị xâm nhập hoàn toàn , xây dựng lại nó từ đầu hoặc khôi phục lại nó từ một bản sao lưu tốt được biết đến.8. Xác định và giảm thiểu tất cả các lỗ hổng đã được khai thác . Sự cố có thể xảy ra bằng cách tận dụng các lỗ hổng trong hệ điều hành hoặc các ứng dụng. Nó là rất quan trọng để xác định các lỗ hổng đó và loại bỏ hoặc giảm thiểu chúng để vụ việc không tái diễn.9. Xác nhận rằng các hoạt động đã được khôi phục lại bình thường. Hãy chắc chắn rằng dữ liệu, ứng dụng, và các dịch vụ khác bị ảnh hưởng bởi vụ việc đã được trả lại cho các hoạt động bình thường.10. Tạo một báo cáo cuối cùng . Báo cáo này nên ghi chi tiết quá trình xử lý sự cố. Nó cũng nên cung cấp một bản tóm tắt về những gì đã xảy ra và khả năng ứng phó sự cố chính thức sẽ giúp để xử lý tình hình, giảm thiểu rủi ro, và hạn chế thiệt hại nhanh hơn.

Page 27: Incident Response