웹애플리케이션취약점 어떻게관리해야하는가 - dbguide.net · 2007. 12. 6. ·...

© Copyright IBM Corporation 2007

Disclaimer(Optional location for any required disclaimer copy.

To set disclaimer, or delete, go to View | Master | Slide Master)

IBM Korea

웹애플리케이션취약점,어떻게관리해야하는가?

자동화된웹애플리케이션취약점분석도구를이용한웹애플리케이션취약점의효율적인관리와보완방안2008. 11. 29

How to manage Web Application Vulnerabilities? | Purpose for Seminar | 20071129 | 29-Nov-072

IBM Korea


웹애플리케이션을안전하게하기위한방법및이를위한애플리케이션취약점관리

많은조직들은웹애플리케이션과서비스환경을통해서

사업과업무활동영역을넓혀가고있습니다. 이는누구나어디에서든지접근할수있는인터넷과웹의편리한

접근성때문입니다. 하지만, 누구나어디에서나 접근할수

있다라는이점이악의적인사용자에게는좋은공격

대상으로떠오르게되었고, 이로인해웹애플리케이션과서비스에대한공격이날로증가하고있습니다.

이러한현실에서웹애플리케이션과서비스환경을

안전하게하고지속적인관리와감사를통해사업

안정성과기업의가치를높일수있는방안을제시하고자

합니다.




IBM Korea

인터넷과 이용 편의성을앞세운 개발 및 서비스 환경이악화시킨 웹 취약점


IBM Korea


인터넷보급변동추이

인터넷보급변동추이년도별초고속인터넷가입자수

0

2,000,000

4,000,000

6,000,000

8,000,000

10,000,000

12,000,000

14,000,000

16,000,000

1999 2000 2001 2002 2003 2004 2005 2006 20070%

50%

100%

150%

200%

250%

Axi

s La

bel

CAGRFrom 1999

전체가입자수

Source: 정보통신부미래정보전략본부인터넷정책팀 2007.11.06


IBM Korea


웹애플리케이션사고변동추이

웹애플리케이션사고변동추이년도별웹애플리케이션사고복합성장율

-40.00%

-20.00%

0.00%

20.00%

40.00%

60.00%

80.00%

100.00%

120.00%

140.00%

2000 2001 2002 2003 2004 2005 2006 2007

Axi

s La

bel

CAGRFrom

Previous year

Source: The Web Hacking Incidents Database, 07 Nov. 2007 Web Application Security Consortium

CAGRFrom 1999


IBM Korea


애플리케이션취약점변동추이

웹애플리케이션취약점변동추이년도별개발환경별발견된웹애플리케이션취약점수

Axi

s La

bel

Source: US-CERT Common Vulnerabilities and Exposures

0 0 0 17 2 2 9 1210 3 11 35 2172

203145

0 7 13 22 6 6 24 121 11 42148

92

395

1,2371,189

0

400

800

1200

1600

1999 2000 2001 2002 2003 2004 2005 2006

.Net ASP JSP PHP


IBM Korea



웹애플리케이션취약점변동추이년도별개발환경별발견된 Cross-site Scripting 취약점수

Axi

s La

bel


0 0 1 1 4 40 8 5 2071 61

2 3 2 4 7 5641 26

125

331

414

0

400

800

2001 2002 2003 2004 2005 2006

.Net ASP JSP PHP


IBM Korea



웹애플리케이션취약점변동추이년도별개발환경별발견된 SQL Injection 취약점수

Axi

s La

bel


0 0 0 0 0 2 30 0 5 1127

9154

0 0 0 0 0 2 11 3 11 13

81

401

318

0

200

400

600

2000 2001 2002 2003 2004 2005 2006

.Net ASP JSP PHP


IBM Korea



웹애플리케이션취약점변동추이년도별개발환경별발견된 File Inclusion 취약점수

Axi

s La

bel


4 3 8

61

173

0

50

100

150

200

2002 2003 2004 2005 2006

PHP


IBM Korea



웹애플리케이션취약점변동추이년도별개발환경별발견된 Directory Traversal 취약점수

Axi

s La

bel


0 2 41

4 3 10 0 2 0 03

016

94

28

79 80

0

20

40

60

80

100

2000 2001 2002 2003 2004 2005 2006

ASP JSP PHP


IBM Korea



웹애플리케이션취약점변동추이년도별개발환경별발견된 Poor Authentication 취약점수

Axi

s La

bel


0 0 0 0 0 01

01

4

0

67

10 0 0

10

10

1 1

9

45

24

29

0

8

16

24

32

2000 2001 2002 2003 2004 2005 2006

.Net ASP JSP PHP


IBM Korea



