Offcanvas
Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.
Offcanvas
1111Some text as placeholder. In real life you can have the elements you have chosen. Like, text, images, lists, etc.

SBOM

주요 SBOM 포맷 SPDX와 사이클론DX의 비교

소프트웨어 자재 명세서(Software Bill of Material, SBOM)는 취약점 관리에서 점차 중요한 역할을 담당하고 있다. 그럼에도 불구하고 아직까지 많은 기업이 SBOM 포맷 간 차이점 같은 기본적인 주제를 이해하려 애쓰고 있다.   SBOM 포맷이란 무엇인가? SBOM 포맷은 SBOM을 생성하기 위한 통합 구조를 정의하고 최종 사용자 또는 고객과 공유하기 위한 표준이며, 소프트웨어의 구성을 다른 툴이 이해할 수 있도록 공통의 형식으로 설명한다. 주요 SBOM 포맷은 SPDX(Software Package Data Exchange), SWID 태그(Software Identification Tags), 사이클론DX(CycloneDX)가 대표적이다. 이중 SPDX와 사이클론DX만이 보안 사용례로 채택되고 있다. SWID는 주로 라이선스에 중점을 두고 있기 때문에 이번 논의 대상에서 제외된다. 미국 사이버보안 및 인프라 보안국(Cybersecurity and Infrastructure Security Agency, CISA)과 기타 기관이 언급한 것처럼 당분간 업계에는 여러 가지 SBOM 포맷이 혼재할 것이다.  SPDX 리눅스 재단에서 운영하는 프로젝트인 SPDX는 공유 및 수집을 위한 소프트웨어 패키지와 관련된 정보에 대해 공통 데이터 교환 포맷을 만드는 것이 목적이었다. SPDX는 주요 SBOM 포맷 중에서 가장 많은 파일 형식을 지원한다. RDFa, .xlsx, .spdx, .xml, .json, .yaml.가 포함된다. 또한 SPDX는 일련의 소프트웨어 패키지, 파일 또는 스니펫(Snippet)을 설명함으로써 동적 사양이 되는 것을 목표로 하고 있다. SPDX는 국제 표준화 기구(ISO)의 인증 자격을 취득한 유일한 SBOM 포맷이다. ISO에서 정의한 표준화 및 품질 보증 요건을 모두 충족함을 의미한다. 2021년 9월에 발표된 ISO 인증 소식과 함께 리눅스 재단은 SPDX 커뮤니티에 속하는 인텔, 마이크로...

SBOM SPDX 사이클론DX 3일 전

마이크로소프트의 오픈소스 SBOM 생성기 살펴보기

솔라윈즈(SolarWinds) 해킹 사건 이후, 기업은 CI/CD를 도입하는 과정에서 확인해야 할 것이 많아졌다. 사용자에게 배포하는 소프트웨어를 의도한 대로 구축하려면 어떻게 해야 하는가? 코드의 의존성이 모두 원하는 형태로 나타났는가? 서드파티 모듈을 사용하면 기대한 결과를 얻을 수 있는가? 같은 질문을 던져야 하는 것이다.    겹겹이 쌓인 코드와 의존성으로 시스템은 점점 복잡해지고 있다. 거기다 현대 시대의 개발자는 공개된 소스코드를 활용한다. 남이 만든 코드이지만 사람들은 그 소스코드를 있는 그대로 신뢰한다. 하이퍼텍스트라는 용어를 고안한 걸로 유명한 옥스포드대 교수 테드 넬슨의 표현처럼, 모든 기술이 이제 서로 심층적으로 얽히고설켜 있는 것이다. 이때 소스코드의 신뢰를 확인하기 위한 방안으로 SBOM이 떠오르고 있다.    SBOM이 필요한 이유 솔라윈즈 해킹 사건이 일어난 후 미국 행정부는 국가 사이버 보안을 높이겠다는 행정명령을 따로 발표하고 미 국립 표준기술연구소(National Institute of Standards and Technology)에게 관련 지침을 개발 및 배포하라고 지시했다. 해당 지침은 소프트웨어 공급망, 모듈 네트워크, 코드 개발에 사용되는 구성요소의 보안을 강화하는 방안을 골자로 하고 있으며, 현재 외부에 공개된 상태다. 이 문서는 기업에게 코드와 함께 소프트웨어 명세서(Software Bill of Material, SBOM)를 함께 제시하라고 요청하고 있다.  사실 SBOM은 새로운 것이 아니다. 마이크로소프트를 포함한 많은 기업이 기술 상세 정보를 사용자에게 제공하고 있었다. 대신 표준화된 문서는 없었으며, 기업마다 그 구조가 다 달랐고, 기계가 판독할 수 없는 형태이기도 했다. 그래서 마이크로소프트는 SBOM 스키마 표준을 개발하기 CISQ(Consortium for Information and Software Quality)라는 그룹과 협력했다. 미 정부가 SBO...

SBOM 오픈소스 2022.08.01

"선택 아닌 필수" SBOM을 작성하는 베스트 프랙티스와 추천 프로그램 8선

소프트웨어를 실제로 보호하려면 코드 안에 무엇이 있는지 알아야 한다. 그렇기 때문에 오늘날 소프트웨어 자재 명세서(Software Bill of Material, SBOM)는 필수적이다. 과거에는 코드 보안에 대해 크게 걱정하지 않았다. 어리석은 일이었다.   그리고 보안 문제가 잇따라 발생했다. 솔라윈즈 소프트웨어 공급망 공격, 여전히 진행 중인 Log4j 취약점 및 npm 메인테이너 항의 코드가 잘못된 사건으로 보안 업계는 소프트웨어 공급망을 정리해야 한다는 사실을 분명히 깨달았다. 독점 소프트웨어는 제작자가 프로그램 내부에 무엇이 있는지 알려주지 않으므로 불가능하다. 그러나 오픈소스 프로그램을 사용하면 SBOM(s-bomb으로 발음됨)으로 정리할 수 있다. 사실 SBOM은 더 이상 ‘하면 좋은 것’이 아니다. 미국에서는 연방정부의 명령이다. 미국 대통령 조 바이든이 2021년 7월 12일 발표한 ‘국가 사이버보안 개선에 관한 행정명령’에서는 SBOM이 요구사항에 포함된다. 행정명령은 SBOM을 ‘소프트웨어 구축에 사용되는 다양한 구성요소의 세부 사항 및 공급망 관계를 포함하는 공식 기록’으로 정의한다. ‘소프트웨어 개발자와 공급업체는 종종 기존 오픈소스 및 상용 소프트웨어 구성요소를 조립하여 제품을 만드는 경우가 많다’는 점 때문에 오픈소스 소프트웨어에서 특히 중요한 문제다. 그렇다. 오픈소스 소프트웨어가 모든 곳에서, 모든 것을 위해 사용된다는 것은 모두가 안다. 하지만 오픈소스 구성요소를 포함한 애플리케이션이 무려 92%에 달한다는 사실을 알고 있었는가? 사실 평균적인 현대 프로그램은 70%가 오픈소스 소프트웨어로 구성되어 있다.  분명히 조치가 필요하다. 리눅스 재단과 오픈소스 보안 재단(Open Source Security Foundation, OpenSSF), 오픈체인(OpenChain)에 따르면 정답은 SBOM이다. 리눅스 재단의 연구 담당 부사장 스티븐 헨드릭은 SBOM을 다음과 같이 정의한다.   ...

SBOM 추천 오픈소스 2022.07.27

소프트웨어 세계의 자재 명세서, SBOM이 필요한 이유

