Transcript PowerPoint 프레젠테이션

15장
어플리케이션 및 데이터
아키텍쳐
2005.11
신수정
Reference
 Engineering principle for IT security – NIST SP 800-27
NIST SP 800-64
 Guidelines for Security of computer application
 Best practices for secure development by Razvan
 Architectural patterns for enabling application security
 소프트웨어 개발 보안 – 한국전산원
 Guidelines on active content & mobile code
 기타 신수정의 내부 자료
2
0. Introduction
People
보안전략/조직
정책/정보분류
보안기술 아키텍쳐
Process
Technology
Data
Application
User
System
Network
Physical
Data
Application
User
System
Network
Physical
기밀성
무결성
가용성
IdentificationAuthenticationAuthorizationAdministration
Audit
보안관리 아키텍쳐
모니터링
사고대응
사업연속 인력보안
보안교육
Validation/Audit/Measure/Certification
Enterprise Architecture & IT Planning
3
외주보안
1. 위협
공격자가 어떻게 생각하는지를 알 필요가 있음….
-
Asset: 가치가 있는 resource
-
Threat: A potential occurrence that may harm an asset
-
취약성: A weakness that makes a threat possible
-
Attack(or exploit) : An action taken to harm an asset
-
Countermeasure: a safeguard that addresses a threat and mitigates risk
4
1. 위협
1)
2)
3)
4)
5)
Survey and assess: 잠재적인 공격대상의 정의 및 그 특성(서비스, 프로토콜, 취약성 등)
의 assess
Exploit and penetrate
Escalate privileges
Maintain access
Deny service
5
1. 위협
-
위협은 목표와 목적에 기초하여 카테고리 될 수 있음
-
Spoofing: 거짓된 identity를 이용하여 시스템의 접근을 획득
Tampering: 불법적인 데이터의 수정
Repudiation: 사용자가 자신이 수행한 특정 action이나 트랜잭션을 부인하는 능력
Information disclosure: 사적 데이터의 원치 않는 누설
Denial of Service: 시스템 또는 어플리케이션을 unavailable하게 하는 프로세스
Elevation of privilege: 제한된 권한을 가진 사용자가 권한된 접근을 얻기 휘해 권한있는 사
용자의 식별을 가져가는것
6
1. 위협
7
1. 위협-NW
Information gathering
문제) 포트 스캐닝 오픈 포트 정의  배너 그래빙  취약성 체크
대응방안)
footprinting request에 대한 대응을 제한하기 위한 라우터의 구성
네트워크 소프트웨어를 호스트하는 OS의 구성
1)
2) Sniffing
문제) Plaintext traffic을 reading, 가벼운 암호화의 crack
대응방안)
강한 물리적 보안 및 적절한 네트워크의 세그먼트
전송을 암호화
3) Spoofing
문제) true identity를 감춤
대응방안)
내부 IP로 부터 오는 incoming packet의 filter
Invalid local IP address로 부터 나가는 outgoing packet의 filter
4) Session hijacking – man in the middle attack
문제)
대응)
암호화된 session negotiation 사용
암호화된 통신 채널 사용
TCP/IP 취약성을 수정할 수 있는 패치
8
1. 위협-NW
5) Denial of service
문제) 합법적인 사용자가 서버나 서비스에 접근하는 것을 부인하게 함
대응방안)
최근의 서비스 팩의 적용
적절한 레지스트리 세팅을 적용함으로서 TCP/IP 스택을 harden
SYN attack 등을 감지하는 IDS 사용
9
1. 위협-호스트
1) 바이러스, Trojan horse, and worms
문제)
대응방안)
최신의 OS 서비스 팩 및 소프트웨어 패치의 설치
방화벽이나 호스트에서 불필요한 포트들의 블록
사용하지 않는 프로토콜이나 서비스의 disable
Weak, default 구성 setting을 harden
2) Footprinting
문제)
대응방안)
불필요한 프로토콜의 disable
적절한 방화벽 구성으로 port의 lock down
TCP/IP 및 IPSEC 필터의 사용
정보유출을 막기위한 IIS 구성
IDS 사용
3) 패스워드 크래킹
대응방안)
모든 계정에 대한 강한 패스워드 사용
패스워드 추측시도의 수의 제한
디폴트 계정 이름을 사용하지 않음
실패 로그인의 audit
10
1. 위협-호스트
4) DOS
문제)
대응방안)
어플리케이션, 서비스 및 OS를 DOS를 고려하여 구성
패치와 보안 업데이트를 최신화
TCP/IP스택을 DOS에 대응하도록 강화
계정 lockdown 정책의 주의 깊은 사용
High volume of traffic을 처리할 수 있는 기능 보유, 비정상적 높은 load를 처리할 수 있
는 threshold 존재
Application failover 기능 검토
IDS사용
5) Arbitrary code execution
문제)
대응방안)
Path traversal을 막기 위한 IIS 구성
버퍼오버플로우를 막기 위한 최신 패치 및 업데이트
6) 허가되지 않은 접근
대응방안)
안전한 웹 permission 구성
제한된 NTFS permission 을 갖도록 파일, 폴더 구성
Access control mechanism 사용
11
1. 위협-App
12
1. 위협-App
Input Validation
공격자가 어플리케이션이 입력 데이터의 type, length, format 또는 range에 대해 잘 못된 가정을 하
는 것을 발견할 경우, 조작된 입력을 이용하여 application을 공격
Buffer
overflow
Denial of service attack이나 code injection 결과
-철저한 입력 validation 수행
-관리되지 않은 code의 사용 제한
-관리되지 않은 API를 call하는 managed code 조사
-버퍼오버플로우를 박을 수 있는 check기능 사용
Cross-site
scripting
브라우져가 신뢰된 웹 사이트에 접속되는 동안 Arbitrary code가 사용자의 브라우
저에서 실행되도록 함
-철저한 입력 validation 수행
-HTMLEncode, URLEncode 등 함수 사용
SQL
Injection
입력확인 취약성을 이용하여 DB의 arbitrary command 실행
-철저한 입력 validation 수행, DB에 요청을 보내기전 입력을 확인
-DB 접근을 위해 파라메터화된 stored procedure사용
-DB에 접근하기 위해 최소권한 계정 사용
canonicalizati
on
동일한 표준 이름으로 resolve되는 입력의 여러 형태 들
-다응한 입력파일이름을 피하고, 사용시 절대 패스 사용
-파일이름이 well-formed됨을 확인하고 validate
13
1. 위협-App
Authentication
네트워크 도청
인증 credential이 네트워크를 통해 plaintext로 전달될 경우
-네트워크 상으로 패스워드를 전달하지 않는 인증 메커니즘 사용
-패스워드의 암호화 또는 암호화 채널 사용
Brute force attack
-강력한 패스워드 사용
Dictionary attack
저장된 패스워드에 대한 공격
-강력한 패스워드 사용
-Non-reversible 패스워드 해쉬 저장
Cookie replay attack
사용자의 인증 쿠키의 캡처 및 replay
-암호화된 채널의 사용
-cookie timeout 사용
Credential theft
-강한 패스워드의 사용
-패스워드 verifier를 해쉬의 형태로 저장
-계정 lockout 적용
-브라우져에 credentail저장하지 못하게 하던지, 사용자에게 선택토록 함
14
1. 위협-App
Authorization
권한의 elevation
-최소 권한의 프로세스, 서비스 및 사용자 계정의 사용
비밀데이터의 유출
민감한 데이터가 허가되지 않은 사용자에 의해 보여질 경우 발생
-민감 데이터를 보이는 operation에 대한 접근을 허가하기전 role check
-강한 ACL사용
-민감 데이터 저장을 위해 암호화 사용
Data tampering
데이터의 허가되지 않는 변조
-강한 접근 통제 사용
-데이터를 볼 수 있는 사용자와 수정할 수 있는 사용자 사이를 차별화 하기
위해 role-based security의 적용
Luring attacks
적은 권한을 가진 entity가 조금 더 권한을 가진 entity로 하여금 그 대신에
action을 수행하도록 할 수 있을 경우 발생
-신뢰된 code에 대한 접근을 적절한 authorization을 통해 제한함
15
1. 위협-App
Configuration management
- configuration파라미터의 변경, 웹 사이트 내용의 update, 유지보수 등
관리 인터페이스에
대한 허가되지 않은
접근
-관리 인터페이스 수의 최소화
-강한 인증 및 authorization 사용
-local 관리만 지원
Configuration 저장
에 대한 허가되지 않
은 접근
-config파일등에 대한 ACL
-Custom configuration stores을 Web space밖에 저장
Plaintext
configuration secrets
의 retrieval
-패스워드 나 연결 string등 민감한 데이터에 대한 암호화
Lack of individual
accountability
-변경에 대한 로깅 및 감사
-관리자 계정은 공유되어서는 안됨
Over-privileged
process and service
account
응용이나 서비스 계정이 구성 정보를 변경할 수 있도록 할 경우 공격자도 마
찬가지 공격 가능
- 최소 권한 계정 사용
16
1. 위협-App
Sensitive data
저장된 민감 데이터
의 접근
-민감한 데이터를 저장하는 데이터 저장장소에 대한 ALC
-암호화된 데이터 저장
-허가된 사용자만이 접근하는 것을 확인할 수 있는 identity 및 role-based
authorization 적용
네트워크 도청
- 데이터의 암호화
- 암호화된 채널의 사용
Data tampering
-네트워크상의 전송되는 데이터 보호를 위한 tamper-resistant protocol의 적
용(HMAC 등)
17
1. 위협-App
Session management
세션 하이재킹
-안전한 통신 채널을 위해 SSL적용
-다른 세션이 시작시 인증을 위해 한 세션의 로그아웃을 하는 기능 적용
-세션 쿠키에 대한 expiration 주기를 제한
세션 replay
- 핵심 기능을 수행할 경우에는 re-authenticate 적용
-세션을 적절히 expire
-Client에 session을 저장하지 못하도록 하는 option 적용
Man in the middle
-암호화 적용
-HMAC(Hashed Message Authentication Code)사용. 공격자가 메시지를 변
조시켜도 재계산을 통하여 invalid함을 확인
18
1. 위협-App
Cryptography
Poor key generation
or key management
-안전한 키 관리를 포함하는 built-in 암호 루틴의 사용 -DPAPI
-강한 랜덤 키 생성 기능 사용 및 키를 제한된 위치에 저장
-암호화 키를 암호화
-카를 정기적으로 expire
Weak or custom
encryption
- 자체 custom 알고리듬의 개발 금지
- 플랫폼에서 제공되는 증명된 암호화 서비스의 사용
-크랙된 알고리듬 및 기법에 대한 정보 임수
Checksum spoofing
SHA1, MD5는 intercept되고 변경될 수 있음
- MAC이나 HMAC 사용
19
1. 위협-App
Parameter manipulation
- Client와 Web application사이에 보내어지는 파라미터 데이터에 대한 수정
Query string 조작
사용자는 client에서 서버로 HTTP GET 에 의해 전달되는 query string 값을
조작할 수 있음
-민감한 데이터나 서버의 보안 로직에 영향을 줄 수 있는 데이터를 포함하는
query string parameter의 사용을 피함
-forms을 submit하기 위해서 GET대신 HTTP POST를 선택
- query string parameter를 암호화
Form field 조작
HTTP POST를 사용하여 서버에 HTML form field가 plain text로 보내짐
-hidden form field사용대신 서버에 있는 state저장소에 유지된 state를
reference하기 위해 session identifier사용
Cookie 조작
-SSL이 네트워크상의 쿠키는 보호하지만 client 컴퓨터에서의 변조를 막지
못함
-변조위험에 대응하기 위해서는 암호화, HMAC사용
HTTP 헤더 조작
클라이언트는 request header를 생성하고, 서버는 response header생성
- 보안에 대한 의사결정을 HTTP header에 근거해서는 안됨
20
1. 위협-App
Exception management
- Client와 Web application사이에 보내어지는 파라미터 데이터에 대한 수정
Attacker reveals
implementation
detains
-어플리케이션 code base전체에 걸쳐 예외 취급 사용
-어플리케이션 바운더리에 전달되도록 하는 예외를 handle하고 log
-client에게는 일반적이고, harmless한 error message제공
DOS(applicationlevel)
고의로 malformed input을 전달하여 exception 유도
-서버에 있는 모든 입력 데이터를 철저히 validate
-어플리케이션 code base전체에 걸쳐 예외 취급 사용
21
1. 위협-App
Auditing and Logging
User denies
performing an
operation
-웹서버, DB서버 및 Application 서버에 대한 로그 및 감사 수행
-트랜잭션, 로그인 및 로그아웃 등의 주요 이벤트를 로그
-공유 계정을 사용하지 않음
Attackers exploit an
application without
leaving a trace
- 핵심 어플리케이션 레벨 동작을 로그
-로그인 및 로그아웃, 파일시스템의 접근, 실패 오브젝트 접근 시도 등 이벤
트를 감사하기 위한 platform-level 오디팅 수행
- 로그 파일을 백업하고 주기적으로 분석
Attackers cover their -제한된 ACL을 사용해서 로그파일을 안전하게 함
tracks
-시스템 로그파일을 디폴트 location으로 부터 relocate함
22
2. Engineering Principle
 배경: 보안은 시스템 생명주기에서 핵심요소. 보안은 시스템의 초기 계획및 설계 단계부터 incorporated되
