1. Introduction to Assurance
김동헌

2. A table of contents. 1. Assurance and Trust.
2. Building Secure and Trusted Systems.
3. Building Security In or Adding Security Later.

3. Introduction to Assurance
1. Assurance and Trust.

4. 1. Assurance and Trust. Trustworthy. Trust.
An entity is trustworthy if there is sufficient credible evidence l eading one to believe that the system will meet a set of given r equirements.
Trust.
Trust is a belief or desire that a computer entity will do what it should to protect resources and be safe from attack.
Trust is a measure of trustworthiness, relying on the evidence provided.

5. 1. Assurance and Trust. Assurance. Trusted system.
Security assurance, or simply assurance, is confidence that an e ntity meets its security requirements, based on specific evidenc e provided by the application of assurance techniques.
Trusted system.
A trusted system is a system that has been shown 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.

6. 1. Assurance and Trust. Assurance technique. Informal. Semiformal.
Informal methods use natural languages for specifications and justificat ions of claims. Informal methods impose a minimum of rigor on the pr ocesses used.
Semiformal.
Semiformal methods use natural languages for specifications and justifi cations but apply a specific overall method that imposes some rigor o n the process. Often these methods mimic formal methods.
formal.
Formal methods use mathematics and other machine-parsable languag es with tools and rigorous techniques such as formal mathematical pr oofs.

7. Relation. Assurance, policy and mechanisms.
1. Assurance and Trust.
Policy
Assurance
Mechanisms
Relation. Assurance, policy and mechanisms.

8. 1. Assurance and Trust. The need for assurance.
Neumann’s list(problem source).
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. 1. Assurance and Trust. Example. 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.
Intel 486 chip.
Bug in trigonometric functions.

10. 1. Assurance and Trust. The Role of Requirements in Assurance.
Although security policies define security for a particular syste m, the policies themselves are created to meet needs. These ne eds are the requirements.
A requirement is a statement of goals that must be satisfied.

11. 1. Assurance and Trust. Assurance Throughout the Life Cycle.
Policy assurance is the evidence establishing that the set of sec urity requirements in the policy is complete, consistent, and tec hnically sound.
Design assurance is the evidence establishing that a design is su fficient to meet the requirements of the security policy.
Implementation assurance is the evidence establishing that the i mplementation is consistent with the security requirements of the security policy.
Operational or administrative assurance is the evidence establi shing that the system sustains the security policy requirements during installation, configuration, and day-to-day operation.

12. Security requirements
1. Assurance and Trust.
Design and
implementation
refinement
Security requirements
Design
Assurance
justification
Implementation
Development of a trusted system. There may be multiple levels of design and implementation. Note that the refinement steps alternate with the assurance steps.

13. Introduction to Assurance
2. Building Secure and Trusted Systems.

14. 2. Building Secure and Trusted Systems.
An explanation of Life cycle.
The concept of a life cycle addresses security-relevant decision s that often are made outside the engineering disciplines in busi ness situations.
A life cycle starts when a system is considered for developmen t and use. The life cycle ends when the system is no longer use d.
A typical life cycle process is defined in stages.

15. 2. Building Secure and Trusted Systems.
Life cycle(1/4).
Conception.
Idea.
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?

16. 2. Building Secure and Trusted Systems.
Life cycle(2/4).
Manufacture.
Develop detailed plans for each group involved.
May depend on use; internal product requires no sales.
Implement the plans to create entity.
Includes decisions whether to proceed, for example due to market needs.

17. 2. Building Secure and Trusted Systems.
Life cycle(3/4).
Deployment.
Delivery.
Assure that correct masters are delivered to production and protected.
Distribute to customers, sales organizations.
Installation and configuration.
Ensure product works appropriately for specific environment into which it is installed.
Service people know security procedures.

18. 2. Building Secure and Trusted Systems.
Life cycle(4/4).
Fielded Product Life.
Routine maintenance, patching.
Responsibility of engineering in small organizations.
Responsibility may be in different group than one that manufactures product.
Customer service, support organizations.
Retirement or decommission of product.

19. 2. Building Secure and Trusted Systems.
Waterfall Life Cycle Model stage.
Requirements definition and analysis.
System and software design.
Implementation and unit testing.
Integration and system testing.
Operation and maintenance.