웹애플리케이션취약점변동추이년도별개발환경별발견된 Command Injection 취약점수

Axi

s La

bel


0 0 0 0 1 01 3 4

28

67

25

0

20

40

60

80

2001 2002 2003 2004 2005 2006

ASP PHP


IBM Korea



웹애플리케이션취약점변동추이년도별개발환경별발견된 Denial of Service 취약점수

Axi

s La

bel


0 0 0 0 0

2 21

2

0 01 1

21

0

5

0 01

001

4 45

13

7

0

4

8

12

16

2000 2001 2002 2003 2004 2005 2006

.Net ASP JSP PHP


IBM Korea



웹애플리케이션취약점변동추이년도별개발환경별발견된 Buffer Overflow 취약점수

Axi

s La

bel


0 0 0 0

1

0

2

1 1

0 0

3

2

00

1

3

0 0

1

00 0 0

2

1

2

4

0

2

4

6

8

2000 2001 2002 2003 2004 2005 2006

.Net ASP JSP PHP


IBM Korea



웹애플리케이션취약점변동추이년도별개발환경별발견된기타취약점수

Axi

s La

bel


0 0 017

1 0 1 010

1 514

4 1026 26

0 6 10 9 3 210 61 8

24

67

32

111

253

138

0

70

140

210

280

1999 2000 2001 2002 2003 2004 2005 2006

.Net ASP JSP PHP


IBM Korea



웹애플리케이션취약점변동추이년도별주요취약점별변동추이

Axi

s La

bel


0

100

200

300

400

500

600

1999 2000 2001 2002 2003 2004 2005 2006

Buffer Overflow Command Injection Cross-site scripting Denial of ServiceDirectory Traversal File Inclusion HTTP Response Splitting OthersPoor Authentication SQL Injection


IBM Korea


웹애플리케이션보안이요구되는이유

100개가넘는대기업과정부기관의애플리케이션에대한 Sanctum의연구:- 판정한애플리케이션의 92%가 Integration 혹은 Production 단계에서진행된보안테스트에서부적합판정을받음

- 문제수정을위해소요된시간과비용은평균 2.5개월, 25M USD 비용임- 부적합애플리케이션의재검사시 20%(전체의 6%) 가보안테스트를통과하지못함- 이들중절반(전체 8%)는계속적으로보안테스트를통과하지못함

국내외기사화되는웹애플리케이션침해사고: - 약 1억명의미국인들이보안문제로피해를받고있다.. Jon Oltsik, Enteprise S.G.- 2만천명에이르는대출사용자의정보가노출… Marcella Bombardieri, Global staff- 2백2십만에이르는현역장병들의개인정보가도난… NewYork Times- L사, P사, S병원의온라인입사지원서류유출사고- L게임사인증정보유출사고- K, N은행홈페이지를악용한피싱사고와이를이용하기위한 N포탈해킹사고등…


IBM Korea


웹애플리케이션보안이요구되는이유

웹애플리케이션은크래커의제일공격목표:- 75%의공격이애플리케이션계층에서발생 (Gartner)- XSS과 SQL Injection이 1, 2위로보고되는취약점 (Mitre)

대부분의사이트가취약성을가지고있음:- 사이트의 90%가애플리케이션공격에취약함 (Watchfire)- 쉽게공격이가능한취약점의 78%가웹애플리케이션에영향을줌 (Symantec)- 2010년에이으러기업및조직의 80%가애플리케이션보안사고를겪게될것임 (Gartner)

웹애플리케이션은크래커를위한매우가치있는표적임:- 고객정보, 신용카드, ID 탈취, 도용, 사이트변조등

규정이행요구항목:- Payment Card Industry (PCI) Standards, GLBA, HIPPA, FISMA,


IBM Korea


웹애플리케이션보안의문제점

웹 세션은 기본적으로 보호기제가 전혀 없다- 방화벽은웹공격에대한적절한방어를제공하지않는다.- 웹필터, 인증및암호화는다른일을한다.- 모의해킹과같은작업은많은비용이지출되고불편하다.- IT 보안인력은일반적으로애플리케이션개발에대한경험이없다.- 개발자와프로그래머들은일반적으로보안관련된경험이없다.- 웹공격: Cross-site Scripting, SQL Injection과같은공격이지난해갑자기가장많이발생한공격이되었다.

- 아직많은사람들이이러한문제점이존재한다는것조차모르고있다.


IBM Korea


웹애플리케이션해킹이증가하는원인

웹애플리케이션보안에대한이해의부재- SDLC내에서필요한보안요소의적용부재- 취약점을내재한애플리케이션을설계/개발/통합/배포함- 다양한취약점을내재한애플리케이션의증가

자체제작/서드파티애플리케이션애플리케이션자체의대형화및다양한기술의혼재

