Integrated development environment (IDE) for network security configuration files

PRIORITY CLAIM

This application claims priority to U.S. Provisional Application No. 62/163,523, filed May 19, 2015, the entirety of which is incorporated herein by reference.

TECHNICAL FIELD

The present disclosure relates to an Integrated Development Environment (IDE) for network security configuration files.

BACKGROUND

Integrated Development Environment (IDE) functionality is a tool for programming languages. Such IDE functionality does not exist for network security device configuration files, such as files that include access control lists (ACLs) used for network security appliances. Thus, network administrators are hampered when working with network security configuration files.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> is a cloud-based management system in which an Integrated Development Environment (IDE) is provided for a network security device configuration file, according to example an embodiment.

<figref idref="DRAWINGS">FIG. 2</figref> is a flowchart of a process for the IDE in a network security device, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 3</figref> is an illustration of an example format or syntax for a security rule on which the IDE may operate, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 4</figref> is a block diagram of an example hardware implementation for a management entity of the cloud-based management system of <figref idref="DRAWINGS">FIG. 1</figref> that may host the IDE, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 5</figref> is a flowchart of an example method of using the IDE to operate on configuration files, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 6</figref> is a flowchart of a generalized parser operation used of the method <figref idref="DRAWINGS">FIG. 5</figref>, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 7</figref> is a flowchart of operations expanding on a classify operation of the method of <figref idref="DRAWINGS">FIG. 5</figref>, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 8</figref> is an illustration of an example security rule classification database generated by the method of <figref idref="DRAWINGS">FIG. 7</figref>, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 9</figref> is an illustration of an example User Interface (UI) displayed by an editor in connection with the IDE and that shows a part of an opened configuration file, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 10</figref> is an illustration of another example UI displayed by the editor in connection with the IDE, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 11</figref> is an illustration of an example dictionary defining prohibited or potentially dangerous parameters, which may be used with the method of <figref idref="DRAWINGS">FIG. 5</figref>, according to an example embodiment.

<figref idref="DRAWINGS">FIG. 12</figref> is an illustration of an entry in a mapping database created by a security rule parser and used in the method of <figref idref="DRAWINGS">FIG. 5</figref>, according to an example embodiment.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

A method performed in a computer-implemented integrated development environment (IDE) is provided. A configuration file including security rules is preprocessed in the IDE. Each security rule includes multiple security rule parameters to cause a security appliance to apply a network access control when a source attempts to access a destination. At least one of the destination or the source in some of the security rules is represented as a respective object name, where each object name is associated with an object value defined in an object definition in the configuration file. To perform the preprocessing, each object name is mapped to the associated object value based on the object definition for that object name. In response to the configuration file being opened in an editor through which a user interacts with the security rules, the editor is provided with access to results of the preprocessing. Each security rule in the opened configuration file is searched for object names therein. Each object name found in the search is linked to the associated object value mapped thereto by the mapping performed during the preprocessing. A selection of an object name in a security rule of the opened configuration file is received and the associated object value linked to the selected object name is generated for display.

Example Embodiments

With reference to <figref idref="DRAWINGS">FIG. 1</figref>, there is shown a cloud-based management system <b>100</b> in which a network security device configuration file Integrated Development Environment (IDE) (referred to simply as an “IDE”) may be used, according to an embodiment. Cloud-based management system <b>100</b> communicates with network security devices of a customer datacenter <b>120</b>. <figref idref="DRAWINGS">FIG. 1</figref> shows the details of one customer datacenter, but it should be understood that the cloud-based management system <b>100</b> may connect and communicate with multiple customer datacenters.

The cloud-based management system <b>100</b> includes a management entity <b>110</b> including one or more computer servers <b>112</b>(<b>1</b>)-<b>112</b>(M) that execute software to perform the operations associated with an IDE and, in this way, management entity <b>110</b> is said to host the IDE. An example of a hardware configuration for management entity <b>110</b> is described in more detail below in connection with <figref idref="DRAWINGS">FIG. 4</figref>.

Customer datacenter <b>120</b> includes a plurality of network security devices or products (also referred to as network security appliances) <b>130</b>(<b>1</b>)-<b>130</b>(P). Within a customer datacenter there are one or more resources <b>140</b> and one or more actors <b>150</b>. The resources <b>140</b> may include servers, databases, and the actors <b>150</b> are users or processes using a computing device (personal computer, SmartPhone, etc.) that may seek access to one or more of the resources <b>140</b>. The resources and actors may also reside outside the customer datacenter itself, e.g., in the Internet. The network security devices <b>130</b>(<b>1</b>)-<b>130</b>(P) control access of the actors <b>150</b> to the resources <b>140</b> according to network security policies, e.g., sets of one or more network security rules configured on the respective network security devices. The IDE hosted in management system <b>100</b> may be used to examine, validate, and edit the network security policies.

Turning now to <figref idref="DRAWINGS">FIG. 2</figref>, there is a flowchart of a method <b>200</b> of using the IDE in the environment of <figref idref="DRAWINGS">FIG. 1</figref>. <figref idref="DRAWINGS">FIG. 2</figref> is described with continued reference to <figref idref="DRAWINGS">FIG. 1</figref>. At <b>205</b>, a customer (e.g., a business or enterprise) is “on-boarded” to cloud-based management system <b>100</b>. This involves a network administrator/user <b>180</b> logging on to a log-on web page <b>185</b> served by one of the servers <b>112</b>(<b>1</b>)-<b>112</b>(M) of the management entity <b>110</b>. The log-on web page <b>185</b> allows network administrator <b>180</b> to set up privileges to permit management entity <b>110</b> to communicate, over the Internet, with customer datacenter <b>120</b> in order to connect to network security devices <b>130</b>(<b>1</b>)-<b>130</b>(P). In addition, during the initial log-in and setup phase, network administrator <b>180</b> provides names and address (e.g., Internet Protocol (IP) addresses) for each of network security devices <b>130</b> in customer datacenter <b>120</b>. Other types of set-up processes may be used other than use of a log-on web page.

At <b>210</b>, management entity <b>110</b> discovers network security devices <b>130</b> and may import the policies as policy data from each network security device. Briefly, this involves sending a connection string and device type tag to each network security device <b>130</b>(<i>i</i>). Each network security device <b>130</b>(<i>i</i>) responds with device descriptor and policy data for each network security rule configured on the respective network security device. An example subset of the policy data imported form a security device may be: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0022">Protocol: HTTPS</li><li id="ul0002-0002" num="0023">Network: All</li><li id="ul0002-0003" num="0024">Destination: 132.180.0.0/24</li><li id="ul0002-0004" num="0025">Description: Web</li><li id="ul0002-0005" num="0026">Policy: On</li><li id="ul0002-0006" num="0027">Logging: On</li></ul></li></ul>

Management entity <b>110</b> stores the discovered data describing the discovered security devices <b>130</b> and their native policies. The native policies are stored into respective configuration files (where each configuration file is also referred to as a “config file” or simply a “config”). Each native network security policy may be one or more native network security rules associated with a named network security device and formatted according to a corresponding native policy model for a network security device. Each native network security rule may in turn include a set of security rule parameters to permit or deny network access for the named network security device based on a network protocol, source and destination addresses, and a device port.

At <b>215</b>, network administrator <b>180</b> may invoke the IDE hosted on management entity <b>110</b> to display, examine, validate, edit, and/or compare the security rules in one or more of the configuration files created in operation <b>210</b> or other preexisting configuration files stored in management entity <b>110</b>, as described below in connection with <figref idref="DRAWINGS">FIG. 5</figref>.

At <b>220</b>, administrator/user <b>180</b> may also use the IDE to generate and validate new configuration files.

With reference to <figref idref="DRAWINGS">FIG. 3</figref>, there is an illustration of an example format or syntax for an example security rule <b>300</b> on which the IDE may operate. Security rule <b>300</b> is formatted as an access control list (ACL)—extended rule, in which: “NAME” is an object or object group (i.e., a name of a group of rules); “EXT” is a constant; “PERMIT|DENY” is an access control imposed by the rule; “Protocol” is a communication protocol used for an attempted access and may be expressed as an object or an object group. “S” and “D” may each be a tuple that expresses a service port and address, and may be expressed as either an object or an object group, e.g., “all my inbound email” or “all my outbound email,” or called by an object name. S and D may each be identified as a string. In an example, “any” means any port, any address.

Further examples of network security rules that the IDE may operate on include: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0033">1. Access-list left-to-right extended permit ip host 172.16.1.10 host 192.168.1.10.</li><li id="ul0004-0002" num="0034">2. Access-list someName extended permit tcp 172.19.103.0 255.255.255.0 object-group ApplicationServers object-group DM_INLINE_TCP_443.</li><li id="ul0004-0003" num="0035">3. Block all users from using facebook messaging.</li><li id="ul0004-0004" num="0036">4. Allow all users to use Linked in but only allow HR to post jobs on Linkedin, allow all users to use Linkedin.</li></ul></li></ul>

