A Survey and Comparison of Secure Software

Development Standards
2020 13th CMI Conference on Cybersecurity and Privacy (CMI) - Digital Transformation - Potentials and Challenges | 978-1-7281-9056-3/20/$31.00 ©2020 IEEE | DOI: 10.1109/CMI51275.2020.9322704

Armando Ramirez Anthony Aiello Susan J Lincke

Computer Science Department Computer Science Department Computer Science Department
University of Wisconsin-Parkside University of Wisconsin-Parkside University of Wisconsin-Parkside
Kenosha, WI, USA Kenosha, WI, USA Kenosha, WI, USA
[email protected] [email protected] [email protected]

Abstract—There are standards, guidelines, and certifications secure software development. In this paper, we introduce a
for software security to help guide software development few of the most popular industry standards to compare a set of
projects into becoming more securely written to comply with standards, so that the reader may have access to a quick view
any regulations that may apply to the project. These best and gain an understanding of which guidelines they may
practices and standards include Common Criteria, The Open follow to develop more secure software.
Group Architecture Framework (TOGAF), Security Assurance
Maturity Model (SAMM), Building Security In Maturity Model The scope of our paper focuses on providing a survey of
(BSIMM), Application Security Verification Standard (ASVS), commonly used standards for creating secure software
OWASP, and SAFECode, in addition to the national or applications. We are not aware of other papers that offer a
international standards groups, PCI, NIST and ISO/IEC. In survey, that contrasts coverage areas of these standards. This
this paper, we focus on secure software development by survey is useful if one wishes to comply with standards or
surveying and comparing these methods and standards and produce a more secure software product.
discover which areas of the software development life cycle
SDLC, that one or more could be applied to improve the security II. LITERATURE REVIEW
of a software application during its development lifecycle.
There are many reasons that security standards are ignored
Keywords— security standards, OWASP, CC, TOGAF, by developers during software development. Organizations
SAMM, BSIMM, SAFECode, risk, risk management, risk often have conflicting goals of development speed versus
assessment. security, which discourages the use of secure software
standards or even software development lifecycle standards.
I. INTRODUCTION Gandhi et al. [4] states that through assurance controls and
One of the most important issues and sometimes biggest security standards, we can manage vulnerable software. Geer
challenges for companies is the development of secure suggests simplifying software security technologies to require
software and implementing and managing security in the less time and security expertise [5]. This simplification allows
software development life cycle (SDLC) in order to make for quicker adoption for processes and some technologies such
software more secure and adhere to standards and regulatory as SDLs or maturity models; however, security expertise still
requirements [19] [20] [27]. There exists a set of standards, needs to be a high priority despite the rapid changes required
guidelines, and certifications for software security to help in software and hardware [6] [7]. Aranda et al. [8] suggest
guide secure software development projects. We survey these that small companies rarely implement requirements
to describe the strength of each of these and to provide an techniques that address risk because it demands a radical
overview of where a standard may best be used. This paper change in their processes and increases cost. Our paper
focuses on secure software development and ways to provides engineers with a road map of where to acquire both
incorporate best practices throughout the lifecycle of the simple and complex secure software standards, according to
software product under development. We compare some of their needs.
the most widely used standards, the best practices and It is recognized that there is a need for security standards.
guidelines, through research and literature review. We also Farhan [19] points out the necessity of integrating security
discuss areas of the development process these standards and across the SDLC because traditionally addressing security
guidelines may apply to for a software development project to was part of testing, which found bugs often too late. Second,
become more compliant with its relevant security a good standard is necessary to address a myriad of attacks
requirements and/or regulations. Our goal is to provide a such as SQL injection, command injection, buffer overruns,
survey of a selection of software security standards, as well as cross-site scripting, failure to handle errors, string formatting
to determine popular aspects of risk evaluation. problems, neglecting change control, integer bugs, and poor
Risk analysis literature exists for software design (e.g., usability. Fujdiak [20] recommends a two-pronged approach:
[15]), security requirements (e.g., [16]), and safety standards proactive, which can help prevent, and reactive, which can
(e.g., [17]); however, we are curious about which secure help discover faults. Implementation of security standards can
software development processes are adopted within industry help to raise the quality of security in a software product and
security standards. Virtually no literature exists to date, listing address these issues.
and comparing many of the existing industry standards for

978-1-7281-9056-3/20/$31.00 ©2020 IEEE

Authorized licensed use limited to: Carleton University. Downloaded on June 02,2021 at 13:10:02 UTC from IEEE Xplore. Restrictions apply.
 Research in many cases recommends security standards, TABLE I. SAMPLE OF STANDARDS AND THEIR
APPLICATIONS
without offering a description of the standards. Fujdiak [20]
recommends a secure software development lifecycle Standard Application
(SSDLC) where each development phase adds in security
62443-4-1 - Software in industrial control systems
considerations. They suggest adhering to the standards set
27034 – Application security standard – aviation, defense,
from OWASP, ISO/IEC, and NIST but do not contrast financial, medical
standards to use for different phases of a SSDLC and do not 27034-3 Application management process
provide coverage to the standards they recommend. Geer 27034-4 Application security validation
introduces different security standards in achieving 27034-5 Protocols and application security control data
standardized security implementations including BSIMM or structure
SAMM [5]. While these papers recommend security ISO/IEC 61508 - Automated systems functional safety
61508-3 - Software requirements for 61508 Standards
standards, none of these papers provide a survey of available
26262 – Auto industry safety & security standards
secure software standards. 27002:2013 - Organizational security guidelines
Shan et al. [22] reports the results of a questionnaire 15026 - Assurance cases for software and systems
41062:2019-2 - Software acquisition standards
among industry sectors and found two standards that are most 62304 – Medical device SDLC requirements
applied in industry, ISO 2700X, and and for security analysis framework/regulations
methodologies, Common Criteria (ISO 15408). They also 15408 – Common Criteria computer security certification
provide a valuable table of standards that are used for specific 800-37 - Risk Management Framework
sectors of industry. While they provide survey results of 800-53 - Federal Information Security Management Act,
commonly used standards, they do not contrast or compare NIST FISMA Requirements
SP 800-128 - Security: Configuration Management of
these standards. Information Systems
Some papers have used one or more standards during their MISRA - Motor Industry Software Reliability Association C/C++
C/C++ Secure software
development. Popić [27] recognizes that two of the biggest PCI Security Standards Payment Application Data
challenges in the software industry are software quality, and PA-DSS
Security Standard [30]
software security, and discusses the MISRA-C standard, Maturity SAMM – Security Assurance Maturity Model [9]
which focuses on the safe use of the C programming language Models BSIMM - Building Security In Maturity Model [12]
in critical systems. Jefcoat [18] created a file erasing tool that TOGAF - The Open Group Architecture Framework [14]
became certified by Common Criteria. Farhan [19] Design, CC - Common Criteria [13]
recommends NIST 800-64 for the SDLC and comments that Code, OWASP Application Security Verification Standard
Test ASVS [10]
OWASP – CLASP is simple and easy to implement. While SANS Institute
these papers describe a singular or a pair of standards, they do
not contrast them.
SAMM defines this standard as “open framework to help
We also considered research related to software risk organizations formulate and implement a strategy for software
analysis and standards. Risk analysis literature exists for security” [9], and BSIMM defines it as “a reflection of the
software design (e.g., [15]), security requirements (e.g., [16]), current state of software security” where their primary aim is
and safety standards (e.g., [17]); however, we are curious to “wider software security community plan, carry out, and
which risk analysis processes are adopted within industry measure initiatives of their own” [12]. SAMM and BSIMM
security standards. In this paper, we contrast risk both define four categories called ‘business functions’ and
recommendations by these standards. ‘domains’ respectively, where each category is further defined
We evaluate standards related to maturity models, secure into three practices. Both models also define three maturity
software development and international standards. We hope levels, but SAMM has an additional implicit starting point at
readers find our paper helpful in finding security standard(s) zero where activities have not been started.
and source(s) that suit their needs. The practices and activities presented in these models
III. SURVEY OF STANDARDS differ slightly in the approach that each model takes to achieve
a higher maturity level. For example, SAMM presents the
In this section, we perform a survey and comparison of activities along with the measurement of performance,
security standards for software development and describe a associated assurance benefits, personnel involved, and costs.
few of the different security standards listed in Table 1. Here On the other hand, BSIMM presents the security activities
we provide an overview of some of the most popular software along with the people involved and performance
standards used in industry from a general perspective. measurement.
A. Maturity Models B. Industry Groups for Software Development: Design,
Maturity models help organizations introduce and evolve Code, Test Models
their software security process in a guided step-by-step Some standards emphasize these stages in detail: design,
manner. We examine the following maturity models, which code and test, while still requiring aspects of security
are open community projects, and widely used in the IT requirements. Coding and design standards define how
industry: Building Security In Maturity Model (BSIMM) and security requirements should be included into the software
Security Assurance Maturity Model (SAMM). These development process. The requirements include security
documents provide an overview by listing but not describing goals, purpose, target audience, regulations, and policies.
processes in detail. Testing of software helps to verify and achieve effectiveness
for newly integrated requirements. In this section, we
introduce the following standards that are used in the private

Authorized licensed use limited to: Carleton University. Downloaded on June 02,2021 at 13:10:02 UTC from IEEE Xplore. Restrictions apply.
and public sectors: CC, TOGAF, ASVS, SAFECode, NIST, (CWE) references to strengthen security discussions,
and ISO/IEC. descriptions, identification, and implementation.
1) Common Criteria 4) Application Security Verification Standards (OWASP
Common Criteria (CC) is now an international standards ASVS)
framework (ISO/IEC 15408) for certifications in computer OWASP Open Web Application Security Project
security. It originated from a combination of regulations and foundation is a non-profit organization that supplies
standards mainly from three places, TCSEC – US DOD NIST developers with current standards for secure coding practices.
[21], CTCPEC – Canada & US, and ITSEC – European OWASP’s ASVS is an open community security standard
standards from the early 1990s. CC is a standard that used to normalize security controls during software
“provides a common set of requirements for security requirements, design, development, and testing [10]. For
functionality of IT products [such as hardware, software, requirements, an activity checklist supports the following
and/or firmware] and for assurance measures applied to these security verification levels: level 1 is meant for all software,
IT products during a security evaluation” [13]. Moreover, CC level 2 is for applications that contain sensitive data, and level
introduces two specifications, which contribute to CC’s 3 is for the most critical applications. A quick reference guide
flexibility in usage: Security Targets (STs) and Protection gives users detailed actions to take during the development
Profiles (PPs). ST and PP specifications allow creation of a and coding processes of building an application. This
high-level of abstraction guideline that define threats, standard also has a list of testing tools: OWASP Mobile
problems, and security requirements. These specifications are Security Testing Guide (MSTG) for both Android and iOS is
not meant to have detailed description or a long description of a security model listing security requirements, and a base
detail operation. For this reason, CC encourages readers to use template for setting up automated testing for mobile
other security standards in conjunction for a more effective applications. Included is a set of insecure apps called a
way to manage risks and facilitate future security evaluations Hacking Playground that demonstrates the vulnerabilities they
by the organizations. discuss [10].
Vendors who certify products using Common Criteria C. Standards Institutes
assure that these products went through a strict standard Standards institutes tend to focus on specific industries
process of specification and evaluation. These are high quality that have detailed security needs. These needs impact
guarantees from these certified products. CC is used as a base software development in security requirements and testing.
for government certification. The Common Criteria
Recognition Arrangement is an international agreement made 1) National Institute of Standards and Technology (NIST)
up of Common Criteria and Common Methodology for IT The National Institute of Standards and Technology
Security Evaluation (CEM), respectively. Each country uses (NIST) is a department of the US government that has a very
their own processes to certify, and member countries large set of regulations, guidelines, and rules about software
certifications are acknowledged after they have been development and security, that are continually updated and
evaluated by a collaborative Protection Panel (cPP). Goals published. There are vast amounts of free documents that are
include to improve security enhanced products and their guidelines of best practices that are used for integrated control
availability, and ensure that these evaluations are done to the systems (ICS), which include supervisory control and data
highest standards consistently. Each product evaluation acquisition (SCADA), distributed control systems (DCS), as
results in an Evaluation Assurance Level (EAL) between 1 well as many other areas of industry. These systems are found
and 7. Lastly, the guidance of operation section provides in such industries as oil, gas, chemical, electric, water,
examples of tests and guidance in developing tests that can be transportation, wastewater, pulp & paper, food and beverage,
tailored for an IT product [18]. and manufacturing. These document best practices to
securing these systems. They also identify known threats,
2) The Open Group Architecture Framework (TOGAF) review system topologies & architectures, and give
TOGAF® is a “proven Enterprise Architecture countermeasures to address these situations. There are
methodology and framework … to improve business regulations (e.g., FISMA) and specific guidelines that
efficiency”. TOGAF® focuses on architecture definition for companies, vendors, and anyone doing business with the US
large-scale interconnected enterprise systems, addressing government must comply and adhere to [21].
business, data, application, and technology domains [14].
TOGAF®’s 30-page document, “Integrating Risk and 2) ISO/IEC
Security within a TOGAF® Enterprise Architecture” [31], The International Organization for Standardization (ISO)
lists security concerns corresponding to each of the four and the International Electrotechnical Commission (IEC) are
different domains and provides guidance for risk committees responsible for developing, promoting, and
management. maintaining standards worldwide for industry, particularly
communications and information technologies as well as sets
3) Software Assurance Forum for Excellence in Code and govern the standards for electric and electronics. While
(SAFECode) many of these standards documents cost a fee, some may be
The practices defined in SAFECode cover a wide variety downloaded for free at [26].
of the software industry needs with the intention to be
implemented into organizations’ SDL [11]. Practices that a) ISO/IEC 15026-2:2011: The standard ISO/IEC 15026-
SAFECode focuses on are in the areas of design, coding, and 2:2011 is part of the 15026 family of standards, and defines
testing. SAFECode enhances the practices by providing the methodology to develop an assurance case for systems and
methods and tools for organizations to receive guidance and software, which is one or more claim(s) about that product
feedback. They also have Common Weakness Enumeration supported by evidence, reasoning and justification [23].
Assurance cases are used to support the claims in areas such
as its software security, reliability, operability, and safety.

