Student Id: Student Name:

Academic year: 2022-23

Sem-In Examinations-I,
B. Tech. (CSE), 2020 Batch
III/IV, 2nd Semester (Set-I)
Subject Code: 17CS3281-Secure Software Engineering
REVISION QUESTIONS AND ANSWER

Max. Marks: 50
Part-A (4X 3M=12M)
Answer ALL Questions
Q. No. 1, 2 from CO1 Preferred to be at lower BTL than the Max BTL of CO1, No sub questions
Q. No 3, 4 from CO2 Preferred to be at lower BTL than the Max BTL of CO2, No sub questions
1. List the assumptions that are to be reconsidered by project managers for software security.
ANS:
1. Instead of centralized control, which was the norm for large standalone systems, project
managers have to consider multiple and often independent control points for systems
and systems of systems.
2. Increased integration among systems has reduced the capability to make wide-scale
changes quickly. In addition, for independently managed systems, upgrades are not
necessarily synchronized. Project managers need to maintain operational capabilities
with appropriate security as services are upgraded and new services are added.
3. With the integration among independently developed and operated systems, project
managers have to contend with a heterogeneous collection of components, multiple
implementations of common interfaces, and inconsistencies among security policies.
4. With the mismatches and errors introduced by independently developed and managed
systems, failure in some form is more likely to be the norm than the exception and so
further complicates meeting security requirements
2. Enumerate on the influential properties of secure software.
ANS:
Some properties of software, although they do not directly make software secure, nevertheless
make it possible to characterize how secure software is :
1. Dependability
2. Correctness
3. Predictability
4. Reliability
3. Describe about the SQUARE process model.
ANS:
• Security Quality Requirements Engineering (SQUARE) is a process model that was
developed at Carnegie Mellon University.
• It provides a means for eliciting, categorizing, and prioritizing security requirements
for information technology systems and applications.
• The focus of the model is to build security concepts into the early stages of the SDLC.
Steps:
Agree on definitions
Identify security goals
Develop artifacts to support security requirements definition
Perform (security) risk assessment
Select elicitation techniques
Elicit security requirements
Categorize requirements as to level
Prioritize requirements
Inspect requirements

4. Tabulate any four sets of potential threat sources developed by NIST.

ANS:
Threat Source Motivation Threat Actions
Cracker Challenge Ego Rebellion System profiling Social
engineering System
intrusion, break-ins
Unauthorized system access
Computer criminal Destruction of information Computer crime (e.g.,
Illegal information disclosure cyberstalking) Fraudulent act
Monetary gain Unauthorized (e.g., replay, impersonation,
data alteration interception) Information
bribery Spoofing System
intrusion Botnets Malware:
Trojan horse, virus, worm,
spyware Spam Phishing
Terrorist Blackmail Destruction Bomb Information System
warfare Exploitation attack (e.g., distributed
Revenge Monetary gain denial of service) System
Political gain penetration System
tampering
 Industrial espionage Competitive advantage Economic exploitation
Economic espionage Information theft Intrusion
Blackmail on personal privacy Social
engineering System
penetration Unauthorized
system access (access to
classified, proprietary, and/or
technology related
information)
Part-B (4 X 5M=20M)
Answer ALL Questions
5. List the components of optional attack pattern. Classify the vulnerability cases recorded by
CERT and Global Security survey.

ANS:
1. Examples— instances
2. Source exploits
3. Related attack
4. Relevant design patterns
5. Relevant security
6. Related guidelines or rules
7. Relevant security requirements
8. Probing techniques
9.Indicators— warnings of attack
10. Obfuscation techniques
11. Injection vector
12. Payload
13. Activation zone
14. Payload activation impact
CERT
1. "[T]here is a clear and pressing need to change the way we (project managers and software
engineers) approach computer security and to develop a disciplined approach to software
security"
Global Security Survey
1. In Deloitte's 2007 Global Security Survey, 87 percent of survey respondents cited poor
software development quality as a top threat in the next 12 months. "Application security means
ensuring that there is secure code, integrated at the development stage, to prevent potential
vulnerabilities and that steps such as vulnerability testing, application scanning, and penetration
testing are part of an organization's software development life cycle [SDLC]"

6. Observe and reproduce the steps involved in analyzing software vulnerability through malicious
attack and abuse.
ANS
1. Address expected issues through the application of appropriate security architecture and
 features

2. Address unexpected issues through the avoidance, removal, and mitigation of

weaknesses that could lead to security vulnerabilities

3. Continually strive to improve and strengthen the attack resistance, tolerance, and
resilience of the software in everything they do.
7. Describe a real-world example of classic software security problem on a client server
application.
ANS:
1. The architecture had been set up so that the server relied on the client-side application,
 which manipulated a financially sensitive database, to manage all data-access
permissions —no permissions were enforced on the server itself. In fact, only the client
had any notion of permissions and access control.
2. To make matters worse, a complete copy of the database (only parts of which were to
be viewed by a given user with a particular client) was sent to the client program, which
ran on a garden-variety desktop PC.
3. As a consequence, a complete copy of the sensitive data (which was expressly not to be
viewed by the user) was available on that user's PC in the clear. If the user looked in the
application's cache on the hard disk and used a standard-issue unzip utility, he or she
could see all sorts of sensitive information.
4. The client also enforced which messages were sent to the server, honoring these
messages independent of the user's actual credentials. The server assumed that any
messages coming from the client had passed the client software's access control system
(and policy) and were, therefore, legitimate. By intercepting network traffic, corrupting
values in the client software's cache, or building a hostile client, malicious users could
inject data into the database that they were not even supposed to read (much less write
to).
8. Recall the security guidelines from BSI that need to be followed for concurrency management.
ANS:
Failure to follow proper concurrency management protocols can introduce serious
vulnerabilities into a system.
In particular, concurrent access to shared resources without using appropriate concurrency
management mechanisms produces hard-to-find vulnerabilities.
Many "functions" that are necessary to use can introduce "time of check/time of use"
vulnerabilities.
When multiple threads of control attempt to share the same resource but do not follow the
appropriate concurrency protection protocol, then any of the following results are possible:
1.Deadlock: One or more threads may become permanently blocked.
2. Loss of information: Saved information is overwritten by another thread.
3. Loss of integrity of information: Information written by multiple threads may be arbitrarily
interlaced.
4.Loss of liveness: Imbalance in access to shared resources by competing threads can cause
performance problems
Any of these outcomes can have security implications, which are sometimes manifested as
apparent logic errors (decisions made based on corrupt data).
Part-C (2 X 9M=18M)
Answer ALL Questions
9. a. Indicate the risks that are associated when software extensions are appended to a software.
ANS: The growing Internet connectivity of computers and networks and the corresponding user
dependence on network-enabled services (such as email and Web-based transactions) have
increased the number and sophistication of attack methods, as well as the ease with which an
attack can be launched. This trend puts software at greater risk. Another risk area affecting
software security is the degree to which systems accept updates and extensions for evolving
capabilities. Extensible systems are attractive because they provide for the addition of new
features and services, but each new extension adds new capabilities, new interfaces, and thus
new risks. A final software security risk area is the unbridled growth in the size and complexity
of software systems (such as the Microsoft Windows operating system). The unfortunate reality
is that in general more lines of code produce more bugs and vulnerabilities
b. Retell on the phrase “Small Faults, Big Consequences”.
ANS:
There is a conventional wisdom espoused by many software engineers that says vulnerabilities
which fall within a specified range of speculated impact ("size") can be tolerated and allowed to
 remain in the software. This belief is based on the underlying assumption that small faults have
small consequences. In terms of defects with security implications, however, this conventional
wisdom is wrong. Nancy Leveson suggests that vulnerabilities in large software-intensive
systems with significant human interaction will increasingly result from multiple minor defects,
each insignificant by itself, thereby collectively placing the system into a vulnerable state
[Leveson 2004].
For high-assurance systems, there is no justification for tolerating known vulnerabilities. True
software security is achievable only when all known aspects of the software are understood and
verified to be predictably correct. This includes verifying the correctness of the software's
behavior under a wide variety of conditions, including hostile conditions. As a consequence,
software testing needs to include observing the software's behavior under the following
circumstances:
1. Attacks are launched against the software itself.
2. The software's inputs or outputs (e.g., data files, arguments, signals) are compromised
3. The software's interfaces to other entities are compromised
4. The software's execution environment is attacked
(Or)
10. a. Cite the importance of Software Requirement Specification to avoid future risks in the
software.
ANS:
1. Functionality of the software: What the software will do
2. External interfaces: How the given software will interact with hardware, other
software(s) and assumptions on these entities
3. Required performance levels: Required performance levels such as response rate,
recovery rate etc. of the software
4. Quality attributes: The non-functional factors that are used to evaluate the performance
of the software, such as security, safety, portability etc
5. Design constraints: Any operating system limitations (e.g.: the stock exchange software
will only run on Windows), implementation language etc that will affect or limit the
design of the software.
b. Report a solution for the “Heartbleed Vulnerability” case study for software security
assurance.
ANS:
Case Study: Heartbleed Vulnerability

