The Business Is A Customer? ... Information Security?
@ Aug. 7, 2010, 2:43 p.m.
Filed under: Philosophy Tech
Before I start let me give you this warning: I'm tired, cranky and need a nap. I also badly need a shower. Now enjoy my mad rambling ...
Many companies have implemented or are implementing the ITIL Framework within their organization. That usually is a good thing. If done right it brings a common, repeatable process that can be done and tracked for accuracy. Of course, this also can be done wrong which creates gates and bottlenecks, process for process sake, overhead, confusion and special cases in the name of pragmatism .. but I'm not going to talk about that here. I do want to talk about a common idea that seems to tie back with ITIL in many cases and that is IT is the vendor, the business is the customer.
When one thinks of the business/customer relationship usually one simple aspect of it comes to mind. That one aspect is that the customer gets what the customer wants (aka the customer is always right). If the customer is not happy they will go somewhere else. If the customer can get it cheaper elsewhere they will go elsewhere. Generally this is a good thing. It means that there is competition and the lowest price with the highest quality product or service will keep driving other vendors to match or find related services to enhance their products. But how does this actually fit with Information Security within IT and it's greater Business unit(s)?
The short answer is it does not :-) (surprise!). In some ways ITIL attempts to remedy (no pun intended) this with ITIL Security Management which holds true to the CIA triad and requires that InfoSec have documented policies that the company follows (among other things). ITIL Security Management can work, but what about the customer, do they want this?
Here is where things break down in my opinion. When it comes to purchasing a product or service in the real world the burden and effects are on the customer. For instance, if someone buys a chainsaw it will give them a warnings about how they should use it (and how not to use it). The customer can still cut his leg off, but that is the customers fault, the vendor is not responsible nor is hurt by the action (yes, there are exceptions where legal action is taken against a company who didn't provide a disclaimer or warning ...). Using a service example, if someone takes a taxi, opens the door in transit and falls out it's not the taxis fault ... the customer did the action and suffers the burden and effects of the action. It's easy to look at the examples and say they are simple and don't apply ... everyone knows not to fall out of a moving car or take a chainsaw to the leg. It's common sense not to hurt yourself! One could says the same thing about opening up that PDF from an unknown sender too yet business users do this all of the time. This is where the first issue comes into play: The Customer (aka the business) believes they know how to use the tools properly and safely. Of course some can, but a good many of them can not and fall in the camp of being lucky (or pwned and unlucky enough not to know). So how does a traditional vendor tell their customer they are acting risky? If it is a product vendor they will more than likely send a notice or a fix to the customer to let them know there is an issue. They can use the fix or continue using the problematic product at their own risk. If it is a service vendor then sadly the answer is they don't unless it also puts the vendor at risk. If it does put the vendor at risk the action is to usually cut service or, at the very least, cripple the service in such a way that the customer can not cause any harm to the vendor.I don't know about you but I can't see that conversation going well if it's IT as the vendor and the Business as the customer ... unless it's so painfully obvious that someones great grandfather could understand is an issue the customer will get their way. Even if one takes the product route of things, the customer still must use said fix but in the case of a company failure to use the fix can be disastrous to everyone, not just them.
The second issue is that of process. I'm going to use an ITIL implementation as an example but this can be for any process. Let's say that someone from a large printing companies InfoSec group has found an issue. To make things simple, let's say it's a public issue found in Adobe software (there have been tons of them in the last year or so). The company in question gets PDF's from reporters, advertisers, managers, spammers, etc.. This means the the member of InfoSec needs to put in a change request to get the software updated to a safe patched version. Problem is, this will take some time. In fact, it may never get done as the customer may complain they don't have time for petty upgrades ... they have "real" work to do. Putting aside that "real" work probably means 30-40% of their day surfing Facebook and Twitter, this is obviously a problem. The customer does not want to take the small inconvenience to protect themselves and the company. If this is something that IT can do without the need to involve the users then the change will likely be held up in process while it goes through multiple approval layers by people who don't really understand the issue at hand (either way meaning the fix will be delayed increasing the time of vulnerability), which brings us to the third issue.
The third issue is that of the education of those who make the decisions. A good manager understands what his people do on a day to day basis. They also understand the basics of how they do it and what the results mean. They understand more than just 'this is bad' or 'this is good'. In terms of Information Security, simple concepts like data exfiltration or why cross-site scripting is a problem are a must just like understanding basic economics is needed for a manager of a finance department. The problem lies in that as you go up, the understanding of basic concepts goes down. This is not because the people get dumber as you go up (well, hopefully not :-)) but because they have a larger amount of information they should understand. The natural response is to understand all of it in such a shallow manor that you essential understand none of it. By the time you hit those who are actually approving changes basic concepts may seem like abstract tech talk or, even worse, unintelligible alien language (run far away if this is the case ...). Add in that pressure from the customer and politics at this layer and things get tougher. How can any InfoSec engineer work in a situation like that and be productive? By the time the update is approved there is a good chance there is already one or more updates to the same piece of software that need to be applied. Get ready to go through the explanation process again even if it is the exact same issue.
There are more reasons I'm sure. I've been thinking about this for months trying to find a good way that it could actually work and I'm at a total loss. The only way I can see IT InfoSec and Business Units working in unison is if they work together and not in a vendor/customer or master/slave relationship. It seems I'm not the only one with this thought. For instance, Ivar Jacobson has written about breaking out of Business as the Customer mentality.
The next time the business as the customer asks for this:
and you catch them doing this:
... either cry and plan the funeral or smile and bring dead fish to throw in with them.
digg it
seed it
del.icio.us
ma.gnolia
Comments: 0
iPhone4 vs HTC Evo or She Doesn't Care @ June 29, 2010, 9:59 a.m.
Filed under: Philosophy Comedy Tech
Warning: Strong Language
digg it
seed it
del.icio.us
ma.gnolia
Comments: 0
Theory: Why Business People Are Crazy @ Feb. 1, 2010, 10:56 a.m.
Filed under: Philosophy Comedy Tech
I've always wondered why business people (marketing, PR, sales, etc..) make little to no sense when they talk about technology including whatever tech they think will make their life magically easy. I happened to come across a company advertising it's services as a low cost development shop to outsource to. As an engineer, I know that outsourcing works in so few cases it's not really worth looking at (unless you are trying to cut costs and get a promotion quickly ignoring the end result of the work). In any case, here is some of their marketing material. Be prepared to be confused (or inspired if you are a business person).
Is your brain fried yet? If so, put on a suit and SELL SELL SELL!
digg it
seed it
del.icio.us
ma.gnolia
Comments: 0
Answered: Question To Palm Over SDK Agreement @ July 25, 2009, 5:02 p.m.
Filed under: Philosophy Code Tech
Palm responded to my Pre sdk legal question via twitter with in a few days of my original post. One can make free software tool implementations as long as no palm code is used. I'm quite happy with that answer. So far I've been very impressed with Palm's ability to stay connected with it's community instead of throwing the devices over the fence and then focusing on it's replacement (like some other companies have been doing).
digg it
seed it
del.icio.us
ma.gnolia
Comments: 0
Question To Palm Over SDK Agreement @ July 17, 2009, 8:41 p.m.
Filed under: Personal Philosophy Code Tech
I am not a lawyer, but when I read the TOS agreement I feel like it is saying that if you use the SDK you can not reimplement any of the tools ...
digg it
seed it
del.icio.us
ma.gnolia
Comments: 0
Filed under: Philosophy Tech
Before I start let me give you this warning: I'm tired, cranky and need a nap. I also badly need a shower. Now enjoy my mad rambling ...
Many companies have implemented or are implementing the ITIL Framework within their organization. That usually is a good thing. If done right it brings a common, repeatable process that can be done and tracked for accuracy. Of course, this also can be done wrong which creates gates and bottlenecks, process for process sake, overhead, confusion and special cases in the name of pragmatism .. but I'm not going to talk about that here. I do want to talk about a common idea that seems to tie back with ITIL in many cases and that is IT is the vendor, the business is the customer.
When one thinks of the business/customer relationship usually one simple aspect of it comes to mind. That one aspect is that the customer gets what the customer wants (aka the customer is always right). If the customer is not happy they will go somewhere else. If the customer can get it cheaper elsewhere they will go elsewhere. Generally this is a good thing. It means that there is competition and the lowest price with the highest quality product or service will keep driving other vendors to match or find related services to enhance their products. But how does this actually fit with Information Security within IT and it's greater Business unit(s)?
The short answer is it does not :-) (surprise!). In some ways ITIL attempts to remedy (no pun intended) this with ITIL Security Management which holds true to the CIA triad and requires that InfoSec have documented policies that the company follows (among other things). ITIL Security Management can work, but what about the customer, do they want this?
Here is where things break down in my opinion. When it comes to purchasing a product or service in the real world the burden and effects are on the customer. For instance, if someone buys a chainsaw it will give them a warnings about how they should use it (and how not to use it). The customer can still cut his leg off, but that is the customers fault, the vendor is not responsible nor is hurt by the action (yes, there are exceptions where legal action is taken against a company who didn't provide a disclaimer or warning ...). Using a service example, if someone takes a taxi, opens the door in transit and falls out it's not the taxis fault ... the customer did the action and suffers the burden and effects of the action. It's easy to look at the examples and say they are simple and don't apply ... everyone knows not to fall out of a moving car or take a chainsaw to the leg. It's common sense not to hurt yourself! One could says the same thing about opening up that PDF from an unknown sender too yet business users do this all of the time. This is where the first issue comes into play: The Customer (aka the business) believes they know how to use the tools properly and safely. Of course some can, but a good many of them can not and fall in the camp of being lucky (or pwned and unlucky enough not to know). So how does a traditional vendor tell their customer they are acting risky? If it is a product vendor they will more than likely send a notice or a fix to the customer to let them know there is an issue. They can use the fix or continue using the problematic product at their own risk. If it is a service vendor then sadly the answer is they don't unless it also puts the vendor at risk. If it does put the vendor at risk the action is to usually cut service or, at the very least, cripple the service in such a way that the customer can not cause any harm to the vendor.I don't know about you but I can't see that conversation going well if it's IT as the vendor and the Business as the customer ... unless it's so painfully obvious that someones great grandfather could understand is an issue the customer will get their way. Even if one takes the product route of things, the customer still must use said fix but in the case of a company failure to use the fix can be disastrous to everyone, not just them.
The second issue is that of process. I'm going to use an ITIL implementation as an example but this can be for any process. Let's say that someone from a large printing companies InfoSec group has found an issue. To make things simple, let's say it's a public issue found in Adobe software (there have been tons of them in the last year or so). The company in question gets PDF's from reporters, advertisers, managers, spammers, etc.. This means the the member of InfoSec needs to put in a change request to get the software updated to a safe patched version. Problem is, this will take some time. In fact, it may never get done as the customer may complain they don't have time for petty upgrades ... they have "real" work to do. Putting aside that "real" work probably means 30-40% of their day surfing Facebook and Twitter, this is obviously a problem. The customer does not want to take the small inconvenience to protect themselves and the company. If this is something that IT can do without the need to involve the users then the change will likely be held up in process while it goes through multiple approval layers by people who don't really understand the issue at hand (either way meaning the fix will be delayed increasing the time of vulnerability), which brings us to the third issue.
The third issue is that of the education of those who make the decisions. A good manager understands what his people do on a day to day basis. They also understand the basics of how they do it and what the results mean. They understand more than just 'this is bad' or 'this is good'. In terms of Information Security, simple concepts like data exfiltration or why cross-site scripting is a problem are a must just like understanding basic economics is needed for a manager of a finance department. The problem lies in that as you go up, the understanding of basic concepts goes down. This is not because the people get dumber as you go up (well, hopefully not :-)) but because they have a larger amount of information they should understand. The natural response is to understand all of it in such a shallow manor that you essential understand none of it. By the time you hit those who are actually approving changes basic concepts may seem like abstract tech talk or, even worse, unintelligible alien language (run far away if this is the case ...). Add in that pressure from the customer and politics at this layer and things get tougher. How can any InfoSec engineer work in a situation like that and be productive? By the time the update is approved there is a good chance there is already one or more updates to the same piece of software that need to be applied. Get ready to go through the explanation process again even if it is the exact same issue.
There are more reasons I'm sure. I've been thinking about this for months trying to find a good way that it could actually work and I'm at a total loss. The only way I can see IT InfoSec and Business Units working in unison is if they work together and not in a vendor/customer or master/slave relationship. It seems I'm not the only one with this thought. For instance, Ivar Jacobson has written about breaking out of Business as the Customer mentality.
The next time the business as the customer asks for this:
and you catch them doing this:
... either cry and plan the funeral or smile and bring dead fish to throw in with them.
digg it
seed it
del.icio.us
ma.gnolia
Comments: 0
iPhone4 vs HTC Evo or She Doesn't Care @ June 29, 2010, 9:59 a.m.
Filed under: Philosophy Comedy Tech
Warning: Strong Language
digg it
seed it
del.icio.us
ma.gnolia
Comments: 0
Theory: Why Business People Are Crazy @ Feb. 1, 2010, 10:56 a.m.
Filed under: Philosophy Comedy Tech
I've always wondered why business people (marketing, PR, sales, etc..) make little to no sense when they talk about technology including whatever tech they think will make their life magically easy. I happened to come across a company advertising it's services as a low cost development shop to outsource to. As an engineer, I know that outsourcing works in so few cases it's not really worth looking at (unless you are trying to cut costs and get a promotion quickly ignoring the end result of the work). In any case, here is some of their marketing material. Be prepared to be confused (or inspired if you are a business person).
What you are using our software? Unlike the other software you buy. For our software is the tool, if deployed, or a professional you must learn to apply themselves will not achieve the desired effect. When using our software than the software you buy (the tools) you will be advised and supported during implementation of the software, and you will be maintaining the software during operating software.
Is your brain fried yet? If so, put on a suit and SELL SELL SELL!
digg it
seed it
del.icio.us
ma.gnolia
Comments: 0
Answered: Question To Palm Over SDK Agreement @ July 25, 2009, 5:02 p.m.
Filed under: Philosophy Code Tech
Palm responded to my Pre sdk legal question via twitter with in a few days of my original post. One can make free software tool implementations as long as no palm code is used. I'm quite happy with that answer. So far I've been very impressed with Palm's ability to stay connected with it's community instead of throwing the devices over the fence and then focusing on it's replacement (like some other companies have been doing).
digg it
seed it
del.icio.us
ma.gnolia
Comments: 0
Question To Palm Over SDK Agreement @ July 17, 2009, 8:41 p.m.
Filed under: Personal Philosophy Code Tech
I am not a lawyer, but when I read the TOS agreement I feel like it is saying that if you use the SDK you can not reimplement any of the tools ...
From: Steve 'Ashcrow' Milner To: Palm webOSDev Cc: Bcc: Subject: Re: Hello future Palm webOS developers! Reply-To: In-Reply-To: <200907172152.n6HLqDY3000183@mailhost01.palm.com> X-OS: Linux powerhouse 2.6.29.5-191.fc11.x86_64 x86_64 I know this is a general email but I'm going to reply back with my question anyway just in case it's read :-) ... I'm an open source developer (and not a lawyer), and after looking over the terms for using the SDK it *seems* like it states that someone like me could not write an open source implementation of palm-generate or other tools (100% from scratch) if I use the SDK. Is this correct? I'd love to start writing applications for my pre! ... but I also don't want to tie my hands up if I do want to do a free software palm-generate clone. -- Thanks! Steve 'Ashcrow' Milner "I would rather use Java than Perl. And I'd rather be eaten by a crocodile than use Java." -- Trouser
digg it
seed it
del.icio.us
ma.gnolia
Comments: 0
