8: Software Development Security

• self-contained on a device
• example: calc.app

• most business applications user this

• example: databases

• alteration attacks seek to undermine integrity

• web applications

  • client/server applications over the web

• commonly run both endpoint applications and client/server applications

• every project should begin w/business requirements
• quality software requires quality design

• unidirectional, step-by-step

• doesn’t accommodate changes well

• can be easier to secure

• pros of waterfall

  • specific deliverable and review process for each phase
  • phases completed one at at time
  • good for small projects with defined / understood requirements
  • reinforces:
    • “define before design”
    • “design before code”

• cons of waterfall

  • scope changes midway can kill a project
  • working software isn’t ready until very late into the process
  • high risk and uncertainty
  • not good for long ongoing projects
  • not good if changes are likely
  • project end can be far removed from initial requirements definition stage

• circular development process

• prototypes are built, customer gives feedback, prototypes are refined

• pros of prototyping

  • developers can get customer feedback early in design process
  • developers and customer can compare requirements and software being built
  • developers can tell early on if estimates for deadlines and milestones will be met

• cons of prototyping

  • customers don’t understand impact of changes requested
  • developers might take shortcuts during the prototyping process that are undocumented

• combination of prototyping and waterfall

• pros of spiral

  • lots of risk analysis
  • good for large projects
  • good for mission critical projects
  • software is produced early in the process (inner spirals)

• cons of spiral

  • can be costly
  • risk analysis requires expertise
    • success is dependent on that risk analysis
  • not good for small projects

• addresses that customers can request changes quickly

• pros of agile

  • fewer defects
  • greater flexibility
  • immediate feedback

• cons of agile

  • less documentation
  • less focus on system design
  • not good for security

• multi-functional teams
• develop a product, process or policy through parallel decision making

• provide standard benchmarks

• assesses an org’s process maturity

• earlier version of CMMI were focused on software development

• levels

  1. initial

     • work gets done, but is delayed or over-cost

  2. managed

     • configuration management
     • measurement and analysis
     • project monitoring and control
     • project planning
     • process and product QA
     • requirements management
     • supplier agreement management

  3. defined

     • defined analysis and resolution
     • integrated process management
     • org process definition
     • org training
     • org process focus
     • product integration
     • requirements development
     • risk management
     • technical solution
     • validation
     • verification

  4. quantitatively managed

     • org process performance
     • quantitative project management

  5. optimizing

• initiating
• diagnosing
• establishing
• action
• learning

• developed by OWASP

• standardizes code release procedures
• software development never finishes
  • need to maintain software
  • addition of new features

• manages, evaluates and prioritizes requests from customers

• grants permission for developers to make changes
• if approved, developers change code

• tests code
• performs QA checks
• release manager moves code from development environment to production

• dev

• test

• staging

• prod

• all of the above processes are known as software configuration mangement (SCM)

• all changes and configuration management should be logged

• partners developers and operations

• builds collaborative relationships

• embraces automation

• facilitates rapid code release

• provides a stable operating environment for developers

• devops and agile are related

  • both seek continuous integration

• scripts the creation of resources

• example: spinning up new servers w/ scripts that auotmatically configure them to org specifications

• advantages

  • increases environment scalability
  • reduces user error
  • facilitates testing of new code
  • facilitates security automation
    • DevSecOps applies DevOps principles to security

• continuous validation
• continuous integration
• continuous delivery
• continuous deployment
• continuous monitoring

• starts w/ a finished product

• decomposes it to determine how it was made

• interpretted languages

  • look at source code

• compiled languages

  • use a sandbox

    • observe code
    • attempt to determine how it runs

  • use a decompiler

    • attempts to convert machine language back into source code
    • produces difficult to understand results

• purchased from a third party vendor
• runs on customer systems

• developed by a vendor

• runs in a cloud environment for customers

• security professionals must understand and assess all software used by the org

  • regular vulnerability scans should be run on acquired software

  • vendor security updates should be applied

    • security patches
    • hotfixes
    • critical updates
    • major/minor releases

  • open source software also requires careful management

    • might not have as much support as commercial software
    • might become abandoned

  • software security needs to be configured

    • user accounts
    • admin privileges
    • IP range restrictions

• use peer analysis to assess code

• planning

  • leader prepares for code review
    • prepares materials
    • identifies participants
    • schedules review

• overview

  • leader assigns roles to participants
  • provides overview of software

• preparation

  • participants review code individually
    • make note of issues

