DevSecOps에 대한 두려움과 혐오

우리는 2개의 코드 분석기, 4개의 동적 테스트 도구, 자체 기술 및 250개의 스크립트를 보유했습니다. 현재 프로세스에서 이 모든 것이 필요한 것은 아니지만 일단 DevSecOps 구현을 시작하면 끝까지 가야 합니다.

출처. 캐릭터 제작자: Justin Roiland 및 Dan Harmon.

SecDevOps란 무엇입니까? DevSecOps는 어떻습니까? 차이점은 무엇입니까? 애플리케이션 보안 - 무엇에 관한 것인가요? 왜 고전적인 접근 방식이 더 이상 작동하지 않습니까? 이 모든 질문에 대한 답을 알고 있습니다 유리 샤 발린 으로 황새치 보안. Yuri는 모든 것에 대해 자세히 답변하고 기존 애플리케이션 보안 모델에서 DevSecOps 프로세스로 전환하는 데 따른 문제를 분석합니다. 보안 개발 프로세스를 DevOps 프로세스에 통합하는 데 올바르게 접근하는 방법과 아무것도 중단하지 않는 방법, 주요 단계를 통과하는 방법 보안 테스트에 대해, 어떤 도구를 사용할 수 있는지, 차이점은 무엇인지, 함정을 피하기 위해 올바르게 구성하는 방법을 설명합니다.

스피커 소개: 유리 샤발린 - 회사의 수석 보안 설계자 황새치 보안. 애플리케이션 분석 도구를 통합 개발 및 테스트 생태계로 전반적으로 통합하기 위해 SSDL 구현을 담당합니다. 정보보안 분야 경력 7년입니다. 소프트웨어를 개발하고 서비스를 제공하는 Alfa-Bank, Sberbank 및 Positive Technologies에서 근무했습니다. 국제 컨퍼런스 ZerONights, PHDays, RISSPA, OWASP의 연사입니다.

애플리케이션 보안: 무엇에 관한 것인가요?

응용 프로그램 보안 - 애플리케이션 보안을 담당하는 보안 부서입니다. 이는 인프라나 네트워크 보안에 적용되는 것이 아니라 우리가 작성하는 내용과 개발자가 작업하는 내용에 적용됩니다. 이는 애플리케이션 자체의 단점과 취약성입니다.

방향 SDL 또는 SDLC - 보안 개발 수명주기 - 마이크로소프트에서 개발했습니다. 다이어그램은 요구 사항부터 릴리스 및 생산에 이르기까지 모든 개발 단계에서 보안이 참여하는 주요 작업인 표준 SDLC 모델을 보여줍니다. Microsoft는 업계에 버그가 너무 많고 버그가 더 많아 이에 대해 조치를 취해야 한다는 사실을 깨닫고 이 접근 방식을 제안했으며 이는 표준이 되었습니다.

애플리케이션 보안과 SSDL은 일반적으로 알려진 것처럼 취약점을 탐지하는 것이 아니라 취약점 발생을 예방하는 것을 목표로 합니다. 시간이 지남에 따라 Microsoft의 표준 접근 방식은 개선, 개발 및 더 깊고 자세한 내용으로 도입되었습니다.

표준 SDLC는 OpenSAMM, BSIMM, OWASP 등 다양한 방법론에서 매우 상세합니다. 방법론은 다르지만 일반적으로 유사합니다.

성숙도 모델의 보안 구축

나는 그것을 가장 좋아한다 BSIMM - 성숙도 모델의 보안 구축. 방법론의 기본은 애플리케이션 보안 프로세스를 거버넌스, 인텔리전스, SSDL 터치포인트 및 배포의 4개 영역으로 나누는 것입니다. 각 영역에는 12개의 관행이 있으며 이는 112개의 활동으로 표시됩니다.

112개의 활동 각각에는 3단계 성숙도: 초급, 중급, 고급. 12가지 사례를 섹션별로 모두 연구하고, 중요한 사항을 선택하고, 이를 구현하는 방법을 파악하고, 정적 및 동적 코드 분석이나 코드 검토와 같은 요소를 점진적으로 추가할 수 있습니다. 선택한 활동 실행의 일환으로 계획을 작성하고 그에 따라 침착하게 작업합니다.

DevSecOps를 사용해야 하는 이유

DevOps는 보안을 고려해야 하는 일반적이고 대규모 프로세스입니다.

처음에는 개발자 보안 점검이 포함됩니다. 실제로 보안팀의 수는 지금보다 훨씬 적었고, 프로세스에 참여하는 역할을 하는 것이 아니라, 요구 사항을 부과하고 릴리스가 끝날 때 제품의 품질을 확인하는 통제 및 감독 기관의 역할을 했습니다. 이는 보안 팀이 개발 과정에서 배후에 있었고 프로세스에 참여하지 않은 전형적인 접근 방식입니다.

