선언되지 않은 기능 제어

맥심 레핀
JSC "우려사항 "BEGA" 전문가

아나스타샤 사쿨리나
JSC "우려사항 "BEGA" 전문가

요즘 누수사고가 늘어나면서 기밀 정보(CI) 주요 질문은 안정적인 보호에 관한 것입니다.

국가 기밀 및 개인 데이터와 달리 CI 보호 분야의 규제 문서는 본질적으로 권고 사항이므로 따라야 할까요, 말아야 할까요?라는 자연스러운 질문이 생깁니다.

미선언능력부재(NDC) 통제수준에 따른 CI 보호장비 인증의 필요성과 타당성을 고려해 보자.

부적합 물질의 부재에 대한 통제 수준

4가지 수준의 제어가 있습니다. NDV 부재. CI를 보호하기 위해 일반적으로 레벨 4가 사용되지만 NDV 부재에 대한 보다 철저한 분석을 포함하는 레벨 3도 사용할 수 있습니다.

표시된 제어 수준 간의 주요 차이점은 4단계는 정적 소프트웨어 분석을 위한 활동만 포함하고 3단계 제어 활동은 동적 분석을 위한 활동도 수행된다는 것입니다. 이러한 수준의 정적 분석 프로세스는 규제된 기술 작업의 양에 따라 다릅니다. 따라서 레벨 3의 제품 인증을 통해 개발자는 국가 기밀 보호 수단 시장에 접근할 수도 있습니다.

우리는 인증에 찬성하여 다음과 같은 주장을 자주 듣습니다.

• 인증된 소프트웨어가 정보 보안 기능을 올바르게 수행합니다.
• 인증된 소프트웨어는 고객 정보에 해를 끼칠 수 있는 메커니즘이 내장되어 있지 않음을 보장합니다.

실제로, 소프트웨어 인증서가 있다고 해서 항상 이러한 규정의 준수가 보장되는 것은 아닙니다.

국내 시장에서 제공되는 인증서가 있는 제품을 사용하면 일반적으로 전체 소프트웨어 오류가 있고 사용 편의성이나 설정 유연성을 제공하지 않기 때문에 다소 안타까운 광경을 보이는 경우가 많습니다.

안에 대기업프로그램의 오류를 찾아서 테스트하는 것은 별도의 무대, 엄격하게 확립된 방법에 따라 구축되고 수행되었습니다. 많은 수직원. 추가 확인인증 과정에서 오랜 시간과 상당한 시간이 소요됩니다. 재정적 비용, 경쟁사에게 유리한 출발을 제공하여 회사 이익을 감소시키고 인증 비용으로 인해 최종 제품 비용을 크게 증가시킵니다.

자유 소프트웨어 시장에서는 매니아들이 이러한 기능을 수행합니다. 그들은 종종 이 분야에 대해 매우 깊은 지식을 갖고 있으며 그 수는 어떤 실험실의 직원보다 훨씬 많습니다. 이를 통해 전체 코드를 철저하게 검토하고 모든 약점을 수정할 수 있습니다.

안에 지금은 NDV 부재에 대한 인증을 수행하는 테스트 실험실에는 사람도 없고 기술 자원, 적절한 수준에서 허용 가능한 한 빨리복잡한 소프트웨어에 대한 검증 절차를 수행합니다.

또 다른 문제는 소프트웨어 업데이트와 패치가 발급된 인증서의 조건을 위반하고 요구 사항이 있다는 것입니다. 절차를 반복하다체크 무늬. 인증서가 만료된 경우에도 유사한 상황이 발생합니다. NDV 부재 모니터링에 관한 새로운 지침 문서가 있는 경우 확립된 절차새로 제공되는 제품의 인증 속성과 기존 인증 버전의 속성 준수 분석을 기반으로 하는 인증서 확인 및 갱신이 더 이상 작동하지 않습니다.

제품에 소프트웨어 북마크(SW)가 존재하는 문제의 역설

이 역설은 인증 전에는 소프트웨어에 PP가 없었지만 인증 후에는 나타날 수 있다는 사실에 있습니다. 인증서를 획득했다는 착각은 개발자의 경계를 크게 감소시키고 고객에게 예측할 수 없는 결과를 초래할 수 있습니다. 개별 조직이러한 북마크를 사용하면 숨겨진 모니터링을 수행하고 회사 정보를 캡처하여 재량에 따라 사용할 수 있습니다. 이러한 북마크가 식별되면 해당 북마크뿐만 아니라 최종 사용자, 또한 이미지와 평판에 큰 타격을 주고 시장에서의 입지를 약화시킬 개발 회사이기도 합니다. 고객은 전체 보호 시스템을 새로 재구축해야 하며 이로 인해 새로운 비용이 발생하게 됩니다.

정보보호 규제체계는 매우 좋은 의미로일정 수준의 제품 품질을 설정하기 위한 것이지만, 이것이 경쟁을 방해하거나 시장을 규제하는 도구가 되어서는 안 됩니다.

현재 상황을 분석해 보면 기밀 정보 보호를 위한 제품 인증은 보안에 대한 불필요한 착각을 불러일으키기 때문에 관련성이 충분하지 않은 것으로 나타났습니다. 선택할 때 소프트웨어자신을 보호하려면 먼저 전문가의 리뷰와 개발자의 평판을 확인해야 합니다.

