늦게 사이버 보안 업계에서 매우 환영 하는 움직임이 있었다. 소프트웨어 빌드의 보안을 우선 적으로 우선 순위를 정하는 것과 관련된 정서가 가능한 한 빨리 많은 조직에서 개선되기 시작한 것으로 보입니다. 이는 사이버 보안에 대한 Biden의 행정 명령과같은 공식 조치와 함께 모든 사람이 소프트웨어 보안 및 데이터 안전을 보장하기 위해 자신의 역할을 수행해야 한다는 것을 분명히 했습니다. 특히 흥미로운 점은 보안 코딩 표준을 유지하는 개발자의 역할에 대한 대화가 정부 차원에서도 계속 진화하고 있다는 것입니다.

그러나 대화에서 빠진 것이 있습니다. 행정 명령은 개발자가 검증 된 보안 기술이 필요하다고제안하지만 현재 그러한 공식 인증은 존재하지 않습니다. 많은 기업들이 소프트웨어 보안의 규정 준수 및 더 높은 표준에 대한 탐구에서 NIST(EO에 대한 업데이트된 지침을 제공한)에 의해 계속 안내되지만, 올바른 도구를 통합하고 릴리스 속도를 유지하면서 취약점을 크게 줄이는 전략을 생각하고 있다면 대부분은 원하는 결과를 만들기에는 너무 일반적입니다. 이것은 많은 회사가 고정되지 않고 제한된 개발자 교육을 받거나 실용적인 실습 기술을 사용할 수 있도록 일반적인 기반을 구축하지 않는 곳입니다.

보안 인식 개발자는 나무에서 자라지 않지만 올바른 도구로 훨씬 빠르게 양육되고 상승 할 수 있습니다. 이를 위해 미국 정부의 행정명령 지침에 따라 NIST 준수에 대한 독자적인 과정을 발표하게 되어 기쁘게 생각합니다.

개발자를 위한 의미 있는 코드 수준 지원

여기에행정 명령 중요 (EO-critical) 소프트웨어에 대한 NIST 지침을 사용하여, 우리는 궁극적으로, 정부의 최고 수준에서 사용하는 중요한 소프트웨어의 보안을 개선할 다섯 가지 주요 목표를 달성하기 위해 과정을 구성하고, 이상적으로 처음부터 높은 품질의 개발을위한 벤치 마크 역할을해야한다.

개발 코호트의 진정한 컷스루를 위해서는 모든 업스킬링이 이론을 넘어서야 하며, 답을 찾고 민첩하게 유지하기 위해 일과 훈련 간에 일정한 맥락 전환을 초래하지 않는 방식으로 구현되어야 합니다. 세심한 보안 관행(보안 팀은 말할 것도 없고) 정시 개발 스프린트의 블로커로 간주되며 평균 적인 기능 중심 엔지니어의 스타일을 심각하게 경련시다. 

개발자에게 맞춤 맞춤 적합한 짧고 간식이 가능한 마이크로 학습은 서리가 내린 수신이 훨씬 적고 기억에 남을 만한 실용적인 기술 구축을 해야 합니다. 

NIST 코스에서 이 구성 방법을 살펴보십시오.

목표 1: EO 크리티컬 소프트웨어 및 EO 크리티컬 소프트웨어 플랫폼을 무단 액세스 및 사용으로부터 보호합니다.

보안 오용 및 부적절한 인증 관행은 공격자가 시스템에 성공적으로 침투하고, 계정을 인수하고, 데이터를 도용하는 데 의존합니다. 성공적으로 악용하면 큰 문제가 발생할 수 있는 일반적인 버그입니다.

에서 개발자는 Secure Code Warrior Learning Platform에서 개발자는 일상적인 작업에서 이러한 버그가 어떻게 나타나는지 정확하게 반영하는 실제 코드 스니펫을 기반으로 문제를 플레이하고 보안을 위한 정확한 솔루션을 찾도록 할 수 있습니다. 데브옵스 엔지니어의 경우 인프라 보안을 위해서는 세심한 액세스 제어 구성이 필요하며, Terraform, CloudFormation, Ansible과 같은 IaC(Infrastructure as Code) 언어와 Docker 및 Kubernetes에 사용되는 코드에서 이러한 요구 사항을 충족하기 위한 특수한 과제가 있습니다.

목표 2: EO 크리티컬 소프트웨어 및 EO 크리티컬 소프트웨어 플랫폼에서 사용하는 데이터의 기밀성, 무결성 및 가용성을 보호합니다.

이 목표를 위해 모든 도로는 액세스 제어로 이어집니다. 깨진 액세스 제어는 최근 OWASP Top 10 2021의상위 항목으로 주입 결함을 제거했으며 보안 인식 개발자의 기술을 가능한 한 빨리 찾고 수정해야하는 심각한 버그입니다.

이 과정은 코드 수준에서 최소 권한과 같은 개념을 다루며 사용자 계정에 대한 액세스를 필요한 영역만 모범 사례로 제한하는 방법을 제공하는 데 도움이 됩니다.

목표 3: EO 에이치 소프트웨어 플랫폼과 해당 플랫폼에 배포된 소프트웨어를 식별하고 유지 관리하여 EO 에 중요한 소프트웨어를 악용으로부터 보호합니다.

대규모 조직에서 가장 큰 과제 중 하나는 현재 진행 중인 모든 다양한 소프트웨어, 시스템 및 구성 요소에 대한 보안 감독을 유지하는 것입니다. 위험 관리 및 패치와 관련하여 이러한 요소는 보안 유지 관리를 수행하기 위해 경고가 높은 개발자와 함께 모든 보안 프로그램에서 우선 순위가 되어야 합니다. 

에 Secure Code Warrior Learning Platform개발자는 취약한 구성 요소를 식별하고 해결하는 데 도움이 되는 과제와 권한 기반 보안 오구성을 해결할 수 있습니다.

목표 4: EO 크리티컬 소프트웨어 및 EO 크리티컬 소프트웨어 플랫폼과 관련된 위협 및 사고를 신속하게 탐지, 대응 및 복구합니다.

많은 조직이 사이버 보안 문제를 다룰 때 예방과 는 반대로 사고 대응에 여전히 집중하는 것은 불행한 일입니다(그리고 시간과 돈의 낭비). 이것은 우리가 변화를 위해 싸우고있는 문화이며 개발자는 보안 모범 사례에서 적절하게 훈련 될 때 예방 화력을 제공하는 데 있습니다. 

Objective 4는 개발자가 역할의 맥락에서 자신의 환경과 소프트웨어 및 네트워크 수준에서 엔드포인트를 지속적으로 모니터링해야 합니다. 부족한 로깅 및 모니터링은 또 다른 일반적이고 교활한 버그이며 엔지니어가 일상적인 작업에서 이를 성공적으로 탐색할 수 있는 것이 중요합니다.

에 Secure Code Warrior Learning Platform개발자는 웹, API 또는 클라우드 언어로 작업하든 이러한 기술을 연마하는 데 어려움을 겪을 수 있습니다.

지속 가능성을 가진 보안 인식.

목표 5: EO 크리티컬 소프트웨어 및 EO 크리티컬 소프트웨어 플랫폼의 보안을 촉진하는 인간의 행동에 대한 이해와 성능을 강화합니다.

이것은 매우 일반화되어 있지만 달성하는 것이 가장 중요합니다... 처음 네 가지 목표를 마스터하지 않고는 할 수 없습니다. 이 지침은 빈번한 보안 인식 활동이 수행되며 EO 크리티컬 소프트웨어에 대한 모든 "인적 행동"은 역할과 책임의 맥락에서 적절하게 교육을 받은 사람들에 의해 수행될 것을 요청합니다.

개발자는 보안 구성 및 액세스 제어 외에도 코드와 가장 가깝고 개인적인 사용자 중 하나입니다. 그들의 보안 기술을 육성해야하며 NIST가 설명 한 대로 높은 기준을 달성하기 위해 실습 과정 구조는 특히 대규모 개발 코호트와 함께 이를 해결할 수있는 효율적인 방법이 될 수 있습니다. 

오늘 개발 팀의 경험 치수 와 보안 IQ에 추가를 시작하십시오.

이 문서의 원래 게재 위치는 보안 대로. 여기에서 업데이트 및 신디케이트되었습니다.

‍

우리의 집단 정신에 거의 뿌리 박혀 좋은 것이 더 좋은 것입니다. 당신이 정말로 좋아하는 것 중 하나를 가지고 있다면, 두세 개 또는 그 이상을 갖는 것은 아무런 문제가 없습니다. 결국, 당신은 좋은 것을 너무 많이 가질 수 없습니다, 그렇죠?

