Secure Coding - 소프트웨어 개발 방법론

* Secure Coding

1. 소프트 개발 보안 방법론

 - 개요

개발서버 - 스테이징서버 - 웹애플리케이션서버 3가지가 있다. 그 뒤에 DB가 존재한다.

방화벽이 있으면(인가되지않는 사용자막는 방화벽, 패턴인식 방화벽, 웹 방화벽)

방화벽을 달아도 애플리케이션서버가 바로 공격당할 수 있다.

ex)DDOS, 랜섬웨어

 - 보안 침해사고 유형 및 사례

멀웨어, XSS, 워터링 홀은 타겟이 개인이고

SQLi, DDOS, Web Shell 등은 서버를 공격한다.

MyBatis에서 ${}를 쓰면 SQLi에 위험이 있다.

양자컴퓨터로도 못푸는 암호 방식 -> 블록체인

웹애플리케이션 취약점 이용 - url패턴을 통한 개인정보 탈취

                           - 서버로 접근해서 내부망 해킹 및 악성코드 삽입

                           

                           - 파일 업로드 취약점을 이용 - Web Shell -> 암호화되지않은 고객정보가 로그에 저장

 - 시큐어 코딩의 필요성

보안 취약점 중 70%는 설계과정의 오류부터 발생한다.

대부분 제품 완성 후 베타 테스트에서 보안 업데이트 및 패치로 보완하고 있는 추세

설계에 가장 많은 투자를 해야한다.

 - 보안 개발 방법론

요구사항분석 - 설계 - 구현 - 테스트

요구사항분석 - 보안요구사항 식별

설계         - 어느 기능에서 어느 문제인지, 어떻게 통제할것인지

구혀         - SW 개발보안 가이드를 준비하여 개발, 도구활용해서 보안약점 진단

테스트       - 취약점 진단, 모의해킹 테스트

MS - SDL

Oracle - SSAP

Secure Software - CLASP

SDL과 CLASP를 많이 쓴다.

 - OWASP CLASP

OWASP라는 단체가 만든 CLASP

책임자나 PM 등 프로젝트 참여자에 대한 보안에 관한 지침 제공

설계나 오류를 찾아내어 개선하기 위해 취약점 목록을 제공

CLASP 프로세스는 View - Activity - Process Component로 구성된 계층 구조

5개의 검증을 제공한다 - 개념검증, 역할기반검증, 활동평가검증, 활동구현검증, 취약성검증

개념검증 - CLASP를 구성하고 있는 역할기반검증, 활동평가검증, 활동구현검증, 취약성검증를 검증한다.

역할기반검증 - 역할을 가진 각 담당자들이 보안문제에 접근하는 방법과 기본적인 책임을 소개

활동평가 검증 - 앞에 있는 보안지침서를 잘지켜내고있는지

활동구현 검증 - 24개의 활동 평가 검증 기준의 세부사항, 잘 진행되고 있는지

취약성검증  - 애플레키에션에서 취약점이 있는지 찾는다.

 - MicroSoft SDL

SDL - Window95부터 나왔다.

교육 - 계획/분석 - 설계 - 구현 - 시험/검증 - 배포/운영 - 대응으로 이루어진 프로세스다.

소프트웨어를 안전하진 않지만 우선 만들고 업데이트로 처리한다.

위협모델링 작업 수행 - 보안팀구성 -> 분해 작업 -> 

위협 추출( 신분 위장(Spooping Identity)

데이터 변조(Tampering with data)

부인(Repudiation)

정보유출(Information Disclosure)

서비스 거부(Denial of Serice, DoS)

권한 상승(Elevation of Privilege) )

위협 추출에 따라 점수를 매겨서 도출된 위협에 대한 위험도를 계산한다.

DREAD 위험도 분류 이용, 가장 위협적인 요소들이 먼저 제거될 수 있도록 한다.

예상 피해(Damage potential) 피해가 얼마나 클 것인가.

재현 확률(Reproducibility) 공격이 성공할 확률이 얼마인가

공격 용이도(Exploitability) 공격을 위해 얼마나 많은 노력과 기술이 필요한가.

영향을 받는 사용자(Affected users) 위협으로부터 얼마나 많은 사용자가 영향을 받는가.

발견 용이성(Discoverability) 얼마나 쉽게 취약성이 발견되는가.

영향을 받는 사용자가 가장 중요하다.

기능에 관련된 점수와 DREAD와 관련된 점수를 다 측정한다.

실제 피해가 발생하면 어떻게 대응 할것인지 대응기법을 선택해야 한다.

문제점 무시 문제점을 무시하고 아무런 대응도 하지 않는다. 불가피한 사유로 아무런 대응을 하지 않기로 했다면, 위협에 관련된 기능을 기본적으로 비활성화 상태로 설치할 수 있는지 고려해야 한다.

문제점 알림 사용자에게 문제점을 알리고 사용자로 하여금 그 기능을 사용할 것인지사용하지 않을 것인지 결정할 수 있도록 한다.

문제점 제거 문제점을 고칠 시간이 없고, 보안 위험도가 충분히 높다면, 그 기능을 삭제하는 것을 진지하게 고려해야 한다.

문제점 수정 가장 분명한 해결책. 기술적으로 문제를 고치는 것이지만 현실적으로 가장 어려운 방법인 경우도 있다.

도출된 위협들을 제거하기 위해 요구되는 기술들을 도출

신분 위장(Spooping Identity) 적절한 인증(패스워드, 비밀키, 홍채인식, 지문 등)

패스워드는 저장하지 않음.

Cookie Authentication

Kerberos Authentication

PKI 시스템 (SSL/TLS 이용)

전자서명

데이터 변조(Tampering with data) 해쉬 ( 제일많이쓰는 방법 )

ACLSs

Message authentication codes

전자서명

부인(Repudiation) 전자서명

감사로그

정보유출(Information Disclosure) Privacy-enhanced 프로토콜

암호화( 정보유출때 심각한 유출에 위험한 정보는 암호화 )

ACLs

서비스 거부(Denial of Serice, DoS) ACLs

필터링

Throttling

Quality of service

권한 상승(Elevation of Privilege) 최소한의 권한으로 실행

Group of role membership

Input validation

 - 소프트웨어 보안 개발 가이드 ( SDL을 한국형으로 바꿔놓은것 )