Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.
Shaping A Better Future For Software Security
Industry and government leaders discuss ways to improve practices, awareness and education around secure software development. Here’s a recap of what you missed.
5 Min Read
I had the awesome privilege recently to participate in an exploratory working group (EWG) designed to help shape the future of software security and assurance and focused on accelerating the adoption of new practices to deliver software resiliency for today’s cyber-driven world. As we have seen with many notable security breaches and incidents, poorly developed software plays a significant role in exposing key vulnerabilities exploited by threat actors.
The net effect is that vulnerable software poses a significant threat to this nation. As we rely more and more on software, the impact of security breaches and incidents will continue to rise.
The goal and vision for EWG is to "create a very succinct and concrete plan of real-world actions that are executable today for a more resilient software world.” The group consisted of invited representatives from Parasoft, Cigital, Amazon Web Services, Google, Bug Crowd, Veracode, Microsoft, Aetna, Heartland Payment Systems, the Software Assurance Marketplace (SWAMP), Kestrel Technologies, Data Theorem, Elavon, Secure Decisions, and the Open Crytpo Audit Project. There were also several universities represented: University of Maryland, Carnegie Mellon, University of Nebraska-Omaha, University of Wisconsin, and the George Mason University.
There were four working group sessions led by industry experts:
Gaps in Assurance Tool Technologies, Bart Miller, Chief Scientist for the SWAMP
Capability gaps: What are the most urgent problems that current tools are not finding?
Language gaps: What languages and environments are not well covered by current tools?
Usability gaps: What obstacles make current tools unnecessarily difficult to use?
SWAMP Certificates: Labeling Software with Assurance Levels to Improve the Software Supply Chain, Mark Sherman, Director at Software Engineering Institute (SEI)
Could SWAMP be an Underwriter's Laboratory and issue a "UL" label? What would need to go into such a label? Could SWAMP check enough to at least shame the worst stuff? How could the labels be popularized so that there is consumer demand (or a financial distinction) for such labels?
What kinds of technical assistance can provide assurance of software components used by their consumers? How can the use of open-source components be assured? What practices can be implemented to limit the risk of insider threats in the software supply chain?
A more orthogonal encyclopedia of software weaknesses than Common Weakness Enumeration (CWE), Paul Black, Computer Scientist at National Institute of Standards and Technology (NIST)
CWEs were a great advance for their day. We now understand that the classes of weaknesses tools report don't match well with CWEs. Tools must extensively over- or under-generalize. And attacks are scarcely integrated into CWEs. A general nomenclature or systematic way to describe software weaknesses could be based on chains and composites, Software Fault Patterns, and Semantic Templates. Tool builders could clearly explain to users what their tool catches (and what it doesn't).
Mobility App Security Threats, Sam Malek, PhD, George Mason University
What kinds of security threats are posed by mobile apps and app markets?
What tools and techniques currently exist for vetting mobile apps and reducing the security risks?
What are the promising areas of future research and development?
Talking points
In trying to understand why software developers are not using software assurance tools, one participated noted, "If the tools are so great, why aren’t more developers using them?”
There was a discussion on having a human process implemented as part of automation in software development to help interpret and prioritize security weaknesses identified in software. For organizations it’s important to understand what defects or weakness classes matters the most.
Incorporating safety-type checks into the software assessment process, similar to the way a seatbelt in a car is inspected to ensure it’s working as intended.
Rethinking the way in which software development is being taught, with an increased focus on secure coding. Figuring out ways to incorporate new advancements and discoveries back into the learning process.
Incentivizing quality and security as part of the software development process. Can organizations get economic value for developing secure code?
Building culture in organizations to formalize software assurance as part of the software development process. Finding ways to make secure easy, and insecure the obvious.
Is it easier to teach security to developers, than to teach security professionals how to be developers? Many organizations are starting to evaluate the benefits of hiring developers within their security organizations.
Overall, I thought the initial meeting was successful; it helped confirm the need to keep software security assurance at the center of cyber security conversations. I want to share with you some of my key takeaways:
The gaps in software assurance tools are understated; the tools are not as good as perceived. As a result, many software developers don’t have confidence in using software assurance tools. This leads to more security weaknesses in software during maintenance phases. Improving software assurance tools for early adoption is important to increase confidence in using them.
There is a growing dependency on open-source software. Consequently, focusing on how to validate, verify, and assess software as part of the software supply chain is critical to determine risks in third-party software.
The idea of incentivizing secure software development activities seems like a realistic outcome, or a practice that many organizations can put in place to help improve the overall quality and security of software. This will help make secure easier, and insecure the obvious (Thanks, Casey Ellis.)
If you teach coding, you have to teach and enforce good coding practices. Teaching kids and students how to code is an excellent idea, but teaching them the quality and security aspects of coding is even more important. Many computer scientists believe you must teach how to design a secure system prior to teaching someone how to code.
The next EWG is tentatively scheduled for October. As part of this session, the group would like to get more industry engagement from open-source developers, security researchers, and executives and stakeholders responsible for security within their organizations. If you are interested in participating, please contact me or share your thoughts in the comments.
About the Author
You May Also Like
More Insights
