로그프레소, 보안운영 플랫폼 '로그프레소 엔터프라이즈 4.0' 출시

로그프레소 '소나 4.0' CC인증 획득

보안운영(SecOps) 플랫폼 전문기업 로그프레소(대표 양봉열)는 최근 IT보안인증사무국으로부터 SIEM 플랫폼 '로그프레소 소나 4.0'에 대한 EAL2 등급의 CC인증을 획득했다고 22일 밝혔다. CC인증은 평가기관에서 IT 제품의 보안성을 평가하고 이에 대한 결과를 인증하는 제도다. 제품의 안정성과 신뢰성을 검증받은 제품은 국가·공공기관에 우선 공급할 수 있다. '로그프레소 소나 4.0'은 차세대 통합보안관리(SIEM) 플랫폼이다. 전통 통합보안관리 영역과 더불어, 내부통제, 개인정보관리, 멀티클라우드 관리 등 IT 인프라를 사용하는 모든 영역의 보안 관리 플랫폼으로 활용할 수 있다. 2017년 출시된 이후로 금융권을 비롯한 제조, 공공 등 다양한 산업군에서 통합보안관리, 내부통제, 클라우드 통합관리 등 전사적 정보보안 플랫폼으로 사용 중이다. 특히 인공지능 특허 기술을 적용해 시나리오를 기반으로 하는 기존 위협과 알려지지 않은 비정상적인 위협까지 탐지할 수 있다. 국내외 보안 솔루션 및 다양한 퍼블릭 클라우드 서비스와의 연계가 용이해 클라우드 통합 모니터링 분야에서도 두각을 나타내고 있다. 구동언 로그프레소 사업본부장은 “CC인증 획득으로 로그프레소 소나가 국가에서 요구하는 보안 요구사항을 충족하는 제품이라는 것을 검증 받았다”며 “조달 총판사인 아이티윈과 함께 클라우드 중심으로 전환되는 공공 IT 인프라에 걸맞은 차세대 SIEM 제품 공급에 힘쓸 것”이라고 밝혔다. 윤대원기자 yun1972@etnews.com [https://www.etnews.com/20220520000089](https://www.etnews.com/20220520000089)

2022-05-20

[보안칼럼] 랩서스 공격으로 드러난 관제 사각지대

지난 3월 남미의 해킹조직 랩서스가 MS, 엔비디아, 옥타, 삼성전자 등 글로벌 대기업을 공격해 화제가 됐다. 이들은 기업 기밀을 탈취한 후 돈을 주지 않으면 정보를 유출하겠다는 협박을 자행했고, 텔레그램 등을 통해 행적을 과시하는 대담함을 보였다. 보안 관계자가 충격을 받은 지점은 랩서스가 보안이 견고하다고 알려진 다수 기업을 너무나 쉽게 침투했다는 사실이다. 이들 기업은 인증도 단순 암호가 아닌 다중 인증(MFA)을 사용했을 뿐만 하니라 방화벽, 침입탐지시스템, 엔드포인트 위협 탐지 및 대응 (EDR), 매체제어 솔루션 등 수많은 보안 계층을 유지했다. 그런데 어떻게 이런 보안 계층을 모두 우회했을까. 공통적으로 드러난 주목할 만한 특징은 사회공학적 기법 사용이다. 이를 통해 인증을 우회하고 임직원으로 위장해서 상대적으로 감시가 취약한 SaaS 서비스와 퍼블릭, 프라이빗 클라우드를 공략했다. 이러한 사실은 옥타가 침해 사실을 부인하자 랩서스는 텔레그램을 통해 세부 사항을 밝히며 반박한 대목에서 나타난다.  이는 광범위하게 사용되는 슬랙(Slack)과 같은 협업 툴의 공개된 채널에서 임직원이 AWS 크리덴셜을 공유하는 행위가 전혀 모니터링 및 조처되지 않고 있음을 의미한다. AWS와 슬랙을 사용하고 있다면 같은 사례가 존재하지 않는지 AKIA로 검색해 보길 바란다. 랩서스는 익스체인지 온라인의 메일 플로 룰을 변경해서 숨은 참조로 모든 메일을 포워딩하고 내부 정보를 획득했다. 오피스 365의 중요 변경 사항에 대한 보안 감사를 수행하는 조직은 아직 매우 드물 것이다. 랩서스는 또 셰어포인트(SharePoint), 컨플루언스(Confluence), 지라(JIRA), 깃허브(GitHub) 등 다양한 SaaS 서비스를 탐색하며 민감한 정보에 접근하고 더 높은 계정의 크리덴셜을 확보했다. 정보 유출을 완료한 후에는 프라이빗 클라우드의 가상머신을 삭제하는 파괴적 행위를 한 후 침해대응 팀이 어떻게 움직이는지 관찰하는 여유로움마저 보였다. 이 모든 과정을 돌아보면 통합보안관제 체계가 전통 종심방어 모델에 함몰된 게 얼마나 위험한지 깨닫게 된다. 코로나19는 재택근무와 SaaS 도입을 가속화했고, 기업의 중요한 정보 자산은 더 이상 내부에만 존재하지 않게 됐다. 그러나 전통적 통합보안관제 시스템은 여전히 DDoS, 방화벽, IPS, 웹방화벽 위주의 네트워크 관제 체계에 갇혀 있고 SaaS 역시 데이터 통합에 필요한 감사 API를 제공하는 서비스는 아직까지 소수인 것이 현재 직면한 현실이다. SaaS의 경우 IT나 보안 부서가 아닌 현업 부서에서 직접 도입해 사용하는 경우가 많다. 세일즈포스에는 민감한 매출 정보가 많은데 이에 대한 보안은 누가 책임져야 할까. 영업이나 재무팀일까, 보안팀일까“ HR팀이 도입해서 사용하는 그리팅에는 많은 개인정보가 집적돼 있는데 누가 어떤 이력서에 접근하고 있는지 모니터링할 수 있을까? 현업을 담당하든 보안을 담당하든 SaaS 서비스를 개발하든 우리는 이제 SaaS 보안 문제에 대해 깊이 검토하고 해결해 나가야 한다. 정보 보안은 우리 모두의 책임이기 때문이다. 현업의 역할은 명확하다. 사내에 보안 조직이 있다면 SaaS 도입 시 보안관제 체계에 통합될 수 있도록 검토 프로세스에 포함해야 한다. 만약 별도 보안 조직이 없다면 권한과 정보 공유를 필수 범위로 최소화하는 원칙을 세우고 준수하자. 그렇게 해야만 SaaS 서비스에 내부자 공격이 들어왔을 때 피해 범위를 최소화 할 수 있게 된다. IT 및 보안 역할도 있다. 재택근무와 SaaS 전환으로 인해 전에 없던 많은 공격 경로가 생성됐을 수 있다. SaaS 및 클라우드 침해 발생 시 리스크를 종합적으로 검토해 보고 보안운영 플랫폼에 SaaS 및 클라우드 감사 로그를 통합해 인증 이상 징후, 취약점, 내부 정보 공개 노출, 중요 구성 변경에 대해 모니터링해야 한다. SaaS 서비스는 감사 API 기능 제공에 높은 비용을 책정하는 경향이 있는데 침해 사고가 발생하면 서비스 공급자도 책임을 피해 갈 수 없다. 자체 로그 저장 비용이 문제라면 최소한 고객 소유의 오브젝트 스토리지에 저장 혹은 웹훅 등을 통해서 외부 시스템에 감사 데이터를 통합할 수 있는 기능을 제공해야 한다. 사용자 인증이나 OAuth 애플리케이션 인증 기록은 필수적이다. 정보 조회 등 행위 이력이 모두 기록되면 가장 좋지만, 주요 설정 변경에 대해 통지하는 것만으로도 많은 문제를 예방할 수 있다. 보안운영플랫폼 역할도 필요하다. 관제시스템은 전통적 온프레미스 위주의 보안관제에서 벗어나 새로운 시대적 요구에 부응해야 한다. 온프레미스 환경에 보안관제시스템을 구축했다 하더라도 SaaS 서비스의 구성 정보 및 감사 로그를 취합해서 경보 및 대응 조치를 적시에 수행할 수 있도록 API 통합을 서둘러야 한다. 특히 사회공학적 기법을 사용한 침투는 정상행위와 잘 구분되지 않는 내부자 유출 탐지와 유사한 문제이기 때문에 외부침해관제(SIEM)와 내부유출탐지(UEBA)가 하나로 통합된 보안관제 체계를 제공해야 문제를 해결할 수 있다. 오래 전부터 알려져 있듯이, 보안 시스템은 딱 '가장 약한 연결 고리' 수준의 힘을 갖는다. 공격자는 이미 공개출처 정보 (OSINT), 임직원 매수, 다크웹 크리덴셜 구매, SIM 스와핑 등 다양한 수단을 이용하여 인증 절차를 우회하고 있다. 따라서 내부 접속을 신뢰하지 않는 제로트러스트 기반의 접근 방법이 필요하며 공동의 노력을 통해 SaaS라는 관제의 사각지대를 해소해야만 당면한 문제를 해결하고 공격자의 침투를 훨씬 더 어렵게 만들 수 있다. 보안 로그만을 기반으로 알려진 위협에 대응하는 전통적인 보안관제체계에서 SaaS를 포함한 IT 운영 및 보안 전 영역의 데이터를 보안운영(SecOps) 플랫폼에 통합할 때 궁극적으로 알려지지 않은 위협에 포괄적으로 대비할 수 있다. 아직 SaaS 관제 통합에 대해 완전한 해답을 찾은 조직이나 벤더는 없지만 SaaS 데이터 통합의 필요성에 대한 공동체 인식이 곧 문제 해결의 첫걸음이 될 것이다. [https://www.etnews.com/20220607000249](https://www.etnews.com/20220607000249)

2022-06-09

로그4j 취약점 스캐너 '오픈소스'로 공개했더니 생긴 일

지난해 12월 10일. "컴퓨터 역사상 최악"이라고 평가 받는 보안 취약점이 발견되면서 전 세계 IT 업계에 비상이 걸렸다. 거의 모든 자바 기반 애플리케이션에 사용되고 있는 로깅 라이브러리 로그4j에 공격자가 임의 코드를 실행할 수 있는 치명적인 버그가 확인된 것이다. 신속한 조치가 필요한 긴급상황이지만, 어떤 시스템에 로그4j가 쓰이고 있는지 또 쓰고 있는 버전이 취약한 것인지 아닌지 빠르게 확인하는 일부터 난관이었다. 국내 보안 스타트업 로그프레소의 양봉열 대표도 이런 상황에 주목했다. 그는 취약한 로그4j를 찾아주는 '스캐너'를 밤새 만들어 다음날인 11일 소스코드 저장소 깃허브(☞링크)에 공개했다. 비슷한 기능을 제공하는 스캐너들이 여러개 등장했지만, 로그프레소 스캐너는 그 중에서 가장 높은 신뢰를 받으며 빠르게 확산됐다. 오픈소스 커뮤니티와 실시간 소통하며 200여 개가 넘는 요구사항을 받아, 필요한 기능을 빨리 반영한 것이 통했다. "엔지니어로서 기여하고 싶다"는 생각에서 시작한 일이지만, 이 과정에서 돈으로 살 수 없는 글로벌 브랜드 인지도와 신뢰도를 쌓는 예상 밖의 수확도 얻었다. 로그프레소 로그4j 스캐너는 현재까지 깃허브를 통해 글로벌에서 약 45만 건 다운로드될 만큼 인기를 얻었다. 마이크로소프트, VM웨어, 델, SAS 같은 글로벌 초 대형 IT 벤더들이 로그프레소 스캐너를 보안 권고문에서 추천하고, 더 나아가 자사 제품에 통합하거나 소스코드를 가져다가(포크해) 새로운 제품을 개발한 것은 더 큰 성과다. 국내 소프트웨어 산업 전반이 오픈소스 기여 활동에 소극적이라는 점을 고려했을 때, 로그프레소의 사례는 의미가 있어 보인다. 최근 로그프레소의 양봉열 대표와 구동언 상무를 만나 로그4j 취약점 스캐너 개발기를 들어봤다. -로그프레소의 본업은 무엇인가 구동언 상무(이하 구) "보안과 관련된 데이터 분석이 본업이다. 방화벽 데이터, 개인 정보와 관련된 데이터 등 다양한 데이터를 모으고 분석해 보안에 관한 적절한 의사결정을 내릴 수 있도록 돕는 솔루션을 제공한다. 글로벌 업체와 비교하면 스플렁크와 비슷한 사업 모델이다." -로그4j 스캐너는 어떻게 만들게 됐는지 양봉열 대표(이하 양) "처음에는 로그4j가 워낙 크고 급한 이슈라서 시작했다. 다들 이 문제로 어려움을 겪고 있으니까, 엔지니어적인 마인드로 스캐너를 빠르게 만들어서 도움이 되자는 생각에 만들었다. 취약점 점검으로 돈을 버는 회사는 아니니까 오픈소스 공개에 좀 자유로웠던 것 같다." -로그4j에 버전별로 다양한 취약점이 발견 됐는데, 스캐너는 이를 다 커버하나? 구 "로그4j 전체 버전에 대한 취약점을 확인할 수 있다. 취약점 중에 패치가 나오거나 임시 조치가 가능한 것들은 그것까지 안내하고, 아닌 것들은 정확하게 버전 몇을 쓰고 있어서 문제라고 알려준다." 양 "사실 맨 처음의 코드는 그렇게 복잡하지 않았다. 가장 첫 번째 버전의 코드들을 보면 200줄 정도밖에 안 된다. 이 정도만 해도 취약점을 스캐닝하는 기능들은 충분히 다 수행을 할 수 있었다. 사용자들이 생기면서 요구 사항을 올라와, 그것을 반영하다 보니까 지금은 옵션이 많아졌다. 처음에는 로그4j 2버전에 한 가지 취약점만 진단하게 했었다. 그러다 로그4j 1버전 취약점도 찾아달라, 또 비슷한 로그백이라는 솔루션의 취약점도 찾아달라, Zip 파일 안에 있는 것도 찾아달라, 원래는 지정된 경로를 다 스캔하도록 되어 있는데, 네트워크 드라이브는 제외하고 스캔하게 해달라, 백업이나 복원을 원하는 경로에 하게 해달라, 취약한 버전을 찾았는데 이걸 관리해야 하니까 포팅할 수 있는 수단을 만들어달라 등 이런 요구 사항들이 계속 들어왔다." -공개 후 반응은 어땠나? 양 "처음에는 스캐너를 바이너리 버전(컴파일해서 최종 결과물로 나온 실행파일)만 올려놨다. 그런데 많은 사람들이 소스코드를 오픈을 해달라고 요구하더라. 국내에서는 로그프레소를 검색해 보면 회사 정보를 알 수 있지만, 해외에서는 전혀 알려지지 않았으니까 스캐너를 신뢰하지 못해서였다. 취약점을 찾으려고 스캐너를 다운받았는데, 이게 오히려 악성코드일 수 있다는 생각을 한 것 같다. 그래서 소스코드를 공개하고 오픈소스 커뮤니티와 리뷰를 하는 과정을 많이 거치면서 사람들에게 신뢰 얻고 빠르게 알려진 것 같다. 점점 많이 쓰이니까 글로벌 IT 벤더들이 우리 스캐너를 보안 권고문에 포함하기도 했다. 또 그것을 보고 더 많이 사용자가 유입되는 일들이 벌어졌다. 현재 스캐너 다운로드는 약 45만 건을 기록하고 있다." 구 "마이크로소프트 애저 데이터브릭스, VM웨어, 델, 시스코는 보안권고문에 우리 스캐너를 포함시켰다. SAS는 우리 스캐너를 포크해서 SAS 고객에 맞춘 버전인 '로구치노(loguccino)'를 만들었다. IBM 소트웨어를 인수한 HCL은 우리 제품을 내부에 통합하기도 했다. 소스가 모두 공개돼 있으니까 살펴보고 고객들에게 제공했을 때 리스크가 없겠다고 판단을 한 것 같다." -다른 비슷한 스캐너가 많이 나왔는데, 로그프레소 스캐너가 더 빨리 확산된 이유는 뭐라고 보나 구 "결국 적극적인 피드백이 차별화를 만들었다고 본다. 이용자들도 이 것이 잘 동작하는지 신뢰를 할 수 있어야 하는데, 적극적인 피드백으로 신뢰를 줬다." 양 "이슈 페이지에 보면 한 200개 이상 요구사항이 들어왔다. 12월 한 달 동안은 거의 잠을 못잤다. 해외, 특히 유럽 사용자들이 많다보니까 이슈를 올려준 시간대가 다 한국시간으로는 새벽이고, 대응이 늦어지면 또 사람들이 빠져나갈 것 같아서 빨리 대응하려다 보니까 잠을 거의 못잤다." -생각보다 많은 시간과 노력이 들어갔는데...스캐너를 공개하길 잘했다고 생각하나 구 "어떤 분들은 수백만 달러를 써도 못 할 마케팅을 했다고 말해주기도 하더라. 이런 활동이 당장 매출로 이어지는 것은 아니지만, 기술 회사에 필요한 글로벌 마케팅은 사실 이런 것이라고 본다. 기업에 필요한 것을 만들어서 올리고 사용자들이 피드백을 주고 다시 개선하고 이런 과정들을 공개적으로 다 보여줬다. 그 과정에서 기술력도 검증 받는 효과가 있었다." -로그프레소 스캐너를 오픈소스 프로젝트로 진행하면서 느낀 점이 있다면 양 "지금까지 4~5명 정도가 로그프레소 스캐너 프로젝트에 컨트리뷰트했다. 특정한 기능을 추가해준 것부터 테스트 코드를 보내준 것까지 여러 가지로 기여를 해줬다. 이 과정에서 약간 아쉽게 생각된 부분은 국내 오픈소스 생태계에 대한 부분이다. 오픈소스 기여 활동에 관심이 적어서 아쉽다. 그냥 올려놓은 코드를 테스트만 해줘도 개발자 입장에서는 도움이 많이 된다. 그런데 국내에서는 뭔가 글을 올리는 것 자체도 좀 부담스럽게 생각하는 느낌이다. 지금 깃허브에 올라온 대부분의 이슈들도 다 영어권 사용자들한테 나온 피드백이다. 국내에선 딱 한 건 밖에 없었다." -로그4j 취약점 대응이 장기화 될 것이란 전망이 많은데...어떻게 대응해야 하나 양 "거의 모든 프로그램에 로그4j가 들어가 있다. 전부 다 패치가 이뤄지는지 관리하려면 엄청나게 시간이 소요될 수밖에 없다. 장기간 관리가 필요할 수밖에 없어서, 로그4j 이슈가 오래 갈 것이라고 얘기하는 사람이 많다. 공공기관이나 대기업들 같은 경우는 인프라 관리가 잘 돼 있어 조치가 빨리 이뤄졌지만, 중소기업은 버그 식별조차 안 된 경우가 많다. 또 대기업이나 공공기관이라고 할지라도 인터넷 서비스에 있는 로그4j는 찾아서 막아 놨지만, 내부 시스템에 있는 것들은 아직 다 처리하지 않았을 가능성이 많다. 공격자가 다른 취약점을 타고 내부로 들어오게 되면 내부에서 쓰는 로그4j 애플리케이션들이 굉장한 위험요소가 될 수 있다. 그래서 취약점을 완벽하게 박멸하는 게 중요하다. 우리가 계속적으로 로그4j를 추적하고 모니터링할 수 있도록 '로그4j 워치 서비스'를 내놓은 이유이기도 하다." 구 "로그4j 워치는 스캔 후 리포트까지 받아볼 수 있게 만든 클라우드 서비스다. 기업이 로그4j 사태에 대응하려면, 스캔한 내용을 정리한 리포트도 필요하다. 그런 부분을 워치 서비스가 제공해준다. 10대까지는 무료 플랜으로 제공한다. 그 이상으로 점검이 필요한 경우에는 별도로 협의를 하고 있는데, 그렇다고 많은 비용을 받는 것은 아니다. 공익적인 차원에서 운영하는 측면이 더 크다. 지금은 로그4j와 관련해 큰 불은 어느정도 껐고, 잔불이 좀 남아 있는 상태라고 보면 될 거 같다. 이 잔불이 어떤 형태로든 기업의 보안에 영향을 줄 수 있기 때문에 주의해야 한다. 지금도 자동화된 로그4j 공격 패킷이 돌아다니고 있다. 누구라도 하나만 걸려라라는 식으로 이미 알려진 취약점을 가지고 공격을 한다. 이런 공격은 항상 돌아다니기 때문에 취약점을 방어해야 한다. 결국 이 문제 해결하려면 안전한 버전으로 업데이트하고 패치를 해야 한다. 그렇게 하려면 작동하는 시스템이 취약한 오픈소스 버전을 쓰고 있는지 아닌지를 알 수 있어야 한다." 임유경 기자lyk@zdnet.co.kr [https://zdnet.co.kr/view/?no=20220413113217](https://zdnet.co.kr/view/?no=20220413113217)

2022-04-13