3.2 Relevant Tasks Defined and Supported

오픈소스 보안 보증 프로그램이 효과적으로 운영되기 위해서는, 관련된 모든 작업이 명확하게 정의되고, 필요한 자원이 적절하게 할당되어야 합니다. 이는 프로그램 운영에 필요한 인력, 예산, 그리고 기술적인 전문 지식을 확보하고, 프로그램의 지속적인 개선을 지원하는 데 필수적입니다.

3.2.1 Access (접근성)

타사에서 조직의 소프트웨어에 영향을 미치는 알려진 취약점에 대해 문의할 수 있는 접근성을 제공하는 것은, 투명성을 높이고, 커뮤니티와의 협력을 강화하며, 잠재적인 보안 문제를 신속하게 해결하는 데 매우 중요합니다.

3.2.1.1 공개적으로 볼 수 있는 취약점 문의 방법

ISO/IEC 18974

• 4.2.1.1: Publicly visible method to allow third parties to make known vulnerability or newly discovered vulnerability enquires (e.g., via an email address or web portal that is monitored by program participants);
• 4.2.1.1 제3자가 알려진 취약점 또는 새로 발견된 취약점에 대한 문의를 할 수 있도록 공개적으로 볼 수 있는 방법 (예: 프로그램 참여자가 모니터링하는 이메일 주소 또는 웹 포털)

Self-Certification Checklist

• We have a method to allow third parties to make Known Vulnerability or Newly Discovered Vulnerability enquires (e.g., via an email address or web portal that is monitored by Program Participants);
• 제3자가 알려진 취약점 또는 새로 발견된 취약점에 대한 문의를 할 수 있는 방법(예: 이메일 주소 또는 웹 포털)이 있습니다.

조직은 누구나 쉽게 접근할 수 있는 방법으로, 소프트웨어의 취약점에 대한 정보를 제공할 수 있도록 해야 합니다. 이는 조직의 웹사이트, 보안 관련 페이지, 또는 별도의 버그 바운티 플랫폼 등을 통해 구현할 수 있습니다. 중요한 것은, 정보 제공 방법이 명확하고, 쉽게 찾을 수 있어야 하며, 지속적으로 모니터링되어야 한다는 점입니다.

구현 방법 및 고려사항

• 전용 이메일 주소:
  • security@example.com과 같이, 취약점 보고를 위한 전용 이메일 주소를 생성하고, 웹사이트에 공개합니다.
  • 이메일 주소는 보안팀 또는 관련 담당자가 지속적으로 모니터링해야 합니다.
• 웹 기반 보고 양식:
  • 취약점 보고에 필요한 정보(예: 소프트웨어 이름, 버전, 취약점 설명, 재현 방법)를 입력할 수 있는 웹 기반 보고 양식을 제공합니다.
  • 보고 양식은 사용하기 쉽고, 명확한 안내 문구를 포함해야 합니다.
• 보안 페이지:
  • 조직의 보안 정책, 취약점 보고 절차, 그리고 관련 연락처 정보를 포함하는 보안 페이지를 웹사이트에 게시합니다.
  • 보안 페이지는 쉽게 찾을 수 있도록, 웹사이트 메인 페이지에 링크를 제공합니다.
• 버그 바운티 프로그램:
  • 외부 보안 전문가에게 조직의 시스템을 테스트하고, 취약점을 발견하도록 장려하는 버그 바운티 프로그램을 운영합니다.
  • 버그 바운티 프로그램은 취약점 보고에 대한 보상을 제공하고, 연구자들의 참여를 유도합니다.

예시

• “저희 회사의 제품에서 보안 취약점을 발견하신 경우, security@example.com으로 연락주시기 바랍니다. 자세한 내용은 보안 페이지를 참조하십시오.” 와 같은 문구를 웹사이트에 게시합니다.
• 취약점 보고 웹 양식에는 다음과 같은 항목을 포함합니다.
  • 보고자 정보 (이름, 이메일 주소)
  • 영향 받는 제품 및 버전
  • 취약점 설명
  • 재현 단계
  • 증거 자료 (스크린샷, 로그 파일 등)