가장 큰 문제는 정보 보안이 개발과 별개라는 것입니다. 일반적으로 이것은 일종의 정보 보안 회로이며 2-3개의 크고 값비싼 도구를 포함합니다. XNUMX개월에 한 번씩 점검이 필요한 소스코드나 애플리케이션이 도착하고, XNUMX년에 한 번씩 제작된다. 침투 테스트. 이 모든 것이 업계의 출시 날짜가 지연되고 개발자가 자동화된 도구로 인해 수많은 취약점에 노출된다는 사실로 이어집니다. 지난 XNUMX개월 동안의 결과가 정리되지 않았기 때문에 이 모든 것을 분해하고 수리하는 것은 불가능하지만 여기에 새로운 배치가 있습니다.

우리 회사의 업무 과정에서 우리는 모든 영역과 산업의 보안이 이제 같은 바퀴에서 개발을 따라잡고 회전해야 할 때라는 것을 이해하고 있음을 확인합니다. 기민한. DevSecOps 패러다임은 모든 릴리스 및 반복에 대한 민첩한 개발 방법론, 구현, 지원 및 참여와 완벽하게 들어맞습니다.

DevSecOps로 전환

보안 개발 라이프사이클에서 가장 중요한 단어는 "프로세스". 도구 구입을 생각하기 전에 이 점을 이해해야 합니다.

단순히 DevOps 프로세스에 도구를 통합하는 것만으로는 충분하지 않습니다. 프로세스 참여자 간의 의사소통과 이해가 중요합니다.

도구가 아니라 사람이 더 중요합니다.

보안 개발 프로세스에 대한 계획은 도구 선택 및 구매로 시작하여 도구를 현재 프로세스에 통합하려는 시도로 끝나는 경우가 많으며 이러한 시도는 여전히 남아 있습니다. 모든 도구에는 고유한 특성과 한계가 있기 때문에 이로 인해 불행한 결과가 발생합니다.

일반적인 경우는 보안 부서가 광범위한 기능을 갖춘 훌륭하고 값비싼 도구를 선택하고 이를 프로세스에 통합하기 위해 개발자에게 온 경우입니다. 그러나 그것은 효과가 없습니다. 이미 구매한 도구의 한계가 현재 패러다임에 맞지 않는 방식으로 프로세스가 구성되어 있습니다.

먼저, 원하는 결과와 프로세스가 어떤 모습일지 설명하세요. 이는 프로세스에서 도구와 안전의 역할을 이해하는 데 도움이 됩니다.

이미 사용 중인 것부터 시작하세요.

값비싼 도구를 구입하기 전에 이미 가지고 있는 도구를 살펴보십시오. 모든 회사에는 개발을 위한 보안 요구 사항이 있고, 점검과 침투 테스트가 있습니다. 이 모든 것을 모두가 이해할 수 있고 편리한 형식으로 변환하는 것은 어떨까요?

일반적으로 요구 사항은 선반에 놓인 종이 탈무드입니다. 회사를 방문하여 프로세스를 살펴보고 소프트웨어에 대한 보안 요구 사항을 요청한 경우가 있었습니다. 이 문제를 다룬 전문가는 다음을 찾는 데 오랜 시간을 보냈습니다.

- 자, 노트 어딘가에 이 문서가 놓여 있는 경로가 있었습니다.

그 결과 우리는 일주일 후에 문서를 받았습니다.

요구 사항, 확인 사항 및 기타 사항에 대해서는 예를 들어 페이지를 만드십시오. 합류 - 누구에게나 편리해요.

이미 가지고 있는 것을 다시 포맷하고 이를 사용하여 시작하는 것이 더 쉽습니다.

보안 챔피언 사용

일반적으로 개발자가 100~200명인 일반 회사에는 여러 기능을 수행하는 보안 전문가가 한 명 있지만 물리적으로 모든 것을 확인할 시간은 없습니다. 아무리 최선을 다해도 그 혼자서는 개발이 생성하는 모든 코드를 확인하지 못할 것입니다. 이러한 경우를 위해 다음과 같은 개념이 개발되었습니다. 보안 챔피언.

보안 챔피언은 제품 보안에 관심이 있는 개발 팀 내의 사람들입니다.

Security Champion은 개발팀의 진입점이자 보안 전도사입니다.

일반적으로 보안 전문가가 개발팀을 방문하여 코드의 오류를 지적하면 다음과 같은 놀라운 대답을 듣습니다.

- 당신은 누구죠? 처음 뵙네요. 저는 모든 것이 괜찮습니다. 제 선배 친구가 저에게 코드 리뷰에 "지원"을 줬고, 계속 진행하겠습니다!

이는 개발자가 직장과 코드 검토에서 지속적으로 상호 작용하는 선배나 팀원에 대한 신뢰가 훨씬 더 높기 때문에 일반적인 상황입니다. 보안 담당자 대신 보안 챔피언이 실수와 결과를 지적한다면 그의 말이 더 큰 비중을 차지할 것입니다.