Turning now to <figref idref="DRAWINGS">FIG. 4</figref>, a block diagram is shown of an example hardware implementation for the management entity <b>110</b>. In one example, the management entity <b>110</b> includes one or more servers <b>112</b>(<b>1</b>)-<b>112</b>(M). Each server includes one or more processors <b>410</b>, one or more network interface units <b>412</b> and memory <b>414</b>. The memory <b>414</b> stores control software <b>416</b>, that when executed by the processor(s) <b>410</b>, cause the server to perform the various operations described herein for the management entity <b>110</b> and the IDE. Local user input/output devices (not shown) may be coupled with management entity <b>110</b> to enable a user to enter information and receive information from the management entity. Such devices include, but are not limited to, a display, a keyboard, a mouse, and so on.

The processor(s) <b>410</b> may be a microprocessor or microcontroller (or multiple instances of such components). The network interface unit(s) <b>412</b> may include one or more network interface cards that enable network connectivity.

The memory <b>414</b> may include read only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physically tangible (i.e., non-transitory) memory storage devices. Thus, in general, the memory <b>414</b> may comprise one or more tangible (non-transitory) computer readable storage media (e.g., memory device(s)) encoded with software or firmware that comprises computer executable instructions. For example, control software <b>416</b> includes logic to implement the operations described herein in connection with the IDE, a security rule editor associated with the IDE, and a User Interface (UI) (such as a Graphical User Interface (GUI)) associated with the IDE. Memory <b>414</b> also stores data (not shown) generated and used by the aforementioned logic. For example, the data may include a mapping database to map object names expressed in security rules to object attributes, and security rule classifications, all of which are described below.

Administrator <b>180</b> may interact with management entity <b>110</b> through UIs by way of a user device <b>420</b> that connects by way of a network (local area network (LAN) and/or wide area network (WAN)) with the management entity <b>110</b>. The user device <b>420</b> may be a personal computer (laptop, desktop), tablet computer, SmartPhone, etc.

With reference to <figref idref="DRAWINGS">FIG. 5</figref>, there is a flowchart of an example method <b>500</b> of using the IDE in cloud-based management system <b>100</b> to operate on configuration files, e.g., for network security devices <b>130</b>. A given configuration file may be a named text file including multiple entries, e.g., sequential lines in the text file, at least some of which correspond to network security rules. Each network security rule includes multiple security rule parameters to cause a network security device to apply a network access control (e.g., permit or deny) when a source (e.g., an IP address or a range of IP addresses) attempts to access a destination (e.g., an IP address or a range of IP addresses). Either the destination or the source (or both) in some of the security rules may be represented as/by a respective object name associated with an object value defined in an object definition of the configuration file. For generality, the object name may name an object group or simply and object. Also, some of the configuration file entries may represent delineated remarks or comments interspersed among the security rules and that have no effect on the security appliance.

At an initial configuration file preprocessing operation <b>505</b>, user <b>180</b> invokes the IDE to access a configuration file and preprocess the accessed configuration file. Operation <b>505</b> creates configuration file preprocessing results accessible to and used by subsequent operations <b>520</b> (expanded in further operations <b>525</b>-<b>550</b>) invoked by a user through a configuration file editor that becomes linked with the preprocessing results. The preprocessing results may be stored, for example, in a companion file associated with or linked to the configuration file. Configuration file preprocessing operation <b>505</b> includes preprocessing sub-operations <b>510</b> and <b>515</b>, now described. In an embodiment, operation <b>500</b> may access and preprocess multiple configuration files.

At <b>510</b>, the IDE performs a parser operation, described here at a high-level, to parse the security rules in the configuration file based on a native security rule syntax/grammar to build a mapping database, e.g., a lookup table. The mapping database maps object names in security rules to their associated object values.

At <b>515</b>, the IDE classifies the security rules in the configuration file into different security rule classifications based on commonality between the security rules. In another embodiment in which multiple configuration files are accessed for preprocessing, the IDE classifies the security rules across the multiple configuration files based on commonality between the security rules across the multiple configuration files.

