Chúng tôi có 2 máy phân tích mã, 4 công cụ kiểm tra động, các công cụ thủ công của riêng chúng tôi và 250 tập lệnh. Không phải tất cả những điều này đều cần thiết trong quy trình hiện tại, nhưng một khi bạn bắt đầu triển khai DevSecOps, bạn phải đi đến cùng.
. Người sáng tạo nhân vật: Justin Roiland và Dan Harmon.
SecDevOps là gì? Còn DevSecOps thì sao? Sự khác biệt là gì? Bảo mật ứng dụng - nó nói về cái gì? Tại sao phương pháp cổ điển không còn hiệu quả nữa? Biết câu trả lời cho tất cả những câu hỏi này Yuri Shabalin của An ninh cá kiếm. Yuri sẽ trả lời chi tiết mọi thứ và phân tích các vấn đề trong quá trình chuyển đổi từ mô hình Bảo mật ứng dụng cổ điển sang quy trình DevSecOps: cách tiếp cận đúng cách việc tích hợp quy trình phát triển an toàn vào quy trình DevOps và không phá vỡ bất cứ điều gì, cách thực hiện các giai đoạn chính kiểm tra bảo mật, những công cụ nào có thể được sử dụng và chúng khác nhau như thế nào cũng như cách định cấu hình chúng một cách chính xác để tránh những cạm bẫy.
Về diễn giả: Yu Ri Shabalin - Kiến trúc sư trưởng về an ninh trong công ty An ninh cá kiếm. Chịu trách nhiệm triển khai SSDL, tích hợp tổng thể các công cụ phân tích ứng dụng vào một hệ sinh thái thử nghiệm và phát triển thống nhất. 7 năm kinh nghiệm trong lĩnh vực bảo mật thông tin. Làm việc tại Alfa-Bank, Sberbank và Positive Technologies, công ty phát triển phần mềm và cung cấp dịch vụ. Diễn giả tại các hội nghị quốc tế ZerONights, PHDays, RISSPA, OWASP.
Bảo mật ứng dụng: nó nói về cái gì?
Bảo mật ứng dụng - Đây là phần bảo mật chịu trách nhiệm bảo mật ứng dụng. Điều này không áp dụng cho cơ sở hạ tầng hoặc bảo mật mạng mà áp dụng cho những gì chúng tôi viết và những gì các nhà phát triển đang làm - đây là những thiếu sót và lỗ hổng của chính ứng dụng.
Hướng - Vòng đời phát triển bảo mật - được phát triển bởi Microsoft. Sơ đồ hiển thị mô hình SDLC chuẩn, nhiệm vụ chính của mô hình này là sự tham gia của bộ phận bảo mật ở mọi giai đoạn phát triển, từ yêu cầu đến phát hành và sản xuất. Microsoft nhận ra rằng có quá nhiều lỗi trong ngành, còn nhiều lỗi hơn và cần phải làm gì đó để khắc phục nó, và họ đã đề xuất phương pháp này, phương pháp này đã trở thành kinh điển.
Bảo mật ứng dụng và SSDL không nhằm mục đích phát hiện các lỗ hổng như người ta thường tin mà nhằm ngăn chặn sự xuất hiện của chúng. Theo thời gian, phương pháp tiếp cận chuẩn mực của Microsoft đã được cải tiến, phát triển và đưa vào phân tích sâu hơn, chi tiết hơn.
SDLC chuẩn có độ chi tiết cao theo nhiều phương pháp khác nhau - OpenSAMM, BSIMM, OWASP. Các phương pháp khác nhau, nhưng nói chung là giống nhau.
Xây dựng an ninh trong mô hình trưởng thành
Tôi thích nó nhất BSIMM - . Cơ sở của phương pháp này là việc phân chia quy trình Bảo mật ứng dụng thành 4 lĩnh vực: Quản trị, Thông minh, Điểm tiếp xúc SSDL và Triển khai. Mỗi lĩnh vực có 12 hoạt động, được thể hiện dưới dạng 112 hoạt động.
Mỗi hoạt động trong số 112 hoạt động đều có 3 cấp độ trưởng thành: người mới bắt đầu, trung cấp và cao cấp. Bạn có thể nghiên cứu tất cả 12 phương pháp thực hành theo từng phần, chọn những thứ quan trọng đối với mình, tìm ra cách triển khai chúng và dần dần thêm các yếu tố, chẳng hạn như phân tích mã tĩnh và động hoặc xem xét mã. Bạn viết ra một kế hoạch và bình tĩnh thực hiện theo nó như một phần của việc thực hiện các hoạt động đã chọn.
Tại sao DevSecOps
DevOps là một quy trình chung, quy mô lớn, trong đó vấn đề bảo mật phải được tính đến.
Ban đầu liên quan đến kiểm tra an ninh. Trên thực tế, số lượng đội bảo mật ít hơn nhiều so với hiện tại và họ không đóng vai trò là người tham gia quy trình mà là cơ quan kiểm soát và giám sát áp đặt các yêu cầu đối với quy trình đó và kiểm tra chất lượng sản phẩm khi kết thúc phát hành. Đây là một cách tiếp cận cổ điển trong đó các nhóm bảo mật đứng sau bức tường trong quá trình phát triển và không tham gia vào quá trình này.
Vấn đề chính là bảo mật thông tin tách rời khỏi sự phát triển. Thông thường đây là một loại mạch bảo mật thông tin và nó chứa 2-3 công cụ lớn và đắt tiền. Sáu tháng một lần, mã nguồn hoặc ứng dụng cần kiểm tra sẽ được gửi đến và chúng được sản xuất mỗi năm một lần. . Tất cả điều này dẫn đến thực tế là ngày phát hành của ngành bị trì hoãn và nhà phát triển phải đối mặt với một số lượng lớn lỗ hổng từ các công cụ tự động. Không thể tháo rời và sửa chữa tất cả những thứ này, bởi vì kết quả của sáu tháng trước vẫn chưa được phân loại, nhưng đây là một đợt mới.
Trong quá trình làm việc của công ty chúng tôi, chúng tôi thấy rằng an ninh trong tất cả các lĩnh vực và ngành công nghiệp hiểu rằng đã đến lúc phải bắt kịp và quay vòng với sự phát triển trên cùng một bánh xe - trong . Mô hình DevSecOps hoàn toàn phù hợp với phương pháp phát triển linh hoạt, triển khai, hỗ trợ và tham gia vào mọi bản phát hành và lặp lại.
Chuyển sang DevSecOps
Từ quan trọng nhất trong Vòng đời phát triển bảo mật là "quá trình". Bạn phải hiểu điều này trước khi nghĩ đến việc mua dụng cụ.
Chỉ kết hợp các công cụ vào quy trình DevOps là chưa đủ—việc giao tiếp và hiểu biết giữa những người tham gia quy trình là rất quan trọng.
Con người quan trọng hơn, không phải công cụ.
Thông thường, việc lập kế hoạch cho một quy trình phát triển an toàn bắt đầu bằng việc chọn và mua một công cụ và kết thúc bằng những nỗ lực tích hợp công cụ đó vào quy trình hiện tại, những nỗ lực này vẫn là những nỗ lực. Điều này dẫn đến những hậu quả đáng tiếc, bởi mọi công cụ đều có những đặc điểm và hạn chế riêng.
Một trường hợp phổ biến là khi bộ phận bảo mật chọn một công cụ tốt, đắt tiền với khả năng rộng rãi và đến gặp các nhà phát triển để tích hợp nó vào quy trình. Nhưng nó không thành công - quy trình được cấu trúc theo cách mà những hạn chế của công cụ đã mua không phù hợp với mô hình hiện tại.
Đầu tiên, hãy mô tả kết quả bạn mong muốn và quá trình sẽ diễn ra như thế nào. Điều này sẽ giúp hiểu được vai trò của công cụ và sự an toàn trong quy trình.
Bắt đầu với những gì đã được sử dụng
Trước khi mua những công cụ đắt tiền, hãy xem những gì bạn đã có. Công ty nào cũng có yêu cầu bảo mật để phát triển, có kiểm tra, pentest - tại sao không chuyển tất cả những điều này thành một hình thức dễ hiểu và thuận tiện cho mọi người?
Thông thường yêu cầu là một cuốn Talmud bằng giấy nằm trên kệ. Có trường hợp chúng tôi đến một công ty để xem quy trình và yêu cầu xem các yêu cầu bảo mật đối với phần mềm. Chuyên gia giải quyết vấn đề này đã dành một thời gian dài để tìm kiếm:
- Bây giờ, ở đâu đó trong ghi chú có một đường dẫn chứa tài liệu này.
Kết quả là chúng tôi nhận được tài liệu một tuần sau đó.
Đối với các yêu cầu, séc và những thứ khác, hãy tạo một trang trên ví dụ: Chổ hợp lưu - nó thuận tiện cho mọi người.
Việc định dạng lại những gì bạn đã có và sử dụng nó để bắt đầu sẽ dễ dàng hơn.
Sử dụng nhà vô địch bảo mật
Thông thường, trong một công ty trung bình có 100-200 nhà phát triển, có một chuyên gia bảo mật thực hiện một số chức năng và không có thời gian để kiểm tra mọi thứ. Ngay cả khi anh ta cố gắng hết sức, một mình anh ta sẽ không kiểm tra tất cả mã mà quá trình phát triển tạo ra. Đối với những trường hợp như vậy, một khái niệm đã được phát triển - .
Người hỗ trợ bảo mật là những người trong nhóm phát triển quan tâm đến tính bảo mật của sản phẩm của bạn.
Nhà vô địch bảo mật là điểm đầu vào của nhóm phát triển và một nhà truyền bá bảo mật đã hợp thành một.
Thông thường, khi một chuyên gia bảo mật đến gặp nhóm phát triển và chỉ ra lỗi trong mã, anh ta sẽ nhận được câu trả lời đầy ngạc nhiên:
- Còn bạn là ai? Tôi đang gặp bạn lần đầu tiên. Mọi thứ với tôi đều ổn - người bạn cấp cao của tôi đã cho tôi “đăng ký” trong bài đánh giá mã, chúng ta tiếp tục!
Đây là một tình huống điển hình, bởi vì người ta tin tưởng nhiều hơn vào cấp trên hoặc đơn giản là đồng đội mà nhà phát triển thường xuyên tương tác trong công việc và khi đánh giá mã. Nếu thay vì nhân viên an ninh, Security Champion chỉ ra sai lầm và hậu quả thì lời nói của anh ta sẽ có trọng lượng hơn.
Ngoài ra, các nhà phát triển biết rõ mã của họ hơn bất kỳ chuyên gia bảo mật nào. Đối với một người có ít nhất 5 dự án trong một công cụ phân tích tĩnh, thường rất khó để nhớ tất cả các sắc thái. Các nhà vô địch bảo mật biết rõ sản phẩm của họ: những gì tương tác với những gì và những gì cần xem xét đầu tiên - chúng hiệu quả hơn.
Vì vậy, hãy cân nhắc việc triển khai Security Champions và mở rộng tầm ảnh hưởng của nhóm bảo mật của bạn. Điều này cũng hữu ích cho bản thân nhà vô địch: phát triển chuyên môn trong một lĩnh vực mới, mở rộng tầm nhìn kỹ thuật, nâng cao kỹ năng kỹ thuật, quản lý và lãnh đạo, tăng giá trị thị trường. Đây là một số yếu tố của kỹ thuật xã hội, “con mắt” của bạn trong nhóm phát triển.
Giai đoạn thử nghiệm
nói rằng 20% nỗ lực sẽ tạo ra 80% kết quả. 20% này là các hoạt động phân tích ứng dụng có thể và nên được tự động hóa. Ví dụ về các hoạt động như vậy là phân tích tĩnh - SAST, phân tích động - DAST и Kiểm soát nguồn mở. Tôi sẽ cho bạn biết thêm về các hoạt động cũng như về các công cụ, những tính năng chúng ta thường gặp khi đưa chúng vào quy trình và cách thực hiện chính xác.
Các vấn đề chính của công cụ
Tôi sẽ nêu bật những vấn đề liên quan đến tất cả các công cụ và cần được chú ý. Tôi sẽ phân tích chúng chi tiết hơn để không lặp lại chúng thêm.
Thời gian phân tích dài. Nếu từ khi cam kết đến khi phát hành mất 30 phút cho tất cả các lần kiểm tra và lắp ráp thì việc kiểm tra bảo mật thông tin sẽ mất một ngày. Vì vậy, không ai sẽ làm chậm quá trình. Hãy tính đến tính năng này và rút ra kết luận.
Mức độ âm tính giả hoặc dương tính giả cao. Tất cả các sản phẩm đều khác nhau, tất cả đều sử dụng các framework khác nhau và phong cách mã hóa riêng. Trên các cơ sở mã và công nghệ khác nhau, các công cụ có thể hiển thị các mức Âm tính giả và Dương tính giả khác nhau. Vậy hãy nhìn xem chính xác có gì trong đó của bạn các công ty và cho của bạn các ứng dụng sẽ cho kết quả tốt và đáng tin cậy.
Không tích hợp với các công cụ hiện có. Xem xét các công cụ về mặt tích hợp với những gì bạn đã sử dụng. Ví dụ: nếu bạn có Jenkins hoặc TeamCity, hãy kiểm tra khả năng tích hợp của các công cụ với phần mềm này chứ không phải với GitLab CI mà bạn không sử dụng.
Thiếu hoặc quá phức tạp trong việc tùy chỉnh. Nếu một công cụ không có API thì tại sao lại cần nó? Mọi thứ có thể thực hiện trong giao diện đều phải có sẵn thông qua API. Lý tưởng nhất là công cụ này phải có khả năng tùy chỉnh việc kiểm tra.
Không có lộ trình phát triển sản phẩm. Sự phát triển không đứng yên, chúng tôi luôn sử dụng các framework và chức năng mới, viết lại mã cũ sang ngôn ngữ mới. Chúng tôi muốn chắc chắn rằng công cụ chúng tôi mua sẽ hỗ trợ các khuôn khổ và công nghệ mới. Vì vậy, điều quan trọng là phải biết rằng sản phẩm có thật và chính xác sự phát triển.
Tính năng xử lý
Ngoài các tính năng của công cụ, hãy tính đến các tính năng của quá trình phát triển. Ví dụ, cản trở sự phát triển là một sai lầm phổ biến. Hãy xem những tính năng nào khác cần được tính đến và nhóm bảo mật nên chú ý đến điều gì.
Để không bỏ lỡ thời hạn phát triển và phát hành, hãy tạo quy tắc khác nhau và khác nhau hiển thị nút chặn — tiêu chí để dừng quá trình xây dựng khi có lỗ hổng — cho các môi trường khác nhau. Ví dụ: chúng tôi hiểu rằng chi nhánh hiện tại sẽ chuyển sang vị trí phát triển hoặc UAT, điều đó có nghĩa là chúng tôi không dừng lại và nói:
“Ở đây bạn có những điểm yếu, bạn sẽ không đi đâu xa hơn nữa!”
Tại thời điểm này, điều quan trọng là phải nói với các nhà phát triển rằng có những vấn đề bảo mật cần được chú ý.
Sự hiện diện của các lỗ hổng không phải là trở ngại cho việc thử nghiệm thêm: thủ công, tích hợp hoặc thủ công. Mặt khác, chúng ta cần bằng cách nào đó tăng cường tính bảo mật của sản phẩm và để các nhà phát triển không bỏ qua những gì họ thấy an toàn. Do đó, đôi khi chúng tôi làm điều này: tại chỗ, khi nó được triển khai sang môi trường phát triển, chúng tôi chỉ cần thông báo về sự phát triển:
- Các bạn ơi, các bạn có vấn đề thì hãy chú ý nhé.
Ở giai đoạn UAT, chúng tôi lại hiển thị cảnh báo về các lỗ hổng và ở giai đoạn phát hành, chúng tôi nói:
- Các bạn, chúng tôi đã cảnh báo các bạn nhiều lần, các bạn không làm gì cả - chúng tôi sẽ không để các bạn ra ngoài với điều này.
Nếu chúng ta nói về mã và động lực, thì cần chỉ hiển thị và cảnh báo về các lỗ hổng của những tính năng và mã vừa được viết trong tính năng này. Nếu một nhà phát triển di chuyển một nút đi 3 pixel và chúng tôi nói với anh ta rằng anh ta đã chèn SQL vào đó và do đó cần phải sửa khẩn cấp thì điều này là sai. Chỉ nhìn vào những gì được viết bây giờ và những thay đổi trong ứng dụng.
Giả sử chúng tôi có một khiếm khuyết chức năng nhất định - cách ứng dụng không hoạt động: tiền không được chuyển, khi bạn nhấp vào nút thì không có chuyển sang trang tiếp theo hoặc sản phẩm không tải. Lỗi bảo mật - đây là những khiếm khuyết giống nhau, nhưng không phải về mặt vận hành ứng dụng mà là về mặt bảo mật.
Không phải tất cả các vấn đề về chất lượng phần mềm đều là vấn đề bảo mật. Nhưng mọi vấn đề về bảo mật đều liên quan đến chất lượng phần mềm. Sherif Mansour, Expedia.
Vì tất cả các lỗ hổng đều là những lỗi giống nhau nên chúng phải được đặt ở cùng một vị trí với tất cả các lỗi phát triển. Vì vậy, hãy quên đi những báo cáo và tệp PDF đáng sợ mà không ai đọc.
Khi tôi đang làm việc tại một công ty phát triển, tôi nhận được báo cáo từ các công cụ phân tích tĩnh. Tôi mở nó ra, kinh hãi, pha cà phê, lật qua 350 trang, đóng lại và tiếp tục làm việc. Báo cáo lớn là báo cáo chết. Thông thường chúng chẳng đi đến đâu, thư từ bị xóa, bị lãng quên, thất lạc hoặc doanh nghiệp cho biết họ chấp nhận rủi ro.
Phải làm gì? Chúng tôi chỉ đơn giản chuyển đổi các khiếm khuyết đã được xác nhận mà chúng tôi tìm thấy thành một dạng thuận tiện cho việc phát triển, chẳng hạn như chúng tôi đưa chúng vào danh sách tồn đọng trong Jira. Chúng tôi ưu tiên các lỗi và loại bỏ chúng theo thứ tự ưu tiên, cùng với các lỗi chức năng và lỗi kiểm tra.
Phân tích tĩnh - SAST
Đây là một phân tích mã cho các lỗ hổng., nhưng nó không giống với SonarQube. Chúng tôi không chỉ kiểm tra các mẫu hoặc phong cách. Một số phương pháp tiếp cận được sử dụng trong phân tích: theo cây dễ bị tổn thương, theo , bằng cách phân tích các tập tin cấu hình. Đây là tất cả những gì liên quan đến chính mã.
Ưu điểm của cách tiếp cận: xác định các lỗ hổng trong mã ở giai đoạn đầu phát triểnkhi chưa có giá đỡ hoặc dụng cụ làm sẵn, và khả năng quét tăng dần: quét một phần mã đã thay đổi và chỉ quét tính năng mà chúng tôi hiện đang thực hiện, giúp giảm thời gian quét.
Nhược điểm - đây là sự thiếu hỗ trợ cho các ngôn ngữ cần thiết.
Tích hợp cần thiết theo ý kiến chủ quan của tôi, những thứ nên có trong các công cụ:
- Công cụ tích hợp: Jenkins, TeamCity và Gitlab CI.
- Môi trường phát triển: Intellij IDEA, Visual Studio. Sẽ thuận tiện hơn cho nhà phát triển không phải điều hướng một giao diện khó hiểu vẫn cần phải ghi nhớ mà có thể xem tất cả các tích hợp và lỗ hổng cần thiết mà anh ta đã tìm thấy ngay tại nơi làm việc trong môi trường phát triển của chính mình.
- Đánh giá mã: SonarQube và đánh giá thủ công.
- Trình theo dõi lỗi: Jira và Bugzilla.
Hình ảnh cho thấy một số đại diện tốt nhất của phân tích tĩnh.
Điều quan trọng không phải là các công cụ mà là quy trình, vì vậy, có những giải pháp Nguồn mở cũng tốt để thử nghiệm quy trình.
Mã nguồn mở SAST sẽ không tìm thấy số lượng lớn lỗ hổng hoặc DataFlow phức tạp, nhưng chúng có thể và nên được sử dụng khi xây dựng một quy trình. Chúng giúp hiểu rõ quy trình sẽ được xây dựng như thế nào, ai sẽ phản hồi lỗi, ai sẽ báo cáo và ai sẽ báo cáo. Nếu bạn muốn thực hiện giai đoạn đầu trong việc xây dựng tính bảo mật cho mã của mình, hãy sử dụng các giải pháp Nguồn mở.
Làm thế nào điều này có thể được tích hợp nếu bạn đang ở giai đoạn đầu của hành trình và không có gì: không CI, không Jenkins, không TeamCity? Hãy xem xét việc tích hợp vào quá trình.
Tích hợp cấp độ CVS
Nếu bạn có Bitbucket hoặc GitLab, bạn có thể tích hợp ở cấp độ .
Theo sự kiện - kéo yêu cầu, cam kết. Bạn quét mã và trạng thái bản dựng sẽ hiển thị xem kiểm tra bảo mật đã đạt hay không thành công.
Phản hồi. Tất nhiên, phản hồi luôn luôn cần thiết. Nếu bạn chỉ làm bảo mật ở một bên, đặt nó vào một cái hộp và không nói cho ai biết bất cứ điều gì về nó, và sau đó vào cuối tháng, bạn đã phát hiện ra một loạt lỗi - điều này không đúng và không tốt.
Tích hợp với hệ thống đánh giá mã
Có lần, chúng tôi đóng vai trò là người đánh giá mặc định cho người dùng AppSec kỹ thuật trong một số dự án quan trọng. Tùy thuộc vào việc xác định được lỗi trong mã mới hay không có lỗi, người đánh giá sẽ đặt trạng thái trên yêu cầu kéo thành “chấp nhận” hoặc “cần cải thiện” - mọi thứ đều ổn hoặc các liên kết đến chính xác những gì cần được cải thiện cần phải được cải thiện. Để tích hợp với phiên bản đang được sản xuất, chúng tôi đã kích hoạt tính năng cấm hợp nhất nếu bài kiểm tra bảo mật thông tin không vượt qua. Chúng tôi đã đưa điều này vào quá trình xem xét mã thủ công và những người tham gia khác trong quy trình đã thấy các trạng thái bảo mật cho quy trình cụ thể này.
Tích hợp với SonarQube
Có nhiều về chất lượng mã. Ở đây cũng vậy - bạn chỉ có thể tạo các cổng tương tự cho các công cụ SAST. Sẽ có giao diện giống nhau, cổng chất lượng giống nhau, chỉ có điều nó sẽ được gọi cổng an ninh. Ngoài ra, nếu bạn có quy trình sử dụng SonarQube, bạn có thể dễ dàng tích hợp mọi thứ vào đó.
Tích hợp ở cấp độ CI
Mọi thứ ở đây cũng khá đơn giản:
- Ngang bằng với autotests, kiểm tra đơn vị.
- Phân chia theo giai đoạn phát triển: phát triển, kiểm tra, sản xuất. Có thể bao gồm các bộ quy tắc khác nhau hoặc các điều kiện hư hỏng khác nhau: dừng quá trình lắp ráp, không dừng quá trình lắp ráp.
- Khởi chạy đồng bộ/không đồng bộ. Chúng tôi đang chờ kết thúc kiểm tra bảo mật hay không. Nghĩa là, chúng tôi chỉ khởi chạy chúng và tiếp tục, sau đó chúng tôi nhận được trạng thái rằng mọi thứ đều tốt hoặc xấu.
Tất cả đều nằm trong một thế giới màu hồng hoàn hảo. Trong cuộc sống thực không có điều đó, nhưng chúng tôi cố gắng. Kết quả của việc chạy kiểm tra bảo mật phải tương tự với kết quả của kiểm tra đơn vị.
Ví dụ: chúng tôi đã thực hiện một dự án lớn và quyết định bây giờ chúng tôi sẽ quét nó bằng SAST - OK. Chúng tôi đã đẩy dự án này vào SAST, nó gây ra cho chúng tôi 20 lỗ hổng và bằng một quyết định mạnh mẽ, chúng tôi đã quyết định rằng mọi thứ đều ổn. 000 lỗ hổng là khoản nợ kỹ thuật của chúng tôi. Chúng tôi sẽ bỏ khoản nợ vào một chiếc hộp, chúng tôi sẽ từ từ giải quyết nó và thêm lỗi vào bộ theo dõi lỗi. Hãy thuê một công ty, tự mình làm mọi việc hoặc nhờ các nhà vô địch bảo mật giúp đỡ - và nợ kỹ thuật sẽ giảm.
Và tất cả các lỗ hổng mới xuất hiện trong mã mới phải được loại bỏ giống như các lỗi trong một đơn vị hoặc trong các cuộc kiểm tra tự động. Nói một cách tương đối, quá trình lắp ráp đã bắt đầu, chúng tôi đã chạy nó, hai bài kiểm tra và hai bài kiểm tra bảo mật đều thất bại. OK - chúng tôi đã đi, xem xét những gì đã xảy ra, sửa cái này, sửa cái khác, chạy nó vào lần tiếp theo - mọi thứ đều ổn, không có lỗ hổng mới nào xuất hiện, không có thử nghiệm nào thất bại. Nếu nhiệm vụ này sâu hơn và bạn cần hiểu rõ về nó hoặc việc sửa các lỗ hổng sẽ ảnh hưởng đến các lớp lớn của những gì ẩn giấu: một lỗi đã được thêm vào trình theo dõi lỗi, lỗi đó sẽ được ưu tiên và sửa chữa. Thật không may, thế giới không hoàn hảo và các thử nghiệm đôi khi thất bại.
Một ví dụ về cổng bảo mật là một ví dụ tương tự của cổng chất lượng, xét về sự hiện diện và số lượng lỗ hổng trong mã.
Chúng tôi tích hợp với SonarQube - plugin đã được cài đặt, mọi thứ đều rất tiện lợi và tuyệt vời.
Tích hợp với môi trường phát triển
Tùy chọn tích hợp:
- Chạy quét từ môi trường phát triển trước khi cam kết.
- Xem Kết quả.
- Phân tích kết quả.
- Đồng bộ hóa với máy chủ.
Đây là giao diện khi nhận kết quả từ máy chủ.
Trong môi trường phát triển của chúng tôi một mục bổ sung chỉ xuất hiện để thông báo cho bạn rằng các lỗ hổng như vậy đã được phát hiện trong quá trình quét. Bạn có thể chỉnh sửa mã ngay lập tức, xem các đề xuất và . Tất cả đều được đặt tại nơi làm việc của nhà phát triển, rất thuận tiện - không cần phải theo các liên kết khác và xem thêm thứ gì đó.
Mã nguồn mở
Đây là chủ đề yêu thích của tôi. Mọi người đều sử dụng thư viện Nguồn mở - tại sao phải viết một đống nạng và xe đạp khi bạn có thể lấy một thư viện làm sẵn trong đó mọi thứ đã được triển khai?
Tất nhiên, điều này là đúng, nhưng các thư viện cũng do con người viết ra, chúng cũng ẩn chứa những rủi ro nhất định và cũng có những lỗ hổng được báo cáo định kỳ hoặc liên tục. Do đó, có bước tiếp theo trong Bảo mật ứng dụng - đây là phân tích các thành phần Nguồn mở.
Phân tích nguồn mở - OSA
Công cụ này bao gồm ba giai đoạn lớn.
Tìm kiếm lỗ hổng trong thư viện. Ví dụ: công cụ này biết rằng chúng tôi đang sử dụng một số thư viện và trong đó hoặc có một số lỗ hổng trong trình theo dõi lỗi liên quan đến phiên bản thư viện này. Khi bạn cố gắng sử dụng nó, công cụ sẽ đưa ra cảnh báo rằng thư viện có lỗ hổng và khuyên bạn nên sử dụng phiên bản khác không có lỗ hổng.
Phân tích độ tinh khiết của giấy phép Điều này chưa đặc biệt phổ biến ở đây, nhưng nếu bạn làm việc ở nước ngoài, thì đôi khi bạn có thể bị đánh thuế ở đó vì sử dụng một thành phần nguồn mở không thể sử dụng hoặc sửa đổi. Theo chính sách của thư viện được cấp phép, chúng tôi không thể làm điều này. Hoặc, nếu chúng tôi sửa đổi và sử dụng nó, chúng tôi nên đăng mã của mình. Tất nhiên, không ai muốn công bố mã sản phẩm của mình, nhưng bạn cũng có thể tự bảo vệ mình khỏi điều này.
Phân tích các thành phần được sử dụng trong môi trường công nghiệp. Hãy tưởng tượng một tình huống giả định rằng cuối cùng chúng ta đã hoàn thành quá trình phát triển và phát hành bản phát hành microservice mới nhất của mình. Anh ấy sống ở đó thật tuyệt vời - một tuần, một tháng, một năm. Chúng tôi không thu thập nó, chúng tôi không tiến hành kiểm tra an toàn, mọi thứ dường như vẫn ổn. Nhưng đột nhiên, hai tuần sau khi phát hành, một lỗ hổng nghiêm trọng xuất hiện trong thành phần Nguồn mở mà chúng tôi sử dụng trong bản dựng cụ thể này, trong môi trường công nghiệp. Nếu chúng tôi không ghi lại những gì và nơi chúng tôi sử dụng thì chúng tôi sẽ không nhìn thấy lỗ hổng này. Một số công cụ có khả năng giám sát các lỗ hổng trong thư viện hiện đang được sử dụng trong ngành. Nó rất hữu ích.
Các tính năng:
- Chính sách khác nhau cho các giai đoạn phát triển khác nhau
- Giám sát các thành phần trong môi trường công nghiệp.
- Kiểm soát thư viện trong tổ chức
- Hỗ trợ cho các hệ thống xây dựng và ngôn ngữ khác nhau.
- Phân tích hình ảnh Docker.
Một vài ví dụ về các nhà lãnh đạo ngành đang tham gia phân tích Nguồn mở.
Cái miễn phí duy nhất là cái này từ OWASP. Bạn có thể bật nó trong giai đoạn đầu tiên, xem nó hoạt động như thế nào và nó hỗ trợ những gì. Về cơ bản, đây đều là những sản phẩm đám mây hoặc tại chỗ, nhưng đằng sau nền tảng của chúng, chúng vẫn được gửi tới Internet. Họ không gửi thư viện của bạn mà gửi các giá trị băm hoặc giá trị riêng của họ mà họ tính toán và gửi dấu vân tay đến máy chủ của họ để nhận thông tin về sự hiện diện của các lỗ hổng bảo mật.
Tích hợp quá trình
Kiểm soát chu vi của thư viện, được tải xuống từ các nguồn bên ngoài. Chúng tôi có kho lưu trữ bên ngoài và nội bộ. Ví dụ: Event Central chạy Nexus và chúng tôi muốn đảm bảo rằng không có lỗ hổng nào trong kho lưu trữ của chúng tôi có trạng thái "nghiêm trọng" hoặc "cao". Bạn có thể định cấu hình ủy quyền bằng công cụ Vòng đời tường lửa của Nexus để loại bỏ các lỗ hổng như vậy và không lưu lại trong kho lưu trữ nội bộ.
Tích hợp vào CI. Cùng cấp độ với autotests, unit test và chia thành các giai đoạn phát triển: dev, test, prod. Ở mỗi giai đoạn, bạn có thể tải xuống bất kỳ thư viện nào, sử dụng bất cứ thứ gì, nhưng nếu có điều gì đó khó khăn với trạng thái “nghiêm trọng”, có lẽ nên thu hút sự chú ý của các nhà phát triển về vấn đề này ở giai đoạn phát hành vào sản xuất.
Tích hợp với các tạo phẩm: Nexus và JFrog.
Tích hợp vào môi trường phát triển. Các công cụ bạn chọn phải tích hợp với môi trường phát triển. Nhà phát triển phải có quyền truy cập vào kết quả quét từ nơi làm việc của mình hoặc khả năng tự quét và kiểm tra mã để tìm lỗ hổng trước khi cam kết CVS.
Tích hợp đĩa CD. Đây là một tính năng thú vị mà tôi thực sự thích và tôi đã nói đến - theo dõi sự xuất hiện của các lỗ hổng mới trong môi trường công nghiệp. Nó hoạt động như thế này.
Chúng ta có Kho thành phần công cộng — một số công cụ bên ngoài và kho lưu trữ nội bộ của chúng tôi. Chúng tôi muốn nó chỉ chứa các thành phần đáng tin cậy. Khi ủy quyền một yêu cầu, chúng tôi kiểm tra xem thư viện đã tải xuống không có lỗ hổng. Nếu nó tuân theo các chính sách nhất định mà chúng tôi đặt ra và nhất thiết phải phối hợp với quá trình phát triển thì chúng tôi sẽ không tải nó lên và được nhắc sử dụng phiên bản khác. Theo đó, nếu có thứ gì đó thực sự quan trọng và không tốt trong thư viện, thì nhà phát triển sẽ không nhận được thư viện ở giai đoạn cài đặt - hãy để anh ta sử dụng phiên bản cao hơn hoặc thấp hơn.
- Khi xây dựng, chúng tôi kiểm tra xem không ai làm trượt bất cứ thứ gì xấu, tất cả các bộ phận đều an toàn và không ai mang bất cứ thứ gì nguy hiểm vào ổ flash.
- Chúng tôi chỉ có các thành phần đáng tin cậy trong kho lưu trữ.
- Khi triển khai, chúng tôi một lần nữa kiểm tra chính gói: war, jar, DL hoặc Docker image để đảm bảo rằng nó tuân thủ chính sách.
- Khi gia nhập ngành, chúng tôi theo dõi những gì đang xảy ra trong môi trường công nghiệp: các lỗ hổng nghiêm trọng xuất hiện hoặc không xuất hiện.
Phân tích động - DAST
Các công cụ phân tích động về cơ bản khác với mọi thứ đã được nói trước đây. Đây là một kiểu bắt chước công việc của người dùng với ứng dụng. Nếu đây là một ứng dụng web, chúng tôi gửi yêu cầu, mô phỏng công việc của khách hàng, nhấp vào các nút ở mặt trước, gửi dữ liệu nhân tạo từ biểu mẫu: dấu ngoặc kép, dấu ngoặc, ký tự ở các bảng mã khác nhau, để xem cách ứng dụng hoạt động và xử lý dữ liệu bên ngoài.
Hệ thống tương tự cho phép bạn kiểm tra các lỗ hổng mẫu trong Nguồn mở. Vì DAST không biết chúng tôi đang sử dụng Nguồn mở nào nên nó chỉ đưa ra các mẫu “độc hại” và phân tích phản hồi của máy chủ:
- Vâng, ở đây có vấn đề về khử lưu huỳnh, nhưng không phải ở đây.
Có những rủi ro lớn trong việc này, bởi vì nếu bạn tiến hành kiểm tra bảo mật này trên cùng một băng ghế mà những người kiểm tra làm việc cùng, những điều khó chịu có thể xảy ra.
- Tải cao trên mạng máy chủ ứng dụng.
- Không tích hợp.
- Khả năng thay đổi cài đặt của ứng dụng được phân tích.
- Không có sự hỗ trợ cho các công nghệ cần thiết.
- Khó khăn trong việc thiết lập.
Chúng tôi đã gặp một tình huống khi cuối cùng chúng tôi khởi chạy AppScan: chúng tôi đã mất một thời gian dài để cố gắng truy cập vào ứng dụng, có 3 tài khoản và rất vui - cuối cùng chúng tôi sẽ kiểm tra mọi thứ! Chúng tôi bắt đầu quét và điều đầu tiên AppScan làm là vào bảng quản trị, chọc vào tất cả các nút, thay đổi một nửa dữ liệu và sau đó tắt hoàn toàn máy chủ bằng lệnh đó. -yêu cầu. Phát triển với thử nghiệm cho biết:
- Các bạn, các bạn đang đùa tôi à?! Chúng tôi đã cấp cho bạn tài khoản và bạn đã thiết lập chỗ đứng!
Xem xét những rủi ro có thể xảy ra. Tốt nhất, hãy chuẩn bị một giá đỡ riêng để kiểm tra tính bảo mật thông tin, ít nhất bằng cách nào đó sẽ cách ly với phần còn lại của môi trường và kiểm tra có điều kiện bảng quản trị, tốt nhất là ở chế độ thủ công. Đây là mức pentest - phần trăm nỗ lực còn lại mà hiện tại chúng tôi chưa xem xét.
Điều đáng cân nhắc là bạn có thể sử dụng tính năng này như một cách tương tự để kiểm tra tải. Ở giai đoạn đầu tiên, bạn có thể bật máy quét động với 10-15 luồng và xem điều gì sẽ xảy ra, nhưng thông thường, như thực tế cho thấy, không có gì tốt cả.
Một số tài nguyên mà chúng tôi thường sử dụng.
Đáng làm nổi bật là “con dao Thụy Sĩ” dành cho bất kỳ chuyên gia bảo mật nào. Mọi người đều sử dụng nó và nó rất thuận tiện. Phiên bản demo mới của phiên bản doanh nghiệp hiện đã được phát hành. Nếu trước đây nó chỉ là một tiện ích độc lập với các plugin thì giờ đây, các nhà phát triển cuối cùng đã tạo ra một máy chủ lớn mà từ đó có thể quản lý một số tác nhân. Cái này hay đấy, tôi khuyên bạn nên thử nó.
Tích hợp quá trình
Việc tích hợp diễn ra khá tốt và đơn giản: bắt đầu quét sau khi cài đặt thành công ứng dụng cho giá đỡ và quét sau khi thử nghiệm tích hợp thành công.
Nếu tích hợp không hoạt động hoặc có các chức năng sơ khai và mô phỏng thì điều đó là vô nghĩa và vô dụng - cho dù chúng tôi gửi mẫu nào, máy chủ vẫn sẽ phản hồi theo cách tương tự.
- Lý tưởng nhất là có một bệ thử nghiệm riêng biệt.
- Trước khi kiểm tra, hãy viết ra trình tự đăng nhập.
- Việc kiểm tra hệ thống quản trị chỉ là thủ công.
quá trình
Khái quát một chút về quy trình nói chung và về công việc của từng công cụ nói riêng. Tất cả các ứng dụng đều khác nhau - một ứng dụng hoạt động tốt hơn với phân tích động, ứng dụng khác hoạt động tốt hơn với phân tích tĩnh, ứng dụng thứ ba với phân tích OpenSource, pentest hoặc ứng dụng nào đó hoàn toàn khác, chẳng hạn như các sự kiện với .
Mọi quá trình đều cần được kiểm soát.
Để hiểu cách một quy trình hoạt động và nơi nó có thể được cải thiện, bạn cần thu thập số liệu từ mọi thứ bạn có thể có trong tay, bao gồm số liệu sản xuất, số liệu từ công cụ và từ trình theo dõi lỗi.
Mọi thông tin đều hữu ích. Cần phải nhìn từ các góc độ khác nhau xem công cụ này hay công cụ kia được sử dụng tốt hơn ở đâu, nơi quy trình cụ thể bị chùng xuống. Có thể đáng để xem xét thời gian phản hồi của quá trình phát triển để biết nơi cần cải thiện quy trình dựa trên thời gian. Càng nhiều dữ liệu, càng có thể xây dựng nhiều phần từ cấp cao nhất đến chi tiết của từng quy trình.
Vì tất cả các máy phân tích tĩnh và động đều có API riêng, phương pháp khởi chạy, nguyên tắc riêng, một số có bộ lập lịch, số khác thì không - chúng tôi đang viết một công cụ Người điều phối AppSec, cho phép bạn tạo một điểm truy cập duy nhất vào toàn bộ quy trình từ sản phẩm và quản lý nó từ một điểm.
Người quản lý, nhà phát triển và kỹ sư bảo mật có một điểm truy cập mà từ đó họ có thể xem những gì đang chạy, định cấu hình và chạy quét, nhận kết quả quét và gửi yêu cầu. Chúng tôi đang cố gắng thoát khỏi thủ tục giấy tờ, chuyển mọi thứ thành tài liệu của con người, được sử dụng trong quá trình phát triển - các trang trên Confluence với trạng thái và số liệu, lỗi trong Jira hoặc trong các trình theo dõi lỗi khác nhau hoặc tích hợp vào quy trình đồng bộ/không đồng bộ trong CI /ĐĨA CD.
Chìa khóa chính
Công cụ không phải là điều chính. Đầu tiên hãy suy nghĩ thấu đáo về quy trình - sau đó triển khai các công cụ. Các công cụ này tốt nhưng đắt tiền, vì vậy bạn có thể bắt đầu với quy trình và xây dựng sự giao tiếp cũng như hiểu biết giữa bộ phận phát triển và bảo mật. Từ quan điểm an toàn, không cần thiết phải “dừng” mọi thứ. Từ quan điểm phát triển, nếu có điều gì đó cao siêu tới hạn thì cần phải loại bỏ, không được làm ngơ trước vấn đề.
Chất lượng sản phẩm - mục đich chung vừa an ninh vừa phát triển. Chúng tôi làm một việc, chúng tôi cố gắng đảm bảo rằng mọi thứ hoạt động chính xác và không có rủi ro về danh tiếng hoặc tổn thất tài chính. Đây là lý do tại sao chúng tôi thúc đẩy cách tiếp cận DevSecOps, SecDevOps để cải thiện khả năng giao tiếp và nâng cao chất lượng sản phẩm.
Hãy bắt đầu với những gì bạn đã có: yêu cầu, kiến trúc, kiểm tra từng phần, đào tạo, hướng dẫn. Không cần phải áp dụng ngay tất cả các phương pháp thực hành cho tất cả các dự án - di chuyển lặp đi lặp lại. Không có tiêu chuẩn duy nhất - cuộc thí nghiệm và thử các cách tiếp cận và giải pháp khác nhau.
Có dấu bằng nhau giữa lỗi bảo mật thông tin và lỗi chức năng.
Tự động hóa mọi thứcái đó di chuyển. Bất cứ thứ gì không di chuyển, hãy di chuyển nó và tự động hóa nó. Nếu việc gì đó được thực hiện bằng tay thì đó không phải là một phần tốt của quy trình. Có lẽ nó đáng để xem xét và tự động hóa nó.
Nếu quy mô của nhóm IS nhỏ - sử dụng Nhà vô địch bảo mật.
Có lẽ những gì tôi đã nói sẽ không phù hợp với bạn và bạn sẽ nghĩ ra thứ gì đó của riêng mình - và điều đó tốt. Nhưng chọn công cụ dựa trên yêu cầu cho quy trình của bạn. Đừng nhìn vào những gì cộng đồng nói rằng công cụ này tệ và công cụ này tốt. Có lẽ điều ngược lại sẽ đúng với sản phẩm của bạn.
Yêu cầu về dụng cụ.
- Mức độ thấp Sai tích cực.
- Thời gian phân tích phù hợp.
- Dễ sử dụng.
- Sự sẵn có của tích hợp.
- Hiểu rõ lộ trình phát triển sản phẩm.
- Khả năng tùy biến các công cụ.
Báo cáo của Yuri đã được chọn là một trong những báo cáo hay nhất tại DevOpsConf 2018. Để làm quen với những ý tưởng và trường hợp thực tế thú vị hơn nữa, hãy đến Skolkovo vào ngày 27 và 28 tháng XNUMX ở trong . Tốt hơn nữa, nếu bạn sẵn sàng chia sẻ kinh nghiệm của mình, thì để báo cáo cho đến ngày 21 tháng XNUMX.
Nguồn: www.habr.com