1 trên 100: Cách thiết kế các đội để thu hẹp khoảng cách an ninh

1 trên 100

Ngay cả khi bạn làm việc cho một tổ chức lớn, rất có thể bạn có thể ghi nhớ tên của tất cả những người bảo mật làm việc trong CNTT. Theo một khảo sát gần đây, tỷ lệ của các nhà phát triển so với bảo mật là 100: 1, theo nghiên cứu gần đây (cùng một nghiên cứu chỉ ra tỷ lệ 10: 1 của các nhà phát triển so với ops). Các nghiên cứu trước đây đã báo cáo tỷ lệ từ 100: 3 đến 100: 6, do đó, có một số tiến bộ nhưng không đủ nhanh.

Điều đó không tốt cho các tổ chức này. Khả năng giải quyết các quy định bảo vệ quyền riêng tư dữ liệu sắp tới như Liên minh châu Âu GDPR và ngăn chặn sự cố tràn dữ liệu thường xuyên xuất hiện trên các tin tức trong những năm qua. Có aren đủ người bảo mật có tay nghề cao hiện nay để lấp đầy khoảng trống. Áp dụng thành công các hoạt động phát triển và vận hành an toàn không chỉ đòi hỏi sự hiểu biết kỹ thuật sâu sắc mà còn cả sự nghiêm túc, sở hữu các kỹ năng giao tiếp, thuyết phục và cân bằng để đạt được sự mua từ các nhóm phát triển và (thường xuyên hơn là không) quản lý cấp cao.

Chúng tôi vẫn còn trong một vòng luẩn quẩn mà chuyên môn bảo mật không đủ hấp dẫn bởi vì, trong lịch sử, các công ty không được ưu tiên bảo mật đủ. Những công ty tương tự hiện đang phải đối mặt với nhu cầu ngày càng tăng đối với trò chơi bảo mật của họ, nhưng họ thiếu người.

Vì vậy, những lựa chọn nào chúng ta phải thu hẹp khoảng cách bảo mật này?

Trước tiên, hãy làm rõ rằng việc tự động hóa kiểm tra bảo mật cơ bản (như lỗ hổng của bên thứ ba) và hướng dẫn mã hóa và tích hợp bảo mật trong đường ống phân phối sẽ là điều không tưởng đối với bất kỳ nhóm phát triển sản phẩm nào hiện nay. Bộ công cụ trong DevSecOps tiếp tục mở rộng và cả các yêu cầu cấp cộng đồng và cấp doanh nghiệp đều được phục vụ tốt.

Vậy đâu là khoảng trống? Nó có tên trong trò chơi tấn công của hacker, một cuộc tìm kiếm liên tục tìm kiếm các vectơ tấn công tiềm năng mới trong các ứng dụng của chúng tôi Và nó cũng trong nhiệm vụ khó khăn là phân tích rủi ro có ý nghĩa và mô hình hóa mối đe dọa và chuyển nó thành hành động và ưu tiên. Những điều này đòi hỏi tư duy bảo mật sâu sắc và nền tảng, nó không phải là thứ mà các nhóm phát triển sản phẩm có thể được yêu cầu đảm nhận khi tải thêm nhận thức lên trên các trách nhiệm hiện có của họ.

Công việc mà Matthew Skelton và tôi đã thực hiện nghiên cứu, lập danh mục và giải thích làm thế nào các cấu trúc liên kết DevOps khác nhau có thể đóng một vai trò quan trọng trong việc tiến hành hoặc ngăn chặn việc áp dụng DevOps phù hợp với vấn đề trong tay.

Hai cấu trúc liên kết nhóm riêng biệt (và có thể bổ sung) xuất hiện trong tâm trí:

A) Trách nhiệm bảo mật được chia sẻ hoàn toàn

B) Bảo mật như một nhóm kích hoạt

Sự khác biệt, ưu và nhược điểm của từng phương pháp là gì?

Trách nhiệm bảo mật được chia sẻ hoàn toàn có nghĩa là mỗi nhóm phát triển sản phẩm tích hợp ít nhất một thành viên nhóm hình chữ T tập trung vào bảo mật. Cách tiếp cận này là đầy đủ khi tổ chức cố gắng cho các nhóm phát triển sản phẩm tự trị đa chức năng. Nhân viên bảo mật cần có khả năng chuyển các mối đe dọa bảo mật phức tạp thành các câu chuyện bảo mật có thể hành động và các tiêu chí chấp nhận mà nhóm có thể hiểu và thực hiện theo quan điểm kỹ thuật.

