1. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-1 Chapter 17: Introduction to Assurance Overview Why assurance? Trust and assurance Life cycle and assurance Building security in vs. adding security later

2. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-2 Overview Trust Problems from lack of assurance Types of assurance Life cycle and assurance Waterfall life cycle model Other life cycle models Adding security afterwards

3. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-3 Trust Trustworthy entity has sufficient credible evidence leading one to believe that the system will meet a set of requirements Trust is a measure of trustworthiness relying on the evidence Assurance is confidence that an entity meets its security requirements based on evidence provided by applying assurance techniques

4. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-4 Relationships

5. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-5 Problem Sources 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

6. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-6 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

7. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-7 Role of Requirements Requirements are statements of goals that must be met –Vary from high-level, generic issues to low- level, concrete issues Security objectives are high-level security issues Security requirements are specific, concrete issues

8. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-8 Types of Assurance Policy assurance is evidence establishing security requirements in policy is complete, consistent, technically sound 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

9. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-9 Types of Assurance Operational assurance is evidence establishing system sustains the security policy requirements during installation, configuration, and day-to-day operation –Also called administrative assurance

10. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-10 Life Cycle

11. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-11 Life Cycle Conception Manufacture Deployment Fielded Product Life

12. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-12 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?

13. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-13 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

14. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-14 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

15. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-15 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

16. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-16 Waterfall Life Cycle Model Requirements definition and analysis –Functional and non-functional –General (for customer), specifications System and software design Implementation and unit testing Integration and system testing Operation and maintenance

17. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-17 Relationship of Stages

18. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-18 Models Exploratory programming –Develop working system quickly –Used when detailed requirements specification cannot be formulated in advance, and adequacy is goal –No requirements or design specification, so low assurance Prototyping –Objective is to establish system requirements –Future iterations (after first) allow assurance techniques

19. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-19 Models Formal transformation –Create formal specification –Translate it into program using correctness-preserving transformations –Very conducive to assurance methods System assembly from reusable components –Depends on whether components are trusted –Must assure connections, composition as well –Very complex, difficult to assure

20. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-20 Models Extreme programming –Rapid prototyping and “best practices” –Project driven by business decisions –Requirements open until project complete –Programmers work in teams –Components tested, integrated several times a day –Objective is to get system into production as quickly as possible, then enhance it.

21. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-21 Security: Built In or Add On? Think of security as you do performance –You don’t build a system, then add in performance later Can “tweak” system to improve performance a little Much more effective to change fundamental algorithms, design You need to design it in –Otherwise, system lacks fundamental and structural concepts for high assurance

22. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-22 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

23. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-23 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

24. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-24 Chapter 18: Evaluating Systems Goals Trusted Computer System Evaluation Criteria FIPS 140 Common Criteria

25. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-25 Overview Goals –Why evaluate? Evaluation criteria –TCSEC (aka Orange Book) –FIPS 140 –Common Criteria

26. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-26 Goals Show that a system meets specific security requirements under specific conditions –Called a trusted system –Based on specific assurance evidence Formal evaluation methodology –Technique used to provide measurements of trust based on specific security requirements and evidence of assurance

27. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-27 Evaluation Methodology Provides set of requirements defining security functionality for system Provides set of assurance requirements delineating steps for establishing that system meets its functional requirements Provides methodology for determining that system meets functional requirements based on analysis of assurance evidence Provides measure of result indicating how trustworthy system is with respect to security functional requirements –Called level of trust

28. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-28 Why Evaluate? Provides an independent assessment, and measure of assurance, by experts –Includes assessment of requirements to see if they are consistent, complete, technically sound, sufficient to counter threats –Includes assessment of administrative, user, installation, other documentation that provides information on proper configuration, administration, use of system Independence critical –Experts bring fresh perspectives, eyes to assessment

29. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-29 Bit of History Government, military drove early evaluation processes –Their desire to use commercial products led to businesses developing methodologies for evaluating security, trustworthiness of systems Methodologies provide combination of –Functional requirements –Assurance requirements –Levels of trust

30. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-30 Functional Requirements Discretionary access control requirements –Control sharing of named objects –Address propagation of access rights, ACLs, granularity of controls Object reuse requirements –Hinder attacker gathering information from disk or memory that has been deleted –Address overwriting data, revoking access rights, and assignment of resources when data in resource from previous use is present

31. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-31 Functional Requirements Mandatory access control requirements (B1 up) –Simple security condition, *-property –Description of hierarchy of labels Label requirements (B1 up) –Used to enforce MAC –Address representation of classifications, clearances, exporting labeled information, human-readable output Identification, authentication requirements –Address granularity of authentication data, protecting that data, associating identity with auditable actions

32. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-32 Functional Requirements Audit requirements –Define what audit records contain, events to be recorded; set increases as other requirements increase Trusted path requirements (B2 up) –Communications path guaranteed between users System architecture requirements –Tamperproof reference validation mechanism –Process isolation –Enforcement of principle of least privilege –Well-defined user interfaces

33. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-33 Functional Requirements Trusted facility management (B2 up) –Separation of operator, administrator roles Trusted recovery (A1) –Securely recover after failure or discontinuity System integrity requirement –Hardware diagnostics to validate on-site hardware, firmware of TCB

34. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-34 Assurance Requirements Configuration management requirements (B2 up) –Identify configuration items, consistent mappings among documentation and code, tools for generating TCB System architecture requirements –Modularity, minimize complexity, etc. –TCB full reference validation mechanism at B3 Trusted distribution requirement (A1) –Address integrity of mapping between masters and on- site versions –Address acceptance procedures

35. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-35 Assurance Requirements Design specification, verification requirements –B1: informal security policy model shown to be consistent with its axioms –B2: formal security policy model proven to be consistent with its axioms, descriptive top-level specification (DTLS) –B3: DTLS shown to be consistent with security policy model –A1: formal top-level specification (FTLS) shown consistent with security policy model using approved formal methods; mapping between FTLS, source code

36. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-36 Assurance Requirements Testing requirements –Address conformance with claims, resistance to penetration, correction of flaws –Requires searching for covert channels for some classes Product documentation requirements –Security Features User’s Guide describes uses, interactions of protection mechanisms –Trusted Facility Manual describes requirements for running system securely Other documentation: test, design docs

37. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-37 Evaluation Classes A and B A1Verified protection; significant use of formal methods; trusted distribution; code, FTLS correspondence B3Security domains; full reference validation mechanism; increases trusted path requirements, constrains code development; more DTLS requirements; documentation B2Structured protection; formal security policy model; MAC for all objects, labeling; trusted path; least privilege; covert channel analysis, configuration management B1Labeled security protection; informal security policy model; MAC for some objects; labeling; more stringent security testing

38. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-38 Evaluation Classes C and D C2Controlled access protection; object reuse, auditing, more stringent security testing C1Discretionary protection; minimal functional, assurance requirements; I&A controls; DAC DDid not meet requirements of any other class

39. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-39 Evaluation Process Run by government, no fee to vendor 3 stages –Application: request for evaluation May be denied if gov’t didn’t need product –Preliminary technical review Discussion of evaluation process, schedules, development process, technical content, etc. Determined schedule for evaluation –Evaluation phase

40. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-40 Evaluation Phase 3 parts; results of each presented to technical review board composed of senior evaluators not on evaluating team; must approve that part before moving on to next part –Design analysis: review design based on documentation provided; developed initial product assessment report Source code not reviewed –Test analysis: vendor’s, evaluators’ tests –Final evaluation report Once approved, all items closed, rating given

41. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-41 Impact New approach to evaluating security –Based on analyzing design, implementation, documentation, procedures –Introduced evaluation classes, assurance requirements, assurance-based evaluation –High technical standards for evaluation –Technical depth in evaluation procedures Some problems –Evaluation process difficult, lacking in resources –Mixed assurance, functionality together –Evaluations only recognized in US

42. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-42 FIPS 140: 1994–Present Evaluation standard for cryptographic modules (implementing cryptographic logic or processes) –Established by US government agencies and Canadian Security Establishment Updated in 2001 to address changes in process and technology –Officially, FIPS 140-2 Evaluates only crypto modules –If software, processor executing it also included, as is operating system

43. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-43 Requirements Four increasing levels of security FIPS 140-1 covers basic design, documentation, roles, cryptographic key management, testing, physical security (from electromagnetic interference), etc. FIPS 140-2 covers specification, ports & interfaces; finite state model; physical security; mitigation of other attacks; etc.

44. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-44 Security Level 1 Encryption algorithm must be FIPS- approved algorithm Software, firmware components may be executed on general-purpose system using unevaluated OS No physical security beyond use of production-grade equipment required

45. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-45 Security Level 2 More physical security –Tamper-proof coatings or seals or pick-resistent locks Role-based authentication –Module must authenticate that operator is authorized to assume specific role and perform specific services Software, firmware components may be executed on multiuser system with OS evaluated at EAL2 or better under Common Criteria –Must use one of specified set of protection profiles

46. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-46 Security Level 3 Enhanced physical security –Enough to prevent intruders from accessing critical security parameters within module Identity-based authentication Strong requirements for reading, altering critical security parameters Software, firmware components require OS to have EAL3 evaluation, trusted path, informal security policy model –Can use equivalent evaluated trusted OS instead

47. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-47 Security Level 4 “Envelope of protection” around module that detects, responds to all unauthorized attempts at physical access –Includes protection against environmental conditions or fluctuations outside module’s range of voltage, temperatures Software, firmware components require OS meet functional requirements for Security Level 3, and assurance requirements for EAL4 –Equivalent trusted operating system may be used

48. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-48 Impact By 2002, 164 modules, 332 algorithms tested –About 50% of modules had security flaws –More than 95% of modules had documentation errors –About 25% of algorithms had security flaws –More than 65% had documentation errors Program greatly improved quality, security of cryptographic modules

49. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-49 Common Criteria: 1998–Present Began in 1998 with signing of Common Criteria Recognition Agreement with 5 signers –US, UK, Canada, France, Germany As of May 2002, 10 more signers –Australia, Finland, Greece, Israel, Italy, Netherlands, New Zealand, Norway, Spain, Sweden; India, Japan, Russia, South Korea developing appropriate schemes Standard 15408 of International Standards Organization De facto US security evaluation standard

50. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-50 Evaluation Methodology CC documents –Overview of methodology, functional requirements, assurance requirements CC Evaluation Methodology (CEM) –Detailed guidelines for evaluation at each EAL; currently only EAL1–EAL4 defined Evaluation Scheme or National Scheme –Country-specific infrastructures implementing CEM –In US, it’s CC Evaluation and Validation Scheme; NIST accredits commercial labs to do evaluations

51. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-51 CC Terms Target of Evaluation (TOE): system or product being evaluated TOE Security Policy (TSP): set of rules regulating how assets managed, protected, distributed within TOE TOE Security Functions (TSF): set consisting of all hardware, software, firmware of TOE that must be relied on for correct enforcement of TSP –Generalization of TCB

52. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-52 Protection Profiles CC Protection Profile (PP): implementation- independent set of security requirements for category of products or systems meeting specific consumer needs –Includes functional requirements Chosen from CC functional requirements by PP author –Includes assurance requirements Chosen from CC assurance requirements; may be EAL plus others –PPs for firewalls, desktop systems, etc. –Evolved from ideas in earlier criteria

53. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-53 Form of PP 1.Introduction PP Identification and PP Overview 2.Product or System Family Description Includes description of type, general features of product or system 3.Product or System Family Security Environment Assumptions about intended use, environment of use; Threats to the assets; and Organizational security policies for product or system

54. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-54 Form of PP (con’t) 4.Security Objectives Trace security objectives for product back to aspects of identified threats and/or policies Trace security objectives for environment back to threats not completely countered by product or systemand/or policies or assumptions not completely met by product or system 5.IT Security Requirements Security functional requirements drawn from CC Security assurance requirements based on an EAL May supply other requirements without reference to CC

55. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-55 Form of PP (con’t) 6.Rationale Security Objectives Rationale demonstrates stated objectives traceable to all assumptions, threats, policies Security Requirements Rationale demonstrates requirements for product or system and for environment traceable to objectives and meet them This section provides assurance evidence that PP is complete, consistent, technically sound

56. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-56 Security Target CC Security Target (ST): set of security requirements and specifications to be used as basis for evaluation of identified product or system –Can be derived from a PP, or directly from CC If from PP, ST can reference PP directly –Addresses issues for specific product or system PP addresses issues for a family of potential products or systems

57. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-57 Form of ST 1.Introduction ST Identification, ST Overview CC Conformance Claim Part 2 (or part 3) conformant if all functional requirements are from part 2 (or part 3) of CC Part 2 (or part 3) extended if uses extended requirements defined by vendor as well 2.Product or System Description Describes TOE as aid to understanding its security requirement

58. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-58 Form of ST (con’t) 3.Product or System Family Security Environment 4.Security Objectives 5.IT Security Requirements These are the same as for a PP

59. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-59 Form of ST (con’t) 6.Product or System Summary Specification Statement of security functions, description of how these meet functional requirements Statement of assurance measures specifying how assurance requirements met 7.PP Claims Claims of conformance to (one or more) PP requirements

60. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-60 Form of ST (con’t) 8.Rationale Security objectives rationale demonstrates stated objectives traceable to assumptions, threats, policies Security requirements rationale demonstrates requirements for TOE and environment traceable to objectives and meets them TOE summary specification rationale demonstrates how TOE security functions and assurance measures meet security requirements Rationale for not meeting all dependencies PP claims rationale explains differences between the ST objectives and requirements and those of any PP to which conformance is claimed

61. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-61 CC Requirements Both functional and assurance requirements EALs built from assurance requirements Requirements divided into classes based on common purpose Classes broken into smaller groups (families) Families composed of components, or sets of definitions of detailed requirements, dependent requirements and definition of hierarchy of requirements

62. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-62 Key Points First public, widely used evaluation methodology was TCSEC (Orange Book) –Criticisms led to research and development of other methodologies Evolved into Common Criteria Other methodologies used for special environments

63. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-63 Web Trust A Web site assurance service developed by American Institute of Certified Public Accountants (AICPA) and Canadian Institute of Chartered Accountants (CICA) Reviews have been on large e-commerce sites to gain customer confidence

64. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-64 Main Trust Principles Availability Security Integrity

65. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-65 Main Web Trust Principles Availability – backup and disaster recovery procedures. Security – identification, authentication, authorization, logging and monitoring. Business practices and transaction integrity – equivalent business treatment to brick-and-mortar channel, no unauthorized transaction change.

66. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-66 Other Web Trust Principles Confidentiality – no unauthorized viewing Privacy – confidentiality of personal info Non-repudiation – digital certificate Customer disclosures – give customers they want to know relating to their info

67. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-67 Web Trust Review The reviewer has to be licensed by AICPA or CICA. The outcome of the review consists of a report and the Web Trust seal if the client passes the selected criteria. The seal can be placed on the Web site. High control assurance.

68. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-68 Web Trust Seal Semi-annual update review required of Internet service providers in order to keep the seal. Annual update review required of Certificate Authorities in order to keep the seal, but satisfy all principles.

69. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-69 Web Trust Seal Quarterly update review required of other organizations in order to keep the seal A click on the seal will bring the Web site visitor to the review report and Web Trust principles

70. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-70 Consumer Assurance Addressed by Web Trust The company is real  The company is trustworthy  The consumer will receive the goods purchased The consumer will receive delivery when promised

71. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-71 Consumer Assurance The consumer can return purchased goods or service the goods through the warranty provided In case of problems (e.g., shipping errors) there are mechanisms to rectify the situation There is a contact telephone number connected to a “live”representative who can help in the event of a problem

72. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-72 Consumer Assurance The site offers alternative ways to pay if the customer decides against submitting the information electronically The information they submit is protected on the host’s network through strong security measures

73. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-73 Consumer Assurance The site’s connections to the internet are secure The site has implemented and documented a security policy The information submitted to the site is encrypted with a strong encryption package

74. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-74 Consumer Confidence Financial information (account information, credit card numbers, billing information) cannot be copied, stolen or viewed by persons other than those for whom its is intended. Personal information submitted (e.g., home address, telephone number, e-mail address) will be viewed only by those intended to receive it.

75. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-75 Consumer Assurance Any information submitted will not be sold or used for purpose other than those intended

76. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-76 SysTrust A system assurance service developed by American Institute of Certified Public Accountants (AICPA) and Canadian Institute of Chartered Accountants (CICA) Reviews have been on new systems in an organization or systems shared by a number of partner organizations High control assurance

77. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-77 Main SysTrust Principles Availability Security Integrity

78. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-78 Other SysTrust Principles Confidentiality Privacy Maintainability

79. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-79 Components of System Infrastructure Software People Procedures Data

80. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-80 Availability and Security Availability - The system is available for operation and use at times set forth in service level statements or agreements Security - The system is protected against unauthorized physical and logical access

81. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-81 Integrity and Maintainability Integrity - System processing is complete, accurate, timely and authorized. Focusing on completeness and authorization. Maintainability - The system can be updated when required in a manner that continues to provide for system availability, security and integrity.

82. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-82 SysTrust Review The reviewer has to be licensed by AICPA or CICA The review is reported with an opinion against management’s assertion about the system

83. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-83 SysTrust Users Management Customers Trading partners Financial statement auditors

84. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-84 SysTrust Users Internal and legislative auditors Software vendors Service providers

85. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-85 Web Trust and SysTrust Report An opinion on management’s asserted controls. Controls are grouped by control objectives (criteria) and by principles, order is principle, control objective and control procedure. Opinion does not cover system description, although system description is often included in the report. But if reviewer knows that system description is misleading, s/he should not issue an opinion on the controls.

86. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-86 Web Trust and Sys Trust Report Opinion addresses adequacy of controls for each selected principle. Opinion covers the reporting period.

87. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-87 Drivers for SysTrust Review The potential conflict of interest between the system operator and system user or owner. The complexity of systems, requiring expertise to conduct an audit that would provide a reasonable degree of assurance about their conformity with system reliability principles and criteria.

88. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-88 Drivers for SysTrust Review The remoteness of users from systems requiring an independent objective representative to observe the system on their behalf. The consequences of system unreliability. The four conditions above may contribute individually to the need for assurance services related to the reliability of an entity’s key information system(s) and they may also interact to increase the need for such assurance.

89. November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #17-89 Symptoms of System Unreliability Frequent system failures Failure to prevent unauthorized access Loss of data integrity Serious maintenance problems