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

 정보

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

• 작성자     : 이상호

• 작성일     : 2020-05-12

• 설   명      :

• 수정이력 :

 

 

 내용

[SW 개발 보안 요구사항 명세와 설계]

[1] SW개발보안의 개요 

• SW개발보안은 해킹 등 사이버공격의 원인인 보안 취약점을 SW개발 단계에서 미리 제거 하고 SW개발에 따른 생명주기별 단계적으로 수행하고 개발 과정에서 보안 업무을 수행하며 안전한 보안요소를 만족하는 소프트웨어를 개발・운영하기 위한 목적으로 수행하는 개발 방법이다. 

   

• 1. SW개발보안의 3요소 

   

  • 소프트웨어 개발보안 구축하기는 정보보안의 세가지 요소인 기밀성(confidentiality), 무결성(integrity), 그리고 가용성(availability)을 지키고, 서버 취약점을 사전에 방지하여 외부 위협과 내부 위협으로부터 위험을 최소화하는 구축 방법을 말한다.

 

• (1) 소프트웨어 자산(Asset)과 관련된 상세 

   

  • 자산 조직의 데이터 또는 조직의 소유자가 가치를 부여한 대상 (서버의 하드웨어, 소프트웨 어와 기업의 중요 데이터) 

     

• (2) 위협원(Threat agents) 

   

  • 조직 자산의 파괴와 손해가 발생하는 행동을 할 수 있는 내·외부의 주체(해커, 내부 의 인가받지 않은 임직원, 단체, 자연재해) 

     

• (3) 위협(Threat) 

   

  • 조직의 자산에 대한 위협이 되는 위협원의 공격 행동 (해킹, 삭제, 자산의 불법적인 유 출, 위/변조, 파손) 

     

• (4) 취약점(Vulnerability) 

   

  • 위협이 발생하기 위한 사전 조건에 따른 상황(평문을 전송, 입력값을 검증하지 않음, 비밀번호를 공유하는 행위) 

     

• (5) 위험(Risk) 

   

  • 위협원이 취약점을 사용하여 위협 행동하여 자신에 나쁜 영향의 결과를 가져올 확률 과 영향도

 

[2] 소프트웨어 개발보안의 요구공학 프로세스

• 보안요구 공학은 크게 보안요구사항 개발과 보안요구사항 관리로 나눠지며 개념도는 아래 와 같다.

 

• 1. 소프트웨어 개발보안의 요구사항 개발 

   

  • (1) 소프트웨어 개발보안의 요구사항 도출 

     

    • 보안요구사항 도출은 조직의 이해관계자의 상호의견을 조율하고, 협의를 통해 요구사 항을 수집하고 수집된 요구사항을 정제하고 내용별로 분류한다. 이때 참조되는 산출물 은 제안서나 계약서, 과업지시서, 회의록, 사업 수행 계획서가 주로 참조된다.

       

  • (2) 소프트웨어 개발보안의 요구사항 분석 

     

    • 그 후에 보안요구사항을 내용별로 분류된 것을 토대로 분석에 들어가는데 요구사항 중에서는 실제로 구현하기 어렵거나 현시점에서 과도하게 비용 또는 인력이 소모되는 비용 효율적인 면을 고려하여 보안요구사항의 제약조건을 판별하게 된다. 만약 기술적 이나 비용적으로 당장 구현이 힘들더라도 비슷한 대안을 제시할 수 있다면 의견 제시 로 보안요구사항 분석서에 기술하여도 무방하다.

 

• (3) 소프트웨어 개발보안의 요구사항 명세 

   

  • 다음은 보안요구사항을 다른 사람이 알아보기 쉽도록 명세화 시킨다. 보안요구사항의 분석서를 통하여 요구사항 정의서가 도출되는데 내용은 소프트웨어 개발 시스템의 목 표 기술과 사업의 기능과 비기능적 요구사항이 명세되어야 한다

 

• (4) 소프트웨어 개발보안의 요구사항 확인과 검증 

   

  • 소프트웨어 개발보안요구사항 명세 작성이 완료되면 관계자들에게 요구사항이 맞는지 확인하고 검증하는 과정이 필요하다. 이때 이해 관계자들의 지식과 조직의 성숙도, 소 프트웨어 개발보안요구사항 문서와, 조직의 표준을 고려하여 소프트웨어 개발보안요구 사항 문제 보고서를 작성하게 된다. 그 보고서를 경영진 또는 중간관리자에게 승인을 받아 내용을 확정하는데 경영진 또는 중간관리자는 보고서의 문서화의 정도, 내용의 명확성, 간결하고 실제로 구현이 가능하고, 문제가 없는지 테스트가 가능하여야 하며, 향후 장애 등의 문제 발생 시 근본 원인을 파악할 수 있도록 추적성이 가능한 코드체 계를 통하여 내용 검토를 수행한 후에 검증하게 된다.

 

