1

Security Middleground for Resource Protectionin Measurement Infrastructure-as-a-Service

Ravi Akella, Saptarshi Debroy, Prasad Calyam, Alex Berryman, Kunpeng Zhu, Mukundan SridharanUniversity of Missouri-Columbia, City University of New York, The Samraksh Company, USA;

Email: {raxv8, calyamp}@missouri.edu; saptarshi.debroy@hunter.cuny.edu; {alex.berryman, tony.zhu, mukundan.sridharan}@samraksh.com

Abstract—Securing multi-domain network performance monitoring (NPM) systems that are being widely deployed as ‘MeasurementInfrastructure-as-a-Service’ (MIaaS) in high-performance computing is becoming increasingly critical. It presents an emerging set ofresearch challenges in cloud security given that security mechanisms such as policy-driven access to federated NPM services acrossmultiple domains need to be designed carefully to protect MIaaS resources and data. In this paper, we advocate the design of asecurity middleground between default open/closed access settings and present policy-driven access controls of measurement functionsfor a multi-domain federation using a MIaaS. Our approach involves an analytical investigation based on a set of custom metricsto compare and contrast the legacy, role-based and more fine-grained, attribute-based access control schemes to design a securitymiddleground. We implement the chosen middleground with a secured middleware, viz., “OnTimeSecure”. Our middleware enables‘user-to-service’ and ‘service-to-service’ authentication, and enforces federated authorization entitlement policies for timely orchestrationof MIaaS services. Lastly, we evaluate OnTimeSecure in a real multi-domain MIaaS testbed by performing threat modeling and securityrisk assessments to validate the analysis outcomes and demonstrate its effectiveness for easy integration and sustainable adoption.

Index Terms—Network Performance Monitoring System, Measurement Infrastructure-as-a-Service, Security middleground, Policy-driven access, Resource Protection, Risk assessment

F

1 INTRODUCTION

M Ulti-domain network performance monitoring (NPM) sys-tems based on active measurements using tools such as

Ping, Traceroute, OWAMP (for one-way delay measurements)and BWCTL (for TCP/UDP throughput measurements) [1] arebeing widely deployed in both academia and industry. SuchNPM frameworks enable of a Measurement Infrastructure-as-a-Service (MIaaS) through ‘measurement federations’ that providesystem and network performance measurement services to thecross-domain data-intensive HPC applications. More specifically,creation of MIaaS enables collection and sharing of end-to-endperformance measurements in order to identify end-to-end per-formance bottlenecks of such HPC collaborations using anomalydetection [2], optimal network path selection or the forecastingof network weather [3]. Examples of explicit measurement fed-erations that have recently evolved for Internet-wide monitoringinclude perfSONAR [1], SamKnows [4], M-Lab [5], Atlas [6],Ark [7], HoBBIT [8], and m-Plane [9].

Amongst these multi-domain NPM frameworks, perfSONARis the most widely instrumented framework within academia andindustry due to its ease of installation, interoperability standardsdeveloped at Open Grid Forum (OGF), web-service based accessto measurement services and extensibility features due to adoptionof service-oriented architecture principles. Most existing commer-cial products are focused on single-domain deployments, and useproprietary mechanisms for data collection, storage and publish/-subscribe of data archives of current and historic measurements.Latest reports within the perfSONAR community that show over1400 measurement point instances worldwide, and comparisonof perfSONAR with other popular performance measurement andmonitoring systems can be found at [10].

However, deploying the current implementations of perf-SONAR into multi-domain federations at large-scale via MIaaSpresents an emerging set of research challenges in cloud security.Translation of user privileges across domains becomes criticalin order to: protect the MIaaS resources from being used byunauthorized users to launch cyber attacks, mitigate MIaaS re-

This material is based upon work supported by the Department of Energyunder Award Numbers: DE-SC0001331 and DE-SC0007531, and NationalScience Foundation under Award Number: ACI-1440582. The views andopinions of authors expressed herein do not necessarily state or reflect thoseof the united states government or any agency thereof.

source compromise, and limit undesired cross-domain measure-ment tasks through intelligent inter-domain measurement resourceprovisioning. Such cross-domain security requirements motivatethe adoption of authentication and authorization policies to addressfederation issues, such as: Who can initiate active measurementswithin Domain B, or between Domain A and B? Who can view themeasurement archive in Domain B? Does a Domain B user havepriority access to Domain A measurement resources? Apart fromaddressing such ‘user-to-service’ authentication and authorizationissues, security mechanisms such as policy-driven access need tobe designed carefully in MIaaS to also mitigate confidentialityand integrity-compromise of measurement data for inter-domain‘service-to-service’ interactions.

Designing a ‘user-to-service’, and ‘service-to-service’ secu-rity solution becomes non-trivial as the desired solution cannotcompromise the ‘Federated NPM core performance requirements’(e.g., permission manageability, system scalability) that are essen-tial for smooth operation of a MIaaS. Thus, to protect MIaaS re-sources against cyber attacks and information compromises, whileat the same time avoiding performance barriers of wide-adoption(e.g., overheads in setting up federation security mechanisms),the domains need to establish and enforce “measurement levelagreements” [11] (MLAs). However, designing and enforcingMLAs that are mutually agreeable to all domains is difficult,which prompted perfSONAR to recommend the default practice of‘totally open’ implementation mode to run tests on measurementpoints and view data within measurement archives. In this mode,there is minimal regulation imposed by restricting maximumprobing bandwidth utilization for active measurement tools.

Consequently, enterprises that are concerned about undesiredmeasurement tests and data shares in open access mode resortto the other extreme option of a ‘strictly closed’ mode. In thismode, measurement points are not registered with a perfSONARGlobal Lookup Service, and tests can only be scheduled betweenmeasurement points within the firewall by select intra-domainusers, and no measurement archive data is publicly accessible.Although this mode provides increased security, it limits cross-domain performance measurement collection and sharing thatis fundamental to end-to-end federated system monitoring andtroubleshooting bottlenecks over the Internet.

2

Thus, to protect the MIaaS resources without hindering cross-domain sharing, there is a need for an access control based ‘se-curity middleground’ between ‘totally open’ and ‘strictly closed’modes to compose a Resource Protection Service (RPS) bybalancing cross-domain security requirements and NPM corerequirements. Although the related literature [12], [13] comparethe utility of different access control schemes based on industry-standard security metrics, a novel analytical investigation basedon measurable ‘custom metrics’ that reflect both security andcore requirements viz., ‘middleground requirements’ is warrantedin the general NPM context. Such ‘custom metrics’ definitionand subsequent analysis will lay the foundation for intelligentfine-tuning of the middleground requirements to compose a RPSsolution that satisfies federation MLAs.

In this paper, we investigate the design of a ‘Security Middle-ground’ to create a RPS solution that satisfies any given MLAs forinter-domain and intra-domain federation policies. Our approachinvolves defining measurable custom metrics that represent andhelp balance perfSONAR middleground requirements, as wellas comparing and contrasting candidate middleground solutionsthrough rigorous analytical modeling’ of the custom metrics. Wecompare legacy “Role Based Access Control” [14] (RBAC) andthe fine-grained “Attribute Based Access Control” (ABAC) [15]techniques that are commonly adopted within enterprises as candi-date access control solutions. We then utilize the analysis outcometo implement a novel secure middleware viz., “OnTimeSecure”with the desired RPS functionalities. OnTimeSecure is built usingRESTful APIs [16] that are modular, and interoperable withperfSONAR standards based deployments, and it enables perf-SONAR to be integrated with popular federated authenticationand authorization frameworks (e.g., Shibboleth-based [17]). Weevaluate and compare OnTimeSecure dependability performanceagainst ‘totally open’, and ‘strictly closed’ perfSONAR modes ina real-world multi-domain MIaaS testbed through threat modelingand security risk assessments against most common threats, suchas Distributed Denial of Service (DDoS) [18], [19] attacks ac-cording to National Institute of Standards and Technology (NIST)method [20] guidelines. The evaluation results help us validatethe OnTimeSecure RPS composition and access control choicesdictated by the analysis. A summary of the overall contributionsof our work is as follows:

• We detail a set of architecture requirements of federated NPMsystems, and conduct a deep investigation of the challenges withrigorous analytical modeling and subsequent optimization ofa middleground RPS solution for multi-domain measurementorchestration. To the best of our knowledge, our work is thefirst to comprehensively compare access control methods onthe basis of unique NPM federation requirements to arrive at apertinent security middleground solution.

• We demonstrate how to compose a middleground RPS solutionby devising trade-offs for optimization based on intra-domainand inter-domain NPM requirements.

• We develop ‘user-to-service’ and ‘service-to-service’ securityimplementations in our OnTimeSecure middleware that can beused in cloud-based MIaaS for perfSONAR deployments.

• Through real-world implementation, we show how easily andsustainably OnTimeSecure can be adopted in enterprises andvalidated for robustness against cyber security threats.

The remainder of this paper is organized as follows: Section 2discusses the related work. Section 3 details the challenges anddesign requirements of a security middleground solution. Section 4describes the analytical modeling of access control methods forstudying tradeoffs in choosing a security middleground. Sec-tion 5 describes OnTimeSecure middleware implementation anddependability evaluation in a NPM testbed using the NIST riskassessment guidelines. Section 6 concludes the paper.

2 RELATED WORK

With HPC systems crucially relying on the design of next-generation networks due to their data movement needs, the needfor federated NPM frameworks such as perfSONAR [1] has alsoevolved. Through a Central Intelligence System (CIS) that ishosted in a cloud platform (e.g., Amazon Web Services) as partof the MIaaS, various measurement tools placed on MeasurementPoint Appliances (MPAs) are orchestrated to collect end-to-endperformance measurements. A CIS instance runs a measurementrequest brokering service to discover, manage and control a num-ber of strategically placed MPAs in the core and at the edges of thefederation domains. The MPAs act as measurement end-points thathost active measurement tools for end-to-end metrics (e.g., one-way delay, round-trip delay, jitter, loss, TCP/UDP throughput) andcan also interface with other enterprise-related performance metricsources of system (e.g., encoder CPU, Memory), network (e.g.,TCPdump) or application (e.g., Video Frame Rate).

