Bán phần mềm cho Chính phủ Hoa Kỳ? Biết chứng thực bảo mật trước tiên

Bán phần mềm cho Chính phủ Hoa Kỳ? Biết chứng thực bảo mật trước tiên

Dấu thời gian: 7:2023 sáng ngày 10 tháng 00 năm XNUMX
Bán phần mềm cho Chính phủ Hoa Kỳ? Biết chứng thực bảo mật đầu tiên Thông minh dữ liệu PlatoBlockchain. Tìm kiếm dọc. Ái.

Trong vài tháng qua, chính phủ Hoa Kỳ đã đưa ra một số yêu cầu mới ảnh hưởng đến các tổ chức bán phần mềm cho các cơ quan chính phủ. Vì những yêu cầu mới này rất phức tạp nên nhiều nhà lãnh đạo vẫn chưa chắc tổ chức của họ sẽ bị ảnh hưởng như thế nào. Trong bài viết này, tôi sẽ chia sẻ một số khái niệm quan trọng nhất mà bạn cần hiểu để có thể bảo vệ hoạt động kinh doanh chính phủ của mình và luôn tuân thủ.

Yêu cầu bảo mật phần mềm mới: Điều gì đã thay đổi?

Trong nhiều năm qua, các sự cố bảo mật cấp cao như những sự cố đã ảnh hưởng đến SolarWinds và gói nguồn mở log4j đã làm tăng sự chú ý của chính phủ về bảo mật phần mềm. Bắt đầu với Sắc lệnh hành pháp 14028 của Nhà Trắng về việc cải thiện an ninh mạng của quốc gia vào tháng 2021 năm XNUMX, một loạt hành động trong hai năm qua đã dẫn đến một loạt yêu cầu rõ ràng tác động đến bất kỳ nhà cung cấp phần mềm nào của chính phủ.

Trong tương lai, bất kỳ tổ chức nào bán phần mềm cho chính phủ Hoa Kỳ sẽ phải tự chứng thực rằng phần mềm đó tuân thủ các thông lệ phát triển phần mềm an toàn do chính phủ nêu trong Đạo luật này. Khung phát triển phần mềm bảo mật NIST.

Một trong những điều quan trọng nhất cần hiểu là các tổ chức không chỉ phải chứng thực rằng bản thân họ tuân theo các thực tiễn này đối với mã phần mềm mà họ viết mà còn các thành phần nguồn mở mà họ đưa vào ứng dụng của mình cũng tuân theo các thực tiễn này.

Vào đầu tháng 6, chính phủ đã tái khẳng định những yêu cầu này trong Bản ghi nhớ OMB M-23-16 (PDF) và đặt ra thời hạn tuân thủ đang đến rất nhanh — có thể đến vào quý 4 năm nay (đối với phần mềm quan trọng) và quý đầu tiên của năm tới (đối với tất cả các phần mềm khác).

Điều này có nghĩa là trong vài tháng tới, các tổ chức sẽ phải nỗ lực tìm hiểu các yêu cầu chứng thực mới này và xác định cách thức tổ chức của họ sẽ tuân thủ, đối với cả mã họ tự viết và các thành phần nguồn mở mà họ đưa vào các sản phẩm phần mềm của mình.

Theo M-23-16, hình phạt cho việc không tuân thủ là rất nặng:

“Cơ quan [liên bang] phải ngừng sử dụng phần mềm nếu cơ quan nhận thấy tài liệu của nhà sản xuất phần mềm không đạt yêu cầu hoặc nếu cơ quan không thể xác nhận rằng nhà sản xuất đã xác định được các hoạt động mà họ không thể chứng thực…”

Trường hợp đặc biệt thách thức của nguồn mở

Khi nhiều tổ chức đang tìm hiểu sâu hơn về các yêu cầu chứng thực, họ nhận thấy rằng việc tuân thủ, đặc biệt là với thời hạn chặt chẽ, có thể là một thách thức. NIST SSDF là một khuôn khổ phức tạp về bảo mật và sẽ mất thời gian để các tổ chức không chỉ đảm bảo tuân thủ các biện pháp này mà còn ghi lại chi tiết các biện pháp thực hành của họ.

