오픈소스는 장점과 단점이 매우 명확하다. 장점이 명확한 탓에 앞으로도 계속해서 사용될 것으로 보이며, 그렇기에 단점을 해결하는 것이 당분간은 관건이 될 전망이다. 다행히 오픈소스에 대한 대책만 잘 마련하면 얻어갈 것이 많아 보인다.
오픈소스 소프트웨어는 어디에나 존재한다. 기술 혁신의 촉진제이기도 하며, 애플리케이션 마감 시간을 실질적으로 단축시켜주는 일등공신이기도 하다. 동시에 각종 보안 사건을 초래하는 구멍이기도 하며, 공격자들이 드나드는 통로가 되기도 한다. ‘어디에나 있다’는 특성 때문에 오픈소스에서 발견된 통로는 대단히 파급력이 높으며, 이는 최근의 로그4j(Log4j) 취약점 사태로 인해 극명하게 드러난 바 있다.
[이미지 = utoimage]
오픈소스, 사이버 범죄자들에게도 매력적이다
오픈소스를 겨냥한 사이버 공격 전략은 공격자들에게 매우 매력적으로 다가온다. 오픈소스는 개발자들이 널리 사용하기 때문에, 오픈소스만 잘 감염시켜두면 그 효과가 일파만파 퍼져가기 때문이다. 적은 노력으로 많은 것을 거두게 하는 것이 지금의 오픈소스다. 게다가 오픈소스는 누구나 들여다보고 점검에 참여할 수 있는데, 그렇기 때문에 오히려 누구나 돌보지 않는 요소로 남아있을 때가 많다. 공격자들의 속임수에 ‘누군가 점검하겠지’라는 무관심이 겹쳐지면 악성 요소들을 꽤나 오랜 시간 숨길 수 있다.
오픈소스 공격의 피해 규모와 피해 조직은 다양하며, 쉽게 가늠하기 어렵다. 예를 들어 2017년 에퀴팩스(Equifax)라는 대형 신용 모니터링 및 조회 기업에서 오픈소스 관련 데이터 침해 사고가 발생했을 때 1억 5천 명에 가까운 사람들이 피해를 입었다. 하지만 중소 기업에서 주로 사용하는 오픈소스인 에스포CRM(EspoCRM), 핌코어(Pimcore), 어카운팅(Akaunting)에서 취약점이 9개나 발견됐지만 사실 이 사건은 거의 아무런 일 없이 묻히다시피 했다.
그 누구도 오픈소스에서 벗어날 수 없다
미국의 사이버 보안 전담 기관인 CISA는 로그4j의 취약점을 보유하고 있는 장비가 적어도 수천만 대에서 수억 대 될 것이라고 발표했다. 또한 보안 업계는 로그4j 취약점을 해결하는 데에 적어도 수년이 걸릴 것이라고 예측하고 있기도 하다. 이런 사건과 예측들로부터 경각심을 가지게 된 조직이라면 앞으로 오픈소스를 사용할 때 조심스러워질 수밖에 없을 것이다.
하지만 오픈소스를 전혀 사용하지 않겠다는 건 현실적이지 않다. 현대 소프트웨어들은 전부 오픈소스라는 기본 단위를 벽돌처럼 쌓는 방식으로 만들어지기 때문이다. 이 오픈소스가 있어 조직들은 비슷한 기능들을 구현할 때마다 새로 프로그래밍을 할 필요가 없고, 심지어 투자 비용과 시간이 크게 줄어드는 효과도 본다. 이것이 개발 과정에서는 그 무엇과도 바꿀 수 없는 장점이기 때문에 이를 포기하는 조직이 나오지는 않을 것이다. 현존하는 웹사이트들의 60%가 아파치(Apache)와 엔진엑스(Nginx)를 기반으로 하고 있고, 90%의 IT 전문가들도 활발하게 오픈소스를 활용하고 있다.
소프트웨어 실험과 보호
오픈소스를 완전히 배제하는 건 있을 수도 없는 일이고, 좋은 해결책도 아니다. 소프트웨어 개발 팀과 보안 팀이 합작해서 소프트웨어 개발, 정책 마련, 완성품 실험과 같은 프로세스를 새롭게 마련하는 것이 훨씬 현실적이며 효과적인 대책이다. 만약 이런 식으로 오픈소스 문제를 해결하고자 하는 조직이라면 세 가지 단계로 나눠서 접근하는 것을 권한다. 첫 번째는 코드의 스캔과 실험이다. 두 번째는 발견된 취약점의 해결 프로세스를 명확하게 설정하는 것이다. 세 번째는 보안 문제를 다루는 것에 대한 규칙을 설정하는 것이다.
오픈소스 환경의 복원력 혹은 방어력을 실험할 때라면 정적 코드 분석부터 실시하는 것이 좋다. 하지만 정적 코드 분석만으로 오픈코드 환경을 전부 확인할 수는 없다. 이건 시작일 뿐이다. 정적 코드 분석이란, 오픈소스 소프트웨어가 실제 애플리케이션 내에 구축되기 전 단계에서 행해지는 것으로, 실제 실행이 되었을 때와는 사뭇 다른 결과를 낼 수 있다. 실행이 되는 단계에서 발동되는 악의적인 특성이 있을 수도 있기 때문이다. 그런 특성들은 정적 코드 분석으로 잡아낼 수 없다. 그렇기 때문에 샌드박스 환경에서 추가로 실험을 진행하는 게 좋다. 이를 동적 코드 분석이라고 한다.
스캔을 완료했다면 이제 발견된 취약점을 해결할 차례다. 하지만 그 전에 이 취약점을 어떤 식으로, 어떤 순서로 해결할 것인지를 결정해야 한다. 취약점을 해결하다가 개발자가 애써 줄여놓은 개발 기간이 연장될 수 있고, 출시 이후에 발견된 취약점들에 대한 패치 개발도 염두에 두어야 하기 때문이다. 개발, 취약점 발견, 해결, 출시가 모두 종합적으로 고려된 개발 및 출시 프로세스가 정리되어야 누구도 나중에 불만을 갖지 않게 된다. 특히 ‘빨리 하라고 해서 빨리 개발했더니 나중에 취약점에 대한 책임까지도 묻더라’라는 난처한 입장에 개발자들이 처하지 않을 수 있게 된다.
이렇게 프로세스를 정한다고 하더라도 누군가는 금방 잊어버릴 수 있고, 상황에 따라 프로세스가 변경될 수도 있다. 그러니 결정된 프로세스에 대하여서나, 그 프로세스를 변경하는 방법에 대해서는 문서화 하는 것을 추천한다. 오픈소스를 활용한 개발은 어떤 순서로, 어떤 실험 과정을 통해 이뤄지며, 어떤 상태에서 출시를 할 수 있고, 얼마나 긴 기간 동안 패치로 지원을 해야 하는지, 그리고 이런 순서가 변경되어야 할 때 어떤 순서로, 어떤 권한을 가진 사람이 변경을 진행하는지 문서로 명확히 해두면 나중에 혼란이 줄어든다.
이 때 사용 가능한 오픈소스의 ‘자격’이나 ‘등급’ 역시 미리 정해둘 수 있다. 나쁜 방법이라고 볼 수는 없는데, 이 등급을 맞추는 과정에서 업무가 좀 과도해질 가능성은 존재한다. 또한 개발 과정 전체가 느려질 수도 있다. 그래서 이 내용은 보안과 개발 속도의 중요성에 따라 조직이 상황에 맞게 결정하거나 결정하도록 하면 될 것이다. [기사 더보기]
[출처 : 보안뉴스(https://www.boannews.com/)]
[기자 : 문정후 기자(globoan@boannews.com)]