In order to manage and protect the MIaaS resources and end-to-end performance data from unauthorized access, several accesscontrol based middleware methods [21] [22] and security overlaynetworks [23] previously designed are relevant. However, thenetwork community thus far has adopted the most rudimentaryorganizational access control method viz., Role Based AccessControl (RBAC) [14], [24], [25], in deployment solutions of themiddleground. In our earlier work that is focused on the earlyimplementation of OnTimeSecure [26], we show how RBACcan meet the NPM security requirements and designed a basicimplementation of Shibboleth-based [17] federated authenticationand authorization framework. Our earlier implementation alsofeatures a policy-engine that interfaces with a meta-schedulerfrom prior works [11] [26], for prioritization of measurementrequests and conflict-free scheduling, while users concurrentlyattempt to utilize perfSONAR measurement resources. Similarapproaches have been proposed in [27] that uses eduGAIN [28]and X.509 [29] for identifying and managing authorized users inperfSONAR deployments for access control to basic measurementfunctions such as MPA discovery, test initiation and data query.

Due to the fact that inter-domain security policies tend todynamically change in a distributed manner, Attribute BasedAccess Control (ABAC) [30] [31] has been suggested as a so-lution to heterogeneous and dynamic security requirements ofemerging web applications. Moreover, ABAC is being closelyintegrated within shared/federated infrastructures in academia thatalso happen to be one of the largest deployers of perfSONAR.For instance, testbeds such as GENI [32] for federated networkingexperiments, and DeterLab [33] for cyber-security experiments,are considering ABAC for access control of federated resourcessupporting distributed computing applications. Further, the Gridcommunity [35] has also adopted ABAC to address their federatedsecurity and architecture requirements in favor of their earlierapproach of using Grid Security Infrastructure (GSI) in the GlobusToolkit [36] to implement security using Public Key Infrastructure(PKI) [37]. Although ABAC has been observed to perform betterfor inter-domain scenarios, it is known to have performance issuesin an intra-domain setup when domain permissions are pre-definedand static [34] [44]. Moreover, auditing an ABAC implementationis cumbersome for large systems and involves exhaustive enu-meration of the attributes of users and corresponding attributeobjects [34].

To date, middleware based multi-domain methods such as [22]exist, where a selective access of monitoring data is configureddepending on the authentication credentials of the enterprisepartners. In addition, existing works such as [12] [13] comparesecurity solutions for access control on the basis of traditional met-rics such as safety and separation-of-duty. Requirements for accesscontrol in measurement infrastructures have been studied in themPlane [9] effort. Our work similarly identifies the requirementsand also comprehensively compares the relative utility of thetwo most commonly used access control models (i.e., RBAC and

3

Fig. 1. Inter-domain perfSONAR federation hierarchical model with CISsand MPAs

ABAC) based on ‘custom metrics’ that can optimize both securityand core performance requirements of a MIaaS. In this paper,we perform analytical comparison of these generic access controlschemes based on custom metrics relevant to federated NPMsto gauge their hybrid use and limitations in creating the MIaaSsecurity middleground. We particularly build upon best practicesof RBAC/ABAC hybrid approaches [44], the work by authorsin [45] where they verify secured cross-domain RBAC policies,and the work in [39] where chosen middleground implementations(variants of ABAC in their case) were compared.

3 SECURITY MIDDLEGROUND DESIGN CHAL-LENGES AND REQUIREMENTSIn this section, we first describe the NPM federation architecture,and measurement functions that need to be secured. Followingthis, we discuss the elementary security requirements and coreperformance requirements of a MIaaS deployment that need to besatisfied by the security middleground solution.

3.1 NPM Federation Measurement FunctionsA middleground solution in between “totally open” and “strictlyclosed” modes requires an NPM system comprising of a central-ized “Entitlement Service” (ES), which is independent of anydomain as shown in Figure 1, and is used for communicationbetween domains. When a user makes a request for cross-domainmeasurement resources, the ES responds with ‘Yes’ or ‘No’ bytalking to the CISs of the other domains. We can see the hierar-chical cross-domain architecture of MPAs with associated mea-surement tools for obtaining network status of ‘Route Changes’,‘Jitter’, and ’TCP/UDP Throughput’ with specific measurementfunctions (e.g., Schedule task from, View results) for both activeand passive measurements associated with each tool. Each mea-surement function corresponds to a unique ‘permission’ that aparticular user of the federation needs to be mapped to, in order touse the NPM system.

Distributed co-ordination of broker services across co-operating domains (say Domain A, B and so on) allows the devel-opment of federated broker services that comply with mutually-agreeable MLAs to assist in monitoring objectives (such as routinenetwork monitoring, or diagnosing bottleneck anomaly events,or network weather forecasting) related to multi-domain networkperformance management. For e.g., when performance bottlenecksarise, the correlation of anomaly measurement events across theend-to-end network segments can help in both the detection anddiagnosis as part of troubleshooting activities [40].

Within both intra-domain and inter-domain scenarios, accesscontrol needs to be applied when users or services access anyof the measurement functions such as: discover a measurementpoint, add a performance test to schedule upon user request, pushthe schedule to a measurement point, publish measurements into

measurement archive, query the measurement archives for intra-domain performance analysis/visualization transformations, querymeasurement archive to share inter-domain performance trends, ornotify intra-domain user of an anomaly event. We assume that auser or service has ‘permissions’ if allowed to access any of theintra-domain/inter-domain measurement functions.

3.2 MIaaS RequirementsHerein, we discuss the MIaaS requirements that make designing asecurity middleground between ‘totally open’ and ‘strictly closed’modes a non-trivial problem in a typical multi-domain NPMfederation. In particular, we explain how a Resource ProtectionService (RPS) can be composed to balance the cross-domainsecurity requirements and NPM core requirements.

3.2.1 Security and vulnerabilityPermissions can be granted based on federation policies in MLAsthat are mutually agreeable to meet various monitoring objec-tives of domain users. Typically, a MIaaS needs to support alarge number of users, each with their individual monitoringobjectives, while also, more importantly, being secure againstcyber-attacks. The monitoring objectives can differ dependingupon enterprise user roles/privileges. For example, a ‘NetworkOperator’ might want to schedule measurement tests for routinenetwork-wide monitoring. Alternatively, a ‘Power User’ of thenetwork who regularly transfers large data sets over wide-area toremote instrumentation or collaborator/partner sites would want tobe notified if there are any anomalies in network performance thatmight be causing bottlenecks in data transfer throughput. Further,a neighboring domain’s (say Domain B) ‘Power User’ mightwant to schedule a measurement test to diagnose a performancebottleneck along an end-to-end network path traversing DomainA administered links (assuming Domain A and B are alreadypart of a measurement federation i.e., they have shared eachothers’ measurement infrastructure topologies and have agreeduser identity sharing policies). The challenge lies in translatingsuch access privileges across domains and resolving other cross-domain security issues, such as: Will Domain B ‘Power User’ bea ‘Power User’ in Domain A as well? What if those privileges ofbeing a ‘Power User’ are abused in Domain A? Is demoting him to‘Regular User’ in Domain A under-privileging and does it satisfyhis/her monitoring objectives?

We argue that any remote user who is given more permissionsto MIaaS resources than required, or deserved is highly likelyto turn the system vulnerable to unintended threats and potentialabuse of precious MIaaS resources (i.e., hardware and softwareinfrastructure along with expert personnel time/cost to remedy).Such abuse eventually results erroneous measurement outcomescausing performance bottlenecks for both MIaaS and the sup-ported cross-domain HPC applications. Thus, the middlegroundneeds to ensure that the MIaaS is not vulnerable from elementswithin the system due to careless mapping of users to MIaaSresource permissions.

3.2.2 Permissions manageabilityWith cross domain access of MIaaS resources, user privilegestranscend beyond their home domain leading to user permissionmapping in a foreign domain subjected to that domain’s organiza-tional hierarchy. Overlapping domain hierarchies create manage-ability issues caused by redundant permissions associated withmeasurement resources being created and managed, especiallyfor Role based organizational models. Such manageability issuescompound with new sets of domains, measurement resources,or users joining the federation causing performance bottlenecks.Thus, the security middleground solution should aim to ensureefficient maintenance and management of permissions for sharedresources by the network administrator.

4

3.2.3 System scalability

One of the important design criteria of MIaaS facilitating cross-domain data-intensive scientific collaborations is the ability toseamlessly scale with new domains joining the federation withnew sets of users, or new MPAs and associated measurementresources. However, for all practical purposes, in a federated en-vironment with prevalent inter-domain resource sharing, ensuringeasy scaling within the confounds of a federated RPS is easiersaid than done. The overheads associated with adding each newuser/measurement resource impart a ripple effect on the entiremulti-domain federation causing major end-to-end performancebottlenecks. For e.g., adding a new measurement metric viz.,‘Data transfer time metric assuming RoCE (RDMA over Con-verged Ethernet) protocol’ into only one of the MPAs belongingto one of the domains’ CIS may lead to overheads on policyissues, such as: creating permissions for unique MPA-metricresource, creating new privileges for the permissions or addingthe permissions within existing privileges, mapping existing andnew users with the privileges, sharing such mapping informationacross multiple domain, and so on. Thus, the MIaaS securitymiddleground solution needs to prioritize and optimize systemscalability requirements.

3.2.4 Conflict-free scheduling

One of the major problems with end-to-end monitoring of a multi-domain network is scheduling cross-domain measurement requestsinvolving active measurement tools such as Ping, Traceroute,H.323 Beacon, Iperf, and Pathload. These measurement toolsinject test traffic into the network causing multiple concurrentactive measurement tasks to overlap over the same measurementservers or along the same network paths. Overlapping of mea-surement tasks may or may not be problematic, depending onthe measurement tools being scheduled at that particular timeinterval [11] [26]. If a measurement tool such as Ping whichis neither CPU nor channel intensive is being scheduled, over-lapping it with other tools does not affect performance. Suchan overlap is “Concurrent execution”, which improves responsetime; Whereas, Iperf and Pathchar are CPU intensive applications,and overlapping them might lead to misleading results due to“measurement conflicts”. Thus, the security middleground needsto host a meta-scheduler that takes the policy mapping output (i.e.,policy rules) of the measurement requests and produces timetablesof measurement test jobs (i.e., invoking of measurement toolssuch as Ping, OWAMP, BWCTL) for the different measurementfederation MPAs in a conflict-free and federation policy compliantmanner.

3.2.5 Auditability

