Thread: Re: [Embedlets-dev] Re: Security
Status: Alpha
Brought to you by:
tkosan
Menu
▾
▴
embedlets-developer
|
From: Gregg G. W. <gr...@sk...> - 2003-02-10 03:38:03
|
>I think using vlans to secure the connection between embedlets and >enterprise systems is overly optimistic. Embedlet hardware with >temperature probing devices might be used in a plant, but in office >buildings as well and I don't think network groups are going to be fond of >creating vlans with lots of devices spread acros buildings. The point is that as soon as you have to send the data across a building or through a network, you really do need to know a lot more about the data's successful transference, as well as being able to guarentee that it does follow your corporate requirements for data security. This is not about lazy programmers. The code exists, processors exist, network equipment exists. You have to decide at what level the cost to the end devices is so overwhelming that it is more cost effective to do it at the point of network traversal rather then between end applications, which may not know about each others capabilities regarding secure data transmission. More importantly, when a keyset is compromized, soneone is going to need to fix the problem, and asking them to telnet to 1000 field devices to update keys is not going to go over well, when there are only 10 routers involved in the network. Data communication concentrators are your friend... Scalability is paramount here. The 10 device applications have been done. The 100 device applications have been done. The 500 device applications are being worked on using existing technologies. The 10000 device applications are in the future. Think about how you'll make it possible for a couple of people to watch over, manage, configure and repair 10,000 devices... ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Gregg G. W. <gr...@sk...> - 2003-02-11 04:06:47
|
>(Having been a system operator for over 5 years learned me the avarage >programmer is lazy and has not even the slightest idea what impact their >'design' will have in an operational environment.) :-) :-) :-) Many people on this list are engineers, not technicans! I appreciate your experience, just make sure you measure your response to similar stimulous in a way that allows everyone to see your concerns (this is something that I don't do well, because I get passionate about things that I have had bad experiences with too ;-). I spent 9 years working on and around telephone switching systems. I designed a language and the associated processes that controlled the duplex hardware (computer level, and device level) during the software retrofit process (replacing the software on a running switch). When something went wrong, I typically had 1 hour to go through 500,000 lines of base code (including assembly) to find problems (support calls at 3:00am in the morning). Sometimes I had 10 minutes to establish the extent of a problem by pouring through the status information and control display screens (at 300 baud) to establish what the next step was. As a matter of fact, I got to do this for the Prime Minister of the U.K. so that he could talk to his generals in Saudi-Arabia on the day the ground war started in 1990. Believe me when I say I am well aware of many issues that create headaches for persons managing systems. I won't say I know every issue that you know, but that's what's great about this list. We can utilize everyones expertise to make sure we make a really great decision about how to do all this stuff. visible security and encryption in the APIs: -1 pluggable comms interface that could provide security and connection authentication: +1 ----- gr...@cy... (Cyte Technologies Inc) |
|
From: Jac K. <j.k...@th...> - 2003-02-10 18:52:57
|
On Sun, 9 Feb 2003, Gregg G. Wonderly wrote: > The point is that as soon as you have to send the data across a building or > through a network, you really do need to know a lot more about the data's > successful transference, as well as being able to guarentee that it does > follow your corporate requirements for data security. Sure. > This is not about lazy programmers. The code exists, processors exist, > network equipment exists. You have to decide at what level the cost to > the end devices is so overwhelming that it is more cost effective to do > it at the point of network traversal rather then between end > applications, which may not know about each others capabilities > regarding secure data transmission. More importantly, when a keyset is > compromized, soneone is going to need to fix the problem, and asking > them to telnet to 1000 field devices to update keys is not going to go > over well, when there are only 10 routers involved in the network. > Data communication concentrators are your friend... Given the kind of application you're thinking of you're right. Now imagine someone using embledlets to monitor entrance doors of 140 buildings within a country. In a setup like this data concentrators won't help and managing VPNs become a significant cost factor, so the cost per device might not be as much of an issue. At this point we have the option to add security into the mix without breaking anything, so I'm asking to keep an open mind to setups with different requirements and facilitate them as well. (Having been a system operator for over 5 years learned me the avarage programmer is lazy and has not even the slightest idea what impact their 'design' will have in an operational environment.) Regards, Jac -- Jac Kersing Technical Consultant The-Box Development j.k...@th... http://www.the-box.com |
|
From: Brill P. <bri...@ro...> - 2003-02-10 19:03:39
|
> At this point we have the option to add security into the mix without > breaking anything, so I'm asking to keep an open mind to setups with > different requirements and facilitate them as well. I agree with you, even if we don't implement in early runs, we should defiantly build the capability in... and I don't just mean password protection. - Brill Pappin |
Thanks for helping keep SourceForge clean.
X