Nism Unit 2

Group Discussions

This week, we focused on aligning our schedules. The team is distributed over 3 timezones, so discussions were had over Discord regarding what schedule to use. Eventually, we were able to come to an arrangement, deciding to meet on Sundays at 2pm BST. I also wanted to have midweek standups done via a voice call, but it would not be possible to have everyone join a call during a weekday, so I thereafter suggested doing a standup via text posting. Voice calls for standups are beneficial because blockers can be resolved instantly, and in my research for finding an alternative, I found that asyncrhonous communication can negatively influence coordination (Ahmad et al., 2018). As a result, I think it’ll be worthwhile to make sure the Sunday discussions are longer so that tasks are easier to complete during the week. I’ll also keep looking for other research to improve team cohesion.

Seminar Session- STRIDE and DREAD Tools

A task given this week, as part of the seminar, was to evaluate our posts within the context of the STRIDE and DREAD framework created by Microsoft. My approach to this task is viewable in the Document Links section.

Reflections

My main intention during this unit was to work on my analytical and critical thinking skills for the peer responses.

Learning about the STRIDE and DREAD tools was useful. What I like about the tools is that they make it very easy to organize one’s thinking regarding threats. Assigning points makes it very easy to analyze a threat in detail- as an example, from the DREAD analysis done, I can conclude that denial of service attacks and brute force attacks are dangerous because they have a low bar to entry, and in the case of a brute force attack, can lead to larger compromises across networks. The steps are repeatable, require no adjustment, and details are freely available online.

I aim to apply this type of analysis to my own work, especially when considering deployments. I often have to create new deployments on my company’s infrastructure, and sometimes this can include using Docker images. Because Docker images contain operating systems, they can become mechanisms for compromise. Being able to assess container vulnerabilities in terms of STRIDE and DREAD would make it easier for me to select secure containers when creating a new deployment.

As an example of how I might apply this, I might need to create a new microservice deployment based on a java image. Using the docker scan command would provide me with vulnerabilities on the image, but I could use STRIDE/DREAD to determine whether the vulnerabilities require concern or not. For instance, the image might contain an obscure buffer overflow vulnerability that requires specific timings to successfully exploit. This would have a low DREAD score since a successful exploit might only cause the container to restart, and would require a lot of in-depth knowledge to exploit. Comparatively, a container might contain an information leak (category I in STRIDE), which has a high DREAD score because it’s easy to replicate and affects all users, even if the information leaked is somewhat inconsequential. Trivial information leakage at scale could give an attacker an advantage when attempting to find vulnerabilities, making it important to address this, and this insight can be gained directly from DREAD analysis.

As shown above, the given frameworks make it much easier for me to apply network security because of the structure that they provide, so I look forward to applying it to my work.

Document Links

Peer Responses
Seminar 1 Preparation- STRIDE and DREAD Tools

References

Ahmad, M., Lenarduzzi, V., Oivo, M. & Taibi, D. (2018) ‘Lessons Learned on Communication Channels and Practices in Agile Software Development’, 2018 Federated Conference on Computer Science and Information Systems (FedCSIS). Poznan, Poland, 9-12 September. New Jersey: IEEE. 929-938.