7.2-0-D8-October2021 (Software Development Security)

Software Development
Security
(Understanding, Applying, and Enforcing Software Security)
Test Objectives at a Glance
• 8.1 Understand and integrate security in the Software
Development Life Cycle (SDLC)
• 8.2 Identify and apply security controls in software
development ecosystems
• 8.3 Assess the effectiveness of software security
• 8.4 Assess security impact of acquired software
• 8.5 Define and apply secure coding guidelines and
standards
Domain 8: SW Development Security 2

Domain Objectives 8.1
8.1 Understand and integrate security in the Software
Development Life Cycle (SDLC)
• Development methodologies (e.a. Agile, Waterfall, DevOps,
DevSecOps)
• Maturity models (e.g. Capability Maturity Model (CMM), Software
Assurance Maturity Model (SAMM))
• Operation and maintenance
• Change management
• Integrated product team (IPT)

Systems Development Life Cycle (SDLC)
• Focuses on security at every level
• Used to plan, execute, and control a software development
project
• Security plan is the first step of any SDLC model
• Multiple models of the SDLC
• Most models contain 5 basic phases:
• Initiation
• Development/acquisition
• Implementation
• Operation
• Disposal

Systems Development Life Cycle (ISC)2
System Development Lifecycle System Lifecycle has
Phases two additional Phases
• Project Initiation and planning • Operations and
• Functional Requirements Definition Maintenance
• System Design Specifications Support
• Development and Implementation • Decommissioning/
• Documentation and Common Disposal and System
Program Controls Replacement
• Testing and
EvaluationControl(Certification/Acc
reditation)
• Transition to Production
Project Initiation and Planning Security
Activities
• Determine security requirements
• Conduct risk analysis
• Define security strategy

Functional Requirements Specifications
Security Activities
• Identify Security Areas
• Establish security requirements
• Security tests
• Define strategy
• Develop functional baseline

Detailed Design Specifications Security
Activities
• Establish security specifications
• Update security test plans
• Document security baseline

Development and Documentation Security
Activities
• Develop security code
• Evaluation of security code
• Document security code

Testing, Acceptance, and Transition into
Production Security Activities
• Test security components
• Validate security in integrated systems
• Implement security code
• Document security controls
• Certify secure operations
• Accept secure system

Software Development Methods
Requirements
Analysis
Waterfall Lifecycle Method
Design Measure Twice,
• Finish one stage prior to starting Cut Once
Development
the next Testing
• Requires formal reviews before Maintenance
moving into the next phase
• Heavy overhead in planning and
administration
• No changes once the project is started
• Paradigm for non-iterative models
• Non-iterative are more secure
Spiral Model
• Non-iterative
• Estimated costs and schedules are revised at the end of
each risk assessment
• Decision to proceed/cancel project is revisited after
each risk assessment
• Nested waterfall phases
• Each phase has 4 sub phases
• Phases based on Deming PDCA
• Plan, do, check, act

Build and Fix
• Simplest and least disciplined method
• Useful for small development projects where quality is not
essential.
• Not a recommended software development practice.
1. Developer creates the first version of the program with
limited specification and design
2. Software developer may sketch out a functional or technical
design based on customer needs
3. From the initial project, the software is repeatedly modified
until the customer is satisfied.
Incremental Method
• A repetitive mini waterfall
• A series of small, incremental development projects
• Without a complete understanding of ultimate end product,
success may be hard to achieve
1. Determine system requirements
2. Evaluate and prioritize
3. Develop based on priority

Clean Room Model
• Non-iterative
• Write good code the first time
• Controls defects in software
• Quality achieved through design versus testing and
remediation
• Focus is on defect prevention rather than defect
removal

Prototyping Model
• Prototyping
• Iterative
• Developed to combat the weaknesses of the waterfall model
• Refine prototype until acceptable
• 4 Step Process:
• Initial Concept
• Design and Implement Initial Prototype
• Refine Prototype
• Complete and Release

Modified Prototype Model (MPM)
• Modified Prototype Model (MPM)
• Iterative
• Ideal for web application development
• Allows for basic functionality to be deployed in a quick time frame
• Maintenance phase begins after the deployment
• Application evolves as the environment changes (not frozen in
time)

Rapid Application Development (RAD) /
Joint Application Development (JAD)
• Rapid Application Development (RAD)
• Iterative
• Rapid prototyping within strict time limits
• Can be a disadvantage if decisions are made too quickly
• Joint Application Development (JAD)

• Iterative
• Management process that allows developers to work directly with
users. Can help with RAD
• Key players communicate at key phases of development

Exploratory Model
• Requirements built on what is available
• Built on assumptions as to how the system might work
• Consists of planning and trying different designs before development
• Not cost-effective
• Results in less-than-optimal systems
• Iterative

Component Based Model
• Component Based Development
• Involves using standardized building blocks to assemble, rather
than develop, an application
• May be a security advantage as the components have previously
been tested for security
• Similar to Object Oriented Programming (OOP)

Reuse Model
• Reuse Model
• Built from existing components
• Best suited for projects using

object oriented development …
because objects can be
exported, reused, and modified
• Libraries of software modules

are maintained to be copied for
use in any system

Agile Model
• Individuals and interactions over processes and tools

• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• More flexible
• Fast turnaround
• Strong communications
• Customer involvement
• Methods include scrum and extreme programming
Waterfall Model versus Agile Model

Extreme Programming (XP) Model
• Extreme Programming (XP)
• Based on simplicity, communications, and feedback
• Relies on subprojects of limited and defined scope with
programmers working in pairs
• Code quality improves to compensate for second
programmer cost.
• Relies on continuous integration and test-driven
development to produce working software.

Scrum Development Model
• Small teams of developers called
scrum teams
• Scrum master supports the
scrum team
• Product owner makes major
decisions
• The teams take the project from
start to finish, handing off similar
to rugby

DevOps
• An approach based on lean and agile principles in which
business owners and the development, operations, and
quality assurance departments collaborate and work
together to deliver software in a continuous manner that
enables the business to more quickly react to market
opportunities and reduce the time to include customer
feedback into products.
• A set of practices that combines software development and
IT operations.
• It trys to shorten the systems development life cycle and provide
continuous delivery with high software quality.
DevSecOps
• it is short for development, security and operations.
• Make everyone accountable for security with the objective
of implementing security decisions and actions at the same
scale and speed as development and operations decisions
and actions
• DevSecOps tools ensures security is built into applications
instead of added later.
• When security is present during every stage of the software
delivery lifecycle, the cost of compliance is reduced and
software is delivered and released faster
Maturity Models
• A tool for process improvement (capability maturity model)
• Used to evaluate areas of capability or performance and to
point out specific areas of improvement
• May be used as a standard to evaluate a process
• Can be used as a bench mark or score card to evaluate
performance or identify improvement areas.

Maturity Models: Capability Maturity
Model (CMM)
Levels
• Initial
• Managed
• Defined
• Qualitatively managed
• optimizing

Maturity Models: Capability Maturity
Model Integration (CMMI)
Process level improvement program created to integrate an
assessment and process improvement guidelines for separate
organizational functions.
Levels
• Incomplete
• performed
• Managed
• Defined
• Qualitatively managed
• optimizing
Maturity Models: Building Security in Maturity
Model (BSIMM) & Software Assurance Maturity
Model (SAMM)
BSIMM: Descriptive software security focused maturity
model based on actual software security initiatives. Available
under the creative commons license. An evidence based
model as it reflects real world industry activities.
SAMM: framework to help organizations formulate and

implement a security software strategy that is tailored to the
specific risks facing an organization (prescriptive framework).
Maintained by OWASP. Based on: governance, construction,
verification, and operations

Integrated Product Team
• An Integrated Product Team (IPT) is a multidisciplinary group
of people who are collectively responsible for delivering a
defined product or process.
• IPTs are used in complex development programs/projects
for review and decision making.
• The emphasis of the IPT is on involvement of all
stakeholders (users, customers, management, developers,
contractors) in a collaborative forum

Integrated Product and Process
Development (IPPD)
• Combine product design and process design to better
understand product requirements
• Facilitates meeting cost and performance objectives
• Facilitates multi-skilled team members working together
through the concept of integrated product teams
• Allows for team decisions to made from input from the
entire team.

