Bài đăng này là một phần trong series chia sẻ Những thực hành hay nhất trong việc quản lý thành phần nguồn mở của Sonatype.

Phân biệt giữa Remediation – Khắc phục và Mitigation – Giảm thiểu, tìm hiểu về việc nâng cấp các thành phần nguồn mở lên các phiên bản mới, không dễ bị tổn thương bất cứ khi nào có thể và loại bỏ những rủi ro mà bạn sẽ không hoặc không thể nào giải quyết.

Các tổ chức thành công trong việc quản lý lỗ hổng luôn chủ động tạo ra cả kế hoạch giảm thiểu và khắc phục để xử lý các mối đe doạ và lỗ hổng khi chúng phát sinh. Việc loại bỏ hoàn toàn rủi ro là rất tốn kém, do đó hai phương pháp quản lý rủi ro nói trên đóng vai trò riêng biệt và rất quan trọng trong việc bảo vệ các ứng dụng khỏi các mối đe doạ của bên thứ ba. Chúng có vẻ giống nhau, thậm chí có thể hoán đổi cho nhau, nhưng sự khác biệt giữa chúng là rất quan trọng.

• • Remediation – Khắc phục có nghĩa là sửa chữa hoặc chống lại một cái gì đó. Đây là cách tiếp cận lâu đời trong việc phản ứng với lỗ hổng. Biện pháp khắc phục nhằm mục đích giảm bớt các mối đe doạ, và không chỉ đơn giản là việc có một sơ đồ hoặc cây quyết định để hướng dẫn tổ chức phản ứng với lỗ hổng. Có rất nhiều yếu tố bạn cần xem xét và không có phương pháp nào là hoàn hảo trong mọi trường hợp, vì mỗi tổ chức có các ưu tiên riêng và các ngưỡng rủi ro khác nhau.

• • Mitigation – Giảm thiểu là công việc làm giảm độ nghiêm trọng của một vấn đề nào đó. Trường hợp lý tưởng nhất hẳn sẽ là khi các ứng dụng của bạn không có lỗ hổng, vì các kế hoạch khắc phục sự cố của tổ chức đã ngăn chặn chúng một cách hiệu quả. Tuy nhiên, trên thực tế, giải pháp thiết thực hơn trong việc giảm thiểu là chấp nhận rủi ro. Một số tổ chức biết rủi ro có tồn tại, nhưng xác định rằng đó là rủi ro có thể chấp nhận được khi cân nhắc với nỗ lực hoặc chi phí để giải quyết nó thông qua biện pháp khắc phục.

Các chiến lược khắc phục thành phần

Có bốn chiến lược phổ biến để khắc phục các lỗ hổng, mỗi chiến lược đều có ưu và nhược điểm riêng tuỳ theo các tình huống cụ thể của tổ chức, cụ thể như sau: 

Nâng cấp thành phần

Nâng cấp thành phần lên phiên bản tốt hơn và an toàn hơn là chiến lược khắc phục hiệu quả nhất. Đây là lựa chọn ít tốn kém nhất và có thể được tự động hoá (tiết kiệm nhiều thời gian và tài nguyên hơn). Tuy nhiên, thời gian chờ đợi nhà bảo trì phát hành phiên bản thành phần mới có thể kéo dài rất lâu, đồng thời có khả năng làm phát sinh vấn đề liên quan đến các thành phần phụ thuộc bên trong. Do đó, phương pháp này đòi hỏi một cách tiếp cận chậm hơn, có quy trình hơn để không tạo ra thêm rủi ro trong quá trình khắc phục sự cố ban đầu.

Bản vá DIY (Do It Yourself Patch)

Một trong những lợi ích của bất kỳ giải pháp tự thực hiện nào là bạn có thể nắm quyền điều khiển và kiểm soát mã nguồn. Bằng chiến lược vá lỗi DIY, bạn sẽ xoá mã nguồn có vấn đề khỏi đường dẫn thực thi của mình và thay thế bằng mã nguồn do chính bạn viết. Nếu thành công, bạn nên chia sẻ giải pháp đã được mã hoá của mình với những người khác cùng sử dụng mã nguồn dễ bị tấn công cũ – đóng góp cho cộng đồng là một nỗ lực rất đáng hoan nghênh. Một lợi ích khác là cách tiếp cận này rất nhanh chóng và tiết kiệm, điều mà lãnh đạo của bạn chắc chắ sẽ đánh giá rất cao.

Chuyển đổi thành phần

Mặc dù lý do bạn lựa chọn thành phần dễ bị tổn thương ngay từ đầu là vì nó cung cấp chính xác những gì ứng dụng của bạn yêu cầu, nhưng thông thường vẫn sẽ có những thành phần khác mà bạn có thể hoán đổi. Ngoài ra, nếu thành phần được thay đổi đã được “làm sạch”, thì đó sẽ là một hành động khiến đôi bên cùng có lợi. Tuy nhiên, nhược điểm của phương pháp này là quá trình tái cấu trúc có thể gây tốn kém thời gian và tài nguyên nhưng lại không tạo ra bất kỳ giá trị bổ sung nào.

Loại bỏ hoàn toàn thành phần

Nếu tổ chức của bạn có thể chấp nhận việc từ bỏ thành phần bị ảnh hưởng, thì lợi ích của việc xoá hoàn toàn thành phần đó khỏi ứng dụng của bạn chắc chắn sẽ là xoá bỏ hoàn toàn mối đe doạ. Rốt cuộc, đây sẽ là lựa chọn an toàn nhất, vì nếu phải giữ lại chức năng mà thành phần đã cung cấp, bạn có thể tự mình viết và duy trì mã. Mặc dù đây là một chiến lược tốn thời gian, nhưng bạn sẽ giảm được nhiều rủi ro bên ngoài.

Các chiến lược giảm thiểu

Có hai chiến lược chính để giảm thiểu các lỗ hổng, hiển nhiên mỗi chiến lược đều có ưu nhược điểm riêng tuỳ theo từng tình huống, cụ thể như sau:

Miễn trừ

Chiến lược giảm thiểu phổ biến nhất là miễn trừ rủi ro. Một số lý do chính khiến các tổ chức lựa chọn phương pháp này bao gồm:

• – Không gây ra tác động nào cho ứng dụng (hay còn gọi là không thể khai thác)
• – Có một thời kỳ ân hạn (grace period) để giải quyết rủi ro một cách thoả đáng
• – Không có vấn đề nào cần ưu tiên thực hiện để khắc phục vấn đề 
• – Không đòi hỏi lộ trình nào để giải quyết vấn đề trong tương lai
• Một số thực hành hay nhất bạn nên tuân theo khi lựa chọn miễn trừ một vi phạm:

• – Miễn trừ thay vì bỏ qua rủi ro
• – Ghi lại một định dạng chung bằng văn bản cho các miễn trừ
• – Tránh miễn trừ vĩnh viễn – việc miễn trừ nên được xem xét định kỳ để đảm bảo một lý do nhất quán
• – Xem xét các miễn trừ đối với các rủi ro có nguy cơ cao thường xuyên hơn so với các rủi ro có mức độ đe doạ thấp
• – Khi có thể, hãy cân nhắc chuyển đổi các thành phần ngay cả khi ứng dụng không thể khai thác được. Thông thường, thành phần này vẫn là một rủi ro do vẫn còn nằm trong ứng dụng.

Xác định cơ sở

Đối với các ứng dụng cũ hoặc có tác động thấp mà không được phát triển một cách tích cực, bất kỳ hoạt động khắc phục nào cũng đều có thể nằm ngoài phạm vi của dự án và không khả thi. Chiến lược chung trong những tình huống như vậy là xác định một cơ sở để chấp nhận mọi rủi ro hiện có và chỉ khắc phục rủi ro mới. Nếu bạn áp dụng chiến lược này, hãy thường xuyên xem xét mọi rủi ro cơ sở và phát triển một hệ thống thông báo cho các bên liên quan khi một rủi ro mới được xác định.

Theo Sonatype