개편된 PCI 보안 표준 위원회 지침: 그들은 충분히 왼쪽으로 이동합니까?

이 문서의 버전은 원래 디지털 거래 잡지에 게시되었습니다.

올해 PCI 보안 표준 위원회는 PCI 소프트웨어 보안 프레임워크의 일환으로 소프트웨어 보안 가이드라인의 새로운 세트를 발표했습니다. 이 업데이트는 최신 소프트웨어 개발과 함께 소프트웨어 보안 모범 사례를 제공하는 것을 목표로 합니다. 이 과정은 시간이 지남에 따라 어떻게 바뀌었는지 인정하는 환상적인 이니셔티브로, 우리의 삶의 대부분이 급속히 디지털화되기 전에 설정된 보안 표준을 재고해야 합니다.

이는 변화하는 요구사항으로 진화하는 적응형 가이드라인과 안전한 개발 프로세스에서 계속 느슨해질 경우 통제 불능상태가 될 수 있는 사이버 보안 환경의 요구에 더욱 밀접하게 관여하는 업계의 분명한 증거입니다. 당연히 PCI 보안 표준 위원회가 은행 및 금융 업계 내에서 관리 기관 역할을하고 (에서와 같이, 우리는 우리의 모든 돈을 보호하기 위해 신뢰하는 소프트웨어에 대한 보안 표준을 설정, 신용 카드, 온라인 거래 및 판매 시점에서), 그들은 위험을 많이 수행하고 그것을 줄이기 위해 큰 동기를 가지고있다.

이러한 표준은 확실히 이전 버전을 개선하고 또한 전반적인 품질의 일환으로 보안을 우선 순위를 신속하고 혁신적인 기능 개발에 있는 구멍을 연결하는 몇 가지 방법을 이동하지만 assessment 아직 갈 길이 멀다는 것을 알게 된 것은 다소 실망스러운 현실입니다.

아니, 그건 내가이 이니셔티브에 "바, 험버그!"를주는 것이 아니에요. 사실, 이러한 새로운 보안 지침은 단순히 왼쪽으로 충분히 우리를 이동하지 않습니다.

여전히 테스트에 고정되어 있었고 너무 늦게 테스트되었습니다.

PCI 보안 표준 프레임워크에서 발견한 한 가지 눈부신 문제는 테스트에 대한 명백한 의존성입니다. 물론 소프트웨어는 여전히 테스트해야 합니다(SAST/DAST/IAST 프로세스는 여전히 그 자리를 차지하고 있음), 여전히 동일한 함정에 빠지고 다른 결과를 기대하고 있었습니다.

우리가 알고, 사랑하고 신뢰하는 소프트웨어를 만들기 위해 코드 라인 이후에 줄을 쓰는 사람은 누구입니까? 소프트웨어 개발자.

스캔 도구 또는 수동 코드 검토로 이 코드를 테스트할 수 있는 부러운 위치는 누구입니까? AppSec 전문가.

이 전문가들은 무엇을 계속 발견합니까? 수십 년 동안 우리를 괴롭혔던 동일한 버그. SQL 주입, 사이트 간 스크립팅, 세션 관리 약점등 몇 년 동안 수정하는 방법을 알고 있었던 간단한 것들... 그것은이 사람에 대 한 그라운드 호그 데이 처럼. 그들은 개발자가 수년 동안 수정할 수 있는 코드 위반을 찾아 고치는 데 시간을 보냈다.

이것은 부정적인 것이 아닙니다. assessment 어느 팀 중; 개발자와 AppSec 전문가는 모두 해야 할 매우 중요한 일을 가지고 있지만, 그들은 서로의 방식으로 계속 얻을 수 있습니다. 이 상황은 보안 인식이 거의 없는 개발자가 부정적인 보안 문화에서 작동하는 결함이 있는 SDLC만 영속되며, 안전하지 않은 코드를 생성하여 처음 작성된 후 스캔, 평가 및 수정해야 합니다. AppSec은 확인되지 않은 상태로 두면 회사에 재앙을 초래할 수 있는 작은 반복되는 문제에 너무 사로잡혀 있기 때문에 진정으로 복잡한 문제를 해결할 시간이 거의 없습니다.

우리는 테스트가 코드의 보안 약점에 대한 캐치 올이 될 수 있도록하여 시간, 돈 및 자원을 낭비하고 있습니다. 그리고 격일로 대규모 데이터 유출로 이 방법은 분명히 최적으로 작동하지 않습니다. 이러한 새로운 표준은 여전히 최종 제품 상태를 평가하고 있습니다(아마도 모든 개발자가 보안 에 유의하고 있다는 가정하에, 이는 그렇지 않습니다) 이미 구축된 표준입니다. 이것은 결함을 해결하기 위해 가장 비싸고 어려운 단계입니다. 그것은 당신이 이사 같은 날에 어떤 위험을 확인하기 위해 안전 팀을 가지고, 공상, 새로운 집을 구축처럼. 재단에 문제가 있다면, 문제를 해결하기 시작하기 위해 그 지역에 도착하는 시간, 비용 및 완전한 두통을 상상해보십시오. 그것은 종종 쉽고 저렴 단순히 다시 시작 (그리고 첫 번째 버전을 구축 하는 모든 사람에 대 한 완전히 만족 스러운 프로세스).

