2017.04.17

글로벌 칼럼 | 서드파티 보안 실패에서 은행이 배워야할 것들

Evan Schuman | Computerworld
가장 효과적인 사이버 공격은 우리가 취하는 보안 조치들을 피해가고 있다. 우리는 항상 과거에 발생했던 공격에 대응하고 있으며, 우리의 조치가 실패할 수 있는 가능성에 대해서는 거의 생각하지 않는다.


Credit: pixabay

가능성은 항상 존재한다. 첨부파일을 통해 악성코드(Malware)가 들어오는 경우를 보자. 우리는 직원들이 모르는 사람이 보낸 첨부파일을 열지 않도록 메모를 보낸다. 사이버 범죄자들은 이것을 보고 피싱(Phishing)을 이용해 수신인의 가까운 동료가 보낸 것처럼 보이는 이메일에 첨부파일을 보낸다. 그러면 우리는 예상치 못한 첨부파일을 열지 말라고 직원들에게 경고한다. 그러면 공격자들은 첨부파일 경고를 기다렸다가 공격을 개시한다.

최근 브라질의 한 은행에 대한 공격을 살펴보자. 전략적으로 오타에 배치한 사이트가 사용자에게 원하는 사이트를 정확하게 찾아 방문하라고 경고하고 있으며, 특히 뱅킹 사이트의 경우에는 더욱 중요한 문제다.

물론, 공격자들은 우리가 조심하도록 교육을 받았다는 사실을 알고 있다. 그래서 브라질의 사이버범죄자들은 은행을 공격할 때 해당 은행의 DNS 공격자를 먼저 공격했다. 이를 통해 그들은 해당 은행의 도메인에 대한 유효한 디지털 인증서를 구매할 수 있었다. 그리고 나서 그들은 은행을 공격해 백신 앱을 비활성화하는 악성코드를 심었다.

이 공격을 자세히 다룬 다크 리딩(Dark Reading)의 기사에서는 다음과 같이 밝혔다. "해당 은행의 온라인 서비스에 접근하는 고객들은 트러스티어(Trusteer) 뱅킹 보안 플러그인 애플리케이션으로 가장한 악성코드의 공격을 받았다. 해당 악성코드는 로그인 크리덴셜(Credential), 이메일, 연락처 목록, 이메일 및 FTP 크리덴셜을 수집했다."

해당 은행과 DNS 제공업체는 분명 실수를 저질렀다. 실수는 훌륭한 학습 방법이며, 타인의 실수는 더욱 그렇다. 우선, 해당 은행은 DNS 제공업체의 이중 인증 사용을 거부했다. 이를 사용했더라면 공격의 효과가 없었을 수 있다.

둘째, 카스퍼스키랩(Kaspersky Labs)에 따르면 해당 DNS 제공업체는 자체 사이트에서 CSRF(Cross Site Request forgery) 결함을 배치했다고 다크 리딩이 밝혔다. 이 결함에 DNS 기업의 이메일 피싱 공격이 합쳐져 패치 이전에 초기 접근이 가능했던 것 같다.

이를 통해 기업들이 협력업체에 얼마나 의존하고 있는지 알 수 있다. 시스템과 사람들을 현명하게 단속할 수 있지만 공급업체, 유통업체, DNS 제공업체, 클라우드 제공업체, 하도급업체 등이 해킹을 당하는 경우 자신도 그렇게 된다.

안타깝게도 이런 보안 전략의 엄청난 구멍은 표준 파트너 계약서에 몇 개의 추가 조항을 추가하는 법률적인 조치로는 해결할 수 없다. 파트너에 대한 보안 사양을 설정하는 것으로는 더 이상 충분하지 않다. 반드시 그것들을 정기적으로 테스트하는 메커니즘을 마련하고 구멍이 발견되면 가혹하게 처벌해야 한다(비공개로 하는 것이 이상적이다).

목적은 처벌이 아니다. 목적은 모든 파트너가 자신과 마찬가지로 보안을 중시하도록 하는 것이다.

한 가지 더 있다. 파트너가 이중 인증처럼 더 나은 보안을 제공하는 경우 따라야 한다. 이 공격으로 인해 소송이 발생하는 경우 해당 은행이 이를 거부했던 사실이 불리하게 작용할 것이다.

보안 정책에 대해 그 누구도 여러 단계의 승인 없이 파트너의 추가 보안 제안을 거부할 수 없도록 하는 규칙을 고려할 수 있다. 이런 정책을 서면으로 진행한다. 서류 작업의 위협보다 직원들이 보안을 더욱 신중하게 만드는 조치는 없다. editor@itworld.co.kr  


