I like the car analogy for a few reasons. First, you are licensed to operate the vehicle on public roads where others are operating their vehicles. The license proves (supposedly, but that's another story) that you have been trained on how to operate the vehicle and that you can operate that vehicle safely. It also proves that you have agreed to obey the rules that are involved with driving such as speed limits.
Which brings me to my point: you have to be licensed to operate a vehicle on public roads, why not be licensed to operate your computer on the public internet? Maybe you would have to take basic computer/internet knowledge test and possibly demonstrate that you know how to operate an already installed virus scanner or something. This is just a thought and I haven't thought through all the technicalities (person vs. residence license, state or federal, etc.).
I'm not actually a proponent of this, just something that came to mind while reading the car analogy.
Security should be something that is considered from the beginning of design. Having said that, I know from experience that it isn't and that management tends to want to plug the hole after the boat sinks. That is, once something bad happens, you get all the money you want and all you have to say is "security".
In order to get management to fund security efforts on their data networks, you have to have a good idea of what could happen to your network/data. The first step is to identify all the vulnerabilities to your systems. These include not only hackers and insiders, but also natural threats like earthquakes and hurricanes (these are mainly useful for disaster recovery solutions).
Take those threats and multiply by the probability of that event happening. Probability of a hacker exploiting a known software vulnerability....pretty good. Hurricane in Kansas...probably not. Once you have these probabilities identified, then you have to measure the potential damage to the company. Will you lose all your data (destroyed, not stolen)? Will someone post/sell private data (company data or personal customer data) that was stolen. Were your servers totally destroyed and you have to buy new ones? Some of these have hard $$ costs to them. Others don't (think embarrassment and tarnished record). It's usually good to convey the "worst case" and the probability of that happening.
If you make your case and still don't get the requisite funding...keep your vulnerability list and everything handy. Then if something does happen, you can point and say "told ya!"
Atrivis
Slashdot Mirror
I like the car analogy for a few reasons. First, you are licensed to operate the vehicle on public roads where others are operating their vehicles. The license proves (supposedly, but that's another story) that you have been trained on how to operate the vehicle and that you can operate that vehicle safely. It also proves that you have agreed to obey the rules that are involved with driving such as speed limits.
Which brings me to my point: you have to be licensed to operate a vehicle on public roads, why not be licensed to operate your computer on the public internet? Maybe you would have to take basic computer/internet knowledge test and possibly demonstrate that you know how to operate an already installed virus scanner or something. This is just a thought and I haven't thought through all the technicalities (person vs. residence license, state or federal, etc.).
I'm not actually a proponent of this, just something that came to mind while reading the car analogy.
Security should be something that is considered from the beginning of design. Having said that, I know from experience that it isn't and that management tends to want to plug the hole after the boat sinks. That is, once something bad happens, you get all the money you want and all you have to say is "security". In order to get management to fund security efforts on their data networks, you have to have a good idea of what could happen to your network/data. The first step is to identify all the vulnerabilities to your systems. These include not only hackers and insiders, but also natural threats like earthquakes and hurricanes (these are mainly useful for disaster recovery solutions). Take those threats and multiply by the probability of that event happening. Probability of a hacker exploiting a known software vulnerability....pretty good. Hurricane in Kansas...probably not. Once you have these probabilities identified, then you have to measure the potential damage to the company. Will you lose all your data (destroyed, not stolen)? Will someone post/sell private data (company data or personal customer data) that was stolen. Were your servers totally destroyed and you have to buy new ones? Some of these have hard $$ costs to them. Others don't (think embarrassment and tarnished record). It's usually good to convey the "worst case" and the probability of that happening. If you make your case and still don't get the requisite funding...keep your vulnerability list and everything handy. Then if something does happen, you can point and say "told ya!" Atrivis