Study on security requirements for the web based operation system of a shipping company

웹 기반 해운 선사 운영시스템 보안 요구사항 연구

Abstract

The operation system of a shipping company is still maintaining the mainframe based terminal access environment or the client/server based environment. Nowadays shipping companies that try to migrate it into a web-based environment are increasing. However, in the transition, if the design is processed by the old configuration and knowledge without considering the characteristics of the web-based environment and shipping business, various security vulnerabilities will be revealed at the actual system operation stage, and system maintenance costs to fix them will increase significantly. Therefore, in the transition to a web-based environment, a security design must be carried out from the design stage to ensure system safety and to reduce security-related maintenance costs in the future. This paper examines the characteristics of various threat modeling techniques, selects suitable modeling technique for the operation system of a shipping company, applies data flow diagram and STRIDE threat modeling technique to shipping business, derives possible security threats from each component of the data flow diagram in the attacker's point of view, validates the derived threats by mapping them with attack library items, represents the attack tree having various attack scenarios that attackers can attempt to achieve their final goals, organizes into the checklist that has security check items, associated threats and security requirements, and finally presents 23 security requirements that can respond to threats. Unlike the existing general security requirements, the security requirements presented in this paper reflect the characteristics of shipping business because they are derived by analyzing the actual business of a shipping company and applying threat modeling technique. Therefore, I think that the presented security requirements will be of great help in the security design of shipping companies that are trying to proceed with the transition to a web-based environment in the future.

해운 선사의 운영시스템은 주전산기를 이용한 단말기 접속 환경 또는 클라이언트/서버 구조의 환경을 유지하고 있는 경우가 아직 많으며, 웹서버 및 웹 애플리케이션 서버를 이용한 웹 기반 환경으로의 전환을 고려하는 해운 선사가 증가하고 있다. 그런데 전환 과정에서, 기존 구성 방식과 지식을 바탕으로 웹 기반 환경의 특성 및 해운 업무의 특성을 고려하지 않고 설계를 진행하는 경우, 다양한 보안상 취약점이 실제 시스템 운영 단계에서 드러나게 되고, 이는 시스템 유지보수 비용의 증가를 초래하게 된다. 그러므로 웹 기반 환경으로의 전환 시에는, 시스템 안전성 확보 및 보안 관련 유지보수 비용 절감을 위해 설계 단계에서부터 반드시 보안을 고려한 설계가 진행되어야 한다. 본 논문에서는 다양한 위협 모델링 기법의 특성을 살펴보고, 해운 선사 운영시스템에 적합한 모델링 기법을 선정한 후, 데이터 흐름도와 STRIDE 위협 모델링 기법을 해운 선사 업무에 적용하여, 데이터 흐름도의 각 구성 요소에서 발생 가능한 보안 위협을 공격자 관점에서 도출하고, 공격 라이브러리 항목과의 매핑을 통해 도출된 위협의 타당성을 입증한다. 그리고, 이를 이용하여 공격자가 최종목표 달성을 위해 시도할 수 있는 다양한 공격 시나리오를 공격 트리로 나타내고, 보안 점검 사항과 관련 위협 및 보안 요구사항을 체크리스트로 구성한 후, 최종적으로 도출된 위협에 대응할 수 있는 23개의 보안 요구사항을 제시한다. 기존의 일반적인 보안 요구사항과는 달리, 본 논문에서 제시하는 보안 요구사항은 해운 선사의 실제 업무를 분석한 후, 여기에 위협 모델링 기법을 적용하여 도출된 해운 업무 특성을 반영한 보안 요구사항이므로, 추후 웹 기반 환경으로의 전환을 추진하는 해운 선사들의 보안 설계에 많은 도움이 될 것으로 생각한다.

1. 서론

해운 선사의 운영시스템은 주전산기를 이용한 단말기접속 환경 또는 클라이언트/서버 구조의 환경을 유지하고 있는 경우가 아직 많으며, 웹서버 및 웹 애플리케이션 서버(web application server, WAS)를 이용한 웹 기반 환경으로의 전환을 고려하는 해운 선사가 증가하고 있다.

그런데 전환 과정에서, 기존 구성 방식과 지식을 바탕으로 웹 기반 환경의 특성 및 해운 업무의 특성을 고려하지 않고 설계를 진행하는 경우, 다양한 보안상 취약점이 실제 시스템 운영 단계에서 드러나게 되고, 이는 시스템 유지보수 비용의 증가를 초래하게 된다. 그러므로, 웹 기반 환경으로의 전환 시에는, 시스템 안전성 확보 및 보안 관련 유지보수 비용 절감을 위해 설계 단계에서부터 반드시 보안을 고려한 설계가 진행되어야 한다.

본 논문에서는, 다양한 위협 모델링 기법의 특성을 살펴보고, 해운 선사 운영시스템에 적합한 모델링 기법을 선정한 후, 데이터 흐름도(data flow diagram, DFD)와 STRIDE 위협 모델링 기법을 해운 선사 업무에 적용하여, 데이터 흐름도의 각 구성 요소에서 발생 가능한 보안 위협을 공격자 관점에서 도출하고, 공격 라이브러리 항목과의 매핑을 통해 도출된 위협의 타당성을 입증한다. 그리고, 이를 이용하여 공격자가 최종목표 달성을 위해 시도할 수 있는 다양한 공격 시나리오를 공격 트리로 나타내고, 보안 점검 사항과 관련 위협 및 보안 요구사항을 체크리스트로 구성한 후, 최종적으로 도출된 위협에 대응할 수 있는 웹 기반 해운 선사 운영시스템의 설계 단계에서 고려해야 하는 23개의 보안 요구사항을 제시한다.

