chapter -4

Application and OS security

1
 Application Security
 It is the use of software, hardware, and procedural methods to
protect applications from external threats

 is the process of developing, adding, and testing security

features within applications to prevent security vulnerabilities
against threats such as unauthorized access and modification.

2
 Application code attacks
 An application attack consists of cybercriminals gaining access to
unauthorized areas.
 Attackers most commonly start with a look at the application layer,
hunting for application vulnerabilities written within code.
 attacks target certain programming languages than others, and a
wide range of applications representing various languages receive
attacks:
e.g. .NET, Ruby, Java, Node.js, Python, and many more.
 Vulnerabilities are found in both custom code and open-source
frameworks and libraries.

3
 Application code attacks
 Most common application layer attacks
 Buffer Overflow(buffer overrun)
 It occurs when the volume of data exceeds the storage capacity of
the memory buffer.
 the program attempting to write the data to the buffer overwrites
adjacent memory locations
 attackers exploit buffer overflow issues by overwriting the memory
of an application
 It changes the execution path of the program, triggering a response
damages files or exposes private information.

4
 Application code attacks
 Buffer overflow

 Types of Buffer Overflow Attacks

 Stack-based buffer overflows are more common, and leverage
stack memory that only exists during the execution time of a
function.
 Heap-based attacks are harder to carry out and involve flooding the
memory space allocated for a program beyond memory used for
current runtime operations.
 C and C++ are two languages that are highly susceptible to buffer
overflow attacks,
5
 Mac OSX, Windows, and Linux all use code written in C and C++
 Application code attacks
 Prevent Buffer Overflows
 Three common protections are:
 Address space randomization (ASLR)-randomly moves around the address
space locations of data regions.
 buffer overflow attacks need to know the locality of executable code, and
randomizing address spaces makes this virtually impossible.
 Data execution prevention:-flags certain areas of memory as non-executable or
executable, which stops an attack from running code in a non-executable region.
 Structured exception handler overwrite protection (SEHOP)
 helps stop malicious code from attacking Structured Exception Handling (SEH),
a built-in system for managing hardware and software exceptions.
 It prevents an attacker from being able to use the SEH overwrite exploitation
technique.
 an SEH overwrite is achieved using a stack-based buffer overflow to overwrite
6
an exception registration record, stored on a thread’s stack.
 Application code attacks
 Fuzzing attack is an automated process used to find application
vulnerabilities.
 It consists of inserting massive amounts of random data, or fuzz,
into source code and observing the outcomes.
 Fuzzing is an inexpensive and rapid way to detect vulnerabilities
within an application.
 Fuzz testing is a quality assurance technique used to discover
coding errors and security loopholes in software, operating
systems, or networks.
 Fuzzers work best for discovering vulnerabilities that can be
exploited by buffer overflow, DOS (denial of service), cross-site
scripting, and SQL injection.
7
 Application code attacks
 cross-site scripting attacks are used to redirect users to websites
where attackers can steal data from them.
 allow an attacker to masquerade as a victim user, to carry out any
actions that the user is able to perform, and access any of the user's
data.

 Protection
 software developers must validate user input and encode output.

8
 Application code attacks
 SQL injection attacks are used to steal information from databases
 Retrieve any number of items, including sensitive company data, user lists
or private customer details.
 E.g. SELECT ItemName, ItemDescription
FROM Item
WHERE ItemNumber = ItemNumber

9
 Application code attacks
 Hijacking is a type of network attack in which the attacker
takes over the control and communication between the victim
system and the network.
 Any kind of information theft including password, email
information, bank account information, etc.

 Prevention
 Encrypting all data transmitted on a web page.
 Using HTTPS certification on websites. 10
 Types of application security
 Different types of application security features include authentication,
authorization, encryption, logging, and application security testing
 Developers can also code applications to reduce security vulnerabilities
 Authentication: the software developers build procedures into an
application to ensure that only authorized users gain access to it.
 Authentication procedures are accomplished by requiring a user name
and password when logging in to an application.
 Authorization: the system can validate that a user has permission to
access the application by comparing the user’s identity with a list of
authorized users.
 Authentication must happen before authorization so that the application
matches only validated user credentials to the authorized user list.

11
 Types of application security
 Encryption: a mechanism of security measures that can protect
sensitive data from being seen or used by a cybercriminal.
 Keeps safe the traffic containing sensitive data when traveling
between end-user and the cloud, in cloud-based applications
 Logging: can help identify who got access to the data and how.
 Application log files provide a time-stamped record of which
aspects of the application were accessed and by whom
 Application security testing: is the process of making applications
