Trend micro 주관 CloudSec 2023에서 필기한 것들을 공유합니다. 개인적인 해석을 기반으로 한 것 참고

기조연설

1. Trend Micro: 클라우드 위험이 곧 비즈니스 위험입니다.

현황

처음부터 victim을 고도로 특정하고 공격을 시작하는 쪽으로 진화하고 있음(APT)

Threat actor evolution

Cyber criminals
Nations state actors
Insiders

내부자의 실수 등으로 유출되는 것에 주목해야 한다고 강조

Attack Surface Scale

기존 레거시에서 확장되었고, 확장 중.

software supply chain, 백업 등을 위해 얽혀있는 각종 클라우드, 헬스케어 서비스, IT/OT 기기 등

Security Tool Spawl

(직역:날뛰는 보안 도구?)

위의 위협에 맞서 각종 툴들의 갯수가 늘어나고 서로 겹치고, 사용자가 지불해야 하는 비용이 막대하게 증가함

Cloud Risk

Security /Challenges on your cloud journey

Evolving Env
Measureing Risk
Multi-clouid complexity
hybrid Requirements
Incident handling

Cloud Security Silo

CSPM
CDR(EDR, XDR의 클라우드 개념)
CNAPP
IaC

Enterprise에서의 보안

Attack Surface Risk management
Detection and Response(XDR +)
protection and prevention

How?

Let your SOC do cloud

클라우드 이벤트를 탐지하고 반응해라
클라우드 인프라와 데이터 플로우를 visualize해라

리스크의 표준화

자산에 따른 리스크를 고려해라
개발자 또한 endpoint를 가지고 있음을 기억해라
Specialty systems를 통합해라

2. 아마존웹서비스: 보안담당자를 위한 GenAI 보안 전략

GenAI란 무엇인가?

Foundation model을 기반으로 텍스트, 이미지 등을 생성하는 AI

Foundation model: 방대한 양의 비정형 데이터, 아주 많은 파라미터를 포함. 다목적 활용

GenAI로 무엇을 할 수 있나

텍스트, 이미지, 코드, 챗봇, 요약 등

생성형 AI의 참여 기업 유형

Provider

Foundation model을 처음부터 스스로 구축해서 Tuner, consumer에게 제공
Tuner

Provider가 만든 것을 튜닝
Consumer Provider, Tuner가 만든 결과물을 자사 서비스에 녹여 사용

대표적인 FM 커스터마이징 패턴

(난이도순)

프롬프트 엔지니어링
Retrieval Augmented Generation(RAG, 검색 증강 생성?)
FM Fine Tuning
FM을 직접 생성

GenAI에 대한 국내 규제 동향

보통의 경우,다른 나라들도 이에 대응하여 정책 준비중에 있음

아래의 것으로 개보위의 정책 방향을 알 수 있음

'인공지능 시대 안전한 개인정보 활용 정책방향' 발표(23.8)
인공지능 프라이버시팀 신설(23.10)
'AI 리스크 평가모델' 마련
AI 프라이버시 정책협의회를 중심으로 6개 분야별 가이드라인 마련

요약

기획 및 설계
- 개인정보 보호 중심 설계 원칙
- 기획단계부터 위험요인을 제거할 필요
- AI 단계별 위험 분석 및 대응 계획 수립
- AWS의 플레이북 생각하면 좋을 것 같다
데이터 수집

AI 개발을 위한 개인정보 수집/이용 번위에 대한 기준 제시
학습
- 가명정보 특례를 활용한 AI 학습
  - 적법하게 수집된 개인정보는 토계작성, 과학적 연구 등의 목적으로 가명처리하여 동의없이 AI 연구개발 가능!
  - 단 위의 과정에서 프라이버시 침해를 최소화하기 위해 적극적 안전조치 필요
- 개인정보 보호 강화기술(PET) 연구개발 및 활용
  - 합성데이터를 안전하게 생성하여 AI 학습 등에 활용하도록 관련 절차 및 권고기준 마련 예정(24.9)
    
    (동형암호화?를 적극적으로 활용하라고 권고하더라)
서비스제공
- 투명성 제고
  - 정보주체가 AI개발 및 서비스 시 자신의 개인정보 수집/처리가 이루어지는 방식을 명확하게 알 수 있어야 함
  - 개인정보처리방침 등 활용
- 정보주체 권리보장
  - AI 서비스 이용하는 정보주체가 자신의 권리를 쉽게 이해하고 행사할 수 있도록 보장 필요
  - 자동화된 결정에 대한 거부권, 설명요구권 등 보장 필요

GenAI 보안

Top 10 AI/ML 관련 보안 위협

프롬프트 인젝션
안전하지 않은 출력 핸들링
학습 데이터 오염
모델 서비스 거부
공급망 취약점
민감 정보 노출

등등

생성형 AI의 대표적인 문제점: Hallucination

-> 책임있는 생성형 AI를 만들어야 한다. 하지만 까다롭다.

Foundation Model에서의 도전과제 및 해결 방안

도전 과제
- 비합법적이거나 악의적인 목적을 위한 생성형 AI 및 FM 사용
- 모델 보호 및 필터를 피하기 위한 프롬프트 공격
- 잘못된 출력 또는 기타 바람직하지 않은 출력의 위험
해결 방안
- 입력 및 출력에 대한 검증 매커니즘 구현
- 도메인 중심의 FM 및 모델 튜닝을 통한 리스크 축소
- 사람의 판단 필요

대표적인 솔루션: AWS SageMaker

데이터 경계 보안 - VPC Endpoint 정책 강화

위협탐지 및 사고 대응

Amazon Macie/GuardDuty/ECR 등을 활용해라

3. 한국인터넷진흥원(KISA) 사이버침해대응본부 침해대응단: 최근 침해사고 동향 및 대응방안

최근 침해사고 현황

제조기업을 대상으로 한 랜섬웨어 공격이 아주 많이 늘었다!

원인1: 코로나로 인한 사회 환경의 급격한 디지털 전환
원인2: 익명성이 보장된 다크웹, 가상자산시장 활성화(이미 사업화가 됨)

랜섬웨어 증가 및 진화

예전엔 암호화만 하고 끝났으나, 요즘은 공격자들이 뽕을 뽑고 간다.

1차 갈취: 복호화 비용
2차 갈취: 데이터 유출 협박
3차 갈취: 피해자 대상 정보 유출

최근 침해사고 사례

랜섬웨어가 유행하면서 백업솔루션이 잘 팔렸었다.

이젠 바이오 기업 및 제조업체 대상으로, 인터넷에 노출되는 자산과 백업서버를 최우선하여 집중공격이 이루어지고 있다.

백업서버를 선제적으로 털어서 데이터를 가져가고 기존 데이터를 날려버린 후, 위의 2차 갈취 시에 응용함.

또한 개발서버가 잘 노려지고, 잘 털린다.

기업의 대응

나를 알자

내부의 보안 상황을 객관적인 시각으로 재진단
내부 자산에 대한 재점검(특히 외부에 노출되거나 방치된 자산 모니터링. 이것이 되는 회사는 많지 않다)
자산의 중요도에 따라 등급 재분류
중요 자산의 위치는 필요에 따라 재배치
중요 자산의 접근 주체에 명확하고 최소한의 업무 권한만 부여
중요 자산의 가시성과 무결성 확보되도록 지속 모니터링
기업의 존폐와 연관된 자산의 경우 업무 지속성이 보장된 백업체계 운영

적을 알자(많이들 소홀한 부분)

자체 대응과 외부 인텔리네트워크를 활용한 대응역량 강화
미국 마이터 ATT&CK Matrix 프레임워크 활용. 이것은 보안 담당자들끼리 이미 커뮤니케이션 수단이 되었다. 잘 정리되어있으니 반드시 참고

일관된 보안정책을 유지할 것.

이 말인즉슨 A에 3레벨의 보안, B에 2레벨의 보안, C에 5레벨의 보안을 적용하면 안된다는 이야기이다. 시간이 지나면 결국은 2레벨로 하향평준화 되기 때문에, 되도록 일관적으로 맞추라는 뜻

4. 메가존클라우드: 개방형 보안 체계(OCSF)를 통한 Amazon Security Lake 보안 이벤트 대시보드 구현 방안

OCSF = Open CyberSecurity Schema Framework

: 보안 솔루션 공급자/소스에 종속적이지 않도록 보안 데이터의 벤더 중립성을 제공하는 오픈소스 프로젝트이다.

보안 데이터에 관해

데이터를 잘 활용하기 위함 -> 데이터를 축적이 목표가 아닌 활용이 최종 목표
데이터의 효과적인 활용을위해서는 사용자의 필요에 맞추어 데이터 전처리가 필수
보안 데이터를 효과적으로 활용하기 위해 표준화와 정규화가 필요

OCSF 미적용시 발생 가능한 문제점

: 보안 데이터가 사용자에 맞추어지지 않고, 솔루션에 종속적이게 되어 사용자는 사용 시에 여러가지 제약이 생기게 되고, 어쩔 수 없이 재가공을 하게 된다. -> 낭비

Data Sovereignty = 데이터 주권

: 데이터의 진정한 소유자가 보안 솔루션 공급자에 종속되지 않고, 보안 데이터를 능동적이고 효과적으로 접근하고 활용할 수 있도록 하기 위함