SBOM은 소프트웨어 제품의 구성요소를 세부적으로 알려줄 뿐만 아니라 각 구성요소의 공급망 관계도 보여주는 공식적이고 체계적인 기록이다. SBOM에는 애플리케이션에 포함된 패키지와 라이브러리, 해당 패키지와 라이브러리 간의 관계, 기타 업스트림 프로젝트가 기술된다. 재사용되는 코드 및 오픈소스와 관련해서는 특히 더 중요하다.   자동차의 자재 명세서 개념에는 많이들 익숙할 것이다. 자재 명세서에는 자동차가 움직이기 위해 필요한 모든 구성요소가 매우 세부적으로 기술된다. 자동차 공급망은 복잡하기로 악명이 높고, 도요타나 제너럴 모터스가 조립하는 자동차라 해도 그 구성 부품의 상당수는 전 세계에 분포한 하도급 업체에서 제조된다. 자재 명세서는 이와 같은 각 부품이 어디에서 왔는지를 알려준다. 이 정보는 단순한 흥미거리가 아니다. 예를 들어 특정 생산 주기의 에어백이 리콜되는 경우 자동차 제조업체는 그 에어백의 제조 출처를 빠르게 알아낼 방법이 필요하다.   소프트웨어 만들기와 자동차 제조는 분명 다르지만 컨테이너화된 분산 애플리케이션 구축하기 위해 외부 오픈소스 라이브러리를 사용하는 사례가 증가하고 있는 만큼 두 프로세스에는 생각보다 공통점이 많다. 그래서 SBOM이 갈수록 더 보편화되고 있는 것이다.   개발자와 사용자 모두 SBOM을 사용해서 자신이 배포하거나 사용하는 소프트웨어에 정확히 어떤 구성요소가 포함되는지 알 수 있다. 여기엔 특히 보안과 관련해서 여러 중요한 의미가 있다.   왜 SBOM이 필요한가? 모놀리식 사유 소프트웨어 코드베이스의 시대는 오래 전에 끝났다. 현대 애플리케이션은 광범위한 코드 재사용을 기반으로 오픈소스 라이브러리를 사용해서 구축되는 경우가 많다. 또한 이러한 애플리케이션은 필요한 요소를 모두 갖춘 작은 기능적 구성요소인 컨테이너로 분할되는 추세다. 컨테이너는 쿠버네티스와 같은 컨테이너 오케스트레이션 플랫폼으로 관리되며 로컬 또는 클라우드에서 실행된다.   이러한 변화는 전체적으로 ...

SBOM SCA 2022.07.21

OT 기기 취약점 대량 발견 "표준 인증도 소용없어"…포어스카우트

최근 한 조사에 따르 10곳의 업체가 만든 운영 기술(Operational Technology, OT) 기기에서 56가지의 결함이 드러났다. 모두 프로그래밍 오류가 아니라 안전하지 않게 설계되거나 구현된 기능이 원인이었다. 지난 10년 동안 보안 연구자와 악의적 공격자의 OT 기기에 대한 관심이 증가했음에도 불구하고, 업계가 아직도 근본적인 ‘설계부터 안전을 고려한 보안 내재화(secure-by-design)’ 원리를 준수하지 않고 있음이 극명하게 드러난 것이다.  는 최신 보고서에서 “공격자가 취약점을 악용하면서 표적 OT 기기에 네트워크를 통해 액세스한 후 코드를 실행하거나, OT 기기의 로직, 파일, 펌웨어를 변경하고 인증을 우회하며, 인증 정보를 훼손하고 서비스 거부를 유발하는 등 다양한 악영향을 미칠 수 있다”라고 밝혔다.   통칭 ‘OT:ICEFALL’으로 알려진 이 보안 문제는 불안전한 엔지니어링 프로토콜, 부실한 암호 구현 또는 파손된 인증 체계, 안전하지 않은 펌웨어 업데이트 메커니즘, 그리고 원격 코드 실행으로 악용될 수 있는 부실한 네이티브 기능에 기인한다. 실제로 공개된 취약점 중 14%는 원격 코드 실행으로, 21%는 펌웨어 조작으로 이어질 수 있다.    이 연구에서 밝혀진 또 다른 흥미로운 사실은 취약 기기 대부분이 OT 환경에 적용되는 각종 표준에 따라 인증을 받았다는 점이다. 예를 들어 IEC62433, NERC CIP, NIST SP 800-82, IEC 51408/CC, IEC62351, DNP2 시큐리티, 모드버스 시큐리티 (Modbus Security) 등이다.  보고서는 “이들 표준이 주도한 견실화 노력은 분명 보안 프로그램 개발, 위험 관리, 그리고 아키텍처 수준 설계 및 통합 활동에서의 큰 개선에 기여했으나, 개별 시스템 및 컴포넌트의 보안 개발 수명주기를 성숙시키는 데는 미흡했다”라고 결론지었다.    OT의 ‘보안 비내재화’ 역사&nb...

OT 운영기술 보안내재화 2022.06.24

소프트웨어 보안의 필수품 '서드파티 라이브러리 목록'