In an embodiment, the IDE classifies the security rules, within one configuration file or across multiple configuration files, into one or more identical security rule classifications based on identicality (i.e., a measure of identicality) between the security rules, such that each identical security rule classification includes security rules that are identical to each other. The IDE also classifies the security rules into one or more similar security rule classifications based on similarity (i.e., a measure of similarity) but not identicality between the security rules, such that each similar security rule classification includes security rules that are similar but not identical to each other. The IDE stores the various security rule classifications in a security rule classification database that also associates each classified security rule with file location, including (i) a name of the configuration file in which the security rule is found, and (ii) a location, e.g., a line number, where the security rule is found in the configuration file.

Operations <b>505</b> and <b>510</b> generate preprocessing results including but not limited to (i) the lookup table that maps object names to object values, and (ii) the security rule classifications, which are accessed in subsequent IDE operations <b>520</b>, as described below. Operations <b>520</b> include operations <b>525</b>-<b>550</b> performed on a configuration file after it has been preprocessed and opened using an editor, such as a text editor, associated with the IDE.

At <b>525</b>, responsive to user interaction, the user opens the configuration file in an editor, such as a text editor, through which the user interacts with the security rules in the (opened) configuration file. The user may access the editor through the IDE, i.e., the editor may be provided by the IDE. The editor may add line numbers adjacent each of the security rules and remarks in the opened configuration file and display the line numbers along side the aforementioned entries. Responsive to the configuration file being opened in the editor, the IDE links the opened configuration file with the preprocessing results generated in operation <b>505</b>. To do this, the IDE may link the opened editor to the preprocessing results using an address pointer or a file pointer directed to the preprocessing results. In this way, the IDE makes the preprocessing results accessible to the editor and, as a result, the user may access the preprocessing results through interaction with the editor.

At <b>530</b>, the IDE searches each security rule in the configuration file for object names therein. The IDE links or maps each found object name in the security rule to the associated object value mapped thereto in the lookup table of the preprocessing results.

At <b>535</b>, the IDE performs regular expressions searches on security rule parameters in the opened config file and generates for display visual indications associated with security rule parameters found to match the regular expressions.

The regular expression search may include a search of the security rule parameters of each security rule for an object or object group designator (e.g., the label “object” or the label “object-group”) followed by an object name. For each found object or object group designator, the IDE generates for display (e.g., via the editor) a visual object or object group indication to visually differentiate the found object or object group designator from other security rule parameters that are not object or object group designators. As a result, for example, each found object or object group designator may be highlighted in blue when displayed by the editor.

The regular expression search may also include a search for delineated remarks interspersed among the security rules and that have no effect on the security appliance. For each found remark, the IDE may generate for display a visual remark indication to visually differentiate the found remark from the security rules. For example, each found remark may be “greyed-out” when displayed by the editor.

The regular expression search may include a search of the security rule parameters of each security rule for a delimiter, such as “access-list” indicating that a current line in the configuration file is dedicated to a security rule. For each found security rule delimiter, the IDE may generate for display a visual security rule indication to visually differentiate the found security rule delimiter.

Other regular expression searches may be performed and their results indicated visually through the editor.

At <b>540</b>, the IDE compares security rule parameters in the configuration file to a dictionary that defines prohibited or potentially dangerous parameters and corresponding warnings, and generates for display the warnings associated with any found matches. The dictionary may be generated by the administrator before operations <b>520</b> are invoked.

At <b>545</b>, the IDE receives a user selection of an object name in a security rule in the configuration file via the editor. For example, the user may hover a cursor over the object name or use a mouse to click on the object name, which results in the selection of that object name. In response to the selection, the IDE accesses the object value associated with the selected object name that was linked to the object name at previous operation <b>530</b>. The IDE generates for display (via the editor) the object value linked to the selected object name. If the IDE is unable to access an object value for the selected object name (because there is no object definition for that object name in the configuration file) the IDE generates for display an error message indicating that the selected object name is not defined. Also, if the IDE determines from the mapping database that the selected object name resolves to two different values, the IDE generates for display an error messages indicating an error associated with the selected object name. The aforementioned errors may also be identified and flagged to the user visually during the parser operation <b>510</b>.

At <b>550</b>, the IDE receive a user selection of a security rule in the configuration file through the editor, e.g., when the user selects one of the line numbers displayed adjacent a security rule by the editor. In response, the IDE searches for an entry, corresponding to the selected security rule, in any of the security rule classifications that were generated at previous operation <b>540</b>. If an entry is found in one of the security rule classifications, the IDE generates for display all of the other rules in the one of the classifications along with the file locations of the other rules (e.g., line numbers and filenames for the other rules).

