2010 IEEE 6th World Congress on Services
Security Engineering Approach to Support Software Security
Francisco José Barreto Nunes Arnaldo Dias Belchior
Mestrado em Informática Aplicada Mestrado em Informática Aplicada
Universidade de Fortaleza Universidade de Fortaleza
Fortaleza, Brazil Fortaleza, Brazil
fcojbn@yahoo.com.br (In memoriam)
Abstract— As information security and privacy become
increasingly important to organizations, the demand grows for
software development processes that assure information
integrity, availability, and confidentiality. Unfortunately,
despite the investments made in process improvement, there is
still no guarantee that the developed software products are
protected from attacks or do not present security
vulnerabilities. As soon as software products continue to
present security flaws and be compromised by attacks, the
Systems Security Engineering – Capability Maturity Model
(SSE-CMM) becomes the de facto model to structure a
software security approach. Moreover, security best practices,
practical experience or international standards, like ISO/IEC
15408, should also be considered to support security
engineering as they propose activities that can be adapted to
enhance security in a software development process and
contribute towards the overall software security. This paper
proposes a security engineering approach to support software
security through a specialized process that helps develop more
secure software, entitled Process to Support Software Security
(PSSS). In addition, one of PSSS’s subprocess, Model Security
Threat, is explained in detail. This paper also presents the
results of the case study when the PSSS was first applied in a
software development project as well as the preliminary results
of a large project implementation.
Keywords - Information Security; Security Engineering;
Software Security; Process to Support Software Security
I. INTRODUCTION
According to GARTNER, most attacks are focused on
the application layer [1]. Because of this, software security
defects become the main concerns that security professionals
deal with nowadays. This trend has motivated considerable
research in the improvement of software development
processes.
As a consequence, security engineering becomes an
important part of the business processes that protects
corporate assets and information. Devanbu [2] considers that
changes in software development practices and software
architectures have opened new opportunities for applying
security engineering.
Moreover, the use of security engineering to develop
secure software products would be a viable alternative to
formal methods as security engineering is not oriented
978-0-7695-4129-7/10 $26.00 © 2010 IEEE
DOI 10.1109/SERVICES.2010.37
Adriano Bessa Albuquerque
Mestrado em Informática Aplicada
Universidade de Fortaleza
Fortaleza, Brazil
adrianoba@unifor.br
towards mathematical formalization so it could reduce time
and cost of the development process.
In order to protect corporate data, organizations gradually
enhance secure methodologies and initiatives to develop
more secure software products. For example, CLASP
(Comprehensive, Lightweight Application Security Process)
[3] is a framework whose purpose is to include security into
a software development process.
OECD (Organisation for Economic Co-operation and
Development) states the principle “Security design and
implementation” as a characteristic of information systems
[4]. In fact, information security is aimed at protecting
information processed by information systems and
maintaining the confidentiality, integrity and availability of
this information.
A common misunderstanding occurs, for example, when
software engineers think that an identity and authentication
control implemented in software to protect data
confidentiality and integrity makes this software secure.
Actually, this supposed secure software just implements a
security function and cannot be considered secure. That is,
security function does not insure that software is secure [5].
This paper presents an overview of the PSSS - Process to
Support Software Security, or just support process, based on
the activities derived from SSE-CMM [6], ISO/IEC 15408
[7] [8] [9], ISO/IEC 27002 [10], and OCTAVE (The
Operationally Critical Threat, Asset, and Vulnerability
Evaluation) [11]. In addition, this paper summarizes not only
the results of the case study when the PSSS was first applied
in a software development project but also the initial
outcomes of a software security project at a financial
institution.
The paper is organized as follows: Section 2 describes
briefly the security models and standards used to organize
the activities of the proposed support process; Section 3
presents a short description of the activities of the PSSS;
Section 4 explains in more detail the subprocess “Model
Security Threat”; Section 5 analyzes the results of the case
study when the PSSS was applied in a project of an access
control and audit software and introduces the preliminary
results of a large software security project; and Section 6
presents the conclusions of this paper.
48
 II. INFORMATION SECURITY MODELS AND STANDARDS
Anderson states that security engineering is about
building systems to remain dependable in the face of malice,
error, or mischance. As a discipline, it focuses on the tools,
processes, and methods needed to design, implement, and
test entire systems, and to adapt existing systems as their
environment evolves [12].
SSE-CMM [6] is a process reference model that
describes security features of processes at different levels of
maturity. It is focused upon the requirements for
implementing security in a system or related systems
components.
SSE-CMM does not dictate a specific process to be used
by an organization. The intent is that the organization should
use the model in its existing processes. The scope
encompasses:
• The system security engineering activities for a
secure product or a trusted system addressing the
complete lifecycle of: concept definition,
requirements analysis, design, development,
integration, installation, operation, maintenance and
decommissioning;
• Requirements for product developers, secure
systems developers and integrators, organizations
that provide computer security services and
computer security engineering;
• Applies to all types and sizes of security engineering
organizations from commercial to government and
the academe.
In order to use SSE-CMM as a tool to improve and
assess security engineering capability, security engineering
should be integrated with other engineering disciplines.
OCTAVE (The Operationally Critical Threat, Asset, and
Vulnerability Evaluation) [11] is a strategic planning and
evaluation technique based on security risks. The risks of the
most critical assets are used to prioritize processes that need
improvement and to elaborate a strategic orientation to
mitigate these risks.
Alberts states that OCTAVE defines a comprehensive,
systematic, context driven, and self directed approach to
information security risk evaluations [11]. That is, OCTAVE
enables an organization’s personnel to sort through the
complex web of organizational and technological issues to
understand and address its information security risks.
ISO/IEC 15408 (Evaluation Criteria for Information
Technology Security) [7] [8] [9] presents a set of criteria to
evaluate the security of products. These criteria or
requirements are divided into: security functional
requirements [8] and security assurance requirements [9].
The former are a set of security characteristics that a
software product can implement. The latter may function as
actions to be executed during the development process to
validate and certify that the software developed is secure
because these actions were performed according to part 3 of
ISO/IEC 15408 [9].
ISO/IEC 27002 (Code of Practice for Information
Security Management) [10] aims at preserving information
49
to be confidential, available and accurate. This is achieved
through the implementation of security controls which
ensures that the defined security goals will be satisfied.
Based on these models and standards, a mapping of
similar activities was organized to draft the first version of
the PSSS. The SSE-CMM was the principal base of this
mapping which is shown in Table 1.
III. PSSS – PROCESS TO SUPPORT SOFTWARE SECURITY
The research oriented by SSE-CMM, ISO/IEC 15408,
ISO/IEC 27002, and OCTAVE allowed the elaboration of a
set of subprocesses and activities that constitute the Process
to Support Software Security (PSSS) which follows the
iterative and incremental life cycle approach.
The approach of PSSS is not organized in accordance
with each step or phase of an iterative development life cycle
as this appears in [13], [14] and [15]. PSSS’s orientation
allows software engineers to include the support process in
any software life cycle.
The subprocesses and their activities are designed to span
the entire software development life cycle and make security
a pragmatic part of how secure software should be
developed.
That is, PSSS is structured to provide visibility towards
information security throughout a software development
process and to perform systematically security activities,
such as software-based vulnerability, threat, impact and risk
assessments, which also contribute to information security
strategic goals.
There is no need to use all the activities of the PSSS.
They can be adapted to function effectively within the
organizational development process. This facilitates the
coordination between the PSSS and a particular corporate
development process. It is considered an important aspect to
have each activity as integrated as possible into the life cycle
phases and one approach to reach this integration is to apply
each activity in parallel with the phases.
The type and scope of a project define which activities to
select in order to adapt the software product to be developed.
Besides that, the type of product defines the formalism and
rigors of evaluations to be implemented.
The support process identifies two important actors: the
Security Engineer and the Security Auditor. The Security
Engineer is responsible for the specialization of the PSSS
based on the objectives of the software development project
and in connection with business plans and strategies.
The Security Auditor is responsible for evaluating if the
software development projects are done in compliance with
the specialized PSSS and to validate the effectiveness of the
PSSS application, for example, in terms of the results of the
activities and the artifacts developed. The Security Auditor
should not perform the activities of the software quality
assurance team.
The PSSS is formed by 37 activities grouped in a set of
11 subprocesses (Fig. 1) which are briefly described as
follows:
 TABLE I.
