개발 환경의 변화, 보안 이슈

• 자체 개발 >> 프레임워크 오픈소스 사용

• 기술의 진화, 프레임워크 자체 취약점 오픈소스 관리 이슈

  • 많은 기업에서 사용 중인 프레임워크의 1-day, 0-day 취약점을 악용하는 공격 증가

  e.g.) Spring Java 프레임워크에서 발견된 1-day 취약점

  ⇒ 프레임워크, 오픈소스 자체 구조로 발생하는 취약점에 알맞은 대응 어려움

취약점, 알맞은 대응은?

취약점이 존재한다고 무조건 바로 패치할 수 없음 → 취약점 조치 시 이슈가 발생할 수 있음

(업데이트에 따른 장애 이슈, 서비스 간의 호환성 이슈, 한정된 자원(인력, 시간, 커뮤니케이션))

공격자 관점의 1-day 취약점 Check List

• 취약한 라이브러리를 사용 중인가?

• 사용 중인 라이브러리의 버전은 안전한가?

• 최신 버전인가? 주기적인 업데이트를 수행하고 있는가?

• 취약점 동작 시 **파급력(Severity)**은 어디까지인가?

  • 정보 유출/에러 발생/명령 실행 등… 취약점으로 어떤 행위가 가능한가?

  • ⭐ 각 기업의 다른 환경을 고려해야 함 → 취약점이 실제 어느 지점에서 방어될 수 있는지 파악

    • 인프라 구조 ← Firewall, IPS/IDS, WAF, SELinux 등 많은 보안 장비와 Mitigation 포함

    ⇒ 취약점이 Exploit 되더라도 파급력이 존재하지 않을 수 있음

• 취약점이 발현(동작)하기 위한 조건이 충족되는가?

  • 시나리오 파악: 해커들의 공격 시나리오는 어떤 식으로 이루어지는가

    • 해커들은 한정된 리소스로 최고 효율로 금전적 이득 달성을 목표로 함 → 따라서 특정 기업을 targeting하기보다 다양한 기업을 대상으로 자동화된 공격을 수행함

  • 취약점 코드 사용 여부 - 존재하는가? X 동작하는가? O

    • 취약점이 실현 가능한가?
    • 요청이 취약점이 발생하는 지점까지 그대로 전달되는가?
    • 취약점이 발생할 수 있는 설정이 그대로 적용되어 있는가?

    e.g.) 오픈소스 취약점 발생 → 서비스 내 코드에서 어떤 함수를 사용하고 있는지 확인 필요

  • 공격 표면 관리(Attack Surface Management)

    • 회사의 특성이 반영된 Security Layer 구성
    • 취약점이 어느 지점(Layer)에서 시작될 수 있는지 파악 필요
    • 공격 조건이 표면에서 시작되는 경우 우선순위 상승
      • 긴급도: 취약점 1 > 취약점 3 > 취약점 2

    

    토스 SLASH23 + ISEC 필기 재구성

    • 사전 단계부터 공격이 어렵도록 공격 표면 관리!!
      • Shodan, Criminal IP, censys 등 OSINT 툴 활용
      • 지속적인 Blackbox 모의해킹, Bugbounty 등을 활용
      • 사용하고 있는 프레임워크, 오픈소스에 대한 정보(버전 등) 노출 최소화

결론

• 시나리오 + 인프라 ⇒ 우선순위 도출 후 조치

  • 시나리오
    • 취약점 발현 조건
    • 취약점 발현 시 파급력
    • 보안 허들로 인한 시나리오 연결 가능성
  • 인프라
    • 기업 별 Security Layer
    • Layer, Infra 구성에 기반하여 개별 취약점에 대한 조치 방안 도출
  • 우선순위
    • 더 빠르게 대응해야 하는 부분은?
    • 취약점 리스크 감소 방안은?
    • 효율적인 리소스 활용 방법은?

• WISET Red team 멘토링 中 비슷한 사례 언급해주심

  • 백링크 → (비공개) ‣