8.2 Identify and apply security controls in software development
ecosystems
• Programming languages
• Libraries
• Tool sets
• Integrated Development Environment (IDE)
• Runtime
• Continuous Integration and Continuous Delivery (CI/CD)
• Security Orchestration, Automation, and Response (SOAR)
• Software Configuration Management (SCM)
• Code repositories
• Application security testing (e.g., Static Application Security Testing (SAST),
Dynamic Application Security Testing (DAST))

Application Development Methodology
• Programming Language Evolution
1. Machine
2. Assembler
3. High-level
4. Very high level
5. Artificial Intelligence
• Source code vs. Machine code

• Interpreters, Compilers, and Assemblers

Object Oriented Technology and
Programming
• Message - how objects communicate
• Method - functionality an object can carry out
• Behavior - results or output of an object
• Classes - collection of common methods from a set of
objects that defines their behavior
• Instance - examples of classes containing their method
• Delegation - forwarding of a request by an object to another
object
• Cohesion and Coupling - (next slide)
Object Oriented Technology and
Programming
• Coupling
• Level of interaction between objects
• Low coupling means less interaction
• Low coupling is easier to troubleshoot
• Cohesion
• Degree to which an object depends on other objects
• High cohesion: low dependence on other objects
• High cohesion is easier to troubleshoot

Object Oriented Security
• Encapsulation (data hiding)
• Protects private data from outside access
• Polymorphism
• How different objects respond to the same
command (two like objects can have the same
input but have different outputs)
• Inheritance (code reuse)

• Occurrence when methods from a class
(parent) are inherited by a subclass (child)
Libraries
• 3rd party libraries are one of the highest security risks
• Hacker focus has shifted from operating systems to
applications.
• All categories of applications tend to use third-party libraries
to accelerate the development process.
• Most critical vulnerabilities in third-party libraries are
disclosed as Common Vulnerabilities and Exposures (CVEs)
• Applications that use them are not updated in a timely manner.
• CVEs do not represent all of the vulnerabilities found in third-party
software, and other unidentified weaknesses may exist.

Computer-Aided Software Engineering
(CASE)
• Tools using computers and computer utilities to support
software engineering tasks and activities in the process of
developing software
• Examples are compilers, assemblers, linkers, translators,

loaders/debuggers, program editors, code analyzers, and
version control mechanisms
• When the CASE tools are integrated: ICASE

Integrated Development Environment
(IDE)
• Enables programmers to consolidate different aspects of program
writing
• Facilitate the programming process with special features like
syntax highlighting and autocomplete, etc.
• May provide tools for debugging, compiling, formation of builds,
etc.
• Can aid in code review and help in catching syntax errors.

Runtime
• The period of time when a program is running.
• It begins when a program is opened (or executed)
• Ends with the program is quit or closed.
• Term most often used in software development.

Runtime Code
• Some code is executed that does not necessary come from the
program that was written.
• This code is necessary for the proper execution of the code that
was written
• This unwritten code was supplied during compilation or assembly

Continuous Integration and Continuous
Delivery (CI/CD)
• Continuous integration (CI) and continuous delivery (CD) are
principles and practices that enable application
development teams to deliver code changes more
frequently and reliably (CI/CD pipeline). The implementation
is also known as the CI/CD pipeline.
• The CI/CD pipeline is one of the best practices for devops
teams to implement, for delivering code changes more
frequently and reliably

Security Orchestration, Automation, and
Response (SOAR)
• This refers to a collection of software solutions and tools that help
organizations streamline security operations
• It works in three key areas: threat and vulnerability management,
incident response, and security operations automation.
• SOAR lets you automate handling of security operations-related
tasks. It performs tasks—such as scanning for vulnerabilities, or
searching for logs—without human intervention.
• SOAR offers methods of connecting security tools and integrating
disparate security systems. It is the connected layer that
streamlines security processes and powers security automation.

Software Configuration Management
(SCM)
• The task of tracking and controlling changes in the software
part of the larger disciplinary field of Configuration
Management.
• The SCM practices include vision controls in the
establishment of baselines. If something goes wrong, SCM
can determine what was changed and who changed it.
• Examples: Solarwinds, Puppet, Chef

