Who is Responsible for Security in Tech?

Are you an IT professional? Then you are.

I have been in software and application development for almost 2 decades, and I have seen a lot questionable security. Initially, it was due to a lack of awareness, and the ease of exploiting vulnerabilities. The race to get work completed eclipsed the consideration of how and why — if it was possible then it was done, regardless of the consequences.

Security has changed a lot since then, and I have spent time learning and researching elements of security in application development, and cyber security concepts based both on personal interest and professional responsibility. As a developer, I have been aware of cyber attacks, data breaches, vulnerabilities and threats since very early on in my career. In the present landscape of ransomware, malware and value of data, I feel that security is paramount in all development, and too often I am shocked at the level of knowledge (or lack thereof) in cyber security my peers have; reliance on other teams, departments or providers to perform security tasks is common and leads to introduced vulnerabilities in software development, and strain on resources required to mitigate them.

I recently discussed this at Sydney Modern Apps, and it highlighted a resistance between software developers and cyber security professionals. Security does not stop at software development — equally important are the processes in place within an organisation, as if these are vulnerable then they can lead to exposure. An example of this would be a lack of clarity or ownership on keeping systems patched — when this fails, then systems are left vulnerable to zero-day threats that can easily be mitigated.

Opinions that frameworks and platforms take care of security are not without some truth, but they still need to be configured correctly. A web application firewall can be used to mitigate a lot of attacks against web applications and public-facing APIs if used correctly, but it is not a silver bullet. It is all too easy to create vulnerabilities in applications through coding alone, allowing an attacker to exploit weaknesses and gain access to information or systems. Alone, perhaps, a single vulnerability does not present itself as a risk — it may seem innocuous enough to ignore or discard as the effort to mitigate it is not deemed a good use of resources, but if this is used in a chain to gain elevated access or to achieve information on systems or network topology that inform a larger attack, then the risk can be seen as greater than when isolated.

Known vulnerabilities are scored for their severity using the Common Vulnerability Scoring System (CVSS). This score gives a broad picture of the risk and can help prioritise required mitigations. Recently I was asked about why a vulnerability might have a change in score — presented with the frustration of dealing with security professionals that appeared to change their minds and subsequently the reposition of workload. Although this is frustrating, the reason may be due to the change in metrics or newly discovered threats, or possibly the change from the versions of CVSS used. It is important to understand that security is constantly changing as a reaction to the landscape — new vulnerabilities are discovered and remediated on a daily basis, and security professionals will need to pivot with it. When we start to question the advice we are given, then we need to evaluate whether we are in a position to do so — seeking advice in the first place might be an indicator that the knowledge and expertise is not available in-house. It is better, and recommended, to enquire further with your security professionals about what has brought on change, why there is increased perceived risk, and what steps can be taken, rather than ignore the advice as inconsistent and therefore incorrect.

Throughout my career I have experienced the reluctance to follow security advice, and the justifications that are created to allow us to feel comfortable doing so — I have been in the position myself before I learned about cyber security. It is often the easier path, which as you probably know is not always the correct path.

Security should be a part of development throughout the lifecycle, not just at the end, and it should be taken seriously.