InfoSecter Introduction

Welcome to the Information Security Dissector also known as InfoSecter. With this tool, you will gain a greater understanding of how accurately your network security devices are enforcing your enterprise's security policy.

InfoSecter works on configurations from a variety of network security device vendors. All of these devices control how packets are handled through the evaluation of ordered lists of rules often called access control lists (ACLs). Changes to a rule within a long ordered list may have unintended consequences. InfoSecter helps you understand how your current configurations operation and the implications of potential changes without having to deploy the configurations.

InfoSecter supports the types of analysis.

InfoSecter is implemented in three programs:

InfoSecter processes configurations from a growing list of security device vendors. The current list includes:

1 Basic Concepts

InfoSecter processes security device configurations to help the user understand how his network security device configuration really works. InfoSecter operations involve a number of core concepts.

1.1 Cross Interface

For some families of security devices (particularly Cisco devices), the configuration language describes how packets should be handled with respect to a single interface either for packets entering that interface or packets leaving that interface.

At run time, packets will cross two interfaces, and thus features configured on both the inbound and outbound interfaces will affect how that packet is handled. It can be useful to look at conflicts on a single interface basis, but it is can also be useful to understand how the device will handle packets flowing over pairs of interfaces.

The Cross Interface option in Analyzer changes the operation so pairs of interfaces will be analyzed. The routing information and address translation information in the configuration is used to determine how packets will flow between pairs of interfaces at run time. InfoSecter will be conservative about determining whether a packet can cross a pair of interfaces, so there may be reports about packets crossing a pair of interfaces when in reality those packets would not cross those interfaces.

1.2 Security Device Features

Security devices include firewalls, IPSec devices, proxies, and address translation devices. The trend in security devices is to include more and more functionality in a single box as witnessed by the expanding Unified Threat Management (UTM) space. Therefore, when reviewing the implementation of a security device either by manually reading the configurations, scanning, or using a tool like InfoSecter, it is not sufficient to merely determine whether the device will drop or pass a packet. The implementation review must also determine how the device will process packets that eventually pass through the device. If the policy indicates that traffic must be proxied in when passed through the security device, the implementation review must include this information.

InfoSecter tracks the application of the following security device features

Feature Alignment

On many security devices, different security features are specified in different ACLs or rule tables. This can result in shorter and simpler rule lists for some devices, but it makes it difficult for a human to look at the configuration and get a good understanding of how packets are processed end-to-end. For Dissection, Cross Conflict, and Policy Validation InfoSecter first aligns all features that apply to a packet traversing an interface (or a pair of interfaces in the Cross Interface case). This means that the resulting reports show everything that will happen to the packets enumerated in the report.

1.3 Self Conflict

This operation looks for conflicts between rules within the same rule table. For most families of security devices configuration of features is controlled by ordered rule lists often called access control lists (ACLs). If a packet matches a rule, the device will apply the corresponding action even if a later rule also matches and is what the system administrator intendend.

Almost all configurations will have conflicts within their tables, and most of those conflicts will be innocuous. However, unintended conflicts are a major source of configuration errors, and conflicts should be carefully examined and understood when reviewing a network security device configuration.

1.4 Cross Conflict

The Cross Conflict operation compares the functionality defined by a pair of network security device configurations. These may be configurations from two different versions of a configuration for the same device, or they may be configurations from two devices that should be performing equivalent roles in a network security architecture (potentially configurations from different versions or different vendors).

Textual differences can be used as a quick approximation to a functional difference, but the textual difference has some problems. A straight textual difference will catch changes that have no functional impact (e.g. configuration element name changes). The textual difference may miss functionality changes caused by lines that are not changed directly but affected by textual changes to earlier lines.

Change Review

Changes to large ordered rule tables can easily have unintended consequences. By enumerating how packets will be handled differently between the two configurations, you can easily review and understand all differences. Cross Conflict reports can streamline your organization's change review process. Rather than looking over all configuration lines in the new version of a configuration file, you can concentrate on the lines that affect functionality changes as indicated in the Cross Conflict report.

Device Migration

The Cross Conflict operation is useful when you are migrating from one firewall device to another (say from a PIX to ASA or a IOS to Netscreen). InfoSecter build common models from the configurations and performs a functional comparison. Therefore, you can build a proposed configuration for the new device and then use the Cross Conflict operation to generate a report of the packets that are handled differently between the two configurations, and review that hopefully small set of packets to update your new device's configuration as necessary.

The Cross Conflict operation can be performed against single interfaces or it can analyze flows over pairs of interfaces using Cross Interface mode.

1.5 Dissection

The Dissection operation creates a table of non-conflicting packet areas called slices. Each slice represents a set of packets that all have the same firewall actions performed. Further, each possible packet will be present in exactly one slice. This removes ambiguity when trying to understand how a configuration will operate so that when the slice containing a packet at issue is found no more searching is needed to know that the behavior of the slice is how the packet would be handled by the firewall.

Browsing

Combined with filtering, Dissection lets you interactively learn about a configuration and determine if the configuration is operating according to the guiding security policy. This can be useful in the cases when you must quickly learn about new configurations. For example, when you are new to an organization, your organization must incorporate a set of devices (e.g. through a merger), or you are a consultant or auditor working with a new customer.

Remediation

Dissection and filtering can also be useful for remediation. Say you are given a set of packets that are causing a problem, e.g. they are passing when they shouldn't be or they are not being appropriately processed, but you don't know which of the 100's or 1000's of lines in your configuration need to be changed to fix the problem. You can build a dissection report of the configuration, and then set up a filter to concentrate on how the problem packets are being handled. The dissection slices include references to the configuration lines that cause the action. You have reduced the number of lines down to a handful, and at this point it is generally obvious what needs to be changed in the configuration.

You can dissect rule tables of independent interfaces. Alternatively, you can use the cross interface calculation to compute a dissection of how packets are handled as they flow across pairs of interfaces.

1.6 Policy Validation

It can be useful to have standing policy checks that are scripted to be run against configurations at key points in the network security implementation lifecycle. InfoSecter provides Querent to help you write and manage descriptions of sets of packets and their expected actions. InfoSecter can process these packet descriptions or expressions against a device configuration in one of two ways: as a query or a constraint.

In both cases, Analyzer computes the lines of the configuration that affect the packets in the description. In the query case, Analyzer creates a report that includes the packet processing configuration lines that match the packet expression. In the constraint case, Analyzer creates a report that includes that packet processing configuration lines that do not match the packet expression.

