효과적인 소프트웨어 보안 계획을 수립하는 5단계...

효과적인 소프트웨어 보안 계획을 수립하는 5단계 절차

(그리고 계획이 필요한 10가지 이유)

© 2017 Synopsys, Inc. | www.synopsys.com | a j b r 2

목차

6페이지: 소프트웨어 보안 계획이 필요한 10가지 이유

7페이지: 효과적인 소프트웨어 보안 계획의 청사진

9페이지: 보안 책임자가 알아야 하는 5가지

9페이지: 효과적인 SSI의 비결 11페이지: 5가지 주요 보안 정책

11 페이지: 인정받는 교육 프로그램 구성 요령

12 페이지: 개발 과정에 보안을 구현하는 도구

14 페이지: 지속적인 소프트웨어 보안 개선을 입증할 수 있는 10가지 중요한 척도

15 페이지: 고위 임원의 눈높이에 맞는 프리젠테이션

17 페이지: 외부 견해의 가치

20 페이지: 숫자 세기만큼 쉬운 SSI 설정

21 페이지: 맞춤형 샘플 로드맵

24 페이지: SSI 핵심 요약

https://www.synopsys.com/

https://twitter.com/synopsys

https://www.linkedin.com/company/synopsys

https://www.facebook.com/Synopsys/

https://www.youtube.com/user/synopsys


소프트웨어 보안 전략, 세우셨나요?

당신은 올해에만 46개의 웹 애플리케이션과 19개 모바일 앱, 20개 클라이언트 서버 앱을 테스트했습니다. 그리고 새 애플리케이션 보안 테스트 도구를 구입했습니다. 112개 취약점을 찾아냈습니다. 이 정도면 이미 훌륭하게 해내었습니다.

하지만 너무 뿌듯해하기 전에 자문해보세요. 위험이 크게 줄었나요? 아예 사라졌나요? 치명적인 취약점이 해결되지 않은 채 남아 있나요? 이사회는 당신이 하는 일이 얼마나 중요한지, 진행했던 일이 어떤 영향을 미쳤는지 이해하나요?

이러한 질문에 쉽게 답할 수 없다면 소프트웨어 보안 테스트 계획이 있다 하더라도 소프트웨어 보안 전략은 가지고 있지 않은 것입니다.

이미 애플리케이션 보안 테스트에 투자하고 있다면 위험 수준을 낮추기 위한 올바른 길에 들어선 셈입니다. 하지만 이제 다음 단계로 도약해야 할 때입니다. 소프트웨어 보안 전략(software security initiative-SSI)을 수립하여, 애플리케이션 보안 활동을 단순한 코스트 센터가 아닌 조직의 경쟁 우위 요소로 키워야 합니다.







다음 중 하나라도 경험한 적이 있다면 이 안내서를 읽어보시기 바랍니다.• 직감에만 의지해 보안 예산을 어디에 투입할지 결정했습니다.

• 보안 우선순위 지정과 문제 해결을 두고 개발 팀과 대립했습니다.

• 임원진이나 다른 부서에 보안 요구 사항을 전달하느라 애를 먹었습니다.

• 같은 팀에서 같은 보안 문제가 반복적으로 발견되었습니다.

• 용량 문제, 개발 일정이나 규제 변경에 대응하는 데 필요한 리소스를 급하게 찾아야 했습니다.

• 뒤늦게 애플리케이션 취약점 테스트 요청을 받고 제품 출시가 지연되었습니다.

• 보안 사고에 대한 뉴스를 접하고(Target, Wal-Mart, Sony, Neiman Marcus 등) “우리 회사에도 이런 일이 일어나지 않을까?”라고 생각했습니다.

• 과거에 형편없는 보안 계획 때문에 고생한 적이 있습니다.

• Secure SDLC가 없거나, 모범적인 소프트웨어 보안을 실천하는 벤더에 대한 정보가 부족하여 고객과의 거래가 지연되었습니다.

• 연방거래위원회 또는 다른 규제 기관으로부터 정밀 조사를 받은 적이 있습니다.

솔직하게 답해보세요. 답변이 녹음되지는 않으니까요.

위 항목 중 하나라도 해당한다면, 이 안내서의 검증된 절차에 따라 소프트웨어 보안 계획을 수립하고 발전시켜 기존의 보안 활동을 체계적이고 전략적이며 확실한 프로그램으로 재구성하시기 바랍니다.

