How compliance and security requirements may conflict

아티클
08/24/2016

The Desktop Files보안과 규정 준수

Wes Miller

IT 전문가로서 여러분은 서로 보완되어야 하지만 그대신 종종 서로 경쟁하는 목표에 직면할 수 있습니다. 보안과 규정 준수는 하나를 실현하면 다른 한 쪽도 향상되어야 하는 조직 차원의 두 가지 목표입니다. 그러나 그렇지 않은 경우가 일반적입니다. 여기서는

보안 유지가 여러분에게 요구되는 이니셔티브에 대한 준수를 항상 의미하지는 않는 이유 및 종종 규정 준수가 보안을 의미하지 않거나 규정 준수가 보안과 진정으로 동등시 되는 경우에도 실현해야 할 최소한의 보안을 의미하지 않는 이유에 대해 간략하게 설명하려고 합니다.

보안은 필수

SDL 리소스

The Security Development Lifecycle, Michael Howard와 Steve Lipner 공저(Microsoft Press, 2006)
보안 개발 수명 주기 블로그
Microsoft에서 보안 개발 수명 주기 살펴보기
보안 개발자 센터
신뢰할 수 있는 컴퓨팅 보안 개발 수명 주기

규정 준수에는 일반적으로 외부로부터 조직, 업계, 회사 또는 제품에 부과되는 요구 사항(인력, 프로세스, 인프라, 기술 등)이 수반됩니다. 경우에 따라서는 업계 내에서 발표된 표준(예: PCI-DSS(Payment Card Industry Data Security Standard))을 준수해야 합니다. 이상적으로 이러한 표준은 최소한 어느 정도까지는 조직의 기존 운영 방식과 맞는 이니셔티브입니다. 표준 채택이 급증함에 따라 비즈니스를 목적으로 하지 않는 경우라면 몰라도 이러한 표준을 간과할 수는 없습니다. 결국 표준을 채택하여 이를 최대한 활용해야 합니다.

일반적으로 좀 더 까다로운 준수 유형도 있습니다. 여기에는 HIPAA(Health Insurance Portability and Accountability) 및 Sarbanes-Oxley와 같이 이행과 시기에 대한 선택권이 거의 주어지지 않는 정부에서 제정한 이니셔티브가 포함됩니다.

규정 준수를 이해하는 데 중요한 포인트는 준수가 대체로 "하향식" 접근 방식을 사용한다는 점입니다. 일반적으로 이니셔티브를 정의하는 획일적인 템플릿이 제공되며, 여러분은 제품과 프로세스를 살펴보고 이 이상한 모양의 템플릿에 이를 어떻게 끼워 맞출 수 있을지 알아내야 합니다. 규정 준수 이니셔티브의 의도뿐만 아니라, 아마도 보다 중요한 문제일 수도 있는, 규정을 준수하지 않을 경우 또는 성공하지 못할 경우 발생될 수도 있는 법률 또는 재정적 파장이 있다면 이것이 무엇인지도 인식하고 있어야 합니다.

우리는 많은 규정 준수 이니셔티브의 의도에 충분히 공감하지만, 이행이 쉽지 않은 경우가 종종 있으며 원하는 목표를 실현하지 못할 수도 있습니다. 또한, 유감스럽게도 효과적이지 못한 규정이 많습니다. 즉, 준수하지 않을 경우 받게 될 수 있는 직접적인 법률적 또는 재정적 불이익이 없습니다.

의료 환자 중 한 명인 저도 여러분에게 HIPAA의 실익을 완벽하게 설명할 수 없습니다. 여러분에게 말씀드릴 수 있는 점은 병원에 갈 때마다 다루어야 할 서류가 엄청나게 많다는 사실입니다. 더 심한 것은 의도하지 않은 결과가 발생될 수도 있다는 것입니다. 한 의사나 진료 기관에서 다른 의사나 진료 기관으로 중요한 의료 정보를 이관하려고 한 적이 있으십니까? 서면 승인이 없는 경우에는 해당 정보가 아무리 시급하게 필요할지라도 절대로 불가능합니다.

한마디로, 여러 의미에서 일부 규정 준수 이니셔티브는 선택적 이니셔티브가 되는 셈입니다. 즉, 여러분은 프로세스나 제품을 오로지 이러한 규정 준수 이니셔티브를 충족시키기 위해서 수정하거나 설계하고 있는 것입니다. 세 살 짜리 제 아이에게도 가끔 묻는 질문인데요, "그게 좋은 생각일까요?"

