Reading notes from "Software and Systems Security for CompTIA CySA+" on Pluralsight

notes.md

Software and Systems Security for CompTIA CySA+

Examining the Software Development Lifecycle (SDLC)

• ignored instructor's advice to set up penetration testing VMs

Phases

Planning

• the most important phase
• done by the most senior team members, with input from customers

Requirements

• software, hardware, external sources
• where is the data being stored?
• how is the traffic transmitted?
• how is access granted?
• who's given admin rights?

Design

Risk Analysis

• threats and vulnerabilities which may arise from interaction with other systems
• external/legacy code -- any vulnerabilities?
• high-risk privacy projects could require legal review

Functional Specifications

• description of interface requirements (input types/validation)
• time zones, dates in the past allowed?
• workflow
• audit trail for every update on the database

Implementation

• boxes, diagrams
• "known resource environment"
• connections

Testing

• test the boxes from "Implementation" from an "unknown resource environment"
  • aka "hacker view"
• make a testing plan
  • unit tests
  • system/end-to-end tests

Deployment

• how is it being secured?
• what is the security mechanism in the CI/CD system, and the server(s)
• if it's deployed via portable hardware, what happens if it's lost?
• package installer - does it install what you think it does?

Maintenance

• ongoing security monitoring
• emergency response procedures
• updates that could affect the application
  • OS, backend, third-party

End of Life

• steps to remove software
• effects on other back end resources
• make sure you disable service accounts
• thorough documentation will power thorough decomissioning

Software Development Models

Code and Fix

• no plan
• fix problems as they occur, or until the project is finished
• if the architecture is wrong, big rewrites may be required
• may never get released
• DANGEROUS

Waterfall

• one task after the next, predefined
• when to use?
  • requirements are well-documented
  • technology is understood, not dynamic
  • ample resources, including expertise
• it's a bit rigid, can't really pivot
  • better for simple projects
• security-wise, it allows for security checks at every stage

Agile

• satisfy the customer through early and continuous deployment
  • check security at each deployment
  • progress is visible
• welcome changing requirements
• business + devs working together
• sustainable development, consistent pace
• self-organizing teams
• iterative improvement of team effectiveness
• each iteration goes through each of the five phases (above)
• disadvantages
  • not great for complex dependencies
  • depends on customers
  • not great for documentation (?)

Iterative

• no full specification of requirements
• starts by specifying only a part of it, then another part on completion
• when to use?
  • when requirements are clear, but may evolve
  • time to market constraint
  • using new tech, learning on the fly
  • resources for later phases aren't available yet
• bugs and security flaws can be caught in each iteration
• disadvantages
  • more resources may be required, like consultants etc.
  • not for small projects
  • not suitable for changing features

Spiral

• Waterfall "control" aspects + Iterative
• revisits four phases multiple times
  • each iteration is a "spiral"
• when to use
  • budget constrained, but risk evaluation is important
  • medium/high-risk
  • long-term commitment
  • unsure of requirements
• disadvantages
  • management is more complex
  • don't know when it'll be done
  • process is complex

(Security) Code Reviews

• why?
  • detect vulnerabilities early on

Outlines

• define the scope of the code review
  • budget constraints
  • types of code review
  • categorize vulnerabilities

Common Sense Tips

• talk with the team
• have enough time
• limit to 400 lines, 60 minutes
• verify the fixes took

Types

• static (without execution)
• dynamic (monitor system memory, response behaviors, performance while running)
• peer review
• UAT (user acceptance testing)
• fuzzy testing
  • application UI fuzzers
    • import/export functions, input fields
  • protocol fuzzers
    • transmit manipulated packets into the application using unexpected values in header/payload
  • file format fuzzers
    • open files whose format has been manipulated
  • dumb fuzzers generate random inputs
  • other fuzzers test known vulnerabilities
• fault injection
  • compile time -- introduce fault by modifying source code
  • protocol software -- send unexpected/noncompliant data
  • runtime -- inserting into memory or injecting faults to cause the application to fall down
• mutation testing
  • small modifications to the program itself
• stress/load testing
• security regression
• formal method
  • capture every possible path, find corner cases
  • requires the system spec to be stated formally

