Information Systems Security

Transcription

1 Information Systems Security Lecture 4: Security Engineering Prof. Dr. Christoph Karg Aalen University of Applied Sciences Department of Computer Science Learning Objective Learning Objective This lecture s learning objective is an introduction to the topic of security engineering. The following questions are addressed: What is the goal of security engineering? Of which parts consists the security engineering process? Which techniques exist for threat risk modeling? What is a security policy? What does threat modeling mean? C. Karg (Information Systems Security) 4. Security Engineering 2 / 53

2 Overview Overview Security engineering definition Security engineering process Analysis phase Modeling phase Implementation phase Microsoft thread modeling process Security development life cycle Common security mechanisms C. Karg (Information Systems Security) 4. Security Engineering 3 / 53 Security Engineering Security Engineering Specialized field of engineering Goal: Build systems to remain dependable in the face of malice, error, or mischance Focus on tools, processes, and methods needed to design, implement, and test complete systems to adapt existing systems as their environment envolves Requires cross-disciplinary expertise such as Cryptography and computer security Hardware tamper-resistance Formal methods Knowledge of economics Applied psychology The law C. Karg (Information Systems Security) 4. Security Engineering 4 / 53

3 Analysis Framework Security Engineering Policy Incentives Mechanism Assurance C. Karg (Information Systems Security) 4. Security Engineering 5 / 53 Security Engineering Analysis Framework (Cont.) Interaction of four components: Policy: What are you supposed to achieve? Mechanisms: Which mechanisms (ciphers, access control, hardware tamper-resistance,... ) do you assemble to implement the policy? Assurance: How reliant is each of the deployed mechanisms? Incentives: What are the reasons that people guarding and maintaining your systems work properly? why attackers try to defeat your policy and to attack your systems? C. Karg (Information Systems Security) 4. Security Engineering 6 / 53

4 Security Engineering Process Overview Security Engineering Is An Ongoing Process Problem Improvement Requirements & Risks Assessment Adapt Verify Plan Execute Action Measurement & Validation Implementation Operational System C. Karg (Information Systems Security) 4. Security Engineering 7 / 53 Security Engineering Process Overview Phases Of The Engineering Process Application Area Requirements audit Threat Analysis Analysis Risk Assessment specify Modeling Security Policy Security Model Model Verification Priliminary Design Validation Integration Testing Security Architecture Concept Modul Testing Security Model Code Inspection maintenance of operation C. Karg (Information Systems Security) 4. Security Engineering 8 / 53

5 Security Engineering Process Prerequisites Prerequisites Application Area: Which industrial sector? Which geographic region? Which environment? Security Requirements: Technical aspects Organizational aspects Legal aspects C. Karg (Information Systems Security) 4. Security Engineering 9 / 53 Security Engineering Process Analysis Phase Structural Analysis Goal: Provide detailed information on the structure of the company and provide respective security requirements Categories: Infrastructure: Buildings, power supply, telecommunications,... IT-Infrastructure: Network Hardware components Software Organization: Corporate structure Departments Business processes C. Karg (Information Systems Security) 4. Security Engineering 10 / 53

6 Security Engineering Process Analysis Phase Threat Analysis Goal: systematically detect potential organizational, technical, and user-related reasons for threats, which may cause damage Approach: Search vulnerabilities Physical defects Software defects Analyze organizational processes Useful helpers: Penetration Testing Security Chains C. Karg (Information Systems Security) 4. Security Engineering 11 / 53 Security Engineering Process Analysis Phase Penetration Testing A penetration test consists of Password cracking attacks Attacks by recording and manipulation the network traffic Attacks by using known exploits Approach: 1. Internet research to collect publicly available information such as IP addresses 2. Usage of a port scanner to detect accessible services of an IT system 3. Usage of fingerprinting methods to detect the operating system and its version, the type of web browser, etc. 4. Identification of known exploits of the IT system 5. Usage of known exploits to get unauthorized access to the system C. Karg (Information Systems Security) 4. Security Engineering 12 / 53

