If you make devices that support enterprise operational tasks, sensor data gathering, or a range of other enterprise processes, then your device’s security posture is a major concern for your customers.
But if you are not in the IT security industry, the security posture for your device may not even be something that is clearly defined in product requirements. Besides the obvious security-oriented features, such as encryption and authentication and compliance-mandated features, security requirements are often embedded in a host of other functions and processes that may be covered by your device requirements.
But security practitioners think of these various features, settings and functions as the security posture.
As we discussed in a previous blog posting, the classic description of a security posture is defined by the National Institute of Standards and Technology at the enterprise level. It says in essence that the enterprise’s network and systems are capable of defending the enterprise’s information and assure its security and integrity.
That flows down to each system and device supporting the enterprise’s information movement, processing and storage.
There are a large number of security guides, frameworks and checklists that can be used by an enterprise to audit its security posture and perform vulnerability assessments, covering everything from policy development to employee training to enterprise application architectures.
For the developer of a device to be deployed by an enterprise, what does the enterprise security posture mean in practical terms?
Want to be secure? Join the CIA
An effective security posture is one that protects the Confidentiality, Integrity and Availability (CIA) of the information and systems required to meet the company’s operational goals.
This “CIA Triad” is a longstanding rule-of-thumb that security practitioners use to assess the security from an information perspective:
- Can you keep the company’s information confidential when it is required?
- Can you ensure the integrity of information, to prevent modification or manipulation by unauthorized people?
- Can you ensure the availability of information when it is needed?
Sometimes security analysts replace the “a” term in CIA with Authentication or Access. Really all of those concepts apply in the general CIA framework as well.
Of course, your customer’s industry, regulatory environment or particular application for your device will frame how CIA applies to your device in the broader security posture. For example:
- An IoT medical device may be handling or processing data that falls under the category of Protected Health Information and so, in the US, must be secured to be compliant with the Health Insurance Portability and Protection Act (HIPAA). That implies the use of encryption for confidentiality.
- An Industrial Internet of Things sensor device may be measuring the temperature for a particular machine in a manufacturing process. If that temperature reading is important for quality control, for example, then the availability of that IIoT sensor’s information is essential. That implies redundancy, high availability configurations, defenses against communications disruption, and so on.
Security Posture Requirement Evaluation
As the examples illustrate, CIA is focused on the enterprise’s information, so you need to dig a level or two deeper to apply it to the underlying systems and processes. Depending on your product requirements process, these may be consolidated into a single group of security requirements, or may be spread across and integrated into all requirement categories.
To understand the security posture of your device, you will need to evaluate a host of functional and deployment parameters:
- Networking: Public, private, wired, wireless, cellular.
- Access control: Remote, local, and authentication methods, such as single- and multi-factor.
- Functional footprint: Are only the minimum necessary functions in place and operational, to keep the attack surface as small as possible?
- Device hardening: If an attacker gains unauthorized access to the network or the device, what can they do? How can you limit the impact of a successful compromise?
- Updating and patching: How will controlled and secure updates be delivered and installed, especially to respond to new vulnerabilities in a timely way?
- Security architectures: How will the device operate in relation to security architecture elements such as firewalls, intrusion detection systems, access gateways, and so on?
- Security requirements: Will the device operate in the context of specific enterprise information security requirements, such as handling data that could identify a healthcare patient or that is a financial transaction?
This list is certainly not exhaustive and there may be more or fewer dimensions to consider depending on your particular device and deployment context.
Secure by Design
Timesys has worked for years with product developers to bring their products to market very quickly but with strong embedded system security postures. Our build environments include Yocto Project and Timesys Factory and we offer best-in-class services and support for embedded Linux development.
In addition, our new TRST Product Protection offering enables product developers to audit the security posture of their systems, harden them, establish secure update processes, minimize attack surfaces, and reduce the risk of compromise in a deployment.
About Timesys
Timesys has extensive experience with embedded system development and lifecycle management. Timesys has been instrumental in working with global leader semiconductor manufacturers with smart, quick and quality solutions for highly complex systems with accelerated product innovation and multiple product variants.