또한 개발자는 보안 전문가보다 자신의 코드를 더 잘 알고 있습니다. 정적 분석 도구에 최소 5개 이상의 프로젝트가 있는 사람의 경우 일반적으로 모든 뉘앙스를 기억하기 어렵습니다. 보안 챔피언은 자신의 제품을 알고 있습니다. 즉, 무엇이 무엇과 상호 작용하는지, 무엇을 먼저 보아야 하는지, 즉 제품이 더 효과적이라는 것을 알고 있습니다.

따라서 보안 챔피언을 구현하고 보안 팀의 영향력을 확대하는 것을 고려해 보십시오. 이는 챔피언 자신에게도 유용합니다. 새로운 분야의 전문성 개발, 기술적 지평 확장, 기술, 관리 및 리더십 기술 업그레이드, 시장 가치 증대 등이 있습니다. 이는 개발 팀의 "눈"인 사회 공학의 일부 요소입니다.

테스트 단계

패러다임 20~80 20%의 노력이 80%의 결과를 가져온다고 합니다. 이 20%는 자동화할 수 있고 자동화해야 하는 애플리케이션 분석 관행입니다. 그러한 활동의 ​​예로는 정적 분석이 있습니다. SAST, 동적 분석 - DAST и 오픈 소스 제어. 활동과 도구, 프로세스에 도입할 때 일반적으로 접하게 되는 기능 및 올바르게 수행하는 방법에 대해 자세히 설명하겠습니다.

도구의 주요 문제점

모든 기기와 관련이 있고 주의가 필요한 문제를 강조하겠습니다. 더 이상 반복하지 않도록 더 자세히 분석하겠습니다.

분석 시간이 깁니다. 커밋부터 릴리스까지 모든 테스트와 조립에 30분이 소요된다면 정보 보안 점검에는 하루가 소요됩니다. 따라서 아무도 프로세스 속도를 늦추지 않을 것입니다. 이 기능을 고려하고 결론을 도출하십시오.

높은 수준의 거짓 부정 또는 거짓 긍정. 모든 제품은 서로 다르며 모두 서로 다른 프레임워크와 고유한 코딩 스타일을 사용합니다. 다양한 코드베이스 및 기술에서 도구는 다양한 수준의 거짓 부정 및 거짓 긍정을 표시할 수 있습니다. 그럼 정확히 무엇이 들어 있는지 살펴보세요 당신의 회사와 당신의 응용 프로그램은 좋고 신뢰할 수 있는 결과를 보여줍니다.

기존 도구와 통합되지 않음. 이미 사용하고 있는 도구와의 통합 측면에서 도구를 살펴보세요. 예를 들어 Jenkins 또는 TeamCity가 있는 경우 사용하지 않는 GitLab CI가 아닌 이 소프트웨어와의 도구 통합을 확인하세요.

사용자 정의의 복잡성이 부족하거나 과도합니다. 도구에 API가 없다면 API가 필요한 이유는 무엇입니까? 인터페이스에서 수행할 수 있는 모든 작업은 API를 통해 수행할 수 있어야 합니다. 이상적으로는 도구에 검사를 사용자 정의할 수 있는 기능이 있어야 합니다.

제품 개발 로드맵이 없습니다. 개발은 멈추지 않고 항상 새로운 프레임워크와 기능을 사용하고 오래된 코드를 새로운 언어로 다시 작성합니다. 우리는 우리가 구매하는 도구가 새로운 프레임워크와 기술을 지원하는지 확인하고 싶습니다. 따라서 제품이 실제적이고 정확한지 아는 것이 중요합니다. 로드맵 개발.

프로세스 기능

도구의 기능 외에도 개발 프로세스의 기능도 고려하세요. 예를 들어, 개발을 방해하는 것은 흔한 실수입니다. 그 밖에 어떤 기능을 고려해야 하는지, 보안팀이 주의해야 할 사항은 무엇인지 살펴보겠습니다.

개발 및 출시 기한을 놓치지 않으려면 다른 규칙 그리고 다른 쇼 스토퍼 — 취약점이 있는 경우 빌드 프로세스를 중지하기 위한 기준 — 다양한 환경에 대한. 예를 들어, 현재 분기가 개발 스탠드 또는 UAT로 이동한다는 것을 이해합니다. 즉, 멈추지 않고 다음과 같이 말합니다.

"여기에 취약점이 있습니다. 더 이상 갈 수 없습니다!"

이 시점에서는 주의가 필요한 보안 문제가 있음을 개발자에게 알리는 것이 중요합니다.

취약점의 존재는 추가 테스트에 장애가 되지 않습니다.: 수동, 통합 또는 수동. 반면에 우리는 어떻게든 제품의 보안을 강화하여 개발자가 안전하다고 생각하는 것을 무시하지 않도록 해야 합니다. 따라서 때로는 다음과 같이 수행합니다. 스탠드에서 개발 환경으로 롤아웃할 때 개발팀에 간단히 알립니다.

- 여러분, 문제가 있으니 주의하세요.

UAT 단계에서는 취약점에 대한 경고를 다시 표시하고 릴리스 단계에서는 다음과 같이 말합니다.

- 여러분, 우리는 여러분이 아무것도 하지 않았다고 여러 번 경고했습니다.

