SCW-Symbole
Held-Hintergrund ohne Trennlinie
Blog

개정된 PCI 보안 표준 위원회 지침: 개정된 지침은 충분히 왼쪽으로 바뀌었는가?

Pieter Danhieux
Veröffentlicht Jul 04, 2019
Zuletzt aktualisiert am 09. März 2026

이 기사의 한 버전은 원래 에 게시되었습니다. 디지털 트랜잭션 매거진.

올해 PCI 보안 표준 위원회는 완전히 새로운 세트를 출시했습니다. 소프트웨어 보안 지침 PCI 소프트웨어 보안 프레임워크의 일부로이번 업데이트는 소프트웨어 보안 모범 사례를 최신 소프트웨어 개발과 연계하는 것을 목표로 합니다.우리 삶의 대부분이 급속히 디지털화되기 훨씬 이전에 세워졌던 보안 표준을 다시 생각해 보아야 하기 때문에 시간이 지남에 따라 이 프로세스가 어떻게 변해왔는지 인정하는 환상적인 이니셔티브입니다.

이는 우리 업계가 변화하는 요구 사항에 따라 변화하는 적응형 가이드라인에 대한 아이디어에 더욱 긴밀하게 관여하고 있는 것은 물론 보안 개발 프로세스를 계속 느슨하게 유지할 경우 매우 빠르게 통제 불능 상태가 될 수 있는 사이버 보안 환경의 요구에 더욱 긴밀하게 관여하고 있다는 분명한 증거입니다.당연히 PCI 보안 표준 위원회 (PCI Security Standards Council) 가 은행 및 금융 업계 내에서 관리 기관의 역할을 수행함에 따라 (예: 자금, 신용 카드, 온라인 거래 및 판매 시점을 보호하기 위해 당사가 신뢰하는 소프트웨어에 대한 보안 표준을 설정하는 것과 같이) 리스크는 많은 위험을 수반하며 위험을 줄이려는 의욕도 큽니다.

이러한 표준은 이전 버전보다 확실히 개선되었으며 전반적인 품질 평가의 일환으로 보안을 우선시하는 빠르고 혁신적인 기능 개발의 허점을 메우는 데 어느 정도 도움이 되지만, 아직 갈 길이 멀다는 사실은 다소 실망스러운 현실입니다.

아니, 그건 내가 “으악, 험버그!” 라고 말하는 게 아니야.이 이니셔티브에.사실 이러한 새로운 보안 지침은 우리를 좌익으로 이끌지 못합니다.

우리는 여전히 테스트에 집착하고 있었습니다 (그리고 테스트는 너무 늦었습니다).

PCI 보안 표준 프레임워크에서 발견한 한 가지 눈에 띄는 문제는 테스트에 대한 명백한 의존성입니다.물론 소프트웨어는 아직 테스트를 거쳐야 하지만 (그리고 SAST/DAST/IAST 프로세스도 여전히 그 자리를 지키고 있습니다), 우리는 여전히 같은 함정에 빠졌고 다른 결과를 기대하고 있습니다.

누가 다음에 줄을 씁니까? 코드 라인 우리가 알고 사랑하고 신뢰하는 소프트웨어를 만들기 위해서요?소프트웨어 개발자.

스캐닝 도구나 수동 코드 검토를 통해 이 코드를 테스트할 때 부럽지 않은 사람이 있을까요?AppSec 전문가.

이 전문가들이 계속해서 발견하고 있는 것은 무엇일까요?수십 년 동안 우리를 괴롭혔던 바로 그 버그.몇 년 동안 해결 방법을 알고 있었던 간단한 것들: SQL 인젝션, 크로스 사이트 스크립팅, 세션 관리 약점... 이 친구들한테는 그라운드호그 데이 같아요.그들은 수년 동안 개발자들이 직접 고칠 수 있는 코드 위반 사항을 찾아내고 고치는 데 시간을 쏟았습니다. 단, 보안이 프로세스의 우선순위가 아니었다는 점만 빼면요. "특히 기능 제공이 왕이고 보안이 창의적인 프로세스와 프로젝트 완성의 승리를 훔치는 애자일 개발 시대에 말이죠.

이는 어느 팀에 대한 부정적인 평가도 아닙니다. 개발자와 AppSec 전문가 모두 매우 중요한 일을 해야 하지만 서로 방해하는 일이 계속되고 있습니다.이러한 상황은 보안 인식이 거의 없는 개발자들이 부정적인 보안 문화 속에서 작업하면서 안전하지 않은 코드를 생성하므로 SDLC에 결함이 생길 뿐입니다. 이 코드는 처음 작성된 후 한참 후에 스캔, 평가 및 수정해야 합니다.AppSec은 반복되는 사소한 문제에 너무 사로잡혀 방치할 경우 여전히 회사에 재앙을 초래할 수 있기 때문에 정말 복잡한 문제를 해결할 시간이 거의 없습니다.

테스트를 코드의 보안 약점을 모두 찾아내는 데 사용함으로써 시간, 비용 및 리소스를 낭비하고 있습니다.게다가 이틀에 한 번씩 대규모 데이터 침해가 발생하고 있는 상황에서 이 방법은 최적으로 작동하지 않는 것이 분명합니다.이러한 새로운 표준은 여전히 최종 제품 상태를 평가하고 있습니다 (아마도 모든 개발자가 보안을 알고 있다는 가정 하에 이미 구축된 표준처럼, 그렇지 않을 수도 있습니다).이 단계는 결함을 수정하기에 가장 비용이 많이 들고 어려운 단계입니다. 마치 멋진 새 집을 짓는 것과 같지만 입주 당일에 안전 팀을 불러 위험 요소를 점검하는 것과 같습니다.기초에 문제가 있다면 문제 해결을 시작하기 위해 해당 지역에 도착하는 데 드는 시간과 비용, 그리고 골치 아픈 일을 상상해 보십시오.간단히 다시 시작하는 것이 더 쉽고 비용도 적게 드는 경우가 많습니다 (그리고 첫 버전을 만든 사람이라면 누구나 이 과정을 완전히 만족하지 못할 수도 있습니다).

