A Framework of Attacker Centric Cyber Attack ... - Semantic Scholar

This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the ICC 2007 proceedings.

A Framework of Attacker Centric Cyber Attack Behavior Analysis Xuena Peng

Hong Zhao

Software Center Northeastern University Shenyang, China [email protected]

Software Center Northeastern University Shenyang, China [email protected]

Abstract—Cyber attack behavior analysis can be roughly classified as “network centric” and “attacker centric” approaches. Compared with traditional “network centric” approach, the keys to implement “attacker centric” approach are to investigate the attacker relationship as while as tracking attackers. Current “attacker centric” approach researches mainly focus on single attacker centric behavior analysis, but overlook the attacker relationship and its impact on attack behavior analysis. This paper is mainly coping with such issues. In this paper, the framework of attacker centric behavior analysis is proposed. As key technique, the principles of choosing desirable attacker set are discussed, the concepts of attacker group and group member are introduced, and the corresponding attacker group recognition algorithms are also proposed. Finally, based on the proposed approaches, a prototype system CABAS is developed and evaluated under DARPA 2000 intrusion detection evaluation datasets. The experimental results show that our approach has potential in analyzing complex cooperative attacks. Keywords-network security; intrusion correlation; attack behavior; behavior analysis

I.

detection;

alert

INTRODUCTION

Intrusion detection system is among the most important network security utilities, and it is commonly applied to detect various types of attacks existed in network traffic. Although current intrusion detection systems can detect most known attacks, they are not desirable assistants to security administrators, because they generate too many alerts with low-level semantics, and most of them are false positives. In such case, it is almost impossible for the administrators to understand the cyber attacks in time by manually analyzing the IDS alerts. In recent years, automatic IDS alerts analysis technique has become one of the hot topics in network security. Since in essence IDS alerts can be viewed as images of attack behaviors, it is reasonable for us to believe that analyzing the IDS alerts is actually analyzing the attack behaviors behind the alerts. For such consideration, we employ the term like “attack behavior analysis” instead of terms like “alert analysis” in this paper. Cyber attack behavior analysis can be roughly classified as “network centric” analysis and “attacker centric” analysis. “Network centric” analysis focuses on the security events and

status changes of the protected entities, it is not very suitable to profile the attackers and make attacker centric protection in advance and counteraction afterwards. On the contrary, “attacker centric” behavior analysis approach focuses on the attackers, disclosing the relationship among several attackers, and tracking every suspicious entity as long as it behaves as an attacker, and responses according to their attack behaviors when encountering dangerous attackers. Compared with traditional “network centric” attack behavior analysis, “attacker centric” attack behavior analysis has advantages in detecting attacker’s overall threat, selecting emergency response strategies, and providing evidences for network forensics. Our proposed attack behavior analysis framework is an attacker centric approach. In such framework, the attackers relationships are investigated, and latent attacker groups can be recognized; the attack behaviors of each attacker groups can be tracked and the relationship among attack behaviors can be reasoned; the priority of both the attacker groups and their behaviors can be evaluated and corresponding response strategies can be proposed. Since many traditional methods can be referenced, how to track the attackers and analyze the track are relatively easy. The key technique in our framework is to recognize the attackers relationship. Such technique is less investigated before, since most traditional “attacker centric” analysis researches are single attacker based. Our framework is dedicated in dealing with attacks enforced by both single attacker and cooperative attackers. II.

RELATED WORK

Cyber attack behavior analysis techniques can be roughly classified into two categories: “network centric” analysis and “attacker centric” analysis. As far as we know, “network centric” behavior analysis techniques remain dominant. Typical approaches include: probabilistic alert correlation approach proposed by Alfonso Valdes[1], causality correlation approach proposed by Peng Ning[2] as while as Frederic Cuppens[3], chronicle pattern matching approach proposed by Benjamin Morin[4], statistical causality analysis approach proposed by Xinzhou Qin[5], security goal oriented system Scyllarus demonstrated by Robert Goldman[6], Colored Petri net approach proposed by Dong Yu[7]. Although these approaches differ from each other, they are in common

1-4244-0353-7/07/$25.00 ©2007 IEEE