20. 2. Building Secure and Trusted Systems.
Relationship of stage.
Requirements definition and analysis
System and software design
Implemenation and unit testing
Integration and system testing
Operation and maintenance
The waterfall life cycle model. The solid arrows represent the flow of development in the model. The dashed arrows represent the paths along which information about errors may be sent.

21. 2. Building Secure and Trusted Systems.
Other Models of Software Development(1/5).
Exploratory Programming.
A working system is developed quickly and then modified until it perf orms adequately.
there are no requirements or design specifications. Hence, assurance becomes difficult.
this model is not particularly useful for building secure and trusted sys tems because such systems need precise requirements and detailed ve rification that they meet those requirements as implemented.

22. 2. Building Secure and Trusted Systems.
Other Models of Software Development(2/5).
Prototyping.
Prototyping is similar to exploratory programming.
The objective of the rapid development is specifically to establish the system requirements.
The reimplementation can be done using another model that is more conducive to development of secure and trusted systems.

23. 2. Building Secure and Trusted Systems.
Other Models of Software Development(3/5).
Formal Transformation.
The developers create a formal specification of the software system.
They transform this specification into a program using correctness-pr eserving transformations.
A system developed should be subjected to the same rigorous imple mentation testing and vulnerabilities analysis that are applied to any ot her methodology.

24. 2. Building Secure and Trusted Systems.
Other Models of Software Development(4/5).
System Assembly from Reusable Components.
This technique assumes that systems are made up mostly of compone nts that already exist.
Developing trusted systems out of trusted components is complex be cause of the need to reconcile the security models and requirements of each component.
Developing trusted systems out of untrusted components is even mor e complex. However, this is a common approach to building secure an d trusted systems.

25. 2. Building Secure and Trusted Systems.
Other Models of Software Development(5/5).
Extreme Programming.
Extreme programming is a development methodology based on rapid prototyping and best practices such as separate testing of component s, frequent reviewing, frequent integration of components, and simple design.
The nature of an evolving design leaves the product vulnerable to the problems of an add-on product.
If threats were analyzed and appropriate security requirements develo ped before the system was designed, a secure or trusted system could result.

26. Introduction to Assurance
3. Building Security In or Adding Security Later.

27. 3. Building Security In or Adding Security Later.
Like performance, security is an integral part of a comput er system. It should be integrated into the system from th e beginning, rather than added on later.
A basic concept in the design and development of secure computer systems is the concept of a reference monitor and its implementationthe reference validation mechanis m.

28. 3. Building Security In or Adding Security Later.
Reference monitor.
A reference monitor is an access control concept of an abstrac t machine that mediates all accesses to objects by subjects.
Reference validation mechanism.
A reference validation mechanism (RVM) is an implementation of the reference monitor concept. An RVM must be tamperpro of, must always be invoked (and can never be bypassed), and m ust be small enough to be subject to analysis and testing, the co mpleteness of which can be assured.

29. 3. Building Security In or Adding Security Later.
Example.
Security kernel.
A security kernel is a combination of hardware and software that impl ements a reference monitor.
Security kernels were early examples of reference validation m echanisms.

30. 3. Building Security In or Adding Security Later.
Example.
Trusted computing base.
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.
A TCB consists of one or more components that together enf orce the security policy of a system.
The ability of a TCB to enforce a security policy depends solely on the mechanisms within the TCB and on the correct input of parameters (such as a user's clearance) related to the security policy.

31. 3. Building Security In or Adding Security Later.
Adding On Security.
Key to problem: analysis and testing.
Designing in mechanisms allow assurance at all levels.
Too many features adds complexity, complicates analysis.
Adding in mechanisms makes assurance hard.
Gap in abstraction from requirements to design may prevent complete requirements testing.
May be spread throughout system(analysis hard).
Assurance may be limited to test results.

32. 3. Building Security In or Adding Security Later.
Key Points.
Assurance critical for determining trustworthiness of systems.
Different levels of assurance, from informal evidence to rigorous mathematical evidence.
Assurance needed at all stages of system life cycle.
Building security in is more effective than adding it later.