ni.com is currently undergoing scheduled maintenance.
Some services may be unavailable at this time. Please contact us for help or try again later.
소프트웨어 어플리케이션의 보안에는 개발 수명 주기 전반에 걸쳐 보안 사고방식을 적용하기 위한 공식적인 방법론이 필요합니다. 이 소프트웨어 개발 수명 주기 (SDLC)는 개발이 시작되기 전에 팀을 준비하고, 소프트웨어 개발을 위한 보호 조치를 마련하고, 소프트웨어 설계에 보안 모범 사례를 적용하며, 릴리스 후 소프트웨어를 지원하는 것으로 시작됩니다. 이 문서는 NI LabVIEW 팀이 프로젝트에 보안 소프트웨어 개발 프레임워크를 포함하는 공식 SDLC를 채택하도록 권장합니다.
소프트웨어 개발 수명 주기 (SDLC)는 하드웨어에 내장된 코드를 포함하여 소프트웨어를 설계, 생성 및 유지 관리하는 공식적 또는 비공식적 방법론입니다.
모든 소프트웨어 팀은 공식적으로 문서화되어 있든 그렇지 않든 이미 개발 프로세스를 갖추고 있습니다. 의도적인 보안 개발은 해당 프로세스 전반에 걸쳐 취약점을 줄이고, 유지보수성을 향상시키며, 보안 문제를 해결하는 비용을 절감하는 활동을 추가합니다. 취약점에는 코드 결함으로 인한 버그뿐만 아니라 보안 설정 셋팅, 잘못된 신뢰 가정 및 오래된 위험 분석으로 인한 약점도 포함됩니다.
SDLC에서 보안을 더 일찍 다룰수록 동일한 수준의 보안을 달성하는 데 궁극적으로 필요한 노력과 비용이 줄어듭니다. 시프트 레프트로 알려진 이 원리는 SDLC 모델에 관계없이 매우 중요합니다. 시프트 레프트 원리는 보안 어플리케이션 개발에 사용할 수 있는 보안 프로그래밍 환경인 LabVIEW를 비롯한 모든 프로그래밍 환경에 적용됩니다. 완성된 어플리케이션의 보안은 개발 팀이 채택한 SDLC에 크게 좌우됩니다.
SDLC 및 규정 준수에 관한 중요 참고 사항: 유럽 사이버복원력법 (CRA, Cyber Resilience Act), 미국 사이버보안 성숙도 모델 인증 (CMMC, Cybersecurity Maturity Model Certification), 영국 국방 사이버 인증 (DCC, Defence Cyber Certification) 등과 같은 대부분의 규제 프로그램은 시스템이 이 SDLC에 제시된 것과 같은 보안 관행을 따라 설계되었다는 증거를 요구하지만, 이러한 프로그램은 단순한 SDLC보다 훨씬 더 많은 것을 요구합니다. 더 자세한 정보는 해당 프로그램의 문서를 참조하십시오.
이 지침은 주로 NIST Special Publication 800-218, Secure Software Development Framework (SSDF)에 정의된 원리와 관행을 기반으로 하며, 이는 보안 소프트웨어 개발을 위한 기술 중립적인 프레임워크를 제공하며 미국 정부의 소프트웨어 보안 요구 사항을 지원하는 것으로 널리 인정됩니다. 각 SSDF 관행은 테스트, 측정, 자동화 및 엔지니어링 환경에서의 실질적인 구현에 중점을 두어 LabVIEW 개발 팀의 요구에 맞게 해석되고 적용되었습니다.
이 문서에 제시된 권장사항은 또한 JKI Security Suite 및 Microsoft Security Development Lifecycle (SDL)을 비롯한 다른 확립된 보안 개발 프레임워크 및 업계 모범 사례와 비교되었으며, 이는 소프트웨어 보안, 위험 관리 및 소프트웨어 공급망 보호에 대한 검증된 접근 방식과의 일관성을 보장하기 위한 것입니다. 목적은 LabVIEW를 사용하는 조직에 사이버 보안을 개발 프로세스에 통합하기 위한 실질적인 로드맵을 제공하는 것입니다. 이를 통해 고객, 규제 기관 및 정부 조달 프로그램에서 갈수록 요구하는 증거와 추적성도 함께 생성할 수 있습니다.
NIST 800-218에서 설명된 프로세스는 소프트웨어 개발의 네 가지 영역에 대해 다룹니다.
이 문서에서는 이러한 주제를 사용하여 LabVIEW SSDF의 개발을 안내합니다.
개발을 시작하기 전에, 팀이 보안 개발 원리를 채택하고, 필요한 교육 과정을 완료하고, 보안 개발을 지원하는 프로세스와 도구를 구축할 수 있도록 조치를 취하는 것이 중요합니다. 이 단계에서는 다음과 같은 목표를 달성하는 데 시간이 걸립니다:
이러한 요구 사항은 모든 소프트웨어 개발 팀에 일반적이지만, 테스트 팀 및 LabVIEW 팀에 맞추어야 할 몇 가지 조치를 취할 수 있습니다.
많은 테스트 팀은 회사의 보안 팀과 분리되어 있습니다. 보안을 중요하게 여긴다는 점을 알 수 있도록 보안 팀과 협력하여 신뢰 관계를 구축하십시오. 보안 팀과 만나 개발된 코드에 대한 요구사항을 이해하십시오. 프로젝트와 테스트 영역을 보여주고 프로세스를 안내하십시오. 보안 팀이 테스트 랩의 운영 방식과 여러분이 직면한 제약 사항을 이해하는 것이 도움이 됩니다. 여러분의 과제는 다른 IT 시스템의 과제와 다르므로, 보안 팀이 이러한 차이점을 이해하면 도움이 됩니다.
또한 보안 팀의 우려를 이해하는 것이 중요합니다. 보안 팀이 준수해야 하는 프로그램을 이해하면 보안 의무사항을 요구사항까지 추적할 수 있으며, 원래 프로그램의 의도를 더 잘 충족할 수 있습니다.
요구사항 추적은 팀이 보안 코드를 제공할 수 있도록 준비하는 중요한 부분입니다. 요구사항을 단순히 저장하는 것 이상으로, 우수한 추적 프로세스는 해당 요구사항의 추적성을 제공합니다. 팀은 수명 주기 전반에 걸쳐 요구사항을 추적할 수 있어야 합니다:
요구사항 정의 → 설계 → 구현 → 테스트 → 결함 수정 → 릴리스
이러한 추적성은 고객 감사, 보안 선언 (CRA 등), 평가 (CMMC 등) 또는 공급업체 보안 검토 시 증거가 됩니다.
GitHub 이슈 + 프로젝트 + 마일스톤은 대부분의 소규모 팀에서 가장 일반적인 요구사항 추적 방식입니다. 추적을 위한 다른 옵션으로는 GitLab (무료 및 유료 등급), Azure DevOps, JIRA 및 기타 전문 소프트웨어 개발 도구가 있습니다. 이러한 도구를 사용하면 이슈를 생성하고 해결될 때까지 추적할 수 있습니다.
선택한 도구 내에서 보안 요구사항을 체계적으로 추적합니다. 각 요구사항은 다음 조건을 충족해야 합니다:
요구사항 추적 도구를 선정한 후, 개발 과정에서 이러한 도구를 사용하는 절차를 문서화합니다. 시스템의 수명 주기 동안 요구사항 추적 및 이슈 추적에 이 프로세스를 사용합니다. 프로세스에는 다음과 같은 단계가 포함될 수 있습니다.
코드를 모듈화하도록 계획합니다. 개별 모듈을 테스트할 수 있으므로 이 단계는 특히 LabVIEW에서 유용합니다. 모듈형 아키텍처를 계획할 때 유닛 테스트도 함께 개발할 계획을 세우십시오. 이렇게 하면 코드 품질이 향상되고, 업데이트 후 코드를 더 빠르게 검증할 수 있으며, 이는 시스템이 배포된 후에도 마찬가지입니다.
NI 유닛 테스트 프레임워크 사용에 대해 자세히 알아보기
타사 테스트 도구는 추가적인 가치를 제공합니다. 예를 들어 JKI의 Caraya 및 LUnit 제품은 LabVIEW 팀을 위한 소프트웨어 테스트를 확장합니다.
하도급 작업, 타사 소프트웨어 및 오픈 소스 컴포넌트를 확인하고 승인하는 프로세스를 정의합니다. 프로세스에는 사용하는 컴포넌트의 알려진 취약점을 식별하기 위해 Common Vulnerabilities and Exposures (CVE)와 같은 공개 데이터베이스를 확인하는 작업이 포함되어야 합니다.
오픈 소스 컴포넌트를 사용하는 경우, 어플리케이션에서 해당 코드를 사용하기 전에 취약점을 스캔할 책임이 있습니다.
보안 관련 역할을 포함하여 팀 내에서 특정 역할을 정의합니다. 각 역할의 책임과 접근 권한을 확인합니다. 최소한 특권 접근 권한을 가진 역할 (관리자)을 사용자 역할 (개발자 및 운영자)과 분리하여 정의해야 합니다.
이러한 역할에 적용할 수 있는 보안 교육을 작성합니다. 팀원에게 교육을 할당하고 이수 여부를 추적합니다. 이러한 기록은 인증 검토에서 증거로 사용될 것입니다.
온라인에서 제공되는 NI 보안 교육 과정 사용을 고려하십시오: 테스트 시스템 통합을 위한 보안 고려사항 과정.
ISC2와 같은 업계 자격증 프로그램은 저렴한 입문 수준의 인증을 제공합니다. 테스트 팀에게 이러한 프로그램의 가치는 보안 팀과 소통하기 위한 공통 언어를 제공하는 것입니다.
SDLC를 정의한 후 회사 경영진에게 이를 제시하고 공식적인 지원을 받으십시오. 최소한 보안 예산을 승인하는 직급의 승인을 받아야 하며, 이는 프로그램에 대한 의지를 보여줍니다.
조직으로서 발생할 수 있는 데이터 타입을 확인하고 라벨 시스템을 생성합니다. 다음 데이터 타입을 고려해야 합니다:
명확한 데이터 관리 및 라벨링 시스템을 갖추면 각 데이터 분류에 알맞은 제한을 적용하여 데이터를 적절히 보호할 수 있습니다. 시스템 개발을 시작하기 전에 조직 차원에서 이를 정의하면 적절한 위험 영역에 적절한 컨트롤을 적용하여 시간을 절약할 수 있습니다. 기존 기업 및 IT 라벨링 시스템에 매핑하면 시스템 간 데이터 공유 방식이 간단해집니다.
보안을 위해 표준화할 소프트웨어와 드라이버 버전 및 설정을 확인합니다. LabVIEW의 경우 개발에 사용할 버전을 식별합니다. 설치에 대한 안전한 설정을 마련합니다. LabVIEW 보안 설정 가이드를 참조하십시오. 다른 보안 설정 가이드는 ni.com/security에서 찾을 수 있습니다.
감사 가능성을 확보하고 새 시스템을 신속하게 설정하기 위해 개발 및 빌드 머신의 설정을 자동화합니다. 베이스라인 설치를 구축하고 해당 설치에서 이미지를 생성합니다.
개발 과정에서 보안 검사에 사용할 도구를 구축합니다. 잠재적 보안 취약점을 찾기 위해 프로그램을 실행하지 않고 소스 코드를 분석하는 정적 어플리케이션 보안 테스트 (SAST) 도구가 필요합니다. LabVIEW 그래픽 코드의 경우, LabVIEW 코드의 정적 분석을 제공하도록 특별히 설계된 JKI Security Suite를 권장합니다. 또는 보안 문제를 찾는 수동 정적 코드 분석을 수행할 수 있습니다.
SAST 도구는 코드의 취약점을 분석하는 중요한 보안 도구 중 하나입니다. 동적 어플리케이션 보안 테스트 (DAST) 도구도 중요하며, 테스트 중 실행 중인 코드를 스캔하는 데 사용됩니다. 소프트웨어 구성 분석 (SCA, Software Composition Analysis)은 오픈 소스 라이브러리, 타사 패키지, 소프트웨어 구성요소의 사용을 확인하고 해당 구성요소에 대한 알려진 취약점 및 라이센스 문제를 스캔합니다.
보안 문제를 찾기 위해 코드를 스캔하는 데 사용되는 다른 유형의 도구도 많이 있습니다. 프로젝트에 적합한 도구는 사용하는 도구 세트, 프로젝트의 특성, 사용하는 코드 종류에 따라 다릅니다. 보안 개발 수명 주기의 이 단계에서는 팀이 사용할 도구를 조사하고 식별하는 것이 중요합니다.
보안 개발에서는 소스 코드가 저장되어 있어야 하며, 여러 버전으로 저장되어 있어 코드에 문제가 발생할 경우 팀이 이전 버전으로 되돌릴 수 있습니다. 보안 개발을 수행할 조직을 준비하는 과정의 일환으로, 코드를 저장하고 개발을 위해 코드를 체크아웃하며 소스 코드의 버전 관리를 유지하는 코드 저장소를 구축합니다.
코드 저장소에서 브랜치를 사용하면 병렬 개발과 안정적인 릴리스가 용이해집니다. 조직에서 사용할 브랜치 유형을 정의합니다. 이러한 브랜치 유형은 표준이지만 필요에 맞게 조정할 수 있습니다:
적절한 보안 컨트롤을 제공하는 저장소를 사용하십시오. 추적성을 위해 저장소가 커밋 파일 및 변경 사항의 전체 이력을 유지하는지 확인합니다.
코드 개발에 사용되는 컴퓨터가 기본적인 사이버 보안 정책을 따르도록 합니다. 이러한 기본적인 컨트롤에는 암호 보호, 악성 코드 보호, 기타 기본적인 사이버 위생이 포함됩니다. 이러한 기본 컨트롤의 예는 https://www.acquisition.gov/far/52.204-21을 참조하십시오.
추적성을 위해 시스템 개발에 사용되는 컴퓨터의 설정 셋팅을 기록합니다. 기록할 설정 셋팅의 예는 다음과 같습니다.
대부분의 보안 프로그램은 팀이 SSDF의 일부로 수립된 관행을 따랐다는 증거를 요구합니다. 시스템 개발 및 배포 과정에서 증거를 추적하고 업데이트하는 저장소를 설정합니다. 시스템은 다음 아이템을 추적해야 합니다:
많은 팀이 이러한 보안 작업을 수행하지만, 실행한 것을 증명할 수 없습니다. 규정 준수 팀은 팀이 프로세스를 갖추고 있는지와 해당 프로세스를 준수하는지를 모두 확인하고자 할 것입니다. 이러한 문서를 한 곳에 모아두면 감사 및 규정 준수 검토가 크게 간소화됩니다.
조직이 코드를 안전하게 개발할 준비가 되면, 다음 작업은 소프트웨어를 보호하는 것입니다. 이 단계는 팀이 개발 및 릴리스 중에 코드를 안전하게 유지하도록 합니다.
개발 과정 중 소프트웨어를 보호하는 것은 사용되는 프로그래밍 언어에 관계없이 모든 소프트웨어에서 매우 중요합니다. LabVIEW 팀이 소프트웨어 개발을 위한 전문 워크플로 도구를 채택함에 따라, 해당 팀은 보안 개발 프로세스와 도구도 채택해야 합니다.
이전 단계에서 확인한 보안 코드 저장소를 사용하여 코드를 저장하고 관리합니다. 좋은 저장소는 소스 코드 관리 이상을 수행합니다. 또한 요구사항, 문서, 빌드 스크립트, 테스트 아티팩트 및 릴리스 이력도 포함합니다. 저장소에는 코드와 지원 자료가 많이 포함되어 있으므로 보안 저장소를 사용하는 것이 중요합니다. 저장소가 손상되면 소프트웨어도 손상됩니다.
저장소 내에서 메인 브랜치는 반드시 보호해야 하는 핵심 자산입니다. 팀은 코드를 보호하기 위해 정책을 정의하고 준수해야 합니다. 이러한 정책에는 다음과 같은 예가 포함될 수 있습니다:
또한 저장소는 요구사항 생성부터 개발, 제품 릴리스까지의 추적성을 제공해야 합니다. 일부 저장소에서는 커밋 서명을 허용합니다 (예: Git).
저장소는 소프트웨어 변경사항을 기록하여 감사 추적을 제공해야 합니다. 무엇이 변경되었는지, 누가 변경했는지, 왜 변경되었는지, 누가 승인했는지, 언제 릴리스되었는지? 또한 릴리스 이미지를 보안 아카이브에 백업해 두면 저장소가 손상되더라도 코드를 복구할 수 있습니다.
SBOM은 코드 개발에 사용되는 소프트웨어와 컴포넌트의 목록을 제공합니다. 빌드 과정의 일부로 SBOM을 생성하면 코드에서 어떤 컴포넌트가 사용되는지 기록되므로, 취약점을 식별하고 수정하는 프로세스가 간소화됩니다.
LabVIEW 2026 Q3부터 어플리케이션 빌드 프로세스의 일부로 SBOM을 생성할 수 있습니다. 자세한 내용은 독립 어플리케이션용 SBOM 생성을 참조하십시오.
코드 서명은 소프트웨어가 알려진 조직에 의해 생성되었는지, 릴리스 이후 수정되지 않았는지, 배포가 승인되었는지 사용자가 확인할 수 있는 메커니즘을 제공합니다. LabVIEW 어플리케이션에서는 실행 파일, 설치 프로그램, 배포 패키지, DLL, 드라이버, 업데이트 패키지에 코드 서명을 적용해야 합니다.
이 설명에 따라 빌드 과정 중에 어플리케이션에 서명할 수 있습니다. 또한 Microsoft의 SignTool.exe를 사용하여 소프트웨어에 서명할 수 있으며, 이는 어플리케이션이나 파일에 서명하는 것과 같습니다.
어플리케이션에는 암호, API 키, 인증서, 토큰, 암호화 키, 데이터베이스 자격 증명, 서비스 계정 자격 증명과 같은 비밀 정보가 필요한 경우가 많습니다. 이러한 비밀 정보는 시스템 및 데이터에 대한 접근을 제공하므로 소프트웨어 수명 주기 전반에 걸쳐 보호해야 합니다.
암호, API 키, 인증서, 암호화 키를 소스 코드, 설정 파일, 빌드 스크립트, 테스트 유틸리티에 직접 하드코딩하지 마십시오. 하드코딩된 비밀 정보는 교체하기 어렵고 저장소에 복사될 수 있으며, 소스 코드 검토, 백업, 배포된 어플리케이션의 리버스 엔지니어링을 통해 노출될 수 있습니다.
가능한 경우 보안 OS 또는 하드웨어로 보호되는 스토리지를 사용하여 비밀 정보를 저장합니다. 보안 또는 보호된 스토리지의 예로는 다음과 같은 옵션이 있습니다:
비밀 정보에 대한 접근 권한을 부여할 때 최소 권한 원칙을 적용합니다. 비밀 정보에 접근해야 하는 사용자, 시스템 및 서비스만 이를 검색할 수 있어야 합니다. 관리자 자격 증명은 사용자 자격 증명과 분리되어야 하며, 가능한 한 공유 계정을 피해야 합니다.
암호, 인증서, API 키 및 암호화 키는 조직 정책에 따라 주기적으로 교체되어야 합니다. 비밀 정보를 생성하는 방법, 저장 위치, 접근 가능한 사용자 및 손상된 비밀 정보를 해지하는 방법을 정의하는 프로세스를 수립합니다.
테스트 시스템은 실제 네트워크 연결, 데이터베이스, 클라우드 서비스, 인스트루먼트를 자주 사용합니다. 테스트 팀은 테스트 중에 이러한 시스템에 접근해야 합니다. 가능한 경우 프로덕션 자격 증명 대신 전용 테스트 자격 증명을 사용하십시오. 테스트 환경을 분리하면 개발 및 검증 활동 중 운영 시스템이 노출될 위험을 줄일 수 있습니다.
이 단계에서는 소프트웨어의 안전한 설계, 구현, 테스트 및 검증에 중점을 둡니다. 이 작업을 효과적으로 수행하려면, 팀이 의도한 소프트웨어 사용의 위험과 요구사항을 평가하고 이러한 위험에 맞게 설계해야 합니다. 모범 사례에는 가능한 경우 검증된 보안 컴포넌트의 재사용, 개발 중 테스트, 개발 코드의 취약점 스캔이 포함됩니다. 팀은 기본 보안 설정 사용을 포함하여 안전한 사용을 계획합니다.
테스트 및 측정 어플리케이션은 일반 소프트웨어 어플리케이션과는 다른 보안 과제에 직면합니다. LabVIEW 팀은 이러한 과제를 이해하고, 어플리케이션에 초점을 맞춘 공격으로부터 보호할 소프트웨어를 개발할 수 있는 위치에 있습니다. LabVIEW는 여러 내장 안전 보호 기능을 제공하지만, 팀은 가능한 공격을 고려하고 이에 대한 방어를 준비해야 합니다.
Open Worldwide Application Security Project (OWASP)는 사람들이 보안 소프트웨어를 구축할 수 있도록 무료 도구, 가이드 및 표준을 제공하는 비영리 기관입니다. OWASP는 커뮤니티 기반 위협 모델링 가이드를 제공합니다. OWASP의 모델은 작업 범위 설정, 위협 식별, 대책 및 완화 방법 결정, 작업 평가를 위한 구조화된 일련의 단계를 제공합니다.
테스트 팀의 경우, 개발 중인 시스템에 대한 의도된 용도와 위협을 이해하는 대화로 시작합니다. 대화에는 주요 개발자, 테스트 아키텍트, 시스템 엔지니어, 제품 책임자, 사이버 보안 담당자, 운영 담당자가 포함되어야 합니다.
OWASP 접근 방식에는 스푸핑, 변조, 부인, 정보 공개, 서비스 거부, 권한 상승 (STRIDE) 등의 위협 목록이 포함되어 있습니다. STRIDE 위협 범주는 팀이 모든 유형의 위협을 고려하도록 안내하는 데 도움이 됩니다.
테스트 팀은 브레인스토밍 세션에서의 경험을 바탕으로 테스트 환경에서 위협이 시스템에 미치는 영향을 구체적으로 살펴야 합니다.
이러한 테스트 특정 위험을 보다 전통적인 사이버 위협에 추가하면 테스트 시스템에 적합한 방어 전략을 파악할 수 있습니다. 위협 모델링의 결과물은 우선순위가 지정된 위험과 이를 완화하는 데 필요한 보안 요구사항의 집합이어야 합니다. 이러한 요구사항은 다음 섹션에서 설명된 시스템 설계 및 개발 작업에 대한 입력입니다. 정기적인 위협 검토는 팀이 시간 경과에 따라 새롭게 등장하는 위협을 식별하고 이전 위협 모델에서 포착하지 못한 문제를 검토하는 데 도움이 될 수 있습니다.
위협 모델링은 시스템의 위험을 식별합니다. 다음 단계는 이러한 위험을 수명 주기 내내 구현, 테스트 및 추적할 수 있는 측정 가능한 보안 요구사항으로 변환하는 것입니다. 보안 요구사항은 기능 요구사항과 동일한 수준의 엄격함으로 취급되어야 합니다.
보안 요구사항은 시스템이 제공해야 하는 보안 컨트롤 또는 동작을 정의합니다. 우수한 보안 요구사항은 구체적이고, 측정 가능하며, 테스트 가능하고, 추적 가능해야 합니다. 다음 테이블은 몇 가지 예제를 보여줍니다.
보안 요구사항은 고유한 식별자를 할당하고 기능 요구사항에 사용되는 동일한 요구사항 관리 도구를 통해 추적되어야 합니다.
잘 정의된 보안 요구사항은 개발 주기 전체를 통해 추적할 수 있어야 합니다. 추적 가능성은 식별된 위험이 해결되었음을 보여주며, 고객 감사, 공급업체 보안 평가, 규제 검토 중에 유용한 증거를 제공합니다.
테스트 및 측정 시스템의 보안 요구사항은 기업용 소프트웨어 프로젝트에서 자주 무시됩니다. 보안 요구사항을 개발할 때 표준 보안 범주를 사용하되, 다음 사항도 고려하십시오.
측정치가 부정확하고 테스트 결과가 손상되면 상당한 비즈니스 영향이 발생할 수 있기 때문에, 무결성에 대한 보안 요구사항은 기밀성 요구사항만큼 중요합니다.
모듈형 코드는 기능을 통제된 인터페이스를 갖춘 명확히 정의된 컴포넌트로 분리하여 결함과 취약점의 영향을 제한합니다. 우수한 모듈형 설계에서 각 모듈은 다른 모듈에 필요한 기능만 노출합니다. 이렇게 하면 진입점이 줄어들고 오용 기회가 감소합니다. 또한 모듈형 코드는 테스트가 용이하므로 코드에 업데이트를 적용하고 검증하는 것이 더 쉽다는 장점이 있습니다.
모듈형 코드를 만들 때에는 최소 권한의 원리를 고려하십시오. 모듈은 기능을 수행하는 데 필요한 권한만 가져야 합니다. 예를 들어 인스트루먼트 통신 기능은 데이터베이스에 접근할 필요가 없습니다. 이는 다른 모듈에서 처리하기 때문입니다. 데이터베이스 핸들을 인스트루먼트 통신 모듈에 전달하지 마십시오.
데이터가 모듈 사이에서 전달되면, 통신의 신뢰도를 평가합니다. 필요한 경우, 다른 컴포넌트로부터 데이터를 받기 전에 소스를 검증하십시오.
모듈형 코드를 사용하면 보안 검토가 용이합니다. 코드 세트 전체를 검토하는 대신 각 모듈을 검토할 수 있습니다. 코드 검토자는 단일 컴포넌트의 보안에 기여하기 위해 전체 코드 세트를 이해할 필요가 없습니다.
또한 코드 모듈은 코드 재사용을 단순화합니다. 안전하게 개발되고 테스트된 모듈은 의도한 대로 작동한다는 확신을 가지고 다른 어플리케이션에 재사용할 수 있습니다.
모범 사례 세트를 정하고 이를 따르십시오. 코드 검토를 통해 이러한 관행을 준수하는지 확인해야 합니다. 모범 사례의 전체 검토는 이 문서의 범위를 벗어나지만, 최소한 다음 영역을 포함해야 합니다:
공인된 LabVIEW 유닛 테스트 프레임워크 (NI 유닛 테스트 프레임워크, JKI Caraya 또는 LUnit)를 사용합니다. 이러한 도구를 사용하면 개발자가 입력과 출력을 정의하고 코드가 올바르게 작동하는지 검증할 수 있습니다. 이는 전체 어플리케이션을 실행하지 않고도 가능합니다. 따라서 코드 검증이 단순해집니다.
모듈을 격리하여 테스트할 수 있기 때문에 유닛 테스트는 비싼 장비 제어와 같은 중요한 기능을 보호합니다. 유닛 테스트는 반복 가능한 실행을 위해 설계되어 있어야 하며, 코드 변경 시 자동으로 실행되도록 연속 통합 (CI) 시스템에 통합되어야 합니다.
보안 검토가 자주 수행되는 것은 보안 중심의 개발 문화를 구축하는 데 중요한 부분입니다. 검토는 팀이 보안 관행을 설정하고, 서로 배우고, 보안 프로세스를 강화하는 방법을 제공합니다. 보안 검토는 개발 전에 시작하며, 계획된 아키텍처와 메소드를 검토합니다. 그런 다음 코드가 안전하게 개발되도록 개발 과정 전체를 계속해서 검토해야 합니다. 검토 빈도는 개발 규모를 기준으로 정해야 하며, 상당한 후속 개발이 진행되기 전에 문제를 수정할 수 있을 만큼 충분히 자주 검토해야 합니다. 모든 병합 요청, 풀 요청 또는 기타 중요한 코드 통합 이벤트에서 검토가 수행되어야 합니다. 예약된 추가 검토는 큰 프로젝트에 적합할 수 있습니다.
팀이 체크리스트에 따라 검토를 수행하면 보안 검토가 크게 향상됩니다. 이러한 체크리스트는 조직에 의해 설정되고 위협 및 위험 분석을 기반으로 각 프로젝트의 시작 부분에서 사용자 정의되어야 합니다.
수동 코드 검토뿐만 아니라 자동 코드 검토를 수행합니다. 연속 통합 및 연속 전달/배포 (CI/CD) 프로세스를 사용하는 경우, 각 코드 체크인 시 코드가 스캔되도록 보안 스캔을 입력 프로세스에 추가합니다. 매일 또는 매주 실행되도록 추가적인 스캔 도구를 설정하여 코드의 영구적인 부분이 되기 전에 새로운 보안 결함을 감지합니다. 정적 분석, 유닛 테스트, 기타 보안 스캔 도구를 사용하여 다양한 검토 유형을 포함시킵니다.
가능하면 개발 소프트웨어 드라이버의 최신 버전을 사용하십시오. 거의 매일 새로운 보안 위협이 발견되고 개발자는 보안 문제를 패치와 새로운 소프트웨어 버전으로 수정합니다. 최신 버전을 사용할 수 없는 경우, 제조업체에서 보안 업데이트를 계속 제공하는 소프트웨어를 사용하여 시스템의 수명 동안 이를 수신합니다.
제조업체가 제공하는 설정 가이드를 사용하여 보안을 위해 도구를 설정합니다.
NI 제품에 대해 지원되는 소프트웨어 버전 목록을 참조하십시오.
제품을 릴리스하기 전에 프로젝트 시작 시 식별된 위협 및 위험을 기반으로 테스트를 실시하십시오. 이 목록에는 다음 테스트가 포함될 수 있습니다:
LabVIEW는 그래픽 프로그래밍 언어이므로 일부 기존 보안 도구로는 LabVIEW 코드를 테스트할 수 없습니다. JKI Security Suite 같은 도구는 LabVIEW 개발자를 위해 설계된 보안 중심의 정적 분석 기능을 제공하며, 이를 통해 LabVIEW 코드를 스캔하고 그래픽 프로그래밍 언어의 특정 보안 문제를 해결할 수 있습니다.
JKI Security Suite에 대해 자세히 알아보기
개발 팀이 위협 모델을 검토하고, 중요한 취약점을 해결하고, 유닛 테스트를 적용하여 통과하고, 정적 분석을 수행하고, SBOM을 생성하고, 코드 검토를 수행하고, 릴리스 패키지에 서명했다는 것을 입증할 수 없으면 릴리스를 승인해서는 안 됩니다. 공식 릴리스 게이트 프로세스를 시행하면 경영진이 프로세스 준수 여부와 소프트웨어의 보안을 검토하여 의사 결정을 내릴 수 있습니다.
보안 소프트웨어 개발은 프로세스의 일부에 불과합니다. 보안 어플리케이션도 잘못 배포되거나 설치 및 설정 중 보안 컨트롤이 제거되면 취약해질 수 있습니다. 그러므로 배포 프로세스는 사용자에게 소프트웨어를 배포하기 전에 정의된 절차, 검토 및 검증 작업이 포함된 보안 소프트웨어 개발 수명 주기의 일부로 처리되어야 합니다.
보안 기본 설정
어플리케이션은 기본 보안 설정을 사용하여 배포해야 합니다. 사용자는 일반적으로 기본 설정이 권장 설정을 나타낸다고 가정합니다. 기본적으로 비활성화된 보안에 민감한 옵션은 시스템의 수명 동안 비활성화 상태를 유지할 수 있습니다.
보안 기본값에는 다음과 같은 예가 포함될 수 있습니다.
사용자는 보안 보호 기능을 수동으로 활성화하기보다는 보안 설정을 의식적으로 약화시켜야 합니다.
프로덕션 강화
릴리스 전에 개발 중에는 유용하지만 프로덕션 환경에서는 불필요한 위험을 초래하는 개발 아티팩트와 기능을 제거하십시오. 다음 기준에 따라 어플리케이션을 검토합니다.
프로덕션 시스템은 시스템 운영에 필요한 기능만 노출해야 합니다.
계정 및 권한 관리
시스템에 필요한 권한을 검토하고 적절한 역할에 할당합니다. 시스템은 문서화된 운영상 필요가 없는 한 관리자 권한을 부여해서는 안 됩니다. 서비스 계정은 의도한 기능을 수행하는 데 필요한 권한만 갖추도록 설정되어야 합니다. 역할 기반 권한을 고려할 때는 다음을 고려하십시오:
시스템에 민감한 정보가 저장되어 있는 경우, 접근 통제가 해당 정보를 적절히 보호하는지 확인하십시오.
네트워크 보안 설정
배포 전에 필요한 모든 네트워크 통신을 문서화합니다. 시스템이 연결할 때마다 다음을 고려하십시오:
데이터가 네트워크 경계를 넘으면 데이터를 보호해야 합니다. 각 데이터 전송 시 다음 예방 조치를 따르십시오.
테스트 시스템은 기업 네트워크, 제조 네트워크, 클라우드 서비스, 인스트루먼트에 동시에 연결되는 경우가 많습니다. 이러한 신뢰 경계를 이해하고 문서화하는 것은 중요한 배포 작업입니다.
비밀 정보 및 자격 증명 관리
어플리케이션은 종종 암호, API 키, 인증서, 토큰 또는 암호화 키가 필요합니다. 이러한 비밀 토큰을 처리할 때는 다음을 피하십시오:
대신 다음 도구 또는 기술 중 하나를 사용하십시오:
비밀 정보를 생성, 저장, 교체, 백업 및 해지하는 방법을 문서화합니다. 이 과정을 따릅니다.
로깅 및 감사
어플리케이션은 중요한 운영 및 보안 관련 이벤트를 기록해야 합니다. 기록할 이벤트의 예는 다음과 같습니다:
로그는 해당 정보를 볼 권한이 없는 사용자에게 노출될 수 있으므로, 암호 및 개인 정보나 기밀 정보와 같은 시크릿이 로그에 기록되지 않도록 확인하십시오.
로그를 사용하면 장애를 해결하고, 사고를 조사하고, 고객 및 규제 요구사항 준수를 입증할 수 있습니다.
가능한 경우, 어플리케이션 로그를 Windows 이벤트 뷰어 또는 Linux Syslog와 같은 플랫폼 로깅 메커니즘과 통합하여 모니터링, 사고 조사, 규정 준수 보고를 단순화합니다. 보안 서버로 로그를 보내면 보호 및 접근성에 도움이 되는지 평가합니다.
감사 로그를 무단 접근 및 수정으로부터 보호하고 로그 보존 기간을 정의합니다.
릴리스 승인
소프트웨어를 릴리스하기 전에, 최종 보안 검토를 수행하여 어플리케이션이 팀의 릴리스 요구사항을 충족하는지 확인합니다. 이 최종 검토에는 다음이 포함됩니다.
릴리스 과정에서는 이러한 작업이 완료되었음을 보여주는 증거가 생성되어야 합니다. 이러한 증거 기록은 무결성을 유지하기 위해 릴리스 후 변조로부터 보호되어야 합니다.
코드 서명 및 패키지 무결성
사용자는 릴리스된 소프트웨어가 예상된 조직에서 비롯되었으며 릴리스 이후 수정되지 않았는지 확인할 수 있어야 합니다.
코드 서명은 다음 소프트웨어 유형에 적용되어야 합니다.
코드 서명은 소프트웨어 수정을 방지하지 않지만, 허가되지 않은 수정 사항을 강력하게 감지하고 소프트웨어가 예상되는 발행자로부터 오는지 확인합니다.
배포 검증
설치 후, 배포된 시스템이 원하는 환경에서 안전하게 작동하는지 확인합니다. 검증 작업은 다음 기능을 확인해야 합니다:
중대한 설정 변경이 있을 때마다 보안 검증을 수행해야 합니다.
배포 증거
정의된 프로세스에 따라 배포가 수행되었음을 보여주는 기록을 유지합니다. 이러한 레코드에는 다음과 같은 예가 포함됩니다.
이러한 레코드는 고객 감사, 공급업체 평가, 규제 검토, 내부 보안 조사 중에 유용한 추적성을 제공합니다.
소프트웨어 취약점은 시스템 또는 해당 데이터의 기밀성, 무결성, 가용성을 훼손하도록 악용될 수 있는 소프트웨어 설계, 구현, 설정 또는 운영 프로세스의 약점, 결함, 오류입니다. 팀이 개발한 코드 또는 소프트웨어에서 사용되는 컴포넌트 중 하나에서 취약점을 식별할 수 있습니다. 취약점은 악의적 행위자가 시스템을 손상시킬 수 있는 수단을 제공하므로, 이러한 취약점을 수정하고 영향을 받는 시스템에 수정 사항을 배포하는 것이 중요합니다.
테스트 업계는 취약점에 대처하기 위해 역사적으로 어려움을 겪고 있습니다. 많은 테스트 프로젝트는 시스템의 지속적인 유지 관리에 대한 자금 없이 단일 초기 자금 지원 모델로 지원됩니다. 이는 테스트 팀이 보안 업데이트를 제공하는 경우에도 시스템을 업데이트할 리소스가 없다는 의미입니다. 이는 시스템을 최신 상태로 유지해야 하는 보안 요구사항과 직접 충돌합니다.
상당한 과제는 업데이트에 필요한 검증의 양입니다. 소프트웨어와 하드웨어 도구가 비용이 들지 않더라도, 업데이트 후 시스템이 의도한 대로 작동하는지 검증하기 위해 업데이트는 매우 비용이 들 수 있습니다.
보안 업계가 변화함에 따라 테스트 업계도 테스트 시스템의 수명 주기 전반에 걸쳐 더 효과적으로 계획하고 자금을 지원하도록 변화해야 합니다. 테스트 팀은 다음 단계를 통해 전체 수명 주기 관리 방식으로 전환할 수 있습니다:
ni.com/security에서 LabVIEW, 드라이버 및 기타 소프트웨어를 포함한 NI 제품의 취약점을 알립니다. 패치는 Common Vulnerabilities and Exposures (CVE) 시스템을 통해서도 보고됩니다. 이 패치는 NI 엔지니어가 개발한 소프트웨어 코드 또는 사용하는 컴포넌트의 취약점을 수정할 수 있습니다. ni.com/security에서 새 패치 알림을 받을 수 있습니다.
또한 SBOM을 사용하여 소프트웨어의 스캔을 자동화할 수 있습니다. LabVIEW 어플리케이션에서 SBOM을 생성하는 경우, 스캔 소프트웨어를 설정하여 CVE 데이터베이스에 보고된 문제를 확인하고 알릴 수 있습니다. SBOM을 스캔하고 이를 CVE 데이터베이스와 대조하는 다양한 소프트웨어 구성 분석 (SCA) 도구가 있습니다.
최종 사용자가 취약점을 식별하면 이를 여러분에게 직접 보고할 수 있습니다. NI 소프트웨어 내에 문제가 있는 경우, ni.com/security에서 이를 보고할 수 있습니다.
취약점 보고서를 심각하게 취급하는 것이 중요합니다. 사용자가 문제를 보고하거나 소프트웨어 스택에서 취약점이 보고되는 경우, 취약점을 분석하여 영향과 악용될 가능성을 판단하십시오. 이러한 문제는 취약점의 특성과 해당 소프트웨어 컴포넌트를 사용한 방식에 따라 영향을 받습니다. 악용 위험이 상당하다고 판단되면 소프트웨어를 업데이트하고 최종 사용자에게 패치를 제공해야 합니다.
유럽 사이버 복원력 법안 (CRA)과 같은 일부 규정에서는 보안 패치를 5년 이상 제공해야 합니다. 일부 계약에서는 더 긴 기간 또는 더 짧은 기간의 지원 약속을 지정할 수 있습니다. 프로젝트를 완료한 후 예상치 못한 상황을 피하려면 초기 프로젝트 제안에서 이 수준의 지원을 계획하십시오.
취약점 수정 프로세스의 일부로 취약점의 근본 원인 분석을 수행하여 개발 프로세스를 개선하고 향후 프로젝트에서 유사한 문제가 발생하지 않도록 하십시오.
보안 소프트웨어 개발은 프로젝트가 끝날 때 수행되는 별도의 작업이 아닙니다. 이는 시스템의 수명 주기 전반에 걸쳐 통합되는 일련의 관행입니다. 이 가이드에 설명된 원칙을 채택함으로써 LabVIEW 팀은 취약점을 줄이고, 유지보수성을 향상시키며, 규정 준수 노력을 간소화하고, 맡겨진 시스템과 데이터를 더욱 효과적으로 보호할 수 있습니다. 보안은 프로세스이며 팀은 시간이 지남에 따라 성숙해집니다. 지금 바로 제품 수명 전반에 걸쳐 보안을 지속적으로 향상시키는 반복 가능하고 지속 가능한 프로세스를 수립하십시오.
| 위협 | 보안 요구사항 |
|---|---|
| 테스트 결과의 허가되지 않은 수정 | 적절한 역할을 가진 인증된 사용자만 저장된 테스트 결과를 수정할 수 있습니다. |
| 네트워크 트래픽 가로채기 | 어플리케이션과 외부 시스템 간의 모든 통신은 암호화된 프로토콜을 사용해야 합니다. |
| 교정 데이터 손상 | 교정 데이터는 허가되지 않은 수정으로부터 보호되어야 하며, 모든 변경 사항은 기록되어야 합니다. |
| 허가되지 않은 장비 컨트롤 | 관리 또는 위험 장비 작업에는 인증되고 권한이 부여된 사용자가 필요합니다. |