Thought Leadership Series: What keeps an AppSec CTO up at night?

by Contributed | Sep 15, 2022 | Technology

This article is contributed. See the original author and article here.

The security community is continuously changing, growing, and learning from each other to better position the world against cyber threats. In the latest post of our Community Voices blog series, Microsoft Senior Product Marketing Manager Brooke Lynn Weenig talks with Chris Wysopal, Co-Founder and Chief Technology Officer of Veracode. The thoughts below reflect Chris’s views, not the views of Chris’s employer, and are not legal advice. In this blog post, Chris talks about app security.

Brooke: How did you get into app security?

Chris: I started playing with computers around 10 or 12 and in high school in the pre-Internet days. I would dial-up bulletin board systems and find forbidden information that you could not find in the library. I wanted to learn how to program computers. What really got me thinking about cybersecurity was finding these underground bulletin boards and seeing people talk about breaking into systems. It was in the back of my mind as I went to college and learned to be a programmer. It drove me to take my programming skills and use them for building cybersecurity tools and helping people build secure applications.

Before Veracode, I was doing security consulting, whether a company needed someone to help design a secure network or authentication system or do forensics work or incident response work. This new field of app security was emerging with the Internet. Banks, for instance, were building web applications and saying, “We do not have anyone who can help us make sure this is secure.” Emerging attacks, like SQL injection and cross-site scripting, were coming out. We were coming up with techniques to help them find those attacks. I had a development background and knew how to write and inspect code. Combining the development background with cybersecurity seemed like a great way to do something unique.

Brooke: What are microservices and why are they on the rise?

Chris: Microservices are a new way of doing more agile development. Instead of building big, monolithic applications, where 10 scrum teams are all working together on one big application, why not have those 10 scrum teams each work on a small piece of an application that has an API and does one function, like authentication or report generation?

It allows a small scrum team of seven or eight people to write, test, and deploy their own code. It is a much more reliable and efficient way to put small pieces of code into production and allows you to reuse those services across many different applications. Customers will have a couple dozen microservices and they will build dozens of applications out of those microservices. Also, API is now the way you interact with microservices, so API security becomes the main thing you’re trying to secure.

It is important to make sure each microservice takes care of its own security by using encryption and strong authentication. Each microservice has to be logging its activity and each one needs to be tested for security because they have attack surface that an attacker can interact with. Ultimately, it is more secure because you are securing a more well-defined service rather than a big, monolithic application.

Brooke: What are the biggest security threats and how can companies protect themselves?

Chris: One of the emerging big ones are vulnerabilities in open source components like the Apache Log4J exploit, which was a series of critical vulnerabilities discovered in December 2021. The way that organizations use open source is kind of a set it and forget it. Two, three, or four years later, a critical vulnerability comes out and they scramble. “Where am I using Log4J?” and everyone stops doing everything to respond. There should be a process where you stay up to date so when new vulnerabilities come out, you have a process for updating your open-source usage efficiently.

I recommend that people use software composition analysis as part of the development pipeline, so every time they build the code, they are looking at the open source and seeing if there have been any new vulnerabilities since they built their code. They can update those before they push it into production and keep their open source fresh and secure instead of letting it age and it becomes a crisis. There is the acronym SOAR – security, orchestration, automation, and remediation. You can bring that to code and do things in as automated a way as possible. Check every time you build to deploy the code. If you are a deploying daily, you are checking that daily. If it is monthly, you are checking it monthly.

Brooke: Will there be more automation and teaching machines to secure our code?

Chris: There was a presentation at Black Hat on GitHub’s Copilot, an AI pair programmer for developers, and it does a good job of writing code for developers. Of course, it learns how to do that from other code, and we know other code has vulnerabilities. These researchers found cases where Copilot was suggesting code that had vulnerabilities.

Even if you are using something like Copilot, you have to do security testing. It is not guaranteed that it gives you secure code, but on the other hand, if we have this other process of auto-remediation, maybe Copilot and auto-remediation can work together. Before it suggests the code, it can check it and make sure it is suggesting clean code. That just means that the two machines have to talk to each other first.

