DEPENDABILITY ATTRIBUTES FOR INCREASED SECURITY IN COMPONENT-BASED SOFTWARE DEVELOPMENT

Existing software applications become increasingly distributed as their continuity and lifetimes are lengthened; consequently, the users’ dependence on these applications is increased. The security of these applications has become a primary concern in their design, construction and evolution. Thus, these applications give rise to major concerns on the capability of the current development approach to develop secure systems. Component-Based Software Development (CBSD) is a software engineering approach. CBSD has been successfully applied in many domains. However, the CBSD capability to develop secure software applications is lacking to date. This study is an extension of the previous study on the challenges of the security features in CBSD models. Therefore, this study proposes a solution to the lack of security in CBSD models by highlighting the attributes that must be embedded into the CBSD process. A thorough analysis of existing studies is conducted to investigate the related software security attributes. The outcome analysis is beneficial for industries, such as software development companies, as well as for academic institutions. The analysis also serves as a baseline reference for companies that develop component-based software.


INTRODUCTION
Existing software applications become increasingly distributed as their continuity and lifetimes are lengthened; consequently, the users' dependence on these applications is increased. The dependability of these applications has become a primary concern in their design, construction and evolution. Kahtan et al. (2012) reported that pervasive computing gives rise to major concerns on the capability of current development models to develop dependable systems. Component-Based Software Development (CBSD) is a software engineering approach (Sommerville, 2011); its capability to develop dependable software applications is unknown to date.
CBSD is a technique that focuses on the use of existing software codes to develop software applications and thus avoids the need to develop from scratch (Alhazbi and Jantan, 2007;Lin, 2007). CBSD shifts the development emphasis from programming software to composing software systems (Gill and Tomar, 2010) by integrating existing software components based on the assumption that certain parts of a large software system reappear regularly and that common parts must be written once and then reused several times rather than written over and over again (Ahmed et al., 2012).
Several studies have reported the different challenges in using CBSD in software development in terms of component security trust. According to Moradian and Håkansson (2010), the interdependencies of software components create security issues during the integration phase of their development. Talib et al. (2010) stated that the lack of a suitable guide during the CBSD life cycle leads to faults in software requirements, design, or codes and thus results in major security threats. According to Carvalho et al. (2009), selecting a component with unknown security properties is unacceptable because it may produce catastrophic results.

JCS
Therefore, dependability attributes must be verified and validated throughout the CBSD process to guarantee the dependability of software applications (Kahtan et al., 2012). The original definition of dependability underscores the justification of the trust. Dependability is defined as the level of reliability with which a property of a computer system can deliver the service it is supposed to provide (Laprie, 1992). Avizienis et al. (2004) defined dependability as the ability of a system to avoid service failures that are more frequent and severe than expected.
This study is organized as follows. Section 1 provides the introduction. Section 2 explains software security and CBSD in detail. Section 3 defines and reviews related studies on software security. Section 4 highlights software security attributes. Dependability attributes are defined in Section 5. Finally, the conclusion is provided in section 6.

