Lite Threat Modeling을 사용한 패스트트랙 보안 개발

Lite Threat Modeling을 사용한 패스트트랙 보안 개발

라이트 위협 모델링 PlatoBlockchain 데이터 인텔리전스를 사용한 신속한 보안 개발. 수직 검색. 일체 포함.

바쁜 소프트웨어 회사에서는 항상 새로운 개발이 이루어집니다. 그러나 보안 개발도 진행되고 있습니까?

LTM(Lite Threat Modeling)이라는 프로세스는 보안 개발에 이해 관계자를 참여시켜 보안이 고정되지 않고 구워지도록 합니다. LTM이란 무엇이며 기존의 위협 모델링과 어떻게 다릅니까?

라이트 위협 모델링 접근법

LTM은 시스템 또는 애플리케이션의 잠재적인 보안 위협 및 취약성을 식별, 평가 및 완화하기 위한 능률적인 접근 방식입니다. 의 단순화된 버전입니다. 전통적인 위협 모델링, 일반적으로 보안 위험에 대한 보다 포괄적이고 상세한 분석이 포함됩니다.

LTM을 사용하면 펜 테스트에서와 같이 시스템이나 앱이 손상되었는지 확인하기 위해 수동으로 핀을 시스템이나 앱에 고정하지 않습니다. 오히려 애플리케이션에 "이론적인 허점"을 뚫어 가능한 공격 경로와 취약점을 찾아냅니다.

다음은 고려해야 할 몇 가지 질문입니다.

  • 누가 우리 시스템을 공격하고 싶어할까요?
  • 시스템의 어떤 구성 요소를 공격할 수 있으며 어떻게 공격할 수 있습니까?
  • 누군가가 침입하면 일어날 수 있는 최악의 상황은 무엇입니까?
  • 이것이 우리 회사에 어떤 부정적인 영향을 미칠까요? 고객에게?

LTM은 언제 수행됩니까? 

새 기능이 출시되거나 보안 제어가 변경되거나 기존 시스템 아키텍처 또는 인프라가 변경될 때마다 LTM을 수행하는 것이 가장 좋습니다.

이상적으로는 LTM이 수행됩니다. 시간 내에 디자인 단계와 전에 구현. 결국 프로덕션 환경에 출시되기 전에 취약점을 수정하는 것이 훨씬 더 쉽습니다. 조직 전체에서 LTM을 확장하려면 명확하고 일관된 프로세스와 표준을 설정해야 합니다. 여기에는 위협 범주의 공통 세트 정의, 위협 및 취약성의 공통 소스 식별, 위험 평가 및 완화를 위한 표준 절차 개발이 포함될 수 있습니다.

조직에서 LTM을 수행하는 방법 

조직 내에서 LTM 수행을 시작하려면 먼저 내부 보안 팀이 LTM 대화를 주도하도록 합니다. 엔지니어링 팀이 프로세스에 더 익숙해지면 자체 위협 모델 수행을 시작할 수 있습니다.

조직 전체에서 LTM을 확장하려면 명확하고 일관된 프로세스와 표준을 설정해야 합니다. 여기에는 위협 범주의 공통 세트 정의, 위협 및 취약성의 공통 소스 식별, 위험 평가 및 완화를 위한 표준 절차 개발이 포함될 수 있습니다.

피해야 할 일반적인 LTM 실수

보안 담당자는 위협 모델링에 능숙합니다. 그들은 종종 최악의 경우를 예상하고 엣지 케이스를 생각할 만큼 충분히 상상력이 풍부합니다. 그러나 이러한 자질은 또한 다음과 같은 LTM 함정에 빠지게 합니다.

  • 이상값에 너무 집중합니다. 이것은 대화의 초점이 이상값에 대한 가장 현실적인 위협에서 멀어질 때 LTM 연습 중에 발생합니다. 이를 해결하려면 생태계를 철저히 이해해야 합니다. SIEM(보안 정보 및 이벤트 관리) 및 기타 보안 모니터링 시스템의 정보를 사용합니다. 예를 들어 애플리케이션 프로그래밍 인터페이스(API) 엔드포인트를 공격하는 공격이 10,000건이라면 적이 공격에 집중하고 있다는 것을 알 수 있습니다. LTM도 여기에 집중해야 합니다.
  • 너무 기술적입니다. 종종 이론적 취약성이 발견되면 기술 인력은 "문제 해결 모드"로 뛰어듭니다. 그들은 취약점이 조직에 미치는 영향에 대해 이야기하는 대신 문제를 "해결"하고 기술 구현에 대해 이야기합니다. LTM 연습 중에 이런 일이 발생하면 대화를 되돌리십시오. 아직 구현에 대해 이야기하지 않을 것이라고 팀에 알리십시오. 통해 이야기 위험과 영향 먼저.
  • 도구만으로 위험을 처리한다고 가정합니다. 종종 개발자는 도구가 모든 문제를 찾을 것으로 기대합니다. 결국 현실은 위협 모델이 특정 취약성을 찾기 위한 것이 아니라는 것입니다. 오히려 아키텍처 수준에서 시스템의 전반적인 위험을 살펴보는 것을 의미합니다. 사실 안전하지 않은 디자인은 OWASP의 가장 최근의 디자인 중 하나였습니다. 상위 10가지 웹 애플리케이션 보안 위험. 아키텍처 보안 문제는 해결하기 가장 어렵기 때문에 아키텍처 수준에서 위협 모델이 필요합니다.
  • 잠재적인 위협과 취약점을 간과합니다. 위협 모델링은 일회성 연습이 아닙니다. 끊임없이 변화하는 공격 벡터와 위협 행위자보다 앞서 나가기 위해서는 잠재적인 위협과 취약성을 정기적으로 재평가하는 것이 중요합니다.
  • 높은 수준의 구현 전략을 검토하지 않습니다. 잠재적인 위협과 취약성이 식별되면 이를 완화하거나 제거하기 위한 효과적인 대책을 구현하는 것이 중요합니다. 여기에는 입력 유효성 검사, 액세스 제어 또는 암호화와 같은 기술적 제어와 직원 교육 또는 관리 정책과 같은 비기술적 제어 구현이 포함될 수 있습니다.

결론

LTM은 잠재적인 보안 위협 및 취약성을 식별, 평가 및 완화하기 위한 능률적인 접근 방식입니다. 개발자에게 매우 친숙하며 안전한 코드 이동이 가능합니다. 조기에 위협 모델링 수행 소프트웨어 개발 수명 주기(SDLC)에서 더 좋은 점은 위협 모델링을 실행하기 위해 실험실에 의존하는 것과는 반대로 LTM은 소프트웨어 개발자와 설계자가 직접 수행할 수 있다는 것입니다.

일관되고 효과적인 방식으로 LTM을 개발하고 구현함으로써 조직은 가장 중요한 보안 위험을 신속하고 효과적으로 식별하고 해결하는 동시에 일반적인 함정과 실수를 피할 수 있습니다.

타임 스탬프 :

더보기 어두운 독서