• meeting

  • formal meeting w/ participants
  • developers discuss defects

• rework

  • developers correct defects

• followup

  • leadership confirms that defects are fixed

• most orgs use a much less formal process

• ensures that the finished software functions properly

• verification

  • checks that the software meets the business requirements

• validation

  • checks that the software works properly

• uses automated scripts to verify system capacity
• may be run internally or by an outside vendor
• verifies that the system can handle the maximum expected load
• often determines the maximum capacity by testing to failure

• checks that software will work for users
• users test the software
• focus on usability
• also known as beta testing

• checks for unexpected side effects from updating software
• checks that software behaves in the same manner compared to the previous version
  • except any new added functionality

• checks code for security flaws
• uses technology to test software

• uses automated technology to analyze code for errors
• doesn’t run code
• like an automated version of a code review

• automated testing that actually executes code

• provides inputs and tests outputs

• verifies that the code is functioning correctly

• synthetic transaction

  • developers supply inputs to code w/ known expected outputs

tip:
code reviews, static testing and dynamic testing are complementary.
they are not competing, and can be used together.

• software testing technique that feed many different input values into a program
• attempts to cause unpredictable states ot unauthorized access

• developer-supplied input
• developer-supplied script that generates input
• generation fuzzing
  • fuzz testing app generates random input
• mutation fuzzing
  • fuzz testing app analyzes real input and generates input from that

tip:
remember to avoid looking like a hacker…
fuzz testing should only be done w/ permission.

• provide secure store and version control

• allows for coordinated code changes among multiple developers

• version control helps meet audit requirements

• promotes code reuse and helps avoid dead code

• public repos

  • potential disclosure issue
  • be sure to remove API keys, passwords, etc.

• secure de-/provisioning

  • ensures the integrity of released code

  • integrity measurement

    • verifies that released code isn’t changes
    • hashes code before moving to production
    • ensures that malicious code isn’t released

• restricts software that can run on a system

• Applocker: example of Windows application control technology

• application control logs should be sent to SIEM or central log storage repo

• whitelisting

  • admins create a list of all applications that may run on a system

• blacklisting

  • admins create a list of applications that are prohibited from running on a system

• integrate application control logs into SIEM

• host software baselining

  • identifies expected system software
  • helps with updates
  • reports deviations from baselines

• developers often rely on third-part code
  • raises security concerns if not vetted

• shared software code objects with relavent functions

• created by vendors
• provide programming resources
• include documentation and testing utilities

• allow for interaction w/ remote services

• outsourcing code development introduces security concerns

• many practices combine to produce secure software

• security should be integrated w/ the SDLC

  • shouldn’t be bolted on after the fact

• need to understand software security threats

• input validation

• encrypt sensitive data

• enforce least privilege

• test all code before deploying to production

• sandboxing

  • isolates development
  • allows developers to test code prior to committing changes

Open Web Application Security Project maintains a list of common web security issues

• use proper authentication
• encrypt sensitive data
• validate input
• avoid and remediate known exploits
• deploy obfuscation and camoflague
• prompt patching
  • attackers quickl exploit new vulnerabilities

• type and scope of encryption
• user access to application
• access granted to authorized users
• security of underlying infrastructure
  • servers, firewalls, etc.
• configuration baselines
  • allow for quick identification and remediation of security gaps

• dynamic web applications rely on back-end databases to store user info, product info, etc.
• attackers can exploit input fields to inject SQL commands into a database as part of a normal action
• Bobby Tables!

• input validation

  • checks user input on server prior to executing SQL commands
  • checks must be server-side; attackers can easily bypass client-side checks

• parameterized SQL

  • pre-compiles SQL code on the database server
  • prevents user input from altering query structure

aka XSS

• attacker embeds malicious code into third party websites that is later run by innocent users

• XSS attackers commonly embed scripts into sites via user input

  • via <script> tags

• prevention

  • use input validation
    • don’t allow users to submit fields with <script> tags

aka XSRF, CSRF, “sea surf”

• similar to XSS, but more dangerous

• use one site to trick browsers into sending malicious requests to another site

• leverage the fact that users are logged into multiple websites

  • persistant cookies keep users logged in for periods of time

• XSRF secretly send requests to other websites

  • usually through images

• prevention

  • orgs:
    • rearchitect websites
    • prevent HTTP GET requests
    • leverage Access-Control-Allow-Origin
    • educate users
    • auto-log users out of site after period of time
  • users
    • log out of sites

• server-side request forgery

  • manipulate servers into retrieving malicious data from what it thinks is a reputable source