해운 선사의 운영시스템은 선하증권(bill of lading) 과같은 유가 증권의 발행, 운임의 수금, 선박 운항, 세관 신고, 유류 대금 지급, 대화주 서비스 제공 등 기업의 영업, 운영, 회계, 재정 전반에 걸친 광범위한 부분을 지원하고있으므로, 모든 부분에 대한 위협 모델링을 진행하기에는 분석 범위가 너무 넓어 어려움이 있다. 따라서, 모든 해운 선사에서 공통으로 구현하여야 하는 핵심 기능에 대한 위협 모델링을 진행하며, 이 기능은 해운 업무에서 가장 중심이 되는 선적 서류와 관련된 부분으로서 선적요청서(shipping request), 선하증권(bill of lading), 송장 (invoice), 송금(remittance), 화물도착통지서(arrival notice), 화물인도지시서(delivery order), 적하목록(manifest), 화물추적(cargo tracking) 등에 대한 관리 업무를 의미한다. 또한, 정보기술 인프라(IT infrastructure) 측면에서는, 클라이언트는 웹브라우저를 이용하여 시스템에 접속하고, 서버는 Unix 또는 Linux 기반의 웹서버 및 WAS 환경에서 서비스를 제공한다는 가정하에 위협 모델링을 진행한다.

기존의 일반적인 보안 요구사항과는 달리, 본 논문에서 제시하는 보안 요구사항은 해운 선사의 실제 업무를 분석한 후, 여기에 위협 모델링 기법을 적용하여 도출된 해운 업무 특성을 반영한 보안 요구사항이므로, 추후 웹 기반 환경으로의 전환을 추진하는 해운 선사들의 보안 설계에 많은 도움이 될 것으로 생각한다.

본 논문의 구성은 다음과 같다. 2장에서는 다양한 위협 모델링 기법을 소개하고, 해운 선사 운영시스템에 적합한 위협 모델링 기법을 선정하며, 해운 선사 운영시스템 보안 관련 연구 동향을 설명한다. 3장에서는 STRIDE 위협 모델링의 일반적인 절차를 설명하며, 4장에서는 해운 선사 운영시스템에 위협 모델링을 적용한 단계별 수행 절차 및 결과를 설명하고 체크리스트를 도출하며, 5 장에서는 웹 기반 해운 선사 운영시스템 보안 요구사항을 정의하고, 6장에서는 본 연구의 결론을 기술한다.

2. 관련 연구

2.1 다양한 위협 모델링 기법

위협 모델링은 시스템에 문제를 일으킬 수 있는 다양한 종류의 보안 위협을 구현 단계 이전의 설계 단계에서 식별하고, 시스템에 미치는 영향도를 평가한 후, 중요도에 따라 그것들을 분류하는 기법을 의미한다. 이러한 절차는, 발생 가능한 중요 보안 이슈들을 시스템 개발의 초기 단계에서 식별함으로써 구현 단계에서의 수정사항을 최소화하여 전체 시스템 개발에 필요한 비용을 크게 절감할 수 있게 한다[1].

대표적인 기법으로는, 공격자의 관점에서 보안 위협을 분석하는 STRIDE, 개인정보보호 관점에서 위협을 분석하는 LINDDUN, 위험(risk) 관리 관점에서 위협을 분석하는 Trike, 위험 또는 자산 기반하에 위협을 분석하는 PASTA, 조직 위험 평가 중심의 OCTAVE 등의 위협모델링 기법들이 있다.

2.1.1 STRIDE

STRIDE는 공격자의 관점에서 보안 위협을 검토하고 위장, 변조, 부인, 정보 노출, 서비스 거부, 권한 상승의 6가지 카테고리로 위협을 분류한다. STRIDE는 각 카테고리의 첫 글자를 가져와 만들어진 명칭이며, 그 상세 내용은 다음과 같다.

• 위장(spoofing): 공격자가 다른 사용자로 위장하는 것
• 변조(tempering): 공격자가 데이터 또는 코드 등에 악의적인 변경을 가하는 것
• 부인(repudiation): 공격자가 수행한 행동을 부인하는 것
• 정보 유출(information disclosure): 정보에 접근할 권한이 없는 누군가에게 정보가 노출되는 것
• 서비스 거부(denial of service): 유효한 사용자에게 서비스를 거부하거나 성능이 저하되도록 하는 것
• 권한 상승(elevation of privilege): 적절한 인증 절차 없이 권한을 상승시키는 것

STRIDE를 이용한 위협 모델링에서, 가장 많이 사용되는 방식은 다음의 2가지이다.

• STRIDE-per-Element: 분석하고자 하는 시스템에 대하여 DFD를 작성한 후, DFD에 존재하는 각각의 요소(element) 별로 STRIDE 관점에서 어떤 위협이 발생 가능한지를 점검하는 방법
• STRIDE-per-Interaction: 분석 시스템의 DFD를 작성한 후, 신뢰 경계(trust boundary)를 넘나드는 데이터 흐름에 대해서 STRIDE 관점에서 어떤 위협이 발생 가능한지를 점검하는 방법

STRIDE는 IT 관련 위협에 초점을 맞추어 설계되었으며, 다양한 종류의 보안 위협을 설계 단계에서 식별하여 발생 가능한 위협과 취약점을 분류하는데 효과적인 기법이다. 장점은 쉽게 배우고 실행할 수 있으며 문서화가 잘되어있다는 점이고, 단점은 시스템이 복잡해지면 위협의 수가 급격히 증가한다는 점이다[2, 21, 22, 23].

2.1.2 LINDDUN

LINDDUN는 다음 카테고리들에 대한 위협을 다루며, 그 이름은 각 카테고리의 첫 글자로 만들어진 약어이다.

• 연결성(linkability): 공격자는 데이터 주체의 신원 정보 없이 두 관심 있는 항목을 연결할 수 있다.
• 식별성(identifiability): 공격자는 관심 항목을 통해 데이터 주체들의 집합으로부터 데이터 주체를 식별할 수 있다.
• 부인 방지(non-repudiation): 데이터 주체는 수행한 행위나 송부한 요청에 대해 부인할 수 없다.
• 탐지 가능성(detectability): 공격자는 그 내용 자체를 읽을 수 있는 것과 상관없이, 데이터 주체에 대한 관심 항목의 존재 여부를 구분할 수 있다.
• 정보 유출(disclosure of information): 공격자는 데이터 주체에 대한 관심 항목의 내용을 알 수 있다.
• 비인지(unawareness): 데이터 주체는 데이터 주체의 개인 데이터 수집, 처리, 저장 또는 공유에 대한 활동과 그 목적을 알지 못한다.
• 미준수(non-compliance): 개인 데이터의 처리, 저장 또는 취급이 법률, 규정, 정책을 준수하지 않는다.

LINDDUN은 개인정보에 대한 위협을 체계적으로 도출하고 완화하기 위해 설계된 개인정보 위협 모델링 방법론이며, 구조적인 방법으로 위협 모델링 프로세스를 진행하도록 도움을 준다. 장점은 개인정보보호 지식 지원을 제공하여 개인정보보호 비전문가도 개인정보 위협에 대하여 추론할 수 있도록 지원하는 점과 위협 완화를 위한 우선순위를 지정할 수 있다는 점이고, 단점은 시스템이 복잡해지면 위협의 수가 급격히 증가한다는 점이다 [3, 21, 22, 23].

2.1.3 Trike

Trike는 공격에 대한 대응책이 주어진 공격의 위험에 대해 적절하고 효율적인지 확인하는 것에 주안점을 두고, 다음 4가지 항목을 고려하여 위협 모델을 구성한다.

• 시스템 이해당사자의 도움을 받아, 시스템이 각 자산에 미치는 위험을 모든 이해당사자가 수용할 수 있는지 확인한다.
• 작업의 수행 여부를 말할 수 있게 한다.
• 수행한 작업과 결과를 이해당사자에게 전달한다.
• 이해당사자가 자신의 영역 내에서 자신의 행동이 자신과 다른 이해당사자에게 은연중에 미칠 수 있는 위험을 이해하고 줄일 수 있도록 권한을 준다.

Trike는 위험 관리 관점에서 보안 감사를 진행하기 위해 사용되는 통합된 개념 프레임워크로, 이해당사자의 구성 요소(자산, 역할, 행동, 위험 노출)에 대한 위험 측정에 초점을 둔다. 장점은 위협 완화를 위한 우선순위를 지정할 수 있고, 자동화 도구가 제공된다는 점이고, 단점은 관련 문서가 모호하고 불충분하며, 개발이 완료되지 않고 중단되어 있다는 점이다[4, 21, 22, 23].

2.1.4 PASTA

PASTA는 “Prcess for Attack Simulation & Threat Analysis”의 약어로서, 다음의 특성을 가진다.

• 통합 애플리케이션 위협 분석
• 애플리케이션 위협 모델링 방법론
• 위험 또는 자산 기반 접근 방식
• 비즈니스 통합에 적합

PASTA는 애플리케이션과 비즈니스에 미치는 위협의 영향을 아래의 7단계로 분석한다.

• 비즈니스와 보안 목표를 정의한다.
• 기술적인 범위를 정의한다.
• 애플리케이션을 세분화한다.
• 위협을 분석한다.
• 취약점을 분석한다.
• 공격을 열거하고 모델링을 수행한다.
• 위험과 영향을 분석한다.

PASTA는 위험 중심 방법론에 초점을 맞춘 위협 시뮬레이션 기능을 가진 위협 모델링 프레임워크로, 비즈니스 목표와 기술적 요구사항의 통합을 목표로 한다. 장점은 주요 의사 결정자를 참여시켜 운영, 거버넌스, 아키텍처 및 개발에 대한 보안 입력을 요구함으로써 위협 모델링 프로세스를 전략적 수준으로 끌어올린다는 점과 위협완화를 위한 우선순위를 지정할 수 있다는 점이고, 단점은 많은 시간과 노력이 필요한 광범위한 프로세스를 요구한다는 점이다[5, 21, 22, 23].

2.1.5 OCTAVE

OCTAVE는 “Operationally Critical Threat, Asset, and Vulnerability Evaluation"의 약어이며, 조직이 다음을 수행할 수 있도록 도와준다.

• 조직의 운영 측면의 위험 허용치를 설명하는 질적 위험 평가 기준을 개발한다.
• 조직의 목표에 중요한 자산을 식별한다.
• 해당 자산에 대한 취약점 및 위협을 식별한다.
• 위협이 실현될 경우, 조직에 미치는 잠재적인 영향을 판단하고 평가한다.

OCTAVE는 사이버 보안에 대한 위험 기반 전략 및 계획 평가 방법으로, 조직 위험 평가에 초점을 맞추고, 기술적 위험을 다루지 않는다. 주요 항목은 운영 위험, 보안 관행 및 기술이다. 장점은 위험 관리에 유용하고, 반복적으로 일관된 결과를 얻을 수 있으며, 위협 완화를 위한 우선순위를 지정할 수 있고, 확장 가능하다는 점이고, 단점은 관련 문서가 모호하고 방대하며, 시간이 많이 소요되고, 기술적 위험을 다루지 않는다는 점이다[6, 21, 22, 23].

2.2 해운 선사 운영시스템에 적합한 위협 모델링 기법

해운 선사 운영시스템의 선적 서류에 관련된 부분은 주로 기업 간의 거래와 관련된 정보를 다루기 때문에 개인정보를 거의 포함하지 않는다. 따라서 개인정보보호에 특화된 LINDDUN 기법은 적합하지 않다. 또한, 선적 서류에 대한 해운 선사 공통 기능에 대하여 설계 단계에서 보안 위협을 식별하고자 하는 이번 논문에서, 기업 조직구조 및 중요 자산 등 대상 기업의 상세 정보를 포함하여 분석이 진행되어야 정확한 결과물을 기대할 수 있는 Trike, PASTA, OCTAVE 기법은 적합하지 않다.

따라서 이 연구에서는 다양한 종류의 위협을 설계 단계에서 도출하여 발생 가능한 위협과 취약점을 효율적으로 식별할 수 있는 STRIDE 기법을 이용할 것이며, 상대적으로 오류가 적고 정확한 결과를 도출할 수 있는 STRIDE-per-Element 방식으로 분석을 진행한다.

2.3 해운 선사 운영시스템 보안 관련 연구 동향

해운 선사 운영 시스템 보안 요구사항과 관련된 선행연구는, 항만물류 관련 기업의 정보보호 강화를 위해, 정보보호 관리체계를 구축 및 개선하는 방안에 관한 연구이다. 이 연구에서 주목한 부분은 기술적인 상세 보안 항목이 아닌, 관리 통제 항목에 대한 정의와 정보보호 관리체계 구축 및 개선 방안이다[7].

다른 선행 연구는, 해운물류 보안 시스템 구축에 관련된 연구로서, 이는 시스템 측면이 아닌 컨테이너의 물리적 보안에 관련된 부분이며 radio frequency identification (RFID), 전자봉인 및 X-ray 화물 검색기에 관한 내용을 다루고 있다[8, 9, 10].

