CSC 415: Exam 1

Risk Management Framework (SS Pillar)

(risk = probability * impact) 1) Understand business context 2) Identify business and technical risks 3) Prioritize risks into a ranked set 4) Define mitigation strategy 5) Carry out fixes and validate

Information Processing

1) Aggregation 2) Identification 3) Insecurity 4) Secondary Use 5) Exclusion

Information Dissemination

1) Breach of confidentiality 2) Disclosure 3) Exposure 4) Increased accessibility 5) Blackmail 6) Appropriation 7) Distortion

The 3 Security Principles

1) Defense in Depth 2) No security through obscurity 3) Disallow by Default

OWASP Top 10 Vulnerabilities

1) Injection 2) Broken Auth/Session Management 3) Cross-Site Scripting 4) Broken Access Control 5) Security Misconfiguration 6) Sensitive Data Exposure 7) Insufficient Attack Protection 8) Cross-Site Request Forgery 9) Components w/ Known Vulnerabilities 10) Underprotected APIs Injection, XSS and Broken Auth have been on the ris

Cross-Site Request Forgery Mitigation

1) Make sure you are not vulnerable to XSS attacks. 2) Use Anti-CSRF Tokens (Nonce or HMAC) 3) Check headers 4) Require multiple steps to complete dangerous operations

Cross-Site Scripting Mitigation

1) Never trust user input 2) Use static analysis tool to detect injection vulnerabilities 3) Implement security checks client-side and server-side 4) Use a blacklist or whitelist 5) Sanitize input 6) Use encoding libraries

Injection Attack Mitigation

1) Never trust user input 2) Use static analysis tool to detect injection vulnerabilities 3) Implement security checks client-side and server-side 4) Use a blacklist or whitelist 5) Sanitize input 6) Use prepared statements 7) Use database frameworks

3 Software Security Pillars

1) Risk Management 2) Touchpoints 3) Knowledge

CWE/SANS Top 25 Weaknesses

1) SQL Injection 2) OS Command Injection 3) Buffer Overflow 4) XSS 5) Missing Auth 6) Hard-Coded Credentials 7) Missing Encryption 8) Unrestricted File Uploads 9) Lack of Input Sanitization These weaknesses are what LEADS TO software vulnerabilities.

Information Collection

1) Surveillance - watching/listening/recording an individual's behavior 2) Interrogation - questioning/probing an individual for information

Code of Fair Information Practices

1) There must be no secret record-keeping system 2) There must be a way for a person to find out what information is being collected and how it is being used 3) The must be a way for a person to decide how their information can be used 4) The must be a way for a person to correct information about themselves 5) Whoever is in charge of the system must assure the reliability of the data and prevent misuse.

Seven Touchpoints (SS Pillar)

1) code reviews 2) architectural risk analysis 3) penetration testing 4) risk-based security testing 5) abuse cases 6) security requirements 7) security operations

Knowledge Catalogs (SS Pillar)

1) principle - statement of wisdom derived from experience 2) guideline - recommendation for how to do/not do development (SEMANTICS) 3) rule - recommendation for how to do/not to do development (SYNTAX) 4) vulnerability - result of a software defect that an attacker can exploit 5) exploit - instance of an attack that takes advantage of a vulnerability 6) attack pattern - identify and predict exploits within the system 7) historical risk - identified risks during development

Software Security Misconceptions

1) software security can be accomplished using a single tool 2) modern programming languages are secure 3) firewalls are enough for security 4) penetration testing is the only testing that you need to do 5) cryptography solves everything 6) finding bugs is the software security 7) my software isn't important enough to be a target 8) security is only the dev's problem 9) only software in sensitive domains needs to be secure (review counter-arguments)

HIPAA

3 Parts: 1) Protection for privacy of Protected Health Information 2) Protection for security of Protected Health Information 3) Standards for electronic data exchange in healthcare 4 Requirements: 1) Access Control 2) Audit Control 3) Integrity Control 4) Transmission Security

Design Flaw vs. Implementation Bug

A design flaw is a mistake or weakness in the design of the software. An implementation bug is an error, failure, flaw, or fault within a piece of software. Roughly a 50/50 split IRL.

Security Vulnerability

A design flaw or an implementation bug that may allow an attacker to exploit software for malicious purpose.

Dangers of Improper Restriction of Excessive Authentication Attempts

Allowing excessive auth atempts makes the system susceptible to brute force attacks. Mitigate by disconnecting/locking the account after small number of attempts, using a lockout period to slow down attempts, and requiring the completion of computational tasks (CAPTCHAs)

Privacy Breach

An activity creates harm by disrupting the activities of others.

Protected Health Information (PHI)

Any individually identifiable health information that can be used to get the patient's identity, the services they receive, their payment methods, etc. Examples: birthday contact info VIN IPs Biometrics Account/Record numbers

Dangers of URL Redirection Attacks

Attacker can identify these "open redirects" and change the destination to a malicious URL. Mitigate by not using open redirects, validate redirects to make sure they remain on the network/server, and warn users when they are leaving the host website.

Dangers of Untrusted Inputs

