In a discussion, opposing views are presented and defended and the team searches for the best view to help make a team decision. In a discussion, people want their own views to be accepted by the group. The emphasis is on winning rather than on learning.
In dialogue, people freely and creatively explore issues, listen deeply to each other and suspend their own views in search of the truth. People in dialogue have access to a larger pool of knowledge than any one person enjoys. The primary purpose is to enlarge ideas, not to diminish them.
"It’s not about winning acceptance of a viewpoint, but exploring every option and agreeing to do what is right."
On August 1, 2007 I was crossing the I-35W Mississippi bridge on my way to one of my last MBA classes at the Carlson School of Management, University of Minnesota. I was on my motorcycle at the time and traffic was stop and go. That summer the MN Department Of Transportation (DOT) had decided to resurface the bridge and traffic had been pushed to the outer lanes while the scrappers and jackhammers were busy removing the old surface.
The bridge wasn't just vibrating it was bouncing! I could feel its momentum beneath my tires and could see the cars around me rising and falling slowly. It didn't feel safe, but my thought was, "well they wouldn't be doing this if it wasn't safe, right?" I kicked it into gear and finished crossing the bridge pulling into the parking ramp when it happened: the bridge collapsed behind me killing 13 people and crippling some of my classmates. A minute earlier and you would not be reading this today.
The NTSB cited a design flaw as the likely cause of the collapse, noting that too-thin gusset plate ripped along a line of rivets, and asserted that additional weight on the bridge at the time of the collapse contributed to the catastrophic failure.
That day inspired two clear security mandates for me:
1. Trust but Verify
2. Build Security In. Don’t bolt it on
The first is a well-known tenant of security. The bridge falling was a wake up call for me, because I recall vividly thinking as the bridge was bouncing up and down, “surely this must be safe because they wouldn’t be doing this otherwise?”
“When you see something, say something”
Now when I see something suspicious I raise my hand and say something. This is the security empowerment mandate. This doesn’t just apply to security it’s any situation where the pattern suggests an anomaly, in security posture or business practices alike.
The second lesson learned was the icon of that gusset-plate, as a reminder that security should not be simply bolted on. Modern bridges no longer rely on gusset-plates for their strength and security. Why should modern software?
In information security the gusset-plate approach is essentially Security Operations or “SecOps” – all the structures put in place to build sandboxes around vulnerable assets. It’s the firewalls, anti-virus systems, file-systems scanners, and web application proxies.
I see the same complacency in terms of the trust by assumption that companies place into their infrastructure. Developers don’t take an ownership in the security of their systems because they have been trained to rely on the SecOps infrastructure to keep them safe in their sandboxes.
If we’re going to build modern software we can no longer afford to place our trust in the apparatus of SecOps – we must move the ball back squarely into the applications themselves – an AppSec, or SecDev program.
The old methods of trying to enforce input data types, lengths, and sanitization at the edge are brittle and do not scale horizontally. The tightly coupled coordination between Development and Operations (DevOps) to manage the Web Application Firewall (WAF) rules creates so many bottlenecks in the application delivery pipeline that few organizations deploy more than a handful of vendor supplied generic rules, hoping to filter out the most basic attacks.
Instead of relying on web application firewalls and proxies to try and prevent, let alone detect, malicious activity, we must embed that capability within the applications themselves. The developers know what is an anomaly – they code for it with structures like “assert()” and “try/catch” blocks. By linking in a standardized logging system that can feed into an enterprise Security Information and Event Mangement (SIEM) system, malicious activity can be discovered AS IT’S HAPPENING in a way that scanning log data can’t even match.
“Don’t try to train developers to code securely. Give them secure code”
By collapsing towards a set of hardened input sanitization routines we can wipe out most of the OWASP Top Ten exploitable defects. And since few developers have a passion for rolling their own, it behooves us to find and promote secure tools that they can just leverage. Later in our maturity we can add rules to our code scanning tools to detect if the approved libraries are being used adding in a layer of enforcement.
Once input sanitization has been handled and security events are being consumed by the security logging tools, focus on standardizing authentication and authorization handling. You’d be surprised at the number of exploitable systems that can leverage authenticated sessions to pivot and access other assets because the developers did not think to confirm that the entitlements were bound. “I have a valid token or session cookie, let’s go and modify that user number that was passed in as part of the session…” The ability to pivot on credentials is not the kind of defect you’re going to find from code or vulnerability scanning. Very few penetration testers are going to find it either. The best method is to “trust but verify” – demand to see evidence in the log files that the session-handler can detect when access request is being made on assets not bound to that token.
This is the essence of a SecDevSecOps approach:
1. Trust but Verify
2. Build Security in -- don’t bolt it on
Tweeting about #SecDevOps on Twitter @TheLittleDuke