웨스 웰스가 이끄는 인스턴트 커넥트 소프트웨어(Instant Connect Software) 팀은 오래전부터 무엇보다 보안을 중요시해왔다. 인스턴트 커넥트 소프트웨어는 LTE, 5G, MANET을 포함한 다양한 사설 및 공용 네트워크를 통해 모바일, IP, 라디오, 전화 디바이스를 연결하는 푸시-투-토크(push-to-talk) 음성 커뮤니케이션, 그리고 그것을 구현하는 커뮤니케이션 소프트웨어 개발업체이며, 웰스는 이 업체의 최고 제품 책임자다. 인스턴트 커넥트 소프트웨어는 최전선 실무 팀에 필요한 연결을 구현한다. 주 고객은 전 세계의 정부와 군사 기관이다. 석유 및 가스, 광산, 제조, 물류 분야의 사기업 역시 이 소프트웨어를 사용해 핵심 작업을 지원한다.   웰스는 고객의 특성상 소프트웨어가 “모든 면에서 안전해야 한다”라고 말했다.   웰스는 “고급 암호화 표준(AES)과 전송 계층 보안(TLS)을 포함한 제품 보안 전략으로 모든 부분이 안전하게 보호되며 완전히 암호화된다”라고 말했다.   인스턴트 커넥트는 연방 정보 처리 표준(FIPS) 140-2에 명시된 암호화 모듈에 대한 미국 정부의 컴퓨터 보안 표준을 준수한다. 인스턴트 커넥트 알고리즘에 대한 NIST 인증은 FIPS 표준을 충족 또는 초과 충족한다는 것을 입증한다.   웰스는 정부 및 군 기관을 고객으로 두려면 이러한 요건을 모두 갖추어야 한다고 말했다.   또한 인스턴트 커넥트 소프트웨어 제품에 사용되는 모든 서드파티 라이브러리 목록(소프트웨어 명세서, SBOM)도 고객에 제공해야 한다.   개선 기회 인스턴트 커넥트는 보안에 전념하면서 오랜 기간 정부 기관을 대상으로 보안 역량을 입증해왔지만, 웰스는 서드파티 라이브러리를 세분화해서 추적하고 취약점을 검토하는 점에서 개선의 여지가 있었다고 말했다.   웰스는 “과거에는 우리가 사용하는 라이브러리, 각 릴리스에 사용된 라이브러리의 버전을 수동으로 추적해야 했다. 이 자료를 ...

SBOM 소프트웨어명세서 서드파티라이브러리목록 2022.06.21

“로그4j 그 이후를 말한다" 오픈소스 보안의 중요성 강조…베라코드 CTO

美 애플리케이션 보안 전문 기업 베라코드(Veracode)의 CTO가 로그4j 취약점의 여파, 오픈소스 보안 문제 인식을 높이는 방법 등을 조언했다. 지난 2021년 12월 초 수백만 개의 애플리케이션에서 사용되는 오픈소스 자바 구성요소 ‘로그4j’에서 일련의 취약점이 발견되면서 전 세계의 기업 보안 부서는 비상 경계 태세에 돌입해야 했다.    로그4j는 미국 사이버 보안 및 인프라 보안국(CISA; Cybersecurity and Infrastructure Security Agency)을 비롯해 다른 국가의 CERT(Computer Emergency Response Team)에서도 경고했을 만큼 큰 사건이었으며, 아울러 보안 및 오픈소스 소프트웨어 생태계, 개발자가 오픈소스 구성요소를 사용하고 추적하는 방법에 관한 새로운 논의를 촉발했다.  애플리케이션 보안 업체인 베라코드의 설립자 겸 CTO이자 애플리케이션 보안 및 취약점 분야에서 20년 이상의 경력을 갖춘 보안 업계 베테랑인 크리스 위소팔과 ‘로그4j 취약점의 여파와 오픈소스 보안의 미래’를 주제로 나눈 대화를 정리했다. ‘로그4j’의 중요성과 여파 “로그4j는 ‘광범위하게 사용돼 거의 모든 서버에 영향을 미칠 수 있다는 점에서’ 개발팀이 일상적으로 다루는 것과는 확실히 다른 유형의 취약점이었다. 거의 모든 기업에 영향을 미쳤고, 모든 기업의 여러 개발 부서, 즉 회사를 위해 새로운 일을 하는 부서와 1년에 한 번 정도 코드를 변경하는 유지관리 모드로 운영되던 부서를 강타했다.”  “베라코드는 SaaS 업체이기 때문에 모든 고객을 살펴볼 수 있다. 작년에 스캔한 수십만 개의 애플리케이션 중에서 특히 기업 고객을 관심 있게 살펴봤다. 95%의 기업 고객이 자바를 쓰고 있어 자바의 인기를 알 수 있다. 만약 자바에 이와 같은 취약점이 또 있다면 그 역시 널리 퍼질 것이다.” “아울러 88%는 로그4j를 사용하고, 58%는 취약한 버전을 쓴다고 답했다. 그래서...

