Unit 2

Learning Outcomes Achieved

1. Identify & manage security risks as part of a software development project
2. Critically analyse development problems and determine appropriate methodologies, tools and techniques to solve them

Blog Post

The blog post was a useful exercise in writing concisely, and the requirement of using 5 different ISO/IEC 27000 terms improved my communication skills. I was initially concerned that using many keywords would make my points harder to understand, however, I learned that the opposite is true. After rereading my blog post and the posts of my peers, I realized that the usage of keywords saved a lot of space in terms of word count, while maintaining clarity. An additional, yet impactful benefit, is that it made the writing of all the blog articles appear more consistent (even though the authors were different), making all of the posts much easier to follow. Of course, knowing the actual meaning behind the words is a prerequisite, however, the benefits are immediately experienced thereafter.

After coming to this understanding, I have decided to change my approach to communication when working with more technical audiences. In the design document, I intend to focus on using clear, technical terms. I will also encourage my group to do the same- by doing this, the quality of the document will improve because definitions will be unambiguous and clear, the wordcount will be easier to manage, and finally, the use of technical language will cause the writing to appear more uniform even though the document is being written by a team with different styles of writing.

After posting my article, I received the following feedback from my tutor:

Hi Shan,

I agree that the notion of trust is so important in faciliating a security-aware and security-compliant environment. While we can enforce that employees complete security training, this may be done as more of a ‘tick-box’ exercise than anything else. The fact of employee ‘buy-in’ needs to also take place, and responsibility. ‘Mindless compliance’ - this is an interesting concept related to this. Behaviour analysis can really help to support this, Shan, I agree. I would be very interested to understand what can be done once behaviours are understood - perhaps this could make for a relevant dissertation topic, as I can imagine there are multiple perspectives to research in relation to this.

Cathryn

I found this to be a really useful response, especially the suggestion of selecting it as a dissertation topic. I have begun thinking about what to do my dissertation on, though finding a good topic appears to be a skill in, and of itself. I began searching for resources to better understand the necessity of relevance and multiple perspectives, thereby determining why “mindless compliance” is a solid topic to consider, but due to time constraints, I was not able to find good resources- most were niche and related to specific fields (such as business). That said, I did discover certain terms that should be researched at a later date. From my searches on Google Scholar, I found that a lot of academic works use the term “research gaps”, “relevance”, and “missing perspectives”. When time allows, I aim to revisit these terms.

Overall, this exercise helped me achieve learning outcome 1, because the list of terms showed me new areas that I should consider when creating secure software or securing an organization. For example, I was unaware of the terms “residual risk”, “information security continuity”, and “control objectives”. Learning these terms has changed my perspective on security because they indicate the importance of implementing ongoing security management efforts. Although a key component of security is addressing specific problems with concrete steps (e.g. installing patches for vulnerabilities), it is just as important to ensure that procedures and practices are put into place which are useful in general. Deloitte (n.d.) recommends both of the aforementioned approaches.

Artefact

Link to blog post

Unit Reading

For me, the most influential article in the reading list was the article written by Dadzie (2005). What the article makes clear, is that software patching is not just about the act of patching itself, but also minimizing the associated risks caused by updating and deploying a new application. As the author explains, competing priorities (e.g. release schedules and the severity of a vulnerability) can force developers to make suboptimal choices for the sake of faster response, and these suboptimal choices can harm the customer’s ability to prevent attacks. Although the article is from 2005, this notion still holds true- a very recent example of this is how Microsoft issued a temporary workaround for a critical vulnerability, while working on a patch (Ilascu, 2021). The workaround provided requires manual effort and some prerequisite knowledge, which may necessitate a Systems Administrator or IT specialist, making the temporary solution less accessible to companies that do not employ the relevant employees.

After reading the article, from the perspective of someone wanting to develop secure software, the key lesson I took away is that structure is important for improving overall application security. Structure, in my understanding, and in this context, refers to (potentially automated) systems and controls that serve software development and deployment processes. One example of structure, as suggested in the article, could be having some logging system which sends data to a server regarding a computer’s patch installation. Having structure to support patching at various steps in the process, allows the process to become more scalable, and the guarantees provided by automation improve the overall security and reliability of the system. In my own work, I would like to start applying this knowledge by assessing the patching process within the context of the product that I work on. Areas such as these have a clear situational component, however, knowing which areas to assess (e.g. risk of regression, the amount of software using the problematic code, and so on), is crucial. Therefore, contextualizing the matter before creating structure, is a better option.

Through this reflection, I have achieved learning outcomes 1 and 2 because I have discovered a new area of risk in terms of software security, and in addition, I have learned which areas to assess when looking at a patching system, and how to assess those areas (i.e. contextually), in order to find flaws and solve them.

Peer Responses

As part of the collaborative discussion, students were required to provide peer feedback on two others’ diagrams. After reading the various replies made by my fellow students, a noteworthy observation I made was that advanced UML notations become a necessity when complex workflows need to be represented. The diagram created by Smirnov (2021) is a great exmaple of this. The process which he represented required a detailed explanation, as it included actions such as waiting, early termination, and processing a collection of elements. Based on my experience, effective UML activity diagrams are able to display detail without losing clarity, and using advanced notations to add more detail is a means of doing this. However, Ambler (2005) argues that lesser-known notations should be used sparingly because individuals can vary in their understanding of UML. Ambler further suggests to provide a legend describing any unique notations used. I agree with this suggestion, and in future, I would like to add legends to my diagrams to maintain both clarity and detail. However, before I would be able to do so, I would need to develop a better sense of judgement regarding which symbols might be seen as advanced.

The content of the responses improved my critical thinking regarding vulnerabilities. I found that a common theme across all responses was the concept of assumptions. As the focus of discussion was discussing the root cause of a vulnerability, a key area to consider is the assumptions made. One example is in the post made by Edgell (2021)- the vulnerability discussed was the usage of weak passwords, however the existence of the vulnerability is contingent on the ability for an attacker to obtain email addresses that can be used. This was pointed out by the professor, and I found another discussion which also had behavior contingent on assumptions- namely, the assumption made that an attacker could have long-standing access to a compromised system (Obayemi, 2021). These discussions showed me the importance of clarity and awareness when describing an attack scenario: because assumptions are not constant (by nature), attempting to resolve a vulnerability based on an unseen assumption would mean that resolution becomes situationally effective, as opposed to generally effective. An awareness of assumptions made in security helps temper expectations, and in addition, encourages discussion of situations that would not be covered by a certain measure implemented.

Through this exercise, I have achieved learning outcome 2, because I learned how hidden assumptions can influence the effectiveness of secure software development.

Artefact

Link to feedback given Link to feedback given

Link to feedback received

References

Ambler, S. (2005) The Elements of UML 2.0 Style.

Dadzie, J. (2005) Understanding Software Patching. Web: IEEE.

Deloitte. (n.d.) Five essential steps to improve cybersecurity. Web: Deloitte.

Ilascu, I. (2021) Microsoft shares temp fix for ongoing Office 365 zero-day attacks. Available from: https://www.bleepingcomputer.com/news/security/microsoft-shares-temp-fix-for-ongoing-office-365-zero-day-attacks/ [Accessed 8 September 2021].