Keep the design as simple and small as possible.
Base access decisions on permission rather than exclusion.
Every access to every object must be checked for authority (there and then).
The design (and the code) should not be considered secret. The secret is always data, like a password or a cryptographic key.
It’s always safer if it takes two parties to agree on a decision than if one can do it alone.
Operate with the minimal set of powers needed to get the job done.
Minimize subsystems shared between or relied upon by mutually distrusting users ( 상호 신뢰하지 않는 사용자들 사이에서 ).
Design security systems for ease of use for humans.
Individual processes or tasks running in their own space.
The ability to only use a resource as it was designed to be used.
The breaking down of larger tasks into smaller, more manageable tasks.
Having multiple forms of security. This can be from hardware or software, but it involves a series of checks and balances to make sure the entire system is secured from multiple perspectives
Security mechanisms should not make the resource more difficult to access than when security mechanisms were not present
사내 네트워크, WAN 혹은 인터넷 전반에 걸친 취약점에 대한 것.
네트워크 프로토콜 취약점, 서비스 접근 방해 공격, 통신 링크 방해 등이 이루어질 수 있다.
어플리케이션, 기자재 혹은 운영체제 코드의 취약점에 대한 것.
특히 웹 서버 소프트웨어에 집중된다.
개인, 외부인, 휴먼 에러, 관계자 등 사람으로 부터 생기는 취약점에 대한 것.

보안 취약점을 악용하는 잠재적 기술 집합을 표현하는 데이터 구조체

Formal statement of rules and practices that specify or regulate how a system or organization provides security services to protect sensitive and critical system resources
어떻게 시스템이나 조직이 민감하고 중요한 시스템 자원을 보호하기 위해 보안 서비스를 제공하는가에 대한 구체적이고 보편적으로 쓰여진 규칙에 대한 공적인 문서
The degree of confidence one has that the security measures, both technical and operational, work as intended to protect the system and the information it processes
기술적, 운영적 보안 조치가 시스템과 시스템이 처리하는 정보를 보호하기 위해 의도한 대로 작동한다는 확신의 정도
각각의 특정 기준으로 제품이나 시스템에 대한 평가를 진행하는 것.