오픈소스 로그4j 보안 취약점 2022.05.27

소프트웨어 공급망 공격 증가세, "SBOM이 필수 대응책"

런타임 보안 업체 앵코어(Anchore)의 최근 연구에 따르면, 작년 기업 5곳 중 3곳 이상이 소프트웨어 공급망 공격의 표적이 됐다. 앵코어는 IT와 보안, 개발, 데브옵스 부문에 종사하는 경영진과 팀장, 관리자 428명을 대상으로 설문조사를 실시했다. 이들 중 약 3분의 1, 즉 30%가 작년에 상당한, 혹은 중간 규모의 소프트웨어 공급망 공격을 받았다고 답했다. 자사 소프트웨어 공급망에 큰 타격이 없었다고 답한 비율은 겨우 6%에 불과했다. 앵코어는 작년 12월 3일부터 12월 30일까지 이 조사를 실시했으며, 아파치 로그4j 유틸리티에서 발견된 취약점을 공격 범주에 포함했다. 로그4j는 작년 12월 9일에 등장했으며, 응답자의 55%가 이전에도 소프트웨어 공급망 공격을 받은 적이 있다고 밝혔다. 수치는 로그4j가 나온 이후 65%로 급격히 올랐다. 앵코어 수석 부사장인 킴 웨인스는 “로그4j가 나오기 전에 공급망 공격을 한 번도 경험하지 않은 기업도 있는 반면, 그 전부터 공격을 받았고 로그4j가 출시된 후 더욱 막대한 피해를 입은 기업도 있다”라고 설명했다.   소프트웨어 공급망 공격에 심각한 타격을 받는 IT 업체 또한, 이번 조사에서 소프트웨어 공급망 공격을 경험한 IT 업체의 비율은 15%이며 타 산업군의 경우 3%인 것으로 나타났다. IT 업체가 다른 업계에 비해 소프트웨어 공급망 공격의 영향을 훨씬 더 크게 받는다는 것을 알 수 있다. 웨인스는 “공격자가 침투한 소프트웨어가 수천 명의 사용자에게 배포되면 수천 곳의 각 다른 기업에 공격을 위한 기반이 형성된다”라고 경고했다. 많은 기업이 공급망 보안에도 중점을 두는 것으로 나타났다. 응답자 중 54%는 공급망 보안을 최상위, 혹은 상당히 중요한 분야로 꼽았다. 컨테이너를 많이 사용하는 기업일수록 공급망 보안에 대한 관심도는 훨씬 더 높았으며, 이들의 70%가 공급망 보안을 최우선순위로 고려해야 한다고 답했다. 웨인스는 “주의를 기울여야 할 의존성의 수는 컨테이너와 클라...

소프트웨어공급망공격 SBOM 2022.02.15

글로벌 칼럼 | ‘선택 아닌 필수’ SBOM 관리의 중요성