이미 애플리케이션 보안 테스트를 실시하고 있는데... 이것만으로는 불충분한가요?한마디로 말해, 그렇습니다.

많은 사례 연구와 백서에서 애플리케이션 보안 테스트를 사실상 소프트웨어 보안 기법으로 제시합니다. 조직이 보안 문제를 심각하게 받아들인다는 증거로 내세우기 좋은 특효 처방인 셈입니다.

애플리케이션 보안 테스트는 모든 보안 프로그램에 필요한 아주 중요한 구성 요소입니다. 그러나 “penetrate & patch” 방식의 애플리케이션 테스트 자체는 보안 전략이 아닙니다. 애플리케이션 보안 테스트는 출발대일 뿐, 결승선이 아닙니다.







사전 예방적 보안은 시간과 비용을 절약해주지만 그것만으로 충분하지 않습니다. 보안프로그램은 전반적인 위협 노출빈도를 낮추기 위해 도입해야만 합니다.

(Forrester Research, Inc. 수석 애널리스트 Tyler Shields)







소프트웨어 보안계획이 필요한 10가지 이유

소프트웨어 보안 계획을 세우면 다음과 같은 여러 가지 장점이 있습니다.

1. 허용되지 않는 위험을 우선적으로 해결합니다.

2. 개발자가 중단을 최소화하여 안전한 소프트웨어를 만들 수 있는 길이 열리므로 생산성이 향상됩니다.

3. 특정 인물이나 그룹에게 소프트웨어 보안 위험을 감소시켜야 하는 책임을 부여하여 최선을 다해야 하는 환경을 조성합니다.

4. 공동의 우선순위와 책임, 계획을 기반으로 보안 팀과 개발 팀 사이에 공식적인 협업의 장을 마련하여 혼란을 줄이고 모두가 효율적으로 협력할 수 있도록 합니다.

5. 제품 관리자, 설계자, 개발자, 테스터, 그 외 모든 이해 관계자가 참여한 가운데 소프트웨어 보안 요구사항을 문서화하고 조율하여 조직 차원의 합의를 이끌어냅니다.

6. 내부 팀과 외부 벤더 등 소프트웨어 공급망에 관여하는 모든 사람에게 일관된 목표를 제시하므로, 시작점이 어디든 모든 소프트웨어가 안전하게 구축될 것으로 확신할 수 있습니다.

7. 정책, 표준, 도구, 전문가 등 모든 소프트웨어 보안 요구를 처리하는 ‘전문가 조직’을 구성하여 모두가 원하는 해답을 얻고 기술력을 향상할 수 있는 거점을 제공합니다.

8. 성공 여부를 측정하고 고객, 파트너, 이사회에 전달할 수 있습니다.

9. 소프트웨어 개발 체인의 모든 이해 관계자와 꾸준하게 접촉하고 교육을 제공하여 보안을 중시하는 문화를 육성합니다.

10. 개발 팀의 변화하는 요구를 반영하는 동시에 위험을 관리합니다.







효과적인 소프트웨어 보안 계획의 청사진 가장 효과적인 SSI는 조직의 특성에 따라 정교하게 다듬어지고 직원, 프로세스, 소프트웨어 포트폴리오를 중심으로 확장할 수 있는 것입니다. SSI는 투자 결정을 내린 근거를 설명하고 위험을 줄이기 위한 합리적이고 명확한 방법을 알려줌으로써 앞으로 나아가야 할 “방향을 제시하는” 지표입니다.

소프트웨어 보안 계획을 세우기 위한(또는 기존의 계획을 되살리기 위한) 확고한 기반을 마련하는 가장 좋은 방법은 다음과 같이 5단계로 구성됩니다.

1. 구축(Build)

2. 측정(Measure)

3. 확인(Verify)

4. 개선(Improve)

5. 관리(Manage)







구축







구축

SSI의 확고한 토대를 마련하려면 우선순위를 지정하기 위한 주요 정보, 거버넌스 구조, 개발 주기에 보안을 통합하기 위한 교육과 도구 등이 필요합니다.

이러한 요소에 대해 하나씩 자세히 알아보겠습니다.

보안 책임자가 알아야 하는 5가지애플리케이션 보안 활동에 필요한 우선순위를 지정하려면 해야 할 일의 범위를 완벽하게 이해해야 합니다.

알고 계신가요...

1. 현재 어떤 개발 프로젝트를 진행 중이고, 기한은 언제인가요?

2. 어떤 팀이 어떤 애플리케이션을 진행하고 있나요?

