SOC 2 규정 준수 및 유지를 위한 도구

SOC(시스템 및 조직 통제) 2 규정 준수는 감사를 통과하기 위해 한 번만 시행하는 단순한 프로세스가 아닙니다. 영구적인 절차 변경은 지루하고 시간이 많이 걸리지만 조직이 SOC 2 감사를 통과할 수 있도록 하기 위해 반드시 필요합니다. 이는 단순히 CPA에게 서류 추적을 제공하는 것 이상의 의미가 있습니다. 규정 준수를 영구적으로 유지하거나 규정 준수 표준을 위반할 위험을 감수할 수 있는 적절한 제어 및 도구를 갖추고 있어야 합니다. SOC 2 규정 준수를 잃는 것은 대부분의 조직에서 선택 사항이 아니지만, 올바른 도구를 사용하면 규정 준수를 유지하고 향후 감사에서 지속적인 규정 준수를 촉진하는 데 도움이 됩니다.

콘텐츠

1. SOC 2에 대한 간략한 개요
2. SLA 표준 충족
3. 규정 준수 여부를 판단하기 위한 추적 지표
4. 다른 지표에 영향을 미치는 KPI
5. 규정 준수를 위한 도구
6. 결론

SOC 2에 대한 간략한 개요

현재 SOC 규정 준수를 검토 중인 조직에게는 고려해야 할 정보의 양이 압도적으로 많을 수 있습니다. 모든 것을 점검해야 하는 것처럼 보일 수도 있습니다. 대부분의 조직은 다음 목표를 위해 노력합니다. SOC 2 또는 SOC 3 규정 준수를 위해 노력합니다. SOC 2와 SOC 3 규정 준수의 주요 차이점은 SOC 3 감사 보고서가 공개적으로 제공된다는 점입니다. 두 가지 유형에 대한 요구 사항은 동일하지만 SOC 3는 일반적으로 공급자의 사이트에 공개적으로 배포됩니다. 예를 들어 Google의 클라우드 플랫폼은 SOC 3를 준수하며 다음 사이트에서 보고서를 읽을 수 있습니다. 해당 사이트.

SOC 2 감사는 조직의 데이터 보안 능력과 고객 데이터의 지속적인 가용성 및 무결성을 보장하는 데 사용되는 제어 기능에 중점을 둡니다. 감사의 5가지 주요 원칙은 다음과 같습니다:

• 개인정보 보호: 조직에서 액세스 제어, 다단계 인증(MFA) 및 암호화를 사용하여 데이터 개인 정보 보호를 유지하나요?
• 보안: 방화벽, 침입 탐지, MFA를 사용하여 공격자가 데이터에 액세스하지 못하도록 차단하고 있나요?
• 가용성: 인프라에 성능 모니터링, 재해 복구, 인시던트 관리 처리 기능이 포함되어 있나요?
• 처리 무결성: 소프트웨어 개발 Lifecycle(SDLC) 및 변경 관리에 품질 보증 및 프로세스 모니터링이 포함되어 있나요?
• 기밀성: 데이터 저장소에 권한이 없는 사용자로부터 보호하기 위한 암호화, 액세스 제어 및 방화벽이 포함되어 있나요?

SOC 2 규정 준수는 다른 규정 준수 표준과 같은 인증이 아닙니다. 이는 데이터 보안 및 가용성에 대한 높은 수준의 표준을 충족하는지 확인하기 위해 현재 절차와 인프라를 감사하는 것입니다. 

SLA 표준 충족

사이버 보안 인프라를 검토하고 보강하기 위해 서두르다 보면 서비스 수준 계약(SLA) 표준을 간과하는 경우가 종종 있습니다. SLA는 고객에게 하는 약속이며, 이러한 약속은 계약에 따른 것으로 반드시 지켜야 합니다. 예를 들어 고객에게 중간 수준의 문제에 대해 5일의 해결 시간을 제공했다면 그 기간 내에 문제를 해결해야 하며, 그렇지 않으면 SLA 목표를 놓치게 됩니다.