코드와 역학에 대해 이야기한다면 이 기능에 방금 작성된 기능과 코드의 취약점만 표시하고 경고해야 합니다. 개발자가 버튼을 3픽셀 이동했는데 거기에 SQL 삽입이 있어서 긴급하게 수정해야 한다고 말하면 이는 잘못된 것입니다. 지금 작성된 내용과 신청서에 적용되는 변경 사항만 살펴보세요.

애플리케이션이 작동하지 않아야 하는 특정 기능적 결함이 있다고 가정해 보겠습니다. 돈이 이체되지 않거나 버튼을 클릭해도 다음 페이지로 전환되지 않거나 제품이 로드되지 않습니다. 보안 결함 - 동일한 결함이지만 애플리케이션 운영 측면이 아니라 보안 측면에서 그렇습니다.

모든 소프트웨어 품질 문제가 보안 ​​문제인 것은 아닙니다. 그러나 모든 보안 문제는 소프트웨어 품질과 관련이 있습니다. 셰리프 만수르(Expedia)

모든 취약점은 동일한 결함이므로 모든 개발 결함과 동일한 위치에 위치해야 합니다. 그러니 아무도 읽지 않는 보고서와 무서운 PDF는 잊어버리세요.

개발회사에 근무할 때 정적분석 도구로부터 보고서를 받았습니다. 나는 그것을 열고, 겁에 질려, 커피를 만들고, 350페이지를 훑어본 다음, 닫고 계속 작업했습니다. 큰 보고서는 죽은 보고서다. 일반적으로 아무데도 가지 않고, 편지가 삭제되거나 잊혀지거나 분실되거나 회사에서 위험을 감수한다고 말합니다.

무엇을 해야 할까요? 발견한 확인된 결함을 개발에 편리한 형태로 간단히 변환합니다. 예를 들어 Jira의 백로그에 넣습니다. 결함을 우선적으로 처리하여 기능적 결함, 테스트 결함과 함께 우선순위에 따라 제거합니다.

정적 분석 - SAST

취약점에 대한 코드 분석입니다., 하지만 SonarQube와는 다릅니다. 우리는 패턴이나 스타일만 확인하지 않습니다. 분석에는 취약점 트리에 따라 다음과 같은 다양한 접근 방식이 사용됩니다. 데이터 흐름, 구성 파일을 분석하여. 이것이 코드 자체와 관련된 전부입니다.

접근 방식의 장점: 개발 초기 단계에서 코드의 취약점을 식별합니다.아직 스탠드나 기성 도구가 없는 경우 증분 스캔 기능: 변경된 코드 섹션과 현재 수행 중인 기능만 스캔하므로 스캔 시간이 줄어듭니다.

죄수 팀은 - 필요한 언어에 대한 지원이 부족합니다.

필요한 통합, 내 주관적인 의견으로는 도구에 있어야 합니다.

• 통합 도구: Jenkins, TeamCity 및 Gitlab CI.
• 개발 환경: Intellij IDEA, Visual Studio. 개발자에게는 아직 기억해야 할 이해하기 어려운 인터페이스를 탐색하는 것이 아니라 직장에서 발견한 필요한 모든 통합과 취약점을 자신의 개발 환경에서 바로 확인하는 것이 더 편리합니다.
• 코드 검토: SonarQube 및 수동 검토.
• 결함 추적기: Jira 및 Bugzilla.

그림은 정적 분석의 가장 대표적인 예를 보여줍니다.

중요한 것은 도구가 아니라 프로세스이므로 프로세스를 테스트하는 데에도 좋은 오픈 소스 솔루션이 있습니다.

SAST 오픈 소스는 엄청난 수의 취약점이나 복잡한 데이터 흐름을 찾아내지는 못하지만 프로세스를 구축할 때 사용할 수 있고 사용해야 합니다. 프로세스가 어떻게 구축되는지, 버그에 대응할 사람, 보고할 사람, 보고할 사람을 이해하는 데 도움이 됩니다. 코드 보안 구축의 초기 단계를 수행하려면 오픈 소스 솔루션을 사용하십시오.

여정의 시작 단계에 CI, Jenkins, TeamCity 등 아무것도 없다면 어떻게 이를 통합할 수 있습니까? 프로세스에 통합하는 것을 고려해 봅시다.

CVS 레벨 통합

Bitbucket이나 GitLab이 있다면 해당 레벨에서 통합이 가능합니다. 동시 버전 시스템.

이벤트별 - 풀 요청, 커밋. 코드를 스캔하면 빌드 상태에 보안 검사 통과 또는 실패 여부가 표시됩니다.

피드백. 물론 피드백은 항상 필요합니다. 방금 보안 작업을 수행하고 상자에 넣고 아무에게도 말하지 않은 다음 월말에 많은 버그를 버렸다면 이는 정확하지도 좋지도 않습니다.

코드 리뷰 시스템과 통합

