Design Talk: March 2010
Security-Critical Software Development Process and Tools
By John Greenland, VP Business Development, LDRA Technology, Inc.
Security now dominates the forefront of industries as varied as defense, finance, and energy, and transportation. Software developed for these markets must ensure that it meets new levels of assurance.
In adherence to the MILS (Multiple Independent Levels of Security) specification, software components are separated from each other to ensure that failure or breach of one component does not jeopardize the system. And, in complying with the Common Criteria for Information Technology Security Evaluation, software must prove that it meets specified security requirements and properties from the lowest levels of security (unclassified) to the highest (top secret).
The Common Criteria specifies that software must meet certain software development process requirements and adhere to a set of programming standards, software verification activities, and traceability from high- to low-level design requirements down to the resulting source and object code. Current software tools provide code analysis that enables programming standards compliance and detailed source code documentation by providing the following evaluations:
Structural coverage analysis—establishes a correlation between requirements that are tested and code structures exercised by the test to document that the code running on the host or target system meets stated requirements. It ensures that the code structure is verified to the correct security level and can confirm the absence of unintended functions. It also traces requirements through both source code (static analysis) and execution of object code (runtime analysis).
Control coupling—graphically represents the dependence of a software component on the components that call it or are called by it. This information can be mapped to the source code to demonstrate the control flow of code under test. This also illustrates the degree to which an identified control coupling is exercised at run time.
Data coupling—provides all instances a data item is accessed by a software component, tracking and reporting these instances across procedure and file boundaries, even when they are aliased as parameters to procedure calls. Dynamic data flow coverage indicates which data components are accessed at run time to provide an execution trace for a specific test data set.
Requirements traceability—proves the correctness of requirements-based development and verification by assuring that software requirements are properly associated with the requisite test cases and can be traced from their highest level through the design to final implementation and deployment on the target system (Figure 1). Tool suites integrating requirements coverage with code review, data and control coupling and code coverage tools offer the best possible support for Common Criteria certification.
Testing and structural code coverage measurement—offers coverage metrics identifying code not executed at runtime. It quickly identifies missing or inadequate test data via textual and graphical reports.
Conclusion
Security-related development requires adherence to MILS and the Common Criteria processes. Automated tools offering static and dynamic analysis, test and requirements traceability ensure companies can meet certification measures without taxing resource requirements, excessive cost and schedule risk. Without leveraging these tools and processes, security-related development and verification is a much more onerous task.
John Greenland is currently serving as VP Business Development for LDRA Technology, Inc., where he is responsible for certain sales areas, partnerships, and new market development. He possesses over 20 years experience in the embedded software development tools industry, working in various technical, sales, and marketing roles.
| There's so much more to electronics design than the electronics By Rob Evans, Technical Editor, Altium Limited, rob.evans@altium.com [1] At the fundamental and certainly traditional level, electronics design is about assembling and connecting electronic components together to achieve the intended, functional result. It’s a workable view that has loosely fitted the process of electronics design since its inception – even when you take into account the more ethereal concepts of embedded systems and software-defined functionality. What’s significant about that conventional view of electronics product design is that it’s inherently centered on the elements inside the box. So the factors we consider when creating a product design that differentiates itself amongst others tend to be constrained inside that tight electronic sphere. In practice we might seek a market advantage by making the circuitry perform faster, offer more features, or even implement new component technology that will lower the product’s street price. The tendency is, understandably, to offer new or improved product designs that are defined by an electronics-centric view. But customers who might buy that product really don’t care about the unique way the electronics parts have been combined or how fiendishly clever the software is. What they increasingly care about is the unique and useful user experience a product delivers, outside the box. Today, this experience involves how a product interacts with the user and its own physical surroundings, what systems and networks it can interact with, and the beneficial services it can hook in to. From the overall design perspective, creating that desirable customer experience is the really tricky bit, and involves much more than a traditional process of electronics design. Standing in the customer’s shoes, or applying design empathy, is one place to start. We need to create interfaces and connection systems that make sense to non-technical users, enclosure designs and user controls that work ergonomically. We need to avoid the response, “Oh dear, looks like this interface was designed by an engineer." Perhaps above all though, we need to look beyond the device itself to create a whole customer experience that’s unique, valuable to the user and provides a sustainable point of differentiation in the market. That experience is increasingly being defined by externally connected systems, both within the user’s own environment (PCs and local networks) and to the wider internet structure (company servers and web-based services). The connectivity benefits of this approach to product design are not just confined to consumer products. Industrial, medical, military and automotive teams can all gain commercial advantage, and establish sustainable relationships with their customers, by thinking about design beyond the box of electronics hardware under development. The value this adds to the user experience, and therefore a product’s competitive advantage, is huge. And the future potential is even greater. Our designs also need to consider systems that support the rising demand for intelligent, interconnected electronic products that can independently operate in an internet-based device mesh – products that act as free nodes in the internet cloud. Creating an electronic design that will operate in this ecosystem involves more than just the electronics that enable connectivity (the hardware and software layers). It requires the development of intelligent systems, within the product and at a company level, that deliver the functionality and user experience customers are seeking. But it also means expanding our view of electronic product design beyond the device itself, to one that encompasses all of the factors that define the next generation of electronic products. |
Intellectual Property Protection
Maintaining all of this information about your product will enable you to have peace of mind knowing that you can quickly and effectively change suppliers if there are pricing or quality issues. A quality design firm, consultant, or manufacturing partner will have no problems turning any of this information over to you at the conclusion of development or at production start-up, but it should be discussed as part of the negotiations and included in a final contract. If a programmer refuses to supply source code, or a design firm refuses to give the native CAD data it should set off some alarms. |
The classic concern about outsourcing is that you will wake up one morning to find out that counterfeit versions of your products are being sold by a shady offshore firm. The reality is that this scenario is extremely rare. Most off-shore manufacturers are focused on contract manufacturing and have no interest in destroying their reputation by engaging in this type of activity. Designing Multi-Touch Products That Are More User-Centric |
With the fast-growing popularity of multi-touch functionality in a wide variety of consumer electronics and professional products, not enough attention is being paid to the actual needs of the end user. Product planners, designers, and third-party integrators of multi-touch technology need to strike the right balance between look-and-feel and usability – to find the right mixture of hardware and software; and, most importantly, to design their products for the user, not their own egos.