Back
The Evolution of Security Frameworks and Key Factors that Affect Software Development
In a recent episode of Agent of Influence, I talked with Cassio Goldschmidt, Head of Information Security at ServiceTitan about the evolution of security frameworks used to develop software, including key factors that may affect one company’s approach to building software versus another. Cassio is an internationally recognized information security leader with a strong background in both product and program level security.
I wanted to share some of his insights in a blog post, but you can also listen to our interview here, on Spotify, Apple Music or wherever you listen to podcasts.
Key Considerations When Developing Software
As Goldschmidt noted, one of the first security frameworks that was highly publicized was Microsoft STL, and a lot of security practitioners thought it was the way to develop software, and it was a one size fits all type of environment. But that is definitely not the case.
Goldschmidt said that when SAFECode (Software Assurance Forum for Excellence and Code), a not for profit was created, it was a place to discuss how to develop secure code and what the development lifecycle should be among those companies and at large. But – different types of software and environments require different approaches, and will be affected by a variety of factors at each business, including:
- Type of Application: Developing an application that is internet facing or just internet connected, or software for ATM machines, will influence the kind of defense mechanisms you need and how you should actually think about the code you’re developing.
- Compliance Rules: If your organization has to abide by specific compliance obligations, such as PCI, for example, they will in some ways dictate what you have to do. Like it or not, you will need to follow some steps, including looking at the OWASP Top 10 and make sure you are free of any cross-site scripting or SQL injections.
- The Platform: The architecture for phones and the security controls you have for memory management are very different from a PC, or what you have in the data center, where people will not be able to actually reverse engineer things. It’s something you have to take into consideration when you are deciding how you are going to review your code and the risk that it represents.
- Programming Language: Still today a lot of software is developed using C++. Depending on the language you use, you may not have the proper support for cross site scripting, so you have to actually make sure that you’re doing something to compensate for the flaws of the language.
- Risk Profile: Each business has its own risk profile and the kind of attacks they are willing to endure. For example, DDoS could be a big problem for some companies versus others, and for some companies, even if they have a data breach, it might not matter as much as for other companies depending on the type of business. For example, if you’re in the TV streaming business and a single episode of Game of Thrones leaks, it likely won’t have a big impact, but if you’re in the movie business and one of your movies leaks, then that will likely affect revenue for that movie.
- Budget: Microsoft, Google, and other companies with large budgets have employee positions that don’t exist anywhere else. For example, when Goldschmidt was at Symantec, they had a threat research lab, which is a luxury. Start-ups and many other companies might not have this and might need to use augmented security options.
- Company Culture: The maturity of the culture of the company also matters quite a bit as well. Security is not just a one stop activity that you can do at a given time, but something that ends up becoming part of your culture.
Today, there are a lot of tools and resources in the market such as Agile Security by O’Reilly that will tell you how to do things in a way that really fit the new models that people are using for developing code.
Security Software Versus Software Security
Security software is the software used to defend your computer, such as antivirus, firewalls, IDS, and IPS. These are really important, but that doesn’t mean they are necessarily secure software or that they were actually developed with defense programming in mind. Meanwhile, secure software is software developed to resist malicious attacks.
Goldschmidt said he often hears that people who make security software don’t necessarily make secure software. In his experience though, security software is so heavily scrutinized that it eventually becomes secure software. For example, antivirus software is a great target for hackers because if an attacker can get in and disable that antivirus, they can ultimately control the system. So, from his experience, security software does tend to become more secure, although it’s not necessarily true all the time.
One inherent benefit I’ve noticed for companies developing security software is that they’re in the business of security, so the engineers and developers they’re hiring are already very savvy when it comes to understanding security implications. Thus, they tend to focus on making sure at least some of the most common and basic issues are covered by default, and they’re not going to fall prey to basic issues.
If an individual doesn’t have this experience when they join a company developing security software, it becomes part of their exposure and experience since they are spending so much time learning about viruses, malware, vulnerabilities, and more. They inherently learn this as part of their day to day – it’s almost osmosis from being around other developers who are constantly thinking about it.
One of my mentors described the difference between security software and secure software to me this way: Security software is software that’s going to protect you as the end user from getting breached. Software security is making sure that your developers are developing the software in a manner that the software is going to behave when an attacker is trying to make it misbehave.
Goldschmidt and I also spent time discussing the cyber security of the Brazilian elections. You can listen to the podcast here to learn more.
