How to build a successful application security program

[Guest Emma Jones]

The security community is continuously changing, growing, and learning from each other to better position the world against cyber threats. In the latest Voice of the Community blog series post, Microsoft Product Marketing Manager Natalia Godyla talks with Tanya Janca, Founder of We Hack Purple Academy and author of the best-selling book “Alice and Bob Learn Application Security.” Previously, Tanya shared her perspectives on the role of application security (AppSec) and the challenges facing AppSec professionals. In this blog, Tanya shares how to build an AppSec program, find security champions, and measure its success.

 

Natalia: When you’re building an AppSec program, what are the objectives and requirements?

 

Tanya: This is sort of a trick question because the way I do it is based on what’s already there and what they want to achieve. For Canada, I did antiterrorism activities, and you better believe that was the strictest security program that any human has ever seen. If I’m working with a company that sells scented soap on the internet, the level of security that they require is very different, their budget is different, and the importance of what they’re protecting is different. I try to figure out what the company’s risks are and what their tolerance is for change. For instance, I’ve been called into a lot of banks and they want the security to be tight, but they’re change-adverse. I find out what matters to them and try to bring their eyes to what should matter to them.

 

I also usually ask for all scan results. Even if they have almost no AppSec program, usually people have been doing scanning or they’ve had a penetration test. I look at all of it and I look at the top three things and I say, “OK, let’s just obliterate those top three things,” because quite often the top two or three are 40 to 60 percent of their vulnerabilities. First, I stop all the bleeding, and then I create processes and security awareness for developers. We’re going to have a secure coding day and deep dive into each one of these things. I’m going to spend quality time with the people who review all the pull requests so they can look for the top three and start setting specific, measurable goals.

 

It’s really important to get the developers to help you. When you have a secure coding training, a bunch of developers will self-identify as the security developer. There will be one person who asks multiple questions. We’re going to get that person’s email. They’re our new friend. We’re going to buy that person some books and encourage open communication because that person is going to be our security champion. Eventually, many of my clients start security champion programs and that’s even better because then you have a team of developers—hopefully one per team—that are helping you bring things to their team’s attention.

 

Natalia: What are some of the key performance indicators (KPIs) for measuring security posture?

 

Tanya: As application security professionals, we want to minimize the risk of scary apps and then try to bring everything across the board up to a higher security posture. Each organization sets that differently. For an application security program, I would measure that every app receives security attention in every phase of the software development life cycle. For a program, I take inventory of all their apps and APIs. Inventories are a difficult problem in application security; it’s the toughest problem that our field has not solved.

 

Once you have an inventory, you want to figure out if you can do a quick dynamic application security testing (DAST) scan on everything. You will see it light up like a Christmas tree on some, and on others, it found a couple of lows. It’s not perfect, but it’s what you can do in 30 days. You can scan a whole bunch of things quickly and see OK, so these things are terrifying, these things look OK. Now, let’s concentrate on the terrifying things and make them a little less scary.

 

Natalia: Do you have any best practices for threat modeling cloud security?

 

Tanya: For threat modeling generally, I introduce it as a hangout session with a security person and try not to be too formal the first time, because developers usually think, “What is she doing here? Danger, Will Robinson, danger. The security person wants to spend time with us. What have we done wrong?” I say, “I wanted to talk about your app and see if there’s any helpful advice I can offer.” Then, I start asking questions like, “If you were going to hack your app, how would you do it?”

 

I like the STRIDE methodology, where each of the letters represents a different thing that you need to worry about happening to your apps. Specifically, spoofing, tampering, repudiation, information disclosure, denial of service (DOS), and elevation of privilege. Could someone pretend to be someone else? Could someone pretend to be you? I go through it slowly in a conversational manner because that app is their baby, and I don’t want them to feel like I’m attacking their baby. Eventually, I teach them STRIDE so they can think about these things. Then, we come up with a plan and I say, “OK, I’m going to write up these notes and email them to you.” Writing the notes means you can assign tasks to people.

 

With threat modeling in the cloud, you must ask more questions, especially if your organization has had previous problems. You want to ask about those because there will be patterns. The biggest issue with the cloud is that we didn’t give them enough education. When we’re bringing them to the cloud, we need to teach them what we expect from them, and then we’ll get it. If we don’t, there’s a high likelihood we won’t get it.

 

Natalia: How can security professionals convince decision-makers to invest in AppSec?

 

Tanya: I have a bunch of tricks. The first one is to give presentations on AppSec. I would do lunch and learns. For instance, I sent out an email once to developers: “I’m going to break into a bank at lunch. Who wants to come watch?” and then I showed them this demo of a fake bank. I explained what SQL injection was and I explained how I’d found that vulnerability in one of our apps and what could happen if we didn’t fix it. And they said, “Woah!” Or I’d ask, “Who wants to learn how to hack apps?” and then I showed them a DAST tool. I kept showing them stuff and they started becoming more interested.

 

Then, I had to interest the developer managers and upper management. Some were still not on board because this was their first AppSec program and my first AppSec program. No one would do what I said, and I had all these penetration test results from a third party, and we had hired four different security assessors and they’d reported big issues that needed to be addressed.

 

So, I came up with a document called the risk sign-off sheet, which listed all the security risks and exactly what could happen to the business. I was extremely specific about what worried me. I printed it and I had a sign-off for the Director of Security for the whole building and the Chief Information Officer of the entire organization. I went to them and said, “I need your signature that you accept this risk on behalf of your organization.” I put a little note on the risk sign-off sheet that read: Please sign.

 

The Director of Security called and said, “What is this, Tanya?” and I told him, “No one will fix these things and I don’t have the authority to accept this risk on behalf of the organization. Only you do. I don’t have the authority to make these people fix these things. Only you do. I need you to sign to prove that you were aware of the risks. When we’re in the news, I need to know who’s at fault.” Both the CIO and the Director of Security refused to sign, and I said, “Then you have to give me the authority. I can’t have the responsibility and not have the authority” and it worked. I’ve used it twice at work and it worked.

 

It’s also important to explain to them using words they understand. The Head of Security, who is in charge of physical security and IT security, was a brilliant man but he didn’t know AppSec. When I explained that because of this vulnerability you can do this with the app, and this is what can result for our customers, he said, “Oh, let’s do something.” I had to learn how to communicate a lot better to do well at AppSec because as a developer, I would just speak developer to other developers.

 

Learn more

 

• Elevate your security posture with Microsoft Cloud App Security, Microsoft’s Cloud Access Security Broker.
  
• Learn about Microsoft’s Cloud Security approach.
  
• Get started with Azure Security Center.
  

 

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.

 

The post How to build a successful application security program appeared first on Microsoft Security.

 

Continue reading...