AIRCC PUBLISHING CORPORATION
Metric For Evaluating Availability Of An Information System: A Quantitative Approach Based On Component Dependency
Suhail Qadir Mir1 and S.M.K. Quadri2
1Post Graduate Department of computer sciences, University of Kashmir, India
2Department of Computer Science, Jamia Millia Islamia, India
The purpose of the paper is to present a metric for availability based on the design of the information system. The availability metric proposed in this paper is twofold, based on the operating program and network delay metric of the information system (For the local bound component composition the availability metric is purely based on the software/operating program, for the remote bound component composition the metric incorporates the delay metric of the network). The aim of the paper is to present a quantitative availability metric derived from the component composition of an Information System, based on the dependencies among the individual measurable components of the system. The metric is used for measuring and evaluating availability of an information system from the security perspective, the measurements may be done during the design phase or may also be done after the system is fully functional. The work in the paper provides a platform for further research regarding the quantitative security metric (based on the components of an information system i.e. user, hardware, operating program and the network.) for an information system that addresses all the attributes of information and network security.
Availability, Metric, Security, Dependency, Information System.
The traditional way of dealing with security was to employ the protection mechanisms after the developmental stages of an Information System . As a result, most of the research work in Information and Computer/Network Security is based on the detailed study of complex protocols or of complex systems and also given the fact that the genesis of the security holes is often backtracked to failures associated with such complex protocols and complex systems. In the last decade or so the security paradigm has shifted beyond the study of complex protocols, to the level were secure systems can be designed and evaluated in a connected and chronological order (evaluations of measurable components carried out individually) and also how secure systems can be designed in a manner that in spite of the adversarial environment, the system may perform its intended function [5, 6, 7, 8 and 9]. The approach of evaluating the security of measurable components at system-design level focused on the mechanisms and design of components in such a way that the components facilitated security measurement . The formulation of a methodology for the composing of such individually evaluated components of systems such that the security is ensured is still a research question with no concrete answers and furthermore, no system-design level methodology exists to compose such individuality. Also, very few methodologies exist that quantify the amount of security provided by a particular system [11, 12] and not much either that talk about quantifying security beyond the application level i.e. at the system design level. The main reason is the fact that most of the security validation attempts are qualitative in nature, focused more on the processes and functionality of the system.
Given the dearth of a solid quantitative security metrics, there exists no quantitative method for measuring systems availability from the security perspective, but various measurement schemes do exist which measure availability in terms of functionality and performance , furthermore there are no measurements of availability at the design level. Given the importance of Availability as a security attribute , there is a need to quantify availability as a security attribute. Quantifying availability at an early stage i.e. system design level for systems with component based design would serve the purpose of security evaluation better because security evaluation at an early stage of system design would facilitate the process of making changes in the design accordingly keeping in view the security and performance of the overall system. This paper proposes a metric for availability that quantifies availability at the system-design level or for a developed system the metric is applied to the individual working components (software/program code), which are brought into the picture after applying the process of reverse engineering.
Why is the metrics software based? The answer is simple, because of the fact that, the hardware of the system is usually more secure, reason being the physical restrictions in attacking the hardware. Since the goal is to measure availability from the security perspective, the hardware that way is affected indirectly, basically by exploiting the operating code of the system. Also whenever we talk about availability of the hardware we are more focused on the functional aspects of the system, rather than the security i.e. system is much better functional (high availability) with redundancy in the hardware.
This paper is organised as follows: Section 2 discusses the relation between dependability and availability, Section 3 emphasises on the dependencies in a Component Composition, section 4 contains the derivation of the metric and the algorithm for availability evaluation, section 5 concludes the paper with emphasis on the effects of dependency chains on availability and the importance of the metric.
2.Dependability And Availability
Availability is one of the integrative attributes of dependability, as shown in figure 1. Dependability is a computer system property such that the service delivered by the system can be trusted and justified for the same. The service delivery is actually the behavior of the system as it is observed by its user(s); a user is a different system (human or physical) which collaborates with the erstwhile . The world today is showing ever-growing reliance and dependence on information computing systems, which has put forward many questions and challenges regarding the limits to their dependability. To counter such questions various global terminological and conceptual frameworks came into existence over the past two decades and a half. As came the concept and terminology of dependability and has undergone various changes since its introduction in the early standard documents of security. Some of the early definitions that were adopted back then are well explained in . With the passage of time and changes in the technological world a more standard definition of dependability was established, based on the classical notions of security, reliability, maintainability and safety, which are since then seen as the dependability attributes [14 and 1].
When we talk about a system being a Dependable one, it certainly means that all the attributes of dependability exist in that system. Any alteration or deviation in the values of the attributes will certainly result in the system being lesser dependable. One such deviation can occur in the availability attribute of the system. If the system has a component-based design (CBD) and has large number of interacting components (i.e. long chains of dependencies), the system may require additional disk space and processing, which may result in degrading the performance of the system or in worse case result in a Dependency Hell , which may ultimately result in rendering a system unavailable, thus impacting the availability attribute of the Security of the Information System.
Fig. 1: Attributes of Dependability and Security
The effects on Availability can impact other security attributes as well, as is explained in . In order to counter such a problem, two things need to be done. First is to see to what extent a system can handle the growing dependencies. Secondly to come up with a measurement scale that gives an idea about the system being stable or unstable based on the dependencies among the components. Lesser the dependencies more are the chances of the system to work in a stable state, which in other words means a good score for the Availability attribute of the system.
3.Dependencies In Component Composition
In a scenario where there are many interacting components of an Information System, a component may call the service of any other component which may in turn call services of other components and so on until the required task is accomplished. The components are interlinked in a well-organized manner in order to provide the required functionality in an efficient and balanced manner. Such a scenario is known as component composition or composition of the system. In the case of distributed/networked environment, the component composition is located over remote information systems. The component composition, in this case, can be both local bound (standalone system) and remote bound. In component based system architecture the component is the basic building block of the system, more precisely a component usually is a black box building block that’s only concerned with inputs and outputs, without any knowledge of the internals of the component. In a component composition, components interact, collaborate and participate with each other to carry out the required system functionality, resulting in dependencies among various interacting components. The associations that exist between interacting components can be either direct or indirect :
The dependency between components is categorized into four types, implicit dependency (direct and indirect), explicit dependency (direct and indirect). Implicit dependencies are related to the systems environment while as Explicit dependency is the clearly defined dependency i.e. a component may refer to other components and may be used by many components. In a component composition while the components interact, collaborate and participate, the system contains various types of dependencies, as explained in .
To model the dependencies between various components in the system and to derive a metric for Availability based on the components we make use of an Adjacency Matrix (AMnxn) aka dependency matrix or the component dependency graph. To construct the matrix we need to represent the system components in a graphical form. We make use of UML modeling for the representation of components in a graphical form. In figure 2 is shown the structure of a component based system using the UML paradigm. The boxes represent the various interacting components of the system. As shown in the figure the dependencies appear as a result of linkage between the provider and required interfaces (any type of dependency as mentioned in the list above), these are the implicit dependencies. The explicit dependencies are shown by the dotted arrow, tail represents the source component that is dependent on the component connected by the arrow head.
Fig2: Illustration of Components and their Dependencies in a System
In the adjacency matrix denoted by AMnxn each component is represented by a column and a row with indices as “i” and “j” respectively. Let’s assume that a component Ci depends on another component Cj, then the comparable element in the adjacency matrix AMnxn is denoted as “1”, otherwise the value is denoted as “0”. If an element in the matrix is represented by dij, then all the values in the matrix AMnxn can be generalized as:
Therefore the Adjacency matrix AMnxn (aka Direct Dependency matrix DDnxn) for a component composition involving N components would look like this:
C1, C2. . . . CN are components
dij is either 0 (no dependency) or 1(dependency)
Fig 3 Matrix Direct Dependency
The matrix drawn above is a Direct Dependency Matrix that represents the direct interactions between various interacting components in the system. Using Warshall’s algorithm of transitive closure  we create one more matrix called as Full Dependency Matrix, that contains all possible interactions (direct and indirect) between components. The algorithm for computing the complete dependencies of a component Ci is:
The input to the Algorithm is the direct dependency matrix and the output after applying the Warshall’s Algorithm is the full dependency matrix that looks like:
C1, C2. . . . CN are components
fdij is either 0 (no dependency)or 1(dependency)
Fig 4 Matrix Full Dependency
The Full Dependency Matrix represents all possible dependencies that a component can have in a component composition. For the dependency(whether direct or indirect) between any two components Ci and Cj belonging to column and row with indices as “i” and “j” respectively, the comparable element “fdij” in the full dependency matrix FDnxn is denoted as “1”, otherwise as “0”.
Related to the dependency matrices, we define the following dependency determinants of an individual component Ci in the composition as follows:
Next, we quantify Inward-Dependency and Outward-Dependency as Inward-Degree and Outward-Degree respectively in Full Dependency Matrix.
4.1 Formation Of Metric For Availability
When the components of an Information System interact, collaborate and participate with each other, a long chain of dependencies can create issues  in the system. In order to keep an eye on that, we need to analyze the dependency levels of each of the components in the system. This will give us the indications about the critical behavior of the components and based on such data we can analyze the effects that it will have on the functioning of the overall system from the security (Availability) perspective.
In the previous section we defined a term Total-Dependency, which can be put mathematically as:
InDeg (Ci) is the Inward-Degree of the component Ci
OutDeg (Ci) is the Outward-Degree of the component Ci
To control the results in the region of 0 and 1, the above equation can be written as:
inDeg(Ci) or inDeg(Ci) > 0.
The dependency of components C1 + C2 ………. + Cn for the overall system tDep(SyS) becomes:
The main trait of Availability is timely access to resources, a delayed response is no response given the speed at which information systems operate these days. In a scenario of a component composition, a component or a group of components may be dependent upon another component or a group of components, which may, in turn, be dependent upon another component or a group of components. Such type of dependency chains may result in delayed responses. This may ultimately impact the Availability of the system. There are more delays if the interacting components are located over remote information systems, in such component compositions the functionality provided by the components is accessed by the client components via the remote procedure calls (RPC’s) which start with a client stub call (invocation), then the parameter packing (marshalling) and sending the message from the client to the server machine. The incoming packets are fed into the server stub and then the parameter unpacking (un-marshalling). Finally the call by server stub to the server procedure. The delay involved is mainly due to the following factors [20, 23 and 24]:
From the above discussion, it’s clear that the factors that can impact Availability of the system in a component composition are:
The metric for Availability that we are proposing in the thesis is based on the factors mentioned above. Recall from the fig and the definitions of inDeg and outDeg, the number of components that may request the services of a component Ci for their required functionality is inDeg(Ci). The number of components requested by component Ci for its required functionality is outDeg(Ci). As the dependency chain grows and also given the delays associated with the remote/networked nature of the composition, it is certainly going to show effects on the performance of the component (delayed response or no availability) and the Availability of the overall system.
Using the above-mentioned factors and the equation 5 as base, the availability of the component Ci is:
the fact that relationships among every component either in inDeg or outDeg are the factor of 1 – N i.e. for the required functionality, Ci may call some or every component in outDeg(Ci), on behalf of the calling components. Therefore in the component chain, the calling components (components in inDeg(Ci)) invoking Ci ,accumulate the outDeg(Ci) component by inDeg(Ci) number of times. Therefore the above equation becomes:
Furthermore the metric also take into account the delay associated with the component chain. The delay here is twofold i.e. for systems with local bound component compositions and for systems with remote component compositions.
For the former (local bound) processing delay ΔPj for each component which Ci calls for its service (Components in outDeg(Ci)) is:
J=0 for the processing delay of the component itself
Therefore the equation 8 for Availability becomes:
For the later (remote bound) we make use of the delay metric (used for measuring network performance), the metric comprises of processing delay ΔP, the propagation delay ΔR, the Queuing delay ΔQ and the transmission delay ΔT. For each component which Ci calls for its service (Components in outDeg (Ci)) and also the delay of processing the component Ci itself, the metric for delay of the dependency path can be calculated as:
k and l are two adjacent nodes.
Transmission delay from k to l, ΔTkl =b/ρ,
b: bits in the packet, ρ:bandwidth between node k and l
ΔRkl Propagation time from node k to l
Queuing delay of k: ΔQk, queuing delay of l: ΔQl
Processing delay of k: ΔPk, Processing delay of l: ΔPl
Note: delay calculated is Unidirectional
Therefore the equation for Availability for the system with remote component composition becomes:
The range of values for the Availability metric of the component Ci will be in the region of 0-1. The proposed metric for Availability will serve as an indicator about the critical components of the system. If the value of the availability of a component is somewhere near 0 then the component is rendered as a critical one, higher values nearing 1 means otherwise. More the number of dependencies, more the value will tend to 0. A lesser value higher risks to the availability of the component. Based on the above equation the Availability metric for the overall system would be:
N is the number of components in the system.
IAV(Ci) is the availability level of the component Ci
The range of values for the Availability metric IAV(SyS) for the system will be in the region of 0-1. Based on this value different designs of the system can be considered and the best design chosen would be the one whose score would be nearing 1. A score nearing 1 would mean stability in terms of analyzing the growing dependencies in the system.
While measuring the Availability if we go beyond the application level of an information system i.e. the component level, the dependencies among the various interacting components can be used to determine the availability/workability or risk analysis of an information system. The work in this paper presented a novel metric of measuring the availability at the component level that gave us an idea about the risk involved (from the security perspective) in the particular design of the component composition. The metric is based on the various interactions among the components of the system, plus the processing time taken by each of the components whether components be local bound or remote bound. More the dependencies of a component on other components more complexity in the design which may ultimately result in low performance and may ultimately impact the workability/availability of the information system. The work in the paper gives us an analysis of each component with respect to the dependency on other components and the processing times associated with those interactions. Using the results from the metrics as a reference the design may be altered for better performance of the information system. Since the metric is more inclined towards the software part of the information system, the future scope lies in incorporating more of the other components (hardware, user and network) in the metric as well. Also in the future the work can be extended to distributed computing environment, which involves a complex component based architecture of hardware, software and the network.
 Avizienis, A., Laprie, J. C., & Randell, B. (2012). Fundamental concepts of dependability. Computers & Operations Research, Elsevier.
 Li, B. (2003, September). Managing dependencies in component-based systems based on matrix model. In Proc. Of Net. Object. Days (Vol. 2003, pp. 22-25).
 Rosen, K. H., & Krithivasan, K. (1999). Discrete mathematics and its applications (Vol. 6). New York: McGraw-Hill.
 D. P. Gilliam, T. L. Wolfe, J. S. Sherif, and M. Bishop. ―Software security checklist for the software life cycle.‖ In Proceedings of the Twelfth IEEE International Workshop on Enabling Technologies: Infrastructure for Colaborative Enterprises (WETICE’03), 2003.
 Deswarte, Y., & Powell, D. (2006). Internet security: an intrusion-tolerance approach. Proceedings of the IEEE, 94(2), 432-441.
 Verissimo, P., Correia, M., Neves, N. F., & Sousa, P. (2009). Intrusion-resilient middleware design and validation. Information Assurance, Security and Privacy Services, 4, 615-678.
 Raj, S. B. E., & Varghese, G. (2011, March). Analysis of intrusion-tolerant architectures for Web Servers. In Emerging Trends in Electrical and Computer Technology (ICETECT), 2011 International Conference on (pp. 998-1003). IEEE.
 Wen-ling, P., Li-Na, W., Huan-guo, Z., & Wei, C. (2005). Building intrusion tolerant software system. Wuhan University Journal of Natural Sciences, 10(1), 47-50.
 Wylie, J. J., Bigrigg, M. W., Strunk, J. D., Ganger, G. R., Kiliccote, H., & Khosla, P. K. (2000). Survivable information storage systems. Computer, 33(8), 61-68.
 W. Jansen, ―Directions in security metrics research‖, U.S. National Institute of Standards and Technology, NISTIR 7564, Apr. 2009.
 Neto, A. A., & Vieira, M. (2009, October). Untrustworthiness: A trust-based security metric. In Risks and Security of Internet and Systems (CRiSIS), 2009 Fourth International Conference on (pp. 123-126). IEEE.
 Cheng, Y., Deng, J., Li, J., DeLoach, S. A., Singhal, A., & Ou, X. (2014). Metrics of Security. In Cyber Defense and Situational Awareness (pp. 263-295). Springer International Publishing.
 Qadir, S. and Quadri, S.M.K. (2016) Information Availability: An Insight into the Most Important Attribute of Information Security. Journal of Information Security, 7, 185-194. http://dx.doi.org/10.4236/jis.2016.73014.
 Laprie, J. C.. Dependable computing: concepts, limits, challenges. In Proceedings of the Twenty-Fifth international conference on Fault-tolerant computing (pp. 42-54). IEEE Computer Society.
 Mir, I. A., & Quadri, S. M. K. (2012). Analysis and evaluating security of component-based software development: A security metrics framework. International Journal of Computer Network and Information Security, 4(11), 21.
 García, C. (2016). Reputation management of an Open Source Software system based on the trustworthiness of its contributions.
 Blom, M. (2006). Empirical Evaluations of Semantic Aspects in Software Development.
 Marcus, E., & Stern, H. (2003). Blueprints for high availability. John Wiley & Sons.
 Schwartz, M. (1987). Telecommunication networks: protocols, modeling and analysis (Vol. 7). Reading, MA: Addison-Wesley.
 Bolot, J. C. (1993, October). End-to-end packet delay and loss behavior in the Internet. In ACM SIGCOMM Computer Communication Review (Vol. 23, No. 4, pp. 289-298). ACM.
 M. G., & Karol, M. J. (1988). Queueing in high-performance packet switching. IEEE Journal on selected Areas in Communications, 6(9), 1587-1597.
 Lai, K., & Baker, M. (2000, August). Measuring link bandwidths using a deterministic model of packet delay. In ACM SIGCOMM Computer Communication Review (Vol. 30, No. 4, pp. 283-294). ACM.
 Forouzan, B. A. (2002). TCP/IP protocol suite. McGraw-Hill, Inc.
 Forouzan, A. B. (2006). Data communications & networking (sie). Tata McGraw-Hill Education.