0% found this document useful (0 votes)
19 views138 pages

Domain 8 - Software Development Security

Uploaded by

ryancheungkk2
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
19 views138 pages

Domain 8 - Software Development Security

Uploaded by

ryancheungkk2
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 138

Software Development

Security

CISSP COMMON BODY OF KNOWLEDGE (CBK)


DOMAIN – 8

© 2021 CLOUD EDUCATION GROUP LIMITED 1


Software Development Security Domain
• Learning Objective
o 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).
o 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.
o 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.

© 2021 CLOUD EDUCATION GROUP LIMITED 2


Top 25 Most Dangerous programming Errors
Rank ID Name Score
[1] CWE‐79 Improper Neutralization of Input During Web Page Generation ('Cross‐site Scripting') 46.82
[2] CWE‐787 Out‐of‐bounds Write 46.17
[3] CWE‐20 Improper Input Validation 33.47
[4] CWE‐125 Out‐of‐bounds Read 26.5
[5] CWE‐119 Improper Restriction of Operations within the Bounds of a Memory Buffer 23.73
[6] CWE‐89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') 20.69
[7] CWE‐200 Exposure of Sensitive Information to an Unauthorized Actor 19.16
[8] CWE‐416 Use After Free 18.87
[9] CWE‐352 Cross‐Site Request Forgery (CSRF) 17.29

2020 CWE/SANS
[10] CWE‐78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') 16.44
[11] CWE‐190 Integer Overflow or Wraparound 15.81
[12] CWE‐22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') 13.67
[13] CWE‐476 NULL Pointer Dereference 8.35
[14] CWE‐287 Improper Authentication 8.17
[15] CWE‐434 Unrestricted Upload of File with Dangerous Type 7.38
[16] CWE‐732 Incorrect Permission Assignment for Critical Resource 6.95
[17] CWE‐94 Improper Control of Generation of Code ('Code Injection') 6.53
[18] CWE‐522 Insufficiently Protected Credentials 5.49
[19] CWE‐611 Improper Restriction of XML External Entity Reference 5.33
[20] CWE‐798 Use of Hard‐coded Credentials 5.19
[21] CWE‐502 Deserialization of Untrusted Data 4.93
[22] CWE‐269 Improper Privilege Management 4.87
[23] CWE‐400 Uncontrolled Resource Consumption 4.14
[24] CWE‐306 Missing Authentication for Critical Function 3.85
[25] CWE‐862 Missing Authorization 3.77

© 2021 CLOUD EDUCATION GROUP LIMITED 3


Software Development Security Domain Topics
• 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

© 2021 CLOUD EDUCATION GROUP LIMITED 4


Size Matters

Number of connections (or interfaces) = n * (n ‐ 1) / 2

© 2021 CLOUD EDUCATION GROUP LIMITED 5


Size Matters
• “As project size increases, errors usually come more from requirements and
design (Boehm 1981, Grady 1987, Jones 1998)”

© 2021 CLOUD EDUCATION GROUP LIMITED 6


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.

© 2021 CLOUD EDUCATION GROUP LIMITED 7


Clinger‐Cohen Act of 1996 (CCA)
• The Clinger‐Cohen Act of 1996 (a.k.a. ITMRA) defined the Federal agencies
and DoD’s acquisition, management, and usage of IT.
• Key Elements
o Defines the roles & responsibilities of Federal agencies and their executives (i.e.
directors and CIOs.)
o Requires Federal agencies to implement performance and result‐based management
for capital planning and investment control (CPIC)
o Defines the IT acquisition process
o Requires IT architecture be defined for all Federal agencies (i.e. Federal Enterprise
Architecture (FEA))

© 2021 CLOUD EDUCATION GROUP LIMITED 8


Why CCA / ITMRA necessary
In 1992, GAO reported: “Defense’s mission critical systems continue to have significant
software development problems. Numerous GAO reports and Defense studies have
identified many problems, including a lack of management attention , ill‐defined system
requirements, and inadequate testing. The highly complex nature of mission critical
systems and millions of lines of software required to support them contribute to the
continuation of serious software development problems.” E.g.,

 Cheyenne Mountain Upgrade (CMU)

 Strategic Defense Initiative (SDI)

 Patriot surface to air missile system (Patriot)

* ITMRA – Information Technology Management Reform Act

© 2021 CLOUD EDUCATION GROUP LIMITED 9


Why CCA / ITMRA necessary
 Army Tactical Command and Control System (ATCCS)

 AN/BSY 2 combat system for SSN 21 Seawolf submarine (BSY‐2)

 AN/FQ 93 computer for the North American Aerospace

Defense Command

 C‐17 transport aircraft

 F‐14D Tomcat fighter aircraft, etc.

© 2021 CLOUD EDUCATION GROUP LIMITED 10


Federal Enterprise Architecture (FEA) Framework
• Federal Enterprise Architecture Framework (FEAF) focuses on BUSINESS

© 2021 CLOUD EDUCATION GROUP LIMITED 11


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
o Information security controls (e.g., NIST SP 800‐53, CNSS 1253, ISO/IEC 27001:2005)
o IT processes management frameworks (e.g., ITIL, CMMI, ISO/IEC 27000 IT Service
Management, PMBOK)
• COBIT governance is composed of 5 focus areas:
o Strategic alignment
o Value delivery
o Resource management
o Risk management
o Performance measurement

