[시큐어코딩] 보안이 강화된 소프트웨어 개발 방법론

기업들이 보안 목적으로 채택할 수 있는 다양한 종류의 S-SDLC가 있다.

OWASP CLASP, 마이크로소프트 SDL, 씨지털 터치 포이트(Cigital TouchPoints) 등이 있다.

보안강화를 위한 SDLC(소프트웨어 개발 라이프사이클) 기법에서는,

   - 반복적인 위험 평가,

   - 영향 분석및 보안 모델링,

   - 구성요소에 대한 보안 평가,

   - 통합/조립 옵션 시제품화

   - 소스코드의 보안 코드화

   - 보안 심사

가 병행되는 통합 보안 테스트를 지원해야 한다.

안전한 소프트웨어 개발,도입을 위한 보안 가이드 V1.0  

안전한_소프트웨어_개발도입을_위한_보안가이드_V1.0.pdf

NIST Security Considerations in the System Development life Cycle

NIST_Security Considerations in the System Development Life Cycle.pdf

OWASP CLASP

(Comprehensive, Lightweight Application Security Process)

---

OWASP CLASP : https://www.owasp.org/index.php/Category:OWASP_CLASP_Project

CLASP Version 1.2 문서: 

OWASP-CLASP.zip 

Secure Software사에서 개발한 소프트웨어 개발 생명주기의 초기단계의 보안을 강화하기 위한 목적을 둔 정형 프로세스이다. 활동중심, 역할기반의 프로세스로 구성된 집합체로 시스템이 코드를 작성하기 전에 적절한 애플리케이션 문제점을 명시하고 접근하도록 하기 위한 일련의 기법과 실천 방법들을 제시하고 있다.

- CLASP는 프로젝트관리자, 보안감사책임자, 개발자, 설계자, 테스트책임자등 프로젝트 참여자에 대한 보안에 관한 지침을 제공한다.

- 프로그램 설계나 코딩 오류를 찾아내어 개선하기 위해 개발팀에 취약점 목록을 제공한다.

- 취약점 목록의 취약점들을 점검하기 위한 자동화된 정적 분석 툴을 이용한다.

CLASP 프로세스는 View - Activity - Process Component 로 구성된 계층 구조이다.

5개의 검증(View)를 제공하며, 이러한 뷰는 활동(Activity)로 세분화되며, 활동은 프로세스 요소를 포함한다.

다음은 CLASP검증(View)와 상호 작용을 보여주는 그림이다.

출처:OWASP CLASP

- 개념검증(Concepts View)

   :  기본적인 보안 목적은 각 리소스에 대해 다음의 내용을 충족시켜야 한다.

     . Authorization(access control)

     . Authentication

     . Confidentiality

     . Data Integrity

     . Availability

     . Accountabiliry

     . Non-Repudiation

- 역할기반검증(Role-bases View)

   : Sample Conding Guideline중에서 프로젝트에 참가하는 각 역할별 지침서를 명시하고 있다.

     . Project Manager

     . Requirements Specifier

     . Designer

     . Architect

     . Implementer

     . Test Analyst

     . Security Auditor

- 활동 평가 검증(Activity-Assessment View)

   : 24개의 Security Activity 정의하고 각 액티비티를 수행하는 Role을 정의한다.

     프로젝트 관리자가 CLASP 활동의 적합성을 확인할 수 있도록 다음과 같은 가이드라인 제공.

     . 활동 적용 

     . 활동의 누락으로 인한 위험 

     . 구현 비용의 추정 

     . 활동을 실행하는 역할

    

24개의 Security Activity와 관련된 Project Role

CLASP Activity	Related Project Role
보안인식 프로그램	•   Project Manager
보안 통계 모니터링	•   Project Manager
운영환경지정	•   Owner: Requirements Specifier •   Key Contributor: Architect
글로벌 보안 정책 확인	•   Requirements Specifier
자원과 신뢰구간 식별	•   Owner: Architect •   Key Contributor: Requirements Speci­fier
사용자 역할및 자원 능력 정의	•   Owner: Architect •   Key Contributor: Requirements Speci­fier
보안관련 요구사항 문서화	•   Owner: Requirements Specifier •   Key Contributor: Architect
상세 오용 사례	•   Owner: Requirements Specifier •   Key Contributor: Stakeholder
공격 정의	•   Designer
설계시 보안 원칙 적용	•   Designer
연구및 기술 솔루션의 보안 상태 평가	•   Owner: Designer •   Key Contributor: Component Vendor
클래스 디자인시 보안 속성 주석 달기	•   Designer
데이터베이스 보안 구성 지정	•   Database Designer
시스템 요구사항을 수집하고 보안 설계를수행한다.(위협모델링)	•   Security Auditor
소스관리 프로세스에 보안 분석을 통합	•   Integrator
인터페이스 구현	•   implementer
자원 정책과 보안 기술을 정교하게 구현	•   implementer
보안 이슈를 보고	•   Owner: Designer •   Fault Reporter
소스레벨 보안 검토 수행	•   Owner: Security Auditor •   Key Contributor: implementer; Designer
보안 테스트를 정의하고, 구현하고, 수행	•   Test Analyst
리소스의 보안 속성을 확인	•   Tester
코드서명 수행	•   Integrator
운영보안 가이드 구축	•   Owner: Integrator •   Key Contributor: Designer; Architect; implementer
프로세스 단결별 보안 이슈 관리	•   Owner: Project Manager •   Key Contributor: Designer

- 활동 구현 검증(Activity-implements View)

   : 각 "Security Activity"의 목적이나 목표를 정의하고 각 활동에 대한 자세한 정보를 제공한다.

ex) 

Activity1: 보안 인식 프로그램

Purpose:	•   프로젝트 구성원 보안 교육과 책임을 통해 중요한 프로젝트의 목표를 고려한다. •   프로젝트 구성원이 효과적으로 보안에 충분히 노출되어 있는지 확인한다.
Role:	Project Manager
Frequency:	Ongoing

  

. 모든 구성원에 대한 보안 교육을 제공한다.

. 로컬 보안 설정에 대한 인식을 증진        

. 프로젝트의 보안 책임자를 임명한다.

....

- 취약성 검증(Vulnerability View)

   애플리케이션 소스코드에서 발새알 수 있는 보안 취약점들을 104개 타입으로 정의.

   104개의 문제 유형은 5개의 카테고리로 분류한다.

      . Range and Type Errors

      . Environmental Problems

      . Synchronization & Timing Errors

      . Protocol Errors

      . General Logic Errors

        [그림출처] OWASP CLASP 프로젝트

CLASP 실천방법은 모든 보안 관련 소프트웨어 개발 활동의 기본이 되며 다음 7가지 실천 방법이 있다.

- 기관의 인식 프로그램

- 응용 평가 수행

- 보안 요구사항 인지

- 안전한 개발 업무의 구현

- 취약성 개선 과정의 수립

- 평가 척도의 정의 및 점검

- 운영상 보안 지침서 발행

마이크로소프트의 SDL(Security Development Lifecycle)

---

빌게이츠가 2002년 1월에 작성한 Trustworthy Computing 메모로 시작으로 마이크로소프트사는 보안 수준이 높은 안전한 소프트웨어를 개발 하기 위한 프로세스 개선 작업을 수행하였다. 그 결과 SDL이 적용된 소프트웨어는 이전 버전에 비해 50%이상 취약점이 감소하였다고 발표하였다.

마이크로소프트는 보안 수준이 높은 소프트웨어를 개발하기 위해 다음 3가지 요소가 필요하다고 정의하고 있다.

1. 반복 가능한 프로세스

2. 엔지니어 교육

3. 측정 기준및 책임성

SDL은 보안 관련한 작업들을 기존의 소프트웨어 개발 생명주기에 추가적인 작업을 정의한다.

[그림출처] KISA 안전한 소프트웨어 개발,도입을 위한 보안가이드 V1.0

- 요구사항단계:

   중앙 보안팀에 보안 자문가를 요청한다.

   보안 자문가는 계획을 검토하고, 권장사항을 제안하고, 보안팀이 제품팀의 일정을 지원하기 위한 적절한 자원을 

   계획하도록 지원한다.

   보안 전문가는 프로젝트 구상단계에서 부터 최종 출시때 까지 보안팀과 제품팀의 창구역할을 수행한다.

   주요 보안 목표를 결정하고, 일정 중단을 최소화하면서 소프트웨어 보안을 극대화할 수 있는 방법을 찾는다.

   소프트웨어 보안 기능및 인증조치가 소프트웨어와 함께 사용되는 소프트웨어아 어떻게 통합할 것인지도 고려한다.

