Arthur Hicken, Evangelist-
Arthur has been involved in automating various practices at Parasoft for 20 years. He has worked on projects including database development, the software development lifecycle, web publishing and monitoring, and integration with legacy systems. Arthur has worked with IT departments in companies such as Cisco, Vanguard, and Motorola to help improve their software development practices. He has taught at the College of DuPage in Illinois as well as developing and conducting numerous technical training courses at Parasoft. As an expert in his field, Arthur has been quoted in Business 2.0, Internet Week, and CNET news.com regarding Web site quality issues
With service virtualization, it is simple to have dependencies emulate different security scenarios that would otherwise be difficult to configure and unfeasible to test against. For instance, with SSL, you could configure acceptable and unacceptable certificates. Or, you could emulate various behaviors related to authorization, authentication, and access controls. You could also configure the dependent system to deliver malicious payloads. This provides very granular control over the security behavior of the dependencies in your environment. Your standard functional test scenarios can then be run against these different environment configurations.
While standard penetration testing simulates attacks through an API in a non-stateful manner, service virtualization lets you emulate attacks at various levels of the system and at different points within a stateful process (e.g., at different points in a logical use case or workflow). This not only broadens your test coverage, but can also expose security vulnerabilities that are manifested only a certain set of environment conditions—and that would not be apparent with non-stateful penetration testing.
Moreover, service virtualization enables you to apply testing and validation at multiple depths and levels. By applying validations and assertions to the messages from your AUT, you can isolate and zero in on specific components. You could validate a service’s response for any indication that its security controls are not working properly (or that additional ones should be implemented). For example, you can determine how the exact element you’re testing handles an attempted attack such as an SQL injection. With this direct validation, you gain significantly more visibility into the behavior of a particular component than you can obtain via the output of the larger integrated system.
Using service virtualization for security testing in this way offers the following key benefits:
• It lets you derive more value from your existing functional test scenarios (since you can run them vs. dependencies exhibiting different security behavior).
• It enables extensive security testing to be performed without a security expert. Existing test scenarios can be easily executed against a broad set of preconfigured security scenarios.
• It lets you isolate and zero in on the security behavior of the specific components you’re interested in.