Information Centric Security

ICS and "Where Do I Start"

I delivered the Information Centric Security Lifecycle presentation at Tech Target ISD.  In it I went over all of the phases of the lifecycle, from creation to destruction, and discussed all of the tools and methods one might employ, along with a couple of different models for Information Centric Security.  At the end I was asked a question from the audience about "Where Do I Start?  If I wanted to begin this at my company today, where would I start?"

It is a surprisingly simple question, but one that I am not accustomed to answering, and I think that I did a poor job in addressing.  I basically pointed the guy back to the lifecycle and said "If it's new data, go through this process.  If it is existing data, go through this process".  Technically sound, but not very helpful.  If you are working at a large firm with hundreds of legacy systems and data strewn all over the place, the challenges are far greater than that.  It's not just a question of picking a model and adopting it, but what data, what tools, what policies, what security model, and how do all of these choices affect every single thing I do in IT, adversely or otherwise.

I have talked about different ICS models in previous ICS Posts.  One of the Information Centric Security Models that I am a big fan of, the virtualized application space, limit's the scope of use for data to that application space, and implements it's security and privacy policies based upon the assumptions of a small domain of users and functions.  The down side of the model is that this does not take into account other applications, and does not readily adapt to generic data at the end points.  It's more focused than that, and while it can provide a very granular data security model, as well as mediate end user and corporate data security policies, it is lacking in flexibility.  The digital rights management systems that I have seen that mimic this model do not account for the data sprawl problem and do not assist the IT professional in getting a handle on existing data.

I realize that in the adoption of Information Centric Security, the Data Loss Prevention (DLP) vendors that are moving into this space have done something very pragmatic, and very right, in that they are somewhat agnostic in their securing of information.  The idea is to analyze and protect everything that they can view, from the network to the end point.  The proceed from the premise that both they are not aware of all of the information that is on the network, and that users will try to bypass the controls.  To address they set up the application at logical choke points (users machine, network),  constantly scan, analyze and enforce.  This is why I tend to call DLP a data centric security model as opposed to ICS, and I tend to criticize it's general efficiency.  Still, there is a tremendous practicality in the approach, for it automates much of the discovery, analysis, protection and policy enforcement on an existing body of data as it moves around an enterprise.  It provides the means to move from a network or host based security philosophy to a information centric one.  I assume that the vendors will migrate into being application context aware in the future, but for now, what they offer may be enough for most enterprises. 

I did not get up on stage and pitch DLP, but I must say that the tools and approach of DLP does offer an advantage when considering how to move to a data centric security model. If you are wondering where to start, the content discovery, analysis and generic policy enforcement tools within many of the DLP suites offer some advantages. 

-Adrian

Information Centric Security and Virtualization

Reading the latest blog post over at the Data Centric Protection and Management site, and the observation on Virtualization and data security.  This is a very concise summation, and very much the point.  You might not, and probably should not, trust the network, the OS or other peer applications in certain contexts. Doubly so in a virtualized environment.  With Information Centric Security, you create a virtual container, wrapper or 'universe' for the data and the business rules.  You no longer care if some of the infrastructure has been compromised as you may still be able to keep data secure even if it has been copied or vMotion'ed off to some other place outside your control.  I have discussed the variations on implementation models in previous posts, but when it comes down to it there are only a handful.  But the general need for Information Centric Security became more pressing with SOA, and will likely become a necessity with an entirely virtualized data center. 

I am glad to see more people blogging on this topic.

-Adrian

Miscellaneous Ramblings on ICS

I was having lunch the other day, discussing Information Centric Security, with someone I had never met before.  It was an amazing conversation, and it struck me as ironic that two people who have each spent the last dozen years at different companies working with different technologies have come to so many similar conclusions.  Both in the deficiencies in how we use the security tools we have today, or more correctly, the mis-application of those technologies.  We both had nearly identical concepts about how to move security forward, and how it will take a fundamental shift in the mentality and approach of the security practitioners to achieve these goals.  Our consensus was that it is not so much a technology issue, but will require a fundamental shift in perspective to advance IT security from where we are today.  There is more than enough technology available.  Our technology tool kit is full of cool stuff.  Technology is not the limiting factor.  How we approach solving problems is.  I called it an ‘Approach’, he called it a ‘Mind Hack’.  Whatever.  It is these types of meetings that keep me in this profession and get me excited about my work.

It is also interesting to see how biases and beliefs manifest themselves into different implementation strategies.  Forgive the crude analogy, but while we both fervently believe in Information Centric Security as a model, we worship at slightly different altars of implementation.  Some of us view the solution as a virtualized application space, which I believe is manifest of a business processing security perspective.  Others view the solution as a packetized encapsulation of data objects, which I believe originates from a perspective of personal data protection.  The former has a distinct advantage in the area of misuse detection and data policy management, the later has a decided advantage in privacy and application dependencies.  There will be other proposals, which will all have a common thread that data will have a playground in which it is used, accessed and stored.  The differences are where you draw your ‘line in the sand’, or the protective boundary around the data. Personally, the more the better as it shows the flexibility of the concept, but it can make it more difficult to get your head around.

