SbD(Security by Design) 설명
Security by Design은 보안을 사후 고려 사항이 아닌 기둥으로 설정하는 것, 즉 설계 단계부터 보안 제어를 소프트웨어 제품에 통합하는 것을 목표로 하는 소프트웨어 개발 접근 방식입니다. SbD는 기업이 보안 기능에 대한 추가 비용 없이 즉시 배포할 수 있는 보안 소프트웨어를 만듭니다.
SbD를 더 잘 이해하려면 수백만 달러 상당의 상품을 보관할 수 있는 안전한 창고를 구축해야 하는 시나리오를 상상해 보십시오. 쉽게 뚫을 수 있는 목재로 건물을 짓고, 센서 및 CCTV와 같은 보안 기능으로 건물을 강화하고, 보안 회사를 고용할 수도 있습니다. 또는 벽돌로 창고를 짓고, 무거운 금속 문을 사용하고, 동일한 보안 기능을 설치할 수 있습니다.
물론 벽돌 창고는 보안 기능에 관계없이 뚫을 수 없는 시스템을 보유하는 것이 더 좋기 때문에 더 안전할 것이며, 이것이 SbD를 대표하는 접근 방식입니다.
The Secure Coding Best Practices [Cheat Sheet]
With curated insights and easy-to-follow code snippets, this 11-page cheat sheet simplifies complex security concepts, empowering every developer to build secure, reliable applications.
Download Cheat Sheet
보안을 고려한 설계가 필요한 이유
웹 기반 앱은 소프트웨어 공급업체가 보안을 강화하기 전에 소프트웨어를 제공했기 때문에 VbD(Designed by Design)에 취약했습니다. 즉, 기업은 보안 기능을 추가 기능으로 구매하고 주요 취약점이 발생할 때마다 패치해야 했으며, 더 많은 기능은 더 많은 비용을 의미하므로 공급업체에게 수익성 있는 접근 방식이었습니다.
그러나 공급망 공격의 주요 대상인 기업은 침해가 발생할 때 법적, 재무적, 평판에 대한 결과에 직면하는 기업입니다(종종 그렇습니다).
SbD는 사용자와 공급업체가 자신의 행동 또는 부작위에 대해 책임을 지는 소프트웨어 개발 문화를 촉진함으로써 이러한 "엔터프라이즈 사용자를 처벌하고 공급업체를 보호하는" 문제를 해결합니다. 이를 통해 공급업체와 사용자의 소프트웨어를 모두 개선할 수 있습니다 보안 태세 공격 표면을 줄이고 다른 주요 결과를 촉진합니다.
더 쉽고 저렴한 패치 적용
데이터 침해 및 관련 재정적 및 평판 손상을 방지하기 위해 소프트웨어를 사용하는 동안 서둘러 보안 수정 사항을 적용하는 것은 골칫거리이고 비용이 많이 들고 오류가 발생할 수 있습니다.
처음부터 보안을 유지하도록 설계된 제품은 점점 더 적은 수의 중요한 패치가 필요하므로 프로세스가 훨씬 저렴하고 쉬워집니다.
비용 효율적인 제품
설계상 취약한 시스템을 보호하는 유일한 방법은 여러 애드온을 추가하는 것입니다. 그러나 공격자는 여전히 백도어 시스템에 침투하기 위해 VbD 결함에 의해 생성되었습니다.
기본적으로 시스템을 보호하는 것이 데이터 침해 및 관련 비용, 소송 및 벌금의 높은 위험에 직면하는 것보다 비용 효율적입니다.
규정 준수
SbD 접근 방식을 사용하여 개발된 소프트웨어는 보안을 핵심으로 하기 때문에 기본적으로 규정을 준수할 가능성이 더 높습니다. 이렇게 하면 다양한 소프트웨어 구성 요소를 확인하는 프로세스가 쉬워집니다. 컴플라이언스 다양한 규정으로.
설계에 따른 보안은 어떻게 작동하나요?
SbD 접근 방식에는 아래에서 살펴보는 4가지 주요 단계가 있습니다.
1단계: 보안 요구 사항 정의
SbD는 개발할 소프트웨어, 잠재적 취약성 및 해당 보안 요구 사항에 대한 명확한 연구로 시작합니다. 데이터베이스 서비스의 경우 보안 요구 사항에는 암호화, RBAC(역할 기반 액세스 제어) 및 기타 권한 부여 기술이 포함됩니다.
2단계: 위험 평가 및 위협 모델링 수행
이 단계에서는 상황에 맞는 취약성 스캐너 소프트웨어의 잠재적 공격 경로를 매핑합니다.
예를 들어 데이터베이스 서비스 공급자는 데이터베이스에 저장된 민감한 개인 식별 정보(PII) 및 보호된 건강 정보(PHI)로 인해 공용 IP 또는 권한 있는 계정과 같은 가능한 공격 경로에 노출됩니다.
Free Cloud Risk Assessment
Connect with a Wiz expert for a personal walkthrough of the critical risks in each layer of your environment.
Request Assessment
3단계: 코드 작성과 보안 조치를 동시에 구축
이 단계에서 엔지니어링 팀은 기존의 코딩 절차를 버리고 네이티브로 소프트웨어를 개발합니다 보안 조치. 데이터베이스 공급자의 경우 다음과 같은 코드 작성이 포함될 수 있습니다.
기본적으로 데이터베이스가 일반에 공개되지 않도록 합니다.
엔터프라이즈 사용자가 추가 기능을 구매할 필요 없이 사용자 입력의 유효성을 자동으로 검사합니다.
모든 형태의 액세스 권한이 부여되기 전에 여러 인증 메커니즘이 필요합니다.
권한 있는 계정에 대한 액세스 지점을 제한합니다.
4단계: 지속적인 모니터링 및 패치 적용
마지막으로 소프트웨어를 테스트하고 설계상 안전한 것으로 확인되면 배송됩니다. 사용자가 소프트웨어를 배포하면 공급업체는 지속적으로 모니터링, 감사 및 SbD 업데이트를 새로운 위협으로 전송하고 취약점 등장.
설계에 따른 보안 원칙
CISA(Cybersecurity and Infrastructure Security Agency)는 소프트웨어 제조업체가 제품을 개발할 때 세 가지 핵심 원칙을 채택할 것을 권장합니다.
공동 책임
공급업체와 고객 모두 보안의 부담을 분담해야 합니다. 소프트웨어 제조업체는 보안 제품을 구축하고 위협 환경이 진화함에 따라 소프트웨어를 정기적으로 패치해야 합니다. 한편 고객은 이 소프트웨어를 사용하여 제품을 안전하게 구성하고 데이터를 안전하게 유지해야 합니다.
근본적인 투명성
소프트웨어 제조업체는 설계상 제품을 안전하게 만드는 요소에 대한 정보를 공유해야 합니다. 그들은 정확한 취약성 권고, 관련 CVE(Common Vulnerability and Exposure) 레코드 및 인증 메커니즘 등 SbD 제품에 기대되는 몇 가지 사항에 대해 고객에게 책임을 집니다.
조직 구조
SbD는 최고 경영진 수준의 헌신과 모든 이해 관계자 간의 커뮤니케이션이 필요하며, 협업은 공급업체와 고객, 개발자와 보안 팀 간의 핵심입니다. 이를 통해 거의 뚫을 수 없는 보안 제어를 쉽게 구현하고 통찰력 기반 예산 계획 및 리소스 할당을 가능하게 할 수 있습니다.
설계에 의한 보안 구현의 과제
SbD 채택의 세 가지 주요 과제에 대해 논의해 보겠습니다.
| Challenge | Description |
|---|---|
| Short-term costs vs. long-term profits | The cost of restructuring legacy software and switching programming languages to embed security—rather than bolt it on—is discouraging for most vendors. Even in modern systems, embedding security is a complex and costly process. Still, in the long run, fewer and less complicated patches, fewer attacks, etc. will mean the initial cost pays for itself. |
| Marketability | The motivation—for cloud vendors—to implement SbD is low, as there are no direct monetary returns for them. It is difficult to market restructured SbD products on the “now secure-by-design” premise, as this will leave enterprise users with the presupposition that the products weren’t properly built and secured earlier on. It is easier to sell legacy software as is, alongside aftersales/add-on security products like firewalls and antivirus. |
| Third-party vendor liability | An important implication of SbD is that software vendors are liable for supply chain vulnerabilities. For example, a single security flaw can affect several enterprise customers who would want the vendor to take the blame, i.e., face the financial and reputational consequences. Getting all parties onboard with the shared responsibility model is thus critical, as discussed above. This makes it clear that security is in fact a shared burden between the vendor and the customer. |
설계에 의한 보안 모범 사례
CISA는 다음에서 추려낸 몇 가지 SbD 전술을 제공합니다. 보안 소프트웨어 개발 프레임워크(SSDF) NIST(National Institute of Standards and Technology): NIST의 스태미너 800-218. 조직은 이러한 관행을 소프트웨어 개발 수명 주기(SDLC)의 모든 단계에 통합해야 합니다.
보안 소프트웨어 구성 요소 사용
라이브러리, 프레임워크 및 미들웨어를 포함한 보안이 잘 설정된 소프트웨어 구성 요소를 검증된 공급자에서만 배포합니다. 또한 암호화 및 인증 실패, 손상된 액세스 제어, 주입 취약성 및 로깅 문제를 포함하여 알려진 취약성이 있는 소프트웨어를 사용하지 마십시오.
클라우드 네이티브 애플리케이션 보호 플랫폼A cloud native application protection platform (씨엔앱) 보안되지 않은 구성 요소를 감지하는 데 유용합니다.
좋은 디자인 관행 채택
조직은 심층적인 방어를 구현하여 소프트웨어 시스템에 대한 위험을 줄일 수 있습니다. 둘 이상의 보안 조치 계층이 있습니다.. 한편, 샌드박싱은 소프트웨어와 보안 구성 요소를 격리하여 단일 구성 요소의 손상이 전체 시스템에 영향을 미치지 않도록 합니다.
또한 공급업체는 패치를 쉽게 적용할 수 있는 소프트웨어를 설계해야 합니다. 소프트웨어 업데이트로 인한 다운타임을 최소화하면 기업 사용자가 패치를 더 빨리 적용할 수 있습니다.
메모리 안전 프로그래밍 언어 활용
NIST는 다음을 권장합니다. 개발자 CFI(Control-Flow Integrity) 및 ASLR(Address Space Layout Randomization)과 같은 일반적인 메모리 대상 완화를 구현합니다. 그러나 이 외에도 NIST는 메모리가 안전하지 않은 언어인 C 및 C++는 피하면서 Rust, Go, Java, C#, Swift 및 Python과 같은 최신 메모리 안전 언어를 채택해야 한다고 지적합니다.
이는 SlammerWorm, Ghost Engine 및 Stagefright와 같은 메모리 안전 취약성을 완화하는 데 도움이 됩니다.
Adopt parameterized queries and web template frameworks
매개 변수가 있는 쿼리는 쿼리 자체에서 사용자 입력을 분리하는 매개 변수가 있는 SQL 쿼리입니다. 웹 템플릿 프레임워크에는 의심스러운 사용자 입력을 자동으로 방지하는 상황에 맞는 정보가 포함되어 있습니다. 이러한 메커니즘은 SQL 주입을 방지하는 데 도움이 됩니다. XSS(교차 사이트 스크립팅) 공격.
SBOM 제공
소프트웨어 공급업체는 소프트웨어를 개발하는 데 사용한 독점 및 타사 소프트웨어 구성 요소, 라이브러리 및 도구 목록을 사용자에게 제공해야 합니다. 이 목록은 다음을 통해 생성할 수 있습니다. 에이전트 없는 SBOM 스캐너- 취약성을 쉽게 해결할 수 있습니다.
기본 암호 제거
공급자는 기본 암호를 사용하여 제품을 출시하지 않아야 합니다. 대신 다단계 인증을 채택하고 사용자가 소프트웨어를 구성한 직후 강력한 암호를 설정하도록 요구해야 합니다.
소프트웨어 권한 부여 프로파일 제공
이러한 프로필은 사용자 역할 및 사용 사례를 지정하여 사용자 데이터 및 권한 있는 계정에 대한 불필요한 액세스를 제한합니다. 소프트웨어 제조업체는 자세한 소프트웨어 인증 프로필을 제공하고, 최소 권한 원칙을 구현하고, 지정된 제한에서 벗어나지 않도록 경고를 발행해야 합니다.
결론
Security by Design은 소프트웨어 설계 단계부터 보안 프로토콜을 사전 예방적으로 구현합니다. CISA 및 기타 주요 업계 관계자가 옹호하는 SbD는 취약성 평가, 공격 경로 분석 및 소프트웨어 구성 요소 분석을 수행하여 앱이 출시되기 전과 SDLC의 모든 단계에서 잠재적인 소프트웨어 취약성을 파악하고 해결하도록 권장합니다.
목표는 설계상 이미 취약하기 때문에 시스템을 공격으로부터 적절하게 보호하지 못하는 값비싼 볼트온 보안 도구와 복잡한 판매 후 코드 변경을 없애는 것입니다.
SbD는 앱을 빌드하고 보호하기 위한 더 저렴하고 빠르며 강력한 접근 방식입니다. 이것이 바로 Wiz가 다음을 옹호하는 주요 옹호자인 이유입니다. 배송 보안 코드. 해결책:
엔드-투-엔드(end-to-end) 소프트웨어 가시성 확보
최신 SBOM 제공
활성화 공격 경로 분석
에 가입하기 맞춤형 데모 Wiz가 설계에 의한 보안 제품을 향한 여정을 시작하는 데 어떻게 도움이 되는지 알아보십시오.
See for yourself...
Learn what makes Wiz the platform to enable your cloud security operation