© 2021 CLOUD EDUCATION GROUP LIMITED 12


Augment IT Governance with Information
Security
• Information security is an ubiquitous practice

© 2021 CLOUD EDUCATION GROUP LIMITED 13


ISO/IEC 12207:2008, Software Life Cycle Processes

© 2021 CLOUD EDUCATION GROUP LIMITED 14


Life Cycle Stages in Defense Acquisition System

© 2021 CLOUD EDUCATION GROUP LIMITED 15


Each Life Cycle Stage has Milestone & Review

© 2021 CLOUD EDUCATION GROUP LIMITED 16


Governance & SE reduces Acquisition Risks
• By Development Stage, 85% of LCC has already been committed
• Ratio of structural/design defects (flaws) vs. implementation weaknesses
(bugs) is 50:50
• If structural/design flaws have not been discovered, mitigating them will
add 20 to 100 times to the plan cost. (And up to 1000 x in Production/Test
Stage.)
• Running source code analysis tools doesn’t
help, because they are mostly for finding
implementation weaknesses

© 2021 CLOUD EDUCATION GROUP LIMITED 17


Capability Maturity Model (CMM) ‐ History
• In 1986, Software Engineering Institute (SEI) and MITRE began developing an
assessment framework for measuring the maturity of an organization’s
system/software engineering process
o Process capability describes expected results
o Process performance represents the actual results achieved
o Process maturity is the degree which a process is explicitly defined, managed,
measured, controlled, and effective

© 2021 CLOUD EDUCATION GROUP LIMITED 18


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.

© 2021 CLOUD EDUCATION GROUP LIMITED 19


ISO/IEC 21827: SSE‐CMM
• System Security Engineering ‐ Capability Maturity Model (SSE‐CMM)

© 2021 CLOUD EDUCATION GROUP LIMITED 20


ISO/IEC 21827: SSE‐CMM
SSE CMM is composed of two domains:
• Security Base Practices • Project & Organizational Base Practices
1. Administer Security Controls 1. Ensure Quality
2. Assess Impact 2. Manage Configuration
3. Assess Security Risk 3. Manage Project Risks
4. Assess Threat 4. Monitor & Control Technical Effort
5. Assess Vulnerability 5. Plan Technical Effort
6. Build Assurance Argument 6. Define Organization’s SE Process
7. Coordinate Security 7. Improve Organization’s SE Process
8. Monitor Security Posture 8. Manage Product Line Evolution
9. Provide Security Input 9. Manage SE Support Environment
10. Specify Security Needs 10. Provide Ongoing Skills & Knowledge
11. Verify & Validate Security 11. Coordinate with Suppliers

© 2021 CLOUD EDUCATION GROUP LIMITED 21


Measure of Effectiveness – Assurance Requirements
• Meeting the assurance requirements is a
part of “due diligence” processes.
Example:
o SC‐3: Security Function Isolation. The
information system isolates security functions
from non‐security functions.
• Meeting the functional requirements is a
part of “due care” processes.
Example:
o VLAN technology shall be created to partition
the network into multiple mission‐specific
security domains.
o The integrity of the internetworking
architecture shall be preserved by the access
control list (ACL).

© 2021 CLOUD EDUCATION GROUP LIMITED 22


Assurance Requirements ‐ Federal Agencies

© 2021 CLOUD EDUCATION GROUP LIMITED 23


Assurance Requirements ‐ DoD
• DoDI 8500.2, Information Assurance (IA) Implementation
o Confidentiality Controls + Controls for Integrity & Availability (i.e. Mission Assurance
Category (MAC))

© 2021 CLOUD EDUCATION GROUP LIMITED 24


Assurance Requirements ‐ Industry
• ISO/IEC 27001:2005, Information Technology ‐ Security Techniques ‐ Security
Management System Requirements

© 2021 CLOUD EDUCATION GROUP LIMITED 25


Assurance Requirements ‐ Credit Card
Payment Industry
• Payment Card Industry ‐ Data Security Standard (PCI DSS), Requirements and
Security Assessment Procedures, Version 2.0, October 2010

© 2021 CLOUD EDUCATION GROUP LIMITED 26


Assurance Requirements ‐ Other PCI Security
Standards
• Payment Application Data Security Standard (PA‐DSS) Requirement and
Security Assessment Procedure , Version 2.0, October 2010
• Payment Card Industry PIN Transaction Security (PCI PTS)
o PIN Security Requirements , Version 1.0, September 2011
o Hardware Security Module (HSM), Version 1.0, April 2009
o Point of Interaction (POI) Modular Security Requirements, Version 3.1, October 2011
• Payment Card Industry Point to Point Encryption (PCI P2PE)
o P2PE Hardware Solution Requirements and Testing Procedures , April 2012

© 2021 CLOUD EDUCATION GROUP LIMITED 27


Software Development Security Domain Topics
• 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

© 2021 CLOUD EDUCATION GROUP LIMITED 28


