OWASP AppSec Day, 2017

Attended the OWASP AppSec Day again this year (only for the single day, even though they had a course that ran for 2 days), since I had so much fun last year. It was really hard to choose between talks, there were so many interesting sounding ones.

I'l break break some of the talks down into their own posts, because otherwise this post will get too long, but I'll cove the panel at the end of the day. They did it last year, and it was really funny and interesting, so they decided to do it again this year.

The panelists (from the right):
Frenchie (MC): who works at Culture Amp (and doesn't sound French, though maybe he is)
Serge: who is an application security professional, currently working at Coles, and one of the founders of Bugcrowd.
Julian (the event organiser): an application security engineer at Seek
Bec (I think that was her name, she wasn't listed in the schedule): a pen tester (I wrote at Assurance, but I thought I remembered her saying CultureAmp as well). She is also one of the creators of Hackers Helping Hackers.
Pamela: pen tester who used to work for the London stock exchange. I went to her talk last year on software defined radio, which was amazing.

What is application security?
Among other things, it includes:

• pen testing: web and mobile
• defensive techniques: protecting against attackers

The development world is shifting, and it's hard to keep up. Having lots of deployments per day is quite common now, and it's really difficult to keep on top of application security.

How can developers secure their systems?

• start using security tools (might not be the greatest leap, but it's about making small, incremental changes)
• talk about security
• there doesn't seem to be a security culture among developers anymore
• the focus for developers seems to be just ship as much as they can - which the speakers acknowledge isn't the fault of developers, as they have to do what they have to do
• take the time to understand how frameworks can be used to protect you
• trying to build security around culture is harder than trying to build culture around security
• when it comes to getting people involved in security, shifting the frame might help
• don't call it a security audit, call it a "health check"
• bribe people with snacks to convince them to do a health check
• make sure your security team is approachable
• rather than trying to get application teams to make security changes when your team is ready, try and schedule changes around their deployment lifecycle
• don't be alarmist - if you treat everything as though it's on fire and SUPER URGENT!!!!! people will stop caring
• shifting the accountability to product owners / delivery managers can also help. The security team can raise all the issues it likes, but it may just be cheaper to get hacked than fix a vulnerability - and if that's the way the business decides to accept risk, then so be it.

How do you measure application security success? What are some potential KPIs?

Have you been in the news recently? If no, then great success!

Note: that was tongue-in-cheek.

It's a bit difficult to measure success, and it's quite unfortunate that it seems to happen reactively, i.e., companies will only focus on security once they've been hacked.

Bug bounty programs are great and SEEK has had a lot of success with it.

Seeing how much of your codebase gets flagged on static analysis tools. Counting how many security reviews the code has had.

How to prevent phishing?

Run phishing campaigns against your own company, with educational links for the "clickers" explaining what kind of warning signs to look out for. Could also send them on a a training program.

Why are developers not security conscious?

Generally, it seems to be lack of time. Project managers don't want to delay projects to have to deal with potential security issues, as it's not something that the customer sees directly.

But there are also just some developers who don't care, and just want to build cool stuff.

How do you get people to fix vulnerabilities?

Check back with the application teams to make sure they are working on the issues.

It may also be because they don't understand what the issue is, or how they can fix it. If the security team isn't great at communicating problems, or the developers just don't have the required education to know how to fix problems, then all the issues will just remain giant question marks in the backlog.

Don't leave the application as the only line of defense. Put in other controls so that even if the application gets compromised, your entire company doesn't just fall over.

Security education - how do I get it?

Very few universities are tailored towards security. Some will have courses, but they will just be the basics, and not go into any topics in detail. Getting certifications is also quite expensive, especially for recent university graduates - the one that was mentioned cost $1k, just for the exam.

Going to conferences and meet-ups is a great way to pick up knowledge. There are a heap of meet-ups all over the country. Here's the OWASP Melbourne meetup: https://www.meetup.com/en-AU/Application-Security-OWASP-Melbourne

On the other side, it is important for companies to invest in junior people. The industry is growing, and if companies expect to only hire experienced application security experts, the pool of people is going to dry up pretty quickly.

If you have a limited budget, is it better to pay for security tools for your developers, or hire external security experts to come in?

Tools are great... if the people using them know what the output means. Giving tools to developers who haven't had any security training at all will not help them very much - they need the time to learn how to use them.

Plus, they're not designed for developers (one of them quipped that only developers are good enough to make usable tools - security experts write tools to get whatever they need to do done, not to win awards for being beautiful).

But once that education is there, then it'll be helpful for the rest of the project lifecycle. So the earlier you can introduce security tools, the better. Otherwise it might be better just to hire external people who already know what they're looking for / how to fix it.

What can we do to minimise non-technical attack vectors, e.g. fraud, phishing, account takeovers?

Look at the behaviour of your users, are they logging in at unusual times or spending excessively / on unusual things?

(This was the topic of one of the talks I went to, so I'll write more about that later.)

How trustworthy are 3rd party vendors - in particular the ones who claim they can monitor for breaches?

(This question is referring to having another company perform some service with your data, e.g. a company might do credit card processing for you.)

If possible, look at their reputation. Have they had any breaches themselves in the recent past?

If they allow it, try pen testing them. If you can break into their systems, how much can you trust your data with them?

Do they have a security team?

Send them a questionnaire. Not a completely reliable measure, but exact answers don't matter. Look for dodgy sounding marketing-speak-type answers like, "We're 100% secure!" "We've never been hacked!"

Are attacks still the same, or are there more and more cutting-edge attacks being developed?

Most of the attacks follow a standard pattern. A lot of vulnerabilities can be found in the OWASP top 10. Attackers don't always use some super fancy zero-day vulnerability - why bother when the website left its help box unsecured? 95% of the bugs reported to SEEK are in the OWASP top 10.

A big mistake a lot of teams make is bringing in the pen testers too early. If developers checked for the common errors, and pen testers were brought in later in the cycle, the results would be more effective.

Breadth vs depth of knowledge?

Accept that you know nothing!

Learn the OWASP top 10.

With experience, you'll learn "smells"

Know how to research and develop exploits

Dabble in niches only if it's something that interests you - it's a lot easier than forcing yourself to learn something just because you think a security expert should know about it. A couple of the panelists admitted to not knowing much about networks, which makes me incredibly relieved, as that stuff really puts me to sleep.

Go to meet-ups, conferences, and take part in CTFs (Capture the Flag events). There are some online CTFs that you can participate in, for practice.

If you're a developer, try our hand at building a security tool.


-----------------

I really enjoyed this year's event. They did a great job incorporating feedback from last year, and it was easy to get an idea of how technically complex a particular topic would be. I hope they do it again next year.