개발 팀이 보안 모범 사례에 참여하도록 하고, 모든 직장에서 긍정적인 보안 문화를 만들고 유지하는 것 외에도 효율적으로 코딩할 수 있는 지식으로 역량을 강화함으로써 처음부터 노력해야 합니다.

그것은 학습 곡선인가? 지옥 그래, 그렇습니다. 불가능합니까? 확실히. 그리고 지루한 드루거일 필요는 없습니다. 캐피탈 원에서 Russ Wolfes 경험이 어떤 징후라면 개발자의 창의적이고 문제 해결 특성에 직접 호소하는 교육 방법은 이미 은행 및 금융 분야에서 엄청난 성공을 거두었습니다.

여전히 완벽한 "최종 상태"를 찾고 있었습니다.

업데이트된 PCI 보안 표준을 원하는 컨텍스트에서 살펴보면 완료된 사용자 지원 금융 상품은 최적의 보안 및 안전을 위해 이러한 모범 사례를 따라야 하므로 절대적으로 괜찮습니다. 그러나, 내 관점에서, 모든 단일 회사 - 금융 또는 그렇지 않으면 - 단지 그들이 한 걸음 뒤로 했다 고 사이클의 처음부터이 작업을 수행하는 것이 훨씬 더 효율적이다는 것을 깨달았다, 기능 품질과 보안의 높은 기준모두를 대표하는 소프트웨어 최종 상태에 도달의 가장 좋은 기회를 가질 것이다.

그 완벽한 엔드 스테이트? 알다시피, 제품을 스캔하고 수동으로 검토하고 완벽하고 오류가없는 경우 발생하는 제품? 우리는 여전히 그것을 찾고 있습니다. 이 시점에서, 그것은 유니콘입니다.

왜 그렇게 애매합니까? 다음과 같은 여러 가지 요인이 있습니다.

• 스캐닝 도구는 의존하지만 항상 효과적인 것은 아닙니다. 거짓 긍정은 DAST / SAST / PCI 스캔이 코드 베이스의 가능한 모든 취약점을 식별하고 공개 할 수 없다는 사실과 마찬가지로 사용의 실망스러운 시간 낭비 부산물입니다. 물론, 그들은 당신에게 모든 명확한 줄 수 있습니다,하지만 그들은 정말 모든 것을 찾고 있습니까? 공격자는 보호대상이라고 생각되는 것에 액세스하려면 하나의 취약점만 있으면 됩니다.
• 개발자는 계속해서 동일한 실수를 저지르고 있습니다. 보안에 대한 개발자 간의 지식 분포가 없으며 잘 알려져 있고 문서화된 "보안 코드 레시피"(좋은 보안 코드 패턴)가 없습니다.
• 협력적이고 긍정적인 보안 문화를 구축하는 데 중점을 두지 않습니다.
• 개발자는 창의적인 프로세스와 민첩한 개발 방법론을 방해하지 않고 고객이 작성한 제품에 보안을 구울 수 있는 올바른 도구를 제공해야 합니다.

이러한 지침은 소프트웨어가 준수해야 하는 보안 표준에 대한 강력한 검증 체크리스트이지만 해당 상태로 소프트웨어를 제공하는 가장 좋은 프로세스는 논쟁의 여지가 있습니다.

우리는 스캐너가 부족하기 때문에 안전하지 않은 소프트웨어가 없으며 개발자가 사용하기 쉽고 이해하기 쉬운 보안 도구가 제공되지 않기 때문에 안전하지 않은 소프트웨어가 있습니다.

우리는 지금 진화의 시대에 있습니다. 일반적으로 소프트웨어 보안은 수년 동안 선택 사항이었습니다. 오늘날, 그것은 본질적으로 필수입니다 - 특히 민감한 정보 (금융, 의료, 사회 보장)의 수호자 ... 당신은 아이디어를 얻을).

PCI 보안 표준 위원회는 벤치 마크를 설정하는 데 도움이, 하지만 난 그들을보고 싶어요 - 모든 업계의 존경과 영향 - 개발자를위한 실용적인 지침을 포함하는 쪽으로 작업, 적절하고 긍정적 인 교육 및 도구에 중점을. 현재 조직은 개발 팀이 보안 에 대해 인식하고 준수하도록 보장해야 한다는 압박감이 없으며, 많은 개발자가 해를 끼치려는 팀에 의해 악용될 때 작고 쉽게 고정된 실수의 규모를 이해하지 못합니다.

인생에서 가치있는 어떤 것으로 예상되는 것처럼, 정말 진정으로 변화를 제정하는 마을을 않습니다. 그리고 공기의 변화는 (희망) 왼쪽에더 우리 모두를 휩쓸 것입니다 .