Những điều căn bản về bảo mật phần mềm cho quản lý lập trình phần mềm

Quản Trị Mạng - Có ít đi những lổ hổng bảo mật đồng nghĩa với việc chất lượng của phần mềm tốt hơn và giá thành giảm đi. Merkow và Raghavan đã cung cấp những hướng dẫn chuyên môn trong việc xây dựng và quản lý một phần mềm bảo mật đáp ứng được những tiêu chí trên.

Nếu chúng ta không học được bất kì một điều gì từ hơn 60 năm phát triển phần mềm với độ bảo mật của nó, sẽ không ngẫu nhiên có code chất lượng cao. Chính phủ các quốc gia đều biết được chất lượng và bảo mật cần phải được xác định chính xác, được thiết kế và triển khai từng bước trong suốt chu trình phát triển phần mềm (SDLC - Software Development Life - Cycle).

Các chính phủ luôn chắc chắn trong việc chỉ cho phép những phần mềm có khả năng mới được sử dụng để bảo vệ bí mật quốc gia. Tuy nhiên, quan điểm này không bao giờ được tiết lộ với thế giới thương mại và điều chúng ta thiếu ngày nay là nghi vấn về độ tin cậy của một nhóm ứng dụng.

Vì vậy, bài báo này sẽ nhấn mạnh về các vấn đề và cung cấp các giải pháp nhằm giúp bạn tránh được lặp lại các lỗi lầm gây ra các phần mềm và hệ thống không bảo mật và không đáng tin cậy. Chúng ta sẽ đề cập tới mong muốn của mọi người khi họ có một phần mềm và điều thực sự họ nhận được là gì, lý do gây ra những lỗ hổng, và khi bạn là một người quản lý, bạn có thể làm gì để nâng cấp những thói quen phát triển phần mềm của công ty mình cũng như đánh giá sự tiến bộ thành công của bạn.

Người dùng mong chờ điều gì ở phần mềm?

Phần mềm thực sự tiện ích với những gì chúng có thể làm được. Mọi người mua phần mềm bởi nó có thể đáp ứng được nhu cầu của họ nhằm thực hiện một số chức năng. Những chức năng này (hoặc tính năng) có thể đơn giản như cho phép người dùng viết một bức thư hoặc có thể phức tạp như tính toán lượng tiêu tốn xăng của chặng đường một chiếc tên lửa sắp được phóng lên mặt trăng.

Người dùng cũng (sai lầm) hay cho rằng phần mềm họ mua được viết với code có chất lượng. Khi bạn mua một gói phần mềm, bạn thường thừa nhận chúng sẽ hoạt động giống như những gì đã được quảng cáo và bạn cũng sẽ không nghĩ về việc chương trình này sẽ thực hiện công việc của nó tốt như thế nào.

Sự thật đáng buồn là hầu hết phần mềm vẫn có những sai sót và những sai sót này có thể đe dọa ảnh hưởng tới độ bảo mật và an toàn của bất kì một hệ thống nào chúng đang hoạt động trên. Những sai sót này không chỉ xuất hiện trên chiếc máy tính chúng ta sử dụng hàng ngày, mà còn có mặt ở những thiết bị khác, ví như điện thoại di động và các thiết bị y tế và những dịch vụ khác như ngân hàng và tài chính, năng lượng, và viễn thông.

Các nhà lập trình được dạy để viết code – họ không được dạy cách viết code tốt.

Các tổ chức khuyến khích các nhà lập trình viết nhiều code, hơn là vì code tốt trong bối cảnh code giá rẻ và code được phát triển nhanh chóng đang thống trị thị trường.

Đặc biệt, các ứng dụng Web rất dễ có khả năng bị hỏng với một số loại lỗ hổng (ví dụ Cross Site Scripting (XSS)) trừ phi nhà lập trình có nỗ lực ngăn chặn chúng. Nếu nhà lập trình viên thất bại trong việc thêm những đoạn mã hóa đầu ra và xác nhận đầu vào phù hợp, ứng dụng này sẽ dễ dàng bị tấn công theo mặc định tới XSS.

Đối với một nhà lập trình, phần mềm này có thể hoạt động như mục tiêu làm việc đặt ra nhưng không bao giờ kiểm tra xem chúng hoạt động thế nào khi chúng có một số mã độc hoặc bị tấn công trực tiếp.

