Chuẩn bị

Trong phần này, chúng ta sẽ thảo luận chi tiết về cách chuẩn bị cho tổ chức của bạn ra mắt và chạy thành công chương trình thông báo lỗ hổng, bao gồm lời khuyên thiết thực về cách bổ sung những lỗ hổng mà bạn đã xác định được.

Tìm lỗi

Tìm lỗi

Việc tăng cường chương trình bảo mật hiện tại của bạn với các nhà nghiên cứu bảo mật bên ngoài là một cách hay để tìm ra các vấn đề phức tạp và che giấu lỗ hổng. Tuy nhiên, việc sử dụng VDP để tìm các vấn đề bảo mật cơ bản có thể phát hiện được trong nội bộ sẽ gây lãng phí tài nguyên.

Quản lý thành phần

Khi nói đến việc tìm lỗi, cách duy nhất để biết nên bắt đầu từ đâu là nếu bạn nắm rõ những nội dung trong đó. Bạn có thể mua 100 công cụ bảo mật, nhưng điều đó sẽ không có gì khác biệt nếu các nhóm đứng trước các ứng dụng, hệ thống và dịch vụ đột xuất mà bạn không hay biết, đặc biệt là khi bạn không có cách phát hiện và thực hiện việc đánh giá bảo mật đối với những tài sản này. Liên hệ với các cá nhân và nhóm chịu trách nhiệm giúp thiết lập các ứng dụng, hệ thống và dịch vụ mới để xem liệu họ đã có quy trình tạo và duy trì khoảng không quảng cáo về những gì đang diễn ra cũng như người sở hữu chúng hay chưa. Nếu chưa có quy trình hiện tại, thì đây là cơ hội tuyệt vời để cộng tác với các nhóm này nhằm xây dựng một quy trình. Tốt nhất là bạn nên nắm được các thành phần của tổ chức khi bắt đầu xác định khu vực dễ bị tấn công. Trong quá trình này, nhóm bảo mật sẽ tham gia vào việc phát triển việc triển khai cơ sở hạ tầng mới để đưa ra đánh giá bảo mật. Bạn nên có kho hàng rộng lớn về tài sản và chủ sở hữu. Loại khoảng không quảng cáo này rất hữu ích khi áp dụng các bản vá mới yêu cầu một số hệ thống phải tạm thời ngừng hoạt động. Công cụ này cung cấp sơ đồ lộ trình về các cá nhân hoặc nhóm cần được thông báo và những hệ thống bị ảnh hưởng. Việc áp dụng quy trình quản lý tài sản hiệu quả giúp đảm bảo chủ sở hữu được xác định sớm trong quy trình, được cập nhật thường xuyên và tất cả hệ thống trên tổ chức đều hoạt động như dự kiến.

Ngoài việc chủ động quản lý tài sản, hãy cân nhắc những biện pháp phản ứng mà bạn có thể triển khai để xác định những tài sản thuộc về tổ chức của bạn nhưng bị bỏ sót trong các quy trình quản lý tài sản chuẩn. Trong đó có thể bao gồm cả việc sử dụng cùng một quy trình "thăm dò" được các nhà nghiên cứu bảo mật tham gia vào VDP và các chương trình tìm lỗi nhận thưởng. Ví dụ: bạn có thể tận dụng các công cụ nguồn mở và miễn phí để quét và liệt kê các dải IP hoặc miền giao diện Internet có thể thuộc về tổ chức của bạn. Khi tìm kiếm tiền thưởng lỗi trên Google, bạn sẽ đưa ra nhiều mẹo và thủ thuật giúp xác định tài sản mà tổ chức mà bạn chưa biết.

Quét lỗ hổng cơ bản

Giờ đây, khi bạn đã có nền tảng vững chắc về nơi bạn cần tìm các vấn đề về bảo mật, hãy cùng tìm hiểu cách bạn thực sự làm điều đó. Có nhiều cấp độ chuyên sâu mà bạn có thể xem xét tuỳ thuộc vào tài nguyên của tổ chức của bạn. Tuy nhiên, bạn cần tìm được sự cân bằng giữa những nỗ lực bảo mật nội bộ của mình và cộng đồng tấn công bên ngoài thông qua chương trình thông báo lỗ hổng. Sự cân bằng này là khác nhau cho mỗi tổ chức, tuỳ thuộc vào tài nguyên có sẵn.

Chọn công cụ

Có nhiều công cụ giúp bạn xác định lỗ hổng. Một số công cụ quét lỗ hổng được cung cấp miễn phí, trong khi một số công cụ khác có tính phí. Việc xác định công cụ nên chọn phụ thuộc vào nhu cầu cá nhân của bạn.

  • Các yêu cầu của tổ chức bạn
  • Mức độ mà mỗi công cụ đáp ứng các yêu cầu này
  • Liệu lợi ích của công cụ mang lại nhiều hơn chi phí (về mặt tài chính và việc triển khai).

