This is the final post in a four-part series about secure software methodologies from Tangram Flex.
Almost all of today’s systems use some kind of software component. We’re talking about things as simple as a fitness tracker to huge, critical systems like military aircraft. Technology is changing by the minute and the machines around us are becoming more complex and sophisticated by the day, but one thing remains the same: security is critical.
This series introduced the theory of secure software: Secure software does what it’s supposed to do, and nothing else. It’s easy to explain this theory, but much more complicated to achieve. Correct by construction methods give us a great framework to get started. Writing functionally correct code for software components, hardening the interfaces between them, and implementing system-level security are measures for building truly secure systems.
At this point in the series, some experienced readers probably think Tangram Flex is peddling some kind of snake oil or writing with a lot of aspiration. The truth is, engineering is beginning to evolve- it’s not perfect, but we’re finally getting there.
If it’s so easy, why doesn’t everyone do it?
Many computer and systems engineering organizations have proposed constructive approaches to building secure software. The US Department of Defense has loudly trumpeted the need for acquisitions reform- there is a serious need for faster, safer ways to build and update systems. The demand for speed, however, has driven most major programs to develop software that is optimized for performance and cost, waiting until the very end to apply system-level security and reliability measures. As an engineering organization, most of us at Tangram Flex get this- we’ve been there, too. Traditionally we’ve all followed the processes of the Systems Engineering V. It’s probably not a surprise to anyone working on software-driven systems today that there is room for improvement.
Up until now, tools haven’t existed to execute a correct-by-construction, component-oriented vision for critical systems.
Really secure systems- think Defense, Nuclear Power, Medical- have paid the price by giving up speed and cost savings to achieve security.
Development tools for private sector end-user software have focused on decreasing time-to-market, often overlooking basic security needs. The customers of both kinds of software are pushing movement to the middle. They want faster, cheaper, and more secure systems across the board.
There’s an app for that
The DoD has made speed and costs reduction efforts a priority, while the private sector has been spurred by high profile breaches to dramatically increase security throughout their systems. These competing priorities have led to new types of tools in multiple key areas:
- Model-based tools are being that blend systems engineering, security engineering, and software development capabilities that are relevant to software components. These tools are the opposite of traditional tools that were built to produce high-level architecture views exclusively for systems engineers.
- Advances in component assurance tools and cloud-based execution have enabled code to be analyzed in near real-time, at scale. This allows code to be checked in the flow of work, rather by a security expert later.
- Interface generation tools are rapidly maturing. Interfaces can be optimized fast enough that connecting components is no longer the bottleneck of integration. Tools exist now that automatically create secure “glue code” between components using white-listed parameters. Breakthroughs in mathematical transforms have made this process more efficient and repeatable.
- Now for a little buzzword bingo… Advances in cloud computing, containerization, orchestration and collaboration (bingo!) have enabled rapid synchronization of engineering activities. The authoritative source of truth no longer lives a local hard drive, but instead is cloud-native… accessible anywhere anytime by authorized users.
A lot of fundamental work has been completed, but as with any good software, execution is everything. The tools we have today require a lot of domain expertise, training, and handholding. Many assurance and interface generation tools are awesome but pretty difficult for an average engineer to use. Niche command line tools don’t provide the type of user experience that a developer would actually choose to use. In addition, systems-level assurance reasoning is still in its infancy with hurdles to overcome.
Even with these challenges, we are at the forefront of a secure software paradigm shift. We have a strong foundation and it will only get better from here.
Our entire team at Tangram Flex is immersed in navigating the transition to component-based engineering.
We would love to hear your opinions about this series, especially about your experiences in the journey of better software. Find us on LinkedIn, Twitter, or send us a note: firstname.lastname@example.org.
Adapted from a paper written by Don Barrett, Systems Engineer at Tangram Flex
Edited by Liz Grauel, Technical Writer at Tangram Flex