Là một phần trong hoạt động nghề nghiệp của mình, các nhà phát triển, người thử nghiệm và chuyên gia bảo mật phải xử lý các quy trình như Quản lý lỗ hổng bảo mật (VM), SDLC (Bảo mật).
Bên dưới những cụm từ này là các tập hợp thực tiễn và công cụ khác nhau được sử dụng đan xen với nhau, mặc dù người dùng của chúng khác nhau.
Tiến bộ kỹ thuật vẫn chưa đạt đến mức một công cụ có thể thay thế con người để phân tích tính bảo mật của cơ sở hạ tầng và phần mềm.
Thật thú vị khi hiểu tại sao lại như vậy và những vấn đề mà người ta phải đối mặt.
Процессы
Quy trình Quản lý lỗ hổng được thiết kế để giám sát liên tục về bảo mật cơ sở hạ tầng và quản lý bản vá.
Quy trình SDLC bảo mật (“chu trình phát triển an toàn”) được thiết kế để duy trì tính bảo mật của ứng dụng trong quá trình phát triển và vận hành.
Một phần tương tự của các quy trình này là quy trình Đánh giá lỗ hổng - đánh giá lỗ hổng, quét lỗ hổng.
Sự khác biệt chính giữa quét VM và SDLC là trong trường hợp đầu tiên, mục tiêu là phát hiện các lỗ hổng đã biết trong phần mềm hoặc cấu hình của bên thứ ba. Ví dụ: phiên bản Windows đã lỗi thời hoặc chuỗi cộng đồng mặc định cho SNMP.
Trong trường hợp thứ hai, mục tiêu là phát hiện các lỗ hổng không chỉ trong các thành phần (phụ thuộc) của bên thứ ba mà chủ yếu trong mã của sản phẩm mới.
Điều này tạo ra sự khác biệt về công cụ và cách tiếp cận. Theo tôi, nhiệm vụ tìm kiếm các lỗ hổng mới trong một ứng dụng thú vị hơn nhiều, vì nó không liên quan đến các phiên bản lấy dấu vân tay, thu thập biểu ngữ, mật khẩu cưỡng bức, v.v.
Để quét tự động chất lượng cao các lỗ hổng ứng dụng, cần có các thuật toán tính đến ngữ nghĩa của ứng dụng, mục đích của ứng dụng và các mối đe dọa cụ thể.
Máy quét cơ sở hạ tầng thường có thể được thay thế bằng bộ đếm thời gian, như tôi đã nói . Vấn đề là, hoàn toàn theo thống kê, bạn có thể coi cơ sở hạ tầng của mình dễ bị tổn thương nếu bạn không cập nhật nó trong một tháng.
Dụng cụ
Quét, giống như phân tích bảo mật, có thể được thực hiện bằng hộp đen hoặc hộp trắng.
Black Box
Khi quét hộp đen, công cụ phải có khả năng hoạt động với dịch vụ thông qua cùng giao diện mà người dùng làm việc với dịch vụ đó.
Các máy quét cơ sở hạ tầng (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, v.v.) tìm kiếm các cổng mạng mở, thu thập “biểu ngữ”, xác định phiên bản của phần mềm đã cài đặt và tìm kiếm cơ sở kiến thức của họ để biết thông tin về các lỗ hổng trong các phiên bản này. Họ cũng cố gắng phát hiện các lỗi cấu hình như mật khẩu mặc định hoặc truy cập dữ liệu mở, mật mã SSL yếu, v.v.
Máy quét ứng dụng web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, v.v.) cũng có thể xác định các thành phần đã biết và phiên bản của chúng (ví dụ: CMS, khung, thư viện JS). Các bước chính của máy quét là thu thập dữ liệu và làm mờ.
Trong quá trình thu thập thông tin, máy quét sẽ thu thập thông tin về giao diện ứng dụng hiện có và các tham số HTTP. Trong quá trình làm mờ, dữ liệu bị thay đổi hoặc được tạo sẽ được chèn vào tất cả các tham số được phát hiện nhằm gây ra lỗi và phát hiện lỗ hổng.
Các máy quét ứng dụng như vậy lần lượt thuộc lớp DAST và IAST - Kiểm tra bảo mật ứng dụng động và tương tác.
Hộp trắng
Có nhiều sự khác biệt hơn khi quét hộp trắng.
Là một phần của quy trình VM, các máy quét (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, v.v.) thường được cấp quyền truy cập vào hệ thống bằng cách thực hiện quét xác thực. Do đó, máy quét có thể tải xuống các phiên bản gói đã cài đặt và thông số cấu hình trực tiếp từ hệ thống mà không cần đoán chúng từ các biểu ngữ dịch vụ mạng.
Quá trình quét chính xác và đầy đủ hơn.
Nếu chúng ta nói về quét hộp trắng (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, v.v.) của các ứng dụng, thì chúng ta thường nói về phân tích mã tĩnh và việc sử dụng các công cụ thích hợp của lớp SAST - Kiểm tra bảo mật ứng dụng tĩnh.
Vấn đề
Có rất nhiều vấn đề với việc quét! Cá nhân tôi phải giải quyết hầu hết chúng như một phần của việc cung cấp dịch vụ xây dựng quy trình quét và phát triển bảo mật, cũng như khi tiến hành công việc phân tích bảo mật.
Tôi sẽ nêu bật 3 nhóm vấn đề chính, được xác nhận qua các cuộc trò chuyện với các kỹ sư và người đứng đầu dịch vụ bảo mật thông tin ở nhiều công ty.
Sự cố quét ứng dụng web
- Khó khăn trong việc thực hiện. Máy quét cần được triển khai, định cấu hình, tùy chỉnh cho từng ứng dụng, phân bổ môi trường thử nghiệm để quét và triển khai trong quy trình CI/CD để việc này có hiệu quả. Nếu không, đó sẽ là một thủ tục hình thức vô ích và chỉ tạo ra những kết quả dương tính giả
- Thời lượng quét. Ngay cả trong năm 2019, máy quét thực hiện công việc loại bỏ giao diện trùng lặp rất kém và có thể mất nhiều ngày để quét hàng nghìn trang với 10 thông số trên mỗi trang, coi chúng là khác nhau, mặc dù chúng chịu trách nhiệm về cùng một mã. Đồng thời, quyết định triển khai vào sản xuất trong chu kỳ phát triển phải được đưa ra nhanh chóng.
- Khuyến nghị kém. Máy quét đưa ra các đề xuất khá chung chung và nhà phát triển không phải lúc nào cũng có thể nhanh chóng hiểu được cách giảm mức độ rủi ro từ chúng và quan trọng nhất là liệu việc đó có cần phải được thực hiện ngay bây giờ hay nó vẫn chưa đáng sợ
- Tác động tiêu cực đến ứng dụng. Máy quét có thể thực hiện một cuộc tấn công DoS vào một ứng dụng và cũng có thể tạo một số lượng lớn thực thể hoặc thay đổi các thực thể hiện có (ví dụ: tạo hàng chục nghìn nhận xét trên blog), vì vậy bạn không nên khởi động quá trình quét một cách thiếu suy nghĩ trong sản xuất
- Chất lượng phát hiện lỗ hổng thấp. Máy quét thường sử dụng một mảng tải trọng cố định và có thể dễ dàng bỏ sót lỗ hổng không phù hợp với kịch bản hành vi đã biết của ứng dụng.
- Máy quét không hiểu chức năng của ứng dụng. Bản thân máy quét cũng không biết “Internet Banking”, “thanh toán”, “bình luận” là gì. Đối với họ, chỉ có các liên kết và tham số, do đó, một lớp lớn các lỗ hổng logic kinh doanh có thể xảy ra vẫn hoàn toàn chưa được khám phá; họ sẽ không nghĩ đến việc xóa sổ hai lần, theo dõi dữ liệu của người khác bằng ID hoặc tăng số dư thông qua làm tròn
- Máy quét không hiểu ngữ nghĩa của các trang. Máy quét không thể đọc Câu hỏi thường gặp, không thể nhận dạng hình ảnh xác thực và không thể tìm ra cách đăng ký và sau đó đăng nhập lại, bạn không thể nhấp vào “đăng xuất” và cách ký yêu cầu khi thay đổi tham số các giá trị. Kết quả là hầu hết ứng dụng có thể không được quét.
Sự cố khi quét mã nguồn
- Dương tính giả. Phân tích tĩnh là một nhiệm vụ phức tạp đòi hỏi nhiều sự đánh đổi. Độ chính xác thường phải hy sinh và ngay cả những máy quét doanh nghiệp đắt tiền cũng tạo ra một số lượng lớn kết quả dương tính giả
- Khó khăn trong việc thực hiện. Để tăng độ chính xác và đầy đủ của phân tích tĩnh, cần phải tinh chỉnh các quy tắc quét và việc viết các quy tắc này có thể tốn nhiều công sức. Đôi khi, việc tìm ra tất cả các vị trí có lỗi trong mã và sửa chúng sẽ dễ dàng hơn là viết quy tắc để phát hiện những trường hợp như vậy
- Thiếu sự hỗ trợ phụ thuộc. Các dự án lớn phụ thuộc vào một số lượng lớn các thư viện và khung công tác giúp mở rộng khả năng của ngôn ngữ lập trình. Nếu cơ sở kiến thức của máy quét không có thông tin về "phần chìm" trong các khung này, nó sẽ trở thành một điểm mù và máy quét thậm chí sẽ không hiểu được mã
- Thời lượng quét. Tìm lỗ hổng trong mã là một nhiệm vụ phức tạp về mặt thuật toán. Do đó, quá trình này có thể mất nhiều thời gian và yêu cầu tài nguyên máy tính đáng kể.
- Độ che phủ thấp. Bất chấp việc tiêu tốn tài nguyên và thời gian quét, các nhà phát triển công cụ SAST vẫn phải thỏa hiệp và phân tích không phải tất cả các trạng thái mà chương trình có thể ở
- Khả năng tái tạo của các phát hiện. Việc trỏ đến dòng và ngăn xếp cuộc gọi cụ thể dẫn đến lỗ hổng là điều tuyệt vời, nhưng trên thực tế, máy quét thường không cung cấp đủ thông tin để kiểm tra sự hiện diện của lỗ hổng từ bên ngoài. Rốt cuộc, lỗ hổng cũng có thể nằm ở mã chết, kẻ tấn công không thể truy cập được.
Sự cố quét cơ sở hạ tầng
- Hàng tồn kho không đủ. Trong các cơ sở hạ tầng lớn, đặc biệt là những cơ sở hạ tầng tách biệt về mặt địa lý, việc biết máy chủ nào cần quét thường là điều khó khăn nhất. Nói cách khác, nhiệm vụ quét liên quan chặt chẽ đến nhiệm vụ quản lý tài sản
- Ưu tiên kém. Máy quét mạng thường tạo ra nhiều kết quả có lỗ hổng không thể khai thác được trong thực tế, nhưng về mặt hình thức mức độ rủi ro của chúng là cao. Người tiêu dùng nhận được một báo cáo khó giải thích và không rõ cần phải sửa điều gì trước tiên.
- Khuyến nghị kém. Cơ sở kiến thức của máy quét thường chỉ chứa thông tin rất chung chung về lỗ hổng và cách khắc phục, vì vậy quản trị viên sẽ phải tự trang bị cho Google. Tình hình tốt hơn một chút với máy quét hộp trắng, có thể đưa ra lệnh cụ thể để khắc phục
- Làm bằng tay. Cơ sở hạ tầng có thể có nhiều nút, nghĩa là có thể có nhiều sai sót, các báo cáo về chúng phải được phân tích cú pháp và phân tích thủ công ở mỗi lần lặp
- Độ che phủ kém. Chất lượng quét cơ sở hạ tầng trực tiếp phụ thuộc vào quy mô của cơ sở kiến thức về các lỗ hổng và phiên bản phần mềm. Trong đó, , ngay cả những người dẫn đầu thị trường cũng không có nền tảng kiến thức toàn diện và cơ sở dữ liệu của các giải pháp miễn phí chứa rất nhiều thông tin mà những người dẫn đầu không có
- Vấn đề với việc vá lỗi. Thông thường, việc vá các lỗ hổng cơ sở hạ tầng liên quan đến việc cập nhật gói hoặc thay đổi tệp cấu hình. Vấn đề lớn ở đây là một hệ thống, đặc biệt là hệ thống cũ, có thể hoạt động không thể đoán trước do cập nhật. Về cơ bản, bạn sẽ phải tiến hành thử nghiệm tích hợp trên cơ sở hạ tầng trực tiếp trong sản xuất.
Phương pháp tiếp cận
Làm thế nào để được?
Tôi sẽ cho bạn biết thêm về các ví dụ và cách giải quyết nhiều vấn đề được liệt kê trong các phần sau, nhưng bây giờ tôi sẽ chỉ ra các hướng chính mà bạn có thể làm việc:
- Tổng hợp các công cụ quét khác nhau. Với việc sử dụng đúng cách một số máy quét, bạn có thể đạt được sự gia tăng đáng kể về nền tảng kiến thức và chất lượng phát hiện. Bạn thậm chí có thể tìm thấy nhiều lỗ hổng hơn tổng số tất cả các máy quét được khởi chạy riêng lẻ, đồng thời bạn có thể đánh giá chính xác hơn mức độ rủi ro và đưa ra nhiều đề xuất hơn
- Tích hợp SAST và DAST. Có thể tăng phạm vi bao phủ của DAST và độ chính xác của SAST bằng cách trao đổi thông tin giữa chúng. Từ các nguồn, bạn có thể nhận thông tin về các tuyến đường hiện có và sử dụng DAST, bạn có thể kiểm tra xem lỗ hổng có hiển thị từ bên ngoài hay không
- Học máy™. Năm 2015 tôi (và ) về việc sử dụng số liệu thống kê để cung cấp cho máy quét khả năng trực giác của hacker và tăng tốc chúng. Đây chắc chắn là nguồn thức ăn cho sự phát triển của phân tích bảo mật tự động trong tương lai.
- Tích hợp IAST với autotests và OpenAPI. Trong quy trình CI/CD, có thể tạo quy trình quét dựa trên các công cụ hoạt động như proxy HTTP và các bài kiểm tra chức năng hoạt động qua HTTP. Các thử nghiệm và hợp đồng OpenAPI/Swagger sẽ cung cấp cho máy quét thông tin còn thiếu về luồng dữ liệu và giúp quét ứng dụng ở nhiều trạng thái khác nhau
- Cấu hình đúng. Đối với mỗi ứng dụng và cơ sở hạ tầng, bạn cần tạo hồ sơ quét phù hợp, có tính đến số lượng và tính chất của giao diện cũng như công nghệ được sử dụng
- Tùy chỉnh máy quét. Thông thường, không thể quét ứng dụng nếu không sửa đổi máy quét. Một ví dụ là cổng thanh toán, trong đó mỗi yêu cầu phải được ký. Nếu không ghi một trình kết nối vào giao thức cổng, máy quét sẽ vô tình bắn phá các yêu cầu có chữ ký sai. Cũng cần thiết phải viết các máy quét chuyên dụng cho một loại lỗi cụ thể, chẳng hạn như
- Quản lý rủi ro. Việc sử dụng nhiều máy quét khác nhau và tích hợp với các hệ thống bên ngoài như Quản lý tài sản và Quản lý mối đe dọa sẽ cho phép sử dụng nhiều tham số để đánh giá mức độ rủi ro, để ban quản lý có thể có được bức tranh đầy đủ về trạng thái an ninh hiện tại của quá trình phát triển hoặc cơ sở hạ tầng
Hãy theo dõi và hãy làm gián đoạn quá trình quét lỗ hổng!
Nguồn: www.habr.com