Finally, for a MIaaS where multi-domain users are assigneddifferent sets of intra-domain/inter-domain permissions based ontheir credentials and/or domain hierarchy, it becomes paramountimportance to have a detailed log of permissions related towho/why/when and how long information is maintained acrossdomains. Thus, a security middleground composition that requiresminimal policy based log-keeping and easy auditability is morepreferable.

3.3 Mapping MIaaS requirements into custom metrics

In order to design an optimal and security middleground between‘totally open’ and ‘strictly closed’, we need to translate thesecurity and core performance requirements of a MIaaS intomeasurable and novel custom-defined metrics. These metricssubsequently form the basis of the middleground mathematicalanalysis and optimization while arriving at the optimal and securedmiddleground solution.

3.3.1 Average resource over-provisioningIn contrast to prevalent metrics such as safety and separation ofduty that are used for access control comparison and model check-ing verification purposes [12], [13], we argue that the vulnerabilityof a MIaaS is compromised fundamentally when measurementresources are over-provisioned i.e., when users are given morepermissions than they require, and in turn increase the risk ofpossible abuse. Our argument is that any internal user of thesystem who is given more permissions than he/she requires ordeserves is potentially more likely to cause a greater performancedegradation to the MIaaS than some attacker from the outsidewith no initial access trying to penetrate into the system. Thus,the number of over-provisioned permissions associated with themeasurement resources is the measure of MIaaS security in termsof access control, with more over-provisioning denoting less asecured posture. We measure normalized average resource over-provisioning as: The ratio of the number of excess permissionsgranted for an average user to the total number of permissionsgranted to that user.

3.3.2 Average permission redundancyAny MIaaS is more manageable in terms of permissions if ithas a lesser number of redundant permissions. Thus, we arguethat the average number of redundant permissions is the measureof system permission manageability, such that the greater the‘Average permission redundancy’, the lesser the ‘PermissionsManageability’ of the system and vice versa. On one hand, where‘Average resource over-provisioning’ is directly related to users,‘Average permission redundancy’ on the other hand is a permis-sion management outcome. If we assume a system with a totalof 5 permissions, a, b, c, d, and e and assume them to be dividedinto 3 roles R1 = {a, b, c}, R2 = {c, d, e}, R3 = {a, c, e}, we canobserve that permissions a, c, and e are redundantly used for twoor more roles. Now, if we assume that a new user’s permissionrequirements are {a, b, e}, then to satisfy this requirement, in aRBAC scenario, the user needs to be assigned either roles (R1, R3)or (R1, R2); thus over-provisioning permission {c} or {d}, whichare different from the redundant permissions. The correspondingnormalized quantification is: Average permission redundancy isthe ratio of the number of redundant permissions in the federationto the total number of permissions in the federation.

3.3.3 Average new mappingsAs the ease of accommodating new elements in any systemis inversely proportional to the amount of interactions/messagesbeing passed, we argue that the MIaaS scalability can be measuredby the number of new mappings that are created and need to bemanaged for the accommodation. We already mentioned that suchaccommodation can occur in cases where a new domain is beingincorporated in the federation, a new MPA is being added into anexisting domain, a new set of measurement tools and resourcesare being added to a single or multiple MPA(s), or a new useris being added to the existing domains. Note that each of thesecases generates a different number of new mappings resultingin different measures of scalability. Average new mappings isquantified as the total number of new mappings/connections thatneed to be created to accommodate an average number of newelements in the NPM federation. However, the value of averagenew mappings is dependent on the type of the element, i.e.,domain, MPA, resource/tool, or user.

3.3.4 Scheduler response timeAs we already established that the security middleground solu-tion needs to host a meta-scheduler service in order to ensure‘Conflict-free’ scheduling of cross-domain measurement tasks,the overall ‘Response Time’ of the meta-scheduler thus reflectsthe scheduling efficiency i.e., scalability of the middlegroundsolution in a cloud context as discussed in [46]. In a typicalMIaaS, a set of measurement tasks can be assigned by users

5

belonging to different domains with different relative priorities.Thus, scheduling non-conflicting cross-domain measurement tasksin a concurrent manner is the key factor for a meta-scheduler toreduce overall response time and ensure successful measurementoutcomes. The middleground solution, i.e., the underlying accesscontrol mechanism, has a profound effect on the meta-scheduler’sability to maintain concurrency because it controls the manner inwhich permissions are assigned to users across domains. Now,with more cross-domain tasks being scheduled, the chances ofthem having conflicts with each other increase, and thus increasesthe probability of the scheduler to run them in a sequential mannerin order to resolve such conflicts. Thus, with more cross-domaintasks, the scheduler response time increases. Now, we argue thatwith more permissions being assigned to the users, higher isthe probability that they are going to exercise such permissions.This in turn results in more cross-domain measurement tasks, andultimately higher scheduler response time. Therefore, we measurethe scheduler response time as: The total number of permissionsassigned to all users, assuming that all the users schedule mea-surement tasks associated with each assigned permission.

3.3.5 Message overheadAny system with low message exchange rate among componentsis easy to audit and keep track of. Thus, we argue that the overall“message overhead” is the measure of system auditability withlow overhead denoting high auditability. We calculate messageoverhead as: The average number of messages exchanged whilemapping a set of users to their assigned permissions. One mightargue that using message overhead to quantify auditability es-sentially makes ‘permissions manageability’ a redundant metric.This is because a higher average over-provisioning will lead toincreased message overhead. In most cases increasing messageoverhead can lead to over-provisioning and vice versa. However,this observation is not universal as the number of messagesexchanged to map one user to a single permission may overcomethe effect of overall permissions over-provisioning. Thus, it isonly fair to use both ‘average permissions over-provisioning’and ‘message overhead’ as performance metrics of a securitymiddleground solution.

Our overall approach to compose the MIaaS security mid-dleground and to enforce it through the RPS is demonstratedin Figure 2. The first step involves the process of convertingthe MIaaS requirements into custom metrics, and then estab-lishing the relative merits and drawbacks of candidate accesscontrol techniques (RBAC/ABAC) for inter-domain and intra-domain scenarios based on the custom metrics. The optimal accesscontrol choices for both the scenarios are then used to compose‘user-to-service’ and ‘service-to-service’ protocol solutions whichare finally enforced as the desired MIaaS security middlegroundby the RPS. The user-to-service solution will be part of thesoftware design and capabilities within the ‘Authentication andAuthorization Service’, and the ‘Resource Protection Service’ ofthe ‘Security Layer’ within the perfSONAR stack, whereas theservice-to-service solution will be part of the software design andcapabilities within the ‘Infrastructure and Data Layer’.

4 MIDDLEGROUND MODELING AND ANALYSISIn this section, we first overview the two candidate access controlchoices for middleground RPS composition. Then, we presentdetails of mathematical modeling and analysis of the accesscontrol schemes based on the custom metrics for both intra-domain and inter-domain MIaaS scenarios. Finally, we presentsimulation experiment results that validate the analysis trends.

4.1 Access Control Choices for Middleground RPSOur choice of RBAC [14], [24], [25] and ABAC [30] [31] ascomparison candidates stems from the fact that they represent thetwo most generic access control types in multi-domain federations.

Fig. 2. Multi-domain MIaaS security middleground RPS composition

(a) RBAC scheme (b) ABAC scheme

Fig. 3. Users’ access to permissions for RBAC and ABAC choice

Figure 3(a) shows the RBAC approach that can be used to mapmulti-domain users to permissions (i.e., measurement functions)for achieving a security middleground. Here, the federation usersare mapped into ‘Roles’ that allow them to control relevantpermissions assigned to those ‘Roles’. Users can be a part of oneor more Roles (e.g., Network Operator, Power User, Regular User)that generally depend on institution-level personnel status of users(e.g., student, faculty, engineering staff). In some implementation,users are mapped into active directory groups and subsequentlythe groups are mapped in one or more roles. Moreover, Roles canbe assigned priority levels that are useful when there is contentiondue to multi-domain users concurrently attempting to utilize mea-surement resources in an intra-domain or inter-domain manner.The priority levels can be set to order measurement requests basedupon User Role (e.g., Network Operator Role users always havehigher priority than Power Users), or Domain Type (e.g., Intra-domain measurement requests have higher priority than Inter-domain measurement requests). In contrast, Figure 3(b) shows theABAC approach that inherently provides much more fine-grainedaccess by directly mapping multi-domain users to permissions.Federation users are handled using a ‘Lock-and-Key’ mechanismwhere each measurement function has a unique bit pattern (i.e.,‘Lock’), and only authorized users with the pertinent attributes(i.e., ‘Key’) are able to “unlock” the measurement function.4.2 Security Middleground Modeling and AnalysisWe now present the performance comparison between RBAC andABAC schemes based on the custom metrics described earlierthrough mathematical modeling and analysis. Each custom metricanalysis is followed by MATLAB numerical simulation to pictori-ally represent the characteristics of the corresponding metric withdifferent system variables.

Although the user-permission and user-role relationship in anoperational setting is time variant, we have considered a discreteevent model in our analysis for simplicity. Thereby, instead of

6

TABLE 1Notations used in the security middleground analytical modeling

p Number of unique permissions for access controlr Total number of roles created for RBAC solutionu Total number of users/subjectspr Number of permissions per roleur Number of users belonging to a particular roleru Number of roles a user belongs to

Amsg Number of messages transferred per ABAC interactionRmsg Number of messages transferred per RBAC interactionC Concurrency factor

modeling the relationship as a function of time, we have varied thesystem variables of the relationship, such as the number of users,number of roles, and number of permissions. This approach servestwo purposes: (a) it does not compromise the model generality,and (b) it accounts for scenarios where values of the time variantmodel elements are different. Table 1 lists the notations used inour analytical modeling detailed in the following.

4.2.1 Average resource over-provisioningWe already explained that for any MIaaS, when an authorizeduser is over-provisioned, i.e., user is given more permissions toresources than necessary, it creates system vulnerability issues.More specifically, it makes the system vulnerable to cyber attacksand increases potential MIaaS resource abuse in both intra-domainand inter-domain measurement contexts. Let us consider a multi-domain federation hosting MIaaS with u users and p uniquepermissions to resources with each user requiring access to kresources and an equal number of permissions. For an ABACimplementation, u users are mapped directly to p permissionstailored for the specific user requirements. According to theaverage resource over-provisioning definition, for such ABACimplementation, there are no over-provisioned permissions for anyuser due to direct user-to-permission mapping. Thus,