With reference to <figref idref="DRAWINGS">FIG. 6</figref>, there is a flowchart expanding on high-level parser operation <b>510</b> of method <b>500</b>, according to an embodiment.

A lexer operation <b>605</b> (also referred to as “lexer” <b>605</b>) receives the configuration file, including the security rule parameters of the security rules, the object definitions, and the remarks, in the form of a character stream. Lexer <b>605</b> also receives a predetermined lexer grammar file for the security rules including acceptable security rule tokens and grammar rules for the tokens. Lexer <b>605</b> tokenizes the security rule parameters of each security rule based on the lexer grammar file to produce a stream of tokens, and delivers the stream of tokens to parser operation <b>610</b> (also referred to as “parser <b>610</b>”).

In addition to the stream of tokens, parser <b>610</b> receives predetermined parser grammar rules for the security rules. Parser <b>610</b> parses the stream of tokens, including object definitions and object names therein, based on the parser grammar rules to build a hierarchical parser tree from the tokens in the stream of tokens. Each time parser <b>610</b> encounters an object name while building the parser tree, the parser creates an entry for the object name in the mapping database (indicated at <b>615</b> in <figref idref="DRAWINGS">FIG. 6</figref>) that maps the object name to its attributes. Parser <b>610</b> searches the object definition tokens for the attributes defined for each object name. The attributes include (i) one or more values associated with the object name as defined in a corresponding configuration file object definition, and (ii) a location in the configuration file, e.g., a line number, of the security rule in which the object name is found. Mapping database <b>615</b> may be implemented as a lookup table that uses a hash map to map each object name to its corresponding attributes. Parser <b>610</b> also delivers each parsed security rule to security rule classification operation <b>515</b>, described in detail below.

At operation <b>515</b> described above, the IDE classifies security rules into security rule classifications. To do this, the IDE compares each security rule to every other security rule in the configuration file or to every other security rule across multiple configuration files to determine how similar the security rule is to the other security rules based on one or more commonality/similarity criteria. Based on results of the compare, the IDE classifies the security rule into one or more security rule classifications, such as identical classifications or similar classifications. As mentioned above, each security rule typically includes security rule parameters, such as a name of a group of rules (e.g. “inside-in” vs. “inside-out”), an access control (e.g., permit or deny), a protocol (e.g., IP, TCP, UDP, ICMP), a source (e.g., IP address), a destination (e.g., IP address), device/service ports, interfaces, and/or context (e.g. a deny rule surrounded by other deny rules), where some of the security rule parameters may be expressed as an object name or object group name associated with attributes. The security rule parameters represent points of comparison used to classify the security rules. For example, to compare two security rules, their corresponding security parameters or points of comparison are compared, as will be described below.

With reference to <figref idref="DRAWINGS">FIG. 7</figref>, there is a flowchart of operations <b>700</b> expanding on classify operation <b>510</b> of method <b>500</b>. Operations <b>700</b> determine commonality/similarity between security rules based on their corresponding points of comparison (i.e., corresponding security parameters), and classify the security rules based on results of the determine operation.

At <b>705</b>, different points of comparison (i.e., security rule parameters) are defined. These points of comparison will form a basis for a determination as to whether different security rules are sufficiently similar as to be placed together into a similar security rule classification or sufficiently identical to be placed together into a an identical security rule classification.

At <b>710</b>, a weight or coefficient w_iis assigned to each point of comparison.

At <b>715</b>, corresponding ones of the points of comparison from the different security rules being compared are compared to each other to arrive at a Boolean result, e.g., match=1, no match=0.

At <b>720</b>, each Boolean result is multiplied by the corresponding assigned weight to produce weighted Boolean results.

At <b>725</b>, the Boolean results are combined into a match score according to a predetermined expression/equation.

At <b>730</b>, the match score is compared to a non-zero similarity score threshold and a non-zero identicality score threshold that is greater than the similarity score threshold. If the compare indicates the match score is equal to or greater than the similarity score threshold but less than the identicality score threshold, the different (compared) network security rules are deemed similar to each other and thus classified into the similar security rule classification. If the compare indicates the match score is equal to or greater than the identicality score threshold, the different network security rules are deemed identical to each other and thus classified into the identical security rule classification. If the compare indicates the match score is below the similarity score threshold, the different network security policies are deemed dissimilar to each other and, optionally, may be classified into a unique classification. When a security rule is classified into a similar or identical security rule classification, the security rule is entered into the classification along with a descriptor that identifies the file location (e.g., line number and file name) of that security rule as well as an indicator of the type of commonality, e.g., similar or identical, associated with the classification.