The Heartbleed vulnerability occurred in the OpenSSL "assert" function, which is the initiator of
a heartbeat protocol to verify that the OpenSSL server is live. OpenSSL is an open-source
implementation of the secure socket layer (SSL) and transport layer security (TLS)
protocols used for securing web communications. The assert function sends a request with two
parameters, a content string (payload) and an integer value that represents the length of the
payload it is sending. If the OpenSSL connection is available the expected response is a return
of the content string for the length specified.

The protocol assumes that the requested length of the payload returned is less than 65,535 and
less than or equal to the payload length, but those assumptions are never verified by the
responding function. A consequence of a violation of either of these limitations is that the
request can trigger a data leak. Rather than a buffer overflow, this leak is what is called an over-
read. The security risk is that the additional data retrieved from the server's memory could
contain passwords, user identification information, and other confidential information.

The defect appears to have been accidentally introduced by an update in December 2011.
OpenSSL is a widely used and free tool. At the disclosure of Heartbleed, approximately
500,000 of the internet's secure web servers certified by trusted authorities were believed to be
 vulnerable to the attack. The new OpenSSL version repaired this vulnerability by including a
bounds check to ensure that the payload length specified by a developer is not longer than the
data that is actually sent. Unfortunately, that check is only the start of an implemented
correction because elimination of the vulnerability requires the 500,000 users of this software to
upgrade to the new version. In addition, because this problem is related to security
certificates, protecting systems from attacks that exploit the Heartbleed vulnerability requires
that companies revoke old SSL certificates, generate new keys, and issue new certificates.

IEEE's Security and Privacy article Heartbleed 101 provides an excellent summary of why this
vulnerability was not found sooner, even with the use of static analysis tools. The designer of
each static analysis tool has to make trade-offs among the time required for the analysis, the
expert help required to support the tool's analysis, and the completeness of the analysis. Most
static analysis tools use heuristics to identify likely vulnerabilities and to allow completion of
their analysis within useful times. The article goes on to explain that while static analysis tools
can be effective for finding some types of vulnerabilities, the complexity of OpenSSL
(including multiple levels of indirection and other issues) exceeded the capabilities of existing
tools to find this type of vulnerability.
While the OpenSSL program is complex, the cause of the vulnerability is simple. The software
never verified the design assumption that the length of the content to be returned to the caller
was less than or equal to the length of the payload sent. Verifying that the input data meets its
specifications is a standard activity performed for quality, not just for security.
The associated software errors that led to the "goto fail" and Heartbleed vulnerabilities should
have been identified during development. These two examples highlight the fact that quality
practices, such as inspections and reviews of engineering decisions, are essential for security.
For example, testing and code analyzers, must be augmented by disciplined quality
approaches.

Improve Security with Quality

Our research suggests that implementing systems with effective operational security requires
incorporating both quality and security considerations throughout the lifecycle. Predicting
effective operational security requires quality evidence and security expert analysis at each step
in the lifecycle. If defects are measured, it follows that from 1 percent to 5 percent of them
should be considered vulnerabilities. Likewise, when security vulnerabilities are measured, then
code quality can be estimated by considering them to be 1 percent to 5 percent of expected
defects.

Further evaluation of systems is needed to see if the patterns suggested by our analysis continue
to hold. We explored several options to expand our sample size, but found limited data about
defects and vulnerabilities assembled in a form that could be readily analyzed. This analysis
must be done for each unique version of a software product. At this time, evaluation of each
software product requires careful review of each software change and reported vulnerability.
The review not only matches up defects with source code versions, but also reviews each
vulnerability reported against the product suite to identify defects specific to the selected
product version by parsing available description information and identifying operational results
for the same source code. Collection of data about each product in a form that supports
automation of this analysis would greatly speed confirmation.