focusing on attack behaviors and victims, while taking little consideration about attackers. For example, with current network centric analysis approach, it is possible that a recognized attack scenario includes isolated attackers’ behaviors, or cooperated attacker’s behaviors are scattered to many scenarios. Since attack strategy and attack intention are valid concepts for single attacker or attacker group, we assume that it is meaningless to find out these metrics in network centric analysis framework. Compared with “network centric” attack behavior analysis approaches, the importance of “attacker centric” attack behavior analysis has not been fully recognized, and only a few approaches have been proposed. In [8], Burroughs suggested that “it is not the attack but rather the attacker against which our networks must be defended”, and proposed a Bayesian multiple hypothesis tracking (BMHT) algorithm to recognize and understand single attacker’s behavior tracks. Another “attacker centric” approach is proposed by Oliver M. Dain in [9], Dain presents 3 different “attacker centric” methods to cluster alerts generated in DEF CON 2000, among these methods only the data mining approach clearly takes the attacks carried out by cooperative attackers into account. III.

ATTACKER CENTRIC ATTACK BEHAVIOR ANALYSIS FRAMEWORK

We assume that the attacker's actions themselves are unknown, but the attacker's behavior may result in alerts, so that the essence of analyzing alerts generated by IDS is analyzing attack behaviors that the alerts infer to. Since there are high volumes of false positives generated by IDS in practical network environment, the alerts do not always refer to attack behaviors. In our proposed framework, we first infer the attack behaviors from alerts, and use such attack behaviors to do further analysis. Before introducing the framework, we define some elementary concepts first. [Def. 1] Attack Behavior (briefed as AB) is the network traffic with specific attack semantics or pragmatics, it is described as 6-tuple, AB = (ID, AttackerID, VictimID, BehaviorType, BehaviorStatus, HpnTime), in which ID is the identifier of the attack behavior; AttackerID and VictimID represent the identifiers of the attacker and victim respectively; BehaviorType and BehaviorStatus represent the type and status of attack behavior respectively; HpnTime represents the time that the attack behavior happens. [Def. 2] Attacker is the subject who applied the attack behaviors. Victim is the entity who endures the attack behaviors. The “attacker centric” attack behavior analysis framework can be described as is shown in figure 1. Because the techniques of some attack behavior (alert) analyzing modules, such as attack inference, attack tracking, reasoning, response and decision support, are either relatively simple or have been investigated by the prior researchers, we will briefly introduce the functionality of these modules in this section, but leave the key technique of attacker group recognition module in the next section.

At t acker Gr oup Recogni t i on

At t acker Gr oups

At t ack Behavi or s

At t ack Behavi or Tr acki ng

At t ack I nf er ence

Behavi or Tr ack Eval uat i on

Al er t s

I DS

I DS

Behavi or Tr ack Reasoni ng

I DS

Response Deci si on Suppor t

Figure 1 the framework of attacker centric cyber attack behavior analysis A. Attack Behavior Inference Traditional NIDS (network-based IDS) detects attacks mainly by monitoring network traffic, and matching them with specific signatures. Such approach takes little account of the network environment, so it is inevitable to generate false alerts or context irrelevant alerts. In order to compensate for such defects, we need to preprocess the alerts and find out the probable semantics of the network traffic. Such functionality is what we want to implement in attack behavior inference module. The data structure of attack behavior is defined in def1, the attributes in such structure is of great importance for further analysis. But all these attributes are not accurately provided in the IDS alerts. First of all, the behavior type is not always accurately provided because of tremendous false alerts. For example, some administrative processes, such as vulnerability scanning or antivirus system updating, may trigger false alerts because their traffic is similar with that of the attacks. For such situation, some determined or none determined traffic semantic inference methods can be applied to identify the actual traffic semantic from IDS alerts. Then, the attackerID and victimID are also not always accurately provided. They are not always of the same semantics with sourceID and destID, although for most behavior types, the sourceID corresponds to attackerID, and destID corresponds to victimID. In [9], Dain proposed that the mapping from sourceID and destID to attackerID and victimID can be viewed as a function of behavior type, and we also verified that it may be effective to define such functions to derive these attributes form IDS alerts. Finally the behavior status is also an important attribute that is seldom provided in NIDS alerts. For example, when there’s CodeRed traffic targeting a Linux system in the network, NIDS will just report the attack, without evaluating if the attack is possible to be successful. In resolving such issue, some prior works have discussed a lot about environment context based alert verification technique[10], which can help to disclose the attack status. B. Attack Behavior Tracking Attack behavior tracking is to find out everything done by each set of attackers, and the process is defined in def. 3. [Def. 3] Attacker Behavior Tracking (ABTracking) During a given time period TP, “attacker behavior tracking” is the


