Guidelines for defining your network hierarchy
Building a network hierarchy in IBM® QRadar® is an essential first step in configuring your deployment. Without a well configured network hierarchy, QRadar cannot determine flow directions, build a reliable asset database, or benefit from useful building blocks in rules.
- Organize your systems and networks by role or similar traffic patterns.
For example, you might organize your network to include groups for mail servers, departmental users, labs, or development teams. Using this organization, you can differentiate network behavior and enforce behaviour-based network management security policies. However, do not group a server that has unique behavior with other servers on your network. Placing a unique server alone provides the server greater visibility in QRadar, and makes it easier to create specific security policies for the server.
- Place servers with high volumes of traffic, such as mail servers, at the top of the group. This hierarchy provides you with a visual representation when a discrepancy occurs.
- Avoid having too many elements at the root level.
Large numbers of root level elements can cause the Network hierarchy page to take a long time to load.
- Do not configure a network group with more than 15 objects.
Large network groups can cause difficulty when you view detailed information for each object. If your deployment processes more than 600,000 flows, consider creating multiple top-level groups.
- Conserve disk space by combining multiple Classless Inter-Domain Routings (CIDRs) or subnets
into a single network group. For example, add key servers as individual objects, and group other major but related servers into multi-CIDR objects.
Table 1. Example of multiple CIDRs and subnets in a single network group Group Description IP addresses 1 Marketing 10.10.5.0/24 2 Sales 10.10.8.0/21 3 Database Cluster 10.10.1.3/32
10.10.1.4/32
10.10.1.5/32
- Define an all-encompassing group so that when you define new networks, the appropriate policies
and behavior monitors are applied. In the following example, if you add an HR department network, such as 10.10.50.0/24, to the Cleveland group, the traffic displays as Cleveland-based and any rules you apply to the Cleveland group are applied by default.
Table 2. Example of an all-encompassing group Group Subgroup IP address Cleveland Cleveland miscellaneous 10.10.0.0/16 Cleveland Cleveland Sales 10.10.8.0/21 Cleveland Cleveland Marketing 10.10.1.0/24 - In a domain-enabled environment, ensure that each IP address is assigned to the appropriate domain.