안타깝게도 이러한 논리는 몇 가지 상황에서는 효과가 있지만, 규모가 커지면 금방 무너지는 경우가 있습니다. 어떤 경우에는 수익이 감소하기 시작합니다. 13번째 초콜릿 케이크 한 조각이 실제로 얼마나 더 큰 가치나 기쁨을 가져다줄까요? 그리고 좋은 것을 너무 많이 추가하는 것이 개인이나 조직에 심각한 위험 요소가 될 수 있는 경우도 있습니다.

사이버 보안 도구가 너무 많습니다.

최근 몇 년 동안 대부분의 조직에서 통제 불능 상태에 빠진 사이버 보안 도구는 좋은 것이 너무 많으면 나쁜 것이 될 수 있는 중요한 영역입니다. 다크 리딩의 한 연구에 따르면 대부분의 최고 정보 보안 책임자는 네트워크를 보호하기 위해 평균 55~75개의 서로 다른 보안 제품 또는 애플리케이션에 의존하고 있는 것으로 나타났습니다. 그럼에도 불구하고 공격은 여전히 계속되고 있습니다. Verizon 2023 데이터 유출 조사 보고서에 따르면 성공적인 공격이 증가하고 있으며, 그 중 가장 복잡한 공격은 탐지하는 데 그 어느 때보다 오랜 시간이 걸리고 있습니다.

공격자는 어떻게 표면에있는 것처럼 보이는 75 개 이상의 사이버 보안 도구의 불가능한 건틀릿을 우회 할 수 있습니까? 사실 그들은 종종 여행 경보를하지만, 인간 수비수들은 방어 도구를 유지하거나 수천 개의 일일 경보에 응답하여 통지하기에는 너무 바쁩니다. 많은 보안 도구를 사용하면 실제로 공격자가 탐지되지 않은 상태로 유지하는 데 필요한 커버를 제공 할 수 있습니다.

TechRadar의 최근 보고서는 너무 많은 사이버 보안 도구를 사용하는 부정적인 결과를 강조했습니다. 설문 조사에 참여한 기업 중 71 %는 사이버 보안 팀이 성공적으로 관리 할 수있는 것보다 더 많은 도구가 있다고 느꼈습니다. 이로 인해 실제로 더 많은 도구가 추가됨에 따라 보안 태세가 악화되었습니다. 사실, 더 많은 도구가 더 많은 보안과 동일하다는 믿음과는 달리, 설문 조사에 참여한 사람들의 압도적 인 대다수는 환경 전체에 설치된 모든 사이버 보안 도구 때문에 훨씬 덜 안전하다고 느낀다고보고했습니다.

대부분의 조직에서 클라우드로의 대규모 이동으로 상황은 더욱 악화되었습니다. 가능한 모든 공격 경로를 다루기 위해 많은 사이버 보안 도구를 네트워크에 계층화하는 것이 인기를 얻은 이유 중 하나는 거의 전적으로 온프레미스 자산의 시대에 전략이 효과가 있었기 때문입니다. 또는 적어도 조직은 수익이 감소하고 부정적인 결과가 너무 빨리 발생하지 않았습니다. 그러나 클라우드 환경에서는 더 많은 도구를 추가할수록 더 많은 복잡성과 취약성이 발생합니다.

겹치는 도구를 유지 관리하는 작업 외에도 도구 중심 접근 방식의 또 다른 큰 문제는 더 많은 도구가 온라인 상태가 될 때 확실히 발생할 오탐의 바다입니다. 거짓 긍정을 쫓는 것은 조직에 실질적인 이익이되지 않기 위해 인적 보안 요원으로부터 항상 멀어질 수 있습니다. 그리고 그 사이에, 진짜 공격은 모든 거짓 경보 안에 쉽게 숨길 수 있습니다. 사이버 보안 전문가는 너무 늦을 때까지 실제 위협을 찾지 못할 수도 있습니다.

더 나은 방법

환경에서 모든 보안 도구를 제거하는 것은 재앙입니다. 그러나 당신은 또한 정말로 도움이 될 수있는 핵심 도구가 충분한주의를 기울이지 않을 정도로 많은 것을 갖고 싶지 않습니다. 올바른 도구 선택을 찾고 시간과 자원을 너무 많이 낭비하지 않도록하는 것이 중요합니다.

도구 통합 작업을 수행하는 핵심은 보안에 대한 인간 주도의 접근 방식에 동시에 투자하는 것입니다. 여기에는 전통적으로 해당 역할에 배포되지 않은 자산, 즉 공격자가 목표로 삼는 바로 그 앱과 소프트웨어를 코딩하는 임무를 맡은 개발자 팀을 사용하는 것이 포함되어야 합니다.

개발자는 전통적으로 보안 업무를 맡지 않았지만 이는 변화하고 있습니다. 실제로 개발자가 보안에 집중하도록 장려하는 것은 모든 사람이 보안 응용 프로그램 배포에 대한 책임을 지는 DevSecOps 운동의 핵심 측면입니다. 개발자가 갑자기 보안 전문가가 되거나 조직의 보안에 대한 주요 책임을 질 것으로 기대하는 사람은 아무도 없지만, 보안 코드를 작성하는 방법을 가르치고 잘 수행된 작업에 대해 보상을 주는 것은 겹치는 모든 보안 도구를 제거할 수 있는 무대를 마련하는 데 큰 도움이 될 수 있습니다.

좋은 보안 코드로 시작하면 일반적인 악용 및 취약성을 검색하도록 설계된 수백 가지 사이버 보안 도구 중 일부를 쉽게 제거 할 수 있습니다. 결국 개발자가 보안 코드를 만드는 환경을 조성하게 될 것이며, 몇 가지 선택된 사이버 보안 도구는 보안 팀이 너무 많은 좋은 일로 과부하되지 않고 쉽게 모니터링하고 유지 관리 할 수있는 추가 검사 역할을 할 수 있습니다.

사이버 공격은 의심의 여지없이 증가하고 있습니다. Verizon 2021 데이터 유출 조사 보고서에 따르면 오늘날 위협 환경은 그 어느 때보 다 위험 합니다. 모든 규모의 조직은 더 많은 양의 공격과 이를 표적으로 삼는 위협 행위자로부터 더 정교한 수준을 경험하고 있습니다. 그리고 공격자의 성공률도 급증하고 있습니다.

가장 최근의 공격을 분석하면 사이버 방어에 대한 전례없는 공격 중에 해커가 사용하는 가장 일반적인 취약점과 기술을 파악하는 데 도움이됩니다. 2021년 OWASP(Open Web Application Security Project)의 상위 10대 보안 위험 및 취약성을 만든 공격과 같이 가장 널리 사용되는 공격 중 일부는 자격 증명을 훔치거나 손상시키는 것과 관련이 있습니다. Akamai가 실시한 보안 조사에 따르면 , 압도적 다수인 75%가 API가 보유한 자격 증명을 직접 목표로 삼았습니다.

API의 부상과 가능한 파멸

대부분 API라고 불리는 애플리케이션 프로그래밍 인터페이스가 거의 모든 조직의 네트워크 내에서 증가하고 있다는 것은 놀라운 일이 아닙니다. 이는 대부분의 클라우드 기반 서비스의 중요한 구성 요소로, 대부분의 회사, 조직 및 정부 기관에서 온프레미스 자산의 기능을 빠르게 인계받고 있습니다. 요즘에는 클라우드 없이는 어떤 종류의 비즈니스 나 작업도 거의 실행할 수 없으며, 특히 공개적인 업무는 거의 없습니다. 즉, API는 확실히 모든 네트워크에서 꽤 많은 서비스를 함께 보유하는 접착제가 될 것입니다.

API의 놀라운 점은 네트워크 리소스 할당 측면에서 대부분 작고 눈에 거슬리지 않는다는 것입니다. 그리고 그들은 거의 모든 일을 수행 할 수 있도록 완전히 유연합니다. API의 핵심은 특정 프로그램을 제어하거나 관리하도록 맞춤화된 개별 소프트웨어입니다. 호스트 운영 체제, 응용 프로그램 또는 서비스의 데이터 액세스와 같은 매우 구체적인 기능을 수행하는 데 사용할 수 있습니다.