Họ cũng phải có khả năng truyền đạt rủi ro và chi phí tiềm năng cho tổ chức (tuân thủ, doanh thu và danh tiếng) theo cách mà chủ doanh nghiệp có thể hiểu và ưu tiên. Mặt khác, họ nên sẵn sàng thực hiện các nhiệm vụ không liên quan đến bảo mật khi cần thiết. Theo thời gian, quyền sở hữu phân tích và triển khai bảo mật sẽ lan rộng trong nhóm trong khi nhân viên bảo mật hình chữ T có thể giữ chuyên môn về việc tuân thủ các thực tiễn tốt nhất về bảo mật, phương pháp và công cụ mới, tạo điều kiện cho các hội thảo liên quan đến bảo mật và bảo mật sản phẩm hàng đầu chiến lược.

Mục tiêu không phải là để nhân viên an ninh được phân bổ tất cả các công việc bảo mật, nếu không, chúng tôi chỉ chuyển một silo ở cấp vĩ mô (nhóm bảo mật bị cô lập) sang cấp vi mô (thành viên nhóm bị cô lập).
Mỗi nhóm sản phẩm - được mô tả là một vòng tròn màu vàng - có 7 đến 9 thành viên trong nhóm, trong đó ít nhất một người là nhân viên bảo mật hình chữ T - được mô tả bên trong một vòng tròn màu xanh lá cây - nhưng những người khác cũng tham gia vào công việc bảo mật

Tất nhiên, vẫn còn một nơi quan trọng cho một cái nhìn tập trung về bảo mật trên nhiều sản phẩm và lĩnh vực kinh doanh trong tổ chức. Chia sẻ kinh nghiệm, cách tiếp cận và kết quả là rất quan trọng. Nhưng điều này có thể dưới hình thức một cộng đồng thực hành hoặc bang hội (theo cách nói của Spotify) của các cá nhân có động lực tập hợp thường xuyên, thay vì một nhóm chuyên dụng (mặc dù điều đó có thể hoạt động tốt, nếu bạn có phương tiện).

Ưu

  • Quyền sở hữu an ninh nhóm sẽ tăng lên, dẫn đến giải quyết sự cố an ninh nhanh hơn (không tầm thường) và, có lẽ quan trọng hơn là học hỏi từ họ để tránh lặp lại nỗi đau trong tương lai.
  • Vì các đội có giới hạn kích thước tự nhiên (8 người9), tỷ lệ nhân viên CNTT so với nhân viên bảo mật (hình chữ T) sẽ tiến gần hơn đến 10: 1 theo thời gian với cấu trúc liên kết của nhóm này. Sự đa dạng trong nền tảng kỹ thuật một mình sẽ mang lại lợi ích về cách tiếp cận các vấn đề và ưu tiên.
  • Việc chuyển sang cấu trúc liên kết này sẽ gửi một tín hiệu không thể phủ nhận tới mọi người trong tổ chức rằng an ninh hiện là công dân hạng nhất trong các sản phẩm của chúng tôi.

Nhược điểm

  • Chi phí tìm kiếm và tuyển dụng (có thể yêu cầu các gói hào phóng) và tăng cường thêm 9 người bảo mật (trong một tổ chức với 100 nhà phát triển) sẽ là một vấn đề nghiêm trọng (theo phần giới thiệu của bài đăng này). Dự kiến ​​quá trình chuyển đổi này sẽ mất một khoảng thời gian đáng kể, trong đó bạn cần phải có sự kết hợp của các mô hình (một số nhóm sản phẩm tự trị và một số vẫn phụ thuộc vào một nhóm tập trung) và suy nghĩ về chiến lược chọn đội nào đi trước. Ví dụ: bắt đầu bằng cách chỉ định những người bảo mật có kinh nghiệm hơn cho các nhóm làm việc trên các sản phẩm rủi ro hơn trong tổ chức của bạn.
  • Các đội tự trị có hiệu suất cao dựa trên sự ổn định và biết được các điểm mạnh và yếu của nhau. Bất kỳ thay đổi nào đối với thành phần nhóm, thậm chí là một người, chắc chắn sẽ gây ra sự gián đoạn. Nhóm nghiên cứu có thể cảm thấy nó đang cung cấp ít hơn và trở nên kém năng suất hơn trong khi đảm nhận góc độ bảo mật mới. Điều quan trọng là mọi người đều hiểu điều này là bình thường và được chấp nhận.
  • Thiếu một điểm liên lạc tập trung cho mối quan tâm an ninh. Các nhà quản lý cấp cao, đặc biệt, có thể cảm thấy có một người không phải là người nắm giữ an ninh trong một cấu trúc phi tập trung. Đảm bảo có các kênh liên lạc và mọi người có thể gửi yêu cầu thông tin bảo mật đến đúng nhóm (hoặc cộng đồng thực hành) có thể giúp đỡ ở đây.

