2017년 4월 18일 화요일

소프트웨어 안전성 분석(2)

제4차 산업혁명이 나타나면서 각 산업에서 소프트웨어가 차지하는 비중이 점점 늘어나고 있어 소프트웨어의 안전성에 대한 이슈가 날로 커지고 있다. 지난 회에 이어 소프트웨어 안전성 분석에 대해 알아보고자 하며 지난 회에서는 소프트웨어 안전성 분석의 개념 중심으로 살펴봤고 이번 회에서는 실제 적용된 체계 중심으로 살펴본다.
소프트웨어 안전성 확보 체계
소프트웨어의 안전성을 확보하기 위한 노력은 최근에 이루어진 것은 아니다. 이미 오래 전부터 소프트웨어로 인한 대형 사고는 계속 발생하고 있다. ‘96년 4월에 유럽의 상업 우주선 아리안 5호는 발사한지 50여초 만에 공중에서 폭발했는데 사고의 원인을 소프트웨어 오류 때문이라고 결론 냈다. 64비트 숫자 값을 16비트 정수로 변환하는 과정에서 일어난 것으로 지금은 흔하게 알려져 있는 오버플로우 오류였고, 이로 인해 5억 달러 우주선이 폭파됐다. 가까운 일본의 최근 사례로 도요타는 ‘10년부터 차량 급발진 사례로 여러 번의 소송을 받아 왔고 결국 미국 법무부의 조사를 받았다. 조사 중 소프트웨어 전문업체를 통해 전자제어장치의 소프트웨어 오류로 급발진이 발생한다는 사실이 입증되었고 도요타는 12억 달러의 합의금을 내야했다. 이처럼 크지 않을 것 같은 소프트웨어 오류로 인한 피해는 앞으로 기하급수적으로 늘어날 것으로 예상되기 때문에 소프트웨어 안전성에 대한 철저한 검증과 관리가 필요하다.

소프트웨어 안전성 기준 확보

각 산업에서는 산업 고유의 안전성 확보를 위한 기준이 준비되어 있는데 전자나 기계적인 장치가 들어있는 경우 소프트웨어에 대한 내용도 포함되어 있는 경우가 대부분이다(표1). 각 기준에는 산업별로 안전성에 대한 확보, 검증, 관리에 대한 가이드라인이 포함되어 있어 소프트웨어와 관련된 가이드라인을 확인한다.

<표1> 산업별 안전성 기준

출처: 중소기업융합학회 논문 - 소프트웨어 개발 프로세스에서의 안전성 분석 및 관리활동의 적용방안

소프트웨어 안전성 보증 프로세스

소프트웨어를 개발할 때는 요구사항을 기준으로 체계적으로 반영될 수 있도록 준비하고 제대로 적용되었는지 확인하는 것이 기본이다. 소프트웨어의 안전성 확인도 개발 프로세스에 맞추어 준비를 하는 것이 가장 효율적이기 때문에 요구사항에서 안전성 관련된 부분을 발췌하여 정리하고 소프트웨어에 제대로 적용되는지 확인하도록 해야 한다(그림1).

<그림1> 소프트웨어 안전성 보증 프로세스의 예
출처: 2015 소프트웨어 안전성 컨퍼런스

다만 주의할 사항이 있는데, 그림1과 같은 방법은 소프트웨어 중심으로 만들어지는 프로세스로 볼 수 있고, 각 산업별로는 더 다양한 형태로 소프트웨어 안전성이 확보될 수 있도록 프로세스를 확인하고 적용해야 한다(그림2).

<그림2> 산업별 소프트웨어 안전성 기준
출처: 2015 소프트웨어 안전성 컨퍼런스

각 소프트웨어 안전성 보증 프로세스에 맞춰 개발을 진행할 때도 메인 프로세스가 각 산업에 있다고 하더라도 소프트웨어는 안전성 보증 프로세스에 맞추는 것이기 때문에 단 번에 끝내는 것이 아니라 안전성 수준에 따라 점진적(Increment), 반복적(Iteration) 프로세스를 도입하는 것도 좋은 방법이다. 더 보기 >>>