불행히도, 이것은 매우 동일한 유연성이며, 종종 작고 보안 팀에서 간과한다는 사실로 인해 API가 매력적인 대상이됩니다. 대부분의 API는 개발자가 완벽한 유연성을 제공하도록 설계되어 관리 중인 핵심 프로그램이 수정되거나 변경되더라도 계속 작동할 수 있습니다. 그리고 몇 가지 표준이 있습니다. 눈송이와 거의 마찬가지로 많은 API는 특정 네트워크의 단일 프로그램으로 특정 기능을 제공하도록 생성된다는 점에서 독특합니다. 보안을 잘 알지 못하거나 보안에 특별히 집중하지 않는 개발자가 코딩한 경우 공격자가 찾아서 악용할 수 있는 여러 가지 취약점 이 있을 수 있습니다.

슬프게도, 문제는 빨리 손에서 벗어나고 있습니다. Gartner에 따르면 2022년까지 API와 관련된 취약점은 모든 사이버 보안 범주에서 가장 빈번한 공격 벡터가 될 것입니다.

공격자가 API를 손상시키려는 주된 이유는 API가 수행하는 특정 기능을 인수할 수 있기 때문이 아니라 API와 관련된 자격 증명을 훔치기 위해서입니다. API의 가장 큰 문제점 중 하나는 취약점에 익숙할 뿐만 아니라 핵심 기능과 관련하여 종종 과도한 권한이 부여된다는 것입니다. 단순화를 위해 대부분의 API는 네트워크에서 거의 관리자 수준의 액세스 권한을 갖습니다. 공격자가 하나를 제어할 수 있는 경우 공격자가 해당 권한을 사용하여 네트워크에 더 깊고 실질적인 침입을 시작할 수 있습니다. 또한 API에는 공격자가 리디렉션하는 모든 작업을 수행할 수 있는 권한이 있기 때문에 API가 모든 영역 VIP 백스테이지 패스 덕분에 규칙을 위반하지 않기 때문에 해당 작업은 기존 사이버 보안 모니터링을 우회하는 경우가 많습니다.

조직이 조심하지 않으면 네트워크 및 클라우드 내에서 API가 증가하여 공격자의 표적이되는 경우에도 큰 문제가 발생할 수 있습니다.

API 방어

API의 상황이 위험해지는 만큼 절망적이지는 않습니다. DevSecOps와 같은 움직임을 통해 개발자가 보안을 더 잘 인식하도록 돕고 개발에서 테스트 및 배포에 이르기까지 소프트웨어 생성의 모든 측면에 보안 및 모범 사례를 도입하려는 노력이 많이 있습니다. 이 교육의 일부로 API 보안을 포함시키는 것은 2022년 이후까지 API 악용 추세를 극복하려는 모든 조직에 매우 중요합니다.

즉, API 보안 측면에서 지금 당장 구현할 수있는 몇 가지 좋은 모범 사례가 있습니다.

첫 번째는 모든 API에 대해 엄격한 ID 제어를 포함하는 것입니다. 사용 권한을 할당 할 때 거의 인간 사용자와 같다고 생각해야합니다. API는 특정 기능만 수행하도록 설계되었기 때문에 공격자가 API를 손상시킬 수 있는 경우 발생할 수 있는 상황에 대해 생각해야 합니다. 역할 기반 액세스 제어 사용을 고려하십시오. 이상적으로는 궁극적으로 API와 사용자에게 제로 트러스트 원칙을 적용해야하지만 이는 종종 먼 길입니다. 좋은 ID 관리는 시작하기에 좋은 곳입니다. 해당 프로그램의 일부로 API를 포함시켜야합니다.

또한 API에서 수행하는 다양한 호출을 가능한 한 엄격하게 제어해야 합니다. 이러한 호출을 매우 컨텍스트 중심의 요청으로 제한하면 공격자가 악의적 인 목적으로 수정하기가 훨씬 더 어려워집니다. 초기 API가 무엇을 찾아야하는지, 무엇을 무시해야 하는지를 정확히 알고 있는 다른 API에 대해 매우 상황에 맞는 호출을 수행하여 API를 계층화할 수도 있습니다. 이는 위협 행위자가 해당 체인 내에서 API를 악용하고 손상시킬 수 있는 경우에도 위협 행위자가 사용할 수 있는 기능을 제한하는 효과적인 방법이 될 수 있습니다.

API에 대해 평준화되는 위협은 확실히 압도적 인 것처럼 보일 수 있습니다. 그러나 보안 챔피언이 된 개발자를 지원하고 보람있게 만드는 모범 사례를 구현함으로써 상황은 훨씬 덜 절망적 인 것처럼 보일 수 있습니다. 좋은 훈련과 실습을 통해 공격자가 작지만 필수적인 API 작업마 중 하나를 어떻게 든 손상시켜야하더라도 공격자가 기동 할 여지가 거의 없도록 강력한 보안 프로그램을 수립 할 수 있습니다.

마지막으로 도로 여행을 한 때는 언제였습니까? 당신이 세상에 어디에 있는지에 따라, 그것은 단지 의제에 최근 반환 될 수 있습니다,하지만 정말, 아무것도 열린 도로보다 더 나은 풍경의 변화를 받고. 

물론 소프트웨어 취약점이 아니라면.

우리는 테슬라와 지프가 이미 보안 연구원들과 협력하여 조기에 발견되지 않으면 심각한 안전 문제로 이어질 수있는 악용 가능한 버그를 찾는 등 자동차 업계의 느슨한 사이버 보안 조치로 인한 위험에 대해 긴 이야기를 했습니다. 우리는 또한 어떻게, 일반적으로, 소프트웨어 보안은 와일드 웨스트에 여전히 방법에 대해 이야기했습니다. 소프트웨어는 우리가 돌아서고, 많은 연결된 장치, 차량 및 주변 기기의 경우 최종 사용자 교육과 경계를 넘어 필요한 보안 조치가 잘 어울립니다.

API 취약점은 특히 교활해지고 있으며, 지난 6개월 동안만 악의적인 API 트래픽이 300% 이상 증가했습니다. 현대 차량이 본질적으로 바퀴에 API라는 점을 감안할 때 이것은 오히려 우려됩니다. 그들은 연결, 다른 응용 프로그램과 매우 수다, 그리고 많은 취약 한 끝점 중 하나로서 대상 공격에 잡힐 수 있습니다. 

EV 충전기가 너무 많이 말하는 경우

커넥티드 차량은 소프트웨어 안전에 대한 조사를 받고 있지만 액세서리는 어떻습니까? 펜 테스트 파트너스의 천재 승무원은 6 개의 가정용 전기 자동차 충전 브랜드뿐만 아니라 광범위한 공공 EV 충전 네트워크에서 여러 코드 수준의 취약점을 발견했습니다.

누가 충전기에 관심이 있습니까? 공격자가 무엇을 얻을 수 있습니까? 불행하게도, 우리를 위해 초과 근무를 일하는 강력하고 깊은 기술의 단점 중 하나는 일반적으로 이러한 장치가 TMI의 나쁜 경우가 있다는 것입니다. EV 충전기는 API를 통해, 클라우드 기반 환경에서 동반 모바일 앱과 통신하며, 이 모든 것이 안전하게 코딩되고 구성되지 않으면 악용에 취약할 수 있습니다. API는 의도적으로 앱 간의 통신을 위한 수문을 열고 이러한 끝점이 신중하게 구성되지 않으면 취약한 앱 백도어를 통해 너무 많이 공유하거나 더 나빠질 수 있습니다.

Pen Test Partners는 수백만 대의 EV 충전기가 납치될 수 있는 매우 위험한 취약점, 계정 인수 및 원격 제어/계정에 대한 액세스를 허용한 API 권한 부여 문제 의 여러 사례, 여러 EV 장치의 동기화된 제어를 통해 전력망을 방해할 가능성도 발견했습니다. 이러한 문제는 모두 패치되었지만 공격자 간에 몇 줄의 코드가 있고 핵심 기능과 서비스 인프라가 완전히 중단되었다는 사실은 매우 중요합니다. 

그것은 마스터 물건처럼 아니에요, 어느. 예를 들어 Wallbox는 API에 두 개의 안전하지 않은 직접 개체 참조(IDOR)가 있었는데, 이 참조가 악용될 경우 계정 인수를 허용했습니다. IDOR는 OWASP 상위 10개 API 취약점에서2위에 속하는 깨진 인증에 속합니다. 그것은 품질 코드의 학습 및 구현에 실패를 가리키는 먼지만큼 일반적입니다. 우리는 버그 통신 경로의 무수한을 통해 민감한 장치와 응용 프로그램을 연결으로 지속 할 수 없습니다, 제대로 구성된 API는 단지입니다. 

자동차 API로 안전하게 작업하면 교육과 인내심이 필요합니다.