Intercept Proxies

• get between the client and server
  • manipulate data
  • affect timing

BurpSuite

• he's running the OWASP BWA (bad web app), intercepting it using a BurpSuite proxy
• devtools-like
• allows submission of forms

OWASP ZAP

• included in Kali Linux
• similar to BurpSuite, it intercepts
• crawls the page, raises alerts
• sql injection example

Reverse Engineering

• extracting code from a binary
  • how?
    • decomposing
      • disassembler -- machine code from memory -> text string
      • decompiler -- deconstruct high-level code
      • debugger
    • obfuscating code
      • ? isn't this a way to protect against reverse engineering??
    • reverse engineering labs
      • put buggy code/malware in a sandbox for analysis
      • important to keep it away from the hypervisor and network
      • WANNACRY was defeated this way
        • it had a kill switch, which reached out to a nonexistent URL
        • researcher registered that domain/URL, which prevented the drive from being encrypted

Applying Best Practices of Secure Coding

• goals
  • confidentiality
  • integrity
  • availability
• attacker's goals
  • what the application can be made to do
• client side UI offers no protection, because you can build your own requests
• Java and Flash applets can be decompiled

Input Validation

• identify all data sources
  • trusted/untrusted
  • validate all data from untrusted sources
  • centralized input validation routine
  • use proper character sets e.g. UTF-8 for all input sources
    • encode data using character set before validating
    • determine if the systems support UTF-8
  • all failures should result in input rejection
  • e.g. headers, urls, cookie name/values
  • include automated postbacks from JS, Flash, other embedded stuff (?)
  • headers must include only ASCII chars
• validate data from redirects
  • an attacker to submit malicious content directly to the target, which could get around the application logic
• validate expected data types, ranges, lengths
• validate input against an approved list of allowed chars, if possible
• implement additional controls, if you're going to need to allow special chars
  • secure task-specific APIs
  • output encoding
    • use a trusted system (your server)
    • standard tested routine for each type of outbound encoding
    • contextually output encoding
      • e.g. HTML entity encoding
    • encode all chars, unless we know they're safe for the intended interprter
    • contextually sanitize output, like XML, SQL, LDAP
    • sanitize all output of untrusted data to the operating system commands
  • account for utilization of that data throughout the application

Authentication and Password Management

• authentication on all pages and resources, except public pages
• auth should be forced on a trusted system
• use standard, tested auth services
• use a centralized authentication implementation
• segregate auth logic from the resource being requested
  • use redirection from and to centralized auth
• auth should fail securely
• admin and account management should be at least as secure as the user auth
• only store cryptographically strong, one-way, salted hashes of the passwords
  • ensure the table/file is writable only by the application
• password hashing must be done on a trusted system (server)
• validate auth data only on completion of all data's input
• don't show which part of auth failed
• error responses should be identical in both display and source code
• use auth for connections to external systems, especially if there's sensitive info being transmitted
  • auth credentials should be encrypted and stored in a protected location on the trusted system
• only use HTTP POST
• send non-temporary passwords via encrypted connection
• enforce password complexity and length requirements (more than 15 chars)
• obscured passwords in input
• enforce account disabling after ~5 attempts
  • interval of disablement, balance it between it becoming a DDoS for your site and allowing brute force
• reset questions -- don't do pre-programmed ones or Googlable info
• only send password reset to known emails
• put a short expiration time on password resets
• notify the use when a password reset occurs
• force change of temporary password
• stop password recycling
• password must be at least one day old before resetting
• enforce password refreshes
• disable "remember me?"
• report the last use of the account to the user at their next login
• monitor to identify attacks against mupltiple accounts, like using the same password
• change vendor-supplied password/user IDs, or disable those accounts
• use multi-factor auth for high-value accounts
• re-authenticate for critical operations
• inspect third-party code carefully

Session Management

• use the server/framework's management controls
• session ID should be created on trusted system
• session algos should be well-vetted
• set domain/path for cookies containing the session identifiers to a restricted value for the site
• logout should fully terminate associated session and its connection, as well as access to protected pages
• make session as short as possible
• don't allow persistent logins, enforce periodic session terminations, especialy sensitive info-containing apps
• if session is established before login, close it and establish a new one after login
• if there's re-auth, create a new session identifier
• if there's a user ID currently logged in, don't allow concurrent logins
• hide session identifiers in URL
  • should only be located in HTTP cookie header