우리는 반드시 처음부터 작업해야 합니다. 개발팀이 보안 모범 사례에 참여하도록 하고, 효율적으로 안전하게 코딩할 수 있는 지식을 제공하여 긍정적인 보안 문화를 만들고 유지해야 합니다. 각각의 직장.

학습 곡선인가요?네, 맞아요.불가능해요?절대 아니죠.그리고 지루한 고역일 필요도 없죠.개발자의 창의적이고 문제를 해결하는 특성에 직접적으로 어필하는 교육 방법은 이미 은행 및 금융 부문에서 엄청난 성공을 거두었습니다. 캐피탈 원에서의 러스 울프스 체험 모든 징후입니다.

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

업데이트된 PCI 보안 표준을 용도와 같이 사용자가 바로 사용할 수 있는 완성된 금융 상품이 최적의 보안 및 안전을 위해 이러한 모범 사례를 따라야 한다는 점에서 보면 전혀 문제가 없습니다.하지만 제 생각에는 금융 기업이든 아니든 모든 회사가 기능 품질과 높은 보안 표준을 모두 갖춘 소프트웨어 최종 상태에 도달할 수 있는 가장 좋은 기회를 갖게 될 것입니다. 한 걸음 물러서서 사이클의 시작부터 이 작업을 수행하는 것이 훨씬 더 효율적이라는 것을 깨닫기만 한다면 말입니다.

완벽한 최종 상태?아시다시피, 제품을 스캔하고 수작업으로 검토한 후 완벽하고 오류 없이 나올 때 발생하는 문제죠?아직 찾고 있는 중이에요.지금으로서는 유니콘입니다.

왜 그렇게 애매한가요?여러 가지 요인이 있습니다.

  • 스캔 도구는 많이 사용되지만 항상 효과적인 것은 아닙니다.오탐지는 사용에 따른 실망스럽고 시간을 낭비하는 부산물입니다. DAST/SAST/PCI 스캐닝을 함께 사용하더라도 코드 기반에서 발생할 수 있는 모든 취약점을 식별하고 찾아낼 수는 없습니다.물론, 그들은 수도 있습니다 모든 것을 명확하게 설명해 주지만 그들은 정말로 모든 것을 찾고 있습니까?공격자는 단 하나의 취약점만 악용하면 보호된다고 생각하는 항목에 액세스할 수 있습니다.
  • 개발자들은 계속해서 같은 실수를 저지르고 있습니다.개발자 간에는 보안에 관한 지식이 분산되지 않으며 잘 알려져 문서화된 “보안 코드 레시피" (양호하고 안전한 코드 패턴) 도 없습니다.
  • 협력적이고 긍정적인 보안 문화를 구축하는 데 중점을 둘 필요는 없습니다.
  • 개발자는 창의적인 프로세스와 애자일 개발 방법론을 방해하지 않으면서 자신이 작성한 제품에 보안을 적용할 수 있는 적절한 도구를 제공해야 합니다.

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

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

우리는 지금 진화의 시대에 살고 있습니다.수년 동안 일반적으로 소프트웨어 보안은 선택 사항이었습니다.오늘날에는 기본적으로 필수입니다. 특히 민감한 정보 (금융, 의료, 사회보장 등) 를 보관하는 사람에게는 더욱 그렇습니다.

PCI Security Standards Council이 벤치마크를 설정하는 데 도움을 주고 있지만, 업계의 모든 존경과 영향력을 바탕으로 적절하고 긍정적인 교육과 도구에 중점을 두고 개발자를 위한 실용적인 지침을 포함하기 위해 노력하는 모습을 보고 싶습니다.현재로서는 개발 팀이 보안을 인지하고 규정을 준수하는지 확인해야 한다는 조직 부담은 없습니다. 또한 많은 개발자들이 해를 끼치려는 사람들이 악용할 때 쉽게 고칠 수 있는 사소한 실수의 심각성을 이해하지 못하고 있습니다.

인생에서 가치 있는 일이 무엇이든 기대하듯이, 진정으로 변화를 일으키기 위해서는 정말 한 마을이 필요합니다.그리고 대기의 변화가 (바라건대) 우리 모두를 휩쓸게 될 거예요. 더 왼쪽으로.

Ressourcen anzeigen
Ressourcen anzeigen

올해 PCI 보안 표준 위원회는 PCI 소프트웨어 보안 프레임워크의 일부로 완전히 새로운 소프트웨어 보안 지침을 발표했습니다.이번 업데이트는 소프트웨어 보안 모범 사례를 최신 소프트웨어 개발과 연계하는 것을 목표로 합니다.

Sind Sie an weiteren Informationen interessiert?

Vorstandsvorsitzender, Chairman und Mitbegründer

mehr erfahren

Secure Code Warrior ist für Unternehmen da, um den Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Unabhängig davon, ob Sie AppSec-Manager, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind, können wir Ihnen dabei helfen, die Risiken zu reduzieren, die mit unsicherem Code verbunden sind.

Demo-Termin vereinbaren
Freigabeziel:
LinkedIn-MarkenSozialx Logo
Verfasser
Pieter Danhieux
Veröffentlicht Jul 04, 2019

