"To kill an error is as good a service as, and sometimes even better than, the establishing of a new truth or fact." - Charles Darwin
The IEEE Center for Seucre Design recently published a set of design principles for Avoiding Security Flaws. The distinction between Bugs versus Flaws is a crucial one, the lion's share of attention in the indsutry goes to bugs and perhaps this appropriate, but we can really use a lot more clarity of thought in how to address security flaws:
"Both bugs and flaws are types of defects. A defect may lie dormant in software for years only to surface in a fielded system with major consequences. A bug is an implementation-level software problem. Bugs may exist in code but never be executed. A flaw, by contrast, is a problem at a deeper level. Flaws are often much more subtle than simply an off-by-one error in an array reference or use of an incorrect system call. A flaw might be instantiated in software code, but it is the result of a mistake or oversight at the design level. For example, a number of classic flaws exist in error-handling and recovery systems that fail in an insecure or inefficient fashion."
You see architectural and design flaws have an impact in a more pervasive way. Flaws can be structural - the design team chose the weak frameworks to build on, so in a vulnerability assessment you see th normal parade of bugs but stepping back from that you realize that the building everything on PHP was perhaps not the wisest move in the first place. Flaws tend to be more rare than bugs, but when you have flaws in a system they are pernicious, manifesting themselves over and over again and the observable issues tend to cascade.
Flaws can be behavioral. This recent Twitter exchange points out two such examples of sources of Flaws.
Race Conditions often have their root in TOCTOU flaws, for example where the system does not have a way to ensure consistency from where the authorization is enforced to the source used for that decision. As Marinus van Aswegen points out, credentials have their own potential for generating flaws. Its not good enough to say that here is a static credential, the architecture must work to address the safety of the credential through its lifecycle, and often augment that with risk based controls on the backend, recognizing that, say passwords alone, won't get the job done.
Flaws can be related to the creational routines. These can include the lack of a secure boot or one that can be trivially bypassed. Creational flaws can include things like hard coded keys. These kind of flaws can result in the entire rest of the system's access controlbeing bypassed or cloning the entire system.
The top 10 list from IEEE Center for Secure Design is as follows:
- Earn or give, but never assume trust
- Use an authentication mechanism that cannot be bypassed or tampered with
- Authorize after you authenticate
- Strictly separate data and control instructions, and never process control instructions received from untrusted sources
- Define an approach that ensures all data are explicitly validated
- Use cryptography correctly
- Identify sensitive data and how they should be handled
- Always consider the users
- Understand how integrating external components changes your attack surface
- Be flexible when considering future changes to objects and actors
I think that is an excellent list, especially the first eight. I might quibble a bit with the last two, although integration and flexibility should be on the list in some manner, but I might phrase it differently.
Three things that I would like to see addressed in any security architecture effort addition to this list:
- Identity.Its the new perimeter after all. As Marinus van Aswegen says a credential is a zero day. And when it comes to rresolving TOCTOU issues, identity protcols are at the heart of the matter as well. The first three issues on the IEEE CSD list are really the first mile and last of the identity protocol, but the protocol itselt warrants a place here
- Design for malice, there should be a call to build visibility into systems. Logging and monitoring is often an afterthought, instead the focus needs to be on design patterns for log records, events streams, persistence, and monitoring. This is an important hedge on the rest of the list, it explicitly assumes a scenario and prepares for when things do not go as planned. G.K. Chesterton says it well, "The real trouble with this world of ours is not that it is an unreasonable world, nor even that it is a reasonable one. The commonest kind of trouble is that it is nearly reasonable, but not quite. Life is not an illogicality; yet it is a trap for logicians. It looks just a little more mathematical and regular than it is; its exactitude is obvious, but its inexactitude is hidden; its wildness lies in wait." Where this distinction matters is that authentication, authorization et al assume you know how the system is used, designing for malice is about when you don't. This leads to a fundamentally different set of capabilities. Its not simply a DMZ, its more like Moscow Rules.
- There should be a clear focus on integration. We have lots of great security concepts, but whether they work in the real world is usually a matter of usability (which is covered) or integration. Integration is the single biggest deciding factor in successful/unsuccessful efforts. We don't really have security problems instead we mainly have integration problems. The core concepts of security were supposedly figued out decades ago, yet we still have ongoing security problems. Integration needs as much focus as we give attack and defense. Integration as a whole is orders of magnitude away from the amount of attention it needs in the security industry.
Those three I think deserve to be top of mind for any security architect. The CSD effort overall is excellent, we have so many people with the title security architect, but security architects really lack core guiding principles. The list can be adapted to your environment or just to test your own principles against. We need to kill both bugs and flaws. Its a great resource for the latter which is underemphasized in practice today; the list helps to think about architecture and design flaws. Old flaws never die, you have to kill them. We need resources like this to avoid the perils of incrementalism and push the industry's ideas to fresh thinking on security architecture and design.