Viết phần mềm, giống như khi lái một chiếc xe, là một thói quen. Trước khi có ai đó dạy chúng ta cách lái xe an toàn, chúng ta hầu như không biết sự nguy hiểm của lái xe và những kỹ năng cần thiết để ngăn chặn hoặc tránh các vụ tai nạn. Ô tô thường có những cơ chế an toàn được xây dựng sẵn, nhưng khi lái xe, chúng ta sẽ phải hoàn toàn sử dụng các kỹ năng lái xe an toàn.

Vấn đề này tệ đến mức nào?

Năm 2008, những lỗ hổng được tìm ra từ các phần mềm thương mại đã gia tăng đáng kể – tăng 13,5% so với năm 2007. Độ nghiêm trọng của các lỗ hổng cũng tăng lên với 15,3%. Những lỗ hổng có độ nghiêm trọng vừa có mức tăng 67,5% và có gần 92% các lổ hổng của năm 2008 đều có thể bị khai thác từ xa.

Trong tổng số các lỗ hổng được phát hiện vào năm 2008, chỉ có 47% lỗ hổng có thể vá được bằng các bản vá của nhà cung cấp. Cuối năm 2008, 74% các lỗ hổng ứng dụng web được tiết lộ năm này cũng không có một bản vá nào để vá chúng.

Các ứng dụng Web cũng là của Achilles Heel of Corporate IT Security. Hàng năm, tổ chức này đã chi hàng triệu đô về bảo mật cấu trúc phần mềm của mình – một phần đáng kể trong ngân quỹ toàn năm của hãng. Các khoản chi tiêu cho bảo mật phần mềm tập trung vào phát hiện những lỗ hổng hiện thời trong những phần mềm đang được tổ chức sở hữu và tìm các cách nhằm giảm những nguy cơ khhi sử dụng chúng. Viết lại các phần mềm, cho dù là chữa một lỗi hoặc thay đổi về cơ bản cách làm việc của phần mềm, cũng như ảnh hưởng tới các khoản chi tiêu hàng năm của hãng. Code xấu cũng có ảnh hưởng xấu tới hiệu suất bất cứ khi nào ứng dụng hoặc hệ thống bị lỗi, dẫn đến việc mất mát trực tiếp hoặc gián tiếp tới công việc kinh doanh. Những lỗ hổng khác của ứng dụng Web còn ảnh hưởng xấu tới thương hiệu, danh tiếng, trộm dữ liệu và các vấn đề liên quan tới từ chối dịch vụ.

Hãy tự xây dựng cho mình một bảo mật phần mềm riêng!

Các lỗ hổng phần mềm xuất hện trong phần mềm bởi cùng với đặc điểm kỹ thuật, triển khai và vòng kiểm tra, các yêu cầu dành cho bảo mật phần mềm không được quan tâm và bị xao lãng. Phần mềm chỉ được bảo mật khi nó được thiết kế dành cho bảo mật – hầu hết những sự cố gắng trong việc nâng cấp bảo mật sau khi có vấn đề thậm chí còn phức tạp hơn nhiều so với khi chúng được cân nhắc ngay từ khi mở đầu phát triển.

Để có thể di chuyển la bàn về phát triển những yêu cầu bảo mật phần mềm mà bảo mật nên được xây dựng trong chu trình phát triển và bắt đầu với một công cụ quản lý được hỗ trợ bởi Secure Coding Initiative nhằm nâng cấp được cách nghĩ một tổ chức sẽ thế nào và phát triển phần mềm cho tất cả mọi người có thể sử dụng – từ sử dụng gia đình hoặc bán cho ai đó.

Bất kì một code bảo mật ban đầu nào đều phải đáp ứng được tất cả các bước của chu trình phát triển của một phần mềm. Các chương trình bảo mật được an toàn theo thiết kế, trong suốt quá trình phát triển và theo mặc định. Với bất kì một thay đổi ban đầu nào, giáo dục luôn đóng vai trò quan trọng. Giáo dục là “viên đá đặt nền móng” cho bất kì một sự can thiệp hiệu quả nào nhằm nâng cấp chất lượng phần mềm. Ưu tiên dựa vào những người có kinh nghiệm trong việc phát triển phần mềm có code bảo mật; cũng như rất cần thiết trong việc đào tạo thiết kế an toàn và quản lý code nhằm giúp cho các nhà phân tích, thiết kế và các nhà phát triển có thể hiểu rõ ràng hơn về cách những phân tích chưa hoàn thành, quyết định thiết kế tồi, và các hành động viết code tồi phải chịu trách nhiệm về những lỗ hổng phần mềm và hệ thống.

