In a day and age when the prime directive for many organizations is to seek digital agility above all else, cool new apps get conceived, assembled and deployed at breakneck speed.
Related: DHS instigates 60-day cybersecurity sprints
Software developers are king of the hill; they are the deeply-committed disciples pursuing wide open, highly dynamic creative processes set forth in the gospels of DevOps and CI/CD.
In this heady environment, the idea of attempting to infuse a dollop of security into new software products — from inception — seems almost quaint. I recently sat down with Rohit Sethi, CEO of Security Compass, to discuss why this so-called “product security” gap inevitably must be narrowed, and why there are encouraging signs that should be what happens, going forward, albeit incrementally.
For a full drill down on our wide-ranging conversation, please give the accompanying podcast a listen. Here are key takeaways.
History of product security
It has become all too common today for an organization to commit to what Sethi calls a “fast-and-risky” approach to building new software products. In a race gain a competitive edge, companies do whatever it takes to deploy new software products as quickly as possible. As a nod to security, nominal static analysis and maybe a bit of penetration testing gets done just prior to meeting a tight deployment deadline.
This, in fact, was the same general approach to developing and deploying new software that existed in early 2002 when Bill Gates slammed the brakes on all Windows development to focus on implementing Trustworthy Computing. Microsoft, at the time, was on the brink of getting swallowed up by potent self-spreading Windows worms like SirCam, Code Red, ILoveYou and Nimbda. So Gates directed billions of dollars towards the adoption of Security Development Lifecyle, or SDL, a systematic approach to infusing product security at the start of the Windows development process.
Gates deserves credit for raising the bar of product security. Since he coined Trustworthy Computing and Microsoft strategically embraced SDL, it has become a common practice to integrate security requirements, design reviews and threat modeling into the software development cycle. But now, of course, digital transformation has changed everything.
“Those methods are becoming outdated,” Sethi told me. “They just can’t keep up with the way that people build software today. People build very quickly, and then they ship it out. And right before shipping, they’ll do a bunch of security checks . . . They may or may not fix anything they find, because their deadlines are tight. This works well until there’s a breach, and then you have to go back and explain why you never integrated security from the onset of development.”
11th hour inspections
Digital transformation has turned back the clock on product security. And this time around, the coding flaws of concern aren’t limited to one operating system; the risks present themselves all throughout the digital landscape, wherever software connections get made between humans and machines, as well as from machine-to-machine.
Product security has become a numbers game. A typical situation is for an enterprise to have a small team of product security professionals working on several hundred software products in different stages of development, Sethi says. Ideally, a certain level of threat modeling and security requirements would get done on every project. But in practice, the developers are doing well if they get to the most critical ones, Sethi says. After that, it comes down to slipping in a round of eleventh-hour inspections: static analyses, and perhaps a bit of penetration testing just prior to meeting a deployment deadline.
Observes Sethi: “Threat modeling is quite time-consuming and requires a lot of expertise, so not everybody even does this. It requires, for example, drawing out the trust boundaries within the architecture of the application to gain an understanding of where trusted and untrusted data is coming in, and then determining if there are any ways to attack the system, such as spoofing or tampering data.
“It’s not uncommon to have a team of six or eight people assigned to a thousand applications, so there’s no way they can do threat modeling on all of them. So they prioritize and work on the crown jewels, and rely on tools to find any security vulnerabilities after the fact.”
In today’s environment, implementing Microsoft-style SDL best coding practices, done manually by a small team, could add weeks to the deployment schedule. SDL practices may run counter to frameworks like CI/CD, which stands for Continuous Integration/Continuous Deployment. Software developers today work as swiftly as they can on small chunks of coding, or microservices, cobbled together inside of software containers, which they place into a code repository, such as GitHub.
This gives other developers easy access to many chunks of coding. Developers are free to modify, add to or utilize endless small chunks, and out of the other end comes a new app that gets deployed into service, with no human intervention.
Returning to security-by-design
The cybersecurity community isn’t blind to how DevOps – the melding of development and operations teams to speed delivery of new apps – and its core CI/CD component have vastly expanded the attack surface of business networks. Modern-day software development produces vast swaths of new microservices, and the software containers the sit in, that do not adhere to very basic secure-coding practices.
Can anything reverse this trend, going forward? The steady advance of the SecOps and DevSecOps movements – which push security to the left of software development timelines –hold promise narrowing the product security gap over time. Security Compass is among a group of vendors innovating new tools and services to bring machine learning and advanced automation increasingly into this mix.
Sethi
Security Compass, for instance, supplies a platform that allows development teams to manually or automatically describe the system they are building; this specifies what the application is and what functionalities it includes. This information gets automatically correlated to a comprehensive knowledge base of potential security and compliance issues, which triggers creation of corresponding countermeasures and controls that are added automatically to product backlogs. Thus, automation helps to weave security-by-design best practices into daily workflows. The company coined the market term Balanced Development Automation for this approach to DevSecOps.
Again it’s a numbers game. “No one is claiming you can write 100 percent secure code,” Sethi told me. “But if 80 to 90 percent of the security vulnerabilities we see getting exploited are preventable, which I believe they are, and if you could get to even half of that, then you’d have almost half as many breaches, and that represents billions of dollars of economic value.”
Clearly, striving for software that’s secure by design, as well as highly agile, is doable and something that needs to get done, the sooner the better. I’ll keep watch and keep reporting.
Acohido
Pulitzer Prize-winning business journalist Byron V. Acohido is dedicated to fostering public awareness about how to make the Internet as private and secure as it ought to be.