Chinese dualism of attack and defence meets Rugged Manifesto
Chinese dualism of attack and defence meets Rugged Manifesto
The Emperor T’ai-tsung (or Taizong) was the second emperor of the Tang Dinasty in China, and previous Prince of Qi which was the Province which culture highly influenced Sun Tzu and consequently the Art of War. He’s credited with saying:
“Attacking and defending are one! If you understand that they are the one, then in a hundred battles you will be victorious a hundred times”
This sentence was used almost verbatim by Sun Tzu as well. According to Derek M C Yuen, argues that Li Ching, in Ibid, “believes the attainment rises above knowledge and directly involves one’s mindset”
“If in attack you do not understand defending, and in defending you do not understand attacking, but instead not only make them into two separate affairs, but also assign responsibility for them to separate offices, then even though the mouth recites the words of Sun Tzu and Wu-Tzu, the mind has not thought about the mysterious subtleties of the discussion of the equality of attack and defence. How can the reality then be known?”
This seems to me logical and hard to argue with. Having started my security career as a penetration tester, but the last 14 years as a defender, I always found the defenders who haven’t done attacking tend to have more of a compliance-led view of criticality of controls as opposed to the people with penetration testing experience who have a more practical and real-world understanding of attack vectors, though may not necessarily understand the most efficient or effective ways to address them.
But if we consider the dualism of attack and defence and the typical responsibilities of the CISO, the “typical structure” of Security teams is still to focus on defender teams with Penetration testing being performed by outsourced companies at the end of development cycles. Companies which are more advanced in their security posture, now have internal attacker teams but I’m afraid that still isn’t the norm and we’re very far away from that being the new normal. And I believe this has significant implications to our organisations to defend themselves against real world attackers.
This is mainly because penetration tests typically have both a scope (which is not typically a constraint on attackers) and a schedule (which will typically be divided in meet and greets, pre-reqs, actual testing and the writing of the infamous report) which make for very little time actually testing our defences.
But more than a question of structure, I believe this is a question of practice. Especially in a DevOps world of fast feedback loops, organisations that spend most of their time defending with little continuous time validating defences and searching for other attack vectors, will be imbalanced and fail to grasp the “mysterious subtleties of the discussion of the equality of attack and defence” and that is making us all less secure.
I believe there’s a “security movement” which got this balance as envisioned by Chinese strategic thinking, and that is the Rugged Movement.
But what does being Rugged mean ?
“Rugged” describes software development organizations which have a culture of rapidly evolving their ability to create available, survivable, defensible, secure, and resilient software. Rugged organizations use competition, cooperation, and experimentation to learn and improve rather than making the same mistakes over and over.
Breakers and builders work side by side continuously to make rugged software. They challenge and test the assumptions of the Builders, so the organisations can improve their resilience.
If you want to to create a Rugged organisation, then you need to stop relying on on external assurances which are done outside of the pace of the organisation and ensure that this is on-going and continuous activity which needs to permeate across the organisation.
But there’s more to it than this:
“Being Rugged means that you constantly patch and refactor your software development organisation to eliminate the organisational bugs that are causing insecure code.”
Rugged doesn’t make insecure software something that the Devs are to blame or the security team fails to assure. It realises that insecure software is caused by organisational bugs, and that is something that everyone’s responsible for. It makes breaking and building the same affair and the responsibility of the same office. The affair of creating rugged organisations.
Insecure software is a symptom, not a cause.
References:
