2017년 2월 20일 월요일

봇넷의 근본적인 이유와 최근에 다시 이슈가 된 이유

Q: 봇넷이 나타난 것이 꽤 오래 전으로 알고 있습니다. 아직까지도 봇넷의 근본적인 해결이 안되는 이유와 최근에 다시 이슈가 된 이유에 대해 설명 부탁합니다.

봇넷은 90년대초에 EggDrop이라는 것으로 처음 나왔습니다. 그 이후에도 Forbot, PBot, Toxbot 등 많은 변종 봇들이 나타났고 최근에는 그 숫자도 더 늘고 있어 대응에 매우 어려움을 겪고 있습니다. 근본적인 해결이 어려운 이유는 감염만 시키면 타겟팅 된 PC를 손쉽게 제어하면서 다양한 2차 공격을 할 수 있기 때문에 신종 봇들을 계속 만들어내기도 하고 이미 감염된 수많은 좀비 PC들을 한꺼번에 치료할 수 있는 것도 아니기 때문에 감염이 꼬리를 물면서 유지되는 것이지요.
관심도가 떨어진 적도 없지만 최근에 다시 이슈가 되고 있는 이유는 초고속 인터넷 망이 구축되면서 네트워크 속도도 빨라지고 더 많은 PC들이 접속되고 있기 때문입니다. 특히 우리나라처럼 인터넷 망이 우수한 곳에서는 봇넷이 더 많이 활동하고 있다고 봐야 합니다.
봇넷의 주된 확산지였던 이메일 뿐만 아니라 SNS를 통해 더 많은 확산 방법이 생겨나면서 최근의 위험성이 더 강조되고 있습니다. 특히 IoT의 확대로 앞으로 더 큰 걱정인데요. 무제한으로 데이터를 수집하는 창구인 IoT는 기존 기술들에 비해 보안성이 상대적으로 낮아 봇넷의 집중 타겟이 될 수 있습니다.

Q: 봇넷의 주된 공격 방법이 좀비 PC를 이용한 DDoS로 알고 있는데요. 모두 그런 것은 아니지만 DDoS에 대한 대응 방법이 어느 정도 성공을 거둔 사례도 있고 툴도 나와 있는 것으로 알고 있습니다. 다시 봇넷의 심각성이 왜 대두가 되고 있는 것인지 조금 더 자세한 설명 부탁합니다.

네 맞습니다. 이전에 봇넷은 감염된 좀비 PC를 활용해 DDoS나 스팸 발송 등의 공격을 하고 공격과 동시에 봇을 더 확대하는 형태가 일반적이었습니다. 그림2에서 보는 것처럼 감염된 좀비 PC를 C&C 서버를 통해 수시로 제어하면서 다양하고 빈번한 공격이 가능했습니다.

<그림2> 봇넷의 공격 방법
출처: KISA

더보기


한번에 개발과 반복(Iteration)을 통한 개발(Sprint)

SI는 프로세스 상 분석, 설계, 개발을 한번에 진행하는 폭포수(Water-fall) 방식을 취한다. 한번에 분석하고 한번에 설계하고 한번에 개발하기 때문에 계획한대로 끝난다면 한번의 프로세스로 마칠 수 있어 시간이 매우 절약될 수 있지만 개발되는 중간이나 이후에도 고객과 의견이 맞지 않아 마찰이 빈번하게 발생한다.
애자일은 3차례 정도 반복해서 개발하는 방식을 취한다. 한번 개발이 끝나는 것을 이터레이션이라고 하고 한번의 스프린트가 완료되었다고 말한다. 스프린트의 단위는 계획(또는 커뮤니케이션), 디자인, 빌드(개발), 테스트, 리뷰로 이루어진다(그림3). SI와 같이 요구사항 분석, 분석, 설계, 개발, 테스트로 구성되어도 무방하다.

<그림3> 애자일 스프린트의 예
출처: 노나카 이쿠지로 - 애자일 개발과 스크럼

스프린트 모델의 장점은 개발 결과물에 대한 고객의 피드백을 받아 반영할 시간이 보장되어 있다는 것이다. 폭포수 모델의 경우 한번 개발이 완료되면 잘 못 개발되었다고 하더라도 수정하기가 매우 어렵다. 반면에 스프린트 모델은 하나의 스프린트가 끝날 때마다 고객에게 제대로 개발되었는지 확인하고 보완사항을 반영하여 다음 스프린트를 수행하게 된다. 일반적으로 3회 정도의 스프린트라면 고객이 만족할만한 개발이 된다고 알려져 있다.
SI에서도 CBD(Component Based Development) 모델이나 애자일 초기 시점에 이터레이션을 활용한 적이 있었지만 크게 성공하지는 못했다. 한번의 이터레이션이 종료될 때 개발의 주체에 고객이 없어 고객의 피드백을 받지 못했기 때문에 이터레이션의 효과를 보지 못했다. 하이브리드 형 애자일도 성공하지 못한 것도 비슷한 이유 때문이었다. 애자일의 기본 방향성은 고객의 참여이기 때문이다.

더보기


User Testing Brain & Software



  • 유저테스팅이란?


  • 유저테스팅 프로세스





  • 유저테스팅 대상




더보기

2017년 2월 17일 금요일

봇넷의 현황과 대응기술 방향


스마트 디바이스의 보급으로 사이버 공간이 지속적으로 확대되고 있고 수많은 정보가 옮겨지고 있다. 개인정보를 수집하여 악용하거나 경쟁사의 시스템을 못쓰게 하는 등 네트워크로 연결된 곳에서는 언제나 위험이 산재해 있다. 이번 회에서는 보안과 관련하여 많은 이슈가 되고 있는 봇넷(botnet)에 대해 글로벌 아웃소싱센터를 구축하고 담당하는 한용만 박사와 단국대학교 컴퓨터보안연구센터원을 만나 이야기를 들어본다.

Q: 안녕하세요. 봇넷은 인터넷 세상에서 가장 위험한 공격으로 알려져 있습니다. 봇넷에 대한 정의를 부탁합니다.

스팸 메일이나 악성 코드를 전파하도록 하는 봇(bot)에 PC가 감염되어 해커(bot master)가 마음대로 제어할 수 있는 좀비 PC들로 구성된 네트워크를 말합니다(그림1). 일단 악성 코드 하나가 심어지고 나면 순식간에 전파될 수 있어 최근에 가장 위험한 공격 중 하나로 꼽히고 있습니다.

<그림1> 봇넷의 공격 개념
출처: 인터넷침해대응센터

일단 좀비 PC로 감염이 되고 나면 봇 마스터가 지속적으로 좀비 PC를 제어할 수 있기 때문에 침해 사고의 범위가 무한대로 늘어날 수 있다는 높은 위험성을 가지고 있습니다. 봇넷의 경우 원천적으로 차단하거나 감염된 PC를 쉽게 치료할 수 있는 기술이 있는 것은 아니기 때문에 이번 회에서는 기술적 요소보다는 봇넷의 위험성과 위험에 노출되지 않기 위한 방법 등에 대해 기억했으면 합니다.


SI와 애자일에서 요구사항 수집

SI와 애자일에서 가장 크게 차이가 있는 부분이다. SI는 고객이 요청하는 요구사항을 기반으로 하기 때문에 요구사항 정의에 신중을 기하고 고객이 요구하는 것 외에는 개발에 반영하려는 노력을 하지 않는 것이 현실이다. 요구사항이 한번 정해지면 프로젝트 종료할 때까지 번복하기가 매우 어렵고 고객과 협의도 쉽지 않기 때문이다.
애자일은 커뮤니케이션을 기본으로 한다. 요구사항을 수집하기는 하지만 사용자 스토리 단위로 요구사항을 정리하기 때문에 고객이 미처 생각하지 못한 부분을 찾아내어 함께 정의할 수 있다. 그리고 프로젝트 중간에도 요구사항이 맞지 않으면 빠르게 변경하여 대응한다.
애자일에서는 요구사항을 사용자 스토리 단위로 정의하여 필요한 기능들을 정의하게 된다. 하나의 스토리에 필요한 기능이 정의되고, 기능이 모두 개발되면 한 개의 사용자 스토리가 완성이 되는 것이다(그림2). 사용자 스토리를 체계적으로 정리하기 위해 사용자 스토리 워크샵이라는 활동을 따로 하는 경우가 일반적이고, 이렇게 정리된 사용자 스토리를 개발 일정에 맞춰 프로젝트 계획을 수립하게 된다.

<그림2> 애자일의 사용자 스토리 기반 요구사항 정의

요구사항이 정의되는 시점에 SI와 애자일의 가장 큰 차이점은 SI는 단편적인 요구사항만 정의되는 경우가 많고 애자일은 스토리 단위로 정의되는 것이다. 스토리 단위로 정의하는 것의 장점은 고객이 얘기하지 않아도 스토리 전개 상 필요한 것들이 한 눈에 들어오고 설사 얘기되지 않은 기능들도 찾아낼 수 있는데 있다.



더보기

디자인 씽킹 - 펩시콜라와 코카콜라 이야기

  • 펩시콜라와 코카콜라 이야기


  • 문화인류학적 조사를 시행하라


  • 문화인류학적 조사를 시행하라



2017년 2월 16일 목요일

ICBM 기반의 산업

Q: ICBM이 오늘 주제에서 나오리라고 생각은 못했습니다. 앞으로 인더스트리 4.0에 맞춰 재구성되는 산업은 ICBM 기반으로 만들어지겠다는 생각이 듭니다.

ICBM을 얘기하면 IT나 소프트웨어 전문가조차도 너무 개념적인 이야기라고 말을 많이 합니다. 하지만 ICBM은 미래형 산업에 가장 잘 적용되는 구성 방안이라고 볼 수 있습니다. 어느 미래 산업이든 빅데이터를 생산해낼 것이고 이를 위해서는 수집하는데 필요한 IoT 센서가 필요하고 체계적으로 분석하고 성장하기 위해 머신 러닝이 꼭 필요하기 때문입니다. 클라우드는 이 것들을 하나로 묶어주는 역할이겠지요.

Q: IT 기술이 발전하면서 여러 산업들은 더 많은 발전을 이루기 때문에 상상하지 못하는 형태의 제품들이 많이 나올 것이라 생각했는데 소프트웨어 입장에서 보면 표준화된 틀 내에서 움직이는 것 같습니다. 이번 이야기의 마무리를 부탁드립니다.

이번 이야기의 주제는 보는 시각에 따라 다양하게 해석될 수 있습니다. 아직 체계가 덜 잡힌 개념이라고 볼 수도 있지만, 그만큼 기대되는 것들이 많다는 얘기도 됩니다. 점점 단순해져 간다고 느끼던 소프트웨어가 산업 변화의 중심이 된다는 것은 매우 흥미롭고 장미빛 전망을 주기도 하지만 체계적이고 효율적인 접근이 없다면 모든 산업을 망칠 수도 있다는 위험도 안게 됩니다. 이러한 위험을 줄이기 위해서는 소프트웨어 개발자들이 소프트웨어만 공부할 것이 아니라 소프트웨어가 필요한 다양한 산업에 대한 심도 있는 학습이 필요한 시점입니다.