Bug hunting is not a security research
Unfortunately, "security research" is commonly used to stand out a basic bug hunting work from others. There is a page on the majority companies/personal websites titled as security research, however, What you can usually end up seeing there is a list of published security advisories or reported security vulnerabilities often with proof-of-concepts and exploit codes. Here I just wanted to have a few words to point out what is research and what is not.
What is not research:
Looking at different public resources on the definition of "research", I found the following work has a good explanation on the differences between what research is and is not. Sharkawi from University of Washington says:
- it is not information gathering (e.g. google-ing is not act of research!)
- It is no reascending of facts (e.g. not doing a good literature review and doing/writing something on a known subject is not a research. This happens quite often in info-sec field. Have a look at these works Hijacking airplanes with an Android phone and Hacker + Airplanes = No Good Can Come Of This for example. All talking about similar topics (ATC, ADS-B) with no proper referencing to the original work.)
- It is not a sale pith (a new improvement in a product developed after years of research!)
What is research
Sharkawi continues on what the characteristics of a research work are:
- Originated with a new questions, idea or a problem with no acceptable solution
- Requires clear articulation of a goal
- Follows a specific plan of procedure
- Literature review and publication of findings in an acceptable form
Well I can't really see all/any of the above characteristics in what is called nowadays as security research. Lets be positive and try to find a way to describe the above characteristics in the current security research practices:
- Finding or exploiting a software bug is neither a new question, a new idea, nor a problem with no acceptable solution. It is about finding problem in someone else's code or finding a human mistake that typically happens because of time and budget limitation on software development.
- I don't really see a clear definition of a goal in any security advisories. Perhaps the goal is "To find coding mistakes in X though Y that result in Z!"
- Specific plan? Can you see flow of scientific process method in any of the security advisories? What I mean by that? Have a look at [1] it has simply 6 stages for any scientific procedure: hypothesis, deduction, predictions, observation, test of predictions, induction.
- Literature review! Tell me about it. There are so much plagiarism of both ideas and codes without any references what so ever!
Still insisting to call it a security research?
Then in this case we are going to have the following situation:
- Software bugs are research problems!
- Debuggers are virtual research labs.
- Software developers are scientific professors as in their daily job they deals with lots of research problems and scientifically fixing them!
- Patching software bugs is scientific research experiment.
Hope you get what I am going with this.
So, what to call it then?
Well I wanted to call it an engineering practice. But after do some reading articles like this I still do not see the steps involve in Engineering Design Practise in bug hunting:
- Define the Problem (What, Who, Why)
- Do Background Research
- Specify Requirements
- Create Alternative Solutions
- Choose the Best Solution
- Do Development Work
- Build a Prototype
- Test and Redesign
Overall the process involve in both engineering and scientific methods are more rigorous that finding software bugs. In a best case scenario, finding or exploiting security bugs (and not identifying coding mistakes!) is more of an engineering process. The process is to analyse and monitor a software operation via a not well defined method to discover a software bug or exploit a bug in different way.
That's for now!
References
- [1] Wilson, E. Bright. An Introduction to Scientific Research. McGraw-Hill. 1952.
- [2] M. A. Sharkawi. Research and Development. University of Washington. 2012.
- [3] Hackers get Schooled: Learning Lessons from Academia. (Panel discussion). ShmooCon 2013.
