충격을 받은 구름?

2014년 24월에는 대부분의 UNIX 기반 시스템 구성 요소인 "Bash"의 일련의 취약점 형태로 보안 커뮤니티를 강타한 또 다른 폭탄 "Shellshock"이 있었습니다. 그것은 큰 피해를 입힐 가능성이 있으며 커뮤니티는 영향을 받은 모든 시스템을 고치려고 열광했습니다. 이미 수백만 건의 공격 시도가 인터넷의 거의 모든 시스템에 던져졌으며 일부 공격자는 이를 자가 복제 "웜"으로 바꾸려고 시도했습니다. 안전한 것으로 간주되려면 공급업체의 네트워크가 다중 계층 방화벽 및 침입 탐지 시스템으로 보호되어야 합니다. 이러한 네트워크는 7x365xXNUMX 보안 운영 센터(SOC)에서 모니터링해야 합니다. 지속되는 유일한 보안 접근 방식은 LiveOps가 뒤따르는 전략과 유사한 "심층 보안(SECURITY IN DEPTH)" 전략이며, 다중 중첩 및 중복 보호 계층이 있습니다.

LiveOps에서는 보안에 대한 전체적인 접근 방식을 사용합니다. 프로젝트가 구상되고 드로잉 보드에 배치되는 순간부터 개발 및 테스트 단계를 통해 배포 후까지 애플리케이션 보안 팀이 각 단계를 검토합니다. 보안은 공급업체가 소프트웨어 개발 수명 주기의 모든 단계에서 플랫폼을 설계하고 구축하는 방법의 필수적인 부분이어야 합니다. 또한 보안 시스템은 솔루션이 산업 표준 보안 요구 사항을 준수하거나 능가한다는 것을 입증하기 위해 철저한 테스트를 거쳐야 합니다. 클라우드 기반 시스템은 고객 데이터의 보안 및 무결성을 보장하고 보안 위협 또는 데이터 위반으로부터 보호하며 고객 데이터에 대한 무단 액세스를 방지하기 위해 XNUMX시간 모니터링이 필요합니다.

시스템이 당사의 보안 데이터 센터에 배치되는 즉시 모니터링 및 감사, 패치 및 분석이 이루어집니다. 데이터는 몇 년 후 데이터가 저장된 하드 드라이브가 재활용 센터의 산업용 파쇄기에서 최종 안식처를 만나는 마지막 순간까지 바로 보호됩니다.

취약점이 노출될 때마다 Shellshock(또는 매달 발견되는 눈에 잘 띄지 않는 수십 개의 취약점)과 같이 LiveOps 팀은 영향을 검토하고 수정 계획을 결정한 다음 적절한 팀과 함께 이를 구현합니다.

Shellshock의 경우 우리의 접근 방식은 다음 XNUMX단계로 구성되었습니다.

  1. 여러 공급업체의 자동 스캔과 수동 테스트를 사용하여 모든 공개 취약성 사례를 검색합니다. (아무것도 발견되지 않았습니다.)
  2. 웹 애플리케이션 방화벽 규칙을 업데이트하고 Security Operation Center 팀에 알립니다.
  3. 공격 시도에 대한 IDS 로그를 검토하십시오. (다양한 시도가 있었지만 성공하지 못했습니다.)
  4. 다양한 반복을 통해 적절한 패치를 전면적으로 롤아웃합니다.
  5. 개념 증명 코드를 테스트하여 모든 시스템에서 패칭의 성공 여부를 확인하십시오.
  6. 내부 취약성 스캔을 실행하여 누락된 상자가 없는지 확인하십시오.
  7. "bash" 사용을 위한 모든 프로덕션 소스 코드의 "화이트 박스" 검토를 실행합니다.

이러한 작업 중 일부는 병렬로 실행되었고 전체 팀의 노력이 필요했지만 보안 노출 없이 생산 프로세스에 영향을 주지 않고 이 문제를 신속하게 해결했습니다.

클라우드 시스템의 사용자로서 무엇을 할 수 있습니까?

보안에 대한 일반적인 모범 사례(항상 기꺼이 고객에게 조언함) 외에 해야 할 유일한 일은 경계를 유지하고 클라우드 공급자를 적절하게 검토하는 것입니다.

이와 같은 사고는 앞으로도 반복될 것입니다. 준비된 파트너를 선택하십시오.

FreeDigitalPhotos.net에서 Stuart Miles의 이미지 제공.