Vorstandsvorsitzender, Chairman und Mitbegründer

Pieter Danhieux ist ein weltweit anerkannter Sicherheitsexperte mit mehr als 12 Jahren Erfahrung als Sicherheitsberater und 8 Jahren als Principal Instructor für SANS, wo er offensive Techniken lehrt, wie man Organisationen, Systeme und Einzelpersonen auf Sicherheitsschwächen hin untersucht und bewertet. Im Jahr 2016 wurde er als einer der "Coolest Tech People in Australia" (Business Insider) ausgezeichnet, erhielt die Auszeichnung "Cyber Security Professional of the Year" (AISA - Australian Information Security Association) und besitzt die Zertifizierungen GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.

Freigabeziel:
LinkedIn-MarkenSozialx Logo

이 기사의 한 버전은 원래 에 게시되었습니다. 디지털 트랜잭션 매거진.

올해 PCI 보안 표준 위원회는 완전히 새로운 세트를 출시했습니다. 소프트웨어 보안 지침 PCI 소프트웨어 보안 프레임워크의 일부로이번 업데이트는 소프트웨어 보안 모범 사례를 최신 소프트웨어 개발과 연계하는 것을 목표로 합니다.우리 삶의 대부분이 급속히 디지털화되기 훨씬 이전에 세워졌던 보안 표준을 다시 생각해 보아야 하기 때문에 시간이 지남에 따라 이 프로세스가 어떻게 변해왔는지 인정하는 환상적인 이니셔티브입니다.

이는 우리 업계가 변화하는 요구 사항에 따라 변화하는 적응형 가이드라인에 대한 아이디어에 더욱 긴밀하게 관여하고 있는 것은 물론 보안 개발 프로세스를 계속 느슨하게 유지할 경우 매우 빠르게 통제 불능 상태가 될 수 있는 사이버 보안 환경의 요구에 더욱 긴밀하게 관여하고 있다는 분명한 증거입니다.당연히 PCI 보안 표준 위원회 (PCI Security Standards Council) 가 은행 및 금융 업계 내에서 관리 기관의 역할을 수행함에 따라 (예: 자금, 신용 카드, 온라인 거래 및 판매 시점을 보호하기 위해 당사가 신뢰하는 소프트웨어에 대한 보안 표준을 설정하는 것과 같이) 리스크는 많은 위험을 수반하며 위험을 줄이려는 의욕도 큽니다.

이러한 표준은 이전 버전보다 확실히 개선되었으며 전반적인 품질 평가의 일환으로 보안을 우선시하는 빠르고 혁신적인 기능 개발의 허점을 메우는 데 어느 정도 도움이 되지만, 아직 갈 길이 멀다는 사실은 다소 실망스러운 현실입니다.

아니, 그건 내가 “으악, 험버그!” 라고 말하는 게 아니야.이 이니셔티브에.사실 이러한 새로운 보안 지침은 우리를 좌익으로 이끌지 못합니다.

우리는 여전히 테스트에 집착하고 있었습니다 (그리고 테스트는 너무 늦었습니다).

PCI 보안 표준 프레임워크에서 발견한 한 가지 눈에 띄는 문제는 테스트에 대한 명백한 의존성입니다.물론 소프트웨어는 아직 테스트를 거쳐야 하지만 (그리고 SAST/DAST/IAST 프로세스도 여전히 그 자리를 지키고 있습니다), 우리는 여전히 같은 함정에 빠졌고 다른 결과를 기대하고 있습니다.

누가 다음에 줄을 씁니까? 코드 라인 우리가 알고 사랑하고 신뢰하는 소프트웨어를 만들기 위해서요?소프트웨어 개발자.

스캐닝 도구나 수동 코드 검토를 통해 이 코드를 테스트할 때 부럽지 않은 사람이 있을까요?AppSec 전문가.

이 전문가들이 계속해서 발견하고 있는 것은 무엇일까요?수십 년 동안 우리를 괴롭혔던 바로 그 버그.몇 년 동안 해결 방법을 알고 있었던 간단한 것들: SQL 인젝션, 크로스 사이트 스크립팅, 세션 관리 약점... 이 친구들한테는 그라운드호그 데이 같아요.그들은 수년 동안 개발자들이 직접 고칠 수 있는 코드 위반 사항을 찾아내고 고치는 데 시간을 쏟았습니다. 단, 보안이 프로세스의 우선순위가 아니었다는 점만 빼면요. "특히 기능 제공이 왕이고 보안이 창의적인 프로세스와 프로젝트 완성의 승리를 훔치는 애자일 개발 시대에 말이죠.

이는 어느 팀에 대한 부정적인 평가도 아닙니다. 개발자와 AppSec 전문가 모두 매우 중요한 일을 해야 하지만 서로 방해하는 일이 계속되고 있습니다.이러한 상황은 보안 인식이 거의 없는 개발자들이 부정적인 보안 문화 속에서 작업하면서 안전하지 않은 코드를 생성하므로 SDLC에 결함이 생길 뿐입니다. 이 코드는 처음 작성된 후 한참 후에 스캔, 평가 및 수정해야 합니다.AppSec은 반복되는 사소한 문제에 너무 사로잡혀 방치할 경우 여전히 회사에 재앙을 초래할 수 있기 때문에 정말 복잡한 문제를 해결할 시간이 거의 없습니다.