Authorized licensed use limited to: Carleton University. Downloaded on June 02,2021 at 13:10:02 UTC from IEEE Xplore. Restrictions apply.
They may also be referred to a specific named case e.g., instructional and training documentation, in areas including
reliability case, maintainability case. This standard is encryption, authentication, logging, information storage,
reviewed every five years and provides an overview about the wireless, network and remote access, and process verification.
elements and requirements needed to develop an assurance
case ant its components such as claim, coverage, argument IV. COMPARATIVE ANALYSIS
characteristics, evidence, associated assumptions, and Table II and III contrast the stages covered by each
justifications that are required. Assurance cases are an standard, as well as the risk management support for each.
important part of the software and systems engineering. An
assurance case can also be applied to safety or security of a A. Developing Processes
software product. The two evaluated maturity models are similar in some of
the activities they present. SAMM and BSIMM models have
b) ISO/IEC 41062: This standard helps those that are a very effective way to measure progress. As shown in Table
acquiring software for their organization. It is a recommended 2, both models have a heavy focus on risk assessment through
practice and comprehensive standard for software acquisition the activities that are required [9] [12]. For instance, abuse
[24], that describes current best practices for acquiring cases are activities recommended in both models that are easy
software systems that are available e.g., software as a service to develop, demonstrate how attacks affect the software, and
(SaaS), off-the-shelf (OTS) software, and custom-developed aid to create a more well-rounded risk assessment. Moreover,
software. Eight steps and twelve checklists are outlined with both models require activities to create threat models for the
detailed actions for acquiring quality software including a specific application and technology. Lastly, the multi-step
planning and acquisition strategy, preparing contract process in these standards allow organizations to start at low
requirements, selecting software vendors, and providing level and reach higher maturity levels using a step-by-step
assurances such as software safety and software information approach with a focus on process improvement.
security assurances.
B. Mature Processes
3) PCI PA-DSS The NIST and ISO standards provide extensive
The Payment Card Industry (PCI) Security Standards documentation for mature organizations or severe
Council, in addition to standardizing how payment cards shall applications. NIST is often compared to ISO 27001, the
be used within business through its Data Security Standard framework for information security management systems,
(PCI DSS), includes a standard for Payment Application Data because of their similarities. Both NIST and ISO publications
Security Standard (PA-DSS). This standard certifies follow a strict structure. ISOs numbering system refers to a
applications that are used to accept and process card base number as a "family" of documents containing sub
payments, particularly for third party use. [30] documents related to specific areas these policies should be
The standard consists of a set of requirements and tests, integrated into. Each publication number and sub-number
which can be used to certify the software by a Payment contains extensive documentation and procedural steps to take
Application Qualified Security Assessor (QSA). Assessors for each stage of the project's development lifecycle. ISO is
perform tests outright and through reviewing required more risk focused while NIST focuses more on security.

TABLE II. STANDARDS COVERAGE BY DEVELOPMENT STAGE

Stage BSIMM SAMM ISO/IEC NIST MISRA ASVS CC TOGAF SANS PA-DSS
Process X X X X X X X X X
Training X X X X X X X X X X
Requirements X X X X X X X
Design X X X X X X
Develop Code X X X X
Test X X X X X X X
Deploy X X X X X X
Review X X X X X X
Certify* Organization Product Person Person Product
*Certification exists for a person (TOGAF, SANS), product (CC, PA-DSS), or organization (ISO 20000)

TABLE III. RISK MANAGEMENT IN SECURITY STANDARDS

Risk Requirements SAMM BSIMM TOGAF CC ASVS SAFE- NIST ISO

Code
Risk Training X X X X
Threat Identification X X X X X X X X
Classification of Data and Software Assets X X X X X
Specified and Detailed Coding Threats X X
Risk Prioritization X X X X X
Baseline Mitigation for Known Risks X X X X
Risk Monitoring X X X

Authorized licensed use limited to: Carleton University. Downloaded on June 02,2021 at 13:10:02 UTC from IEEE Xplore. Restrictions apply.
C. Coding provide general risk guidance OCTAVE may be helpful for
SANS, OWASP, and TOGAF provides specific coding inexperienced users.
examples and known code vulnerabilities and pitfalls to avoid
Classification of data and software assets are
in a few languages and are excellent tools for the developer in
complementary to risk prioritizations because it adds more
understanding how to write secure software applications.
relevance and weight to the risks. Moreover, asset
They are popular tools used for managing common code
classification in software development aids in the threat
vulnerabilities and threats that every developer should have in
identification because organizations can identify more clearly
their knowledge base. ASVS and SAFECode describe
the risks revolving assets and how the organization, users, and
detailed software-oriented threat lists, as opposed to
customers are affected.
emphasizing the risk process [10][11]. Both standards specify
a list of coding practices and requirements that should be An important risk requirement not heavily enforced in
implanted in software (e.g., string and buffer functions, these security standards is baseline mitigation for known risks.
input/output validation, cross site scripting defenses, Establishing a baseline mitigation for known risks enables the
cryptography). The approach that these standards take in users to have their work checked against some of the common
handling risks are somewhat different. ASVS lists a series of risks involved during development but also facilitates the
checkpoints aiding the user to fulfil the requirements that process in identifying risks in future projects. Only TOGAF,
revolve around the application. On the other hand, SAFECode SAMM, and NIST introduce the concept of mitigations for
recommends coding practices and a general approach for known risks.
implementation, but also includes verifications and references
that allow the users to fully understand and mitigate threats. TABLE IV. RISK METHODOLOGY BY STANDARD

