오용 사례

Misuse case
시리즈의 일부
정보 보안
vectorial version
관련 보안 카테고리
위협
방어.
보안 요건을 파악하는 데 사용할 수 있는 오용 사례 원칙의 예.

오용 사례는 소프트웨어 개발 업계에서 사용되는 비즈니스 프로세스 모델링 도구입니다.오용 사례 또는 오용 사례라는 용어는 사용 [1]사례의 반대인 에서 파생되었습니다.이 용어는 1990년대에 노르웨이 과학기술 대학의 구토름 신드레와 노르웨이 베르겐 대학의 안드레아스 L. 오달에 의해 처음 사용되었다.이 문서에서는 시스템에 대해 악의적인 행위를 실행하는 프로세스를 설명하며,[2] 사용 사례를 사용하여 시스템에 의해 수행된 모든 작업을 설명할 수 있습니다.

개요

사용 사례는 개발 중인 소프트웨어 및 기타 제품의 필수 동작을 규정하며, 기본적으로 소프트웨어의 정상적인 동작과 사용을 상세히 설명하는 구조화된 스토리 또는 시나리오입니다.한편, 오용 사례에서는 발생해서는 안 되는 것(네거티브 시나리오 등)과 이에 의해 특정된 위협이 강조되어 새로운 요건을 정의하는 데 도움이 됩니다.이러한 위협은 새로운 사용 사례로 표현됩니다.

이 모델링 도구에는 다음과 같은 몇 가지 장점이 있습니다.

  • 다른 툴에서는 불가능할 수 있는 기능요건과 비기능요건(보안요건, 플랫폼요건 등)에 동일한 가중치를 제공할 수 있습니다.
  • 설계 프로세스 시작부터 보안을 강조하여 설계 결정을 성급하게 내리는 것을 방지합니다.
  • 이 툴은 개발자와 이해관계자 간의 커뮤니케이션을 개선하기 위한 툴로 중요한 시스템 솔루션과 트레이드오프 분석에 [3]대해 쌍방이 합의할 수 있도록 하는 데 중요합니다.
  • 오용 사례를 작성하면 기능적 요건과 비기능적 요건을 쉽게 식별할 수 있는 연쇄반응이 발생하는 경우가 많습니다.오용 사례가 발견되면 대응책으로 작용하는 새로운 사용 사례가 생성되는 경우가 많습니다.이것은 새로운 [4]오용 사례의 대상이 될 수 있습니다.
  • 다른 도구에 비해 사용 사례 및 UML과 더 잘 관련되고 모델의 원활한 채용이 용이합니다.

그것의 가장 큰 약점은 단순함이다.프로젝트 실행을 위한 적절한 계획을 수립하려면 보다 강력한 도구와 결합해야 합니다.또 다른 약점은 구조와 의미론의 부족이다.

사용에서 오용 사례까지

산업계에서 봤을 때 외부에서 유래한 요청에 응답하는 시스템의 동작을 설명하기 위해:시각적 모델링 기법처럼 그 형상에[5]요구 사항[1]의 엔지니어들 사이에 인기가 활용 사례 덕분에 중요하다, 그들은 배우의 관점에서 시작해서 그것의 형식을 명시적으로 eac 시스템을 묘사한다.h악토r의 목표와 [6]이를 달성하기 위해 시스템이 구현해야 하는 흐름.

UML 사용 사례 다이어그램과 최종 사용자 또는 도메인 전문가의 언어를 사용하기 때문에 사용 사례 모델의 추상화 수준은 설계 활동을 위한 적절한 출발점이 됩니다.그러나 소프트웨어 보안 분석을 위해 개발자는 부정적인 시나리오에 주목하고 이해해야 합니다.그래서 1990년대 노르웨이에서 '사용 사례의 역'이라는 개념이 생겨났다.

오용 사례와 사용 사례의 대조를 이루는 것이 목표입니다. 오용 사례는 시스템의 이해 관계자가 허용할 수 없다고 간주하거나 Guttorm Sindre와 Andreas L. Opdahl이 말한 것처럼 "시스템이 [1]허용해서는 안 되는 기능"을 나타냅니다.이 차이는 시나리오에도 있습니다.'긍정적' 시나리오는 개인 또는 조직이 원하는 목표에 도달하는 일련의 액션입니다.'부정적' 시나리오는 해당 조직에 의해 발생하지 않기를 바라거나 적대적인 에이전트(반드시 [7]인간일 필요는 없습니다)에 의해 바람직한 목표입니다.

그 차이에 대한 또 다른 설명은 사용 사례를 사용자에게 더 큰 가치를 주는 완료된 일련의 작업으로 정의한다는 것입니다. 오용 사례를 조직 또는 특정 이해관계자에게 손실을 초래하는 완료된 일련의 작업으로 정의할 수 있습니다.

'좋은' 경우와 '나쁜' 경우 사이에서는 시나리오를 나타내는 언어가 일반적입니다.유스케이스 다이어그램은 OMG에 의해 정의된2개의 모델링 언어(UML)와 시스템 모델링 언어(SysML)에 정식으로 포함되어 있습니다.이러한 도면 에이전트 사용 및 시나리오 오용 사례에 대한 명확한 집중을 지원합니다.텐션.[9]