- 설계단계: 

   소프트웨어의 전체적인 요건과 구조를 제시한다. 

   설계단계에서 고려해야할 주요 요소들

   . 보안 구조및 설계 지침 정의: 소프트웨어의 전체 구조를 보안의 관점에서 정의하고, 시스템 보안이 필수적인 

                                            소프트웨어 부분을 확인한다. 

   . 소프트웨어 공격 외형 요소 기록: 사용자의 범위에 따라 노출 범위를 결정하고, 노출된 기능은 최소한의 권한을 할당

                                            한다.

   . 위협 모델링 작업 수행: 구조화된 기법을 이용하여 각 자산에 피해를 줄 수 있는 위협과 위험도를 계산하고, 위협을

                                            완화하기 위한 대응 조치를 파악한다.

- 구현단계:

   개발팀은 소프트웨어를 코드화하고, 테스트하고, 통합한다. 보안 결함및 약점을 제거하거나 예방조치를 하여 최종 

   버전의 소프트웨어에 잔류하지 않도록 조치한다.

   제품의 사용자를 위한 올바른 보안 실천 방법을 문서화하고 필요한 경우 사용자가 보안 수준을 확인할 수 있는 도구를

   제작한다.

- 검증단계:

   소프트웨어가 기능적으로 완전하여 베타 시험을 하는 단계이다. 개발팀은 이 단계에서 소프트웨어 배포후에 발생할

   수 있는 보안 위협에 대응할 수 있음을 보증하기 위한 침입 테스트 등을 수행한다.

- 배포단계:

   소프트웨어에 대한 최종 보안 점검을 실시하며 이것은 중앙 보안팀에 의해 실시되는 독립적인 소프트웨어 점검이다.  

   최종 보안 점검에는 유사 소프트웨어에 영향을 미치는 것으로 새롭게 보고된 취약점에 대해 대응가능한지도 포함

   된다.

   침입테스팅, 추가적인 코드 점검, 잠재적으로 중안 보안팀을 보완하는 독립적인 외부 게약업체에 의한 보안 점검및 

   침입 테스트가 필요한 단계이다.

- 지원및 서비스 단계:

   개발팀은 배포된 소프트웨어에서 새로 발견되는 취약점에 대한 대처를 대응 프로세스를 준비해야 한다.

   대응 프로세스는 취약성 보고서를 평가를 준비하고, 적절히 보안권고및 업데이트를 발표하는 것을 포함한다.

   보고된 취약성에 대한 사후 검토를 실시하여 SDL 프로세스, 교육, 도구 사용을 업데이트 하는 작업들을 수행한다.

Cigital TouchPoints

---

Seven Touchpoints for Software Security

The figure above specifies the software security touchpoints (a set of best practices) that I cover in this book and shows how software practitioners can apply the touchpoints to the various software artifacts produced during software development. These best practices first appeared as a set in 2004 in IEEE Security & Privacy magazine. Since then, they have been adopted (and in some cases adapted) by the U.S. government in the National Cyber Security Task Force report, by Cigital, by the U.S. Department of Homeland Security, and by Ernst and Young.

The touchpoints are one of the three pillars of software security. Attaining software security may not be easy, but it doesn't have to be a burden. By describing a manageably small set of touchpoints (or best practices) based around the software artifacts you already produce, I avoid religious warfare over process and get on with the business of software security. You don't have to adopt all seven touchpoints to begin to build security in (though doing so is highly recommended). The figure above shows the seven touchpoints ordered according to effectiveness and importance. The touchpoints are designed to fill the gap between the state of the art and the state of the practice-something that can be done only through the common adoption of best practices.

Touchpoints are a mix of destructive and constructive activities. Destructive activities are about attacks, exploits, and breaking software. These kinds of things are represented by the black hat (offense). Constructive activities are about design, defense, and functionality. These are represented by the white hat (defense). Both hats are necessary.

I used to present the software security touchpoints in order from left to right. Although that works OK, a better pedagogical approach is to order the touchpoints by their natural utility and present them in some sort of ranking. Some touchpoints are by their very nature more powerful than others, and you should adopt the most powerful ones first.

Here are the touchpoints, in order of effectiveness:

1. Code review
2. Architectural risk analysis
3. Penetration testing
4. Risk-based security tests
5. Abuse cases
6. Security requirements
7. Security operations

Cigital_TouchPoints_Architecture_Risk_Analysis.pdf

국내외 정보보호 관리체계 인증

---

ISO 27001

   ISMS에 대한 국제 표준

   전반적인 경영시스템의 일부로 하여 비즈니스 위험 접근법을 기반으로 하는 정보보호를 수립, 구현, 운영, 모니터 검토, 유지및 개선하기 위한 시스템

