1. Chapter 17 Building Secure and Trusted Systems
An, Eunju
Database Lab.

2. Assurance and Trust Definition 17-1 Definition 17-2
An entity is trustworthy if there is sufficient credible evidence leading one to believe that the system will meet a set of given requirements. Trust is a measure of trustworthiness, relying on the evidence provided.
Security assurance, or simply assurance, is confidence that an entity meets its security requirements, based on specific evidence provided by the application of assurance techniques.

3. Assurance Techniques Informal Method Semiformal Method Formal Method
Use natural languages
Minimum of rigor
Semiformal Method
Apply a specific overall method that imposes some rigor
Formal Method
Use mathematics and other machine-parsable languages

4. Security assurance
Acquired by applying a variety of assurance techniques
Statement of requirements that explicitly defines the security expectations of the mechanism(s)
Provides justification that the mechanism meets policy through assurance evidence and approvals based on evidence
Executable entities that are designed and implemented to meet the requirements of the policy
Figure 17-1

5. Information assurance
Ability to access information and preserve the quality and security of that information
Difference
Information assurance : Focus is on the threats to information and the mechanisms used to protect information
Security assurance : Focus is on the correctness, consistency, or completeness of the requirements and implementation of those mechanisms
『 “assurance” means “security assurance” 』

6. Trusted System Definition 17-3
A trusted system is a system that has been show to meet well-defined requirements under an evaluation by a credible body of experts who are certified to assign trust ratings to evaluated products and systems.

7. The Need for Assurance
Applying assurance techniques is time-consuming and expensive
Accidental or unintentional failures of computer systems, as well as intentional compromises of security mechanisms

8. The Need for Assurance
Neumann describes nine types of problem sources in computer systems.
Requirements definitions, omissions, and mistakes
System design flaws
Hardware implementation flaws, such as wiring and chip flaws
Software implementation errors, program bugs, and compiler bugs
System use and operation errors and inadvertent mistakes
Willful system misuse
Hardware, communication, or other equipment malfunction
Environmental problems, natural causes, and acts of God
Evolution, maintenance, faulty upgrades, and decommissions

9. Examples Challenger explosion
Sensors removed from booster rockets to meet accelerated launch schedule
Deaths from faulty radiation therapy system
Hardware safety interlock removed
Flaws in software design
Bell V22 Osprey crashes
Failure to correct for malfunctioning components; two faulty ones could outvote a third
Intel 486 chip
Bug in trigonometric functions

10. The Role of Requirements in Assurance
Definition 17-4
Vary from high-level, generic issues to low-level, concrete issues
Security objectives are high-level security issues
Security requirements are specific, concrete issues
A requirement is a statement of goals that must be satisfied.

11. Types of Assurance
Policy assurance is evidence establishing security requirements in policy is complete, consistent, technically sound
Figure 17-2

12. Types of Assurance
Design assurance is evidence establishing design sufficient to meet requirements of security policy
Implementation assurance is evidence establishing implementation consistent with security requirements of security policy
Operational assurance is evidence establishing system sustains the security policy requirements during installation, configuration, and day-to-day operation
Also called administrative assurance

13. Life Cycle Conception This stage starts with an idea Proof of concept
Decisions to pursue it
Proof of concept
See if idea has merit
High-level requirements analysis
What does “secure” mean for this concept?
Is it possible for this concept to meet this meaning of security?
Is the organization willing to support the additional resources required to make this concept meet this meaning of security?

14. Manufacture GROUP OUTPUT
Development of more detailed plans ( marketing plans, sales training plans, development plans, test plans..)
OUTPUT
Materials to determine whether to proceed
ex.
GROUP
OUTPUT
Marketing
marketing collateral (white papers, data sheets..)
Sales
Documented leads and sales channels
Engineering
Tested, debugged system
Documentation
Manuals, guides
Service
Staff who handle telephone calls

15. Deployment process of getting the system out to the customer Substages
Domain of production, distribution, shipping Security & assurance issue : what was received, what was shipped.
Proper production setting

16. Fielded Product Life
Patching or fixing bugs, maintenance, customer service.
Separate from the product development organization.
Engineering process -> track maintenance and patches.
Deployment process -> distribute patches and new releases.
Must meet development level of assurance.

17. The Waterfall Life Cycle Model
Definition The waterfall life cycle model is the model of building in stages, whereby one stage is completed before the next stage begins.
Most common technique
Figure 17-3