• protect server side session data
  • by ipmlementing appropriate access controls on the server
• create new session ID if HTTP->HTTPS switch or vice versa
  • better to only use HTTPS
• use strong random per-session tokens/params
  • OR per-request strong random tokens/params
• set the "secure" attribute on cookies
• set cookies with HttpOnly attribute

Access Control

• use only trusted system objects, e.g. a server-side session object, for auth
• use a single site-wide component to check access authorization
• access control should fail securely
• deny all access if the application can't access its security configuration
• enforce auth controls on every request, including server-side scripts OR requsets from client-side things like AJAX
• isolate privileged logic from other application code
• restrict access to authorized users
  • files or other resources,
  • protected URLs
  • protected functions
  • direct object references
  • services
  • application data
  • configuration information esp. security-related, including those outside the application's control
  • policy information used by access controls
• if there's state data on the client side, use encryption and integrity checks on the server side to catch state changes
• enforce application logic flows to comply with business rules
• limit the number of transactions a user/device can perform within a specific time period
  • balance between preventing automated attacks and useability
• maybe use a "referrer" header as a supplemental check, not by itself -- can be spoofed
• if you allow long auth sessions, re-validate periodically to make sure thier privileges haven't changed
  • if they have, log them out
• implement account auditing, disable unused/retired accounts
• use the least privilege theory when possible for eaccessing third party systems (?)
• create an access control policy

Cryptographic Practices

• all cryptographic functions to protect secrets must be used on trusted systems
• protect master secrets from unauthorized access
• crypto modules should fail securely
• make sure random numbers are generated using a vetted/approved library
  • should be compliant to FIPS 140-2
• establish policy for managing crypto keys

Error Handling and Logging

• don't disclose sensitive info in error responses
  • e.g. debugging, stack trace
  • use generic errors
• the app should handle application errors, don't rely on server configuration
• free allocated memory when an error occurs
• deny access by default when there's an error
• logging controls should be on trusted system
• log should contain success and failure
• log important event data
• restrict log access
• use a master routine for all logging operations
• don't store sensitive info in the logs
• ensure there's a mechanism to go through and look at the logs
• validate log entry's integrity using a hash function
• log
  • input validation failures
  • auth failures
  • tampering events, including unexpected changes to state
  • attempts to connect with invalid/expired tokens
  • log system exceptions
  • changes to admin settings, especially security-related
  • TLS connection failures
  • cryptographic module failures

Data Protection

• least privilege -- restrict users only to the functionality they need to do their jobs
• protect cached/temporary copies of sensitive data from unauthorized access
  • purge them when no longer required
• encrypt sensitive data, including on the server
• prevent source code download
• don't store passwords non-securely
• remove comments from production code that might reveal sensitive info
• remove unnecessary applications/system docs (?)
• don't include sensitive info if you use HTTP GET
• disable autocomplete on forms
• disable client-side caching
• support removal of sensitive data in app
• access controls for data stored on the server
  • cached data, temp files, data that should be accessible only by specific system users

Communication Security

• use TLS for sensitive info, including connections to external systems
• TLS certs should not be expired, and have the correct domain
• no TLS fallback, just fail
• DevSecOps
  • apply principle of least privilege
  • use threat modeling and other techniques at the start of the project and throughout the lifecycle
• use a single TLS implementation
  • stipulate character encoding
• filter sensitive info in parameters from the HTTP referrer

System Configuration

• use the latest versions of server, frameworks
  • patched
• disable directory listings
• restrict web server, process, and service accounts (least privileged)
• when an excepotion occurs, make sure it fails securely
• remove all unnecessary functions and files
• remove test code
• robots.txt
  • prevent disclosure of your directory structure
    • place directories in disallowed parent dir, then disallow the parent dir in robots.txt instead of one at a time
• define which HTTP methods the application supports
  • and whether it'll be handled differently on different pages
• make sure multiple HTTP versions are handled in a similar manner (?) e.g. 1.0, 1.1
• remove unnecessary info from the responder header related to the OS, server version, application framework
  • you can use software to spoof other things
• security configuration store needs to be human-readable
• implement asset management system and register system components and software in that system
  • that way you can know about any changes that take place, and whether you allowed it
• isolate dev and prod environments, use virtualization
  • allow access only to authorized groups
    • sometimes dev environments are less secure
• implement a software control system

Database Security

• strong, typed parametrized queries
  • keep query and data separate using placeholders -- use prepared statements
• input validation (as before), output encoding
  • don't run db commanbd if they fail
• least privilege for db access
• secured credentials for db access
• connection strings shouldn't be hardcoded, but stored in a separate file on trusted system, and encrypted
• use stored procedures to abstract data access
• allow removal of permissions to tables
• unused connections should be removed asap
• change default db credentials
• use multi-factor auth for admin db access
• disable unnecessary functions
• don't install all DB features
• remove sample vendor content
• review accounts on DB, disable defaults
• application should connect to the DB with different credentials for every "trust distinction"

File Management

• don't pass user-supplied data to any dynamic "include" function
• require auth before allowing file upload
• limit file types for upload
• validate uploaded files by checking the file headers
• don't save the files in the same context -> database or file content server
• limit files that could be interpreted automatically by the server
• turn off execution privileges on files uploaded to a dir
• implement safe uploading on Unix by mounting a target file dir as a launchable drive using the associated path/chrooted environment
• use a white list of file types
• don't pass user-supplied data into a dynamic redirect
  • if you have to, the redirect should only accept validated relative path URLs
• don't pass directory/file paths; use index values mapped to a predefined list of paths
• don't send an absolute path to the client
• make sure application files and resources are read-only
• scan the file a user uploads for virus/malware

Memory Management (?)

• input/output controls for untrusted data
• buffer should be as large as specified
• if the destination buffer size is equal to the source buffer size, it may not null terminate the stream (?)
• check the buffer boundaries if calling it in a loop
• make sure there's no danger of writing past the allocated space
• truncuate input streams to a reasonable length before passing them to copy/concat function
• don't rely on garbage collection
  • explicitly close resources
    • connections
    • objects
    • file handles
• use non-executable stacks when possible
• avoid known vulnerable functions like strcat, strcopy, prntif (?)
• free the RAM

General Coding Practices

• use tested and approved managed code instead of reinventing the wheel
• use task-specific built-in APIs to conduct OS tasks
  • don't allow the application to issue commands directly to the OS, especially through application-intended command shells
• use checksums/hashes to verify the integrity of the interpreted code, libraries, executables, config files
• use locking to prevent multiple simultaneous requests, prevent race conditions
• protect shared variables and resources from inappropriate concurrent access (?)
• explicitly initialize all variables/data stores during declaration or just before first usage (?)
• raise privileges needed by application as late as possible and terminate soon after
• understand math calc in your language: byte size discrepancies, signed and unsigned distinctions, truncations, large and small numbers
• don't pass user-supplied data to any dynamic execution function
• restrict users from generating new code/altering existing code
• review all secondary apps/code/libraries
• implement safe updating
  • use and verify cryptographic signatures for your code
• use TLS to transfer code to server

Cloud Computing

Service Oriented Architecture (SOA) and Microservices

• closely mapped to business workflows
• contains sub-services optionally
• "unknown environment"
  • customers don't need to know how it works, just what it does and how to access
• self-contained
  • doesn't rely on state of other services, exposes a clear input/output interface
• allows application components to communicate over different protocols
• allows integration of services from different vendors
• parallels with
  • Unix Philosophy (each tool should do one thing very well)
  • agile

API Connectivity Issues

• API keys must be secured
• communications should use HTTPS

SAML (security assertion markup language)

• XML-based framework for exchanging security-related information
  • user auth
  • entitlement
  • attributes
• often used with SOAP
• allows us to take advantage of SSO (sign sign-on)
• the info is communicated in the form of Assertions
  • contain info about any acts of auth
  • attribute assertions -- name, address, etc.
• binding communications
  • bind to communication assertions over a network protocol

Infrastructure as Code (IoC)

• allows us to create IT environments with a little bit of code