When I feel ill, I take a trip to my doctor. At first, the doctor will run some tests to see if there is anything visible that can help indicate what treatment should be given.
(Disclaimer: the writer of this post is in no way or manner a medical doctor).
The Black Box approach
The doctor’s initial prognosis for a regularly healthy person is usually based on visible symptoms and information reported by the patient. A runny nose could indicate a simple cold. However, it can also indicate the flu, allergies, sinusitis, deviated septum and sometimes, it could even indicate pregnancy. If symptoms don’t persist or increase in severity, the doctor will maintain their prognosis and assign a standard treatment.
|“Black–box testing is a method of software testing that examines the functionality of an application without peering into its internal structures or workings. This method of test can be applied to virtually every level of software testing: unit, integration, system and acceptance.”|
However, real medical practice relies on much more than just external symptoms. External symptoms are not sufficient. Therefore, you can expect your doctor to insist on deeper analysis such as periodical blood tests. This provides deeper insight into how our body functions and creates a bill of health for future reference.
The White Box approach
Modern medicine has provided us with a wide variety of tools to analyze the human body. These include blood tests, MRIs, x-rays, biopsies, etc.. The ability to look into our bodies inner-workings and gain information about what our bodies look like from the inside has enabled the medical industry to learn exponentially more about disease and the human body than before these tools were designed.
|“White–box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) is a method of testing software that tests internal structures or workings of an application, as opposed to its functionality (i.e. black-box testing).”|
But enough with the medical talk. Let’s understand what this all has to do with application security.
White and Black Box Application Security
The wonderful thing about application security is that at the end of the day, no matter if you are building wearable technology (aka IoT), Industrial Control Systems (ICS), mobile applications, web applications, embedded applications or any other type of software, they are all built using code. The code can be written in multiple programming languages and in varying structures, yet it’s always the code that makes our technology work.
Black box testing tools, including solutions like Dynamic Application Security Testing (DAST), are designed to analyze the response of an application to an attack. Using multiple techniques, black box tests depend on exposing a “symptom,” discovered by the tester. Attacking an application by trying to run real hacking attempts on the application will expose many of these symptoms. A simple example would be to run a standard SQL injection attack and see if you are able to get more data from the database than what you should. If the tester is able to get privileged data, the test indicates that the application is exposed to an SQL injection flaw.
White box testing methods such as Static Application Security Testing (SAST) rely on the only advantage a vendor has over the hackers – the source code. Access to the application’s source code allows white box tools to build a comprehensive understanding of the risks which might be exposed.
Using the same SQL injection example, white box testing uses a different method. The idea behind white-box testing is to crawl through the code and find all the data junctions where the user has the potential to communicate with the database. For every such location in the code, the system should validate that proper sanitization is performed and ensure that the data is sanitized before it is allowed to run a query on the database.
The major advantage of white box testing solutions goes beyond the detection stage, however.
With a well-integrated SAST solution, an organization is able to address application security concerns as soon as they appear. This is achieved by introducing application security as an integral piece of the software development life cycle (SDLC). A strong SAST solution enables developers to identify their coding mistakes and address them early in the process, thus reducing the costs of handling vulnerabilities at a later stage of the SDLC and eliminating the “cost of delay” caused by late detection of application security issues, which in many cases causes a project delay.
Beyond the educational advantage of learning how to code securely, developers actually start addressing vulnerabilities in the same way they address functional bugs, transforming an SDLC into a Secure-SDLC (sSDLC).
With all that said, just like physical security methods to sensitive locations (i.e. Airport or Bank) will employ multiple security measures including barriers, guards, authentication and more, application security should also be based on a defense-in-depth strategy.
At the end of the day, the goal should be to filter out the majority of risks as early as possible in the process and eliminate delivery delays due to last minute detection of security risks.
|An apple a day keeps the doctor away and a code scan a day keeps the hackers at bay.|