선행 연구 조사에서, 해운 선사의 운영시스템에 대하여 위협 모델링 기법을 이용하여 보안 요구사항을 도출한 기존 연구 사례는 찾아볼 수 없었으며, 정책적인 부분 및 물리적인 보안에 관한 연구 사례만이 조사되었다.

3. STRIDE 위협 모델링

STRIDE 위협 모델링은, 먼저 데이터 흐름도(data flow diagram, DFD)를 그려서 분석하려는 시스템의 범위와 자산을 명확히 식별하는 것에서 시작한다. 이후, 실제 발생 가능한 위협을 파악하기 위해 공격 라이브러리 (attack library)를 구성하며, 이는 공격자 전술/기술 지식 베이스, 취약점 분류 프로젝트, 취약점 데이터베이스, 보안 표준 인식 문서 등 다양한 소스에서 실제 위협을 수집하여 구성한다.

다음으로, STRIDE 기법을 이용하여 DFD의 각 구성요소에서 발생할 수 있는 위협을 공격자 관점에서 검토하여 열거하고, 공격 라이브러리 항목과 매핑하여 도출된 위협의 타당성을 입증한다. 그리고, STRIDE에서 도출된 위협과 공격 라이브러리의 항목을 조합하여, 어떠한 위협을 이용하여 공격이 이루어지고 이를 통해 어떻게 공격자가 최종목표에 도달하는지에 대한 다양한 공격시나리오를 표현한 공격 트리(attack tree)를 작성한다.

공격 트리에 포함된 공격 시나리오에 대하여 DREAD 기법을 사용하여 위험도를 산정하는 것이 가능하나[2], 이는 주관적인 산정이 될 수 있고 잘못된 결과를 도출할 수 있어 추천되지 않으므로 생략한다[1]. 마지막으로, 위에서 도출된 위협에 대하여 점검할 사항은 무엇이고, 연관된 위협은 어떠한 것들이 있으며, 이러한 위협에 대응하는 보안 요구사항은 무엇인지를 체크리스트로 표현한다[1, 2].

3.1 DFD

위협 모델링의 시작은, 분석하고자 하는 시스템의 범위를 정하고 지켜야 할 자산을 명확히 식별하기 위해서 시스템을 추상화하여 실제 필요한 정보가 잘 드러나도록 도식화하는 것이다. 이를 위해 DFD를 구성하여, 시스템의 범위와 자산을 확인하고 데이터 흐름을 파악하여 위협이 발생할 수 있는 부분을 정확히 식별하여야 한다. DFD를 구성할 때는, 하향식으로 접근하여야 하며, 전체 시스템을 한눈에 볼 수 있도록 작성하는 가장 상위수준인 배경도 (context diagram)에서 시작하여 점차 세부적인 상세 항목을 표현하는 Level 1 diagram과 Level 2 diagram을 작성한다.

3.2 공격 라이브러리(attack library)

공격 라이브러리는 현재 분석 중인 시스템에서 발생 가능한 위협을 모아 놓은 리스트이며, 시스템에 대한 위협을 찾는데 유용한 도구로 사용된다[1]. 이러한 공격라이브러리는 취약점 분류 프로젝트, 취약점 데이터베이스, 논문, 컨퍼런스, 기술보고서, 표준 문서 등 다양한 소스로부터 알려진 위협 항목을 수집하여 구성한다.

다음 단계에서 진행되는 STRIDE에 의해 도출되는 위협은 매우 추상적이므로 발생 가능한 구체적 위협에 대해 공격 시나리오를 작성하는 공격 트리(attack tree)를작성하기에는 무리가 있다. 따라서 STRIDE를 이용한 DFD 구성 요소별 위협 도출 후, 이를 공격 라이브러리의 항목과 매핑하여 구체화하는 과정이 필요하며, 이 과정을 통해 도출된 위협의 타당성을 검증할 수 있다.

3.3 STRIDE

STRIDE-per-Element 방식을 이용하여, DFD에서 도출된 구성 요소들에 대하여 공격자의 관점에서 발생 가능한 보안 위협을 검토하고 위장, 변조, 부인, 정보 노출, 서비스 거부, 권한 상승의 6가지 카테고리로 각각의 위협을 분류한다. 이렇게 STRIDE-per-Element 방식을 적용할 때, 각 구성 요소 종류별 적용 가능한 항목은 차이가 있으며 이를 Table 1 에 표시하였다[1, 2].

(표 1) STRIDE-per-Element 적용 가능 매핑[1, 2]

(Table 1) Applicable mapping for STRIDE-per-Element[1, 2]

STRIDE에 의해 도출된 위협은 매우 추상적이므로, 이러한 위협이 실제로 발생할 수 있는지를 검증하기 위해, 각 위협에 공격 라이브러리의 항목을 매핑하여 구체화함으로써 도출된 위협의 타당성을 입증하여야 한다.

3.4 공격 트리(attack tree)

공격 트리는 트리 구조로 시스템에 대한 공격자의 공격 시나리오를 표현하며, 루트 노드(root node)에 공격자가 달성하려는 최종목표를 설정하고, 리프 노드(leaf node)로부터 루트 노드에 도달하는 다양한 공격 경로 및 방법을 기술함으로써, 다양한 공격 시나리오에 대한 시스템의 보안 대응 방안을 수립할 수 있도록 지원하는 체계적인 방법이다. 공격 트리는 그래픽(graphic)한 트리 형식이나 폼(form) 형식으로 표현할 수 있으며, STRIDE에서 도출된 위협과 공격 라이브러리의 항목을 이용하여 실제 발생 가능한 다양한 공격 시나리오를 작성한다[1].

3.5 체크리스트

STRIDE와 공격 라이브러리를 통해 구체적인 위협을 도출하고, 공격 트리를 통해 발생 가능한 공격 시나리오를 구성한 후, 이를 기반으로 발생할 수 있는 위협에 대해 점검할 사항은 무엇이고, 연관된 위협은 어떠한 것이 있으며, 관련된 보안 요구사항(이러한 위협에 대응하는 방법)은 어떤 것이 있는지 정의한 체크리스트(checklist) 를 구성하면 STRIDE 위협 모델링 과정은 완료되고 도출된 자료를 근거로 시스템에 필요한 보안 요구사항을 정의할 수 있다[1].

