Trên thực tế, 43% các vụ vi phạm dữ liệu là kết quả của việc bảo mật ứng dụng web (AppSec) yếu, mà nguyên nhân hàng đầu do biên độ tấn công rộng. Trong bối cảnh hiện nay, nhiều khi, vì sợ ảnh hưởng đến danh tiếng mà các tổ chức do dự trong việc báo cáo các cuộc tấn công khiến việc xác định những sự cố mạng trở thành một thách thức cũng như làm gia tăng sự thiếu minh bạch và trách nhiệm giải trình của lĩnh vực.
Một vấn đề nữa là thị trường phần mềm, bao gồm cả chuỗi cung ứng phần mềm chưa chú trọng bảo mật. Rất khó để phân biệt sự khác biệt giữa phần mềm an toàn và phần mềm không an toàn, do đó cả người sản xuất và người dùng đều không thể đưa ra quyết định sáng suốt trước những rủi ro. Thị trường cũng chưa tạo sự kích thích các nhà sản xuất tạo mã an toàn và những người dùng phải tin tưởng một cách mù quáng vào những phần mềm có vai trò quan trọng nhất trong cuộc sống và doanh nghiệp (DN) của họ.
Tuy nhiên, các DN có thể thực hiện tốt hơn công việc bảo vệ các ứng dụng của mình trong toàn bộ vòng đời phát triển phần mềm để không trở thành nạn nhân của vi phạm. Dù là sáng kiến bảo mật ứng dụng nào cũng phải đảm bảo rằng: (1) Mã tùy chỉnh có các biện pháp bảo vệ phù hợp và không có lỗ hổng; (2) Thư viện mã nguồn mở an toàn; (3) Có các công cụ thích hợp để phát hiện tấn công, có khả năng hiển thị và ngăn chặn khai thác. Điều quan trọng là các tổ chức phải nắm vững ba lĩnh vực này bằng cách tận dụng các công nghệ DevSecOps (Development - Security - Operations: Phát triển - Bảo mật - Vận hành).
Loại bỏ các lỗ hổng bảo mật và bảo mật mã tùy chỉnh
Khi các ứng dụng ngày càng trở nên phức tạp và phân tán, hiệu quả của các quy trình và công cụ bảo mật ứng dụng truyền thống đã bị tụt hậu ở một số lĩnh vực quan trọng trong đó có cả việc loại bỏ qua các lỗ hổng của quá trình phát triển phần mềm và bảo vệ các ứng dụng trong môi trường sản xuất. Điều này khiến cho các lỗ hổng bị phát tán trong mã ứng dụng mà không được phát hiện. Trên thực tế, đây chính xác là những gì đã xảy ra đối với nhiều tổ chức khi phản hồi về lỗ hổng Log4j vào tháng 12/2021. Các nhóm bảo mật đã mất rất nhiều thời gian tìm kiếm những bản sửa lỗi cho các thư viện nhưng cuối cùng nó lại không thực sự được sử dụng cho các ứng dụng và API của họ.
Mới đây, Tổng thống Mỹ Joe Biden đã ra sắc lệnh về việc cải thiện tình hình an ninh mạng của quốc gia, chỉ đạo vVện Tiêu chuẩn và Công nghệ quốc gia (NIST) tạo ra một tiêu chuẩn tối thiểu mới để kiểm tra bảo mật ứng dụng. Tiêu chuẩn này khuyến khích cách tiếp cận hiện đại, kiểm tra bảo mật trực tiếp trong mã để có thể hiển thị tối ưu, giám sát liên tục các hệ thống ứng dụng với thời gian thực thi nhanh hơn.
Thay vì dựa vào các công cụ quét tĩnh và động truyền thống để phát hiện lỗ hổng, các tổ chức nên chuyển sang các công cụ kiểm tra bảo mật ứng dụng tương tác (IAST) để tự động phát hiện và xác định các lỗ hổng bảo mật từ bên trong các ứng dụng. Kiểm tra bảo mật ứng dụng chính xác theo thời gian thực là điều bắt buộc, từ các ứng dụng web truyền thống, API…
Bảo mật các thư viện mã nguồn mở
Một xu hướng khác trong thế giới nhà phát triển là việc tăng cường áp dụng phần mềm nguồn mở (OSS), trong đó mã được thiết kế để có thể truy cập công khai cho việc sử dụng và sửa đổi. Với cách mã hóa phi tập trung và cộng tác này giúp các tổ chức giảm chi phí, mang lại sự linh hoạt và nhiều cơ hội đổi mới hơn, đồng thời cho phép hiển thị đầy đủ trong cơ sở mã.
Tuy nhiên, sự gia tăng OSS và việc sử dụng OSS trong toàn bộ chuỗi cung ứng phần mềm cũng mang lại nhiều rủi ro. Các ứng dụng sử dụng OSS là mục tiêu chính của tội phạm mạng vì một khi lỗ hổng được phát hiện, tin tặc có thể tấn công hầu như bất kỳ ứng dụng nào được xây dựng bằng OSS có lỗ hổng.
Các nhóm bảo mật thường dựa vào các công cụ phân tích thành phần phần mềm (software composition analysis - SCA) để nắm được nơi nào trong mã của họ dễ bị tấn công nhất. Trong khi SCA được thiết kế để quét cơ sở mã OSS nhằm tìm các lỗ hổng thì các nhà phát triển và nhóm bảo mật cần phải thận trọng khi sử dụng các SCA kế thừa.
Thông thường, SCA này chỉ quét ở cấp kho lưu trữ, nghĩa là các nhóm bảo mật chỉ có thể thấy được các phần được sử dụng để thử nghiệm, một phần của nền tảng hoặc một phần của máy chủ ứng dụng của họ. Các nhóm bảo mật sẽ không có cách nào biết được liệu những thư viện đó có thực sự được ứng dụng hoặc API yêu cầu hay không. Những vấn đề này có thể gây ra những mệt mỏi do có quá nhiều cảnh báo khiến việc kiểm tra bảo mật bị chậm lại và cuối cùng là không có kế hoạch ứng phó sự cố cho khai thác zero-day. Việc chạy SCA theo thời gian thực có thể xác định những rủi ro có nguy cơ xảy ra cao nhất bằng cách gắn cờ các thư viện được ứng dụng gọi ra và tổng hợp các lỗ hổng để tạo ra một cái nhìn được tập trung về các mối đe dọa mạng.
Mặc dù OSS có thể đáp ứng nhu cầu kinh doanh về tốc độ nhưng các tổ chức phải đảm bảo an ninh và các công cụ quản lý lỗ hổng bảo mật của họ có thể giải quyết các rủi ro đi kèm.
Phát hiện tấn công và ngăn chặn khai thác
Hiện nay chính phủ Tổng thống Joe Biden đã và đang thực hiện các bước để đưa AppSec đi đúng hướng với Sắc lệnh an ninh không gian mạng và các tiêu chuẩn triển khai từ NIST, cả hai đều đang thúc đẩy sự minh bạch trên thị trường phần mềm với các yêu cầu hình thành dự luật các nguyên vật liệu phần mềm (Software Bill of Materials - SBOM) và kiểm thử bảo mật ứng dụng tối thiểu cũng như việc tạo ra các hộp bảo hiểm và các nhãn bảo mật phần mềm. Nhiều tổ chức khác đang hỗ trợ những nỗ lực này, trong đó có dự án bảo mật ứng dụng web mở (Open Web Application Security Project - OWASP) và Cơ quan hệ thống thông tin quốc phòng (Defense Information Systems Agency - DISA).
Bước tiếp theo là phải đảm bảo các nhóm bảo mật có thể nhận thấy được ai đang tấn công các ứng dụng và API, những xu hướng tấn công nào chúng đang sử dụng và hệ thống nào chúng đang nhắm mục tiêu. Các cuộc tấn công mạng ở lớp ứng dụng phần lớn là "vô hình" trước các biện pháp phòng thủ vành đai cũng như tường lửa truyền thống và các hệ thống phát hiện xâm nhập (IDS). Các giao tiếp ứng dụng hiện đại tuy đơn giản nhưng lại quá phức tạp để thiết bị mạng có thể hiểu được, vì vậy chúng có xu hướng ép xung (overblock) và khóa lại (underblock), tạo sự xáo trộn các toán tử. Để phát hiện những cuộc tấn công này, các nhóm an ninh mạng cần phải hiểu về dữ liệu tấn công, cách mã thực thi và sử dụng dữ liệu.
Cuối cùng, các lỗ hổng ứng dụng là không thể tránh khỏi nhưng việc xử lý chúng ngay sau khi phát hiện ra không phải lúc nào cũng khả thi. Việc phát hiện và bảo vệ khỏi những cuộc tấn công mạng trước khi các lỗ hổng được vá có thể giúp các nhóm bảo mật tập trung vào các nhiệm vụ quan trọng khác thay vì mất nhiều thời gian vá mọi lỗ hổng khi được phát hiện.
Mô hình bảo mật ứng dụng truyền thống là chưa đủ, các tổ chức phải tìm cách triển khai những công cụ phù hợp để đạt được DevSecOps thành công và bảo vệ khỏi các lỗ hổng mã không thể tránh khỏi. Một chương trình bảo mật ứng dụng hiện đại phải có nền tảng giải pháp phù hợp để cho phép các nhóm phát triển và bảo mật làm việc cùng nhau một cách hiệu quả trong toàn bộ danh mục phần mềm và vòng đời phần mềm./.
.png "5 lý do để tăng cường bảo mật mạng")