3. 내부, COTS 또는 타사에서 어떤 코드를 개발하나요?

4. 가장 심각한 기술적 위험은 어디에 있나요?

5. 애플리케이션 인벤토리는 어떻게 구성되어 있고, 무엇이 비즈니스에 가장 큰 영향을 미치나요?

지금부터 알아봅시다.

이와 같은 물음에 바로 대답하지 못해도 괜찮습니다. 최근 SANS Institute 연구에 따르면 응답자의 1/4 이상이 조직에서 몇 개의 애플리케이션을 사용하거나 관리하는지 파악하지 못하고 있습니다.

현재 알고 있는 것에서부터 출발하여, 지식의 인벤토리를 계속 구축하면 됩니다.

효과적인 SSI의 비결 The Secret to a Rock-Solid SSI 성공적인 SSI의 비결은 거버넌스에 있습니다. 거버넌스는 보안 활동에 대한 책임을 부여하고 행동에 대한 기대 수준을 설정하기 때문에, 지속 가능한 SSI를 위한 토대를 마련하거나 정확한 크기를 산정하기 위해 반드시 필요한 절차입니다.

공식 정책과 명시적 표준, 체계적인 프로세스를 통해 중앙의 보안 그룹에서 거버넌스를 수립하든, 애플리케이션 팀을 위한 기술 및 코딩 표준에 따라 스크럼 마스터가 수립하든 차이는 없습니다. 사실 누군가 책임을 져야 하고 소프트웨어 보안에 관한 기대 수준을 의무화해야 합니다. 그렇지 않으면 ‘Secure SDLC’를 보장할 수 없습니다.

주의하세요! 외부와 단절된 상태에서 보안 정책을 수립하면 안 됩니다.

궁극적 책임은 보안 책임자가 져야 하겠지만, 회사의 다른 책임자들과 애플리케이션 보안에 대해 폭넓게 논의하고 조직 전체에 배포해야 합니다. 무엇보다, 개발 팀을 조기에 투입하여 정책 수립과 시행에 대한 주인의식을 공유하도록 해야 합니다.

위험 = 가능성 x 영향

(이 공식을 수백 번은 보셨으리라 짐작하지만, 또다시 거론할 수밖에 없었습니다. 왜냐하면 불변의 진리이기 때문입니다.)

비즈니스에 영향을 미치는 애플리케이션 요소:

• 수입(revenue)과의 관계

• 비즈니스 연속성에 미치는 영향

• 규제 준수 또는 요구사항

• 서비스 대상

• 애플리케이션에서 저장하거나 액세스하는 민감한 데이터의 양

• 액세스 방법

• 다른 시스템과의 연결/통합

• 인적 안전성

• 국가 안보

먼저, 각 요소에 포인트 값을 부여하면서 시작합니다. 애플리케이션의 각 요소에 부여된 포인트를 더합니다. 애플리케이션을 비즈니스 위험 수준 “높음”, “중간”, “낮음”으로 나누어 우선순위를 정합니다.






https://www.sans.org/reading-room/whitepapers/analyst/survey-application-security-programs-practices-35150


구축

대부분의 기업에는 Secure SDLC가 없습니다. 이유는, 주장과 달리 실제 대다수 기업에 소프트웨어 보안 거버넌스가 없을 뿐 아니라 애플리케이션 포트폴리오의 보안 태세에 대한 체계적인 통제가 불가능하기 때문입니다.

이런 기업이 되지 마세요.

고객, 보험사, 규제 기관 중 어떤 곳에서도 반기지 않습니다. 그리고 많은 기업이 곧 경험하겠지만 임원진과 이사회도 달가워하지 않습니다.

그럼, “보안”정책의 부재가 어떤 영향을 미치는지 살펴보겠습니다.

1. Security Tracker2. 비즈니스 혁신 및 기술 부서3. 2014 사이버 범죄 비용 연구

5770

$1.7

미국 사업체의 57퍼센트가 사이버 보안 정책을 적용하지 않습니다.1

보안 정책을 제대로 이해하지 못한 기업의 70퍼센트가 직원과 관련된 보안 사고를 당했습니다.

(정책을 제대로 이해하는 기업의 사고율은 41%)2

MILLION

적절한 리소스에 투자하고, 높은 수준의 보안 책임자를 임명하고, 인증받은 전문가나 직원을 고용한 기업은 170만 달러에 해당하는 사이버 범죄 “비용 절감” 효과를 거두었습니다.3







구축