현재 진정으로 신뢰할 수 있는 보호 시스템을 구축하려면 유능하고 검증된 서비스에 돈을 투자하는 것이 좋습니다. 시스템 관리자그리고 컨설턴트. 그들의 지식과 경험은 귀하가 특정 회사에 가장 안정적이고 적합한 솔루션을 선택하는 데 도움이 될 것입니다.

주제에 관한 기사

설계 중 정보 보안 요구 사항 정보 시스템사용된 정보 보안 수단을 특징짓는 특성이 표시됩니다. 이는 보안 분야의 다양한 규제 기관 행위에 의해 정의됩니다. 정보 보안, 특히 - FSTEC 및 러시아 FSB. 어떤 보안 등급이 있는지, 보호 장비의 유형과 유형, 이에 대해 자세히 알아볼 수 있는 위치가 기사에 반영되어 있습니다.

소개

오늘날 정보 보안 보장 문제는 세심한 관심의 대상입니다. 정보 보안을 보장하지 않고 모든 곳에서 구현되는 기술이 새로운 심각한 문제의 원인이 되기 때문입니다.

러시아 FSB는 상황의 심각성을 보고합니다. 전 세계적으로 수년 동안 공격자들에 의해 발생한 피해 규모는 3000억 달러에서 1조 달러에 이릅니다. 제공된 정보에 따르면 검찰총장러시아 연방, 2017년 상반기에만 러시아 현장 범죄 건수 첨단 기술 6배 증가 총액 2017년에는 전 세계적으로 산업 부문의 표적 공격이 증가한 것으로 나타났습니다. 특히 러시아에서는 2016년 대비 공격 건수가 22% 증가했다.

정보기술이 군사·정치적, 테러 목적의 무기로 사용되기 시작했고, 내정 간섭에도 활용되기 시작했다. 주권 국가, 기타 범죄를 저지른 경우도 있습니다. 러시아 연방은 국제 정보 보안 시스템 구축을 지지합니다.

영토에서 러시아 연방정보 소유자와 정보 시스템 운영자는 정보에 대한 무단 접근 시도를 차단하고 IT 인프라의 보안 상태를 모니터링할 의무가 있습니다. 지속적으로. 동시에 기술적 조치를 포함한 다양한 조치를 취하여 정보 보호를 보장합니다.

정보 보안 도구 또는 정보 보호 시스템은 기본적으로 데이터베이스에 저장된 정보 모음인 정보 시스템의 정보 보호를 보장합니다. 정보 기술, 처리 보장 및 기술적 수단.

현대 정보 시스템은 다양한 하드웨어 및 소프트웨어 플랫폼의 사용, 구성 요소의 영토적 분포, 개방형 데이터 네트워크와의 상호 작용이 특징입니다.

이러한 상황에서 정보를 보호하는 방법은 무엇입니까? 해당 요구 사항이 부과됩니다. 승인된 기관, 특히 FSTEC과 러시아의 FSB. 기사의 틀 내에서 이러한 규제 기관의 요구 사항을 고려하여 정보 보안 시스템 분류에 대한 주요 접근 방식을 반영하려고 노력할 것입니다. 규제 문서에 반영된 정보 보호 장비 분류를 설명하는 다른 방법 러시아 부서, 그리고 또한 외국 단체대행사는 그 이상입니다 이 기사의더 이상 고려되지 않습니다.

이 기사는 러시아 FSTEC(대부분) 및 간략히 러시아 FSB의 요구 사항을 기반으로 정보 보안을 분류하는 방법에 대한 구조화된 정보의 소스로서 정보 보안 분야의 전문가를 시작하는 데 유용할 수 있습니다.

비암호화 정보 보안 방법의 제공을 절차를 결정하고 조정하는 구조는 러시아의 FSTEC(구 러시아 연방 대통령 산하 국가 기술 위원회, 국가 기술 위원회)입니다.

독자가 러시아 FSTEC에서 설립한 국가 공인 정보 보안 도구 등록부를 본 적이 있다면 정보 보호 시스템의 목적을 설명하는 부분에 "RD SVT"와 같은 문구가 있다는 점에 확실히 주의를 기울였을 것입니다. 등급', '부적합 데이터에 대한 부적합 부재 수준' 등(그림 1).

그림 1. 인증된 정보보호기기 등록부 일부

암호정보 보안도구의 분류

러시아 FSB는 암호화 정보 보호 시스템 클래스를 KS1, KS2, KS3, KV 및 KA로 정의했습니다.

KS1급 정보보안장비의 주요 특징은 외부로부터의 공격에 대한 저항력이다. 통제 구역. 이는 공격 방법의 생성, 준비 및 구현이 암호화 정보 보안 개발 및 분석 분야의 전문가 참여 없이 수행됨을 의미합니다. 특정 정보보안 시스템이 사용되는 시스템에 대한 정보는 오픈소스로부터 얻을 수 있다고 가정한다.

암호화 정보 보안 시스템이 클래스 KS1을 통해 차단된 공격과 통제된 영역 내에서 수행되는 공격을 견딜 수 있는 경우 해당 정보 보안은 클래스 KS2에 해당합니다. 예를 들어, 공격을 준비하는 동안 다음에 대한 정보가 가능합니다. 물리적 조치정보시스템 보호, 통제구역 제공 등

자금에 물리적으로 접근할 수 있는 경우 공격에 저항할 수 있는 경우 컴퓨터 기술암호화 정보 보안 시스템이 설치되어 있으면 KS3 클래스와 같은 수단을 준수한다고 말합니다.

