Logo Zephyrnet

Phần mềm & Bảo mật: Cách nâng cao vấn đề bảo mật chuỗi cung ứng trong chương trình nghị sự

Ngày:

COMMENTARY

Sau log4j, chuỗi cung ứng phần mềm đang được giám sát chặt chẽ hơn về các vấn đề bảo mật. Chính phủ Mỹ hóa đơn phần mềm bắt buộc của vật liệu (SBOM) cho các dự án phần mềm liên bang để các nhóm bảo mật có thể hiểu được mọi rủi ro tiềm ẩn từ các thành phần phần mềm. Cơ quan An ninh mạng và Cơ sở hạ tầng (CISA), Ủy ban Liên minh Châu Âu, Trung tâm An ninh mạng Quốc gia của Vương quốc Anh và Nhật Bản đang hợp tác để làm cho SBOM trở nên hữu ích hơn và có giá trị hơn.

Tuy nhiên, có những vấn đề cần khắc phục. Trên thực tế, việc triển khai SBOM vẫn nằm trong danh sách ưu tiên của nhiều giám đốc an ninh thông tin (CISO). Khi tôi hỏi các CISO ở Anh tại sao, vấn đề là ở mức độ ưu tiên. Khi bạn có quá nhiều vấn đề cần giải quyết, SBOM mang lại bao nhiêu giá trị cho ngày hôm nay?

Bên cạnh đó, bạn còn có vấn đề ai chịu trách nhiệm bảo trì phần mềm liên quan. Đây có phải là ứng dụng của bên thứ nhất mà nhóm nội bộ của bạn đã tổng hợp hay ứng dụng của bên thứ ba mà bạn đã mua từ nhà cung cấp? Còn phần mềm thuê ngoài do nhà phát triển bên thứ ba phát triển cho tổ chức của bạn thì sao? Ai sẽ chịu trách nhiệm quản lý SBOM cũng như quy tắc?

Bảo mật chuỗi cung ứng phần mềm và phân công trách nhiệm

Trong thế giới phần mềm, việc theo dõi những gì đang được sử dụng là một thách thức vì khối lượng công việc có thể được tạo ra và dừng lại theo từng phút tùy theo nhu cầu. Tuy nhiên, việc có danh sách chính xác về những gì đã được cài đặt, những gì đang chạy và những gì có thể dễ bị tổn thương sẽ rất cần thiết khi quản lý rủi ro.

Tất cả điều này có ý nghĩa về mặt lý thuyết. Vậy tại sao nó lại rơi vào danh sách ưu tiên của CISO, nhóm bảo mật và nhà phát triển? Thách thức là làm thế nào các chương trình này được triển khai trong thực tế. Với quá nhiều công nghệ thông tin cần chăm sóc, quá nhiều thay đổi diễn ra và quá nhiều phần mềm cần theo dõi, dữ liệu có thể khiến các nhóm choáng ngợp.

Việc thiết lập trách nhiệm về bảo mật và quản lý ứng dụng phải tập trung vào các trách nhiệm thực tế. Ví dụ, phần mềm thường được xây dựng bởi các nhà cung cấp thuê ngoài. Các hợp đồng này phải bao gồm việc phân phối SBOM như một phần của khoản tiền gửi để phát triển, cũng như ai sẽ chịu trách nhiệm duy trì tài liệu đó theo thời gian. Yếu tố quan trọng nhất là ai đó phải chịu trách nhiệm và những người còn lại trong tổ chức cũng biết trách nhiệm của họ.

Giúp các nhóm cộng tác hiệu quả

SBOM đang trưởng thành nhanh chóng, nhưng chúng vẫn còn một chặng đường dài trước khi được chuẩn hóa. Thông thường, các vấn đề bảo mật trở thành câu tục ngữ nóng hổi, ​​​​được truyền sang người tiếp theo càng nhanh càng tốt. Việc giao cho nhà phát triển hàng trăm hoặc hàng nghìn vấn đề phần mềm cần khắc phục không làm cho những sửa lỗi đó xảy ra một cách kỳ diệu; trên thực tế, nó có thể dẫn đến nhiều vấn đề hơn khi các nhóm không biết phải tập trung vào điều gì.

Để giải quyết vấn đề này, chúng ta cần triển khai các biện pháp thực hành tốt hơn về bảo mật chuỗi cung ứng phần mềm, bắt đầu với SBOM và quản lý tài sản, sau đó là các cuộc thảo luận về mức độ ưu tiên thích hợp giữa nhóm bảo mật và nhà phát triển. Cả hai nhóm phải tự động hóa nhiều quy trình xung quanh việc khắc phục sự cố hoặc triển khai các bản cập nhật.

Về mặt bảo mật, điều này sẽ liên quan đến việc vá lỗi tự động cho các vấn đề có rủi ro thấp. Đối với các nhà phát triển, điều đó có nghĩa là triển khai bảo mật bằng các phương pháp thiết kế. Bảo mật CNTT có thể cung cấp các công cụ tích hợp sớm vào quy trình làm việc của nhà phát triển để có thể khắc phục sự cố sớm hơn. Bảo mật cũng có thể trợ giúp bằng cách gắn cờ các cách khác để loại bỏ sự cố.

Ví dụ: một CISO mà tôi làm việc cùng đã khiến các nhóm mất tinh thần trong cả lĩnh vực bảo mật và phát triển phần mềm. Hơn một triệu sự cố phần mềm và lỗ hổng bảo mật đã tồn tại trên các thiết bị đầu cuối, ứng dụng và cơ sở hạ tầng. Để biết nguyên nhân cốt lõi của vấn đề này, chúng tôi đã xem xét vấn đề tồn tại ở đâu. Điều nhanh chóng trở nên rõ ràng là không có ai chịu trách nhiệm trực tiếp về các bản cập nhật trong thư viện hình ảnh phần mềm. Cả hai bên đều nỗ lực giải quyết các vấn đề, nhưng mỗi khi một hình ảnh mới được tạo ra từ thư viện đó, các vấn đề “cũ” lại xuất hiện. Những hình ảnh đó cũng chứa nhiều phiên bản Java, khiến chúng chịu trách nhiệm phát hiện hàng trăm lỗ hổng trên mỗi hình ảnh.

Tập hợp mọi người xung quanh bàn và sửa những hình ảnh đó sẽ giảm đáng kể số lượng lỗ hổng và cảnh báo. Nhóm đã nhận thấy số lượng lỗ hổng nổi bật của mình giảm đi một nửa, giải phóng thời gian và khiến cả hai bên đánh giá cao đối phương hơn.

Loại thảo luận này không thể thực hiện được nếu không có dữ liệu. Nhận được nhiều thông tin chi tiết hơn sẽ giúp bạn ưu tiên trên tất cả các hệ thống của mình, bao gồm cả phần mềm của bên thứ nhất, để bạn có thể thúc đẩy sự cộng tác nhiều hơn, thay đổi thực sự và thành công thực sự cho nhóm của mình.

tại chỗ_img

Tin tức mới nhất

tại chỗ_img