Your take is right on: security as a field has a long, long way to go.
Regarding the issues you mention regarding the definition of security and the use of formal methods, in my opinion, the practical thing to do is to define "secure enough" for each system, rather than trying to define "security" or "secure" for all systems in general. As far as I have been able to determine via experimentation with systems being built by industry, tool development, and consultation with requirements folks, this means formally stating:
- The relevant parts of the starting state of the system when protection is active
- The starting privileges of the attackers the system should protect against
- The specific actions the attackers should not be able to take, at the same level of abstraction as the functional requirements
- What the system ought to do when these attackers try to take these actions
This does not solve the problem of getting the correct values in each of these slots (some of which is a generic requirements problem and some of which is an inherent part of formal methods), but it does begin to define a less-fuzzy interface between the humans and analysis tools, and it does provide clearer criteria for noticing when apparently low-value paths actually merit high-value protection.
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