한때 우리는 여러 중요한 프로젝트에서 기술 AppSec 사용자의 기본 검토자 역할을 했습니다. 새 코드에서 오류가 식별되었는지 또는 오류가 없는지에 따라 검토자는 풀 요청의 상태를 "수락" 또는 "작업 필요"로 설정합니다. 즉, 모든 것이 정상이거나 정확히 개선이 필요한 링크에 대한 링크입니다. 개선될 필요가 있습니다. 프로덕션에 들어가는 버전과의 통합을 위해 정보 보안 테스트를 통과하지 못한 경우 병합 금지를 활성화했습니다. 우리는 이를 수동 코드 검토에 포함시켰고 프로세스의 다른 참가자들은 이 특정 프로세스의 보안 상태를 확인했습니다.

SonarQube와의 통합

많은 사람들이 품질 게이트 코드 품질 측면에서. 여기서도 마찬가지입니다. SAST 도구에 대해서만 동일한 게이트를 만들 수 있습니다. 동일한 인터페이스, 동일한 품질 게이트가 있으며, 그것만 호출됩니다. 보안 게이트. 또한 SonarQube를 사용하는 프로세스가 있으면 거기에 있는 모든 것을 쉽게 통합할 수 있습니다.

CI 수준의 통합

여기의 모든 것도 매우 간단합니다.

• 자동 테스트와 동등, 단위 테스트.
• 개발단계별 구분: 개발, 테스트, 프로덕션. 다양한 규칙 세트 또는 다양한 실패 조건이 포함될 수 있습니다. 조립을 중지하고 조립을 중지하지 마십시오.
• 동기/비동기 실행. 우리는 보안 테스트가 끝날지 말지를 기다리고 있습니다. 즉, 방금 시작하고 계속 진행하면 모든 것이 좋거나 나쁘다는 상태를 얻습니다.

모든 것이 완벽한 핑크색 세상에 있습니다. 실생활에는 그런 것이 없지만 우리는 노력합니다. 보안 검사 실행 결과는 단위 테스트 결과와 유사해야 합니다.

예를 들어, 우리는 대규모 프로젝트를 수행하고 이제 SAST로 스캔하기로 결정했습니다. 우리는 이 프로젝트를 SAST로 밀어붙였고, 이로 인해 20개의 취약점이 생겼고, 확고한 의지로 모든 것이 괜찮다고 결정했습니다. 000개의 취약점은 우리의 기술적 부채입니다. 우리는 부채를 상자에 넣고 천천히 정리하고 결함 추적기에 버그를 추가할 것입니다. 회사를 고용하거나, 모든 것을 스스로 처리하거나, 보안 챔피언의 도움을 받도록 하세요. 그러면 기술 부채가 줄어들 것입니다.

그리고 새 코드에서 새로 나타나는 모든 취약점은 단위 또는 자동 테스트의 오류와 동일한 방식으로 제거되어야 합니다. 상대적으로 말하면 어셈블리가 시작되고 실행되었으며 두 가지 테스트와 두 가지 보안 테스트가 실패했습니다. 좋습니다. 무슨 일이 일어났는지 살펴보고, 한 가지를 수정하고, 다른 것을 수정하고, 다음에 실행했습니다. 모든 것이 괜찮았고, 새로운 취약점도 나타나지 않았으며, 테스트도 실패하지 않았습니다. 이 작업이 더 깊고 잘 이해해야 하는 경우 또는 취약점 수정이 내부의 큰 계층에 영향을 미치는 경우: 결함 추적기에 버그가 추가되면 우선 순위가 지정되고 수정됩니다. 불행히도 세상은 완벽하지 않으며 테스트가 실패하는 경우도 있습니다.

보안 게이트의 예는 코드의 취약점 존재 여부와 수 측면에서 품질 게이트와 유사합니다.

SonarQube와 통합됩니다. 플러그인이 설치되어 있어 모든 것이 매우 편리하고 멋집니다.

개발 환경과의 통합

통합 옵션:

• 커밋하기 전에 개발 환경에서 스캔을 실행합니다.
• 결과를 봅니다.
• 결과 분석.
• 서버와의 동기화.

서버로부터 결과를 받는 모습은 다음과 같습니다.

우리 개발 환경에서는 인텔리즈 아이디어 스캔 중에 해당 취약점이 감지되었음을 알리는 추가 항목이 나타납니다. 즉시 코드를 편집하고 권장 사항을 확인하고 흐름 그래프. 이것은 모두 개발자의 작업장에 있으므로 매우 편리합니다. 다른 링크를 따라가거나 추가 내용을 볼 필요가 없습니다.

오픈 소스

이것은 내가 가장 좋아하는 주제입니다. 모두가 오픈 소스 라이브러리를 사용합니다. 모든 것이 이미 구현되어 있는 기성 라이브러리를 사용할 수 있는데 왜 목발과 자전거를 많이 작성합니까?

물론 이는 사실이지만 라이브러리도 사람이 작성하므로 특정 위험도 포함되어 있으며 정기적으로 또는 지속적으로 보고되는 취약점도 있습니다. 따라서 애플리케이션 보안의 다음 단계는 오픈 소스 구성 요소 분석입니다.