• 2. 소프트웨어 개발보안의 요구사항 관리

   

  • 비즈니스 환경 변화 또는 시간의 흐름에 따라 서버 보안요구사항은 변경될 수 있으며 서버 보안요구사항은 지속적으로 관리되고 갱신되어야 한다. 

     

  • 서버 보안요구사항의 관리는 이해관계자 간의 협상을 통해 기준을 정하고 상부의 정식 승 인 받아 변경을 수행해야 한다. 아무런 승인 없이 서버 보안요구사항을 변경하게 되면 시 간이 지나면 이력을 알 수 없기 때문에 관리를 철저하게 하고 서버 보안요구사항 명세서 와 함께 서버 보안요구사항 추적 매트릭스를 통해 산출물과 테스트 시나리오 등을 관리하도록 한다.

 

 

• (1) 소프트웨어 개발보안의 설계 

   

  • 소프트웨어 개발보안 설계의 시작단계는 소프트웨어 개발에 운영되고 개발되는 운영 애플리케이션의 조직의 사업방향에 맞는 보안 목적을 정의 하고 조직의 업무 현행 현 황 업무 파악과 응용 애플리케이션 개발과정에서 이행되고 적용되어야 하는 조직의 보안 정책을 검토하고 소프트웨어 개발보안 위험 분석 및 전사 조직에 적용되는 소프트웨어 개발보안 계획을 작성하는데 목적이 있다. 

     

  • (가) 소프트웨어 개발보안의 요구사항 

     

    • 반영 소프트웨어 개발보안의 분석 단계에서 파악된 소프트웨어 개발보안 요구사항 분석 서의 요구사항을 반영하여 소프트웨어 개발 설치 시 감지하지 못하는 보안 위험과 통제를 고려하여 소프트웨어 개발보안 설계를 작성한다. 소프트웨어 개발보안 설계서의 내용은 소프트웨어 개발의 기능과 OS, 애플리케이 션의 기본 설계와 상세 설계서를 작성하도록 한다.

  • (나) 소프트웨어 개발보안의 요구사항 설계 반영 

     

    • 소프트웨어 개발보안의 분석 단계에서 정의된 소프트웨어 개발보안 요구사항 분석 을 통해 나타난 항목을 검토한 뒤에 아래 사항을 고려하여 설계에 반영한다. 

       

      • 1) 소프트웨어 개발보안 계획이나 조직의 표준(기술, 비즈니스 요건)에 적합한지 확인한다. 

         

      • 2) 실제 소프트웨어 개발보안이 가능한지 가능성 여부를 판단한다. 3) 보안요구사항을 분석하여 소프트웨어 개발보안 설계에 적절히 반영한다.

• (다) 소프트웨어 개발보안의 환경 설계 반영 

   

  • 기술적인 구현 타당성이 검증되었고 확인되었다면 네트워크 보안을 검토하여 소프트웨어 개발과 네트워크 연결 시 문제가 발생하지 않는지 아래와 같은 사항을 검 토하여 설계에 반영한다. 

     

    • 1) 외부 사이버 공격으로부터 개발/운영 환경 보호를 위해 네트워크 보안환경을 구성한다. 

       

    • 2) 개발/운영에 필요한 네트워크를 분리하고 소프트웨어 개발도 분리하여 다른 접근 경로로 구성한다. 

       

    • 3) DMZ 구간에 설치될 소프트웨어 개발의 네트워크 접근과 소프트웨어 개발의 계정관리 체계를 점검하여 구성한다

 

• (2) 소프트웨어 개발보안 계획 수립 

   

  • 소프트웨어 개발보안의 계획의 단계는 다음 그림과 같이 시작 →분석 →설계 →구현 →시험 단계로 수행한다

 

[수행]

[1] 정보에 대한 보안항목을 환경 분석에 따라 법률적으로 검토한다.

• 소프트웨어 개발에 대한 보안항목의 식별을 위해 내·외부 환경 분석을 통하여 보안항목 을 분석하고 규제와 컴플라이언스 이슈제거를 위한 사전 항목을 식별한다. 또 소프트웨어 의 목적에 맞게 소프트웨어가 처리하는 정보의 분류를 조직 정보의 자산 가치에 따라 기 타 중요정보를 식별한다.

 

