Metric for Evaluating Availability of an Information System : A Quantitative Approach Based on Component Dependency

International Journal of Network Security & Its Applications (IJNSA) Vol.9, No.2, March 2017
DOI: 10.5121/ijnsa.2017.9201 1
METRIC FOR EVALUATING AVAILABILITY OF AN
INFORMATION SYSTEM: A QUANTITATIVE
APPROACH BASED ON COMPONENT DEPENDENCY
Suhail Qadir Mir1
and S.M.K. Quadri2
1
Post Graduate Department of computer sciences, University of Kashmir, India
2
Department of Computer Science, Jamia Millia Islamia, India
ABSTRACT
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.
KEYWORDS
Availability, Metric, Security, Dependency, Information System.
1. INTRODUCTION
The traditional way of dealing with security was to employ the protection mechanisms after the
developmental stages of an Information System [4]. 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 [10]. 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

2
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 [18], furthermore
there are no measurements of availability at the design level. Given the importance of
Availability as a security attribute [13], 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 [1]. 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 [14]. 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

3
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 [16], 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 [13]. 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 [15]:
− Direct Dependency: when the components interact directly.
− Indirect Dependency: when the components interact through intermediate components
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 [2].

4
4. QUANTIFYING DEPENDENCIES
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:
(1)
Therefore the Adjacency matrix AMnxn (aka Direct Dependency matrix DDnxn) for a component
composition involving N components would look like this:
Fig 3 Matrix Direct Dependency
Where,
C1, C2. . . . CN are components
dij is either 0 (no dependency) or 1(dependency)

5
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 [3] 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:
Fig 4 Matrix Full Dependency
Where,
C1, C2. . . . CN are components
fdij is either 0 (no dependency)or 1(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:
− Total-Dependency: of a component Ci is defined as the overall associations of the
component Ci with other components in the component composition.
− Inward-Dependency: of a component Ci is the number of components in the composition
that are directly or indirectly dependent up on the component Ci.
− Outward-Dependency: of a component Ci is defined as the components in the composition
upon which component Ci depends directly or indirectly for its provided functionalities.

6
Next, we quantify Inward-Dependency and Outward-Dependency as Inward-Degree and
Outward-Degree respectively in Full Dependency Matrix.
− Inward-Degree: inDeg(Ci) of a component Ci is the number of components in Inward-
Dependency of component Ci. It is calculated simply by counting the number of 1’s in the
corresponding column j in the FDnxn Matrix. Mathematically the above statement can be
written as:
(2)
− Outward-Degree: outDeg (Ci) of a component Ci is the number of components in Outward-
Dependency of component Ci. It is calculated by counting the number of 1’s in the
corresponding row i in the FDnxn Matrix. Mathematically the above statement can be
written as:
(3)
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 [16] 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:
(4)
Where,
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:
(5)
Where,
inDeg(Ci) or inDeg(Ci) > 0.
The dependency of components C1 + C2 ………. + Cn for the overall system tDep(SyS) becomes:
Where,
N is the number of components in the system.
tDep(SyS) ====
tDep (Ci) ====
(6)

7
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]:
− Processing delay: component’s processing time measured from its invocation to the return
of the results [19].
− Propagation delay: in the case of remote component composition the time taken by the
message to travel from the calling component to the destination component over the
network, excluding the processing and queuing delay [19].
− Transmission delay: in the case of the remote component composition is the time taken to
transmit the message from the calling component to the destination component over the
network [22].
− Queuing delay: in the case of remote component composition the time taken by the
message to enter the queue or leave the queue of a node on the network [21].
From the above discussion, it’s clear that the factors that can impact Availability of the system in
a component composition are:
• inDeg of the component Ci .
• outDeg of the component Ci .
• Delay involved in the dependency chain.
1. Processing delay.
2. Propagation delay.
3. Transmission delay.
4. Queuing delay
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:
IAV(Ci) = (7)

8
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:
Where,
inDeg(Ci) or outDeg(Ci) > 0
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:
(9)
Where,
J=0 for the processing delay of the component itself
Therefore the equation 8 for Availability becomes:
(10)
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:
Where,
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:
IAV(Ci) =
= outDeg(Ci)
= inDeg(Ci)
(8)
IAV(Ci) =
Delay =

9
⇒⇒⇒⇒IAV(Ci)=
Where,
inDeg(Ci) or outDeg(Ci) > 0
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:
Where,
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.
IAV(SyS) =
= outDeg(Ci), Components in out-dependency of Ci
= inDeg(Ci), Components in in-dependency of Ci

10
5.CONCLUSION
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.

11
REFERENCES
[1] Avizienis, A., Laprie, J. C., & Randell, B. (2012). Fundamental concepts of dependability. Computers
& Operations Research, Elsevier.
[2] 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).
[3] Rosen, K. H., & Krithivasan, K. (1999). Discrete mathematics and its applications (Vol. 6). New
York: McGraw-Hill.
[4] 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.
[5] Deswarte, Y., & Powell, D. (2006). Internet security: an intrusion-tolerance approach. Proceedings of
the IEEE, 94(2), 432-441.
[6] 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.
[7] 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.
[8] 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.
[9] 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.
[10] W. Jansen, ―Directions in security metrics researchǁ, U.S. National Institute of Standards and
Technology, NISTIR 7564, Apr. 2009.
[11] 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.
[12] 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.
[13] 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.
[14] 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.
[15] 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.
[16] García, C. (2016). Reputation management of an Open Source Software system based on the
trustworthiness of its contributions.
[17] Blom, M. (2006). Empirical Evaluations of Semantic Aspects in Software Development.
[18] Marcus, E., & Stern, H. (2003). Blueprints for high availability. John Wiley & Sons.
[19] Schwartz, M. (1987). Telecommunication networks: protocols, modeling and analysis (Vol. 7).
Reading, MA: Addison-Wesley.
[20] 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.
[21] M. G., & Karol, M. J. (1988). Queueing in high-performance packet switching. IEEE Journal on
selected Areas in Communications, 6(9), 1587-1597.
[22] 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.
[23] Forouzan, B. A. (2002). TCP/IP protocol suite. McGraw-Hill, Inc.
[24] Forouzan, A. B. (2006). Data communications & networking (sie). Tata McGraw-Hill Education.

Metric for Evaluating Availability of an Information System : A Quantitative Approach Based on Component Dependency

More Related Content

What's hot (18)

Similar to Metric for Evaluating Availability of an Information System : A Quantitative Approach Based on Component Dependency (20)

Recently uploaded (20)

Metric for Evaluating Availability of an Information System : A Quantitative Approach Based on Component Dependency