Bạn có thể dùng mẫu yêu cầu này (OpenDocument .ods, Microsoft Excel .xlsx) để đánh giá nhiều công cụ theo yêu cầu của bạn. Một số yêu cầu mẫu được đưa vào mẫu, nhưng bạn nên thảo luận với các nhóm bảo mật, CNTT và kỹ thuật để điều chỉnh các tính năng bắt buộc. Ít nhất thì trước khi triển khai một chương trình thông báo lỗ hổng, bạn nên quét lỗ hỏng bảo mật đối với mọi thành phần có tiếp xúc với bên ngoài (chẳng hạn như trang web, API, ứng dụng di động). Điều này giúp bạn tìm thấy và khắc phục các lỗ hổng dễ phát hiện trước khi mời các nhà nghiên cứu bảo mật bên ngoài kiểm thử các tài sản và dịch vụ này.

Thiết lập tính năng quét

Tính năng tự động quét lỗ hổng bảo mật có thể tìm thấy rất nhiều vấn đề, nhưng cũng có thể tạo ra kết quả dương tính giả. Đó là lý do tại sao bạn cần có tài nguyên để xác thực kết quả trước khi chia sẻ với các nhóm chịu ảnh hưởng. Bạn cần triển khai các quy trình để đảm bảo các lượt quét được chạy thường xuyên và thực sự giải quyết được kết quả của các lượt quét này. Mỗi tổ chức có thể có những thay đổi khác nhau, nhưng ít nhất bạn cần xác định:

  • Tần suất quét
    • Liên tục
    • Hằng tuần
    • Hằng tháng
  • Những thành phần đang được quét
  • Thông tin xác thực
    • Quét xác thực so với quét chưa xác thực
    • (gợi ý: nếu bạn không quét bằng thông tin xác thực, thì nhà nghiên cứu bảo mật sẽ kiểm tra thông tin xác thực khi bạn bắt đầu VDP, thì có thể bạn sẽ thấy số lượng lỗ hổng bảo mật tăng đột biến)
  • Vai trò và trách nhiệm
    • Xác định các thành viên trong nhóm chịu trách nhiệm chạy quá trình quét
    • Thiết lập chế độ xoay vòng nếu cần
  • Quét kết quả
    • Xác minh kết quả quét
    • Gửi lỗi cho các lỗ hổng đã xác minh
    • Xác định chủ sở hữu để sửa lỗi
    • Liên hệ với chủ sở hữu về biện pháp khắc phục

Chúng ta sẽ tìm hiểu chi tiết hơn về cách đảm bảo các vấn đề bảo mật đã xác định được khắc phục trong phần Sửa lỗi ở phần sau của hướng dẫn này.

Quy trình đánh giá bảo mật

Mặc dù quét lỗ hổng là một cách hiệu quả để chủ động xác định các vấn đề bảo mật trong tổ chức của bạn, nhưng việc triển khai các quy trình đánh giá bảo mật có thể giúp ngăn chặn việc phát hiện các lỗ hổng bảo mật ngay từ đầu. Trong phạm vi của hướng dẫn này, thuật ngữ đánh giá bảo mật dùng để chỉ mọi tình huống kích hoạt quá trình xem xét thủ công của một thành viên trong nhóm bảo mật. Thông thường, điều này bao gồm việc có quyền chặn một thay đổi nếu thay đổi đó bị cho là quá rủi ro. Nếu nhóm bảo mật của bạn không có khả năng ngăn chặn những thay đổi có tính rủi ro, thì bạn vẫn cần có sẵn các quy trình để ghi nhận rủi ro. Điều này có thể giúp đảm bảo bất kỳ ai thúc đẩy thay đổi đều hiểu rõ rủi ro liên quan và chủ động chấp nhận rủi ro đó.

Tiêu chí đánh giá bảo mật

Khi nào nên đánh giá bảo mật? Việc tạo một bộ tiêu chí kích hoạt quy trình xem xét bảo mật giúp đảm bảo rằng mọi người đều có ý kiến giống nhau. Dưới đây là một số ví dụ về các trường hợp có thể kích hoạt quy trình đánh giá bảo mật.

  • Đề xuất chức năng mới liên quan đến dữ liệu nhạy cảm của người dùng
    • Một tính năng mới cho phép người dùng chia sẻ vị trí của mình trên bản đồ
    • Yêu cầu người dùng cung cấp thông tin có khả năng nhạy cảm, chẳng hạn như địa chỉ nhà riêng, ngày sinh hoặc số điện thoại của họ
  • Cập nhật chính cho các chức năng hiện có
    • Lấy dữ liệu người dùng hiện có và sử dụng theo cách mới mà có thể người dùng không mong đợi nếu không cho họ cơ hội chọn không tham gia
    • Thay đổi đối với bất kỳ tính năng nào liên quan đến việc xác thực, uỷ quyền và quản lý phiên
  • Thay đổi đối với môi trường sản xuất của công ty
    • Thay đổi về cấu hình mạng, đặc biệt là những thay đổi có thể dẫn đến việc để lộ dịch vụ ra bên ngoài
    • Cài đặt phần mềm mới để xử lý dữ liệu nhạy cảm của người dùng mà nếu bị xâm phạm có thể gián tiếp được sử dụng để truy cập vào dữ liệu nhạy cảm của người dùng
    • Thiết lập các hệ thống hoặc dịch vụ mới
  • Tương tác với nhà cung cấp mới hoặc thay đổi cách bạn làm việc với nhà cung cấp hiện tại
    • Giới thiệu một nhà cung cấp mới chuyên xử lý dữ liệu nhạy cảm của người dùng
    • Những thay đổi về cách bạn làm việc với một nhà cung cấp hiện tại, dẫn đến việc nhà cung cấp này phải xử lý dữ liệu nhạy cảm của người dùng

