Posts Tagged ‘Software Attacks
Security a New Dimension in Embedded System Design
Embedded systems, which will be ubiquitously used to capture, store, manipulate, and access data of a sensitive nature, pose several unique and interesting security challenges. Security has been the subject of intensive research in the areas of cryptography, computing, and networking. However, security is often mis-construed by embedded system designers as the addition of features, such as specific cryptographic algorithms and security protocols, to the system. In reality, it is an entirely new metric that designers should consider throughout the design process, along with other metrics such as cost, performance, and power.security in one form or another is a requirement for an increasing number of embedded systems, ranging from low-end systems such as PDAs, wireless handsets, networked sensors, and smart cards, to high-end systems such as routers, gateways, firewalls, storage servers, and web servers. Technological advances that have spurred the development of these electronic systems have also ushered in seemingly parallel trends in the sophistication of security attacks. It has been observed that the cost of insecurity in electronic systems can be very high. For example, it was estimated that the “I Love You” virus caused nearly one billion dollars in lost revenues worldwide.
With an increasing proliferation of such attacks, it is not surprising that a large number of users in the mobile commerce world (nearly 52% of cell phone users and 47% of PDA users, according to a survey by Forrester Research) feel that security is the single largest concern preventing the successful deployment of next-generation mobile services. With the evolution of the Internet, information and communications security has gained significant attention. For example, various security protocols and standards such as IPSec, SSL, WEP, and WTLS, are used for secure communications. While security protocols and the cryptographic algorithms they contain address security considerations from a functional perspective, many embedded systems are constrained by the environments they operate in, and by the resources they possess. For such systems, there are several factors that are moving security considerations from a functioncentric perspective into a system architecture (hardware/software) design issue.
- An ever increasing range of attack techniques for breaking security such as software, physical and side-channel attacks require that the embedded system be secure even when it can be logically or physically accessed by malicious entities. Resistance to such attacks can be ensured only if built into the system architecture and implementation.
- The processing capabilities of many embedded systems are easily overwhelmed by the computational demands of security processing, leading to undesirable tradeoffs between security and cost, or security and performance.
- Battery-driven systems and small form-factor devices such as PDAs, cell phones and networked sensors often operate under stringent resource constraints (limited battery, storage and computation capacities). These constraints only worsen when the device is subject to the demands of security.
- Embedded system architectures need to be flexible enough to support the rapid evolution of security mechanisms and standards.
- New security objectives, such as denial of service and digital content protection, require a higher degree of co-operation between security experts and embedded system architects.
Securing against software attacks
Software is a central and critical aspect of the computer (and embedded system) security problem. Software defects with security ramifications —including implementation bugs such as buffer overflows and design flaws such as inconsistent error handling — promise to be with us for years. All too often, malicious intruders can hack into systems by exploiting software defects. Moreover, Internet-enabled software applications present the most common security risk encountered today, with software’s ever expanding complexity and extensibility adding further fuel to the fire.
Software security’s best practices leverage good software engineering practice and involve thinking about security early in the software design life cycle (SDLC), knowing and understanding common threats (including language-based flaws and pitfalls), designing for security, and subjecting all software artifacts to thorough objective risk analyses and testing.
Security is an emergent property of a software system. This is a subtle point often lost on development people who tend to focus on functionality. Obviously, there are security functions in the world, and most modern software includes security features, but adding features such as SSL (for cryptographically protecting communications) does not present a complete solution to the security problem. A security problem is more likely to arise because of a problem in a standard part of the system (e.g., the API to the server) than in some given security feature. This is an important reason why software security must be part of a full lifecycle approach. Just as you cannot test quality into a piece of software, you can not spray paint security features onto a design and expect it to become secure.
Figure 1: Software security best practices applied to various software artifacts in the Software Design Life Cycle (SDLC)
As practitioners become aware of software security’s importance, they are increasingly adopting and evolving a set of best practices to address the problem. There is no substitute for working software security as deeply into the development process as possible and taking advantage of the engineering lessons software practitioners have learned over the years. Figure 1 specifies one set of best practices and shows how software practitioners can apply them to the various software artifacts produced during software development. Although the artifacts are shown laid out in a linear sequence, most organizations follow an iterative approach, which means that best practices will be cycled through more than once as the software evolves.
Software security best practices apply at various levels:
- The requirements level: Security requirements must cover both overt functional security (e.g., the use of applied cryptography) and emergent characteristics.
- The design and architecture level: A system must be coherent and present a unified security architecture that takes into account security principles (such as the principle of least privilege).
- The code level: Static analysis tools — tools that scan source code for common vulnerabilities — can discover implementation bugs at the code level.
Risks crop up during all stages of the software life cycle, so a constant risk analysis thread, with recurring risk tracking and monitoring activities, is highly recommended. Security testing must encompass two strategies: testing security functionality with standard functional testing techniques, and risk-based security testing based on attack patterns and threat models. Penetration testing is also useful, especially if an architectural risk analysis is specifically driving the tests.
Embedded Software Attacks and Countermeasures
Software in embedded systems is a major source of security vulnerabilities. Three factors, which we call the Trinity of Trouble — complexity, extensibility and connectivity — conspire to make managing security risks in software a major challenge.
1. Complexity: Software is complicated, and will become even more complicated in the near future. More lines of code increases the likelihood of bugs and security vulnerabilities. As embedded systems converge with the Internet and more code is added, embedded system software is clearly becoming more complex. The complexity problem is exacerbated by the use of unsafe programming languages (e.g., Cor C++) that do not protect against simple kinds of attacks, such as buffer overflows. For reasons of efficiency, C and C++ are very popular languages for embedded systems. In theory, we could analyze and prove that a small program is free of problems, but this task is impossible for programs of realistic complexity today.
2. Extensibility: Modern software systems, such as Java and .NET, are built to be extended. An extensible host accepts updates or extensions (mobile code) to incrementally evolve system functionality. Today’s operating systems support extensibility through dynamically loadable device drivers and modules. Advanced embedded systems are designed to be extensible (e.g., J2ME, Java Card). Unfortunately, the very nature of extensible systems makes it hard to prevent software vulnerabilities from slipping in as an unwanted extension.
3. Connectivity: More and more embedded systems are being connected to the Internet. The high degree of connectivity makes it possible for small failures to propagate and cause massive security breaches. Embedded systems with Internet connectivity will only make this problem grow. An attacker no longer needs physical access to a system to launch automated attacks to exploit vulnerable software. The ubiquity of networking means that there are more attacks, more embedded software systems to attack, and greater risks from poor software security practices.