보안 소프트웨어 개발에서 소프트웨어 보안 강화까지

편집자 주: 유감스럽게도 소프트웨어 개발 공급업체에서는 소프트웨어 수명 주기(SDLC)의 초기 단계에서 보안 고려 사항을 무시하는 것이 일반적입니다. 결과적으로 이전 단계의 취약점이 소프트웨어 개발의 다음 단계로 넘어가 최종 제품에 부정적인 영향을 미칩니다. 개별 소프트웨어 개발에 대한 다년간의 경험을 통해 전문가는 안전한 소프트웨어 개발을 위한 실용적인 팁을 제공합니다. 그러나 이론적인 수준뿐만 아니라 실제적인 수준에서도 지원이 필요하면 저희에게 편지를 보내주십시오.

안전한 소프트웨어 개발을 위한 모범 사례 권장 소프트웨어 개발의 모든 단계에서 보안 측면 고려: 요구 사항 분석에서 유지 관리까지. 이러한 권장 사항을 무시하면 조직의 후속 초점은 사후 취약성 수정 및 소프트웨어 보안 개선에 두게 되며 이는 종종 매우 비용이 많이 들고 달성하기 어렵습니다.

황금률은 매우 간단합니다. 초기 보안 측면이 개발 프로세스에 통합될수록 나중에 보안 취약성을 수정하는 데 드는 비용이 줄어듭니다.

안전한 소프트웨어 개발로의 전환을 단순화하기 위해 소프트웨어 수명 주기(SDLC)의 어느 단계에서 어떤 보안 조치(철저한 주장 없이)를 취할 수 있는지 설명하는 단계별 가이드를 만들었습니다.

계획 및 요구 사항 분석

프로젝트 초기에 안전과 관련하여 고객의 기대치와 개발 프로세스에서 고려해야 할 사항을 명확히 해야 합니다. 여기에는 보안 지침 수립 그리고 보안 요구 사항의 명확한 정의, 보안 검사를 가능한 한 빨리 시작할 수 있습니다. 고객 요구 사항을 충족하면서 안전한 소프트웨어 개발을 보장하려면 다음 단계를 권장합니다.

• 사용 사례와 남용 사례를 함께 사용하십시오.

남용 사고는 소프트웨어에 대한 가능한 위협을 예상하고 대비하는 데 도움이 됩니다. 사용 사례는 오용 가능성이 있는 경우 어떤 미래 지향적 조치를 취해야 하는지 설명합니다.

예를 들면 다음과 같습니다.

학대 사건: 권한이 없는 사용자가 고객의 소프트웨어에 액세스하려고 합니다.

적절한 사용 사례: 이러한 모든 시도는 SIEM 시스템에 의해 기록 및 분석되어야 합니다.

• 보안 위험 평가 및 위험 프로필 생성

보안 위험을 평가하고 분석하는 데 도움이 되는 다양한 보안 지침 및 표준(예: 의료 부문의 경우 HIPAA 또는 금융 부문의 경우 SOX)이 있습니다.

요구 사항 분석 단계에서 비즈니스 분석가는 보안 전문가와 긴밀히 협력해야 합니다. 위험 프로필 지원서 제공하다. 이 문서는 응용 프로그램의 어떤 구성 요소가 심각도에 따라 우선 순위가 지정되어 악의적인 공격 및 보안 위험에 취약한지 설명합니다.

설계

설계 단계에 있습니다 여섯 가지 안전 원칙 보안 소프트웨어:

• “최소 권한” 원칙(또는 최소 원칙). 이 원칙에 따르면 작업을 완료하는 데 실제로 필요한 권한만 사용자에게 할당해야 합니다. 그 이상도 그 이하도 아닙니다.
• 권한 분리(또는 권한 분리). 이 설계 원칙은 제한된 수의 사용자만 권한을 할당하여 소프트웨어의 특정 기능(예: 만들기, 삭제)에 액세스할 수 있도록 허용합니다.
• 전체 액세스 제어. 소프트웨어에 대한 모든 사용자 액세스 권한을 확인해야 합니다. 이는 권한을 상승시켜 제한된 권한을 가진 사용자를 방지합니다(권한 에스컬레이션) 권한이 없는 리소스에 액세스할 수 있습니다.
• 여러 계층의 보안. 이 원칙은 위험을 줄이는 방법을 제공합니다. 단일 장애 지점 (SPoF) 보안 측면에서 (m그것 SPoF, 개별 구성 요소의 오류는 전체 소프트웨어를 손상시키거나 충돌을 일으킬 수 있습니다). 방법은 매우 간단합니다. 소프트웨어의 보안 계층이 많을수록 해커가 취약점을 악용할 가능성이 줄어듭니다.
• 안전한 실패. 소프트웨어가 실패하면 안전한 상태여야 합니다. 소프트웨어가 더 이상 얻기 쉬운 여전히 다음과 같은 정보 보안의 다른 핵심 가치를 반영해야 합니다. 기밀 그리고 진실성 보장하다. 이는 소프트웨어가 안전하지 않은 구성 요소를 비활성화할 수 있는 안전한 기본 설정으로만 배송되어야 함을 의미합니다.
• 사용자 친화적인 보안. 보안 측면을 고려할 때 보안 메커니즘은 사용자 경험을 손상시키지 않도록 사용자 친화적으로 설계되어야 합니다. 이러한 메커니즘이 방해가 되는 경우 사용자가 이를 비활성화할 가능성이 높습니다.