In an example in which operation <b>705</b> of method <b>700</b> defines as the points of comparison various rule parameters used in the access list—extended model, operation <b>725</b> may evaluate the following expression, in which “|match on &lt;point of comparison&gt;?|” defines a match/comparison test that evaluates to a Boolean result: <br />match score=<i>w</i>₁|match on name?|*<i>w</i>₂|match on permit/deny?|*<i>w</i>₃|match on protocol?|*<i>w</i>₄|match on source address?|*<i>w</i>₅|match on destination address?|+[<i>w</i>₆|match on service ports?|+<i>w</i>₇|match on rule context?|].

In the above equation for match score, both a multiplicative combination and an additive combination of tests results are used. The multiplicative combination is used for points of comparison deemed of higher importance, while the additive combination is used for points of comparison deemed of lower importance. Also, weights w_imay be initially set to 1, but other values may be used. In addition, the similar score threshold may be set to 2 and the identical score threshold may be set to 4, for example, so that if the match score evaluates to 2 or 3, the security rules being compared are deemed similar, and if the match score evaluates to 4 or greater, the security rules being compared are deemed identical, otherwise the security rules are deemed unique.

With reference to <figref idref="DRAWINGS">FIG. 8</figref>, there is an illustration of an example security rule classification database <b>800</b> generated by method <b>700</b>. In the example of <figref idref="DRAWINGS">FIG. 8</figref>, database <b>800</b> is represented as a table having rows <b>805</b> each to represent a respective security rule classification into which multiple security rules have been classified. The columns include: a rule index that lists file locations, such as line numbers L1, L2, and so on, that are an index or key to the security rules in the security rule classification for the given row; security rule identifiers including the location (e.g., line number Li and filename Fi) of each security rule Ri in the security rule classification for the given row; and a commonality type for the security rule classification for the given row (e.g., “similar” or “identical”). The security rule identifiers, e.g., line number Li and filename Fi, may include address pointers to a given line number Li in a given named file Fi for a given security rule Ri. In the example of <figref idref="DRAWINGS">FIG. 8</figref>, row 1 represents a similar security rule classification into which similar security rules R1 (located at line L1 in filename F1) and R3 (located at line L3 in filename F1) are classified. Row 2 represents an identical security rule classification into which identical security rules R4 (located at line L4 in filename F1) and R5 (located at line L5 in filename F2) are classified. The information in database <b>800</b> may be organized in many different ways, such as in one or more linked lists of classification nodes that each store rule locations and indicators of commonality type.

Security rule classification database <b>800</b> may be used in the following manner. At operation <b>550</b> described above, the IDE receives a user selection of a security rule through the editor. The IDE uses the line number of the selected rule (available from the editor) as an index to search the rule indexes of classification database <b>800</b> for a match. If a match is found, the IDE accesses the rule identifiers and the commonality type in the row (i.e., security rule classification) of database <b>800</b> corresponding to the match. The IDE uses the rule identifiers to locate and access the other security rules, from their respective files and line numbers within those files, that are in the same classification as the selected rule and generates for display the other security rules, their locations, and the commonality type. For example, if the selected rule is on line 1 of the file with filename F1, the IDE uses line L1 as the index to find the similar security classification corresponding to row 1 of database <b>800</b>, and to access information for the other security rule R3 in that classification.

With reference to <figref idref="DRAWINGS">FIG. 9</figref>, there is an illustration of an example User Interface (UI) <b>900</b> displayed by an editor responsive to information generated for display in connection with the IDE and that shows a part of an opened configuration file (i.e., “config”) named “NEWYORK” in an edit window <b>905</b>. Edit window <b>905</b> shows line numbers <b>910</b> for each line of the configuration file. Each line represents a corresponding security rule. In the example of <figref idref="DRAWINGS">FIG. 9</figref>, the security rule parameters include, but are not limited to, a security rule indicator <b>922</b> (e.g., access list), an object group designator <b>924</b> (e.g., “object-group”), and an object group designator <b>926</b>. These security rule parameters are all regular expressions found in the regular expression search of operation <b>535</b> and are, therefore, highlighted for ease of recognition by the viewer. In line <b>630</b>, “DM_INLINE_1” and “Voyage_DMZ” are object group names having attributes defined in the object definitions of config NEWYORK (not specifically shown in <figref idref="DRAWINGS">FIG. 9</figref>).

