Technological University: Secure App Development Report (Module XYZ)

This report analyzes the secure development lifecycle for a social media application, focusing on the specific needs of a university environment. The report begins with an executive summary and overview of the Secure Development Lifecycle (SDL) and its importance in building secure software. It details applicable principles for web security, including authentication, authorization, confidentiality, integrity, availability, accountability, and non-repudiation. The report then delves into web application security, including policy frameworks (COBIT, ISO 27002, and Sarbanes-Oxley), authentication methods, and best practices for password management and sensitive data storage. It covers vulnerability analysis, access control, session management, and data validation techniques. Furthermore, the report examines vulnerability and assessment testing, including VAPT, and applies these principles to the context of a banking application, highlighting the steps required for secure development. Finally, the report outlines the steps for banking app developers, including security requirements, attack surface analysis, threat modeling, security testing, and data retention and disposal. The conclusion summarizes the key findings and emphasizes the importance of a proactive approach to security throughout the development lifecycle.

Table of Contents
Executive Summary 2
Overview 3
Applicable principles for web security 3
Web application security 5
Policy framework 5
Web application authentication 6
Access control and authentication 8
Session management 9
Data Validation 9
Vulnerability and Assessment testing 9
Overview of the application 11
Steps for banking app developer 12
1. Security requirement establishment 12
2. Attack surface analysis 12
3. Threat modeling implementation 12
4. Perform static analysis security testing 13
5. Interactive application security testing operation 13
6. Security gate creation 13
7. Ongoing source development education introduction 14
Overview of secure SDL 15
SDL Design 15
Security Requirements 16
Security Awareness and training 16
Threat modeling 17
Software tracking by third-party 18

Secure build18
QA and security testing 19
Data Retention and Disposal 21
Conclusion 22
Appendices 23
References 24

EXECUTIVE SUMMARY
The project elaborates about the details for the secure development of the application,
following a suitable Secure Development Lifecycle model, e.g. Microsoft SDL. It includes
several terms which are utilized in this report findings are shown below as:
• Strategies/ Policy structure
• Corroboration
• Authorisation/ Approach authority
• Time administration
• Facts authorization
• Vulnerability assessment and testing
• Recording

OVERVIEW
SDLC is the main pillar of the secure software pillars network, which can also be termed as
the security development lifecycles. The meaning of the pillar is related to the important
activities which provide the assurance for securing the software here. SDL can also be
elaborated as the procedure for submerging reliability artefacts in the whole application
cycles. These SDL occurrences must be plotted to a general software development lifecycle
(SDLC) either by using the agile or the waterfall procedure. There are several interests for the
SDL ventures which are approximated numerous but two main benefits are:
 Build buy-in.
 Security by default.
Software development lifecycle elaborates the several stages that an application results which
go through from starting to close of its existence. There are various SDLCs which subsist in
the company’s recently and these organizations are unbound to explain the phases. SDLC not
at most useful to the application straight delivered to the clients, but it is also applicable to IT
and to software as a service (SaaS) projects. (dzone.com, 2019)
The development methodologies such as Agile, CD and Lean and others need to rethink the
subsisting SDLCs and promising the accommodations. For instance, a group with the active
habitat may have the ensuing movement:
Figure.1 SDLC Phases and activities
Applicable principles for web security:
Web security is totally based on the 7 principles which are elaborated below: (Spacey, 2011)

1. Authentication:
Applicable in user’s identity confirmation
2. Authorization:
Applicable in specification for accessing rights to resources
3. Confidentiality:
Information disclosure prevention for the unauthorized systems
4. Information Probity:
Information cannot be bribed without observation
5. Opportunity:
Websites must be available and fast.
6. Accountability:
When the system accesses the data their action must be traceable, for instance:
logging.
7. Abrogation:
This is the capacity for proving that the agreement took place such as: electronic
receipts.
Web application security
Policy Frame work:
Figure.2 Policy Framework

Organizations require establishing data protection strategy illuminated by the pertinent
national prescription; merchant agreement, company directive, and subordinate top practices
for instance OWASP. (Owasp.org, 2020)
a. COBIT:
It is a famous probability administration substructure constructed around four provinces such
as:
 Organization and Planning
 Delivery and related support
 Execution and Acquisition
 Visualizing
