Terms and Definitions

Extreme Programming (XP)—an Agile method that uses pairs of

programmers
Object-Oriented Design—A “black box” approach to the design of
code, or equipment, or systems
Object-Oriented Programming— group lines of code together
“black box” as objects to run as a unit of code.
Spiral Model—a software model designed to control risk
Systems Development Life Cycle— focuses on security in every
phase
Waterfall Model—model that uses rigid phases; when one phase
ends, the next begin
 PROGRAMMING CONCEPTS
• Machine code - (also called machine language) Executed directly
by the CPU, CPU-dependent; A series of 1s and 0s that translate to
instructions that are understood by the CPU.
• Source code - instructions which are written in text that must be
translated into machine code before execution by the CPU.
• High-level languages English-like instructions such as “printf”
• Assembly language Low-level computer programming language.
Assembly language instructions are short mnemonics, such as
“ADD,” “SUB” (subtract), and “JMP” (jump), that match to machine
language instructions.
• Assembler - convert assembly language into machine language.
• Disassembler - convert machine language into assembly
Compilers, Interpreters, and Bytecode
• Compilers - take source code, i.e. C or Basic, and compile it
into machine code, and saves the results as an executable
• Interpreter - Code is interpreted line by line each time the
program is run.
• Bytecode, i.e Java bytecode, is also interpreted code.
Bytecode exists as an intermediary form (converted from
source code), but still must be converted into machine
code before it may run on the CPU
 Scrum

• Scrum Team - small teams of developers

• Scrum Master - a senior member of the
organization, offering advocacy and support
for the team
Product Owner is the voice of the business
unit to the development (Scrum Team)
 Secure SW Development Life Cycle
(SDLC)
• SDLC focuses on security in every phase
• Focusing on the entire system, from selection/development, operational
requirements, to secure disposal

• Contain five basic phases

1 - Initiation,
Secure Software Development
2 - Development/acquisition,
(first 3 phases)
3 - Implementation, assessment

4 - Operation and maintenance Secure Operations Life Cycle (last 2

5 - Disposal phases)
 SDLC - Initiation
• Document need and purpose for the software
• Conduct a Sensitivity Assessment:
– Look at the security sensitivity of the software
and the information to be processed
 SDLC Acquisition/Development
(The system is purchased or developed)

• 1. Determine Security Requirements:

• Technical features (access controls),
• assurances (background checks for system developers),
• operational practices (awareness and training).
• 2. Incorporate Security Requirements Into
Specifications:
• Incorporated step 1 above in the project plan.
• 3. Obtain the System and Related Security Activities:
• Develop the system’s security features,
• Monitor development for security issues, responding to
changes, and possible threats.
 SDLC – Implementation/Assessment
(The system is installed and tested)

• 1. Install/Turn-On Controls:
• Turn on, configure and enable all security features.
• 2. Security Assessment:
• Certify/assess the system;
• testing security management, physical facilities, personnel,
procedures, the use of commercial or in-house services
(such as networking services), and contingency planning.
• 3. Authorization:
• The formal approval to operate by authorization
official (management)
• Explicit acceptance of risk.
 Operation/Maintenance:
(System is modified/updated/audited as necessary)
• 1. Security Operations and Administration:
• Include backups, training, managing cryptographic keys, user
administration, and patching.
• 2. Operational Assurance:
• Check whether system is operated to its current security
requirements.
• 3, Audits and Monitoring:
• Audit to evaluate five Trust service Principles (CIA + Security and
Privacy)
• Time or Event based
• 4. Monitoring – NIST 800-137
• ongoing system/software/user assessments per step 3 above
 Disposal
(The secure decommission of a system)
• Data location considerations:
• Data may be moved to another system, archived,
discarded, or destroyed.

• Media Sanitization:
• Delete/Erase/ High level format
• Overwrite seven times
• Degauss
• Physical Destruction
• Cloud Computing
• Crypto-Erase or Crypto-Shredding
Web Vulnerabilities OWASP
 Software Testing Methods
• Static –
• tests/review the code passively: the code is not running.
• Dynamic –
• tests the code while executing it.
• White box
• access to program source code, data structures, variables, etc
• Black box -
• no internal details: the software is treated as a black box that receives inputs.
• A Traceability Matrix –
• map customer’s requirements to the software testing plan: it “traces” the
“requirements,” and ensures that they are being met.
 Software Testing Levels
• Unit Testing:
• Low-level tests of software components, such as functions, procedures or objects
• Installation Testing:
• Testing software as it is installed and first operated
• Integration Testing:
• Testing multiple software components as they are combined into a working system.
• Regression Testing:
• Testing software after updates, modifications, or patches
• Acceptance Testing:
• testing to ensure the software meets the customer’s operational requirements. When done
directly by the customer, it is called User Acceptance Testing
• Fuzzing (also called fuzz testing)
• black box testing that enters random, malformed data as inputs into software programs to
determine if they will crash.
 Disclosure of Software Vulnerabilities
• Disclosure –
• actions taken by a security researcher after discovering a software
vulnerability

• Full Disclosure –
• Releasing vulnerability details publicly
• Considered unethical because many black may benefit from this
practice; i.e. zero-day exploits (exploits for vulnerabilities with no patch

• Responsible disclosure –
• Privately sharing vulnerability information with vendor, and
• withholding public release until a patch is available.
• Generally considered to be the ethical disclosure option
 Software Capability Maturity Model
(CMM)
• (1) Initial: Characterized as ad hoc or chaotic. Few
processes are defined, and success depends on individual
effort.
(2) Repeatable: Basic project management
(3) Defined: Management and engineering activities is
documented, standardized, and integrated into a standard
software process for the organization.
(4) Managed: Detailed measures of the software process
and product quality are collected, analyzed, and used to
control the process. Both the software process
and products are quantitatively understood and controlled.
(5) Optimizing: Continual process improvement is enabled