보안 SW 요구사항

프로그램과 소프트웨어

프로그램: 소스코드, 목적코드

소프트웨어: 프로그램 + 관련 산출물(문서, 시험수행, 실행 로그 등)

 

이걸 인슐림 펌프로 예시를 들어보면

인슐린 펌프 시스템 개요 및 요구사항 요약

1. 시스템 개요

• 당뇨병 환자의 혈당 조절을 위한 임베디드 시스템
• 혈당 센서 데이터 수집 → 인슐린 필요량 계산 → 마이크로펌프 작동
• 혈당 변화율을 기반으로 적절한 인슐린 주입량 결정
  
  • 저혈당 → 뇌 기능 장애, 혼수상태, 사망 위험
  • 고혈당 → 장기적인 눈, 신장 손상

2. 소프트웨어(시스템) 요구사항

• 인슐린을 필요할 때 즉시 공급 가능해야 함
• 정확한 인슐린 용량을 안정적으로 전달해야 함
• 시스템이 항상 이 요구사항을 충족하도록 설계 및 구현되어야 한다

 

소프트웨어 요구 사항

- 기능 요구 사항: ~~해야된다..

- 비기능 요구 사항: 보안요구사항(기밀성, 무결성, 가용성 ...), 성능 요구 사항, 실시간성/응답성/편의성/안정성...

 

보안 요구 사항을 어떻게 찾는가?

보안 요구 사항 정의

- 시스템이 예상되는 위협에 어떻게 대응해야 하는지를 먼저 정의하고 주체와 객체의 관섬에서 기술한다.