process that the security system follows all the members of a given tracked target set TTSet, monitors their target behaviors and records them in time order. This process is represented as ABTracking (TTSet, TP). As described in def. 3, the tracked target is the basic element that forms the TTSet. Tracked target is used here to describe what should be tracked. It is defined as def. 4. [Def. 4] Tracked Target (briefed as TT) is the basic element of TTSet, and is introduced to describe the attacker’s specific characters to be tracked, it is described as 6-tuple, TT = (ID, AttackerID, BehaviorTypes, TimePeriod, CapLevel, ThreatLevel), in which ID represents the identifier of the target to be tracked; AttackerID represents the attacker to be tracked; BehaviorTypes represent the target behavior types to be tracked for TT; TimePeriod represents the time period to enforce behavior tracking; CapLevel represents the attacking capability of TT as an attacker; and ThreatLevel represents the threat caused by TT as an attacker. By applying ABTracking to a TTSet during TP, the system can generate a set of attackers’ behaviors. Such behavior set can be described as tracked attacker behavior set, briefed as TABSet(TTSet, TP), which constitutes of all the observable target attack behaviors carried out by the members of tracked target set TTSet. TABSet(TTSet, TP) can be computed as follows: TABSet(TTSet, TP) = {tabij | ∀ tti∈TTSet, ( is_matched(tabij.attackerID,tti.attackerID)) ∧(tabij.hpntime ∈TP∩tti.timeperiod ) ∧(tabij.behaviorType∈tti.behaviorTypes )} The time ordered attack behavior list transformed by the TABSet(TTSet, TP) is called attack behavior track, and is represented as ABTrack(TTSet, TP). Attacker behavior track is made of attack behaviors. Applying attack behavior tracking to TTSet, and synthetically analyzing the track can help the administrator to understand high-level attack behavior pragmatics (or semantics) that cannot be expressed by single attack behavior. Both TABSet(TTSet, TP) and ABTrack(TTSet, TP) are the outcome of the attacker behavior tracking process, and can be used for further processing. C. Behavior Track Reasoning Attack behavior analysis is more than tracking. Further reasoning is needed to take account of the context information, recognize possible connections among the attack behaviors, and distill high-level semantics of the track. Specific techniques on track reasoning are not within the scope of this paper. In fact, some of the techniques introduced in section 2 can be referenced for track reasoning. In this part, we only present one of the best practices, which can be easily applied to this module. The approach is the alert causality reasoning technique proposed by Peng Ning[2] in TIAA, which is the system dedicated in analyzing the relationship between different attack behaviors. Peng Ning’s causality reasoning is based on the observation that most intrusions are not isolated but related as different stages of attack sequences, with the early stages

preparing for the later ones. In other words, there are often logical causality relationships among attack steps. In his approach, the alerts, which are the indications of attack behaviors, are correlated using prerequisites and consequences of intrusions. His approach identifies the prerequisite (e.g., existence of vulnerable services) and the consequence of each type of attack, and correlates the corresponding alerts by matching the consequence of some previous alerts with the prerequisite of some later ones. D. Track Evaluation and Response Decision Support Track evaluation is the process to enforce qualitative and quantitative evaluations to the track, and evaluate the track within a larger time and space behavior context. And track response decision is the process to select the best response strategy from several feasible strategies according to organization’s security policy. For track evaluation and response, most researches evaluate the response priority and strategy at the granularity of isolated attack behaviors. But we think that the attack behaviors applied by relative attackers may be correlated and their response priority would be affected by each other, it would be very difficult to do such evaluation at the granularity of isolated attack behaviors. Even though such evaluation is possible, we still assume that the evaluation of the overall attack track is more important to the administrators. So in such module, we do not intend to generate attack behavior based evaluation results and response decisions, but to generate attack behavior track based evaluation results and response decisions. IV. ATTACKER GROUP RECOGNITION One of the key techniques in “attacker centric” analysis is to investigate the attacker relationship, and find out the sets of attackers to be tracked. A. Tracked Target Set Choosing and Attacker Group Take TargetSet (briefed as TS) as the set constituted of all observable attackers in a certain time period, then for any set TTS, where TTS ⊆ TS, TTS can be used as a tracked target set. Since tracking TTSet is not without any cost, this cost can be shown in both system and human processing stage. So it is unrealistic to track every possible TTSet. Choosing worthwhile tracked target set from all possible sets is very important to balance the cost and benefit. By the term “tracked target set choosing”, we refer to choosing the worthwhile ones from all possible tracked target sets. By analyzing the effectiveness of different tracked target sets, we found that inter relationships among attackers of the set are the keys to recognize desirable tracked target sets. For arbitrary multi-member set TTSet ⊆ TS, the members of TTSet can be independent or cooperative. The TTSet with independent members are not worthy of tracking, because nothing more can be obtained by tracking these target members as a whole than tracking them separately; while the TTSet full of cooperative members are worthy of tracking, because more cooperative relationships of attack behaviors


enforced by cooperative attackers can be discovered by tracking these target members as a whole than tracking them separately. In order to express the set of the correlated attackers, we introduce the concept of attacker group, which is defined in def. 5. [Def. 5] Attacker group (briefed as AG) is the organization composed of correlative attackers, it is described as 8-tuple, AG = (GroupID, GMS, OrganizeTime, DisorganizeTime, AttackGoal, AttackStatus, AttackStrategy, VictimSet), in which, GroupID is the identifier of the group; GMS represents the group member set; OrganizeTime and DisorganizeTime show when the group is organized and disorganized respectively; AttackGoal represents the goal that the attack group achieves; AttackStatus represents current status of the attacks applied by attacker group; AttackStrategy represents attack strategies of the attacker group; and VictimSet represents the victims the attacker group. [Def. 6] Group Member (briefed as GM) is the basic element of a group member set, it is described as 5-tuple, GM = (GroupID, AttackerID, JoinTime, DisjoinTime, BehaviorTypes), in which, GroupID is the identifier of the group; AttackerID is the identifier of the attacker; JoinTime and DisjoinTime represent the time the attacker joins and disjoins the group respectively; BehaviorTypes represent the behavior types relative to the group. It would be desirable to construct tracked target with attacker group’s members. Transforming the attacker group into tracked target set and applying behavior tracking & analysis can provide the administrator with comprehensive and valuable information about the attacker group’s goals, strategies, behaviors, and threat estimations. Such information is very useful in security management, emergency response, behavior confront and network forensics. B. Attacker Group Recognition Recognizing attacker groups automatically, correctly and completely is the prerequisite to automating attack behavior tracking and analysis in “group” granularity. Within the lifecycles of an attacker group, two stages are propitious to recognizing attacker group, namely as the construction stage and the attacking stage. In these two stages, affiliations among different members of the group present in different ways. In attacker construction stage, such affiliation can be disclosed when new members join the group and set up cooperative relationships with existing members. In attacking stage, such affiliation can be disclosed by the attack behavior cooperation applied by different attackers. In different stages, different recognition methods are needed. In this section, we just propose two simple attacker group recognition algorithms for each stage, and leave the refinement of the algorithms in our future work. 1) Attacker group recognition in construction stage Observing the process that new members enter attacker group and setup cooperative relationships with existed members of the group during construction stage is very helpful in recognizing attacker group. “Compromised” relationship deduced from the observation of compromising attack

