As we have laid the groundwork over the last year and a half of publications focused on Security Management for Critical Infrastructure, we can now start to link some solid solution details. This article is the first part of a multi-part release which will outline the component and access features for the contents of the security DNA. I have related this feature several times to the TCP/IP stack which we are familiar with for communication. The TCP/IP stack is the minimum components required on each system to enable it communicate with every other system on a network. The central secrets block or DNA of each device provides a similar uniformity for each system allowing it to participate and link to the security Eco-system. The image shown here which is the focus of this months article shows the component requirements for such a central security management block (DNA).
We already have examples of attackers targeting the eco-system of products before they have even reached their end use networks. For the most part we are not aware of how deep rooted these problems are because many providence chains do not even have a method of detecting such compromises. This article from NexGov.com is the first of these types of compromises which I have found publically discussed, but don’t be fooled it is not the first. I have been pulled into discussions regarding these types of compromises for years, however they were determined to be business problems and embarrassing ones at that, which were tightly controlled as confidential.
Below is another article which I enjoyed because I believe it is right on track. The main problem we have with security solutions is that many companies sell a great product which solves a particular security need. However an end to end solution requires many of these products all linked and interlocked together which to date has not had adequate economically drivers to link up these multiple solutions and providers.
My goal here is to begin just this, pulling together the multiple solutions to build a security eco-system. This months article ends with an open call to start reaching out to me to discuss how we can pull such an Eco-system together. I would love to have conversations with anyone who has taken an interest in my articles which may have some incite to continuing and building such an interlocking security eco-system. The content for this months article can be found on Fierce Smart Grid at the following link.
Managing Secrets is Essential for Securing Critical Infrastructure
In the last few articles we discussed the industry and organizations which make up the Security Eco-system for critical infrastructure. This broader look at industry organization and touch points, is something we will focus on in this article but also will go a little in depth to look at the components of the DNA which make up the security center of each critical infrastructure device. At the heart of linking these two together is a management area which I defined in one of my earliest articles that focuses on the Management of Secrets.
The practice of Secrets Management contains a few aspects which support the Security Eco-system as well as managing logistic support within participating organizations. As I have written on many occasions, Cyber Security is not a technical practice although it has been treated as such by many organizations for many years. Cyber security is best thought of as controlling and enforcing the same actions and operations we do in the real world, but doing so in virtual environments. Any operation we as people perform in the business environment were at one time done by real people in the physical world. Now we are gradually transitioning each of these business operations to the virtual environment. As I do not see this trend reversing, we have to accept that this will be the nature of our world for the foreseeable future.
Handling of most sensitive material in organizations is required to be assigned to people which are accountable, responsible, and trusted by management. In a traditional business environment it is these type of individuals which entirely enable the organization to maintain its competitive edge. They protect corporate secrets and know how as an honored commitment they make to the company. It is the moral code of humans which enables this accountability and trust to maintain a corporation’s confidentiality, and this works because the honorable human believes it is the proper thing to do.
In the physical world we use locked doors and file cabinets, we restrict access and divide the most sensitive components between multiple people. When logistic support is required for large amounts of products or clients, tracking records were maintained in shipping and warehouse filing cabinets with meticulous accuracy. As companies grew and the computer age virtualized sensitive material and logistical databases, this shift also migrated and distributed the accountability and trust for handling of these sensitive items. Cyber security operations done by systems with distributed permissions and authorization now take the place of the rigid human implemented honor system controls.
Determining Sensitive material
What types of things are considered sensitive material which needs to be organized by Secrets Management? First we will talk about the contents of the distribute DNA of each device. If you remember in the article “Why critical infrastructure needs both asynchronous and synchronous components” I explained that when we look at the needs for cryptographic key management the question that I found needed to be answered was “what environmental factors act on each system and what components need to be in a central DNA to support each of these environments and actors?” Components of the distributed DNA needs to consider the influences of each actor across the four TA-chains. The expanded list of influencer categories I have identified through my research include:
- Manufacturers programing transports
- Device Unique identification, configuration, and signatures
- Manufacturer and Network vendor credentials
- Cryptographic communication and sessions keys
- Organizational trust management and cross-organization certification
- Change maintenance and upgrade verification
- Personal users, ownership, identity, and account logistic information
- Distributed network identity management credentials
- Continued operation, security renewal, and key derivation secrets
When looking at the list of categories of secrets some are directly used for mathematical cryptographic operations which implement the mechanics of cyber security while others are logistic and organizational. Some have a strict need for confidentiality while others have public access visibility. The thing that is universal is that the use of these components of the DNA needs to be strictly enforced in accordance to the need for each particular content portion of the DNA. The figure “Detailed Key Management Block” shows a possible design for these components divided into three use scopes: supply chain, governance, and operational.
Figure: Detailed Key Management Block
Managing Secrets in the Supply Chain scope
The first scope of distributed DNA secrets is the development scope (supply chain scope) and it starts in the manufacturing of the products themselves, this begins with the generation of the bit strings themselves. These initial processes need to consider the quality of the generation process and protection of generation algorithms. This scope includes the need for the cryptographic secrets to be controlled in every distributed manufacturing process to ensure they are not available to untrusted parties. A large part of this scope is to provide methods of secure provisioning to insert them into each system Trust Center.
One of this management area primary focuses is ensure that a vendor’s product line does not become compromised. In the article “Can we trust information from embedded systems?” we explained the need for diligence in designs of embedded systems to enable us to trust data produced by such systems. The following items have to be addressed to manage secrets successfully. In evaluating the strength of a supply security each of these elements of secret management should be evaluated in order to get an overall understanding of the embedded devices (or product lines) resistance to compromise.
- Process of generating secrets
- Storage of global or product line IP secrets
- Personal access to secrets, separation of visibility.
- Access to enterprise systems holding IP secrets
- Procedure of personal accessing secrets
- Process and medium for transporting secrets
- Diversification of secrets in devices
- Product line provisioning process
- Logistical control and tracking secrets
- Access to onboard secrets in deployed products
- Distributed re-provisioning of deployed products
Manufacturers programing transports need to be held confidential and only used during the initial customization programing. For the strongest use of these transports they should either be eliminated after use or diversified to new derived content as part of each use. Diversifying to a new derived contend as part of use would enable the reprogramming of initial customization information as a last resort to compromise later on in the life of the product.
The largest risk here is the access to product secrets by subcontractors in various regions of the world where they are manufactured, or transferred through possible untrusted parties. These secrets either need to be inserted securely or inserted in a trusted environment both of these do not usually coexist. To have a trusted environment relies on trusting some local individual or group of individuals to have knowledge of or access to cryptographic secrets. A high accountable security policy should provide for separation of duties and division of scope. Producing a structure where no single individual has the entire picture would be essential in such an environment so that collaboration would be required to compromise product secrets.
Setting up a secure insertion process with the products requires a large initial effort and high assurance that each step of the process is trusted. This is most effectively done when using a hardware security module (HSM) to maintain secrets in conjunction with a designed in cryptographic transport in the device itself. This can set up an environment where the secrets are inserted by the owner into the HSM in an encrypted format, using asymmetric cryptography where the HSM secures the private decryption key. The HSM would then interface with each part providing an encrypted provisioning method using the devices built in transport along with a unique randomness input for each transaction. In this environment a rather high assurance that only the customer that inserted the secrets into the HSM have knowledge of the secrets and no one in the manufacturing environment would be ever have access to the customers secrets.
A secure insertion process also has some exceptional challenges relating to the ability to maintain a logistical accuracy for what secrets are in which components. Since visibility is removed from the manufacturing process they cannot offer any logistical assistance on what secrets were mapped to each products. There is also the risk that the secure insertion process in the product will be compromised and thus the entire effort circumvented.
Supply chain control entails management of secrets and/or products from the location they are produced through assembly, integration, distribution up to the utilization by end product users. This includes being able to determine which device has what secret when it comes time to use it in the field. This can then enable revoking known compromised products by providing an operational white listing method.
The storage of product manufacturing, including any parties involved with supply chain of both hardware and software is important to track a product throughout its lifecycle. This information is needed for maintaining a trust chain and accountability to enable many security features. It also provide means of tracking quality, reliability, warrantee actions, operational and update support.
Activating Secrets Management
As we continue expanding on Secrets Management we will see several times the necessity to reference DNA components by thinking about them two ways. First strings of bits which is used directly in a cryptographic operation usually referred to as Keys. However, when including the expanded scope where all the actors which interface with the DNA are part of managing secrets, now there are strings of bits which are not keys. They need to be stored internal to a key management block (DNA) and used to produce other usable strings but not used directly for cryptographic operations. The only fitting way to reference these just important aspects of are to address them as sets of secrets.
As we continue to explore Secrets Management in the next two scopes (over the next few articles) keep in mind this logical separation, as well as the need for strict access restrictions that will also become more obvious as we roll out these areas. As I first brought to light in my last article much of the industry requirements for Secrets Management does not currently exist today. Any of my readers who would like to begin discussions on where a particular product or capability offering would fit into this eco-system pleas open up discussions threads or reach out to me directly. I would love to be aware of any products or services which can be featured to build awareness to current or evolving solutions in this area.
Original Article Link: Managing secrets is essential for securing critical infrastructure
Training from ICS-ISAC – Security Eco-System for Critical Infrastructure