Saturday, October 3. 2015
Bad Security Architecture Can Kill
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
Friday, November 7. 2014
Abstract. We propose a system based on a Bitcoin like cryptocurrency model whereby participants use Proofs of Identity tests in order to have certain digital identity elements linked to public key cryptographic keys such as ECC based PGP in order to be entered into a public ledger system known as a blockchain. We contemplate a nominal reward system for passing Proofs of Identity such as responding to an encrypted email and posting their IDCoin address on their social media networks that would demonstrate positive control of a given account. Participants would be encouraged to perform key-signing for anyone known to them in order to build a Web of Trust. (WoT). The rewards (aka tokens or simply “coins”) would then be eligible to be “spent” on reputational events which would also be entered into the blockchain. Reputational Events could be anything from signing another members public key to expressing an opinion about another member of the WoT to rating a transaction or the IP address of an email server to real world things such geolocations or the license plates of automobiles.
Tuesday, October 14. 2014
Regarding the http://bitnation.co crowdfunding raise currently on, I will not be investing, nor do I recommend anyone else invest at this time.
Here are the top 10 reasons:
10. The target launch date was set arbitrarily and then capriciously driven to without concern, consult, or agreement by the critical stakeholders involved. The least of which was having core capabilities installed and tested prior to announcing the sale date.
9. The supporting documentation (white paper et al) requires at least a 30-day review period and an open comments via peer-review which has not happened.
8. The sale is offered as “crypto equity” however there are no voting rights. Furthermore the legal standing of the corporation has not been documented.
7. The payment address appears to be static (1Q6QnUx83BH4qKwAtm7qbZztxvWTtU7XEk) -- which is highly unusual for such transactions -- how could you prove you are the owner of a given purchase?
6. Additionally the payment address is NOT a MULTI-SIG account as the CEO recently stated, which means her assertion that there are a number of individuals involved in the release of whatever funds are raised is wishful thinking. This either means she does not know what a multi-signature address actually is, or has not actually looked at or made a purchase herself, or is purposely being deceitful. It's also "possible" though unlikely that the funds are held in a counterparty account for which the company does not have access to until after the sale, afterwhich time they will be sent to a multi-sig account. Either way, what's there today is NOT as she claims.
5. The use of funds is not credible in terms of the launch of a company — it appears to support a “founders lifestyle”
4. The company does not actually employ anyone other than its founder — nor are there are any exclusive contracts in place for the acquisition of key technology that is claimed as part of the offer.
3. The sources of revenue (Identity without standing, land ownership attestation without precedent or show conveyance of “good title” etc) — do not provide a compelling reason for a customer to acquire other than for pure novelty. No actual suggested sale price for such items have been offered, nor any notion of cost, the difference of which would equal the profit that in theory an equity holder could enjoy some part of those proceeds in the form of a dividend.
2. There is nothing of substance in the Github archive -- most of the entries contain a simple "Hello World" example and everything else are simple clones of other projects.
1. The leadership style of the founder has been divisive, humiliating, demoralizing and without any semblance of remorse or culpability. What is particularly concerning has been the treatment of people who are basically volunteers — I can only imagine what the treatment might include if she felt entitled and empowered because of the tacit acceptance of a paycheck by an employee.
These are not attributes I admire and certainly will not reward.
Fundamentally TRUST comes down to having confidence in two aspects of the person or group seeking yours:
1. Do you have confidence in the INTENT?
2. Do you have confidence in the COMPETENCE?
I'm willing to extend most people the benefit of the doubt when it comes to intent. I generally assume "good intentions" -- though even in this case there is likely just cause to question this in the face of the evidence.
The lack of any credible demonstrable proofs of concepts combined with a "fad approach" to selecting technology spelled out in the Dev Plan continue to demonstrate a "top down, edict driven" approach that is antithetical to "consensus" -- which is at the core of all things blockchain. So that calls the competence into question.
Therefore, until Bitnation can show a credible, demonstrable value proposition that includes a compelling reason for customers to acquire its services and what reasonable expectation of service level agreement (SLA) they can expect, I can not in good faith recommend investing in it at this time.
Friday, June 7. 2013
Tuesday, December 11. 2012
"...the essence of mastering systems thinking as a management discipline lies in seeing patterns where others see only events and forces to react to.", [Peter M. Senge, The Fifth Discipline: The Art & Practice of the Learning Organization, p.123]
Some things that embracing Systems Thinking has revealed about me:
1. I am wired for pattern-matching and pattern-recognition! Software or Social Systems.
2. I understand reverse-engineering stone cold. This is the best way to discovering "cause & effect."
3. I practice having my "crucial conversations" days to weeks in advance
4. I re-read important books annually. Chief among my favorites is Machiavelli's "The Prince" on my desk for reference, which leads to
5. I usually have figured out what you're likely going to do and likely going to say and what my response will likely be three moves from now
When someone tells you what they are "not going to do", do not be dazzled by their amateur misdirection.
I recently had a conversation with a new manager who told me he was basically going "stay out of my way" -- it was the second time I'd heard that exact phrase in the past six months, first from his predecessor who did everything but. Which I understood he meant he was planning the exact opposite.
When you attempt to "lather. rinse. repeat." a highly visible pattern, especially one that has failed miserably, you have to at some point have some kind of honest inner reflection that you might not be as clever as you think you are?
Unless you work for an organization that is fiercely protective of incompetence.
Something's I've learned over my brief time here:
1. The only thing people hate more than a surprise is
2. An unplanned errand.
Today's Big Idea: "Think long and hard about your interaction with people you perceive as your subordinates. Allow for the off chance that they might just be as smart as you. And for the truly gifted, statistically speaking, one in a thousand are likely smarter than you."
That's how I've treated every team I've had the privilege of serving. It is something I learned from Steve Jobs who advocated "hiring people smarter than you" -- I've been very fortunate to have worked with a number of rock-stars who clearly outshine me!
But if you're going to try and throw someone under the bus -- I would caution you to avoid people with really long reach. Especially ones that can see you coming from a mile away...
Who are you guys and what are you doing here distracting me? The Big Idea Blog is written by David Duccini & David Walbridge
(Page 1 of 34, totaling 166 entries) » next page