Phần lớn các vấn đề bảo mật đều liên quan đến các lỗi lập trình. Dù vấn đề đó ảnh hưởng tới các cấu phần của hệ điều hành, ứng dụng client/server, ứng dụng web hay các đoạn mã nhúng trong thiết bị phần cứng, thì các lỗ hổng bảo mật nổi tiếng đều liên quan đến lỗi lập trình.
Mặc dù các lập trình viên luôn muốn phát triển ứng dụng không có lỗi nhưng họ thường ưu tiên quan tâm đến các chức năng hấp dẫn của ứng dụng, hoàn thành dự án đúng tiến độ để kịp đưa sản phẩm ra thị trường hay những vấn đề khác hơn so với việc đảm bảo sự an toàn, bảo mật của ứng dụng. Mặt khác, do tính phức tạp của các hệ thống kỹ thuật, việc đảm bảo ứng dụng không có lỗi bảo mật là cực kỳ khó khăn, ngay cả với những lập trình viên cao cấp.
Liệu có thể giải quyết vấn đề bằng cách sử dụng các bản vá lỗi? Rất nhiều công ty lớn nhỏ không thể theo kịp tốc độ xuất hiện chóng mặt của các bản vá. Hãy giả sử toàn bộ Internet và các dịch vụ trọng yếu của nó chỉ bao gồm 100 ứng dụng chính. Và mỗi ứng dụng đó chỉ có khoảng 100 lỗ hổng bảo mật thì chúng ta đã có 10 ngàn lỗ hổng có thể bị tin tặc lợi dụng.
Trên thực tế số lỗ hổng còn lớn hơn nhiều. Lập trình viên bảo mật nổi tiếng Wietse Venema ước lượng rằng có khoảng 1 lỗi bảo mật trong 1000 dòng lệnh mà ông viết. Với những hệ điều hành như Linux hay Windows – những sản phẩm bao gồm hàng trăm triệu dòng lệnh – thì số lỗi bảo mật có thể lên tới hàng trăm ngàn. Theo thống kê của CERT, người ta đã phát hiện được khoảng 5000 lỗi bảo mật trong năm 2003. Với tốc độ đó, cần phải mất 20 năm để phát hiện hết các lỗi bảo mật của một hệ điều hành. Việc khắc phục các lỗi đó còn mất nhiều thời gian hơn và theo quan sát thì khoảng 10-15% các bản vá bảo mật lại sinh ra lỗ hổng mới! Việc áp các bản vá đó – ngay cả khi những người quản trị hệ thống không làm việc gì khác – sẽ không bao giờ giúp chúng ta có được một hạ tầng Internet an toàn. Vì thế, dù việc vá lỗi rất quan trọng, nhưng việc làm thế nào để giảm bớt các lỗi bảo mật trong phần mềm còn quan trọng hơn.
Làm thế nào để giảm bớt số lỗi bảo mật trong phần mềm? Một sai lầm phổ biến của rất nhiều người – từ lập trình viên cho đến cán bộ quản lý – là chạy theo các lỗ hổng. Quan điểm của họ là “hãy đưa tôi danh sách các lỗi bảo mật cần tránh, tôi sẽ đảm bảo chúng không xuất hiện trong phiên bản tiếp theo”.
Phát hiện lỗ hổng bảo mật mới? Hãy thông báo cho các nhóm lập trình để biết và tránh lỗ hổng đó. Điều đó không sai, nhưng không phải là điều quan trọng nhất. Rất nhiều lỗ hổng khác nhau xuất phát từ cùng một kiểu lỗi trong lập trình. Việc xác định và đảm bảo lập trình viên tuân thủ các nguyên tắc cơ bản trong lập trình bảo mật sẽ đem lại hiệu quả cao hơn rất nhiều so với việc chạy theo từng lỗ hổng cụ thể.
Tương tự như thế, các lỗi bảo mật cần được đánh giá, phân loại để đảm bảo các nỗ lực được tập trung để giải quyết những vấn đề quan trọng nhất. Một trong những cách tiếp cận đó là OWASP Top 10 - danh sách các lỗi bảo mật nghiêm trọng nhất của phần mềm web do Open Web Application Security Project lập. Danh sách này được công bố lần đầu năm 2010 và cập nhật năm 2013.
OWASP Top 10 khá nổi tiếng và được nhiều tổ chức sử dụng: Microsoft dùng để đánh giá độ bao phủ của quy trình phát triển an toàn và khả năng nâng cao độ an toàn bảo mật mà việc áp dụng quy trình mang lại, NSA cũng dùng nó trong tài liệu hướng dẫn lập trình web an toàn của tổ chức này, PCI Council thì tận dụng để hình thành nên một phần của tiêu chuẩn PCI DSS. Nhưng liệu cách tiếp cận từ trên xuống có giúp giải quyết hết các vấn đề của lập trình an toàn bảo mật? Nếu lỗ hổng bảo mật không nằm trong mã nguồn của ứng dụng mà lại xuất hiện trong các thư viện do bên thứ ba cung cấp hay trong hệ điều hành thì phải làm thế nào?
Trong trường hợp này, việc phát tán thông tin về lỗ hổng cho từng nhóm lập trình/từng lập trình viên đơn lẻ không có ý nghĩa gì nhiều. Cách tốt nhất là phân công một nhóm hay một cán bộ chuyên trách theo dõi danh sách các lỗ hổng, xác định phương án khắc phục (có thể là cập nhật bản vá lỗi, phiên bản mới, thay đổi cấu hình triển khai hay phát triển bổ sung một giải pháp thay thế, vòng tránh) trước khi gửi phương án đó cho các nhóm phát triển. Rõ ràng ở đây việc làm rõ quy trình và chuyên môn hoá sẽ có hiệu quả hơn nhiều so với cách làm “sai đâu sửa đó”.
Thực tế ở tất cả các đơn vị phát triển phần mềm cho thấy, những tài liệu về lỗi bảo mật trong phần mềm hay những hướng dẫn kỹ thuật để tránh lỗi tuy rất phổ biến nhưng không giúp ích nhiều trong việc nâng cao chất lượng phần mềm nếu không áp dụng quy trình giám sát, kiểm tra. Các công ty phần mềm đều nhận ra rằng, điều cốt yếu để đáp ứng yêu cầu bảo mật cho phần mềm là phải triển khai những quy trình có thể lặp lại, đảm bảo chất lượng đồng đều và đo kiểm được. Từ đó, các nhà cung cấp phần mềm lần lượt chuyển sang áp dụng những quy trình nghiêm ngặt, tập trung nâng cao độ an toàn cho sản phẩm. Quy trình đó sẽ nhằm giảm thiểu số lỗ hổng bảo mật trong quá trình thiết kế, lập trình và tài liệu, phát hiện và gỡ bỏ những lỗ hổng trong quá trình phát triển càng sớm càng tốt.