암호화정보 보안이 개발 및 분석 분야의 전문가가 참여하여 발생한 공격에 저항하는 경우 특정 자금, 연구 센터를 포함하여 보호 장비에 대한 실험실 연구를 수행 할 수 있었고, 우리 얘기 중이야 HF 클래스를 준수합니다.

NDV 시스템 소프트웨어 사용 분야의 전문가가 공격 방법 개발에 참여한 경우 해당 디자인 문서암호화 정보 보안의 하드웨어 구성 요소에 대한 액세스가 있었다면 KA 클래스를 통해 이러한 공격에 대한 보호를 제공할 수 있습니다.

전자서명 보호수단의 분류

수단 전자 서명공격을 견딜 수 있는 능력에 따라 KS1, KS2, KS3, KV1, KV2 및 KA1 클래스와 비교하는 것이 일반적입니다. 이 분류는 암호화 정보 보안과 관련하여 위에서 설명한 분류와 유사합니다.

결론

이 기사에서는 러시아의 정보 보안 시스템을 분류하는 몇 가지 방법을 조사했으며 그 기반은 다음과 같습니다. 규제 체계정보 보안 분야의 규제 기관. 고려되는 분류 옵션은 완전하지 않습니다. 그럼에도 불구하고 제시된 요약 정보를 통해 정보 보안 분야의 초보 전문가가 보다 빠르게 탐색할 수 있기를 바랍니다.

그런데 "NDV 라이센스"는 없습니다.

나는 그것을 파고드는 것이 아니라 단지 그것을 알아내고 싶을 뿐입니다.

공동 개발인 경우 신청자는 개발자 중 한 명이 될 수 있습니다.

지원자는 간단합니다. 그렇다면 왜 이 일을 해야 합니까?

추가 생산을 위해서는 라이센스가 필요합니다.

그렇지 않은 경우 인증을 위한 일련의 문서, 개발 사용에 대한 개발자와의 계약 또는 기타 기반이 필요합니다. 안에 이 경우후속 판매로 생산이 불가능한 경우 인증서가 필요한 이유는 무엇입니까?

> 개발자가 개발 또는 기타 기반의 사용에 대해 설명합니다. 이 경우

> 후속 판매로 생산이 불가능하다면 왜 인증서가 필요합니까?

FSTEC 인증을 받는 방법

탐나는 인증서를 받다

FSB의 요구 사항에 따른 비암호화 정보 및 통신 시스템 인증

I.G. 샤포시니코프, LLC "인증 연구 센터" 이사, Ph.D.

V.A. 밀체프, Licensing and Certification LLC "인증 연구 센터" 부국장

FSB(이전 FAPSI)의 활동 영역 중 하나는 암호화 정보 보호 수단 인증입니다. 인증 연구 자체는 공인된 실험실 및 센터에서 수행됩니다. 동시에, 제품이 정보 보안 요구 사항을 준수하는지 확인합니다. LLC "인증 연구 센터"(CSR)는 암호화 장비 인증에 종사하는 조직으로 만들어졌습니다. 따라서 첫 번째 라이센스를 취득함으로써 센터는 FAPSI가 정한 통신 보안 요구 사항에 따라 암호화 기술 인증을 위한 테스트 연구소의 지위를 획득했습니다. 암호화 기술 인증은 인증 고객이 구현 절차를 명확하게 이해하는 데 필요한 활동 영역입니다. 후자는 일반적으로 인증 절차를 성공적으로 완료하기 위해 취해야 할 조치와 제출할 자료를 알고 있습니다. 지정된 순서법적으로 여러 가지로 고정되어 있습니다. 규제 문서(예: PKZ-2005)

새로운 요구 사항에 따라

안에 최근에 FSB 정보보안 요구사항에 따른 인증제품의 범위가 대폭 확대되었습니다. 요즘은 통신장비 뿐만 아니라 암호화 수단보호하지만 아무것도 없습니다.

현재 FSB는 암호화 기술 외에도 다음을 인증합니다.

• 디지털 PBX;
• 방화벽;
• 다시성 디지털 계층 장비;
• 에 사용되는 소프트웨어 자동화 시스템아 특별한 목적을 위한 ITCS;
• 항바이러스제.

인증 연구를 수행할 때 FSB의 규제 문서(요구 사항, 방법)가 사용됩니다. 현재 이러한 문서는 암호화 정보 보호 수단을 포함하지 않는 모든 유형의 위 통신 장비에 대해 존재합니다. CRC는 이러한 새로운 요구 사항에 따라 인증 연구를 수행하는 선구자가 되었으며 규제 창설에 참여했습니다. 방법론적 문서그리고 그것들을 엄격하게 준수하여 일합니다.

이 기사의 목적은 암호화 기술이 포함되지 않은 장비를 인증하는 데 있어 기존의 어려움에 대한 아이디어를 제공하는 것입니다. 또한 이 기술의 창시자에게 제시되는 요구 사항을 숙지할 필요가 있습니다.

안에 최근 몇 년일반적으로 이 절차에 익숙하지 않은 새로운 비정부 개발 회사가 많이 등장했습니다. 광범위한 약물의 결핍은 부정적인 역할을 합니다(예: PKZ-99 및 PKZ-2005). 주 문서안전 요구 사항의 개발 및 인증을 규제합니다. 부재시 행동 순서가 결정됩니다. 기존 관행. 아래에서는 CRC의 경험을 바탕으로 절차의 가장 중요한 사항을 반영하려고 노력할 것입니다.