I do not want to make you think that we can fix every single vulnerability in an automated way, but if we can fix even half of them, that saves a huge amount of time.

Brooke: How do you help clients define their security control goals?

Chris: Different organizations are at different maturity levels. Some organizations don’t know how many applications they have, how many they’ve built, or where they are because they’re just starting out. A lot of it is what we call attack surface discovery, where you are discovering those web apps and APIs that you have exposed, or you’re going through your code repos and looking at all the different applications you’ve built.

The next step is prioritizing your applications because you don’t want to spend a lot of time on old legacy application that are going away in a few months or in a year versus the brand-new line-of-business application you just started using that you know will last for 10 years. Then, look at your open-source vulnerabilities because those are in the National Vulnerability Database that everyone can read. Take a big prioritization approach and cut out things that you are not going to fix, whittling it down to just the most important applications and vulnerabilities. Automate that vulnerability finding process as much as possible.

Brooke: How can IT and security teams work together to solve vulnerabilities faster?

Chris: That’s a big question I get all the time because people struggle to get these two teams to work together. Traditionally, they have done their thing off on their own. The development team develops stuff. The security team looks at all kinds of assets, like what the organization has purchased versus built, and tries to secure those things themselves.

With ongoing development of a new application or an application that you’re constantly updating, those teams have to build a working relationship. The best way to do that is for people on each team to meet on a regular basis so each team understands the challenges, struggles, and priorities of the other team. You have to break out of the silos and meet on a regular basis – weekly is good – and then, you can do some cross-pollination.

At Veracode, we have the concept of security champions, where developers work alongside the application security experts and learn things like threat modeling or manual penetration testing. Find people who think this is fun and cool, and it may be a new career for them. Get people to volunteer, if possible, but also get people from the security team working alongside the developers and saying,” I will help configure your build pipeline and integrate security testing into your pipeline for you.” Those types of things go a long way in getting the teams to really work together.

Brooke: What is needed to close the app security talent gap?

Chris: A lot of security can be picked up either on the job or in a boot camp-type environment. I’ve been talking to community colleges in Massachusetts, where Veracode is headquartered, about having certificate programs where people can learn how to run a vulnerability scan and how to work in a SOC, like where to look at a malware alert that’s coming from someone’s laptop or at a suspicious phishing test.

We should have more boot camps and more certificate programs at community colleges, so that people don’t have to go to school for four years to do this or to switch careers. They can do this on the side and see if they like it. On the demand side, companies have to be willing to take on interns and people doing this as their first job. We have intern programs at Veracode, and they’ve been very successful. We’ve hired a lot of people that way.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

Released: Microsoft.Data.SqlClient 4.1.1

by Contributed | Sep 14, 2022 | Technology

This article is contributed. See the original author and article here.

We have released an update to Microsoft.Data.SqlClient, version 4.1.1. The update addresses several issues that are important to our customers.

Updates in Microsoft.Data.SqlClient 4.1.1 include:

Fixed

• Fixed connection failure by not requiring Certificate Revocation List (CRL) check during authentication. #1706


• Parallelized SSRP requests on Linux and macOS when MultiSubNetFailover is specified. #1708, #1746


• Added CommandText length validation when using stored procedure command types. #1709


• Fixed NullReferenceException during Azure Active Directory authentication. #1710


• Fixed null SqlBinary as rowversion. #1712


• Fixed table’s collation overriding with default UTF8 collation. #1749

Changed

• Updated Microsoft.Data.SqlClient.SNI (.NET Framework dependency) and Microsoft.Data.SqlClient.SNI.runtime (.NET Core/Standard dependency) version to v4.0.1 #1755, which includes the fix for AppDomain crash introducing in issue #1418


• Code improvements: #1711

To get the new package, add a NuGet reference to Microsoft.Data.SqlClient in your application.

For the list of changes in Microsoft.Data.SqlClient 4.1.1, you can also see the Release Notes.

If you encounter any issues or have any feedback, head over to the SqlClient GitHub repository and submit an issue.

David Engel