문서화 방안

오픈소스 정책 내 아래와 같이 외부 문의 대응 시 보안취약점에 대한 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

3.2.1.2 취약점 문의 대응 내부 절차

ISO/IEC 18974

• 4.2.1.2: An internal documented procedure for responding to third party known vulnerability or newly discovered vulnerability inquiries.
• 4.2.1.2 제3자의 알려진 취약점 또는 새로 발견된 취약점 문의에 응답하기 위한 내부 문서화된 절차가 존재합니다.

Self-Certification Checklist

• We have an internal documented procedure for responding to third party Known Vulnerability or Newly Discovered Vulnerability inquiries.
• 외부 문의에 대한 내부 대응 절차가 문서화되어 있습니다.

외부에서 취약점 문의가 접수되었을 때, 조직 내부에서 체계적이고 효율적으로 대응하기 위한 절차를 마련하는 것은 매우 중요합니다. 이 절차는 문의 접수, 분석, 해결, 그리고 보고 과정 전반을 아우르며, 각 단계별 책임자와 기한을 명확히 정의해야 합니다. 또한, 정보 보안 및 법적 책임을 고려하여, 민감한 정보를 안전하게 처리하고 공유할 수 있도록 해야 합니다.

구현 방법 및 고려사항

• 대응 팀 구성:
  • 취약점 문의를 접수하고 처리할 책임 있는 팀 또는 담당자를 지정합니다.
  • 대응 팀은 보안 전문가, 개발자, 그리고 법률 담당자 등을 포함할 수 있습니다.
• 프로세스 정의:
  • 취약점 문의 접수, 분류, 분석, 해결, 그리고 보고 단계를 포함한 전체 프로세스를 문서화합니다.
  • 각 단계별 책임자와 기한을 명확하게 정의합니다.
• 심각도 평가 기준:
  • 취약점의 심각도를 평가하기 위한 기준을 마련합니다.
  • CVSS (Common Vulnerability Scoring System) 점수를 활용하여 취약점의 심각도를 객관적으로 평가할 수 있습니다.
• 대응 절차:
  • 취약점의 심각도에 따라 다른 대응 절차를 마련합니다.
  • 고위험 취약점에 대해서는 즉시 대응하고, 저위험 취약점에 대해서는 모니터링 또는 장기적인 해결 방안을 고려합니다.
• 커뮤니케이션 가이드라인:
  • 취약점을 보고한 사람에게 진행 상황을 알리고, 필요한 정보를 요청하는 방법에 대한 가이드라인을 마련합니다.
  • 고객과의 소통은 투명하고 신속하게 이루어져야 합니다.

구체적인 절차 예시

1. 접수: security@example.com으로 접수된 취약점 문의는 보안팀에서 확인하고, 접수 번호를 부여합니다.
2. 분류: 보안팀은 취약점의 유형과 영향을 받는 시스템을 분석하고, 심각도를 평가합니다.
3. 분석: 개발팀은 취약점의 원인을 분석하고, 해결 방안을 모색합니다.
4. 해결: 개발팀은 취약점을 해결하기 위한 코드를 수정하고, 테스트를 수행합니다.
5. 검증: QA팀은 수정된 코드에 새로운 취약점이 없는지 확인하고, 기존 취약점이 해결되었는지 검증합니다.
6. 보고: 보안팀은 취약점 해결 결과를 보고하고, 관련 문서를 업데이트합니다.
7. 통보: 보안팀은 취약점을 보고한 사람에게 해결 결과를 통보합니다.

문서화 방안

오픈소스 프로세스 내 외부 문의 대응 절차에 보안취약점 대응 부분을 추가합니다. (참고 : 오픈소스 프로세스 템플릿)

3.2.2 Effectively Resourced (효과적인 자원 할당)