API 보안의 실망스러운 점은 사이버 보안 재해의 새로운 물결로 선전되어 실제로 웹 개발에서 수십 년 동안 보았던 것과 동일한 오래된 문제에 대한 새로운 설정일 뿐이라는 것입니다. 크로스 사이트 스크립팅, 주입, 잘못된 구성 : 익숙한 소리?

NIST와 같은 조직의 최근 지표는 유망하며 소프트웨어 보안이 더욱 규제되고 표준화되고 있음을 보여줍니다. 그러나, 우리는 여전히 매일 작성되는 코드의 홍수에 발생 해야 하는 보호의 양에 흠집을 넣어 필요한 전문가 부족. 개발자는 보안 지식과 책임에 대해 높아져야 하며 주도권을 잡기 위해 개발자가 아닙니다. 가전 제품에 임베디드 시스템을 작업하는 팀이 나 자동차를 다른 사람의 원격 제어 장난감으로 바꿀 수 있는 API가 있다면 일반적인 취약점 을 도입하는 것을 중단하는 데 필요한 것을 갖추고 있는지 확인해야 합니다. 

예를 들어 XSS로 인해 보안 API와 취약한 API 간의 차이는 미미하지만 개발자는 잘못된 코딩 패턴을 좋은 것과 구별하는 뉘앙스를 보여줘야 합니다. 그 외에도, 게으른 개발 프로세스는 종종 API 구성에서 평소와 같이 비즈니스, 많은 주어진 광대 한 권한과 함께 설정 된 작업을 수행하기 위해 최소 요구 사항 이상, 따라서 너무 많은 추가 위협 표면 및 잠재적인 데이터 도난을 열어. 이러한 요소는 빌드 중에 고려해야 하지만 허용 가능한 개발 관행에 배어지지 않으면 프로세스는 계속해서 위험 요소가 될 것입니다.

새로운 위협 배우 놀이터 를 피하기

위협 배우의 대상으로 API의 극적인 증가는 주의가 인식 낮은 매달려 과일로 이동하는 것을 보여줍니다 ... 그리고이 경우, 잠재적 인 차량 인수의 형태로 생명에 잠재적 인 위협뿐만 아니라, 상당한 급여에 파이프 라인이 될 수있는 하나입니다. 

API 보안을 우연히 만드십시오. 소프트웨어의 통신 생태계의 일부로 중요한 고려 사항이되어야하며 동급 최강의 보안 프로그램 목록에서 높은 수준이어야 합니다. 이 것의 핵심은 각 API를 인간처럼 취급하고 어떤 액세스 권한이 있어야 하는지 평가하는 것입니다. 회계에서 짐은 전체 회사에 대한 모든 민감한 법률 문서에 액세스 할 수 있어야합니까? 아마도, 일반적으로 액세스 제어는 실제 직원의 경우 올바르게 결정됩니다. API에 대해도 마찬가지이며, 다른 모든 것들의 동일한 제로 트러스트 방법으로 구성되지 않은 경우 모든 사람이 귀하의 비밀을 알 릴 수있는 강력한 채팅 상자임을 기억하는 것이 중요합니다.

조직은 높은 경고에 있어야 하며 개발자는 이러한 취약한 포털에서 절망에 이르는 양질의 코드를 만드는 데 필요한 눈입니다. 이 목표에 대한 올바른 사고 방식과 창조의 중요한 단계에서 올바른 결정을 내릴 수 있는 실습 기술을 통해 보안 인식 엔지니어로서 성장하고 번창할 수 있는 기회를 제공해야 할 때입니다.

이 문서의 버전은 포브스 기술 위원회의특징으로나타났다. 여기에 업데이트되고 신디케이트되었습니다.

‍

데이터 유출의 잘못된 편에 있는 것과 같은 것은 없습니다. 처음에는 부정, 공황이있을 수 있습니다. 모든 폭발물이 방영되고 CISO가 홍보와 함께 오전 2시 컨퍼런스 콜을 해야 하는 경우 소매를 걷어붙이고 엔드포인트, 시스템 확보 및 잠재적 공격 벡터를 신속하게 제거할 때입니다. 적어도 말하자면 피크닉은 아닙니다. 

그럼에도 불구하고 이것은 앞으로 많은 조직에서 시작될 현실이며 포괄적 인 사이버 보안 사고 대응 계획을 절대적으로 준비해야합니다. 그러나 문제는 이 사후 대응 전략이 사이버 공격의 잠재적 심각성을 예방하거나 줄이기 위해 노력하는 대신 많은 시간과 자원 및 노력이 집중되어 있다는 것입니다. 그것은 의심 심장 마비에 대 한 구급차를 호출 처럼 조금; 결과는 수시로 훨씬 덜 긍정적입니다 - 더 손상은 말할 것도 없고 - 너무 늦기 전에 예방 건강 조치가 효력이 있던 경우에 보다는. 

이를 위해 예방 계획은 어떤 모습일까요? 보안 프로가 매일 증가하는 사이버 위험을 완화하기 위해 모든 도구를 어떻게 사용할 수 있는지 살펴보겠습니다.

앞에 놓인 작업의 범위 이해 

분명해 보이지만 사이버 위험을 완화하는 "올바른" 계획은 산업 간에 미묘한 차이를 가지고 있으며 원하는 결과에 도달하기 위해 선행이 필요한 것을 이해하는 것이 중요합니다.

현재 어떤 보안 문제가 존재합니까? 그들은 몇 시간과 자원을 차지하고 있습니까? 그들 중 몇 개는 되풀이되는 문제입니까? 이러한 요소는 중요한 요소이며 기본 출발점을 제공합니다. 충전이 필요한 역할, 툴링의 간격 및 전문 지식과 도구 관점에서 필요한 역할을 고려하여 엔드포인트를 확보하고 공격 표면을 줄이는 동시에 잠재적 위험의 다른 영역을 선점합니다.

최근 보고서에 따르면 11개 산업은 지난 1년 동안 매일 애플리케이션의 절반 이상에 걸쳐 심각한 취약점을 보았습니다. 특히 유틸리티, 공공 행정 및 전문 서비스 산업은 알려진 취약점을 패치하는 데 평균 288 일이 걸렸습니다. 이는 매우 느리기 때문에 패치를 적용하기 전에 이러한 취약점이 발견되면 공격자에게 심각한 피해를 줄 수 있는 충분한 시간을 제공합니다. 이는 데이터 유출이 30%에 육박할확률과 함께 사고 반응이 충분하지 않다는 냉정한 신호이며, 대규모 사이버 공격의 영향에 대해 지분이 너무 높으면 최고의 사이버 공격이 발생할 수 있기를 바랍니다.

문화적 변화를 위한 바이인 준비

현상 유지를 흔들어 몇 눈썹을 제기하는 경향이 있지만, 진실은, 보안 프로그램은 지속적인 개선의 일정한 상태에 있어야합니다. 모든 구성 요소는 관련성을 유지해야 하며 새로운 개발을 평가하고 고려해야 합니다. 

예방에 중점을 두는 것은 사후 대응과는 달리 보안 팀 외부에서 는 접근 방식이 널리 이해되지 않을 수 있으며, 특히 크고 나쁜 보안 사고가 발생하지 않은 경우. 그것은 깨지지 않고 수정할 필요가 없는 것으로 보일 수 있습니다. 이 경우 임원 을 얻는 것이 필수적입니다. 그들이 고려해야 할 더 적절한 점 중 일부는 다음과 같습니다.

• 중요한 사고의 잠재적 비용과 는 달리 역할 기반 교육 및 관련 도구와 같은 예방 조치의 시간과 비용 절감 
• 취약점을 찾고 수정하는 방법은 보안 팀의 쇼스토퍼 수가 줄어들면서 제 시간에 릴리스를 유지하는 방법
• 개발 팀에서 출시까지 잠재적인 보안 위험을 준비하고 선점하는 이유는 전체적으로 더 많은 시간(중요한 현금은 말할 수 없음)을 절약합니다. 이를 관점으로 제시하기 위해 테스트 단계에서 발견된 후기 단계의 취약점(또는 더 나쁜 후 프로덕션)은 평균 3,000%의 비용을 증가시킬 수 있습니다.
  

제안된 문화적 변화는 처음에는 불편해 보일지라도 비즈니스 목표와 일치하는 것이 중요합니다. 

보안 인식은 무언가이며, 보안 기술은 모든 것입니다.

업계로서 우리는 보안 인식의 중요성에 대해 자주 이야기하며, 이는 조직의 모든 직원의 점점 더 중요한 구성 요소입니다. 그러나, 그것은 립 서비스 및 수동 훈련에서 중지 하는 충분 하지 않습니다., 특히 기술 적인 위치에 있는 사람들을 위해.

