Hi Randall,
To expand on Stefan's response; If the WAF resides in a location that cannot inspect both production and test network traffic then we can use the second set of bridge interfaces to accommodate. However, we must take into account the total throughput of traffic across both bridges so the WAF does not become overloaded.
Typical test environments see only a fraction of traffic their production counterparts receive so this is usually a non-issue, however, your environment may vary.
Since the WAF will now be handling production and non-production traffic, it's important to create a clear distinction in the GUI to prevent "accidents" from occurring. I recommend creating a new Site group for the test environment. This will group the test assets away from the production assets. I also recommend using a nomenclature, such as appending "test", or "tst" to each Server Group and HTTP Service created.
Lastly, it is recommended the test assets use a copy of the security of the policies - by default they will receive the same policies as the production assets. Creating a copy of the policies (recommend appending "test" to the names) will ensure any changes to policy affect the test environment only.
------------------------------
Jaired Anderson
Senior Professional Services Consultant
imperva
------------------------------
Original Message:
Sent: 10-17-2019 14:49
From: Randall Lasini
Subject: Managing Non-Prod testing without investment in it
How are you managing your non-prod testing options when there is no investment in it? For example, when your organization (from a the business side) chooses not to fund additional SecureSphere or Imperva instance, even give a single Gateway, for non-production testing, development, or troubleshooting; what have your solutions been?
#On-PremisesWAF(formerlySecuresphere)
#AllImperva
------------------------------
Randall Lasini
Senior Cyber Security Engineer
illion
------------------------------