Invoke a query if there are key areas of the packet space you particularly want to review. This is very similar to settting filters within Visualizer while reviewing a dissected configuration.

Invoke a constraint if there are key action and packet settings that must always be preserved. The packet expression specifies this constraint. You only need to be informed if the constraint is violated. Thus, you can develop a library of constraints based on the operations in your information and run the constraints against every proposed configuration change.

In both cases, the report describes the affected packet areas and provides lines from the packet expression to the configuration lines that impact the packet for this configuration.

2 InfoSecter Visualizer

Visualizer is a graphical application in the InfoSecter product that is used to visualize the results of running Analyzer. It diplays the slices generated by Analyzer along with the original configuration(s) used. Visualizer also supports sorting and filtering the slices to rapidly locate the interesting slices and from there the original configuration source lines of interest. Analyzer can be run directly from Visualizer and for normal interactive use Visualizer will be the primary interface to InfoSecter.

There are five main areas in the Visualizer display

When two configurations are compared, there are two Config Inspectors and two Symbol Viewers, one pair for each configuration.

The Config Inspector and Symbol Viewer are dockable widgets. Such widgets can be undocked and moved
separately on the screen. The docking and undocking is performed by using your mouse to select and move the subwindow. Alternatively each dockable subwindow has a triangular icon in the upper right corner will undock and redock the window.

Not all areas will appear in all cases. Areas that are not useful for a particular result file are hidden.

Visualizer also has the Analysis Dialog which is a very complex widget in its own right and is used to configure a run of Analyzer.

Click on a link above for further detail on any of these components, or look below for an overview of Visualizer's main window.

Operations

The primary operations of Visualizer are in the File menu. These are

OperationUse
New AnalysisOpen the Analysis Dialog to run Analyzer and view the result.
View AnalysisView an already performed analysis by opening a file containing the results.
Save Results AsSave the current results in to a file for later viewing or use by another applicaiton.
QuitExit Visualizer

The View menu has options for viewing or not viewing the Config Inspectors and Symbols Viewers. Each can be shown or hidden independently, although showing the second pair if only one configuration is in the analysis results isn't very useful. The common use of this menu is to show one of the options after it has been closed (on purpose or accidently).

The Help menu has three operations.

OperationUse
ContentsView the InfoSecter documentation contents (including this file)
AboutDisplay information about Visualizer and InfoSecter.
LicenseOpen the License Viewer.

Visualizer Main Window Overview

Here is an example of the main window of Visualizer.

The same image, with the components labeled.

The Symbol Viewer as an undocked window.

2.1 Main Grid

When a configuration is analyzed, a set of behavior slices is generated which describe the interesting behavior found by the analysis. The Main Grid is where those slices are displayed. Each row is one slice. Each column is a specific property of the slice. The properties displayed depend on the type of analysis done. Here is a complete list of all possible properties that may be displayed in the Main Grid.

Column Operations

Each column can be sorted in ascending or descending order by left-clicking on the column header. The currently sorted column displays an arrow head in the header.

The columns can be widened or narrowed by dragging the dividing lines between the column headers left or right. The columns can be arranged by clicking and dragging a column header.

The main grid can have multiple tabs if multiple expressions are used for policy validation. Each expression that generates results has its own set of slices which are displayed in different tabs.

2.2 Filter and Query Tabs

The filter and query tabs are a tabbed display for packet expressions. The "Filter" tab displays the current filter expression. The "Query" tab displays the current query expression, if any. This tab will be available only when the result file was generated by a query or constraint analysis.

The Query tab is non-editable.

The Filter tab is not directly editable, but it can be changed to apply a filter to the Main Grid.

2.2.1 Filter Expressions

Filtering is a key feature of Visualizer. It is what lets you rapidly locate important information in the configuration. The essense is that you provide a specification for which slices are of interest, and then the Main Grid displays only slices that match the specification. The specification takes the form of a filter expression. The filter expression specifies the desired values of the columns for a slice and the Main Grid hides all slices that do not match. The remaining slices are those of interest.

Basics

Filtering is done by creating a filter expression and then applying it to the Main Grid. A filter expression is built out of predicates. A predicate is a column name, a comparison operator, and a value. For a particular slice, a predicate is true if the value in the slice for the named column compares correctly with the value in the predicate. The manner in which the value from the slice and the value in the predicate are compared is controlled by the comparison operator in the predicate.

Let's look at a few examples.

Consider this predicate

Destination Address ^ 192.168.56.0/24

The column name is "Destination Address" and the value is "192.168.56.0/24". The '^' character is the intersection operator. It is true if any destination address in the slice is the same as any address in the 192.168.56.0/24 network. If, instead of the destination address of the packets in the slice, we were concerned with the source address, we could use this predicate --

Source Address ^ 192.168.56.0/24

This is same as before except the source addresses in the slices are compared against the 192.168.56.0/24 network. When thinking of predicates, think of the column name as a stand in for the value in the slice, which is compared to the predicate value.

Every named column except "Index" can be used in a predicate. Each column has a specific type of value and the value in the predicate must be of that type. For instance, "Destination Address" must have a range of IP addresses, and "Scope" must have a list of scopes.

The full set of comparison operators is

NameComparison
^IntersetTrue if any value in the predicate is the same as any value in the slice.
-<Contained byTrue if every value in the slice is also in the predicate value. I.e., the slice values is entirely contained by (is a subset of) the predicate value.
>-ContainsTrue if every value in the predicate value is also in the slice. I.e., the slice value entirely contains (is a superset of) the predicate value.
=EqualTrue if the predicate value and the slice value are identical.
<Less thanTrue if the slice value is less than the predicate value.
<=Less than or equalTrue if the slice value is less than or equal to the predicate value.
>Greater thanTrue if the slice value is greater than the predicate value.
>=Greater than or equalTrue if the slice is greater than or equal to the predicate value.

Not every column supports every comparison operator. For instance, it makes no sense to check if one range of IP address is greater than another.

Combining predicates

Predicates are useful by themselves, but they are even more useful as building blocks to more complex filter expressions. Predicates can be combined using three binary operators.

 NameMeaning
|OrTrue if either or both sides is true.
&AndTrue only if both sides are true.
*OtherwiseOnly used in Querent, listed here for completeness because it may be displayed in the Query tab.

A binary operator can combine two predicates or it can combine the result another binary operator and a predicate, or two results, so that predicates can be chained together by binary operators.

For example,

Source Address ^ 10.10.0.0/16 | Source Address ^ 172.16.24.0/24 & Destination Service ^ TCP::HTTP

The "or" operator combines the predicates on "Source Address" and is true if the source addresses in the slice intersect the 10.10.0.0/16 network or the 172.16.24/24 network. The "and" operator is true if the "or" was true and the destination service range for the slice contains TCP port 80 (HTTP). Binary operators in a sequence operate in order from left to right. This can be changed by using parentheses. Binary operators cannot reach inside parentheses so any operators inside parentheses operate before those outside.

For example, this filter expression is the same as the previous despite the change in ordering because the parentheses force the source address comparisons before the destination service.

Destination Service ^ TCP::HTTP & ( Source Address ^10.10.0.0/16 | Source Address ^ 172.16.24.0/24 )

Without the parentheses the "and" operator would go first which is probably not what was desired. Parentheses can be used inside other parentheses providing complete control over the order of operation of binary operators. A pair of matched parentheses and its contents are referred to as a "sub-expression".

Negation

A filter expression can be negated by placing a '!' character in front of it.

! Actions >- permit

The predicate here is true if the actions for a slice include the "permit" action. The '!' negates that, turning true in to false and false in to true. As a result this filter expression is true if and only if the slice actions do not contain the "permit" action. Negation can be applied to either a predicate or a sub-expression. Negation only affects what is immediately after the '!' character, which is either a predicate or a sub-expression.

For example, going back we could have the filter expression

Destination Service ^ TCP::HTTP & ! ( Source Address ^ 10.10.0.0/16 | Source Address ^ 172.16.24.0/24 )

This is true if the destination service in the slice contains the HTTP port and the source address does not contain any address from the 10.10.0.0/16 network nor the 172.16.24.0/8 network. Without the parentheses the negation would affect only the predicate with the 10.10.0.0/16 network.

2.2.2 Editing Filters

There are two ways to create filter expressions in Visualizer. One is to use the context menu on cells in the Main Grid, the other is to type the expression in the filter edit box.

Creating filters from cell data

The simplest way to create a filter expression is to right click on a cell in the Main Grid. This will pop up a menu with an "Add Filter" item. Under that item are various predicates which can be added to the current filter expression based. All of them use the value in the cell as the predicate value and current column. They vary only in the comparison operator and whether the predicate is negated.

For example, given a slice with the destination address of 10.12.0.0/16, to display only slices that affect traffic going to same network you would right-click on the cell in the row for the slice in the 'Destination Address" column. Then under "Add Filter" select "Intersects".

The filter display is updated to have that predicate.

If you are not editing the filter, then the result is immediately applied and the main grid is updated. If the filter edit box is active, then the predicate is added to the text in the box but not applied.

You can add additional filters for other columns. The predicates are connected by the "and" binary operator so that the displayed slices must match all the predicates. For example, suppose you wanted to exclude slices with the "deny" action. Right click on a cell with "deny" and select the "does not contain" predicate.

This changes the filter expression and applies it to the main grid.

You can remove predicates by right clicking on a column and use the "Remove Filter" item. This can have several items in it. The "All Filters" item always appears and will erase the entire filter expression and stop filtering. The "Column Filters" will remove all predicates that refer to the column. If there are any such predicates, they will be listed in the menu and can be removed individually.

Note that none of the actions contain "deny" because we have filtered those out.

Direct editing

In addition to using filters generated from slice data, the filter expression can be edited directly via the "Edit Filter" button to the right of the filter tab. Pressing the button opens up a small edit panel and several other buttons.

ButtonAction
ApplyIf the edit box contains a valid filter expression, it replaces the current filter expression and is used to filter the main grid.
ResetErases the edit box then copies the current filter expression to it. This "resets" the expression being edited to the current expression.
Close EditorClose the edit box. The current contents are left as is.

The edit box uses the Guided Editor to provide hints as you type. You can also use a right click on a cell to add a predicate to the edit box. This just puts the text for the column filter at the end of the current edit box contents. It is not guaranteed to create a valid filter expression.

2.3 Conflict Inspector

The Conflict Inspector shows the details of the conflict slice selected in the Main Grid. The display has three sections

  1. Column headers, which label the data in the column
  2. The conflict row, which duplicates the data of the slice from the Main Grid.
  3. The contributor rows, which contain slices from the configuration that contribute to the conflict.

The meaning of the column labels are the same as in the main grid columns.

The conflict row is always greyed out and cannot be selected. It is displayed for reference because it describes the actual behavior of the security device. The conflict rows are slices that describe the behavior of the contributing configurations rules. Note that even if the behavior of a contributing slice is the same as the conflict slice, the packet properties of the slice may be different. The conflict slice covers only packets that are in conflict which may not be all of any of the contributing slices.

If a conflict row is selected then the Config Inspector highlights the lines in the configuration that contribute to that slice. You can then easily find the reason why the contributing slice has the properties it does.

2.4 Config Inspector

Config Inspector is a widget that displays a configuration used by Analyzer to create the analysis.

There are a number of different elements in the display.

The title of the widget is the path to the configuration file used for the analysis.

The toolbar contains buttons to help in browsing the configuration. On the left are the next highlight and previous highlight buttons. When a slice with source lines is selected (either in the Main Grid or the Conflict Inspector) the sources lines are highlighted in the appropriate Config Inspector to aid in locating those lines. You can scroll down in the configuration to find them or use the next and previous highlight buttons to scroll the configuration to the next or previous set of highlighted lines. They are enabled or disabled automatically based on whether there is, relative to the current line, a next or previous highlighted line.

Like a web browser, Config Inspector maintains a stack of what lines you have visited in the
configuration. You can use the previous line and next line buttons in the toolbar to step through the configuration viewing history. These are also enabled and disabled automatically as previous and next lines in the history are available.

Config Inspector displays definitions and references within the configuration as hypertext links. A reference to a named item (e.g., an object-group in PIX) defined in the configuration is displayed as a link. Hovering over the link will cause a tip window will pop up and show the values of the definition. Left clicking on link will change the current line to the item's definition in the configuration file.

Right clicking a marked name will bring up a context menu.

The "View" option will scroll to the name in the Symbol Viewer, opening the viewer if it is not already visible. The "Goto" submenu lists all lines on which the name is used. Selecting one of these items will scroll to that line in the configuration.

Moving around in the configuration can be done using standard text document navigation keys. In addition you can go directly to a line by number or using incremental searching to locate lines.

Go directly to a line by line number by pressing Control-G.

The text "Goto Line:" will appear after the current line number indicator. As you type numbers they will appear after this text. Pressing ENTER or RETURN will scroll to the line number entered. ESCAPE or clicking on a line will cancel. Note that blank lines are not displayed. If the entered line number is a blank line, the current line will be set to the last non-blank line before that line.

You can search for a particular string in configuration by typing
Control-F or Control-I for a search forward from the current line, or Control-Shift-F or Control-Shift-I for a search backwards from the current line. The text "Search:" or "Reverse search": will appear for forward and backwards searchs respectively. Type in the text you want to find. As you type, the configuration will be searched and will scroll to the first line relative to the current line where the current search text is found.

Press ENTER or RETURN to skip to the next line with the text, or type additional text. Press ESCAPE or click a line to stop searching. If the text turns red, it means that the search string was not found. Use browsing history to go back to a previous line if the search does not leave you where you want to be.

2.5 Symbol Viewer

Symbol Viewer is a docking window in Visualizer that displays the symbols defined in a configuration.

The left column lists all of the defined symbols. The right column contains the definition of the symbol. If a symbol is defined in terms of another symbol, that symbol and its definition are included as children of the first symbol. This puts the entire definition of each symbol in a single location for viewing.

In this case, symbol "ng1" is defined in terms of "ng2" which in turn uses "whoville" as part of its definition. The symbol "ng1" has been selected to show its direct definition and the nested entries for "ng2" and "whoville" expanded. An unexpanded entry for "ng2" at the top level can be seen directly below.

The symbol viewer can be shown and hidden using Control-1 (Symbol Viewer for the first configuration) or Control-2 (for the second configuration) in the Visualizer, for the first and second configurations respectively. Symbol Viewer can be accessed from "View" item in the Config Inspector context menu. Selecting the "View" option will cause the corresponding Symbol Viewer to be displayed if it is not already and the selected symbol highlighted.

2.6 Analysis Dialog

The Analysis Dialog is the primary graphical user interface for Analyzer. It encapsulates the options available for performing an analysis. The dialog is accessed by select the "File | New Analysis" menu option in Visualizer.

When using the dialog, first pick the type of analysis to perform in the "Type of Analysis" group box.

Some types of analysis may be computed for each network interface independently, or over traffic that traverses a pair of interfaces. If this choice matters for the type of analysis the "Cross Interface" check box will be enabled. If checked, traffic is analyzed per pair of interfaces. If not checked, traffic is analyzed for each interface independently. If it is greyed out, it doesn't matter if it is checked or not. This option is primarily of interest to Cisco devices.

The "File 1" group box is always enabled. If the analysis requires two configuration files, the "File 2" group box will be enabled.

Each file group box contains a "Path" drop down list. This specificies the file system location of the configuration file. The drop down contains a history of recently analyzed files. You can type in the path directly or use the "Browse" button to locate the file via a file dialog.

The "Family" drop down box is used to specify the family of devices for which the configuration is used. Not all configuration files can have their type automatically detected so it is important to set this option correctly. The particular verions of the device for the configuraiton can be set in the "Version" box. If the "Autodetect" checkbox is checked Analyzer will attempt to determine the version from the contents of the configuration. If it is not checked, a version must be entered in the "Version" box.

These controls are the same for "File 1" and "File 2" except that "File 2" has an additional checkbox labeled "Different". If this is not checked, then the family, version, and Autodetect options are set to be the same as for "File 1" and cannot be changed. If checked, then they can be changed to be different from "File 1".

The analysis results can be placed in a temporary file for Visualizer or placed in a file you select. To do the latter, check the "Save" check box and put the path to the desired file in the "Path" drop down. As with the configuration file paths, the drop down is a history of files recently used to store analysis results. The "Browse" button allows you to browse the file system with a file dialog to select the file.

3 InfoSecter Querent

In order to process constraints against a firewall configuration, the Analyzer needs a query document which specifies the constraints. This is an XML file which can be edited in any text editor. Querent is an application that creates and edits query documents to make using constraints easier and more reliable.

Each query document has a set of policy expressions. A policy expression is a set of properties for a network packet. Such expressions can be used to perform Policy Validation by verifying that packets with those properties are (or are not) in the behavior of a firewall configuration. The packet properties in an expression can be addresses, services, and actions. For instance, packets that come from a specific network to another network using the HTTP protocol that are permitted.

The packet properties in an expression can be specified directly, or via macros. A macro is a name with an associated value that can be used in place of that value. This is useful to make sure that all uses of a particular value are identical, to make the expression more comprehensible (e.g., "Engineering Networks" instead of "10.34.68.0/25"), or to make it easy to change a value in multiple expressions. The association of values with macros is stored in a dictionary. Each query document has a single set of macros but an arbitrary number of dictionaries. The dictionary used during analysis is specified as a command line argument to Analyzer.

There are three tabs in the Querent window.

To start, you will need to create or open a query file. Go to the File menu and select "New" or "Open". From the File menu you can also save the results of your query editing.

3.1 Expressions

The main expression tab shows a list of currently defined expressions. The tool bar contains a number of icons that represent actions to perform on these expressions.

Using Expressions

To perform Policy Validation, select the Expressions tab. From that tab, select the set of expressions you want to use as constraints against a configuration. Then click the screw driver and wrench. A dialog box will appear.

Enter the path to the file containing the configuration, or use the "Browse" button to browse the file system and select the file. Set the device family in the "Family" drop down. You must set the proper version in the "Version" area or enable "Autodetect" which will attempt to determine the version automatically. This may not work for some versions for some families.

The resuls will be put in to a temporary file, or you can have them saved to a specific file by entering the path to the file in the "Path" area of the "Results" groupbox and checking the "Save to" checkbox directly below.

The "Options" groupbox lets you set the dictionary to use (if there is more than one) with the "Dictionary" dropdown, and whether to look at traffic for each interface independently (disable the "Cross Interface" checkbox) or for pairs of interfaces (enable the "Cross Interface" checkbox). See Cross Interface for more details on this.

Once you have selected all the parameters, press the "Analyze" button to start the Analyzer. This will pop up a status window.

The overall status is displayed in the first line. You can access the details of the Analyzer's output by pressing the button next to "Process Output", or press to hide them. In the same way uou can also access the details of the command line used to invoke Analyzer by pressing the button next to "Command Line". In the screen shot above, the process details are displayed and the command line options are not. The state of these buttons is remembered so that showing the process details will do so in subsequent analyses until changed.

Once the analysis has successfully completed, you can press a "View Results" button will appear. If you press it, the status pop up will close and new instance of Visualizer will start and display the results. The constraint expression is displayed between the top conflict grid and the bottom configuration display. The conflict grid shows all packet regions expressed by the configuration that do not match the constraint expression. Each expression used will get a separate tab for its specific results.

Because you can view the command line options, using Querent can be a handy way to set up for using Analyzer in a script.

3.1.1 Structured Editor

The expression editor displays the expression in terms of clauses. A clause is a set of fields with values specified. All the fields and values within a clause will be combined by the and operator in the final expression. For example, a clause with "Source Address" set to 192.168.1.1 and "Action" set to permit will match only packets with a source address of 192.168.1.1 that the configuration will permit. If a field value is not set, it is ignored and does not contribute to the expression.

Icons on the top editor tool bar perform a number of basic operations.

Editing Clauses

To set values in a clause, click on a field name. This will activate the associated value entry field to the right of the field name. Start typing in the value entry area. The Guided Editor will give you hints for proper values in hint popup windows. You can continue typing or select a hint from the popup window. See Guided Editor for more details on the editing mechanism. After completing a value, hit return. For most fields, you can enter multiple values. These values will be interpreted as alternates. For example, if you enter 192.168.1.0/24 and 10.10.10.128 for the Destination Address field, the expression evaluation will interpret this as the Destination Address matches the network 192.168.1.0/24 or the host 10.10.10.128.

To edit an existing value, double-click the value and start editting. To delete a value, select the value, and hit delete key.

Each field and value pair is separated by an equal sign . You can click on the equal sign to toggle it to the equal sign. This effects how the field value pair is interpreted during the expression evaluation. In our example of the Destination Address field with values 192.168.1.0/24 and 10.10.10.128, if there is an equal sign, the expression will be interpreted as the Destination Address matches the network 192.168.1.0/24 or the host 10.10.10.128. If a not equal sign is shown, the expression will be evaluated as the Destination Address is not in the network 192.168.1.0/24 and it does not equal the host 10.10.10.128.

Each clause has a tool bar with three buttons.

Composing Clauses

An expression is composed of multiple clauses. The expression editor shows how clauses are combined through indentation and operators. If two clauses are at the same indentation level, they are connected by a line with the green plus circle the or operator. When evaluated, the first clause will be evaluated to find matching packets and actions. Then the second clause will be evaluated to find matching packets and actions. The resulting expression is the union of the packets and actions described in each clause.

If one clause is a child of another clause (that is the second clause is indented underneath the first clause), the results of the clauses are combined with the and operator. Effectively the outer clause is checked and if it matches, the inner clauses are checked. If the outer clause doesn't match, the inner clauses are not checked at all.

Clauses at the same level ("sibling clauses") are combined with the or operator, which means that they are all checked until one matches if all parent clauses match. If there are clauses nested under the siblings, those are checked only if their parent (one of the siblings) matches.

The expression as a whole matches if any clause without nested clauses matches. A parent clause (one with nested clauses) matches if any of its nested clauses match.

Controlling Clause Nesting

In the expression editor tool bar, there is a set of four arrow buttons.

In addition to combining clauses through and and or operators, there is also an otherwise operator. The otherwise operator can be used on the last clause in a list of clauses at the same identiation level; that is a set of clauses combined by the or operator. The clause after the otherwise operator expresses the action or scope that must apply to the packet that does not match any of the previous clauses. For example, consider one clause that specified the Source Address was 10.10.0.0/16 and the Action was permit, and after the otherwise operator another clause that specified the action of deny. This would mean that only packets with the source address in the 10.10.0.0/16 network should be permitted and all other packets should be denied. The otherwise operator provides a concise means of expressing the expected action in all "other" cases.

The last clause in a list can be converted between an or clause and an otherwise clause by toggling the icon next to the close. If it is blue plus circle or green plus circle the final clause is another or clause. If it is blue x circle or green x circle the final clause is an otherwise clause. If the operator is red

it means that the clause has an otherwise operator and was moved to a location where such an operator is not permitted. In this case it will be treated as an or. If the clause is moved to a location where otherwise is valid the operator will change back to green. You can change the operator to or but you can't change it back unless the operator is moved to a location where otherwise is valid. This is done so that the otherwise operator is not changed while a clause is being moved.

If it's still not clear what operator a clause has, hover the mouse cursor over the operator and it will provide a tool tip.

3.2 Macros

The Macros tab shows a table of the currently defined macros. Icons in the tool bar control the macros.

To edit any field in the table, double-click and edit. The type is one of IP Address, IP Service, IP Protocol, Action, or Scope. The structured editor uses the type information to determine what macros can be used in which fields. The Dictionaries editor also uses the type information to ensure that correct values are entered in the dictionary.

Macros can be used as values in the structured editor. To distinguish between a macro and a string, all macro references must start with the '$' character.

For example, say you created a macro of type IP Address named "LabServers". In the expression editor, you could enter "$LabServers" for the value of the Destination Address if you wanted to compose an expression testing how traffic to the Lab Servers was being processed. Note that the structured editor checks the macro types and does not permit macros of the wrong type to be used (e.g., if you are editing a Scope value, you will not have access to "$LabServers" because it is not a Scope).

3.3 Dictionaries

Dictionary tab is split into two sides. The left hand side shows a list of the currently defined dictionaries. One dictonary is the active dictionary. The values in that dictionary are displayed in the right hand side of the the table.

Icons in the tool bar control the dictionaries.

The values of the dictionary selected in the dictionary list are displayed in the right hand side of the tab. These values are available for edit. If no macros are displayed, toggle the display button in the tool bar from a green square to a striped square.

4 InfoSecter Analyzer

Generally InfoSecter Analyzer will be invoked via the Visualizer or Querent. However, Analyzer can also be invoked directly or invoked from scripts. A summary of Analyzer's command line options is shown below.

Syntax

USAGE: Analyzer <cfg1> [-o <cfg2>] [-V <version string>] 
[-V2 <version string>] [-D <base directory>]
[-R <family registration file>]
[-R2 <family2 registration file>]
[-x]
[-t]
(-c <expression file> [<expression name> [<dictionary name>]])* 
(-q <expression file> [<expression name> [<dictionary name>]])*
(-C <expression cst file>)*
(-Q <expression cst file>)*
[-f <outfile>]

Examples

To compute a Self Conflict operation on PIX configuration pix1.cfg, use the following command line. 

analyzer pix1.cfg -D /infosecter -R /infosecter/lib/pix-reg.plat -f out.xml

To compute a Cross Conflict operation on PIX configurations pix1.cfg and pix2.cfg, use the following command line. 

analyzer pix1.cfg -o pix2.cfg 
-D /infosecter -R /infosecter/lib/pix-reg.plat -f out.xml

To compute Dissection with Cross Interface calcuations on PIX configuration pix1.cfg, use the following command line. 

analyzer pix1.cfg -t -x -D /infosecter -R /infosecter/lib/pix-reg.plat -f out.xml

To compute a Cross Conflict operation on PIX configuration pix1.cfg and FWSM configuration fwsm1.cfg use the following command line. 

analyzer pix1.cfg -o fwsm1.cfg 
-D /infosecter -R /infosecter/lib/pix-reg.plat 
-R2 /infosecter/lib/fwsm-reg.plat
-f out.xml

To compute a Constraint Policy Validation operation on a NetScreen configuration ns-comp.cfg and an expression named "test" stored in file constrain.query use the following command line. 

analyzer ns-comp.cfg -D /infosecter -R /infosecter/lib/ns-reg.plat
-c constrain.query test -f out.xml

5 InfoSecter Device Support

InfoSecter operates on configurations from a variety of security device vendors. Rather that communicating with the security devices directly most of the InfoSecter tools work on files that contain information about a device's configuration (either the current configuration, a past configuration, or a potential future configuration). Many organizations already have a process for managing device configurations, and InfoSecter can adapt to those processes. In the detailed device notes, we present options for accessing a device's configuration for organizations that do not already have a configuration management process.

The configuration of a security device is sensitive information. With the details of a security device's configuration, an attacker knows exactly what your organization is protecting and what it is not. The attacker can also gain insight in how your network is structured. Therefore, when using InfoSecter, you must be careful about how your device configuration files are stored. For example, they should not be stored in a shared directory accessible to all.

InfoSecter attempts to parse all commands in a configuration (with some expections noted in the detailed machine notes). It builds a model of packet processing concentrating on the firewall, IPSec, and protocol analysis features of the device.

Here are more specific notes about using InfoSecter with specific types of devices.

5.1 InfoSecter Support Notes for PIX, ASA, and FWSM

Supported versions

The analysis support concentrates on firewall and VPN features. In particular InfoSecter reports may include the following classes of actions.

The tool will parse most of the the commands in the supported versions with the following exceptions.

Gather device configurations

InfoSecter operates on configuration files. There are several means to export a configuration from a PIX or ASA device. One uses the ASDM https interface to pull a config from a PIX/ASA to a client machine. Another technique pushes a config from a PIX/ASA to a client machine.

Pulling a configuration

From a client machine, use https to pull the running config or the start up config from the ASA/PIX. To enable this, the device must be configured to allow ASDM access as described in the Cisco Documentation (short of installing the ASDM image). The device must have a certificate installed using the crypto key generate rsa command. The embedded web server must be enabled on the device using the http enable command, and the http command must be used to give access to the requesting client.

Once the device is configured to allow https access, you can use a browser on the client machine to fetch the URL. Say the PIX/ASA device is at address 192.168.1.1, the URL would be 

    https://192.168.1.1/exec/show run

You will be prompted for a user name and password. If you have AAA authentication enabled or local users defined, use one of the defined user names and passwords. Otherwise, use "pix" for the username and your enable password for the password.

Pushing a configuration

From the ASA/PIX device you can use the copy command to copy the start up or running config to an accessible machine via a variety of protocols (including tftp, ftp, scp, rcp, http, and https). The Cisco Documentation describes this technique for backing up configurations in greater detail.

For example, if there is a machine with the address 192.168.200.2 running a FTP server with an account for user, you can issue the following command to copy the running config to the ftp server. 

    copy running-config ftp://user:password@192.168.200.2/run.cfg

5.2 InfoSecter Support Notes for IOS

Supported versions

InfoSecter has been tested on configurations from versions 12.3 and 12.4.

The InfoSecter analysis support concentrates on firewall and IPSec features. In particular InfoSecter reports may include the following classes of actions.

The IOS command set is vast. InfoSecter parses firewall feature set commands and core IOS commands. It does not parse the entire IOS command set. InfoSecter analysis will continue over the information from the parsed commands.

Gathering device configurations

Secure copy (copy over the SSH protocol) can be used to pull configurations from the IOS device to a client machine. To enable such access, the IOS device must be configured to allow SSH access and then to enable scp access. The Cisco documentation on SSH and scp cover this in detail.

To enable ssh access to the device, you must use the crypto key generate rsa command to create a named key pair for use with the SSH server on the device. To enable secure copy access from a client to the IOS device use the ip scp server enable command.

Once the device is configured to allow scp access, you can use your favorite secure copy program (e.g. scp from OpenSSH or pscp from PuTTY). For example, using OpenSSH's scp, the following command will pull the running config from an IOS device with the address 192.168.1.1 and store it locally in the file backup.cfg. 

    scp admin@192.168.1.1:running-config backup.cfg

This example assumes there is a user named admin either defined on the IOS device or defined in a AAA server that the IOS device uses for authentication and authorization.

5.3 InfoSecter Support for NetScreen

Supported Versions

InfoSecter has been tested against versions 5.1 through 5.4 of ScreenOS.

The InfoSecter analysis support concentrates on firewall and VPN features. In particular InfoSecter reports may include the following classes of actions.

InfoSecter attempts to parse all commands that can show up in a Netscreen configuration file (output of get config). The features most directly related with firewall filtering and IPSec tunneling have been most deeply tested. If a command fails to parse, the information from the remainder of the configuration that has been parsed will be used in the analysis.

Gather device configurations

InfoSecter operates on configuration files. There are several means to export a configuration from a Netscreen device. One can use secure copy to pull a configuration from the Netscreen device to a client machine. Another technique pushes a configuration file from a Netscreen Device to a client machine. One can also use the Netscreen Security Manager to create CLI versions of the current policy and feed that information to InfoSecter for analysis.

Pulling a configuration

Secure copy (copy over SSH) can be used to pull the configuration saved in non volatile RAM from the Netscreen device to the client machine.

To enable ssh and scp to your netscreen box, you need the following commands

On the client device, use a secure copy client (e.g. scp from OpenSSH or pscp from PuTTY) to move files between your client host and the firewall devices' flash memory.

The name of the devices' startup config on its flash drive is ns_sys_config, so to copy that startup config from the firewall device to backup.cfg on your client, issue the following command (assuming the default administrative user netscreen on the firewall device). 

scp netscreen@192.168.50.50:ns_sys_config ns_sys_config_backup

With Netscreen you can either use a password for the client, or you can register a certificate with the device for the client authentication. The Concepts & Examples Reference Guide: Volume 3, Administration document from Netscreen provides the details for setting up ssh, scp, and the authentication options.

Pushing a configuration

From the Netscreen device you can use the "exec save" command to copy the start up configuration to an accessible machine via tftp.

For example, if there is a machine with the address 192.168.200.2 running a tftp server, you can issue the command exec save config from flash to tftp 192.168.200.2 /tftpboot/backup.cfg to copy the starup config to the tftp server.

5.4 InfoSecter Support Notes for CheckPoint

Supported versions

InfoSecter has been tested against CheckPoint NGX R65.

The analysis support concentrates on firewall and IPSec features. In particular InfoSecter reports may include the following classes of actions.

Gather device configurations

InfoSecter's analysis operates over a snapshot of the Check Point operational policy with respect to a particular firewall device. The Check Point Smart Center may contain firewall policies that are applied to multiple physical enforcing devices.

InfoSecter includes a program to pull a snapshot of the current configuration for a particular firewall device from the SmartCenter policy database. This tool uses the OPSEC CPMI interface to read information from the database. This tool does not write interface to the database, so there is no threat of corrupting the policy database while pulling a configuration snapshot. The configuration snapshot is stored in an XML file, which can then be used by the InfoSecter Executer engine.

Initializing communication

Check Point enforces an authenticated encrypted channel called Secure Internal Communications (SIC) for all communication between its components, so the InfoSecter tools must be initialized before they are allowed access to the policy database. This initizalization requires actions on the firewall device, in the SmartDashboard GUI, and from the InfoSecter client machine.

On the Smart Center Server

To initialize the SIC key, you must log onto your SmartCenter Server (most likely co-located with your firewall machine), and enter the command fw putkey -opsec -ssl <InfoSecter address> This command will prompt you for an authentication key. Pick a phrase and remember it for use on the InfoSecter machine.

On SmartDashboard

Log into SmartDashboard to create a representation of InfoSecter as an OPSec client. This will create a certificate which InfoSecter will use for proof of identify for future communication.

  1. Create a host node for the InfoSecter client machine if it is not already represented in the SmartDashboard database.
  2. Go to the Manage menu and select the OPSEC Applications entry. This will pop up a dialog box. Click the New button to create a representation of your installation of the InfoSecter application. This will drop down a list of types of applications you can create. Select OPSEC Application.... This will pop up a new dialog box.
    1. In the new dialog box, enter a name for the application, e.g. InfoSecter or InfoSecter_on_hostX.
    2. For Host select the host object representing your InfoSecter machine
    3. Under Client Entities click the check box next to the CPMI protocol. This is the OPSEC protocol used by InfoSecter.
    4. Click on the Communication... button. This will open another dialog box that prompts you for an Activation Key. Pick a phrase (this does not need to be the same phrase you selected on the SmartCenter), enter it twice, and click the Intialize button.
    5. Back at the OPSEC Application Properties dialog box, there is now a CPMI Permissions tab. Select that tab. Change the login creditials from the "Administrator's Credentials" to a Permissions Profile. You may need to create a new profile. This profile must provide read and write access to the Security Policy database even those InfoSecter only reads the Security Policy database.

On the InfoSecter machine

Finally, on the InfoSecter machine you can run the infosecter-checkpoint-setup.exe to complete the SIC and certification initializations you started on the firewall and in SmartDashboard. This program is located under the bin/cp directory of the InfoSecter install directory.

infosecter-checkpoint-setup.exe will display a simple dialog box composed of two parts. The top part completes the SIC initialization you started at the firewall console. In the text field labeled Smart Center Server enter the address or resolvable name for the Smart Center Server. In the text field labeled Secret Phrase enter the authentication key you entered on the Smart Center Server.

With both of these values entered, press the Initialize button. Status information will be displayed in a box under the Intialize button.

If the first step was successful, look at the bottom part of the dialog box to complete the communication initialization between InfoSecter and SmartDashboard. In the field labeled Application Name enter the name you selected for the installed InfoSecter application in SmartDashboard. In the field labeled Secret Phrase enter the activation key you created when initializating communication in SmartDashboard for the InfoSecter application. Press the pull button to pull the application certificate keys created by SmartDashboard. Status information about this step will be displayed in a text box under the pull button.

Pulling a snapshot

Assuming the initialization sequence was successful, you can use the infosecter-checkpoint-retrieve.exe application (also located in bin/cp subdirectory of the InfoSecter install directory) to get a snapshot of the current policy for your Check Point firewall.

This application will display a dialog box. In the field labeled Smart Center Server enter the address or resolvable name of the Smart Center machine. In the field labeled CheckPoint Firewall enter the name of the firewall for which you want the policy. In the field labeled Application Name enter the name you used in definition of the InfoSecter application installation in SmartDashboard. In the text field labeled Save in File enter the name of the XML file where you want the snapshot stored. You may use the Browse button to aid in selecting a file. In the text field labeled Debug Level, you can enter a number from 0 to 9 to display increasing amounts of debug information. If the connection is not working, the debug messages may give you some hints to the problem.

Once the fields are entered, hit the Retrieve button to start the snapshot process. The window below the buttons will show status and debug messages about the snapshot process. If the snapshot is successful, the file you indentified in the Save in File field will contain information about the current configuration of the identified firewall that can be used by InfoSecter for analysis. This file may be selected in the Visualizer or Querent for analysis.

6 Reference

These are reference guides for various elements of InfoSecter that are referred to from other parts of the documentation or serve as ancillary functionality to the main product.

6.1 Guided Editor

The Guided Editor is a text editor that provides specialized help for entering information in InfoSecter. It acts as a normal text editor except that it can provide context sensitive hints to make entering information faster and easier. See here for a reference of available keystrokes.

Guided Editor Basics

When hints are available, a small popup box will appear a little below and to the right of the text cursor as show in the picture. Here the Guided Editor is being used to enter an IP address range for a field in Querent. The user has typed in "192.168.10.0". The green is part of a color code and indicates the input is valid. While a single address is acceptable as a range, you can specify a larger range by entering a network specification, either a CIDR bit count mask or an octet mask, or '-' character and another IP address. The hint box shows all of these to indicate that while the current input is sufficient, you can type more.

Hints can be treated simply as hints and all data entered directly. You can click on a hint in which case the text is added to the input. Hints can be selected by using the UP and DOWN arrow keys and then used by typing Control-Space. For common used values (such as the class C network mask) this can be much faster and more accurate than typing it by hand.