사용 지역

오용 사례는 [10]보안 분야에서 가장 일반적으로 사용됩니다.IT 시스템의 중요성이 계속 증가함에 따라 모든 기업이 데이터 [11]보호 기능을 개발하는 것이 매우 중요해졌습니다.

따라서 예를 들어 오용 사례를 사용하여 해커가 시스템에서 무엇을 할 것인지, 해커가 자신의 요건을 정의할 수 있습니다.개발자 또는 설계자는 동일한 UML 다이어그램에서 사용자와 해커의 요건을 정의할 수 있으며,[12] 이는 시스템의 보안 위험을 식별하는 데 도움이 됩니다.

기본 개념

오용 사례도를 대응하는 사용 사례도와 함께 작성한다.이 모델에는 2개의 새로운 중요한 엔티티가 도입되어 있습니다(기존 사용 사례 모델, 사용 사례 및 행위자의 엔티티 외에).

  • 오용 사례 : 시스템을 손상시키기 위해 개인 또는 엔티티가 수행할 수 있는 일련의 작업입니다.
  • [Misuser] : 오용 사례를 개시한 액터.이는 의도적이거나 부주의하게 수행될 수 있습니다.

도표

오용 사례 모델은 사용 사례 모델에서 발견된 관계 유형(포함, 확장, 일반화 및 연관성)을 활용합니다.또한 다이어그램에서 사용할 두 가지 새로운 관계를 소개합니다.

경감하다
유스케이스를 사용하면, 오용 케이스가 정상적으로 완료될 가능성을 경감할 수 있습니다.
위협하다
오용 사례는 예를 들어 이용 사례를 악용하여 위협하거나 목적 달성을 방해할 수 있습니다.

이러한 신개념과 기존 사용 사례의 신개념은 다음과 같은 메타 모델을 제공하며, Sindre 및 Opdah(2004)[2]에서도 볼 수 있다.

설명

오용 사례를 텍스트로 설명하는 방법에는 두 가지가 있습니다. 하나는 사용 사례 설명 템플릿에 포함되어 있습니다. 여기서 Threats라는 추가 설명 필드를 추가할 수 있습니다.오용 사례 단계(및 대체 단계)를 입력할 수 있는 필드입니다.이를 오용 사례를 설명하는 경량 모드라고 합니다.

오용 사례를 설명하는 다른 방법은 이 용도로만 별도의 템플릿을 사용하는 것입니다.사용 사례 설명(이름, 요약, 작성자 및 날짜)에서 일부 필드를 상속하는 것이 좋습니다.또한 Basic path 필드 및 Alternative path 필드도 조정하여 사용 사례 대신 오용 사례의 경로를 설명합니다.이 외에도 다음과 같은 몇 가지 필드를 사용할 것을 권장합니다.

  • 오용사례명
  • 요약
  • 작가.
  • 날짜.
  • 기본 경로
  • 대체 경로
  • 경감 포인트
  • 확장점
  • 트리거
  • 전제 조건
  • 전제 조건
  • 경감 보증
  • 관련 업무 규칙
  • 잠재적인 오사용자 프로파일
  • 이해관계자 및 위협
  • 용어 및 설명
  • 범위
  • 추상화 수준
  • 정밀도 수준

이해하시겠지만, 위의 목록은 매번 완전히 작성하기에는 너무 포괄적입니다.처음에 모든 필드를 입력해야 하는 것은 아니므로 살아있는 문서로 봐야 합니다.도표부터 시작할지, 아니면 묘사부터 시작할지에 대한 논쟁도 있었다.Sindre와 Opdahl이 이 문제에 대해 제시한 권장 사항은 사용 사례와 동일하게 수행되어야 한다는 것입니다.

Sindre와 Opdahl은 보안 요건을 식별하기 위해 오용 사례를 사용하기 위한 다음 5가지 단계를 제안합니다.

  1. 시스템 내의 중요한 자산을 특정하다
  2. 각 자산의 보안 목표 정의
  3. 시스템에 해를 끼칠 가능성이 있는 이해관계자를 특정함으로써 이들 보안 목표에 대한 위협을 특정한다.
  4. 리스크 평가 등의 기법을 사용하여 위협의 리스크를 특정하고 분석한다.
  5. 리스크에 대한 보안 요건을 정의합니다.

이 5단계 프로세스에서는 재사용 가능한 오용 사례 저장소를 지원으로 사용할 것을 권장합니다.

조사.

현재 연구 분야

오용 사례에 대한 현재의 연구는 주로 오용 사례가 프로젝트, 특히 소프트웨어 프로젝트에 가져올 수 있는 보안 개선에 초점이 맞춰져 있습니다.애플리케이션 개발의 초기 단계에서 케이스 개발의 오용 관행을 널리 도입하는 방법이 검토되고 있습니다.즉, 결함을 빨리 발견할수록 패치를 쉽게 찾을 수 있고 프로젝트의 최종 비용에 미치는 영향을 줄일 수 있습니다.