간단히 말해서 코드를 만지는 사람은 안전하게 코딩할 수 있는 기술이 갖추어져 있지 않은 경우 잠재적인 보안 위험입니다. 기본 보안 매개 변수에 대한 일반적인 인식은 좋은 시작이지만, 좋은, 안전한 코딩 패턴, 가난한 습관에 대한 맥락적 지식이 없는 것은 공격자가 더러운 작업을 수행하는 데 의존하는 품질 개발 기술의 부족입니다. 

개발자를 쓰지 마십시오.

태도가 변화하고 있지만, 많은 조직은 개발자가 보안 완화 계획에서 거의 진정한 고려사항이 아닌 방식으로 구성됩니다. 은행 및 금융과 같은 일부 산업은 엄격한 규정 준수 및 규제 요구 사항을 가지고 있으며, 이로 인해 모든 직원을 위해 전반적으로 보안 관행과 교육이 강화됩니다. 그리고 그들은 확실히 다른 수직 앞서 있는 동안, 지구에 거의 모든 조직 보안 인식 개발자의 사내 군대에서 혜택을 받을 수 있습니다., 그들은 최선을 다하고 전에 일반적인 보안 버그를 냄새 하는 기준 능력. 대부분은 보안 프로그램 퍼즐의이 중요한 조각을 달성 근처에 아무 데도 없다 - 우리는 이제까지 매년 볼륨 증가 코드의 홍수를 확보의 희망이있는 경우 필요합니다.

예방 보안은 손가락이 소프트웨어를 만들기 위해 키보드를 터치하는 순간을 시작해야하지만 개발자는 보안 기술 격차를 혼자 해소 할 것으로 예상 할 수 없습니다. 더 높은 수준의 코드 품질에 도달하기 위해서는 올바른 도구 집합과 컨텍스트 지침이 필요하며, 연간 규정 준수 요구 사항이 적용될 때마다 산발적으로 롤아웃되는 사후 고려가 아니라 일상 업무의 일부가 될 때 최상의 결과를 항상 얻을 수 있습니다.

이 문서의 버전은 테크 크런치에등장. 여기에 업데이트되고 신디케이트되었습니다.

‍

2021년에 는 이름을 지을 수 없는 한 해에 충분한 혼란을 겪었던 것처럼, 2021년은 기록상 최악의 데이터 유출 의 형태로 미국 정부에 대한 귀가 들리지 않는 강타로 시작되었습니다. 솔라윈즈 사건은 여러 정부 부처와 대규모 조직을 공포에 빠뜨리고 종점을 확보하기 위해 출격하는 파괴적이고 정교한 국가 국가 공격이었습니다. SolarWinds 소프트웨어의 거의 모든 최종 사용자가 손상되었으며, 이 사건으로 소프트웨어 공급망의 사이버 보안과 방어가 중요하다는 것을 분명히 했습니다.

사이버 보안이 중요하다는 것은 분명하지만 공급망의 맥락에서 실제로 무엇을 의미합니까?

평균 개발 팀의 사이버 보안 현황

매년 수십억 줄의 코드를 나타내는 엄청난 양의 소프트웨어가 매일 생산되고 있으며, 이는 점진적으로 디지털 라이프스타일에 의해 생성된 수요에 따라 증가하고 있습니다. 글로벌 개발자 인구는 2024년까지 거의 2,900만 명으로급증하고 있으며, 현재 는 안전하게 코딩할 수 있는 능력을 평가하고 인증할 수 있는 공식적인 인증이 존재하지 않습니다. 그렇다고 모든 개발자가 안전하지 않은 코드를 생성하거나 다시 사용하는 것은 아니지만, 의심할 여지 없이 기본적인 보안 약점이 당사의 데이터를 신뢰하는 소프트웨어에 도입될 수 있다는 지속적인 위험이 있습니다.

개발자는 가능한 한 빨리 기능 및 배송 코드를 만드는 능력에 대해 평가됩니다. 보안은 대부분의 조직에서 성공을 위한 벤치마크가 아니었지만, 소프트웨어 생성 초기에 공통 보안 버그를 방지하는 데 있어 더 많은 기업이 보유하고 있는 잠재력을 실현함에 따라 이러한 감정이 바뀌기 시작했습니다. 그러나 실현과 구현은 두 가지 이며, 대부분의 고등 개발 이후 courses 보안 코딩 관행에 대한 컨텍스트를 생략하는 것은 종종 부족을 만회하기 위해 개발자의 작업장까지 달려 있습니다. 기술 구축 및 지식 공유가 드물거나 관련이 없다면 효과가 없을 것입니다. 따라서 기술 개발 부족을 통해 반복되는 취약점의 주기는 끊어지지 않습니다. 

당연히, 세계의 사이버 보안 불황을 해결하는 것은 평균 소프트웨어 개발자의 책임이 아닙니다; 결국, 조직은 이유를 위해 매우 비싼 보안 전문가를 고용합니다. 그러나 보안 전문가는 공급이 부족하며 개발자는 확실히 부담을 줄이는 역할을 할 수 있습니다. 

그러나 파괴적인 사이버 공격을 방지하는 측면에서 중요한 인프라와 민감한 조직을 위한 소프트웨어를 만드는 공급업체와 공급업체는 어디에 있을까요? 최소한 소프트웨어 조달의 현상 유지에 변화가 필요할 것입니다.

보안 소프트웨어 공급망의 방해가 되는 함정

체인의 피곤한 속담은 가장 약한 링크만큼 강하기 만하면 불행히도 소프트웨어 공급에 관해서는 사실입니다. 회사가 보안 모범 사례를 강화하고 개발자 upskilling에 대한 투자, 기능적 DevSecOps 환경으로의 이동 (즉, 소프트웨어에 대한 책임을 공유하는 모든 사람 가능한 한 안전하게 만들어지는 경우)과 함께 파티에 왔는지 여부는 중요하지 않습니다. 보안 문제가 있는 공급업체의 소프트웨어를 사용하는 경우 해당 소프트웨어를 에코시스템에 상속하여 그 결과를 부담하게 됩니다.

물론 보안 팀은 기술 스택에 타사 추가의 안전을 평가하는 데 도움을 주어야 하지만 솔루션 중에서 선택의 여지가 없는 비즈니스 요구사항을 기반으로 결정을 내릴 수 있습니다. 이 시점에서 신뢰 운동이 될 수 있습니다. 공급업체가 회사만큼 이나 보안에 관심이 있습니까? 그리고 공급업체는 실제로 위험을 이해할 수 있는 위험과 보호하는 데 필요한 자산을 평가할 수 있습니까?

투명성은 공급업체 소프트웨어 추가의 보안 실행 가능성을 평가하는 데 중요한 요소입니다. 그들은 자신의 보안 관행을 선행하고있습니까? 그들은 데이터를 안전하게 유지하는 접근 방식에 자부심을 가져야하며, 이는 최우선 과제여야 합니다. 보안 관행이 아무 데도 게시되지 않거나 정보를 사용할 수 없는 경우 보안이 최상급으로 제공되지 않을 가능성이 큽분입니다. 공급업체는 기술적 질문에 답할 수 있어야 하며 ISO27001 및 SOC2와 같은 독립적인 인증도 해치지 않을 것입니다. 또한"후드 아래를 보고 자신의 내부 실사 및 보안 관행의 일환으로 취약점을 검사 할 수없는 경우 잊어 버리십시오.

특히 공급 업체 코드가 새로운 맥락에서 작업을 수행하기 위해 기존 시스템으로 접혀있는 경우 수요가 빠르게 진행되는 상황에서 공급 업체와 구매자 모두 게임의 맨 위에 있어야하며, 둘 다 개발자가 출시하기 전에 일반적인 보안 버그와 결함을 픽업하기 위해 지상의 부츠로 있어야합니다. 기술 솔루션의 기존 거미줄에 새로 추가하면 수백 또는 수천 개의 종속성이 손상될 수 있으며, 하나의 작은 실패가 치명적인 취소로 이어질 수 있습니다.

그렇다면 해결책은 무엇일까요? 처음부터 사내 모든 것을 코딩? 1998년이라면, 그것은 의미가 있을 것입니다. 그러나 가장 가까운 세차장인 "Jeeves에게 물어보세요"가 더 이상 없는 것처럼 오늘날의 맥락에서 작동하는 현실적인 안전 장치를 구현해야 합니다.

아직 은색 총알은 없지만 해결책이 있습니다.

구매자의 경우 보안 assessment 공급업체 소프트웨어 및 개발 관행의 우선 순위는 전체 보안 프로그램 및 위험 완화 계획의 우선 순위가 되어야 합니다. 개발자의 인증, 관행 및 보안 평판에 대해 질문하십시오.

공급업체(그리고 실제로 소프트웨어를 만드는 모든 회사)는 보안이 최우선이며 업스킬링에 집중해야 한다는 것을 입증할 준비가 되어 있어야 합니다. 보안 숙련도 개발자는 수요가 많으며 올바른 도구와 지원을통해 기존 팀에서 구축하고 일반적인 취약점으로 인한 공격을 방어할 수 있습니다. 그러나 그들에게 오래된 훈련을 던지지 마십시오. 기존 워크플로우와 보완적인 보안 툴링으로 번창할 시간을 제공합니다. 가능한 한 쉽게 만들고, 그 성가신 버그가 비즈니스에 전력을 공급하는 코드 사이에서 얇아질 것을 지켜보십시오.

결론은 공급망의 일부인 경우 소프트웨어 위험이 즉시 악화되어 모든 사용자와 취약한 구성 요소가 활용된 시스템에 영향을 미친다는 것입니다. 공급업체가 소프트웨어를 구현하는 회사또는 공급업체와 조직이 모두 보안 프로그램에 부족한 만큼 보안에 대해 심각하지 않다면 SolarWinds와 같은 광범위한 공급망 공격이 불가피하게 표준이 될 것이며 이는 모두에게 중요한 문제입니다.

소프트웨어 개발 외부에서 일하는 모든 사람에게 는 직관적이지 않은 것처럼 보일 수 있지만, 수년에 걸쳐 응용 프로그램 보안에 고용된 많은 전문가들이 프로그래밍 경험이 거의 또는 전혀 없는 중요한 역할을 수행했습니다. 이러한 AppSec 전문가는 많은 산업 및 조직의 생명선이 된 응용 프로그램에 취약점이 들어가지 않도록 하는 팀의 일원이지만 실제로 코드 자체를 직접 평가하거나 수정할 수 있는 사람은 거의 없습니다. 

많은 보안 전문가는 코딩 배경에서 오는 대신 공격 벡터, 위협, 악용 및 비즈니스 위험에 대한 핵심 지식의 관점에서 자신의 역할에 접근합니다. 코드의 제한된 보기가 있습니다. 모든 AppSec 전문가가 동일한 기술을 가지고 있는 것은 아니지만, 많은 사람들이 조직 표준또는 관련 산업 및 정부 프레임워크에 따라 프로그램 및 시스템을 보호할 수 있도록 코드 검토자 및 스캔 도구와 협력하는 일반적인 날입니다. 그런 다음 결과에 대한 보고서를 작성하고 코드를 위반할 수 있는 공격 벡터에 대한 정보를 다시 보냅니다. 그런 다음 개발자가 현재 작업에 얼마나 파괴적이더라도 필요한 수정을 해야 합니다.

이러한 상황이 이런 식으로 발전한 이유는 지난 몇 년 동안 지배적인 논리가 네트워크와 응용 프로그램을 보호하는 작업이 너무 광범위했기 때문에 사이버 보안 분야에서 일하는 모든 사람들이 모든 역할을 수행할 것으로 기대하는 것은 의미가 없었기 때문입니다. 딥 코딩 기술은 개발자에게 맡졌으며 개발 파이프라인 아래로 코드를 더 멀리 쓰거나 편집할 수 있는 능력에는 거의 가치가 없습니다.

이러한 사고 방식은 빠르게 변화하고 있으며, 이는 개발자가 AppSec로 수익성 있는 점프와 커리어 전환을 할 수 있는 특별한 기회를 제공합니다. 모든 개발자가 소위 어두운 면을 포용하기를 원하지 는 않으며 많은 개발자가 AppSec 팀에 대한 의견에 특별히 긍정적이지 않습니다. 그러나 그렇게하는 사람들을 위해, 점점 더 유혹 황동 반지를 잡을 수있는 더 나은 시간이 없었다.

DevSecOps는 거의 모든 산업을 구동

모든 조직에서 보안 인식 프로그래머와 개발자의 가치를 높이는 가장 큰 요인 중 하나는 DevSecOps와 같은보다 민첩한 개발 관행을 수용하려는 거의 보편적인 움직임입니다. 개발, 보안 및 운영이 결합되면 사이버 보안은 처음부터 끝까지 새로운 소프트웨어 개발에 통합된 공동 책임이 됩니다. 이러한 환경에서 코딩 기능은 전반적으로 점점 더 귀중한 자산으로 여겨지고 있으며, 이는 보안을 본질적으로 이해하는 엔지니어에게 특히 그렇습니다.

높은 수준에서 사이버 보안을 이해할 뿐만 아니라 모든 것을 작동하게 하는 코드도 이론적으로 지식이 집중된 사람보다 모든 조직에 본질적으로 더 가치가 있는 AppSec 전문가가 말합니다. 코드 내에서 발견된 취약점을 신속하게 검색및 평가한 다음 이러한 문제를 완화할 수 있는 것이 DevSecOps가 이러한 인기를 보는 이유의 핵심입니다.

AppSec에서 일하는 개발자는 또한 그들을 고용하는 모든 조직에 또 다른 큰 이점을 가져다. 집의 개발 측면에서 오는 그들은 쉽게 보안 및 취약점에 대해 개발자와 이야기 할 수 있습니다. 또한 개발 팀의 코치가 되는 것이 훨씬 쉬워서 더 나은 코더가 될 수 있도록 도와줍니다. 시간이 지남에 따라 AppSec에서 "어두운 면"낙인을 제거하고 조직 전체의 소프트웨어 개발 내에서 팀을 통합하는 데 도움이 될 수도 있습니다.

사이버 보안 기술 부족이 악화되고 있습니다.

셰익스피어는 아무도 좋은 불지 않는 아픈 바람이라고 말했습니다. 그가 의미하는 바는 가장 어두운 상황조차도 누군가에게 유익을 가져다 주는 것이었다. 사이버 보안 기술 부족은 이것의 좋은 예입니다.

인력 부족은 거의 모든 곳에서 심각하게 느껴지고 있습니다. 전략 국제학 센터가 최근 실시한 설문조사에서 IT 의사 결정자의 82%는 조직이 사이버 보안 기술 부족으로 어려움을 겪고 있다고 답했으며, 71%는 부족으로 인해 조직에 직접적이고 측정 가능한 손상을 입었다고 답했습니다. 보고서는 이 위기를 더 나은 시각으로 제시하기 위해 미국에서만 2020년에 는 약 94만 개의 사이버 보안 일자리가 고용된 분야에 대해 52만 개 이상의 미충전 사이버 보안 일자리가 있었다고 지적했다.

사이버 보안 인력 부족은 점점 더 위험한 위협 환경에서 인프라, 비즈니스 및 데이터를 보호하려는 조직에 나쁜 소식입니다. 그러나 AppSec 및 보안에 들어가려는 개발자에게 좋은 기회를 만듭니다. 사이버 보안 및 AppSec 위치는 거의 모든 곳에서 사용할 수 있습니다. 그리고 사이버 보안 포지션이 요즘 평균 21% 더 많은 시간을 보내고 있는 가운데, 급여는 전반적으로 증가하고 있습니다.

AppSec로 점프하기

개발자가 삶의 햇볕이 잘 드는 보안 측면으로 수익성 있는 점프를 할 수 있는 더 좋은 시기는 없을 것입니다. 보안 인식 개발자는 더 이상 스톱갭 보안 방법의 일부로 간주되지 않고 사이버 보안 수비수로서 완전하고 존경받는 역할을 작성하고 있습니다. DevSecOps 및 기타 민첩한 개발 방법론을 수용한 조직에 특히 그렇습니다. 그리고 사이버 보안 인재 부족은 거의 모든 회사, 정부 기관 또는 조직에서 직책을 사용할 수 있음을 의미합니다. 올바른 기술을 가진 사람들은 일하고 싶은 곳을 선택하고 선택할 수 있습니다.

AppSec로 이동하는 것은 모든 사람을위한 것이 아닐 수도 있으며, 물론 대부분의 개발자는 놀라운 기능을 구축하는 데 집중할 것입니다. 그러나 점프를 고려하는 사람들을 위해, 기존의 코딩 기술을 강화하기 위해 보안 교육에 투자하면 많은 문을 열 수 있습니다. 최고의 AppSec 사람들은 기술을 깊이 이해하고 동료 개발자의 곤경에 대한 공감을 가지고 있기 때문에 엔지니어링에서 나옵니다. DevSecOps는 모든 사람이 어쨌든 보안에 대한 책임이 있다는 것을 의미하므로 현재의 중요한 기술 부족을 활용하여 응용 프로그램 보안으로 경력을 발전시키지 않겠습니까? 자신과 가족, 그리고 경력을 위해 긍정적인 행동을 할 수 있는 더 좋은 시기는 없었습니다.

