Having worked in academia for many years, I am familiar with the reluctance of many to bite the hand that feeds them.
However, I must say I am surprised by Dan's not being able to smoke out someone from academia willing to coauthor this thing.
Off the top of my head, I can think of two extremely prominent infosec people who I would expect to have readily agreed. I'm hoping that Geer didn't ask them, because if they held off for funding-related reasons, it is truly a sad commentary.
There is little we can do to create a technical solution to a social problem.
Unpatched servers providing security functions are not acceptable. Sure, in the real world they happen, but unless the admin was specifically directed to pick up the boss's dry cleaning instead of patching them, this should never happen.
Lack of "peer review". Not much possibility of avoiding it in a small shop, alas. Best one can hope is that the admin will be diligent about keeping informed, and will try to get his/her design vetted informally via whatever channels are available. In larger shops, management should require a more formal approval process. If they don't, this is not the technologists' fault.
Insider attack. I guess you should revisit your threat model, then, huh? This is infosec 101.
Social engineering the secretary. This one is cured thru better education, and by better physical security. Why does the secretary have physical access to the file server anyway? At best, (s)he should be able to page/call the admin about the guy with the clipboard who needs to take the fileserver back to his workshop at the North Pole.
CIO prefers "productivity" to security. Fine. Officers of the firm are SUPPOSED to make those decisions. Make sure it is in writing, and that it is an informed decision as far as the risks the CIO is permitting. When the company gets owned, at least you'll have some company in the doghouse/unemployment office.
Irresponsible VPN access. Should be a policy about who gets it, which should have taken worm, virus, etc. risks into account when it was created.
Untested restore procedures. If this happens, you deserve to be fired. You're spot on here.
Users prefer dancing rabbits. Didn't the company budget for a security education program? Maybe when the root cause of the next network implosion is traced to such a thing, you can make damn sure the manager of the responsible employee is made aware. After that, the head on the pike by the water cooler should provide an adequate disincentive.
Your last paragraph is right on the money. I don't want to sound like your "wiseguy", but absent some kind of management direction to the contrary, or a threat model under which internal threats were minimal, why would someone design a network to NOT have every single part doing its best to defend against internal and external threats? Do today's infosec people think you can plug in some sort of "security box" to make the bad guys all go away, or something?
Re:If it's raw ethernet, then it's not "IP based"
on
HyperSCSI Examined
·
· Score: 1
I R'd TFA, and it doesn't say anything about IP-based SANs.
It does, however, call the protocol a "beer can with an engine" (or some such colorful metaphor for 'kludge').
I'm not a bit twiddler or an electrical engineer, but it looks to me like this is reinventing the wheel.
Yep. Geer is one who gets it. @Stake is a for-profit firm, of course, and I suppose Dan was "employed at will", but to me this sounds a bit too much like Purdue sacking Spaf for his stance on Microsoft would sound.
@Stake clients are best served by a firm that is beholden to no SW publisher, and what this action suggests is that @Stake is not such a firm.
If a junior techie had been involved in M$-bashing, and had dragged in the @Stake name, I can see how he might be taken to the woodshed. However, as CTO I would expect Dan to have been considered an officer of the firm, and he certainly has the judgment not to go off half-cocked. Apparently, he isn't allowed to use the company name even as such, and the concept of his affiliation being given merely for identification is one lost on @Stake's executives, who fear their customers are too ignorant to differentiate between the opinions of a man and the position of a firm.
As a potential customer of @Stake's, I must say I am disheartened. I have been pleased in the past by the caliber of their people and publications, but this actions leaves a very sour taste in my mouth. There may be more to this story than meets the eye, of course.
In any event, all of us should wish Dan well. He has done *ALOT* for the community, and has done so with the purest of motives. It would be nice if more of us could say that.
Slashdot Mirror
Having worked in academia for many years, I am familiar with the reluctance of many to bite the hand that feeds them.
However, I must say I am surprised by Dan's not being able to smoke out someone from academia willing to coauthor this thing.
Off the top of my head, I can think of two extremely prominent infosec people who I would expect to have readily agreed. I'm hoping that Geer didn't ask them, because if they held off for funding-related reasons, it is truly a sad commentary.
Much of what you say is true.
There is little we can do to create a technical solution to a social problem.
Unpatched servers providing security functions are not acceptable. Sure, in the real world they happen, but unless the admin was specifically directed to pick up the boss's dry cleaning instead of patching them, this should never happen.
Lack of "peer review". Not much possibility of avoiding it in a small shop, alas. Best one can hope is that the admin will be diligent about keeping informed, and will try to get his/her design vetted informally via whatever channels are available. In larger shops, management should require a more formal approval process. If they don't, this is not the technologists' fault.
Insider attack. I guess you should revisit your threat model, then, huh? This is infosec 101.
Social engineering the secretary. This one is cured thru better education, and by better physical security. Why does the secretary have physical access to the file server anyway? At best, (s)he should be able to page/call the admin about the guy with the clipboard who needs to take the fileserver back to his workshop at the North Pole.
CIO prefers "productivity" to security. Fine. Officers of the firm are SUPPOSED to make those decisions. Make sure it is in writing, and that it is an informed decision as far as the risks the CIO is permitting. When the company gets owned, at least you'll have some company in the doghouse/unemployment office.
Irresponsible VPN access. Should be a policy about who gets it, which should have taken worm, virus, etc. risks into account when it was created.
Untested restore procedures. If this happens, you deserve to be fired. You're spot on here.
Users prefer dancing rabbits. Didn't the company budget for a security education program? Maybe when the root cause of the next network implosion is traced to such a thing, you can make damn sure the manager of the responsible employee is made aware. After that, the head on the pike by the water cooler should provide an adequate disincentive.
Your last paragraph is right on the money. I don't want to sound like your "wiseguy", but absent some kind of management direction to the contrary, or a threat model under which internal threats were minimal, why would someone design a network to NOT have every single part doing its best to defend against internal and external threats? Do today's infosec people think you can plug in some sort of "security box" to make the bad guys all go away, or something?
I R'd TFA, and it doesn't say anything about IP-based SANs.
It does, however, call the protocol a "beer can with an engine" (or some such colorful metaphor for 'kludge').
I'm not a bit twiddler or an electrical engineer, but it looks to me like this is reinventing the wheel.
Yep. Geer is one who gets it. @Stake is a for-profit firm, of course, and I suppose Dan was "employed at will", but to me this sounds a bit too much like Purdue sacking Spaf for his stance on Microsoft would sound. @Stake clients are best served by a firm that is beholden to no SW publisher, and what this action suggests is that @Stake is not such a firm. If a junior techie had been involved in M$-bashing, and had dragged in the @Stake name, I can see how he might be taken to the woodshed. However, as CTO I would expect Dan to have been considered an officer of the firm, and he certainly has the judgment not to go off half-cocked. Apparently, he isn't allowed to use the company name even as such, and the concept of his affiliation being given merely for identification is one lost on @Stake's executives, who fear their customers are too ignorant to differentiate between the opinions of a man and the position of a firm. As a potential customer of @Stake's, I must say I am disheartened. I have been pleased in the past by the caliber of their people and publications, but this actions leaves a very sour taste in my mouth. There may be more to this story than meets the eye, of course. In any event, all of us should wish Dan well. He has done *ALOT* for the community, and has done so with the purest of motives. It would be nice if more of us could say that.