SSE-CMM
Base Practice 10.06 - Define a
consistent set of statements
which define the protection to
be implemented in the system
Base Practice 11.03 - Verify
that the solution implements
the requirements associated
with the previous level of
abstraction
SAMPLE OF THE MAPPING OF THE SECURITY MODELS AND STANDARDS
ISO/IEC 15408 ISO/IEC 27002 OCTAVE
SSE-CMM : Process Area (PA) 10 – Specify Security Needs
- Specify functional 12.1 Identify information system - Creates or refines the security
security requirements security requirements requirements for the
organization’s critical assets
- Create risk mitigation plans
SSE-CMM : Process Area (PA) 11 – Verify and Validate Security
- Functional tests 15.1 Compliance with legal
- Independent testing requirements
_____
15.2 Compliance with security
policies and standards, and
technical compliance
Figure 1. Process to support software security.
50

A. Plan Security
This subprocess has the following purposes: Identify the
security objectives of the software to be developed; Prepare
the project security plan; Plan processing environments and
Plan security incidents management.
In general, this subprocess elaborates or refines the
security plan and organizes a security team.
The responsibilities of the security engineer include:
Identify the security objectives; Prepare the project security
plan; Organize the security team.
B. Assess Security Vulnerability
This subprocess has the following purposes: Identify
security vulnerabilities and Analyze identified security
vulnerabilities. In general, this subprocess identifies and
describes, for each iteration, the system security
vulnerabilities related to the environment where the system
would operate.
The responsibilities of the security engineer include:
Institute a vulnerability assessment method; Identify security
vulnerabilities; Analyze the identified vulnerabilities.
C. Model Security Threat
This subprocess has the following purposes: Identify
security threats; Classify security threats and Develop
strategies to reduce security threats. In general, this
subprocess identifies and describes system security threats
with their properties and characteristics in the context of
security vulnerabilities.
This subprocess is detailed in section IV.
D. Assess Security Impact
This subprocess has the following purposes: Review
critical activities for security; Review software security
artifacts and Identify and describe security impacts. In
general, this subprocess identifies and describes relevant
system security impacts and defines the probability of their
causes based on security vulnerabilities and threats.
The responsibilities of the security engineer include:
Prioritize the critical activities influenced by the software;
Review software’s security artifacts; Identify security
impacts from unwanted incidents.
E. Assess Security Risk
This subprocess has the following purposes: Identify
security exposure; Assess security exposure risk and
Prioritize security risks. In general, this subprocess analyzes
the security risks of the developing system by identifying the
security exposure, the risk caused by this exposure, and the
priorities of these risks based on security vulnerabilities,
threats and impacts.
Providing this subprocess finds any information that
evidences there is a new risk besides the ones previously
assessed, it is necessary to make new security vulnerability,
threat, and impact assessment originated from the new risk.
The responsibilities of the security engineer include:
Identify security exposures; Evaluate and prioritize security
risks.
51
F. Specify Security Needs
This subprocess has the following purposes: Elicit
customer security needs; Capture a high-level security view
of the system; Define security requirements and Obtain
agreement about security requirements. In general, this
subprocess specifies the security needs of the system
according to stakeholders’ security needs.
The responsibilities of the security engineer include:
Elicit customer’s security needs; Develop a high-level
security view of the software; Obtain agreement about the
security requirements.
G. Provide Security Information
This subprocess has the following purposes: Understand
security information needs; Identify security constraints and
considerations; Provide security alternatives and Provide
support requirements. In general, this subprocess provides
system architects, designers, implementers, or users with any
security information needed to perform their work.
Security information would be considered a variety of
information which has impact on, is necessary to support, or
helps members of a software security project.
The responsibilities of the security engineer include:
Research additional security information (or subjects)
impacting the project; Support the team with this security
information making it available.
H. Verify and Validate Security
This subprocess has the following purposes: Define
security verification and validation approach; Perform
security verification; Perform security validation and Review
and communicate security verification and validation results.
In general, this subprocess accredits that software solutions
are verified and validated according to their designed
security goals.
Verifying security ensures that software satisfies
specified security requirements. Validating security
demonstrates that software accomplishes its intended
security requirements when placed in its production or
operational environment.
The responsibilities of the security engineer include:
Define the approach for security verification and validation;
Perform security verification and validation; Communicate
the results.
The responsibility of the security auditor includes: Assess
the security verification and validation activities.
I. Manage Security
This subprocess has the following purposes: Manage
security services and components; Manage security training
and education programs and Manage the implementation of
security controls. In general, this subprocess not only
coordinates the activities needed to organize and to keep the
security mechanisms to the software development project,
but also manages the implementation of controls for new
functions and addresses the problems identified during the
subprocess “Verify and validate security”.
 Figure 2. Subprocess “Model Security Threat”.