신청부터 자격증까지

따라서 인증에는 다음과 같은 필수 단계가 포함됩니다.

• FSB에 인증 신청서 제출 - 인증을 수행해야 하는 요구 사항을 준수하기 위한 인증 계획, 표준 및 기타 규제 문서의 이름을 나타냅니다.
• 인증 요구 사항 수준 조정;
• 기술 사양 개발 및 테스트 연구소와의 계약 체결;
• 인증받은 제품의 샘플 제시 및 모든 것 필요한 서류테스트를 위해;
• 인증 테스트 수행;
• 후속 검증을 통해 안전 요구 사항에 따라 제품 수정(필요한 경우)
• 보고서를 준비하여 FSB에 보냅니다. » FSB에 대한 보고서 준비 및 인증서 발급.

인증 제품에 대한 요구 사항 수준은 원칙적으로 FSB 및 인증 장비가 설치될 시스템 고객과 함께 인증 고객에 의해 결정됩니다. 동시에 한계도 있다 기능성하드웨어 - 다음에 사용되는 기능만 이 응용 프로그램, 다른 것들은 소프트웨어 또는 하드웨어 수준에서 삭제되거나 차단됩니다. 최대 높은 수준정보 보호 요구 사항은 국가 비밀을 구성하는 정보가 포함된 정보의 처리와 관련이 있습니다. 따라서, 그 처리를 위한 기술적 수단을 인증할 때, 최대 수량유형의 테스트를 수행하며 각 테스트는 가장 엄격한 표준을 따릅니다. 이는 당연히 더 길고 더 노동 집약적인 연구가 수반됩니다. 그리고 장비 개발자(신청자)는 가장 상세하고 완전한 재료(문서) 인증된 장비에 관한 것입니다.

인증장비 제출서류 목록

1. 인증된 개체의 아키텍처에 대한 자세한 다이어그램. 기능 블록그리고 그들 사이의 연결.

2. 전체 제품의 작동에 대한 설명입니다.

3. 각 보드(하위 장치)에 대해 다음이 제공되어야 합니다.

• 기술적 설명;
• 설정 지침;
• 작동 지침;
• 전기 회로도;
• 요소 목록;
• 기능 다이어그램.

4. 자세한 설명다음을 포함해야 하는 소프트웨어:

• 소프트웨어 아키텍처;
• 기능 다이어그램;
• 알고리즘이 가장 중요한 절차및 기능;
• 모든 모듈과 그 의미의 목록
• 모든 프로시저, 함수, 상수 및 변수 목록과 그 목적
• 주석이 포함된 모든 원본 텍스트;
• 소프트웨어 소스 코드 작업을 위한 개발 도구;
• 개발 도구용 구성 파일;
• 최종 소프트웨어 프로젝트의 컴파일 도구, 방법 및 조립 순서
• 인증된 장비에 대한 테스트 계획과 인증된 장비에 대해 선언된 모든 기능.

기준은 변하지 않는다

인증에는 특수 통신 시스템 고객의 요구에 따라 특정 단계에서 장비 개발 프로세스를 "동결"시키는 것이 포함된다는 사실을 특히 강조할 필요가 있습니다. 따라서 위의 모든 문서는 이 "동결된" 수정 사항을 참조해야 합니다. 후자는 모든 범위의 테스트를 거쳐 인증서를 받고 모델이 됩니다. 이는 “인증”이라는 개념이 적용되는 장비를 생산하는 데 사용됩니다.

통신 장비 개발자는 오류 수정, 수행 기능 확장 또는 변형 하드웨어(예: 요소 기반) 추적을 위해 장비의 소프트웨어를 정기적으로 변경합니다. 즉, 장비의 지속적인 현대화가 발생합니다. 그러나 변형이 있는 장비로 인증서를 확장하려면 추가 연구가 필요합니다. 일반적으로 개발자와 인증 기관 사이에 오해가 발생하는 곳입니다. 첫째, 첫 번째 문서는 다음과 관련된 다양한 부분을 제출합니다. 다른 단계장비의 "개발" 및 인증 후에는 자신의 관점에서 충족되지 않는 사소한 변경이 가능하다고 간주합니다. 높은 요구 사항인증된 장비에 대한 요구 사항.

이처럼 엄격한 보안기준 정보 보안 FSB의 요구 사항에 따른 통신 장비의 사용 영역은 사용 영역에 따라 결정됩니다. FSB 인증서는 장비를 작동할 수 있는 기회를 제공합니다. 고위 당국당국. 따라서 하드웨어 개발자는 인증을 받기 전에 인증이 필요한지 여부를 고려해야 합니다. 충분히 얻을 수 있을 가능성이 있습니다 FSTEC 인증서, 장비를 다음에서 사용할 수 있습니다. 정부 기관. FSB 요구 사항에 따라 인증을 결정한 경우 인증 연구소의 전문가와 협력하여 기술 사양을 작성하고, 보호 수준을 결정하고, 인증을 위한 문서 및 장비 목록을 작성해야 합니다. 예를 들어 현대 미술 센터에서는 기관과 계약을 체결하기 전에도 이러한 준비가 수행됩니다.

