Reasoning about the Security Configuration of SAN Switch Fabrics

Reasoning about the Security Configuration of SAN Switch Fabrics William M. Fitzgerald Simon N. Foley Dept. of Computer Science University College Cork Cork, Ireland Email: wfitzgerald@4c.ucc.ie Dept. of Computer Science University College Cork Cork, Ireland Email: s.foley@cs.ucc.ie Abstract—Management of a switch fabric security configuration, a core component of Storage Area Networks, is complex and error prone. As a consequence, misconfiguration of and/or a poor understanding of a switch fabric may unnecessarily expose an enterprise to known threats. A formal model of a switch security configuration is presented. This model is reasoned over to help manage complex switch fabric security configurations. I. I NTRODUCTION An integral part of a Storage Area Network (SAN) is its switch fabric. Intuitively, a SAN switch provides interconnections between SAN client nodes (initiators) and storage array nodes (targets), primarily to exchange SCSI traffic [1]. A significant challenge in providing security for a SAN is attaining a degree of confidence that the security configuration of its switches adequately addresses the (security) threats. A misconfiguration may result in unapproved access, the denial of approved access or inadequate mitigation of threats to SAN nodes. In practice, switch security configuration is more complex than simply providing firewall-like access-control rules. Rather, switch security configuration must be considered in the context of other security services required by the switch fabric, thereby increasing the likelihood of misconfiguration. For example, when generating access-control rules for the enterpriselevel SAN security requirement: “permit switch fabric interaction with trusted remote authentication servers”, a security configuration is not just defined in terms of a set of packetfilter access-control rules. The security configuration of the switch fabric must also consider a set of authentication accesscontrol rules that specify, at an application-level, the trusted remote authentication servers, and, furthermore, whether the authentication access-control rules defined (perhaps on a single switch source) are to be distributed across the entire switch fabric (another set of application-level access-control rules). This paper considers the problem of reasoning about and managing complex security configurations of SAN switches. A formal model for switch security configuration is developed using Description Logic [2]. This approach builds on previous research [3]–[5] that demonstrated the effectiveness of using Description Logic to model and reason about firewall rules. While there are extensive research results on query [3], [6], [7] and structural [3], [8], [9] analysis of firewall rules, the authors are unaware of research published on the similar analysis of SAN switch rules. Switch security configuration is typically a more complex proposition than conventional firewalls and the paper describes how such reasoning can be done in the proposed model of switch security. For example, a query such as: “has read-only access to a particular disk on a specific target storage array within a given zone defined in the context of a particular VSAN been granted to trusted initiator client nodes?” may be formalized within the model. Structural analysis is also considered to detect access-control rule conflicts. The contribution of this paper is a formal model for switch security configuration with which to perform query and structural analysis. In addition, structural analysis definitions that define inter-shadowing and inter-spurious conflicts between firewall-based and zone-based switch security configurations are presented. The paper is organised as follows. Section II provides an overview of the switch fabric security configuration challenges. An overview of Description Logic and Semantic Web Rule Language is presented in Section III. Section IV presents a Description Logic based model for SAN switch security configuration. Additional structural analysis definitions are defined in Section V. Section VI provides some examples that demonstrate analysis of switch fabric security configurations. II. S WITCH S ECURITY C ONFIGURATION This section provides examples of security configuration challenges that need to be considered with respect to configuring access-control rules for switch management and for traffic routed through the switch. A. Switch Management Configuring switch management access controls is not simply about opening the relevant management service ports such as SSH or remote authentication service ports for example RADIUS. One needs to consider whether management access to the switch is permitted for out-of-band management (over an Ethernet interface) or in-band management (where TCP/IP traffic is tunnelled over a Fibre Channel interface). One may also wish to permit certain SAN initiators (for example, IP address white-list) and deny others. It may also be considered prudent to define a set of access-control rules that explicitly state what privileges a SAN administrator is authorised for, once authenticated to a switch. For example, SAN administrators are typically authorised for root privileges while SAN network operators are not. Similarly, are Authentication, Authorisation & Accounting (AAA) services performed locally on each switch within the SAN fabric or centrally through a remote AAA server farm typically hosted on a separate LAN. If performed remotely, are the access-control rules correctly providing intended secure SAN-to-LAN AAA communication? One has also to consider reflecting locally on each switch, a comparable set of AAA access-control rules defined on remote AAA servers as a precautionary redundancy countermeasure should remote AAA communication fail. B. Traffic Management With respect to traffic routed through the switch between initiator clients and target storage arrays, it is not simply about making for example the iSCSI TCP port 3260 accessible for all traffic. Furthermore, iSCSI traffic for example does not necessarily have to communicate on the IANA [10] recommended port of 3260. It may also be a security requirement to deny certain SAN initiators (for example, IP address or World Wide Name black-list) access to all storage arrays, only accept iSCSI traffic from some initiators and require other initiators to use iSCSI over IPSec. One may also need to consider accesscontrol rules that restrict certain initiators access to a specific disk or set of disks within a storage array and so forth. C. Structural Misconfiguration Management While the SAN access-control rules on an individual basis may be compliant with the enterprise-level security requirements, the structural relationships between the access-control rules themselves may introduce a scenario such that the overall configuration is inconsistent. For example, firewall-based access-control rules in a switch configuration are tested in the sequence in which they appear in the configuration. That is, once a packet has been successfully matched against an accesscontrol rule, no further rule tests are carried out for that packet. Thus, an access-control rule placed out of sequence may unintentionally cause a misconfiguration. Consider two accesscontrol rules, where one permits iSCSI traffic to a storage array and the other denies access to all network resources, including the storage array. Depending on the sequence of these two access-control rules, a misconfiguration may result. Misconfiguration may also occur between access-control rules deployed on multiple inter-operating SAN access controls. For example, an upstream switch may be unintentionally denying intended storage array iSCSI traffic that is correctly configured on an another downstream switch. In practice, managing a SAN switch security configuration that is aligned with the enterprise-level security requirements is complex and error-prone. Configuration is largely dependent on the expert-knowledge of the SAN administrator drawing upon best practice and standards. III. D ESCRIPTION L OGIC AND SWRL Description Logic (DL) is a decidable portion of first-order logic [2]. DL concepts represent sets of individuals (instances) and properties (roles) represent binary relations applied to individuals. For example, the DL assertion: StorageArray ⊑ Server ⊓ ∃≥1 hosts.Service ⊓ ∃≥1 isProtectedBy.ProtectionServer specifies that a storage array hosts one or more services (for example iSCSI) and is protected by one or more protection servers (for example firewalls and/or switches). The Semantic Web Rule Language (SWRL) complements DL, providing the ability to infer additional information but at the expense of decidability. SWRL rules are horn-clause like rules written in terms of DL concepts, properties and individuals. A SWRL rule is composed of an antecedent (body) part and a consequent (head) part, both of which consist of positive conjunctions of atoms [11]. For example, the requirement that servers hosting iSCSI based services protected by protection servers require those protection servers to open port 3260, is expressed in the following SWRL rule. StorageArray(?sa) ∧ hosts(?sa,?iSCSI) ∧ hasPort(?iSCSI, 3260) ∧ isProtectedBy(?sa,?ps) → hasOpenPort(?ps,3260) where 3260 is an atom/constant and ?sa, ?iSCSI, ?ps represent unbound variables in the rule. IV. S WITCH ACCESS C ONTROL M ODEL A formal model for SAN switch security configuration is developed using DL [2] and the SWRL [11]. Note that in presenting the model components, for reasons of space, complete specifications in particular, disjoint axioms, subproperties or closure axioms are omitted. Similarly for reasons of space, not all switch access controls modelled, for example port-based, iSCSI-based and remote authentication-based access controls, are presented. However, a relevant portion of the model is presented that conveys the challenges identified within this paper. While the model for the SAN switch security configuration presented in this paper is Cisco centric [12], [13], much of the model attributes are implementation neutral. Concept CiscoM DSRule defines the set of Cisco MDS access-control rules. This concept is further specialised to more specific sub-concepts, namely concepts ExecRule and Conf igRule. CiscoMDSRule ≡ ExecRule ⊔ ConfigRule Concept ExecRule defines a set of execution-mode accesscontrol rules that enable temporary switch configuration modifications, debugging and display of system information. Concept Conf igRule defines a set of configuration-mode accesscontrol rules that enable permanent (across reboots) switch configuration modifications. These two sub-concepts are in turn further specialised to form a hierarchy of access-control rules. A fragment of this hierarchy is illustrated in Figure 1. The double-headed arrow represents a subsumption relation. CiscoMDSRule ConfigRule ExecRule ShowRule DebugRule ClearRule Fig. 1. IPAccessRule RoleRule RadiusRule VSANRule ZoneRule Fragment of Cisco MDS Rule Hierarchy. A. TCP/IP-based Access Control List Traditional TCP/IP based traffic plays an important role within a SAN fabric. For example, configuration management of a SAN switch or communication with remote AAA servers are performed over TCP/IP protocols. Modern SAN switches have the ability to route TCP/IP traffic over traditional Ethernet or tunnelled over Fibre Channel interfaces. As a consequence, the SAN fabric is exposed to traditional TCP/IP based threats. While upstream network access control mechanisms such as firewalls and Intrusion Detection Systems provide protection against known TCP/IP based threats, it is considered best practice to adopt a security in depth approach [14], [15]. Therefore, switch Access Control Lists (ACLs) are used to make decisions about whether or not to permit a packet. Consider as a running example switch configuration management where management may be performed using the Fabric Manager (via SNMP) or the Command Line Interface (via SSH or Telnet). These management services are accessible by all SAN nodes connected to the switch whether authorised or not. Therefore, it becomes necessary, in addition to a management service’s own security controls, to restrict management access to SAN administrator IP addresses only. Concept IPAccessListRule represents a set of TCP/IP-based ACL rules. Each access-control rule takes the form of a series of filter conditions on packet fields that must be met in order for that access-control rule to be applicable with a consequent action for the matching packet. A TCP/IP access-control rule is composed of one or more (∃ restriction) protocols (property hasP roto), one or more source and destination IP addresses (properties hasSrcIP and hasDstIP ), one or more ports (property hasDstP ort), zero or more (∀ restriction) connection states (property hasState), zero or more ICMP Types (property hasICM P T ype) and one action. IPAccessListRule ⊑ ConfigRule ⊓ ∃≥1 hasProto.Protocol ⊓ ∃≥1 hasSrcIP.IPAddress ⊓ However, the reader is referred to [3] where these concepts are defined within a model of the TCP/IP stack developed as part of previous research [4]. Concept Action is an enumerated set of actions (individuals) that can be taken against a matching packet. Action ≡ {permit, deny, log&deny} For a TCP/IP-based access-control rule to take effect it must be first assigned a switch interface and then assigned a direction (inbound or outbound) in which it is to filter packets [12]. Therefore, each access-control rule has a dependency (dependsOn property) with exactly two other Cisco MDS rules, namely those defined by concepts InterfaceRule and IPAccessGroup respectively. A hierarchy of TCP/IP-based ACLs are defined to represent categories of access-control rules that may be implemented by SAN switches. For example, concept M gmtACL is representative of the TCP/IP-based access-control rules that are applicable to a switch’s management interface. MgmtACL ⊑ IPAccessListRule The following SAN security requirement stating that “a SAN administrator host having an IP address of 192.168.1.20 is permitted inbound SSH access to the SAN switch management interface (mgmt0) with an IP address of 192.168.1.1” is characterised by the following three Cisco MDS rules. ip access-list mgmt-ACL permit tcp 192.168.1.20 192.168.1.1 eq port ssh interface mgmt 0 ip access-group mgmt-ACL in Individual mACL, an instance of concept M gmtACL, represents the ‘ip access-list’ access-control rule including its dependency relationship with access-control rules ‘interface’ and ‘ip access-group’. MgntACL(mACL) ← hasProto(mACL, tcp) ⊓ hasSrcIP(mACL, ip192.168.1.20) ⊓ hasDstIP(mACL, ip192.168.1.1) ⊓ hasPort(mACL, p22) ⊓ hasAction(mACL, permit) ⊓ dependsOn(mACL, mgnt0) ⊓ dependsOn(mACL, mgnt0Inbound) ∃≥1 hasDstIP.IPAddress ⊓ ∃≥1 hasDstPort.Port ⊓ where individuals mgnt0 and mgnt0Inbound are instances of concepts InterfaceRule and IPAccessGroup respectively. ∀≥0 hasState.State ⊓ ∀≥0 hasICMPType.ICMPType ⊓ ∃=1 hasAction.Action ⊓ B. Role-based Access Control ∃=2 dependsOn.CiscoMDSRule For reasons of space, concepts P rotocol, IP Address, P ort, State and ICM P T ype are not defined in this paper. The previous section discussed the importance of restricting access to management services of a switch to SAN administrators only. Adopting the principle of least privilege is considered best practice. Therefore, one may also want to restrict the set of privileges in terms of access-control rule permissions that each SAN administrator is authorised for. Concept RoleRule represents the set of roles (individuals) such that each access-control rule is composed of a single rule order index (property hasOrder), a privilege (property canExecute) with respect to one of five Cisco MDS rule categories, a single action (individuals permit or deny) applicable to that privilege, one or more users that a role is intended for (property isRoleOf) and zero or more VSANs for which that role isAppliedT o. Note, VSANs are discussed in Section IV-C and are analogous to Virtual Local Area Networks (VLANs). RoleRule ⊑ ConfigRule ⊓ ∃=1 hasOrder.Integer ⊓ ∃=1 canExecute.(ConfigRule ⊔ ExecRule ⊔ DebugRule ⊔ ShowRule ⊔ ClearRule) ⊓ ∃=1 hasAction.Action ⊓ ∃≥1 isRoleOf.User ⊓ ∀≥0 isAppliedTo.VSANDB Concept Role is further specialised to provide a hierarchy of roles. For example, a role for a SAN operator (concept OpRole) and a SAN administrator (concept AdminRole). OpRole, AdminRole ⊑ RoleRule Role-based access control is important to minimise unnecessary threats with respect to unauthorised modification of switch configuration as a consequence of a compromised SAN administrator account with root privileges or the (un)intended execution of commands by a SAN administrator not intended to have such privileges. For example, the following Cisco MDS access-control rules may be (un)intentionally misused by user Eve such that user Alice who is logged into the switch is forcibly logged out or has her password changed, thus a Denial of Service ensues. As a consequence, it is important to avoid role-based access control misconfiguration. clear user Alice username Alice password y0u’v3B33nH4ck3d The following SAN security requirement: “User Eve, a restricted SAN administrator, is authorised for Exec accesscontrol rules with the exception of the ‘clear’ access-control rules” is encoded as the following set of concept AdminRole individuals. AdminRole(exec1) ← hasAction(exec1, permit) ⊓ isRoleOf(exec1, eve) ← role name adminrole rule 1 permit exec role name adminrole rule 2 deny exec feature clear username eve role adminrole Note due to page constraints, the username access-control rule that explicitly assigns user Eve to the administrator role is not presented. However the inverse property of isRoleOf is property hasRole that has concept User as its domain and concept Role as its range. C. VSAN-based Access Control A Virtual Storage Area Network (VSAN) is a logical partition of a physical SAN and provides a basis for traffic isolation between nodes that are physically connected within the same SAN [12]. VSANs, with advantages of redundancy and reduced hardware costs aside, play an important part in provisioning network access control. SAN nodes may only be a connected to a single VSAN thereby ensuring that traffic communicated within a VSAN is isolated from traffic in other VSANs. Note, each VSAN has its own dedicated routing and configuration management services. From a security perspective, VSANs within an enterprise maybe used to define a virtual SAN fabric for each of its departments. For example, a separate VSAN for the Research, Sales and Human Resources departments. Consider the following SAN security requirement that states: “Nodes within each department should have access to data stored on their respective storage arrays where access to data from other departments is prohibited” as a running example. Without defining separate VSANs, all nodes connected to the same physical SAN fabric have the potential to communicate with nodes across departments (also noted in Section IV-A). Therefore, a SAN administrator should define relevant VSANs to ensure proper departmental demarcation. A VSAN rule (individual) is defined to have a unique identifier (property hasID), operate over one or more interfaces (property hasIface), have an optional human readable name (property hasN ame) and a decision whether or not that VSAN is currently activated (property isActivated). VSANRule ⊑ hasOrder(exec2, 2) ⊓ canExecute(exec2, clear) ⊓ hasAction(exec2, deny) ⊓ isRoleOf(exec2, eve) ConfigRule ⊓ ∀=1 hasName.String ⊓ ∃=1 hasID.Integer ⊓ ∃≥1 hasIface.Interface ⊓ ∃=1 isActivated.Boolean hasOrder(exec1, 1) ⊓ canExecute(exec1, exec) ⊓ AdminRole(exec2) Individuals exec1 and exec2 are representative of the following low-level Cisco MDS rule-set. Further explanation of concept Interface is required. A SAN switch has many kinds of interfaces for example Fibre Channel interfaces (individuals of concept FCIface) and iSCSI interfaces (individuals of concept ISCSIIface. Such interfaces have a slot value and an interface value. FCIface, FVIface, FCIPIface, ISCSIIface ⊑ Interface ⊓ ∃≥1 hasSlotValue.Integer ⊓ ∃≥1 hasIfaceValue.Integer Consider the Research department VSAN as a running example, where the following security requirement states: “External research partner nodes, internal research department nodes, the shared research storage array and the backup storage array should be isolated from other SAN traffic by defining a dedicated Research VSAN”. The following Cisco MDS rule-set defines a Research VSAN called ‘rSAN’ with an ID of 2 and operates over switch interfaces iscsi 1/1, iscsi 2/1, fc 1/3 and fc 1/4 with which to connect external and internal iSCSI initiator nodes and, research and backup storage array fibre channel target nodes respectively. vsan vsan vsan vsan database database database database vsan vsan vsan vsan 2 2 2 2 name name name name rSAN rSAN rSAN rSAN interface interface interface interface iscsi 1/1 iscsi 2/1 fc 1/3 fc 1/4 These low-level Cisco MDS access-control rules are encoded within the following DL assertions. VSANRule(rVSAN) ← hasName(rVSAN, “rSAN”) ⊓ hasID(rVSAN, 2) ⊓ hasIface(rVSAN, iscsi1-1) ⊓ hasIface(rVSAN, iscsi2-1) ⊓ hasIface(rVSAN, fc1-3) ⊓ hasIface(rVSAN, fc1-4) ⊓ Concept ZoneRule represents the set of access-control zone rules (individuals) that have a name (property hasN ame), isAssignedT o a VSAN and have one or more hasM ember relationships with individuals of concept M ember. ZoneRule ⊑ ConfigRule ⊓ ∃=1 hasName.String ⊓ ∃=1 isAssignedTo.VSANRule ⊓ ∃≥1 hasMember.Member Concept M ember represents individuals (SAN nodes) that are members of one or more zones along the isMemberOf property. There are a number of disjunction axioms that define necessary conditions for concept membership. For example, an individual that is a member of a particular zone may be referred to by its pWWN (property hasPWWN). Members may have zero or more ports. An explanation of property hasLU N ID will be discussed in Section IV-D2. Note, only the relevant fragment of this definition is provided due to page limitation. isActivated(rVSAN, true) where the following holds for individuals iscsi1/1, iscsi2/1, fc1/3 and fc1/4: ISCSIIface(iscsi1-1) ← hasSlotValue(iscsi1-1, 1) ⊓ hasIfaceValue(iscsi1-1, 1) ISCSIIface(iscsi2-1) ← FCIface(fc1-3) ← hasSlotValue(iscsi2-1, 2) ⊓ hasIfaceValue(iscsi2-1, 1) hasSlotValue(fc1-3, 1) ⊓ Member ⊑ ConfigRule ⊓ ∃≥1 isMemberOf.Zone ⊓ (∃≥1 hasIPAddress.IPAddress ⊔ ∃≥1 hasFWWN.FWWN ⊔ (∃≥1 hasPWWN.PWWN ⊓ ∀≥0 hasLUNID.String)) ⊓ ∀hasPort.Port hasIfaceValue(fc1-3, 3) FCIface(fc1-4) ← hasSlotValue(fc1-4, 1) ⊓ hasIfaceValue(fc1-4, 4) D. Zone-based Access Control Zone-based Access Control (or Zoning) provides a basis for fined-grained demarcation of nodes within a VSAN [12], [16]. A zone consists of members (initiator and target nodes). Members of a zone can access each other, while members across different zones cannot. Zones are defined within a VSAN. Zone membership is based on either IP addresses or World-Wide Names (WWNs) of the nodes connected to a switch fabric [12]. For example, a node may be referred to by its pWWN, that is, its port World Wide Name (analogous to a Ethernet MAC address). Note, while VSANs and Zones provide traffic isolation they are different to one another. For example, VSANs provide routing, naming and zone protocols. These protocols are not available on a per-zone basis [12]. While a VSAN provides a logical demarcation of nodes it hosts from nodes hosted within other VSANs, it may be a further security requirement to restrict nodes within the same VSAN from communicating with each other. Consider as running example the following SAN security requirement: “External research partner nodes are permitted access to the research storage array while internal Research department nodes are permitted to access both the research and backup storage arrays”. The following is an example implementation of the SAN security requirement described above, where individual exZone and individual inZone are representative of external and internal zone access-control rules that permit external research partners (initiators InitA and InitB) access to the research storage array (target individual resSA), and an internal research department initiator (individual InitC) access to both the research storage array and the backup storage array (target individual bakSA). ZoneRule(exZone) ← hasName(exZone, “ExZone”) ⊓ isAssignedTo(exZone, rVSAN) ⊓ hasMember(exZone, initA) ⊓ hasMember(exZone, initB) ⊓ hasMember(exZone, resSA) ZoneRule(inZone) ← hasName(inZone, “InZone”) ⊓ isAssignedTo(inZone, rVSAN) ⊓ hasMember(inZone, initC) ⊓ hasMember(inZone, resSA) ⊓ hasMember(inZone, bakSA) where the following also holds: Member(initA) ← hasPWWN(initA, pwwn00:11:22:ab) Member(initB) ← ← hasPWWN(initB, pwwn00:11:22:cd) Member(initC) Member(resSA) Member(bakSA) hasPWWN(initC, pwwn11:22:33:cd) ← ← hasFWWN(resSA, fwwn22:33:44:ef) hasFWWN(bakSA, fwwn33:44:55:gh) The following is the corresponding Cisco MDS rule-set. zone zone zone zone zone zone name name name name name name ExZone ExZone ExZone InZone InZone InZone vsan vsan vsan vsan vsan vsan 2 2 2 2 2 2 member member member member member member pwwn pwwn fwwn pwwn fwwn fwwn 00:11:22:ab 00:11:22:cd 22:33:44:ef 11:22:33:cd 22:33:44:ef 33:44:55:gh 1) Read-Only Zones: Within a SAN, VSAN or zone, initiators by default have read/write access to their permitted target storage arrays. Switches, for example the Cisco MDS series, have the ability to restrict read/write access to a storage array at a switch-level by explicitly defining read-only zones. Note, while modern storage arrays provide their own access-controls with respect to read/write access, it is considered best practice to adopt a security in depth approach [15]. Concept ZoneRule is therefore extended to include details (isReadOnly property) about read/write access within a zone. ZoneRule ⊑ ConfigRule ⊓ ∃=1 isReadOnly.Boolean The SAN security requirement outlined in Section IV-D may be further refined such that: “External research partner nodes are permitted read-only access to the research storage array . . .”. This will require the following Cisco MDS rule in addition to the previously defined external zone rule-set. 2) Lun-Zoning: A storage array is composed of a number of disks or LUNs. By default any initiator node within the same zone as the target storage array has access to all of its LUNs. LUN-Zoning is an access control mechanism that restricts access to a storage array on a per-LUN basis [12]. Note, while modern storage arrays provide their own accesscontrols with respect to LUN access (LUN Masking [16]), it is best practice to consider a security in depth approach [15]. The SAN security requirement outlined in Section IV-D1 may be further refined such that: “External research partner nodes are permitted read-only access to specific LUNs within the research storage array . . .”. Consider the following scenario. External research partners identified as initA and initB both require read access to a specific LUN (LUN identifier 0X63) where both partners collaborate with respect to the data stored on this LUN. However, external research partner initB requires read access to another LUN (LUN identifier 0X64) such that external research partner initA has no collaboration. The following low-level Cisco MDS rules uphold these requirements. zone zone zone zone zone name name name name name ExZone ExZone ExZone ExZone ExZone vsan 2 member pwwn 00:11:22:ab lun 0X63 vsan 2 member pwwn 00:11:22:cd lun 0X63 vsan 2 member pwwn 00:11:22:cd lun 0X64 vsan 2 member fwwn 22:33:44:ef attribute read-only Individual exZone defined in Section IV-D1 remains the same. However, the individuals of concept M ember are encoded with additional knowledge that ensures external initiators initA and initB are permitted read-only access to their respective LUNs (hasLU N ID property relationship) within the research storage array (resSA). Member(initA) Member(initB) ← ← . . . ⊓ hasLUNID(initA, 0X63) . . . ⊓ hasLUNID(initB, 0X63) ⊓ hasLUNID(initB, 0X64) V. S TRUCTURAL C ONFLICT A NALYSIS D EFINITIONS Structural Analysis examines the relationship that rules have with one another within a security configuration or across multiple inter-dependent security configurations [3], [8], [9]. This paper extends the existing work on firewall structural analysis techniques and considers inter-configuration conflicts that may occur between a firewall and a zone security configuration. For ease of exposition, the relevant properties are described using a basic discrete math notation. These properties have been implemented in SWRL to perform structural analysis and an example is provided in Section VI. zone name ExZone attribute read-only Individual exZone, representative of the external zone security requirement is updated to include detail that defines the external zone as read-only. Note ‘. . . ’ refers to the original individual assertion. ZoneRule(exZone) ← . . . ⊓ isReadOnly(exZone, true) A. SAN Rule Composition In the context of inter-configuration conflicts between a firewall and a zone configuration, a SAN access-control rule is defined as a tuple. Rule ≡ Condition × Action Given r : Rule, rule r is a tuple (r1 ,r2 ) where r1 ∈ Condition and r2 ∈ Action. For simplicity, and when no ambiguity arises, r.Condition is a syntactic sugar for r1 and so forth. Filter Conditions. The set of filter conditions (Condition) that describes the common filter conditions between firewall and zone access-control rules is defined as an 2-tuple. Condition ≡ SrcIP × DstIP The source and destination IP addresses (SrcIP and DstIP) are defined as an inclusive interval, where an interval is a subset of all possible IP addresses for source and destination IP addresses. SrcIP,DstIP ≡ [0, 232 -1] Given r:Rule, then r.Condition1 ∈ SrcIP and r.Condition2 ∈ DstIP . For simplicity, and when no ambiguity arises, r.SrcIP is a syntactic sugar for r.Condition1 and so forth. For example, r.SrcIP is used to access the attribute value of set SrcIP , instead of r.Condition1 (or r11 ). Action. The set of target actions are: Action ≡ {permit, deny, log&deny} rzone .Condition ⊂cond sfw .Condition ∧ rzone .Action = permit ∧ sfw .Action = permit) Note, zone rules are not defined over IP address ranges and therefore do not cause spurious conflicts with firewall rules. VI. A NALYSIS OF ACCESS C ONTROL C ONFIGURATION A. Structural Analysis Firewall centric structural analysis techniques, for example [3], [8], [9], are also applicable to firewall-based SAN access-control rules. The following SWRL rule extends these works and detects inter-shadowing conflicts between firewall access-control rules (SWRL variable ?fwr) and zone accesscontrol rules (SWRL variable ?zr). Relevant filter conditions of each firewall access-control rule (lines 2-5) and each zone access control rule (lines 8-12) are then examined against the subsumption relation (lines 14-17) defined in Section V-B. IPAccessListRule(?fwr)∧ (1) hasSrcIPStart(?fwr,?sIPS)∧hasIPValue(?sIPS,?sIPSV)∧ (2) B. Subsumption Filter Conditions The filter conditions of rule s (s.Condition) subsumes those of rule r (r.Condition), if every filter condition field of r, for example r.SrcIP , is equal to or is a subset of the corresponding filter condition fields of rule s, for example s.SrcIP . Consider rules r, s:Rule with identical filter conditions except for their source IP address ranges; r.SrcIP = {10.37.2.12} and s.SrcIP = {10.37.2.10, . . . , 10.37.2.15}, then r.Condition is subsumed by s.Condition if r.SrcIP ⊆ s.SrcIP holds. Formally, given rules r, s : Rule, then r.Condition is subsumed (⊆cond ) by s.Condition if and only if r.Condition ⊆cond s.Condition holds across each of the corresponding filter condition fields. r.Condition ⊆cond s.Condition Inter-Spurious Conflict. Given rules rzone , sf w :Rule, rule sf w is spurious to rule rzone , if the filter conditions of rzone is a subset of the corresponding filter conditions of rule sf w , where sf w is allowing more than what rule rzone is intending. ≡ r.SrcIP ⊆ s.SrcIP ∧ r.DstIP ⊆ s.DstIP hasSrcIPEnd(?fwr,?sIPE)∧hasIPValue(?sIPE,?sIPEV)∧ (3) hasDstIPStart(?fwr,?dIPS)∧hasIPValue(?dIPS,?dIPSV)∧(4) hasDstIPEnd(?fwr,?dIPE)∧hasIPValue(?dIPE,?dIPEV)∧(5) hasAction(?fwr,deny)∧ (6) ZoneRule(?zr)∧ (7) (8) hasMember(?zr,?m1) ∧ hasMember(?zr,?m2)∧ hasIPStart(?m1,?ipS1)∧hasIPValue(?ipS1,?ipSV1)∧ hasIPEnd(?m1,?ipE1)∧hasIPValue(?ipE1,?ipEV1)∧ hasIPStart(?m2,?ipS2)∧hasIPValue(?ipS2,?ipSV2)∧ hasIPEnd(?m2,?ipE2)∧hasIPValue(?ipE2,?ipEV2)∧ differentFrom(?m1,?m2)∧ swrlb:greaterThanOrEqual(?ipSV1,?sIPSV)∧ swrlb:lessThanOrEqual(?ipEV1,?sIPEV)∧ swrlb:greaterThanOrEqual(?ipSV2,?dIPSV)∧ (9) (10) (11) (12) (13) (14) (15) C. Inter SAN Rule conflicts swrlb:lessThanOrEqual(?ipEV2,?dIPEV)∧ (16) (17) Inter-Shadowed Conflict. Given rules rzone , sf w :Rule, rule rzone (zone access-control rule) is shadowed by rule sf w (firewall access-control rule), if the filter conditions of rzone are a subset of or equal to the corresponding filter conditions of rule sf w , where sf w is denying what rule rzone is intending to permit. → isInterShadowedBy(?zr,?fwr) (18) rzone .Condition ⊆cond sfw .Condition ∧ Zone members may also be identified by their WWNs. Firewall access-control rules do not consider WWN’s. As a consequence, a relationship (hasWWNIPMapping) between each zone member’s WWN and its corresponding IP address must be asserted or inferred (for example using SWRL). rzone .Action = permit ∧ B. Query Analysis (sfw .Action = deny ∨ sfw .Action = log&deny) Query Analysis provides a way to ask hypothetical ‘whatif’ questions of a security configuration [3]. A switch can be analysed to check whether or not the answers to queries made of its configuration are consistent with the enterprise-level Note, zone rules only have an permit action and therefore do not cause a shadowing conflict with firewall rules. security requirements. For example the following SQWRL query asks: “What role or roles are users authorised for?” User(?user) ∧ RoleRule(?role) ∧ isRoleOf(?role, ?user) → sqwrl:select(?user, ?role) The following SQWRL query asks what initiators (members) have been assigned read-only access to what disks (identified by LUN ID’s) within a given zone defined in the context of a particular VSAN? Member(?mem) ∧ ZoneRule(?zone) ∧ VSANRule(?vsan)∧ hasName(?zone,?zname) ∧ hasName(?vsan,?vname)∧ isReadOnly(?zone, true) ∧ hasLUNID(?mem,?lunid)∧ isAssignedTo(?zone,?vsan) ∧ hasMember(?zone,?mem) → sqwrl:select(?mem, ?lunid,?zname,?vname)∧ sqwrl:columnNames(“Initiator”, “Disk”, “Zone”, “VSAN”) VII. R ELATED R ESEARCH While there is extensive research on synthesis [17], [18], query [6], [7] and structural [8], [9] analysis, these firewallcentric works do not consider switch security configuration. This paper builds on previous firewall centric research [3]–[5] to model and reason about SAN switch security configurations. VIII. D ISCUSSION AND C ONCLUSION This paper considered the problem of reasoning about and managing complex switch security configurations. A formal model for switch security configuration was presented. Structural analysis definitions that define inter-shadowing and inter-spurious conflicts between firewall-based and zone-based switch security configurations where presented. Future work will explore additional structural analysis techniques that involve other switch security mechanisms. For example, role-based access-control rules are order dependent. Depending on the sequence of these rules, a misconfiguration may result. An exploration of possible conflicts between individually consistent VSAN configurations due to Inter-VSAN Routing [12] will be also be investigated. Future work will adopt the threat-based approach in [4] to structure knowledge about switch security configurations in terms of threats with which to construct a catalogue of best practice countermeasures. One may then, in conjunction to structural and query analysis described in this paper, automatically generate suitable switch security configurations (countermeasures) that mitigate known SAN threats. This threat-based approach will also facilitate the construction of a best practice catalogue of candidate queries. Thus, providing inexperienced security administrators with the ability ask expert questions about the effectiveness of an existing switch security configuration. These candidate queries could be based on testing for best practice compliance. For example, to test if a switch security configuration is SNAI [19] compliant, the security administrator can draw upon a catalogue of SNAI candidate compliance queries. View publication stats ACKNOWLEDGMENT This research has been supported by Science Foundation Ireland grant 08/SRC/11403. R EFERENCES [1] J. Somasundaram and A. Shrivastava, Information Storage and Management: Storing, Managing, and Protecting Digital Information. Wiley, 2009. [2] F. Baader, D. Calvanese, D. L. McGuinness, D. Nardi, and P. PatelSchneider, The Description Logic Handbook: Theory, Implementation and Applications. Cambridge University Press, March 2003. [3] W. M. Fitzgerald, “An Ontology Engineering Approach to Network Access Control Configuration,” PhD Thesis, University College Cork, Ireland, August 2010. [4] S. N. Foley and W. M. Fitzgerald, “Management of Security Policy Configuration using a Semantic Threat Graph Approach,” Journal of Computer Security, Volume 19, Number 3, IOS Press, May 2011. [5] W. M. Fitzgerald and S. N. Foley, “Management of Heterogeneous Security Access Control Configuration using an Ontology Engineering Approach,” 3rd ACM Workshop on Assurable and Usable Security Configuration, Chicago, USA, October 2010. [6] A. Mayer, A. Wool, and E. Ziskind, “Offline Firewall Analysis,” International Journal of Information Security, vol. 5, no. 3, pp. 125– 144, May 2006. [7] R. Marmorstein and P. Kearns, “A Tool for Automated iptables Firewall Analysis,” Usenix Annual Technical Conference, Freenix Track, Pages: 71-81, Anaheim, CA, USA, April 2005. [8] E. S. Al-Shaer, H. H. Hamed, R. Boutaba, and M. Hasan, “Conflict Classification and Analysis of Distributed Firewall Policies,” IEEE Journal on Selected Areas in Communications, Issue: 10, Volume: 23, Pages: 2069 - 2084, October 2005. [9] F. Cuppens, N. Cuppens-Boulahia, and J. Garcı́a-Alfaro, “Detection and Removal of Firewall Misconfiguration,” IASTED International Conference on Communication, Network and Information Security (CNIS), Phoenix, AZ, USA, November 2005. [10] “IANA Port Numbers,” http://www.iana.org/assignments/port-numbers. [11] M. O’Connor, H. Knublauch, S. Tu, B. Grossof, M. Dean, W. Grosso, and M. Musen, “Supporting Rule System Interoperability on the Semantic Web with SWRL,” 4th International Semantic Web Conference (ISWC2005), Galway, Ireland, 2005. [12] Cisco MDS 9000 Family CLI Configuration Guide, Release 4.x., Cisco, February 2009. [13] Cisco MDS 9000 Family Command Reference, Release 5.x., Cisco, February 2010. [14] K. Scarfone and P. Hoffman, “Guidelines on Firewalls and Firewall Policy: Recommendations of the National Institute of Standards and Technology,” NIST Special Publication 800-41, Revision 1, September 2009. [15] K. Scarfone, W. Jansen, and M. Tracy, “Guide to General Server Security: Recommendations of the National Institute of Standards and Technology,” NIST Special Publication 800-123, July 2008. [16] J. Tate, F. Lucchese, and R. Moore, Introduction to Storage Area Networks. CIBM Redbooks, 2006. [17] F. Cuppens, N. Cuppens-Boulahia, T. Sans, and A. Miège, “A Formal Approach to Specify and Deploy a Network Security Policy,” 2nd Workshop on Formal Aspects in Security and Trust (FAST), Toulouse, France, August 2004. [18] M. G. Gouda and X.-Y. A. Liu, “Firewall Design: Consistency, Completeness and Compactness,” 24th IEEE International Conference on Distributed Computing Systems (ICDCS), Japan, March 2004. [19] Storage Security Best Current Practices (BCPs), Version 2.1.0, Storage Networking Industry Association (SNIA), September 2008.