The responsibilities of the security engineer include:
Control security services and system components; Identify
training needs and educational programs; Supervise the
implementation of security controls.
J. Monitor Security Behavior
This subprocess has the following purposes: Analyze
events with security impact; Identify and prepare the answer
to relevant security incidents; Monitor changes in security
threats, vulnerabilities, impacts, risks, and environment;
Review system security condition to identify necessary
changes and Perform security audit.
In general, this subprocess monitors the security of the
developed software to identify if the security features defined
in the project are achieved and are effectively implemented.
It also supports the identification of new security features to
be incorporated in the software.
The responsibilities of the security engineer include:
Analyze the events with a negative impact in security;
Identify and prepare the response of software security
incidents; Monitor changes affecting environments,
vulnerabilities, threats, and risks; Review software security
behavior.
The responsibility of the security auditor includes: Assess
the results of the activities from this subprocess; Reassess the
changes; Perform periodic security audits.
K. Assure Security
This subprocess has the following purposes: Define
security assurance strategy; Perform security change impact
analysis and Control security assurance evidences. In
general, this subprocess defines a set of activities which can
be applied to assure that the security of the software product
is achieved.
The responsibility of the security engineer includes:
Develop a strategy to maintain the security assurance.
52
The responsibilities of the security auditor include:
Perform an impact analysis; Control the security assurance
evidences.
In the next section, an example of the subprocess “Model
Security Threat” will be given.
IV. SUBPROCESS “MODEL SECURITY THREAT”
The purpose of the subprocess Model Security Threat
(Fig. 2) is to identify and characterize security threats with
their properties in the context of the security vulnerabilities
assessed previously.
Security threats can be defined as an event that
compromises the normal behavior of software and, as a
consequence, may have a negative impact in the
organization.
Threat modeling can be used to identify threats and make
project decisions based on threats that can cause the major
damage to the software.
The main difficulty in this subprocess lies on knowing all
the possibilities information could be threatened or misused.
As stated by Saltzer [16], one must demonstrate that every
possible threat has been anticipated.
The information about threats is necessary to develop
strategies to reduce these threats. The strategies can
influence the software development project, the coding, and
test cases.
The security engineer is responsible to execute security
threat identification and implement abuse cases and attack
trees. Then, he classifies these threats and organizes
interviews with selected users among executives, managers,
and operational staff in order to develop strategies to reduce
the impact of these threats. Software engineers and users
could help the security engineer modeling security threats.
Each activity is described in the following sections.
A. Identify Security Threats
The goal of this activity is to identify security threats
throughout the software life cycle.
Threats caused by people can be accidental and
deliberate. However, the activity should focus on a wide and
well-defined threat group to assure that these threats caused
by people will be treated by the software.
The assessment of threat agents, who explore the threats,
and the mechanisms, used to explore software
vulnerabilities, is critical to software threat identification.
The implementation of abuse cases and attack trees is an
important part of threat modeling.
Unfortunately, use cases do not include security concepts
as an integral part of requirements engineering [2]. So abuse
cases become an important tool to represent these security
concerns.
Abuse cases or misuse cases cover the practices that
could corrupt security of software products and describe the
software behavior under attack. To develop abuse cases (Fig.
3) it is essential to know what needs to be protected, against
whom, and for how long time. According to McGraw [17],
the simplest way to create abuse cases is through
brainstorming.
Attack trees model the decision process to commit
attacks. The root represents the goal of the threat agent, for
example: steal credit card numbers. The leaf nodes represent
actions the agent executes and each way in the tree
represents a unique attack to reach the goal [18].
Attack trees support risk analysis when answering
questions concerning the security of the software product to
design, implement and test new protections or controls
against attacks.
Figure 3. Example of an abuse case.
B. Classify Security Threats
The goal of this activity is to classify the most critical
and feasible threats.
Based on the information about threat agents and their
capacity, probability of threats, among other relevant threat
information, the security threats are classified.
Threat classification guidelines can be used to help
performing this activity, for example STRIDE (Spoofing
53
identity, Tampering with data, Repudiation, Information
disclosure, Denial of service, Elevation of privilege) [19].
Determining the threat agent's ability and capacity to
execute a successful attack is an important aspect of threat
classification. In addition, assessing the likelihood of a threat
to become true completes the information needed to classify
security threats.
C. Develop Strategies to Reduce Security Threats
The goal of this activity is to develop a set of strategies to
reduce the probability of threats to happen.
Strategies to reduce threat likelihood can involve the
implementation of software controls, training initiatives,
security awareness campaigns, among others.
In the following section, the results of the application of
the process to support software security will be presented.
V. PSSS IMPLEMENTATION RESULTS
The support process was initially applied in a simple
Web-based software development project in a public
company with more than four million customers. This
project constituted an access control and audit system that
defines and controls user access and registers the actions of
these users.
The case study of the PSSS was performed with a small
set of activities covering most of the subprocesses due to the
time constraint of this project. These activities were selected
based on project characteristics and on the experience of the
software engineering team.
Firstly, each activity was described and explained to
express the benefits and importance of applying each one.
Then, an informal workshop about the support process
occurred to verify whether the activities were suitable to the
project and, afterwards, a simple version of a security plan
was prepared.
Next, the security engineer and the software engineer
identified and analyzed security vulnerabilities and identified
security threats. The information related to security
vulnerabilities and threats helped to understand and select
security needs. With these security needs and with the help
of attack trees (Fig. 4), it was possible to identify a set of
security requirements:
• The system ensures creation of safe passwords: the
system must assure that every password creation and
password change follows defined password creation
criteria;
• The system ensures correct system access: the
system must provide a secure user access with
authentication and validation;
• The system ensures the integrity of registered audit
information: the information related to the actions of
users and administrators must be registered only for
consultation and this information must not be
changed or deleted.
After design and implementation, it was verified if the
security requirements were implemented in the final
software. Although only a small portion of security tests was

