"Penetrate and Patch" as a failed security process is distinct from vilifying independent security research, and it should be obvious from my post as I point out that penetration testing is a integral part of the testing and verification process. It tells you if your process and design have failed, but it is not a good development process itself.
Again and tediously: the only reason anyone would use that sequence of words would be to invoke Ranum's (in)famous "Six Dumbest Ideas In Computer Security" post, one of which was, in effect, "the entire modern science of software security".
I recommend, in the future, that if you want to pursue a security policy angle in discussions online with people, you avoid using that term.
I am invoking it. “Penetrate and Patch” is illustrative and catchy and the arguments presented, for that one in particular, are largely theoretically, empirically, and even predictively supported.
In fact, all of points except “Hacking is Cool”, are largely well supported. The common thread being that all the other points are about “designing systems secure against common prevailing threat actors” (i.e “defense”) and only that point is about “development of adversarial capabilitys” (i.e. offense) which they wrongfully undervalue and even associate criminality with; misunderstanding the value of verification processes.
And besides, the entire modern science of software security is, objectively, terrible at “designing systems secure against common prevailing threat actors”. What it is pretty good at is the “development of adversarial capabilitys” which has so far vastly outstripped the former and demonstrates quite clearly that prevailing “defense” is grossly inadequate by multiple orders of magnitude.
If you say so, but I was a practitioner in 1997 and am a practitioner in 2025 and I think you'd be out of your mind to prefer the norms and praxis of circa-1997 software security. You do you.
The proposals were not the norms of the time. It is literally a rant against prevailing “bad” ideas of the time.
“Default Permit”, “Enumerating Badness”, “Penetrate and Patch”, “Educating Users” were the norms of the time and still, largely, are. And that is part of why “defense” is so grossly inadequate against common prevailing threat actors.
I prefer the norms of high security software which include, but do not consist exclusively of, most of the stated ideas.
I have no idea what assessment you are even referencing. The only assessments you made as far as I can tell were:
1) The post was made to vilify independent security research.
2) The post argues against "the entire modern science of software security".
3) The norms of 1997 are worse than the norms of 2025 and that my support for the argument that "Penetrate and Patch" is a poor security policy is somehow indicative that I prefer the norms of 1997 even though "Penetrate and Patch" was and continues to be the prevailing norm.
To which I argue:
1) Maybe so. However, the arguments against most of the stated practices, in particular everything except idea #4, stand on their own and have stood the test of time.
2) Given the contents of the rest of that post, this is almost surely a statement that idea #4 was wrong which I have agreed was incorrect. I also, separately, argue that "the entire modern science of software security" is basically useless at producing systems secure against common prevailing threat actors as is demonstrated daily. This is distinct from the high level of capability in producing systems and processes that can identify and exploit vulnerabilitys which is a clear win for the "the entire modern science of software security". However, such capability is not very helpful in achieving the former which is the thing usually desired from "security".
3) I am just baffled. I have to assume that you just misread my position. Otherwise you are arguing that the systems of 1997 were default deny, explicit whitelists, engineered for security from the start, and operate in a secure configuration by default. Or that the security processes of 2025 are that way. Both of which are laughable. I guess you could also argue that those principles are bad, but I am pretty sure even the sorry state of affairs that passes for "software security" these days recognizes those are correct principles even if they utterly fail to even attempt them.
