Phát triển an toàn là nhu cầu cấp thiết đối với nhiều công ty tạo ra phần mềm tùy chỉnh hoặc cho chính họ. Việc tìm kiếm và loại bỏ các lỗ hổng kịp thời cho phép bạn giảm thời gian phát hành sản phẩm, giảm rủi ro bảo mật thông tin và giảm thiểu chi phí phát triển sản phẩm.
- Giới thiệu
- Các bước chính trong quy trình phát triển an toàn
- Các công cụ được sử dụng trong DevSecOps
- Sử dụng Solar appScreener để xây dựng quy trình phát triển an toàn
- kết luận
Giới thiệu
Phát triển an toàn, DevSecOps, nhằm mục đích tự động hóa các quy trình bảo mật thông tin và giới thiệu các biện pháp kiểm soát bảo mật ở giai đoạn đầu của quá trình tạo ra các sản phẩm phần mềm.
Theo thống kê, khoảng 90% sản phẩm phần mềm di động của Nga có nguy cơ bị hack và trong một thử nghiệm, 98% ứng dụng web đã bị hack thành công.
TRONG nghiên cứu Viện Ponemon và Rezilion 78% số người được hỏi báo cáo rằng các lỗ hổng có nguy cơ cao trong môi trường thông tin của họ phải mất hơn ba tuần để giải quyết và 30% cho biết các lỗ hổng phải mất hơn năm tuần để giải quyết.
Các lỗ hổng trong các ứng dụng đã trở thành nguyên nhân chính của các cuộc tấn công có động cơ chính trị nhằm vào tài nguyên web của các cơ quan chính phủ Nga và các công ty trong nước. Nỗ lực giới thiệu và kích hoạt các khả năng chưa được khai báo trong nguồn mở (Nguồn mở) trên cơ sở địa lý đã trở nên thường xuyên hơn.
Các lỗ hổng và khả năng không được khai báo trong mã ứng dụng đến từ đâu? Thứ nhất, do đặc thù của quá trình phát triển: sử dụng cấu trúc ngôn ngữ không an toàn, các thành phần của bên thứ ba (framework, thư viện), nhúng bookmark để tăng tốc độ phát triển. Thứ hai, việc thiếu thời gian dẫn đến việc việc xem xét mã được thực hiện nhanh chóng, chú trọng vào chức năng, trong khi phân tích chất lượng cao cần phải hết sức chú ý, bao gồm cả vấn đề bảo mật. Thứ ba, người ta thường sử dụng phần mềm cũ chứa nhiều lỗ hổng nổi tiếng cũng như phần mềm khó hoặc không thể cập nhật.
Sự phát triển an toàn không bị các cơ quan quản lý chú ý, các yêu cầu đối với nó có thể được tìm thấy trong Lệnh số 239 của FSTEC của Nga, GOST số 56939-2016, GOST số 58412-2019, Quy định của Ngân hàng Nga số 719-P, 757- P, 683-P.
Các bước chính trong quy trình phát triển an toàn
Việc sử dụng DevSecOps cho phép bạn duy trì mức độ bảo mật cần thiết trong quá trình phát triển và trong suốt vòng đời của phần mềm. Cách tiếp cận này cũng tập trung vào việc xác định và quản lý rủi ro. Kết quả của việc thực hiện quy trình phát triển an toàn là giảm 80% số lượng lỗ hổng. Hãy xem xét các giai đoạn chính của quy trình bằng cách sử dụng phương pháp Vòng đời phát triển bảo mật (SDLC) làm ví dụ, phương pháp này đã trở thành tiêu chuẩn cho nhiều tập đoàn lớn trên thế giới.
Hình 1. Vòng đời phát triển bảo mật (SDLC)
Đào tạo
Tất cả nhân viên, cũng như các nhà thầu và những người khác tham gia phát triển phần mềm, đều phải trải qua đào tạo về kiến thức cơ bản về an ninh mạng và đào tạo thường xuyên trong lĩnh vực phát triển an toàn.
Yêu cầu
Công việc trên mỗi sản phẩm do công ty phát triển bắt đầu bằng việc xác định rõ ràng các yêu cầu an toàn. Các yêu cầu được xác định dựa trên các yếu tố như loại dữ liệu sẽ được sản phẩm xử lý, các mối đe dọa đã biết, các biện pháp thực hành tốt nhất, quy định và yêu cầu của ngành cũng như phát hiện từ các sự cố trước đó.
Thiết kế
Ở giai đoạn này, các mô hình mối đe dọa được thiết kế để giúp xác định và phân loại các mối đe dọa theo các rủi ro hiện có. Các mô hình mối đe dọa phải được duy trì và cập nhật trong suốt vòng đời của mỗi sản phẩm khi có thay đổi đối với phần mềm.
Thực hiện
Giai đoạn triển khai được đặc trưng bằng việc kiểm tra mã để tìm lỗ hổng, bao gồm cả việc sử dụng các công cụ phân tích tĩnh.
xác minh
Ở giai đoạn xác minh, quy trình làm mờ, kiểm tra động mã và xem xét khu vực tấn công tiềm ẩn được thực hiện.
Giải phóng
Trước khi đưa phần mềm vào sản xuất, quy trình kiểm tra cuối cùng được thực hiện để xác định xem các yêu cầu bảo mật được triển khai thực tế có đáp ứng các yêu cầu đã nêu ở giai đoạn thiết kế hay không và kế hoạch ứng phó được chuẩn bị trong trường hợp xảy ra sự cố bảo mật thông tin.
Phản ứng
Giai đoạn phản hồi bao gồm việc thực hiện kế hoạch được phát triển ở giai đoạn trước.
Các công cụ được sử dụng trong DevSecOps
Phân tích mã tĩnh (SAST)
Phân tích tĩnh được thực hiện ở chế độ hộp trắng và cho phép bạn tìm các lỗ hổng mà không thực sự thực thi mã cơ bản. Công cụ này được đặc trưng bởi các tính năng sau: trong giai đoạn đầu, số lượng lỗ hổng tối đa được xác định thông qua phân tích mã nguồn; có thể tích hợp máy phân tích vào đường ống và quét tăng dần. Nó cũng có nhược điểm – ví dụ, tỷ lệ lớn các kết quả dương tính giả.
Hình 2. Đặc điểm của việc triển khai SAST ở các giai đoạn phát triển hệ thống khác nhau
Tốt nhất là triển khai bộ phân tích mã tĩnh theo khái niệm Shift Left, tức là đưa ra các kiểm tra trong quá trình phát triển sản phẩm chứ không phải ở giai đoạn cuối. Điều này sẽ ảnh hưởng trực tiếp đến chi phí sửa chữa các khuyết tật đã được xác định. Ví dụ: nếu chúng tôi giả định rằng chi phí sửa chữa các lỗ hổng đã xác định ở giai đoạn phát triển dự án được ước tính là X rúp, thì việc thu hẹp khoảng cách ở giai đoạn chấp nhận dự án sẽ tốn 10 lần và ở giai đoạn vận hành hệ thống – 100 lần rúp.
Nếu dự án đang được thực hiện bởi một công ty bên ngoài, SAST không thể được triển khai trong quá trình phát triển – bạn sẽ phải phân tích mã nguồn theo cách thủ công khi nó được cung cấp cho khách hàng.
Phân tích mã động (DAST)
Phân tích mã động được thực hiện ở chế độ “hộp đen”, khi công cụ không xác định được mã nguồn và quá trình kiểm tra được thực hiện trong quá trình thực thi chương trình. DAST mô phỏng các cuộc tấn công độc hại bên ngoài sử dụng các vectơ phổ biến để xâm phạm ứng dụng. Công cụ này được đặc trưng bởi các tính năng sau: nó có thể được sử dụng khi không có mã nguồn, nó không bị ràng buộc với các ngôn ngữ lập trình và có số lượng dương tính giả tối thiểu. Những nhược điểm bao gồm một số lượng lớn các lỗ hổng bị bỏ sót và các khả năng không được khai báo do phạm vi bao phủ không đầy đủ của mã được phân tích.
Phân tích thành phần nguồn mở (OSA)
OSA bao gồm một số thành phần: phân tích thành phần (Phân tích thành phần phần mềm (SCA), rủi ro giấy phép (LR) và bảo mật chuỗi cung ứng (SCS). SCA được sử dụng để xác định các thành phần nguồn mở tạo nên phần mềm và xác minh tính bảo mật của chúng. LR được sử dụng để phân tích các rủi ro pháp lý liên quan đến việc cấp phép cho các thành phần nguồn mở. SCS là cần thiết để phân tích tính bảo mật của các thành phần ở tất cả các giai đoạn của quá trình phần mềm xâm nhập vào tổ chức, từ thời điểm tạo hoặc mua chúng đến giai đoạn sử dụng. OSA cũng cho phép bạn thay thế một số thành phần nhất định nếu thiếu sót của chúng không thể khắc phục được.
Sử dụng Solar appScreener để xây dựng quy trình phát triển an toàn
Không có nhiều sản phẩm trên thị trường bảo mật thông tin có thể được sử dụng toàn diện để thực hiện quy trình phát triển bảo mật. Một trong số đó là Solar appScreener, bao gồm SAST, DAST, SCS và SCA, cho phép bạn tích hợp vào chu trình phát triển phần mềm bảo mật và đào tạo nhân viên những kiến thức cơ bản về DevSecOps.
Solar appScreener hỗ trợ 36 ngôn ngữ lập trình. Để giảm thiểu số lượng lỗ hổng bị bỏ sót trong mã và kết quả dương tính giả, sản phẩm triển khai công nghệ Fuzzy Logic Engine đã được cấp bằng sáng chế, sử dụng bộ máy toán học logic mờ và là bí quyết công nghệ của Solar Group.
Hãy xem một ví dụ về tích hợp appScreener vào SDLC. Sơ đồ quy trình phát triển phần mềm được thể hiện trong Hình 3.
Hình 3. Tích hợp appScreener vào quy trình phát triển an toàn
Như bạn có thể thấy, sau khi xây dựng dự án trong CI, việc kiểm tra tĩnh theo lịch trình (SAST/SCA) sẽ được thực hiện. Kết quả được nhóm IS xác minh.
Hình 4. Kết quả phân tích sử dụng SCA
Hình 5. Kết quả phân tích bằng SAST
Yêu cầu sửa mã được tạo trong Jira. Sau khi các nhà phát triển sửa các lỗ hổng, dự án sẽ được gửi trở lại CI, từ đó nó sẽ đi vào môi trường thử nghiệm. Bước tiếp theo là quét ứng dụng động để tìm lỗ hổng (DAST).
Hình 6. Kết quả phân tích DAST
Sau khi thử nghiệm động, giai đoạn xác minh kết quả thu được của nhóm bảo mật thông tin và tạo ứng dụng để sửa các lỗ hổng sẽ bắt đầu lại.
Sau khi kết quả của tất cả các lần quét đều đạt yêu cầu, ứng dụng sẽ được chuyển sang các giai đoạn tiếp theo của vòng đời (tiền sản xuất, sản xuất).
kết luận
Để đảm bảo tính bảo mật của phần mềm đang được phát triển, điều tối ưu là trước tiên hãy triển khai các quy trình DevSecOps như vậy và chỉ sau đó mới triển khai các công cụ cụ thể để phân tích mã. Đồng thời, nên triển khai toàn diện các công cụ: SAST, DAST, OSA. Điều này là cần thiết để kiểm tra mã ở các chế độ hoạt động khác nhau và xác định thêm các lỗ hổng cũng như chức năng chưa được khai báo. Nếu không thể triển khai tất cả các công cụ cùng một lúc thì nên kích hoạt SAST và OSA trước. Chúng tôi đã xem xét việc triển khai và sử dụng một sản phẩm có chức năng SAST, DAST và OSA, được giới thiệu trên thị trường nội địa, sử dụng ví dụ về Solar appScreener.