Đây chưa phải danh sách đầy đủ, nhưng sẽ gợi ý cho bạn về những thay đổi nào cần phải trải qua quy trình đánh giá bảo mật. Khi bạn xác định các tiêu chí cần thực hiện và không cần đánh giá bảo mật, hãy trao đổi với các bên liên quan chính trong tổ chức để đảm bảo:

  • Các bên liên quan có cơ hội xem xét và đưa ra ý kiến phản hồi về tiêu chí
  • Các bên liên quan đồng ý với tiêu chí
  • Các bên liên quan đồng ý chủ động yêu cầu đánh giá bảo mật

Hãy ghi lại tiêu chí này, cũng như cách yêu cầu đánh giá bảo mật (ví dụ: gửi lỗi vào hàng đợi mà nhóm bảo mật theo dõi) để giúp tổ chức của bạn dễ dàng tuân thủ quy trình này nhất có thể.

Cung cấp nguồn nhân lực cho quy trình đánh giá bảo mật

Không giống như quy trình quét tự động, quy trình đánh giá bảo mật có thể tốn nhiều tài nguyên hơn để thực hiện. Mỗi nhóm bảo mật chỉ có rất nhiều thời gian trong ngày để hoàn thành vô số công việc, vì vậy, bạn cần ước tính số lần đánh giá bảo mật có thể được tạo dựa trên các tiêu chí của mình. Nếu bạn nhận thấy nhóm của mình bị quá tải và bị tụt lại phía sau, những người đang chờ các tính năng ra mắt sẽ cảm thấy khó chịu với nhóm bảo mật. Điều này có thể dẫn đến sự chuyển đổi về văn hoá trong tổ chức, khiến nhóm bảo mật bị coi là một người chặn thay vì đối tác. Nếu quy trình đánh giá bảo mật không hiệu quả, nhiều cá nhân và nhóm sẽ cố gắng bỏ qua hoàn toàn. Nếu nguồn lực eo hẹp, hãy cân nhắc nới lỏng các tiêu chí yêu cầu đánh giá bảo mật và sẵn sàng chấp nhận thêm một số rủi ro tồn đọng khác. Nếu sự cố xảy ra do thiếu nguồn lực để đánh giá bảo mật, thì điều này sẽ giúp chứng minh cho nhu cầu có thêm tài nguyên bảo mật.

Thực hiện đánh giá bảo mật

Khi quyết định xem nên thực hiện đánh giá bảo mật nào và cách thực hiện chúng, bạn cần có một hàng đợi được ưu tiên. Tạo một phương thức chuẩn để những người khác trong tổ chức của bạn yêu cầu đánh giá bảo mật với bất kỳ thông tin nào bạn cần để ưu tiên xem xét một cách thích hợp. Ví dụ: hãy cân nhắc tạo một bảng câu hỏi về các mục như bản chất của thay đổi, bao gồm cả bản tóm tắt ngắn gọn về thay đổi và loại dữ liệu người dùng có thể bị ảnh hưởng. Bạn có thể tự động phân loại các bản đánh giá bảo mật tiềm ẩn thành các thay đổi có mức độ rủi ro cao, trung bình hoặc thấp dựa trên câu trả lời cho các câu hỏi này. Nếu một thay đổi có rủi ro cao, bạn có thể cần phải thực hiện quy trình đánh giá bảo mật chuyên sâu hơn. Nếu một thay đổi có ít rủi ro hơn, thì bạn có thể triển khai quy trình xem xét bảo mật đơn giản hơn để giảm bớt nguồn lực cần thiết và tăng tốc quy trình, từ đó hỗ trợ hoạt động kinh doanh hiệu quả hơn. Cân nhắc thiết lập chế độ xoay vòng trong nhóm để chịu trách nhiệm quản lý hàng đợi đánh giá bảo mật, đảm bảo rằng các thành viên trong nhóm tiếp tục xem xét bảo mật mới và theo dõi tiến trình đánh giá bảo mật hiện có. Quy trình đánh giá bảo mật thực tế sẽ khác nhau tuỳ thuộc vào nội dung được kiểm tra. Ví dụ: một tính năng mới trong ứng dụng di động của bạn có thể yêu cầu một kỹ sư bảo mật xem xét mã và tìm kiếm các lỗ hổng bảo mật tiềm ẩn. Phần mềm mới đang được cài đặt có thể cần được xem xét để đảm bảo rằng chế độ kiểm soát quyền truy cập được thiết lập phù hợp. Việc làm việc với nhà cung cấp bên ngoài có thể trình bày một quy trình hoàn toàn khác. Để tham khảo, hãy đọc Bảng câu hỏi đánh giá bảo mật dành cho nhà cung cấp của Google.

Sửa lỗi

Việc tìm lỗi rất quan trọng, nhưng tính bảo mật chỉ cải thiện sau khi các lỗi đó được khắc phục. Biết được rủi ro nào đang tồn tại với tổ chức là tốt, nhưng việc có thể giải quyết rủi ro đó một cách hiệu quả sẽ tốt hơn.

Quản lý lỗ hổng