Avg. ResOverProv.ABAC = 0 (1)In a RBAC implementation, we assume that p permissions

are organized into r roles, and u users are grouped into ggroups which are again mapped into roles. Such three tier user-permission mapping is non-trivial to model for steady-state dueto relational properties between users to groups, and group toroles. Permissions overlapping among roles makes modeling suchrelations even more difficult for steady state scenarios. In order toperform a fair comparison, we consider RBAC best-case scenarioin terms of permission redundancy with no permissions beingoverlapped among roles. Thus, the number of permissions per roleis given as:

pr =p

r(with p > r) (2)

We also assume a one-on-one group-role mapping to reducecomputational complexity without any loss of generality, whichessentially reduces the user-group mapping into user-role map-ping. In order to model the nature of such user-role mapping, theeffective limiting condition for any realistic user-role relation willbe the fact that all the roles assigned per user should cover all kpermissions required by the user, and each such assigned role willhave at least one common permission with the set of k requiredpermissions. Thus, the probability of any user ut being mapped toi roles is expressed as:P{ut 7→ i} = P{P (i) ⊇ {k}} × P{P (j) ∩ {k} ≥ 1

: (∀ j ∈ {r} & j 6= i)}

=( 1

|P (i)|× 1

|P (i)| − 1× · · · × 1

|P (i)| − (k − 1)

)× P{k ≥ i}

=( k−1∏

l=0

1

i× pr − l

)× P{k ≥ i} (3)

where P (i) and P (j) are the number of permissions in roles i andj respectively, {k} is the set of k roles, and {r} is the set r roles.We use Eqn. (3) to evaluate the average number of roles that anyuser ut is mapped into and it is expressed as:ruavg = E[Number of roles a user is mapped into]

= 1× P{ut 7→ 1}+ 2× P{ut 7→ 2} · · ·+ r × P{ut 7→ r}

=r∑

i=1

i× P{ut 7→ i} (4)

Thus, the average resource over-provisioning in a RBACimplemented system is given as:

Avg. ResOverProv.RBAC =ruavg × pr − k

ruavg × pr(5)

Average resource over-provisioning characteristics comparisonbetween RBAC and ABAC solutions for different values of p(from Eqns. (5) and (1)) is shown in Figure 4(a). We observethat RBAC performance deteriorates with more permissions (i.e.,resources in the system), before saturating at worst case value(value 1). This in turn signifies worst performance in an inter-domain scenario with more resources and corresponding permis-sions, whereas ABAC over-provisioning is independent of thenumber of unique permissions.

4.2.2 Average permission redundancyLet us assume that there are p permissions that define access toall the measurement functions in a federation. Consequently, thenumber of roles that can be created with 1 permission from the setof p permissions is

(p1

); the number of roles that can be created

with 2 permissions from the set of p permissions is(p2

), and so on.

Hence, the maximum number of roles that can be created using ppermissions is given by:

rmax =

(p

1

)+

(p

2

)+ · · ·+

(p

p

)=

p∑i=1

(p

i

)= 2p − 1

The number of roles that can be created with p permissionsthus varies from 1 to rmax (2p − 1). However, in an average casescenario, it is not possible to gauge the actual number of rolescreated as such role creation is dependent on other environmentalfactors (such as: user requirements, domain requirements, or orderof user arrival affecting role creation) which are non-trivial tomodel. In an average case, all the possibilities of the number ofroles are equally likely. Thus, expected number of roles createdwith p permissions is given by:

ravg = E[Number of roles] =1 + 2 + · · ·+ rmax

rmax

=rmax + 1

2= 2p−1 (6)

Now the number of permissions in each role is also a functionof the personal preferences of the System Administrator (i.e.,the Role Assigner), which in turn depends on the environmentvariables mentioned earlier. However, on an average, the numberof permissions in a role may vary from 1 to p assuming there areno duplicate permissions per role. Thus, the average number ofpermissions per role is given by:

pravg = E[Number of permissions per role] =1

p

p∑i=1

i

=p + 1

2(7)

The total number of permissions associated with all the rolesin an RBAC implementation is given as:

ravg × pravg = (p + 1)× (2p−2) (8)Next, we calculate the number of redundant permissions

among (p + 1) × (2p−2) permissions in all of the roles. Forthis, let us assume that there are 3 unique permissions a, b, cfor a RBAC solution. Therefore, the maximum number of roles

7

(a) Over-provisioning of resources compari-son between RBAC and ABAC

(b) Illustration of policy manageability com-parison between RBAC and ABAC

(c) Scheduler scalability comparison betweenRBAC and ABAC

Fig. 4. Over-provisioning, redundancy, and new mappings comparison between RBAC and ABAC

that can be created with these 3 permissions is 7, and thoseroles are represented by the set of different combination ofthose 3 permissions expressed as {a},{b},{c},{a,b},{a,c},{b,c},and {a,b,c}. We remark that - except for the first 3 roles, i.e.,{a},{b}, and {c}, any other roles contribute to redundancy asthey have repetitions of the 3 basic permissions. Roles such as{a,b},{a,c},{b,c}, and {a,b,c} are redundant as they contain acombination of permissions that are previously defined. The totalnumber of redundant permissions in this case are 3 a’s, 3 b’s, and3 c’s. Thus, average redundancy is quantified as ‘the differencebetween the number of assigned permissions and the number ofunique permissions over the number of assigned permissions’.

Therefore, the average number of redundant permissions in aRBAC solution is given by,

Average RedundancyRBAC =ravg × pravg − p

ravg × pravg

=(p + 1)× (2p−2)− p

(p + 1)× (2p−2)(9)

It is interesting to see that average permission redundancy forRBAC is only a function of the number of unique permissions inthe system p. This is intuitive as although in RBAC, the creationof roles depends on the orientation of permissions among theresources, which is in turn dependent on how the roles are created.The occurrence of any permission more than once is redundant andcreates manageability issues for the MIaaS. On the other hand, foran ABAC implemented MIaaS, Average RedundancyABAC = 0 asthere are no redundant permissions due to the direct nature of user-to-permission mapping. Pictorial comparison of this characteristicusing MATLAB is shown in Figure 4(b) that depicts RBACperformance rapidly deteriorating with increasing p similar toFigure 4(a), while ABAC performing better with 0 redundancy.

4.2.3 Average new mappingsScalability of a system is determined by the ‘ease’ of incorporatingnew ‘subjects’ into the existing system. In an access control policyimplementation, such ‘subjects’ correspond to users, domains inthe federation, MPAs within a domain, or measurement functionsassociated with a MPA. However, we remark that an increasein any of such ‘subjects’ eventually leads to increased controlmessaging, which can be used as a measure of the ‘ease’ ofincorporation. Thus, for reducing mathematical redundancy andfor analysis simplification purposes, we measure system scalabil-ity by the number of new mappings required to provide the newusers with suitable permissions. Let us assume that in an ABACimplementation, the system needs to scale up to accommodaten users with each requiring on an average o permissions. Theattribute sets for n such users can be represented as,

User1 = {p11, p12, p13, · · · , p1o}User2 = {p21, p22, p23, · · · , p2o}

.

.

Usern = {pn1 , pn2 , pn3 , · · · , pno}

Now a new user may require 1 permission, or 2 permissions,or so on till p permissions depending on their privileges witheach permission resulting in one mapping. Therefore, the averagenumber of new permissions p̄ or average number of new mappingsis expressed as:

p̄ = E[Number of permissions requested per user] =

p∑i=1

i

p(10)

Thus, the number of new mappings involved to scale an ABACsystem for n new users with each requiring p̄ permissions on anaverage is given as,

MappingsABAC = n× p̄ = n×

p∑i=1

i

p(11)

In a RBAC implementation, let us assume that the RBACsystem has r roles. A new user who is entering the system submitsa set of requirements and then requests for policy mapping to roles.Based on the user’s requirements, he/she can be mapped to 1 role,or 2 roles and so on till r roles. Therefore, similar to Eqn. (10)analysis, the average number of roles a new user can belong to isgiven as,

r̄ = E[Number of roles a user belongs to] =

r∑i=1

i

r(12)

Thus, the number of new mappings involved to scale a RBACsystem for n new users with each being included into r̄ roles onan average is given as,

MappingsRBAC = n× r̄ = n×

r∑i=1

i

r(13)

As for any real implementation, r << p, and thereforewe can conclude that on an average MappingsRBAC <<MappingsABAC . However, it is to be noted that the worst casefor a ABAC or RBAC system manifests when each new useris required to be mapped to all permissions (p) or all roles (r),respectively. In contrast, the best cases for both access controlpolicies are when the number of required mapping is 1. Thus,

MappingsRBAC |WorstCase = u× r

MappingsABAC |WorstCase = u× p

MappingsRBAC |BestCase = MappingsABAC |BestCase = u

In Figure 4(c), we show pictorial comparison of scalability per-formance between ABAC and RBAC solutions (from Eqns. (11)and (13)) using MATLAB. We observe that for realistic values of rand p, RBAC performs considerably better than ABAC in terms ofaverage new mappings required. It is to be noted that in scenarioswhere r = p, ABAC and RBAC perform similarly; however,such scenarios are highly unlikely for a realistic implementation.It is interesting to note that such scalability characteristics of

8

ABAC and RBAC are not specific to inter-domain or intra-domainscenarios because the condition r << p holds true for bothscenarios within a MIaaS.

4.2.4 Response TimeAny multi-domain federation supporting a MIaaS requires usersto be initially assigned permissions to access certain resourcesacross the federation, followed by the same users using eachassigned permission to schedule measurement tasks betweenMPAs of different domains. Recall that measurement jobs withactive measurement tools need to be scheduled in a conflict-freemanner. Thus, response time of the scheduler within a particulardomain is directly proportional to the number of concurrentlyscheduled measurement tasks involving this domain in the fed-eration. In order for the MIaaS to accurately detect and diagnosemulti-domain network status, it is of paramount importance thatthe security middleground solution ensures minimal number ofconcurrent measurement schedules to effectively minimize thescheduler response time. However, it is nontrivial to estimatethe number of concurrently scheduled measurement tasks as itis a function of other incidental and environmental variables inuser’s monitoring objectives. Therefore, in order to perform afair analytical comparison between RBAC and ABAC inspiredmiddlegrounds in terms of scheduler response time, we argue thatthe total number of permissions assigned to all users can be usedas a measure to evaluate response time, assuming all the usersare trying to schedule measurement tasks associated with eachpermission.

Now for a RBAC inspired middleground, a user may beassigned 1 role, or 2 roles, or so on till r roles based on his specificmonitoring objective requirements and user credentials. Thus, theaverage number of roles that can be assigned to a user is given by,

ruavg =1 + 2 + 3 + · · ·+ r

r

=r × (r + 1)

2× r

=r + 1

2(14)

Similarly each role can contain 1 permission, or 2 permissions, orso on till p permissions. Thus, the average number of permissionsper role is given by,

pr =1 + 2 + 3 + · · ·+ p

p=

p + 1

2(15)

We previously already argued that the total number of assignedpermissions to u users is equal to the total number of concurrentmeasurement tasks, which in turn can be used as a measure ofscheduler response time. Thus, from Eqns. (14) and (15), theresponse time for RBAC is expressed as,

RespTimeRBAC = u× ruavg × pr

= (u)(r + 1

2)(p + 1

2) (16)

However, the scheduler response time in ABAC is the productof the total number of users with only the average number ofpermissions assigned to a user due to the direct user-permissionsmapping. Thus, the response time for ABAC is given as,

RespTimeABAC = u× up

= (u)(p + 1

2) (17)

Pictorial comparison between RBAC and ABAC in terms ofscheduler response time from Eqns. (16) and (17) is shown inFigure 5(a) using MATLAB. We see that the extra multiplier ofr+12 in Eqn. (16) causes RBAC to perform poorly in comparison

to ABAC in terms of scheduler response time. With more users,both ABAC’s and RBAC’s performance deteriorates with RBACshowing steeper performance degradation. We can also observethat - with the same number of permissions and more rolesin the system, which is a more likely scenario of inter-domain

measurement scheduling, RBAC performance degrades. However,due to the direct nature of user-permission mapping, ABACperformance in terms of response time is independent of cross-domain measurement tasks scheduling.

In the above discussion of scheduler response time, we as-sumed that the scheduler processes all scheduled measurementtasks sequentially without any parallel processing of measurementjobs. However, enabling the scheduler to be able to schedule anumber of measurement tasks in parallel reduces the responsetime, preserves the measurement data integrity and thus improvesthe system efficiency. For this purpose, we adopt the ConcurrencyFactor index for the security middleground solution design, anduse it to define the maximum number of non-conflicting tasksthan can be run in parallel without affecting the bandwidthrequirements of other application (non-measurement) traffic. Wedenote the concurrency factor with variable C; C = 3 signifiesthat the scheduler is able to concurrently schedule a maximum of3 non-conflicting measurement tasks.

Thus, including the provision of MLA in measurement jobscheduling results in an updated response time for a securitymiddleground solution which is given as,

RespTimeConcRBAC =

⌊RespTimeRBAC

C

⌋+ RespTimeRBAC

RespTimeConcABAC =

⌊RespTimeABAC

C

⌋+ RespTimeABAC

(18)Now from Eqns. (16), (17), and (18), we can formulate,

RespTimeConcK =

⌊RespTimeK

C

⌋+ RespTimeK

where, RespTimeK for any access control scheme K is expressedas,RespTimeK = No. of users× Avg. no. of 1st hierarchy elements

per user× Avg. no. of 2nd hierarchy elements per 1st hierarchyelement× · · · and so on

Now when K = RBAC, number of hierarchies are two, viz.,roles and permissions, and thus we calculate average numberof roles per user, and average number of permissions per role.Whereas, for K = ABAC , there is only one level of hierarchy,and thus we calculate the number of permissions per role.

(a) Scheduler response time comparison (b) Response time for different MLA

Fig. 5. RBAC, ABAC scheduler response time comparison

We pictorially show the characteristics of the above equation inFigure 5(b) for low (C = 1) and high (C = 10) concurrency. Weobserve that - although RBAC response time performance is worsethan ABAC for any value of C , RBAC performance degradeswith higher p (i.e., in inter-domain scenario) and is more severewhen concurrency is low. With more concurrency (higher C)possibility as a result of fewer conflicts among measurement tasks,RBAC response time performance improves and is comparablewith that of ABAC. Thus, we can infer that RBAC is not a prudentsolution choice in terms of scheduler response time for inter-domain measurement scenarios, where the number of resourcesare limited or the measurement tasks have high resource conflictfactors.

9

4.2.5 Message OverheadWhen users initially authenticate with the system and requestaccess to measurement functions, there is typically a lot of mes-sage exchange between the Resource Provider and the ResourceRequestor causing high increase in the auditability complexity.Thus, the overhead caused due to message exchange is a keyperformance metric that any access control scheme should min-imize to keep easier audit trail in the multi-domain federation. Inthe following, we compare the RBAC and ABAC solutions byquantifying the amount of message overhead incurred by each ofthem.

For simplicity of the analysis, let us assume that Amsgrepresents the number of messages exchanged between the Re-source Provider and the Resource Requestor for a single ABACpermission assignment to a user, andRmsg represents the numberof messages exchanged for a single RBAC role assignment toa user. For an ABAC implemented system, the total number ofmessages exchanged for one user requesting an average of puavgpermissions is expressed as puavg ×Amsg . Thus, for u such users,the total number of messages exchanged can be given by,

MessagesABAC = (puavg ×Amsg)× u

= u× (p + 1

2)×Amsg (19)

Similarly for a RBAC implemented system, the total numberof messages exchanged for u users with each being a part of agiven average ruavg roles will be,

MessagesRBAC = = (ruavg ×Rmsg)× u

= u× (r + 1

2)×Rmsg (20)

Although comparison of Eqns. (19) and (20) through sim-ulation is unintuitive and unfair due to the lack of commonvariables, we argue that for all practical implementation purposes,Rmsg < Amsg and r < p. Therefore, we remark that for intra-domain scenarios, where r is relatively smaller than p, RBACperforms better as MessagesRBAC < MessagesABAC. However,for inter-domain scenarios, where there is role explosion, r iscomparable to p, and there is not much difference between theABAC and RBAC approaches.

4.2.6 Analysis correctness validation through simulationWe simulated the RBAC and ABAC based middleground solutionsfor multi-domain federations mimicking a MIaaS in Java in orderto validate the correctness of our analysis. We vary the totalnumber of permissions in the system from 2 until 24. For each setof permissions we generate a random number of roles for RBAC.Afterwards these roles are mapped to random permissions, wemake sure that every permission in the permission set is present inat least one role, and there is no permission redundancy withina role. The users are mapped randomly to a number of rolesuntil the users’ permission requirements are fulfilled. Similarlyfor ABAC scheme, the users are randomly mapped to permissionsuntil their requirements are fulfilled. The user requirements arealso randomly generated for both the schemes. This procedureensures complete randomness in the system setup, thus exhibitingaverage case outcomes.

We calculate the ‘Average redundancy’ by going through allthe roles and checking how many unique permissions are redun-dantly distributed across the different roles. Then the ‘Averageredundancy’ is calculated by dividing the number of redundantpermissions with the total number of permissions in the systemin all the roles. We also calculate ‘Average over-provisioning’ bycalculating the number of permissions requested by a user andthen subtracting it from the total number of permissions allottedto the user. Dividing this value by the total number of permissionsallotted to the user gives us the ‘Average over-provisioning’. The‘Average redundancy’ and ‘Average over-provisioning’ values arecalculated for the selected number of permissions in the system inthe set {4, 8, 12, 16, 20, 24}. Figures 6(a) and 6(b) represent the

‘Average permission redundancy’ and ‘Average over-provisioning’characteristics with x-axis representing the number of uniquepermissions in the system. We can observe that the nature of ourmathematical model and simulation results closely match, whichverifies the correctness of our mathematical model.

(a) Average permissions redundancy sim-ulation results

(b) Average resource over-provisioningsimulation results

Fig. 6. Simulation results for RBAC and ABAC based middlegrounds

4.2.7 Middleground RPS OptimizationFollowing the completion of the modeling and analysis of thesecurity and core performance requirements, the next step in ourapproach is to optimize the federation MLAs and perform intra-domain and inter-domain trade-offs on the basis of a MIaaS fora typical multi-domain federation. The optimization outcome willbe the middleground RPS access control composition for inter-domain and intra-domain scenarios, which satisfies all the securityand core performance requirements of a federated NPM system.

We remark that - although the modeling and analysis is genericfor any federated NPM system, the corresponding optimizationfor middleground RPS composition is specific to the uniquerequirements of a measurement federation design. Researchersand network designers should carefully consider the most per-tinent performance metrics based on their unique architecturerequirements in order to compose their security middleground.The proposed optimization and metric trade-offs method is onesuch approach for a perfSONAR-specific implementation, wherethe outcome in terms of access control choices are shown inTable 2. We argue that the ideal security middleground RPScomposition to satisfy the security and core performance require-ments of a perfSONAR federation is a combination of RBACbased intra-domain policy engine and ABAC-based inter-domainpolicy engine. In the next section, we describe how we use thisinsight to design our OnTimeSecure middleware with ‘user-to-service’ and ‘service-to-service’ integration, and address multi-domain monitoring objectives in a federated NPM system.

5 ONTIMESECURE PROTOCOL IMPLEMENTATIONAND EVALUATION CASE STUDYIn this section, we first describe OnTimeSecure middleware designthat has two main protocol components: user-to-service, andservice-to-service. User-to-service interactions happen when userperforms a login into the portal, or it may involve the users’device interacting with the services for accessing the variousmeasurement functions. The user-to-service component is furtherdivided into authentication of legitimate users, and authorizationof access to pertinent measurement resources. On the other hand,the service-to-service design component deals with mutual au-thentication between services that autonomously orchestrate witheach other solely based on the identity of the service. Service-to-service component further consists of MPA discovery protocol andmessage encryption to protect confidentiality and authenticity.

Following the description of the OnTimeSecure middlewaredesign, we evaluate the dependability of OnTimeSecure throughan exemplar case study in a multi-domain NPM testbed withMIaaS. In the evaluation discussion, we first describe the testbedsetup with actual users and explain how we perform a threat

10

TABLE 2Middleground RPS composition through federation MLA optimization and metric trade-offs

Federation MLAs Corresponding metric optimization Access Control OutcomeFewer system vulnerabilities Optimizing average resource over-provisioning Inter-domain ABAC

Better resource management across domains Optimizing average permission redundancy Inter-domain ABACBetter Scalability for intra-domain access Optimizing average new mappings Intra-domain RBACConflict-free scheduling across domains Optimizing scheduler response time Inter-domain ABAC

Better audit-trail within domains Optimizing message overhead Intra-domain RBAC

modeling and security risk assessment study based on overallattack likelihood and impact factors.

5.1 User-to-Service Protocol Design, Capabilities5.1.1 Authentication & authorizationIn order to determine whether a user is legitimate (authenti-cate) and thereafter grant appropriate privileges to access themeasurement resources (authorize), the CIS interfaces with theIdentity Provider(s) (IdP). The Identity Provider is an independentbody outside any domain, and is used to pass authenticationinformation from the user to the CIS. Our current implementationof OnTimeSecure interfaces the CIS with Shibboleth-based IdPbecause it provides a solid platform for extensibility and wideadoption i.e., Shibboleth infrastructure are based upon SecurityAssertion Markup Language (SAML) [41], which is an open-standard already being used within perfSONAR communities inacademia and industry for exchanging authentication information.The CIS acts as a Service Provider (SP) for the perfSONAR user,by validating users credentials, and thus providing the users accessto measurement resources based on their permissions. We alsoassociate a unique X.509 certificate with each user, that is used fortying users to permissions, and also used for uniquely identifyingthe user [27]. We also create a unique APIKey/APISecret pair foreach user, that is used by his/her device for authenticating itselfwith the CIS system in a ‘device-to-service’ communication. TheAuthentication and Authorization is independent of home/foreigndomain access scenarios as it involves only verifying users’credentials and thereby providing access to resources allotted andthus is not specific to RBAC/ABAC implementation.

The basic workflow for service authentication and authoriza-tion with users or devices is shown in Figure 7. In a ‘user-to-service’ case, the user firstly requests access to a resource, and isthereby re-directed to the Identity Provider (IdP) to login. Afterthe user submits his/her credentials along with the home domainname, the IdP presents user’s credentials to the home domain CIS,which validates the credentials. After validating, the CIS retrievesthe unique X.509 certificate and thus provides the user accessto resources by retrieving the permissions tied with his X.509certificate. Whereas, in a ‘device-to-service’ case, the devicesends a RESTful request to home domain CIS containing the‘APIKey/APISecret’ for authenticating the device, and a resourcerequest. The CIS similarly retrieves the permissions associatedwith the corresponding X.509 and grants access to the device.

Fig. 7. Sequence diagram for service authentication and authorization

Fig. 8. Components and workflow for access control in OnTimeSecureusing intra-domain RBAC and inter-domain ABAC showing messagesexchanged for intra-domain (red), inter-domain (green), and commonscenarios (blue)

5.1.2 Access provisioning

The ‘Access Provisioning Layer’ deals with the policy mappingof permissions to the users. Using the mathematical analysis andoptimization outcome, we use RBAC for intra-domain and ABACfor inter-domain resource provisioning as shown in Figure 8. Thedomain CIS hosts the ‘Switching Point’, ‘Administration Point’and the ‘Enforcement Point’. The Switching Point checks forthe incoming users’ request and makes a decision on whether toprovision resources using RBAC or ABAC policy engine basedon whether the requesting user belongs to that domain or aforeign domain. The ‘Entitlement Service’ developed as a part ofOnTimeSecure is used for communication between domains whenan inter-domain access is initiated. The Entitlement Service residesoutside any of the domains, and is used only for the purpose ofinter-domain communication. We believe that, any entity that isoutside a given domain, should not contain any security informa-tion pertaining to the domain, as this could compromise the infor-mation security of the domain. Thus, the Entitlement Service onlyfacilitates the authentication and authorization communicationsrequired between different domains. Given that the EntitlementService only sends requests and responses back and forth as shownin Figure 8, there is minimal overhead involved in the mediation.The permissions allotted to a user are associated with his/herunique X.509 certificate, and the validity of the permissions for auser is determined by their X.509 certificate. The AdministrationPoint is responsible for managing and creating permissions withrespect to the measurement functions in the MPAs. For example,if a new measurement function called “TCP throughput” hasbeen created in MPA-1, it needs to create a permission for thismeasurement function, which can be delegated to the users. Lastly,the Enforcement Point enforces the policy decisions made by therespective ‘Policy Decision Points’.RBAC based intra-domain policy engine: The RBAC basedpolicy engine keeps track of users mapping to ‘Groups’, ‘Groups’mapping to ‘Roles’ and thus ‘Roles’ mapping to permissions.Thus, the record of which permission is assigned to which user ismaintained by verifying which Group the user is mapped to, andwhich Role does that Group possess. The first main component of

11

the RBAC based policy engine is the ‘Policy Mapping Point’,which is responsible for allowing existing users access to therequested permissions. Whenever new user requirements arrive,it passes the user’s credentials to gather the corresponding user-group, group-role, and role-permissions information from the‘Data Engine’, and then forwards the information to the ‘PolicyDecision Point’.

The second component is the ‘Policy Decision Point’ thatmakes a decision on the user’s request based on the user-group-role-permission mapping information. For e.g., if a user is nothierarchically mapped to certain permissions, then the requestfor that permission cannot be granted to the user. The thirdcomponent is the ‘Data Engine’, which is a database that storesall the mapping information pertaining to users, groups, roles, andpermissions.ABAC based inter-domain policy engine: The ‘EntitlementService’ co-ordinates the communication between the domainsfor setting up the inter-domain resource provisioning to users. Itmaintains details of the CIS of all the domains, and thus servesas a medium of communication between the domains. Whenevera user requests permissions from the other domain, the CIS ofthe users’ home domain contacts the Entitlement Service for thedetails of the foreign domain CIS, for which the EntitlementService responds with the CIS details. The CIS of the homedomain then submits the users’ requirements in an XACML [42]file to the foreign domain CIS. The foreign domain CIS then sendsthe request to ABAC based policy engine and makes a decision onthe access depending on the policy engine output. The first majorcomponent of the ABAC based inter-domain policy engine is the‘Policy Information Point’, which contains information about theSubject, Resource and Environment attributes. It also containsa mapping of the user from foreign domain (subject attributes),which permissions the user has reserved (resource attributes), andfor how long the user has reserved the resource (environmentattributes). For e.g., it checks the users’ permission mappinginformation along with the environment variable to determine ifthe users’ access has expired. In case of permission expiration, itinforms the ‘Policy Decision Point’ and prevents the user fromperforming any actions on this resource.

The second component is the ‘Policy Decision Point’, whichis similar to the RBAC based one in that, it also makes a decisionon access control for the user. For e.g., whenever a user from aforeign domain requests access to a resource for the first time,the Policy Decision Point analyses the users’ attributes and thenmakes a decision on whether to grant access to the user and forhow long, by co-ordinating with the users’ home domain CIS.

5.2 Service-to-Service Protocol Design, CapabilitiesThe service-to-service design and capabilities deal with mutualauthentication between services that autonomously orchestratewith each other solely based on the identity of the service.Below we present OnTimeSecure service-to-service discoveryscheme for initial pairing of the CIS and MPAs in which keysare securely exchanged, and are subsequently used to createdigital signatures for confidentiality and authenticity of messagesexchanged between the services.

5.2.1 MPA discovery protocolThe MPA Discovery involving pairing of the CIS and the MPAsis initiated through a web UI on the CIS such that only userswith appropriate permissions can add and configure new MPAs.Figure 9 shows the MPA discovery protocol that follows thePretty Good Privacy (PGP) standard [43] principles. The MPAsto be added are deployed at strategic points within the topologyof the network and are set as being “discoverable”. Following thephysical set-up and configuration, an authorized user can initiatethe MPA Discovery protocol through the CIS web UI. The CISholds a valid SSL certificate, allowing the CIS’s identity to be

Fig. 9. MPA discovery protocol flow diagram

verified by the MPAs using the normal X.509 certificate chainingmodel. The MPAs use a self-signed SSL certificate and a publicRSA key to define their initial identity to the CIS. On initiationof a subnet scan from the CIS, an MPA responds with an AESEncrypted bundle containing its public key, and other pertinentstate information (e.g., NAT status, software version, measurementfunctions supported). The CIS decrypts the bundle and presentsthe information to the requesting user for verification. After userapproval of the MPA’s identity, the CIS generates an encryptedbundle containing the ‘APIKey’/‘APISecret’ pair that is sent andstored securely in the MPA using access control lists (ACLs)provided by the Linux file system in order to limit the readabilityof the key pair to the service account. On completion of theabove pairing for addition of an MPA, the CIS would have shareda unique key pair consisting of an APIKey and an APISecretthat represents the service identity of the newly added MPA.Every ensuing message and request sent between the MPA andCIS is digitally signed using this APISecret. The CIS stores theAPISecret for all MPAs indexed by their corresponding APIKeys.

5.2.2 Message confidentiality and authenticityMessage confidentiality and authenticity deals with encryptionand digital signing of messages exchanged between the CISand MPAs. Messages are exchanged as JSON objects betweenRESTful web services called over a HTTPS connection. MPAscreate their own self-signed certificates and rely on the validationof the CIS certificate. The APIKey/APISecret pair distributed inthe MPA Discovery is used for digital signing of messages toensure message integrity and authenticity. As explained earlier,the APIKey acts as an index into the table within the CIS databasecontaining the APISecrets. The Signature element is the RFC 2104HMAC-SHA1 of selected elements from the content, includinga timestamp header and the body of POST requests, thus thesignature will vary from request to request.

If the request signature calculated by the receiver, and theresponse signature calculated by the sender match the signaturesincluded with the content, the REST call is treated as authenti-cated. If either of the signature validation fails, neither the sendernor the receiver will process the API call and the failure is loggedand reported. Also, the timestamp adds entropy to the signatures,and provides protection from replay-attacks.

5.3 Experimental Testbed and Security ConfigurationWe setup an implementation of OnTimeSecure middleware ona multi-domain MIaaS experimental testbed shown in Figure 10comprising of the following institutions: The Ohio State Univer-sity (OSU), Ohio Technology Consortium (OH-TECH), ClemsonUniversity, and University of Missouri (MU), which are con-nected to each other through an external “Entitlement Service”.

