나경아빠의 스케치북 - 고통은 희망의 씨앗이다

기말고사 대비 허접 요약

1. 전자금융거래의 개념

- 금융회사와 전자금융업자가 전자적 장치(CD/ATM, 전화, 휴대폰, 카드 단말기 등)을 이용하여 이용자에게 "비대면"

   "비서면"으로 전자금융서비스 - 전자 여/수신, 전자 증권거래, 전자 보험거래, 전자 지급거래 등 - 를 제공하는 것

- 전자어음거래는 전자금융거래에 포함되지 않는다(전자어음법 적용 때문)

2. 전자금융거래에 있어서 본인인증 종류

1) ID, Password 인증

2) 공인인증서 인증

3) SMS 인증 - 인증번호 입력

4) ARS 인증 - ARS 에서 요구하는 인증번호 입력

5) 단말기 지정 인증

6) OTP 인증 - otp 번호를 휴대폰으로 전송 후 입력

3. 전자금융거래에 있어 공인인증서 사용에 대한 찬성과 반대 입장, 그 이유

- 찬성

- 사설 인증서 필요

- active x 방식 개선 필요

4. 메모리 해킹 수법, 대응방안

1) 2013.6 유형 (1) 메모리 해킹

① 수법

- 이용자가 전자금융 이체 중 공격자는 보안 프로그램을 무력화시키고 이체를 실패를 반복적으로 발생

   시켜 고객의 금융정보들을 탈취하여 사기범 컴퓨터에서 탈취한 정보로 이체

② 대응

- 사기범은 전자금융관련 규정에서 전자금융 이체시 오류가 났을 때 오류가 난 보안카드 번호를 

   다시 물어보는 취약점을 이용하여 이체가 가능

- 전자금융 이체시 오류가 난 컴퓨터와 다른 컴퓨터에서 이체가 있을 시 새로운 보안카드 번호 요구

2) 2013.8 유형(2) 메모리 해킹

① 수법

- 이용자가 전자금융 이체 완료 후 공격자는 악성코드에 의한 보안카드 번호(앞뒤 2자리)를 팝업시켜 보안

   카드 등 금융정보들을 탈취하여 사기범 컴퓨터에서 탈취한 정보로 이체

② 대응

- 대 고객 안내

- 보안 프로그램 패치

3) 2013.9 유형(3) 메모리 해킹

① 수법

- 이용자가 전자금융 이체 중 공격자는 금융회사로 전송하는 이체 전문의 계좌번호를 변조하여 이용자가

   입력하지 않은 사기범 계좌로 이체

- 키보드 보안, 구간 암호화(E2E, End to End) 보안 정책이 브라우저의 DOM 영역에서 일시적으로 평문이

   노출되는 취약점을 이용

② 대응

- 확장 E2E

- 금융부가정보(수취은행명, 수취계좌명, 금액, 이체건수 등) 가 포함된 전화인증/문자인증 강화

5. DDoS 공격의 개념과 대응방안

1) 공격 개념

- 정상 이용자들 컴퓨터를 감염시키고 명령을 전달할 C&C 서버 확보

- 정상 이용자들이 C&C 서버로 접속할 수 있도록 C&C 서버 주소가 삽입된 악성코드를 정상 이용자들이 

   접속하는 정상 사이트에 주입 또는 감염시킴

- 정상 이용자들이 정상 사이트에서 C&C 서버 주소가 삽입된 파일을 다운로드 받음

- 다운로드된 파일은 정상 이용자들 컴퓨터가 C&C 서버로 접속시킴

- 공격자는 C&C 서버를 통해서 명령을 내리고 공격 명령을 내림

- 감염된 이용자들은 공격 대상 사이트로 접속

- 공격을 받은 사이트 또는 서버는 네트워크 트랙픽 대역폭, CPU, 메모리, 커넥션 개수 등의 자원 감소로

   서비스가 지연

- 해당 사이트를 이용하는 정상 이용자들은 서비스 받지 못함

2) 대응

- Anti DDoS 서버 설치

- 통신회사를 통해서 비정상 패킷을 차단

- 서버의 커넥션 유지 시간 감소, 커넥션 개수 증가 등 조치

6. 내부정보 유출 유형과 대응 방안

1) DB 대량조회 후 출력 또는 파일 다운로드

2) 업무용 백오피스 시스템에서 조회 후 출력 또는 파일 다운로드 

3) 테스트 서버에서 실 운영 서버와 같은 데이터 대량조회 후 출력 또는 다운로드

7. IT 아웃소싱에 대한 정보유출 방지 대책

- DB 에서 개인정보 대량 조회 탐지 (테이블, 컬럼, 주민번호 복호화 명령 모니터링)

- 배치, 조회, 개발 시 관리자/팀장의 이중 결제

- 물리적 망분리

- 개인정보 DB 조회용 전용 DB 계정 사용 및 통제

8. 스마트폰 기반 모바일 금융에 대한 위협 두 가지의 개념과 대응 방안

- 모르겠다

- 왜 두가지지?

9. 카드사 정보 유출 원인과 대책

1) 원인

- USB 쓰기 권한 통제가 되지 않음

- 테스트용 데이터를 실 운영 서버에서 조회해서 외주 직원에게 전달

2) 대책

- USB 쓰기 통제가 되는 보안 프로그램 설치, 삭제 불가능

- 실 운영 데이터는 테스트 서버로 가상의 주민번호, 이름, 주소 등으로 변환되고 테스트 데이터는

   변환된 테스트 서버에서 추출해서 테스트에 이용 처리