불량 AI와 로봇에 대한 대중 문화 참조가 많이 있으며, 가전 제품이 인간 주인을 켜고 있습니다. 공상 과학 소설의 재미와 환상에 크게 가득차 있지만 IoT와 연결된 장치가 가정에서 더 널리 퍼지기 때문에 사이버 보안및 안전에 관한 대화도 마찬가지입니다. 소프트웨어는 우리 주변에 있으며, 우리에게 많은 혁신과 편의를 제공하는 모든 영리한 일을 하기 위해 코드 라인에 얼마나 의존하고 있는지 잊어 버리는 것은 매우 쉽습니다. 웹 기반 소프트웨어, API 및 모바일 장치와 마찬가지로 공격자가 야생에서 발견되면 임베디드 시스템의 취약한 코드를 악용할 수 있습니다. 

마이크로파 군대가 사이버 공격의 결과로 인류를 노예로 만드는 것은 불가능하지만(테슬라 봇은 약간 우려스런) 악의적인 사이버 이벤트가 여전히 가능합니다. 일부 자동차, 비행기 및 의료 기기는 복잡한 임베디드 시스템 코드에 의존하여 주요 작업을 수행하며 이러한 물체가 손상될 가능성은 놀라운 것일 뿐만 아니라 잠재적으로 생명을 위협할 수 있습니다.

다른 모든 유형의 소프트웨어와 마찬가지로 개발자는 생성 단계 의 시작 부분에서 코드를 가장 먼저 만질 수 있습니다. 그리고 다른 모든 유형의 소프트웨어와 마찬가지로, 이것은 제품이 생방송되기 전에 들키지 않을 수 있는 교활하고 일반적인 취약점의 번식지가 될 수 있습니다. 

개발자는 보안 전문가가 아니며, 어떤 회사도 그 역할을 할 것으로 예상해서는 안되지만, 자신과 관련된 위협을 해결하기 위해 훨씬 더 강력한 무기를 장착할 수 있습니다. 일반적으로 C 및 C++로 작성된 임베디드 시스템은 기술 요구가 계속 진화함에 따라 더 자주 사용되며 이 환경에서 는 개발자를 위한 특수 보안 교육이 필수적입니다. 

폭발 공기 튀김, 불량 차량 ... 우리는 오리를 앉아 있습니까?

안전을 위해 모든 보안 개발에 대한 몇 가지 표준 및 규정이 있지만 모든 유형의 소프트웨어 보안을 위해 훨씬 더 정확하고 의미 있는 진전을 만들어야 합니다. 누군가가 에어 프라이어를 해킹하여 발생할 수있는 문제를 생각하기가 훨씬 멀어 보일 수 있지만 원격 코드 실행 공격 (위협 배우가 위험한 수준으로 온도를 올릴 수 있도록)의 형태로 일어났습니다.

특히 차량은 특히 복잡하며, 여러 개의 임베디드 시스템이 탑재되어 있으며, 각각 마이크로 기능을 담당합니다. 자동 와이퍼에서 엔진 및 제동 기능에 이르기까지 모든 것을 제공합니다. WI-Fi, Bluetooth 및 GPS와 같은 통신 기술의 스택과 얽혀 있는 커넥티드 차량은 여러 공격 벡터에 노출된 복잡한 디지털 인프라를 나타냅니다. 그리고 2023년까지 전 세계적으로 7,630만 대의 커넥티드 차량이 도로를 강타할 것으로 예상되는데, 이는 진정한 안전을 위해 마련될 방어 기반의 모놀리스를 나타냅니다.

MISRA는 임베디드 시스템의 맥락에서 코드 안전, 보안, 휴대성 및 신뢰성을 용이하게 하기 위한 지침을 개발한 임베디드 시스템 위협에 맞서 싸우는 핵심 조직입니다. 이 지침은 모든 회사가 임베디드 시스템 프로젝트에서 노력해야 하는 표준의 북스타입니다.

그러나 이 골드 표준을 준수하는 코드를 만들고 실행하려면 도구에서 보안 인식은 물론 자신있는 임베디드 시스템 엔지니어가 필요합니다. 

임베디드 시스템 보안 업스킬링이 그렇게 구체적인 이유는 무엇입니까?

C 와 C ++ 프로그래밍 언어는 오늘날의 표준에 의해 노인이지만 널리 사용되고 있습니다. 임베디드 시스템 코드베이스의 작동 코어를 형성하며 임베디드 C/C++는 연결된 장치 세계의 일부로 반짝이는 현대 생활을 즐깁니다.

이러한 언어는 오히려 고대의 뿌리를 가지고 있음에도 불구하고 - 사출 결함 및 버퍼 오버플로와 같은 일반적인 문제면에서 유사한 취약점 동작을 표시 - 개발자가 임베디드 시스템에서 보안 버그를 완화하는 데 진정으로 성공을 거두기 위해, 그들은 그들이 작업 하는 환경을 모방 하는 코드와 실습을 얻을 해야 합니다. 일반 보안 관행에서 일반 C 교육은 단순히 여분의 시간과 관리가 임베디드 C 컨텍스트에서 작업하는 것처럼 강력하고 기억에 남는되지 않습니다.

현대 차량에 12개에서 100개 이상의 임베디드 시스템을 갖춘 개발자는 IDE에서 찾아야 할 사항과 이를 해결하는 방법에 대한 정밀 교육을 받아야 합니다.
‍

1층에서 임베디드 시스템을 보호하는 것은 모든 사람의 책임입니다.

많은 조직에서 현상 유지는 개발 속도가 적어도 개발자의 책임에 관해서는 보안을 능가한다는 것입니다. 안전한 코드를 생성하는 능력에 대해 거의 평가되지 않지만 멋진 기능의 빠른 개발은 금본위제입니다. 소프트웨어에 대한 수요는 증가할 뿐이지만, 이것은 취약점과의 전쟁에서 패배한 문화와 그들이 허용하는 후속 사이버 공격에 대비한 문화입니다. 

개발자가 교육을 받지 않은 경우, 그것은 그들의 잘못이 아니며 AppSec 팀의 누군가가 전체 개발 커뮤니티에 대한 upskilling 프로그램을 사용할 수 있는 권리(평가 가능한) 프로그램을 추천하여 채우는 데 도움을 줄 필요가 있는 구멍입니다. 소프트웨어 개발 프로젝트의 시작 부분에서 보안은 모든 사람, 특히 개발자가 자신의 역할을 수행해야 하는 것을 감안할 때 가장 중요한 고려 사항이 되어야 합니다. 

임베디드 시스템 보안 문제로 실습

버퍼 오버플로, 사출 결함 및 비즈니스 논리 버그는 모두 임베디드 시스템 개발의 일반적인 함정입니다. 단일 차량이나 장치에 마이크로 컨트롤러의 미로에 깊이 묻혀있을 때, 그것은 보안 관점에서 재앙을 철자 할 수 있습니다.

버퍼 오버플로는 특히 널리 퍼져 있으며, 이전에 우리가 이전에 이야기한 에어 프라이어 (원격 코드 실행 허용)를 어떻게 손상시키는지 에 대해 자세히 알아가고 싶다면 CVE-2020-28592에 대한이 보고서를 확인하십시오.

이제 버퍼 오버플로 취약점을 실제 임베디드 C/C++ 코드에서 실습할 시간입니다. 이 문제를 재생하여 이 교활한 버그로 이어지는 잘못된 코딩 패턴을 찾고, 식별하고, 수정할 수 있는지 확인합니다.
‍

‍

어떻게 하셨나요? 임베디드 시스템 보안에 대한 정밀하고 효과적인 교육을 위해 www.securecodewarrior.com 방문하십시오.

응용 프로그램 보안 전문가로서 조직의 응용 프로그램의 사이버 안전을 보장하는 것이 귀하의 임무입니다. 그러나 응용 프로그램에서 실행되는 코드를 작성할 책임은 없습니다. 개발 팀 내의 엔지니어는 다음과 같습니다. 그렇다면 보안을 염두에 두고 이러한 시스템을 개발하고 있는지 어떻게 해야 할까요? 

대부분의 경우 다음 중 일부 또는 전부를 수행할 수 있습니다. 