테스트를 코드의 보안 약점을 모두 찾아내는 데 사용함으로써 시간, 비용 및 리소스를 낭비하고 있습니다.게다가 이틀에 한 번씩 대규모 데이터 침해가 발생하고 있는 상황에서 이 방법은 최적으로 작동하지 않는 것이 분명합니다.이러한 새로운 표준은 여전히 최종 제품 상태를 평가하고 있습니다 (아마도 모든 개발자가 보안을 알고 있다는 가정 하에 이미 구축된 표준처럼, 그렇지 않을 수도 있습니다).이 단계는 결함을 수정하기에 가장 비용이 많이 들고 어려운 단계입니다. 마치 멋진 새 집을 짓는 것과 같지만 입주 당일에 안전 팀을 불러 위험 요소를 점검하는 것과 같습니다.기초에 문제가 있다면 문제 해결을 시작하기 위해 해당 지역에 도착하는 데 드는 시간과 비용, 그리고 골치 아픈 일을 상상해 보십시오.간단히 다시 시작하는 것이 더 쉽고 비용도 적게 드는 경우가 많습니다 (그리고 첫 버전을 만든 사람이라면 누구나 이 과정을 완전히 만족하지 못할 수도 있습니다).

우리는 반드시 처음부터 작업해야 합니다. 개발팀이 보안 모범 사례에 참여하도록 하고, 효율적으로 안전하게 코딩할 수 있는 지식을 제공하여 긍정적인 보안 문화를 만들고 유지해야 합니다. 각각의 직장.

학습 곡선인가요?네, 맞아요.불가능해요?절대 아니죠.그리고 지루한 고역일 필요도 없죠.개발자의 창의적이고 문제를 해결하는 특성에 직접적으로 어필하는 교육 방법은 이미 은행 및 금융 부문에서 엄청난 성공을 거두었습니다. 캐피탈 원에서의 러스 울프스 체험 모든 징후입니다.

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

업데이트된 PCI 보안 표준을 용도와 같이 사용자가 바로 사용할 수 있는 완성된 금융 상품이 최적의 보안 및 안전을 위해 이러한 모범 사례를 따라야 한다는 점에서 보면 전혀 문제가 없습니다.하지만 제 생각에는 금융 기업이든 아니든 모든 회사가 기능 품질과 높은 보안 표준을 모두 갖춘 소프트웨어 최종 상태에 도달할 수 있는 가장 좋은 기회를 갖게 될 것입니다. 한 걸음 물러서서 사이클의 시작부터 이 작업을 수행하는 것이 훨씬 더 효율적이라는 것을 깨닫기만 한다면 말입니다.

완벽한 최종 상태?아시다시피, 제품을 스캔하고 수작업으로 검토한 후 완벽하고 오류 없이 나올 때 발생하는 문제죠?아직 찾고 있는 중이에요.지금으로서는 유니콘입니다.

왜 그렇게 애매한가요?여러 가지 요인이 있습니다.

  • 스캔 도구는 많이 사용되지만 항상 효과적인 것은 아닙니다.오탐지는 사용에 따른 실망스럽고 시간을 낭비하는 부산물입니다. DAST/SAST/PCI 스캐닝을 함께 사용하더라도 코드 기반에서 발생할 수 있는 모든 취약점을 식별하고 찾아낼 수는 없습니다.물론, 그들은 수도 있습니다 모든 것을 명확하게 설명해 주지만 그들은 정말로 모든 것을 찾고 있습니까?공격자는 단 하나의 취약점만 악용하면 보호된다고 생각하는 항목에 액세스할 수 있습니다.
  • 개발자들은 계속해서 같은 실수를 저지르고 있습니다.개발자 간에는 보안에 관한 지식이 분산되지 않으며 잘 알려져 문서화된 “보안 코드 레시피" (양호하고 안전한 코드 패턴) 도 없습니다.
  • 협력적이고 긍정적인 보안 문화를 구축하는 데 중점을 둘 필요는 없습니다.
  • 개발자는 창의적인 프로세스와 애자일 개발 방법론을 방해하지 않으면서 자신이 작성한 제품에 보안을 적용할 수 있는 적절한 도구를 제공해야 합니다.

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

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

우리는 지금 진화의 시대에 살고 있습니다.수년 동안 일반적으로 소프트웨어 보안은 선택 사항이었습니다.오늘날에는 기본적으로 필수입니다. 특히 민감한 정보 (금융, 의료, 사회보장 등) 를 보관하는 사람에게는 더욱 그렇습니다.

PCI Security Standards Council이 벤치마크를 설정하는 데 도움을 주고 있지만, 업계의 모든 존경과 영향력을 바탕으로 적절하고 긍정적인 교육과 도구에 중점을 두고 개발자를 위한 실용적인 지침을 포함하기 위해 노력하는 모습을 보고 싶습니다.현재로서는 개발 팀이 보안을 인지하고 규정을 준수하는지 확인해야 한다는 조직 부담은 없습니다. 또한 많은 개발자들이 해를 끼치려는 사람들이 악용할 때 쉽게 고칠 수 있는 사소한 실수의 심각성을 이해하지 못하고 있습니다.

인생에서 가치 있는 일이 무엇이든 기대하듯이, 진정으로 변화를 일으키기 위해서는 정말 한 마을이 필요합니다.그리고 대기의 변화가 (바라건대) 우리 모두를 휩쓸게 될 거예요. 더 왼쪽으로.

Ressourcen anzeigen
Ressourcen anzeigen

Um den Bericht herunterzuladen, füllen Sie bitte das folgende Formular aus.

Wir bitten um Ihre Zustimmung, Ihnen Informationen zu unseren Produkten und/oder verwandten Themen der Sicherheitscodierung zukommen zu lassen. Wir behandeln Ihre personenbezogenen Daten stets mit größter Sorgfalt und verkaufen sie niemals zu Marketingzwecken an andere Unternehmen.