7 Security Engineering Process Analysis Phase Security Chains Security chains are a tool to analyze the threats of processes within a company A security chain splits up a business or organizational process into single steps Potential threats are associated with each step of the chain Both threats of technical and non-technical kind are considered C. Karg (Information Systems Security) 4. Security Engineering 13 / 53 Security Engineering Process Analysis Phase Security Chain Example Social Engineering Sniffing Keylogger Virus Spoofing, Sniffing, DoS User System Access Authentification Place Of Work Access Control Intranet Firewall, IDS Service Content Provider Internet Server WWW, ERP Spoofing, DoS, Privacy Sniffing, DoS, Profiling Worms, DoS Security chain for a user working in the accounting department C. Karg (Information Systems Security) 4. Security Engineering 14 / 53

8 Security Engineering Process Analysis Phase Risk Assessment Formula: Risk R = S E, where S amount of damage E occurrence probability of the threat Assignment of S: Primary damage causes personnel costs, loss of production, or costs of reproduction Secondary damage loss of reputation and trust Assignment of occurrence probability E: Complexity of the attack Benefit of the attack C. Karg (Information Systems Security) 4. Security Engineering 15 / 53 Security Engineering Process Analysis Phase Threat Risk Modeling Goals Define the security requirements of an application Identify potential threats and vulnerabilities Identify a logical thought process in defining the security of a system Find bugs in the application earlier Create a documentation to be used to specify security specification and security testing procedures Provide a justification for purchasing security related hardware and software C. Karg (Information Systems Security) 4. Security Engineering 16 / 53

