Mobile and embedded software teams, users and stakeholders have historically underestimated the risk of security threats. As a result, vulnerabilities that can be exploited by hackers to gain access to mobile and embedded software devices are on the rise and will only continue unless the programming and testing staff takes measures to prevent them. These vulnerabilities can come from many sources such as: inadequate architecture or poor design, software coding errors, and intentional code such as viruses and back doors inserted into the code during development or updates. This paper examines a variety of good engineering practices that should be considered to minimize and control vulnerabilities during development and test activities. While much of this advice may seem common to historic information technology (IT) security concepts, it is still under used in many mobile and embedded system projects. An overview of testing attack concepts with specific considerations for mobile and embedded software devices will be introduced.
Software has had security issues since its inception. Now with nearly everyone on the planet carrying networked computers in their pockets added with the rise in hacking (gaining unauthorized access), vulnerabilities must be prevented. With the increased use of embedded devices and mobile systems (smart phones, pacemakers, cpus and interface units in cars and Bluetooth networks in and connected to cars, tanks, Humvees, etc.), devices that once were not considered a security risk should always be considered vulnerable. The industry is experiencing hacking of embedded systems such as avionics (GPS spoofing of drones, even cars), medical (pacemakers), and factory systems (controllers). Solders now carry “personal” cell phones as well as other “smart” devices into the battlefield to assist them in tracking friendlies and enemies” or to call in air strikes, as simple examples. These example mobile and embedded systems and the software executing on them represent non-traditional threats yet are examples of areas where software compromises must be stopped.
It may be tempting to consider mobile and embedded devices using the same security measures as traditional IT systems. In some cases, this may mitigate vulnerabilities. However, mobile and embedded devices have features that set them apart from traditional IT systems including:
• Networking situations that change quickly or networks that can be subject to vulnerabilities themselves;
• Mobility issues such as device ownership that can be changed or lost without prior knowledge or devices with features supporting movement, etc.;
• Resource limitations such as power, processing speed, memory, and certain timing issues;
• Environmental factors such as water, sun, cold, heat, dust, moisture, and so forth;
• Different user interfaces (UIs) such as smaller screen size, readability, touch screen issues including swiping;
• Operability on many hardware platforms and integration issues;
• Different cycles of software and hardware updates and how those are handled, compared to the classic IT domain.
Mobile and embedded development teams have begun to recognize the impact of these aspects but are slowly reacting to the security threats. Further, mobile and embedded devices may contain unknown, even counterfeit software that can present a threat without the knowledge of the user or network. Even without counterfeit software, the system may come with vulnerabilities [1, 2]. Further, the rapid growth of 25% (or more) per year in mobile and embedded software markets  means that security risks are likely to increase.
This paper examines software lifecycle considerations for reducing security threats with a focus on security test attacks. Since security topics are large and complex only basic introductions are presented with pointers to further information.
Software is now embedded in cars which are being hacked [4, 5], industrial control systems which are at risk , mobile devices with vulnerabilities [7, 8, 9, 10], medical devices that have been hacked  and other areas, all of which face security concerns. The paper defines development mitigations including architecture, design and coding practices. Then, security attacks that the test team should consider are summarized. While a majority of the concepts presented are applicable to various types of software domains, many of the concepts presented are either not well known or well-practiced within mobile and embedded software development projects, as illustrated in error taxonomies reported in [2, 5, 7]. A goal of this paper is to increase the awareness on mobile and embedded development projects of basic security concepts, while presenting some security concepts tailored to mobile and embedded domains.
The Situation: Mobile and Embedded Software Security Threats 
At one time, not too many years ago, mobile systems, did not exist and, embedded software devices were safely sequestered and isolated from networks. Thus, security threats to such devices and systems were limited or not considered, at all. Mobile and embedded development teams may have introduced security vulnerabilities but did not conduct security testing because of the lack of risk. This is changing. For example, a Coverity Scan 2010 Open Source Integrity Report for Android  done using static analysis testing (a type of attack) found 0.47 defects per 1,000 Source Lines of Code (SLOC) for a total 359 defects. Of these, 88 were considered “high risk” in the security domain. Also, an OS hole in Android with Angry Birds counterfeit software allowed researchers Jon Oberheide and Zach Lanier (http://jon.oberheide.org/) to gain access to embedded devices. Further, there are numerous reports  of cars and medical devices now being hacked. Additionally, soldiers and employees are carrying personal devices (smart phones) into the theatre and work environments that cannot be certified “risk free.” With security attacks such as GPS spoofing and cracking attacks, these devices introduce a risk brought in by the very users of the devices. And finally, there is the Stuxnet virus (http://spectrum.ieee.org/podcast/telecom/security/how-stuxnet-is-rewriting-the-cyberterrorism-playbook) and its decedents which demonstrate risks to factory control systems worldwide. These data points illustrate the risk of vulnerabilities to mobile and embedded devices. Teams need to be aware of traditional IT security approaches as well as those for mobile and embedded considerations.
For every security counter measure solution, hackers may find another problem or attack to implement. It is a constant game of cat and mouse. It is tempting to go back to pen and paper but even these were not secure! There are numerous general security safeguarding measures to consider, which are covered in this article.
If teams could create perfect software, they would not need to be concerned with security vulnerabilities because they could just “build it” secure. But since software development is a human creative process and humans make mistakes at all levels of development (concept and requirements, architecture and design, coding, and testing), teams can only seek to minimize security risks during these efforts.
Development Pattern Activity 1: Plan and Specify a Secure System 
Certainly building a more secure software system must start at the beginning with plans, concepts, and system specifications. The more security risks a software system has, the more these efforts can be justified. For example, consider:
• Methods to clearly specify requirements - see http://sun nyday.mit.edu/safer-world/index.html
• Formal methods - see https://www.ece.cmu. edu/~koopman/des_s99/formal_methods/
• Model-based systems and software development - see Object Modeling Group at http://utp.omg.org/
Such approaches may be of use for some mobile and embedded systems, but more than likely, most systems with software efforts will use a waterfall lifecycle or derivative of it, or alternatively, they will use agile concepts . However, any approach can introduce vulnerabilities. Additionally, most mobile and embedded systems are a mix of non-developed (off-the-shelf) and customized software components, both of which come with vulnerabilities. Organizations need to put forth a good offense and defense starting with systems engineering. Active Systems Engineering addresses functional and non-functional requirements, including security characteristics. Systems engineering should be supported by the right level of system analysis including active verification and validation with early attack testing, which can find some errors even before coding starts.
Finally, planning should address product control concepts such as anti-tamper features, software protection for downloaded files to ensure “correct” software is obtained e.g., internal signatures such as a checksum, encrypted files and data, and trusted supply chain management. These concepts can be used to reduce the likelihood of a project obtaining counterfeit software from outside parties (i.e., malware). Afterwards, plans would progress into design, architecture, coding, and testing where each stage would ensure that steps are taken so that malicious or vulnerable software is not introduced into the product.
Development Pattern Activity 2: Design and Architecture 
As the system is planned and specified, considerations regarding architecture and design need to be included. In architecture and design, the engineer needs to develop secure software with proven practices including:
• Selecting secure architecture structures;
• Careful development of data structures and databases;
• Trade studies and specification of non-developed items;
• Minimization of design coupling and maximized cohesion;
• Involvement of user considerations, where user includes the malicious user or hacker;
• Rigorous systems and software engineering practices including threat and risk assessment; and
• Design practices that consider security threats.
Weak architecture and design practices can impact the overall vulnerabilities that no amount of good coding and test practices can fully overcome.
Development Pattern Activity 3: Coding Practices 
With foundations of requirements and frameworks provided by architecture and design, implementation programming stands a better chance of minimizing errors and vulnerabilities. All projects need good coding practices in place to help minimize sloppy coding practices which can introduce risks. Samples of recommended mobile and embedded coding practices are listed in Table 1.
Development Pattern Activity 4: Verification and Validation Security Testing
A significant focus of this paper is on concepts that can be applied to mobile and embedded systems at any point in time to improve and address security vulnerabilities by applying software verification and validation testing concepts as defined in standards such as IEEE 1012 and ISO29119 [17,18]. Verification and validation security testing is applicable during development, operation, and maintenance. For example, the security threats of a piece of mobile software will likely evolve as the devices are used in differing situations and for newer purposes in operational use. Consider a smart phone app designed for civilian use that is taken into the battlefield without proper security testing only to end up compromising, hurting or killing our troops or our “friendlies.” As part of full life cycle rigorous security practices, the concepts of risk and attack-based testing [18,2] prove particularly useful.
Risk-based Testing with Criticality Levels 
Fundamental to many development and testing efforts is the idea of risk management. Not every mobile or embedded software device poses the same risk, threat, or has the same vulnerabilities. For example, a small standalone mobile game on a smart phone is not the same as a mobile mapping app that a solider may be using, but when on this person in a given situation, this smart phone and the app may be a security threat. Understanding the risk directs much of the development and testing efforts. IEEE 1012 defines integrity levels that can be used to determine the nature of verification and validation and/or testing. ISO29119 uses risk-based testing to determine test plans, design, levels, and techniques. Basically, more risk in the security or quality areas would mean more testing should be done.
Currently, many mobile and some embedded software systems opt for “no security risk.” This may mean no or minimal testing. However, the use of such software in different operational uses (i.e., networked) can mean more testing is needed. Further, the use and incorporation of non-developed (off-the-shelf) software may introduce the risk of counterfeit software parts. When risk analysis indicates security concerns, rigorous verification and validation with attack-based testing are often indicated.
Attack-based Testing [2, 19,20,21]
A test attack is a pattern to approach testing based on common modes of failure seen over and over. Attacking software and systems is an attempt to demonstrate that they (hardware, software, and operations) do not meet requirements or functional and non-functional objectives. Attacks target errors as well as provide other valuable information to stakeholders. Because testers usually only run checks to verify that the system or software meets requirements, which is necessary, but not sufficient, test attacks should be practiced often. Pure requirements-based testing can miss large (egregious) errors and vulnerabilities that can be leveraged to allow access to a system.
Some may see test attacks as a negative. However, attacks can be viewed as a positive for security testing since these are the methods hackers are employing and if the efforts can stop any hacking, that could be considered as a positive as well as worthwhile. Using the information from an attack, developers can then improve the overall security of software or systems.
Mobile and embedded attacks were developed for errors determined from a historic industry taxonomy database . The attack patterns use classic test and security evaluation techniques. A taxonomy is a classification of error patterns. IEEE has offered research over the years that many security testers and hackers form mental models of system failures and then, learn patterns to find these commonly occurring errors. Attack patterns build on mental models to aide security testers in a particular domain, herein for mobile and embedded devices.
This article offers examples of mobile and embedded security attacks by name although the details are out of scope of this piece (see  for specific actions and details). These attack patterns are based on researched industry taxonomy, which was created over a large number of publicly reported security errors and flaws. Taxonomies and attack patterns will never be comprehensive or complete since the nature of systems and software is evolving and not every project makes public the details of their vulnerabilities much less how they are found. Readers should use Table 2 as an introduction then, continue their own research into taxonomies and attack patterns, which may fit their local mobile and embedded contexts.
Table 2 is a beginning for mobile and embedded security testers. Many of these attacks relate to traditional security testing concepts, but the examples cite specific concerns that mobile and embedded testers should consider. The security test world is a fast moving and ever changing area. Newer threats and error taxonomy patterns are emerging constantly. Mobile and embedded security testing projects must constantly research, learn, and improve to stay current with what hackers are doing and to understand future vulnerabilities.
The concepts and attacks in this paper should be viewed as a starting point for projects wishing to improve their secure software development approaches, given the current poor practices . Both doing and not doing these concepts can have impacts on the quality as well as on legal considerations. Mobile and embedded device use, features, and connections will continue to increase in the world and could mean that security threats will also increase. Security concerns impact all engineering domains e.g., system, hardware, software, and support areas such as testing. Mobile and embedded projects should be proactive during development using concepts such as attack-based testing to reduce many security vulnerabilities.
References and Notes
1. MSK McClure, Scambray, and Kurtz, “Hacking Exposed” McGraw Hill
2. JDH - J. Hagar “Software Test Attacks to Break Mobile and Embedded Devices”, CRC press, 2013
3. Smart Phone Market Growth, ABI research report , 2013
4. C. Miller & C. Valasek, “Adventures in Automotive Networks and Control Units”, web document
5. . Security threats on embedded consumer devices, OMTP tech report, 2009
6. J. Weiss, “Threats impacting the nation” Testimony before the subcommittee on oversight, investigations, and management, committee on homeland security, House of Representatives, US Government accounting office, Washington, D.C.
7. Coverity Scan 2010 Open Source Integrity Report for Android, see
8. McAfee, “McAfee Threat Report: 4th quarter 2012”, McAfee Labs Pub, Santa Clara, CA, 2012
9. M. Arapinis, L. Mancini, E. Ritter, M. Ryan, N. Golde, K Redon, and R. Borgaonkar, “New Privacy Issues in mobile telephony: Fix and Verification in computer and communications security”, ACM, vol/no: missing, pp 205-216, 2012
10. D. Bhasker, “4G LTE Security for Mobile Network Operators”, Cyber Security and Information Systems , Vol 1 No 4, pp 20-29
11. K Venkatasubramanian, E Vasserman, O. Sokolsky, and I Lee, “ Security and Interoperable Medical Device systems”, IEEE security and privacy, Vol 10, No 5, 2012
12. M. Merkow, and L Raghavan, “Secure and resilient software”, CRC press, 201212.
13. Agile software -
14. D Kleidermacher “Embedded Systems Security, Practical Methods for Safe and Secure Software and Systems Development” Newnes books, ISBN :9780123868879, 2012
15. R Mahmood, “A whitebox approach for automated security testing of android applications on the cloud”, 7th international workshop on automation of software test , 2012
16. Taz T. Daughtery, “Security systems through software reliability engineering”, Cyber Security and Information Systems, Vol 1, No 1, 2012
17. IEEE1012 Verification and Validation Plan, IEEE press, 2012
18. ISO/IEEE/IEC29119 Software Test Standard, IEEE/ISO press, 2013
19. W.J.W.Z. Chuanxiong Guo, “Smart phone attacks and defenses” Microsoft Research Pub
20. . J. Whittaker & H. Thompson “How to Break Software Security” Addison Wesley, 20049.
21. M.A. Mobarhan, M.A. Mobsrhan, and A. Shahbahrami, “Evaluation of security attacks on different mobile communication systems”, Canadian Journal on Network and Information Security, Vol 3, No 1 Aug 2012
22. J Viega and H. Thompson, “The state of embedded device security”, IEEE security and privacy, Vol 10, No 5, 2012
Jon Hagar is a senior systems-software engineer and testing consultant supporting software product integrity, verification, and validation with a specialization in mobile and embedded software systems. Jon is the lead editor/author on ISO 29119 Software Testing series of Standards, co-chair of the OMG UML Test Profile Standard model based test standard, and contributor to IEEE 1012 verification and validation plans.
« Previous Next »