추가로 중요한 점 협동인증 기관과 고객은 연구 범위와 그에 따른 작업 비용을 결정합니다. 검사 중인 장비의 복잡성으로 인해 수행 없이 이 볼륨을 설정하는 것이 때로는 어렵습니다. 예비 연구. 그러면 처음에는 작업의 첫 번째 단계에 대해서만 계약이 체결됩니다. 예비 분석 FSB의 관련 부서와 일치하는 문서, 프로그램 및 테스트 방법이 개발되고 있습니다. 합의된 연구 프로그램은 향후 연구 규모, 구현 시기 및 작업 비용을 결정하는 객관적인 문서가 됩니다.

또 한 가지 주목할 만한 점 중요한 점인증 연구 구현 - 제출된 보고서 검토 전문단체(제 8 FSB 센터 단위). 이 단계는 인증 계약에 포함되지 않지만(FSB는 계약 당사자가 될 수 없기 때문에) 구현에는 일반적으로 최대 2개월이 소요됩니다. 조사 결과 보안 요구 사항 준수에 대한 제 8 FSB 센터의 결론이 나왔습니다. 물론, 인증 연구소 보고서의 긍정적인 결론이 결론에 대한 동일한 긍정적인 평가를 보장하는 것은 아닙니다. 그러나 우리 테스트 실험실의 관행에 따르면 결론의 일치는 거의 100%에 이릅니다. 에이 긍정적인 결론인증서를 받을 수 있는 자격을 부여합니다.

논의

인증이 필요합니까? 필요한 경우 어떤 서류를 기준으로 합니까?

암호화 기술의 전문 용어가 언제부터 문자 "O9"로 시작되었는지 이해가 되지 않습니다.

이전에는 "LOBERS"만이 이런 식으로 썼습니다.

가격도 없고 명확한 요구사항도 없습니다.

인증자는 어디에 있었나요?

인증이니 참고하세요 상기 기술이는 컴퓨터 공격, 무단 액세스로부터 정보 통신 시스템 운영에 대한 일정 수준의 안정성을 보장하므로 필요하다고 인정됩니다. 정보 자원, 불법적이거나 잘못된 행위 서비스 인력. 그렇기 때문에 일반적으로 정부 고객이 인증 장비를 요구하며 이는 개발자에게 중요합니다.

이것은 무엇에 관한 것인가요?

이 방향으로 어떤 일이 이루어졌나요?

방금 비눗방울을 불었나요?

인턴이 글을 썼습니다(첫 번째 하단 사진) - 두 검열관(상단 사진)은 분명히 자고 있었습니다.

"FSB(이전 FAPSI) 활동 영역 중 하나"

마치 FSB가 FAPSI라고 불렸던 것처럼 :)

KGB 제8본부 인원은 KGB와 SVR로 나누어졌다.

그런 다음 KGB에서는 FSK라고 불렸고 어딘가에 FAPSI가 동일한 것으로 구성되었습니다.

그리고 푸틴 대통령이 FAPSI를 FSO, FSB, SVR로 나누었을 때 그는 이미 모든 사람을 혼란스럽게 했습니다.

그래서 그들은 부서장(부서)의 이름이 동수들에게 무엇인가를 말해 준다고 가정하고 자신들이 원하는 대로 자신들을 부른다.

한마디로로드하지 마십시오. 모두 엉망입니다.

이전에는 이 영역이 FAPSI의 관할권에 속해 있었습니다. FAPSI가 분할되면 FSB로 넘어갔습니다.

백과사전에서 그 주제를 공부하셨나요?

아니면 의도적으로 이 오류를 (백과사전에) 삽입했습니까?

아마추어가 아닌 전문적인 환경에서 제가 알 수 있는 한, 용어는

암호 "o9TEHNIKA"는 고대부터 접속사 "O9" 없이 작성되었습니다.

O - Shchechelev 수준의 클릭커 및 기타 "JOURNALISTS9-" 전문가9를 위한 것입니다.

진짜 지침 문서(RD)는 선언되지 않은 기능의 부재에 대한 통제 수준에 따라 일반 시스템 및 응용 소프트웨어에 내장된 소프트웨어를 포함하여 소프트웨어(국내 및 수입) 정보 보안 도구(IS)의 분류를 설정합니다.

이 문서는 암호화 정보 보호 도구용 소프트웨어에는 적용되지 않습니다.

통제 수준은 이 RD에서 지정한 요구 사항 집합의 충족에 따라 결정됩니다. :

구성과 문서 내용, 정보보호 소프트웨어 테스트를 위해 신청자가 제출한 정보

지침 문서는 RD "컴퓨터 시설"에 추가로 개발되었습니다. 정보에 대한 무단 액세스로부터 보호합니다. 정보에 대한 무단 접근에 대한 보안 지표", M., Military Publishing House, 1992,

RD “자동화 시스템. 정보에 대한 무단 액세스로부터 보호합니다. 자동화 시스템 분류 및 정보 보호 요구 사항”, M., 군사 출판사,

1992 및 RD “컴퓨터 시설. 방화벽. 정보에 대한 무단 액세스로부터 보호합니다. 정보에 대한 무단 접근에 대한 보안 지표”, M., 1997.

이 문서는 전문가를 위한 것입니다. 테스트 실험실, 고객, 정보 보안 소프트웨어 개발자를 모니터링하면서 선언되지 않은 기능이 없는지 확인합니다.

1. 일반 조항

1.1. 분류제한된 정보를 보호하도록 설계된 소프트웨어에 적용됩니다.

1.2. 설치됨 네 가지 수준의 제어선언되지 않은 기능이 부족합니다. 각 레벨은 특정 최소 요구 사항 세트가 특징입니다.

