Topics:
Analytics : Security
CSI 2008: Brian Snow's Assurance And Controls
Snow briefly related a story about fielding a secure battlefield communications system. During the process, they looked at the threats they had to overcome, some of which were eavesdropping, jamming, and location of the transmitter. They had to factor in these issues during the design phase. Radio, even directed broadcasts, spreads in unintended ways. Eavesdropping was a potential threat. Even with the best encryption, an enemy could jam the signal, cutting off communications and, finally, the enemy could track the location of the radio transmission and attack it directly. Snow's illustration shows that threats are dynamic in nature and the only way to get ahead of them is to be proactive. Exacerbating the problem, Snow points out, is that security product vendors aren't proactive in their feature sets. Their primary goal should be to protect their customers and not make a profit. Waiting until the vendor hears customer demand isn't an excuse to delay adding features that will protect their customers from attackers. I can't tell you how often I have heard vendors state they will add a feature only when there is customer demand. That position is short-sighted and ill-conceived. Customers won't always demand new features -- either they don't realize a feature would be useful, they can't articulate what they need, or the message doesn't make it from the salesperson to the development team. Even if a customer does demand a feature, that doesn't mean it gets built. How many customers does it take to get a new feature instituted? Obviously, information security doesn't begin and end with products, and Snow talked through seven topics -- location, robust control, assurance, cross-disciplinary work, human interface, management, and mutual suspicion -- that are all critical to an information security program. I found the robust controls and assurance the most interesting topics and they integrate nicely. Robust controls work even in the face of a hostile environment. There's no definitive metric for robust, but the controls have to be hardened enough that they can't be bypassed. You have to have the assurance that the product or process will behave predictably even in the face of a malicious attacker. That's hard to find and there are far too many examples of secure systems failing. Many of the track sessions are focused on robust control and assurance and there are plenty of options available. Unfortunately, without product support processes, we'll only get so far. It's a wonder we have any assurance at all. « French RIAA Sues SourceForge For Aiding And Abetting Piracy? | Main | iPhone Experts: Stay Away From Firmware 2.2 » |
| Sign Up Now For InformationWeek News Alerts |
