Software security engineering
- 2. What we will learn today • Security concepts • Security risk management • Design for security • System survivability
- 3. 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.
- 4. 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.
- 6. Security Concepts • Assets • Exposure • Vulnerability • Attack • Threats • Control
- 7. 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
- 8. 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.
- 9. 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.
- 10. System layers where security may be compromised
- 11. System security management • User and permission management Adding and removing users from the system and setting up appropriate permissions for users • Software deployment and maintenance Installing application software and middleware and configuring these systems so that vulnerabilities are avoided. • Attack monitoring, detection and recovery Monitoring the system for unauthorized access, design strategies for resisting attacks and develop backup and recovery strategies.
- 13. 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.
- 14. 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.
- 15. Risk management involves • Preliminary risk assessment • Life cycle risk assessment • Operational risk assessment
- 16. 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.
- 18. Misuse cases Misuse cases are instances of threats to a system. •Interception threats Attacker gains access to an asset •Interruption threats Attacker makes part of a system unavailable •Modification threats A system asset are modified •Fabrication threats False information is added to a system
- 19. 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.
- 20. 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.
- 21. 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.
- 22. 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.
- 23. Vulnerabilities associated with technology choices
- 24. 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.
- 25. Operational risk assessment • Environment characteristics can lead to new system risks • Risk of interruption means that logged in computers are left unattended.
- 27. Design for security • Architectural design how do architectural design decisions affect the security of a system? • Good practice what is accepted good practice when designing secure systems? • Design for deployment what support should be designed into a system to avoid the introduction of vulnerabilities when a system is deployed for use?
- 28. 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? • Distribution How should system assets be distributed so that the effects of a successful attack are minimized? • These are potentially conflicting If assets are distributed, then they are more expensive to protect. If assets are protected, then usability and performance requirements may be compromised.
- 29. Protection – defense in depth
- 30. Layered protection model • Platform-level protection Top-level controls on the platform on which a system runs. • Application-level protection Specific protection mechanisms built into the application itself e.g. additional password protection. • Record-level protection Protection that is invoked when access to specific information is requested
- 32. Distribute assets to reduce losses
- 33. 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
- 34. Distributed assets in an equity trading system
- 35. 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
- 37. 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.
- 38. System Survivability analysis Four stage process: •System Understanding •Critical services identification •Attack simulation •Survivability analysis
- 40. Thank you !!!