이 기사의 버전은 SD 타임즈에 나타났습니다. 여기에서 업데이트되고 신디케이트되었습니다.

‍

우리가 진보에 대해 이야기 할 때, 일반적으로 디지털 발전은 대화의 최전선에 있습니다. 우리는 모든 것이 더 좋고, 빠르고, 편리하고, 더 강력하기를 원하며, 적은 돈, 시간 및 위험을 위해 그것을하고 싶습니다. 대부분의 경우 이러한 "불가능한"목표는 결국 충족됩니다. 몇 년 동안 여러 버전이 걸릴 수도 있지만 (그리고 기능 디자인에서 기어를 한 번 더 변경하라는 요청을 받으면 쿠데타를 시작할 수있는 개발자 팀), 매일 코드가 세상을 변화시키고 있습니다. 

그러나 훌륭한 소프트웨어 확장에는 큰 책임이 따르며, 현실은 보안 관점에서 처리 할 준비가되어 있지 않다는 것입니다. 소프트웨어 개발은 더 이상 섬이 아니며, 클라우드, 가전 제품 및 차량의 임베디드 시스템, 모든 것을 연결하는 API는 말할 것도없고 중요한 인프라에서 소프트웨어 기반 위험의 모든 측면을 고려할 때 공격 표면은 경계가없고 통제 할 수 없습니다. 

노련한 보안 전문가들에 의해 각 코드 라인이 꼼꼼하게 점검되는 마법의 시간을 기대할 수는 없지만 기술 격차가 조만간 줄어들지 않고 있지만 업계로서 코드 수준 보안에 대한보다 전체적인 접근 방식을 채택 할 수 있습니다.

무한한 공격 표면을 당면한 도구로 어떻게 연결시킬 수 있는지 살펴 보겠습니다.

비즈니스 위험 수준 (그리고 당신이 기꺼이 받아 들일 수있는 것)에 대해 현실적으로 생각하십시오.

완벽한 보안은 지속 가능하지 않지만 눈가리개를 씌우고 모든 것이 푸른 하늘인 척하는 것도 아닙니다. 우리는 이미 조직이 고의로 취약한 코드를 제공한다는 것을 알고 있으며, 분명히 이것은 새로운 기능과 제품으로 출시 할 시간에 따라 계산 된 위험입니다. 

속도에서의 보안은 특히 DevSecOps가 표준 개발 방법론이 아닌 곳에서는 어려운 과제입니다. 그러나 최근의 Log4Shell 익스플로잇 을 살펴보면 코드의 상대적으로 작은 보안 문제가 어떻게 성공적인 공격의 기회를 열었는지 알아보고 낮은 품질의 코드를 제공하는 데 대한 계산 된 위험의 결과가 예상보다 훨씬 클 수 있음을 알 수 있습니다.

(액세스) 제어 괴물이되는 것에 익숙해지십시오.

비용이 많이 드는 데이터 침해는 잘못 구성된 클라우드 스토리지 환경으로 인해 발생하며, 액세스 제어 오류로 인한 민감한 데이터 노출의 가능성은 대부분의 조직에서 보안 팀을 계속 괴롭 히고 있습니다. 

2019년 포춘지 선정 500대 기업인 퍼스트 아메리칸 파이낸셜 코퍼레이션(First American Financial Corp. )은 이를 어려운 방법으로 발견했습니다. 비교적 쉽게 수정할 수 있는 인증 오류로 인해 은행 명세서, 모기지 계약, 사진 ID 등 8억 건 이상의 기록이 노출되었습니다. 문서 링크는 사용자 식별이나 로그인이 필요하지 않으므로 웹 브라우저를 사용하는 모든 사용자가 액세스할 수 있습니다. 더 나쁜 것은 순차적 인 숫자로 기록되어 링크의 단순한 숫자 변경으로 인해 새 데이터 레코드가 노출된다는 것을 의미합니다. 

