![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On 3/27/2013 1:13 PM, Derek Martin wrote: > On Wed, Mar 27, 2013 at 10:12:28AM -0400, Rich Pieri wrote: >> Security by obscurity is no security at all. > > This is a popular mantra of paid security professionals, but it is a > fallacy, and in fact is a tool that those very same people employ > every day (e.g. recommendations to run ssh servers on non-standard > ports, configure servers to respond with non-default banners, etc.). > The benefits of such measures often amount to foiling script kiddies > who may otherwise compromise your otherwise vulnerable system with > zero effort, but that itself can be a big win, since this is the > overwhelming majority of attack traffic that most sites see. When combined with port-knocking, having a non-standard port for a service like ssh is an effective means of preventing port-scanning attacks. It doesn't prevent an attacker from knocking on all ports that end in "21", before trying all ports that end in "22", or from gaining root access to your server by exploiting a bug in Exim4, but it _IS_ an effective tool when properly deployed. There is a difference between putting the key to your home under a rock in the front yard or giving it to a neighbor: while the local "Script kiddie" may be willing to beat up your neighbor to obtain the key to your home, it is not "security via obscurity". What we have to deal with instead is a tendency I call "security-by-stupidity", i.e., the tendency of some executives to assume that M$ has it all under control. > It's virtually impossible to completely harden your network against a > very knowledgable and determined attacker. So, PART of the point of > securing your systems (passive measures) is to slow them down, to give > you a chance to notice their activites, so you can react and do > something about it (active measures). Security through obscurity IS a > useful tool to that end. */ALL/* security is an effort to slow an attacker down. Underwriters Laboratories rates safes in terms of the length of time they can withstand well-known attacks: a safe with a UL rating of TRTL-30 is able to withstand an attack by an experienced safecracker, with a torch and tools, for thirty minutes. It is impossible to harden /*ANY*/ network completely: the Defender's Dilemma applies. That doesn't mean that you put the family jewels in a disguise safe among your cooking spices: every experienced criminal will always looks there. It /*DOES*/ mean that any security effort has to combine evaluations of the risks, rewards, and costs of each security measure. The Iranian nuclear specialists could have anticipated STUXNET: they were simply unable to do so because of a cultural bias that prevented them from anticipating that their own employees might be part of a virus-delivery system. > It just needs to be understood that it is not sufficient, and it is > one of the least effective methods... you need security in depth, and > obscurity is a VERY SMALL part of that, but it is indeed a part. The > REAL gains you get from it are small, but they're often trivial to > implement, so they're cost-effective. In the end, security is about > trading costs... just like buying insurance. Well, I (obviously) disagree. S-T-O might be part of a /sales/ effort, and I'm as likely as the next salesman to take advantage of my customers' preconceived notions about how Hollywood taught them everything they need to know about computers, but it is /*NOT*/ part of a realistic security program. Security-by-obscurity is, IMNSHO, the all-too-human tendency to dismiss certain attacks as "impossible", merely because they seem improbable. That doesn't mean that I will ignore them or minimize their risks to my customers, merely that I will account for their tendency to underrate them, and recommend appropriate alternatives, such as added insurance, in place of the defense-in-depth needed to secure against them. Bill -- Bill Horne 339-364-8487
![]() |
|
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |