Secure Code Design and Implementation

From Smithnet Wiki
Revision as of 18:49, 7 January 2022 by NickPGSmith (talk | contribs) (→‎Application Attacks)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Software Development Lifecycle

Software Platforms

  • Endpoint applications (self contained on device)
  • Client/Server apps

Development Methodologies

Incorporate security at every stage

  • Waterfall: rigid, linear, steps
  • Spiral: iterative process
    • Begin / Dev & Test / Risk Assess / Determine Requirements / recycle
  • Agile (continuous dev, short dev/release cycles); prioritise:
    • Individuals/interactions over processes/tools
    • Working Software over documentation
    • Customer collaboration over contracts
    • Respond to change over follow plan

Maturity Models

Standard benchmarks: CMMI (Capability Maturity Model Integration):

  • Initial
  • Managed
    • Reuse code, config management, project planning, QA, requirements management
  • Defined
    • Documented practices, integrated project management, risk management, validation, etc
  • Quantitatively Managed
    • Organisation process management, quantitative project management
  • Optimising
    • Continuous process management, causal management and resolution

Current version used for software dev plus supply chain and others.

IDEAL model is an alternative:

  • Initialising
  • Diagnosing
  • Establishing
  • Action
  • Learning

Change Management

  • Request control
  • Change control > through CAB, docs
  • Release management > through QA against RFC
  • Dev > Test > Staging > Production environments

Automation and DevOps

Build collaborative relationships Embrace automation Facilitate rapid releases Provide a stable operating environments

DevOps and Agile both seek continuous operation "interactions as code2 > eg script to change Base OS image to specific requirement > scalable, use of immutable servers, reduce errors, facilitate testing Facilitates security automation > "DevSecOps"

  • Continuous validation
  • Continuous integration
  • Continuous delivery
  • Continuous deployment
  • Continuous monitoring

Software Quality Assurance

Code Review

Peer analysis Formal, FAGAN:

  • Planning
  • Overview > assign roles
  • Preparation
  • Meeting > discuss issues/defects
  • Rework > corrective actions
  • Follow-up > confirm finish

(repeat)

Software Testing

  • Verification and validation: are we building the right software & are we building the software right
  • Stress testing
  • UAT
  • Regression testing

Code Security Tests

Static: software is examined for common errors Dynamic: code is executed and tested (synthetic transactions)

Fuzz Testing

Dev supplied input, valid or invalid

  • Generation
  • Mutation (real date + changes)
  • eg use Zed Attack Proxy (ZAP)

Code Repositories

Avoid dead code Public or private Sensitive info must be removed from public repositories Integrity management > check hashes

Application Management

Control: whilelist/blacklist

eg Windows AppLocker (restrict running of software)

Automated processes for updates

Host system baselining

Third-party Code

Libraries, SDKs, APIs, Outsourced code

Application Attacks

OWASP Top 10

  • Injection flaws
  • Broken authentication
  • Sensitive data exposure
  • External entities
  • Broken access control
  • Security misconfiguration
  • XSS
  • Insecure deserialization
  • Using components with known vulnerability
  • Insufficient logging/monitoring

Application Security

Application hardening:

  • Use proper auth, encrypt data, validate user input, avoid/remediate known exploits, deploy obfuscaton and camouflage
  • Prompt patching is critical
  • Application config:
    • type and scope of encryption
    • access granted to authorise
    • security of underlying infrastructure

Configuration baselines allow quick identification

Prevent SQL Injection

Input validation eg never pass single quotes; use parameterised SQL

Cross-site Scripting

Takes place without knowledge of victim. Don't allow <script> in user input.

Request Forgery (CSRF/XSRF)

Uses the fact often many tabs open to different sites; auth cookies transfer between tabs. eg <img> tag but URL executes another function

  • Rearchitect web app -> don't use GETs; auto-logging out users after time.

Server Side Request Forgery (SSRF)

Change metadata; being send to sever to trick

Defend Against Directory Traversal

  • Webgoat and ZAP
  • Prevent "." in input
  • Strict access control

Overflow Attacks

When buffer size is insufficient for input data

Cookies and Attachments

Stored in browser; track activity. Used in apps too.

Session Hijacking

Cookie provides an authentication session reference. If not random -> guessable

  • Cookie guessing
  • Session replay attacks
  • Should be sent over an encrypted channel

Code Execution Attacks

  • Arbitrary code execution (perhaps remote)
  • Install malicious code
  • Join a botnet
  • Create accounts for later use

Mitigate by:

  • Limit application access
  • Patch systems & applications

Privilege Escalation

Gain administrative access attacks

  • Perform input validation
  • Enforce least privilege principle
  • Use DEP and ALSR technologies

Driver Manipulation

Memory Vulnerabilities

Race Condition Vulnerabilities

Secure Coding Practices

Input Validation

  • Whitelisting: powerful but not always possible
  • Blacklisting: eg prohibit SQL keywords

Parameterized Queries

  • SQL is not sent, only data to a stored procedure

Authentication and Session Management Issues

  • Never store plaintext passwords: use hashed & slated (protect against rainbow attacks)
  • Encrypt passwords in transit: TLS

Output Encoding

Take a dangerous character and replace, eg HTML encoding; URL encoding

Error and Exception Handling

Code Signing

  • Obtain a cert from a CA; sign code
  • Check public key to validate the signature's hash matches this code

Database Security

  • Database normalisation
    • prevent inconsistency
    • prevent update anomalies
    • reduce need for restructuring
    • make DB schema more informative

1st Normal Form

  • Create separate tables for different sets of related data
  • Provide a primary key for every table
  • Records may not have multivalued fields
  • Records in a table must have the same number of fields

2nd Normal Form (adds)

  • Every non-key fields must be a fact about the entire key

3rd Normal Form (adds)

  • No non-key fields may be a fact about another non-key fields

Notes:

  • Information at rest in a DB
  • Database activity monitoring
  • Use stored procedures where possible

Data Deidentification

Identifying individuals, eg ZIP/Birthday/Gender combination -> 87% unique

Anonymise data -> HIPPA standard

  • Expert determination approach
  • Safe harbour approach -> remove standard IDs

Data deobfuscation

  • Hashing & salting
  • Tokenisation: replaces sensitive fields with random identifiers
  • Hashing: redact sensitive information