Einreichung
scw Erfolgssymbol
scw-Fehlersymbol
Um das Formular zu senden, aktivieren Sie bitte das „Analytics“-Cookie. Nach Abschluss können Sie es jederzeit wieder deaktivieren.

이 기사의 한 버전은 원래 에 게시되었습니다. 디지털 트랜잭션 매거진.

올해 PCI 보안 표준 위원회는 완전히 새로운 세트를 출시했습니다. 소프트웨어 보안 지침 PCI 소프트웨어 보안 프레임워크의 일부로이번 업데이트는 소프트웨어 보안 모범 사례를 최신 소프트웨어 개발과 연계하는 것을 목표로 합니다.우리 삶의 대부분이 급속히 디지털화되기 훨씬 이전에 세워졌던 보안 표준을 다시 생각해 보아야 하기 때문에 시간이 지남에 따라 이 프로세스가 어떻게 변해왔는지 인정하는 환상적인 이니셔티브입니다.

이는 우리 업계가 변화하는 요구 사항에 따라 변화하는 적응형 가이드라인에 대한 아이디어에 더욱 긴밀하게 관여하고 있는 것은 물론 보안 개발 프로세스를 계속 느슨하게 유지할 경우 매우 빠르게 통제 불능 상태가 될 수 있는 사이버 보안 환경의 요구에 더욱 긴밀하게 관여하고 있다는 분명한 증거입니다.당연히 PCI 보안 표준 위원회 (PCI Security Standards Council) 가 은행 및 금융 업계 내에서 관리 기관의 역할을 수행함에 따라 (예: 자금, 신용 카드, 온라인 거래 및 판매 시점을 보호하기 위해 당사가 신뢰하는 소프트웨어에 대한 보안 표준을 설정하는 것과 같이) 리스크는 많은 위험을 수반하며 위험을 줄이려는 의욕도 큽니다.

이러한 표준은 이전 버전보다 확실히 개선되었으며 전반적인 품질 평가의 일환으로 보안을 우선시하는 빠르고 혁신적인 기능 개발의 허점을 메우는 데 어느 정도 도움이 되지만, 아직 갈 길이 멀다는 사실은 다소 실망스러운 현실입니다.

아니, 그건 내가 “으악, 험버그!” 라고 말하는 게 아니야.이 이니셔티브에.사실 이러한 새로운 보안 지침은 우리를 좌익으로 이끌지 못합니다.

우리는 여전히 테스트에 집착하고 있었습니다 (그리고 테스트는 너무 늦었습니다).

PCI 보안 표준 프레임워크에서 발견한 한 가지 눈에 띄는 문제는 테스트에 대한 명백한 의존성입니다.물론 소프트웨어는 아직 테스트를 거쳐야 하지만 (그리고 SAST/DAST/IAST 프로세스도 여전히 그 자리를 지키고 있습니다), 우리는 여전히 같은 함정에 빠졌고 다른 결과를 기대하고 있습니다.

누가 다음에 줄을 씁니까? 코드 라인 우리가 알고 사랑하고 신뢰하는 소프트웨어를 만들기 위해서요?소프트웨어 개발자.

스캐닝 도구나 수동 코드 검토를 통해 이 코드를 테스트할 때 부럽지 않은 사람이 있을까요?AppSec 전문가.

이 전문가들이 계속해서 발견하고 있는 것은 무엇일까요?수십 년 동안 우리를 괴롭혔던 바로 그 버그.몇 년 동안 해결 방법을 알고 있었던 간단한 것들: SQL 인젝션, 크로스 사이트 스크립팅, 세션 관리 약점... 이 친구들한테는 그라운드호그 데이 같아요.그들은 수년 동안 개발자들이 직접 고칠 수 있는 코드 위반 사항을 찾아내고 고치는 데 시간을 쏟았습니다. 단, 보안이 프로세스의 우선순위가 아니었다는 점만 빼면요. "특히 기능 제공이 왕이고 보안이 창의적인 프로세스와 프로젝트 완성의 승리를 훔치는 애자일 개발 시대에 말이죠.

이는 어느 팀에 대한 부정적인 평가도 아닙니다. 개발자와 AppSec 전문가 모두 매우 중요한 일을 해야 하지만 서로 방해하는 일이 계속되고 있습니다.이러한 상황은 보안 인식이 거의 없는 개발자들이 부정적인 보안 문화 속에서 작업하면서 안전하지 않은 코드를 생성하므로 SDLC에 결함이 생길 뿐입니다. 이 코드는 처음 작성된 후 한참 후에 스캔, 평가 및 수정해야 합니다.AppSec은 반복되는 사소한 문제에 너무 사로잡혀 방치할 경우 여전히 회사에 재앙을 초래할 수 있기 때문에 정말 복잡한 문제를 해결할 시간이 거의 없습니다.

테스트를 코드의 보안 약점을 모두 찾아내는 데 사용함으로써 시간, 비용 및 리소스를 낭비하고 있습니다.게다가 이틀에 한 번씩 대규모 데이터 침해가 발생하고 있는 상황에서 이 방법은 최적으로 작동하지 않는 것이 분명합니다.이러한 새로운 표준은 여전히 최종 제품 상태를 평가하고 있습니다 (아마도 모든 개발자가 보안을 알고 있다는 가정 하에 이미 구축된 표준처럼, 그렇지 않을 수도 있습니다).이 단계는 결함을 수정하기에 가장 비용이 많이 들고 어려운 단계입니다. 마치 멋진 새 집을 짓는 것과 같지만 입주 당일에 안전 팀을 불러 위험 요소를 점검하는 것과 같습니다.기초에 문제가 있다면 문제 해결을 시작하기 위해 해당 지역에 도착하는 데 드는 시간과 비용, 그리고 골치 아픈 일을 상상해 보십시오.간단히 다시 시작하는 것이 더 쉽고 비용도 적게 드는 경우가 많습니다 (그리고 첫 버전을 만든 사람이라면 누구나 이 과정을 완전히 만족하지 못할 수도 있습니다).

우리는 반드시 처음부터 작업해야 합니다. 개발팀이 보안 모범 사례에 참여하도록 하고, 효율적으로 안전하게 코딩할 수 있는 지식을 제공하여 긍정적인 보안 문화를 만들고 유지해야 합니다. 각각의 직장.

학습 곡선인가요?네, 맞아요.불가능해요?절대 아니죠.그리고 지루한 고역일 필요도 없죠.개발자의 창의적이고 문제를 해결하는 특성에 직접적으로 어필하는 교육 방법은 이미 은행 및 금융 부문에서 엄청난 성공을 거두었습니다. 캐피탈 원에서의 러스 울프스 체험 모든 징후입니다.

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

업데이트된 PCI 보안 표준을 용도와 같이 사용자가 바로 사용할 수 있는 완성된 금융 상품이 최적의 보안 및 안전을 위해 이러한 모범 사례를 따라야 한다는 점에서 보면 전혀 문제가 없습니다.하지만 제 생각에는 금융 기업이든 아니든 모든 회사가 기능 품질과 높은 보안 표준을 모두 갖춘 소프트웨어 최종 상태에 도달할 수 있는 가장 좋은 기회를 갖게 될 것입니다. 한 걸음 물러서서 사이클의 시작부터 이 작업을 수행하는 것이 훨씬 더 효율적이라는 것을 깨닫기만 한다면 말입니다.

완벽한 최종 상태?아시다시피, 제품을 스캔하고 수작업으로 검토한 후 완벽하고 오류 없이 나올 때 발생하는 문제죠?아직 찾고 있는 중이에요.지금으로서는 유니콘입니다.

왜 그렇게 애매한가요?여러 가지 요인이 있습니다.

  • 스캔 도구는 많이 사용되지만 항상 효과적인 것은 아닙니다.오탐지는 사용에 따른 실망스럽고 시간을 낭비하는 부산물입니다. DAST/SAST/PCI 스캐닝을 함께 사용하더라도 코드 기반에서 발생할 수 있는 모든 취약점을 식별하고 찾아낼 수는 없습니다.물론, 그들은 수도 있습니다 모든 것을 명확하게 설명해 주지만 그들은 정말로 모든 것을 찾고 있습니까?공격자는 단 하나의 취약점만 악용하면 보호된다고 생각하는 항목에 액세스할 수 있습니다.
  • 개발자들은 계속해서 같은 실수를 저지르고 있습니다.개발자 간에는 보안에 관한 지식이 분산되지 않으며 잘 알려져 문서화된 “보안 코드 레시피" (양호하고 안전한 코드 패턴) 도 없습니다.
  • 협력적이고 긍정적인 보안 문화를 구축하는 데 중점을 둘 필요는 없습니다.
  • 개발자는 창의적인 프로세스와 애자일 개발 방법론을 방해하지 않으면서 자신이 작성한 제품에 보안을 적용할 수 있는 적절한 도구를 제공해야 합니다.

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

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

우리는 지금 진화의 시대에 살고 있습니다.수년 동안 일반적으로 소프트웨어 보안은 선택 사항이었습니다.오늘날에는 기본적으로 필수입니다. 특히 민감한 정보 (금융, 의료, 사회보장 등) 를 보관하는 사람에게는 더욱 그렇습니다.

PCI Security Standards Council이 벤치마크를 설정하는 데 도움을 주고 있지만, 업계의 모든 존경과 영향력을 바탕으로 적절하고 긍정적인 교육과 도구에 중점을 두고 개발자를 위한 실용적인 지침을 포함하기 위해 노력하는 모습을 보고 싶습니다.현재로서는 개발 팀이 보안을 인지하고 규정을 준수하는지 확인해야 한다는 조직 부담은 없습니다. 또한 많은 개발자들이 해를 끼치려는 사람들이 악용할 때 쉽게 고칠 수 있는 사소한 실수의 심각성을 이해하지 못하고 있습니다.

인생에서 가치 있는 일이 무엇이든 기대하듯이, 진정으로 변화를 일으키기 위해서는 정말 한 마을이 필요합니다.그리고 대기의 변화가 (바라건대) 우리 모두를 휩쓸게 될 거예요. 더 왼쪽으로.

Webinar ansehen
Beginnen
mehr erfahren

Klicken Sie auf den folgenden Link und laden Sie die PDF-Datei dieser Ressource herunter.

Secure Code Warrior ist für Unternehmen da, um den Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Unabhängig davon, ob Sie AppSec-Manager, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind, können wir Ihnen dabei helfen, die Risiken zu reduzieren, die mit unsicherem Code verbunden sind.

Bericht anzeigenDemo-Termin vereinbaren
Ressourcen anzeigen
Freigabeziel:
LinkedIn-MarkenSozialx Logo
Sind Sie an weiteren Informationen interessiert?

Freigabeziel:
LinkedIn-MarkenSozialx Logo
Verfasser
Pieter Danhieux
Veröffentlicht Jul 04, 2019

Vorstandsvorsitzender, Chairman und Mitbegründer

Pieter Danhieux ist ein weltweit anerkannter Sicherheitsexperte mit mehr als 12 Jahren Erfahrung als Sicherheitsberater und 8 Jahren als Principal Instructor für SANS, wo er offensive Techniken lehrt, wie man Organisationen, Systeme und Einzelpersonen auf Sicherheitsschwächen hin untersucht und bewertet. Im Jahr 2016 wurde er als einer der "Coolest Tech People in Australia" (Business Insider) ausgezeichnet, erhielt die Auszeichnung "Cyber Security Professional of the Year" (AISA - Australian Information Security Association) und besitzt die Zertifizierungen GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.

Freigabeziel:
LinkedIn-MarkenSozialx Logo

이 기사의 한 버전은 원래 에 게시되었습니다. 디지털 트랜잭션 매거진.

올해 PCI 보안 표준 위원회는 완전히 새로운 세트를 출시했습니다. 소프트웨어 보안 지침 PCI 소프트웨어 보안 프레임워크의 일부로이번 업데이트는 소프트웨어 보안 모범 사례를 최신 소프트웨어 개발과 연계하는 것을 목표로 합니다.우리 삶의 대부분이 급속히 디지털화되기 훨씬 이전에 세워졌던 보안 표준을 다시 생각해 보아야 하기 때문에 시간이 지남에 따라 이 프로세스가 어떻게 변해왔는지 인정하는 환상적인 이니셔티브입니다.

이는 우리 업계가 변화하는 요구 사항에 따라 변화하는 적응형 가이드라인에 대한 아이디어에 더욱 긴밀하게 관여하고 있는 것은 물론 보안 개발 프로세스를 계속 느슨하게 유지할 경우 매우 빠르게 통제 불능 상태가 될 수 있는 사이버 보안 환경의 요구에 더욱 긴밀하게 관여하고 있다는 분명한 증거입니다.당연히 PCI 보안 표준 위원회 (PCI Security Standards Council) 가 은행 및 금융 업계 내에서 관리 기관의 역할을 수행함에 따라 (예: 자금, 신용 카드, 온라인 거래 및 판매 시점을 보호하기 위해 당사가 신뢰하는 소프트웨어에 대한 보안 표준을 설정하는 것과 같이) 리스크는 많은 위험을 수반하며 위험을 줄이려는 의욕도 큽니다.

이러한 표준은 이전 버전보다 확실히 개선되었으며 전반적인 품질 평가의 일환으로 보안을 우선시하는 빠르고 혁신적인 기능 개발의 허점을 메우는 데 어느 정도 도움이 되지만, 아직 갈 길이 멀다는 사실은 다소 실망스러운 현실입니다.

아니, 그건 내가 “으악, 험버그!” 라고 말하는 게 아니야.이 이니셔티브에.사실 이러한 새로운 보안 지침은 우리를 좌익으로 이끌지 못합니다.

우리는 여전히 테스트에 집착하고 있었습니다 (그리고 테스트는 너무 늦었습니다).

PCI 보안 표준 프레임워크에서 발견한 한 가지 눈에 띄는 문제는 테스트에 대한 명백한 의존성입니다.물론 소프트웨어는 아직 테스트를 거쳐야 하지만 (그리고 SAST/DAST/IAST 프로세스도 여전히 그 자리를 지키고 있습니다), 우리는 여전히 같은 함정에 빠졌고 다른 결과를 기대하고 있습니다.

누가 다음에 줄을 씁니까? 코드 라인 우리가 알고 사랑하고 신뢰하는 소프트웨어를 만들기 위해서요?소프트웨어 개발자.

스캐닝 도구나 수동 코드 검토를 통해 이 코드를 테스트할 때 부럽지 않은 사람이 있을까요?AppSec 전문가.

이 전문가들이 계속해서 발견하고 있는 것은 무엇일까요?수십 년 동안 우리를 괴롭혔던 바로 그 버그.몇 년 동안 해결 방법을 알고 있었던 간단한 것들: SQL 인젝션, 크로스 사이트 스크립팅, 세션 관리 약점... 이 친구들한테는 그라운드호그 데이 같아요.그들은 수년 동안 개발자들이 직접 고칠 수 있는 코드 위반 사항을 찾아내고 고치는 데 시간을 쏟았습니다. 단, 보안이 프로세스의 우선순위가 아니었다는 점만 빼면요. "특히 기능 제공이 왕이고 보안이 창의적인 프로세스와 프로젝트 완성의 승리를 훔치는 애자일 개발 시대에 말이죠.

이는 어느 팀에 대한 부정적인 평가도 아닙니다. 개발자와 AppSec 전문가 모두 매우 중요한 일을 해야 하지만 서로 방해하는 일이 계속되고 있습니다.이러한 상황은 보안 인식이 거의 없는 개발자들이 부정적인 보안 문화 속에서 작업하면서 안전하지 않은 코드를 생성하므로 SDLC에 결함이 생길 뿐입니다. 이 코드는 처음 작성된 후 한참 후에 스캔, 평가 및 수정해야 합니다.AppSec은 반복되는 사소한 문제에 너무 사로잡혀 방치할 경우 여전히 회사에 재앙을 초래할 수 있기 때문에 정말 복잡한 문제를 해결할 시간이 거의 없습니다.