어야 하고, 대응되어야 함. 보안에 대한 적절한 주의가 없다면 조직의 정보시스템은 주요한 미션 위험의 근원
이 됨. 초기상태 부터 보안을 고려함으로써 보안은 조직의 미션을 성취하는데 도와주고 지원하는 enabler가
될 것임.
 사용자, 시스템 관리자, 프로그램 개발자 모두 시스템 사용, 설계, 개발, 운영에 관련된 보안의 원칙에 대해
이해하여야 함.
Engineering principles for IT security: 정보시스템의 설계, 개발, 운영상에 고려되어야 할 시스템-레벨 보
안의 리스트
 목적: 안전한 정보시스템의 설계를 지원하기 위함
 5 Life-cycle
-Initiation: 시스템의 필요 및 목적표현 - 민감성 평가 수행
-Development/Acquisition: 시스템 설계, 구매, 프로그램, 개발 수행 - 보안요구사항 결정, 보안요구사항을
Spec화
-Implementation: 시스템이 테스트되고, 설치됨 – 보안테스트, accreditaion
-Operation/Maintenance: 시스템 작동 – assurance, 감사 및 모니터링
-Disposal: 처분- 정보의 저장, 파괴, 매체의 처리
23
2. Engineering Principle
원칙 1) 설계를 위한 기초로서 건전한 보안정책을 수립
원칙 2) 보안을 전체적인 시스템 설계의 통합적인 파트로 취급함.
원칙 3) 관련된 보안 정책에 의해 지배되는 물리적, 논리적 보안 바운더리를 명확하게 기술함.
원칙 4) 위험을 허용가능한 수준까지 감소함.
원칙 5) 외부 시스템은 안전하지 않다고 가정함.
원칙 6) 위험감소와 비용 증가 및 효과성 감소 사이의 잠재적인 trade-off를 정의함.
원칙 7) Layered security의 이행(no single point of vulnerability)
원칙 8) 조직의 보안 목적을 meet라기 위한 tailored 시스템 보안 대책을 이행
원칙 9) 단순화를 위해 노력
원칙 10) 취약성을 최소화하고 대응에 있어 탄력성이 있는(resilient) IT 시스템을 설계하고 운영
24
2. Engineering Principle
원칙 11) 신뢰할 시스템 요소를 최소화
원칙 12) 물리적, 논리적으로 분산되어 있는 대책의 조합을 통해 보안을 이행
원칙 13) 시스템은 기대되는 위협에 대해 현재, 앞으로도 탄력성있도록(resilient) 확신 제공
원칙 14) 취약성을 최소화함
원칙 15) 여러 중첩된 정보 영역을 대응하는 보안대책의 formulate
원칙 16) 미션-crtitical 자원으로 부터 공적접근 시스템을 고립화
원칙 17) 컴퓨팅 시스템과 네트워크 인프라를 구분하기 위한 바운더리 메커니즘의 사용
원칙 18) 가능한 보안은 이식성과 상호운용성의 개방표준에 근거
원칙 19) 보안요구사항을 개발할 경우 평이한 언어의 사용
원칙 20) 불법적인 사용을 발견하고 사고조사를 지원하기 위한 감사 메커니즘의 설계 및 구축
25
2. Engineering Principle
원칙 21) 안전하고 물리적인 기술 업그레이드 프로세스를 포함한, 새로운 기술을 주기적으로 채
용할 수 있는 보안의 설계
원칙 22) 도메인의 내부와 통과(across) 양면에서의 적절한 접근통제 결정을 확신할 수 있는 사
용자 및 프로세스의 인증
원칙 23) accountability를 확신하기 위해 유일한 identities의 사용
원칙 24) 최소권한의 이행
원칙 25) 불필요한 보안 메커니즘을 구축하지 않음.
원칙 26) 프로세스되는중, 전송중, 저장중 정보의 보호
원칙 27) 사용하기 쉬운 운영을 위한 노력
원칙 28) 적절한 가용성을 보증하기 위한 비상 또는 재해복구 절차의 개발
원칙 29) 적절한 보안을 성취하기 위해 custom product의 고려
원칙 30) 시스템의 셧다운 또는 disposal시에 적절한 보안의 확인
26
2. Engineering Principle
원칙 31) 모든 가능한 “attacks”의 부류에 대해 보호
원칙 32) 흔한 에러와 취약성의 정의 및 방지
원칙 33) 개발자들이 안전한 소프트웨어를 개발하는 방법에 대해 훈련받도록 확인
27
2. Engineering Principle
cf) NIST 800-14 Principles(조직초점)
(1) 컴퓨터 보안은 조직의 미션을 지원함.
(2) 컴퓨터 보안은 건전한 관리의 핵심적인 요소임.
(3) 컴퓨터 보안은 cost-effective 해야 함.
(4) 시스템 소유자는 자신의 소유 조직 외부에 대한 보안 책임을 가짐.
(5) 컴퓨터 보안 책임과 accountability는 explicit해야 함.
(6) 컴퓨터 보안은 포괄적이고 통합적인 접근을 요구함.
(7) 컴퓨터 보안은 주기적으로 재평가 되어야 함.
(8) 컴퓨터 보안은 사회적인 요소에 의해 constraint되어야 함.
28
3. Application 아키텍쳐
 Principles