미국 정보보호 관리체계(FISMA)

    9.11 이후 연방정부기관의 정보시스템을 보호하기 위해 FISMA 제정

KISA ISMS(정보보호관리체계)

    정보자산의 무결성, 비밀성, 가용성을 실현하기 위한 절차와 과정을 체계적으로 수립, 문서화 하고 지속적으로 관리, 운영하는 체계

PIMS(개인 정보보호 관리 체계)

    개인정보 강화를 목적으로 개인정보보호에 대한 법규 준수 여부를 집중 점검하기 위해 개인 정보를 취급하는 조직이 전사차원에서 개인 정보 보호 활동을 체계적 지속적으로 수행하는데 필요한 보호 조치 체계

G-ISMS(전자정부 정보보호 관리체계)

    행정기관용 정보보호 관리 체계 모델

    KISA ISMS와 ISO 27001 기반으로 행정기관 특히 전자 정부 대민 서비스에 적합한 모델 개발

정보보호 안전 진단

 

국내외 정보보호 관리체계 인증에 관한 연구 동향 분석

국내외 정보보호 관리체계 인증.pdf

FISMA(Federal Information Security Management Act)

---

2002년 미국에서 제정된 전자정부법중 Title3에 속하는 법으로 정부기관의 정보자산과 정보시스템을 보호하기 위해 전사적 정보보호 프로그램을 개발, 문서화, 구현하도록 요구하고 있다. FISMA는 기관의 CIO와 정보보호책임자로 하여금 정보보호 프로그램을 매년 검토하여 그 결과를 OMB에 보고 하도록 요구하며, OMB는 감독 역할을 수행하며, 각 기관에서 제출하는 자료를 사용하여 의회에 FISMA 법안 준수에 대한 연간 보고서를 작성하여 제출한다.

FISMA 준수를 위한 정보보호 구현및 평가 프로세스와 관련 문서

[사진출처] KISA 해외 정보통신 기반 보호 동향

<참고> FIPS 199(STD for security categorization of federal information & information systems, 2004,2)은 정보 유형(type)및 정보시스템에 기포하여 분류하는 방법을 제시하고 있으며, 정보및 정보시스템에서 보장해야 하는 3가지 정보보호 목표를 정의하고 있다. 기밀성(개인정보보호포함), 무결성(부인방지및 인증포함), 가용성

<참고> FIPS 200(Mininum Security Requirements for Federal Information and Information System, 2006, 3)은 17개의 정보보호 통제 영역에 대한 최소한의 정보보호 요구사항을 기술하고 있는 문서이다.

해외정보통신기반 보호 동향.

FISMA 준수를 위한 정보보호 구현및 평가과정 소개

해외정보통신기반보호동향(FISMA).pdf

안행부 SW 개발 보안 의무화를 위한 "정보시스템 구축, 운영 지침"

---

2012년 12월 사업비 40억이상의 전자정부 SW 개발 사업은 SW 개발 단계부터 소스코드 보안 약점 진단, 제거를 의무화 하는 지침이 작성됨.

[그림출처] KISA 아카데미 "소프트웨어 개발보안 전문가 기본 과정"

출처: https://www.owasp.org/index.php/Threat_Risk_Modeling

Threat Risk Modeling

 [hide] 

• 1 Threat Risk Modeling
• 2 Performing threat risk modeling using the Microsoft Threat Modeling Process
  • 2.1 Identify Security Objectives
  • 2.2 Application Overview
  • 2.3 Decompose Application
  • 2.4 Identify Threats
  • 2.5 STRIDE
  • 2.6 DREAD
• 3 Alternative Threat Modeling Systems
  • 3.1 Trike
  • 3.2 AS/NZS 4360:2004 Risk Management
  • 3.3 CVSS
  • 3.4 OCTAVE
• 4 Conclusion
• 5 Further Reading
• 6 Appendix: Alternative open-source Risk Management tools
• 7 Reference

When you start a web application design, it is essential to apply threat risk modeling; otherwise you will squander resources, time, and money on useless controls that fail to focus on the real risks.

The method used to assess risk is not nearly as important as actually performing a structured threat risk modeling. Microsoft notes that the single most important factor in their security improvement program was the corporate adoption of threat risk modeling.

OWASP recommends Microsoft’s threat modeling process because it works well for addressing the unique challenges facing web application security and is simple to learn and adopt by designers, developers, code reviewers, and the quality assurance team.

