1. Introduction to Assurance
AI Lab.
오석영

2. Contents 17.1 Assurance and Trust
The Need for Assurance
The Role of Requirements in Assurance
17.2 Building Secure and Trusted Systems
Life Cycle (Meta model)
The Waterfall Life Cycle Model
Other Life Cycle Model
17.3 Building Security In or Adding Later
17.4 Recent Works

3. 1. Assurance and Trust

4. Assurance and Trust Trust Trusted system
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.
Trusted system
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.

5. Assurance
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.
Policy
Mechanisms
Assurance

6. The Need for Assurance Neumann’s list (problem source)
1. Requirements definitions, omissions, and mistakes
2. System design flaws
3. Hardware implementation flaws, such as wiring and chip flaws
4. Software implementation errors, program bugs, and compiler bugs
5. System use and operation errors and inadvertent mistakes
6. Willful system misuse
7. Hardware, communication, or other equipment malfunction
8. Environmental problems, natural causes, and acts of God
9. Evolution, maintenance, faulty upgrades, and decommissions

7. example
(1/28), Space Shuttle Challenger disaster , Radiation therapy machine malfunctioning
killing everyone on board
Decision to take shortcuts to meet an accelerated launch schedule
Sensors removed from booster rockets
Three patients died from a radiation overdose
Flaws in software design
Hardware safety interlock removed

8. 3. 1979, Three Mile Island Nuclear Failure 4. Bell V22 Osprey crashes
Hardwar problem
Flaws in software design
: temperature very high -> the system printed a string of “?” rather than the measured temperature
High-technology helicopter
Failure to correct for malfunctioning components;
two faulty ones could outvote a correctly functioning third

9. The Role of Requirements in Assurance
Requirement is a statement of goals that must be satisfied
Security objectives are high-level security issues
Security requirements are specific, concrete issues

10. Assurance Throughout the Life Cycle
Policy assurance is the evidence establishing that the set of security requirements in the policy is complete, consistent, and technically sound.
Design assurance is the evidence establishing that a design is sufficient to meet the requirements of the security policy.

11. Assurance Throughout the Life Cycle
Implementation assurance is the evidence establishing that the implementation is consistent with the security requirements of the security policy.
Operational or administrative assurance is the evidence establishing that the system sustains the security policy requirements during installation, configuration, and day- to-day operation.

12. Development of a trusted system

13. 2. Building Secure and Trusted Systems

14. Building Secure and Trusted Systems
Life cycle (4 step)
The concept of a life cycle addresses security- relevant decisions that often are made outside the engineering disciplines in business situations.
A life cycle starts when a system is considered for development and use. The life cycle ends when the system is no longer used.

15. Life Cycle - ① Conception
Idea
Decisions to pursue it
Proof of concept
Demonstration that an 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. ② Manufacture Develop detailed plans for each group involved
Marketing / sales training / development / test plan etc.
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
Output
Materials to determine whether to proceed
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

17. ③ Deployment Delivery (production, distribution and shipping)
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 must know security procedures

18. ④ Fielded Product Life Routine maintenance, patching
Responsibility of engineering in small organizations
Responsibility may be in different group than one that manufactures product
Commercial systems often have separate customer service and support organizations
Product retirement or decision to take a product out of service, is a critical part of this stage

19. The Waterfall Life Cycle Model
The waterfall life cycle model is the model of building in stages, whereby one stage is completed before the next stage begins.

20. Requirements definition and analysis
Functional and non-functional requirements
Requirements describe what, not how and should be implementation-independent
System and software design
External functional specification and internal design specification
Implementation and unit testing
Implementation is development of software programs
(programs or program units)
Unit testing is process of establishing that the unit meets its specifications

21. Integration and system testing
Integration is the process of combining all the unit-tested program units into a complete system
System testing is the process of ensuring the system as a whole meets the requirements
Operation and maintenance
Fielding the system (move into production)
Maintenance involves correction of errors, routine maintenance, release of new versions

22. trickle down Error discovered in system testing
Impact the software design

23. Other Models of Software Development
① Exploratory programming
Developed quickly and then modified.
Used in AI system
Users cannot formulate detailed requirements specification
Adequacy > Correctness
Secure and Trusted system
Assurance becomes difficult :
no requirements or design specifications
implementation potentially vulnerable to attack

24. ② Prototyping 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

25. ③ Formal Transformation
Create formal specification
Translate it into program using correctness-preserving transformations
developed should be subjected to the same rigorous implementation testing and vulnerabilities analysis that are applied to any other methodology

26. ④ System Assembly from Reusable Components
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

27. ⑤ Extreme Programming Based on rapid prototyping and best practices
separate testing of components, frequent reviewing etc.
Objective is put a minimal system into production as quickly as possible
Assurance
Leaving requirement open does not ensure security requirements will be properly implemented
Threats were analyzed and appropriate security requirements developed before the system was designed
=> trusted system

28. 3. Building Security In or Adding Security Later

29. Building Security In or Adding Security Later
Imagine you’re trying to create a high-performance system out of poor-performance system
If it’s because of fundamental structure, design of the system, then it might be better to start over
You need to design it in
Otherwise, system lacks fundamental and structural concepts for high assurance
Like performance, security is an integral part of a computer system. It should be integrated into the system from the beginning

30. Building In Security Reference monitor
the access control concept of an abstract machine
that mediates all accesses to objects by subjects
Reference validation mechanism (RVM)
the implementation of the reference monitor concept
Must be tamperproof
always invoked and can never be bypassed
small enough to be subject to analysis and testing, the completeness of which can be assured

31. Security kernel combines hardware and software to implement reference monitor
early example of RVM
Trusted computing base (TCB) consists of all protection mechanisms within a system including h/w, f/w, and s/w that are responsible for enforcing security policy
generalizes notion of security kernel

32. trade-offs between features and simplicity
More and deeper assurance leads to a higher level of trust in the resulting system
Design analysis (formal/informal method)
More thorough testing
trade-offs between features and simplicity
Including many features often leads to complexity, which limit the ability to analyze the system, which in turn lowers potential level of assurance

33. Adding On Security Adding in mechanisms makes assurance hard
May be spread throughout system (analysis hard)
Assurance may be limited to test results
Testing of conformance to a flowed design is similar to designing a system to meet inappropriate requirement
Gap in abstraction between security requirements and implementation code may prohibit complete requirements testing

34. Example for Secure Unix
AT&T products
SV/MLS
SVR4.1ES
Architecting of System
used existing kernel modular structure
=>no implementation of least privilege
restructured kernel to make it highly modular
=> incorporated least privilege
File Attributes
added separate table
for mandatory access control labels
(inode point to the table)
Need two access, so inconsistency issue can happens.
more failure point
Redefined
inode structure
to include MAC label
(more effort to upgrade)
Only one access needed to check permissions

35. 4. Current Works

36. A Design for Component Assembly Framework
for Security Assurance

37. A study on the Process for Applying Security Assurance based CC on Software Lifecycle

38. On the Study of Trusted information Exchange Services based on Authentication Policy Extension