more resistant to security threats, by identifying security
weaknesses and vulnerabilities in source code.

12
 Application security testing:
 There are mainly two types of application security testing
1. Static application Security testing: it scans the application source
files, accurately identifies the root cause and helps remediate the
underlying security flaws.
2. Dynamic application security testing: simulates controlled attacks
on a running web application or service to identify exploitable
vulnerabilities in a running environment

13
 Security in operating system
 It is the process of ensuring OS integrity, confidentiality, and
availability.
 Measures used to protect the OS from threats, viruses, worms,
malware or remote hacker intrusions.
 OS security encompasses all preventive-control techniques, which
safeguard any computer assets capable of being stolen, edited or
deleted
 There are many approaches to OS mechanisms:
 Performing regular OS patch updates
 Installing updated antivirus engines and software
 Inspecting all incoming and outgoing network traffic through a firewall
 Creating secure accounts with required privileges only (i.e., user management)
 Access control and authentication
 One Time passwords 14
 Security in operating system
 Comprehensive security

15
 Security in operating system
 User management:- is the ability of administrators to grant access and
manage user access to resources and control user accounts.
 The resources are systems, devices, applications, storage systems,
networks, SaaS services,
 A user management system forms an integral part of identity and access
management (IAM) and serves as a basic form of security.
 Information Security Policy comprises policies, standards, guidelines, and
procedures pertaining to information security
 Acceptable Encryption and Key Management Policy
 Data Breach Response Policy
 Personnel Security Policy
 Data Backup Policy
 User Identification, Authentication, and Authorization Policy
 Risk Assessment Standards and Procedures
 Secure Systems Management Policy 16
 Security in operating system
 Computer Forensics: is a branch of forensic science that deals with
the application of investigative analysis techniques on computers in
order to retrieve and preserve evidence in a way that is legally
acceptable.
 The science of computer forensics lies in the ability of the forensics
expert to present findings in a way that is acceptable and usable by
a court of law
 The goal of computer forensics is the performance of a structured
investigation on a computing device to find out either what
happened or who was responsible for what happened and
 at the same time maintaining a properly documented chain of
evidence in a formal report
 Legal Issues and Information Security( reading assignment)
17
 Mobile security
 Mobile security is efforts to secure data on mobile devices such as
smartphones and tablets.
 Mobile devices can be attacked by potentially malicious apps,
network-level attacks, and exploitation of vulnerabilities within the
devices and mobile OS.
 Protection
 Keep your software updated.
 Install a firewall.
 Download apps from official app stores.
 Always read the end-user agreement.

18
 Web security
 Problem: Web Attacker sets up malicious site visited by the victim,
no control of network
 Web security: is the separation or control of threats from assets
within or maintained by web-based services to protect the integrity
of service, confidentiality of the communication, and the
availability of the application
 Protection
 Browser policies, session mgmt, user authentication
 HTTPS and
 web application security(protecting data, customers, and
organizations from data theft, interruptions in business
continuity, or other harmful results of cybercrime).eg. WPF
 web application firewalls: protect web applications by filtering 19and
 Network security
 Problem: Network Attacker: Intercepts and controls network
communication
 Protocol designs, vulnerabilities, Malware, DDoS

 Network Security: is the protection of a computer network and its

services from unauthorized modification, destruction, or disclosure.
 Protection
 Security measures built into the network hardware and design
 Control the flow of data in a network
 Use of hardware or software firewalls
 Security measures built into the web service

20
 Data security
 Data security: is the process of protecting data from unauthorized
access and data corruption throughout its lifecycle.
 Problem
 Unauthorized access to data
 Eavesdropping on communications
 Corruption of data
 Denial of service
 Protection
 data encryption, hashing, and key management practices that protect data
across all applications and platforms.

21
 Security problems in software
 Defects are implementation vulnerabilities and design vulnerabilities.
 Bugs are implementation-level errors that can be detected and
removed.
 Example: Buffer overflow.
 Flaws are problems at a deeper level. They are instantiated in the code
and present or absent at design-level.
 Example: Error-handling problems.
 Failures are the inability of the software to perform its required
function.
 Vulnerabilities are errors that an attacker can exploit.
 Either flaw in the design or flaws in the implementation.
 Design-level vulnerabilities are the hardest defects to handle.
22
 Security problems in software ..
 Risks: capture the probability that a flaw or a bug will impact the
purpose of the software.
 Risk = probability x impact
 Malicious software(malware) is software written with the intent to
damage, exploit, or disable devices, systems, and networks.
 It is used to compromise device functions, steal data, bypass access
controls, and cause harm to computers and other devices and
networks they are connected to.
 The six most common types of malware are viruses, worms, Trojan
Horses, spyware, adware, and ransomware
 Viruses: are designed to damage target computer or device by
corrupting data, reformatting hard disk, or completely shutting
down your system. 23
 Security problems in software ..
 Worms: spread over computer networks by exploiting operating
system vulnerabilities.
 It is a standalone program that replicates itself to infect other
computers, without requiring action from anyone
 Trojan Horses: enters in to the system masked as a normal, harmless
file or program designed to trick, downloading, and install malware
 With help of trojan horse, a cybercriminal can steal data, install
more malware, modify files, monitor user activity, destroy data,
steal financial information, conduct (DoS) attacks on targeted web
addresses

24
 Security problems in software ..
 Spyware: is designed to track browsing habits and internet activity.
 Spying includes activity monitoring, collecting keystrokes, and harvesting
account information, logins, and financial data
 It can spread by exploiting software vulnerabilities, bundling with
legitimate software
 Adware: being an advertising software that puts unwanted advertising on a
computer screen.
 Malicious adware can collect data, redirect to advertising sites, and change
internet browser settings
 Ransomware: is a type of malware that holds data captive and demands
payment to release the data back.
 It restricts user access to the computer by either encrypting files on the
hard drive or locking down the system and displaying messages that are
intended to force the user to pay the attacker to release the restrictions25and
 security risk assessment
 It identifies, assesses, and implements key security controls in
applications.
 It focuses on preventing application security defects and
vulnerabilities
 It supports administrators in making informed resource allocation,
tooling, and security control implementation decisions.
 conducting an assessment is an integral part of an organization’s
risk management process.
 The steps involve
 Identification
 Assessment
 Mitigation.
 Prevention 26
 Pillars of Software Security
 The three pillars of software security

Software security

Risk knowledge
m a na ge m e nt Touchpoints

27
 Pillars of Software security
 Risk management
 It is the process of identifying, assessing, and controlling threats to
an organization's capital and earnings.
 A continuous risk management process is an essential part to
software security.
 It identifies, ranks, tracks, and understands software security risks
as it changes over time
 Risk management framework (RMF)
 An overall approach to risk management.
 Allows a consistent and continuous expertise-driven approach to
risk management.
 The goal is to consistently track and handle risks. 28
Risk management framework (RMF) activities

29
 Risk management framework (RMF) activities
 Understand the business context.
 A key task of an analyst.
 Extract and describe business goals.
 Set priorities.
 Understanding what risks to consider.
 Conducting project research to the scope.
 Identify the business and technical risks, synthesize, prioritize, and rank
the risks.
 Business risks impact business goals.
 Mapping technical risks to business goals.
 Developing a set of risk questionnaires.
 Interviewing the target project team.
30
 Evaluating software artifacts
 Risk management framework (RMF) activities
 Synthesize, prioritize, and rank the risks.
 Prioritize the risks based on the business goals.
 Risk metrics:
 risk likelihood, risk impact, risk severity
 and number of risks emerging and mitigated over time
 Define the risk mitigation strategy.
Create a coherent strategy for mitigating the risks that take into account:
 Cost.
 Implementation time.
 Likelihood of success.
 Competence.
 Impact.
 Identify the validation techniques . 31
 Risk management framework (RMF) activities
 Carry out fixes and validate that they are correct.
 Implement the mitigation strategy.
 The artifacts should be rectified.
 Progress is measured in terms of completeness against
mitigation strategy.
 Use validation techniques to validate that artifacts no
longer bear unacceptable risk.
 Metrics include artifact quality metrics and levels of
risk mitigation effectiveness

32
 Touchpoints
 Security touchpoints are system-wide activity: from
design to testing and feedback

33
 1- Code Review (Tools)
 methodical assessments of code designed to identify bugs, increase
code quality, and help developers learn the source code.
 Focused on finding and fixing bugs
 Use static analysis tools to find, and fix security bugs,
vulnerabilities, and security risks in the application without
running.
 Code review can capture only half of the problems
 Taxonomy of coding errors
 Input validation and representation
 Metacharacters, alternate encodings, numeric representations
 Forgetting input validation
 Trusting input too much
e.g. buffer overflow 34
 Touchpoints
 Code Review (Tools): …
 Taxonomy of coding errors…
 API abuse
 API represents a contract between caller and callee
 E.g., failure to enforce the principle of least privilege
 Error handling
 Security defects related to error handling are very common
 Forget to handle errors or handle them roughly
E.g., unchecked error value; empty catch block
 Code quality
 Poor code quality leads to unpredictable behavior
35
 2. Architectural Risk Analysis:
 finding design and specifications flaws
 Design flaws
 Account for 50% of security problems.
 Can't be detected by staring at code.
 A higher-level understanding is required
 Architectural Risk Analysis:
 Tracks risk over time.
 Links system-level concerns to probability and impact measures.
 Fits with RMF
 Critical Aspects of Architectural Risk Analysis:
 Attack Resistance Analysis.
 Ambiguity Analysis and Weakness Analysis
36
 2.Architectural Risk Analysis:
 Attack Resistance Analysis:
 It captures the check-list like approach to the risk analysis taken in
the Microsoft STRIDE(Spoofing, Tampering, Repudiation,
Information Disclosure, Denial of Service, and Elevation of
Privilege) approach.
 Steps:
 Identify general flaws using secure design literature and checklists.
 Map attack patterns using either the results of abuse case
development or a list of historical risks.
 Identify risks in the architecture based on the use of checklists.
 Understand and demonstrate the viability of these known attacks.

37
 2. Architectural Risk Analysis:
 Ambiguity Analysis:
It captures the creative activity required to discover new risks.
It requires at least two analysts and experience.
 Weakness Analysis:
 Is aimed at understanding the impact of software dependencies.
 Software is built on top of complex middleware frameworks.
 Understand what kind of assumptions we make about outside
software.
 What happens when assumptions fail?

38
 3. Software Penetration Testing
 A method of evaluating software security by simulating an attack
in an outside-in manner.
 use the same tools, techniques, and processes as attackers to find
and demonstrate the business impacts of weaknesses in a system
 advantage
 Find weaknesses in systems
 Determine the robustness of controls
 Support compliance with data privacy and security regulations
 Provide qualitative and quantitative examples of current
security posture and budget priorities for management
 Use static and dynamic penetration testing tools.

39
 3. Software Penetration Testing
 Penetration Testing:...
 Penetration testing stages
 The pen testing process can be broken down into five stages

40
 4. Risk-Based Security Testing
 It is based on the probability of risk.
 Testers must follow:
 Risk-based approach:
 Grounded in both system's architectural reality and the
attacker's mindset, to measure software security adequately.
 Focused on areas of code where an attack is likely to succeed.
 Different from Penetration Testing:
 Level of approach: Inside-out approach.
 Timing of testing: Before the software is complete.
 It is applied before the software is complete, at the unit level, in a
testing environment with stubs and pre-integration
 Risk analysts should identify and rank risks
41
 4. Risk-Based Security Testing
 Security Testing must involve two approaches:
 Functional security testing:
 Testing mechanisms that ensure that functionality is well
implemented.
 Adversarial security testing:
 Risk-based security testing motivated by understanding the
attacker's approach.

42
 5. Abuse Cases:
 Software types don't normally describe non-normative behavior in
use cases, nor do they describe it with UML
 Determining what the software can't and won't do
 Example: users can't enter more than 50 characters.
 Don't accept the idea that says "No one would do these things".
 What happens when functional security mechanisms are
compromised?

43
 5. Abuse Cases:
 Generating abuse cases:
 Creating Anti-Requirements:
 Provide insights into how attackers will approach system’s assumptions.
 Applied throughout the lifecycle.
 Generated by security analysts.
 Creating an attack model:
 Explicit consideration of well-known attacks.
 Select attack patterns relevant to the system.
 Build abuse cases around attack patterns.
 Include anyone who can gain access to the system.

44
6. Security Requirements
 Cover both functional security and emergent
characteristics.
 Satisfy three criteria:
 Definition: Must be explicitly defined what security
requirements are.
 Assumption: Must take into account the assumptions that
the system will behave as expected.
 Satisfaction: Security requirements must satisfy the
security goals, and the system must satisfy the security
requirements.

45
7. Security Operations
 Software security operations can be integrated with
network security operations.
 Defensive technique:
 Understanding software behavior that leads into successful
attack.
 Knowledge gained by understanding attacks should be
cycled back into software development.

46
 Knowledge
 Involves
 Gathering, encapsulating, and sharing security knowledge
 Software security knowledge catalogs
Principles
Guidelines
Rules Can be put into three categories
Vulnerabilities
Prescriptive knowledge
Exploits
Diagnostic knowledge
Attack patterns
Historical knowledge
Historical risks

47
 Knowledge
 Mapping of software security knowledge catalogs to various
software artifacts and software security best practices.

48
End of course

49