Lỗ hổng bảo mật đến từ nhiều nguồn lực, trong đó có các nỗ lực nội bộ (ví dụ: quét lỗ hổng và xem xét tính bảo mật), các chương trình kiểm tra và kiểm tra thâm nhập của bên thứ ba, hoặc thậm chí là các nhà nghiên cứu bảo mật bên ngoài thông báo cho bạn qua các kênh hỗ trợ trước khi VDP chính thức ra mắt. Tổ chức của bạn cần có cách thức để phân loại các lỗ hổng bảo mật mới và hiện có nhằm đảm bảo các lỗ hổng này được thông báo cho đúng bên liên quan, được ưu tiên đúng cách và khắc phục kịp thời. Khi triển khai VDP, bạn sẽ có thêm một luồng lỗ hổng mới chuyển vào các quy trình quản lý lỗ hổng của mình. Việc có sẵn các quy trình vững chắc để xử lý những lỗ hổng này giúp bạn theo dõi tiến trình khắc phục và phản hồi yêu cầu cập nhật của các nhà nghiên cứu bảo mật bên ngoài. Việc có thể nhanh chóng ưu tiên xử lý một lỗ hổng bảo mật và trao đổi với người tham gia VDP về tiến trình khắc phục sẽ giúp tăng cường tương tác với cộng đồng nhà nghiên cứu bảo mật, cũng như nâng cao danh tiếng về bảo mật cho tổ chức của bạn. Các phần sau đây trình bày các khía cạnh của chương trình quản lý lỗ hổng mà bạn cần áp dụng trước khi triển khai VDP.

Thiết lập các tiêu chuẩn về mức độ nghiêm trọng và tiến trình khắc phục

Việc tạo một quy định chung về mức độ nghiêm trọng của các lỗ hổng và tiến trình khắc phục lý tưởng tương ứng với từng mức độ nghiêm trọng sẽ giúp bạn dễ dàng đặt ra các kỳ vọng chuẩn cho tổ chức của mình. Nếu mọi lỗ hổng bảo mật được xử lý như trường hợp khẩn cấp, tổ chức của bạn sẽ dùng hết tài nguyên và trở nên phẫn nộ với nhóm bảo mật. Nếu mọi lỗ hổng được coi là có mức độ ưu tiên thấp, thì các lỗ hổng bảo mật sẽ không bao giờ được khắc phục và nguy cơ bị xâm phạm sẽ tăng lên. Mọi tổ chức đều có nguồn lực hạn chế, vì vậy, bạn cần thiết lập thứ hạng về mức độ nghiêm trọng. Thứ hạng này cung cấp các tiêu chí giúp tổ chức của bạn nắm được mức độ nghiêm trọng của một lỗ hổng, cũng như tiến trình khắc phục dự kiến tương ứng với từng mức độ nghiêm trọng. Soạn thảo một bộ nguyên tắc về mức độ nghiêm trọng và chia sẻ bộ nguyên tắc đó với các bên liên quan chính trong tổ chức của bạn để lấy ý kiến phản hồi. Ví dụ: nếu kỹ thuật có liên quan đến việc tạo ra các tiêu chuẩn mức độ nghiêm trọng, thì nhiều khả năng họ sẽ tuân thủ các tiêu chuẩn này và tuân thủ chúng khi đến lúc khắc phục lỗ hổng trong khoảng thời gian xác định. Những nguyên tắc về mức độ nghiêm trọng này có thể thay đổi tuỳ thuộc vào rủi ro cụ thể đối với doanh nghiệp của bạn. Bạn nên cân nhắc thực hiện một bài tập lập mô hình mối đe doạ để suy nghĩ xem những mối đe doạ nào có nhiều khả năng và tác động nhiều nhất đến tổ chức của mình, đồng thời đưa ra ví dụ về các vấn đề thuộc từng loại mức độ nghiêm trọng. Dưới đây là ví dụ về các tiêu chuẩn nghiêm trọng và tiến trình khắc phục đối với một tổ chức tài chính.

Mức độ nghiêm trọng Nội dung mô tả Tiến trình khắc phục Ví dụ
Nghiêm trọng Các vấn đề gây ra mối đe doạ tức thì cho người dùng hoặc doanh nghiệp của chúng ta. Chủ sở hữu: Chủ sở hữu chính phụ trách đảm bảo lỗ hổng được khắc phục sẽ được xác định trong vòng 8 giờ. Gọi và gọi cho các tài nguyên trên trang khi cần, ngay cả ngoài giờ làm việc bình thường.
Khắc phục: Vấn đề cần được khắc phục hoặc ít nhất là giảm thiểu rủi ro trong thời gian sớm nhất có thể hoặc tối đa là trong vòng 3 ngày làm việc.		 Xâm nhập cơ sở dữ liệu phát hành công khai, bao gồm cả hồ sơ tài chính của tất cả người dùng.

Kẻ tấn công có được quyền truy cập vào các bí mật thương mại, chẳng hạn như các thuật toán đầu tư độc quyền của chúng tôi.