모바일 기기 확대로 인한 회사들의 보안 문제

거의 모든 회사원들에게 모바일 기기가 보급되면서 모바일을 이용하여 업무를 수행하도록 하는 회사들이 지속적으로 늘어나면서 회사 업무 보안에 대한 관심도가 증가하고 있지만 이보다 더 임직원들을 통해 회사 안으로 들어오는 모바일 자체에 대한 보안 문제는 고민거리를 더 안겨주는 추세다. 이번 회에서는 단국대학교 보안연구실의 연구원들, 글로벌테크 이성규 이사와 함께 모바일의 확대로 인해 늘어가는 회사들의 고민거리에 대해 알아보기로 한다.

Q: 안녕하세요. 최근에 스마트폰의 등장으로 기업에서 스마트폰을 이용하여 업무 영역을 확대하는 사례가 늘고 있습니다. 모바일과 관련된 기업들의 움직임에 대해 먼저 부탁합니다.

회사 내에서 스마트폰이 없는 사람은 아마 거의 없을 겁니다. 스마트폰 자체를 거부하는 일부 피쳐폰 사용자 말고요. 그러다 보니 기업의 경영자 입장에서는 스마트폰을 이용하여 업무의 편의성을 제공하려 한다지만 어떻게 보면 더 타이트한 업무 범위를 강조하는 것일 수 있지요. 회사에 도움이 되지 않는데 일부러 비용을 들여서 적용할 필요는 없기 때문이죠. 이메일도 더 빨리 볼 수 있고 결재도 더 신속히 결정되고 근태도 스마트폰으로 신청할 수 있고요. PC 앞에서 처리하던 것들을 스마트폰으로 할 수 있으니 업무 관점의 신속성이 더 높아진 것이죠.

<그림1> 기업 내 업무 커뮤니케이션 설문 결과



출처: 이스트소프트

그림1을 보면 스마트폰으로 업무를 활용하는 수치가 지금도 계속 증가하고 있습니다. 우리가 스마트폰으로 흔히 이용하는 메신저나 이메일 뿐만 아니라 자료 공유나 문서 작성에도 많이 활용하고 있다는 것이 눈에 띄는 변화입니다. 그리고 다소 사용률이 떨어질 것 같은 중년층의 경우도 지속적으로 늘어가고 있고 사장이나 임원들이 더 적극적으로 활용하고 있는 추세이기 때문에 증가하는 속도는 더 빨라질 것으로 보입니다.

Q: 업무에 스마트폰을 활용하는 경우가 계속 증가하고 있는 것은 부정할 수 없는 사실이긴 한데 업무에 도움이 많이 되기 때문인가요?

논란이 있기는 하지만 도입한 회사들의 경우 커뮤니케이션에는 상당히 도움이 된다는 보고가 나오고 있기는 합니다만 사용자인 직원들은 불만 섞인 피드백이 많이 나오는 것도 사실입니다. 시도 때도 없이 울려대는 스마트폰 때문에 회사 안과 밖의 경계가 없어진 때문이겠죠. 긍정적인 면을 본다면 담당자와 한시도 떨어지지 않는 스마트폰은 업무 공백을 없애주는 핵심 요소이기 때문에 업무에 도움을 준다고 봐야겠지요.

<그림2> 모바일 오피스의 예
출처: 삼양데이타시스템

예전에 그룹웨어(Groupware)가 유행하던 현상과 비슷하다고 보시면 되지요. 그룹웨어도 처음에는 이메일이나 회사 게시판 정도가 운영되다가 화상 회의나 일정 관리, 주요 거래선 관리, 결국 회사 전용 메신저도 추가되었고 구글 드라이브와 같은 문서 공유 솔루션도 만들어졌지요.

Technical Debt as a Core Software Engineering Practice