오픈 소스 분석 - OSA

이 도구에는 세 가지 큰 단계가 포함되어 있습니다.

라이브러리의 취약점을 검색합니다. 예를 들어, 도구는 우리가 일부 라이브러리를 사용하고 있다는 것을 알고 있으며 CVE 또는 이 버전의 라이브러리와 관련된 버그 추적기에 몇 가지 취약점이 있습니다. 이를 사용하려고 하면 도구는 라이브러리가 취약하다는 경고를 표시하고 취약성이 없는 다른 버전을 사용하도록 조언합니다.

라이센스 순도 분석. 이곳에서는 아직 특별히 인기가 없지만, 해외에서 일하는 경우 때때로 사용하거나 수정할 수 없는 오픈 소스 구성 요소를 사용하는 데 대해 세금을 받을 수 있습니다. 허가받은 도서관의 정책에 따라, 저희는 이를 할 수 없습니다. 아니면 수정하여 사용한다면 코드를 게시해야 합니다. 물론 누구도 자신의 제품 코드를 공개하고 싶어하지 않지만, 이로부터 자신을 보호할 수도 있습니다.

산업 환경에서 사용되는 구성 요소를 분석합니다. 우리가 마침내 개발을 완료하고 마이크로서비스의 최신 릴리스를 출시했다는 가상의 상황을 상상해 봅시다. 그는 그곳에서 일주일, 한 달, 일 년 동안 훌륭하게 살고 있습니다. 우리는 그것을 수집하지도 않고 안전 점검도 실시하지 않으며 모든 것이 괜찮은 것 같습니다. 그러나 출시 XNUMX주 후 갑자기 산업 환경에서 이 특정 빌드에서 사용하는 오픈 소스 구성 요소에 심각한 취약점이 나타납니다. 무엇을 어디서 사용하는지 기록하지 않으면 이 취약점을 볼 수 없습니다. 일부 도구에는 현재 업계에서 사용되는 라이브러리의 취약점을 모니터링하는 기능이 있습니다. 매우 유용합니다.

특징 :

• 다양한 개발 단계에 대한 다양한 정책.
• 산업 환경에서 구성 요소를 모니터링합니다.
• 조직 내 도서관 통제.
• 다양한 빌드 시스템 및 언어를 지원합니다.
• Docker 이미지 분석.

오픈 소스 분석에 참여하는 업계 리더의 몇 가지 예입니다.

무료는 이것뿐이네요 종속성 검사 OWASP에서. 첫 번째 단계에서 이 기능을 켜고 작동 방식과 지원 사항을 확인할 수 있습니다. 기본적으로 이들은 모두 클라우드 제품이거나 온프레미스이지만 기반 뒤에서는 여전히 인터넷으로 전송됩니다. 이들은 귀하의 라이브러리가 아닌 자신이 계산한 해시 또는 자체 값과 지문을 서버에 보내 취약점 존재에 대한 정보를 받습니다.

프로세스 통합

도서관의 경계 통제, 외부 소스에서 다운로드됩니다. 우리는 외부 저장소와 내부 저장소를 가지고 있습니다. 예를 들어 Event Central은 Nexus를 실행하며 저장소 내에 "중요" 또는 "높음" 상태의 취약점이 없는지 확인하려고 합니다. Nexus 방화벽 수명 주기 도구를 사용하여 프록시를 구성하면 이러한 취약점이 차단되어 내부 저장소에 들어가지 않도록 할 수 있습니다.

CI로 통합. 자동 테스트, 단위 테스트 및 개발 단계(개발, 테스트, 프로덕션)로 나누는 것과 동일한 수준입니다. 각 단계에서 라이브러리를 다운로드하고 무엇이든 사용할 수 있지만 "중요" 상태에 문제가 있는 경우 프로덕션 릴리스 단계에서 개발자의 관심을 끌 가치가 있을 것입니다.

아티팩트와의 통합: 넥서스와 JFrog.

개발 환경에 통합. 선택한 도구는 개발 환경과 통합되어야 합니다. 개발자는 자신의 작업장에서 스캐닝 결과에 접근할 수 있거나 CVS에 커밋하기 전에 코드의 취약점을 직접 스캐닝하고 확인할 수 있는 능력이 있어야 합니다.

CD 통합. 이것은 제가 정말 좋아하고 이미 언급한 멋진 기능입니다. 산업 환경에서 새로운 취약점의 출현을 모니터링하는 것입니다. 그것은 다음과 같이 작동합니다.

우리는 공용 구성 요소 저장소 — 일부 외부 도구와 내부 저장소. 우리는 신뢰할 수 있는 구성 요소만 포함하기를 원합니다. 요청을 프록시할 때 다운로드한 라이브러리에 취약점이 없는지 확인합니다. 우리가 설정한 특정 정책에 해당하고 반드시 개발과 협력해야 하는 경우에는 해당 버전을 업로드하지 않고 다른 버전을 사용하라는 메시지가 표시됩니다. 따라서 라이브러리에 정말 중요하고 나쁜 것이 있는 경우 개발자는 설치 단계에서 라이브러리를 받지 못할 것입니다. 더 높거나 낮은 버전을 사용하도록 하십시오.