The following sections provide some overview information (or see Section 6.9, Further Reading, for additional resources).

Threat Risk Modeling

Threat risk modeling is an essential process for secure web application development. It allows organizations to determine the correct controls and to produce effective countermeasures within budget. For example, there is little point in spending $100,000 for fraud control for a system that has negligible fraud risk.

Performing threat risk modeling using the Microsoft Threat Modeling Process

The threat risk modeling process has five steps, enumerated below and shown graphically in Figure 1. They are:

1. Identify Security Objectives
2. Survey the Application
3. Decompose it
4. Identify Threats
5. Identify Vulnerabilities

Let’s consider the steps in more detail.

Identify Security Objectives

The business (or project management) leadership, in concert with the software development and quality assurance teams, all need to understand the security objectives. To facilitate this, start by breaking down the application’s security objectives into the following categories:

• Identity: Does the application protect user identity from abuse? Are there adequate controls in place to ensure evidence of identity (as required for many banking applications?)
• Financial: Assess the level of risk the organization is prepared to absorb in remediation, as a potential financial loss. For example, forum software may have a lower estimated financial risk than an Internet banking application.
• Reputation: Quantify or estimate of the loss of reputation derived from the application being misused or successfully attacked.
• Privacy and Regulatory: To what extent will the application have to protect user data? Forum software by its nature is public, but a tax preparation application is subject to tax regulations and privacy legislation requirements in most countries.
• Availability Guarantees: Is the application required to be available per a Service Level Agreement (SLA) or similar guarantee? Is it a nationally protected infrastructure? To what level will the application have to be available? High availability techniques are significantly more expensive, so applying the correct controls up front will save a great deal of time, resources, and money.

This is by no means an exhaustive list, but it gives an idea of some of the business risk decisions leading into selecting and building security controls.

Other sources of risk guidance come from:

• Laws (such as privacy or finance laws)
• Regulations (such as banking or e-commerce regulations)
• Standards (such as ISO 17799)
• Legal Agreements (such as payment card industry standards or merchant agreements)
• Corporate Information Security Policy

Application Overview

Once the security objectives have been defined, analyze the application design to identify the components, data flows, and trust boundaries.

Do this by surveying the application’s architecture and design documentation. In particular, look for UML component diagrams. Such high level component diagrams are generally sufficient to understand how and why data flows to various places. For example, data movement across a trust boundary (such as from the Internet to the web tier, or from the business logic to the database server), needs to be carefully analyzed, whereas data that flows within the same trust level does not need as much scrutiny.

Decompose Application

Once the application architecture is understood then decompose it further, to identify the features and modules with a security impact that need to be evaluated. For example, when investigating the authentication module, it is necessary to understand how data enters the module, how the module validates and processes the data, where the data flows, how the data is stored, and what fundamental decisions and assumptions are made by the module.

Identify Threats

It is impossible to write down unknown threats, but it is likewise unlikely that new malware will be created to exploit new vulnerabilities within custom systems. Therefore, concentrate on known risks, which can be easily demonstrated using tools or techniques from Bugtraq.

Microsoft suggests two different approaches for writing up threats. One is a threat graph, as shown in Figure 2, and the other is a structured list. 

Typically, a threat graph imparts more information quickly but it takes longer to construct, while a structured list is easier to create but it will take longer for the threat impacts to become obvious.

1. Attacker may be able to read other user’s messages
2. User may not have logged off on a shared PC
3. Data validation may allow SQL injection
4. Implement data validation
5. Authorization may fail, allowing unauthorized access
6. Implement authorization checks
7. Browser cache may contain contents of message
8. Implement anti-caching directive in HTTP headers
9. If eavesdropping risk is high, use SSL

Note that it takes a motivated attacker to exploit a threat; they generally want something from your application or to obviate controls. To understand the relevant threats, use the following categories to understand who might attack the application:

• Accidental Discovery: An ordinary user stumbles across a functional mistake in your application, just using a web browser, and gains access to privileged information or functionality.
• Automated Malware: Programs or scripts, which are searching for known vulnerabilities, and then report them back to a central collection site.
• The Curious Attacker: a security researcher or ordinary user, who notices something wrong with the application, and decides to pursue further.
• Script Kiddies: Common renegades, seeking to compromise or deface applications for collateral gain, notoriety, or a political agenda, perhaps using the attack categories described in the OWASP Web Application Penetration Checklist.
• The Motivated Attacker: Potentially, a disgruntled staff member with inside knowledge or a paid professional attacker.
• Organized Crime: Criminals seeking high stake payouts, such as cracking e-commerce or corporate banking applications, for financial gain.