테스트를 코드의 보안 약점을 모두 찾아내는 데 사용함으로써 시간, 비용 및 리소스를 낭비하고 있습니다.게다가 이틀에 한 번씩 대규모 데이터 침해가 발생하고 있는 상황에서 이 방법은 최적으로 작동하지 않는 것이 분명합니다.이러한 새로운 표준은 여전히 최종 제품 상태를 평가하고 있습니다 (아마도 모든 개발자가 보안을 알고 있다는 가정 하에 이미 구축된 표준처럼, 그렇지 않을 수도 있습니다).이 단계는 결함을 수정하기에 가장 비용이 많이 들고 어려운 단계입니다. 마치 멋진 새 집을 짓는 것과 같지만 입주 당일에 안전 팀을 불러 위험 요소를 점검하는 것과 같습니다.기초에 문제가 있다면 문제 해결을 시작하기 위해 해당 지역에 도착하는 데 드는 시간과 비용, 그리고 골치 아픈 일을 상상해 보십시오.간단히 다시 시작하는 것이 더 쉽고 비용도 적게 드는 경우가 많습니다 (그리고 첫 버전을 만든 사람이라면 누구나 이 과정을 완전히 만족하지 못할 수도 있습니다).

우리는 반드시 처음부터 작업해야 합니다. 개발팀이 보안 모범 사례에 참여하도록 하고, 효율적으로 안전하게 코딩할 수 있는 지식을 제공하여 긍정적인 보안 문화를 만들고 유지해야 합니다. 각각의 직장.

학습 곡선인가요?네, 맞아요.불가능해요?절대 아니죠.그리고 지루한 고역일 필요도 없죠.개발자의 창의적이고 문제를 해결하는 특성에 직접적으로 어필하는 교육 방법은 이미 은행 및 금융 부문에서 엄청난 성공을 거두었습니다. 캐피탈 원에서의 러스 울프스 체험 모든 징후입니다.

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

업데이트된 PCI 보안 표준을 용도와 같이 사용자가 바로 사용할 수 있는 완성된 금융 상품이 최적의 보안 및 안전을 위해 이러한 모범 사례를 따라야 한다는 점에서 보면 전혀 문제가 없습니다.하지만 제 생각에는 금융 기업이든 아니든 모든 회사가 기능 품질과 높은 보안 표준을 모두 갖춘 소프트웨어 최종 상태에 도달할 수 있는 가장 좋은 기회를 갖게 될 것입니다. 한 걸음 물러서서 사이클의 시작부터 이 작업을 수행하는 것이 훨씬 더 효율적이라는 것을 깨닫기만 한다면 말입니다.

완벽한 최종 상태?아시다시피, 제품을 스캔하고 수작업으로 검토한 후 완벽하고 오류 없이 나올 때 발생하는 문제죠?아직 찾고 있는 중이에요.지금으로서는 유니콘입니다.

왜 그렇게 애매한가요?여러 가지 요인이 있습니다.

  • 스캔 도구는 많이 사용되지만 항상 효과적인 것은 아닙니다.오탐지는 사용에 따른 실망스럽고 시간을 낭비하는 부산물입니다. DAST/SAST/PCI 스캐닝을 함께 사용하더라도 코드 기반에서 발생할 수 있는 모든 취약점을 식별하고 찾아낼 수는 없습니다.물론, 그들은 수도 있습니다 모든 것을 명확하게 설명해 주지만 그들은 정말로 모든 것을 찾고 있습니까?공격자는 단 하나의 취약점만 악용하면 보호된다고 생각하는 항목에 액세스할 수 있습니다.
  • 개발자들은 계속해서 같은 실수를 저지르고 있습니다.개발자 간에는 보안에 관한 지식이 분산되지 않으며 잘 알려져 문서화된 “보안 코드 레시피" (양호하고 안전한 코드 패턴) 도 없습니다.
  • 협력적이고 긍정적인 보안 문화를 구축하는 데 중점을 둘 필요는 없습니다.
  • 개발자는 창의적인 프로세스와 애자일 개발 방법론을 방해하지 않으면서 자신이 작성한 제품에 보안을 적용할 수 있는 적절한 도구를 제공해야 합니다.

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

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

우리는 지금 진화의 시대에 살고 있습니다.수년 동안 일반적으로 소프트웨어 보안은 선택 사항이었습니다.오늘날에는 기본적으로 필수입니다. 특히 민감한 정보 (금융, 의료, 사회보장 등) 를 보관하는 사람에게는 더욱 그렇습니다.

PCI Security Standards Council이 벤치마크를 설정하는 데 도움을 주고 있지만, 업계의 모든 존경과 영향력을 바탕으로 적절하고 긍정적인 교육과 도구에 중점을 두고 개발자를 위한 실용적인 지침을 포함하기 위해 노력하는 모습을 보고 싶습니다.현재로서는 개발 팀이 보안을 인지하고 규정을 준수하는지 확인해야 한다는 조직 부담은 없습니다. 또한 많은 개발자들이 해를 끼치려는 사람들이 악용할 때 쉽게 고칠 수 있는 사소한 실수의 심각성을 이해하지 못하고 있습니다.

인생에서 가치 있는 일이 무엇이든 기대하듯이, 진정으로 변화를 일으키기 위해서는 정말 한 마을이 필요합니다.그리고 대기의 변화가 (바라건대) 우리 모두를 휩쓸게 될 거예요. 더 왼쪽으로.

Inhaltsverzeichnis

PDF herunterladen
Ressourcen anzeigen
Sind Sie an weiteren Informationen interessiert?

Vorstandsvorsitzender, Chairman und Mitbegründer

mehr erfahren

Secure Code Warrior ist für Unternehmen da, um den Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Unabhängig davon, ob Sie AppSec-Manager, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind, können wir Ihnen dabei helfen, die Risiken zu reduzieren, die mit unsicherem Code verbunden sind.

Demo-Termin vereinbarenDownload
Freigabeziel:
LinkedIn-MarkenSozialx Logo
Ressourcen-Hub

Hilfreiche Ressourcen für den Einstieg

Weitere Beiträge
Ressourcen-Hub

Hilfreiche Ressourcen für den Einstieg

Weitere Beiträge