4. 해운 선사 운영시스템 위협 모델링

이제 3장의 STRIDE 위협 모델링 기법을 해운 선사의 공통 업무인 선적 서류 관련 업무에 적용하여 웹 기반 해운 선사 운영시스템에 특화된 보안 요구사항을 도출하고자 한다.

4.1 DFD

선적 서류 관련 시스템의 범위와 자산을 확인하고, 데이터 흐름을 파악하여, 위협이 발생할 수 있는 부분을 정확히 식별하기 위해 DFD를 작성한다.

4.1.1 배경도(context diagram)

선적 서류 관련 시스템의 전반적인 구성을 살펴보기 위해, 4개의 외부 객체(User, Shipper, Customs, Consignee) 와 하나의 프로세스(선사 운영시스템) 및 중요 데이터 흐름을 포함한 배경도를 Figure 1과 같이 구성하였다.

(그림 1) 배경도

(Figure 1) Context Diagram

4.1.2 Level 1 Diagram

배경도에서 도출된 항목 중 프로세스에 대하여, 주요 기능을 4개의 프로세스로 세분화하고(P1. Application Management, P2. Shipping Document Management, P3. Account Receivable Management, P4. Electronic Data Interchange(EDI) Management) 데이터 저장소 역할을 담당하는 세 개의 데이터베이스(D1. Database for user management, D2. Database for operating, D3. Database for EDI)를 추가한 후 데이터 흐름을 좀 더 상세하게 표현하고 4개의 외부 객체 중 관리 주체가 변경되는 3개의 외부객체(E2. Shipper, E3. Customs, E4. Consignee)를 신뢰 경계로 설정하여 Level 1 diagram을 구성하고, 이를 Appendix 1 에 추가하였다.

4.1.3 Level 2 Diagram

프로세스를 상세 기능별로 더욱 세분화하여 분류하고 데이터 흐름은 실제 프로그램에서 함수(function)에 대응되는 수준으로 상세하게 구성하여, 가능한 데이터 흐름을 모두 표현하였다. 총 4개의 외부 객체, 12개의 프로세스, 86개의 데이터 흐름, 3개의 데이터 저장소를 정의하고, 이렇게 구성된 6개의 상세 Level 2 diagram을 Appendix 2에서 7에 추가한 후, 핵심적인 사항을 Table 2 에 표시하고 자세한 기능을 상술하였다.

(표 2) Level 2 Diagram 상세 항목

(Table 2) Level 2 Diagram Detail Items

4.2 공격 라이브러리(attack library)

공격 라이브러리 구성을 위해, ATT&CK 공격자 전술 /기술 지식 베이스(knowledge base), WASC 취약점 분류 프로젝트, CVE 취약점 데이터베이스, OWASP Top 10 보안 표준 인식 문서 등을 이용하여 웹 기반 환경에서 발생할 수 있는 총 436개의 위협을 수집하고, 이중서론의 가정에 따라 Unix 또는 Linux 서버 환경에서 발생 가능한 148개의 위협을 추출하였다[11, 12, 13, 14].

수집된 공격 라이브러리의 위협에 대하여, 다음 단계의 STRIDE에서 도출되는 위협과의 매핑을 쉽게 하도록, 각각의 특성을 고려하여 위장(S), 변조(T), 부인(R), 정보 노출(I), 서비스 거부(D), 권한 상승(E) 중 해당하는 적절한 특성을 판단한 후 ‘O’를 표기하여 분류하였고, 이 위협이 DFD의 외부 객체(Ex), 프로세스(Pr), 데이터 흐름(Df), 데이터 저장소(Ds) 중 어떤 구성 요소에서 발생 가능한지를 검토하여 ‘V’로 표기하여 분류한 후, 핵심적인 사항을 Table 3에 나타내었다.

(표 3) 공격 라이브러리

(Table 3) Attack Library

4.3 STRIDE

DFD level 2 diagram 에 표기된 구성 요소를 살펴보면(Table 2) 4개의 외부 객체, 12개의 프로세스, 86개의 데이터 흐름, 3개의 데이터 저장소가 정의되어 있음을 확인할 수 있다. 이러한 DFD level 2 diagram 의 각 구성 요소에 STRIDE-per-Element 를 적용한 결과, 총 334개의 위협이 식별되었으며, 이중 핵심적인 사항을 Table 4 에 나타내었다.

(표 4) STRIDE-per-Element 분석 결과

(Table 4) STRIDE-per-Element Analysis Result

이렇게 도출된 위협은 매우 추상적이므로, 이러한 위협이 실제로 발생할 수 있는지를 검증하기 위해, 각 위협에 공격 라이브러리의 항목을 매핑하여 구체화함으로써 도출된 위협의 타당성을 입증하였다(Table 4 의 공격 라이브러리 컬럼에 매핑).

4.4 공격 트리(attack tree)

공격자가 해운 선사 운영시스템에서 시도할 수 있는 최종목표는 크게 3가지로 생각할 수 있다.

1)정보 유출(information leakage) : 운송하고 있는 화물의 이동 정보나 화주/선사의 은행 계좌와 같은 재정 정보를 유출하여 악의적인 목적에 이용

2)데이터 변조(data tampering) : 운송하고 있는 화물의 대수 또는 운임을 변조하거나, 송금액 등의 재정 정보를 변조하여 악의적인 목적에 이용

3)서비스 중단(service unavailable) : 해운 선사 운영시스템을 중단시켜 직접적인 재정 손실 또는 평판의 하락을 초래

따라서, 공격 트리를 구성하는 루트 노드는 공격자가 달성하려는 3가지 최종목표로 설정하였다. 최종목표를 달성하기 위한 중간목표는 ATT&CK 공격자 전술/기술지식 베이스[11]에서 공격자가 해운 선사 운영시스템에 시도할 가능성이 있는 전술을 선택하여 22개의 노드 (node)로서 구성하였으며, 리프 노드의 경우 구체적인 위협을 표현하여야 하므로 공격 라이브러리의 위협 항목을 사용하여 260개의 리프 노드를 구성하였다. 또한, 리프 노드에서 시작하여 루트 노드에 도달하는 노드들의 관계에 있어 부모 노드(parent node)와 자식 노드(child node) 의상호 관계에 따라 AND 및 OR 조건으로 적절히 연결하여 공격자의 다양한 공격 시나리오를 표현하였다.

