당장 급해 보이는 것에 집중하다보면 자연스럽게 다음으로 미뤄지는 것들이 있다. 기술 부채가 바로 그런 것들이다. 모든 빚이 그렇듯, 기술 부채도 잊고 살다보면 언젠가 숨통을 조이는 손아귀로 변한다. CISO가 특별히 기술 부채에 관심을 기울여야 한다.
[보안뉴스 문정후 기자] 새로운 기능을 추가한다는 것의 이면에는 항상 어두운 측면이 존재했다. 이른 바 ‘기술 부채’라는 것이 쌓인다는 것이다. 그렇기 때문에 기능을 추가하는 대신 안정성이 떨어진다든지, 속도가 느려진다든지, 보안성이 낮아진다든지 하는 일들을 우리는 겪는다. 하나를 얻고 하나를 잃는 게 우리 IT 생태계의 기본 진리다.
지금의 IT 분야를 관통하는 표현은 ‘빠르게 출시하고 기존의 것을 부순다’이다. 빠르게 전진, 그것도 장애물을 다 부수며 통과하는 그런 느낌이다. 그러면서 기술 부채를 뒤에 조금씩 남겨가며 누적시키게 되는데, 그 부채라는 것의 대부분은 ‘보안’이라고 할 수 있다. 그것도 기꺼이 남기는 게 보통이다. 앞으로 나아가기 위해 보안을 기꺼이 희생한다는 뜻이다. 아무래도 신기능과 새 기술을 도입하는 것에 관심이 갈 수밖에 없다. 이런 보편적인 성향을 거슬러 보안이라는 채무를 다 해결하도록 조직을 이끄는 게 CISO의 역할이라고 할 수 있다.
로그4j(Log4j)라는 취약점이 왜 그토록 큰 화제가 되었을까? 그 취약점이 너무나 많은 요소들에, 너무나 깊이 얽혀 있었기 때문이다. 로그4j라는 취약점 하나만을 보면 큰 문제가 아닌데, 우리가 지난 수십 년 동안 그 취약점 위에 너무나 많은 부채를 쌓아 왔다는 것이다. 이렇게 허망한 기초 위에 쌓아둔 성이 한두 개일까? 어떻게 해서든 로그4j의 위기만 넘긴다면 우린 안전할까?
기술 부채를 지난 수십 년 넘게 쌓아왔고, 그것이 조금씩 삐그덕거리기 시작했으며, 로그4j는 시작에 불과한 현상이라고 필자는 생각한다. 이렇게 소프트웨어의 공급망에서 각종 보안 문제가 생기는 현상을 보안 업계는 많이 겪지 않았다. 새로운 도전 과제가 우리를 향해 다가오고 있다고도 볼 수 있다. 이런 때 CISO들이 해야 할 일들이 있다.
새로운 유형의 취약점이 다가온다는 것을 받아들인다
대부분의 기업들은 이제 ‘네트워크 보안’에 있어서는 꽤나 능숙한 모습을 보인다. 온프레미스 환경에서 생기는 문제들에 대해서는 익숙한 모습이다. 하지만 이제 새로운 유형의 문제들에 익숙해져야 한다. 바로 개발 환경과 소프트웨어 공급망에서 발생하는 문제들이다. 당연하지만 온프레미스 바깥으로까지 뻗쳐 있는 문제들이며, 그러므로 우리 회사 직원이 아닌 사람들까지도 관여된다. 특히 각종 개발 환경과 소프트웨어 아티팩트들까지도 아울러야 한다는 점에서 까다롭다.
이제 약간의 상식과 경험을 갖춘 사람들이라면 오늘 생전 처음 보고 출처도 알 수 없는 USB 드라이브를 집어들고 다짜고짜 자기 노트북에 꼽지 않는다. 그 안에 온갖 해악한 것들이 들어있을 수 있다는 것을 인지하고 있는 것이다. 공공 리포지터리에서 발견한 소프트웨어 패키지도 마찬가지다. 주인 없는 USB를 조심스럽게 확인하듯 소프트웨어 패키지들도 충분히 확인한 후에 사용해야 한다.
하지만 현실 속에서 그렇게까지 하는 사람은 찾기 힘들다. USB는 조심하는데 유명 리포지터리에서 찾은 소프트웨어 패키지는 아무렇게나 사용한다. 공격자들은 개발자들의 이러한 습성을 알고 악용한다. 너무나 쉬운 공략 대상이나 그냥 넘어가기가 어려운 것이다. 이 구멍을 통해 공격자들은 개발자가 속한 조직의 네트워크에 드나들 수 있게 되고, 다른 장비나 개발 환경에 도달할 수 있게 되며, 각종 정보들에 접근할 수 있게 된다. 새로운 유형의 공격 통로가 열렸고 또 넓어지는 중이다.
개발 환경을 폐쇄시키는 것으로는 답이 되지 않는다
개발 환경을 공격자들이 자주 노린다고 해서 개발 환경을 폐쇄할 수는 없는 노릇이다. 이런 상황에서 CISO들이 해야 할 일은 여러 가지가 있을 수 있는데, 먼저는 개발자들을 대상으로 한 각종 지침이나 정책 자료를 모아서 제공하거나, NIST의 안전소프트웨어개발프레임워크(SSDF), 오픈SSF의 소프트웨아티팩트공급망수준(SLSA) 등을 개발자들에게 알려주고 교육하고 훈련시키는 것도 좋은 방법 중 하나다. 사실 가장 기본적인 절차라고 할 수도 있겠다.
이 때 지나치게 보안의 관점에서 보안의 기본 내용들을 개발자들에게 강제적으로 알려주는 건 안 될 일이다. 오히려 개발자들이 오픈소스를 어떤 식으로 어떤 이유로 활용하는지를 깊이 이해하는 것이 먼저다. 보안을 위한 회사의 정책을 개발자들은 어떻게 이해하고 있는가? 오픈소스를 어디서 주로 가져오는가? 오픈소스를 어떻게 확인하고 확신하는가? 이런 질문을 가지고 개발자의 시선을 보다 확실하게 익힐 필요가 있다.
여태까지 쌓여왔던 혹은 오래된 기술 부채부터 갚는 건 어떨까?
개발자의 시선으로 개발 환경을 단단히 다져가고 있거나 다 다졌다면, 겨우 기초 작업을 이뤄가고 있는 것이니 아직 안심해서는 안 된다. 기초 중 기초 작업만 겨우 해낸 것이다. 이제는 그 기초 위에서 실질적인 ‘강화 작업’을 해야 한다. 소프트웨어와 OS, 펌웨어들을 패치함으로써 취약점들을 없애는 것부터 시작하는 걸 추천한다.
소프트웨어를 업데이트 하고 그 때 그 때 패치하는 건 그 자체로 어려운 일은 아니나 지겹고 따분할 때가 많다. 재미는 없는데 시간도 많이 잡아먹는다. 하찮은 일이면서 누가 알아주지도 않는 일이다. 하지만 빚을 갚는 것에 해당하는 모든 일이 그렇다. 빚을 낼 때나 그 돈을 쓸 때는 잘 몰랐던, 꾸준히 갚아가는 것의 단조로움과 막막함은(물론 빚이 조금씩 사라지는 것을 보는 희열도 있긴 하지만) 빚을 져본 사람이면 누구나 알 것이다. 그렇다고 안 할 수도 없는 게 채무 청산이다. 각종 업데이트와 패치도 마찬가지다.
물론 적잖은 반대에 부딪힐 수 있다. 어디에나 새 것을 두려워 하는 사람도 있고, 새 것만 좋아하는 사람도 있기 마련이다. 소프트웨어 업데이트를 할 때 뭔가 달라질까봐 진지하게 고민하는 사람들도 얼마든지 존재한다. “그래도 해야 된다!”고 강압적으로 밀어붙이는 건 이런 부류의 불안감을 전혀 해소시키지 못한다. 테스트 환경을 만들어 패치 이후의 소프트웨어/OS/펌웨어를 사용해 보도록 하는 것이 좋다. 이런 작업을 소홀히 해 취약점을 계속 쌓는다면 나중에 더 큰 문제가 발생한다.
신규 부채가 쌓이지 않도록 하라
개발 환경을 단단히 만들고 과거 부채들도 어느 정도 갚는 것이 진정한 효과를 발휘하려면 새로운 기술 부채가 생기지 않도록 해야 한다. 기껏 갚고 해결하고 훌훌 털고 돌아섰더니 새로운 부채가 더 많이 쌓인다면 얼마나 허무하겠는가. 예전 것을 줄이며 새로운 것이 생기지 않도록 채무의 과거와 현재를 같이 바라보는 것이 CISO의 시선이어야 한다.
그러므로 CISO들은 개발자들이 안전하게 일할 수 있는 환경을 미리 만들어 두어, 개발자들이 개발 환경이라는 전체 그림을 다 고려하기 전에 코드부터 어디선가 들고 들어와 작업을 시작하는 일이 없도록 해야 한다. 사실 개발자가 필요로 하는 코드들을 미리 검사하거나, 그 때 그 때 실시간으로 검사하는 방법과 프로세스를 구축하는 것도 필요한 일이다. 빚을 쌓지 않고 나아가는 방법, 특히 개발자들이 자기도 모르게 빚을 누적시키지 않도록 가이드라인을 제시하는 것이 CISO의 중요한 역할이다.
글 : 댄 로렝(Dan Lorenc), CEO, Chainguard
[국제부 문정후 기자(globoan@boannews.com)]
[보안뉴스 문정후 기자] 새로운 기능을 추가한다는 것의 이면에는 항상 어두운 측면이 존재했다. 이른 바 ‘기술 부채’라는 것이 쌓인다는 것이다. 그렇기 때문에 기능을 추가하는 대신 안정성이 떨어진다든지, 속도가 느려진다든지, 보안성이 낮아진다든지 하는 일들을 우리는 겪는다. 하나를 얻고 하나를 잃는 게 우리 IT 생태계의 기본 진리다.
[이미지 = gettyimagesbank]
지금의 IT 분야를 관통하는 표현은 ‘빠르게 출시하고 기존의 것을 부순다’이다. 빠르게 전진, 그것도 장애물을 다 부수며 통과하는 그런 느낌이다. 그러면서 기술 부채를 뒤에 조금씩 남겨가며 누적시키게 되는데, 그 부채라는 것의 대부분은 ‘보안’이라고 할 수 있다. 그것도 기꺼이 남기는 게 보통이다. 앞으로 나아가기 위해 보안을 기꺼이 희생한다는 뜻이다. 아무래도 신기능과 새 기술을 도입하는 것에 관심이 갈 수밖에 없다. 이런 보편적인 성향을 거슬러 보안이라는 채무를 다 해결하도록 조직을 이끄는 게 CISO의 역할이라고 할 수 있다.
로그4j(Log4j)라는 취약점이 왜 그토록 큰 화제가 되었을까? 그 취약점이 너무나 많은 요소들에, 너무나 깊이 얽혀 있었기 때문이다. 로그4j라는 취약점 하나만을 보면 큰 문제가 아닌데, 우리가 지난 수십 년 동안 그 취약점 위에 너무나 많은 부채를 쌓아 왔다는 것이다. 이렇게 허망한 기초 위에 쌓아둔 성이 한두 개일까? 어떻게 해서든 로그4j의 위기만 넘긴다면 우린 안전할까?
기술 부채를 지난 수십 년 넘게 쌓아왔고, 그것이 조금씩 삐그덕거리기 시작했으며, 로그4j는 시작에 불과한 현상이라고 필자는 생각한다. 이렇게 소프트웨어의 공급망에서 각종 보안 문제가 생기는 현상을 보안 업계는 많이 겪지 않았다. 새로운 도전 과제가 우리를 향해 다가오고 있다고도 볼 수 있다. 이런 때 CISO들이 해야 할 일들이 있다.
새로운 유형의 취약점이 다가온다는 것을 받아들인다
대부분의 기업들은 이제 ‘네트워크 보안’에 있어서는 꽤나 능숙한 모습을 보인다. 온프레미스 환경에서 생기는 문제들에 대해서는 익숙한 모습이다. 하지만 이제 새로운 유형의 문제들에 익숙해져야 한다. 바로 개발 환경과 소프트웨어 공급망에서 발생하는 문제들이다. 당연하지만 온프레미스 바깥으로까지 뻗쳐 있는 문제들이며, 그러므로 우리 회사 직원이 아닌 사람들까지도 관여된다. 특히 각종 개발 환경과 소프트웨어 아티팩트들까지도 아울러야 한다는 점에서 까다롭다.
이제 약간의 상식과 경험을 갖춘 사람들이라면 오늘 생전 처음 보고 출처도 알 수 없는 USB 드라이브를 집어들고 다짜고짜 자기 노트북에 꼽지 않는다. 그 안에 온갖 해악한 것들이 들어있을 수 있다는 것을 인지하고 있는 것이다. 공공 리포지터리에서 발견한 소프트웨어 패키지도 마찬가지다. 주인 없는 USB를 조심스럽게 확인하듯 소프트웨어 패키지들도 충분히 확인한 후에 사용해야 한다.
하지만 현실 속에서 그렇게까지 하는 사람은 찾기 힘들다. USB는 조심하는데 유명 리포지터리에서 찾은 소프트웨어 패키지는 아무렇게나 사용한다. 공격자들은 개발자들의 이러한 습성을 알고 악용한다. 너무나 쉬운 공략 대상이나 그냥 넘어가기가 어려운 것이다. 이 구멍을 통해 공격자들은 개발자가 속한 조직의 네트워크에 드나들 수 있게 되고, 다른 장비나 개발 환경에 도달할 수 있게 되며, 각종 정보들에 접근할 수 있게 된다. 새로운 유형의 공격 통로가 열렸고 또 넓어지는 중이다.
개발 환경을 폐쇄시키는 것으로는 답이 되지 않는다
개발 환경을 공격자들이 자주 노린다고 해서 개발 환경을 폐쇄할 수는 없는 노릇이다. 이런 상황에서 CISO들이 해야 할 일은 여러 가지가 있을 수 있는데, 먼저는 개발자들을 대상으로 한 각종 지침이나 정책 자료를 모아서 제공하거나, NIST의 안전소프트웨어개발프레임워크(SSDF), 오픈SSF의 소프트웨아티팩트공급망수준(SLSA) 등을 개발자들에게 알려주고 교육하고 훈련시키는 것도 좋은 방법 중 하나다. 사실 가장 기본적인 절차라고 할 수도 있겠다.
이 때 지나치게 보안의 관점에서 보안의 기본 내용들을 개발자들에게 강제적으로 알려주는 건 안 될 일이다. 오히려 개발자들이 오픈소스를 어떤 식으로 어떤 이유로 활용하는지를 깊이 이해하는 것이 먼저다. 보안을 위한 회사의 정책을 개발자들은 어떻게 이해하고 있는가? 오픈소스를 어디서 주로 가져오는가? 오픈소스를 어떻게 확인하고 확신하는가? 이런 질문을 가지고 개발자의 시선을 보다 확실하게 익힐 필요가 있다.
여태까지 쌓여왔던 혹은 오래된 기술 부채부터 갚는 건 어떨까?
개발자의 시선으로 개발 환경을 단단히 다져가고 있거나 다 다졌다면, 겨우 기초 작업을 이뤄가고 있는 것이니 아직 안심해서는 안 된다. 기초 중 기초 작업만 겨우 해낸 것이다. 이제는 그 기초 위에서 실질적인 ‘강화 작업’을 해야 한다. 소프트웨어와 OS, 펌웨어들을 패치함으로써 취약점들을 없애는 것부터 시작하는 걸 추천한다.
소프트웨어를 업데이트 하고 그 때 그 때 패치하는 건 그 자체로 어려운 일은 아니나 지겹고 따분할 때가 많다. 재미는 없는데 시간도 많이 잡아먹는다. 하찮은 일이면서 누가 알아주지도 않는 일이다. 하지만 빚을 갚는 것에 해당하는 모든 일이 그렇다. 빚을 낼 때나 그 돈을 쓸 때는 잘 몰랐던, 꾸준히 갚아가는 것의 단조로움과 막막함은(물론 빚이 조금씩 사라지는 것을 보는 희열도 있긴 하지만) 빚을 져본 사람이면 누구나 알 것이다. 그렇다고 안 할 수도 없는 게 채무 청산이다. 각종 업데이트와 패치도 마찬가지다.
물론 적잖은 반대에 부딪힐 수 있다. 어디에나 새 것을 두려워 하는 사람도 있고, 새 것만 좋아하는 사람도 있기 마련이다. 소프트웨어 업데이트를 할 때 뭔가 달라질까봐 진지하게 고민하는 사람들도 얼마든지 존재한다. “그래도 해야 된다!”고 강압적으로 밀어붙이는 건 이런 부류의 불안감을 전혀 해소시키지 못한다. 테스트 환경을 만들어 패치 이후의 소프트웨어/OS/펌웨어를 사용해 보도록 하는 것이 좋다. 이런 작업을 소홀히 해 취약점을 계속 쌓는다면 나중에 더 큰 문제가 발생한다.
신규 부채가 쌓이지 않도록 하라
개발 환경을 단단히 만들고 과거 부채들도 어느 정도 갚는 것이 진정한 효과를 발휘하려면 새로운 기술 부채가 생기지 않도록 해야 한다. 기껏 갚고 해결하고 훌훌 털고 돌아섰더니 새로운 부채가 더 많이 쌓인다면 얼마나 허무하겠는가. 예전 것을 줄이며 새로운 것이 생기지 않도록 채무의 과거와 현재를 같이 바라보는 것이 CISO의 시선이어야 한다.
그러므로 CISO들은 개발자들이 안전하게 일할 수 있는 환경을 미리 만들어 두어, 개발자들이 개발 환경이라는 전체 그림을 다 고려하기 전에 코드부터 어디선가 들고 들어와 작업을 시작하는 일이 없도록 해야 한다. 사실 개발자가 필요로 하는 코드들을 미리 검사하거나, 그 때 그 때 실시간으로 검사하는 방법과 프로세스를 구축하는 것도 필요한 일이다. 빚을 쌓지 않고 나아가는 방법, 특히 개발자들이 자기도 모르게 빚을 누적시키지 않도록 가이드라인을 제시하는 것이 CISO의 중요한 역할이다.
글 : 댄 로렝(Dan Lorenc), CEO, Chainguard
[국제부 문정후 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-05-12] 
