사이버보안을 강화하는 애자일 개발 10원칙

경쟁이 극심한 오늘날 환경은 기업에 더 빨리 움직이고 더 혁신할 것을 요구한다. 결과적으로 80% 이상의 기업이 애자일 개발 방법론을 채택한다. 그러나 소프트웨어 주기를 관리하는 과정이 안전하지 않으면 ‘빠른 개발’은 사이버 범죄자가 악용할 수 있는 여러 기회로 이어진다.
 

애자일 개발은 속도, 협업, 의사소통, 상호작용을 중요시 여긴다. 기업이 애자일 개발을 더 안전하게 운영하려면 어떻게 해야 할까? ISF(Information Security Forum)가 권장하는 10가지 원칙을 살펴보자. 

1. 역할과 책임을 정의하라 

애자일 프로젝트 지휘에 책임이 있는 시니어 리더는 보안 활동의 책임과 역할을 명확하게 정의해야 한다. 여기에는 공식적, 비공식적 보고 라인과 함께 프로토콜 확대, 필수적인 회의, 보안팀에 프로젝트 상태 보고하기 같은 프로젝트 관리 활동 설정도 포함된다. 이를 통해 보안을 애자일 애플리케이션 개발 과정에 통합하는 동시에 IT팀과 보안팀 사이에 헌신, 책임, 건설적 관계를 조성할 수 있다. 

2. 기술과 훈련에 투자하라

보안은 일종의 단체 경기다. 모든 개발자는 코드에 보안적 허점이 없도록 보장하는 자신의 역할에 충실해야 한다. 개발자는 보안 문제에 대한 지식이나 이해도가 낮을 수 있고 보안보다 소프트웨어 배포를 더 우선하는 경향이 있다. 개발자에게 힘을 실어주기 위해 기업은 코칭, 멘토링, 기술 향상에 투자해야 한다. 여기에는 보안 훈련 및 인식 세션, 시니어 개발자의 멘토링, 특화된 애자일 보안 훈련 이벤트 제공과 OWAST, CWE(Common Weakness Enumeration), BSIMM(Building Security In Maturity Model), SAFECode, CERT 같은 무료 리소스에 대한 액세스가 포함된다. 

3. 정보 위험 관리 과정을 적용하라

케이크가 오븐에서 구워져 나온 이후 무언가를 추가하는 것보다는 오픈에 넣고 굽기 전, 즉 시작 단계에서 보안을 함께 고려하는 것이 비용도 적게 들고 효율적이다. 전체 개발 주기 안에서 정보 위험을 관리하는 데 도움이 되는 프로세스를 수립해야 한다.  

여기에는 보안 관점에서 수준이 높은 애플리케이션 아키텍처에 대한 합의, ‘보안이 중요한’ 애플리케이션 및 기능 목록 식별, 비즈니스 영향 평가 수행, 초기 단계에서 정보 위험과 취약점 평가 실시, 새로 식별된 위험 보고 프로세스가 포함된다. 기업은 정보 위험 소유자가 누구인지 지침을 제공하고, 위험 검토 프로세스를 정의하고, 위험 관리 의사결정 방법을 정해야 한다. 

4. 보안 요구사항을 명확히 하라

사용자 스토리, 소프트웨어 요구사항 정의서, 스토리 매핑, 와이어프레임, 페르소나, 사용례 등 다양한 포멧으로 보안 요구사항을 또렷하게 표현하라. 개발자가 보안 설명서를 더 잘 이해하고 정의하고 실행할 수 있다. 이를 통해 보안 요구사항을 제품 백로그에서 기능적 요구사항으로 취급해 작업으로 변환(분해)하며, 요구사항 관리 도구에 통합해 프로젝트의 생산성 지표에 포함할 수 있다. 

5. 위협 모델링을 수행하라

애플리케이션의 보안 맥락을 이해하기 위해서는 위협 모델링 연습을 정기적으로 수행해야 한다. 위협 모델링 연습의 목적은 안전하지 않은 설계의 면면을 발견하는 것, 위협을 식별/분석/우선순위화하는 것, 애플리케이션 공격에 가장 많이 쓰이는 기술과 방법(스푸핑, 탬퍼링, 서비스 부정, 권한 상승)을 알아내는 것, 어떤 위협이 추가 보안 테스트가 필요한지 식별하는 것이 대표적이다. 가장 중요한 것은 각 위협을 선제적으로 완화할 전략과 솔루션을 만드는 것이다. 