• 보안 결함에 대한 모든 코드를 검토하고 이를 개발 팀에 다시 보고하여 수정합니다. 
• 보안 개발 수명 주기 전반에 걸쳐 엄격한 동료 검토 프로세스를 적용합니다. 
• 정기적인 응용 프로그램 assessment /내부 또는 외부 보안 팀에 의해 수행 되는 침투 테스트.
• 취약점을 포착하기 위해 검색 도구를 구현합니다.
  

이들은 훌륭한 모범 사례입니다, 그러나 그(것)들은 또한 비싸고 당신이 아프게 될 때마다 항생제의 라운드를 취하는 것과 유사합니다. 뿐만 아니라 높은 비용으로 제공 합니까, 그것은 효능을 잃고 시간이 지남에 따라 면역 체계를 약화시킬 수 있습니다. 

개발자가 제공하는 코드를 처음부터 안전하게 작성하려면 어떻게 해야 합니까? 

보안을 통해 코딩을 통해 사람들이 배우는 방법을 먼저 생각해 보십시오. 우리 대부분은 시각 학습자이며, 우리는 일을 통해 배운다. 그러나 보안 코드 교육은 종종 '체크 더 박스' 활동으로 제공되며 개발자의 일상 업무와 는 관련이 없습니다. 개발자가 업계 표준을 준수하기 위해 보안 교육을 자주 받았으며 개발자가 학습 과정을 즐기는 것은 물론 실제로 이러한 지식을 보유하는 것이 아니라 보안 교육을 받았다는 것을 증명하기 위해 고안되었습니다. 

인간이 배우는 경향이 있는 또 다른 방법은 우리의 면역 계통이 하는 것과 같은 방식으로 우리의 실수를 통해입니다. T 세포는 그들이 과거에 발생하고 성공적으로 근절 한 병원균의 종류를 기억, 그래서 그들은 미래에 그들에 대해 보호 할 수 있습니다. 이것은 개발자가 보안 SDLC에서 수행해야 하는 역할입니다.

실수를 하지 않기를 기대하는 것은 비현실적이지만, 향후 보안 취약점으로 이어질 코딩 패턴을 인식할 수 있는 방식으로 준비할 수 있습니다. 

이는 강력한 피어 검토 프로세스가 매우 강력해지는 방식이기도 합니다. 한 개발자가 보안 결함을 알아차리지 못한다고 해서 다른 개발자가 그렇지 않다는 의미는 아닙니다. 그리고 개발 팀이 전반적으로 더 잘 훈련될수록 더 많은 취약점이 트랙에 걸려 생산되지 않을 것입니다. 

소프트웨어 취약점은 병원균과 같습니다.

소프트웨어 취약점은 병원균과 같아서 그들과 싸우기 위해 이를 기억해야 한다는 의미입니다. 병원균으로, 우리의 면역 계통은 가혹한 질병 또는 더 나쁜 피하기 위하여 그것을 싸우는 방법을 기억하기 전에 수시로 여러 번 드러워야 합니다. 

취약한 소프트웨어의 성공적인 사이버 공격은 조직을 심각하게 무력화하거나 죽일 수 있습니다. 그러나 개발자가 제어된 환경에서 먼저 소프트웨어 취약점을 도입하는 경우 보안 코딩 지식과 기술을 늘리고 정기적으로 연습하여 위협에 대한 면역을 구축하기 위해 노력할 수 있습니다. 

제어된 환경에서 개발자를 보안 결함에 노출

우리는 아프지 않도록 완전히 보호할 수는 없지만 면역 체계를 강화하고 가능한 한 건강하게 유지하기 위해 할 수 있는 일들이 있습니다. 규칙적인 운동, 건강한 식사 및 충분한 수면과 같은 것들은 일반적으로 강한 면역 체계와 관련된 라이프 스타일 선택 사이에 있습니다. 그러나 이러한 모든 것들은 약간의 노력이 필요하며 계속되어야합니다. 일주일 동안 매일 조깅을 하거나 한 달 동안 술을 마시면 전반적인 건강에 흠집이 날 것입니다. 그것은 또한 나가서 우리가 실행 걸릴 첫 날 10k를 실행하는 것이 좋습니다. 우리는 먼저 운동에 우리의 마음과 근육을 노출해야합니다. 우리는 또한 우리가 우리의 몸과 우리가 사랑하는 건강한 음식과 운동에 대한 좋은 균형을 찾을 때까지 실험의 비트를 가지고 있다는 것을 알고있다.

소프트웨어 개발 보안에 관해서는 그렇게 다르지 않습니다. 학습은 시간이 지남에 따라 연습과 함께 발생하며 개발자는 정기적으로 안전한 코딩 기술을 향상시키기 위해 동일한 진행 교육이 필요합니다. 물론 소프트웨어 개발은 항상 진화하고 적응하고 있으며, 이는 취약점도 마찬가지입니다. 그래서 간단한 교육 과정만으로는 충분하지 않습니다. 개발자는 잠재적인 위협에 충분히 익숙해지기 위해서는 정기적인 업스킬링이 필요합니다. 

개발 팀 내에서 무리 면역을 달성하는 것을 목표로

한 사람이 모든 보안 문제를 방지할 수 없습니다. 팀에 보안 챔피언이 있는 것은 좋지만, 최상의 보호를 위해 보안 취약점에 대해 알게 된 사람들이 많을수록 조직이 이를 예방할 수 있는 더 나은 기회를 얻을 수 있습니다. 다시 그것은 면역 체계가 다른 목적을 위해 T 세포의 다른 모형이 있는 방법보다는 별로 다르지 않습니다. 모든 개발자는 보안을 보장하는 팀의 일부입니다. 그들이 책임을 지고, 잘 하고, 심지어 그것을 즐기는 능력이 있다면, 결과적으로 개발 팀 내에서 사이버 위협에 대한 무리 면역을 만들 수 있습니다.

반복 노출로 보안 상단 유지

우리의 뇌는 우리의 면역 계통이 작동하는 것과 유사한 방식으로 배웁니다. 독일의 심리학자 헤르만 에빙하우스는 기억과 학습 분야의 선구자였습니다. 그는 학습이 시간이 지남에 따라 여러 학습 세션으로 이루어야 한다고 추론했습니다. 우리가 학교에 있을 때, 우리는 첫 번째 소개 후에 새로운 지식을 유지할 것으로 예상되지 않습니다. 먼저 정보가 우리에게 제시되고, 우리는 지침으로 그것을 연습한 다음 스스로 연습합니다. 그리고 시험에 합격할 수 있을 만큼 충분히 배운 후에도, 우리가 배우는 데 시간과 노력을 기울인 지식을 정기적으로 사용하지 않는다면 정보는 곧 잊혀지는 경향이 있습니다. 우리 중 얼마나 많은 사람들이 고등학교 프랑스어를 기억해야 한다는 것을 기억할 수 있습니까?

그렇다면 슬라이드를 보고 누군가보안에 대해 이야기하는 하루를 하면 실제로 출석 하는 개발자가 보다 안전하게 코딩될 수 있다고 어떻게 믿을 수 있을까요?

반복되는 취약점의 패턴은 이것이 단순히 작동하지 않는다는 것을 보여줍니다. 

안전한 개발 면역을 어떻게 달성할 수 있습니까?

그 해답은 우리의 본성에 있습니다. 우리의 몸과 마음은 똑같이 작동하며, 우리가 그들과 함께 일하고 그들에 반대하지 않는 한, 그들은 문제에 대한 아름다운 해결책을 제공합니다. 

응용 프로그램이 안전한지 확인하려면 개발자를 업스킬링하여 보안 코드를 작성해야 합니다. 그렇지 않으면 AppSec은 보안 결함에 대한 모든 코드를 검토하고 동일한 반복 취약점을 다시 개발로 보고하여 학습된 것이 없는 것으로 신속하게 수정되는 데 모든 시간을 할애할 것입니다. 그리고 다음 릴리스를 위해 모든 것을 다시 수행합니다.

그래서 반복하자.

이를 위해 개발 관리자와 협력하는 경우 보안 SDLC를 구현하고 규정 준수 상자에 대한 보안 교육 요구 사항을 체크할 뿐만 아니라 개발 프로세스에 실제 적인 영향을 줄 수 있습니다. 이 모든 것의 상단에 체리를 넣어, AppSec는 더 이상 발생하지 않습니다 및 다시 개발 팀에 반복 취약점을보고하고 개발자는 그들을 해결하는 데 적은 시간을 할애합니다. 즉, 세상을 더 좋게 만드는 놀라운 소프트웨어를 만들고 개선하는 데 더 많은 시간을 할애할 수 있습니다. 

개발 팀을 업스킬할 준비가 되셨습니까? 가서 우리와 함께 데모를 예약합니다.