Code Repositories
• Location to store code as the name implies
• A code repository uses versioning systems
• The code repository holds the source code while the version
system software archives that code.
• Code repositories give you a way to tag the different versions,
keeping records of changes within the same project.
• Example: GITHub

Software Escrow
• 3rd party stores archive of software
• Party is neutral
• Stores the source code
• Negotiated as contractual requirement with a software

vendor
• Protects the purchaser should the vendor go out of business

Application security testing (e.g., Static Application
Security Testing (SAST), Dynamic Application Security
Testing (DAST))
• SAST = White Box Testing
• DAST = Black Box Testing

Software Testing Methods
• Test from multiple angles
• Test from low to high
• Methods:
• Static/Dynamic
• White/Black box
• Traceability Matrix

Software Testing Levels
• Testing levels:
• Interface testing
• Alpha/Beta testing
• Pilot testing
• Installation testing
• Integration testing
• Regression testing
• Acceptance testing
• Function testing
• Parallel testing
• Sociability testing
White Box Testing
• AKA: Structural Testing
• AKA: Code-Based Testing
• Identifies test cases from examining the source code
• Structural testing can identify “Dead Code”
• Code that is never executed during program execution
• Testing can be extended by using metrics to show the
percentage of software structure that has been evaluated.
• Metrics are usually referred to as “coverage”. This usually
means 100% coverage of the software. Each program piece
has been executed at least once.
Black Box Testing
• AKA: Definition-Based Testing
• AKA: Specification-Based Testing
• AKA: Functional Testing
• Identifies test cases based on what the software/program is
intended to do
• Functional testing methods:
• Normal Case (test with expected inputs)
• Output Forcing (Chosen test inputs produce selected outputs)
• Robustness (correct behavior when given invalid inputs)
• Combination of Inputs (combination of above)
8.3 Assess the effectiveness of software security
• Auditing and logging of changes
• Risk analysis and mitigation

At Issue
• Increases in business and mission risk is attributable to
software
• Exploitable software is vulnerable to attack
• Software vulnerabilities jeopardize:
• Intellectual property
• Consumer trust
• Business operations and services
• Critical infrastructure
• Process control systems
• Commercial software products

Risk Analysis
• In software testing, risk analysis is the process of identifying
risks in applications and prioritizing them to test.
• A risk is a potential for loss or damage to an organization
from materialized threats.
• Risk Analysis attempts to identify all the risks and then
quantify the severity of the risks

Risk Mitigation
• One choice is to accept and acknowledge that a risk is
impacting the project.
• Another choice is to avoid and adjust project scope,
schedule, or constraints to minimize the effects of the risk.
• Another choice is to control by taking action to minimize
the impact or reduce the intensification of the risk

Risk Analysis and Mitigation
• Once a risk has been documented:
• Identify the mitigation steps that can be taken to lessen the
probability of the event occurring
• Create a contingency plan that goes into effect either prior to or
when the event occurs
• Evaluate the probability of each risk against the mitigation
strategy cost before deciding to implement a contingency plan
• Contingency plans implemented prior to an event are pre-emptive
actions intended to reduce or remove the risk.
• Contingency plans implemented after an event only lessen the impact

Risk Analysis and Mitigation Strategy
• Integrate into the overall SDLC and change management
process
• Use standardized methods of reporting risk

• Qualitative versus quantitative versus hybrid
• Track and manage discovered weaknesses
• Document risk decisions to aid due diligence

Corrective Actions
• Software products have numerous security weaknesses that
are only identified after they are fielded
• Patch management
• Have a backup, back out plan, target non critical systems first
• Change management
• Vulnerability testing

Testing and Verification
• Independent Verification and Validation (IV&V) teams work to
determine if security issues are truly resolved
• Code signing certificates help protect users from downloading

compromised code.
• Code Signing:
• Security technique to ensure code integrity
• Identify who developed the code
• Determine if code is trustworthy
Code Signature
• Three parts:
• A seal which is a collection of various hashes from various parts of the
code
• A digital signature which signs the seal and guarantees its integrity
• A unique identifier which is used to identify the code to the group or
category it belongs.
• Signing does not:

• Guarantee code to be free of compromise
• Guarantee that the app will not load altered or unstable code
• Provide protection under Digital Rights Management

8.4 Assess security impact of acquired software
• Commercial-off-the-shelf (COTS)
• Open source
• Third-party
• Managed services (e.g., Software as a Service (SaaS),
Infrastructure as a Service (IaaS), Platform as a Service (PaaS))

Software Assurance (SwA)
• Level of confidence that software is free from
vulnerabilities, either intentionally designed into the
software or accidentally inserted at any time during its
lifecycle, and that it functions in the intended manner
• SwA needs to be verified in the major phases of the generic

acquisition process
• Planning phase
• Monitoring and acceptance phase
• Follow-on

• Planning Phase
• Determine needs
• Develop requirements
• Create an acquisition strategy that includes risk identification
• Develop evaluation criteria
• Monitoring and Acceptance Phase

• Establish a contract work schedule
• Implement change control procedures
• Implement a plan for review and acceptance of deliverables

• Follow-On
• Sustainment (includes risk management, assurance case
management, and change management)
• Disposal or decommissioning
• Risk management

Commercial off the Shelf (COTS)
• An application’s attack surface is not limited to its own code
and the code of explicitly included libraries, because those
libraries have their own dependencies.
• Modern software development relies on open source
libraries, even for those applications that are sold
commercially.
• Developers may not always be aware how these components are
introducing vulnerabilities into their code.

Open Source
• Seven in 10 applications use at least one open source library
with a security flaw, which makes those applications
vulnerable
• 47 percent of the open source libraries with at least one
vulnerability were “transitive” dependencies.
• Transitive dependencies refers to situations where a library relies
on code from other libraries

Transitive Dependencies
• If a library includes another library, and that one also pulls in code from
yet another library, the code the developer is writing winds up having
three dependencies, not just one. As applications get more complex,
the number of dependencies the developer has to manage grows pretty
quickly.
• If an application picks up its dependencies via second, third, or even
greater degrees of separation from a developer's original code, this
increases the difficulty of managing those dependencies.
• It is hard for developers to stay on top of making sure they are using the
most up-to-date versions of open source libraries. They can keep track
of the ones they are using directly, but they often have to trust that the
upstream library maintainers are managing the other dependencies.

Third Party
• Up to 90 percent of an application typically consists of third-
party components, mostly open source.
• Imported code represents functionality that your developers
did not author, but becomes code you have to manage.

8.5 Define and apply secure coding guidelines and standards
• Security weaknesses and vulnerabilities at the source-code level
• Security of application programming interfaces (APIs)
• Secure coding practices
• Software Defined Security

Threats in the Software Environment –
Buffer Overflow
• One of the oldest and most common of software
problems
• Caused when a program fills up its buffer of memory

with more data than it can hold
• Can lead to the insertion of malicious code used to

gain administrative access
• Caused by insufficient bounds checking (data length,

type, format)
Buffer Overflow
• Caused by ineffective parameter checking
• Implemented by the programmer
• Perform bounds enforcement and error

checking
• Check data length/type
• Hardware states and hardware controls

make buffer overflows impossible
• Patch or upgrade
Citizen Programmers
• Anyone can learn a programming language and become a
programmer
• Not trained in or bound by system development practices

• No proper application design
• No change control
• No support for the application
• Software creations are often developed chaotically and lack

security
Covert Channels
• Communication channel allowing two cooperating
processes to transfer information in such a way that it
violates the security policy
• Two commonly defined types

• Storage: One process writes data to a storage location and another
process directly or indirectly reads it
• Timing: One process relays information to another by modulating
its use of system resources

Memory Reuse / Object Reuse
• Memory Management involves
• Allocating memory space to one process
• Re-allocating it upon process completion
• Then re-allocating it to a new process
• Problem
• Residual information

Social Engineering
• Sometimes referred to as “people
hacking”
• Has the ability to circumvent access

controls
• Malicious software will often contain

