DevSecOps hay SecDevOps, đâu là lựa chọn tốt nhất?

Các lỗ hổng nguồn mở đang gia tăng. Vậy chúng ta nên làm thế nào để giải quyết chúng một cách hiệu quả.

Hiện nay, DevOps và bảo mật là ai ưu tiên hàng đầu của các tổ chức phần mềm và kết quả của việc tích hợp bảo mật vào DevOps là sự ra đời của các thuật ngữ SecDevOps và DevSecOps. Mặc dù được sử dụng thay thế cho nhau, nhưng thứ tự của các từ mới là quan trọng. Tại sao? Bởi vì trong hầu hết các trường hợp, bảo mật vẫn chỉ được quan tâm vào cuối quá trình triển khai. Trong bài viết này, tôi sẽ thảo luận về cách lựa chọn phần mềm bảo mật dễ dàng đạt được hiệu quả hơn khi bảo mật là một phần không thể thiếu của quá trình triển khai và phát triển. Chúng ta nên coi trọng chúng ngay từ khi bắt đầu quá trình nghiên cứu phát triển phần mềm thay vì tại giai đoạn cuối.

Bảo mật trong chuỗi DevSecOps

Mặc dù sự tập trung vào vấn đề bảo mật ngày càng tăng, nhưng các nhóm phần mềm tích hợp khiến cho quá trình thiết lập bảo mật tạo nên một quy trình thực hiện đầy thách thức. Áp lực để hoàn thành các dự án đúng thời hạn và trong ngân sách cho phép thường khiến tổ chức bỏ qua những cân nhắc khác. Do đó, chúng ta có xu hướng thêm bảo mật vào như bước cuối cùng để hoàn thiện phần mềm trước khi phát hành chính thức, như minh họa dưới đây:

Vì trong tổ chức, những người có kiến thức về bảo mật không nhiều, thường chỉ giới hạn ở một vài cá nhân, và những cá nhân này thường được nhóm lại thành một nhóm bảo mật tập trung. Nhóm bảo mật được giao nhiệm vụ kiểm tra sản phẩm bằng cách sử dụng "hộp kỹ thuật" của họ để tìm lỗ hổng trong sản phẩm trước khi chính thức triển khai. Nếu nhóm bảo mật tìm thấy lỗ hổng, họ chuyển "tin xấu" này cho nhóm phát triển nhưng, vì nhóm phát triển không được đào tạo về bảo mật hoặc có kiến thức về cách sử dụng các công cụ mà nhóm bảo mật đang sử dụng, nên nhóm bảo mật thường bị coi là "kẻ xấu" bởi vì họ không cho phát hành sản phẩm vì nó tồn tại "một số lỗ hổng bảo mật". Vậy những hành động điển hình của đội bảo mật là gì?

Chúng ta phải đối mặt với thực tại là sẽ rất khó khăn để có được các bản sửa lỗi, thông qua kiểm soát và tiêu chuẩn mã hóa quan trọng cho một dự án "đã hoàn thành và bị lỗi" ngay khi nhóm phát triển có yêu cầu. Vậy chuyện gì sẽ xảy ra? Sản phẩm vẫn được phát hành với các lỗ hổng bảo mật đã biết và thậm chí chưa biết, nhưng có thể đi kèm một số lời hứa sẽ "sửa chúng trong phiên bản tiếp theo". Đây là những gì bạn nhận được khi đặt nhiệm vụ bảo mật sau nhiệm vụ phát triển - "Dev" rồi "Sec" rồi "Ops". Mặc dù đây không phải là điều chúng ta mong đợi, nhưng đây là thực tế trong nhiều tổ chức. Hãy xem xét một cách tiếp cận tốt hơn được mô tả dưới đây.

Bảo mật trong chuỗi SecDevOps

Kiểm soát bảo mật, hướng dẫn, tiêu chuẩn mã hóa và chính sách phải được tích hợp hoàn toàn vào quy trình phát triển phần mềm. Điều này được thực hiện bằng cách đưa hoạt động bảo mật vào ngay từ đầu quy trình - "Sec" rồi "Dev" rồi "Ops". Nhóm bảo mật (hoặc có thể là một chuyên gia hoặc nhà phát triển cao cấp chuyên về bảo mật) xác định các chính sách cần thiết trước cho nhóm phát triển.

Các chính sách này có thể bao gồm các tiêu chuẩn mã hóa an toàn, các quy tắc để tránh các API không an toàn và mã hóa kém, hướng dẫn sử dụng phân tích tĩnh và động và hướng dẫn kiểm tra. Mục tiêu là để các nhà phát triển hướng tới một phần mềm an toàn hơn và sau đó quá trình tự động hóa sẽ giúp biến điều này thành hiện thực.

Với tự động hóa, bạn có thể chuyển cách tiếp cận bảo mật cho chiến lược SecDevOps như sau:

Khi bảo mật được thực hiện trước khi bắt đầu phát triển, nhóm phát triển sẽ tự nhiên trở nên thành thạo hơn về bảo mật và hiển nhiên sẽ phát hiện ra ít lỗ hổng bảo mật hơn ở cuối quy trình.

Các lỗ hổng bị phát hiện sau đó có thể được điều tra và nghiên cứu. Từ kết quả phân tích nguyên nhân gốc của lỗ hổng, chúng sẽ được sử dụng để cải thiện các chính sách và hướng dẫn về bảo mật - về cơ bản là cải thiện kết quả tại mỗi quy trình phát triển tiếp theo.

Thúc đẩy các cải tiến lặp đi lặp lại cho chính sách bảo mật dẫn đến việc chu kỳ phát triển sẽ như sau:

Cách tiếp cận tích hợp và phát triển này hoạt động tốt hơn nhiều so với việc cố gắng thực hiện kiểm tra bảo mật vào cuối quy trình.

Làm thế nào để thực hiện điều này?

Không có cách nào khác ngoài việc thêm bảo mật như một yêu cầu bổ sung cho các nhà phát triển, nhưng cách bạn quản lý tác động của việc này sẽ điều tạo ra sự khác biệt giữa một sản phẩm đúng hạn, an toàn và một sản phẩm trễ nhưng không an toàn. Yêu cầu quan trọng là tích hợp bảo mật vào quy trình phát triển hiện có, bạn có thể thực hiện bằng cách tích hợp bộ công cụ kiểm tra tương thích CWE của Parasoft để bảo mật là một phần của chất lượng và quy trình làm việc chung.

Làm cho bảo mật trở thành một phần của chất lượng với quy trình tập trung vào bảo mật

Quy trình làm việc bắt đầu với chính sách mã hóa an toàn. Bước đầu, Trưởng nhóm lập trình viên tạo ra một cấu trúc (có thể dựa trên các nguyên tắc mã hóa như CERT, CWE, OWASP, UL-2900 hoặc PCI-DSS) để các thành viên còn lại thực hiện trực tiếp trong IDE của họ. Điều này cung cấp cho nhà phát triển khả năng kiểm tra mã hóa cục bộ trên máy của họ trước khi cam kết kiểm soát nguồn và đảm bảo sửa các vi phạm bảo mật ở đâu và khi nào rẻ hơn và dễ dàng hơn.

Cấu hình tương tự sau đó tiếp tục được tận dụng thực hiện ở quá trình xây dựng tiếp theo. Hoạt động phân tích toàn diện này vượt ra ngoài phạm vi mã hóa được sửa đổi cục bộ của nhà phát triển và từ đó cung cấp một mạng lưới an toàn để chuyển qua đường ống phân phối nhằm đảm bảo rằng mã hóa không an toàn không được quảng bá ở các giai đoạn sau.

Cuối cùng, kết quả phân tích được gửi lại cho IDE của nhà phát triển thông qua bảng điều khiển phân tích và báo cáo tập trung, nơi có thể theo dõi tiến trình, sửa chữa khóa mã và báo cáo kiểm tra được tạo trong thời gian thực.

Quy trình thực hiện đầy đủ của SecDevOps như sau:

Nhà quản lý và lãnh đạo bảo mật hiện có thể đánh giá các dự án dựa trên các tiêu chuẩn bảo mật như CWE, trong bảng điều khiển trung tâm như dưới đây:

Các bảng điều khiển này có thể hiển thị xu hướng của thông tin và trả lời các câu hỏi, chẳng hạn như "Dự án đang được cải thiện hay đang trở nên tồi tệ hơn?" hoặc "Khu vực nào của dòng mã đang gây ra nhiều vấn đề nhất?"

Để trả lời những câu hỏi này và cả những câu hỏi khác, nhóm phát triển sẽ biến đổi từ DevSecOps thành SecDevOps.

Tổng kết

Mặc dù việc sử dụng DevSecOps và SecDevOps có thể hoán đổi cho nhau, nhưng thứ tự của các từ trong chuỗi cũng quan trọng như hàm ý của các công cụ, kỹ thuật và quy trình của chuỗi hoạt động này. Bảo mật thường được mặc định dưới dạng tiện ích bổ sung hoặc quy trình kiểm tra trước khi phát hành sản phẩm, nhưng rất khó khắc phục các sự cố bảo mật khi sản phẩm đã được công bố. Đẩy bước bảo mật sang trái, như trong SecDevOps, là chìa khóa thành công. Bảo mật phải là một phần của quy trình làm việc hàng ngày của mỗi nhà phát triển và được tích hợp vào phần mềm. Tự động hóa của Parasoft thay đổi các chính sách và kiểm soát bảo mật để xây dựng bảo mật cho quy trình trong khi giảm tác động và rủi ro của SecDevOps (và DevSecOps!).