6. 보안 프로그래밍 기술을 사용하라

페어 프로그래밍, 리팩토링, CI/CD, 피어 리뷰, 보안적 반복, 테스트 중심 개발 등 이미 정립된 보안 프로그래밍 기술 활용을 의무화하라. 이렇게 하면 애플리케이션 코드의 비기능적 품질을 개선하고 향후 악용 가능성이 있는 보안 취약점을 허용하는 프로그래밍 결점을 제거할 수 있다. 보안 프로그래밍 기술은 보안 방법론에 경험이 많지 않은 개발자를 지도하는 데에도 유용하고, AI나 로우코드/노코드 같은 신기술을 사용하고, 복잡한 애플리케이션의 면면을 개발하고, 서드파티 애플리케이션을 통합하고, 규정준수 요구사항을 충족하는 데에 도움이 된다. 

7. 독립적 보안 리뷰를 수행하라 

독립적인 리뷰어에게 정적 코드 분석(애플리케이션 코드의 오류, 버그, 허점을 분석하기 위해 소스 코드를 리뷰하는 것)과 동적 분석(흔하지 않거나 예기치 않은 행동을 식별하는 수행 중 애플리케이션 행동 검사) 수행을 의뢰하라. 그러면 이해관계자가 애플리케이션이 보안 요구사항을 충족하고 여타의 보안 취약점이 없다는 점을 신뢰할 수 있다. 

8. 보안 테스트를 자동화하라 

보안팀이 모든 반복 작업을 수동으로 수행하면서 평가하는 것은 불가능하다. 그래서 애플리케이션 코드의 결함과 취약점을 지속적으로 점검하고 보완 관련 작업을 일관되고 체계적으로 수행하며, 보안 이벤트를 분석하고 보안팀과 개발자의 부담을 덜어줄 수 있는 자동화를 도입할 필요가 있다. 그러나 모든 것을 자동화할 수는 없으며, 자동화가 수동 테스트를 완전히 대체할 수도 없다. 예를 들면, 논리적 결함을 식별하기 위해서는 수동 리뷰가 필요하다. 

9. 승인 기준에 보안을 포함하라 

보안 승인 기준의 표준 세트를 만들어 공유 및 유지해야 한다. 또한 기준은 애플리케이션 코드에 대한 독립 리뷰가 수행되었는지, 보안 테스트가 완료되었는지, 애플리케이션에 통합된 코드 섹션을 유지/추적 가능한지, 신뢰할 만한 출처에서 검증되었는지, 반복 백로그의 요구사항이 성공적으로 충족되었는지, 보안 취약점을 포함한 모든 결함이 인지되고 보안에 영향을 미치는 모든 설계 변경이 식별/승인되었는지 확인한다. 이런 기준을 통해 기술 부채를 줄이고, 이해관계자에게 신뢰를 주고, 애플리케이션 코드가 배포되기 전에 승인 기준이 전적으로 충족되었음을 확인할 수 있다. 

10. 보안 성과를 평가하라 

보통 애자일 프로젝트에는 보안 성과에 대한 한정된 평가가 뒤따른다. 그래서 기업이 애플리케이션의 보안이 비즈니스 요구사항을 만족했는지를 확인하는 것이 까다로워진다. 그러므로 기업이 합의된 KPI 지표에 대해 적합한 보안 지표를 모니터링하고 평가하는 것이 중요하다. 보안 지표에는 유형, 숫자, 취약점 보안 수준, 독립 테스트 결과, 보안 정책에서 승인되고 미승인된 일탈 건수, 보안 유출 사고가 없는 기간, 그 외 결함 삭제 지표가 포함된다. 

기업의 개발 환경이 민첩하다면 정보 보안 역시 민첩하게 뒤를 따라야 한다. 모든 기업이 이상 소개한 10가지 원칙과 베스트 프랙티스를 따를 것을 권고하는 이유다. 보안 성공은 개발자, 프로젝트 관리자, 경영팀 등 모든 구성원 간의 협력과 헌신의 수준에 달려 있다. 보안 프로세스가 코딩하듯 빠르게 반복을 거듭하고 개선되어야 더 나은 애플리케이션 보안과 영향력 있는 변화를 업계에 전달할 수 있을 것이다.
editor@itworld.co.kr