2017.04.17

글로벌 칼럼 | 서드파티 보안 실패에서 은행이 배워야할 것들

Evan Schuman | Computerworld
가장 효과적인 사이버 공격은 우리가 취하는 보안 조치들을 피해가고 있다. 우리는 항상 과거에 발생했던 공격에 대응하고 있으며, 우리의 조치가 실패할 수 있는 가능성에 대해서는 거의 생각하지 않는다.


Credit: pixabay

가능성은 항상 존재한다. 첨부파일을 통해 악성코드(Malware)가 들어오는 경우를 보자. 우리는 직원들이 모르는 사람이 보낸 첨부파일을 열지 않도록 메모를 보낸다. 사이버 범죄자들은 이것을 보고 피싱(Phishing)을 이용해 수신인의 가까운 동료가 보낸 것처럼 보이는 이메일에 첨부파일을 보낸다. 그러면 우리는 예상치 못한 첨부파일을 열지 말라고 직원들에게 경고한다. 그러면 공격자들은 첨부파일 경고를 기다렸다가 공격을 개시한다.

최근 브라질의 한 은행에 대한 공격을 살펴보자. 전략적으로 오타에 배치한 사이트가 사용자에게 원하는 사이트를 정확하게 찾아 방문하라고 경고하고 있으며, 특히 뱅킹 사이트의 경우에는 더욱 중요한 문제다.

물론, 공격자들은 우리가 조심하도록 교육을 받았다는 사실을 알고 있다. 그래서 브라질의 사이버범죄자들은 은행을 공격할 때 해당 은행의 DNS 공격자를 먼저 공격했다. 이를 통해 그들은 해당 은행의 도메인에 대한 유효한 디지털 인증서를 구매할 수 있었다. 그리고 나서 그들은 은행을 공격해 백신 앱을 비활성화하는 악성코드를 심었다.

이 공격을 자세히 다룬 다크 리딩(Dark Reading)의 기사에서는 다음과 같이 밝혔다. "해당 은행의 온라인 서비스에 접근하는 고객들은 트러스티어(Trusteer) 뱅킹 보안 플러그인 애플리케이션으로 가장한 악성코드의 공격을 받았다. 해당 악성코드는 로그인 크리덴셜(Credential), 이메일, 연락처 목록, 이메일 및 FTP 크리덴셜을 수집했다."

해당 은행과 DNS 제공업체는 분명 실수를 저질렀다. 실수는 훌륭한 학습 방법이며, 타인의 실수는 더욱 그렇다. 우선, 해당 은행은 DNS 제공업체의 이중 인증 사용을 거부했다. 이를 사용했더라면 공격의 효과가 없었을 수 있다.

둘째, 카스퍼스키랩(Kaspersky Labs)에 따르면 해당 DNS 제공업체는 자체 사이트에서 CSRF(Cross Site Request forgery) 결함을 배치했다고 다크 리딩이 밝혔다. 이 결함에 DNS 기업의 이메일 피싱 공격이 합쳐져 패치 이전에 초기 접근이 가능했던 것 같다.

이를 통해 기업들이 협력업체에 얼마나 의존하고 있는지 알 수 있다. 시스템과 사람들을 현명하게 단속할 수 있지만 공급업체, 유통업체, DNS 제공업체, 클라우드 제공업체, 하도급업체 등이 해킹을 당하는 경우 자신도 그렇게 된다.

안타깝게도 이런 보안 전략의 엄청난 구멍은 표준 파트너 계약서에 몇 개의 추가 조항을 추가하는 법률적인 조치로는 해결할 수 없다. 파트너에 대한 보안 사양을 설정하는 것으로는 더 이상 충분하지 않다. 반드시 그것들을 정기적으로 테스트하는 메커니즘을 마련하고 구멍이 발견되면 가혹하게 처벌해야 한다(비공개로 하는 것이 이상적이다).

목적은 처벌이 아니다. 목적은 모든 파트너가 자신과 마찬가지로 보안을 중시하도록 하는 것이다.

한 가지 더 있다. 파트너가 이중 인증처럼 더 나은 보안을 제공하는 경우 따라야 한다. 이 공격으로 인해 소송이 발생하는 경우 해당 은행이 이를 거부했던 사실이 불리하게 작용할 것이다.

보안 정책에 대해 그 누구도 여러 단계의 승인 없이 파트너의 추가 보안 제안을 거부할 수 없도록 하는 규칙을 고려할 수 있다. 이런 정책을 서면으로 진행한다. 서류 작업의 위협보다 직원들이 보안을 더욱 신중하게 만드는 조치는 없다. editor@itworld.co.kr  


X