Một sự cố đang diễn ra bao gồm kẻ tấn công chiếm quyền truy cập vào mạng nội bộ hoặc hệ thống sản xuất nhạy cảm của chúng tôi.
Cao Các vấn đề mà nếu bị lợi dụng có thể gây ra thiệt hại đáng kể. Chủ sở hữu: Phải xác định được chủ sở hữu chính trong vòng một ngày làm việc.
Sửa lỗi: Trong vòng 10 ngày làm việc (khoảng 2 tuần).		 Các lỗ hổng bảo mật có thể dẫn đến quyền truy cập vào dữ liệu hoặc chức năng nhạy cảm của người dùng (ví dụ: người dùng có khả năng lấy cắp tiền của người dùng khác).
Phương tiện Các vấn đề khó bị lợi dụng hơn hoặc không gây ra thiệt hại trực tiếp. Chủ sở hữu: Phải xác định được chủ sở hữu chính trong vòng 5 ngày làm việc.
Sửa lỗi: Trong vòng 20-40 ngày làm việc (~1-2 tháng).		 Các sự cố đã xác minh do các trình quét tự động xác định, chẳng hạn như các bản vá để cập nhật bảo mật mà chưa biết trường hợp khai thác nào đã biết.

Các vấn đề tiết lộ thông tin có thể tạo điều kiện cho các cuộc tấn công khác.

Các vấn đề về giới hạn tốc độ có thể bị lợi dụng (ví dụ: việc có thể liên tục đoán mật khẩu của người dùng).
Kém Các vấn đề ít tác động nhất; chủ yếu dùng để ghi nhật ký các vấn đề đã biết. Không có yêu cầu nào về việc tìm chủ sở hữu hoặc khắc phục vấn đề trong một mốc thời gian cụ thể. Thông tin công bố ít có khả năng gây ra rủi ro, nhưng trong trường hợp thông tin không nhất thiết phải truy cập được từ bên ngoài.

Chăm sóc bọ

Ở đây, chúng ta không nói về việc cắt tóc mà đang nói về việc đảm bảo các lỗi được định dạng chính xác để có thể dễ dàng khắc phục. Bạn có thể dựa vào bảng trước đó làm kim chỉ nam để thiết lập các định nghĩa về mức độ nghiêm trọng của riêng mình. Các định nghĩa này được dùng để phân loại lỗi theo nhiều mức độ nghiêm trọng và thông báo cho chủ sở hữu.

Ngoài việc chỉ định mức độ nghiêm trọng cho từng lỗ hổng, bạn cần đảm bảo rằng các lỗi ở định dạng chuẩn để giúp các nhóm tiếp nhận xử lý dễ dàng hơn. Các lỗ hổng bảo mật sẽ xuất hiện trong quy trình quản lý lỗ hổng ở nhiều định dạng (chẳng hạn như kết quả của trình quét tự động hoặc nội dung ghi thủ công từ các quy trình đánh giá bảo mật). Việc dành thời gian để chuyển đổi từng lỗ hổng sang định dạng chuẩn sẽ làm tăng khả năng nhóm tiếp nhận có thể nhanh chóng hiểu và giải quyết vấn đề.

Định dạng hoặc mẫu này có thể thay đổi tuỳ thuộc vào tổ chức của bạn và thông tin nào thích hợp nhất để giúp chủ sở hữu sửa lỗi được chỉ định cho họ, nhưng bạn có thể sử dụng mẫu ví dụ sau đây. Sau này, bạn có thể sử dụng lại mẫu này khi tạo biểu mẫu gửi chương trình thông báo lỗ hổng cho các nhà nghiên cứu.

Tiêu đề: <một dòng mô tả về vấn đề, thường là loại lỗ hổng và lỗ hổng bảo mật/dịch vụ/v.v. có liên quan đến lỗ hổng, đưa ra mức độ nghiêm trọng hoặc ánh xạ mức độ nghiêm trọng đến một trường trong công cụ theo dõi lỗi của bạn>Tóm tắt: <mô tả ngắn gọn về lỗ hổng và lý do tại sao nó quan trọng>Các bước tái tạo: <hướng dẫn từng bước để chỉ ra sự tồn tại của lỗ hổng và cách khắc phục:Các bước khắc phục / cách khắc phục

Sau đây là ví dụ về lỗ hổng bảo mật có mức độ nghiêm trọng cao tiềm ẩn:

Tiêu đề: [HIGH] Tham chiếu đối tượng trực tiếp không an toàn (IDOR) trong các trang hồ sơ Tóm tắt: Chúng tôi đã phát hiện một IDOR trong chức năng của trang hồ sơ của ứng dụng. Điều này cho phép mọi người dùng có quyền truy cập trái phép để xem và chỉnh sửa hồ sơ của người dùng khác, bao gồm cả họ tên, địa chỉ nhà riêng, số điện thoại và ngày sinh của người dùng khác. Chúng tôi đã xem xét nhật ký và có vẻ như vấn đề này chưa được khai thác. Chúng tôi đã phát hiện vấn đề này trong nội bộ. Các bước tái tạo:

  1. Thiết lập một proxy, ví dụ: Burp Suite) để chặn lưu lượng truy cập trên một thiết bị di động đã cài đặt ứng dụng.
  2. Truy cập vào trang hồ sơ của bạn rồi chặn yêu cầu HTTP được liên kết.
  3. Sửa đổi profileID=###### thành profileID=000000 (đây là người dùng thử nghiệm) và gửi yêu cầu HTTP.
  4. Ứng dụng sẽ hiển thị hồ sơ của người dùng 000000 và bạn sẽ có thể xem và chỉnh sửa thông tin của họ.