b. ISO 27002:
It is a probability formed data safety administration substructure which is straight obtained by
the BS 7799 levels. It is an intercontinental level and utilized steadily for all the organization.
Nevertheless, Little US companies utilize ISO 27002 as well, especially if they have the
branches exterior US.
c. Sarbanes-Oxley:
The main creator for several US companies in embracing the OWASP commands is to help
with the on-going Sarbanes-Oxley agreement. If a company accompanied each authority, it
would not instinctively allow the company SOX agreement. Hence, the evolution lead is
functional as an acceptable application authority accession and in-house evolution as a bit of
huge agreement scheme.
Web application authentication:
There are 6 web authentications which are elaborated below: (Killoran, 2018)
1. Create a Web Application Authentication Checklist:
The checklist must include four major steps such as:
 Data gathering
 Course of action plan
 Security check execution

 Major issues remedies
2. Update and security of passwords:
Figure.3 Passwords do’s and Dont’s
There are many issues with passwords which are annoyance for customers to control it:
 Uncomplicated for estimate physically or by utilizing the automatic instruments
 The countersigns which are user generated follow the pattern often for making easy to
compromise.
 Similar credentials are applicable for protecting the different accounts.
 Not stored in the correct way.
3. Sensitive data storage separation from the regular data:
Several protection authorities propose data classification into three types:
 Some tactful data that could place the organization and its customer at the greater
possibility must be examined confined information. This data must at most be
constructed present on secretive manner.

 Personal information is data that is tactful but quite requires to be retrieved by the
whole division. For example: customers’ home addresses must still support a extent of
seclusion but might be applicable to the merchandise group.
 Lastly the general information is a non-delicate data which shows minimum
possibility to the work. This data is normally attainable for anybody in the work as
well as at intervals publically shown as the people’s identity or the public network
account.
Figure.4 document security feature levels
4. Web applications vulnerabilities analysis:
There are few questions which are required to investigate for web applications
vulnerabilities analysis as mentioned below:
 Does the website use non-password login? If it is not, does the two factor
authentication for account protection?
 Are there limited login attempts for hacks prevention from attempting the
brute-force attack?
 Does the application allow the user authorization for other application to
information access?
5. Test the web applications authentications based on the lower permission:

It is common issue for operators to utilize low- level accounts as an arrival end into
the application’s under structure as long as these descriptions are having some
features such as:
 These are frequently slighter done up and having fragile countersign.
 These accounts hold upper level permission that not at all modernizes.
 These are not maintained as high-level accounts.
Once it make sure that the low level accounts are protected then it is possible to move on the
high level accounts for assuring that the security measures stands strong with no matter.
6. Web application Firewall applications:
The rearmost web application corroboration good practices can endorse to the organizations
is to utilize a request firewall throughout the whole procedure. The applications managing by
the test and implementations changes could take much time through all the main threats. It is
essential that the team must be vigilant in applications monitoring for any threat. Hence it is
required to use WAF for threat protection. Fundamentally, some congestion scattered any
WAF is choked if it is spiteful and it can generate practice regulation to additionally
implementation protection.
Access control and authentication:
The ideology of access control is mandatory and critical design component for any of the
application’s security. Generally, a web application must prevent the front-end and the back-
end information and the system assets by access control boundaries implementation on what
client can do, which assets access must provide, and what operations are allowed for
performing the data. In ideal case, n access control idea must protect against the unauthorized
reviewing, modifications or the data copying. In addition, access control methodology can
also support for restricting the malicious code simulation, or unauthorized activity by an
attacker exploiting the architecture dependencies such as(DNS server, ACE server, etc.).
(Cgisecurity.com, 2020)
Session management:
Web session management is the ideology which permits the web server for exchanging state
data to identify and track each user connection. It is generally user authentication and the
preference management for example the history storing for previously visited contexts and

the level data. Most commonly example for the session oriented systems are the web based
apps which require to maintaining the user specific data. The general pattern of the web based
session management is to authenticate the user to the web server with the login credential at
once and to set the formal sessions. By this manner, the user does not require to send the
identity and passwords to the web server for each request. (Pdfs.semanticscholar.org, 2011)
Data Validation:
SDV or the semantic data validation is implemented in Java Servlet and Java and the filters.
The web servers utilized are Apache 1.3.20 running on MS Windows Server 2003, and
Apache Tomcat 5.01. As far as the operation will be concerned, the SDV prototype service
could be able to secure infinite number of application attacks.
The prototype service implementation of this service involves three main elements: HTTP
Interceptor, RDF parser, and Data validator. Initially HTTP interceptor takes benefit of the
term that the browser appeals are directed at both a certain host and the port. In this working,
the Tomcat server listens on port 8081. The utility review the browser appeal on the default
port 80 and it redirects to Tomcat. The outcomes coming to this ideology are not transferred
to the client on port 80. The HTTP interceptor is a multi-threaded java application for
handling the concurrent connections by utilizing multi threads that enhances the flexibility or
power of the web server and client programs majorly.
Vulnerability and Assessment testing:
VAPT and Vulnerability assessment and Penetration Testing are two categories of
vulnerability testing. The tests have several strengths and are often combined for achieving
the more complex vulnerability observation. In short, Vulnerability Assessments and
Penetration Testing perform two different works usually with different outcomes, within the
same concentrative region.
Vulnerability assessment equipment vulnerabilities are available, but they do not differentiate
between the flaws which can be exploited to damage and those that cannot. Vulnerability
scanners alert companies to the pre-existing flaws in their code and where they are
located. Penetration tests attempt to exploit the vulnerabilities in a system to determine
whether unauthorized access or other malicious activity is possible and identify which flaws
pose a threat to the application.

OVERVIEW OF THE APPLICATION
Banking has gone digital in today’s timing. Approximately all major banks offer both an
online portal and the mobile app as well. The people seem prefer both in this way. A recent
survey named as PWC study established that 46% of the users at most utilize online banking
and a huge leap from the preceding literature such as in 2012, in which at most 27% utilized
online banking entirely. (Checkmarx, 2018)
Figure.5 Digital banking Graph
The major issue was found as the flaw pertaining is proof restraining, which signified that the
observations were shortcoming for detecting the important destructibility that could permit
striker take command on the sufferer’s online banking. Its security issues like mentioned
above shows the importance of covering these topics at the time of digital bank app
development. Hence conducting additional obtains for the monetary organizations; digital
banking also conveys a lot of risks.
For SDLC development, it is a quite critical to be pursued evolution of the fixed applications.
The SDLC will emplacement of a methodology for developing the certain protection is
constructing into the result, without decelerating the evolution procedure downwards. Now

there are 7 censorious stairs which are required for SDLC that designers and the protection
groups should tasks jointly for ensuring the releasing the online protection or the mobile
banking app.
Steps for banking app developers:
1. Security Requirements establishments:
The initial move is to learn the certainty needs of the banking app. Due to the tactful essence
for the banking apps, it is essential to allocate at the minimum one associate of the protection
group to effort with the construction group and the association requires beginning prior to the
management done.
Throughout this SDLC bit, management and security must know the main security risks
within the software which includes the standard the program should pursue. The collaborator
from twain of the security and development groups should be known to check transmission is
intelligible from the arrival, and some chinks in the procedure must be eminent.
2. Attack surface analysis:
Some banking software will occur with risk regions, which can refer as the charge exterior.
This charge exterior OWASP writes is assembled with:
 The volume for entire information and the instruction paths into and out of these
applications.
 The coding protects the paths.
 All the valuable data must be used in the applications which include the keys and the
secrets, analytic work facts, intellectual property, confidential information and PII.
 The coding secures the data.
There are several organizations which have come up with methodologies for charge exterior
quantifying. Microsoft’s Michael Howard has implemented a respective charge exterior
computation, and the investigators at Carnegie Mellon have implemented the charge exterior
grade. It can be obliging for begin by utilising one of these ideas term simulating one that
operates finest for the company.

