Page 6 - Cyber Warnings

• Requirements stage: Once a system-wide threat assessment is available, the device
threat surface can be understood. At the requirements stage, security-specific
requirements can be introduced, along with known “abuse cases” (use cases that an
attacker might follow) and a risk analysis. Security requirements, as listed below, are
introduced and accounted for. This stage is critical because it is the point at which
security becomes a known development project goal with the appropriate level of risk
management, scheduling, and costing.

• Design and architecture: As candidate architectures become available, reviews must
include security aspects (where previously, they may not have). Assessing architecture
in light of the known threat assessment and security requirements adds an additional
dimension to this phase of development. At this stage, testing plans should be created
that include security analyses that follow the perceived “abuse cases.”

• Code development: At the coding stage, following security guidelines and coding
standards are critical. The use of automation tools such as static analysis is key to
ensure that vulnerabilities are not introduced into the product. Testing and test
automation that includes a security analysis are important at this stage.

• Integration and test: As the system as a whole starts to take form, subsystem and
system testing will find vulnerabilities before integration and deployment to the market.
Automated penetration testing tools can be very helpful at this stage to uncover
vulnerabilities that may not have been accounted for in earlier stages of development.
Packaging and configuration of the end product for deployment is key at the final stages.
Ensuring that the out-of-the-box product is as secure as possible prevents many of the
security issues we see today in connected devices.

• Deployment and maintenance: When a product enters the market and starts wide
deployment, security vulnerabilities become exponentially more costly to fix. A product
designed with a security-first approach is less likely to end up with a security breach, but
companies must be prepared to deal with security on an ongoing basis. Designing the
product with the ability to update firmware and software is critical to addressing new-
found issues expeditiously. However, as a product goes through maintenance and
revision, security is an ongoing concern, and new vulnerabilities and threats need to be
fed back into the system in an iterative approach.

Security Requirements
Securing an embedded device requires many considerations. Key examples of security
requirements that might go above and beyond existing functional requirements are as follows:

• User authentication – validating user access and enforced privileges for different
classes of users.

6 Cyber Warnings E-Magazine – March 2017 Edition
Copyright © Cyber Defense Magazine, All rights reserved worldwide