다수의애플리케이션운용및관리로인한업무부하

- 애플리케이션취약점의관리체계미비주기적인점검이불가능하여점검의시기를놓침

다수의애플리케이션에대한전체적인관리및시정결여

웹애플리케이션이공격자에게주는매력- 기업및조직의데이터에접근하는게이트웨이

- 많은사용자의정보와온라인거래가이루어지는장소

- 웹애플리케이션취약점을이용한손쉬운데이터획득가능성


IBM Korea


웹애플리케이션해킹

해커가행동에나서기앞서이용하는Systematic 계획

- 공격하고자하는서버인프라스트럭쳐와서버운영체제및타입에대해서연구

- 웹사이트와웹애플리케이션에대한조사를진행

- 입력값검증이어떻게이루어지는지확인

- 공격의계획을세우고실행함


IBM Korea


웹애플리케이션해킹

해커가신용카드세부정보를공격대상의애플리케이션검색하기위해 SQL Injection을수행하였다면

- 공격하고자하는웹애플리케이션의취약점을발견하면, 사용되는포트를통해웹서버로공격시도

- 웹서버는악의적인코드를수신하고웹애플리케이션서버로이를전송

- 웹애플리케이션서버는악의적인코드를수신하고, 이를데이터베이스서버로전송

- 데이터베이스서버는데이터베이스에서악의적인코드를실행하며, 데이터를신용카드테이블로전달

- 웹애플리케이션서버는데이터베이스로부터신용카드세부정보를포함하고있는페이지를이용하여동적으로페이지생성

- 웹서버는신용카드를해커에게전달


IBM Korea


웹해킹기법은?

자주이용되는웹애플리케이션해킹기법Static Methods와 Dynamic Methods

SQL InjectionCross-site ScriptingDirectory & Link TraversalSource Code DisclosureCommon File CheckParameter ManipulationHidden PathsSession HijackingAuthentication AttackEtc…

Know ExploitsDirectory EnumerationWeb Server ExploitsEtc…

Dynamic MethodsStatic Methods

UnknownKnown


IBM Korea


웹애플리케이션해킹이사업에미치는영향

Read/write access to customer databasesUnauthorized Site/Data AccessForceful Browsing/SQL Injection

Alter distributions and transfer accountsFraud, Data TheftParameter Tampering

Access to non-public personal information, fraud, etc.

Access O/S and ApplicationStealth Commanding

Larceny, theft, customer mistrustIdentity TheftCross Site scripting

Unauthorized access, privacy liability, site compromised

Admin AccessDebug options

Illegal transactionsSite AlterationHidden fields

Larceny, theftSession HijackingCookie poisoning

Site Unavailable; Customers GoneDenial of Service (DoS)Buffer overflow

잠재적으로사업에미치는영향부정적인영향애플리케이션위협


IBM Korea


요약

Summary

인터넷서비스및웹환경의급격한변화

사용자의증가와원격지에서의접근성개선

편의성과이용성에치중한웹애플리케이션서비스환경의증가

각개발환경별취약점의지속적인증가

다양한서비스환경에접목된취약점의이용

기업데이터의접근의용이성




IBM Korea

웹애플리케이션보안,왜! SDLC에포함돼야하나?


IBM Korea


웹애플리케이션보안에관심을가져야하는가?

답은 “예”입니다:

웹해킹이라는공격행위는 Traditional하게웹사이트의변조행위로부터, SQL Injection이나XSS를통해정보의탈취변조나사용자세션획득및악성코드의실행등으로직접적인공격대상과

관련된모든사용자와조직이피해를보기

때문이며, 침해사고의 75%가웹애플리케이션단에서이루어지며, 모든웹애플리케이션의2/3이상이취약점을가지고있고, 웹애플리케이션보안은기존의네트워크/시스템보안과함께중요한주요평가기준이될것이기때문입니다.


IBM Korea


웹애플리케이션보안취약점의관리가필요한가?

웹애플리케이션보안위협과취약점을파악하고있다는것은웹애플리케이션을안전하게하고원활한서비스를하는데도움을줄수있습니다:- 이는어떤보호기술이드러난취약점에대해가장효과적으로애플리케이션을방어하는데이용될수있는지를정의하기때문임.

- 이는문제점을해결하는데있어특정한기술을선택하기에앞서일반적인대책을구상하여처리하는것이바람직한방법이기때문임

- 이는해결된문제점과해결되지않은문제점을파악함으로써항상애플리케이션이가지고있는문제점을이해하여발생할수있는사고를최대한억제하거나예상할수있기때문임

단계적인보안취약점관리는

- 특정부서에집중되는과중한업무를경감할수있음