많은 기업에서 Log4j에서 발견된 Log4Shell 취약점이 미치는 영향을 파악하고 문제를 해결하기 위해 분주히 움직이고 있다. Log4Shell 취약점은 보편적으로 사용하는 라이브러리에서 발견되어 악용이 쉽기 때문에 특히 위험하다. 중요한 것은 Log4j 취약점 정보가 자세히 공개되기 전에 이미 많은 공격이 진행됐다는 사실이다. 따라서 Log4j 취약점 대응은 시간 싸움이며, SBOM(Software Bill of Materials)을 생성해 정보를 신속하게 제공하는 것이 소프트웨어 공급망 취약점 공격 대응에 필수적인 요소가 됐다.   일반적으로 보안팀과 개발팀은 취약점 문제를 해결한 후에 해결책을 다시 검토한다. 취약점은 미래에도 계속 발견될 것이 분명하므로, 더욱 잘 대비하는 방법을 찾아야 하기 때문이다. 이런 환경에서 SBOM은 다양한 소프트웨어를 사용하는 기업이 공급망 가시성을 확보하는 데 필수 요소가 됐다. 이제 기업은 ‘SBOM 관리’라는 새로운 역량을 갖추어야 한다. 포괄적인 SBOM 생성하기 현재까지 업계에서 가장 많이 사용하는 SBOM 관리 방법은 애플리케이션을 출시하거나 배포할 때마다 SBOM을 만드는 것이다. 최근 미국 사이버보안 개선에 관한 행정 명령에 따르면, 소프트웨어 서비스 업체는 미국 연방 기관에 판매하거나 제공하는 소프트웨어에 대한 SBOM을 제출해야 한다. 시각을 넓혀서 바라본다면 SBOM 생성은 첫걸음일 뿐이다. Log4j 취약점으로 인해 우리는 새로운 제로데이 공격이 발생할 때 즉시 활용할 수 있는 SBOM의 필요성을 깨달았다. SBOM 제작은 쉽지만, 수백 개에서 수천 개에 달하는 SBOM을 관리하는 것은 그렇지 않다. SBOM 관리 역량을 갖추는 것은 변화하는 위협 환경에 대처하는 어려운 요구사항이다.  물론 오늘날에는 애플리케이션을 배포하기 전 취약점을 검사하는 것이 관행이다. 하지만 이런 검사만으로 충분하지 않다. 앱 구성 요소를 점검하고 취약점을 감지하는 활동은 앱 사용 중에도 정기적으...

SBOM log4j log4shell 2021.12.22

글로벌 칼럼 | "SaaS BOM 가능할까", 고객 관점의 BOM 필요

미국 바이든 대통령이 발표한 '국가 사이버보안 강화에 대한 행정 명령(Executive Order)'은 SBOM(Software Bill of Material)과 관련해 엄청난 반향을 일으켰다. 보안 전문가들은 관련 구성요소의 투명성을 높이는 방법으로 소프트웨어 공급망 보안을 강화하는 방안은 지지하지만, SBOM의 과대 광고와 이행과 관련된 일련의 문제들을 해결하기 위한 방향과 지침이 필요하다고 주장한다.   소비자가 SBOM을 수령한 뒤에 이를 어떻게 처리할지에 대한 해답이 미흡한 것은 물론이고, SaaS처럼 공급업체 관리형 배포 모델을 대상으로 이를 개발할 방법이 명확하지 않다. 특히 업계 어디서나 SaaS를 활용하고 있기 때문에, 이런 모호한 부분들은 위험 관리 도구로 SBOM을 효과적으로 사용하는 것을 방해한다. SaaS BOM 프레임워크 이 도전과제를 해결하는 방편으로 SaaS의 BOM이 어떻게 해야 하는지 보여주는 프레임워크를 제안한다. 이런 문서의 구성요소를 설명하면 여러 주장이 나올 수 있다. 특정 SaaS 제품에서 소프트웨어의 정확한 의미를 합의하는 것조차 어려운 일이기 때문이다. 공급업체로부터 결과물을 받을 때, 이를 내부에 둘 계획을 세우는 고객은 자신이 다운로드 받은 것을 정확히 파악해 여기에 맞게 추적할 수 있다. 하지만 SaaS를 사용한다면 이런 확신은 거의 불가능하다. 예를 들어, ‘소프트웨어’에 제품이 실행되는 클라우드 서비스 공급업체의 IaaS나 PaaS가 포함되어 있는가? 공급업체가 배포 운영 및 유지관리에 이용하는 앤서블(Ansible), 셰프(Chef), 테라폼(Terraform) 같은 도구는 어떠한가? SSO(Single Sign-On)를 통해 접근할 수 있는 CI/CD(Continuous Integration/Continuous Delivery) 파이프라인의 구성요소는? 앞서 언급한 SSO 기능을 촉진하는 기업의 ID 공급업체와 연결되는 HR 시스템은? 완벽한 회계가 가능하더라도, 매일, 또는 분...

SaaS BOM SBOM BOM 2021.09.14

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.