Case Story:

You are the So+ware Engineer of a project. Your role is to secure the Applica9on Program Interfaces
(APIs) func9ons of business applica9on specific cloud services being developed. However you will
design cybersecurity capabili9es of the project’s cloud services in compliance to the following project
governance standards:

• The So0ware Engineering Body of Knowledge (SWEBoK), as a development methodology

• A Shi0 Le0 guide for considering security controls in SDLC work
• A Zero Trust guide for fostering a person and device centred approach for incorpora9ng
cybersecurity risk management capabili9es in cloud services design and ops-execu9on.

The project’s development environment adopts an IBM’s DevSecOps model

A corporate Enterprise Architect is assigned to your project. The person is responsible for
cybersecurity controls implementa9on across the organisa9on, including all projects; and has given
you a cybersecurity brief for securing the API func9ons. The expecta9on is that you will propose how
you can apply the “Shi+ Le+” guide in your project work; especially in the verifica9on and valida9on
of the project’s applica9on’s requirements during so+ware (product) tes9ng.

The Enterprise Architect has agreed to reference the Landing Page of the project’s business
applica9on, to dra+ your first API Shi+-Le+ guidelines, incorpora9ng OAuth 2.0 framework, that
applies Zero Trust principles in first authen9ca9on of user and device iden99es and monitoring user
transac9ons down to database resource levels.

Overview of OAuth 2.0:

OAuth 2.0 provides a flexible and standardized approach that provides an open architecture
framework for securing API authen9ca9on and authoriza9on. It is widely adopted by many
popular services and APIs, including social media pla]orms and cloud service providers, to
enable third-party applica9ons to access user data in a controlled and secure manner
without exposing user creden9als.

The framework guides project teams to design and implement Zero Trust features that allow
cloud based applica9ons to obtain limited access to user resources on an HTTP service (such
as APIs) without needing to know the user's creden9als or have direct access to their
passwords. It is commonly used to provide secured and delegated access to protected
resources, such as user data, on behalf of a user.

The OAuth 2.0 framework involves mul9ple par9es: the resource owner (the user who owns
the protected resources), the client (the applica9on or service reques9ng access to the
resources), the authoriza9on server (which authen9cates the user and issues access tokens),
and the resource server (which hosts the protected resources).

OAuth 2.0 applies six Zero Trust compliant security pathways:

User IdenFty AuthenFcaFon Steps:

1. Client RegistraFon: The client applica9on registers itself with the authoriza9on server and
receives a client iden9fier and client secret. This step establishes trust between the client
and the server.
2. User AuthenFcaFon and AuthorizaFon: The client redirects the user to the authoriza9on
server, where the user is prompted to authen9cate and authorize the client's access to their
resources. This step ensures that the user explicitly grants permission to the client.

TransacFons Monitoring Steps:

 3. Access Token Request: Once the user grants authoriza9on, the client sends a request to the
authoriza9on server to obtain an access token. The request includes the client iden9fier,
client secret, and other required parameters.
4. Access Token Issuance: If the client's request is valid and authorized, the authoriza9on
server issues an access token to the client. The access token represents the client's authority
to access the protected resources on behalf of the user.
5. Resource Access: The client presents the access token to the resource server when
reques9ng access to protected resources. The resource server validates the access token and
grants or denies access to the requested resources based on the token's validity and the
user's authoriza9on.

Problem Descrip4on
In addi9on to knowing how to implement the Shi+ Le+ guidelines in your project, you have the
research and understand the defini9on no9ons of:

• Shi+ Le+ paradigms and V-Tes9ng framework in So+ware Tes9ng Implica9ons

• Zero Trust user authen9ca9on and transac9ons monitoring
• SWEBoK oriented SDLC work ac9vity structures
• IBM DevSecOps approach to automa9ng SDLC work

and how they interrelate in your development of your project’s Shi+ Le+ procedures.

A near coming project sponsor mee9ng is approaching in 14 days’ 9me. Your project manager is
asking you to present to project leads a visual mind map that visualises and explains how project
designers can secure API func9ons in the Landing Page. You are also expected to provide a short
management report that elaborates the explana9on of your presenta9on.

Problem Statement
Your report should clearly answer the following ques9ons:

1. Explain the key concepts of

• Shi+ Le+
• DevSecOps
• Zero Trust Architecture
• SWEBoK So+ware Tes9ng Ac9vi9es
• The V Tes9ng Model