이 보안 문제는 언론에 노출되기 전에 내부적으로 확인되었지만 고위험 보안 문제로 올바르게 분류하지 못했고 긴급한 수정을 위해 고위 경영진에게보고하지 않아 오늘날에도 여전히 탐색중인 낙진이 발생했습니다.

깨진 액세스 제어가 이제 OWASP Top 10의 맨 위에 자리 잡고있는 이유가 있습니다 : 먼지만큼 일반적이며, 개발자는 자체 빌드에서 인증 및 권한에 대한 모범 사례를 탐색하기 위해 검증 된 보안 인식과 실용적인 기술이 필요하며 민감한 데이터 노출을 보호하기위한 검사와 조치가 마련되어 있는지 확인합니다. 

API의 특성으로 인해 특히 관련성이 높고 까다 롭습니다. 그들은 디자인적으로 다른 응용 프로그램과 매우 수다스럽고, 개발 팀은 모든 잠재적 액세스 포인트에 대한 가시성을 가져야합니다. 결국, 그들은 더 안전한 소프트웨어를 제공하기 위해 알려지지 않은 변수와 사용 사례를 고려할 수 없습니다.

보안 프로그램 분석: 예방에 얼마나 중점을 두는가?

보안 프로그램의 많은 구성 요소가 사고 대응 및 대응에 전념하고 있지만 많은 조직이 보안 사고를 예방하는 데 사용할 수있는 모든 리소스를 활용하지 않음으로써 귀중한 위험 최소화를 놓치고 있습니다.

물론 문제가되는 버그를 발견하는 데 도움이되는 포괄적 인 보안 도구 스택이 있지만 거의 50 %의 회사가 취약한 코드를 배송하는 것을 인정했습니다. 시간 제약, 툴셋의 복잡성, 보고에 대응할 수 있는 숙련된 전문가의 부족은 본질적으로 계산된 위험에 기여하지만, 클라우드, 애플리케이션, API 기능, 임베디드 시스템, 라이브러리 및 끊임없이 확장되는 기술 환경에서 코드를 보호해야 한다는 사실은 우리가 항상 현재의 접근 방식에서 한 걸음 뒤쳐질 수 있도록 보장합니다.

보안 버그는 인간이 일으킨 문제이며, 로봇이 우리를 위해 모든 문제를 해결할 것으로 기대할 수는 없습니다. 개발 코호트가 매년 세미나뿐만 아니라 적절한 교육 빌딩 블록으로 효과적으로 숙련되지 않은 경우 저품질 코드를 표준으로 받아 들일 위험이 항상 있으며 보안 위험이 있습니다. 

개발자의 준비 상태를 과대 평가했습니까?

개발자는 보안 코딩 능력에 대해 거의 평가되지 않으며 우선 순위가 아닙니다 (많은 경우 KPI도 아닙니다). 그들은 더 나은 길을 보여주지 않거나 성공의 척도라고 말하면 가난한 보안 관행에 대한 가을 녀석이 될 수 없습니다. 

그러나 조직 내에서 제공된 지침이 일반적인 보안 위험을 완화하기 위해 엔지니어링 팀을 준비하는 데 효과적이라는 가정이 너무 자주 있습니다. 보안 모범 사례를 적용하기위한 교육 및 인식에 따라, 그들은 바람직한 첫 번째 방어선이 될 준비가되어 있지 않을 수도 있습니다 (그리고 끝없는 주입 결함으로 인해 펜테스트 보고서가 막히는 것을 막을 수 있습니다). 

이상적인 상태는 복잡성을 증가시키는 학습 경로가 완료되고 결과 기술이 실제 환경에서 개발자에게 실제로 작동하는지 확인하는 것입니다. 그러나 이를 위해서는 개발자가 처음부터 고려되고 올바르게 활성화되는 문화적 표준이 필요합니다. 우리가 산업으로서 우리가 스스로 만든 광대 한 코드 풍경을 지키기 위해 광야로 나간다면, 우리는 우리가 얻을 수있는 모든 도움이 필요할 것입니다 ... 그리고 우리 앞에는 우리가 깨닫는 것보다 더 많은 것이 있습니다.