에서 KernelCare에서 우리는 고객이자 공급자입니다. 고객에게 서비스를 제공하지만 내부 IT 직원은 내부 직원을 지원하고 자체 표준과 내부 직원과의 약속에 따라 정해진 SLA를 충족해야 합니다. 고객이자 공급자이기도 한 우리는 SLA를 충족하는 것의 중요성과 합리적인 기대치를 설정하는 것의 중요성을 잘 알고 있습니다.

SLA는 협상할 수 있지만 일단 계약이 체결되면 조직은 SLA 요구 사항을 충족하기 위해 노력해야 합니다. SLA 요구 사항 및 메트릭은 일반적으로 티켓팅 시스템과 같은 내부 애플리케이션에서 추적됩니다. 이러한 SLA 요구 사항 중 하나는 가동 시간이며 가용성에 대한 SOC 2 감사 원칙을 다룹니다.

규정 준수 여부를 판단하기 위한 추적 지표

규정 준수를 위해 노력하는 조직의 경우, 첫 번째 단계 중 하나는 보고서를 실행하고 핵심 성과 지표(KPI) 형태의 메트릭을 수집하는 것입니다. KPI는 모든 IT 시스템에서 여러 가지 지표를 측정하는 데 사용됩니다. KPI를 통해 우수한 부분과 개선의 여지가 있는 부분을 파악할 수 있습니다. 또한 더 나은 전략에 집중하고 병목 현상을 제거해야 할 부분을 알려줄 수도 있습니다.

SOC 2 규정 준수에 사용되는 일반적인 KPI는 가동 시간 측정입니다. 가동 시간(또는 시스템 가동 시간)은 연중 시스템을 사용할 수 있는 시간을 의미합니다. 시스템은 서버, 네트워킹 장비 또는 스토리지일 수 있습니다. 서비스를 오프라인으로 전환하고 재부팅이 필요한 예정된 유지보수를 포함하여 모든 다운타임은 이 지표에 영향을 미칩니다. 

우수한 가동 시간 가용성 평가를 달성하기 위해 공급업체는 다음을 위해 노력합니다. 9의 수. 가동 시간 비율에서 9가 많을수록 공급업체가 고객에게 제공할 수 있는 가동 시간 및 가용성의 품질이 더 우수합니다. 예를 들어, 매년 52.60분의 다운타임만 약속할 수 있는 조직은 가용성 또는 가동 시간 비율이 99.99% 또는 4.9입니다. 다운타임 수치가 낮을수록 가동 시간 비율이 높습니다. 모든 조직은 100%를 위해 노력하지만, 현실적으로 단 몇 밀리초라도 예기치 않게 서비스를 중단시키는 문제가 발생하기 때문에 모니터링, 알림 및 직원 대응은 문제 해결 SLA에 매우 중요합니다.

가동 시간만이 규정 준수 검토에 사용되는 유일한 지표는 아닙니다. 일반적으로 조직에는 현재 절차의 효율성을 판단하기 위해 따르는 몇 가지 KPI가 있습니다. 몇 가지 다른 지표는 다음과 같습니다:

• 심각도 수준(예: 높음, 중간, 낮음)별로 구분된 CVE(공통 취약점 노출)에 취약한 것으로 확인된 애플리케이션의 수입니다.
• 운영 체제를 포함한 취약한 소프트웨어를 패치하는 데 걸리는 평균 시간
• 서비스별 가용성
• 호스트 또는 네트워크 부하 및 지연 시간

다른 지표에 영향을 미치는 KPI

어떤 경우에는 상충되는 KPI가 있어 상황을 판단하기 어렵게 만드는 경우도 있습니다. 일반적인 KPI는 악명 높은 '취약성 격차'로, 스캔을 통해 소프트웨어가 취약하거나 오래된 것으로 확인된 후 시스템을 패치하는 데 걸리는 시간입니다. 이 갭은 시스템이 패치가 적용되지 않은 채로 시간이 지날 때마다 증가합니다. 

