Đánh giá an toàn ứng dụng di động theo NIST
Mục đích tài liệu đánh giá an toàn ứng dụng di động của NIST là giúp các tổ chức: (1) hiểu quy trình kiểm tra ứng dụng, (2) lập kế hoạch thực hiện quy trình kiểm tra ứng dụng, (3) xây dựng các yêu cầu an toàn ứng dụng, (4) hiểu các loại lỗ hổng ứng dụng và phương pháp thử nghiệm để phát hiện lỗ hổng và (5) xác định xem ứng dụng có được chấp nhận cho việc triển khai trên hệ thống của tổ chức hay không.
Tài liệu của NIST nêu bật những yếu tố đặc biệt quan trọng cần xem xét trước khi ứng dụng được chấp nhận/từ chối bởi tổ chức trước khi đưa vào sử dụng. Tài liệu này của NIST không đề cập đến các vấn đề bảo mật của nền tảng di động và hệ điều hành. Tài liệu được xây dựng phù hợp, mang tính thực tế cao đối với việc đánh giá an toàn cho các ứng dụng di động hiện nay.
Đặt vấn đề
Hiện nay cùng với sự phát triển của cách mạng công nghiệp 4.0 và chính phủ điện tử, các doanh nghiệp, tổ chức và các cơ quan nhà nước đang triển khai nhiều ứng dụng di động phục vụ cho các hoạt động tác nghiệp của mình. Tuy nhiên, ứng dụng này cũng tồn tại những lỗ hổng bảo mật tiềm tàng, dễ bị kẻ tấn công khai thác nhằm truy cập trái phép vào tài nguyên công nghệ thông tin của tổ chức hoặc dữ liệu cá nhân của người dùng. Để giúp giảm thiểu các lỗ hổng, nâng cao khả năng an toàn khi sử dụng cũng như đảm bảo rằng ứng dụng tuân thủ các yêu cầu bảo mật đặt ra, NIST đưa ra khuyến cáo cho việc đánh giá an toàn ứng dụng di động theo yêu cầu của tổ chức sử dụng các ứng dụng đó.
Tài liệu Kiểm tra an toàn ứng dụng di động (VSMA - Vetting the Security of Mobile Applications - NIST Special Publication 800-163) được xây dựng bởi NIST, với quy trình đánh giá gồm hai nội dung chính: thử nghiệm ứng dụng và chấp nhận/từ chối ứng dụng đó. Trong đó, thử nghiệm ứng dụng là các hoạt động kiểm tra lỗ hổng phần mềm bằng cách sử dụng các công cụ, dịch vụ để đưa ra các báo cáo lỗ hổng và đánh giá rủi ro. Chấp nhận/từ chối là hành động liên quan đến đánh giá các báo cáo và đánh giá rủi ro cùng với các tiêu chí bổ sung để xác định sự phù hợp của ứng dụng với yêu cầu bảo mật tổ chức và cuối cùng là chấp nhận hay không chấp nhận triển khai ứng dụng di động vào trong hoạt động của tổ chức.
Bài viết này sẽ tập trung giới thiệu về một số nội dung đánh giá an toàn ứng dụng di động theo tài liệu NIST SP 800-163.
Quy trình kiểm tra ứng dụng
Trước khi đưa ứng dụng vào triển khai trong tổ chức việc cần thiết đầu tiên là phải đánh giá an toàn ứng dụng di động. Để việc đánh giá an toàn ứng dụng di động có thể thực hiện, đầu tiên tổ chức phải đưa ra được các yêu cầu an toàn và mức độ rủi ro chấp nhận được của chính tổ chức làm căn cứ đánh giá. Tổ chức có thể tự mình hoặc thông qua các chuyên gia xây dựng các yêu cầu an toàn. Khi đã xây dựng được các yêu cầu an toàn, việc đánh giá an toàn ứng dụng di động chính là thực hiện quy trình kiểm tra ứng dụng có tuân thủ các yêu cầu an toàn đã được xây dựng của tổ chức hay không.
Quy trình này được thực hiện sau khi ứng dụng được phát triển và phát hành nhưng chưa được triển khai trong tổ chức. Do đó, quá trình đánh giá an toàn ứng dụng di động của NIST khác với quy trình đảm bảo an toàn ứng dụng trong vòng đời phát triển ứng dụng.
Hình 1: Quy trình đánh giá an toàn ứng dụng di động của NIST
Quá trình đánh giá an toàn ứng dụng di động bắt đầu từ việc người quản trị chuyển ứng dụng (từ kho ứng dụng hoặc từ nhà phát triển) đến người phân tích để thực hiện phân tích, đánh giá.
Người quản trị là thành viên của tổ chức chịu trách nhiệm triển khai, duy trì đánh giá ứng dụng di động theo yêu cầu an toàn của tổ chức.
Người phân tích có trong tay các dịch vụ, công cụ và con người để phân tích, tìm kiếm các lỗ hổng an toàn. Sau khi đánh giá an toàn, một báo cáo về lỗ hổng và đánh giá rủi ro được xây dựng và chuyển cho người kiểm tra để đưa ra khuyến nghị và chuyển cho người phê duyệt.
Người phê duyệt sẽ đánh giá dựa trên các yêu cầu an toàn của tổ chức để xác định xem ứng dụng có vi phạm bất kỳ các yêu cầu an toàn nào không. Sau khi đánh giá tất cả các báo cáo gồm cả các báo cáo về đánh giá rủi ro và tiêu chí an toàn của tổ chức, người phê duyệt sẽ tổng hợp và đưa ra ý kiến chấp nhận hay từ chối sử dụng ứng dụng trong tổ chức. Đề xuất này được gửi cho người quản trị trong tổ chức.
Cuối cùng, người quản trị sẽ xem xét và đưa ra quyết định đối với ứng dụng di động. Nếu ứng dụng được chấp nhận, người quản trị sẽ cho phép triển khai ứng dụng đó trên các thiết bị di động của tổ chức. Trong trường hợp ngược lại, nếu tổ chức vẫn mong muốn triển khai ứng dụng, tổ chức sẽ đưa ra yêu cầu đối với nhà phát triển khắc phục các vấn đề an toàn còn tồn tại hoặc tiếp tục xác định các phương án sử dụng các ứng dụng tương đồng khác, đồng thời lặp lại việc đánh giá đối với ứng dụng mới được xác định có khả năng thay thế.
Thử nghiệm ứng dụng
Lưu ý đầu tiên của NIST trong việc thử nghiệm ứng dụng là tổ chức thử nghiệm cần tuân thủ theo yêu cầu an toàn ứng dụng trước khi quan tâm tới lỗ hổng tồn tại trong ứng dụng. Tổ chức thử nghiệm phải đảm bảo tính toàn vẹn của ứng dụng, bảo vệ quyền sở hữu trí tuệ, bảo mật liên quan đến việc truyền tải, lưu trữ và xử lý ứng dụng trong quá trình đánh giá và đảm bảo tuân thủ các thoả thuận khác. Nếu tổ chức trong quá trình đánh giá an toàn ứng dụng di động để lộ mã nguồn ứng dụng, thì tổ chức đó phải chịu trách nhiệm trước pháp luật về quyền sở hữu trí tuệ.
Việc thử nghiệm ứng dụng được bắt đầu từ các yêu cầu chung với các phương pháp thử nghiệm được sử dụng để phát hiện các lỗ hổng vi phạm những yêu cầu an toàn đặt ra. Yêu cầu an toàn chung là yêu cầu an toàn đặc tả các tính chất và hành vi cần thiết của ứng dụng để đảm bảo tính an toàn, gồm các yếu tố sau:
Tính năng uỷ quyền: ứng dụng phải làm việc như mô tả, tất cả các nút, menu và các giao diện phải hoạt động. Việc kiểm tra bao gồm các kiểm tra từ màn hình người dùng, bàn phím vật lý, bàn phím ảo cho tới các cảm biến trên thiết bị như GPS, camera, micro, cảm biến định hướng,… có được phép sử dụng hay không.
Ngăn chặn chức năng trái phép: Chức năng trái phép là các chức năng không được phép thực thi, phải được ngăn chặn. Các chức năng này có thể là: các chức năng làm rò rỉ dữ liệu của người dùng tới bên thứ ba, truyền các thông tin nhạy cảm định danh thiết bị, lừa gạt người dùng bằng tin nhắn cao cấp (các tin nhắn được sử dụng để thanh toán sản phẩm, dịch vụ), theo dõi trái phép vị trí người dùng, tiêm các trang web giả mạo vào trình duyệt,…
Giới hạn quyền: Ứng dụng chỉ nên có các quyền tối thiểu cần thiết mà vẫn đảm bảo thực hiện được các hoạt động. Một số ứng dụng sử dụng chức năng không nhất quán với quyền, mô tả của ứng dụng hay một số ứng dụng yêu cầu những quyền mà không thực sự cần để ứng dụng hoạt động. Các quyền vượt mức thể hiện dưới một trong các dạng: các dữ liệu vào/ra và lưu trữ trên thẻ nhớ di động; các lệnh đặc quyền (cho phép truy cập tới các cấu trúc sâu hơn) hay thông qua các API (cho phép gọi và thực hiện từ các API khác).
Bảo vệ dữ liệu nhạy cảm: Các ứng dụng thu thập, lưu trữ và truyền dữ liệu nhạy cảm phải bảo vệ tính bí mật và tính toàn vẹn của dữ liệu này. Danh mục này bao gồm bảo mật quyền riêng tư, chẳng hạn như yêu cầu quyền sử dụng thông tin cá nhân và chỉ sử dụng thông tin đó cho mục đích được uỷ quyền. Nhằm nâng cao tính an toàn và chất lượng của các ứng dụng trong việc bảo vệ dữ liệu nhạy cảm. Trước đó, NIST đã ban hành và khuyến nghị áp dụng đối với các ứng dụng “Tiêu chuẩn xử lý liên bang FIPS 140-2”. Tiêu chuẩn này quy định việc sử dụng các thuật toán mật mã, các yêu cầu an toàn, bảo mật đối với các mô đun mật mã.
An toàn mã nguồn: Các ứng dụng di động không được sử dụng bất kỳ đoạn mã hay thư viện không an toàn nào, cần đảm bảo các thư viện này không chứa các điểm yếu, hạn chế sử dụng các thư viện không kiểm soát được.
Kiểm tra cập nhật ứng dụng: Các phiên bản mới của ứng dụng phải được kiểm tra để xác định điểm yếu trước khi cập nhật. Mục đích chính là để xác nhận rằng ứng dụng tuân thủ mức độ rủi ro bảo mật đã được xác định và xác định xem nhà phát triển có vô tình tạo ra điểm yếu bảo mật tiềm ẩn ảnh hưởng tới hạ tầng không.
Để thực hiện được những yêu cầu bảo mật trên, NIST đưa ra khuyến nghị về phương pháp đánh giá an toàn ứng dụng di động gồm: (1) kiểm tra tính chính xác, (2) đánh giá mã nguồn ứng dụng hoặc mã máy, (3) sử dụng phân tích tĩnh và phân tích động, (4) công cụ hỗ trợ đánh giá.
Kiểm tra tính chính xác của ứng dụng là quá trình thực hiện chương trình với mục đích tìm lỗi nhằm cải thiện chất lượng, xác minh và xác thực tính năng được mô tả, hoặc ước tính tác động tiêu cực đến chất lượng, chức năng và độ tin cậy của ứng dụng. Đối với NIST, kiểm tra tính chính xác của ứng dụng di động dựa trên nền tảng đánh giá tính chính xác của ứng dụng nói chung và các đặc điểm kỹ thuật của ứng dụng cụ thể cần kiểm tra.
Các mục tiêu của việc thực hiện đánh giá mã nguồn là tìm các lỗ hổng trong mã nguồn và để xác minh các kết quả từ các công cụ phát hiện điểm yếu trong mã nguồn. Thông thường, việc đánh giá mã nguồn được thực hiện thủ công bởi người đánh giá an toàn mã nguồn. Khi mã nguồn ứng dụng không có sẵn (hoặc đã bị làm rối mã), việc đánh giá an toàn mã nguồn sẽ được xem xét trên nền tảng mã nhị phân (trong tài liệu của NIST, “mã nhị phân” được đề cập ở đây có thể tham chiếu đến mã máy).
Các công cụ phân tích thường được mô tả là phân tích tĩnh hoặc phân tích động. Phân tích tĩnh kiểm tra mã nguồn ứng dụng và mã nhị phân, cố gắng làm rõ mọi hành vi có thể xảy ra khi chạy ứng dụng. Nó cung cấp một mức độ đảm bảo kết quả phân tích là một mô tả chính xác về hành vi của chương trình không, mặc dù có hay không môi trường thực thi hay đầu vào. Phân tích động hoạt động bằng cách thực hiện một chương trình cần xử lý sử dụng một bộ các đầu vào và phân tích hành vi khi ứng dụng hoạt động. NIST khuyến nghị các đơn vị đánh giá an toàn cho ứng dụng di động cần phải kết hợp cả hai phương pháp phân tích tĩnh và phân tích động.
Trong hầu hết các trường hợp, việc đánh giá an toàn ứng dụng di động cần phải sử dụng nhiều công cụ tự động để đáp ứng các yêu cầu kiểm tra. Sử dụng nhiều công cụ giúp khả năng phát hiện lỗ hổng ứng dụng di động được cải thiện cũng như nâng cao tính chính xác của kết quả cho những công cụ cung cấp kiểm tra trùng lặp.
Các công cụ tự động bao gồm:
+ Trình mô phỏng: trình giả lập ứng dụng trên máy tính.
+ Truy cập thiết bị từ xa: truy cập thiết bị từ máy tính.
+ Kiểm tra tự động: Tạo các tập lệnh tự động để chạy các trường hợp kiểm tra hồi quy từ xa trên thiết bị. Công cụ thuộc nhóm này gồm: các công cụ thử nghiệm giao diện và điều khiển người dùng; điều khiển và dữ liệu; fuzzing; thử nghiệm mức mạng.
+ Tự động hoá thử nghiệm: Công cụ tự động hoá việc lặp lại các kiểu tra sau khi chúng được thiết kế bởi con người (hữu ích với các bài kiểm tra cần lặp lại thường xuyên).
+ Công cụ phân tích tĩnh: Phân tích hành vi của ứng dụng (công cụ phân tích tĩnh) và đo lường các yếu tố của phần mềm không liên quan trực tiếp đến hành vi, nhưng hữu ích trong việc dự đoán thông tin phụ trợ cho việc kiểm định mã ứng dụng (công cụ độ đo).
Các thông tin kết quả kiểm tra, đánh giá lỗ hổng ứng dụng di động theo NIST sẽ được chia sẻ. Đây là cơ sở giúp cho các tổ chức đánh giá giảm thiểu chi phí tìm kiếm, đánh giá lại các lỗ hổng đã được phát hiện thông qua cơ sở dữ liệu điểm yếu quốc gia (National Vulnerability Database - NVD). Cơ sở dữ liệu này là kho lưu trữ dữ liệu quản lý điểm yếu dựa trên tiêu chuẩn của Mỹ sử dụng giao thức tự động hóa nội dung bảo mật (Security Content Automation Protocol - SCAP). Dữ liệu này cho phép tự động hóa quản lý lỗ hổng, đánh giá an toàn và tuân thủ. NVD bao gồm cơ sở dữ liệu về danh sách kiểm tra an toàn (checklist), lỗi phần mềm liên quan đến bảo mật, cấu hình sai, tên sản phẩm và độ đo tác động.
Để thuận lợi cho việc triển khai đánh giá ứng dụng, trong tài liệu còn đưa vào 02 phần phụ lục quan trọng: Phụ lục B – Các loại điểm yếu ứng dụng Android và phụ lục C – Các loại điểm yếu ứng dụng iOS.
Trong 02 phụ lục này chỉ ra các điểm yếu của các ứng dụng chạy HĐH Android và iOS, nhưng không bao gồm các điểm yếu nền tảng phần cứng và mạng. Các điểm yếu được phân loại theo 03 mức đánh giá từ thấp tới cao là A, B, C.
Mức A là mức điểm yếu mô tả rộng nhất cho các lỗ hổng được chỉ định ở cấp đó.
Mức B được gọi là mức con thu hẹp phạm vi của lớp dễ bị tổn thương vào một nhóm lỗ hổng nhỏ hơn, phổ biến.
Mức C đặc tả lỗ hổng riêng đã được xác định.
Mục đích của cấu trúc phân cấp này là hướng dẫn người triển khai tìm ra loại lỗ hổng mà họ đang tìm kiếm càng nhanh càng tốt. Ngoài ra, các đề xuất liên quan đến hoạt động thử nghiệm ứng dụng được mô tả trong Phụ lục A.2. Thông tin về các công cụ và kỹ thuật kiểm tra và đánh giá bảo mật có thể hữu ích cho việc thực hiện thử nghiệm ứng dụng được trình bày trong tài liệu [2].
Chấp nhận/Từ chối ứng dụng
Người kiểm tra sẽ nhận các báo cáo về an toàn từ phía người phân tích và đưa ra các khuyến nghị về ứng dụng di động được đánh giá. Người kiểm tra cũng đánh giá ứng dụng liên quan đến các yêu cầu ngữ cảnh - nhạy cảm của tổ chức bằng cách sử dụng tiêu chí đánh giá riêng của tổ chức để đưa ra bản báo cáo hoàn chỉnh.
Sự khác nhau giữa người kiểm tra và người phê duyệt là người kiểm tra sẽ xem xét an toàn ứng dụng di động dựa trên các lỗ hổng an toàn chung (có thể được cộng đồng an toàn ứng dụng di động trên thế giới thông báo). Trong khi đó, người phê duyệt sẽ xem xét ứng dụng di động đó trên nền hệ thống triển khai và yêu cầu an toàn của tổ chức. Ngoài ra, người phê duyệt cần đánh giá ứng dụng dựa trên hiểu biết về nhà phát triển ứng dụng, độ nhạy cảm của dữ liệu sử dụng, mức độ quan trọng của ứng dụng với quy trình kinh doanh, những người dùng dự định, nền tảng phần cứng hỗ trợ triển khai, môi trường hoạt động của ứng dụng. Dựa trên tất cả những vấn đề trên, người phê duyệt mới đưa ra ý kiến của mình về việc chấp nhận hay từ chối sử dụng ứng dụng trong tổ chức.
Cuối cùng, việc quyết định thuộc về người quản trị của tổ chức. Người quản trị ngoài xem xét các vấn đề về bảo mật, sẽ phải xem xét các thông tin bổ sung như tiêu chí ngân sách, chính sách và hướng phát triển… để đưa ra quyết định phù hợp với tổ chức của mình.
Kết luận
Phương pháp đánh giá an toàn ứng dụng di động theo NIST hướng tới việc đánh giá, kiểm tra ứng dụng di động có tuân thủ các yêu cầu bảo mật của tổ chức hay không. Phương pháp đánh giá này được xây dựng kế thừa từ phương pháp đánh giá an toàn phần mềm mà NIST đã từng ban hành, do đó có những hạng mục chưa thực sự phù hợp cũng như chưa theo kịp sự phát triển của ứng dụng di động. Tuy nhiên nó vẫn có những ưu điểm riêng, được nhiều chuyên gia đánh giá an toàn nghiên cứu, áp dụng và coi đây như một cẩm nang tham khảo khi triển khai việc đánh giá an toàn ứng dụng di động.
Phương pháp VSMA này được xây dựng theo hướng tiếp cận của cơ quan quản lý (xây dựng bởi NIST) nhằm hướng tới việc xác nhận ứng dụng di động có nên được đưa vào sử dụng hay không và cũng rất phù hợp với các tổ chức, phòng thí nghiệm đánh giá an toàn ứng dụng di động.
Một cách tiếp cận khác dành cho việc đánh giá ứng dụng di động cũng được các chuyên gia quan tâm và áp dụng là đánh giá theo phương pháp của OWASP với mục tiêu đánh giá an toàn ứng dụng di động theo phân cấp bảo mật (MASVS-L1, MASVS-L1+R, MASVS-L2, MASVS-L2+R) với khuyến nghị đánh giá với các yêu cầu đạt được cụ thể theo từng mức độ.
Hiện nay, phương pháp đánh giá VSMA theo NIST vẫn đang được các chuyên gia của NIST tiếp tục nghiên cứu, cập nhật và phát triển. Cùng với việc sử dụng cơ sở dữ liệu điểm yếu của NIST, nên cũng chính là một trong những ưu thế quan trọng trong việc sử dụng phương pháp, đảm bảo là căn cứ quan trọng để đưa các sản phẩm ứng dụng di động vào sử dụng trong các tổ chức.
|
Tài liệu tham khảo [1]. Steve Quirolgico, Jeffrey Voas, Tom Karygiannis, Christoph Michael,Karen Scarfone, Vetting the Security of Mobile Applications, NIST Special Publication (SP) 800-163, 01/2015 http://dx.doi.org/10.6028/NIST.SP.800-163 (06/2018). [2]. K. Scarfone, M. Souppaya, A. Cody and A. Orebaugh, Technical Guide to Information Security Testing and Assessment, NIST Special Publication (SP) 800-115, September 2008. http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf. |
TS. Nguyễn Viết Phan, KS. Phạm Ánh Dương