11. a. Describe various principles of securing the weakest link and separation of privilege.
ANS:
Weakest link
Attackers are more likely to attack a weak spot in a software system than to penetrate a heavily
fortified component. For example, some cryptographic algorithms can take many years to break,
so attackers are unlikely to attack encrypted information communicated in a network. Instead,
the endpoints of communication (e.g., servers) may be much easier to attack. Knowing when
 the weak spots of a software application have been fortified can indicate to a software vendor
whether the application is secure enough to be released.

Separation of Privilege
The Principle of Separation of Privilege A system should ensure that multiple conditions are
met before it grants permissions to an object. Checking access on only one condition may not be
adequate for enforcing strong security. If an attacker is able to obtain one privilege but not a
second, the attacker may not be able to launch a successful attack. If a software system largely
consists of one component, however, it will not be able to implement a scheme of having
multiple checks to access different components. Compartmentalizing software into separate
components that require multiple checks for access can inhibit an attack or potentially prevent
an attacker from taking over an entire system.
b. Classify the vulnerabilities as per the CWE approach, identify the mappings between a threat
and vulnerability.
ANS:
Vulnerability Classification Classifying vulnerabilities allows for pattern recognition of
vulnerability types. This exercise, in turn, may enable the software development team to
recognize and develop countermeasures to deal with classes of vulnerabilities by dealing with
the vulnerabilities at a higher level of abstraction. The most comprehensive and mature example
of such a classification taxonomy currently available is the Common Weakness Enumeration
(CWE) [CWE 2007], which has been crafted as a normalized aggregation of dozens of the other
such taxonomies recognized and respected by the industry. The CWE includes seven toplevel
categories for architecture and source code [Tsipenyuk 2005]:
Data Handling
API Abuse
Security Features
Time and State
Error Handling
Code Quality
Encapsulation

Mapping Threats and Vulnerabilities

The combination of threats and vulnerabilities illustrates the risks to which the software is
exposed. Several models exist to categorize the areas where these threats and vulnerabilities
frequently intersect. One example is Microsoft's STRIDE, which provides a model of risks to a
computer system related to spoofing, tampering, repudiation, information disclosure, denial of
service, and elevation of privilege. Risk classification assists in communicating and
documenting risk management decisions. Risk mitigation mechanisms should map to the risk
category or categories of the threats and vulnerabilities that have been identified through this
effort.
(Or)
12. a. Examine the plan that are to be considered to mitigate architectural flaws.
ANS:
Risk Mitigation Planning
1. Penetration Testing
2. Architectural mitigations require following changes
a. Change to multiple modules
 b. Change to Multiple systems
Measures to reduce Likelihood Risk
1. 1. Improving the skill
2. 2. Reduce the period of time.
Measures to reduce Impact of risk
1. Estimating Vulnerability
2. Remediating a broken system
Mitigation Factors
1. Detection strategies
2. Correction Strategies.
b. Explain any two candidate prioritization methods.
ANS:
Binary Search Tree (BST)
A binary search tree is an algorithm that is typically used in a search for information and can
easily be scaled to be used in prioritizing many requirements [Ahl 2005].
The basic approach for requirements is as follows, quoting from [Ahl 2005]:
1. Put all requirements in one pile.
2. Take one requirement and put it as the root node.
3. Take another requirement and compare it to the root node.
4. If the requirement is less important than the root node, compare it to the left child node. If the
requirement is more important than the root node, compare it to the right child node. If the node
does not have any appropriate child nodes, insert the new requirement as the new child node to
the right or left, depending on whether the requirement is more or less important.
5. Repeat Steps 3 and 4 until all requirements have been compared and inserted into the BST.
6. For presentation purposes, traverse through the entire BST in order and put the requirements
in a list, with the least important requirement at the end of the list and the most important
requirement at the start of the list.
Numeral Assignment Technique
The numeral assignment technique provides a scale for each requirement. Brackett proposed
dividing the requirements into three groups: mandatory, desirable, and unessential. Participants
assign each requirement a number on a scale of 1 to 5 to indicate its importance [Karlsson
1995]. The final ranking is the average of all participants' rankings for each requirement.