12

Fig. 10. Multi-domain MIaaS testbed setup in Internet2 InCommon forOnTimeSecure dependability evaluation

The “Entitlement Service” acts as a medium of communicationbetween the domains. Each institution had 4 MPAs deployed atstrategic points within their domains, and registered their MPAsto a common CIS using the secure MPA discovery protocoldescribed in Section 5.2.1. All four institutions are part of the In-ternet2 InCommon Federation, which is the identity managementfederation for the US research and education community. Morespecifically, we registered OnTimeSecure as a certified serviceprovider (there are only 9 other certified entities for ‘Research andScholarship’ within Internet2 InCommon), and thus we have madeour implementation accessible to over 350 InCommon membersin higher education, government, industry and research centers.

Each institution owns an IdP that users of the correspondingdomains use to authenticate with their credentials. Upon success-ful authentication, the IdP sends SAML assertions to the CIS SPwith the attributes that can be released as per the respective institu-tion’s policy. As part of the first set of experimental evaluation, weconfigured the testbed in the “totally open” perfSONAR (Open-pS) mode by having all the permissions of the system assigned toall the users, and by having encryption as well as digital signaturesturned-off. Also by turning off inter-domain access, and by havingthe encryption as well as digital signatures turned off, we wereable to configure the testbed in “strictly closed” perfSONAR(Closed-pS) mode. In contrast, we were able to configure thetestbed in the “resource protected” perfSONAR (RPS-pS) modeby turning-on encryption as well as digital signatures and pre-configuring policy rule examples to suit the intra-domain RBACand inter-domain ABAC modes of operation. For the secondexperiment, we configured the RPS-pS mode with “All-RBAC”and “All-ABAC” compositions to compare their dependabilityperformance against our intra-domain RBAC and inter-domainABAC inspired RPS-pS. The evaluation of both the experimentsare performed by extending the National Institute of Standards andTechnology (NIST) method guidelines [20] for the MIaaS context.

Fig. 11. Risk calculation using NIST method

5.4 Threat Modeling and Security AssessmentThe NIST method for conducting risk assessments is a widelyaccepted procedure to analyze the security robustness and depend-ability of a system. The risk assessment study allows us to evaluateour security middleground modeling for different NPM federationrequirements. The risk calculation from a threat event using theNIST method is shown in Figure 11, and involves the followingsteps: (i) assess the likelihood of threat occurrence on basis ofprobability of initiation and success, (ii) assess the level of impactin event of a successful attack, and (iii) calculate the overall riskscore as a combination of the likelihood and impact.

For both the experiments, we identified 5 possible threatevents from the NIST guidelines that were potential ‘High’ to‘Moderate’ security risks to an institution or MIaaS deploying amulti-domain NPM federation. We first customize the NIST threatevents in the context of multi-domain MIaaS as shown in Table 3.Then we assess the security performance of RPS-pS and compareit with Open-pS and Closed-pS configurations against each ofthese events. We use a semi-quantitative scale of 0-10 for theimpact/likelihood event assessments, with 10 indicating very high,8 indicating a high, 5 indicating a moderate, 2 indicating a low,and 0 indicating very low levels of impact. For the assessment, thethree basic attack variables, e.g., Likelihood of Initiation, Like-lihood of Success, and Impact of the attack are assigned valuesusing the NIST guidelines. The final Risk value is calculated usingthe method illustrated in Figure 11. In the figure, f1 is defined asa max() function with the likelihoods as arguments. Whereas,f2 is an davg()e function between overall likelihood and impact.The only exception condition for the function occurs if any basicvariable value is 0, in which case the overall Risk becomes 0.

5.5 DiscussionThe assessment results comparison for Open, RPS security modesshow the benefit of using RPS-pS over Open-pS in success-fully defending against well known attacks as shown in Fig-ures 12(a), 12(b), and 12(c). For high impact DDoS attack (10),the likelihood of initiation for Open-pS is very high (10) becauseMPAs are openly visible, moderate (5) for RPS-pS because ofaccess to MPA limited to fewer people, and moderate (5) forClosed-pS because the number of users and MPAs are reducedby half. The likelihood for DDoS attack succeeding remains thesame as the likelihood of initiation because once DDoS attacks areinitiated, they are likely to succeed.

For Man-in-the-middle attack (Impact 10) for the user deviceand MPA link case, the Open-pS, and Closed-pS are highlyvulnerable (10) because of zero encryption mechanism. Whereasour RPS-pS system is less vulnerable (2) due to proper encryptionstandards used. The likelihood of success remains the same aslikelihood of initiation, because upon initiation it is equally likelyto happen. For inter-domain MPA to MPA, Open-pS is highlyvulnerable (10), RPS-pS is minimally vulnerable (2), and Closed-pS system is not vulnerable (0) due to absence of inter-domaincommunication. Whereas for intra-domain MPA to MPA Man-in-the-middle attacks, the likelihood of initiation and success remainthe same as the user device and MPA link case.

For Information Compromise (Moderate impact 5), Open-pSis highly vulnerable (10), RPS-pS is moderately vulnerable (5)because, on an average only half the users have permissions toinstall new software in the system, and Closed-pS is also moder-ately vulnerable (5) because it is vulnerable for only intra-domainscenarios and not for inter-domain scenarios. The likelihood ofsuccess remains the same as likelihood of initiation for Open-pSand Closed-pS, but decreases for RPS-pS (2) because it may bepossible that the database has read/write permission, and the userwith read permissions can also initiate an attack but with lowsuccess. For the Credential alteration attack, likelihood of initia-tion is high (10) for Open-pS, Closed-pS and RPS-pS because thecredential authority sits outside the NPM framework and is easilyaccessible, but the likelihood of success decreases for Closed-pS(0) because it is not likely to be accessible by outside attackers. Forspilling sensitive data, Open-pS is highly vulnerable (10) becauseof its open nature. RPS-pS is also vulnerable (8) because of theplausible inter-domain access scenarios, and Closed-pS is very low(2) because of only intra-domain access being plausible.

Comparing RPS-pS with Closed-pS reveals that - although insome cases, the likelihood of attack initiation is higher for RPS-pSdue to limited inter-domain resource provisioning in Closed-pS,the overall success likelihood in RPS-pS is equal or better in mostcases. Such results thus validate our choice of RPS as a securitymiddleground. We also compare our proposed middleground RPS

13

TABLE 3NIST Guided Threat Events specific to multi-domain MIaaS deployment

NIST Threat Events MIaaS Specific DescriptionI. Distributed Denial of Service attack Attack on a single MPA/CIS using multiple systems outside the federationII. Internal network traffic modification(man-in-the-middle attack)

Interception and modification of the web services communication within the MIaaS. Different forms of man-in-the-middle attack can be:a. Link between the Device and MPA being attackedb. Link between two MPAs belonging to the same domain being attackedc. Link between two MPAs belonging to different domains being attacked

III. Information Compromise attack Attack by either installing malware in the MIaaS to disturb measurement schedules or by modifying thecollected measurement data. The two manifestations are: a. Malware installation, and b. Database alteration

IV. Credential alteration attack Attack compromising a Certificate Authority (CA) to make malware or illegitimate connections appearlegitimate

V. Spill sensitive data to outside agent Attack involving MPA/CIS information spillage to unauthorized outside agent

(a) Likelihood of initiation comparison (b) Likelihood of success comparison (c) Overall risk comparison

Fig. 12. Risk assessment results comparison of Open, RPS and Closed security configurations using NIST method

(a) Likelihood of initiation comparison (b) Likelihood of success comparison (c) Overall risk comparison

Fig. 13. Risk assessment results comparison of RPS, All-RBAC and All-ABAC based middleground configurations using NIST method

solution with the All-RBAC and with All-ABAC middlegroundRPS implementation as shown in Figures 13(a), 13(b), and 13(c).The results do not contain man-in-the-middle attack outcomesas the corresponding outcome is independent of the RPS accesscontrol composition. However, for all other type of attacks, ourproposed middleground RPS for most cases performs better thanAll-RBAC and as good as All-ABAC modes. For some casesAll-ABAC mode’s robustness is better than our RPS due to theformer’s inherent property of zero resource over-provisioning forboth inter-domain and intra-domain scenarios. However, suchbetter robustness comes at a cost of reduced manageability andscalability as discussed previously. Thus, our RPS middlegroundproves to be ideal for balancing both MIaaS security robustnessand performance requirements.

6 DISCUSSIONS AND CONCLUSIONS

In this paper, we address salient emerging problems in designinga security middleground for multi-domain NPM federations withMIaaS, especially in the perfSONAR community that has over1400 measurement point instances worldwide as part of explicitmeasurement federations. Our contributions include a detailedanalytical modeling and comparison between RBAC and ABACschemes that can act as security middleground solutions. Basedon the modeling and analysis efforts, we presented the protocolimplementation details of our ‘OnTimeSecure’ middleware that

can be used to configure a customized security middlegroundbetween default open/closed access settings.

The lessons learnt in solving the research and operationalchallenges for securing a multi-domain MIaaS are as follows:• Access control techniques are typically designed to satisfy

authentication and authorization requirements of a system. Ourwork showed how different family of access control techniquesimpact the efficiency of a system differently both from atheoretical and practical stand-point. We proved that the keyfor designing an effective security middleground solution for acloud-based measurement service is a thorough understandingof the system’s security and performance requirements, as wellas their inter-conflicts. Our results show that use of ad-hoc ac-cess control choices may not only lead to compromised systemsecurity but also may adversely affect service performance.

• We showed how a sound theoretical comparison approach alongwith relevant optimizations in an access control implementationcan help a cloud-based service such as our MIaaS to achievesecurity and protection objectives without compromising per-formance objectives. Although, the evaluation of such a securityimplementation becomes non-trivial due to the lack of genericsecurity metrics for comparison of different types of securitythreats, we demonstrated how the NIST-guided risk assessmentapproach in evaluation experiments were helpful to evaluate andcompare the effectiveness of a security middleground solution.

Our work has the potential to transform how enterprises

14

