Loading...

Domain_08: Software
Development Security

  • Programming Language Generations:

    • First – Machine language (01011010011) [Binary]

    • Second – Assembly Language (al, 061h) [Assembly]

    • Third – High-Level Languages (printf) [COBOL, C, Basic]

    • Fourth – Very High Level (select * from). Increase programmer efficiency [ColdFusion, Oracle Reports]

    • Fifth – Natural Language (father(x,y))

  • Assurance

  • Avoiding and Mitigating System Failure 

    • Input Validation 

    • Authentication & Session Management

    • Error Handling

    • Logging

    • Fail-Secure & Fail Open

  • OOP (Object-Oriented Programming)

    • OOP Concepts:

      • Messages: How objects communicate. Input & output to an object. Requesting/responding 2 calls

      • Methods: Commands defined in a base class and inherited/performed by objects.

      • Behavior: The results or output exhibited by an object is a behavior. Behaviors are the results of a message being processed through a method.

      • Class: User-defined data types

      • Instance: Objects are instances of or examples of classes that contain their methods.

      • Objects: An instance of a base class. Inherits methods and properties & has values for properties

      • Inheritance: Inheriting methods and properties from a parent class

      • Delegation: Sending a function it doesnt understand to another object

      • Polymorphism: (many forms) Performs different operations depending on the message context

      • Polyinstantiation: (many instances) Two or more instances with the same name, different data

      • Coupling: Highly coupled objects require a lot of other objects to perform basic jobs

      • Cohesion: High cohesion objects are more independent. Low cohesion=high coupling

    • OOA/OOAD (Object-Oriented Analysis & Design)

      • Flowchart showing the way data in a program flows & is manipulated

      • Visualized as a series of messages & objects

      • Seeks to understand a problem domain (challenge you‟re addressing) & designs the solution

      • Once OOA/OOAD is completed, an OOP language is used to write the code

  • Systems Development Life Cycle

    • • Conceptual definition

    • • Functional requirements determination

    • • Control specifications development

    • • Design review

    • • Code review walk-through

    • • System test review

    • • Maintenance and change management

  • Software Development Life Cycle

    • • Request/Gather information

      • Security Requirements

      • Security risk assessment

      • Privacy risk assessment

      • Risk-level acceptance

      • Informational, functional, and behavioral requirements

    • • Design

      • Informational model

      • Functional model

      • Behavioral model

      • Attack surface analysis + Threat modeling

    • • Develop

      • Automated CASE tools + Static analysis

    • • Test/Validation

      • Unit, integration, user acceptance, and regression testing

      • Dynamic analysis + Fuzzing + Manual Testing

    • • Release/Maintenance

      • Final security review

  • Technique to Secure Software Development

    • Paramerter Validation & Input Validation

    • Change Management

    • Multi-Factor Authentication

    • Trusted Platform Module Chip

  • Relational database (RDBMS)

    • Database Types

      • Object-Oriented:

        • Persistent objects and procedures stored in a DB

      • Hierarchical:

        • Tree structure with parent-child relationships

      • Network:

        • Represents objects and their relationships

      • Distributed Data:

        • Data stored in more than one DB with logical links

      • Relational Databases:

        • (Most Common) SQL: 2-dimensional tables of related data

    • Database keys

      • Primary Keys:

        • A primary key is selected from the set of candidate keys for a table to be used to uniquely identify the records in a table. Each table has only one primary key, selected by the database designer from the set of candidate keys. The RDBMS enforces the uniqueness of primary keys by disallowing the insertion of multiple records with the same primary key. In the Customers table, the Company ID would likely be the primary key.

      • Candidate Keys:

        • A candidate key is a subset of attributes that can be used to uniquely identify anyrecord in a table. No two records in the same table will ever contain the same values for all attributes composing a candidate key. Each table may have one or more candidate keys, which are chosen from column headings.

      • Alternate Keys:

        • Any candidate key that is not selected as the primary key is referred to as an alternate key. For example, if the email ID is unique to a customer, then email could be considered a candidate key. Since Company ID was selected as the primary key, then email is an alternate key.

      • Foreign Keys:

        • A foreign key is used to enforce relationships between two tables, also known as referential integrity. Referential integrity ensures that if one table contains a foreign key, it corresponds to a still-existing primary key in the other table in the relationship. It makes certain that no record/tuple/row contains a reference to a primary key of a nonexistent record/tuple/row.

      • Referential integrity

        • means that every foreign key in a secondary table matches a primary key in the parent table; if this is not true, referential integrity has been broken.

      • Semantic integrity

        • means that each attribute (column) value is consistent with the attribute data type. Entity integrity means each tuple has a unique primary key that is not null.

  • Software Development Security

    • ACID MODEL

    • Atomicity

      • Entire transaction
        must succeed, else roll back.

    • Consistency

      • Transactions start and end with a
        consistent database

    • Isolation

      • Transactions operate
        separately from each other.

    • Durability

      • Once committed to DB, transactions
        must be preserved

  • Covert Channels

    • Covert Storage Channel

      • Writing to storage by one process and reading by a lower security process

    • Covert Timing Channel

      • One process signaling another process using system resources

  • Software Development Methodologies

    • Waterfall

      • System Rquirements

      • Software Requirements

      • Preliminary Design

      • Detailed Design

      • Code and Debug

      • Testing

      • Operation and Maintenance

    • Spiral 

    • Agile

  • Change and Configuration Management

    • Change Management Process

      • Request Control 

      • Change Control 

      • Release Control 

    • Configuration Management

      • Configuration Identification 

      • Configuration Control 

      • Configuration Status 

      • Configuration Audit 

  • Software Maturity Models

    • Capability Maturity Model (CMM)

      • Level 1: Initial 

        • People moving with
          little no process for software
          development

      • Level 2: Repeatable 

        • Basic lifecycle
          management processes are introduced

      • Level 3: Defined

        • Developers operate according to a set of
          formal
          documented software development
          processes

      • Level 4: Managed 

        • Quantitative measures
          are utilized to gain a detailed
          understanding of the development process.

      • Level 5: Optimizing 

        • A process of
          continuous improvement occurs,
          including a feedback loop.

    • Software Assurance Maturity Model (SAMM)

      • 3 Maturity Level

        • Level 1 - Initial Implementation

        • Level 2 - Structured Realization

        • Level 3 - Optimized Operation

      • 5 Business functions

        • Governamce

          • Strategy & Metrics

          • Policy & Compliance

          • Education and Guidance

        • Design

          • Threat Assessment

          • Security Requirements

          • Secure Architecture

        • Implementation

          • Secure Build

          • Secure Deployment

          • Defect Management

        • Verification

          • Architecture Analysis

          • Requirement Driven Testing

          • Security Testing

        • Operations

          • Incident Management

          • Environment Management

          • Operation Management

    • IDEAL Model

      • I: Initiating

      • 2: Diagnosing

      • 3: Establishing

      • 4: Acting

      • 5: Learning

  • Devops & DevSecops

    • Code Repositories 

      • This is where source code and related artifacts
        (such as libraries) are stored
        ✓ Do not commit sensitive information
        ✓ Protect access to your code repositories
        ✓ Sign your work
        ✓ Keep your development tools (IDE) up-to-date

    • Code Libraries

      • Example: Certain languages are prone to certain types of attacks In lower level languages (like C) use of safe memory
        allocation and string manipulation libraries can reduce
        risk of buffer overflow attacks code libraries for some important core functions can improve application security and reduce risk others encryption, handling secrets, bulk data transfer

    • Runtime

        • describes the period of time during which a
          software program is running
          - this is when dynamic application security testing
          (DAST) evaluates security of an application
          - assessing software security at runtime is
          generally the only option for purchased software

    • CI/CD

        • Implement identity and access management
          (including MFA)                                                                        - store secrets securely and scan code to
          ensure no hard coded secrets
          - Implement role based access control (and
          least privilege access) to the environment
          - automate vulnerability scanning in your
          CI/CD pipeline - release versioning will improve recoverability
          and issues tracking

    • Static Application Security  Testing 

      • analysis of computer software
        performed
        without actually executing programs
        tester has access to the underlying
        framework, design, and implementation
        a program which communicates with a
        web application (executes the application).
        tester has no knowledge of the
        technologies or frameworks that the
        application is built on
        requires source code

    • Dynamic Application SecurityTesting

      • Dynamic testing evaluates the security of software
        in a runtime environment and is often the only option for
        organizations deploying applications written by someone else. In those cases, testers often do not have access to the underlying source code.
        One common example of dynamic software testing is the use of web application scanning tools to detect the presence of cross-site scripting, Structured Query Language (SQL) injection, or other flaws in web applications. Dynamic tests on a production environment should always be carefully coordinated to avoid an unintended interruption of service.

  • Software Testing

    • White-Box Testing

      • White-box testing examines the internal logical structures of a program and steps through the code line by line, analyzing the program for potential errors.                                           The key attribute of a white-box test is that the testers have access to the source code.

    • • Black-Box

      • Testing Black-box testing examines the program from a user perspective by providing a wide variety of input scenarios and inspecting the output. Black-box testers do not have access to the internal code. Final acceptance testing that occurs prior to system delivery is a common example of black-box testing.

    • • Gray-Box Testing

      • Gray-box testing combines the two approaches and is popular for software validation. In this approach, testers examine the software from a user perspective, analyzing inputs and outputs. They also have access to the source code and use it to help design their tests. They do not, however, analyze the inner workings of the program during their testing.

  • Application Programming Interfaces (API)

    • Types of API

      • SOAP

      • REST

      • GraphQL