5 가지 주요 보안 정책

1. 소프트웨어 보안. 회사 내에서 소프트웨어 보안을 실현하기 위한 고위급 임원의 기대 수준을 구성원들에게 전달하고 제품 요구사항, 구현, 조달, 배포, 운영 부서에 보안을 통합합니다. 최소한 다음 주제를 다룹니다. Secure SDLC. 사용은 선택이 아닙니다. 애플리케이션 위험 순위. 어떤 애플리케이션이 비즈니스에 가장 중요한지 판단할 수 있는 명확한 지침을 제시합니다. 애플리케이션 설계. 시스템 설계에 보안 제어의 통합을 의무화합니다. 애플리케이션 개발. 특정 기술 스택과 의무 코딩 표준을 요구하고 개발자에게 명확한 지침과 사전에 구축된 보안 최적 설계, 즉 ‘secure-by-design’ 모듈을 제공합니다. 애플리케이션 테스트. 어떤 애플리케이션을 테스트해야 하는지, 어떤 관문을 통과해야 하는지 결정하고 테스트 주기 일정을 정합니다. 소프트웨어 프로젝트 영향 순위. 소프트웨어 프로젝트의 영향 순위를 정의하고 이 순위에 따라 어떤 보증 활동이 수반되는지 개괄합니다. 결함 심각도 및 수정. 버그와 오류 심각도가 정해지는 규칙, 코딩 버그와 설계 오류의 수정 일정을 수립합니다. 소프트웨어 보안 정책과 기타 정책을 조화롭게 유지합니다.

2. 네트워크 보안. 애플리케이션 보안에 도움을 주는 프로토콜과 인증 수준을 결정합니다.

3. 데이터 보안. 중요한 IP와 민감한 고객 데이터를 식별하고 분류하여 개발자가 적절한 보안 기능을 적용하도록 합니다.

4. 물리적 보안. 액세스 제어를 관리하고 물리적 인프라를 보호합니다.

5. 재해 복구. 보고, 기록, 해결책 등 애플리케이션에 공격 이벤트가 발생할 경우 취해야 할 조치를 정의합니다.

인정받는 교육 프로그램 구성 요령소프트웨어 개발 수명 주기에 관여하는 모든 이가 각자의 역할에 따라 소프트웨어 보안 의무를 이행하는 방법을 알아야 합니다. 임원진, 중간 관리자, 제품 담당자, 테스터, 시스템 설계자, 개발자, 그 외 모든 관계자가 여기에 해당합니다.

개발자가 인센티브를 자신의 경력 관리의 일부로써 중요하고 가치 있는 것으로 받아들여질 수 있도록 실적 평가 및 보상에 인센티브 제도를 포함시켜야 합니다.







구축

왜 개발자인가?

OWASP(Open Web Application Security Project)에서는 IT 보안에 대한 인식 수준을 높이기 위해 3년마다 10대 웹 애플리케이션 보안 취약점을 발표합니다. SQL 인젝션, 크로스 사이트 스크립팅처럼 잘 알려진 보안 취약점은 매번 빠지지 않고 등장합니다. 그런데도 소프트웨어 개발자는 이러한 취약점을 애플리케이션에 수도 없이 계속 코딩합니다.

효과적인 SSI는 코드가 쓰이는 시점, 즉 코어에서 애플리케이션 보안을 관리해야 합니다. 버그와 오류를 애플리케이션 빌드에서 최대한 일찍 제거할수록 QA 단계에 시간과 비용을 들여 해결해야 할 필요가 적어집니다. 따라서 보안이 보장된 애플리케이션은 시장 출시 시기를 앞당길 수 있고, 경쟁 우위를 확보할 가능성도 커집니다.

SSI 계획에 인센티브를 반영하여, 개발자가 단순히 기능을 구현하는 데 그치지 않고 보안 코드를 개발하는 능력을 키울 수 있도록 동기를 부여해야 합니다. 온라인과 오프라인 교육 프로그램을 통해 개발자를 지원할 수 있습니다. 달리 말해, 개발자의 경력 관리에서 인센티브가 중요하고 가치 있는 것으로 받아들여질 수 있도록, 성능 평가와 보상에 이를 포함해야 합니다.

개발 과정에 보안을 구현하는 도구동적 분석, 정적 분석, 퍼지 테스트, 그 외 여러 도구는 보안 팀이 지속적으로 광범위한 취약점을 찾아내는 데 도움이 됩니다. 한마디로 이러한 유형의 도구는 문제 해결에 시간과 비용이 많이 필요한 시점, 즉 이미 배포된 애플리케이션이나 사전 프로덕션 빌드에서 문제를 찾아내는 데 사용됩니다.

