I just got off the phone with Gretchen Hellman from Voltage and she asked if I would write something about them. I'm still digesting it really, but I have to say, they seem to have a pretty smart solution to some real business problems. This is what I love about Americans, everything's an opportunity, not an issue. I live in Spain.
Anyway, Voltage saw there was an issue around PKI administration, so they addressed it. They saw usability problems with email encryption when certificates were used, so they fixed it. They are now seeing lots of talk about holes in web applications making for vulnerabilities in online transactions, so they've looked at that too. People keep asking them about laptop encryption when they are talking about other forms of encryption (a common issue from experience), so they bought Safeboot - easy!
Voltage is yet another Dan Boneh company, he's another one of these guys that I've been aware of for my whole career. When I started, Dr. B (as I call him) was at RSA, he then helped found my chums Ingrian, and now he's at Voltage, who I hope will remain friends now too. Now this is what I want to do with my career - start up useful security companies which address real life business issues, that people are having now.
WebAppSec is something we hear a lot of in the SBN pages, not something I cover a great deal about because my view is that the apps "should" be secure, yes, but the data is really where the issue is, so as long as the apps do their job, so what if they were written by a 15 year old? Cheap development will never go away as long as there are teenagers and emerging nations to exploit. (Harsh, but true.)
I've talked about data-centric security for a long time now. It is my long held belief that applications, databases and transport mechanisms are redundant to a large degree in security. Voltage have helped move this argument forward for me, my little brain is cranking up once more, and I love them for it right now.
I will be writing more about this next week once I've seen a bit more proof and substance, but essentially it goes like this:
DBs and apps have issues with encrypted data because of formatting, so what choices do you have around data? Come on Mr. Data-Centric, get out of that one!
Well, you can choose not to encrypt or encrypt at the file level, either way, by the time you get your data to the application or database layer, it's no longer encrypted. That's no good.
You can choose to buy a column level encryption product and say goodbye to your IT budget, it won't necessarily interact with your application very nicely, and it's not really much of an investment.
But Voltage have implemented a very clever technology (lots of Maths, or Math to my American friends) to get around this - format preserving encryption. Great, now your database can store the data in its original format. Now we can encrypt data in the database, using the also very clever IBE (identity based encryption) product they have, and hey presto, the information remains encrypted throughout the transaction until an authorised user, with the correct ID tries to access it. This is perfection, scalable, data centric, simple ID based encryption. Once again I'm excited about some technology. I feel slightly vindicated, now if only everyone would go out and buy it, I could be your king.
[Oh yes, I didn't mention Martin Hellman to Gretchen (her father), but she brought him up right at the end. Deservedly proud I guess, and with an audience who she knew would appreciate the name drop, why the hell not? I feel writing this should earn me a meeting with the great man, another name for my Security Spotters Handbook.]
Thursday, 21 June 2007
Tuesday, 19 June 2007
It just gets better
I received an email last week titled "CONSUMERS DEMAND: Protect Our Personal Information!". At first I went to delete it, anything which goes into my junk mail is normally crap, and if it has capital letters and exclamation marks in it, it is almost certainly sales crap. But something caught my eye about the content as I reached for the delete button, the word "encryption". I'm a sucker for that sort of thing.
But hang on, Hellman… yes, Gretchen Hellman is daughter of Martin, one half of Diffie-Hellman (the Hellman half!). Although I bet she doesn't like to be reminded of it at every possible opportunity, but OK, now I’m double interested.
The mail started something like this:
"Thought you might be interested in working on a blog post about key management (encryption management). Analysts at Gartner and Forrester agree this is a topic that needs to be discussed more publicly and by tech media."
Now this sounds VERY like a sales pitch to me. Anyone who cites G and F, and says that they agree that it needs to be discussed, blah, blah, blah, basically doesn't understand what they are proposing and is trying to sound knowledgeable by proxy. I know because I've heard it, recently, in my own office.
And er, "key management (encryption management)"? Where do I start on this one? I don't think I have to do I? Key management != encryption management, nor is either a subset of the other, in fact, what the hell is encryption management? Why do you have to manage encryption? Surely if you've managed your keys properly the encryption kind of manages itself?
One more thing, I used to work for Vormetric, and I don’t remember one single case of a consumer demanding to protect their personal information. In fact most of the time it was like looking for a needle in a haystack, and even then we had to convince them to take a look. However, he also just mentioned blogging, and I like blogging.
He continued: "Crypto experts Luther Martin and Gretchen Hellmann are available this week and next to be interviewed on this topic."
But hang on, Hellman… yes, Gretchen Hellman is daughter of Martin, one half of Diffie-Hellman (the Hellman half!). Although I bet she doesn't like to be reminded of it at every possible opportunity, but OK, now I’m double interested.
I'm speaking to Gretchen on Thursday, and I'll let you know how it goes.
Saturday, 16 June 2007
I'm a stalker
I admit it.
I'm the kindest type of stalker though, I send emails to my victims and if they don't reply I leave them alone. One of the ones who didn't get away was Rich Mogull, security man extraordinaire, a guy I have a lot of respect for, not least because I have worked for a number of the companies he has analysed in his role at Gartner, usually favourably.
So how did I get in touch with the great man? Well, I'm ashamed to admit, although I'm actually quite proud of it too, I used a bit of social engineering. One of the more apt phrases I've heard used in the pages of Security Bloggers Network recently is "flattery injection" attacks. Well, this is basically what I did. I quoted his blog, and said pretty much what I've said here, that I've followed him all my career and that I respect his work. He emailed to say thanks, and I just kept him in dialog.
OK, so it wasn't planned and I have no right to be smug about it. I have no desire to put one over on him anyway, but it was a good way to start the blog. Long story shortened, I got to speak to Rich last week, there was a slight delay on the line which made things a little tricky, I talked over him a couple of times, but I could have gone on all day. Maybe I should have listened more...
Someone once said something about meeting their heroes, only to be disappointed. I wasn't. He was a thoroughly nice chap and he knows LOADS of stuff without being big-headed. I only wish I could have had more time.
Last month I got to say "Hi" to Hoff. Literally it was just that, and my name. I knew he'd read my blog, and he smiled in recognition of it: "I'm just going into a briefing", the majestic one replied to me as he glided off across the hall. Still, another name for my "security guy" spotters book.
I had a guy called Karel Rode from CA and ISGAfrica drop me a line last month too. He's a security giant on his continent (far more so than I anyway) and we had some lengthy discussions about user and data security (surprise!).
I'm thinking if I keep this up I should be able to say hello to everyone in security by the time I retire. The thing is, I love it. If you are a security guy, drop me a line, give me something to talk about.
I noticed Mike Rothman quoted my blog again last week, maybe I'll leave a message on his answerphone...
I'm the kindest type of stalker though, I send emails to my victims and if they don't reply I leave them alone. One of the ones who didn't get away was Rich Mogull, security man extraordinaire, a guy I have a lot of respect for, not least because I have worked for a number of the companies he has analysed in his role at Gartner, usually favourably.
So how did I get in touch with the great man? Well, I'm ashamed to admit, although I'm actually quite proud of it too, I used a bit of social engineering. One of the more apt phrases I've heard used in the pages of Security Bloggers Network recently is "flattery injection" attacks. Well, this is basically what I did. I quoted his blog, and said pretty much what I've said here, that I've followed him all my career and that I respect his work. He emailed to say thanks, and I just kept him in dialog.
OK, so it wasn't planned and I have no right to be smug about it. I have no desire to put one over on him anyway, but it was a good way to start the blog. Long story shortened, I got to speak to Rich last week, there was a slight delay on the line which made things a little tricky, I talked over him a couple of times, but I could have gone on all day. Maybe I should have listened more...
Someone once said something about meeting their heroes, only to be disappointed. I wasn't. He was a thoroughly nice chap and he knows LOADS of stuff without being big-headed. I only wish I could have had more time.
Last month I got to say "Hi" to Hoff. Literally it was just that, and my name. I knew he'd read my blog, and he smiled in recognition of it: "I'm just going into a briefing", the majestic one replied to me as he glided off across the hall. Still, another name for my "security guy" spotters book.
I had a guy called Karel Rode from CA and ISGAfrica drop me a line last month too. He's a security giant on his continent (far more so than I anyway) and we had some lengthy discussions about user and data security (surprise!).
I'm thinking if I keep this up I should be able to say hello to everyone in security by the time I retire. The thing is, I love it. If you are a security guy, drop me a line, give me something to talk about.
I noticed Mike Rothman quoted my blog again last week, maybe I'll leave a message on his answerphone...
Saturday, 2 June 2007
Humblest pie - part 3: Data-classification
I'm almost done with my preaching, and parallel apologising to Rory. This should be short and sweet, so I'll end up with a summary and say goodnight.
Data-classification can be done in a number of ways. I'm not 100% sure of the process now I come to think about it, but it basically involves assigning attributes to every single piece of data on your network. This is obviously a massive job, and once it's done, you need to control access to that data. This requires a device in line with the user accessing the data, plus a massive initial effort of data processing. But, this is being done as we speak in a number of very large companies. EMC offer a data classification service, NetApp has OEMed Kazeon, other solutions are attracting huge investment, this is a "right now" opportunity.
The data-classification companies are selling this service as a "de-duping" activity, removing duplicate data from systems to save on storage costs. This is a good way to sell to short-sighted management, but the long term benefits are far greater.
Data-classification allows security to be applied directly to data. Decisions can be made about access to data made on the data's sensitivity level, and clearance level of a user. Data is always kept at an appropriate level of security in storage, and presented to applications with an appropriate level of control.
Summary
Data-classification allows the appropriate level of control in data-centric security systems. Data-centric security allows freer movement of data between user and storage, because a large number of network controls can be removed or consolidated. DRM exists as an endpoint issue, on a network this can be largely solved with application control inside a network context, and physical controls outside of this context. Outside of a network, this is still a very difficult topic to address.
Thanks to Rory McCune for his patience and sticking to his guns. I get what you were talking about now...
Data-classification can be done in a number of ways. I'm not 100% sure of the process now I come to think about it, but it basically involves assigning attributes to every single piece of data on your network. This is obviously a massive job, and once it's done, you need to control access to that data. This requires a device in line with the user accessing the data, plus a massive initial effort of data processing. But, this is being done as we speak in a number of very large companies. EMC offer a data classification service, NetApp has OEMed Kazeon, other solutions are attracting huge investment, this is a "right now" opportunity.
The data-classification companies are selling this service as a "de-duping" activity, removing duplicate data from systems to save on storage costs. This is a good way to sell to short-sighted management, but the long term benefits are far greater.
Data-classification allows security to be applied directly to data. Decisions can be made about access to data made on the data's sensitivity level, and clearance level of a user. Data is always kept at an appropriate level of security in storage, and presented to applications with an appropriate level of control.
Summary
Data-classification allows the appropriate level of control in data-centric security systems. Data-centric security allows freer movement of data between user and storage, because a large number of network controls can be removed or consolidated. DRM exists as an endpoint issue, on a network this can be largely solved with application control inside a network context, and physical controls outside of this context. Outside of a network, this is still a very difficult topic to address.
Thanks to Rory McCune for his patience and sticking to his guns. I get what you were talking about now...
Humbler pie - part 2: Data-centric security
As part of an on-going attempt to spread love throughout the blogging community, I will attempt to explain data-centric security, a love in my life only secondary to my wife (by quite a long way you understand).
So, what is data-centric security?
Quite simply, data-centric security is any security applied to data as opposed to the network, or to users. Most people will be familiar with user security as authentication, authorisation and accounting. The rest of security normally seems to be network based, so you would be forgiven for thinking that this is what security is about. Certainly that's been the argument of a thousand vendors, but apart from securing applications and hosts so that data access cannot be manipulated, what else is really needed on the network?
Consider what you are protecting, and from whom you are protecting it. These are the 2 places you need to protect from manipulation. If you can trust the start of a transaction (user -> data), you can trust the end. That is to say, if you know that you have the correct user identified, you can then protect the data from access by anything other than that user or set of users which are authorised to access it. This of course takes perimeter controls around the data, as discussed with DRM in the previous post, which on a network are still best applied by a device between user and data.
What it does not mean is that devices which currently exist to protect the network are the right ones.
Firewalls
Without revealing my bias about firewalls, consider their purpose for a second. They are to protect networks from intrusion over certain ports. They even now inspect traffic coming over legitimate ports, in an attempt to prove their worth (oops, almost revealed my hatred of them for a moment then!)
Why is this an issue? Well, if an attacker gets onto an unprotected port on a PC or server in your network, he can traverse various controls, take ownership, forge access and steal data.
I'll ask the question again, why is this an issue? In reality it's because applications have holes. OSs have holes, databases have holes, etc. All that firewalls have achieved is to drive the threat inside the firewall. Nowadays 80-90% of attacks come from inside the firewall. Or if you're TJX, the guy outside with the Pringle's can pointing at your wireless network (which is inside the firewall).
Why not just put host based firewalls on each of these vulnerable points and save thousands, plus increase the security of your network from insider threat?
Other devices
I can't think of one other device inside a network which could not be eliminated with an upgrade of hardware or securing of software. Reporting and management tools are just an additional piece of software, which could be incorporated into an upgraded piece of hardware. Proxies, load balancers, anything. There is no need for all of this network security if the host is properly configured.
Convergence
For years more and more capabilities have been appearing on devices on the network, firewalls, IDS, IDP, AV, proxy type filters. These have begun to be placed on a single perimeter device which can deal with all of this functionality, much simplifying network security, and also proving a point. This can all be put on a host. If you put all your applications onto a single host as well, you could shove it all in the same box. What about your data? Why not? If the hardware had the performance capabilities, what's to stop you, apart from catastrophic systems failure? Get 2!
This seems unlikely, I admit, but where is convergence most likely to end up? Will we end up with the return to the mainframe as above, or diverge back out for convenience? I don't know. I wouldn't predict the mainframe model. It is more likely to end up somewhere in the middle.
In my opinion we will end up with a single device at the perimeter, then our web/app tier, then another single device for data control, then the data environment.
The network will be used for transmission of data only, and in the shortest routes possible between these 4 areas. The data device will apply access controls based on user attributes applied at the perimeter device. The data will be classified as to it's security level, and the users will be permitted access to the data based on their security clearance level.
The logic problem
The more secure the data, the more controls will need to be applied in storage. This is where data-centric security really begins, at the end. This is why I love it, because it starts at the end-point and works it way backwards, like a proper logic problem.
Basic level data does not need much protection. Confidential data requires encryption. Data required for legal proof or record retention requires integrity controls. All of it can be compressed to save space. This can all be done in different levels of physical storage, WORM for integrity, locked away for confidentiality, on high performance optical disks for high availability.
Weaknesses
What this solution cannot do is protect the data once it is at the user. At this point, when the user has the data under their control, DRM comes into play. As discussed previously, on a network we have different issues than off a network. In this case we are on a network, but if our data is classified we can more easily apply controls at the application level once we have decided HOW we are going to apply them. A device between application and data can apply per-user application controls on a network which cannot be applied off the network. At this point I have to tip my hat to Rory McCune again, and admit that he is right that applications will have to recognise the data tags to apply the security levels off network, and this is where our original misunderstanding arose from.
On a network therefore, DRM effectively becomes a physical security problem. Stopping shoulder surfing, photographing screens, copying data with a pencil and paper. Off the network, the problems still exist, and this is why DRM is such a big issue.
Addressing this properly, as Rory correctly says again, will require standards, which are already being worked on for the transmission and protection of data on the Semantic Web. Applying the classification is the first step. I'll talk about this tomorrow.
So, what is data-centric security?
Quite simply, data-centric security is any security applied to data as opposed to the network, or to users. Most people will be familiar with user security as authentication, authorisation and accounting. The rest of security normally seems to be network based, so you would be forgiven for thinking that this is what security is about. Certainly that's been the argument of a thousand vendors, but apart from securing applications and hosts so that data access cannot be manipulated, what else is really needed on the network?
Consider what you are protecting, and from whom you are protecting it. These are the 2 places you need to protect from manipulation. If you can trust the start of a transaction (user -> data), you can trust the end. That is to say, if you know that you have the correct user identified, you can then protect the data from access by anything other than that user or set of users which are authorised to access it. This of course takes perimeter controls around the data, as discussed with DRM in the previous post, which on a network are still best applied by a device between user and data.
What it does not mean is that devices which currently exist to protect the network are the right ones.
Firewalls
Without revealing my bias about firewalls, consider their purpose for a second. They are to protect networks from intrusion over certain ports. They even now inspect traffic coming over legitimate ports, in an attempt to prove their worth (oops, almost revealed my hatred of them for a moment then!)
Why is this an issue? Well, if an attacker gets onto an unprotected port on a PC or server in your network, he can traverse various controls, take ownership, forge access and steal data.
I'll ask the question again, why is this an issue? In reality it's because applications have holes. OSs have holes, databases have holes, etc. All that firewalls have achieved is to drive the threat inside the firewall. Nowadays 80-90% of attacks come from inside the firewall. Or if you're TJX, the guy outside with the Pringle's can pointing at your wireless network (which is inside the firewall).
Why not just put host based firewalls on each of these vulnerable points and save thousands, plus increase the security of your network from insider threat?
Other devices
I can't think of one other device inside a network which could not be eliminated with an upgrade of hardware or securing of software. Reporting and management tools are just an additional piece of software, which could be incorporated into an upgraded piece of hardware. Proxies, load balancers, anything. There is no need for all of this network security if the host is properly configured.
Convergence
For years more and more capabilities have been appearing on devices on the network, firewalls, IDS, IDP, AV, proxy type filters. These have begun to be placed on a single perimeter device which can deal with all of this functionality, much simplifying network security, and also proving a point. This can all be put on a host. If you put all your applications onto a single host as well, you could shove it all in the same box. What about your data? Why not? If the hardware had the performance capabilities, what's to stop you, apart from catastrophic systems failure? Get 2!
This seems unlikely, I admit, but where is convergence most likely to end up? Will we end up with the return to the mainframe as above, or diverge back out for convenience? I don't know. I wouldn't predict the mainframe model. It is more likely to end up somewhere in the middle.
In my opinion we will end up with a single device at the perimeter, then our web/app tier, then another single device for data control, then the data environment.
The network will be used for transmission of data only, and in the shortest routes possible between these 4 areas. The data device will apply access controls based on user attributes applied at the perimeter device. The data will be classified as to it's security level, and the users will be permitted access to the data based on their security clearance level.
The logic problem
The more secure the data, the more controls will need to be applied in storage. This is where data-centric security really begins, at the end. This is why I love it, because it starts at the end-point and works it way backwards, like a proper logic problem.
Basic level data does not need much protection. Confidential data requires encryption. Data required for legal proof or record retention requires integrity controls. All of it can be compressed to save space. This can all be done in different levels of physical storage, WORM for integrity, locked away for confidentiality, on high performance optical disks for high availability.
Weaknesses
What this solution cannot do is protect the data once it is at the user. At this point, when the user has the data under their control, DRM comes into play. As discussed previously, on a network we have different issues than off a network. In this case we are on a network, but if our data is classified we can more easily apply controls at the application level once we have decided HOW we are going to apply them. A device between application and data can apply per-user application controls on a network which cannot be applied off the network. At this point I have to tip my hat to Rory McCune again, and admit that he is right that applications will have to recognise the data tags to apply the security levels off network, and this is where our original misunderstanding arose from.
On a network therefore, DRM effectively becomes a physical security problem. Stopping shoulder surfing, photographing screens, copying data with a pencil and paper. Off the network, the problems still exist, and this is why DRM is such a big issue.
Addressing this properly, as Rory correctly says again, will require standards, which are already being worked on for the transmission and protection of data on the Semantic Web. Applying the classification is the first step. I'll talk about this tomorrow.
Humble pie - part 1: DRM
Rory McCune and I have had words this weekend. The posts and comments are too numerous to mention. The basic issue has come down to a couple of misunderstandings, and if Rory can make them, then anyone can, and I should try and clear them up instead of ranting...
First off, I apologise to Rory for biting his head off, he got me at the wrong time, that's all. I then proceeded to do what I hate most about other bloggers, which is to criticise instead of explain. I am an arse. He is a smart and generous guy, and his blog is worth a read.
I'm going to spread this across a number of posts to keep the reader (hopefully more than one) from switching off, but they will basically be the same thread.
What is DRM?
The most familiar form of digital rights management to most readers will be that of Apple's iTunes. This is an "off network" form of DRM, and a valuable problem to crack, but faces economic issues which make this a complex task.
DRM in a network is difficult because networks are fairly porous from the inside out. Documents can be easily printed, copied, emailed and saved to USB or other. Of course it is possible to disable printing, copying and saving. Emailing of attachments or scanning of mails for keywords can be effective as a perimeter control too, but this seems like very tight security for most networks. Even if all of this was implemented, there is nothing to stop someone looking over the CFO's shoulder to read my salary, writing down a list of account numbers from the credit card database, or photographing the screen when logged in as sysadmin.
Digital rights management outside of a network is essentially a way of sending data protection along with the data. This is also extremely hard to achieve. DRM is achieved by packaging a file with some sort of license. If the license is not activated, or becomes inactive, the file will not open. The license also controls copying and printing of the content. This requires perimeter controls built around the data.
The problem with this type of DRM is that you have to send the controls along with the files. These perimeter controls are then in the hands of the very people who want to attack them.
DRM on music files has proved incredibly unpopular, Apple's iTunes has been under constant attack from users because of the problems it causes in transferring music between systems. Apple have had to patch their DRM systems continually to beat the crackers.
(They also had a lawsuit brought by the Beatles, because they promised not to enter the music business with the Apple brand, as it was the same name as the Beatles' record company. Then came iTunes, and Apple entered the music business in a fairly big way. You still won't find Beatles tunes on iTunes, but that's another matter entirely...)
DRM is probably the toughest security to achieve, largely because of the nature of that security.
On the network, with current capabilities, you can achieve DRM by applying too much security. Thich disables business processes as much as securing the network. Or you can apply hardly any security, in which case you lose control of the data very quickly.
Off-network DRM is an economic tool as much as a security tool, it forces users to pay for access to a file. In an ordinary network the administrators have the control over the access rights, and it is they who need to enforce this and pay for it, so there is no conflict of interest. With DRM, the user pays, but the administrators still want to enforce. Unsurprisingly, the users try to take access into their own hands.
DRM is just one (very visible) part of data-centric security. In my next post I will be examining data-centric security, before moving on to data-classification, and an attempt at explaining all the different subsets that each of these fits into.
First off, I apologise to Rory for biting his head off, he got me at the wrong time, that's all. I then proceeded to do what I hate most about other bloggers, which is to criticise instead of explain. I am an arse. He is a smart and generous guy, and his blog is worth a read.
I'm going to spread this across a number of posts to keep the reader (hopefully more than one) from switching off, but they will basically be the same thread.
What is DRM?
The most familiar form of digital rights management to most readers will be that of Apple's iTunes. This is an "off network" form of DRM, and a valuable problem to crack, but faces economic issues which make this a complex task.
DRM in a network is difficult because networks are fairly porous from the inside out. Documents can be easily printed, copied, emailed and saved to USB or other. Of course it is possible to disable printing, copying and saving. Emailing of attachments or scanning of mails for keywords can be effective as a perimeter control too, but this seems like very tight security for most networks. Even if all of this was implemented, there is nothing to stop someone looking over the CFO's shoulder to read my salary, writing down a list of account numbers from the credit card database, or photographing the screen when logged in as sysadmin.
Digital rights management outside of a network is essentially a way of sending data protection along with the data. This is also extremely hard to achieve. DRM is achieved by packaging a file with some sort of license. If the license is not activated, or becomes inactive, the file will not open. The license also controls copying and printing of the content. This requires perimeter controls built around the data.
The problem with this type of DRM is that you have to send the controls along with the files. These perimeter controls are then in the hands of the very people who want to attack them.
DRM on music files has proved incredibly unpopular, Apple's iTunes has been under constant attack from users because of the problems it causes in transferring music between systems. Apple have had to patch their DRM systems continually to beat the crackers.
(They also had a lawsuit brought by the Beatles, because they promised not to enter the music business with the Apple brand, as it was the same name as the Beatles' record company. Then came iTunes, and Apple entered the music business in a fairly big way. You still won't find Beatles tunes on iTunes, but that's another matter entirely...)
DRM is probably the toughest security to achieve, largely because of the nature of that security.
On the network, with current capabilities, you can achieve DRM by applying too much security. Thich disables business processes as much as securing the network. Or you can apply hardly any security, in which case you lose control of the data very quickly.
Off-network DRM is an economic tool as much as a security tool, it forces users to pay for access to a file. In an ordinary network the administrators have the control over the access rights, and it is they who need to enforce this and pay for it, so there is no conflict of interest. With DRM, the user pays, but the administrators still want to enforce. Unsurprisingly, the users try to take access into their own hands.
DRM is just one (very visible) part of data-centric security. In my next post I will be examining data-centric security, before moving on to data-classification, and an attempt at explaining all the different subsets that each of these fits into.
Backtracking
I had a couple of complaints recently about not doing track-back on some of my posts. I guess that happens when more people start reading your posts, whether they hate them or love them. So that's a good thing as far as I am concerned.
Rory, who may not be loving me at present, was only aware that I blogged about him because of a comment that Hoff made about not tracking back. He may well have been referring to me also, because I refered to a post of his and then emailed him about it.
I was going to move to WordPress, but having to email half a dozen people to change registration details didn't appeal, having to export and import didn't appeal, and basically I'm just damn lazy.
So, imagine my delight when I came across Haloscan. If you're on Blogger and have similar problems, give it a go. If only to keep Hoff happy.
Rory, who may not be loving me at present, was only aware that I blogged about him because of a comment that Hoff made about not tracking back. He may well have been referring to me also, because I refered to a post of his and then emailed him about it.
I was going to move to WordPress, but having to email half a dozen people to change registration details didn't appeal, having to export and import didn't appeal, and basically I'm just damn lazy.
So, imagine my delight when I came across Haloscan. If you're on Blogger and have similar problems, give it a go. If only to keep Hoff happy.
Comment on comment about comments.
OK, so did I over-react to Rory bad-mouthing data-centric security? He thinks so. Maybe I did. Maybe because I know he is a CISSP and respected blogger I didn't give him as much leeway as mere mortals. However, I think my motives have also been misunderstood, read on...
He made the following points, which I will comment on in turn:
"Thanks for replying (although I almost missed your comment no trackback!). I must say I'm a bit dissapointed, in that I thought I raised some valid points in a reasonably constructive way, but seem to have annoyed you a bit."
Blogger has no trackback facility, which is becoming testing. I may well move to WordPress soon, but that has it's own difficulties. My reaction was timing more than anything, but since when was "Data-centric security... Yeuch" constructive? Let's move on.
"1. How do you mean I don't have to manage it [tagged data]? My role is at a corporate and one of the challenges I see in corporates implementing this kind of security is that without standards it'll be impossible for it to work."
I'm aware of Rory's role, and the corporate which he works for. It is very large, he must be pretty good. I am very pleased to have a fellow Brit in the network, and someone who has worked in finance. I have no desire to challenge the professionalism of either Rory or his company. Of course they need standards.
However, what I was talking about amounts to rulesets, which are essentially internal technical standards, as I thought was very well explained by Hoff in his post. The data tagging never needs to leave your network, that's the point. There's a very low management overhead once the tagging is done. The only standards need to be between your data and the device which tagged them.
By the way, this will evolve into standards when it needs to, when data-classification becomes viable on the Web. This needs to happen in steps however, the first one being some take-up of this technology before we can prove how easy it is to control the data. Once the data is proven to be controllable we can start to externalise it with less risk. This is essentially what people are referring to as Web 3.0, the Semantic Web. In fact I could argue that RDF was a standard, but I'm not getting into that now...
"2. You've not really passed on anything new to this. Again in many companies I've worked with the idea of getting users to understand and manage security rights has caused a load of problems and I think that anything else which adds to that burden is probably a non-starter."
I wasn't trying to pass on anything new, but I again I fail to see why this is relevant. You should be a politician. You were bad-mouthing Hoff's excellent post, I was postulating an opposing view.
This is the nature of debate. I don't want a debate about how to debate however, the debate itself is much more interesting. So, back to the matter in hand:
Why would the users have to even know about it? I don't get this argument. The point with data-centric security is that the security is applied as far away from the users as possible. The only thing the user has to do is authenticate properly, the rest of the decisions are made on his behalf. A network device maps users to profiles to classified data as per a ruleset. I think Chris was pretty clear on this in his post.
I'm not a big fan of network devices by the way, but what Crossbeam and other UTM devices provide is a jump-off point for security to evolve faster. Once the standards you talk about are in place, the device will no longer be such a requirement, but because it's UTM, something else will take the place of the data security. I can see a need for a UTM box for evolution purposes.
"3. Didn't think I said it too hard. Wouldn't you agree that the only DRM usage (music files) that has had widespread take-up has been, in my opinion, a disaster. Now I'm not familiar with EMC etcs DRM products and how they solve these problems, perhaps you could tell me more about that."
I understood what Rory said very clearly. He seems to have missed what I said in return. He seems to be throwing up smokescreens.
Yes, music DRM has been a failure. However, music files which I am trying to sell to the public are not the same as corporate files I am trying to keep secret, and the security surrounding them needs to be handled differently. Personally I wouldn't bother with anything other than a digital watermark or similar on MP3s and MPGs. There is a very strong economic argument that it doesn't really affect sales either way these days, for exactly the reasons you are talking about.
In a corporate environment however we aren't trying to get the public interested in our data, we are trying to keep them away from it.
But when did I say EMC did DRM stuff? EMC has a data-classification service, as do most of the big storage vendors. I will let them do their own sales though, they are big enough.
I'm talking about data-classification, it's Rory who has turned this into a DRM argument because this one (very small) area of data security supports his arguments. I will post on DRM soon which shows why I think it is largely irrelevant to logical security.
[In a moment of clarity however, I think I'm beginning to see the problem here. Let me get this straight DRM= part of data-centric security, data-classification= the basis of data-centric security, DRM does not = data-classification or data-centric security as a whole. I am NOT talking about data controlling who accesses it by itself. Neither is Hoff, neither is anyone else who is not on drugs.]
"4. Sorry I've NEVER seen those models of security used outside the military and the police. Modern corporates in my experience all use DAC style because there are no products which are considered manageable which implement those pieces."
There are commercial products available for data classification. There are commercial products available that provide frameworks for data access controls as specified by the models we talked about too. Not many, but that security is in a poor state is part of my point. It's astonishing how few people understand it, and that's what really bugs me, especially when they put it down without knowing what they are talking about. I'm trying to push it forwards, Hoff is trying to push it forwards, by educating. We are both vendors trying to push products, but the market needs to understand. It's hard enough appealing to users when they are having trouble understanding, but when other security people are, it's practically impossible.
Maybe these models aren't used outside the military, but that doesn't mean a) you haven't studied them, b) they don't work, and c) they wouldn't be manageable - quite the opposite. Rory is confusing established security models with products which are not on the shelf yet. I never implied they were, just that they are a great idea. Are you saying that you don't want military style security on your network, Rory?
"Yes I have studied security for many years thanks. Just because I don't think that one direction that people are going in for security is the best doesn't mean I'm anti-security. What I've found however is that companies are focused on having information available to make business decisions and any security measure that makes that difficult/impossible is not one which will see wide adoption."
Many years in security, we all know how frustrating that can be. You have to admit that it's pretty dull these days once you know what your options are. Corporate lapdog doing the bidding of the CEO, CFO and CIO, consultant searching for business in a world full of security consultants who are undercutting you because they're not as good, or change of direction altogether. That's why I'm a product manager at a software company, trying to make things change, because I had the opportunity, and because I can (it's where all the best people end up, right Chris?).
I certainly didn't mean to imply Rory was anti-security. I'm positive he is very good at his job. His current employer certainly wouldn't have employed him if he weren't. I have no reason to imply otherwise. What I don't like is attacks on data-centric security without careful consideration of the facts, or as it seems, not understanding it.
It shouldn't make anything more difficult business-wise, in fact it should make things easier. There are some very strong arguments for data classification. The first one being that if you identify your data, you will know if you have duplicates. This is an instant ROI of about 20-30% on current infrastructure.
Once this is done, the rest of the game is child's play. Install a device somewhere at the perimeter to control access to the data, and put some rules in it. These never have to change. Only user attributes have to change. The rest of the network can be used to transfer data, quickly and freely without the need to pass it through a hundred devices. It should speed up communication and make it more efficient, add confidentiality and integrity, and not affect availability.
It's more about alignment of users and data.
Consider this:
FACT: There is very little data security at present. It's evolving fast.
FACT: The Semantic Web will require data-centric security before it can evolve safely.
FACT: Every decent security company under the sun has been bought up by a storage company recently. What do you reckon they're doing?
FACT: I'm a vendor of data integrity products. The market is huge and completely untapped. Many people talk like Rory, but the early adopters and visionaries are loving this stuff. This is usually a sign that the market will follow. We have some very large partners and plenty of investors (although we always want more). Not bad for 15 people based in Spain.
Data is the future of security, whether you're comfortable with it or not.
He made the following points, which I will comment on in turn:
"Thanks for replying (although I almost missed your comment no trackback!). I must say I'm a bit dissapointed, in that I thought I raised some valid points in a reasonably constructive way, but seem to have annoyed you a bit."
Blogger has no trackback facility, which is becoming testing. I may well move to WordPress soon, but that has it's own difficulties. My reaction was timing more than anything, but since when was "Data-centric security... Yeuch" constructive? Let's move on.
"1. How do you mean I don't have to manage it [tagged data]? My role is at a corporate and one of the challenges I see in corporates implementing this kind of security is that without standards it'll be impossible for it to work."
I'm aware of Rory's role, and the corporate which he works for. It is very large, he must be pretty good. I am very pleased to have a fellow Brit in the network, and someone who has worked in finance. I have no desire to challenge the professionalism of either Rory or his company. Of course they need standards.
However, what I was talking about amounts to rulesets, which are essentially internal technical standards, as I thought was very well explained by Hoff in his post. The data tagging never needs to leave your network, that's the point. There's a very low management overhead once the tagging is done. The only standards need to be between your data and the device which tagged them.
By the way, this will evolve into standards when it needs to, when data-classification becomes viable on the Web. This needs to happen in steps however, the first one being some take-up of this technology before we can prove how easy it is to control the data. Once the data is proven to be controllable we can start to externalise it with less risk. This is essentially what people are referring to as Web 3.0, the Semantic Web. In fact I could argue that RDF was a standard, but I'm not getting into that now...
"2. You've not really passed on anything new to this. Again in many companies I've worked with the idea of getting users to understand and manage security rights has caused a load of problems and I think that anything else which adds to that burden is probably a non-starter."
I wasn't trying to pass on anything new, but I again I fail to see why this is relevant. You should be a politician. You were bad-mouthing Hoff's excellent post, I was postulating an opposing view.
This is the nature of debate. I don't want a debate about how to debate however, the debate itself is much more interesting. So, back to the matter in hand:
Why would the users have to even know about it? I don't get this argument. The point with data-centric security is that the security is applied as far away from the users as possible. The only thing the user has to do is authenticate properly, the rest of the decisions are made on his behalf. A network device maps users to profiles to classified data as per a ruleset. I think Chris was pretty clear on this in his post.
I'm not a big fan of network devices by the way, but what Crossbeam and other UTM devices provide is a jump-off point for security to evolve faster. Once the standards you talk about are in place, the device will no longer be such a requirement, but because it's UTM, something else will take the place of the data security. I can see a need for a UTM box for evolution purposes.
"3. Didn't think I said it too hard. Wouldn't you agree that the only DRM usage (music files) that has had widespread take-up has been, in my opinion, a disaster. Now I'm not familiar with EMC etcs DRM products and how they solve these problems, perhaps you could tell me more about that."
I understood what Rory said very clearly. He seems to have missed what I said in return. He seems to be throwing up smokescreens.
Yes, music DRM has been a failure. However, music files which I am trying to sell to the public are not the same as corporate files I am trying to keep secret, and the security surrounding them needs to be handled differently. Personally I wouldn't bother with anything other than a digital watermark or similar on MP3s and MPGs. There is a very strong economic argument that it doesn't really affect sales either way these days, for exactly the reasons you are talking about.
In a corporate environment however we aren't trying to get the public interested in our data, we are trying to keep them away from it.
But when did I say EMC did DRM stuff? EMC has a data-classification service, as do most of the big storage vendors. I will let them do their own sales though, they are big enough.
I'm talking about data-classification, it's Rory who has turned this into a DRM argument because this one (very small) area of data security supports his arguments. I will post on DRM soon which shows why I think it is largely irrelevant to logical security.
[In a moment of clarity however, I think I'm beginning to see the problem here. Let me get this straight DRM= part of data-centric security, data-classification= the basis of data-centric security, DRM does not = data-classification or data-centric security as a whole. I am NOT talking about data controlling who accesses it by itself. Neither is Hoff, neither is anyone else who is not on drugs.]
"4. Sorry I've NEVER seen those models of security used outside the military and the police. Modern corporates in my experience all use DAC style because there are no products which are considered manageable which implement those pieces."
There are commercial products available for data classification. There are commercial products available that provide frameworks for data access controls as specified by the models we talked about too. Not many, but that security is in a poor state is part of my point. It's astonishing how few people understand it, and that's what really bugs me, especially when they put it down without knowing what they are talking about. I'm trying to push it forwards, Hoff is trying to push it forwards, by educating. We are both vendors trying to push products, but the market needs to understand. It's hard enough appealing to users when they are having trouble understanding, but when other security people are, it's practically impossible.
Maybe these models aren't used outside the military, but that doesn't mean a) you haven't studied them, b) they don't work, and c) they wouldn't be manageable - quite the opposite. Rory is confusing established security models with products which are not on the shelf yet. I never implied they were, just that they are a great idea. Are you saying that you don't want military style security on your network, Rory?
"Yes I have studied security for many years thanks. Just because I don't think that one direction that people are going in for security is the best doesn't mean I'm anti-security. What I've found however is that companies are focused on having information available to make business decisions and any security measure that makes that difficult/impossible is not one which will see wide adoption."
Many years in security, we all know how frustrating that can be. You have to admit that it's pretty dull these days once you know what your options are. Corporate lapdog doing the bidding of the CEO, CFO and CIO, consultant searching for business in a world full of security consultants who are undercutting you because they're not as good, or change of direction altogether. That's why I'm a product manager at a software company, trying to make things change, because I had the opportunity, and because I can (it's where all the best people end up, right Chris?).
I certainly didn't mean to imply Rory was anti-security. I'm positive he is very good at his job. His current employer certainly wouldn't have employed him if he weren't. I have no reason to imply otherwise. What I don't like is attacks on data-centric security without careful consideration of the facts, or as it seems, not understanding it.
It shouldn't make anything more difficult business-wise, in fact it should make things easier. There are some very strong arguments for data classification. The first one being that if you identify your data, you will know if you have duplicates. This is an instant ROI of about 20-30% on current infrastructure.
Once this is done, the rest of the game is child's play. Install a device somewhere at the perimeter to control access to the data, and put some rules in it. These never have to change. Only user attributes have to change. The rest of the network can be used to transfer data, quickly and freely without the need to pass it through a hundred devices. It should speed up communication and make it more efficient, add confidentiality and integrity, and not affect availability.
It's more about alignment of users and data.
Consider this:
FACT: There is very little data security at present. It's evolving fast.
FACT: The Semantic Web will require data-centric security before it can evolve safely.
FACT: Every decent security company under the sun has been bought up by a storage company recently. What do you reckon they're doing?
FACT: I'm a vendor of data integrity products. The market is huge and completely untapped. Many people talk like Rory, but the early adopters and visionaries are loving this stuff. This is usually a sign that the market will follow. We have some very large partners and plenty of investors (although we always want more). Not bad for 15 people based in Spain.
Data is the future of security, whether you're comfortable with it or not.
Friday, 1 June 2007
A kick in the teeth
Obviously SOMEONE didn't read my plea yesterday, so I will repeat: "please, please, please, think about what you are writing before you bombard us with rubbish". Anyone titling a piece of writing with something this negative is obviously after a scrap, so, as I also said yesterday, bring it on.
Rory McCune cites Chris's (Hoff) article from this morning about data security. An article which is one of the most well thought out, well presented and well explained that I've ever read on the pages of this network. An article which made me feel happy, it has network diagrams and everything.
That happiness has all gone now, turned into bitter bile (by a thoughtless reactive post - much like this one), which I now present to you for digestion. (Urgh, sorry to be so biological.)
"One: there's no widely agreed on DRM open standard that companies are applying now. "
1. It was a theoretical argument, but if you're going to be picky, so am I.
2. It really doesn't need it though does it? If you are applying classifications to the data, and you have a Crossbeam box (not that I'm marketing Crossbeam, but this is what the post was about) between user and data, the box, as Chris says, can make the intelligent decision based on the device, which is presented to it, and the data it is trying to access, which it knows all about. That's why there's a rule set. It's all there, the device just has to be tied to a user. Just like you should be as punishment.
"Two: More importantly the idea of assigning security levels to individual data items or collections of data items seems really un-manageable to me."
1. It's lucky you don't have to manage it then isn't it? That's what we have computers for.
2. Tell this to Njini who are running a whole business on this premise (and doing quite nicely too).
3. Tell it to EMC, Hitachi or NetApp for that matter. Guys, you're getting it wrong, Rory said. It's really hard.
4. Tell it to the military, Biba, Clark, Wilson, Bell and Lapadula. I KNOW you have a CISSP hidden somewhere in that brain of yours, maybe dust the books off and have a read?
(5. Tell it to Hoff, far scarier to deal with. The ginger ninja will have his own way with you though, of that I'm sure.)
Oh god, I'm getting angry just sitting at my desk. Time for acoffee break tranquilizer.
"Three: Data-centric security has been trialed recently in a large multi-company multi-system environment that everyone's heard of and it's been a complete disaster, which is DRM on music files."
1. This is an argument about economics. I'd like to hear Jon Robinson's take on this.
2. A private network is typically trying to restrict access, therefore availability, and increase confidentiality and integrity. Your example is trying to increase availability, whilst keeping confidentiality and integrity, which is next to impossible. Did you ever study security?
I could go on, but I'm sick and tired. I KNEW this would happen.
Rory McCune cites Chris's (Hoff) article from this morning about data security. An article which is one of the most well thought out, well presented and well explained that I've ever read on the pages of this network. An article which made me feel happy, it has network diagrams and everything.
That happiness has all gone now, turned into bitter bile (by a thoughtless reactive post - much like this one), which I now present to you for digestion. (Urgh, sorry to be so biological.)
"One: there's no widely agreed on DRM open standard that companies are applying now. "
1. It was a theoretical argument, but if you're going to be picky, so am I.
2. It really doesn't need it though does it? If you are applying classifications to the data, and you have a Crossbeam box (not that I'm marketing Crossbeam, but this is what the post was about) between user and data, the box, as Chris says, can make the intelligent decision based on the device, which is presented to it, and the data it is trying to access, which it knows all about. That's why there's a rule set. It's all there, the device just has to be tied to a user. Just like you should be as punishment.
"Two: More importantly the idea of assigning security levels to individual data items or collections of data items seems really un-manageable to me."
1. It's lucky you don't have to manage it then isn't it? That's what we have computers for.
2. Tell this to Njini who are running a whole business on this premise (and doing quite nicely too).
3. Tell it to EMC, Hitachi or NetApp for that matter. Guys, you're getting it wrong, Rory said. It's really hard.
4. Tell it to the military, Biba, Clark, Wilson, Bell and Lapadula. I KNOW you have a CISSP hidden somewhere in that brain of yours, maybe dust the books off and have a read?
(5. Tell it to Hoff, far scarier to deal with. The ginger ninja will have his own way with you though, of that I'm sure.)
Oh god, I'm getting angry just sitting at my desk. Time for a
"Three: Data-centric security has been trialed recently in a large multi-company multi-system environment that everyone's heard of and it's been a complete disaster, which is DRM on music files."
1. This is an argument about economics. I'd like to hear Jon Robinson's take on this.
2. A private network is typically trying to restrict access, therefore availability, and increase confidentiality and integrity. Your example is trying to increase availability, whilst keeping confidentiality and integrity, which is next to impossible. Did you ever study security?
I could go on, but I'm sick and tired. I KNEW this would happen.
Subscribe to:
Posts (Atom)