System Development Life Cycle (SDLC)
Models and Processes
• Waterfall Development Models
o Waterfall ‐ DoD STD 2167A (replaced by MIL STD 498 on 11/1994).
o Modified Waterfall ‐ MIL STD 498 (cancelled on 5/1998)
• Iterative Development Models
o Boehm’s Spiral Model
o Rapid Application Development (RAD) & Joint Application Development (JAD)
• SDLC Processes
o ISO/IEC 12207, Software Life Cycle Processes (IEEE/EIA 12207 US implementation)
(based on MIL STD 499B)
o ISO/IEC 15288, Systems Engineering System Life Cycle Processes (IEEE std 1220‐2005,
US implementation)
• New models
• Agile
• DevOps

© 2021 CLOUD EDUCATION GROUP LIMITED 29


Waterfall Development Models

© 2021 CLOUD EDUCATION GROUP LIMITED 30


Other SDLC Models –
Modified Waterfall w/ Subprojects

© 2021 CLOUD EDUCATION GROUP LIMITED 31


Boehm’s Spiral Model

© 2021 CLOUD EDUCATION GROUP LIMITED 32


Rapid Application Development (RAD) Model
• Iterative, but spiral cycles are much smaller
• Risk based approach, but focus on “good enough” outcome
• SDLC fundamentals still apply
o Requirements, configuration, and quality management, design process, coding, test
& integration, technical and project reviews etc.

© 2021 CLOUD EDUCATION GROUP LIMITED 33


Evolutionary Prototyping Model
• The system concept is refined continuously
o The focus is on “good enough” concept, requirements, and prototype.
o However, it is difficult to determine level of effort (LOE), cost, and schedule.

© 2021 CLOUD EDUCATION GROUP LIMITED 34


Incremental Commitment Model

© 2021 CLOUD EDUCATION GROUP LIMITED 35


The need for speed? Agile Development
Approach
• Agile software development
o Iterative, incremental, and evolutionary
o Efficient and face‐to‐face communication
o Very short feedback loop and adaptation cycle
o Quality focus

Project Terms Agile Terms


MNS Vision
CONOPS User Stories
Release & Iteration
SDP Plans, Backlogs
Retrospectives,
PMR/MS Reviews Product Demo

© 2021 CLOUD EDUCATION GROUP LIMITED 36


Agile SDLC Model ‐ Scrum
• Scrum is an agile software development methodology and model that is
both iterative and incremental
• The concept derived from the development of commercial products,
where
o Product owner provides the vision and roadmap
o Scrum master specifies activities and ensures deliverables meet the sprint and
iteration goals
o Team executes the specified scrum activities
• The process is executed in a series of “time‐boxed” sprints and iterations,
where:
o A “sprint” is usually 2 to 4 weeks; and
o The end product is a “iteration”

© 2021 CLOUD EDUCATION GROUP LIMITED 37


Agile SDLC Model ‐ Scrum
• The product vision is translated into a list of
project requirements
• This “list” is called the product backlog. It
encompasses all the project requirements and
work
• The scrum master works with the product
owner to plan and divide the product backlog
into a series of sprint backlog
• The self‐organized team composed of domain and SMEs. The team is empowered to
select, plan, and make decisions on its work task
• The daily stand up team meeting is called the daily‐scrum. It keeps the team members
focused on their tasks. Both product owner and scrum master are required to
participate

© 2021 CLOUD EDUCATION GROUP LIMITED 38


Are there other SDLC models?
• DevOps is a set of practices that combines
software development (Dev) and IT operations
(Ops). It aims to shorten the systems
development life cycle and provide continuous
delivery with high software quality. DevOps is
complementary with Agile software
development; several DevOps aspects came
from the Agile methodology.
1. Coding – code development and review, source code management tools, code merging.
2. Building – continuous integration tools, build status.
3. Testing – continuous testing tools that provide quick and timely feedback on business risks.
4. Packaging – artifact repository, application pre‐deployment staging.
5. Releasing – change management, release approvals, release automation.
6. Configuring – infrastructure configuration and management, infrastructure as code tools.
7. Monitoring – applications performance monitoring, end‐user experience.

© 2021 CLOUD EDUCATION GROUP LIMITED 39


Philosophy behind the Rugged DevOps
• Seamless integration of software development and IT operations
• Focus on the “big picture” rather than security controls
o Standard configuration
o Process discipline
o Controlled access to production systems
• Results
o 75% reduction in outages triggered by software deployment since 2006
o 90% reduction in outage minutes triggered by software deployments
o Instantaneous automated rollback
o Reduction in complexity

© 2021 CLOUD EDUCATION GROUP LIMITED 40


DevOps Environment

© 2021 CLOUD EDUCATION GROUP LIMITED 41


DevOps Environment

© 2021 CLOUD EDUCATION GROUP LIMITED 42


History of Systems/Software Engineering
Process Standards

© 2021 CLOUD EDUCATION GROUP LIMITED 43


Software & System Engineering Management
Processes
• There are more and more “software intensive” systems
o Systems are getting more complex. Hardware problems are often addressed through
software
o Operating environments are stochastic. Software are more flexible than hardware
• As SDLC models evolves, management processes are evolving too
o DoD‐STD‐2167A ‐ Waterfall SDLC + SE Process
o MIL‐STD‐498 ‐ Modified Waterfall SDLC + SE Process
o IEEE 1220 ‐ System Engineering Process
o ISO 12207 ‐ Software + System Engineering Mgmt. Process
o ISO 15288 ‐ System Engineering Mgmt. Process

