(Warning: A slightly long read. I have wanted to write about doctrine for the longest of times, but I decided to weave in some of my personal musings about other areas of cybersecurity as well, that are related to doctrine. The result is a long story.)
Introduction: The Thought on Business
A number of friends I have spoken to in recent weeks have expressed ideas of running their own business. These range from half-joking thoughts of setting up their own “florist shops” to sacking their bosses so that they could become the boss themselves.
I did not think myself of becoming a business person in my growing-up years. The closest to an entrepreneural idea then was to set up a tuition centre because the business model behind such a centre was direct — simply encourage the parents that they needed to “one-up” the competition so that they would have a brighter future when sitting for key national examinations. Some friends would probably have heard of me opining that tuiton centre owners are among the most agile of businessmen; a change in syllabus or examination format would be met almost immediately with a new class or advertisement highlighting new classes or pedagogies the tuition centre would adopt. One minister even quipped that tuition centres would offer rock-climbing tuition if the scholarship admission criteria for the PSC included a rock climbing segment in it!
Philosophical Thoughts on Value Creation
In recent months, I have changed my mind slightly about my perspective towards business. At the heart of a business is its ability to create value in some sort of area. Even something morally reprehensible like the promotion of a gambling website arguably provides value for its consumers; its consumers are willing to put in money in exchange for the entertainment and stimulation it provides them (this excludes the stimulation thrust upon them through sleepless nights should they borrow too much money from the loansharks).
My work as a cybersecurity professional allows me to enjoy its technicalities in all its glory. I still remembered the joy I felt in popping my first reverse shell on an engagement. To penetration testers, arbitrary command execution is often the goal they seek to achieve in an engagement, through exploitation of a vulnerability, or a chain of vulnerabilities. Being able to obtain a reverse shell allows penetration testers to take over a system, which shows their success at their objective. The technical aspect of the job kept me rather happy for a while.
However, a more philosophical question began to take root. With enough time for vulnerability research in an engagment, I could make an application look horribly written, as if the developers paid no heed at all to secure coding principles. But what was the point in all of those reverse shells, if no one could see the value of the engagement beyond project managers and developers lamenting that “the cybersecurity auditors are at it again, slowing everyone down?”. This extends to almost anywhere where cybersecurity doctrine has taken root in some shape and form.
Looking at Web Applications: The Good, the Bad and the Ugly of Doctrine
According to OWASP Foundation, they highlight four main activities that are instrumental in securing web applications. These are:
- Automatic vulnerability assessment scanners (e.g. Burpsuite Pro, Core Impact)
- Manual penetration testing (e.g. procuring the services of a company like Offensive Security)
- Automatic code review (e.g. using a tool like HP Fortify; tools exist for both static application software testing and dynamic application software testing, also known as SAST and DAST)
- Manual code review (such as what I’m learning right now through the Advanced Web Application and Exploitation course)
Often, in a mature institution, these processes are put in place into doctrine for compliance as part of a framework to assess the security posture of web applications. There is the good, the bad and ugly of this.
The good: Having standards is good for the industry. Standardisation allows for us to have a minimum baseline of security practices and standards that all application testers need to know to be deemed as a professional in the field. Web application testers must understand the OWASP Top 10 and know how to, at the minimum, be able to test for elementary cases of each of those classes of vulnerabilities. Without a common baseline, it is almost impossible to have a common ground to do make further constructive dialogue on any sort of web application security topic.
The bad: Doctrine is good only if it does not overly hinder others. No one enjoys a process that becomes the limiting factor in project delivery. Project managers need to factor in roadblocks that may introduce project risks. These can include cybersecurity risks arising from insecure components being delivered as part of the solution, potentially compromising confidentiality, integrity and availability of a system as part of the project. However, project managers are also extremely worried about schedule delays. These can arise from security assessments that cannot be finished on time. No project manager enjoys waiting for months just for a security assessment to be cleared, especially when there exists an impasse between the security team and project delivery team.
At a project management level, resolving of such issues is often possible if the project managers have technical competency to understand security risks that may affect a project’s delivery. Project managers, at their core, focus on project delivery and risk management. With technical competency, the bad can still be mitigated somewhat.
The ugly: Many cybersecurity professionals (the ones who take pride in what they do) are very passionnate about their job, no matter which domains they may specialise in. Some are perfectionist even though they are also aware that security is never a 100% certainty, but in fact, at macroscopic levels, a probabilistic issue with incomplete information almost all the time (this is why risk management exists to begin with!). What we have a very low tolerance for is how doctrine is skirted such that compliance is achieved, but not in the spirit of cybersecurity best practices.
One such example is in the “penetration test“. A penetration test can vary widely in scope, and is almost impossible to specify a minimum baseline for this, as software implementations permeate many different industries with different needs and priorities. This means that the penetration testing engagement with different industries can differ considerably in scope, given the different risk tolerances for various issues that can arise from a penetration test. For example, an institution running power plants would certainly prioritise availability above confidentiality and integrity as a power grid knock-out would be instantly felt, giving rise to immediate business impact. The ugliness begins once the objective of these security activities shift from a value-creation prospect (improvement of security posture) to a process-level requirement (compliance). Once the motivations of a security assessment are adjusted, so will the attitudes towards security. Unlike in the safety and auditing domains, where extremely clear standards are being put forth with little room for deviation from such requirements, very few industries have mature enough cybersecurity governance, awareness and understanding of the business value cybersecurity activities bring about.
The “Irrational Human”, Once Again?
Security professionals harp on stories of massive data breaches and security compromises to no end. In fact, many of us are walking encyclopedias of the largest cyber attacks, such as Equifax and the Mirai botnet attacks. It should be obvious that anyone who dabbles in cybersecurity risk should be more enthusiastic about understanding the impact of cybersecurity on business, isn’t it?
In a process-driven world, that is not true. Where do cybersecurity activities currently rank on a P&L statement? Cybersecurity is a cost. From a project manager’s perspective, cost is a factor that should be managed. Moreover, unlike direct costs such as material and manpower towards the project objective, cybersecurity does not directly contribute to a project objective. It is a risk mitigation function.
In a world without safety governance or safety frameworks, it is plausible that an unethical company will ignore safety costs in the interests of cost-cutting. The same applies to cybersecurity, unfortunately, because of the probabilistic nature of incidents. We often grossly mis-estimate statistical outcomes. Project managers who have to manage these risks also find it difficult to articulate accurately to management these statistical risks, especially if they lack technical competency in these domains. Hence, it is not entirely fair to dump the blame on humans and to call them “irrational”. There’s no point in re-iterating a tautology that we are terrible at probability.
Why All That Introduction on Business?
Cybersecurity exists to help the business or operation of an enterprise. No business or operations exist? No cybersecurity required either, since there is nothing to support. When looking at doctrine, it is important to not fall into the short-sighted vision of “technical compliance”. Compliance can mean anything from merely following the rules to following the spirit of the rules whenever possible. It’s grey even though it sounds like a binary issue of compliance or non-compliance.
Because of the direct ties to business, cybersecurity professionals need to articulate the value proposition of proper cybersecurity work. This often means transcending the technical domain which we are familiar with to the language of business people; business people discuss risk likelihood, risk impact, value, and bottomline. The translation from technical parlance to business jargon requires a deep understanding of both technology and business roles.
What I personally think is lacking, at least among peers in my age range, is the enthusiasm in being the bridge across technical and business units. This is understandable; many aspiring cybersecurity professionals started being interested in the world of cybersecurity because they could break and reconstruct software and hardware. Like me, they would find great joy in obtaining shells to control servers, and not find much joy in creating risk matrices and convincing project stakeholders about the value proposition cybersecurity brings to an enterprise.
This is certainly not a lost cause. The very fact that joy can be sparked through arbitrary control of computer components they do not own should suggest that we can sell the story of impact. This means that cybersecurity professionals must also know how to be salesmen. In any argument on value proposition, what counts in business is solutions. Besides merely articulating impact, cybersecurity professionals must also be keenly aware on solving these issues. While remediation may not be glamorous and is often painful, teaching others how to build and develop better is generating value, as opposed to simply destroying systems and leaving ruins in the cybersecurity professional’s wake.
A Last Warning About the Ugly
I will return to the “ugly” in the “good”, “bad” and “ugly” because I have a few more remarks to make about perversion of doctrine. Unfortunately, just like in any industry, there will be firms that claim to be “good, cheap and fast”. Refer them to this GIF for the optimistic view. I think we sometimes cannot even get two of the “good, cheap and fast” trio! Considering the nature of depth required for thorough cybersecurity work, it is extremely unlikely for us to do this quickly or cheaply.
But how do we know if firms are selling snake oil that meets compliance standards without delivering any sort of value? Well, this is why you have cybersecurity friends and colleagues to turn to for advice! Cybersecurity professionals are very nice, and most of us are white hats. We don’t hack you just for fun or malice; we really want to help make cyberspace safer for everyone. Examples of these? Look at how the security community comes together for bug bounties such as those offered by HackerOne, or look for one of the many security enthusiast communities; some of them offer general talks that are suitable for laypersons to find out more.
Next post will probably be on my AWAE journey.