Understanding your test environment

- [Instructor] Before you execute any security tests, you need to make sure you understand your test environment. It's useful to know how to build test cases based on your attack surface validation, cases you can validate through simulation techniques. In Domain 3: Secure Software Design, we discussed the concept of attack surface evaluation, when you evaluate your app's attack surface. You make specific design choices based on the threats and risks that you're most concerned with. You also determine which controls you should build into your app to counter those threats and risks. When you validate your app's attack surface, you'll want to dust off that design document so you can build test cases that will determine whether or not your design and control choices hold up. You'll be validating whether or not those controls were appropriately implemented in the app, as well as whether or not they effectively mitigate the identified risks. If you think you'll be able to perform a tax surface evaluation by just pointing a web app security scanner at your production app, you may want to reconsider. Testing in production is generally considered a big no-no. Fortunately, you can use simulation testing to perform that validation without breaking anything. In short, a simulated testing environment looks like production and responds like production, but it's not actually production. In order to simulate a production environment, you'll want to start with the production code base. When you deploy this code, though, you're going to deploy it to dedicated systems that are entirely disconnected from production. This includes servers, databases, and ideally, even networks. The level of difficulty in building a non-production environment is going to vary based on how the code was written. Hard-coded production values like URLs or database strings will need to be modified for testing. Otherwise, your simulated testing environment will try to make calls to production systems. Virtualization and containerization can definitely reduce the cost and effort associated with creating a simulated environment for testing. But don't take too many shortcuts. Remember, you're not just testing how well your app protects the confidentiality and integrity of sensitive data, you're testing how well the app meets your availability requirements as well. The simulated environment isn't just the systems, it's the data as well. You'll want to create synthetic workloads for your security test. A defining characteristic of a synthetic workload is that it has no real business use. All the values you use, all the fake accounts and fake transactions should be structured so the app still works. They just shouldn't include any actual production data. Testing with production data could result in highly sensitive or regulated data ending up in a less secure environment. Best case scenario, you've got a compliance violation on your hands. Worst case, an attacker finds that data, and you're looking at a data breach. Before you run your first security test, you'll want to be certain that you have a solid understanding of your test environment, and that you've built a simulated instance of your app that doesn't contain any production data.