TRACK

아카마이: API보안에 대한 이해와 방안

API란?

시스템에 공개적으로 노출된 하나 이상의 엔드포인트로 구성된 프로그래밍 인터페이스. JSON, XML 등으로 표현됨

API는 조직에서 엄청나게 소비되고 있으며, 서비스를 제공하는 조직이라면 신경을 많이들 쓰고 있는 부분이다.

API 확산: API 서비스 소비량 70% API 보안에 대한 요구: 70% API에 대한 개발자들의 노력: 50%

API만의 고유한 고민들

Security

웹 어플리케이션 공격이 API와 관련되어 있고, 가장 일반적인 공격 벡터이다.

application origin attack

컨텐츠 갈취/사용자 데이터 노출
Performance

성능적으로 많이 기대되는 것에 미치지 못한다.

사용자 이탈, 매출 손실, 고객 손실 및 충성도 하락
Reliability(가용성)

77%가 API 안정성을 최우선 과제로 취급

수요에 맞추어 애플리케이션 확장이 어려움

서비스 가용성의 불일치 문제에 직면

과거와의 비교

기존 앱과 최신 앱의 주요 차이점 중 하나는 뷰가 렌더링되는 위치

과거
- 백엔드 서버가 대부분의 뷰 생성을 담당
- 클라이언트-서버는 HTML을 통해 이루어짐
- 데이터 소스는 곧 DB라고 봐도 무관
현재
- 뷰가 일반적으로 클라이언트 자체에서 렌더링됨
- 데이터 소스는 앱 서버이고, 데이터 쿼리가 graphQL 등

API 활용 사례는 다양하다. 페이, 게임, 쇼핑몰, OTT, 위치기반서비스, 날씨 등의 interactive apps 등등

데이터가 오가는 창구인 만큼, 데이터 유출에 유의해야 한다.

API attack surface 찾아보기

API security

API 설계의 특성 때문에 합법적인 사용과 공격 및 악용을 구분하기 어렵다.
정교한 보안 제어가 필요하다

과거와 현재의 비교

과거
- 목표: 데이터 센터에 중요 시스템을 식별
- 방법: 네트워크 침투 후 측면 이동
현재
- 목표: 노출된 API에 비즈니스 로직과 데이터 식별
- 방법: 설계상 API를 통해 노출된 데이터 및 트랜잭션, API 키와 자격증명을 손상시킴

API 보안을 생각할 때, API 보안에 영향을 미치는 소프트웨어 개발 및 문서화 같은 비보안 영역까지 확장해야 함. 또한 인적 오류를 조심해야 함

보안과 비보안을 아우르는 주의가 필요하다...가 결론

DevOps 역시 모두의 고민거리

발표자가 인용한 OWASP API Security Top 10

#	2019	2023
1	Broken Object Level Authorization	Broken Object Level Authorization
2	Broken User Authentication	Broken Authentication
3	Excessive Data Exposure	Broken Object Property Level Authorization
4	Lack of Resources & Rate Limiting	Unrestricted Resource Consumption
5	Broken Function Level Authorization	Broken Function Level Authorization
6	Mass Assignment	Unrestricted Access to Sensitive Business Flows
7	Security Misconfiguration	Server Side Request Forgery
8	Injection	Security Misconfiguration
9	Improper Assets Management	Improper Inventory Management
10	Insufficient Logging & Monitoring	Unsafe Consumption of APIs

주목했던 취약점: 그때나 지금이나 1위인 BOLA취약점과 BFLA(5위)

API 권한 핸들링에 주의해라

API 보호를 위한 모범 사례

개발 라이프 사이클과 통합
보안 테스트를 지속적으로 CI/CD에 통합하기

등등

모든 API 탐지를 하는 것이 중요합니다.

용어 정리:

좀비 API
쉐도우 API
North-South API

대외성 API를 지칭
East-West API

대내성 API를 지칭

쉐도우 API를 어떻게 찾을까? -> 광범위한 범위에서 로그 분석 등의 방법으로 능동적/지능적으로 탐지

API gateway + security 강조

진앤현 시큐리티: 위험관리 프로세스 자동화 방안

오픈텍스트 오픈소스 라이브러리 방화벽을 통한 취약점 탐지/수정 한계성 극복

오픈소스 라이브러리 취약점:

높은 버전의 라이브러리를 자동으로 다운받는 취약점. 버전이 현재의 것보다 높으면 무조건적으로 다운받아 오는데, 가짜 라이브러리임에도 불구하고 자동으로 받아오는 취약점이 존재한다.