© 2021 CLOUD EDUCATION GROUP LIMITED 44


DoD‐STD‐2167A – System Engineering Process

© 2021 CLOUD EDUCATION GROUP LIMITED 45


Everything must be traceable
• Verification ‐ “The process of evaluating a system or component to
determine whether the products of a given development phase satisfy the
conditions imposed at the start of that phase.”
• Validation ‐ “Confirmation, through the provision of objective evidence, that
the requirements for a specific intended use or application have been
fulfilled.”

© 2021 CLOUD EDUCATION GROUP LIMITED 46


ISO/IEC 15288:2008, System Life Cycle Processes
• ISO/IEC 15288
encompasses
o Systems/software
engineering processes
(Technical Processes)
o Project management
processes
o Project support
infrastructure
(Organizational Project
Enabling Processes)
o Contract/business
management processes
(Agreement Processes)

© 2021 CLOUD EDUCATION GROUP LIMITED 47


ISO/IEC 12207:2008, Software Life Cycle Processes

© 2021 CLOUD EDUCATION GROUP LIMITED 48


IEEE std 1220, System Engineering Process

© 2021 CLOUD EDUCATION GROUP LIMITED 49


IEEE std 1220: System Engineering Process (SEP)

© 2021 CLOUD EDUCATION GROUP LIMITED 50


Introducing Security Engineering into SDLC

© 2021 CLOUD EDUCATION GROUP LIMITED 51


Security Considerations in SDLC
1. Initiation Phase (IEEE 1220: Concept stage)
o Survey & understand the policies, standards, and guidelines
o Identify information assets (tangible & intangible)
o Define information classification & protection level (security categorization).
o Define rules of behavior & security CONOPs
o Conduct preliminary risk assessment
2. Acquisition / Development Phase (IEEE 1220: Development stage)
o Conduct risk assessment
o Define security requirements and select security controls (categories & types)
o Perform cost/benefit analysis (CBA)
o Security planning (based on risks & CBA)
o Practice Information Systems Security Engineering (ISSE) Process to develop
security controls
o Develop security test & evaluation (ST&E) plan for verification & validation of
security controls

© 2021 CLOUD EDUCATION GROUP LIMITED 52


Security Considerations in SDLC
3. Implementation Phase (IEEE 1220: Production stage)
o Implement security controls in accordance with system security plan (SSP)
o Perform Security Certification & Accreditation of target system
4. Operations / Maintenance Phase (IEEE 1220: Support stage)
o Configuration management & perform change control
o Continuous monitoring Perform periodic security assessment
5. Disposition Phase (IEEE 1220: Disposal stage)
o Preserve information ‐ archive and store electronic information
o Sanitize media ‐ Ensure the electronic data stored in the disposed media are
deleted, erased, and over‐written
o Dispose hardware ‐ Ensure all electronic data resident in hardware are deleted,
erased, and over‐written (i.e. EPROM, BIOS, etc.)

© 2021 CLOUD EDUCATION GROUP LIMITED 53


Information Systems Security Engineering
(ISSE) Process
• Phase 1: Discover Information Protection Needs
o Ascertain the system purpose.
o Identify information asset needs protection.
• Phase 2: Define System Security Requirements
o Define requirements based on the protection needs.
• Phase 3: Design System Security Architecture
o Design system architecture to meet on security requirements.
• Phase 4: Develop Detailed Security Design
o Based on security architecture, design security functions and features for the system.
• Phase 5: Implement System Security
o Implement designed security functions and features into the system.
• Phase 6: Assess Security Effectiveness
o Assess effectiveness of ISSE activities.

© 2021 CLOUD EDUCATION GROUP LIMITED 54