• 1. 내·외부환경 분석(법에 따른 제도와 규정 등)을 통해 보안 항목을 식별한다. 

   

  • 분석단계에서 정보와 조직의 정보처리 기능에 대해 식별해야 하는 항목작업이 우선적으로 수행되어야 한다. 보안요구사항은 법률적인 요구사항의 검토가 필수적이다. 전체 법 조항이 필요한 경우는 국가법령정보센터를 참조하여 검토하는데, 기업의 비즈니스 모델에 따라 규제 받는 법률의 내용은 다음과 같다.

     

  • 정보보호관련 법령 목록

     

  • 국가기밀보호 

     

    • 보안업무 규정, 군사기밀 보호법과 군형법 등 

       

  • 중요정보의 국외 유출 방지 

     

    • 산업기술의 유출 방지 및 보호에 관한 법률, 기술의 이전 및 사업화 촉진에 관한 법률, 민군겸용 기술사업 촉진법, 부정경쟁방지 및 영업 비밀 보호에 관한 법률 등

  • 전자서명 및 인증 

     

    • 전자서명법, 전자정부법 등 

       

  • 정보통신망과 정보시 스템의 보호추진 

     

    • 국가정보화기본법, 정보통신기반보호법, 정보통신망 이용촉진 및 정 보보호 등에 관한 법률, 전자정부법, 전자 문서 및 전자거래 기본법, 국가사이버안전관리 규정 등

       

  • 침해행위의 처벌 

     

    • 전자무역 촉진에 관한 법률, 형법, 정보통신기반 보호법, 정보통신망 이용촉진 및 정보보호 등에 관한 법률 

       

  • 개인정보보호 

     

    • 개인정보 보호법, 정보통신망 이용촉진 및 정보보호 등에 관한 법률, 신용정보의 이용 및 보호에 관한 법률 등

 

• (1) 보안 관련 법규를 검토한다. 

   

  • (가) 개인정보 보호법을 검토한다. 

     

    • 개인정보 처리 과정 상의 정보 주체와 개인정보 처리자의 권리, 의무 등을 검토하 여 소프트웨어 개발 요구사항에 충분히 반영한다. 

       

      • 1) 개인정보 고유식별 정보의 처리 제한 요구사항을 수집한다. 

         

        • 개인을 식별하는 고유한 식별정보(주민등록번호, 또는 여권번호, 개인의 운전면 허번호, 외국인의 외국인등록번호)를 처리하는 경우 그 정보가 분실, 도난, 유출, 변조 또는 훼손되지 않도록 암호화를 통하여 안전성을 확보하고 필요한 조치를 해야 한다. 

           

      • 2) 개인정보보호법 안전조치 의무화 요구사항을 반영한다. 개인정보가 분실, 도난, 유출, 변조 또는 훼손되지 않도록 조직내부의 보안관리 계획을 수립하고, 접속기록보관이 필요하기 때문에 안전성 확보를 위한 필요한 기술적, 관리적, 물리적 조치를 하여야 한다.

      • 3) 개인정보의 안전성 확보 조치 요구사항을 수집한다. 개인정보를 안전하게 저장, 전송할 수 있는 암호화 기술의 적용 또는 이에 상응 하는 조치가 필요하다

 

• (나) 정보통신망 이용촉진 및 정보보호 등에 관한 법률을 검토한다. 

   

  • 정보통신망을 통하여 수집, 처리, 보관, 이용되는 개인정보의 보호에 관한 규정을 검토하여 소프트웨어 개발 요구사항에 충분히 반영한다. 

     

    • 1) 개인정보의 보호조치 시행령 제 15조를 분석한다. 

       

      • 개인정보가 안전하게 저장, 전송될 수 있도록 보안조치를 하여야 하며, 비밀번 호 및 바이오정보(지문, 홍채, 음성, 필적 등) 단방향 암호화 저장, 개인의 주민 등록번호와 금융 계좌번호, 그리고 금융정보를 암호화하여 저장하고, 개인정보 와 인증정보를 송·수신하는 경우 보안이 강화된 서버 인프라 구축 등의 조치 와 그 밖의 검증된 암호화 기술을 이용한 보안 조치를 위한 요구사항 분석을 실시한다. 

         

    • 2) 개인정보의 보호조치 법률 제 28조를 분석한다. 

       

      • 개인정보를 취급할 때에는 개인정보의 분실, 도난, 누출, 변조 또는 훼손을 방지 하기 위해 기술적, 관리적 조치를 하여야 하며, 개인정보를 안전하게 저장, 전송 할 수 있는 암호화 기술 등을 이용한 보안조치를 취해야 한다

    • 3) 개인정보의 암호화를 분석한다. 

       

      • 비밀번호, 바이오정보는 복호화되지 않도록 일방향 암호화하여 저장하고, 주민 등록번호와 신용카드 번호 그리고 은행 계좌번호에 대해서는 안전한 암호화 알 고리즘으로 암호화하여 저장한다. 

         

      • 서비스를 제공하는 서버 단에서 SSL(Secure Socket Layer) 인증서를 통하여 송·수신하는 정보를 암호화하여 송·수신하며, 서비스를 제공하는 서버에 암호화 응용프로그램을 설치하여 전송하는 정보를 암호화하여 송·수신하는 기능의 보안조치를 취해야 한다.

