DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

GITAM SCHOOL OF TECHNOLOGY

GITAM (Deemed to be University), VISAKHAPATNAM-530045

Program B.Tech MID III Marks 30

06-04-2023
Semester VIII Course Code 19ECS448 Date
Thursday
SECURE
9.30AM -
Branch CSE Course Title SOFTWARE Time
11.00AM
ENGINEERING

SECTION A (10 marks)

Answer all the questions. Each question carries equal marks. 5x2=10M
1. a) Memorize “What is Software Security Testing”? CO4 L3
b) Connect “Why is Software Security Testing Required”? CO4 L4
c) Relate the definition of Security Governance? CO4 L5
d) Summarize Characteristics of Effective Security Governance and
Management? CO5 L2
e) Discover about Enterprise Software Security Framework? CO5 L5

SECTION B (20 marks)

Each Question carries 10 marks with internal choice 2x10=20M
2. Criticize “While preparing and planning for security tests, what approaches a
developer can take “? CO4 L3
3. Illustrate types of Software Security Testing CO5 L4
(OR)
4. a) Design “What are the SSDLC best practices” ? CO4 L2
b) Write about V-Model (validation and verification)? CO5 L2
5. Develop “Adopting an Enterprise Software Security Framework”? CO5 L4
(OR)
6. a) Relate “Maturity of Practice.”? CO5 L3
b) Cite “How Much Security Is Enough”? CO5 L4
 MID – III - KEY
SECTION A (10 marks)
Answer all the questions. Each question carries equal marks. 5x2=10M
1. a) Memorize “What is Software Security Testing”? CO4 L3
Security test activities are primarily performed to demonstrate that a system meets its
security requirements and to identify and minimize the number of security vulnerabilities
in the software before the system goes into production. Additionally, security test activities
can aid in reducing overall project costs, protecting an organization’s reputation or brand
once a product is deployed, reducing litigation expenses, and complying with regulatory
requirements.
b) Connect “Why is Software Security Testing Required”? CO4 L4
The goal of security testing is to ensure that the software being tested is robust and continues
to function in an acceptable manner even in the presence of a malicious attack. Security testing
is motivated by probing undocumented assumptions and areas of particular complexity to
determine how a software program can be broken. The designers and the specification might
outline a secure design, and the developers might be diligent and write secure code, but
ultimately the testing process determines whether the software will be adequately secure once
it is fielded.
c) Relate the definition of Security Governance? CO4 L5
The term governance applied to any subject can have a wide range of interpretations and
definitions. For the purpose of this chapter, we define governing for enterprise security as
follows:
Directing and controlling an organization to establish and sustain a culture of security in the
organization’s conduct (beliefs, behaviors, capabilities, and actions) Treating adequate security
as a non-negotiable requirement of being in business.

NIST defines information security governance as:

The process of establishing and maintaining a framework and supporting management structure
and processes to pro- vide assurance that information security strategies – are aligned with and
support business objectives, – are consistent with applicable laws and regulations through
adherence to policies and internal controls, and – provide assignment of responsibility, all in
an effort to manage risk.
d) Summarize Characteristics of Effective Security Governance and
Management? CO5 L2
 • Security is managed as an enterprise issue, horizontally, vertically, and cross-
functionally throughout the organization.
• Security is treated as a business requirement. It is considered a cost of doing business
and perceived as an investment rather than an expense or a discretionary budget-line
item.
• Security is considered an integral part of normal strategic, capital, project, and
operational planning cycles. Security has achievable, measurable objectives that are
integrated into strategic and project plans and implemented with effective controls and
metrics.
• Security is addressed as part of any new project initiation, acquisition, or relationship
and as part of ongoing project management.
• Managers across the organization understand how security serves as a business enabler.
• All personnel who have access to digital assets and enterprise networks understand their
individual responsibilities to protect and preserve the organization’s security, including
the systems and software that it uses and develops.
e) Discover about Enterprise Software Security Framework? CO5 L5
In the context of an Enterprise Software Security Framework, governance is competency in
measuring software-induced risk and supporting an objective decision-making process for
remediation and software release. This competency involves creating a seat at the project
management table for software risk alongside budget and scheduling concerns.
The ESSF defines an organization’s approach to software security and describes roles,
responsibilities,
activities, deliverables, and measurement criteria. It also includes a communication plan for
enterprise wide-rollout. Enterprise software and data architectures are essential anchors of the
goal-state an ESSF defines. Definition of and migration toward a secure enterprise architecture
are thus part of the framework competency.

