This is the first in a series of blog posts around my growing and developing thoughts about security in the Quality and Testing space. This writing will, I hope, explore some of my learning, discoveries, experiences and frustrations with testing and quality processes and organisations with regard to security.
It is my long term aim that these blogs (with some work) will eventually become some sort of book, guide or learning resource to those who are interested in developing their security testing skills, and discovering more about how to incorporate this thinking into their work as testers, and other technology focussed roles.
I will be focusing on areas such as security testing strategy, risk and threat modelling, incorporating security testing and mitigation techniques into your day to day work, use of tools, and training materials amongst other topics…all under the banner of Exploring Security. You could consider it a manifesto of sorts, if you like.
Firstly, I would like to illustrate a few problems, as I see them at the moment.
Balancing security with other concerns
Security is important. VERY IMPORTANT. However it isn’t the only concern for businesses and technical teams. Developing and testing for security is often seen as a risk to delivery of products and services. Whether that is in terms of time to market concerns, return on investment, legal and compliance issues, security should always be considered as part of the design process. Within many industries, especially those involved with safety, defence, finance, medical and pharma tech all have specific regulations and compliances that must be observed, including with regard to application and infrastructure security.
Equally, any organisation or company that handles personal or other sensitive data is required to ensure that data is handled appropriately under various laws. The EU and it’s signatories have signed up to GDPR for example. This governs the management and handling of data. Breach of its rules can lead to severe financial and legal penalties.
However, striking a balance between the various legal and ethical responsibilities and other business imperatives can be difficult. Security, like accessibility, usability and functionality is part of that balance. An application that works beautifully, and serves its users well is great, but the data held by the application is at risk to attack and exploitation then there is an imbalance. Equally, if security is so draconian that it makes applications and services unusable, then you will not serve your users well.
Infrastructure vs Application Security
I feel that there is a dangerous assumption that infrastructure security provisions and mitigations can solely be used to protect applications that are hosted on that infrastructure.
It’s important to protect both the infrastructure that applications are hosted on, and the application code and services itself. Without both, applications will potentially be at risk to a variety of exploits. Potential hackers will use any route to undermine and exploit your systems, and will use the easiest route they can find to do so. Don’t make it easy for them.
Employing defence in depth and in breadth is always the best policy. An attack against poor infrastructure could for example result in a denial of service. An attack against poor application security could result in attacks such as SQLi (SQL Injection). Both approaches should be used in consort.
This blog series also serves as a way for me to redevelop my skills of focus, concentration and learning, especially in community engagement, communication, technical skills and workplace problem solving. I have been keeping my community engagement to almost negative values during my father’s recent poor health, and subsequent passing in November 2019. I hope you will be seeing quite a bit more from me in 2020, if in a slightly different form.
I hope this serves as an exciting taster of what will be coming in the future. If you would like to contribute to this series in any way, through comment, collaboration and discussion, please let me know.