The charge exterior analysis is a composite bit for protecting some implementations, due to
its points the most censorious and the possibility endangered regions of the code for ensuring
that the system is protected at the time of development and testing.
3. threat modelling implementation:
The upcoming move in fixed SDLC is to carry out the warning modelling. Threat modelling
supports the developer for learn which security control is needed for the app to farther make
sure the protection is construct in from the beginning. The threat modelling procedure
requires elaboration which assets require to be save, the appearance and entrance ends at
which these assets could be acquired and mitigation strategies evolution for every warning
once they’ve been prioritized.
The connection betwixt the attack surface observation and threat modelling is quite closed,
and it means that some attack surface changes will need threat modelling, and that threat
modelling supports collaborator finer learn the attack surface.
4. Perform static analysis security testing:
The fixed investigation protection testing tests the auto flow of an appeal for detecting the
censorious destructibility. The proceed level SAST equipment do this in automatic manner by
protecting the ode for its root, and can be modified in the present stages of the development
process. This SAST testing is an essential part of the SDLC due to this it detects flaws as well
before the applications goes into the production which means the bugs can be found and fixed
where it’s both easiest and cheapest to do so. SAST operates by pointing the developers to
the specific regions in the code where the issues are present.
5. Interactive application security testing operations:
Whereas SAST interacts with the code of IAST, the nest step is to protect the SDLC which
test on the live version of the software. In essence, whereas SAST is the security person who
ensure the secure code and IAST is a hacker which works to getting the access in the app
areas it’s not supposed to be able to. IAST does not need a deep application understanding.
Only looking at if it is vulnerable and how that vulnerability can be exploited.
6. Security gate creation:

However the most essential part for SDLC is to make sure that the software with high and
medium vulnerability flaws doesn’t make it productive. Microsoft’s SDL procedure refers to
security gates which termed as ‘bug bars’, but the ideology is similar. Security gates establish
a minimum level of the security and the code is checked for the high risk vulnerabilities. Any
code marked as the high risk should be sent back to the developers for fixing the
implementation. These checks are best implemented while still under development by using
the static analysis testing, as a platform like CxSAST can automatically detect these
vulnerabilities while the developers are still processing the code for supporting the fix at its
source position.
7. On-going source development education introduction:
However it is not the part of the traditional SDLC, developer learning is a part of the secure
SDLC. Developer training is quickly enhancing ground in protection development
organizations due to its effectiveness in turning the developers who know small to nothing
about the protection into secure developers who consider security at each turn. Especially in
the high sensitive environment such as the banking app, having developers who learn the
security procedure will go far in faster releasing secure software.

OVERVIEW OF THE SECURE SDL
Figure.6 SDLC Process
For SDL implementation in a better way as the software development cycle can look like the
following figure as shown below:
Figure.7 Software development cycle
SDL Design
SDL design or the preparation must address the following issues:

1. What are the major security aims needed by the software in CIA terms such as
integrity, availability and confidentiality?
2. What are the policies and regulation that are required to be followed?
3. What are the environment’s possible threats?
During SDL design operation, concentrates on the following deliverables:
 SDLC security milestones
 Security needs gathered by customers, standards and regulations.
 Needed certifications
 Training needed
 Risk assessments
 Third party software requirements.
 Key security resources (security team etc.)
 SDL assets
 Security metrics
 PIA.
Security Requirements
Security requirements must be considered at the timing of early cycle such as planning by the
project managers.
The security requirement is the list that each product should comply with. Security
requirements example should include:
 Only approved cryptography.
 Inputs sanitizations.
 Not utilizing backdoors.
 Approved library usage.
 Usage of multifactor authentication etc.
Security Awareness and training
Security awareness and training must be provided preferably at the early stages timing by
everyone.
Security training:

The goals of the security trainings are to raise the developer’s security knowledge, designers,
architects and the quality assurance. On other side, the aim is to encourage the protection
mind set for all the stakeholders.
Security trainings target QA, architects, designers and the developers. These can cover the
aspects such as: SDL, secure design principles and the common protection issues, and also
address some of the coding pitfalls for example: neglecting buffer overflows and Java coding
etc.
Security awareness programs:
These programs targeted as everybody must involve in this project due to the software
security as a responsibility of everyone. Program must require a technical background and it
may also include the topics like Integrity, Availability and confidentiality. There are various
lessons which must be followed such as threat understanding, risk management and its
impacts, and SDL understanding.
Threat modelling
Threat modelling must be considered at the planning time by project managers. The goals of
threat modelling is to identify and manage the threats earlier in the secure development
lifecycle and plan for the proper mitigations due to the cost remediation issues on it is much
lower than the later cycle.
It also helps in architecture validation with the development team and forces the team to look
at the security architecture and privacy perspective. There are four steps for threat modelling:
1. Prepare:
Architecture diagram creation
2. Analyse:
STRIDE model mapping
3. Mitigations determinations:
Mitigation description

4. Validation:
Retrospective activity execution
Threat modelling can also have the several ideologies, such as:
Design-centric: applicable in system design
Attacker-centric: weaknesses explosion
Asset-centric: specific things protection
Threat modelling must be done at planning phase in earlier and the updated later during the
development.
Software tracking by third-party
The software tracking must be considered on priority basis as soon as possible by the
technical lead.
Leveraging third-party software must also introduce the additional risk which requires to be
mitigated. This third-party software can be applicable for both the commercial use and open
source. The project team requires keeping an inventory for all third party tools utilized in the
project, as this will help for ensuring all the tools used in the project which have the latest
security patches.
The inventory must be done as soon as possible in the development cycle. Monitoring
vulnerabilities have to be done by the senior technical member for understanding the
vulnerabilities and the technical lead for coordinating the security patches deployment.
Secure build
 Security design review:
The review for the security design must be done at the timing of design and
implementation by the development team. The aim of the security design review is to
build the most secure flags.

Security design applies to an individual features created by the development team.
These features can correspond to the respective user stories. The security plan review
can be done at the similar timing of functional feature design.
 Peer code review:
The peer code review must be done at the time of implementation by the development
team. The aim of that peer code review is to make sure that the software has built with
the most protected flags.
Security checks must be the part of the code review. These can be done by the
training developers on the common coding protection pitfalls and providing the secure
coding checklist.
The examples for that security code review checks must include the following:
 Are essential security events logged it?
 If the authentication is needed, can it be by passé?
 Does the software dump user’s passwords available in the logs?
 Is the user input properly validated?
 Does the software properly release the sources such as memory, system handles and
the ports that aren’t require anymore?
QA and security testing
In the software development cycle, the code review and QA mostly concentrated on being
operational to make sure that the software is doing what it is expected to do. Nevertheless,
security testing elaborates testing with a hacker’s perspective.
a. Static Analysis:
The static analysis must be done at the timing of testing and development by QA,
developers and the security expert. Static application security testing or SA is the
investigation of the software which is performed without executing the programs. It
can be operated on the source code and on the object code. SA is the white box testing
procedure that has full access to the possible behaviours of the software.
Some of the benefits include:

 Can identify the exact locations of weaknesses.
 Allows the quick fixes
 Minimizes entire project value by finding weaknesses earlier
 Can be done by the QA engineer for code understanding.
b. Dynamic Analysis:
The dynamic analysis must be done during testing and development by QA,
developers and the security expert.
DA is the software investigation which is done by the program execution on the real
and the virtual processor in the real tie. The aim is to find the security errors in the
program when it’s running. It can also support for ensuring the functionality on the
program operates as planned. There are several advantages of DA testing which are
elaborated below:
 Can find the configurations, infrastructure and the patch errors that SA tools
can miss.
 Identifies the vulnerabilities in the runtime environment
 Findings validation from SA tests
 Can be implemented on any application written in any of the language.
c. Vulnerability scanning:
This vulnerability scanning must be done at the timing of development and the testing
by QA, security experts and the developers.
Vulnerability scanning tools are applicable against the running software. The tools
generally operate by injecting “malicious” inputs and investigating how the software
handles them. These kinds of tools are mostly utilized to scan the applications with a
web interface including SOAP APIs and REST. Vulnerabilities like XSS, SQL
injections and the poor session management can be investigated during these scans.
d. Fuzzing:
Fuzzing must be done towards end of development and during the testing phase by the
security expert, QA and developers.

