현재 위치: WiKi Security Spirit » Business Certifications » A사 보안솔루션 취약점 진단 사례

차이

문서의 선택한 두 판 사이의 차이를 보여줍니다.

--- wiki_security_corp:a사_개발_보안솔루션_취약점_진단_사례 [2014/09/23 09:31] – 새로 만듦 wiki1122
+++ wiki_security_corp:a사_개발_보안솔루션_취약점_진단_사례 [2015/04/13 02:11] – wiki1122
@@ 줄 1: / 줄 1: @@
 {{keywords>CC인증,STRIDE,위협분석,취약성,진단,개선대책,가중치,금융기관,국제표준,정보자산,IT,금융그룹,이해관계자,실무자,인증,유지관리,인증획득,컨설팅,상위감독기관,관리체계,보안솔루션,금융기업,금융감독원,유출사고,글로벌,그룹정책,중요도평가,정보보호,정보보안,위험조치계획,취약점진단,모의해킹진단,계획서,결과보고서,효과성분석,프로젝트성공요인,컨설팅산출물}}
+* 사업 등 관련 문의: T) 02-322-4688, F) 02-322-4646, E) [[info@wikisecurity.net]]
 ===== A사 보안솔루션 취약점 진단 사례 =====
@@ 줄 6: / 줄 9: @@
 ==== [ 배경 및 주제 ]====
-- A금융회사는 정보보안 추진계획에 따라 DB 접근통제 솔루션을 비롯하여 몇 종의 보안솔루션을 구축사업을 진행하였다. \\
+- A금융회사는 정보보안 추진계획에 따라 DB 접근통제 솔루션을 비롯하여 몇 종의 보안솔루션 구축사업을 진행하였다. \\
 - 금융감독규정에 따라 도입되는 모든 보안솔루션은 CC인증획득 솔루션이며, 도입 솔루션중에 하나인 DB접근통제 솔루션은 A사의 요구에 따라 대대적인 커스터마이징 요구를 한 상태이다. \\
 - DB접근통제 솔루션의 커스터마이징 요구에 따라 솔루션의 아키텍처를 비롯하여 많은 부분의 개발이 필요하게 되었으며 그에 따른 보안상의 안전성을 진단하여 검증을 받을 필요가 발생하였다. \\
-- 보안제품도 사람이 개발한 소프트웨어를 기반으로 하기 때문에 보안상의 헛점이 존재한다. \\
+- 보안제품도 사람에 의해 개발된 소프트웨어를 기반으로 하기 때문에 보안상의 헛점이 존재한다. \\
 - 특히 기존 아키텍처까지 변경을 가져오는 커스터마이징 상황에서는 예상하지 못했던 보안상의 다양한 문제점이 발생될 수도 있기 때문에 고객사에서는 해당 보안솔루션의 취약점 진단을 요청했다. \\
-- 기존의 보안시스템 취약점 진단 체크리스트나 기법은 이와 같은 상황에서 목적을 달성할 수 없기 때문에 보안 위협 시나리오 분석을 바탕으로 취약점을 진단하는 방법으로 진행을 하였다.
+- 기존의 보안시스템 취약점 진단 체크리스트나 기법은 이와 같은 상황에서 적합하지 않기 때문에 보안 위협 시나리오 분석을 바탕으로 취약점을 진단하는 방법으로 진행을 하였다.
 ==== [ 프로젝트 기간 ]====
@@ 줄 17: / 줄 20: @@
 ==== [ 주요 수행 내용 ]====
-- 해당 DB접근제어 솔루션의 계략적인 아키텍처는 사용자 PC에 설치되는 Agent와 DBMS 앞의 설치된 Proxy Gateway로 구성된 솔루션이다. \\
+- 해당 DB접근제어 솔루션의 개략적인 아키텍처는 사용자 PC에 설치되는 Agent와 DBMS 앞단에 설치된 Proxy Gateway로 구성된 솔루션이다. \\
-- Proxy Gateway서버에는 사용자 인증모듈, 보안정책 모듈, 접근기록관리 모듈 등이 탑재되어 사용자 접근통제, 권한권한관리, 접근기록관리 등의 기능을 제공한다. \\
+- Proxy Gateway서버에는 사용자 인증모듈, 보안정책 모듈, 접근기록관리 모듈 등이 탑재되어 사용자 접근통제, 권한관리, 접근기록관리 등의 기능을 제공한다. \\
-- 고객사의 커스터마이징 요구에 따라 PC agent의 변경은 없으나 Proxy Gateway가 2개의 별도 물리적 서버인 Gateway Server와 Log Server로 분리 구성되고 많은 부분의 추가개발이 필요하게 되었다. \\
+- 고객사의 커스터마이징 요구에 따라 PC agent의 변경은 없으나 Proxy Gateway가 2개의 다른 물리적 서버인 Gateway Server와 Log Server로 분리 구성되고 많은 부분의 추가개발이 필요하게 되었다. \\
 - 솔루션의 TO-BE 아키텍처를 분석하여 위협타겟을 설정하고 타겟별 발생가능한 위협들을 마이크로소프트사의 STRIDE분석 기법을 적용하여 위협을 분석하였다. \\
 - 위협분석결과로 도출된 시나리오에 따라 발생 가능한 위협에 대한 취약성을 진단하기 위한 취약점 점검항목을 개발하고, 점검항목별 취약점을 진단하는 방법론을 적용하였다. \\
-- 솔루션이 복잡하지 않기 때문에 위협타겟은 PC Agent를 포함하여 총 5개가 도출되었으며, 총 11개의 위협가 도출되었다. \\
+- 솔루션이 복잡하지 않기 때문에 위협타겟은 PC Agent를 포함하여 총 5개가 도출되었으며, 총 11개의 위협이 도출되었다. \\
-- 11개의 위협시나리오의 취약점 점검항목을 개발하여 취약점을 진단한 결과 Buffer overflow, Input validation, 접근제어 정책 모듈의 장애대응을 위한 watchdog 메커니즘 부재, 로그데이터의 무결성 확보 미흡 등의 취약점이 발견되었다. \\
+- 11개 위협시나리오의 취약점 점검항목을 개발하여 취약점을 진단한 결과 Buffer overflow, Input validation, 접근제어 정책 모듈의 장애대응을 위한 watchdog 메커니즘 부재, 로그데이터의 무결성 확보 미흡 등의 취약점이 발견되었다. \\
-- 해당 솔루션 업체는 고객사의 커스터마이징 요구사항과 더불어 발견된 취약점을 조치하는 일정을 계획하여 개발을 진행하였다. \\
+- 해당 솔루션 업체는 고객사의 커스터마이징 요구사항과 더불어 발견된 취약점을 조치하는 일정을 계획하여 개발 진행하였다. \\
 - 전반적인 수행절차는 아래와 같다. \\
 {{:wiki_security_corp:case-product-00.jpg?200|}}
@@ 줄 31: / 줄 34: @@
   * 대상 시스템의 물리적, 논리적 아키텍처 및 Process Diagram을 정확하게 파악하는 것이 중요
   * 기존의 체크리스트 기반의 취약점 진단기법은 목적달성에 한계가 있기 때문에 위협분석 기법 관점의 접근이 중요
-  * 개인의 경험에만 의존된 위협분석이 아니라 공신력있고 검증된 기법을 적용하여 누락되는 보안위협이 없도록 기법을 선택하는 것이 중요
+  * 개인의 경험에만 의존한 위협분석이 아니라 공신력있고 검증된 기법을 적용하여 누락되는 보안위협이 없도록 기법을 선택하는 것이 중요
 ==== [ 주요 Activity와 산출물 ]====
@@ 줄 44: / 줄 47: @@
 {{:wiki_security_corp:case-product-01.jpg?200|}}
 \\

추적:

차이

검색