오픈소스 보안 보증 프로그램을 성공적으로 운영하기 위해서는, 단순히 정책과 절차를 수립하는 것만으로는 충분하지 않습니다. 이러한 정책과 절차가 실제로 효과를 발휘하기 위해서는, 프로그램에 필요한 인력, 예산, 그리고 기술적인 전문 지식을 적절하게 확보하고 할당해야 합니다. 이는 프로그램의 지속 가능성을 보장하고, 변화하는 위협 환경에 효과적으로 대응할 수 있도록 하는 데 매우 중요합니다.

3.2.2.1 프로그램 역할 식별 문서

ISO/IEC 18974

• 4.2.2.1: Document with name of persons, group or function in program role(s) identified;
• 4.2.2.1 프로그램 역할에 지정된 개인, 그룹 또는 기능의 이름이 포함된 문서.

Self-Certification Checklist

• We have documented the people, group or functions related to the Program.
• 프로그램 관련 인물, 그룹, 또는 기능을 문서화했습니다.

프로그램 역할 식별 문서는 오픈소스 보안 보증 프로그램의 성공적인 운영을 위한 초석과 같습니다. 이 문서는 프로그램에 참여하는 모든 이해관계자들이 각자의 역할과 책임을 명확히 이해하도록 돕고, 효율적인 협업과 의사소통을 가능하게 합니다. 또한, 책임 소재를 명확히 함으로써, 프로그램 운영 과정에서 발생할 수 있는 혼란과 책임을 회피하는 상황을 방지합니다.

구현 방법 및 고려사항

1. 포괄적인 역할 정의:
   • 프로그램 운영에 필요한 모든 역할을 식별하고, 각 역할의 목표, 책임, 그리고 권한을 명확하게 정의합니다.
   • 프로그램 관리자, 보안 전문가, 법률 담당자, 개발자, 그리고 운영 담당자 등 다양한 역할을 고려합니다.
2. 책임 할당:
   • 각 역할에 적합한 담당자 또는 팀을 지정하고, 책임과 권한을 명확하게 부여합니다.
   • 담당자는 해당 역할에 필요한 전문 지식과 경험을 갖추고 있어야 합니다.
3. RACI 매트릭스 활용 (선택 사항):
   • RACI (Responsible, Accountable, Consulted, Informed) 매트릭스를 활용하여 각 역할의 책임을 더욱 명확하게 정의할 수 있습니다.
   • RACI 매트릭스는 각 작업에 대해 누가 책임을 지고, 누가 실행하며, 누가 협의하고, 누가 정보를 제공받는지 명확하게 보여줍니다.
4. 문서화:
   • 역할 정의, 책임 할당, 그리고 RACI 매트릭스 (선택 사항) 등을 문서화하여, 프로그램 참여자들이 쉽게 접근할 수 있도록 합니다.
   • 문서는 조직의 내부 위키, 공유 문서 저장소, 또는 기타 협업 도구에 게시할 수 있습니다.
5. 정기적인 검토 및 업데이트:
   • 프로그램의 역할 정의는 조직의 구조, 운영 방식, 그리고 기술 환경 변화에 따라 변경될 수 있습니다.
   • 따라서, 역할 정의 문서를 정기적으로 검토하고 업데이트하여, 최신 상태를 유지해야 합니다.

예시

구현 시 고려사항

• 문서는 간결하고 명확하게 작성되어야 하며, 모든 프로그램 참여자가 쉽게 이해할 수 있어야 합니다.
• 문서는 접근 권한을 적절하게 관리하여, 기밀 정보를 보호해야 합니다.
• 문서는 정기적으로 검토하고 업데이트하여, 최신 상태를 유지해야 합니다.

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

3.2.2.2 프로그램 역할의 적절한 인력 배치 및 자금 제공

ISO/IEC 18974

• 4.2.2.2: The identified program roles have been properly staffed and adequate funding provided;
• 4.2.2.2 식별된 프로그램 역할이 적절히 인력 배치되었으며 충분한 예산이 제공되었음을 나타내는 문서.

Self-Certification Checklist

