We rely on many systems to function and to do so safely and securely often without too much thought, whether it is utilities such as the electric grid, transportation such as airlines, automotive or rail travel, medical care or the delivery of goods. We normally expect and trust systems to “simply work”. Occasionally we are unpleasantly surprised such as with the fires in California and elsewhere leading to loss of electrical service after the event, planes crashing due to design issues, autonomous cars not negotiating lanes safety, or supply chains being disrupted.
We place enormous trust in the systems we rely upon. As these systems depend more and more on software to function it becomes essential to understand software and in particular how to have software that can be relied upon for a trustworthy system.
Trusting software requires confidence in the organization that produced it (“Do they do things in a way that inspires confidence? Does the leadership care about quality, safety, and so on or just profits? ” etc.), confidence in the actual products (“Was the airplane assembled properly or were incorrect bolts used?”), and confidence in the service associated with the system (“Is maintenance performed regularly and properly?”).
We have just published a new article on Software Trustworthiness Best Practices. In this paper we outline the entire lifecycle, including the importance of communicating and validating requirements, proper architecture and design, providing enough support for implementation and testing (including tools), validating, operating and decommissioning software. We also raise the value of software protection which is not always considered. The following diagram from the paper shows the lifecycle:
The paper includes practical discussions of issues such as software updates, end-of-life strategy and software protection – all topics that can be ignored when focused on software implementation. The appendix includes a software lifecycle checklist that should be helpful as well as some examples of failures related to software.
Software trustworthiness is essential to creating trustworthy systems and considerations of the topics and practices in the paper should help with the journey toward more trustworthy systems.
This IoT Security Maturity Model is timely, needed and new since it incorporates business, process, technology and operations aspects, and considers the security need from an integrated perspective including various contexts (end-end, device, edge, cloud, etc) and viewpoints such as information technology (IT) as well as Operational Technology (OT).
The IoT Security Maturity Model is a strategic document addressing the challenge of how to invest appropriately to address security needs and as a strategy provides an approach and model as well as actionable guidance. The need is to invest appropriately to address concerns, without investing too much or too little and by focusing in the areas that matter. The strategy is holistic, considering business, process, technology and operations.
An important concept is that of maturity. This is not the same as security levels, since it is about the degree of fit of the solution to the need. Thus if a situation does not require much security then even if few security mechanisms are applied the solution can be mature, since it is possible to demonstrate confidence that the correct approach has been taken.
The general approach is for business owners and technology owners to work together to set targets, then perform an assessment to determine the current state, identify and mitigate gaps, and then repeat this process periodically as threats, technologies and business concerns change. This creates a continuous improvement cycle.
The model has domains of governance (roughly process), enablement (technology) and hardening (operations) as well as the corresponding sub-domains and practices as shown in the following figure from the SMM:
Each domain, sub-domain and practice can have a comprehensiveness
level associated with it, indicating the depth and completeness of
that item, ranging from none, to minimal (1), ad hoc (2), consistent
(3) and formalized (4). In addition, the model is extensible to
address the needs of specific verticals (e.g. manufacturing, retail,
medical etc) through the use of scope, to enable specifics relative to
certain comprehensiveness levels to be defined. Scope also allows
system specifics as well. A set of comprehensiveness levels including
scope may be defined as an industry profile.
The IoT Security Maturity Model has a table for each of the eighteen practices, providing detail for each of the comprehensiveness levels, including an objective that can be used by business stakeholders, as well as a general description of the level, what needs to be done to achieve it, and indicators of accomplishment. Such indicators can be used to determine in an assessment if the level has been achieved.
The IoT Security Maturity Model includes examples drawn from different verticals for each of the practice comprehensiveness tables as well as case studies at the end. The case studies are based on real assessments that were done previously, recast into the IoT Security Maturity Model to demonstrate that it works for real cases as well as to provide examples that can be understood.
Best Practices from the IIC and elsewhere can be used to provide detailed guidance on addressing the gaps. We are also working on additional guidance in the form of mappings from IoT Security Maturity Model comprehensiveness levels to details in other frameworks like the IIC Security Framework, and IEC 62443, the NIST Cybersecurity Framework and others (e.g. comprehensiveness level 3 maps to this specific guidance). We also are looking to work with partners on creating profiles for verticals.
Thinking long term we have looked at how this model might also be
applicable to the concept of Trustworthiness, which includes security,
safety, reliability, resilience and privacy taken together and outlined
some thoughts on this in the IIC Journal of Innovation Trustworthiness
issue.
This post just introduces the IoT Security Maturity Model. For more complete details, definitions and explanations please refer to the Practitioner’s guide itself. If you would like to participate in further developing this work please join us at the IIC.
If I put a fence with a hole in it in front of a broken wall in front of a partly filled in moat, is my castle secure?
The answer is ‘No’.
On the other hand if the defects are not immediately visible and not lined up with each other, then having these three layers could stop some attackers completely, while others may need time to find the flaw in each. Thus it could require more time and effort on the part of an attacker.
If everyone in the village knows about the flaws, then there might as well not be any barriers. If every weekend they walk through the various openings to have a picnic on the castle grounds, then all know that these barriers are not meaningful, at least to those who are informed.
It is interesting that Defense in Depth was supposedly conceived by the NSA, or at least documented by them, the masters of penetrating systems. To be honest, security in depth has its place, since one of the rationales is that attackers may come from different points in the system, so different security measures may be needed to address different aspects of the overall concern. As the NSA notes, an understanding of the system, adversaries, risks etc is required. Thus “security in depth” has a place as part of a broader understanding but is not functional merely as a mantra.
Security in Depth is mentioned repeatedly in the OPM oversight hearing, an interesting view for both the questions and the answers or lack of answers. Mention of security in depth is usually followed by a statement that there is no security silver bullet (other than security in depth).
There is an alternative to security by depth which is security through simplicity.
Take the case of the OPM, where it is speculated that security clearance background check forms (form SF-86) were taken, each having a wealth of personal information about an individual and their contacts. Security technologies failed to prevent the breach or even detect it while it was in progress (while the OPM is not disclosing details, apparently there were first breaches of the contractors working for OPM, then at least two subsequent breaches. Information on one later breach was loaded into Einstein, an intrusion detection and analysis system , which then flagged a previously unknown earlier breach).
Rather than piling up all these questionable and complex technologies wouldn’t it have been simpler and safer to document and follow a single governance rule:
“All clearance forms and their related documentation, including backups, will be
immediately and completely destroyed following the decision whether to grant clearance on the basis of those forms.”
The principle here is that the information is collected to make a decision, so once the decision is made, get rid of the information. The only reason to keep the information is in the event that a mistaken decision was made, to go back and look for indications that could have indicated the mistake. Is the ability to go back worth the time, costs and risks of keeping the information? It seems not.
During the OPM hearings the question of priorities came up, with the theme of “Isn’t security your #1 priority, so why did you let this happen?”. There was no clear statement of the obvious, which might have been ‘No, security was not the only priority. The priority was the running of operational support systems for other functions, with security as an aspect of that.’
So if those in charge are not willing to destroy the records once a decision is made, what would be the next best alternative? Probably to keep those records on a machine without internet/network access in a locked room. This would raise the cost of adding or reviewing records. By why should they be online once a decision is made?
All of this leads to the question of whether the costs and risks of (in)security in depth are the primary concerns in this case when a policy decision to ‘Eliminate records that have served their purpose’ might have sufficed.
Technology mechanisms and the speed of deployment might not have been the core problem, but rather governance decisions.
Reactively responding to security threats is like a never-ending session of “whack-a-mole”. It will keep everyone busy but probably never end and does not scale with the complexity of the web, its applications and context. Responding to threats is important but we need a longer term solution to the underlying problem.
With the advent of the Web and the reshaping of entire industries to base themselves on the Open Web Platform we are all becoming more dependent on the underlying Trust associated with this platform. Fixing numerous flaws in security and privacy related to ambiguities or errors related to deployment, implementation and design of numerous technologies and their interactions is a huge task that could outlast the businesses and individuals that are relying on the technology. What makes this especially hard is that the complexity of both individual technologies and the composition of those technologies offer many creative avenues for attack (not to mention the impact of Moore’s law to reduce the efficacy of older cryptographic algorithms). To give one example, HTML5 is generally taken to mean the composition of many specifications, such as HTML5, CSS, JavaScript, and a variety of web APIs.
Ultimately what is needed is accountability as noted by Professor Hal Abelson of MIT (slides, PDF). What is also needed are systematic approaches to the underlying issues. For the most part this currently consists of best practices for code development (e.g. validate inputs), for operating system design (e.g. sandbox applications) and deployments (e.g. enforce password strength rules). One issue with this is that everyone is busy meeting time to market constraints and focused on “getting the job done” which typically is the visible functionality, not security. It takes a lot of discipline to build in security, and even so time with the degradation of algorithms and attacks based on complexity remain, creating a long term cost issue. Security and Privacy by Design are worthy approaches toward incorporating concern for these issues into the entire process, but are easier said than done.
Creating standards to enable interoperability is a lot of work, even when the standards are based on previous development experience. Just as code is modularized, so are standards, enabling writing, reviewing and interop testing in a reasonable time frame. This also allows the work to scale as different people work on different standards. This also creates issues as not all assumptions are documented or shared, or as new ideas and approaches appear later in the process (an example might be Promises for example). Some work is also abandoned for a variety of reasons, and this can be good as the community learns. The net result is that there can be inconsistencies among specifications in basic approaches (e.g. to the API interface designs). All of these groups are tasked with creating specific deliverables that specify functionality to be composed with the implementation of other specifications to create applications. This puts the application developer in charge of security and privacy, for only they understand the application, its context and end-end requirements. The designer of a component cannot speak to the privacy data re-use or retention possibilities, or key distribution approaches, for example.
This does not mean that security or privacy cannot be improved by the standardization community. They can. Notable examples include Strict Transport Security to ensure all requests for all web page resources use TLS regardless of web page links, and Cross Origin Sharing (CORS) to define a uniform approach for web browsers to enforce cross-origin web access, to enable use of resources in a web application from a site other than the source of the web application. What else can be done?
Taking an overall architectural view is helpful (see “Framework for Web Science”). The 2001 semantic web layering diagram is illuminating in that the capstone is “Trust” and that “Digital Signature” is a glue binding the parts together, showing the fundamental importance of trust based on security mechanisms (the 2006 version is also in the text showing Crypto instead of Digital Signature and other refinements but still requiring security mechanisms and proof to support trust):
XML Digital Signature 1.1 reached W3C Recommendation this year, demonstrating that creating the security basis is not easy (the JSON approach simplified the requirements and thus the effort but I expect fundamental issues will remain).
I offer another security-centric architectural diagram to suggest the magnitude of the size of the task of “simply providing a security foundation”:
Working through the diagram we see the following items:
Entropy. The basis of most digital security (as opposed to building a physical moat around your castle) is the amount of true randomness or entropy upon which the techniques depend. If the randomness is not there, then the digital techniques fall apart. That makes this the basis, though often ignored.
Key Management. A fundamental security principle is that only the key need be secret, not the algorithms etc. Thus given good entropy, the next building block is suitable keys, keeping private keys secret and so on. A lousy key won’t be of much use.
Next is some means of associating keys with their purpose, discovering and using appropriate keys, and knowing they are valid. I put this as Certificate management (including revocation) and all that goes behind CA certificate issuance. I use PKI terminology but this may not be the only way to accomplish this (in fact the question appears whether X.509 should be replaced, given the ambiguities and complexity)
To be useful the use of crypto algorithms depends on keys and meaningful associations (even though certs may be created using crypto functions as well)
Confidentiality and integrity are fundamental security features, I add identity as an essential building block in this layer (though again obviously certs may support this functionality there may be more to it in terms of policy, access control etc)
Next we get to the Open Web Platform, including a variety of APIs that may use the underlying functionality (yes, Web Crypto may also offer some of this stack in the Javascript layer as well, layers are not clean are they?)
Finally we get to the Web Applications that pull it all together (or do they)?
The reason for doubt is on the side: implementation quality for all items matters a great deal, as does the fact that everything must evolve over time (e.g. key and certification roll-over, algorithm agility etc)
I put trust on the other side to indicate that items must operate in an integrated manner to produce a usable result. (I also left out reputation management as another trust mechanism).
As experienced with Internet protocol layering, some functionality is replicated in different layers and we can discuss what the exact layering should be. However, it is clear that there are a large number of logical components, all of which must work correctly depending on correct design, correct implementation, and correct deployment and use. That offers a large number of opportunities for failure.
What is needed are generic high level simplifications to make trust more achievable. Strict Transport Security does that, taking a successfully deployed protocol and reducing the attack surface. CORS works toward that end at well, by slightly increasing an attack surface to enable needed functionality but in a controlled and understood manner.
It seems that we need more work to reduce the attack surface in a consistent manner, by reducing optionality and choices. It seems that one area is certification – are there too many choices and details in creating certificates and managing them? Can we reduce the choices and ambiguities?
How about Javascript APIs and WebIDL? Can more be done to unify and simplify? Is a best practices guide needed?
It seems a good time to review how much can be simplified, how many options can be removed, and how much consistency can be encouraged. Maybe the W3C TAG could work on this, for example. It seems fundamental to next steps for the Architecture of the World Wide Web.