SECTION B (20 marks)

Each Question carries 10 marks with internal choice 2x10=20M
1. Criticize “While preparing and planning for security tests, what approaches a
developer can take “? CO4 L3
Role of security testing in each of these activities:
• Unit testing, where individual classes, methods, functions, or other relatively small
components are tested
• Testing libraries and executable files
• Functional testing, where software is tested for adherence to requirements
• Integration testing, where the goal is to test whether software components work together as
they should
• System testing, where the entire system is under test
2. Illustrate types of Software Security Testing CO5 L4
Two common methods for testing whether software has met its security requirements are
functional security testing and risk-based security testing. Functional testing is meant to ensure
that software behaves as specified and so is largely based on demonstrating that requirements
defined in advance during requirements engineering are satisfied at an acceptable level. Risk-
based testing probes specific risks that have been identified through risk analysis.
Functional Testing: Functional testing usually means testing the system’s adherence to its
functional requirements. A functional requirement usually has the following form: “When a
specific thing happens, then the software should respond in a certain way.” This way of
specifying a requirement is convenient for the tester, who can exercise the “if” part of the
requirement and then confirm that the software behaves as it should.
Risk-Based Testing: Risk-based testing addresses negative requirements, which state what
a software system should not do. Tests for negative requirements can be developed in a number
of ways. They should be derived from a risk analysis, which should encompass not only the
high-level risks identified during the design process but also low-level risks derived from the
software itself.
(OR)
3. a) Design “What are the SSDLC best practices” ? CO4 L2
The classic SDLC stages require modification to integrate security strengthening
activities throughout the entire process.
We briefly considered the main stages of a typical SDLC process at the start of this
article. Now, let’s see how these steps are modified when security is integrated into each
stage.
1. Requirement gathering
 This stage now focuses on preparing a list of security and regulatory requirements and
all the other general details of the project. A detailed plan is generally formulated, where
the corresponding security assurance activities for all the different stages are laid down.
A crucial component of this stage is security awareness training. Training sessions
aimed at providing security knowledge to the participants in the project equips them to
take measures for secure design and development and establish a security mindset right
from the outset for the whole team.
2. Design
As before, the design stage is where all the details, such as programming languages,
software architecture, functionalities and user interfaces are decided. The SSDLC
practices in this stage involve determining much of the security functionalities and
defense mechanisms of the application.
Some key security-focused activities in this stage include:
• Threat modeling: Simulating attack scenarios and integrating effective
countermeasures to the list of identified threats capable of compromising the
application establishes the foundation for all subsequent security measures taken. Early
detection of possible threats not only reduces the likelihood of successful attacks but
also reduces costs associated with security integration for the whole project.
• Design documents and reviews: The modeling results help teams prepare design
documents identifying security requirements and key vulnerabilities that need to be
addressed for the security of the application.
• Identifying third-party risks: Even the most secure application is liable to attacks if the
associated third-party components are vulnerable, rendering the whole system weak.
Therefore, it is paramount to check and monitor possible security holes in third-party
apps and apply patches as necessary for the integrity of the whole application system.
3. Development/build
This is the stage where all the implementation takes place. In the SSDLC context, the stage
involves activities such as secure coding and scanning.
• Secure coding: Secure best practices for application coding such as authentication and
encryption are taken care of in this stage. Typically, teams aim to follow secure coding
practices, which successfully eliminates many basic vulnerabilities, minimizing the
need for backtracking the same steps to fix and patch ignored vulnerabilities discovered
later in the project.
• SAST: Static application scanning tools (SAST) have made it possible to test and
review code before the application is complete. Static scanning helps discover security
issues at any stage of development, making it easier to detect and fix issues as the
project evolves.
• Manual code review: SAST provides automated scanning functionality. While it greatly
facilitates developers, saving time and effort when it comes to discovering
vulnerabilities, manual reviews can never be ignored entirely. Human supervision is
still needed to identify potential issues in the code that malicious attackers could
potentially exploit.
4. Testing
The testing stage is where security testing goes into full swing under the SSDLC approach.
Common practices performed during this stage include:
• Dynamic scanning: Unlike SAST, dynamic application scanner tools (DAST) simulate
hacking attempts and threats at runtime to expose application vulnerabilities. Combined
with SAST in the previous stage, DAST adds an extra layer of testing that eliminates
most security errors.
• Fuzzing: In fuzz testing, developers generate random inputs that mimic custom patterns
and check if the application can handle these inputs. This helps build protection for
problems like SQL injection, which is essentially a form of malicious input.
• Penetration testing: Simulating attacks by inviting a third-party team of security
professionals is one of the best ways of exposing hidden vulnerabilities in any system.
It’s always possible for the developing team to overlook certain attack scenarios that
the experience and knowledge of third-party experts might reproduce through
penetration testing.
5. Deploy and maintain
The job of a developer doesn’t end when an application goes live. Apps have ecosystems
of their own, and they must be managed, maintained and taken care of.
• Some SSDLC practices in this stage include:
• Environment response: An application may be foolproof itself, but every application is
only useful only in its relation to the larger ecosystem. Once an application is launched,
monitoring the environment and its influence on the app’s behavior and integrity is a
critical aspect of maintenance.
 • Incident response plan: In the real world, no application truly immune to security
breaches. An incident response plan prescribes the plans, actions, and procedures that
your team must follow in the event of a breach.
• Security checks: Threats and attacks are always evolving, and applications must evolve
even faster to stay safe. Frequent security checks help protect applications from new
forms of attacks and vulnerabilities.
b) Write about V-Model (validation and verification)? CO5 L2
• The V-model (the V stands for validation and verification) is a linear model, but its
similarity with waterfall ends at this point.
• The chief characteristic of this model is its heavy emphasis on testing. This is why the
V-model is marked by each stage having its own testing activity so that testing takes
place throughout all phases of development until completion.
• The extensive testing and quality controls embedded in the V-model make it one of the
most expensive and demanding software development approaches. As such, it’s only
used in highly specialized situations, such as projects where the risk tolerance for
failures and errors is marginal.
4. Develop “Adopting an Enterprise Software Security Framework”? CO5 L4
Most organizations no longer take for granted that their deployed applications are secure. But
even after conducting penetration tests, network and hosting security personnel spend
considerable time chasing incidents. Your organization might be one of the many that have
realized the “secure the perimeter” approach doesn’t stem the tide of incidents because the
software it’s building and buying doesn’t resist attack.
Common pitfalls
Lack of Software Security Goals and Vision:
• It bears repeating: The first hurdle for software security is cultural. It’s about how
software resists attack, not how well you protect the environment in which the software
is deployed. Organizations are beginning to absorb this concept, but they don’t know
exactly what to do about it. Their first reaction is usually to throw money and one of
their go-getters at it. He or she might make some progress initially by defining some
application security guidelines or even buying a static analysis tool—essentially,
picking the low-hanging fruit
• Although it sounds compelling, avoid charging off to win this easy battle. If your
organization is large, you don’t need to be reminded of what role politics plays. At the
director level, headcount, budget, and timelines are the system of currency, and
 demanding that development teams adhere to guidelines requiring development they
haven’t budgeted for, or imposing a tool that spits out vulnerabilities for them to fix
prior to release, can quickly send software security efforts into political deficit.
Creating a New Group:
• Some organizations respond to the software security problem by creating a group to
address it. Headcount and attention are necessary, but it’s a mistake to place this
headcount on an island by itself. It’s an even bigger mistake to use network security
folks to create a software security capability—they just don’t understand software well
enough.
• Software security resources must be placed into development teams and seen as
advocates for security, integration, and overcoming development roadblocks.
Software Security Best Practices Nonexistent:
• Security analysts won’t be much more effective than penetration testing tools if they
don’t know what to look for when they analyze software architecture and code.
Likewise, levying unpublished security demands on developers is nonproductive and
breeds an us-versus them conflict between developers and security
• Instead, build technology-specific prescriptive guidance for developers. If the guidance
doesn’t explain exactly what to do and how to do it, it’s not specific enough. Specific
guidance removes the guesswork from the developer’s mind and solves the problem of
consistency between security analysts.
Software Risk Doesn’t Support Decision Making:
• Although most organizations view critical security risks as having the utmost
importance, project managers constantly struggle to apply risk-management
techniques. The first reason for this is a lack of visibility. Even if a technical
vulnerability is identified, analysts often don’t fully understand its probability and
impact. Rarely does an organization use a risk-management framework to consistently
calculate a risk’s impact at the project-management or portfolio level.
Framing the Solution:
• An enterprise software security framework (ESSF) is a new way of thinking about
software security more completely at the enterprise level, targeting the problem directly
without demands for massive headcount, role changes, or turning an IT shop upside
down to prioritize security ahead of supporting the business that funds it.
• ESSFs align the necessary people, know-how, technologies, and software development
activities to achieve more secure software. Because every organization possesses
 different strengths and weaknesses and, most important, faces different risks as a result