To take this one step further, much of the security we have today is designed to protect the infrastructure.  It is external to business processing and in many cases is deployed as an ad-on at the network level.  ICS by contrast is systemic.  ICS places security directly on the asset of value, not the infrastructure.   ICS and Firewalls or IDS are not mutually exclusive, but take the opposite approach. 

Anyway, it is great to get a chance to sit down with someone who has been thinking about this for many years and hammer out some ideas and where to go with this. We are going to reach a critical mass on this in short order.

Data Security: Threats and Objectives.

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. 

Thompson's RSA keynote.

I finally got around to watching John Thompson’s RSA keynote address this morning. I was hopeful that there would be something interesting here. There was. He was speaking on the topic of Information Centric Security. This is surprising to me. Partially because this is a concept that a lot of people in security have trouble getting their head around. So if the leaders in security still have trouble conceptually, mass acceptance is probably a long way off. Even more so, Information Centricity would require a metamorphic change to the products Symantec produces today. A decidedly non-perimeter, non-network, non-packet model that requires bi-directional establishment of trust does not fit with what they offer today. I am unaware of any company CEO that really follows through with changes that would adversely affect the usefulness of their core revenue generating products.  Still, his advocacy is encouraging.

There is a link for the presentation here if you did not see it during RSA.

The quote “The battleground for security no longer revolves around the infrastructure, it revolves around data” gives me a warm fuzzy feeling, being a non-network security guy.  Sure, a statement taken unto itself is rather generic. Just because you perceive a need to move away from a perimeter or network based model for security does not necessarily mean you endorse an information centric model.  But when put in context to the remainder of the presentation and the other quotes about the need for an information centric approach to security, digital rights management, security as a business enabler, white listing, linking security with data management, it appeared to me that he really ‘gets’ it. I am not trying to be condescending, rather my point is this does not appear to be marketing speak, but genuine understanding. Cool. I will be interested to see what the strategic product roadmap looks like to get there.

 

p.s. Does anyone know where the statistics came from about reaching the ‘inflection point’ that the lines of malicious code has grown equal to the lines of ‘legitimate’ code produced on a daily basis?

Contrasting Privacy & Integrity Models

Information Centric Follow-on comments

There was a comment on Rich Mogull’s blog page after he posted Principles of Information Centric Security about existing models for security and integrity, and comments on novelty. I think that is worth delving into in a bit more detail.

The Bell-LaPadula model, as I understand it, defines security states and governs how data moves between these states. Its motivation was to help prevent secure information from leaking by providing handling instructions. In essence it would provide decision support for who gets to do what to the data. This is a policy model for data. If your business application is secure document management, this would embody the business rules you might choose to implement, or one of several you choose to implement.

The Clark-Wilson model, as I understand it, is about data integrity. It advocates a user, application and data set triumvirate, along with a verification process, to ensure data integrity. Data and users are authenticated, and the ‘transformational’ algorithms certified for use with certain user& data combinations. In a nutshell, once data in the system is verified for integrity, every modification is subsequently verified before the transaction is completed. If your business application airline flight scheduling, this would be a framework to ensure that all operational and logistical restraints were met prior to scheduling to ensure consistency.

Conceptually, either model could be implemented in an Information Centric manner, or it could be implemented at the Application level (typical), or it could be implemented at the network/device level (is a DLP-esque way).   Clark-Wilson bases the rules on a controlled system. We are moving to systems that are globally networked and we cannot necessarily rely upon central, organized control. Hierarchical security models with mono-directional establishment of trust do not work.

Clark-Wilson has a couple of weaknesses as by definition it implies a closed ‘system’. It relies upon certain trust relationships that may not be valid, for example, within an SOA framework. How do you ensure the integrity of the transformation model? A Rogue can simply ignore the rules of the game. ‘System’ certified relations may not be trusted, a user does not have a way of certifying the systems because there is implicit trust in the relationships as defined. Could it be augmented to fill these gaps? Probably. But this is the tit-for-tat game we have been playing at for decades.

I could make similar statements for Bell-LaPadula in non-trusted environments, and I would also recognize that Bell-LaPadula could be augmented to deal with the issues raised above. That is neither here nor there. My point is not to point out weaknesses in these two models, and these both do what they were designed to do very well. I do want to show the differences in that wrapping security and integrity up with the data, and providing that bundle enough information on defending itself from un-trusted applications, or subverted access controls.  An Inside-Out model, not Outside-In.

 

