|
http://www.hackerschool.org/HS_Boards/zboard.php?AllArticle=true&no=11 [복사]
별표랑 영어섞여 있는 부분들은 도저히 뭐라고 하는지 알아들을 수가 없네요.
해외 사시는 능력자분들이나 들리시는 분들은 좀 다듬어주시면 감사하겠습니다!
누가 위협 모델링을 해야 할까요?
so who should threat model?
전형적으로 저는 꼭 개발자를 전체 위협 모델링 과정에 참여하게 할 것을 권장해드립니다.
typically, i will recommend the developers must be involved in the entire process of threat model.
왜 개발자들이 위협 모델링을 해야할까요?
why would you think the developers must be involved in threat models?
개발자들은 코드를 만들면서 어느 부분에 가장 특별한 주의를 기울여야 하는지 알아야 하기 때문입니다.
so that they can figure out 'where exactly they need to make sure that paying extra attention' to developing codes
프로젝트 매니저들 또한 확실히 포함되어야합니다.
project managers need to be involved
저기 보이는 것처럼 개발 일정을 정하기 때문이죠.
obvioulsy because they will have to additional timeline over there
그리고 비즈니스 개발자, 예전부터 대부분의 경우에서 제품을 (소유한? 의 소유권을 가지고 있는?) 사람들입니다, 그들도 포함되어야합니다.
and business devs -the people who generally own the products yesterday and most of the cases,- they need to be involved.
위협 모델링을 언제 해야 할까요?
when should you threat model?
이건 정말 정말 중요한 질문입니다.
this is a really really big question.
모든 위협 모델링의 예시들은 제각기 다른 시간대에 하라고 말합니다.
every organization threat model at a different time period
저는 일반적으로 디자인 단계 바로 다음에 위협 모델링을 할 것을 추천해드립니다.
typically i would recommend that you threat model just after the design stage
기능적인 면에서 프로그램의 목적에 대해 세세하게 설계하자마자 말이죠.
once you've figured a lot of details from the functionality point of your what your application should do
then you'll do the threat modelling
그리고 테스트 단계 전에도 위협 모델링을 해야합니다.
and then you again do it before the testing stage.
하지만 마이크로소프트는 위협 모델링을 테스트 단계에서만 해도 된다고 말합니다.
but microsoft says that you should just threat model towards testing stage
또 어떤 그룹은 개발을 완료하고 배포하기 직전에 해도 된다고 합니다.
and there are different organazations that say that you should just do it at the end of the products before releasing it
네 아주 정확하죠.
yeah exactly.
(프레젠테이션: 프로그램이 배포되고 취약점이 발견되고 나서야 위협 모델링을 함, 메모:어떤 프로그램, 내부 전용이라도 위협 모델링을 해야 함)
그래서, 보시는 바와 같이 전형적으로 배포되고 나서야 위협 모델링이 이루어집니다.
so typically now as you can see most of the applications are threat models just after the release
왜냐고요?
why?
대부분은 취약점이 있는 제품을 출시하고 나서야 그들은 "맙소사 여기 취약점이 있어! 다른 곳은 어떤지 위협 모델링을 해보자"라고 말합니다.
because they would be vulnerable released on product ****? they will say 'oh my god, there's vulnerabilities let's threat model and try to figure out where are the other areas
하지만 그러려면 그들은 맨 처음 주요 취약점들이 존재했던 곳으로 되돌아가야합니다.
but they have to go back and actually take from the very beginning what are the major ******** and what are the major locations there vulnerabilities could exist
여기 간단한 폭포수 모델이 있습니다.
so here's a simple waterfall model.
초기 위협 모델링의 권장되는 위치는 프로그램 디자인을 마치자 마자가 되겠죠.
recommended loaction should be initial threat model right after the program design.
그리고 테스트 단계 직전에도 다시 해봐야 합니다.
revisit threat model right before the testing stage
하지만 크래커들과 코드 리뷰어들은 이 모든 일들이 일어나고 나서야 합니다.
but attackers and code reviewers typically these days do it right after everything is happened
너무 늦습니다. 공격당하기 매우 좋은 상황이죠.
it is too late. it's a bandit situation over there.
뭔가 이미 잘못된 걸 고치려고 하면
you just trying to fix something that is already broken
프로그램의 전체 디자인이 깨질 수도 있는 상황인거죠
it might be the entire design of the application might be broken.
나중에 몇몇 기초 디자인의 문제에 대한 예를 들어볼겁니다.
and we'll talk about some basic design issues as well in the examples.
위협 모델링은 어떻게 하는 걸까요?
how to threat model?
위협 모델링은 크게 3단계로 나눌 수 있습니다.
threat model has 3 major processes
처음은 프로그램에 대한 정보를 수집하는 것입니다.
it is collecting information about the applications.
프로그램의 목적이 무엇인지 알아내는 것이죠.
figure out "what's the goal of the application is"
이 프로그램은 어디에 쓰이는가, 뭘 위해 만들어졌는가, 내부에서만 쓰이는 인트라넷 전용 프로그램인가?
where has it to *****, what is the purpose of the application, is it just a intranet application?
확신하기 위해 문서화하세요.
document it for sure
(왜냐하면,) 아마 모든 분들이 최소한 한 번쯤은 내부 사용자 전용으로 디자인 된 프로그램이 갑자기 인터넷에 올라와 있는 것을 본 적이 있으실겁니다.
because, i know all of you have gone through at least one application that was initialy designed for internal use only and it sudddenly on the internet.
그런 일은 항상 일어납니다.
and that happens all the time.
만약 프로그램의 목적이 뭐였는지, 전체적인 양상이 무엇이었는지를 문서화하지 않았다면
and if you have not documente that what the goal was, what the whole aspects
*******************************
never c???? generally are easy ?*****
그들은 가장 빨리 나가는 통로를 찾아 나갈 것입니다.
they're gonna take the quickest way out
********
******분명 누군가가 이렇게 생각할겁니다
one of **** will think
"아 이거 별거 아니네, 비밀번호는 그냥 여기 대충 던져놓고 편안하게 생각하자."
"ah, it's not a big deal, let me just put the password here and let's make it easy"
내부 사용자 전용이잖아요. 누가 신경써요. 그렇죠?
and it's literally internal use only. who cares? right?
????????????????????????
but the ******(matter is?) it's going to go to the internet if this document is there at least someone might be review it ******** they will review it
프로그램을 분석하세요.
decompose the application.
- 프로그램을 (해부해서?) 프로그램의 데이터 흐름도를 그려서
프로그램의 데이터 흐름에 대해 더 큰 이해를 할 수 있게 말입니다
we'll talk about breaking the application and what are the appliction basically
draw some kinds of data flow diagram to get a bigger understanding of the data flow of the application
- 어디서 시작되고 어디서 끝나는지, 뭘 어느 위치에서 가로챌 수 있는지요
where does it starts, where does it ends, what are the locations that might be intercepts happening.
그리고 보안 위협들을 자세히 분석하세요.
and then do detail analysis of threats.
저는 이게 누구에게도 보안적이고 개발자의 관점에서 물어보기에 가장 어렵다고 생각합니다.
this in my opinion is the most difficult to ask for anyone from security perspectives and developers perspectives.
그리고 보안 위협에 대한 자세한 분석을 하는 사람들이나 보안 개발자들은 매우 드뭅니다. 제 생각으로는요
the ideal people to do the detail analysis the threats or security developers, who are in my opinion very rare to find
수많은 각기 다른 취약점들의 리스트를 구하려면 할 수 있겠지만,
you can get a list of all the different types of vulnerabilities but
사람들은 꼭 아키텍처적인 측면에서 생각하지만은 않습니다.
people do not really think from the architecure level
******************************************************
umm now these with all the securities who *** every ****
CISSP 인증을 취득하거나 취업 등등을 하려고 하는 사람들-
trying to get CISSP and get a job and do anything and everything.
so becareful who is involved at that st*** and we'll talk it little bit more *****-?
프로그램의 정보를 수집하는 것, 바로 첫 단계죠
so collecting background information, this is process step one.
프로그램이 어떻게 만들어졌는지,
how the application was built,
의존 관계는 어떤지,
what are the dependencies
상호 프로세스 의존적(inter-process dependencies)인지,
is it inter-process dependencies,
외부 의존성은 LPC인지 RPC인지
are there any external dependencies is LPC, RPC
정확히 무엇이 작동되는지
what exactly is happening there
네임드 파이프을 포함하고 있는지, 원격 네임드 파이프인지,
is it creating named pipes, does they need remote named pipes,
권한은 적절한지,<<*********
are the premissions **** popers,
무엇으로 무엇을 하는지를 반드시 문서화해야합니다.
anything to do with anything should be documented over here |
Hit : 2499 Date : 2011/05/04 06:44
|
97, 
1/4 
멍멍