engage in multi-domain network monitoring, while protectingand selectively restricting access to institutional measurement re-sources based upon intra-domain/inter-domain federation policies.In addition, results from this work provide cyber security re-searchers knowledge related to key solution trade-offs and guide-lines in terms both analytical benefits and protocol complexity inorder to satisfy the specific security requirements of any federatedresource pools. Further, findings from this paper can lead to ahigher adoption of multi-domain systems with MIaaS that are ofcritical importance in the end-to-end performance transparency forpertinent network resource allocation and adaptation in emergingBig Data ecosystems with heavy data movement needs.

REFERENCES[1] A. Hanemann, J. Boote, E. Boyd, J. Durand, L. Kudarimoti, R. Lapacz, M. Swany,

S. Trocha, J. Zurawski, “perfSONAR: A Service Oriented Architecture for Multi-Domain Network Monitoring”, Proc. of Service Oriented Computing, SpringerVerlag, LNCS 3826, pp. 241-254, 2005.

[2] P. Calyam, J. Pu, W. Mandrawa, A. Krishnamurthy, “OnTimeDetect: DynamicNetwork Anomaly Notification in perfSONAR Deployments”, MASCOTS, 2010.

[3] B. Gaidioz, R. Wolski, B. Tourancheau, “Synchronizing Network Probes to avoidMeasurement Intrusiveness with the Network Weather Service”, HPDC, 2000.

[4] SamKnows: Worldwide Broadband Measurement Service -http://www.samknows.com

[5] M-Lab: Open Platform for Internet Measurement Tools Community -http://www.measurementlab.net

[6] V. Bajpai, S. Eravuchira, J. Schnwlder, “Lessons learned from using the RIPE AtlasPlatform for Measurement Research”, ACM SIGCOMM CCR, 2015.

[7] Archipelago (Ark) Measurement Infrastructure - http://www.caida.org/projects/ark[8] W. de Donato, A. Botta, A. Pescape, “HoBBIT: A Platform for Monitoring

Broadband Performance from the User Network”, Traffic Monitoring and Analysis,Springer Verlag, LNCS 8406, pp. 55-77, 2014.

[9] mPlane - an Intelligent Measurement Plane for Future Network and ApplicationManagement - http://www.ict-mplane.eu

[10] perfSONAR Deployments Tracker and Other System Comparisons -http://www.perfsonar.net/about

[11] P. Calyam, C. Lee, E. Ekici, M. Haffner, N. Howes, “Orchestrating Network-wideActive Measurements for Supporting Distributed Computing Applications”, IEEETransactions on Computers, Vol. 56, No. 12, pp. 1629-1642, 2007.

[12] V. C. Hu, D. R. Kuhn, T. Xie, “Property Verification for Generic Access ControlModels”, IEEE/IFIP TSP, 2008.

[13] V. C. Hu, D. R. Kuhn, T. Xie, J. Hwang, “Model Checking for Verificationof Mandatory Access Control Models and Properties”, Int’l Journal of SoftwareEngineering and Knowledge Engineering, 2011.

[14] R. Sandhu, E. Coyne, H. Feinstein, C. Youman, “Role-Based Access ControlModels”, IEEE Computer Journal, Vol. 29, No. 2, pp. 38-47, 1996.

[15] L. Wang, B. Wang, “Attribute-Based Access Control Model for Web Services inMulti-Domain Environment”, MASS, 2010.

[16] M. Masse, “REST API Design Rulebook”, O’Reilly Media ISBN: 978-1-4493-1050-9, 2011.

[17] R. Morgan, S. Cantor, S. Carmody, W. Hoehn, K Kligenstein, “Federated Security:The Shibboleth Approach”, EDUCAUSE, 2004.

[18] A. Dainotti, A. Pescape, G. Ventre, “NIS04-1: Wavelet-based Detection of DoSAttacks”, Proc. of IEEE Globecom, 2006.

[19] A. Lakhina, M. Crovella, C. Diot, “Diagnosing network-wide traffic anomalies”,Proc. of ACM SIGCOMM, 2004.

[20] R. Ross, “Guide for Conducting Risk Assessments”, NIST SP800-30-Rev1 TechnicalReport, 2012.

[21] J. Al-Jaroodi, N. Mohamed, H. Jiang, D. Swanson, “Middleware infrastructurefor parallel and distributed programming models in heterogeneous systems”, IEEETransactions on Parallel and Distributed Systems, 2003.

[22] R. Brennan, K. Feeney, S. Yuqian, D. O’Sullivan, “Secure federated monitoring ofheterogeneous networks”, IEEE Communications Magazine, Vol. 51, Issue 11, 2013.

[23] K. Salah, J. A. Calero, S. Zeadally, S. Almulla, M. Alzaabi, “Using CloudComputing to Implement a Security Overlay Network,” IEEE Security and Privacy,2013.

[24] Z. Zhang, X. Zhang, R. Sandhu, “ROBAC: Scalable Role and Organization BasedAccess Control Models”, COLLABORATECOM, 2006.

[25] A. Pereira, V. Muppavarapu, S. Chung, “Role-based Access Control for GridDatabase Services using the Community Authorization Service”, IEEE Transactionson Dependable and Secure Computing, 2006.

[26] P. Calyam, S. Kulkarni, A. Berryman, K. Zhu, M. Sridharan, R. Ramnath, G.Springer, “OnTimeSecure: Secure Middleware for Federated Network PerformanceMonitoring”, CNSM, 2013.

[27] C. Rodriguez, M. Molina, J. Boote, “The Authentication and Authorization infras-tructure of perfSONAR MDM”, TNC, 2008.

[28] eduGAIN Specification - http://www.geant.net/service/eduGAIN/Pages/home.aspx

[29] X.509 Specification - http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0.pdf

[30] V. C. Hu, D. Ferraiolo, R. Kuhn, A. Schnitzer, K. Sandlin, R. Miller, K. Scarfone,“Guide to Attribute Based Access Control (ABAC) Definition and Considerations”,NIST Special Publication 800-162, 2014.

[31] E. Yuan, J. Tong, “Attributed Based Access Control (ABAC) for Web Services”,ICWS, 2005.

[32] GENI ABAC Specification - http://groups.geni.net/geni/attachment/wiki/GEC11Authorization/geni-abac.pdf

[33] DeterLab ABAC Specification - http://abac.deterlab.net[34] E. Coyne, R. Weil, “ABAC and RBAC: Scalable, Flexible, and Auditable Access

Management”, IEEE Computer Society IT Professional, Vol. 15, Issue 3, 2013.[35] Z. Xu, K. Martin, “A Practical Deployment Framework for Use of Attribute-Based

Encryption in Data Protection”, HPCC, 2013.

[36] T. Barton, J. Basney, T. Freeman, T. Scavo, F. Sienbenlist, V. Welch, R. Ananthakr-ishnan, B. Baker, M. Goode, K. Keahey, “Identity Federation and Attribute-basedAuthorization through the Globus Toolkit, Shibboleth, GridShib, and MyProxy”,Proc. of PKI Research and Development Workshop, 2006.

[37] C. Adams, S. Lloyd, “Understanding PKI: Concepts, Standards, and DeploymentConsiderations”, Addison-Wesley ISBN 978-0321743091, 2003.

[38] A. Gouglidis, I. Mavridis, V. C. Hu, “Verification of Secure Inter-operation Proper-ties in Multi-domain RBAC Systems”, IEEE SERE-C, 2013.

[39] L. Griffin, B. Butler, E. de Leastar, B. Jennings, D. Botvich, “On the Performanceof Access Control Policy Evaluation”, IEEE International Symposium on Policies forDistributed Systems and Networks (POLICY), 2012.

[40] P. Calyam, M. Dhanapalan, M. Sridharan, A. Krishnamurthy, R. Ramnath,“Topology-Aware Correlated Network Anomaly Event Detection and Diagnosis”,Springer Journal of Network and Systems Management (JNSM), 2013.

[41] OASIS Security Services Technical Committee, “Security Assertion Markup Lan-guage (SAML) v1.1”, OASIS Standard 200308, 2003.

[42] XACML Specification - http://docs.oasis-open.org/xacml/2.0/access control-xacml-2.0-core-spec-os.pdf

[43] OpenPGP Message Format - https://tools.ietf.org/html/rfc4880[44] “Best Practices in Enterprise Authorization: The RBAC/ABAC Hybrid Approach,”

white paper, EmpowerID, 2013.[45] A. Gouglidis, I. Mavridis, “domRBAC: An access control model for modern

collaborative systems”, Elsevier Computers & Security (COSE), 2012.[46] K. Salah, R. Boutaba, “Estimating Service Response Time for Elastic Cloud

Applications,” IEEE CloudNet, 2012.

Ravi Akella received the BS degree in Informa-tion Technology from GITAM University, India in2012. He is currently pursuing his MS degreein Computer Science at University of Missouri-Columbia. His current research interests includecloud computing, and cyber security.

Saptarshi Debroy received his PhD degree inComputer Engineering from University of CentralFlorida in 2014, MTech degree from JadavpurUniversity, India in 2008, and BTech degree fromWest Bengal University of Technology, India in2006. He completed his Post Doctoral Fellow-ship at University of Missouri-Columbia. Cur-rently he is an Assistant Professor at the HunterCollege of The City University of New York. Hiscurrent research interests include cloud comput-ing, and network security.

Prasad Calyam received his MS and PhD de-grees from the Department of Electrical andComputer Engineering at The Ohio State Uni-versity in 2002 and 2007, respectively. He is cur-rently an Assistant Professor in the Departmentof Computer Science at University of Missouri-Columbia. His current research interests includecloud computing, and cyber security.

Alex Berryman is currently pursuing his BS de-gree in Aeronautical and Astronautical Engineer-ing at The Ohio State University, and is a Soft-ware Engineer at The Samraksh Company. Hiscurrent research interests include computer andnetwork virtualization, and distributed systems.

Kunpeng Zhu received the BS degree in Com-puter Science and Engineering at Yanshan Uni-versity, China in 2009 and MS degree in Geode-tic Science and Surveying at The Ohio StateUniversity in 2011. He is currently a SoftwareEngineer at The Samraksh Company. His cur-rent research interests include re-usable soft-ware engineering, and scalable web services.

Mukundan Sridharan received the BS degreein Electronics and Communication Engineeringfrom Madras University, India, and the MS andPhD degrees in Computer Science and Engi-neering from The Ohio State University, in 2000,2002, and 2011, respectively. He is currently aPrincipal Engineer at The Samraksh Company.His current research interests include wirelessnetworks and distributed systems.