Security is all about Context

Since this is my first security related blog post (ever), I would like to write about one of the most important things that I learnt during my grad school: security is all about context. This is exactly one of those important lessons that we learn, as a student, and don’t realize their importance until we apply them to the real world problems. It has been almost 3 months since I’ve started working as a full-time Security Consultant, and I’ve already realized how appropriately this phrase applies to the real world problems in computer security.

In case you don’t feel like reading more, here’s the TLDR:

“Security is all about Context

One of the perks of working as a Security Consultant is that you get to test/break/pwn applications/software every now and then. In order to effectively test applications/software, it is really important to understand the context. Two great approaches to understanding the context are: Application Threat Modeling and Attack Surface Analysis (these do not have to be formal ones if you’re just testing an application, but are very important for efficient security assessments). From the OWASP links mentioned above:

The Attack Surface describes all of the different points where an attacker could get into a system, and where they could get data out. Threat Modeling is a structured approach that enables you to identify, quantify, and address the security risks associated with an application.

There is a recursive relationship between Attack Surface Analysis and Application Threat Modeling: changes to the Attack Surface should trigger threat modeling, and threat modeling helps you to understand the Attack Surface of the application.

The simplest possible example that I could think of off the top of my head is related to a Cross-Site Scripting mitigation technique. The most common advice on this problem, which experts usually give, is: “Use context appropriate encoding” (notice the word “context”?). It simply means that just any output encoding cannot guarantee full-proof protection against XSS attacks. What else could go wrong if we just HTML encode the output? Well, the application might be inserting these user inputs into JavaScript or into the event handlers, in which case HTML encoding is not the correct mitigation. Now the question is if it is enough to just escape all inputs with respect to JavaScript and HTML? Again, it depends! What if the application has an import to CSV functionality, allowing others to import user data in CSV (Comma Seperated Values) format? An attacker can use this to insert spreadsheet formulae, which can lead to arbitrary command execution on victim’s computer. For more information on this, read Comma Separated Vulnerabilities. The point is, it is hard to devise a proper mitigation mechanism for an attack, without understanding the context.

Yet another example (kind of lame, but apt with regards to this post’s topic): Apple claims that your fingerprint is the perfect password. Well, they are absolutely right! But this cannot be true in every context. For instance:

I woke this morning to find my 7 y/o levering my finger onto the TouchID sensor of my phone. Maybe time to go back to passwords.

— Matthew Green (@matthew_d_green) November 25, 2014

I’m sure that by now, you all would have realized that this is the reason why any advice/solution/answer, that you’ve received or you’ll ever receive from a security expert, will always start with the phrase: It depends. Yep, it all depends on the context! Big thanks to Prof. Seth Nielson for teaching this important lesson (among many others).

Feel free to email me, if you want me to share something specific or need any advice/help. Please feel free to do the same or leave a comment below, if you have any advice for me or any comment regarding anything on this website. We are all here to learn. That’s what life is all about!