- 사용사례와 악용및 오용 사례를 나눈다(사용 사례는 시스템과 사용자간의 정상적인 상호작용이지만 악용의 경우 의도적으로 피해를 주기 위한 상호작용이다.

- 위협 모델링 기법: 공격자의 시각에서 사고하도록함.

- 해커vs공격자: 개커는 시스템의 내부 원리를 이해하는 기술전문가로 반드시 악의는 아니지만 공격자는 보안 침해를 목적으로 시스템을 공격하는 사람이다.

- 보안 요구사항 참고 자료: CC라고 국제적르오 보안 평가 기준되는게 있다함

- 기존 소프트웨어 보안 기능 참고: 유사한 SW에서 제공하는 기능 보고 필요성 판단하거나 과거사례로 강화

 

Commom Criteria(CC)

- 정보 기술 보안 평가를 위한 공통평가 기준\

- 보호 프로파일: CC의 기능과 보증 요구사항을 이용해 특정 제품군의 보안요구사항을 정의한 문서임

 

Trust, Trustworthy, Untrusted

보안 관점에서 신뢰 관리는 중요하다. 시스템 보안을 강화하려면 신뢰할 수 없는 데이터 처리해야되고 신회할 수 없는 요소에 대해서는 방어 기법을 적용할 줄 알아야한다.

 

Privacy Requirements

- 개인정보의 기본 원칙: 일단 개인정보 중요성을 인식, SW가 개인정보 수집하면 적절한 조치 생각해야함

- 가장 간단한 개인정보 보호? 수집안하면 된다..

- 수집해야되면? 젤 적게 수집하기

 

위험관리(Risk Management)의 필요성

위험이란?: 발생할 가능성이 있는 문제를 위험이라 한다. 소프트웨어 보안에서는 이 보안 취약점 발생 위험을 관리하는것이 핵심

SW에서는 누가 악성코드 넣거나 취약점 넣거나 등등 할수가 있는데 여기서 위험관리가 중요함. 위험은 ㄱ완전 없앨수는 없고 합리적인 조치로 최소화하도록 해야됨. 그리고 생기기전에 예방하는게 비용적인 면에서도 효과적인 측면에서도 유리하다.

위험관리는 어떻게? : 예상되는 보안 위협이 뭐가있는지 먼저 분석하고 발생 가능성과 영향끼칠걸 확인해서 대응할 순서를 정한다. 그리고 나서 보안 대책을 적용해서 위험을 최소화하도록 하고 보안 상황을 주기적으로 점검하고 업데이트 할 수 있도록 한다.

 

 

위험 관리 프로세스 (Risk Management Process)

1. 위험 계획(Risk Planning): 프로젝트의 위험 관리 절차 수립
2. 위험 식별(Risk Identification): 예상되는 보안 위험 요소 목록화
   • 유사 프로젝트 분석을 통한 위험 요소 파악
3. 위험 분석(Risk Analysis): 위험의 발생 가능성과 영향도 평가
   • 발생 가능성과 심각도가 높은 위험에 집중
4. 위험 처리(Risk Handling): 위험에 대한 대응 방법 결정
   • 수용(Acceptance & Monitoring): 감시 및 공유
   • 회피(Avoidance): 위험 요소 제거 (예: 불필요한 데이터 수집 금지)
   • 전가(Transfer): 타 시스템에 위험을 넘김 (예: ID 관리 위임, 보험 계약)
   • 통제(Control): 발생 가능성과 심각도를 줄이는 조치 수행
     • 보안 설계 및 안전한 프로그래밍 기법 적용
     • 코드 검토 및 취약점 분석 도구 사용
     • 시스템 강화(Hardening) 기법 적용
5. 위험 모니터링(Risk Monitoring): 지속적인 위험 감소 노력
   • 위험 감소 여부 지속적으로 점검 및 조정

 

위험 식별

위험 식별해야 파악할 수 있어서 중요함. 근데 많이들 인식못한다.

실무경험이나 가이드라인 보고 보안 사고 방식 학습하면 되고 항상 의심하기 ㅡㅡ^

 

보안은 프로세스고, 제품이 아니다

Burce Schneier가 비슷한 말을 했다고 한다.

보안 환경은 계속해서 취약점도 생기고,, 법도 바뀌고,, SW 사용하는것도 바뀌고.,, 그래서 아무튼 계속 안전한 건 아님. 옛날에 안전했어도 이젠 아닐수도 있고 그런것. 그래서 지속적으로 보안 관리가 필요하다. 보안은 한번 설치하고 끝나는게 아니라 계속 관리해야하는 부분인것.

 

체크리스트의 불완전성

체크리스트나 가이드라인 등등은 보안의 보조수단. 근데 체크리스트한다고해서 보안 보장하는건 아님. 보안에서 핵심은 사고하는 능력이다. 어떻게 이 시스템을 악용할 수 있는지 가능성을 계속 생각하고 예상해서 예방하는게 중요하다.

 

 

NIST Cybersecurity Framework (CSF) 2.0

: 사이버 보안 리스크 관리를 위한 프레임워크.. 조직이 보안 태세를 개선하고 사이버 위협에 효과적으로 대응할 수 있도록 함

- 확장된 적용 범위: 기존에는 주로 중요한 인프라 산업에 초점을 맞췄지만, 2.0 버전에서는 모든 산업과 조직(중소기업, 비영리단체 등)도 활용할 수 있도록 조정됨

- 6개 핵심 기능(Core Functions)
이전 버전(Identify, Protect, Detect, Respond, Recover)에서 "Govern"(거버넌스) 기능이 추가

1. Govern (거버넌스): 조직의 보안 정책, 리스크 관리, 규제 준수 등을 체계적으로 운영
2. Identify (식별): 자산, 위협, 취약점을 파악하여 리스크 관리 전략 수립
3. Protect (보호): 보안 정책, 접근 제어, 암호화 등을 통해 위협 예방
4. Detect (탐지): 이상 징후 및 침해 사고를 신속하게 감지
5. Respond (대응): 보안 사고 발생 시 신속한 대응 및 피해 완화 조치 수행
6. Recover (복구): 시스템을 정상 상태로 복구하고 운영을 지속할 수 있도록 지원.

프로파일(Profile) 개념 강화

• 조직별 맞춤형 보안 전략 수립 가능.
• 조직이 특정 목표나 규제를 충족하도록 유연하게 적용 가능.

거버넌스 & 리스크 관리 프레임워크와의 연계

• ISO 27001, COBIT, CIS Controls 등 다른 보안 프레임워크와 쉽게 통합 가능.

 

 

보안 취약점

: 보안 요구사항을 충족하지 못하는 실패 사례

: 대부분 의도치않은거지만 악의적인 삽입도 가능하다

: 백도어나, 논리 폭탄(특정 조건에서 악성동작하는 코드) 등이 있다

: 최근 증가하고 있어서 여러 관리 프로세스나 교육이 필요함

 

보안 취약점 보고 및 처리

보안 연구자 역할은 취약점 발견해서 공급업체에 보고하는 것

보통 취약점은 먼저 비공개로 공급업체에 보고되고 일정기간 내에 공급업체에서 수정 조치를 취한 후에 취약점이 공개된다. 그래서 사용자들은 업데이트 하면된당..

 

취약점 관리 시스템에 CVE가 있음!

CVE (Common Vulnerabilities and Exposures)

전 세계적으로 공개된 보안 취약점을 관리하는 표준 데이터베이스

CVE 항목: 고유 식별번호(ID), 설명, 최소 1개의 공개 참조 정보 포함

형식: CVE-연도-번호 (예: CVE-2014-0160, OpenSSL Heartbleed 취약점)

미국 국립 취약점 데이터베이스(NVD) 등 다양한 DB에서 추적 가능

CVE 할당 절차

CVE 번호는 CNA (CVE Numbering Authority)가 부여

MITRE가 주관 CNA(최종 조정 역할) 수행

Microsoft, Red Hat 등 주요 소프트웨어 기업도 CNA 역할 수행

CNA마다 고유한 CVE 블록을 할당받아 사용 (예: CVE-2025-50000)

CVE의 한계

요청된 취약점만 CVE 할당됨 (요청 없으면 CVE 없음)

공개적으로 배포된 소프트웨어만 대상 (맞춤형 SW 및 온라인 서비스 제외)

 

주요 보안 취약점 유형

OWASP Top 10:웹애플리케이션에서가장심각한보안취약점목록
https://owasp.org/www-project-top-ten/
CWE Top 25:소프트웨어전반에서가장흔하고위험한취약점목록
https://cwe.mitre.org/top25/
OWASP Mobile Top 10:모바일애플리케이션의주요보안취약점
https://owasp.org/www-project-mobile-top-10/
OWASP IoT Top 10:사물인터넷(IoT) 보안취약점목록
https://wiki.owasp.org/index.php/OWASP_Internet_of_Things_Project

 

CVE랑 CWE는 뭐가 다른가..?

CVE는 특정 제품의 개별 취야점을 식별

CWE는보안 취약점 유형(카테고리)를 정의한다. 

 

보안 취약점의 유형을 알면 흔한 취약점을 알 수 있고 이것만 알아도 sw 보안 수준이 향상될 수 있고 공격자 관점에서 시스템을 바라보는 능력이 키워진다.