Software Security

By
Dr.S.Jagadeesan
Assistant Professor (Senior Grade 2)
Department of Software Systems and
Application
School of Information Technology and
VIT Vellore 1

Engineering ,
Module 1 - Security issues in Software

• Introduction, The problem, Software assurance and software

security, Threats to software security, Sources of software
insecurity, Benefits of detecting software security defects early,
Managing secure software development, Properties of secure
software.

2
Software Security

• Software security is the practice of building software to be secure

and to function properly under malicious attack.
• Software security is an idea implemented to protect software
against attacks and other hacker risks so that the software
continues to function correctly under such potential risks.
• Security is necessary to provide integrity, authentication and
availability.

3
Software Security

• It is about
• Understanding software-induced security risks and how to manage them
• Leveraging software engineering practice,
• thinking security early in the software lifecycle
• Knowing and understanding common problems
• Designing for security
• Subjecting all software artifacts to thorough objective risk analyses and
testing
• It is a knowledge intensive field

4
Security Issues
• Building, deploying, operating
and using software that has not
been developed with security
in mind can be high risk – like
walking a high wire without a
net.
• The degree of risk can be
compared to the distance you
can fall and the potential
impact.

5
Software and Security

• Software Security = Risk Management

• Security is about regulating access to assets
• E.g., information or functionality
• Software provides functionality
• E.g., on-line exam results
• This functionality comes with
certain risks
• E.g., what are risks of on-line
exam results?
• Privacy (score leakage);
Modification
6
• Software security is about
managing these risks
Software Security

• Security is always a secondary concern

• Primary goal of software is to provide functionalities or services
• Managing associated risks is a derived/secondary concern
• There is often a trade-off/conflict between
• security
• functionality & convenience
• Security achievement is hard to evaluate when nothing bad
happens

7
Software Security

8
Software Security

• Security is about imposing countermeasures to reduce risks to

assets to acceptable levels
• “Perfect security” is not necessary and costly
• A security policy is a specification of what security
requirements/goals the countermeasures are intended to achieve
• secure against what and from whom ?
• Security mechanisms to enforce the policy
• What actions we should take under an attack?

9
Changing target of attacks

• Traditionally, focus on operating system and network “Solutions”

• regular patching of OS, firewalls, virus scanners
• Then focus shifted to
• web applications
• web browser
• mobile devices
• smartphones, tablets, that bypass firewalls
• embedded software • in cars, IoT devices, factories, critical
infrastructures...

10
Security Bugs and Failures
• A Security bug is also called as
vulnerability
• When a vulnerability get triggered
(exploited), it may generate a
security failure (against the security
policy) and compromise the
system.
• Security analysis is the process to
determine the security posture of a
system.
 It answers the question: Is the system
vulnerable with respect to the known
vulnerabilities?
11
Software Security
• The well-known trio
• Confidentiality, integrity, availability (CIA)
• There are more “concrete” goals
• traceability and auditing (forensics)
• monitoring (real-time auditing)
• multi-level security
• privacy & anonymity
• ...
• and meta-property
• assurance – that the goals are met
• “information assurance”

12
Starting Point for Ensuring Security

• 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…)
• Attackers
• employees, clients, script kiddies, criminals
• Any discussion of security without understanding these issues is
meaningless

13
Software Security

• Security is about imposing countermeasures to reduce risks to

assets to acceptable levels
• “Perfect security” is not necessary and costly
• A security policy is a specification of what security
requirements/goals the countermeasures are intended to achieve
• secure against what and from whom ?
• Security mechanisms to enforce the policy
• What actions we should take under an attack?

14
Security Objectives - CIA

• Confidentiality (or secrecy)

• unauthorized users cannot read information
• Integrity
• unauthorized users cannot alter information
• Availability
• authorized users can always access information

15
Security Objectives - CIA

Dr. M. LAWANYA SHRI, 16

SITE
Security - Authentication

Identity Verification
• Ex : How can Bob be sure that he is communicating with Alice?
• Three General Ways:
• Something you know (i.e., Passwords)
• Something you have (i.e., Tokens)
• Something you are (i.e., Biometrics)

