취약성(컴퓨팅)

Vulnerability (computing)
시리즈의 일부
정보 보안
vectorial version
관련 보안 카테고리
위협
방어.
시리즈의 일부
컴퓨터 해킹
역사
해커의 문화와 윤리
회의
컴퓨터 범죄
해킹 도구
연습 사이트
말웨어
컴퓨터 보안
무리
출판물

취약성은 장치/시스템의 전반적인 보안을 약화시키는 컴퓨터 시스템의 결함입니다.취약성은 하드웨어 자체 또는 하드웨어에서 실행되는 소프트웨어의 약점일 수 있습니다.취약성은 공격자와 같은 위협 행위자에 의해 악용되어 컴퓨터 시스템 내에서 권한 경계를 넘어(즉, 승인되지 않은 작업을 수행)될 수 있습니다.취약성을 부정 이용하려면 공격자는 시스템 취약점에 연결할 수 있는 하나 이상의 도구 또는 기술을 가지고 있어야 합니다.이 프레임에서 취약성은 공격 표면이라고도 합니다.

취약성 관리는 이론적으로는 다르지만 모든 자산의 검출, 자산의 우선순위 부여, 완전한 취약성 검사 평가 또는 실행, 결과 보고서 작성, 취약성 수정, 복구 확인 등 일반적인 프로세스를 포함하고 있습니다.이 프랙티스는 일반적으로 컴퓨팅 [1]시스템의 소프트웨어 취약성을 나타냅니다.신속한 취약성 관리란 모든 취약성을 가능한 [2]한 신속하게 식별하여 공격을 방지하는 것을 말합니다.

보안 위험은 종종 취약성으로 잘못 분류됩니다.동일한 위험의 의미로 취약성을 사용하면 혼란이 발생할 수 있습니다.취약성의 부정 이용으로 인해 중대한 영향이 발생할 가능성이 있습니다.그리고 리스크가 없는 취약성이 있습니다.예를 들어 영향을 받는 자산이 가치가 없는 경우 등입니다.동작 중인 공격 및 완전히 구현된 공격의 알려진 인스턴스가 하나 이상 있는 취약성은 악용 가능한 취약성으로 분류됩니다.취약성의 창은 전개된 소프트웨어에 보안 취약점이 도입 또는 나타난 시점부터 액세스가 삭제되거나 보안 수정이 사용 가능/전개되거나 공격자가 비활성화될 때까지의 시간입니다(제로 데이 공격 참조).

보안 버그(보안 결함)는 보다 좁은 개념입니다.소프트웨어에는 관련이 없는 취약성이 있습니다.하드웨어, 사이트, 직원의 취약성은 소프트웨어 보안 버그가 아닌 취약성의 예입니다.

제대로 사용하기 어려운 프로그래밍 언어로 구성되면 다수의 취약성이 나타날 수 있습니다.

정의들

ISO 27005는 취약성을 다음과 [3]같이 정의합니다.

하나 이상의 위협에 의해 악용될 수 있는 자산 또는 자산 그룹의 약점. 자산은 조직의 임무를[4] 지원하는 정보 리소스를 포함하여 조직, 비즈니스 운영 및 그 연속성에 가치가 있는 모든 것을 말합니다.

IETF RFC 4949의 [5]취약성은 다음과 같습니다.

시스템의 보안 정책을 위반하는 데 악용될 수 있는 시스템 설계, 구현 또는 운영 및 관리의 결함 또는 약점

미국 국가보안시스템위원회는 2010년 4월 26일자 [6]CNSS 지침 No. 4009의 취약성을 정의했다.

취약성: 정보 시스템, 시스템보안 절차, 내부 제어 또는 구현의 취약성으로 위협원에 의해 악용될 수 있습니다.

많은 NIST 출판물에서는 다양한 출판물에 있는 IT 컨텍스트의 취약성을 정의하고 있습니다.FISMApedia[7] 용어는[8] 목록을 제공합니다.SP 800-30 [9]중 하나를 더 크게 설명하십시오.

시스템 보안 절차, 설계, 구현 또는 내부 제어의 결함 또는 약점으로, 보안 위반 또는 시스템 보안 정책 위반이 발생할 수 있습니다.

ENISA는 의 취약성을[10] 다음과 같이 정의합니다.

