|
http://www.hackerschool.org/HS_Boards/zboard.php?AllArticle=true&no=13 [복사]
so basically, You're saying that, I'm saying that
when an application is in design stage
기본적으로 응용 프로그램 설계 단계에 있을 때,
or when you are about to do threat analysis hopefully this is still in design stage.
혹시 위협 분석을 하려고 할 때, 바라건데 이것도 아직은 설계 단계입니다.
you should have full knowledge of this background
당신은 이 배경을 모두 잘 알아야만 합니다.
or at least as mush knowledge as possible
혹은 가능한한 많이 알아야 합니다.
and there're too much knowlodges also handful so you know
그릐고 세상엔 너무 많고 어려운 지식들이 있습니다.
you want to have as much knowledge as a from a security perspective focus
당신은 보안적인 시각에 초점을 맞춘 많은 지식을 원합니다.
sit with the developers, talk to them, get the knowledge
** them
개발자들과 함께 앉아서 대화를 하고, 지식을 얻으세요.
decompose application
응용 프로그램 분해하기
so break the application into major chunks
응용 프로그램을 중요한 부분들로 쪼갭니다.
you can either break it to indivisual component type
그것을 개별적인 컴포넌트 형태로 쪼갤 수 있습니다.
by the entry point, trust point
entry point와 trust post로 말입니다.
you can break into application architecture level itself
그리고 응용 프로그램을 아키텍쳐 레벨로 쪼갤 수도 있습니다.
uh.. what is an application architecture?
응용 프로그램 아키텍쳐란?
authentication, authorization, session management,
인증, 허가, 세션 관리...
you break the application into these specific areas
ok
이처럼 응용 프로그램을 특정한 영역으로 나눌 수 있습니다.
once you have this specific area
이처럼 특정한 영역으로 나눌 때,
you can isolatate them and you can focus *** problem or **** perspective
그것들을 따로 떼어낼 수 있고, *** 문제 혹은 *** 관점에만 초점을 맞출 수 있습니다.
you can say ok this person is good at authentication stuff
그리고 '이 사람은 인증쪽을 잘해'
so and crypto stuff
'그리고 암호학을 잘해' 이런식으로 말할 수 있습니다.
so lets get him going* in that authentication in crypto level
이제 그 사람을 인증과 암호학 쪽에 할당을 시킵니다.
you can seperate it and you have actual physical seperation of reviewing code
이렇게 나눌 수 있고, 코드 리뷰의 실제 물리적인 구분을 가지게 됩니다.
right now what happens typically is they hire ten people review the code
보통은 코드 리뷰를 위한 10명을 사람을 고용해서
everybody is reviewing it's pretty bizarre
모두가 같은 리뷰를 맡게 합니다. 아주 특이합니니다.
if you actually break down into separate chunks it might became easier
하지만 여러 영역으로 나누면 일이 더 쉬워집니다.
the other matter that you can do is break in into indivisual components
또 다른 방법은 개별적인 컴포넌트로 나누는 것입니다.
identify all entry point the network accessible, locally accessible
모든 entry point, 즉 네트워크 접근, 로컬 접근을 확인합니다.
and identify the trust levels
그리고 trust level들을 확인합니다.
this is typically what microsoft recommends
이것은 MS가 추천하는 방식이기도 합니다.
so modeling the ar... modeling system itself
그래서 시스템 자체를 모델링합니다.
this is the third level
이것은 세번째 단계입니다.
you can either do at third process stage
세 번째 프로세스 단계에서 해도 되며,
you can either draw dataflow diagrams
dataflow 다이어그램을 그려도 됩니다.
what is the dataflow diagrams?
dataflow 다이어그램이란?
it's just a graphical representation of your entire data
단지 전체 데이터를 그래픽적으로 표현한 것입니다.
how it's flowing from start to finish
시작에서 끝까지 어떻게 흘러가는지..
I'm sure all of you know uh.. the details of dataflow diagrams ****
dataflow 다이어그램에 대해선 잘 알고 계실 거라 생각합니다.
and then do a detailed analysis of a determined threats
다음엔 명백한 위협에 대한 세부적인 분석에 들어갑니다.
this is the part where, again it's the single biggest challenge in my mind
저는 이 부분이 가장 어려운 문제라고 생각합니다.
you have to figure out what the possbility dangers are to the application
응용 프로그램에 발생할 수 있는 위험성이 무엇인지를 알아내야 합니다.
so far we have not touch the code
아직까진 코드를 언급하지 않았습니다.
we are still thinking from threat analsysis point of view
우리는 아직 위협 분석 관점에서만 보고 있습니다.
i just want to keep that.. keep that in your mind right now
지금 기억하시기 바랍니다.
and figure out what is vulnerabilty?
그리고 취약점이 무엇인지 알아야 합니다.
vulnerabilty is when a thread is susceptible to in an attack
위협이 공격을 허용할 때, 그것을 취약점이라 합니다.
it is not *** attack, but it could be an attack
ok
*** 공격은 아니지만, 공격이 될 수 있습니다.
something might be a threat but it might not a vulnerability
위협은 되지만 취약점이 되지는 않을 수 있습니다.
but every vulnerablity has to be a threat
그러나 모든 취약점들은 위협이 됩니다.
it's a unmitigated threat
완전한 위협입니다.
it's what a vulnerabilty is
이것이 바로 취약점입니다.
and if few have not thought of the threat before hand it,
그리고 만약 위협에 대해 미리미리 생각하지 않는다면,
it is likely that it would turn into a vulnerability
그것이 나중에는 취약점이 될 수가 있습니다.
because you have obviously not level confirmations to accepts*
단계 구분이 확실하게 되어있지 않기 때문입니다.
so here are couple of definitions
여기 몇개의 정의가 있습니다.
which are dictionary.com and writing secure code
dictionary.com과 writing secure code 서적에서 발췌한 것입니다.
talk about different between threats, risks, and vulnerabilities
위협, 위험요소, 취약점의 차이점에 대해 말하고 있습니다.
so, basically threat is a malicious entity that might try to attack
기본적으로 위협이란 공격을 시도하는 악의적인 독립체를 말합니다.
I think I made some mistakes over there.. a malicious
(저건 실수를 한거 같네요 a malicious)
a threat does not constitute vulnerablity
위협이 취약점으로 여겨지지는 않습니다.
and basically is something that could be exploited but we dont have information about it
ok?
그리고 exploit이 가능할 수는 있지만, 그것에 대한 아무런 정보를 가지고 있지 않은 상태입니다.
risks, something might go wrong
위험 요소란, 뭔가가 잘못되어가고 있다는 것을 의미합니다.
and finally, vulnerability is definitly there is a weakness which has or has not yet been exploited
ok
그리고 마지막으로 취약점이란, 명백한 결점이 있고, 이미 exploit 되었거나 아직 exploit되지 않은 것을 말합니다.
assigning values all the theats that you bigger doubt
의심스러운 모든 위협에 가치를 부여합니다.
this is the second most important part of thread analysis
이번엔 위협 분석에 있어서 두번째로 중요한 것입니다.
a pre-source code review
바로 소스 코드 리뷰입니다.
so microsoft came out with the standard DREAD model you know
아시다시피, MS는 표준 DREAD 모델을 제시했습니다.
figure out damage reproduce simplity, exploitablity and assigned number between one to ten
um...
피해 재현을 간단히하고, exploit 가능성을 1에서 10까지의 숫자로 구분합니다.
when I used to teach class of writing secure code or source code reviews
제가 write secure code이나 source code review 수업을 할 때,
we use go under DREAD modeling and everyone used to ask me this question
우리는 DREAD 모델링을 사용하고, 모두가 이러한 질문을 합니다.
which I had a lot of difficulty answering
이에 대한 답변을 하기가 꽤 어렵습니다.
how do you assign of value to damage to potential or any of these between one and ten?
피해 가능성이나 이러한 1부터 10까지의 숫자들을 어떤 기준으로 할당하죠?
how figure it out, is there a standard?
어떻게 그걸 알까요? 표준이 있나요?
and unfortunatly there is information about it
하지만 아쉽게도 이에대한 정보는 없습니다.
but it's pretty much pulling it out of your behind
하지만 생각하는 것보다 꽤 많은 것이 있습니다.
잘 안 들렸던 부분은 해외에 거주하고 있는 슈퍼 짱 z0nk님아가 도와주었습니다.
해석은 좀... 발 해석입니다.. ㅎㅎ
|
Hit : 2354 Date : 2011/05/09 04:49
|
97, 
1/4 
멍멍
