Written by Dr. Anila Mjeda, Cyber Skills Lecturer

In Ancient Greek literature, Troy is portrayed as a powerful kingdom of the Heroic Age. Troy’s ability to withstand battles and attacks was due to the strength of its walls which, legend has it, were built by Greek gods, Poseidon and Apollo. This was all the more evident when Troy ‘fell’ after it’s supposed, impenetrable outer perimeter, got breached. 

This lesson from Greek Mythology echoes ever true in today’s software systems. Our Cyber Security mechanisms must be approached in a manner called ‘Defence-in-depth”, where a number of defence mechanisms are layered to offer better protection to the system. (Imagine the medieval castles’ layers of fine battlements, towers, and 'high' and 'steep' walls.) What is most vital in Cyber Security, is the inner most layer of a strong, defence-in-depth. This layer should start with secure coding which is a concept we call ‘Shifting Left’.

Shifting Left

Shifting left, in essence means incorporating security at the beginning of a project, such as data collecting, and incorporating security activities in each of the stages of the software development lifecycle. The shifting left metaphor stems from the fact that people whose native language is written from left to right, tend to perceive left (think of the outmost left on a page) as the place where one begins their work.

As a developer, will your application need to handle credit card data? Will the users of your application be allowed to upload their own files to the system, and which third-party components will you be using in the system? These are but a fraction of the security considerations to be analysed from the beginning of any project.

Today’s software systems are inherently interconnected, and we cannot simply draw up the bridge and defend our systems medieval style. Software systems use libraries, APIs, microservices and in general a variety of components that translate to an end-product. There are complex dependencies, many of which to third-party software. Furthermore, modern approaches such as Continuous Integration / Continuous Deployment (CI/CD) pipelines, Infrastructure as Code (IaC), Security as Code (SaC), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS) push more functionality into the software domain.

This blurring of the boundaries means that security is not the job of only the security professionals and calls for the development team to play a crucial role in it.

Software developers are talented and inventive creators and as cyber-attacks increase in numbers and severity, it is vital they collaborate closely with the security professionals and get the proper training to interweave security into their creations. While proper training of developers is the real answer to prevent vulnerabilities creeping up into our apps, if I were to start from one element, it would be the mentality of Zero-Trust. While I do not recommend it as a mentality for life, I do very much recommend it in all thing's cybersecurity. The Zero-Trust concept extends from infrastructure to software. In fact, one aspect of our software which if we do right, would solve most of our security woes is zero-trusting all inputs. 

Zero-Trust Your Inputs

Language purists might forgive this conversion of zero-trust into a verb, on the grounds that placing no trust on all inputs (even when they come from your own system), would help us mitigate most of our security troubles.

You may be asking, “Why don't we just do it then, and “solve” security once and for all?”. Part of the difficulty relies on identifying every single input.

Did we identify all the cloud workflows that can trigger our serverless functions? Are there any unforeseen ways into our database (Hello injection vulnerabilities)? Can an attacker give instructions to the server and resultantly gain access they should not have (Server-Side Request Forgery (SSRF) vulnerabilities)? Can our web-based system be commandeered to attack our legitimate users (Cross Site Scripting (XSS) vulnerabilities)? -- are but a few of the possible attacks where the proper handling of inputs would go a long way to make our systems secure.

If you are starting your journey into secure coding and zero-trusting your inputs, I would strongly encourage you to learn more about input validation and output encoding. To get you started, brief explanations of whitelisting, validating, output encoding, and escaping are given in the text box below:

 

Troy may have fallen in the Trojan War but in the digital age we can make our security ‘walls’ that of their own legends.