Tình huống tấn công / ảnh hưởng: Bất kỳ người dùng nào cũng có thể sử dụng lỗ hổng bảo mật này để xem và chỉnh sửa hồ sơ của người dùng khác. Trong trường hợp xấu nhất, kẻ tấn công có thể tự động hoá quy trình truy xuất thông tin hồ sơ của mọi người dùng trong toàn bộ hệ thống của chúng tôi. Mặc dù chúng tôi tin rằng vấn đề này chưa được khai thác, nhưng chúng tôi phải coi đây là vấn đề có mức độ nghiêm trọng CAO và tiêu chuẩn. Nếu chúng tôi quan sát thấy bằng chứng về hành vi bóc lột, thì điều này có thể chuyển lên mức độ nghiêm trọng quan trọng. Các bước khắc phục: Triển khai hoạt động kiểm tra phía máy chủ để đảm bảo người dùng đưa ra yêu cầu sẽ có quyền xem/chỉnh sửa hồ sơ được yêu cầu thông qua giá trị của profileID. Ví dụ: nếu Alice đăng nhập và có profileID 123456, nhưng Alice được quan sát thấy đã yêu cầu profileID 333444, thì người dùng sẽ thấy lỗi và nỗ lực truy cập vào hồ sơ của người dùng khác sẽ được ghi lại. Để biết thêm thông tin về IDOR và cách khắc phục, vui lòng xem Các tài liệu của OWASP về lỗi này.

Bạn có thể tiết kiệm thời gian và công sức thủ công bằng cách tìm cách tự động hoá việc chuyển đổi lỗ hổng bảo mật từ nhiều nguồn sang định dạng chuẩn. Khi tạo thêm nhiều lỗ hổng, bạn có thể sẽ thấy các chủ đề phổ biến trong các bước khắc phục. Ngoài mẫu định dạng lỗi chung, bạn nên tạo thêm mẫu cho các loại lỗ hổng bảo mật phổ biến.

Tìm chủ sở hữu

Có lẽ một trong những khía cạnh khó khăn nhất của việc quản lý lỗ hổng là việc xác định chủ sở hữu để sửa lỗi, cũng như kêu gọi sự tham gia của họ để dành nguồn lực nhằm thực sự sửa lỗi đúng lịch. Nếu bạn đã thiết lập các quy trình quản lý thành phần, thì việc này sẽ dễ dàng hơn một chút. Nếu không thì đây có thể là động lực thôi thúc họ làm việc đó. Tuỳ thuộc vào quy mô tổ chức, việc tìm chủ sở hữu có thể khá đơn giản hoặc cực kỳ phức tạp. Khi tổ chức của bạn phát triển, nỗ lực xác định người chịu trách nhiệm khắc phục các vấn đề bảo mật mới phát hiện cũng tăng lên. Cân nhắc việc triển khai chế độ xoay vòng hoạt động trong công việc. Bất kỳ ai làm nhiệm vụ đều chịu trách nhiệm xem xét các lỗ hổng chưa được chỉ định, theo dõi chủ sở hữu và sắp xếp thứ tự ưu tiên dựa trên mức độ nghiêm trọng. Ngay cả khi bạn có thể xác định ai chịu trách nhiệm sửa lỗ hổng và giao lỗi cho họ, bạn cũng cần phải thuyết phục họ đầu tư thời gian vào việc khắc phục lỗi đó. Phương pháp này có thể thay đổi tuỳ theo nhóm hoặc cá nhân và những mục khác mà họ đang xử lý. Nếu đã đạt được sự đồng thuận của tổ chức đối với các tiêu chuẩn về mức độ nghiêm trọng và tiến trình sửa lỗi, thì bạn có thể tham khảo các tiêu chuẩn đó, nhưng đôi khi có thể cần phải thuyết phục hơn nữa để nhờ người khác sửa lỗi. Dưới đây là một số mẹo chung để thúc đẩy khắc phục lỗ hổng:

  • Giải thích lý do: Khi ai đó được giao một lỗ hổng cần khắc phục, đó thường là công việc ngoài dự kiến. Giải thích lý do tại sao vấn đề này quan trọng để khắc phục kịp thời (ví dụ: Tình huống tác động / tấn công) và đảm bảo chủ sở hữu hiểu.
  • Thu thập ngữ cảnh: Trong một số trường hợp, chỉ một người có kiến thức cần thiết để khắc phục lỗi và họ có thể đang thực hiện những nhiệm vụ khác. Hãy dành thời gian để tìm hiểu những lỗ hổng này – có thể các nhiệm vụ khác sẽ quan trọng hơn việc khắc phục lỗ hổng này trong thời gian ngắn hạn. Việc thể hiện sự đồng cảm và linh hoạt trong tiến trình khắc phục sẽ giúp tạo dựng thiện chí và củng cố mối quan hệ với những người cần khắc phục lỗ hổng. Hãy cẩn thận đừng để kéo dài quá nhiều, nếu không, tổ chức của bạn sẽ không xem xét nghiêm túc tiến trình khắc phục.
  • Giải thích cách thực hiện: Ngay cả khi bạn có đưa ra lời khuyên về cách khắc phục trong lỗi, người phụ trách khắc phục vấn đề có thể vẫn bối rối hoặc cần trợ giúp để tìm hiểu cách khắc phục lỗi. Nếu trẻ cần trợ giúp để tìm ra cách khắc phục vấn đề, hãy hướng dẫn trẻ. Nếu chỉ gửi lỗi cho chủ sở hữu mà không giúp họ, thì mối quan hệ của tổ chức với nhóm bảo mật sẽ bị tổn hại. Hỗ trợ người khác nhiều nhất có thể sẽ tạo điều kiện cho họ khắc phục các lỗ hổng hiện tại và trong tương lai, cũng như giúp hướng dẫn người khác.
  • Điều chỉnh yêu cầu của bạn: Nhiều nhóm và cá nhân có thể đã có sẵn các quy trình để chấp nhận và ưu tiên các yêu cầu công việc sắp tới. Một số nhóm có thể muốn người quản lý xử lý tất cả các yêu cầu được gửi đến. Một số khác thì muốn gửi yêu cầu trợ giúp ở định dạng chuẩn. Một số ứng dụng sẽ chỉ hoạt động dựa trên những nội dung đã xác định trước trong chạy nước rút. Trong mọi trường hợp, việc dành thêm thời gian để điều chỉnh yêu cầu của bạn cho phù hợp với định dạng mà nhóm hoặc cá nhân đó thường sử dụng để tiếp nhận yêu cầu trợ giúp sẽ làm tăng khả năng yêu cầu của bạn được ưu tiên và xử lý.
  • Chuyển lên cấp trên như phương án cuối cùng: Nếu bạn đã thử tất cả những cách trên nhưng cá nhân hoặc nhóm chịu trách nhiệm khắc phục lỗ hổng không có thời gian để khắc phục vấn đề bảo mật nghiêm trọng, hãy cân nhắc việc chuyển lên lãnh đạo nếu cần. Đây phải luôn là phương án cuối cùng, vì có thể phá hoại mối quan hệ giữa bạn với cá nhân hoặc nhóm được đề cập.

