개편된 PCI 보안 표준 위원회 가이드라인: 충분히 '시프트 레프트' 되었는가?

이 기사의 일부 내용은 Digital Transactions Magazine에 게재되었습니다.

올해 PCI 보안 표준 위원회는 PCI 소프트웨어 보안 프레임워크의 일환으로 완전히 새로운 소프트웨어 보안 가이드라인을 발표했습니다. 이번 업데이트는 소프트웨어 보안 모범 사례를 현대적인 소프트웨어 개발 방식에 맞추는 것을 목표로 합니다. 이는 우리 삶의 대부분이 급격히 디지털화되기 훨씬 이전에 설정된 보안 표준을 재고해야 할 만큼 프로세스가 변화했음을 인정하는 매우 훌륭한 시도입니다.

이는 우리 업계가 변화하는 요구 사항에 맞춰 진화하는 유연한 가이드라인의 중요성을 더 깊이 인식하고 있음을 보여주는 분명한 증거입니다. 또한, 보안 개발 프로세스를 소홀히 할 경우 걷잡을 수 없이 커질 수 있는 사이버 보안 환경의 위협에 대응하려는 의지이기도 합니다. 당연히 은행 및 금융 업계의 관리 기구로서(우리의 자금, 신용카드, 온라인 거래 및 결제 시점의 보안을 책임지는 소프트웨어의 표준을 설정하는 기관으로서) PCI 보안 표준 위원회는 막대한 위험을 안고 있으며, 이를 줄여야 할 강력한 동기를 가지고 있습니다.

이번 표준이 이전 버전에 비해 확실히 개선되었고, 보안을 전체 품질 평가의 일부로 우선시하면서도 신속하고 혁신적인 기능 개발을 가능하게 하는 공백을 메우는 데 어느 정도 기여한 것은 사실입니다. 하지만 여전히 갈 길이 멀다는 현실은 다소 실망스럽습니다.

이런 제안에 대해 무조건적인 비판을 하려는 것은 아닙니다. 다만, 새로운 보안 가이드라인이 우리를 충분히 '왼쪽(개발 초기 단계)'으로 이동시키지 못하고 있다는 점을 지적하고 싶습니다.

우리는 여전히 테스트에만 집착하고 있으며, 그마저도 너무 늦게 수행하고 있습니다.

PCI 보안 표준 프레임워크에서 발견한 한 가지 명백한 문제는 테스트에 대한 과도한 의존성입니다. 물론 소프트웨어 테스트는 여전히 필수적이며(SAST/DAST/IAST 프로세스도 제 역할이 있습니다), 하지만 우리는 여전히 같은 함정에 빠져 다른 결과를 기대하고 있습니다.

우리가 알고 사랑하며 신뢰하는 소프트웨어를 만들기 위해 코드 한 줄 한 줄을 작성하는 사람은 누구일까요? 바로 소프트웨어 개발자입니다.

스캔 도구나 수동 코드 검토를 통해 이 코드를 테스트해야 하는 난처한 입장에 처한 사람은 누구일까요? 바로 앱 보안(AppSec) 전문가들입니다.

이 전문가들이 계속해서 발견하는 것은 무엇일까요? 수십 년 동안 우리를 괴롭혀온 똑같은 버그들입니다. SQL 인젝션, 크로스 사이트 스크립팅(XSS), 세션 관리 취약점 등 이미 해결 방법을 알고 있는 간단한 문제들입니다. 마치 영화 '사랑의 블랙홀'처럼 반복되는 상황이죠. 개발자 스스로가 수년 전부터 해결할 수 있었던 코드 위반 사항을 찾는 데 시간을 낭비하고 있습니다. 보안이 프로세스의 우선순위에서 밀려나 있기 때문입니다. 특히 기능 전달이 최우선인 애자일 개발 시대에는 보안이 창의적인 프로세스와 프로젝트 완수의 기쁨을 앗아가는 방해꾼 취급을 받곤 합니다.

이는 어느 한 팀을 비난하려는 것이 아닙니다. 개발자와 앱 보안 전문가 모두 매우 중요한 업무를 수행하고 있지만, 서로의 발목을 잡고 있는 상황입니다. 이러한 상황은 보안 인식이 부족한 개발자가 부정적인 보안 문화 속에서 안전하지 않은 코드를 생산하고, 이를 나중에 스캔하고 수정해야 하는 결함 있는 SDLC(소프트웨어 개발 생명주기)를 고착화합니다. 앱 보안 팀은 방치할 경우 기업에 재앙을 초래할 수 있는 사소하고 반복적인 문제들을 처리하느라 정작 정말 복잡한 보안 이슈를 해결할 시간조차 부족한 실정입니다.

테스트를 코드 보안 취약점의 만능 해결책으로 삼는 것은 시간과 비용, 자원의 낭비입니다. 매일같이 대규모 데이터 유출 사고가 발생하는 것을 보면, 이 방식이 최선이 아니라는 점은 명백합니다. 새로운 표준들은 여전히 이미 완성된 최종 제품 상태를 평가하는 데 머물러 있습니다(모든 개발자가 보안을 잘 알고 있다는 가정하에 말이죠). 이는 결함을 수정하기에 가장 비용이 많이 들고 어려운 단계입니다. 마치 새로 지은 집에 입주하는 날 안전 점검팀을 불러 위험 요소를 찾는 것과 같습니다. 기초 공사에 문제가 있다면, 이를 수정하기 위해 얼마나 많은 시간과 비용, 노력이 들지 상상해 보십시오. 차라리 처음부터 다시 시작하는 것이 더 쉽고 저렴할 때가 많습니다(물론 첫 버전을 만든 사람들에게는 매우 허탈한 과정이겠지만요).

