Assumptions and Recommendations

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Assumptions and Recommendations

It is recommended to begin the implemementation in QA/staging environment. You can deployment in production
but be cautions about traffic volume, and Auto Policy Generation profiles you use (Production Profile only.)
Gather required information for deployment:
Obtain Network Topology diagram

Get the domains\URLs with protocols (HTTP\HTTPS:Uniqe port).

Where is the SSL being terminated?
Are different IP\Port defined for every web site or is the web server based on Host Header?
Gather required information for Security Policy Planning:

If a penetration test was conducted and information can be gathered before the implemementation, it will be ve
Do you have a public Admin path that requires special attention?

Are there any File Upload folders? (if positive what extensions are valid)
Are there any Streaming Media files?
Where are the Login pages? We will need valid username and password for the testing.
Please define what is the Code Page for every site we need to protect (UTF-8, 8859-2 etc.)
Sensitive Cookies in the application?
Are Credit Card Numbers processed by the Application? Are the numbers in a database?
Any other confidential information (such as national ID numbers) that should not appear in the response?
Any know Web Application vulnerabilities you are aware of?
You would need a contact person who is knowledgeable on all web application areas and can perform all kind
activates (surfing, purchasing and such) and can also confirm that everything is working.
Is there a Security Page for the website?
For example: http://www.radware.com/securityblock/securityblock1.asp?_event_transid=2181105781
See our template here: http://kb.radware.com/questions/2695/

AppWall Implementation Steps (version 5.6)

PHASES Phase Description
PHASE 1

PHASE 2

PHASE 2.1

Details

Implementation Goals and Planning

Planning the implementation

Based on the your implementation goals plan the implementation:

- Select the relevant Security Policy Track
- The security track will derive how long should the implementation take
- How many web applications should be tested
Who are the people required to accomplish a successful implementation:
- Application QA
- Relevant Security personnel
- Application people that can address application scope questions and issues.
- Does this web application available for implementation
What traffic volume expected and what impact it might have on performance

Pre-Install Information Gathering

if the web application is externally accessible, you can View traffic, identify potential challenges, activate Auto Discovery
before arriving on site

Deployment in Staging Environment

Select preferable deployment: Virtual of Physical Appliance

If VMware ESX infrastructure exists, consider using AppWall VA.

If performance is part of evaluation criteria, verify that the Hosting ESX is running on reasonable HW, with the ability to
allocate required resources for the AppWall VA or use the physical appliance.

Select preferable deployment mode

Reverse Proxy: suitable for ADC deployment when original client IP address is not required in web app. If Client IP
address required for logging purposes only, you can add client ip address in XFF header and still use the Reverse Proxy.
The preferable deployment mode. For Additional information please refer to KB2559.
Transparent Proxy: suitable for ADC deployment when original client IP address required in web app. Please refer to
line 20 for limitations of this deployment mode.
Bridge: suitable for standalone AppWall deployments, usually in a non-ADC environment.

Preferably implement AppWall in Test/QA/Staging environment

It is highly recommended to deploy AppWall in a Test/QA/Staging environment first, especially as part of implementation.
If the prefered deployment is in the production environment, and the SSL traffic is terminated before the Web servers
you may consider using AppWall Monitor for span port traffic.
Deployment in production in-inline mode Gateway is not recommended but might be requested.

ADC (Alteon or AppDirector) deployment

Deploy AppWall only as after successful ADC deployment was validated. Pay
special attention to next item:

PHASE 2.2

Test the cache policy with Alteon / AppDirector on the target web site for afew
days prior to moving traffic through AppWall.

After redirecting the traffic through AppWall, set the cache only on AppWall farm (there is a common mistake to set
cache also on the web server farm).

Monitoring Traffic Volume (CEC)

ADC acceleration

Set on Alteon/AppDirector the Close on session end and check the peak value.
There is a limitation with activating Acceleration and SSL offloading features in AppDirector along with AppWall in
Transparent Proxy mode:
- AppDirector versions 1.x support Transparent servers but not SSL offloading.
- AppDirector versions 2.x support SSL Offloading but no transparent servers.

