Читать книгу The Official (ISC)2 SSCP CBK Reference - Mike Wills - Страница 102
Testing/Implementing Patches, Fixes, and Updates
ОглавлениеChapter 7 goes into more detail on the overall software development process and the concepts behind the software development lifecycle (SDLC) models, both classic and cutting-edge, that are in widespread use today. As the security administrator or team member, you may need to be involved in the overall development process to ensure that any security-relevant issues, perspectives, functional requirements, and insights get incorporated into both the product as it is developed and the management process that keeps that development on track. At some of those test opportunities—which there are more of in a large systems development than there would be for a small, tightly focused patch or update—security may need to be more of an active member of the test team and not just an interested stakeholder and observer. Your experience and insight about what happens when systems fail to be secure can be of great help to test teams as they conduct scenario-based test cases; your knowledge of how the application or system under test should be interacting with network and systems security monitoring and incident detection tools may also benefit the post-test analysis activities as well.
It is best and common practice to do security-related testing in an isolated testing environment, safely quarantined off from your live production environments. Virtual machines in tightly secured test and development subnets, and hosts are ideal for this. This contains any problems that the test may otherwise set loose into your production systems or out into the wild. It also allows you to be more aggressive in stressing the system under test than you could otherwise afford to be if testing were conducted on or associated with your live production environment.
You can also adapt penetration testing scenarios and approaches you would otherwise use against your systems hosted in an isolated testing environment, before you've released those new versions of the systems into live production and operational use. Black box, white box, or other forms of penetration testing may be quite useful, depending upon the nature of the changes you're trying to evaluate.