[자격증] 정보처리기사 실기 : 24강 소프트웨어 개발 보안 구축 (SW 개발 보안 구현하기)

 정보

• 업무명     : 정보처리기사 실기 : 24강 소프트웨어 개발 보안 구축 (SW 개발 보안 구현하기)

• 작성자     : 이상호

• 작성일     : 2020-05-12

• 설   명      :

• 수정이력 :

 

 

 내용

[SW 개발 보안 구현]

[1] SW개발보안 구현을 위한 시큐어 코딩

• 안전한 소프트웨어를 개발하여 각종 보안 위협으로부터 예방하고 대응하고자 하며 정보시 스템 개발 시 보안성을 고려하고 보안 취약점을 사전에 제거하기 위하여 시큐어 코딩을 사용한다. 

   

• 1. 소프트웨어 개발보안 측면의 시큐어 코딩의 목적 

   

  • (1) 보안 취약점과 결함방지 

     

    • 최근 사이버 공격의 진화에 따라 사전에 정보처리시스템의 보안취약점을 사전에 대응 하고 SQL injection 취약점, Zero Day Attack 공격, 침입차단시스템(TMS System) 등 보안장비의 우회 등과 같은 보안 취약점을 사전에 제거하여 개발한다.

  • (2) 안전한 대고객 서비스 확대 

     

    • 대부분의 대고객 서비스가 ICT신기술을 통하여 인터넷을 통해 제공되면서, 대고객 서 비스의 보안취약점을 지속적으로 진단하여 제거에 효율적 관리 방안을 마련한다. 

       

  • (3) 안정성 및 신뢰성 확보 

     

    • 대고객 서비스의 신뢰성을 기반으로 하는 안정성에 기반한 보안확보를 위해 정보시스 템의 기초 단계부터 설계 개념 및 시큐어 코드의 수준에서의 대응조치를 제안하여 대 고객 서비스의 보안성을 강화한다

• 2. 개발단계 보안을 위한 시큐어 코딩 적용방안 

   

  • 소프트웨어 초기 설계와 개발과정에서 개발자의 실수와 지식 부족, 프로그래밍 언어의 고 유한 특징 등으로 발생 가능한 소프트웨어 취약점의 최소화를 위하여, 초기 설계 단계부 터 보안요소를 고려하여 진행하는 개발 방식이며, SW개발 단계별 결함 수정비용 분석: 보 안 고려 없이 개발된 소프트웨어의 사후 수정비용은 시큐어 코딩 비용의 수십 배에 달하 는 것으로 파악된다. 

     

  • (1) 보안 정책의 

     

    • 수립 개발보안 가이드 작성 및 공지, 적용 의무화 사업에 대한 명확한 구분과 정책 추진이 필요하다. 

       

  • (2) SW개발보안을 위한 시큐어 코딩 가이드 작성 

     

    • 사업자는 SW개발보안을 위한 적절한 개발절차와 방법을 마련하여 참여인력에게 제공 하여 보안을 위한 시큐어 코딩 가이드를 작성하도록 한다.

  • (3) 시큐어 코딩 가이드 교육 

     

    • 참여인력에 대한 소프트웨어 개발보안 가이드 및 시큐어 코딩 교육을 실시한다. 

       

  • (4) 시큐어 코딩 자동화 도구 

     

    • 개발과정에서 보안약점 진단도구를 이용하여 개발자 스스로 보안약점 진단 및 제거에 활용한다

 

[2] SW보안을 위한 시큐어 코딩의 점검내용

• SW응용프로그램의 각 기능을 안전하게 서비스하기 위해 식별된 보안항목 중 보안요구사 항 정의서에 있는 보안 항목을 식별한다. 

   

• 1. 입력데이터 검증 및 표현 

   

  • 이용자, 프로그램에서 입력되는 데이터에 대한 유효성 사전 검증체계를 갖추고, 오류발생 시 처리가 가능하도록 개발을 수행한다

 

• SW보안 입력 데이터 검증 및 표현

  • SQL삽입 

     

    • 사용자의 입력 값 등 외부 입력 값이 SQL 쿼리에 삽입되어 공격 

       

  • 자원 삽입 

     

    • 외부 입력된 값의 사전 검증이 없거나 또는 잘못 처리된 검증을 거쳐서 제공되는 시스템 자원에 접근 경로 등의 정보로 이용될 때 발생 

       

  • 크로스사이트 스크립트 

     

    • 검증되지 않은 외부 입력 값에 의해 브라우저에서 악의적인 코드가 실행되는 보안약점 

       

  • 운영체제 명령어 삽입 

     

    • 운영체제(OS) 명령어 파라메터 입력 값이 적절한 사전검증을 거치지 않고 사용되어 공격자가 운영체제 명령어를 조작할 수 있는 보안약점 

       

  • 기타 

     

    • 신뢰성이 낮은 URL주소로 자동으로 접속되는 LDAP 삽입, 디렉토리 경로 조작, 연결 크로스사이트 요청 위조, XQuery 삽입, XPath 삽입, HTTP 응 답분할 등

• 2. 보안기능 

   

  • 보안기능(인증, 접근제어, 기밀성, 암호화, 권한 관리 등)을 적절하지 않게 구현 시 발생할 수 있는 보안약점이다.

     

  • 사용자 중요한 정보를 평문으로 저장되거나 (또는 전송되는 경우 ), 소스에 명시적으로 적 혀있는 패스워드(하드코딩), 충분하지 못한 암호화 키 길이를 사용하는 경우, 적절하지 못 한 무작위 난수 값을 사용하는 경우, 내부 시스템상의 패스워드 평문 저장 등을 의미한다.

 

• SW보안 기능

  • 적절한 인증 없는 중요기능 허용 

     

    • 적절하지 못한 인증 없이 중요정보(개인정보, 계좌이체 정보 등)를 열람 또는 변경 가능한 보안 취약점 

       

  • 부적절한 인가 

     

    • 적절하지 못한 접근제어로 외부 입력 파라미터값이 포함된 문자열로 서버 인프라 자원에 접근되거나 (또는 서버 실행 인가)가능케 하는 보안약점 

       

  • 중요한 자원에 대한 잘못된 권한설정 

     

    • 중요한 자원(프로그램 설정 값, 민감한 사용자 데이터의 노출 등)에 대한 적절하지 못한 접근권한을 부여되어, 의도치 않게 중요정보가 노출 ․수정되는 보안약점 

       

  • 취약한 암호화 알고리즘 사용 

     

    • 중요한 민감성 정보(패스워드, 개인정보 등)의 기밀성이 취약한 암호 화 알고리즘을 사용하여 정보가 노출되는 보안 취약점

• 3. 시간 및 상태 

   

  • 프로그램 실행 중에 동시에 수행되는 병렬 처리 시스템, 다수의 프로세스가 실행되는 환경에서 시간과 실행 상태를 부적절하게 처리되어 발생 가능한 보안 취약점이다

 

• 4. 에러 처리 표현 

   

  • 에러를 처리하지 않거나, 불충분하게 처리하여 에러 정보에 중요정보(시스템 등)가 포함될 때 발생할 수 있는 보안약점이다.

 

 

• 5. 코드 오류 

   

  • 프로그램의 형(type)변환 오류, 인프라 자원(메모리 사용현황 등)의 적절하지 못한 반환 값 등과 같이 개발자가 범할 수 있는 개발 오류로 인해 발생되는 보안약점이다.

 

• 6. 캡슐화 

   

  • 중요한 데이터를 은닉하기 위한 확장개념이라고 볼 수 있으며, 캡슐화는 객체들의 내부와 외부 간의 분리 역할을 수행하고 사용자에게 상세 구현을 감추고 필요사항만 보이게 함으로써, 객체의 속성과 메소드를 다른 객체가 접근할 수 없도록 하기 때문에 메시지 수신에 의해 요구된 작업을 수행한다. 따라서 소프트웨어의 부품의 재사용증대와, 소프트웨어의 수정, 시험, 유지보수성이 향상되는 효과가 있다

 

• 중요한 프로그램의 데이터와 프로그램의 기능성을 충분하지 못하게 캡슐화하였을 때 인가 되지 않은 사용자에게 프로그램 내부의 데이터 누출이 가능해지는 보안약점이며, 그 예로 Private 배열에 Public Data가 할당되거나, Public Method부터 반환된 Private 배열 등이 있다.

 

