7 Software Development Security

2,911 views

Published on

Software Development Security Domain

1 Comment
4 Likes
Statistics
Notes
  • helo Dear How i can mail you regarding the information which i need it
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
2,911
On SlideShare
0
From Embeds
0
Number of Embeds
23
Actions
Shares
0
Downloads
279
Comments
1
Likes
4
Embeds 0
No embeds

No notes for slide
  • Unauthorized Access: identification and authentication of users are not consistently enforced… a systems engineering problem.Improper Usage: Information assets are not always identified and inventoried… another security engineering problem. We don’t always know the level of protection necessary. One thing that DoD does pretty well is having a security classification guide for each project.Under investigation: Those are the incidents that nobody knows exactly the cause and impact. During May of ‘08, MITRE’s Bill Neugent had presented a talk to my sponsor – IRS on the fact that cyber threats are getting more “sophisticated” – no longer just hackers, we now have insiders, organized crime, terrorists, criminals perpetrating fraud. Security engineers needs to understand the MISSION, BUSINESS OBJECTIVES, and OPERATIONAL PROCESSES.
  • Unauthorized Access: identification and authentication of users are not consistently enforced… a systems engineering problem.Improper Usage: Information assets are not always identified and inventoried… another security engineering problem. We don’t always know the level of protection necessary. One thing that DoD does pretty well is having a security classification guide for each project.Under investigation: Those are the incidents that nobody knows exactly the cause and impact. During May of ‘08, MITRE’s Bill Neugent had presented a talk to my sponsor – IRS on the fact that cyber threats are getting more “sophisticated” – no longer just hackers, we now have insiders, organized crime, terrorists, criminals perpetrating fraud. Security engineers needs to understand the MISSION, BUSINESS OBJECTIVES, and OPERATIONAL PROCESSES.
  • As with all the CMM models, it is measured by a set of defined practice areas. For SSE-CMM, the practices are divided into two domains: Security Base Practices and Project & Organization Base Practices.In the Security Base Practices domain, we have 11 practices which are very much captured in our ISSE Process.In the Project & Organizational Base Practices, we also have 11 practices which are some what captured in PMBOK.
  • As with all the CMM models, it is measured by a set of defined practice areas. For SSE-CMM, the practices are divided into two domains: Security Base Practices and Project & Organization Base Practices.In the Security Base Practices domain, we have 11 practices which are very much captured in our ISSE Process.In the Project & Organizational Base Practices, we also have 11 practices which are some what captured in PMBOK.
  • None Persistent: Alice often visits a particular website, which is hosted by Bob. Bob's website allows Alice to log in with a username/password pair and store sensitive data, such as billing information.Mallory observes that Bob's website contains a reflected XSS vulnerability.Mallory crafts a URL to exploit the vulnerability, and sends Alice an email, enticing her to click on a link for the URL under false pretenses. This URL will point to Bob's website, but will contain Mallory's malicious code, which the website will reflect.Alice visits the URL provided by Mallory while logged into Bob's website.The malicious script embedded in the URL executes in Alice's browser, as if it came directly from Bob's server (this is the actual XSS vulnerability). The script can be used to send Alice's session cookie to Mallory. Mallory can then use the session cookie to steal sensitive information available to Alice (authentication credentials, billing info, etc.) without Alice's knowledge.Persistent:Mallory posts a message with malicious payload to a social network. When Bob reads the message, Mallory's XSS steals Bob's cookie.Mallory can now hijack Bob's session and impersonate Bob.
  • http://xkcd.com/327/
  • 7 Software Development Security

    1. 1. CISSP® Common Body of Knowledge Review: Software Development Security Domain Version: 5.9CISSP Common Body of Knowledge Review by Alfred Ouyang is licensed under the Creative CommonsAttribution-NonCommercial-ShareAlike 3.0 Unported License. To view a copy of this license, visithttp://creativecommons.org/licenses/by-nc-sa/3.0/ or send a letter to Creative Commons, 444 Castro Street, Suite900, Mountain View, California, 94041, USA.
    2. 2. Learning ObjectiveSoftware Development Security Domain Software Development Security domain refers to the controls that are included within systems and application software and the steps used in their development (e.g., SDLC). Software refers to system software (operating systems) and application programs such as agents, applets, software, databases, data warehouses, and knowledge-based systems. These applications may be used in distributed or centralized environments. The candidate should fully understand the security and controls of the system development process, system life cycle, application controls, change controls, data warehousing, data mining, knowledge-based systems, program interfaces, and concepts used to ensure data and application integrity, security, and availability. Reference: CISSP CIB, January 2012 (Rev. 2) -2-
    3. 3. Application Development SecurityCurrent State of Insecurity in Federal Agencies • “The 25 major agencies of Federal government continue to improve information security performance relative to C&A rate and testing of contingency plans and security controls.” – OMB FY 2008 Report to Congress on Implementation of FISMA. % of System with a: FY 2005 FY 2006 FY 2007 FY 2008 Certification and Accreditation 85% 88% 92% 96% (C&A) Tested Contingency Plan 61% 77% 86% 92% Tested Security Controls 72% 88% 95% 93% Total Systems Reported 10,289 10,595 10,304 10,679 • Yet, “20 of 24 major agencies indicated that inadequate information security controls were either a significant deficiency or a material weakness.”* * Source: GAO-08-496, Information Security– Although Progress Reported, Federal Agencies Need to Resolve Significant Deficiencies, February 14, 2008 3
    4. 4. Application Development SecurityCurrent State of Insecurity in Federal Agencies • # of security incidents keeps growing*… Security Incidents - FY05 to FY11 Number of Incidents Reported by Federal Agencies 80000 70000 60000 50000 40000 30000 20000 10000 0 FY’05 FY’06 FY’07 FY’08 FY’09 FY’10 FY’11 1. Unauthorized Access 304 706 2,321 3,214 4,848 5,782 6,959 2. Denial of Service 31 37 36 26 48 28 33 3. Malicious Code 1,806 1,465 1,607 2,274 6,977 12,926 11,556 4. Improper Usage 370 638 3,305 3,762 6,148 7,334 8,372 5. Scans/Probes/Attempted Access 976 1,388 1,661 1,272 1,152 69,832 66,057 6. Under Investigation 82 912 4,056 7,502 10,826 11,534 13,601 * Source: US-CERT 4
    5. 5. Application Development SecurityCurrent State of Insecurity in COTS Software • The software flaw statistics are also trending upward… 60000 50000 40000 30000 20000 10000 0 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 # of Vulnerabilities/year Total # of Vulnerabilities in NVD • According to an analysis by Software Engineering Institute (SEI): “Most software security vulnerabilities arise from common causes; more than 90 percent are caused by known software defect types.” Where the top 10 causes account for about 75 percent of all vulnerabilities. * Source: National Vulnerability Database (http://nvd.nist.gov) -5-
    6. 6. TopicsSoftware Development Security Domain • Governance & Management • System Life Cycle and Security • Software Environment and Security Controls • Programming Languages • Database and DB Warehousing Vulnerabilities, Threats, and Protections • Software Vulnerabilities and Threats -6-
    7. 7. Governance & ManagementInformation Security Governance • Policy. Management directives that establish expectations (goals & objectives), and assign roles & responsibilities. • Standards. Functional specific mandatory activities, actions, and rules. • Procedure. Step-by-step implementation instructions. • Baseline (or Process). Mandatory description of how to implement security packages to ensure consist security posture. • Guidelines. General statement, framework, or recommendations to augment baselines or procedures. Law, Regulations Law, Regulations Executive Orders Organizational DoD Directives Policies Joint Doctrines Functional DoD Instructions Implementation DoD Agency Policies Policies & MOUs Process & Procedure: Baselines: Guidelines: Process & Baselines Standards: Standards Guidelines DITSCAP / MAC Security DISA STIGs Procedure (/ Process) DoD Regulations DIACAP Controls NSA SNAC SCGs SIPRNet CAP -7-
    8. 8. Governance & ManagementFederal Enterprise Architecture (FEA) Framework • Federal Enterprise Architecture Framework (FEAF) focuses on BUSINESS Reference: Federal Enterprise Architecture Consolidated Reference Model, May 2005 -8-
    9. 9. Governance & ManagementCOBIT Governance Framework • Control Objectives for Information and related Technology (COBIT) is an IT Governance Framework created by Information Systems Audit and Control Association (ISACA) • COBIT controls can encompass: – Information security controls (e.g., NIST SP 800-53, CNSS 1253, ISO/IEC 17799 IT) – IT processes management frameworks (e.g., ITIL, CMMI, ISO/IEC 2000 IT Service Management, PMBOK) • COBIT governance is composed of 5 focus areas: – Strategic alignment – Value delivery – Resource management – Risk management – Performance measurement Reference: COBIT 4.1 (http://www.isaca.org/) 9
    10. 10. Governance & ManagementAugment IT Governance with Information Security • Information security is an ubiquitous practice… Interrelationship of COBIT InfoSec Controls: Components… • Management • Operational • Technical Reference: COBIT 4.1 (http://www.isaca.org/) 10
    11. 11. Governance & ManagementISO/IEC 15288:2008, System Life Cycle Processes • ISO/IEC 15288* Agreement Processes Project Processes Technical Processes Stakeholder Project Planning encompasses: Acquisition Process Process Requirements Definition Process – Systems/software Supply Process Project Assessment and Control Process Requirements Analysis Process engineering processes Decision Management Architecture Design Process Process (Technical Processes) Organizational Risk Management Implementation – Project management Project-Enabling Processes Process Process processes Life Cycle Model Management Process Configuration Management Process Integration Process – Project support Infrastructure Information Verification Process Management Process Management Process infrastructure (Organizational Project- Project Portfolio Management Process Management Process Transition Process Enabling Processes) Human Resource Validation Process Management Process – Contract/business Quality Management Operation Process management processes Process (Agreement Processes) Maintenance Process Disposal Process * Note: ISO/IEC 15288 is identical to IEEE Std 15288 - 11 -
    12. 12. Governance & ManagementSoftware Capability Maturity Model (SW-CMM) • Level 1: Initial – The software development process is characterized as ad- hoc. Success depends on individual effort and heroics. • Level 2: Repeatable – Basic project management (PM) processes are established to track performance, cost, and schedule. • Level 3: Defined – Tailored software engineering and development processes are documented and used across the organization. • Level 4: Managed – Detailed measures of product and process improvement are quantitatively controlled. • Level 5: Optimizing – Continuous process improvement is institutionalized. - 12 -
    13. 13. Governance & ManagementISO/IEC 21827: SSE-CMM …(1/2) • System Security Engineering – Capability Maturity Model (SSE-CMM) 0 1 2 3 4 5 Not Performed Planned & Well Qualitatively Continuously Performed Informally Tracked Defined Controlled Improving Base practices performed Committing to perform Defining a standard Establishing measurable Establishing quantitative Planning performance process quality goals process effectiveness goals Tracking performance Tailoring standard process Determining process Improving process Verifying performance Using data capability to achieve goals effectiveness Perform a defined process Objectively managing performance - 13 -
    14. 14. Governance & ManagementISO/IEC 21827: SSE-CMM …(2/2) • SSE-CMM is composed of two domains: – Security Base Practices (11 x Process Areas) – Project & Organizational Base Practices (11 x Process Areas) • Security Base Practices • Project & Organizational Base Practices – Administer Security Controls – Ensure Quality – Assess Impact – Manage Configuration – Assess Security Risk – Manage Project Risks – Assess Threat – Monitor & Control Technical Effort – Assess Vulnerability – Plan Technical Effort – Build Assurance Argument – Define Organization’s SE Process – Coordinate Security – Improve Organization’s SE Process – Monitor Security Posture – Manage Product Line Evolution – Provide Security Input – Manage SE Support Environment – Specify Security Needs – Provide Ongoing Skills & Knowledge – Verify & Validate Security – Coordinate with Suppliers - 14 -
    15. 15. Information Security ConceptsMeasure of Effectiveness – Assurance Requirements • Meeting the assurance requirements is a part of “due diligence” processes. Information Security Requirements – Example: SC-3: Security Function Isolation. The information system isolates security functions from non-security functions. Assurance Functional Requirements Requirements • Meeting the functional For establishing For defining security behavior of the IT confidence that the requirements is a part of “due product or system. security function will perform as intended. care” processes. – Example: • VLAN technology shall be created to partition the network into multiple mission-specific security domains. • The integrity of the internetworking architecture shall be preserved by the access control list (ACL). - 15 -
    16. 16. Governance & ManagementAssurance Requirements – Civil Agencies …(1/3) CLASS FAMILY IDENTIFIER Reference: NIST SP800-53, Rev 3, Recommended Security Controls for Risk Assessment RA Planning PL Management System and Services Acquisition SA Certification, Accreditation, and Security Assessment CA Program Management PM Personnel Security PS Physical and Environmental Protection PE Contingency Planning CP Configuration Management CM Operational Maintenance MA Federal Information Systems System and Information Integrity SI Media Protection MP Incident Response IR Awareness and Training AT Identification and Authentication IA Access Control AC Technical Audit and Accountability AU System and Communications Protection SC - 16 -
    17. 17. Governance & ManagementAssurance Requirements – DoD …(2/3) DoDI 8500.2, Information Assurance (IA) Implementation • Confidentiality Controls + Controls for Integrity & Availability (i.e. Mission Assurance Category (MAC)) CONFIDENTIALITY INFORMATION SUBJECT AREA NAME ABBREVIATION NUMBER OF CONTROLS CLASSIFICATION E4.A1 (MAC I) CONTROLS IN E4.A2 (MAC II) SUBJECT AREA E4.A4 (High) Classified Information E4.A5 (Medium) Sensitive Information E4.A3 (MAC III) Security Design & DC 31 E4.A6 (Basic) Public Information Configuration Identification & Authentication IA 9 Enclave & Computing EC 48 Environment Enclave Boundary Defense EB 8 Physical & Environmental PE 27 Personnel PR 7 Continuity CO 24 Vulnerability & Incident VI 3 Management - 17 -
    18. 18. Governance & ManagementAssurance Requirements – Industry …(3/3)ISO/IEC 27001:2005, Information Technology – SecurityTechniques – Security Management System – RequirementsCONTROL CATEGORY SUB-CATEGORY OF CONTROLSSecurity Policy Information security policyOrganization of Information Security Internal organization; External partiesAsset Management Responsibility for assets; Information classificationHuman Resource Security Prior to employment; During employment; Termination or change of employmentPhysical and Environmental Security Secure areas; Equipment security Operational procedures and responsibilities; Third party service delivery management; System planning andCommunications and Operations acceptance; Protection against malicious and mobile code; Back-up; Network security management; MediaManagement handling; Exchange of information; Electronic commerce services; Monitoring Business requirement for access control; User access management; User responsibilities; Network accessAccess Control control; Operating system access control; Application and information access control; Mobile computing and teleworkingInformation Systems Acquisition, Security requirements of information systems; Correct processing in applications; Cryptographic controls;Development, and Maintenance Security of system files; Security in development and support processes; Technical vulnerability managementInformation Security Incident Reporting information security events and weaknesses; Management of information security incidents andManagement improvementsBusiness Continuity Management Information security aspects of business continuity management Compliance with legal requirements; Compliance with security policies and standards, and technicalCompliance compliance; Information system audit considerations - 18 -
    19. 19. TopicsSoftware Development Security Domain • Governance & Management • System/Software Life Cycle and Security • Software Environment and Security Controls • Programming Languages • Database and DB Warehousing Vulnerabilities, Threats, and Protections • Software Vulnerabilities and Threats - 19 -
    20. 20. System/Software Development Life Cycle (SDLC)System Development Life Cycle (SDLC) Models andProcesses • Waterfall Development Models – Waterfall: DoD-STD-2167A (replaced by MIL-STD-498 on 11/1994). – Modified Waterfall: MIL-STD-498 (cancelled on 5/1998) • Iterative Development Models – Boehm’s Spiral Model. – Rapid Application Development (RAD) & Joint Application Development (JAD) • SDLC Processes – ISO/IEC 12207, Software Life Cycle Processes (IEEE/EIA 12207 US implementation) (based on MIL-STD-499B) – ISO/IEC 15288, Systems Engineering – System Life Cycle Processes (IEEE std 1220 – 2005, US implementation) - 20 -
    21. 21. System/Software Development Life Cycle (SDLC)Waterfall Development Models • Classic Waterfall: • Modified Waterfall: DoD-STD-2167A MIL-STD-498 Requirements Requirements Design Design Implementation Implementation Verification Verification Maintenance Maintenance - 21 -
    22. 22. System/Software Development Life Cycle (SDLC)Boehm’s Spiral Model Reference: http://csse.usc.edu/people/barry.html - 22 -
    23. 23. System/Software Development Life Cycle (SDLC)Rapid Application Development (RAD) Model • Iterative, but spiral cycles are much smaller. • Risk-based approach, but focus on “good enough” - S. McConnel, Rapid Development: Taming Wild Software Schedules outcome. • SDLC fundamentals still apply… – Requirements, configuration, and quality management, - http://www.cs.bgsu.edu/maner/domains/RAD.htm design process, coding, test & integration, technical and project reviews etc. Reference: - 23 -
    24. 24. System/Software Development Life Cycle (SDLC)Incremental Commitment Model Reference: B. Boehm, J.A. Lane, Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering, CrossTalk, October 2007. - 24 -
    25. 25. System/Software Development Life Cycle (SDLC)History of Systems/Software Engineering ProcessStandards Reference: http://en.wikipedia.org/wiki/Systems_engineering_process - 25 -
    26. 26. System/Software Development Life Cycle (SDLC)Software & System Engineering Management Processes • There are more and more “software-intensive” systems… – Systems are getting more complex. Hardware problems are often addressed through software; – Operating environments are stochastic. Software are more flexible than hardware. • As SDLC models evolves, management processes are evolving too… – DoD-STD-2167A: Waterfall SDLC + SE Process – MIL-STD-498: Modified Waterfall SDLC + SE Process – IEEE 1220: System Engineering Process – ISO 12207: Software + System Engineering Mgmt. Process – ISO 15288: System Engineering Mgmt. Process - 26 -
    27. 27. System/Software Development Life Cycle (SDLC)DoD-STD-2167A – System Engineering Process Software Process Software Acceptance Implementation Installation Support Project System System System System Requirements Architecture Qualification Integration Analysis Design Testing System Software Software Requirements Qualification Analysis Testing Software Software Architectural Integration Design Software Detailed Software Coding Design & Testing Software Reference: DoD-STD-2167A, Defense System Software Development, February 29, 1988 - 27 -
    28. 28. System/Software Development Life Cycle (SDLC)ISO/IEC 15288:2008, System Life Cycle Processes • ISO/IEC 15288* Agreement Processes Project Processes Technical Processes Stakeholder Project Planning encompasses: Acquisition Process Process Requirements Definition Process – Systems/software Supply Process Project Assessment and Control Process Requirements Analysis Process engineering processes Decision Management Architecture Design Process Process (Technical Processes) Organizational Risk Management Implementation – Project management Project-Enabling Processes Process Process processes Life Cycle Model Management Process Configuration Management Process Integration Process – Project support Infrastructure Information Verification Process Management Process Management Process infrastructure (Organizational Project- Project Portfolio Management Process Management Process Transition Process Enabling Processes) Human Resource Validation Process Management Process – Contract/business Quality Management Operation Process management processes Process (Agreement Processes) Maintenance Process Disposal Process * Note: ISO/IEC 15288 is identical to IEEE Std 15288 - 28 -
    29. 29. System/Software Development Life Cycle (SDLC)ISO/IEC 12207:2008, Software Life Cycle Processes System Context Processes Software Specific Processes Reference: IEEE/IEC 12207:2008, Information Technology Software Life Cycle Processes Agreement Processes Project Processes Technical Processes SW Implementation SW Support Processes Processes Stakeholder Software Software Project Planning Acquisition Process Requirements Implementation Documentation Process * Note: ISO/IEC 12207is identical to IEEE Std 12207 Definition Process Process Process Project Assessment Requirements Analysis Software Requirements Software Configuration Supply Process and Control Process Process Analysis Process Management Process Decision Management Architecture Design Software Architectural Software Quality Process Process Design Process Assurance Process Organizational Risk Management Implementation Software Detailed Software Verification Project-Enabling Process Process Design Process Process Processes Life Cycle Model Configuration Software Construction Software Validation Integration Process Management Process Management Process Process Process Infrastructure Information Software Integration Software Review Verification Process Management Process Management Process Process Process Project Portfolio Software Qualification Management Process Transition Process Software Audit Process Management Process Testing Process Human Resource Software Problem Validation Process Validation Process Management Process Resolution Process Quality Management Process Operation Process Software Reuse Processes Domain Engineering Reuse Program Maintenance Process Process Management Process Reuse Asset Disposal Process Management Process - 29 -
    30. 30. System/Software Development Life Cycle (SDLC)IEEE std 1220, System Engineering Process IEEE 1220: System Life Cycle (SLC) Development Production Disposal Concept Stage Support Stage Stage Stage Stage Fabrication Assembly, System Preliminary Detailed Integration Definition Design Design & Test (FAIT) - 30 -
    31. 31. System/Software Development Life Cycle (SDLC) IEEE std 1220: System Engineering Process (SEP) • IEEE 1220 defined System Inputs: CONOPS System Context System Engineering Process (SEP) Requirements Process Inputs Requirement and constrain within System Life Cycle Requirements Assessment conflicts Requirements Analysis Output Requirements Baseline (SLC) Requirement trade-offs and impacts Inp ut Validated Requirements Output Requirements Baseline Verification IEEE 1220: System Life Cycle (SLC) ut Inp Decomposition and requirement allocation alternatives Functional Output Functional Architecture Functional Analysis Assessment Development Production Disposal Concept Stage Support Stage Decomposition / allocation Stage Stage Stage ut trade-offs and impacts Inp Verified Functional Output Functional Verification Architecture ut Inp Fabrication Design solution requirements and Assembly, alternatives System Preliminary Detailed Integration Definition Design Design Output Physical Architecture & Test Design Assessment Synthesis (FAIT) Design solution trade-offs ut and impacts Inp Verified Physical Output System Engineering Process (SEP) Design Verification Architecture ut Inp Output:Reference: IEEE STD 1220: Standard for Application and System DevelopmentManagement of the Systems Engineering Process Specification - 31 -
    32. 32. System/Software Development Life Cycle (SDLC)Introducing Security into SDLC Defense Acquisition Life Cycle (DoD 5000) User needs & Materiel Technology Production and Operations & Technology Solution Engineering & Manufacturing Development Development Deployment Support Opportunities Analysis ISO/IEC 15288 Systems and Software Engineering Life Cycle Preliminary Production Utilization Conceptual Design Detailed Design & Development Design Construction System Support Systems Engineering Life Cycle using Structured Analysis and Design Method Concept Development Stage Engineering Development Stage Post Development Stage Concept Concept Advanced Engineering Integration & Operations & Needs Analysis Production Exploration Definition Development Design Evaluation Support Typical System System Preliminary Critical Test Deployment OperationsDecision Concept Requirements Design Design Readiness Readiness Readiness Gates Review Review Review Review Review Review Review (SCR) (SRR) (PDR) (CDR) (TRR) (DRR) (ORR) Information Systems Security Engineering (ISSE) Life Cycle Discover Define Design System Develop Detailed System Design & Implement System & Security Continuous Information Requirements Architecture Security Controls Controls Monitoring Protection Needs Typical C&A System Security Test & System Decision Gates Certification Evaluation Accreditation (ST&E) Software Development: Rational Unified Process Inception Elaboration Construction Transition Business Requirements Analysis & Design Implementation Deployment/CM Modeling McGraw’s Software Security Touch Points Test Test & Test Requirements and Use Cases Architecture & Design Code Feedback From The Fields Plans Results Focus on software Focus on software structural defects weaknesses - 32 -
    33. 33. System/Software Development Life Cycle (SDLC)IEEE std 1220, System Engineering Process IEEE 1220: System Life Cycle (SLC) Development Production Disposal Concept Stage Support Stage Stage Stage Stage Fabrication Assembly, System Preliminary Detailed Integration Definition Design Design & Test (FAIT) - 33 -
    34. 34. System/Software Development Life Cycle (SDLC)Security Considerations in SDLC 1. Initiation Phase (IEEE 1220: Concept Stage) – Survey & understand the policies, standards, and guidelines. – Identify information assets (tangible & intangible). – Define information classification & protection level (security categorization). – Define rules of behavior & security CONOPs. – Conduct preliminary risk assessment. 2. Acquisition / Development Phase (IEEE 1220: Development Stage) – Conduct risk assessment. – Define security requirements and select security controls (categories & types). – Perform cost/benefit analysis (CBA). – Security planning (based on risks & CBA). – Practice Information Systems Security Engineering (ISSE) Process to develop security controls. – Develop security test & evaluation (ST&E) plan for verification & validation of security controls. Reference: NIST SP 800-64 Security Considerations in the Information System Development Life Cycle. - 34 -
    35. 35. System/Software Development Life Cycle (SDLC)Security Considerations in SDLC 3. Implementation Phase (IEEE 1220: Production Stage) – Implement security controls in accordance with system security plan (SSP). – Perform Security Certification & Accreditation of target system. 4. Operations / Maintenance Phase (IEEE 1220: Support Stage) – Configuration management & perform change control. – Continuous monitoring – Perform periodic security assessment. 5. Disposition Phase (IEEE 1220: Disposal Stage) – Preserve information. archive and store electronic information – Sanitize media. Ensure the electronic data stored in the disposed media are deleted, erased, and over-written – Dispose hardware. Ensure all electronic data resident in hardware are deleted, erased, and over-written (i.e. EPROM, BIOS, etc.) Reference: NIST SP 800-64 Security Considerations in the Information System Development Life Cycle. - 35 -
    36. 36. System/Software Development Life Cycle (SDLC)Information Systems Security Engineering (ISSE) Process• Phase 1: Discover Information Protection Needs – Ascertain the system purpose. – Identify information asset needs protection.• Phase 2: Define System Security Requirements – Define requirements based on the protection needs.• Phase 3: Design System Security Architecture – Design system architecture to meet on security requirements. PHASE 1:• Phase 4: Develop Detailed Security Design DISCOVER NEEDS – Based on security architecture, design PHASE 6: PHASE 2: ASSESS EFFECTIVENESS DEFINE SYSTEM security functions and features for the system. REQUIREMENTS• Phase 5: Implement System Security PHASE 3: DESIGN SYSTEM ARCHITECTURE – Implement designed security functions and PHASE 4: features into the system. DEVELOP DETAILED DESIGN• Phase 6: Assess Security Effectiveness USERS/USERS’ REPRESENTATIVES PHASE 5: IMPLEMENT – Assess effectiveness of ISSE activities. SYSTEM Reference: Information Assurance Technical Framework (IATF) Rel. 3.1 - 36 -
    37. 37. System/Software Development Life Cycle (SDLC)Security starts at the beginning… DoDIEEE 1220 Acquisition Key System Engineering Tasks Key Security Engineering Tasks* SDLC User Needs & Task 1: Discover Mission/Business Needs Task 1: Discover Information Protection Needs Technology • Understand customer’s mission/business goals (i.e., initial • Understand customer’s information protection needs (i.e., Opportunities capability, project risk assessment) infosec. risk assessment) • Understand operating environment (i.e., sensitivity of • Understand system concept of operations (CONOPS) information assets, mode of operations)Concept • Create high-level entity-data relations model (i.e., systemStage Concept • Create information management model (IMM) context diagram) Refinement • Define engineering project strategy and integrate into the • Define information protection policy (IPP) and integrate into overall project strategy the project strategy • Create system engineering management plan (SEMP) • Create system security plan (SSP) and integrate into SEMP Milestone A Task 6: Assess project performance in meeting mission/business needs * Reference: Information Assurance Technical Framework (IATF), Release 3.1 PHASE 1: DISCOVER NEEDS PHASE 6: • Key Deliverables PHASE 2: – ASSESS EFFECTIVENESS DEFINE SYSTEM Mission Needs Statement / Project Goal(s) and REQUIREMENTS Objectives PHASE 3: DESIGN SYSTEM ARCHITECTURE – System Capabilities PHASE 4: – Preliminary CONOPS DEVELOP DETAILED DESIGN – Preliminary System Context Descriptions USERS/USERS’ REPRESENTATIVES PHASE 5: IMPLEMENT – Project Risk Assessment – SYSTEM Draft System Engineering Management Plan (SEMP) 37
    38. 38. DoDIEEE 1220 Acquisition Key System Engineering Tasks Key Security Engineering Tasks SDLC Task 2: Define System Requirements Task 2: Define Security Requirements • Refine system context (e.g., functional components) Technology • Define system requirements (e.g., functional, performance, • Select assurance requirements and define security Development operational, support, etc.) functional requirements • Refine CONOPS • Refine IMM and SSP • Baseline system requirements Milestone B Task 6: Assess project performance in meeting mission/business needs Task 3: Design System Architecture Task 3: Design System Security Architecture • Determine & select architecture frameworkDevelopment • Design system architecture and allocate system • Allocate system security requirements to subsystems andStage requirements to subsystems and components (i.e., RTM) service components (i.e., RTM) System • Analyze gaps (i.e., risk assessment) Development Task 4: Develop Detailed System Design (Logical & Task 4: Develop Detailed System Security Design (Logical & Physical) & Physical) Demonstration • Refine entity-data relations model (i.e., UML diagrams, • Refine IMM, embed security controls into system design data-flow, network, etc.) products (i.e., UML, data-flow, network, etc.) • Perform system synthesis analysis to assure system integration (i.e., system design, system architecture, system requirements, and project mission/business needs) Milestone C Task 6: Assess project performance in meeting mission/business needs PHASE 1: DISCOVER NEEDS • Key Deliverables PHASE 2: PHASE 6: ASSESS EFFECTIVENESS – System Requirements DEFINE SYSTEM REQUIREMENTS – Functional Definitions (+ allocation of system PHASE 3: requirements) DESIGN SYSTEM ARCHITECTURE – System Architecture (Contextual + Logical) PHASE 4: DEVELOP – Detailed System Design (Logical + Physical) DETAILED USERS/USERS’ DESIGN – Requirements Traceability Matrix (RTM) REPRESENTATIVES PHASE 5: IMPLEMENT SYSTEM 38
    39. 39. DoDIEEE 1220 Acquisition Key System Engineering Tasks Key Security Engineering Tasks SDLC Task 5: Implement System Design Task 5: Implement Security Controls • Procure system components / construct system • Code/ customize/ configure system functional components • Conduct code inspection/ walk-through/ unit test • Perform system integration Production • Conduct system test • Conduct security test & evaluation (ST&E)Production and Task 6: Assess project performance in meeting mission/business needsStage Deployment • Generate system operations procedure (SOP) and users • Generate SOP (a.k.a. trusted facility manual (TFM)), guide/ manual Incident response plan, business continuity plan (BCP) • Conduct system readiness review • Obtain system certification • Deploy system • Conduct system acceptance test • Assess security effectiveness • Obtain approval to operate (ATO) PHASE 1: DISCOVER NEEDS • Key Deliverables PHASE 2: PHASE 6: ASSESS EFFECTIVENESS – Implement detailed system design – DEFINE SYSTEM REQUIREMENTS Perform test & evaluations (unit, system, security PHASE 3: tests) DESIGN SYSTEM ARCHITECTURE – Test reports PHASE 4: DEVELOP – Standard Operating Procedure (SOP) + User DETAILED DESIGN Manuals USERS/USERS’ REPRESENTATIVES PHASE 5: IMPLEMENT – Deploy system SYSTEM – Conduct acceptance tests 39
    40. 40. System/Software Development Life Cycle (SDLC)Rational Unified Process (RUP) Reference: http://www.ibm.com/developerworks/webservices/library/ws-soa-term2/ - 40 -
    41. 41. System/Software Development Life Cycle (SDLC)Rational Unified Process (RUP) Software Development: Rational Unified Process Inception Elaboration Construction Transition Business Requirements Analysis & Design Implementation Deployment/CM Modeling McGraw’s Software Security Touch Points Test Test & Test Requirements and Use Cases Architecture & Design Code Feedback From The Fields Plans Results • Use cases drives requirements (Business Needs/Concept Exploration) – System, software, and security engineers create operational use cases (e.g., operational, functions, threat, risks models) – Use cases drives operational requirements • System design drives design specifications (Concept Definition/Detailed Design) – Operational requirements are decomposed into system functions and functional requirements – Architecture organizes system functions allocation of functional requirements – Architecture is further decomposed into detailed system design – Detailed system design is explained in design specifications • Design specifications drives programming of software codes (Implementation/Coding/Integration/Testing) – Software components integrated into functional components/subsystems (Unit Testing) – Functional subsystems integrated into system (/systems) (System Testing) – System perform functions that meets the operational needs (Acceptance Testing) • Deployment/transition into operations - 41 -

    ×