of using software, ESSFs will differ across organizations. There are, however, certain
properties that all good ESSFs will possess.
“Who, What, When” Structure
• To align each group’s role in achieving secure software, an organization’s ESSF should
possess a “who, what, when” structure—that is, the framework should describe what
activities each role is responsible for and at what point the activity should be conducted.
Because building security into applications requires the collaboration of a wide variety
of disciplines, the framework should include roles beyond the security analysts and
application development teams. Figure 7–1 shows column headings under which an
ESSF might list each role’s responsibility. The boxes outlined in a lighter shade
represent each role’s first steps
 (OR)
5. a) Relate “Maturity of Practice.”? CO5 L3
Security’s emergence as a governance and management concern is primarily taking place
in the parts of the organization that provide and use IT. We currently see minimal attention
paid to this topic during the early life-cycle phases of software and system development,
but increasing attention being devoted to it during detailed design, coding, and testing.
Treating security as a governance and management concern, as a risk management concern,
and as a project management concern at the earliest phases of the life cycle will likely
produce more robust, less vulnerable software, thereby resulting in a decline in the reactive,
fire-fighting mode now observed in most IT and system operations and maintenance
organizations.
Audit’s Role
• As part of the U.S. Critical Infrastructure Assurance Project, the Institute of Internal
Auditors (IIA) held six summit conferences in 2000 to better understand the role of
 governance with respect to information security management and assurance. The IIA
also provided guidance in 2001 in the document titled “Information Security
Governance: What Directors Need to Know.” This report includes case studies from
General Motors, IBM, BellSouth, Intel, Sun Microsystems, the Federal Reserve Bank
in Chicago, and Home Depot. Useful questions to ask that resulted from this work are
listed in “Maturity of Practice and Exemplars” on the BSI Web site.
• The Information Systems Audit and Control Association (ISACA) and its partner
organization, the IT Governance Institute (ITGI), have published extensive guidance
on information technology and information security governance. Their report titled
“Information Security Governance: Guidance for Boards of Directors and Executive
Management” [ITGI 2006] addresses these questions:
• 1. What is information security governance?
• 2. Why is it important?
• 3. Who is responsible for it?
Operational Resilience and Convergence:
• A number of other organizations are describing their efforts to achieve organizational
resilience through the integration of business continuity, operational and technology
risk management, compliance, and information security and privacy, supported by
audit. These integrating activities occur across products and business lines and take into
account people, business processes, infrastructure, applications, information, and
facilities. Indicators of success include the following outcomes:
• Reduced risk of a business interruption
• Shorter recovery time when an interruption occurs
• Improved ability to sustain public confidence and meet customer expectations
• Increased likelihood of complying with regulatory and internal service level
requirements
• The identification of security risks and interdependencies between business
functions and processes within the enterprise and the development of managed
business process solutions to address those risks and interdependencies.
A Legal View:
• The American Bar Association’s Privacy and Computer Crime Committee has
published a “Roadmap to an Enterprise Security Program”.
• The Roadmap presents a structure that includes governance, security integration and
security operations, implementation and evaluation, and capital planning and
investment controls. The steps for governance include these
• Establish governance structure, exercise oversight, and develop policies.
• Inventory digital assets (networks, applications, information).
• Establish ownership of networks, applications, and information; designate security
responsibilities for each.
• Determine compliance requirements with laws, regulations, guidance, standards, and
agreements (privacy, security, and cybercrime).
• Conduct threat and risk assessments and security plan reviews (for internal and contractor
operations). This may include certification and accreditation.
• Conduct risk management based on digital asset categorization and level of risk.
A Software Engineering View:
• An emerging body of knowledge describes aspects of how to apply governance and
management thinking to the engineering and development of secure software. In
addition to John Steven’s article “Adopting an Enterprise Software Security
Framework”, several other articles on the BSI Web site that were previously published
in a series in IEEE Security & Privacy address aspects of this issue.
• “Adopting a Software Security Improvement Program” provides several concrete steps
and a progression of phases for improvement. “Bridging the Gap Between Software
Development and Information Security” describes a range of secure software
development activities and practices to conduct during a software development life
cycle.
Exemplars:
Many use strategic questions and guiding principles as starting points. Summaries are
provided for the following organizations and events:
• Aberdeen Group
• American Chemistry Counsel
• Audit Associations (Institute of Internal Auditors, Information Technology Governance
Institute)
• BITS
• Corporate Governance Task Force
• Corporate Information Security Working Group
• Federal Financial Institutions Examination Council
 • Health Information and Management Systems Society