D. Testing Standar Risk Methodology Characteristics

Secure development requires control implementation and d
verification. SAFECode and ASVS recommend the following SAMM Multiple-step risk process.
Build and maintain application-specific threat models.
testing techniques to ensure effectiveness of requirements and Develop attacker profile from software architecture.
coding practices: attack surface, fuzz and robustness testing, Develop and maintain abuse-case models per project.
penetration testing, static analysis tools, among others. Evaluate risk from third-party components.
BSIMM focuses on penetration testing, aiding developers to Elaborate threats models with compensating controls.
find problems using testing tools, perform deep-dive analysis, BSIMM Multiple-step process.
Classify and inventory data according to security goals
and customize testing tools. Identify potential attackers.
E. Certification Build attack patterns and abuse-cases.
Create technology-specific attack patterns.
CC offers certification for products that need to meet strict Build and maintain top N possible attacks list.
regulations and compliance, while PA-DSS is a product Create and use automation to mimic attackers.
certification specific to payment card processing. TOGAF Implement testing techniques/tools (penetration test focus)
and SANS certifies individuals and developers for their Includes active team to develop new attack models.
knowledge of secure software development processes CC Generalized risk for IT products.
according to standards. Define protective profiles and security targets.
Identify threats to IT products & operation environment
F. Focus on Risk Processes Enforce security rules, procedures, or guidelines.
Some standards provide guidance on the risk process; TOGAF Generalized risk for projects.
others provide specific threat models applicable to code; yet Define threats based around data, services, unauthorized
use.
others point to external standards for threat models. TOGAF Assess risk based on the risks’ effect and frequency.
provides a general process without a specific model, whereas Classify risks based on impact to the organization.
CC provides a threat model without specifying a risk process. Mitigate risk and determine residual risk.
Both refer to external methodologies and standards to focus Monitor risk.
on specific risks in the IT product while keeping a broad scope ASVS Discusses code-related risks.
for the whole project. Provide a lists of security requirements applications should
implement.
All security standards specify threat identification, which Identify all application components, e.g., libraries, external
systems.
is one of the first steps for risk assessment requirements.
Verify a high-level architecture for the application is
Unlike CC or TOGAF, security standards such as SAFECode, defined.
SAMM, and BSIMM recommend the use of misuse and abuse Verify that all application components are defined in terms
cases to tailor the risk assessment for specific applications. of the business and security functions provided.
Verify centralized implementation of security controls.
Table 4 summarizes how these standards focus on risk. Verify that components are segregated via security
The first aspect considered for these security standards is risk controls.
training; SAMM and TOGAF have the more complete Verify that all applications components, libraries, modules,
spectrum of requirements for risk management training with frameworks, platforms, and operating systems are free from
known vulnerabilities.
SAMM providing a software-oriented perspective and Implement testing techniques and tools.
TOGAF is more focused on enterprise architecture. SAFE Standard Focuses on Threat Model (i.e., risk identification).
Code Implement secure coding practices.
The OCTAVE process for risk assessment includes risk Identify threats using techniques/methodologies: STRIDE,
identification (defining assets, threats, vulnerabilities); risk misuse cases, brainstorming, and/or threat library.
analysis and prioritization; and risk treatment [29]. The risk Evaluate and prioritize risks using a risk rating system;
process is useful because it can be applied to any IT project; mitigate according to priority.
however, when standards (e.g., CC and TOGAF) do not Validate using testing techniques and tools.

Authorized licensed use limited to: Carleton University. Downloaded on June 02,2021 at 13:10:02 UTC from IEEE Xplore. Restrictions apply.
 V. CONCLUSION [16] N. Laoufi, "From Risk Analysis to the Expression of Security
Requirements for Systems Information," 2015 Fourth International
We have examined and compared common business Conf. on Cyber Security, Cyber Warfare, and Digital Forensic
model examples and frameworks for building security in and (CyberSec), IEEE, 2015, pp. 84-89. doi: 10.1109/CyberSec.2015.25.
improving software security in the business processes. We [17] D. R. Wallace, D. R. Kuhn and L. M. Ippolito, "An analysis of selected
conclude that many standards might not cover all the security software safety standards," in IEEE Aerospace and Electronic Systems
requirements for secure software development when used Magazine, vol. 7, no. 8, pp. 3-14, Aug. 1992. doi: 10.1109/62.151140.
individually. Instead, a process for creating secure software [18] K. Jefcoat, "What is Common Criteria Certification, and Why Is It
Important? - Blancco", Blancco.com, 2018. [Online]. Available:
relies on implementing more than one of the standards, https://www.blancco.com/blog-what-is-common-criteria-certification-
especially to conform to regulation or for certification of a why-is-it-important/
secure software application. [19] A. R. Shehab Farhan and G. M. Mostafa Mostafa, "A Methodology for
Enhancing Software Security During Development Processes," 2018
REFERENCES 21st Saudi Computer Society National Computer Conf. (NCC), 2018,
[1] F. H. Shezan, S. F. Afroze and A. Iqbal, "Vulnerability detection in pp. 1-6, doi: 10.1109/NCG.2018.8593135.
recent Android apps: An empirical study," 2017 International Conf. on [20] R. Fujdiak et al., "Managing the Secure Software Development," 2019
Networking, Systems and Security (NSysS), IEEE, 2017, pp. 55-63. 10th IFIP International Conf. on New Technologies, Mobility and
doi: 10.1109/NSysS.2017.7885802. Security (NTMS), pp. 1-4, doi: 10.1109/NTMS.2019.8763845.
[2] Health and Human Services, "Health Information Privacy - HIPAA," [21] NIST, “National Institute of Standards and Technology,” NIST, 17-
HHS.gov, 18-Dec-2015. [Online]. Available: Jun-2020. [Online]. Available: https://www.nist.gov/. [Accessed: 20-
https://www.hhs.gov/hipaa/index.html. Jun-2020].
[3] European Union, "EU GDPR Information Portal," EU GDPR Portal. [22] L. Shan, B. Sangchoolie, P. Folkesson, J. Vinter, E. Schoitsch and C.
[Online]. Available: https://www.eugdpr.org/. Loiseaux, "A Survey on the Application of Safety, Security, and
[4] R. A. Gandhi, K. Crosby, H. Siy and S. Mandal, "Gauging the Impact Privacy Standards for Dependable Systems," 2019 15th European
of FISMA on Software Security," in Computer, vol. 47, no. 9, IEEE, Dependable Computing Conf. (EDCC), Naples, Italy, 2019, pp. 71-72,
pp. 103-107, Sept. 2014. doi: 10.1109/MC.2014.248. doi: 10.1109/EDCC.2019.00023.
[5] D. Geer, "Are Companies Actually Using Secure Development Life [23] IEEE Standard--Adoption of ISO/IEC 15026-2:2011 Systems and
Cycles?," in Computer, vol. 43, no. 6, IEEE, pp. 12-16, June 2010. doi: Software Engineering--Systems and Software Assurance--Part 2:
10.1109/MC.2010.159. Assurance Case," in IEEE Std 15026-2-2011 , vol., no., pp.1-28, 11
Oct. 2011, doi: 10.1109/IEEESTD.2011.6045293.
[6] J. F. Dhem and N. Feyt, "Hardware and software symbiosis helps smart
card evolution," in IEEE Micro, vol. 21, no. 6, pp. 14-25, Nov/Dec [24] ISO/IEC/IEEE International Standard - Software engineering -
2001. doi: 10.1109/40.977754. Recommended practice for software acquisition," in ISO/IEC/IEEE
41062:2019(E) , vol., no., pp.1-56, 20 Feb. 2019, doi:
[7] J. P. Bowen, M. Hinchey, H. Janicke, M. Ward and H. Zedan, 10.1109/IEEESTD.2019.8645777.
"Formality, Agility, Security, and Evolution in Software
Development," in Computer, vol. 47, no. 10, pp. 86-89, Oct. 2014. [25] A. Hazeyama, "Survey on Body of Knowledge Regarding Software
IEEE. doi: 10.1109/MC.2014.284. Security," 2012 13th ACIS International Conference on Software
Engineering, Artificial Intelligence, Networking and
[8] J. Aranda, S. Easterbrook and G. Wilson, "Requirements in the wild: Parallel/Distributed Computing, 2012, pp. 536-541, doi:
How small companies do it," 15th IEEE International Requirements 10.1109/SNPD.2012.64.
Engineering Conf. (RE 2007), IEEE, 2007, pp. 39-48. doi:
10.1109/RE.2007.54 [26] ISO (International Organization for Standardization), Publicly
Available Standards. [Online]. Available:
[9] OWASP, “OWASP SAMM Project,” [Online]. Available: https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html.
https://www.owasp.org/index.php/OWASP_SAMM_Project [Accessed: 28-Jul-2020]
[10] OWASP, “OWASP: Application Security Verification Standard [27] S. Popić, G. Velikić, H. Jaroslav, Z. Spasić and M. Vulić, "The Benefits
Project,” OWASP. [Online]. of the Coding Standards Enforcement and it's Influence on the
Available:https://www.owasp.org/index.php/Category:OWASP_Appl Developers' Coding Behaviour: A Case Study on Two Small Projects,"
ication_Security_Verification_Standard_Project 2018 26th Telecommunications Forum (TELFOR), 2018, pp. 420-425,
[11] SAFECode. [Online]. Available: doi: 10.1109/TELFOR.2018.8612149
https://safecode.org/publication/SAFECode_Dev_Practices0211.pdf. [28] ISO, “International Organization for Standardization,” ISO, 09-Jan-
[12] BSIMM, "Building Security In Maturity Model | BSIMM," Building 2020. [Online]. Available: https://www.iso.org/. [Accessed: 04-Aug-
Security In Maturity Model|. [Online]. Available: 2020].
http://www.bsimm.com [29] C. Woody and C. Alberts, "Considering Operational Security Risk
[13] Common Criteria, "Common Criteria," Publications : New CC Portal. during System Development," in IEEE Security & Privacy, vol. 5, no.
[Online]. Available: https://www.commoncriteriaportal.org. 1, pp. 30-35, Jan.-Feb. 2007. doi: 10.1109/MSP.2007.3
[14] Open Group, The TOGAF® Standard, V. 9.2, 2018. Available: [30] [30] PCI Security Standards Council, Payment Card Industry (PCI)
www.opengroup.org. Payment Application Data Security Standard, v 2.0, Oct 2010, URL:
[15] D. Verdon and G. McGraw, "Risk analysis in software design," in IEEE https://www.pcisecuritystandards.org/minisite/en/docs/pci_pa_dss_v2
Security & Privacy, vol. 2, no. 4, pp. 79-84, July-Aug. 2004. doi: -0.pdf.
10.1109/MSP.2004.55. [31] Open Group, Integrating Risk and Security within a TOGAF®
Enterprise Architecture, 2016, Available: www.opengroup.org.

Authorized licensed use limited to: Carleton University. Downloaded on June 02,2021 at 13:10:02 UTC from IEEE Xplore. Restrictions apply.