IEEE 1220 ‐ Key Deliverables
Key Deliverables system requirements)
• IEEE 1220: Concept stage o System Architecture (Contextual +
Logical)
o Mission Needs Statement / Project
Goal(s) and Objectives o Detailed System Design (Logical +
Physical)
o System Capabilities
o Requirements Traceability Matrix
o Preliminary CONOPS (RTM)
o Preliminary System Context
Descriptions • IEEE 1220: Production stage
o Project Risk Assessment o Implement detailed system design
o Perform test & evaluations (unit,
o Draft System Engineering system, security tests)
Management Plan (SEMP)
o Test reports
• IEEE 1220: Development stage o Standard Operating Procedure (SOP) +
o Key Deliverables User Manuals
o System Requirements o Deploy system
o Conduct acceptance tests
o Functional Definitions (+ allocation of

© 2021 CLOUD EDUCATION GROUP LIMITED 55


Rational Unified Process (RUP)

© 2021 CLOUD EDUCATION GROUP LIMITED 56


Rational Unified Process (RUP)
• Use cases drives requirements (Business Needs/Concept Exploration)
o System, software, and security engineers create operational use cases (e.g., operational,
functions, threat, risks models)
o Use cases drives operational requirements
• System design drives design specifications (Concept Definition/Detailed Design)
o Operational requirements are decomposed into system functions and functional requirements
o Architecture organizes system functions allocation of functional requirements
o Architecture is further decomposed into detailed system design
o Detailed system design is explained in design specifications
• Design specifications drives programming of software codes
(Implementation/Coding/Integration/Testing)
o Software components integrated into functional components/subsystems (Unit Testing)
o Functional subsystems integrated into system (/systems) (System Testing)
o System perform functions that meets the operational needs (Acceptance Testing)
• Deployment/transition into operations

© 2021 CLOUD EDUCATION GROUP LIMITED 57


Integrated System/Security Engineering in RAD

© 2021 CLOUD EDUCATION GROUP LIMITED 58


Software Development Security Domain Topics
• 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

© 2021 CLOUD EDUCATION GROUP LIMITED 59


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 part of the trusted computing base that implements
reference monitor concept.

© 2021 CLOUD EDUCATION GROUP LIMITED 60


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
o The reference validation mechanism must be tamper proof
o The reference validation mechanism must always be invoked
o 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.

© 2021 CLOUD EDUCATION GROUP LIMITED 61


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:
o Process activation
o Execution domain switching
o Memory protection
o Input/output operation

© 2021 CLOUD EDUCATION GROUP LIMITED 62


Secure Kernel
• Secure kernel is an implementation
of a reference monitoring mechanism
responsible for enforcing security
policy.
• It meets the following three (3)
conditions
o Completeness ‐ All accesses to
information must go through the kernel
o Isolation ‐ The kernel itself must be
protected from any type of
unauthorized access
o Verifiability ‐ The kernel must be proven
to meet design specifications

© 2021 CLOUD EDUCATION GROUP LIMITED 63


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
o Ring 0 contains kernel functions of the OS
o Ring 1 contains the OS
o Ring 2 contains the OS utilities
o Ring 3 contains the applications

© 2021 CLOUD EDUCATION GROUP LIMITED 64


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
• Application in Ring 3

© 2021 CLOUD EDUCATION GROUP LIMITED 65


Same principles, but different technology thus
different attacks
• Reference monitoring principles is consistent even with virtualization:
Violation of privilege
o Hypervisor vulnerabilities. Attack of kernel (Ring 0)
o Hypervisor escape vulnerabilities. Violation
of isolation of guest VMs (Ring 0)
o Administrative VM vulnerabilities
 Management server vulnerabilities.
Exploitation of virtualized system
configuration. (Ring 0)
 Management console vulnerabilities.
Attacks of privileged state (Entire TCB)
o 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)

© 2021 CLOUD EDUCATION GROUP LIMITED 66


Example of Processor Privilege States –
Many‐ to‐Many
• VMware vSphere further abstracts the hardware layer
o Virtual Machine File System (VMFS) for abstraction of data storage
o vNetwork Distributed Switch (vDS) for abstraction of network layer
o vMotion for distribution of processing power and high availability

© 2021 CLOUD EDUCATION GROUP LIMITED 67


More complexity, more attack surfaces ‐
Examples
• Hypervisor vulnerability:
o CVE 2010 2070: Xeon IA 64 architecture, allows local user to modify processor status register that can cause DoS
. (CVSS: 4.9 [Medium])
• Hypervisor escape vulnerability:
o 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:
o CVE 2008 2097: Buffer overflow in VMware ESX management service that allows remote authenticated users to
gain root privileges. (CVSS: 9.0 [High])
o CVE 2008 4281: Directory traversal in VMware ESXi that allows VM administrators to gain elevated privileges.
(CVSS: 9.3 [High])
o 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:
o 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])
o 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])

© 2021 CLOUD EDUCATION GROUP LIMITED 68


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

© 2021 CLOUD EDUCATION GROUP LIMITED 69


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
o Practice good SDLC process (code inspection & walkthrough)
o Programmer implementing parameter checks and enforce data rules
o Apply patches for OS & applications
o If available, implement hardware states and controls for memory protection
o Buffer management for OS

© 2021 CLOUD EDUCATION GROUP LIMITED 70


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

© 2021 CLOUD EDUCATION GROUP LIMITED 71


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

© 2021 CLOUD EDUCATION GROUP LIMITED 72


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

© 2021 CLOUD EDUCATION GROUP LIMITED 73


Cryptography
• Cryptography provides confidentiality, integrity, authentication, and non‐
repudiation in information operations.
o Asymmetric Key Cryptography
 Because of slow cipher operation speed, it is mostly used for key management
function.
o 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.
o Hash Function
 Message Digest
 Message Authentication Code (MAC)
 Key hashed MAC (HMAC)
o Digital Signature

© 2021 CLOUD EDUCATION GROUP LIMITED 74


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

© 2021 CLOUD EDUCATION GROUP LIMITED 75


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)
o Define elements of a process or work function
o 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.
o Limit users and system processes to access only resources necessary to perform
assigned functions
• Separation of system environments
o Development environment
o QA/test environment
o Production or operational environment

© 2021 CLOUD EDUCATION GROUP LIMITED 76


Other Security Controls
• Social Engineering
o Countermeasure: User security awareness training
• Backup, Malicious Code/Malware, Virus Protection Controls
o 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
o Install Sandbox for access control of mobile codes
o 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

© 2021 CLOUD EDUCATION GROUP LIMITED 77


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

© 2021 CLOUD EDUCATION GROUP LIMITED 78