Improper Admin access right
Improper creation No update of users
of users with admin with admin rights
rights
Figure 4. Example of an attack tree of the access control and audit system.
done due to project time constraints, the results were
sufficient to certify the implementation.
Although the support process had been received
enthusiastically by the sponsors and stakeholders, it
presented some problems during the case study. These
problems reflected the lack of understanding of some
security concepts as well as the lack of time and resources to
combine the support process and corporate software
development methodology.
The second implementation of the support process is
supposed to finish in 2010 and takes place in a banking
institution. The project is focused, in his first stage, on
organizing a set of security actions derived from the PSSS to
proper elicit security requirements. These security actions
were adapted and included into the company’s software
development methodology.
To avoid resistance during the project’s beginning, it was
planned a concrete software security education program.
That is, to have the support from the software group, not
only a software security introduction course was developed,
but also a presentation was made showing the benefits.
Implementing PSSS in this new project promoted great
challenges when “Plan Security” and “Specify Security
Needs” were adapted. However, the main problem is the
organization's lack of software security culture which
compromises the results and delays the schedules. That is,
some stakeholders do not see the strategic importance of
software security, so the security priorities are left unnoticed.
Besides this drawback, as a result for “Plan Security”, it was
decided that the security objectives for each development
project would be referenced in the “Vision” document which
considers criticality, assumptions, risks and restrictions.
For “Specify Security Needs”, the principal difficulty
was to identify the security actions which would be
performed together with the former activities from
requirements discipline without causing bureaucracy and
delaying development projects. For example, it was initially
proposed a strategy based on abuse cases that was later
refused due to extra work and presumed low productivity.
Because of this, the accepted strategy was to organize an
orientation guide with the most common software
vulnerabilities and threats which would contribute with
requirements, analysis, design and test disciplines.
Audit log
modification
Improper User access right DBA modifies the table
DBA has no
permission
Besides the introductory course and the proposed actions
to elicit security requirements, more results were produced
including new and adapted artifacts with security sections
and a software security orientation guide to educate software
analysts, architects and testers to understand and avoid
common software security vulnerabilities and threats.
The proof of effectiveness of this actual project is going
to occur when the pilot project begins in May. The pilot
results will be analyzed to assess the impact of performing
the security actions, as a postmortem analysis, and lessons
learned will be organized to avoid problems from
reoccurring, to ameliorate the outcomes of future projects
and to make the PSSS more effective and consistent.
In both PSSS projects, the system security behavior and
user satisfaction increased not only because security
requirements were formally implemented but also because
software was being developed using a solid and consistent
software security development process.
VI. CONCLUSION AND FUTURE WORK
Software security is seemed as a superficial discipline
supported by an ad hoc process and treated almost always at
the end of software development life cycle with the help of a
penetration test or with guidance of a static analyzer tool.
According to Howard [19], application security should be
designed and incorporated into the products since the
beginning of the development process. This increases the
importance of establishing a security engineering approach
consisting of security activities forming a process to support
the development of more secure software as it assures the
confidentiality, integrity, and availability of processed and
stored information, delivering value to customers.
Perhaps, at a first impression, PSSS can be seen as a
heavy process as well as useless because there are other
security-based software processes. Nevertheless, PSSS offers
37 positive security activities to be adapted and specialized
based on corporate software development preferences. PSSS
is designed for any iterative project and for any organization
in need of software security solutions.
Some benefits of the PSSS include:
• Permit proactively the identification and correction
of software security problems;
54
 • Consider the assessment of security vulnerability,