관련된 컴퓨터 시스템, 네트워크, 응용 프로그램 또는 프로토콜의 보안을 손상시키는 예기치 않은 바람직하지 않은 이벤트를 초래할 수 있는 약점, 설계 또는 구현 오류의 존재.(ITSEC)

Open Group은 의 취약성을[11] 다음과 같이 정의합니다.

위협 능력이 위협에 저항할 수 있는 능력을 초과할 가능성.

FAIR(Factor Analysis of Information Risk)는 취약성을 다음과 [12]같이 정의합니다.

자산이 위협 에이전트의 조치를 거부할 수 없는 가능성

FAIR 취약성에 따르면 통제력, 즉 힘의 표준 측정과 비교한 통제력 강도 및 위협 능력, 즉 위협 에이전트가 자산에 적용할 수 있는 가능한 힘의 수준과 관련이 있다.

ISACA는 Risk It 프레임워크의 취약성을 다음과 같이 정의합니다.

설계, 구현, 운용 또는 내부 통제의 약점

데이터 및 컴퓨터 보안:표준 개념과 용어 사전, 저자인 Dennis Longley와 Michael Shain, Stockton Press, ISBN0-935859-17-9는 취약성을 다음과 같이 정의합니다.

1) 컴퓨터 보안에서는 정보에 대한 부정 액세스 또는 중요한 처리를 방해할 우려가 있는 자동 시스템 보안 절차, 관리 제어, 인터넷 제어 등의 취약점. 2) 컴퓨터 보안에서는 물리적 배치, 조직, 절차, 인사, 관리 등의 취약점.ADP 시스템 또는 액티비티에 해를 입히기 위해 악용될 수 있는 관리, 하드웨어 또는 소프트웨어.3) 컴퓨터 보안에 있어서 시스템에 존재하는 약점 또는 결함.공격 또는 유해 이벤트 또는 위협 에이전트가 해당 공격을 실행할 수 있는 기회.

Matt Bishop과 Dave[13] Bailey는 컴퓨터의 취약성에 대해 다음과 같이 정의하고 있습니다.

컴퓨터 시스템은 컴퓨터 시스템을 구성하는 엔티티의 현재 구성을 기술하는 상태로 구성된다.시스템은 시스템 상태를 변경하는 상태 천이를 적용하여 계산합니다.일련의 스테이트 천이를 사용해 소정의 초기 스테이트로부터 도달 가능한 모든 스테이트는, 시큐러티 정책에 의해서 정의되고 있는 허가 또는 무허가 클래스로 분류됩니다.이 문서에서는 이러한 등급과 전환의 정의를 자명한 것으로 간주합니다.Vulnerable 상태는 허가된 상태 천이를 사용하여 허가되지 않은 상태에 도달할 수 있는 허가된 상태입니다.손상된 상태는 도달한 상태입니다.공격은 일련의 인가 스테이트 천이를 의미하며, 이 천이에서는 타협 스테이트가 됩니다.정의상 공격은 취약한 상태에서 시작됩니다.취약성은 취약하지 않은 모든 상태와 구별되는 취약 상태의 특성화입니다.일반적인 경우 취약성은 많은 취약한 상태를 특성화할 수 있습니다.특정인 경우 하나의 상태만 특성화할 수 있습니다.

National Information Assurance Training and Education Center는 [14][15]취약성을 다음과 같이 정의합니다.

자동 시스템 보안 절차, 관리 제어, 내부 제어 등의 취약점. 정보에 대한 부정 액세스 또는 중요한 처리를 방해할 수 있는 위협에 의해 악용될 수 있습니다. 2. 시스템 보안 절차, 하드웨어 설계, 내부 제어 등의 취약점. 시스템 보안 절차, 하드웨어 설계, 내부 제어 등의 취약점을 악용하여 자동화를 도모할 수 있습니다.기밀정보 또는 기밀정보에 대한 접근. 3. ADP 시스템 또는 활동에 위해를 가하기 위해 악용될 수 있는 물리적 레이아웃, 조직, 절차, 인력, 관리, 관리, 하드웨어 또는 소프트웨어의 취약점.취약성의 존재 자체가 해를 입히는 것은 아닙니다.취약성은 ADP 시스템 또는 액티비티가 공격에 의해 피해를 입을 수 있는 조건 또는 조건의 집합일 뿐입니다.4 .주로 내부 환경(자산)의 엔티티에 관한 어설션입니다.자산(또는 자산 클래스)은 취약하다고 합니다(어떤 면에서 에이전트 또는 에이전트 컬렉션을 포함할 수 있습니다).V(i,e)는 여기서 e는 빈 집합일 수 있습니다.5 .다양한 위협에 대한 민감성.(6) 특정 내부실체의 재산 집합과 특정 외부실체의 재산 집합이 위험을 내포하는 것.7부자연스러운(인공에 의한) 적대적인 환경에서 일정 수준의 영향을 받은 결과, 명확한 열화(지정된 임무를 수행할 수 없는)를 일으키는 시스템의 특성.

