Tag Archives: security engineering

Nov 14 2020
Leave a comment
Blog Posts

DevSecOps Decisioning Principles

I know you’ve heard this before, but DevOps is not about tools. At its core, DevOps is really a supply chain for efficiently delivering software. At various stages of the process, you need testing and validation to ensure the delivery of a quality product. With that in mind, DevSecOps should adhere to certain principles to best support the automated SDLC process. To this end, I’ve developed a set of fundamental propositions for the practice of good DevSecOps.

  • Security tools should integrate as decision points in a DevOps pipeline aka DevSecOps.
  • DevSecOps tool(s) should have a policy engine that can respond with a pass/fail decision for the pipeline. 
    • This optimizes response time.
    • Supports separation of duties (SoD) by externalizing security decisions outside the pipeline.
    • “Fast and frugal” decisioning is preferred over customized scoring to better support velocity and consistency. 
    • Does not exclude the need for detailed information provided as pipeline output.
  • Full inspection of the supply chain element to be decisioned, aka “slow path,” should be used when an element is unknown to the pipeline decisioner. 
  • Minimal or incremental inspection of the supply chain element to be decisioned, aka “fast path,” should be used when an element is recognized (e.g. hash) by the pipeline decisioner.
  • Decision points should have a “fast path” available, where possible, to minimize any latency introduced from security decisioning.
  • There should be no attempt to use customized risk scores in the pipeline. While temporal and contextual elements are useful in reporting and judging how to mitigate operational risk, attempts to use custom scores in a pipeline could unnecessarily complicate the decisioning process, create inconsistency and decrease performance of the pipeline.  
  • Security policy engines should not be managed by the pipeline team, but externally by a security SME, to comply with SoD and reduce opportunities for subversion of security policy decisions during automation.

Using a master policy engine, such as the Open Policy Agent (OPA), is an ideal way to “shift left” by providing a validation capability-as-a-service that can be integrated at different phases into the development and deployment of applications. Ideally, this allows the decoupling of compliance from control, reducing bottlenecks and inconsistency in the process from faulty security criteria integrated into pipeline code. By using security policy-as-code that is created and managed by security teams, DevSecOps will align more closely with the rest of the SDLC. Because at the end of the day, the supply chain is only as good as the product it delivers.

Tagged , , , , , ,
Sep 17 2015
Leave a comment
Blog Posts

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 , , , , ,
Aug 07 2015
1 Comment
Blog Posts

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 , , , , ,
Jul 30 2015
Leave a comment
Blog Posts

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: