Previous
Index Next
ISCS version 0.1.1
ISCS is managed through the Security Policy Manager (SPM). The SPM is probably unlike any other network security configuration tool you have ever used. There are no firewall rules, NAT rules, routing rules, proxy ARPs or Security Associations to configure. You will never again write an order dependent rule in a list of ACLs. If you are an experienced network security administrator, you may find this a bit unnerving at first. We joke that the unlearning curve is steeper than the learning curve for experienced administrators. Once you unlearn the old, cumbersome habits and adapt to the ISCS way, you will understand how experienced ISCS administrators configure the security environments in between 1% and 10% of the time it used to take them with traditional network security configurators. When security becomes that easy to administer, we can take security into areas that were never cost justifiable before such as implementing inter-office security on our WANs or securing mobile computing devices. So relax and take a few minutes to learn how to think the ISCS way.
Let's immediately address two objections that are bound to arise. First, "I miss the low level, granular control I used to have." Although one may lose some granularity, it is a very good trade. The burdens placed upon IT security professionals frequently exceed available human and financial resources. There is not enough time to spend hours upon hours configuring low-level rules rules. We can make the analogy to hand crafting an automobile. Yes, one has control over every fine detail when building a car by hand but who can afford to do so. Instead we are quite content to buy one produced in the factory.
However, you will not lose nearly as much granularity and control as you may think. One of the important design criteria of the ISCS project is to never say we cannot do something because of a restriction in the GUI. The SPM exposes almost every possible function available at the command line in one way or another. Extraordinary control and amazing complexity can be accomplished with ISCS. Indeed, you will have the ability to build more sophisticated security than you ever could before.
Second, "Why all the dialog boxes?!" This is closely related to the first objection. Security is not a simple matter. We allow great complexity within ISCS. We have chosen sensible defaults and implemented robust input validation to make life simple and safe for the novice but we have also exposed tremendous power to the experienced user. Complex security requires a lot of information. The dialog boxes collect that information from you so that the SPM can digest that information and then do all the hard, tedious, time consuming work for you. You will begin to hate the GUI designers after clicking through your thirtieth dialog about the presence of SuperRange and SubRanges when defining IP addresses. . . that is, until such a reminder keeps you from making a catastrophic error. Well, we do want to make this a SHORT introduction so on to the ISCS way.
ISCS administrators never configure rules; they never think about rules. They always think in terms of policies. Policies are high level, abstract ways to describe your security environment. They should be intuitive and reflect the real use of information in your organization such as Sales has access to Sales data.
Security Policies answer the question, "WHO has ACCESS to WHAT?" "That sounds just like a firewall rule," you might say. Yes it does but we answer the question in a very different way. Stop thinking in terms of:
Source Address 10.5.6.7 on source ports 1024:65535 to Destination Address 10.1.1.4 on destination port 80 takes the action ALLOW
Instead think in terms of:
Engineering, Marketing, our external testing partner and our public relations consultants need access to the new product data. WHO has ACCESS to WHAT.
There are three major differences in the way ISCS answers that question. First, the answer is not monolithic. A rule like "Source Address 10.5.6.7 on source ports 1024:65535 to Destination Address 10.1.1.4 on destination port 80 takes the action ALLOW" evaluates all the criteria together. As a result, we need a separate rule for every possible combination of Source Address, Source Port, Destination Address, Destination Port and Action. ISCS break the evaluation into its three separate parts so we only need to define WHO once, WHAT once and the relationship between the two (ACCESS) once. We then mix and match as needed.
Second, both WHO and WHAT are organized into separate, hierarchical structures with inheritance. ISCS refers to a WHO as an "Accessor". An Accessor can be a user or a computer -- anything that is trying to access a resource. Accessors are then organized into a hierarchical structure of Access Groups. This will become clear in a moment when we look at some screen shots. ISCS refers to a WHAT as a Resource. A Resource is a combination of Server and Service. Thus port 80 on 10.1.1.4 is a Resource. Resources are also organized into Resource Groups and these are arranged in a hierarchical structure with inheritance. ACCESS is defined in a Security Policy. A Security Policy establishes a relationship between an Access Group and a Resource Group.
The Sales Access Group may contain one hundred different subnets and two hundred other ways of identifying users. It may also contain subgroups for American Sales, European Sales and Asian Sales. The Sales Data Resource Group may have a hundred servers with two hundred different services and subgroups for Consumer Sales Data, Corporate Sales Data and Government Sales Data. When we create a policy that says give Sales access to Sales Data, we have just given all those different ways of defining Sales and all their descendants access to all the various Sales Data Resources and all their descendants.
Third, ISCS has very flexible means of defining WHO.
The first question ISCS asks is "Who can WHO be?" A single IP address? A subnet? An Accessor with a particular combination of fields in their X.509 certificate? An Accessor with a certain Active Directory group membership? ISCS has many ways of defining WHO. This low level definition of WHO preserves granularity and enables an ISCS administrator to scale down to the micro level. However, these granular definitions are never used to manage change. That is too cumbersome. That's why we arrange them into a hierarchical arrangement of groups -- Access Groups -- with inheritance. Security changes are managed (partially) by manipulating the Access Groups and not the individual Accessor definitions. This gives a macro view of security and allows changes to be quickly implemented across a huge number of Accessors of any type - the ability to scale up. Figure 1 shows a typical Access Groups screen.
Figure
1
ISCS handles WHAT in a similar fashion. Unlike other network security management configurators, the SPM combines the Destination Address with the Destination Port into a single object named a Resource. ISCS preserves the granularity of defining WHAT down to a specific service on a specific server. It even provides the ability to override the Server IP address, NAT settings and the public TTL for any Resource (overriding the public TTL is a way to prevent an attacker from sending data from a compromised server to any other site across the Internet). The individual Resources are never used to manage access control. That is too cumbersome. Instead, the Resources are placed into Resource Groups which are themselves arranged in a hierarchical structure with inheritance. This enables macro control over large numbers of Resources through a single convenient handle. Figure 2 shows a typical Resource Groups screen.
Figure
2
The final magic is worked on the Policy Tab. One simply drags an Access Group onto a Resource Group or vice versa and clicks on whether it is an ALLOW or DENY policy. By the way, DENY policies are strongly discouraged and usually unnecessary. ISCS uses a default DENY approach and implements a technology named "Best Match" to make explicit DENY policies very rare events. However, this subject is beyond the scope of a "short" introduction. Figure 3 displays a typical policy screen.
Figure
3
Observe the figure 3 policy lines very carefully. They may initially look like firewall rules but a closer examination shows that they are entirely different. There is no source address or port and no destination address or port. There are no NAT rules and no encryption rules. These are true, high level, abstracted, process oriented, simple to create and non-order dependent policies. The policies are not imposed upon individual IP addresses or devices. They are imposed upon groups of users, Access Groups which may define users in a myriad of ways, and Resource Groups which may include widely disparate Resources of many different kinds. They are policies which reflect the way people work and information flows.
That one drag and drop policy creation may actually produce hundreds or thousands of device specific rules and automatically distribute them to hundreds or even thousands of PEPs but it took the administrator five seconds. This is the incredible power of the ISCS way.