CISSP® Common Body of Knowledge

Review:
Software Development
Security Domain

Version: 5.9

CISSP Common Body of Knowledge Review by Alfred Ouyang is licensed under the Creative Commons
Attribution-NonCommercial-ShareAlike 3.0 Unported License. To view a copy of this license, visit
http://creativecommons.org/licenses/by-nc-sa/3.0/ or send a letter to Creative Commons, 444 Castro Street, Suite
900, Mountain View, California, 94041, USA.
Learning Objective

Software 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-
Application Development Security

Current 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
Application Development Security

Current State of Insecurity in Federal Agencies

• # of security incidents keeps growing*…
Security Incidents - FY'05 to FY'11
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
Application Development Security

Current 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-
Topics

Software 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-
Governance & Management

Information 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-
Governance & Management

Federal Enterprise Architecture (FEA) Framework

• Federal Enterprise Architecture Framework (FEAF)
focuses on BUSINESS

Reference: Federal Enterprise Architecture Consolidated Reference Model, May 2005

-8-
Governance & Management

COBIT 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

Governance & Management

Augment 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

Governance & Management

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

- 11 -
Governance & Management

Software 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 -
Governance & Management

ISO/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 -
Governance & Management

ISO/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 -
Information Security Concepts

Measure 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 -
Governance & Management

Assurance 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 -
Governance & Management

Assurance 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 -
Governance & Management

Assurance Requirements – Industry …(3/3)

ISO/IEC 27001:2005, Information Technology – Security
Techniques – Security Management System – Requirements
CONTROL CATEGORY SUB-CATEGORY OF CONTROLS
Security Policy Information security policy
Organization of Information Security Internal organization; External parties
Asset Management Responsibility for assets; Information classification
Human Resource Security Prior to employment; During employment; Termination or change of employment
Physical and Environmental Security Secure areas; Equipment security
Operational procedures and responsibilities; Third party service delivery management; System planning and
Communications and Operations
acceptance; Protection against malicious and mobile code; Back-up; Network security management; Media
Management
handling; Exchange of information; Electronic commerce services; Monitoring
Business requirement for access control; User access management; User responsibilities; Network access
Access Control control; Operating system access control; Application and information access control; Mobile computing and
teleworking
Information 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 management
Information Security Incident Reporting information security events and weaknesses; Management of information security incidents and
Management improvements
Business Continuity Management Information security aspects of business continuity management
Compliance with legal requirements; Compliance with security policies and standards, and technical
Compliance
compliance; Information system audit considerations

- 18 -
Topics

Software 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 -
System/Software Development Life Cycle (SDLC)

System Development Life Cycle (SDLC) Models and

Processes
• 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 -
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 -
System/Software Development Life Cycle (SDLC)

Boehm’s Spiral Model

Reference: http://csse.usc.edu/people/barry.html - 22 -
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 -
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 -
System/Software Development Life Cycle (SDLC)

History of Systems/Software Engineering Process

Standards

Reference: http://en.wikipedia.org/wiki/Systems_engineering_process - 25 -
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 -
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 -
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 -
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 -
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 -
 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
Development
Management of the Systems Engineering Process Specification

- 31 -
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 Operations

Decision 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 -
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 -
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 -
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 -
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 -
System/Software Development Life Cycle (SDLC)

Security starts at the beginning…

DoD
IEEE 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., system
Stage 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
 DoD
IEEE 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 framework
Development
• Design system architecture and allocate system • Allocate system security requirements to subsystems and
Stage
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
 DoD
IEEE 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 needs
Stage
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
System/Software Development Life Cycle (SDLC)

Rational Unified Process (RUP)

Reference: http://www.ibm.com/developerworks/webservices/library/ws-soa-term2/
- 40 -
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 -
 System/Software Development Life Cycle (SDLC)

Integrated System/Security Engineering in RAD

w me nt
w me s
ie w

vie it ion

vie it me

vie it ns

vie it ns
nt

nt

nt

nt
v

Re omm atio

Re omm atio
Re omm dat

Re omm lop

w me

w me
Re

C oun

C eve

C per

C per
BR

O
D
OT

F
MS 1 MS 2 MS 3 MS 4 MS 5

t
pt

ep
ce

nc

M
on

Co

CA
w
rm VM III:

em io V:
io C

lo
or :
s W IV
on II:

&
at t I :

to
kf
at ed nt

st rat nt
iti nt

es nt
Pl rust me

Sy teg me
or n

n
n
pl me

fin me

oc me
T cre

In cre
Ex cre

De cre

Pr cre
In

In
In

In

In
fo
Major Activities

Concurrent risk and Initial scoping System life cycle Develop Increment III Develop Increment IV Develop Increment V From preceding
opportunity-driven Concept definition architecture and prototype prototype prototype phase
growth of system CONOPS Objectives
Investment analysis Exercise Increment III Exercise Increment IV Exercise Increment V
understanding and Build to increment prototype prototype prototype
definition 1. Requirements System
plans and Rebaseline system Rebaseline system Transition into analysis Requirements
specifications features & capabilities features & capabilities operations
(if necessary) Plan for future release Requirements
(if necessary)
2. Functional System
Evaluation of OTBR Package Updated PIP Prototype Prototype Prototype definition Architecture
evidence of feasibility Draft PIP CONOPS Updated PIP Updated PIP Operational Transition
to proceed Plan Functions
Conceptual Updated CONOPS System Design
Architecture System Architecture Updated System Reqs. Updated System 3. Physical
System Reqs. & & Functional Specs. Design Baseline System Design
Updated System Reqs. definition
Functional Specs. & Functional Specs. User features requests
System model
Stakeholder review & High, but 4. Design
commitment addressable Acceptable Prototype
validation
Risk? Risk? Risk? Risk?
Negligible
Too high,
unaddressable
To next phase

Adjust scope, priorities, or discontinue

- 42 -
Questions:
• What are the relationships between SDLC models
and SSE-CMM models?
– SDLC describes… to a system acquisition project

– SSE-CMM describes…

• What are the relationships between security controls

models (NIST SP800-53, DoDI 8500.2, ISO/IEC
27001, etc.) and CMM/SSE-CMM models?
– Security assurance requirements provide measurement of…

– CMM utilizes the measurement metrics from security control

models to measure…

- 43 -
Answers:
• What are the relationships between SDLC models
and SSE-CMM models?
– SDLC describes the key engineering process to a system
acquisition project
– SSE-CMM describes the key security and management
processes to a security engineering practice

• What are the relationships between security controls

models (NIST SP800-53, DoDI 8500.2, ISO/IEC
27001, etc.) and CMM/SSE-CMM models?
– Security assurance requirements provide measurements of
management, operational, and technical controls
– CMM utilizes the measurement metrics from security control
models to measure practice maturity

- 44 -
Topics

Software 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

- 45 -
Software Environment and Security Controls

Review of Computer Operations Architecture Model

• Reference monitor is a conceptual abstraction of a
“machine”, system, or software that mediates access
of objects by subjects.

• Trusted computing base is a system of security

controls that meets the confidentiality and integrity
security objectives.

• Secure kernel is a trusted computing base that