1.3. 정보를 보호하기 위해 사용되는 소프트웨어의 경우, ~에 귀속됨 국가기밀, 통제 수준은 다음보다 낮지 않도록 보장되어야 합니다. 제삼.

1.4 . 최고 수준의 제어 – 첫 번째 , "OV"로 분류된 정보를 보호하는 데 사용되는 소프트웨어에는 충분합니다.

두번째 통제 수준 "CC"라고 표시된 정보를 보호하는 데 사용되는 소프트웨어에는 충분합니다.

제삼 통제 수준 충분한 "C"라고 표시된 정보를 보호하는 데 사용되는 소프트웨어입니다.

1.5 최대 낮은 수준제어 - 네번째 , 보호에 사용되는 소프트웨어로는 충분합니다. 비밀의정보.

2. 용어 및 정의

2.1. 선언되지 않은 기능 - 설명되지 않았거나 문서에 설명된 기능과 일치하지 않는 소프트웨어 기능. 이를 사용하면 처리된 정보의 기밀성, 가용성 또는 무결성을 위반할 수 있습니다. 특히 선언되지 않은 기능의 구현은 소프트웨어 북마크입니다.

2.6. 기능 객체의 실제 실행 경로는 다음과 같은 경우에 실제로 실행되는 기능 객체의 순서입니다. 특정 조건(입력 데이터).

정보에 대한 무단 접근으로부터 보호 1부. 정보 보안 소프트웨어

선언되지 않은 기능의 부재에 대한 통제 수준에 따른 분류

국가 의장의 결정에 의해 승인됨 기술위원회 1999년 6월 4일자 러시아 연방 대통령 N 114

이 지침 문서(RD)는 선언되지 않은 기능의 부재에 대한 통제 수준에 따라 일반 시스템 및 응용 소프트웨어에 내장된 소프트웨어를 포함하여 소프트웨어(국내 및 수입) 정보 보안 도구(IS)의 분류를 설정합니다.

이 문서는 암호화 정보 보호 도구용 소프트웨어에는 적용되지 않습니다.

통제 수준은 다음과 같이 부과된 본 RD에서 지정한 요구 사항 집합의 충족에 따라 결정됩니다.
- 정보 보호 소프트웨어 테스트를 위해 신청자가 제출한 문서의 구성 및 내용
- 테스트 내용.

지침 문서는 다음을 보완하기 위해 개발되었습니다.
- RD “컴퓨터 시설. 정보에 대한 무단 액세스로부터 보호합니다. 정보에 대한 무단 접근에 대한 보안 지표”, M., Military Publishing House, 1992;
- RD “자동화 시스템. 정보에 대한 무단 액세스로부터 보호합니다. 자동화 시스템 분류 및 정보 보호 요구 사항”, M., Military Publishing House, 1992;
- RD “컴퓨터 시설. 방화벽. 정보에 대한 무단 액세스로부터 보호합니다. 정보에 대한 무단 접근에 대한 보안 지표", M., 1997.

이 문서는 선언되지 않은 기능이 없는지 모니터링할 때 테스트 실험실 전문가, 고객 및 정보 보안 소프트웨어 개발자를 대상으로 합니다.

1. 일반 조항

1.1. 이 분류는 제한된 정보를 보호하도록 설계된 소프트웨어에 적용됩니다.

1.2. 선언되지 않은 기능의 부재에 대한 4가지 수준의 제어가 설정됩니다. 각 레벨은 특정 최소 요구 사항 세트가 특징입니다.

1.3. 국가기밀로 분류된 정보를 보호하기 위해 사용되는 소프트웨어에 대해서는 최소한 3분의 1 수준의 통제수준이 보장되어야 한다.

1.4. "OV"로 분류된 정보를 보호하는 데 사용되는 소프트웨어에는 최고 수준의 제어가 첫 번째로 충분합니다.

"CC"라고 표시된 정보를 보호하는 데 사용되는 소프트웨어에는 두 번째 수준의 제어로 충분합니다.

"C"로 분류된 정보를 보호하는 데 사용되는 소프트웨어의 경우 세 번째 제어 수준으로 충분합니다.

1.5 가장 낮은 통제 수준은 네 번째로, 기밀 정보를 보호하는 데 사용되는 소프트웨어에 충분합니다.

2. 용어 및 정의

2.1. 선언되지 않은 기능은 설명되지 않았거나 문서에 설명된 기능과 일치하지 않는 소프트웨어 기능으로, 이를 사용하면 처리된 정보의 기밀성, 가용성 또는 무결성을 위반할 수 있습니다.

특히 선언되지 않은 기능의 구현은 소프트웨어 북마크입니다.

2.2. 소프트웨어 북마크는 특정 조건(입력 데이터)에서 문서에 설명되지 않은 소프트웨어 기능의 실행을 시작하여 처리된 정보의 기밀성, 가용성 또는 무결성을 침해하는 소프트웨어에 의도적으로 추가된 기능 개체입니다.

2.3. 기능적 객체는 프로그램 알고리즘의 완성된 부분을 구현하기 위한 작업을 수행하는 프로그램 요소입니다.

기능적 객체는 프로시저, 함수, 분기, 연산자 등이 될 수 있습니다.

2.4. 정보 객체- 프로그램에서 순환하는 정보 조각을 포함하는 프로그램 요소입니다. 프로그래밍 언어에 따라 정보 객체변수, 배열, 레코드, 테이블, 파일, 조각이 될 수 있습니다. 숫양등.