17
Security - Authentication

SOMETHING YOU KNOW

Example: Passwords
• Pros:
• Simple to implement
• Simple for users to understand
• Cons:
• Easy to crack (unless users choose strong ones)
• Passwords are reused many times
• One-time Passwords (OTP): different password used each time, but it is
difficult for user to remember all of them
18
Security - Authentication
SOMETHING YOU HAVE

• OTP Cards (e.g. SecurID): generates new password each time user
logs in
• Smart Card: tamper-resistant, stores secret information, entered
into a card-reader
• Token / Key (i.e., iButton)

Example : ATM Card

Strength of authentication depends on difficulty of forging
19
Security - Authentication
SOMETHING YOU ARE:
• Biometric security devices measure unique characteristics of a
person, such as voice pattern, the iris or retina pattern of the eye, or
fingerprint patterns.
• With biometrics, it can be extremely difficult for someone to break
into a system.

20
Security - Authorization

• Checking whether a user has permission to conduct some action

• Identity vs. Authority
EXAMPLE :
Is a “subject” (Alice) allowed to access an “object” (open a file)?
• Access Control List: mechanism used by many operating systems
to determine whether users are authorized to conduct different
actions

21
Security – Access Control List

• Set of three-tuples <User, Resource, Privilege>

• Specifies which users are allowed to access which resources with
which privileges
• Privileges can be assigned based on roles (e.g. admin)

22
Security – Access Control List

ACLs used to implement these models

• Mandatory: computer system decides exactly who has access to
which resources
• Discretionary (e.g. UNIX): users are authorized to determine
which other users can access files or other resources that they
create, use, or own
• Role-Based (Non-Discretionary): user’s access & privileges
determined by role

23
Security - Confidentiality

• Goal: Keep the contents of communication or data on storage

secret
• Example: Alice and Bob want their communications to be secret
from Eve
• Key – a secret shared between Alice & Bob
• Sometimes accomplished with :
• Cryptography, Steganography, Access Controls, Database Views

24
Security – Data/ Message Integrity
• Data Integrity = No Corruption
• Man in the middle attack: Has Mallory tampered with the
message that Alice sends to Bob?
• Integrity Check: Add redundancy to data/messages
• integrity checking is generally considered one of the strongest
anti-malware controls, since it has the potential to detect and
locate all persistent malware intrusions along with any
additional persistent changes to the system that malware could
have made
• Techniques:
• Hashing (MD5, SHA-1, …), Checksums (CRC…)
• Message Authentication Codes (MACs)
Security - Availability

• It is important to ensure that the information concerned is readily

accessible to the authorized viewer at all times.
• Some types of security attack attempts to deny access to the
appropriate user, either for the sake of inconveniencing them, or
because there is some secondary effect.
• For example, by breaking the web site for a particular search
engine, a rival may become more popular.

26
Security – Non Repudiation
• Un-deniability of a transaction
• Nonrepudiation is the that someone cannot deny
assurance something.
• nonrepudiation refers to the ability to ensure that a party to a
contract or a communication cannot deny the authenticity of their
signature on a document or the sending of a message that they
originated.
• Alice wants to prove to Trent that she did communicate with Bob
• Generate evidence / receipts (digitally signed statements)
• Often not implemented in practice, credit-card companies become
de facto third-party verifiers
27
CIAAN

• A simple & long-time applicable security model is the CIA triad; standing
for Confidentiality, Integrity and Availability; three key principles
which are guaranteed in any kind of secure system.

• As security continued to improve however, it has been clear that

Authenticity and Non-Repudiation are also essential parts of a secure
system.

28
How to Realize Security Objectives? AAAA

• Authentication
• who are you?

• Access control/Authorization
• control who is allowed to do
what
• this requires a specification of
who is allowed to do what

• Auditing 29

• check if anything went wrong

How to Realize Security Objectives? AAAA
• Other names for the last three A's
• Prevention
• measures to stop breaches of security goals
• Detection
• measures to detect breaches of security goals
• Reaction
• measures to recover assets, repair damage, and persecute
(and deter) offenders

• Good prevention does not make detection & reaction

superfluous
• E.g., breaking into any house with windows is trivial; despite this absence
of prevention, detection & reaction still deter burglars. 30
Countermeasures

• Countermeasures can be non-IT related

• physical security of building
• screening of personnel
• legal framework to deter criminals
• training employee

• but we won’t consider these (although they are also very

important)

31
Countermeasures and More Vulnerabilities
• Countermeasures can lead to new vulnerabilities
• E.g., if we only allow three incorrect logins, as a
countermeasure to brute-force attacks (account be frozen),
which new vulnerability do we introduce?
• Denial of Service attack
• If a countermeasure relies on new software, bugs in this new
software may mean
• that it is ineffective, or
• worse still, that it introduces more weaknesses
• E.g., Witty worm appeared in Mar 2004 exploited ISS
security software
32
Countermeasures and More Vulnerabilities

 Threats exploit Vulnerabilities and damage Assets.

 Countermeasures mitigate Vulnerabilities and therefore might mitigate Threats.
33
Understanding Risk Drivers:
 Threats and Countermeasures

34
 Countermeasures and More Vulnerabilities
• Knowledge about threats & vulnerabilities crucial
• my first dynamic webpage, with a cgi-bin script, was hopelessly insecure

• Vulnerabilities can be specific to programming language, operating

system, database,... being used, and are continuously evolving, so
we cannot hope to cover all vulnerabilities.

• “Fortunately”, people keep making the same mistakes and some old
favorites never seem to die,
• – esp. public enemy number 1: the buffer overflow 35
Typical Software security vulnerabilities

36
Software Assurance and Software Security
• The ability to trust that software will remain dependable under all
circumstances, with a justified level of confidence, is the objective
of software assurance.
• Software assurance has become critical because dramatic
increases in business and mission risks are now known to be
attributable to exploitable software.

37
Software Assurance and Software Security
• Software is the weakest link in the successful execution of
interdependent systems and software applications.
• Software size and complexity obscure intent and preclude
exhaustive testing.
• Outsourcing and the use of unvetted software supply-chain
components increase risk exposure.
• The sophistication and increasingly more stealthy nature of
attacks facilitates exploitation.
• Reuse of legacy software with other applications introduces
unintended consequences, increasing the number of vulnerable
targets.
• Business leaders are unwilling to make risk-appropriate
investments in software security
38
Software Assurance and Software Security
The objective of software security is to field software-based systems
that satisfy the following criteria:

• The system is as vulnerability and defect free as possible.

• The system limits the damage resulting from any failures caused
by attack-triggered faults, ensuring that the effects of any attack
are not propagated, and it recovers as quickly as possible from
those failures.
• The system continues operating correctly in the presence of most
attacks by either resisting the exploitation of weaknesses in the
software by the attacker or tolerating the failures that result from
such exploits.
39
Software Assurance and Software Security
Software that has been developed with security in mind generally
reflects the following properties throughout its development life cycle:
• Predictable execution. There is justifiable confidence that the
software, when executed, functions as intended. The ability of
malicious input to alter the execution or outcome in a way favorable
to the attacker is significantly reduced or eliminated.
• Trustworthiness. The number of exploitable vulnerabilities is
intentionally minimized to the greatest extent possible. The goal is
no exploitable vulnerabilities.
• Conformance. Planned, systematic, and multidisciplinary activities
ensure that software components, products, and systems conform to
requirements and applicable standards and procedures for specified
uses
40
Threats to Software Security
• In information security, the threat—the source of danger—is
often a person intending to do harm, using one or more malicious
software agents. Software is subject to two general categories of
threats:
 Threats during development (mainly insider threats).
 Threats during operation (both insider and external threats).

41
Threats during development (insider)
• The term “insider threats” often refers to individuals who use their
knowledge of or access to an organization and its systems to
deliberately perpetrate wrongdoing, whether fraud, sabotage, theft,
or a violent act.
• These individuals may be current or former employees,
contractors, or employees of third-party service providers.
• A software engineer can sabotage the software at any point in its
development life cycle.
• The secure development practices, designed to help reduce the
exposure of software to insider threats during its development
process.
42
The 3 Most Common Insider Threats

