Inaccurate data...

I haven't had any negative feedback so far on my data security postings from last week, but talking to people who've read my posts and tried to understand where I'm coming from, it's clear that I've oversimplified something which needs a lot more explanation.
I normally generalise to make points, but this time I need to go back and fill in some gaps.

Firstly, I talk about transaction security, from user through the network to the data. This ignores a large part of physical and logical security, the security of the host itself. I stayed away from content and activity monitoring because where I have traditionally worked with data, these I tend to view as perimeter controls.

I also perhaps don't mention DRM when I should. That's simply because I don't anyone who's got a reliable solution yet, although I've been told that such things do exist.

Really, it's because there is enough of an overlap for me to consider these things part of the huge number of network devices that are in existence now. There are fabulous solutions like Vontu for controlling all of this.

Encryption is covered by a panacea of products, you can protect inside your database, outside your database, at the file level, on the wire, in transit and at rest. I've worked for Vormetric, (which, by the way is still the best file level encryption I've ever seen), I've worked with Ingrian for a number of years, I know the guys at Protegrity too. Then there's Decru, who I wish I'd worked with (certainly when they were bought by NetApp in 2005), and NeoScale who I know only by reputation (and their systems guy who joined Vormetric just before I left). These are just the good solutions, there are tens of others which don't make my list of top guys.

And yet still no-one does data integrity properly. Encryption and restriction doesn't provide it, WORM devices don't provide it except in storage, digital certificates provide a partial solution, etc. And this is why I focused here. Sorry for any misunderstanding. I'm not an analyst (yet), if you want that, read Rich Mogull on Securosis, I've followed his work my entire career and what he doesn't know in this space isn't worth knowing.

Me, I just see holes I want fill, and that's what I write about.

Can we license data? - part II

The issue is that people will still want to steal data if it's licensed or not, my wife just gave me the example of someone stealing the blueprints to a new BMW car (I was actually involved in encrypting the blueprints for the new 6-series in Munich because someone had stolen a part of them, but that's another story). If it was licensed, people would still want to steal it, change it slightly and then produce a new car that drove well and looked good, but wasn't a BMW. The problem here is identifying where the value lies in the data and how you would license it.

If you can prove that various parts are the same, you can charge for breach of copyright, and therefore could license in our data sharing model.

I've heard of technology which will analyse databases of information and tell you if the data has the same patterns in it. They are currently using it to detect picture spam, i.e. delta changes in emails and pictures attached can fool anti-spam because of weak rules, but not with this thing attached, which seems like a waste to me. They are also doing trials with some sort of medical research which is more valuable.

If we could prove that the car was essentially 90% BMW we could charge for the license...

Can we license data? - part I

Following on from my last post, Jon Robinson asked me whether it was feasible to license data. He said to me "What I think would be enlightening would be creating a taxonomy of information that needs to be secured or leveraged in one form or another and then listing the best alternatives for doing so."

The securing or the leveraging is utility of the information. It comes down to ownership of the data, its permanence and perceived value, i.e. this really boils down to "what is 'private' data?"

One of the problems with data is that once it’s in the public domain, it loses it’s identity (unless it IS an identity), whereas a process, or utility, is still identifiable as the original, it has a fingerprint, or some part of it does, and can therefore be licensed more easily. If the data IS an identity of some sort, then we have a different issue, it is identifiable as the original and therefore always has a value, hence why identity theft is a problem. Maybe therefore data either has identity, or none, and if you can’t prove the identity, then if you try to license it, you can’t collect. If we can prove that the data in it’s original form falls under our own license, then we should be able to charge for it, i.e. a copy of a book, a print of a painting, etc.

This is why there is such value in proper data integrity, proving that the original data is still original, to a more granular level than digital certs hopefully. What is harder to do is retrieve data or reconstruct data once it is lost, so an 'idea' can be rearranged and still be a pretty close copy, without bearing any relation to the original fingerprint, this is a real world issue with copyright and trademarks still.

Recreating the Industry

