Mapping Security and Privacy Research across the Decades

This is really interesting: “A Data-Driven Reflection on 36 Years of Security and Privacy Research,” by Aniqua Baset and Tamara Denning:

Abstract: Meta-research—research about research—allows us, as a community, to examine trends in our research and make informed decisions regarding the course of our future research activities. Additionally, overviews of past research are particularly useful for researchers or conferences new to the field. In this work we use topic modeling to identify topics within the field of security and privacy research using the publications of the IEEE Symposium on Security & Privacy (1980-2015), the ACM Conference on Computer and Communications Security (1993-2015), the USENIX Security Symposium (1993-2015), and the Network and Distributed System Security Symposium (1997-2015). We analyze and present data via the perspective of topics trends and authorship. We believe our work serves to contextualize the academic field of computer security and privacy research via one of the first data-driven analyses. An interactive visualization of the topics and corresponding publications is available at https://secprivmeta.net.

I like seeing how our field has morphed over the years.

Tags: academic papers, computer security, history of security, privacy

Posted on October 24, 2019 at 6:21 AM • 10 Comments

Comments

Me • October 24, 2019 9:10 AM

@That chart on the last page of the slideshow

ARGG!!! There is a reason we have keys for charts like this!

Overall, it was kind of interesting.

Clive Robinson • October 24, 2019 11:44 AM

@ Me,

ARGG!!! There is a reason we have keys for charts like this!

Yes so they can be locked away to prevent people going la-la or worse.

Oh and the last page is not the worst, take a look at slide 39…

Correct me if Im wrong but I thought the idea behind making graphs and charts was to make data easier to comprehend…

@ All,

The paper it’s self is probably going to be a dull read for most people, but there are some bits of interest.

Primarily that the research is very much skewed from the actuall reality of computers in use. That is low level hardware that does not use OS’s appears to be significantly under represented.

Which with the majority of affiliations of the authors being academic or academic related, suggests that academia is not investigating a very large chunk of the market.

Perhaps that is a trend that realy should be “red flagged”.

Ismar • October 24, 2019 3:10 PM

@Bruce, thanks for sharing this free info with us.
I found the paper interesting enough to read to the end despite its first part being very dry (probably a prerequisite for academic papers ????).
I disagree with @Clive somewhat that topics that don’t feature prominently or not at all are the ones that could be where the real danger is as they would be of the highest value and reserved for high profile targets only and not as applicable to targeting of wider population.

Finally, mobile apps security seems a very hot topic but don’t remember any posts about it on this blog (will try to find some positive stories in this space for this Friday’s blog) where as I did not notice much prominence given to zero days (unless they are covered by some other category) which surprises me a bit.

Clive Robinson • October 24, 2019 6:15 PM

@ Ismar,

mobile apps security seems a very hot topic but don’t remember any posts about it on this blog

Search for the term “end run”.

Mobile app security is rather pointless because the platform is insecure, and can not be made secure under current considerations.

The reason for this is that the security end point of the apps is before the communications end point. So anyone who has access to the communications channel can reach around the security end point in the app to the plaintext user inyerface.

Untill we move the security end point beyond the communications end point application security is in effect pointless. This is not just true of mobile and smart devices but any computer using commercial off the shelf (COTS) hardware and consumer grade OS’s.

So untill we fix the security / communications end point issue, which I’ve been talking about one way or another for three decades now, then talking about application security is a bit like discussing if castles in the air should be painted baby pink or fairy blue…

Sorry to be so blunt about it but you would have thought that a fact so obvious to military communications thinking for well over a century now might have got through to those who claim they have developed secure communications apps, when in fact all they realy have done is misdirected peoples view away from the fact that not just SigInt agencies but bank account emptying hackers have been doing “end run attacks” in various ways including “IO Shims” for more than a decade.

As our host @Bruce has pointed out on more than one occasion security is a system made of a chain of parts, thus the strength of the system is that of the weakest link not the strongest. As others have put it, why put a strong room door on a tent when you can not be bothered to even tie down the flaps at the other end…

Just remember with mobile phones and smart devices, you in no way own them the OS developers (Google, Apple) own the “smart” and the communications service provider owns the rest. As CarrierIQ proved and countless not uninstallable apps have shown, even your every key stroke is owned by somebody else to be bought and sold without your knowledge or consent.

