I was on a rant today because I was having a discussion about Information Centric Security, and someone has said that the implementation I was proposing promoted viruses and malicious code. The assertion is the packetized implementation of ICS I endorsed hid the contents from the user who received it, and therefore all sorts of malware could be hidden within the packets and ‘jump out’ at unsuspecting users. That is a great point, I do concede; completely wrong in two assumptions, but a good point that enforces my point for the need of two-way (or more) trust establishment. It also underlines the issue of what we should and should not do with the data we receive. The data we receive, who sent it and what their intentions were are assumed, and assumed to be good intentioned. Information Centric Security is meant to help assess not only Identity and proper use, but also help address the grotesque lack of trust establishment. We are far too trusting of other people, web sites, downloads, and in general, any free stuff that comes our way. And after spending the last few days with an infected DNS server, I don't even trust our infrastructure. Data needs to protect itself, and the users need to protect themselves.
I have been making several assertions in recent posts that an Information Centric Security inherently addresses several problems we typically face with today’s security products simply by the nature of this security model. I realize I should back these statements up with some specific examples to further elucidate what the heck it is I am talking about. So this is this the first of several posts on that subject. I want to start with an outline of some of the typical attacks and the associated objectives of the attackers to provide an overview of the ‘threatscape’. I will talk about how to apply the Information Centric model to one or two common tasks, and then talk about what value an ICS model provides in those contexts. I will also make mention to some of the things that ICS does not help with or problems that it does not solve.
So what are we trying to do? Secure data. That begs the question ‘secure it from what’, which becomes a much longer and more difficult discussion, but I will attempt to tackle some of the major points here. This is an overview list of the types of threats that I will be considering as this will help frame the attacks to be considered. I have broken objectives and attacks into two separate lists I broke this into two lists to better illustrate a many to many relationship of attacks and threats, as well as the complexity of information security challenges.
So what are some of the hacker’s objectives when it comes to data security?
Theft of data.
Alteration of data.
Pretty much, that is it. I am making the assumption that if data can be viewed, it can be copied. We have been working hard for the last two decades to make data available, and pretty much every medium I can convey data on has a way for me to siphon it off. And I also assume that these two goals can be accomplished by subversion of the processing infrastructure or machine for the purpose of:
Alter an event or processing
Altering the functionality of a machine
Theft of activity
Use infrastructure to attack another machine
This is not an exhaustive list, but the major ones that popped into my mind. Feel free to add more and I will attempt to discuss in future posts. I will note that there are many other objectives for hackers, for example denial of service attacks, but my intention is to limit this discussion to data security and not general infrastructure security challenges. For Information Centric Security, these first two items are the challenges we are trying to address. Each of the above objectives they can accomplished in a number of different ways. Given these objectives, how might a hacker go about it?
Insider attacks: Use of the approved platforms, applications and credentials to either steal or alter data.
Network attacks or theft of data in motion: Network monitoring or ‘sniffing’, ‘man in the middle’ attacks and the like.
Data at Rest: gaining access to a file server, console or backup media and other forms of direct access to data at rest.
Quasi Data at Rest: Databases. These repositories have a unique set of challenges given the myriad of ways to execute functions on data, and typically require some degree of inspection of the data to perform reporting and analysis functions. And there are a myriad of attacks such as bypassed credential checks, SQL Injection, Buffer Overflows, exercising external code inks, data leakage and more.
Data in process: Applications. As with databases, web applications and large footprint enterprise applications like SAP offer a myriad of exploits.
Platform: Use of remote sessions, viruses or other code that provides a gateway onto the system, OS or application that houses/processes the data.
Physical attacks: This could run the gamut from looking over someone’s shoulder, Tempest attacks (quasi-physical), stealing a computer to holding a gun to someone’s head. I am going to ignore this as section to discuss as a) it is somewhat outside the topic of computer security and is more of a traditional security problem, and as well as b) this typically devolves into an insider attack.
My intention is not to create a definitive list, but rather cover the bulk of objectives and threats, and discuss how Information Centricity addresses some of the problems. This is a long enough list that it is going to take some time to address. In the next post, I am going to discuss two examples of how someone might choose to implement ICS, and then follow that up with a discussion of how ICS deals with some of the threats brought up in this post.
Comments