measures ssdlc
보안 SDLC 또는 SSDLC를 구현하기위한 다양한 보안 조치에 대해 알아보십시오.
기술이 빠르게 성장함에 따라 보안 데이터의 해킹 및 도용에 대한 보안 관련 위협도 그에 따라 증가했습니다. 따라서 기술 성장은 소프트웨어 제조업체가 보안 위협 및 취약성에 대해 강력하고 견고하다는 것을 확인하는 데 어려움을 겪고 있습니다.
소프트웨어 제품은 특히 개인 및 금융 데이터를 포함하는 국방, 금융 및 의료와 같은 부문에서 고도로 보안되고 규정 및 규제 된 보안 및 개인 정보 보호 표준을 충족하지 않는 한 의도 된 기능에 완벽하게 작동하더라도 출시 할 수 없습니다. .
제품이 배포 될 때 심각도가 높든 중간이든간에 제품에 보안 결함이있을 수 없습니다. 따라서 모든 종류의 공격, 악의적 인 위협, 취약성으로부터 소프트웨어와 데이터를 보호하고 최종 사용자에 대한 소프트웨어의 신뢰성을 보장하는 것이 매우 중요합니다.
기존의 소프트웨어 개발과 달리 전체 소프트웨어가 개발 된 후 마지막 단계에서 테스트하는 것은 더 이상 효과적이지 않습니다. Agile, DevOps 및 ShiftLeft 개념을 구현하면 애플리케이션 수명주기의 모든 단계뿐 아니라 초기에 테스트를 수행하는 것이 필수적입니다.
그러나 소프트웨어의 보안은 마지막 단계에서 구축하거나 테스트 할 수 없으므로 소프트웨어의 전체 보안을 보장하기 위해 모든 단계에서 구축해야합니다.
학습 내용 :
SSDLC에 대한 보안 조치
아래 나열된 것은 보안 SDLC 또는 SSDLC를 보장하기 위해 소프트웨어 개발 수명주기 전반에 걸쳐 구현할 수있는 보안 관련 조치의 다양한 수단이며 가능한 한 결함이 다음 단계로 넘어갈 수 없습니다.
SDLC 단계에서 보안을 구축해야하는 다양한 보안 분석 및 평가가 있습니다.
- 요구 사항 단계
- 계획 단계
- 아키텍처 및 디자인 단계 : 설계에 따른 보안 위험 평가.
- 개발 단계 : 보안을위한 코드의 정적 분석 인 보안 코드 분석.
- 구현 단계 : 애플리케이션 보안 테스트 인 Dynamic Code Analysis.
- 테스트 – 배포 전 단계 : 침투 테스트 및 취약성 분석.
# 1) 요구 사항 단계
- 주로 소프트웨어에 필요한 보안 조치가 구축되었는지 확인하기 위해 보안 관련 특정 요구 사항 요구 사항 단계에서 충분한 세부 정보와 예상 결과를 명확하게 파악해야합니다.
- 일반적인 사용 사례와 비즈니스 시나리오를 식별하면서 명확한 보안 관련 사용 사례 및 시나리오 보안 기능을 캡처하고 보안 테스트 시나리오를 설계하기 위해 확인 목적으로 식별되어야합니다.
다음은 캡처 할 수있는 명시적인 보안 관련 요구 사항을 보여주는 몇 가지 샘플 예입니다.
Sec-Req-01 : 시스템은 모든 게이트웨이 및 입구 지점에서 인증 조치를 취해야합니다.
Sec-Req-02 : 시스템은 보안 로그인 화면을 통해 인증을 구현해야합니다.
Sec-Req-03 : 개인 데이터는 저장시 암호화됩니다.
# 2) 계획 단계
이에 국한되지 않고 높은 수준에서 계획 단계에서 다음 사항을 처리해야합니다.
예제로 수동 테스트 케이스를 작성하는 방법
- 강한 사람, 전담 보안 팀 , 프로그램 팀의 PMO (프로젝트 관리 사무실) 외부에서 작동하며 보안 책임자, 보안 설계자, 보안 테스터 프로그램의 모든 보안 관련 활동을 편향되지 않은 방식으로 수행하고 관리하도록 구성됩니다. 이러한 각 역할에 대해 명확한 RnR (역할 및 책임) 및 RACI가 정의됩니다.
- 어떤 에스컬레이션, 모호성 보안 문제와 관련된 문제는 PSO (Product Security Officer)가 처리해야 보안 팀이 원활하게 작동하고 올바른 결정을 내리는 데 도움이됩니다.
- 강력한 보안 테스트 전략 보안 관련 요구 사항을 구현하는 방법, 테스트 할 방법,시기 및 대상, 각 단계에서 사용해야하는 도구를 식별해야합니다.
- 참여는 필수입니다. 보안 연락처 프로그램과 관련된 모든 기술 / 검토 토론에 대해 보안 팀이 프로그램에 발생하는 변경 사항을 알 수 있도록합니다.
# 3) 아키텍처 및 디자인 단계
설계 단계 초기에 보안 측면에 더 많은주의를 기울이면 보안 위험을 방지하고 SDLC에서 나중에 설계 변경에 대한 상당한 노력을 줄이는 데 도움이됩니다.
소프트웨어 및 소프트웨어가 호스팅 될 인프라를 설계하는 동안 모든 것이 가능합니다. 보안 설계 구현 보안 설계자의 참여로 잘 설계되어야합니다.
기능적 및 비 기능적 설계 및 아키텍처 측면 간의 모호성과 충돌은 올바른 이해 관계자가 참여하는 브레인 스토밍 세션을 통해 해결해야합니다.
이 단계에서는 상세한 제품 보안 위험 평가 (때로는 ‘정적 평가’ 보안 전문가 팀에 의해 수행되어야합니다.
보안 위험 평가 설계 관점에서 보안 관련 결함을 식별하고 이에 따라 제품을 높이기 위해 예비 설계 / 아키텍처 단계에서 보안 관점에서 프로그램 검토를 포함합니다. 보안 위험 문제를 해결하고 다음 단계로 들어 가지 않도록 프로젝트 팀에 요청합니다.
오이는 어떤 종류의 검사를 도와 주나요?
이러한 평가는 해당 문서에 요약 된 조직 / 산업 보안 지침, 표준 및 제어를 기반으로 수행됩니다. 예 : UXW 00320, UXW 030017
제품 보안 위험 평가 중 :
- 요구 사항, 기능, 사용자 스토리 및 해당 디자인 문서는 프로젝트 팀이 공유 한 세부 정보, 아티팩트를 기반으로 검토됩니다. 예 : 디자인 문서 (HLDD 및 LLDD). 평가에는 문서가없는 경우 관련 프로젝트 팀 구성원과 논의하거나 의심스러운 부분을 명확히하기 위해 또한 포함됩니다.
- 설정된 표준 및 기타 모범 사례에 대해 프로그램의 보안 요구 사항을 매핑하는 동안 간격이 식별됩니다. 때로는 식별 된 격차를 기반으로 위협 모델도 개발됩니다.
- 이러한 격차는 잠재적 인 보안 위험으로 식별되며 구현을위한 가능한 완화 조치를 제안하고 제기 및 관리하는 것도 포함됩니다.
- 프로젝트 팀이 이러한 완화를 구현하면 시스템 테스트 팀이 설계 한 적절한 테스트 사례를 통해 종결 여부를 확인합니다.
- 추적 성을 제공하는 위험 관리 매트릭스는 이러한 위험을 추적 할 준비가되어 있습니다. 보안 설계자와 PSO는 잔여 위험에 대한 승인 및 사인 오프를 수행합니다.
설계 단계에서 식별되는 일반적인 위협 패턴은 입력 유효성 검사, 감사 / 로그 관리, 구성 및 암호화와 관련이 있습니다. 위험 식별에는 Weak Passwords, Simple Brute Force Attacks 등과 같은 공격 취약성이 포함됩니다.
일반적인 검토에는 개인 데이터에 대한 액세스, 감사 추적 액세스, 블랙 리스팅-화이트리스트 엔티티, 데이터 정리 및 삭제 활동과 관련된 위험이 포함됩니다.
샘플 테스트 시나리오에는 다음이 포함됩니다.
- 버퍼 오버플로 취약점 : 매개 변수를 수동으로 퍼징하여 서버 속도를 늦추고 서버가 응답하지 않도록 (서비스 거부) 강제하지 않아야합니다.
- 데이터 삭제 : 공격자가 시스템에 악성 콘텐츠를 삽입하고 저장할 수 없도록 모든 입력 및 출력에 대해 적절한 데이터 삭제가 이루어 지도록합니다.
# 4) 개발 단계
안전한 코드 분석 이다 정적 코드 평가 평가하는 데 사용되는 방법 비밀번호 자동화 된 스캐닝 도구를 사용하는 소프트웨어의 다양한 기능. 예: 확고히 하다.
이 분석은 보안 위협에 대해 생성 된 코드를 스캔하기 위해 모든 코드 체크인 / 빌드에서 수행됩니다. 이 평가는 일반적으로 사용자 스토리 수준에서 수행됩니다.
- 플러그인을 통한 Fortify 스캔은 개발자의 컴퓨터에 설치해야합니다.
- Fortify는 빌드 템플릿과 통합되어야합니다.
- 자동 스캔은 매일 모든 빌드에서 수행됩니다.
- 스캔 결과는 보안 팀에서 오 탐지 여부를 분석합니다.
- 이 평가에서 확인 된 결함은 폐쇄까지 제기 및 관리되어 누출을 최소화 / 다음 단계로 제로화합니다.
샘플 테스트 시나리오에는 다음이 포함됩니다.
- 데이터 전송 중에 민감한 데이터가 일반 텍스트로 전송되지 않도록합니다.
- 안전한 데이터 전송을 보장하려면 HTTPS 채널에 외부 API를 배포해야합니다.
# 5) 구현 단계
동적 코드 분석 OWASP (Open Web Application Security Project) 테스트라고도하는 애플리케이션 보안 테스트에 불과합니다. VAPT (취약점 분석 및 침투 테스트)는 구현 / 테스트 단계에서 수행되어야합니다.
이 분석은 바이너리 및 일부 환경 구성을 평가하고 보안 요구 사항에 대한 코드를 더욱 강화합니다.
이 분석의 일부로 동적 행동 또는 프로그램의 다양한 기능에 대한 보안 관련 취약점을 분석합니다. 규정 된 사용 사례 및 비즈니스 시나리오도 동적 코드 분석을 수행하는 데 사용됩니다.
이 활동은 테스트 빌드 자동 및 수동 접근 방식으로 다양한 보안 도구를 사용합니다.
- HP WebInspect, Burp Suite, ZAP 및 SOAP UI 도구는 일반적으로 표준 취약성 데이터베이스에 대한 취약성을 확인하는 데 사용됩니다 ( 예: OWASP 상위 10 )
- 이 활동은 주로 자동화되어 있지만 특정 도구 제한으로 인해 오 탐지를 분류하기 위해 일부 수동 작업이 필요할 수 있습니다.
- 이는 테스트 할 준비가 된 소프트웨어가 배포되는 별도의 환경 (시스템 테스트 환경)에서 이상적으로 수행됩니다.
- 제안 된 완화 조치를 통해 취약성을 제기하고 종결시켜야합니다.
이 분석 중에 식별 된 일반적인 위협 패턴은 입력 유효성 검사, 손상된 인증 및 세션 관리, 민감한 데이터 노출, XSS 및 암호 관리와 관련이 있습니다.
샘플 테스트 시나리오에는 다음이 포함됩니다.
- 암호 관리 : 암호가 구성 파일 또는 시스템의 어느 곳에도 일반 텍스트로 저장되지 않도록합니다.
- 시스템 정보 유출 : 시스템 정보가 어느 시점에서든 유출되지 않도록하기 위해 printStackTrace가 공개 한 정보는 공격 계획에서 적을 도울 수 있습니다.
# 6) 테스트 – 배포 전 단계
침투 테스트 , 짧은 펜 테스트 및 Infra VAPT (취약점 분석 및 침투 테스트) , 본격적인 전체적인 테스트입니다 완전한 솔루션 과 구성 (네트워크 포함) 사전 프로덕션 또는 프로덕션과 유사한 환경에서 이상적으로 수행됩니다.
이것은 주로 다른 취약점과 함께 DB 취약점 및 서버 취약점을 식별하기 위해 수행됩니다. 이것이 수행 될 보안 테스트의 마지막 단계입니다. 따라서 여기에는 이전에보고 된 결함 및 위험에 대한 검증도 포함됩니다.
- Nessus, Nmap, HP Web Inspect, Burp Suite, ZAP와 같은 도구는 시장에서 사용 가능하며 펜 테스트를 수행하는 데 사용됩니다.
- 자동화 된 도구를 사용하여 웹 애플리케이션을 스캔하고 추가 검증을 위해이 테스트를 수행합니다. 테스트는 실제 공격자의 행동을 시뮬레이션하기 위해 수행되므로 몇 가지 부정적인 테스트도 포함될 수 있습니다.
- 인프라 취약성 평가에는 취약성을 식별하고 표적 공격에 대한 복원력을 확인하기위한 인프라 (네트워크, 시스템 및 서버)의 스캔, 분석 및 보안 구성 검토가 포함됩니다.
- 이는 배포 할 준비가 된 소프트웨어를 테스트하여 실시간 환경을 시뮬레이션하는 사전 프로덕션 또는 프로덕션과 유사한 환경에서 수행됩니다.
- 스캐너와 수동 기술을 모두 사용하여 취약점을 식별하여 오 탐지를 제거합니다. 또한 수동 테스트 중에 실시간 비즈니스 시나리오가 수행됩니다.
- 전체 프로그램에 대해 수행되는 전체 보안 분석에 대한 최종 보고서가 생성되어 고위험 항목의 상태를 강조합니다.
샘플 테스트 시나리오에는 다음이 포함됩니다.
- 취약한 HTTP 메서드가 활성화되지 않도록합니다.
- 다른 사용자의 민감한 정보가 네트워크를 통해 일반 텍스트로 표시되지 않도록합니다.
- 악성 파일의 업로드를 방지하기 위해 파일 업로드에 대한 유효성 검사가 구현되었는지 확인합니다.
SSDLC의 표 형식 요약
아래 표에는 위에서 설명한 보안 분석의 다양한 측면이 요약되어 있습니다.
| SDLC 단계 | 주요 분석 완료 | 이 평가에서 정확히 수행되는 작업 | 입력 | 사용 된 도구 | 산출 |
|---|---|---|---|---|---|
| 요구 사항 | 보안 요구 사항을 효율적으로 캡처하기 위해. | 요구 사항이 분석됩니다. | 요구 사항 문서 / 사용자 스토리 / 기능 | 안내서 | 보안 요구 사항은 요구 사항 사양에 내장되어 있습니다. |
| 계획 | 설정 될 보안 팀 보안 테스트 전략이 준비되었습니다. | 팀 식별 및 설정. 이해 관계자와 함께 전략을 준비, 검토 및 승인했습니다. | 무 | 안내서 | RnR 및 RACI가 정의 된 보안 팀 설정. 보안 테스트 전략 문서를 서명했습니다. |
| 디자인 | 보안 위험 평가 | 보안 결함을 식별하기 위해 프로그램 관련 문서를 검토합니다. 팀과 논의하십시오. 위험이 식별되고 완화가 제안됩니다. | 프로젝트 관련 문서 : HLDD, LLDD. | 직접 검토 | 확인 된 설계 위험. 완화 제안이 포함 된 위험 관리 매트릭스. |
| 개발 | 보안 코드 분석 (정적 평가) | 보안 스캐너는 개발자의 컴퓨터에 연결됩니다. 빌드 템플릿과 통합 된 보안 도구입니다. | 개발 된 코드 | 스캐너 자동화 (Fortify). 오 탐지 수동 분류. | 보안 코드 결함. 완화를 통한 위험 관리 매트릭스. |
| 이행 | 동적 코드 분석 (동적 평가) | 애플리케이션 보안 테스트가 완료되었습니다. | 단위 테스트 빌드 전용 테스트 환경 | 보안 테스트 도구 (HP WebInspect, Burp Suite, ZAP 오 탐지 수동 분류. | 동적 코드 분석 결함. 완화 기능이있는 위험 관리 매트릭스. |
| 테스트 / 배포 전 | 펜 테스트, 인프라 VAPT | 실시간 시나리오를 사용한 침투 테스트 및 Infra VAPT. 이전에보고 된 위험 / 결함의 확인. | 빌드를 배포 할 준비가되었습니다. Pre-Prod 또는 Production like Environment. | 보안 테스트 도구 (Nessus, NMAP, HP WebInspect) 오 탐지 수동 분류. | 완화 기능이있는 위험 관리 매트릭스. 위험 상태가 포함 된 최종 보안 테스트 보고서. |
결론
따라서 SDLC의 다양한 단계에 걸쳐 통합 된 이러한 모든 보안 관련 측면의 구현을 통해 조직은주기의 초기에 보안 결함을 식별하고 조직이 적절한 완화를 구현할 수 있으므로 고위험 보안 결함 라이브 시스템에서.
이 연구는 또한 대부분의 보안 결함이 개발 단계, 즉 개발 단계에서 소프트웨어로 유도된다는 것을 보여줍니다. 코딩 단계 여기서 코딩은 어떤 이유로 든 모든 보안 측면을 충분히 처리하지 못했습니다.
이상적으로는 어떤 개발자도 보안을 손상시키는 잘못된 코드를 작성하고 싶어하지 않습니다. 따라서 개발자에게 보안 소프트웨어를 작성하는 방법을 안내하기 위해 다가오는 자습서에서는 모범 사례 및 코딩 지침 개발자를 위해 소프트웨어의 더 나은 보안을 보장합니다.
Secure SDLC 또는 SSDLC에 대한이 튜토리얼이 도움이 되었기를 바랍니다.