• 7. API 오용 

   

  • 의도된 사용에 반하는 방법으로 API를 사용하거나, 보안에 취약한 API를 사용하여 발생할 수 있는 보안약점이다.

 

[수행]

[1] 설계가 완료된 SW프로그램 개발환경을 점검한다.

• 1. SW응용프로그램을 구현한다. 

   

  • (1) 초기 설계단계의 기능 명세서에 따라 기본 설계서를 작성하고 상세설계서 등에 반영된 보안요구사항을 응용프로그램 개발자가 직접 구현한다.

     

  • <응용프로그램 방식의 보안 구현의 고려사항>

     

    • 개인정보 입력 시 암호화되어야 하는 범위를 결정한다. 

       

    • 소프트웨어 플랫폼을 확인하여 보안 모듈을 선택한다. 

       

    • 보안 구축 전문업체의 확인을 통해 소프트웨어 플랫폼에 맞는 응용프로그램방식의 솔루션을 제공해 줄 수 있는지 확인하여야 한다. 

       

    • 응용프로그램 방식에서의 암호화 부분은 텍스트로 전송되는 부분만을 암호화하여, 이 미지와 같이 암호화가 불필요한 부분을 제외하여 적절히 암호화 적용부분 결정한다. 

       

    • 응용프로그램 방식의 보안 구축을 완료한 후 적절한 테스트 시나리오를 통해 구축완료를 선포한다

 

• 2. 응용프로그램 구현 환경을 관리한다. 

   

  • (1) 로그인 관리 

     

    • (가) 로그인 실패 시 정확한 원인을 표시한다. 

       

      • 개발자의 로그인 실패 시 로그인 실패 이유의 설명 없이 세션을 종료하거나 재입 력 대기를 하지 않는다. 

         

    • (나) 잘못된 패스워드 입력 횟수 제한

       

      • 일정 횟수 이상 패스워드를 잘못 입력할 경우 일시적인 사용 중지 또는 세션을 종료한다. 

         

    • (다) 최근 로그인 정보 표시 

       

      • 개발자가 로그인 시 가장 최근에 성공적으로 로그인한 날짜, 시각 등의 정보를 화 면에 표시한다

         

    • (라) 일정시간 경과 시 자동 로그오프 

       

      • 사용자로부터 일정시간 동안 입력이 없을 경우 자동 로그오프 또는 세션 종료 처 리를 한다. 

         

    • (마) 로그인 상태 유지 시 세션 방식 적용 

       

      • 웹 애플리케이션의 경우 브라우저에 저장된 쿠키(cookie) 방식보다는 서버 측에 일 부 정보를 저장하여 상호 대조할 수 있는 세션(session) 방식을 사용한다.

  • (2) 패스워드 관리  

     

    • (가) 패스워드 최소 길이 제한 패스워드의 최소 길이를 통제할 수 있도록 최소 패스워드 길이 값을 정의한다. 

 

• (나) 추측 가능한 패스워드 사용 통제 

   

  • 1) 사용자 개인 정보(주민등록번호, 휴대폰 번호 등)와 관련된 패스워드는 사용하 지 못한다. 2) 사용자 ID와 동일한 패스워드는 사용하지 못한다. 3) 동일한 문자 또는 숫자가 반복되는 패스워드는 사용하지 못한다. 4) 문자 또는 숫자만으로 구성된 패스워드는 사용하지 못한다. 

     

• (다) 패스워드 변경 및 확인 시 보안 적용

   

  • 패스워드 변경 시 현재 패스워드를 확인한 후 변경 사항을 적용한다. 

     

• (라) 패스워드 파일 접근통제 및 암호화 저장 여부 진단 

   

  • 응용프로그램에 저장된 패스워드 파일은 관리자도 알아볼 수 없도록 암호화된 형태로 저장한다.

• (3) 개발자 계정 관리 

  • (가) 추측 가능 및 Default 계정 사용 통제 애플리케이션 관리자 계정의 경우 "admin", "root", "administrator" 등 추측가능하 거나 디폴트(default) 계정을 사용하지 않도록 구현한다.

 

• (나) 불필요한 계정에 대한 주기적 검토 및 삭제 

   

• 일정 기간 동안 사용하지 않는 계정에 대한 일시 사용 중지 및 사용 중지 된 후 휴면 계정에 대한 삭제 조치를 한다.

 

• (4) 데이터 보안 관리 

   

  • (가) 주요 데이터 및 자료 파일 등의 DB 저장 유무 

     

    • 주요 데이터를 접근통제가 수행되는 DB에 저장한다. 

       

  • (나) 데이터의 보안등급 분류 설정 

     

    • 응용프로그램에서 사용되는 데이터에 대한 보안등급 설정 및 보안등급에 따른 보 안대책 수준을 구현한다. 

       

  • (다) 클라이언트와 서버 간의 데이터 암호화 전송 여부 

     

    • 서버와 개발자 간에 사용되는 연결 및 전송되는 자료의 보안성 강화를 위해 필요 시 암호화 전송을 구현한다. 

       

  • (라) 암호화 Key 관리 정책 

     

    • 데이터베이스에 자료 저장 시 암호화를 사용하였을 경우 Key 관리 정책 및 복구에 대한 안전성을 확인한다.

• (5) 응용프로그램 접근제어 관리 

  • (가) 개발자 그룹별 접근 권한 통제 

    • 응용프로그램의 개발자를 그룹별로 구분하고 접근 권한에 대한 등급을 설정하여 접근 권한을 관리한다. 

  • (나) 관리자 접근 통제 강력한 응용프로그램 서비스 관리자의 접근 통제를 실시한다(예: 응용프로그

    • 램 서버에서 관리자에 대한 접근 날짜, 접근 시간, IP 주소별로 통제 적용

  • (다) 다중 접속 권한 제한 

    • 단일 개발자 ID의 다중 온라인 세션(session) 생성을 제한한다

 

• (라) 인증절차를 우회한 접근통제 

   

  • 모든 응용프로그램 접근 방법에 대한 인증을 실시한다. 

     

• (마) 인가된 등급 이상의 정보에 대한 접근 통제 

   

  • 특정 수준의 정보에 대한 접근 권한을 부여받은 개발자는 해당 수준 또는 그 이하 의 정보에만 접근하도록 구현한다. 

     

• (바) 개발 시 사용된 Sample & Backup 코드 접근 제한 

   

  • 응용프로그램 개발 시 사용된 샘플 소스코드(sample source code) 및 백업코드 (backup code) 등에 대한 접근을 제한한다.

• (6) 로그 관리 및 접근 통제 

  • (가) 보안 등급별 로깅 설정(비밀/일반) 로그 관리 및 접근 통제를 위하여 보안 등급별 로그 방법을 설정한다. 

    • 1) 로그의 중요도에 따른 분류가 가능하도록 구성한다. 

    • 2) 정보의 비밀등급 설정에 따라 생성, 수정, 삭제, 조회 기능을 관리한다. 

    • 3) 분류정보에 따른 로그인 정보, 오류정보, 기밀정보 접근 기록은 별도 관리되 도록 구현한다. 

    • 4) 비밀 로그정보는 기밀정보 접근기록, 관리자 모듈 접근 정보, 콘텐츠 유료 보 생성 및 삭제 정보, 상거래 수행 정보 등을 포함하도록 구현한다.
      
      

 

• (나) 보안등급별 로그 보관기간 설정 

   

  • 모든 개발자 ID의 개발시스템 로그인 및 이용기록을 저장한다(개발자 ID, 단말 ID, 사용시간, 사용 정보명, 로그인 실패, 출력내역 등이 포함). 

     

• (다) 로그 접근 통제 

   

  • 1) 보안 담당자의 사전 승인이 없는 경우 응용프로그램의 로그파일에 대한 접근 을 제한한다. 

     

  • 2) 로그 파일에 대한 무결성 확보 및 백업된 로그파일은 수정이 불가능하도록 구현한다.

 

[3] 설계가 완료된 SW프로그램의 주요 취약점을 사전에 점검한다.

• 1. 설계가 완료된 SW프로그램의 정적 분석을 실시한다. 알려진 주요 취약점을 정적 분석을 실행하여 위험도를 예측한다. 

   

  • (1) XSS:Cross-site scripting 

     

    • 애플리케이션이 입력물/출력물 검증 부족으로 인해 클라이언트 쪽의 악성 코드 인젝션 (injection)이 일어나기 쉬운 사용자가 수정 가능한 파라미터를 포함하고 있는지 여부에 대해 검토한다. 

       

  • (2) 인젝션(Injection) 

     

    • 애플리케이션이 의도하지 않은 명령어를 수행하거나 허용되지 않은 데이터를 접근하 도록 조작하는 악성 문구를 주입하는 공격에 대해 모듈을 보호하도록 애플리케이션이 클라이언트 입력 파라미터를 검증하는지 여부를 검토한다. 

       

  • (3) 불안전한 직접적인 객체 참조 

     

    • 애플리케이션이 URL이나 형상(form) 파라미터로서 파일, 디렉토리, 데이터베이스 기록, 키 등의 내부 이행 객체에 대한 참조를 안전하지 않은 방법으로 제공하는지 여부를 검토한다. 

       

  • (4) 불안전한 암호 저장 

     

    • 클라이언트 쪽 애플릿과 HTML 소스 코드와 같은 공개적으로 접속 가능한 정보에서 회수할 수 있는 민감한 암호화 상세 정보 (암호화 알고리즘, 암호화 키 등)를 애플리케 이션이 제공하는지 여부를 검토한다

  • (5) URL 접근 제한 실패 

    • 애플리케이션이 모호한 URL(obscurity)이나 위장술(obfuscation)을 기반으로 기능을 제 한하는지의 여부를 검토한다. 

  • (6) 취약한 인증 및 세션 관리 

    • 인증 사용자의 ID를 추정할 수 있도록 인증과 세션 관리를 침해하는 공격 리스크를 최 소화할 수 있도록 인증 및 적절한 세션 관리를 올바르게 이행했는지 여부를 검토한다. 

  • (7) 사이트 간 요청 위조(CSRF: Cross-site request forgery) 

    • 특정 액션의 상세 사항을 예측하여 애플리케이션에 악의적인 요청을 위조하는 공격이 허용될 수 있는 예측 가능한 파라미터가 애플리케이션에 포함되어 있는지 여부를 검 토한다. 

  • (8) 잘못된 보안 설정 

    • 시스템 데이터 및 기능에 허가를 받지 않고 접근하여 시스템 전체가 침해되는 결과를 가져오는 공격을 방지할 수 있도록 애플리케이션이 적절히 설정되어 있는지 여부를 검토한다. 

  • (9) 불충분한 전송 레이어 보호 

    • 네트워크를 통해 전송되는 애플리케이션 데이터가 허용되지 않은 가로채기 (interception) 및 Man-in-the middle 공격을 방지할 수 있도록 적절히 안전한지 여부를 검토한다. 

  • (10) 검증되지 않은 리디렉팅(redirects) 및 포워드(forward) 

    • 사용자가 악성 웹 사이트로 리디렉팅 되는 것을 방지할 수 있도록 애플리케이션 페이 지 리디렉션 및 포워드를 검증할 수 있도록 통제를 이행했는지의 여부를 검토한다. 

  • (11) 애플리케이션 로직 결함 

    • 의도한 목적의 애플리케이션 로직이 악용되어 워크플로우나 정보를 변환, 혹은 우회하 거나, 조작하는 결과를 가져올 수 있는지 여부를 검토한다. 

  • (12) 인증 우회 

    • 애플리케이션을 악용하여 보안 통제를 우회해 내부 애플리케이션 기능에 직접적으로 접근하는 공격을 허용할 수 있는지 여부를 검토한다. 

  • (13) 권한부여(Authorization) 우회 

    • 권한 부여 메커니즘을 악용하여 악의적인 사용자가 특권을 강화해서 애플리케이션 기 능이나 사용자의 민감한 데이터에 비인가 접근을 허용할 수 있는지 여부를 검토한다.

 

[SW 개발 보안 테스트와 결함 관리]

[1] SW개발보안 테스트

• 1. SW개발보안 테스트의 결함 등급의 영향도와 긴급도 

   

• 보안테스트의 결함 등급은 보안의 영향도(impact)와 긴급도(urgency)에 따라서 측정된다. 

   

• (1) 주요관리 항목

   

  • (가) 높은 등급으로 할당된 보안결함 사고의 수 

     

  • (나) 전체 문제 수 대비 근본원인이 도출된 보안결함 수 

     

  • (다) 한번 만에 근본원인이 도출된 보안결함 수 

     

• (2) 세부 프로세스 주요 참여자 역할 

   

  • (가) 운영조직: 할당된 보안결함 근본원인 도출 

     

  • (나) 시스템/서비스 공급자: 할당된 보안결함 근본원인 도출 

     

  • (다) 문제 분석가: 할당된 보안결함 근본원인 도출 

     

  • (라) 문제관리 책임자: 보안결함 근본원인 도출 상태 점검

 

• 2. SW개발보안 테스트의 종류 

   

  • SW구현이 완료되면 조직의 보안정책의 적합 여부를 확인하여야 한다. SW시스템에는 기 본적으로 외부에서는 네트워크 환경, 내부에서는 OS와 DB, 애플리케이션이 설치되고 비즈니스 운영에서 생성되는 애플리케이션 데이터와, DB 데이터가 생성되는데 조직의 보안정 책의 기준에 합당한지 충분히 테스트 하고 결과는 검증되어야 하며 결과에 대한 증빙을 남겨 보안 감사에 대비한다. 

  • SW개발 단계에서 SW보안 테스트를 하여 취약점을 진단하는 방법은 다음과 같이 정적분 석과 동적 분석으로 구분할 수 있으며, 상호 보완적으로 선택할 수 있다.

 

• 3. SW개발보안 테스트의 일반 원칙 모든 보안 테스트의 직무는 이해관계가 긴밀하게 얽혀있으면 공정한 테스트가 불가능하다. 일반적으로 개발자와 운영자는 분리되어 테스트를 수행하고 평가하여야 한다. 운영 담 당자와 애플리케이션 개발자 및 보안 담당자는 서버보안 테스트 절차에 따라 보안 기능을 시험하고 결과를 검증한다. 

   

  • (1) SW보안 테스트 계획서에 따른 실시 

     

    • 시스템에 운영될 비즈니스와 관련된 애플리케이션 보안 설계 구현과정에서 제시된 추 가 요구 항목 및 최신 취약점 점검을 서버 보안 테스트 계획서에 따라 보안 기능을 테스트한다. 

       

  • (2) SW보안 테스트의 적정성 판단 

     

    • 보안 기능 테스트가 완료되면 보안 담당자는 평가결과를 이해관계자와 상호 검토하여 서버 보안 기능의 적절성 여부를 검토하고 결과를 상호 통보하게 된다. 

       

  • (3) SW보안 결과의 신뢰성 

     

    • 보안 평가자는 평가 절차에 따라 적절히 계획되고 실행되었는지, 평가결과가 신뢰할 수 있는 기술로 검증되었는지 다시 한번 확인한다. 

       

  • (4) SW보안결함발견 시 피드백 결과 확인

     

    • 보안 담당자 및 보안 평가자의 테스트 결과를 서버 담당자에게 피드백하여 문제가 있는 요구사항에 기능에 대한 보완이 이루어 질 수 있도록 조치를 취하게 하고, 필요 시 기술적인 제언을 수행한다

 

[2] SW개발보안 테스트에 따른 결함관리

• SW보안의 발생 결함을 체계적, 커뮤니케이션 자동화 구현 등을 통해 반복적이고 지속적인 테스트 수행 후 발생한 결함 제거 및 재발을 방지하여 고품질의 소프트웨어를 제공하는 활동 및 기법으로 정의한다. 

   

• 1. SW개발보안결함의 개요

   

  • 보안결함은 프로그램과 보안명세서와의 차이와 불일치이고 기대하는 보안품질의 결과와 실제 관찰 결과 간의 차이라고 정의된다. 즉 SW시스템이 사용자가 기대하는 타당한 보안 기대치를 만족하지 못하는 것을 의미한다. 

  • (1) SW보안결함의 종류 

    • SW보안결함의 종류는 기대치와 예상치를 기준으로 아래와 같이 분류할 수 있다.

    • SW보안결함 

      • 소프트웨어 제품의 보안품질이 정의된 특성과 일치하지 않는 모든 행위 

    • 발견된 보안결함 

      • 설치/운영되기 전에 발견된 소프트웨어 보안결함 

    • 잠재적 보안결함 

      • 설치/운영되는 환경에 전달된 소프트웨어 보안결함 

    • SW의 특이한 

      • 고장 잠재 보안결함들이 소프트웨어의 운영 중에 나타나서 발생하는 하나 이상의 이상 징후들의 집합 

  • (2) SW보안결함관리 프레임워크 

    • SW보안결함관리 프로세스와 프레임워크는 아래와 같이 표현될 수 있으며 개발 프로세스에 따라 단계별 결함활동을 수행 후 결함 이력을 DB에 저장하여 결함상태 추적과 모니터링 활동을 수시로 병행하게 된다.
      
      

 

• (3) SW보안결함관리 절차 

   

  • SW보안결함관리 절차는 관리계획을 기반으로 관리수행을 진행하고 최종 결과보고 단 계로 절차를 세분화할 수 있다.

 

• 2. SW보안결함분류와 심각도를 포함한 단위 테스트의 절차 및 산출물 

   

  • (1) 보안 테스트 계획서 작성 

     

    • 테스트 일정, 담당자, 담당자별 역할설정 및 테스트 수행 Guideline 테스트 전략, 대상 및 범위, 테스트 조직, 수행절차 및 진척, 결함관리, 단위테스트 목록, 결함관리계획(결 함 분류/결함 심각도/추적, 모니터링)애 관한 내용으로 테스트 계획서를 작성한다. 

       

  • (2) 보안 테스트 범위와 분석과 분할 

     

    • 테스트 범위에 대한 분석 및 업무 기능별 분할, Event/Activity별 분할을 실시한다. 

       

  • (3) 보안 테스트 시나리오의 작성 

     

    • 테스트와 검증이 필요한 다양한 시나리오를 기록하고, 테스트 ID, 시나리오명, 테스트 시나리오 내용을 통해 구성화면 목록, 상태(Pass/Fail)을 기록, 결함분류한다.

  • (4) 보안 테스트 시나리오 테스트케이스 작성 

    • SW보안 테스트 요건, 시나리오, 조건을 계획/구성, 테스트 단계, 대상시스템, 작성자, 시나리오명, 테스트ID, 테스트 케이스, 테스트 데이터(Input, valid/invalid data) 및 Action, 예상결과를 테스트 케이스에 반영하여 작성한다. 

  • (5) 보안 테스트 수행 

    • SW보안 테스트 Case/Data 기준으로 테스트 수행, Defect Report, 결함보고 및 시정조 치를 수행한다. 

  • (6) 보안 테스트 평가 

    • SW 보안 테스트 수행 결과에 대한 평가(정성적, 정량적 평가)를 실시한다. 

  • (7) 보안 테스트 결과보고 

    • SW 보안 테스트 수행이 완료됨에 따라 완료된 Test의 전반적인 내용이나 성과 결과를 기술한다

 

[연습문제]

• 응용프로그램 방식의 보안 구현의 고려사항이 잘못된 것은?

   

  • 개인정보 입력 시 암호화되어야 하는 범위를 결정한다. 

     

  • 소프트웨어 플랫폼을 확인하여 보안 모듈을 선택한다. 

     

  • 응용프로그램 방식에서의 암호화 부분은 텍스트로 전송되는 부분만을 암호화하여, 이미지와 같이 암호화가 불필요한 부분을 제외하여 적절히 암호화 적용부분 결정한다. 

     

  • 응용프로그램 방식의 보안 구축을 완료하기 전 적절한 테스트 시나리오를 통해 구축완료를 선포한다
    
    

• 패스워드 관리에 대해 잘못 설명한 것은? 

   

  • 패스워드 최소 길이 제한 패스워드의 최소 길이를 통제할 수 있도록 최소 패스워드 길이 값을 정의한다.

     

  • 사용자 개인 정보(주민등록번호, 휴대폰 번호 등)와 관련된 패스워드는 사용하지 못한다.

     

  • 동일한 문자 또는 숫자가 반복되는 패스워드는 사용하지 못한다.

     

  • 문자 또는 숫자만으로 구성된 패스워드는 사용할 수 있다.
    
    
    

 참고 문헌

[논문]

• 없음

[보고서]

• 없음

[URL]

• 없음

 

 문의사항

[기상학/프로그래밍 언어]

• sangho.lee.1990@gmail.com

[해양학/천문학/빅데이터]

• saimang0804@gmail.com

 

 

 

 

 

 

 

 

 

 

 

본 블로그는 파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있음