Nhưng thậm chí còn đáng ngại hơn là chính phủ đang yêu cầu các nhà cung cấp chứng thực các biện pháp bảo mật cho toàn bộ sản phẩm phần mềm của họ, bao gồm các thành phần nguồn mở trong phần mềm đó. Ngày nay, phần mềm hiện đại thường được tạo thành chủ yếu từ các thành phần nguồn mở được ghép lại với nhau, cùng với một số phần mềm tùy chỉnh. Trong nghiên cứu của chúng tôi, chúng tôi đã tìm thấy rằng hơn 90% ứng dụng chứa các thành phần nguồn mở, và trong nhiều trường hợp nguồn mở chiếm hơn 70% cơ sở mã.

Tổ chức của bạn có thể chứng thực các biện pháp bảo mật của riêng mình, nhưng làm thế nào bạn có thể chứng thực chính xác các biện pháp bảo mật mà các nhà bảo trì nguồn mở tuân theo, những người viết và duy trì mã nguồn mở mà bạn sử dụng trong các ứng dụng của mình?

Đó là một thách thức lớn và các tổ chức đang tìm kiếm các nhà bảo trì nguồn mở để biết thêm thông tin về các biện pháp bảo mật của họ. Thật không may, nhiều người trong số những người bảo trì nguồn mở này là những tình nguyện viên không được trả lương, họ làm việc trên nguồn mở như một sở thích vào ban đêm và cuối tuần. Vì vậy, việc yêu cầu họ thực hiện thêm công việc để xác thực rằng các biện pháp bảo mật của họ phù hợp với các tiêu chuẩn cao do NIST SSDF đặt ra là không thực tế.

Một cách mà các tổ chức có thể tránh được thách thức này là không sử dụng nguồn mở trong các ứng dụng của họ. Và mặc dù bề ngoài điều đó nghe có vẻ giống như một giải pháp đơn giản, nhưng nó cũng là một giải pháp thay thế ngày càng không khả thi, vì nguồn mở theo nhiều cách đã trở thành nền tảng phát triển hiện đại trên thực tế.

Cách tốt hơn để giải quyết vấn đề này là đảm bảo những người duy trì các gói mà bạn tin cậy đang được trả tiền để thực hiện công việc bảo mật quan trọng này.

Điều này có thể yêu cầu bạn thực hiện nghiên cứu bổ sung để đảm bảo các thành phần nguồn mở mà bạn đang sử dụng có những người bảo trì đằng sau chúng và được trả tiền — bởi các nhà hảo tâm của công ty, bởi các quỹ hoặc bởi các nỗ lực thương mại — để xác thực các gói của họ đáp ứng các tiêu chuẩn bảo mật quan trọng này. Hoặc thậm chí bạn có thể tự mình liên hệ với những người bảo trì và trở thành nhà tài trợ doanh nghiệp cho công việc của họ. Khi thiết kế phương pháp tiếp cận của bạn, hãy nhớ rằng hầu hết các ứng dụng hiện đại không cần thiết đều có hàng nghìn phần phụ thuộc nguồn mở riêng biệt, mỗi phần phụ thuộc được tạo và duy trì bởi một cá nhân hoặc nhóm khác nhau, vì vậy nỗ lực thủ công để mở rộng quy mô phương pháp này là đáng kể.

Một bước tiến đầy thách thức nhưng cần thiết

Những yêu cầu này có thể khó tuân thủ, nhưng trong bối cảnh các lỗ hổng bảo mật ngày càng gia tăng gây tổn hại lớn cho khu vực công và tư nhân, chúng là một bước tiến cần thiết. Chính phủ Hoa Kỳ là người mua hàng hóa và dịch vụ lớn nhất trên thế giới và điều đó đúng với CNTT cũng như các lĩnh vực khác. Bằng cách sử dụng sức mua của mình để buộc phải cải thiện tiêu chuẩn bảo mật tổng thể cho phần mềm, chính phủ đang giúp đảm bảo một tương lai an toàn hơn, bảo mật hơn.

Dấu thời gian:

Thêm từ Đọc tối