공격 라이브러리에서 가능한 많은 위협 항목들을 공격 트리의 리프 노드에 표현하여 다양한 실제 공격 패턴을 나타내고자 하였으며, 공격 라이브러리의 위협 항목에 대응하는 STRIDE에서 도출된 위협을 매핑하여 상호비교가 가능하게 하였다(Table 5 의 위협 컬럼에 매핑). Table 5 는 이렇게 구성된 공격 트리의 핵심적인 사항을 나타내며, 이를 이용하여 해운 선사 운영시스템에 발생 가능한 위협 및 공격 시나리오를 확인할 수 있다[11, 12, 13, 14].

(표 5) 공격 트리

(Table 5) Attack Tree

4.5 체크리스트

해운 선사 운영시스템에 대하여, 선적 서류 업무의 DFD를 구성하고 공격 라이브러리와 STRIDE를 통해 구체적인 위협을 도출한 후, 공격 트리를 작성하여 발생 가능한 공격 시나리오를 확인하였다. 이를 기반으로, 발생할 수 있는 위협에 대해 점검할 사항은 무엇이고, 연관된 위협은 어떠한 것이 있으며, 관련된 보안 요구사항(이러한 위협에 대응하는 방법)은 어떤 것이 있는지 정의한 체크리스트의 핵심적인 사항을 Table 6에 나타내었다[11, 12, 13, 14, 15].

총 51개의 점검항목을 정의하였으며, 카테고리는 NIST cybersecurity 프레임워크의 카테고리 분류 방식에 따라 분류하였다[16].

(표 6) 체크리스트

(Table 6) Checklist

5. 웹 기반 해운 선사 운영시스템 보안 요구사항 정의

4장에서 DFD Level 2 diagram을 작성하고, 공격 라이브러리를 구성한 후, DFD의 구성 요소에 STRIDE 위협 모델링 기법을 적용하여 위협을 도출하고, 공격 트리를 작성하여 발생 가능한 위협 및 공격 시나리오를 표현한 후, 이를 이용하여 발생할 수 있는 위협에 대한 점검 사항과 연관된 위협 및 관련된 보안 요구사항을 포함한 체 크리스트를 작성하였다. 이러한 자료들을 근거로, 웹 기반 해운 선사 운영시스템에 요구되는 보안 요구사항을 다음과 같이 정의한다.

5.1 인프라 측면

체크리스트(checklist, CL) 상의 위협의 개수가 실제 위협의 위험도와 비례한다고는 할 수 없으나, 개별 조치를 통하여 대응할 수 있는 위협의 수를 나타내기 때문에 중요한 의미가 있다. 다음은 인프라 측면의 보안 요구사항을 나타낸다.

1)CL10 (212개 위협 항목과 연관)

대응하는 보안 요구사항은, 네트워크의 섹션을 분할하여 중요 시스템, 기능, 자원을 격리하는 것이며, 이를 위해서는 네트워크 장비의 물리적 분리 또는 가상네트워크 구성을 통한 논리적 분리를 통해 중요 시스템의 네트워크에 별도의 정책을 적용하고, 역할에 따라 프론트 엔드(front-end), 백엔드(back-end)로 네트워크를 분리하며, 필요하다면 중요 시스템에 추가 방화벽을 구성하여 시스템을 보호하여야 한다.

2)CL30 (200개 위협 항목과 연관)

대응하는 보안 요구사항은, 네트워크 보안 장비를 설치하여 송수신 트래픽을 필터링하고 프로토콜 기반 필터링을 수행하는 것이며, 이를 위해서는 애플리케이션 계층에서 동작이 가능한 3세대 방화벽의 도입이 필요하다[17].

3)CL03 (100개 위협 항목), CL09 (28개 위협 항목)

대응하는 보안 요구사항은, 웹 기반 컨텐츠를 제한하는 것이며, 이를 위해서는 애플리케이션에서 조건을 추가하거나, 웹서버 또는 WAS에 설정을 추가하는 것이 가능하나, 이보다는 포괄적으로 웹 공격을 탐지/방어할 수 있는 web application firewall(WAF)를 설치하여 웹 애플리케이션을 예상치 못한 위협으로부터 방어하는 것이 필요하다[18].

4)CL02 (99개 위협 항목과 연관)

대응하는 보안 요구사항은, 침입 방지 시스템(intrusion prevention system)을 설치하여 시그니처(signature) 기반 또는 이상(anomaly) 기반으로 네트워크에서 악의적인 트래픽을 검출하고 차단하는 것이다[19].

5)CL31 (86개 위협 항목과 연관)

대응하는 보안 요구사항은, SSL/TLS 암호화 트래픽을 검사하여 악의적인 트래픽을 검출하는 것이며, 이를 위해서는 암호화된 트래픽을 복호화하여야 한다. 보안 강화를 위해 대부분의 트래픽이 암호화되고 이전에 비해 강력한 암호화 알고리즘이 등장하는 추세에서, 기존 장비에 부하를 주지 않고 효율적으로 복호화 과정을 진행하기 위해서는 SSL/TLS 전용 복호화 장비를 도입하여야 한다.

인프라 구성을 통해 대응할 수 있는 체크리스트 항목은 6개이고, 관련된 보안 요구 사항은 5개이며, 가장 많은 위협과 연관되는 부분이다. 이를 위해 적절한 보안 장비 도입 및 구성이 필요하며, 다른 항목들에 비해 상대적으로 쉽고 빠르게 적용할 수 있다. 다만, 초기 투자비가 발생할 수 있으며, 비용 절감을 위해서는 성능이 다소 저하되나 여러 기능을 하나의 장비에 포함하고 있는 unified threat management(UTM)의 도입을 검토할 수 있다[20].

만일, 시스템을 퍼블릭 클라우드(public cloud) 환경에 구축하는 것을 고려하고 있다면, 이러한 장비들이 대부분 클라우드 컴퓨팅의 제품 및 서비스로 구현되어 있으므로, 초기 투자 없이 사용량에 근거하여 비용을 지불하는 방식으로 인프라를 구성할 수 있다. 그러나 이 경우, 초기 투자비는 절감되나 운영 비용이 증가하여 3년 이상의 총 소유 비용은 온프레미스(on-premise) 환경에서의 장비 도입과 비교해 더 증가할 수 있다.