Risk-driven필요, weakest link에 초점
Relevancy & weakest Links
Clarity
명확한 요구제시, 잘못된 설계의 이행은 추후 수정 곤란
Quality
보안은 feature의 문제가 아니라 품질의 문제, 복잡하면서 낮은 품질 보다
는
단순하면서 높은 품질이 더 보안성 높음.
Involve all stakeholders
인프라팀, 개발팀, 업무팀간의 참여 필요. 상호간의 GAP은 보안문제 발생
기술뿐 아니라 프로세스 고려 필요
Technology & Process
비상대응 필요
Fail-safe Operation
Defense in depth
최소권한 원칙, 필요권한 원칙(guest 등)
Principle of appropriate privilege
Best practices for secure development by Razvan
29
33. Application 아키텍쳐
 Principles
사용자의 실수방지를 위한 도움, 인터페이스
Interacting with users
어느 엔터티가 누구를 무엇을 위해 신뢰하는지 분석 필요
TCB(Trusted Computing Base): 시스템내의 보호메카니즘의 총체,
Trust boundaries
- 모든 상호교류의 통로가 되는 checkpoint역할
Trusted Path: a direct communication path between a user and TCB.
3-Party Software
보안기능, 과거의 사고 내역, 취약성 등의 평가 필요
Protect or avoid, generation-storage-transit
Manipulation of sensitive data
Attack first on paper
Think outside of the box
Review
Design review, code review
Declarative vs programmaic
프로그램 실행시 보안의 제한: 프로그샘 자체의 체크, 실행환경에서의 체크
Best practices for secure development by Razvan
30
3. Application 아키텍쳐
 서비스