- 지속적인관리를통해위협에대한조정과시정및 Metric을가질수있음- 애플리케이션의 SDLC 단계중빠른시점에문제점을발견할수있도록도움을줌- 가장비용효율적인솔루션을제안할수있음

- 보다나은자산에대한보호를제공할수있음


IBM Korea


일반적인웹애플리케이션보안을이루기위한구조

데이터베이스

Application

Server

애플리케이션

Application

Server

애플리케이션

인증된사용자 안전한설정제공

예외처리

적절한입력값검증

민감한데이터보호서비스서비스

거부공격거부공격

파라메터조작방지

민감한데이터보호

세션하이재킹방지

적절하지않은입력값검증

인가된사용자

감사및로깅


IBM Korea


일반적인애플리케이션 SDLC의 4단계

Design(설계)- 애플리케이션의특정요소의세부설계및다른애플리케이션들과의연동에대한세부내용을포함한논리적요소들의정의가이루어지는단계임

Coding(개발)- 설계와상세사양에부합된결과로동작하는애플리케이션에서보여주기위한단계임

Testing or Quality Assurance(검사또는품질관리)- 애플리케이션과제안된기능명세간의무결성과정확한동작여부를확인하는단계이며, 이를통해실제운영환경에서의배포를진행할수있음

Deployment or Production(배포또는제품화)- 실제운영환경에들어갈때, 애플리케이션이동작하게될환경을생성하는단계임

이러한 SDLC의단계가반드시분리되어야할필요는없고, 어떤단계/과정은동시에이루어질수있습니다.


IBM Korea


웹애플리케이션이취약성을갖게되는이유

웹애플리케이션개발전요구분석시발생하는문제

요구분석내용을통한웹애플리케이션설계시발생하는문제- 잘못된요구분석을따라설계하여발생하는문제

- 정상적인요구분석을따랐지만설계시발생하는문제

설계이후의코딩상의문제- 잘못된설계를따라코딩시발생하는문제

- 정상적인설계를따랐지만코딩시발생하는문제

빌드과정에서발생하는문제- 잘못된코딩에의해서발생하는문제

- 정상적인코딩이이루어진요소들의조합시발생하는문제

운영시발생하는문제

이러한문제점들은

기본적으로

각단계별담당자들이

웹애플리케이션

보안에대한이해도가

어느정도인지에따라

결정되게됩니다.


IBM Korea


조직에맞는애플리케이션개발절차의구축

Design Coding Testing Deployment

Re-Design

Re-Design

Re-Design

Re-Coding

Re-Coding

문제발견시점


IBM Korea


조직에맞는애플리케이션개발절차의구축

예컨대애플리케이션의특정부분에대한검사는다른부분이아직개발되고있는동안진행될수있습니다. 어떤단계에서도문제는발견될수있고, 이들문제는현단계에서이전의단계로강제로돌려보내질수있습니다.Testing 단계에서발견된보안취약점은애플리케이션의일부를 Re-coding하거나더하다면 Re-design하도록할수있습니다. 애플리케이션라이프사이클은시장의요구에따라가속되고있고, 압축된주기에서많은수의취약점이만들어질수있으므로, Flexible한개발절차를구축하고따르는것은시간과비용을보존할수있는좋은방법이될수도있습니다.

Introduction > language setting


IBM Korea


SDLC에서의일반적인문제발견방법과공통적인원인

SDLC에따른절차와문제의원인

Requirement Design Coding Testing Integration Production

점검도구및모의해킹검사

서드파티취약점

제조사의잘못된설정

운영상의에러

점검도구를통한단위(유닛)별자세한코드검토

부적절한데이터검증

안전하지않은 IDE 마법사

보안위험에대한이해부재

부족한개발일정

문제발견방법이없음: 요구분석팀은무엇을모르는지를모름


필수사항의결여

요구분석미비(보안성결여)

해커,감사및사용자관찰

사용자정책에러

사회공학

네트워크/시스템에치우친보안정책

점검도구를통한 데이터검증및시스템검사

에러에대한검사와기능을제외한검사의결여

미약한코드커버리지

형식적인설계 –보안팀검토

적합하지않은기술선택


불완전한검사지원


IBM Korea


요약

Summary

애플리케이션취약점은소프트웨어개발주기의각단계에서발생

각단계별협업혹은상호간의검토없이는주기내에처리가불가

각단계별문제발견방법과공통원인의이해가요구




IBM Korea

웹애플리케이션취약점,어떻게검토하고관리할수있나?


IBM Korea


웹애플리케이션취약점에대한이해와관리, 필요한것일까?

웹애플리케이션취약점을이해하고, 운영하는애플리케이션의위험도를평가

관리하는것은반드시필요합니다.

