보안 사고와 의사 결정을 안내하는 데 사용할 수 있는 취약성을 처리하기 위한 몇 가지 일반 원칙이 있습니다.
첫째, 우리가 무엇을 보호하고 있는지 이해하는 것이 우리가 취해야 할 조치에 영향을 미치기 때문에 항상 중요합니다. 예를 들어, 아티팩트가 웹 서버인 경우 신뢰할 수 없는 사용자로부터 이를 보호해야 합니다. 우리의 아티팩트가 암호화 소프트웨어라면 시스템에 물리적으로 접근하는 사용자로부터도 이를 보호해야 합니다. 각각의 경우에 우리는 위험 경계가 무엇인지, 어디에 초점을 맞춰야 하는지 명확하게 구분합니다.
둘째, 구성은 코드 베이스의 일부입니다. 악의적인 행위자가 구성에 액세스할 수 있는 경우 이는 해당 악의적인 행위자가 코드 베이스에 액세스할 수 있는 것과 기본적으로 동일합니다.
최근 Log4j 2.x 취약점(Log4Shell)으로 인해 발생한 취약한 시스템의 쓰나미를 고려하여 보안 조직으로서 우리는 다른 잠재적인 취약점을 더 면밀히 조사할 수 있습니다. 그러나 코드에서 발견한 모든 잠재적인 보안 문제를 성급하게 판단하기 전에 이 기회를 잠시 멈추고 반성해야 할 수도 있습니다. 냉철한 사람은 안전 문제를 일으키는 모든 것이 반드시 동일하게 분류되는 것은 아니라고 제안할 수도 있습니다.
예를 들어, 이 렌즈를 통해 Log4j 1.x에 대한 최근 CVE-2021-4104 할당을 살펴볼 수 있습니다. 이를 악용하려면 설정을 조작하기 위해 구성 파일에 직접 액세스해야 합니다. Node 커뮤니티의 예와 함께 Logback 프로젝트와 관련하여 유사한 주제가 등장하고 있습니다.
확실히 해두자면, 잠재적인 취약점을 노출하는 것은 여전히 좋은 일입니다. 그러나 미디어의 공포 속에서도 우리 자신의 비판적 사고를 탐구하고 우리가 주목해야 할 커뮤니티 기준을 다시 설정하는 것도 적절합니다. 잠재적인 취약점이 또다시 쓰나미를 일으키면 득보다 실이 더 많아 이미 과도한 스트레스를 받고 있는 보안 팀을 더욱 압도하고 오픈 소스 소프트웨어를 보호하려는 업계의 지속적인 노력을 방해할 수 있습니다.
CVE에 대한 비판적 사고
위 스레드에서 확인된 토론은 몇 가지 매우 흥미로운 질문을 제기합니다.
예를 들어, 취약점을 악용하려면 시스템 내부 파일에 대한 권한 있는 액세스가 필요한 경우 이것이 실제로 취약점입니까? 거의 모든 중요한 최신 소프트웨어는 안전하지 않은 작업을 허용하도록 구성될 수 있습니다. 마찬가지로, sshd가 빈 비밀번호를 사용한 로그인을 허용하도록 구성되었을 수도 있습니다. 이것을 sshd의 새로운 취약점으로 간주해야 합니까?
우리 보안 팀이 사용하는 메커니즘 중 하나는 예상되는 동작과 예상치 못한 동작을 고려하는 아이디어입니다. 원격 코드를 실행하도록 소프트웨어를 구성할 수 있고 이 기능이 잘 문서화되어 있다면 이는 악용될 수 있는 취약점을 제공하는 행위입니까? 이는 실제로 그 자체로 보안 취약점이 되기보다는 예상되는 동작으로 간주될 수 있습니다.
안전하지 않은 구성 패턴이 없도록 소프트웨어를 설계해야 합니까? 이는 칭찬할 만한 목표로 보일 수 있지만 지난 30년 이상 동안 우리가 오픈 소스 소프트웨어를 설계해 온 방식과 다소 충돌합니다. 오픈 소스 소프트웨어의 일반적인 설계 목표는 모든 사용 사례를 허용하는 최고 수준의 구성 가능성을 달성하는 것입니다. 최근에는 합리적인 보안 기본값이 부차적인 목표가 되었지만 원칙은 항상 사용자에게 적합하거나 안전하거나 안전하지 않다고 생각하는 방식으로 소프트웨어를 구성할 수 있는 선택권을 주는 것이었습니다.
또한 우리는 현재 CVE가 개인과 회사 모두 쉽게 제기할 수 있고 신뢰성과 캐시 가능성으로 인해 가치가 있는 세상에 살고 있습니다. 이러한 독특한 조합은 문제가 있는 과제로 이어질 수 있습니다. 반면, 잠재적인 보안 문제를 원활하게 보고할 수 있는 능력은 긍정적일 수밖에 없으므로 우리는 뭔가 역설적인 상황에 직면하게 됩니다.
업계에서는 더 많은 소프트웨어를 개발하면서 취약점 식별 능력이 점점 더 향상되고 있으므로 과부하 가능성을 쉽게 확인할 수 있습니다.
소프트웨어의 취약점을 적절하게 식별하고 이를 평가하고 완화 조치를 제공하는 것은 특히 복잡한 경우에 매우 리소스 집약적이며 대부분 수동 프로세스입니다. 기계 학습 방법이 점점 더 유용해지고 인공 지능의 가치가 더욱 높아질 수 있지만, 많은 경우 (아이러니하게도) 컴퓨터는 진단에 그다지 유용하지 않습니다.
미래를 바라보며
여기에 설명된 토론 포인트는 특정 CVE를 변경하기 위한 것이 아니라 취약점 평가의 미래와 현재와 미래에 안전하지 않다고 간주되는 사항에 대한 대화를 시작하기 위한 것입니다. 일반적인 사용 사례에 적합한 강력하고 일반적인 오픈 소스 소프트웨어를 구축하려면 필연적으로 어느 정도 보안을 제공하는 구성 가능한 모드가 필요합니다. 이 작업을 계속하려면 사용의 함정을 이해하는 것도 사용자의 책임입니다. 아마도 대답은 더 나은 문서화와 교육뿐 아니라 일반적인 사용 사례에서 잠재적인 취약점을 분류하는 것일 수도 있습니다.
참고 : https://snyk.io/blog/when-is-a-cve-not-a-cve/
CNCSO의 원본 기사, 재생산 시 출처를 명시해 주세요: https://cncso.com/kr/컨텍스트의-보안-html