Một khi đã được phổ biến kiến thức, những người tham dự SDLC sẽ hành động khác đi và bắt đầu hoạt động như cơ chế kiểm tra và cân bằng bên trong giúp nắm bắt được vấn đề sớm hơn cũng như giúp giảm chi phí phát triển và tăng chất lượng hệ thống.

Giáo dục cần chuẩn bị nhân lực có kiến thức cơ bản về lỗ hổng các ứng dụng Web, làm cho họ quen với các công cụ hack, cũng như chuẩn bị cho họ những công cụ và kỹ năng mới giúp họ thực hiện công việc của mình tốt hơn.

Ở những ngày đầu của phát triển phần mềm, các nghiên cứu đã cho thấy chi phí chỉnh sửa các lỗi, lỗ hổng trong thiết kế thấp hơn rất nhiều khi những vấn đề này bị phát hiện và chữa lỗi với các yêu cầu, giai đoạn thiết kế hơn là sau khi họ bắt đầu sản xuất phần mềm. Vì vậy, nếu bạn tiếp hợp các phương pháp bảo mật với chu trình phát triển càng sớm, giá của phần mềm sẽ càng rẻ.

Những phương pháp bảo mật là cải tiến thông thường và bất kì một tổ chức nào đều có thể và nên tiếp nhận chúng với môi trường hiện tại của mình. Không có một cách trực tiếp nào để thực hiện những phương pháp này – mỗi một tổ chức sẽ phải tinh chỉnh và tùy biến chúng sao cho phù hợp với môi trường phát triển và vận hành của mình. Những phương pháp nâng cấp này cũng thêm nhiều trắc nghiệm giải trình và cấu trúc vào trong hệ thống. Hiện nay, có rất nhiều phương pháp phát triển bảo mật phần mềm đáng chú ý, ví như Secure Development Lifecycle (SDL) của Microsoft, Touchpoints của Cigital, và một phương pháp chúng ta sẽ thử nghiệm trong bài này, có tên CLASP.

Comprehensive, Lightweight Application Security Process (CLASP) – Quy trình bảo mật ứng dụng nhẹ nhàng, toàn diện.

Nhóm dự án bảo mật ứng dụng Web mở - OWASP - (Open Web Application Security Project) là một tổ chức mở được sáng lập nhằm cho phép các tổ chức hiểu, phát triển, sử dụng và lưu giữ những ứng dụng có thể tin tưởng. Một dự án nổi bật hơn nữa của họ có tên Phương pháp bảo mật ứng dụng nhẹ nhàng, thuận tiện – CLASP - (Comprehensive, Lightweight Application Security Process).

CLASP là một tập hợp các quy trình và công cụ đã được xác định sẵn có thể tiếp hợp với bất kì một quy trình phát triển phần mềm nào. Quy trình này được thiết kế cho người dùng dễ sử dụng cũng như rất hiệu quả.

CLASP sử dụng một phương pháp tiếp cận, bản ghi các hoạt động mà các tổ chức nên thực hiện. CLASP có rất nhiều tiện ích mở rộng có sẵn cho người dùng và các nguồn bảo mật nguồn mở giúp việc thực hiện những hoạt động trên trở nên thực tế hơn và có khả năng đạt được.

Hãy coi CLASP như một thư viện nguồn để có thể tránh được vòng quay khi bạn bắt gặp nhu cầu cho một quy trình mới hoặc các ý tưởng mới trong việc phát triển bảo mật phần mềm.

CLASP cung cấp những thông tin cụ thể mở rộng trên:

• Các khái niệm đằng sau CLASP để có thể bắt đầu

• 7 điều Best Practices – các thói quen tốt nhất – giúp định nghĩa CLASP

• Các dịch vụ bảo mật mức độ cao, đóng vai trò là nền tảng

• Các nguyên tắc bảo mật chủ yếu dành cho phát triển phần mềm

• Các Role tóm tắt có liên quan tới phát triển phần mềm

• Các hoạt động nhằm bổ xung cho quy trình phát triển để có thể xây dựng phần mềm bảo mật hơn

• Kỹ thuật và bản đồ chỉ dẫn của quy trình CLASP

