CSSE 492 Software Dependability Seattle University Computer Science & Software Engineering Winter 2007 Prof. Roshanak Roshandel

SD 3 Secure by Design Secure by Default Secure in Deployment Secure architecture and code Threat analysis Vulnerability reduction Attack surface area reduced Unused features turned off by default Minimum privileges used Protection: Detection, defense, recovery, and management Process: How to guides, architecture guides People: Training The SD 3 Security Framework

Secure Product Development Timeline TestPlans Complete Test Plans CompleteDesignsComplete Concept CodeComplete ShipPost-Ship Test for security vulnerabilities Assess security knowledge when hiring team members Determine security sign-off criteria Send out for external review Analyze threats Learn and refine Perform security team review Train team members Test for data mutation and least privilege Resolve security issues, verify code against security guidelines =ongoing

Secure By Design Raise security awareness of design team Raise security awareness of design team Use ongoing trainingUse ongoing training Challenge attitudes - “What I don’t know won’t hurt me” does not apply!Challenge attitudes - “What I don’t know won’t hurt me” does not apply! Get security right during the design phase Get security right during the design phase Define product security goalsDefine product security goals Implement security as a key product featureImplement security as a key product feature Use threat modeling during design phaseUse threat modeling during design phase

What Is Threat Modeling? Threat modeling is a security-based analysis that: Threat modeling is a security-based analysis that: Helps a product team understand where the product is most vulnerableHelps a product team understand where the product is most vulnerable Evaluates the threats to an applicationEvaluates the threats to an application Aims to reduce overall security risksAims to reduce overall security risks Finds assetsFinds assets Uncovers vulnerabilitiesUncovers vulnerabilities Identifies threatsIdentifies threats Should help form the basis of security design specificationsShould help form the basis of security design specifications

Benefits of Threat Modeling Helps you understand your application better Helps you understand your application better Helps you find bugs Helps you find bugs Identifies complex design bugs Identifies complex design bugs Helps integrate new team members Helps integrate new team members Drives well-designed security test plans Drives well-designed security test plans Threat Vulnerability Asset

The Threat Modeling Process Identify Assets 1 Create an Architecture Overview 2 Decompose the Application 3 Identify the Threats 4 Document the Threats 5 Rate the Threats 6 Threat Modeling Process

Threat Modeling Process Step 1: Identify Assets Build a list of assets that require protection, including: Build a list of assets that require protection, including: Confidential data, such as customer databasesConfidential data, such as customer databases Web pagesWeb pages System availabilitySystem availability Anything else that, if compromised, would prevent correct operation of your applicationAnything else that, if compromised, would prevent correct operation of your application

Threat Modeling Process Step 2: Create An Architecture Overview Identify what the application does Identify what the application does Create an application architecture diagram Create an application architecture diagram Identify the technologies Identify the technologies NTFS Permissions (Authentication) File Authorization URL Authorization.NET Roles (Authentication) User-Defined Role (Authentication) SSL (Privacy/Integrity) Trust Boundary Alice Mary Bob IIS Anonymous Authentication Forms Authentication IPSec (Private/Integrity) Trust Boundary ASPNET (Process Identity) Microsoft ASP.NET Microsoft ASP.NET Microsoft Windows r Authentication Microsoft SQL Server™

Threat Modeling Process Step 3: Decompose the Application Break down the application Break down the application Create a security profile based on traditional areas of vulnerability Create a security profile based on traditional areas of vulnerability Examine interactions between different subsystems Examine interactions between different subsystems Use DFD or UML diagrams Use DFD or UML diagrams Identify Trust Boundaries Identify Data Flow Identify Entry Points Identify Privileged Code Document Security Profile

Threat Modeling Process Step 4: Identify the Threats Assemble team Assemble team Identify threats Identify threats Network threatsNetwork threats Host threatsHost threats Application threatsApplication threats