threat, impact and risk in every iteration of the
development process;
• Assure that software products be compliant with
legal and regulatory requirements;
• Can be used to help creating an ISO 15408 and
27001-compliant software development process.
The support process is not alone in the quest to increase
security in software products. Besides [3] and [17], there is
also the process proposed by Microsoft, called The Security
Development Lifecycle (SDL) [20]. Each of them has
advantages and disadvantages and it is the responsibility of
the development organizations to consider which one best
fits in their software development life cycles. Therefore, as a
complementary work, the support process would be updated
by analyzing the results of the application of these secure
development processes. Based on this analysis, it could be
possible to know, for example, how security problems are
handled better than in the PSSS.
Finally, the PSSS, as a security engineering approach,
may improve the effectiveness of software security projects
as it avoids common restrictions of the SSE-CMM,
OCTAVE, ISO/IEC 27002, and ISO/IEC 15408. Some of
these restrictions include:
• SSE-CMM is complex as it demands 29 generic
practices to apply to 126 base practices. Moreover, it
tries to focus on different engineering disciplines. It
also lacks detailing how to implement its process
areas in different contexts. Because of these
characteristics, it is hard to understand and
implement SSE-CMM;
• OCTAVE allows people from the organization to be
responsible for setting the organization’s security
strategy. This could lead to security problems when
these people have no security education or because
they could have other responsibilities and are not
entirely responsible for the security program;
• ISO/IEC 27002 contains a vast number of security
controls to be applied among different processes in
any kind of organization. This could be seen as a
weakness as this could lead to wrong interpretations.
Another issue is that the standard does not explain
how to best implement each security control;
• ISO/IEC 15408 has its use restricted because of its
complexity in implementing and assessing the
security aspects of the software product. This
standard requires a specialized knowledge which
makes its use more expensive and time consuming.
Although the PSSS presents an organized software
security initiative, additional research must be done in order
to improve and disseminate software security discipline, such
as: software security with agile processes, software security
architecture, or software security metrics. Unfortunately, it
must be observed that software security aspects are being
researched without focusing on Software Engineering
support and with little Security Engineering orientation.
Further work could involve the support of knowledge
management which contributes towards the improvement of
55
software development processes based on the experience and
knowledge collected. So, the improvement of Security
Engineering approaches means the creation of knowledge or
the improvement of old knowledge about these approaches.
Then, this updated knowledge is institutionalized in the
organization's software development process [21].
REFERENCES
[1] GARTNER. Available: www.gartner.com.
[2] Premkumar T. Devanbu, Stuart Stubblebine, “Software Engineering for
Security: a Roadmap”, in Proceedings of the Conference on the Future of
Software Engineering, pp. 227 – 239, June 04-11, 2000, Limerick, Ireland.
[3] CLASP. (2006, November). Comprehensive, Lightweight Application
Security Process [Online]. Version 1.2. Available:
www.owasp.org/index.php/owasp_clasp_project.
[4] OECD. (2002, July). Organisation for Economic Co-operation and
Development [Online]. Guidelines for the Security of Information
Systems and Networks: Towards a Culture of Security, Principle 7 -
Security design and implementation, page 13. Available: www.oecd.org.
[5] Gary McGraw, "Software security," IEEE Security & Privacy, Vol. 2, no.
2, pp. 80-83, 2004.
[6] SSE-CMM. (2003, June). Systems Security Engineering – Capability
Maturity Model [Online]. Version 3. Available: www.sse-cmm.org.
[7] Information Technology – Security Techniques – Evaluation Criteria for
IT Security – Part 1: Introduction and General Model. ISO/IEC 15408-1,
2005.
[8] Information technology – Security techniques – Evaluation criteria for IT
security – Part 2: Security functional requirements. ISO/IEC 15408-2,
2005.
[9] Information technology – Security techniques – Evaluation criteria for IT
security – Part 3: Security assurance requirements. ISO/IEC 15408-3,
2005.
[10] Information technology – Security technical - Code of practice for
information security management. ISO/IEC 27002, 2005.
[11] C. Alberts et al. (2001, December). OCTAVE - The Operationally Critical
Threat, Asset, and Vulnerability Evaluation [Online]. Carnegie Mellon –
Software Engineering Institute. Available: www.cert.org/octave.
[12] Ross Anderson, Security Engineering: A Guide to Building Dependable
Distributed Systems. John Wiley and Sons, 2001.
[13] A. Apvrille, M. Pourzandi, “Secure Software Development by Example,”
IEEE Security & Privacy, vol. 3, no. 4, July/August 2005, pp. 10–17
[14] C. Muniraman, M. Damodaran, “A Practical Approach to Include Security
in Software Development” [Online], in Issues in Information Systems, vol.
8, no. 2, pp. 193-199, 2007. Available:
www.iacis.org/iis/2007/PDFs/Muniraman_Damodaran.pdf.
[15] Kenneth R. van Wyk. Gary McGraw, “Bridging the Gap between
Software Development and Information Security,” IEEE Security &
Privacy, vol. 3, no. 5, September/October 2005, pp. 75-79.
[16] J.H. Saltzer, M.D. Schroder, “The Protection of Information in Computer
Systems”, in Proceedings of the IEEE, vol. 63, no. 9, 1975, pp. 1278 -
1308. Available: http://web.mit.edu/Saltzer/www/publications/protection.
[17] Gary McGraw, Software security: building security in, 1st Edition.
Addison-Wesley, 2006.
[18] B. Schneier, “Attack trees: modeling security threats”, Dr. Dobbs’ Journal,
December, 1999.
[19] M. Howard, D. LeBlanc, Writing Secure Code, 2nd Edition. Microsoft
Press, 2002.
[20] Howard, M., and Lipner, S. The Security Development Lifecycle, 1st
Edition. Microsoft Press, 2006.
[21] Arent, J., Nøbjerg, J., Pedersen, M. H., “Creating Organizational
Knowledge in Software Process Improvement”, in Proceedings of the 2nd
International Workshop on Learning Software Organizations, 2000, pp.
81-92.