Assessing information security vulnerabilities can be done by inspection or testing. Inspection can be manual, reviewing the design and implementation looking for vulnerabilities, or automated, in which software analyzes the configuration or code. Testing can be white-box, in which the tester knows the details of the system’s design and implementation; black-box, in which the tester knows nothing about the internals of the system; or gray-box, in which the tester has some knowledge.
Related Product : Certified Information System Security Professional | CISSP
In practice, a combination of some or all of the above methods is usually employed in order to try to reduce the probability that an unidentified (and unmitigated) vulnerability will remain in the system when it is put into production. These activities, combined with threat modeling, increase the level of assurance that the system will operate in a secure manner.
In the case of secure software development, assessing code is usually manually reviewed at least once, sometimes twice: first, a peer review process that requires the approval of a second developer before any code changes or additions can be committed to production; and later, a code inspection of the most sensitive and critical components, conducted by developers unrelated to those who developed the original code, to carefully examine the code looking for vulnerabilities or security defects.
Manual code review is very time-consuming, and must be done by experienced (and therefore valuable) developers. A risk-driven approach to manual code reviews allows the organization to focus on those parts of the code where compromise presents the greatest risk. Such an approach might result in greater attention to authentication, authorization, cryptography, and data sanitization functions.
Once you have analyzed the system and identified the potential vulnerabilities, you need to consider the impact should the vulnerability be exploited by a threat actor, and the likelihood of the vulnerability being exploited.
Different architectures (e.g., distributed vs. centralized) and systems (e.g., databases, servers, applications, etc.) require controls that address the unique security challenges they present, but in all cases the underlying platform (operating system) needs to be secure, which includes ensuring that the underlying system has been appropriately hardened (unnecessary services disabled, unneeded ports blocked, etc.) and updated as part of a vulnerability management process, both discussed in Chapter 7.
Follow Us
https://www.facebook.com/INF0SAVVY
https://www.linkedin.com/company/14639279/admin/