Fuzzing is a black box testing technique which involves providing the invalid random
unexpected data into the program. The aim is to test how well protocols and file
formats are managed. In simple language, Fuzzing finds the security bugs and flaws
by utilizing malformed data injection.
e. Third Party penetration Testing:
Third party penetration testing must be done at the end of the testing and the
development phase by third party certifies pen tester.
It is a security investigation in which the tester simulates the hacker’s action. The aim
is to discover coding errors, system configuration error and to uncover the exploitable
vulnerabilities and validate security features.
Data Retention and Disposal
The data disposal must be done at the end of the product’s life by the developer or the data
expert.
There are several goals for the data disposal. They can vary from an old product that is no
longer required, to no further data usage, a defective product or no legal right for retaining the
data. One of the most applicable practices is “crypto-shredding” as the act of overwriting or
deleting the encryption keys. Getting rid of this data is a big challenge when there is a
concern about the information confidentiality. For make sure that the data has deleted
properly or overwritten is an essential part of SDLC. (Chopra and Madan, 2015)
Conclusion
This investigation reflects that real-life security practices pointed as the best practices which
are introduced in literature. The best practices are generally ignored due to avoiding the
compliances which increase the group burden. In their review, teams are constructing for
making the reasonable cost beneficial trade which avoids the designers blame, this prediction
elaborates that the issues enhances in the organization’s hierarchy. The outcomes show the
requirement for the light weighted best practices that take into the realities and the

development pressure. It can also conclude the additional automation for the secure
programming practices to ease the burden without security sacrificing. (Assal and Chiasson,
2018)
Appendices
Figure.1 SDLC Phases and activities
Figure.2 Policy Framework
Figure.3 Passwords do’s and Dont’s
Figure.4 document security feature levels
Figure.5 Digital banking Graph
Figure.6 SDLC Process
Figure.7 Software development cycle

References
dzone.com. (2019). How to Approach Security Development Lifecycle (SDL) - DZone
Security. [online] Available at: https://dzone.com/articles/how-to-approach-security-
development-lifecycle-sdl [Accessed 4 Jan. 2020].
Checkmarx. (2018). How Secure is Your Online Banking App? 7 Steps for Banking App
Developers. [online] Available at: https://www.checkmarx.com/blog/secure-online-banking-
app/ [Accessed 4 Jan. 2020].
Assal, H. and Chiasson, S. (2018). Security in the Software Development Lifecycle. USENIX
Association, [online] pp.281-296. Available at:
https://www.usenix.org/system/files/conference/soups2018/soups2018-assal.pdf [Accessed 4
Jan. 2020].
Chopra, R. and Madan, S. (2015). Security During Secure Software Development Life Cycle
(SSDLC). International Journal of Engineering Technology, Management and Applied
Sciences, [online] 3, pp.1-4. Available at:
http://www.ijetmas.com/admin/resources/project/paper/f201509231443005088.pdf [Accessed
4 Jan. 2020].
Spacey, J. (2011). The 8 Principles Of Web Security. [online] Simplicable. Available at:
https://arch.simplicable.com/arch/new/the-8-principles-of-web-security [Accessed 6 Jan.
2020].
Owasp.org. (2020). Policy Frameworks - OWASP. [online] Available at:
https://www.owasp.org/index.php/Policy_Frameworks [Accessed 6 Jan. 2020].

Killoran, J. (2018). Top 6 Secure Web Application Authentication Best Practices. [online]
Swoop Two-Factor. Available at: https://swoopnow.com/web-application-authentication-
best-practices/ [Accessed 6 Jan. 2020].
Cgisecurity.com. (2020). Chapter�8.�Access Control and Authorization. [online]
Available at: https://www.cgisecurity.com/owasp/html/ch08.html [Accessed 6 Jan. 2020].
Pdfs.semanticscholar.org. (2011). [online] Available at:
https://pdfs.semanticscholar.org/2524/b9c8239cfce01371454c1e1840c48654c97d.pdf
[Accessed 6 Jan. 2020].