Secure SDLC에 보안이 “유지되도록” 하는 데 도움이 될 도구를 찾아보세요. 보안 테스트와 수정 문제를 일찍 해결할수록 비용 효과와 생산성이 높아집니다.

개발자의 기존 워크플로우와 기술에 보안 도구를 바로 통합하면 처음부터 보안 코드를 작성하도록 도움을 줄 수 있습니다(예: 통합 개발 환경). 새로운 도구로 인해 개발자가 프로세스를 변경해야 하거나 선호하는 시스템을 포기해야 한다면 사용을 유도하기가 어려울 것입니다.

조기에 결함을 해결했더니

생산성이 15%나 높아졌습니다

-Aetna 최고 정보 보호 책임자, Jim Routh






https://www.owasp.org/index.php/Main_Page


측정







측정

많은 사람들이 소프트웨어 보안 수준을 측정할 수 없다고 생각합니다. 어떤 일이 일어나지 않는다는 것을 어떻게 측정하겠습니까?

무언가 존재하는지 아직 알지 못한다는 이유만으로 존재하지 않는다고 단정 지을 수는 없습니다. 그리고 보안 침해 같은 것이 아직 발생하지 않았다고 해서 앞으로도 일어나지 않으리라는 보장은 없습니다.

해커가 조직에 침투하지 못하도록 막았다는 사실을 입증하지 못하더라도 소프트웨어 보안 계획의 효과를 입증할 방법은 많습니다.

내부 메트릭은 비즈니스 목표를 달성하기 위한 지속적 개선에 기여합니다.

SSI 목표를 수립할 때 기본적인 비즈니스 목표를 반영하세요. 이런 식으로 하면, 결과를 공유할 때 궁극적으로 SSI가 조직의 운영 방식을 어떻게 바꾸었는지 보여줄 수 있습니다. 보안 프로그래밍을 통해 운영 프로세스를 개선할 뿐만 아니라, 소프트웨어 출시 시기를 앞당기고 비용을 절약하고 있다는 점을 이사회에 입증하면 여러분의 업무는 반복적인 “확인란 체크” 작업에서 중요한 비즈니스 직능으로 격상될 것입니다.

지속적인 소프트웨어 보안 개선을 입증할 수 있는 10가지 중요한 척도

1. 항목마다 강력한 특성과 위험 데이터를 포함하는 소프트웨어 인벤토리 통용

2. 테스트 주기와 상관없이 테스트를 실시한 모든 애플리케이션의 비율

3. 각 유형과 수준의 위험 기반 테스트를 실시한 애플리케이션 개수(없음부터 가벼운 테스트, 정밀 테스트까지)

4. 소프트웨어 보안 정책이나 규제 준수 요구사항에 부합하지 않기 때문에 요구되는 분산 수치

5. 다양한 유형의 보안 결함을 수정해야 하는 시점

6. 생산 단계까지 해결되지 않은 보안 버그와 설계 오류의 수

7. 개발이나 조달 등, 모든 Secure SDLC 게이트를 통과하는 소프트웨어 프로젝트 비율

8. 개발자가 취약점 수정 이외의 활동에 할애하는 시간

9. 요구사항 단계에서 생산 단계까지, 소프트웨어 보안 문제로부터 파생된 지연 빈도

10. 규제 요구사항을 충족하거나 초과하는 애플리케이션 개수

11. 해당 직무에 적합한 기술 수준을 보유한 소프트웨어 보안 이해 관계자의 인원수

쓰다 보니 10가지가 아니라 11가지가 되었습니다. 하지만 모두 중요하기 때문에 어쩔 수 없습니다.

“증거가 없다는 사실이 곧 그것이 없다는 증거는 아니다.”

- 천문학자 Carl Sagan







측정

고위 임원의 눈높이에 맞는 프리젠테이션

임원진이 이해하고 인정하는 측정 기준에 초점을 맞추면 소프트웨어 보안 계획에 대한 지속적인 지원을 얻을 가능성이 커집니다. 그렇지 않으면 추가 리소스에 대한 주장을 펼쳐야 합니다.

외부 메트릭을 활용하면 더욱 폭넓은 SSI 분야와 대조해볼 수 있습니다.