5.2 보안 정책(security policy) 측면

보안 정책 측면의 보안 요구사항은 다음과 같다.

1)CL23 (126개 위협 항목과 연관)

대응하는 보안 요구사항은, 디렉터리 및 파일의 엄격한 접근 권한 관리를 위해, 실제 필요한 사용자만 자원에 접근할 수 있도록 설정하고, 시스템 파일의 경우 최소 권한만을 부여한 후, 주기적으로 이에 대한 감사 (audit)를 진행하는 것이다.

2)CL24 (115개 위협 항목과 연관)

대응하는 보안 요구사항은, 중요한 정보에 대하여 강력한 암호화 키(key) 및 알고리즘을 적용하여 정보를 보호하는 것이다.

3)CL06 (59개 위협 항목과 연관)

대응하는 보안 요구사항은, 주기적인 패치 절차와 정책을 수립하여 서버와 시스템에 보안 패치를 적용하는 것이며, 이를 위해서는 매월 정기적인 보안 패치일 자를 지정하여 서비스를 중단시키고 패치를 진행하는 것을 정책화하는 것이 필요하다.

4)CL11 (46개 위협 항목과 연관)

대응하는 보안 요구사항은, 높은 권한을 가진 계정 (privileged account)에 대하여 엄격한 관리를 진행하는 것이며, 이를 위하여 이러한 권한이 부여된 계정을 목록으로 작성하여 관리하고, 주기적인 감사를 통해 관리 진행 여부를 확인하여야 한다.

5)CL22 (46개 위협 항목), CL04 (45개 위협 항목)

대응하는 보안 요구 사항은, 운영체제 또는 소프트웨어의 잘못된 설정(misconfiguration)을 최소화하는 것이며, 이를 위해 설치/설정 가이드 문서를 작성 및 배포하여 따르게 함으로써 담당자의 실수를 방지하고, 주기적인 감사를 통해 정상 설정 여부를 확인하는 절차가 필요하다.

6)CL20 (27개 위협 항목과 연관)

대응하는 보안 요구 사항은, 사용자 계정의 생성, 변경, 사용, 권한 부여와 관련된 절차를 엄격히 관리하는 것이며, 이를 위해서는 사용자 계정의 관리 절차를 명시하고 정책화하여야 한다.

7)CL01 (13개 위협 항목), CL27 (12개의 위협 항목)

대응하는 보안 요구 사항은, 서버와 사용자 PC에 안티 바이러스/안티 맬웨어(antivirus/antimalware) 소프트웨어를 설치하는 것이다.

8)CL14 (13개), CL25 (13개), CL26 (12개)

대응하는 보안 요구사항은, 서버의 경우에는 설치/설정 가이드 문서를 통해 불필요한 소프트웨어의 설치 및 실행을 통제하는 것이고, 사용자 PC의 경우 어드민 권한을 제거하고 사용자 권한만 부여한 후 도메인에 참여(join)하여 도메인 컨트롤러의 정책을 통해 소프트웨어의 설치 및 실행을 통제하거나, 사용자 PC 관리에 특화된 소프트웨어를 설치함으로써 불필요한 소프트웨어의 설치 및 실행을 통제하는 것이다.

9)CL32 (12개 위협 항목과 연관)

대응하는 보안 요구 사항은, 서버와 사용자 PC의 백업을 진행하는 것이며, 이를 위해 서버의 경우 일/월/ 영구 백업 정책을 수립하여 실행하고, 필요시 재해 복구 계획(disaster recovery plan)을 수립한 후, 최소 30km 이상의 거리에 disaster recovery(DR) 센터를 구축하여 재해 상황에 대비할 수 있다. 백업의 경우 랜섬웨어에 대한 거의 유일한 대처 방법이므로 사용자 PC에 대해서도 주기적인 백업이 진행되어야 하며 이를 원격 저장소에 보관하여야 한다.

10)CL29 (16개 위협 항목과 연관)

대응하는 보안 요구사항은, 침입 탐지 로그 데이터 등 중요 정보의 노출을 방지하기 위해, 효과적으로 제어가 가능한 원격 저장소에 이러한 정보들을 저장하는 것이며, 이를 통해 공격자가 로컬 시스템에서 이러한 정보를 확인하고 조작하는 것을 방지할 수 있다.

11)CL05 (13개 위협 항목과 연관)

대응하는 보안 요구사항은, 주기적인 보안 인식 교육을 진행하는 것이고, 이를 통해 사용자의 보안 역량을 강화할 수 있다.

12)CL17 (13개 위협 항목과 연관)

대응하는 보안 요구사항은, 계정에 대한 안전한 패스워드 정책을 강제하는 것이며, 패스워드 길이, 조합, 사용기간 등의 정책을 상세히 설정하여야 한다.

13)CL19 (11개 위협 항목과 연관)

대응하는 보안 요구사항은, 보안 강화를 위해 multi-factor authentication(MFA)를 적용하는 것이며, 시스템의 중요 기능 및 관리메뉴에 접속하는 경우 MFA 인증을 통해 보안 수준을 높여야 한다. MFA는 공격자가 유효한 계정정보를 취득한 후 시스템에 접속할 때도 이에 대처할 수 있는 좋은 정책이 된다.

14)CL18 (4개 위협 항목과 연관)

대응하는 보안 요구사항은, 일정 회수의 로그인 실패 후 계정 잠금 정책을 적용하는 것이며, 이를 통해 암호를 추측하여 계정에 접근하는 시도를 방지할 수 있다. 다만, 이 경우 이를 악용하여 특정 회수 이상 계정에 로그인 시도를 하여 계정을 잠기게 하는 공격에 노출될 가능성이 있다.

보안 정책 적용을 통해 대응할 수 있는 체크리스트 항목은 18개이고, 관련된 보안 요구 사항은 14개이다. 중요한 부분은 정책 수립 후 이를 시행하고 감사하고 문제점이 발생하면 대응하는 절차가 주기적으로 계속 진행되어야 한다는 점이다.

5.3 개발(development) 측면

개발 측면의 보안 요구사항은 다음과 같다.