9 Security Engineering Process Analysis Phase Threat Modeling Systems Microsoft Threat Modeling Process Common Vulnerability Scoring System (CVSS) ( Common Weakness Scoring System (CWSS) ( OCTAVE ( C. Karg (Information Systems Security) 4. Security Engineering 17 / 53 Security Engineering Process Modeling Phase Modeling Phase A security policy describes the target state of an IT system usually as a criteria catalog It is necessary to adjust the security (target state) with the results provided by the threat analysis and risk management (current state) A security model is a scheme for specifying and enforcing security policies C. Karg (Information Systems Security) 4. Security Engineering 18 / 53

10 Security Engineering Process Modeling Phase Design Principles Fail-safe defaults: Access is denied per default. Access must be granted explicitly Complete mediation: Every access must be checked for acceptance Need to know: Each subject gets only the access rights, it needs for fulfillment of its tasks Economy of mechanism: the deployed security mechanisms must be easy to use and should be applied automatically as a matter of routine Open design: any design methods and mechanisms should be unfolded ( no security through obscurity ) C. Karg (Information Systems Security) 4. Security Engineering 19 / 53 Security Engineering Process Modeling Phase Security Policies A security policy defines the set of technical and organizational rules directives of behavior responsibilities roles, and procedures of a system or a organizational unit C. Karg (Information Systems Security) 4. Security Engineering 20 / 53

11 Security Engineering Process Modeling Phase Example: Password Policy All system-level passwords (e.g., root, NT admin) must be changed on at least a quarterly basis All user-level passwords (e.g., , web, desktop computers, etc.) must be changed at least every six month. The recommended change interval is every four month User accounts that have system-level privileges granted through group memberships or programs such as sudo must have a unique password from all other accounts held by that user Passwords must not be inserted into messages or other forms of electronic communication C. Karg (Information Systems Security) 4. Security Engineering 21 / 53 Security Engineering Process Implementation Phase Implementation Phase The implementation phase puts the modeling results into work. The security architecture is derived from the security model. It describes the security mechanisms to be deployed in order to be compliant to the model. A validation is necessary to check whether the security architecture was implemented correctly. Note: security engineering is a consecutive and iterative process. C. Karg (Information Systems Security) 4. Security Engineering 22 / 53

12 Microsoft Threat Modeling Process The Modeling Process Microsoft Threat Modeling Process Identify Security Objectives Application Overview Identify Vulnerabilities Decompose Application Identify Threats C. Karg (Information Systems Security) 4. Security Engineering 23 / 53 Microsoft Threat Modeling Process Identify Security Objectives Identify Security Objectives Categories of security objectives: Identity Does the application protect the user identity from abuse? Are there control mechanisms to ensure evidence of identity? Financial Aspects Is there a financial loss in case of the security breach of the application? How high is the risk of a financial loss? C. Karg (Information Systems Security) 4. Security Engineering 24 / 53

13 Microsoft Threat Modeling Process Identify Security Objectives Identify Security Objectives (Cont.) Reputation Is there a loss of reputation if the application is successfully attacked? Can this loss be quantified? Privacy and Regulatory Does the application protect user data? Does the user data underlie any legal policies? Availability Guarantees Has the application to fulfill a service level agreement? To what level has the application to be available? What are the penalties for being unavailable? C. Karg (Information Systems Security) 4. Security Engineering 25 / 53 Microsoft Threat Modeling Process Identify Security Objectives Application Overview And Decomposition Analyze the application design to identify components of the application data flow between the components trust boundaries High level UML diagrams are a helpful tool Decompose the application to identify the security-related modules which need to be evaluated C. Karg (Information Systems Security) 4. Security Engineering 26 / 53

14 Microsoft Threat Modeling Process Identify Threats Identify Threats Use online resources to find relevant exploits Exploit Database ( Open Source Vulnerability Database ( Check the existing exploits against the modules of your application Document the existing threats using threat graphs, or threat lists Draw attack trees to estimate the chance of a successful attack C. Karg (Information Systems Security) 4. Security Engineering 27 / 53 Microsoft Threat Modeling Process Identify Threats Threat Graph Example Attacker may be able to read other users messages User may not have logged off on a shared computer Authorization may fail, allowing unauthorized access Data validation may fail, allowing SQL injection Browser cache may contain contents of a message Implement data validation Implement authorization checks Implement anti caching HTTP headers If risk is high, use SSL C. Karg (Information Systems Security) 4. Security Engineering 28 / 53

15 Microsoft Threat Modeling Process Identify Threats Threat List Example Threat: Attacker may be able to read other user s messages Attack: 1. User may not have logged off on a shared computer 2. Data validation may fail, allowing SQL injection Implement data validation 3. Authorization may fail, allowing unauthorized access Implement authorization checks 4. Browser cache may contain contents of a message Implement anti-caching HTTP headers If risk is high, use SSL C. Karg (Information Systems Security) 4. Security Engineering 29 / 53 Microsoft Threat Modeling Process Identify Threats Attack Trees The root of the tree represents the attack goal. The internal nodes represent sub-ordinate targets. Node types OR node one of child targets is necessary to cause the threat. AND node all child targets must be fulfilled to cause threat. All pathes from leafs to the root describe different ways for a successful attack. C. Karg (Information Systems Security) 4. Security Engineering 30 / 53

16 Microsoft Threat Modeling Process Identify Threats Example: Masquerading Of A Mobile Device attack target masquerade attack decision node attack step beyond technical scope local login AND remote login valid login possession of the device without authentication login required stealing threaten owner blackmail owner appropriation AND auth token required auth data required without user s assistance with user s assistance without biometrics with biometrics forgery stealing threaten owner blackmail owner appropriation threaten owner blackmail owner forgery lost device unattended device disposed device C. Karg (Information Systems Security) 4. Security Engineering 31 / 53 Microsoft Threat Modeling Process Identify Threats Example: Risk Assessment Of An Attack Tree sniffing of a user password Risk: very high MAX spy out the unencrypted access to stored terminal input network transmission password data Risk: low Risk: very high Risk: high C. Karg (Information Systems Security) 4. Security Engineering 32 / 53

17 Microsoft Threat Modeling Process STRIDE STRIDE STRIDE is a classification scheme for threats Goal: Classify known threats according to the kinds of exploit there are used STRIDE stands for Spoofing identity Tampering with data Repudiation Information disclosure Denial of service Elevation of privilege C. Karg (Information Systems Security) 4. Security Engineering 33 / 53 Microsoft Threat Modeling Process STRIDE STRIDE (Cont.) Spoofing Identity Key risk of applications with multi-user-access such as databases, file servers,... Users should not be able to become any other user or get privileges of other users. Tampering with Data A user should not get unauthorized access to confidential data. The application should check data received from users. C. Karg (Information Systems Security) 4. Security Engineering 34 / 53

18 Microsoft Threat Modeling Process STRIDE STRIDE (Cont.) Repudiation Users may dispute transactions they have performed. If non-repudiation is a necessary feature, then appropriate mechanisms such as access logs or audit trails must be deployed. Information Disclosure If an attacker reveals confidential user data stored in the application, this may cause a loss of confidence and reputation. Hence, application must include strong access controls to prevent tampering and abuse of confidential data. C. Karg (Information Systems Security) 4. Security Engineering 35 / 53 Microsoft Threat Modeling Process STRIDE STRIDE (Cont.) Denial of Service An application should be checked against use of expensive resources such as processing of large files, complex computations, heavy-duty database queries,... Expensive operations should be restricted to authenticated and authorized users.. Elevation of Privilege An application with distinct user and administrator roles should ensure that a normal user cannot elevate his role to a higher privilege. C. Karg (Information Systems Security) 4. Security Engineering 36 / 53

19 Microsoft Threat Modeling Process DREAD Risk Assessment DREAD Risk Assessment DREAD is a classification scheme for quantifying the risk of a given threat. Using DREAD, threats can be compared and prioritized. DREAD stands for Damage Potential Reproducibility Exploitability Affected Discoverability C. Karg (Information Systems Security) 4. Security Engineering 37 / 53 Microsoft Threat Modeling Process DREAD Risk Assessment The DREAD Formula DREAD Formula: Risk DREAD = S DA + S RE + S EX + S AF + S DI 5 where S DA = score damage potential S RE = score reproducibility S EX = score exploitability S AF = score affected users S DA = score discoverability Note: Each score must have a value in {0, 1, 2,..., 10}. C. Karg (Information Systems Security) 4. Security Engineering 38 / 53

20 Microsoft Threat Modeling Process DREAD Risk Assessment Quantifying DREAD Categories Example Damage Potential: If a threat occurs, how much damage will be caused? 0 = Nothing 5 = Individual user data is compromised or affected 10 = Complete system or data destruction Reproducibility: How easy is it to reproduce the threat exploit? 0 = Very hard or impossible, even for administrators of the application 5 = One or two steps required be an authorized user 10 = Usage a web browser without authentification C. Karg (Information Systems Security) 4. Security Engineering 39 / 53 Microsoft Threat Modeling Process DREAD Risk Assessment Quantifying DREAD Categories Example (Cont.) Exploitability: What is needed to exploit this threat? 0 = Advanced programming and network knowledge with custom or advanced attack tools 5 = Malware exists on the Internet, or exploit is easily performed, using available attack tools 10 = Just a web browser Affected Users 0 = None 5 = Some users, but not all 10 = All users Discoverability: Usually set to 10 by convention C. Karg (Information Systems Security) 4. Security Engineering 40 / 53

21 Security Development Life Cycle Security Development Life Cycle (SDL) Process to increase the quality of software development Introduced by Microsoft Paradigms Secure by design software is designed to protect itself and the processed information against attacks Secure by default user gets minimal access rights by default Secure in deployment provision of manuals and tools that support the user in securely applying the software Communication developers shall be upfront with exploits and provide patches rapidly C. Karg (Information Systems Security) 4. Security Engineering 41 / 53 SDL Process Security Development Life Cycle C. Karg (Information Systems Security) 4. Security Engineering 42 / 53

22 Security Development Life Cycle SDL Process Phases 1. Training: Training of the software developer 2. Requirements: Identification of the security requirements and the protection targets of the software 3. Design: Identification of the essential components Definition of a software architecture Threat modeling 4. Implementation: Usage of tools to avoid vulnerabilities Code reviews C. Karg (Information Systems Security) 4. Security Engineering 43 / 53 Security Development Life Cycle SDL Process Phases (Cont.) 5. Verification: Beta testing of the fully completed software systematical search of defects (security push) 6. Release: Final security review to check whether the software is ready for the market 7. Response: Process to react on exploits fast and comprehensively C. Karg (Information Systems Security) 4. Security Engineering 44 / 53

23 Common Security Mechanisms Common Security Mechanisms User identification and authentification Management and enforcement of user permissions Auditing Recycling of common used resources Maintenance of system availability C. Karg (Information Systems Security) 4. Security Engineering 45 / 53 Common Security Mechanisms User Identification And Authentication User Identification And Authentication Goal: Defense against masquerading attacks and unauthorized access Requirements: Subjects must have an unique identifier Mandatory authentification mechanism Common authentication mechanisms: Passwords ( What you know ) Smart cards or security tokens ( What you have ) Biometric authentication ( What you are ) C. Karg (Information Systems Security) 4. Security Engineering 46 / 53

24 Common Security Mechanisms User Permissions User Permissions Goal: Prevent unauthorized access to files and other system resources. Approach: a users needs the appropriate rights to access an object. The assignment of permissions must be viewed as a dynamic process. Usually, a policy regulates which permissions are assigned to an user. Role-based approach: a user gets only the permissions which are necessary for the user s tasks. Owner Principle: only the owner of an object can modify its permissions. C. Karg (Information Systems Security) 4. Security Engineering 47 / 53 Common Security Mechanisms Enforcement Of User Permissions Enforcement Of User Permissions User permissions must be enforced to prevent unauthorized access of information and resources. Complete mediation: every access to every object must be checked. Complete mediation is difficult to implement. Implementation via file handles and file descriptors. Challenge: Removal of permissions of resources which are already in usage. C. Karg (Information Systems Security) 4. Security Engineering 48 / 53

25 Common Security Mechanisms Audits Audits Goal: Collect data to analyze computer systems after an attack, ant to prevent suspects to deny their actions A security policy regulates which data is collected Usually the following data is gathered: Authentification attempts of users Access to files, system resources, databases Logs of web servers Changes of user permissions Important: the access to the data logs must be controlled to protect the users privacy. C. Karg (Information Systems Security) 4. Security Engineering 49 / 53 Common Security Mechanisms Recycling Of Common Used Resources Recycling Of Common Used Resources Goal: Preparation of commonly used resources to prevent information leakage. Commonly used resources: Main memory of a computer Hard disks or network shares Portable storage such as USB sticks Laptops and mobile phones used as substitutes in case of a hardware defect A policy should rule how a freed resource is recycled. C. Karg (Information Systems Security) 4. Security Engineering 50 / 53

26 Common Security Mechanisms Maintenance Of System Availability Maintenance Of System Availability Goal: Prevention of Denial-Of-Service Attacks Approach: Prioritization of the importance of the deployed services The redundancy of critical hardware components improves the availability. An emergency plan defines processes to recover from an incident such as system failure or a DOS attack. C. Karg (Information Systems Security) 4. Security Engineering 51 / 53 Summary Summary Security engineering is a kind of systems engineering which focuses on security topics concerning IT systems. The development phases are analysis of the infrastructure, modeling of security policies, and deployment of a security architecture. Security Development Life is an approach to improve security in software development. Security engineering is an ongoing process. C. Karg (Information Systems Security) 4. Security Engineering 52 / 53

27 Summary References J. R. Vacca: Computer And Information Security Handbook, Morgan-Kaufman, R. J. Anderson: Security Engineering: A Guide to Building Dependable Distributed Systems, Wiley, A. Basta, W. Halton: Computer Security and Penetration Testing, Thomson, J. Slay, A. Koronios: Information Technology Security & Risk Management, Wiley, OWASP Project: Threat Risk Modeling (https: // C. Karg (Information Systems Security) 4. Security Engineering 53 / 53