I've just been reading through Mitchell Ashley's Network Convergence paper and I'm still a bit annoyed that I didn't think of it myself. I've been involved in a similar project, but centred around an open compliance framework (open source and open standards), so I have to be convinced that this is the way which makes most sense for the industry to proceed.
However, something is nagging at me. I can't quite get past the facts that big organisations like to pay for software and have it properly supported, plus all of this "free" stuff has hidden costs which usually come in the form of expensive consultants (like Mitchell and, er... me). And there aren't going to be enough consultants available for it to be viable for a very large and dispersed organisation.
I really wish everyone would install Cobia and develop tools to run on top of it, but unless they are going to see an immediate return on their time investment, I don't think it will happen that quickly.
I agree with Jon Robinson that network appliances CAN suck, and Mitchell's answer is almost perfect. Certainly for anyone brave enough to have a go it is cheap and effective. Jon and I have been talking on this point since his post and it seems there is a lot more at stake than just cost however. I didn't realise quite how much more until Jon pointed out a few things. I will let him post on this next week when he's moved his blog over to Wordpress rather than stealing his thunder. Essentially though: it is the data that is of value, but not JUST the data, it's all down to how we use it. I blogged on this last week in answer to something Kenneth Belva posted, and now I think it's all part of the same set of convergence ideas, which relate to the advancement of security, and vice versa.
All of which talking led Jon to ask me a simple question: "Could we license our data and let anyone use it, like we do with GPL for software for example, and what are the implications for its security?" (That's paraphrasing, his email was rather longer, but you get the idea). Answers on a postcard please!

The great data debate.

A great blog entry from Kenneth Belva here in bloginfosec, got me slightly excited. An open debate about data security is something I've been looking forward to. Quite apart from the fact that I've studied his work for years and have a bucket of respect for the guy, I have to continue the debate as it seems to have opened up a few lines of communication with the wider community, and I love nothing more than a good healthy discussion.

Kenneth says "...data has utility. By that I mean that if one cannot do anything with the data there is no value to it." Thus echoing Donn B. Parker's awkwardly named but intricately woven Parkerian Hexad.

The paradox here is that if I completely secure my data, it becomes unusable, so loses it's value, but if I make it too widely available, it loses it's confidentiality and thus the value becomes so diluted that it effectively loses its value... uh?

This is simply because it is a mistake to think of a secure network as giving you secure data. They are 2 very different forms of security. The data can still be widely available on the network, but as confidential as possible. It is this that makes the network so important to secure, because it ensures the data's availability AND utility. But then the data needs to be secure in itself.

There are a couple of issues of paramount importance here, the integrity of the network, and the confidentiality and the integrity of the data. These are the very things we should be looking to secure to ensure our use of the data and the network is safe. I will follow up on PCI Answers with the data disclosure debate later tonight. These are just the kind of conversations we should all be having.

ERP Security, any ideas?

Friday afternoon, 4pm, Barcelona: The Managing Director comes to me and says we need to reposition our approach to the European market. "Everyone is saying they need us, but as part of a bigger picture". My heart sank, we've put a lot of effort in since I moved out here and to tell the truth I was experiencing the same thing with my calls, even to the guys I know in the States who are at least 4 years ahead of us in security terms.

So we're repositioning, and I've spent the weekend preparing our ERP security program. I'm pulling industry best practices and solutions from all over the place and putting them together in a package, but one thing is overwhelmingly clear. The ERP guys don't pretend to have security sewn up, they are ERP guys, not security guys after all, but the security that is available for these applications has a large amount of holes, and not a huge amount of solutions.

Does anyone out there have some good ERP security offerings? Tools for getting right inside the database to audit the data, identifying users after connection pooling from the app has anonymised them to the db, tracking transactions from start to finish, etc. I know enough about securing the data once it's got to the storage, ensuring the integrity of all the transactions through to reporting, and even applying user security, but the "application to database audit problem" seems to be pretty tough.

I'd really appreciate some pointers.

Thanks,

Rob.

And I repeat...

I have admit I didn't expect to make a big splash when I entered the world of data integrity. We're up against digital signatures, TripWire, encryption and access controls, and everything else that's been wedged into this space by poorly thought out compliance regulations, over eager sales people, network engineers, silver tongued pre-sales, security guys...
Yes, I place the blame squarely at my own feet. I have been all of these things, apart from a poorly thought out compliance regulation of course, that would be odd.
The fact is, data integrity still doesn't exist, and here we are basking in the swimming pool of security whilst the administrator of false senses dances through our data, happy in the knowledge he is king and no one can catch him. A bad mixed metaphor, but quite picturesque I think.

Let me explain. In the beginning there were firewalls, this kept out some Bad People. Then there was AntiVirus. This kept out some Bad Things, written by Bad People. Then there was IDS, followed by IPS, then IDP, then app firewalls and UTM. Basically it's all sewn up at the perimeter. Then we realised the attacks were coming from inside. Alan Shimel calls it M&M security, crunchy on the outside, soft in the middle. I call it armadillo security for exactly the same reasons (anyone in the UK will remember the Dime advert along the same lines).

Of course for perimeter security to work, user security has had to work. RSA had SecurID all figured out years ago, and I've still to see a better answer to strong authentication. Every year I expect to see something to challenge it at Infosec, and still nothing. CryptoCard, Entrust, OK, they're pretty good as cheap alternatives, but they aren't as secure, and that's what I like, security.

So, we move inside the network and start to rely on Cisco for everything. Ooops. Cisco are the dogs danglies when it comes to networking, but networking security? They try bless them, but they just can't move fast enough. I've mentioned ConSentry in the NAC space already in this blog. I spoke to Sean Remnant there this afternoon and it seems he's getting busy now. When he last visited me in the UK, he and Bill Wester (SE Director) looked a little nervous of how sales might go. Despite my full support (and who wouldn't be delighted with that?) they seemed worried that Cisco and Micro$oft (why do they persist with that silly name, surely trading standards should have had them by now, MegaHard, that's much closer), would be able to knock them out of the market by their sheer size. Cisco even threw them out of the NAC Consortium because they were too much of a threat. Ooops again Cisco, don't think we didn't notice!

As far as I'm concerned then, NAC has the network sewn up pretty well, again, as long as your users are authenticating properly, all the network needs is good access controls. But then, what about your data? Do I sound like a stuck record? Do I? Do I?

Right, let's assume you have encryption. What happens when superadmin walks in and disappears with your financial accounts? What about the CEO, the CFO, etc, etc.? OK, apply some clever data centric access controls. Now the security admin has control. What happens when he walks off with your data? Now apply some separation of duties. What happens when the security and network admin get together and decide to rip off the company because they aren't paid enough. The solution? Pay your techies more! No, obviously not, that would be counter productive, if you do that, they hold you to ransom more.

OK, so we apply separation of duties, and implement TripWire. They still walk off with the data, but at least they didn't change anything on the network whilst they were doing it. PHEW! Email still works! Sorry, I don't mean to disrespect TripWire for a second, they are a vital piece of network security, which no-one else addresses, but they are monitoring controls, not data controls. OK, so now assume you have the data access logs streamed, encrypted, controlled for access, duties separated, and a digital signature of the data taken every time a log is saved, just for good measure. Apart from the incredible amount of data that would create in new signatures, what does it prove?

Now my superadmins, who know where this logging information is kept, just go in and delete the entries which show where they stole valuable data. The digital signature is broken, the files don't match up when I come to read them, if I come to read them at all, etc...

There are still holes, that's my point. We need something which gets around this, something which follows the data, not the network or the user. Something to go with the encryption and access controls, with the user security, with the network security. The rest of it we've had sewn up for a while, and we're just banging on down the same old path of tweaking it and polishing it, before we've even finished the whole story.

You wouldn't have had to spend $/€ 50k a year on firewalls, chasing your tail and wondering why your data was still going awol, if you'd just waited and insisted on the security being tighter. Understanding your security even. Getting a security guy in who knows what he's doing. The problem is, we're the only ones who know how it's done, us, the security guys, and we don't tell anyone. I don't think even we understand it properly, that's the real issue, and until we're prepared to admit that, we're not going to make any progress.

My previous posts have explained it in part, but I don't think people will even try to understand until the penalties are high enough. Compliance is one thing, fines are another, what we really need is a tight disclosure law. The only thing that really affects people is reputation, banks put aside money to deal with fines and breaches, did you know that? They EXPECT to be hit. Why?

These are all the themes I cover on a weekly basis and I wish I didn't sound like I was repeating myself. The fact is, I have to.