Heuristic

  • Có phải tổ chức của bạn đã có các nhóm chức năng chéo, tích hợp các chủ doanh nghiệp và chịu trách nhiệm về QA và giám sát và chạy các ứng dụng mà họ phát triển?
  • Các sản phẩm (hoặc dịch vụ) hiển thị hồ sơ rủi ro rất khác nhau?
  • Các sản phẩm (hoặc dịch vụ) có chạy trên các ngăn xếp công nghệ và cơ sở hạ tầng không đồng nhất không?

Nếu câu trả lời cho một trong những câu hỏi trên là khẳng định, thì cấu trúc liên kết này có thể chứng minh phù hợp để giải quyết khoảng cách bảo mật.

Bảo mật như một nhóm kích hoạt có nghĩa là một nhóm bảo mật chuyên dụng cung cấp hỗ trợ và hướng dẫn (ví dụ: tạo ra các nguyên tắc phát triển an toàn) cho các nhóm phát triển sản phẩm.

Điều quan trọng, nhóm bảo mật tập trung không thực hiện công việc phân tích và thực hiện bảo mật thực tế, thay vào đó thúc đẩy và hướng dẫn nó khi cần thiết.

Điều quan trọng không kém là nhóm này tham gia ngay từ khi bắt đầu dự án hoặc phát hành để giúp nhóm sản phẩm xem xét ý nghĩa bảo mật, cách tiếp cận và thực tiễn ở mỗi giai đoạn của vòng đời.

Một nhóm bảo mật chuyển đổi - được mô tả theo chiều dọc màu xám - hỗ trợ ba nhóm sản phẩm - được mô tả theo chiều ngang màu cam - dẫn đến trách nhiệm chung về bảo mật - được mô tả như một vòng tròn màu lục nhạt

Nhiều tổ chức đã thực hiện phương pháp này, bao gồm Spotify và Sportradar. Nó đòi hỏi một sự thay đổi cấu trúc ít quyết liệt hơn từ nhóm bảo mật truyền thống của silo, vì chúng tôi về cơ bản thay đổi trách nhiệm của nhóm này (hướng dẫn và hỗ trợ thay vì thực hiện). Nhưng điều đó có thể khiến phần còn lại của tổ chức khó nhận ra rằng các nhóm sản phẩm dự kiến ​​sẽ có quyền sở hữu cao hơn về bảo mật hệ thống của họ.

Pablo Jensen, CTO tại Sportradar, gần đây đã nói về đội bảo mật thông tin chuyên dụng của họ Vai trò thúc đẩy các nguyên tắc và chính sách bảo mật phối hợp chặt chẽ với các nhóm sản phẩm, lắng nghe phản hồi của họ và lặp đi lặp lại theo thời gian. Một trong những cổng vòng đời dự án của họ là một tập thể dục để bắt đầu phát triển, cần có sự chấp thuận của đội an ninh, đủ suy nghĩ đã được đưa ra cho ý nghĩa bảo mật và công việc được lên kế hoạch phù hợp. Nhóm này báo cáo trực tiếp cho CEO và có thẩm quyền dừng việc ra mắt sản phẩm nếu cần thiết.

Vai trò của một nhóm bảo mật tập trung cung cấp hướng dẫn thay vì thực hiện công việc bảo mật sản phẩm (Tín dụng: Pablo Jensen, CTO tại Sportradar - trình chiếu từ bài thuyết trình QCon London 2018 của anh ấy)