In the example of <figref idref="DRAWINGS">FIG. 9</figref>, the user has selected the security rule on line <b>631</b>, e.g., by clicking on line number <b>631</b>. In response, the IDE has searched classifications database <b>800</b> linked by the IDE to configuration file NEWYORK and found that the security rule at line <b>631</b> belongs to a similar security rule classification indicating similar security rules at lines <b>632</b> and <b>633</b> of config NEWYORK. Thus, UI <b>900</b> also includes a classification window <b>930</b> (containing information generated by the IDE and displayed by the IDE) to indicate that the security rules at lines <b>632</b> and <b>633</b> are similar to the selected security rule at line <b>631</b>.

With reference to <figref idref="DRAWINGS">FIG. 10</figref>, there is an illustration of another example User Interface (UI) <b>1000</b> displayed by the editor in connection with the IDE and that shows a part of opened configuration file NEWYORK in an edit window <b>1005</b>. In the example of <figref idref="DRAWINGS">FIG. 10</figref>, the user has selected object-group name <b>1010</b> “DM_INLINE_SERVICE_1.” In response to the user selection, the IDE has accessed the attributes linked to object-group name <b>1010</b> in the mapping database <b>615</b>. Thus UI <b>1000</b> also includes an attributes window <b>1015</b> generated by the IDE that indicates the attributes mapped to the selected object-group.

With reference to <figref idref="DRAWINGS">FIG. 11</figref>, there is an illustration of an example dictionary that defines prohibited or potentially dangerous parameters that may be used in operation <b>540</b>. In the example of <figref idref="DRAWINGS">FIG. 11</figref>, dictionary <b>1100</b> defines/stores a security parameter “any any” and a corresponding warning “warning” to be displayed via a UI should the stored security parameter be found in one of the security rules of a configuration file in operation <b>540</b>.

<figref idref="DRAWINGS">FIG. 12</figref> is an illustration of an example entry <b>1200</b> in mapping database <b>615</b> created and used in the method of <figref idref="DRAWINGS">FIG. 5</figref>, according to an example embodiment. The entry maps the object group name “DM_INLINE_SERVICE_1” to its various attributes <b>1205</b> as defined in the corresponding object definitions of the configuration file. The attributes are displayed in connection with selected object group name “DM_INLINE_SERVICE_1” in the UI <b>1000</b> of <figref idref="DRAWINGS">FIG. 10</figref>.

In summary, the IDE is used to operate on configuration files in a way that extends functionality beyond that of a mere text editor. The IDE preprocesses a configuration file. Once the configuration is preprocessed, the IDE is able to perform extended configuration file examination functions. For example, the IDE compares each object name used in the security rules against the object definitions and, if the object name is missing from the object definitions, the IDE provides feedback to an administrator/user (via a UI) that the object name is not defined. Also, if the same object name resolves to two different values, this is flagged as an error to the user. The IDE also compares object names in the configuration file against a dictionary of known vulnerabilities and, if a match occurs, warns the user that the object names create known vulnerabilities. For example, security rule parameters such as “any any” may be included in the dictionary of vulnerabilities because any instance of “any any” in any security rule allows “any server to talk to any server” and, therefore, should possibly be flagged as security vulnerability.

The IDE uses syntax highlighting to indicate operational vs. non-operational parts of security rules and to distinguish between security rules and remarks. In syntax highlighting, comments (i.e., remarks) are greyed-out and object names are highlighted. The IDE also exposes/reveals underlying definitions associated with a security rule object name when the object name is selected by a user. To do this the IDE conveniently displays the definition/values of the selected object name parsed earlier so the user does not have to scroll through the file to look for the definitions mapped to the selected object name. The IDE may perform an auto-complete on operations entered by a user into the configuration file and also highlights errors. The IDE compares user selected lines (security rules) in one version of a configuration file against lines in other versions of the file. The IDE displays to the user lines from other configuration files that are the same or similar to a line selected in a current configuration file. The IDE provides the user with immediate visual feedback when the user edits, defines, or simply views a configuration file regarding whether the file is correct or incorrect.