implements reference monitor concept.

Reference: Secrets & Lies – Digital Security in a Networked World, Bruce

Schneier, Wiley Publishing, 2000
- 46 -
Software Environment and Security Controls

Reference Monitor
• Reference monitor is performed by a reference
validation mechanism.
• Reference validation mechanism is a system
composed of hardware and software.
• Operating condition principles:
– The reference validation mechanism must be tamper proof.
– The reference validation mechanism must always be
invoked.
– The reference validation mechanism must be small enough
to be subject to analysis and tests to assure that it is correct.
• OS shall be evaluated at TCSEC B2 (i.e. structured
protection) and above.

- 47 -
Software Environment and Security Controls

Trusted Computing Base (TCB)

• The Trusted Computing Base is the totality of
protection mechanisms within a computing system –
hardware, firmware, software, processes, transports

• The TCB maintains the confidentiality and integrity of

each domain and monitors four basic functions:
– Process activation
– Execution domain switching
– Memory protection
– Input/output operation

Reference: DoD 5200.28-STD, Department of Defense Trusted Computer

System Evaluation Criteria (TCSEC), August 15, 1983
- 48 -
Software Environment and Security Controls

Secure Kernel
• Secure kernel is an
implementation of a reference
monitoring mechanism responsible In the kernel model, the inside layer
controls basic OS services, such as:
for enforcing security policy. - memory management,
- security,
- I/O,
- request management, etc.

• It meets the following three (3)

conditions:
– Completeness. All accesses to
information must go through the
kernel.
– Isolation. The kernel itself must be User applications, environment
protected from any type of subsystems, and subsystem DLLs
exist on the outer layers.
unauthorized access.
– Verifiability. The kernel must be
proven to meet design specifications.
- 49 -
Software Environment and Security Controls

Processor Privilege States

• Processor privilege states protect the processor
and the activities that it performs.
• Privileged levels are called rings.

• For example: Intel x86 has 4 privilege ring levels

– Ring 0 contains kernel functions of the OS.
– Ring 1 contains the OS. Ring 0
– Ring 2 contains the OS utilities. OS Kernel

– Ring 3 contains the applications.

0
1
2 Ring 3
Applications
3

- 50 -
Software Environment and Security Controls

Example of Processor Privilege States

VMware ESX
– Hypervisor operates at Ring 0
– Guest OS kernel and OS now
moved to Ring 1
– OS utilities in Ring 2 Ring 0
VMware Hypervisor
– Application in Ring 3
Ring 1
OS Kernel and OS

Ring 2
0 OS utilities
1
2 Ring 3
Applications
3