한편, 보안은 올바르게 실현될 경우 상향식 이니셔티브입니다. 소프트웨어 제품을 설계하든 조직의 새로운 네트워크를 위한 아키텍처를 설계하든 기억해야 할 주요 개념은 시작하기 전에 철저히 준비해야 한다는 것입니다. 예를 들어, 제품 아키텍처를 설계하는 경우 바람직한 시작 단계에서는 통신, 지역화, 버전 등에 대해 다룰 것입니다. 이와 마찬가지로 처음부터 응용 프로그램에 포함시킬 보안 요소를 다루고 개발 과정 전체에 걸쳐 계속 조사하고 조정해 나가야 합니다.

여러분 중 대다수에 해당될 것으로 생각되는데, 다른 사람에게 이어받은 응용 프로그램이나 아키텍처로 작업 중인 경우에도 제가 여기서 자주 언급하는 심층적인 보안 검토를 반드시 수행해야 합니다. 어떻게 작동하는지 이해하지 못한다면 보안 상태를 어떻게 점검할 수 있겠습니까? Microsoft® Security Development Lifecycle(SDL)에 대한 자세한 내용은 "SDL 리소스" 추가 기사를 참조하십시오.

큰 그림

오래전에 보안은 단순히 암호화, ACL(액세스 제어 목록), TLS 또는 PKI(공개 키 인프라)를 구현하는 것과는 다르다고 배운 적이 있습니다. 진정한 보안은 큰 그림을 파악하는 것입니다. 즉, 특정 프로토콜 버전이 제외되었거나 지원되지 않는 이유, 새로운 기능에서 man-in-the-middle 공격을 차단하는 이유, 제품 V1이 훨씬 더 빠름에도 불구하고 어떻게 제품 V2를 구현하는 것이 V1보다 훨씬 더 안전한지 등 다양한 측면을 파악해야 합니다. 또한 인프라의 모든 부분이 어떻게 맞아 떨어지는지도 이해해야 합니다.

한편, 규정 준수는 기술을 채택하고 구축한 인프라를 특정 기준에 맞추는 것을 의미합니다. PCI-DSS(Payment Card Industry Data Security Standard) 또는 NERC(North American Electric Reliability Council)와 같은 일부 이니셔티브는 그 취지가 좋으며 실질적인 보안 변화를 촉진할 수 있습니다. 하지만 다양한 "규정 준수 이니셔티브"를 고유의 특정 프로젝트와 끼워 맞춰야 하고 사용 가능한 리소스가 한정되어 있다면 보안 이니셔티브에 대한 지지는 낮아지게 됩니다.

보안은 오랫동안 소프트웨어 개발 부분에서 주목을 받지 못했습니다. 여러분 중 대다수가 보안에 대해 "나중에 하죠"라고 답하는 그런 조직에서 근무해 왔을 것입니다. 그러나 이제는 보안에 시간적 여유가 있다는 생각에 문제가 있으며 결코 그럴 수 없다는 인식이 퍼져 규정 준수 이니셔티브가 서서히 정착하고 있습니다.

충분하다-잘못된 인식

최근에 저는 직장을 옮겼습니다. 현재 저는 여기 텍사스주 오스틴에서 예전에 Winternals에서 Protection Manager 제품을 사용하여 구축했던 기술과 유사한 응용 프로그램 허용목록 방식(whitelisting) 기술을 구축하는 새로운 일을 시작했습니다. 여기서 근무하면서 저는 고객이 말하고 싶어하는 매우 흥미로운 주제 중 하나가 그들이 현재 기술을 얼마나 안전하다고 느끼는지 또는 좀 더 구체적으로 말하면 그들이 사용 중인 기술 제품이 인프라를 얼마나 안전하게 구축하고 있다고 생각하는지에 대한 것이었습니다. 대부분의 제품이 전체적으로 안전하며 보안 취약점이 거의 없다고 생각되지만, 흔히 저를 조금 움찔하게 만드는 그들의 평가는 시스템의 "보안이 충분하다"라는 표현이었습니다.

규정 준수 이니셔티브는 흥미롭습니다. 이러한 이니셔티브를 충족하거나 충족하지 못하거나 둘 중 하나입니다. 책임은 여러분에게 있습니다. 이니셔티브를 충족하지 못할 경우 일반적으로 벌금 또는 위약금이 부과되거나 조직에서 퇴출됩니다. 대체로 이러한 처벌은 실질적인 변화를 가져오는 데 충분하지 않습니다.

연방 정부에서 요구하는 이니셔티브의 경우, "감사자를 만족시키기에 충분하다"라는 태도 또는 HIPAA와 같은 지원 법률에서 시행에 대한 충분한 투자가 이루어지지 않는다는 것을 빌미로 규정 준수 프레임워크가 실제로 마련되지 않은 상태에서도 이를 실행하겠다는 무모한 의도를 어김 없이 접하게 됩니다. 다시 말해서 보험 없이 운전할 때는 비용이 훨씬 덜 드는 것 같지만 결국 나중에는 위험한 결과에 직면할 수 있다는 것을 의미합니다.

