So, as move into the security testing, first of all we look at two main types of testing: White Box testing and the black box testing.
We will next talk about security testing. The security testing is broken up into two main types of testing. There is White Box testing and also Black Box testing. White Box testing is sometimes referred to as clear box testing or structural analysis. The Black Bock testing is opposite of white box testing and is more of a zero knowledge test.
The reason why it’s called the clear box or white box testing is because the source code is fully physical. Generally, the tester is another programmer that has access to whatever they want in terms of supporting documents, any aspects of the source code, any source of the use and misuse documents, configuration files, whatever they need to have access to so that they may be able to really test the code for how well it has been written as to its structure and logic as well as meeting standards, from a security standpoint.
Black Box testing is where it’s a zero knowledge test. There is zero knowledge of the coding and then another programmer, an “attacker” goes through the software and tries to see if they can create a compromise, just like a normal attacker would do, with no inside knowledge. They go through a series of tests which are fitting for this role they play in attempts to compromise the data. Some of the black box testing techniques might be fuzzing, scanning or penetration testing logic.
Fuzzing. Fuzzing we’ll just mention first, because we’ve talked a lot about code injection, and we’ve talked a lot about our web applications especially the parts where they elicit input from users or user forms. If there are any forms for the user to input, we have to make sure that they are safe and secure. Somehow, also that they don’t lead to having problems on the back end. The fuzzing is sometimes referred to fault injection testing. The programmer who’s testing the system, will inject faults over and over with slightly different variations and seeing how the software responds. Do we have an application that can withstand malicious code or withstand code injection, or do we have software that allows for commands to be injected? We are testing to see if the software can withstand that type of attack. That kind of verification of software is referred to as fuzzing. We could also look for any other security bugs. Detection of such things like buffer overflow errors, and any time we could detect these, then there’s more information written to memory than what is allowed, overflowing or overfilling the memory buffer. When the memory has overflowed, then it spills its contents into some other application or some other buffer for another area associated with the system.
Remote code execution: Anytime that we are accessing code through a remote location, with the user inputting information into an application, there are always inherent risks involved. So, having the potential danger with the remote access is one of the factors we are exploring with this type of test. Another is that we are looking also for: faulty logic, poor structure, and other things that we could use fuzzing to detect their presence.
Scanning: There’s a lot to be said about scanning when we talk about vulnerability assessments and penetration testing. Scanning is a more passive means of gathering information. Basically, when this is done, the person is scanning the network to try to identify the ip address of the user, the various naming conventions, schemas, where the various critical servers are located, which ports are open and so on. There are a number of different scans which include: vulnerability, content and privacy. Generally, vulnerability is scanning for inherent flaws. The content scan is looking for some sort of embedded virus like in macros part of an application. The privacy scan is looking that there are no privacy violations. These lead into our understanding of penetration tests (also called pen-tests) where there is an opportunity for exploitation of the weaknesses of the software.
The general vulnerability scan is looking for some of the known flaws and looking to see if the common ports are open for example, port 80 being open and such. On the system, is the user looking for the web traffic and patches for the system to improve security as well as continuing to add updates, for continuing to improve security as well. The vulnerability scan is looking for these things.
Another kind of scan is called content scan. This is where we scan for the actual content of what’s on the webpage. It doesn’t have to be just the file, but we can also scan for the macros of the webpage, word document, and so on. Viruses infect the macros of some of these other file types and it hasn’t always been an easy element to scan. But now there is better programming today to check on the presence of malware or viral content.
Privacy scanning: This is the type of scanning to continue looking at the the software to make sure that it is not exploiting the privacy of our customers or our patients or whomever the software was originally written for.
Penetration testing: This is the type of tests where we complete like a vulnerability scan and then then take things a step further with it being a more active process. Pen tests are more active while scanning tests are considered as passive.
Penetration or pen tests usually follow four steps: reconnaissance, resiliency attack, removal of evidence, and then reporting and recommendations. The first step is reconnaissance and it involves gathering information by looking at public websites. For example, looking at what information is out there and publicly made available like address, domain name, other information about your organization.
Then, the second step is resiliency attack. This is where the attacker is looking to exploit vulnerabilities of your website. This is where the actual attack happens. Once they have been successful in their attack, then they will want to remove any indication of ever having been at your website.
The attacker is going to clean up any evidence of being there in the removing evidence step. So, some of the things that will be removed or erased are the audit logs, any software that might be left behind, any of the backdoor software. Also, one of the things is to rename any of the software I’ve loaded to make it seem as a legitimate service so that the owner doesn’t automatically see what we’ve loaded as maliciousware or whatnot.
The last step of pen-testing is the reporting and recommendation. This is where we report any of finding the vulnerabilities, reporting on any noncompliance issues, noncompliance with organizational policy (whether we agree with the policy or whether it is working or not), and any of the other results from the scan. This scan is over the owner’s network and looking at the elements and principles of foundational programming whether following the organizational policies or not. We also can see what the vulnerabilities are. Compared to the scan which is a passive process, the pen-testing is a much more active process, and can take steps further in exploitation processes.