- Forward
An Introduction to CS531
Secure Programming


Prof. David Bernstein
James Madison University

Computer Science Department
bernstdh@jmu.edu

Print

Objective of CS531
Back Forward
  • A Casual Statement of the Objective:
    • Help you learn how to write secure software
  • Required for a Careful Statement of the Objective:
    • An understanding of the process(es) used to write software
    • A careful definition of some terms
Purposes of Today's Meeting
Back Forward
  • Discuss some of the topics that are necessary to create a careful statement of the objectives of this course
    • Software Processes
    • Software Products
    • Software Quality
    • CS531 from a Process Perspective, a Quality Perspective, and an Operational Perspective
  • Discuss the course and my expectations
Processes
Back Forward
  • A Definition:
    • A process (a.k.a. activity) is a collection of related tasks (a.k.a. actions) that transforms a set of inputs into a set of outputs.
  • An Observation:
    • The set of algorithms is a subset of the set of processes (which, includes, for example heuristics)
  • Describing Processes:
    • Specify the inputs to and outputs from the process
    • Specify the tasks
    • Specify the inputs to and outputs from each task (a.k.a. data flows)
    • Specify the order of tasks and the conditions under which they occur (a.k.a. control flows)
Software Processes
Back Forward
  • Definition:
    • A software process is a set of activities/tasks (and corresponding inputs and outputs) that results in the specification, development, validation, and/or evolution of a software product
  • An Observation:
    • Software processes are very complex and, hence, our discussion of them will necessarily involve abstraction
Common Activities in Software Processes
Back Forward
  • Project Planning:
    • Financial/economic analysis
    • Scheduling
    • Resource allocation
    • Cost estimation
    • Risk management
  • Product Design:
    • Identification of needs and desires
    • Specification of requirements
    • Prototyping
  • Engineering Design:
    • Creation of static models
    • Creation of dynamic models
    • Consideration of architectural styles and design patterns
  • Implementation:
    • Development
    • Code/documentation management
    • Debugging
    • Verification and validation
  • Deployment
  • Support and Maintenance
Software Products
Back Forward
  • What People (Other than Us) Care About:
    • Having everything they need to solve one or more problems or achieve one or more goals (i.e., a complete means to one or more ends)
  • Definition:
    • A software product is one or more programs, sub-programs, or libraries, along with the data and supporting materials and services, that a client can use to solve problems or achieve goals
Some Important Terms Related to Software Products
Back Forward
  • Defect - any undesirable aspect of a product
  • Failure - a deviation between a product’s actual behavior and intended behavior (e.g., a feature that is missing or incorrect)
  • Fault - a defect that could (or does) give rise to a failure
  • Trigger - a condition that causes a fault to result in a failure
Properties of Software Products
Back Forward
  • Reliable - Low probability of failure under normal operating conditions
  • Robust - Able to operate without failure under a wide variety of condtions
  • Safe - Able to minmize the damage resulting from failure
  • Secure - Low probability of failure as a result of operating conditions that are intended to cause a failure
Quality Assurance
Back Forward
  • Definition:
    • Quality assurance (QA) is a systematic pattern of activities intended to ensure that a product properly satisfies the needs and desires of its stakeholders.
  • Activities:
    • Validation is the process of determining if a product (or its specification) satisfies stakeholders’ needs and desires ("Are we building the right product?")
    • Verification is the process of determining if a product (or its specification) satisfies those needs and desires properly ("Are we building the product right?")
Quality Assurance - An Example
Back Forward
  • The Setting:
    • You are a newspaper reporter and you are told to write an article about homelessness (the product)
  • Validation:
    • You must write about homelessness
    • Note: All validation activities are product specific
  • Verification:
    • You must write properly (e.g., use proper grammar, follow the newspaper's style guide, make a compelling argument)
    • Note: Some verification activities are product-specific (e.g., the quality of the argument) and some are not (e.g., proper grammar)
Defect Elimination - Prevention
Back Forward
  • Process Guides:
    • Standards and guidelines that describe the way everyone in the organization should behave
    • Templates and checklists that make it easier to do so
  • Analysis and Design Methodologies:
    • Well-codified approaches to understanding and solving software-related problems (e.g., OO)
  • Well-Studied Solutions:
    • Reference architecture
    • Design patterns
Defect Elimination - Detection and Removal
Back Forward
  • Review and Correct:
    • Automated tools
    • Manual techniques (e.g., desk-checks, walk-throughs, inspections)
  • Test and Debug:
    • Testing is a validation and verification process that makes use of the system/product (including prototypes) while it is in operation or being operated on
Focus of CS531
Back Forward
  • From a Software Process Perspective:
    • Our concern is with failures that arise from decisions made during construction (and, to some extent, engineering design)
  • From a Software Quality Perspective:
    • We are not concerned with ruggedness (i.e., reliability, robustness, and safety) though ruggedness and security are often closely related
    • We are principally concerned with defect prevention
  • From an Operational Perspective:
    • We are not concerned with failures that result from network configuration decisions
    • We are not concerned with failures that result from cryptographic decisions
    • We are not concerned with failures that result from policy decisions
Side Benefits of Taking CS531
Back Forward
  • You may learn some specific languages that you are unfamiliar with (and, at worst, you'll have to review them)
  • You may learn about some tools that you are unfamiliar with (though this will be entirely up to you)
  • You will become better at reviewing code and documentation written by others
About Prof. Bernstein
Back Forward
  • The Early University Years
  • Working for a Living
  • The Quest for a Ph.D.
  • The Esteemed Professor
  • Now
About You
Back Forward
  • Time Allocation:
    • Full-time graduate students take 3 courses per semester
    • Being a full-time graduate students requires at least as many hours as being a full-time employee (e.g., 45 hrs/week)
    • You should expect to spend 15 hrs/week on a graduate course
  • Languages You Must Know or Learn on Your Own:
    • C
    • Java
  • Language You May Know but I'll Lecture On (Briefly):
    • HTML/CSS
    • JavaScript
    • PHP
There's Always More to Learn
Back -