Fortinet black logo

Administration Guide

Implementation

Copy Link
Copy Doc ID 1ce38eeb-8119-11eb-9995-00505692583a:436395
Download PDF

Implementation

ATR allows you to build Security Rules to trigger on administrator defined-patterns of Security Events to generate Security Alarms. Security Rules can be targeted to only generate alarms for specific hosts, users, and locations. Actions can be taken on Security Alarms to isolate or block compromised hosts automatically.

This section of the documentation discusses the implementation in the order in which it should be done. As the options are discussed, links to additional information are provided.

Network devices

Find or create devices

You will need to find or create the network devices you wish to configure. See Find containers or devices or Add or modify a pingable device. For pingable devices, ATR provides the Security Events option. This allows you to select a security appliance from which events may be accepted in order to create a security event when an event rule is matched.

Threat analysis engines

When you have configured the security devices, you can create threat analysis engines, which will scan applications on the host to determine the threat level, and provide a threat score.

Security policies

Security rules

Once you have configured your network devices, you must create security rules. Security Rules contain triggers that correlate incoming events from the network devices and create an alarm. Defined in the host profile, security rules determine which actions to take based on the alarm that is triggered by the host. See Security rules.

Creating a security rule to catch all incoming events enables you to analyze traffic and identify patterns in order to create rules based on this information. Add a trigger with a single filter, with a minimum severity of 0 and a maximum severity of 10. This will ensure that incoming events of all severity levels are captured by the system.

After you create the trigger, add a security rule using the trigger and set both the user/host profile and Action to None.

Note

This Security Rule will catch all incoming events. To ensure that it does not interfere with normal system operation, it should be the lowest ranked rule.

Note

Because this Security Rule will produce a large number of security events, it will affect system performance. The Security Rule should only be enabled in production during specific times, such as off hours.

Once all incoming Security Events are captured, you can create Security Rules directly from the Security Events view based on various types of Security Events.

Permissions

You must provide permissions for users to view security alarms that are created when a security rule is matched. Users can may then take action on a security alarm if it was not done automatically. You can allow the user to take any action on an alarm, or specify the actions the user is allowed to take. See Add an administrator profile.

Monitor the system

You can monitor and take actions on alarms created from incoming events that satisfy triggers established by security rules that are defined for the host. See Security events.

A security rule with a trigger satisfied and a matching User/Host profile creates a security alarm. The rule may then take an action automatically. The action for a higher-ranked rule takes precedence over the action for a lower-ranked rule. The lower-ranked rule is not implemented automatically, but can still be done manually. However, the action for a higher-ranked security rule will override a lower-ranked rule that was previously implemented.

You can configure the application settings when creating the security rule in Policy Configuration. See Add or modify a rule. As hosts are scanned by the agent, the applications are updated. The security rule includes the applications as part of the trigger that will create an alarm when the rule is satisfied. See Application view .

Security event severity level mappings

Each vendor defines its own severity levels for syslog messages. These severity levels are normalized within FortiNAC to provide additional filtering options for incoming security events. The following table provides severity level mappings between the vendor and FortiNAC.

CheckPoint

Vendor severity level

FortiNAC severity level

1

1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

10

Stonegate

Vendor severity level

FortiNAC severity level

0

1

1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

TippingPoint SMS

Vendor severity level

FortiNAC severity level

0

1

1

3

2

5

3

7

4

9

FireEye

Vendor severity level

FortiNAC severity level

0

1

1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

FortiOS

Vendor severity level

FortiNAC severity level

INFORMATION

1

NOTICE

3

WARNING

5

ALERT

7

CRITICAL

8

ERROR

9

EMERGENCY

10

PaloAlto

Vendor severity level

FortiNAC severity level

INFORMATIONAL

1

LOW

3

MEDIUM

5

HIGH

7

CRITICAL

9

Implementation

ATR allows you to build Security Rules to trigger on administrator defined-patterns of Security Events to generate Security Alarms. Security Rules can be targeted to only generate alarms for specific hosts, users, and locations. Actions can be taken on Security Alarms to isolate or block compromised hosts automatically.

This section of the documentation discusses the implementation in the order in which it should be done. As the options are discussed, links to additional information are provided.

Network devices

Find or create devices

You will need to find or create the network devices you wish to configure. See Find containers or devices or Add or modify a pingable device. For pingable devices, ATR provides the Security Events option. This allows you to select a security appliance from which events may be accepted in order to create a security event when an event rule is matched.

Threat analysis engines

When you have configured the security devices, you can create threat analysis engines, which will scan applications on the host to determine the threat level, and provide a threat score.

Security policies

Security rules

Once you have configured your network devices, you must create security rules. Security Rules contain triggers that correlate incoming events from the network devices and create an alarm. Defined in the host profile, security rules determine which actions to take based on the alarm that is triggered by the host. See Security rules.

Creating a security rule to catch all incoming events enables you to analyze traffic and identify patterns in order to create rules based on this information. Add a trigger with a single filter, with a minimum severity of 0 and a maximum severity of 10. This will ensure that incoming events of all severity levels are captured by the system.

After you create the trigger, add a security rule using the trigger and set both the user/host profile and Action to None.

Note

This Security Rule will catch all incoming events. To ensure that it does not interfere with normal system operation, it should be the lowest ranked rule.

Note

Because this Security Rule will produce a large number of security events, it will affect system performance. The Security Rule should only be enabled in production during specific times, such as off hours.

Once all incoming Security Events are captured, you can create Security Rules directly from the Security Events view based on various types of Security Events.

Permissions

You must provide permissions for users to view security alarms that are created when a security rule is matched. Users can may then take action on a security alarm if it was not done automatically. You can allow the user to take any action on an alarm, or specify the actions the user is allowed to take. See Add an administrator profile.

Monitor the system

You can monitor and take actions on alarms created from incoming events that satisfy triggers established by security rules that are defined for the host. See Security events.

A security rule with a trigger satisfied and a matching User/Host profile creates a security alarm. The rule may then take an action automatically. The action for a higher-ranked rule takes precedence over the action for a lower-ranked rule. The lower-ranked rule is not implemented automatically, but can still be done manually. However, the action for a higher-ranked security rule will override a lower-ranked rule that was previously implemented.

You can configure the application settings when creating the security rule in Policy Configuration. See Add or modify a rule. As hosts are scanned by the agent, the applications are updated. The security rule includes the applications as part of the trigger that will create an alarm when the rule is satisfied. See Application view .

Security event severity level mappings

Each vendor defines its own severity levels for syslog messages. These severity levels are normalized within FortiNAC to provide additional filtering options for incoming security events. The following table provides severity level mappings between the vendor and FortiNAC.

CheckPoint

Vendor severity level

FortiNAC severity level

1

1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

10

Stonegate

Vendor severity level

FortiNAC severity level

0

1

1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

TippingPoint SMS

Vendor severity level

FortiNAC severity level

0

1

1

3

2

5

3

7

4

9

FireEye

Vendor severity level

FortiNAC severity level

0

1

1

2

2

3

3

4

4

5

5

6

6

7

7

8

8

9

9

10

FortiOS

Vendor severity level

FortiNAC severity level

INFORMATION

1

NOTICE

3

WARNING

5

ALERT

7

CRITICAL

8

ERROR

9

EMERGENCY

10

PaloAlto

Vendor severity level

FortiNAC severity level

INFORMATIONAL

1

LOW

3

MEDIUM

5

HIGH

7

CRITICAL

9