개발

회사를 설립할 수 있습니다. 모범 사례 그리고 표준 예를 들어 OWASP(Open Web Application Security Project) Top 10과 같은 안전한 개발을 위해. 소프트웨어 개발에 어떤 보안 위험이 있는지, 어떤 조치를 취해야 하는지, 필수 구현 사양을 준수하고 준수 여부를 확인하는 데 사용되는 도구는 무엇인지 설명합니다. 어떤 프로그래밍 언어와 상관없이 안전한 코드 생성을 위한 표준 생성되며 이들은 반드시 반드시 다음 영역을 포함해야 합니다.

• 액세스 제어
• 인증 및 세션 관리
• 데이터 검증(입력 및 출력)
• 오류 처리 및 로깅
• 데이터 보안 및 암호화.

모든 관행과 표준은 주로 회사를 돕는 것을 목표로 합니다. 취약점 가능한 한 빨리 피하거나 제거하십시오.

테스트

테스트 단계는 주로 지정된 요구 사항(기능적 및 비기능적 모두)과 그 효율성을 확인하고 오류를 식별하고 제거하는 데 중점을 둡니다. 검사를 구현하기 위해 다양한 테스트 방법이 사용됩니다. 그들 중 일부는 할 수 있습니다 시 구현(예: 단위 테스트, 정적 코드 분석, 코드 검토, 설계 검토 등).

직접 배달 전에 제품 침투 테스트가 진행됩니다. 취약점을 발견하기 위해 개발된 제품이 가능한 보안 공격에 취약한지 여부를 판단하는 데 도움이 됩니다. 마지막으로, 발견된 취약점에 대한 정보를 포함하고 이를 제거하는 방법에 대한 제안을 제공하는 자세한 보고서가 있습니다.

소프트웨어 제공 및 유지보수

프로덕션 서버에 소프트웨어를 안전하게 배송하고 설치하려면 다음 단계를 수행하는 것이 좋습니다.

• 사고 대응 계획(IRP)을 만들고 계획되지 않은 보안 사고 및/또는 중단에 대응하는 방법을 제공하고 사고가 발생할 때 취해야 할 조치에 대한 지침을 제공합니다. 이러한 신뢰할 수 있는 계획을 통해 발생한 사고에 조기에 대응하고 효과적으로 관리 및 해결할 수 있습니다.
• 최종 보안 검사를 실시합니다. 이 검사는 소프트웨어가 보안 관점에서 사용할 준비가 되었는지 확인해야 합니다. 성공적으로 완료된 후에야 제품이 게시됩니다.
• 보안 변경 관리 계획 만들기 생성된 제품의 기능에 부정적인 영향을 미치지 않도록 모든 변경 사항을 제어합니다.
• 최종 제품을 인증합니다. 이 인증은 모든 소프트웨어 요구 사항이 충족되었음을 보장합니다.

고객에게 제품을 인도한 후 유지 관리 단계가 시작됩니다. 유지 보수 활동은 보안 문제가 발생하지 않도록 업데이트 후 정기적으로 제품을 점검하고 성능, 보안성, 사용성 등을 모니터링하고 재평가하는 활동입니다.

보안 비용

보안 소프트웨어 개발에는 의심할 여지 없이 추가 비용이 수반되며 보안 전문가의 집중적인 참여가 필요합니다. 하지만 그래도 단계별로 구현하면 그렇게 복잡하지 않습니다. 어쨌든 처음부터 개발 프로세스에 보안 조치를 구축하는 비용은 결함이 있는 소프트웨어로 인해 발생할 수 있는 잠재적 손상 비용보다 훨씬 낮습니다. 또한 초기 단계에서 오류를 제거하는 비용은 이후 단계나 제품이 이미 서비스 중일 때보다 낮습니다.