Imperva Cyber Community

communities_1.jpg
 View Only
  • 1.  Managing Non-Prod testing without investment in it

    Posted 10-17-2019 14:49
    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
    ------------------------------


  • 2.  RE: Managing Non-Prod testing without investment in it

    Posted 10-22-2019 15:05
    Hi Randall,

    You have hit on a pet peeve of mine, you can imagine that in Support, not having a test instance to work on can make our jobs considerably more difficult.

    However, there is still a lot you can do without a test instance. For example, it is possible to have test applications protected by the GW, so at least you can test policies (both security and audit) on a controlled access test instance of your application, without affecting the rule sets on your prod instances.

    Another option some of our customers with large physical deployments use is to have the test instances on VMs, so that at the very least testing can be done on a setup which can be easily restored to a known good state using snapshots or whatever.

    Obviously this doesn't help when it comes to patching or upgrading the physical Gateways or MX nodes, but for that you could always make use of our Upgrade Validation service, to give you the best possible chance.

    ------------------------------
    Stefan Pynappels
    Escalation Engineer
    Imperva
    ------------------------------



  • 3.  RE: Managing Non-Prod testing without investment in it

    Posted 10-29-2019 10:10
    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
    ------------------------------