다른 연구는 최종 목표를 달성하기 위해 오남용 사례를 개선하는 데 초점을 맞추고 있다. "응용 프로세스가 부족하고 결과가 너무 일반적이며 개념의 정의 부족이나 잘못된 해석을 일으킬 수 있다."또, 「정보 시스템 시큐러티 리스크 관리(ISSRM)의 참조 모델에 비추어 오용 사례를 파악해, 시큐러티 리스크 관리 프로세스를 취득할 것」을 제안한다.

장래의 개선

오남용 사례는 연구자들 사이에서 잘 알려져 있다.이 주제에 대한 연구 주체가 지식을 입증하고 있지만 학계를 넘어서는 오남용 사례는 널리 채택되지 않고 있다.

Sindre와 Opdahl(남용 사례 개념의 부모)이 제안하듯이, "추가 작업의 또 다른 중요한 목표는 [2]오용 사례를 산업적으로 폭넓게 채택하는 것입니다.이들은 같은 기사에서 오용 사례를 활용 사례 모델링 도구에 포함시키고 소프트웨어 설계자를 지원하기 위해 표준 오용 사례의 "데이터베이스"를 만들 것을 제안합니다.시스템 이해관계자는 자신의 문제 영역에 고유한 요건에 대해 독자적인 오용 사례 차트를 작성해야 합니다.지식 데이터베이스가 개발되면 람다 해커들이 사용하는 표준 보안 결함의 양을 줄일 수 있습니다.

다른 연구는 오용 사례의 가능한 실종된 구체적인 해결책에:이 접근법은 높은 레벨에서 보안 요구 사항의 도출을 도울 수 있는[14]"을 썼다, 어떻게 합법적 행동과 구체적인 자산기 때문에 따라서 그것이 무엇 오용 사건으로 간주되어야 합니다,도 wh에 분명하지 않다 남용 사건과 연결하는 방법을 보여 주지 않는다 초점을 두었다.c에온텍스트」를 참조해 주세요.이러한 비판은 선행 섹션에 제시된 제안과 개선사항을 통해 다루어질 수 있다.

UML 표기법의 일부로 오용 사례를 표준화하면 프로젝트 개발의 필수 요소가 될 수 있습니다."[15]보안 기능 또는 취약성과 위협을 완화하기 위해 추가된 대책에 대한 특정 표기법을 작성하는 것이 유용할 수 있습니다."

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b c 신드레와 옵달(2001년)."오류 사례를 통한 보안 요건 파악"
  2. ^ a b c Sindre and Opdahl (2004년)."Wayback Machine에서 2011-07-16년 아카이브된 오용 사례로 보안 요건 충족"
  3. ^ 트레이드오프 분석에서의 오용 사례의 초기 산업 경험(2002년, Ian Alexander에 의해) 2008-04-30년 웨이백 머신에 아카이브됨
  4. ^ Ian Alexander, 오용 사례: 적대적인 의도를 가진 사용 사례.IEEE 소프트웨어, Vol 20, No 1, 2003년 1월~2월, 58-66.DOI: 10.1109/MS.2003.1159030
  5. ^ Jacobson, "오브젝트 지향 소프트웨어 엔지니어링: 사용 사례 중심 접근법", 1992년 보스턴, Addison-Wesley
  6. ^ Gunnar Peterson, John Steven, "개발 프로세스에서의 오용 정의", IEEE SECURITY & PRIVACY, 2006년 11월/12월
  7. ^ Ian Alexander "오용 사례: 악의적인 의도를 가진 사용 사례", 프레젠테이션
  8. ^ Guttorm Sindre, Andreas L. Opdahl, "오용 사례 설명 템플릿"
  9. ^ Ian Alexander "오용 사례: 악의적인 의도를 가진 사용 사례"
  10. ^ Asoke K. Talukder; Manish Chaitanya (17 December 2008). Architecting Secure Software Systems. CRC Press. p. 47. ISBN 978-1-4200-8784-0. Retrieved 5 October 2016.
  11. ^ Jesper M. Johansson; Steve Riley (27 May 2005). Protect Your Windows Network: From Perimeter To Data. Addison-Wesley Professional. p. 491. ISBN 978-0-321-33643-9. Retrieved 5 October 2016.
  12. ^ Asoke K. Talukder; Manish Chaitanya (17 December 2008). Architecting Secure Software Systems. CRC Press. p. 50. ISBN 978-1-4200-8784-0. Retrieved 5 October 2016.
  13. ^ Raimundas Matulevichius, Nicolas Mayer, Patrick Heymans, "오용 사례와 보안 리스크 관리 제휴"
  14. ^ 패브릭 A브레이즈, 에두아르도 BFernandez, Michael VanHills, "오용 활동을 통해 보안 요건 충족"
  15. ^ Lillian Röstad, "확장 오용 사례 표기법:취약성 및 내부자 위협 포함"