Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Security ITGD 2202 Supervision:- Assistant Professor

Similar presentations


Presentation on theme: "Software Security ITGD 2202 Supervision:- Assistant Professor"— Presentation transcript:

1 Software Security ITGD 2202 Supervision:- Assistant Professor
Dr. Sana’a Wafa Al-Sayegh Student: Anwaar Ahmed Abu-AlQumboz

2 The Objective of "Software Security":
Contents Definition The Objective of "Software Security": The Qualities of "Secure Software": Security in the Software Lifecycle:- Deploying Software Security Practices Software Security Practices:- Summary Reference

3 Definition A Software : The programs, routines, and symbolic languages that control the functioning of the hardware and direct its operation. Software security is the idea of engineering software so that it continues to function correctly under malicious attack.

4 The Objective of "Software Security":
The objective of software security is to design, implement, configure, and support software systems in ways that enable them to: continue operating correctly in the presence of most attacks by either resisting the exploitation of faults or other weaknesses in the software by the attackers or tolerating the errors and failure that result from such exploits . isolate, contain, and limit the damage resulting from any failures caused by attack-triggered faults that the software was unable to resist or tolerate and recover as quickly as possible from those failures .

5 The Qualities of "Secure Software":
The vulnerabilities in executing software originate in the process used to create that software: the decisions made by its developers, the flaws they inadvertently or intentionally include in its specification and design, and the faults and other defects they inadvertently or intentionally include in its implemented code. ـــIn addition to trustworthiness, predictable execution, and conformance, secure software must be attack-resistant or attack-tolerant, and at the whole system level it must be attack-resilient. To achieve attack-resistance or attack-tolerance, both software components and whole software systems should be able to recognize attack patterns in the input data or signals they receive from external entities (humans or processes). They should be able to either resist attack-patterned input or tolerate the failures that result from a successful attack or intentional external fault. To achieve attack-resilience (often referred to as survivability), software systems must be able to recover from any failures that result from successful attacks on the software by resuming operation at or above some predefined minimum acceptable level of service in the short term. The system must eventually recover full service at the specified level of performance.

6 Security in the Software Lifecycle:-
Protection against intentional subversion or forced failure. Preservation of the three subordinate properties that make up security—availability, integrity, and confidentiality. Security manifests as the ability of the system to protect itself from external faults that may be accidental or deliberate (attacks). According to Bruce Schneier in Beyond Fear “Security is about preventing adverse consequences from the intentional and unwarranted actions of others.”

7 Deploying Software Security Practices
The main goals of deploying software security practices include the following: Exploitable faults and other weaknesses are avoided by well-intentioned developers. The likelihood is greatly reduced or eliminated that malicious developers can intentionally implant exploitable faults and weaknesses or malicious logic into the software. The software is attack-resistant, attack-tolerant, and attack- resilient.

8 Software Security Practices:-

9 Architectural risk analysis.
Software Security Practices:- Code reviews Architectural risk analysis. Penetration testing Security testing. Abuse cases Security operations.

10 Software Security Practices:-
Code Reviews:- -Fix implementation bugs, not design flaws. -Benefits of code reviews: Find defects sooner in the lifecycle Find defects with less effort than testing Find different defects than testing Educate developers about security flaws. Static Analysis Tools:- Automated assistance for code reviews -Speed: review code faster than humans can -Accuracy: 100s of secure coding rules False Positive:- -Tool reports bugs in code that aren’t there. -Complex control or data flow can confuse tools. False Negatives:- -Tool fails to discover bugs that are there. -Code complexity or lack of rules to check.

11 Software Security Practices:-
Architectural Risk Analysis:- ــFix design flaws, not implementation bugs. Risk analysis steps:- 1)-Develop an architecture model. 2)-Identify threats and possible vulnerabilities. 3)-Develop attack scenarios. 4)-Rank risks based on probability and impact. 5)-Develop mitigation strategy. 6)-Report findings. Risk Analysis:- -Attack Analysis: Historical attacks and vulnerabilities. Attack patterns:- -Command Delimiters -Multiple Parsers and Double Escapes Attack trees. -Ambiguity Analysis Compare understandings of architects. -External Weakness Analysis

12 Software Security Practices:-
Penetration Testing:- -Test software in deployed environment. -Allocate time at end of development to test: Often time-boxed: test for n days Schedule slips often reduce testing time Fixing flaws is expensive late in lifecycle. -Penetration Testing Tools: Test common vulnerability types against inputs Fuzzing: send random data to inputs Don’t understand application structure or purpose. -WebScarab -Paros Proxy -Burp Suite -Vulnerability Scanners -Nikto -Nessus

13 Software Security Practices:-
Security Testing:- Two types of testing:- -Functional: verify security mechanisms. -Adversarial: verify resistance to attacks generated during risk analysis. Different from traditional penetration testing:- -White box. -Use risk analysis to build tests. -Measure security against risk model.

14 Software Security Practices:-
Abuse Cases:- -Anti-requirements Think explicitly about what software should not do. -A use case from an adversary’s point of view Obtain Another User’s CC Data Alter Item Price Deny Service to Application. -Developing abuse cases Informed brainstorming: attack patterns, risks. Security Operations:- -User security notes:- -Software should be secure by default. -Enabling certain features/configs may have risks. -User needs to be informed of security risks. -Incident response -What happens when a vulnerability is reported? -How do you communicate with users? -How do you send updates to users?

15 Summary The information needs to be secure because of what it is and how it is acted upon by other entities. Software needs to be secure because of what it does, including how it acts upon other entities. The main objective of information security and the systems that store and transmit information is to protect information from unauthorized disclosure, modification, or deletion. The main objective of software security is to produce software that will not be vulnerable to unauthorized modification or denial of service during its execution.

16 Reference https://buildsecurityin.us-cert.gov/daisy/bsi/547-BSI.html

17 Thank a lot For You IT..Student.. Anwaar Abu-AlQumboz


Download ppt "Software Security ITGD 2202 Supervision:- Assistant Professor"

Similar presentations


Ads by Google