Identification
Authentication
Password, SSO
Authorization
MAC, DAC, RBAC
Confidentiality
Cryptography, Steganography
Integrity
Accountability
Distributed Service
PKI, MAC(Message Authentication code)
Log, support for non-Repudiation
Kerberos(authentication mechanism),
SAML(security assertion markup language)
31
•Group: who can do this
•Role: how should these users be
collectively referred to
3. Application 아키텍쳐
 Distributed System Security consideration







Web authentication
GET consideration
*SP page
Beware of Extension
HTML comments
Semantic Injection
Validate everything which can
not be trusted
 ActiveX control
 Error message
Database
Middleware
Presentation Layer








 Oracle
 SQL
 Informix ..
COM/COM+/.NET
EJB
CORBA
DCOM
RMI
IIOP
CSIv2
SOAP
Protocol





32
SSL &TSL
SRP
SPEKE
SPNEGO
CSP
3. Application 아키텍쳐
 Architectural Pattern for Enabling Application Security :
안전한 application을 개발하기 위해 적용될 pattern
Proving a security module and a way to log into a system
Ex) single logon screen
Single Access point
Organizing security checks and their repercussions
Ex) 접근 체크, 패스워드 체크
Check Point
Roles
Organizing users with similar security privileges
-사용자 베이스 관리는 너무 크고 복잡
Sessions
Localizing global information in a multi-user environment
- 사용자에 대한 global 정보가 session을 통해 application에 분산
Full View with errors
Provide a full view to users, showing exceptions when needed
Limited View
Allowing users to only see what they have access to
Secure Access Layer
Integrating application security with low level security
- 외부시스템과의 연결
Source: Architectural patterns for enabling application security
33
3. Application 아키텍쳐
Source: Architectural patterns for enabling application security
34
3. Application 아키텍쳐
Source: Architectural patterns for enabling application security
35
3. Application 아키텍쳐
Category
Identification
로그온설계
Authentication
패스워드 설계
설계 방향
접근권한 설계
Authorization
Audit
화면설계
로깅설계
Administration
보안관리설계
암호화
암호화
무결성
무결성
36
세부설계 방안
4. Architecture & design Issue
37
4. Architecture & design Issue
38
4. Architecture & design Issue
1) 보안 정책 및 절차
-
보안정책: Application이 하도록 허락된 일과, 사용자가
Application에 할 수 있도록 허가된 일에 대해 결정, 어떤
사용자가 하도록 허가되지 않는지에 대한 제한 결정
-
Application이 Policy를 깨지 않도록 주의
2) 네트워크 인프라 요소
-
목표 환경, Baseline security requirement(filtering rule,
port 제한, 지원 프로토콜 등)
-
방화벽 정책이 Application설계에 미치는 영향
-
웹서버로 부터 내부자원에 어떠한 프로토콜, 포트, 서비스
가 접근되도록 허가되는지 고려
-
Application설계가 요구하는 프로토콜과 포트 정의
3) Deployment Topology
-
remote application tier를 보유하고 있는지?
-
Identity flow and the accounts
4) Intranet, Extranet, Internet
39
-
caller의 신원을 여러 application tier에 걸쳐 back-end까
지 어떻게 흐르게 할것인가?
-
어디서 authentication을 할 것인가?
4. Architecture & design Issue
* 적절한 Input validation: 최근의 application공격에 대항하는 가장 강력한 방어책
XSS, SQL injection, Buffer overflow 등의 input attack의 대응
•
Valid input? Malicious input?
1)
-
모든 입력은 malicious 하다고 가정하라 !
증명되기 까지는 모든 입력은 문제가 있다고 가정
Source가 trust boundary외에서 부터 온다면 validate하라
2) Centralize your approach
validation rule이 일관성있게 적용되도록 함.
40
4. Architecture & design Issue
3) No not rely on client-side validation
Server-side code의 validation도 필요
4) Be careful with canonicalization issues
이 issue를 피하기 위해서는 사용자로부터 input file name을 받아들이는 application설계를
피함
예) application이 사용자로부터의 파일 이름을 결정하도록 설계
- 입력 파일 이름을 받아들일 경우, 특정 파일에 대한 접근을 부여하거나 거절하는 보안 결정을 내
리기 전에 이들이 strictly formed되었는지 확인
5) constrain, reject and sanitize your input
41
4. Architecture & design Issue
*
-
Constraint input
About allowing good data
Filter
Reject everything else as bad data
•
-
Validate data for type, length, format, and range
Strong type checking 사용
Length check 사용
•
-
Reject known bad input
do not remain constant
•
-
Sanitize input
about making potentially malicious data safe
42
4. Architecture & design Issue
* Authentication
*
세 가지 고려사항
Application중 authentication이 필요로 하는 곳에 대한 정의: trust boundary를 교차할 경우
Caller가 누군지 validate
Identify the user on subsequent requests
•
-
Password 메커니즘의 이슈
이름과 패스워드가 안전하지 않은 채널을 통해 plaintext로 전달되는가?
Credential들이 어떻게 저장되는가?
Credential들이 어떻게 verify되는가? Hash
Authebticated user가 initail logon 이후 어떻게 identified되는가?
•
-
실행
Separate public and restricted areas
Use account lockout policies for end-user accounts
Support password expiration periods
Be able to disable accounts
Do not store passwords in user stores
Requiring strong passwords
Do not send passwords over the wire in plaintext
Protect authentication cookies
43
4. Architecture & design Issue
* Authorization
•
•
Authenticated identity가 할 수 있는 것과 어떤 리소스를 access할 수 있는지를 결정함
약한 authorization은 정보유출과 조작 가능
1)
2)
-
Use multiple gatekeepers
Restrict user access to system-level resources
system-level resources: files, folders, registry keys, database objects, event logon 등
ACL
3) Consider authorization granularity
44
4. Architecture & design Issue
-caller의 security context를 사용하여 자원에 접근
-Window ACL
-사용자 specific resource
-Os level auditing
-Poor application scalability
-DB connection pooling
-Application identity가 공통
45
4. Architecture & design Issue
-caller의 role membership에 의거하여 자원 접근의 idrentity의 제한 집합 사용
46
4. Architecture & design Issue
* Configuration management
1)
-
Secure your administration interfaces
허가된 운영자나 관리자에 의해서만 접근가능
인증서 사용
원격 관리 불허
원격 관리시 SSL 또는 VPN적용
2) Secure your configuration stores
웹 공간내에 configuration 파일 저장 금지
ACL이나 DB 접근권한으로 보호
DB connection string, 계정 credential들은 암호화하여 저장하고 접근 제한
3) Separate administration privileges
4) Use least privileged process and service accounts
웹서버 프로세스를 구동하는 process accounts
다운스트림 자원과 시스템을 접근하는데 사용되는 service accounts
47
4. Architecture & design Issue
* Sensitive data
* secretes: 패스워드, 데이터베이스 연결 strings, 신용카드 번호 등
1)
피할 수 있다면 secret을 저장하지 말라
Hash 값 저장 등
2) Code에 secret을 저장하지 말라
3) 데이터베이스 연결, 패스워드, 키 등을 plaintext로 저장하지 말라
암호화를 사용하고 암호화된 string을 저장
4) Local security authority에 secret을 저장하지 말라
-
LSA를 저장하려면 application이 관리자 권한을 가져야 함
5) secret을 암호화하기 위해 Data protection API를 사용하라
암호/복호키를 platform 시스템이 관리하고, application issue가 아임
48
4. Architecture & design Issue
* Sensitive per user data: 로그온 credientials, application data(신용카드번호, 은행계좌번호)
등이 보호되어야 함. 프라이버시
1)
요구시 sensitive data 를 추출하라
Memory상에 persisting or cashing하지 말고 활용
2) 데이터를 암호화하던지 채널을 안전하게 하라
SSL: client와 웹서버사이
IPSEC: 서버들 사이
여러 중간단계를 거쳐 흐르는 민감한 데이터의 보호: message level 암호화
3) 민감한 데이터를 persistent cookies에 저장하지 말라
4) HTTP-GET프로토콜을 사용하여 민감한 데이터를 전달하지 말라
-
데이터를 전달하기 위해 query string을 사용
query string은 안전하지 않으며 종종 서버에 의해 로깅됨
49
4. Architecture & design Issue
* Session management
* Session 관리: application-level responsibility
1)
Session authentication cookies를 보호하기 위해 SSL를 사용하라
HTTP연결상으로 authentication cookies를 보내지 않음
2) authentication cookies의 내용을 암호화하라
- 쿠키를 탈취해도 보거나 수정할 수 없음
3) Session lifetime을 제한하라
4) 불법적인 접근으로 부터 session state를 보호하라
50
4. Architecture & design Issue
* 암호화
* privacy, non-repudiation, tamperproofing, authentication
1)
개별적 암호화를 개발하지 말라
HTTP연결상으로 authentication cookies를 보내지 않음
2) Keep unencrypted data to the algorithm
3)
-
정확한 알고리듬과 키 길이를 사용하라
다량 데이터의 암호화: TripleDES
댜량 데이터의 늦으나 강한 암호화: Rijndael
잠시간 기간동안 저장될 데이터의 암호화, 빠르나 약한: DES
전자서명: RSA, DSA
해슁: SHA 1.0
Keyed 해슁: HMAC SHA1.0 v- 키가 있는 사람만이 해쉬계산
4) 암호키를 보호하라
키 관리를 피하기 위해 DPAPI사용 – 키관리를 OS에서 수행
키를 주기적으로 사이클
51
4. Architecture & design Issue
* Parameter manipulation
* Client와 web application사이에 전송되는 데이터의 수정, query string, form field, cookies,
HTTP 헤더 등이 될 수 있음
1)
민감한 쿠키 상태의 암호화
쿠키는 session identifies나 서버사이드 authorization에 사용되는 데이터를 가지고 있을 수
있음
암호화 사용
2) Make sure that users do not by pass your checks
end user의 조작가능
이러한 체크를 client-side가 아닌 server-side에서의 점검 필요
3)
-
Client로 부터 보내어지는 모든 값을 validate
사용자가 입력하고 수정할 수 있는 필드의 제한
Client로 부터의 모든 값을 validate
가능한 알려진 좋은 값만 허용
4) HTTP 헤더 정보를 신뢰하지 말라
공격자는 헤더를 변조할 수 있음
헤더의 정보를 가지고 security check금지
52
4. Architecture & design Issue
* Exception management
* 중앙화된 예외 관리 및 로깅 솔루션 설계
1)
Client에게 정보를 누설하지 말라
일반적인 메시지만 return
2) 상세 에러 메시지를 로그하라
에러로그에 상세 에러메세지 전송
패스워드나 민감한 데이터의 로그는 금지
3)
-
예외를 catch하라
구조화된 예외 처리 사용
DOS 방지, 정보누설 방지
53
4. Architecture & design Issue
* Exception management
* 중앙화된 예외 관리 및 로깅 솔루션 설계
1)
Client에게 정보를 누설하지 말라
일반적인 메시지만 return
2) 상세 에러 메시지를 로그하라
에러로그에 상세 에러메세지 전송
패스워드나 민감한 데이터의 로그는 금지
3)
-
예외를 catch하라
구조화된 예외 처리 사용
DOS 방지, 정보누설 방지
54
4. Architecture & design Issue
* Auditing & logging
* 법적 의미
1)
Audit & log access across application tiers
App-level및 platform auditing의 복합
2) Consider identity flow
Caller의 identity를 어떻게 flow하는지 고려
OS레벨에서의 flow (예) Kerberos) - > OS level auditing
App레벨에서의 flow  Middle tier에서의 로깅 및 back-end로깅과의 일관성- 서버 clock
synchronization
3)
-
Key event를 로그하라
성공/실패 로그온, 데이터 변경, 데이터 검색, 네트워크 통신, 관리자 기능 로그
이벤트 시간, 이벤트 장소, 사용자, 프로세스 신원, 세부 설명
4) Secure log files
ACL 등을 활용
로그파일을 조작할 수 있는 직원 수의 최소화
5) Backup & analyze log files regularly
운영서버에서 주기적으로 remove되어야 함
55
4. Architecture & design Issue
56
10.System Development Security
5. 개발과정상의 보안
(1) Project Initiation
-Conceptual definition
-Conceptual proposal & initial study
(2) Functional design
Analysis & Planning
-Functional requirements definition
-System environment specification
(3) System Design
specification
-System Functional design
-Detailed planning of functional
breakdown
-Code design review
(4) Software development
(5) Installation, Evaluation
& Testing
(6) Maintenance/ Operation
(7) Revision/replacement/
destruction
Programming & documentation
-HW installation/integration
-Pre-implementation testing,
installation
Program change & minor
modification
-Major modification or replacement
-Sold, given away or discard
57
-Identify security needs
-initial risk analysis
-identify security framework
-Security area in project plan
-Define security requirements/Risk analysis
- Preliminary security test plan
- Include security requirement in contracts
-Security requirement baseline
-Define security specifications
-Update security test plan
-Security areas in formal baseline
-Write /procure & install security related code
-Perform unit tests, evaluate security code
- Include approved components in baseline
-Test security components
-Test security in integrated system
-Install security code
–Document security control
- Conduct acceptance test
- verify project security
-Perform risk analysis & sensitive
application recertification
- Periodic audit
10.System Development Security
5. 개발과정상의 보안
Project Initiation
(1) Identify user needs – Identify security needs
(2) Evaluate alternatives –initial risk analysis
(3) Select/approve approaches – identify security framework
•Initial risk assessment: If security risks are not considered, cost-benefit analyses may favor a system
plan with unnecessary exposure to failures. Initial assessment should only estimate the damage that
could result from major failures that might occur in spite of controls.
58
10.System Development Security
5. 개발과정상의 보안
Functional design Analysis & Planning
(1) Prepare project plan – Security area in project plan
(2) Develop functional requirement –Define security requirements/Risk
analysis
(3) Preliminary test plans – Preliminary security test plan
(4) Select acquisiton strategy – Include security requirement in RFPs,
contracts
(5) Establish formal functional baseline – has Security requirement
59
10.System Development Security
5. 개발과정상의 보안
Functional design Analysis & Planning
•
Definition of security requirements: Many security problems can be traced to
a poorly thought out security plan or to an inadequate definition of what the
software supposed to do.
Application system interface
Responsibilities associated with each interface
Separation of duties
Sensitive objects & operations: sensitivity, function…
Error tolerance: the expected reliability and validity of data
Availability requirement
Requirement for basic controls
Management considerations
•
Risk Assessment: thorough risk analysis including safeguard selection be
performed at the beginning of the design phase to assure that appropriate
cost-effective security controls are integral to the system’s design.
60
10.System Development Security
5. 개발과정상의 보안
System Design specification
(1) Develop detailed design – Define security specifications
(2) Update testing goals & plans –Update security test plan
(3) Establish formal baseline – Security areas in formal baseline
61
10.System Development Security
5. 개발과정상의 보안
System Design specification
•
-
Designing for security: Inadequate security which is difficult to improve
without a major redesign of the system
Unnecessary programming
Restricted user interfaces
Human engineering
Shared computer facilities
Isolation of critical code: the code & system data that is critical to security
should be well identified so it can be easily audited and protected
Backup & recovery
Use of available control: OS, facility may already provide a variety of controls
Design review: omissions and inadequacies…
62
10.System Development Security
5. 개발과정상의 보안
Security Design
•
Baseline controls
Backup
Access control- Physical & Logical(Role-based access control)
Audit trails
Change control
Documentation
(Contingency ):checkpoint/restart, Disk mirroring, RAID
(Encryption)
•
-
Supplementary controls
sensitivity/criticality/granularity: data & system classification
Integration with procedural, OS, Network control
(Encryption)
63
10.System Development Security
5. 개발과정상의 보안
Software development
(1) Construct form detailed design specifications – write /procure &
install security related code
(2) Perform & evaluate unit tests –Perform unit tests, evaluate security
code
(3) Implement detailed design – Include approved components in
formal baseline
64
10.System Development Security
5. 개발과정상의 보안
Software development
•
-
-
Programming practice for security: programming errors that affect security,
especially flaws in the implementation of security controls, fraudulent
additions or changes to the application code by programmers.
Peer review
Program library
Documentation of security-related code
Programmer association with operational system: when possible,
programmers should not be in a position to receive benefits from system
when it becomes operational
Redundant computation
Program development tool
65
10.System Development Security
5. 개발과정상의 보안
Installation, Evaluation & Testing
(1)
(2)
(3)
(4)
(5)
(6)
Test system components – test security components
Validate system performance –Test security in integrated system
Install system – Install security code
Prepare project manual – document security control
Perform acceptance test – conduct acceptance test
Accept system – verify project security
66
10.System Development Security
5. 개발과정상의 보안
Installation, Evaluation & Testing
•
-
-
Test & Evaluation: Errors and omissions that affect security, especially flaws
in the implementation of security control
Test plan
Static evaluation – techniques which involve examination and analysis of the
system documentation and code, represent the most effective way to detect
deliberate traps or other unauthorized modifications.
* code review, penetration studies, source code analyzer
Dynamic testing – techniques involving executing of the application systems,
or portion of the system, with test data and comparing the actual result with
expected or known results
* program analyzer
67
10.System Development Security
5. 개발과정상의 보안
68