NetOptics

 
Last week, the SEC published a new guidance document that is shaking the security industry with a new mandate for publicly traded companies to disclose real or potential cyber-attacks capable of disrupting business operations or financial stability (see CF Disclosure Guidance: Topic No. 2).
 
In other words, risk management, security and vulnerabilities will have to be reported by public companies and should be addressed while public companies are performing M&A activities.  Never before companies were asked to report their cyber security readiness or even the impact of (in)security on their business. 
 
Now, in order to report the level of security ("real or potential cyber-attacks"), those companies will have to run risk management programs and monitor their entire network and assess every part of their business to identify any risk. 
 
The server room has (finally) made it to the board room.
 
This new guidance emphasizes that public companies (actually they use the word “registrants”) should disclose the risk of cyber incidents “if these issues are among the most significant factors that make an investment in the company speculative or risky.”
 
Registrants are expected to evaluate security risks, and if a registrant determines that disclosure is required, the registrant is expected to “describe the nature of the material risks and specify how each risk affects the registrant,” avoiding generic disclosures.
 
The SEC indicated that in analyzing cyber security risks and whether that risk should be reported, registrants should take the following into account:
 

• Prior cyber incidents and the severity and frequency of those incidents.
• The probability of cyber incidents occurring and the quantitative and qualitative magnitude of those risks, including the potential costs and other consequences resulting from misappropriation of assets or sensitive information, corruption of data or operational disruption.
• The adequacy of preventative actions taken to reduce cyber security risks in the context of the industry in which they operate and risks to that security, including threatened attacks of which they are aware.

 
While the SEC is making a note that companies should avoid generic “boilerplate” disclosure, they reiterate that the federal securities laws do not require disclosure that itself would compromise a registrant’s cyber security, but stull they ask registrants to provide sufficient disclosure to allow investors to appreciate the nature of the risks faced by the particular registrant in a manner that would not have that consequence.
 
-- Sharon

A while back, I wrote about using Bypass Switches as Taps. I'd like to tell you about some improvements we've made to increase the flexibility of Tap mode in the iBypass Swtich starting with code version 2.2.1.

With code prior to V2.2.1, the behavior is as described in the previous post: When the Heartbeat timeout parameter is set to zero (command: "set timout 0"), the iBypass Switch is forced into Bypass ON mode. In Bypass ON mode, network traffic is copied to the monitor ports like a full-duplex breakout tap. In normal Bypass ON mode, Heartbeat packets are included in the monitor traffic so the iBypass Switch can detect when the tool comes back online. When Bypass ON is forced, there are no Heartbeats because the Heartbeat timeout is 0.

With code V2.2.1 and later, link traffic is NOT copied to the monitor ports in normal Bypass ON mode; only Heartbeat packets are seen on the monitor ports. To see the link traffic on the monitor ports like at Tap, now you use the new CLI command "set mode 1" or "set mode tap". This puts the iBypass Switch into Tap mode. Heartbeat packets continue to be emitted, but you can turn them off by setting the timeout to zero, like before. However, "set timeout 0" by itself does not force Bypass ON (or Tap) mode, it controls only the Heartbeats. To return to nomal bypass switch operation, use the command "set mode 2" or "set mode bypass" and restore the Heartbeat timeout if you had set it to zero for Tap mode.

To summarize,

   Old code: Network traffic is copied to the monitor ports in Bypass ON mode

   New code: Network traffic is NOT copied to the monitor ports in Bypass ON mode

   To make the iBypass switch behave like a Tap:

   Old code: "set timeout 0"

   New code: "set mode 1" or "set mode tap" (also, optionally, "set timeout 0" to remove Heartbeat packets)

   What does "set timeout 0" do?

   Old code: Force Bypass ON mode (like a Tap) and stop Heartbeats

   New code: Stop Heartbeats only

   How to return to bypass switch mode?

   Old code: restore timeout to non-zero value

   New code: "set mode 2" or "set mode bypass" (also, restore timeout to non-zero value if you had set it to zero to stop heartbeats)

Most importantly: If you never use the iBypass Switch as a Tap, none of this matters to you at all!

Note: Code V2.2.1 was put into production 6/20/11 for 10/100/1000 copper iBypass Switch models. The GigaBit fiber models got the new Tap mode behavior with code V3.0.2 released 9/30/11, which also applied to the 10/100/1000 models. The 10 GigaBit models will get the change later this year. These code versions are not field upgradable because they depend on changes to lower level product firmware, so you will only see it on new units shipped after those dates.