Software Development Security Domain Topics
• 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

© 2021 CLOUD EDUCATION GROUP LIMITED 79


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

© 2021 CLOUD EDUCATION GROUP LIMITED 80


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

© 2021 CLOUD EDUCATION GROUP LIMITED 81


Object Oriented Programming (OOP) ‐
Characteristics
• Object is an instance of the class
• Class tell the system how to make objects
• Encapsulation is the technique of keeping together data structures and
methods (procedures) which act on them
• Method is a procedure or routine associated with one or more classes
• Message is objects perform work by sending messages to other objects
• 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

© 2021 CLOUD EDUCATION GROUP LIMITED 82


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)
o 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

© 2021 CLOUD EDUCATION GROUP LIMITED 83


Distributed Object Oriented Systems
• Common Object Request Broker Architecture (CORBA)
o 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)
o 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
o Java Platform Standard Edition (Java SE)
o Java Platform Enterprise Edition (Java EE)

© 2021 CLOUD EDUCATION GROUP LIMITED 84


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

© 2021 CLOUD EDUCATION GROUP LIMITED 85


How CORBA Works

• CORBA uses Interface Definition Language (IDL) to describe interface requirements.


• CORBA uses Internet Inter‐ORB Protocol (IIOP) to communicate between Object
Request Brokers (ORBs).

© 2021 CLOUD EDUCATION GROUP LIMITED 86


Component Object Models
• Component Object Model (COM) architecture
o 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
o An extension of COM to support objects distributed across a network

© 2021 CLOUD EDUCATION GROUP LIMITED 87


Component Object Models

COM

DCOM

© 2021 CLOUD EDUCATION GROUP LIMITED 88


Object Linking & Embedding (OLE)
• OLE allows applications to share functionality by live data exchange and
embedded data
o Embedding ‐ places data in a foreign program
For example: Embedding of a Visio diagram inside of a PowerPoint slide
o 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

© 2021 CLOUD EDUCATION GROUP LIMITED 89


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
o ActiveX Controls ‐ interactive objects in a web page that provides user interaction
functions
o ActiveX Documents ‐ enable user to view non HTML documents (e.g. Word, Excel, or
PPT)
o ActiveX Scripting Controls ‐ integrated controls for ActiveX controls and/or Java
Applets from web browser or server
o Java Virtual Machine (JVM) ‐ enables web browser (IE) to run Java applets and
integrate with ActiveX controls
o ActiveX Server Framework ‐ provide web server functions to support the above
functions plus objects for database access and online transactions

© 2021 CLOUD EDUCATION GROUP LIMITED 90


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
o Java SE (Standard Edition)
o Java EE (Enterprise Edition)
o Java ME (Micro Edition)

© 2021 CLOUD EDUCATION GROUP LIMITED 91


Java Platform Enterprise Edition
• Java Enterprise Edition (Java EE) uses Java SE as a foundation
• There are Containers are the runtime components for Java EE.
o Applet
o Application Client
o Web
o EJB

© 2021 CLOUD EDUCATION GROUP LIMITED 92


Java Application Server Architecture

© 2021 CLOUD EDUCATION GROUP LIMITED 93


Software Development Security Domain Topics
• 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

© 2021 CLOUD EDUCATION GROUP LIMITED 94


Database Management System (DBMS)
• Databases are developed to manage information from many sources in one
location
o Eliminate the need for duplication of information in the system (thus preserves
storage space)
o 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)
o Enables Multiple Users and Applications to access, view, and modify data as Needed.
o Can enforce control restrictions
o Provides data integrity and redundancy
o Established procedures for data manipulation

© 2021 CLOUD EDUCATION GROUP LIMITED 95


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

© 2021 CLOUD EDUCATION GROUP LIMITED 96


Relational DBMS (RDBMS)
• Information records (data) are structured in database tables
o Columns (attributes) represent the variables
o Rows (records) contain the specific instance of information records
• Atomic relation = Every row/column position has always exactly one data
value and never a set of values

© 2021 CLOUD EDUCATION GROUP LIMITED 97


Relational DBMS (RDBMS) ‐ Primary & Foreign
Keys
• Data within the RDBMS
o Unique ID is the “primary key”. It identifies each row (record or tuple)
o Tuple cannot have a null value in the primary key
o The primary key value guarantees that the tuple is unique
o “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

© 2021 CLOUD EDUCATION GROUP LIMITED 98


Relational DBMS (RDBMS) ‐ Primary & Foreign
Keys

© 2021 CLOUD EDUCATION GROUP LIMITED 99


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

© 2021 CLOUD EDUCATION GROUP LIMITED 100


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)

© 2021 CLOUD EDUCATION GROUP LIMITED 101


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

© 2021 CLOUD EDUCATION GROUP LIMITED 102


OODBMS &ORDBMS
• Object oriented database (OODB) represents a “paradigm shift” in the
traditional database models (hierarchical, network, and relational)
o Example of OODBMS: Versant
• Object relations are build dynamically based on “business needs” instead of
a series of fixed “business processes”
o 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
o Example of ORDBMS: Oracle (8i, 9i, 10g), IBM DB2

© 2021 CLOUD EDUCATION GROUP LIMITED 103


