Secure-by-Design – What it really means
For decades, device security took a back seat to considerations of feature/functionality – responsiveness, connectivity, UX, etc. – and to protecting OEM intellectual property. Architects and developers typically deferred the issue of cybersecurity to the networks and locales where their devices were deployed, relying on in-place perimeter security, or crossing their proverbial fingers, hoping that their software and hardware choices would remain unnoticed by bad actors, practicing security-by-obscurity.
In today’s increasingly hostile cybersecurity environment, architects of intelligent devices find themselves facing customer and industry-based requirements to build more secure systems. But legacy practices don’t die easily, and incremental approaches remain the norm: embedded devs will typically first implement a combination of good practices and technologies to satisfy such requirements, e.g., using SCA tools to manage vulnerabilities, enabling parameter checking, performing pen-testing, expanding code reviews, adding encryption, multi-factor authentication, etc. All excellent, but a patchwork of remediations can still leave systems exploitable and open to attack.
To achieve maximum security, embedded designs must rethink designs ab ovo – from the beginning.
A Security Foundation
Secure-by-Design is increasingly becoming the mainstream development approach to ensure security of software systems. Advocates of the methodology often promote it with great zeal, bordering on the religious, but it is a very scientific and logical approach to software and device security.
Secure-by-Design means that software and devices are designed to be foundationally secure using a documented and repeatable process, one that proceeds in distinct phases and dovetails into existing product and service life-cycles, as illustrated here.
Let’s step through the phases, examining inputs, outputs and implications.
Risk Analysis
Risk analysis entails identifying and analyzing potential issues that could negatively impact device use cases and/or business operations, particularly in terms of the assets we are looking to protect.
Performing a risk analysis considers adverse events caused by malicious or inadvertent human activities and also by acts of nature, like weather or earthquakes. An important part of risk analysis is identifying the potential for harm from these events, as well as their likelihood.
Risk Analysis is a cross-discipline activity that can involve input from the CISO’s office, engineering, product management, product test, QA/QC, field engineering, tech support, even legal and finance. For enterprise software and services, the IT department also plays a key role.
Typical Risk Analysis steps include
- Enumerating assets needing protection (data, PII, currency, hardware, etc.) and their security properties (integrity, confidentiality, availability, etc.)
- Identifying attacker and threat profiles, including business models – most often, bad actors are looking to monetize their activities in some way: stealing IP, installing ransomware, mining Bitcoins, etc. State actors, by contrast, seek to exfiltrate industrial secrets or cause physical or financial damage to infrastructure.
- Defining resistance levels commensurate to the threats – not all threats have clear defenses and budgets for countermeasures are finite.
- Evaluating the balance between risks and organizational benefits
- Planning responses and remediation for technology failure or asset loss.
The output of the Risk Analysis is typically a set of General Security Requirements.
Security Design Assessment
Understanding the risks is not the same as designing a product or service to meet those risks. The goal of a Security Design Assessment is to map identified risks onto the features and functions of a product or service. Such mapping ensures that both general and risk-specific resilience form a foundational part of the product specification (vs. an afterthought).
During this phase, it is also beneficial to consider system software architectures that offer intrinsic security benefits, like those found in systems built on a Trusted Computing Base and/or that leverage available technologies like TrustZone and off-the-shelf secure components.
An oft-ignored activity under Security Design Assessment, especially for organizations implementing Secure-by-Design for the first time, is integrating security best practices across the entire product life-cycle. Secure-by-Design must span all steps, from design and prototyping through deployment and ultimately through end-of-life (at which point products are more easily acquired and analyzed to discover attack surfaces and vulnerabilities).
Security Design Analysis, like Risk Analysis is cross-disciplinary, and should involve the same range of roles and any others involved in the product life-cycle, e.g., documentation and even product marketing, who will need to describe and promote security configurations and capabilities.
The output of the Security Design Analysis must be actionable, not a set of security ideals but requirements and practices that will result in delivering a more secure product or service. Typically these outputs are embodied in a Product Function Security Requirements document, that accompanies other requirements sets, but also explicitly covers key life-cycle activities like testing and QA.
Security and The Product Life-Cycle
Secure-by-Design is not a do-once-and-forget activity. To be effective, the practices and controls involved must be ongoing, and apply to agile as well as legacy development practices. Data and experiences generated across that life-cycle must feed back into Secure-by-Design: new product features may constitute new assets in need of protection; bugs reported to tech support may require remediation for security; the complete software stack must be reviewed regularly for vulnerabilities in software and hardware components; new types of attacks will change threat profiles and resilience priorities.
ProvenRun Is Here To help
Because Secure-by-Design is such a comprehensive vision and approach to securing products and services, it can seem daunting, even unrealistic. Or just too hard or too expensive. It needn’t be, and the return on this security investment is safer, more reliable designs and increasingly, being able to meet mandates for cybersecurity from customers and governments. ProvenRun is here to help.
Learn more about ProvenRun Security Consulting and Security Engineering to help you adopt and integrate Secure-by-Design into your company’s development practices.