software security engineering

40
Software Security Engineering

Upload: aizazhussain234

Post on 15-Apr-2017

209 views

Category:

Software


0 download

TRANSCRIPT

Page 1: Software security engineering

Software Security Engineering

Page 2: Software security engineering

What we will learn today• Security concepts• Security risk management• Design for security• System survivability

Page 3: Software security engineering

What is Security Engineering ?

Security engineering is concerned with how to develop and maintain systems that can resist malicious attacks intended to damage a computer-based system or its data.

Page 4: Software security engineering

Why Security Engineering?

• To make more dependable systems we need to secure over systems from the threats from malicious and technically skilled attackers as well as problems resulting from accidentals mistakes in the development process.

• This has become a priority for businesses and individuals as more and more criminals try to exploit networked systems for illegal purposes.

Page 5: Software security engineering

Security Concepts

Page 6: Software security engineering

Security Concepts

• Assets• Exposure• Vulnerability• Attack• Threats• Control

Page 7: Software security engineering

Security concerns

• Confidentiality Ensuring that data is only accessible to authorized people and organizations

• Integrity Ensuring that external attacks cannot damage data and programs

• Availability Ensuring that external attacks do not compromise the availability of data and programs

Page 8: Software security engineering

Controls for security

• Controls that intend to ensure that the attacks are unsuccessful.• Controls that are intended to detect and repel attacks.• Controls that support from recovery problems.

Page 9: Software security engineering

Application/infrastructure security

• Application security is a software engineering problem where the system is designed to resist attacks.

• Infrastructure security is a systems management problem where the purchased infrastructure is configured to resist attacks.

Page 10: Software security engineering

System layers where security may be compromised

Page 11: Software security engineering

System security management

• User and permission managementAdding and removing users from the system and setting up appropriate permissions for users

• Software deployment and maintenanceInstalling application software and middleware and configuring these systems so that vulnerabilities are avoided.

• Attack monitoring, detection and recoveryMonitoring the system for unauthorized access, design strategies for resisting attacks and develop backup and recovery strategies.

Page 12: Software security engineering

Security Risk Management

Page 13: Software security engineering

Security risk management

• Risk management is concerned with assessing the possible losses that might ensue from attacks on the system and balancing these losses against the costs of security procedures that may reduce these losses.

Page 14: Software security engineering

Note:Risk management is a business issue rather than a technical issue, so software engineers should not decide what controls should be included in a system. It is up to senior management to decide whether or not to accept the cost of security or to accept the exposure that results from the lack of security procedures.

Page 15: Software security engineering

Risk management involves

• Preliminary risk assessment• Life cycle risk assessment• Operational risk assessment

Page 16: Software security engineering

Preliminary risk assessment

• In preliminary risk assessment security requirements for the whole system, not just the software.

• At this stage, decisions on the detailed system requirements, the system design or the implementation technology have not been made.

Page 17: Software security engineering

Preliminary risk assessment

Page 18: Software security engineering

Misuse casesMisuse cases are instances of threats to a system.•Interception threats

Attacker gains access to an asset

•Interruption threatsAttacker makes part of a system unavailable

•Modification threatsA system asset are modified

•Fabrication threatsFalse information is added to a system

Page 19: Software security engineering

Asset analysis

Asset Value Exposure

The information system High. Required to support all clinical consultations. Potentially safety-critical.

High. Financial loss as clinics may have to be canceled. Costs of restoring system. Possible patient harm if treatment cannot be prescribed.

The patient database High. Required to support all clinical consultations. Potentially safety-critical.

High. Financial loss as clinics may have to be cancelled. Costs of restoring system. Possible patient harm if treatment cannot be prescribed.

An individual patient record Normally low although may be high for specific high-profile patients.

Low direct losses but possible loss of reputation.

Page 20: Software security engineering

Threat and control analysis

Threat Probability Control Feasibility