Phân tích căn nguyên

Ngoài việc tìm và sửa các lỗ hổng riêng lẻ, việc phân tích nguyên nhân gốc rễ (RCA) có thể giúp bạn xác định và giải quyết các vấn đề bảo mật mang tính hệ thống. Mọi người đều có tài nguyên hạn chế, vì vậy bạn nên bỏ qua bước này. Tuy nhiên, việc đầu tư thời gian vào việc phân tích xu hướng trong dữ liệu về lỗ hổng bảo mật cũng như tìm hiểu thêm về các lỗi nghiêm trọng và có mức độ nghiêm trọng cao có thể giúp tiết kiệm thời gian và giảm rủi ro về lâu dài. Ví dụ: giả sử bạn nhận thấy cùng một loại lỗ hổng bảo mật (ví dụ: chuyển hướng ý định) xuất hiện lặp đi lặp lại trong ứng dụng. Bạn quyết định trao đổi với các nhóm đưa lỗ hổng bảo mật này vào ứng dụng của mình và nhận ra phần lớn trong số họ không hiểu lệnh chuyển hướng ý định là gì, tại sao vấn đề này quan trọng hay cách ngăn chặn. Bạn đã tổ chức một buổi nói chuyện và hướng dẫn để giúp các nhà phát triển trong tổ chức của bạn hiểu rõ về lỗ hổng bảo mật này. Lỗ hổng bảo mật này có thể sẽ không biến mất hoàn toàn, nhưng tốc độ xuất hiện của lỗ hổng này có thể sẽ giảm xuống. Khi bạn triển khai VDP, mọi lỗ hổng bảo mật do bên thứ ba báo cáo đều là lỗ hổng bảo mật thông qua các quy trình bảo mật nội bộ hiện có của bạn. Việc triển khai RCA đối với các lỗi trong VDP sẽ cung cấp thêm thông tin chi tiết về cách cải thiện chương trình bảo mật của bạn theo cách có hệ thống.

Phát hiện và ứng phó

Phát hiện và ứng phó là mọi công cụ và quy trình mà bạn có sẵn để phát hiện và ứng phó với các cuộc tấn công tiềm ẩn nhắm vào tổ chức của bạn. Điều này có thể ở dạng giải pháp mua hoặc tự phát triển để phân tích dữ liệu nhằm xác định hành vi đáng ngờ. Ví dụ: trong phần Grooming Bugs (Lỗi xác định), chúng tôi đã nói về việc ghi nhật ký mỗi khi người dùng cố gắng có quyền truy cập trái phép vào hồ sơ của một người dùng khác. Bạn có thể thấy một tín hiệu hoặc cảnh báo được tạo nếu nhận thấy một người dùng đã nhiều lần truy cập không thành công vào hồ sơ của người dùng khác trong một khoảng thời gian ngắn. Thậm chí, bạn có thể tự động hoá quy trình chặn người dùng đó truy cập vào bất kỳ dịch vụ nào của bạn trong một khoảng thời gian nhất định hoặc vô thời hạn cho đến khi chúng tôi có thể xem xét và khôi phục quyền truy cập theo cách thủ công. Nếu bạn chưa áp dụng cơ chế phát hiện và ứng phó với sự cố, hãy cân nhắc làm việc với một chuyên gia tư vấn để được hướng dẫn về cách xây dựng chương trình điều tra kỹ thuật số và ứng phó sự cố (DFIR) cho tổ chức của bạn. Nếu đã có sẵn cơ chế phát hiện và phản hồi, bạn nên xem xét hậu quả của việc có 5, 10 hoặc thậm chí 100 nhà nghiên cứu bảo mật thử nghiệm các nền tảng tấn công trên Internet. Điều này có thể tác động lớn đến mọi IDS/IPS (hệ thống phát hiện và ngăn chặn xâm nhập) mà bạn đang triển khai.

