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