SECURITY ENGINEERING TUTORIAL TRACK

SECURITY ENGINEERING TUTORIAL TRACK Tutorials Presented By • Joel E. Sachs The Sachs Groups P.O. Box 6340 Annapolis410-269-7714 sachs@dockmaster.ncsc.mil • Karen M. Ferraiolo Arca Systems, Inc. 8229 Boone Blvd., Suite 610 703-734-5611 ferraiolo@arca.va.com Tutorial Schedule • Part I: Security: Joel E. Sachs » 0800 - 0930 • Part II: Security Engineering: Joel E. Sachs » 1000 - 1130 • Part III: The Security Engineering Capability Maturity Model: Karen M. Ferraiolo » 1330 - 1500 & 1530 - 1700 1 SECURITY ENGINEERING TUTORIAL TRACK Part I: Security Objectives • Gain Intuitive Understanding » “Secure” » “Trustworthy” » “Trusted” • Gain Relational Understandings » » » » Problems Players Issues Approaches Non-Objectives • Learn All the Details • Study INFOSEC History • Become Security Engineers Schedule • 0800 - 0930 2 An Enterprise Enterprise Business Functions Business Capabilities leverage “Virtual System” Applications Data Infrastructure leverage Information System Capabilities 3 Today's System Solutions - Characteristics Complex Distributed/Networked • Interconnected • Interoperating Highly Evolved Applications Highly Evolved User Interfaces 4 Example System Architecture Local DB wksta Server Local DB wksta Server wksta wksta wksta wksta wksta wksta bridge crypto crypto crypto gateway crypto E X T E R N A L S Y T E M S 5 crypto gateway Central DB Server Central File Server Other Central Servers Classif. DBMS Today's System Solutions - Uses Command and Control • Transaction Processing Systems Intelligence • Analytical Systems Logistics Systems Communications Speciality Functions • External Connections Perplexed By: • Interconnections • Interoperations 6 System Views Operational > Functional > Software > Hardware Application + Data + Infrastructure Decomposition View SW Layer View ISO Model System user interface developed applications applications DBMS OS networking - usually COTS application presentation Subsystems session transport network data link physical Components Mechanisms Others: Client-Server, Object-Oriented 7 Goal - “We’re Secure” Who (what) is we? • Enterprise • System » Application » Data » Infrastructure Who says (decides)? • • • • • • • • CEO (Commander) COO (Operational Commander) CIO (Information Systems Director) Employees (e.g., System Users) Utility Providers Vendors Users Customers • Outside Context • Products 8 Secure From/Against/For What At Issue • Threats • Weaknesses • Risks Motivation • Sensitive, Private, or Critical » Processing » Information & Data » Mission or Operation – Old Restrictive View + Keep „em Out – New Enabling View + Let „em In • Multiple Classes (Domains) of » Users » Information & Data » Functions • Strong Management or Operational Control » Enterprise Assets » “Users” 9 Threats, Weaknesses, & Risks Threats • • • • Target Enterprise InstantiateWeaknesses Vulnerabilities in System Aspects Aggregate into System Impacts RisksOperational Impacts • Acceptable 10 What is Security Requirements Areas • Confidentiality • Availability • Assurance • IntegrityResource Protection • No Unauthorized Access • Limited Authorized Access Views • Data • Operation Capability • Information • Functional Capability • System Assets • Attributes • Enterprise • Assurance Strong Management • System Users Implementation • Functions 11 Securing An Enterprise - Who’s Involved Procuring Agency (Buyer) • Specifier • IV&V Contractor • Applications Developers • COTS Vendors • Security Agencies / Authorities • Accreditation Team • System Manager(s) System Integrator • Subsystem Integrators • Specialists / Consultants Certification Authority (Certifier) • Certification Team • Security Agencies / Authorities Designated Approving Authority (DAA) (Accreditor) End-User Organization • End-Users • System Security Administrator(s) 12 Consumption Chain • • • Value-Adder Value-Adder Value-Adder • • • General Model COTS Vendor COTS Vendor COTS Vendor Integrator PMO Application Developer End-Users Accreditor Evaluator Evaluator Evaluator Certifier Simplified Example 13 Goal - Secure The Enterprise Enterprise - - - Judge Secure Operation - - - Judge Secure • Assess Environment - - - Decide Trustworthy • Assess System - - - Decide Trustworthy Design - - - Engineer Trustworthiness Implement - - - Engineer & Test Trustworthiness Select COTS - - - Select Features & Trusted-ness Avail COTS - - - Produce Features & Trusted-ness 14 When are We Secure ? What is Necessary & Sufficient to Decide? • • • • • Requirements Design Implementation Operation Maintenance What Kind of Decision? • Technical or Management • Objective, Subjective, or JudgmentalWhat to Decide On? • Enterprise • Operational Environment • Information System 15 Must Resolve Multiple Security Concerns Acquisition Enterprise Integration Certification Accreditation Operation System Subsystem Component Mechanism Note: Other considerations personnel, physical, administrative Note: Other Acquisition/Development Models: Evolutionary, Incremental, etc. 16 INFOSEC Areas Operations Security Information Security Physical Security Personnel Security Administrative Security Communications Security Emanations Security Computer Security 17 Establishing Assurance - Claims & Evidence 1st Party Processes Specific Techniques General Methods 2nd Party 3rd Party People Individuals Organizations Tools Specific Tools Engineering Environments Results (Products/Systems) Interim End 18 Establishing Assurance - Roles Roles Develop Assess Concur Approve Accept Development Phases Concept Architecture Detailed Design Product Selection Implementation Integration & Test Operation 19 Trust Development/Acquisition Mode First-Party • Develops Third-Party • Assesses Second-Party • Approves • Accepts Others • Concur – Interaction of • Security Engineering • Risk Analysis • Risk Management/Acceptance 20 Implications for Players Developed by: Procuring Agency System Integrator Specifier Subsystem Integrators Applications Developers Specialists/Consultants COTS Vendors Approved by: Procuring Agency Designated Approving Authority Developed for: End-User Organization End-Users System Manager (s) System Security Officer (s) 21 IV&V Contractor Certification Body Security Agencies System Weaknesses System Context • Physical • Procedural • User System • • • • System Subsystem Component Mechanism » Product » Software » Hardware 22 Threat Categories • Irresponsibility • Probing • Penetration Examples • Password Disclosure • ByPass of Controls • Privileges Motivation • Accidental • Malicious Perpetrators • Nature • Users » Individuals » Spawned Processes • Outsiders » Individuals » Spawned Processes 23 Example Threat Attacks Denial of Service wksta wksta Local DB wksta Server Access Control wksta wksta Local DB wksta Server Identification and Authentication Misrouting wksta wksta wksta bridge Wiretapping crypto crypto crypto gateway Cryptanalysis crypto Replay E X T E R N A L S Y S T E M S 24 crypto gateway Central DB Server Mislabeling / Covert Channels Central File Server Other Central Servers Classif. DBMS Viruses Risks (Impacts) Customer Mi ssion Mi ssion Assets Mi ssion Threats Developer System Assets System Threats Engineering Susce ptibilities Vulnerabil ities System Im pacts Customer Op erational Im pacts = Mis sion Risks 25 Primary Concerns of the Players End-User • Performing Mission successfully >>> Secure Concept of Operations PMO • Buying a usable System Solution >>> System Spec (what req‟t), SOW (how req‟t), System Security Policy Integrator / Application Developer • Delivering an acceptable System Solution >>> Security Designs, SecurityCertifier • Assuring System Weaknesses >>> Security VerificationAccreditor • Accepting Operational Risks >>> Risk Assessment, Cost-Benefit-Impact Analyses 26 Trust Paradigm Policy Mechanism Assurance 27 Assurance Demonstrate Mechanisms Enforce Policy • Correctness • Effectiveness • Workmanship Types of Evidence • Security Architecture & Design Specifications • Configuration Control & Management » Design » Implementation • • • • Analyses of Security Specifications Security Testing Results Penetration Testing Results Process, Methods, Procedures Note: 1st-Party Evidence Supports 3rd-Party Assessment • Both Support 2nd-Party Approval & Acceptance 28 Mechanism Need to Define Security Mechanisms • • • • • Enterprise Level System Level Subsystem Level Component Level Mechanism Level Secure Concept of Operations Security Architecture Security Designs Implementation / Product Selection Implementation / Mechanism Selection 29 Policy Enforced Security Rules • • • • • • • • Logical Structure The Simple Rule Explanation Rationale National & International Law Corporate Policy Enterprise Policy System Policy Policy Flow-Down Product Policy(s) Note: Most Interested in the Information System Security Policy 30 Trust Analyses Design Analyses Techniques • VerificationModeling • Flow Analysis • Fault Analysis • Access Analysis Testing • Security Testing • Threat Analysis • Impact Analysis • PenetrationRisk Analysis • Vulnerability Analysis Note: Analyses can be Formal (mathematical) or Informal 31 Trusted Concepts Least Privilege Object ReUse Reference Monitor Trusted Path Trusted Process Trusted Recovery Trusted Distribution System Security Officer(s) 32 Trust Techniques Access Control • • • • • MAC (e.g., No “Read Up”, No “Write Down”) DAC PrivilegesLabeling Classifications Clearances Minimization/Simplification 33 Trust Notions Entities • • • • • • • • Subjects Objects Trusted Untrusted Dedicated System High Compartmented Multilevel Modes of Operation Enforceable Boundaries • Security Perimeters • Trusted Computer Bases (TCBs) • Security Kernel 34 SECURITY ENGINEERING TUTORIAL TRACK Part II: Security Engineering Objectives • Gain Intuitive Understanding » Key Processes » Key Practices • Gain Relational Understandings » Development » Certification » Accreditation Non-Objectives • Learn All the Details • Study INFOSEC History • Become Security Engineers Schedule • 1000 - 1130 35 Security Engineering Activities - Business Operation Definition of Security Problem • Understanding of Mission • Definition of Operational Concept Identification of Assurance Needs Definition of Security Needs • Customer‟s • User‟s Identification of Threats & Acceptable Risk Levels 36 Security Engineering Activities - System System • • • • • • • • Rapid Development of Alternative Security Solutions Reduction of Functional & Security Complexity Development of System Assurance Evidence IdentificationSub-System Rapid Development of Alternative Security Solutions Reduction of Functional & Security Complexity Development of Sub-System Assurance Evidence IdentificationInterfaces 37 Security Engineering Activities - Component Component • Selection of COTS Products » Security Features » Security Attributes » Security Concerns • • • • • Development of Component Assurance Evidence IdentificationMechanism Development of Security Mechanisms Development of Mechanism Assurance Evidence Identificationities 38 Trusted Integration • Role of Security • Policy Integration • Assurance Integration • Mechanism Integration • Development Methodology 39 Trusted Development Model Mi ss on Di rective i Securi ty Directives mi ss on req'ts i securit y p olicy Requirem ent s concept of o ps secure co ncept of ope ratio ns syst em le ve l req uire me nts SPM secure enviro n d escripti on de sign STLS* inp ut t o en vironm enta l securit y activitie s Archite ctur e req uire me nts sub s ystem level de sign SPM STLSs Design req uire me nts SPM * comp one nt level Implem enta tion de sign STLSs* COTS product se lection im plem en tatio n sub s ystem int egra tion a nd test Integr ation syst em i nteg rati on a nd t est Key: * optional input to next act ivi ty tes t , analyze, or s how corres pondence to reqts 40 Integration Issues - Policy Need to Derive System Security Requirements • Security Policy » System Specific Security Policy » Environmental Security Description • MLS Concept of Operations » » » » Users Operational Environment Information Objects System and its Functions Security Policy and MLS Con Ops Based On • Applicable Security Directives • Mission Directives and Requirements Address and Trade-off • User Flexibility • Various Security Disciplines 41 Integration Issues - Mechanisms Need to Define Security Mechanisms • System • Subsystem • Component Security Architecture Security Designs Implementation / Selection Minimization/Simplification of TCB • Important to Assurance Additional Functions Examples • Trusted Downgrade • Multiple Security Officers (Hierarchy) 42 Trust Challenges TCB Isolation Object Granularity Product TCB Interfacing Issues Product TCB Extensions Consistent Product Labeling 43 Role of Products Mission Directives System Security Policy System Security Architecture SubSystem Security Policies SubSystem Security Designs Component Security Policies Product Security Features Product Description Product Security Policy Product Security Designs 44 Example Trade-Offs - Alternatives Terminal Terminal Terminal Terminal S T Terminal Terminal S T S Secret DB Top Secret DB T MLS DBMS Fig. 5: MLS DBMS Approach MLS Guard Fig. 1: Air Gap Approach Secret DB Top Secret DB Fig. 3: MLS Guard Approach Terminal Terminal S T MLS Wksta S T One-way Gateway S Top Secret DB T MLS DBMS Secret DB MLS DB FILTER Fig. 6: Integrated MLS Approach Fig. 2: One-Way Gateway Approach Secret DB Top Secret Top Secret DB DB Fig. 4: MLS DB Filter Approach 45 M LS Terminal Terminal Example Trade-Offs - Impacts ONE AIR GAP MLS MLS INTEMLS DBMS WAY GUARD DB GRATED DBMS GUARD FILTER Development Cost Assurance Rqmt's Hardware Redundancy Consistency Difficulties Performance Impact Low Low Low Hi Med Hi Hi Med Med Med Hi Hi Low Low Very Hi Very Hi Low Low Very Low Hi Hi Hi Hi MedHi Low Low Med Hi LowMed LowMed Hi Hi LowMed Hi LowMed Low UI Limitations Other Considerations • • • • Trustworthiness Operational Environment User Flexibility Operational Risks 46 Security Engineering Pervasiveness Classic INFOSEC Techniques OPSEC Informati on Se curi ty IN FOSEC COMSEC COMPU SEC Acq uisi ti o n En terprise Modeli n g Life Cycle Phases Devel op ment Systems En i n g eeri ng Integration Se curi ty En gineering So ftware En i n g eeri ng Operation Hardware En i n g eeri ng Major Engineering Disciplines Mainten ance Te st En i n g eeri ng Devel op er Evaluator Certifier Accr e ti n di g Au thority Bu yer/User Major System Solution Roles 47 Security Engineering Activities Dev eloper Sec urity Concept Sec urity Requirements Sec urity Verification Sec urity Des ign Sec urity Val idati on Sec urity Implementation Securi ty Eng inee ring 48 Assurance Activities Customer User • Ope ratio nal/ Missio n Nee ds • Pe rce ive d Assura nce Ne eds Developer • Se curity Fun cti on Ne eds • Assura nce Ne eds Assura nce Rqmts Unders tand ing ac RCSs n r l wt o n an wi es Th es s t o i f o m a ieaonldt o t ho e c A hal o r d y r e al l pe s on el t h appr pr t e c l a anc r n wi o i a er e Th RCSal ac ar p a . an f o m hal es k ap r ov l d r s c s e A m l wh t he e i t i i phy i al e r x s n n s c or g al f or a i n, n mto i l t e oc t i s t en t v or , i el s r s i i y . m wh a l b l i i at g c n f t ae nc i d n c o e l n o ges o . n o m t r o i f r m t i n a dat r y ac c s s n c ha at m ak n e s t l d oc m da a as r i t i an a pr pr i e l bel us r a s g h u n e por p an ex or . A e a t o a a d t t p ( i al o m e u be d d s at ) wi . . , f p r t an un t r s t e or ur i n . e l r d n u i o o . h i t m a e n m c l l f e Th RCSs hal ot c t al M e A pr e l l AC di o r o r m una r z e n o l s u i f d f c t o , ho i s c o i f r m e, m o i i a i n t or de t r u t i . c s at n u d n Ra i na to l e M AC k ep us r s f r o a c e s i g da a e s e m c s n t au wh h . f o hor ed hey ar e no c l r e an r i t t z c t a e d d Accred iting Authority • Accredit ation • Assura nce Re comme nda tion Evidence Collection and Packaging I n er l k i t c g o n Ca dbo r d r a 2” Ac i vi y t t I dnt i i c t i o e f a n 2” Engineering Activities Re ui r m q e ent s Uner s ani ng d t d Ev dene i c Pl nni g a n Ev dene i c Pa kagng c i Ev dene i c Col ec i o l t n Certifie r • Assura nce Cla ims An alysis • Evide nce Ana lysis • Assura nce Cla ims • Evide nce • Evide nce 49 Security Engineering Coordination Developer Sec urity Enginee ring Group Othe r Engineering Groups Security Engineering Sec urity Coordina tion Ev idence Management Intergroup Coordina tion Sof tware Engineering Perf ormance Hardware Engineering Engineering Ma nagement Groups Security Vulnerability Analysis Rqmt s Management Integrated Project Mgmt Organizational Process Def n Project Planning External Coordination Customer User/ Buy er Certif ier Accrediting Authority 50 Security Engineering Roles & Groups Management • • • • • • • • Security Engineering Manager Project Security Engineering Manager Security Engineering Process Group Coordination Groups Security Engineering Role Security Engineering Groups Other Engineering Groups Security-Related Groups Customer • • • • Buyer Role User Role Accrediting Role Certifier Role Engineering Analysis • Security Validation & Verification Roles • Security Validation & Verification Group 51 Security Engineering Process Structure Engineering Activities • • • • • • Security Concept Security Design Security Requirements Security Implementation Security Validation Security Verification Operational Security Risk Activities • Security Vulnerability Analysis » » » » Mission Analysis Susceptibility Identification Prioritize Vulnerabilities Reduce Vulnerabilities Assurance Activities Assurance Activities • Evidence Management » » » » Assurance Req‟ts Understanding Evidence Activity Identification Evidence Collection Evidence Packaging • • • • Project Planning Project Management Process Definition Process Improvement 52 Summary - What We Did Address Security • Issues & Concerns • INFOSEC is A Critical Emerging Technology Trust is Established (i.e., Engineered) • At Multiple Levels • By Multiple Players Security Engineering • Processes • Roles 53 Summary - What We Didn’t Address Different Development Approaches • Objected Oriented • Evolutionary • Incremental Build Process Assurance • SEI CMM • Security Engineering CMM Engineering Environments & Tools Trust Criteria & Security Guidance 54 SECURITY ENGINEERING TUTORIAL TRACK Part III: The Security Engineering Capability Maturity Model The Need The Model • • • • • • • • • • Overview Development Challenges KPAs and Rationales Assurance Implications Appraisal Methods Piloting Phases Schedule Structure Results of the 1st Workshop The Project Schedule • 1330 - 1500 • 1530 - 1700 55 The Need: Benefits of a Security Engineering CMM to Security Engineering Acquisition • standardized ranking of bidders‟ capabilities • more predictable results and certifications Engineering • structured discipline - with standardized key process areas and practices • achievable process improvements - through incremental steps End-Users • cheaper, better, faster security - in delivered systems and products 56 The Model: Overview Model Focus Model Framework Model Development Approach 57 Focus of the Security Engineering CMM Objectives • security engineering process improvement mechanism • security engineering capability evaluation mechanism • process-based assurance measurement mechanism Target of Model • organizations that develop secure systems • addresses development only -- not operation / maintenance Framework • CMM framework defines steps for process improvement • generalized SEI CMM could provide the basis for any engineering CMM 58 Security Engineering CMM Framework: Maturity Levels The SEI CMM framework defines the steps for process improvement Continuously improving process Optimizing “Work the measures” Managed Predictable process “Measure the work” Standard, consistent process Defined “Work the plan” Repeatable Disciplined process “Plan the work” Initial “Work and work some more” 59 Security Engineering CMM Framework: Maturity Level Structure Maturity Levels indicate Process Capability achieve Goals contain Key Process Areas organized by Common Features address Implementaton or Institutionalization contain Key Practices describe Infrastructure or Activities Common Features •Activities Performed •Commitment to Perform •Ability to Perform •Measurement and Analysis •Verifying Implementation 60 The Security Engineering CMM Approach: a Generalized SEI CMM generalized SEI CMM could provide the basis for any engineering CMM Generalized CMM Management KPAs Organization KPAs Engineering KPAs Specialty CMMs Specialty KPAs Interpreted KPAs 61 Generalized SEI CMM Approach Management Organizational Engineering 5 • Technology Change Management Optimizing • Process Change Management • Quantitative Process Mgmt • Defect Prevention • Security Validation • Security Vulnerability Analysis • Quality Management • Security Concept • Security Verification • Evidence Management • Peer Reviews • Security Requirements • Security Design • Security Implementation 4 3 2 1 Managed Security Engineering CMM KPA Overview • Security Coordination • External Coordination • Integrated Project Mgmt • Intergroup Coordination • Requirements Management • Project Planning • Project Tracking & Oversight • Subcontract Management • Quality Assurance • Configuration Management • Organization Process Focus • Organization Process Defn • Training Program Defined Repeatable Initial Security Engineering • Ad Hoc Processes Generalized SEI CMM Interpreted for Security Engineering 62 The Model: Development Challenges Developing a separate model for security engineering Relationship of security engineering to other disciplines Using the SEI CMM approach 63 Development of a Separate CMM for Security Engineering ISSUE Isolation Process Area Differences APPROACH Coordination KPAs Consistency with Systems Engineering CMM KPAs Advantages • fosters maturity of security engineering practice • recognizes security engineering as a distinct discipline • allows for reliance on organization’s capability as some indicator of assurance 64 Engineering Discipline Relationships ISSUE Organizational Structure Terminology APPROACH model reflects security engineering practice irregardless of organization Process improvement/measurement defintions are consistent with SEI CMM Security definitions are provided Overlapping Activities Engineering process areas are applicable to all engineering disciplines 65 Why Follow the SEI CMM Approach Although the SEI CMM is management/organization focused: the SEI CMM approach provides the appropriate mechanism for security engineering • capability measurement • incremental improvement • discipline establishment and evolution and can be interpreted the SEI CMM approach is proven and generally accepted (SEI-94-TR-013) 66 The Model: KPAs and Rationales KPAs described in terms of grouping practices Management, Organizational, and Engineering practices Rationale for KPA maturity level placement 67 Background What is a KPA? • “a cluster of related activities that, when performed collectively, achieve a set of goals considered important for establishing process capability” • Ideal Characteristics: » » » » » Same level of granularity No overlap in goals Logical grouping Continuously active throughout lifecycle Cover security engineering practices for a development organization 68 What Do Security Development Organizations Do? Developer Organizational Practices • People • Process Organizational Practices Management Practices • Project • Coordination Management Practices Security Engineering Practices • Engineering • Analysis Security Engineering Practices 69 Management KPAs Adapted from the SEI CMM • Removed software-specific practices • Many others have used this approach What’s left? • Generic set of practices good for any organization What’s missing for security? • External Coordination • Security Coordination 70 Coordination Practices Customer Developer Management Groups Other Engineering Groups 3 2 Security Groups 1 71 Organizational KPAs Adapted from the SEI CMM • Removed software-specific practices What’s missing for security? • ? 72 Engineering KPAs Doing the work • Some beginnings in the SEI CMM‟s Software Product Engineering KPA Two parts • General engineering process that applies to all disciplines • Security specific practices Process Assets • Security practices that do not relate to maturity • examples: penetration testing, formal modeling... 73 General Engineering Process Customer Developer Concept Identification Requirements System Needs Design Verification Validation Implementation 74 Security Concept Definition Purpose • to plan, develop, refine, and document a security oriented view of an entire information system, including the people, environment, and automated system Goals • Security Concept Definition activities are planned • Security concept information is developed, refined, and documented • Appropriate assurance evidence is developed and documented 75 Requirements KPAs Customer Developer Requirements Management Project Requirements Baseline Requirements Security Requirements Security Relevant Requirements 76 Security Requirements Purpose • to ensure that the security-related project and system requirements are identified, specified, and refined throughout the project life cycle Goals • Security Requirements activities are planned • All security-relevant requirements are identified and documented • The security-relevant requirements are clearly and properly stated, testable, and independent of implementation • Security-relevant requirements are coordinated with other engineering groups, refined, and maintained throughout the life cycle • Appropriate assurance evidence is developed and documented 77 Security Design Purpose • to identify, analyze, and select trustworthy solutions to engineering problems...ranging in scope from full system architectures to individual components Goals • Security Design activities are planned • Secure system design alternatives are developed, refined, and documented • Secure system design alternatives are selected and agreed to by all affected groups • Appropriate assurance evidence is developed and documented 78 Security Implementation Purpose • to ensure that implementation of the system meets all security-related requirements...including hardware, software, communications, and all parts of the system that enforce security policies Goals • Security Implementation activities are planned • Implementation of the system meets all security-related requirements • Responsibility for performing security-related implementation is shared with other engineering groups • Security engineering assistance is provided to the appropriate engineering groups • Appropriate assurance evidence is developed and documented 79 Security Verification Purpose • to ensure that the system being built correctly meets the project‟s security-related system requirements...by checking that each stage of development properly implements the previous stage Goals • Security Verification activities are planned • Work products are objectively verified to ensure they meet the project‟s security-related system requirements • Appropriate assurance evidence is developed and documented 80 Security Validation Purpose • to ensure that the solution being developed effectively enforces the enterprise security policies and effectively satisfies the enterprise needs Goals • Security Validation activities are planned • Work products are compared to the needs of the business operation to establish their validity • Work products are objectively verified against the applicable system security-related requirements • Appropriate assurance evidence is developed and documented 81 Security Specific Practices Assurance Management • Addresses planning and management of assurance evidence Security Risk Management • Handles operational security risk analysis and management • Distinguished from program risk management 82 Assurance Related Practices Customer Developer Requirements Understanding Assurance Needs Activity Identification Evaluate Evidence Accreditation Decision Evidence Collection Evidence Production 83 Evidence Management Purpose • to manage the identification, planning, packaging, and presentation of assurance claims and evidence Goals • Definition and performance of evidence activities are coordinated with other engineering groups • Evidence activities are planned, described, and well integrated into the engineering process • The assurance package contents include assurance claims and supporting evidence adequate to comply with system security function and assurance requirements 84 Security Risk Related Practices Customer Developer Sys. Threats & Assets Mission Design and Build System Operational Impacts Determine Vulnerabilities System Impacts 85 Security Vulnerability Analysis Purpose • to identify any potential vulnerabilities that could be used to deliberately or inadvertently violate the protection requirements of the system to be fielded Goals • Security vulnerability analysis activities are planned and documented • Security vulnerability analysis activities are performed throughout the development life cycle • Affected groups and individuals are informed of security vulnerability analysis activities and results 86 Security Engineering CMM KPA Overview Management Organizational Engineering 5 4 3 • Technology Change Management Optimizing • Process Change Management • Quantitative Process Mgmt Managed • Defect Prevention • Security Validation • Security Vulnerability Analysis • Quality Management Work the Measures Measure the Work Defined • Security Coordination • External Coordination • Intergroup Coordination • Integrated Project Mgmt • Requirements Management • Project Planning • Project Tracking & Oversight • Subcontract Management • Quality Assurance • Configuration Management • Organization Process Focus • Organization Process Defn • Training Program • Security Concept • Security Verification • Evidence Management • Peer Reviews Work the Plan 2 1 Repeatable • Security Requirements • Security Design • Security Implementation Plan the Work Initial • Ad Hoc Processes Work and Work 87 Level 1 Features • Schedules, budgets, and quality are unpredictable • Lack of management • System security is unpredictable KPAs • None 88 Level 2 Features • Basic management practices are instutionalized • Basic engineering practices are instutionalized KPAs • Security Requirements • Security Design • Security Implementation – Project Planning – Project Tracking & Oversight – Subcontract Management – Quality Assurance – Configuration Management – Requirements Management 89 Level 3 Features • Processes are standardized • Processes are integrated internally and externally • Verification mechanism is in place KPAs • • • • • Security Concept Security Verification Evidence Management Security Coordination External Coordination – Integrated Project Management – Organization Process Focus – Organization Process Definition – Training Program – Peer Reviews – Intergroup Coordination 90 Level 4 Features • Processes are measured quantitatively • Customer‟s needs are measured KPAs • Security Validation • Security Vulnerability Analysis – Quality Management – Quantitative Process Management 91 Level 5 Features • Proactive identification of strengths and weaknesses in the process and the results KPAs • Defect Prevention • Technology Change Management • Process Change Management 92 Security Engineering CMM KPA Maturity Level Placement Summary Process Capability Security Eng. Management Organizational • Process Change Mgmt • Technology Change Mgmt 5 4 3 2 Optimizing • Defect Prevention • Proactive identification of strengths and weaknesses in the process and the results Work the Measures Managed • Processes are measured quantitatively • Customer’s needs are measured • Security Vuln. Analysis • Security Validation • Quant. Process Mgmt. • Quality Management Measure the Work Defined • Processes are standardized • Processes are integrated internally and externally • Verification mechanism is in place • Basic management practices are instutionalized • Basic engineering practices are instutionalized • • • • Evidence Management Security Concept Security Verification Peer Reviews • • • • Integ. Proj. Mgmt Intergroup Coord. Security Coord. External Coord. • Org. Process Focus • Org. Process Def’n • Training Program Work the Plan Repeatable • Security Requirements • Project Planning • Security Design • Project Management • Security Implementation Plan the Work 1 Initial • Schedules, budgets, and qualtiy are unpredictable • Lack of management • System security is unpredictable • None • None Work and Work 93 The Model: Assurance Implications Assurance Definition Relating Process Assurance and System Assurance Metric Issues 94 Assurance Components Security Needs Confidence Claims Evidence People System Process Environment 95 ? Relationship between Process Assurance and System Assurance? Process System Claims Claims Evidence Evidence ?1 Process Assurance ?2 System Assurance ?3 Security Needs ?1: ?2: ?3: ...to system evidence? ...to system assurance? ...to security needs? 96 Relationship between Process Assurance and System Assurance Process System Evidence Claims 1 Claims Quality of... Evidence Process Assurance 2 X System Assurance 3 Security Needs 97 Determining Total Assurance Determine Security Needs Security Needs Determine Mix Measure Assurance Types System Process People Environment 98 Process Assurance Metric Security Engineering CMM as a basis? Assurance-relevance of Security Engineering CMM activities Measurement basis • Maturity Levels • Assessment Profiles 99 Assurance Implications Summary Value of process assurance Security Engineering CMM process assurance contribution Security Engineering CMM as a process assurance metric basis 100 The Model: Appraisal Methods Who will use it For what is it used How is it used When is it used 101 Use of the Security Engineering CMM Who: What: Acquisition Organizations Assess Capability Monitor Contract Capability Evaluations Pre-Award During Contract Engineering Organizations Guide Improvement Analysis Process Process Assessments Continual How: When: 102 Additional Use Issues Methodologies Pilot Trials Questionnaire 103 Ratings Against Multiple Models ? CMM for Hardware SEI CMM for Software ? Generalized ? ? ? ? ? Systems Engineering CMM ? Software Acquisition Maturity Model People Management CMM Security Engineering CMM 104 Ratings Against Multiple Models One Rating • High level achieved in all selected models Multiple Ratings (per specialty CMM) • one rating per specialty engineering CMM • each rating combined with generalized CMM Multiple Ratings (generalized CMM + specialty CMMs) • one rating for each speciality engineering CMM • a separate rating for generalized CMM 105 The Model: Piloting Status Piloting a strawman Indication of interest 106 Status Effort to date focused on model development Current Plans: • Planning and development of appraisal methods needs to be addressed by future Application Working Group • National Council on Systems Engineering (NCOSE) Capability Assessment Working Group (CAWG) provides an example of a piloting program 107 Piloting a Strawman Model is not yet community reviewed or accepted Appraisal methods have not been developed or agreed upon However ... Organizations have indicated interest in using the Security Engineering CMM: • • • • Boeing CSC Harris Information Systems Division Hughes Command & Control Systems Division 108 The Security Engineering CMM Project Project Phases Schedule Project Structure Results of the 1st Workshop 109 Phases of Security Engineering CMM Ongoing Development Security Engineering CMM Vision: O&M widespread improvement of security engineering capability through communitywide involvement/acceptance/adoption Develop Conceive Strawman Working Groups/ Support Infrastructure v1.0 Research/Work on Model Development Draft Pilot Trials Review Current Work 110 Security Engineering CMM Project Schedule (strawman) Apr 93-Aug 93 Aug 93-Dec 94 Research Security Engineering CMM Development Workbook Acceptance and Adoption Plan Security Engineering CMM 1st Public Workshop Draft Model Description Appraisal Methods Plan Training Plan Pilot Trials Plan Security Engineering CMM 2nd Public Workshop Security Engineering CMM Draft Questionnaire Draft Security Engineering CMM Description v1.0 Pilot Trials and Analyses Report 111 18-20 Jan 95 Sep 95 Jan 96 Sep 96 Security Engineering CMM Project Structure Project Technical Coordination Project Technical Coordinator Technical Support Positions Executive Oversight Group Publicity Steering Group Baseline & Coordination Issues Publicity Group Leader Support Positions Project Leader Security Engineering CMM Author Group Author Group Leader Working Group Facilitator Technical Support Positions (one per committee) CCB Project Librarian Security Engineering CMM Application Group Application Group Leader Working Group Facilitator Appraisal Methods KEY: Groups Committees Reviewers Document Development Issues Technical Issues Community Reviewers Technical Support Positions (one per committee) Training Program Community Participant Positions Government Sponsored Support Positions Questionnaire KPA Writing Key Reviewers Key Reviewers Pilot Programs 112 Purpose and Responsibilities of Working Groups Steering Group • Provides Oversight and Overall Direction for the Project • Approves Release of Work Products • Provides Oversight of CCB Author Working Group • Determines solutions to issues • Generates draft model and revisions Application Working Group • Defines and develops appraisal methods • Plans and provides for training • Plans and provides support for pilot trial 113 Project Participation Options Steering Group Member Working Group • • • • Primary Member Secondary Member Leader Committee Leader Key Reviewer Community Reviewer 114 Project Products Primary Products • • • • • • Requirements Document Model Description and Key Practices Appraisal Method Pilot Appraisal Plan Training Plan Questionnaire Supporting Products • Project Master Plan • Guide to Information Exchange • Style Guide 115 The Security Engineering CMM 1st Public Workshop 18-20 January 1995 Preliminary Working Group meetings held • 1st meetings of Steering, Author, and Application Working Groups planned • tasks defined • working group members identified Workshop Participant Survey results: most felt • the Security Engineering CMM effort is important to the security engineering community • the most important issues had been identified Attendees • 80 participants from 61 organizations • acquisition, certification/evaluation, integration/development • software, systems, and security engineering communities 116 The Security Engineering CMM 1st Public Workshop Attending Organizations • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Aegle Research Corp. ALCATEL AGCS, Inc. Air Force Intelligence Warfare Center Air Force Strategic Air Command Allied Bendix Aerospace Allied Signal Communication Systems Allied Signal Technical Services Corp. Arca Systems, Inc. BDM International, Inc. Boeing Defense and Space Group Boeing Information Systems Booz-Allen and Hamilton, Inc. Computer Sciences Corp. Communications Security Establishment Department of Defense Defense Intelligence Agency/8-03 Defense Information Systems Agency/JIEO/A&E DISA/CISS EER Systems Federal Reserve, Reserve Component Automation System Fuentez Systems Concepts General Research Corporation Grumman Data Systems GTE HFSI/SSSO Hampel Consulting Harris Corp. Information Systems Division Hughes, Command and Control Systems Division IDC Government Institute for Defense Analysis • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • ITT Air Space Communications Division Johnson Space Flight Center Loral Federal Systems Gaithersburg Loral Western Development Labs Martin Marietta, Communications Systems Merdan Group, Inc. MITRE Motorola Bovernment and Space Technology Group National Institute for Standards and Technology Naval Research Laboratory National Security Agency Northrop Grumman Oracle Corporation PRC pragma Systems Corp. Resolution Trust Corp. SEMA, INC. The Sachs Groups Science Applications International Corp. Secure Computing Corp. SecureWare Service Central de la Securite des Systemes d‟Information SCSSI Sparta, Inc. Sybase Systems Engineering and Management Associates Systems Research Applications Tax System Modernization Institute/IITRI Telos Federal Systems TRW Integrated Engineering Division UNISYS 117 Points of Contact For project information: Project Leader: John Adams/Marcia Zior NSA, V2 Ft. George G. Meade, MD 20755-6000 410-684-7141 secmm@dockmaster.ncsc.mil For a strawman workbook and workshop information: Publicity Group Leader: Sally Moulton Arca Systems, Inc. 8229 Boone Blvd., Suite 610 703-734-5611 moulton@arca.va.com 118