|
|
|
Market Research Report
Avoiding an Embedded Security Disaster: What vendors, OEMs and developers need to know about embedded security
|
Avoiding an Embedded Security Disaster: What vendors, OEMs and developers need to know about embedded security published by Embedded Market Forecasters in July, 2007. This report consists of 43 pages and the price starts from US $ 3750.
Abstract
Introduction
For many years, embedded systems have been quietly working behind the scenes
of almost all modern technologies, from automobiles to factory floors to space
exploration missions. Increasingly, these critical embedded systems are built
from COTS software, and often incorporate standards-based network
connectivity. Just as the early networked desktop PC' s and server' s were
unprepared to address the new security implications of network connectivity,
today' s embedded systems present a significant new security concern, which
must be addressed immediately and systematically. This paper will examine
several significant embedded systems security concerns, and where possible
outline recommended courses of remedial action.
Executive Summary
Embedded systems are responsible for the availability and functionality of
many critical systems, from factory automation to gas pipeline monitors to
networking equipment. Unfortunately, the critical importance of embedded
systems is seldom matched with a strong, comprehensive security
infrastructure. Some of the critical security issues presented by modern
embedded systems are:
- Diverse network-connected embedded systems use combinations of custom and
COTS software, the details of which are typically known only to the vendor of
each embedded device, making vulnerability assessment, risk analysis, and
patch management difficult
- Many embedded protocol implementations derive from older versions of
opensource software like OpenSSL and the BSD TCP/IP stack, resulting in
vulnerabilities to known attacks, which have since been patched in the main
software distributions
- Many other protocol implementations are built entirely from scratch, and
have not benefited from years of public analysis and repeated attack,
resulting in unproven protocol implementations that may be vulnerable to attack
- Even when vulnerabilities are identified, patches must be developed for
each device or device family by the vendor, requiring tight collaboration
between embedded software developers and the OEM' s building devices based on
the developers' software
- Deployment of software patches is even more difficult, expensive, and
timeconsuming than the most elaborate mobile/remote patch management systems
for PCs and PDAs, making the total cost of a vulnerability in an embedded
system much higher, and the motivation to patch that vulnerability much lower
- Most network-aware embedded devices lack sufficient management and
auditing functionality, making centralized configuration and monitoring
difficult and costly, and severely limiting the data available for attack
pattern detection and afterattack forensic analysis
- Embedded systems are not always considered an IT responsibility, and thus
often fall outside IT control, resulting in lax policy enforcement, minimal
configuration management and auditing, distorted risk analyses, and little or
no integration with enterprise security tools
Remediation of these issues will require a concerted effort on the part of
commercial and custom embedded software developers, OEM' s building embedded
systems, vendors selling them, and customers purchasing and implementing
products based on network-aware embedded software. Until information security
becomes a strategic technology for embedded systems developers, their products
will continue to be characterized by complacency and vulnerability.
Table of Contents
- AVOIDING AN EMBEDDED SECURITY DISASTER: What vendors, OEMs and developers
need to know about embedded security
- Introduction
- Executive Summary
- Encryption (or lack of)
- Lack of Certified Encryption
- The Federal Information Processing Standards (FIPS): Why embedded vendors,
OEMs and developers need to incorporate FIPS 140-2
- Improper Application of Encryption
- Using Strong Encryption, Weakly
- Key Size Disparities
- Using "Pretend" Encryption
- Unproven Protocol Implementations
- SNMP
- TCP/IP
- OpSenSSL-derivatives
- Inevitable Conclusion
- Protecting the Wrong Things
- Lack of Management & Monitoring Abilities
- Painful & Expensive Patch Management with Minimal Accountability
- Embedded Limitations At Odds with Security Requirements & Existing
- Security Standards
- SSL
- SSH
- IP-Sec
- Common Requirements - SSL, SSH, and IP-Sec
- When SSL, SSH, and IP-Sec Are Overkill
- Lack of Vendor- or Industry-Originated Best Practices
- Insecure by Default
- Ambiguous Responsibilities
- Summary
- Appendix A - A Brief Introduction to FIPS 140
- What Is FIPS 140?
- Why is FIPS 140 Important?
- I' ve never heard of FIPS 140, So How Important Can It Be?
- How is FIPS 140 different from the Common Criteria certification?
- How is FIPS 140 different from SSL or IP-sec?
- If I have FIPS 140 certification, does that mean my system is secure?
- How can I get FIPS 140 certification?
- Appendix B - Integration of FIPS 140-certified Modules into Embedded
Solutions
- Embedded Systems Support
- Insufficient Flexibility
- Unacceptable Pricing, Licensing Terms
- Out Of Date Certifications
- Available Toolkits
- Integrating FIPS 140 into New and Existing Embedded Systems
- An SSL Implementation
- An IP-Sec Implementation
- A Proprietary Product with Existing Encryption Capabilities
- A Proprietary Product without Existing Encryption Capabilities
- RTOS CONSIDERATIONS
- Appendix C - A Survey of Embedded Security Products
- IP-Sec Implementations
- TeamF1 V-IPSecure
- Elmic Systems Voyager IPsec/IKE
- InterPeak IKE
- InterPeak IP-sec
- SSL Implementations
- TeamF1 SSLimSecureSecure
- Interpeak Embedded SSL
- Accelerated Technology Nucleus SSL
- SSH Implementations
- TeamF1 SSHield
- Interpeak Embedded SSH
- Proprietary Encrypted Communication Tools
- Embedded Management Technologies
- FIPS 140 Certified Encryption Toolkits
- Certicom SecurityBuilder GSE
- Cryptos Mobile Systems TACHYON-Crypt
- Atmel AT97SC3201
- Appendix D: Glossary
|
 |