이는보통하나의취약점에는다양한

Exploit이존재할수있고, 이러한 Exploit들은다른취약점들과연관되어져있을수도있고, 애플리케이션의다른부분에영향을받거나

영향을줄수있기때문입니다.


IBM Korea


SDLC 단계별보안검토가요구되는이유

10x

20x

15x

베타에서발견

30x10x1x코딩과정에러

5x

코딩단계발견

1x

10x

통합단계발견

통합과정에러

설계과정에러

20x

30x1x

GA에서발견설계단계발견

SDLC에따른에러생성과발견간의시간경과에따른비용

Source: US NIST Research 2006

설계과정에서만들어진에러가 GA에서발견된다면, 설계단계에서에러를수정하는비용의 30배의지출이발생통합과정에서만들어진에러가 GA에서발견된다면, 통합과정에서수정하는비용의20배의지출이발생이는각공정별보안검토와이를보완하기위한노력이해당과정이후확인되는문제를보완하는것보다효과적임을증명함


IBM Korea


SDLC 프로세스에서나타나는에러의형태

요구분석단계에러: 요구분석팀의역할은애플리케이션이지향할것으로예상되는일반적인보안경향을제공함- 요구분석팀이애플리케이션보안위험에대한이해가없거나낮다면:

특정한애플리케이션위험에대한점검을위한요구사항을알지못함위험점검을위한요구사항을포함하지않은애플리케이션요구사항을설계팀에전달

설계단계에러: 설계팀의역할은요구분석목록에따른애플리케이션의설계- 애플리케이션보안위험에대한인식과지식이없거나낮다면:

빈약하거나잘못적용된기술선택검사프레임워크의부재

개발단계에러:- 애플리케이션보안위험에대한인식과지식이없거나낮다면:

새로운코드를만드는대신문제점있는코드를다시이용함보안에이용할수없는 IDE 마법사를이용하여코드를생성적절한데이터검증을하지않음선택된프레임워크의보안기능을이용하지않음

Last Stage 에러:- 애플리케이션보안에대한이해가보편적이지못함- 이전단계에서보안에러를발견하고수정했기를희망함- 제한된시간과검토인원으로점검을진행함


IBM Korea


웹애플리케이션보안을이루기위한주체

웹애플리케이션보안을이루기위해서는다수의주요한주체가사람, 프로세스, 기술및정책에서반드시성립되고유지돼야합니다.

- 사람: SDLC의주체. 개발과배포에책임. 안전한설계원리와보안위험의기본을이해해야함- 기술: 자동화된보안검사도구의이용으로 Scale과비용면에유리하도록함. 기업내정책및규정에밀접하고일관성있는권고를제공해야함

- 프로세스: SDLC에보안검사를통합하는것은좋은위험관리의중요한시작임. 최종검토의일부로이러한위험에정통한책임있는보안및품질평가팀에의해검사가요구됨. 이러한프로세스는발견된보안문제에대한시간과비용을최소화하기위해각공정별로통합이요구됨

- 규정: 사람과기술및프로세스를강제할수있는조직및산업계의표준. 각주체별적절한이해와기능및절차를준수할수있도록함

상기사항에대한적절한측정과시정이있어야당면한위험을완화하기위한충분한보호기재가제공되고있다고할수있습니다.

전체주기에대한베이스라인과이력이수립되는동안, 주요측정사항은위협, 취약점, 개선작업과위험도와같은중요요소를반드시포함해야합니다.


IBM Korea


SDLC에따른웹애플리케이션보안성향상솔루션

Build QA Security ProductionCodeRequirements Design

IBM Rational AppScan

White-box Tester

W.A.F. & P.T.

Other Black-box tester

Testing & Integration

웹애플리케이션보안성향상을위해국내에서이용되는솔루션:- 웹애플리케이션취약점분석도구(Black-box Tester; Dynamic Analysis)- 소스분석도구(White-box Tester; Static Analysis)- 웹애플리케이션방화벽

- 모의해킹및컨설팅


IBM Korea


일반적인웹애플리케이션보안검사접근법

Automated Testing

Black-box testing 과White-box testing의장점을조화

Black-box testing과White-box testing의단점을보완

정적인감사

코드레벨의취약점제거

실시간분석

다양한단계에적용가능

전체혹은부분요소에대한분석

다양한검사가능

심도깊은분석가능

실제 Exploit테스트가능

장점

이용자의이해에따른탐색율과신뢰도변동

개발자의처리요구

제품별검사결과차별

웹취약점분석도구

Top-down 접근Input-Output testing구조및기능문제검사

보안담당자

개발자

모의해킹테스터

Black-box Testing

개발단계이용가능

전체적인 연관성있는검토불가