Types of threats Examples S poofing Forging messages Replaying authentication packets T ampering Altering data during transmission Changing data in files R epudiation Deleting a critical file and deny it Purchasing a product and deny it I nformation disclosure Exposing information in error messages Exposing code on Web sites D enial of service Flooding a network with SYN packets Flooding a network with forged ICMP packets E levation of privilege Exploiting buffer overruns to gain system privileges Obtaining administrator privileges illegitimately Threat Modeling Process Identify the Threats by Using STRIDE

Threat #1 (I) View payroll data 1.1 Traffic is unprotected 1.2 Attacker views traffic Sniff traffic with protocol analyzer Listen to router traffic Router is unpatched Compromise router Guess router password 1.0 View payroll data (I) 1.1 Traffic is unprotected (AND) 1.2 Attacker views traffic Sniff traffic with protocol analyzer Listen to router traffic Router is unpatched (AND) Compromise router Guess router password Threat Modeling Process Identify the Threats by Using Attack Trees

Threat Modeling Process Step 5: Document the Threats Document threats by using a template: Document threats by using a template: Leave Risk blank (for now) Leave Risk blank (for now) Threat DescriptionInjection of SQL Commands Threat target Data Access Component Risk Attack techniques Attacker appends SQL commands to user name, which is used to form a SQL query Countermeasures Use a regular expression to validate the user name, and use a stored procedure with parameters to access the database

Threat Modeling Process Step 6: Rate the Threats Use formula: Use formula: Risk = Probability * Damage Potential Use DREAD to rate threats Use DREAD to rate threats Damage potentialDamage potential ReproducibilityReproducibility ExploitabilityExploitability Affected usersAffected users DiscoverabilityDiscoverability

Threat Modeling Process Example: Rate the Threats Threat #1 (I) View payroll data 1.1 Traffic is unprotected 1.2 Attacker views traffic Sniff traffic with protocol analyzer Listen to router traffic Router is unpatched Compromise router Guess router password Damage potential Affected Users -or- Damage Reproducibility Exploitability Discoverability -or- Chance

Coding to a Threat Model Use threat modeling to help Use threat modeling to help Determine the most “dangerous” portions of your applicationDetermine the most “dangerous” portions of your application Prioritize security push effortsPrioritize security push efforts Prioritize ongoing code reviewsPrioritize ongoing code reviews Determine the threat mitigation techniques to employDetermine the threat mitigation techniques to employ Determine data flowDetermine data flow

Agenda Secure Development Process Secure Development Process Threat Modeling Threat Modeling Risk Mitigation Risk Mitigation Security Best Practices Security Best Practices

Risk Mitigation Options Option 1: Do Nothing Option 2: Warn the User Option 3: Remove the Problem Option 4: Fix It Patrolled

Risk Mitigation Process Threat Type (STRIDE) Mitigation Technique Technology SpoofingAuthentication NTLM X.509 certs PGP keys Basic Digest Kerberos SSL/TLS 1.Identify category For example: Spoofing 2.Select techniques For example: Authentication or Protect secret data 3.Choose technology For example: Kerberos

Sample Mitigation Techniques Client Server Persistent Data Authentication Data Configuration Data STRIDE  SSL/TLS  IPSec  RPC/DCO with Privacy  Firewall  Limiting resource utilization for anonymous connections  Strong access control  Digital signatures  Auditing Insecure Network

Agenda Secure Development Process Secure Development Process Threat Modeling Threat Modeling Risk Mitigation Risk Mitigation Security Best Practices Security Best Practices

Run with Least Privilege Well-known security doctrine: Well-known security doctrine: “Run with just enough privilege to get the job done, and no more!” Elevated privilege can lead to disastrous consequences Elevated privilege can lead to disastrous consequences Malicious code executing in a highly privileged process runs with extra privileges tooMalicious code executing in a highly privileged process runs with extra privileges too Many viruses spread because the recipient has administrator privilegesMany viruses spread because the recipient has administrator privileges

References Threat Modeling Threat Modeling Frank Swiderski and Window Snyder (Author), MicrosoftFrank Swiderski and Window Snyder (Author), Microsoft Writing Secure Code Writing Secure Code Michael Howard and David C. LeBlanc, MicrosoftMichael Howard and David C. LeBlanc, Microsoft