attack allows an attacker to manipulate a web server’s file directory

• Unix file system directory references

  • ./ current directory
  • ../ one directory up
  • ../../ two directories up
  • etc

• attacker users file system references to look for files on the server

• prevention

  • input validation
  • strict file system access controls — user running web server should only have access to web server files

• developers often set aside memory buffers for user input when developing applications

• attackers input a string much larger than the buffer

• the server can then inadvertantly return information outside of the buffer

• prevention

  • input validation

• track user activities on the web

• stored by websites in the user’s browser

• used to recognize and remember the user

• are also used in some applications

  • known as locally stored objects (LSOs)

• track users on the web
• often used by ad networks
• logging into one site has the potential de-anonymize the user

• cookies are used for web authentication

• cookie guessing

  • guessable cookie jeopardize security
  • cookie values (such as session ID) should be random, not based on a guessable pattern

• session replay

  • cookies are susceptible to replay attacks
  • cookies should be sent over an encrypted connection to prevent eavesdropping

• occur when an attacker exploits vulnerabilities on a system that allow them to run commands on the systems

• arbitrary code execuction

  • code execution attack where the attacker runs commands of his choice

• remote code execution

  • code execution attack that takes place over a network

• objectives

  • install malware
  • join the host to a botnet
  • steal sensitive information
  • install a backdoor for later use

• gain admin access

• often exploit buffer overflow attacks

• prevention

  • input validation
  • enforce least privilege
  • keep OS, platform, apps patched
  • use data execution prevention (DEP) and address space layout randomization (ASLR) technology

• device drivers act as a software interface between an OS and hardware
• requires low-level access to the OS

• modifying a driver to carry malicious code
• requires access to the device driver’s source code
• less common
  • attackers rarely have access to source code

• wraps a legitimate driver w/ a malicious shim containing malicious code
• doesn’t require acces to the driver’s source code

• protects against malicious drivers
• ensures that drivers are authentic and safe

• memory management provides isolated memory for each system process and application

• allows for arbitrary code execution

• has the potential to slow down or disable a system

• applications fail to release memory for resuse

• variable that stores the address to a location in memory

• pointer deferencing

  • process of following a point

  • NULL pointer dereferencing

    • situation where a pointer isn’t set, therefore it points nowhere
    • best case scenario: application crashes and attacker can access a debug log
    • worst case scenario: allows an attacker to bypass security controls

• tricks an application into loading malicious code
• often attempted through the use of memory vulnerabilities

• when the proper function of a security control depends on the timing of actions performed by the user or system
• uncontrolled race conditions can be a security vulnerability

• there is a time elapsed between authorization and the action taken
• can be prevented by locks that prevent simultaneous transactions from creating race conditions

• should filter user-supplied input

  • should always be performed on the server

• approaches

  • whitelisting

    • specifies allowed input
    • not always practical
      • can you come up w/ a list of every possible good input?

  • blacklisting

    • specifies disallowed input
    • more difficult
    • less effective

• SQL template pre-compiled on the database server
• used by stored procedures
• example

• never store passwords in plaintext
  • use hashing and salting
• encrypt passwords in transit
• use SSL/TLS
  • encrypts web traffic

• encoding

  • replaces dangerous characters used in SQL injection attacks and XSS

  • HTML encoding

    • uses &xxx;
    • example: ' = '

  • URL encoding

    • uses %####
    • example: ' = %27

• appropriate error handling is critical to software security

• unpredictable states jeopardize application security

• error handling
  exception handling

  • avoids unpredictable states

• try-catch model

• ensures users that code comes from a legitimate source

• applies digital signatures to software

• signing code

  1. developer obtains a digital cert
  2. developer creates a digital signature w/ private key associated w/ digital cert’s public key

• verifying code signatures

  1. user downloads software
  2. user’s OS validates digital signature of the software
  3. user’s OS validates the signature’s hash of the software
  4. software is trusted

• this process is similar to digital signatures used in email

• database normal forms

  • design rules for columns and tables in a data base

  • why normalize?

    • prevent data inconsistancies
    • prevent update anomolies
    • reduce need for restructuring
    • make database schema more informative

• obsfuscation and camoflauge can hide the locations of sensive data

• database activity monitoring
  DAM

  • logs and analyzes database requirements

• stored procedures

  • protect against SQL injection attacks

• removes obvious identifiers

• anonymization

  • removes the possibility of identification

