Commentary

Mike Fratto
Network Computing  

CSI 2008: Brian Snow's Assurance And Controls

Brian Snow's keynote at CSI 2008 started with an amusing graphic of a guy pouring gas over his head while lighting a cigar. The message was we always take risks, even when we aren't aware of them. Snow learned a thing or two about risk while working at the NSA for 20 years, ending as technical director for information assurance. Information risks, he points out are, moving targets and information security programs need to be adaptable and well designed.

Brian Snow's keynote at CSI 2008 started with an amusing graphic of a guy pouring gas over his head while lighting a cigar. The message was we always take risks, even when we aren't aware of them. Snow learned a thing or two about risk while working at the NSA for 20 years, ending as technical director for information assurance. Information risks, he points out are, moving targets and information security programs need to be adaptable and well designed.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.


More Software Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

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.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links