보안도 종종 이와 같은 장애에 부딪히지만 제 생각으로는 최소한 보안은 보다 실제적입니다. 개발자나 구현자가 규격을 벗어난 섹션을 그대로 둘 경우 제품이 규정을 위반할 가능성이 높아질 것이라고 관리 부서에 적극적으로 피력한다면 최소한 제품이 출시되거나 배포가 완료된 후 "그렇게 될 것라고 이미 경고했습니다"라는 말은 할 수 있을 것입니다. 제 경험상 규정 준수 이니셔티브는 대체로 제한된 가용 예산 내에서 급하게 실현됩니다. 목표는 단순히 이니셔티브에서 요구하는 최소 사항만 충족하는 것입니다. 따라서 제가 보기에 그것은 진정한 의도가 아닌 단지 글자 그대로의 이니셔티브를 충족하는 것뿐입니다.

현재 상태 파악

보안 및 규정 준수 리소스

이상적으로는 제품과 조직을 가능한 한 안전하게 만들어야 한다고 말할 수도 있겠지만, 현실에서 대부분의 규정 준수 이니셔티브는 서투른 엔지니어링 또는 흔히 자기 만족의 결과로 인한 절충안 정도의 수준입니다. 우리는 안타깝게도 "충분하다"가 정말로 충분한 수준으로 인식되고 있는 세계에 살고 있습니다. 하지만 보안 부분에서 "충분하다"는 대체로 신중한 결정이 아닙니다. IT 전문가들인 우리는 규정 준수 이니셔티브를 마음에 새기고 그 진정한 의도와 실행이라는 두 가지를 모두 충족시키기 위해 노력하며, 가능한 수준에서의 보안이 아니라, 반드시 갖추어야 할 필수 수준의 보안을 유지할 수 있는 인프라를 구축하도록 해야 합니다. 다시 말해서 단순히 이니셔티브를 충족시키는 수준이 아니라 실질적인 보안을 통해 규정을 준수해야 합니다.

대규모 시스템에 통합하려는 일련의 기술이든 하나의 상용 소프트웨어이든 구축하고 있는 기술을 한 걸음 뒤로 물러나서 살펴보는 것도 중요합니다. 시스템에서 서로 맞물리는 부분, 모든 부분이 함께 작동되는 방식, 시스템에 대한 보다 큰 위협을 파악하는 일은 매우 중요합니다.

각자가 속해 있는 업계에 따라 다양한 규정 준수 이니셔티브가 여러분 업무와 연관되어 있을 수 있습니다. 이러한 규정 준수 이니셔티브를 일상 생활에서 접할 수도 있고 새 프로젝트 또는 기술을 설계할 때만 접할 수도 있습니다. 또는 이러한 규정 준수 이니셔티브가 특별 지시에 따른 규정 준수 검토 또는 감사 과정 중에만 업무의 한부분이 되는 경우도 있습니다. 어떤 경우든 상관없습니다. 규정 준수 이니셔티브를 무시해서도 안 되지만, 현재의 상태도 바람직하지 않습니다. 업무와 연관된 규정 준수 이니셔티브를 충족하는 데만 급급해 하지 말고, 대신 여러분의 기술을 완벽히 이해할 수 있도록 보안에 대한 철저한 검토를 수행하고 규정 준수 검토와 동시에 보안을 모델링해야 합니다.

손해볼 것이 없음

궁극적으로 규정 준수 이니셔티브를 충족시키지 못하여 부과되는 위약금이 모호하게 느껴질 수도 있습니다. 그러나 규정을 준수하지 않으면 이니셔티브가 제안된 상황과 동일한 위험이 닥칠 때 보호를 받을 수 없습니다. 결과가 막연하거나 먼 얘기 같겠지만 현실로 나타날 것입니다. 이러한 결과는 개인적인 결과에 그치지 않을 수도 있습니다. 따라서 실제적이어야 하지만 항상 최악의 상황을 염두에 두어야 합니다.

엄격한 보안적 관점에서 동일한 공간을 살펴보면 위협은 명백합니다. 따라서, 특히 취약점을 보완하지 않은 상태로 둘 경우 발생할 수 있는 잠재적인 비용을 즉시 식별할 수 있어야 합니다.

저와 함께 이 주제를 논의했던 많은 사람들은 규정 준수 이니셔티브에는 종종 해석의 여지가 너무 많기 때문에 때로는 규정 준수 이니셔티브의 진실이 숨겨져 있다는 사실을 강조합니다. 하지만 보안 검토를 수행하고 나면 보안 누락에 대해서는 이 말이 사실이 아니라는 것을 알게 됩니다. 보안을 무시하면 이로 인해 즉각적인 위협이 닥치게 됩니다. 그렇지 않다면 보안 검토에 투입된 사람을 다시 고려해 보아야 할 수도 있습니다. 솔루션에서 실제 문제를 찾아낼 수 있는 주요 팀원이 빠져 있기 때문일 수도 있으니까요.

악순환

지난 해 보안 특집 칼럼에서 "데이터 보호 방법"(technet.microsoft.com/magazine/cc162325)에 대해 설명한 적이 있습니다. 1년의 시간이 지나는 동안 더 많은 시스템이 손상되었고, 암호화되지 않은 랩톱이 더 많이 분실되었으며, 더 많은 개인 정보가 신뢰할 수 없는 자들에게 유출되었습니다. 보안에 있어서 어떠한 진전이 있었는지 말하기가 매우 어렵습니다. 왜 우리는 여전히 같은 곳에 머물러 있는 걸까요? 흔히 프로젝트는 적은 예산을 기반으로 터무니없이 광범위한 리소스를 사용하여 너무나 짧은 기간 내에 너무 많은 기능을 제공하려고 안간힘을 쓰다가 예상보다 늦어집니다.

안타깝게도, 이러한 환경은 아주 최소한의 작업을 하는 것이 일반화되는 분위기를 유도합니다. 이것은 확실히 솔루션의 보안 또는 규정 준수를 보장하기 위한 방법이 아니며 또한 프로젝트의 기간이나 비용에도 전혀 도움이 되지 않습니다.

개인적으로 저는 다음과 같은 확고한 신념을 가지고 있습니다.

보안을 유지하지 않으려면 솔루션을 구축해서는 안 됩니다.
새로운 기능을 추가할 때마다 시작하기 전에 보안을 먼저 설계해야 합니다.
조직에서 엔지니어링 프로세스의 한 단계로 보안을 구축할 의향이 없다면 전체 회사 또는 조직 목표가 무엇인지에 대해 의문을 제기해야 합니다.

조직에서 안전하게 유지해야 할 고객 또는 파트너 개인 데이터의 양이 점점 더 많아지고 있습니다. 너무나 자주 보안이 기본적으로 보장되지 않고 직원이 조직의 보안 조치에 대해 의문을 가지고 이를 안전하게 느끼지 못하는 세계에서 우리가 살고 있다는 사실은 참으로 안타까운 일입니다.

규정 준수가 아닌 실제 보안 실패가 너무나 일반적으로 "시스템 보안을 구축해야 할 시점"을 나타내는 계기로 작용하며, "신원 도용 보험"이 개인 데이터, 잠재적인 재무적 평안이 손상된 고객, 학생, 환자 및 직원을 달래기 위한 표준 책임 전략이 되어 왔습니다.

우리 모두는 일반적으로 매우 짧은 시간 동안 매우 작은 부분을 위해 너무나 많은 것을 하라는 요구를 받습니다. 하지만 IT 전문가로서 우리는 보안이 주목을 받지 못하는 이유, 관리 부서에서 흔히 규정 준수 이니셔티브 또는 보안 실패 및 실제 또는 잠재적인 법적 위협(조직을 궁지에 빠뜨리고 위태롭게 할 수도 있는)을 직면할 때만 보안을 생각하는 이유에 대해 문제를 제기해야 할 책임이 있습니다.

도전

무엇보다도 현재의 상태에 도전할 것을 권유합니다. 규정 준수 목표만을 충족시키라는 지시를 받는 경우 단지 누군가의 보안 개념을 충족시키는 데 시간을 낭비하지 말고 규정 준수 목표가 확실히 충족되도록 노력하십시오. 여러분의 목표는 시스템 보안을 유지하는 것이어야 하며, 그 과정에서 규정 준수 이니셔티브를 충족하기 위한 인프라 또는 프로세스를 충분히 정의하십시오. 이 주제에 대한 자세한 내용은 "보안 및 규정 준수 리소스" 추가 기사를 참조하십시오.

요약하자면, 규정 준수는 대부분의 경우 보안으로 가는 길이 아닙니다. 하지만 올바르게 구현되고 갖춰진 보안은 규정 준수로 가는 길일 수 있습니다.

Wes Miller는 텍사스주 오스틴에 위치한 CoreTrace(www.CoreTrace.com)에서 기술 제품 수석 관리자를 맡고 있으며, 이전에는 Winternals Software에서 그리고 Microsoft에서 프로그램 관리자로 일했습니다. 문의 사항이 있으신 분은 technet@getwired.com으로 연락하시기 바랍니다.

추가 리소스