취약성 및 리스크 요인 모델

리소스(물리적 또는 논리적)에는 위협 행위자에 의해 악용될 수 있는 취약성이 하나 이상 있을 수 있습니다.그 결과, 조직이나 그 외의 관계자(고객, 써플라이어)에 속하는 자원의 기밀성, 무결성, 가용성이 저하될 가능성이 있습니다.이른바 CIA 3인방은 정보보안의 초석이다.

공격은 시스템리소스의 변경이나 동작에 영향을 미쳐 무결성이나 가용성을 손상시키려 할 때 활성화 될 수 있습니다.'패시브 공격'은 시스템에서 정보를 학습하거나 사용하려고 하지만 시스템 리소스에 영향을 주지 않고 기밀성을 [5]손상시킵니다.

OWASP: 위협 에이전트와 비즈니스에 미치는 영향 간의 관계

OWASP(그림 참조)는 같은 현상을 약간 다른 용어로 나타내고 있습니다.공격 벡터를 통한 위협 에이전트는 시스템의 취약점(취약성)을 악용하여 비즈니스 영향과 연결된 IT 리소스(자산)에 기술적 영향을 미칩니다.

전체적인 그림은 위험 [16]시나리오의 위험 요소를 나타낸다.

정보보안관리시스템

정보보안관리시스템(ISMS)에 관한 일련의 방침이 개발되어 리스크 관리원칙에 따라 특정 조직에 적용되는 규칙 및 규정에 따라 보안전략을 수립할 수 있는 대책을 수립하고 있습니다.이러한 대책은 보안 제어라고도 불리지만, 정보 전송에 적용할 경우 보안 [17]서비스라고 불립니다.

분류

취약성은 관련된 [3]자산 클래스에 따라 분류됩니다.

  • 하드웨어
    • 습기 또는 먼지에 대한 민감성
    • 보호되지 않은 스토리지에 대한 민감성
    • 기능 부전의 원인이 되는 연령에 따른 마모
    • 과열
  • 소프트웨어
    • 불충분한 테스트
    • 안전하지 않은 부호화
    • 감사 추적의 부족
    • 설계 결함
  • 네트워크
  • 인사
  • 물리 사이트
    • 자연재해(예를 들어 홍수, 지진)의 영향을 받기 쉬운 지역
    • 전원 차단
  • 조직의
    • 정기 감사의 결여
    • 연속성 계획의 결여
    • 안전성의 결여

원인들

  • 복잡성: 크고 복잡한 시스템은 결함 및 의도하지 않은 액세스 [18]포인트의 가능성을 높입니다.
  • 익숙함:일반적으로 잘 알려진 코드, 소프트웨어, 운영 체제 및/또는 하드웨어를 사용하면 공격자가 결함을 [19]악용할 수 있는 지식 및 도구를 가지고 있거나 찾을 가능성이 높아집니다.
  • 접속성:물리적 연결, 권한, 포트, 프로토콜 및 서비스와 액세스 가능한 시간이 늘어날수록 [12]취약성이 증가합니다.
  • 암호 관리 결함:컴퓨터 사용자는 무차별적인 [20]힘으로 발견될 수 있는 취약한 암호를 사용합니다.컴퓨터 사용자는 프로그램에서 액세스할 수 있는 컴퓨터에 암호를 저장합니다.사용자는 많은 프로그램과 웹사이트 [18]사이에서 비밀번호를 재사용합니다.
  • 운영 체제 설계의 근본적인 결함:운영체제 설계자는 최적의 정책을 사용자/프로그램 관리에 적용하도록 선택합니다.예를 들어 기본 허용과 같은 정책을 사용하는 운영 체제는 모든 프로그램과 모든 사용자에게 [18]전체 시스템에 대한 전체 액세스 권한을 부여합니다.이 운영 체제 결함을 통해 바이러스 및 멀웨어가 관리자 [21]대신 명령을 실행할 수 있습니다.
  • 인터넷 웹 사이트 참조:일부 인터넷 웹 사이트에는 컴퓨터 시스템에 자동으로 설치될 수 있는 유해한 스파이웨어 또는 애드웨어가 포함되어 있을 수 있습니다.이러한 웹사이트에 접속하면 컴퓨터 시스템이 감염되어 개인정보가 수집되어 [22]제3자에게 전달됩니다.
  • 소프트웨어 오류:프로그래머는 소프트웨어 프로그램에 악용 가능한 버그를 남깁니다.소프트웨어 버그로 인해 공격자가 [18]응용 프로그램을 잘못 사용할 수 있습니다.
  • 선택되지 않은 사용자 입력:프로그램은 모든 사용자 입력이 안전하다고 가정합니다.사용자 입력을 검사하지 않는 프로그램은 명령 또는 SQL 문(버퍼 오버플로, SQL 주입 또는 기타 검증되지 않은 입력)[18]을 의도하지 않게 직접 실행할 수 있습니다.
  • 과거의 [23][24]실수로부터 배울 수 없음: 예를 들어 IPv4 프로토콜 소프트웨어에서 발견된 대부분의 취약성은 새로운 IPv6 [25]구현에서 발견되었습니다.

이 조사에 따르면 대부분의 정보 시스템에서 가장 취약한 부분은 인간 사용자, 운영자, 설계자 또는 기타 [26]인간입니다. 따라서 인간은 자산, 위협, 정보 자원으로서의 다양한 역할로 간주되어야 합니다.사회 공학은 보안에 대한 우려가 커지고 있습니다.

결과들

보안 침해의 영향은 매우 [27]클 수 있습니다.대부분의 법률에서는 IT관리자가 IT시스템과 애플리케이션의 취약성을 부정행위로 알고 있는 경우 대처하지 못하는 것으로 간주하고 있습니다.IT관리자는 [28]IT리스크를 관리할 책임이 있습니다.프라이버시법은 관리자가 보안 리스크의 영향이나 가능성을 줄이기 위해 행동하도록 강제하고 있습니다.IT보안 감사는 다른 독립된 사람들이 IT환경이 적절하게 관리되고 있다는 것을 증명하고 최소한 성의를 다했다는 것을 증명하는 방법입니다.침투 테스트는 조직이 채택한 약점과 대응책을 검증하기 위한 것입니다.White hat 해커는 조직의 IT 자산을 공격하여 [29]IT 보안을 침해하는 것이 얼마나 쉬운지 또는 얼마나 어려운지를 조사하려고 합니다.IT리스크를 전문적으로 관리하는 적절한 방법은 고위 [17]경영진이 제시한 보안전략에 따라 ISO/IEC 27002나 Risk IT 등의 정보보안 관리시스템을 도입하여 이를 따르는 것입니다.

정보 보안의 핵심 개념 중 하나는 심층 방어 원칙, 즉 다음을 수행할 수 있는 [27]다층 방어 시스템을 구축하는 것이다.

  • 착취를 막다
  • 공격을 탐지하여 요격하다
  • 위협 요원을 찾아내어 기소하다

침입 탐지 시스템은 공격을 탐지하는 데 사용되는 시스템 클래스의 예입니다.

물리적 보안은 정보 자산을 물리적으로 보호하기 위한 일련의 수단입니다. 누군가가 정보 자산에 물리적으로 액세스할 수 있는 경우 공격자가 정보 자산에 대한 모든 정보에 액세스하거나 합법적인 사용자가 리소스를 사용할 수 없도록 하는 것이 널리 받아들여지고 있습니다.

적절한 보안 수준을 충족하기 위해 컴퓨터, 운영 체제 및 응용 프로그램이 충족해야 하는 몇 가지 기준이 개발되었습니다.ITSEC와 공통 기준은 두 가지 예입니다.

취약성 공개

취약성에 대한 공동 공시(일부에서는 '책임 있는 공시'라고 하지만 다른 이들은 편향된 용어로 간주)는 큰 논쟁의 주제이다.Tech Herald가 2010년 8월에 보도한 바와 같이, "Google, Microsoft, TipingPoint 및 Rapid7은 향후 [30]공개에 어떻게 대처할지 설명하는 가이드라인과 성명을 발표했습니다."다른 방법은 일반적으로 취약성의 모든 세부 정보가 공개될 때 소프트웨어 작성자에게 수정을 더 빨리 공개하도록 압력을 가할 목적으로 완전히 공개하는 것입니다.2014년 1월 구글이 마이크로소프트의 취약점을 드러낸 후 마이크로소프트가 이를 수정하기 위한 패치를 공개하자 마이크로소프트의 한 담당자가 [31]공개를 위해 소프트웨어 회사 간의 협력적인 관행을 요구했다.

취약성 인벤토리

Mitre Corporation은 Common Vulnerabilities and Exposure라는 시스템에서 공개적으로 공개된 취약성의 불완전한 목록을 유지합니다.이 정보는 National Institute of Standards and Technology(NIST)와 즉시 공유됩니다.NIST에서는 Common Vulnerability Scoring System(CVSS), Common Platform Enumeration(CPE) 방식 및 Common Vulnerability Enumeration을 사용하여 각 취약성에 위험 점수를 부여합니다.

클라우드 서비스 프로바이더는 CVE [32]시스템을 사용하는 서비스에 보안 문제를 나열하지 않는 경우가 많습니다.현재 클라우드 컴퓨팅 취약성 열거, 심각도 평가 및 통합 추적 [33]메커니즘에 대한 보편적인 표준이 없습니다.Open CVDB 이니셔티브는 CSP의 취약성을 카탈로그로 작성하는 커뮤니티 기반의 중앙 집중형 클라우드 취약성 데이터베이스로,[34] 사용자가 자신의 환경에서 이러한 문제를 탐지하거나 방지하기 위해 취할 수 있는 단계를 나열합니다.

OWASP는 시스템 설계자와 프로그래머를 교육하기 위해 취약성 클래스 목록을 유지하며,[35] 따라서 소프트웨어에 의도하지 않게 취약성이 기록될 가능성을 줄입니다.

취약성 공개일

취약성의 공개 시간은 보안 커뮤니티와 업계에서 다르게 정의됩니다.흔히 '특정 당사자에 의한 보안 정보의 공개'라고 합니다.일반적으로 취약성 정보는 메일링 리스트에서 논의되거나 보안 웹 사이트에 게시되며 나중에 보안 권고 사항이 발생합니다.

공개된 시각은 보안 취약성에 대한 공개된 정보가 다음 요건을 충족해야 하는 채널에서 보안 취약성에 대해 기술된 첫 번째 날짜입니다.

  • 그 정보는 일반에게 무료로 제공되고 있다.
  • 취약성 정보는 신뢰할 수 있는 독립된 채널/소스에 의해 공개됩니다.
  • 취약성은 공개 시 위험 등급 정보가 포함되도록 전문가의 분석을 거쳤다.
취약성 식별 및 제거

컴퓨터 시스템의 취약성을 검출(경우에 따라서는 제거)하는 데 도움이 되는 많은 소프트웨어 도구가 있습니다.이러한 툴은 감사자에게 발생할 수 있는 취약성에 대한 좋은 개요를 제공할 수 있지만 인간의 판단을 대체할 수는 없습니다.스캐너에만 의존하면 시스템에 존재하는 문제에 대한 잘못된 긍정과 제한된 범위의 뷰가 생성됩니다.

취약성은 Windows, macOS, 다양한 형태의 Unix 및 Linux, OpenVMS 등을 포함한 모든 주요 운영 체제에서 발견되었습니다.시스템에 대해 취약성이 이용될 가능성을 줄이는 유일한 방법은 신중한 시스템 유지보수(소프트웨어 패치 적용 등), 도입의 베스트 프랙티스(방화벽 및 접근통제 사용 등) 및 감사(개발 중 및 도입 라이프 사이클 전체)를 포함한 지속적인 경계에 의한 것입니다.

취약성이 드러나는 장소

취약성은 다음과 관련이 있으며 다음과 같은 경우에 나타날 수 있습니다.

  • 시스템의 물리적 환경
  • 직원(예: 직원, 경영진)
  • 관리 절차 및 보안 정책
  • 업무 운영 및 서비스 제공
  • 주변기기를 포함한 하드웨어
  • 소프트웨어(즉, 사내 또는 클라우드)
  • 접속성(통신기기 및 설비)

순수한 기술적 접근법이 항상 물리적 자산을 보호하는 것은 아닙니다. 유지관리 직원이 시설에 들어갈 수 있도록 하고 절차에 대해 충분한 지식을 갖춘 사람이 적절한 주의를 기울여 따를 수 있도록 하는 행정 절차를 갖추어야 합니다.단, 기술 보호가 반드시 사회공학(보안) 공격을 막는 것은 아닙니다.

취약성의 예:

  • 공격자는 버퍼 오버플로 취약점을 발견하여 사용하여 악성 프로그램을 설치하여 기밀 데이터를 유출합니다.
  • 공격자는 사용자가 악성코드가 첨부된 전자 메일 메시지를 열도록 설득합니다.
  • 홍수는 지하에 설치된 컴퓨터 시스템을 손상시킨다.

소프트웨어의 취약성

취약성을 유발하는 일반적인 소프트웨어 결함 유형은 다음과 같습니다.

코딩 가이드라인이 일부 개발되어 다수의 정적 코드 분석기를 사용하여 코드가 가이드라인을 준수하는지 검증하고 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Vulnerability Management Life Cycle NPCR CDC". www.cdc.gov. 2019-03-12. Retrieved 2020-07-04.
  2. ^ Ding, Aaron Yi; De Jesus, Gianluca Limon; Janssen, Marijn (2019). "Ethical hacking for boosting IoT vulnerability management: a first look into bug bounty programs and responsible disclosure". Proceedings of the Eighth International Conference on Telecommunications and Remote Sensing - ICTRS '19. Ictrs '19. Rhodes, Greece: ACM Press: 49–55. arXiv:1909.11166. doi:10.1145/3357767.3357774. ISBN 978-1-4503-7669-3. S2CID 202676146.
  3. ^ a b ISO/IEC, "정보기술 - 보안기술 - 정보보안 리스크 관리" ISO/IEC FIDIS 27005:2008
  4. ^ 영국표준협회, 정보기술 - 보안기술 - 정보통신기술 보안관리 - 제1부: 정보통신기술 보안관리 개념 및 모델 BS ISO/IEC 13335-1-2004
  5. ^ a b 인터넷 기술 특별 조사위원회 RFC 4949 인터넷 보안 용어집 버전 2
  6. ^ "CNSS Instruction No. 4009" (PDF). 26 April 2010. Archived from the original (PDF) on 2013-06-28.
  7. ^ "FISMApedia". fismapedia.org.
  8. ^ "Term:Vulnerability". fismapedia.org.
  9. ^ NIST SP 800-30 정보기술 시스템 리스크 관리 가이드
  10. ^ "Glossary". europa.eu.
  11. ^ Technical Standard Risk Taxonomy ISBN 1-931624-77-1 문서번호: C081, The Open Group, 2009년 1월
  12. ^ a b "정보 리스크 요인 분석 소개(FAIR)", 리스크 관리 Insight LLC, 2006년 11월, 웨이백 머신에서 2014-11-18년 아카이브됨
  13. ^ 매트 비숍과 데이브 베일리입니다취약성 분류의 중요 분석.기술 보고서 CSE-96-11, 데이비스 캘리포니아 대학 컴퓨터 과학부, 1996년 9월
  14. ^ 코리 슈(1996년).INFOSEC 용어집, 버전 2.0. CD-ROM (아이다호 주립 대학 및 정보 시스템 보안 기구)
  15. ^ NIATEC 용어집
  16. ^ ISACA THE RISK IT Framework (등록 필요)2010년 7월 5일 Wayback Machine에서 아카이브 완료
  17. ^ a b Wright, Joe; Harmening, Jim (2009). "15". In Vacca, John (ed.). Computer and Information Security Handbook. Morgan Kaufmann Publications. Elsevier Inc. p. 257. ISBN 978-0-12-374354-1.
  18. ^ a b c d e Kakareka, Almantas (2009). "23". In Vacca, John (ed.). Computer and Information Security Handbook. Morgan Kaufmann Publications. Elsevier Inc. p. 393. ISBN 978-0-12-374354-1.
  19. ^ Krsul, Ivan (April 15, 1997). "Technical Report CSD-TR-97-026". The COAST Laboratory Department of Computer Sciences, Purdue University. CiteSeerX 10.1.1.26.5435. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  20. ^ Pauli, Darren (16 January 2017). "Just give up: 123456 is still the world's most popular password". The Register. Retrieved 2017-01-17.
  21. ^ "The Six Dumbest Ideas in Computer Security". ranum.com.
  22. ^ "The Web Application Security Consortium / Web Application Security Statistics". webappsec.org.
  23. ^ 로스 앤더슨입니다암호 시스템이 실패하는 이유Cam-bridge, University Computer Laboratory, 기술 보고서, 1994년 1월
  24. ^ 닐 슐라거.기술이 실패했을 때: 20세기의 중대한 기술 재해, 사고 및 실패.게일 리서치사, 1994년
  25. ^ 해킹:착취의 기술 제2판
  26. ^ Kiountouzis, E. A.; Kokolakis, S. A. (31 May 1996). Information systems security: facing the information society of the 21st century. London: Chapman & Hall, Ltd. ISBN 0-412-78120-4.
  27. ^ a b Rasmussen, Jeremy (February 12, 2018). "Best Practices for Cybersecurity: Stay Cyber SMART". Tech Decisions. Retrieved September 18, 2020.
  28. ^ "What is a vulnerability? - Knowledgebase - ICTEA". www.ictea.com. Retrieved 2021-04-03.
  29. ^ Bavisi, Sanjay (2009). "22". In Vacca, John (ed.). Computer and Information Security Handbook. Morgan Kaufmann Publications. Elsevier Inc. p. 375. ISBN 978-0-12-374354-1.
  30. ^ "The new era of vulnerability disclosure - a brief chat with HD Moore". The Tech Herald. Archived from the original on 2010-08-26. Retrieved 2010-08-24.
  31. ^ Betz, Chris (11 Jan 2015). "A Call for Better Coordinated Vulnerability Disclosure - MSRC - Site Home - TechNet Blogs". blogs.technet.com. Retrieved 12 January 2015.
  32. ^ "Wiz launches open database to track cloud vulnerabilities". SearchSecurity. Retrieved 2022-07-20.
  33. ^ Barth, Bradley (2022-06-08). "Centralized database will help standardize bug disclosure for the cloud". www.scmagazine.com. Retrieved 2022-07-20.
  34. ^ Writer, Jai VijayanContributing; ReadingJune 28, Dark; 2022 (2022-06-28). "New Vulnerability Database Catalogs Cloud Security Issues". Dark Reading. Retrieved 2022-07-20.{{cite web}}: CS1 maint: 숫자 이름: 작성자 목록(링크)
  35. ^ "Category:Vulnerability". owasp.org.
  36. ^ David Harley (10 March 2015). "Operating System Vulnerabilities, Exploits and Insecurity". Retrieved 15 January 2019.
  37. ^ 대부분의 노트북은 주변기기를 통한 공격에 취약합니다.http://www.sciencedaily.com/releases/2019/02/190225192119.htm 출처:케임브리지 대학교]
  38. ^ 네트워크 프린터를 부정 이용하는 중입니다.Ruhr University Bochum IT 보안 연구소
  39. ^ [1] 2007년 10월 21일 Wayback Machine에서 아카이브 완료
  40. ^ "Jesse Ruderman » Race conditions in security dialogs". squarefree.com.
  41. ^ "lcamtuf's blog". lcamtuf.blogspot.com. 16 August 2010.
  42. ^ "Warning Fatigue". freedom-to-tinker.com.

외부 링크

  • Wikimedia Commons의 취약성(컴퓨팅)과 관련된 미디어
  • Open Directory http://dmoz-odp.org/Computers/Security/Advisories_and_Patches/ 보안 어드바이저리 링크