Ưu

  • Khung thời gian ngắn hơn để chuyển sang mô hình hỗ trợ từ một nhóm bảo mật bị cô lập truyền thống thực hiện phần lớn công việc bảo mật.
  • Sẽ không yêu cầu một số lượng lớn các nhân viên mới, do đó tránh được tất cả các nỗ lực liên quan và gián đoạn nhóm tiềm năng. Trọng tâm ở đây phải là đảm bảo toàn bộ đội ngũ cho phép có tất cả các kỹ năng mềm cần thiết, bên trên các kỹ năng kỹ thuật.

Nhược điểm

  • Đội ngũ này cần phải thành thạo giao tiếp hiệu quả, mà bản thân nó là một điều tốt. Đây là một kỹ năng cần được mài giũa theo thời gian, do đó ban đầu đầu tư vào trợ giúp bên ngoài hoặc bên trong để xác định chiến lược truyền thông và nội dung giám tuyển có thể được yêu cầu.
  • Chuyển sang mô hình này phát đi một tín hiệu yếu về sự thay đổi trong trọng tâm bảo mật. Tín hiệu cần được khuếch đại và có thể yêu cầu lặp lại trong một thời gian dài cho đến khi nó chìm trong một phần của văn hóa org.
  • Giới thiệu trách nhiệm, thực tiễn và công cụ mới có thể là thách thức đối với các nhóm phát triển sản phẩm đã ở đỉnh cao năng lực của họ. Nhóm hỗ trợ tập trung có thể bị choáng ngợp với các yêu cầu trợ giúp và chịu áp lực phải giúp thực hiện bảo mật sản phẩm, điều này sẽ đánh bại toàn bộ mục đích của mô hình.
  • Theo thời gian, sự tập trung bảo mật bên trong các nhóm sản phẩm có thể mất dần khi không có nhân viên an ninh tham gia vào kế hoạch phát hành / chạy nước rút của nhóm và các cuộc nổi bật hàng ngày. Một số loại quản trị sẽ cần phải được đưa ra để tránh hiệu ứng này.

Heuristic

  • Có một số lượng nhỏ các nhóm phát triển sản phẩm (cho phép cộng tác chặt chẽ hơn với nhóm bảo mật) không?
  • Các thành viên trong nhóm sản phẩm có thể hiện sự quan tâm đến các chủ đề bảo mật và sự thèm học không (ví dụ như tham dự các hội nghị kỹ thuật hoặc các cuộc họp)?
  • Có phải việc giải quyết các sự cố liên quan đến an ninh trong sản xuất đương nhiên liên quan đến cả người bảo mật và người phát triển (trái ngược với một trò chơi đổ lỗi trong đó mỗi bên tránh xa trách nhiệm)?

Nếu câu trả lời cho một trong những câu hỏi trên là khẳng định, thì cấu trúc liên kết này có thể chứng minh phù hợp để giải quyết khoảng cách bảo mật.

Phần kết luận

DevSecOps đã nâng cao hồ sơ bảo mật trong CNTT và các luồng vi phạm dữ liệu nghiêm trọng thường xuyên đã phơi bày khoảng cách bảo mật trong hầu hết các tổ chức. Trong bài đăng này, tôi đã trình bày một vài cách tiếp cận khả thi để thu hẹp khoảng cách đó (chia sẻ trách nhiệm bảo mật hoàn toàn so với bảo mật như một nhóm cho phép), cùng với những ưu và nhược điểm của họ, và chẩn đoán dựa trên ngữ cảnh.

Hãy nhớ thiết kế nhóm không nên tĩnh. Các tổ chức, con người và quy trình phát triển tự nhiên theo thời gian và những gì ngày hôm nay phù hợp nhất có thể là trở ngại của ngày mai đối với phần mềm nhanh hơn và an toàn hơn. Nó có khả năng là một tổ chức trước tiên sẽ chuyển từ cách tiếp cận silo bảo mật truyền thống sang bảo mật trên mạng khi cho phép mô hình đội hình đầu tiên và theo thời gian chuyển sang một trách nhiệm bảo mật được chia sẻ đầy đủ về cấu trúc, khi nhận thức và chuyên môn về bảo mật lan rộng trong các nhóm sản phẩm.

Những cấu trúc liên kết và chiến lược bảo mật nào khác mà bạn đã thấy trong các tổ chức hoặc khách hàng của mình? Vui lòng bình luận dưới đây hoặc gửi email cho tôi tại:

tôi tại manuelpais chấm net