우리는 반드시 기초부터 시작해야 합니다. 개발 팀이 보안 모범 사례에 참여하도록 유도하고, 효율적으로 안전한 코드를 작성할 수 있는 지식을 갖추게 하며, 모든 직장에 긍정적인 보안 문화를 조성하고 유지해야 합니다.

학습 곡선이 가파르냐고요? 물론입니다. 하지만 불가능할까요? 절대 아닙니다. 그리고 지루한 고역일 필요도 없습니다. Capital One의 Russ Wolfe 사례에서 볼 수 있듯이, 개발자의 창의성과 문제 해결 능력을 자극하는 교육 방식은 이미 금융권에서 큰 성공을 거두고 있습니다.

우리는 여전히 완벽한 '최종 상태'를 찾고 있습니다.

업데이트된 PCI 보안 표준을 의도된 맥락, 즉 '완성된 사용자용 금융 제품은 최적의 보안과 안전을 위해 이러한 모범 사례를 따라야 한다'는 관점에서 본다면 충분히 훌륭합니다. 하지만 제 생각에 금융권을 포함한 모든 기업이 기능 품질과 높은 수준의 보안을 모두 갖춘 소프트웨어를 만들 수 있는 가장 좋은 방법은, 한 걸음 물러나 개발 주기 초기부터 보안을 고려하는 것이 훨씬 효율적임을 깨닫는 것입니다.

그 완벽한 최종 상태란 무엇일까요? 제품을 스캔하고 수동으로 검토했을 때 오류 하나 없이 완벽하게 나오는 상태를 말하는 것일까요? 우리는 여전히 그것을 찾고 있습니다. 하지만 현재로서는 유니콘처럼 실재하지 않는 환상에 가깝습니다.

왜 그렇게 도달하기 어려울까요? 여기에는 여러 가지 요인이 있습니다.

• 스캔 도구에 의존하고 있지만, 항상 효과적인 것은 아닙니다. 오탐은 시간 낭비를 초래하는 골칫거리이며, DAST, SAST, PCI 스캔을 모두 동원하더라도 코드 베이스의 모든 취약점을 찾아낼 수는 없습니다.물론 스캔 결과가 안전하다고 나올 수는 있지만, 과연 모든 것을 검사하고 있을까요? 공격자는 단 하나의 취약점만 찾아내도 보호받고 있다고 믿는 시스템에 침투할 수 있습니다.
• 개발자들은 여전히 같은 실수를 반복하고 있습니다. 보안에 관한 지식 공유가 이루어지지 않고 있으며, 잘 알려지고 문서화된 '보안 코드 레시피(우수 보안 코드 패턴)'도 부족합니다.
• 협력적이고 긍정적인 보안 문화를 구축하려는 노력도 부족합니다.
• 개발자들이 창의적인 작업 흐름이나 애자일 개발 방법론을 방해받지 않으면서도 제품 개발 단계부터 보안을 내재화할 수 있도록 적절한 도구를 제공해야 합니다.

이 가이드라인은 소프트웨어가 준수해야 할 보안 표준을 확인하는 강력한 체크리스트이지만, 소프트웨어를 그 수준까지 끌어올리는 최선의 과정에 대해서는 여전히 논의가 필요합니다.

소프트웨어가 안전하지 않은 이유는 스캐너가 부족해서가 아니라, 개발자에게 길잡이가 되어줄 사용하기 쉽고 이해하기 쉬운 보안 도구가 제공되지 않기 때문입니다.

우리는 지금 변화의 시대를 살고 있습니다. 오랫동안 소프트웨어 보안은 선택 사항이었지만, 오늘날에는 필수 요소가 되었습니다. 특히 금융, 의료, 사회보장 등 민감한 정보를 다루는 곳이라면 더욱 그렇습니다.

PCI 보안 표준 위원회(PCI Security Standards Council)가 기준을 마련하는 데 기여하고 있지만, 업계에서 쌓아온 명성과 영향력을 바탕으로 개발자를 위한 실질적인 가이드라인을 포함해 주었으면 합니다. 특히 적절하고 긍정적인 교육과 도구 제공에 중점을 두어야 합니다. 현재는 조직이 개발팀의 보안 인식과 규정 준수를 보장하도록 강제하는 압력이 없으며, 많은 개발자가 사소하고 쉽게 고칠 수 있는 실수가 악의적인 공격자에게 이용될 때 얼마나 큰 위험을 초래하는지 제대로 인지하지 못하고 있습니다.

가치 있는 모든 일이 그렇듯, 진정한 변화를 위해서는 모두의 노력이 필요합니다. 지금 감지되는 변화의 바람이 우리 모두를 더 왼쪽으로(시프트 레프트) 이끌어 주기를 기대합니다.