개발기간에영향

환경/컴파일러에제한

소스분석도구

Bottom-up 접근Method, 기능검사

개발자

보안담당자

White-box Testing Gray-box TestingManual Testing

단점

점검방법

점검주체

Black-box testing과White-box testing을연계하는 Framework을별도로구축해야함

작업자의기술에의지

부분적인검사

Depth의보장율낮음높은시간,비용지출보완을위한자료부족

Black-box & White-box testing framework

자동화된도구

스크립트

체크리스트

보안담당자

개발자

보안전문가

모의해킹테스터

컨설턴트


IBM Korea


웹애플리케이션취약점, 어떻게관리해야하는가?

안전한웹애플리케이션을개발하는것은애플리케이션의 SDLC에걸친지속적인주의를요구하는복잡한과정임

원래의요구분석으로부터최종배포에이르는모든단계중어느한부분에서발생하는실수도심각한보안취약점을야기할수있음

보안취약점은이전과달리새로운도전에직면하도록함

웹은사용자들의접근을위해개발되지만, 이를조작하는악의적인의도를예상해야함웹애플리케이션취약점은 SDLC의모든단계부분부분에서주의가주어져야함- 단일전송, 세션, 애플리케이션과전체서버와같은모든단계에서고려되야함- 반드시조직적이고지속적이며, 조직의개발-배포-유지프로세스내에구축되야함- 애플리케이션이어떻게개발되고운용되는지평가하기위해적용되야함

애플리케이션초기단계에서부터보안에대해고려하고, 애플리케이션 SDLC의모든단계에서자동화된도구를이용하여취약점을줄이고관리하기위한노력이요구됨


IBM Korea


각단계별수행내용및절차

각단계별수행내용 -작업내용

새로운코드의개발

보안코드검토

보안단위검사

자동화된보안 성립절차

검사

자동화된화이트박스를통한코드검증

보안응답처리계획수립

보안시스템구축

-추가되는보안시스템에대한구축및단위테스트

구축 검증및배포설계요구분석

작업

내용

버그수정

보안시스템및기능검사

자동화된블랙박스보안평가점검

최종보안검토

보안문제점추적

보안서비스및응답처리-보안작업후조치요청

-모의해킹

-주기적인점검및QA/지원팀보안문제관련미팅

-보안업데이트, 패치테스트, 패치공개, 패치배포

보안설계검토

-기능및설계상세사양

정의

보안검사계획수립

보안명세정의

-계층별보안체계수립

-Interface 보안체계수립

개발및 QA에이용될보안검사정의

위협모델링

-구조분석을기반으로예상되는보안위협을도출하여개선방안수립

보안설계및개발검증에대한 best practice 적용

보안요구사항정의(시스템및기능)

-환경및요구분석: 과거작업분석, 신규요구분석, 환경분석-법,제도,규정상의보안요건정의

-서비스기능상의보안요건분석및정의: 시스템구조분석을기반으로필요한보안요건도출

-품질가이드라인

-패키지보안기능분석

일정계획

보안코딩표준교육

보안프레임워크정의

보안요구사항매핑


IBM Korea



각단계별수행내용 –기법및산출물

보안감사

문서검토

윤리적인해킹

기능및퍼포먼스점검

보안검사

문서검토

인터뷰

문서검토

유관법률/지침조사구조분석

인터뷰

기법

보안구축결과서

보안검사결과서

보안구현검토서

보안응답조치작업목록및반영서

구축 검증및배포설계요구분석

산출물

보안시험결과서

모의해킹결과서

운영지침

기능점검결과서

퍼포먼스점검결과서

자동화도구점검결과서

규정이행점검내역서

위협모델링결과서

보안체계설계서

보안검사계획서

위협모델링검토서

보안요건정의서

보안코딩표준정의서

일정계획서

보안코딩표준교육서


IBM Korea



•웹애플리케이션을안전하게하는것은애플리케이션의개발주기에따라취약점을최소화할수있도록각단계별로보안요소를고려한작업이요구되며, 이를위해웹애플리케이션보안교육이요구됩니다.

•교육을통한웹애플리케이션보안의이해의증진은각단계별작업자의이해도에따른보안성을제고한단계별작업이이루어지며, 이에대한체크리스트혹은도구를통해활용도를높일수있습니다.

•애플리케이션의취약점을검출하고관리하고수정하며감시하기위한지속적인작업이요구됨을위의그림을통해서알수있습니다.

•이는설계, 코딩단계에서발생한취약점을검출하여관리하지않으면결국베타혹은프로덕션된애플리케이션을관리하면서문제를수정해야하기때문이며, 이러한관리가체계적으로이루어지지않는다면, 문제발생시이를적절하게대처하거나, 기존에수정된애플리케이션의내용을확인하지못하고문제점을가지고있는애플리케이션을재배포하는등의문제가발생할수있기때문입니다.