a fraudulent component in an
attempt to get a user to run the
program
Time of Check/Time of Use (TOC/TOU)
• A form of asynchronous attack (time)
• Occurs when a program checks access permission too far in

advance of a resource request
• The attack gets in between steps and makes modifications
• How to Mitigate:
• Have software lock the items it will use while carrying out its
checking tasks
Web Threats
• Web sites are the primary interface for e-Commerce
• Potential problems
• Fraud
• Theft
• Web sites can add a vector for intrusion into the private network
• Most attacks happen at the application level
• Web sites vulnerable due to accessibility

Top 10 Web Threats
• Drive By Downloads • Watering Hole attacks
• Click Jacking • Third Party Web APPs
• Plug-in and script enabled • Mobile Application Threats
attacks
• Advanced Phishing attacks
• Social Engineering Networks
• Malvertising
• P2P Dangers

Web Input Validation
• When Accepting Input, Control:
• Length
• Type
• Range of memory
• This Can Prevent:

• Buffer Overflows
• SQL Injection
• CGI Attacks

Structure Query Language (SQL)
Injection
• SQL Injection
• Type of injection attack in which SQL commands are injected into data-
plane input in order to effect predefined SQL commands. (OWASP)
• Allows an attacker to query data from the database via the user
interface
• DoS is the most common SQL attack
• (example) User ID = ‘ ‘ or 1=1;
• Attempts to login as the database admin
• Safeguards:
• Input validation Harden database
• Parameterized queries Stored procedures

Web Protection
• If your program sets cookies on the client:
• Encrypt them
• Do not use sequential, calculable, or predictable cookies, session
numbers, or URL data
• Validate all input and output
• Fail secure
• Do not cache secure pages
• Do not automatically trust data, regardless of source
• Audit

Executable Content / Mobile Code
• Software that is transmitted across the network to a local
systems and executed on that system
• Java Applets
• Active X Components
• Scripts / Plug-ins

JAVA Security
• Java Security Provisions: interpreter, class loader, security
manager
• Java Applet
• Client-side program that is platform independent
• Runs inside another application (as in a web browser)
• Sandbox
• A Virtual Machine (JVM) converts byte to machine code
• Restricts the applets access to system resources
• Digital Signatures
• Applets containing a digital signature can run outside of the virtual
machine and be given access to system resources based on the trust
conveyed by the certificate accompanying the digital signature

JAVA Security
• Java Steps
• Programmer creates the code and compiles it with a Java compiler
• Java compiler turns the source code into byte code
• User downloads the Java Applet
• The Java Virtual Machine converts the byte code into machine level code
• Applet runs whenever called on
• Scripts and Plug-ins

• Scripts run within the browser
• Browser plug-ins increase the attack surface of the web browser
(QuickTime/Adobe/Flash)

ActiveX
• Controls used to interact with web pages
• Developed by Microsoft for Windows OS
• Downloaded to the user’s hard drive

• Greater access to system resources than Java
• PKI aware authenticode (code is digitally signed)

• Relies on signature, certificates, and the user’s awareness

Items Revisited from a Previous Domain
• Application Programming Interface (API)
• Representational State Transfer (REST) API
• Java Script Object Notation (JSON)
• Extensible Markup Language (XML)
• Simple Object Access Protocol (SOAP)
• Security Assertion Markup Language (SAML)
• Service Oriented Architecture (SOA)
• Web Services Security (WSS)
• Services Provisioning Markup Language (SPML)
• Extensible Access Control Markup Language (XACML)(PEP/PDP)
• API Authentication

Current Software Environment
• Issues with Current Information Systems
• Becoming more distributed
• Increase in the use of open protocols, interfaces, and source
code
• Increased sharing of resources
• Speed to Market
• Malicious Code
• Customer demand

Application Security Preview
• Software includes both operating systems and application
software
• Application refers to agents, applets, databases, data
warehouses, and knowledge-based systems
• Security must be considered in all aspects of the application
lifecycle, such as:
• Planning, Development, Implementation, Operation, and
Maintenance

Programming
• Addressing Security at the Source
• Past practices did not require security implementation
• Security professionals are not software developers
• Software developers are not security professionals
• Functionality versus Security
• Complexity of design