• We have ensured the identified Program roles have been properly staffed and adequate funding has been provided.
• 식별된 프로그램 역할이 적절히 인력 배치되고 충분한 자금이 제공되었음을 확인했습니다.

프로그램 역할이 아무리 잘 정의되어 있어도, 해당 역할을 수행할 인력이 부족하거나, 필요한 자금이 제대로 지원되지 않는다면 프로그램은 제대로 운영될 수 없습니다. 따라서, 조직은 각 역할에 필요한 인력을 적절하게 배치하고, 프로그램 운영에 필요한 충분한 자금을 제공해야 합니다. 이는 프로그램의 성공적인 운영을 위한 필수적인 조건입니다.

구현 방법 및 고려사항

1. 인력 계획 수립:
   • 각 역할별로 필요한 인력 수를 정확하게 산정합니다.
   • 인력 산정 시에는 역할의 책임 범위, 업무량, 그리고 필요한 기술 수준 등을 고려해야 합니다.
   • 장기적인 관점에서 인력 수요를 예측하고, 채용 또는 내부 인력 재배치 계획을 수립합니다.
2. 예산 계획 수립:
   • 프로그램 운영에 필요한 모든 비용 항목(인건비, 교육비, 도구 구매비, 컨설팅 비용 등)을 식별하고, 각 항목별 예산을 산정합니다.
   • 예산은 현실적으로 집행 가능하도록, 충분한 근거를 바탕으로 산정해야 합니다.
   • 예산 확보 계획을 수립하고, 경영진의 승인을 받습니다.
3. 자원 확보 및 배분:
   • 인력 채용 또는 내부 인력 재배치를 통해 필요한 인력을 확보합니다.
   • 확보된 예산을 각 항목별로 적절하게 배분합니다.
   • 자원 배분 시에는 프로그램의 우선순위와 목표를 고려해야 합니다.
4. 정기적인 검토 및 조정:
   • 인력 및 예산 계획의 적절성을 정기적으로 검토하고, 필요에 따라 조정합니다.
   • 프로그램 운영 상황, 예산 집행 현황, 그리고 외부 환경 변화 등을 고려하여 계획을 업데이트합니다.

예시

• 인력:
  • 보안팀에 오픈소스 보안 전문가 2명을 채용하여, 오픈소스 컴포넌트의 취약점 분석 및 대응을 담당하도록 합니다.
  • 법무팀에 오픈소스 라이선스 전문가 1명을 지정하여, 오픈소스 사용 시 법적 검토를 지원하도록 합니다.
• 예산:
  • 오픈소스 보안 도구(SCA, SAST 등) 구매에 연간 5천만원의 예산을 배정합니다.
  • 오픈소스 보안 교육 프로그램 운영에 연간 1천만원의 예산을 배정합니다.
  • 외부 보안 컨설팅 비용으로 연간 2천만원의 예산을 배정합니다.

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

3.2.2.3 알려진 취약점 해결을 위한 전문 지식 식별

ISO/IEC 18974

• 4.2.2.3: Identification of expertise available to address identified known vulnerabilities;
• 4.2.2.3 식별된 알려진 취약점을 해결하기 위해 이용 가능한 전문성을 명시한 문서.

Self-Certification Checklist

• We have ensured expertise available is to address identified Known Vulnerabilities;
• 식별된 알려진 취약점을 해결하기 위한 전문 지식이 확보되어 있음을 확인했습니다.

오픈소스 컴포넌트에서 알려진 취약점이 발견되었을 때, 이를 신속하고 효과적으로 해결하기 위해서는 해당 취약점에 대한 전문 지식을 가진 인력이 필요합니다. 이러한 전문 지식은 내부 인력으로부터 확보할 수도 있고, 외부 전문가의 도움을 받을 수도 있습니다. 중요한 것은, 필요한 전문 지식을 적시에 확보하고 활용할 수 있는 체계를 구축하는 것입니다.

구현 방법 및 고려사항