다른 조직의 SSI와 비교함으로써 내부의 개선 정도를 입증할 수 있을 뿐 아니라, 고위 임원진들에게 현재 진척 정도에 대한 거시적 관점을 피력할 수 있습니다. 직설적으로 말해, 다른 기업의 상황을 엿보는 것은 기업의 경영진이 보안을 진지하게 받아들이게 만드는 강력한 유인책입니다.

소프트웨어 보안 계획을 세우기 위한 도구로 널리 사용되는 업계 최고의 모델 중 하나는 BSIMM(Building Software Security In Maturity Model)입니다. BSIMM 프로젝트는 모든 유형의 조직이 도입했으며 소프트웨어 보안을 향상한 것으로 입증된 소프트웨어 보안 사례를 벤치마킹합니다. 데이터-백엔드 보안 업계 표준과 귀사의 프로그램을 비교한 결과를 알 수 있습니다.

BSIMM 평가를 수행하고 커뮤니티에 참여하는 방안을 고려해보세요. 측정이 이루어지는 원리를 확인할 수 있을 뿐 아니라 SSI를 구축한 사람들과 지속적인 교류를 할 수 있습니다. 계획을 수립하는 경험을 통해 많은 것을 배울 수 있습니다.

BSIMM에 대해 자세히 알아보기(HTTPS://WWW.BSIMM.COM/)






https://www.bsimm.com/







확인







확인

이제 정책과 측정 계획을 수립했으므로 SSI에 정의한 활동과 요구사항이 제대로 이루어지고 있는지, 기대한 효과를 발휘하는지 확인할 체크포인트를 마련할 시점입니다.

말하자면, 확인 단계는 자동차 검사에 비유할 수 있습니다. 자동차는 일 년에 한두 번 안전 검사를 통과해야 합니다. 그러나 “엔진 체크등”이 켜지면 곧 정비소에 차를 맡겨 무슨 문제가 있는지 확인하기 위한 몇 가지 점검을 받습니다.

결함 검사는 마치 자동차의 “엔진 체크등”과 같습니다. 시스템에 문제가 생겼으니 가능한 빨리 해결해야 한다는 경고입니다.

개발 주기가 끝날 때까지 기다렸다가 간신히 시간을 내어 복잡한 보안 테스트를 실시하는 대신, 중간 중간에 간단한 테스트를 수행할 수 있습니다. 달리 말해 “이 소프트웨어를 출시하기에 너무 위험하지 않은지 확인해보자”에서 “이 소프트웨어가 목표한 대로 실행되는지 확인해보자”로, 테스트에 대한 철학을 바꾸는 것입니다.

워터폴 개발 방식을 도입한 기업은 요구사항 단계, 아키텍처 단계, 코딩 단계, QA 단계에 테스트를 추가합니다. 애자일 방식은 사용자 스토리에 보안을 통합하고, 개발자가 문제를 찾아내 순조롭게 해결할 수 있도록 하는 것입니다.

출시 전 보안 단계는 훨씬 짧으므로 SSI가 제대로 작동하는지 알아보기 쉽습니다. 더 이상 용량 소모와 출시 지연을 가져오고 모두에게 악영향을 미치는 수준의 보안 문제가 대규모로 확산하는 현상은 없을 것입니다.

외부 견해의 가치

내부에서 평가와 문제 해결 작업을 진행하는 경우, 때때로 외부의 견해를 참조하는 것이 좋습니다. 외부 테스트 파트너는 테스트 결과가 정확한지, 기본 시스템이 공격을 방어할 수 있는지 추적하여 전문적인 견해를 제공합니다.

애플리케이션 테스트 벤더는 내부 도구만으로는 찾아낼 수 없는 취약점을 찾아낼 수동 테스트 전략과 필요한 도구를 갖추고 있습니다. 이들은 결과를 조합해 의심스러운 지점을 확인하고 거짓 양성을 제거합니다. 무엇보다, 결과를 해석해 내부 팀이 찾아낸 모든 문제를 해결할 수 있도록 돕습니다.

경고

여기에서 멈추면 안 됩니다! 결함 검사가 SSI라면, 발전할 여지가 없습니다.

“이 소프트웨어를 출시하기에 너무 위험하지 않은지 확인해보자” 에서 “이 소프트웨어가 목표한대로 실행되는지 확인해보자”로 테스트에 대한 철학을 바꾸세요







개선







개선

소프트웨어 보안 계획 수립은 한 번에 끝내는 활동이 아닙니다. 패턴을 지속적으로 관찰하고 정밀한 대응 전략을 짜야 합니다.

교육에 더욱 집중해야 하나요?

새로운 코딩 표준이 필요한가요?

실행 계획을 더 효과적으로 만들 수 있을까요?

현재 실행 중인 테스트를 수정해야 하나요?







개선

숫자 세기만큼 쉬운 SSI 설정SSI 설정은 한 번에 끝내는 활동이 아닙니다. 실제 환경에서 일상적인 압박을 견디며 처음의 SSI 구조로 작업하다 보면, 개선이 필요한 영역이 분명 발견될 것입니다. 사용할 수 있는 도구나 기법과 마찬가지로 공격의 수준도 날로 진화하고 있습니다.

1. 패턴을 관찰합니다. 확인 과정 중에 동일한 보안 문제가 계속 발견되는 경우, 표준을 수정하고 교육 수준을 높이거나 개발자에게 더욱 효과적인 도구를 제공해야 할 수 있습니다. 또는 취약점이 근본적인 설계 오류로부터 비롯되었음을 감지한 경우, 설계 팀에 아키텍처 변경을 요구해야 합니다.

2. 탄력적 용량을 준비합니다. SSI는 포트폴리오를 구성하는 애플리케이션 개수와 유형 변경, 조직 구조 변화, 규제 요구사항 개정, 새로운 공격 벡터의 등장에 따라 능동적으로 대응할 수 있는 유연한 프로그램이어야 합니다. 애플리케이션 테스트에 대한 요구가 내부 용량을 초과하는 상황이 불가피하게 발생할 것입니다. 훌륭한 테스트 파트너를 찾으면 내부 팀의 부담을 덜고, 모든 애플리케이션에 걸쳐 일관된 테스트와 문제 해결을 보장할 수 있습니다.

3. 미래를 위한 로드맵을 마련합니다. 다음과 같이 모든 소프트웨어 보안 기능에 대한 전문성으로 무장한 SSI가 최대한의 성능을 발휘하는 세상을 상상해보세요.

• 위험 및 규제 준수

• 오픈 소스 관리

• 벤더 관리

• 보안 아키텍처 설계 검토

• 애플리케이션 보안 테스트

• 보안 코드 검토

• 결함 관리

모든 역량에 대해 같은 수준으로 전문성을 구축할 필요는 없습니다. 하지만 SSI가 비즈니스 우선순위로 발전할 수 있도록 기준을 세워 주기적으로 진척 현황을 점검해야 합니다.







개선

이제 성공적인 SSI의 마지막 단계인 관리가 남았습니다.

계획적인

활동...

위험 및 규제 준수

IT 운영

정책과 표준

메트릭

S-SDLC와 게이트

포트폴리오 관리

오픈 소스 관리

벤더 관리

결함 관리

SSG 배포

공격 지능

역량 관리 위성

보안 최적 설계

결함 검사

맞춤형 샘플 로드맵

2015 2016 2017 2018







관리







관리

지금까지 살펴보았듯이 효과적인 SSI는 유동적인 요소와 다양한 구성원, 부서의 참여로 이루어집니다. 키를 쥔 캡틴으로서 여러분의 의무는 모두가 안전하게 항해를 마칠 수 있도록 지휘하는 것입니다.

구조를 유지하고 각각의 보안 활동에 대한 통찰을 얻으려면, 목표 달성에 기여할 효과적인 프로젝트 관리 시스템을 마련해야 합니다.

개발 수명 주기의 보안 테스트, 소프트웨어 출시 및 업그레이드 일정에 보안 활동을 쉽게 결합할 수 있는 시스템을 찾아보세요. 일반적인 프로젝트 관리 도구보다, 보안 전용 도구를 사용하면 시간이 절약되고 SSI 내에서 관리되는 주요 요소를 놓치지 않을 수 있습니다.

최적의 시스템을 도입하면 시간 경과, 애플리케이션 유형, 비즈니스 부서, 특정 프로젝트에 따른 비교를 수월하게 진행할 수 있습니다. 한눈에 진행률을 추적하고, 어떤 지점이 목표에 못 미치는지, 어떤 영역에 특별한 주의가 필요한지 알 수 있을 것입니다.

그뿐만 아니라 경영진에게 보고할 시의적절하고 정확한 데이터를 확보할 수 있습니다.

결론모든 SSI는 상급 조직의 구조와 문화를 반영합니다. 어떤 기업은 중앙 집중식 관리를, 다른 조직은 분산식 관리를 선호합니다. 일부 조직은 외주 리소스에 의존하는 데 비해, 다른 조직은 신규 직원을 충원합니다. 관리 서비스를 선호하는 조직이 있는가 하면, 자체 기술 팀 육성에 치중하는 조직도 있습니다.

지금까지 살펴본 5단계 프로세스는 성공을 돕는 지침서입니다. 이 지침을 활용하면 개발 주기에 관여하는 모든 이해 관계자들의 의견을 효과적으로 조율하고, 비즈니스 목표에 기여하는 정도를 증명하는 한편, 장기적으로 활용할 수 있는 효과적인 프로그램을 도입할 수 있을 것입니다.

보안 전용 도구를 사용하면 시간이 절약되고 SSI 내에서 관리되는 주요 요소를 놓치지 않을 수 있습니다.

SSI를 수립할 준비가 되었지만 어떻게 시작할지 막막하다고 느끼나요? 여러분에게 필요한 모든 것을 통합하여 준비했습니다.

이를 SSI-In-a-Box(Software Security Initiative In-a-Box)라고 합니다.

자세히 알아보세요.

SSI-IN-A-BOX에 대해 자세히 알아보겠습니다.






https://www.synopsys.com/software-integrity/software-security-strategy/software-security-initiative.html




1. 구축• 애플리케이션 포트폴리오, 규제 요구사항, 기술 및 비즈니스 위험 영역에 대한 정보를 수집합니다.

• 책임을 분배하고 경영진의 지원을 받는 정책을 마련하는 등, 거버넌스 구조를 수립합니다.

• 내부 팀 및 벤더와 폭넓게 소통합니다.

• 내부와 외부의 적임자를 동원하여 SS에 정의된 평가 및 문제 해결 활동을 수행합니다.

• 직원이 보안 능력을 개선할 기회를 마련하고, 인센티브를 통해 자연스럽게 유도합니다.

2. 측정• 측정 결과를 통해 지속적인 발전을 입증하고 비즈니스 목표와의 연관성을 밝힙니다.

• 보안 활동과 BSIMM(Building Security In Maturity Model)을 비교하고 커뮤니티에 참여합니다.

3. 확인• 최종 단계까지 기다리는 대신, 개발 프로세스 전반에 걸친 결함 검사 체크포인트를 마련합니다.

• 내부 결과와 외부 분석 결과를 비교하여 정확성을 보장하고 탐지 오류의 가능성을 줄입니다.

4. 개선• 추가 리소스, 교육, 지속적인 투자가 필요한 영역과 패턴을 파악합니다.

• 소프트웨어 보안 기능에 대한 전문성을 키울 로드맵을 마련합니다.

5. 관리• SSI 관리와 조정에 유용한 보안 전용 프로젝트 관리 도구를 마련합니다.

• 팀의 성과와 애플리케이션 유형을 분석, 비교합니다.

• 경영진 및 조직 전체의 모든 이해 관계자에게 진척 현황을 보고합니다.

SSI 핵심 요약







SYNOPSYS의 차별점

Synopsys는 고객의 소프트웨어 개발주기(SDLC)와 소프트웨어 공급망 관리(SCM)에 자연스럽게 통합하여, 소프트웨어의 보안성과 품질을 강화할 수 있는 가장 종합적인 솔루션을 제공합니다. 전통적인 테스트 서비스를 뛰어 넘어 고객이 애플리케이션의 취약점을 탐지, 수정, 예방하여 비스니스를 강화할수 있도록 도와줍니다.

Synopsys는 통합적인 애플리케이션 보안 접근법을 갖고 제품과 전문 관리 서비스 등을 적절히 밸런싱하여 제공하기 때문에 고객의 특정한 요구 사항에 모두 대응할 수 있습니다. 또한, 단순히 테스트에만 국한되지 않고, Synopsys의 보안 전문가들을 통해 개선 가이드, 프로그램 디자인 서비스, 트레이닝등을 통해 안정된 애플리케이션을 유지 관리할 수 있도록 도와줍니다.

자세한 내용은 www.synopsys.com/software에서 확인할 수 있습니다.

185 Berry Street, Suite 6500San Francisco, CA 94107 USA

시높시스코리아(Synopsys Korea)경기도 성남시 분당구 판교역로 235에이치 스퀘어 N동 5층대표번호: 02-3404-2700이메일: [email protected]






효과적인 소프트웨어 보안 계획을 수립하는 5단계...

Documents