Unauthorized user gains access as system manager and makes system unavailable

Low Only allow system management from specific locations that are physically secure.

Low cost of implementation but care must be taken with key distribution and to ensure that keys are available in the event of an emergency.

Unauthorized user gains access as system user and accesses confidential information

High Require all users to authenticate themselves using a biometric mechanism.

Log all changes to patient information to track system usage.

Technically feasible but high-cost solution. Possible user resistance.

Simple and transparent to implement and also supports recovery.

Page 21: Software security engineering

Security requirements• Patient information must be downloaded at the start of a clinic

session to a secure area on the system client that is used by clinical staff.

• Patient information must not be maintained on system clients after a clinic session has finished.

• A log on a separate computer from the database server must be maintained of all changes made to the system database.

Page 22: Software security engineering

Life cycle risk assessment

• Risk assessment while the system is being developed and after it has been deployed

• More information is available - system platform, middleware and the system architecture and data organization.

• Vulnerabilities that arise from design choices may therefore be identified.

Page 23: Software security engineering

Vulnerabilities associated with technology choices

Page 24: Software security engineering

Security requirements• A password checker shall be made available and shall be run daily. Weak

passwords shall be reported to system administrators.

• Access to the system shall only be allowed by approved client computers.

• All client computers shall have a single, approved web browser installed by system administrators.

Page 25: Software security engineering

Operational risk assessment

• Environment characteristics can lead to new system risks

• Risk of interruption means that logged in computers are left unattended.

Page 26: Software security engineering

Design for Security

Page 27: Software security engineering

Design for security• Architectural design

how do architectural design decisions affect the security of a system?

• Good practicewhat is accepted good practice when designing secure systems?

• Design for deploymentwhat support should be designed into a system to avoid the introduction of vulnerabilities when a system is deployed for use?

Page 28: Software security engineering

Architectural design• Two fundamental issues have to be considered when designing an

architecture for security.• Protection

How should the system be organized so that critical assets can be protected against external attack?

• DistributionHow should system assets be distributed so that the effects of a successful attack are minimized?

• These are potentially conflictingIf assets are distributed, then they are more expensive to protect. If

assets are protected, then usability and performance requirements may be compromised.

Page 29: Software security engineering

Protection – defense in depth

Page 30: Software security engineering

Layered protection model• Platform-level protection

Top-level controls on the platform on which a system runs.

• Application-level protectionSpecific protection mechanisms built into the application itself e.g. additional password protection.

• Record-level protectionProtection that is invoked when access to specific information is requested

Page 31: Software security engineering

A layered protection architecture

Page 32: Software security engineering

Distribute assets to reduce losses

Page 33: Software security engineering

Distributed assets

• Distributing assets means that attacks on one system do not necessarily lead to complete loss of system service

• Each platform has separate protection features and may be different from other platforms so that they do not share a common vulnerability

Page 34: Software security engineering

Distributed assets in an equity trading system

Page 35: Software security engineering

Guideline for Security Design

• Base security decisions on an explicit security policy• Avoid a single point of failure• Fail securely• Balance security and usability• Be aware of the possibility of social engineering• Use redundancy and diversity to reduce risk• Validate all inputs• Compartmentalize your assets• Design for deployment• Design for recoverability

Page 36: Software security engineering

System Survivability

Page 37: Software security engineering

System Survivability dependency

System survivability depends upon three factors•Resistance

– avoiding problems by building capabilities into the system to repel attacks.

•Recognition– detecting problems by building capabilities into the system to detect attacks and

failures and assess the resultant damage.

•Recovery– tolerating problems by building capabilities into the system to deliver essential

services whilst under attack and to recover full functionality after an attack.

Page 38: Software security engineering

System Survivability analysisFour stage process:•System Understanding•Critical services identification•Attack simulation•Survivability analysis

Page 39: Software security engineering

System Survivability analysis

Page 40: Software security engineering

Thank you !!!