• 구축할 때 우리는 아무도 나쁜 것을 미끄러지지 않았는지, 모든 구성 요소가 안전하고 누구도 플래시 드라이브에 위험한 것을 가져오지 않았는지 확인합니다.
• 저장소에는 신뢰할 수 있는 구성요소만 있습니다.
• 배포할 때 패키지 자체(war, jar, DL 또는 Docker 이미지)를 다시 한 번 확인하여 정책을 준수하는지 확인합니다.
• 업계에 진출할 때 우리는 산업 환경에서 무슨 일이 일어나고 있는지 모니터링합니다. 심각한 취약점이 나타나거나 나타나지 않습니다.

동적 분석 - DAST

동적 분석 도구는 이전에 말한 모든 것과 근본적으로 다릅니다. 이는 사용자의 응용 프로그램 작업을 모방하는 것입니다. 웹 애플리케이션인 경우 요청을 보내고 클라이언트 작업을 시뮬레이션하고 전면에 있는 버튼을 클릭하고 양식에서 따옴표, 대괄호, 다양한 인코딩의 문자 등 인공 데이터를 보내 애플리케이션이 어떻게 작동하고 처리되는지 확인합니다. 외부 데이터.

동일한 시스템을 사용하면 오픈 소스의 템플릿 취약점을 확인할 수 있습니다. DAST는 우리가 어떤 오픈 소스를 사용하고 있는지 모르기 때문에 단순히 "악성" 패턴을 던지고 서버의 응답을 분석합니다.

- 예, 여기에 역직렬화 문제가 있지만 여기에는 없습니다.

여기에는 큰 위험이 따릅니다. 왜냐하면 테스터가 작업하는 동일한 벤치에서 이 보안 테스트를 수행하면 불쾌한 일이 발생할 수 있기 때문입니다.

• 애플리케이션 서버 네트워크의 부하가 높습니다.
• 통합이 없습니다.
• 분석된 애플리케이션의 설정을 변경하는 기능.
• 필요한 기술에 대한 지원이 없습니다.
• 설정이 어렵습니다.

마침내 AppScan을 시작했을 때 상황이 발생했습니다. 애플리케이션에 액세스하는 데 오랜 시간을 보냈고 3개의 계정을 얻었고 만족했습니다. 마침내 모든 것을 확인할 것입니다! 우리는 스캔을 시작했고 AppScan이 가장 먼저 한 일은 관리자 패널로 가서 모든 버튼을 뚫고 데이터의 절반을 변경한 다음 서버를 완전히 종료하는 것이었습니다. 메일 양식-요청. 테스트를 통한 개발은 다음과 같이 말했습니다.

- 얘들아, 지금 장난하는 거야?! 우리는 당신에게 계정을 주었고 당신은 스탠드를 세웠습니다!

가능한 위험을 고려하십시오. 이상적으로는 정보 보안을 테스트하기 위한 별도의 스탠드를 준비합니다. 이 스탠드는 적어도 어떻게든 나머지 환경과 격리되고, 조건부로 관리 패널을 확인합니다(가급적이면 수동 모드에서). 이것은 침투 테스트입니다. 현재 우리가 고려하지 않는 남은 노력 비율입니다.

이를 부하 테스트와 유사하게 사용할 수 있다는 점을 고려해 볼 가치가 있습니다. 첫 번째 단계에서는 10-15개의 스레드가 있는 동적 스캐너를 켜고 무슨 일이 일어나는지 확인할 수 있지만 일반적으로 실습에서 알 수 있듯이 좋은 것은 없습니다.

우리가 일반적으로 사용하는 몇 가지 리소스입니다.

강조할 가치가 있는 Burp 스위트 모든 보안 전문가를 위한 "스위스 칼"입니다. 누구나 사용하고 있고 매우 편리합니다. 이제 Enterprise Edition의 새로운 데모 버전이 출시되었습니다. 이전에는 플러그인이 포함된 독립 실행형 유틸리티에 불과했다면 이제 개발자는 마침내 여러 에이전트를 관리할 수 있는 대규모 서버를 만들고 있습니다. 이거 멋지네요. 꼭 시도해 보시길 권합니다.

프로세스 통합

통합은 매우 훌륭하고 간단하게 이루어집니다. 성공적인 설치 후 스캔 시작 스탠드용 애플리케이션 및 성공적인 통합 테스트 후 스캐닝.

통합이 작동하지 않거나 스텁 및 모의 함수가 있는 경우 이는 무의미하고 쓸모가 없습니다. 어떤 패턴을 보내든 서버는 여전히 동일한 방식으로 응답합니다.

• 이상적으로는 별도의 테스트 스탠드입니다.
• 테스트하기 전에 로그인 순서를 적어 두십시오.
• 관리 시스템 테스트는 수동으로만 수행됩니다.

Процесс