2. Explain how these concepts interplay to structure the sec9ons in your report. Use mind mapping
as a criFcal thinking technique to itera9vely frame your thoughts to eventually arrive at a visual
outcome for organising these thoughts for wri9ng.
Solu4on Direc4on
A Report Template is provide to frame this explana9on.

Execu&ve Summary

1) Report Purpose
2) Report Objec&ve & Discussion Scope
3) Concepts Defini&on
4) Concepts Interrela&onship Summary (mind-map)
5) Recommended wri&ng sec&ons and brief descrip&on
6) Conclusion

References
Appendices (op&onal and will not be assessed)

Word Limit
1,300 to 1,500 (Max) words reference list not included.
Recommended Readings
SWEBoK
P. Bourque and R.E. Fairley, eds., Guide to the So+ware Engineering Body of Knowledge, Version 3.0,
IEEE Computer Society, 2014; www.swebok.org. hhps://www.computer.org/educa9on/bodies-of-
knowledge/so+ware-engineering

SYNOPSIS
The So+ware Engineering Body of Knowledge (SWEBoK) is a widely recognized guide that provides a
comprehensive overview of the knowledge areas and principles in the field of so+ware engineering.
It is not ahributed to a single author but is the result of collabora9ve efforts from the so+ware
engineering community.

The SWEBoK was developed and is maintained by the IEEE Computer Society and the Associa9on for
Compu9ng Machinery (ACM). It is an authorita9ve resource that undergoes regular updates and
revisions by a team of subject maher experts from academia, industry, and research ins9tu9ons.

The ini9al version of SWEBoK was released in 2004, and subsequent versions have been published
over the years, incorpora9ng updates and advancements in the field of so+ware engineering. The
collabora9ve nature of SWEBoK ensures that it represents the collec9ve exper9se and consensus of
the so+ware engineering community, contribu9ng to its credibility and relevance.

This is a useful document to refer to industry applica9on when developing “New ways of Working” /
seeking to increase the capability of so+ware development teams. It is an o+en-used resource to
determine what acFvity a team should be undertaking in so+ware development.

IBM What is DevSecOps?

hhps://www.ibm.com/topics/devops#:~:text=By%20defini9on%2C%20DevOps%20outlines%20a,eac
h%20other%2C%20or%20in%20silos.

SYNOPSIS
DevSecOps is an approach to so+ware development and opera9ons that integrates security prac9ces
and considera9ons into the DevOps workflow. It aims to ensure that security is built into the
so+ware delivery process from the beginning rather than being an a+erthought.

Tradi9onally, security has o+en been seen as a separate phase or responsibility that comes a+er the
development and deployment stages. However, this approach can result in vulnerabili9es and
security gaps being overlooked or addressed too late in the process. DevSecOps seeks to address this
by promo9ng a culture of shared responsibility, collabora9on, and automa9on between
development, opera9ons, and security teams.

Key Principles of DevSecOps:

1. Shi+-Le+ Security: DevSecOps emphasizes integra9ng security prac9ces as early as possible

in the so+ware development lifecycle (SDLC). This means considering security requirements
during the design and development phases, conduc9ng security tes9ng, and addressing
vulnerabili9es early on.
2. Automa9on: DevSecOps relies on automa9on tools and processes to enforce security
controls consistently and efficiently. Automated security tes9ng, vulnerability scanning, and
code analysis are examples of prac9ces used to iden9fy and address security issues
con9nuously.
3. Con9nuous Monitoring: DevSecOps advocates for con9nuous monitoring of applica9ons and
systems in produc9on environments. This allows for the detec9on and response to security
incidents and vulnerabili9es in real-9me, helping to reduce the 9me between iden9fying a
threat and taking ac9on.
4. Collabora9on and Shared Responsibility: DevSecOps promotes collabora9on and shared
responsibility between development, opera9ons, and security teams. By fostering open
 communica9on and coopera9on, teams can work together to iden9fy and address security
risks throughout the SDLC.
5. Security as Code: DevSecOps treats security configura9ons, policies, and controls as code
ar9facts. This allows for versioning, automated tes9ng, and integra9on into the overall
so+ware delivery process. Security as code prac9ces ensure consistency, scalability, and
maintainability of security measures.

Benefits of DevSecOps:

• Improved Security: DevSecOps promotes a proac9ve and con9nuous approach to security,

