SFCS: We Talked to Security Strategist Jonathan Knudsen From Synopsys

For this edition of Stories From Cybersecurity, we talked to Jonathan Knudsen from Synopsys. Jonathan has worked in a variety of roles in cybersecurity including as a developer, consultant, and author. He also likes to break things! We asked Jonathan some questions to pick his brain on all things hacking and cybersecurity. He also has some useful advice for industry newcomers. Let's take a look. 

 

NANCY: How did you become a security strategist?

 

JONATHAN: “Security strategist” is a wonderful amalgam of my previous roles and experience. My university degree is in mechanical/aerospace engineering, but I started off working as a software developer and have been involved in software ever since. 

 

I was a technical writer for a while, and one of the books I enjoyed writing the most was about cryptography.

From there I learned more and more about software security, including a deep dive into TLS (Transport Layer Security). In 2011 I joined a little Finnish company called Codenomicon. Working as a systems engineer, I gained deep knowledge about secure development practices, particularly fuzz testing.

 

After Codenomicon was acquired by Synopsys, I got access to a broader set of security testing tools and learned even more about secure development methodology. In fall 2019 I started teaching a class at Duke University about the secure development life cycle and the processes and tools for minimizing risk.

 

NANCY: How do you expect our security strategies to evolve over the next decade?

 

JONATHAN: On the IT security side of things, we are right now witnessing the death of the perimeter. When people first started thinking about network security, we had this antiquated idea that we would circle the wagons or build a strong castle wall to protect all our trusted assets. It is a flawed analogy, as networks are too porous to make perimeter defenses highly effective. As an industry, we are just starting to move to zero trust architectures, in which we correctly recognize that assets and users inside the perimeter should not get any special trust.

 

In product security, over the next decade, we will see a dawning appreciation of the risks of building and using software. Right now we have this mentality that we can throw a couple of developers at a project, and they can use open source components for free, and you can build an application very inexpensively. That is like thinking that just because you can stack one rock on top of another, you will be able to build a beautiful cathedral.

 

The reality is that it takes more than just development skills to build software that is appropriately safe, secure, and robust. The secure development life cycle ensures that you consider security at every phase, that you are managing risk in your supply chain, and that your end product has minimal risk for you and your customers.

 

The main reason we are slow to adopt secure development practices is that it costs more in the short term but less in the long term. Over the next decade, I hope that all organizations will realize that the short term expense of building software right will more than pay for itself in terms of dramatically lowering risk in the long term.

 

NANCY: In your recent article, you said, "we need to change our thinking and our processes to build software right." Do you have any tips on how to do this?

 

JONATHAN: Start now. Take one small step to reduce your risk, then take another, and another. Many organizations are still missing fundamentals, things that are not hard to do but can make a big difference in risk. If you want to keep people from stealing things in your house, you lock your doors and windows when you’re not at home. Many organizations are leaving doors wide open, and many times they don’t even know how many doors they have.

 

Building software has always been focused on functionality, on making something that works. This mindset starts in university computer science programs, where assignments are graded based on fulfilling functional requirements. For some assignments, the goal is to pass a series of automated tests, which are again mostly about functionality. Once you get into the workplace, the process is similar, with developers working to pass tests based on functional requirements. Security is often forgotten, neglected, or clumsily tacked on to the end of the development process.

 

Building software right means that security is infused into the entire software life cycle, from design and architecture all the way through to maintenance and incident response. This is a shift from how organizations have been creating software. Change is always hard, but this is a change that must be made. We rely on software more and more. Attackers are becoming more and more capable. The only solution is to build software right using a secure development life cycle.

NANCY: Do you have any advice for aspiring security professionals?

 

JONATHAN: Learn, learn, and learn some more. Software security is a fascinating and complex field, with constant innovation from both attackers and defenders. Never hesitate to ask questions and always be willing to learn something new.

 

Share your enthusiasm. Organizations all over the world are creating security groups, but it’s important to realize that the security group is responsible for spreading a culture of security throughout the rest of the organization. You need technical skills to be a security professional, but you also need to be able to communicate outward, to help shepherd the organization towards higher awareness and lower risk.