It is vital to understand the level of attacker you are defending against. For example, a motivated attacker, who understands your internal processes is often more dangerous than script kiddies.

STRIDE

STRIDE is a classification scheme for characterizing known threats according to the kinds of exploit that are used (or motivation of the attacker). The STRIDE acronym is formed from the first letter of each of the following categories.

Spoofing Identity “Identity spoofing” is a key risk for applications that have many users but provide a single execution context at the application and database level. In particular, users should not be able to become any other user or assume the attributes of another user.

Tampering with Data Users can potentially change data delivered to them, return it, and thereby potentially manipulate client-side validation, GET and POST results, cookies, HTTP headers, and so forth. The application should not send data to the user, such as interest rates or periods, which are obtainable only from within the application itself. The application should also carefully check data received from the user and validate that it is sane and applicable before storing or using it.

Repudiation Users may dispute transactions if there is insufficient auditing or recordkeeping of their activity. For example, if a user says, “But I didn’t transfer any money to this external account!”, and you cannot track his/her activities through the application, then it is extremely likely that the transaction will have to be written off as a loss.

Therefore, consider if the application requires non-repudiation controls, such as web access logs, audit trails at each tier, or the same user context from top to bottom. Preferably, the application should run with the user’s privileges, not more, but this may not be possible with many off-the-shelf application frameworks.

Information Disclosure Users are rightfully wary of submitting private details to a system. If it is possible for an attacker to publicly reveal user data at large, whether anonymously or as an authorized user, there will be an immediate loss of confidence and a substantial period of reputation loss. Therefore, applications must include strong controls to prevent user ID tampering and abuse, particularly if they use a single context to run the entire application.

Also, consider if the user’s web browser may leak information. Some web browsers may ignore the no caching directives in HTTP headers or handle them incorrectly. In a corresponding fashion, every secure application has a responsibility to minimize the amount of information stored by the web browser, just in case it leaks or leaves information behind, which can be used by an attacker to learn details about the application, the user, or to potentially become that user.

Finally, in implementing persistent values, keep in mind that the use of hidden fields is insecure by nature. Such storage should not be relied on to secure sensitive information or to provide adequate personal privacy safeguards.

Denial of Service Application designers should be aware that their applications may be subject to a denial of service attack. Therefore, the use of expensive resources such as large files, complex calculations, heavy-duty searches, or long queries should be reserved for authenticated and authorized users, and not available to anonymous users.

For applications that do not have this luxury, every facet of the application should be engineered to perform as little work as possible, to use fast and few database queries, to avoid exposing large files or unique links per user, in order to prevent simple denial of service attacks.

Elevation of Privilege If an application provides distinct user and administrative roles, then it is vital to ensure that the user cannot elevate his/her role to a higher privilege one. In particular, simply not displaying privileged role links is insufficient. Instead, all actions should be gated through an authorization matrix, to ensure that only the permitted roles can access privileged functionality.

DREAD

DREAD is a classification scheme for quantifying, comparing and prioritizing the amount of risk presented by each evaluated threat. The DREAD acronym is formed from the first letter of each category below.

DREAD modeling influences the thinking behind setting the risk rating, and is also used directly to sort the risks. The DREAD algorithm, shown below, is used to compute a risk value, which is an average of all five categories.

Risk_DREAD = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5

The calculation always produces a number between 0 and 10; the higher the number, the more serious the risk.

Here are some examples of how to quantify the DREAD categories.

Damage Potential

• If a threat exploit occurs, how much damage will be caused?
  • 0 = Nothing
  • 5 = Individual user data is compromised or affected.
  • 10 = Complete system or data destruction

Reproducibility

• How easy is it to reproduce the threat exploit?
  • 0 = Very hard or impossible, even for administrators of the application.
  • 5 = One or two steps required, may need to be an authorized user.
  • 10 = Just a web browser and the address bar is sufficient, without authentication.

Exploitability

• What is needed to exploit this threat?
  • 0 = Advanced programming and networking knowledge, with custom or advanced attack tools.
  • 5 = Malware exists on the Internet, or an exploit is easily performed, using available attack tools.
  • 10 = Just a web browser

Affected Users

• How many users will be affected?
  • 0 = None
  • 5 = Some users, but not all
  • 10 = All users

Discoverability

