SDL: Security Development Lifecycle

MS site Link
The Trustworthy Computing Security Development Lifecycle

보안에 대해 곤욕을 치르고 있는 MS. 드디어 이러 해괴 망칙한 것까지 만들어 내다. -0-

전통적인 관점에서 보자면 Security Vulerability는 일종의 버그라 할 수 있다. 그것이 특정 컨디션(케이스)이 되면 오동작을 하고 프로그램이 종료되거나 임의코드 수행이나 정의된 동작이 아닌 다른 동작을 수행하는 것이다. 그래서 이를 Testing이나 Verification의 차원에서 점검하는 것이 일반적이었다. 하지만 SDL에서는 Security Requirement라는 것을 정의를 하고 이에 따른 개발 Process를 거치도록 한것이다. 그리고 Requirement나 Design 단계를 보면 완전히 제품의 요구사항과는 별개로 놀고 있다. 물론 Release 단계가 없듯 제품에 어떤 변화를 주고자하는 것보다는 Support의 Lifecycle이라 할 수 있다. (시제로는 무수한 Security Patch를 쏟아 내기도 하겠지만 --;)

최근에 ZeroBoard가 보안문제로 시끄러웠던 적이 있다. 이전의 서비스데몬/인터넷 어플레케이션들이 패스워드를 유출하거나 인증을 뛰어넘는 접근등으로 문제가 된적이 있었다. 아직도 많은 바이러스들이 시스템 커널이나 서비스를 직접 공략하지만 일부는 MSN이나 Outlook등의 일반 어플리케이션, 그리고 웹상의 어플리케이션을 공략하곤 한다. MS의 경우 Windows만 보안성을 점검해야 하는 것이 아니라 Exchange나 IIS같은 각종 Server들과 아웃룩등의 제품들도 대상이 되는 것이다. 이는 일반 기업들도 마찬가지다. Compression Tool을 만드는 회사라 하더라도 압축파일을 다룸에 있어 잘못된 정보에 대해 Arbitary Code Execution같은 버그라도 존재한다 치면 바이러스 유포의 원천이 될 수 있는 것이다.

보안적인 관점에서 이런 식의 접근은 상당히 정형화되었다는 것에 점수를 주고 싶고 소프트웨어공학적으로도 이런 식의 이야기도 썰이 풀리는 구나 하는 생각이 든다. 공정이란 만들면 되는것. 뭔가 개선할 것이 있다면 측정하고 분석하고는 기존의 비슷한 방법에 끼워 맞추면 뭔가 그럴싸 한게 나오나 보다. 실제 가치성에 대해서는 위의 링크에서 몇가지 예를 보여 주면서 좋아졌다고는 하나 액면 그대로 밑기에는 여러 요소들이 있다. 가령 post 단계는 제품 유지보수의 후반이라던가.. pre 단계에서 많이 잡았다던가 등등등.