Data Warehousing and Mining
• Data Warehousing
o Combines data from multiple databases or data sources into a large database called
“data warehouse”
o Requires more stringent security because all data is in a central facility
• Data Mining
o A.k.a. Knowledge discovery in databases (KDD)
o Practice of automatically searching large stores of data for patterns
o Data mining tools are used to find associations and correlations to product Metadata
and can show previously unseen relationships

© 2021 CLOUD EDUCATION GROUP LIMITED 104


Database Controls
• Granularity ‐ The degree to which access to objects can be restricted.
• Content dependent access control
o 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
o Cell Suppression
 A technique used to hide or not show specific cells that contain information that
could be used in an inference attack

© 2021 CLOUD EDUCATION GROUP LIMITED 105


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
o Making sure the most up to date information is available
o 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

© 2021 CLOUD EDUCATION GROUP LIMITED 106


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

© 2021 CLOUD EDUCATION GROUP LIMITED 107


Database Controls ‐ Configurable Controls for
Integrity
• Rollback ‐ is a statement that ends a current transaction and cancels all other
changes
o 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.
o 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

© 2021 CLOUD EDUCATION GROUP LIMITED 108


Database Security Controls
• Polyinstantiation
o Allows a relation to contain multiple rows with the same primary key
o The multiple instances of Primary Keys are distinguished by their security levels
o Used to prevent inference attacks by inserting “bogus” data at lower security levels
• Granularity ‐ The degree to which access to objects can be restricted
o 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

© 2021 CLOUD EDUCATION GROUP LIMITED 109


Database Security Issues
• Online Transaction Processing (OLTP)
o Usually used when multiple databases are clustered to provide fault tolerance and
higher performance
o Transaction logs are used for synchronization of databases
o 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

© 2021 CLOUD EDUCATION GROUP LIMITED 110


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

© 2021 CLOUD EDUCATION GROUP LIMITED 111


Software Development Security Domain Topics
• 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

© 2021 CLOUD EDUCATION GROUP LIMITED 112


Relationship between Threat, Risk, and
Countermeasure
• Threat source Entity that may acts on a
vulnerability
• Threat Any potential danger to
information life cycle
• Vulnerability A system has weakness or
flaw that may provide an opportunity to a
threat source
• Risk The likelihood of a threat source take
advantage of a vulnerability
• Exposure An instance of being
compromised by Threat Source
• Countermeasure / safeguard An
administrative, operational, or logical
mitigation against potential risk(s)

© 2021 CLOUD EDUCATION GROUP LIMITED 113


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

© 2021 CLOUD EDUCATION GROUP LIMITED 114


Common Weakness Enumeration (CWE)
• CWE is an online dictionary of software weaknesses

https://cwe.mitre.org
© 2021 CLOUD EDUCATION GROUP LIMITED 115
2020 CWE/SANS Top 25 Most Dangerous
Programming Errors
Rank ID Name
1 CWE‐119 Improper Restriction of Operations within the Bounds of a Memory Buffer
2 CWE‐79 Improper Neutralization of Input During Web Page Generation ('Cross‐site Scripting')
3 CWE‐20 Improper Input Validation
4 CWE‐200 Information Exposure
5 CWE‐125 Out‐of‐bounds Read
6 CWE‐89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
7 CWE‐416 Use After Free
8 CWE‐190 Integer Overflow or Wraparound
9 CWE‐352 Cross‐Site Request Forgery (CSRF)
10 CWE‐22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
11 CWE‐78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
12 CWE‐787 Out‐of‐bounds Write
13 CWE‐287 Improper Authentication
14 CWE‐476 NULL Pointer Dereference
15 CWE‐732 Incorrect Permission Assignment for Critical Resource
16 CWE‐434 Unrestricted Upload of File with Dangerous Type
17 CWE‐611 Improper Restriction of XML External Entity Reference
18 CWE‐94 Improper Control of Generation of Code ('Code Injection')
19 CWE‐798 Use of Hard‐coded Credentials
20 CWE‐400 Uncontrolled Resource Consumption
21 CWE‐772 Missing Release of Resource after Effective Lifetime
22 CWE‐426 Untrusted Search Path
23 CWE‐502 Deserialization of Untrusted Data
24 CWE‐269 Improper Privilege Management
25 CWE‐295 Improper Certificate Validation

© 2021 CLOUD EDUCATION GROUP LIMITED 116


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

© 2021 CLOUD EDUCATION GROUP LIMITED 117


Reduce / Eliminate Software Vulnerabilities
• Addressing structural/design flaws
o Understand the information protection needs
o Develop use/abuse cases
o Define system security requirements
o Design system architecture
o Develop detailed system design & security controls
• Addressing software bugs (weaknesses)
o Develop detailed software design & specifications
o Implement code reviews
o Static code analyzers
o Perform tests
o Unit, subsystems, system, acceptance tests
o Vulnerability scanners

© 2021 CLOUD EDUCATION GROUP LIMITED 118


Threats to Software Buffer Overflow
• One of the oldest and most common problems to software
o Wagner et. al. estimated over 50% of all vulnerabilities are due to buffer overflow
• No. 1 in 2020 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

© 2021 CLOUD EDUCATION GROUP LIMITED 119


