Skip to main content

Table 1 The ISO 27005 standard criteria for effective SRE approach selection

From: A fuzzy TOPSIS based analysis toward selection of effective security requirements engineering approach for trustworthy healthcare software development

Criteria

Description

Security goal (C1)

Security goals clearly state what the software system must avoid and not how that preventative measures should be accomplished.

Security requirement (C2)

Security requirements are implications of software system threats that can be obtained only from design process. Security requirements quite precisely reflect safety objectives.

Stakeholder (C3)

A stakeholder is a person, an organization or a community with an interest with the under development software system. A Stakeholder perspective defines a specific stakeholder’s requirements. The stakeholders can show various kinds of requirements.

Asset (C4)

Software asset would be any process / service that a corporation uses as part of the economic operations. For companies, monitoring and managing such assets is essential, as they may involve regulatory risks, threats to brand equity and even existence.

Threat (C5)

Threats to software system are harmful elements of computer programs and programs that can potentially harm your computer or capture personal and financial information.

Vulnerability (C6)

Vulnerability may consider as software system defect that can consider leaving it open to manipulation. Vulnerability may also correspond to any kind of deficiency in a software system on its own, in a set of processes, or even anything which leaves the security and privacy of data at risk.

Risk (C7)

Risk is a failure prediction; a possible issue that might or might not arise in the future. It is usually limited by inadequate of information, regulation or time. It is possibility of experiencing from failure in software development life cycle.