• ISO/IEC 27001 and ISO/IEC 17799
• National Association of Corporate Directors
• National Institute of Standards and Technology
• Payment Card Industry Data Security Standard
• Veterans Administration Data Breach
Several of these examples and their supporting references provide sufficient detail to help
you start implementing a security governance and management program
b) Cite “How Much Security Is Enough”? CO5 L4
• Prior to selecting which security governance and management actions to take and in
what order, you must answer the following question: How much security is enough?
One way to tackle this question is to formulate and answer the set of security strategy
questions presented.
• identify a means for determining your definition of adequate or acceptable security, and
use these as inputs for your security risk management framework.
Defining Adequate Security
• Determining adequate security is largely synonymous with determining and managing
risk. Where possible, an organization can implement controls that satisfy the security
requirements of its critical business processes and assets. Where this is not possible,
security risks to such processes and assets can be identified, mitigated, and managed at
a level of residual risk that is acceptable to the organization
• Adequate security has been defined as follows: “The condition where the protection
strategies for an organization’s critical assets and business processes are commensurate
with the organization’s tolerance for risk. In this definition, protection strategies include
principles, policies, procedures, processes, practices, and performance indicators and
measures—all of which are elements of an overall system of controls.
Risk Tolerance:
• An organization’s tolerance for risk can be defined as “the amount of risk, on a broad
level, an entity is willing to accept in pursuit of value (and its mission)”. Risk tolerance
influences business culture, operating style, strategies, resource allocation, and
infrastructure. It is not a constant, however, but rather is influenced by and must adapt
to changes in the environment.
• Defining the organization’s tolerance for risk is an executive responsibility. Risk
tolerance can be expressed as impact (potential consequences of a risk-based event),
 likelihood of a risk’s occurrence, and associated mitigating actions. For identified and
evaluated risks, it could be defined as the residual risk the organization is willing to
accept after implementing risk-mitigation and monitoring processes.
• With the benefit of this description, a useful way to address the question “How much
security is enough?” is to first ask, “What is our definition of adequate security?” To do
so, we can explore the following more detailed questions:
• What are the critical assets and business processes that support achieving our
organizational goals? What are the organization’s risk tolerances, both in
general and with respect to critical assets and processes?
• Under which conditions and with what likelihood are assets and processes at
risk? What are the possible adverse consequences if a risk is realized? Do these
risks fit within our risk tolerances?
• In cases where risks go beyond these thresholds, which mitigating actions do
we need to take and with which priority? Are we making conscious decisions to
accept levels of risk exposure and then effectively managing residual risk? Have
we considered mechanisms for sharing potential risk impact (e.g., through
insurance or
with third parties)?
• For those risks we are unwilling or unable to accept, which protection strategies
do we need to put in place? What is the cost–benefit relationship or return on
investment of deploying these strategies?
• How well are we managing our security state today? How confident are we that
our protection strategies will sustain an acceptable level of security 30 days, 6
months, and 1 year from now? Are we updating our understanding and
definition of our security state as part of normal planning and review processes?