In this case, for the octet mask, several hints are provided. These are, in order, the mask for the widest network possible for the IP address, the class C network for the address, and the host mask. The class A and class B network masks are not offered as hints because they are invalid for this address. These values are a "best guess" as to the most commonly used masks. If none are correct, you can simply enter the mask directly.

Hints are also provided if part of the data is entered. In this image the yellow means that the input is not correct but could be correct with additional text. The hints in this case are the smallest and largest possible IP addresses consistent with the part of the address already present. Again, these are the common cases and if not correct can be ignored.

What if you make a mistake? In most cases the Guided Editor will catch this and let you know what's wrong. Here the background has been set to red to indicate bad input and the hint explains the problem ("257" is too large a value for a single octect in an IP address). When the input is bad, using the hint will erase the bad input but not replace it. It is usually easier to use BACKSPACE to back up and correct the error.

Some of the names used in InfoSecter can be long. While this makes the display more understandable it can also take extra effort to type. The Guided Editor makes this easier to enter by automatically selecting a hint if that is the only hint. Only enough of a name to be unique must be typed in order to have a hint with the complete name selected. In addition the Guided Editor has additional help for names with spaces in them. For such a name, each space seperated word is checked independently across spaces in the input. For this reason you only need to match enough initial characters of each word to match the correct name.

For example, in Visualizer, the column names contain spaces. Two such column names are "Destination Address" and "Destination Service". Typing just the letter 'd' brings up two hints, one for each column name.

If you type "d a", then the 'd' will match "Destination" in both column names, but the 'a' will be matched against the second words, "Service" and "Address". Since only "Address" starts with 'a', it will be the only hint and become selected.

Typing CONTROL-Space at that point will cause the "d a" you entered to be changed to "Destination Address". This also works with actions and scopes that contain spaces. You can also see that the hints have changed to comparison operators appropriate for values for the Destination Address column.

The Guided Editor is case insensitive -- it doesn't matter if you type "d a" or "D a" or "d A". This example also demonstrates typing additional characters for the first and second word in "Destination Address" still matches, despite the odd mixture of upper and lower case letters.

Color Code

Color is used with the Guided Editor to indicate the validity of the current input, although the exact manner varies. The color code is the same in all cases.

ColorMeaning
GreenInput is correct.
YellowInput is not correct, but could become correct with additional input.
RedInput is wrong. No amount of additional input could make it correct. The current input must be changed.

Using the Guided Editor in Querent

Querent used the Guided Editor to edit values for clauses and dictionary values. Querent changes the background of the value field to indicate the acceptability of the input according to the color code.

Using the Guided Editor in Visualizer

Visualizer use the Guided Editor to edit filter expressions. Visualizer highlights sections of input according to the color code. More hints will be provided than in Querent because filter expressions are more complex than values.

Special Keystrokes

Control-HEnable hinting
Shift-Control-HDisable hinting
Up, Control-USelect the previous hint
Down, Control-NSelect the next hint
HomeSelect first hint
EndSelect last hint
Tab, Right, Control-SpaceUse the selected hint
EscapeTemporarily hide the hint box

6.2 License Viewer

License Viewer lets you examine and updated your license for InfoSecter. You can access License Viewer from either Visualizer or Querent. Open the Help menu on the menu bar and select the "License" item.

The license itself is a string of upper case letters and digits. The current license is displayed and is editable. The other fields are not editable and display information about the license.

FieldInformation
TypeType of license
Customer IDThe identifier of the customer who owns this license.
License IDThe identifier of this license, per customer.
FeaturesThe security device families that are enabled.
ExpiresThe expiration date of the license.

The type of license is one of

To update your license

  1. Erase the current license.
  2. Type or paste in the new license.
  3. Verify that the license is valid by looking at the Type field.
  4. Click the "Update" button.

6.3 Utility Scripts

InfoSecter provides a number of Perl scripts. In all cases invoking the script with the -help argument print a usage message that explains the script arguments.

Creative Commons License

InfoSecter Report Generator, InfoSecter Internet Storm Center Expression Builder , and InfoSecter Packet Capture Expression Builder by Network Geographics are licensed under a Creative Commons Attribution-Share Alike 3.0 United States License. Executable versions of the scripts that include the dependent modules are provided for the Windows platform. These executables were generated from the included source by PerlApp from Active State.

Index

 A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z 

A

  • ASA
  • Analysis Dialog
  • Analyzer
  • Analyzer examples
  • Analyzer syntax

    • B

  • Browsing

    • C

  • CheckPoint
  • Cisco IOS
  • Cisco PIX, ASA, and FWSM
  • Composing Clauses
  • Config Inspector
  • Config Inspector Objects
  • Config Inspector Toolbar
  • Config Inspector context menu
  • Configuration Change Review
  • Conflict Inspector
  • Controlling Clause Nesting
  • Cross Conflict
  • Cross Interface

    • D

  • Dictionaries
  • Display or hide Symbol Viewer
  • Dissection
  • Dissection
  • Dissection Slice

    • E

  • Editing Claues
  • Editing Filters
  • Expressions, Editing in Querent

    • F

  • FWSM
  • Feature Alignment
  • Filter Expressions
  • Filter Operator Table
  • Filter and Query Tabs
  • Filtering

    • G

  • Guided Editor
  • Guided Editor, color
  • Guided Editor, keystrokes

    • H

  • Hints

    • I

  • IOS
  • InfoSecter Device Support
  • InfoSecter Reference
  • Introduction

    • J

  • Juniper Netscreen

    • K

  • Keystrokes, Guided Editor

    • L

  • License Type
  • License Viewer
  • License, Update

    • M

  • Macros
  • Main Grid

    • N

  • Negation, Predicate

    • P

  • PIX
  • Policy Validation
  • Predicate
  • Predicate Negation

    • Q

  • Querent
  • Querent Expressions
  • Querent, Editing Expressions
  • Querent, Editing values
  • Querent, Macros
  • Querent, Nesting Clauses

    • R

  • Remediation

    • S

  • SCP
  • SSH
  • SSL
  • Security Device Features
  • Security Device Migration
  • Self Conflict
  • Structured Editor
  • Symbol Viewer

    • T

  • Tabs, Main Grid
  • Tile
  • Tiling

    • U

  • Update License
  • Using Expressions
  • Utility Scripts

    • V

  • Visualizer
  • Visualizer Help Menu
  • Visualizer Main Window
  • Visualizer, Analysis Dialog
  • Visualizer, Editing filter expressions
  • Visualizer, Filter Tab
  • Visualizer, Filtering
  • Visualizer, Main Grid
  • Visualizer, Query Tab