Memoirs of a Security Tester
Memoirs of a Security Tester
Author: Jouni Hiltunen, Senior Specialist, Bittium
I have had the pleasure of working at Bittium for five years and most of the time I have been involved in security testing of Bittium Tough Mobile product family. In this blog I will shed some light on my thoughts and experiences along the journey.
Fighting Against the Evil
One of the most inspiring factors when working in the field of cyber security is that I can be one of the good guys fighting against the bad guys. Well, that was what I thought back in the day as apprentice. Nowadays, I rarely think about it. Maybe the adversary is just not that concrete in my everyday work.
My background is in cyber security research where the perceived threats are sometimes quite abstract. I never had to face a real adversary. The threats became more immediate when I moved into product security. I was now protecting concrete products and real end users! However, even when the impact of the work became more concrete, the faceless adversary is still out there somewhere behind the curtain of news and statistics. But maybe that is a privilege that should be more appreciated. I´m sitting comfortably in the office while keeping a safe mental and physical distance to the crooks.
Couple of times I had to take a step towards the frontline and participate in incident response investigations but typically even in those cases the evil is dressed up as nice looking (although malicious) app that is coded probably by a hard working father earning some money for the family in a nine-to-five job in a malware factory. I guess the better we, the defenders, do our jobs, less we are visible and can stay far from the frontline.
The Most Challenging Job in Tech Industry?
Luckily, there are plenty of other motivating factors in security testing. Dan Geer, one of the most interesting icons in cyber security, has said: “…cyber security is the most intellectually demanding occupation on the planet.” [1] He might well be biased and world might have changed since that statement but he certainly has a point when considering the rate of change in technologies, evolution of cybercrime and espionage as well as risk management based on unknown capabilities of adversaries, to name a few. Given the breadth of a smartphone attack surface (e.g. complexity of the operating system and variety of input interfaces) and rate of change in mobile ecosystem, the challenge is obvious when protecting a secure smart phone such as Tough Mobile.
Cyber security is indeed fast paced as the tsunami of daily security related news manifests. One excellent news feed I follow is one from the Finnish National Cyber Security Centre but keeping up even with that particular feed is challenging if one does not dedicate some time every day for it. It’s also important to follow latest developments in vulnerability research, exploit tactics and security tools. Sometimes even the news related to politics and legislation may have influence over security testing.
The challenge is also obvious when one is hunting for the unknown. As Dan Geer put it when comparing quality assurance with security testing: “…the idea is not ‘Does the product do what it is supposed to do?’ but rather ‘Does the product not do what it supposed to not do?'” [2]. This is an open-ended question in which no certain answer can be given.
The Existential Question
Another grand old man of cyber security Bruce Schneier has asked a question: “Are vulnerabilities in software dense or sparse?”. This is actually the existential question for security testing – question of whether testing and patching matters. If the vulnerabilities are dense, let´s say there are thousands of them, it doesn’t make a difference to find and patch ten vulnerabilities since the product will still be effectively vulnerable (given that the vulnerabilities have equal severity).
We could come up with a metric to solve this dilemma. For instance, a metric that tells us how many bugs there are per million lines of code, how many of these bugs cause security issues and how many of these vulnerabilities are exploitable in a given threat scenario. However, measuring such a metric is possible only in retrospect.
Whatever the truth is, one can always dodge this dilemma by taking account the general goal of defensive security which aims at increasing the costs for the adversary so that the attacking is not worth the effort. Each patched vulnerability in the product means a less chance for attacker to find one. This is one of the ways to give meaning to one’s work given the uncertainties.
I’m delighted to see that in the big picture the security testing can make a difference. For instance, Android operating system has introduced additional mitigations strategies (better access control, attack surface reduction, architectural decomposition) especially to parts of the system that suffered from vulnerabilities the most such as the media framework.
Let´s Get Paranoid
Another profound question one has to ask, when approaching a new test target is: “Trust or not to trust?”. The information asymmetry (capabilities and knowledge possessed by each party are not public) between players in the field of security lays a fruitful ground to myths and plain paranoia. However, the reality is, given the complexity of today´s technologies, there are always some things that have to be taken as ground truths.
Let’s take cryptography, for instance. Virtually all communication technologies rely on standardized cryptographic algorithms. In practice only computationally secure (it cannot be broken within a reasonable amount of time using reasonable resources such as budget, energy, and so on) algorithms are used. We trust that the standardization process ensures that the approved algorithms are subject to a close scrutiny conducted by several independent experts so that no one has a significant advantage of breaking the algorithms.
To fuel the conspiracy theories, the documents leaked by Edward Snowden, suggests that such conspiring has taken place in a standardized cryptographically secure pseudorandom number generator called Dual Elliptic Curve Deterministic Random Bit Generator. Although this algorithm was included in an internationally acclaimed standardization body´s lists of approved algorithms from 2006 to 2014, its’ weaknesses were known and publicly criticized. This example illustrates the importance of keeping up with the security scene, doing background research and maintaining a healthy level of paranoia when making trust based decisions
Business, as usual
No matter how intriguing the myths and conspiracy theories related to security testing might be, the scarce security testing resources stipulate pragmatism and business-driven approaches. In fact, a thing that came by surprise when I started doing product security is the diversity of sources that would guide the testing. For instance, given that Common Criteria and national security certifications are important for Tough Mobile customers, it´s important to support the evaluations and ensure that the penetration tests done by external laboratories are completed smoothly.
Prioritizing security testing based on threats is quite easy, theoretically. Just take the standard risk model, which states that the risk is equal to the likelihood (chance of a particular threat to happen) times the impact (severity of the consequences if the particular threat happens). However, one soon finds oneself wondering how to calculate the amount of likelihood and impact. DREAD, a popular mnemonic, could help in this task. It stands for Damage (how big would the damage be if the attack succeeded?), Reproducibility (how easy is it to reproduce an attack to work?), Exploitability (how much time, effort, and expertise is needed to exploit the threat?), Affected users (if a threat were exploited, what percentage of users would be affected?) and Discoverability (how easy is it for an attacker to discover this threat?). However, finding quantitative answers to these questions in practice requires a lot of imagination to estimate the unknown factors. This makes the prioritizing more of an art than an engineering task, especially if it is to be done is a reasonable time.
Different Shades of Grey
It has become already apparent that threats are not black and white but they have different shades of grey depending on which angle you look at them and who is looking. Therefore, some blunt facts are needed to tip the scales. What is the role of the test target in overall security posture? How are the customers using it and what are the governing security policies? What is the testing effort needed based on available resources and expertise? If there is a vulnerability found, can we mitigate it? Is there going to be code refactoring or design changes for the target in the near future? Can the testing be automated? What is the history of the tested code base and will it be maintained? What are the trends in vulnerability research? [3]
There seems to be a lot of work even before the actual testing can be started. So usually one has to increase contrast instead of defining the exact shade of grey. But none the less, defining the purpose of the testing is paramount since the persistent tester might put their whole soul in the search of the unknown.
From Black Box…
In addition of product security, I have been doing penetration and security testing for external networks and devices. It is usually done as black box (no prior information on the target) or gray box testing (some information e.g. architecture documents are used as prior information). Discovering information on the target (what technologies are used, how it is configured, what are the protected assets and even sometimes hints of the mind of the creators) through reverse-engineering and reconnaissance is exciting by its own right.
But this approach is even more open-ended than white box security testing (where you have the details of the most parts of the implementation available). Since it’s hard to figure out how well you have done your job, e.g. in terms of test coverage, there is a constant pressure to complete the testing “honorably”, e.g. by finding a critical vulnerability on the target. On the other hand this pressure is the fuel that could make one to push over the limits.
..to White Box
White box testing is a different ball game, but the lessons learned from black box testing are also valuable. For example, the white box targets tend nowadays be a mess of complex frameworks, build environments and interrelated dependencies. Therefore, sometimes even some basic parts of the code do not work as expected which can be discovered through a black box testing type of poking.
When I started doing product security it was no surprise how much more efficient the white box approach was. However, it did not mean that the testing could be done in less time although the same coverage could be achieved faster. When playing with open cards, there are also higher expectations for “honorable´ outcome. When the code is available to scrutiny, new testing techniques and tools such as source code auditing and static and dynamic code analysis are apparent. Fuzz testing (a testing technique using invalid, unexpected, or random data as inputs), which is also a crucial part of black box testers arsenal, could be utilized more efficiently through instrumentations that enable faster and coverage guided fuzzing as well as sanitizers that would reveal security issues that otherwise would be unnoticed.
Testing tools used in black box testing, such as vulnerability scanners, network traffic analysis and attack tools and Android application security scanners, are also valuable. One could in theory just rely on those tools (and related checklists) but usually the targets are so unique that the tools do not cover all the relevant aspects. Therefore, security testing is not always about breaking things but also about creating right tools for the job.
Enjoying the Journey
The security testing has been an enjoyable journey for me. Although the excitement of finding new vulnerabilities is still there after the years, the mix of learning new, challenge of open-ended questions, profound pondering mixed with myth and unknowns, pragmatism and co-operation makes the journey most enjoyable.
Well, that’s a lot of topics that would deserve more pondering. But now I have to leave you with another quote from Dan Geer: “There is never enough time. Thank you for yours.”
[1] Dan Geer, Trends in Cyber Security, keynote address for the National Reconnaissance Office at its Planning Conference, Nov 2013, http://geer.tinho.net/geer.nro.6xi13.txt
[2] Dan Geer, The Art of Software Security Testing, Wysopal C, Dai Zovi D, Nelson L, & Dustin E, Symantec Press, 2007
[3] Lillian Ablon & Andy Bogart, “Zero Days, Thousands of Nights The Life and Times of Zero-Day, Vulnerabilities and Their Exploits´, 2017: “Since it was known that Stuxnet exploited font vulnerabilities, bunch of researcher dig into font vulnerabilities which resulted extinction of whole bug class.”
Jouni Hiltunen, Senior Specialist, Bittium
Jouni Hiltunen is a passionate information security professional who has several years of experience as a research scientist including research team leading and project management. Since 2016, he has contributed to Bittium’s product security as a software security tester and test manager as well as a security product manager. Jouni has written multiple scientific publications, and is a Certified Ethical Hacker who enjoys bug bounty hunting and internet vulnerability research in his spare time.