Top Down verses Bottom Up
Programming
• Top Down Programming
• Starts with the highest level requirement and works down
• Risks making incorrect assumptions about the lower level devices
• Example: C programming
• Bottom Up Programming
• Starts with low level technical details and works up
• Risks wasting time developing features that will not be in the final
product
• Example: object oriented programming

Standards and Practices for securing the
SDLC
• ISO/IEC 27034:2011 “information technology-security
techniques-application security”
• ISO/IEC JTC 1/SC7 “software and systems engineering standards”
• ISO 12207:2017 “system and software engineering-software
lifecycle processes”
• ISO/IEC/IEEE 15288:2015 “systems and software engineering-
system life cycle processes”
• ISO/IEC TR 15504 “Information technology-process assessment”
• NIST SP800-64 Revision 2 “security considerations in the system
development life cycle”

Control and Separation of Environments
• Three environments exist:
• Development
• Quality Assurance/Staging
• Application (Production/users)
• To separate environments:
• Physical Separation
• Access Control Lists
• Content Dependent Access Controls
• Role Based Restraints
• Accountability
• Separation of Duties

Baselining
• A captured point in time where current system security configuration is
understood
• Creates a common security configuration
• Helpful when responding to security incidents
• Makes recovery of systems easier
• Effective method of providing a required level of protection across a

broad area
Certification / Accreditation
• Four Step Process
• Initiation Phase
• Security Certification Phase
• Security Accreditation Phase
• Continuous Monitoring Phase

Software Defined Security
• Security model where information security is implemented,
controlled and managed by security software.
• Software-managed, policy-driven and governed security
where most of the security controls such as intrusion
detection, network segmentation and access controls are
automated and monitored through software.

Questions?

7.2-0-D8-October2021 (Software Development Security)

Uploaded by

Copyright:

Available Formats

You might also like

7.2-0-D8-October2021 (Software Development Security)

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

7.2-0-D8-October2021 (Software Development Security)

Uploaded by

Copyright:

Available Formats

Software Development

Domain 8: SW Development Security 2

Domain 8: SW Development Security 3

Domain 8: SW Development Security 4

Domain 8: SW Development Security 6

Domain 8: SW Development Security 7

Domain 8: SW Development Security 8

Domain 8: SW Development Security 9

Domain 8: SW Development Security 10

Domain 8: SW Development Security 12

Domain 8: SW Development Security 14

Domain 8: SW Development Security 15

Domain 8: SW Development Security 16

Domain 8: SW Development Security 17

• Joint Application Development (JAD)

Domain 8: SW Development Security 18

• Built on assumptions as to how the system might work

• Consists of planning and trying different designs before development

• Results in less-than-optimal systems

Domain 8: SW Development Security 19

Domain 8: SW Development Security 20

• Best suited for projects using

• Libraries of software modules

Domain 8: SW Development Security 21

• Individuals and interactions over processes and tools

Domain 8: SW Development Security 23

Domain 8: SW Development Security 24

Domain 8: SW Development Security 25

Domain 8: SW Development Security 28

Domain 8: SW Development Security 29

SAMM: framework to help organizations formulate and

Domain 8: SW Development Security 31

Domain 8: SW Development Security 32

Domain 8: SW Development Security 33

Domain 8: SW Development Security 34

• Source code vs. Machine code

Domain 8: SW Development Security 35

Domain 8: SW Development Security 37

• Inheritance (code reuse)

Domain 8: SW Development Security 39

• Examples are compilers, assemblers, linkers, translators,

• When the CASE tools are integrated: ICASE

Domain 8: SW Development Security 40

Domain 8: SW Development Security 41

Domain 8: SW Development Security 42

Domain 8: SW Development Security 43

Domain 8: SW Development Security 44

Domain 8: SW Development Security 45

Domain 8: SW Development Security 46

Domain 8: SW Development Security 47

• Negotiated as contractual requirement with a software

Domain 8: SW Development Security 48

Domain 8: SW Development Security 49

• Test from low to high

Domain 8: SW Development Security 50

Domain 8: SW Development Security 54

Domain 8: SW Development Security 55

Domain 8: SW Development Security 56