SOFTWARE SECURITY AND CBSD
Current applications and systems contain software components as basic elements and CBSD is utilized to build applications and systems (Ahmed et al., 2012;Kouroshfar et al., 2009;Lau et al., 2011). However, CBSD lacks security in terms of software components (Hutchinson et al., 2004;Karen et al., 2011). Thus, the software can be considered a defective source. For example, malicious hackers and intruders exploit software defects (coding bugs such as buffer overflows and design flaws such as inconsistent error handling) to obtain unauthorized access and launch attacks. This problem emphasizes the need for designers to build a secure software (Al-Azzani and Bahsoon, 2010). In a recent example of hacking reported by Gibbs (2013), the Malaysian site of Google was hacked by a Pakistani group. The search service was replaced with a splash screen crediting the group before the site was taken completely offline. Researchers have acknowledged the importance of software security in the software development lifecycle. Due to poor software development practices, which include improper testing, failure to control common programming errors and poor understanding of the interactions between different software components that will lead to system failure (Kahtan et al., 2012). Examples of such opinions are discussed briefly below. McGraw (2004) stated that in the fight for better software, treating the disease itself (poorly designed and implemented software) is better than taking an aspirin to stop the symptoms. The deep integration of software security into the development process and the engineering lessons from software practitioners have no substitute. Hadžiosmanović et al. (2012) discovered that vulnerabilities in Industrial Control Systems (ICSs), which include nuclear power plants and oil and gas extraction and distribution facilities, have increased mainly because of poor software development cycles used by several vendors and the "security by obscurity" paradigm used to "protect" legacy devices. Dobariya and Gajjar (2012) noted that one of the challenges in VoIP is that poor software development can lead to various security problems. Bygren et al. (2012) stated that poor software development in early-and mid-stage acquisition can result in failure to provide the desired results. This failure ranges from unwanted or missing features to cost and schedule overruns as well as critical flaws in system security or reliability. Sudhakar and Dava (2012) reported that poor software development practices occur because of marketing pressure and could lead to the release of unsecure server applications. These problems have caused an increase in traffic monitoring approaches. Thomas (2012) claimed that vulnerabilities can cause broad-range system failure, which is often compounded by poor software development. The majority of companies have discovered that they do not possess the engineering discipline to recreate binaries that are currently running their businesses.
Many technologists and commercial vendors have demonstrated that unsecure software affects people's lives in many ways. For instance, the Symantec Security Response team (Security, 2012) highlighted in the 2011 symantec internet security threat report that more than 5.5 billion malicious attacks were blocked in 2011; this value is more than 81% higher than that in 2010. The Verizon Enterprise Solutions team (Verizon, 2012) revealed in The 2012 Data Breach Incident Report that 855 malicious incidents occurred in 2012; 174 million records were compromised. The sophos team (Sophos, 2012) reported in security threat report 2012 that Google removed more than 100 malicious applications from the Android Market in 2011 when hackers exploited vulnerabilities in the system. Secunia (2011) stated in secunia yearly report 2011 that the Science Publications JCS vulnerabilities that affect typical end points have tripled to more than 800 and that the majority of these vulnerabilities (79%) are found in third-party programs. Technologies (2011) team highlighted in that organizations collectively lose 545 man hours a year on the average owing to IT downtime and data recovery.
In conclusion, protecting a continuously evolving network is difficult even when the software is not updated every five minutes. If a software has a defensively designed self-protection mechanism, is properly tested from a security perspective, or has few vulnerabilities, operating a secure network will be easy and cost effective. Progress should be attained on both fronts. However, in the long term, codes that are easy to defend must be developed (McGraw, 2011). Researchers and technologists need to understand how to manage poor software development practices. The software security approach aims to provide such help by exploring the development of best practices. Software security involves helping CBSD designers remove the burden of security problems from end users.