• (다) 신용정보의 이용 및 보호에 관한 법률 개인 신용정보의 취급 단계별 보호조치 및 의무사항에 관한 규정을 검토하여 소프트웨어 개발 요구사항에 충분히 반영한다.

 

• (라) 위치정보의 보호 및 이용 등에 관한 법률 

   

  • 개인위치정보 수집, 이용, 제공 파기 및 정보주체의 권리 등 규정을 검토하여 소프트웨어 개발 요구사항에 충분히 반영한다. 

     

• (마) 표준 개인정보보호 지침 

   

  • 조직의 표준 개인정보 지침은 개인정보 취급자와 개인정보 처리자가 준수해야 하는 개인정보의 처리에 관한 기준을 준수하고, 개인정보 침해의 유형 및 예방조치 등에 관한 세부사항 규정을 검토하여 소프트웨어 개발 요구사항에 충분히 반영한다.

     

• (바) 개인정보의 안전성 확보 조치 기준 

   

  • 개인정보 처리자가 개인정보를 처리함에 있어서 분실, 도난, 유출, 변조, 훼손되 지 아니하도록 안전성을 확보하기 위해 취해야 하는 세부적인 기준 규정과 개인 정보 위험도 분석기준과 개인정보 처리시스템의 보호수준을 진단하여 암호화에 상응하는 조치 필요여부를 판단할 수 있는 기준을 규정을 검토하여 소프트웨어 개발 요구사항에 충분히 반영한다.

     

• (사) 개인정보 영향평가에 관한 기준 

   

  • 개인정보의 영향평가 수행을 위하여 공신력 있는 평가기관의 지정 및 영향평가의 절 차 등에 관한 세부 기준 규정을 검토하여 소프트웨어 개발 요구사항에 충분히 반영한다

• (2) 소프트웨어 개발 요구사항 관련 특정 IT기술 관련 규정과 법률이 있는지 조사한다. 

   

  • (가) RFID 프라이버시 보호 가이드라인 

     

    • RFID 활용 시 개인정보보호 조치 사항을 검토하여 소프트웨어 개발 요구사항에 충 분히 반영한다.

       

  • (나) 위치정보의 보호 및 이용 등에 관한 법률 

     

    • 개인정보에서 실시간 개인의 위치정보 수집과 서비스 제공에 필요한 정보를 가공 하거나 이용하는 경우, 개인정보보호 조치 사항을 검토하여 소프트웨어 개발 요구 사항에 충분히 반영한다.

       

  • (다) 위치정보의 관리적, 기술적 보호조치 권고 해설서 

     

    • 지문, 홍채 등 생체정보 수집, 이용 시 개인정보보호 조치 사항을 검토하여 소프트 웨어 개발 요구사항에 충분히 반영한다. 

       

  • (라) 바이오정보 보호 가이드라인 

     

    • 새로운 컨텐츠 서비스 이용하고 제공하는 경우 개인정보 침해사고 예방을 위한 준 수사항을 검토하여 소프트웨어 개발 요구사항에 충분히 반영한다. 

       

  • (마) 뉴미디어 서비스 개인정보보호 가이드라인

     

    • 뉴미디어 서비스 이용하고 뉴미디어 서비스를 제공 시 개인정보 침해사고 예방 을 위한 준수사항을 검토하여 소프트웨어 개발 요구사항에 충분히 반영한다