2.5. 기능 객체의 실행 경로는 알고리즘에 의해 결정된 실행된 기능 객체의 순서입니다.

2.6. 기능 객체의 실제 실행 경로는 특정 조건(입력 데이터)에서 실제로 실행되는 기능 객체의 순서입니다.

2.7. 기능 객체 실행을 위한 중요한 경로는 통제되지 않은 위반 가능성이 있는 경로입니다. 정해진 규칙정보 개체를 처리합니다.

2.8. 프로그램 소스 코드의 정적 분석은 문서에 구현되고 선언된 소프트웨어 기능의 (부)적합성을 모니터링하기 위한 일련의 방법입니다. 구조 분석프로그램 소스 코드의 분해.

2.9. 프로그램 소스 코드의 동적 분석은 기능 개체의 실제 실행 경로 식별과 정적 분석 과정에서 구성된 경로와의 후속 비교를 기반으로 문서에 구현되고 선언된 소프트웨어 기능의 준수 여부를 모니터링하는 방법 세트입니다. .

3. 통제 수준에 대한 요구사항
3.1. 요구 사항 목록

표 1

명칭
"-" - 요구사항 없음 이 수준;
"+" - 신규 또는 추가 요구 사항;
"=" - 요구 사항은 이전 레벨의 요구 사항과 동일합니다.

3.2. 네 번째 수준의 통제에 대한 요구 사항

3.2.1. 문서의 구성 및 내용 관리

신청자가 제출한 서류에는 다음이 포함되어야 합니다.

소프트웨어 구성 및 문서에 대한 정보가 포함된 사양(GOST 19.202-78)

구성에 대한 기본 정보(소프트웨어에 포함된 파일의 체크섬 표시)가 포함된 프로그램 설명(GOST 19.402-78) 논리적 구조소프트웨어 운영 환경, 소프트웨어 제작 시 기술 장비를 운영하는 방법, 기술 및 규칙에 대한 설명

소프트웨어 목적, 적용 범위, 사용 방법, 해결해야 할 작업 클래스, 적용 제한 사항, 하드웨어의 최소 구성, 운영 환경 및 운영 절차에 대한 정보가 포함된 적용 설명(GOST 19.502-78).

소프트웨어에 포함된 프로그램의 소스 텍스트(GOST 19.401-78).

수입된 소프트웨어의 경우 문서 구성이 필요한 것과 다를 수 있지만 내용은 지정된 GOST의 요구 사항을 준수해야 합니다.

3.2.2. 소프트웨어의 초기 상태 모니터링

제어는 소프트웨어의 초기 상태를 기록하고 얻은 결과를 문서에 제공된 결과와 비교하는 것으로 구성됩니다.

소프트웨어의 초기 상태를 모니터링한 결과는 소프트웨어에 포함된 프로그램의 소스 코드와 로드 모듈의 고유한 체크섬 값으로 계산되어야 합니다.

소프트웨어에 포함된 각 파일에 대해 체크섬을 계산해야 합니다.

3.2.3. 프로그램 소스 코드의 정적 분석

프로그램 소스 코드의 정적 분석에는 다음과 같은 기술 작업이 포함되어야 합니다.
- 파일 수준에서 소프트웨어 소스 텍스트의 완전성 및 중복성 부족을 제어합니다.
- 소프트웨어 소스 텍스트와 해당 개체(부팅) 코드의 준수를 제어합니다.

3.2.4. 보고

테스트가 완료되면 결과가 포함된 보고서(프로토콜)가 작성됩니다.
- 소프트웨어의 초기 상태를 모니터링합니다.
- 파일 수준에서 제어 대상 소프트웨어의 소스 텍스트의 완전성 및 중복성 부재에 대한 제어
- 소스 텍스트와 해당 개체(부팅) 코드의 준수를 제어합니다.

3.3. 세 번째 수준의 통제 요건

3.3.1. 문서의 구성 및 내용 관리

요구 사항에는 네 번째 제어 수준에 대한 유사한 요구 사항이 완전히 포함됩니다.

또한 소프트웨어에 포함된 구성 요소의 목적, 처리된 데이터 세트(데이터베이스 하위 스키마)의 매개변수, 생성된 반환 코드, 설명에 대한 기본 정보가 포함된 "설명 참고 사항"(GOST 19.404-79)을 제시해야 합니다. 사용된 변수, 작동하는 알고리즘 등

3.3.2. 소프트웨어 초기 상태 모니터링

요구 사항에는 네 번째 수준의 제어에 대한 유사한 요구 사항이 완전히 포함됩니다.

3.3.3.프로그램 소스코드의 정적 분석

네 번째 통제 수준에 대한 유사한 요구 사항 외에도 추가 다음 요구 사항:
- 기능 개체(절차) 수준에서 소프트웨어 소스 텍스트의 완전성 및 중복성 부족을 제어합니다.
- 관리를 위한 기능 개체(모듈, 절차, 기능)의 연결 제어
- 정보에 따라 기능 개체(모듈, 프로시저, 기능)의 연결을 제어합니다.
- 정보객체의 통제 다양한 유형(예: 지역 변수, 전역 변수, 외부 변수 등)
- 기능 개체(프로시저, 함수)를 실행하기 위한 경로 목록 형성.

3.3.4. 프로그램 소스 코드의 동적 분석