패치 적용을 지연하는 조직은 이 지표가 규정 준수에 비해 너무 높다고 생각할 수 있습니다. 일반적으로 패치는 매월(또는 매주) 특정 날짜로 예정되어 있습니다. 문제는 이제 취약점이 공개적으로 알려져 있고 일부는 익스플로잇 코드와 함께 발표된다는 것입니다. 소프트웨어 업데이트가 지연되면 서버는 취약한 상태로 남아 익스플로잇에 노출됩니다. 2019년에 발생한 데이터 유출 패치를 사용할 수 있는 취약점으로 인해 발생했습니다. 

하나의 KPI 지표가 다른 지표에 영향을 미쳐 여러 목표에 차질을 빚을 수 있습니다. 예를 들어, 취약성 격차와 패치 적용으로 인해 서버를 재부팅해야 하는 경우 가동 시간에 영향을 미칠 수 있습니다. 매일 새로운 CVE가 발표되고 패치가 배포되기 때문에 조직이 이를 따라잡고 재부팅을 피하는 것이 어려워질 수 있으며, 이로 인해 다운타임이 발생하여 SLA에 영향을 미칠 수 있습니다. 예를 들어 30일 이내에 시스템을 패치해야 하고 예정된 패치 세션마다 재부팅이 필요한 경우 가동 시간 비율이 낮아집니다.

규정 준수를 위한 도구

규정 준수를 충족하고 SLA 요건을 준수하기 위한 좋은 전략은 자동화를 사용하는 것입니다. 자동화를 통해 많은 문제를 심각한 침해나 규정 위반으로 발전하기 전에 감지할 수 있습니다. 또한 패치와 같은 일부 문제를 해결하는 데에도 사용할 수 있습니다. 패치 관리 자동화 도구는 시중에 나와 있는 많은 취약성 스캔 도구와 잘 통합되므로 함께 사용하여 취약성 격차를 개선할 수 있습니다.

취약점을 수동으로 패치하는 경우 관리자에게는 부담이 될 수 있습니다. 관리자는 보고서를 읽고, 올바른 소프트웨어 버전을 결정하고, 패치를 테스트한 다음 프로덕션 환경에 배포해야 합니다. 수백 대의 서버를 보유한 조직이라면 패치 관리를 전담하는 팀 전체가 필요할 것입니다. 자동화 도구를 사용할 수 있는 경우 이러한 시스템은 조직의 리소스 낭비가 될 수 있습니다. 자동화 도구를 사용하면 수동으로 패치를 적용하는 대신 시간과 리소스를 절약할 수 있습니다.

다음은 KernelCare가 SOC 2 규정을 준수하고 모든 서버의 보안을 개선하기 위해 사용하는 몇 가지 도구입니다:

• 테너블 네서스: Nessus는 시중에서 가장 인기 있는 취약점 스캐너 중 하나입니다. 네트워크를 스캔하고 패치되지 않은 소프트웨어를 포함한 취약점을 찾습니다.
• Ivanti: Ivanti는 에셋을 발견하고 패치 자동화를 관리합니다. 
• KernelCare: 자체 제품을 사용하여 타사 라이브러리 및 Linux Kernel을 포함한 소프트웨어 패치를 유지합니다. KernelCare는 소프트웨어를 자동으로 패치할 뿐만 아니라 재부팅이 필요 없는 솔루션으로, 패치 후 서버를 재부팅할 필요가 없습니다. 이 서비스는 재부팅 다운타임으로 인한 가동률 손실 없이 가동 시간 지표를 최대한 높게 유지합니다.

결론

규정을 준수하려면 서버를 최신 취약성 패치로 업데이트해야 하지만, 가동 시간 SLA를 유지하는 것도 중요합니다. 이러한 충돌로 인해 조직은 올바른 도구를 찾고 모든 요구 사항을 충족하는 절차를 개발하기가 어려울 수 있습니다. 재부팅 없는 패치를 포함한 자동화를 통해 조직은 높은 가동 시간을 유지하면서 취약한 시스템을 30일 이내에 패치할 수 있습니다. 결과적으로 이러한 도구를 사용하면 감사를 받은 후 SOC 2 규정 준수에 훨씬 더 가까워질 수 있습니다.