SOFTWARE SECURITY
The term "software security" has been defined by many authors in literature. McGraw (2004) stated that software security is engineering software that can continue to function correctly under malicious attacks. Cogo (2013) defined software security as a function focused on vulnerability extraction and system protection. Ghebremedhin (2012) defined software security as a measure that prevents the danger or risk of attacks. The Department of Homeland Security (Karen et al., 2006) defined secure software as software that cannot be forced to perform unintended functions. Software security also refers to the process of creating software that is considered secure (Boampong and Wahsheh, 2012). This process includes a robust design that deters software attacks through the identification and expulsion of problems in the software itself and through the provision of proper information to software developers, architects and users with regard to the development of secure applications.
One important goal of software security is to ensure justifiable confidence in the following basic features: The software under consideration functions in the intended manner and does not compromise the security or any other required properties of the software; the software environment or managed information is reliable and can continue to operate under all anticipated circumstances; and the software does not have vulnerabilities (McGraw, 2011). Such vulnerabilities may refer to an anomalous and hostile environment and to other utilization conditions (Karen, 2009). For this reason, software developers must anticipate these conditions and then design and implement the software to manage these challenges efficiently. Such conditions may include any of the following: Exposure of the operational software to accidental events threatening its basic security; exposed to intentional choices or actions that threaten its security during its development, deployment, operation, or continuity; and the presence of unintentional faults in the software and its environment.
Many studies have stated that the only means to solve software vulnerability is to consider software security development (Khaled and Han, 2006;Kim, 2004;McGraw, 2004;Mir and Quadri, 2012;Simpson, 2012). However, efforts to measure and improve software security remain under investigation (Alberts et al., 2012;Colombo et al., 2012;Karen et al., 2006;Lai, 2012;Steward et al., 2012). To address the research problem and the gaps identified in existing literature, the following issues are investigated: • What are the common software security attributes addressed in the literature • What significant attributes should be considered to solve the shortcomings of CBSD

SOFTWARE SECURITY ATTRIBUTES
In literature, the terms "dependability," "trustworthiness," and "survivability" are used interchangeably to describe the properties of software security (Karen, 2009).

Dependability
Dependable software executes predictably and operates correctly under all conditions even when the conditions are hostile, the software is under attack, or the software operates on a malicious host.

Trustworthiness
Trustworthy software contains few vulnerabilities or weaknesses that can be intentionally exploited to subvert Science Publications JCS or sabotage the reliability of the software. To be considered trustworthy, the software must contain no logic that causes it to behave in a malicious manner.

Survivability
Survivability (also referred to as "resilience"): Software is considered resilient when it can (a) resist (i.e., protect itself against) or tolerate (i.e., continue operating dependably in spite of most known attacks, including as many novel attacks as possible) attacks and (b) recover quickly with as little damage as possible from attacks that the software can neither resist nor tolerate.
In several studies, the trustworthiness attribute is required in CBSD to achieve a secure software component (Muhammad and Zulkernine, 2011;Yan and Prehofer, 2011;Zhou, 2010). Other researchers believe that survivability (or resilience) is necessary to have secure software components (Gama et al., 2012;Zhiwen et al., 2010). The dependability attribute is a widely accepted concept through which to achieve better security in most software components (Crnkovic and Grunske, 2007;Xu et al., 2006;Yi and Li, 2011). In Security in The Software Lifecycle (Karen et al., 2006), the Department of Homeland Security defined "dependability" as the degree to which the software is operable and capable of performing its functionality or delivering a service that can justifiably be relied upon (i.e., trusted) as correct. To achieve dependability, the software must have the ability to avoid service failures that are frequent, severe, or have longer duration and are considered acceptable to users. Survivability and trustworthiness are closely related to dependability (Karen et al., 2006). According to Sommerville (2011), the dependability of a computer system is the property of the system that reflects the user's degree of trust in that system. The most important dimensions of dependability are availability, reliability, safety and security. Moreover, the dependability of a computer system is a property that equates to its trustworthiness. The dependability attributes in CBSD has been considered in many studies (De Andrés et al., 2008;Gallina et al., 2012;Kharchenko et al., 2009;Tambe et al., 2010;Yi and Li, 2011). Dependability counters the security vulnerabilities, abnormal behavior and untrustworthy issues in a software system. To consider a system dependable, it must be viewed according to different but complementary properties (or instances of dependability), such as availability, integrity, reliability, safety, maintainability and confidentiality (Avizienis et al., 2004;Dai et al., 2006;Redwine Jr, 2007).
In conclusion, current literature shows that dependability attributes are the cure for security threats, abnormal behavior and untrustworthy issues in a software system. Therefore, in this study, dependability attributes are considered to overcome the security lacking in component-based software development.