behaviors among entities is one of the typical relationships indicating attacker group construction stage. Algorithm 1 is based on such idea. [Algorithm 1] AttackBehaviors: time ordered attack behavior set GroupSet: A set of attacker groups Group: a member of group set Begin For each abi in AttackBehaviors /* find all the groups of which abi.attackerID is a member at abi.hpntime*/ group = findGroup(GroupSet, abi.attackerID, abi.hpntime); If group = NULL then group = createNewGroup (abi.attackerID, abi.hpntime); addtoGroupSet(GroupSet, group); End if /* add the victim to the attacker’s group, if attacker takes control of victim.*/ If canCompromise(abi.BehaviorType) then While group != NULL addtoGroup(group, abi.victimID, abi.hpntime); End while End if End For End Generally, when an attacker group member compromises an outside entity by applying certain attacks, it is reasonable to assume that “compromised” relationship has set between the group member and the outside entity. The group member is capable to invite the outside entity to the group, thus new member is added to the group. For example, let G represents an attacker group, and A represents a group member, when A compromised an outside entity C by enforcing attack behavior b, then A gains the accessing or controlling authority of C, thus A is capable of ordering C to apply some attacks in order to achieve the attacking goal of G. In such situation, we can assume that group member A introduces its victim C to the group G. 2) Attacker group recognition in attacking stage When the attacker group construction stage is not within the sight of the monitored network or the process is very stealthy, algorithm1alone may not recognize all the members of an existing group. To compensate for algorithm 1, we also propose algorithm 2. [Algorithm2] GroupSet: the set of attacker group; Group: a member of group set; Similarity: the vector represents similarity metrics between groups, including algorithms and values; OverallSimilarity: overall similarity value of between two groups; Threshold: predefined value in order to tune the overall similarity. Begin


For each groupi in GroupSet For each groupj in GroupSet, groupi ≠groupj //compute the similarity metrics between groups For each metrick in Similarity metrick.value = metrick.algorithm(groupi, groupj); End for OverallSimilarity =

∑ metric .value * w ∑w i

Darpa 2000, in fact, it is exactly these hosts that form a group and cooperate in the later DDoS attack.

i

i

//merge groups if their similarity exceeds threshold If OverallSmilarity > threshold then groupi = merge(groupi, groupj); delfromGroupSet(GroupSet, groupj); End If End For End For End The main idea of algorithm 2 is to decide whether two groups should be viewed as one by estimating the connections of attack behavior between two groups. Estimation can be made based on many metrics, including: the behavior cooperative degree between two groups, the similarity between their behavior patterns, the similarity between group members, the similarity between group victims, and etc. In algorithm 2, we use a vector variable “Similarity” to represent these metrics’ algorithms and values. Meanwhile, we also realized that the sporadic behaviors of different independent attackers might also seem to be cooperative. For the sake of decreasing the possibility of merging such isolative groups as one, we use a threshold to tune the group similarity, and only the groups with overall similarity higher than the threshold can be merged into one group. V.

Figure 2 Example of recognized attacker groups For each recognized attacker group, CABAS generate tracks and analyze the causality of the behaviors on the track. Figure 3 is the causality graph generated from the track of the group presented in Figure 2. Compared to the graph directly generated by TIAA, it is obvious that this graph represents only correlate attack behaviors enforced by cooperative attackers, but not those enforced by non-relative attackers.

EXPERIMENTAL RESULTS

Based on the proposed framework, we have developed an offline network attack behavior analysis prototype, CABAS, and performed several experiments. In CABAS, we have integrated commonly used environment context based alert verification technique[10] to validate the successfulness before group recognition process, and causality alert correlation technique proposed by Peng Ning[2] to analyze the inter behavior relationships of the track, while leaving the evaluation and response decision modules unimplemented yet. We have performed a series of experiments using the two DARPA 2000 intrusion detection evaluation (IDEVAL) datasets [7]. We take the alert set provided in [11] as CABAS’s input, and these alerts were generated by RealSecure using Darpa 2000 datasets as input (please read [12] for further details about the alert set). In the experiments, CABAS effectively recognize possible attacker groups. Figure 2 shows one of the attacker group recognized by CABAS from the alerts of the inside dataset of LLDoS1.0. The group is initialized by “Sadmind Ping” attack behavior, which adds “202.77.162.213” as a group member, then by several “Sadmind Amslverify Overflow” behaviors, “172.016.112.010”, ”172.016.112.050”, “172.016.115.020” are added to the group. According to documents provided by

Figure 3 causality graph of attacker group behavior track Table 1 shows the experimental results, including the detection and false alert rates for RealSecure Network Sensor 6.0, TIAA, and CABAS. Since the number of attacks depends on how one view the attacks, counting the number of attacks is a subjective process. In order compare our result with TIAA, we inherent the counting methods in TIAA. In table 1, the experimental results of LLDoS2.0.2, we depict the number of alerts as “n+m”, in order to emphasize the fact that they are attack graphs generated by two attacker groups’ tracks. “n” represents the alert number of the causality graph with true alerts, and “m” represents for the alert number of the causality graph with false alerts. Compared with TIAA, the experimental results in Table 1 show that CABAS can effectively reduce false alerts rate without reducing detection rate. Although, compared with