1. 필요한 전문 분야 식별:
   • 프로그램 운영에 필요한 기술적인 전문 분야를 식별합니다.
   • 예: 웹 보안, 암호화, 네트워크 보안, 시스템 관리, 그리고 오픈소스 라이선스 등
   • 각 전문 분야별로 필요한 지식 수준과 경험을 명확하게 정의합니다.
2. 내부 전문가 목록 작성:
   • 조직 내에서 해당 전문 분야에 대한 지식과 경험을 가진 인력 목록을 작성합니다.
   • 각 전문가의 전문 분야, 경력, 그리고 연락처 정보를 기록합니다.
   • 전문가 목록은 최신 정보를 유지해야 합니다.
3. 외부 자원 확보 계획:
   • 내부적으로 해결하기 어려운 문제에 대비하여, 외부 전문가 또는 컨설팅 업체를 활용할 수 있는 계획을 수립합니다.
   • 신뢰할 수 있는 외부 자원을 확보하고, 계약 조건을 명확하게 정의합니다.
4. 접근 절차 마련:
   • 프로그램 참여자들이 필요한 전문 지식에 쉽게 접근할 수 있도록 절차를 마련합니다.
   • 예: 내부 전문가에게 문의하는 방법, 외부 컨설팅 업체를 활용하는 방법 등
   • 접근 절차는 문서화하여 모든 프로그램 참여자가 숙지하도록 합니다.

구체적인 예시

• 취약점 분석:
  • 특정 오픈소스 컴포넌트에서 SQL Injection 취약점이 발견된 경우, 웹 보안 전문가에게 분석을 의뢰하고, 공격 경로와 영향 범위를 파악합니다.
• 라이선스:
  • 특정 오픈소스 라이선스의 의무사항에 대한 해석이 필요한 경우, 오픈소스 라이선스 전문가에게 법적 검토를 의뢰합니다.

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

3.2.2.4 보안 보증에 대한 내부 책임 할당 절차

ISO/IEC 18974

• 4.2.2.4: A documented procedure that assigns internal responsibilities for security assurance.
• 4.2.2.4 보안 보증을 위해 내부 책임을 할당하는 절차를 문서화한 자료.

Self-Certification Checklist

• We have a documented procedure that assigns internal responsibilities for Security Assurance.
• 보안 보증에 대한 내부 책임을 할당하는 절차가 문서화되어 있습니다.

오픈소스 보안 보증 프로그램의 효과적인 운영을 위해 내부 책임을 명확히 할당하는 절차를 수립합니다. 이 절차는 다음과 같습니다:

1. 책임 할당 주체:
   • 오픈소스 프로그램 매니저(OSPM)가 주도하여 내부 책임 할당 절차를 수행합니다.
2. 책임 할당 절차:
   • OSPM이 연간 책임 할당 회의를 소집합니다.
   • 각 부서장(법무, IT, 보안, 개발, 품질 등)과 협의하여 보안 보증 활동별 책임자를 선정합니다.
   • 선정된 책임자 목록을 OSRB(Open Source Review Board)에 제출하여 최종 승인을 받습니다.
3. 문서화:
   • 승인된 책임 할당 결과를 공식 문서로 작성합니다.
   • 문서에는 각 보안 보증 활동, 책임자, 역할, 필요 역량이 명시됩니다.
   • 작성된 문서는 회사의 문서 관리 시스템에 등록하고 버전 관리합니다.
4. 책임 할당 기준:
   • 각 역할에 필요한 기술과 경험을 정의하고, 이에 따라 적합한 인원을 선정합니다.
   • 성과 평가와 연계하여 책임 수행에 대한 동기를 부여합니다.
5. 정기적인 검토 및 갱신:
   • 연 1회 이상 책임 할당 현황을 검토하고 필요시 조정합니다.
   • 조직 구조 변경, 인사 이동 등 주요 변화가 있을 때마다 즉시 갱신합니다.
6. 교육 및 인식 제고:
   • 새로 할당된 책임자에 대해 필요한 교육을 제공합니다.
   • 전체 조직을 대상으로 책임 할당 결과를 공유하여 인식을 제고합니다.

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)