18. The Waterfall Life Cycle Model
Requirements Definition and Analysis
Requirements
Functional : interactions between the system and environment.
Nonfunctional : constraints or restrictions
WHAT(O) : HOW(X)
Analysis of requirements
correct, consistent, complete, realistic, verifiable, traceable
Architecture must be able to support the requirements.

19. The Waterfall Life Cycle Model
System and Software Design
Requirements into specific executable programs.
Written external functional specifications, Internal design specifications.
Input, output, constraints of functions
Algorithms, data structures, required internal routines

20. The Waterfall Life Cycle Model
implementation and Unit Testing
Implementation
development of software programs (programs or program units)
Unit testing
process of establishing that the unit meets its specifications
Integration and System Testing
Integration
Process of combining all the units into a complete system
System testing
Process of ensuring that the system as a whole meets the requirements (iterative)

21. The Waterfall Life Cycle Model
Operation and Maintenance
Fielding the system (move into production)
Maintenance
correction of errors, routine maintenance, release of new versions

22. The Waterfall Life Cycle Model
Iteration between the process at each stage

23. The Waterfall Life Cycle Model
“trickle down”
Error discovered in system testing
Impact the software design

24. The Waterfall Life Cycle Model계획
요구분석 설계
문제 정의
타당성 분석
비용,일정 예측
시스템정의서
프로젝트계획서
DFD
자료사전
소단위명세서
요구 사양서
시스템구조설계
프로그램 설계
UI 설계
구조설계서
상세설계서
사용자지침
테스트계획 구현 시험
운용,유지보수
프로그래밍
단위테스트
프로그램 (모듈 별 코드)
인수시험계획서
통합시험
기능시험
성능시험
통합 소프트웨어
검증 소프트웨어 설치
인수시험
설치 소프트웨어

25. Other Models 1.Exploratory Programming
Developed quickly and then modified.
AI system (O)
Users cannot formulate detailed requirements specification
Adequacy > Correctness
Secure and Trusted system (X)
Assurance becomes difficult : No requirements or design specifications
implementation potentially vulnerable to attack

26. Other Models 2. Prototyping
1.Rapid development (for establish the system requirements)
2.Reimplemented to create a production-quality system (using another model)
3. Formal Transformation
Create a formal specification (by developer)
Beneficial to security, to design (if well-formed security requirements)

27. Other Models 정의 분석 업무설계 기술설계 구축 테스트 이행 프로토 타입 Initial Concept Design
and
Implement
initial
prototype
Refine
until
acceptable
Complete
release

28. Other Models 4. System Assembly from Reusable Components Assumption
systems are made up mostly of components that already exist.
Need to reconcile the security models and requirements
Trusted systems out of trusted components
Trusted systems out of untrusted components
Complex
Common approach to building secure and trusted systems

29. Other Models 5. Extreme Programming
Based on rapid prototyping and best practices
separate testing of components, frequent reviewing, frequent integration of components and simple design
Objective
put a minimal system into production as quickly as possible
Benefits and Drawbacks
Vulnerable to the problems of an add-on product
Leaving requirements does not ensure that security requirements
Analyze threats, develop requirements before the system designed Trusted system

30. Building Security In or Adding Security Later
Definition 17-11
Definition 17-12
A reference monitor is an access control concept of an abstract machine that mediates all accesses to objects by subjects.
A reference validation mechanism (RVM) is an implementation of the reference monitor concept. An RVM must be tamperproof, must always be invoked (and can never be bypassed), and must be small enough to be subject to analysis and testing, the completeness of which can be assured.

31. Building Security In or Adding Security Later
Definition 17-13
Definition 17-14
A security kernel is a combination of hardware and software that implements a reference monitor.
A trusted computing base (TCB) consists of all protection mechanisms within a computer system – including hardware, firmware, and software – that are responsible for enforcing a security policy.

32. Building Security In or Adding Security Later
Integrated into the system from the beginning, rather than added on later?
Products created from proevious version without security -> cannot achieve high trust

33. Building Security In or Adding Security Later
More and deeper assurance leads to a higher level of trust
Trade-offs between features and simplicity
Complexity (inclusion of many features)
Gap in abstraction between security requirements and implementation code

34. Examples Multics Gemsos guards
General-purpose operating systems that built for secure applications
Gemsos
High-assurance, formally verified operating system
minimal UNIX-like kernel and limited functionality
guards
Information flow control mechanisms
RECON
a highly classified reconnaissance database to an unclassified network
Restricted Access Processor
between two different classified networks

35. Examples 2 AT&T products Add mandatory controls to UNIX system SV/MLS
Add security to UNIX System V Release 3.2
SVR4.1ES
Re-architect UNIX system to support security