참석자
Ipek Ozkaya - At the SEI she is the deputy lead for the Architecture Practices initiative.
요약
---
기술 채무 (Technical Debt): 소프트웨어 개발 프로젝트를 진행할 때, 초기에 제대로 처리하지 않은 일이 반복 주기에서는 문제점으로 나타나고, 이러한 문제점이 다른 수정사항이나 또 다른 문제를 나타낼 수 있어 원금에 이자까지 지불해야 하는 상황이 온다는 개념
---

이번 이야기는 기술 부채와 소프트웨어에서의 의미에 관한 것입니다. 수년에 걸쳐서 우리는 레거시 현대화, 애자일 적용, 아키텍처가 충분히 많은지, 어떤 것을 바꿔야 기술이 바뀌는지 문제를 겪은 많은 고객과 함께 했습니다.
다양한 고객과 다양한 문제에 걸쳐 한 가지 사실은 있습니다. 실제로 시스템에 남는 것을 표현할 수 없다는 것입니다. 예를 들어, 정말로 레거시를 업그레이드 해야 합니까? 정말로 아키텍처를 다시 만들어야 합니까? 그리고 어떻게 트레이드-오프를 결정해야 합니까? 결국 마지막에는 비즈니스 결정만 아니라 디자인 결정을 해야 한다는 것입니다. 하지만 일단 비용 측면을 고려하면서 트레이드-오프를 이야기하면 계속 반복될 겁니다. 그것은 커뮤니케이션 메커니즘뿐만 아니라 연관된 여러 연구 과제에서 기술적 부채를 찾는 시작입니다. 이것이 프로젝트의 착수 방법입니다.

2017년 4월 13일 목요일

SW 영향평가 제도

SW분야에서 공공과 민간의 역할 정립을 위해 공공정보화 사업의 기획단계부터 민간시장에 미치는 부정적 영향을 평가.


정부가 민간시장을 위축시키면 안 되며 민간시장에 미치는 영향을 사전 평가하는 등 공공정보화 사업 추진절체 개선(SW중심사회 실현전략 보고회, ’14.7월)

SW ASSETBANK UI UX (동영상)




2017년 4월 12일 수요일

정보공개제도란?

정의

"정보공개제도"란 국가기관 지방자치단체등 공공기관이 업무 수행 중 생산하여 보유ㆍ
관리하는 정보를 국민에게 공개함으로써, 국민의 알 권리를 보장하고 더 많은 정보를
바탕으로 국정운영에 대한 참여를 유도하기 위한 제도입니다.

정보공개법의 제정ㆍ시행

  • 정보공개법의 개정(1998.1.1 시행)
  • 국민의 알 권리를 확대하고 국정운영의 투명성을 높이기 위해
    지난 '96년 <공공기관의 정보공개에 관한 법률> 을 제정ㆍ공포하고, ’98년1월1일부터 시행

공개형태

  • 청구공개
  • 공공기관이 직무상 작성 또는 취득하여 관리하고 있는 정보를 청구인의 청구에 의하여 공개하는 제도
    (예)공문서의 열람, 복사청구 등
  • 정보공개
  • 정보를 보유한 공공기관이 자발적으로 또는 법령상 의무적으로 정보를 제공하는 제도
    (예)인터넷을 통한 정보제공, 간행물의 배포 등 

2017년 4월 11일 화요일

소프트웨어 안전성 분석(1)

