Princess Sumaya University for Technology

The King Hussein School for Computing

Sciences
13434 Secure Software Development
Topic 1: Introduction to software security

Dr. Ahmad Altamimi

Acknowledgment: Most of these slides have been adopted from Core Software Security by James Ransome and Anmol
Misra book for our course. Additional slides have been added from the mentioned references in the syllabus
Outline
o Introduction to Secure Software Development
o Insecure Design
o Vulnerability, Threat, and Risk
o Software Security
o Quality Versus Secure Code
Introduction to Secure
Software Development
Introduction to Secure Software
Development
o What really causes a majority of the information security problems we have today?
▪ Insecure code and unaware users.

o What is the primary target of hackers, cybercriminals, and nation-state cyber

warriors?
https://threatmap.checkpoint.com/
▪ It is insecure code. https://www.microsoft.com/en-us/msrc/bounty
NVD - Home (nist.gov)
https://chandanbn.github.io/cvss/

o What has quickly become the highest unnecessary cost to software development?
▪ It is flawed, arising from insecure code already released to the market.
▪ Such code must be fixed when discovered that it should have been fixed during the development of
the product.
Cont’d
o Have you ever written software where security mattered?

o How do you know that you have delivered secure software?

▪ Try to think of examples
▪ What are your indicators?
▪ How will you convince others that your software is secure?

o Security is not black-and-white !! It is a process, not a state

▪ Security is until proven “insecure”
▪ Diff of Feeling safer and Being safer
▪ Protection can be costly
Motivation
o In the past, software product stakeholders did not view software security as a high
priority.
o It was believed that a secure network infrastructure would provide the level of
protection needed against malicious attacks.
o In recent history, however, network security alone has proved inadequate against
such attacks.
▪ Users have successfully penetrated valid authentication channels through techniques
such as Cross-Site Scripting (XSS), Structured Query Language (SQL) injection, and
buffer overflow exploitation.
▪ In such cases, system assets were compromised, and both data and organizational
integrity were damaged.
Cont’d
o The security industry has tried to solve software security problems through stopgap
measures.
o First came platform security (OS security), then came network/perimeter security,
and now application security (IP filtering, Lockdown executables, Patch).
o Patches can fix one security problem but open (or re-open) other security issues.
o Companies are not always able to give each patch (fix) the attention it deserves, or
it may not go through the regular software development cycle.
o Resulting in more security problems than the patch/fix is designed to mitigate.
Cont’d
o In SE, we teach you how to build software but not as much breaking software.
o So, we do need defense-in-depth to protect our assets, but fundamentally it is a
software security flaw and needs to be remediated through the Secure Software
Development (SDL) approach.
o Implementation of an SDL ensures that security is inherent in good enterprise
software design and development, not an afterthought included later in production.
o The product not only has to work right (quality), but it also has to be secure
(security). The aim is to build a system that cannot be broken into. Is it possible?
Cont’d
o A single defect in millions of lines of code can
result in a system failure (safety critical systems).
o Typically, more than 35% of project costs are
allocated to software design.
o The elimination of software risk early in the
development cycle, when vulnerabilities are
easier and less expensive to fix.
So, Why Software Security?
o Most software systems today contain numerous flaws and bugs that get exploited
by attackers. See https://cwe.mitre.org/
o New threats emerge every day.
o Exponential increase in vulnerabilities in software systems.
o Software security is everybody's job.
o Programmers have a long history of repeating the same security-related mistakes!
o Organizations will need more people to do the changes in the infrastructure and
to fix other security-related issues (increase the cost of the project).
Insecure Design
Insecure Design
o It is a broad category representing different weaknesses, expressed as “missing or
ineffective control design.”
▪ Those weaknesses that exist due to a lack of security implementation in an application
at the time of development.

o The UK defense Dept. identified Cyber Software Security Design as a TOP priority area. US
Government formed a new branch of the military: the US Cyber Command (May 2010)
o Malware can bring down real-world infrastructure, and present dangers, e.g. Stuxnet
malware was responsible for damaging Iran’s nuclear computer system in 2010
Insecure Design
o A study by the National Institute of Standards and Technology (NIST) – found:
o Software errors cost the U.S. economy an estimated $59.5 billion annually.
o The same study notes that more than one-third of these costs, or some $22.2 billion,
could be eliminated by an improved Design and testing infrastructure that enables
earlier and more effective identification and removal of software defects.
Cont’d
o Software engineers must be trained to be security-conscious.
▪ Security Awareness
▪ Fail to use parameterized SQL queries → SQL injection
▪ Forget to validate all input → Cross-site scripting
▪ Security knowledge
▪ How to implement parameterized SQL queries
▪ How to validate all input
▪ Do real security tasks
▪ Launch SQL Injection attack
▪ Launch Cross-site scripting attack

▪ Embrace the best practice

Vulnerability, Threat, and Risk
Starting Point of Ensuring Security
o Any discussion of security should start with an inventory of
▪ the stakeholders (owners, companies…)
▪ their assets (data, service, customer info…)
▪ the threats to these assets (erase, steal…)
o Attackers
▪ employees, clients, script kiddies, criminals
o Any discussion of security without understanding these issues is meaningless
 TERM EXPLANATION
Threat The possibility that a harmful event, such as an attack, will occur to an asset such as data or
the network itself.

Vulnerability A weakness in a system or its design that could be exploited by a threat.