Caching

Set the caching only on AppWall Farm.

Do not enable caching during Auto Policy Generation phase.

SSL Termination

preferably enable SSL Termination at the ADC. If AppWall must process SSL traffic you have the option to set the tunnel
to either SSL-Clear or SSL-SSL mode. If using SSL-SSL consider smaller encryption key in the backend web servers

Multiplexing

Multiplexing might be an issue, as termination of one server tcp connection by AppWall upon security violation, might
impact multiple client connections. Recommended not to use.

Layer 7 Policy

In the scenario of many web servers which might result in many tunnels, use Host header based policy in the ADC.
Host header Policy enables defining single tunnel to different applications and different servers. The need for more than
a single tunnel will be when both SSL and HTTP traffic is used, and when multiple encoding types are utilized
(applications in different languages). For additional details about host based security policy please refer to KB2869

Redirect Policy
Disable Multiplexing on AppWall's Farm (in AppDirector)

LB rules based on source IP for testing e.g. QA\LAN

Before the actual AppWall deployment

AppWall Deployment
place AppWall in a server rack
Connect AppWall to the network. Make sure there are at least 2 available
network ports in the switch

At least one port used for web application traffic and one port for management. Additional NICS can be added. In Bridge
mode 2 NICs required for Bridge and one for management.

Define unique hostname for AppWall server, set management IP for remote
management
Upgrade to AppWall latest version
Install the latest Java on your PC in order to run AppWall MNG Application
https://MNG_IP/Console/

PHASE 3

Local AppWall Settings:

Time zone
DNS
Default Gateways for Management and Services
Routing Rules
Management IP
Services IP
Management Default Gateway for separated routing of Management traffic
In the
scenario of Bridge mode deployment, configure a bridge IP, from the relevant network segment
Bridge IP - for Bridge mode deployment; the bridge ip address must not be from the MNG subnet
MNG IP and Bridge IP must be with
a different networks

Validate that an authenticated license is installed on AppWall.

If management application shows "Ended with Errors" message at the bottom, follow the next instructions:
check > Forensics > initialization logs - look for red items:
usually License issue or Is

Verify that the relevant AppWall instance is running (Gateway or Cluster)

Verify AppWall License match instance type

For additional details regarding Cluster deployment please refer to KB2441

There are 2 types of license for AppWall. Base platform license and throughput license. There is still backward
compatibility for the previous Licenses with no throughput limitation

Map network topology

Set services (Web traffic) IP addresses, define required routing rules
SSL Certificate

Have a network topology map

Define Network Firewall rules for web traffic

Define Network Firewall rules for remote management:
The IPs of Administrator, Partner & Radware.

Open Ports - change rule for port 80/443 to allow access to AppWall instead of directly to Servers
Open TCP ports in the network Firewall for management interface (for encrypted mgmt traffic):
8200 (Gateway management)
8270 (Cluster management)
443 for Web Interface
22 for CLI (SSH)
2214 and 9216 (Vision) - for more details please refer to KB2710

Check code-page for every protected website

Verify (in the user guide) that the required code-pages are supported.
If not contact Support to add support for required Code-page

Create and configure in AppWall a security page