RealSecure, there may be some alerts lost in an attacker the group’s behavior track. Thus the overall detection rate of group’s causality graph, the lost alerts can be easily found on CABAS would also not be reduced. # # # detected Detection # true False Dataset observabl Tool alerts attacks Rate alerts alert e attacks RealSecure 891 51 57.30% 57 93.60% DMZ 89 TIAA 57 50 56.18% 54 5.26% CABAS 54 50 56.18% 54 0 LLDoS1. 0 RealSecure 922 37 61.67% 44 95.23% Inside 60 TIAA 44 36 60% 41 6.82% CABAS 41 36 60% 41 0 RealSecure 425 4 57.14% 6 98.59% DMZ 7 TIAA 5 3 42.86% 3 40% LLDOS CABAS 3+2 3 42.86% 3 40% 2.0.2 RealSecure 489 12 80.00% 16 96.73% Inside 15 TIAA 13 10 66.67% 10 23.08% CABAS 10+2 10 66.67% 10 16.67% Table 1 Experimental Results VI.

CONCLUSION AND FUTURE WORKS

In this paper, a novel “attacker centric” network attack behavior analysis framework is proposed. Our approach, which is different from traditional behavior analysis approaches, takes account of not only the cooperative relationship among attack behaviors, but also the cooperative relationship among attackers. In this paper, the set of cooperative attackers are recognized as groups, and the attacker group recognition is the key to achieve group scale attacker behavior tracking and analyzing, so two simple attacker group recognition algorithms are also proposed. For validation, we have implemented a prototype system, called CABAS, and evaluate the system under DARPA 2000 dataset. The experimental results show that our approach has potential in analyzing sophisticated attacks enforced by cooperative attackers. ACKNOWLEDGMENT This work was supported by the National Scienc Foundation Committee of P.R.C under Grant 60602061, and also by a grant from the National High Technology Research and Development Program of China (2006AA01Z413). Thank also goes to Mr. Yanwen Qu for his guidance in the theory of multi-agents system, the idea of which is illuminative to our approach. REFERENCES [1] Valdes, A. and K. Skinner, an approach to sensor correlation, in the 3rd International Workshop on Recent Advances in Intrusion Detection. 2000, Springer-Verlag: Toulouse, France. [2] Ning, P., et al., Techniques and tools for analyzing intrusion alerts. ACM Trans. Inf. Syst. Secur., 2004. 7(2): p. 274-318. [3] Cuppens, F. and A. Miege. Alert Correlation in a Cooperative Intrusion Detection Framework. in the 2002

IEEE Symposium on Security and Privacy. 2002. Oakland, California, USA: IEEE Computer Society. [4] Morin, B. and H. Debar. Correlation of Intrusion Symptoms: an Application of Chronicles. in the 6th International Symposium on Recent Advances in Intrusion Detection. 2003. Pittsburgh, PA, USA: Springer-Verleg. [5] Qin, X., A Probabilistic-Based Framework for INFOSEC Alert Correlation. 2005, Georgia Institute of Technology. [6] Goldman, R., et al. Information Modeling for Intrusion Report Aggregation. in the DARPA Information Survivability Conference and Exposition (DISCEX II). 2001. 2001. [7] Yu, D. and D. Frincke. A Novel Framework for Alert Correlation and Understanding. in Applied Cryptography and Network Security, Second International Conference (ACNS 2004). 2004. [8] Burroughs, D., L. Wilson, and G. Cybenko. Analysis of Distributed Intrusion Detection Systems Using Bayesian Methods. in IEEE International Performance Computing and Communications Conference. 2002. [9] Dain, O. and R. Cunningham, Building Scenarios from a Heterogeneous Alert Stream. IEEE Transactions on Systems, Man and Cybernetics, 2002. [10] Christopher, K., R. William, and V. Giovanni, Using Alert Verification to Identify Successful Intrusion Attempts. Journal of Practice in Information Processing and Communication (PIK), 2004. 27(4). [11] TIAA's homepage. http://discovery.csc.ncsu.edu/software/ correlator/ [12] Ning, P. and Y. Cui, An Intrusion Alert Correlator Based on Prerequisites of intrusions. 2002, Department of Computer Science, North Carolina State University.