프로그램 소스 코드의 동적 분석에는 다음과 같은 기술 작업이 포함되어야 합니다.
- 기능 개체(프로시저, 기능)의 실행 제어
- 기능 객체(프로시저, 함수)의 실제 실행 경로와 정적 분석 과정에서 구축된 경로를 비교합니다.

3.3.5. 보고

네 번째 통제 수준에 대한 유사한 요구 사항 외에도 보고서(프로토콜)에는 다음 결과가 추가로 포함되어야 합니다.
- 기능 개체(절차) 수준에서 제어되는 소프트웨어 소스 텍스트의 완전성 및 중복성 부족을 제어합니다.
- 관리를 위한 기능 개체(모듈, 절차, 기능)의 연결 제어
- 정보에 따라 기능 개체(모듈, 프로시저, 기능)의 연결을 제어합니다.
- 다양한 유형의 정보 객체 제어(예: 지역 변수, 전역 변수, 외부 변수 등)
- 기능 개체(프로시저, 기능)를 실행하기 위한 경로 목록을 구성합니다.
- 기능 개체(프로시저, 기능)의 실행을 모니터링합니다.
- 기능 객체(프로시저, 함수)의 실제 실행 경로와 정적 분석 과정에서 구축된 경로를 비교합니다.

3.4. 두 번째 수준의 통제에 대한 요구 사항

3.4.1. 문서의 구성 및 내용 관리

3.4.2. 소프트웨어 초기 상태 모니터링

요구 사항에는 세 번째 수준의 제어에 대한 유사한 요구 사항이 완전히 포함됩니다.

3.4.3. 프로그램 소스 코드의 정적 분석

- 기능 개체(기능) 수준에서 제어되는 소프트웨어 소스 텍스트의 완전성 및 중복성 부족을 제어합니다.
- 잠재적으로 위험한 목록(기본)에서 소프트웨어 소스 텍스트에 지정된 구조의 존재에 대한 구문 제어 프로그램 구성;
- 기능 개체(분기) 실행을 위한 경로 목록 형성
- 전문가가 지정한 정보 개체 목록에 대한 기능 개체(절차, 기능) 실행을 위한 주요 경로 분석
- 제어되는 소프트웨어의 소스 텍스트로부터 블록 다이어그램, 다이어그램 등을 구성하고 기능 개체(프로시저, 기능)의 작동 알고리즘과 "에 제공된 작동 알고리즘에 대한 후속 분석을 수행합니다. 설명문”.

3.4.4. 프로그램 소스 코드의 동적 분석

세 번째 수준의 통제에 대한 유사한 요구 사항 외에도 다음 요구 사항이 추가로 부과됩니다.
- 기능 개체(분기)의 실행 제어
- 기능 객체(브랜치)의 실제 실행 경로와 정적 분석 과정에서 구축된 경로 비교

3.4.5 보고

세 번째 수준의 통제에 대한 유사한 요구 사항 외에도 보고서(프로토콜)에는 다음 결과가 추가로 포함되어야 합니다.
- 기능 개체(기능) 수준에서 제어되는 소프트웨어 소스 텍스트의 완전성 및 중복성 부족을 제어합니다.
- 잠재적으로 위험한 구조 목록(기본)에서 소프트웨어 소스 텍스트에 지정된 구조의 존재에 대한 구문 제어
- 기능 개체(분기)를 실행하기 위한 경로 목록을 생성합니다.
- 전문가가 지정한 정보 개체 목록에 대한 기능 개체(절차, 기능) 실행을 위한 주요 경로 분석
- 제어 대상 소프트웨어의 소스 텍스트로부터 블록 다이어그램, 다이어그램 등의 구성 및 후속 비교 분석기능 개체(절차, 기능)의 작동 알고리즘 및 "설명 참고 사항"에 제공된 작동 알고리즘
- 기능 개체(브랜치)의 실행을 모니터링합니다.
- 기능 객체(브랜치)의 실제 실행 경로와 정적 분석 과정에서 구축된 경로를 비교합니다.

3.5. 첫 번째 수준의 통제에 대한 요구 사항

3.5.1. 문서의 구성 및 내용 제어

3.5.2. 소프트웨어의 초기 상태 모니터링

요구 사항에는 두 번째 수준의 제어에 대한 유사한 요구 사항이 완전히 포함됩니다.

3.5.3. 프로그램 소스 코드의 정적 분석

두 번째 제어 수준에 대한 유사한 요구 사항 외에도 다음 요구 사항이 추가로 부과됩니다.
- 인증된 컴파일러를 사용하여 소프트웨어 소스 텍스트와 해당 개체(부팅) 코드의 적합성을 제어합니다.
- 잠재적으로 위험한 구조 목록(기본)에서 소프트웨어 소스 텍스트에 지정된 구조의 존재를 의미론적으로 제어합니다.

3.5.4. 프로그램 소스 코드의 동적 분석

요구 사항에는 두 번째 수준의 제어에 대한 유사한 요구 사항이 완전히 포함됩니다.

3.5.5. 보고

두 번째 수준의 통제에 대한 유사한 요구 사항 외에도 보고서(프로토콜)에는 다음 결과가 추가로 포함되어야 합니다.
- 인증된 컴파일러를 사용하여 소프트웨어 소스 텍스트와 개체(부팅) 코드의 호환성을 모니터링합니다.
- 잠재적으로 위험한 구조 목록(기본)에서 소프트웨어 소스 텍스트에 지정된 구조의 존재를 의미론적으로 제어합니다.