1)CL35 (51개 위협 항목과 연관), CL44(51개), CL47(51개), CL36(42개), CL33(36 개), CL34(36개), CL37(36개), CL40(36개), CL42(36 개), CL43(36개), CL48(36개), CL49(36개), CL41(24 개), CL46(19개), CL45(15개), CL38(12개), CL39(12 개), CL51(12개), CL50(4개)

대응하는 보안 요구사항은, 애플리케이션의 자체의 취약점을 제거하는 시큐어 코딩(secure coding)을 개발과정에 포함하도록 정책을 수립하고 추진하는 것이며, 이를 위해 개발자들에게 개발 보안 가이드를 배포 /교육하여 보안을 고려한 코딩이 진행되도록 하고, 이에 대한 관리, 검증 및 테스트가 정책에 따라 진행되도록 하여야 한다.

2)CL07 (28개 위협 항목과 연관)

대응하는 보안 요구사항은, 소스 코드를 검토하여 보안 취약점이 발생할 수 있는 부분을 탐지할 수 있는 도구를 도입하는 것이며, 일정 주기로 도구를 실행하여 소스 코드의 안전성을 검토하여야 한다.

개발 프로세스 개선을 통해 대응할 수 있는 체크리스트 항목은 20개이고, 관련된 보안 요구 사항은 2개이다. 시스템 개발 시, Spring과 같은 프레임워크를 이용할 경우, 코드상 취약점이 발생할 수 있는 요소를 상당수 감소시킬 수 있으므로 이러한 개발 프레임워크 도입을 고려해야 한다.

5.4 솔루션(solution) 도입 측면

솔루션 도입 측면의 보안 요구사항은 다음과 같다.

1)CL21 (27개 위협 항목과 연관)

대응하는 보안 요구사항은, 자동화된 방식으로 시스템이나 네트워크의 잘못된 권한설정, 안전하지 않은 소프트웨어 항목, 안전하지 못한 구성 등의 취약점을 스캔하여 보고하는 솔루션을 도입하거나, 수작업을 통해 이러한 사항들을 주기적으로 감사하는 정책과 절차를 마련하는 것이다. 이러한 취약점은 신속하게 확인되고 보고되어야 하므로 자동화된 솔루션을 도입하는 것이 수작업에 의한 점검에 비해 안전성을 높일 수 있다.

2)CL51 (12개 위협 항목과 연관)

대응하는 보안 요구사항은, 자동화된 소프트웨어에 의한 공격으로부터 시스템을 보호하는 방안을 마련하는 것이고, 이를 위해서는 completely automated public turning test to tell computers and humans apart (CAPTCHA)와 같은 솔루션을 도입하여야 한다.

솔루션 도입을 통해 대응할 수 있는 체크리스트 항목은 2개이고, 관련된 보안 요구 사항은 2개이다. 취약점에 대한 자동화된 검출은 시스템 안전성 유지에 매우 중요한 부분이며, 이를 통해 보안 수준을 높일 수 있다.

6. 결론

시스템을 새로운 웹 기반 환경으로 전환하는 경우 가장 중요한 부분은 설계 과정이며, 시스템 안전성 확보 및 보안 관련 유지보수 비용 절감을 위해 반드시 보안을 고려한 설계를 진행하여야 한다. 기존 구성 방식과 지식을 바탕으로 잘못된 설계가 진행되고, 이에 기반하여 시스템이 구성될 경우, 실제 시스템 운영 시 치명적인 보안 문제를 발생시키게 되고, 이를 해결하기 위해서는 큰 비용과 노력이 필요하게 되며, 이러한 문제가 빈번하게 발생한다면, 대내적인 손실뿐 아니라 대외적인 회사의 평판에도 나쁜 영향을 미치게 된다. 일부 해운 선사의 경우 보안 취약점을 이용한 사이버 공격으로 인해, 시스템 운영이 일정 기간 중단된 사례가 있으며, 이로 인해 천문학적 규모의 손실이 발생하였다.

본 논문에서는 웹 기반 해운 선사 운영시스템의 보안 설계를 위해, STRIDE 위협모델링 기법으로 선적 서류 업무를 분석하여 위협 항목을 도출하고, 이를 공격 라이브러리의 항목과 매핑하여 구체화한 후, 공격 트리를 구성하여 발생 가능한 위협과 다양한 공격 시나리오를 검토하고, 체크리스트를 구성하여 발생할 수 있는 위협에 대한 점검 사항과 연관된 위협 및 이에 대응할 수 있는 보안 요구사항을 정리한 후, 최종적으로 인프라 측면의 보안 요구사항 5개, 보안 정책 측면의 보안 요구사항 14 개, 개발 측면의 보안 요구사항 2개, 솔루션 도입 측면의 보안 요구사항 2개, 총 23개의 보안 요구사항을 도출하고 상술하였다.

본 논문에서 제안된 보안 요구사항은 하향식으로 제시된 기존의 일반적인 보안 요구사항이 아닌, 해운 선사 업무에 대하여 애플리케이션 함수 수준의 세부 기능을 분석한 DFD에서 시작하여 STRIDE 위협 모델링 기법을 적용하여 도출된 웹 기반 해운 선사 운영시스템에 특화된 보안 요구사항이므로, 어떤 보안 요구사항을 따르지 않았을 경우 어떤 업무와 관련된 시스템에 보안 취약점이 발생할 수 있는지 쉽게 판단할 수 있다.

그러므로, 웹 기반 환경의 특성 및 해운 업무의 특성을 고려한 본 논문의 보안 요구사항들은 웹 기반 환경으로의 시스템 전환을 고려하는 해운 선사들의 보안 설계에 올바른 지침을 제공하고, 실제 설계 과정에서 발생할 수 있는 시행착오를 줄이는 데 많은 도움을 줄 것으로 생각한다.

그러나, 본 논문은 해운 선사의 전체 업무가 아닌 선적 서류와 관련된 일부 핵심 업무만을 대상으로 하여 작성되었고, Unix 또는 Linux 기반의 웹서버 및 WAS 환경을 가정하여 진행되었으므로, 향후 운임의 수금, 선박 운항, 세관 신고, 유류 대금 지급, 대화주 서비스 제공 등 나머지 해운 선사 업무에 대한 분석을 진행하고, Windows 기반 환경에 관한 연구를 진행하고자 한다.

부록(appendix)