leading to more robust and secure so+ware systems.
• Faster Response: By integra9ng security throughout the development process, organiza9ons
can iden9fy and address vulnerabili9es more quickly, reducing the impact of poten9al
breaches.
• Collabora9on and Communica9on: DevSecOps encourages cross-func9onal collabora9on,
fostering a shared understanding of security considera9ons and beher alignment between
teams.
• Compliance: By integra9ng security prac9ces into the development workflow, organiza9ons
can more easily meet regulatory and compliance requirements.

Implemen9ng DevSecOps requires a combina9on of cultural shi+s, process changes, and the
adop9on of appropriate tools and technologies. It involves breaking down silos between
development, opera9ons, and security teams to create a unified approach to so+ware delivery that
priori9zes security.

Zero Trust Architecture

A Zero Trust Architecture Model for Access Control in Cloud-Na9ve Applica9ons in Mul9-Loca9on
Environments

hhps://nvlpubs.nist.gov/nistpubs/SpecialPublica9ons/NIST.SP.800-207A.ipd.pdf

SYNOPSIS
Zero Trust Architecture (ZTA) is a security model and approach to network and system design that
emphasizes strict access controls, verifica9on, and con9nuous monitoring to enhance cybersecurity.

The fundamental principle of Zero Trust Architecture is to assume that no device or user should be
inherently trusted, regardless of whether they are inside or outside the organiza9on's network
perimeter.

Tradi9onal network security models o+en relied on a perimeter-based approach, assuming that
devices and users inside the network were trusted, and the primary focus was on protec9ng the
perimeter from external threats. However, with the increasing number of sophis9cated cyber-ahacks
and the rise of remote work and cloud-based services, this model has proven to be insufficient.

Zero Trust Architecture, on the other hand, operates under the principle "never trust, always verify."
It incorporates various security measures to ensure that every access request is thoroughly
authen9cated and authorized, regardless of its source or loca9on. (see the OAuth 2.0 requirements
in case study)

Applying the principles of Zero Trust in so+ware development involves implemen9ng security
measures and prac9ces that focus on verifying and securing every component of the applica9on,
regardless of its origin or loca9on. Here are some key steps to apply Zero Trust in so+ware
development:
 1. Secure So+ware Development Lifecycle (SDLC): Integrate security throughout the en9re
so+ware development process, star9ng from the design phase. Adopt security best
prac9ces, code reviews, and tes9ng methodologies to iden9fy and fix security vulnerabili9es
early in the development process.
2. Secure APIs: If your so+ware relies on APIs (Applica9on Programming Interfaces), ensure
they are protected using authen9ca9on, authoriza9on, and encryp9on mechanisms.
Regularly review and update API security configura9ons.
3. DevSecOps Integra9on: Integrate security into the DevOps process through DevSecOps.
Automate security tes9ng, vulnerability scanning, and security controls as part of the
con9nuous integra9on and con9nuous deployment (CI/CD) pipeline.

By adop9ng these prac9ces, so+ware development teams can enhance the security posture of
their applica9ons, making them more resilient against various security threats and adhering to
the Zero Trust principles of "never trust, always verify."

V-Tes&ng Framework/Model
Firesmith, D. (2013, November 11). Using V Models for Tes9ng. Retrieved July 18, 2023, from
hhps://insights.sei.cmu.edu/blog/using-v-models-for-tes9ng/.

SYNOPSIS
An ar9cle for the So+ware Engineering Ins9tute by Donald Firesmith in 2013. While this is an older
ar9cle, it is s9ll relevant as it discusses tes9ng of so+ware in development. This relates to the
SWEBoK (So+ware Engineering Body of Knowledge).

The V Model is a simple variant of the tradi9onal waterfall methodology of system or so+ware
development. The V model builds on the waterfall model by emphasizing verifica9on and valida9on.

The V model takes the bohom half of the waterfall model and bends it upward into the form of a V,
so that the ac9vi9es on the right verify or validate the work products of the ac9vity on the le+. More
specifically, the le+ side of the V represents the analysis ac9vi9es that decompose the users' needs
into small, manageable pieces, while the right side of the V shows the corresponding synthesis
ac9vi9es that aggregate (and test) these pieces into a system that meets the users' needs.

When programmers apply a V model to the Agile Development of a large, complex system, however,
they encounter some poten9al complica9ons that require more than a simple collec9on of small V
models including the following:

§ The architecturally significant requirements and associated architecture must be engineered

and stabilized as rapidly as is prac9cal. All subsequent increments depend on the
architecture, which becomes hard--and expensive--to modify a+er the ini9al increments
have been based on it.

§ Mul9ple, cross-func9onal agile teams will be working on different components and

subsystems simultaneously, so their increments must be coordinated across teams to
produce consistent, testable components and subsystems that can be integrated and
released.

ShiY LeY Tes&ng: 4 Types

Four Types of Shi+ Le+ Tes9ng: featuring Donald Firesmith as Interviewed by Suzanne Miller
hhps://resources.sei.cmu.edu/asset_files/Podcast/2015_016_100_447147.pdf

SYNOPSIS
In these podcast notes, Donald Firesmith, author of the “V Model for Tes9ng” ar9cle above states:
 We need to recognize that Shi0-le0 tes4ng is essen4ally moving tes4ng to the le0 on the
development lifecycle, le0 on the project 4meline.

Therefore, what we are doing here is moving tes9ng earlier, so that we are not wai9ng un9l the
system is produced to start tes9ng it. So, we are star9ng to do much more in the way of unit tes9ng
and integra9on tes9ng and performing these ac9vi9es much earlier, beginning to do tes9ng at the
very beginning of the project.

We are not just talking about defining the tests at the beginning of the project because that has been
done for years, but we are talking about execu9ng tests at the beginning of the project.

In the past, the le+ side of the V was there for planning and doing some ini9al prepara9on work. You
might actually develop some test cases early on, but you weren’t actually tes9ng anything because,
back in those days, there was nothing really to test at that point in 9me.

Shi+-le+ tes9ng is based on other trends in the so+ware development world, which has moved a lot
of the rest of the development effort earlier in the project. We started doing detailed design work
earlier. We started doing implementa9on earlier. We started doing integra9on earlier and, therefore,
we had something that we could start tes9ng much earlier.

Why does it maher? Why does shi+-le+ tes9ng maher? What are its benefits, and are they are any
drawbacks to this approach?

The benefits of shi+-le+ tes9ng include things like the testers become involved earlier in the
development process. That makes it more likely that tes9ng is going to get integrated with the rest of
the development process, and it is also going to make it more likely that tes9ng receives the
resources it needs to get done properly. Tes9ng executable models can be used to iden9fy mistakes
in the requirements, the architecture, and the design. This is done then before significant efforts
have been wasted in implemen9ng these in so+ware and hardware.

Notes: Requirement modelling is conceptualising user and

other corporate governance requirements into so+ware
design, as discrete funcFonal and embedded non-funcFonal
capabili9es. Then these concept models are detailed into
logical design models, independent of compu9ng pla]orm
choices. Once a compu9ng pla]orm is decided, these logical
design artefacts are translated into physical design artefacts
that are implemented in computer-code.

• These design artefacts, regardless of whether they depict conceptual, logical or physical design-
views of so+ware capabili9es are usually expressed in three common so+ware capability
perspec9ves:
• Process models that characterises the dynamic processing behaviours of so+ware
• Data models that define the database storage (and some9mes content-contexts) structures of
data resources
• UX/UD models eg Graphic User Interface (GUI) model, which describe the user-computer-
interfaces in terms of display-layout, useability and service experiences

Today’s trend on UX/UD aspects of so+ware has led some to believe service design is everything and
fixes the user problems in so+ware development. Over simplifying user requirement modelling and
transla9on to so+ware design artefacts to UX/UD models is erroneous for holis9c so+ware design.
This is because service experience is not a just a consequence of so+ware usability and experience
effects but is also influenced by the func9onal and non-func9onal capabili9es of the so+ware in
capturing, valida9ng, processing, storing and presen9ng data resources for different human ac9vity-
driven purposes. Shi0 Le0 principles in so+ware tes9ng today only assure that the func9onal and
non-func9onal capabili9es (the hard requirements) of so+ware-applica9ons are fit for purpose, while
the UX/UD capabili9es (the so+ requirements) may con9nue to delight and/or irate the human
experience when using these func9onal and non-func9onal capabili9es. Future psychology
techniques are yet to evolve for detec9ng social engineering in human-machine interac9ons, but this
is yet to be covered in today’s Shi+-Le+ paradigms.