That is the reality get used to it and, live with it or mitigate it, there is no middle ground, no “sleeping with the enemy”. As an ordinary user you have no other choices available and probably never will, especially when the standards the communications have to comply with already have back doors built in. Thus the only way to mitigate it reliably is to take the security end point off of the device that has the communications end point and ensure sufficient segregation by appropriate energy gapping and technology use…

Petre Peter • October 24, 2019 7:03 PM

Computer security is becoming everything security.

Ismar • October 24, 2019 9:11 PM

@Clive – burning the midnight oil – your post time would indicate so based on your UK location?
I absolutely agree on the weakest link theory but don’t see it as excluding making other links stronger while we figure out how to enhance end point security.
Have you ever given any thought to developing some rudimentary hardware module that can be used as an add on to a mobile phone to encrypt / decrypt simple text messages before/after they reach the currently insecure (not controlled by end user) mobile phone ecosystem?
I have seen similar hardware used to provide enhancements to the phone range finding/ measuring capabilities and know that the physical size should not be an issue.
Could your diode idea be adopted to use via headphones jack or even via charging cable?

Clive Robinson • October 24, 2019 10:25 PM

@ Ismar,

Have you ever given any thought to developing some rudimentary hardware module that can be used as an add on to a mobile phone

Many times over the years[1]. I even developed a hardware token with screen and keyboard.

The problem is it almost always fails. Not because of technology faults but human faults, failing to follow even basic OpSec.

People appear to think that “collect it all” is a myth and that any mistakes or lapses they make are ephemeral not chiseled in stone tablets.

So the realy hard but most important design rule has to be,

Make using it less painfull than using any other method.

That way users will follow the path of least resistance to themselves, thus use the more secure option.

[1] I was probably the first person to suggest using mobile phones as a side channel for banking transactions. I worked out tricks to turn SMS messages from a secondary service with uncertain delivery into one that was nearly the same as placing call primary services. Whilst doing this long before smart phones I realised that, that was the way phones were going, and thus at some point banking apps would run on the same phone the SMS was going to. Thus how dangerous using mobile phones as security side channels was. Thus I thought about other ways. You can see some of it in my past discussions with @Nick P and others about “authenticating transactions” being more important than authenticating communications channels. Further the cods-up over using capatchers… Yup if ever there was a new way to fail I was one of the first to find it biting my nether regions somehow.

Sancho_P • October 25, 2019 7:14 AM

Interesting research, thanks!
Unfortunately the really fascinating timeline overview of their 20 categories (pdf) is missing from the slides (likely due to bad visibility).

However, for all the time it took them for the research, it wasn’t enough to give the paper a publication date – Gosh, how old school I am!

Sancho_P • October 25, 2019 7:20 AM

@Ismar

”Have you ever given any thought to developing some rudimentary hardware module that can be used as an add on to a mobile phone to encrypt / decrypt simple text messages before/after they reach the currently insecure (not controlled by end user) mobile phone ecosystem?”

There are three pitfalls in that thought (if I understood you correctly):

a) A HW module before data reach the phone would imply using the same insecure (proprietary and closed community) standards and require the service provider to accept your device (certification).

b) Even if a), this device can not block “regular” access / phone use, thus an insecure phone can’t be the “safe haven” for your plaintext (received or in preparation).
Your phone has to be deemed compromised, including keyboard, screen and any connectivity.

c) From b), your phone can – and will be at some time – served malware from criminals of one or the other party, esp. if you are known to transfer “secrets”. This may prevent you from accessing your stored secrets (loss of data) and force you to use a different, likely more insecure communication channel, likely in a hurry.

For a very basic suggestion see: https://www.schneier.com/blog/archives/2019/09/friday_squid_bl_696.html#c6799839

SpaceLifeForm • October 25, 2019 5:59 PM

@Sancho_P

I think that an external device that can do the encryption could work.

Provided one can do the Faraday cage properly.

Or the double Faraday Cage.

It may be easier to use an external device that shows a QR.

Take pic.

But,it still needs to be caged.

Schneier on Security

Mapping Security and Privacy Research across the Decades

Comments

Leave a comment Cancel reply