일반적인 프로세스와 특히 각 도구의 작업에 대해 조금 일반화했습니다. 모든 애플리케이션은 서로 다릅니다. 하나는 동적 분석으로 더 잘 작동하고, 다른 하나는 정적 분석으로 더 잘 작동하고, 세 번째는 OpenSource 분석, 침투 테스트로 더 잘 작동합니다. 와프.

모든 프로세스에는 제어가 필요합니다.

프로세스가 어떻게 작동하고 어디를 개선할 수 있는지 이해하려면 생산 지표, 도구의 지표, 결함 추적기 등 손에 넣을 수 있는 모든 것에서 지표를 수집해야 합니다.

어떤 정보라도 도움이 됩니다. 이 도구 또는 해당 도구가 더 잘 사용되는 곳, 프로세스가 특히 처지는 곳을 다른 각도에서 볼 필요가 있습니다. 시간에 따라 프로세스를 개선할 부분을 알아보려면 개발 응답 시간을 살펴보는 것이 좋습니다. 데이터가 많을수록 최상위 레벨부터 각 프로세스의 세부사항까지 더 많은 섹션을 구축할 수 있습니다.

모든 정적 및 동적 분석기에는 자체 API, 자체 시작 방법, 원칙이 있으므로 일부에는 스케줄러가 있고 다른 일부에는 없습니다. 우리는 도구를 작성하고 있습니다. AppSec 오케스트레이터를 사용하면 제품의 전체 프로세스에 대한 단일 진입점을 만들고 한 지점에서 관리할 수 있습니다.

관리자, 개발자 및 보안 엔지니어는 실행 중인 항목을 확인하고, 스캔을 구성 및 실행하고, 스캔 결과를 받고, 요구 사항을 제출할 수 있는 하나의 진입점을 갖습니다. 우리는 서류 작업에서 벗어나 모든 것을 개발에 사용되는 인간의 작업으로 변환하려고 노력하고 있습니다. 상태 및 메트릭이 포함된 Confluence 페이지, Jira 또는 다양한 결함 추적기의 결함, CI의 동기/비동기 프로세스로의 통합 등이 있습니다. /CD.

주요 요점

도구는 중요한 것이 아닙니다. 먼저 프로세스를 생각한 다음 도구를 구현하십시오. 도구는 훌륭하지만 비용이 많이 들기 때문에 프로세스부터 시작하여 개발과 보안 간의 의사소통과 이해를 구축할 수 있습니다. 안전의 관점에서 볼 때 모든 것을 "정지"할 필요는 없지만, 개발의 관점에서 보면 초임계도가 높은 것이 있으면 제거해야 하며 문제를 간과해서는 안 됩니다.

제품 품질 - 공통의 목표 보안과 개발 모두. 우리는 한 가지 일을 합니다. 모든 것이 올바르게 작동하고 평판 위험이나 금전적 손실이 없는지 확인하려고 노력합니다. 이것이 바로 우리가 의사소통을 개선하고 제품 품질을 향상시키기 위해 DevSecOps, SecDevOps 접근 방식을 장려하는 이유입니다.

이미 가지고 있는 것부터 시작하세요.: 요구사항, 아키텍처, 부분 점검, 교육, 지침. 모든 관행을 모든 프로젝트에 즉시 적용할 필요는 없습니다. 반복적으로 이동. 단일 표준은 없습니다. 실험 다양한 접근 방식과 솔루션을 시도해 보세요.

정보 보안 결함과 기능 결함 사이에는 등호가 있습니다.

모든 것을 자동화하세요그게 움직인다. 움직이지 않는 것은 무엇이든 옮기고 자동화하세요. 어떤 일이 손으로 이루어지면 이는 프로세스의 좋은 부분이 아닙니다. 아마도 이를 검토하고 자동화하는 것도 가치가 있을 것입니다.

IS 팀의 규모가 작은 경우 - 보안 챔피언을 사용하세요.

아마도 내가 말한 것이 당신에게 적합하지 않을 것이고 당신은 당신 자신의 것을 생각해 낼 것입니다. 그것은 좋습니다. 하지만 프로세스 요구 사항에 따라 도구를 선택하십시오.. 커뮤니티에서 이 도구는 나쁘고 이 도구는 좋다고 말하는 것을 보지 마십시오. 아마도 귀하의 제품에는 그 반대가 적용될 수 있습니다.

도구 요구 사항.

• 낮은 수준의 거짓 긍정.
• 적절한 분석 시간.
• 사용 편의성.
• 통합 가용성.
• 제품 개발 로드맵을 이해합니다.
• 도구를 사용자 정의할 수 있습니다.

Yuri의 보고서는 DevOpsConf 2018에서 최고 보고서 중 하나로 선정되었습니다. 더욱 흥미로운 아이디어와 실제 사례를 알아보려면 27월 28일과 XNUMX일에 Skolkovo를 방문하세요. DevOpsConf 이내에 축제 RIT++. 더 좋은 점은, 귀하의 경험을 공유할 준비가 되어 있다면, 신청서 제출 21월 XNUMX일까지 보고서를 제출하세요.

출처 : habr.com