• Hướng dẫn Code nhằm giúp các nhà lập trình và chỉnh sửa khi họ xem xét code

Bạn có thể nhận được bản copy miễn phí của CLASP trong dạng sách hoặc từ OWASP CLASP Wiki.

Thực hiện các thói quen tốt cho bảo mật ứng dụng phần mềm yêu cầu một quy trình đáng tin cậy để hướng dẫn một đội lập trình trong việc tạo ra và triển khai một ứng dụng có khả năng chống lại được các cuộc tấn công bảo mật. Bên trong dự án triển khai phần mềm, CLASP Best Practices là điều căn bản của tất cả những hoạt động phát triển phần mềm có liên quan tới bảo mật. Dưới đây là 7 thói quen tốt nhất:

Best Practice 1: Thiết lập các chương trình nhận biết

Best Practice 2: Thực hiện đánh giá ứng dụng

Best Practice 3: Nắm bắt các yêu cầu bảo mật

Best Practice 4: Thực hiện các thói quen phát triển bảo mật

Best Practice 5: Xây dựng các phương pháp sửa chữa lỗ hổng

Best Practice 6: Xác định và quản lý

Best Practice 7: Đưa ra các hướng dẫn thao tác bảo mật

Các khái niệm và kỹ thuật bảo mật chủ yếu có thể xa lạ với đội ngũ lập trình phần mềm của công ty bạn và những người có liên quan trong vấn đề phát triển và triển khai ứng dụng. Vì vậy, việc phổ biến kiến thức với những người có liên quan là điều rất cần thiết. Các chương trình nhận biết có thể nhanh chóng được triển khai, sử dụng các nguồn chuyên môn ngoài, và gửi trả lại bằng cách giúp chắc chắn rầng các hoạt động đẩy mạnh bảo mật phần mềm sẽ được thực hiện hiệu quả. Dưới đây là một số mẹo nhỏ với nhận dạng bảo mật:

Đưa ra các buổi phổ biến kiến thức cho tất cả thành viên trong một đội

Trước khi thành viên của đội có thể nhận diện các vấn đề liên quan tới bảo mật, bạn phải chắc chắn rằng họ đã có đủ kiến thức với những vấn đề như vậy. Điều này có thể thực hiện tốt với một chương trình đào tạo. Mọi người trong đội nên đón nhận từ lời giới thiệu đào tạo cho tới các khái niệm bảo mật cơ bản và quy trình phát triển bảo mật được sử dụng bên trong công ty.

Đẩy mạnh nhận biết cài đặt bảo mật khu vực

Mọi người trong một dự án phát triển nên làm quen với các yêu cầu bảo mật của hệ thống, bao gồm mẫu nguy cơ tấn công cơ bản. Khi những dữ liệu này được in ra, chúng cần được phân phát và trình bày với các thành viên trong đội. Ngoài ra, bạn cũng nên cố gắng thu hút và khuyến khích ý kiến của tất cả mọi người trong đội.

Thiết lập trách nhiệm giải trình đối với các vấn đề bảo mật

Trách nhiệm giải trình truyền thống trong các tổ chức lập trình là dựa trên lịch và đặc tính. Bảo mật nên được “đối xử” giống như những đặc tính khác.

Chỉ định một chỉ huy dự án bảo mật

Một cách tuyệt vời để có thể tăng nhận biết bảo mật trong một chu trình phát triển là bổ nhiệm một thành viên trong nhóm trở thành trưởng nhóm dự án bảo mật, cụ thể là một người có tâm huyết, kinh nghiệm về bảo mật.

Thiết lập chế độ thưởng cho việc kiểm soát các vấn đề bảo mật

Trách nhiệm giải trình rất cần thiết trong việc nâng cao nhận thức bảo mật, nhưng vẫn có một cách hiệu quả hơn là thiết lập chế độ thưởng cho những ai hoàn thành công việc trong linh vực bảo mật. Ví dụ, chúng ta có thể thưởng cho ai đó đã làm tốt những công việc sau trong một thời gian dài – cụ thể là nếu kết quả luôn kết hợp với người này.

Cách chức năng kiểm tra và đánh giá thường được thực hiện bởi nhân viên phân tích kiểm tra hoặc bởi tổ chức QA nhưng có thể mở rộng toàn bộ SDLC. CLASP cung cấp hướng dẫn chi tiết trong việc đánh giá ứng dụng:

• Nhận dạng, triển khai và thực hiện các bài kiểm tra bảo mật

• Tìm kiếm các vấn đề bảo mật không tìm thấy bằng cách thực hiện xem xét lại

• Tìm kiếm các nguy hiểm bảo mật được giới thiệu bởi môi trường hoạt động

• Làm việc như một cơ chế bảo vệ, nắm bắt các lỗi trong thiết kế, đặc kiểm kỹ thuật, và triển khai

• Thực hiện phân tích bảo mật của các yêu cầu hệ thống và thiết kế

• Đánh giá giống như nguy hiểm hệ thống trong một chế độ thời gian và chi phí hiệu quả bằng cách phân tích những yêu cầu và thiết kế

• Nhận dạng các nguy cơ hệ thống mức độ cao được chứng minh bằng tư liệu dẫn trong cả các yêu cầu hoặc trong dữ liệu phụ

• Nhận dạng các yêu cầu bảo mật không phù hợp hoặc không thích hợp

• Đánh giá ảnh hưởng bảo mật của các yêu cầu không hệ thống

• Thực hiện xem xét lại bảo mật mức độ nguồn

• Tìm kiếm các lỗ hổng bảo mật trong khi triển khai

• Nghiên cứu và đánh giá tình hình bảo mật của các giải pháp bảo mật

• Đánh giá các nguy hiểm bảo mật trong các thiết bị bên thứ 3

• Xác định độ hiệu quả của một công nghệ

• Xác nhận những đóng góp của các nguồn về bảo mật

• Xác nhận sự tồn tại của phần mềm bằng các Policy bảo mật đã được xác định trước đó

Ngoài ra, cũng rất quan trọng trong phạm vi cập nhật của ứng dụng và những cải tiến để xác định các bước để nhận dạng, đánh giá, và chỉnh sửa các lỗ hổng. Hướng dẫn của CLASP có thể tìm thấy cho:

• Nhấn mạnh các vấn đề bảo mật đã được báo cáo

• Đảm bảo rằng các nguy hiểm bảo mật đã được nhận dạng trong quá trình triển khai đã được xem xét

• Quản lý vấn đề bảo mật bộc lộ quá trình

• Giao tiếp hiệu quả với các nhà nghiên cứu bảo mật bên ngoài khi đã xác định được các vấn đề bảo mật trong phần mềm đã cho ra mắt, tạo điều kiện cho những công nghệ ngăn chặn hiệu quả hơn

• Giao tiếp hiệu quả với khách hàng khi đã xác nhận được các vấn đề bảo mật trong phần mềm đã được ra mắt

Bạn không thể quản lý điều bạn không thể đo. Tuy nhiên, thực hiện nỗ lực quản lý chuẩn đo hiệu quả có thể là nhiệm vụ khó thực hiện. Dẫu vậy, chuẩn đo là một yếu tố quan trọng trong nỗ lực bảo mật ứng dụng chung. Chúng quan trọng trong việc đánh giá tình hình bảo mật chung vào thời điểm hiện tại của công ty bạn, giúp tập trung chú ý vào những lỗ hổng nghiêm trọng nhất, và cho biết độ hiệu quả – hoặc không hiệu quả – khi bạn đầu tư vào nâng cấp bảo mật.

• Quản lý chuẩn đo bảo mật

• Đánh giá tình hình bảo mật của dự án phát triển đang được triển khai

• Bắt buộc trách nhiệm giải trình đối với những bảo mật không phù hợp

Bảo mật không kết thúc khi một ứng dụng được hoàn thành và triển khai trong môi trường sản phẩm. Những lời khuyên và hướng dẫn dưới đây về các yêu cầu bảo mật sẽ giúp người dùng đảm bảo được tổ chức của bạn đã tận dụng tốt các khả năng được xây dựng trong ứng dụng.

• Xây dựng một hướng dẫn bảo mật

• Cung cấp cho các bên liên quan tài liệu về các phương pháp về hoạt động bảo mật giúp đảm bảo chắc chắn cho sản phẩm

• Cung cấp dữ liệu đối với sử dụng chức năng bảo mật bên trong sản phẩm

• Xác định rõ cấu hình bảo mật cơ sở dữ liệu

• Định nghĩa cấu hình bảo mật mặc định dành cho các nguồn cơ sở dữ liệu được triển khai như một phần của thực thi

• Nhận diện cấu hình được “tiến cử” cho các nguồn cơ sở dữ liệu được triển khai bởi một bên thứ 3