• HIPAA deidentification standards

  • expert determination

    • apply scientific / statistical principles

  • safe harbor

    • remove 18 types of identifiers

• transforms PII into a form where it isn’t possible to tie that info to an individual

• hashing

  • replaces sensitive fields w/ hash values
  • salting decreases likelihood that data will be recovered by a rainbow table attack

• tokenization

  • replaces sensitive fields w/ a random identifier
  • uses a lookup table to find sensitive info
    • lookup table must be. secured

• masking

  • redacts sensitive info in a file
  • masking ████ like this ████

people and orgs play different roles in cloud computing

• offers cloud computing services to third parties
• run infrastructure
• might outsource to other cloud providers

• consumer of cloud services
• purchases cloud computing services from one or more cloud service provider
• nature of relationship with provider can vary
  • self-service
  • one-on-one support w/ account managers

• provides add-on services
  • might assist org in implementing cloud for org
  • might offer security monitoring

• provide managed IAM services

• can add a third party security layer between an org and their cloud service provider

  • network-based CASBs

    • intercepts network traffic between the org and cloud
    • monitors traffic for security issues
    • can block access if issue discovered

  • API-based CSABs

    • queries cloud service by API and monitors
    • may be limited by API access and what information is available from API

• on-demand self-service

  • resources are available when the org needs them
  • can spin up servers on demand using pre-configured images

• scalability

  • can increase capacity on demand

  • horizontal scaling

    • adding additional servers to a pool to meet increased demand

  • vertical scaling

    • adding more resources (CPU, memory, storage) to a server on demand

• elasticity

  • the ability to expand and contract quickly

• broad network access

  • provide anywhere anytime access

• measured service

  • pay only for what you consume

• offer managed IT services to customers

• offer managed IT security services to customers

• if used, must be carefully monitored and documented

• examples of services offered

  • management of entire security infrastructure
  • monitoring of system logs
  • management of firewalls and network security
  • performance of IAM

• exam tip: MSSPs may also be referred to as security as a service (SECaaS)

• add a third party security layer between an org. and their cloud service provider

• ISO 17789: Cloud Computing Reference Architecture

  • the reference architecture is a helpful framework, but is just a starting point

  • defines cloud computing activities

  • customer activities

    • user cloud services
    • perform service trials
    • monitor services
    • administer security
    • provide billing reports
    • handle problems
    • administer tenancies
    • perform business admin
    • select services
    • request audit reports

  • cloud service provider activities

    • prepare systems and services
    • monitor services
    • manage assets
    • provide audit data
    • manage customer relationships
    • perform peering
    • ensure compliance
    • provide connectivity

  • partner activities

    • design, create, maintain services
    • test services
    • perform audits
    • set up legal agreements
    • acquire and assess customers
    • assess the market

• no cloud model is superior, it all depends on context and the org’s needs

• _X_aaS
  • x as a service

• depends on the level of the service

  	IaaS	PaaS	SaaS
  data	customer	customer	customer
  app	customer	customer	vendor
  OS	customer	vendor	vendor
  hardware	vendor	vendor	vendor
  data center	vendor	vendor	vendor

  exam tip
  understanding the shared responsibility model is important for infosec professionals.

• reduce attack surface of product
  • user input
  • protocols / services / interfaces / processes — minimize
  • resource files
  • open named pipes / open sockets
  • how many items are accessible
  • dynamic web pages (ASP, etc.)
  • ACL configuration

• identify security objectives
  • legislative drivers
  • contractual requirements
  • alignment with business objectives
• CIA triad
• tools for threat modeling
  • data flow diagrams
  • use/misuse cases

• CIA
• AAA
• secure design principles

• code reuse
• flaws vs. bugs
  • flaw: inherent fault with the design of code
  • bug: implementation fault
• open vs. closed design

• good enough security
• least privilege
• depth of defense
• separation of duties
• fail safe
• complete mediation
• open design
• economy of mechanism
• least common mechanism
• psychological acceptability
• leverage of existing components
• weakest link
• single points of failure

• quality: does it do what it’s supposed to do?
• security: focus on reducing the probability and/or impact of vulnerabilities/threats
• best implemented together throughout the SDLC

• training / awareness for developers
  • security is often not emphasized in universities / academia
  • often push to get it done and make fixes after deployment via patches
• a shift of focus and understanding from managers
  • need to budget time and money in development to include security
• bug tracking classification — DREAD
  • D: damage potential
  • R: reproducability
  • E: exploitability
  • A: affected user base
  • D: discoverability