Threats to Software Buffer Overflow
• Recommended countermeasure to prevent buffer overflow attacks
o Patch, patch, and patch
o Always check for inputs. Enforce controls at the interfaces
o Ensure applications are not exposed to faulty components
o Use language and frameworks that are relatively “immune” to buffer overflows

© 2021 CLOUD EDUCATION GROUP LIMITED 120


Threats to Software Cross site Scripting (XSS)
• XSS is one of the most prevalent web application (web‐app) security flaw
• No. 2 in 2020 CWE/SANS Top 25 and OWASP Top 10.
o 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.
o These “untrusted data” could be JavaScript, or other browser executable RIA
contents such as Active X, Flash, Silverlight, etc.
• Recommended countermeasures to prevent XSS attacks:
o Never insert untrusted data except in allowed locations
o Use “escaping” (a.k.a. output encoding) technique
o Use an HTML policy engine to validate or clean user driven HTML in an outbound
way
o Prevent DOM‐based XSS
o Use “HTTPOnly” cookie flag

© 2021 CLOUD EDUCATION GROUP LIMITED 121


Threats to Software SQL Injection
• In 2020, SQL Injection is No.1 in both CWE/SANS Top 25 and OWASP Top 6
• SQL injection occurs when an application sends “untrusted data” to an
interpreter as a part of command or query
o These “untrusted data” can be in SQL queries, LDAP queries, Xpath queries, etc.
• Attackers can
o 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.)
o Trick the interpreter to execute unintended commands

© 2021 CLOUD EDUCATION GROUP LIMITED 122


Threats to Software SQL Injection

© 2021 CLOUD EDUCATION GROUP LIMITED 123


Threats to Software SQL Injection
• Recommended countermeasures to prevent SQL injection attacks:
o Use “prepared statements” (/ parameterized queries) such as
 Java EE use PreparedStatement() with bind variables
 .NET use parameterized queries like SqlCommand() or OleDbCommand() with
binding variables
 PHP use PDO with strongly typed parameterized queries (use binParam())
o Use stored procedures
o Escaping all “user supplied” inputs. Treat user inputs as untrusted data, don’t insert
them directly as a part of a SQL query

© 2021 CLOUD EDUCATION GROUP LIMITED 124


Threats to Software ‐ OS Command Injection
• OS Command Injection (a.k.a. Shall Injection) is 11th in 2020 Top 25 CWE
o Attacker injects and execute unwanted system commands through vulnerable
applications that lacks proper input data validation (e.g., forms, cookies, HTTP
headers etc.)
o As with SQL Injection, it is a variant of Code Injection attack, except it utilizes
applications running as “system” instead of “user”
• Recommended countermeasure
o Validate inputs
o Use application provided API
o Run automated code analysis tools

© 2021 CLOUD EDUCATION GROUP LIMITED 125


Use of Automated
Analysis Tools
• For detection of structural flaws • For detection of software weakness
(“defects”) (“bugs”)
o Tool integration frameworks (a.k.a. o Static code analysis tools
IDEs)  Source code security analyzers, byte
o Software engineering management, code scanners, binary code scanners
architecture/design modeling (MBSE), o Dynamic analysis tools
requirements traceability, design
patterns  Web application vulnerability
scanners, database vulnerability
o Code quality review tools scanners
o Network vulnerability scanners
 SCAP compatible security
configuration scanners

© 2021 CLOUD EDUCATION GROUP LIMITED 126


Malicious Code / Malware
• Malicious code / malware (Malicious software)

• For CISSP, there are many types of “malware”


o Viruses
o Worms
o Trojan horses
o Rootkits
o Spyware
o Some cookies…

© 2021 CLOUD EDUCATION GROUP LIMITED 127


Malware as a Threat to Information Operations
• Operations are getting better at addressing insider threats

• The fact is that most of threats are still from


external threat agents

© 2021 CLOUD EDUCATION GROUP LIMITED 128


Malware as a Threat to Information Operations
• Most of data breaches are from hacking and malware

• Majority of malware are installed remotely

© 2021 CLOUD EDUCATION GROUP LIMITED 129


Malware as a Threat to Information Operations
• Advanced Persistent Threat (APT) is very real
o Malware is now a tool for hackers
o They are stealing data

© 2021 CLOUD EDUCATION GROUP LIMITED 130


Threats to Software Malicious Code / Malware
• Malicious code / malware (MALicious softWARE)
o 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.
o 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.

• 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.

• 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.

© 2021 CLOUD EDUCATION GROUP LIMITED 131


Threats to Software Malicious Code / Malware
• 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.
o 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.

• 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

© 2021 CLOUD EDUCATION GROUP LIMITED 132


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.

© 2021 CLOUD EDUCATION GROUP LIMITED 133


Threats to Software Malicious Code / Malware
• 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.

© 2021 CLOUD EDUCATION GROUP LIMITED 134


Sample Question ‐ 1

© 2021 CLOUD EDUCATION GROUP LIMITED 135


Sample Question ‐ 2

© 2021 CLOUD EDUCATION GROUP LIMITED 136


Sample Question ‐ 3

© 2021 CLOUD EDUCATION GROUP LIMITED 137


Sample Question ‐ 4

© 2021 CLOUD EDUCATION GROUP LIMITED 138

You might also like