Các tổ chức lập trình nên có một quy trình mà họ sử dụng để thực hiện công việc lập trình. Cách hiệu quả nhất để thực hiện được điều đó là xây dựng một đội quy trình kỹ thuật từ chính các thành viên trong đội lập trình để họ có quyền sở hữu trong việc vạch ra quy trình.

Dưới đây là các bước được khuyến cáo nên sử dụng để có thể hình thành một đội quy trình kỹ thuật:

Xây dựng một bản hướng dẫn nhiệm vụ quy trình kỹ thuật

Cung cấp tài liệu về mục tiêu của đội quy trình. Sẽ rất hợp lý khi toàn bộ thành viên trong đội đều ký vào bản hướng dẫn nhiệm vụ này.

Xác định một người đứng đầu

Đội quy trình nên xác định rõ ràng một người đứng đầu, người sẽ định hướng công việc và sau đó sẽ truyền lại định hướng này cho các thành viên. Điều này có nghĩa là đội này sẽ chịu trách nhiệm cho tất cả các mặt liên quan tới kỹ thuật và các hoạt động được triển khai kết hợp với những hoạt động trước đó của khung quy trình bảo mật mới này.

Xác định những người đóng góp phụ

Cũng giống như người đứng đầu quy trình, người có khả năng truyền bá tốt cũng nên được trọng dụng tốt như những người có đóng góp đáng kể nhất.

Ghi rõ các quyền hạn và trách nhiệm

Ghi rõ ra tài liệu về quyền hạn và trách nhiệm của từng thành viên trong đội.

Tạo văn bản hướng dẫn quy trình của CLASP

Giờ là lúc đưa ra quyết định cho một khung quá trình. Liệu một hướng dẫn quy trình là một phần của CLASP có thể sử dụng được? Quyết định này và hướng dẫn quy trình kết quả cần phải được tạo thành văn bản và được phê chuẩn trước khi chuyển thành văn bản triển khai.

Xem xét lại và phê chuẩn trước khi triển khai

Thiết lập ra một điểm kiểm tra trước khi triển khai. Trong đó, sẽ có một hướng chính của quy trình được thực hiện. Mục tiêu của điểm này nhằm thu hút các phản hồi về việc liệu khung làm việc đã được tạo thành văn bản sẽ thay thế mục tiêu của quy trình đã được đặt trước đó. Đội làm việc không nên tiếp tục tiến hành văn bản triển khai của dự án cho tới khi được chấp thuận bởi tổ chức hoặc công ty.

Ghi lại bất kì một vấn đề nào

Các vấn đề xảy ra trong quá trình hình thành đội quy trình kỹ thuật nên được ghi lại cẩn thận. Những vấn đề này cần được thêm vào quy trình kỹ thuật hoặc kế hoạch triển khai quy trình – phù hợp với việc quản lý các nguy cơ.

Trong khi các phương pháp SDLC – với các tiện ích bảo mật tương ứng từ lúc bắt đầu cho tới khi kết thúc – sẽ thực hiện công việc trên, điều cần phải làm rõ là chuẩn đo và phép đo là thiết yếu để có thể chắc chắn bạn đang đi đúng hướng.

Đánh giá thành công của chương trình phát triển bảo mật

Ở phần cuối của bài viết, chúng ta sẽ đi sâu vào 2 phần mềm quản lý bảo mật, Open Software Assurance Maturity Model (OpenSAMM) của OWASP và phần mềm Building Security in Maturity Model (BSIMM).

OpenSAMM

SAMM là khung làm việc mở giúp các tổ chức trình bày chính xác và thực hiện một chiến lược trong việc bảo mật phần mềm, được biến đổi tương thích với một số nguy cơ các tổ chức đang phải đối mặt. OpenSAMM cung cấp hướng dẫn và mẫu được xác định rõ ràng dành cho việc phát triển và triển khai phần mềm, cùng với đó là các công cụ tiện ích dành cho việc tự đánh giá hoặc lên kế hoạch.

SAMM được xác định nhằm giúp các tổ chức nhỏ, vừa và lớn đều có thể sử dụng khi họ sử dụng bất kì loại SDLC nào. Mẫu này có thể áp dụng cho mở rộng tổ chức, cho doanh nghiệp nhỏ lẻ, hoặc thậm chí là một dự án cá nhân. OpenSAMM bao gồm một file PDF 96 trang với các miêu tả chi tiết của các hoạt động chính và quy trình bảo mật tương ứng. Bạn có thể download miễn phí file này trên trang web của OpenSAMM.

