Introduction
I found this module quite challenging as the topic was completely new to me. I entered the module with almost no knowledge of how networks work, or information data transfer protocols, and an extremely limited exposure to penetration testing and ethical hacking. The module was split into three distinct parts (for me at least).
Part 1
The first focussed on the TCP/IP and OSI models of networking and how data was transferred between nodes on a network. The information was a little dry, but I found it fascinating that so many of us use the internet without any real idea of how it actually works.
Part 2
The second part introduced the topics of security and a number of tools used for gathering information about websites and web applications. It was here that I learned about Microsoft's widely used threat classification framework STRIDE and vulnerability measurement scale DREAD. Having a means to put a numerical value on the severity of a threat or vulnerability allows a user to compare vulnerabilities and threats and make informed business decisions about which vulnerabilities they should address and in what priority. I was introduced to the idea of vulnerabilities that are deemed unnecessary to address, ones whose impact was so minimal that it wasn’t worth the effort to mitigate against them.
We also learned a lot about security legislation and standards like GDPR for personal data collection and storage and PCI DSS for criteria that systems which accept card payments must meet. This will be particularly useful to me in my current position as a Software Engineer at a UK based software company which creates cloud-based financial management software. I was aware of the existence of GDPR before the module began but the learning materials, and particularly the executive summary of our pen-testing findings enabled me to discover many of the details in the legislation and the steps a web application designer/owner should take in order to meet the legislation and provide wits users with fully transparent collection and storage policies.
Part 3
An article we read in unit 6 introduced a number of widely used pen-testing tools which are used for gathering information about targets and vulnerability analysis. This was the start of what I think of as part three of the module - learning about practical penetration testing tools and how to use them. I discovered that the Kali Linux operating system comes with the mentioned tools pre-installed, and so downloaded and installed it on an SSD drive that I could plug into my Windows laptop.
I really enjoyed learning about the new tools and downloaded a well-known instructional application called the Damn Vulnerable Web Application to practice my skills on. It was great to run the tools against the application knowing that you should be able to find particular vulnerabilities like sql injection and cross-site scripting opportunities. The knowledge that the vulnerabilities were there and just needed to be discovered meant that I could tell if I was using the tool correctly and interpreting the results accurately or not.
Summative Assessments
There were two summative assessments, the first of which required that we test design a testing plan and strategy, and then in assignment 2, implement the plan and provide an executive summary of our results.
The first assignment was practical and introduced us to the idea of a pen-testing plan, following prescribed and well-defined methodologies and techniques when testing rather than firing random shots in the dark. Our team collaborated well, split the work evenly and met regularly to share our progress and draft and redraft our plan. This was shown in our feedback for the assignment which was overwhelmingly positive and resulted in a distinction.
Our team encountered a number of difficulties in the second half of the module. First, we discovered that the target website for our tests had a very secure system, and we each had our IP addresses blocked from accessing the site on a number of occasions. This resulted in a couple of weeks where none of the team could access the site and we were frustrated not to be able to make progress with the assignment. We did manage to find a way around this problem by using a Tor proxy server which masked our IP address and effectively gave us a new one each time we accessed the site.
Following that, we were informed that one of the team had withdrawn from the module, and another of our members tested positive for Covid and then had surgery followed by a period of recuperation. This put us under quite a bit of pressure to conclude the testing plan in a timely manner, and together with the difficulties accessing the target site, really damaged my motivation and negatively affected my interaction with the module materials.
We eventually pulled together towards the end of the module to finish the executive summary, but I found myself getting frustrated when the work I was doing on the report was ignored, overlooked, or edited. It seemed that nothing I contributed was deemed of sufficient quality for one very demanding team mate.
Conclusion
Overall, I learnt a lot about network security and pen-testing tools in this module, adn really look forward to the opportunity to extend my knowledge and capabilities with further practice on the DVWA. I also learned that teams really need a JIRA board to manage the workload effectively and assign the workload evenly. In future, on team-based assignments, I intend to have a back-up plan in case of unforeseen circumstances. I will also strive to maintain my motivation in the face of challenging behaviour from team-mates, ensuring that my voice and the voices of others on the team are all given equal weight and importance. To be honest, being part of a dysfunctional team has opened my eyes a little and will help me prepare for any eventuality on future team projects at the university or in my workplace.
