Reference Engineering principle for IT security NIST SP

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 기밀성 무결성 가용성 Identification. Authentication. Authorization. Administration 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. 위협-App 12

3. Application 아키텍쳐 q Principles Relevancy & weakest Links Risk-driven필요, weakest link에 초점 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 아키텍쳐 q 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 아키텍쳐 q 서비스 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 아키텍쳐 q Distributed System Security consideration q q q q Web authentication GET consideration *SP page Beware of Extension HTML comments Semantic Injection Validate everything which can not be trusted q Active. X control q Error message Database Middleware Presentation Layer q q q q COM/COM+/. NET EJB CORBA DCOM RMI IIOP CSIv 2 SOAP 32 q Oracle q SQL q Informix. . Protocol q q q SSL &TSL SRP SPEKE SPNEGO CSP

3. Application 아키텍쳐 q 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 * 적절한 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: 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 * 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 * 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