Build a Company Security page to which users will be redirected upon security violation (e.g. "Please contact customer
support."). An advance security page which can process query parameters, can accept and show event transaction ID
for easier search in Forensics (by default the parameter name is "_event_transid").
For more details please refer to KB2695

Rollback plan & execution

what do YOU do in a case of emergency:

move tunnel to BYPASS state
Define ADC Backup Servers that routes directly to Servers

Ask the Admin to provide all SSL server certificates and the passwords
Install certificates on Alteon / AppDirector.
Define SSL policy.
If end-to-end SSL required, import certificates to AppWall as well.

Initial Configuration: Create a Tunnel in Passive Mode

Add web servers

In ADC deployment it will usually be an internal VIP that will balance the traffic to the web servers.
In non-ADC environment, Web server interface will be the protected web server.
in Bridge mode deployment, you can also set a Web Farm

Create a new tunnel(s) in AppWall. If creating an SSL tunnel select the Server
certificates imported in phase 2

defining 1-2 tunnels to protect the implementation sites.

consider the limitation of number of tunnels

If at this phase protecting multiple servers is required, you should plan how to distribute traffic to your applications: The
total number of tunnels which can be defined in AppWall is limited to 50. Even without reaching this limit, if you are
required to add more than 15 tunnels, you should consider revising your tunnel planning:
Please refer to Layer 7 Policy section (C 24).

XFF (X-Forwarded-For) or TrueIP HTTP header

Set the tunnel default working mode to Passive

HTTP Properties and Parsing Properties review
Review other tunnel settings to be relevant to the tested application
If relevant, add X-Forwarded-For setting in Tunnel Properties.

PHASE 4

Configure AppWall to add client source IP address to the XFF header

Configure AppWall to retrieval client IP address from XFF when AppWall receives client IP in XFF Header. Possible
scenarios might be:
- AppDirector Client NAT
- ISA Server
- CDN (e.g. Akamai)
- Other Proxies
For additional details, please refer to KB2559 and KB2528

Code page, Masking Errors, Server Identity

Message size: a preliminary inspection of message size should be performed.
In the scenario of Reverse or Transparent Proxy implementation, when application needs clients source IP addresses

Selecting Security Implementation Strategy

Based on the implementation goals/requirements/plan select the most relevant The Security Implementation Strategies detailed herein are independent one from each other. In real-life
Security Implementation Strategy: one of the options 4.1, 4.2 or 4.3
implementation scenario, it might be a reasonable approach to begin with one implementation strategy, and in future
phases to switch to a different strategy to address wider scope of security threats.
During the implementation it is recommended to select one of the security implementation strategies listed herein
based on the requirements.
The levels presented are just recommendations; Different policies can be defined.
When selecting the Implementation Strategy, consider the Security TCO
Tradeoff:

Risk, values and tradeoffs

Low False Positive Rate vs. Security Coverage to wide scope of threats.
Performance impact
TCO - availability of resources to maintain the policy
Time for deployment

Consider how you can hedge the risk/effort through implementation of

Application Paths

PHASE 4.1:
Security
Level 1

Defining Standard Security policy

Time for Level: 3 day(s)

depends on Application size and efficiency of testing process

In the Security Policy view, create a new Web Application using the web
application wizard, with:
- "/" Application Path
- Rapid Auto Policy Generation mode
- Select the relevant Profile: If staging environment select Manual Browsing or
Manual Crawling; if Production, select Production Rapid.

Web Application can be defined on a:

- Web Server
- Host
- Application Folder

At the host level (under web application) configure the Security Page
Browse through AppWall

at the Host level setting in the Security Policy

Initially the admin should access the application through AppWall to validate traffic is processed properly and basic
legitimate requests are not blocked. Specifically check message size logs that nothing is blocked

Let the Auto-discovery build application tree according to processed traffic

Forward traffic through AppWall:
- In staging environment forward only legitimate (attack free) traffic
- In production environment you can forward real application traffic

Auto Discovery will show access information (parameters status codes, 404, etc.) and application structure
define who will access the application through AppWall in the first phase (QA, test group, admin). Warning: do not use
staging profiles in production environment.

Testing

QA team or admin, either manually or also using a crawler browse through the entire Web application (make sure all
dark corners are accessed as well) - to generate logs for later fine tuning.

Verify that Vulnerabilities, Database and HTTP Methods security filters are
enabled. Review the Path Blocking filter findings, disable Safe Reply\Path
Blocking in case there is no need.
Let the system generate policy automatically
Fine tuning through Refining the security policy from the Security events, using
"Refine!" button

Configure the AppWall system to forward events to Vision Reporter

Backup the policy

Violations of HTTP RFC should be fixed in application or can be set to be ignored by AppWall either for specific URL or
for "Any URL".
Review all Security events in the Forensics view.
At this point all traffic should be legitimate and should not be blocked. Refine the events that generate false positives.
At this point 404 status code can be identified as well (broken links)
consider using Discard all rules or Apply to all other pages

Right Click - backup or from Web Based Management interface

OR
PHASE 4.2:
Security
Level 4.2.1:
2
PHASE

Defining Advanced Security policy

The Auto Policy Generated Policy
In the Security Policy view, create a new Web Application using the web
application wizard, with:
- "/" Application Path
- Rapid Auto Policy Generation mode
- Select the relevant Profile: If staging environment select Manual Browsing or
Manual Crawling; if Production, select Production Rapid.
At the host level (under web application) configure the Security Page
Create Application Paths (if required) with Rapid Auto Policy Generation Mode.
Activate relevant Security filters in these Application Paths based on the next
inputs:
Identify where sensitive data might be residing in the application. Create
Application Paths and activate Safe Reply Filter on relevant sections

Time for Level: 3 - 4 days

depends on Application size and efficiency of testing process
Web Application can be defined on a:
- Web Server
- Host
- Application Folder

at the Host level setting in the Security Policy

Payment and shopping cart web app pages

Any page that might leak sensitive info
If there is no Credit Card Numbers, Social Security Numbers or other types of Sensitive data - Disable this filter

Verify that Vulnerabilities, Database and HTTP Methods security filters are
enabled in all Application Paths

or in Full Auto mode

Browse through AppWall

Initially the admin should access the application through AppWall to validate traffic is processed properly and basic
legitimate requests are not blocked. Specifically check message size logs that nothing is blocked

Let the Auto-discovery build application tree according to processed traffic

Forward traffic through AppWall:
- In staging environment forward only legitimate (attack free) traffic
- In production environment you can forward real application traffic

Auto Discovery will show access information (parameters status codes, 404, etc.) and application structure
define who will access the application through AppWall in the first phase (QA, test group, admin). Warning: do not use
staging profiles in production environment.

Testing

QA team or admin, either manually or also using a crawler browse through the entire Web application (make sure all
dark corners are accessed as well) - to generate logs for later fine tuning.

Fine tuning through Refining the security policy from the Security events, using
"Refine!" button

Message Size and RFC properties are part of the Auto Policy Generation. Nevertheless review the events for details and
refine:
Message size and parsing properties events should be reviewed first
Violations of HTTP RFC should be fixed in application or can be set to be ignored by AppWall either for specific URL or
for (Any URL)
Review all Security events in the Forensics view.
Parameters Security Bypass list can be updated to bypass cookies that do not require protection. Add the Alteon /
AppDirector persistency cookie to the list of bypassed parameters
At this point all traffic should be legitimate and should not be blocked. Refine the events that generate false positives.
At this point 404 status code can be identified as well (broken links)
consider using Discard all rules or Apply to all other pages

Additional security features can be enabled based on needs and requirements

PHASE 4.2.2

e.g. if during penetration test a specific folder was identified as exposing sensitive info and should not be accessed, can
be added to Path Blocking

Configure the AppWall system to forward events to Vision Reporter

Advanced Manually Set Security Features
Indentify what is considered as sensitive information, in the organization. Define Some organization regard different data as sensitive. If possible use custom pattern in Safe Replay to mitigate
custom sensitive patterns for Safe Reply
sensitive data leakage.
integration with external DLP solution available through ICAP protocol

Is there any /admin/ application path (for configuration of the web site, creating Add Path Blocking filter to all Application paths, and add sensitive folders to Path Blocking filter on all application
web users, etc). if so, consider using path blocking for that path.
Paths.
If limited access is needed, define web role(s) based on source IP address or based on Successful Login Detection. You
can then allow access to these path only relevant role.
Is there any file upload folder? if so, use "File Upload"
If exists create Application Path for Upload application and define File Upload filter on it with specific allowed file types
If limited access is needed, define web
role(s) based on source IP address or based on Successful Login Detection. You can then allow access to these path only
relevant role.
Are there any streaming files (swf, avi, mpeg, radio). if so use "bypass
if exists - define to bypass in tunnel level "Security Bypass" tab. Also allows ignoring problematic applications cookies
extensions"
(ASP, Google, etc.)
use Brute Force security filter to secure login pages

Create Application Path for Login page and Authenticated pages, and enable Brute Force Filter on them. For additional
information, refer to KB2952.

Identify sensitive cookies and secure them.

Securing cookies (the default is signing, but you can also encrypt) impacts performance
Preferably secure only the sensitive cookies identified rather than securing all
Session security filter events should be reviewed to define whether there are cookies that should not be processed as
the client side need to read or manipulate them.

Backup the policy

Right Click - backup or from Web Based Management interface

Defining Complete Security policy

Time for Level: ~2 weeks

depends on Application size and efficiency of testing process

OR
PHASE 4.3:
Security
Level 4.3.1:
3
PHASE

The Auto Policy Generated Policy

In the Security Policy view, create a new Web Application using the web
application wizard, with:
- "/" Application Path
- Extended Auto Policy Generation mode
- Select the relevant Profile: If staging environment select Manual Browsing or
Manual Crawling; if Production, select Production Automatic

Set the Auto mode in the Web Application wizard

As of AppWall version 5.0 the / Application Path is recursive.
Web Application can be defined on a:
- Web Server
- Host
- Application Folder

if possible import and process sitemap.xml for shorter time for initial policy

Tools which AppWall offers for Auto Policy Generation:

Traffic Processing (AC) test/prod
External Crawler test (C:\WINDOWS\system32\drivers\etc\hosts)
External Sitemap Generator staging or producation
Sitemap import staging or producation
Internal Crawler staging or producation
- Limitations: HTTPS, Redirects, login

Browse through AppWall

Initially the admin should access the application through AppWall to validate traffic is processed properly and basic
legitimate requests are not blocked. Specifically check message size logs that nothing is blocked

Let the Auto-discovery build application tree according to processed traffic

Based on Auto Discovery review, consider whether you need a Regular
Expression based Application Path

Auto Discovery will show access information (parameters status codes, 404, etc.) and application structure
repeat this periodically at the during the initial auto policy process.
For Regular Expression Application Path please refer to KB2506

Forward traffic through AppWall:

- In staging environment forward only legitimate (attack free) traffic
- In production environment you can forward real application traffic

define who will access the application through AppWall in the first phase (QA, test group, admin). Warning: do not use
staging profiles in production environment.

Testing

QA team or admin, either manually or also using a crawler browse through the entire Web application (make sure all
dark corners are accessed as well) - to generate logs for later fine tuning.

Fine tuning through Refining the security policy from the Security events, using
"Refine!" button

Message Size and RFC properties are part of the Auto Policy Generation. Nevertheless review the events for details and
refine:
Message size and parsing properties events should be reviewed first
Violations of HTTP RFC should be fixed in application or can be set to be ignored by AppWall either for specific URL or
for (Any URL)
Review all Security events in the Forensics view.
Parameters Security Bypass list can be updated to bypass cookies that do not require protection. Add the Alteon /
AppDirector persistency cookie to the list of bypassed parameters
At this point all traffic should be legitimate and should not be blocked. Refine the events that generate false positives.
At this point 404 status code can be identified as well (broken links)
consider using Discard all rules or Apply to all other pages

Turn Auto Policy Generation off

Review and Tune auto - generated policy

PHASE 4.3.2

Configure the AppWall system to forward events to Vision Reporter

Advanced Manually Set Security Features
In case where parameters are used globally across the application, configure
global parameters policy

after at least 1 week, preferably longer

review the generated Application Paths, the utilized Security Filters and the generated refinements for the relevant
security filters
modify and tune the policy:
- delete non-relevant Application Paths
- create RegEx based Application paths (only when there are many application paths that can be merged into few
RegEx based Application Paths)
0
Defining a list of parameters in the Global Parameters filter significantly simplifies the learning phase of the Parameters
Filter

In case the application processes XML client input and / or web services import
WSDL file and activate WebServices or XMLSecurity where needed.
Create Application Paths (if required) with Extended Auto Policy Generation
Mode. Activate relevant Security filters in these Application Paths based on the
next
inputs:
Double
check that SafeReply filter activated where required, by Auto Policy
Generation. If not create Application Paths and activate Safe Reply Filter on
relevant sections

Payment section and shopping cart web app pages must be secured by SafeReply
Any page that might leak sensitive info

Indentify what is considered as sensitive information, in the organization. Define Some organization regard different data as sensitive. If possible use custom pattern in Safe Replay to mitigate
custom sensitive patterns for Safe Reply
sensitive data leakage.
integration with external DLP solution available through ICAP protocol
Is there any /admin/ application path (for configuration of the web site, creating Add Path Blocking filter to all Application paths, and add sensitive folders to Path Blocking filter on all application
web users, etc). if so, consider using path blocking for that path.
Paths.
If limited access is needed, define web role(s) based on source IP address or based on Successful Login Detection. You
can then allow access to these path only relevant role.
Is there any file upload folder? if so, use "File Upload"

If exists create Application Path for Upload application and define File Upload filter on it with specific allowed file types
If limited access is needed, define web
role(s) based on source IP address or based on Successful Login Detection. You can then allow access to these path only
relevant role.

Are there any streaming files (swf, avi, mpeg, radio). if so use "bypass
extensions"

if exists - define to bypass in tunnel level "Security Bypass" tab. Also allows ignoring problematic applications cookies
(ASP, Google, etc.)

use Brute Force security filter to secure login pages

Create Application Path for Login page and Authenticated pages, and enable Brute Force Filter on them. For additional
information, refer to KB2952.

Identify sensitive cookies and secure them.

Securing cookies (the default is signing, but you can also encrypt) impacts performance
Preferably secure only the sensitive cookies identified rather than securing all
Session security filter events should be reviewed to define whether there are cookies that should not be processed as
the client side need to read or manipulate them.

When required configure the Authentication and User Tracking settings under
the host

Enables:
- Authentication
- single-sign-on to multiple application
- successful login detection to cross and sub domain application
- role-based policy for authenticated users and for guests
- role-based policy by mapping AppWall roles to LDAP groups

Logging filter - highly effects performance; use it only selectively and for
specific application paths for short periods of time.

PHASE 5

Form field and parameters protection or obfuscation should be utilized only

where required

Usually as a solution for known sensitive parameters or penetration test result.

Backup the policy

Right Click - backup or from Web Based Management interface

Advanced Tuning
Avoid from Product fingerprint

PHASE 6

CSRF protection is set to Passive by default. Review the logs change the mode to Active if required

In "Hosts" section under "Security Policy" tab you have the CSRF protection settings. Please manually REFINE by either allowing domain name (e.g.
*.domain.com) or specific file under the new "Hosts" section.

View Dashboard - view active connection per tunnel to learn normal behavior
(baseline).

update max active connections in tunnel configuration if needed (a good Active Connections :TPS ration should be ~
1:2-3)

Idle session timeout

You should also trace the ration between Active connections to the Transactions Rate (TPS) - High Active connections
to Transactions Rate ratio might indicate wrong settings of idle connections in the web server and in the AppWall tunnel

Backup the policy

Right Click - backup or from Web Based Management interface

Vision Reporter
Configuring AppWall for events distribution
Security Reports
Application Intelligence
PCI Compliance
Correlating Reports
Alerts

PHASE 7

PHASE 9

under Configuration View > Services you can configure the Vision Reporter settings. For more details please refer to KB
2826

Configuring Multi-Tenancy
You may consider configuring user Authentication and Role based policy with
Active Directory, LDAP, and Radius.

For additional information please refer to kb2882

Setting policy per web application (Tenant / Customer)

Reminder: Web Application can be defined on a:

- Web Server
- Host
- Application Folder

Creating AppWall users with management RBAC per web application

a. Administrator
b. Web Application Owner
c. Web Application Viewer

Reporting per customer

PHASE 8

Change the K_V_D__ cookies prefixes \ "_event_transid" parameter name of security page\ make sure the security page
neither contain the expressions such as "Web Application Firewall" \ "AppWall" or similar

can be shown when logging in as Web Application owner and viewing the reports only of your owned applications

Switching to Active mode (in staging environment)

when no false positives found in the events

Change the chosen tunnel state to Active mode

review logs periodically and refine policy as needed
Review Vision reports and Forensics info
Backup the policy

after all events are handled and refined, change tunnel mode to Active

Moving to Production (passive mode)

when no event from internal testing generated and you ready to move to active

Right Click - backup or from Web Based Management interface

Change the Staging environment AppWall tunnel mode to passive

change Automatic Configuration profile to Production pro"Production Rapid" or "Production Automatic" Traffic analysis profiles !!!

Transfer AppWall policy form staging environment to the production AppWall

create a branded informative page with transaction ID for case tracking of false for additional information pleas refer to kb 2695
positive incidents
Review the security events periodically
Remember: Your tunnel is still in Passive mode !!!

PHASE 10

Switching to Active mode (in Production)

Once the Auto Policy Generation process is in advanced state, you can proceed
to next step of switching to active mode

How you know Auto Policy Generation is in advanced state:

Auto Policy Generation progress bar reaches at least 75%
AllowList refinements (in Rapid mode you should expect to see 5 - 10 common file extensions)
In Rapid mode system is recommended to be in passive mode 4 - 7 days. In extended mode, depending on traffic
volume and diversity of the traffic, system is recommended to be in passive mode 1 - 3 weeks.

disable the "Suppress Events when Auto Configuration Learns" check box in the
Security Policies > Auto Policy Generation
You now have 2 possible approaches as to how to switch the system to Active
mode in production
select the active Implementation Strategy: one of the options 10.1 or 10.2

PHASE 10.1: The Conservative Approach

Active Filter By Filter

Reminder: when auto policy generation system switches a security filter to

active mode it means the policy optimization process accomplished for this filter
in the relevant application path and host.
For all the Security Filters which were switched to active mode by the Auto
policy, manually change the working mode passive.
For all these Security Filters manually change the automation mode to "Auto
Refinement".
Create custom views in Forensics Security Log to filter the security events by
"tunnel" event

Refine\review Tunnel event

switch tunnel to active while all the filters are Passive

Create custom views in Forensics Security Log to filter the security events by
Security Filters.
For each such filter review the events and make sure there are no false positives
switch filter by filter to active mode
Depending on how frequently the web application is being updated and
You can consider disabling Automatic Policy Generation either per filter or globally across the device in the Security
modified, consider to disable Automatic Policy Generation per
Policies > Auto Policy Generation. You can also disable tunnel's "Auto Policy optimization" in the relevant tunnel >
filter\tunnel\device
"General Properties".

OR
PHASE 10.2: The Rapid Approach

Active Tunnel

Create custom views in Forensics Security Log to filter the security events by
Security Filters.
For each such filter review the events and make sure there are no false positives
consider disabling Automatic Policy Generation per filter\tunnel\device
depending on how frequently the web application is being updated and modified.
Create custom views in Forensics Security Log to filter the security events by
Refine\review Tunnel event
"tunnel" event
switch tunnel to active while all the filters are Passive
consider to disable Automatic Policy Generation per filter\tunnel\device

depending on how frequently the web application is being updated and modified.