Vào ngày 10 tháng 2 năm 2022, Cục An toàn thông tin của Bộ Thông tin và Truyền thông đã ban hành hướng dẫn “Khung phát triển phần mềm an toàn” (phiên bản 1.0). Vina Aspire xin gửi đến các bạn thông tin về nội dung của hướng dẫn “Khung phát triển phần mềm an toàn” (phiên bản 1.0). Nguyên văn về hướng dẫn như sau:
HƯỚNG DẪN
KHUNG PHÁT TRIỂN PHẦN MỀM AN TOÀN
(Kèm theo Công văn số 166/BTTTT-CATTT ngày 10 tháng 02 năm 2022 của Bộ Thông tin và Truyền thông)
- Giới thiệu
Vòng đời phát triển phần mềm (SDLC – Software Development Life Cycle) là phương pháp luận hay một chuỗi các quy trình để phát triển phần mềm từ thiết kế, xây dựng và duy trì phần mềm. Có một số mô hình SDLC phổ biến gồm mô hình thác nước (waterfall), xoắn ốc (spiral), phát triển phần mềm linh hoạt (agile), đặc biệt mô hình agile kết hợp giữa phát triển phần mềm và triển khai. Rất ít mô hình SDLC đề cập chi tiết đến vấn đề an toàn phần mềm, vì vậy các phương pháp phát triển phần mềm an toàn thường cần được bổ sung và tích hợp vào từng mô hình SDLC. Bất kể mô hình SDLC nào được sử dụng, các phương pháp phát triển phần mềm an toàn cần được tích hợp trong suốt quá trình vì ba lý do: để giảm số lượng điểm yếu (vulnerability) trong phần mềm đã phát hành, để giảm thiểu tác động tiềm ẩn của việc khai thác các điểm yếu chưa được phát hiện hoặc chưa được khắc phục và để giải quyết gốc rễ nguyên nhân của các điểm yếu để ngăn chặn sự xuất hiện lặp lại.Hầu hết các khía cạnh của an toàn phần mềm có thể được giải quyết nhiều lần trong SDLC, tuy nhiên, vấn đề an toàn được giải quyết càng sớm thì càng cần ít nguồn lực và chi phí để đạt được cùng một mức độ an toàn. Nguyên tắc này, còn được gọi là dịch chuyển sang trái (shifting left), là nguyên tắc quan trọng bất kể mô hình SDLC nào. Dịch chuyển sang trái giúp giảm thiểu bất kỳ tồn tại kỹ thuật chúng đòi hỏi cần khắc phục các lỗi bảo mật sớm trong quá trình phát triển hoặc sau khi phần mềm được đưa vào sản xuất.Tài liệu này xác định và khuyến nghị các phương pháp phát triển phần mềm an toàn, trọng tâm là kết quả của các hoạt động sẽ được thực hiện hơn là vào các công cụ, kỹ thuật và cơ chế được sử dụng để làm như vậy, hướng đến:
- Có thể được sử dụng bởi các tổ chức trong bất kỳ lĩnh vực hoặc cộng đồng nào, bất kể quy mô hoặc mức độ phức tạp về an toàn thông tin mạng
- Có thể được áp dụng cho phần mềm được phát triển để hỗ trợ công nghệ thông tin (CNTT), hệ thống điều khiển công nghiệp (ICS), hệ thống vật lý mạng (CPS) hoặc Internet of Things (IoT)
- Có thể được tích hợp vào bất kỳ quy trình phát triển phần mềm hiện có nào và chuỗi công cụ tự động; không được ảnh hưởng tiêu cực đến các tổ chức đã áp dụng các hoạt động phát triển phần mềm an toàn.
- Có thể áp dụng rộng rãi, không phân biệt riêng cho các công nghệ, nền tảng, ngôn ngữ lập trình, mô hình SDLC, môi trường phát triển, môi trường hoạt động, công cụ, v.v.
- Có thể giúp một tổ chức lập tài liệu về các thực hành phát triển phần mềm an toàn hiện tại của mình và xác định các mục tiêu thực hành trong tương lai như một phần của quá trình cải tiến liên tục.
- Có thể hỗ trợ một tổ chức hiện đang sử dụng mô hình phát triển phần mềm cổ điển trong việc chuyển đổi các phương pháp phát triển phần mềm an toàn sang sử dụng với mô hình phát triển phần mềm hiện đại (ví dụ: Agile, DevOps).
- Có thể hỗ trợ các tổ chức đang mua sắm và sử dụng phần mềm hiểu được các phương pháp phát triển phần mềm an toàn do các nhà cung cấp của họ sử dụng.
- Khung phát triển phần mềm an toàn
Tài liệu này xác định phiên bản 1.0 Khung phát triển phần mềm an toàn (SSDF – Security Software Development Framework) được chia thành bốn nhóm:- Giai đoạn chuẩn bị của tổ chức (PO – Prepare the Organization): Các tổ chức phải đảm bảo nhân sự, quy trình và công nghệ để thực hiện phát triển phần mềm an toàn tại cấp độ tổ chức. Giai đoạn này cũng có thể áp dụng cho quá trình phát triển phần mềm an toàn, như các nhóm phát triển riêng lẻ hoặc các dự án.– Bảo vệ phần mềm (PS – Protect the Software): Các tổ chức cần bảo vệ tất cả các thành phần của phần mềm phòng chống giả mạo và truy cập trái phép.
– Sản xuất phần mềm đảm bảo an toàn (PW – Produce Well-Security Software): Các tổ chức cần sản xuất phần mềm đảm bảo an toàn với tối thiểu các điểm yếu tồn tại trong các phiên bản phát hành.
– Ứng phó với các lỗ hổng bảo mật (RV – Respond to Vulnerabilities): Các tổ chức phải xác định điểm yếu bảo mật còn tồn tại trong các phiên bản phần mềm phát hành và ứng phó tương ứng để xử lý những điểm yếu này và ngăn ngừa tương tự xảy ra trong tương lai.
Mỗi thực hành xác định bao gồm các thành phần sau đây:
– Thực hành: Tên của thực hành và một định danh riêng, tiếp theo bằng một diễn giải thực hành đó, tại sao và những lợi ích của thực hành đó.
– Nhiệm vụ: Một hoặc nhiều hoạt động cần để hoàn thành một thực hành.
– Ví dụ triển khai: Một hoặc nhiều ví dụ của loại các công cụ, các quy trình và các phương thức có thể được sử dụng để giúp trển khai một nhiệm vụ, không nhằm ngụ ý rằng bất kỳ ví dụ hoặc tổ hợp các ví dụ nào là bắt buộc hoặc chỉ những ví dụ đã nêu là các phương án khả thi.
DANH MỤC TỪ VIẾT TẮT
|
SDLC |
Vòng đời phát triển phần mềm an toàn |
|
SSDF |
Khung phát triển phần mềm an toàn |
KHUNG PHÁT TRIỂN PHẦN MỀM AN TOÀN
| Thực hành | Nhiệm vụ | Ví dụ triển khai |
| Chuẩn bị của tổ chức (PO) | ||
| Xác định yêu cầu đảm bảo an toàn thông tin cho phát triển phần mềm (PO.1):
Đảm bảo an toàn thông tin luôn gắn liền với SDLC. Bao gồm các yêu cầu từ các nguồn nội bộ (ví dụ: chính sách, mục tiêu kinh doanh và chiến lược quản lý rủi ro của tổ chức) và các nguồn bên ngoài (ví dụ: luật và quy định hiện hành). |
PO.1.1: Xác định và ghi lại các yêu cầu đảm bảo an toàn thông tin cho cơ sở hạ tầng trong quá trình phát triển phần mềm, đồng thời thực hiện các yêu cầu này liên tục trong suốt SDLC. | • Xác định chính sách đảm bảo an toàn thông tin cho cơ sở hạ tầng phát triển phần mềm, bao gồm cả việc đảm bảo an toàn thông tin cho điểm cuối xuyên suốt SDLC và duy trì tính bảo mật liên tục.
• Xác định chính sách để đảm bảo các quy trình phát triển phần mềm xuyên suốt SDLC và duy trì đảm bảo an toàn thông tin liên tục, bao gồm các phần mềm nguồn mở, phần mềm bên thứ ba đang được sử dụng phục vụ phần mềm được phát triển. • Định kỳ thực hiện kiểm tra, đánh giá về an toàn thông tin. • Đào tạo, nâng cao kiến thức về an toàn thông tin cho nhân viên để đáp ứng được với các yêu cầu thực tế. |
| PO.1.2: Xác định và áp dụng các yêu cầu đảm bảo an toàn thông tin đối với các phần mềm đáp ứng tiến độ đề ra. | • Xác định các chính sách, các yêu cầu từ khâu thiết kế và bảo đảm kiến trúc phần mềm dựa trên quản trị rủi ro.
• Xác định các chính sách đảm bảo an toàn thông tin cho phần mềm và kiểm tra tính tuân thủ quy định trong SDLC. • Phân tích rủi ro khi tích hợp nhiều công cụ, công nghệ trong cùng sản phẩm. • Quy định các yêu cầu về sao lưu và thời gian lưu trữ phần mềm dựa trên mô hình SDLC. • Tuân thủ các chính sách như: Vòng đời phần mềm, thông báo cho bên sử dụng về thời hạn và hỗ trợ đối với phần mềm. • Kiểm tra, đánh giá tính bảo mật của phần mềm. |
|
| PO.1.3: Các yêu cầu cho nhà cung cấp sản phẩm, dịch vụ. | • Xác định yêu cầu đảm bảo an toàn thông tin trong các hợp đồng và tại các cam kết của bên cung cấp phần mềm.
• Xác định các tiêu chí liên quan đến đảm bảo an toàn thông tin trong quá trình lựa chọn, phát triển phần mềm. • Yêu cầu nhà cung cấp sản phẩm, dịch vụ chứng minh nguồn gốc và tính bảo mật của sản phẩm. • Thiết lập và tuân thủ các quy trình đánh giá rủi ro. • Thiết lập và tuân theo các quy trình để giải quyết rủi ro. |
|
| Thực hiện các vai trò và trách nhiệm (PO.2):
Đảm bảo mọi yếu tố liên quan đến SDLC được chuẩn bị để thực hiện các vai trò và trách nhiệm liên quan đến SSDF trong suốt quá trình phát triển phần mềm. |
PO.2.1: Xác định vai trò và trách nhiệm cho các vị trí của SSDF.
Thường xuyên đánh giá, xác định lại vai trò và trách nhiệm của các thành viên trong nhóm. |
• Xác định vai trò và trách nhiệm liên quan đến SSDF cho tất cả các thành viên của nhóm phát triển phần mềm.
• Tích hợp các vai trò đảm bảo an toàn thông tin vào quy trình phát triển phần mềm. • Xác định vai trò về bảo đảm an toàn thông tin của từng vị trí (từ quản lý cấp cao đến nhân viên và bên sử dụng vận hành sản phẩm) có liên quan đến SDLC. • Định kỳ kiểm tra, đánh giá vai trò, trách nhiệm của từng vị trí nhân viên. • Đào tạo, nâng cao kiến thức về những xu hướng mới cho từng cá nhân liên quan. |
| PO.2.2: Đào tạo, nâng cao kiến thức về an toàn thông tin cho tất cá nhân viên. Định kỳ kiểm tra, đánh giá trình độ của nhân sự để cập nhật, bổ sung kiến thức cần thiết về an toàn thông tin. | • Xác định yêu cầu kiến thức đào tạo đối với từng đối tượng.
• Xác định loại hình đào tạo hoặc chương trình đào tạo cần thiết cho từng vị trí nhân sự. • Tổ chức các khóa học phù hợp với từng vị trí nhân viên. • Kiểm tra, đánh giá năng lực của từng nhân viên từ đó có định hướng và thay đổi chương trình đào tạo cho phù hợp. |
|
| PO.2.3: Xây dựng và áp dụng các quy định về SDLC cùng các vai trò và trách nhiệm liên quan đến SSDF. | • Chỉ định một lãnh đạo hoặc nhóm lãnh đạo chịu trách nhiệm về toàn bộ quy trình phát triển phần mềm an toàn.
• Nâng cao nhận thức về các rủi ro sẽ gặp khi phát triển phần mềm không tích hợp tính bảo mật trong suốt vòng đời phát triển và giảm thiểu rủi ro do thực tiễn SSDF cung cấp. • Phổ biến kiến thức cho nhân viên có vai trò, trách nhiệm liên quan đến SSDF về các quy định và tầm quan trọng của SSDF đối với tổ chức. |
|
| Triển khai các công cụ hỗ trợ (PO.3): | PO.3.1: Chỉ định công cụ cần thiết để giảm thiểu rủi ro và bảo | • Xây dựng danh mục công cụ và xác định công cụ phù hợp đối với từng danh mục. |
| Sử dụng tự động hóa để giảm bớt nhân lực, cải thiện độ chính xác, tính nhất quán, khả năng sử dụng và tính toàn diện của các phương thức bảo mật trong suốt SDLC, cung cấp cách lập hồ sơ và trình bày việc sử dụng phương pháp. | đảm đảm bảo an toàn thông tin khi tích hợp các công cụ. | • Xác định công cụ đảm bảo an toàn thông tin để tích hợp vào chuỗi các công cụ dành cho nhà phát triển.
• Đánh giá khả năng/năng lực của từng công cụ. • Sử dụng công nghệ tự động để quản lý và điều phối chuỗi công cụ . |
| PO.3.2: Thực hiện theo các phương pháp đảm bảo an toàn thông tin được khuyến nghị để triển khai và duy trì các công cụ và chuỗi các công cụ. | • Kiểm tra, đánh giá đảm bảo an toàn thông tin của từng công cụ.
• Tích hợp các công cụ và tuân theo các quy trình phát triển phần mềm hiện có. • Áp dụng công nghệ mới và các quy trình cần thiết cho các bản dựng mẫu. • Cập nhật, nâng cấp hoặc thay thế các công cụ có tính năng vá lỗ hổng bảo mật và thêm các tính năng mới cho công cụ. • Định kỳ kiểm tra, đánh giá các công cụ để phát hiện lỗ hổng bảo mật. • Định kỳ kiểm tra, đánh giá tính toàn vẹn của sản phẩm để xác định các rủi ro tiềm ẩn. |
|
| PO.3.3: Cài đặt, cấu hình các công cụ để đáp ứng về đảm bảo an toàn thông tin theo quy định | • Sử dụng công cụ sẵn có để tạo sự kiện kiểm tra về các hành động liên quan đến phát triển an toàn.
• Xây dựng và áp dụng các chính sách đảm bảo an toàn thông tin và sao lưu dữ liệu. |
|
| Xác định và sử dụng các tiêu chí đảm bảo an toàn thông tin cho phần mềm kiểm tra, đánh giá (PO.4): Bảo đảm phần mềm theo SDLC đáp ứng các tiêu chí khi được kiểm tra, đánh giá an toàn thông tin trong quá trình phát triển. | PO.4.1: Xác định tiêu chí kiểm tra, đánh giá an toàn thông tin của phần mềm và theo dõi trong suốt SDLC. | • Đảm bảo các tiêu chí về quản lý rủi ro an toàn thông tin.
• Xác định các chỉ số hiệu suất chính (KPI) và các chỉ số rủi ro chính (KRI) để đảm bảo an toàn thông tin cho phần mềm. • Bổ sung các tiêu chí đảm bảo an toàn thông tin cho phần mềm vào các nội dung kiểm tra, đánh giá. • Theo dõi, phát hiện các bước bỏ qua không tuân thủ quy định vè kiểm tra đánh giá yêu cầu đảm bảo an toàn thông tin. • Báo cáo kết quả kiểm tra, đánh giá an toàn thông tin. |
| PO.4.2: Thực hiện các quy trình để thu thập và bảo vệ thông tin cần thiết để bảo đảm các tiêu chí về an toàn thông tin. | • Sử dụng các công cụ để thu thập thông tin cho việc đưa ra các yêu cầu bảo mật.
• Bổ sung các công cụ cần thiết để hỗ trợ việc thu thập thông tin hỗ trợ các tiêu chí. • Tự động hóa các quy trình áp dụng các tiêu chí. • Chỉ cho phép nhân viên được ủy quyền để truy cập thông tin thu thập và ngăn chặn bất kỳ thay đổi hoặc xóa thông tin. |
|
| Thực hiện và duy trì đảm bảo an toàn thông tin trong môi trường phát triển phần mềm (PO.5): Bảo đảm các yếu tố tác động từ môi trường để quy trình phát triển phần mềm được bảo vệ khỏi các mối đe dọa từ bên trong và bên ngoài. | PO.5.1: Tách biệt và bảo vệ từng môi trường liên quan đến phát triển phần mềm. | • Áp dụng phương pháp xác thực, nhận dạng riêng biệt với xác thực dựa trên rủi ro và quyền truy cập có điều kiện cho từng môi trường khác nhau.
• Sử dụng phân đoạn mạng và kiểm soát truy cập để tách môi trường phát triển thành từng phần, từng khâu riêng biệt để giảm thiểu ảnh hưởng khi bị tấn công. • Triển khai xác thực và hạn chế các liên kết để tránh bị ảnh hưởng lẫn nhau giữa các môi trường khi xuất hiện các rủi ro. Chỉ sử dụng Internet khi thật sự cần thiết. • Thường xuyên ghi nhật ký giám sát và kiểm tra các môi trường liên kết giữa các thành phần. • Thực hiện ghi log thường xuyên và giám sát các hoạt động để kịp thời đưa ra các cảnh báo và có biện pháp ứng phó khi xuất hiện các sự cố mất an toàn thông tin mạng. • Cấu hình các biện pháp đảm bảo an toàn thông tin và công cụ thực thi bảo mật để bảo vệ an toàn cho môi trường phát triển phần mềm. • Thường xuyên kiểm tra dữ liệu các phần mềm và kiểm tra, đánh giá lỗ hổng bảo mật trên các phần mềm đó. |
| PO.5.2: Thực hiện quản lý, đánh giá rủi ro an toàn thông tin cho các sản phẩm, phần mềm trước khi đưa vào sử dụng. | • Cấu hình phần mềm trước khi đưa vào sử dụng dựa trên các quy định đã được phê duyệt.
• Cấu hình phần mềm trước khi đưa vào sử dụng để cung cấp chức năng, dịch vụ cần thiết cho người dùng. • Liên tục theo dõi tình trạng bảo mật của các sản phẩm, phần mềm trước khi đưa vào sử dụng. • Áp dụng các biện pháp đảm bảo an toàn thông tin và công cụ đánh giá, bảo đảm an toàn thông tin cho các sản phẩm, phần mềm trước khi đưa vào sử dụng. • Yêu cầu xác thực đa yếu tố cho quyền truy cập vào các sản phẩm, phần mềm trước khi đưa vào sử dụng. |
|
| Bảo vệ phần mềm | ||
| Bảo vệ tất cả các dạng mã không bị xâm nhập và giả mạo trái phép (PS.1): Ngăn chặn những thay đổi trái phép đối với mã nguồn. | PS.1.1: Lưu trữ các dạng mã, bao gồm cả mã nguồn và mã thực thi, chỉ những người được ủy quyền mới có thể truy cập khi cần thiết. | • Lưu trữ tất cả mã nguồn và hạn chế quyền truy cập. Ví dụ, các mã nguồn mở được sử dụng dùng cho mục đích truy cập công cộng, trường hợp này tính toàn vẹn và tính khả dụng phải được bảo vệ.
• Sử dụng các tính năng kiểm soát để theo dõi các thay đổi được thực hiện đối với mã nguồn. • Xem xét và phê duyệt tất cả các thay đổi được thực hiện đối với mã nguồn sau khi đã được tự động quét các lỗ hổng bảo mật. • Sử dụng ký số để giúp bảo vệ tính toàn vẹn của tệp. • Sử dụng mật mã (ví dụ: hàm băm mật mã) để giúp bảo vệ tính toàn vẹn của tệp. |
| Cung cấp cơ chế xác minh tính toàn vẹn của phần mềm (PS.2): Bảo đảm người mua và người sử dụng phần mềm là hợp pháp, không giả mạo. | PS.2.1: Cam kết bảo đảm tính toàn vẹn cho người mua và người sử dụng phần mềm. | • Mã hóa ứng dụng trên các trang web bằng các hàm băm nhằm tăng tính bảo mật.
• Cung cấp các chứng chỉ đã được thẩm định bởi cơ quan có thẩm quyền, thiết lập ký mã khóa để hệ điều hành, công cụ và dịch vụ khác có thể xác nhận tính hợp lệ của chữ ký trước khi sử dụng. • Định kỳ đánh giá quy trình ký mã khóa, bao gồm: Gia hạn chứng chỉ, luân phiên, thu hồi và bảo vệ. |
| Sao lưu bảo đảm tính toàn vẹn cho các phần mềm (PS.3): Sao lưu các phần mềm để giúp xác định, phân tích và loại bỏ các lỗ hổng được phát hiện trong phần mềm sau khi được đưa vào sử dụng. | PS.3.1: Lưu trữ an toàn các tệp dữ liệu (ví dụ: thông tin xác minh tính toàn vẹn, dữ liệu xuất xứ) của mỗi phần mềm đã được đưa vào sử dụng. | • Thiết lập quyền truy cập cho các đối tượng có thể sử dụng dữ liệu với mục đích kiểm tra, đánh giá.
• Sao lưu và bảo đảm tính toàn vẹn của phần mềm đã được đưa vào sử dụng. |
| PS.3.2: Thu thập và chia sẻ mã nguồn các thành phần của mỗi phần mềm. | • Cung cấp mã nguồn cho cá nhân, tổ chức mua phần mềm để phù hợp với chính sách của tổ chức.
• Cập nhật mã nguồn của phần mềm và các thành phần của phần mềm. |
|
| Sản xuất phần mềm đáp ứng bảo mật tốt (PW) | ||
| Thiết kế phần mềm để đáp ứng các yêu cầu bảo mật và giảm thiểu rủi ro bảo mật (PW.1): Xác định và đánh giá các yêu cầu đảm bảo an toàn thông tin cho phần mềm; xác định những rủi ro bảo mật mà phần mềm có thể gặp phải trong quá trình hoạt động và cách thiết kế của phần mềm nhằm giảm thiểu những rủi ro. | PW.1.1: Áp dụng phương pháp mô hình hóa rủi ro để đánh giá tính bảo mật phần mềm (VD: mô hình hóa mối đe dọa, mô hình hóa cuộc tấn công; mô hình hóa lược đồ tấn công). | • Đào tạo, nâng cao nhận thức về đảm bảo an toàn thông tin cho nhóm phát triển hoặc cộng tác với cá nhân, tổ chức chuyên về mô hình rủi ro để có biện pháp xử lý, giảm thiểu.
• Thực hiện các đánh giá chuyên sâu hơn với các khu vực có nguy cơ rủi ro về bảo mật cao. • Rà soát các báo cáo và số liệu thống kê về lỗ hổng bảo mật phần mềm. • Phân loại dữ liệu để xác định từng loại dữ liệu mà phần mềm sẽ tương tác. |
| PW.1.2: Sao lưu các yêu cầu về đảm bảo an toàn thông tin cho phần mềm và các rủi ro để đưa ra các phương án thiết kế phù hợp. | • Ghi lại tác động đối với từng rủi ro, bao gồm các phương án giảm thiểu và lý do của bất kỳ trường hợp ngoại lệ nào đã được phê duyệt đối với các yêu cầu đảm bảo an toàn thông tin. | |
| PW.1.3: Xây dựng các yêu cầu về tính năng và dịch vụ đảm bảo an toàn thông tin. (ví dụ: tích hợp với hệ thống quản lý nhật ký, quản lý danh tính, kiểm soát truy cập và quản lý lỗ hổng bảo mật hiện có). | • Xây dựng thư viện phần mềm gồm các mô -đun để hỗ trợ các tính năng và dịch vụ bảo mật được tiêu chuẩn hóa.
• Đưa ra các yêu cầu về tính năng và dịch vụ bảo mật trong quá trình phát triển phần mềm. |
|
| Rà soát, đánh giá thiết kế phần mềm để xác minh sự tuân thủ với các yêu cầu bảo mật và các yếu tố rủi ro (PW.2): Đảm bảo phần mềm đáp ứng các yêu cầu đảm bảo an toàn thông tin và xử lý rủi ro. | PW.2.1: Yêu cầu cá nhân, đơn vị độc lập với đơn vị thiết kế kiểm tra đánh giá rủi ro và các yêu cầu đảm bảo an toàn thông tin | • Rà soát từ khâu thiết kế phần mềm bảo đảm các yêu cầu, tính năng đảm bảo an toàn thông tin
• Rà soát, đánh giá các yếu tố rủi ro trong quá trình thiết kế phần mềm. • Rà soát, đánh giá các phương án xử lý rủi ro. • Yêu cầu nhà thiết kế phần mềm sửa lỗi để đáp ứng các yêu cầu. • Thay đổi thiết kế hoặc chiến lược xử lý rủi ro nếu không thể đáp ứng các yêu cầu đảm bảo an toàn thông tin. |
| Kế thừa, phát triển tính năng bảo mật hiện có trên phần mềm thay vì đầu tư, mua sắm phần mềm mới bảo mật mới. (PW.3): Giảm chi phí phát triển phần mềm, đẩy nhanh quá trình phát triển phần mềm và giảm khả năng gia tăng lỗ hổng bảo mật vào phần mềm bằng cách sử dụng lại các mô-đun và dịch vụ phần mềm đã được kiểm tra tình trạng đảm bảo an toàn thông tin. | PW.3.1: Mua sắm, đầu tư các thành phần phần mềm được bảo mật tốt (ví dụ: thư viện phần mềm, mô-đun, phần mềm trung gian…) từ các nhà phát triển và bên thứ ba. | • Rà soát, đánh giá các thành phần phần mềm trước khi đưa vào sử dụng.
• Kiểm thử mã nguồn cho cho từng thành phần của phần mềm và đánh giá rủi ro có thể gây ra. • Xây dựng thư viện phần mềm để lưu trữ các thành phần mã nguồn mở đã được kiểm định và kiểm duyệt. • Xác định những thành phần phải có trong phát triển phần mềm. |
| PW.3.2: Xây dựng các thành phần phần mềm được đảm bảo an toàn thông tin tuân theo SDLC để đáp ứng các nhu cầu phát triển mà phần mềm của bên thứ ba không thể đáp ứng. | • Tuân thủ các yêu cầu đảm bảo an toàn thông tin để phát triển phần mềm an toàn.
• Xác định những thành phần phải có trong phát triển phần mềm. |
|
| PW.3.4: Kiểm tra, đánh giá tính tuân thủ các yêu cầu đảm bảo an toàn thông tin ở các thành phần phần mềm, mã nguồn mở. | • Rà soát, đánh giá lỗ hổng bảo mật chưa được sửa chữa, khắc phục. | |
| PW.3.5: Rà soát, kiểm tra tính toàn vẹn của các thành phần phần mềm. | • Đảm bảo việc rà soát các thành phần của phần mềm được diễn ra định kì, thường xuyên; Phát hiện kịp thời, hạn chế xuất hiện lỗ hổng.
• Lên phương án xử lý phần mềm không còn khả dụng. • Xác nhận tính toàn vẹn của các thành phần phần mềm thông qua chữ ký số hoặc các cơ chế khác. |
|
| Phát triển phần mềm bằng dựa trên các quy tắc đảm bảo an toàn
thông tin (PW.4): Giảm số lượng lỗ hổng bảo mật trong phần mềm và giảm chi phí bằng cách loại bỏ các lỗ hổng trong quá trình tạo mã nguồn bằng cách tuân theo các tiêu chí về mức độ nghiêm trọng của lỗ hổng bảo mật do tổ chức xác định. |
PW.4.1: Tuân thủ tất cả các phương pháp mã hóa an toàn phù hợp với ngôn ngữ và môi trường phát triển để đáp ứng các yêu cầu của tổ chức. | • Xác thực đầu vào, xác nhận và mã hóa đầu ra.
• Tránh sử dụng các chức năng và cuộc gọi không an toàn. • Cung cấp khả năng ghi nhật ký và truy vết. • Sử dụng các IDE có khả năng đảm bảo an toàn thông tin tốt. • Kiểm tra các lỗ hổng bảo mật khác, thường gặp đối với môi trường và ngôn ngữ phát triển. • Yêu cầu nhà phát triển xem xét mã phần mềm để bổ sung (không thay thế), việc đánh giá mã do người hoặc công cụ khác thực hiện. |
| Cấu hình môi trường phát triển tích hợp, biên dịch, trình thông dịch và xây dựng các quy trình để cải thiện khả năng đảm bảo an toàn thông tin | PW.5.1: Sử dụng trình biên dịch, trình thông dịch và xây dựng các công cụ cung cấp các tính năng cải thiện yêu cầu đảm bảo an toàn thông tin. | • Sử dụng các bản cập nhật của công cụ biên dịch, công cụ thông dịch và công cụ thiết lập.
• Tuân thủ các quy trình quản lý thay đổi khi triển khai hoặc cập nhật các công cụ biên dịch, công cụ thông dịch và công cụ thiết lập, đồng thời kiểm tra tất cả các thay đổi không hợp lệ đối với các công cụ. • Xác nhận thường xuyên tính xác thực và tính toàn vẹn của các công cụ biên dịch, công cụ thông dịch và công cụ thiết lập. |
| (PW.5): Giảm số lượng lỗ hổng bảo mật trong phần mềm, loại bỏ các lỗ hổng trước khi kiểm thử để giảm chi phí. | PW.5.2: Xác định các tính năng của trình biên dịch, trình thông dịch, công cụ thiết lập và cách cấu hình từng tính năng, sau đó triển khai và sử dụng các cấu hình đã được phê duyệt. | • Bật các tính năng của trình biên dịch, tạo ra các cảnh báo cho mã bảo mật kém an toàn trong quá trình biên dịch.
• Tiến hành kiểm thử để đảm bảo các tính năng hoạt động tốt, tránh gây ra sự cố vận hành hoặc các sự cố khác. • Xác minh liên tục các cấu hình đã phê duyệt và đang sử dụng. • Cung cấp thông tin về trình biên dịch, trình thông dịch và cấu hình công cụ thiết lập trong cơ sở kiến thức của các nhà phát triển có thể truy cập, tìm kiếm và tái tạo trong môi trường phát triển cục bộ |
| Xem xét, phân tích mã phần mềm để xác định các lỗ hổng và xác minh sự tuân thủ với các yêu cầu đảm bảo an toàn thông tin (PW.6): Xác định, khắc phục các lỗ hổng trước khi phần mềm được đưa vào sử dụng nhằm ngăn chặn việc khai thác lỗ hổng bảo mật. Sử dụng các công cụ, tính năng phát hiện lỗ hổng có sẵn để giảm tải nguồn lực, chi phí, thời gian. | PW.6.1: Xác định việc sử dụng xem xét mã (con người xem trực tiếp mã để rà soát) hoặc phân tích mã (sử dụng các công cụ được để rà quét). | • Tuân thủ các chính sách và hướng dẫn của tổ chức về thời điểm nên thực hiện việc xem xét mã và cách thức tiến hành. |
| PW.6.2: Kiểm tra, đánh giá, phân tích mã dựa trên các tiêu chuẩn an toàn thông tin. Phân loại và đưa ra phương án khắc phục lỗ hổng bảo mật. | • Thực hiện kiểm tra, đánh giá ngang hàng về mã nguồn.
• Áp dụng đánh giá ngang hàng để kiểm tra mã backdoor và mã độc khác. • Áp dụng công cụ phân tích tĩnh để tự động kiểm tra lỗ hổng bảo mật và đánh giá sự tuân thủ các tiêu chuẩn mã hóa an toàn. • Xác minh tính tuân thủ của mã thông qua các tiêu chí kiểm tra đánh giá. • Sử dụng các công cụ tự động để xác định và khắc phục các hoạt động phần mềm không an toàn. • Xác định nguyên nhân của mỗi vấn đề. |
|
| Kiểm tra thực thi luật để xác định lỗ hổng và xác minh sự tuân thủ với yêu cầu đảm bảo an toàn thông tin (PW.7): Xác định các lỗ hổng có thể xử lý trước khi phần mềm được đưa vào sử dụng nhằm tái khai thác.
Sử dụng các phương pháp tự động làm giảm nguồn lực trong việc phát hiện các lỗ hổng. |
PW.7.1: Xác định việc thực hiện kiểm tra mã thực thi để xác định và loại bỏ các lớp lỗ hổng không được đề cập trong các bài đánh giá, phân tích hoặc thử nghiệm trước đó. | • Tuân thủ các chính sách hoặc nguyên tắc của tổ chức về thời điểm nên thực hiện kiểm tra mã nguồn và cách thức tiến hành. |
| PW.7.2: Thiết kế thử nghiệm, thực hiện thử nghiệm và ghi lại kết quả, bao gồm ghi lại và xử lý tất cả các vấn đề đã phát hiện và các biện pháp khắc phục được đề xuất trong quy trình làm việc của nhóm phát triển hoặc hệ thống theo dõi vấn đề. | • Thực hiện kiểm tra chức năng của các tính năng đảm bảo an toàn thông tin.
• Tích hợp kiểm tra lỗ hổng động vào bộ kiểm thử tự động của dự án. • Kết hợp các bài đánh giá lỗ hổng bảo mật trước đây vào bài đánh giá của dự án để đảm bảo các lỗi không xuất hiện lại. • Xem xét cơ sở hạ tầng và công nghệ phần mềm sẽ sử dụng trong khi phát triển các kế hoạch thử nghiệm. • Sử dụng các công cụ kiểm tra fuzz testing để tìm các vấn đề với việc xử lý đầu vào. • Sử dụng phương pháp kiểm thử xâm nhập trong trường hợp có sẵn mã nguồn nhằm nâng cao khả năng đánh giá. • Xác định và ghi lại nguyên nhân của từng vấn đề được phát hiện. • Ghi lại kinh nghiệm qua việc phân tích nguyên nhân lỗ hổng bảo mật để đưa ra hướng dẫn, khuyến nghị cho lập trình viên phát triển phần mềm có thể truy cập và tìm kiếm. |
|
| Cấu hình phần mềm cài đặt đảm bảo an toàn thông tin theo mặc định (PW.8): Cải thiện đảm bảo an toàn thông tin của phần mềm tại thời điểm cài đặt giảm khả năng phần mềm được triển khai với cài đặt bảo mật yếu. | PW.8.1: Xác lập chính sách đảm bảo an toàn thông tin chuẩn để cài đặt, cấu hình bảo mật. Giúp các cài đặt mặc định được an toàn và không tác động tới các chức năng bảo mật được cung cấp bởi các nền tảng, cơ sở hạ tầng mạng. | • Lên kế hoạch kiểm tra để đảm bảo các cài đặt cấu hình mặc định hoạt động một cách tốt nhất, không gây ra điểm yếu và ảnh hưởng đến những hoạt động khác của hệ thống. |
| PW.8.2: Triển khai cài đặt mặc định (hoặc nhóm cài đặt mặc định, nếu có), ghi lại từng cài đặt cho quản trị viên phần mềm. | • Xác minh cấu hình đã được phê duyệt có sẵn cho phần mềm.
• Sao lưu mục đích của từng cài đặt, các tùy chọn, giá trị mặc định, mức độ liên quan đến đảm bảo an toàn thông tin, tác động hoạt động tiềm năng và mối quan hệ với các cơ sở khác. • Sử dụng các cơ chế kỹ thuật để ghi lại cách mỗi cài đặt có thể được thực hiện và đánh giá bởi quản trị viên phần mềm. • Lưu trữ cấu hình mặc định ở định dạng có thể sử dụng được và tuân theo kiểm soát thay đổi thực hành để sửa đổi nó (ví dụ: cấu hình dưới dạng mã). |
|
| Ứng phó với các lỗ hổng bảo mật (RV) | ||
| Xác định và xác nhận các lỗ hổng trên một nền tảng đang triển khai (RV.1): Đảm bảo các lỗ hổng được xác định sớm để có phương án điều chỉnh kịp thời, giảm khả năng bị tấn công. | RV.1.1: Thu thập thông tin từ người sử dụng, các nguồn công khai về các lỗ hổng tiềm năng trong phần mềm và các mô-đun phần mềm bên thứ ba sử dụng. | • Thiết lập chương trình báo cáo về các lỗ hổng bảo mật, giúp các chuyên gia bảo mật dễ dàng trong việc tiếp cận, tìm hiểu mã nguồn và báo cáo các lỗ hổng có thể gặp.
• Giám sát cơ sở dữ liệu về lỗ hổng bảo mật, danh sách gửi thư bảo mật và các nguồn khác về báo cáo lỗ hổng thông qua các phương tiện thủ công hoặc tự động. • Sử dụng các nguồn thông tin tình báo về mối đe dọa để hiểu rõ hơn về cách các lỗ hổng đang bị khai thác. • Thường xuyên kiểm tra nguồn gốc và phần mềm dữ liệu cho mỗi bản phát hành phần mềm đang được sử dụng để xác định các lỗ hổng mới tiềm ẩn trong các ứng dụng. |
| RV.1.2: Đánh giá, phân tích và kiểm tra mã nguồn phần mềm để xác định việc phần mềm không tồn tại những lỗ hổng bảo mật. | • Cấu hình chuỗi công cụ để thực hiện phân tích và kiểm tra mã tự động một cách thường xuyên hoặc liên tục.
• Chủ động truy xuất nguồn gốc và dữ liệu của phần mềm nhằm xác định kịp thời các lỗ hổng mới của phần mềm. |
|
| RV.1.3: Có chính sách giải quyết việc khắc phục lỗ hổng bảo mật, đồng thời thực hiện các vai trò, trách nhiệm và quy trình cần thiết để hỗ trợ chính sách. | • Có Nhóm ứng phó sự cố về bảo mật sản phẩm (PSIRT) và các quy trình để xử lý các phản hồi đối với các báo cáo và sự cố về lỗ hổng bảo mật.
• Có nhật kí ghi lại những đánh giá, phản hồi về xử lý lỗ hổng, zero-days, lỗ hổng đang bị khai thác và những sự cố nghiêm trọng liên quan đến cộng đồng và ứng dụng. |
|
| Đánh giá và loại bỏ các lỗ hổng (RV.2): Để đảm bảo các lỗ hổng bảo mật được khắc phục kịp thời, tránh được những rủi ro bị tấn công | RV.2.1: Phân tích từng lỗ hổng để thu thập đầy đủ thông tin, đưa ra kế hoạch khắc phục. | • Sử dụng phần mềm theo dõi sự cố để ghi lại sự kiện rủi ro.
• Dự trù kế hoạch để khắc phục các lỗ hổng • Tính toán ảnh hưởng của việc khai thác lỗ hổng. • Tính toán mọi phương án cần thiết để lập kế hoạch khắc phục lỗ hổng bảo mật. |
| RV.2.2: Phát triển và thực hiện kế hoạch khắc phục cho từng lỗ hổng. | • Lập kế hoạch phản ứng nhanh với các lỗ hổng trước mắt, trước khi có những biện pháp khắc phục lâu dài.
• Cung cấp biện pháp khắc phục cho người sử dụng sản phẩm thông qua thiết bị tự động và cơ chế phân phối đáng tin cậy. • Phát triển và ban hành các khuyến cáo đảm bảo an toàn thông tin cho người sử dụng, bao gồm những mô tả về thay đổi trong phần mềm, cấu hình, cài đặt . |
|
| Phân tích chuyên sâu các lỗ hổng (RV.3): Giảm thiểu các lỗ hổng trong tương lai. | RV.3.1: Phân tích tất cả các lỗ hổng đã xác định để tìm ra nguyên nhân ban đầu. | • Ghi lại nguyên nhân của mỗi vấn đề khi được phát hiện.
• Ghi lại kinh nghiệm qua việc phân tích nguyên nhân lỗ hổng để đưa ra hướng dẫn, khuyến nghị cho lập trình viên phát triển phần mềm có thể truy cập và tìm kiếm. |
| RV.3.2: Phân tích nguyên nhân lỗ hổng theo từng thời điểm và từng giai đoạn để đưa ra những hướng dẫn chính xác. | • Ghi lại kinh nghiệm qua việc phân tích nguyên nhân lỗ hổng để đưa ra hướng dẫn, khuyến nghị cho lập trình viên phát triển phần mềm có thể truy cập và tìm kiếm.
• Tích hợp thêm cơ chế tự động phát hiện vào các chuỗi công cụ để tự động phát hiện các nguyên nhân lỗ hổng trong tương lai. |
|
| RV.3.3: Chủ động lên kế hoạch rà quét lỗ hổng trong các phần mềm, và đưa ra cách khắc phục. | Xem PW.6 và PW.7. | |
| RV.3.4: Rà soát lại SDLC để chủ động đưa ra những cập nhật thích hợp nhằm ngăn chặn, giảm khả năng của lỗ hổng trong các bản cập nhật phần mềm hoặc trong phần mềm mới được tạo. | • Ghi lại kinh nghiệm qua việc phân tích nguyên nhân lỗ hổng để đưa ra hướng dẫn, khuyến nghị cho lập trình viên phát triển phần mềm có thể truy cập và tìm kiếm.
• Lập kế hoạch và chủ động lên phương án thực hiện chỉnh sửa thay đổi đối với các hướng dẫn của SSDF. |
|
TÀI LIỆU THAM KHẢO
[1] NIST Special Publication 800-218, Secure Software Development Framework (SSDF) Version 1.1
Vina Aspire là công ty tư vấn, cung cấp các giải pháp, dịch vụ CNTT, An ninh mạng, bảo mật & an toàn thông tin tại Việt Nam. Đội ngũ của Vina Aspire gồm những chuyên gia, cộng tác viên giỏi, có trình độ, kinh nghiệm và uy tín cùng các nhà đầu tư, đối tác lớn trong và ngoài nước chung tay xây dựng.
Các Doanh nghiệp, tổ chức có nhu cầu liên hệ Công ty Vina Aspire theo thông tin sau:
Email: info@vina-aspire.com | Website: www.vina-aspire.com
Tel: +84 944 004 666 | Fax: +84 28 3535 0668
Vina Aspire – Vững bảo mật, trọn niềm tin