Rủi ro tiềm ẩn bao gồm:

  • Quá tải cảnh báo: Vô số cảnh báo hoặc tín hiệu trông giống như các cuộc tấn công độc hại, nhưng thực ra là hoạt động thử nghiệm bình thường, đã được phê duyệt từ các nhà nghiên cứu bảo mật tham gia vào VDP. Có thể tạo ra nhiều độ nhiễu đến mức khó phân biệt các cuộc tấn công thực với hoạt động kiểm thử bảo mật chính đáng.
  • Cảnh báo giả đối với phản hồi sự cố: Nếu bạn có các quy trình tại trang mà từng cá nhân vào lúc 2:00 sáng thứ Bảy, họ sẽ không vui khi thức dậy và điều tra một sự cố vi phạm tiềm ẩn mà thực chất chỉ là một nhà nghiên cứu bảo mật thực hiện thử nghiệm hợp pháp.
  • Chặn các nhà nghiên cứu bảo mật: Nếu đã áp dụng các công nghệ IPS (hệ thống ngăn chặn xâm nhập) linh hoạt, bạn có thể chặn địa chỉ IP của một nhà nghiên cứu bảo mật đang cố gắng quét, kiểm tra thủ công, v.v. để xác định lỗ hổng bảo mật và báo cáo cho bạn. Đặc biệt là trong trường hợp của VDP, nếu một nhà nghiên cứu bảo mật bị chặn sau 5 phút thử nghiệm, họ có thể sẽ mất hứng thú và chuyển sang tập trung vào chương trình của tổ chức khác. Điều này có thể dẫn đến tình trạng các nhà nghiên cứu bảo mật thiếu tham gia chương trình của bạn, làm tăng nguy cơ các lỗ hổng bảo mật chưa được phát hiện (và do đó tổ chức của bạn không xác định được). Mặc dù bạn có thể không muốn làm giảm IPS của mình, nhưng có một số biện pháp khác bạn có thể thực hiện để giảm thiểu nguy cơ ngừng tương tác với các nhà nghiên cứu.

Cách giải quyết các rủi ro này phụ thuộc phần lớn vào phương pháp bạn muốn thực hiện khi làm việc với các nhà nghiên cứu bảo mật bên ngoài. Nếu muốn có kiểu kiểm thử hộp đen nhiều hơn để mô phỏng các cuộc tấn công thực tế, thì bạn có thể không cần làm gì cả. Trong trường hợp này, lưu lượng truy cập của nhà nghiên cứu sẽ tạo ra cảnh báo và nhóm của bạn có thể tiến hành điều tra và ứng phó cho phù hợp. Điều này sẽ giúp nhóm của bạn thực hành cách ứng phó với những cuộc tấn công thực tế, nhưng có thể làm giảm mức độ tương tác với các nhà nghiên cứu bảo mật, đặc biệt là khi họ bị chặn kiểm thử. Điều này cũng có thể dẫn đến việc bỏ lỡ một cuộc tấn công thực sự trong khi dành thời gian điều tra quy trình kiểm thử hợp pháp. Nếu muốn sử dụng phương pháp hộp xám nhiều hơn, bạn có thể cân nhắc làm việc với các nhà nghiên cứu bảo mật để tự xác định lưu lượng thử nghiệm của họ theo cách nào đó. Nhờ đó, bạn có thể đưa vào danh sách cho phép hoặc lọc ra lưu lượng truy cập khỏi quá trình kiểm thử và nhận cảnh báo. Nhóm của bạn sẽ có thể phân biệt chính xác hơn các cuộc tấn công thực tế và các cuộc kiểm thử đã được phê duyệt, đồng thời các nhà nghiên cứu sẽ có quyền tìm và báo cáo lỗ hổng cho bạn mà không bị các hệ thống ngăn chặn xâm nhập gây trở ngại cho bạn. Một số tổ chức yêu cầu nhà nghiên cứu bảo mật gửi biểu mẫu đăng ký một giá trị nhận dạng duy nhất có thể đính kèm vào tiêu đề trong các yêu cầu do nhà nghiên cứu tạo. Điều này giúp tổ chức đưa lưu lượng truy cập vào danh sách cho phép cho nhà nghiên cứu, cũng như khả năng xác định xem nhà nghiên cứu có bắt đầu tiến xa hơn phạm vi thử nghiệm đã thoả thuận hay không. Nếu điều này xảy ra, bạn có thể liên hệ với nhà nghiên cứu và yêu cầu họ chờ cho đến khi bạn có thể thống nhất xây dựng kế hoạch thử nghiệm.

Trước
Bài đánh giá
Tiếp
Thuyết phục các bên liên quan.