0일은 개발의 1일이었습니다.
컬럼비아 대학의 최근 연구에 따르면 우리는 하루에 70개 이상의 결정에 얽매여 있다고 합니다. 물론 중요한 것만 세어 본다면 말입니다. 코넬 대학 의 이전 연구에 따르면 우리는 하루에 음식과 관련된 결정만 200개가 넘습니다.
우리가 하루에 내리는 결정 중 대부분은 장기적으로 보면 중요하지 않은 것들입니다. 영향은 미미하며, 대부분 "좋음"이나 "나쁨"으로 분류할 수 없습니다. 그것들은 단지 우리가 내린 선택일 뿐입니다. 하지만 어떤 선택은 심각한 결과를 초래합니다. 일부는 의도적이며 사전에 생각해 낸 것입니다. 어떤 것들은 의도치 않은 일이며, 뒤늦게 깨달아서야 분명해집니다.
돌이켜보면 당연한 것처럼 보이는 몇 가지 의도치 않은 결과는 애플리케이션의 보안과 관련이 있습니다.
선택사항: 플랫폼, 프레임워크 및 구성 요소
개발 첫날부터 선택이 이루어집니다. 그러한 선택의 대부분은 플랫폼 및 프레임워크, 라이브러리, 타사 구성 요소를 중심으로 이루어집니다. 개발 과정에서는 이런 선택이 많이 이루어집니다. 오늘날 애플리케이션의 80-90%가 오픈/타사 소스 구성요소로 구성되어 있다고 추정 됩니다. 오픈/타사 소스 구성 요소를 포함하게 되는 각 선택은 특히 애플리케이션 보안과 관련하여 잠재적인 결과를 초래합니다. Black Duck Software의 분석에 따르면 상용 소프트웨어 제품 당 평균 105개의 오픈소스 구성 요소가 포함되어 있다고 합니다.
표면적으로 보면 그러한 결과는 그렇게 무섭지 않습니다. Contrast Security의 조사에 따르면 소프트웨어 라이브러리는 취약점의 7%에 불과한 것으로 나타났습니다. Black Duck은 애플리케이션당 평균 22.5개의 오픈소스 취약점을 발견했습니다. 해당 취약점 중 40%가 '심각'으로 평가되었습니다. 하지만 애플리케이션의 나머지 10~20%인 사용자 정의 코드가 애플리케이션의 취약점 대부분을 담당한다는 점을 고려하면 그 정도는 최소한에 불과합니다.
안타깝게도 대부분의 취약점은 CVE를 통해 공개되지 않았으며, 공격자는 샘플 악용 코드에 쉽게 접근할 수 없었습니다. 악의적인 행위자는 수천 개의 웹 애플리케이션에서 동일한 구성 요소와 라이브러리를 사용하는 환경에서 타겟을 찾기 위해 그다지 노력할 필요가 없습니다. 현재, 앱과 웹사이트 구축에 사용된 기술 사용을 추적하는 builtwith.com에 따르면 Apache Struts를 사용하는 라이브 사이트가 거의 40,000개에 달합니다. 대부분의 사람들은 Apache Struts 2의 공개된 취약점이 악용되어 인터넷에 약간의 공황 상태가 발생한 사례를 알고 있습니다. 비슷한 공황은 OpenSSL과 같이 널리 사용되는 오픈 소스 및 타사 라이브러리와 관련된 심각한 취약성 공개로 인해 발생했습니다.
하지만 라이브러리나 타사 구성 요소를 포함할지, 오픈 소스 프레임워크에서 앱을 빌드할지를 선택하는 것만이 잠재적으로 문제가 될 수 있는 것은 아닙니다. 개발 과정에서 우리가 내리는 다른 선택도 심각한 결과를 초래할 수 있으며, 특히 불안정한 개발 관행으로 이어질 경우 더욱 그렇습니다.
선택사항: 속도를 위한 보안 거래
보안이 속도보다 중요하다는 말은 전혀 놀라운 일이 아닙니다. 그것은 항상 그래왔습니다. 2014년 McAfee가 보안 전문가 504명을 대상으로 실시한 설문 조사에 따르면 "조사에 참여한 조직의 약 3분의 1이 방화벽 보안 기능을 정기적으로 비활성화하여 네트워크 성능을 높이려고 시도한다고 인정했습니다."
개발도 다르지 않습니다. 그들은 실행 속도가 아니라 파이프라인 속도에 중점을 둡니다. 시장에 애플리케이션을 더욱 시기적절하게 출시하고 업데이트를 제공해야 한다는 수요를 충족하기 위해, 많은 기업이 개발 단계에서는 보안을 전혀 고려하지 않는다고 인정합니다. 2017년 Arxan | IBM이 모바일 및 IoT 개발자를 대상으로 실시한 설문 조사에 따르면, 응답자의 26%가 보안 문제를 확인하기 위해 모바일 앱을 전혀 테스트하지 않았고, 거의 절반(48%)이 IoT 앱을 테스트하지 않는 것으로 나타났습니다. 69%는 납품에 대한 압박 때문에 보안을 생략하는 경우가 많다고 답했습니다.
올 여름에 진행된 고객 이벤트인 Agility 에 참석한 사람들을 대상으로 한 여론 조사 결과 이것이 현실임을 다시 한 번 확인했습니다. 절반 이상(62%)이 조직 내에서 속도를 위해 보안을 희생했다고 인정했습니다.
그리고 조직이 발견된 취약점을 어떻게 해결할 것인지에 대한 선택도 있습니다. Black Duck의 분석에 따르면 2018년에 검사한 애플리케이션의 10%가 여전히 2014년 Heartbleed 취약점에 취약한 것으로 나타났습니다. Ponemon이 실시한 ServiceNow 연구에 따르면, 침해 피해자 중 무려 57%가 사용 가능한 패치를 설치했더라면 침해를 예방할 수 있었다고 밝혔습니다.
선택에는 결과가 따른다
개발 첫날부터 배포 이후까지 전체 애플리케이션 스택의 보안과 관련하여 내리는 선택은 중요합니다. 이러한 선택은 점심으로 버거나 샐러드를 먹는 것과 같은 수준이 아닙니다. 이러한 선택은 IT와 비즈니스뿐만 아니라 앱 제공업체의 보안을 중요하게 여기는 고객에게도 영향을 미칠 수 있는 결정입니다.
"앱 사용자 여러분"이라는 내용의 편지를 한 번도 받아보지 않은 사람은 거의 없을 겁니다. 이 편지는 데이터가 노출되었다는 내용입니다. 이는 보안을 느슨하게 할 수 있다는 허가가 아닙니다. 오히려 우리 모두는 고객의 개인 정보를 보호하기 위해 더 노력해야 합니다.
그렇게 하기 위한 가장 좋은 방법은 개발 첫날부터 내리는 모든 선택이 우리가 개발하는 애플리케이션의 보안을 향상할 수 있는 기회라는 것을 인식하는 것입니다. 의식적이고 현명하게 선택하세요.