The IDE is integrated with a security rule classifier that identifies identical, similar, and unique rules across multiple configuration files. Assume several configuration files have been imported and the security rules therein have been classified into identical, similar, and unique groups using the rule classifier. In the IDE, the user may select (e.g., click on) a security rule in one configuration file which was found in several of the other configuration files and thus classified as identical to the other rules in the other files. Responsive to the user selection of the rule in the one configuration file, the IDE recognizes that the configuration rule is identical to the other rules from the other configuration files and displays a list that shows the other security rules from the other configuration files and identifies their locations in the other configuration files.

The IDE also performs security rule consistency checking and provides feedback if a security rule entered in a configuration file by the user is inconsistent with an earlier entered security rule. For example, consider a first rule that gives access to everybody to anywhere, then any subsequent more restrictive rule is inconsistent or contradictory and is flagged as such by the IDE. The IDE can flag object names that were not previously defined.

In summary, features of IDE include: <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0082">1. An interactive UI that enables the user to visualize many features associated with one or more security configuration files (as follows).</li><li id="ul0006-0002" num="0083">2. Finding identical and similar security rules within and across configuration files, and displaying the results.</li><li id="ul0006-0003" num="0084">3. Performing security rule validation, finding invalid security rules, such as undefined names.</li><li id="ul0006-0004" num="0085">4. Detecting logical security rule misconfigurations, e.g., use of “any any” followed by rules that try to restrict (e.g., Access List inside ACL Ext Permit Any Any—means anyone can access the firewall, so any subsequent rule is inconsistent).</li><li id="ul0006-0005" num="0086">5. Detecting known vulnerabilities based on a dictionary of known vulnerabilities.</li><li id="ul0006-0006" num="0087">6. Syntax highlighting, e.g., shadowing comments (remarks) and highlighting of object names.</li><li id="ul0006-0007" num="0088">7. Syntax validation.</li></ul></li></ul>

In summary, in one form, a method is provided comprising: in a computer implemented integrated development environment: preprocessing a configuration file including security rules, each security rule including multiple security rule parameters to cause a security appliance to apply a network access control when a source attempts to access a destination, at least one of the destination or the source in some of the security rules represented as a respective object name, each object name associated with an object value defined in an object definition in the configuration file, the preprocessing including mapping each object name to the associated object value based on the object definition for that object name; responsive to the configuration file being opened in an editor through which a user interacts with the security rules, providing the editor with access to results of the preprocessing; searching each security rule in the opened configuration file for object names therein; linking each object name found in the searching to the associated object value mapped thereto by the mapping performed during the preprocessing; and receiving a selection of an object name in a security rule of the opened configuration file and generating for display the associated object value linked to the selected object name.

In another form, an apparatus is provided comprising: a network interface unit configured to enable communications over a network; and a processor, coupled to the network interface unit, configured to, in a computer implemented integrated development environment: preprocess a configuration file including security rules, each security rule including multiple security rule parameters to cause a security appliance to apply a network access control when a source attempts to access a destination, at least one of the destination or the source in some of the security rules represented as a respective object name, each object name associated with an object value defined in an object definition in the configuration file, wherein the processor is configured to preprocess by mapping each object name to the associated object value based on the object definition for that object name; responsive to the configuration file being opened in an editor through which a user interacts with the security rules, provide the editor with access to results of the preprocessing; search each security rule in the opened configuration file for object names therein; link each object name found in the searching to the associated object value mapped thereto by the mapping performed during the preprocessing; and receive a selection of an object name in a security rule of the opened configuration file and generating for display the associated object value linked to the selected object name.

In still a further form, a method is provided comprising: in a computer implemented integrated development environment: preprocessing a configuration file including security rules, each security rule configured to cause a security appliance to apply a network access control when a source attempts to access a destination, the preprocessing including classifying the security rules in the configuration file into security rule classifications based on commonality between the security rules; responsive to the configuration file being opened in an editor through which a user interacts with the security rules, providing the editor with access to results of the preprocessing; receiving a selection of a security rule in the opened configuration file; responsive to the selection, determining whether the selected security rule is classified into any of the security rule classifications; and if it is determined that the selected security rule is classified into one of the security rule classifications, generating for display the security rules in the one of the security rule classifications.

In yet another form, a non-transitory tangible computer readable storage media encoded with instructions is provided. The instructions, when executed by a processor, cause the processor to perform the methods described herein.

The above description is intended by way of example only. Various modifications and structural changes may be made therein without departing from the scope of the concepts described herein and within the scope and range of equivalents of the claims.