• 2. 정보의 자산 가치에 따라 기타 중요정보를 식별한다. 

   

  • (1) 조직의 정보 자산 가치에 따른 중요한 자산의 정보 식별 소프트웨어 시스템이 처리하는 정보는 법적인 의무사항으로 필수적인 결함제거를 위 한 안전조치가 필요한 정보들 이외에도 물리적이고, 기술적으로 접근하거나 접근되는 허용되는 범위와 정보유출이 발생하는 경우, 예상되는 피해를 기준으로 보안등급을 결 정하고 조직의 정보의 자산 가치를 기준으로 중요정보를 식별하고, 분류하며, 법적의무사항에 준하는 보안강도를 적용한다

 

[2] 보안항목의 요구사항을 수집한다.

• 보안요구사항 수집을 통하여 다양한 관계자들의 의견을 청취하여 문서로 분류하고 비슷한 내용은 서로 그룹핑을 하여 요구사항을 단순화시킨 후 단순화시킨 내용을 다시 관계자들의 확인을 거쳐 내용검증을 통해 요구사항을 분류하고 체계화시킨다. 서버 보안요구사항은 서버의 보안 안정성을 확보하기 위한 기초 데이터로서 내/외부 위협으로 부터 주요 자산을 보호하는데 목적이 있다.

 

• 1. 보안관련 법률검토 요구사항에 의한 개발 환경의 계획과 통제에 관한 정보를 식별한다. 

   

  • 보안 법률검토에 의한 보안의 목적과 목표 설정 이행 시스템에 대한 정확한 정보를 식별 하여 보안요구사항을 분석할 수 있도록 파악한다. 

     

• 2. 소프트웨어 개발 PM(project manager)은 보안요구사항을 분석하여 수행 계획을 수립한다. 

   

  • 보안 설계서의 작업 준비로 보안 환경에 대한 자료 수집과 자료 정리에 따라 작업을 할당 하고 역할과 책임을 분류한다. 그 이후 작업 실시에 따른 일정별 작업 계획을 수립하고, 보안 환경 구축에 필요한 과업별 작업 카드 작성 및 기록과 보고체계를 구축한다.

• 3. 보안 환경의 적용 기술을 검토한다. 

   

  • 보안 환경의 요구사항 수집과 현행 시스템의 목표를 바탕으로 보안 환경의 구축을 위해 구체적으로 필요한 적합한 환경 기술, 인력과 인력의 기술수준, 조직의 보안 성숙도를 기 반으로 스펙(spec)을 기술하고 검토한다. 

     

  • (1) 보안 환경의 요구사항 이행 방안 

     

    • (가) 보안 환경 설계서의 요구사항 정의에 의해 요구사항에 대한 식별을 수행하고 각 요구사항의 테스크(task)에 대한 의존도와 독립성에 대한 검토를 수행한다. 

       

    • (나) 각 요구사항의 항목별로 하부 요구사항을 구체적으로 어떻게 구현할 것인지 세부 적인 도출을 수행한다.

 

• (2) 보안 환경의 구축 가능한 기술에 대한 참조 기술 목록을 검색한다. 

   

  • 보안 환경 설계서의 정의된 요구사항의 세부 이행 방안에 대한 각종 참조 기술을 검 색하고 보안 설계서의 이행 방안에 따른 각각 적용해야 하는 참조 기술을 별도로 정 의하여 보안 환경의 구축을 수행하고 참조 기술을 갱신한다. 

     

• (3) 보안 환경의 참조 적용 기술에 대한 적용 가능성을 검토한다.

   

  • (나) 구체적으로 해당 참조 기술을 사용하는 방법, 해당 참조 기술을 이용하기 위한 적용 가능성을 검토한다.

 

[SW 개발 보안 환경구축 일정계획 수립]

[1] 보안성이 강화된 응용프로그램 구현을 위한 환경의 구축

• 보안성이 강화된 응용프로그램 구현을 위한 환경은 대상이 되는 시스템을 개발 환경에 배 포하기 위해 사용되는 취약점 진단 도구, 취약점 진단 과정 중 대상 시스템을 모니터링 하고 결함을 추적하고 관리하기 위한 결함 관리 시스템 등으로 구성된다. 

   

• 1. 보안취약점 환경구축(Set up Security vulnerability Environment) 기능 취약점 진단을 수행하기 위해 필요한 서버, 스토리지 및 네트워크 환경은 아래와 같은 역 할을 실시한다.

   

  • (1) 대상 시스템을 테스트 환경에 배포 

     

  • (2) 보안 취약점 점검에 필요한 진단도구와 모니터링 툴을 설치 관리 

     

  • (3) 보안 취약점 진단하는 환경 설정 정보를 문서화 명세 관리

 

• 2. 취약점 모니터링 환경(Monitor Environment) 기능 

   

  • (1) 보안 취약점 진단 진행 중 보안 취약점 진단 환경 인프라와 대상 시스템에 대한 모니터링 수행 

     

  • (2) 보안 취약점 진단 진행 중 환경에 대한 모니터링 정보를 저장

 

[2] 보안성이 강화된 응용프로그램 구현을 위한 일정 계획의 수립

• 보안이 강화된 소프트웨어 개발 구축을 위해 개발 전략과 계획은 실제 발주 전 구매 혹은 계약 이전에 수립하며 조직의 보안 정책을 일정 계획에 반영해야 한다. 그리고 전략 및 계획 수립 과정은 보안이 강화된 소프트웨어 개발에 관한 일정, 그리고 실행을 위한 역할과 책임을 명시하며 개발 결정을 위해 포함되어야 할 내용으로 아래와 같은 것이 있다. 

   

• 1. 일정 계획을 위한 보안 전문가를 선정한다. 개발 부서에서는 개발을 위한 모든 과정(계획, 요구사항 분석, 도출, 프로그램 소스 코드 선택, 계약과 발주, 프로젝트 관리 등)은 지식이 풍부하고, 동일 업무에 경험이 있는 공신력 있는 보안 전문가와 보안 실무자를 통해 수행될 수 있도록 해야 한다.

• 2. 일정 계획을 위한 보안 범주를 식별한다. 

   

  • 조직의 보안 범위는 개발되는 시스템의 데이터와 정보처리시스템을 위협하는 사고의 잠재 적 파급 효과를 기반으로 조직의 보안요구사항을 도출하고 선택하고 내용은 일정에 반영 한다. 

     

• 3. 보안요구사항을 분석한다. 

   

  • 중요 보안고려사항뿐 아니라 소프트웨어 개발자와 공급자 선택, 조직의 각 주요 부서 간 의 역할 및 책임, 전사적인 프로젝트 관리 등에 대한 사항이 기술되어야 한다. 

     

• 4. 보안성이 강화되었는지 취약점 점검과 함께 독립적인 테스트 계획을 기획한다. 

   

  • 보안이 강화된 소프트웨어 구축, 안정성 평가 기능과 특별한 요구사항이 있는지 직간접으로 확인을 위한 취약점 점검 계획이 기술되어야 한다.

 

[수행]

[1] 보안성이 강화된 응용프로그램 구현을 위한 환경을 구축한다.

• 시스템으로부터 실행 가능한 프로그램에 대하여 설계된 보안 취약점 시나리오 케이스를 기반으로 취약점 점검을 수행하기 위한 취약점 점검 환경을 구축한다. 이 구축된 취약점 점검 환경에서 취약점 점검 계획서에 정의된 취약점 점검 환경 및 자원을 설정하여 취약 점 점검 수행을 준비하는 과정이다.

   

• ★ 소프트웨어 보안계획의 장점 

   

  • 허용되지 않는 위험을 우선적으로 해결 

     

  • 개발자가 중단을 최소화하여 안전한 소프트웨어를 만들 수 있는 길이 열리므로 생산성이 향상 

     

  • 특정 인물이나 그룹에게 소프트웨어 보안 위험을 감소시켜야 하는 책임을 부여하여 최선을 다해야 하는 환경을 조성 

     

  • 공동의 우선순위와 책임, 계획을 기반으로 보안 팀과 개발 팀 사이에 공식적인 협업의 장을 마련하여 혼란을 줄이고 모두가 효율적으로 협력

  • 제품 관리자, 설계자, 개발자, 테스터, 그 외 모든 이해관계자가 참여한 가운데 소프트웨어 보안요구사항을 문서화하고 조율하여 조직 차원의 합의도출 

     

  • 내부 팀과 외부 벤더 등 소프트웨어 공급망에 관여하는 모든 사람에게 일관된 목표를 제시 하므로, 시작점이 어디든 모든 소프트웨어가 안전하게 구축될 것으로 확신 

     

  • 정책, 표준, 도구, 전문가 등 모든 소프트웨어 보안 요구를 처리하는 ‘전문가 조직’을 구 성하여 모두가 원하는 해답을 얻고 기술력을 향상할 수 있는 거점을 제공 

     

  • 성공 여부를 측정하고 고객, 파트너, 이사회에 전달

     

  • 소프트웨어 개발 체인의 모든 이해 관계자와 꾸준하게 접촉하고 교육을 제공하여 보안을 중 시하는 문화를 육성 

     

  • 개발 팀의 변화하는 요구를 반영하는 동시에 위험을 관리

     