용어 정리
- BOM(Bill of Materials)
  
  예를 들면 샌드위치 재료 목록
  
  빵의 종류와 생산지, 고기의 종류와 원산지, 언제 유통되었는가 등의 정보들 목록
SBOM(Software Bill of Materials)

취약점 식별 및 관리를 위한 식별정보 목록

미국 연방정부에서는 본인들과 사업계약을 맺은 기업에게 SBOM 제출을 의무화하고 있음.

오픈소스 사용 사례가 늘어남에 따라 이에 대한 관리가 이루어져야만 보안을 논할 수 있다.

태니엄: 운영의 완벽을 완성하는 Tanium의 위력

소프트웨어 공급망 위협 대응: 많은 기업이 경험한 위협

이제 자체적인 무언가로 개발을 진행하는 곳은 거의 없다.

기업이 이용하는 소프트웨어에서 오픈소스 구성 비율이 70%를 차지

-> 이에 따른 취약점 보유 현황이 크게 증가(+40%)

Log4j 예시 및 SBOM 이야기

(위와 동일) Log4j가 터졌을 때 기업 내에서의 전형적인 사례:

ex.) CISO/CIO와 실무진 간 의사소통

CISO/CIO: Log4j를 사용 중인 소프트웨어를 전수 조사해서 보고하세요.

실무진: 전수 조사에는 기한이 필요합니다.

CISO/CIO: 전수 조사에 필요한 기한이 얼마나 필요한가요?

실무진: 그 기한을 파악하는 기한이 필요합니다.

Log4j가 어디에 얼마나 들어가 있는지 한순간에 파악이 가능한 기업이 얼마나 있을까요?

SBOM of Build time/Runtime

런타임 기반 SBOM을 보는게 맞다는 의견(이유는 지금도 궁금)

보안 위협 대응에 관해

기본적으로 만족되어야 하는 것: 데이터 수집 유무와 방식, 데이터의 정확도, 대응 시간

기업의 일하는 방식의 변화(재택/하이브리드 근무)에 따른 endpoint 확장은 이전으로 돌아오기 어려우며, 이와 같이 변화한 환경은 그대로 인기있는 보안 홀이 되고 있다. 이와 같은 것들 또한 관리해 나가지 않으면 안됨.

NIST가 제시한 기준/조건 7가지 항목 중 무려 4개가 가시성에 대한 이야기이다.(NIST SP800-207?)

앞으로의 Security Tool이 가져야 할 필수요건: 실시간 조회 및 조치

귀사는 대내외 환경 변화에 대응하며, 지금 어디에 어떤 리스크가 얼마나 존재하는가를 인지할 수 있나요?

세미나 전반 개인적인 정리

기업이 기업 소유의 것들을 제대로 관리가 안되고 있는 것은 생각보다 보통 있는 일인 것 같습니다.
DevSecOps라는 말이 생겨난 지 몇년은 되었는데, 이는 모두가 필요성을 느껴서 만들어진 단어라고 생각합니다. 다만, 실무에서 Dev를 하는 사람들과 Sec/Ops를 하는 사람들 간의 이해관계나 시선 등의 격차를 좁히기는 어려우며, 이를 실현하고자 하는 기업에게는 여전히 고민거리인 것 같습니다.
★ 이번 세미나를 전반적으로 아우르는 단어는 '가시성(Visualize)'이라고 느꼈습니다. 가시성이라고 하면 보통 대시보드와 같은 것들을 떠올리는데, 다량의 데이터를 보안 담당자가 한눈에 식별 가능한가 여부를 의미하는 것이냐고 하면 이것도 틀리지는 않아 보입니다. 다만 '한눈에 확인 가능한가' 뿐만 아니라 '모두 볼 수 있느냐' 까지 의미를 확장하고 이해해야 할 것 같습니다. 기업이 스스로의 자산을 모두 파악하고 있는지, 스스로 만든 소프트웨어의 구성 요소를 전부 파악하고 있는지, 이것들이 모두 실시간으로 철저히 관리되고 있는지의 여부를 묻고 있고, 이걸 해결해주는 솔루션을 제시하고 있는 것처럼 보여집니다.
갈수록 고도화되고 복잡해져가는 환경을 보안이 딱 따라가고 있는 것 같습니다. 이 분야 안에서도 각기 전문 분야를 솔루션 회사들이 하나씩 잡아서 발전시키고 세일즈하는 모양새입니다. AWS의 경우는 혼자 다 해먹거나... 보안 관련 이슈 해결을 자급자족 하고 있으며 솔루션의 소비자 자리로 향해가는 회사들은 언제까지 스스로의 힘으로 이 모든 것들을 해결할 수 있을까요?

cloudsec2023trendmicro

CloudSec 2023 Korea 후기