산업 내에서 직접적인 소프트웨어 활용이 많아지면서 소프트웨어의 안전성에 대한 고민이 다른 측면으로 다시 시작되었다. 소프트웨어가 오류없이 동작하는데 초점이 맞춰진 예전에는 소프트웨어 테스팅이나 보안 중심으로 안전성을 확인했지만 지금은 소프트웨어가 산업 자체에 영향을 주는 경우가 많아 이 외에도 다양한 관점으로 안전성을 살펴볼 필요가 생겼다. 2회에 걸쳐 소프트웨어 안전성 분석에 대해 알아보고자 하며 이번 회에서는 소프트웨어 안전성 분석의 개념 중심으로 살펴보도록 한다.
소프트웨어 관점의 소프트웨어 안전성 분석
소프트웨어가 사용되면서 사용자들에게 가장 큰 고민은 소프트웨어 오류였다. 소프트웨어를 개발하면서 나타나는 오류는 사용자뿐만 아니라 개발을 완료한 개발자 입장에서도 많은 시간과 노력을 들여야 하는 경우가 많았다. 또한 소프트웨어를 사용하는 범위가 산업의 기반 시설들을 다루는 경우보다는 대체로 오퍼레이션과 관련된 것들이 많아 소프트웨어의 안전성이 좋지 않아도 산업 자체가 동작하는데 큰 무리는 없었다. 그래도 소프트웨어의 안전성을 높이기 위해 글로벌 기업을 중심으로 많은 예산과 인력을 투입하였고 다양한 소프트웨어 분석 도구와 기술을 개발하여 대처하였다. 개발 과정에서부터 보안 안전성을 고려하여 개발하는 시큐어 소프트웨어 개발 방법론(Secure Software Development Methodology)도 소프트웨어 안전성이나 보안 위협을 고려한 방법이라고 할 수 있다.
과거에 많이 사용된 소프트웨어 안전성 분석 방법은 크게 화이트박스 테스팅(White box Testing)과 블랙박스 테스팅(Black box Testing)으로 볼 수 있다. 화이트박스 테스팅은 분석 대상이 되는 소프트웨어의 소스코드를 대상으로 취약성이 발생할 수 있는 패턴을 분석하거나 버퍼 오버플로우와 포맷 스트링 취약점 등을 점검하여 소프트웨어가 적절하게 데이터를 처리하는지 점검하는 방식이다. 블랙박스 테스팅은 소프트웨어에 데이터를 입력하고 소프트웨어의 동작을 모니터링하면서 안전성을 점검한다. 블랙박스 테스팅은 소스코드가 반드시 필요하지는 않고 화이트박스 테스팅이 발견하지 못하는 예외적인 상황을 유발시켜 다양한 형태의 안전성 분석을 할 수 있지만 시간과 비용이 많이 드는 것이 단점이기 때문에 효율적인 테스팅을 위해서 자동화된 안전성 분석 도구가 이용되는 경우가 많다(그림1).

<그림1> 블랙박스 테스트와 화이트박스 테스트

소프트웨어의 안전성 분석을 위해서는 분석 대상 소프트웨어의 수준에 따라 분석 방법을 결정하는데 실행 프로그램만 있는 경우에는 블랙박스 테스팅, 소스코드가 제공되는 경우에는 화이트박스 테스팅을 수행하는 경우가 많다. 블랙박스 테스팅과 리버스 엔지니어링(Reverse Engineering)을 접목한 그레이박스 테스팅(Gray box Testing)도 알려져 있다(표1).

<표1> 소프트웨어 안전성 분석 방법의 장단점
출처: 한국전자통신연구원(ETRI)

블랙박스 테스팅과 화이트박스 테스팅을 활용하는 방법도 여러가지가 있다. 먼저 소프트웨어에 다양한 입력을 하여 실행시킨 후 결과를 살펴보는 동적 분석(Dynamic Analysis)과 소프트웨어를 실행시키지 않고 소스 코드의 내용으로 판단하는 정적 분석(Static Analysis)이 있다. 블랙박스 테스트와 화이트박스 테스트를 이 두가지 방법으로 구분하여 안전성을 테스트 할 수 있다(표2).

<표2> 정적 분석과 동적 분석
출처: 데이터베이스진흥원

소프트웨어 안전성 확인을 위해서 동적 분석은 소프트웨어의 특성에 따라 다양한 방법으로 확인해야 하지만 정적 분석은 요구사항을 받아 개발을 하면서 확인하기 때문에 요구사항을 받은 후 진행되는 프로세스에 따라 안전성 확인 방법이 어느 정도 정해져 있다.