• How easy is it to discover this threat?
  • 0 = Very hard to impossible; requires source code or administrative access.
  • 5 = Can figure it out by guessing or by monitoring network traces.
  • 9 = Details of faults like this are already in the public domain and can be easily discovered using a search engine.
  • 10 = The information is visible in the web browser address bar or in a form.

Note: When performing a security review of an existing application, “Discoverability” will often be set to 10 by convention, as it is assumed the threat issues will be discovered.

Note: Using DREAD can be difficult at first. It may be helpful to think of Damage Potential and Affected Users in terms of Impact, while thinking of Reproducibility, Exploitability, and Discoverability in terms of Probability. Using the Impact vs Probability approach (which follows best practices such as defined in NIST-800-30), I would alter the formula to make the Impact score equal to the Probability score. Otherwise the probability scores have more weight in the total.

Alternative Threat Modeling Systems

OWASP recognizes that the adoption of the Microsoft modeling process may not fit all organizations. If STRIDE and DREAD are unacceptable for some reason, we recommend that your organization “dry run” the other threat risk models discussed against an existing application or design. This will allow you to determine which approach works best for you, and to adopt the most appropriate threat modeling tools for your organization.

In summary, performing threat modeling provides a far greater return than most any other control in this Guide. Therefore, make threat risk modeling an early priority in your application design process.

Trike

Trike is a threat modeling framework with similarities to the Microsoft threat modeling processes. However, Trike differs because it uses a risk based approach with distinct implementation, threat, and risk models, instead of using the STRIDE/DREAD aggregated threat model (attacks, threats, and weaknesses). From the Trike paper, Trike’s goals are:

• With assistance from the system stakeholders, to ensure that the risk this system entails to each asset is acceptable to all stakeholders.
• Be able to tell whether we have done this.
• Communicate what we’ve done and its effects to the stakeholders.
• Empower stakeholders to understand and reduce the risks to them and other stakeholders implied by their actions within their domains.

For more information on Trike, please see Section 6.9, reference 8.

AS/NZS 4360:2004 Risk Management

The Australian/New Zealand Standard AS/NZS 4360, first issued in 1999, and revised in 2004, is the world’s first formal standard for documenting and managing risk and is still one of the few formal standards for managing it. The standard’s approach is simple (it’s only 28 pages long), flexible, and iterative. Furthermore, it does not lock organizations into a particular risk management methodology, provided the methodology fulfils the AS/NZS 4360 five steps. It also provides several sets of risk tables as examples, and allows organizations to freely develop and adopt their own.

The five steps of the AS/NZS 4360 process are:

• Establish Context: Establish the risk domain, i.e., which assets/systems are important?
• Identify the Risks: Within the risk domain, what specific risks are apparent?
• Analyze the Risks: Look at the risks and determine if there are any supporting controls in place.
• Evaluate the Risks: Determine the residual risk.
• Treat the Risks: Describe the method to treat the risks so that risks selected by the business will be mitigated.

AS/NZS 4360 assumes that risk will be managed by an operational risk group, and that the organization has adequate skills and risk management resources in house to identify, analyze, and treat the risks.

The advantages of AS/NZS 4360:

• AS/NZS 4360 works well as a risk management methodology for organizations requiring Sarbanes-Oxley compliance.
• AS/NZS 4360 works well for organizations that prefer to manage risks in a traditional way, such as just using likelihood and consequence to determine an overall risk.
• AS/NZS 4360 is familiar to most risk managers worldwide, and your organization may already have implemented an AS/NZS 4360 compatible approach.
• You are an Australian organization, and may be required to use it if you are audited on a regular basis, or to justify why you aren’t using it. Luckily, the STRIDE/DREAD model discussed earlier is AS/NZS 4360 compatible.

The limitations of AS/NZS 4360:

• The AS/NZS 4360 approach works best for business or systemic risks than for technical risks.
• AS/NZS 4360 does not define the methodology to perform a structured threat risk modeling exercise.
• As AS/NZS 4360 is a generic framework for managing risk, it does not provide any structured method to enumerate web application security risks.

Although AS/NZS 4360 may be used to rank risks for security reviews, the lack of structured methods of enumerating threats for web applications makes it less desirable than other methodologies described earlier.

CVSS

The US Department of Homeland Security (DHS) established the NIAC Vulnerability Disclosure Working Group, which incorporates input from Cisco Systems, Symantec, ISS, Qualys, Microsoft, CERT/CC, and eBay. One of the group’s outputs is the Common Vulnerability Scoring System (CVSS).

The advantages of CVSS:

• You have just received notification from a security researcher or other source that your product has vulnerability, and you wish to ensure that it has an accurate and normalized severity rating, so as to alert your customers to the appropriate level of action required when you release the patch.
• You are a security researcher, and have found several threat exploits within an application. You would like to use the CVSS ranking system to produce reliable risk rankings, to ensure that the ISV will take the exploits seriously as indicated by their rating.
• CVSS has been recommended by the working group for use by US Government departments. However, it is unclear if it will become policy or be widely adopted at the time of this writing.

The limitations of CVSS:

• CVSS does not find or reduce the attack surface area (i.e. design flaws), or help enumerate risks within any arbitrary piece of code, as it is just a scoring system, not a modeling methodology.
• CVSS is more complex than STRIDE/DREAD, as it aims to calculate the risk of announced vulnerabilities as applied to deployed software and environmental factors.
• The CVSS risk ranking is complex – a spreadsheet is required to calculate the risk components as the assumption behind CVSS is that a specific vulnerability has been identified and announced, or a worm or Trojan has been released targeting a small number of attack vectors.
• The overhead of calculating the CVSS risk ranking is quite high if applied to a thorough code review, which may have 250 or more threats to rank.

OCTAVE

OCTAVE is a heavyweight risk methodology approach originating from Carnegie Mellon University’s Software Engineering Institute (SEI) in collaboration with CERT. OCTAVE focuses on organizational risk, not technical risk. OCTAVE comes in two versions: Full OCTAVE, for large organizations, and OCTAVE-S for small organizations, both of which have specific catalogs of practices, profiles, and worksheets to document the modeling outcomes.

OCTAVE is popular with many sites and is useful when:

• Implementing an organizational culture of risk management and controls becomes necessary.
• Documenting and measuring business risk becomes timely.
• Documenting and measuring the overall IT security risk, particularly as it relates to the corporate IT risk management, becomes necessary.
• When documenting risks surrounding complete systems becomes necessary.
• To accommodate a fundamental reorganization, such as when an organization does not have a working risk methodology in place, and requires a robust risk management framework to be put in place.

The limitations of OCTAVE are:

• OCTAVE is incompatible with AS/NZS 4360, as it mandates Likelihood = 1 (i.e., It assumes a threat will always occur) and this is inappropriate for many organizations. OCTAVE-S makes the inclusion of this probability optional, but this is not part of the more comprehensive OCTAVE standard.
• Consisting of 18 volumes, OCTAVE is large and complex, with many worksheets and practices to implement.
• It does not provide a list of “out of the box” practices for assessing and mitigating web application security risks.

Because of these issues, OWASP does not anticipate that OCTAVE will be used at large by application designers or developers, because it fails to take threat risk modeling into consideration, which is useful during all stages of development, by all participants, to reduce the overall risk of an application becoming vulnerable to attack.

Conclusion

In this chapter, we have touched on the basic principles of threat risk modeling, risk management, and web application security. Applications that leverage the underlying intent of these principles will be more secure than their counterparts, which will only be minimally compliant just by including specific controls.

Further Reading

• Threat Analysis & Modeling v2.1.2, © Microsoft Corporation, 2007.
• Threat Modeling Web Applications, J.D. Meier, Alex Mackman, Blaine Wastell, © Microsoft Corporation, May 2005.
• Improving Web Application Security: Threats and Countermeasures, J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan, © Microsoft Corporation, June 2003.
• Threat Modeling, Frank Swiderski and Window Snyder, Microsoft Press, June 2004, ISBN 0-7356-1991-3.
• Writing Secure Code, 2nd Edition, Howard and LeBlanc, (pp. 69 – 124), Microsoft Press, 2003, ISBN 0-7356-1722-8.
• The STRIDE Threat Model, © Microsoft Corporation, 2005.
• DREADful - the DREAD system, © Microsoft Corporation, 2005.
• A Conceptual Model for Threat Modeling Applications, Saitta, Larcom, and Michael Eddington, July 2005, http://dymaxion.org/trike/.
• AS/NZS 4360:2004 Risk Management, Standards Australia and Standards New Zealand.
• CVSS, U.S. Department of Homeland Security library, February 2005.
• OCTAVE, CERT library.

Appendix: Alternative open-source Risk Management tools

• OSMR
• MARCO
• CORAS Risk Assessment Platform
• ISO 17799 Risk Assessment Toolkit
• Easy Threat Risk Assessment
• ARMS
• Minaccia
• ThreatMind
• Open Source Requirements Management Tool