DEPENDABILITY ATTRIBUTES
In simple terms, dependability ensures that the software always operates correctly. Several low-level properties can be viewed as attributes of dependability as well. Table 1 presents the dependability attributes (Avizienis et al., 2004;Redwine Jr, 2007).
Two interesting questions must be considered in relation to this topic: How can these properties be satisfied collectively in one CBSD process and can the current state of the CBSD approach collectively address the requirements.
Tremendous research efforts have been exerted in current literature, resulting in many studies on integrating all six dependability attributes into the CBSD process. Table 2 highlights the dependability attributes integrated into the CBSD process addressed in the current literature.
However, each study on verifying safety and maintainability as well as on estimating reliability, integrity, confidentiality and availability properties in CBSD has progressed independently (Crnkovic and Grunske, 2007). This condition can be attributed to the following reasons: (1) the attributes of safety and maintainability that address challenges must be specified, composed and verified in the software component; (2) the traditional ways to estimate reliability and availability attributes in a system architecture using stochastic methods are based on uncertain and inaccurate parameters; and (3) studies that analyze the vulnerabilities of confidentiality and integrity attributes are inadequate. All of these attributes must be embedded into the CBSD process to develop dependable component-based software systems. If the CBSD approach is enhanced in this manner, specifying and verifying these same attributes would be possible. The software should be operational and ready to provide the correct service. It must be easily accessible to its intended and authorized users, referring to both humans and processes. The availability of a system is the probability that it is capable of delivering useful services at any time.

Reliability
The continuity of correct service refers to the probability that the system can aptly the expected services to the user over a given period of time. It also refers to the probability of failure-free operation over a certain period of time for a specific purpose within a particular environment. Integrity This attribute refers to the fact that the software must be protected from subversion; improper system alterations must be absent. Unauthorized modifications by unauthorized entities, such as corruption, overwriting, destruction, tampering and insertion of unintended (including malicious) logic or deletion, lead to subversions in the system. In such cases, integrity must be preserved during the development and implementation of the software.

Confidentiality
This attribute refers to the absence of unauthorized disclosure of information as applied to the software rather than the data being handled. Moroever, its refers to the characteristics, existence and/or protected or hidden content of unauthorized entities. Confidentiality often prevents unauthorized entities from learning about the system through reverse engineering or by developing effective attacks against the system. Safety This attribute refers to the absence of catastrophic effects on both the environment and the user. It can also refer to the possibility that the system can cause damage to the environment and people.

Maintainability
This attribute refers to the ability to go through repairs and modifications. New requirements emerge as systems are used.Thus, the usefulness of a system must be maintained by modifying it to accommodate such requirements. Maintainable software is software that can be adapted economically to manage new requirements; in such instances, the modifications are unlikely to introduce new errors into the system.

CONCLUSION
A thorough analysis of existing research was conducted in this study to investigate the related software security attributes. Literature indicates that several attributes are used interchangeably to describe the properties of software security. Hence, the dependability attributes utilized to solve the lack of security in the CBSD process were proposed in this study. Six dependability attributes were identified:

JCS
Availability, reliability, confidentiality, integrity, safety and maintainability. By considering these dependability attributes, the CBSD product will be cured of security threats, abnormal behavior and untrustworthy issues. Moreover, embedding dependability attributes will help CBSD developers relieve end users of the burden of security problems.
This study has contributed to highlight the importance of embedding the CBSD process into the dependability attributes, the analysis in this study serves as a baseline reference for software development companies in promoting the CBSD. The analysis is beneficial for industries, such as software development companies and can also be used for academic purposes in order to fill the gap in existing CBSD models.
This study limited to address the importance of embedding the CBSD process into the dependability attributes. Discussion of embedding the CBSD phases (i.e., requirement analysis, design, implementation and testing) into dependability attributes is beyond the scope of this paper.
Future studies could start by identifying the vulnerabilities that affect the dependability attributes. In addition, designing a model for developing a dependable component-based software, which can overcome the weaknesses of the existing models while retaining their strengths.