• 1. 취약점 점검 환경 분석서 입력물 

   

  • (1) 취약점 점검 계획서 

     

  • (2) 취약점 점검 케이스 설계 명세서 

     

• 2. 도구 및 기법 

   

  • 취약점 점검 환경 분석서를 식별하기 위한 여러 도구 및 기법을 소개한다. 

     

  • (1) 취약점 점검 환경 정보 수집 취약점 점검 조직들로부터 취약점 점검 환경에 대한 정보를 얻기 위한 기법을 사용하고 델파이 기법을 주로 사용한다. 

     

    • (가) 시스템 담당자 정보 

       

      • 시스템이 어떻게 구성될 것인지에 대한 종합적인 정보를 얻어야 한다. 취약점 점검 이 왜 필요한지, 어떤 종류의 취약점 점검을 수행하여야 하는지, 취약점 점검 담당 자 정보를 적용한다. 

         

    • (나) DB 담당자 정보 

       

      • 시스템 환경 구성에 필요한 DB의 구성과 취약점 점검 수행 시 필요 데이터의 종류 와 출력값 및 입력값에 대한 자문을 얻는다.

         

    • (다) 개발 담당자 정보 

       

      • 개발환경, 아키텍처, 개발언어, 성능목표 지수 등에 대한 정보를 취득한다. 

         

    • (라) 업무 담당자 정보 

       

      • 사용자가 주로 사용하는 업무에 대한 가이드와 구현될 향후 시스템에 대한 정보를 얻는다. 

         

    • (마) 기타 Key Man 정보 

       

      • 프로젝트를 수행하면서 발생할 수 있는 이슈에 대한 해결이 가능한 Key Man에 대 한 정보를 수집한다.

         

  • 3. 취약점 점검 계획서, 명세서 검토 

     

    • (1) 취약점 점검 계획서 

       

      • 취약점 점검 활동의 범위, 접근 방법, 자원, 일정 등에 대해 정의되어 있으며, 취약점 점검 항목, 취약점 점검 수행이 되어야 하는 항목, 수행되는 작업, 해당 작업에 대한 개인별 역할과 책임, 계획과 관련된 리스크 등을 식별한다.

 

• (2) 취약점 점검 설계 명세서 

   

  • 취약점 점검 접근 방법을 상세화하고, 설계 시 포함된 특성과 해당 특성에 대한 취약 점 점검 활동, 취약점 점검 활동을 완료하기 위한 취약점 점검 케이스 및 취약점 점검 절차, 각 특성에 대한 성공과 실패 기준 등을 식별한다. 

     

• (3) 취약점 점검 케이스 명세서 

   

  • 취약점 점검 케이스 명세서는 입력으로 사용된 실제 입력값과 그에 따른 예상 출력결 과를 문서화한 것이며, 취약점 점검 케이스 사용에 필요한 취약점 점검 절차상의 제약 사항을 식별한다

 

• (4) 취약점 점검 절차 명세서  

   

  • 취약점 점검 절차 명세서는 관련 취약점 점검 설계를 수행하기 위해, 정의된 취약점 점검 케이스를 수행하고, 취약점 점검 절차는 단계별로 따라야 하는 내용과 외부 환경 의 상세 내용을 식별하고 시스템을 운영하기 위한 모든 단계를 식별한다. 

     

• (5) 취약점 점검 목록 분석 

   

  • 과거 유사한 취약점 점검 활동에서 취약점 점검 분석서를 식별 시 사용하였던 체크리 스트나 점검 목록을 분석하여 식별할 수 있는 장점이 있는 반면, 체크리스트나 점검 목록에 누락된 내용은 식별할 수 없는 단점이 있다. 

     

• (6) 가정 분석 

   

  • 취약점 점검은 결과에 대한 가정을 바탕으로 계획을 세우기 때문에, 가정이 부정확하 거나 불일치, 불완전할 경우 취약점 점검 실패가 발생할 수 있다. 

     

• (7) 도식화 기법 

   

  • 조직 업무 프로세스, 인과관계도, 시스템 또는 프로세스 흐름도, 영향 관계도를 통해 취약점 점검 환경 분석을 수행한다.

• 4. 산출물 

   

  • 취약점 점검 환경 구축의 산출물은 취약점 점검 환경 설치 및 명세서로 내용은 다음과 같다.

 

[2] 보안성이 강화된 응용프로그램 구현을 위한 일정 계획을 수립한다.

• 1. 시작단계로 조직의 개발 업무 현황 수집하고 보안등급으로 구분한다. 

   

  • 실제로 운영되는 업무를 보안 규정에 맞는 요소별 보안 등급으로 구분한다

 