Attacker can modify input to bypass security mechanisms to get critical information to use/steal. Mitigate by performing checks on client-side and server-side, sanitize user input, use blacklist/whitelist, and only store state information server-side

Invasion of Privacy

Characterized by intrusion or decisional interference

Common Security Objectives

Confidentiality Integrity Availability Identification & Authentication Accountability Privacy

Integrity (Security Objective)

Degree to which a system/component guards against improper modification or destruction of computer programs or data

Availability (Security Objective)

Degree to which a system/component is operational and accessible when required for use

Accountability (Security Objective)

Degree to which actions affecting software assets can be traced to the actor responsible for the action

Privacy (Security Objective)

Degree to which an actor can understand and control how their information is used

Confidentiality (Security Objective)

Degree to which the data is disclosed only as intended

Dangers of Incorrect Authorization

Executing an auth check incorrectly. Use a proper access controls: 1) Discretionary Access Control (DAC) is the most flexible and least-safe since it permits delegation of privileges to individual users. 2) Mandatory Access Control (MAC) restricts access to objects based on sensitivity. Used by governments. 3) Role-Based Access Control (RBAC) grants access based on assigned role of user. Keeps users on a "need to know" basis. RBAC has the benefit of being Many-to-Many Avoid issues by performing control checks on users before they try to do an action, not displaying links or buttons to unauthorized functions, following the principle of least-privilege by setting very strict default permissions.

Dangers of Unrestricted File Uploads

Hackers can upload malicious scripts and files and use them for attacks. Mitigate by validating file types, using anti-virus to scan inputted files, and store files in a DB separate from the system.

Covered Entity

Healthcare provides that transmit and/or maintain PHI.

Cross-Site Scripting

Input creates dynamic HTML elements (change appearance, transfer data, hijack session) 1) Reflected XSS 2) Stored XSS

Privacy Policy

Natural language description of how information is collected, used, and disclosed. 4 Parts: 1) Notice/Awareness 2) Choice/Consent 3) Integrity/Security 4) Access/Participation

Identification & Authentication (Security Objective)

Need to establish that a claimed identity is valid for a user, process, or device.

Right to Privacy

Our right to keep a domain around us which includes all things that are part of us. We have the ability to choose which parts of this domain can be accessed by others and to what extent.

Gramm-Leach Bliley Act (GLBA)

Protect consumer personal financial information 3 Principle Parts/Rules: 1) Financial Privacy 2) Safeguards 3) Pretexting Provisions

FERPA

Protects privacy of student education records, gives parents certain rights w/ respect to their children's records.

Injection Attacks

Unvalidated input is embedded with instruction stream that executes on the system Simple: use ; or " to break up statements and insert your own Tautology: use ' OR '1'='1 to get everything Destruction: use : DROP TABLE users; --' to delete and stop all following code Union: special type of attack to get other tables in the DB, add UNION ALL SELECT*... to ask about whatever you want Advanced: use error messages or stuff like user() or database() to get info about the system

Dangers of Path Traversal Attacks

User can explore the system and access files or directories outside of the ones they are authorized to use. Mitigate by performing checks on client-side and server-side, sanitize user input, use blacklist/whitelist, only store state information server-side, and use the principle of least privilege!

Dangers of Sensitive Data Exposure

When an attacker gains unauthorized access to sensitive data and resources. Data must be secure at rest and in-transit. Mitigate by classifying data by impact level (Low, Mid High or Public, Confidential, Sensitive, or Red, Yellow, Green) and implementing strategies appropriate with each level. Do not store any unnecessary sensitive data, its just extra risk.

Cross-Site Request Forgery

When an attacker takes advantage of a web app that cannot/does not sufficiently verify whether a request was intentionally provided by the user

Dangers of Uncontrolled Format Strings

When an attacker uses printf-style functions to cause buffer overflows or data representation problems. Mitigate by sanitizing user input and running static analysis tools.

Dangers of Broken/Missing Authentication

When software does not require authentication for functionality for user-specific or resource-intensive actions. Attackers can hijack sessions and impersonate users. Best practices include encrypting essential data, using session IDs that expire, CAPTCHAs, and Multifactor Authentication strategies. Mitigate these vulnerabilities by diving software into privilege areas, using a centralized auth mechanism, and performing security checks

Dangers of Improper Encryption

When software fails to encrypt sensitive data at rest or in-transit. Hashing is not encryption, its one-way! Use it for comparing values without storing plaintexts. Mitigate by using industry approved cryptography methods, ensuring the encryption systems are properly integrated, hashing w/ salt, carefully managing keys, building modular cryptographic systems.

Dangers of Buffer Overflow Attacks

When the attacker takes advantage of a system that copies input->output buffer without validating the size. Software executes code outside of authorized scope. Mitigate by using libraries that do not allow buffer overflows, use compiler extensions to detect vulnerabilities, validate user inputs, run with principle of least-privilege.

Dangers of Integer Overflow Attacks

performing a calculation that can produce an integer overflow or wraparound. Stems into other attacks if calculation is used for resource management, execution control, etc. Mitigate by being diligent with your data types, performing code inspections, checking for OOB values in your calculation, and using dedicated libraries for large calculations.