10. 전산센터 마비 요인 중 가장 크다고 판단한 두 가지 요인 및 대응방안

1) 요인

- 스마트 기기 확산에 따른 출입통제 항목 증가(구글 글래스, 웨어러블 스마트 기기 등)

- 전력선 이중화 -> 현실적으로 2개의 변전소, 2개의 전력회사로부터 전기 수급이 힘듬

2) 대응방안

- 전통적인 출입통제 방식의 변화

- 주요소 주유를 통한 발전기 

실질적인 첫 수업.

수업의 주요 내용은 오늘 발표한 "금융분야 개인정보 유출 재발방지 종합대책" 을 설명

아래 내용은 수업 내용을 포함하여 종합대책을 별도로 정리

보도자료_금융분야_개인정보_유출_재발방지_종합대책.hwp

별첨_금융분야_개인정보_유출_재발방지_종합대책.hwp

1. 수집정보의 필요최소화

1) 금융업권별, 상품별로 30~50여개인 수집정보 항목을 필수항목(6~10개)과 선택

   항목으로 구분, 최소화

2. 주민번호 과다노출 관행 개선

1) 최초 거래시에만 주민번호 수집

-> 계좌 개설, 상품 가입 등 화면에서만 주민번호 입력값을 둬야함.

2) 이후에는 주민번호 기입없이 신원확인 절차 거치도록 하여 노출 최소화

-> 백오피스 등에서 고객 확인용 주민번호 입력박스 제거

3) 수집한 주민번호는 내외부망 모두 암호화 저장

4) 주민번호를 불법활용 또는 유출한 경우에는 과태료 및 과징금 가중

-> 내부, 외부에서 주민번호를 입력값으로 하여 조회시 모니터링 필요

-> 출력 결과값에 주민번호 제거

-> 자료출력 업무는 보안팀, 컴플라이언스팀의 승인, 통제 프로세스 필요

3. 제3자 정보제공의 구체화

1) 제공되는 정보의 내용, 이용목적, 정보가 제공되는 업체명 및 업체 수, 제공기간,

    및 파기계획을 구체적으로 적시

->1년, 2년 등 명확한 제공기간 적시 후 모니터링 통해 해당 기간 도래시 

   파기할 수 있도록 개발

4. 무차별 비대면 방식의 개인정보 활용 엄격화

1) 무차별적 문자전송을 통한 권유, 모집 등 영업행위 금지

-> 지점, 마케팅에서의 상품 안내 SMS 발송 금지

2) 이메일, 전화 등 비대면 영업에 대한 엄격한 통제방안 마련

- 이메일의 제목, 전화상담시 우선적으로 "소속회사, 송부인, 연락목적 및 정보획

   득경로" 등을 명확히 안내

-> 고객의 연락처, 상품만기 등에 대해 정보를 어디서 획득했는지 DB 에

    보관하도록 개발

5. 신입금계좌지정 서비스 : 금융사기 피해를 최소화하고자 미지정 계좌로는 소액이체

-> 소액이체를 하루에 한번 허용할건지, 매 이체마다 소액만으로 하면 여러번

    가능한건지 등 개발 검토 필요

-> 기존 전자금융사기 예방서비스에 적용 검토, 금액은 유동적으로 개발

-> 이상금융거래탐지 시스템과 충돌 검토

6. 필요한 기간만 엄격히 보관 후 파기

1) 거래종료 후 3개월후에 원칙적으로 필요한 정보(식별정보, 거래정보 등)만 보관하

    하고 파기(예 : 학력, 직업, 직위 등) (1단계 보호조치)

-> 별도 Table 에 파기될 정보를 보관하도록 개발

-> 파기할 대상 선정하고 이체, 로그인, 주문, 보험료 납입, 카드 결제 등 이

    후 3개월동안 거래 없는지 조회 후 조치. 일상 배치

-> 다시 거래가 일어나면 복원 검토

2) 거래종료 후 5년이 경과한 정보는 원칙적으로 모두 파기 (2단계 보호조치)

-> 해당 고객들의 정보는 별도 DB 로 모두 이관

-> 전체 정보를 암호화 -> 주민번호 외 모든 정보 암호화 확인 필요

7. 본인정보 이용, 제공 현황 조회 요청권

- 고객이 본인의 신용정보가 이용, 제공되고 있는 현화(이용/제공주체, 목적, 날짜 등)

   을 언제든지 확인할 수 있는 조회시스템 구축

-> 입력값으로 주민번호는 사용 불가

-> 개인별로 정보제공 상세 정보(업체, 기간, 목적, 파기여부 등)를 웹, 업무

    시스템에 개발

8. 연락중지 청구권

-> 자료출력, 지점, 본사에서 전화, SMS 발송 대상 조회 시 이 값을 확인해야함

9. 정보 보호 청구권

- 고객이 거래종료 이후 본인정보를 보호할 것을 요청할 경우 금융회사는 파기 및 

   보안조치를 취하고 그 결과를 즉시 통보

-> 해당 고객의 정보를 DB 에서 발췌해서 바로 별도 DB 로 이관하고 암호화

    하도록 개발

10. 정보보안 주기적 점검 강화

- 금융회사별 "보안점검의 날"을 지정하여 CISO 책임하에 매월 보안점검을 실시하고

   CEO에게 점검결과 및 보완계획을 보고. 금감원에 제출

-> 매년 취약점 점검하는 것처럼 한다면 매달 엄청한 작업

-> 금융보안 표준 체크리스트 기준으로 한다고 해도 557 규정 인력으로는       부담