IBM Korea



IBM Korea


요약

Summary

각단계별보안검토의필요

각단계별담당자에대한보안위험에대한이해요구

안전한애플리케이션의개발및운용을위한주체의확립요구

비용효율적인기법의도입을위한적절한자동화된솔루션적용요구

안전한애플리케이션의개발과취약점관리를위한일반적인수행절차를준수할필요가있음




IBM Korea

웹애플리케이션취약점효과적인관리를위한IBM Rational AppScan


IBM Korea


웹애플리케이션의문제점을지적하고관리하는 AppScan


IBM Korea


AppScan이제공하는기능

웹애플리케이션코드점검

가능성이있는취약점들과에러발견

발견된내용들이왜문제인지를전달

발견된내용들이어떻게규정및규제를위반하는지보고

무엇을어떻게수정해야하는지권고

모의해킹프로세스를접목

전사적인관리를가능하게하는 Scalability


IBM Korea


AppScan이제공하는주요가치

전세계에서가장잘알려진강력한기능및품질- 웹애플리케이션보안감사를선도하는최초의제품의진보된제품

- 애플리케이션의모든단계의작업에대한이해가능한수정안을제공하는유일한도구

- 일반사용자및전문가와모의해킹검사자를위한다양한도구

- 모든종류의운영체제에운영중인웹서버(IIS, 아파치, 넷스케이프등) 및기반기술(ASP, PHP, JSP, .Net 등)에대한인프라스트럭쳐및애플리케이션점검지원

- 웹애플리케이션을스캔하고, 보안문제점을검사하고적용가능한보고서와권고안을제공- 스캔능력, Zero-Day취약점업데이트, 구성마법사와세부보고시스템이모두더해져손쉽게이용가능

- 산업표준및가장폭넓게사용되는 40가지규정이행항목에대한별도의이행정보보고서제공

최상의시정과관리를모의해킹검사자와보안감사팀에게제공하는최상의조합


IBM Korea


AppScan 적용시기대효과

애플리케이션에대한단계별산출물단위로자동화된취약점평가및감사기능제공

검사결과에대한다양한보고서출력기능제공

취약점을명시하고수정권고기능제공

전반적인검사계획의키구성으로검사예약기능제공

다양한감사보고서를통한대상애플리케이션의감사기능

파이스캔을이용한 P.T.와의통합

운영중인사이트에대한손쉬운 문제점분석및진단가능

주기적인검사로신뢰높은사이트운영

해킹에대한분석으로담당자보안인식강화

손쉬운관리

보안예산감소가능

컨설팅비용및시간절약

보안담당자

측면

통합된애플리케이션에대한자동화된보안취약점검출기능제공

애플리케이션설계나개발시발생할수있는취약점검출기능제공

서드파티소프트웨어에서발생하는알려진취약점검출기능제공

애플리케이션그자체의코드나구성에기인해발생하는취약점검출기능제공

취약점을추적하고분석하는기능을이용한종합적인결과물산출기능

제공

개발된애플리케이션에대한손쉬운검증

문제점을화면으로확인

다양한도움말제공으로분석및수정

컨설팅비용및시간절약

운영자측면

개발시 실시간으로취약점및수정권고기능제공

모듈단위의자동화된검사기능제공

실시간라인취약점수정기능제공

검사나코딩시실시간으로보안교육이이루어짐

자동스크립트생성기능제공

개발시실시간으로보안검증가능

신뢰성높은개발업무수행가능

검사도구를활용함으로인해별도의교육없이자연스럽게보안코딩교육이가능

개발자측면

제공 기능기대효과부문


IBM Korea


AppScan이제공하는웹애플리케이션보안

AppScan EnterpriseAppScan Enterprise

SDLC를 통한웹 애플리케이션보안검사

AppScan DEAppScan DE AppScan QAAppScan QA AppScan SEAppScan SE

Test ApplicationsAs Developed

Test ApplicationsAs Developed

Test ApplicationsAs Part of

QA Process

Test ApplicationsAs Part of

QA Process

Test ApplicationsBefore

Deployment

Test ApplicationsBefore

Deployment

ApplicationDevelopment

QualityAssurance

SecurityAudit

ProductionMonitoring

애플리케이션개발

품질확인 보안감사 제품감시

개발과정에서애플리케이션검사

품질확인절차의한부분에서

애플리케이션검사

배포이전에애플리케이션검사

배포된애플리케이션의감시또는 재감사




IBM Korea

안전한웹애플리케이션개발추가적인참조사항


IBM Korea


추가적인고려사항