Also, on the subject of novelty:

I tend to view many things that may not be novel as revolutionary. The first plasma television picture was shown in a lab in 1970, but even in 2002 I could not have imagined having a 50 color television set hanging on my wall!  Patents for novel concepts often lapse before a genuine embodiment ever appears in front of the public. Information Centricity is not novel as discussions and papers have been made available to the public for at least a decade. That does not diminish what I consider to be a more revolutionary than evolutionary approach to security that Information Centricity provides.

“Shortly after I published my paper on ‘Fuzzy Logic’ I started to hear the murmurs and snickering in the hallways behind my back. Not just students, but professors, my own peers, thought I was a fool for seriously proposing such an idea … several years later the Japanese adopted the concept as an effective method of scheduling trains for their rail systems. I was then lauded as a genius by many ... I don’t believe either group is right in their assessment, but the answer probably lies somewhere in between”.

That quote was made by Professor Lofti Zadeh at the beginning of a lecture I had at Cal in 1998. (Or was it 1999? Perhaps my memory is a bit fuzzy as well). Fuzzy Logic was not novel at the time of adoption, but certainly revolutionary in the approach. The evolutionary changes in IT infrastructure has rendered many of our basic assumptions on trust and reliance invalid. Information Centricity turns the trust hierarchy upside down, and would fit my definition of a revolutionary approach. It has its own set of problems, but it addresses many common problems we have with confidentiality, integrity and security. Not a panacea, but a big step forward.

Information Centricity follow-up comments

Complexity and Implementation

I selected the email example on Information Centricity for a couple of different reasons. One of which was based upon several Blog posts out there talking about what changes would need to be made to the infrastructure, or basically ‘how do we get there from here’.  And now that I have seen Mike Rothman’s comment  that “I'm not going to be so bold as to say it isn't happening, but it's nothing I've seen before” I am glad I did. When you start thinking about how to implement Information Centricity, let’s say in an SAP environment, it’s enough to make your head explode. I wanted to start small to demonstrate a couple ways Information Centricity addresses security issues in changing IT landscape. 

As email is ubiquitous, and email tools are prevalent, I felt that this was a good illustration. All I really need from the technical side is for a tool kit/extension onto my favorite email tool that can handle keys, digital signatures and encryption. From a people/process side, I simply need agreement on what we will use and the exchange of keys. This is not a big change in technology. But it is a fairly significant change in perspective. 

The typical IT security model is to start with systems & processes to perform business functions, and then patch security on top through various preventative and detective controls as new threats emerge. Information Centricity we start with secure data. Then we embed rules on how and when it gets used.  It doesn’t mean we are throwing existing systems out, rather we are changing the nature of the information that flows through them.  Systemic rather than additive.  Assume insecure and uncontrolled, then enable as trust is established.

Information Centric Security Example

Sure enough, we are starting to see some more posts on the subject. Rich Mogull took up the charge and put the stake in the ground with some guidelines for defining what constitutes an information centric security model.  I am glad he did this, both from the sense that I think he did a great job, but also from the realization I cannot. While I am a big proponent, I have far too many pre-conceived notions about this type of security to provide a neutral definition that does not pre-suppose some deployment strategies. I am thankful he took the first step, and some of the heat for, proposing this model.

What I want to do to take this one step further is provide a tangible example of this model.  I want to provide the simplest example of what I consider to be an information centric security. I have never spoken with Rich directly on this subject and he may completely disagree, but this is one of the simplest examples I can come up with. It embodies the basic tenants, but it also exemplifies the model’s singular greatest challenge. Of course there is a lot more possible than what I am going to propose here, but this is a starting point.

Consider a digitally signed email encrypted with PGP as a tangible example. 

Following Rich Mogull’s defining tenets/principles post:

• The data is self      describing as it carries MIME type and attachment or you can encrypt the payload and leave      business context (SMTP email header) exposed.
• The data is self defending in both confidentiality (encrypted with the recipient public key) and integrity (digitally signed by the sender). 
• While the business context in this example is somewhat vague, it can be supplied in the email message itself, or added as a separate packet and interpreted by the application(s) that decrypt, verify hash or read the contents. Basically, it’s variable.
• The data is protected in motion, does not need network support for security, and really does not care about the underlying medium of conveyance for security, privacy or integrity. The verification can be      performed independently once it reaches its destination. And the payload, the message itself,      could be wrapped up and conveyed into different applications as well. A trouble ticket application or customer relationship management application are but two examples of changing business contexts.
• The policies can work consistently      provided there is an agreed upon application processing. I think Rich’s intention was business      processing, but it holds for security policies as well. Encryption provides a nice black & white example as anyone without the appropriate private key is not going to gain access to the email message. Business rules and processes embedded should have some verification that they have not been altered or tampered with, but cryptographic hashes can provide that. We can even add a      signed audit trail, verifiable to receiving parties, within the      payload. 

I might add that there should be independent ‘Brokerage’ facilities for dispute resolution or verification of some types of rules, process or object state in workflow systems. If recipients can add or even alter some subset of the information, who’s copy is the latest and greatest? But anyway, that is too much detail for this example.

The fundamental problem with this model? People. If you do not trust the recipient or user of the data to whom you have provided credentials, the model does not provide privacy. Un-trustworthy recipients can leak sensitive information. In our example, hopefully we did not send the email message to them, but obviously we do not always know who we can trust, or under what certain circumstances we trust a person. This is serious, but no less of a problem than in just about every other information usage and sharing system ever created. 

A note on DLP and Information Centric Security: Security that acts directly upon information, and information that embeds it’s security are different concepts. IMO. Under a loose definition, I understand how one could view Data Loss Prevention, in context Monitoring/IDS and even Assessment as a data centric examination of security. But this is really not what I am attempting to describe. Maybe we change the name to Embedded Information Security, but that is semantics we can work out later.

One of the commenter’s on Mogull’s web site references both the Bell-LaPadula and Clark-Wilson. These papers are relevant and I will discuss in a future post, as well as the topic of evolutionary change and novelty.  For now, I just want to propose a tangible example.

### Update ###

Hoff was kind enough picked up this post on his blog. Chris is right that the first bullet is very confusing.  What I meant to say is that the business application, email, is self evident.  The email header remains as it would normally be.  The information is self describing as it is tagged as encrypted content in the message body, or could be an attachment to the email.  I mentioned MIME purely for non-text based attachments.  Sorry about the word jumble.

Data Centric Security Model

Security attributes of data and data should be inseparable

                            

I was having lunch last week with a good friend, Kurt Stammberger, discussing various security technologies and the state of the industry in general . If you’re not familiar with the name, think RSA Security Conference, as Kurt successfully guided that event from its origins as a small conference room gathering to one of the largest security events around. During lunch Kurt brought up the Transactor project, a Digital Rights Management platform that proposed a method of creating unique objects that the two of us had worked on together.  That dredged up a lot of old memories and war stories. Reminiscing over the amazing people who worked on that project, how advanced the security was in both design and execution brought to mind many of the same old problems we are trying to solve today. But as with many tech startups, there was some incredible work never saw the light of day. The crux of the conversation was this is a great idea, but one who’s time had not yet come.

 

Ironic that when I got back from lunch I ran across Gunnar Peterson’s article on SOA security. I think the Gunnar is dead on target! The introductory examples that it is about the car, and not about the garage is precisely the point. How do you protect data in a distributed environment, not just when parked but also when in motion? Who do you trust and what rules do you enforce? This must be part of the design if the system is to have a chance for success, and to extend that one step further, wrapped around or embedded with the data. The car is secured, not the garage.

 

It is based upon these concepts I have proposed that the ability to protect data without some form of wrapper or ‘meta data’ is difficult to impossible in an SOA environment, either at rest or in motion. And coincidentally, this is much of what the Transactor project was about, and quite specifically what the Limited Edition Digital Object was meant to provide a medium for this type of transfer. In a nutshell, a LEDO is a container with embedded use and ownership rules, private & public components, with each component maintained by its respective owner. I have even gone so far as to propose that perhaps we do away with the concept of unstructured data altogether in the corporate environment. If it is valuable, wrap it up, and let the data bring its own security and ownership along for the ride.

 

 

In the late 90s the Transactor team members at large viewed this type technology as fundamental to Internet commerce, as security and ownership are critical elements to conducting commerce, so the need was obvious to this tiny minority. There was considerable conviction that we were building ‘the right thing’. Many people outside the team thought we were a cursed group of morons, bringing our unneeded security to their projects, and told us as much. Especially members of other projects in house projects, who had our beta version DRM technology rammed down their throats under the guise of ‘eating ones own dog food ‘. While surprised at the hostility we generated at the time, it did prepare me in the coming decade as how those who are not worried about security perceive it as pure hindrance to their own activities, and willing to go to great lengths to avoid dealing with these additional challenges. I have come to expect that security is still not typically part of the development process because it is not part of the specification, process or mindset of the development teams.

 

I have talked with several members of the security community about this over the last few months and the concept of a data centric security model is starting to gain some momentum. I will delve into some of these concepts and variations more thoroughly in the future, as there are many potential variants. There is no hurry because the market is still 3-5 years away at best. We are a long way away from viewing data security as an enablement for conducting transaction in open – and subsequently more risky – environments. I hope that Gunnar’s article will get some attention by software architects in the meantime, as less time discussing the use of POJO’s, and more time discussing security in a distributed processing environment is needed.