Khi sử dụng OpenSAMM, một công ty có thể nhận lợi ích từ việc:

• Đánh giá các thói quen bảo mật phần mềm trong tổ chức của mình

• Xây dựng một phần mềm cân bằng bảo mật ứng dụng trong một phép lặp đã được xác định rõ

• Chứng minh các cải tiến cụ thể về chương trình bảo mật của bạn

• Xác định và đánh giá các hoạt động liên quan tới bảo mật trong tổ chức của bạn

Building Security in Maturity Model (BSIMM)

Building Security in Maturity Model được thiết kế nhằm giúp bạn hiểu, đánh giá và lên kế hoạch cho một ý tưởng bảo mật phần mềm. BSIMM được tạo ra trong một quá trình hiểu và phân tích dữ liệu từ 9 sáng kiến bảo mật phần mềm hàng đầu rồi được phê chuẩn và chỉnh sửa với dữ liệu được lấy từ 21 sáng kiến bảo mật phần mềm phụ.

Nếu được sử dụng phù hợp, đúng cách, BSIMM có thể giúp bạn xác định các bước nên làm nhằm thực hiện hiệu quả các mục tiêu.

BSIMM đã liệt kê các quy trình kỹ thuật được sắp xếp vào 4 lĩnh vực:

1. Governance: những quy trình kỹ thuật giúp sắp xếp, quản lý và đánh giá một sáng kiến bảo mật phần mềm.

2. Intelligence: Các quy trình kỹ thuật được tạo ra từ các sưu tầm được sử dụng trong việc thực hiện các hoạt động bảo mật phần mềm trong tổ chức. Các sưu tầm này bao gồm cả hướng dẫn bảo mật ban đầu và mô hình chuỗi theo tổ chức.

3. SSDL Touchpoints: Các quy trình kỹ thuật có sự kết hợp giữa phân tích và sự đảm bảo của một số thành phần phát triển phần mềm cùng với các quy trình. Tất cả các phương pháp bảo mật đều được bao gồm trong những quy trình kỹ thuật này.

4. Deployment: Những quy trình kỹ thuật có cái chung giữa bảo mật mạng truyền thống và các phần mềm bảo vệ các tổ chức. Cấu hình phần mềm, bảo vệ và các vấn đề liên quan tới môi trường đã có tác động trực tiếp đến bảo mật phần mềm.

Để giúp bạn có thể bắt đầu làm việc với BSIMM, có rất nhiều nguồn miễn phí trên trang web của BSIMM để người dùng có thể thu thập thông tin dạng MS Excel và phát triển kế hoạch thực thi một dự án trong MS Project. Bảng tính sẽ giúp bạn học, chia phần thông tin hành động trong BSIMM, trong khi file Project sẽ cho phép bạn copy hoặc kích – và – thả các hành động để có thể sắp xếp chúng theo các cụm hoặc nhóm theo ý muốn của người dùng. Sau khi đã hoàn thành quá trình đánh giá riêng, bạn có thể xây dựng một biểu đồ mạng nhện từ kết quả và so sánh chúng với các kết quả khác trong một nghành giống hoặc tương tự khác. Công cụ nghiên cứu BSIMM Begin là một công cụ hữu ích để có thể bắt đầu với BSIMM. Nghiên cứu này dựa trên Web, tập trung vào 40 trong tổng số 110 hành động được bao gồm trong BSIMM đầy đủ cho phép bạn có một số ý tưởng về cách các hoạt động bảo mật phần mềm cơ bản của mình khi so sánh với các phương pháp được thực hiện bởi các tổ chức khác.

Bảo mật phần mềm dành cho các nhà quản lý: Tổng kết

Sẽ không có sự khác biệt nào về đường lối bạn sử dụng nhằm triển khai một mã bảo mật – khi bạn cố gắng tiến tới các cải tiến, nỗ lực của bạn rất đáng khen ngợi. Trong khi có bất kì một phương pháp nào có thể giúp bạn thực hiện những điều trên, chuẩn đo và các phương pháp đánh giá là thiết yếu giúp đảm bảo rằng bạn đang đi đúng hướng trong việc bảo mật hệ thống và bảo mật phần mềm.