43
Threats during Operation (insider/external)
• Any software system that runs on a network-connected platform
is likely to have its vulnerabilities exposed to attackers during its
operation.
• Attacks may take advantage of publicly known but unpatched
vulnerabilities, leading to memory corruption, execution of
arbitrary exploit scripts, remote code execution, and buffer
overflows.
• Software flaws can be exploited to install spyware, adware, and
other malware on users' systems that can lie dormant until it is
triggered to execute.

44
External threats
• External threats are anything from your organization's outside
environment that can adversely affect its performance or achievement
of its goals.
• Ironically, stronger organizations can be exposed to a greater level of
threats than weaker organizations because success breeds envy and
competition to take what your organization has achieved.

45
Insider vs external threats

46
Threats during Operation
This approach has two critical shortcomings:
• The security of the application depends completely on the
robustness of operational protections that surround it.
• Many of the software-based protection mechanisms (controls)
can easily be misconfigured or misapplied. Also, they are as likely
to contain exploitable vulnerabilities as the application software
they are (supposedly) protecting.

47
Sources of Software Insecurity
• Software—especially networked, application-level software—is
most often compromised by exploiting weaknesses that result from
the following sources:
• Complexities, inadequacies, and/or changes in the software's
processing model (e.g., a Web- or service-oriented architecture
model).
• Incorrect assumptions by the engineer, including assumptions about
the capabilities, outputs, and behavioral states of the software's
execution environment or about expected inputs from external
entities (users, software processes).

48
 Sources of Software Insecurity – contd.,
• Flawed specification or design, or defective implementation of
• The software's interfaces with external entities. Development mistakes of this
type include inadequate (or nonexistent) input validation, error handling, and
exception handling.
• The components of the software's execution environment (from
middleware-level and operating-

49
 Principles of Defect prevention

• The integral part of the defect prevention process begins with requirement analysis
– translating the customer requirements into product specifications without
introducing additional errors.

• Software architecture is designed, code review and testing are done to find out the
defects, followed by defect logging and documentation.

• One aspect of quality assurance that is particularly relevant during rapid

development is the presence of error-prone modules—that is, modules that are
responsible for a disproportionate number of defects.
50

• If an organization can prevent defects or detect and remove them early, it can
realize significant cost and schedule benefits.
Defect prevention cycle

51
Managing Secure Software Development
Secure software development is mandatory for software that is
developed for the following uses:
• In a business environment
• To process personally identifiable information (PII) or other sensitive
information
• To communicate regularly over the Internet or other networks

Secure software development process model at Microsoft

52
Managing Secure Software Development
What Products and Services Are Required to Adopt the
SDL(SECURITY DEVELOPMENT LIFECYCLE) Process?
• Any software release that is commonly used or deployed
within any organization, such as a business organization or a
government or nonprofit agency.
• Any software release that is commonly used or deployed within
any organization, such as a business organization or a
government or nonprofit agency.
• Any software product or service that targets or is attractive to
children 13 years old and younger.
• Any software release that regularly connects to the Internet or
other networks. 53
Managing Secure Software Development
What Products and Services Are Required to Adopt the SDL
Process?
• Any software release that automatically downloads updates.
• Any software release that accepts or processes data from an
unauthenticated source, including:
• Callable interfaces that “listen”.
• Functionality that parses any unprotected file types should be limited to
system administrators.
• Any release that contains ActiveX controls.
• Any release that contains COM controls.

54
Secure Software Development Lifecycle

Secure software development process model at Microsoft

55
Secure Software Development Lifecycle

Software development life cycle with defined security touchpoints

56
Software Security Touchpoints

57
 Managing Secure Software Development
Software security practitioners perform many different tasks to manage
software security risks, including
• creating security abuse/misuse cases;
• listing normative security requirements;
• performing architectural risk analysis;
• building risk-based security test plans;
• wielding static analysis tools;
• performing security tests;
• performing penetration testing in the final environment; and
• cleaning up after security breaches.
58
Thank you

59