Scratchpad and Secure Code Design and Implementation: Difference between pages
NickPGSmith (talk | contribs) m (4 revisions imported) |
NickPGSmith (talk | contribs) |
||
Line 1: | Line 1: | ||
== Software Development Lifecycle == | |||
=== Software Platforms === | |||
* Endpoint applications (self contained on device) | |||
* Client/Server apps | |||
* | === Development Methodologies === | ||
** | |||
* Change | 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 |
Revision as of 18:49, 7 January 2022
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