저희 회사에서는 Microsoft 보안 개발 수명주기를 채택하기 위해 노력하고 있으며 MSDL 프로세스의 일부에는 보안 및 개인 정보 보호 버그 막대를 설정하는 것이 포함됩니다. 나는 MSDL 이전에 버그 바의 개념을 들었고 이것이 최종 제품에서 기꺼이 수용 할 수있는 버그의 수준 / 양에 대한 정의라는 것을 이해합니다. 프로젝트의 버그 바를 만드는 방법을 전혀 이해하지 못했습니다. 내가 배울 수있는 버그 바를 설정하는 잘 문서화 된 프로세스가 있습니까?
나는 프로젝트의 실제 시나리오 또는 예제를 위해 인터넷 검색을 시도했습니다. 프로젝트 시작시 버그 막대를 정의했지만 버그 막대를 설정하는 과정에 대한 좋은 결과 나 팁을 얻을 수없는 것 같습니다. MSDL 예제 완성 된 버그 바로 보이지만 이와 같은 것을 정의하는 과정에 대해 배우고 싶습니다. 예를 들어 이전에 이와 같은 작업을 수행 한 적이있는 사용자의 경우 매우 특정한 방식으로 버그 막대를 정의 했습니까 (예 : " 무단 파일 시스템 액세스는 허용되지 않습니다. 파일 시스템 ") 또는 버그를 발견하면 1 ~ 5 등급 (5 개가 가장 심각함)으로 등급을 매길 것이라고 말하는 지연된 접근 방식을 취했습니까? 3 이상의 버그는 배송되지 않으며 버그가 발견 될 때까지 버그 순위를 남겨 둡니다. 전자를하려고하는 것은 어리 석고 불가능한 활동이라고 생각하지만, 나중에는 프로젝트가 시작될 때 관대함으로 편향되는 경향이 있습니다.
다시 말해서 모든 것을 마무리합니다. 간결한 질문으로, 누구든지 버그 바를 정의 / 만들기위한 잘 문서화 된 접근 방식을 제공 할 수 있습니까?
답변
Let ” 버그 바에 대한 기본 정의로 시작합니다.
품질 게이트와 버그 바는 허용 가능한 최소 수준의 보안 및 개인 정보 보호 품질을 설정하는 데 사용됩니다. 프로젝트 팀 각 개발 단계에 대해 품질 게이트를 협상해야합니다 (예 : 코드 체크인 전에 모든 컴파일러 경고를 분류하고 수정해야 함). 버그 막대는 보안 취약성의 심각도 임계 값을 정의하는 데 사용되는 품질 게이트입니다. 예를 들면 다음과 같습니다. 출시 시점에 “중요”또는 “중요”등급을받은 응용 프로그램에 알려진 취약점이 없습니다. 버그 표시 줄이 설정되면 완화되어서는 안됩니다.
소프트웨어 사용자가 버그 보고서를 제출할 때 버그가 클라이언트 또는 서버 버그인지 여부와 버그가 영향을 미치는 범위 등 STRIDE 카테고리를 버그에 할당해야합니다. 사용자는 소프트웨어 개발자 및 QA 직원이 될 수 있습니다. STRIDE는 다음을 의미합니다.
- 스푸핑
- 조작
- 거부
- 정보 공개
- 서비스 거부 (DoS)
- EoP (권한 상승)
관련 “범위”값은 다음과 같습니다.
- 클라이언트-스푸핑 된 신뢰할 수있는 UI 공통 / 기본 시나리오
- 클라이언트-특정 다른 시나리오에서 스푸핑 된 신뢰할 수있는 UI
- 클라이언트-더 큰 공격 시나리오의 일부로 스푸핑 된 UI
- 서버-스푸핑 된 특정 사용자 또는 보안 프로토콜을 통한 컴퓨터
- 서버-보안 프로토콜을 통해 스푸핑 된 임의 사용자 또는 컴퓨터
- 클라이언트-다시 시작한 후에도 유지되는 변조 된 신뢰할 수있는 데이터
- 클라이언트-변조 된 데이터 재시작 후 유지되지 않음
여기에서 각 조합에 심각도 수준을 할당하는 매트릭스가 생성됩니다. 가능한 심각도 수준 값은 다음과 같습니다.
- 중요
- 중요
- 보통
- 낮음
- 없음
행렬의 예제 항목 (이러한 항목이 여러 개있을 수 있음) :
STRIDE 카테고리 : 스푸핑
범위 : 클라이언트-공통 / 기본 시나리오에서 스푸핑 된 신뢰할 수있는 UI설명 : 공격자가 표시 할 수있는 능력 사용자가 기본 / 일반 시나리오에서 유효한 신뢰 결정을 내리기 위해 의존해야하는 UI와 다르지만 시각적으로 동일한 UI 신뢰 결정은 시스템이나 특정 로컬 또는 원격 소스와 같은 특정 엔터티에서 일부 정보를 제공한다고 믿고 사용자가 작업을 수행 할 때마다 정의됩니다.
심각도 수준 : 중요
Microsoft는 배포하기 전에 중요도가 “낮음”보다 높은 모든 버그를 수정한다고 주장합니다.
추가 정보
Microsoft Team Foundation Server 2010에 보안 버그 표시 줄 추가
새로운 SDLC : 보안 개발 수명주기