It is the total sum of the vulnerabilities in a given system that is accessible to an attacker. The
Attack attack surface describes different points where an attacker could get into a system and where
Surface they could get data out of the system.

The mechanism that is used to leverage a vulnerability to compromise an asset. Exploits may
be remote or local. A remote exploit works over the network without prior access to the target
Exploit system. In a local exploit, the threat actor has some type of user or administrative access to
the end system. It does not necessarily mean the attacker has physical access to the end
system.

Risk The likelihood that a particular threat will exploit a particular vulnerability of an asset and
result in an undesirable consequence.

Attacker A person or process that attempts to access data, functions, or other restricted areas of the
system without authorization, potentially with malicious intent. An actor or agent that is a
source of danger, capable of violating confidentiality, availability, or integrity of information
assets
Vulnerability, Threat, and Risk
Exploit, Threat, Vulnerability Protection
o Protect against exploits?
▪ Anti-virus, intrusion detection, firewalls, etc.

o Protect against threats?

▪ Use forensics to find & eliminate
▪ Policy, incentives, deterrents, etc.

o Protect against vulnerabilities?

▪ Engineer secure software!
Vulnerability
o A vulnerability may be a design flaw or poor coding that allows an attacker to
exploit software for a malicious purpose
▪ E.g., allowing easily-guessed passwords (poor coding)
▪ E.g., complete lack of passwords when needed (design flaw)

o Alternative definition: “Vulnerabilities are errors that an attacker can exploit.

Either flaw in the design or flaw in the implementation.”
▪ Design-level vulnerabilities are the hardest defects to handle.
Design VS Implementation Vulnerabilities
o Design vulnerability: a mistake that prevents the program from operating
securely, no matter how perfectly the coders implement it.
▪ Often found in the security features (e.g., lack of passwords).

o Implementation vulnerability: is caused by security bugs in the actual coding of

the software.
▪ Poor coding or Tiny flaws that might lead to catastrophe (e.g., easily-guessed passwords,
not sizing buffers properly).
Common Secure Design Issues
o Poor use of Cryptography
▪ Creating your own cryptography.
▪ Choosing the wrong cryptography.
▪ Hard-coded secret.
▪ Mishandling private information.

o Tracking users and their permissions

▪ Weak or missing session management.
▪ Weak of missing authentication.
▪ Weak of missing authorization.
Common Secure Design Issues
o Flawed Input Validation
▪ Not performing validation in a secure manner
▪ Not centralizing validation routines
▪ Not security component boundary

o Weak Structural Security

▪ Large attack surface
▪ Running process at too high a privilege level
▪ No defense in depth (an approach to cybersecurity in which a series of defensive mechanisms are layered in
order to protect valuable data).
▪ Not failing securely (When the product encounters an error condition or failure, its design requires it to fall
back to a state that is less secure, such as selecting the weakest encryption algorithm ).

o Missing audit logs.

Implementation Issues
o Complied languages: C/C++
▪ Buffer overflow/Stack smashing
o Interpreted languages: Shell scripting and PHP
▪ Command injection using shell scripting
▪ Remote file inclusion in PHP
o Virtual Machine Languages: Java and C#
▪ Sending to the JVM a Java program that is designed so that almost any memory error in its
address space will allow it to take control of the JVM
o Generic application implantation issues
▪ SQL Injection
▪ Cross-Site scripting
Software Security
Software Security Concept
o A creative process involving:
▪ Multiple perspectives (models)
▪ Multiple layers of abstraction
(models)
o An evolutionary process
involving:
▪ Incremental developments
▪ Backtracking over designs
▪ Requirements reformulation,
elaboration, and volatility
Software Security
o NOT an arcane black art
▪ Finding a severe vulnerability source code
▪ Crafting the exploit
▪ However, endless clever ways to break software

o But you have much more knowledge than the attackers do

▪ Fear-mongering will not be tolerated here
o Don’t just leave it to the experts. Take responsibility for knowing the security
Cont’d
o Although tools and experts are helpful,
▪ You can’t just deploy a magical tool and expect all vulnerabilities to disappear
▪ You can’t outsource all of your security knowledge

o Even if you are using a security library, know how to use it properly

o Cryptography is important and needed

o Cannot solve all of your security problems

o Proofs, access control rules, and verification are helpful, but inherently incomplete
Cont’d
o Software security is a reality that everyone must face. Not just developers, all
stakeholders
o A learnable mindset for software engineers
o The ability to prevent unintended functionality
▪ At all layers of the stack
▪ In all parts of your system
Cont’d
Risk management is important, but students would:
o Denial
I don’t have to think about this. Let me just code.
Leave it to the experts.
I could never understand this anyway.

o Irrational fear
Everything is possible now!!!
Every mitigation is necessary!!!
Cont’d
o Bag of Tricks
Let’s just try these tricks that worked in the past
We’ve done these 10 things. That’s a lot. Close enough, right?

o Reasoned, Balanced, Defensive Mindset

If we do X, we mitigate Y, which is worthwhile because of Z.
Quality Versus Secure Code
Quality Versus Secure Code
o Secure code is not necessarily quality code, and quality code is not necessarily
secure code.
▪ Quality is not measured in terms of confidentiality, integrity, and availability, but rather
in terms of ease of use and whether it is reusable and maintainable.
▪ Quality code does not mean secure code: A developer can write efficient code that is
easy to maintain and reusable, but if that code allows an unauthorized user to access
the application’s assets, then the code is of no use.

o You cannot have quality without security or security without quality. These two
attributes complement each other.