• <요소별 SW개발보안 등급>

   

  • 보안요소 

     

  • 조직의 보안기준에 따른 등급 구분 

     

  • 기밀성 

     

  • 고객비밀, 매우 극비, 중간적인 비밀, 대외비, 일반정보 

     

  • 무결성 

     

  • High, Middle, Low 

     

  • 가용성 

     

  • 1분, 시간, 1일, 1주, 1달

 

• 2. 시작단계로 조직의 업무 현황을 파악한다. 

   

  • 다음과 같은 소프트웨어 보안약점 유형을 미리 파악하여 코딩 시 실수하지 않도록 숙지하고 추후 보안약점 발생 시에 대비하여 보안대책을 강구한다.

     

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

     

    • 개발되는 프로그램 입력 값의 사전적으로 검증이 누락이 되는 부적절한 검증, 입력 데 이터의 부적절한 형식값(parameter)지정으로 인해 발생할 수 있는 보안약점으로 SQL 삽입, 크로스사이트 스크립트(XSS) 등의 공격을 유발할 수 있다

 

• (2) 보안기능 

   

  • 보안기능(사용자 인증, 내·외부 접근제어, 암호화, 기밀성, 사용자와 운영자 등의 권한 관리 등)을 적절하지 않게 구현하는 경우 발생할 수 있는 보안약점으로 적절한 인증 없는 중요기능 허용, 부적절한 인가 등이 포함된다. 

     

• (3) 시간 및 상태 

   

  • 정보처리를 실시하는데 시간적으로 병렬이나 동시에 실행을 지원하는 병렬시스템, 다 수의 프로세스가 수행되는 동작 환경에서 수행시간과 처리 상태를 적절하게 관리하지 못하여 발생가능성이 있는 보안 취약점이다. 

     

• (4) 에러처리 

   

  • 프로그램 실행 시 에러가 발생하여 에러를 예외 처리하지 못하거나, 충분하게 처리하 지 못하고, 에러 발생 시 에러 정보에 시스템의 취약점을 추론할 수 있는 중요한 정보 (시스템 인프라와 프로그램 정보, 상세한 에러 처리 내역 등)가 포함될 때 발생할 수 있는 취약점으로서 에러 처리를 적절하게 관리하지 못하여 발생하는 보안약점이다.

• (5) 코드오류 

   

  • 프로그램형(type) 변환하는 경우 발생하는 오류, 서버의 리소스 자원(메모리 등)의 부적 절한 반환(버퍼 오버플로우) 등과 같이 개발자가 흔하게 실수 하는 프로그램 오류로 인해 발생되는 보안 취약점이다. 

     

• (6) 캡슐화 

   

  • 외부에 은닉이 필요한 중요한 데이터와 필요한 기능성을 충분하지 못하게 캡슐화하였 을 때 인가되지 않은 사용자에게 데이터 유출, 권한문제 등이 발생할 수 있는 보안취 약점이다.

     

• (7) API 오용 

   

  • 서비스에서 제공되는 이용에 반하는 방법으로 API를 이용하거나 보안에 취약한 API를 오용하여 발생할 수 있는 보안 취약점이다.

• 3. 응용프로그램 개발 환경 및 구현 계획을 수립한다. 

   

  • (1) 개발 환경 구현

     

  • (2) 응용프로그램 구현 계획

• 4. 보안에 적용될 조직의 정책을 검토한다. 

   

  • (1) 보안 정책을 검토한다.

     

  • (2) 등급과 정책을 결정하였으면 보안계획을 수립한다.

     

  • (3) 등급과 정책을 결정하였으면 보안계획을 수립한다.

 

[연습문제]

• 정보보안의 세가지 요소가 아닌 것은?

   

  • 기밀성(confidentiality)

     

  • 무결성(integrity)

     

  • 가용성(availability

     

  • 효율성(efficiency)

 

• 요소별 SW개발보안 등급의 설명이 잘못된 것은?

   

  • 보안요소: 조직의 보안기준에 따른 등급 구분 

     

  • 기밀성 : 고객비밀, 매우 극비, 중간적인 비밀, 대외비, 일반정보 

     

  • 무결성 : 대,중,소

     

  • 가용성 : 1분, 시간, 1일, 1주, 1달

 

 참고 문헌

[논문]

• 없음

[보고서]

• 없음

[URL]

• 없음

 

 문의사항

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

• sangho.lee.1990@gmail.com

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

• saimang0804@gmail.com

 

 

 

 

 

 

 

 

 

 

 

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