Reference: VMware ESX I/O Driver Model (http://blogs.vmware.com/performance/2007/11/ten-reasons-why.html) - 51 -

Software Environment and Security Controls

Same principles, but different technology thus different

attacks
• Reference monitoring principles is consistent even
with virtualization: Violation of privilege
– Hypervisor vulnerabilities. Attack of kernel (Ring 0)
– Hypervisor escape vulnerabilities. Violation of isolation of
guest VMs (Ring 0)
– Administrative VM vulnerabilities
• Management server vulnerabilities.
Exploitation of virtualized system
configuration. (Ring 0)
• Management console vulnerabilities.
Attacks of privileged state (Entire TCB)
– Guest VM vulnerabilities. Exploitation of OS vulnerabilities,
but can potentially provide an attack vector to administrative
VM, hypervisor, then other guest VMs (Ring 3/Ring 2 
Ring 1  Ring 0)

Reference: Virtual Reality (http://blogs.vmware.com/virtualreality/2008/06/) - 52 -

Software Environment and Security Controls

Example of Processor Privilege States – Many-to-Many

• VMware vSphere further abstracts the hardware layer

vcenter/index.jsp?topic=/com.vmware.vsphere.intro.doc_41/c_vmware_infrastructure_intr
– Virtual Machine File System (VMFS) for abstraction of data
storage
– vNetwork Distributed Switch (vDS) for abstraction of network
layer
– vMotion for distribution of processing power and high
availability

Reference: http://pubs.vmware.com/vsphere-4-esx-
oduction.html
- 53 -
Software Environment and Security Controls

More complexity, more attack surfaces - Examples

• Hypervisor vulnerability:
– CVE-2010-2070: Xen IA-64 architecture, allows local user to modify
processor status register that can cause DoS. (CVSS: 4.9 [Medium])
• Hypervisor escape vulnerability:
– CVE-2009-1244: VM display function in VMware allows guest OS user to
execute arbitrary code in hypervisor. (CVSS: 6.8 [Medium])
• Administrative VM vulnerabilities:
– CVE-2008-2097: Buffer overflow in VMware ESX management service that
allows remote authenticated users to gain root privileges. (CVSS: 9.0
[High])
– CVE-2008-4281: Directory traversal in VMware ESXi that allows VM
administrators to gain elevated privileges. (CVSS: 9.3 [High])
– CVE-2009-2277: Cross-site scripting (XSS) vulnerability in WebAccess in
VMware VirtualCenter that allows remote attacker to inject arbitrary web
script to steal “context data” such as authentication credentials (CVSS: 4.3
[Medium])
• Guest VM vulnerabilities:
– CVE-2011-2145: VMware Host Guest File System (HGFS) allows Solaris or
FreeBSD guest OS users to modify guest OS files. (CVSS: 6.3 [Medium])
– CVE-2011-2217: ActiveX controls in Internet Explorer allows remote
attacker to execute arbitrary code or corrupt memory in VMware
Infrastructure. (CVSS: 9.3 [High])
Reference:
• T. McNevin, Introduction to Hypervisor Vulnerabilities (Part 1), MITRE, 2009
• B. Williams, T. Cross, Virtualization System Vulnerabilities, IBM X-Force, 2010
• NVD (http://web.nvd.nist.gov/view/vuln/search) - 54 -
Software Environment and Security Controls

Security Controls for Software Environment

• For CISSP Exam, countermeasures are also called
“security controls”…
– Security Controls for Buffer Overflows
– Memory Protection
– Covert Channel Controls
– Cryptography
– Password Protection Techniques
– Inadequate Granularity of Controls
– Control and Separation of Environments
– Time of Check/Time of Use (TOC/TOU)
– Social Engineering
– Backup Controls
– Malicious Code/Malware Controls
– Virus Protection Controls
– Mobile Code Controls
– Sandbox
– Programming Language Support
– Access Controls

Reference: Official (ISC)2 Guide to The CISSP CBK, H. Tipton, et. al., (ISC)2
Press, Auerbach Publications, 2007. - 55 -
Software Environment and Security Controls

Security Controls for Buffer Overflow

• One of the oldest and most common problems to
software.
• A buffer overflow occurs when a program or process
tries to store more data in a buffer (temporary data
storage area) than it was intended to hold.
• Vulnerability is caused by lack of parameter checking or
enforcement for accuracy and consistency by the
software application or OS.
• Countermeasure:
– Practice good SDLC process (code inspection & walkthrough).
– Programmer implementing parameter checks and enforce data
rules.
– Apply patches for OS & applications.
– If available, implement hardware states and controls for memory
protection.
– Buffer management for OS.
- 56 -
Software Environment and Security Controls

Memory Protection
• Memory protection is enforcement of access control
and privilege level to prevent unauthorized access to
OS memory.
• Countermeasures:
– Ensure all system-wide data structures and memory pools
used by kernel-mode system components can only be
accessed while in kernel mode.
– Separate software processes, protect private address space
from other processes.
– Hardware-controlled memory protection
– Use Access Control List (ACL) to protect shared memory
objects.

- 57 -
Software Environment and Security Controls

Covert Channel Controls*

• Covert channel is an un-controlled information flow
(or unauthorized information transfer) through hidden
communication path(s).
– Storage channel
– Timing channel
• Countermeasure steps:
– Identify potential covert channel(s)
– Verify and validate existence of covert channel(s)
– Close the covert channel by install patch or packet-filtering
security mechanism.

* Note: While the definition of covert channel may be old, it is considered as “fundamental” in CISSP CBK.

Reference: NCSC-TG-30, A Guide To Understanding Covert Channel Analysis of Trusted System

- 58 -
Software Environment and Security Controls

Covert Channel Controls*

• Countermeasure for covert channel:
– Information Flow Model is a variation of access control matrix
– Information Flow Model is based on Object Security Levels.
– Object-to-object information flow is constrained in accordance with
object’s security attributes.

Object A B C D E F G
A N/A X
B N/A X
C X N/A
D N/A X
E X N/A
F N/A X
G X N/A

- 59 -
Software Environment and Security Controls

Cryptography
• Cryptography provides confidentiality, integrity,
authentication, and non-repudiation in information
operations.
– Asymmetric Key Cryptography
– Because of slow cipher operation speed, it is mostly used for
key management function.
– Symmetric Key Cryptography
– Because of speed, symmetric-key cryptosystems are used for
crypto. operations. E.g. SSL/TLS at Transport-level
(communication path), e-mail & SOAP messages at message-
level.
– Hash Function
– Message Digest
– Message Authentication Code (MAC)
– Key-hashed MAC (HMAC)
– Digital Signature
- 60 -
Software Environment and Security Controls

Security Controls: Password Protection Techniques

• Password Structure
– Password length
– Password complexity: a mix of upper/lowercase letters,
numbers, special characters
– Not using common words found in dictionary
• Password Maintenance
Set password lifetime limits & policy…
– Password change in <90> days
– Password can not be reused within <10> password changes
– <One> change to <every 24 hr.>
– Password file must be encrypted and access controlled.

- 61 -
Software Environment and Security Controls

Granularity of Controls
• Separation of duties means that a process is
designed so that separate steps must be performed
by different people (i.e. force collusion)
– Define elements of a process or work function.
– Divide elements among different functions
• Least privilege is a policy that limits both the system’s
user and processes to access only those resources
necessary to perform assigned functions.
– Limit users and system processes to access only resources
necessary to perform assigned functions.
• Separation of system environments.
– Development environment.
– QA/test environment.
– Production or operational environment.
- 62 -
Software Environment and Security Controls

Other Security Controls

• Social Engineering
– Countermeasure: User security awareness training.
• Backup, Malicious Code/Malware, Virus Protection
Controls
– Countermeasures:
• Install & use anti-virus system, H-IDS.
• Enable access control to critical system files.
• Tape backups, access control of media.
• Encrypt sensitive information for confidentiality & integrity.
• Mobile Code Controls
– Install Sandbox for access control of mobile codes.
– Example: Java “containers” or Java Virtual Machine (JVM).
• Java applets running in Web browser.
• Applications using Java Remote Method Invocation (RMI) to
run Java Beans.
- 63 -
Software Environment and Security Controls

Security Controls – Access Controls

• Discretionary access control (DAC)
– Information owner determines who has access & what
privileges they have.
• Mandatory access control (MAC)
– Information classification & system determine access.
– Access decision based on privilege (clearance) of subject &
sensitivity (classification) of object (file).
– Requires labeling (or data tag)
• Access Control/Capability Matrix
– Implement through the use of ACL.
• View-based Access Control
– Authorization of specific views by tables, columns, and key
sets.

- 64 -
Questions:
• What are the three operating condition principles for
a reference monitor?
–
–
–

• What are the three operating conditions for a secure

kernel?
–
–
–

- 65 -
Answers:
• What are the three operating condition principles for
a reference monitor?
– must be tamper proof
– must always be invoked
– subject to analysis and tests

• What are the three operating conditions for a secure

kernel?
– Completeness (must always be invoked)
– Isolation (must be tamper proof)
– Verifiability (each operations shall be subject to analysis and
tests)

- 66 -
Questions:
• What causes buffer overflow?
–

• Why a good information flow model is a good tool for

supporting the identification of covert channel?
–

- 67 -
Answers:
• What causes buffer overflow?
– When a program or process that lacks parameter
enforcement control tries to store more data in a buffer than
it was intended to hold

• Why a good information flow model is a good tool for

supporting the identification of covert channel?
– Information flow model is the system design baseline that
illustrates the directional vectors of information flow between
objects (e.g., programs or processes)

- 68 -
Questions:
• Program that allows the information owner to
determine who has what type of access and privilege
is an implementation of what type of access control?
–

• For mandatory access control (MAC), an access

decision is based on privilege of ___ & sensitivity of
___?
–
–

- 69 -
Answers:
• Program that allows the information owner to
determine who has what type of access and privilege
is an implementation of what type of access control?
– Discretionary access control (DAC)

• For mandatory access control (MAC), an access

decision is based on privilege of ___ & sensitivity of
___?
– Subject
– Object

- 70 -
Topics

Software 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

- 71 -
Programming Languages
• A set of instructions and rules that tell the computer
what operations to perform.
• Languages have evolved in “generations”
– 1st Generation: Machine language
– 2nd Generation: Assembly language
– 3rd Generation: High-level language
• COBOL, BASIC, FORTRAN, Pascal, C, C+, C++, C#, Java
– 4th Generation: Very high-level language
• SQL, JavaScript, Perl, SGML (Standard General Markup
Language): HTML, XML, SAML, XACML.
– 5th Generation: Natural language
• BPEL (Business Process Execution Language), BQEL
(Business Query Language)

- 72 -
Programming Languages
• Assembler – program that translates an assembly
language program into machine language.
– Assembly Language  Machine Language.

• Compiler – translates a high-level language into

machine language.
– High-level Language (3rd Gen.)  Machine Language.

• Interpreter – instead of compiling a program at once,

the interpreter translates it instruction-by-instruction.
It has a fetch and execute cycle.
– Very high-level Language (4th Gen.)  Interpreter instruction
 Machine Language.

- 73 -
Programming Languages

Object-Oriented Programming (OOP)

• OOP method that creates an object.
– The object is a block of pre-assembled code that is a self-
contained module.
– Once written, object can be reused.
– Objects are encapsulated, thus providing some security.
– Objects have methods (code with programming interfaces)
and attributes (data) encapsulated together.

- 74 -
Programming Languages

Object-Oriented Programming (OOP) – Characteristics

• Class tell the system how to make objects.
• Object is an instance of the class.
• Message: objects perform work by sending
messages to other objects.
• Method is a procedure or routine associated with one
or more classes.
• Encapsulation is the technique of keeping together
data structures and methods (procedures) which act
on them.
• Inheritance is the ability to derive new classes from
existing classes. A derived class (or subclass)
inherits the instance variables and methods of the
“base-class” (or superclass), and may add new
instance variables and methods.

- 75 -
Programming Languages

Object-Oriented Programming (OOP) – Characteristics

• Polymorphism describes the process of using an
object in different ways for different set of inputs.
• Polyinstantiation is creating a new version of an
object by replacing variables with other values (or
variables).
– Also used to prevent inference attacks against databases
because it allows different versions of the same information
to exist at different classification levels.
• Cohesion is the ability of a module to execute one
function with little interaction from other modules.
• Coupling is a measure of the interconnection among
modules in an application.

- 76 -
Programming Languages

Distributed Object-Oriented Systems

• Common Object Request Broker Architecture
(CORBA)
– A standard that “wrap” data objects. The object request
broker (ORB) component enables heterogeneous
applications and computing environment to interoperate.
• Component Object Model (COM) & Distributed
Component Object Model (DCOM)
– COM and DCOM are Microsoft object-oriented system
standards for interoperate in a heterogeneous applications
within a homogeneous (Microsoft) computing environment.
It uses Object Linking & Embedding (OLE) and ActiveX.
• Java
– Java Platform Standard Edition (Java SE)
– Java Platform Enterprise Edition (Java EE)

- 77 -
Programming Languages

Common Object Request Broker Architecture (CORBA)

• A set of standards that address the need for
interoperability between hardware and software.
– Allows applications to communicate with one another
regardless of their location.
– The Object Request Broker (ORB) establishes a
client/server relationship between objects.
– The ORB enforces the system’s security policy.

2. Policy implemented
here.

1. Client Policy
application sends Enforcement Code 3. Target Object
message.

ORB Security System

- 78 -
Programming Languages

How CORBA Works

Remote Invocation Mechanism

Client Object Client Object

IDL Stubs IDL Skeleton IDL Stubs IDL Skeleton

ORB Interface IIOP ORB Interface

Object Request Broker Object Request Broker

• CORBA uses Interface Definition Language (IDL) to describe

interface requirements.
• CORBA uses Internet Inter-ORB Protocol (IIOP) to
communicate between Object Request Brokers (ORBs).
Source: http://www.omg.org/gettingstarted/corbafaq.htm
- 79 -
Programming Languages

Component Object Models

• Component Object Model (COM) architecture
– An open software architecture from DEC and Microsoft,
allowing interoperation between ObjectBroker and OLE.
Microsoft evolved COM into DCOM .
• Distributed Component Object Model (DCOM)
architecture
– An extension of COM to support objects distributed across a
network.
• Object Linking and Embedding (OLE)
– A distributed object system and protocol from Microsoft, OLE
allows an editor to "farm out" part of a document to another
editor and then re-import it.
– Example: a desk-top publishing system might send some
text to a word processor or a picture to a bitmap editor using
OLE.

- 80 -
Programming Languages

Component Object Models

Source: http://technet.microsoft.com/en-us/library/cc722925.aspx - 81 -
Programming Languages

Object Linking & Embedding (OLE)

• OLE allows applications to share functionality by live
data exchange and embedded data.
– Embedding – places data in a foreign program.
For example: Embedding of a Visio diagram inside of a
PowerPoint slide.

– Linking – capability to call a program.

For example: Double click on the embedded Visio diagram in
a PowerPoint slide and invoke Visio application to edit the
diagram.

- 82 -
Programming Languages

ActiveX
• A loosely defined set of technologies developed by
Microsoft. ActiveX is a set of technologies that
enables interactive contents for web.
• Elements of ActiveX technologies:
– ActiveX Controls: interactive objects in a web page that
provides user interaction functions.
– ActiveX Documents: enable user to view non-HTML
documents (e.g. Word, Excel, or PPT)
– ActiveX Scripting Controls: integrated controls for ActiveX
controls and/or Java Applets from web browser or server.
– Java Virtual Machine (JVM): enables web browser (IE) to run
Java applets and integrate with ActiveX controls.
– ActiveX Server Framework: provide web server functions to
support the above functions plus objects for database
access and online transactions.

- 83 -
Programming Languages
Source: http://java.sun.com/javase/javasemap-lg.html
Java Platforms
• Java is designed as a standard application “platform”
for computing in a networked heterogeneous
environment (developed by Sun Microsystems.)
• Java is a high-level programming language. Java
source code are compiled into bytecode, which can
then be executed by a Java interpreter.
• Java has three
platforms:
– Java SE
(Standard Edition)
– Java EE
(Enterprise Edition)
– Java ME
(Micro Edition)

- 84 -
Programming Languages

Java Platform Enterprise Edition

• Java Platform Enterprise Edition (Java EE) uses Java
Platform SE as the foundation for the following class
“containers”
• Containers are the runtime components for Java EE.
– Applet
– Application Client
– Web
– EJB

Source: http://docs.oracle.com/cd/E19879-01/820-
4343/abeat/index.html

- 85 -
Programming Languages

Java Application Server Architecture

Source: http://www.javaworld.com/javaworld/jw-01-2008/images/tomcat6_1.jpg - 86 -
Questions:
• COBOL, FORTRAN, C, C+, C++, C# are what
generation programming languages?
–

• JavaScript, Perl, SQL, SGML are what generation

programming languages?
–

• What mechanism translates a high-level language

(3rd Generation) into machine language?
–

- 87 -
Answers:
• COBOL, FORTRAN, C, C+, C++, C# are what
generation programming languages?
– 3rd Generation

• JavaScript, Perl, SQL, SGML are what generation

programming languages?
– 4th Generation

• What mechanism translates a high-level language

(3rd Generation) into machine language?
– Compiler

- 88 -
Questions:
• In object-oriented programming (OOP), what tells the
system how to make object(s)?
–

• In OOP, what is the technique that keeps the data

structures and methods (procedures) together?
–

• In OOP, what is the term that describes the process

of using an object in different ways for different set of
inputs?
–

- 89 -
Questions:
• In object-oriented programming (OOP), what tells the
system how to make object(s)?
– Class

• In OOP, what is the technique that keeps the data

structures and methods (procedures) together?
– Encapsulation

• In OOP, what is the term that describes the process

of using an object in different ways for different set of
inputs?
– Polymorphism

- 90 -
Topics

Software 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

- 91 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

Database Management System (DBMS)

• Databases are developed to manage information
from many sources in one location.
– Eliminate the need for duplication of information in the
system (thus preserves storage space).
– Prevent inconsistency in data by making changes in one
central location.
• DBMS consists of: hardware, software, and
databases used to manage large sets of structured
data (or information asset).
– Enables Multiple Users and Applications to access, view,
and modify data as Needed.
– Can enforce control restrictions.
– Provides data integrity and redundancy.
– Established procedures for data manipulation.

- 92 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

DBMS Models
• Hierarchical DBMS
– Stores information records (data) in a single table
– Uses parent/child relationships
– Limited to a single tree, no links between branches
• Network DBMS
– Relationship of information records are of same type
– All associations are direct connects, which forms a network
• Relational DBMS
– Information records are structured in tables
– Columns are the “attributes”, Rows are the “records”
• Object-oriented DBMS & object relational DBMS
– Information records are objects
– Relationships of objects are dynamic. The association can
be made hierarchical, network, or relational

- 93 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

Relational DBMS (RDBMS)

• Information records (data) are structured in database tables.
– Columns (attributes) represent the variables
– Rows (records) contain the specific instance of information records
• Atomic relation – every row/column position is always
exactly one data value and never a set of values.
Attributes

Traveler Manifest Table

Unique ID Last Name First Name Port of Entry (POE)

Tuples / 123456-123456 Smith John DCA

Rows
234567-123456 Rogers Mike LGA

345678-123456 Johnson John SFO

456789-123456 Smith Jack SAN

Primary Key
- 94 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

Relational DBMS (RDBMS) – Primary & Foreign Keys

• Data within the RDBMS
• Unique ID is the “primary key”. It identifies each row
(record or tuple)
• Tuple cannot have a null value in the primary key.
• The primary key value guarantees that the tuple is
unique
• “foreign key” is an attribute or combination of
attributes in another database table that matches the
value of “primary key” in the first database table
– Referential integrity rule
• For any foreign key value, the reference relation to another
table must have a tuple with the same value of the other table’s
primary key
• A null value in the foreign key field prevents a join

- 95 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

Relational DBMS (RDBMS) – Primary & Foreign Keys

Traveler Manifest Table

Unique ID Last Name First Name Port of Entry (POE)

123456-123456 Smith John DCA

Primary Key 234567-123456 Rogers Mike LGA

345678-123456 Johnson John SFO

456789-123456 Smith Jack SAN

Foreign Key

Baggage Manifest Table

Unique Tag ID Airline Flight Number Unique ID

DCA456-123456 AA AA-456 123456-123456

LGA567-123456 JetBlue JB-567 234567-123456

SFO678-123456 United UA-678 345678-123456

SAN89-123456 NW NW-89 456789-123456

- 96 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

Relational DBMS (RDBMS) – View & Schema

• Data dictionary – Central repository of data elements
and their relationships.

• Schema – Holds data that describes a database.

• View – Virtual relation defined by the database to

keep subjects from viewing certain data.

- 97 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

Relational DBMS (RDBMS) – Security Issues

• Ensure integrity of input data (check input values,
prevent buffer overflow).

• Access control ensuring only authorized user are

performing authorized activities (“need-to-know”,
“least privilege”).

• Preventing deadlock (stalemate when 2 or more

processes are each waiting for the other to do
something before they can proceed).

- 98 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

OODBMS &ORDBMS
• Class is a set of objects which shares a common
structure and behavior. The relationship between
classes can be hierarchical. (i.e. super-class, and
subclass.)

• Object is a unique instance of a data structure

defined according to the template provided by its
class. Each object has its own values for the
variables belonging to its class and can respond to
the messages (methods) defined by its class.

• Method is a procedure or routine associated with one

or more classes.

- 99 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

OODBMS &ORDBMS
• Object-oriented database (OODB) represents a
“paradigm-shift” in the traditional database models
(hierarchical, network, and relational).
– Example of OODBMS: Versant.
• Object relations are build dynamically based on
“business needs” instead of a series of fixed
“business processes”.
– Currently, the foundational DBMS engine for most of
ORDBMS are still RDBMS. Object relations are build:
• Presentation Layer: User/client level.
• Business Logic Layer: Accepts commands from the
presentation layer and send instructions to the data layer.
• Data Layer: The database.
– Example of ORDBMS: Oracle (8i, 9i, 10g), IBM DB2.

- 100 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

Data Warehousing and Mining

• Data Warehousing
– Combines data from multiple databases or data sources into
a large database called “data warehouse”.
– Requires more stringent security because all data is in a
central facility.

• Data Mining
– A.k.a. Knowledge-discovery in databases (KDD).
– Practice of automatically searching large stores of data for
patterns.
– Data mining tools are used to find associations and
correlations to product Metadata and can show previously
unseen relationships.

- 101 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

Database Controls
• Granularity - The degree to which access to objects
can be restricted.

• Content dependant access control

– Permissions by View combining specific tables, columns,
and key sets.
• Authorizations for specific views having specific attributes, and
for actions to perform within those views.
• DAC, by specific grant to user or group by owner.
• MAC, by classification level.
– Cell Suppression
• A technique used to hide or not show specific cells that contain
information that could be used in an inference attack.

- 102 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

Database Controls
• Partitioning – Involved dividing a database into
different parts which makes it harder for an individual
to find connecting pieces
• Noise and perturbation – A technique of inserting
bogus information aimed at misdirecting or confusing
an attacker
• Concurrency – allowing multiple users to access the
data contained within a database at the same time.
– Making sure the most up to date information is available
– If concurrent access is not managed by the Database
Management System (DBMS) so that simultaneous
operations don't interfere with one another problems can
occur when various transactions interleave, resulting in an
inconsistent database.

- 103 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

Database Controls – Types of Integrity Service

• Semantic integrity – Ensures that structural and
semantic rules are enforced. Types of rules include
data types, logical values, uniqueness constraints,
and operations that could adversely affect the
database.

• Entity integrity – Ensures that tuples are uniquely

identified by primary key values.

• Referential integrity – Ensures that all foreign keys

reference valid (and existing) primary keys. The
other word, if a record does not include a primary key
it cannot be referenced.

- 104 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

Database Controls – Configurable Controls for Integrity

• Rollback – is a statement that ends a current
transaction and cancels all other changes
– Occurs when some type of “glitch” is encountered during
transaction
• Commit – terminates a transaction and executes all
changes that were just made by a user.
– If a user attempts a “commit” and it cannot be completed
correctly…a “rollback” is executed to ensure integrity
• Savepoint(s) – are used to ensure that if a system
failure occurs, or an error is detected, the database
can return to a known good state prior to the problem
• Checkpoint(s) – (similar to Savepoints) when the
database S/W fills to a certain amount of memory, a
checkpoint is initiated, which saves the data from the
memory segment to a temporary file.

- 105 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

Database Security Controls

• Polyinstantiation
– Allows a relation to contain multiple rows with the same
primary key
– The multiple instances of Primary Keys are distinguished by
their security levels
– Used to prevent inference attacks by inserting “bogus” data
at lower security levels

• Granularity – The degree to which access to objects

can be restricted.
– Granularity can be applied to both the actions allowable on
objects, as well as to the users allowed to perform those
actions on the object

- 106 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

Database Security Issues

• Online Transaction Processing (OLTP)
– Usually used when multiple databases are clustered to
provide fault tolerance and higher performance.
– Transaction logs are used for synchronization of databases
– OLTP transactions occur in real time which usually updates
more than one database…which introduces integrity threats.
To counteract this ACID test should be implemented.
• Atomicity – Divides transactions into units of work and ensures
all modifications take effect or none do
• Consistency – A transaction must follow integrity policy for that
specific database and ensure that all data is consistent in the
different databases
• Isolation – Transactions execute in isolation until completed,
without interacting with other transactions
• Durability – Once the transaction is verified as accurate on all
systems, it is committed and the databases cannot be rolled
back

- 107 -
Database and DB Warehousing Vulnerabilities, Threats, and Protections

Database Threats
• Aggregation
– The act of combining information from separate sources.
– The combined information has a sensitivity level greater that
any of the individual parts.
• Inference
– A user deduces (infers or figures out) the full story from
pieces learned through aggregation and other sources.
– Differs from aggregation in that data not explicitly available is
used during the act of deduction (inference or plain figuring it
out).
• Deadlocking
– Two processes have locks on separate objects and each
process is trying to acquire a lock on the object the other
process has.

- 108 -
Questions:
• What are the four types of database management
system (DBMS) models?
–
–
–
–

• In RDBMS, what is the definition for atomic relation?

–

• In RDBMS, what is a primary key?

–

- 109 -
Answers:
• What are the four types of database management
system (DBMS) models?
– Hierarchical
– Network
– Relational
– Object-oriented

• In RDBMS, what is the definition for atomic relation?

– Every row/column position always contains exactly one data
value

• In RDBMS, what is a primary key?

– The attribute that uniquely identifies each record

- 110 -
Questions:
• For RDBMS, how is the relationship between
database tables created?
–

• In an object-oriented relational database (ORDBMS),

what are the three layers where the object relations
are build?
–
–

- 111 -
Answers:
• For RDBMS, how is the relationship between
database tables created?
– When an attribute of a database table is also an attribute of
another database table

• In an object-oriented relational database (ORDBMS),

what are the three layers where the object relations
are build?
– Presentation Layer: User/client level
– Business Logic Layer: Accepts commands from the
presentation layer and send instructions to the data layer
– Data Layer: The database

- 112 -
Questions:
• For granularity access control, what are the two
content dependent access control implementations
for a DBMS?
–
–

• For DBMS, what is the term used that describes

multiple users accessing data contained within a
database at the same time?
–

• What is the act of combining information from

different sources?
–

- 113 -
Answers:
• For granularity access control, what are the two
content dependent access control implementations
for a DBMS?
– Permissions by view
– Cell suppression

• For DBMS, what is the term used that describes

multiple users accessing data contained within a
database at the same time?
– Concurrency

• What is the act of combining information from

different sources?
– Aggregation

- 114 -
Topics

Software 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

- 115 -
Vulnerability & Threats

Relationship between Threat, Risk, and Countermeasure

• Threat source. Entity that may
acts on a vulnerability. Give rise to
Threat source
• Threat. Any potential danger to
information life cycle. Exploits
Threat
• Vulnerability. A system has
weakness or flaw that may Leads to
provide an opportunity to a Vulnerability

Indirectly affects
threat source.
• Risk. The likelihood of a threat Risk
Reduces/
source take advantage of a Eliminates

vulnerability. Asset
Can damage
• Exposure. An instance of being
compromised by Threat Source. Exposure
And causes an
• Countermeasure / safeguard.
Counter
An administrative, operational, or measure
Can be countered by a
logical mitigation against
potential risk(s).

- 116 -
Vulnerability & Threats

Structural Defects, Weaknesses, Bugs, and Vulnerabilities

• Vulnerabilities are weaknesses that allow attackers to
compromise the security objectives of information
and/or information systems.
• Defects can be design flaws and/or implementation
weaknesses.
• Bugs are implementation-level weaknesses.
Information Systems Security Engineering (ISSE) Life Cycle
Discover
Information Define Design System Develop Detailed System Design & Implement System & Security Continuous
Protection Requirements Architecture Security Controls Controls Monitoring
Needs

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 structural defects (flaws) Focus on software weaknesses (bugs)

- 117 -
Vulnerability & Threats

Common Weakness Enumeration (CWE)

• CWE is an online dictionary of software weaknesses.

Reference: Common Weakness Enumeration (CWE) (http://cwe.mitre.org/)

- 118 -
Vulnerability & Threats

2011 CWE/SANS Top 25 Most Dangerous Programming

Errors
Rank Score ID Name
[1] 93.8 CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
[2] 83.3 CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
[3] 79.0 CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
[4] 77.7 CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
[5] 76.9 CWE-306 Missing Authentication for Critical Function
[6] 76.8 CWE-862 Missing Authorization
[7] 75.0 CWE-798 Use of Hard-coded Credentials
[8] 75.0 CWE-311 Missing Encryption of Sensitive Data
[9] 74.0 CWE-434 Unrestricted Upload of File with Dangerous Type
[10] 73.8 CWE-807 Reliance on Untrusted Inputs in a Security Decision
[11] 73.1 CWE-250 Execution with Unnecessary Privileges
[12] 70.1 CWE-352 Cross-Site Request Forgery (CSRF)
[13] 69.3 CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
[14] 68.5 CWE-494 Download of Code Without Integrity Check
[15] 67.8 CWE-863 Incorrect Authorization
[16] 66.0 CWE-829 Inclusion of Functionality from Untrusted Control Sphere
[17] 65.5 CWE-732 Incorrect Permission Assignment for Critical Resource
[18] 64.6 CWE-676 Use of Potentially Dangerous Function
[19] 64.1 CWE-327 Use of a Broken or Risky Cryptographic Algorithm
[20] 62.4 CWE-131 Incorrect Calculation of Buffer Size
[21] 61.5 CWE-307 Improper Restriction of Excessive Authentication Attempts
[22] 61.1 CWE-601 URL Redirection to Untrusted Site ('Open Redirect')
[23] 61.0 CWE-134 Uncontrolled Format String
[24] 60.3 CWE-190 Integer Overflow or Wraparound
[25] 59.9 CWE-759 Use of a One-Way Hash without a Salt

Reference: http://cwe.mitre.org/top25/index.html
- 119 -
Vulnerability & Threats

Categories of Software Weaknesses

• Insecure interaction between components
– “Weaknesses related to insecure ways in which data is sent
and received between separate components, modules,
programs, processes, threats, or systems.”
• Risky resource management
– “Weaknesses related to ways in which software does not
properly manage the creation, usage, transfer, or destruction
of important system resources.”
• Porous defenses
– “Weaknesses related to defensive techniques that are often
misused, abused, or just plain ignored.”

Reference: http://cwe.mitre.org/top25/index.html
- 120 -
Vulnerability & Threats

Reduce / Eliminate Software Vulnerabilities

• Addressing structural/design flaws Give rise to
Threat source
– Understand the information protection needs
– Develop use/abuse cases Threat
Exploits

– Define system security requirements

– Design system architecture Vulnerability
Leads to

Indirectly affects
Develop detailed system design & security controls
Risk
Reduces/
Eliminates

• Addressing software bugs (weaknesses) Asset

Can damage

– Develop detailed software design & specifications

Exposure
– Implement code reviews And causes an

• Static code analyzers Counter

– Perform tests measure

Can be countered by a

• Unit, subsystems, system, acceptance tests

• Vulnerability scanners
Information Systems Security Engineering (ISSE) Life Cycle
Discover
Information Define Design System Develop Detailed System Design & Implement System & Security Continuous
Protection Requirements Architecture Security Controls Controls Monitoring
Needs
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 structural defects (flaws) Focus on software weaknesses (bugs) - 121 -
Vulnerability & Threats

Threats to Software – Buffer Overflow

• One of the oldest and most common problems to
software.
– Wagner et. al. estimated over 50% of all vulnerabilities are
due to buffer overflow.*
• No. 3 in 2011 CWE/SANS Top 25.
• A buffer overflow occurs when a program or process
tries to store more data in a buffer (temporary data
storage area) than it was intended to hold.
• In buffer overflow attacks, the extra data may contain
codes designed to trigger specific actions, in effect
sending new instructions to the attacked computer
that could, for example, damage the user's files,
change data, or disclose confidential information.

Reference:
• * A First Step Towards Automated Detection of Buffer Over-run Vulnerabilities, D. Wagner, et. al., 2000.
• 2011 CWE/SANS Top 25 Most Dangerous Programming Errors, MITRE, September 2011.
- 122 -
Vulnerability & Threats

Threats to Software – Cross-site Scripting (XSS)

• XSS is one of the most prevalent web application
(web app) security flaw.
• No. 4 in 2011 CWE/SANS Top 25 and OWASP Top
10.
• XSS occurs when a web app in web browser accepts
“untrusted data” and sends it to a web app server
without proper validation. Attackers can then execute
scripts in a victim’s web browser to hijack user
sessions, deface web sites, insert malicious content,
redirect users, etc.
– These “untrusted data” could be JavaScript, or other
browser-executable RIA contents such as Active X, Flash,
Silverlight, etc.

Reference: 2011 CWE/SANS Top 25 Most Dangerous Programming Errors, MITRE, September 2011.
- 123 -
Vulnerability & Threats

Threats to Software – SQL Injection

• In 2011, SQL injection is No.1 in both CWE/SANS
Top 25 and OWASP Top 10.
• SQL injection occurs when an application sends
“untrusted data” to an interpreter as a part of
command or query.
– These “untrusted data” can be in SQL queries, LDAP
queries, Xpath queries, etc.
• Attackers can:
– Alter the logic of SQL queries to bypass security (e.g.,
authentication, authorization, etc.) to gain unauthorized
access to data (e.g., steal, corrupt, or change data.)
– Trick the interpreter to execute unintended commands

Reference: 2011 CWE/SANS Top 25 Most Dangerous Programming Errors, MITRE, September 2011.
- 124 -
Vulnerability & Threats

Threats to Software – Malicious Code / Malware

Malicious code / malware (MALicious softWARE)
• Virus – A program or piece of code that is loaded
onto your computer without your knowledge and
runs against your wishes. Viruses can also
replicate themselves. A simple virus that can make
a copy of itself over and over again is relatively
easy to produce.
• Polymorphic virus – A virus that changes its virus
signature (i.e., its binary pattern) every time it
replicates and infects a new file in order to keep
from being detected by an antivirus program.

- 125 -
Vulnerability & Threats

Threats to Software – Malicious Code / Malware

• Boot sector virus – A boot sector virus is a common
type of virus that replaces the boot sector with its own
code. Since the boot sector executes every time a
computer is started, this type of virus is extremely
dangerous.
• Macro virus – A type of computer virus that is encoded
as a macro embedded in a document. Many
applications, such as Microsoft Word and Excel,
support powerful macro languages. These applications
allow you to embed a macro in a document, and have
the macro execute each time the document is opened.
– According to some estimates, 75% of all viruses today are
macro viruses. Once a macro virus gets onto your machine, it
can embed itself in all future documents you create with the
application.
- 126 -
Vulnerability & Threats

Threats to Software – Malicious Code / Malware

• Worm – A program or algorithm that replicates itself
over a computer network and usually performs
malicious actions. Differ from viruses in that they are
self contained and do not need a host application to
reproduce.
• Logic bomb – Also called slag code, programming
code (typically malicious) added to the software of an
application or operating system that lies dormant until
a predetermined period of time or event occurs,
triggering the code into action.

- 127 -
Vulnerability & Threats

Threats to Software – Malicious Code / Malware

• Trojan horse – A destructive program that
masquerades as a benign application. Unlike viruses,
Trojan horses do not replicate themselves but they
can be just as destructive. One of the most insidious
types of Trojan horse is a program that claims to rid
your computer of viruses but instead introduces
viruses onto your computer.
• Data diddler – refers to the payload in a Trojan or
virus that deliberately corrupts data, generally by
small increments over time.
• Hoax – usually warnings about viruses that do not
exist, generally carry a directive to the user to forward
the warning to all addresses available to them.
• Trapdoor/backdoor – can also be called a
maintenance hook; it’s a hidden mechanism that
bypasses access control measures.

- 128 -
Validation Time… 

1. Classroom Exercise

2. Review Answers

- 129 -
Classroom Exercise: Constructing a Security Engineering
Project… (1/5)
Systems Engineering (SE) Activities Security Engineering (ISSE) Activities
Discover Mission/Business Needs Discover Information Protection Needs
The SE helps the customer understand and document the The ISSE facilitates the system owners, architects, and
information management needs that support the business or engineers in assessing the information protection needs by
mission. Statements about information needs may be performing risk assessment, capturing the information
captured in an information management model (IMM). management model (IMM), defining the information protection
policy (IPP) and compile them into a comprehensive
information management plan (IMP).
Define System Requirements Define System Security Requirements
The SE allocates identified needs to systems. A system The ISSE allocates the information protection needs in
context is developed to identify the system environment and accordance with the information management plan (IMP) that
to show the allocation of system functions to that aligns with a preliminary system security concept of
environment. A preliminary system Concept of Operations operations (CONOPS) and generates a set of baseline
(CONOPS) is written to describe operational aspects of the security requirements in accordance with FIPS 200.
candidate system (or systems). Baseline requirements are
established.
Design System Architecture Design System Security Architecture
The SE performs functional analysis and allocate by The ISSE works in conjunction with system architect and
analyzing candidate architectures, allocating requirements, engineers in defining a system architecture using the
and selecting mechanisms. The system engineer identifies designated system architecture framework to explain the
components or elements, allocates functions to those system architecture at the conceptual and logic levels in
elements, and describes the relationships between the meeting the defined baseline security requirements.
elements.
- 130 -
Classroom Exercise: Constructing a Security Engineering
Project… (2/5)
Systems Engineering (SE) Activities Security Engineering (ISSE) Activities
Develop Detailed System Design Develop Detailed Security Design
The SE analyzes design constrains, analyzes trade-offs, does The ISSE analyzes the design constrains, trade-offs from the
detailed system design, and considers life-cycle support. The system architecture and begin to work with system architect
systems engineer traces all of the system requirements to the and engineers to define detailed system design.
elements until all are addressed. The final detailed design
results in component and interface specifications that provide
sufficient information for acquisition where the system is
implemented.
Implement System Implement System Security
The SE moves the system from specifications to the tangible. The ISSE works with SE in implementing the baseline
The main activities are acquisition, integration, configuration, detailed system design. The information systems security
testing, documentation, and training. Components are tested engineer provide inputs to the certification and accreditation
and evaluated to ensure that they must meet the (C&A) process and verify the implemented system design
specifications. After successful testing, the individual meets the defined baseline security requirements against the
components – hardware, software, and firmware – are identified threats .
integrated, properly configured, and tested as a system.
Assess System Effectiveness Assess System Security Effectiveness
The results of each activity are evaluated to ensure that the The ISSE focuses on the effectiveness of the implemented
system will meet the user’s needs by performing the required security controls and countermeasures, and validates them
functions to the required quality standard in the intended against the defined information management plan (IMP).
environment. The systems engineer examines how well the
system meets the needs of the mission.
- 131 -
Classroom Exercise: Constructing a Security Engineering
Project… (3/5)
1. Discovering the Information Protection Needs
1.1 Collect & analyze system information:
Business/Mission Needs, high-level concept of
information operations, data sensitivity, mode of
operations, etc.
1.2 Perform Risk Assessment of the “to-be” information
system
1.3 Generate Information Management Model (IMM)
1.4 Generate Information Protection Policy (IPP)
1.5 Assemble Information Management Plan
2. Defining the System Security Requirements
2.1 Define security context description (i.e. scope)
2.2 Generate system security requirements: functional &
assurance

- 132 -
Classroom Exercise: Constructing a Security Engineering
Project… (4/5)
3. Designing the System Security Architecture
3.1 Describe the Conceptual Security Architecture
3.2 Describe the Logical Security Architecture
3.3 Describe the Physical Security Architecture
4. Developing the Detailed System Security Design
4.1 Describe the Security Architecture at the components
level
4.1.1 Defending the Network & Infrastructure
4.1.2 Defending the Enclave Boundary
4.1.3 Defending the Computing Environment
4.1.4 Supporting the IT Infrastructure

- 133 -
Classroom Exercise: Constructing a Security Engineering
Project… (5/5)
5. Implementing the System Security
5.1 Implement system design for defending the network
infrastructure
5.2 Implement system design for defending the enclave
boundary
5.3 Implement system design for defending the computing
environment
5.4 Implement system design for supporting the IT
Infrastructure
6. Assessing the Security Effectiveness
6.1 Perform analysis on Security Requirements Traceability
matrix (S-RTM)
6.2 Verify conformance of system design to S-RTM
6.3 Validate security implementation to S-RTM
6.4 Support Security Certification & Accreditation (C&A)
Team

- 134 -
Group 1: Waterfall SDLC Model

ISSE Phase 1: Discovering Information

Protection Needs
ISSE Phase 2: Define Security
Requirements
Requirements
ISSE Phase 3: Design System Security
Design Architecture
ISSE Phase 4: Develop Detailed
Security Design
Implementation
ISSE Phase 5: Implement System
Security

Verification

ISSE Phase 6: Assess Security

Effectiveness
Maintenance

- 135 -
Group 1: Waterfall SDLC Model

1.3

1.0 ? ? 1.5

1.4

Req. ? ? ?
?

Dsgn. 6.1
?
3.1 ? ? 4.0 4.1

?
Impl. 6.2

5.0 5.1 ? ?

6.3 ?

- 136 -
 Group 2: DoD-STD-2167A (V-Model)

ISSE Phase 1: Discovering Process Software

Software
Acceptance
Information Protection Needs Implementation Installation
Support

Project
ISSE Phase 2: Define Security
Requirements System System
System
System
Requirements Architecture Qualification
Integration
Analysis Design Testing
ISSE Phase 3: Design System System
Security Architecture
Software Software
Requirements Qualification
ISSE Phase 6: Assess
Analysis Testing Security Effectiveness

ISSE Phase 4: Develop Software

Software
Architectural
Detailed Security Design Integration
Design

Software Detailed Software Coding

Design & Testing

Software
ISSE Phase 5: Implement System Security

- 137 -
Group 2: DoD-STD-2167A (V-Model)
1.3

Prcs. Sys.
1.0 ? ? ? 2.0 ? ? ?
Impl. Req.

1.4 6.1
?
Sys.
3.1 ? ? 4.0 4.1
Arch.
?

SW.
2.0 2.1 2.2
Req.
6.2 ?
6.1
4.1.3
SW.
3.1 ? ? 4.0 ?
Arch.
4.1.4
6.2
Sys.
Intgr.

5.0 5.1 ?

6.3 ?

- 138 -
Group 3: Boehm’s Spiral SDLC Model

ISSE Phase 1

5 e

ISSE
has
EP

Pha
ISS
ISSE Phase 6:

se
Assess Security

2
Effectiveness

IS
e

SE
as
Ph

Ph
SE

as
IS

e
4
- 139 -
Group 3: Boehm’s Spiral SDLC Model
1.3

Risk SW.
1.0 ? ? ? 2.0 ? ?
Anlys Req.

1.4 6.1

Sys.
Plan.
1.3

Risk SW.
1.0 ? ? ? 2.0 ? ?
Anlys Req.
?
1.4 6.1

?
SW.
3.1 ? ? 4.0 4.1
Arch.

?
6.2
Sys.
Intgr.
?
5.0 5.1 ?

Test,
?
Eval.

6.3 ?

- 140 -
Reference

ANSWERS

- 141 -
Group 1: Waterfall SDLC Model

1.3

1.0 1.1 1.2 1.5

1.4

Req. 2.0 2.1 2.2

4.1.1

Dsgn. 6.1
4.1.2
3.1 3.2 3.3 4.0 4.1

4.1.3
Impl. 6.2

5.0 5.1 5.2 4.1.4

5.3

6.3 5.4

- 142 -
Group 2: DoD-STD-2167A (V-Model)

1.3

Prcs. Sys.
1.0 1.1 1.2 1.5 2.0 2.1 2.2 4.1.1
Impl. Req.

1.4 6.1
4.1.2
Sys.
3.1 3.2 3.3 4.0 4.1
Arch.
4.1.3

SW.
2.0 2.1 2.2
Req.
6.2 4.1.4
6.1

4.1.3
SW.
3.1 3.2 3.3 4.0 4.1
Arch.
4.1.4

6.2
Sys.
Intgr.

5.0 5.1 5.2

5.3

6.3 5.4

- 143 -
Group 3: Boehm’s Spiral SDLC

1.3

Risk SW.
1.0 1.1 1.2 1.5 2.0 2.1 2.2
Anlys Req.

1.4 6.1

Sys.
Plan.
1.3

Risk SW.
1.0 1.1 1.2 1.5 2.0 2.1 2.2
Anlys Req.
4.1.1
1.4 6.1

4.1.2
SW.
3.1 3.2 3.3 4.0 4.1
Arch.

4.1.3
6.2
Sys.
Intgr.
4.1.4
5.0 5.1 5.2

Test,
5.3
Eval.

6.3 5.4

- 144 -