요구사항및분석

- 요구사항관리를이용되는케이스로개발하고비즈니스모델링및데이터모델링을이용하여프로젝트위험감소를목적으로함

- 개발인프라: 요구사항및분석을통합된도구를이용하여시간을절약하고재작업을피하도록함

- 개발플랫폼: 요구사항및분석은결함추적, 설계및개발테스트도구와통합되어작업을손쉽게시작하고결과를빠르게산출할수있음.

- 요구사항및분석이고려대상인이유: 사용자의요구를이해하고그우선순위를파악하여애플리케이션개발및개발시필요한보안요구조건을효율적으로분석하여올바른설계지침을만들어낼수있음.

- 자동화된요구분석도구를이용하면사용자의요구사항을시스템과상호관계하는방식으로요구사항을구현하여애플리케이션요소간을손쉽게연결할수있음.

- 요구사항분석도구를통해구현하고자하는애플리케이션과비즈니스프로세스를분석하여최적화하여유용한프레임워크를구현할수있도록함. 프로세스를실시간모니터하여복잡한흐름을분석하고병목지점혹은문제지점을정확하게파악할수있음.


IBM Korea


추가적인고려사항

안전한 Coding 도구

기운영중인애플리케이션에대한보안고려사항검토

- CMMI(Capability Maturity Model® Integration)를이용한애플리케이션보안성증진

- 마이크로소프트의 DREAD-BASED 위험스코어링을적용한위험도분석


IBM Korea


웹애플리케이션을이용한서비스제공시요구되는제반사항고려

보안항목고려를위한구조와설계를검토

- 배포와기반기술고려사항

- 애플리케이션구조와설계고려사항

Input ValidationAuthenticationAuthorizationConfiguration ManagementSensitive DataSession ManagementCryptographyParameter ManipulationException ManagementAuditing and Logging

기반기술(언어)보안: ASP.NET의예

- 설계고려사항

Auditing and LoggingAuthentication –FormsAuthorizationCode Access SecurityData AccessException ManagementInput/Data ValidationImpersonation/DelegationParameter ManipulationSensitive DataSession Management

- Deployment 고려사항- Communication Security


IBM Korea



CLR/Managed Code보안: .Net Framework의예- General Code Review Guideline

잠재적인위협은명확히문서화한다(위협들은특정시나리오와조합형태에좌우됨)개발된코드가어떤 Coding 가이드라인을따르고 Secure Coding을위한어떤가이드라인을사용했는지확인Managed Code Review Guideline

- Assembly-Level Checks- Class-Level Checks- Cryptography- Secrets- Exception Management- Delegates- Serialization- Threading- Reflection- Unmanaged Code Access자원접근고려사항

- File I/O- Event Log- Registry- Environment Variables


IBM Korea



데이터접근보안

- SQL Injection Checks- Authentication- Authorization- Configuration Management- Sensitive Data- Exception management- 배포고려사항

엔터프라이즈서비스보안

- 개발자확인사항

AuthenticationAuthorizationConfiguration ManagementSensitive DataAuditing and Logging배포고려사항

Impersonation

- 관리자확인


IBM Korea



네트워크보안

- Router 고려사항- 방화벽고려사항

- 스위치고려사항

원격보안

- Design ConsiderationsInput ValidationAuthenticationAuthorizationConfiguration ManagementSensitive DataException ManagementAuditing and Logging


IBM Korea



웹서버보안(예: IIS 5/5.1의경우)- Patches and Updates- IISLockdown- Services- Protocols- Accounts- Files and Directories- Shares- Ports - Registry- Auditing and Logging- Sites and Virtual Directories- ISAPI Filters- IIS Metabase- Server Certificates- Machine.config- Code Access Security- Other Considerations.

웹서비스보안: ASMX 1.1의예- Design Considerations- Development Considerations

Input ValidationAuthenticationAuthorization Sensitive DataParameter manipulationException managementAuditing and LoggingProxy ConsiderationsAdministration Considerations


IBM Korea



웹애플리케이션에대한위협모델구축

- 1단계: Identify Security Objectives- 2단계: Create an Application Overview- 3단계: Decompose Your Application- 4단계: Identify Threats- 5단계: identify Vulnerabilities


IBM Korea


감사합니다감사합니다..

㈜시드시스템서울시영등포구양평동 1가 31-10 MK빌딩 5층우편번호 150-862 대표전화: (02)2635-7985 팩스: (02)2635-7986영업지원: [email protected]기술지원: [email protected]

Secure your Web business infrastructure with us, you will improve the value of your business and Service on the internet.

웹애플리케이션취약점 어떻게관리해야하는가 - dbguide.net · 2007. 12. 6. ·...

Documents