Tag Archives: security engineering

Is Your Security Architecture Default-Open or Default-Closed?

One of the most significant failures I see in organizations is an essential misalignment between Operations and Security over the default network state. Is it default-open or default-closed? And I’m talking about more than the configuration of fail-open or fail-closed on your security controls.

Every organization must make a philosophical choice regarding its default security state and the risk it’s willing to accept. For example, you may want to take a draconian approach, i.e. shooting first, asking questions later. This means you generally validate an event as benign before resuming normal operations after receiving notification of an incident.

But what if the security control detecting the incident negatively impacts operations through enforcement? If your business uptime is too critical to risk unnecessary outages, you may decide to continue operating until a determination is made that an event is actually malicious.

Both choices can be valid, depending upon your risk appetite. But you must make a choice, socializing that decision within your organization. Otherwise, you’re left with confusion and conflict over how to proceed during an incident.

baby_meme

Tagged , , , , ,

Being the Security Asshole

Yes, I have become a security asshole. The one who says “no” to a technology. But I say it because of risk, and not just security risk.  And I’m angry, because my “no” is a last resort after many struggles with developer, engineering and operations teams in organizations that struggle to get the basics right.

I try to work with teams to build a design. I bring my own architecture documents and diagrams, which include Powerpoint presentations with talking points. I create strategy road maps explaining my vision for the security architecture in an organization. I detail our team’s progress and explain how we want to align with the rest of enterprise strategy and architecture. I stress that our team exists to support the business.

What do I get in return? Diagrams so crude, they could be drawn in crayon or made with Legos. They usually don’t even have IP addresses or port numbers. I have to argue with sysadmins about whether Telnet is still an acceptable protocol in 2015. I’m subjected to rehashed Kool-Aid about how some product is going to rescue the organization even though I found significant vulnerabilities during the assessment, which the vendor doesn’t want to fix.

And if this means that you hate me, fine. I’ll be the asshole. I’ll embrace it. But at least I can have a clear conscience, because I’ve done my best to safeguard the organization that’s paying me.

Tagged , , , , ,

The Physical Layer: Networking’s Fifth Circle of Hell

Recently, Pope Francis made headlines when he called unrestrained capitalism the “dung of the devil.*” I’m betting he’s never been a network engineer dealing with negotiation issues.** Problems at the physical layer always seem to be the most painful, mostly because you think, “Dammit, I should have known better!”

These thoughts come after the third in a series of attempts to insert a Vendor’s network packet broker bypass module inline at my $dayjob. Vendor requires and only supports manual configuration of the GigE LX fiber ports, but we couldn’t get this to work. It was infuriating, because we seemed to have link, but the dB loss was too high.

I should mention that in most of my previous jobs, the network team always managed the perimeter router. But not in this shop. Unbeknownst to me, the demarcation point, a port on a router, was set to auto-negotiate. This wasn’t identified in the diagram and was only discovered after lots of yelling by a cast of thousands, including multiple representatives from the Vendor, in a server room late at night. This issue was finally resolved by opening a case with the service provider and requesting that they hard set the uplink port on the managed router.

The situation was infuriating. I woke up at 5:00 AM the next morning with a bad case of nerd-rage. I needed to find a target for my anger, so I went to Google to help me direct this justified (so I thought) apoplexy.  I started reading through the IEEE standards on Ethernet and 1000BASE-X, even finding an “interpretation” document. This just made me more irate.

18.3.1.8 Auto-Negotiation
The Auto-Negotiation algorithm of Clause 28, while the preferred method for the determination of half or full duplex operation, is not currently defined for fiber MAUs.
Manual configuration, while not recommended for copper-based MAUs, is the only practical choice for fiber implementations. Connecting incompatible DTE/MAU combinations such as a full duplex mode DTE to a half duplex mode MAU, or a full duplex mode station (DTE and MAU) to a half duplex network, can lead to severe network performance degradation, increased collisions, late collisions, CRC errors, and undetected data corruption.

Point – Vendor

37.1.4.4 User Configuration with Auto-Negotiation

Rather than disabling Auto-Negotiation, the following behavior is suggested in order to improve interoperability with other Auto-Negotiation devices. When a device is configured for one specific mode of operation (e.g. 1000BASE-X Full Duplex), it is recommended to continue using Auto-Negotiation but only advertise the specifically selected ability or abilities. This can be done by the Management agent only setting the bits in the advertisement registers that correspond to the selected abilities.

Point – Mrs. Y. The Vendor doesn’t support this option.

Interpretation for IEEE std 802.3-2002 #1-11/02 (1000BASE-X Auto-negotiation)

The standard clearly states in the second paragraph of subclause 37.2.5.1.1 Control register (Register 0), “When manual configuration is in effect at a local device, manual configuration should also be effected for the link partner to ensure predictable configuration.”
Hence, if this recommendation is not followed and a link has manual configuration in effect at a local device but not at the link partner, or the reverse, the resultant link configuration can not be predicted.

Point – Vendor

Final Decision: I will direct my righteous indignation at the IEEE. I spent over two hours going through reams of documentation to find this information and I’m still confused by which is the “best practice.” Is it any wonder that vendors and network professionals still argue about the standards?

Pope_link

*Devil Dung would be a great name for a punk rock band.

** And please don’t flame me over referencing Pope Francis. He seems like a cool guy with a good sense of humor. I don’t think he’d mind.

Tagged , , , , ,
%d bloggers like this: